[Bug tree-optimization/51362] [4.7 Regression] ICE: SIGFPE (division by zero) in good_cloning_opportunity_p at ipa-cp.c:2401
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51362 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-12-07 CC||jakub at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #1 from Jakub Jelinek 2011-12-07 08:26:52 UTC --- This isn't dup of PR50744, it ICEs even with the PR50744 patch. But with the patch on the assert that size_cost is non-zero, rather than because of dividing by zero.
[Bug tree-optimization/51362] [4.7 Regression] ICE: SIGFPE (division by zero) in good_cloning_opportunity_p at ipa-cp.c:2401
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51362 Jakub Jelinek changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #2 from Jakub Jelinek 2011-12-07 08:27:26 UTC --- *** Bug 51439 has been marked as a duplicate of this bug. ***
[Bug middle-end/51439] [4.7 Regression] ICE(SIGFPE) in good_cloning_opportunity_p
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51439 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED CC||jakub at gcc dot gnu.org Resolution||DUPLICATE --- Comment #4 from Jakub Jelinek 2011-12-07 08:27:26 UTC --- IMNSHO dup of PR51362. *** This bug has been marked as a duplicate of bug 51362 ***
[Bug bootstrap/50686] [4.7 regression] IRIX 6.5 bootstrap failure: ICE in in lookup_cfa_1, at dwarf2cfi.c:595
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50686 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #21 from Jakub Jelinek 2011-12-07 09:00:47 UTC --- Can't reproduce that with x86_64-linux x mips-sgi-irix6.5 cross and current trunk.
[Bug bootstrap/50686] [4.7 regression] IRIX 6.5 bootstrap failure: ICE in in lookup_cfa_1, at dwarf2cfi.c:595
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50686 --- Comment #22 from ro at CeBiTec dot Uni-Bielefeld.DE 2011-12-07 09:08:41 UTC --- > --- Comment #21 from Jakub Jelinek 2011-12-07 > 09:00:47 UTC --- > Can't reproduce that with x86_64-linux x mips-sgi-irix6.5 cross and current > trunk. As I mentioned, it reproduces in an i386-solaris x mips-sgi-irix6.5 cross and natively as of r182060. Could you try an i686-linux cross? I'm not yet set up for that. Thanks. Rainer
[Bug bootstrap/50686] [4.7 regression] IRIX 6.5 bootstrap failure: ICE in in lookup_cfa_1, at dwarf2cfi.c:595
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50686 --- Comment #23 from Jakub Jelinek 2011-12-07 09:21:16 UTC --- Can't reproduce with i686-linux x mips-sgi-irix6.5 cross either.
[Bug c++/51318] [4.7 Regression] segfault on Eigen3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51318 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #8 from Jakub Jelinek 2011-12-07 09:29:29 UTC --- Started with http://gcc.gnu.org/viewcvs?view=revision&revision=181174, i.e. PR50835, in particular reverting the lvalue_kind change makes the ICE go away.
[Bug c/51441] Incorrect FP rounding on addition of doubles
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51441 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jakub at gcc dot gnu.org Resolution||INVALID --- Comment #5 from Jakub Jelinek 2011-12-07 09:35:16 UTC --- Invalid.
[Bug ada/51307] [4.7 Regression] s-taprop.adb:676:25: "CLOCK_RT_Ada" not declared in "OS_Constants"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51307 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P4 CC||jakub at gcc dot gnu.org
[Bug ada/48835] Porting GNAT to GNU/Linux/m68k
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48835 --- Comment #42 from Mikael Pettersson 2011-12-07 09:58:17 UTC --- (In reply to comment #41) > I'll continue to bisect and test with r162897 reverted. With r162897 reverted subsequent gcc-4.6 snapshots up to the 4.6.2 release bootstrap fine with Ada enabled and a few patches applied, specifically: 1. revert the core of r162897 (original has a few harmless failing hunks) 2. backport of pr43804 fix 3. backport of pr47612 fix which also fixes pr48554 4. the m68k-ada patch as posted here earlier 5. backport r178834 cfgcleanup HAVE_cc0 fix (will also be in 4.6.3) Note I'm not applying the insv fragment of r171341 any more. I saw some test suite regressions from 4.6 with it applied so I've dropped it. However, meanwhile 4.7 has broken. 4.7-20110730 builds fine as a cross, but every snapshot from 20110806 to 20111203 ICE as follows: /tmp/objdir/./gcc/xgcc -B/tmp/objdir/./gcc/ -B/home/mikpe/pkgs/linux-x86/cross-m68k/m68k-unknown-linux/bin/ -B/home/mikpe/pkgs/linux-x86/cross-m68k/m68k-unknown-linux/lib/ -isystem /home/mikpe/pkgs/linux-x86/cross-m68k/m68k-unknown-linux/include -isystem /home/mikpe/pkgs/linux-x86/cross-m68k/m68k-unknown-linux/sys-include-c -g -O2 -W -Wall -gnatpg -nostdinc a-assert.adb -o a-assert.o +===GNAT BUG DETECTED==+ | 4.7.0 20111203 (experimental) (m68k-unknown-linux) GCC error:| | in fp_size_to_prec, at ada/gcc-interface/misc.c:781 | | Error detected around :0 | So now I'm bisecting trunk to identify the cause of this regression.
[Bug middle-end/40154] [4.4/4.5/4.6/4.7 Regression] internal compiler error: in do_SUBST, at combine.c:681
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40154 --- Comment #5 from Jorn Wolfgang Rennecke 2011-12-07 10:17:53 UTC --- Actually, it is not enough to ensure that the mode matches; we must ensure that the SET_DEST of the insn we attach the note to is set to the value.
[Bug tree-optimization/50744] [4.7 Regression] ice in good_cloning_opportunity_p
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50744 --- Comment #7 from Martin Jambor 2011-12-07 10:30:55 UTC --- Author: jamborm Date: Wed Dec 7 10:30:49 2011 New Revision: 182076 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=182076 Log: 2011-12-07 Martin Jambor PR tree-optimization/50744 * ipa-cp.c (good_cloning_opportunity_p): Assert size_cost is positive, compute evaluation in HOST_WIDEST_INT. (safe_add): New function (propagate_effects): Use safe_add to accumulate effects. * testsuite/gcc.dg/ipa/pr50744.c: New test. Added: trunk/gcc/testsuite/gcc.dg/ipa/pr50744.c Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-cp.c trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/50744] [4.7 Regression] ice in good_cloning_opportunity_p
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50744 Martin Jambor changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #8 from Martin Jambor 2011-12-07 10:36:48 UTC --- Fixed.
[Bug tree-optimization/51362] [4.7 Regression] ICE: SIGFPE (division by zero) in good_cloning_opportunity_p at ipa-cp.c:2401
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51362 Martin Jambor changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |jamborm at gcc dot gnu.org |gnu.org | --- Comment #3 from Martin Jambor 2011-12-07 10:39:41 UTC --- Mine.
[Bug libfortran/51448] New: Compiler crash when assigning floating point values of different kinds
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51448 Bug #: 51448 Summary: Compiler crash when assigning floating point values of different kinds Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: francois.wil...@cmm.ensmp.fr $ gfortran --version GNU Fortran (Ubuntu/Linaro 4.6.1-9ubuntu3) 4.6.1 $ cat 1.f90 PROGRAM MAIN IMPLICIT NONE TYPE mytype REAL b(2) END TYPE mytype TYPE(mytype) a DOUBLE PRECISION, ALLOCATABLE :: x(:) ALLOCATE(x(2)) a%b=0.0E0 x=a%b END $ gfortran -O0 1.f90 1.f90: In function ‘MAIN__’: 1.f90:10:0: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. The program won't crash when "x=REAL(a%b, KIND(0.0D0))" instead of "x=a%b". OS: Linux Mint 12, gfortran preinstalled package.
[Bug middle-end/51442] volatile bitfields broken on arm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51442 --- Comment #3 from Richard Earnshaw 2011-12-07 10:55:17 UTC --- (In reply to comment #2) > Created attachment 26010 [details] > Only use BLKmode for volatile accesses which are not naturally aligned. > > Per Julian Brown's original email at > http://gcc.gnu.org/ml/gcc-patches/2011-03/msg01477.html: > > gcc/ > * expr.c (expand_expr_real_1): Only use BLKmode for volatile > accesses which are not naturally aligned. If this patch is backported then so must: http://gcc.gnu.org/ml/gcc-patches/2011-11/msg01390.html
[Bug libffi/50051] MIPS libffi does not compile for mips64octeon-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50051 Anthony Green changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011-12-07 CC||green at redhat dot com Ever Confirmed|0 |1 --- Comment #3 from Anthony Green 2011-12-07 11:00:05 UTC --- (In reply to comment #2) > Simple fix which works for me: > Index: src/mips/n32.S > === > --- src/mips/n32.S(revision 177681) > +++ src/mips/n32.S(working copy) > @@ -43,6 +43,7 @@ > #ifdef __GNUC__ > .abicalls > #endif > +.set mips4 > .text > .align2 > .globlffi_call_N32 Thanks Andrew. Does this force the generation of FP instructions, which are then emulated through OS traps? AG
[Bug ada/48835] Porting GNAT to GNU/Linux/m68k
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48835 --- Comment #43 from Andreas Schwab 2011-12-07 11:07:16 UTC --- What is the argument of fp_size_to_prec here?
[Bug libfortran/51448] [4.6/4.7 Regression] Compiler crash when assigning floating point values of different kinds
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51448 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-12-07 Summary|Compiler crash when |[4.6/4.7 Regression] |assigning floating point|Compiler crash when |values of different kinds |assigning floating point ||values of different kinds Ever Confirmed|0 |1 --- Comment #1 from Dominique d'Humieres 2011-12-07 11:10:31 UTC --- r167173 is OK r167380 gives a segmentation fault. The backtrace for trunk revision 181881 (x86_64-apple-darwin10) gives Program received signal SIGSEGV, Segmentation fault. 0x0001000b6c0c in get_std_lbound (expr=0x141b15210, desc=0x142929d20, dim=0, assumed_size=false) at ../../p_work/gcc/fortran/trans-array.c:7401 7401 if (GFC_DESCRIPTOR_TYPE_P (TREE_TYPE (desc))) (gdb) bt #0 0x0001000b6c0c in get_std_lbound (expr=0x141b15210, desc=0x142929d20, dim=0, assumed_size=false) at ../../p_work/gcc/fortran/trans-array.c:7401 #1 0x0001000c005c in gfc_alloc_allocatable_for_assignment (loop=0x7fff5fbfd450, expr1=0x141b15c30, expr2=0x141b16020) at ../../p_work/gcc/fortran/trans-array.c:7704 #2 0x0001000d71a6 in gfc_trans_assignment_1 (expr1=0x141b15c30, expr2=0x141b16020, init_flag=false, dealloc=true) at ../../p_work/gcc/fortran/trans-expr.c:6353 #3 0x0001000b44b2 in trans_code (code=0x141b163e0, cond=0x0) at ../../p_work/gcc/fortran/trans.c:1209 #4 0x0001000d141b in gfc_generate_function_code (ns=) at ../../p_work/gcc/fortran/trans-decl.c:5255 #5 0x000100072b7d in gfc_parse_file () at ../../p_work/gcc/fortran/parse.c:4410 #6 0x0001000afd96 in gfc_be_parse_file () at ../../p_work/gcc/fortran/f95-lang.c:250 #7 0x000100692851 in toplev_main (argc=2, argv=0x7fff5fbfd9a8) at ../../p_work/gcc/toplev.c:557 #8 0x00011674 in start ()
[Bug tree-optimization/51315] [4.6/4.7 regression] unaligned memory accesses generated with -ftree-sra
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51315 --- Comment #9 from rguenther at suse dot de 2011-12-07 11:36:55 UTC --- On Tue, 6 Dec 2011, ebotcazou at gcc dot gnu.org wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51315 > > --- Comment #8 from Eric Botcazou 2011-12-06 > 16:41:38 UTC --- > > Note that in the end it's always us transforming > > > > a->b.c > > > > to (effectively) > > > > T *tem = &a->b.c; > > *tem > > > > which expand unfortunately handles differently. So whenever we do that > > we have to either avoid doing that if expand would have a different > > idea about the results alignment (there is currently no way that computes > > just expands idea of an expressions alignment - one piece of a good > > solution would provide that, not only SRA has this "issue"), or, stick > > that information somewhere > > AFAICS that's what the memcpy folder does if STRICT_ALIGNMENT, so the > generated > GIMPLE is perfectly valid. But SRA isn't as cautious as the folder and, in > particular, doesn't compare the alignments of source and destination. In any > case, I don't think that we want to patch outside SRA on the 4.6 branch. The memcpy folder is very conservative, Martin patched SRA to that effect for STRICT_ALIGNMENT targets but that caused a lot of SRA regressions for those targets (and now we have a testcase involving SSE vector moves, thus, on a non-STRICT_ALIGNMENT target). But yes, dumbing down SRA is easy - there is a single function that guards "possibly unaligned" accesses. Richard.
[Bug fortran/51434] ICE with scalar init of an array parameter, used in DT default init with transfer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51434 --- Comment #9 from Tobias Burnus 2011-12-07 11:44:48 UTC --- (In reply to comment #7) > Any guess when this ICE might get some attention and into a release version? Well, as you can see from the discussion here, it does get attention. But in general: Only regressions have a high priority. (Regression = something which worked before but stopped doing so. At least the code of comment 4 never worked in gfortran.) -- We try hard to fix also the other issues, but as the development is based on volunteers and there are many bugs and feature requests, it might take a while. Release: The GCC development is now in the stabilization phase and GCC 4.7.0 will be presumably released around March next year. See http://gcc.gnu.org/ml/fortran/2011-12/msg00028.html (esp. the "Status" part in the forwarded email). (In reply to comment #4) > That's the line: > else if (mpz_cmp (c->ts.u.cl->length->value.integer, > c->initializer->ts.u.cl->length->value.integer)) > with > c->initializer->ts.u.cl == NULL Draft patch - one probably needs to do something similar for derived types. --- a/gcc/fortran/decl.c +++ b/gcc/fortran/decl.c @@ -1500,6 +1500,8 @@ add_init_expr_to_sym (const char *name, gfc_expr **initp, locus *var_locus) &init->where); array->shape = gfc_get_shape (sym->as->rank); + if (init->ts.type == BT_CHARACTER) + array->ts.u.cl = init->ts.u.cl; for (n = 0; n < sym->as->rank; n++) spec_dimen_size (sym->as, n, &array->shape[n]);
[Bug tree-optimization/50873] The fix to PR50730 causes gcc.c-torture/unsorted/dilayout.c to ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50873 rsand...@gcc.gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED CC||rsandifo at gcc dot gnu.org AssignedTo|unassigned at gcc dot |rsandifo at gcc dot gnu.org |gnu.org | --- Comment #3 from rsandifo at gcc dot gnu.org 2011-12-07 11:45:40 UTC --- We need to tweak maybe_legitimize_operand_same_code (thanks Ramana for the heads-up). Testing a fix.
[Bug middle-end/50823] [4.7 Regression] ICE in inline_small_functions, at ipa-inline.c:1407
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50823 --- Comment #15 from Richard Guenther 2011-12-07 11:55:19 UTC --- Author: rguenth Date: Wed Dec 7 11:55:16 2011 New Revision: 182077 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=182077 Log: 2011-12-07 Richard Guenther PR tree-optimization/50823 * ipa-inline.c (edge_badness): Do not account for the number of remaining calls. * gcc.dg/torture/pr50823.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr50823.c Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-inline.c trunk/gcc/testsuite/ChangeLog
[Bug ada/48835] Porting GNAT to GNU/Linux/m68k
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48835 --- Comment #44 from Mikael Pettersson 2011-12-07 12:04:14 UTC --- (In reply to comment #43) > What is the argument of fp_size_to_prec here? size == 80
[Bug c++/51229] [C++0x] [4.7 Regression] Broken diagnostic: 'integer_cst' not supported by dump_dec
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51229
--- Comment #3 from Jakub Jelinek 2011-12-07
12:04:46 UTC ---
Created attachment 26015
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26015
gcc47-pr51229.patch
Untested fix.
This patch doesn't deal with missing diagnostics for invalid:
struct A { int i; };
int a = { .foo = 6 };
int b = { [0] = 1 };
_Complex float c = { .foo = 0, 1 };
_Complex float d = { [0] = 0, 1 };
_Complex float e = { 0, .foo = 1 };
_Complex float f = { 0, [0] = 1 };
char g[] = { [7] = "abcd" };
I'd prefer to leave that part to Jason.
[Bug middle-end/50823] [4.7 Regression] ICE in inline_small_functions, at ipa-inline.c:1407
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50823 Richard Guenther changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #16 from Richard Guenther 2011-12-07 12:23:38 UTC --- Fixed.
[Bug libfortran/51448] [4.6/4.7 Regression] Compiler crash when assigning floating point values of different kinds
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51448 Richard Guenther changed: What|Removed |Added Target Milestone|--- |4.6.3
[Bug rtl-optimization/51447] global register variable definition incorrectly removed as dead code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51447 Richard Guenther changed: What|Removed |Added Keywords||wrong-code Status|UNCONFIRMED |NEW Last reconfirmed||2011-12-07 Component|c |rtl-optimization Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther 2011-12-07 12:42:58 UTC --- Confirmed.
[Bug middle-end/37130] warning: array subscript is above array bounds.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37130 Richard Guenther changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED Target Milestone|4.4.2 |4.5.0 --- Comment #8 from Richard Guenther 2011-12-07 12:44:10 UTC --- It's not a regression.
[Bug ada/48835] Porting GNAT to GNU/Linux/m68k
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48835 --- Comment #45 from Andreas Schwab 2011-12-07 12:48:29 UTC --- That should probably be 96.
[Bug tree-optimization/51446] -fno-trapping-math generates NaN constant with different sign
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51446 --- Comment #1 from Richard Guenther 2011-12-07 12:51:39 UTC --- I get -2251799813685248 9221120237041090560 vs. -2251799813685248 -2251799813685248 the subtraction is carried out with 4.7, also with 4.6.2.
[Bug ada/864] --program-suffix is ignored (for ada)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=864 --- Comment #22 from Richard Guenther 2011-12-07 12:54:15 UTC --- (In reply to comment #20) > I would also very much like to see the patch in comment 16 applied. There is > now a second report open at bug 51095, I will mark it as a dup. Are there > copyright or licensing reasons why it would have to be submitted by RG, or > does > posting it in BZ count as an assignment? Technically I took the patch from Debian, so it's their duty to submit it.
[Bug tree-optimization/51444] [4.4 Regression]: Spurious "is used uninitialized" warning for structure with bitfields
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51444 Richard Guenther changed: What|Removed |Added Target Milestone|--- |4.4.7 --- Comment #1 from Richard Guenther 2011-12-07 12:55:36 UTC --- Probably fixed as side-effect of some fix. If you identify the revision that fixed it the branch maintainer could assess whether a backport is a good idea at this stage.
[Bug rtl-optimization/51447] [4.4/4.5/4.6/4.7 Regression] global register variable definition incorrectly removed as dead code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51447 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org Target Milestone|--- |4.4.7 Summary|global register variable|[4.4/4.5/4.6/4.7 |definition incorrectly |Regression] global register |removed as dead code|variable definition ||incorrectly removed as dead ||code --- Comment #2 from Jakub Jelinek 2011-12-07 12:56:50 UTC --- Introduced in between r125000 and r126000, i.e. most likely dataflow branch merge.
[Bug ada/51307] [4.7 Regression] s-taprop.adb:676:25: "CLOCK_RT_Ada" not declared in "OS_Constants"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51307 John David Anglin changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED --- Comment #9 from John David Anglin 2011-12-07 13:01:49 UTC --- Fixed.
[Bug tree-optimization/51362] [4.7 Regression] ICE: SIGFPE (division by zero) in good_cloning_opportunity_p at ipa-cp.c:2401
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51362 Martin Jambor changed: What|Removed |Added CC||hubicka at gcc dot gnu.org --- Comment #4 from Martin Jambor 2011-12-07 13:03:42 UTC --- Well, it's estimate_ipcp_clone_size_and_time that returns zero estimated size growth. I find that quite strange, I'd never expect the function to return that, I'd expect a new function clone to certainly take up some space. Honza, should I handle the zero size value or is that the bug that should be addressed?
[Bug ada/48835] Porting GNAT to GNU/Linux/m68k
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48835 --- Comment #46 from Andreas Schwab 2011-12-07 13:10:15 UTC --- There were a lot of float related changes around 2011-08-02.
[Bug rtl-optimization/51447] [4.4/4.5/4.6/4.7 Regression] global register variable definition incorrectly removed as dead code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51447 Jakub Jelinek changed: What|Removed |Added CC||bonzini at gnu dot org --- Comment #3 from Jakub Jelinek 2011-12-07 13:09:54 UTC --- Indeed, fast_dce during cse1 removes this. Paolo, could you please have a look? Thanks.
[Bug target/51390] Builtin changes on November 29th, broke recip-5.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51390 --- Comment #7 from Iain Sandoe 2011-12-07 13:13:16 UTC --- with a stage1 compiler built with O0/g3: /GCC/gcc-live-trunk/gcc/testsuite/gcc.target/powerpc/recip-5.c:12:39: error: Builtin function __builtin_recipdiv is not supported with the current options Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_PROTECTION_FAILURE at address: 0x 0x006cad58 in store_expr (exp=0x4289a460, target=0x4292c3a0, call_param_p=0, nontemporal=) at /GCC/gcc-live-trunk/gcc/expr.c:5170 5170 if (CONSTANT_P (temp) && GET_MODE (temp) == VOIDmode (gdb) bt #0 0x006cad58 in store_expr (exp=0x4289a460, target=0x4292c3a0, call_param_p=0, nontemporal=) at /GCC/gcc-live-trunk/gcc/expr.c:5170 #1 0x006c8778 in expand_assignment (to=0x4291b18c, from=0x4289a460, nontemporal=) at /GCC/gcc-live-trunk/gcc/expr.c:4948 #2 0x004b2b10 in expand_call_stmt (stmt=0x42912d20) at /GCC/gcc-live-trunk/gcc/cfgexpand.c:2074 #3 0x004b2d00 in expand_gimple_stmt_1 (stmt=0x42912d20) at /GCC/gcc-live-trunk/gcc/cfgexpand.c:2115 #4 0x004b3674 in expand_gimple_stmt (stmt=0x42912d20) at /GCC/gcc-live-trunk/gcc/cfgexpand.c:2267 #5 0x004b37ac in expand_gimple_tailcall (bb=0x42919880, stmt=0x42912d20, can_fallthru=0xbfffea94 "") at /GCC/gcc-live-trunk/gcc/cfgexpand.c:2314 #6 0x004befb4 in expand_gimple_basic_block (bb=0x42919880) at /GCC/gcc-live-trunk/gcc/cfgexpand.c:3999 #7 0x004c1de8 in gimple_expand_cfg () at /GCC/gcc-live-trunk/gcc/cfgexpand.c:4530 #8 0x00b2b314 in execute_one_pass (pass=0x15bb638) at /GCC/gcc-live-trunk/gcc/passes.c:2079 #9 0x00b2b678 in execute_pass_list (pass=0x15bb638) at /GCC/gcc-live-trunk/gcc/passes.c:2134 #10 0x00df25d4 in tree_rest_of_compilation (fndecl=0x428edd80) at /GCC/gcc-live-trunk/gcc/tree-optimize.c:421 #11 0x00506ba8 in cgraph_expand_function (node=0x428f63d8) at /GCC/gcc-live-trunk/gcc/cgraphunit.c:1818 #12 0x00506ea4 in cgraph_expand_all_functions () at /GCC/gcc-live-trunk/gcc/cgraphunit.c:1885 #13 0x005081e8 in cgraph_optimize () at /GCC/gcc-live-trunk/gcc/cgraphunit.c:2198 #14 0x005042d0 in cgraph_finalize_compilation_unit () at /GCC/gcc-live-trunk/gcc/cgraphunit.c:1327 #15 0x00046584 in c_write_global_declarations () at /GCC/gcc-live-trunk/gcc/c-decl.c:10026 #16 0x00cbf304 in compile_file () at /GCC/gcc-live-trunk/gcc/toplev.c:573 #17 0x00cc38c4 in do_compile () at /GCC/gcc-live-trunk/gcc/toplev.c:1928 #18 0x00cc3b88 in toplev_main (argc=28, argv=0xb0ac) at /GCC/gcc-live-trunk/gcc/toplev.c:2004 #19 0x001b5f78 in main (argc=28, argv=0xb0ac) at /GCC/gcc-live-trunk/gcc/main.c:36
[Bug tree-optimization/50904] [4.7 regression] pessimization when -fno-protect-parens is enabled by -Ofast
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50904 --- Comment #50 from Venkataramanan Kumar 2011-12-07 13:18:57 UTC --- In the machine I used Induct run time improves from 68.9 seconds to 55.94 seconds for -Ofast. I will update on other benchmarks and SPEC2006 once I complete testing.
[Bug gcov-profile/51449] New: [4.7 regression] Rev181994 causes tramp3d-v4 profiled build failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51449 Bug #: 51449 Summary: [4.7 regression] Rev181994 causes tramp3d-v4 profiled build failure Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: gcov-profile AssignedTo: unassig...@gcc.gnu.org ReportedBy: mar...@trippelsdorf.de http://www.suse.de/~rguenther/tramp3d/tramp3d-v4.cpp.gz % c++ -w -Ofast -fprofile-generate -march=native tramp3d-v4.cpp /tmp/ccMmeivA.o:tramp3d-v4.cpp:function Inform::flush(): error: undefined reference to '__gcov0__ZNKSt19basic_ostringstreamIcSt11char_traitsIcESaIcEE3strEv' /tmp/ccMmeivA.o:tramp3d-v4.cpp:function Inform::flush(): error: undefined reference to '__gcov0__ZNKSt19basic_ostringstreamIcSt11char_traitsIcESaIcEE3strEv' /tmp/ccMmeivA.o:tramp3d-v4.cpp:function Inform::flush(): error: undefined reference to '__gcov0__ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_PKc' /tmp/ccMmeivA.o:tramp3d-v4.cpp:function Inform::flush(): error: undefined reference to '__gcov0__ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_PKc' /tmp/ccMmeivA.o:tramp3d-v4.cpp:function Inform::flush(): error: undefined reference to '__gcov0__ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_PKc' /tmp/ccMmeivA.o:tramp3d-v4.cpp:function Inform::flush(): error: undefined reference to '__gcov0__ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_PKc' /tmp/ccMmeivA.o:tramp3d-v4.cpp:function Inform::flush(): error: undefined reference to '__gcov0__ZNSt19basic_ostringstreamIcSt11char_traitsIcESaIcEE3strERKSs' /tmp/ccMmeivA.o:tramp3d-v4.cpp:function Inform::flush(): error: undefined reference to '__gcov0__ZNSt19basic_ostringstreamIcSt11char_traitsIcESaIcEE3strERKSs' /tmp/ccMmeivA.o:tramp3d-v4.cpp:function Pooma::Statistics::print(Inform&, long (*)(long)): error: undefined reference to '__gcov0__ZNSolsEl' /tmp/ccMmeivA.o:tramp3d-v4.cpp:function Pooma::Statistics::print(Inform&, long (*)(long)): error: undefined reference to '__gcov0__ZNSolsEl' /tmp/ccMmeivA.o:tramp3d-v4.cpp:function Inform& operator<< (Inform&, double const&) [clone .isra.122]: error: undefined reference to '__gcov0__ZNSolsEd' /tmp/ccMmeivA.o:tramp3d-v4.cpp:function Inform& operator<< (Inform&, double const&) [clone .isra.122]: error: undefined reference to '__gcov0__ZNSolsEd' /tmp/ccMmeivA.o:tramp3d-v4.cpp:function Pooma::Options::operator=(Pooma::Options const&): error: undefined reference to '__gcov0__ZNSsaSERKSs' /tmp/ccMmeivA.o:tramp3d-v4.cpp:function Pooma::Options::operator=(Pooma::Options const&): error: undefined reference to '__gcov0__ZNSsaSERKSs' /tmp/ccMmeivA.o:tramp3d-v4.cpp:function Inform::setPrefix(char const*): error: undefined reference to '__gcov0__ZNSsaSEPKc' /tmp/ccMmeivA.o:tramp3d-v4.cpp:function Inform::setPrefix(char const*): error: undefined reference to '__gcov0__ZNSs6assignEPKc' /tmp/ccMmeivA.o:tramp3d-v4.cpp:function Inform::setPrefix(char const*): error: undefined reference to '__gcov0__ZNSs6assignEPKc' /tmp/ccMmeivA.o:tramp3d-v4.cpp:function Inform::setPrefix(char const*): error: undefined reference to '__gcov0__ZNSsaSEPKc' /tmp/ccMmeivA.o:tramp3d-v4.cpp:function Pooma::Options::reset(): error: undefined reference to '__gcov0__ZNSsaSEPKc' /tmp/ccMmeivA.o:tramp3d-v4.cpp:function Pooma::Options::reset(): error: undefined reference to '__gcov0__ZNSs6assignEPKc' /tmp/ccMmeivA.o:tramp3d-v4.cpp:function Pooma::Options::reset(): error: undefined reference to '__gcov0__ZNSs6assignEPKc' /tmp/ccMmeivA.o:tramp3d-v4.cpp:function Pooma::Options::reset(): error: undefined reference to '__gcov0__ZNSsaSEPKc' /tmp/ccMmeivA.o:tramp3d-v4.cpp:function Pooma::Options::parse(int&, char**&): error: undefined reference to '__gcov0__ZNSsD2Ev' /tmp/ccMmeivA.o:tramp3d-v4.cpp:function Pooma::Options::parse(int&, char**&): error: undefined reference to '__gcov0__ZNSs4_Rep10_M_disposeERKSaIcE' /tmp/ccMmeivA.o:tramp3d-v4.cpp:function Pooma::Options::parse(int&, char**&): error: undefined reference to '__gcov0__ZNSsD2Ev' /tmp/ccMmeivA.o:tramp3d-v4.cpp:function Pooma::Options::parse(int&, char**&): error: undefined reference to '__gcov0__ZNSs4_Rep10_M_disposeERKSaIcE' /tmp/ccMmeivA.o:tramp3d-v4.cpp:function Pooma::Options::parse(int&, char**&): error: undefined reference to '__gcov0__ZNSs4_Rep10_M_disposeERKSaIcE' /tmp/ccMmeivA.o:tramp3d-v4.cpp:function Pooma::Options::parse(int&, char**&): error: undefined reference to '__gcov0__ZNSs4_Rep10_M_disposeERKSaIcE' /tmp/ccMmeivA.o:tramp3d-v4.cpp:function handle_cmd_args(int, char**): error: undefined reference to '__gcov0__ZNSs6appendEPKc' /tmp/ccMmeivA.o:tramp3d-v4.cpp:function handle_cmd_args(int, char**): error: undefined reference to '__gcov0__ZNSs6appendEPKc' /tmp/ccMmeivA.o:tramp3d-v4.cpp:function handle_cmd_args(int, char**): error: undefined reference to '__gcov0__ZNSs6appendEPKc' /tmp/ccMmeivA.o:tramp3d-v4.cpp:function handle_cmd_args(int, char**): e
[Bug c++/50896] [4.7 Regression] FAIL: g++.dg/lto/20100302 cp_lto_20100302_0.o-cp_lto_20100302_1.o link, -flto -fabi-version=2 (internal compiler error)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50896 Richard Guenther changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #1 from Richard Guenther 2011-12-07 13:31:35 UTC --- dup *** This bug has been marked as a duplicate of bug 50601 ***
[Bug lto/50601] [4.7 Regression] New LTO failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50601 Richard Guenther changed: What|Removed |Added CC||rguenth at gcc dot gnu.org --- Comment #9 from Richard Guenther 2011-12-07 13:31:35 UTC --- *** Bug 50896 has been marked as a duplicate of this bug. ***
[Bug rtl-optimization/51447] [4.4/4.5/4.6/4.7 Regression] global register variable definition incorrectly removed as dead code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51447
--- Comment #4 from Paolo Bonzini 2011-12-07 13:48:42
UTC ---
The bug is that rbx is added to the EXIT_BLOCK uses:
Basic block 1 , prev 2, loop_depth 0, count 0, freq 0.
Predecessors:
;; bb 1 artificial_defs: { }
;; bb 1 artificial_uses: { u-1(3){ }u-1(6){ }u-1(7){ }u-1(20){ }}
Successors:
but "jmp *%rbx" does not have the EXIT_BLOCK as a successor:
Basic block 2 , prev 0, next 1, loop_depth 0, count 0, freq 1, maybe hot.
Predecessors: ENTRY [100.0%] (fallthru)
;; bb 2 artificial_defs: { }
;; bb 2 artificial_uses: { u-1(6){ }u-1(7){ }u-1(16){ }u-1(20){ }}
Successors:
;; Pred edge ENTRY [100.0%] (fallthru)
(note 4 0 2 2 [bb 2] NOTE_INSN_BASIC_BLOCK)
(insn 2 4 3 2 (set (reg/v/f:DI 59 [ func ])
(reg:DI 5 di [ func ])) f.c:4 62 {*movdi_internal_rex64}
(nil))
(note 3 2 7 2 NOTE_INSN_FUNCTION_BEG)
(jump_insn 7 3 0 2 (set (pc)
(reg/v/f:DI 59 [ func ])) f.c:5 608 {*indirect_jump}
(nil))
;; End of basic block 2 -> ()
... so the liveness of rbx is not propagated from the end of basic block 1 to
the end of basic block 2.
I think the testcase is bogus:
You may not use [goto void *] to jump to code in a different function.
If you do that, totally unpredictable things will happen. The best way
to avoid this is to store the label address only in automatic variables
and never pass it as an argument.
However, this one also shows the same issue:
register void *volatile ptr asm("rbx") ;
void testfn1(void* func)
{
for(;;)
ptr = func;
}
and the fix should likely work for both.
[Bug libfortran/51448] [4.6/4.7 Regression] Compiler crash when assigning floating point values of different kinds
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51448
Tobias Burnus changed:
What|Removed |Added
Keywords||ice-on-valid-code
CC||burnus at gcc dot gnu.org
--- Comment #2 from Tobias Burnus 2011-12-07
13:50:22 UTC ---
Workaround: -fno-realloc-lhs
Draft patch:
--- a/gcc/fortran/trans-array.c
+++ b/gcc/fortran/trans-array.c
@@ -7428,7 +7584,16 @@ get_std_lbound (gfc_expr *expr, tree desc, int dim, bool
assumed_size)
gfc_array_index_type, cond,
lbound, gfc_index_one_node);
}
- else if (expr->expr_type == EXPR_VARIABLE)
+
+ if (expr->expr_type == EXPR_FUNCTION)
+{
+ /* A conversion function, so use the argument. */
+ gcc_assert (expr->value.function.isym
+ && expr->value.function.isym->conversion);
+ expr = expr->value.function.actual->expr;
+}
+
+ if (expr->expr_type == EXPR_VARIABLE)
{
tmp = TREE_TYPE (expr->symtree->n.sym->backend_decl);
for (ref = expr->ref; ref; ref = ref->next)
@@ -7441,15 +7606,6 @@ get_std_lbound (gfc_expr *expr, tree desc, int dim, bool
assumed_size)
}
return GFC_TYPE_ARRAY_LBOUND(tmp, dim);
}
- else if (expr->expr_type == EXPR_FUNCTION)
-{
- /* A conversion function, so use the argument. */
- expr = expr->value.function.actual->expr;
- if (expr->expr_type != EXPR_VARIABLE)
- return gfc_index_one_node;
- desc = TREE_TYPE (expr->symtree->n.sym->backend_decl);
- return get_std_lbound (expr, desc, dim, assumed_size);
-}
return gfc_index_one_node;
}
[Bug lto/48100] [4.6 Regression] Assertion failed in lto_varpool_replace_node, at lto-symtab.c:304 with mixed LTO/non-LTO objects
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48100 Richard Guenther changed: What|Removed |Added Summary|[4.6/4.7 Regression]|[4.6 Regression] Assertion |Assertion failed in |failed in |lto_varpool_replace_node, |lto_varpool_replace_node, |at lto-symtab.c:304 with|at lto-symtab.c:304 with |mixed LTO/non-LTO objects |mixed LTO/non-LTO objects --- Comment #7 from Richard Guenther 2011-12-07 13:51:44 UTC --- The resolution is still the same - we just don't ICE anymore on trunk. Needs to be bisected I guess.
[Bug lto/48100] [4.6 Regression] Assertion failed in lto_varpool_replace_node, at lto-symtab.c:304 with mixed LTO/non-LTO objects
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48100 --- Comment #8 from Richard Guenther 2011-12-07 13:53:38 UTC --- Author: rguenth Date: Wed Dec 7 13:53:30 2011 New Revision: 182082 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=182082 Log: 2011-12-07 Richard Guenther PR lto/48100 * gcc.dg/lto/20111207-1_0.c: New testcase. * gcc.dg/lto/20111207-1_1.c: Likewise. * gcc.dg/lto/20111207-1_2.c: Likewise. * gcc.dg/lto/20111207-1_3.c: Likewise. Added: trunk/gcc/testsuite/gcc.dg/lto/20111207-1_0.c trunk/gcc/testsuite/gcc.dg/lto/20111207-1_1.c trunk/gcc/testsuite/gcc.dg/lto/20111207-1_2.c trunk/gcc/testsuite/gcc.dg/lto/20111207-1_3.c Modified: trunk/gcc/testsuite/ChangeLog
[Bug gcov-profile/51449] [4.7 regression] Rev181994 causes tramp3d-v4 profiled build failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51449 Richard Guenther changed: What|Removed |Added Priority|P3 |P1 Target Milestone|--- |4.7.0
[Bug rtl-optimization/51447] [4.4/4.5/4.6/4.7 Regression] global register variable definition incorrectly removed as dead code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51447
--- Comment #5 from Paolo Bonzini 2011-12-07 14:04:04
UTC ---
Untested patch...
Index: df-problems.c
===
--- df-problems.c (revision 177688)
+++ df-problems.c (working copy)
@@ -901,6 +901,10 @@ df_lr_local_compute (bitmap all_blocks A
/* The all-important stack pointer must always be live. */
bitmap_set_bit (&df->hardware_regs_used, STACK_POINTER_REGNUM);
+ for (i = 0; i < FIRST_PSEUDO_REGISTER; i++)
+if (global_regs[i])
+ bitmap_set_bit (&df->hardware_regs_used, i);
+
/* Before reload, there are a few registers that must be forced
live everywhere -- which might not already be the case for
blocks within infinite loops. */
Index: df-scan.c
===
--- df-scan.c (revision 177688)
+++ df-scan.c (working copy)
@@ -3733,8 +3733,12 @@ df_get_entry_block_def_set (bitmap entry
bitmap_clear (entry_block_defs);
for (i = 0; i < FIRST_PSEUDO_REGISTER; i++)
-if (FUNCTION_ARG_REGNO_P (i))
- bitmap_set_bit (entry_block_defs, INCOMING_REGNO (i));
+{
+ if (global_regs[i])
+bitmap_set_bit (entry_block_defs, i);
+ if (FUNCTION_ARG_REGNO_P (i))
+bitmap_set_bit (entry_block_defs, INCOMING_REGNO (i));
+}
/* The always important stack pointer. */
bitmap_set_bit (entry_block_defs, STACK_POINTER_REGNUM);
[Bug rtl-optimization/51447] [4.4/4.5/4.6/4.7 Regression] global register variable definition incorrectly removed as dead code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51447
--- Comment #6 from Jakub Jelinek 2011-12-07
14:06:41 UTC ---
I think goto ptr can't be nonlocal, so that testcase indeed would be invalid.
register void *ptr asm ("rbx");
int
foo (void)
{
__label__ nonlocal_lab;
__attribute__((noinline, noclone)) void
bar (void *func)
{
ptr = func;
goto nonlocal_lab;
}
bar (&&nonlocal_lab);
return 1;
nonlocal_lab:
return ptr != &&nonlocal_lab;
}
ought to be valid though, this is normal non-local goto.
[Bug middle-end/40154] [4.4/4.5/4.6/4.7 Regression] internal compiler error: in do_SUBST, at combine.c:681
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40154 Jorn Wolfgang Rennecke changed: What|Removed |Added Keywords||patch --- Comment #6 from Jorn Wolfgang Rennecke 2011-12-07 14:13:15 UTC --- (In reply to comment #5) > Actually, it is not enough to ensure that the mode matches; we must ensure > that the SET_DEST of the insn we attach the note to is set to the value. A patch that takes this into account is posted here: http://gcc.gnu.org/ml/gcc-patches/2011-12/msg00490.html
[Bug other/51450] New: configure's test for -fno-rtti -fno-exceptions broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51450 Bug #: 51450 Summary: configure's test for -fno-rtti -fno-exceptions broken Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassig...@gcc.gnu.org ReportedBy: christophe.l...@st.com I have noticed that configure decides that my build GCC does not support -fno-rtti -fno-exceptions when building a new GCC. I traced this down to a problem in libtool.m4 where _LT_COMPILER_NO_RTTI uses _LT_COMPILER_OPTION to check whether these 2 options are supported. The latter compiles & links $lt_simple_compile_test_code which contains: lt_simple_compile_test_code="int some_variable = 0;" The link phase fails because there is no main(), and then configure decides -fno-rtti -fno-exceptions are not supported. I am not sure about how to fix this: - change _LT_COMPILER_OPTION to use $lt_simple_link_test_code instead? - use a modified _LT_LINKER_OPTION (given that the options tests belong to CFLAGS rather than LDFLAGS)? - other? Maybe this bug should be reported elsewhere?
[Bug c++/51429] [4.7 Regression] ICE with invalid use of overloaded member function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51429 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011-12-07 AssignedTo|unassigned at gcc dot |jakub at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #1 from Jakub Jelinek 2011-12-07 14:49:15 UTC --- Created attachment 26016 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26016 gcc47-pr51429.patch Untested fix.
[Bug middle-end/49945] [4.7 Regression] gcc.dg/guality/vla-1.c FAILs with -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49945 Richard Guenther changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | --- Comment #5 from Richard Guenther 2011-12-07 14:53:36 UTC --- Mine. Similar issue as PR48437.
[Bug middle-end/49945] [4.7 Regression] gcc.dg/guality/vla-1.c FAILs with -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49945 --- Comment #6 from Richard Guenther 2011-12-07 14:59:52 UTC --- Index: gcc/lto-streamer-out.c === --- gcc/lto-streamer-out.c (revision 182081) +++ gcc/lto-streamer-out.c (working copy) @@ -129,6 +129,19 @@ tree_is_indexable (tree t) else if (TREE_CODE (t) == VAR_DECL && decl_function_context (t) && !TREE_STATIC (t)) return false; + else if (TYPE_P (t) + && variably_modified_type_p (t, NULL_TREE)) +return false; else return (TYPE_P (t) || DECL_P (t) || TREE_CODE (t) == SSA_NAME); } fixes it.
[Bug gcov-profile/51449] [4.7 regression] Rev181994 causes tramp3d-v4 profiled build failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51449
--- Comment #1 from Markus Trippelsdorf
2011-12-07 15:14:40 UTC ---
Here is a (somewhat) reduced testcase:
% cat test.ii
extern "C"
{
typedef long unsigned int size_t;
}
namespace std __attribute__ ((__visibility__ ("default")))
{
template < typename _Alloc > class allocator;
template < class _CharT > struct char_traits;
template < typename _CharT, typename _Traits =
char_traits < _CharT >, typename _Alloc =
allocator < _CharT > >class basic_string;
typedef basic_string < char >string;
template < typename _CharT, typename _Traits =
char_traits < _CharT > >class basic_ostream;
typedef basic_ostream < char >ostream;
typedef struct {
}
__pthread_unwind_buf_t __attribute__ ((__aligned__));
}
namespace __gnu_cxx __attribute__ ((__visibility__ ("default")))
{
template < typename _Tp > class new_allocator
{
public:
typedef size_t size_type;
typedef _Tp *pointer;
typedef _Tp & reference;
};
}
namespace std __attribute__ ((__visibility__ ("default")))
{
template < typename _Tp > class allocator:public __gnu_cxx::new_allocator <
_Tp >
{
public:
typedef size_t size_type;
template < typename _Tp1 > struct rebind {
typedef allocator < _Tp1 > other;
};
};
class ios_base
{
};
template < typename _CharT, typename _Traits > class basic_ios:public
ios_base
{
};
template < typename _CharT, typename _Traits > class basic_ostream:virtual
public basic_ios < _CharT, _Traits >
{
public:
typedef _CharT char_type;
typedef basic_ostream < _CharT,
_Traits > __ostream_type;
__ostream_type & operator<< (long __n) {
return _M_insert (__n);
}
__ostream_type & operator<< (bool __n) {
}
template < typename _ValueT > __ostream_type & _M_insert (_ValueT __v);
};
extern template class basic_ostream < char >;
}
namespace __gnu_cxx __attribute__ ((__visibility__ ("default")))
{
template < typename _Alloc > struct __alloc_traits {
typedef typename _Alloc::pointer pointer;
typedef typename _Alloc::reference reference;
template < typename _Tp > struct rebind {
typedef typename _Alloc::template rebind < _Tp >::other other;
};
};
}
class Inform
{
public:
typedef int ID_t;
std::ostream & stream () {
}
};
namespace std
{
extern Inform & endl (Inform &);
}
template < class T > inline Inform &
operator<< (Inform & o, const T & val)
{
o.stream () << val;
}
namespace std __attribute__ ((__visibility__ ("default")))
{
template < typename _Tp, typename _Alloc > struct _Vector_base {
typedef typename __gnu_cxx::__alloc_traits < _Alloc >::template rebind <
_Tp >::other _Tp_alloc_type;
typedef typename __gnu_cxx::__alloc_traits <
_Tp_alloc_type >::pointer pointer;
struct _Vector_impl:public _Tp_alloc_type {
pointer _M_start;
pointer _M_finish;
};
public:
_Vector_impl _M_impl;
};
template < typename _Tp, typename _Alloc = std::allocator
< _Tp > >class vector:protected _Vector_base < _Tp, _Alloc >
{
typedef _Vector_base < _Tp,
_Alloc > _Base;
typedef typename _Base::_Tp_alloc_type _Tp_alloc_type;
typedef __gnu_cxx::__alloc_traits < _Tp_alloc_type > _Alloc_traits;
public:
typedef _Tp value_type;
typedef typename _Alloc_traits::reference reference;
typedef size_t size_type;
size_type size () const {
return size_type (this->_M_impl._M_finish - this->_M_impl._M_start);
}
reference operator[] (size_type __n) {
}
};
struct _Setw {
};
inline _Setw setw (int __n)
{
}
template < typename _CharT,
typename _Traits > inline basic_ostream < _CharT,
_Traits > &operator<< (basic_ostream < _CharT,
_Traits > &__os, _Setw __f)
{
}
class StatisticsData
{
public:
const std::string & description () const {
}
long value () const {
}
};
class Statistics
{
private:
static long defaultFilter (long val);
void print (Inform &, long (*filter) (long) = defaultFilter);
private:
std::vector < StatisticsData * >statList_m;
};
void Statistics::print (Inform & o, long (*filter) (long))
{
int i,
j;
for (i = 0; i < statList_m.size (); ++i) {
o << " " << std::setw (12) << filter (statList_m[i]->
value ());
}
}
}
int main(){}
markus@x4 /tmp % g++ test.ii -O0 -fprofile-generate
markus@x4 /tmp % g++ test.ii -O1 -fprofile-generate
/tmp/ccvdpINQ.o:test.ii:function std::Statistics::print(Inform&, long
(*)(long)): error: undefined reference to '__gcov0__ZNSolsEl'
/tmp/ccvdpINQ.o:test.ii:function std::Statistics::print(Inform&, long
(*)(long)): error: undefined reference to '__gcov0__ZNSolsEl'
/tmp/ccvdpINQ.o:test.ii:function Inform& operator<< (Inform&, long
const&): error: undefined reference to '__gcov0__ZNSolsEl'
/tmp/ccvdpINQ.o:test.ii:function Inform& operator<< (Inform&, long
const&): error: undefined reference to '__gcov0__ZNSolsEl'
collect2:
[Bug fortran/51434] ICE with scalar init of an array parameter, used in DT default init with transfer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51434 --- Comment #10 from Tobias Burnus 2011-12-07 15:31:11 UTC --- (In reply to comment #9) > Draft patch - one probably needs to do something similar for derived types. The patch breaks the "Different CHARACTER lengths (%d/%d) in array constructor" diagnostic, e.g. gfortran.dg/bounds_check_array_ctor_3.f90.
[Bug c++/51420] [c++0x] ICE with invalid user-defined literals
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51420 --- Comment #3 from Jason Merrill 2011-12-07 15:41:08 UTC --- Author: jason Date: Wed Dec 7 15:41:03 2011 New Revision: 182083 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=182083 Log: PR c++/51420 * parser.c (lookup_literal_operator): Check that declaration is an overloaded function. Added: trunk/gcc/testsuite/g++.dg/cpp0x/pr51420.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/testsuite/ChangeLog
[Bug libgcj/51451] New: Premature EOF in stream
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51451 Bug #: 51451 Summary: Premature EOF in stream Classification: Unclassified Product: gcc Version: 4.4.5 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcj AssignedTo: unassig...@gcc.gnu.org ReportedBy: xels...@gmx.net Compiled my java program into native code (x86_64-linux-gnu) and antlr3.4.jar in object: gcj -fPIC -c antlr3.4.jar --classpath=junit.jar -o antlr.o gcj -fPIC myProg.jar antlr.o -o myProg For files>2k, myProg exits at byte 2048 and reports to have reached EOF which is not the case. Occurs for a java CharStream. Java version works fine on the same file. Encoding is UTF-8. gcj -v Using built-in specs. Reading specs from /usr/lib/gcc/x86_64-linux-gnu/4.4.5/libgcj.spec rename spec startfile to startfileorig rename spec lib to liborig Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.4.4-14ubuntu2' --with-bugurl=file:///usr/share/doc/gcj-4.4/README.Bugs --enable-languages=c,c++,java --prefix=/usr --program-suffix=-4.4 --enable-shared --enable-multiarch --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.4 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --disable-libmudflap --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=//usr/lib/jvm/java-1.5.0-gcj-4.4/jre --enable-java-home --with-jvm-root-dir=//usr/lib/jvm/java-1.5.0-gcj-4.4 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.4 --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-werror --with-arch-32=i686 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.4.5 (Ubuntu 4.4.4-14ubuntu2)
[Bug libffi/50051] MIPS libffi does not compile for mips64octeon-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50051 --- Comment #4 from Andrew Pinski 2011-12-07 16:00:25 UTC --- (In reply to comment #3) > Thanks Andrew. Does this force the generation of FP instructions, which are > then emulated through OS traps? Yes and the traps are always enabled in newish kernels.
[Bug fortran/51434] ICE with scalar init of an array parameter, used in DT default init with transfer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51434 --- Comment #11 from Andy Nelson 2011-12-07 16:11:38 UTC --- On Dec 6, 2011, at 7:17 PM, sgk at troutmask dot apl.washington.edu wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51434 > > --- Comment #8 from Steve Kargl > 2011-12-07 02:17:48 UTC --- > On Tue, Dec 06, 2011 at 10:25:00PM +, andy.nelson at lanl dot gov wrote: >> >> Any guess when this ICE might get some attention and into a release version? >> > > Unfortunately, the only guess is the bug will be fixed > when someone gets around to fixing it. :( It comes > down to too few developers and too many things to do > (e.g., fix bugs and implement new features) and too > little time. > Sure. I didn't mean to imply any particular pressure. In the environment I work in, it would be years before I see this fix even if it got fixed today, so any particular time pressure is rather soft. Basically, for most of the codes that I work on and that pay my salary, I can't implement a feature or depend on a bug not hitting me until the oldest machine we have is retired or upgraded past the implementation/fix of whatever it is that I need for some bit of code or other. Thanks for the attention, Andy
[Bug lto/50747] [4.7 Regression] ICE in produce_symtab, at lto-streamer-out.c:1435
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50747
--- Comment #5 from Richard Guenther 2011-12-07
16:13:14 UTC ---
The function in question is DECL_ABSTRACT (it's one of the B::B constructors).
Not sure why we have a cgraph node for it at all:
#0 cgraph_create_node (decl=0x75b92500)
at /space/rguenther/src/svn/trunk/gcc/cgraph.c:495
#1 0x009b6878 in cgraph_get_create_node (decl=0x75b92500)
at /space/rguenther/src/svn/trunk/gcc/cgraph.c:543
#2 0x008c3303 in c_genericize (fndecl=0x75b92500)
at /space/rguenther/src/svn/trunk/gcc/c-family/c-gimplify.c:101
#3 0x00858e0a in cp_genericize (fndecl=0x75b92500)
at /space/rguenther/src/svn/trunk/gcc/cp/cp-gimplify.c:1172
#4 0x00547836 in finish_function (flags=0)
at /space/rguenther/src/svn/trunk/gcc/cp/decl.c:13478
#5 0x00769a05 in synthesize_method (fndecl=0x75b92500)
at /space/rguenther/src/svn/trunk/gcc/cp/method.c:774
#6 0x0068fd62 in mark_used (decl=0x75b92600)
at /space/rguenther/src/svn/trunk/gcc/cp/decl2.c:4372
#7 0x004d0a88 in build_over_call (cand=0x1f33fd0, flags=3, complain=3)
at /space/rguenther/src/svn/trunk/gcc/cp/call.c:6727
#8 0x004d590c in build_new_method_call_1 (instance=0x75a2c1e0,
fns=0x75b79a80, args=0x7fffcc50, conversion_path=0x75b8c340,
flags=3, fn_p=0x0, complain=3)
at /space/rguenther/src/svn/trunk/gcc/cp/call.c:7337
The following fixes the ICE for Volkers testcase, but not the original
from Markus:
@@ -1431,8 +1444,9 @@ produce_symtab (struct output_block *ob,
table: they end up being undefined and just consume space. */
if (!node->address_taken && !node->callers)
{
- gcc_assert (node->analyzed);
- gcc_assert (DECL_DECLARED_INLINE_P (node->decl));
+ gcc_assert ((node->analyzed
+ && DECL_DECLARED_INLINE_P (node->decl))
+ || DECL_ABSTRACT (node->decl));
continue;
}
if (DECL_COMDAT (node->decl)
why assert anything at all here? That is, that's the fix I'd do:
@@ -1430,11 +1443,7 @@ produce_symtab (struct output_block *ob,
them indirectly or via vtables. Do not output them to symbol
table: they end up being undefined and just consume space. */
if (!node->address_taken && !node->callers)
- {
- gcc_assert (node->analyzed);
- gcc_assert (DECL_DECLARED_INLINE_P (node->decl));
- continue;
- }
+ continue;
if (DECL_COMDAT (node->decl)
&& cgraph_comdat_can_be_unshared_p (node))
continue;
[Bug c++/47687] [C++0x] Crash on a lambda returning a lambda (using std::function)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47687 Paolo Carlini changed: What|Removed |Added CC||doko at gcc dot gnu.org --- Comment #8 from Paolo Carlini 2011-12-07 16:53:26 UTC --- *** Bug 51395 has been marked as a duplicate of this bug. ***
[Bug c++/51395] [4.5/4.6 Regression] ICE in dependent_type_p (endless (?) recursion)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51395 Paolo Carlini changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #2 from Paolo Carlini 2011-12-07 16:53:26 UTC --- Dup *** This bug has been marked as a duplicate of bug 47687 ***
[Bug libstdc++/51452] New: has_nothrow_.*constructor bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51452
Bug #: 51452
Summary: has_nothrow_.*constructor bugs
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: d...@boost-consulting.com
The traits that detect nothrow constructibility are buggy because they are
influenced by whether the object has a nothrow dtor; destruction is invoked at
the end of evaluation of the full expression in the noexcept( ... ) operator.
They all use the pattern of constructing a temporary inside noexcept, whereas
they should be using placement new:
struct X
{
X() noexcept;
~X();
};
static_assert( noexcept( X() ), "fails because of ~X" );
static_assert( noexcept(new (nullptr) X()), "works" );
[Bug rtl-optimization/51051] [4.7 Regression]: build fails on cris-elf building libstdc++-v3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51051 --- Comment #11 from Joel Sherrill 2011-12-07 16:56:46 UTC --- I still have HP's patch in my local tree. Should I remove it? Or does it need to be committed?
[Bug c++/51398] [4.7 Regression] ICE with invalid template parameter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51398 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-12-07 Ever Confirmed|0 |1 --- Comment #1 from Paolo Carlini 2011-12-07 16:59:04 UTC --- Doesn't ICE in release mode.
[Bug c++/51403] [4.7 Regression] ICE with invalid template parameter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51403 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-12-07 Ever Confirmed|0 |1 --- Comment #1 from Paolo Carlini 2011-12-07 17:06:11 UTC --- Doesn't ICE in release mode. In general, we have an issue with as non-type parameter: when we see it, we of course error out, we store an error_mark_node and go ahead normally. Then the error_mark_node can come out in many different places: lots of ICEs, all ultimately due to the same issue.
[Bug libstdc++/51452] has_nothrow_.*constructor bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51452 --- Comment #1 from Jonathan Wakely 2011-12-07 17:16:58 UTC --- I think this is by design, see the thread beginning with c++std-lib-30698 I've been surprised by that reasoning several times e.g. http://gcc.gnu.org/ml/gcc-help/2011-11/msg00015.html
[Bug fortran/51434] ICE with scalar init of an array parameter, used in DT default init with transfer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51434
--- Comment #12 from Tobias Burnus 2011-12-07
17:20:14 UTC ---
(In reply to comment #10)
> > Draft patch - one probably needs to do something similar for derived types.
> The patch breaks the "Different CHARACTER lengths (%d/%d) in array
> constructor" diagnostic, e.g. gfortran.dg/bounds_check_array_ctor_3.f90.
Actually, it does not - that was a left over from an earlier attempt (in
expr.c's gfc_get_character_expr). The following should work, but is not
regtested. I am not sure about the BT_DERIVED part; valid examples seem to work
fine while the following invalid code ICEs in decl.c's build_struct. That's
independent of the patch.
type t
character :: z
end type t
type(t), parameter :: s(5) = t('a')
type b
character :: y(5) = transfer('a', s)
end type
end
--- a/gcc/fortran/decl.c
+++ b/gcc/fortran/decl.c
@@ -1502,6 +1502,18 @@ add_init_expr_to_sym (const char *name, gfc_expr
**initp, locus *var_locus)
array->shape = gfc_get_shape (sym->as->rank);
for (n = 0; n < sym->as->rank; n++)
spec_dimen_size (sym->as, n, &array->shape[n]);
+ array->ts.is_c_interop = init->ts.is_c_interop;
+ if (init->ts.type == BT_CHARACTER)
+ {
+ if (init->ts.u.cl->length == NULL)
+ init->ts.u.cl->length
+ = gfc_get_int_expr (gfc_default_integer_kind,
+ &init->where,
+ init->value.character.length);
+ array->ts.u.cl = init->ts.u.cl;
+ }
+ else if (init->ts.type == BT_DERIVED)
+ array->ts.u.derived = init->ts.u.derived;
init = array;
mpz_clear (size);
[Bug libstdc++/51452] has_nothrow_.*constructor bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51452 Paolo Carlini changed: What|Removed |Added CC||daniel.kruegler at ||googlemail dot com --- Comment #2 from Paolo Carlini 2011-12-07 17:20:47 UTC --- Daniel should resolve this.
[Bug c++/51401] [c++0x] [4.7 Regression] ICE with invalid use of auto in template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51401 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011-12-07 AssignedTo|unassigned at gcc dot |jakub at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #1 from Jakub Jelinek 2011-12-07 17:31:21 UTC --- Created attachment 26017 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26017 gcc47-pr51401.patch Untested fix.
[Bug libstdc++/51452] has_nothrow_.*constructor bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51452 Paolo Carlini changed: What|Removed |Added CC||redi at gcc dot gnu.org --- Comment #3 from Paolo Carlini 2011-12-07 17:32:54 UTC --- By the way, Jon, I think we should audit the library a little more systematically vs PR50043 (assuming that, unfortunately, isn't done in time for 4.7) and in case add explicit noexcept.
[Bug libstdc++/51452] has_nothrow_.*constructor bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51452 --- Comment #4 from Jonathan Wakely 2011-12-07 17:38:39 UTC --- yes, I keep forgetting that noexcept should be implied on dtors now
[Bug fortran/51448] [4.6/4.7 Regression] Compiler crash when assigning floating point values of different kinds
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51448 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P4 CC||jakub at gcc dot gnu.org Component|libfortran |fortran
[Bug target/51354] [4.7 Regression] ICE in maybe_record_trace_start
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51354 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #3 from Jakub Jelinek 2011-12-07 17:47:33 UTC --- Fixed.
[Bug c++/51453] New: Feature request: Implement Empty Base Optimization in std::tuple
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51453
Bug #: 51453
Summary: Feature request: Implement Empty Base Optimization in
std::tuple
Classification: Unclassified
Product: gcc
Version: 4.6.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: naso...@hotmail.com
Is it possible to implement empty base optimization on std::tuple, so that
tuples with member free elements have no memory footprint?
struct _Tuple_impl<_Idx>
{
...
protected:
short dummy[0]; // NEW
void _M_swap_impl(_Tuple_impl&) { /* no-op */ }
};
simple test:
#include
...
class empty { short d[0]; };
std::tuple a;
std::cout << sizeof(a) << std::endl; // 2 without tuple ebo (current), and
0 with tuple ebo
...
Best,
Nasos
[Bug c++/51454] New: For loop improper scoping
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51454
Bug #: 51454
Summary: For loop improper scoping
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: pubb...@gmail.com
gcc version 4.7.0 20111203 (experimental) (GCC)
This worked on 4.6, but isn't on 4.7:
for(float x = 0.0f; int x = 0;);
error: redeclaration of ‘int x’
error: ‘float x’ previously declared here
It should be equivalent to this which compiles correctly:
{
float x = 0.0f;
while (int x = 0) { ; }
}
[Bug preprocessor/49973] Column numbers count special characters as multiple columns
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49973 Tom Tromey changed: What|Removed |Added CC||tromey at gcc dot gnu.org Component|c++ |preprocessor --- Comment #9 from Tom Tromey 2011-12-07 17:59:52 UTC --- (In reply to comment #6) > The GCS says "column numbers should start from 1 at the beginning of the > line ... Calculate column numbers assuming that space and all ASCII > printing characters have equal width, and assuming tab stops every 8 > columns.". This doesn't say how other characters should be counted, > although for the results of wcswidth seem appropriate. Note that GCC also handles the tab case incorrectly here. This shows up if you M-x next-error in Emacs in the case where gcc emits column numbers and your source code includes tabs.\ Refiling this to preprocessor.
[Bug libstdc++/51453] Feature request: Implement Empty Base Optimization in std::tuple
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51453 Paolo Carlini changed: What|Removed |Added Component|c++ |libstdc++ --- Comment #1 from Paolo Carlini 2011-12-07 18:01:22 UTC --- I don't think we should fiddle with illegal zero lenght arrays in the C++11 library, even if in general it's a GNU E extension. Of course we are already exploiting EBO for portable data types.
[Bug libstdc++/51453] Feature request: Implement Empty Base Optimization in std::tuple
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51453 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME --- Comment #2 from Jonathan Wakely 2011-12-07 18:08:06 UTC --- (In reply to comment #0) > // 2 without tuple ebo (current), and 0 with tuple ebo A complete object cannot have zero size. std::tuple is exploiting the EBO *more* than it should (see PR 51365) but as long as you don't use 'final' it will already do what you want
[Bug c/51455] New: Possible uninitialized register use when array subscript is unsigned
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51455
Bug #: 51455
Summary: Possible uninitialized register use when array
subscript is unsigned
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: frederik.dewee...@gmail.com
This happens on 4.4, 4.5 and 4.6, with and without strict aliasing.
The following C code:
==
#include
#define SIZE 128
int main(void)
{
int buf[SIZE];
char offsets[SIZE];
int index = 13;
int ret;
int i;
for (i = 0; i < SIZE; i++) {
buf[i] = i;
offsets[i] = (char)i;
}
asm volatile ("mov $0xfafafafafafafafa, %%rax" : : : "rax");
asm volatile ("nop" : : : "memory");
//ret = buf[offsets[index]];
/* XXX: Unsigned subscript here */
ret = buf[((unsigned char *)offsets)[index]];
asm volatile ("nop" : : : "memory");
return ret;
}
==
Generates the following asm for the array access:
0x00400476 <+54>:movabs $0xfafafafafafafafa,%rax
0x00400480 <+64>:nop
0x00400481 <+65>:movzbl 0x20d(%rsp),%eax
0x00400489 <+73>:mov(%rsp,%rax,4),%eax
0x0040048c <+76>:nop
Note how we init eax first and then use rax as an index.
On the other hand, if I remove the cast to 'unsigned char *' (commented in the
snippet above), I get:
0x00400476 <+54>:movabs $0xfafafafafafafafa,%rax
0x00400480 <+64>:nop
0x00400481 <+65>:movsbq 0x20d(%rsp),%rax
0x0040048a <+74>:mov(%rsp,%rax,4),%eax
0x0040048d <+77>:nop
Which initalizes the full rax register, as I would expect.
The questions I have are:
- shouldn't the full rax register be set in the 'unsigned char *' version as
well?
- is there any warranty that movzbl will zero eax's upper 4 bytes in the
'unsigned char *' version? I can't get the program to crash on the systems I
tested, and I would have expected they would, as AMD's docs don't mention the
zeroing of the upper 4 bytes.
Thanks,
Frederik
[Bug libstdc++/51452] has_nothrow_.*constructor bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51452 --- Comment #5 from d...@boost-consulting.com 2011-12-07 18:41:12 UTC --- (In reply to comment #1) > I think this is by design, see the thread beginning with c++std-lib-30698 > > I've been surprised by that reasoning several times e.g. > http://gcc.gnu.org/ml/gcc-help/2011-11/msg00015.html I see the thread. I don't see anything in the thread that supports the idea that it should behave this way, but maybe I'm missing something.
[Bug other/51417] Cross-compiler - wrappers for ar, nm, ranlib installed under wrong names
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51417 --- Comment #2 from Andi Kleen 2011-12-07 18:54:57 UTC --- Hmm, you mean a copy with the version number in addition? Would be reasonable I guess.
[Bug libstdc++/51452] has_nothrow_.*constructor bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51452 --- Comment #6 from Jonathan Wakely 2011-12-07 19:03:30 UTC --- c++std-lib-30708 has Daniel's explanation of his interpretation, as implemented in GCC. FWIW I prefer your interpretation, but will peace Daniel to comment further
[Bug rtl-optimization/51051] [4.7 Regression]: build fails on cris-elf building libstdc++-v3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51051 --- Comment #12 from Hans-Peter Nilsson 2011-12-07 19:07:27 UTC --- (In reply to comment #11) > I still have HP's patch in my local tree. I assume you mean Bernd's patch referenced in this PR. (I was only doing the legwork.) > Should I remove it? Or does it need > to be committed? Both are committed, see comments 8 and 9. Please look into what makes it look different in your tree. brgds, H-P
[Bug c/51455] Possible uninitialized register use when array subscript is unsigned
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51455 --- Comment #1 from Andrew Pinski 2011-12-07 19:10:55 UTC --- ((unsigned char *)offsets)[index] still sign extends to int.
[Bug c++/51454] For loop improper scoping
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51454 --- Comment #1 from Paolo Carlini 2011-12-07 19:19:17 UTC --- Note that ICC and Comeau also reject it in strict mode.
[Bug middle-end/45416] [4.5/4.6/4.7 Regression] Code size regression between 4.6/4.7(4.5) and 4.4 for ARM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45416 --- Comment #13 from Andrew Pinski 2011-12-07 19:23:13 UTC --- Author: pinskia Date: Wed Dec 7 19:23:10 2011 New Revision: 182084 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=182084 Log: 2011-12-07 Andrew Pinski PR middle-end/45416 * expr.c (do_store_flag): Rewrite code that looks for BIT_AND_EXPR for SSA-expand. 2011-12-07 Andrew Pinski PR middle-end/45416 * gcc.dg/pr45416.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/pr45416.c Modified: trunk/gcc/ChangeLog trunk/gcc/expr.c trunk/gcc/testsuite/ChangeLog
[Bug middle-end/45416] [4.5/4.6 Regression] Code size regression between 4.6/4.7(4.5) and 4.4 for ARM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45416 Andrew Pinski changed: What|Removed |Added Status|ASSIGNED|NEW Known to work||4.7.0 AssignedTo|pinskia at gcc dot gnu.org |unassigned at gcc dot ||gnu.org Summary|[4.5/4.6/4.7 Regression]|[4.5/4.6 Regression] Code |Code size regression|size regression between |between 4.6/4.7(4.5) and|4.6/4.7(4.5) and 4.4 for |4.4 for ARM |ARM --- Comment #14 from Andrew Pinski 2011-12-07 19:24:22 UTC --- Fixed on the trunk. If someone wants to backport the patch, that is ok with me.
[Bug c/51455] Possible uninitialized register use when array subscript is unsigned
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51455 --- Comment #2 from frederik.deweerdt at gmail dot com 2011-12-07 19:25:30 UTC --- (In reply to comment #1) > ((unsigned char *)offsets)[index] still sign extends to int. I'm not sure how to parse this. My problem is that '((unsigned char *)offsets)[index]' uses the 'l' version of mov and eax as destination register. I would expect the generate asm to use the 'q' version of mov and use rax as destination register.
[Bug c/51455] Possible uninitialized register use when array subscript is unsigned
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51455 --- Comment #3 from Andrew Pinski 2011-12-07 19:28:29 UTC --- movzbl 0x20d(%rsp),%eax is the same as: movzbq 0x20d(%rsp),%rax as all l instructions zero extend to q.
[Bug c/51455] Possible uninitialized register use when array subscript is unsigned
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51455 --- Comment #4 from Jakub Jelinek 2011-12-07 19:30:21 UTC --- Probably time for you to read the docs. E.g. AMD 24592 pdf, in 3.1.2 says: "In general, byte and word operands are stored in the low 8 or 16 bits of GPRs without modifying their high 56 or 48 bits, respectively. Doubleword operands, however, are normally stored in the low 32 bits of GPRs and zero-extended to 64 bits." Of course movzbl insn clears all upper 56 bits of the destination register, like movzbq, but is one byte shorter.
[Bug c/51455] Possible uninitialized register use when array subscript is unsigned
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51455 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jakub at gcc dot gnu.org Resolution||INVALID --- Comment #5 from Jakub Jelinek 2011-12-07 19:31:10 UTC --- Invalid.
[Bug libstdc++/51456] New: gcc-4.5.3 ARM misaligned relocation for __gxx_personality_v0 in libstdc++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51456
Bug #: 51456
Summary: gcc-4.5.3 ARM misaligned relocation for
__gxx_personality_v0 in libstdc++
Classification: Unclassified
Product: gcc
Version: 4.5.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: junkmailnotr...@yahoo.com
gcc-4.5.3 cross-compiled for ARM generates a misaligned relocation for
__gxx_personality_v0 in libstdc++.
This was found when running Mozilla Fennec, but also occurs with trivial
programs linked against libstdc++ such as Hello World.
C file hello.c contains:
#include
int main(void)
{
printf("hello world\n");
return (0);
}
Compiled on an x86_64 host as follows:
% arm-softfloat-linux-gnueabi-gcc -o hello hello.c -lstdc++
%
Run on an ARM target (iPAQ hx4700) produces the following:
# ./hello
Bus error
#
Adding ld.so debug produces the following:
# export LD_DEBUG=all
# ./hello
682:
682: relocation processing: /lib/libstdc++.so.6 (lazy)
682: symbol=__gxx_personality_v0; lookup in file=./hello [0]
682: symbol=__gxx_personality_v0; lookup in
file=/lib/libstdc++.so.6 [0]
682: binding file /lib/libstdc++.so.6 [0] to /lib/libstdc++.so.6
[0]: normal symbol `__gxx_personality_v0' [CXXABI_1.3]
Bus error
#
Running objdump on the host shows the misaligned symbol:
% arm-softfloat-linux-gnueabi-objdump -R
/usr/lib/gcc/arm-softfloat-linux-gnueabi/4.5.3/libstdc++.so.6.0.14 | fgrep
__gxx_personality_v0
00107afb R_ARM_ABS32 __gxx_personality_v0
00124848 R_ARM_JUMP_SLOT __gxx_personality_v0
%
The version information returned by gcc-4.5.3 is the following:
% arm-softfloat-linux-gnueabi-gcc -v
Using built-in specs.
COLLECT_GCC=/usr/x86_64-pc-linux-gnu/arm-softfloat-linux-gnueabi/gcc-bin/4.5.3/arm-softfloat-linux-gnueabi-gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/arm-softfloat-linux-gnueabi/4.5.3/lto-wrapper
Target: arm-softfloat-linux-gnueabi
Configured with:
/var/tmp/portage/cross-arm-softfloat-linux-gnueabi/gcc-4.5.3-r1/work/gcc-4.5.3/configure
--prefix=/usr
--bindir=/usr/x86_64-pc-linux-gnu/arm-softfloat-linux-gnueabi/gcc-bin/4.5.3
--includedir=/usr/lib/gcc/arm-softfloat-linux-gnueabi/4.5.3/include
--datadir=/usr/share/gcc-data/arm-softfloat-linux-gnueabi/4.5.3
--mandir=/usr/share/gcc-data/arm-softfloat-linux-gnueabi/4.5.3/man
--infodir=/usr/share/gcc-data/arm-softfloat-linux-gnueabi/4.5.3/info
--with-gxx-include-dir=/usr/lib/gcc/arm-softfloat-linux-gnueabi/4.5.3/include/g++-v4
--host=x86_64-pc-linux-gnu --target=arm-softfloat-linux-gnueabi
--build=x86_64-pc-linux-gnu --disable-altivec --disable-fixed-point
--without-ppl --without-cloog --disable-lto --with-float=soft --disable-nls
--with-system-zlib --disable-werror --enable-secureplt --disable-multilib
--enable-libmudflap --disable-libssp --disable-libgomp
--with-python-dir=/share/gcc-data/arm-softfloat-linux-gnueabi/4.5.3/python
--enable-checking=release --disable-libgcj --enable-languages=c,c++
--with-sysroot=/usr/arm-softfloat-linux-gnueabi --disable-bootstrap
--enable-__cxa_atexit --enable-clocale=gnu
--with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo 4.5.3-r1 p1.0,
pie-0.4.5'
Thread model: posix
gcc version 4.5.3 (Gentoo 4.5.3-r1 p1.0, pie-0.4.5)
%
[Bug libstdc++/51456] gcc-4.5.3 ARM misaligned relocation for __gxx_personality_v0 in libstdc++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51456 --- Comment #1 from Andrew Pinski 2011-12-07 19:43:26 UTC --- What version of glibc are you using? glibc should be handling the unaligned relocation correctly. Also GCC is correct here in using the unaligned relocation.
[Bug libstdc++/51456] gcc-4.5.3 ARM misaligned relocation for __gxx_personality_v0 in libstdc++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51456 --- Comment #2 from Andrew Pinski 2011-12-07 19:44:09 UTC --- See http://gcc.gnu.org/ml/gcc-help/2005-07/msg00325.html for a problem against MIPS for the same unaligned relocation.
[Bug libstdc++/51386] [4.7 Regression]: 23_containers/unordered_set/hash_policy/load_factor.cc execution timeout
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51386 --- Comment #8 from François Dumont 2011-12-07 19:47:08 UTC --- Author: fdumont Date: Wed Dec 7 19:47:03 2011 New Revision: 182085 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=182085 Log: 2011-12-07 François Dumont PR libstdc++/51386 * include/bits/hashtable_policy.h (_Prime_rehash_policy::_M_next_bkt): Fix computation of _M_prev_resize so that hashtable do not keep on being rehashed when _M_max_load_factor is lower than 1. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/hashtable_policy.h
[Bug c++/51369] [c++0x] [4.7 Regression] ICE using constexpr in template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51369 --- Comment #1 from Jakub Jelinek 2011-12-07 19:51:57 UTC --- Author: jakub Date: Wed Dec 7 19:51:54 2011 New Revision: 182086 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=182086 Log: PR c++/51369 * init.c (build_value_init): Allow array types even when processing_template_decl. * g++.dg/cpp0x/constexpr-51369.C: New test. Added: trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-51369.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/init.c trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/51446] -fno-trapping-math generates NaN constant with different sign
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51446 --- Comment #2 from lucier at math dot purdue.edu 2011-12-07 19:55:32 UTC --- I don't understand what you're saying. On my linux box heine:~/Downloads> uname -a Linux heine 3.0.0-13-generic #22-Ubuntu SMP Wed Nov 2 13:27:26 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux and with this compiler: heine:~/Downloads> /pkgs/gcc-4.6.2/bin/gcc -v Using built-in specs. COLLECT_GCC=/pkgs/gcc-4.6.2/bin/gcc COLLECT_LTO_WRAPPER=/pkgs/gcc-4.6.2/libexec/gcc/x86_64-unknown-linux-gnu/4.6.2/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../../gcc-4.6.2/configure --prefix=/pkgs/gcc-4.6.2 --enable-languages=c --disable-multilib Thread model: posix gcc version 4.6.2 (GCC) I get exactly the same results as in my initial report. Do you mean that you get different results with the SVN version of 4.6.2? Brad
