[Bug fortran/45532] gfortran namelist read error
--- Comment #1 from burnus at gcc dot gnu dot org 2010-09-04 07:35 --- CONFIRM. The program works with NAG, g95, ifort and prints 1. -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||jvdelisle at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||wrong-code Last reconfirmed|-00-00 00:00:00 |2010-09-04 07:35:23 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45532
[Bug tree-optimization/45533] New: Incorrect MEM_REF operand causes ICE.
/home/ramana/cross-build/arm-none-linux-gnueabi/obj/gcc2/gcc/cc1 -O2 ~/testcase.i Arch. specific configuration of GCC :--with-cpu=cortex-a9 --with-fpu=neon --with-float=softfp ./testcase.i: In function elf_machine_load_address: ./testcase.i:5254:38: warning: taking address of expression of type void [enabled by default] ./testcase.i: In function _dl_relocate_object: ./testcase.i:5432:1: error: Invalid first operand of MEM_REF. prephitmp.252_36 ./testcase.i:5432:1: note: in statement D.14709_176 = MEM[(const struct Elf32_Rel *)prephitmp.252_36 + 8B]; ./testcase.i:5432:1: error: Invalid first operand of MEM_REF. prephitmp.252_36 ./testcase.i:5432:1: note: in statement D.14712_1273 = MEM[(const struct Elf32_Rel *)prephitmp.252_36 + 8B]; ./testcase.i:5432:1: internal compiler error: verify_stmts failed Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. From a gdb session the pass that seems to have this problem with verification is ivopts. r163801 - works fine r163802 - starts ICE'ing. -- Summary: Incorrect MEM_REF operand causes ICE. Product: gcc Version: 4.6.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ramana at gcc dot gnu dot org GCC host triplet: x86_64-linux GCC target triplet: arm-none-linux-gnueabi http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45533
[Bug tree-optimization/45533] Incorrect MEM_REF operand causes ICE.
--- Comment #1 from ramana at gcc dot gnu dot org 2010-09-04 07:53 --- Created an attachment (id=21692) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21692action=view) Reduced testcase for ICE -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45533
[Bug tree-optimization/45533] Incorrect MEM_REF operand causes ICE.
--- Comment #2 from jakub at gcc dot gnu dot org 2010-09-04 08:01 --- *** This bug has been marked as a duplicate of 45519 *** -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE Summary| Incorrect MEM_REF operand |Incorrect MEM_REF operand |causes ICE. |causes ICE. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45533
[Bug bootstrap/45519] [4.6 regression] Failed to bootstrap
--- Comment #11 from jakub at gcc dot gnu dot org 2010-09-04 08:01 --- *** Bug 45533 has been marked as a duplicate of this bug. *** -- jakub at gcc dot gnu dot org changed: What|Removed |Added CC||ramana at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45519
[Bug fortran/45530] gfortran internal compiler error
--- Comment #1 from burnus at gcc dot gnu dot org 2010-09-04 08:14 --- CONFIRM. NAG prints: Error: nm2.f90, line 22: Namelist-group-object CURVE has a POINTER component -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||ice-on-invalid-code Last reconfirmed|-00-00 00:00:00 |2010-09-04 08:14:29 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45530
[Bug tree-optimization/45522] VRP misses oppurtunity for statement folding.
--- Comment #8 from rguenther at suse dot de 2010-09-04 08:29 --- Subject: Re: VRP misses oppurtunity for statement folding. On Fri, 3 Sep 2010, hubicka at gcc dot gnu dot org wrote: --- Comment #7 from hubicka at gcc dot gnu dot org 2010-09-03 20:28 --- In #5 the expression is created by PRE via create_expression_by_pieces that uses normal fold that is not able of constant variable folding. The statement does not get folded later and survives. I guess one can fold all statements in commit_edge_insertions but it seems by symptomatic? You need to enhance fully_constant_vn_reference_p. Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45522
[Bug target/45524] r163815/r163816 produces new regressions on x86_64-apple-darwin10
--- Comment #15 from bonzini at gnu dot org 2010-09-04 09:08 --- Please revert the patch in both gcc and src. It's clear that the way to go is to first write small patch to smooth out the nuances you pointed out, and then introduce the new macro in a way that doesn't change the semantics. Sorry for the spotty review. :/ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45524
[Bug fortran/45507] [4.6 Regression] Bogus Error: Can't convert TYPE(c_ptr) to INTEGER(4)
--- Comment #5 from janus at gcc dot gnu dot org 2010-09-04 09:29 --- Subject: Bug 45507 Author: janus Date: Sat Sep 4 09:29:11 2010 New Revision: 163856 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163856 Log: 2010-09-04 Janus Weil ja...@gcc.gnu.org PR fortran/45507 * resolve.c (resolve_allocate_expr): Generate default initializers already at this point, resolve them and put them into expr3, ... * trans-stmt.c (gfc_trans_allocate): ... instead of waiting until translation stage. 2010-09-04 Janus Weil ja...@gcc.gnu.org PR fortran/45507 * gfortran.dg/allocate_alloc_opt_12.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/allocate_alloc_opt_12.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/fortran/trans-stmt.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45507
[Bug fortran/45507] [4.6 Regression] Bogus Error: Can't convert TYPE(c_ptr) to INTEGER(4)
--- Comment #6 from janus at gcc dot gnu dot org 2010-09-04 09:31 --- Fixed with r163856. Closing. -- janus at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45507
[Bug bootstrap/45519] [4.6 regression] Failed to bootstrap
--- Comment #12 from rguenth at gcc dot gnu dot org 2010-09-04 09:34 --- Created an attachment (id=21693) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21693action=view) patch w/o typos... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45519
[Bug rtl-optimization/45223] RTL PRE GCSE pass hoists trapping insn out of loop
--- Comment #7 from ubizjak at gmail dot com 2010-09-04 10:03 --- Unassigning... -- ubizjak at gmail dot com changed: What|Removed |Added AssignedTo|ubizjak at gmail dot com|unassigned at gcc dot gnu ||dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45223
[Bug target/45524] r163815/r163816 produces new regressions on x86_64-apple-darwin10
--- Comment #16 from dominiq at lps dot ens dot fr 2010-09-04 10:16 --- Could someone check that revisions 163815 and 163816 are not exposing a more serious latent bug: I have configured gcc with --enable-decimal-float=no and --disable-decimal-float without disabling -decimal-float. Are these options working on linux? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45524
[Bug bootstrap/45519] [4.6 regression] Failed to bootstrap
--- Comment #13 from rguenth at gcc dot gnu dot org 2010-09-04 10:21 --- Subject: Bug 45519 Author: rguenth Date: Sat Sep 4 10:21:07 2010 New Revision: 163858 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163858 Log: 2010-09-04 Richard Guenther rguent...@suse.de PR bootstrap/45519 * tree-flow.h (force_gimple_operand_1): Declare. (force_gimple_operand_gsi_1): Likewise. * gimplify.c (force_gimple_operand_1): New worker taking a gimple predicate for ... (force_gimple_operand): ... which now wraps it. (force_gimple_operand_gsi_1, force_gimple_operand_gsi): Likewise. * tree-ssa-loop-ivopts.c (find_interesting_uses_address): Revert last change. * tree-ssa-address.c (gimplify_mem_ref_parts): Use force_gimple_operand_gsi_1 with is_gimple_mem_ref_addr. (create_mem_ref): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/gimplify.c trunk/gcc/tree-flow.h trunk/gcc/tree-ssa-address.c trunk/gcc/tree-ssa-loop-ivopts.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45519
[Bug bootstrap/45519] [4.6 regression] Failed to bootstrap
--- Comment #14 from rguenth at gcc dot gnu dot org 2010-09-04 10:21 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45519
[Bug target/45524] r163815/r163816 produces new regressions on x86_64-apple-darwin10
--- Comment #17 from joseph at codesourcery dot com 2010-09-04 11:05 --- Subject: Re: r163815/r163816 produces new regressions on x86_64-apple-darwin10 On Sat, 4 Sep 2010, bonzini at gnu dot org wrote: Please revert the patch in both gcc and src. It's clear that the way to go is to first write small patch to smooth out the nuances you pointed out, and then introduce the new macro in a way that doesn't change the semantics. Sorry for the spotty review. :/ Since the differences are generally deliberate, what's actually wanted is a macro that preserves them. The basic information of which targets support DFP by default / at all and what the default format is on each target should be in a single place. The information about whether $target or $host is relevant, and about what the configuration variables should be set to if DFP is disabled, should be passed as arguments to the macro. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45524
[Bug c/37985] [4.3/4.4/4.5/4.6 Regression] unsigned char shift lacks statement with no effect warning
--- Comment #8 from simartin at gcc dot gnu dot org 2010-09-04 11:34 --- This is due to http://gcc.gnu.org/ml/gcc-patches/2006-08/msg01041.html -- simartin at gcc dot gnu dot org changed: What|Removed |Added CC||simartin at gcc dot gnu dot ||org Last reconfirmed|2008-12-24 05:11:57 |2010-09-04 11:34:54 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37985
[Bug target/45524] r163815/r163816 produces new regressions on x86_64-apple-darwin10
--- Comment #18 from dominiq at lps dot ens dot fr 2010-09-04 11:51 --- See also http://gcc.gnu.org/ml/gcc-testresults/2010-09/msg00342.html for a non-darwin platform. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45524
[Bug middle-end/45534] New: [4.6 Regression] ICE in refs_may_alias_p_1, at tree-ssa-alias.c:1031
From revisions 163847 (163744 works) to 163859, I see the following ICEs with both -m32 and -m64 libgomp.graphite/force-parallel-3.c:5:6: internal compiler error: in refs_may_alias_p_1, at tree-ssa-alias.c:1031 libgomp.graphite/force-parallel-9.c:5:6: internal compiler error: in refs_may_alias_p_1, at tree-ssa-alias.c:1031 with -m64 -Os gfortran.dg/backspace_1.f:82:0: internal compiler error: in refs_may_alias_p_1, at tree-ssa-alias.c:1031 gfortran.dg/record_marker_2.f:83:0: internal compiler error: in refs_may_alias_p_1, at tree-ssa-alias.c:1031 libgomp.fortran/appendix-a/a.16.1.f90:26:0: internal compiler error: in refs_may_alias_p_1, at tree-ssa-alias.c:1031 libgomp.fortran/omp_atomic2.f90:35:0: internal compiler error: in refs_may_alias_p_1, at tree-ssa-alias.c:1031 and with -m64 -O2 -fgraphite-identity gfortran.dg/graphite/pr42393-1.f90:6:0: internal compiler error: in refs_may_alias_p_1, at tree-ssa-alias.c:1031 -- Summary: [4.6 Regression] ICE in refs_may_alias_p_1, at tree-ssa- alias.c:1031 Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end 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=45534
[Bug target/45524] r163815/r163816 produces new regressions on x86_64-apple-darwin10
--- Comment #19 from davek at gcc dot gnu dot org 2010-09-04 11:54 --- (In reply to comment #18) See also http://gcc.gnu.org/ml/gcc-testresults/2010-09/msg00342.html for a non-darwin platform. Yep, it's all the same kind of undefined symbol problems as in Jack's original description of the bug. I configured using plain --enable-decimal-float, I imagine that explicitly specifying --enable-decimal-float=bid would help. (Shall give it a try.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45524
[Bug target/45524] r163815/r163816 produces new regressions on x86_64-apple-darwin10
--- Comment #20 from davek at gcc dot gnu dot org 2010-09-04 11:57 --- (In reply to comment #19) (In reply to comment #18) See also http://gcc.gnu.org/ml/gcc-testresults/2010-09/msg00342.html for a non-darwin platform. Yep, it's all the same kind of undefined symbol problems as in Jack's original description of the bug. Note however that it's before the revision where this patch was applied, and wouldn't have shown up without my explictly adding the --enable option. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45524
[Bug middle-end/45534] [4.6 Regression] ICE in refs_may_alias_p_1, at tree-ssa-alias.c:1031
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45534
[Bug middle-end/45534] [4.6 Regression] ICE in refs_may_alias_p_1, at tree-ssa-alias.c:1031
-- iains at gcc dot gnu dot org changed: What|Removed |Added CC||iains at gcc dot gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-09-04 12:05:15 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45534
[Bug tree-optimization/45535] New: [4.6 regression] ICE during tree_ssa_dse
The attached testcase generates a segfault during alias analysis run as part of the DSE pass. Command line options: /scratch/rearnsha/gnu/gcc-eabi/git/gcc/cc1 -quiet -nostdinc -v -I /scratch/rearnsha/gnu/gcc-eabi/git/git-vfp-eabi-O3/linux-2.4.23-pre3-testplatform/include -I . -imultilib fpu -iprefix /scratch/rearnsha/gnu/gcc-eabi/git/gcc/../lib/gcc/arm-eabi/4.6.0/ -isystem /scratch/rearnsha/gnu/gcc-eabi/git/gcc/include -isystem /scratch/rearnsha/gnu/gcc-eabi/git/gcc/include-fixed -D__USES_INITFINI__ -D __linux__ -D __KERNEL__ -D CONFIG_ARCH_S390X -D CONFIG_ARCH_S390 -U __i386__ -U __x86_64__ -D KBUILD_BASENAME=memory -isystem /scratch/rearnsha/gnu/testinstall/arm-eabi/sys-include -iwithprefix include -quiet -dumpbase memory.c -mcpu=arm1136jf-s -marm -mfpu=vfp -mfloat-abi=hard -auxbase-strip memory.o -O3 -w -version -fno-short-enums -fno-strict-aliasing -fno-common -fomit-frame-pointer besttry.c Testcase is from CSiBE. -- Summary: [4.6 regression] ICE during tree_ssa_dse Product: gcc Version: 4.6.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rearnsha at gcc dot gnu dot org GCC target triplet: arm-eabi http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45535
[Bug tree-optimization/45535] [4.6 regression] ICE during tree_ssa_dse
--- Comment #1 from rearnsha at gcc dot gnu dot org 2010-09-04 12:24 --- Created an attachment (id=21694) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21694action=view) testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45535
[Bug target/45524] r163815/r163816 produces new regressions on x86_64-apple-darwin10
--- Comment #21 from howarth at nitro dot med dot uc dot edu 2010-09-04 13:08 --- Index: gcc/configure.ac === --- gcc/configure.ac(revision 163853) +++ gcc/configure.ac(working copy) @@ -608,10 +608,6 @@ # Enable C extension for decimal float if target supports it. GCC_AC_ENABLE_DECIMAL_FLOAT([$target]) -dfp=`if test $enable_decimal_float != no; then echo 1; else echo 0; fi` -AC_DEFINE_UNQUOTED(ENABLE_DECIMAL_FLOAT, $dfp, -[Define to 1 to enable decimal float extension to C.]) - bid=`if test $enable_decimal_float = bid; then echo 1; else echo 0; fi` AC_DEFINE_UNQUOTED(ENABLE_DECIMAL_BID_FORMAT, $bid, [Define to 1 to specify that we are using the BID decimal floating Index: config/dfp.m4 === --- config/dfp.m4 (revision 163853) +++ config/dfp.m4 (working copy) @@ -30,6 +30,10 @@ esac ]) + dfp=`if test $enable_decimal_float != no; then echo 1; else echo 0; fi` + AC_DEFINE_UNQUOTED(ENABLE_DECIMAL_FLOAT, $dfp, + [Define to 1 to enable decimal float extension to C.]) + # x86's use BID format instead of DPD case x$enable_decimal_float in xyes) @@ -50,4 +54,4 @@ esac AC_SUBST(enable_decimal_float) -]) \ No newline at end of file +]) which restore the original code sequencing, eliminates the decimal float failures on x86_64-apple-darwin10. However, I don't know what this does to linux due to the remaining differences being omitted. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45524
[Bug bootstrap/45518] [4.6 regression] bootstrap failure on sparc64-unknown-linux-gnu
--- Comment #3 from mikpe at it dot uu dot se 2010-09-04 13:38 --- Can you show us the complete configure options you used? I'm trying to build gcc-4.6 for sparc64-linux w/o --with-cpu=v8 (so it defaults to 64-bit mode) and I can't get past an error after stage1 where it tries to configure a 32-bit zlib but passes the wrong path to prev-gcc. -- mikpe at it dot uu dot se changed: What|Removed |Added CC||mikpe at it dot uu dot se http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45518
[Bug target/45524] r163815/r163816 produces new regressions on x86_64-apple-darwin10
--- Comment #22 from howarth at nitro dot med dot uc dot edu 2010-09-04 13:39 --- I should note that one probe I am using to monitor how this builds is what grep decimal_float config.log reports in the gcc, libdecnumber and libgcc build directories. Pre-r163815/r163816, on darwin this was.. enable_decimal_float='dpd' for gcc and libdecnumber but... decimal_float='no' enable_decimal_float='no' in the libgcc build directory. With the patch in comment 21, this is changed to... decimal_float='no' enable_decimal_float='dpd' Note that this compares to what we got in libgcc with r163815/r163816 of... decimal_float='yes' enable_decimal_float='dpd' -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45524
[Bug tree-optimization/45535] [4.6 regression] ICE during tree_ssa_dse
--- Comment #2 from rearnsha at gcc dot gnu dot org 2010-09-04 13:40 --- caused by svn+ssh://gcc.gnu.org/svn/gcc/tr...@163802 -- rearnsha at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45535
[Bug tree-optimization/45522] VRP misses oppurtunity for statement folding.
--- Comment #9 from hubicka at gcc dot gnu dot org 2010-09-04 13:51 --- Hi, thanks. In meantime I made tree-ssa-pre to fold statements it produces and it gets me to bootstrapland with sanity check in expr.c except for Ada (with the patches I sent so far) So it seems that I need to basically duplicate all logic for initializer folding from tree-ssa-ccp.c into this function, right? I guess it makes sense, but it is all quite ugly. On VN side, i wondered if we can retire more of expand this way. For example dojump knows that: a = b ror x; if (a != 0) can be folded into: if (b != 0) (ror is rotation). I guess we should do this kind of tricks in VN instead? Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45522
[Bug tree-optimization/45522] VRP misses oppurtunity for statement folding.
--- Comment #10 from rguenther at suse dot de 2010-09-04 14:11 --- Subject: Re: VRP misses oppurtunity for statement folding. On Sat, 4 Sep 2010, hubicka at gcc dot gnu dot org wrote: --- Comment #9 from hubicka at gcc dot gnu dot org 2010-09-04 13:51 --- Hi, thanks. In meantime I made tree-ssa-pre to fold statements it produces and it gets me to bootstrapland with sanity check in expr.c except for Ada (with the patches I sent so far) Well - that's a workaround and will cause us to miss PRE because we do not fold during translation of expressions. So I wouldn't go down that route. So it seems that I need to basically duplicate all logic for initializer folding from tree-ssa-ccp.c into this function, right? I guess it makes sense, but it is all quite ugly. Yes ;) On VN side, i wondered if we can retire more of expand this way. For example dojump knows that: a = b ror x; if (a != 0) can be folded into: if (b != 0) (ror is rotation). I guess we should do this kind of tricks in VN instead? Well ... it's not that easy (that's not CSE but tree-combining, so the specific thing would fit to forwprop). Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45522
[Bug tree-optimization/45535] [4.6 regression] ICE during tree_ssa_dse
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-09-04 14:12 --- I will have a look (seems I need to build a cross ...) -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-09-04 14:12:56 date|| Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45535
[Bug target/45524] r163815/r163816 produces new regressions on x86_64-apple-darwin10
--- Comment #23 from howarth at nitro dot med dot uc dot edu 2010-09-04 14:26 --- The patch in comment 21 seems to work on x86_64-unknown-linux-gnu for a stock build. Iin the libgcc build directory before and after the patch, I get... decimal_float='yes' enable_decimal_float='bid' -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45524
[Bug target/45524] r163815/r163816 produces new regressions on x86_64-apple-darwin10
--- Comment #24 from howarth at nitro dot med dot uc dot edu 2010-09-04 14:38 --- Created an attachment (id=21695) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21695action=view) Move definition of ENABLE_DECIMAL_FLOAT to 1 into config/dfp.m4. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45524
[Bug target/45524] r163815/r163816 produces new regressions on x86_64-apple-darwin10
--- Comment #25 from hjl dot tools at gmail dot com 2010-09-04 15:13 --- Created an attachment (id=21696) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21696action=view) A patch Please try this one. -- hjl dot tools at gmail dot com changed: What|Removed |Added Attachment #21695|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45524
[Bug target/45524] r163815/r163816 produces new regressions on x86_64-apple-darwin10
-- hjl dot tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-09-04 15:14:04 date|| Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45524
[Bug target/45524] r163815/r163816 produces new regressions on x86_64-apple-darwin10
--- Comment #26 from hjl dot tools at gmail dot com 2010-09-04 15:19 --- Created an attachment (id=21697) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21697action=view) A regenerated patch I really don't like autconf cache. -- hjl dot tools at gmail dot com changed: What|Removed |Added Attachment #21696|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45524
[Bug debug/45419] -fcompare-debug failure at -O3
--- Comment #15 from aoliva at gcc dot gnu dot org 2010-09-04 15:26 --- Got a patch -- aoliva at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |aoliva at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45419
[Bug debug/45408] -fcompare-debug failure with -O2 -ftree-vectorize -fno-var-tracking-assignments
--- Comment #4 from aoliva at gcc dot gnu dot org 2010-09-04 15:27 --- *** This bug has been marked as a duplicate of 45419 *** -- aoliva at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45408
[Bug debug/45419] -fcompare-debug failure at -O3
--- Comment #16 from aoliva at gcc dot gnu dot org 2010-09-04 15:27 --- *** Bug 45408 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45419
[Bug debug/45130] -fcompare-debug failure with -Os -fsched-spec-load -fschedule-insns
--- Comment #3 from aoliva at gcc dot gnu dot org 2010-09-04 15:28 --- *** This bug has been marked as a duplicate of 45136 *** -- aoliva at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45130
[Bug debug/45136] -fcompare-debug failure with -Os -fschedule-insns
--- Comment #8 from aoliva at gcc dot gnu dot org 2010-09-04 15:28 --- *** Bug 45130 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45136
[Bug target/45524] r163815/r163816 produces new regressions on x86_64-apple-darwin10
--- Comment #27 from howarth at nitro dot med dot uc dot edu 2010-09-04 15:44 --- Both patches fail on a x86_64-apple-darwin10 bootstrap with.. make[3]: *** No rule to make target `../../gcc-4.6-20100904/gcc/../libdecnumber/no/decimal32.h', needed by `dfp.o'. Stop -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45524
[Bug target/45524] r163815/r163816 produces new regressions on x86_64-apple-darwin10
--- Comment #28 from hjl dot tools at gmail dot com 2010-09-04 16:07 --- Created an attachment (id=21698) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21698action=view) A new patch Try this one. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45524
[Bug bootstrap/45067] [4.6 regression] ARM bootstrap failure: internal compiler error: in expand_widen_pattern_expr, at optabs.c:522
--- Comment #13 from mikpe at it dot uu dot se 2010-09-04 16:19 --- For the record, the original ICE in this PR was fixed by r162784: http://gcc.gnu.org/ml/gcc-cvs/2010-07/msg01138.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45067
[Bug target/45524] r163815/r163816 produces new regressions on x86_64-apple-darwin10
--- Comment #29 from howarth at nitro dot med dot uc dot edu 2010-09-04 16:32 --- (In reply to comment #28) Created an attachment (id=21698) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21698action=view) [edit] A new patch Try this one. This bootstraps. Regtesting next. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45524
[Bug target/45070] Miscompiled c++ class with packed attribute on ARM with -Os optimizations (Qt 4.6.2)
--- Comment #16 from armin76 at gentoo dot org 2010-09-04 16:41 --- I'd like it backported to 4.4 if possible, thanks -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45070
[Bug target/45524] r163815/r163816 produces new regressions on x86_64-apple-darwin10
--- Comment #30 from bonzini at gnu dot org 2010-09-04 16:41 --- It's clear that the way to go is to first write small patch to smooth out the nuances you pointed out, and then introduce the new macro in a way that doesn't change the semantics. Since the differences are generally deliberate, what's actually wanted is a macro that preserves them. Sure, I meant leaving the differences in semantics to the single configure scripts. This is what H.J.'s patch does more or less, and I like it. I'm not sure whether the patches remove the need for the other patch in comment #21 though. Jack, can you post what you are exactly testing (without the regenerated files, which are unnecessary)? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45524
[Bug fortran/45530] gfortran internal compiler error
--- Comment #2 from burnus at gcc dot gnu dot org 2010-09-04 16:43 --- The endless loop happens in derived_inaccessible - seemingly called by resolve_fl_namelist (all resolve.c); that check happens before the pointer-components check. Moving the PRIVATE/accessible check _after_ the pointer/allocatable components cures the issue. -- burnus at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |burnus at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2010-09-04 08:14:29 |2010-09-04 16:43:21 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45530
[Bug bootstrap/44970] [4.6 regression] Revision 162270 failed to bootstrap
-- bonzini at gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-09-04 16:46:13 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44970
[Bug bootstrap/44970] [4.6 regression] Revision 162270 failed to bootstrap
--- Comment #79 from bonzini at gnu dot org 2010-09-04 16:49 --- Created an attachment (id=21699) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21699action=view) incomplete patch This shows what I plan to do. It doesn't even compile stage2, so it is more or less useless. Still here it is. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44970
[Bug target/45524] r163815/r163816 produces new regressions on x86_64-apple-darwin10
--- Comment #31 from howarth at nitro dot med dot uc dot edu 2010-09-04 16:58 --- (In reply to comment #30) I'm not sure whether the patches remove the need for the other patch in comment #21 though. Jack, can you post what you are exactly testing (without the regenerated files, which are unnecessary)? Testing H.J.'s gcc-pr45524-3.patch as it is the first in his series which bootstraps on x86_64-apple-darwin10. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45524
[Bug c++/45536] New: gcc updates output timestamp even when compilation fails
When provided with a spurious header filename on the command line, gcc updates
the output file's timestamp even if compilation fails. Re-invoking make
consequently produces a message that the target is up to date. The target may
be a shared library or executable.
This problem was previously reported to binutils
(http://sourceware.org/bugzilla/show_bug.cgi?id=11977) and closed as invalid,
not a binutils bug.
Consider two files: ldtest.h (empty, not included), and ldtest.C:
$ cat ldtest.C
int
main( int argc, char *argv[] )
{
return 0;
}
Build it, ruin the source, build it (fails), build it again (succeeds):
$ make ldtest.borked
c++ -o ldtest.borked ldtest.C ldtest.h
$ make break
ldtest.C sed 's/return/r eturn/' ldtest.c
mv ldtest.c ldtest.C
$ make ldtest.borked
c++ -o ldtest.borked ldtest.C ldtest.h
ldtest.C: In function int main(int, char**):
ldtest.C:4: error: r was not declared in this scope
ldtest.C:4: error: expected `;' before eturn
make: *** [ldtest.borked] Error 1
$ make ldtest.borked
make: `ldtest.borked' is up to date.
$ stat ldtest.C ldtest.borked | grep -E 'ldtest|Change'
File: `ldtest.C'
Change: 2010-09-03 12:56:18.14013 -0400
File: `ldtest.borked'
Change: 2010-09-03 12:56:24.168658000 -0400
If ldtest.h is not on the command line, the binary is not updated:
$ make fix
ldtest.C sed 's/r eturn/return/' ldtest.c
mv ldtest.c ldtest.C
$ make ldtest
c++ -o ldtest ldtest.C
$ make break
ldtest.C sed 's/return/r eturn/' ldtest.c
mv ldtest.c ldtest.C
$ make ldtest
c++ -o ldtest ldtest.C
ldtest.C: In function int main(int, char**):
ldtest.C:4: error: r was not declared in this scope
ldtest.C:4: error: expected `;' before eturn
make: *** [ldtest] Error 1
$ make ldtest
c++ -o ldtest ldtest.C
ldtest.C: In function int main(int, char**):
ldtest.C:4: error: r was not declared in this scope
ldtest.C:4: error: expected `;' before eturn
make: *** [ldtest] Error 1
$ stat ldtest.C ldtest | grep -E 'ldtest|Change'
File: `ldtest.C'
Change: 2010-09-03 13:05:18.469643000 -0400
File: `ldtest'
Change: 2010-09-03 13:05:15.407893000 -0400
c++ -v doesn't show collect2 being invoked. The problem might be caused by
the way gcc invokes cc1plus. I wonder about --output-pch= ldtest, below:
$ c++ -o ldtest ldtest.C ldtest.h -v
Using built-in specs.
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-libgcj-multifile
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk
--disable-dssi --enable-plugin
--with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --with-cpu=generic
--host=x86_64-redhat-linux
Thread model: posix
gcc version 4.1.2 20080704 (Red Hat 4.1.2-44)
/usr/libexec/gcc/x86_64-redhat-linux/4.1.2/cc1plus -quiet -v -D_GNU_SOURCE
ldtest.C -quiet -dumpbase ldtest.C -mtune=generic -auxbase ldtest -version -o
/tmp/ccI315nM.s
ignoring nonexistent directory
/usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../x86_64-redhat-linux/include
#include ... search starts here:
#include ... search starts here:
/usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../include/c++/4.1.2
/usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../include/c++/4.1.2/x86_64-redhat-linux
/usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../include/c++/4.1.2/backward
/usr/local/include
/usr/lib/gcc/x86_64-redhat-linux/4.1.2/include
/usr/include
End of search list.
GNU C++ version 4.1.2 20080704 (Red Hat 4.1.2-44) (x86_64-redhat-linux)
compiled by GNU C version 4.1.2 20080704 (Red Hat 4.1.2-44).
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 2d02d8750f9b337bb19a7dd5b4e2167e
ldtest.C: In function int main(int, char**):
ldtest.C:4: error: r was not declared in this scope
ldtest.C:4: error: expected `;' before eturn
/usr/libexec/gcc/x86_64-redhat-linux/4.1.2/cc1plus -quiet -v -D_GNU_SOURCE
ldtest.h -quiet -dumpbase ldtest.h -mtune=generic -auxbase ldtest -version -o
/tmp/ccI315nM.s --output-pch= ldtest
ignoring nonexistent directory
/usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../x86_64-redhat-linux/include
#include ... search starts here:
#include ... search starts here:
/usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../include/c++/4.1.2
/usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../include/c++/4.1.2/x86_64-redhat-linux
/usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../include/c++/4.1.2/backward
/usr/local/include
/usr/lib/gcc/x86_64-redhat-linux/4.1.2/include
/usr/include
End of search list.
GNU C++ version 4.1.2 20080704 (Red Hat 4.1.2-44) (x86_64-redhat-linux)
compiled by GNU C version 4.1.2 20080704 (Red Hat 4.1.2-44).
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 2d02d8750f9b337bb19a7dd5b4e2167e
While
[Bug c++/45536] gcc updates output timestamp even when compilation fails
--- Comment #1 from hjl dot tools at gmail dot com 2010-09-04 17:24 --- Please provide a complete testcase, including Makefile. -- hjl dot tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45536
[Bug fortran/45530] gfortran internal compiler error
--- Comment #3 from burnus at gcc dot gnu dot org 2010-09-04 17:47 --- Subject: Bug 45530 Author: burnus Date: Sat Sep 4 17:47:02 2010 New Revision: 163862 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163862 Log: 2010-09-04 Tobias Burnus bur...@net-b.de PR fortran/45530 * resolve.c (resolve_fl_namelist): Change constraint checking order to prevent endless loop. 2010-09-04 Tobias Burnus bur...@net-b.de PR fortran/45530 * gfortran.dg/namelist_63.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/namelist_63.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45530
[Bug tree-optimization/45522] VRP misses oppurtunity for statement folding.
--- Comment #11 from hubicka at gcc dot gnu dot org 2010-09-04 18:00 --- Created an attachment (id=21700) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21700action=view) proposed fix for sccvn Well, this is patch I am currently testing. At least small part is shared in between tree-ssa-ccp (probably should go into gimple-fold) and VN. I am not sure how much of other initializer folding I need to borrow - i.e. folding of var_decl into its decl_initial, handling of component_refs and such. Also the tree-ssa-ccp code seems quite incomplette, it won't fold array with incomplette initializer for example because it won't find the matching item. Probably worth to fix. Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45522
[Bug target/45524] r163815/r163816 produces new regressions on x86_64-apple-darwin10
--- Comment #32 from howarth at nitro dot med dot uc dot edu 2010-09-04 18:12 --- I can confirm that gcc-pr45524-3.patch bootstraps and eliminates the regressions caused by r163815/r163816 on x86_64-apple-darwin10. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45524
[Bug target/42313] FAIL: gcc.target/i386/builtin-unreachable.c scan-assembler-not %e[bs]p on i686 darwin
--- Comment #8 from howarth at nitro dot med dot uc dot edu 2010-09-04
19:13 ---
(In reply to comment #7)
I fixed the test case to not expect the unimplemented optimization in r157197,
however, it would be nice to ensure the async signal handlers can handle
unaligned stacks and to perform this optimization. I'm fairly certain the
signal handers have to cope as code gen can do:
_h:
subl$12, %esp
movl$1, %eax
addl$12, %esp
ret
for int h () { return 1; } and certainly we can take a signal at _h+0, where
esp isn't aligned. Given that, we can omit sp alignments for leaf functions
(and no tail calls either), even on machines where otherwise an alignment is
required, as long as any variables on the stack are correctly aligned.
When this optimization is added, we can undo the r157197 change.
My proposed patch to fix PR36502...
http://gcc.gnu.org/ml/gcc-patches/2010-09/msg00237.html
that enables stack realignment on intel darwin also solves this PR as well.
Comparing the output from gcc trunk before and after my patch, I see...
--- builtin-unreachable.s 2010-09-04 15:12:40.0 -0400
+++ builtin-unreachable.trunk_patched 2010-09-04 15:02:45.0 -0400
@@ -3,11 +3,7 @@
.globl _h
_h:
LFB0:
- subl$12, %esp
-LCFI0:
movl$1, %eax
- addl$12, %esp
-LCFI1:
ret
LFE0:
.section
__TEXT,__eh_frame,coalesced,no_toc+strip_static_syms+live_support
@@ -39,16 +35,6 @@
.set L$set$2,LFE0-LFB0
.long L$set$2
.byte 0
- .byte 0x4
- .set L$set$3,LCFI0-LFB0
- .long L$set$3
- .byte 0xe
- .byte 0x10
- .byte 0x4
- .set L$set$4,LCFI1-LCFI0
- .long L$set$4
- .byte 0xe
- .byte 0x4
.align 2
LEFDE1:
.subsections_via_symbols
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42313
[Bug fortran/45019] Aliasing of TARGET dummy argument not detected correctly
--- Comment #13 from burnus at gcc dot gnu dot org 2010-09-04 19:21 --- Subject: Bug 45019 Author: burnus Date: Sat Sep 4 19:20:53 2010 New Revision: 163863 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163863 Log: 2010-09-04 Tobias Burnus bur...@net-b.de PR fortran/45019 * dependency.c (gfc_check_dependency): Add argument alising * check. * symbol.c (gfc_symbols_could_alias): Add argument alising * check. 2010-09-04 Tobias Burnus bur...@net-b.de PR fortran/45019 * gfortran.dg/aliasing_dummy_5.f90: New. Added: branches/gcc-4_5-branch/gcc/testsuite/gfortran.dg/aliasing_dummy_5.f90 Modified: branches/gcc-4_5-branch/gcc/fortran/ChangeLog branches/gcc-4_5-branch/gcc/fortran/dependency.c branches/gcc-4_5-branch/gcc/fortran/symbol.c branches/gcc-4_5-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45019
[Bug fortran/45019] Aliasing of TARGET dummy argument not detected correctly
--- Comment #14 from burnus at gcc dot gnu dot org 2010-09-04 19:21 --- FIXED. Thanks for the bugreport. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45019
[Bug fortran/45489] Default initialization of derived-type function result missing
--- Comment #5 from burnus at gcc dot gnu dot org 2010-09-04 19:25 --- Subject: Bug 45489 Author: burnus Date: Sat Sep 4 19:25:36 2010 New Revision: 163865 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163865 Log: 2010-09-04 Tobias Burnus bur...@net-b.de PR fortran/45489 * resolve.c (apply_default_init): Mark symbol as referenced, if it is initialized. (resolve_symbol): Change intialized check for BT_DERIVED such that also function results get initialized. 2010-09-04 Tobias Burnus bur...@net-b.de PR fortran/45489 * gfortran.dg/initialization_27.f90: New. Added: branches/gcc-4_5-branch/gcc/testsuite/gfortran.dg/initialization_27.f90 Modified: branches/gcc-4_5-branch/gcc/fortran/ChangeLog branches/gcc-4_5-branch/gcc/fortran/resolve.c branches/gcc-4_5-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45489
[Bug middle-end/45508] Does adding configure-options for specs-hardcoding make sense?
--- Comment #5 from nicolai dot stange at zmaw dot de 2010-09-04 19:31 --- (In reply to comment #4) The problem with the configure is the libgcc specs are very target dependent. Yes, and that's the reason why I think that others might benefit from those configure-options. Another remark that I forgot in my first post: There's already an --with-specs option that sets some specs for something (I don't know for what exactly, but it can't be used to set link options, I already tried it: Some other tools complain about unknown options). If your concern is about the work, not about the additional complexicity: I would do the work to add those options, just tell me - For which specs I should do it (all or just link_libgcc) - How do you want the CPP-Macros for the values of the configure-options to be named? - Should those values override or be appended/prepended to the platform-specific default-specs? * If appended/prepended: How do you want the CPP-macro for the concatenated, final spec string to be named? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45508
[Bug pch/45536] PCH uses -o file even when there are other arguments
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-09-04 19:31 --- The problem is the specs is producing the output file for the PCH. [andrew-pinskis-computer:~] apinski% file t.out t.out: GCC precompiled header (version 013) for C Related to PR 33980. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c++ |pch GCC build triplet|elf_x86_64 | GCC host triplet|elf_x86_64 | GCC target triplet|elf_x86_64 | Summary|gcc updates output timestamp|PCH uses -o file even when |even when compilation fails |there are other arguments http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45536
[Bug pch/45536] PCH uses -o file even when there are other arguments
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-09-04 19:32 --- This has enough information to reproduce the bug. Thanks again for the testcase. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-09-04 19:32:11 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45536
[Bug pch/45536] PCH uses -o file even when there are other arguments
--- Comment #4 from pinskia at gcc dot gnu dot org 2010-09-04 19:33 --- (In reply to comment #1) Please provide a complete testcase, including Makefile. The description has enough information to produce the issue. The driver is producing a PCH and an executable with the same output filename. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45536
[Bug fortran/45530] gfortran internal compiler error
--- Comment #4 from burnus at gcc dot gnu dot org 2010-09-04 19:37 --- Subject: Bug 45530 Author: burnus Date: Sat Sep 4 19:36:47 2010 New Revision: 163866 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163866 Log: 2010-09-04 Tobias Burnus bur...@net-b.de PR fortran/45530 * resolve.c (resolve_fl_namelist): Change constraint checking order to prevent endless loop. 2010-09-04 Tobias Burnus bur...@net-b.de PR fortran/45530 * gfortran.dg/namelist_63.f90: New. Added: branches/gcc-4_5-branch/gcc/testsuite/gfortran.dg/namelist_63.f90 Modified: branches/gcc-4_5-branch/gcc/fortran/ChangeLog branches/gcc-4_5-branch/gcc/fortran/resolve.c branches/gcc-4_5-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45530
[Bug libstdc++/45537] New: [c++0x] reject valid? no matching function for call to 'make_pair(void*, int)'
% cat t.cpp
#include utility
void test()
{
void* p = 0;
int i = 0;
std::make_pair void*, int ( p, i );
}
% make
/local/devel/toolchain45/x86_64-gnu-linux.mt_alloc/bin/x86_64-gnu-linux-g++
t.cpp -c -std=gnu++0x -o /dev/null
t.cpp: In function 'void test()':
t.cpp:6:37: error: no matching function for call to 'make_pair(void*, int)'
btw. comeau accepts this code.
--
Summary: [c++0x] reject valid? no matching function for call to
'make_pair(void*, int)'
Product: gcc
Version: 4.5.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pluto at agmk dot net
GCC build triplet: x86_64-gnu-linux
GCC host triplet: x86_64-gnu-linux
GCC target triplet: x86_64-gnu-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45537
[Bug testsuite/43957] [4.6 Regression] FAIL: gcc.dg/const-uniq-1.c scan-tree-dump-times gimple LC0 2
--- Comment #4 from danglin at gcc dot gnu dot org 2010-09-04 19:40 --- Subject: Bug 43957 Author: danglin Date: Sat Sep 4 19:40:07 2010 New Revision: 163867 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163867 Log: PR testsuite/43957 * gcc.dg/const-uniq-1.c: Modify regexp. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/const-uniq-1.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43957
[Bug libstdc++/43785] [C++0x] std::make_pair vs explicit template arguments
--- Comment #20 from pinskia at gcc dot gnu dot org 2010-09-04 19:41 --- *** Bug 45537 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pluto at agmk dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43785
[Bug libstdc++/45537] [c++0x] reject valid? no matching function for call to 'make_pair(void*, int)'
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-09-04 19:41 --- std::make_pair void*, int takes rvalue references which cannot bind to lvalues. See the discussion in PR 43785. *** This bug has been marked as a duplicate of 43785 *** -- 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=45537
[Bug testsuite/43957] [4.6 Regression] FAIL: gcc.dg/const-uniq-1.c scan-tree-dump-times gimple LC0 2
--- Comment #5 from danglin at gcc dot gnu dot org 2010-09-04 19:46 --- Fixed. -- danglin at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43957
[Bug fortran/45489] Default initialization of derived-type function result missing
--- Comment #6 from burnus at gcc dot gnu dot org 2010-09-04 19:48 --- FIXED. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45489
[Bug fortran/45530] gfortran internal compiler error
--- Comment #5 from burnus at gcc dot gnu dot org 2010-09-04 19:49 --- FIXED on the trunk (4.6) and on the 4.5 branch. Thanks for the bug report! -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45530
[Bug testsuite/44651] gcc.target/x86_64/abi/callabi/leaf-[1,2].c fail on darwin
--- Comment #5 from howarth at nitro dot med dot uc dot edu 2010-09-04 20:28 --- My proposed patch to fix PR36502... http://gcc.gnu.org/ml/gcc-patches/2010-09/msg00237.html also fixes this regression as can be since from the diff of leaf.s generated with gcc trunk before and after applying my patch... --- leaf-1.s2010-09-04 16:26:13.0 -0400 +++ leaf-1.s.patched_trunk 2010-09-04 16:24:35.0 -0400 @@ -3,11 +3,7 @@ .globl _foo _foo: LFB0: - subq$8, %rsp -LCFI0: xorl%eax, %eax - addq$8, %rsp -LCFI1: ret LFE0: .section __TEXT,__eh_frame,coalesced,no_toc+strip_static_syms+live_support @@ -39,16 +35,6 @@ .set L$set$2,LFE0-LFB0 .quad L$set$2 .byte 0 - .byte 0x4 - .set L$set$3,LCFI0-LFB0 - .long L$set$3 - .byte 0xe - .byte 0x10 - .byte 0x4 - .set L$set$4,LCFI1-LCFI0 - .long L$set$4 - .byte 0xe - .byte 0x8 .align 3 LEFDE1: .subsections_via_symbols -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44651
[Bug lto/45375] [meta-bug] Mozilla does not build with LTO
--- Comment #5 from hubicka at gcc dot gnu dot org 2010-09-04 20:39 --- Oprofile of WHOPR build. It is quite suprrising how low the usual cpu hogs shows.. 1139097.6329 lto1 lto1 htab_find_slot_with_hash 42787 2.8671 libc-2.11.1.so libc-2.11.1.so _int_malloc 36514 2.4468 lto1 lto1 iterative_hash_hashval_t 36289 2.4317 libelf.so.0.8.12 libelf.so.0.8.12 /usr/lib64/libelf.so.0.8.12 28366 1.9008 lto1 lto1 htab_expand 27648 1.8527 libc-2.11.1.so libc-2.11.1.so memset 27045 1.8123 lto1 lto1 cgraph_edge_badness 26670 1.7871 lto1 lto1 inflate_fast 25955 1.7392 lto1 lto1 lto_input_tree 20010 1.3408 lto1 lto1 lto_input_uleb128 18853 1.2633 lto1 lto1 bitmap_set_bit 16452 1.1024 as as /usr/bin/as 16215 1.0865 lto1 lto1 lto_input_1_unsigned 16141 1.0816 lto1 lto1 lto_output_1_stream 15244 1.0215 libc-2.11.1.so libc-2.11.1.so memcpy 15241 1.0213 lto1 lto1 htab_hash_string 13806 0.9251 lto1 lto1 record_reg_classes.constprop.10 13743 0.9209 lto1 lto1 lto_output_tree 13220 0.8859 lto1 lto1 ggc_internal_alloc_stat 12879 0.8630 libc-2.11.1.so libc-2.11.1.so malloc_consolidate 12847 0.8609 libc-2.11.1.so libc-2.11.1.so _int_free 11712 0.7848 lto1 lto1 lto_streamer_cache_insert_1 11593 0.7768 lto1 lto1 linemap_lookup 11100 0.7438 lto1 lto1 ht_lookup_with_hash 10837 0.7262 lto1 lto1 gtc_visit 10460 0.7009 lto1 lto1 cgraph_estimate_growth 10438 0.6994 lto1 lto1 value_member 9812 0.6575 lto1 lto1 walk_tree_1 9316 0.6243 oprofiledoprofiled /usr/bin/oprofiled 8979 0.6017 libc-2.11.1.so libc-2.11.1.so malloc 8825 0.5914 libc-2.11.1.so libc-2.11.1.so free 8625 0.5780 lto1 lto1 pointer_set_insert 8304 0.5564 lto1 lto1 ggc_set_mark 8276 0.5546 lto1 lto1 type_pair_eq 8089 0.5420 lto1 lto1 gimple_types_compatible_p_1 7981 0.5348 lto1 lto1 lto_output_uleb128_stream 7388 0.4951 lto1 lto1 df_note_compute 7349 0.4924 lto1 lto1 operand_equal_p 7349 0.4924 lto1 lto1 pointer_map_contains 7117 0.4769 lto1 lto1 bitmap_bit_p 7067 0.4736 lto1 lto1 pool_alloc 7030 0.4711 lto1 lto1 verify_cgraph_node 6954 0.4660 lto1 lto1 lto_input_sleb128 6947 0.4655 lto1 lto1 gt_ggc_mx_lang_tree_node 6747 0.4521 libc-2.11.1.so libc-2.11.1.so calloc 6403 0.4291 lto1 lto1 htab_delete 6360 0.4262 lto1 lto1 constrain_operands.part.12 6198 0.4153 lto1 lto1 bitmap_clear_bit 6103 0.4090 lto1 lto1 cse_insn -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
[Bug target/36502] i386/darwin generates unnecessary stack ops in every function
--- Comment #42 from howarth at nitro dot med dot uc dot edu 2010-09-04 20:39 --- Posted final version of proposed patch to... http://gcc.gnu.org/ml/gcc-patches/2010-09/msg00237.html This patch also fixes PR42313 and PR44651 as yet another added bonus. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36502
[Bug target/42313] FAIL: gcc.target/i386/builtin-unreachable.c scan-assembler-not %e[bs]p on i686 darwin
--- Comment #9 from howarth at nitro dot med dot uc dot edu 2010-09-04 21:20 --- Updated patch to reflect the wider coverage of PRs fixed... http://gcc.gnu.org/ml/gcc-patches/2010-09/msg00365.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42313
[Bug target/44651] gcc.target/x86_64/abi/callabi/leaf-[1,2].c fail on darwin
--- Comment #6 from howarth at nitro dot med dot uc dot edu 2010-09-04 21:20 --- Updated patch to reflect the wider coverage of PRs fixed... http://gcc.gnu.org/ml/gcc-patches/2010-09/msg00365.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44651
[Bug target/36502] i386/darwin generates unnecessary stack ops in every function
--- Comment #43 from howarth at nitro dot med dot uc dot edu 2010-09-04 21:21 --- Updated patch to reflect the wider coverage of PRs fixed... http://gcc.gnu.org/ml/gcc-patches/2010-09/msg00365.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36502
[Bug fortran/34145] single_char_string.f90 fails with -fdefault-integer-8
-- tkoenig at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |tkoenig at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2007-11-21 12:25:42 |2010-09-04 23:26:31 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34145
[Bug bootstrap/45518] [4.6 regression] bootstrap failure on sparc64-unknown-linux-gnu
--- Comment #4 from froydnj at codesourcery dot com 2010-09-05 01:38
---
Subject: Re: [4.6 regression] bootstrap failure on
sparc64-unknown-linux-gnu
On Sat, Sep 04, 2010 at 01:38:34PM -, mikpe at it dot uu dot se wrote:
Can you show us the complete configure options you used?
gcc63 is down at the moment for scheduled maintenance, so I can't quote
exactly. As best I can recall, it was:
CC='gcc -m64' /path/to/configure --disable-lib{mudflap,ssp,gomp} \
--enable-languages=c --disable-nls --enable-threads=posix \
--with-mpfr=/opt/cfarm/mpfr-2.4.1-64 \
--with-gmp=/opt/cfarm/gmp-4.2.4-64 --with-mpc=/opt/cfarm/mpc-0.8-64
The --with-* options are specific to compile farm machines.
I talked to Bernd and he had some suggestions for figuring out exactly
what gets miscompiled; due to gcc63 downtime, I haven't had a change to
try those yet.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45518
[Bug target/45524] r163815/r163816 produces new regressions on x86_64-apple-darwin10
--- Comment #33 from hjl dot tools at gmail dot com 2010-09-05 03:22 --- A patch is posted at http://gcc.gnu.org/ml/gcc-patches/2010-09/msg00375.html -- hjl dot tools at gmail dot com changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2010- ||09/msg00375.html http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45524
[Bug bootstrap/45538] New: --enable-build-with-cxx compiling gcc/libcpp/charset.c
Current gcc trunk no longer bootstraps with --enable-build-with-cxx on x86_64-apple-darwin10. The build fails at... config.status: executing depdir commands mkdir .deps g++ -I../../gcc/libcpp -I. -I../../gcc/libcpp/../include -I../../gcc/libcpp/include -g -W -Wall -Wwrite-strings -Wmissing-format-attribute -pedantic -Wno-long-long -I../../gcc/libcpp -I. -I../../gcc/libcpp/../include -I../../gcc/libcpp/include -c -o charset.o -MT charset.o -MMD -MP -MF .deps/charset.Tpo ../../gcc/libcpp/charset.c In file included from ../../gcc/libcpp/charset.c:22: ../../gcc/libcpp/system.h:260:21: warning: libintl.h: No such file or directory In file included from ../../gcc/libcpp/system.h:30, from ../../gcc/libcpp/charset.c:22: /usr/lib/gcc/i686-apple-darwin10/4.2.1/include/stddef.h:152: error: multiple types in one declaration /usr/lib/gcc/i686-apple-darwin10/4.2.1/include/stddef.h:152: error: declaration does not declare anything make[3]: *** [charset.o] Error 1 make[2]: *** [all-stage1-libcpp] Error 2 make[1]: *** [stage1-bubble] Error 2 make: *** [all] Error 2 when the build is configured as... ../gcc/configure --prefix=/Users/howarth/dist --with-gmp=/sw --with-libiconv-prefix=/sw --with-ppl=/sw --with-cloog=/sw --with-mpc=/sw --with-system-zlib --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib --enable-checking=yes --enable-languages=c,c++ --enable-build-with-cxx -- Summary: --enable-build-with-cxx compiling gcc/libcpp/charset.c Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: howarth at nitro dot med dot uc dot edu 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=45538
[Bug bootstrap/45538] --enable-build-with-cxx compiling gcc/libcpp/charset.c
--- Comment #1 from howarth at nitro dot med dot uc dot edu 2010-09-05 04:46 --- Created an attachment (id=21701) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21701action=view) failed bootstrap log on x86_64-apple-darwin10 with --enable-build-with-cxx -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45538
[Bug target/45524] r163815/r163816 produces new regressions on x86_64-apple-darwin10
--- Comment #34 from howarth at nitro dot med dot uc dot edu 2010-09-05 04:57 --- Regression result for gcc-pr45524-3.patch on x86_64-apple-darwin10. http://gcc.gnu.org/ml/gcc-testresults/2010-09/msg00410.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45524
[Bug bootstrap/45538] --enable-build-with-cxx compiling gcc/libcpp/charset.c
--- Comment #2 from howarth at nitro dot med dot uc dot edu 2010-09-05 05:40 --- The same bootstrap failure occurs on x86_64 Fedora 10 with... ../gcc/configure --with-gmp=/usr --with-mpfr=/usr --with-mpc=/usr --prefix=/home/howarth/dist --enable-languages=c,c++ --enable-build-with-cxx which fails with... g++ -I../../gcc/libcpp -I. -I../../gcc/libcpp/../include -I../../gcc/libcpp/include -g -W -Wall -Wwrite-strings -Wmissing-format-attribute -pedantic -Wno-long-long -I../../gcc/libcpp -I. -I../../gcc/libcpp/../include -I../../gcc/libcpp/include -c -o charset.o -MT charset.o -MMD -MP -MF .deps/charset.Tpo ../../gcc/libcpp/charset.c In file included from ../../gcc/libcpp/system.h:30, from ../../gcc/libcpp/charset.c:22: /usr/lib/gcc/x86_64-redhat-linux/4.3.2/include/stddef.h:152: error: multiple types in one declaration /usr/lib/gcc/x86_64-redhat-linux/4.3.2/include/stddef.h:152: error: declaration does not declare anything -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45538
