Hi all,
I am currently adding floating point support for a private target (for
GCC 4.1.1). i am having some problems with register allocation.
In SF mode, i have specified to the compiler that it can use both
floating point registers as well as data registers. For all move
instructions in SF
Hi Mike,
[I'm replying in this thread to the Objective-C patch you posted in
the type-traits discussion, because both that post and this one are
about reducing the number of tree codes]
On 3/13/07, Mike Stump [EMAIL PROTECTED] wrote:
I just converted the Objective-C front-end to free up enough
[EMAIL PROTECTED] (Mike Stump) writes:
../../gcc/gcc/var-tracking.c: In function âvariable_tracking_mainâ:
../../gcc/gcc/var-tracking.c:2961: warning: assuming signed overflow does not
occur when assuming that (X - c) = X is always true
../../gcc/gcc/var-tracking.c:2961: warning:
On Tue, Mar 13, 2007 at 10:28:41PM -0400, Jack Howarth wrote:
Interestingly, while...
gcc-4 pr30703.C -fmessage-length=0 -fopenmp -O0 -L/sw/lib/gcc4.2/lib -lgomp
-lstdc++ -lm -m32 -o ./pr30703.exe
/usr/bin/ld: Undefined symbols:
__Unwind_Resume
collect2: ld returned 1 exit status
On 3/13/07, Jim Wilson [EMAIL PROTECTED] wrote:
Sunzir Deepur wrote:
My wish is to generate a CFG in which I would know, for each basic block
and RTL command, what is the virtual address this command will be at
in the binary..
You can already find much of this info in the gcov profiling
Hello group,
any idea where I can find a (free) graphical VCG viewer suitable
for gcc's vcg outputs ?
seems like the old 1995 package is not applicable on newest linux systems
(am working on fedora).
Thank You
sunzir
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, Mar 13, 2007 at 11:15:27AM -0700, Brian Dessent wrote:
Kai Tietz wrote:
Ok, I will try for this. I have to find a different editor, which is
not too smart as to remove trailing whitespaces ...
Or just add -w to the diff options when
Hello!
Recent committed patch breaks i386ssefp-2.c testcase, where maxsd is
not generated anymore.
I have looked a bit into this failure and noticed that for some reason
we don't perform ifcvt transformations during ce1 RTL pass. The second
transformation is still performed during ce2 pass, but
On 3/14/07, Doug Gregor [EMAIL PROTECTED] wrote:
Hi Mike,
[I'm replying in this thread to the Objective-C patch you posted in
the type-traits discussion, because both that post and this one are
about reducing the number of tree codes]
On 3/13/07, Mike Stump [EMAIL PROTECTED] wrote:
I just
I'll find a way to fix that.
Revital, please try this. I've tested it but know better than to check
things in at the end of the day; I'll post it tomorrow.
It fixes the problem.
Thanks,
Revital
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
NotDashEscaped: You need GnuPG to verify this message
On Tue, Mar 13, 2007 at 02:22:06PM -0700, Jim Wilson wrote:
Revital1 Eres wrote:
ERROR: tcl error sourcing
/home/eres/mve_mainline_zero_12_3/gcc/gcc/testsuite/g++.dg/compat/compat.exp.
ERROR:
Hello,
I have used -da and -dv to produce vcg files of the CFG of this simple program:
int main(int argc, char**argv)
{
if(argc)
printf(positive\n);
else
printf(zero\n);
return 0;
}
I have expected to get a CFG as follows:
Hi all,
first of all i want to thank you for the aid that i have receveid from
this mailing list. I have another little question:
if i have a statemente that is an expression, for example x+5 , how
can i know if the operation is plus (+), or minus (-), or equal(=) or
less () etc..
Can you give me
Hi,
in some cases, a breakpoint can't be set on a continue or break
statement. Here is a simple example:
void foc (void)
{
int a, i;
for (i = 1; i = 10; i++) {
if (i 3)
a = 1;
else
break; // line 9
a = 5;
}
}
int main(void)
{
foc ();
}
The reason is quiet
Andrea Callia D'Iddio wrote on 14/03/2007 12:36:59:
Hi all,
first of all i want to thank you for the aid that i have receveid from
this mailing list. I have another little question:
if i have a statemente that is an expression, for example x+5 , how
can i know if the operation is plus (+),
Jakub,
So shouldn't we either XFAIL pr30703.C on *-apple-darwin* or
specify that the -shared-libgcc flag should be used on that
target for pr30703.C?
Jack
On Wed, Mar 14, 2007 at 10:11:35AM +0100, Jakub Jelinek wrote:
On Tue, Mar 13, 2007 at 10:28:41PM -0400, Jack Howarth
Hi,
We have a '{2,2}' expression (vector initializer) propagated by dom into a
BIT_FIELD_REF:
before (bug.c.105t.vrp2):
vector long int vect_cst_.47;
vect_cst_.47_66 = {2, 2};
D.2103_79 = BIT_FIELD_REF vect_cst_.47_66, 64, 0;
after (bug.c.106t.dom3):
Optimizing
On 13 March 2007 19:56, Ian Lance Taylor wrote:
Dave Korn [EMAIL PROTECTED] writes:
The intermediate cause is that lreg considers all the special-purpose reg
classes when allocating, and for some reason decides that several of the
special-purpose classes have equal cost (zero) to
On 3/14/07, Dorit Nuzman [EMAIL PROTECTED] wrote:
Hi,
We have a '{2,2}' expression (vector initializer) propagated by dom into a
BIT_FIELD_REF:
before (bug.c.105t.vrp2):
vector long int vect_cst_.47;
vect_cst_.47_66 = {2, 2};
D.2103_79 = BIT_FIELD_REF vect_cst_.47_66, 64,
On 3/14/07, Richard Guenther [EMAIL PROTECTED] wrote:
#define LANG_TYPE_CODE (t) (TREE_CODE (t) == LANG_TYPE ?
LANG_TYPE_SUBCODE (t) : INVALID_SUBCODE)
and then INVALID_SUBCODE will fall through to the default case as well.
But that doesn't put the subcodes and the codes into the same
Tristan Gingold [EMAIL PROTECTED] writes:
in some cases, a breakpoint can't be set on a continue or break
statement. Here is a simple example:
The reason is quiet simple: even at -O0 -g, there is no insn (and no
BB) corresponding to the break/continue statement.
Here is a small patch which
Dorit Nuzman [EMAIL PROTECTED] writes:
D.2103_79 = BIT_FIELD_REF {2, 2}, 64, 0;
...which causes he following ICE:
bug.c:8: error: invalid reference prefix
{2, 2}
bug.c:8: internal compiler error: verify_stmts failed
Maybe fold-const.c needs to recognize this case?
On 14 Mar 2007 07:22:10 -0700, Ian Lance Taylor [EMAIL PROTECTED] wrote:
Dorit Nuzman [EMAIL PROTECTED] writes:
D.2103_79 = BIT_FIELD_REF {2, 2}, 64, 0;
...which causes he following ICE:
bug.c:8: error: invalid reference prefix
{2, 2}
bug.c:8: internal compiler error:
Doug Gregor [EMAIL PROTECTED] writes:
Of course, one could use TREE_CODE to see through the difference
between these two, e.g.,
#define TREE_CODE(NODE)
((enum tree_code) (NODE)-base.code == LANG_TYPE?
(enum tree_code)((TYPE_LANG_SPECIFIC (NODE)-base.subcode +
From: Ben Elliston [EMAIL PROTECTED]
gcc --coverage appears to be broken on x86_64 in gcc 4.1.1 on FC6
(works fine with Trunk). I'm almost certain that this is a known
issue, but cannot find a reference in Bugzilla.
I implemented that option, so can probably help you. Contact me in
private
Doug Gregor [EMAIL PROTECTED] writes:
Of course, one could use TREE_CODE to see through the difference
between these two, e.g.,
#define TREE_CODE(NODE)
((enum tree_code) (NODE)-base.code == LANG_TYPE?
(enum tree_code)((TYPE_LANG_SPECIFIC (NODE)-base.subcode +
On Wed, Mar 14, 2007 at 11:36:24AM +0200, Sunzir Deepur wrote:
Hello group,
any idea where I can find a (free) graphical VCG viewer suitable
for gcc's vcg outputs ?
seems like the old 1995 package is not applicable on newest linux systems
(am working on fedora).
See
On Wed, Mar 14, 2007 at 03:47:57AM +, Joseph S. Myers wrote:
On Tue, 13 Mar 2007, Andrew Pinski wrote:
Anyways the best way to fix this is just to fix the bug. Someone
We should have 0 unexpected FAILs in 4.2.0 on common platforms (in
particular the primary release criteria ones for
On Wed, Mar 14, 2007 at 03:47:57AM +, Joseph S. Myers wrote:
It's not punishing the testcase; it's recognising that we have a bug
tracking system to track regressions and having expected unexpected
FAILs is helpful neither to users wishing to know if their compiler built
as
Bootstrapping the trunk (Revision: 122847) on a mipsel-linux system
configured thusly:
$ ../gcc/configure --with-arch=mips32 --with-float=soft
--disable-java-awt --without-x --disable-tls --enable-__cxa_atexit
--disable-jvmpi --disable-static --disable-libmudflap
Joe Buck [EMAIL PROTECTED] writes:
On Wed, Mar 14, 2007 at 03:47:57AM +, Joseph S. Myers wrote:
It's not punishing the testcase; it's recognising that we have a bug
tracking system to track regressions and having expected unexpected
FAILs is helpful neither to users wishing to
On 3/14/07, Sunzir Deepur [EMAIL PROTECTED] wrote:
Hello,
I have used -da and -dv to produce vcg files of the CFG of this simple program:
int main(int argc, char**argv)
{
if(argc)
printf(positive\n);
else
printf(zero\n);
return 0;
}
I
I put the dicussion about compiler books in a WIKI page:
http://gcc.gnu.org/wiki/ListOfCompilerBooks since I feel it is of common
interest.
Please feel free to correct any mistakes and ad more comments or books.
Michael Cieslinski
On 3/14/07, Tristan Gingold [EMAIL PROTECTED] wrote:
Hi,
in some cases, a breakpoint can't be set on a continue or break
statement. Here is a simple example:
I think this is also related to
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29609
Yes, yes I have the whole bugzilla memorized. :)
On Wed, 2007-03-14 at 15:06 +0100, Richard Guenther wrote:
I think the BIT_FIELD_REF should be properly folded to a constant or
the propagation not done.
Agreed. I'd lean towards folding the BIT_FIELD_REF to a constant, but
if that isn't easy I'd recommend avoiding the propagation.
Jeff
* David Daney [EMAIL PROTECTED] [2007-03-14 10:01]:
I get:
$ make compare
Comparing stages 2 and 3
Probably the same as PR31169, reported for HPPA. Unfortunately the PR
doesn't contain much useful information yet.
--
Martin Michlmayr
[EMAIL PROTECTED]
Rohit Arul Raj wrote:
(define_insn movsf_store
[(set (match_operand:SF 0 memory_operand =m)
(match_operand:SF 1 float_regf))]
You must have a single movsf define_insn that accepts all alternatives
so that reload will work. You can't have separate define_insns for
movsf and
On Mar 14, 2007, at 1:49 AM, Ian Lance Taylor wrote:
I see it now. My apologies. I just committed a patch to the 4.2
branch to fix it.
--enable-werror, however, that only works well if you have installed
a gcc of the same vintage as your building. If they differ too much,
you'll still
[ oops, almost forgot why I stared sending the email ]
On Mar 14, 2007, at 1:49 AM, Ian Lance Taylor wrote:
I see it now. My apologies. I just committed a patch to the 4.2
branch to fix it.
I can confirm that fixed it, thanks.
Dear GCC Developers/Users,
I am working on a port of a target backend. I have a problem when
compiling the following program:
---snip---
short b = 5;
short c = 5;
int main(void)
{
long int a[b][c];
a[1][1]=5;
return 0;
}
---snap---
During compilation I get the following
On Mar 14, 2007, at 2:11 AM, Jakub Jelinek wrote:
On Tue, Mar 13, 2007 at 10:28:41PM -0400, Jack Howarth wrote:
Interestingly, while...
gcc-4 pr30703.C -fmessage-length=0 -fopenmp -O0 -L/sw/lib/gcc4.2/
lib -lgomp -lstdc++ -lm -m32 -o ./pr30703.exe
Could we please use g++ to compile C++
Markus Franke wrote:
Does anybody have an idea what could be wrong in the machine description
or to where start finding the error?
Compile with -da, and starting looking at the RTL dumps, mainly the greg
and lreg ones. The greg one will have a section listing all of the
reloads generated,
It looks like modifying the testsuite scripts for libgomp
to properly compile c++ files with g++ will be pretty messy.
Can we just fix PR30703 for now with the simple change...
Index: libgomp/testsuite/libgomp.c++/pr30703.C
===
I'm working on readying the Toshiba Media Processor (mep-elf) port for
contribution to GCC 4.x, but we added some core changes needed to
support it. The changes are listed below; I'd like some feedback
about these before I go too far with them. Are these concepts
acceptable for inclusion in
DJ Delorie [EMAIL PROTECTED] writes:
Coprocessor types - the MeP chip has optional coprocessors, each with
their own register sets. They need their own internal types (mostly
to keep track of which unit to use), which we've created by prefixing
the existing types with COP (i.e. COPSImode,
This and the register changes come close to multi-arch gcc.
Yup. The core has two modes, core and vliw, and the coprocessor(s)
each have their own units. The core manages the opcode processing,
but the coprocessor does the work.
Historically we have not tried to support different
Personally I'd love to see us go this way if it doesn't
inconvenience us too much.
It would be useful to be able to optimize each function as to, for
example, arm or thumb mode based on -Os and/or some heuristics. As a
long-term goal, at least.
Hello all,
Looking at the internals i couldn't find an answer for my problem.
I have a define_expand with the pattern name movmode and a
define_insn movmode_store
The predicate in define_expand is general_operand, so that all
operands are matched.
While in define_insn i have a predicate which
On Mar 14, 2007, Uros Bizjak [EMAIL PROTECTED] wrote:
Recent committed patch breaks i386ssefp-2.c testcase, where maxsd is
not generated anymore.
FWIW, I saw it both before and after the patch for PR 31127. I've
just tried reverting PR 30643 as well, but the problem remains. So
it's
On 14 Mar 2007 18:42:13 -0700, Ian Lance Taylor [EMAIL PROTECTED] wrote:
DJ Delorie [EMAIL PROTECTED] writes:
Coprocessor types - the MeP chip has optional coprocessors, each with
their own register sets. They need their own internal types (mostly
to keep track of which unit to use), which
This is what we do for the Cell also, we expect people to compile
using two different compilers right now, but we are actually looking
into doing an one source based compiling where some functions or
loops are pushed off to the SPUs via annotations like the OpenMP
ones.
It sounds like we're
Janis Johnson wrote:
It's not punishing the testcase; it's recognising that we have a bug
tracking system to track regressions and having expected unexpected
FAILs is helpful neither to users wishing to know if their compiler built
as expected nor to developers glancing over test results
--- Comment #5 from roberto dot gordo at gmail dot com 2007-03-14 08:52
---
unsigned is never promoted, it always stays unsigned.
Sorry to insist, but I'm still not convinced. Please, see these examples,
compiled with -std=c99.
{
unsigned u;
int i;
u = 1; /* this is an
--- Comment #12 from jellby at yahoo dot com 2007-03-14 09:04 ---
I get the same error if I rewind the file (or is it illegal?):
PROGRAM TEST
INTEGER :: A
OPEN(10, FORM=UNFORMATTED, RECL=1024)
A = -1
WRITE(10) A
REWIND(10)
WRITE(10) A
END PROGRAM TEST
--
jellby at
--- Comment #6 from roberto dot gordo at gmail dot com 2007-03-14 09:27
---
I think I've found something. According to the ISO C standard, a decimal
constant without suffixes should ALWAYS be signed int (or signed long long if
it does not fit), but never be unsigned! An octal or
--- Comment #7 from roberto dot gordo at gmail dot com 2007-03-14 09:40
---
That's OK, it is not a bug, sorry.
--
roberto dot gordo at gmail dot com changed:
What|Removed |Added
long emit_cmpxchg( long volatile* p, long from, long to )
{
long v = *p;
if ( v == from )
*p = to;
return v;
}
gcc should be able to optimize this.
--
Summary: cmpxchgq not emitted.
Product: gcc
Version: 4.2.0
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot
|dot org
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2007-03-14 10:49
---
Fixed on 4.2 and 4.3.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-03-14 10:55
---
(In reply to comment #2)
./cc1 -quiet -O -march=athlon-xp -m32 -ftree-vectorize x.i
x.i: In function 'foo':
x.i:2: error: invalid reference prefix
{4, 4, 4, 4}
x.i:2: error: invalid reference
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-03-14 11:00 ---
ifcvt could do this. But is cmpxchgq really faster with its atomictiy
guarantee?
They are all vector-path instructions, a compare - cmov sequence looks
faster (8 cycle latency vs. 10 and also with less constraints
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org
|dot org
Compiling xf86ScanPci.c from xorg-server 1.2.99.901 with gcc 4.2 branch (SVN
118519) takes much longer than with older versions of gcc, and takes loads of
memory (approx. 3 GB).
Works as expected with older gccs and with 4.2 and -O0.
--
Summary: [4.2 Regression] Compiling
--- Comment #1 from pluto at agmk dot net 2007-03-14 11:18 ---
this is a dup of PR30052
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31172
--- Comment #2 from bero at arklinux dot org 2007-03-14 11:21 ---
The difference between this and 30052 is that 30052 claims x86 is ok and the
problem occurs only on x86_64 -- it happens here with x86 (non-64).
Uploading preprocessed source currently gives a bugzilla internal error.
--- Comment #4 from dorit at il dot ibm dot com 2007-03-14 12:13 ---
I also saw this on powerpc64, on a different testcase (vectorizing longs with
-m64). seems like constant propagation during dom3 propagates the vector
initializer into a BIT_FIELD_EXPR, which results in invalid gimple?
--- Comment #5 from dorit at il dot ibm dot com 2007-03-14 12:29 ---
this is the testcase I have ICE-ing on powerpc64-yellowdog, when compiled with
-ftree-vectorize -maltivec -m64 -O2:
long stack_vars_sorted[32];
void partition_stack_vars (long stack_vars_num)
{
long si, n =
--- Comment #8 from roberto dot gordo at gmail dot com 2007-03-14 12:29
---
I'm still unable to match the behavior of gcc with the ISO C standard. I will
try to explain myself.
The reason for which gcc produces different results with hex constants is now
clear. Also, in the following
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-03-14 12:31
---
Here's a patch that should make the code in gfc_conv_cst_int_power() work in
all cases:
Index: trans-expr.c
===
--- trans-expr.c(revision
--- Comment #2 from ubizjak at gmail dot com 2007-03-14 13:13 ---
The problem is with TImode *addti3_1 splitter. An immediate is splitted from
TImode into double DImode values and these values are passed to add/addc pair:
(define_split
[(set (match_operand:TI 0 nonimmediate_operand )
--- Comment #3 from ubizjak at gmail dot com 2007-03-14 13:42 ---
Prototype patch that fixes the failure:
2007-03-14 Uros Bizjak [EMAIL PROTECTED]
* config/i386/i386.md (*addti3_1, *addti3_1 splitter): Use
x86_64_general_operand as operand[2] predicate.
--- Comment #4 from ubizjak at gmail dot com 2007-03-14 13:43 ---
Created an attachment (id=13205)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13205action=view)
Patch
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31167
--- Comment #4 from dominiq at lps dot ens dot fr 2007-03-14 13:58 ---
Subject: Re: ICE with integer_exponentiation_1.f90 and -ffast-math
And Dominique, I would appreciate if you could test the patch on ppc-darwin7.
I'll do it tonight, but before could you test the following code:
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2007-03-14 14:02
---
(In reply to comment #4)
I'll do it tonight, but before could you test the following code
[karma] f90/bug% gfc test_pow.f90
Out of stack space.
Try running 'limit stacksize unlimited' in the shell to raise
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-03-14 14:15 ---
same source, same problem.
*** This bug has been marked as a duplicate of 30052 ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from rguenth at gcc dot gnu dot org 2007-03-14 14:15
---
*** Bug 31172 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30052
--- Comment #13 from rguenth at gcc dot gnu dot org 2007-03-14 14:21
---
It's really all PTA memory.
Mainline:
tree PTA : 0.01 ( 0%) usr 0.00 ( 0%) sys 0.00 ( 0%) wall
40 kB ( 0%) ggc
TOTAL : 2.18 1.05 3.44
--- Comment #6 from dominiq at lps dot ens dot fr 2007-03-14 14:27 ---
Subject: Re: ICE with integer_exponentiation_1.f90 and -ffast-math
On i686-linux, the unpatched compiler works OK without -ffast-math and
segfaults with it.
I am a little bit worried about that. As far as I know
--- Comment #77 from jv244 at cam dot ac dot uk 2007-03-14 14:48 ---
Currently
GNU Fortran (GCC) 4.3.0 20070313 (experimental)
there seems to be a new gcc error on CP2K:
gfortran -c -O3 -ftree-loop-linear -ftree-vectorize -ffast-math -march=opteron
-msse2 fparser.f90
--- Comment #78 from ubizjak at gmail dot com 2007-03-14 15:01 ---
(In reply to comment #77)
gfortran -c -O3 -ftree-loop-linear -ftree-vectorize -ffast-math -march=opteron
-msse2 fparser.f90
/tmp/ccNk6D7G.s: Assembler messages:
/tmp/ccNk6D7G.s:820: Error: suffix or operands
--- Comment #14 from dberlin at gcc dot gnu dot org 2007-03-14 15:12
---
(In reply to comment #13)
It's really all PTA memory.
Mainline:
tree PTA : 0.01 ( 0%) usr 0.00 ( 0%) sys 0.00 ( 0%) wall
40 kB ( 0%) ggc
TOTAL : 2.18
--- Comment #79 from jv244 at cam dot ac dot uk 2007-03-14 15:14 ---
(In reply to comment #78)
Could you post the temporary asm (only lines around line 820 will be enough)
to
check what is going wrong?
.L157:
movslq %r13d,%rax
imulq %rsi, %rax
addq
=opteron
-msse2 fparser.f90
/tmp/ccNk6D7G.s: Assembler messages:
/tmp/ccNk6D7G.s:820: Error: suffix or operands invalid for `sahf'
Does not seem to happen (20070314 on x86-64 Linux) with current CVS version of
CP2k.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29975
--- Comment #12 from uweigand at gcc dot gnu dot org 2007-03-14 15:26
---
This does fix my testcase on mainline. Thanks!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30590
--- Comment #81 from ubizjak at gmail dot com 2007-03-14 15:30 ---
(In reply to comment #79)
movsd %xmm2, (%rsp)
fldl(%rsp)
movsd %xmm1, (%rsp)
fldl(%rsp)
fxch%st(1)
.L120:
fprem
fnstsw %ax
sahf
Hi,
I am cross compiling gcc-4.1.2 for arm
I am currently using gcc-4.1.2 for crosscompiling gcc-4.1.2 source tree
GNU binutils compiled on version 2.17 crosscompiled for ARM
I have attached the text of the error.
--
Summary: Error when cross-compiling gcc-4.1.2 for ARM
--- Comment #1 from bhasker at unixindia dot com 2007-03-14 16:05 ---
Created an attachment (id=13206)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13206action=view)
compilation log
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31173
Ada compiler under gcc-4.2-20070307 fails ACATS c380004. Below is the content
of the test log
,.,. C380004 ACATS 2.5 07-03-12 14:21:49
C380004 Check evaluation of discriminant expressions when the
constraint depends on a discriminant, and the
discriminants
--- Comment #82 from jv244 at cam dot ac dot uk 2007-03-14 16:29 ---
Huh, I somehow misread opteron for athlon. Your code is OK for x86_64, but it
looks to me that you will have to upgrade binutils.
upgrading binutils is not much of an option for me, but with -march=x86-64 I
get
--- Comment #3 from jv244 at cam dot ac dot uk 2007-03-14 16:30 ---
(In reply to comment #2)
this issue now seems fixed on trunk for me as well, so I guess this could be
closed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30835
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-03-14 16:35 ---
../.././gcc/gthr-posix.h:43:21: error: pthread.h: No such file
or directory
../.././gcc/gthr-posix.h:44:20: error: unistd.h: No such file
or directory
That just means you don't
#include math.h
double x = -__builtin_inf ();
int main()
{
if (isinf (x) != -1)
abort ();
return 0;
}
Examine the definition of isinf closely. It returns -1 for -inf.
--
Summary: isinf incorrectly expanded
Product: gcc
Version: 4.3.0
--- Comment #1 from schwab at suse dot de 2007-03-14 17:19 ---
The standard has no such requirement. It only talks about non-zero value.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31175
While discussing how today's C++ compilers lay out data members of structs and
classes on the C++ committee's mailing list the observation was made that no
known implementation, including gcc, takes advantage of the permission to
rearrange members declared with their own access specifier (see
--- Comment #2 from ubizjak at gmail dot com 2007-03-14 17:38 ---
(In reply to comment #0)
Examine the definition of isinf closely. It returns -1 for -inf.
But:
NOTE
Note that these functions are obsolete. C99 defines macros isfinite(),
isinf() and isnan() (for all
--- Comment #10 from craig dot lawson at centrify dot com 2007-03-14 18:13
---
Found it.
The problem is that the library is not be ing properly compiled for
multi-threaded use, but that by some luck basic_file.cc happened to be compiled
that way anyway. c++locale.cc was not so lucky.
--- Comment #1 from fang at csl dot cornell dot edu 2007-03-14 18:14
---
Interesting. Do the attributes apply to derived classes automatically?
struct B __attribute__((reorder)) {
char a;
int b;
};
struct D : public B {
char c, d, e;
};
Is D also allowed to reorder members a and
--- Comment #9 from patchapp at dberlin dot org 2007-03-14 18:15 ---
Subject: Bug number PR 23572
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/2007-03/msg00943.html
--
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-03-14 18:16 ---
Note actually some compilers actually do this even without an attribute. This
is related to the art hack.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31176
1 - 100 of 153 matches
Mail list logo
