[Bug bootstrap/49209] New: Solaris10/SPARC: gcc.c has unresolved references to fatal() while linking xgcc and cpp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49209 Summary: Solaris10/SPARC: gcc.c has unresolved references to fatal() while linking xgcc and cpp Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: nicolai.sta...@zmaw.de Hi everybody, I just tried to bootstrap gcc-4.6.0 on Solaris10 and got this: gcc -g -fkeep-inline-functions -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wc++-compat -fno-common -DHAVE_CONFIG_H -Wl,-R/sw/solaris10/gcc/libelf-0.8.13/lib -Wl,-R/sw/solaris10/gcc/cloog_ppl-0.15.11/lib -Wl,-R/sw/solaris10/gcc/ppl-0.11.2/lib -Wl,-R/sw/solaris10/gcc/mpc-0.8.2/lib -Wl,-R/sw/solaris10/gcc/mpfr-3.0.0/lib -Wl,-R/sw/solaris10/gcc/gmp-5.0.1/lib -o cpp gcc.o opts-common.o gcc-options.o diagnostic.o pretty-print.o input.o vec.o ggc-none.o \ gcc -g -fkeep-inline-functions -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wc++-compat -fno-common -DHAVE_CONFIG_H -Wl,-R/sw/solaris10/gcc/libelf-0.8.13/lib -Wl,-R/sw/solaris10/gcc/cloog_ppl-0.15.11/lib -Wl,-R/sw/solaris10/gcc/ppl-0.11.2/lib -Wl,-R/sw/solaris10/gcc/mpc-0.8.2/lib -Wl,-R/sw/solaris10/gcc/mpfr-3.0.0/lib -Wl,-R/sw/solaris10/gcc/gmp-5.0.1/lib -o xgcc gcc.o opts-common.o gcc-options.o diagnostic.o pretty-print.o input.o vec.o ggc-none.o \ gccspec.o intl.o prefix.o version.o ../libcpp/libcpp.a ./../intl/libintl.a ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a mv -f Tcollect2 collect2 gcc -g -fkeep-inline-functions -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wc++-compat -fno-common -DHAVE_CONFIG_H -Wl,-R/sw/solaris10/gcc/libelf-0.8.13/lib -Wl,-R/sw/solaris10/gcc/cloog_ppl-0.15.11/lib -Wl,-R/sw/solaris10/gcc/ppl-0.11.2/lib -Wl,-R/sw/solaris10/gcc/mpc-0.8.2/lib -Wl,-R/sw/solaris10/gcc/mpfr-3.0.0/lib -Wl,-R/sw/solaris10/gcc/gmp-5.0.1/lib -o cpp gcc.o opts-common.o gcc-options.o diagnostic.o pretty-print.o input.o vec.o ggc-none.o \ cppspec.o intl.o prefix.o version.o ../libcpp/libcpp.a ./../intl/libintl.a ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a Undefined first referenced symbol in file fatal gcc.o ld: fatal: Symbol referencing errors. No output written to xgcc collect2: ld returned 1 exit status gmake[4]: *** [xgcc] Error 1 gmake[4]: *** Waiting for unfinished jobs Undefined first referenced symbol in file fatal gcc.o ld: fatal: Symbol referencing errors. No output written to cpp collect2: ld returned 1 exit status gmake[4]: *** [cpp] Error 1 rm gcc.pod gmake[4]: Leaving directory `/tmp/xas/build/gcc_gcc_4.6.0_default_gcc_32/build/gcc' I fixed this by copying the fatal() from gcc/errors.c to gcc/diagnostic.c. However, it is not clear to me why the link succeeds on Debian Lenny (x64) and fails on Solaris10. I also recognized that there is some code duplication in diagnostic.c and errors.c, maybe they're candidates for a cleanup? Best wishes Nicolai
[Bug libfortran/48982] libgfortran on sysv never uses fpsetmask
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48982 --- Comment #6 from Nicolai Stange nicolai.stange at zmaw dot de 2011-05-28 15:48:41 UTC --- Can you test whether this works on 4.6? Works like a charm with gcc-4.6.0 release (without any diffs applied).
[Bug libfortran/48982] libgfortran on sysv never uses fpsetmask
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48982 --- Comment #4 from Nicolai Stange nicolai.stange at zmaw dot de 2011-05-20 14:14:05 UTC --- (In reply to comment #2) Are you sure you need the #include ieeefp.h Definitely, i've got compile errors when it isn't there.
[Bug libfortran/48982] libgfortran on sysv never uses fpsetmask
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48982 --- Comment #5 from Nicolai Stange nicolai.stange at zmaw dot de 2011-05-20 14:15:44 UTC --- (In reply to comment #3) Can you test whether this works on 4.6? Sure, but this might take some time.
[Bug libfortran/48982] libgfortran on sysv never uses fpsetmask
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48982 --- Comment #1 from Nicolai Stange nicolai.stange at zmaw dot de 2011-05-13 14:44:08 UTC --- Created attachment 24240 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24240 Against 4.5.2 The remove and add of the comment line in fpu-sysv.h within this patch is intentional: It seems to contain stray '\303' and gcc complains about this.
[Bug libfortran/48982] New: libgfortran on sysv never uses fpsetmask
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48982
Summary: libgfortran on sysv never uses fpsetmask
Product: gcc
Version: 4.5.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libfortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: nicolai.sta...@zmaw.de
I'm working on Solaris10/SPARC.
nic@nic-desktop:~/gcc-4.5.3$ grep -r have_fpsetmask . | grep -v libgfor_
./libgfortran/configure.host:if test x${have_fpsetmask} = xyes; then
nic@nic-desktop:~/gcc-4.5.3$
have_fpsetmask won't ever be set anywhere.
libgfor_cv_have_fpsetmask ist set and should be tested instead.
This results in set_fpu coming from fpu-generic.h.
Compiling code w. -ffpe-trap=invalid,zero,overflow results in the following
warnings when executing the code:
Fortran runtime warning: IEEE 'invalid operation' exception not supported.
Fortran runtime warning: IEEE 'division by zero' exception not supported.
Fortran runtime warning: IEEE 'overflow' exception not supported.
Best regards
Nicolai
[Bug rtl-optimization/45967] New: gcc-4.5.x optimizes code with side-effects away
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45967 Summary: gcc-4.5.x optimizes code with side-effects away Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: nicolai.sta...@zmaw.de Created attachment 22016 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22016 testcase containing failer and workaround Hi everybody, while debugging a numpy testuite failer addressing refcounts, I came across a strange optimization issue. Since I have no clue where the problem is located, I decided to choose rtl-optimization as Component. Please correct me if I'm wrong. I'm not even sure if this really is a bug (although I'm believing it), but the people in #gcc told me to post it here. I've broken down the problem to a simple testcase (see attached testcase.c). Compile with gcc -c -Wall -O1 testcase.c and have a look at the produced assembler output with objdump -S testcase.o There are two functions in my testcase: one that will be empty (PyArray_Item_XDECREF) and one that uses a workaround that works even with -O3 (PyArray_Item_XDECREF_workaround). The workaround seems to introduce some data dependency, though I don't know exactly what it does, I've found it by trial and error. To help you locating the issue: It only appears with -O1. Everything works fine with the options documented in 'man gcc', that is -fauto-inc-dec -fcprop-registers -fdce -fdefer-pop -fdelayed-branch -fdse -fguess-branch-probability -fif-conversion2 -fif-conversion -fipa-pure-const -fipa-reference -fmerge-constants -fsplit-wide-types -ftree-builtin-call-dce -ftree-ccp -ftree-ch -ftree-copyrename -ftree-dce -ftree-dominator-opts -ftree-dse -ftree-forwprop -ftree-fre -ftree-phiprop -ftree-sra -ftree-pta -ftree-ter -funit-at-a-time given explicitly (and without any -O*) on gcc's command line. I've tested with testcase.c with different gcc versions on different platforms. The workaround function always contains correct assembler code. Only the results for PyArray_Item_XDECREF: It either contains correct code or it is empty (except entering and leaving a stack frame). +--+++---+ |Version |Platform|Optimization|Result | +--+++---+ |4.1.2 |i486-linux-gnu |-O3 |works | |(Debian ||| | |4.1.1-21) ||| | +--+++---+ |4.2.0 |sparcv9-sun-solaris2.10 |-O3 |works | |(self ||| | |compiled) ||| | +--+++---+ |4.3.2 |x86_64-linux-gnu|-O3 |works | |(Debian ||| | |4.3.2-1.1)||| | +--+++---+ |4.4.0 |i686-pc-linux-gnu |-O3 |works | |(self ||| | |compiled) ||| | +--+++---+ |4.4.3 |x86_64-unknown-linux-gnu|-O3 |works | |(self ||| | |compiled) ||| | +--+++---+ |4.4.3 |sparc-sun-solaris2.10 |-O3 |works | |(self ||| | |compiled) ||| | +--+++---+ |4.5.0 |x86_64-unknown-linux-gnu|-O1 |fail | |(self ||| | |compiled) ||| | +--+++---+ |4.5.1 |i686-pc-linux-gnu |-O1 |fail | |(self ||| | |compiled) ||| | +--+++---+ |4.5.1 |sparc-sun-solaris2.10 |-O1 |fail | |(self ||| | |compiled) ||| | +--+++---+ As you can see, the issue is not dependent on the target architecture, but on gcc's version. It seems to have been introduced post-4.4.3 (unfortunately I have no 4.4.4/4.4.5 here) Thank you very much Nicolai
[Bug middle-end/45508] Does adding configure-options for specs-hardcoding make sense?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45508 --- Comment #7 from Nicolai Stange nicolai.stange at zmaw dot de 2010-10-04 19:05:30 UTC --- libgomp, libgcc and libssp are the shared libs of gcc. (actually the correct libstdc++ and libgfortran are also found if the correct libgcc is found as they never are linked in without it). libgomp comes with an spec file that is installed into the lib dir. I've added switches to gcc's configure to specify the link specs of these two libs. I've tested it and it works perfectly for me.
