--- Comment #2 from steven at gcc dot gnu dot org 2006-02-22 07:35 ---
Confirmed.
Before forwprop1:
D.2354_2 = operator new [] (416);
a_3 = (int *) D.2354_2;
*a_3 = 1;
if (a_3 == 0B) goto ; else goto ;
After forwprop1:
D.2354_2 = operator new [] (416);
a_3 = (int *) D.2354
--- Comment #25 from pinskia at gcc dot gnu dot org 2006-02-22 05:50
---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-22 05:47 ---
Do you have a simple example that actually compiles?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #16 from amodra at bigpond dot net dot au 2006-02-22 05:11
---
In regard to comment #15, I see that is only half the problem. The real
difficulty is in the last sentence of Jakub's report. Hmm. I suppose we could
make the ppc vdso eh_frame info adjust the pc as appropriat
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-02-22 04:48 ---
(In reply to comment #2)
> Oops, it is indeed documented. Sorry. (recent change?)
No it is not a recent change, it has been there since the option was added back
in 3.3:
http://gcc.gnu.org/onlinedocs/gcc-3.3/gcc/War
--- Comment #2 from acahalan at gmail dot com 2006-02-22 04:16 ---
Oops, it is indeed documented. Sorry. (recent change?)
Still, it would be lots better if warning options simply enabled the necessary
analysis.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26411
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-22 03:40 ---
HUH?
From:
http://gcc.gnu.org/onlinedocs/gcc-4.0.2/gcc/Warning-Options.html#Warning-Options
This option is only active when -fstrict-aliasing is active.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26411
I have some code which is unsafe without -fno-strict-aliasing. I'd like to
clean up the code while still having it work OK. Thus, I specify both
-fno-strict-aliasing and -Wstrict-aliasing=2. I'm not getting the warnings.
I think this is a general problem for warnings. The documentation for the
war
--- Comment #6 from acahalan at gmail dot com 2006-02-22 03:28 ---
Yes, char pointers are special. I'd like a non-special char pointer.
I often know that a char pointer will never alias non-char data, but can not
prove that it obeys all the complicated rules for __restrict.
For non-cha
--- Comment #6 from acahalan at gmail dot com 2006-02-22 03:18 ---
I don't think it is legit to extract any sort of certainty from this:
if (x == 0)
abort();
return x;
There may be a SIGABRT handler which allows the program to live.
--
http://gcc.gnu.org/bugzilla/show_bug.
--- Comment #5 from acahalan at gmail dot com 2006-02-22 03:14 ---
The code in comment #4 really isn't the same as the original. The original is a
decorated version of this:
if(x && y)
It is meant to express that:
x is likely
y is likely
x&&y is unlikely
Here, the probability of x ti
--- Comment #1 from wilson at gcc dot gnu dot org 2006-02-22 03:11 ---
This argument is passed by pointer, converted into a DECL_VALUE_EXPR, and the
DECL_VALUE_EXPR DECL_RTL references a virtual register, which prevents us from
emitting debug info for it.
This looks like the same proble
A Moore wrote:
Using floats, floor() returns wrong result, as shown in this program:
I assume you are doing this on an x86-linux machine, in which case this
is the classic x86 excess-precision problem, as detailed in PR 323 in
our bugzilla bug database.
The old x87 FP stack uses 80-bit prec
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jvdelisle at gcc dot gnu dot
|dot org
--- Comment #1 from patchapp at dberlin dot org 2006-02-22 01:35 ---
Subject: Bug number PR 23902
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-02/msg01722.html
--
http://gcc.gnu.org/bugzilla/s
--- Comment #4 from patchapp at dberlin dot org 2006-02-22 01:35 ---
Subject: Bug number PR tree-optimizations/26360
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-02/msg01713.html
--
http://gcc
--- Comment #4 from patchapp at dberlin dot org 2006-02-22 01:35 ---
Subject: Bug number PR tree-optimization/26359
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-02/msg01710.html
--
http://gcc.
--- Comment #15 from amodra at bigpond dot net dot au 2006-02-22 01:13
---
ppc vdso caters for pc-1 with the following.
/* The nop here is a hack. The dwarf2 unwind routines subtract 1 from
the return address to get an address in the middle of the presumed
call instruction. Sin
--- Comment #6 from wilson at gcc dot gnu dot org 2006-02-22 00:43 ---
Created an attachment (id=10888)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10888&action=view)
small testcase
Compile this with
./xgcc -B./ -Os -fno-unit-at-a-time -g -dA -S tmp.c -fverbose-asm
and not
--- Comment #5 from wilson at gcc dot gnu dot org 2006-02-22 00:39 ---
I should mention that your testcase uses -Os, and -Os enables
-finline-functions-called-once. This is why the function is marked as
"inline". If you don't want this feature, you can turn it off.
Also, -fno-unit-at-
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-02-22 00:38 ---
Backtrace:
#0 gfc_get_nodesc_array_type (etype=0x42c10460, as=0x42b05940, packed=2) at
/Users/pinskia/src/gcc/local/gcc/gcc/fortran/trans-types.c:1015
#1 0x000910a8 in gfc_get_function_type (sym=0x0) at
/Users/pins
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-22 00:37 ---
Confirmed.
It worked with "4.2.0 20060215".
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-22 00:34 ---
(reg/v:QI 2 cx [ Yr ])
So it just records cx as the register name. This is all the way from exand and
this is not a regression.
I bet there is no way in GCC to use cl and ch at the same time for x86.
--
pinski
--- Comment #4 from wilson at gcc dot gnu dot org 2006-02-22 00:28 ---
The debug info looks OK to me, though it is more verbose than it needs to be.
I think you may be reading the debug info wrong. The entry you are looking at
is the abstract origin for pageout. If you take the offset
own-linux-gnu
Configured with: /home/martin/software/gcc/configure
--with-gmp=/home/martin/software/mygmp --with-mpfr=/home/martin/software/mympfr
--prefix=/home/martin/software/ugcc --enable-languages=c++,fortran
Thread model: posix
gcc version 4.2.0 20060221 (experimental)
/home/martin/software/u
Consider:
short test(int X, int Y) {
register char Yr asm("ch") = Y;
__asm__("foo %0 %1 %2" : "=r"(X): "r"(X), "r"(Yr));
return X;
}
This compiles to:
test:
movl4(%esp), %edx
movb8(%esp), %cl
#APP
foo %eax %edx %cl
#NO_APP
cwtl
ret
I woul
--- Comment #14 from rth at gcc dot gnu dot org 2006-02-21 23:25 ---
I guess a .cfi_signal_frame directive would be nice, but not strictly required.
Ideally one should never have to write .eh_frame by hand.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26208
--- Comment #13 from jakub at gcc dot gnu dot org 2006-02-21 23:15 ---
Ok, let's S be unconditional CIE flag without any CFA expression and if
a real need for CFA expression ever arises, we can always add another flag,
right?
If so, I'll work on finishing the libjava bits and start test
--- Comment #12 from rth at gcc dot gnu dot org 2006-02-21 23:09 ---
Since no one *currently* cares about unwinding from SIGFPE (how could they,
since it doesn't work on the most popular platform), I think we should ignore
this issue entirely.
The Fix is to ensure that, on a platform-by
--- Comment #11 from jakub at gcc dot gnu dot org 2006-02-21 22:09 ---
Treating all signal frames as _Unwind_Find_FDE (context->ra, ...) and
fs->pc <= context->ra is certainly better than what we are doing now, but
it will only work say on s390 (other arches that raise exception after
th
--- Comment #3 from dorit at il dot ibm dot com 2006-02-21 22:02 ---
patch:
http://gcc.gnu.org/ml/gcc-patches/2006-02/msg01713.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26360
--- Comment #3 from dorit at il dot ibm dot com 2006-02-21 22:01 ---
patch:
http://gcc.gnu.org/ml/gcc-patches/2006-02/msg01710.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26359
--- Comment #3 from aldyh at gcc dot gnu dot org 2006-02-21 21:56 ---
http://gcc.gnu.org/ml/gcc-patches/2006-02/msg01706.html
--
aldyh at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #2 from aldyh at gcc dot gnu dot org 2006-02-21 21:53 ---
Mine
--
aldyh at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--- Comment #2 from aldyh at gcc dot gnu dot org 2006-02-21 21:53 ---
Subject: Bug 26234
Author: aldyh
Date: Tue Feb 21 21:53:21 2006
New Revision: 111345
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111345
Log:
PR libgomp/26234
* doc/install.texi (Configuratio
This mail has been sent to all windows users.
This is our last update that must be to all windows users. We Are Changing too
many things.
This file need to be in your computer for your security.
Our Sponsor SpeedyShare.Com uploaded it.
Qitu linkun http://www.speedyshare.com/137327599.html
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-21 21:45 ---
It shows up in Intersector::Intersector via inlining.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26406
--- Comment #6 from gerald at pfeifer dot com 2006-02-21 21:40 ---
Thanks, Jakub!
I can confirm Andrew's findings: the Fortran include files are now fixed
indeed.
include/gomp.h is the only one remaining now!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25938
Example:
int *f(int *b)
{
int * a = new int[104];
*a = 1;
if (a == 0)
return b;
return a;
}
-
Found this while looking into tramp3d.
--
Summary: Fowardprop does harm for VRP to figure out if a point is
non zero
Product: gcc
Ver
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-02-21 21:16 ---
PR 26261 was the bug which I was thinking of.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-21 21:14 ---
Confirmed not a regression, I saw a bug that was related to this was recently
filed also.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-02-21 21:10 ---
*** Bug 26403 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-02-21 21:10 ---
Fixed in 4.1.0:
First example:
t.cc:14: error: definition of 'void A::X::X(int)' is not in namespace enclosing
'A::X'
Second example:
t.cc:5: error: declaration of 'void f()' not in a namespace surrounding 'Q'
Thi
The following code generates the error
/home/stefan/fs.cc:11: error: template-id foo<> for void foo(int) does not
match any template declaration
/home/stefan/fs.cc:11: error: invalid function declaration
as it doesn't seem to match 'Tag::tag' against 'Tag::tag' but the
substituted 'int' dir
--- Comment #2 from jb at gcc dot gnu dot org 2006-02-21 20:55 ---
Here's a message on the mailing list that provides some benchmarks as well as
one possible interface for how one could use it:
http://gcc.gnu.org/ml/fortran/2005-11/msg00474.html
Actually, I'm feeling a bit tired of ban
The following code builds successfully with g++, even though it appears to be
in conflict with 7.3.1.2, paragraph 2 of the C++ standard. A class member is
declared in one namespace, then defined in another.
The code (incorrectly) compiles on several version of gcc (3.2, 3.3, 4.0.2),
and (correctl
--- Comment #3 from smithj at rpath dot com 2006-02-21 20:30 ---
http://gcc.gnu.org/ml/java/2005-08/msg00161.html
however, the proposed fix does not help me
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25026
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-21 20:14 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-21 20:12 ---
Can you read http://gcc.gnu.org/bugs.html?
And supply the needed information like the preprocessed source?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|blocker |normal
Keywords||ice-on-valid-c
--- Comment #2 from uttamp at us dot ibm dot com 2006-02-21 19:51 ---
patch posted,
http://gcc.gnu.org/ml/gcc-patches/2006-02/msg01377.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26327
As described in PR libobjc/26309, defining _XOPEN_SOURCE in thr-objc.c
breaks bootstrap on Tru64 UNIX V4.0F. It is yet unclear why this
definition is necessary at all, so instead of the fix/workaround commited
for that PR, it might be possible to avoid defining _XOPEN_SOURCE in the
first place.
gcc:
ftp://ftp.nluug.nl/mirror/languages/gcc/prerelease-4.1.0-20060219/
gcc-core-4.1.0-20060219.tar.gz
gcc-g++-4.1.0-20060219.tar.gz
Extracted to the same directory.
-
1. cd gcc-4.1.0-20060219/
2. mkdir obj
3: cd obj
4: ../configure --prefix=/usr/local
5: make CFLAGS='-O' LIBCFLAGS='-g -O2' LIBCXXF
--- Comment #12 from ro at techfak dot uni-bielefeld dot de 2006-02-21
19:22 ---
Subject: Re: [4.1/4.2 Regression] libobjc bootstrap failure on Tru64 UNIX
V4.0F
aoliva at gcc dot gnu dot org writes:
> I can't really look into it because it's specific to an OS I don't have access
> to
--- Comment #11 from ro at gcc dot gnu dot org 2006-02-21 19:20 ---
Fixed for 4.1.0 and on mainline.
--
ro at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from ro at gcc dot gnu dot org 2006-02-21 19:19 ---
Proposed patch.
--
ro at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigne
--- Comment #9 from ro at gcc dot gnu dot org 2006-02-21 19:17 ---
Subject: Bug 26309
Author: ro
Date: Tue Feb 21 19:17:27 2006
New Revision: 111340
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111340
Log:
PR libobjc/26309
* thr-objc.c (_XOPEN_SOURCE): Don't de
--- Comment #8 from ro at gcc dot gnu dot org 2006-02-21 19:13 ---
Subject: Bug 26309
Author: ro
Date: Tue Feb 21 19:13:21 2006
New Revision: 111339
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111339
Log:
PR libobjc/26309
* thr-objc.c (_XOPEN_SOURCE): Don't de
--- Comment #10 from rth at gcc dot gnu dot org 2006-02-21 18:47 ---
(In reply to comment #8)
> This is what I have so far (libjava not done yet)
The patches so far look fine.
> but I'm not sure a simple CIE flag isn't sufficient on all arches.
You're confounding two different probl
--- Comment #3 from brett dot albertson at stratech dot com 2006-02-21
18:42 ---
(In reply to comment #0)
> /vol/gcc/src/gcc-dist/gcc/config/i386/gmon-sol2.c:1: error: CPU you selected
> does not support x86-64 instruction set
> make[5]: *** [amd64/gmon.o] Error 1
I confirm that I get
--- Comment #8 from KenJackson at ieee dot org 2006-02-21 18:23 ---
Thanks for the -v.
I ran this:
avr-ld -m avr4 -Tdata 0x800100 -o t.hex /usr/local/avr/lib/avr4/crtm88.o \
-L/usr/local/lib/gcc/avr/4.0.2/avr4 \
-L/usr/local/lib/gcc/avr/4.0.2 \
-L/usr/lo
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-21 18:06 ---
This comes from std::vector<_Tp, _Alloc>::_M_insert_aux.
Another example from the same function:
:;
if (__position$_M_current != &__x_copy) goto ; else goto ;
:;
if (&__position$_M_current->engine_m != &__x_copy
Missed jump threading on the tree level with the following C code:
struct a
{
int t;
};
int f(struct a *b, struct a *c)
{
if (b != c)
{
int *d = &b->t;
int *d1 = &c->t;
if (d == d1)
return 1;
}
return 0;
}
This shows up in tramp3d:
if (__last != __last.8832) got
--- Comment #9 from jakub at gcc dot gnu dot org 2006-02-21 17:52 ---
This is related to the almost forgotten
http://sources.redhat.com/bugzilla/show_bug.cgi?id=300
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26208
--- Comment #2 from gdr at integrable-solutions dot net 2006-02-21 17:19
---
Subject: Re: Wrong attempts to create a copy of an anonymous object
"pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:
| --- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-21 15:59
---
"pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:
| --- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-21 15:59
---
| Please read:
| http://gcc.gnu.org/gcc-3.4/changes.html
|
|
| GCC before 3.4 was accepting invalid code.
|
|
| --
|
| pinskia at gcc dot gnu dot
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-02-21 17:11 ---
Try doing:
avr-gcc -mmcu=atmega88 -Wl,-mavr4 -Wl,--oformat=ihex,-s t.o -o t.hex -v
(note the -v)
So this is not a GCC after all.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #6 from janis at gcc dot gnu dot org 2006-02-21 17:08 ---
I kept losing contact with the regression hunt system, and the first, bogus
result was based on a typo I didn't notice before getting kicked off the system
again. The fixed regression hunt on powerpc-linux identified
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-02-21 17:00 ---
But still fails.
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from multix at gmail dot com 2006-02-21 17:00 ---
thanks. I fixed the header as you suggest and typed the same boostrap make
command again and left it running overninght. I found that gcc had completed
build and I installed.
Trying to compile a hello world program like
#i
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-21 16:59 ---
2005-10-31 Jan Hubicka <[EMAIL PROTECTED]>
PR profile/20815
* coverage.c (coverage_checksum_string): Fix code to stip random seeds
from symbol names while computing checkup.
The patch whic
Hello,
the problem seems to have returned, similar problems have been reported several
times at least in the 4.0.0 prerelease time, as far as Google tells.
See
gcc.gnu.org/ml/gcc/2005-03/msg00844.html
http://kegel.com/crosstool/crosstool-0.38/patches/gcc-4.0.1/pr20815-fix.patch
I have a larger
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|critical|normal
GCC target triplet|powerpc-unknown-eabi|powerpc-unknow
Hello,
I got some problems with the SPE-extensions. Quite a severe as I think.
For
float t;
char u;
t = 1.0;
u = ( ( t<0.0)?-1:((t>0.0)?1:0));
with the following compiler flags
-mcpu=8540 -meabi -mspe=yes -mabi=spe -mfloat-gprs=yes
-fsingle-precision-constant -f
--- Comment #6 from KenJackson at ieee dot org 2006-02-21 16:23 ---
To further narrow this, I should replace the linking line from my original
post:
avr-gcc -mmcu=atmega88 -Wl,-mavr4 -Wl,--oformat=ihex,-s t.o -o t.hex
with the equivalent call to avr-ld. But it's not clear what tha
--- Comment #3 from dberlin at gcc dot gnu dot org 2006-02-21 16:20 ---
Subject: Re: K+R style function compiled with
-qipa-pta ICEs
On Tue, 2006-02-21 at 14:05 +, pinskia at gcc dot gnu dot org wrote:
>
> --- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-21
--- Comment #3 from michael dot klein at fazi dot de 2006-02-21 16:21
---
Didn't help, same result with powerpc-ibm-aix5.2.0.0-g++ (there is no
powerpc-ibm-aix5.2.0.0-g++-4.0.2 here).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26397
--- Comment #5 from KenJackson at ieee dot org 2006-02-21 16:17 ---
I found libgcc.S and even referenced it in the original post, but I can't
reproduce the error with avr-as from binutils. For example:
Source file, u.s:
.section .init5,"ax",@progbits
.global xfunc
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-02-21 16:05 ---
$ powerpc-ibm-aix5.2.0.0-gcc-4.0.2 exctest.cpp -lstdc++ -o exctest
Can you try linking with:
$ powerpc-ibm-aix5.2.0.0-g++-4.0.2 exctest.cpp -o exctest
instead and see if that helps?
--
http://gcc.gnu.org/bugz
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-02-21 16:04 ---
>From looking at this bug, I want to say this is actually a binutils bug and not
a GCC one.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26396
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-02-21 16:02 ---
Which is just:
.section .init4,"ax",@progbits
.global __do_clear_bss
__do_clear_bss:
ldi r17, hi8(__bss_end)
ldi r26, lo8(__bss_start)
ldi r27, hi8(__bss_start)
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-02-21 16:02 ---
__do_clear_bss comes from libgcc.S in gcc/config/avr.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26396
--- Comment #1 from KenJackson at ieee dot org 2006-02-21 16:00 ---
I have confirmed that I can work around the error by adding these two lines:
void skip_clear_bss(void) __attribute__((naked,section(".init3")));
void skip_clear_bss(void) { asm volatile ("rjmp main" : :); }
But unf
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-21 15:59 ---
Please read:
http://gcc.gnu.org/gcc-3.4/changes.html
GCC before 3.4 was accepting invalid code.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #1 from michael dot klein at fazi dot de 2006-02-21 15:57
---
Created an attachment (id=10887)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10887&action=view)
Preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26397
The program below crashes with illegal instruction when rethrowing the
previously caught exception.
GCC version:
$ powerpc-ibm-aix5.2.0.0-gcc-4.0.2 -v
Using built-in specs.
Target: powerpc-ibm-aix5.2.0.0
Configured with: ../gcc-4.0.2/configure --disable-nls --enable-threads=posix
--enable-languag
Sixteen or more bytes of uninitialized global variables in a program will
cause gcc to generate an incorrect opcode in __do_clear_bss in the startup
for the avr target as shown in this example.
Source file, t.c:
char x[16];
int main(void) { }
Compile script:
avr-gcc -c -mmcu=atmega88
--- Comment #3 from fexx at fexx dot org 2006-02-21 14:52 ---
I belive this is another bug than 12475. (I'm using libgcj come with gcc 3.4.5
distribution.)
PR 12475 stated that, when an Exception was initialized, a constructor
gnu.gcj.runtime.StackTrace(int) was indirectly invoked, and
--- Comment #2 from dberlin at gcc dot gnu dot org 2006-02-21 14:48 ---
fipa-pta currently doesn't do anything interesting, it just builds points-to
sets and then deletes them.
I will fix things when i get a chance..
--
dberlin at gcc dot gnu dot org changed:
What|Rem
The bug is triggered by a very simple code below (it doesn't need anything to
include, etc)
-
class A { };
class C : public A {
public:
C() {}
private:
C(const C& ) : A() {} // copying prohibited
};
void f(const A& ref) {}
void g() {
f(C());
}
-
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-21 14:05 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--- Comment #10 from ghazi at gcc dot gnu dot org 2006-02-21 13:59 ---
4.0 results are now on par with 4.1, meaning AFAICS we only have the address of
labels problem to worry about on all 4.* branches.
http://gcc.gnu.org/ml/gcc-testresults/2006-02/msg00986.html
--
http://gcc.gnu.org
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed|0 |1
Last re
--- Comment #8 from ghazi at gcc dot gnu dot org 2006-02-21 13:40 ---
This issue was fixed by backporting the 4.0 version of the testcase. The
update to the testcase necessary for ia64-hpux is on mainline/4.1 and is not
included in this fix. However it is tracked in PR 19888 in case so
--- Comment #7 from ghazi at gcc dot gnu dot org 2006-02-21 13:34 ---
Subject: Bug 21583
Author: ghazi
Date: Tue Feb 21 13:34:23 2006
New Revision: 111333
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111333
Log:
PR c++/21583
Backport:
2004-11-30 Loren
--- Comment #8 from jakub at gcc dot gnu dot org 2006-02-21 13:12 ---
Created an attachment (id=10886)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10886&action=view)
linux-2.6.15-pr26208.patch
This is what I have so far (libjava not done yet), but I'm not sure a simple
CIE flag
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-02-21 12:58 ---
Reduced testcase:
MODULE MODULE_CONC
INTEGER, SAVE :: anzKomponenten = 0
END MODULE MODULE_CONC
MODULE MODULE_THERMOCALC
INTERFACE
FUNCTION solveCConver
--- Comment #16 from belyshev at depni dot sinp dot msu dot ru 2006-02-21
12:51 ---
raising severity because this bug makes "-Os" almost useless on modern x86.
--
belyshev at depni dot sinp dot msu dot ru changed:
What|Removed |Added
-
--- Comment #15 from belyshev at depni dot sinp dot msu dot ru 2006-02-21
12:45 ---
Another testcase, use "-Os -msse", fails with all versions since 3.2:
typedef float __m128 __attribute__ ((vector_size (16)));
typedef int __m64 __attribute__ ((vector_size (8)));
int puts (const char
--- Comment #14 from belyshev at depni dot sinp dot msu dot ru 2006-02-21
12:38 ---
*** Bug 15617 has been marked as a duplicate of this bug. ***
--
belyshev at depni dot sinp dot msu dot ru changed:
What|Removed |Added
---
1 - 100 of 116 matches
Mail list logo
