--- Comment #2 from dominiq at lps dot ens dot fr 2007-09-13 06:39 ---
The (spurious?) warning is also present in 4.3.
> The patch here is clearly wrong. If you don't like the warnings, you should
> work out why they are being output and fix the underlying bug, rather than
> gnoring th
rce if appropriate.
> See <http://gcc.gnu.org/bugs.html> for instructions.
Works for me with gcc version 4.3.0 20070912 (experimental).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33414
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2007-09-13 06:06
---
> Another problem, GNAT Bug Box, is resulted with the tree updated as shown
>
> [...]
> c-4.3-20070907/gcc/ada/a-chlat1.ads -o ada/a-chlat1.o
> /home/voax/linux/build-4.3.x/./prev-gcc/xgcc
> -B/home/voax/linux/bu
--- Comment #1 from patchapp at dberlin dot org 2007-09-13 05:10 ---
Subject: Bug number PR 33412
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/msg01122.html
--
http://gcc.gnu.org/bugzilla/s
--- Comment #8 from patchapp at dberlin dot org 2007-09-13 05:10 ---
Subject: Bug number PR33106
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/msg01118.html
--
http://gcc.gnu.org/bugzilla/sh
--- Comment #14 from prj-bugzilla-gcc at multivac dot cwru dot edu
2007-09-13 05:07 ---
This bug is still present, and my patch still works, in 4.2.2-RC-20070909. If
it's too late (again) to go in this release, is there anything more I can do to
make it more likely to be fixed in the n
--- Comment #35 from eres at il dot ibm dot com 2007-09-13 04:45 ---
Created an attachment (id=14200)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14200&action=view)
lim patch
As I suspected my latest available version is not suitable for current
mainline (I attached it anyway
--- Comment #24 from hjl at lucon dot org 2007-09-13 04:03 ---
(In reply to comment #23)
> (In reply to comment #22)
>
> > 2007-09-12 James E. Wilson <[EMAIL PROTECTED]>
> >
> > * tree-ssa-operands.c (append_vuse): If ann->in_vdef_list true,
> > then set build_loads
--- Comment #5 from andreast at gcc dot gnu dot org 2007-09-13 03:56
---
I see now the same, --enable-checking is used now.
--
andreast at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #7 from danglin at gcc dot gnu dot org 2007-09-13 03:49 ---
Fixed.
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRM
--- Comment #6 from danglin at gcc dot gnu dot org 2007-09-13 03:45 ---
Subject: Bug 33153
Author: danglin
Date: Thu Sep 13 03:45:16 2007
New Revision: 128456
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=128456
Log:
PR testsuite/33153
* gcc.dg/pr32912-1.c: Add
--- Comment #1 from debian-gcc at lists dot debian dot org 2007-09-13
00:59 ---
Created an attachment (id=14199)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14199&action=view)
preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33414
seen with 4.3 20070909, works with 4.2 20070831
Matthias
$ g++ -c -O2 -g -fPIC -c libkformulalib_la.all_cc.iiIn file included from
libkformulalib_la.all_cc.cc:45:/scratch/packages/lpia/tmp/koffice-1.6.3/./lib/kformula/formulacursor.cc:
In member function 'KFormula::BasicElement*
KFormula::Formu
--- Comment #5 from danglin at gcc dot gnu dot org 2007-09-13 00:43 ---
Subject: Bug 33153
Author: danglin
Date: Thu Sep 13 00:43:04 2007
New Revision: 128454
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=128454
Log:
PR testsuite/33153
* gcc.dg/pr32912-1.c: Add
--- Comment #23 from hjl at lucon dot org 2007-09-13 00:13 ---
(In reply to comment #22)
>
> This works for the testcase, but has had no other testing as yet.
>
> 2007-09-12 James E. Wilson <[EMAIL PROTECTED]>
>
> * tree-ssa-operands.c (append_vuse): If ann->in_vdef_list tru
--- Comment #2 from anhvofrcaus at gmail dot com 2007-09-12 23:39 ---
Another problem, GNAT Bug Box, is resulted with the tree updated as shown
[...]
c-4.3-20070907/gcc/ada/a-chlat1.ads -o ada/a-chlat1.o
/home/voax/linux/build-4.3.x/./prev-gcc/xgcc
-B/home/voax/linux/build-4.3.x/./prev-
--- Comment #22 from wilson at specifix dot com 2007-09-12 23:35 ---
Subject: Re: [4.3 Regression] Revision 128239
causes libgomp failure
jakub at gcc dot gnu dot org wrote:
> No matter whether it is right or wrong in tree-ssa-operands.c, I think
> sdse should just avoid removing VAR
--- Comment #7 from kargl at gcc dot gnu dot org 2007-09-12 22:04 ---
Closing the bug at Bill's request. The bug appears to be local to his
setup. Thanks Bill for the bug report; if you have future problems
don't hesitate in sending a bug report.
--
kargl at gcc dot gnu dot org cha
--- Comment #2 from burnus at gcc dot gnu dot org 2007-09-12 21:26 ---
"12.7.2 Elemental function actual arguments and results
[...] For those elemental functions that have more than one argument, all
actual arguments shall be conformable."
"conformable (2.4.5) : Two arrays are said to
--- Comment #15 from jakub at gcc dot gnu dot org 2007-09-12 21:21 ---
H.J. committed this earlier today:
http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=128409
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
-
For most ARM architecture variants, the only atomic operation is swap. The
semantics of the SWP instruction are what gcc calls __sync_lock_test_and_set (a
rather odd name since the set is unconditional). Would it be possible to add a
__sync_lock_test_and_set builtin for ARM that generates a SWP i
--- Comment #6 from longb at cray dot com 2007-09-12 21:05 ---
Subject: Re: GFORTRAN OPTIMIZATION ERROR ABOVE -O0 FOR
MPICH2 TEST F90_RMA/BASEATTRWINF90.F90
sgk at troutmask dot apl dot washington dot edu wrote:
> --- Comment #5 from sgk at troutmask dot apl dot washington dot e
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-09-12 20:57 ---
I think this is the same issue as PR 33348. The shared RTX are the same and
the original RTX is the same type of RTX (I forgot to paste it into the bug
though).
-- Pinski
--
pinskia at gcc dot gnu dot org chang
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |blocker
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33389
--- 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
Component|bootstrap |target
Keywords||build, ice-on-
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
--- 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 gc
--- 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 #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
---
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 #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
input/output
--- 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 #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
Componen
[ 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 PROTECTED]:/src/delta
--- 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 of
--- 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;
re
--- 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;
regi
--- 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",
--- 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=14198&action=view)
Bad bar.s and bar.c.121t.optimized generated by revision 128239
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3338
--- 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=14197&action=view)
Good bar.s and bar.c.117t.optimized generated by revision 128238
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3338
--- 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 #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 #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 #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 #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 mal
--- 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=14196&action=view)
a.cpp
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33409
With the following command line:
[c:\hack]==► 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
--enable
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
CC||ebotcazou at gcc dot gnu dot
|
--- 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
--- 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=14195&action=view)
The fortran source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33408
--- 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
-prefix=/usr/local/gfortran --enable-languages=c,fortran
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
P
--- 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=gcc&view=rev&rev=128441
Log:
PR ada/26797
PR ada/32407
* uti
--- 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=gcc&view=rev&rev=128441
Log:
PR ada/26797
PR ada/32407
* util
--- 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 #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 verifi
--- 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 certainly
--- 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 #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 trunk
--- 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 #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:
:
# r_8 = PHI
# n_11 = PHI
# VUSE
D.11
--- 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
http://gcc.gnu.o
--- 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 #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 che
successes 4
# of expected failures 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
--- 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
--- 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
> l
--- 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:
> === l
--- 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.
>
> /home/rask/build/gcc-x86_
--- 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.
/home/rask/build/gcc-x86_64-unknown-linux-gnu/./prev-gcc/x
--- 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 #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 ===
# of
--- 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
cas
--- 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
Status|UNCONFIRMED
--- 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
Sta
--- 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: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:30 ---
Subject: Bug 33297
Author: burnus
Date: Wed Sep 12 10:30:22 2007
New Revision: 128424
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=128424
Log:
2007-09-12 Tobias Burnus <[EMAIL PROTECTED]>
PR fort
--- 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=gcc&view=rev&rev=128423
Log:
2007-09-12 Tobias Burnus <[EMAIL PROTECTED]>
PR fort
--- 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=gcc&view=rev&rev=128423
Log:
2007-09-12 Tobias Burnus <[EMAIL PROTECTED]>
PR fort
--- 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 #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 #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 #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
BugsThisDepend
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 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
--- 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
--
http://gcc.gnu.org/bugzilla/sh
--- 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 sin
--- 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 #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
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: UN
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
-I/home/mmalaterre/Projects/Insight/Util
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;i<100;i++)
out1[i+1] = out1[i]*in;
}
With O2 we generate at expand time -
fred (in, out1)
{
unsigned int ivtmp.24;
:
ivtmp.24 = (unsig
--- 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
Status|UNC
--- 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 #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 dot
--- 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=gcc&view=rev&rev=128419
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=gcc&view=rev&rev=128418
Log:
2007-09-12 Christopher D. Rickett <[EMAIL PROTECTED]>
--- 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=gcc&view=rev&rev=128417
Log:
2007-09-12 Richard Guenther <[EMAIL PROTECTED]>
PR
1 - 100 of 105 matches
Mail list logo
