Hi Jim,
On 9/12/07, Jim Wilson [EMAIL PROTECTED] wrote:
Sunzir Deepur wrote:
recently I've encountered a problem in which some removals of
(what seems to be unneeded) lines of header files inflicted changes in
the resulting binary. further inverstigation showed
that the chages were
bootstrap with current svn head fails for me on Linux/x86-64:
/abuild/aj/gcc/./prev-gcc/xgcc -B/abuild/aj/gcc/./prev-gcc/
-B/opt/gcc/4.3-devel/x86_64-suse-linux-gnu/bin/ -c -g -O2 -DIN_GCC -W -Wall
-Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition
On 11 Sep 2007 18:14:21 -0700, Ian Lance Taylor [EMAIL PROTECTED] wrote:
Richard Guenther [EMAIL PROTECTED] writes:
On 9/9/07, Richard Guenther [EMAIL PROTECTED] wrote:
Which brings back the fact that you cannot implement malloc in C
(you certainly remember the discussions about C++
Andreas Jaeger [EMAIL PROTECTED] writes:
bootstrap with current svn head fails for me on Linux/x86-64:
...
cc1: warnings being treated as errors
/cvs/gcc-svn/trunk/gcc/treelang/treetree.c:1191: error:
‘treelang_expand_function’ defined but not used
make[3]: *** [treelang/treetree.o] Error 1
Andreas Jaeger [EMAIL PROTECTED] writes:
bootstrap with current svn head fails for me on Linux/x86-64:
...
cc1: warnings being treated as errors
/cvs/gcc-svn/trunk/gcc/treelang/treetree.c:1191: error:
???treelang_expand_function??? defined but not used
make[3]: ***
On 9/11/07, Jim Wilson [EMAIL PROTECTED] wrote:
It does look like loop-iv.c is broken though. Every
simplify_gen_relational call uses SImode. That probably should be
word_mode instead. You might want to submit a bug report for that.
I think even using word_mode there is wrong. An example
I have two patch may be worth to enter into 4.3 at stage 2.
Jan and I tried to ping the first part now about some time and we didn't
got a comment or approval for them.
See
http://www.nabble.com/-PING%5E2-PATCH-%3A-Preparations-for-SYSV-MS-ABI-attributes-in-backend-tf4414541.html
I have to make buying decisions, and having tested a Sun T1000 for a
while I am impressed with Suns hardware. But, we are 100% gnu/linux and
it disturbs me that David Miller seems to be a (very impressive) team of
1 on the sparclinux ML (My impression; perhaps I am wrong?)
So I wonder, is Sun
From: Andrew Walrond [EMAIL PROTECTED]
Date: Wed, 12 Sep 2007 12:37:03 +0100
I have to make buying decisions, and having tested a Sun T1000 for a
while I am impressed with Suns hardware. But, we are 100% gnu/linux and
it disturbs me that David Miller seems to be a (very impressive) team of
1
Hi,
I apologize for the late response to your mail but I sort of did these
patches up recently .
I have a couple of patches that I submitted / intend to submit . One
of them was submitted today regarding a small improvement to the
auto-increment pass. I am not sure if this is suitable for stage3
David Miller wrote:
So no, Sun really isn't helping with any actual development.
I don't know what to say. Incredible work David, but quite frankly, I'm
speechless.
I'm sure I can't be the only hardware purchaser asking these questions.
I really like the Niagra and the successors sound even
On Wed, 12 Sep 2007, Andrew Walrond wrote:
David Miller wrote:
So no, Sun really isn't helping with any actual development.
I don't know what to say. Incredible work David, but quite frankly, I'm
speechless.
I'm sure I can't be the only hardware purchaser asking these questions.
I really
Andrew Walrond wrote:
I'm trying to conceive a valid business reason for Sun to be so
dismissive of the (surely massive?) gnu/linux hardware market, (even if
they would rather we used Solaris), but it eludes me completely.
They are putting a lot of effort into linux on Intel and AMD. 18
Richard Guenther [EMAIL PROTECTED] writes:
CHANGE_DYNAMIC_TYPE_EXPR has the target type, of course. So perhaps
we need __attribute__ ((change_dynamic_type))?
Or actually of course __attribute__ ((malloc)) is fine but we could
throw in a CHANGE_DYNAMIC_TYPE_EXPR after any call to such a
On 12 Sep 2007 08:13:31 -0700, Ian Lance Taylor [EMAIL PROTECTED] wrote:
Richard Guenther [EMAIL PROTECTED] writes:
CHANGE_DYNAMIC_TYPE_EXPR has the target type, of course. So perhaps
we need __attribute__ ((change_dynamic_type))?
Or actually of course __attribute__ ((malloc)) is
Tehila asked me a while ago to comment based on my experience with the
RTL if convert pass and the discussions some of us had at the GCC
summit. Sorry it took me so long to respond.
The target I care about (Cell SPU) has some things that make an
aggressive if convert very useful and profitable.
--- Comment #4 from ubizjak at gmail dot com 2007-09-12 06:50 ---
Fixed by http://gcc.gnu.org/ml/gcc-cvs/2007-09/msg00364.html
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #6 from ubizjak at gmail dot com 2007-09-12 06:52 ---
Middle-end was fixed by http://gcc.gnu.org/ml/gcc-cvs/2007-09/msg00406.html
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #1 from hubicka at gcc dot gnu dot org 2007-09-12 07:03 ---
Subject: Bug 33393
Author: hubicka
Date: Wed Sep 12 07:02:31 2007
New Revision: 128414
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128414
Log:
PR target/33393
* i386.md
--- Comment #3 from dorit at gcc dot gnu dot org 2007-09-12 07:10 ---
Subject: Bug 33373
Author: dorit
Date: Wed Sep 12 07:09:38 2007
New Revision: 128415
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128415
Log:
PR tree-optimization/33373
* tree-vect-analyze
--- Comment #1 from wvangulik at xs4all dot nl 2007-09-12 07:20 ---
Tested this against 4.1.2. The output for the given test case is different
(optimiser removed the useless loading):
/* prologue: frame size=0 */
push r28
/* prologue end (size=1) */
/* #APP */
in r28,
--- Comment #2 from wvangulik at xs4all dot nl 2007-09-12 07:32 ---
(In reply to comment #1)
Hmm I cheated... I used -Os when compiling
Compiling without -O[n] gives no warning
Just tried compiling -O and then it does generate the error. It seems optimiser
flags triggers the warning?
--- Comment #3 from wvangulik at xs4all dot nl 2007-09-12 07:35 ---
(In reply to comment #2)
Ok I need some coffee...
The error IS generated when using -O[n] (so on -O as well)
Without specifing -O the compiler does not generate the warning.
--
--- Comment #7 from rguenth at gcc dot gnu dot org 2007-09-12 07:54 ---
Subject: Bug 33382
Author: rguenth
Date: Wed Sep 12 07:54:17 2007
New Revision: 128417
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128417
Log:
2007-09-12 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #6 from burnus at gcc dot gnu dot org 2007-09-12 07:56 ---
Subject: Bug 33395
Author: burnus
Date: Wed Sep 12 07:56:07 2007
New Revision: 128418
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128418
Log:
2007-09-12 Christopher D. Rickett [EMAIL PROTECTED]
--- Comment #8 from rguenth at gcc dot gnu dot org 2007-09-12 08:07 ---
Subject: Bug 33382
Author: rguenth
Date: Wed Sep 12 08:07:12 2007
New Revision: 128419
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128419
Log:
2007-09-12 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #7 from burnus at gcc dot gnu dot org 2007-09-12 08:19 ---
FIXED.
(The FGSL test suite still fails due to the broken formatted read of a line
ending without line break, see PR 33400; working around that bug, the test
suite succeeds - hooray!)
--
burnus at gcc dot gnu
--- Comment #9 from rguenth at gcc dot gnu dot org 2007-09-12 08:27 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-09-12 08:33 ---
So, invalid.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Hi ,
There's a difference in the code generated between O2 and O3 in the case below.
void fred(long in, short *out1)
{
int i;
for (i=0;i100;i++)
out1[i+1] = out1[i]*in;
}
With O2 we generate at expand time -
fred (in, out1)
{
unsigned int ivtmp.24;
bb 2:
ivtmp.24 =
I cannot compile the following file:
$ /usr/bin/g++-3.3 -save-temps -D_IntensityFiltersPython_EXPORTS -g -Wall -W
-Woverloaded-virtual -Wunused -ftemplate-depth-50 -w -ftemplate-depth-50 -O3
-DNDEBUG -fPIC -I/home/mmalaterre/Projects/Insight/Code/Review
The bootstrap failure reported in
http://gcc.gnu.org/ml/gcc/2007-09/msg00147.html is still present in revision
128385.
--
Summary: At revision 128385 Bootstraping PPC Darwin still fail in
Java
Product: gcc
Version: 4.3.0
Status:
--- Comment #1 from mathieu dot malaterre at gmail dot com 2007-09-12
09:05 ---
sorry just found out:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14711#c17
*** This bug has been marked as a duplicate of 14711 ***
--
mathieu dot malaterre at gmail dot com changed:
What
--- Comment #27 from mathieu dot malaterre at gmail dot com 2007-09-12
09:05 ---
*** Bug 33405 has been marked as a duplicate of this bug. ***
--
mathieu dot malaterre at gmail dot com changed:
What|Removed |Added
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-09-12 09:18 ---
(In reply to comment #2)
I don't know about most likely. sizeof(int) == sizeof(void*) is still pretty
common, so my guess would be that the warning is more often wrong than not.
Common on ILP32 targets but since
--- Comment #2 from patchapp at dberlin dot org 2007-09-12 09:20 ---
Subject: Bug number PR33310
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-09/msg00333.html
--
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-09-12 09:34 ---
libgomp is also broken for powerpc*-linux-gnu. It times out.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33406
Nothing in the IL of the following testcase prevents the stores
to *q and *r in function doit from being reordered:
extern C void * malloc(__SIZE_TYPE__);
extern C void abort(void);
void *p;
void __attribute__((noinline)) init(void)
{
p = malloc(4);
}
inline void *operator new(__SIZE_TYPE__)
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-09-12 10:00 ---
Related to PR29286.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-09-12 10:13 ---
main should call init(), but it doesn't make a difference for the IL. The
bug is wrong-IL for me only at the moment, but nothing prevents the two stores
from being reordered.
Here's one that abort()s at runtime on
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-09-12 10:18 ---
4.2 works by luck as we weakened aliasing by the NONLOCAL stuff. 2.95 works
for whatever reason ;) Even pre-tree-ssa we fail with -O2 (but it works with
-O).
--
rguenth at gcc dot gnu dot org changed:
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-09-12 10:20 ---
-O fails with -fstrict-aliasing as well.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33407
--- Comment #1 from burnus at gcc dot gnu dot org 2007-09-12 10:27 ---
Subject: Bug 33284
Author: burnus
Date: Wed Sep 12 10:27:27 2007
New Revision: 128423
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128423
Log:
2007-09-12 Tobias Burnus [EMAIL PROTECTED]
PR
--- Comment #3 from burnus at gcc dot gnu dot org 2007-09-12 10:27 ---
Subject: Bug 33310
Author: burnus
Date: Wed Sep 12 10:27:27 2007
New Revision: 128423
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128423
Log:
2007-09-12 Tobias Burnus [EMAIL PROTECTED]
PR
--- Comment #4 from burnus at gcc dot gnu dot org 2007-09-12 10:30 ---
Subject: Bug 33297
Author: burnus
Date: Wed Sep 12 10:30:22 2007
New Revision: 128424
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128424
Log:
2007-09-12 Tobias Burnus [EMAIL PROTECTED]
PR
--- Comment #5 from burnus at gcc dot gnu dot org 2007-09-12 10:34 ---
FIXED for the trunk (GCC gfortran 4.3.0).
Thanks for the report.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from burnus at gcc dot gnu dot org 2007-09-12 10:35 ---
FIXED.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33310
--- Comment #5 from burnus at gcc dot gnu dot org 2007-09-12 10:36 ---
Really mark as FIXED.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from burnus at gcc dot gnu dot org 2007-09-12 10:36 ---
FIXED.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from fxcoudert at gcc dot gnu dot org 2007-09-12 11:45
---
I think this was fixed (from gcc/ada/gnat_ugn.texi):
@noindent
As for the @code{C} calling convention, when the @code{External_Name}
parameter is missing, it is taken to be the name of the Ada entity in lower
--- Comment #2 from jh at suse dot cz 2007-09-12 12:01 ---
Subject: Re: [4.3 Regression] Revision 128239 causes libgomp failure
Hi,
I´ve just tested ia64-linux and x86_64-linux on our testers and both are
clean WRT libgomp:
=== libgomp Summary ===
#
--- Comment #5 from kbateman at seicorp dot com 2007-09-12 12:52 ---
Whaddaya know. Section 5-16, Expressions:
If the new-initializer is of the form (), default-initialization shall be
performed (8.5);
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33401
--- Comment #9 from rask at gcc dot gnu dot org 2007-09-12 13:12 ---
This still happens with GCC 4.3 when trying to bootstrap with BOOT_CFLAGS='-O2
-g -fomit-frame-pointer -masm=intel' and it blocks me from working on bug
29493.
--- Comment #10 from ubizjak at gmail dot com 2007-09-12 13:41 ---
(In reply to comment #9)
This still happens with GCC 4.3 when trying to bootstrap with BOOT_CFLAGS='-O2
-g -fomit-frame-pointer -masm=intel' and it blocks me from working on bug
29493.
--- Comment #3 from hjl at lucon dot org 2007-09-12 13:54 ---
(In reply to comment #2)
Subject: Re: [4.3 Regression] Revision 128239 causes libgomp failure
Hi,
I´ve just tested ia64-linux and x86_64-linux on our testers and both are
clean WRT libgomp:
===
--- Comment #4 from jh at suse dot cz 2007-09-12 14:16 ---
Subject: Re: [4.3 Regression] Revision 128239 causes libgomp failure
Have you compared the times to take for make check on libgomp between
revision 128238 and HEAD? With C libgomp tests only, revision 128238 takes
less
--- Comment #5 from hjl at lucon dot org 2007-09-12 14:24 ---
(In reply to comment #4)
Interesting. At the moment I can't access any ia64 machine directly,
just test via our mail based interface that won't let me time the test.
Are those failures an timeouts? It might be some
207
# of unresolved testcases 4
# of untested testcases 35
# of unsupported tests 314
/tmp/jakub/gcc/obj/gcc/xgcc version 4.3.0 20070912 (experimental) (GCC)
=== gfortran tests ===
Running target unix
FAIL: gfortran.dg/do_3.F90 -O3 -fomit-frame-pointer
--- Comment #7 from jakub at gcc dot gnu dot org 2007-09-12 14:39 ---
BTW, when you say -fno-inline-small-functions cures this for you, is the
problem
on libgomp side or in the generated gomp tests? I.e. if you build libgomp
with the default -O2 -finline-small-functions and run
make
--- Comment #9 from hjl at lucon dot org 2007-09-12 14:41 ---
(In reply to comment #7)
BTW, when you say -fno-inline-small-functions cures this for you, is the
problem
on libgomp side or in the generated gomp tests? I.e. if you build libgomp
Apparently not. From
--- Comment #8 from hjl at lucon dot org 2007-09-12 14:40 ---
(In reply to comment #6)
Cannot reproduce this with r128425 + PR32337 + PR32338 fix (8way ia64, make
-j16 -k check):
From
http://gcc.gnu.org/ml/gcc-testresults/2007-09/msg00573.html
=== libgomp tests
--- Comment #32 from rguenth at gcc dot gnu dot org 2007-09-12 14:44
---
load-store motion at the tree level should really catch this. For this it
needs to be extended to disambiguate aliases by looking at the actual memory
references:
bb 4:
# r_8 = PHI r_29(5), r_23(D)(3)
# n_11
--- Comment #33 from rakdver at gcc dot gnu dot org 2007-09-12 14:49
---
Zdenek, I think you had a patch to make lim more precise in this regard?
Yes. Revital Eres was trying to put it into shape suitable for mainline a few
months ago, I am not sure what is the status of that?
--
--- Comment #7 from rguenth at gcc dot gnu dot org 2007-09-12 15:03 ---
For 4.3 we improve runtime with FDO and -O2, in both cases, with and without
FDO 4.3 scores 20% better than 3.4. With 4.1 I also see better scores with
FDO.
For -O3 scores are the same with/w/o FDO for 4.1 and
--- Comment #10 from jakub at gcc dot gnu dot org 2007-09-12 15:04 ---
The whole testsuite takes roughly 10 minutes:
head -n2 libgomp.log; tail -n4 libgomp.log
Test Run By root on Wed Sep 12 10:47:12 2007
Native configuration is ia64-unknown-linux-gnu
=== libgomp Summary
--- Comment #34 from eres at il dot ibm dot com 2007-09-12 15:09 ---
I did not engage with it for some time so I doubt it if my latest version of
the patch (which is originally in
http://gcc.gnu.org/ml/gcc-patches/2007-01/msg02331.html) is suitable for
current mainline. I will
--- Comment #11 from hjl at lucon dot org 2007-09-12 15:36 ---
(In reply to comment #10)
you started seeing this or from 4.2? Knowing whether your libgomp was
miscompiled or if the testcases themselves are miscompiled is really crucial
to finding out what's going on.
I verified
--- Comment #12 from jakub at gcc dot gnu dot org 2007-09-12 15:48 ---
Can you see if e.g. building whole libgomp with -O0 fixes it?
If yes, can you do a binary search which of the sources is miscompiled?
Thanks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33389
--- Comment #2 from ebotcazou at gcc dot gnu dot org 2007-09-12 15:53
---
Subject: Bug 32407
Author: ebotcazou
Date: Wed Sep 12 15:52:57 2007
New Revision: 128441
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128441
Log:
PR ada/26797
PR ada/32407
*
--- Comment #44 from ebotcazou at gcc dot gnu dot org 2007-09-12 15:53
---
Subject: Bug 26797
Author: ebotcazou
Date: Wed Sep 12 15:52:57 2007
New Revision: 128441
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128441
Log:
PR ada/26797
PR ada/32407
*
Thread model: posix
gcc version 4.3.0 20070912 (experimental) (GCC)
--
Summary: internal compiler error: tree check: expected type_decl,
have in debug_flush_symbol_queue, at final.c:3986
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
--- Comment #45 from ebotcazou at gcc dot gnu dot org 2007-09-12 15:55
---
At long last.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from dir at lanl dot gov 2007-09-12 15:55 ---
Created an attachment (id=14195)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14195action=view)
The fortran source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33408
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2007-09-12 15:56
---
Fixed on mainline.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
CC||ebotcazou at gcc dot gnu dot
|
With the following command line:
[c:\hack]==#9658; gcc -v -save-temps --pedantic -c a.cpp
Reading specs from /mingw/lib/gcc/mingw32/3.4.2/specs
Configured with: ../gcc/configure --with-gcc --with-gnu-ld --with-gnu-as
--host=mingw32 --target=mingw32 --prefix=/mingw --enable-threads --disable-nls
--- Comment #1 from martinezfive at comcast dot net 2007-09-12 16:13
---
Created an attachment (id=14196)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14196action=view)
a.cpp
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33409
--- Comment #5 from jakub at gcc dot gnu dot org 2007-09-12 16:13 ---
Could we limit adding of the CHANGE_DYNAMIC_TYPE_EXPRs just to the case
where operator new or __attribute__((malloc)) marked FUNCTION_DECL is not
external? That would be solid even for LTO, if you LTO and have say
--- Comment #6 from burnus at gcc dot gnu dot org 2007-09-12 16:36 ---
See also http://groups.google.com/group/comp.lang.fortran/msg/362cea390359d128
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33106
--- Comment #13 from hjl at lucon dot org 2007-09-12 16:51 ---
(In reply to comment #12)
Can you see if e.g. building whole libgomp with -O0 fixes it?
If yes, can you do a binary search which of the sources is miscompiled?
Thanks.
When I replaced bar.o with the bad one, C only
--- Comment #2 from burnus at gcc dot gnu dot org 2007-09-12 16:52 ---
I cannot reproduce this on x86-64 (Rev. 128440 of today).
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #14 from jakub at gcc dot gnu dot org 2007-09-12 16:59 ---
Can you please attach bad and good bar.s (with -fverbose-asm) and also
-ftree-dump-optimized dump from both?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33389
--- Comment #15 from hjl at lucon dot org 2007-09-12 17:10 ---
Created an attachment (id=14197)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14197action=view)
Good bar.s and bar.c.117t.optimized generated by revision 128238
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33389
--- Comment #16 from hjl at lucon dot org 2007-09-12 17:11 ---
Created an attachment (id=14198)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14198action=view)
Bad bar.s and bar.c.121t.optimized generated by revision 128239
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33389
--- Comment #17 from hjl at lucon dot org 2007-09-12 17:18 ---
gomp_barrier_wait_end in bar.c.121t.optimized has
__asm__ __volatile__(break 0x10:=r r15, =r out0, =r out1, =r
out2, =r out3:r r15, r out0, r out1, r out2, r out3:b6, f15,
f14, f13, f12, f11, f10, f9, f8, f7, f6, p15,
--- Comment #18 from hjl at lucon dot org 2007-09-12 17:20 ---
Revision 128239 miscompiled
static inline void
sys_futex0(int *addr, int op, int val)
{
register long out0 asm (out0) = (long) addr;
register long out1 asm (out1) = op;
register long out2 asm (out2) = val;
register
--- Comment #19 from jakub at gcc dot gnu dot org 2007-09-12 17:49 ---
Here is self-contained source:
void
sys_futex0(int *addr, int op, int val)
{
register long out0 asm (out0) = (long) addr;
register long out1 asm (out1) = op;
register long out2 asm (out2) = val;
--- Comment #20 from jakub at gcc dot gnu dot org 2007-09-12 18:26 ---
append_vuse has:
static inline void
append_vuse (tree var)
{
tree sym;
if (TREE_CODE (var) != SSA_NAME)
{
tree mpt;
var_ann_t ann;
/* If VAR belongs to a memory partition, use it instead
[ forwarded from http://bugs.debian.org/442036 ]
[EMAIL PROTECTED]:/src/delta/bin% cat test.c
long double f(long double *data, long n) {
long double max = 0;
long i;
for (i = 0; i n; i++) {
if (data[i])
max = 1;
}
return max;
}
[EMAIL
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-09-12 19:15 ---
loop-iv.c is RTL.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from dir at lanl dot gov 2007-09-12 19:17 ---
It compiles on the Intel Macintosh with no problem.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33408
--- Comment #21 from wilson at specifix dot com 2007-09-12 19:30 ---
Subject: Re: [4.3 Regression] Revision 128239
causes libgomp failure
The failure occurs in the sdse (simple dead store elimination) pass.
It looks like it is confused by an extended asm statement with
I configured with -
../gcc/configure --prefix=/usr/local/java --enable-languages=c,c++,java
--with-ecj-jar=/Users/dir/gfortran/gcc/ecj.jar --enable-java-awt=gtk
--enable-gtk-cairo --disable-bootstrap --disable-multilib
--x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib
The build failed
--- Comment #1 from andreast at gcc dot gnu dot org 2007-09-12 19:51
---
*** This bug has been marked as a duplicate of 33406 ***
--
andreast at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from andreast at gcc dot gnu dot org 2007-09-12 19:51
---
*** Bug 33411 has been marked as a duplicate of this bug. ***
--
andreast at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from burnus at gcc dot gnu dot org 2007-09-12 19:53 ---
Mine
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|dfranke at
C1242 (R1227) A prefix shall not specify ELEMENTAL if
proc-language-binding-spec appears in the function-stmt or subroutine-stmt.
NAG f95:
Error: z.f90, line 1: BIND(C) is not allowed for elemental procedure A
Example:
elemental function a(b) bind(c)
use iso_c_binding
real(c_float) :: a, b
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Component|bootstrap |target
Keywords||build,
--- Comment #3 from andreast at gcc dot gnu dot org 2007-09-12 20:32
---
--disable-checking succeeded with rev 128389.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33406
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |blocker
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33389
1 - 100 of 120 matches
Mail list logo
