--- 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
--- 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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Summary|inliner introduces |[4.1/4.2 Regression] inliner
|unnecessary type conv
--- 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
--- 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 #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 #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
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 #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
--- 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
[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 #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
--- 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
--
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 #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
--- 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 #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).
--
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||memory-hog
Target Milestone|--- |4.2.0
ht
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;
--- 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
--- 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 #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 #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 #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
--
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
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
--- 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)
--
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
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |bkoz at redhat dot com
|dot org |
41 matches
Mail list logo
