--- Comment #3 from ebotcazou at gcc dot gnu dot org 2006-05-17 06:31
---
I cannot reproduce on the SPARC/Solaris 9 machine I use. Please provide as
many details as you can on the OS, the linker, the assembler, GCC, GDB and so
on.
--
ebotcazou at gcc dot gnu dot org changed:
This testcase generates some kind of initalization of uninitialized part of the
structure:
--cut here--
struct ret_struct
{
int long_buf[10];
};
struct ret_struct
strc_test (int i)
{
struct ret_struct ret;
ret.long_buf[0] = i;
ret.long_buf[1] = 0x2;
ret.long_buf[2] = 0x3;
--- Comment #9 from jakub at gcc dot gnu dot org 2006-05-17 08:24 ---
Subject: Bug 27549
Author: jakub
Date: Wed May 17 08:23:55 2006
New Revision: 113843
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113843
Log:
PR tree-optimization/27549
Backported from
--- Comment #11 from jakub at gcc dot gnu dot org 2006-05-17 08:24 ---
Subject: Bug 27283
Author: jakub
Date: Wed May 17 08:23:55 2006
New Revision: 113843
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113843
Log:
PR tree-optimization/27549
Backported from
--- Comment #7 from jakub at gcc dot gnu dot org 2006-05-17 08:28 ---
Subject: Bug 27548
Author: jakub
Date: Wed May 17 08:27:57 2006
New Revision: 113844
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113844
Log:
2006-05-17 Zdenek Dvorak [EMAIL PROTECTED]
PR
--- Comment #10 from jakub at gcc dot gnu dot org 2006-05-17 08:32 ---
Subject: Bug 27549
Author: jakub
Date: Wed May 17 08:31:51 2006
New Revision: 113845
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113845
Log:
PR tree-optimization/27549
*
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-05-17 08:35 ---
SRA decomposes structure assignment retval = ret
strc_test (i)
{
struct ret_struct ret;
bb 2:
ret.long_buf[0] = i_1;
ret.long_buf[1] = 2;
ret.long_buf[2] = 3;
ret.long_buf[3] = 4;
ret.long_buf[4] = 5;
--- Comment #1 from jakub at gcc dot gnu dot org 2006-05-17 08:35 ---
Subject: Bug 27415
Author: jakub
Date: Wed May 17 08:35:01 2006
New Revision: 113846
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113846
Log:
PR middle-end/27415
* tree.h
--- Comment #4 from jakub at gcc dot gnu dot org 2006-05-17 08:43 ---
Subject: Bug 27491
Author: jakub
Date: Wed May 17 08:42:47 2006
New Revision: 113847
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113847
Log:
PR c++/27491
* semantics.c
--- Comment #5 from jakub at gcc dot gnu dot org 2006-05-17 08:44 ---
Subject: Bug 27491
Author: jakub
Date: Wed May 17 08:44:36 2006
New Revision: 113848
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113848
Log:
PR c++/27491
* semantics.c
--- Comment #6 from jakub at gcc dot gnu dot org 2006-05-17 08:45 ---
Fixed in SVN.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from jakub at gcc dot gnu dot org 2006-05-17 08:46 ---
Fixed in SVN.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #19 from jserv at kaffe dot org 2006-05-17 08:48 ---
I encountered the same problem with gcc-3.4.6 for ARM targets. Even I applied
18081.patch, the situation of infinite memory allocation still exists. Since
gcc-3.4 is closed, I wonder if there is a fix against gcc-3.4.6.
--- Comment #2 from jakub at gcc dot gnu dot org 2006-05-17 08:53 ---
Fixed in SVN.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from soete dot joel at tiscali dot be 2006-05-17 08:56
---
Created an attachment (id=11481)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11481action=view)
just another similar test case regarding double equivalent pb
compile with -O2 the Nan3.s is:
.LEVEL 1.1
--- Comment #3 from bernds at gcc dot gnu dot org 2006-05-17 09:42 ---
Subject: Bug 27620
Author: bernds
Date: Wed May 17 09:42:23 2006
New Revision: 113850
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113850
Log:
PR middle-end/27620
* expr.c (safe_from_p):
--- Comment #15 from dave dot korn at artimi dot com 2006-05-17 10:03
---
I'm new maintainer for Cygwin gcc. I'll be rolling a release with the patch
Paolo proposed rather than using the configure option, although if binary
compatibility problems do crop up I'll look at the second
--- Comment #16 from pcarlini at suse dot de 2006-05-17 10:09 ---
Ok. Hopefully, before the end of this week I can tell you something trustworthy
about binary compatibility.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24196
--- Comment #8 from rakdver at gcc dot gnu dot org 2006-05-17 11:33 ---
Subject: Bug 27548
Author: rakdver
Date: Wed May 17 11:33:00 2006
New Revision: 113853
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113853
Log:
PR tree-optimization/27548
*
// { dg-do run }
// { dg-options -O2 }
char heap[5];
int
main ()
{
for (unsigned ix = sizeof (heap); ix--;)
heap[ix] = ix;
return 0;
}
(distilled from http://gcc.gnu.org/viewcvs?root=gccview=revrev=113851
PR middle-end/27620 testcase) is miscompiled on {x86_64,i?86}-linux at -O2.
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-05-17 11:58 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2006-05-17 12:04
---
Subject: Bug 27553
Author: fxcoudert
Date: Wed May 17 12:04:17 2006
New Revision: 113854
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113854
Log:
PR fortran/27553
* parse.c (next_free):
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2006-05-17 12:06
---
Subject: Bug 27320
Author: fxcoudert
Date: Wed May 17 12:06:42 2006
New Revision: 113855
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113855
Log:
PR fortran/27320
* dump-parse-tree.c
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2006-05-17 12:07
---
Fixed on 4.1 and mainline.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from dberlin at gcc dot gnu dot org 2006-05-17 12:07 ---
Fixed
--
dberlin at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-05-17 12:17 ---
scev_probably_wraps_p returns false because we recorded a max of 49 iteration
from
(gdb) call debug_generic_expr ( loop-bounds-next-at_stmt)
D.1993_10 = (charD.3) ixD.1987_7
using infer_loop_bounds_from_undefined
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-05-17 12:24 ---
Not infering loop bounds from type conversions fixes it.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
I get the following segfault with gcc 4.2.0 20060419. 4.0/4.1 work.
14640:[EMAIL PROTECTED]: ~] /usr/lib/gcc-snapshot/bin/g++ -c mini.c
mini.c: In constructor 'refcountedT, scalar::refcounted(const A1) [with A1 =
refnfsserv, T = nfsserv_ac]':
mini.c:88: instantiated from 'void
--- Comment #1 from tbm at cyrius dot com 2006-05-17 12:32 ---
Created an attachment (id=11483)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11483action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27640
--- Comment #8 from tbm at cyrius dot com 2006-05-17 12:47 ---
(In reply to comment #7)
A regression hunt identified this patch:
http://gcc.gnu.org/viewcvs?view=revrev=112869
r112869 | mmitchel | 2006-04-11 22:59:57 + (Tue, 11 Apr 2006)
Mark, can you comment?
--
--- Comment #4 from spop at gcc dot gnu dot org 2006-05-17 12:47 ---
Subject: Bug 27332
Author: spop
Date: Wed May 17 12:47:43 2006
New Revision: 113856
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113856
Log:
PR middle-end/27332
* tree-loop-linear.c
--- Comment #5 from tbm at cyrius dot com 2006-05-17 12:49 ---
(In reply to comment #4)
Actually the orginal testcase here was not fixed by the patch which is going
to
fix PR 26626 either.
So reopening.
Daniel, since you fixed 26626, do you think you could take a look at this one
--- Comment #4 from rakdver at gcc dot gnu dot org 2006-05-17 13:02 ---
(In reply to comment #2)
scev_probably_wraps_p returns false because we recorded a max of 49 iteration
from
(gdb) call debug_generic_expr ( loop-bounds-next-at_stmt)
D.1993_10 = (charD.3) ixD.1987_7
using
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-05-17 13:05 ---
It's
(set_scalar_evolution
(scalar = D.1993_10)
(scalar_evolution = {79, +, -1}_1))
)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27639
--- Comment #6 from rguenth at gcc dot gnu dot org 2006-05-17 13:05 ---
And we infer
Found new range for D.1993_10: [-INF, 79]
from it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27639
--- Comment #7 from aoliva at gcc dot gnu dot org 2006-05-17 13:08 ---
I suspect http://gcc.gnu.org/viewcvs?root=gccview=revrev=113298 fixes it,
testing now...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27639
--- Comment #8 from rakdver at gcc dot gnu dot org 2006-05-17 13:11 ---
It's
(set_scalar_evolution
(scalar = D.1993_10)
(scalar_evolution = {79, +, -1}_1))
)
Then it is a bug in chrec_convert (might also be related to PR 27619).
--
The following code segfaults if compiled statically using libpthread.a from
Fedora Core 4 (2.6.16-1.2107_FC4) with gcc-4.0.2, but will run ok if
dynamically linked to libpthread.so.0. Here the code:
#include list
#include pthread.h
void* tf (void* tp)
{
pthread_exit (0);
}
int main ()
{
--- Comment #9 from rakdver at gcc dot gnu dot org 2006-05-17 13:12 ---
(In reply to comment #8)
It's
(set_scalar_evolution
(scalar = D.1993_10)
(scalar_evolution = {79, +, -1}_1))
)
Then it is a bug in chrec_convert (might also be related to PR 27619).
sorry, I
--- Comment #10 from aoliva at gcc dot gnu dot org 2006-05-17 13:18 ---
Yep, confirmed, that fixes it. Richard, will you propose your patch for 4.1 as
well, or should I?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27639
--- Comment #11 from rguenther at suse dot de 2006-05-17 13:22 ---
Subject: Re: [4.1/4.2 regression] VRP miscompilation
of simple loop
On Wed, 17 May 2006, aoliva at gcc dot gnu dot org wrote:
--- Comment #10 from aoliva at gcc dot gnu dot org 2006-05-17 13:18
---
--- Comment #12 from rguenth at gcc dot gnu dot org 2006-05-17 13:24
---
Ok, the patch fixes this PR, but not PR26719.
Index: tree-chrec.c
===
--- tree-chrec.c(revision 113852)
+++ tree-chrec.c(working
--- Comment #13 from rguenth at gcc dot gnu dot org 2006-05-17 13:33
---
I cannot reproduce this bug on the 4.1 branch at all.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27639
--- Comment #14 from rakdver at gcc dot gnu dot org 2006-05-17 13:40
---
(In reply to comment #12)
Ok, the patch fixes this PR, but not PR26719.
Index: tree-chrec.c
===
--- tree-chrec.c(revision 113852)
+++
--- Comment #15 from aoliva at gcc dot gnu dot org 2006-05-17 13:41 ---
That's odd. I can't reproduce the bug in mainline, but I could in the 4.1
branch, until I applied your patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27639
--- Comment #16 from rguenth at gcc dot gnu dot org 2006-05-17 13:47
---
(bugzilla doesn't like my mail-replies it seems)
Currently we have a type-mismatch type vs. ct, where ct is the canonical type
for step/base. I guess this was a typo.
--
--- Comment #17 from rakdver at gcc dot gnu dot org 2006-05-17 13:54
---
(In reply to comment #16)
(bugzilla doesn't like my mail-replies it seems)
Currently we have a type-mismatch type vs. ct, where ct is the canonical type
for step/base. I guess this was a typo.
Umm.. right,
--- Comment #3 from bernds at gcc dot gnu dot org 2006-05-17 13:54 ---
Subject: Bug 22541
Author: bernds
Date: Wed May 17 13:54:38 2006
New Revision: 113859
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113859
Log:
PR bootstrap/22541
From Dan Kegel [EMAIL
--- Comment #18 from rguenth at gcc dot gnu dot org 2006-05-17 14:03
---
Hmm, I see. But scev_probably_wraps_p is messed up for non-matching types, and
fixing it the other way around doesn't work. At least I think we should also
bail out if the original chrec wraps. Think of
(int)
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2006-05-17 14:11
---
Subject: Bug 26551
Author: fxcoudert
Date: Wed May 17 14:11:40 2006
New Revision: 113860
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113860
Log:
PR fortran/26551
* resolve.c
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2006-05-17 14:15
---
Subject: Bug 26551
Author: fxcoudert
Date: Wed May 17 14:14:56 2006
New Revision: 113861
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113861
Log:
Testcase forgotten in the previous commit.
--- Comment #19 from rguenth at gcc dot gnu dot org 2006-05-17 14:21
---
if we are checking in scev_probably_wraps_p if the chrec does wrap in the
target
type we should _not_ use signed-types-don't-wrap as we do now:
/* After having set INIT_IS_MAX, we can return false: when not
--- Comment #20 from rguenth at gcc dot gnu dot org 2006-05-17 14:24
---
Still, this all looks like a mess at the moment. Sebastian, can you please
have a look?
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from spop at gcc dot gnu dot org 2006-05-17 14:26 ---
Subject: Bug 26435
Author: spop
Date: Wed May 17 14:25:59 2006
New Revision: 113862
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113862
Log:
PR middle-end/20256
PR middle-end/26435
*
--- Comment #11 from spop at gcc dot gnu dot org 2006-05-17 14:26 ---
Subject: Bug 20256
Author: spop
Date: Wed May 17 14:25:59 2006
New Revision: 113862
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113862
Log:
PR middle-end/20256
PR middle-end/26435
*
--- Comment #21 from rguenther at suse dot de 2006-05-17 15:06 ---
Subject: Re: [4.1/4.2 regression] VRP miscompilation
of simple loop
On Wed, 17 May 2006, rakdver at gcc dot gnu dot org wrote:
--- Comment #14 from rakdver at gcc dot gnu dot org 2006-05-17 13:40
---
--- Comment #22 from rguenther at suse dot de 2006-05-17 15:06 ---
Subject: Re: [4.1/4.2 regression] VRP miscompilation
of simple loop
On Wed, 17 May 2006, rakdver at gcc dot gnu dot org wrote:
--- Comment #8 from rakdver at gcc dot gnu dot org 2006-05-17 13:11
---
--- Comment #23 from rguenth at gcc dot gnu dot org 2006-05-17 15:07
---
The patch in comment #12 bootstrapped and regtested ok on
x86_64-unknown-linux-gnu, which just hints at very poor testsuite coverage of
all this stuff.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27639
--- Comment #7 from bryce at gcc dot gnu dot org 2006-05-17 15:10 ---
Subject: Bug 27352
Author: bryce
Date: Wed May 17 15:09:57 2006
New Revision: 113863
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113863
Log:
PR libgcj/27352
* java/lang/Class.java
--- Comment #4 from sebor at roguewave dot com 2006-05-17 15:12 ---
Here's the verbose output from the compiler driver:
$ gcc -v t.c
Using built-in specs.
Target: sparc-sun-solaris2.9
Configured with: /build/sebor/gcc-4.1.0/configure --enable-languages=c,c++
--- Comment #8 from mckinlay at redhat dot com 2006-05-17 15:18 ---
Fixed
--
mckinlay at redhat dot com changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #9 from jakub at gcc dot gnu dot org 2006-05-17 15:29 ---
Subject: Bug 27548
Author: jakub
Date: Wed May 17 15:29:18 2006
New Revision: 113864
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113864
Log:
PR tree-optimization/27548
*
I updated the source tree this morning and the gfortran build now fails -
rm -rf libbackend.a
ar rc libbackend.a double-int.o tree-chrec.o tree-scalar-evolution.o
tree-data-ref.o tree-cfg.o tree-dfa.o tree-eh.o tree-ssa.o tree-optimize.o
tree-gimple.o gimplify.o tree-pretty-print.o
--- Comment #18 from mmitchel at gcc dot gnu dot org 2006-05-17 15:36
---
It appears that HJ's patches are now checked in. Can we close this PR?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26885
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |mark at codesourcery dot com
|dot org
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-05-17 16:01 ---
Can someone also test 4.1.1?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from bernds at gcc dot gnu dot org 2006-05-17 16:03 ---
Subject: Bug 27620
Author: bernds
Date: Wed May 17 16:03:25 2006
New Revision: 113866
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113866
Log:
PR middle-end/27620
* expr.c (safe_from_p):
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-05-17 16:11
---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
The following test case crashes:
$ gcj -C PipeImpl.java
$ gcj -c *.class -o t.o
PipeImpl.java:0: internal compiler error: in java_mark_cni_decl_local, at
java/decl.c:2182
class PipeImpl
{
public PipeImpl ()
{
VMPipe.init (this);
}
}
final class VMPipe
{
static native void
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-05-17 16:20 ---
This is not a bug, if this shows up in real code, it should be changed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-05-17 16:28 ---
Back trace:
#0 0x001a2758 in expand_virtual_init (binfo=0xd8c0c0, decl=0xd92840) at
../../gcc/cp/init.c:781
#1 0x0019fb7c in dfs_initialize_vtbl_ptrs (binfo=0xd8c0c0, data=0xdb63c0) at
../../gcc/cp/init.c:112
#2
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-05-17 16:45 ---
Both of the testcases here were fixed by the patch for PR 27373.
*** This bug has been marked as a duplicate of 27373 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-05-17 16:45
---
*** Bug 27085 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
version 4.1.1 20060517 (prerelease)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27642
--- Comment #3 from mmitchel at gcc dot gnu dot org 2006-05-17 17:24
---
Subject: Bug 26068
Author: mmitchel
Date: Wed May 17 17:24:00 2006
New Revision: 113869
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113869
Log:
PR c++/26068
* parser.c
--- Comment #4 from mmitchel at gcc dot gnu dot org 2006-05-17 17:27
---
Fixed in 4.2.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
This patch:
2006-05-16 H.J. Lu [EMAIL PROTECTED]
* Makefile.in (GCC_OBJS): Replace options.o with gcc-options.o.
(gcc-options.o): New rule.
* optc-gen.awk: Protect variables for gcc-options.o with
#ifdef GCC_DRIVER/#endif.
is causing bootstrap failures:
gcc
--- Comment #1 from mark at codesourcery dot com 2006-05-17 17:38 ---
Subject: Re: New: [4.1 regression] Bootstrap failure
on native ARM targets
rearnsha at gcc dot gnu dot org wrote:
This patch:
2006-05-16 H.J. Lu [EMAIL PROTECTED]
* Makefile.in (GCC_OBJS): Replace
--- Comment #5 from sebor at roguewave dot com 2006-05-17 17:43 ---
I'm told that the fault is due to a known problem in the Sun libc:
6372620 printstack() segfaults when called from static function
It this doesn't provide sufficient detail to work around the bug in gcc
(assuming you
--- Comment #6 from ebotcazou at gcc dot gnu dot org 2006-05-17 18:10
---
I'm told that the fault is due to a known problem in the Sun libc:
6372620 printstack() segfaults when called from static function
It this doesn't provide sufficient detail to work around the bug in gcc
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-05-17 18:29 ---
Hmm, I think this causes the following invalid code to be accepted (but I am
not sure if this is invalid code or not):
enum in_section { in_toc };
int f(void) { extern int in_toc; }
--
In 3.3 and before we
--- Comment #7 from sebor at roguewave dot com 2006-05-17 18:34 ---
Maybe it's one of the runtime library functions that's static (maybe _start?).
The diff between the two .s files is empty.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27629
My mainline gcc (with svn revision number 113869) doesn't build
with --target=arm-none-eabi.
While building cc1-dummy, I get:
libbackend.a(options.o):(.rodata+0x4474): undefined reference to
`target_fpe_name'
libbackend.a(options.o):(.rodata+0x44b4): undefined reference to
`target_fpe_name'
A
Hi,
My system is a macbook pro (intel duo core) with standard install of OS X. GCC
version 4.01 Build 5250.
I am writing a flex program and ran across a very strange issue. When building
and running the following flex (lex) program, the global variable access does
not work properly. The
--- Comment #2 from pault at gcc dot gnu dot org 2006-05-17 19:03 ---
(In reply to comment #1)
I already mentioned before it should be using VIEW_CONVERT_EXPR instead of an
address and a NOP_EXPR but nobody listened to me in the orginal bug report.
Note this effects both strict
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-05-17 19:06 ---
printf(%d = ret, glo = %d, yylex(), glo);
The C standard does not specify if yylex() or glo is evulated first.
So you are running into that effect and this is code undefined.
See PR 11751 for future reference.
--- Comment #72 from pinskia at gcc dot gnu dot org 2006-05-17 19:06
---
*** Bug 27646 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
I'm not sure if this is the right place to send this bug to. I sent this bug to
Apple on March 2nd, 2006, but the bug is still open in their database as of
today (May 17th).
Here's the description:
I've noticed a different behavior of my application depending on whether I
turned optimization on
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-05-17 19:17 ---
This has already been fixed in 4.0.2.
And this is a dup of bug 23326.
Please don't report to the FSF untill you tried a FSF released compiler and a
newer one at that.
*** This bug has been marked as a duplicate
--- Comment #14 from pinskia at gcc dot gnu dot org 2006-05-17 19:17
---
*** Bug 27647 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Enter the following program:
int main(int argc,char **argv)
{
float x = 0.9;
long y = reinterpret_castlong (static_castfloat
__attribute((may_alias)) x);
return y;
}
and compile with
$ g++-4.0 -O3 -Wall aliastest.cpp
Result is:
aliastest.cpp: In function 'int main(int, char**)':
--- Comment #3 from kazu at gcc dot gnu dot org 2006-05-17 20:31 ---
Reproduced as of svn revision 113870.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27506
--- Comment #4 from mmitchel at gcc dot gnu dot org 2006-05-17 20:33
---
Grumble. In my queue. I should have known better than to try to fix this the
right way. :-)
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-05-17 20:37 ---
This is still a missed optimization.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #24 from mmitchel at gcc dot gnu dot org 2006-05-17 20:38
---
Removing the 4.1 marker, as this is now fixed on the 4.1 branch.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from kazu at gcc dot gnu dot org 2006-05-17 20:39 ---
Assigning to Mark Mitchell as he agreed.
--
kazu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from ebotcazou at gcc dot gnu dot org 2006-05-17 20:40
---
Maybe it's one of the runtime library functions that's static (maybe _start?).
Excerpt from gcc/config/sparc/sol2-c1.asm:
.section.text
.proc 022
.global _start
_start:
--- Comment #5 from kazu at gcc dot gnu dot org 2006-05-17 20:41 ---
Mark Mitchell checked in a patch recently.
--
kazu at gcc dot gnu dot org changed:
What|Removed |Added
On cygwin system, used gcc 3.4.4 to compile gcc 4.1.0. Installed gcc 4.1.0 in
/usr/local.
While compiling Gecode (with make), from gecode-1.1.0.tar.gz, encountered the
following error:
search/reco-stack.cc:85: internal compiler error: in maybe_emit_vtables, at
cp/decl2.c:1548
exact command
1 - 100 of 148 matches
Mail list logo
