BUG: sdcc-2.7 runtime errors on Mac Intel /w Xcode 2.3 & 2.4

[mdickens@…]

I am a MacOS maintainer for the GNU Radio (GR) project. As Apple has moved to Intel-Macs, a number of us in the GR community are excited because GR is optimized for Intel processors and those new computers have better USB 2.0 support (as per Apple's USB list). With this move, we've found that some early Intel models (MacBook Pro and Mini) worked fine with GR with minimal changes to the code. But recent models (MacBook, iMac, Pro) wouldn't work with the USB-based hardware. GR and DarwinPorts (and the ports themselves) have continued to function properly on PPC-based Macs.

I've spend a considerable amount of time tracking down this issue, and it seems to come down to XCode (gcc) not compiling SDCC "correctly", and thus SDCC not producing "good" FPGA code. I've tried SDCC from both DarwinPorts as well as from source (with no patches and the minimal code changes needed for compilation; no configure flags), with XCode 2.3 and 2.4, with no luck. I haven't tried with 2.2.1 (though others have, with mixed results).

Mid-last summer (around July 12), I did an successful install on a MacBook Pro - and luckily kept a tarball of that around. That particular combination of computer, OSX version (not sure), XCode (2.2.1 or 2.3) and SDCC (2.4.0) magically worked, and thus I'm distributing the pre-compiled binaries instead of the source for Intel-Mac GR users - since there isn't any other reliable way to get SDCC installed and working that I've been able to determine.

From my use of SDCC on Intel-Macs, it's clear that neither SDCC 2.4 or 2.6 fully function on that platform. It -does- function properly on PPC-Macs (at least: PowerBook G4, Dual G4, Dual G5). The only explanation I can find (since otherwise my shell environment is identical and the OS installs are all up to date and the same for all of these computers) is that XCode for Intel is causing SDCC to malfunction.

Hence I'm not sure if it's an SDCC issue or an XCode issue; I do know that I don't have time to look further and I'm happy with the work-around for now.

Thanks in advance for working on this. - MLD

[markd@…]

So I take it that it builds fine but has runtime problems? If the latter, is there a short phrase to characterize them so it can be inserted into the summary line?

[mdickens@…]

Example file which causes a bus error under SDCC 2.6.0 for Intel (XCode 2.3 or 2.4) but not for PPC (either 2.4.0 or 2.6.0).

[mdickens@…]

Yes, SDCC builds just fine in DarwinPorts; 2.6.0 builds for me without changes in XCode 2.3 and 2.4 on my PPC and Intel Macs. But it has 2 obvious runtime problems: (!) the compiled code (from either 2.4.0 or 2.6.0 hacked to work), when run on the FPGA, doesn't work correctly; (2) for one particular file there is a bus error at src/SDCClrange.c:465 due to "prereqv" being NULL. Even working around (2) doesn't create "good" FPGA code. I've attached an archive with 2 files: (a) a C code which causes the bus error on my Intel Mac under 2.6.0 (but not 2.4.0) - created by pulling the parts from other files; (2) the file "DoIt" shows how to run sdcc to compile the file.

A short phrase? "SDCC 2.6 Runtime Issues on Intel Mac under XCode 2.3 or 2.4" is about as concise as I can get.

[markd@…]

That's great. Thank you.

[mdickens@…]

YA data point (from a GR correspondent): "I have another surprising data point to add to this whole thing: I just updated all the darwinports stuff on my wife's Macbook Pro. I rebuilt the world, and guess what, the USRP code builds and runs just fine on that machine with SDCC 2.6! This is with XCode 2.2.1. I seem to have gotten the lucky release. Maybe not all the 2.2.1s are the same (different gcc builds or something)? Mine came from the DVD in the box."

This coming Monday (Oct 16), I will try reverting both the MacBook Pro and Intel-iMac to which I have access back to 2.2.1 (likely not from DVD, but rather as downloaded from connect.apple.com) and see if that makes any difference.

[markd@…]

I hope this problem was reported upstream to the developers as it should have been. I just updated the port to 2.7.0, but someone else will have to determine if the problem was fixed. If it isn't please report upstream and not here.

[mdickens@…]

2.7.0 doesn't fix the problem.

In our further testing, it's seems to be a GCC issue introduced somewhere around 4.0 and still around as of at least 4.2.1 in the standard GCC release as well as Apple's; Apple had multiple releases of XCode 2.2, the earliest of which (and first to support Intel) didn't exhibit this bug (all downloadable versions on developer.apple.com do have the bug). I haven't tried 10.5's compiler yet to know if it works or not; installing on 10.5 will likely present its own problems and issues of just getting the background libraries, applications, and includes installed and functional.

I would love to determine a code-snippet to show off the issue, but it's quite involved. We've been trying to figure out how to report it to the GCC folks, since it's such an indirect bug and therefore hard to describe concisely or even trace.

[markd@…]

Bummer. Reopening ticket.

[jmr@…]

Any improvement with XCode 2.5/3.0?

[mdickens@…]

XCode 3.0 doesn't help on Intel-Mac (still works on PPC Mac). I haven't tried Apple's GCC 4.2 preview for Leopard yet, but will do so and report back.

[mdickens@…]

Apple's GCC 4.2 preview 1 for Leopard does work in compiling SDCC 2.7, produces a whole bunch of warnings about deprecated use of initializing strings to char*'s, but, unfortunately, doesn't take care of this issue. I tried compiling SDCC with no optimization, '-O1', and '-O2', but the all worked the same / broke in the same place with the same bus error and debugging errors. Let's hope preview 2 or the release works better.

[macsforever2000@…]

The test runs without any errors for me on Leopard 10.5.5 Intel and sdcc 2.8.0 (updated today in r40070). I'm closing this ticket.

[mlk@…]

In my testing, SDCC 2.8.0 does indeed resolve the issue. Thanks for keeping up with this. - MLD