[Bug target/46072] AIX linker chokes on debug info for uninitialized static variables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46072 Michael Haubenwallner michael.haubenwallner at salomon dot at changed: What|Removed |Added CC||michael.haubenwallner at ||salomon dot at --- Comment #3 from Michael Haubenwallner michael.haubenwallner at salomon dot at 2011-01-25 08:29:49 UTC --- Same here with gcc-4.2.4 on AIX5.3 after upgrading from TL10 to TL12. (need to figure out the exact details of the problem myself yet) Which information is necessary here to help this getting fixed?
[Bug fortran/47448] Invalid check for ASSIGNMENT(=)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47448 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Keywords||rejects-valid Summary|Accepts invalid |Invalid check for |ASSIGNMENT(=) which |ASSIGNMENT(=) |overrides intrinsic | |assignment | --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org 2011-01-25 08:30:41 UTC --- Draft patch. The typo seems to go back to the commit for PR 37425, committed 2009-08-10. However, it seems only to be an accepts-invalid regression. Before the valid and the invalid form were rejected, currently only the valid form is rejected - the invalid is accepted. --- a/gcc/fortran/interface.c +++ b/gcc/fortran/interface.c @@ -654,11 +654,12 @@ gfc_check_operator_interface (gfc_symbol *sym, gfc_intrinsic_op op, /* Allowed are (per F2003, 12.3.2.1.2 Defined assignments): - First argument an array with different rank than second, -- Types and kinds do not conform, and +- First argument is a scalar and second an array, +- Types and kinds do not conform, or - First argument is of derived type. */ if (sym-formal-sym-ts.type != BT_DERIVED sym-formal-sym-ts.type != BT_CLASS - (r1 == 0 || r1 == r2) + (r2 == 0 || r1 == r2) (sym-formal-sym-ts.type == sym-formal-next-sym-ts.type || (gfc_numeric_ts (sym-formal-sym-ts) gfc_numeric_ts (sym-formal-next-sym-ts
[Bug middle-end/45422] [4.6 Regression] compile time increases 3x.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45422 --- Comment #32 from Jakub Jelinek jakub at gcc dot gnu.org 2011-01-25 09:02:57 UTC --- IMHO for P1 purposes we should just look at compile time regressions from 4.5 here at this point. On the #c1 testcase I get with --enable-checking=release current trunk and current 4.5 branch on x86_64-linux: 4.6 x86_64 -m64 -O3 -fbounds-check -ftime-report df live regs : 1.87 ( 3%) usr 0.02 ( 1%) sys 1.66 ( 3%) wall 0 kB ( 0%) ggc parser: 1.04 ( 2%) usr 0.20 ( 9%) sys 1.24 ( 2%) wall 53425 kB ( 6%) ggc tree VRP : 1.82 ( 3%) usr 0.09 ( 4%) sys 2.02 ( 3%) wall 63870 kB ( 8%) ggc tree PTA : 1.02 ( 2%) usr 0.01 ( 0%) sys 0.98 ( 2%) wall 5498 kB ( 1%) ggc tree SSA incremental : 1.23 ( 2%) usr 0.12 ( 6%) sys 1.11 ( 2%) wall 6733 kB ( 1%) ggc tree CCP : 1.33 ( 2%) usr 0.03 ( 1%) sys 1.33 ( 2%) wall 4989 kB ( 1%) ggc complete unrolling: 1.07 ( 2%) usr 0.16 ( 8%) sys 1.28 ( 2%) wall 88755 kB (11%) ggc tree iv optimization : 10.99 (19%) usr 0.09 ( 4%) sys 11.09 (19%) wall 138994 kB (16%) ggc CSE : 1.28 ( 2%) usr 0.01 ( 0%) sys 1.28 ( 2%) wall 229 kB ( 0%) ggc combiner : 2.00 ( 3%) usr 0.00 ( 0%) sys 1.95 ( 3%) wall 31554 kB ( 4%) ggc integrated RA : 3.68 ( 6%) usr 0.01 ( 0%) sys 3.78 ( 6%) wall 19906 kB ( 2%) ggc reload: 2.04 ( 4%) usr 0.00 ( 0%) sys 2.18 ( 4%) wall 7106 kB ( 1%) ggc reload CSE regs : 2.04 ( 4%) usr 0.02 ( 1%) sys 2.01 ( 3%) wall 12188 kB ( 1%) ggc scheduling 2 : 2.55 ( 4%) usr 0.01 ( 0%) sys 2.61 ( 4%) wall 895 kB ( 0%) ggc TOTAL : 57.47 2.1159.60 845009 kB 4.5 x86_64 -m64 -O3 -fbounds-check -ftime-report df live regs : 1.58 ( 4%) usr 0.00 ( 0%) sys 1.39 ( 3%) wall 0 kB ( 0%) ggc parser: 1.02 ( 2%) usr 0.18 ( 9%) sys 1.21 ( 3%) wall 55472 kB ( 7%) ggc tree VRP : 1.39 ( 3%) usr 0.13 ( 6%) sys 1.73 ( 4%) wall 56478 kB ( 8%) ggc tree PRE : 1.03 ( 2%) usr 0.04 ( 2%) sys 1.24 ( 3%) wall 7286 kB ( 1%) ggc complete unrolling: 1.32 ( 3%) usr 0.21 (10%) sys 1.55 ( 3%) wall 91137 kB (12%) ggc tree iv optimization : 5.45 (12%) usr 0.09 ( 4%) sys 5.43 (12%) wall 95576 kB (13%) ggc expand: 2.62 ( 6%) usr 0.16 ( 8%) sys 2.76 ( 6%) wall 58104 kB ( 8%) ggc CSE : 1.18 ( 3%) usr 0.01 ( 0%) sys 0.94 ( 2%) wall 261 kB ( 0%) ggc combiner : 1.53 ( 3%) usr 0.00 ( 0%) sys 1.48 ( 3%) wall 19953 kB ( 3%) ggc integrated RA : 3.21 ( 7%) usr 0.00 ( 0%) sys 3.55 ( 8%) wall 11410 kB ( 2%) ggc reload: 2.13 ( 5%) usr 0.04 ( 2%) sys 2.00 ( 4%) wall 7273 kB ( 1%) ggc reload CSE regs : 1.67 ( 4%) usr 0.01 ( 0%) sys 1.55 ( 3%) wall 10032 kB ( 1%) ggc scheduling 2 : 2.65 ( 6%) usr 0.02 ( 1%) sys 2.66 ( 6%) wall 1063 kB ( 0%) ggc TOTAL : 44.55 2.0546.62 747832 kB 4.6 x86_64 -m32 -O3 -fbounds-check -ftime-report df live regs : 1.24 ( 2%) usr 0.02 ( 1%) sys 1.05 ( 2%) wall 0 kB ( 0%) ggc parser: 1.05 ( 2%) usr 0.18 ( 9%) sys 1.23 ( 2%) wall 53861 kB ( 7%) ggc tree VRP : 1.48 ( 3%) usr 0.05 ( 2%) sys 1.78 ( 3%) wall 52970 kB ( 7%) ggc tree iv optimization : 9.92 (19%) usr 0.15 ( 7%) sys 9.98 (18%) wall 125735 kB (17%) ggc CSE : 1.46 ( 3%) usr 0.00 ( 0%) sys 1.42 ( 3%) wall 329 kB ( 0%) ggc combiner : 1.41 ( 3%) usr 0.01 ( 0%) sys 1.35 ( 2%) wall 20981 kB ( 3%) ggc integrated RA : 2.89 ( 6%) usr 0.00 ( 0%) sys 2.83 ( 5%) wall 14083 kB ( 2%) ggc reload: 2.59 ( 5%) usr 0.02 ( 1%) sys 2.58 ( 5%) wall 18918 kB ( 3%) ggc reload CSE regs : 2.62 ( 5%) usr 0.00 ( 0%) sys 2.91 ( 5%) wall 13557 kB ( 2%) ggc scheduling 2 : 2.49 ( 5%) usr 0.01 ( 0%) sys 2.45 ( 5%) wall 953 kB ( 0%) ggc TOTAL : 52.36 2.0254.39 744417 kB 4.5 x86_64 -m32 -O3 -fbounds-check -ftime-report df live regs : 1.41 ( 3%) usr 0.02 ( 1%) sys 1.43 ( 3%) wall 0 kB ( 0%) ggc parser: 1.02 ( 2%) usr 0.18 ( 9%) sys 1.19 ( 2%) wall 55913 kB ( 8%) ggc tree VRP : 1.44 ( 3%) usr 0.14 ( 7%) sys 1.39 ( 3%) wall 54451 kB ( 8%) ggc tree iv optimization : 7.76 (17%) usr 0.11 ( 5%) sys 8.02 (17%) wall 107362 kB (15%) ggc expand: 2.66 ( 6%) usr 0.08 ( 4%) sys 2.73 ( 6%) wall 56088 kB ( 8%) ggc CSE : 1.41 ( 3%) usr 0.00 (
[Bug gcov-profile/38292] [4.3/4.4/4.5/4.6 Regression] corrupted profile info with -O[23] -fprofile-use
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38292 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |NEW CC||manu at gcc dot gnu.org --- Comment #16 from Manuel López-Ibáñez manu at gcc dot gnu.org 2011-01-25 09:20:23 UTC --- (In reply to comment #15) hmm, can't set the status back to NEW, just to RESOLVED. ... You have to use your gcc account (I think).
[Bug fortran/47439] Fun with scratch files on Windows MKTEMP only allows for 26 files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47439 --- Comment #1 from Janne Blomqvist jb at gcc dot gnu.org 2011-01-25 09:28:14 UTC --- Seems the reason for Windows _mktemp() behavior is due to replicating some age-old BSD behavior. From the Linux mktemp(3) manpage: BUGS Never use mktemp(). Some implementations follow 4.3BSD and replace XX by the current process ID and a single letter, so that at most 26 different names can be returned. Since on the one hand the names are easy to guess, and on the other hand there is a race between testing whether the name exists and opening the file, every use of mktemp() is a security risk. The race is avoided by mkstemp(3). (Needless to say, libgfortran use mkstemp() ifavailable, mktemp() is just a fallback.)
[Bug rtl-optimization/47454] New: registers are not allocated according to its preferred order
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47454
Summary: registers are not allocated according to its preferred
order
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: car...@google.com
Target: arm-linux-androideabi
Created attachment 23115
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23115
testcase
The attached test case is extracted from zlib, when compiled by gcc4.6 with
options -march=armv7-a -mthumb -Os, I got the following code
push{r4, r5, r6, r7, r8, lr}
movr6, r0
movr4, r1
cmpr0, #0
beq.L2
ldrr5, [r0, #0]
cmpr5, #0
beq.L2
cmpr1, #0
bge.L3
negsr4, r1
movsr7, #0
b.L4
.L3:
asrsr7, r1, #4
addsr7, r7, #1
cmpr1, #47
itle
andler4, r1, #15
.L4:
addsr3, r4, #0
subr8, r4, #8
itne
movner3, #1
cmpr8, #7
itels
movlsr8, #0
andhir8, r3, #1
cmpr8, #0
bne.L2
ldrr1, [r5, #8]
cbzr1, .L5
ldrr3, [r5, #4]
cmpr3, r4
beq.L5
ldrr3, [r6, #4]
ldrr0, [r6, #8]
blxr3
strr8, [r5, #8]
.L5:
strr7, [r5, #0]
movr0, r6
strr4, [r5, #4]
pop{r4, r5, r6, r7, r8, lr}
binflateReset
.L2:
mvnr0, #1
pop{r4, r5, r6, r7, r8, pc}
Note that register r8 is used many times, but register r2 is never used. In
thumb2 r8 is high register, its usage will cause 32bit instructions. If we
replace r8 with r2, a lot of code size will be reduced in this case.
In arm.h REG_ALLOC_ORDER is defined as
3, 2, 1, 0, 12, 14, 4, 5, 6, 7, 8, 10, 9, 11, 13, 15 ...
We can see that r2 should be used before r8, but the result is not.
[Bug middle-end/45422] [4.6 Regression] compile time increases 3x.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45422 --- Comment #33 from Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch 2011-01-25 09:47:10 UTC --- I just note that the timings reported by David and Jakub are not for the compile options I originally reported. With 4.6 (20110117) I now have gfortran -c -ftime-report -cpp -fbounds-check -g -O3 -ffast-math -funroll-loops -ftree-vectorize -march=native -ffree-form PR45422.F90 TOTAL : 102.15 while with the options used by David / Jakub I have timings similar to theirs. gfortran -O3 -fbounds-check -ftime-report -c PR45422.F90 TOTAL : 42.87 With 4.5 timings remain ~44s
[Bug tree-optimization/47411] [4.5 Regression] Bootstrap failure on x86-64/Darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47411 --- Comment #5 from Richard Guenther rguenth at gcc dot gnu.org 2011-01-25 09:48:12 UTC --- Author: rguenth Date: Tue Jan 25 09:48:07 2011 New Revision: 169222 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=169222 Log: 2011-01-25 Richard Guenther rguent...@suse.de PR tree-optimization/47411 Backport from mainline 2010-06-30 Michael Matz m...@suse.de PR bootstrap/44699 * tree-vrp.c (vrp_finalize): Deal with changing num_ssa_names. Modified: branches/gcc-4_5-branch/gcc/ChangeLog branches/gcc-4_5-branch/gcc/tree-vrp.c
[Bug bootstrap/44699] [4.6 Regression] Bootstrap failure for x86_64-apple-darwin10: ICE while compiling genmodes.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44699 --- Comment #18 from Richard Guenther rguenth at gcc dot gnu.org 2011-01-25 09:48:12 UTC --- Author: rguenth Date: Tue Jan 25 09:48:07 2011 New Revision: 169222 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=169222 Log: 2011-01-25 Richard Guenther rguent...@suse.de PR tree-optimization/47411 Backport from mainline 2010-06-30 Michael Matz m...@suse.de PR bootstrap/44699 * tree-vrp.c (vrp_finalize): Deal with changing num_ssa_names. Modified: branches/gcc-4_5-branch/gcc/ChangeLog branches/gcc-4_5-branch/gcc/tree-vrp.c
[Bug tree-optimization/47411] [4.5 Regression] Bootstrap failure on x86-64/Darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47411 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #6 from Richard Guenther rguenth at gcc dot gnu.org 2011-01-25 09:49:29 UTC --- Should be fixed.
[Bug tree-optimization/47265] [4.6 Regression] Error: SSA name in freelist but still referenced
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47265 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||zsojka at seznam dot cz --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2011-01-25 09:50:52 UTC --- *** Bug 47443 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/47443] [4.6 Regression] ICE: SSA name in freelist but still referenced or SIGSEGV with -fstack-check=generic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47443 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jakub at gcc dot gnu.org Resolution||DUPLICATE --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2011-01-25 09:50:52 UTC --- Apparently dup of PR47265, at least forward_propagate_addr_expr recurses there too and after returning from the recursion suddenly one needed imm use disappeared. *** This bug has been marked as a duplicate of bug 47265 ***
[Bug middle-end/45422] [4.6 Regression] compile time increases 3x.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45422 --- Comment #34 from Jakub Jelinek jakub at gcc dot gnu.org 2011-01-25 09:52:23 UTC --- -march=native is ambiguous, please see with -v what actually is being used.
[Bug rtl-optimization/47414] [4.6 Regression] wrong code with -O -freorder-blocks -fschedule-insns2 -fno-early-inlining -fstrict-aliasing -ftracer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47414 --- Comment #6 from Richard Guenther rguenth at gcc dot gnu.org 2011-01-25 09:55:58 UTC --- Author: rguenth Date: Tue Jan 25 09:55:54 2011 New Revision: 169223 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=169223 Log: 2011-01-25 Richard Guenther rguent...@suse.de PR middle-end/47414 * tree-ssa-alias.c (indirect_ref_may_alias_decl_p): Use the correct type for TBAA. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-alias.c
[Bug rtl-optimization/47414] [4.6 Regression] wrong code with -O -freorder-blocks -fschedule-insns2 -fno-early-inlining -fstrict-aliasing -ftracer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47414 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #7 from Richard Guenther rguenth at gcc dot gnu.org 2011-01-25 09:56:16 UTC --- Fixed.
[Bug c++/37773] -Wfatal-errors aborts too early
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37773 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added CC||manu at gcc dot gnu.org --- Comment #5 from Manuel López-Ibáñez manu at gcc dot gnu.org 2011-01-25 09:57:03 UTC --- (In reply to comment #3) Works as desigened. Really ;) So what is the point of -fmax-errors=N ? Shouldn't the documentation of Wfatal-errors say: This option is not for users but for compiler developers only? BTW, clang also supports -Wfatal-errors=option.
[Bug middle-end/45422] [4.6 Regression] compile time increases 3x.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45422 --- Comment #35 from Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch 2011-01-25 10:03:02 UTC --- (In reply to comment #34) -march=native is ambiguous, please see with -v what actually is being used. This was mentioned in the initial comment: -march=k8-sse3 -mcx16 -msahf --param l1-cache-size=64 --param l1-cache-line-size=64 --param l2-cache-size=1024 -mtune=k8 The latest timings are on a newer machine (old one is gone now) which has: -march=amdfam10 -mcx16 -msahf -mpopcnt -mabm --param l1-cache-size=64 --param l1-cache-line-size=64 --param l2-cache-size=512 -mtune=amdfam10
[Bug c++/37773] -Wfatal-errors aborts too early
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37773 --- Comment #6 from Jonathan Wakely redi at gcc dot gnu.org 2011-01-25 10:08:42 UTC --- (In reply to comment #5) (In reply to comment #3) Works as desigened. Really ;) So what is the point of -fmax-errors=N ? Eh? Surely -fmax-errors *is* the option intended to be useful to users who want to limit the error output. Just because -Wfatal-errors is designed for something different, doesn't mean -fmax-errors has no point.
[Bug tree-optimization/47265] [4.6 Regression] Error: SSA name in freelist but still referenced
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47265 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2011-01-25 10:10:30 UTC --- Alternative solution would be to remember the count of imm uses before doing FOR_EACH_IMM_USE and if the loop does not iterate that many times, return conservatively that not all uses have been seen.
[Bug lto/44334] rnflow.f90 ~27% slower with -fwhole-program -flto after revision 159852
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44334 --- Comment #45 from rguenther at suse dot de rguenther at suse dot de 2011-01-25 10:20:01 UTC --- On Tue, 25 Jan 2011, howarth at nitro dot med.uc.edu wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44334 --- Comment #44 from Jack Howarth howarth at nitro dot med.uc.edu 2011-01-25 03:13:39 UTC --- Testing... Index: gcc/params.def === --- gcc/params.def(revision 169185) +++ gcc/params.def(working copy) @@ -182,7 +182,7 @@ DEFPARAM(PARAM_LARGE_FUNCTION_INSNS, DEFPARAM(PARAM_LARGE_FUNCTION_GROWTH, large-function-growth, Maximal growth due to inlining of large function (in percent), - 100, 0, 0) + 400, 0, 0) DEFPARAM(PARAM_LARGE_UNIT_INSNS, large-unit-insns, The size of translation unit to be considered large, shows only a major improvement for fatigue (30%). This same improvement can be achieved at -m32 and -m64 with just an increase of large-function-growth to 200. We certainly won't adjust params at this stage. There are other cases (that c-ray one) where more aggressive inlining helps, but we should avoid regressing for -O2 and only tune -O3 params eventually.
[Bug tree-optimization/47411] [4.5 Regression] Bootstrap failure on x86-64/Darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47411 --- Comment #7 from Richard Guenther rguenth at gcc dot gnu.org 2011-01-25 10:24:59 UTC --- Author: rguenth Date: Tue Jan 25 10:24:56 2011 New Revision: 169224 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=169224 Log: 2011-01-25 Richard Guenther rguent...@suse.de PR middle-end/47411 * gcc.dg/torture/pr47411.c: New testcase. Added: branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/torture/pr47411.c Modified: branches/gcc-4_5-branch/gcc/testsuite/ChangeLog
[Bug tree-optimization/47411] [4.5 Regression] Bootstrap failure on x86-64/Darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47411 --- Comment #8 from Richard Guenther rguenth at gcc dot gnu.org 2011-01-25 10:26:23 UTC --- Author: rguenth Date: Tue Jan 25 10:26:20 2011 New Revision: 169225 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=169225 Log: 2011-01-25 Richard Guenther rguent...@suse.de PR middle-end/47411 * gcc.dg/torture/pr47411.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr47411.c Modified: trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/47265] [4.6 Regression] Error: SSA name in freelist but still referenced
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47265
--- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2011-01-25
10:27:41 UTC ---
Actually, there is a far easier fix. Either add
if (all !has_zero_uses (name))
all = false;
to the end of forward_propagate_addr_expr, or we could iterate some more,
either like this:
--- gcc/tree-ssa-forwprop.c.jj 2011-01-15 11:26:42.0 +0100
+++ gcc/tree-ssa-forwprop.c 2011-01-25 11:22:02.828495766 +0100
@@ -1061,6 +1061,8 @@ forward_propagate_addr_expr (tree name,
bool all = true;
bool single_use_p = has_single_use (name);
+ do
+ {
FOR_EACH_IMM_USE_STMT (use_stmt, iter, name)
{
bool result;
@@ -1113,6 +1115,7 @@ forward_propagate_addr_expr (tree name,
gsi_remove (gsi, true);
}
}
+ } while (all !has_zero_uses (name));
return all;
}
or say just once or say 4 times:
int i;
for (i = 0; i 4; i++)
{
FOR_EACH_IMM_USE_STMT (use_stmt, iter, name)
{
...
}
if (!all || has_zero_uses (name))
return all;
}
return false;
[Bug tree-optimization/47265] [4.6 Regression] Error: SSA name in freelist but still referenced
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47265 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1
[Bug tree-optimization/47265] [4.6 Regression] Error: SSA name in freelist but still referenced
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47265
--- Comment #6 from Richard Guenther rguenth at gcc dot gnu.org 2011-01-25
10:47:29 UTC ---
(In reply to comment #5)
Actually, there is a far easier fix. Either add
if (all !has_zero_uses (name))
all = false;
to the end of forward_propagate_addr_expr, or we could iterate some more,
either like this:
--- gcc/tree-ssa-forwprop.c.jj 2011-01-15 11:26:42.0 +0100
+++ gcc/tree-ssa-forwprop.c 2011-01-25 11:22:02.828495766 +0100
@@ -1061,6 +1061,8 @@ forward_propagate_addr_expr (tree name,
bool all = true;
bool single_use_p = has_single_use (name);
+ do
+ {
FOR_EACH_IMM_USE_STMT (use_stmt, iter, name)
{
bool result;
@@ -1113,6 +1115,7 @@ forward_propagate_addr_expr (tree name,
gsi_remove (gsi, true);
}
}
+ } while (all !has_zero_uses (name));
return all;
}
or say just once or say 4 times:
int i;
for (i = 0; i 4; i++)
{
FOR_EACH_IMM_USE_STMT (use_stmt, iter, name)
{
...
}
if (!all || has_zero_uses (name))
return all;
}
return false;
Or simply
return all has_zero_uses (name);
?
[Bug fortran/47455] New: internal compiler error: in fold_convert_loc, at fold-const.c: 2028
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47455 Summary: internal compiler error: in fold_convert_loc, at fold-const.c: 2028 Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: thenl...@users.sourceforge.net The following example results in an internal compiler error. Version: gcc version 4.6.0 20110122 (experimental) (GCC) Platform: i686-pc-mingw32 Expected result: Produce proper source diagnostics/error message for the error. module class_t type :: tx integer, dimension(:), allocatable :: i end type tx type :: t type(tx), pointer :: x contains procedure :: calc procedure :: find_x end type t contains subroutine calc(this) class(t), target :: this this%x = this%find_x() end subroutine calc function find_x(this) class(t), intent(in) :: this type(tx), pointer :: find_x find_x = null() end function find_x end module class_t $ gfortran -c class_t.f90 class_t.f90: In function 'calc': class_t.f90:14:0: internal compiler error: in fold_convert_loc, at fold-const.c:2028 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions.
[Bug c/47438] function arguments memory alignment problem.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47438 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2011-01-25 10:50:00 UTC --- And you are using a parameter that was not initialized (passed).
[Bug c++/47444] False warning: array subscript is above array bounds
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47444 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX --- Comment #4 from Richard Guenther rguenth at gcc dot gnu.org 2011-01-25 10:57:27 UTC --- Well. You might argue that the wording should be 'may be' in all cases where the offending statement might not be executed (which is certainly undecidable as you can't know whether the function is executed at all). But it also isn't the way we handle other warnings (in particular the uninitialized variable uses). Thus I think we should not fix this bug (and it is a non-bug, as certainly the code in question isn't obviously dead). Interprocedual analysis could see that we call the function with a boolean value (thus, either 0 or 1). That said - we can't suit everyone with this kind of warnings.
[Bug tree-optimization/47447] [4.3/4.4 Regression] Unable to coalesce ssa_names x and y ICE in tree-ssa-coalesce.c when -O3 is used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47447 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Known to work||4.2.4, 4.5.0, 4.5.1, 4.6.0 Keywords||ice-on-valid-code Last reconfirmed||2011.01.25 11:00:44 Ever Confirmed|0 |1 Summary|Unable to coalesce |[4.3/4.4 Regression] |ssa_names x and y ICE |Unable to coalesce |in tree-ssa-coalesce.c when |ssa_names x and y ICE |-O3 is used |in tree-ssa-coalesce.c when ||-O3 is used Target Milestone|--- |4.3.6 Known to fail||4.3.0, 4.3.5, 4.4.0, 4.4.4 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2011-01-25 11:00:44 UTC --- Confirmed.
[Bug c/47409] volatile struct member bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47409
--- Comment #6 from Richard Guenther rguenth at gcc dot gnu.org 2011-01-25
11:03:10 UTC ---
We should at least make sure to use memcpy for the array part in
struct {
volatile int i;
int a[10];
} a, b;
a = b;
do we really want to blow up code-size (and compile-time) for
struct {
volatile int a[100];
} a, b;
a = b;
? And what's the difference of the above to
volatile struct {
int a[100];
} a, b;
a = b;
?
What do other compilers do for the above? Is there a DR?
[Bug pch/47430] [4.6 Regression] Random PCH related bootstrap failures on powerpc64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47430 --- Comment #4 from Richard Guenther rguenth at gcc dot gnu.org 2011-01-25 11:07:04 UTC --- 2) make sure other PCH is not read during compilation that is writing PCH makes sense to me anyway
[Bug tree-optimization/47428] [4.6 Regression] ICE: tree check: expected ssa_name, have integer_cst in copy_phis_for_bb, at tree-inline.c:1986
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47428 --- Comment #5 from Richard Guenther rguenth at gcc dot gnu.org 2011-01-25 11:09:08 UTC --- (In reply to comment #4) Created attachment 23100 [details] gcc46-pr47427.patch Different untested fix. Looks good.
[Bug tree-optimization/47426] [4.6 Regression] wrong code with -O2 -fipa-pta
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47426 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | --- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2011-01-25 11:10:34 UTC --- Mine (it's not really a regression).
[Bug target/47424] [4.6 Regression] Glibc miscompiled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47424 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Keywords||wrong-code Last reconfirmed||2011.01.25 11:11:25 Ever Confirmed|0 |1 Target Milestone|--- |4.6.0 Build||x86_64-*-linux --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2011-01-25 11:11:25 UTC --- Testcase?
[Bug lto/47423] Many testsuite failures caused by missing gxx_visibility_sj0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47423
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Keywords||EH, lto
Status|UNCONFIRMED |WAITING
Last reconfirmed||2011.01.25 11:18:37
CC||hubicka at gcc dot gnu.org,
||rguenth at gcc dot gnu.org
Ever Confirmed|0 |1
--- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2011-01-25
11:18:37 UTC ---
Does
Index: cgraphbuild.c
===
--- cgraphbuild.c (revision 169155)
+++ cgraphbuild.c (working copy)
@@ -141,6 +141,11 @@ record_eh_tables (struct cgraph_node *no
{
eh_region i;
+ if (DECL_FUNCTION_PERSONALITY (node-decl))
+ipa_record_reference (node, NULL,
+ cgraph_node (DECL_FUNCTION_PERSONALITY (node-decl)),
+ NULL, IPA_REF_ADDR, NULL);
+
i = fun-eh-region_tree;
if (!i)
return;
fix it? If we'd LTO libsupc++ we have to makr the personality function
as address-taken.
[Bug java/47456] New: internal compiler error: Segmentation fault while using jna
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47456 Summary: internal compiler error: Segmentation fault while using jna Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: java AssignedTo: unassig...@gcc.gnu.org ReportedBy: steve.rei...@iws.fraunhofer.de i tried to use the java native compiler 1.1.1 application for compiling java code to native code. i use gcj for compiling for windows. in the application i use jna. in the line where i try to load the dmx4all.dll the compiler breaks with the following error: creating Main.exe for Windows - processing 3D_Viewer_NEW.jar de/fraunhofer/iws/dmxcontrol/DMXControl.java:29: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. failed... that's why I'm reporting this bug. can you help me or fix this bug so that i can compile my project? the version of the compiler is gcc-122233-win.zip. i got it from your homepage. regards steve reinke
[Bug fortran/47455] [4.6 Regression][OOP] internal compiler error: in fold_convert_loc, at fold-const.c:2028
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47455 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-valid-code CC||burnus at gcc dot gnu.org, ||janus at gcc dot gnu.org Summary|internal compiler error: in |[4.6 Regression][OOP] |fold_convert_loc, at|internal compiler error: in |fold-const.c: 2028 |fold_convert_loc, at ||fold-const.c:2028 --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org 2011-01-25 11:19:44 UTC --- (I have not checked the validity of the code, but ifort 11.1, gfortran 4.5 and NAG 5.1 accept the code.)
[Bug java/47456] internal compiler error: Segmentation fault while using jna
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47456 steve.reinke at iws dot fraunhofer.de changed: What|Removed |Added Severity|normal |blocker
[Bug c/47418] warning: array subscript is above array bounds at O2 with sin6_addr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47418 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.01.25 11:24:58 Ever Confirmed|0 |1 --- Comment #4 from Richard Guenther rguenth at gcc dot gnu.org 2011-01-25 11:24:58 UTC --- VRP sees bb 2: D.2725_3 = u.sa_data[15]; D.2726_4 = (int) D.2725_3; D.2728_6 = u.sa_data[14]; D.2729_7 = (int) D.2728_6; ... D.2769_47 = u.sa_data[0]; D.2770_48 = (int) D.2769_47; test_func (0, D.2770_48, D.2768_46, D.2765_43, D.2762_40, D.2759_37, D.2756_34, D.2753_31, D.2750_28, D.2747_25, D.2744_22, D.2741_19, D.2738_16, D.2735_13, D.2732_10, D.2729_7, D.2726_4); return 0; because of our fancy way of re-building non-addressed components. With 4.6 the warning is gone and we instead have (thanks to MEM-REF): bb 2: D.2695_3 = MEM[(char *)u + 15B]; D.2696_4 = (int) D.2695_3; D.2698_6 = MEM[(char *)u + 14B]; D.2699_7 = (int) D.2698_6; ... D.2740_48 = (int) D.2739_47; test_func (0, D.2740_48, D.2738_46, D.2735_43, D.2732_40, D.2729_37, D.2726_34, D.2723_31, D.2720_28, D.2717_25, D.2714_22, D.2711_19, D.2708_16, D.2705_13, D.2702_10, D.2699_7, D.2696_4); return 0; thus, no more array access and still non-address-taken u. 4.4 also warns about small-test.c: In function 'main': small-test.c:18: warning: array subscript is above array bounds small-test.c:18: warning: array subscript is above array bounds small-test.c:18: warning: array subscript is above array bounds small-test.c:18: warning: 'u' is used uninitialized in this function 4.3 doesn't warn at all. Confirmed. I'd close it as fixed in 4.6 and add a testcase (no time for that right now).
[Bug c++/47417] [4.6 Regression][C++0x] error: use of deleted function 'S::S(const S)'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47417 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||rejects-valid Target Milestone|--- |4.6.0
[Bug c++/47416] [4.6 Regression] ICE in build_data_member_initialization, at cp/semantics.c:5509
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47416 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.6.0
[Bug c/47438] function arguments memory alignment problem.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47438
--- Comment #4 from doh-hyun koh dbms007 at hanmail dot net 2011-01-25
11:28:51 UTC ---
#include stdio.h
int Test1(tranNo, name, path, sSpId, spId, spPg, type, size, parm)
long tranNo;
char* name, *path;
short sSpId, spId, spPg, type;
long size;
char* parm;
{
printf(--- size : %ld\n, size);
}
int Test2(tranNo, name, path, sSpId, spId, spPg, size, type, parm)
long tranNo;
char* name, *path;
short sSpId, spId, spPg;
long size;
short type;
char* parm;
{
printf(--- size : %ld\n, size);
}
main()
{
int xx = 7974288;
Test1(xx);
Test2(xx);
}
compiler option
gcc -O -m64 test.c
Would u please try again ?
[Bug tree-optimization/47413] Constant Propagation and Virtual Function Tables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47413 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||missed-optimization Status|UNCONFIRMED |NEW Last reconfirmed||2011.01.25 11:35:50 CC||rguenth at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2011-01-25 11:35:50 UTC --- With GCC 4.6 I see bb 3: obj_11-vtab = vtab1337; D.3820_15 = f1337 (obj_11); printf (%d\n[0], D.3820_15); so it calls f1337 directly, but it doesn't inline it. We are partly confused by the CFG caused by the NULL test: bb 2: obj_11 = malloc (8); if (obj_11 == 0B) goto bb 4; else goto bb 3; bb 3: obj_11-vtab = vtab1337; bb 4: # obj_12 = PHI 0B(2), obj_11(3) if (obj_12 == 0B) goto bb 6; else goto bb 5; bb 5: D.3822_13 = obj_12-vtab; D.3821_14 = D.3822_13-f; D.3820_15 = D.3821_14 (obj_12); so it takes several iterations through different optimizers to eventually constant propagate the function address (jump-threading the test in BB4, which only happens late by DOM).
[Bug fortran/47455] [4.6 Regression][OOP] internal compiler error: in fold_convert_loc, at fold-const.c:2028
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47455 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 Target Milestone|--- |4.6.0
[Bug fortran/25071] dummy argument larger than actual argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25071 Janne Blomqvist jb at gcc dot gnu.org changed: What|Removed |Added Status|RESOLVED|REOPENED CC||jb at gcc dot gnu.org Resolution|FIXED | --- Comment #7 from Janne Blomqvist jb at gcc dot gnu.org 2011-01-25 12:01:17 UTC --- Reopening.. (In reply to comment #6) I believe this is fixed by PR30940. The first example gives: Warnung: Actual argument contains too few elements for dummy argument 'i' (4/6) at (1) The second example: Warnung: Character length of actual argument shorter than of dummy argument 'y' (10/20) at (1) It currently gives only warnings since I failed to get any comments when an error and when only a warning should be given. Sorry for being 'a bit' late with comments, but IMHO this should be an error and not just a warning, because 1) The standard says so 2) Other compilers reject it (so we can't argue that we must support this common extension) 3) Not rejecting it makes it really easy to corrupt memory. Consider program x character(len=10) :: a, b, c a = 1234567890 b = a c = a call xx2(b) print *, '::', a, '::', b, '::', c, '::' contains subroutine xx2(name) character(len=20), intent(inout) :: name name = 'hi' end subroutine xx2 end program This prints (gfortran 4.4, x86_64 Linux): $ ./chardummy2 ::567890::hi::1234567890:: That is, blanking out the remaining 18 characters at the end of the character b passed to xx2 overwrites part of the character a (why are only 4 characters overwritten and not all 10? because they are allocated 4/8/16? byte aligned on the stack). Note that neither bounds checking nor valgrind detects this error. Missing is the check for array element designators: PR32616. I haven't looked, but maybe PR30940 and PR32616 would need to be fixed as well?
[Bug tree-optimization/47428] [4.6 Regression] ICE: tree check: expected ssa_name, have integer_cst in copy_phis_for_bb, at tree-inline.c:1986
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47428 --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org 2011-01-25 12:01:57 UTC --- Author: jakub Date: Tue Jan 25 12:01:54 2011 New Revision: 169226 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=169226 Log: PR tree-optimization/47427 PR tree-optimization/47428 * tree-ssa-copyrename.c (copy_rename_partition_coalesce): Don't coalesce if the new root var would be TREE_READONLY. * gcc.c-torture/compile/pr47427.c: New test. * gcc.c-torture/compile/pr47428.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr47427.c trunk/gcc/testsuite/gcc.c-torture/compile/pr47428.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-copyrename.c
[Bug tree-optimization/47427] [4.6 Regression] ICE in process_constraint, at tree-ssa-structalias.c:2901
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47427 --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2011-01-25 12:01:57 UTC --- Author: jakub Date: Tue Jan 25 12:01:54 2011 New Revision: 169226 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=169226 Log: PR tree-optimization/47427 PR tree-optimization/47428 * tree-ssa-copyrename.c (copy_rename_partition_coalesce): Don't coalesce if the new root var would be TREE_READONLY. * gcc.c-torture/compile/pr47427.c: New test. * gcc.c-torture/compile/pr47428.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr47427.c trunk/gcc/testsuite/gcc.c-torture/compile/pr47428.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-copyrename.c
[Bug fortran/25071] dummy argument larger than actual argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25071 --- Comment #8 from Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch 2011-01-25 12:12:59 UTC --- (In reply to comment #7) Reopening.. actually, I think this is a kind of error that should be caught at run-time with -fcheck=arguments (not to say bounds). I guess that's not so easy to implement, as it seem to imply that additional hidden subroutine arguments need to be passed around.
[Bug fortran/25071] dummy argument larger than actual argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25071 --- Comment #9 from Tobias Burnus burnus at gcc dot gnu.org 2011-01-25 12:41:11 UTC --- (In reply to comment #8) actually, I think this is a kind of error that should be caught at run-time with -fcheck=arguments (not to say bounds). I guess that's not so easy to implement, as it seem to imply that additional hidden subroutine arguments need to be passed around. Well, that assumes that one compiles all files with the checking option. I like the idea better to have a global (static, SAVE) derived-type (struct) variable which contains the arguments and a function pointer. If loc(current function) == loc(function pointer) then the argument checking is done - else it is for a different function and no checking is done.
[Bug c++/47417] [4.6 Regression][C++0x] error: use of deleted function 'S::S(const S)'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47417 --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org 2011-01-25 12:43:56 UTC --- which version of Boost are you using? I don't know if it's fixed now but older releases (e.g. 1.42) did not support the current rvalue-reference model and unordered_map has no copy-constructor, only a move constructor: unordered_map(unordered_map other) With the latest rvalue-reference model that cannot bind to an lvalue. If you want to use GCC 4.6.0 and -std=c++0x then you need to use a version of Boost that can handle it.
[Bug tree-optimization/47427] [4.6 Regression] ICE in process_constraint, at tree-ssa-structalias.c:2901
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47427 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org 2011-01-25 12:46:19 UTC --- Fixed.
[Bug tree-optimization/47428] [4.6 Regression] ICE: tree check: expected ssa_name, have integer_cst in copy_phis_for_bb, at tree-inline.c:1986
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47428 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org 2011-01-25 12:46:46 UTC --- Fixed.
[Bug c++/47417] [4.6 Regression][C++0x] error: use of deleted function 'S::S(const S)'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47417
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Keywords|rejects-valid |
Status|UNCONFIRMED |RESOLVED
Resolution||INVALID
--- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org 2011-01-25
12:51:09 UTC ---
Boost trunk seems to have the same problem still, so this is a bug in Boost:
unordered_map has no copy constructor when BOOST_HAS_RVALUE_REFS is defined
you could workaround it with a user-provided copy constructor:
S(const S s) : m_(s.m_, s.m_.get_allocator()) { }
[Bug target/46072] AIX linker chokes on debug info for uninitialized static variables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46072
--- Comment #4 from Michael Haubenwallner michael.haubenwallner at salomon dot
at 2011-01-25 12:52:22 UTC ---
What exactly is the difference for gcc between not initializing a static
variable and initializing it to zero?
This is the difference in the generated assembler file:
$ cat mytest.c
static int myvar;
int main(void)
{
return myvar;
}
#if defined(IVAL)
static int myvar = IVAL;
#endif
For the compilation:
$ gcc -g mytest.c -DIVAL=0
(success)
$ gcc -g mytest.c
ld: 0711-593 SEVERE ERROR: Symbol C_BSTAT (entry 29) in object
/tmp//cc26KLXk.o:
The symbol refers to a csect with symbol number 0, which was not
found. The new symbol cannot be associated with a csect and
is being ignored.
collect2: ld returned 12 exit status
(fail)
For the analysis:
$ gcc -g -S mytest.c -o mytestu.s
$ gcc -g -S mytest.c -o mytest0.s -DIVAL=0
$ diff -u mytestu.s mytest0.s
--- mytestu.s 2011-01-25 13:39:43.0 +0100
+++ mytest0.s 2011-01-25 13:40:01.0 +0100
@@ -42,7 +42,7 @@
.byte 31
.align 2
FE..main:
- .bs _mytest.bss_
+ .bs _mytest.rw_[RW]
.stabx myvar:S-1,myvar,133,0
.es
_section_.text:
Both gcc-4.5.1 and gcc-4.2.4 do make this difference.
[Bug c++/47444] False warning: array subscript is above array bounds
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47444 --- Comment #5 from Manuel López-Ibáñez manu at gcc dot gnu.org 2011-01-25 12:58:12 UTC --- (In reply to comment #4) Well. You might argue that the wording should be 'may be' in all cases where the offending statement might not be executed (which is certainly undecidable as you can't know whether the function is executed at all). But it also isn't the way we handle other warnings (in particular the uninitialized variable uses). This is strange. We *precisely* says is uninitialized when it can be proved that it happens and may be uninitialized when it is just some code-paths or we cannot prove that it doesn't happen. And we certainly (or used to, I haven't been following these bugs lately) classify as bugs when the wrong message is printed. Thus I think we should not fix this bug (and it is a non-bug, as certainly the code in question isn't obviously dead). Interprocedual analysis could see that we call the function with a boolean value (thus, either 0 or 1). That said - we can't suit everyone with this kind of warnings. Then I guess we should just point out people to static analysis tools, like http://clang-analyzer.llvm.org/, which are more suited for this task than GCC.
[Bug tree-optimization/47265] [4.6 Regression] Error: SSA name in freelist but still referenced
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47265 --- Comment #7 from Michael Matz matz at gcc dot gnu.org 2011-01-25 12:58:33 UTC --- FWIW removing the second recursive call doesn't regress the testsuite.
[Bug c++/47444] False warning: array subscript is above array bounds
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47444 --- Comment #6 from Jonathan Wakely redi at gcc dot gnu.org 2011-01-25 13:07:06 UTC --- If you want to, although Clang can't analyze C++
[Bug tree-optimization/47426] [4.6 Regression] wrong code with -O2 -fipa-pta
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47426 --- Comment #4 from Richard Guenther rguenth at gcc dot gnu.org 2011-01-25 13:16:58 UTC --- The problem is that i_1(D) has an empty points-to set. It doesn't even receive constraints which is because the function is static but it escapes from getfoo which results in us failing to add NONLOCAL parameter inputs.
[Bug c++/47444] False warning: array subscript is above array bounds
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47444 --- Comment #7 from Manuel López-Ibáñez manu at gcc dot gnu.org 2011-01-25 13:16:55 UTC --- (In reply to comment #6) If you want to, although Clang can't analyze C++ The difference is that by design, Clang aims to do it at some moment in the future, it is a matter of time, resources and contributors, whereas by design GCC aims to not do it. I see a lot of frustrated users trying to use GCC for what it is not meant to be used and getting their bugs closed as invalid.
[Bug tree-optimization/47265] [4.6 Regression] Error: SSA name in freelist but still referenced
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47265 --- Comment #8 from Jakub Jelinek jakub at gcc dot gnu.org 2011-01-25 13:19:35 UTC --- Have you gathered statistics how much less does forwprop propagate though? I'm ATM running an instrumented bootstrap/regtest to see how many replacement hits result from the iterations, if iteration proves not to be worthwhile, I'd say just the return all has_zero_uses (name); change would be safest for 4.6.
[Bug c++/47457] New: g++ calls without optimisation incorrectly from explicitly optimised code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47457
Summary: g++ calls without optimisation incorrectly from
explicitly optimised code
Product: gcc
Version: 4.4.5
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: vas.gurev...@gmail.com
Created attachment 23116
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23116
preprocessed source
When build this code without optimisation, like that,
g++ -o optimizetest optimizetest.cpp
looks like function call from optimised function passes wrong parameters to
static inline function
#include stdio.h
static inline void bar(int a)
{
printf(%d\n, a);
}
void foo() __attribute__((optimize(O2)));
void foo()
{
int a = 10;
bar(a);
}
int main(int, char**)
{
foo();
return 0;
}
If compile with more than 0 optimisation level this works fine and prints 10,
otherwise when compile without optimisation this produces garbage instead of
10.
[Bug c++/47457] g++ calls without optimisation incorrectly from explicitly optimised code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47457 --- Comment #1 from Vasily Gurevich vas.gurevich at gmail dot com 2011-01-25 13:23:58 UTC --- Created attachment 23117 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23117 optimizetest.cpp Source file
[Bug fortran/47455] [4.6 Regression][OOP] internal compiler error: in fold_convert_loc, at fold-const.c:2028
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47455 --- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org 2011-01-25 13:24:39 UTC --- Regarding the regression: FAILS: 2010-05-03-r158988 WORKS: 2010-04-29-r158905 That includes a huge merge by Paul (r158910, 2010-04-29) - seemingly the OOP branch merge. * * * The failure occurs for the assignment in gfc_trans_scalar_assign, which is called by gfc_trans_assignment_1 for: expr1 is BT_DERIVED with this-x expr2 is EXPR_FUNCTION with this-_vptr-find_x The failure occurs for: 5281 gfc_add_modify (block, lse-expr, 5282 fold_convert (TREE_TYPE (lse-expr), rse-expr)); If one looks at rhs-expr.common.type and lhs-expr.common.type both are essentially the same - except that the RHS is a pointer: RHS: pointer_type 0x2ce325e8 type record_type 0x2ac2fb28 tx BLK LHS: record_type 0x2ac2fb28 tx BLK In the working version from April 2010, the dump looks like: *this-$data-x = *find_x ((struct .class.t *) this); The * on the RHS seems to be missing ...
[Bug c++/47457] g++ calls without optimisation incorrectly from explicitly optimised code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47457 --- Comment #2 from Vasily Gurevich vas.gurevich at gmail dot com 2011-01-25 13:24:51 UTC --- Created attachment 23118 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23118 gcc -v output
[Bug fortran/47448] Invalid check for ASSIGNMENT(=)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47448 --- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org 2011-01-25 13:30:35 UTC --- Author: burnus Date: Tue Jan 25 13:30:32 2011 New Revision: 169228 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=169228 Log: 2011-01-25 Tobias Burnus bur...@net-b.de PR fortran/47448 * interface.c (gfc_check_operator_interface): Fix defined-assignment check. 2011-01-25 Tobias Burnus bur...@net-b.de PR fortran/47448 * gfortran.dg/redefined_intrinsic_assignment_2.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/redefined_intrinsic_assignment_2.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/interface.c trunk/gcc/testsuite/ChangeLog
[Bug c++/47457] g++ calls without optimisation incorrectly from explicitly optimised code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47457 Juha Kallioinen juha.kallioinen at nokia dot com changed: What|Removed |Added CC||juha.kallioinen at nokia ||dot com --- Comment #3 from Juha Kallioinen juha.kallioinen at nokia dot com 2011-01-25 13:41:42 UTC --- Additional info: works on a 64bit Ubuntu Maverick (10.10) system, but not on a 32 bit one. Same problem with gcc-4.5.
[Bug c++/47457] g++ calls without optimisation incorrectly from explicitly optimised code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47457 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Attachment #23116|application/octet-stream|text/plain mime type|| --- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org 2011-01-25 13:44:39 UTC --- Comment on attachment 23116 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23116 preprocessed source this isn't preprocessed source, this is the assembler code
[Bug rtl-optimization/47166] [4.5/4.6 Regression] SpecCpu2000 Ammp segfaults for ARM with -O3 -mthumb
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47166 --- Comment #23 from Ian Bolton ibolton at gcc dot gnu.org 2011-01-25 13:45:59 UTC --- (In reply to comment #21) So is this now fixed on the trunk? Can anyone run SPEC2k? Spec2K's Ammp now runs correctly for trunk, with -mthumb -O3. The rest of Spec2K is OK too (apart from mesa, which is the subject of another bug).
[Bug c++/47457] g++ calls without optimisation incorrectly from explicitly optimised code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47457 --- Comment #5 from Vasily Gurevich vas.gurevich at gmail dot com 2011-01-25 13:51:14 UTC --- Created attachment 23119 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23119 real preprocessed source Excuse me, preprocessed source, just in case.
[Bug fortran/47448] Invalid check for ASSIGNMENT(=)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47448 --- Comment #3 from Tobias Burnus burnus at gcc dot gnu.org 2011-01-25 13:54:36 UTC --- Author: burnus Date: Tue Jan 25 13:54:33 2011 New Revision: 169229 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=169229 Log: 2011-01-25 Tobias Burnus bur...@net-b.de PR fortran/47448 * interface.c (gfc_check_operator_interface): Fix defined-assignment check. 2011-01-25 Tobias Burnus bur...@net-b.de PR fortran/47448 * gfortran.dg/redefined_intrinsic_assignment_2.f90: New. Added: branches/gcc-4_5-branch/gcc/testsuite/gfortran.dg/redefined_intrinsic_assignment_2.f90 Modified: branches/gcc-4_5-branch/gcc/fortran/ChangeLog branches/gcc-4_5-branch/gcc/fortran/interface.c branches/gcc-4_5-branch/gcc/testsuite/ChangeLog
[Bug fortran/47448] Invalid check for ASSIGNMENT(=)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47448 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #4 from Tobias Burnus burnus at gcc dot gnu.org 2011-01-25 14:00:31 UTC --- FIXED on the 4.6 trunk and on the 4.5 branch.
[Bug rtl-optimization/37273] [4.4/4.5/4.6 Regression] IRA does not re-materializes addresses (loads from the TOC)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37273 --- Comment #8 from Jeffrey A. Law law at gcc dot gnu.org 2011-01-25 14:10:51 UTC --- Author: law Date: Tue Jan 25 14:10:46 2011 New Revision: 169231 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=169231 Log: PR rtl-optimization/37273 * ira-costs.c (scan_one_insn): Detect constants living in memory and handle them like argument loads from stack slots. Do not double count memory for memory constants and argument loads from stack slots. Modified: trunk/gcc/ChangeLog trunk/gcc/ira-costs.c
[Bug rtl-optimization/37273] [4.4/4.5/4.6 Regression] IRA does not re-materializes addresses (loads from the TOC)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37273 Jeffrey A. Law law at redhat dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|4.4.6 |4.6.0 --- Comment #9 from Jeffrey A. Law law at redhat dot com 2011-01-25 14:11:33 UTC --- Fixed
[Bug fortran/45586] [4.6 Regression] ICE non-trivial conversion at assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586
--- Comment #38 from Mikael Morin mikael at gcc dot gnu.org 2011-01-25
14:32:28 UTC ---
The patch looks good.
Somewhat hackish as you acknowledge, but worth submitting anyway.
A few minor comments below.
Index: fortran/trans-expr.c
===
--- fortran/trans-expr.c (revision 168749)
+++ fortran/trans-expr.c (working copy)
@@ -504,6 +504,19 @@ gfc_conv_component_ref (gfc_se * se, gfc
field = c-backend_decl;
gcc_assert (TREE_CODE (field) == FIELD_DECL);
decl = se-expr;
+ if (DECL_CONTEXT (field) != TREE_TYPE (decl))
+{
+ tree f2 = c-backend_decl2;
+ if (f2 DECL_FIELD_CONTEXT (f2) == TREE_TYPE (decl))
+ ;
+ else for (f2 = TYPE_FIELDS (TREE_TYPE (decl)); f2; f2 = DECL_CHAIN
(f2))
I prefer `if (!cond) ...' instead of `if (cond) ; else ...'
Index: fortran/gfortran.h
===
--- fortran/gfortran.h(revision 168749)
+++ fortran/gfortran.h(working copy)
@@ -934,6 +934,7 @@ typedef struct gfc_component
gfc_array_spec *as;
tree backend_decl;
+ tree backend_decl2;
More descriptive name (e.g. restrict_backend_decl or target_backend_decl or
...)
and comment explaining the need for it appreciated.
One could have the combinatorial explosion of backend_decls here as said
Michael. In any case it can be safely removed if needed, as it is just a cache.
locus loc;
struct gfc_expr *initializer;
struct gfc_component *next;
Index: fortran/trans-types.c
===
--- fortran/trans-types.c (revision 168749)
+++ fortran/trans-types.c (working copy)
@@ -1746,6 +1746,80 @@ gfc_build_pointer_type (gfc_symbol * sym
else
return build_pointer_type (type);
}
+
+static tree
+gfc_nonrestricted_type (tree t)
+{
+ tree ret = t;
+ if (!TYPE_LANG_SPECIFIC (t))
+TYPE_LANG_SPECIFIC (t)
+ = ggc_alloc_cleared_lang_type (sizeof (struct lang_type));
+ if (TYPE_LANG_SPECIFIC (t)-nonrestricted_type)
+return TYPE_LANG_SPECIFIC (t)-nonrestricted_type;
+ switch (TREE_CODE (t))
+{
+ default:
+ break;
+
+ case POINTER_TYPE:
+ case REFERENCE_TYPE:
+ ret = build_qualified_type (t, TYPE_QUALS (t) ~TYPE_QUAL_RESTRICT);
Isn't it necessary to call gfc_nonrestricted_type on TREE_TYPE (t) here ?
+ break;
+
+ case ARRAY_TYPE:
+ {
+ tree elemtype = gfc_nonrestricted_type (TREE_TYPE (t));
+ if (elemtype == TREE_TYPE (t))
+ ret = t;
+ else
+ {
+ ret = copy_node (t);
+ TREE_TYPE (t) = elemtype;
+ /* ??? Change some TYPE_LANG_SPECIFICs too? */
+ }
+ }
+ break;
+
+ case RECORD_TYPE:
+ case UNION_TYPE:
+ case QUAL_UNION_TYPE:
+ {
+ tree field, *chain;
+ for (field = TYPE_FIELDS (t); field; field = DECL_CHAIN (field))
+ if (TREE_CODE (field) == FIELD_DECL)
+ {
+ tree elemtype = gfc_nonrestricted_type (TREE_TYPE (field));
+ if (elemtype != TREE_TYPE (field))
+ break;
+ }
+ if (!field)
+ break;
+ ret = copy_node (t);
+ TYPE_FIELDS (ret) = NULL_TREE;
+ chain = TYPE_FIELDS (ret);
+ for (field = TYPE_FIELDS (t); field; field = DECL_CHAIN (field))
+ {
+ tree newfield = copy_node (field);
+ DECL_CONTEXT (newfield) = ret;
+ DECL_CHAIN (newfield) = NULL_TREE;
+ if (TYPE_FIELDS (ret) == NULL_TREE)
+ TYPE_FIELDS (ret) = newfield;
Those two lines seem to duplicate the line below (as initially chain points to
TYPE_FIELDS(ret)).
+ *chain = newfield;
+ chain = DECL_CHAIN (newfield);
+
+ if (TREE_CODE (field) == FIELD_DECL)
+ {
+ tree elemtype = gfc_nonrestricted_type (TREE_TYPE (field));
+ TREE_TYPE (newfield) = elemtype;
+ }
+ }
+ }
+break;
+}
+ TYPE_LANG_SPECIFIC (t)-nonrestricted_type = ret;
Don't know if it is absolutely necessary, but one might add also :
TYPE_LANG_SPECIFIC (ret)-nonrestricted_type = ret;
+ return ret;
+}
+
/* Return the type for a symbol. Special handling is required for character
types to get the correct level of indirection.
@@ -1789,6 +1863,9 @@ gfc_sym_type (gfc_symbol * sym)
else
type = gfc_typenode_for_spec (sym-ts);
+ if (sym-attr.pointer)
+type = gfc_nonrestricted_type (type);
+
This is missing the target attribute, so you may preferably use the restricted
boolean a few lines below.
if (sym-attr.dummy !sym-attr.function !sym-attr.value)
byref = 1;
else
Index: fortran/trans.h
[Bug fortran/45586] [4.6 Regression] ICE non-trivial conversion at assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586 --- Comment #39 from Mikael Morin mikael at gcc dot gnu.org 2011-01-25 14:40:40 UTC --- (In reply to comment #37) That's what we do ;) Wow! Middle-end gurus take design decisions of mine before I have ever thought them. They are real wizards after all. And void * restrict is not compatible with void *. So you get the ICE. Hum, may I suggest a --push-harder/--will-you-swallow-it option ? More seriously, I will test the patch above.
[Bug tree-optimization/47271] [4.6 Regression] if-conversion removes a test (if), the function generates invalid outputs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47271 --- Comment #16 from Sebastian Pop spop at gcc dot gnu.org 2011-01-25 14:51:28 UTC --- Author: spop Date: Tue Jan 25 14:51:23 2011 New Revision: 169233 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=169233 Log: Fix PR47271: only if-convert full writes. 2011-01-25 Sebastian Pop sebastian@amd.com Jakub Jelinek ja...@redhat.com PR tree-optimization/47271 * tree-if-conv.c (bb_postdominates_preds): New. (if_convertible_bb_p): Call bb_postdominates_preds. (if_convertible_loop_p_1): Compute CDI_POST_DOMINATORS. (predicate_scalar_phi): Call bb_postdominates_preds. * gcc.dg/tree-ssa/ifc-pr47271.c: New. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/ifc-pr47271.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-if-conv.c
[Bug tree-optimization/47271] [4.6 Regression] if-conversion removes a test (if), the function generates invalid outputs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47271 Sebastian Pop spop at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #17 from Sebastian Pop spop at gcc dot gnu.org 2011-01-25 14:54:52 UTC --- Fixed.
[Bug target/46898] libgcc build failure on lm32-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46898 Joel Sherrill joel at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.01.25 14:58:49 Known to work||4.5.2 Ever Confirmed|0 |1 --- Comment #5 from Joel Sherrill joel at gcc dot gnu.org 2011-01-25 14:58:49 UTC --- I can confirm this on the lm32-rtems. This is a serious regression from 4.5.2 since it prevents all lm32 targets from building.
[Bug fortran/45586] [4.6 Regression] ICE non-trivial conversion at assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586
--- Comment #40 from Michael Matz matz at gcc dot gnu.org 2011-01-25 15:02:40
UTC ---
The patch from comment #35 requires another change in unrelated code, which
I think actually fixes a pre-existing bug in type extension support:
Index: fortran/trans-expr.c
===
--- fortran/trans-expr.c(revision 168749)
+++ fortran/trans-expr.c(working copy)
@@ -549,11 +562,11 @@ conv_parent_component_references (gfc_se
if (dt-attr.extension dt-components)
{
- if (dt-attr.is_class)
+ if (1 || dt-attr.is_class)
cmp = dt-components;
else
cmp = dt-components-next;
- /* Return if the component is not in the parent type. */
+ /* Return if the component is in this type. */
for (; cmp; cmp = cmp-next)
if (strcmp (c-name, cmp-name) == 0)
return;
Otherwise the new assert will trigger on extends_*.f03 because the frontend
is trying to generate obviously wrong component_refs.
[Bug fortran/45586] [4.6 Regression] ICE non-trivial conversion at assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586 --- Comment #41 from Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch 2011-01-25 15:03:55 UTC --- (In reply to comment #39) void *. So you get the ICE. Hum, may I suggest a --push-harder/--will-you-swallow-it option ? --enable-checking=release ?
[Bug target/47458] New: m32r fails to build -- __builtin_eh_return not supported
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47458 Summary: m32r fails to build -- __builtin_eh_return not supported Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: j...@gcc.gnu.org 4.6.0 20110110 (experimental) [trunk revision 168642] /users/joel/test-gcc/b-gcc1-m32r/./gcc/xgcc -B/users/joel/test-gcc/b-gcc1-m32r/./gcc/ -nostdinc -B/users/joel/test-gcc/b-gcc1-m32r/m32r-rtems4.11/newlib/ -isystem /users/joel/test-gcc/b-gcc1-m32r/m32r-rtems4.11/newlib/targ-include -isystem /users/joel/test-gcc/gcc-svn/newlib/libc/include -B/users/joel/test-gcc/install-svn/m32r-rtems4.11/bin/ -B/users/joel/test-gcc/install-svn/m32r-rtems4.11/lib/ -isystem /users/joel/test-gcc/install-svn/m32r-rtems4.11/include -isystem /users/joel/test-gcc/install-svn/m32r-rtems4.11/sys-include-g -Os -mmodel=medium -msdata=sdata -O2 -I/users/joel/test-gcc/gcc-svn/gcc/../newlib/libc/sys/rtems/include -g -Os -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -G 0 -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -fno-stack-protector -Dinhibit_libc -I. -I. -I../../.././gcc -I/users/joel/test-gcc/gcc-svn/libgcc -I/users/joel/test-gcc/gcc-svn/libgcc/. -I/users/joel/test-gcc/gcc-svn/libgcc/../gcc -I/users/joel/test-gcc/gcc-svn/libgcc/../include -DHAVE_CC_TLS -DUSE_EMUTLS -o unwind-dw2.o -MT unwind-dw2.o -MD -MP -MF unwind-dw2.dep -fexceptions -c /users/joel/test-gcc/gcc-svn/libgcc/../gcc/unwind-dw2.c In file included from /users/joel/test-gcc/gcc-svn/libgcc/../gcc/unwind-dw2.c:1582:0: /users/joel/test-gcc/gcc-svn/libgcc/../gcc/unwind.inc: In function '_Unwind_RaiseException': /users/joel/test-gcc/gcc-svn/libgcc/../gcc/unwind.inc:136:1: error: __builtin_eh_return not supported on this target /users/joel/test-gcc/gcc-svn/libgcc/../gcc/unwind.inc: In function '_Unwind_ForcedUnwind': /users/joel/test-gcc/gcc-svn/libgcc/../gcc/unwind.inc:212:1: error: __builtin_eh_return not supported on this target /users/joel/test-gcc/gcc-svn/libgcc/../gcc/unwind.inc: In function '_Unwind_Resume': /users/joel/test-gcc/gcc-svn/libgcc/../gcc/unwind.inc:237:1: error: __builtin_eh_return not supported on this target /users/joel/test-gcc/gcc-svn/libgcc/../gcc/unwind.inc: In function '_Unwind_Resume_or_Rethrow': /users/joel/test-gcc/gcc-svn/libgcc/../gcc/unwind.inc:262:1: error: __builtin_eh_return not supported on this target make[4]: *** [unwind-dw2.o] Error 1 make[4]: Leaving directory `/users/joel/test-gcc/b-gcc1-m32r/m32r-rtems4.11/medium/libgcc' make[3]: *** [multi-do] Error 1
[Bug target/47458] m32r fails to build -- __builtin_eh_return not supported
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47458 --- Comment #1 from froydnj at codesourcery dot com froydnj at codesourcery dot com 2011-01-25 15:08:48 UTC --- On Tue, Jan 25, 2011 at 03:05:32PM +, joel at gcc dot gnu.org wrote: In file included from /users/joel/test-gcc/gcc-svn/libgcc/../gcc/unwind-dw2.c:1582:0: /users/joel/test-gcc/gcc-svn/libgcc/../gcc/unwind.inc: In function '_Unwind_RaiseException': /users/joel/test-gcc/gcc-svn/libgcc/../gcc/unwind.inc:136:1: error: __builtin_eh_return not supported on this target This means that m32r (and m32c, at least) need to undef/define TARGET_EXCEPT_UNWIND_INFO in m32r.c to sjlj_except_unwind_info.
[Bug ada/47459] New: m68k Ada ICE in maybe_add_or_update_dep_1, at sched-deps.c:854
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47459 Summary: m68k Ada ICE in maybe_add_or_update_dep_1, at sched-deps.c:854 Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassig...@gcc.gnu.org ReportedBy: j...@gcc.gnu.org /users/joel/test-gcc/b-gccada-m68k/./gcc/xgcc -B/users/joel/test-gcc/b-gccada-m68k/./gcc/ -nostdinc -B/users/joel/test-gcc/b-gccada-m68k/m68k-rtems4.11/newlib/ -isystem /users/joel/test-gcc/b-gccada-m68k/m68k-rtems4.11/newlib/targ-include -isystem /users/joel/test-gcc/gcc-svn/newlib/libc/include -B/users/joel/test-gcc/install-svn/m68k-rtems4.11/bin/ -B/users/joel/test-gcc/install-svn/m68k-rtems4.11/lib/ -isystem /users/joel/test-gcc/install-svn/m68k-rtems4.11/include -isystem /users/joel/test-gcc/install-svn/m68k-rtems4.11/sys-include-c -g -O2 -mcpu=5206 -W -Wall -gnatpg -mcpu=5206 g-sothco.adb -o g-sothco.o +===GNAT BUG DETECTED==+ | 4.6.0 20110124 (experimental) [trunk revision 169182] (m68k-unknown-rtems4.11) GCC error:| | in maybe_add_or_update_dep_1, at sched-deps.c:854| | Error detected around g-sothco.ads:99:9 | | Please submit a bug report; see http://gcc.gnu.org/bugs.html.| | Use a subject line meaningful to you and us to track the bug.| | Include the entire contents of this bug box in the report. | | Include the exact gcc or gnatmake command that you entered. | | Also include sources listed below in gnatchop format | | (concatenated together with no headers between files). | +==+
[Bug c++/47340] [trans-mem] problem with declaration of new operator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47340 Aldy Hernandez aldyh at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.01.25 15:13:02 AssignedTo|unassigned at gcc dot |aldyh at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1
[Bug ada/47459] Regression: m68k Ada ICE in maybe_add_or_update_dep_1, at sched-deps.c:854
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47459 Joel Sherrill joel at gcc dot gnu.org changed: What|Removed |Added Summary|m68k Ada ICE in |Regression: m68k Ada ICE in |maybe_add_or_update_dep_1, |maybe_add_or_update_dep_1, |at sched-deps.c:854 |at sched-deps.c:854 --- Comment #1 from Joel Sherrill joel at gcc dot gnu.org 2011-01-25 15:14:35 UTC --- This is known to work in [gcc-4_5-branch revision 167253] but I don't know how to put that in the Known to Work field.
[Bug middle-end/47449] [x32] can’t find a register in class ‘DIREG’ while reloading ‘asm’
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47449 --- Comment #12 from hjl at gcc dot gnu.org hjl at gcc dot gnu.org 2011-01-25 15:14:54 UTC --- Author: hjl Date: Tue Jan 25 15:14:49 2011 New Revision: 169234 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=169234 Log: Don't propagate hard register. 2011-01-25 H.J. Lu hongjiu...@intel.com PR middle-end/47449 * fwprop.c (forward_propagate_subreg): Don't propagate hard register. Modified: branches/x32/gcc/ChangeLog.x32 branches/x32/gcc/fwprop.c
[Bug rtl-optimization/47166] [4.5 Regression] SpecCpu2000 Ammp segfaults for ARM with -O3 -mthumb
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47166 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Known to work||4.6.0 Summary|[4.5/4.6 Regression]|[4.5 Regression] |SpecCpu2000 Ammp segfaults |SpecCpu2000 Ammp segfaults |for ARM with -O3 -mthumb|for ARM with -O3 -mthumb Known to fail|4.6.0 | --- Comment #24 from Jakub Jelinek jakub at gcc dot gnu.org 2011-01-25 15:20:52 UTC --- Fixed on the trunk then.
[Bug target/46072] AIX linker chokes on debug info for uninitialized static variables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46072 --- Comment #5 from Michael Haubenwallner michael.haubenwallner at salomon dot at 2011-01-25 15:40:07 UTC --- Created attachment 23120 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23120 Patch to simply not use bss section with .bs, but private-data-section instead I'm going to try this patch with gcc-4.2.4 now...
[Bug c/47409] volatile struct member bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47409
--- Comment #7 from John Regehr regehr at cs dot utah.edu 2011-01-25 15:41:58
UTC ---
(In reply to comment #6)
struct {
volatile int a[100];
} a, b;
a = b;
? And what's the difference of the above to
volatile struct {
int a[100];
} a, b;
a = b;
There's no effective difference, I believe.
[Bug fortran/38536] ICE with C_LOC in resolve.c due to not properly going through expr-ref
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38536 --- Comment #22 from Tobias Burnus burnus at gcc dot gnu.org 2011-01-25 15:44:50 UTC --- Created attachment 23121 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23121 draft patch, working but too many warnings (cf. test suite failures) Currently c_loc(a(1:2)) produces the warning Array section in '%s' call at %L which is correct but possibly misleading as F2008 (contrary to F2003) allows it. What F2008 only requires is that the argument is contiguous. At http://gcc.gnu.org/ml/fortran/2011-01/msg00180.html was an early (and very buggy), attached a more advanced patch which gives the warning: Array might be not contiguous in '%s' call at %L However, the patch is also overzealous by warning for a(1:2:5) which is contiguous (as equivalent to a(1:1)). But it also warns elsewhere too much. I think it would be useful to only warn (or error out) if it is known to be noncontiguous of if one cuts down the number of warnings.
[Bug target/47458] m32r fails to build -- __builtin_eh_return not supported
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47458 --- Comment #2 from Joel Sherrill joel at gcc dot gnu.org 2011-01-25 16:19:28 UTC --- I can now build C/C++ for m32r-rtems*. m32c-rtems* builds ok without any patches. OK to commit this and close this PR? Index: gcc/config/m32r/m32r.c === --- gcc/config/m32r/m32r.c(revision 169182) +++ gcc/config/m32r/m32r.c(working copy) @@ -1,6 +1,6 @@ /* Subroutines used for code generation on the Renesas M32R cpu. Copyright (C) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, - 2005, 2007, 2008, 2009, 2010 Free Software Foundation, Inc. + 2005, 2007, 2008, 2009, 2010, 2011 Free Software Foundation, Inc. This file is part of GCC. @@ -210,6 +210,9 @@ #undef TARGET_TRAMPOLINE_INIT #define TARGET_TRAMPOLINE_INIT m32r_trampoline_init +#undef TARGET_EXCEPT_UNWIND_INFO +#define TARGET_EXCEPT_UNWIND_INFOsjlj_except_unwind_info + struct gcc_target targetm = TARGET_INITIALIZER; /* Implement TARGET_HANDLE_OPTION. */
[Bug target/45701] [4.6 Regression] Fail to prefer using r3 for padding a push/pop multiple to 8-byte alignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45701 --- Comment #10 from Jakub Jelinek jakub at gcc dot gnu.org 2011-01-25 16:22:45 UTC --- Author: jakub Date: Tue Jan 25 16:22:34 2011 New Revision: 169240 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=169240 Log: PR target/45701 * config/arm/arm.c (any_sibcall_uses_r3): New function. (arm_get_frame_offsets): Use it. 2011-01-25 Yao Qi y...@codesourcery.com PR target/45701 * gcc.target/arm/pr45701-1.c: New test. * gcc.target/arm/pr45701-2.c: New test. * gcc.target/arm/pr45701-3.c: New test. Added: trunk/gcc/testsuite/gcc.target/arm/pr45701-1.c trunk/gcc/testsuite/gcc.target/arm/pr45701-2.c trunk/gcc/testsuite/gcc.target/arm/pr45701-3.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/arm.c trunk/gcc/testsuite/ChangeLog
[Bug target/45701] [4.6 Regression] Fail to prefer using r3 for padding a push/pop multiple to 8-byte alignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45701 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #11 from Jakub Jelinek jakub at gcc dot gnu.org 2011-01-25 16:24:30 UTC --- Fixed.
[Bug target/47424] [4.6 Regression] Glibc miscompiled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47424 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2011-01-25 16:25:49 UTC --- I've built glibc 2.13 with 20110122ish gcc on both x86_64 and i686 just fine this weekend.
[Bug target/47458] m32r fails to build -- __builtin_eh_return not supported
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47458 --- Comment #3 from froydnj at codesourcery dot com froydnj at codesourcery dot com 2011-01-25 16:26:42 UTC --- On Tue, Jan 25, 2011 at 04:19:33PM +, joel at gcc dot gnu.org wrote: I can now build C/C++ for m32r-rtems*. m32c-rtems* builds ok without any patches. OK to commit this and close this PR? I'm not a maintainer, but given that a number of architectures have been fixed in this manner this release cycle, I think this counts as obvious.
[Bug tree-optimization/47460] New: Inconsistent behaviour of __sync_fetch_and_add builtin?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47460
Summary: Inconsistent behaviour of __sync_fetch_and_add
builtin?
Product: gcc
Version: 4.4.5
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: manuel.holtgr...@fu-berlin.de
I get the unexpected (for me) inconsistent behaviour of the
__sync_fetch_and_add builtin with the program below. My main confusion is
around the missing __sync_val_compare_and_swap_{1,2,4} when not explicitely
specifying the architecture in GCC 4.4.5, but availability in all other tried
variants.
Also, why is there a 64-bit variant when explicitely giving -march=i686 to g++
=4.2 but missing one in g++-4.1?
Thanks!
Program gcc-atomic.cpp
--8--8--8--8--8--8--8--8--8--8--8--8--8--8--8--8
template typename T
void test()
{
T volatile x = 0;
T y = 0;
T z = 0;
__sync_fetch_and_add(x, y, z);
__sync_fetch_and_or(x, y, z);
__sync_fetch_and_xor(x, y, z);
__sync_val_compare_and_swap(x, y, z);
}
int main()
{
testchar();
testunsigned char();
testint();
testunsigned int();
testshort();
testunsigned short();
testlong();
testunsigned long();
testlong long();
testunsigned long long();
return 0;
}
Output WITH -march=i686 switch
--8--8--8--8--8--8--8--8--8--8--8--8--8--8--8--8
$ for i in 1 2 3 4 5; do g++-4.$i --version; g++-4.$i -dumpmachine; g++-4.$i
-march=i686 gcc-atomic.cpp; done
g++-4.1 (GCC) 4.1.3 20080704 (prerelease) (Debian 4.1.2-25)
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
i486-linux-gnu
/tmp/cce8mfQl.o: In function `void testlong long()':
gcc-atomic.cpp:(.text._Z4testIxEvv[void testlong long()]+0x46): undefined
reference to `__sync_fetch_and_add_8'
gcc-atomic.cpp:(.text._Z4testIxEvv[void testlong long()]+0x5f): undefined
reference to `__sync_fetch_and_or_8'
gcc-atomic.cpp:(.text._Z4testIxEvv[void testlong long()]+0x78): undefined
reference to `__sync_fetch_and_xor_8'
gcc-atomic.cpp:(.text._Z4testIxEvv[void testlong long()]+0x9f): undefined
reference to `__sync_val_compare_and_swap_8'
/tmp/cce8mfQl.o: In function `void testunsigned long long()':
gcc-atomic.cpp:(.text._Z4testIyEvv[void testunsigned long long()]+0x45):
undefined reference to `__sync_fetch_and_add_8'
gcc-atomic.cpp:(.text._Z4testIyEvv[void testunsigned long long()]+0x5e):
undefined reference to `__sync_fetch_and_or_8'
gcc-atomic.cpp:(.text._Z4testIyEvv[void testunsigned long long()]+0x77):
undefined reference to `__sync_fetch_and_xor_8'
gcc-atomic.cpp:(.text._Z4testIyEvv[void testunsigned long long()]+0x9e):
undefined reference to `__sync_val_compare_and_swap_8'
collect2: ld returned 1 exit status
g++-4.2 (GCC) 4.2.4 (Debian 4.2.4-6)
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
i486-linux-gnu
g++-4.3 (Debian 4.3.2-1.1) 4.3.2
Copyright (C) 2008 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
i486-linux-gnu
g++-4.4.5 (GCC) 4.4.5
Copyright (C) 2010 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
i686-pc-linux-gnu
g++-4.5.1 (GCC) 4.5.1
Copyright (C) 2010 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
i686-pc-linux-gnu
Output WITHOUT -march=i686 switch
--8--8--8--8--8--8--8--8--8--8--8--8--8--8--8--8
$ for i in 1 2 3 4 5; do g++-4.$i --version; g++-4.$i -dumpmachine; g++-4.$i
gcc-atomic.cpp; done
g++-4.1 (GCC) 4.1.3 20080704 (prerelease) (Debian 4.1.2-25)
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
i486-linux-gnu
/tmp/ccGnLtMn.o: In function `void testlong long()':
gcc-atomic.cpp:(.text._Z4testIxEvv[void testlong long()]+0x46): undefined
reference to `__sync_fetch_and_add_8'
gcc-atomic.cpp:(.text._Z4testIxEvv[void testlong long()]+0x5f): undefined
reference to `__sync_fetch_and_or_8'
gcc-atomic.cpp:(.text._Z4testIxEvv[void testlong long()]+0x78): undefined
reference to `__sync_fetch_and_xor_8'
gcc-atomic.cpp:(.text._Z4testIxEvv[void testlong long()]+0x9f): undefined
reference to `__sync_val_compare_and_swap_8'
/tmp/ccGnLtMn.o: In function `void testunsigned long long()':
gcc-atomic.cpp:(.text._Z4testIyEvv[void testunsigned long
[Bug target/47457] g++ calls without optimisation incorrectly from explicitly optimised code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47457 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target||i?86-*-linux Status|UNCONFIRMED |NEW Last reconfirmed||2011.01.25 16:28:34 Component|c++ |target Ever Confirmed|0 |1 Known to fail||4.4.4, 4.5.2, 4.6.0 --- Comment #6 from Richard Guenther rguenth at gcc dot gnu.org 2011-01-25 16:28:34 UTC --- Confirmed. I think this is a dup though.
[Bug target/47458] m32r fails to build -- __builtin_eh_return not supported
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47458 --- Comment #4 from Richard Guenther rguenth at gcc dot gnu.org 2011-01-25 16:29:26 UTC --- Looks obvious.
[Bug target/47424] [4.6 Regression] Glibc miscompiled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47424 Andreas Schwab sch...@linux-m68k.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID --- Comment #3 from Andreas Schwab sch...@linux-m68k.org 2011-01-25 16:29:56 UTC --- The test is compiled with -mavx and you are not using an AVX capable host.
[Bug c++/47461] New: warn_unused_result attribute ignored for templates
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47461
Summary: warn_unused_result attribute ignored for templates
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: i...@airs.com
When I compile this C++ code with current mainline
class C {
public:
templatetypename T bool f(T* m) __attribute__((warn_unused_result));
};
templatetypename T inline bool C::f(T* m) { return true; }
void f(C* pc) { int i; pc-f(i); }
I should see a warning for the call to pc-f. However, I see no warnings.
I do see a warning for a member function which is not a template.
