[Bug tree-optimization/40760] New: [4.3/4.4/4.5 Regression] unbounded recursion in the gimplifier
The testcase from PR/2161:
#define ONE else if (0) { }
#define TEN ONE ONE ONE ONE ONE ONE ONE ONE ONE ONE
#define HUN TEN TEN TEN TEN TEN TEN TEN TEN TEN TEN
#define THOUHUN HUN HUN HUN HUN HUN HUN HUN HUN HUN
void foo()
{
if (0) { }
/* 11,000 else if's. */
THOU THOU THOU THOU THOU THOU THOU THOU THOU THOU THOU
}
as well as the following:
#define OONE (a()
#define OTENOONE OONE OONE OONE OONE OONE OONE OONE OONE OONE
#define OHUNOTEN OTEN OTEN OTEN OTEN OTEN OTEN OTEN OTEN OTEN
#define OTHOU OHUN OHUN OHUN OHUN OHUN OHUN OHUN OHUN OHUN OHUN
#define CONE)
#define CTENCONE CONE CONE CONE CONE CONE CONE CONE CONE CONE
#define CHUNCTEN CTEN CTEN CTEN CTEN CTEN CTEN CTEN CTEN CTEN
#define CTHOU CHUN CHUN CHUN CHUN CHUN CHUN CHUN CHUN CHUN CHUN
void foo()
{
a()
/* 11,000 right-associated 's with side effects. */
OTHOU OTHOU OTHOU OTHOU OTHOU OTHOU OTHOU OTHOU OTHOU OTHOU OTHOU
CTHOU CTHOU CTHOU CTHOU CTHOU CTHOU CTHOU CTHOU CTHOU CTHOU CTHOU;
}
fail with a segmentation fault do to recursion that is proportional to the
size of the program.
--
Summary: [4.3/4.4/4.5 Regression] unbounded recursion in the
gimplifier
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bonzini at gnu dot org
BugsThisDependsOn: 2161
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40760
[Bug bootstrap/40597] Powerpc bootstrap is broken due to changes in expmed.c
--- Comment #32 from bonzini at gnu dot org 2009-07-15 06:05 --- Yes, but I don't think it's infinite recursion. There are 11,000 else ifs in the testcase. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40597
[Bug tree-optimization/40760] [4.3/4.4/4.5 Regression] unbounded recursion in the gimplifier
--- Comment #1 from bonzini at gnu dot org 2009-07-15 06:06 --- A regression from when, well, there was no gimplifier. -- bonzini at gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Known to fail||4.0.0 4.5.0 Known to work||3.4.6 Last reconfirmed|-00-00 00:00:00 |2009-07-15 06:06:34 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40760
[Bug fortran/33197] Fortran 2008: math functions
--- Comment #28 from burnus at gcc dot gnu dot org 2009-07-15 06:08 ---
In a quick scan of the patch, I note that the mpfr versions
of the simplifications weren't in the patch.
MPFR or MPC? The MPFR version should be there since years; the MPC version of
tan/sinh/cosh/tanh should be there (FX patch which is part of this patch) and
the MPC version of a{sin,cos,tan}{,h} does not exist, yet:
http://gforge.inria.fr/plugins/scmsvn/viewcvs.php/trunk/TODO?root=mpcview=markup
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33197
[Bug rtl-optimization/40761] New: IRA memory hog for insanely nested loops
#define ONE while (b())
#define TEN ONE ONE ONE ONE ONE ONE ONE ONE ONE ONE
#define HUN TEN TEN TEN TEN TEN TEN TEN TEN TEN TEN
#define THOUHUN HUN HUN HUN HUN HUN HUN HUN HUN HUN
void foo()
{
/* 11,000 nested whiles. */
THOU THOU THOU THOU THOU THOU THOU THOU THOU THOU THOU
a();
}
shows IRA taking 82% of compile-time wall time (25 seconds here at -O0) and
needing 1 GB of memory. The reason why I'm reporting this, is that it seems to
be quadratic or at least well superlinear. Changing it to 5500 loops requires
only 300 MB.
Not that it's the most important bug.
--
Summary: IRA memory hog for insanely nested loops
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: memory-hog
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bonzini at gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40761
[Bug c/40757] gcc 4.4.0 miscompiles mpfr-2.4.1
--- Comment #2 from ebotcazou at gcc dot gnu dot org 2009-07-15 06:27 --- Thanks for the report, but we need a preprocessed testcase, see instructions at http://gcc.gnu.org/bugs.html -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40757
[Bug c/40762] New: possible integer miscompilation
Seen on Ubuntu Hardy. The -O2 result seems to be wrong. Also valgrind says
this about the -O2 compilation:
==6729== Conditional jump or move depends on uninitialised value(s)
==6729==at 0x84F22CB: solve_graph (tree-ssa-structalias.c:1570)
reg...@john-home:~/volatile/tmp174$ current-gcc -O1 small.c -o small
reg...@john-home:~/volatile/tmp174$ ./small
checksum = 0
reg...@john-home:~/volatile/tmp174$ current-gcc -O2 small.c -o small
reg...@john-home:~/volatile/tmp174$ ./small
checksum = 1
reg...@john-home:~/volatile/tmp174$ current-gcc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../configure --prefix=/home/regehr/z/tmp/gcc-r149650-install
--program-prefix=r149650- --enable-languages=c,c++
Thread model: posix
gcc version 4.5.0 20090714 (experimental) (GCC)
reg...@john-home:~/volatile/tmp174$ cat small.c
#include stdint.h
#include limits.h
#include stdio.h
uint8_t g_4;
int64_t g_10;
uint8_t g_56;
uint8_t g_64;
static uint8_t safe_rshift_func_uint8_t_u_u(uint8_t left, unsigned int right)
{
return unsigned int)(right)) = sizeof(uint8_t)*CHAR_BIT)
? ((uint8_t)(left))
: (((uint8_t)(left)) ((unsigned int)(right;
}
int32_t func_53 (void);
int32_t func_53 (void)
{
if (safe_rshift_func_uint8_t_u_u (g_56, g_10))
{
}
else
for (g_10 = 0; g_10; g_10 = 1)
{
}
return 1;
}
int32_t func_36 (void);
int32_t func_36 (void)
{
uint8_t p_40;
g_10 = 1;
g_10 func_53 ();
p_40 = g_10 || g_4;
g_64 = g_10;
return 1;
}
int
main (void)
{
func_36 ();
printf (checksum = %d\n, g_64);
return 0;
}
--
Summary: possible integer miscompilation
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: regehr at cs dot utah dot edu
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40762
[Bug rtl-optimization/40761] [4.4/4.5 Regression] IRA memory hog for insanely nested loops
--- Comment #1 from steven at gcc dot gnu dot org 2009-07-15 07:21 --- Ack. -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-07-15 07:21:07 date|| Summary|IRA memory hog for insanely |[4.4/4.5 Regression] IRA |nested loops|memory hog for insanely ||nested loops http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40761
[Bug rtl-optimization/40761] [4.4/4.5 Regression] IRA memory hog for insanely nested loops
-- steven at gcc dot gnu dot org changed: What|Removed |Added Known to fail||4.5.0 Known to work||4.3.0 Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40761
[Bug middle-end/40500] [4.5 Regression] Revision 148512 failed to build binutils
-- steven at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40500
[Bug testsuite/40543] [4.5 Regression] FAIL: g++.dg/pch/pch.C
-- steven at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40543
[Bug testsuite/40543] [4.5 Regression] FAIL: g++.dg/pch/pch.C
-- steven at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-07-15 07:27:27 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40543
[Bug debug/40596] [4.5 regression] Bad debug info for local variables on i386.
-- steven at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40596
[Bug debug/40660] [4.5 Regression] Wierd break points with 4.5, works with 4.4
-- steven at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-07-15 07:28:00 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40660
[Bug debug/40660] [4.5 Regression] Wierd break points with 4.5, works with 4.4
-- steven at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40660
[Bug testsuite/40671] [4.5 Regression] internal compiler error: in extract_insn, at recog.c:2089 on powerpc
-- steven at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40671
[Bug libffi/40700] [4.5 Regression] All amd64 libffi execution tests fail on Solaris 10/x86
-- steven at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40700
[Bug libffi/40701] [4.5 regression] Many libffi tests fail to compile on Tru64 UNIX
-- steven at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40701
[Bug fortran/40743] [4.5 Regression] ICE when compiling iso_varying_string.f95 at revision 149591
-- steven at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40743
[Bug preprocessor/39533] [4.4/4.5 Regression] -MM may list a header file twice
-- steven at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.4.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39533
[Bug preprocessor/39533] [4.4/4.5 Regression] -MM may list a header file twice
--- Comment #12 from steven at gcc dot gnu dot org 2009-07-15 07:30 --- Tom, ping. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39533
[Bug middle-end/40154] [4.4/4.5 Regression] internal compiler error: in do_SUBST, at combine.c:681
-- steven at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.4.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40154
[Bug fortran/40714] [4.4, 4.5 Regression] Fortran runtime error: Invalid argument
-- steven at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.4.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40714
[Bug middle-end/40747] [4.4/4.5 Regression] wrong code for int-is-in-range test at -O1 and above
-- steven at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.4.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40747
[Bug tree-optimization/40760] [4.3/4.4/4.5 Regression] unbounded recursion in the gimplifier
-- steven at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40760
[Bug target/40735] [4.3/4.4 regression] memory hog compiling big functions with -fPIE
--- Comment #8 from steven at gcc dot gnu dot org 2009-07-15 07:34 --- Does seem to be a real issue, somewhere. When trunk builds again, can you please give it a try too? -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-07-15 07:34:32 date|| Target Milestone|--- |4.3.5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40735
[Bug debug/28547] Large compile time regression with -g
--- Comment #3 from steven at gcc dot gnu dot org 2009-07-15 07:36 --- Paul, ping. This is almost 3 years with zero progress. If this is not an issue in GCC 4.3 or later, then please close this PR. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28547
[Bug libstdc++/28457] ext/pb_ds/regression/tree_data_map_rand.cc fails with a particular random seed.
--- Comment #8 from steven at gcc dot gnu dot org 2009-07-15 07:38 --- The audit log for this PR is awfully quiet... Ping? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28457
[Bug fortran/40714] [4.4, 4.5 Regression] Fortran runtime error: Invalid argument
-- burnus at gcc dot gnu dot org changed: What|Removed |Added GCC build triplet|sparc-unknown-linux-gnu | GCC host triplet|sparc-unknown-linux-gnu | GCC target triplet|sparc-unknown-linux-gnu | Priority|P3 |P4 Target Milestone|4.4.2 |4.4.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40714
[Bug fortran/40726] [4.5 Regression] miscompilation at -O1
--- Comment #8 from burnus at gcc dot gnu dot org 2009-07-15 07:42 --- I pointed this out to Paul already, but appearantly it is still stuck in his whole-file patch queue. Last incarnation of that patch (containing this fix) is at: http://gcc.gnu.org/ml/fortran/2009-07/msg00105.html Paul had another version which fixed several issues, but some last-minute regressions were found... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40726
[Bug c++/40357] [4.5 Regression] compiler hang for C++ code
--- Comment #5 from dcb314 at hotmail dot com 2009-07-15 07:44 --- (In reply to comment #4) Fixed by the patch for PR debug/40705 I don't think so. I tried the code on snapshot 20090709 and it still hangs. By the way, how can a fix for a crash also fix a hang ? I would have thought the two were mutually exclusive. -- dcb314 at hotmail dot com changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40357
[Bug c/40762] possible integer miscompilation
--- Comment #1 from steven at gcc dot gnu dot org 2009-07-15 07:46 --- Richi, this looks like it should go into your bucket of things to look at: ==6729== Conditional jump or move depends on uninitialised value(s) ==6729==at 0x84F22CB: solve_graph (tree-ssa-structalias.c:1570) -- steven at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40762
[Bug c++/40752] -Wconversion: do not warn for operands not larger than target type
--- Comment #6 from photon at seznam dot cz 2009-07-15 07:50 --- (In reply to comment #1) Theses are not false warnings: c = 1; is really c = (int)c 1; They are false warnings. The implicit conversion cannot alter the value. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40752
[Bug c++/40357] [4.5 Regression] compiler hang for C++ code
--- Comment #6 from jason at redhat dot com 2009-07-15 07:51 --- Subject: Re: [4.5 Regression] compiler hang for C++ code On 07/15/2009 09:44 AM, dcb314 at hotmail dot com wrote: I tried the code on snapshot 20090709 and it still hangs. The patch wasn't in that snapshot; it wasn't applied until 20090714. By the way, how can a fix for a crash also fix a hang ? I would have thought the two were mutually exclusive. A correction for the internal representation can fix any manner of failure. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40357
[Bug c++/40752] -Wconversion: do not warn for operands not larger than target type
--- Comment #7 from photon at seznam dot cz 2009-07-15 07:54 --- (In reply to comment #5) Then, let's keep this around as an enhancement request. I think this is actually a bug as the specification of the warning is: Warn for implicit conversions that may alter a value. This is not the case here. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40752
[Bug target/40730] redundant memory load
--- Comment #7 from carrot at google dot com 2009-07-15 08:07 ---
(In reply to comment #6)
Carrot, can you please try this test case with my patch
crossjump_abstract.diff from Bug 20070 applied?
I tried your patch. It did remove the redundant memory load. Following is the
output
push{lr}
ldr r3, [r1]
.L6:
str r3, [r0]
mov r2, r3 // M
cmp r3, #0
bne .L5
b .L3
.L4:
ldr r3, [r3, #8]
b .L6
.L5:
ldr r1, [r3, #4]
cmp r1, #0
beq .L4
.L3:
str r2, [r0, #12]
@ sp needed for prologue
pop {pc}
In pass ifcvt it noticed the difference of two stores is the different pseudo
register number and there is no conflict between the two pseudo registers, so
it rename one of them to the same as another and do basic block cross jump on
them earlier. Then pass iterate.c.161r.cse2 detected the redundant load and
remove it.
But it introduced another redundant move instruction marked as M. At the place
r2 is used, r3 still contain the same result as r2, so we can also use r3
there. I think this is another problem.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40730
[Bug c++/40752] -Wconversion: do not warn for operands not larger than target type
--- Comment #8 from pinskia at gcc dot gnu dot org 2009-07-15 08:13 --- For: c += (char) 1; The value can change as you have a wrapping if c is CHAR_MAX. Likewise with: c += c2; -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40752
[Bug tree-optimization/40759] [4.5 Regression] segfault in useless_type_conversion_p
--- Comment #1 from ubizjak at gmail dot com 2009-07-15 08:19 --- Confirmed on i686 (x86_64 with -m32): Program received signal SIGSEGV, Segmentation fault. useless_type_conversion_p (outer_type=0x2ac18624b240, inner_type=0x0) at ../../gcc-svn/trunk/gcc/tree-ssa.c:1003 1003 if (POINTER_TYPE_P (inner_type) #0 useless_type_conversion_p (outer_type=0x2b34ca46c240, inner_type=0x0) at ../../gcc-svn/trunk/gcc/tree-ssa.c:1003 #1 0x0078f62c in verify_gimple_phi (stmt=0x2b34ca571900) at ../../gcc-svn/trunk/gcc/tree-cfg.c:4095 #2 0x0079816e in verify_stmts () at ../../gcc-svn/trunk/gcc/tree-cfg.c: #3 0x0088214d in verify_ssa ( check_modified_stmt=value optimized out) at ../../gcc-svn/trunk/gcc/tree-ssa.c:545 #4 0x006e57a4 in execute_function_todo (data=value optimized out) at ../../gcc-svn/trunk/gcc/passes.c:1007 -- ubizjak at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Component|c |tree-optimization Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-07-15 08:19:01 date|| Summary|segfault|[4.5 Regression] segfault in ||useless_type_conversion_p http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40759
[Bug middle-end/40747] [4.4/4.5 Regression] wrong code for int-is-in-range test at -O1 and above
--- Comment #5 from sezeroz at gmail dot com 2009-07-15 08:19 --- This bug may result in unreliable binary outputs, why is it targeted for fixing in 4.4.2 and not in 4.4.1? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40747
[Bug tree-optimization/40759] [4.5 Regression] segfault in useless_type_conversion_p
-- ubizjak at gmail dot com changed: What|Removed |Added Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40759
[Bug middle-end/40747] [4.4/4.5 Regression] wrong code for int-is-in-range test at -O1 and above
--- Comment #6 from jakub at gcc dot gnu dot org 2009-07-15 08:28 --- I'm already bootstrapping/regtesting a fix, will post afterwards. If it gets approved quickly, I'll include it in 4.4.1-rc1 I plan to roll today. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.4.2 |4.4.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40747
[Bug middle-end/40747] [4.4/4.5 Regression] wrong code for int-is-in-range test at -O1 and above
-- jakub at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40747
[Bug tree-optimization/40321] [4.4/4.5 Regression] internal compiler error: in compute_antic, at tree-ssa-pre.c:2501
--- Comment #17 from jakub at gcc dot gnu dot org 2009-07-15 08:32 --- Retargetting to 4.4.2, this doesn't seem to get to resolution soon enough. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Priority|P1 |P2 Target Milestone|4.4.1 |4.4.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40321
[Bug fortran/40743] [4.5 Regression] ICE when compiling iso_varying_string.f95 at revision 149591
--- Comment #8 from janus at gcc dot gnu dot org 2009-07-15 08:41 --- Subject: Bug 40743 Author: janus Date: Wed Jul 15 08:41:29 2009 New Revision: 149662 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=149662 Log: 2009-07-15 Janus Weil ja...@gcc.gnu.org PR fortran/40743 * resolve.c (resolve_symbol): Don't resolve the formal namespace of a contained procedure. 2009-07-15 Janus Weil ja...@gcc.gnu.org PR fortran/40743 * gfortran.dg/interface_assignment_4.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/interface_assignment_4.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40743
[Bug fortran/40743] [4.5 Regression] ICE when compiling iso_varying_string.f95 at revision 149591
--- Comment #9 from janus at gcc dot gnu dot org 2009-07-15 08:47 --- Fixed with r149662. Closing. -- janus at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40743
[Bug bootstrap/40753] [4.5 Regression] ICE in refs_may_alias_p_1 for libffi/src/powerpc/ffi.c
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-07-15 09:25 --- Subject: Bug 40753 Author: rguenth Date: Wed Jul 15 09:25:34 2009 New Revision: 149664 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=149664 Log: 2009-07-15 Richard Guenther rguent...@suse.de PR middle-end/40753 * alias.c (ao_ref_from_mem): Reject FUNCTION_DECL and LABEL_DECL bases. * gcc.c-torture/compile/pr40753.c: New testcase. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr40753.c Modified: trunk/gcc/ChangeLog trunk/gcc/alias.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40753
[Bug middle-end/40748] simple switch/case, if/else and arithmetics result in different code
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-07-15 09:34 --- switch-conversion could try to handle this. Generally perfect hashing during switch expansion is another thing. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Component|c |middle-end Ever Confirmed|0 |1 Keywords||missed-optimization Last reconfirmed|-00-00 00:00:00 |2009-07-15 09:34:55 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40748
[Bug c++/40749] [4.3/4.4/4.5 Regression] g++ doesnt report missing return if return is of type const type
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-07-15 09:37 --- Confirmed. 4.2 reports g++-4.2 -Wall t.C t.C: In function const A a(): t.C:6: warning: control reaches end of non-void function -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||diagnostic Known to fail||4.3.3 4.4.0 4.5.0 Known to work||4.2.4 Last reconfirmed|-00-00 00:00:00 |2009-07-15 09:37:13 date|| Summary|g++ doesnt report missing |[4.3/4.4/4.5 Regression] g++ |return if return is of type |doesnt report missing return |const type|if return is of type const ||type Target Milestone|--- |4.3.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40749
[Bug c++/40750] Side-effect of member function call not produced in certain circumstances
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-07-15 09:41 --- Confirmed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||wrong-code Last reconfirmed|-00-00 00:00:00 |2009-07-15 09:41:03 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40750
[Bug libfortran/30694] minval/maxval with +/-Inf
--- Comment #28 from burnus at gcc dot gnu dot org 2009-07-15 09:41 --- (In reply to comment #24) So maybe approach the question differently. Which element in an array of NaNs is the smallest one and what is its value? If I pick any one element, its value is NaN. It does not matter which one I select, its value always comes out NaN. Well, according to IEEE 754:2008 the result is the canonicalized NaN, which is implementation defined. NaNs have a sign and may have different bit patterns (payload) but I think we can ignore those. To be conforming, the NaN should match one of the NaNs in the list. (I think the latter will automatically be the case, but even if not, I think essentially no one will care.) (In reply to comment #25) Now, I have another question: what happens for mixed NaNs? For example, in your scheme, what would be the value of MAXVAL((/sNaN, qNaN/))? If FP trapping is enabled = SIGFPE, if not, treat it like a quiet NaN. Whether MAXVAL([x,y]) returns X or Y is implementation defined and thus the result can be an (untrapped) sNan or qNaN. For completeness, IEEE 754:2008 defines (in 5.3.1): maxNum(x, y) is the canonicalized number y if x y, x if y x, the canonicalized number if one operand is a number and the other a quiet NaN. Otherwise it is either x or y, canonicalized (this means results might differ among implementations). When either x or y is a signaling NaN, then the result is according to 6.2. (Note regarding floating-point number: That includes +/-INF but not NaN.) and (in 6.2.3) If two or more inputs are NaN, then the payload of the resulting NaN should be identical to the payload of one of the input NaNs if representable in the destination format. This standard does not specify which of the input NaNs will provide the payload. * * * See also PR 40643. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30694
[Bug bootstrap/40753] [4.5 Regression] ICE in refs_may_alias_p_1 for libffi/src/powerpc/ffi.c
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-07-15 09:43 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40753
[Bug target/40735] [4.3/4.4 regression] memory hog compiling big functions with -fPIE
--- Comment #9 from rguenth at gcc dot gnu dot org 2009-07-15 09:44 --- DF time on this testcase is already big, and the testcase has lots of function calls which would explain the difference between targets (DF needs to track all call-used/clobbered regs). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40735
[Bug libmudflap/40755] [4.5 Regression] Mudflap instrumentation missing in cloned function.
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40755
[Bug fortran/40756] Cleanup TREE_BLOCK
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement Keywords||memory-hog http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40756
[Bug target/40730] redundant memory load
--- Comment #8 from steven at gcc dot gnu dot org 2009-07-15 09:47 --- That redundant move has to be a separate issue, indeed. I would expect the register allocator to coalesce those registers. I hadn't expected this. I thought the result would be just the removal of the redundant load, but the code that comes out is bigger (14 instructions instead of 13) and has a completely different structure. I'll see if I can understand what is going on. Thus, mine. -- steven at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||20070 AssignedTo|unassigned at gcc dot gnu |steven at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2009-07-13 10:10:07 |2009-07-15 09:47:09 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40730
[Bug middle-end/40747] [4.4/4.5 Regression] wrong code for int-is-in-range test at -O1 and above
--- Comment #7 from jakub at gcc dot gnu dot org 2009-07-15 09:48 --- Patch posted: http://gcc.gnu.org/ml/gcc-patches/2009-07/msg00842.html -- jakub at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2009- ||07/msg00842.html http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40747
[Bug tree-optimization/40759] [4.5 Regression] segfault in useless_type_conversion_p
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-07-15 09:53 ---
Program received signal SIGSEGV, Segmentation fault.
0x086e621a in useless_type_conversion_p (outer_type=0xb7cd43f0, inner_type=0x0)
at /home/richard/src/trunk/gcc/tree-ssa.c:1003
1003 if (POINTER_TYPE_P (inner_type)
(gdb) up
#1 0x085823cc in verify_gimple_phi (stmt=0xb7d7b380)
at /home/richard/src/trunk/gcc/tree-cfg.c:4095
4095 if (!useless_type_conversion_p (type, TREE_TYPE (arg)))
(gdb) call debug_gimple_stmt (stmt)
.MEM_20 = PHI .MEM_33(2), .MEM_24(3)
(gdb) call debug_tree (arg)
ssa_name 0xb7d7eac4 nothrow var var_decl 0xb7d7c5a0 .MEMdef_stmt
version 33 in-free-list
somebody released that SSA name. My bet #1 is honzas CD-DCE changes:
#7 0x0848bf5c in execute_one_pass (pass=0x8d09a40)
at /home/richard/src/trunk/gcc/passes.c:1311
1311 execute_todo (todo_after | pass-todo_flags_finish);
(gdb) p *pass
$1 = {type = GIMPLE_PASS, name = 0x8bb581c cddce,
gate = 0x8646077 gate_dce, execute = 0x8646059 tree_ssa_cd_dce,
sub = 0x0, next = 0x8d0a5a0, static_pass_number = 39,
tv_id = TV_TREE_CD_DCE, properties_required = 40, properties_provided = 0,
properties_destroyed = 0, todo_flags_start = 524288, todo_flags_finish = 13}
Honza, you likely forget to propagate bare symbols to uses before renaming
somewhere?
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||hubicka at gcc dot gnu dot
||org
Keywords||ice-on-valid-code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40759
[Bug c/40757] gcc 4.4.0 miscompiles mpfr-2.4.1
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-07-15 09:55 --- I would also recommend to try a newer snapshot from the gcc 4.4 release branch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40757
[Bug rtl-optimization/40761] [4.4/4.5 Regression] IRA memory hog for insanely nested loops
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-07-15 09:56 --- Is it the nesting of loops or really the number of function calls that is important? -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Version|unknown |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40761
[Bug c/40762] possible integer miscompilation
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-07-15 10:09 ---
Confirmed. With -O2 -fno-inline we get in .optimized
func_36 ()
{
bb 2:
g_10 = 1;
func_53 ();
g_64 = 1;
return 1;
FRE does this. I'll check.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2009-07-15 10:09:19
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40762
[Bug c/40762] possible integer miscompilation
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2009-07-15 10:09:19 |2009-07-15 10:09:26 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40762
[Bug middle-end/40762] [4.5 Regression] CD-DCE messes up virtual SSA form
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-07-15 10:17 ---
We have wrong SSA form before FRE:
;; Function func_36 (func_36)
func_36 ()
{
uint8_t g_64.8;
int64_t g_10.5;
bb 2:
# .MEM_17 = VDEF .MEM_16(D)
g_10 = 1;
# VUSE .MEM_17
g_10.5_2 = g_10;
if (g_10.5_2 != 0)
goto bb 3;
else
goto bb 4;
bb 3:
# .MEM_18 = VDEF .MEM_17
func_53 ();
bb 4:
# VUSE .MEM_17
g_10.5_11 = g_10;
g_64.8_12 = (uint8_t) g_10.5_11;
# .MEM_19 = VDEF .MEM_17
g_64 = g_64.8_12;
return 1;
There is a PHI node missing to merge .MEM_18 and .MEM_17.
Which is caused by CD-DCE changes again. Honza?
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|rguenth at gcc dot gnu dot |hubicka at gcc dot gnu dot
|org |org
Component|c |middle-end
Keywords||wrong-code
Priority|P3 |P1
Summary|possible integer|[4.5 Regression] CD-DCE
|miscompilation |messes up virtual SSA form
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40762
[Bug middle-end/40747] [4.4/4.5 Regression] wrong code for int-is-in-range test at -O1 and above
--- Comment #8 from jakub at gcc dot gnu dot org 2009-07-15 10:18 --- Subject: Bug 40747 Author: jakub Date: Wed Jul 15 10:17:54 2009 New Revision: 149675 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=149675 Log: PR middle-end/40747 * fold-const.c (fold_cond_expr_with_comparison): When folding and = to MIN, make sure the MIN uses the same type as the comparison's operands. * gcc.c-torture/execute/pr40747.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr40747.c Modified: trunk/gcc/ChangeLog trunk/gcc/fold-const.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40747
[Bug tree-optimization/40759] [4.5 Regression] segfault in useless_type_conversion_p
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |hubicka at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40759
[Bug target/40487] Extra zero extensions produced for ARM.
--- Comment #12 from rearnsha at gcc dot gnu dot org 2009-07-15 10:31 --- Fixed with: http://gcc.gnu.org/ml/gcc-patches/2009-07/msg00848.html -- rearnsha at gcc dot gnu dot org changed: What|Removed |Added CC||rearnsha at gcc dot gnu dot ||org Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40487
[Bug lto/40758] [LTO] ICE in partition_view_bitmap, at tree-ssa-live.c:331
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-07-15 10:54 ---
For me
./xgcc -B. -shared ice.o -flto
takes ages because iterative_hash_gimple_type seems to be exponential in time!?
Called from gimple_register_type on
pointer_type 0xb7becb60
type function_type 0xb7becbd0
type void_type 0xb7cb69a0 VOID
align 8 symtab 0 alias set -1 canonical type 0xb7cb69a0
pointer_to_this pointer_type 0xb7cb6a10
QI
size integer_cst 0xb7ca9310 constant 8
unit size integer_cst 0xb7ca932c constant 1
align 8 symtab 0 alias set -1 canonical type 0xb7becc40
arg-types tree_list 0xb7be99a0 value pointer_type 0xb7bec000
chain tree_list 0xb7be99bc value integer_type 0xb7bd50e0
disp_color_t
chain tree_list 0xb7be99d8 value integer_type 0xb7bd50e0
disp_color_t
chain tree_list 0xb7be99f4 value integer_type 0xb7cb6310
chain tree_list 0xb7be9a10 value integer_type
0xb7cb6310 chain tree_list 0xb7be9a2c
pointer_to_this pointer_type 0xb7becb60
unsigned SI
size integer_cst 0xb7ca9498 type integer_type 0xb7cb6070 bit_size_type
constant 32
unit size integer_cst 0xb7ca9284 type integer_type 0xb7cb6000 constant
4
align 32 symtab 0 alias set -1 canonical type 0xb7beccb0
I guess we should try hashing without duplicates or store the hash somewhere...
I cannot reproduce the ICE btw. A patch to fix the slowness would be
Index: gimple.c
===
--- gimple.c(revision 149668)
+++ gimple.c(working copy)
@@ -3537,13 +3537,17 @@ gimple_types_compatible_p (tree t1, tree
return same_p;
}
-
/* Returning a hash value for gimple type TYPE combined with VAL. */
static hashval_t
iterative_hash_gimple_type (const_tree type, hashval_t val, unsigned level)
{
hashval_t v;
+ void **slot;
+
+ if ((slot = pointer_map_contains (type_hash_cache, type)) != NULL)
+return iterative_hash_hashval_t (TREE_ADDRESSABLE (type),
+(hashval_t) (size_t) *slot);
/* Combine a few common features of types so that types are grouped into
smaller sets; when searching for existing matching types to merge,
@@ -3604,6 +3608,8 @@ iterative_hash_gimple_type (const_tree t
v = iterative_hash_hashval_t (nf, v);
}
+ *pointer_map_insert (type_hash_cache, type) = (void *) (size_t) v;
+
return v;
}
@@ -3620,28 +3626,13 @@ static hashval_t
gimple_type_hash (const void *p)
{
const_tree type;
- void **slot;
- hashval_t v;
type = (const_tree) p;
if (type_hash_cache == NULL)
-{
- type_hash_cache = pointer_map_create ();
- slot = NULL;
-}
- else
-slot = pointer_map_contains (type_hash_cache, type);
+type_hash_cache = pointer_map_create ();
- if (slot)
-v = (hashval_t) (size_t) *slot;
- else
-{
- v = iterative_hash_gimple_type (type, 0, 0);
- *pointer_map_insert (type_hash_cache, type) = (void *) (size_t) v;
-}
-
- return v;
+ return iterative_hash_gimple_type (type, 0, 0);
}
I am going to bootstrap and test a variant of that.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40758
[Bug rtl-optimization/40761] [4.4/4.5 Regression] IRA memory hog for insanely nested loops
--- Comment #3 from bonzini at gnu dot org 2009-07-15 11:11 ---
do while does not have the same behavior, so the loop shape is important.
the following is as bad and does not have function calls.
#define ONE while (x-- y)
#define TEN ONE ONE ONE ONE ONE ONE ONE ONE ONE ONE
#define HUN TEN TEN TEN TEN TEN TEN TEN TEN TEN TEN
#define THOUHUN HUN HUN HUN HUN HUN HUN HUN HUN HUN
void foo(int x, int y)
{
/* 11,000 nested whiles. */
THOU THOU THOU THOU THOU THOU THOU THOU THOU THOU THOU
y++;
}
--
bonzini at gnu dot org changed:
What|Removed |Added
Keywords||compile-time-hog
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40761
[Bug c++/40357] [4.5 Regression] compiler hang for C++ code
--- Comment #7 from reichelt at gcc dot gnu dot org 2009-07-15 11:19 --- This is really fixed. -- reichelt at gcc dot gnu dot org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40357
[Bug middle-end/40747] [4.4/4.5 Regression] wrong code for int-is-in-range test at -O1 and above
--- Comment #9 from jakub at gcc dot gnu dot org 2009-07-15 11:23 --- Subject: Bug 40747 Author: jakub Date: Wed Jul 15 11:23:22 2009 New Revision: 149681 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=149681 Log: PR middle-end/40747 * fold-const.c (fold_cond_expr_with_comparison): When folding and = to MIN, make sure the MIN uses the same type as the comparison's operands. * gcc.c-torture/execute/pr40747.c: New test. Added: branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/execute/pr40747.c Modified: branches/gcc-4_4-branch/gcc/ChangeLog branches/gcc-4_4-branch/gcc/fold-const.c branches/gcc-4_4-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40747
[Bug middle-end/40747] [4.4/4.5 Regression] wrong code for int-is-in-range test at -O1 and above
--- Comment #10 from jakub at gcc dot gnu dot org 2009-07-15 11:26 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40747
[Bug c++/40764] New: -O3 gives wrong behaviour, no opt. OK
Without -O3, code works as expected. With -O3, varible is reset to 0. Also, probably index overflow. Where goes the .cc or .i ?? Bugzilla: Horribly scarce user interface! g++ -v outputs: Es werden eingebaute Spezifikationen verwendet. Ziel: i486-linux-gnu Konfiguriert mit: ../src/configure -v --with-pkgversion='Ubuntu 4.3.3-5ubuntu4' --with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3 --program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr --enable-targets=all --with-tune=generic --enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu Thread-Modell: posix gcc-Version 4.3.3 (Ubuntu 4.3.3-5ubuntu4) -- Summary: -O3 gives wrong behaviour, no opt. OK Product: gcc Version: 4.3.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: vielhaber at gmail dot com GCC host triplet: ??? intel x86 (AMD), Ubuntu 9.04, What do you want me to enter h http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40764
[Bug tree-optimization/40759] [4.5 Regression] segfault in useless_type_conversion_p
--- Comment #3 from hubicka at ucw dot cz 2009-07-15 11:29 --- Subject: Re: [4.5 Regression] segfault in useless_type_conversion_p I hope that patch for PR40676 should cure those problems. I am just on the way to Prague, but I will try to look into it tomorrow. Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40759
[Bug tree-optimization/40321] [4.4/4.5 Regression] internal compiler error: in compute_antic, at tree-ssa-pre.c:2501
--- Comment #18 from ich at az2000 dot de 2009-07-15 11:31 --- Will this workaround-patch be included in 4.4.1? Because otherwise the whole 4.4.1 release will be pretty much useless for me. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40321
[Bug c++/40764] -O3 gives wrong behaviour, no opt. OK
--- Comment #1 from vielhaber at gmail dot com 2009-07-15 11:31 --- Created an attachment (id=18198) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18198action=view) The .i with -O3 on. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40764
[Bug c++/40764] -O3 gives wrong behaviour, no opt. OK
--- Comment #2 from vielhaber at gmail dot com 2009-07-15 11:32 --- Created an attachment (id=18199) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18199action=view) The .i file without optimization -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40764
[Bug tree-optimization/40321] [4.4/4.5 Regression] internal compiler error: in compute_antic, at tree-ssa-pre.c:2501
--- Comment #19 from rguenther at suse dot de 2009-07-15 11:33 --- Subject: Re: [4.4/4.5 Regression] internal compiler error: in compute_antic, at tree-ssa-pre.c:2501 On Wed, 15 Jul 2009, ich at az2000 dot de wrote: --- Comment #18 from ich at az2000 dot de 2009-07-15 11:31 --- Will this workaround-patch be included in 4.4.1? Because otherwise the whole 4.4.1 release will be pretty much useless for me. Unlikely. You can use -fno-tree-pre as a workaround. Richrd. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40321
[Bug lto/40765] New: [LTO] ICE verify_ssa failed
r...@ryan:~/gcc/lto/x86-build/gcc$ ./xgcc -v Using built-in specs. COLLECT_GCC=./xgcc Target: i686-pc-linux-gnu Configured with: ../configure --enable-languages=c --enable-lto --disable-bootstrap Thread model: posix gcc version 4.5.0 20090714 (experimental) [lto revision 149644] (lto merged with rev 149625) r...@ryan:~/gcc/lto/x86-build/gcc$ ./xgcc -B. getconf.i -flto -c -O r...@ryan:~/gcc/lto/x86-build/gcc$ ./xgcc -B. confvar.i -flto -c -O r...@ryan:~/gcc/lto/x86-build/gcc$ ./xgcc -B. getconf.o confvar.o -flto -shared In function âmainâ: lto1: error: address taken, but ADDRESSABLE bit not set PHI argument table[0]; for PHI node p_93 = PHI table[0](19), table[0](20) lto1: internal compiler error: verify_ssa failed Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. lto-wrapper: ././xgcc returned 1 exit status collect2: lto-wrapper returned 1 exit status -- Summary: [LTO] ICE verify_ssa failed Product: gcc Version: lto Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rmansfield at qnx dot com GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40765
[Bug c++/40764] -O3 gives wrong behaviour, no opt. OK
--- Comment #3 from vielhaber at gmail dot com 2009-07-15 11:43 --- Created an attachment (id=18200) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18200action=view) The C++ source with comments. Comments in lines 180 describe the erroneous behaviour. Output line starting with 1356 and following has resB[1]=0 (wrong!) with -O3 , but maintains previous value 0x2178... without optimization, which is the correct behaviour. lines 79 and 150 ff. concerning array ix_check must be commented out. Comment in l. 150 gives another error, apparently overwriting the array ix_check[100]. If this array is in use, both with and without -O3, things are the same. I checked all indices and do not see the culprit. Guess I will turn to a high-level language like F77 in the near future... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40764
[Bug lto/40765] [LTO] ICE verify_ssa failed
--- Comment #1 from rmansfield at qnx dot com 2009-07-15 11:44 --- Created an attachment (id=18201) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18201action=view) preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40765
[Bug target/40677] flag -mmultiple is ignored
--- Comment #5 from dje at gcc dot gnu dot org 2009-07-15 12:38 --- The patch seems reasonable, but it exposes a latent bug in Nathan's mmultiple patch that was not tested because of this bug. This patch should have been tested and posted to the GCC mailinglist referencing this PR. -- dje at gcc dot gnu dot org changed: What|Removed |Added CC||dje at gcc dot gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-07-15 12:38:19 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40677
[Bug tree-optimization/40321] [4.4/4.5 Regression] internal compiler error: in compute_antic, at tree-ssa-pre.c:2501
--- Comment #20 from rguenth at gcc dot gnu dot org 2009-07-15 12:42
---
One thing that is odd is that the maximal set misses a_1 and b_2 (but it does
have the default defs). Adding PHI arguments to the maximal set fixes this
PR...
Index: tree-ssa-pre.c
===
--- tree-ssa-pre.c (revision 149663)
+++ tree-ssa-pre.c (working copy)
@@ -3662,6 +3662,16 @@ make_values_for_phi (gimple phi, basic_b
add_to_value (get_expr_value_id (e), e);
bitmap_insert_into_set (PHI_GEN (block), e);
bitmap_value_insert_into_set (AVAIL_OUT (block), e);
+ if (!in_fre)
+ {
+ unsigned i;
+ for (i = 0; i gimple_phi_num_args (phi); ++i)
+ {
+ e = get_or_alloc_expr_for (gimple_phi_arg_def (phi, i));
+ add_to_value (get_expr_value_id (e), e);
+ bitmap_value_insert_into_set (maximal_set, e);
+ }
+ }
}
}
I'll give this a complete round of bootstrapping / testing.
Danny - does this look like an obvious mistake or are they not supposed to
be in the maximal set?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40321
[Bug target/40677] flag -mmultiple is ignored
--- Comment #6 from dje at gcc dot gnu dot org 2009-07-15 12:50 --- The fix for this actually is more involved. Nathan had a patch last October which exposed similar bootstrap problems. He posted a revised patch http://gcc.gnu.org/ml/gcc-patches/2008-11/msg01103.html -- dje at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2008- ||11/msg01103.html http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40677
[Bug tree-optimization/40321] [4.4/4.5 Regression] internal compiler error: in compute_antic, at tree-ssa-pre.c:2501
--- Comment #21 from rguenth at gcc dot gnu dot org 2009-07-15 12:54 --- Correction - only b_2 is missing from the maximal set, a_1 is there because it is used in non-PHI nodes. The fix indeed looks quite obvious to me now ... For reference, here is the function before PRE again: bb 2: bb 3: # a_1 = PHI a_3(D)(2), b_2(6) # b_2 = PHI b_4(D)(2), a_1(6) D.1251_5 = a_1-flag; if (D.1251_5 != 0) goto bb 5; else goto bb 6; bb 6: goto bb 3; bb 5: bb 4: # a_14 = PHI a_1(5) # b_15 = PHI b_2(5) D.1254_10 = a_14-pos; D.1255_11 = b_15-pos; D.1253_12 = D.1255_11 + D.1254_10; return D.1253_12; -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40321
[Bug lto/40758] [LTO] ICE in partition_view_bitmap, at tree-ssa-live.c:331
--- Comment #3 from rmansfield at qnx dot com 2009-07-15 12:58 --- I was able to the ICE using different source. Same usage: r...@ryan:~/gcc/lto/x86-build/gcc$ ./xgcc -B. ice2.i -O -flto -c r...@ryan:~/gcc/lto/x86-build/gcc$ ./xgcc -B. ice2.o -flto -shared In file included from :935:0: ice2.i: In function âvpl_process_verticesâ: ice2.i:7594:1: internal compiler error: in partition_view_bitmap, at tree-ssa-live.c:331 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. lto-wrapper: ././xgcc returned 1 exit status collect2: lto-wrapper returned 1 exit status I can attach the obj files if it will help reproduce the issue. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40758
[Bug lto/40758] [LTO] ICE in partition_view_bitmap, at tree-ssa-live.c:331
--- Comment #4 from rmansfield at qnx dot com 2009-07-15 13:02 --- Created an attachment (id=18202) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18202action=view) 2nd preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40758
[Bug c/40757] gcc 4.4.0 miscompiles mpfr-2.4.1
--- Comment #4 from mikpe at it dot uu dot se 2009-07-15 13:15 --- mpfr-2.4.1 compiles and tests Ok for me on an Ultra5 (USIIi) running sparc64-linux, with gmp-4.2.4 (compiled by gcc-4.3.4) and gcc 4.3.4, 4.4.0, and 4.4.1 20090630. I don't have a T2, but could possibly do some tests on USIIIi/Solaris 9. -- mikpe at it dot uu dot se changed: What|Removed |Added CC||mikpe at it dot uu dot se http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40757
[Bug libstdc++/32354] libstdc++.so.6 missing RPATH
--- Comment #6 from joerg dot richter at pdv-fs dot de 2009-07-15 13:15 --- I stumpled across the same problem recently. Executable references both libstdc++.so and libgcc_s.so. libstdc++.so references libgcc_s.so. Both executable dependencies will be correctly resolved (due to RPATH). But when the dynamic linker tries to resolve the second reference to libgcc_s.so it is not using the RPATH of the executable. Only the (not existing) RPATH of libstdc++.so. Which is correct IMHO. So it goes on and tries the system default search directories. There it finds another libgcc_s.so. But this time it is an old version. The executable refused to start, because some versioned symbols could not be found. If libstdc++.so would be linked with -rpath '$ORIGIN' this would work. Note that this even works, when libstdc++.so and libgcc_s.so are moved to a different location. So I think this bug should be reopened. Note: this was observed on solaris2.10 -- joerg dot richter at pdv-fs dot de changed: What|Removed |Added CC||joerg dot richter at pdv-fs ||dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32354
[Bug tree-optimization/40321] [4.4/4.5 Regression] internal compiler error: in compute_antic, at tree-ssa-pre.c:2501
--- Comment #22 from dberlin at gcc dot gnu dot org 2009-07-15 13:37
---
Subject: Re: [4.4/4.5 Regression] internal
compiler error: in compute_antic, at tree-ssa-pre.c:2501
Phi uses can be in the maximum set as long as they are not phi's themselves.
There is a comment above add_to_exp_gen that explains why:
PHI nodes can't go in the maximal sets because they are not in
TMP_GEN, so it is possible to get into non-monotonic situations
during ANTIC calculation, because it will *add* bits.
(being an intersection problem, the number of values in the set should
only ever stay the same or decrease)
I would be surprised if it bootstraps :)
On Wed, Jul 15, 2009 at 8:42 AM, rguenth at gcc dot gnu dot
orggcc-bugzi...@gcc.gnu.org wrote:
--- Comment #20 from rguenth at gcc dot gnu dot org 2009-07-15 12:42
---
One thing that is odd is that the maximal set misses a_1 and b_2 (but it does
have the default defs). Adding PHI arguments to the maximal set fixes this
PR...
Index: tree-ssa-pre.c
===
--- tree-ssa-pre.c (revision 149663)
+++ tree-ssa-pre.c (working copy)
@@ -3662,6 +3662,16 @@ make_values_for_phi (gimple phi, basic_b
add_to_value (get_expr_value_id (e), e);
bitmap_insert_into_set (PHI_GEN (block), e);
bitmap_value_insert_into_set (AVAIL_OUT (block), e);
+ if (!in_fre)
+ {
+ unsigned i;
+ for (i = 0; i gimple_phi_num_args (phi); ++i)
+ {
+ e = get_or_alloc_expr_for (gimple_phi_arg_def (phi, i));
+ add_to_value (get_expr_value_id (e), e);
+ bitmap_value_insert_into_set (maximal_set, e);
+ }
+ }
}
}
I'll give this a complete round of bootstrapping / testing.
Danny - does this look like an obvious mistake or are they not supposed to
be in the maximal set?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40321
--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40321
[Bug tree-optimization/40321] [4.4/4.5 Regression] internal compiler error: in compute_antic, at tree-ssa-pre.c:2501
--- Comment #23 from dberlin at gcc dot gnu dot org 2009-07-15 13:46 --- Subject: Re: [4.4/4.5 Regression] internal compiler error: in compute_antic, at tree-ssa-pre.c:2501 a_1 shouldn't be in the maximal set. If it is, that's a bug. The history here: We didn't use to have a check for domination in avail_out. As a result, values only died if they were in TMP_GEN. (This is what is *supposed* to happen. At some point we added a check for availability to valid_in_sets and i can't remember why). PHI values are not in TMP_GEN, so they will never disappear from the set once in it. Nowadays, it may be safe to put phi values in there. Honestly, the availability check in valid_in_sets worries me, because it shouldn't be necessary. Names should be prevented from being ANTIC past the point of their definition through subtraction of TMP_GEN. On Wed, Jul 15, 2009 at 8:54 AM, rguenth at gcc dot gnu dot orggcc-bugzi...@gcc.gnu.org wrote: --- Comment #21 from rguenth at gcc dot gnu dot org 2009-07-15 12:54 --- Correction - only b_2 is missing from the maximal set, a_1 is there because it is used in non-PHI nodes. The fix indeed looks quite obvious to me now ... For reference, here is the function before PRE again: bb 2: bb 3: # a_1 = PHI a_3(D)(2), b_2(6) # b_2 = PHI b_4(D)(2), a_1(6) D.1251_5 = a_1-flag; if (D.1251_5 != 0) goto bb 5; else goto bb 6; bb 6: goto bb 3; bb 5: bb 4: # a_14 = PHI a_1(5) # b_15 = PHI b_2(5) D.1254_10 = a_14-pos; D.1255_11 = b_15-pos; D.1253_12 = D.1255_11 + D.1254_10; return D.1253_12; -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40321 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40321
[PATCH] gengtype: don't test undefined value after vasprintf failure
I did a quick scan for misuse of pointer values after failed asprintf-style function uses and spotted a few. Here's a patch for one of them: [this patch is relative to just-updated trunk] From 1f71a26ec38860d863ca751aef049d314a4f34b4 Mon Sep 17 00:00:00 2001 From: Jim Meyering meyer...@redhat.com Date: Sat, 6 Jun 2009 19:10:47 +0200 Subject: [PATCH] gengtype: don't test undefined value after vasprintf failure * gengtype.c (xasprintf): Don't test an undefined value upon vasprintf failure. --- gcc/gengtype.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/gcc/gengtype.c b/gcc/gengtype.c index 1b1e6fa..605dbfb 100644 --- a/gcc/gengtype.c +++ b/gcc/gengtype.c @@ -201,7 +201,7 @@ xasprintf (const char *format, ...) va_start (ap, format); n = vasprintf (result, format, ap); - if (result == NULL || n 0) + if (n 0) fatal (out of memory); va_end (ap); -- 1.6.4.rc0.127.g81400
[Bug libstdc++/37907] [c++0x] support for std::is_standard_layout
-- jason at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-07-15 13:57:51 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37907
[Bug fortran/40766] this fortran program is too slow
--- Comment #1 from linuxl4 at sohu dot com 2009-07-15 15:49 --- My server is an atom330/gentoo gfortran -v GNU Fortran (GCC) 4.5.0 20090715 (experimental) Copyright (C) 2009 Free Software Foundation, Inc. gfortran 1.f90; time ./a.out 4.28173363E+09 real120m30.599s user120m29.164s sys 0m0.464s ifort 1.f90; time ./a.out 4.3692155E+09 real2m56.217s user2m55.871s sys 0m0.352s if I call the functions(sin,cos,tan) from intel's libimf.so, then gfortran 1.f90 -limf 4.31716608E+09 real6m39.177s user6m38.289s sys 0m0.512s -- linuxl4 at sohu dot com changed: What|Removed |Added Summary|this fortran program is too |this fortran program is too |slow|slow http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40766
[Bug fortran/40766] this fortran program is too slow
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-07-15 15:55 --- What is the timing when adding -O3 to the command line. GCC defaults to no optimizations turned on. This is unlike ifort which defaults to having optimizations turned on. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40766
[Bug bootstrap/39020] lto-plugin requires visibility support
--- Comment #3 from ro at gcc dot gnu dot org 2009-07-15 16:03 --- I don't think this is a duplicate: even if the bootstrap compiler is gcc, it may still lack visibility support (as it did on Solaris until recently or on IRIX where ld/rld lack the necessary support). At least, this requirement should be documented separately, and maybe it can be avoided. I'm not certain this is significant, though, since the plugin is only used with gold, which may not be available on affected platforms. -- ro at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|DUPLICATE | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39020
[Bug bootstrap/39023] lto-plugin.c uses mkdtemp unconditionally
--- Comment #3 from ro at gcc dot gnu dot org 2009-07-15 16:05 --- Sorry, my Comment #1 was directed at the wrong bug. mkdtemp is still used unconditionally, and this would e.g. affect Solaris 10 where it is missing. -- ro at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39023
[Bug target/40487] Extra zero extensions produced for ARM.
--- Comment #13 from bonzini at gnu dot org 2009-07-15 16:20 --- For the record, it's actually somewhat related to PR39726 (a m68k pessimization), not PR39715. However, because of the way combine canonicalizes the resulting expression, the patch for that bug does not fix the testcase. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40487
[Bug lto/40754] lto1 dies with SIGBUS/SIGSEGV on Solaris 11/SPARC
--- Comment #1 from ro at gcc dot gnu dot org 2009-07-15 16:51 --- I've rebuilt lto1 with just -g and re-run it under gdb. This is not a NULL-pointer dereference, but an improperly aligned pointer: Starting program: /vol/gccsrc/obj/gcc-lto-20090709/11-gcc/gcc/testsuite/g++/lto1 -quiet -dumpbase cc0dayjK-cp_lto_20080709_0.o.lto.o -mcpu=v9 -auxbase-strip ./cc0dayjK-cp_lto_20080709_0.o.lto.ltrans.o -O0 -version -fltrans-output-list=/var/tmp//cc.caijK.ltrans.out -fmessage-length=0 -fno-wpa -fltrans ./cc0dayjK-cp_lto_20080709_0.o.lto.o -o /var/tmp//cccfaqkK.s [New LWP1] warning: Lowest section in /lib/libdl.so.1 is .dynamic at 0094 GNU GIMPLE (lto merged with rev 149291) version 4.5.0 20090706 (experimental) [lto revision 149403] (sparc-sun-solaris2.11) compiled by GNU C version 4.5.0 20090706 (experimental) [lto revision 149403], GMP version 4.2.1, MPFR version 2.3.2 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 GNU GIMPLE (lto merged with rev 149291) version 4.5.0 20090706 (experimental) [lto revision 149403] (sparc-sun-solaris2.11) compiled by GNU C version 4.5.0 20090706 (experimental) [lto revision 149403], GMP version 4.2.1, MPFR version 2.3.2 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Program received signal SIGSEGV, Segmentation fault. 0x00118ca8 in lto_read_decls (decl_data=0xe4ecd0, data=0xff1b036d, resolutions=0x0) at /vol/gcc/src/gcc-lto/gcc/lto/lto.c:179 1: x/i $pc 0x118ca8 lto_read_decls+36: ld [ %g1 + 8 ], %g2 (gdb) print/x $g1 $13 = 0xff1b036d I haven't yet started to investiate further: this is probably much easier for someone who's familiar with lto. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40754
[Bug c++/40752] -Wconversion: do not warn for operands not larger than target type
--- Comment #11 from photon at seznam dot cz 2009-07-15 16:55 ---
(In reply to comment #8)
For:
c += (char) 1;
The value can change as you have a wrapping if c is CHAR_MAX.
Likewise with:
c += c2;
The value cannot change even if an overflow occurs.
{
unsigned char c = 0xff;
c += 1;
// c is 0 here
c = 0xff;
c = (unsigned int)c + 1;
// c is 0 here
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40752
[Bug c++/40752] -Wconversion: do not warn for operands not larger than target type
--- Comment #12 from pinskia at gcc dot gnu dot org 2009-07-15 16:58 --- Except it does alter its value from 0x100 to 0x00 :). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40752
[Bug c++/40752] -Wconversion: do not warn for operands not larger than target type
--- Comment #13 from pinskia at gcc dot gnu dot org 2009-07-15 17:00 --- Or rather from SCHAR_MAX + 1 to SCHAR_MIN :). Since it is 0x7F + 1 == (int)0x80. So we have a negative value now from a positive value. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40752
