Hi gcc-developers,
I was trying to look up some information about the installation of gcc
on http://gcc.gnu.org/install/ and found out the the Building link
(http://gcc.gnu.org/install/build.html) was dead. I checked out
wwwdocs from CVS (as suggested) but I could not find the appropriate
files
Hi,
I wanted to use bb-count, so I expected that -fprofile-arcs and
-fbranch-probabilities would help. I added printf just before
peephole2 optimization and ran the following.
$gcc -O3 -fprofile-arcs test.c -o test
$./test (which produced test.gcno only, but no test.gcda)
$gcc -O3 -fprofile-arcs
Hi.
I was trying to look up some information about the installation of
gcc on http://gcc.gnu.org/install/ and found out the the Building
link (http://gcc.gnu.org/install/build.html) was dead. I checked out
wwwdocs from CVS (as suggested) but I could not find the appropriate
files anywhere...
email directly; instead,
file a bug in Bugzilla, and add me to the CC: list.
Enjoy!
Hi!
My spec cpu2000 run shows 252.eon miscompared with i686-redhat-linux
4.1.0 20060221 (prerelease) compiler. Optimization level is -O2. Spec
reported miscompare of pixels_out.kajiya.
Has anybody seen
On Tue, 21 Feb 2006, Ben Elliston wrote:
Good find, thanks. For install/build.html, for instance:
revision 1.26
date: 2001/05/23 06:02:05; author: gerald; state: dead; lines: +0 -0
Remove all install documentation in HTML format, as this now resides in
gcc/doc/install.texi.
Gerald
On Feb 21, 2006, at 6:09 AM, Grigory Zagorodnev wrote:
Hi!
My spec cpu2000 run shows 252.eon miscompared with i686-redhat-linux
4.1.0 20060221 (prerelease) compiler. Optimization level is -O2. Spec
reported miscompare of pixels_out.kajiya.
Has anybody seen this before?
Yes this is PR 323
Liu Haibin wrote:
Hi,
I wanted to use bb-count, so I expected that -fprofile-arcs and
-fbranch-probabilities would help. I added printf just before
peephole2 optimization and ran the following.
$gcc -O3 -fprofile-arcs test.c -o test
$./test (which produced test.gcno only, but no test.gcda)
Hi!
My spec cpu2000 run shows 252.eon miscompared with i686-redhat-linux
4.1.0 20060221 (prerelease) compiler. Optimization level is -O2. Spec
reported miscompare of pixels_out.kajiya.
Has anybody seen this before?
You should use -ffast-math for eon.
Paolo
Hi,
some people already noticed it seems, so this may be a little too late,
but still. We now have a nightly SPEC tester running which posts the
results to
http://www.suse.de/~gcctest/SPEC/CINT/sb-terbium-head-64/
http://www.suse.de/~gcctest/SPEC/CFP/sb-terbium-head-64/
The machine is a
, and other
similar issues.
If you find problems, please do not send me email directly; instead,
file a bug in Bugzilla, and add me to the CC: list.
Enjoy!
Hi!
My spec cpu2000 run shows 252.eon miscompared with i686-redhat-linux
4.1.0 20060221 (prerelease) compiler. Optimization level
On Mon, 2006-02-20 at 16:49 -0500, Richard Kenner wrote:
Which leaves us with a very fundamental issue. Namely that we can not
use TYPE_MIN_VALUE or TYPE_MAX_VALUE for ranges.
The point is that it *is* supposed to be usable in general. If it can't
be used in a specific case,
this link to
http://gcc.gnu.org/install/build.html
in page
http://gcc.gnu.org/install/
is broken
On Mon, Feb 20, 2006 at 08:54:49PM -0800, [EMAIL PROTECTED] wrote:
I've been testing gcc-4.1 RC1 on x86-linux-gnu with SPEC CPU 2000.
Have you verfied that you can build and run all of the tests without
profile-directed optimizations? Several of these programs require
special options to
On Sun, 2006-02-19 at 20:15 +0100, Eric Botcazou wrote:
Now for the first oddity. If we look at the underlying type
for last we have a type natural___XDLU_0__2147483647. What's
interesting about it is that it has a 32bit type precision, but
the min/max values only specify 31 bits. ie,
On Mon, 2006-02-20 at 22:00 +0100, Richard Guenther wrote:
On 2/20/06, Jeffrey A Law [EMAIL PROTECTED] wrote:
On Sun, 2006-02-19 at 20:43 +0100, Laurent GUERBY wrote:
On Sun, 2006-02-19 at 14:23 -0500, Richard Kenner wrote:
Second, for a given integer type (such as
But if the values in there do not reflect the reality of what values
are valid for the type, then I don't see how they can be generally
useful -- that's my point. We have two fields that are inaccurate,
apparently on purpose, and as a result they are basically unusable.
No,
On Tue, 2006-02-21 at 12:46 -0500, Richard Kenner wrote:
But if the values in there do not reflect the reality of what values
are valid for the type, then I don't see how they can be generally
useful -- that's my point. We have two fields that are inaccurate,
apparently on
On Feb 19, 2006, at 12:13 PM, Andrew Pinski wrote:
On Feb 19, 2006, at 2:39 PM, Andrew Pinski wrote:
Now I run into another problem:
/var/tmp//ccBWaqmT.s:130:Fixup of 1073745640 too large for field
width of 26 bits
We have a 1GB decl here. So the section that this decl goes into
is
On Feb 18, 2006, at 10:09 PM, Andrew Pinski wrote:
anchor.diff.txt
+ if (name[0] == '.' name[1] == ' ')
+return 0;
Urr?
Comment here and then I think it's probably good to go. Need to get a
darwin maintainer to ack it though.
-eric
The latest toplevel bootstrap patches have broken bootstrap on
AIX. Executables are being re-linked when installed in prev-gcc. In
stage2, it relinks with the system gcc, which works, but in stage3 it
relinks with prev-gcc/xgcc which does not exist because the bootstrap is
in the process
Err, no they don't. Clearly an object of the type can hold a value
outside TYPE_MIN_VALUE/TYPE_MAX_VALUE at runtime. That IMHO means
that TYPE_MIN_VALUE/TYPE_MAX_VALUE do not reflect reality.
What does can mean here? If it means is physically capable of, then
TYPE_MIN_VALUE and
On Tue, Feb 21, 2006 at 01:15:47PM -0500, David Edelsohn wrote:
The latest toplevel bootstrap patches have broken bootstrap on
AIX. Executables are being re-linked when installed in prev-gcc. In
stage2, it relinks with the system gcc, which works, but in stage3 it
relinks with
On Tue, 2006-02-21 at 13:31 -0500, Richard Kenner wrote:
Err, no they don't. Clearly an object of the type can hold a value
outside TYPE_MIN_VALUE/TYPE_MAX_VALUE at runtime. That IMHO means
that TYPE_MIN_VALUE/TYPE_MAX_VALUE do not reflect reality.
What does can mean here?
Can a conforming program set the object to a value outside of
TYPE_MIN_VALUE/TYPE_MAX_VALUE.
Let's forget about the obscure unchecked conversion - 'Valid case
because we're going to handle that in whatever way we need to.
So the answer is no.
The relevant build lines, starting with stage2 build of cc1.
ranlib libbackend.a
/tmp/20060221/./prev-gcc/xgcc -B/tmp/20060221/./prev-gcc/ ... -o cc1-dummy
build/genchecksum cc1-dummy cc1-checksum.c
/tmp/20060221/./prev-gcc/xgcc -B/tmp/20060221/./prev-gcc/ ... -o cc1-checksum.o
/tmp/20060221
On Tue, 2006-02-21 at 13:57 -0500, Richard Kenner wrote:
Can a conforming program set the object to a value outside of
TYPE_MIN_VALUE/TYPE_MAX_VALUE.
Let's forget about the obscure unchecked conversion - 'Valid case
because we're going to handle that in whatever way we need to.
OK. So if a program sets an object to a value outside
TYPE_MIN_VALUE/TYPE_MAX_VALUE, then that program is
invalid for the purposes of this discussion?
Correct. Of course, it has to be the *program* that's doing the set
(meaning setting a user-defined variable). If the compiler
Indeed. Ada should in this case generate
R = (T)( (basetype)100 + (basetype)X - (basetype)X )
It does!
i.e. carry out all arithmetic explicitly in the basetype and only for stores
and loads use the subtype.
I'd tend to agree, furthermore, if a pass starts wiping out those
type
Jeffrey A Law wrote:
On Tue, 2006-02-21 at 13:57 -0500, Richard Kenner wrote:
Can a conforming program set the object to a value outside of
TYPE_MIN_VALUE/TYPE_MAX_VALUE.
Let's forget about the obscure unchecked conversion - 'Valid case
because we're going to handle that in whatever
On Tue, Feb 21, 2006 at 02:16:27PM -0500, Daniel Jacobowitz wrote:
On Tue, Feb 21, 2006 at 01:50:47PM -0500, David Edelsohn wrote:
if [ -d ../prev-gcc ]; then \
cd ../prev-gcc \
make install-headers-tar DESTDIR=`pwd`/../gcc/ \
libsubdir=. ; \
else \
That's the problem.
On Tue, 2006-02-21 at 14:14 -0500, Richard Kenner wrote:
OK. So if a program sets an object to a value outside
TYPE_MIN_VALUE/TYPE_MAX_VALUE, then that program is
invalid for the purposes of this discussion?
Correct. Of course, it has to be the *program* that's doing the
Jeffrey A Law wrote:
So, if we have an object with the range based on its type of
[0, 0x7fff] and we add 1 to that object, the resulting range
should be [1, 0x7fff]. ie, 0x8000 is not a valid value
for the type. Right?
The actual rule in Ada works like this:
type X is
On 20 Feb, Andrew Haley wrote:
Andrew Pinski writes:
In libjava/classpath there are two .cvsignore files which haven't been
deleted yet:
native/jni/midi-alsa/.cvsignore
native/jni/midi-dssi/.cvsignore
Should they go, too?
They are also in GCC 4.1.0 RC1.
Rainer Emrich wrote:
/SCRATCH/gcc-build/Linux/ia64-unknown-linux-gnu/install/bin/ld: unrecognized
option '-Wl,-rpath'
This looks like PR 21206. See my explanation at the end. I see this on
some of our FreeBSD machines, but I've never seen it on an IA-64 linux
machine.
--
Jim Wilson, GNU
On Tue, 2006-02-21 at 14:34 -0500, Robert Dewar wrote:
Jeffrey A Law wrote:
So, if we have an object with the range based on its type of
[0, 0x7fff] and we add 1 to that object, the resulting range
should be [1, 0x7fff]. ie, 0x8000 is not a valid value
for the type.
[EMAIL PROTECTED] wrote:
I need some kind of assistance. I am trying to substitute function name during
the compilation procedure.
The only way to tell what is wrong is to debug the patch. And since it
is your patch, you are the one that should be trying to debug it.
Try setting
In this specific case it is a user variable. However, we should
probably clarify the compiler-temporary case as well as VRP really
does not and should not care if an object is a user variable or
a compiler generated temporary.
Right. The only distinction is that if it's a
So in the case above, the set of permissible values is
[1, 0x7fff] after the addition, right?
Well, not quite. The addition isn't done in type X, but in type X'Base,
which does not have the restricted TYPE_{MIN,MAX}_VALUES. But, as we've all
said, there are conversions in there
Umm, why bring up the basetype nonsense at all. The arithemtic
is done in whatever type is associated with the expression, not
the base type. Nothing else makes sense. ie, conversions are
explicit.
The conversions are explicit, but are to the base type, which is also
the
Consider this C++ example (I've annotated each class decl with the
unit size of each structure):
struct A { virtual ~A(); }; // 4
struct B { virtual ~B(); }; // 4
struct X : virtual public A,
virtual public B { // 8
};
struct Y : virtual public B { // 4
virtual
On Feb 21, 2006, at 4:44 PM, Chris Lattner wrote:
Is this the intended layout of this structure? What does it mean when
a field runs off the end of the structure? In this case, should I
just ignore the type size and assume that the 8 bytes are dynamically
there?
I wonder if this is the
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
On Tue, 2006-02-21 at 16:24 -0500, Richard Kenner wrote:
So, back to my example. If I have an object with a range [0,
0x7ff f] based on the type of the object and I add one to that
object, then I can safely conclude that the result of the addition has
the range [1,
Given an expression, we have to do computations in some other type than
the type of the expression? Now that's just silly.
Sure, but that's not what I said.
If the expression has some type X, then we should be doing our
computations in type X.
Right.
Let me try again
On Tue, 2006-02-21 at 15:02 -0700, Jeffrey A Law wrote:
?!? WTF
Given an expression, we have to do computations in some other type than
the type of the expression? Now that's just silly. If the expression
has some type X, then we should be doing our computations in type X.
That would
Snapshot gcc-3.4-20060221 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/3.4-20060221/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 3.4 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
Hello all,
I recently recognized that we run the libffi testsuite without any gcc
flags like -Ox or so. This had the effect that a test case was failing
since it fell in the area of PR 323. return_fl2.c was compiled with -O0.
Now my question, would it make sense to run the testsuite with
Jeffrey A Law wrote:
My feeling? Absolutely, TYPE_MIN_VALUE and TYPE_MAX_VALUE should
represent the set of values that an object of the type may hold.
Any other definition effectively renders those values useless.
I agree -- with the obvious caveat that it need not be the case that the
Richard Kenner wrote:
Let me try again and take a simpler example. If we have
subtype T is Integer range 20..50;
Y: T;
... Y + 1 ...
What the tree looks like is a PLUS_EXPR of type Integer (the base type of
T), not T, whose first operand is a NOP_EXPR converting
Laurent GUERBY wrote:
You keep saying brain damage, but please if you see a better design
(other than forget about user range types :), let us all know!
Actually I think everyone agrees on what is appropriate here. it is
a matter of working out a clear view. I don't think there are any
real
All,
I have a template class:
template class Datum, unsigned long Dim
class DataGrid
{
...
public:
...
std::ostream write( std::ostream output ) const;
...
};
I have a non-member operator overload:
On GCC-3.4 Cygwin I needed:
template class Datum, unsigned long Dim
inline
Hi,
Thanks for giving directions. I've read the codes about this and got
some conception. But I possibly made a mistake, I think. For the
linker, ppc64elf.em and elf64-ppc.c have the solution. For the gcc,
rs6000.c also has the solution. There is a mail, [tree-ssa] -longcall
branch islands for
Daniel Jacobowitz writes:
Daniel Want to try this?
Much better with the patch. Hopefully it can be committed to
mainline soon.
Thanks, David
Are they the same thing? If gcc just emits the instruction 'jbsr',
then the assembler must be modified to handle this instruction. Then I
need modify all the stuff, gcc, as, ld, bfd. I understand aright?
Close enough. I really suggest that you do what everyone else has
suggested
and modify
I am in need of the following version of Bison tool's installation
package available with CYGWIN.
Version - 1.875b
Please help me in letting me know the site address / link from which I
can get that package.
Thank you.
With Regards,
Amarnath M
Looking at the regor.c code I came across the function
try_merge_delay_insns().
There around the line 1488 we will find the following code:
merged_insns = gen_rtx_INSN_LIST (SImode, dtrial,
merged_insns);
Please note that in
Marcin Dalecki [EMAIL PROTECTED] writes:
Looking at the regor.c code I came across the function
try_merge_delay_insns().
There around the line 1488 we will find the following code:
merged_insns = gen_rtx_INSN_LIST (SImode, dtrial,
On Feb 21, 2006, at 7:40 PM, Amarnath wrote:
I am in need of the following version of Bison tool's installation
package available with CYGWIN.
We are not cygwin. You can go over to the cygwin site and install it
and it will let you grab and install this. Try google, if you can't
find the
On 2006-02-22, at 05:41, Ian Lance Taylor wrote:
Marcin Dalecki [EMAIL PROTECTED] writes:
Looking at the regor.c code I came across the function
try_merge_delay_insns().
There around the line 1488 we will find the following code:
merged_insns = gen_rtx_INSN_LIST (SImode,
Marcin Dalecki [EMAIL PROTECTED] writes:
An INSN_LIST which goes into the REG_NOTES field must use a register
note such as REG_DEP_TRUE in the mode field. But merged_insns does
not go into the REG_NOTES field. It is only used within the function
try_merge_delay_insns. Look at the loop
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
David Edelsohn wrote:
make[4]: Entering directory `/tmp/20060221/prev-gcc'
/tmp/20060221/./prev-gcc/xgcc -B/tmp/20060221/./prev-gcc/ ... -o xgcc
collect2: error trying to exec '/tmp/20060221/./prev-gcc/xgcc': execvp: A
file or directory
There's a requirement to not use footnotes in install.texi, apparently.
Also, I did not know about install.texi2html so I added a note on it.
Ok to install?
Paolo
2006-02-22 Paolo Bonzini [EMAIL PROTECTED]
* install.texi: Add notes on install.texi2html.
(Building in
There's a requirement to not use footnotes in install.texi, apparently.
Also, I did not know about install.texi2html so I added a note on it.
Ok to install?
Paolo
2006-02-22 Paolo Bonzini [EMAIL PROTECTED]
* install.texi: Add notes on install.texi2html.
(Building in
--- Comment #3 from jakub at gcc dot gnu dot org 2006-02-21 08:09 ---
Subject: Bug 26379
Author: jakub
Date: Tue Feb 21 08:09:08 2006
New Revision: 111328
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=111328
Log:
PR middle-end/26379
* combine.c
Classpath 0.21-pre contains the following code in
gnu/java/awt/peer/swing/SwingFramePeer.java:
public void setBounds(int x, int y, int w, int h)
{
super.setBounds(x, y, w, h);
if (menuBar != null)
menuBar.setWidth(w);
where the method setBounds(int, int, int, int) does not
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2006-02-21 09:08
---
(In reply to comment #2)
the variable does not have to be a dummy variable either to reproduce this.
subroutine option_stopwatch_s()
character(len=1) :: default_clock
call
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-02-21 09:57 ---
Another way instead of
if(__builtin_expect((__builtin_expect(x,1) __builtin_expect(y,1)), 0))
would be
if(__builtin_expect(!(x y), 1))
I'm sure this does _not_ result in same behavior as __builtin_expect is
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-02-21 10:03 ---
With exception to 'certain' this doesn't really make sense. And the 'certain'
one
should be called __builtin_assert(). But then, VRP or DOM might already
extract information from
if (x == 0)
abort();
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-02-21 10:06 ---
This doesn't really make any sense. Trying to over-educate a compiler usually
leads to worse code. Please rather try to isolate testcases where gcc does not
extract value range information it could extract.
--
--- Comment #6 from rguenth at gcc dot gnu dot org 2006-02-21 10:09 ---
You want to avoid spelling the useless name? Use the preprocessor. Also using
a union will prevent a lot of compiler optimization from happening as you are
making alias analysis harder.
As this is never going to
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-02-21 10:14 ---
So you want
typedef struct {
int bar;
void *foobar
#if !NEEDED_BY_ARCH
__attribute__((readas(0)))
#endif
;
} Foo;
so Foo.foobar is NULL for !NEEDED_BY_ARCH? Why not do the proper thing
and provide
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-02-21 10:17 ---
This needs more explanation. char pointers are special with and without
strict-aliasing.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #16 from thebohemian at gmx dot net 2006-02-21 10:37 ---
Fixed by the following patches:
Main patch:
http://gcc.gnu.org/ml/java-patches/2006-q1/msg00124.html
Build fix for ARM:
http://gcc.gnu.org/ml/java-patches/2006-q1/msg00143.html
Stylistic: remove casts
--- Comment #9 from rguenth at gcc dot gnu dot org 2006-02-21 11:11 ---
Worst offenders are (--disable-checking mainline)
cfg cleanup : 2.30 ( 3%) usr 0.00 ( 0%) sys 2.36 ( 3%) wall
1474 kB ( 0%) ggc
integration : 5.99 ( 7%) usr 0.29 (11%) sys 6.28
--- Comment #6 from jakub at gcc dot gnu dot org 2006-02-21 12:02 ---
Created an attachment (id=10884)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10884action=view)
gcc-trunk-pr26208.patch
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26208
--- Comment #7 from jakub at gcc dot gnu dot org 2006-02-21 12:02 ---
Created an attachment (id=10885)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10885action=view)
binutils-trunk-pr26208.patch
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26208
) THEN
CALL toolStop
ENDIF
!
END SUBROUTINE CTN_Write_String
!
END SUBROUTINE outDiffKoeff
!
PPPS: I'm using 4.2.0 20060221 (experimental)
--
Summary: CONTAIN-ed + assumed character length + WRITE - ICE
at trans-decl.c:849?
Product: gcc
--- Comment #1 from P dot Schaffnit at access dot rwth-aachen dot de
2006-02-21 12:24 ---
Oops!
I forgot to mention that the whole thing occurs under Linux (see hereafter).
Philippe
PS: uname -a:
Linux pinguin7 2.6.5-7.104-bigsmp #1 SMP Wed Jul 28 16:42:13 UTC 2004 i686 i686
i386
--- Comment #12 from belyshev at depni dot sinp dot msu dot ru 2006-02-21
12:38 ---
(In reply to comment #11)
duplicate of #13685 ?
yes.
*** This bug has been marked as a duplicate of 13685 ***
--
belyshev at depni dot sinp dot msu dot ru changed:
What
--- 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
--- 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 #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 #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
--- 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=10886action=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 #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=gccview=revrev=111333
Log:
PR c++/21583
Backport:
2004-11-30 Loren
--- 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
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed|0 |1
Last
--- 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
--
--- 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|
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 #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
--- 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,
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
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
--- 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=10887action=view)
Preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26397
--- 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 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
--- 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 #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
1 - 100 of 178 matches
Mail list logo
