[Bug ada/43749] installed gnat cannot find installed libraries when exec-prefix != prefix
--- Comment #1 from chrisp_42 at bigpond dot com 2010-04-15 06:16 --- This is a duplicate of http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38493 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43749
[Bug regression/43750] -march unconditionally added to COLLECT_GCC_OPTIONS
--- Comment #4 from jue at jue dot li 2010-04-15 07:05 --- Ok, thanks, I feared that you would say that. Will try to move the issue to glibc. But for now we have the unpleasant situation, that current gcc fails to compile current glibc if host is set to i686. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43750
[Bug ada/43749] installed gnat cannot find installed libraries when exec-prefix != prefix
--- Comment #2 from markus dot schoepflin at comsoft dot de 2010-04-15 07:21 --- Looks like both are duplicates of http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15819. Back then it has been noted that it's just not supported. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43749
[Bug libstdc++/43738] basic_file_stdio.cc uses ioctl on a fd, but not available on mingw32
--- Comment #6 from dannysmith at users dot sourceforge dot net 2010-04-15 07:54 --- (In reply to comment #1) FIONREAD is defined by winsock header How come your build of basic_file_stdio includes winsock api headers? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43738
[Bug c++/43757] New: ICE on -flto
$ /usr/bin/g++-4.5 -v -save-temps-Wall -Wextra -std=gnu++0x -DNDEBUG -O2 -flto -g -I/home/jackyf/work/repos/cupt-git/cupt/cpp/lib/include -o CMakeFiles/cupt.bin.dir/cupt.cpp.o -c /home/jackyf/work/repos/cupt-git/cupt/cpp/console/cupt.cpp Using built-in specs. COLLECT_GCC=/usr/bin/g++-4.5 COLLECT_LTO_WRAPPER=/usr/lib/gcc/i486-linux-gnu/4.5.0/lto-wrapper Target: i486-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.5-20100321-1' --with-bugurl=file:///usr/share/doc/gcc-4.5/README.Bugs --enable-languages=c,c++,java,fortran,objc,obj-c++ --prefix=/usr --enable-shared --enable-multiarch --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.5 --program-suffix=-4.5 --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-plugin --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.5/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.5 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.5 --with-arch-directory=i386 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-targets=all --with-arch-32=i486 --with-tune=generic --enable-checking=yes --build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu Thread model: posix gcc version 4.5.0 20100321 (experimental) [trunk revision 157602] (Debian 4.5-20100321-1) COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall' '-Wextra' '-std=gnu++0x' '-DNDEBUG' '-O2' '-flto' '-g' '-I/home/jackyf/work/repos/cupt-git/cupt/cpp/lib/include' '-o' 'CMakeFiles/cupt.bin.dir/cupt.cpp.o' '-c' '-shared-libgcc' '-mtune=generic' '-march=i486' /usr/lib/gcc/i486-linux-gnu/4.5.0/cc1plus -E -quiet -v -I/home/jackyf/work/repos/cupt-git/cupt/cpp/lib/include -D_GNU_SOURCE -DNDEBUG /home/jackyf/work/repos/cupt-git/cupt/cpp/console/cupt.cpp -mtune=generic -march=i486 -std=gnu++0x -Wall -Wextra -flto -g -fworking-directory -O2 -fpch-preprocess -o cupt.ii ignoring nonexistent directory /usr/local/include/i486-linux-gnu ignoring nonexistent directory /usr/lib/gcc/i486-linux-gnu/4.5.0/../../../../i486-linux-gnu/include ignoring nonexistent directory /usr/include/i486-linux-gnu #include ... search starts here: #include ... search starts here: /home/jackyf/work/repos/cupt-git/cupt/cpp/lib/include /usr/include/c++/4.5 /usr/include/c++/4.5/i486-linux-gnu /usr/include/c++/4.5/backward /usr/local/include /usr/lib/gcc/i486-linux-gnu/4.5.0/include /usr/lib/gcc/i486-linux-gnu/4.5.0/include-fixed /usr/include End of search list. COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall' '-Wextra' '-std=gnu++0x' '-DNDEBUG' '-O2' '-flto' '-g' '-I/home/jackyf/work/repos/cupt-git/cupt/cpp/lib/include' '-o' 'CMakeFiles/cupt.bin.dir/cupt.cpp.o' '-c' '-shared-libgcc' '-mtune=generic' '-march=i486' /usr/lib/gcc/i486-linux-gnu/4.5.0/cc1plus -fpreprocessed cupt.ii -quiet -dumpbase cupt.cpp -mtune=generic -march=i486 -auxbase-strip CMakeFiles/cupt.bin.dir/cupt.cpp.o -g -O2 -Wall -Wextra -std=gnu++0x -version -flto -o cupt.s GNU C++ (Debian 4.5-20100321-1) version 4.5.0 20100321 (experimental) [trunk revision 157602] (i486-linux-gnu) compiled by GNU C version 4.5.0 20100321 (experimental) [trunk revision 157602], GMP version 4.3.2, MPFR version 2.4.2-p1, MPC version 0.8.1 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 GNU C++ (Debian 4.5-20100321-1) version 4.5.0 20100321 (experimental) [trunk revision 157602] (i486-linux-gnu) compiled by GNU C version 4.5.0 20100321 (experimental) [trunk revision 157602], GMP version 4.3.2, MPFR version 2.4.2-p1, MPC version 0.8.1 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Compiler executable checksum: 9f8da535b0aaf549220a9b444fd36470 /home/jackyf/work/repos/cupt-git/cupt/cpp/console/cupt.cpp:92:1: internal compiler error: in dwarf2out_finish, at dwarf2out.c:21268 -- Summary: ICE on -flto Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jackyf dot devel at gmail dot com GCC build triplet: i486-linux-gnu GCC host triplet: i486-linux-gnu GCC target triplet: i486-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43757
[Bug c++/43757] ICE on -flto
--- Comment #1 from jackyf dot devel at gmail dot com 2010-04-15 08:03 --- Created an attachment (id=20386) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20386action=view) preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43757
[Bug c/43755] Bit shifting by a 8 byte variable isn't the same as bit shifting by an 8 or a 4 byte constant on 64bit platform.
--- Comment #3 from jakub at gcc dot gnu dot org 2010-04-15 08:12 --- The only bug here is in your program. ISO C99, 6.5.7/3 says: ... If the value of the right operand is negative or is greater than or equal to the width of the promoted left operand, the behavior is undefined. and that's what happens here. ~0 is 32-bit and shifting it by 32 is undefined behavior. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43755
[Bug target/43742] [4.6 Regression] web.c/union_match_dups segfaults for a null *ref on sh-elf
--- Comment #11 from bernds at gcc dot gnu dot org 2010-04-15 08:57 --- Subject: Bug 43742 Author: bernds Date: Thu Apr 15 08:57:27 2010 New Revision: 158367 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158367 Log: PR target/43742 * config/sh/sh.md (doloop_end_split, dect): Undo previous patch. Use matching constraints to ensure inputs match the output. Modified: trunk/gcc/ChangeLog trunk/gcc/config/sh/sh.md -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43742
[Bug c/4412] possible warning of logic errors not given
--- Comment #2 from P at draigBrady dot com 2010-04-15 09:00 --- GCC 4.5 was released yesterday with -Wlogical-op Thanks :) -- P at draigBrady dot com changed: What|Removed |Added CC||P at draigBrady dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4412
[Bug target/43742] [4.6 Regression] web.c/union_match_dups segfaults for a null *ref on sh-elf
--- Comment #12 from steven at gcc dot gnu dot org 2010-04-15 09:06 --- . -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43742
[Bug target/43723] Some ARMs support unaligned
--- Comment #1 from ramana at gcc dot gnu dot org 2010-04-15 09:13 --- It should be safe for GCC to generate unaligned accesses for newer cores that support this. cheers Ramana -- ramana at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||missed-optimization Known to fail||4.4.3 4.5.0 Last reconfirmed|-00-00 00:00:00 |2010-04-15 09:13:28 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43723
[Bug target/43724] GCC produces suboptimal ARM NEON code for zero vector assignment
--- Comment #2 from ramana at gcc dot gnu dot org 2010-04-15 09:17 --- Confirmed. -- ramana at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-04-15 09:17:28 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43724
[Bug c++/43757] ICE on -flto
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-04-15 09:18 --- *** This bug has been marked as a duplicate of 42987 *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43757
[Bug lto/42987] Testcases local1-a.cc and local1.C cause ICE when compiled with -flto -g
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-04-15 09:18 --- *** Bug 43757 has been marked as a duplicate of this bug. *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||jackyf dot devel at gmail ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42987
[Bug c/43756] Bit shifitng by a constant 32 isn't the same as bitshifting by a variable 32.
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-04-15 09:27 --- Shifting by an amount bigger than the width of the type invokes undefined behavior (that is, target specific behavior in this case). We usually try to simulate target behavior here but the i?86 architecture is inconsistent in itself: /* Define if shifts truncate the shift count which implies one can omit a sign-extension or zero-extension of a shift count. */ /* On i386, shifts do truncate the count. But bit opcodes don't. */ /* #define SHIFT_COUNT_TRUNCATED */ -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID Summary|Bit shifitng by a constant |Bit shifitng by a constant |32 isn't the same as|32 isn't the same as |bitshifting by a variable |bitshifting by a variable |32. |32. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43756
[Bug target/43722] [4.4 only] ICE when passing NEON registers using const refrences
--- Comment #8 from ramana at gcc dot gnu dot org 2010-04-15 09:39 --- Could you submit the patch to gcc-patches@ ? If you need some help in testing this patch let me know and I can do it for you. -- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||ice-on-valid-code Known to fail||4.4.3 Last reconfirmed|-00-00 00:00:00 |2010-04-15 09:39:24 date|| Summary|ICE when passing NEON |[4.4 only] ICE when passing |registers using const |NEON registers using const |refrences |refrences Target Milestone|--- |4.4.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43722
[Bug libstdc++/43738] basic_file_stdio.cc uses ioctl on a fd, but not available on mingw32
--- Comment #7 from sherpya at netfarm dot it 2010-04-15 10:03 --- the correct way should be #if defined(FIONREAD) !defined(_WIN32) or if you prefer __MINGW32__ (note _WIN32 is not defined on cygwin) ioctlsocket is not suitable because it does not work on file descriptors also it will need ws2_32 library at link time -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43738
[Bug libstdc++/43738] basic_file_stdio.cc uses ioctl on a fd, but not available on mingw32
--- Comment #8 from davek at gcc dot gnu dot org 2010-04-15 10:13 --- Mid-air collision! Mid-air collision detected! :) (In reply to comment #5) I remember correctly), I wonder whether we should simply special case mingw32 and conditional to the macro being defined Yeah, that seems like the reasonable answer. (don't remember: _MINGW32?) Nearly: __MINGW32__ just include the required headers, and use ioctlsocket in place of ioctl. Not quite, I think: the correct thing to do would be just #if out the clause altogether. In 'doze, file handles and sockets aren't interchangeable, and FIONREAD is only valid using ioctlsocket on a socket handle. All the C++ stuff will only be using underlying C stdio FILEs, I think, and won't work with sockets at all, so we'll not actually ever have a real socket here. Cygwin goes to great trouble to simulate unix-style fds behind the scenes, but on MinGW you get the raw Windows API which has separate file fds and socket handles, so we'll only ever encounter real files here. Gonna be AFK for most of today I'm afraid but will look at this more tomorrow. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43738
[Bug debug/43478] Missing DW_AT_location for a variable
--- Comment #3 from aoliva at gcc dot gnu dot org 2010-04-15 11:34 --- Created an attachment (id=20387) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20387action=view) Patch that fixes this instance of the problem I'm not convinced we have a bug here. The transformations are all correct, and the unfortunate result is that the variable is completely optimized away. Saying so is fine. That said, it is indeed possible to change tree-ssa-reassoc so that the new stmts are inserted after the debug stmt at hand. I get the impression this would always be safe to do, but it feels like a bit of a waste of effort, and it would hardly fix more general situations, and it might choose an insertion point that is just as unfortunate, and perhaps more surprising. Anyhow, this is the patch I'm testing now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43478
[Bug target/43744] SH: Error: pcrel too far
--- Comment #6 from kkojima at gcc dot gnu dot org 2010-04-15 11:55 --- I've tried 4.4 head 42841 pic-cp.patch and got pcrel too far for the test case db4.8-x.c. So unfortunately, there is still a different issue from 42841. I'd like to reopen this bug. -- kkojima at gcc dot gnu dot org changed: What|Removed |Added CC|kkojima at rr dot iij4u dot | |or dot jp | Status|RESOLVED|REOPENED Resolution|DUPLICATE | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43744
[Bug testsuite/43758] New: [4.6 Regression] 19 new GCC h...@158360 regressions
Between revisions 158346 and 158360 the follwoing tests started to fail: FAIL: g++.dg/ext/altivec-1.C (test for excess errors) FAIL: g++.dg/ext/altivec-10.C (test for excess errors) FAIL: g++.dg/ext/altivec-12.C (test for excess errors) FAIL: g++.dg/ext/altivec-13.C (test for excess errors) FAIL: g++.dg/ext/altivec-14.C (test for excess errors) FAIL: g++.dg/ext/altivec-16.C (test for excess errors) FAIL: g++.dg/ext/altivec-17.C (test for errors, line 15) FAIL: g++.dg/ext/altivec-17.C (test for excess errors) FAIL: g++.dg/ext/altivec-2.C (test for excess errors) FAIL: g++.dg/ext/altivec-3.C (test for excess errors) FAIL: g++.dg/ext/altivec-4.C (test for excess errors) FAIL: g++.dg/ext/altivec-5.C (test for excess errors) FAIL: g++.dg/ext/altivec-6.C (test for excess errors) FAIL: g++.dg/ext/altivec-7.C (test for excess errors) ERROR: g++.dg/ext/altivec-7.C: error executing dg-final: couldn't open altivec-7.s: no such file or directory UNRESOLVED: g++.dg/ext/altivec-7.C: error executing dg-final: couldn't open altivec-7.s: no such file or directory FAIL: g++.dg/ext/altivec-8.C (test for excess errors) FAIL: g++.dg/ext/altivec-9.C (test for excess errors) FAIL: g++.dg/ext/altivec-cell-1.C (test for excess errors) FAIL: g++.dg/ext/altivec-cell-2.C (test for excess errors) FAIL: g++.dg/ext/altivec-cell-3.C (test for excess errors) FAIL: g++.dg/ext/altivec-cell-4.C (test for excess errors) FAIL: g++.dg/ext/altivec-cell-5.C (test for excess errors) The errors are /opt/gcc/_gcc_clean/gcc/testsuite/g++.dg/ext/altivec-1.C:14:3: error: 'vector__' was not declared in this scope /opt/gcc/_gcc_clean/gcc/testsuite/g++.dg/ext/altivec-1.C:15:3: error: 'vector__' was not declared in this scope (see http://gcc.gnu.org/regtest/HEAD/native-logsum/gcc/testsuite/g++/g++.log.gzip for a full log). -- Summary: [4.6 Regression] 19 new GCC h...@158360 regressions Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dominiq at lps dot ens dot fr GCC build triplet: powerpc-apple-darwin9 GCC host triplet: powerpc-apple-darwin9 GCC target triplet: powerpc-apple-darwin9 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43758
[Bug testsuite/43759] New: The tests gcc.dg/plugindir*.c should be restricted to builds configured with --enable-plugin
Since their introduction in revision 158247, the tests gcc.dg/plugindir*.c fail on builds not configured with --enable-plugin (see http://gcc.gnu.org/ml/gcc-testresults/2010-04/msg01084.html ). The failure is cc1: error: Plugin support is disabled. Configure with --enable-plugin. i.e., the tests should be skipped for builds not configured with --enable-plugin. -- Summary: The tests gcc.dg/plugindir*.c should be restricted to builds configured with --enable-plugin Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dominiq at lps dot ens dot fr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43759
[Bug testsuite/43758] [4.6 Regression] 19 new GCC h...@158360 regressions
--- Comment #1 from jakub at gcc dot gnu dot org 2010-04-15 12:50 --- Guess this is related to PR36625 - perhaps some target attributes also need to be treated that way (target hook for that?). -- jakub at gcc dot gnu dot org changed: What|Removed |Added CC||jason at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43758
[Bug ada/38493] Ada compiler does not work with --exec-prefix configuration
--- Comment #2 from dougsemler at gmail dot com 2010-04-15 12:53 --- *** Bug 43749 has been marked as a duplicate of this bug. *** -- dougsemler at gmail dot com changed: What|Removed |Added CC||dougsemler at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38493
[Bug ada/43749] installed gnat cannot find installed libraries when exec-prefix != prefix
--- Comment #3 from dougsemler at gmail dot com 2010-04-15 12:53 --- You're right. When I searched for it, it reported no bugs found (sigh). And I see my solution is exactly the same as 38493. *** This bug has been marked as a duplicate of 38493 *** -- dougsemler at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43749
[Bug testsuite/43758] [4.6 Regression] 19 new GCC h...@158360 regressions
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43758
[Bug target/43722] [4.4 only] ICE when passing NEON registers using const refrences
--- Comment #9 from mikpe at it dot uu dot se 2010-04-15 13:37 --- Created an attachment (id=20388) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20388action=view) proposed 4.3 fix for PR43722 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43722
[Bug target/43722] [4.4 only] ICE when passing NEON registers using const refrences
--- Comment #10 from mikpe at it dot uu dot se 2010-04-15 13:40 --- The proposed 4.4 patch has been posted here: http://gcc.gnu.org/ml/gcc-patches/2010-04/msg00885.html Both the 4.4 and 4.3 patches have been bootstrapped and regtested on armv5tel, but due to lack of NEON HW no NEON runtime tests have been done. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43722
[Bug testsuite/43759] The tests gcc.dg/plugindir*.c should be restricted to builds configured with --enable-plugin
--- Comment #1 from howarth at nitro dot med dot uc dot edu 2010-04-15 13:42 --- Do the other targets like linux enable plugins by default? If so, once... http://gcc.gnu.org/ml/gcc-patches/2010-04/msg00610.html goes into gcc trunk and gcc-4_5-branch, we can just default darwin to build plugin support as well. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43759
[Bug libfortran/43572] [4.5/4.6 Regression] FAIL: gfortran.dg/PR19872.f execution test; formatted read - wrong numbers
--- Comment #16 from dave at hiauly1 dot hia dot nrc dot ca 2010-04-15 13:44 --- Subject: Re: [4.5/4.6 Regression] FAIL: gfortran.dg/PR19872.f execution test; formatted read - wrong numbers (In reply to comment #12) A git bisect between the ranges suggested by Dave in Comment #6, gave me r149470 this as the first broken commit using a cross-compiler to arm-linux-gnueabi with qemu as the simulator . Sigh, that should read 149170. Confirmed. See: http://gcc.gnu.org/ml/gcc-testresults/2010-04/msg01184.html http://gcc.gnu.org/ml/gcc-testresults/2010-04/msg01274.html Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43572
[Bug tree-optimization/43611] [4.5 Regression] ICE: SIGSEGV with -fipa-cp-clone -fkeep-inline-functions
--- Comment #15 from rguenth at gcc dot gnu dot org 2010-04-15 13:44 --- Subject: Bug 43611 Author: rguenth Date: Thu Apr 15 13:44:31 2010 New Revision: 158376 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158376 Log: 2010-04-15 Richard Guenther rguent...@suse.de PR c++/43611 * semantics.c (expand_or_defer_fn_1): Do not keep extern template inline functions. * g++.dg/torture/pr43611.C: New testcase. Added: branches/gcc-4_5-branch/gcc/testsuite/g++.dg/torture/pr43611.C Modified: branches/gcc-4_5-branch/gcc/cp/ChangeLog branches/gcc-4_5-branch/gcc/cp/semantics.c branches/gcc-4_5-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43611
[Bug tree-optimization/43611] [4.5 Regression] ICE: SIGSEGV with -fipa-cp-clone -fkeep-inline-functions
--- Comment #16 from rguenth at gcc dot gnu dot org 2010-04-15 13:44 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to fail||4.5.0 Known to work|4.6.0 |4.5.1 4.6.0 Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43611
[Bug tree-optimization/43627] [4.5 Regression] slow compilation (tree canonical iv takes 75%)
--- Comment #21 from rguenth at gcc dot gnu dot org 2010-04-15 13:47 --- Subject: Bug 43627 Author: rguenth Date: Thu Apr 15 13:46:42 2010 New Revision: 158377 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158377 Log: 2010-04-15 Richard Guenther rguent...@suse.de PR tree-optimization/43627 * tree-vrp.c (extract_range_from_unary_expr): Widenings of [1, +INF(OVF)] go to [1, +INF(OVF)] of the wider type, not varying. * gcc.dg/tree-ssa/vrp49.c: New testcase. Added: branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/tree-ssa/vrp49.c Modified: branches/gcc-4_5-branch/gcc/ChangeLog branches/gcc-4_5-branch/gcc/testsuite/ChangeLog branches/gcc-4_5-branch/gcc/tree-vrp.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43627
[Bug tree-optimization/43627] [4.5 Regression] slow compilation (tree canonical iv takes 75%)
--- Comment #22 from rguenth at gcc dot gnu dot org 2010-04-15 13:47 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work|4.4.3 4.6.0 |4.4.3 4.5.1 4.6.0 Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43627
[Bug target/43729] Mach-O LTO support needed for darwin
--- Comment #6 from howarth at nitro dot med dot uc dot edu 2010-04-15 13:48 --- Can we just use the LTO COFF patch... http://gcc.gnu.org/ml/gcc-patches/2010-04/msg00612.html as a template? Hopefully we can just remove the unnecessary sections of the patch and rename things as appropriate (for a first pass at implementing the Mach-O LTO support). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43729
[Bug target/43729] Mach-O LTO support needed for darwin
--- Comment #7 from stevenb dot gcc at gmail dot com 2010-04-15 14:03 --- Subject: Re: Mach-O LTO support needed for darwin Can we just use the LTO COFF patch...as a template? That is certainly my plan, yes. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43729
[Bug c++/43555] [4.3/4.4/4.5/4.6 Regression] wrong address calculation of multidimensional variable-length array element
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43555
[Bug target/43700] [4.4/4.5/4.6 Regression] global register variables defect
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43700
[Bug c++/43704] [4.5/4.6 Regression] ICE: tree check: accessed elt 2 of tree_vec with 1 elts in tsubst, at cp/pt.c:10074
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43704
[Bug target/43726] [4.5/4.6 Regression] lm32-rtems* ICE
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43726
[Bug middle-end/43740] [4.5/4.6 Regression] FAIL: gcc.dg/tree-ssa/20031015-1.c (internal compiler error)
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 Summary|[4.5 Regression] FAIL: |[4.5/4.6 Regression] FAIL: |gcc.dg/tree-ssa/20031015-1.c|gcc.dg/tree-ssa/20031015-1.c |(internal compiler error) |(internal compiler error) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43740
[Bug middle-end/43760] New: [4.6 regression] New test failures
On Linux/ia64, revision 158361 gave: FAIL: 23_containers/deque/operators/1.cc (test for excess errors) FAIL: gfortran.dg/array_constructor_23.f -O2 (test for excess errors) FAIL: gfortran.dg/array_constructor_24.f -O2 (test for excess errors) Revision 158345 is OK. -- Summary: [4.6 regression] New test failures Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl dot tools at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43760
[Bug middle-end/43760] [4.6 regression] New test failures
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added GCC target triplet||ia64-linux Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43760
[Bug testsuite/43759] The tests gcc.dg/plugindir*.c should be restricted to builds configured with --enable-plugin
--- Comment #2 from dominiq at lps dot ens dot fr 2010-04-15 14:41 --- ... we can just default darwin to build plugin support as well. I think the problem should be addressed (i.e., skip the tests) for any build with plugins not enabled, even if --enable-plugin is the default for the target. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43759
[Bug testsuite/43759] The tests gcc.dg/plugindir*.c should be restricted to builds configured with --enable-plugin
--- Comment #3 from doko at ubuntu dot com 2010-04-15 14:48 --- Subject: Re: The tests gcc.dg/plugindir*.c should be restricted to builds configured with --enable-plugin On 15.04.2010 16:41, dominiq at lps dot ens dot fr wrote: --- Comment #2 from dominiq at lps dot ens dot fr 2010-04-15 14:41 --- ... we can just default darwin to build plugin support as well. I think the problem should be addressed (i.e., skip the tests) for any build with plugins not enabled, even if --enable-plugin is the default for the target. on my list. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43759
[Bug c++/43704] [4.5/4.6 Regression] ICE: tree check: accessed elt 2 of tree_vec with 1 elts in tsubst, at cp/pt.c:10074
--- Comment #5 from hjl dot tools at gmail dot com 2010-04-15 14:57 --- The failure of the testcase in comment #1 is caused by revision 145440: http://gcc.gnu.org/ml/gcc-cvs/2009-04/msg00060.html -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||dseketel at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43704
[Bug libfortran/42763] internal compiler error: in instantiate_virtual_regs_lossage ERROR 1
--- Comment #5 from kargl at gcc dot gnu dot org 2010-04-15 15:54 --- (In reply to comment #3) Subject: Re: internal compiler error: in instantiate_virtual_regs_lossage ERROR 1 On Sat, Jan 16, 2010 at 12:04:27AM -, hcolella at gmail dot com wrote: --- Comment #2 from hcolella at gmail dot com 2010-01-16 00:04 --- I was advised to upgrade g77. I did so, to 4.3, and it did not fix my problem. What to you mean by 'did not fix my problem'? I can compile your code with 4.3.5, 4.4.3, and 4.5.0. Make sure you have completely removed the 4.0.1 version of the software. You may be picking up the wrong version. What does 'gfortran -v' report? No feedback from OP after 3 months. Closing as WORKSFORME -- kargl at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42763
[Bug libstdc++/43738] basic_file_stdio.cc uses ioctl on a fd, but not available on mingw32
--- Comment #9 from paolo dot carlini at oracle dot com 2010-04-15 16:04 --- Agreed, if ioctlsocket can't really replace ioctl, let's just explicitly #if out the affected targets for now. We can still improve it later. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43738
[Bug fortran/30073] Array out of bounds gives name of RHS array not LHS array
--- Comment #2 from kargl at gcc dot gnu dot org 2010-04-15 16:10 --- (In reply to comment #1) Shorter test: real :: a(1,1), b(3) integer :: i b = 45.0 i = 2 a(1,1:i) = b(i) end Gfortran seems to do the right thing on this test case. laptop:kargl[212] gfc4x -o z -fcheck=all a.f90 -fdump-tree-original laptop:kargl[213] ./z At line 5 of file a.f90 Fortran runtime error: Index '2' of dimension 2 of array 'a' outside of expected range (1:1) The original testcase in comment #1 still contains the variable. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30073
[Bug fortran/30073] Array out of bounds gives name of RHS array not LHS array
--- Comment #3 from kargl at gcc dot gnu dot org 2010-04-15 16:28 ---
Looking at the -ftree-dump-original output for the code
in comment #1 finds,
if ((logical(kind=4)) __builtin_expect (a.dim[1].ubound D.1545, 0))
{
_gfortran_runtime_error_at (At line 11 of file a.f90[1]{lb:1 sz:1},
Index \'%ld\' of dimension 2 of array \'t\' outside of expected
range (%ld:%ld)[1]{lb: 1 sz: 1}, (unnamed-signed:32) D.1545,
(unnamed-signed:32) a.dim[1].lbound, (unnamed-signed:32)
a.dim[1].ubound);
}
which shows the correct bounds for 'a' are being checked, but
the wrong variable name 't' is inserted in error message. Note,
this code fragment occurs during the actual act of assignment.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30073
[Bug fortran/42169] [4.4/4.5/4.6 Regression] gfortran.dg/pr41928.f90:47: internal compiler error: in store_can_be_removed_p, at ira-emit.c:371
--- Comment #6 from sje at cup dot hp dot com 2010-04-15 17:10 --- I tried comparing the tree's between hppa2.0w-hp-hpux11.11, where I get the bug and ia64-hp-hpux11.23, where I do not see the bug and I didn't see any real differences in the trees, just differences in the names of generated variables (D.1056 vs. D.1077, etc). I used my cutdown test case, testcase.f90, which is the smallest test case I was able to create. The unnamed-unsigned variables I see are 32 bits and not 64 bits, but the odd thing that I see (on both pa and ia64) is: $ grep D.762 x*.f90.* x.f90.003t.original: unnamed-unsigned:32 D.762; x.f90.003t.original:D.762 = (unnamed-unsigned:32) size.6 * 8; The variable is given a value but never used. These 'unnamed-unsigned' variables seem to disappear during the copyrename1 phase. I think this value is the size of the array, in this case the size of ncoset. I guess the Fortran front-end generates it in case it is needed but in this case it is never needed and so gets optimized away. I don't know if it is related to the problem at all but I do wonder why it is 'unnamed-unsigned' and not given a real type name. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42169
[Bug bootstrap/43761] New: Build Stage 2 and 3 comparison fails
Mac OS X Ver 10.6.3 $ gcc --version i686-apple-darwin10-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5646) (dot 1) Copyright (C) 2007 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. /Users/platt/install/GccSources/gcc-4.5.0.build2 $ ../gcc-4.5.0/configure --enable-languages=c,c++,objc,obj-c++,fortran make Comparing stages 2 and 3 warning: gcc/cc1-checksum.o differs warning: gcc/cc1obj-checksum.o differs warning: gcc/cc1objplus-checksum.o differs warning: gcc/cc1plus-checksum.o differs Bootstrap comparison failure! x86_64-apple-darwin10.3.0/libgomp/.libs/bar.o differs x86_64-apple-darwin10.3.0/libgomp/.libs/barrier.o differs x86_64-apple-darwin10.3.0/libgomp/.libs/env.o differs x86_64-apple-darwin10.3.0/libgomp/.libs/iter.o differs x86_64-apple-darwin10.3.0/libgomp/.libs/iter_ull.o differs x86_64-apple-darwin10.3.0/libgomp/.libs/lock.o differs x86_64-apple-darwin10.3.0/libgomp/.libs/loop.o differs x86_64-apple-darwin10.3.0/libgomp/.libs/loop_ull.o differs x86_64-apple-darwin10.3.0/libgomp/.libs/ordered.o differs x86_64-apple-darwin10.3.0/libgomp/.libs/parallel.o differs x86_64-apple-darwin10.3.0/libgomp/.libs/proc.o differs x86_64-apple-darwin10.3.0/libgomp/.libs/sections.o differs x86_64-apple-darwin10.3.0/libgomp/.libs/single.o differs x86_64-apple-darwin10.3.0/libgomp/.libs/task.o differs x86_64-apple-darwin10.3.0/libgomp/.libs/team.o differs x86_64-apple-darwin10.3.0/libgomp/.libs/work.o differs x86_64-apple-darwin10.3.0/libgomp/bar.o differs x86_64-apple-darwin10.3.0/libgomp/barrier.o differs x86_64-apple-darwin10.3.0/libgomp/env.o differs x86_64-apple-darwin10.3.0/libgomp/iter.o differs x86_64-apple-darwin10.3.0/libgomp/iter_ull.o differs x86_64-apple-darwin10.3.0/libgomp/lock.o differs x86_64-apple-darwin10.3.0/libgomp/loop.o differs x86_64-apple-darwin10.3.0/libgomp/loop_ull.o differs x86_64-apple-darwin10.3.0/libgomp/ordered.o differs x86_64-apple-darwin10.3.0/libgomp/parallel.o differs x86_64-apple-darwin10.3.0/libgomp/proc.o differs x86_64-apple-darwin10.3.0/libgomp/sections.o differs x86_64-apple-darwin10.3.0/libgomp/single.o differs x86_64-apple-darwin10.3.0/libgomp/task.o differs x86_64-apple-darwin10.3.0/libgomp/team.o differs x86_64-apple-darwin10.3.0/libgomp/work.o differs make[2]: *** [compare] Error 1 make[1]: *** [stage3-bubble] Error 2 make: *** [all] Error 2 pl...@mastodon.watson.ibm.com:/Users/platt/install/GccSources/gcc-4.5.0.build2 $ Build DID work with gcc-4.4.3. -- Summary: Build Stage 2 and 3 comparison fails Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danp57 at optonline dot net GCC build triplet: x86_64-apple-darwin10.3.0 GCC host triplet: x86_64-apple-darwin10.3.0 GCC target triplet: x86_64-apple-darwin10.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43761
[Bug c++/19291] Warning cannot pass objects of non-POD type should be an error
--- Comment #8 from manu at gcc dot gnu dot org 2010-04-15 18:08 --- GCC 4.5 gives an error. pr19291.C: In function int main(): pr19291.C:6:19: error: cannot pass objects of non-trivially-copyable type struct std::string through ... So FIXED as far as i can see. -- manu at gcc dot gnu dot org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19291
[Bug c++/19291] Warning cannot pass objects of non-POD type should be an error
-- manu at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19291
[Bug bootstrap/43034] bootstrap with --enable-checking=fold fails
--- Comment #1 from matt at use dot net 2010-04-15 18:21 --- I'm hitting the same thing when bootstrapping 4.5 on Ubuntu 9.10 using GCC 4.4.1: ../../gcc-4.5-20100408/gcc/fold-const.c: In function fold_checksum_tree: ../../gcc-4.5-20100408/gcc/fold-const.c:14251:3: error: new qualifiers in middle of multi-level non-const cast are unsafe my configure command: ../gcc-4.5-20100408/configure --prefix=/home/matt --with-system-zlib --enable-clocale=gnu --enable-lto --enable-languages=c,c++,lto --enable-gold --enable-checking=all --enable-werror --enable-bootstrap -with-plugin-ld=ld.gold --with-demangler-in-ld --enable-shared --enable-threads=posix --with-fpmath=sse -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43034
[Bug libfortran/43572] [4.5/4.6 Regression] FAIL: gfortran.dg/PR19872.f execution test; formatted read - wrong numbers
--- Comment #17 from ramana at gcc dot gnu dot org 2010-04-15 18:39 ---
Created an attachment (id=20389)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20389action=view)
Testcase for the problem.
Can this bug be reprioritized ?
Deep inside _gfortrani_set_integer, there's an incorrect sibling call to memcpy
where it shouldn't be doing so.
64: e28d1010add r1, sp, #16
68: e3a02004mov r2, #4
6c: e521c008str ip, [r1, #-8]!
70: e28dd014add sp, sp, #20
74: e49de004pop {lr}; (ldr lr, [sp], #4)
78: eafeb 0 memcpy
78: R_ARM_PLT32 memcpy
There's no reason why this should be being marked as a valid tail call here.
From the tailcall dumps.
set_integer (void * dest, GFC_INTEGER_8 value, int length)
{
GFC_INTEGER_1 tmp;
GFC_INTEGER_2 tmp;
GFC_INTEGER_4 tmp;
GFC_INTEGER_8 tmp;
GFC_INTEGER_1 tmp.30;
GFC_INTEGER_2 tmp.29;
GFC_INTEGER_4 tmp.28;
size_t length.27;
bb 2:
switch (length_1(D)) default: L4, case 1: L3, case 2: L2, case 4:
L1, case 8: L0
L0:
tmp = value_2(D);
memcpy (dest_4(D), tmp, 8); [tail call]
goto bb 8;
L1:
tmp.28_5 = (GFC_INTEGER_4) value_2(D);
tmp = tmp.28_5;
memcpy (dest_4(D), tmp, 4); [tail call]
goto bb 8;
L2:
tmp.29_7 = (GFC_INTEGER_2) value_2(D);
tmp = tmp.29_7;
memcpy (dest_4(D), tmp, 2); [tail call]
goto bb 8;
L3:
tmp.30_9 = (GFC_INTEGER_1) value_2(D);
tmp = tmp.30_9;
memcpy (dest_4(D), tmp, 1); [tail call]
goto bb 8;
L4:
internal_error (0B, Bad integer kind[0]);
bb 8:
return;
}
Attached is a testcase for this . Reproducible by building a cross-compiler to
arm-eabi .
../trunk/configure --with-cpu=cortex-a8 --target=arm-none-eabi
--enable-languages=c
And command line options for the testcase are just -O2.
You can reproduce this problem with r149170 and the fix up patch applied as
well.
cheers
Ramana
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43572
[Bug c++/43704] [4.5/4.6 Regression] ICE: tree check: accessed elt 2 of tree_vec with 1 elts in tsubst, at cp/pt.c:10074
-- dodji at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dodji at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2010-04-09 19:44:08 |2010-04-15 19:08:18 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43704
[Bug c/18624] GCC does not detect local variable set but never used
--- Comment #24 from manu at gcc dot gnu dot org 2010-04-15 19:32 --- @Jakub, is this FIXED? Could you document this new option in GCC 4.6 changes.html? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18624
[Bug driver/43687] Unexpected error message for bad command line argument
--- Comment #6 from joseph at codesourcery dot com 2010-04-15 19:50 --- Subject: Re: New: Unexpected error message for bad command line argument My multilib selection proposal http://gcc.gnu.org/ml/gcc/2010-01/msg00063.html envisages the driver having a better structured notion of what options exist (shared with cc1), in which context the -- to -f mapping might be implemented through a more general system of option aliases rather than the present textual translation. So those changes should make it easier to give better diagnostics here (and more generally to improve how GCC handles -- options). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43687
[Bug target/43700] [4.4/4.5/4.6 Regression] global register variables defect
--- Comment #8 from mikpe at it dot uu dot se 2010-04-15 19:55 --- 4.3 is also broken. Using the simpler test case in PR43732 and a collection of cross-compilers to mips-unknown-linux I see: gcc-4.1.2: -O2 only: ok; -O2 -ffixed-23: ok gcc-4.2.4: -O2 only: ok; -O2 -ffixed-23: ok gcc-4.3.x: -O2 only: ok; -O2 -ffixed-23: bug (for x in 0..4) gcc-4.4.x: -O2 only: bug; -O2 -ffixed-23: bug (x=0, x=3) gcc-4.5.0: -O2 only: bug; -O2 -ffixed-23: bug So -ffixed- broke between 4.2 and 4.3, and global register variables broke between 4.3 and 4.4. -- mikpe at it dot uu dot se changed: What|Removed |Added CC||mikpe at it dot uu dot se http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43700
[Bug fortran/30073] Array out of bounds gives name of RHS array not LHS array
--- Comment #4 from kargl at gcc dot gnu dot org 2010-04-15 19:55 ---
(In reply to comment #3)
Looking at the -ftree-dump-original output for the code
in comment #1 finds,
if ((logical(kind=4)) __builtin_expect (a.dim[1].ubound D.1545, 0))
{
_gfortran_runtime_error_at (At line 11 of file a.f90[1]{lb:1
sz:1},
Index \'%ld\' of dimension 2 of array \'t\' outside of expected
range (%ld:%ld)[1]{lb: 1 sz: 1}, (unnamed-signed:32) D.1545,
(unnamed-signed:32) a.dim[1].lbound, (unnamed-signed:32)
a.dim[1].ubound);
}
which shows the correct bounds for 'a' are being checked, but
the wrong variable name 't' is inserted in error message. Note,
this code fragment occurs during the actual act of assignment.
The problem is in trans-array.c(gfc_trans_array_bound_check).
The two blocks of code
if (!name se-loop se-loop-ss se-loop-ss-expr
se-loop-ss-expr-symtree)
name = se-loop-ss-expr-symtree-name;
if (!name se-loop se-loop-ss se-loop-ss-loop_chain
se-loop-ss-loop_chain-expr
se-loop-ss-loop_chain-expr-symtree)
name = se-loop-ss-loop_chain-expr-symtree-name;
are meant to set 'name' to the relevant variable. The first
sets 'name' to point at 't' while the second block would set
'name' to point at 'a'. Clearly, the 2nd 'if ()' fails because
'name' is non-null.
If we look further down, we see
/* If upper bound is present, include both bounds in the error message. */
if (check_upper)
{
tmp_lo = gfc_conv_array_lbound (descriptor, n);
tmp_up = gfc_conv_array_ubound (descriptor, n);
if (name)
asprintf (msg, Index '%%ld' of dimension %d of array '%s'
outside of expected RANGE (%%ld:%%ld), n+1, name);
What we need is a way to take 'descriptor' and find the name of
the entity it is associated with.
tobias and I worked out a possible fix on IRC.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30073
[Bug driver/43687] Unexpected error message for bad command line argument
--- Comment #7 from manu at gcc dot gnu dot org 2010-04-15 20:00 ---
(In reply to comment #6)
Subject: Re: New: Unexpected error message for bad command
line argument
My multilib selection proposal
http://gcc.gnu.org/ml/gcc/2010-01/msg00063.html envisages the driver
having a better structured notion of what options exist (shared with cc1),
Do you have preliminary patches? I am trying to implement handling group
options (-Wimplicit) in a more consistent way but that would require to break
up the global options.c in per-FE files to avoid problems with undefined
functions. Is this part of your plan / conflicting with it / indifferent ?
--- gcc/doc/options.texi(revision 158350)
+++ gcc/doc/options.texi(working copy)
@@ -141,10 +141,16 @@ will check and convert the argument befo
option handler. @code{UInteger} should also be used on options like
@code{-falign-loops} where both @code{-falign-loops} and
@code{-falign-loop...@var{n} are supported to make sure the saved
options are given a full integer.
+...@item Group
+This option controls other options. There must be a corresponding
+function @code{set_OPTION} defined somewhere that specifies which
+further actions are taken when this option is enabled/disabled.
+
+
@item Var(@var{var})
The state of this option should be stored in variable @var{var}.
The way that the state is stored depends on the type of option:
@itemize @bullet
in which context the -- to -f mapping might be implemented through a more
general system of option aliases rather than the present textual
translation. So those changes should make it easier to give better
diagnostics here (and more generally to improve how GCC handles --
options).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43687
[Bug driver/43687] Unexpected error message for bad command line argument
--- Comment #8 from joseph at codesourcery dot com 2010-04-15 20:37 --- Subject: Re: Unexpected error message for bad command line argument On Thu, 15 Apr 2010, manu at gcc dot gnu dot org wrote: (In reply to comment #6) Subject: Re: New: Unexpected error message for bad command line argument My multilib selection proposal http://gcc.gnu.org/ml/gcc/2010-01/msg00063.html envisages the driver having a better structured notion of what options exist (shared with cc1), Do you have preliminary patches? I am trying to implement handling group options (-Wimplicit) in a more consistent way but that would require to break up the global options.c in per-FE files to avoid problems with undefined functions. Is this part of your plan / conflicting with it / indifferent ? We have not yet begun implementation. For the semantics of group options, see Appendix 1 in my proposal (if -Wx implies -Wy and -Wz, then -Wno-y -Wx and -Wx -Wno-y both should disable -Wy but enable -Wz). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43687
[Bug driver/43687] Unexpected error message for bad command line argument
--- Comment #9 from manu at gcc dot gnu dot org 2010-04-15 20:52 --- (In reply to comment #8) We have not yet begun implementation. For the semantics of group options, see Appendix 1 in my proposal (if -Wx implies -Wy and -Wz, then -Wno-y -Wx and -Wx -Wno-y both should disable -Wy but enable -Wz). Fair enough this is what i was planning to implement. But my question is how you plan to implement this? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43687
[Bug c++/43704] [4.5/4.6 Regression] ICE: tree check: accessed elt 2 of tree_vec with 1 elts in tsubst, at cp/pt.c:10074
--- Comment #6 from dodji at gcc dot gnu dot org 2010-04-15 21:13 --- A patch was posted to http://gcc.gnu.org/ml/gcc-patches/2010-04/msg00928.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43704
[Bug fortran/43227] [fortran-dev Regression] ICE: segmentation fault in mio_expr
--- Comment #1 from janus at gcc dot gnu dot org 2010-04-15 21:30 --- Here is a reduced test case, which ICEs with the same backtrace: module m_string type t_string character, dimension(:), allocatable :: string contains procedure :: char = string_to_char end type t_string contains function string_to_char (s) result(res) class(t_string), intent(in) :: s character(len=size(s%string)) :: res end function string_to_char end module m_string -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43227
[Bug driver/43687] Unexpected error message for bad command line argument
--- Comment #10 from joseph at codesourcery dot com 2010-04-15 21:30 --- Subject: Re: Unexpected error message for bad command line argument On Thu, 15 Apr 2010, manu at gcc dot gnu dot org wrote: --- Comment #9 from manu at gcc dot gnu dot org 2010-04-15 20:52 --- (In reply to comment #8) We have not yet begun implementation. For the semantics of group options, see Appendix 1 in my proposal (if -Wx implies -Wy and -Wz, then -Wno-y -Wx and -Wx -Wno-y both should disable -Wy but enable -Wz). Fair enough this is what i was planning to implement. But my question is how you plan to implement this? We haven't determined who will end up implementing the proposal or produced an implementation design at that level of detail, but personally I would envisage that the .opt files would contain information about what options imply what sets of other options (and what options are exact aliases of other options) and that the awk scripts would generate appropriate datastructures to be used by code shared by the driver and cc1 etc.; certainly any code specific to a particular option, that is needed to determine the set of enabled features that are potentially relevant to multilib selection, must go somewhere that can be linked into both the driver and cc1. As well as back ends contributing code to be linked in both places, it's possible that front ends will also contribute such code (linked into all of cc1, cc1plus etc.), but generic descriptions in .opt files are preferred where possible. (There are certainly complications such as the implications of options from -On depending on both target and optimization level; I was imagining those would be resolved in the course of implementation rather than producing a detailed design for every patch in a long series up front. I should also point out that the focus of the planned work is the improvements to multilib selection, so some cleanups may end up not being implemented if they end up proving not to be relevant to sharing option-processing and feature-calculation code between the driver and cc1 and creating options structures that can be compared in the driver for multilib selection.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43687
[Bug fortran/30073] Array out of bounds gives name of RHS array not LHS array
--- Comment #5 from kargl at gcc dot gnu dot org 2010-04-15 21:32 --- Subject: Bug 30073 Author: kargl Date: Thu Apr 15 21:32:21 2010 New Revision: 158392 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158392 Log: PR fortran/30073 * trans-array.c (gfc_trans_array_bound_check): Eliminate a redundant block of code. Set name to the variable associated with the descriptor. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-array.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30073
[Bug driver/43687] Unexpected error message for bad command line argument
--- Comment #11 from manu at gcc dot gnu dot org 2010-04-15 21:42 --- (In reply to comment #10) We haven't determined who will end up implementing the proposal or produced an implementation design at that level of detail, but personally You make it sound as a project that will take years to get done. I just want to know whether my current approach is feasible or will be overridden by this work, so I don't waste my free time on this. Basically, group options are marked as such in *.opt and a function pointer is added for each option. The awk scripts assign the function set_Woption to this pointer. This function is hand-written right now but in the future it could be autogenerated. When the option is enabled/disabled, the set_W function is called. If you want I can provide a concrete patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43687
[Bug fortran/30073] Array out of bounds gives name of RHS array not LHS array
--- Comment #6 from kargl at gcc dot gnu dot org 2010-04-15 21:44 --- Fixed on trunk. I'll backport the patch to 4.4 and 4.5 soon. -- kargl at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |kargl at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2007-01-22 21:32:30 |2010-04-15 21:44:28 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30073
[Bug debug/43762] New: VLA artificial length var loclist is missing DW_OP_stack_value
gcc (GCC) 4.6.0 20100415 (experimental)
-O2 -g
-
void __attribute__((noinline))
f (int l)
{
char s[l];
}
int
main (void)
{
f (5);
return 0;
}
-
263: Abbrev Number: 5 (DW_TAG_variable)
64 DW_AT_name: s
68 DW_AT_type: 0x74
174: Abbrev Number: 7 (DW_TAG_array_type)
27d: Abbrev Number: 8 (DW_TAG_subrange_type)
82 DW_AT_upper_bound : 0x59
259: Abbrev Number: 4 (DW_TAG_variable)
5a DW_AT_artificial : 1
5b DW_AT_type: 0x8a
5f DW_AT_location: 0x83 (location list)
18a: Abbrev Number: 10 (DW_TAG_const_type)
8b DW_AT_type: 0x87
187: Abbrev Number: 9 (DW_TAG_base_type)
88 DW_AT_byte_size : 8
89 DW_AT_encoding: 7(unsigned)
24c: Abbrev Number: 3 (DW_TAG_formal_parameter)
4d DW_AT_name: l
51 DW_AT_type: 0x6d
55 DW_AT_location: 0x60 (location list)
16d: Abbrev Number: 6 (DW_TAG_base_type)
6e DW_AT_byte_size : 4
6f DW_AT_encoding: 5(signed)
70 DW_AT_name: int
Contents of the .debug_loc section:
Offset BeginEnd Expression
0060 00400460 00400468 (DW_OP_reg5)
0060 End of list
0083 00400460 00400463 (DW_OP_breg5: 0; DW_OP_const1u:
32; DW_OP_shl; DW_OP_const1u: 32; DW_OP_shra; DW_OP_const1s: -1; DW_OP_plus)
0083 00400463 00400468 (DW_OP_breg5: -1)
0083 00400468 0040046c (DW_OP_breg5: -31)
0083 End of list
-
I believe the loclist at 0x83 should have DW_OP_stack_value on each line.
Even according to recent (offlist) mail by Jakub these are location
expressions.
I do not see in the DWARF spec. an explicit description what should mean a DIE
reference for DW_AT_upper_bound, currently generated by GCC as:
82 DW_AT_upper_bound : 0x59
I believe it was designed to supply there the real variable l holding the
value such as if it would be:
82 DW_AT_upper_bound : 0x4c
If an artificial variable calculating the same value is used the artificial
variable should simulate it has such _value_ (and not such its _address_).
(This problem is also affecting Fortran dynamic arrays with -O2 -g.)
--
Summary: VLA artificial length var loclist is missing
DW_OP_stack_value
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jan dot kratochvil at redhat dot com
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43762
[Bug rtl-optimization/43471] Unnecessary reload of asm m operand address
--- Comment #6 from kkojima at gcc dot gnu dot org 2010-04-15 21:51 --- Subject: Bug 43471 Author: kkojima Date: Thu Apr 15 21:51:14 2010 New Revision: 158393 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158393 Log: PR target/43471 * config/sh/sh.c (sh_legitimize_reload_address): Use MAYBE_BASE_REGISTER_RTX_P instead of BASE_REGISTER_RTX_P. Remove a unneeded check for offset_base. Modified: trunk/gcc/ChangeLog trunk/gcc/config/sh/sh.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43471
[Bug driver/43687] Unexpected error message for bad command line argument
--- Comment #12 from joseph at codesourcery dot com 2010-04-15 22:01 --- Subject: Re: Unexpected error message for bad command line argument On Thu, 15 Apr 2010, manu at gcc dot gnu dot org wrote: I just want to know whether my current approach is feasible or will be overridden by this work, so I don't waste my free time on this. I do not advise stopping fixing bugs just because some future work may implement a more general infrastructure. I would expect the changes for the multilibs proposal to involve a long series of incremental patches against trunk rather than a single large patch dump (given that it involves an audit of all specs for all targets for all options defined in specs, and those are liable to change fast, working other than on trunk would be a bad idea). I don't see adding function pointers as a particular improvement over the existing code where switch statements can already handle group options including setting option variables only if they are still -1 (as done for various options at present); marking group options only seems useful to me if the .opt file also lists implications so that the ordering rules are handled automatically. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43687
[Bug bootstrap/43761] Build Stage 2 and 3 comparison fails
--- Comment #1 from dominiq at lps dot ens dot fr 2010-04-15 22:15 --- This is a duplicate of pr43170. A couple of questions: (1) have you use the terminal for a long time with multiple windows/tabs? (2) can you test gcc.c-torture/compile/limits-structnest.c -O2? It should take a few seconds. If not, abort it after a couple minutes. (3) are you using Mathematica? The reasons of these questions, is that my macbook ended in a curious state in which gcc.c-torture/compile/limits-structnest.c was timed out while regtesting and I had several comparison failures for libgomp. All these disappeared when I had to reboot after the last security patches. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43761
[Bug bootstrap/43170] gcc 4.5 20100218 bootstrap compare fails on os x 10.6
--- Comment #17 from dominiq at lps dot ens dot fr 2010-04-15 22:16 --- pr43761 is a duplicate of this one. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43170
[Bug bootstrap/43170] gcc 4.5 20100218 bootstrap compare fails on os x 10.6
--- Comment #18 from steven at gcc dot gnu dot org 2010-04-15 22:18 --- *** Bug 43761 has been marked as a duplicate of this bug. *** -- steven at gcc dot gnu dot org changed: What|Removed |Added CC||danp57 at optonline dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43170
[Bug bootstrap/43761] Build Stage 2 and 3 comparison fails
--- Comment #2 from steven at gcc dot gnu dot org 2010-04-15 22:18 --- *** This bug has been marked as a duplicate of 43170 *** -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43761
[Bug driver/43687] Unexpected error message for bad command line argument
--- Comment #13 from manu at gcc dot gnu dot org 2010-04-15 22:21 ---
(In reply to comment #12)
I don't see adding function pointers as a particular improvement over the
existing code where switch statements can already handle group options
That code does not work when options are disabled/enabled from anywhere else
apart from the command line. See PR40989.
With function pointers we can do:
+ if (option-var_type == CLVC_BOOLEAN)
+ {
+ if (option-set)
+ option-set (1);
+ if (option-flag_var)
+ *(int *) option-flag_var = 1;
+ }
including setting option variables only if they are still -1 (as done for
various options at present); marking group options only seems useful to me
if the .opt file also lists implications so that the ordering rules are
handled automatically.
This could be implemented later by extending Group to Group(option1,option2).
Then the awk scripts would generate the set_ function. But the function
pointers seem as a first step to me.
But if you think it is a bad idea, I will stop now rather than go on and waste
my time.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43687
[Bug target/43700] [4.4/4.5/4.6 Regression] global register variables defect
--- Comment #9 from mikpe at it dot uu dot se 2010-04-15 22:30 --- MIPS global register variables worked up to r144963 but broke in r144964: URL: http://gcc.gnu.org/viewcvs?root=3Dgccview=3Drevrev=3D144964 Log: 2009-03-19 Alexandre Oliva aol...@redhat.com * reginfo.c (globalize_reg): Recompute derived reg sets. The corresponding gcc-patches thread started here: http://gcc.gnu.org/ml/gcc-patches/2009-03/msg00891.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43700
[Bug driver/43687] Unexpected error message for bad command line argument
--- Comment #14 from joseph at codesourcery dot com 2010-04-15 22:32 --- Subject: Re: Unexpected error message for bad command line argument On Thu, 15 Apr 2010, manu at gcc dot gnu dot org wrote: --- Comment #13 from manu at gcc dot gnu dot org 2010-04-15 22:21 --- (In reply to comment #12) I don't see adding function pointers as a particular improvement over the existing code where switch statements can already handle group options That code does not work when options are disabled/enabled from anywhere else apart from the command line. See PR40989. What I'd imagine for options enabled from pragmas / attributes is that there would be a record kept of the state of options before defaults were applied, and such a late-applied option would effectively be appended to those on the command line, with the defaults then reapplied to determine the options subsequently in effect (or in effect for an individual function, etc.). But for the -Werror=foo issue I'd have thought that making it send the -Wfoo option through the existing option processing machinery - as if both were specified consecutively on the command line - should suffice. That seems largely independent of my proposal, and avoids any issues with needing functions to be present for all front ends. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43687
[Bug driver/43687] Unexpected error message for bad command line argument
--- Comment #15 from manu at gcc dot gnu dot org 2010-04-15 22:42 --- (In reply to comment #14) But for the -Werror=foo issue I'd have thought that making it send the -Wfoo option through the existing option processing machinery - as if both were specified consecutively on the command line - should suffice. That seems largely independent of my proposal, and avoids any issues with needing functions to be present for all front ends. That is not how it works. Not sure whether such approach would work at all. But that still doesn't solve the PR I mentioned because sending -Wfoo through the option machinery does not turn options enabled by Wfoo into errors. Even worse, what do you suggest for -Wno-error=foo? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43687
[Bug fortran/43712] ICE on improperly continued character constant
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2010-04-15 22:55 --- I tried this test case gfortran 4.6.0 (current trunk) and i do not get an ICE. It just works. ??? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43712
[Bug driver/43687] Unexpected error message for bad command line argument
--- Comment #16 from joseph at codesourcery dot com 2010-04-15 23:00 --- Subject: Re: Unexpected error message for bad command line argument On Thu, 15 Apr 2010, manu at gcc dot gnu dot org wrote: --- Comment #15 from manu at gcc dot gnu dot org 2010-04-15 22:42 --- (In reply to comment #14) But for the -Werror=foo issue I'd have thought that making it send the -Wfoo option through the existing option processing machinery - as if both were specified consecutively on the command line - should suffice. That seems largely independent of my proposal, and avoids any issues with needing functions to be present for all front ends. That is not how it works. Not sure whether such approach would work at all. But that still doesn't solve the PR I mentioned because sending -Wfoo through the option machinery does not turn options enabled by Wfoo into errors. Even worse, what do you suggest for -Wno-error=foo? Just as -Wfoo for each foo is a separate option that may have its own case, so it would seem that -Werror=foo and -Wno-error=foo are also rather like separate options. That is, the -Wfoo processing code should take information about which derived option was passed, and use it both for setting variables and enabling / disabling errors (possibly calling a process -W option helper function for each option it implies). But I don't want to design a detailed fix for each bug now. The general idea is that you have code using cases rather than function pointers that works for -Wfoo and -Wno-foo and -Wfoo=bar, and if it can also handle -Werror=foo and -Wno-error=foo then you should avoid complications arising from the use of function pointers. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43687
[Bug fortran/42169] [4.4/4.5/4.6 Regression] gfortran.dg/pr41928.f90:47: internal compiler error: in store_can_be_removed_p, at ira-emit.c:371
--- Comment #7 from sje at cup dot hp dot com 2010-04-15 23:47 --- Since the failure requires -O1 as well as -fbounds-check I tried turning off various -O1 optimizations. I could turn off everything (and still get the bug) except if I use -fno-tree-dominator-opts or -fno-guess-branch-probability. If I use either of these flags the bug does not happen. I think something is happening related to the fact that _gfortran_runtime_error_at is marked as 'NORETURN' that is causing a bad optimization. It may be related to making registers as REG_DEAD but I haven't found a place where I think this marking is actually wrong yet. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42169
[Bug bootstrap/43170] gcc 4.5 20100218 bootstrap compare fails on os x 10.6
--- Comment #19 from danp57 at optonline dot net 2010-04-16 00:44 --- On Apr 15, 2010, at 6:15 PM, dominiq at lps dot ens dot fr wrote: --- Comment #1 from dominiq at lps dot ens dot fr 2010-04-15 22:15 --- This is a duplicate of pr43170. A couple of questions: (1) have you use the terminal for a long time with multiple windows/tabs? (2) can you test gcc.c-torture/compile/limits-structnest.c -O2? It should take a few seconds. If not, abort it after a couple minutes. (3) are you using Mathematica? The reasons of these questions, is that my macbook ended in a curious state in which gcc.c-torture/compile/limits-structnest.c was timed out while regtesting and I had several comparison failures for libgomp. All these disappeared when I had to reboot after the last security patches. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43761 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. You reported the bug, or are watching the reporter. 1) I was using a fresh terminal session -- with path set to avoid my gcc build in /usr/local. 3) I do not have mathematica loaded on my systems. I have a number of other packages, but most of them load their libraries in /usr/local However, some of them were loaded from .dmgs so may have put other libraries in inconvenient places. Examples include MySQL, R, etc. I have a build of gsl, but know for sure this is in /usr/local. I have not checked everything. 2) Your path for item 2 was not complete: it was found in gcc-4.5.0/gcc/testsuite. I tried to compile this into an executable using Apples native gcc, with optimization level -O2. I completed quickly, but no main. The calling routine appears associated with version crt1.10.6.o. pl...@mastodon.local:/Users/platt/install/GccSources/gcc-4.5.0/gcc/testsuite/gcc.c-torture/compile $ gcc -o xx -O2 limits-structnest.c Undefined symbols: _main, referenced from: start in crt1.10.6.o ld: symbol(s) not found collect2: ld returned 1 exit status pl...@mastodon.local:/Users/platt/install/GccSources/gcc-4.5.0/gcc/testsuite/gcc.c-torture/compile $ Best, Dan -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43170
[Bug target/43763] New: segfault when using by -mwarn-cell-microcode
Compiler segfaults in some cases when using -mwarn-cell-microcode. -- Summary: segfault when using by -mwarn-cell-microcode Product: gcc Version: 4.4.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jadamcze at utas dot edu dot au GCC target triplet: powerpc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43763
[Bug target/43763] segfault when using by -mwarn-cell-microcode
--- Comment #1 from jadamcze at utas dot edu dot au 2010-04-16 00:47 --- Created an attachment (id=20390) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20390action=view) snippet that triggers the segfault Segfaults when compiled with -O3 -mcpu=cell -mwarn-cell-microcode. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43763
[Bug target/43763] segfault when using by -mwarn-cell-microcode
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-04-16 00:52 --- Confirmed. The problem is from: /* Vector constant 0 is handled as a splitter of V2SI, and in the pattern of V1DI, V4HI, and V2SF. FIXME: We should probably return # and add post reload splitters for these, but this way is so easy ;-). */ -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC target triplet|powerpc-linux-gnu |powerpc*-*-* Keywords||FIXME, ice-on-valid-code Last reconfirmed|-00-00 00:00:00 |2010-04-16 00:52:30 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43763
[Bug bootstrap/43170] gcc 4.5 20100218 bootstrap compare fails on os x 10.6
--- Comment #20 from danp57 at optonline dot net 2010-04-16 01:06 --- PS This will block any direct or first attempt to build gcc by Mac owners unless they try builds of intermediate versions of gcc. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43170
[Bug target/43764] New: -mrelax-pic-calls fails with complex types
Compiling code that calls a function that returns a complex type with
-mrelax-pic-calls results in an ICE.
khazaddum$ cat tmp.c
__complex__ double cd;
__complex__ double foo (void) { return cd; }
void bar (void) { cd = foo (); }
khazaddum$ ./xgcc -B./ -mabicalls -G0 -mrelax-pic-calls -mexplicit-relocs -O -S
tmp.c
tmp.c: In function bar:
tmp.c:3:1: error: could not split insn
(call_insn/i 6 18 7 tmp.c:3 (parallel [
(set (reg:DF 32 $f0)
(call (mem:SI (reg/f:SI 25 $25 [195]) [0 S4 A32])
(unspec [
(const_int 16 [0x10])
(symbol_ref:SI (foo) [flags 0x3] function_decl
0xb74f4000 foo)
] 55)))
(set (reg:DF 34 $f2)
(call (mem:SI (reg/f:SI 25 $25 [195]) [0 S4 A32])
(const_int 16 [0x10])))
(clobber (reg:SI 31 $31))
]) 574 {call_value_multiple_internal} (expr_list:REG_DEAD (reg/f:SI 25
$25 [195])
(expr_list:REG_EH_REGION (const_int 0 [0x0])
(nil)))
(expr_list:REG_DEP_TRUE (use (reg:SI 79 $fakec))
(nil)))
tmp.c:3:1: internal compiler error: in final_scan_insn, at final.c:2650
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
I used a mipsisa32r2-sde-elf toolchain for this, configured without an
assembler. If you configure properly with an assembler, then it isn't
necessary to give the -mrelax-pic-calls and -mexplicit-relocs options. All you
need it -mabicalls and -G 0.
The problem is in mips_annotate_pic_calls. It looks for a CALL rtx, and then
modifies it. Unfortunately, a function returning complex has a call insn with
2 CALL rtx. Because only one was modified, we end up with unrecognizable RTL.
We either need to disable the optimization in this case, or extend it to work
with a call insn with more than one CALL rtx. The first one is easier, the
second one is preferable.
--
Summary: -mrelax-pic-calls fails with complex types
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: wilson at gcc dot gnu dot org
GCC target triplet: mips*-*-*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43764
[Bug bootstrap/43170] gcc 4.5 20100218 bootstrap compare fails on os x 10.6
--- Comment #21 from rwild at gcc dot gnu dot org 2010-04-16 05:17 --- (In reply to comment #20) PS This will block any direct or first attempt to build gcc by Mac owners unless they try builds of intermediate versions of gcc. A bootstrap comparison failure can easily be worked around by specifying --disable-bootstrap at configure time. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43170
[Bug fortran/43712] ICE on improperly continued character constant
--- Comment #4 from burnus at gcc dot gnu dot org 2010-04-16 05:54 --- (In reply to comment #3) I tried this test case gfortran 4.6.0 (current trunk) and i do not get an ICE. It just works. ??? Same here: gcc version 4.4.0 20090206 -- ICE gcc version 4.5.0 20100409 -- works gcc version 4.6.0 20100415 -- works With -std=f95 -pedantic, I get the diagnostic for the continuation line. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43712
[Bug fortran/42353] [fortran-dev] Bogus Error: Name 'vtype$...' at (1) is an ambiguous reference ...
--- Comment #25 from pault at gcc dot gnu dot org 2010-04-16 05:59 --- Created an attachment (id=20391) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20391action=view) A provisional fix for this PR This bootstraps and regtests. I understand why it works but I want to understand why it is necessary; I think that there is an obvious fix there. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42353
