[Bug driver/46516] gfortran-trunk: error: libgfortran.spec: No such file or directory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46516 --- Comment #5 from Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch 2010-11-17 08:02:53 UTC --- (In reply to comment #4) I suppose it's the --disable-multilib, but I don't know why. Yes, it is certainly this. The driver seems to search only in the lib directory and not in the lib64 directory. If I copy the spec file from lib64 to lib it works.
[Bug driver/46516] gfortran-trunk: error: libgfortran.spec: No such file or directory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46516 --- Comment #6 from Tobias Burnus burnus at gcc dot gnu.org 2010-11-17 08:20:07 UTC --- (In reply to comment #5) (In reply to comment #4) I suppose it's the --disable-multilib, but I don't know why. Yes, it is certainly this. The driver seems to search only in the lib directory and not in the lib64 directory. If I copy the spec file from lib64 to lib it works. What's the content of the $BUILD/gcc/multilib.h file? In particular the multilib_raw one? Here, it is (x86-64-linux with multilib): static const char *const multilib_raw[] = { . !m64 !m32;, 64:../lib64 m64 !m32;, 32:../lib !m64 m32;, NULL }; I fear that the current multilib support assumes that the path only has a suffix if one has multilib enabled; cf. gcc.c's for_each_path which is called by find_a_file. It seems to search without multilib in, e.g. /usr/lib and with multilib in /usr/lib/../lib64 for -m64 /usr/lib/../libfor -m32 /usr/lib/. for neither -m32 nor -m64 (does this ever happen?) I think that was a good assumption before the 64bit support on x86-64 was added; there, old programs (with /usr/lib) should continue to work thus the 64bit libs where placed at a non-default directory: /usr/lib64. (For all above: Analogously for /usr/local/lib and $PREFIX/lib etc.) Hence, I am interested how a --disable-multilib $BUILD/gcc/multilib.h looks like.
[Bug driver/46516] Non-multilib search problem in gcc.c / gfortran error: libgfortran.spec: No such file or directory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46516 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Target||x86_64-unknown-linux-gnu Host||x86_64-unknown-linux-gnu Target Milestone|--- |4.6.0 Summary|gfortran-trunk: error: |Non-multilib search problem |libgfortran.spec: No such |in gcc.c / gfortran error: |file or directory |libgfortran.spec: No such ||file or directory Build||x86_64-unknown-linux-gnu
[Bug driver/46516] Non-multilib search problem in gcc.c / gfortran error: libgfortran.spec: No such file or directory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46516 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||joseph at codesourcery dot ||com --- Comment #7 from Tobias Burnus burnus at gcc dot gnu.org 2010-11-17 08:31:06 UTC --- CC Joseph, who - after Alan Modra in 2005 (for PR 20425) - seems to be the only one who has ever touched gcc.c's multilib.
[Bug driver/46516] Non-multilib search problem in gcc.c / gfortran error: libgfortran.spec: No such file or directory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46516 --- Comment #8 from Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch 2010-11-17 08:46:11 UTC --- mine look like: static const char *const multilib_raw[] = { . !m64 !m32;, .:../lib64 m64 !m32;, .:../lib !m64 m32;, NULL }; however, I just observe that the libgomp.spec are causing no problems in my build.
[Bug driver/46516] Non-multilib search problem in gcc.c / gfortran error: libgfortran.spec: No such file or directory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46516 --- Comment #9 from Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch 2010-11-17 08:50:06 UTC --- FYI, with strace I see following things being searched for the specs: access(/data/vondele/gcc_bench/gcc_trunk/build/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/, X_OK) = 0 access(/data/vondele/gcc_bench/gcc_trunk/build/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/, X_OK) = 0 access(/data/vondele/gcc_bench/gcc_trunk/build/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/specs, R_OK) = -1 E NOENT (No such file or directory) access(/data/vondele/gcc_bench/gcc_trunk/build/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/../../../../x86_64-u nknown-linux-gnu/lib/x86_64-unknown-linux-gnu/4.6.0/specs, R_OK) = -1 ENOENT (No such file or directory) access(/data/vondele/gcc_bench/gcc_trunk/build/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/../../../../x86_64-u nknown-linux-gnu/lib/specs, R_OK) = -1 ENOENT (No such file or directory) access(/data/vondele/gcc_bench/gcc_trunk/build/lib/gcc/x86_64-unknown-linux-gnu/specs, R_OK) = -1 ENOENT (No such file or directory) access(/data/vondele/gcc_bench/gcc_trunk/build/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/, X_OK) = 0 access(/data/vondele/gcc_bench/gcc_trunk/build/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/libgfortran.spec, R _OK) = -1 ENOENT (No such file or directory) access(/data/vondele/gcc_bench/gcc_trunk/build/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/../../../../x86_64-u nknown-linux-gnu/lib/x86_64-unknown-linux-gnu/4.6.0/libgfortran.spec, R_OK) = -1 ENOENT (No such file or d irectory) access(/data/vondele/gcc_bench/gcc_trunk/build/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/../../../../x86_64-u nknown-linux-gnu/lib/libgfortran.spec, R_OK) = -1 ENOENT (No such file or directory) access(/data/vondele/gcc_bench/gcc_trunk/build/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/../../../x86_64-unkn own-linux-gnu/4.6.0/libgfortran.spec, R_OK) = -1 ENOENT (No such file or directory) access(/data/vondele/gcc_bench/gcc_trunk/build/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/../../../libgfortran .spec, R_OK) = -1 ENOENT (No such file or directory) access(/lib/x86_64-unknown-linux-gnu/4.6.0/libgfortran.spec, R_OK) = -1 ENOENT (No such file or directory ) access(/lib/libgfortran.spec, R_OK) = -1 ENOENT (No such file or directory) access(/usr/lib/x86_64-unknown-linux-gnu/4.6.0/libgfortran.spec, R_OK) = -1 ENOENT (No such file or direc tory) access(/usr/lib/libgfortran.spec, R_OK) = -1 ENOENT (No such file or directory) open(libgfortran.spec, O_RDONLY) = -1 ENOENT (No such file or directory)
[Bug driver/46516] Non-multilib search problem in gcc.c / gfortran error: libgfortran.spec: No such file or directory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46516 --- Comment #10 from Tobias Burnus burnus at gcc dot gnu.org 2010-11-17 09:27:21 UTC --- (In reply to comment #8) however, I just observe that the libgomp.spec are causing no problems in my build. Are they actually read? Even here, where I use multilib and the gfortran.spec is found, I do not see that the libgomp.spec is read - at least I do not see a line like: Reading specs from ... libgomp.spec unless I explicitly pass '-specs=libgomp.spec' to the driver. My impression is that libgomp.spec should be read if found, otherwise the defaults are used. But seemingly, it is never read - also strace does not show anything.
[Bug c/46517] New: Wrong result on left shift operator without optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46517 Summary: Wrong result on left shift operator without optimization Product: gcc Version: 4.4.4 Status: UNCONFIRMED Severity: major Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: lepi...@free.fr The next samples compiled without opimisation give not the same result in both case if it's use has constante the result is good (the test is on intel platfom) # gcc -o shift shift.c result: constant val=0 variable val=1 # gcc -O2 -o shift shift.c result: constant val=0 variable val=0 On the first case is not a shift but it's rotate you can verify by changing the constant: example SHIFT = 34 the the result is constant val=0 variable val=4 88888 #include stdio.h #define SHIFT(4*8) int main(int argc, char* argv[]) { int val = SHIFT; printf(constant val=%x\n, (1SHIFT)); printf(variable val=%x\n, (1val)); return 0; } 88888
[Bug libstdc++/46455] resource leaks due to missing destructors for mutexes and condvars
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46455 --- Comment #30 from Jonathan Wakely redi at gcc dot gnu.org 2010-11-17 09:37:37 UTC --- (In reply to comment #29) because __gthread_mutex_destroy returns void. Argh, why is gthr-win32.h different here?! Nevermind ... after changing the return types of the _S_destroy functions to void and removing the return specifiers, the test case compiles and runs fine without any leak. Great, thanks very much for testing. I'll get similar changes done to mutex and get this checked in.
[Bug driver/46516] Non-multilib search problem in gcc.c / gfortran error: libgfortran.spec: No such file or directory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46516 --- Comment #11 from Tobias Burnus burnus at gcc dot gnu.org 2010-11-17 09:40:52 UTC --- (In reply to comment #10) Are they actually read? Sorry, I tested wrongly. One needs to have both -fopenmp *and* one needs to link. Then I also sees Read specs + strace for libgomp.spec. I think I just will bootstrap with --disable-multilib and keep silent until I have debugged this.
[Bug c/46460] warn for shifting more than the bits in the (promoted) type is undefined
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46460 Andreas Schwab sch...@linux-m68k.org changed: What|Removed |Added CC||lepinat at free dot fr --- Comment #3 from Andreas Schwab sch...@linux-m68k.org 2010-11-17 09:45:16 UTC --- *** Bug 46517 has been marked as a duplicate of this bug. ***
[Bug c/46517] Wrong result on left shift operator without optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46517 Andreas Schwab sch...@linux-m68k.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #1 from Andreas Schwab sch...@linux-m68k.org 2010-11-17 09:45:15 UTC --- . *** This bug has been marked as a duplicate of bug 46460 ***
[Bug tree-optimization/46312] gcc.dg/vec-scal-opt2.c fails for ARM targets.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46312 --- Comment #11 from irar at gcc dot gnu.org 2010-11-17 10:00:34 UTC --- Author: irar Date: Wed Nov 17 10:00:27 2010 New Revision: 166860 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=166860 Log: PR tree-optimization/46312 * gcc.dg/vect/vect-scal-opt2.c: Rename to... * gcc.dg/vect/vec-scal-opt2.c: ... this. Expect to pass only on targets that support vector shifts with scalar shift argument. Remove dg-options. * gcc.dg/vect/vect-scal-opt.c: Rename to... * gcc.dg/vect/vec-scal-opt.c: ... this, and change likewise. * gcc.dg/vect/vect-scal-opt1.c: Rename to... * gcc.dg/vect/vec-scal-opt1.c: ... this, and change likewise. * gcc.dg/vect/vect.exp: Run vec-scal-* tests with relevant flags. * gcc.dg/vect/vect-114.c: Expect to pass only on targets that support misaligned data accesses. * gcc.dg/vect/pr43432.c, gcc.dg/vect/vect-15.c: Likewise. * gcc.dg/vect/pr43430-2.c: Remove dg-options. * lib/target-supports.exp (check_effective_target_vect_shift_scalar): New. Added: trunk/gcc/testsuite/gcc.dg/vect/vec-scal-opt.c trunk/gcc/testsuite/gcc.dg/vect/vec-scal-opt1.c trunk/gcc/testsuite/gcc.dg/vect/vec-scal-opt2.c Removed: trunk/gcc/testsuite/gcc.dg/vect/vect-scal-opt.c trunk/gcc/testsuite/gcc.dg/vect/vect-scal-opt1.c trunk/gcc/testsuite/gcc.dg/vect/vect-scal-opt2.c Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/vect/pr43430-2.c trunk/gcc/testsuite/gcc.dg/vect/pr43432.c trunk/gcc/testsuite/gcc.dg/vect/vect-114.c trunk/gcc/testsuite/gcc.dg/vect/vect-15.c trunk/gcc/testsuite/gcc.dg/vect/vect.exp trunk/gcc/testsuite/lib/target-supports.exp
[Bug testsuite/45429] [4.6 Regression] gcc.dg/vect/no-section-anchors-vect-64.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45429 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |NEW CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2010-11-17 10:20:16 UTC --- In ia64 cross I see that only one Alignment of access forced using peeling message is printed (for the first loop), instead of two (for the first and third loop). If 163561 was ok, then then difference is most probably the change to the testcase itself: http://gcc.gnu.org/viewcvs/trunk/gcc/testsuite/gcc.dg/vect/no-section-anchors-vect-64.c?r1=163563r2=163562pathrev=163563 The culprit is the change of id array. I guess we could do something like: --- gcc/testsuite/gcc.dg/vect/no-section-anchors-vect-64.c.jj2010-11-17 11:18:22.0 +0100 +++ gcc/testsuite/gcc.dg/vect/no-section-anchors-vect-64.c2010-11-17 11:17:39.0 +0100 @@ -8,7 +8,7 @@ int ib[N] = {0,3,6,9,12,15,18,21,24,27,30,33,36,39,42,45}; int ia[N][4][N+1]; int ic[N][N][3][N+1]; -int id[N][N][N+1]; +int id[N][N][N+4]; __attribute__ ((noinline)) (at least this seems to work for both ia64 and x86_64).
[Bug testsuite/45429] [4.6 Regression] gcc.dg/vect/no-section-anchors-vect-64.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45429 --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2010-11-17 10:25:40 UTC --- And the reason why it only shows up on ia64 is because it uses vectorization factor 2 instead of 4 that is used on x86_64/i386+sse2. With: int id[16][16][17] id[i][1][0+1] is actually aligned to 2 * sizeof (int), so no peeling is needed to align it.
[Bug testsuite/45429] [4.6 Regression] gcc.dg/vect/no-section-anchors-vect-64.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45429 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |jakub at gcc dot gnu.org |gnu.org |
[Bug tree-optimization/46498] [4.5/4.6 Regression] ICE: in eliminate_unnecessary_stmts, at tree-ssa-dce.c:1112 with -O -funsafe-math-optimizations -fno-tree-dominator-opts -fno-tree-reassoc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46498 --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2010-11-17 10:43:25 UTC --- Author: rguenth Date: Wed Nov 17 10:43:21 2010 New Revision: 166861 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=166861 Log: 2010-11-16 Richard Guenther rguent...@suse.de PR tree-optimization/46498 * tree-ssa-dce.c (perform_tree_ssa_dce): Compute dominator info. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-dce.c
[Bug c++/46513] Request: Warning for use of unsafe string handling functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46513 --- Comment #5 from Jonathan Wakely redi at gcc dot gnu.org 2010-11-17 10:43:51 UTC --- (In reply to comment #3) I know finding the replacement is not a GCC issue, but perhaps folks who need to the *nix safe string gear can use TR24731-2 (not TR24731-1), which is POSIX and includes strl* and friends. TR24731-2 does include functions from POSIX, but the only string handling ones in n1337 are strdup and strndup, not strl* - and I might be wrong but I don't know of any plans to add strl* to POSIX. Besides, anything in C1x will not make it into a C++ standard for many years, we're still trying to get C++0x finished and new features won't be added now. Maybe this request should be for the C front end? Otherwise you're requesting warnings in C++ code about functions for which there are no portable, standardised alternative available.
[Bug tree-optimization/46498] [4.5/4.6 Regression] ICE: in eliminate_unnecessary_stmts, at tree-ssa-dce.c:1112 with -O -funsafe-math-optimizations -fno-tree-dominator-opts -fno-tree-reassoc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46498 --- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2010-11-17 10:46:40 UTC --- Author: rguenth Date: Wed Nov 17 10:46:36 2010 New Revision: 166862 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=166862 Log: 2010-11-17 Richard Guenther rguent...@suse.de PR tree-optimization/46498 * tree-ssa-dce.c (perform_tree_ssa_dce): Compute dominator info. Modified: branches/gcc-4_5-branch/gcc/ChangeLog branches/gcc-4_5-branch/gcc/tree-ssa-dce.c
[Bug middle-end/45838] [4.6 Regression] FAIL: libgomp.c/pr34513.c execution test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45838 --- Comment #12 from Jakub Jelinek jakub at gcc dot gnu.org 2010-11-17 11:15:59 UTC --- Author: jakub Date: Wed Nov 17 11:15:55 2010 New Revision: 166863 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=166863 Log: PR middle-end/45838 * tree-ssa-alias.c (ref_maybe_used_by_call_p_1, call_may_clobber_ref_p_1): Return true for __sync_* and some OpenMP builtins that act as threading barriers. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-alias.c
[Bug middle-end/45838] [4.6 Regression] FAIL: libgomp.c/pr34513.c execution test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45838 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #13 from Jakub Jelinek jakub at gcc dot gnu.org 2010-11-17 11:18:18 UTC --- Fixed.
[Bug tree-optimization/46498] [4.5/4.6 Regression] ICE: in eliminate_unnecessary_stmts, at tree-ssa-dce.c:1112 with -O -funsafe-math-optimizations -fno-tree-dominator-opts -fno-tree-reassoc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46498 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #4 from Richard Guenther rguenth at gcc dot gnu.org 2010-11-17 11:18:37 UTC --- Fixed.
[Bug lto/46502] collect2 LTO marker detection is fragile wrt. to nm output format
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46502 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2010-11-17 11:41:11 UTC --- The marker should be removed.
[Bug lto/46504] LTO failed on 483.xalancbmk in SPEC CPU 2006
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46504 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2010.11.17 11:43:41 AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2010-11-17 11:43:41 UTC --- Yep, I've seen this as well. And I've caused this issue to pop up again.
[Bug c++/46513] Request: Warning for use of unsafe string handling functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46513 --- Comment #6 from joseph at codesourcery dot com joseph at codesourcery dot com 2010-11-17 11:50:16 UTC --- On Wed, 17 Nov 2010, noloader at gmail dot com wrote: I stand corrected: C1X draft dated 2010-10-04 now includes the bounds checking interfaces. See C1X Draft, http://www.open-std.org/Jtc1/sc22/wg14/www/docs/n1516.pdf at http://www.open-std.org/Jtc1/sc22/wg14/www/projects. So in addition to [nearly ubiquitous] support for strlcpy and friends, we will have strcpy_s and friends. I can't imagine glibc will want to have that set of functions in libc - I expect it will simply omit that optional set of interfaces and not define __STDC_LIB_EXT1__. Maybe someone will write a glibc add-on putting them in a separate library that a handful of people might then use. *Some* of the functions there are useful, but the notion that tmpfile (for example) has security issues requiring tmpfile_s is nonsense. And the main utility of most of those functions is to retrofit security improvements to old code without understanding it. glibc has its own means for such retrofitting (in particular _FORTIFY_SOURCE). In both cases they are really a matter of reducing the risk from certain kinds of bugs rather than fixing them; to fix them, you need actually to understand the code and determine when you should avoid arbitrary limits and allocate as much memory as needed (taking care about overflow when calculating allocation sizes) and when you should impose limits and how you should handle overflow of them (quietly truncating is not generally a good approach); safer interfaces and _FORTIFY_SOURCE should then be used *on top of* proper design and calculation of allocations, to reduce the risk of any remaining bugs, rather than as a substitute for avoiding the possibility of overflow or truncation in the first place. If you wish to enforce a coding standard disallowing certain functions in a particular code base, you are free to use existing GCC features such as #pragma GCC poison and the deprecated attribute. That seems better to me than GCC embedding particular assumptions about a particular set of functions, when everyone will have their own preferences about what functions should be used and whether functions are safe in a given code base depends on how it uses them.
[Bug lto/46505] LTO miscompiled 416.gamess in SPEC CPU 2006
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46505 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2010-11-17 11:50:51 UTC --- Hm, worked for me last time. Re-checking with r166798.
[Bug lto/46506] LTO miscompiled 465.tonto in SPEC CPU 2006
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46506 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2010-11-17 11:51:23 UTC --- Hm, worked for me last time. Re-checking with r166798.
[Bug c/46509] -Wparentheses shouldn't warn about: A || Y foo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46509 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Severity|normal |enhancement
[Bug middle-end/46510] [4.6 Regression] r166812 breaks bootstrap on x86_64-apple-darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46510 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1 Target Milestone|--- |4.6.0 Summary|r166812 breaks bootstrap on |[4.6 Regression] r166812 |x86_64-apple-darwin10 |breaks bootstrap on ||x86_64-apple-darwin10
[Bug middle-end/46515] [4.6 Regression] Many libjava failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46515 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.6.0
[Bug driver/46516] Non-multilib search problem in gcc.c / gfortran error: libgfortran.spec: No such file or directory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46516 --- Comment #12 from joseph at codesourcery dot com joseph at codesourcery dot com 2010-11-17 11:55:29 UTC --- In http://gcc.gnu.org/ml/gcc-patches/2009-09/msg00826.html I discussed issues relating to finding specs in the presence of multilib paths. I hope this - and Nathan Froyd's patch linked from there in particular, which solved the libgomp.spec issue - helps provide a roadmap for resolving the present issue.
[Bug lto/46505] LTO miscompiled 416.gamess in SPEC CPU 2006
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46505 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2010.11.17 11:57:46 Ever Confirmed|0 |1 --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2010-11-17 11:57:46 UTC --- Confirmed.
[Bug testsuite/45429] [4.6 Regression] gcc.dg/vect/no-section-anchors-vect-64.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45429 --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2010-11-17 12:05:28 UTC --- Author: jakub Date: Wed Nov 17 12:05:24 2010 New Revision: 166865 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=166865 Log: PR testsuite/45429 * gcc.dg/vect/no-section-anchors-vect-64.c: New test. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/vect/no-section-anchors-vect-64.c
[Bug lto/46506] LTO miscompiled 465.tonto in SPEC CPU 2006
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46506 --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2010-11-17 12:05:24 UTC --- Tonto works for me.
[Bug c/46509] -Wparentheses shouldn't warn about: A || Y foo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46509 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2010-11-17 12:07:43 UTC --- Agreed, this is a terrible coding standard, I don't think we should try to special case it. It is much better if ()s are added.
[Bug testsuite/45429] [4.6 Regression] gcc.dg/vect/no-section-anchors-vect-64.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45429 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2010-11-17 12:15:48 UTC --- Fixed.
[Bug middle-end/46515] [4.6 Regression] Many libjava failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46515 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added CC||rth at gcc dot gnu.org --- Comment #1 from H.J. Lu hjl.tools at gmail dot com 2010-11-17 12:51:20 UTC --- It is caused by revision 166829: http://gcc.gnu.org/ml/gcc-cvs/2010-11/msg00718.html
[Bug middle-end/46515] [4.6 Regression] Many libjava failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46515 --- Comment #2 from H.J. Lu hjl.tools at gmail dot com 2010-11-17 12:53:39 UTC --- Failures look like spawn [open ...]^M FAIL: InterfaceDispatch -findirect-dispatch execution - source compiled test UNTESTED: InterfaceDispatch -findirect-dispatch output - source compiled test
[Bug middle-end/46515] [4.6 Regression] Many libjava failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46515 --- Comment #3 from H.J. Lu hjl.tools at gmail dot com 2010-11-17 12:54:35 UTC --- It is on Linux/x86-64.
[Bug rtl-optimization/46440] [4.5/4.6 Regression] ICE: in rtl_verify_flow_info, at cfgrtl.c:2165 with -fstack-protector-all -fno-tree-dominator-opts -fno-tree-fre
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46440 --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2010-11-17 13:02:34 UTC --- Author: jakub Date: Wed Nov 17 13:02:31 2010 New Revision: 166867 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=166867 Log: PR rtl-optimization/46440 * combine.c (update_cfg_for_uncondjump): When changing an indirect jump into unconditional jump, remove BARRIERs from bb's footer. * gcc.dg/pr46440.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr46440.c Modified: trunk/gcc/ChangeLog trunk/gcc/combine.c trunk/gcc/testsuite/ChangeLog
[Bug rtl-optimization/46440] [4.5 Regression] ICE: in rtl_verify_flow_info, at cfgrtl.c:2165 with -fstack-protector-all -fno-tree-dominator-opts -fno-tree-fre
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46440 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Known to work||4.6.0 Summary|[4.5/4.6 Regression] ICE: |[4.5 Regression] ICE: in |in rtl_verify_flow_info, at |rtl_verify_flow_info, at |cfgrtl.c:2165 with |cfgrtl.c:2165 with |-fstack-protector-all |-fstack-protector-all |-fno-tree-dominator-opts|-fno-tree-dominator-opts |-fno-tree-fre |-fno-tree-fre Known to fail|4.6.0 | --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2010-11-17 13:03:42 UTC --- Fixed for 4.6 so far.
[Bug target/39064] libiberty md5.h needs uintptr_t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39064 --- Comment #4 from nightstrike nightstrike at gmail dot com 2010-11-17 13:13:44 UTC --- *** Bug 46464 has been marked as a duplicate of this bug. ***
[Bug other/46464] libiberty pointer size assumptions for Win64 incorrect
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46464 nightstrike nightstrike at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #1 from nightstrike nightstrike at gmail dot com 2010-11-17 13:13:44 UTC --- Duplicate of: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39064 *** This bug has been marked as a duplicate of bug 39064 ***
[Bug lto/46506] LTO miscompiled 465.tonto in SPEC CPU 2006
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46506 --- Comment #3 from H.J. Lu hjl.tools at gmail dot com 2010-11-17 13:19:07 UTC --- Created attachment 22429 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22429 The src.alt for 465.tonto Can you try this alternate source for tonto with -O3 -funroll-loops -ffast-math -fwhole-program -flto=jobserver -fuse-linker-plugin
[Bug lto/46506] LTO miscompiled 465.tonto in SPEC CPU 2006
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46506 --- Comment #4 from Richard Guenther rguenth at gcc dot gnu.org 2010-11-17 13:36:03 UTC --- I have different alternate source, calling destroy_ptr_part_ instead. But I can't parse the perl patch, so I'm not 100% sure.
[Bug rtl-optimization/45652] [4.6 Regression] gcc.dg/compat/scalar-by-value-3 FAILs with -O2 -fselective-scheduling2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45652 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added CC||ebotcazou at gcc dot ||gnu.org --- Comment #5 from Eric Botcazou ebotcazou at gcc dot gnu.org 2010-11-17 14:05:45 UTC --- P1 sounds a little overrated, it's a specialized option and an artificial test. Only IA-64 really uses this thing, right?
[Bug rtl-optimization/45652] [4.6 Regression] gcc.dg/compat/scalar-by-value-3 FAILs with -O2 -fselective-scheduling2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45652 --- Comment #6 from Richard Guenther rguenth at gcc dot gnu.org 2010-11-17 14:08:01 UTC --- (In reply to comment #5) P1 sounds a little overrated, it's a specialized option and an artificial test. Only IA-64 really uses this thing, right? All regressions towards the last release on primary or secondary targets are P1 if they do not involve invalid source or checking-only problems.
[Bug rtl-optimization/45652] [4.6 Regression] gcc.dg/compat/scalar-by-value-3 FAILs with -O2 -fselective-scheduling2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45652 --- Comment #7 from Richard Guenther rguenth at gcc dot gnu.org 2010-11-17 14:08:35 UTC --- Btw, the scheduler guys have a fix in the works already.
[Bug fortran/46518] New: internal compiler error: in vinsn_detach, at sel-sched-ir.c:1271
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46518 Summary: internal compiler error: in vinsn_detach, at sel-sched-ir.c:1271 Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: howa...@nitro.med.uc.edu When using the --enable-build-with-cxx bootstrap on x86_64-apple-darwin10 with the patches... http://gcc.gnu.org/ml/gcc-patches/2010-11/msg01323.html http://gcc.gnu.org/ml/gcc-patches/2010-11/msg01803.html a new ICE appears at -m32 for the gfortran.dg/pr42294.f -O testcase. This failure doesn't occur with a normal bootstrap and with the --enable-build-with-cxx bootstrap is of the form... Executing on host: /sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/gcc/testsuite/gfortran/../../gfortran -B/sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/gcc/testsuite/gfortran/../../ -L/sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/x86_64-apple-darwin10.5.0/i386/libgfortran /sw/src/fink.build/gcc46-4.6.0-1000/gcc-4.6-20101116/gcc/testsuite/gfortran.dg/pr42294.f -O -O2 -fselective-scheduling2 -fsel-sched-pipelining -funroll-all-loops -S -m32 -o pr42294.s(timeout = 300) /sw/src/fink.build/gcc46-4.6.0-1000/gcc-4.6-20101116/gcc/testsuite/gfortran.dg/pr42294.f: In function 'orien': /sw/src/fink.build/gcc46-4.6.0-1000/gcc-4.6-20101116/gcc/testsuite/gfortran.dg/pr42294.f:39:0: internal compiler error: in vinsn_detach, at sel-sched-ir.c:1271
[Bug middle-end/46518] internal compiler error: in vinsn_detach, at sel-sched-ir.c:1271
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46518 Alexander Monakov amonakov at gcc dot gnu.org changed: What|Removed |Added CC||amonakov at gcc dot gnu.org --- Comment #1 from Alexander Monakov amonakov at gcc dot gnu.org 2010-11-17 14:51:24 UTC --- Do you know whether this is present on x86_64-linux?
[Bug middle-end/46518] internal compiler error: in vinsn_detach, at sel-sched-ir.c:1271
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46518 --- Comment #2 from Jack Howarth howarth at nitro dot med.uc.edu 2010-11-17 14:52:42 UTC --- Only occurs for -fPIC on x86_64-apple-darwin10. Adding -fno-PIC on darwin suppresses the ICE.
[Bug target/46519] New: Missing vzeroupper
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46519 Summary: Missing vzeroupper Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: hjl.to...@gmail.com CC: ubiz...@gmail.com Created attachment 22430 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22430 A testcase /export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc -B/export/build/gnu/gcc/build-x86_64-linux/gcc/ -O3 -funroll-loops -ffast-math -mavx -Wno-multichar -S bad.c .L531: vmovapd %ymm0, (%rsp) vzeroupper callGet_Token movlToken_Id(%rip), %eax vmovapd (%rsp), %ymm0 cmpl$1, %eax je .L139 cmpl$2, %eax je .L541 L171: vmovsd (%rax), %xmm9 vsubsd 32(%rsp,%rcx,8), %xmm9, %xmm8 leal1(%rdx), %ecx cmpl%ecx, %esi vmovsd %xmm8, (%rax) jg .L543 jmp .L531 .p2align 4,,10 .p2align 3 .L541: leaq80(%rsp), %rsi movq%r12, %rdi callParse_Num_Term missing vzeroupper movl0(%r13), %esi movl80(%rsp), %eax vmovapd (%rsp), %ymm0 cmpl%eax, %esi
[Bug bootstrap/46086] fail to build gcc 4.5.2 on sparc64-portbld-freebsd9.0 - configure: error: cannot compute suffix of object files: cannot compile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46086 --- Comment #12 from Anton Shterenlikht mexas at bristol dot ac.uk 2010-11-17 15:09:20 UTC --- yes, GMP fails 14 tests: http://seis.bris.ac.uk/~mexas/gmp-5.0.1-regression-test.log I submitted a bug report to gmp-bugs. MPFR passes all tests. Sorry, I should've checked before.
[Bug middle-end/46518] internal compiler error: in vinsn_detach, at sel-sched-ir.c:1271
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46518 --- Comment #3 from Jack Howarth howarth at nitro dot med.uc.edu 2010-11-17 15:11:53 UTC --- (In reply to comment #1) Do you know whether this is present on x86_64-linux? I am unable to do a --enable-build-with-cxx bootstrap using... http://gcc.gnu.org/ml/gcc-patches/2010-11/msg01323.html on x86_64 Fedora10. The bootstrap still fails there with... g++ -g -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -o lto1 \ lto/lto-lang.o lto/lto.o lto/lto-object.o attribs.o main.o tree-browser.o libbackend.a ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a -lcloog -lppl_c -lppl -lgmpxx -L/usr/lib -L/usr/lib -L/usr/lib -lmpc -lmpfr -lgmp -rdynamic -ldl -L../zlib -lz ../libcpp/libcpp.a ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a ld: crtbegin.o: No such file: No such file or directory make[3]: *** [lto1] Error 1
[Bug c++/46497] [C++0x] [4.6 Regression] Defaulted vs declared move constructor vs is_convertible
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46497 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Summary|[C++0x] Defaulted vs|[C++0x] [4.6 Regression] |declared move constructor |Defaulted vs declared move |vs is_convertible |constructor vs ||is_convertible --- Comment #5 from Paolo Carlini paolo.carlini at oracle dot com 2010-11-17 15:21:02 UTC --- Barring evidence to the contrary, this is a regression: the testcase in Comment #2 compiles with 4_5-branch.
[Bug middle-end/46518] internal compiler error: in vinsn_detach, at sel-sched-ir.c:1271
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46518 --- Comment #4 from Alexander Monakov amonakov at gcc dot gnu.org 2010-11-17 15:29:33 UTC --- (In reply to comment #2) Only occurs for -fPIC on x86_64-apple-darwin10. Adding -fno-PIC on darwin suppresses the ICE. Is that in relation to bootstrap flags? There's no PIC flags in the original report. The breakage is rather curious. Build-with-CXX should not cause code generation differences. Can you please build normally-bootstrapped compiler from the same source, build the testcase with the two compilers appending -fdump-tree-all -fdump-rtl-all and attach the two series of dumps?
[Bug rtl-optimization/45652] [4.6 Regression] gcc.dg/compat/scalar-by-value-3 FAILs with -O2 -fselective-scheduling2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45652 --- Comment #8 from Eric Botcazou ebotcazou at gcc dot gnu.org 2010-11-17 15:31:36 UTC --- Btw, the scheduler guys have a fix in the works already. Then they should assign the PR to someone to avoid duplicating efforts.
[Bug driver/46516] Non-multilib search problem in gcc.c / gfortran error: libgfortran.spec: No such file or directory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46516 --- Comment #13 from Tobias Burnus burnus at gcc dot gnu.org 2010-11-17 15:32:34 UTC --- Some debugging: While for libgfortran.spec and libgomp.spec the call to gcc.c's find_a_file and thus to for_each_path is the same, the global variable multilib_os_dir is NULL for libgfortran.spec and only later for libgomp.spec (and thus too late) it is ../lib64 It is set in set_multilib_dir, which is too late: main (int argc, char **argv) { ... // Get default setting, OK so far: specs_file = find_a_file (startfile_prefixes, specs, R_OK, true); // This reads the file we want: /* Process DRIVER_SELF_SPECS, adding any new options to the end of the command line. */ for (i = 0; i ARRAY_SIZE (driver_self_specs); i++) do_self_spec (driver_self_specs[i]); // but ../lib64 is only set at: /* Now that we have the switches and the specs, set the subdirectory based on the options. */ set_multilib_dir (); Frankly, I have no idea how to solve this interdependence.
[Bug middle-end/46518] internal compiler error: in vinsn_detach, at sel-sched-ir.c:1271
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46518 --- Comment #5 from Jack Howarth howarth at nitro dot med.uc.edu 2010-11-17 15:33:35 UTC --- (In reply to comment #4) (In reply to comment #2) Only occurs for -fPIC on x86_64-apple-darwin10. Adding -fno-PIC on darwin suppresses the ICE. Is that in relation to bootstrap flags? There's no PIC flags in the original report. Darwin defaults to -fPIC unlike other targets.
[Bug rtl-optimization/45652] [4.6 Regression] gcc.dg/compat/scalar-by-value-3 FAILs with -O2 -fselective-scheduling2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45652 Alexander Monakov amonakov at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |amonakov at gcc dot gnu.org |gnu.org | --- Comment #9 from Alexander Monakov amonakov at gcc dot gnu.org 2010-11-17 15:39:57 UTC --- (In reply to comment #8) Btw, the scheduler guys have a fix in the works already. Then they should assign the PR to someone to avoid duplicating efforts. Sorry. I'm testing the following patch. There's no way to update REG_BASE_VALUE from sel-sched on the fly, because it affects aliasing for multiple MEMs (even off the code motion paths), making computed availability sets inconsistent with new dependencies. diff --git a/gcc/alias.c b/gcc/alias.c index 2e0ac06..e79a780 100644 --- a/gcc/alias.c +++ b/gcc/alias.c @@ -1291,6 +1291,12 @@ record_set (rtx dest, const_rtx set, void *data ATTRIBUTE_UNUSED) reg_seen[regno] = 1; } +rtx +get_reg_base_value (unsigned int regno) +{ + return VEC_index (rtx, reg_base_value, regno); +} + /* If a value is known for REGNO, return it. */ rtx diff --git a/gcc/rtl.h b/gcc/rtl.h index 3e1df2c..22721a2 100644 --- a/gcc/rtl.h +++ b/gcc/rtl.h @@ -2508,6 +2508,7 @@ extern rtx find_base_term (rtx); extern rtx gen_hard_reg_clobber (enum machine_mode, unsigned int); extern rtx get_reg_known_value (unsigned int); extern bool get_reg_known_equiv_p (unsigned int); +extern rtx get_reg_base_value (unsigned int); #ifdef STACK_REGS extern int stack_regs_mentioned (const_rtx insn); diff --git a/gcc/sel-sched.c b/gcc/sel-sched.c index 70e831d..544348c 100644 --- a/gcc/sel-sched.c +++ b/gcc/sel-sched.c @@ -1139,6 +1139,8 @@ init_regs_for_mode (enum machine_mode mode) /* Can't use regs which aren't saved by the prologue. */ || !TEST_HARD_REG_BIT (sel_hrd.regs_ever_used, cur_reg + i) +|| get_reg_base_value (cur_reg + i) #ifdef LEAF_REGISTERS /* We can't use a non-leaf register if we're in a leaf function. */
[Bug middle-end/46518] internal compiler error: in vinsn_detach, at sel-sched-ir.c:1271
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46518 --- Comment #6 from Jack Howarth howarth at nitro dot med.uc.edu 2010-11-17 15:44:38 UTC --- (In reply to comment #4) (In reply to comment #2) Only occurs for -fPIC on x86_64-apple-darwin10. Adding -fno-PIC on darwin suppresses the ICE. Is that in relation to bootstrap flags? There's no PIC flags in the original report. The breakage is rather curious. Build-with-CXX should not cause code generation differences. Can you please build normally-bootstrapped compiler from the same source, build the testcase with the two compilers appending -fdump-tree-all -fdump-rtl-all and attach the two series of dumps? Under x86_64 Fedora 10 using... ../gcc/configure --with-gmp=/usr --with-mpfr=/usr --with-mpc=/usr --prefix=/home/howarth/dist --enable-languages=c,c++,fortran --enable-build-with-cxx --disable-lto --disable-bootstrap I get a slightly different crash (which might not be surprising since the compiler isn't built entirely with -fPIC like on darwin). Executing on host: /home/howarth/work/gcc/testsuite/gfortran/../../gfortran -B/home/howarth/work/gcc/testsuite/gfortran/../../ -L/home/howarth/work/x86_64-unknown-linux-gnu/32/libgfor tran /home/howarth/gcc/gcc/testsuite/gfortran.dg/pr42294.f -O -O2 -fselective-scheduling2 -fsel-sched-pipelining -funroll-all-loops -S -m32 -o pr42294.s(timeout = 300) /home/howarth/gcc/gcc/testsuite/gfortran.dg/pr42294.f: In function 'orien': /home/howarth/gcc/gcc/testsuite/gfortran.dg/pr42294.f:39:0: internal compiler error: Segmentation fault
[Bug lto/46504] LTO failed on 483.xalancbmk in SPEC CPU 2006
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46504 --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2010-11-17 15:47:20 UTC --- Author: rguenth Date: Wed Nov 17 15:47:17 2010 New Revision: 166870 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=166870 Log: 2010-11-17 Richard Guenther rguent...@suse.de PR lto/46504 * gimple.c (gimple_register_canonical_type): Make sure to only make type leaders canonical types. Modified: trunk/gcc/ChangeLog trunk/gcc/gimple.c
[Bug fortran/46520] New: libquadmath: Build also with --enable-languages=c; fails with some cross targets
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46520 Summary: libquadmath: Build also with --enable-languages=c; fails with some cross targets Product: gcc Version: 4.6.0 Status: UNCONFIRMED Keywords: build Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: bur...@gcc.gnu.org Seemingly, libquadmath is also build with --enable-languages=c only; currently, it shouldn't. Possibly solved by: --- gcc/fortran/config-lang.in (revision 166859) +++ gcc/fortran/config-lang.in (working copy) @@ -30 +30 @@ compilers=f951\$(exeext) -target_libs=target-libgfortran +target_libs=target-libquadmath target-libgfortran Additionally, it fails to configure at some link test with --enable-languages=c --target=moxie-elf which is a pure target board. Ian wrote in #gcc: according to antgreen, the libquadmath configure script expects to be able to link an executable
[Bug rtl-optimization/46521] New: ICE: in reset_sched_cycles_in_current_ebb, at sel-sched.c:7092 with -Os -fselective-scheduling2 -fsel-sched-pipelining -fprofile-generate -fno-early-inlining
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46521 Summary: ICE: in reset_sched_cycles_in_current_ebb, at sel-sched.c:7092 with -Os -fselective-scheduling2 -fsel-sched-pipelining -fprofile-generate -fno-early-inlining Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: zso...@seznam.cz Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu Created attachment 22431 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22431 reduced testcase One of testcases for PR45352 fails with -fno-early-inlining: $ gcc -Os -fselective-scheduling2 -fsel-sched-pipelining -fprofile-generate -fno-early-inlining pr45352.i /mnt/svn/gcc-trunk/gcc/testsuite/gcc.dg/pr45352.c: In function 'df_md_alloc': /mnt/svn/gcc-trunk/gcc/testsuite/gcc.dg/pr45352.c:24:1: internal compiler error: in reset_sched_cycles_in_current_ebb, at sel-sched.c:7092 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. The attached more reduced testcase fails the same way: $ gcc -Os -fselective-scheduling2 -fsel-sched-pipelining -fprofile-generate -fno-early-inlining pr46521.c pr46521.c: In function 'df_md_alloc': pr46521.c:17:1: internal compiler error: in reset_sched_cycles_in_current_ebb, at sel-sched.c:7092 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. I verified the testcase doesn't give any warnings with -Wall -W. Tested revisions: r166795 - crash 4.5 r166509 - crash 4.4 r166509 - crash
[Bug lto/46504] LTO failed on 483.xalancbmk in SPEC CPU 2006
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46504 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2010-11-17 15:57:29 UTC --- Fixed.
[Bug rtl-optimization/46522] New: ICE: in reset_sched_cycles_in_current_ebb, at sel-sched.c:7092 with -O3 -fsel-sched-pipelining -fselective-scheduling2 -funroll-loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46522 Summary: ICE: in reset_sched_cycles_in_current_ebb, at sel-sched.c:7092 with -O3 -fsel-sched-pipelining -fselective-scheduling2 -funroll-loops Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: zso...@seznam.cz Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu Created attachment 22432 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22432 reduced testcase (originally PR45352 comment #19) I am sorry for the amount of compiler flags, removing any of them causes the ICE to disappear. Even manual partial inlining, unrolling, loop unswitching, ... either removes the ICE or doesn't allow me to remove further flags. Flags are either: -O3 -fkeep-inline-functions -fsel-sched-pipelining -fselective-scheduling2 -funroll-loops or -O2 -fkeep-inline-functions -fsel-sched-pipelining -fselective-scheduling2 -funroll-loops -funswitch-loops or -O1 -fcse-follow-jumps -fkeep-inline-functions -fpartial-inlining -freorder-blocks -frerun-cse-after-loop -fschedule-insns2 -fsel-sched-pipelining -fselective-scheduling2 -funroll-loops -funswitch-loops Compiler output: $ gcc -O3 -fkeep-inline-functions -fsel-sched-pipelining -fselective-scheduling2 -funroll-loops pr46522.c pr46522.c: In function 'foo2': pr46522.c:30:1: internal compiler error: in reset_sched_cycles_in_current_ebb, at sel-sched.c:7092 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. Tested revisions (for the -O1 case): r166795 - crash r165699 - OK 4.5 - doesn't know -fpartial-inlining
[Bug c/20385] Lame parse error message for undefined type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20385 --- Comment #9 from Paolo Bonzini bonzini at gnu dot org 2010-11-17 16:14:32 UTC --- Another case in which we still do not detect the unsigned type is after declspecs: typedef uintt16_t pid_t; extern uintt16_t x; I think that until this is fixed, there are still enough bad cases that it's not worth putting it into the release notes.
[Bug rtl-optimization/45352] ICE: in reset_sched_cycles_in_current_ebb, at sel-sched.c:7058
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45352 Zdenek Sojka zsojka at seznam dot cz changed: What|Removed |Added Attachment #22334|0 |1 is obsolete|| --- Comment #20 from Zdenek Sojka zsojka at seznam dot cz 2010-11-17 16:15:34 UTC --- Comment on attachment 22334 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22334 testcase failing in r166433 Opened PR46521 and PR46522 for the new two testcases. This one wasn't really reduced anyway. I also verified the new testcases don't give any warning with -Wall -Wextra. I hope this will make the situation more clear and allow this PR to be closed.
[Bug c++/46497] [C++0x] Defaulted vs declared move constructor vs is_convertible
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46497 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Summary|[C++0x] [4.6 Regression]|[C++0x] Defaulted vs |Defaulted vs declared move |declared move constructor |constructor vs |vs is_convertible |is_convertible | --- Comment #6 from Jason Merrill jason at gcc dot gnu.org 2010-11-17 16:15:44 UTC --- The difference between the user-written and =default versions is one of delayed vs. immediate failure. With a defaulted constructor, at declaration time we perform overload resolution and determine that we can't move 'first', so the pairconst move_only move constructor is deleted. We can't do that for a user-written constructor, so we assume that it's OK, and give an error later when we actually try to instantiate the move constructor. So =default makes the ill-formedness available to SFINAE (pairconst move_only doesn't look move-constructible), whereas an explicitly written constructor does not (it looks move-constructible but moving it causes an error). In 4.5, move_only has an implicitly-declared copy constructor, so it is not a move-only type. Explicitly deleting the copy constructor produces the expected errors.
[Bug middle-end/46510] [4.6 Regression] r166812 breaks bootstrap on x86_64-apple-darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46510 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2010.11.17 16:21:39 Ever Confirmed|0 |1 --- Comment #5 from Jan Hubicka hubicka at gcc dot gnu.org 2010-11-17 16:21:39 UTC --- Can you, please, try if the following works? Index: tree-emutls.c === --- tree-emutls.c (revision 166864) +++ tree-emutls.c (working copy) @@ -324,7 +324,8 @@ new_emutls_decl (tree decl) record_references_in_initializer (to, false); } - varpool_finalize_decl (to); + if (!DECL_EXTERNAL (to)) +varpool_finalize_decl (to); return to; } We should not finalize external vars.
[Bug middle-end/46518] internal compiler error: in vinsn_detach, at sel-sched-ir.c:1271
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46518 --- Comment #7 from Jack Howarth howarth at nitro dot med.uc.edu 2010-11-17 16:22:20 UTC --- Under x86_64 Fedora, when built with... ../gcc/configure --with-gmp=/usr --with-mpfr=/usr --with-mpc=/usr --prefix=/home/howarth/dist --enable-languages=c,c++,fortran --enable-build-with-cxx --disable-lto I get failure... Executing on host: /home/howarth/work/gcc/testsuite/gfortran/../../gfortran -B/home/howarth/work/gcc/testsuite/gfortran/../../ -L/home/howarth/work/x86_64-unknown-linux-gnu/32/libgfor tran /home/howarth/gcc/gcc/testsuite/gfortran.dg/pr42294.f -O -O2 -fselective-scheduling2 -fsel-sched-pipelining -funroll-all-loops -S -m32 -o pr42294.s(timeout = 300) /home/howarth/gcc/gcc/testsuite/gfortran.dg/pr42294.f: In function 'orien': /home/howarth/gcc/gcc/testsuite/gfortran.dg/pr42294.f:39:0: internal compiler error: Segmentation fault This backtraces as... gdb /home/howarth/work/gcc/testsuite/gfortran/../../f951 GNU gdb Fedora (6.8-32.fc10) Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as x86_64-redhat-linux-gnu... (gdb) r /home/howarth/gcc/gcc/testsuite/gfortran.dg/pr42294.f -ffixed-form -quiet -dumpbase pr42294.f -m32 -mtune=generic -march=x86-64 -auxbase-strip pr42294.s -O -O2 -version -fselective-scheduling2 -fsel-sched-pipelining -funroll-all-loops -o pr42294.s -fintrinsic-modules-path finclude Starting program: /home/howarth/work/gcc/f951 /home/howarth/gcc/gcc/testsuite/gfortran.dg/pr42294.f -ffixed-form -quiet -dumpbase pr42294.f -m32 -mtune=generic -march=x86-64 -auxbase-strip pr42294.s -O -O2 -version -fselective-scheduling2 -fsel-sched-pipelining -funroll-all-loops -o pr42294.s -fintrinsic-modules-path finclude GNU Fortran (GCC) version 4.6.0 20101117 (experimental) (x86_64-unknown-linux-gnu) compiled by GNU C version 4.6.0 20101117 (experimental), GMP version 4.2.2, MPFR version 2.3.2, MPC version 0.8 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 GNU Fortran (GCC) version 4.6.0 20101117 (experimental) (x86_64-unknown-linux-gnu) compiled by GNU C version 4.6.0 20101117 (experimental), GMP version 4.2.2, MPFR version 2.3.2, MPC version 0.8 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Program received signal SIGSEGV, Segmentation fault. vinsn_detach (vi=0x0) at ../../gcc/gcc/sel-sched-ir.c:1271 1271 gcc_assert (VINSN_COUNT (vi) 0); Current language: auto; currently c++ Missing separate debuginfos, use: debuginfo-install cloog-ppl-0.15.8-2f10.x86_64 gmp-4.2.2-8.fc10.x86_64 libgcc-4.3.2-7.x86_64 libmpc-0.8-3.fc10.x86_64 libstdc++-4.3.2-7.x86_64 mpfr-2.3.2-1.fc10.x86_64 ppl-0.10.2-6.fc10.x86_64 (gdb) bt #0 vinsn_detach (vi=0x0) at ../../gcc/gcc/sel-sched-ir.c:1271 #1 0x00823e6c in clear_expr (expr=0x7fffdcd0) at ../../gcc/gcc/sel-sched-ir.c:1864 #2 0x00839bc6 in schedule_expr_on_boundary (bnd=value optimized out, expr_vliw=0x15173c0, seqno=-1) at ../../gcc/gcc/sel-sched.c:5435 #3 0x0083aa1c in fill_insns (scheduled_insns_tailpp=Unhandled dwarf expression opcode 0xf2 ) at ../../gcc/gcc/sel-sched.c:5576 #4 schedule_on_fences (scheduled_insns_tailpp=Unhandled dwarf expression opcode 0xf2 ) at ../../gcc/gcc/sel-sched.c:7298 #5 sel_sched_region_2 (orig_max_seqno=51) at ../../gcc/gcc/sel-sched.c:7432 #6 0x0083e30f in sel_sched_region_1 () at ../../gcc/gcc/sel-sched.c:7476 #7 sel_sched_region (rgn=value optimized out) at ../../gcc/gcc/sel-sched.c:7575 #8 0x014cd7e0 in ?? () #9 0x01f8 in ?? () #10 0x0100 in ?? () #11 0x014cd7f0 in ?? () #12 0x0200 in ?? () #13 0x003099a7bfc7 in _int_realloc (av=0x101010101010101, oldmem=0x1, bytes=value optimized out) at malloc.c:5083 #14 0x003099a7cfbe in __libc_realloc (oldmem=0x14bfd90, bytes=504) at malloc.c:3708 #15 0x005b8137 in bitmap_copy (to=0x12f6001, from=0x1f8) at ../../gcc/gcc/bitmap.c:517 #16 0x0034 in ?? () #17 0xfff8 in ?? () #18 0x in ?? ()
[Bug driver/46516] Non-multilib search problem in gcc.c / gfortran error: libgfortran.spec: No such file or directory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46516 --- Comment #14 from Tobias Burnus burnus at gcc dot gnu.org 2010-11-17 16:25:56 UTC --- Suggested solution from Joseph on #gcc: - get rid of the spec file (hooray!) - Add a configure test. One needs to make sure that both the compiler supports __float128 and the libgcc library support it. If I read the files correctly, the latter is set via libgcc/config.host There is also the adjunct file gcc/config.gcc I am not 100% sure whether I understood the syntax; however, there is t-softfp in libgcc and soft-fp/t-softfp in gcc; I do not yet quite understand how they relate and whether that's the correct information; in any case, it is not sufficient as t-softfp is also present for PowerPC, which has a hardware 128-bit FP type.
[Bug tree-optimization/46523] New: [4.6 Regression] ICE: error: inlined_to pointer set for noninline callers, multiple inline callers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46523 Summary: [4.6 Regression] ICE: error: inlined_to pointer set for noninline callers, multiple inline callers Product: gcc Version: 4.6.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: rgue...@gcc.gnu.org CC: hubi...@gcc.gnu.org Target: i?86-*-linux kdevelop4 fails to build with ./cc1plus -quiet -m32 cppduchain.ii -O2 -std=c++0x /usr/src/packages/BUILD/kdevelop-4.1.0/languages/cpp/cppduchain/cppduchain.cpp:839:1: error: inlined_to pointer set for noninline callers /usr/src/packages/BUILD/kdevelop-4.1.0/languages/cpp/cppduchain/cppduchain.cpp:839:1: error: multiple inline callers virtual KDevelop::AbstractType::Ptr Cpp::shortenTypeForViewing(KDevelop::AbstractType::Ptr)::ShortenAliasExchanger::exchange(const Ptr)/3542(2949) @0x71510b00 (asm: _ZZN3Cpp21shortenTypeForViewingE7TypePtrIN8KDevelop12AbstractTypeEEEN21ShortenAliasExchanger8exchangeERKS3_) (inline copy in KDevelop::AbstractType::Ptr Cpp::shortenTypeForViewing(KDevelop::AbstractType::Ptr)/3553) availability:local analyzed 162 time, 17 benefit (175 after inlining) 212 size, 11 benefit (270 after inlining) 36 bytes stack usage reachable body local finalized inlinable called by: virtual KDevelop::AbstractType::Ptr Cpp::shortenTypeForViewing(KDevelop::AbstractType::Ptr)::ShortenAliasExchanger::exchange(const Ptr)/3542 (0.59 per call) (indirect_inlining) virtual KDevelop::AbstractType::Ptr Cpp::shortenTypeForViewing(KDevelop::AbstractType::Ptr)::ShortenAliasExchanger::_ZZN3Cpp21shortenTypeForViewingE7TypePtrIN8KDevelop12AbstractTypeEEEN21ShortenAliasExchanger8exchangeERKS3_.constprop.103(const Ptr)/112 (0.59 per call) (inlined) (can throw external) calls: virtual KDevelop::AbstractType::Ptr Cpp::shortenTypeForViewing(KDevelop::AbstractType::Ptr)::ShortenAliasExchanger::exchange(const Ptr)/3542 (indirect_inlining) (0.59 per call) TypePtrT::~TypePtr() [with T = KDevelop::AbstractType]/2383 TypePtrT::~TypePtr() [with T = KDevelop::TypeAliasType]/4390 TypePtrT::~TypePtr() [with T = KDevelop::AbstractType]/2383 QString::~QString()/537 QString::~QString()/537 QString::~QString()/537 QString::~QString()/537 TypePtrT::~TypePtr() [with T = KDevelop::AbstractType]/2383 TypePtrT::~TypePtr() [with T = KDevelop::AbstractType]/2383 (0.41 per call) (can throw external) TypePtrT::~TypePtr() [with T = KDevelop::TypeAliasType]/5307 (inlined) (0.41 per call) TypePtrT::~TypePtr() [with T = KDevelop::AbstractType]/2383 (0.17 per call) TypePtrT::~TypePtr() [with T = KDevelop::AbstractType]/2383 (0.17 per call) void KDevelop::AbstractType::setModifiers(quint64)/5473 (0.17 per call) quint64 KDevelop::AbstractType::modifiers() const/5425 (0.17 per call) quint64 KDevelop::AbstractType::modifiers() const/5425 (0.17 per call) QString::~QString()/4859 (inlined) (0.10 per call) QString::~QString()/4375 (inlined) (0.10 per call) QString::~QString()/4373 (inlined) (0.10 per call) QString::~QString()/4378 (inlined) (0.10 per call) int Cpp::reservedIdentifierCount(QString)/3541 (0.07 per call) int Cpp::reservedIdentifierCount(QString)/3541 (0.07 per call) int QString::count(QChar, Qt::CaseSensitivity) const/5472 (0.24 per call) QChar::QChar(char)/5471 (0.24 per call) int QString::count(QChar, Qt::CaseSensitivity) const/5472 (0.24 per call) QChar::QChar(char)/5471 (0.24 per call) TypePtrT::~TypePtr() [with T = KDevelop::AbstractType]/2383 (0.35 per call) KDevelop::AbstractType::Ptr KDevelop::TypeAliasType::type() const/5435 (0.35 per call) TypePtrU TypePtrT::cast(U*) const [with U = KDevelop::TypeAliasType, T = KDevelop::AbstractType]/141 (inlined) (0.41 per call) References: Refering this function: has 6 outgoing edges for indirect calls. /usr/src/packages/BUILD/kdevelop-4.1.0/languages/cpp/cppduchain/cppduchain.cpp:839:1: internal compiler error: verify_cgraph_node failed Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions.
[Bug tree-optimization/46523] [4.6 Regression] ICE: error: inlined_to pointer set for noninline callers, multiple inline callers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46523 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.6.0 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2010-11-17 16:28:57 UTC --- Reducing.
[Bug middle-end/46510] [4.6 Regression] r166812 breaks bootstrap on x86_64-apple-darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46510 --- Comment #6 from Jack Howarth howarth at nitro dot med.uc.edu 2010-11-17 16:34:33 UTC --- (In reply to comment #5) Can you, please, try if the following works? Index: tree-emutls.c === --- tree-emutls.c (revision 166864) +++ tree-emutls.c (working copy) @@ -324,7 +324,8 @@ new_emutls_decl (tree decl) record_references_in_initializer (to, false); } - varpool_finalize_decl (to); + if (!DECL_EXTERNAL (to)) +varpool_finalize_decl (to); return to; } We should not finalize external vars. Converts the ICE to a segfault... libtool: compile: /sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/./gcc/xgcc -B/sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/./gcc/ -B/sw/lib/gcc4.6/x86_64-apple-darwin10.5.0/bin/ -B/sw/lib/gcc4.6/x86_64-apple-darwin10.5.0/lib/ -isystem /sw/lib/gcc4.6/x86_64-apple-darwin10.5.0/include -isystem /sw/lib/gcc4.6/x86_64-apple-darwin10.5.0/sys-include -DHAVE_CONFIG_H -I. -I../../../gcc-4.6-20101117/libgomp -I../../../gcc-4.6-20101117/libgomp/config/bsd -I../../../gcc-4.6-20101117/libgomp/config/posix -I../../../gcc-4.6-20101117/libgomp -Wall -pthread -Werror -g -O2 -MT loop.lo -MD -MP -MF .deps/loop.Tpo -c ../../../gcc-4.6-20101117/libgomp/loop.c -fno-common -DPIC -o .libs/loop.o ../../../gcc-4.6-20101117/libgomp/barrier.c: In function 'GOMP_barrier': ../../../gcc-4.6-20101117/libgomp/barrier.c:41:1: internal compiler error: Segmentation fault
[Bug middle-end/46518] internal compiler error: in vinsn_detach, at sel-sched-ir.c:1271
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46518 --- Comment #8 from Jack Howarth howarth at nitro dot med.uc.edu 2010-11-17 16:37:14 UTC --- Backtraces as... gdb /sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/./gcc/cc1 ... (gdb) r -quiet -v -I . -I ../../../gcc-4.6-20101117/libgomp -I ../../../gcc-4.6-20101117/libgomp/config/bsd -I ../../../gcc-4.6-20101117/libgomp/config/posix -I ../../../gcc-4.6-20101117/libgomp -iprefix /sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/gcc/../lib/gcc/x86_64-apple-darwin10.5.0/4.6.0/ -isystem /sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/./gcc/include -isystem /sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/./gcc/include-fixed -MD .libs/barrier.d -MF .deps/barrier.Tpo -MP -MT barrier.lo -D__DYNAMIC__ -D_REENTRANT -D HAVE_CONFIG_H -D PIC -isystem /sw/lib/gcc4.6/x86_64-apple-darwin10.5.0/include -isystem /sw/lib/gcc4.6/x86_64-apple-darwin10.5.0/sys-include ../../../gcc-4.6-20101117/libgomp/barrier.c -fPIC -feliminate-unused-debug-symbols -quiet -dumpbase barrier.c -mmacosx-version-min=10.6.5 -mtune=generic -auxbase-strip .libs/barrier.o -g -O2 -Wall -Werror -version -fno-common -o /var/tmp//cckhMI20.s ... Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x 0x0001009e08b2 in gen_emutls_addr (decl=0x14340a8c0, d=0x7fff5fbfe650) at ../../gcc-4.6-20101117/gcc/tree-emutls.c:418 418 cdecl = cvar-decl; (gdb) bt #0 0x0001009e08b2 in gen_emutls_addr (decl=0x14340a8c0, d=0x7fff5fbfe650) at ../../gcc-4.6-20101117/gcc/tree-emutls.c:418 #1 0x0001009e1181 in lower_emutls_1 (ptr=0x1434d86a8, walk_subtrees=0x7fff5fbfdd9c, cb_data=0x7fff5fbfe5a0) at ../../gcc-4.6-20101117/gcc/tree-emutls.c:527 #2 0x000100c29101 in walk_tree_1 (tp=0x1434d86a8, func=0x1009e0d5e lower_emutls_1, data=0x7fff5fbfe5a0, pset=0x0, lh=0) at ../../gcc-4.6-20101117/gcc/tree.c:10241 #3 0x000100c2b9b5 in walk_tree_1 (tp=0x1434d86e8, func=0x1009e0d5e lower_emutls_1, data=0x7fff5fbfe5a0, pset=0x0, lh=0) at ../../gcc-4.6-20101117/gcc/tree.c:10490 #4 0x000100c2b9b5 in walk_tree_1 (tp=0x1434ff688, func=0x1009e0d5e lower_emutls_1, data=0x7fff5fbfe5a0, pset=0x0, lh=0) at ../../gcc-4.6-20101117/gcc/tree.c:10490 #5 0x0001006960b8 in walk_gimple_op (stmt=0x1434ff640, callback_op=0x1009e0d5e lower_emutls_1, wi=0x7fff5fbfe5a0) at ../../gcc-4.6-20101117/gcc/gimple.c:1361 #6 0x0001009e1468 in lower_emutls_stmt (stmt=0x1434ff640, d=0x7fff5fbfe650) at ../../gcc-4.6-20101117/gcc/tree-emutls.c:557 #7 0x0001009e1a1f in lower_emutls_function_body (node=0x1434d7dc0) at ../../gcc-4.6-20101117/gcc/tree-emutls.c:663 #8 0x0001009e2318 in ipa_lower_emutls () at ../../gcc-4.6-20101117/gcc/tree-emutls.c:765 #9 0x00010084eed2 in execute_one_pass (pass=0x1010ab3a0) at ../../gcc-4.6-20101117/gcc/passes.c:1564 #10 0x00010084fee3 in execute_ipa_pass_list (pass=0x1010ab3a0) at ../../gcc-4.6-20101117/gcc/passes.c:1931 #11 0x000100cdf555 in ipa_passes () at ../../gcc-4.6-20101117/gcc/cgraphunit.c:1696 #12 0x000100cdf738 in cgraph_optimize () at ../../gcc-4.6-20101117/gcc/cgraphunit.c:1765 #13 0x000100cdcad5 in cgraph_finalize_compilation_unit () at ../../gcc-4.6-20101117/gcc/cgraphunit.c:1017 #14 0x000100030c41 in c_write_global_declarations () at ../../gcc-4.6-20101117/gcc/c-decl.c:9837 #15 0x000100969368 in compile_file () at ../../gcc-4.6-20101117/gcc/toplev.c:882 #16 0x00010096c470 in do_compile () at ../../gcc-4.6-20101117/gcc/toplev.c:2313 #17 0x00010096c5b8 in toplev_main (argc=54, argv=0x7fff5fbfe950) at ../../gcc-4.6-20101117/gcc/toplev.c:2374 #18 0x000100115548 in main (argc=54, argv=0x7fff5fbfe950) at ../../gcc-4.6-20101117/gcc/main.c:36
[Bug middle-end/46518] internal compiler error: in vinsn_detach, at sel-sched-ir.c:1271
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46518 --- Comment #9 from Jack Howarth howarth at nitro dot med.uc.edu 2010-11-17 16:38:11 UTC --- sorry...comment 8 ended up in the wrong PR
[Bug middle-end/46510] [4.6 Regression] r166812 breaks bootstrap on x86_64-apple-darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46510 --- Comment #7 from Jack Howarth howarth at nitro dot med.uc.edu 2010-11-17 16:38:47 UTC --- Backtraces as... gdb /sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/./gcc/cc1 ... (gdb) r -quiet -v -I . -I ../../../gcc-4.6-20101117/libgomp -I ../../../gcc-4.6-20101117/libgomp/config/bsd -I ../../../gcc-4.6-20101117/libgomp/config/posix -I ../../../gcc-4.6-20101117/libgomp -iprefix /sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/gcc/../lib/gcc/x86_64-apple-darwin10.5.0/4.6.0/ -isystem /sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/./gcc/include -isystem /sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/./gcc/include-fixed -MD .libs/barrier.d -MF .deps/barrier.Tpo -MP -MT barrier.lo -D__DYNAMIC__ -D_REENTRANT -D HAVE_CONFIG_H -D PIC -isystem /sw/lib/gcc4.6/x86_64-apple-darwin10.5.0/include -isystem /sw/lib/gcc4.6/x86_64-apple-darwin10.5.0/sys-include ../../../gcc-4.6-20101117/libgomp/barrier.c -fPIC -feliminate-unused-debug-symbols -quiet -dumpbase barrier.c -mmacosx-version-min=10.6.5 -mtune=generic -auxbase-strip .libs/barrier.o -g -O2 -Wall -Werror -version -fno-common -o /var/tmp//cckhMI20.s ... Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x 0x0001009e08b2 in gen_emutls_addr (decl=0x14340a8c0, d=0x7fff5fbfe650) at ../../gcc-4.6-20101117/gcc/tree-emutls.c:418 418 cdecl = cvar-decl; (gdb) bt #0 0x0001009e08b2 in gen_emutls_addr (decl=0x14340a8c0, d=0x7fff5fbfe650) at ../../gcc-4.6-20101117/gcc/tree-emutls.c:418 #1 0x0001009e1181 in lower_emutls_1 (ptr=0x1434d86a8, walk_subtrees=0x7fff5fbfdd9c, cb_data=0x7fff5fbfe5a0) at ../../gcc-4.6-20101117/gcc/tree-emutls.c:527 #2 0x000100c29101 in walk_tree_1 (tp=0x1434d86a8, func=0x1009e0d5e lower_emutls_1, data=0x7fff5fbfe5a0, pset=0x0, lh=0) at ../../gcc-4.6-20101117/gcc/tree.c:10241 #3 0x000100c2b9b5 in walk_tree_1 (tp=0x1434d86e8, func=0x1009e0d5e lower_emutls_1, data=0x7fff5fbfe5a0, pset=0x0, lh=0) at ../../gcc-4.6-20101117/gcc/tree.c:10490 #4 0x000100c2b9b5 in walk_tree_1 (tp=0x1434ff688, func=0x1009e0d5e lower_emutls_1, data=0x7fff5fbfe5a0, pset=0x0, lh=0) at ../../gcc-4.6-20101117/gcc/tree.c:10490 #5 0x0001006960b8 in walk_gimple_op (stmt=0x1434ff640, callback_op=0x1009e0d5e lower_emutls_1, wi=0x7fff5fbfe5a0) at ../../gcc-4.6-20101117/gcc/gimple.c:1361 #6 0x0001009e1468 in lower_emutls_stmt (stmt=0x1434ff640, d=0x7fff5fbfe650) at ../../gcc-4.6-20101117/gcc/tree-emutls.c:557 #7 0x0001009e1a1f in lower_emutls_function_body (node=0x1434d7dc0) at ../../gcc-4.6-20101117/gcc/tree-emutls.c:663 #8 0x0001009e2318 in ipa_lower_emutls () at ../../gcc-4.6-20101117/gcc/tree-emutls.c:765 #9 0x00010084eed2 in execute_one_pass (pass=0x1010ab3a0) at ../../gcc-4.6-20101117/gcc/passes.c:1564 #10 0x00010084fee3 in execute_ipa_pass_list (pass=0x1010ab3a0) at ../../gcc-4.6-20101117/gcc/passes.c:1931 #11 0x000100cdf555 in ipa_passes () at ../../gcc-4.6-20101117/gcc/cgraphunit.c:1696 #12 0x000100cdf738 in cgraph_optimize () at ../../gcc-4.6-20101117/gcc/cgraphunit.c:1765 #13 0x000100cdcad5 in cgraph_finalize_compilation_unit () at ../../gcc-4.6-20101117/gcc/cgraphunit.c:1017 #14 0x000100030c41 in c_write_global_declarations () at ../../gcc-4.6-20101117/gcc/c-decl.c:9837 #15 0x000100969368 in compile_file () at ../../gcc-4.6-20101117/gcc/toplev.c:882 #16 0x00010096c470 in do_compile () at ../../gcc-4.6-20101117/gcc/toplev.c:2313 #17 0x00010096c5b8 in toplev_main (argc=54, argv=0x7fff5fbfe950) at ../../gcc-4.6-20101117/gcc/toplev.c:2374 #18 0x000100115548 in main (argc=54, argv=0x7fff5fbfe950) at ../../gcc-4.6-20101117/gcc/main.c:36
[Bug c++/46269] [trans-mem] internal compiler error in expand_block_tm of trans-mem.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46269 Aldy Hernandez aldyh at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #7 from Aldy Hernandez aldyh at gcc dot gnu.org 2010-11-17 16:43:02 UTC --- Fixed on branch in aforementioned threads.
[Bug c++/46497] [C++0x] Defaulted vs declared move constructor vs is_convertible
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46497 --- Comment #7 from Paolo Carlini paolo.carlini at oracle dot com 2010-11-17 16:44:21 UTC --- Ok, I'm still digesting all of this (and in the meanwhile we also realized that likely we have problems in the specs of std::is_convertible itself, in the library). Something still puzzling me is that, if I use the user-defined move constructor, I *cannot* trigger errors, *ever*. Is it possible that we have an accepts-invalid lurking somewhere?
[Bug rtl-optimization/45352] ICE: in reset_sched_cycles_in_current_ebb, at sel-sched.c:7058
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45352 --- Comment #21 from Andrey Belevantsev abel at gcc dot gnu.org 2010-11-17 16:47:00 UTC --- (In reply to comment #20) Comment on attachment 22334 [details] testcase failing in r166433 Opened PR46521 and PR46522 for the new two testcases. This one wasn't really reduced anyway. I also verified the new testcases don't give any warning with -Wall -Wextra. I hope this will make the situation more clear and allow this PR to be closed. I'm looking at this testcase now, it is not too big. The problem seems indeed be a bit different from other test cases. I don't yet have a solution.
[Bug bootstrap/41337] [LTO] Parallel build failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41337 Ralf Wildenhues rwild at gcc dot gnu.org changed: What|Removed |Added CC||rwild at gcc dot gnu.org --- Comment #3 from Ralf Wildenhues rwild at gcc dot gnu.org 2010-11-17 16:52:03 UTC --- If you encounter parallel build failures, please post exact revision that was built, configure command line, build system type, number of processors on the box, N argument in 'make -jN', and ideally also the likelihood (in precent) that the build fails, if it is not deterministic. Please also post the last 300 or so lines of build output, and maybe check whether it always fails in the same spot. It is not too hard to pinpoint parallel build failures but only if there is enough data available.
[Bug target/46524] New: Code size regression due to not reusing immediate operands of moves
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46524 Summary: Code size regression due to not reusing immediate operands of moves Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: hubi...@gcc.gnu.org Created attachment 22433 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22433 preprocessed testcase this is another CSiBE module. The testcase is storing a lot of zeros and ones into many places. GCC 4.3 keep 0 in ebp and does: f29: f3 0f 5c 84 24 e8 00subss 0xe8(%rsp),%xmm0 f30: 00 00 f32: 8b 84 24 0c 01 00 00mov0x10c(%rsp),%eax f39: c7 84 24 80 00 00 00movl $0x3f80,0x80(%rsp) f40: 00 00 80 3f f44: 89 ac 24 84 00 00 00mov%ebp,0x84(%rsp) f4b: 89 ac 24 88 00 00 00mov%ebp,0x88(%rsp) f52: 89 ac 24 8c 00 00 00mov%ebp,0x8c(%rsp) f59: 89 44 24 40 mov%eax,0x40(%rsp) f5d: 89 44 24 54 mov%eax,0x54(%rsp) f61: 89 ac 24 90 00 00 00mov%ebp,0x90(%rsp) f68: c7 84 24 94 00 00 00movl $0x3f80,0x94(%rsp) f6f: 00 00 80 3f f73: 89 ac 24 98 00 00 00mov%ebp,0x98(%rsp) f7a: 89 ac 24 9c 00 00 00mov%ebp,0x9c(%rsp) f81: f3 0f 59 05 00 00 00mulss 0x0(%rip),%xmm0# f89 main+0xf89 f88: 00 f89: 89 ac 24 a0 00 00 00mov%ebp,0xa0(%rsp) f90: 89 ac 24 a4 00 00 00mov%ebp,0xa4(%rsp) f97: c7 84 24 a8 00 00 00movl $0x3f80,0xa8(%rsp) f9e: 00 00 80 3f fa2: 89 ac 24 ac 00 00 00mov%ebp,0xac(%rsp) fa9: 89 ac 24 b0 00 00 00mov%ebp,0xb0(%rsp) fb0: 89 ac 24 b4 00 00 00mov%ebp,0xb4(%rsp) fb7: 89 ac 24 b8 00 00 00mov%ebp,0xb8(%rsp) fbe: c7 84 24 bc 00 00 00movl $0x3f80,0xbc(%rsp) fc5: 00 00 80 3f fc9: 89 6c 24 44 mov%ebp,0x44(%rsp) fcd: 89 6c 24 48 mov%ebp,0x48(%rsp) fd1: 89 6c 24 4c mov%ebp,0x4c(%rsp) fd5: 89 6c 24 50 mov%ebp,0x50(%rsp) fd9: 89 6c 24 58 mov%ebp,0x58(%rsp) fdd: 89 6c 24 5c mov%ebp,0x5c(%rsp) fe1: 89 6c 24 60 mov%ebp,0x60(%rsp) fe5: 89 6c 24 64 mov%ebp,0x64(%rsp) fe9: f3 0f 11 44 24 68 movss %xmm0,0x68(%rsp) fef: 89 6c 24 6c mov%ebp,0x6c(%rsp) ff3: 89 6c 24 70 mov%ebp,0x70(%rsp) ff7: 89 6c 24 74 mov%ebp,0x74(%rsp) ffb: 89 6c 24 78 mov%ebp,0x78(%rsp) fff: c7 44 24 7c 00 00 80movl $0x3f80,0x7c(%rsp) 1006: 3f Mainline uses stores: 13a1: f3 0f 5c 8c 24 dc 00subss 0xdc(%rsp),%xmm1 13a8: 00 00 13aa: 49 03 44 24 40 add0x40(%r12),%rax 13af: f3 0f 11 40 2c movss %xmm0,0x2c(%rax) 13b4: c7 40 20 00 00 00 00movl $0x0,0x20(%rax) 13bb: c7 40 24 00 00 00 00movl $0x0,0x24(%rax) 13c2: c7 40 28 00 00 00 00movl $0x0,0x28(%rax) 13c9: 8b 84 24 f8 00 00 00mov0xf8(%rsp),%eax 13d0: f3 0f 11 44 24 40 movss %xmm0,0x40(%rsp) 13d6: f3 0f 59 0d 00 00 00mulss 0x0(%rip),%xmm1# 13de main+0x13de 13dd: 00 13de: f3 0f 11 44 24 54 movss %xmm0,0x54(%rsp) 13e4: f3 0f 11 44 24 68 movss %xmm0,0x68(%rsp) 13ea: c7 44 24 44 00 00 00movl $0x0,0x44(%rsp) 13f1: 00 13f2: 89 84 24 80 00 00 00mov%eax,0x80(%rsp) 13f9: f3 0f 11 44 24 7c movss %xmm0,0x7c(%rsp) 13ff: 89 84 24 94 00 00 00mov%eax,0x94(%rsp) 1406: c7 44 24 48 00 00 00movl $0x0,0x48(%rsp) 140d: 00 140e: c7 44 24 4c 00 00 00movl $0x0,0x4c(%rsp) 1415: 00 1416: c7 44 24 50 00 00 00movl $0x0,0x50(%rsp) 141d: 00 141e: c7 44 24 58 00 00 00movl $0x0,0x58(%rsp) 1425: 00 1426: c7 44 24 5c 00 00 00movl $0x0,0x5c(%rsp) 142d: 00 142e: c7 44 24 60 00 00 00movl $0x0,0x60(%rsp) 1435: 00 1436: c7 44 24 64 00 00 00movl $0x0,0x64(%rsp) 143d: 00 143e: c7 44 24 6c 00 00 00movl $0x0,0x6c(%rsp) 1445: 00 1446: c7 44 24 70 00 00 00movl $0x0,0x70(%rsp) 144d: 00 144e: c7 44 24 74 00 00 00movl $0x0,0x74(%rsp) 1455: 00 1456: c7
[Bug lto/46525] New: [4.6 Regression] Failed to bootstrap-lto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46525 Summary: [4.6 Regression] Failed to bootstrap-lto Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: unassig...@gcc.gnu.org ReportedBy: hjl.to...@gmail.com On Linux/x86-64, revision 166867] failed with bootstrap-lto: http://gcc.gnu.org/ml/gcc-regression/2010-11/msg00229.html Revision 166855 is OK.
[Bug middle-end/46518] internal compiler error: in vinsn_detach, at sel-sched-ir.c:1271
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46518 Alexander Monakov amonakov at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2010.11.17 18:18:14 AssignedTo|unassigned at gcc dot |amonakov at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #10 from Alexander Monakov amonakov at gcc dot gnu.org 2010-11-17 18:18:14 UTC --- Thanks. diff --git a/gcc/sel-sched-ir.c b/gcc/sel-sched-ir.c index e169276..71c02c4 100644 --- a/gcc/sel-sched-ir.c +++ b/gcc/sel-sched-ir.c @@ -1595,7 +1595,7 @@ static void init_expr (expr_t expr, vinsn_t vi, int spec, int use, int priority, int sched_times, int orig_bb_index, ds_t spec_done_ds, ds_t spec_to_check_ds, int orig_sched_cycle, - VEC(expr_history_def, heap) *history, bool target_available, + VEC(expr_history_def, heap) *history, signed char target_available, bool was_substituted, bool was_renamed, bool needs_spec_check_p, bool cant_move) {
[Bug target/46519] Missing vzeroupper
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46519 --- Comment #1 from Uros Bizjak ubizjak at gmail dot com 2010-11-17 18:42:29 UTC --- Does the patch at [1] also fix this test? [1] http://gcc.gnu.org/ml/gcc-patches/2010-11/msg01802.html
[Bug target/46519] Missing vzeroupper
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46519 --- Comment #2 from H.J. Lu hjl.tools at gmail dot com 2010-11-17 18:49:14 UTC --- (In reply to comment #1) Does the patch at [1] also fix this test? [1] http://gcc.gnu.org/ml/gcc-patches/2010-11/msg01802.html No, that is for a different case.
[Bug lto/46525] [4.6 Regression] Failed to bootstrap-lto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46525 --- Comment #1 from H.J. Lu hjl.tools at gmail dot com 2010-11-17 18:56:09 UTC --- Revision 166872 gave: http://gcc.gnu.org/ml/gcc-regression/2010-11/msg00230.html xgcc: internal compiler error: Segmentation fault (program lto1) Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. lto-wrapper: /export/gnu/import/svn/gcc-test/bld/./prev-gcc/xgcc returned 4 exit status lto-wrapper failedcollect2: ld returned 1 exit status make[6]: *** [jc1] Error 1 make[6]: *** Waiting for unfinished jobs xgcc: internal compiler error: Segmentation fault (program lto1)
[Bug target/40171] GCC does not pass -mtune and -march options to assembler!
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40171 --- Comment #6 from Dzianis Kahanovich mahatma at eu dot by 2010-11-17 19:15:10 UTC --- Created attachment 22434 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22434 atune.patch Yes, I read maillist archives. But I don't know current state of process and may suggest own solution (best for me). Sorry if not actual. I pass only native march|mtune|Wa,-mtune - driver-i386.c -mtune results set are more compatible with GAS -mtune. And host_detect_local_cpu changed to process astune parameter and few (atom generic) incompatible keywords. There are only linux64.h changed. Others - likewise if somebody find this useful. patch produced on 5.0, but used on 4.5.
[Bug middle-end/46518] internal compiler error: in vinsn_detach, at sel-sched-ir.c:1271
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46518 --- Comment #11 from Jack Howarth howarth at nitro dot med.uc.edu 2010-11-17 19:26:31 UTC --- (In reply to comment #10) Thanks. diff --git a/gcc/sel-sched-ir.c b/gcc/sel-sched-ir.c index e169276..71c02c4 100644 --- a/gcc/sel-sched-ir.c +++ b/gcc/sel-sched-ir.c @@ -1595,7 +1595,7 @@ static void init_expr (expr_t expr, vinsn_t vi, int spec, int use, int priority, int sched_times, int orig_bb_index, ds_t spec_done_ds, ds_t spec_to_check_ds, int orig_sched_cycle, - VEC(expr_history_def, heap) *history, bool target_available, + VEC(expr_history_def, heap) *history, signed char target_available, bool was_substituted, bool was_renamed, bool needs_spec_check_p, bool cant_move) { I can confirm that this eliminates the ICE (segfault) during the compilation of gfortran.dg/pr42294.f on x86_64 Fedora10. Will test x86_64-apple-darwin10 next.
[Bug rtl-optimization/46514] 128-bit shifts on x86_64 generate silly code unless the shift amount is constant
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46514 Uros Bizjak ubizjak at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2010.11.17 19:51:24 Ever Confirmed|0 |1 --- Comment #1 from Uros Bizjak ubizjak at gmail dot com 2010-11-17 19:51:24 UTC --- This is how doubleword (TImode on x86_64 and DImode on x86_32 targets) shifts are handled. Doubleword instructions are expanded to final instruction sequence late after register allocation pass, so earlier optimization passes know that they are processing SHIFT expressions and optimize them as shifts. The expansion detects constant count operand and emits special sequence, but for sure it can't detect limited set of possible count operands, and emits universal sequence in this case. That said, doubleword operation code is not the most optimized code around, on the grounds that it is usually not used in performance critical part of the application. Just try to avoid it as much as possible.
[Bug lto/46525] [4.6 Regression] Failed to bootstrap-lto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46525 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.6.0
[Bug debug/39104] stabs debug info fails on IRIX 5.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39104 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #5 from Rainer Orth ro at gcc dot gnu.org 2010-11-17 20:32:57 UTC --- Fixed for binutils 2.21.
[Bug middle-end/46518] internal compiler error: in vinsn_detach, at sel-sched-ir.c:1271
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46518 --- Comment #12 from Jack Howarth howarth at nitro dot med.uc.edu 2010-11-17 20:34:15 UTC --- I can also confirm that the patch in Comment 10 eliminates the ICE in compiling gfortran.dg/pr42294.f -O on x86_64-apple-darwin10 (bootstrapped with --enable-build-with-cxx) as well. Thanks.
[Bug bootstrap/41337] [LTO] Parallel build failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41337 --- Comment #4 from Dima dmitrij.ledkov at ubuntu dot com 2010-11-17 21:02:58 UTC --- (In reply to comment #3) If you encounter parallel build failures, please post exact revision that was built, configure command line, build system type, number of processors on the box, N argument in 'make -jN', and ideally also the likelihood (in precent) that the build fails, if it is not deterministic. Please also post the last 300 or so lines of build output, and maybe check whether it always fails in the same spot. I'm building a cross-compiler: build/host = gnu-linux; target = i686-w64-mingw32. I've been using gcc-4.4 branch this whole week (will test again with trunk when I have time). It is fully deterministic (100% fail rate at the same spot) when I supply --with-build-libsubdir pointing to the $prefix/$target-triplet/lib. But the mentioned value for --with-build-libsubdir option is bogus and doesn't make sense. It is not too hard to pinpoint parallel build failures but only if there is enough data available. I no longer believe my error was to do with parallel make, it was the error between the keyboard and the chair =) in other words pilot error. If someone else will come across with make[1]: *** No rule to make target `build/gencondmd', needed by `s-condmd' Check your config and make sure it is sane =)
[Bug middle-end/45505] [4.6 Regression] gfortran.dg/pr25923.f90
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45505 --- Comment #14 from Jack Howarth howarth at nitro dot med.uc.edu 2010-11-17 21:16:40 UTC --- Interestingly, on x86_64-apple-darwin10, when using a --enable-build-with-cxx bootstrap, these tests change to... XPASS: gfortran.dg/pr25923.f90 -O PR45505 (test for warnings, line 13) XPASS: gfortran.dg/pr25923.f90 -O PR45505 (test for bogus messages, line 22) I don't see the same behavior with a --enable-build-with-cxx bootstrap on x86_64 Fedora10 however.
[Bug c++/46526] New: VTable Problem?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46526 Summary: VTable Problem? Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: nate.kni...@numerica.us Created attachment 22435 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22435 Preprocessed output Both asserts should pass, but one fails. Command: g++-mp-4.6 -std=c++0x -v -g3 -save-temps -Wall expose_bug.cpp -o expose_bug Command output: Using built-in specs. COLLECT_GCC=g++-mp-4.6 COLLECT_LTO_WRAPPER=/opt/local/libexec/gcc/x86_64-apple-darwin10/4.6.0/lto-wrapper Target: x86_64-apple-darwin10 Configured with: ../gcc-4.6-20101113/configure --prefix=/opt/local --build=x86_64-apple-darwin10 --enable-languages=c,c++,objc,obj-c++ --libdir=/opt/local/lib/gcc46 --includedir=/opt/local/include/gcc46 --infodir=/opt/local/share/info --mandir=/opt/local/share/man --datarootdir=/opt/local/share/gcc-4.6 --with-local-prefix=/opt/local --with-system-zlib --disable-nls --program-suffix=-mp-4.6 --with-gxx-include-dir=/opt/local/include/gcc46/c++/ --with-gmp=/opt/local --with-mpfr=/opt/local --with-mpc=/opt/local --enable-stage1-checking --disable-multilib --enable-fully-dynamic-string Thread model: posix gcc version 4.6.0 20101113 (experimental) (GCC) COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.6.5' '-std=c++0x' '-v' '-g3' '-save-temps' '-Wall' '-o' 'expose_bug' '-shared-libgcc' '-mtune=generic' /opt/local/libexec/gcc/x86_64-apple-darwin10/4.6.0/cc1plus -E -quiet -v -dD -D__DYNAMIC__ expose_bug.cpp -fPIC -mmacosx-version-min=10.6.5 -mtune=generic -std=c++0x -Wall -g3 -fworking-directory -fpch-preprocess -o expose_bug.ii ignoring nonexistent directory /opt/local/lib/gcc46/gcc/x86_64-apple-darwin10/4.6.0/../../../../../x86_64-apple-darwin10/include #include ... search starts here: #include ... search starts here: /opt/local/include/gcc46/c++/ /opt/local/include/gcc46/c++//x86_64-apple-darwin10 /opt/local/include/gcc46/c++//backward /opt/local/lib/gcc46/gcc/x86_64-apple-darwin10/4.6.0/include /opt/local/include /opt/local/lib/gcc46/gcc/x86_64-apple-darwin10/4.6.0/include-fixed /usr/include /System/Library/Frameworks /Library/Frameworks End of search list. COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.6.5' '-std=c++0x' '-v' '-g3' '-save-temps' '-Wall' '-o' 'expose_bug' '-shared-libgcc' '-mtune=generic' /opt/local/libexec/gcc/x86_64-apple-darwin10/4.6.0/cc1plus -fpreprocessed expose_bug.ii -fPIC -quiet -dumpbase expose_bug.cpp -mmacosx-version-min=10.6.5 -mtune=generic -auxbase expose_bug -g3 -Wall -std=c++0x -version -o expose_bug.s GNU C++ (GCC) version 4.6.0 20101113 (experimental) (x86_64-apple-darwin10) compiled by GNU C version 4.6.0 20101113 (experimental), GMP version 5.0.1, MPFR version 3.0.0-p8, MPC version 0.8.2 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 GNU C++ (GCC) version 4.6.0 20101113 (experimental) (x86_64-apple-darwin10) compiled by GNU C version 4.6.0 20101113 (experimental), GMP version 5.0.1, MPFR version 3.0.0-p8, MPC version 0.8.2 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Compiler executable checksum: 4b970d796b9f2164104727f632078674 COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.6.5' '-std=c++0x' '-v' '-g3' '-save-temps' '-Wall' '-o' 'expose_bug' '-shared-libgcc' '-mtune=generic' as -arch x86_64 -force_cpusubtype_ALL -o expose_bug.o expose_bug.s COMPILER_PATH=/opt/local/libexec/gcc/x86_64-apple-darwin10/4.6.0/:/opt/local/libexec/gcc/x86_64-apple-darwin10/4.6.0/:/opt/local/libexec/gcc/x86_64-apple-darwin10/:/opt/local/lib/gcc46/gcc/x86_64-apple-darwin10/4.6.0/:/opt/local/lib/gcc46/gcc/x86_64-apple-darwin10/ LIBRARY_PATH=/opt/local/lib/gcc46/gcc/x86_64-apple-darwin10/4.6.0/:/opt/local/lib/gcc46/gcc/x86_64-apple-darwin10/4.6.0/../../../:/usr/lib/ COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.6.5' '-std=c++0x' '-v' '-g3' '-save-temps' '-Wall' '-o' 'expose_bug' '-shared-libgcc' '-mtune=generic' /opt/local/libexec/gcc/x86_64-apple-darwin10/4.6.0/collect2 -dynamic -arch x86_64 -macosx_version_min 10.6.5 -weak_reference_mismatches non-weak -o expose_bug -lcrt1.10.5.o -L/opt/local/lib/gcc46/gcc/x86_64-apple-darwin10/4.6.0 -L/opt/local/lib/gcc46/gcc/x86_64-apple-darwin10/4.6.0/../../.. expose_bug.o -lstdc++ -lgcc_ext.10.5 -lgcc -no_compact_unwind -lSystem COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.6.5' '-std=c++0x' '-v' '-g3' '-save-temps' '-Wall' '-o' 'expose_bug' '-shared-libgcc' '-mtune=generic'
[Bug c/46076] [4.6 regression] constant propagation and compile-time math no longer happening versus 4.4 and 4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46076 --- Comment #11 from Matt Hargett matt at use dot net 2010-11-17 21:37:43 UTC --- Given that int foo() and int foo(void) are not varargs functions, shouldn't GCC mainline be able to optimize this?
[Bug middle-end/46510] [4.6 Regression] r166812 breaks bootstrap on x86_64-apple-darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46510 --- Comment #8 from Dominique d'Humieres dominiq at lps dot ens.fr 2010-11-17 21:39:08 UTC --- As I said in pr46511, removing the assert fixes the bootstrap and does not seem to introduce any regression (finishing regtesting): --- /opt/gcc/_clean/gcc/varpool.c2010-11-16 19:21:22.0 +0100 +++ /opt/gcc/work/gcc/varpool.c2010-11-17 10:59:15.0 +0100 @@ -335,7 +335,7 @@ decide_is_variable_needed (struct varpoo if (node-force_output) return true; - gcc_assert (!DECL_EXTERNAL (decl)); + /* gcc_assert (!DECL_EXTERNAL (decl)); */ /* Externally visible variables must be output. The exception is COMDAT variables that must be output only when they are needed. */
[Bug middle-end/42371] dead code not eliminated during folding with whole-program
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42371 --- Comment #5 from Matt Hargett matt at use dot net 2010-11-17 21:43:13 UTC --- GCC 4.6.0.20101116 still shows this problem, but also introduces new problems on top of it. Let me know if I should file a new bug for the regressions. Either way, is there any update on this enhancement getting into 4.6? Thanks!