gcc-4.8 (and likely earlier) build incorrectly +universal

[jeremyhu (Jeremy Huddleston Sequoia)]

I noticed this when trying to build libgcc on a Leopard VM:

/usr/bin/g++-4.2 -arch i386 -c   -g -DIN_GCC   -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common  -DHAVE_CONFIG_H -I. -I. -I/opt/local/var/macports/build/_Users_jeremy_src_macports_trunk_dports_lang_gcc48/libgcc/work/gcc-4.8.1/gcc -I/opt/local/var/macports/build/_Users_jeremy_src_macports_trunk_dports_lang_gcc48/libgcc/work/gcc-4.8.1/gcc/. -I/opt/local/var/macports/build/_Users_jeremy_src_macports_trunk_dports_lang_gcc48/libgcc/work/gcc-4.8.1/gcc/../include -I/opt/local/var/macports/build/_Users_jeremy_src_macports_trunk_dports_lang_gcc48/libgcc/work/gcc-4.8.1/gcc/../libcpp/include -I/opt/local/include -I/opt/local/include -I/opt/local/include  -I/opt/local/var/macports/build/_Users_jeremy_src_macports_trunk_dports_lang_gcc48/libgcc/work/gcc-4.8.1/gcc/../libdecnumber -I/opt/local/var/macports/build/_Users_jeremy_src_macports_trunk_dports_lang_gcc48/libgcc/work/gcc-4.8.1/gcc/../libdecnumber/dpd -I../libdecnumber -I/opt/local/var/macports/build/_Users_jeremy_src_macports_trunk_dports_lang_gcc48/libgcc/work/gcc-4.8.1/gcc/../libbacktrace   -I/opt/local/include /opt/local/var/macports/build/_Users_jeremy_src_macports_trunk_dports_lang_gcc48/libgcc/work/gcc-4.8.1/gcc/pointer-set.c -o pointer-set.o
/opt/local/var/macports/build/_Users_jeremy_src_macports_trunk_dports_lang_gcc48/libgcc/work/gcc-4.8.1/gcc/pointer-set.c:60: error: integer constant is too large for ‘unsigned long’ type
/opt/local/var/macports/build/_Users_jeremy_src_macports_trunk_dports_lang_gcc48/libgcc/work/gcc-4.8.1/gcc/pointer-set.c: In function ‘size_t hash1(const void*, long unsigned int, long unsigned int)’:
/opt/local/var/macports/build/_Users_jeremy_src_macports_trunk_dports_lang_gcc48/libgcc/work/gcc-4.8.1/gcc/pointer-set.c:60: warning: large integer implicitly truncated to unsigned type

My hunch is that gcc's build system is checking sizeof(long) at configure time for x86_64 and using it for the i386 slice:

configure:5912: /usr/bin/gcc-4.2 -arch i386 -arch x86_64 -o conftest -g    -L/opt/local/lib -Wl,-headerpad_max_install_names 
conftest.c  >&5
configure:5912: $? = 0
configure:5912: ./conftest
configure:5912: $? = 0
configure:5927: result: 8

This needs to be solved in a way similar to how we solve it in X11: ​http://cgit.freedesktop.org/xorg/xserver/tree/include/dix-config-apple-verbatim.h ​http://cgit.freedesktop.org/xorg/xserver/tree/include/dix-config.h.in

[jeremyhu (Jeremy Huddleston Sequoia)]

It looks like this goes back to the GPL2 versions, and assuming it hasn't changed in the mean time, we should be able to add this verbatim:

#if !defined(USED_FOR_TARGET) && defined(__APPLE__)
#undef SIZEOF_LONG
#if __LP64__
#define SIZEOF_LONG 8
#else
#define SIZEOF_LONG 4
#endif

to each of:

gcc/config.in:#undef SIZEOF_LONG
libcpp/config.in:#undef SIZEOF_LONG
libdecnumber/config.in:#undef SIZEOF_LONG
libgomp/config.h.in:#undef SIZEOF_LONG

[jeremyhu (Jeremy Huddleston Sequoia)]

I think the reason we don't see this newer than Leopard is because this is only happening when USED_FOR_TARGET which just picks the first arch (which is x86_64 on SL+ but i386 on Leo)

[jeremyhu (Jeremy Huddleston Sequoia)]

The GPL2 patch I made mostly applies to the GPL3 gccs, so I should have a blind fix for this.

[jeremyhu (Jeremy Huddleston Sequoia)]

initial patch

[larryv (Lawrence Velázquez)]

Cc Me!

[larryv (Lawrence Velázquez)]

patch generated against GCC 4.8 source

[larryv (Lawrence Velázquez)]

patch generated against GCC 4.3 through GCC 4.7 source

[larryv (Lawrence Velázquez)]

This patch​ applies your changes directly to GCC 4.8, and this one​ does so for GCC 4.3 through 4.7.

[jeremyhu (Jeremy Huddleston Sequoia)]

I seem to have let this one slip by. Can you push your changes?

[ryandesign (Ryan Carsten Schmidt)]

Is this still an issue?