Opened 12 years ago

Closed 10 years ago

#2368 closed defect (invalid)

AGG fails to compile on OSX Leopard

Reported by: hobu Owned by: tbonfort
Priority: normal Milestone:
Component: AGG Version: unspecified
Severity: normal Keywords:
Cc: kyngchaos

Description

AGG works fine on Tiger, but it doesn't compile on Leopard. I don't know if this is actually AGG's fault or mapagg.cpp's though. gcc -version *says* 4.0.1, but I don't think it's the same, because this works just fine on the gcc 4.0.1 on Tiger.

mapagg.cpp: In function ‘void msCircleDrawShadeSymbolAGG(symbolSetObj*, imageObj*, pointObj*, double, styleObj*, double)’:
mapagg.cpp:1109: error: insn does not satisfy its constraints:
(insn 3243 1354 1355 126 /Users/hobu/dev/releases/agg-2.4/include/agg_color_rgba.h:268 (set (mem:QI (plus:SI (reg/f:SI 6 bp)
                (const_int -728 [0xfffffffffffffd28])) [0 SR.10486+0 S1 A8])
        (reg:QI 4 si)) 56 {*movqi_1} (nil)
    (nil))
mapagg.cpp:1109: internal compiler error: in reload_cse_simplify_operands, at postreload.c:391
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://developer.apple.com/bugreporter> for instructions.
make: *** [mapagg.o] Error 1

Change History (12)

comment:1 Changed 12 years ago by kyngchaos

Finally got to MapServer on Leopard - yay! Some good news on this agg bug...

It appears to be a compiler optimization bug. It's been around for a while on all platforms (lot's of hits on Google), but maybe Apple's customizations hid it in Tiger, and Leopard's changes (even tho it's still GCC 4.0.1) uncovered it.

The easy workaround - use Apple's standard optimization -Os instead of MapServer's default -O2. This works for me, but may not work on other platforms if it ever turns up. The most reliable option I found was turning off all optimization with -O0, but this will slow down MapServer.

I did find one person that simply reorganized their code in the function in which it was happening for them (made another function out of part of the code) and it went away.

comment:2 Changed 12 years ago by tbonfort

Cc: kyngchaos added

hobu or kyngchaos, if you can somehow let me ssh into a leopard machine I can try to rearrange that function to see if we can prevent that error from happening. using -O2 on the agg code is of capital importance performance wise.

comment:3 Changed 12 years ago by kyngchaos

no ssh possible on my end. I agree that no optimization is not good. But is -Os not good enough? It enables all -O2 optimizatoins, except a few that increase code size (maybe a clue where to start). If you can't get ssh access, I'll be glad to try out any ideas you have.

comment:4 in reply to:  3 ; Changed 12 years ago by tbonfort

Replying to kyngchaos:

no ssh possible on my end. I agree that no optimization is not good. But is -Os not good enough? It enables all -O2 optimizatoins, except a few that increase code size (maybe a clue where to start).

hmm, I actually read the gcc man page and you're right -Os is much better than what I imagined.

If you can't get ssh access, I'll be glad to try out any ideas you have.

I don't have any specific ideas except for fiddling around and trying to make the ICE disappear by trial and error. could you give it a try with -O3 ?

comment:5 in reply to:  4 Changed 12 years ago by kyngchaos

Replying to tbonfort:

could you give it a try with -O3 ?

-O3 also works. Interesting - with both -O2 and -O3, I get MANY warnings about variables may be used uninitialized. But with -Os I only get this one:

mapagg.cpp: In function ‘int msDrawLabelCacheAGG(imageObj*, mapObj*)’: mapagg.cpp:1908: warning: ‘p$x’ may be used uninitialized in this function mapagg.cpp:1908: warning: ‘p$y’ may be used uninitialized in this function

comment:6 Changed 12 years ago by tbonfort

I don't think these warnings are very important, given the amount of optimization maxim has put in his code. from the gcc man page

These warnings are made optional because GCC is not smart enough to see all the reasons why the code might be correct despite appearing to have an error.

these warnings only get triggered with the -O flags, and maybe Os triggers less of these cases

maybe a solution could be to have a special compile command in the makefile for mapagg.cpp:

g++ -O3 -Wno-unitialized mapagg.cpp -o mapagg.o

that would seem to fix the ICE on leopard and remove that flood of warnings we can't do much about

comment:7 in reply to:  6 Changed 12 years ago by kyngchaos

Replying to tbonfort:

maybe a solution could be to have a special compile command in the makefile for mapagg.cpp:

Probably not a good idea - you are leaving out any CXXFLAGS that may be added by configure (and thus needed for a platform) and added by the user (-O3 would be a good default, but some may want to use -Os, which also works, and I also use some Apple universal arch flags). How about:

$(CXX) -c $(CXXFLAGS) -O3 -Wno-unitialized mapagg.cpp -o mapagg.o

The gcc docs say that with multiple -O flags, the last one is the one used, so this would override the configured and user optimizations.

comment:8 Changed 12 years ago by tbonfort

Resolution: fixed
Status: newclosed

added -O3 to mapagg compile options in r7042

comment:9 Changed 12 years ago by kyngchaos

Resolution: fixed
Status: closedreopened

It's broken again. Neither -O3 nor -O2 work now. -Os still works. -O3 seems to work now only when debug symbols are turned on with -g (Paul Spencer came across this combination). Possibly, it never worked - I checked -O3 on the 5.0.0 release, but there were a few changes in mapagg since the release, yet none in mapagg/msCircleDrawShadeSymbolAGG() since r7042. I just now tried trunk to verify a different Leopard problem (not a MapServer problem) and hit this bug.

Since it seems to be a random, and OSX Leopard-only, bug, that can change as the code changes, one possible workaround that would be more flexible until the real problem is identified is to have an env variable in the makefile for the mapagg.o target, say $(MAPAGG_OPT). Don't set it anywhere in the makefile, so for the default case, the configured optimization flags are used. If this gcc optimization bug pops up, set MAPAGG_OPT in the shell and run make again. And document this in the readme.

So, in the makefile:

$(CXX) -c $(CXXFLAGS) $(MAPAGG_OPT) -Wno-unitialized mapagg.cpp -o mapagg.o

Then:

$ make

No error, don't do anything. Mapagg.o optimization error, then:

$ export MAPAGG_OPT=-Os
$ make

May need to try different optimizations to find one that works.

Just an option if the real problem remains elusive.

comment:10 Changed 12 years ago by tbonfort

similar problems that have come up on the agg mailing list seem to have been fixed in the 10.5.1 upgrade.

can you try out and confirm?

comment:11 Changed 12 years ago by kyngchaos

I doubt it - all the previous discussion and trials in this bug report was done on 10.5.1. And it would be the Xcode version that has any affect on this anyways, and that hasn't been updated at all yet.

There is talk of a 10.5.2 coming very soon, and hopefully Apple will update Xcode as well. I ran into another optimization problem with GDAL and 64bit mode, along with other compiler and linker issues this is getting annoying.

comment:12 Changed 10 years ago by tbonfort

Resolution: invalid
Status: reopenedclosed

no problem compiling on leopard and snow leopard now, closing

Note: See TracTickets for help on using tickets.