--- Comment #12 from law at redhat dot com 2006-03-24 07:49 ---
Subject: Re: New: ICE at
gcc/tree-gimple.c:269
On Wed, 2006-03-22 at 16:47 +, jb at gcc dot gnu dot org wrote:
> The capacita benchmark, part of the polyhedron benchmark suite, fails with the
> ICE in the summ
--- Comment #3 from Simon80 at gmail dot com 2006-03-24 07:01 ---
(In reply to comment #2)
> IIRC (there is a bug about this but I cannot find it) pointer to member
> functions are special as you cannot use them to evade accessibility.
>
I thought of this after I reported the bug, and
--- Comment #11 from law at redhat dot com 2006-03-24 06:45 ---
*** Bug 26833 has been marked as a duplicate of this bug. ***
--
law at redhat dot com changed:
What|Removed |Added
--- Comment #7 from law at redhat dot com 2006-03-24 06:45 ---
Ultimately this is the same root cause as 26806.
*** This bug has been marked as a duplicate of 26806 ***
--
law at redhat dot com changed:
What|Removed |Added
--- Comment #6 from law at redhat dot com 2006-03-24 06:43 ---
Subject: Re: [4.2 Regression] ICE
Segmentation fault
On Thu, 2006-03-23 at 22:19 +, pinskia at gcc dot gnu dot org wrote:
> void yasm_lc3b__parse_insn( int num_info, int *num_operands
> , int *operands, int op)
--- Comment #21 from dberlin at gcc dot gnu dot org 2006-03-24 04:04
---
Subject: Re: [4.1/4.2 Regression] ACATS tests
c974001 and c974013 do not terminate with struct aliasing
On Thu, 2006-03-23 at 22:33 +, ebotcazou at gcc dot gnu dot org
wrote:
>
> --- Comment #19
--- Comment #20 from dberlin at gcc dot gnu dot org 2006-03-24 04:00
---
Subject: Re: [4.1/4.2 Regression] ACATS tests
c974001 and c974013 do not terminate with struct aliasing
On Thu, 2006-03-23 at 22:21 +, ebotcazou at gcc dot gnu dot org
wrote:
>
> --- Comment #17
--- Comment #2 from patchapp at dberlin dot org 2006-03-24 03:38 ---
Subject: Bug number pr26026
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2006-03/msg01468.html
--
http://gcc.gnu.org/bugzilla/sh
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-03-24 03:32 ---
This happens also on x86_64-linux-gnu.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #1 from geoffk at gcc dot gnu dot org 2006-03-24 03:14 ---
I'll work around 26840.
--
geoffk at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-03-24 03:04 ---
I am adding the build keyword as this source would come from crt3.c which fixes
a different build failure.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-24 03:03 ---
Caused by:
2006-03-20 Jeff Law <[EMAIL PROTECTED]>
* tree-pass.h (pass_phi_only_copy_prop): Delete.
(pass_phi_only_cprop): Declare.
* passes.c (init_optimization_passes): Replace pass_phi_o
--- Comment #1 from geoffk at gcc dot gnu dot org 2006-03-24 03:00 ---
Passing -fno-tree-dominator-opts disables sufficient optimisations to avoid the
problem.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26840
The following testcase:
extern int f1 (void **);
extern void f2 (void *);
struct s
{
unsigned char field1;
int field2;
};
static inline struct s *
get_globals (void)
{
struct s * r;
void * rr;
if (f1 (&rr))
return 0;
r = rr;
if (! r)
{
extern struct s t;
r = &t
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2006-03-24 02:06
---
I think I have a fix for this. The internal_unit is a single static variable
declared in unit.c. So when we have recursive calls to internal IO we are
stepping on our own feet.
The dtp structure also contains a
--- Comment #2 from jsm28 at gcc dot gnu dot org 2006-03-24 02:05 ---
Subject: Bug 20451
Author: jsm28
Date: Fri Mar 24 02:05:46 2006
New Revision: 112347
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112347
Log:
PR libstdc++/20448
PR libstdc++/20451
* l
--- Comment #5 from jsm28 at gcc dot gnu dot org 2006-03-24 02:05 ---
Subject: Bug 20448
Author: jsm28
Date: Fri Mar 24 02:05:46 2006
New Revision: 112347
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112347
Log:
PR libstdc++/20448
PR libstdc++/20451
* l
--- Comment #1 from jsm28 at gcc dot gnu dot org 2006-03-24 01:59 ---
Subject: Bug 20451
Author: jsm28
Date: Fri Mar 24 01:59:35 2006
New Revision: 112346
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112346
Log:
PR libstdc++/20448
PR libstdc++/20451
* s
--- Comment #4 from jsm28 at gcc dot gnu dot org 2006-03-24 01:59 ---
Subject: Bug 20448
Author: jsm28
Date: Fri Mar 24 01:59:35 2006
New Revision: 112346
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112346
Log:
PR libstdc++/20448
PR libstdc++/20451
* s
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-24 00:02 ---
IIRC (there is a bug about this but I cannot find it) pointer to member
functions are special as you cannot use them to evade accessibility.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26838
--- Comment #1 from Simon80 at gmail dot com 2006-03-23 23:44 ---
Sorry for double posting, but here's the g++ output:
# g++ testcase.cpp
testcase.cpp: In member function 'void C::f()':
testcase.cpp:4: error: 'void A::f()' is protected
testcase.cpp:20: error: within this context
Also,
This seems to be similar to a really old bug on one of the mailing lists,
assuming that it's actually a bug:
class A
{
protected:
void f(){}
};
class B :
public A
{
int c;
};
class C :
public B
{
protected:
void f()
{
A::f(); // ok - see http://gcc.gnu.org/ml/gcc-bugs/1997-10/ms
$ elm3b11:/home/pawar> /opt/gcc-nightly/trunk-20060323/bin/gfortran -O2 -m32
test.f90
test.f90: In function ld_mod:
test.f90:1: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instru
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-23 22:45 ---
Confirmed, PR 25669 and bug 18003 are very closely related (it might turn out
this is a dup of one of them).
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from amodra at bigpond dot net dot au 2006-03-23 22:37
---
fixed
--
amodra at bigpond dot net dot au changed:
What|Removed |Added
Status|ASSIG
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-03-23 22:37 ---
(In reply to comment #4)
> If you are referring to 26781 as opposed to the present 26833; yes, the first
> was from linuxkernel-2.6.16 and the present is from yasm-0.4.0.
Actually it was in reference to PR 26806 whi
--- Comment #4 from malitzke at metronets dot com 2006-03-23 22:35 ---
If you are referring to 26781 as opposed to the present 26833; yes, the first
was from linuxkernel-2.6.16 and the present is from yasm-0.4.0.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26833
--- Comment #19 from ebotcazou at gcc dot gnu dot org 2006-03-23 22:33
---
> How can the addressability of Succ make a difference for the testcase?
How do we determine that the SMT of the structure type and the SFT alias?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25737
endif
if(n2==2097152)RETURN
STOP
end subroutine testf
$ elm3b11:/home/pawar> /opt/gcc-nightly/trunk-20060323/bin/gfortran -c -o
test.o -ftree-loop-linear -O2 -m32test.f90
gfortran: Internal error: Segmentation fault (program f951)
Please submit a full bug rep
--- Comment #18 from rguenth at gcc dot gnu dot org 2006-03-23 22:28
---
I don't get it either. Comment #14 makes us not create an SFT for the
structure element, which of course works around the existing problem as
-fno-tree-salias does. How can the addressability of Succ make a diffe
--- Comment #6 from amodra at gcc dot gnu dot org 2006-03-23 22:24 ---
Subject: Bug 26607
Author: amodra
Date: Thu Mar 23 22:23:58 2006
New Revision: 112335
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112335
Log:
PR target/26607
* config/rs6000/darwin-ldouble.
--- Comment #5 from amodra at gcc dot gnu dot org 2006-03-23 22:23 ---
Subject: Bug 26607
Author: amodra
Date: Thu Mar 23 22:23:24 2006
New Revision: 112334
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112334
Log:
PR target/26607
* config/rs6000/darwin-ldouble.
--- 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. :-)
--
http://g
--- 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_info>0 && !found; num_info--)
{
int mismatch = 0;
for(i = 0
--- 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 vop
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 gfcbug34
--- 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
--- 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
---
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- 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=11108&action=view)
complete case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26833
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: malitzk
--- 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
CC
--- 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 #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
Up
--- 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 #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=11107&action=view)
Stripped down LAPACK subroutine
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26832
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
--- 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
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
FUNCTION
--- 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
--- 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 #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 #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=gcc&view=rev&rev=112329
Log:
Radar 4484060
PR c++/24302
* toplev.c (ch
--- 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 #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 #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.
--
http://gcc.gnu.org/bugz
--- 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 #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 (revi
--- 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.
--
http://gcc.gnu.org/bu
--- 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 :-(
No
--- 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 nu
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 tracebac
--- 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
--- 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 -Wmissing-prot
--- 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 #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
---
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 PROTECTED]:/usr/obj/usr/src/sys/IB
--- 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
--- 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 #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}" \
mandir=
-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 #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 -
--- 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|Remov
xed 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-
--- 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=11106&action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26830
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:
(...)
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
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;
}
bug.c.t97.fi
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfi
--- 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
--
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 #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=gcc&view=rev&rev=112322
Log:
PR target/26347
* config/alpha/predicates.md (local_s
--- 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=gcc&view=rev&rev=112321
Log:
PR target/26347
* config/alpha/predicates.md (local_s
--- 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=gcc&view=rev&rev=112320
Log:
PR target/26347
* config/alpha/predicates.md (local_s
--- 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=11105&action=view)
All those GTK/Ada and GPS sources.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26827
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=pos
--- 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
---
--- 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 #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
Statu
--- 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 un
--- 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 dot
--- 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
Status|ASSIGNE
--- 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
#include
void f(int x) {
long y;
if (x < 0) {
y = -x;
if (y > 0) {
printf("%d\n",y)
--- 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=gcc&view=rev&rev=112319
Log:
2006-03-23 Andrew Pinski <[EMAIL PROTECTED]>
PR tr
--- 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 #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 #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 loo
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 #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
--
--- 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)
1 - 100 of 132 matches
Mail list logo
