These four failures were introduced recently and show up on both x86 and
amd64-linux.
PASS: Tue Feb 14 21:54:03 UTC 2006 (revision 110997)
FAIL: Feb 15 21:37:04 UTC 2006 (revision 18)
,.,. C43208B ACATS 2.5 06-02-16 05:25:54
C43208B CHECK THAT THE EVALUATION OF A MULTIDIMENSIONAL ARRAY
--- Comment #1 from ebotcazou at gcc dot gnu dot org 2006-02-16 08:45
---
These four failures were introduced recently and show up on both x86 and
amd64-linux.
Unfortunate, but confirmed. *sigh*
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed
--- Comment #11 from victork at gcc dot gnu dot org 2006-02-16 09:59
---
Subject: Bug 25918
Author: victork
Date: Thu Feb 16 09:59:00 2006
New Revision: 35
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=35
Log:
testsuite/
2006-02-16 Victor Kaplansky [EMAIL PROTECTED]
--
gcc at pcedev dot com changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |gcc at pcedev dot com
|dot org |
--- Comment #11 from pluto at agmk dot net 2006-02-16 10:41 ---
on 3.4.5 g++ also fails (but xgcc works).
Andrew, What you've checked in #c5, #c6 nad #c7 ?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26230
--- Comment #2 from gcc at pcedev dot com 2006-02-16 10:47 ---
The problem comes from the choice of the constructor during the deserialization
process. Up to now, the first non abstract, non serializable constructor in the
super classes were choosen. So it incorrectly skipped all
__attribute__ ((noinline))
void
bar (int i)
{
asm volatile ( : : r (i));
}
struct S
{
int v;
struct S *w;
};
__attribute__ ((noinline))
void
foo (struct S *s, int l)
{
for (; s; s = s-w)
{
if (s-v (l 6 || l 17))
bar (1);
switch (l)
{
case 6:
--- Comment #6 from ebotcazou at gcc dot gnu dot org 2006-02-16 10:55
---
The test doesn't pass on SPARC/Solaris (this is with 4.1):
At line 12 of file
/home/eric/svn/gcc-4_1-branch/gcc/testsuite/gfortran.dg/large_real_kind_form_io_2.f90
Fortran runtime error: Range error during
--
mark at gcc dot gnu dot org changed:
What|Removed |Added
Component|libgcj |classpath
Product|gcc |classpath
--- Comment #7 from fxcoudert at gcc dot gnu dot org 2006-02-16 11:12
---
OK, I think this is the same bug as reported on some ppc64-linux non-standard
builds. It has to deal with real(16), and is indeed the very same kind of
problem.
This is not a bug introduced by the patch, it just
--- Comment #8 from rguenth at gcc dot gnu dot org 2006-02-16 11:31 ---
I can reproduce this on i586-pc-linux-gnu with -Os -mrtd. As analyzed, the
failure occours with -mrtd if a call to memcpy is generated. The following
testcase fails for me with -mrtd and passes without it for
--- Comment #12 from pinskia at gcc dot gnu dot org 2006-02-16 12:22
---
(In reply to comment #11)
on 3.4.5 g++ also fails (but xgcc works).
Andrew, What you've checked in #c5, #c6 nad #c7 ?
g++ the installed version.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26230
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||wrong-code
Summary|loop-invariant miscompiles |[4.2
Bellow is the source code, command line and error report which I have come
accross. Tester is a nonsense package to demonstrate the problem, it appears
only to fail when reading the array value but when assigning to the array it
works fine.
I have also seen this failure in version 3.4.2 (GNAT
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-02-16 12:29 ---
Milestone should be 4.0.3 pre agreement with GDR and Mark.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Bellow is the source code, command line and error report which I have come
accross. Tester is a nonsense package to demonstrate the problem, it appears
only to fail when reading the array value but when assigning to the array it
works fine.
I have also seen this failure in version 3.4.2 (GNAT
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-16 12:40 ---
*** This bug has been marked as a duplicate of 26317 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-16 12:40 ---
*** Bug 26318 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26317
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-02-16 12:43 ---
Fixed in 4.1.0 and above.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-16 12:50 ---
Confirmed but it might be that the memory load is not marked as being able to
trap so move invariants is moving it above the loop.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #7 from rakdver at gcc dot gnu dot org 2006-02-16 12:52 ---
No, that patch does not fix the problem. It is however the same type of
problem -- vectorizer not updating virtual operands properly (I had tried to
find all places in vectorizer where this could happen in that
--- Comment #2 from jakub at gcc dot gnu dot org 2006-02-16 12:57 ---
It doesn't need to be marked as trapping.
If you have
if (idx = 20)
val = p[idx];
you certainly can't change this into:
tmp = p[idx];
if (idx = 20)
val = tmp;
except if tmp = p[idx]; is speculative load
--- Comment #3 from rakdver at atrey dot karlin dot mff dot cuni dot cz
2006-02-16 12:59 ---
Subject: Re: [4.2 Regression] loop-invariant miscompiles openmp.c
It doesn't need to be marked as trapping.
If you have
if (idx = 20)
val = p[idx];
you certainly can't change this
--- Comment #8 from danglin at gcc dot gnu dot org 2006-02-16 13:08 ---
Subject: Bug 26255
Author: danglin
Date: Thu Feb 16 13:08:01 2006
New Revision: 36
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=36
Log:
PR target/26255
* pa.md: Create separate HI
--- Comment #4 from jakub at gcc dot gnu dot org 2006-02-16 13:11 ---
The MEM is marked as MEM_NOTRAP_P, by do_tablejump - gen_const_mem.
Still, IMHO you can't do that, otherwise we couldn't mark any MEM
as MEM_NOTRAP_P unless it has constant operand. If a particular array
will not
--- Comment #3 from ben dot midgley at ultra-datel dot com 2006-02-16
13:13 ---
Subject: RE: Accessing array embedded in a record with
representation clause
Hello Pinskia,
I have raised this report this morning against gcc-4.2.0 which your
response seems to indicate should not
--- Comment #10 from rguenth at gcc dot gnu dot org 2006-02-16 13:22
---
The problem is that we do not honour the override decl for memcpy simply
because
for expand_call (foo(i, st);) we end up in emit_block_move_via_libcall which
builds yet another memcpy decl via
--- Comment #11 from rguenth at gcc dot gnu dot org 2006-02-16 13:25
---
The problem is we cannot simply use (implicit_)built_in_decl[BUILT_IN_MEMCPY]
here
either because that one is still the internal one, and if annotating our memcpy
decl with __attribute__((__cdecl__)) we warn:
--- Comment #12 from rguenth at gcc dot gnu dot org 2006-02-16 13:34
---
A similar issue is in PR11772 - we fail to account for -mrtd when expanding
calls to builtin functions or functions from libgcc.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22017
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-02-16 13:35 ---
(In reply to comment #4)
The MEM is marked as MEM_NOTRAP_P, by do_tablejump - gen_const_mem.
Still, IMHO you can't do that, otherwise we couldn't mark any MEM
as MEM_NOTRAP_P unless it has constant operand. If a
--- Comment #13 from rguenth at gcc dot gnu dot org 2006-02-16 13:36
---
It all looks like a mess wrt -mrtd, I'm not going to touch this.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22017
--- Comment #6 from rakdver at gcc dot gnu dot org 2006-02-16 13:38 ---
Sadly, Jakub is probably right -- since the very beginning, MEM_NOTRAP_P was
used to mean that the mem cannot trap in its current context. This makes
MEM_NOTRAP_P completely useless as far as code motion is
--- Comment #4 from ben dot midgley at ultra-datel dot com 2006-02-16
13:41 ---
Subject: RE: Accessing array embedded in a record with
representation clause
Appologies just re-read, paying attention this time.
-Original Message-
From: pinskia at gcc dot gnu dot org
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-02-16 13:42 ---
http://gcc.gnu.org/ml/gcc/2005-09/msg00021.html
There are most likely other talk here too.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26316
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-02-16 13:47 ---
/* Generate a memory referring to non-trapping constant memory. */
Which might mean that do_tablejump is using it wrong.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26316
--- Comment #9 from rakdver at gcc dot gnu dot org 2006-02-16 13:53 ---
Given that do_tablejump was the very first setter of MEM_NOTRAP_P, it is not
likely that it would be the wrong one (unless all other setters that came later
chose the other possible semantics).
--
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-02-16 13:54
---
The NOTRAP was added when PR 8866 was fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from pinskia at gcc dot gnu dot org 2006-02-16 13:57
---
Thread for the PR 8866 fix:
http://gcc.gnu.org/ml/gcc-patches/2003-04/msg01438.html
Though I am wondering why do people think it could not trap because it can if
it was moved. Seems like NoTrap is useless in
--- Comment #5 from P dot Schaffnit at access dot rwth-aachen dot de
2006-02-16 14:08 ---
Created an attachment (id=10862)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10862action=view)
Sources which exhibit this behaviour (under 32-bit linux)
Hi!
Here's something that exhibits
--- Comment #6 from eedelman at gcc dot gnu dot org 2006-02-16 14:12
---
With Philippe's testcase, I can reproduce the problem on my system now.
--
eedelman at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from reichelt at gcc dot gnu dot org 2006-02-16 14:12
---
Confirmed.
Even simpler testcase (crashes with gcc -mno-80387):
===
long double foo(long double x) { return x; }
===
--
--- Comment #27 from gdr at gcc dot gnu dot org 2006-02-16 14:54 ---
see comment #12.
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #26 from gdr at integrable-solutions dot net 2006-02-16 14:52
---
Subject: Re: --enable-languages=c,c++ not working as expected, documented
pinskia at gcc dot gnu dot org [EMAIL PROTECTED] writes:
| GDR you commented on this before:
|
--- Comment #28 from pinskia at gcc dot gnu dot org 2006-02-16 15:09
---
(In reply to comment #24)
Since Ben is removing directories in the first place, this is the reason why
this is invalid and not because gnattools is being built even with
--enable-language=c++.
Again this has
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-02-16 15:12 ---
I don't know if this is really valid code as long double on x86_64 uses 387 so
turning off 387 explicitly says no 387 instructions. In fact I think the
regression was caused by actually -mno-387 working correctly
--- Comment #25 from gdr at integrable-solutions dot net 2006-02-16 14:49
---
Subject: Re: --enable-languages=c,c++ not working as expected, documented
pinskia at gcc dot gnu dot org [EMAIL PROTECTED] writes:
| How would you guys design this?
That was explained in the several
--- Comment #4 from amylaar at gcc dot gnu dot org 2006-02-16 15:13 ---
Mark, why isn't this marked as a regression? Before this patch:
http://gcc.gnu.org/ml/gcc-patches/2004-03/msg01422.html ,
we rather erred on the side of copying too much and possibly aborting.
Now we silently
Hello gcc-bugs,
# gcc -O3 z.adb
gcc -O3 z.adb
+===GNAT BUG
DETECTED==+
| 3.3.5 (Debian 1:3.3.5-13) (i486-pc-linux-gnu) Gigi abort, Code=116
|
| Error detected at crypto-types-big_numbers.ads:309:41
|
| Please submit
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-02-16 15:19 ---
(In reply to comment #4)
Mark, why isn't this marked as a regression?
Most likey because I and others did not notice it was a regression and could
not tell from either the patch or the bug report it was.
--
--- Comment #14 from rakdver at gcc dot gnu dot org 2006-02-16 15:23
---
Subject: Bug 26209
Author: rakdver
Date: Thu Feb 16 15:23:24 2006
New Revision: 38
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=38
Log:
PR tree-optimization/26209
* tree-ssa-loop.c
--- Comment #15 from rakdver at gcc dot gnu dot org 2006-02-16 15:25
---
Now fixed also in 4.1.
--
rakdver at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from walter dot zimmer at dlr dot de 2006-02-16 15:28
---
(In reply to comment #6)
Here is a newer patch which fixes it:
I didn't look (or even understand) what the patch does, but I can contribute
empirical evidence that the following construct:
SUBROUTINE FOO
--- Comment #29 from gdr at gcc dot gnu dot org 2006-02-16 15:30 ---
(In reply to comment #28)
(In reply to comment #24)
Since Ben is removing directories in the first place, this is the reason why
this is invalid and not because gnattools is being built even with
--- Comment #4 from pluto at agmk dot net 2006-02-16 15:32 ---
(In reply to comment #3)
I don't know if this is really valid code as long double on x86_64 uses 387 so
turning off 387 explicitly says no 387 instructions. In fact I think the
regression was caused by actually -mno-387
--- Comment #30 from pinskia at gcc dot gnu dot org 2006-02-16 15:37
---
(In reply to comment #29)
Again this bug is about removing two directories and then trying to build
You're totally confused. The bug really is about components being built
when they are not asked for.
--- Comment #5 from rakdver at gcc dot gnu dot org 2006-02-16 15:47 ---
Subject: Bug 26296
Author: rakdver
Date: Thu Feb 16 15:47:20 2006
New Revision: 39
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=39
Log:
PR rtl-optimization/26296
* Makefile.in
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-02-16 15:50 ---
There's a similar issue with trying to override certain builtins calling
convention with -mrtd in effect. Consider
extern void* __attribute__((__cdecl__)) memcpy(void*, void*, __SIZE_TYPE__);
we even after
--- Comment #14 from rguenth at gcc dot gnu dot org 2006-02-16 15:50
---
Reading the documentation for '-mrtd' I'm tempted to close this as invalid.
The
user is changing the ABI while still linking to libraries with a different ABI.
The fact that overriding builtins is not possible
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-02-16 15:50 ---
*** Bug 22017 has been marked as a duplicate of this bug. ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #31 from gdr at integrable-solutions dot net 2006-02-16 15:53
---
Subject: Re: --enable-languages=c,c++ not working as expected, documented when
removing gcc/ada and libada but not gnattools
pinskia at gcc dot gnu dot org [EMAIL PROTECTED] writes:
| (In reply to comment
--- Comment #32 from gdr at gcc dot gnu dot org 2006-02-16 15:53 ---
.
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
Last reconfirmed|2006-02-16 15:30:19
--- Comment #33 from gdr at gcc dot gnu dot org 2006-02-16 15:56 ---
.
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
Status|RESOLVED
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
Summary|--enable-languages=c,c++ not|toplevel
PR 26259 raises a semi valid concern but it was not written correctly in the
first place which is why it was closed so I am opening this new one to explain
what is going on.
Toplevel directories are sometimes associated with languages via
gcc/language/config-lang.in but that associated and be
--- Comment #34 from pinskia at gcc dot gnu dot org 2006-02-16 16:11
---
This bug was orginally opened and not really explaining what happened until
comment #2 and even then it was really You tell the doctor, it hurts when I do
this and the doctor explains, do not that then. The
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-16 16:11 ---
*** Bug 26259 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #35 from pinskia at gcc dot gnu dot org 2006-02-16 16:11
---
(In reply to comment #34)
This is a dup of bug 26323 which explains what really wants to be changed
instead of going in circles of the current correct [documented] behavior.
--
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-02-16 16:17 ---
Also I should point out this is not documented in the user manual because well
users should not be deleting directories. It is documented in the internals
manual, maybe not as big as it should be but it is there.
--
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
--- Comment #11 from sayle at gcc dot gnu dot org 2006-02-16 16:45 ---
Subject: Bug 16787
Author: sayle
Date: Thu Feb 16 16:45:49 2006
New Revision: 45
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=45
Log:
2006-02-16 Roger Sayle [EMAIL PROTECTED]
R. Scott
--- Comment #6 from ebotcazou at gcc dot gnu dot org 2006-02-16 17:37
---
Fixed by Zdenek.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from ebotcazou at gcc dot gnu dot org 2006-02-16 17:37
---
Unfortunate, but confirmed. *sigh*
OK, they all fail at -O0 too, so it's very likely a front-end problem.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26315
--- Comment #12 from pinskia at gcc dot gnu dot org 2006-02-16 17:43
---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #12 from pinskia at gcc dot gnu dot org 2006-02-16 17:43
---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-02-16 17:44 ---
powerpc-darwin has the failure and it supports 128bit long double by default.
powerpc64-linux does not which is why I am removing it from the target.
--
pinskia at gcc dot gnu dot org changed:
What
--- Comment #8 from rakdver at gcc dot gnu dot org 2006-02-16 17:53 ---
This seems somewhat more complicated than I thought -- vectorizer actually does
not touch the statement with changed vops, it just clobbers alias info somehow
so that we are adding vops for it we did not before. I
When GCC is configured with --prefix=/opt/gnu/gcc/gcc-4.1.0,
libgnarl and libgnat are installed in
/opt/gnu/gcc/gcc-4.1.0/lib/gcc/hppa2.0w-hp-hpux11.11/4.1.0/adalib. libgcc_s.sl
is in /opt/gnu/gcc/gcc-4.1.0/lib.
-bash-2.05b$ chatr libgnat-4.1.sl
libgnat-4.1.sl:
shared library
--- Comment #14 from dberlin at gcc dot gnu dot org 2006-02-16 19:46
---
So uh, has anyone figured out why we don't get 1500 with -fno-tree-pre?
Does -fno-gcse help too?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21485
--- Comment #5 from steven at gcc dot gnu dot org 2006-02-16 19:51 ---
Silly question maybe, but why is reg-stack doing anything at all if -mno-80387?
Before reg-stack we have,
(insn 26 12 27 3 (set (mem/c:XF (plus:DI (reg/f:DI 6 bp)
(const_int -16
--- Comment #6 from steven at gcc dot gnu dot org 2006-02-16 19:58 ---
Ignore my comment #5, I mis-grep-ed the insn uids :-/
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26223
I've few memory leaks to report and they are as follows,
ipa-inline.c in function cgraph_early_inlining. pointer 'order'
tree-if-conv.c infunction combine_blocks, returned memory.
loop-unroll.c in function referenced_in_one_insn_in_loop_p, pointer 'body'
cfgloop.c in function cancel_loop, pointer
--- Comment #3 from steven at gcc dot gnu dot org 2006-02-16 20:09 ---
Do we know if this bug is still present?
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from steven at gcc dot gnu dot org 2006-02-16 20:10 ---
There was a question almost a year and a half ago, asking whether this bug is
fixed now. The question so far remains unanswered?
--
steven at gcc dot gnu dot org changed:
What|Removed
--- Comment #11 from nathan at gcc dot gnu dot org 2006-02-16 20:12 ---
Is this still an issue in 4.1/4.2. IIUC I've cleaned up the points where this
warning was/was not being emitted.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17519
--- Comment #13 from sayle at gcc dot gnu dot org 2006-02-16 20:15 ---
Subject: Bug 16787
Author: sayle
Date: Thu Feb 16 20:15:10 2006
New Revision: 47
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=47
Log:
2006-02-16 Roger Sayle [EMAIL PROTECTED]
R. Scott
--- Comment #14 from pinskia at gcc dot gnu dot org 2006-02-16 20:17
---
And for 4.0.3 now.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target
--- Comment #8 from steven at gcc dot gnu dot org 2006-02-16 20:04 ---
One and a half year without any activity -- what's up with this bug?
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--
Summary: Timouts in libgomp tests with --with-long-double-128
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgomp
AssignedTo: unassigned at gcc dot gnu dot org
--- Comment #2 from sje at cup dot hp dot com 2006-02-16 20:40 ---
This header worked with GCC 3.* but 4.0 is pickier about having an array of an
unknown type. I will submit a fixincludes patch to fix the header.
--
sje at cup dot hp dot com changed:
What|Removed
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-16 20:41 ---
First --with-long-double-128 does nothing on Darwin.
Second this is a dup of bug 25978.
*** This bug has been marked as a duplicate of 25978 ***
--
pinskia at gcc dot gnu dot org changed:
What
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-02-16 20:41 ---
*** Bug 26328 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-02-16 21:17 ---
Comment #0 and #2 are fixed now by:
2006-02-16 Daniel Berlin [EMAIL PROTECTED]
* tree-ssa-operands.c (access_can_touch_variable): Fix typo in
previous change.
2006-02-15 Daniel Berlin [EMAIL
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.2.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14705
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-02-16 21:25 ---
Fixed by Daniel's patches.
We get now:
bb 2:
D.1542 = xmalloc ((long unsigned int) n_basic_blocks * 4);
e = frob ();
D.1544 = e-dest;
D.1545 = D.1544-flags;
if ((D.1545 4) == 0) goto L0; else goto L1;
--- Comment #12 from jakub at gcc dot gnu dot org 2006-02-16 21:31 ---
Subject: Bug 26316
Author: jakub
Date: Thu Feb 16 21:31:20 2006
New Revision: 52
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=52
Log:
* openmp.c (resolve_omp_clauses): Add a dummy case label
--- Comment #1 from jakub at gcc dot gnu dot org 2006-02-16 21:35 ---
Subject: Bug 26224
Author: jakub
Date: Thu Feb 16 21:35:38 2006
New Revision: 53
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=53
Log:
PR fortran/26224
* parse.c (parse_omp_do,
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-02-16 21:40 ---
We get:
# bitmap_free_7 = PHI bitmap_free_1(4), bitmap_free_6(5);
L0:;
# bitmap_free_1 = PHI bitmap_free_7(3), bitmap_free_2(2);
L4:;
# VUSE bitmap_free_1;
D.1534_4 = head_3-using_obstack;
if (D.1534_4
If there is an ambiguity with the namespace resolution, the 3.4/4.0 compiler
error message is very unclear while it was much better in 3.3 (and even 2.95):
% cat ns.cpp
namespace NsOut { namespace NsIn { struct Foo { }; } }
namespace NsIn { struct Foo { }; }
using namespace NsOut;
void
Using floats, floor() returns wrong result, as shown in this program:
( BTW, using gcc 4.0.1 )
#include cmath
#include iostream
int
main()
{
floatx( 3.31682e-7 );
floaty( -292.608 );
floatz( 19.5072 );
std::cout Using floats, floor() returns the wrong result:
1 - 100 of 126 matches
Mail list logo
