[Bug c/43385] [4.5 Regression] glibc regex testsuite failures
--- Comment #6 from davem at davemloft dot net 2010-03-24 06:00 --- In the regex cases, glibc/posix/regexec.c:merge_state_with_log() is what gets miscompiled. I will attach match_good.s and match_bad.s match_good.s is a working compile of this function, using gcc-4.3.2 match_bad.s is a miscompiled copy, using mainline gcc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43385
[Bug c/43385] [4.5 Regression] glibc regex testsuite failures
--- Comment #7 from davem at davemloft dot net 2010-03-24 06:01 --- Created an attachment (id=20177) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20177action=view) correctly compiled function -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43385
[Bug c/43385] [4.5 Regression] glibc regex testsuite failures
--- Comment #8 from davem at davemloft dot net 2010-03-24 06:02 --- Created an attachment (id=20178) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20178action=view) miscompiled function -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43385
[Bug c/43385] [4.5 Regression] glibc regex testsuite failures
--- Comment #9 from jakub at gcc dot gnu dot org 2010-03-24 06:38 --- Could you please also attach regexec.i (and what gcc options were used to compile it), so that I can inspect it with a cross-compiler? Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43385
[Bug c/43385] [4.5 Regression] glibc regex testsuite failures
--- Comment #10 from davem at davemloft dot net 2010-03-24 06:43 --- Created an attachment (id=20179) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20179action=view) source that emitted miscompiled function -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43385
[Bug c/43385] [4.5 Regression] glibc regex testsuite failures
--- Comment #11 from jakub at gcc dot gnu dot org 2010-03-24 07:05 --- Created an attachment (id=20180) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20180action=view) hack Minimal patch that should allow playing with reversion of both parts of PR42233 just by changing that 1 to 0 and 0s into 1s (add_reg_br_prob_note and dojump.c need to agree on it). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43385
[Bug c/43385] [4.5 Regression] glibc regex testsuite failures
--- Comment #12 from jakub at gcc dot gnu dot org 2010-03-24 07:08 --- FYI, the only change I'm seeing is: - subcc %g0, %g1, %g0 - addx%g0, 0, %g1 with 1 vs. 0 in gimple_boolify and no effect with the other changes. That said, I'm probably using different cc1 options than you are... ./cc1 -g -O2 -m32 -mptr32 regexec.i -o regexec.s here... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43385
[Bug debug/43479] Missing DW_TAG_lexical_block+DW_TAG_variable
--- Comment #5 from jakub at gcc dot gnu dot org 2010-03-24 08:49 --- Created an attachment (id=20181) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20181action=view) gcc45-pr43479.patch So far only lightly tested fix. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43479
[Bug fortran/43505] New: [4.5 Regression] type mismatch between an SSA_NAME and its symbol with -O3
The testcase below is a development of that in PR41056 comment #8. It, however, does not need -fwhole-file to trigger the ICE. The ICE does not occur with GNU Fortran (GCC) 4.4.4 20100314 (prerelease). It also does not occur if the declaration for 'gridws' is moved to main. Therefore, it is somehow related to the fact that 'gridws' is use associated. [pa...@localhost pr41056]# /irun/bin/gfortran -static -O3 pr*6a.f90 pr41056a.f90: In function anyavg.1546.clone.0: pr41056a.f90:28:0: error: type mismatch between an SSA_NAME and its symbol while verifying SSA_NAME hts_1 in statement hts_1 = (real(kind=4)[0:D.1555] * restrict) gridws; pr41056a.f90:28:0: error: type mismatch between an SSA_NAME and its symbol pr41056a.f90:28:0: error: in statement hts_1 = (real(kind=4)[0:D.1555] * restrict) gridws; pr41056a.f90:28:0: internal compiler error: verify_ssa failed Cheers Paul MODULE MAIN1 INTEGER , PARAMETER :: MXGLVL = 87 CHARACTER(8) :: SRCTYP REAL :: GRIDWS(MXGLVL) REAL :: ZI, HS END MODULE MAIN1 PROGRAM TEST USE MAIN1 IF (HS = ZI) THEN ELSEIF ( SRCTYP == 'AREA' .OR. SRCTYP == 'AREAPOLY' .OR. SRCTYP == 'AREACIRC' .OR. SRCTYP == 'OPENPIT' ) THEN CALL ANYAVG (MXGLVL, GRIDWS) CALL ANYAVG (MXGLVL, GRIDWS) ELSE IF ( HS 0.0 ) THEN CALL ANYAVG (MXGLVL, GRIDWS) CALL ANYAVG (MXGLVL, GRIDWS) CALL ANYAVG (MXGLVL, GRIDWS) ENDIF ENDIF IF (HS.LT.ZI) THEN ZI = HS ENDIF contains SUBROUTINE ANYAVG(NLVLS,HTS) INTEGER NLVLS REAL HTS(NLVLS) IF (5.LT.NLVLS) THEN CALL GINTRP (HTS(5),HTS(5+1)) ENDIF CALL GINTRP (HTS(5-1), HTS(5)) END SUBROUTINE ANYAVG subroutine gintrp (x1, x2) print *, x1, x2 end subroutine END PROGRAM TEST -- Summary: [4.5 Regression] type mismatch between an SSA_NAME and its symbol with -O3 Product: gcc Version: 4.5.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: major Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pault at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43505
[Bug fortran/43505] [4.5 Regression] type mismatch between an SSA_NAME and its symbol with -O3
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-03-24 09:52 --- Hm, but the error is about hts_1, not gridws. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Severity|major |normal Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||ice-checking Last reconfirmed|-00-00 00:00:00 |2010-03-24 09:52:14 date|| Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43505
[Bug java/43504] many libjava testsuite regressions on x86_64-apple-darwin10
--- Comment #2 from dominiq at lps dot ens dot fr 2010-03-24 09:53 --- Confirmed on x86_64-apple-darwin10 and powerpc-apple-darwin9.8.0 (see http://gcc.gnu.org/ml/gcc-testresults/2010-03/msg02060.html ). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43504
[Bug c++/43506] New: name lookup fails in function template
aa.cpp:
templateclass T void f(int x, T t)
{
f(t);
}
void f(int);
void h()
{
f(1,2);
}
when compiled with g++ aa.cpp -c, it shows:
aa.cpp: In function 'void f(int, T) [with T = int]':
aa.cpp:10: instantiated from here
aa.cpp:3: error: no matching function for call to 'f(int)'
once the template instantiated from aa.cpp:10 the function void f(int f) should
has already been declared
--
Summary: name lookup fails in function template
Product: gcc
Version: 4.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: yao_yin at 163 dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43506
[Bug c++/43506] name lookup fails in function template
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-03-24 10:11 --- That's not how it works. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID Summary|name lookup fails in|name lookup fails in |function template |function template http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43506
[Bug c++/43507] New: name lookup fails in function template
aa.cpp:
templateclass T void f(int x, T t)
{
f(t);
}
void f(int);
void h()
{
f(1,2);
}
when compiled with g++ aa.cpp -c, it shows:
aa.cpp: In function 'void f(int, T) [with T = int]':
aa.cpp:10: instantiated from here
aa.cpp:3: error: no matching function for call to 'f(int)'
once the template instantiated from aa.cpp:10 the function void f(int f) should
has already been declared
--
Summary: name lookup fails in function template
Product: gcc
Version: 4.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: yao_yin at 163 dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43507
[Bug target/43498] No unwind info for thunks even with -fasynchronous-unwind-tables
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43498
[Bug libgomp/43499] libgomp.fortran/appendix-a/a.22.7.f90 and libgomp.fortran/omp_parse3.f90 fail on powerpc-unknown-linux-gnu with -fpic
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-03-24 10:16 --- binutils bug. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43499
[Bug c++/43506] name lookup fails in function template
--- Comment #2 from paolo dot carlini at oracle dot com 2010-03-24 10:16 --- *** Bug 43507 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43506
[Bug c++/43507] name lookup fails in function template
--- Comment #1 from paolo dot carlini at oracle dot com 2010-03-24 10:16 --- *** This bug has been marked as a duplicate of 43506 *** -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE Summary|name lookup fails in|name lookup fails in |function template |function template http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43507
[Bug pch/43497] gcc.dg/pch/static-1.c and gcc.dg/pch/static-2.c fail on powerpc-unknown-linux-gnu with -fPIC
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-03-24 10:17 --- I guess nobody cares. Fixed for 4.4. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43497
[Bug testsuite/43495] gcc.c-torture/execute/20000603-1.c fails with -fpic/-fPIC
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-03-24 10:20 --- The test is bogus and does not agree with how GCC interprets type-based aliasing rules. Thus it invokes undefined behavior (dependent on whether we inline or not). -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Component|c |testsuite Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-03-24 10:20:10 date|| Summary|[4.5 regression] gcc.c- |gcc.c- |torture/execute/2603-1.c|torture/execute/2603-1.c |fails with -fpic/-fPIC |fails with -fpic/-fPIC http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43495
[Bug c++/43506] name lookup fails in function template
--- Comment #3 from yao_yin at 163 dot com 2010-03-24 10:56 ---
(In reply to comment #1)
That's not how it works.
but code followed works ,
class X;
templateclass T void f(int x, T t)
{
f(t);
}
void f(X *k);
void h()
{
X *a;
f(1,a);
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43506
[Bug fortran/43505] [4.5 Regression] type mismatch between an SSA_NAME and its symbol with -O3
--- Comment #2 from pault at gcc dot gnu dot org 2010-03-24 11:09 --- (In reply to comment #1) Hm, but the error is about hts_1, not gridws. Does that not merely reflect the order that they are checked in the assignment? Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43505
[Bug fortran/43505] [4.5 Regression] type mismatch between an SSA_NAME and its symbol with -O3
--- Comment #3 from rguenther at suse dot de 2010-03-24 11:30 --- Subject: Re: [4.5 Regression] type mismatch between an SSA_NAME and its symbol with -O3 On Wed, 24 Mar 2010, pault at gcc dot gnu dot org wrote: --- Comment #2 from pault at gcc dot gnu dot org 2010-03-24 11:09 --- (In reply to comment #1) Hm, but the error is about hts_1, not gridws. Does that not merely reflect the order that they are checked in the assignment? No, the checking complains that TREE_TYPE (hts_1) (the type of the SSA name) is != TREE_TYPE (hts) (its symbol). That should never happen. Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43505
[Bug fortran/43505] [4.5 Regression] type mismatch between an SSA_NAME and its symbol with -O3
--- Comment #4 from pault at gcc dot gnu dot org 2010-03-24 11:39 --- (In reply to comment #3) No, the checking complains that TREE_TYPE (hts_1) (the type of the SSA name) is != TREE_TYPE (hts) (its symbol). That should never happen. Ah, OK. Interestingly, when HTS is declared assumed size or assumed shape, the ICE does not occur, as in PR41056. The inlining proceeds as far as calls to gintrp. If gridws is not use associated, gintrp is inlined too. I admit, however, that this is a distraction from the problem with hts. The difficulty must lie with the typing of address expressions in gfortran. I'll have a further think about it tonight. Any advice that you can give would be gratefully received. The critical bit is in trans.c:gfc_build_addr_expr. Cheers Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43505
[Bug target/43498] No unwind info for thunks even with -fasynchronous-unwind-tables
--- Comment #9 from jakub at gcc dot gnu dot org 2010-03-24 11:59 --- Actually, as the thunks are emitted before .eh_frame, it is much easier. -- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2010-03-23 19:13:40 |2010-03-24 11:59:53 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43498
[Bug target/43498] No unwind info for thunks even with -fasynchronous-unwind-tables
--- Comment #10 from jakub at gcc dot gnu dot org 2010-03-24 12:06 ---
Created an attachment (id=20182)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20182action=view)
gcc45-pr43498.patch
Patch to emit unwind info for thunks on x86, x86-64 and s390{,x}.
ppc/ppc64, sparc/sparc64 and ia64 (from arches that I care at least a little
bit about) should be outputting unwind info already before this change.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43498
[Bug c++/43508] New: ICE when compiling SSE code in non-debug mode
The compiler ICEs with the following message: (vec_select:SI (reg:V4SI 21 xmm0 [84]) (parallel [ (const_int 1 [0x1]) ]))/home/piotr.wyderski/rt_rel/texture.cpp: In member function 'virtual float __vector[4] rt::texture_2d::map(float __vector[4]) const': /home/piotr.wyderski/rt_rel/texture.cpp:82:1: internal compiler error: in mem_lo c_descriptor, at dwarf2out.c:13589 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. make[1]: *** [CMakeFiles/a.dir/texture.cpp.o] Error 1 I didn't manage to create a reasonably-sized testcase. -- Summary: ICE when compiling SSE code in non-debug mode Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: piotr dot wyderski at gmail dot com GCC build triplet: i686-pc-cygwin GCC host triplet: i686-pc-cygwin GCC target triplet: i686-pc-cygwin http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43508
[Bug c/43490] sin(x) (actually probably all trig) is inaccurate for large x
--- Comment #9 from simon dot fenney at imgtec dot com 2010-03-24 12:19 --- (In reply to comment #7) This is a glibc problem. Confirmed by LD_PRELOADing a different libm which makes it work. Please report to glibc bugzilla instead. The glibc team are saying that nothing has changed in the maths library (http://sourceware.org/bugzilla/show_bug.cgi?id=11422#c5) which brings me back here as it would appear that the only difference between the working and broken libraries are the versions of gcc used to compile them, e.g. working library: GNU C Library stable release version 2.3.4, by Roland McGrath et al. Compiled by GNU CC version 3.4.6 20060404 (Red Hat 3.4.6-11). example broken library: GNU C Library (EGLIBC) stable release version 2.10.1, gcc version 4.4.1 (Ubuntu 4.4.1-4ubuntu9) -- simon dot fenney at imgtec dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43490
[Bug c/43490] sin(x) (actually probably all trig) is inaccurate for large x
--- Comment #10 from rguenth at gcc dot gnu dot org 2010-03-24 12:37 --- Both sin and sinf are assembly routines so can't probably be affected by the gcc used to compile them. See sysdeps/i386/fpu/s_sinf.S and sysdeps/i386/fpu/s_sin.S. I have not seen a working library for your testcase (2.9, built with GCC 4.3.2 is broken). This isn't a GCC bug but a glibc bug. Clearly glibc uses fsin out of specs. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43490
[Bug c++/43508] ICE when compiling SSE code in non-debug mode
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-03-24 12:50 --- Even unreasonably-sized testcases are useful. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43508
[Bug c/43490] sin(x) (actually probably all trig) is inaccurate for large x
--- Comment #11 from simon dot fenney at imgtec dot com 2010-03-24 13:16 --- (In reply to comment #10) Both sin and sinf are assembly routines so can't probably be affected by the gcc used to compile them. See sysdeps/i386/fpu/s_sinf.S and sysdeps/i386/fpu/s_sin.S. I have not seen a working library for your testcase (2.9, built with GCC 4.3.2 is broken). Hmm. The last lot of code I saw was all generic c. Interesting This isn't a GCC bug but a glibc bug. Clearly glibc uses fsin out of specs. I can't see that *is* this issue unless fsin is also fundamentally broken. The Intel Instruction Set Reference states fsin works in the range -2^63 to +2^63 and I have just tested a value ~2^7 and got the following sin(1240093312.00) (i.e. sin(0x93d4a5 * 2^7)) is computed as -4.581222e-08 (-0x1.898622f829ffep-25) It SHOULD be ~ -4.581062e-08 (-0x1.8982a036335f2p-25) Relative error is 3.485e-03% That is dreadfully inaccurate and corresponds to about 15 bits accuracy instead of an expected result of about 52~53 bits for a double. Is there ANY way to get the gcc and glibc developers to talk directly to each other rather than have me ping-ponging back and forth between the two bugzilla databases? -- simon dot fenney at imgtec dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43490
[Bug c/43490] sin(x) (actually probably all trig) is inaccurate for large x
--- Comment #12 from simon dot fenney at imgtec dot com 2010-03-24 13:18 --- (In reply to comment #11) (In reply to comment #10) and I have just tested a value ~2^7 and got the following Sorry I meant to say ~2^30 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43490
[Bug c/43490] sin(x) (actually probably all trig) is inaccurate for large x
--- Comment #13 from rguenth at gcc dot gnu dot org 2010-03-24 13:20 --- Same error with glibc 2.5. Note that fsin is not part of IEEE and thus does not guarantee 1ulp precision (in fact it is known for its inaccuracies). Please do not keep re-opening this bug. It is not a GCC bug but a GLIBC bug. I don't think it is a GLIBC regression either, unless the x87 assembly wasn't there in 2.3.4. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43490
[Bug c++/43508] ICE when compiling SSE code in non-debug mode
--- Comment #2 from piotr dot wyderski at gmail dot com 2010-03-24 13:24 --- Compiled with: $ /opt/gcc-trunk/bin/g++ -std=gnu++0x -Wno-pmf-conversions -fno-deduce-init-lis t -O3 -DNDEBUG -Wall -Werror -Wno-unused -msse -msse2 -march=native -mfpmath= sse -fomit-frame-pointer -c -ggdb texture.cpp.i However, it is very hard to replicate the error. It is fully deterministic, but occurs on [gcc version 4.5.0 20100322 (experimental) (GCC)] -- a month older compiler does not fail. It also doesn't happen without -ggdb. It requires an SSE4.1-capable processor (mine is Core i7), but occurs only when -march=native -- if I specify no march and explicitly enable -msse4, it also doesn't fail. I don't know what exact command line without -march should look like to cause the bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43508
[Bug c++/43508] ICE when compiling SSE code in non-debug mode
--- Comment #3 from piotr dot wyderski at gmail dot com 2010-03-24 13:27 --- Created an attachment (id=20183) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20183action=view) Testcase to replicate the bug -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43508
[Bug debug/19192] [4.3/4.4/4.5 Regression] Current development gcc generates inaccurate line info for example code
--- Comment #19 from jakub at gcc dot gnu dot org 2010-03-24 13:41 --- Subject: Bug 19192 Author: jakub Date: Wed Mar 24 13:41:30 2010 New Revision: 157693 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157693 Log: PR debug/19192 PR debug/43479 * cfgexpand.c (gimple_assign_rhs_to_tree): Also set TREE_BLOCK from gimple_block. * expr.c (expand_expr_real): Restore previous curr_insn_source_location and curr_insn_block after expand_expr_real_1 call. (expand_expr_real_1) case SSA_NAME: Call expand_expr_real instead of expand_expr_real_1. * gcc.dg/guality/pr43479.c: New test. * gcc.dg/debug/dwarf2/inline2.c (third): Make a a global var and add volatile keyword. Added: trunk/gcc/testsuite/gcc.dg/guality/pr43479.c Modified: trunk/gcc/ChangeLog trunk/gcc/cfgexpand.c trunk/gcc/expr.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/debug/dwarf2/inline2.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19192
[Bug debug/43479] Missing DW_TAG_lexical_block+DW_TAG_variable
--- Comment #6 from jakub at gcc dot gnu dot org 2010-03-24 13:41 --- Subject: Bug 43479 Author: jakub Date: Wed Mar 24 13:41:30 2010 New Revision: 157693 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157693 Log: PR debug/19192 PR debug/43479 * cfgexpand.c (gimple_assign_rhs_to_tree): Also set TREE_BLOCK from gimple_block. * expr.c (expand_expr_real): Restore previous curr_insn_source_location and curr_insn_block after expand_expr_real_1 call. (expand_expr_real_1) case SSA_NAME: Call expand_expr_real instead of expand_expr_real_1. * gcc.dg/guality/pr43479.c: New test. * gcc.dg/debug/dwarf2/inline2.c (third): Make a a global var and add volatile keyword. Added: trunk/gcc/testsuite/gcc.dg/guality/pr43479.c Modified: trunk/gcc/ChangeLog trunk/gcc/cfgexpand.c trunk/gcc/expr.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/debug/dwarf2/inline2.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43479
[Bug c/43384] [4.3/4.4/4.5 Regression] ICE: Segmentation fault with invalid KR-like code
--- Comment #3 from zsojka at seznam dot cz 2010-03-24 13:49 --- Created an attachment (id=20184) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20184action=view) another similiar testcase 3.3.6 gives: $ gcc-3.3.6 pr43384-3.c pr43384-3.c: In function `foo': pr43384-3.c:2: error: parameter `j' is initialized pr43384-3.c:2: error: `i' undeclared (first use in this function) pr43384-3.c:2: error: (Each undeclared identifier is reported only once pr43384-3.c:2: error: for each function it appears in.) pr43384-3.c:2: error: declaration for parameter `j' but no such parameter 3.4.6 and newer without checking: $ gcc-3.4.6 pr43384-3.c pr43384-3.c: In function `foo': pr43384-3.c:2: error: parameter `j' is initialized pr43384-3.c:2: error: `i' undeclared (first use in this function) pr43384-3.c:2: error: (Each undeclared identifier is reported only once pr43384-3.c:2: error: for each function it appears in.) pr43384-3.c:2: confused by earlier errors, bailing out trunk with checking: $ /mnt/svn/gcc-trunk/binary-157675-lto/bin/gcc pr43384-3.c pr43384-3.c: In function 'foo': pr43384-3.c:2:1: error: parameter 'j' is initialized pr43384-3.c:2:9: error: 'i' undeclared (first use in this function) pr43384-3.c:2:9: note: each undeclared identifier is reported only once for each function it appears in pr43384-3.c:3:1: internal compiler error: tree check: expected tree that contains 'decl minimal' structure, have 'error_mark' in store_parm_decls_oldstyle, at c-decl.c:7670 4.4 with checking: $ /mnt/svn/gcc-4_4/binary-157395-enable-checking/bin/gcc pr43384-3.c pr43384-3.c: In function 'foo': pr43384-3.c:2: error: parameter 'j' is initialized pr43384-3.c:2: error: 'i' undeclared (first use in this function) pr43384-3.c:2: error: (Each undeclared identifier is reported only once pr43384-3.c:2: error: for each function it appears in.) ' tree check: expected tree that contains 'decl minimal' structure, have 'error_mark' in c_tree_printer, at c-objc-common.c:109 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43384
[Bug debug/19192] [4.3/4.4/4.5 Regression] Current development gcc generates inaccurate line info for example code
--- Comment #20 from jakub at gcc dot gnu dot org 2010-03-24 13:51 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19192
[Bug debug/43508] ICE when compiling SSE code in non-debug mode
--- Comment #4 from jakub at gcc dot gnu dot org 2010-03-24 13:52 --- Created an attachment (id=20185) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20185action=view) gcc45-pr43508.patch I can't reproduce this myself, but the attached patch could help. OT, wonder about the subject, the ICE clearly happens in debug mode, not non-debug mode... -- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|WAITING |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43508
[Bug c/43490] sin(x) (actually probably all trig) is inaccurate for large x
--- Comment #14 from pluto at agmk dot net 2010-03-24 13:59 --- i've checked the Test0 from example a little on my intel Q9300 cpu. first case: setup 32-bit code and break on libm.sin implementation. Breakpoint 1, main (argc=1, argv=0xe3c4) at t.c:74 (gdb) b sin Breakpoint 2 at 0xf7fa7110: file ../sysdeps/i386/fpu/s_sin.S, line 14. Test 0: (gdb) p testvalue $1 = 43998769152 Breakpoint 2, sin () at ../sysdeps/i386/fpu/s_sin.S:14 (gdb) bt #0 sin () at ../sysdeps/i386/fpu/s_sin.S:14 #1 0x08048682 in main (argc=1, argv=0xe3c4) at t.c:81 (gdb) info float =R7: Valid 0x4022a3e87f00 +43998769152 11x RCSID($NetBSD: s_sin.S,v 1.5 1995/05/09 00:25:54 jtc Exp $) 12x 13x ENTRY(__sin) 14x fldl4(%esp) 15x fxam 16x fstsw %ax 17x movb$0x45, %dh 18x andb%ah, %dh 19x cmpb$0x05, %dh 20x je 3f 21x 4: fsin here we calculate Test0. 22tfnstsw %ax 23x testl $0x400,%eax 24x jnz 1f 25x ret and return... 26x .align ALIGNARG(4) 27x 1: fldpi 28x fadd%st(0) 29x fxch%st(1) 30x 2: fprem1 31x fnstsw %ax 32x testl $0x400,%eax 33x jnz 2b 34x fstp%st(1) 35x fsin 36x ret 37x 3: and the hardware result is: (gdb) info float =R7: Valid 0xbfe38c41185b67e4 -4.081936725100227664e-09 sin(43998769152.00) (i.e. sin(0xa3e87f * 2^12)) is computed as -4.081937e-09 (-0x1.188230b6dp-28) It SHOULD be ~ -4.025292e-09 (-0x1.149dafd6b8987p-28) Relative error is 1.407% as you can see for 32-bit implementation there's *NO* smart argument range reduction. second case: setup 64-bit code. (gdb) break sin Breakpoint 2 at 0x77b79e00: file ../sysdeps/ieee754/dbl-64/s_sin.c, line 90. (gdb) c Test 0: Continuing. Breakpoint 2, __sin (x=43998769152) at ../sysdeps/ieee754/dbl-64/s_sin.c:90 and here's some kind of range reduction for -105414350 |x| 281474976710656. (gdb) fin Run till exit from #0 __sin (x=43998769152) at ../sysdeps/ieee754/dbl-64/s_sin.c:235 0x00400882 in main (argc=1, argv=0x7fffe298) at t.c:81 Value returned is $1 = -4.0252920638371055e-09 sin(43998769152.00) (i.e. sin(0xa3e87f * 2^12)) is computed as -4.025292e-09 (-0x1.149dafd6b8987p-28) It SHOULD be ~ -4.025292e-09 (-0x1.149dafd6b8987p-28) Relative error is 0.000e+00% finally, as you can see this NOT a gcc bug. it's a QOI bug in glibc ;) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43490
[Bug java/43504] many libjava testsuite regressions on x86_64-apple-darwin10
--- Comment #3 from howarth at nitro dot med dot uc dot edu 2010-03-24 14:24 --- Assuming this is change is fixed and not regressed out for gcc 4.5, we should also make sure that there are no additional regressions in the ada testsuite. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43504
[Bug c/43490] sin(x) (actually probably all trig) is inaccurate for large x
--- Comment #15 from simon dot fenney at imgtec dot com 2010-03-24 14:34 --- Thanks. I'll go back to the glibc bugzilla. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43490
[Bug target/39254] [4.4 Regression] gcc.c-torture/execute/va-arg-trap-1.c ICEs on powerpc-apple-darwin9
--- Comment #23 from dominiq at lps dot ens dot fr 2010-03-24 14:41 --- The result of regression testing for gcc and gfortran with the patch committed on trunk at revision 148568 posted at http://gcc.gnu.org/ml/gcc-testresults/2010-03/msg02071.html. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39254
[Bug debug/19192] [4.3/4.4/4.5 Regression] Current development gcc generates inaccurate line info for example code
--- Comment #21 from rguenth at gcc dot gnu dot org 2010-03-24 14:48 --- For 4.5.0. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.3.5 |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19192
[Bug debug/43508] ICE when compiling SSE code with -ggdb
--- Comment #5 from piotr dot wyderski at gmail dot com 2010-03-24 15:33 --- wonder about the subject, the ICE clearly happens in debug mode, not non-debug mode... The command line specified does not contain -DNDEBUG, as the preprocessed file was created in non-debug mode, so all the #ifndef NDEBUG sections have already been removed by the preprocessor. If the entire build (i.e. via CMake) is done in debug mode, the compiler doesn't ICE. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43508
[Bug target/33120] Data not put in BSS section on Mac OS
--- Comment #12 from mrs at gcc dot gnu dot org 2010-03-24 16:08 --- Subject: Bug 33120 Author: mrs Date: Wed Mar 24 16:07:51 2010 New Revision: 157697 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157697 Log: PR java/43504 Revert fix for PR target/33120. Removed: trunk/gcc/testsuite/gcc.target/i386/darwin-zerofill.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/darwin-protos.h trunk/gcc/config/darwin.c trunk/gcc/config/darwin.h trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/ext/instantiate2.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33120
[Bug java/43504] many libjava testsuite regressions on x86_64-apple-darwin10
--- Comment #4 from mrs at gcc dot gnu dot org 2010-03-24 16:08 --- Subject: Bug 43504 Author: mrs Date: Wed Mar 24 16:07:51 2010 New Revision: 157697 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157697 Log: PR java/43504 Revert fix for PR target/33120. Removed: trunk/gcc/testsuite/gcc.target/i386/darwin-zerofill.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/darwin-protos.h trunk/gcc/config/darwin.c trunk/gcc/config/darwin.h trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/ext/instantiate2.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43504
[Bug java/43504] many libjava testsuite regressions on x86_64-apple-darwin10
--- Comment #5 from mrs at gcc dot gnu dot org 2010-03-24 16:10 --- This has been fixed. -- mrs at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43504
[Bug c++/43502] [C++0x] uninitialised read in grokfndecl() with lambda functions cause -fcompare-debug failures
-- jason at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-03-24 16:10:43 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43502
[Bug target/33120] Data not put in BSS section on Mac OS
--- Comment #13 from mrs at gcc dot gnu dot org 2010-03-24 16:13 --- The fixed cause many failures in the libjava testsuite. I've reverted this fix for now until I can spend some time to resolve those issues. We should also ensure that ada is clean as well before we consider this done. -- mrs at gcc dot gnu dot org changed: What|Removed |Added CC||mikestump at comcast dot net Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33120
[Bug java/43504] many libjava testsuite regressions on x86_64-apple-darwin10
--- Comment #6 from mrs at gcc dot gnu dot org 2010-03-24 16:20 --- Thanks for the quick heads up. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43504
[Bug c++/43509] New: ICE: in constructor_name_p, at cp/name-lookup.c:1809 with invalid code in c++0x mode
Command line:
g++ -std=c++0x testcase.cpp
testcase.cpp
template typename struct A { A(); };
typedef A B;
template B::A() {}
--
trunk (with checking) gives:
$ /mnt/svn/gcc-trunk/binary-157675-lto/bin/g++ -std=c++0x testcase.cpp
testcase.cpp:2:12: error: wrong number of template arguments (0, should be 1)
testcase.cpp:1:30: error: provided for 'templateclass struct A'
testcase.cpp:2:15: error: invalid type in declaration before ';' token
testcase.cpp:3:16: internal compiler error: in constructor_name_p, at
cp/name-lookup.c:1809
trunk (without checking) gives:
$ g++-4.5.0-alpha20100318 -std=c++0x testcase.cpp
testcase.cpp:2:12: error: wrong number of template arguments (0, should be 1)
testcase.cpp:1:30: error: provided for 'templateclass struct A'
testcase.cpp:2:15: error: invalid type in declaration before ';' token
testcase.cpp:3:18: error: ISO C++ forbids declaration of 'A' with no type
testcase.cpp:3:18: error: 'int' is not a class or a namespace
testcase.cpp:3:18: error: 'A' is not a template function
4.4 (with checking) gives:
$ /mnt/svn/gcc-4_4/binary-157395-enable-checking/bin/g++ -std=c++0x
testcase.cpp
testcase.cpp:2: error: wrong number of template arguments (0, should be 1)
testcase.cpp:1: error: provided for 'templateclass struct A'
testcase.cpp:2: error: invalid type in declaration before ';' token
testcase.cpp:3: error: 'B' is not a class type
testcase.cpp:3: error: 'B' is not a class type
testcase.cpp:3: error: 'B' is not a class type
testcase.cpp:3: error: ISO C++ forbids declaration of 'A' with no type
testcase.cpp:3: error: 'int' is not a class or a namespace
testcase.cpp:3: error: 'A' is not a template function
Diagnostics look too complicated, given the problem is wrong number of template
parameters.
--
Summary: ICE: in constructor_name_p, at cp/name-lookup.c:1809
with invalid code in c++0x mode
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: zsojka at seznam dot cz
GCC host triplet: x86_64-pc-linux-gnu
GCC target triplet: x86_64-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43509
[Bug c++/43506] name lookup fails in function template
--- Comment #4 from pinskia at gcc dot gnu dot org 2010-03-24 16:42 --- Reopening to ... -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43506
[Bug c++/43509] [C++0x] ICE in constructor_name_p, at cp/name-lookup.c:1809
--- Comment #1 from paolo dot carlini at oracle dot com 2010-03-24 16:43 --- Let's add Jason for this one too. -- paolo dot carlini at oracle dot com changed: What|Removed |Added CC||jason at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43509
[Bug c++/43506] name lookup fails in function template
--- Comment #5 from pinskia at gcc dot gnu dot org 2010-03-24 16:45 --- Close as a dup of bug 29131. Comment #3 is valid as the associated namespace for X is the global namespace. But with fundamental types there is currently no associated namespace so the functions are not found. Now there is a defect report against the C++ standard which asks if this was done that way; that is what PR 29131 references and is suspended until the C++ standards committee decides what should happen. *** This bug has been marked as a duplicate of 29131 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43506
[Bug c++/29131] [DR 225] Bad name lookup for templates due to fundamental types namespace for ADL.
--- Comment #11 from pinskia at gcc dot gnu dot org 2010-03-24 16:45 --- *** Bug 43506 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||yao_yin at 163 dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29131
[Bug c++/43502] [C++0x] uninitialised read in grokfndecl() with lambda functions cause -fcompare-debug failures
--- Comment #3 from jason at gcc dot gnu dot org 2010-03-24 16:49 --- Subject: Bug 43502 Author: jason Date: Wed Mar 24 16:49:06 2010 New Revision: 157701 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157701 Log: PR c++/43502 * parser.c (make_declarator): Initialize id_loc. (cp_parser_lambda_declarator_opt): And set it. Added: trunk/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-debug.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43502
[Bug debug/43479] Missing DW_TAG_lexical_block+DW_TAG_variable
--- Comment #7 from jakub at gcc dot gnu dot org 2010-03-24 16:50 --- Subject: Bug 43479 Author: jakub Date: Wed Mar 24 16:50:11 2010 New Revision: 157702 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157702 Log: PR debug/43479 * ira.c (adjust_cleared_regs): New function. (update_equiv_regs): Adjust cleared_regs in DEBUG_INSNs. Modified: trunk/gcc/ChangeLog trunk/gcc/ira.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43479
[Bug debug/43508] ICE when compiling SSE code with -ggdb
--- Comment #6 from jakub at gcc dot gnu dot org 2010-03-24 16:51 ---
Subject: Bug 43508
Author: jakub
Date: Wed Mar 24 16:51:02 2010
New Revision: 157703
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157703
Log:
PR debug/43508
* dwarf2out.c (mem_loc_descriptor): Don't ICE on
VEC_{MERGE,SELECT,CONCAT,DUPLICATE}.
Modified:
trunk/gcc/ChangeLog
trunk/gcc/dwarf2out.c
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43508
[Bug debug/43479] Missing DW_TAG_lexical_block+DW_TAG_variable
--- Comment #8 from jakub at gcc dot gnu dot org 2010-03-24 16:55 --- Testcase from #c1 fixed, for #c0 I don't consider it a bug -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43479
[Bug c/43385] [4.5 Regression] glibc regex testsuite failures
--- Comment #13 from davem at davemloft dot net 2010-03-24 16:55 --- I'm not passing anything special to the build, just stock -O2 with a 32-bit compiler. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43385
[Bug c/43385] [4.5 Regression] glibc regex testsuite failures
--- Comment #14 from jakub at gcc dot gnu dot org 2010-03-24 17:02 --- Can you please try the #c11 patch with 0 instead of 1 in gimple_boolify and see whether you see any difference beyond those two insns (and whether it works)? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43385
[Bug c/43385] [4.5 Regression] glibc regex testsuite failures
--- Comment #15 from jakub at gcc dot gnu dot org 2010-03-24 17:04 --- Perhaps also with -fverbose-asm see what options were actually used during the compilation? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43385
[Bug c/43385] [4.5 Regression] glibc regex testsuite failures
--- Comment #16 from davem at davemloft dot net 2010-03-24 17:08 --- I'm trying to distill a test case currently and also something broke bootstrap on sparc in the past day or two (I think it's the IRA change) which I want to track down first. I'll play with your patch once I get past those two things. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43385
[Bug c++/43509] [4.5 regression] [C++0x] ICE in constructor_name_p, at cp/name-lookup.c:1809
-- jason at gcc dot gnu dot org changed: What|Removed |Added CC|jason at gcc dot gnu dot org| AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-03-24 17:11:29 date|| Summary|[C++0x] ICE in |[4.5 regression] [C++0x] ICE |constructor_name_p, at |in constructor_name_p, at |cp/name-lookup.c:1809 |cp/name-lookup.c:1809 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43509
[Bug c/43385] [4.5 Regression] glibc regex testsuite failures
--- Comment #17 from davem at davemloft dot net 2010-03-24 17:22 --- I get the same two instruction change you saw with 0 and it makes the test pass. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43385
[Bug target/33120] Data not put in BSS section on Mac OS
--- Comment #14 from dominiq at lps dot ens dot fr 2010-03-24 17:27 --- Note that there was no libjava test failure with the patch in http://gcc.gnu.org/ml/fortran/2010-03/txt7.txt . Also with this patch the test in comment #8 was not improved. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33120
[Bug c/43385] [4.5 Regression] glibc regex testsuite failures
--- Comment #18 from doko at ubuntu dot com 2010-03-24 17:31 --- seen on the 4.4 branch as well on ia64-linux-gnu, configured --with-system-libunwind sparc-linux-gnu, building with -m32 -mcpu=ultrasparc arm-linux-gnueabi, configured with -with-arch=armv7-a --with-float=softfp --with-fpu=vfpv3-d16 --with-mode=thumb -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43385
[Bug c/43510] New: ICE on wrong -mfpu value
Preprocessing an empty file with a wrong -mfpu value results in: empty.c:1:0: error: invalid floating point option: -mfpu=xxx empty.c:1:0: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. The command: /home/buchmann/devel/superfluous/eo3s/tc//bin/arm-fhnw-elf-cpp \ -mfpu=xxx empty.c The version /home/buchmann/devel/superfluous/eo3s/tc//bin/arm-fhnw-elf-cpp -v Configured with: /home/buchmann/devel/gcc/dist/gcc-4.5-20091217/configure -v \ --prefix=/home/buchmann/devel/gcc/target/arm \ --target=arm-fhnw-elf \ --enable-languages=c \ --disable-threads \ --disable-shared \ --disable-multilib \ --disable-nls \ --disable-__cxa_atexit \ --with-as=/home/buchmann/devel/gcc/target/arm/arm-fhnw-elf/bin/as \ --with-ld=/home/buchmann/devel/gcc/target/arm/arm-fhnw-elf/bin/ld \ --with-newlib \ --without-sysroot \ --without-headers \ --disable-libssp \ --disable-nls \ --with-mpfr=/home/buchmann/devel/gcc/target/arm/../infrastructure/ \ --with-mpc=/home/buchmann/devel/gcc/target/arm/../infrastructure/ \ --with-gmp=/home/buchmann/devel/gcc/target/arm/../infrastructure/ \ (reconfigured) /home/buchmann/devel/gcc/dist/gcc-4.5-20091217/configure -v \ --prefix=/home/buchmann/devel/gcc/target/arm \ --target=arm-fhnw-elf --enable-languages=c,c++ \ --disable-threads --disable-shared \ --disable-multilib \ --disable-nls \ --disable-__cxa_atexit \ --with-as=/home/buchmann/devel/gcc/target/arm/arm-fhnw-elf/bin/as \ --with-ld=/home/buchmann/devel/gcc/target/arm/arm-fhnw-elf/bin/ld \ --with-newlib \ --without-sysroot \ --without-headers \ --disable-libssp \ --disable-nls \ --with-mpfr=/home/buchmann/devel/gcc/target/arm/../infrastructure/ \ --with-mpc=/home/buchmann/devel/gcc/target/arm/../infrastructure/ \ --with-gmp=/home/buchmann/devel/gcc/target/arm/../infrastructure/ Thread model: single gcc version 4.5.0 20091217 (experimental) (GCC) Best regards Hans Buchmann -- Summary: ICE on wrong -mfpu value Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hans dot buchmann at fhnw dot ch GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: arm-fhnw-elf http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43510
[Bug target/33120] Data not put in BSS section on Mac OS
--- Comment #15 from developer at sandoe-acoustics dot co dot uk 2010-03-24 17:39 --- (In reply to comment #14) Note that there was no libjava test failure with the patch in http://gcc.gnu.org/ml/fortran/2010-03/txt7.txt . Also with this patch the test in comment #8 was not improved. since this is re-opened a few notes .. (a) the test at comment #8 is different from the original bug since it carries out explicit initialization (as opposed to implicit). (b) I don't think the issue is the segment into which the data are assembled, but rather that the .space instruction is inefficient c.f. the .zerofill one. (c) comment (b) might lead to the observation that we could further improve things by replacing .space with .zerofill as the darwin ASM_SKIP_OP .. unfortunately, .zerofill needs state information (viz-a-viz what segment is current) or, alternatively, a priori knowledge of the target segment. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33120
[Bug target/42957] ARM: Segfault when invalid -mfpu argument is specified.
--- Comment #4 from pinskia at gcc dot gnu dot org 2010-03-24 17:42 --- *** Bug 43510 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||hans dot buchmann at fhnw ||dot ch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42957
[Bug target/43510] ICE on wrong -mfpu value
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-03-24 17:42 --- 20091217 This was fixed already (back in February), please try a new snapshot. Also you should look into using the ARM EABI target rather than the old arm elf target. *** This bug has been marked as a duplicate of 42957 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43510
[Bug c/43385] [4.5 Regression] glibc regex testsuite failures
--- Comment #19 from davem at davemloft dot net 2010-03-24 17:59 --- Created an attachment (id=20186) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20186action=view) Distilled test case. The expression that causes problems is: if (__builtin_expect (integer, 0) ptr != NULL) It thinks that it is legal to test this as: tmp1 = (ptr != NULL) ? 1 : 0; result = (tmp1 integer); but that fails if integer does not have bit 0 set. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43385
[Bug target/43484] [4.5 Regression] GCC 4.5 does not build gamess, zeusmp on powerpc -m32 with loop unrolling
--- Comment #9 from meissner at gcc dot gnu dot org 2010-03-24 18:00 --- Created an attachment (id=20187) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20187action=view) Patch to swap registers if first register is r0 in multi-word moves. This patch fixes the problem in building the spec 2006 benchmarks zeusmp and gamess on the powerpc that was introduced in the 2010-03-17 change to rs6000.c. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43484
[Bug testsuite/43495] gcc.c-torture/execute/20000603-1.c fails with -fpic/-fPIC
--- Comment #4 from ghazi at gcc dot gnu dot org 2010-03-24 18:11 --- OK, I'll modify the testcase to ensure function f() gets inlined. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43495
[Bug c++/43502] [C++0x] uninitialised read in grokfndecl() with lambda functions cause -fcompare-debug failures
--- Comment #4 from jason at gcc dot gnu dot org 2010-03-24 18:13 --- Fixed. -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43502
[Bug c++/43509] [4.5 regression] [C++0x] ICE in constructor_name_p, at cp/name-lookup.c:1809
--- Comment #2 from jason at gcc dot gnu dot org 2010-03-24 18:14 ---
Smaller testcase:
typedef int B;
B::B() {}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43509
[Bug tree-optimization/42906] [4.5 Regression] Empty loop not removed
--- Comment #22 from hubicka at gcc dot gnu dot org 2010-03-24 18:17 --- Hi, I am teaching CD-DCE today so I took oppurtunity to figure out what happens. 1) The original formulation by Cytron et. al. has mistake in it. It claims that after removal of dead conditional one can take any edge and follow to it. This was bug I was solving while ago that closes empty loop to infinite loop. This was subsequently corrected by Rob Shiler. He added clause for redirection of dead conditionals to nearest useful postdominator and he also use reverse dominance frontiers instead of control dependency to mark useful statements. 2) Formulation in Cytron et al. and Morgan's textbook has both problem with not handling PHIs specially as we do. This has nothing to do with allowing constants in operands, but it fails on overlapping live ranges: a_1=exp1 a_2=exp2 if (test) empty else empty a_3=phi(a_1,a_2) here we must mark control dependency for the PHI operands. So Steven's argument about problems with constant arguments in PHIs seems false. 3) as Steven observed, problem is that BB6 is control dependent on itself. It has to be. Control dependency is for basic blocks and if something in basic block is useful, it must be executed same number of times as before. So one can not mark as useful only the source 4) I think problem is that we mark BB as useful for PHI argument while we really need to know if control flow arrived from that BB or other BB. Steven is right that splitting the edge and introducing new BB on the way is correct way to get this issue resolved. I believe that same effect can be by modifying mark_control_dependent_edges_necessary to exclude self control dependences when marking PHI edges (since we are not interested in BB itself). Say that we B is the basic block with PHI. C is BB of PHI source. Now if B postdominates C, then C' (slpitting edge from B to C) will sit in dominance tree just in between B and C and result of control dependence will be same as for C just with C omitted (since C' postdominate C). This follows from equivalency of control dependence and reverse dominance frontiers and way reverse dominance frontiers computatio nworks. If B does not postdominate C, then the split C' would be predecestor of B without any succesors. We already mark reverse dominance frontier of B (since it is live) so we should be happy here. I am testing patch to do that, it bootstraps and solves the testcase. Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42906
[Bug bootstrap/42529] Stage 1 compiler cannot compile
--- Comment #15 from mckelvey at maskull dot com 2010-03-24 18:26 --- (In reply to comment #14) I now see that sjlj dll is back in /usr/local/bin, along with the other one. I delete them, and the new g++ works. At least it compiles to a .o again. We'll see if my project actually runs properly. So I guess that the build and install recreates those rogue dlls. My project compiles and links, but cannot run because the DLL is missing. So the DLL must be deleted to compile. but present to run. I get the same behavior on two hosts, one running Windows 7 and the other XP. Please advise. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42529
[Bug target/38118] gcc emits non-TLS data as TLS on Solaris 11/SPARC
--- Comment #5 from ro at gcc dot gnu dot org 2010-03-24 18:50 --- Subject: Bug 38118 Author: ro Date: Wed Mar 24 18:49:49 2010 New Revision: 157705 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157705 Log: * configure.ac (i[34567]86-*-*): Handle Solaris 2/x86 TLS support and Sun as TLS syntax. (TLS_SECTION_ASM_FLAG) [on_solaris !gas_flag]: Define. * configure: Regenerate. * config.in: Regenerate. * varasm.c (TLS_SECTION_ASM_FLAG): Define default. (default_elf_asm_named_section): Use it. * config/i386/i386.c (output_pic_addr_const): Lowercase @DTPOFF. (i386_output_dwarf_dtprel): Likewise. (output_addr_const_extra): Likewise. (output_pic_addr_const): Lowercase @GOTTPOFF. (output_addr_const_extra): Likewise. (output_pic_addr_const): Lowercase @GOTNTPOFF. (output_addr_const_extra): Likewise. (output_pic_addr_const): Lowercase @INDNTPOFF. (output_addr_const_extra): Likewise. (output_pic_addr_const): Lowercase @NTPOFF. (output_addr_const_extra): Likewise. (output_pic_addr_const): Lowercase @TPOFF. (output_addr_const_extra): Likewise. * config/i386/i386.md (*tls_global_dynamic_32_gnu): Lowercase @TLSGD. (*tls_global_dynamic_64): Likewise. (*tls_local_dynamic_base_32_gnu): Lowercase @TLSLDM. (*tls_local_dynamic_base_64): Lowercase @TLSLD. * defaults.h (TLS_COMMON_ASM_OP): Provide default. (ASM_OUTPUT_TLS_COMMON): Use it. * config/i386/sol2-gas.h (TLS_COMMON_ASM_OP): Undef. PR target/38118 * config.gcc (sparc*-*-solaris2*) [$gas=yes]: Add usegas.h to tm_file. * config/sparc/sol2.h (ASM_OUTPUT_ALIGNED_COMMON): Move ... * config/sol2.h (ASM_OUTPUT_ALIGNED_COMMON): ... here. * config/i386/sol2-10.h (ASM_OUTPUT_ALIGNED_COMMON): Redefine. * config/i386/sol2.h (TARGET_SUN_TLS): Redefine. Modified: trunk/gcc/ChangeLog trunk/gcc/config.gcc trunk/gcc/config.in trunk/gcc/config/i386/i386.c trunk/gcc/config/i386/i386.md trunk/gcc/config/i386/sol2-10.h trunk/gcc/config/i386/sol2-gas.h trunk/gcc/config/i386/sol2.h trunk/gcc/config/sol2.h trunk/gcc/config/sparc/sol2.h trunk/gcc/configure trunk/gcc/configure.ac trunk/gcc/defaults.h trunk/gcc/varasm.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38118
[Bug tree-optimization/42906] [4.5 Regression] Empty loop not removed
--- Comment #23 from hubicka at gcc dot gnu dot org 2010-03-24 19:02 --- Created an attachment (id=20188) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20188action=view) Patch in testing Hi, this is patch I am testing. I was also re-thinking the problem of redirecting BB with dead conditional to next useful postdominator (that is the fixed version of algorihm by shiller). I am not convinced we can pick random PHI argument here as Richard changed my original code looking for source of control dependent graph. The testcase would be something like BB1 with succesors BB2 and BB6 BB2 with succesors BB3 and BB4 BB3 and BB4 with succesors BB5 and BB6 containing PHI that is A from BB1 and B from BB3 or BB4 If we end up eliminating BB3 and BB4 and thus condition in BB3, we will redirect BB3 to BB5. The argument of PHI however must be updated to B for new edge, not A as we pick currently. I will try to create real world testcase and I think we can fix this by avoidiging the redirection. Cytron et al suggest using random edge leaving BB with dead conditional. This is wrong since it closes infinite loops. I think we can instead of that just pick random edge that is not loopback edge in DFS. That won't close loops and will result in acyclic reverse EBBS of empty blocks we easilly cleanup afterwards. Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42906
[Bug middle-end/42181] [4.5 Regression][graphite] -fgraphite-identity miscompiles air.f90
--- Comment #30 from spop at gcc dot gnu dot org 2010-03-24 20:17 --- Fixed. Please use ftp://gcc.gnu.org/pub/gcc/infrastructure/cloog-ppl-0.15.9.tar.gz -- spop at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42181
[Bug target/43498] No unwind info for thunks even with -fasynchronous-unwind-tables
--- Comment #11 from jakub at gcc dot gnu dot org 2010-03-24 20:31 --- Subject: Bug 43498 Author: jakub Date: Wed Mar 24 20:31:09 2010 New Revision: 157706 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157706 Log: PR target/43498 * config/i386/i386.c (x86_output_mi_thunk): Call final_start_function at the beginning and final_end_function at the end. * config/s390/s390.c (s390_output_mi_thunk): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/config/s390/s390.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43498
[Bug debug/43293] Invalid unwind info for i?86 -fpic
--- Comment #6 from jakub at gcc dot gnu dot org 2010-03-24 20:45 --- Subject: Bug 43293 Author: jakub Date: Wed Mar 24 20:44:48 2010 New Revision: 157707 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157707 Log: PR debug/43293 * target.h (struct gcc_target): Add code_end hook. * target-def.h (TARGET_ASM_CODE_END): Define to hook_void_void if not yet defined. (TARGET_ASM_OUT): Add TARGET_ASM_CODE_END. * toplev.c (compile_file): Call targetm.asm_out.code_end hook before unwind info/debug info output. * config/i386/winnt.c (i386_pe_file_end): Don't call ix86_file_end. * config/i386/linux.h (NEED_INDICATE_EXEC_STACK): Don't define. (TARGET_ASM_FILE_END): Define to file_end_indicate_exec_stack. * config/i386/linux64.h (NEED_INDICATE_EXEC_STACK): Don't define. (TARGET_ASM_FILE_END): Define to file_end_indicate_exec_stack. * config/i386/i386.c (ix86_file_end): Renamed to... (ix86_code_end): ... this. Make static. Don't call file_end_indicate_exec_stack. Emit unwind info using final_start_function/final_end_function. (darwin_x86_file_end): Remove. (TARGET_ASM_CODE_END): Define. * config/i386/i386.h (TARGET_ASM_FILE_END, NEED_INDICATE_EXEC_STACK): Don't define. * config/i386/darwin.h (darwin_x86_file_end): Remove prototype. (TARGET_ASM_FILE_END): Define to darwin_file_end. * config/i386/i386-protos.h (ix86_file_end): Remove prototype. * doc/tm.texi (TARGET_ASM_CODE_END): Document. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/darwin.h trunk/gcc/config/i386/i386-protos.h trunk/gcc/config/i386/i386.c trunk/gcc/config/i386/i386.h trunk/gcc/config/i386/linux.h trunk/gcc/config/i386/linux64.h trunk/gcc/config/i386/winnt.c trunk/gcc/doc/tm.texi trunk/gcc/target-def.h trunk/gcc/target.h trunk/gcc/toplev.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43293
[Bug target/43498] No unwind info for thunks even with -fasynchronous-unwind-tables
--- Comment #12 from jakub at gcc dot gnu dot org 2010-03-24 20:52 --- Should be fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43498
[Bug c/43385] [4.5 Regression] glibc regex testsuite failures
--- Comment #20 from jakub at gcc dot gnu dot org 2010-03-24 20:54 --- Thanks, will debug tomorrow. At least it is in gimple_boolify which is much shorter than the other changes... -- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|WAITING |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-03-24 20:54:40 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43385
[Bug middle-end/42777] [graphite] loop interchange heuristic is broken
--- Comment #1 from spop at gcc dot gnu dot org 2010-03-24 21:11 --- I don't think this is due to the interchange heuristic, it looks more like a missed vectorization problem after Graphite. Closing the bug. -- spop at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42777
[Bug target/43484] [4.5 Regression] GCC 4.5 does not build gamess, zeusmp on powerpc -m32 with loop unrolling
--- Comment #10 from meissner at gcc dot gnu dot org 2010-03-24 21:12 --- Patch checked in, subversion id 157709. -- meissner at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43484
[Bug target/42040] [ia64] Inappropriate address spills
--- Comment #14 from sje at cup dot hp dot com 2010-03-24 21:34 --- Well it looks like the big SPEC slowdowns were a glitch. The generated code is only slightly different and when I tried to reproduce the results I saw a slight speed up in mcf instead of a slowdown. I still got an overall slowdown in SPEC, but it was only 0.25%. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42040
[Bug middle-end/42181] [4.5 Regression][graphite] -fgraphite-identity miscompiles air.f90
--- Comment #31 from howarth at nitro dot med dot uc dot edu 2010-03-24 21:35 --- (In reply to comment #30) Fixed. Please use ftp://gcc.gnu.org/pub/gcc/infrastructure/cloog-ppl-0.15.9.tar.gz Shouldn't the required cloog-ppl version in configure be bumped from 0.15.5 to 0.15.9? #if CLOOG_VERSION_MAJOR != 0 || CLOOG_VERSION_MINOR != 15 || CLOOG_VERSION_REVISION 5 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42181
[Bug c/43385] [4.5 Regression] glibc regex testsuite failures
--- Comment #21 from jakub at gcc dot gnu dot org 2010-03-24 22:48 --- I guess we want to call gimple_boolify on the __builtin_expect argument only if it is (inside of the (long) cast) one of the handled cases (TRUTH_*_EXPR, comparisons), but not in the case it is neither of these - then the NE_EXPR around the __builtin_expect was really meant to be the comparison that needs to be boolified and nothing else. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43385
[Bug testsuite/42348] Syntax of dg-skip-if in two obj-c++ tests
--- Comment #10 from janis at gcc dot gnu dot org 2010-03-24 22:51 --- Subject: Bug 42348 Author: janis Date: Wed Mar 24 22:51:08 2010 New Revision: 157715 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157715 Log: 2010-03-24 Iain Sandoe iain.san...@sandoe-acoustics.co.uk PR testsuite/42348 * lib/target-supports.exp: Add support for ObjC/ObjC++ tools in standard tests. (check_effective_target_objc2): New proc. (check_effective_target_next_runtime): New proc. * lib/objc.exp: Determine which runtime is in force and support it. * lib/obj-c++.exp: Ditto. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/lib/obj-c++.exp trunk/gcc/testsuite/lib/objc.exp trunk/gcc/testsuite/lib/target-supports.exp -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42348
[Bug testsuite/41609] Torture tests do not check trivial.{m,mm} for each run case.
--- Comment #3 from janis at gcc dot gnu dot org 2010-03-24 22:53 --- Subject: Bug 41609 Author: janis Date: Wed Mar 24 22:52:47 2010 New Revision: 157716 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157716 Log: 2010-03-24 Iain Sandoe iain.san...@sandoe-acoustics.co.uk PR testsuite/41609 * lib/objc-torture.exp (objc-set-runtime-options): New. * objc/execute/execute.exp: Check runtime options on each pass. * objc/execute/exceptions/exceptions.exp: Ditto. * objc/compile/compile.exp: Ditto. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/lib/objc-torture.exp trunk/gcc/testsuite/objc/compile/compile.exp trunk/gcc/testsuite/objc/execute/exceptions/exceptions.exp trunk/gcc/testsuite/objc/execute/execute.exp -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41609
[Bug bootstrap/43511] New: [4.5 Regression] Configure error at stage 1 in i386/libgomp
Bootstrapping revision 157711 failed at stage 1 with: ... checking for shared libgcc... yes configure: WARNING: === You have requested some kind of symbol versioning, but configure: WARNING: === either you are not using a supported linker, or you are configure: WARNING: === not building a shared libgcc_s (which is required). configure: WARNING: === Symbol versioning will be disabled. checking whether the target supports .symver directive... no configure: versioning on shared library symbols is no checking whether the target supports __sync_*_compare_and_swap... yes configure: updating cache ./config.cache configure: error: unsupported system, cannot find sizeof (omp_lock_t) make[2]: *** [configure-stage1-target-libgomp] Error 1 make[1]: *** [stage1-bubble] Error 2 make: *** [all] Error 2 I'll attach the result of 'diff -up ./x86_64-apple-darwin10/libgomp/config.log ./x86_64-apple-darwin10/i386/libgomp/config.log'. This PR may be related to PR43287, the main difference is that the latter is intermittent while the former seems reproducible. -- Summary: [4.5 Regression] Configure error at stage 1 in i386/libgomp Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dominiq at lps dot ens dot fr GCC build triplet: x86_64-apple-darwin10 GCC host triplet: x86_64-apple-darwin10 GCC target triplet: x86_64-apple-darwin10 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43511
[Bug bootstrap/43511] [4.5 Regression] Configure error at stage 1 in i386/libgomp
--- Comment #1 from dominiq at lps dot ens dot fr 2010-03-24 23:23 --- Created an attachment (id=20189) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20189action=view) result of 'diff -up ./x86_64-apple-darwin10/libgomp/config.log ./x86_64-apple-darwin10/i386/libgomp/config.log' -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43511
[Bug bootstrap/43511] [4.5 Regression] Configure error at stage 1 in i386/libgomp
-- dominiq at lps dot ens dot fr changed: What|Removed |Added Severity|normal |blocker http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43511
[Bug c/43385] [4.5 Regression] glibc regex testsuite failures
--- Comment #22 from jakub at gcc dot gnu dot org 2010-03-24 23:41 --- Created an attachment (id=20190) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20190action=view) gcc45-pr43385.patch So far only very lightly tested fix. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43385
[Bug c/43385] [4.5 Regression] glibc regex testsuite failures
--- Comment #23 from jakub at gcc dot gnu dot org 2010-03-24 23:54 --- Created an attachment (id=20191) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20191action=view) gcc45-pr43385.patch Simpler version of the patch. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Attachment #20190|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43385
[Bug bootstrap/43511] [4.5 Regression] Configure error at stage 1 in i386/libgomp
--- Comment #2 from dominiq at lps dot ens dot fr 2010-03-25 00:08 --- I have forgotten to say that revision 157677 bootstrapped without problem. Also the failure occurs for both serial and parallel (-j2) bootstraps. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43511
