--- Comment #15 from paul dot richard dot thomas at cea dot fr 2006-03-23
08:06 ---
Subject: RE: EQUIVALENCE broken in 32-bit code with optimization -O2
I thought to take a look at the patch tonight; does it look OK to you?
Paul
-Message d'origine-
De : pinskia at gcc dot
--
bonzini at gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |bonzini at gnu dot org
|dot org |
While PR 17298 fixed part of the OP to PR17298, for logical transfer statements
the problem persists with 4.2.0 20060323
./numrec-f90 gfortran -v -c src/bessj.f90
Es werden eingebaute Spezifikationen verwendet.
Ziel: i686-pc-linux-gnu
--- Comment #1 from c dot lemmen at fz-juelich dot de 2006-03-23 09:27
---
Last bug preventing the successful compilation of numerical recipes with
gfortran
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26822
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-03-23 09:29 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from rguenth at gcc dot gnu dot org 2006-03-23 09:35 ---
Looks related to PR25211
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-03-23 09:36 ---
Looks related to PR25211
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-03-23 09:37 ---
Maybe realated to PR25211, but not with PHI nodes here.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from law at redhat dot com 2006-03-23 09:48 ---
Subject: Re: [4.2 Regression] ICE at
gcc/tree-gimple.c:269
On Thu, 2006-03-23 at 00:09 +, pinskia at gcc dot gnu dot org wrote:
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-03-23 00:09
--- Comment #2 from bonzini at gnu dot org 2006-03-23 10:05 ---
I'm taking this.
--
bonzini at gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at
--- Comment #7 from ebotcazou at gcc dot gnu dot org 2006-03-23 10:25
---
I guess (only guess!) that the types differe in a way that aliasing does not
see them clobbered by means of type based alias analysis. Can you try if
-fno-strict-aliasing fixes it?
No, there is really a hole
--- Comment #8 from ebotcazou at gcc dot gnu dot org 2006-03-23 10:27
---
Created an attachment (id=11103)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11103action=view)
Reduced C testcase.
Compile at -O1 on x86.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25737
--- Comment #7 from uros at kss-loka dot si 2006-03-23 10:33 ---
Patch at http://gcc.gnu.org/ml/gcc-patches/2006-03/msg01435.html
--
uros at kss-loka dot si changed:
What|Removed |Added
--- Comment #4 from reichelt at gcc dot gnu dot org 2006-03-23 10:45
---
Fixed by RTH's patch for PS 26084.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from bonzini at gnu dot org 2006-03-23 10:56 ---
Reproducible with -O -ffast-math -ftree-vectorize -msse -msse2 which means the
testcase can easily go in the vect testsuite. Testing a patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26821
--- Comment #9 from rguenth at gcc dot gnu dot org 2006-03-23 11:08 ---
Yay. Reduced testcase:
extern void abort (void);
struct delay_block {
struct delay_block *succ;
};
static struct delay_block Timer_Queue;
struct delay_block* time_enqueue (struct delay_block *d)
{
struct
--- Comment #7 from rakdver at atrey dot karlin dot mff dot cuni dot cz
2006-03-23 11:27 ---
Subject: Re: Segmentation fault on testsuite case gcc.dg/20020425-1.c
recursive gimplification will of course break at some point here. I remember
Zdenek rewriting gimplification to a
The following code snippet causes an ICE when compiled with -fopenmp:
==
struct A
{
~A() {}
};
struct B
{
A a;
B();
};
void foo()
{
#pragma omp parallel
{
B b[1];
new int;
}
}
==
bug.cc: In function 'void foo()':
--- Comment #17 from reichelt at gcc dot gnu dot org 2006-03-23 11:36
---
The ICE in add_stmt_to_eh_region_fn is now tracked in PR26823.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26084
The following code is compiled incorrectly with -O2:
#include stdlib.h
void f(int x) {
if (x 0) {
if (-x 0) {
exit(1);
}
}
}
int main() {
f(-0x8000);
exit(0);
}
$ gcc foo.c; ./a.out
$ gcc -O2 foo.c; ./a.out
zsh: 4407 exit 1
I have djgpp g++ compiler 4.0.0 running on Windows.
To compile I use
gpp -o file -O2 file.cpp
After executing following code
-
#include algorithm
#include iostream
#include sstream
#include string
#include vector
#include queue
#include set
#include map
#include cstdio
/space/rguenther/install/gcc-4.1.0/bin/gcc -O -fomit-frame-pointer -march=i586
-S nvl160095.3-2.min.i -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: /space/rguenther/src/svn/gcc-4_1-branch/configure
--enable-cxa_at_exit --enable-threads=posix --enable-languages=c,c++,fortran
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-03-23 13:00 ---
Created an attachment (id=11104)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11104action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26826
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-03-23 13:05 ---
#1 0x08450df9 in reg_or_subregno (reg=0xb7d87780)
at /space/rguenther/src/svn/gcc-4_1-branch/gcc/jump.c:2011
2011 gcc_assert (REG_P (reg));
(gdb) call debug_rtx(reg)
(mem/c:SI (plus:SI (reg/f:SI 7 sp)
--- Comment #3 from baldrick at free dot fr 2006-03-23 13:19 ---
I've had a look at c35507m. I think it's a front-end bug. The problem occurs
in this type support subprogram:
C35507M.CHARRP (A, F)
{
if ((system__unsigned_types__unsigned) A - 4 = 1)
{
return (integer)
--- Comment #10 from dberlin at gcc dot gnu dot org 2006-03-23 13:40
---
This shows a bunch of bugs actually:
PTA thinks it doesn't need to solve the graph when it does.
The subvar isn't initially marked as addressable if the regular var is in
create_sft.
The second is what is
--- Comment #11 from rguenther at suse dot de 2006-03-23 13:43 ---
Subject: Re: [4.1/4.2 Regression] ACATS tests
c974001 and c974013 do not terminate with struct aliasing enabled
On Thu, 23 Mar 2006, dberlin at gcc dot gnu dot org wrote:
This shows a bunch of bugs actually:
PTA
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-23 14:12 ---
-0x8000 is going to overflow and for signed integers overflow is undefined.
If you want signed integers to be defined to be wrapping use -fwrapv.
--
pinskia at gcc dot gnu dot org changed:
What
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-03-23 14:33 ---
Reduced testcase:
typedef struct {
unsigned short FacilitySelector;
} _cmsg;
typedef struct _AppPlci {
int *appl;
} AppPlci_t;
void AppPlci_hold_reply(AppPlci_t *aplci, unsigned short SuppServiceReason)
{
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-03-23 14:34 ---
Works for me. Make sure the correct libstdc++ is used for executing.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26825
--- Comment #2 from falk at debian dot org 2006-03-23 14:44 ---
Wait a minute. 0x8000 is unsigned. So -0x8000 is well-defined, and
is 0x8000 (unsigned). This is then converted to signed. Since 0x8000
cannot be represented in signed, the result is implementation specific.
--- Comment #4 from bonzini at gnu dot org 2006-03-23 14:47 ---
Looks like we have a (subreg (mem)) which this guard misses:
/* If a memory location is needed for the copy, make one. */
if (in != 0 (REG_P (in) || GET_CODE (in) == SUBREG)
reg_or_subregno (in)
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-03-23 14:49 ---
It is the -x in f where x = 0x8000 which is undefined as it overflows.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
On Mar 23, 2006, at 3:06 AM, paul dot richard dot thomas at cea dot
fr wrote:
I thought to take a look at the patch tonight; does it look OK to you?
I forgot to mention, this was about the patch I was going to create
anyways.
-- Pinski
--- Comment #16 from pinskia at gcc dot gnu dot org 2006-03-23 14:54
---
Subject: Re: EQUIVALENCE broken in 32-bit code with optimization -O2
On Mar 23, 2006, at 3:06 AM, paul dot richard dot thomas at cea dot
fr wrote:
I thought to take a look at the patch tonight; does it look
--- Comment #4 from falk at debian dot org 2006-03-23 14:57 ---
(In reply to comment #3)
It is the -x in f where x = 0x8000 which is undefined as it overflows.
Oh. I see. Right.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26824
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-03-23 15:01 ---
I have a patch in testing.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26826
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-03-23 15:09 ---
Subject: Bug 26795
Author: pinskia
Date: Thu Mar 23 15:09:51 2006
New Revision: 112319
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=112319
Log:
2006-03-23 Andrew Pinski [EMAIL PROTECTED]
PR
--- Comment #5 from simonmar at microsoft dot com 2006-03-23 15:10 ---
I see your point, but I still think there's a bug. Let me change the code
slightly:
#include stdlib.h
#include stdio.h
void f(int x) {
long y;
if (x 0) {
y = -x;
if (y 0) {
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-03-23 15:10
---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from rearnsha at gcc dot gnu dot org 2006-03-23 15:14
---
Pinskia is right, and this is just as undefined as your previous example
(negating INT_MIN is just undefined, however you do it). All you've done is
obfuscated things a bit more.
--
rearnsha at gcc dot gnu
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-03-23 15:15 ---
(In reply to comment #5)
I see your point, but I still think there's a bug. Let me change the code
slightly:
The code is still undefined, as you are comparing an overflowed variable to
something.
-x is still
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-03-23 15:17 ---
Reopening to ...
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-03-23 15:17 ---
Mark as a dup of bug 25329.
*** This bug has been marked as a duplicate of 25329 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-23 15:17 ---
*** Bug 26824 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Hello,
well I got another GNAT BUG DETECTED. This time it's real lot of files - I
which I could help here but I only act as packager here.
Martin
---
gcc -v
Using built-in specs.
Target: i586-suse-linux
Configured with: ../gcc-4.1.0/configure --enable-gmp --enable-mpfr
--enable-threads=posix
--- Comment #1 from krischik at users dot sourceforge dot net 2006-03-23
15:43 ---
Created an attachment (id=11105)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11105action=view)
All those GTK/Ada and GPS sources.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26827
--- Comment #4 from rth at gcc dot gnu dot org 2006-03-23 15:47 ---
Subject: Bug 26347
Author: rth
Date: Thu Mar 23 15:47:50 2006
New Revision: 112320
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=112320
Log:
PR target/26347
* config/alpha/predicates.md
--- Comment #5 from rth at gcc dot gnu dot org 2006-03-23 15:48 ---
Subject: Bug 26347
Author: rth
Date: Thu Mar 23 15:48:24 2006
New Revision: 112321
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=112321
Log:
PR target/26347
* config/alpha/predicates.md
--- Comment #6 from rth at gcc dot gnu dot org 2006-03-23 15:49 ---
Subject: Bug 26347
Author: rth
Date: Thu Mar 23 15:49:00 2006
New Revision: 112322
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=112322
Log:
PR target/26347
* config/alpha/predicates.md
--
rth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org
|dot org
--- Comment #7 from rth at gcc dot gnu dot org 2006-03-23 15:49 ---
Fixed.
--
rth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
struct node { struct node* next; };
static inline
void destruct_list( struct node const* begin, struct node const* end )
{
while ( begin != end )
{
begin = begin-next;
}
}
int main()
{
struct node n;
n.next = n;
destruct_list(n, 0);
return 0;
}
(...)
rm -rf classes
test -z /usr/share/classpath/tools || mkdir -p --
/tmp/gcc-4.2.0-root-pluto/usr/share/classpath/tools
/usr/bin/install -c -m 644 '../../../../../libjava/classpath/tools/tools.zip'
'/tmp/gcc-4.2.0-root-pluto/usr/share/classpath/tools/tools.zip'
/usr/bin/install: cannot stat
At -O1 and up we need a huge amount of memory and compile-time to compile the
testcase. My x86_64 box is at 3GB ram and 30min now, still building.
--
Summary: Insane amount of compile-time / memory needed at -O1 and
up
Product: gcc
Version:
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-03-23 16:48 ---
Created an attachment (id=11106)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11106action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26830
part of the OP to PR17298, for logical transfer statements
the problem persists with 4.2.0 20060323
./numrec-f90 gfortran -v -c src/bessj.f90
Es werden eingebaute Spezifikationen verwendet.
Ziel: i686-pc-linux-gnu
Konfiguriert mit: /opt/src/gcc
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-23 16:56 ---
I was just able to boostrap and install with reversion 112250.
What options are you using to configure with and how are you building/install?
--
pinskia at gcc dot gnu dot org changed:
What
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-03-23 16:56 ---
gcc 3.3.6 is fine on i686, 400MB ram, 30s compile time at -O1. 3.4.6 is also
fine wit -O1 -funit-at-a-time, so tree-ssa related. 4.0.3 is a little worse,
560MB and 60s, but still reasonable. So my bet is aliasing
-libgcj
--enable-libgcj-multifile --enable-libgcj-database --enable-gtk-cairo
--enable-java-awt=qt,gtk,xlib --enable-jni --enable-xmlj --enable-alsa
--enable-dssi x86_64-pld-linux
Thread model: posix
gcc version 4.2.0 20060323 (experimental) (PLD-Linux)
revision 112317.
--
http://gcc.gnu.org
--- Comment #3 from pluto at agmk dot net 2006-03-23 17:06 ---
%{__make} \
GCJFLAGS=%{rpmcflags} \
BOOT_CFLAGS=%{rpmcflags} \
STAGE1_CFLAGS=%{rpmcflags} -O0 \
GNATLIBCFLAGS=%{rpmcflags} \
LDFLAGS_FOR_TARGET=%{rpmldflags} \
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-23 17:13 ---
Well considering the infinite loop is still there, this is not a bug.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-03-23 17:15 ---
Can you try configuring with an absolute path instead of a relative one?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26829
root: gcc -v
Using built-in specs.
Configured with: FreeBSD/i386 system compiler
Thread model: posix
gcc version 3.4.4 [FreeBSD] 20050518
root: uname -a
FreeBSD ws3-plovdiv.digsys.bg 6.1-PRERELEASE FreeBSD
6.1-PRERELEASE #0: Wed Mar 22 20:44:32 EET 2006
[EMAIL
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-03-23 17:29 ---
-fno-tree-salias brings us back to sane behavior.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-03-23 17:36 ---
Well, not exactly sane, but topping at 630MB and finishing after 6min, which is
enough of a regression.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26830
--- Comment #21 from dave at hiauly1 dot hia dot nrc dot ca 2006-03-23
17:49 ---
Subject: Re: 4.1.0 doesn't build in 64bit on PA-RISC
stage1/xgcc -Bstage1/ -B/usr/local/pa20_64/hppa64-hp-hpux11.11/bin/ -g -O2
-DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes
--- Comment #12 from ebotcazou at gcc dot gnu dot org 2006-03-23 17:57
---
PTA thinks it doesn't need to solve the graph when it does.
The subvar isn't initially marked as addressable if the regular var is in
create_sft.
The second is what is actually causing your bug, AFAICT.
When reporting DJGPP bugs, please run your app under gdb and use
where to get a traceback, or use djgpp's symify (or bfdsymify) to
replace these hex numbers with file/line information. You may need to
compile your application with -g to get symbolic debugging
information.
Call frame traceback
--- Comment #2 from dj at redhat dot com 2006-03-23 18:07 ---
Subject: Re: New: bad allocation while adding new elements to vector
When reporting DJGPP bugs, please run your app under gdb and use
where to get a traceback, or use djgpp's symify (or bfdsymify) to
replace these hex
--- Comment #13 from ebotcazou at gcc dot gnu dot org 2006-03-23 18:08
---
That is indeed sufficient to fix the bug for the C testcase but not for an
equivalent Ada testcase, so Richard might have been right in thinking that
there is also some type frobbing on the Ada side :-(
Not
--- Comment #22 from h dot m dot brand at xs4all dot nl 2006-03-23 18:11
---
http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2006-03/msg00524.html
shows that I've been trying to pin the perl5 failure related to this too, but
I'm kinda stuck for now.
--
--- Comment #14 from ebotcazou at gcc dot gnu dot org 2006-03-23 18:13
---
The Ada testcase is correctly compiled at -O with the create_sft change and
Index: tree-ssa-structalias.c
===
--- tree-ssa-structalias.c
--- Comment #15 from ebotcazou at gcc dot gnu dot org 2006-03-23 18:24
---
The tree aliasing machinery appears to totally overlook the flag
/* Used in a FIELD_DECL to indicate that we cannot form the address of
this component. */
#define DECL_NONADDRESSABLE_P(NODE) \
--- Comment #4 from tkoenig at gcc dot gnu dot org 2006-03-23 18:36 ---
There is a problem with the current solution on trunk.
When we do
allocate (a(10))
allocate (a(20),stat=i)
the size information is changed, but the size of the array is not.
--
--- Comment #5 from pluto at agmk dot net 2006-03-23 18:53 ---
(In reply to comment #4)
Can you try configuring with an absolute path instead of a relative one?
here's a fix.
Index: trunk/libjava/classpath/configure.ac
--- Comment #5 from jakub at gcc dot gnu dot org 2006-03-23 19:54 ---
This is actually ICE on valid, a small modification of the testcase
that makes it valid still ICEs.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from dpatel at gcc dot gnu dot org 2006-03-23 19:55 ---
Subject: Bug 24302
Author: dpatel
Date: Thu Mar 23 19:55:47 2006
New Revision: 112329
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=112329
Log:
Radar 4484060
PR c++/24302
* toplev.c
--- Comment #2 from krischik at users dot sourceforge dot net 2006-03-23
20:03 ---
Hello,
Tests on x86_64-suse-linux failed as well.
Martin
--
krischik at users dot sourceforge dot net changed:
What|Removed |Added
--- Comment #8 from krischik at users dot sourceforge dot net 2006-03-23
20:07 ---
Hello Andrew,
you are right - the hole of AWS compiles nicely with x86_64.
Martin
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26678
--- Comment #16 from dberlin at gcc dot gnu dot org 2006-03-23 20:12
---
Subject: Re: [4.1/4.2 Regression] ACATS tests
c974001 and c974013 do not terminate with struct aliasing
On Thu, 2006-03-23 at 18:24 +, ebotcazou at gcc dot gnu dot org
wrote:
--- Comment #15
As the subject says, these four standard names are not documented. By analogy
to the way in which sibcall_epilogue has a separate entry from epilogue,
they should also have their own entries in the standard pattern names for
generation chapter of the internals manual. The entry for
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-23 20:49 ---
Interesting, sibcall_epilogue is documented though.
http://gcc.gnu.org/onlinedocs/gccint/Standard-Names.html#Standard-Names
--
pinskia at gcc dot gnu dot org changed:
What|Removed
Howdy,
there is a recent regression which shows up in the
attached code which is stripped down from LAPACK's
dlasv2.f
% gfc --version
GNU Fortran 95 (GCC) 4.2.0 20060323 (experimental)
% gfc -c dlasv2.f -O
dlasv2.f: In function 'dlasv2':
dlasv2.f:3: error: missing definition
--- Comment #1 from anlauf at gmx dot de 2006-03-23 20:56 ---
Created an attachment (id=11107)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11107action=view)
Stripped down LAPACK subroutine
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26832
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-03-23 21:03 ---
Now, with -O -fno-tree-salias we have
tree copy propagation : 4.30 ( 1%) usr 0.06 ( 0%) sys 4.48 ( 1%) wall
1076 kB ( 0%) ggc
tree SSA rewrite : 280.55 (76%) usr 0.44 ( 3%) sys 287.70 (69%) wall
8254
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-23 21:05 ---
Replacing 't_35' with constant '1.0e+0'
Original statement:tt_37 = t_35 * t_35
Updated statement:tt_37 = t_35
Replacing 'tt_37' with variable 't_35'
Original statement:D.1282_38 = tt_37 + mm_36
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-03-23 21:05
---
*** Bug 26832 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from rguenth at gcc dot gnu dot org 2006-03-23 21:15 ---
I blame into-ssa
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Dunno
See File
--
Summary: ICE Segmentation fault
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy:
--- Comment #1 from malitzke at metronets dot com 2006-03-23 21:24 ---
Created an attachment (id=11108)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11108action=view)
complete case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26833
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #7 from rguenth at gcc dot gnu dot org 2006-03-23 21:37 ---
And I'm wrong. It's loop header copying!(?!)
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-23 21:41 ---
Reducing.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26833
Howdy,
the subject says it all:
% cat gfcbug34.f90
subroutine gfcbug34 ()
implicit none
type t
integer, pointer :: i (:) = NULL ()
end type t
type(t), save :: gf
write(*,*) 'ubound:', ubound (gf% i)
write(*,*) 'lbound:', lbound (gf% i)
end subroutine gfcbug34
% gfc -c
--- Comment #8 from rguenth at gcc dot gnu dot org 2006-03-23 22:09 ---
With structure aliasing on, we create 22326 SFTs for the
CShadingContext::execute function. Aliasing completely breaks down then:
execute: Total number of aliased vops: 18901314
execute: Total number of aliased
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-03-23 22:19 ---
Reduced testcase:
void yasm_lc3b__parse_insn( int num_info, int *num_operands
, int *operands, int op)
{
int found = 0;
int i;
for (; num_info0 !found; num_info--)
{
int mismatch = 0;
for(i =
--- Comment #17 from ebotcazou at gcc dot gnu dot org 2006-03-23 22:21
---
Errr, but that would make it non-addressable, and thus, non-aliasable,
which is the exact opposite effect of what is causing the problem.
Take a look at alias.c:record_component_aliases. :-)
--
1 - 100 of 132 matches
Mail list logo
