--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |bkoz at redhat dot com
|dot org |
The following file compiles in 30s with "gcc -c" and never compiles with "gcc
-O -c"
--
Summary: A file that can not be compiled in reasonable time/space
Product: gcc
Version: 4.0.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
--- Comment #1 from raffalli at univ-savoie dot fr 2006-06-17 09:27 ---
Created an attachment (id=11687)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11687&action=view)
a file that gcc can not compile with -O
just try gcc -c -O on this file !
(remark no problem with icc)
--
This regression was cause by the patches allowing Boehm-GC to be build with
--enable-objc-gc.
The problem is that instead of testing whether java is part of enabled
languages (as java is a default langauge and the front end is build independent
of the runtime), the new configure test should test w
--
ayers at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |ayers at gcc dot gnu dot org
|dot org
--- Comment #2 from steven at gcc dot gnu dot org 2006-06-17 10:18 ---
It actually does finish for me at -O with gcc 4.0.2. It just takes an
incredible amount of time and memory, but that doesn't surprise me so much,
given the nature of this evil test case ;-)
With gcc 4.2 200606
--- Comment #7 from tobias dot burnus at physik dot fu-berlin dot de
2006-06-17 10:57 ---
The test case of comment #4 is invalid as the Fortran standard says that a
pointer is undefined unless it is associated (allocated, assigned) or
deassociated (nullifyed). In this case it is undefin
--- Comment #3 from steven at gcc dot gnu dot org 2006-06-17 11:05 ---
Caused by excessive inlining:
inline heuristics : 37.25 (25%) usr 0.04 ( 1%) sys 36.56 (15%) wall
2312 kB ( 0%) ggc
integration : 19.91 (13%) usr 1.49 (36%) sys 62.70 (26%) wall
1058857 kB
--- Comment #4 from steven at gcc dot gnu dot org 2006-06-17 11:05 ---
Platform independent. Honza, one for you I suppose.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #23 from rleigh at debian dot org 2006-06-17 14:29 ---
This will take a few more hours. I didn't have a built GCC tree to hand, so
I'm still waiting on "make bootstrap".
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28059
The following test code
-- begin --
typedef struct {
int val;
} Foo;
int func(long longPtr) {
Foo *pFoo = *(Foo **)&longPtr; /* BAD! */
/* Foo *pFoo = (Foo *)longPtr; If you do this instead it works */
return pFoo->val;
}
int main(int argc, const char *argv[]) {
Foo foo;
foo.val = 1;
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||memory-hog
Target Milestone|--- |4.2.0
ht
--- Comment #6 from tbm at cyrius dot com 2006-06-17 14:56 ---
(In reply to comment #3)
> It works in 4.2.0 for sure.
I don't think that's correct. I can confirm that gcc 4.2 20060508 works, but
20060530 and 20060613 definitely fail here (both the C and Objective-C test
cases).
--
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-06-17 14:56 ---
Foo *pFoo = *(Foo **)&longPtr; /* BAD! */
The above statement accesses a "long" as a "Foo*" which does violate aliasing
rules.
*** This bug has been marked as a duplicate of 21920 ***
--
pinskia at gcc dot gnu
--- Comment #100 from pinskia at gcc dot gnu dot org 2006-06-17 14:56
---
*** Bug 28073 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
0060613 definitely fail here (both the C and Objective-C test
> cases).
I works with "4.2.0 20060617".
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28062
--- Comment #8 from tbm at cyrius dot com 2006-06-17 16:26 ---
This ICE got introduced with:
r113775 | sayle | 2006-05-15 06:43:05 +0200 (Mon, 15 May 2006) | 13 lines
PR rtl-optimization/22563
Backports from mainline
* expmed.c (store_fixed_bit_field): When usi
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-06-17 18:18 ---
Same with 4.1. 4.0.3 needs about 500MB ram at -O, while 4.1 get's killed with
cc1: out of memory allocating 1134939624 bytes after a total of 43368448 bytes
(though that first number looks "interesting")
--
rgue
[EMAIL PROTECTED] xmm]$ cat x.c
#include
extern char *e1 (void);
char *e1 (void)
{
volatile __m128 dummy = _mm_set_ps1(0.f);
return "OK";
}
[EMAIL PROTECTED] xmm]$ /usr/gcc-4.2/bin/gcc -m32 -O -msse2 -S -mstackrealign
x.c
[EMAIL PROTECTED] xmm]$ cat x.s
.file "x.c"
.sec
--- Comment #6 from rguenth at gcc dot gnu dot org 2006-06-17 18:44 ---
Btw, we do not die during inlining, but during optimization which is confronted
with one gigantic basic block, as all BBs after inlining are merged by fixupcfg
;)
Oh, and we die during RTL optimizations... but I wo
--- Comment #9 from pluto at agmk dot net 2006-06-17 19:24 ---
patch posted on gcc-patches over month ago. still no response.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25672
typedef struct {
double min;
double max;
} interval;
inline interval add(interval x, interval y)
{
interval r;
r.min = x.min + y.min;
r.max = x.max + y.max;
return r;
}
interval foo (interval a, interval b, interval c)
{
return add (a, add (b, c));
}
for the temporary for gimplifying
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-06-17 19:44 ---
http://gcc.gnu.org/ml/gcc-patches/2006-05/msg01236.html does not help (we don't
FRE structure assignments).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28075
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-06-17 19:45 ---
I have a patch to fix the inliner to get rid of the unnecessary type
conversions.
This only happens with C front-end.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-06-17 19:51 ---
This sort of blocks 28071 because we cannot optimize anything with the casts
there and so regalloc blows up with the large BB.
--
rguenth at gcc dot gnu dot org changed:
What|Removed
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-06-17 19:53 ---
Here is the patch:
Index: tree-inline.c
===
--- tree-inline.c (revision 114740)
+++ tree-inline.c (working copy)
@@ -1081,6 +1081,8 @@ setup
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Summary|inliner introduces |[4.1/4.2 Regression] inliner
|unnecessary type conv
--- Comment #2 from Jerry dot James at usu dot edu 2006-06-17 21:04 ---
Created an attachment (id=11688)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11688&action=view)
Testcase showing an optimizaton bug
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28045
--- Comment #3 from Jerry dot James at usu dot edu 2006-06-17 21:05 ---
I can confirm that both the mainline and the current 4.1 branch compile the
testcase correctly. Nevertheless, both the current 4.1 branch and the mainline
(revision 114741) are still miscompiling XEmacs when any opt
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-06-17 22:06 ---
Reduced testcase:
struct a
{
unsigned int bits : 1;
signed long val : ((sizeof(long) * 8) - 1);
};
int Fnegate (struct a b)
{
if ((-((long)b.val)) <= ((long) ((1UL << (((sizeof(long) * 8) - 1) - 1))
-1UL)) &&
--- Comment #101 from steven at gcc dot gnu dot org 2006-06-17 22:06
---
Release folks from the I-use-C-but-do-not-understand-its-semantics punishment
list.
Seriously, though... There is no reason to spam every one of these people
every time there is another duplicate of this bug.
-
--- Comment #102 from dberlin at gcc dot gnu dot org 2006-06-17 23:42
---
Subject: Re: alias violating
steven at gcc dot gnu dot org wrote:
> --- Comment #101 from steven at gcc dot gnu dot org 2006-06-17 22:06
> ---
> Release folks from the I-use-C-but-do-not-understand-its
--- Comment #24 from rleigh at debian dot org 2006-06-18 00:27 ---
../gcc-20060613/configure --enable-languages=c,c++
--prefix=/home/rleigh/gcc-test --enable-shared --with-system-zlib
--without-included-gettext --enable-threads=posix --enable-nls
--enable-__cxa_atexit --enable-libstdcxx
--- Comment #9 from tbm at cyrius dot com 2006-06-18 01:09 ---
(In reply to comment #7)
> It works with "4.2.0 20060617".
Hmm.
(sid)46:[EMAIL PROTECTED]: ~/tmp/gcc/4.2/gcc] ./cc1 -O2 ~/m.c
NSMakePoint RelativePoint g
Analyzing compilation unitPerforming intraprocedural
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-06-18 02:58
---
You know what I have a fix for an inliner bug in my tree which also fixes this
bug. I am going to test that patch fully and submit it for both 4.1.x and
4.2.x.
--
pinskia at gcc dot gnu dot org changed:
--- Comment #7 from jvdelisle at gcc dot gnu dot org 2006-06-18 06:36
---
Subject: Bug 19310
Author: jvdelisle
Date: Sun Jun 18 06:36:45 2006
New Revision: 114752
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114752
Log:
2006-06-18 Jerry DeLisle <[EMAIL PROTECTED]>
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2006-06-18 06:42
---
Subject: Bug 19904
Author: jvdelisle
Date: Sun Jun 18 06:42:26 2006
New Revision: 114753
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114753
Log:
2006-06-18 Jerry DeLisle <[EMAIL PROTECTED]>
--- Comment #8 from jvdelisle at gcc dot gnu dot org 2006-06-18 06:42
---
Subject: Bug 19310
Author: jvdelisle
Date: Sun Jun 18 06:42:26 2006
New Revision: 114753
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114753
Log:
2006-06-18 Jerry DeLisle <[EMAIL PROTECTED]>
--- Comment #9 from jvdelisle at gcc dot gnu dot org 2006-06-18 06:48
---
Fixed on 4.2
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
Summar
--- Comment #7 from jvdelisle at gcc dot gnu dot org 2006-06-18 06:49
---
Fixed on 4.2
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
Summar
41 matches
Mail list logo
