If the following code is compiled with -Os for ARM or ColdFire, the exit
condition for the loop is removed.
Replacing *tbl++ with tbl[i] or using unsigned long instead of volatile
unsigned long does not show the problem.
I suspect the post-increment optimization to be the problem, because the
Power
--- Comment #1 from burnus at gcc dot gnu dot org 2009-07-08 07:36 ---
I can reproduce the ICE with 4.1, 4.2 and 4.3 - but it no longer gives an ICE
with 4.4 or 4.5.
* * *
However, there is also a bug in 4.4: It simply compiles.
Expected: Either an error of the form (NAG f95)
Error
--- Comment #10 from burnus at gcc dot gnu dot org 2009-07-08 08:00 ---
I think one can consider supporting non-signed zeros as extension, similar to
ifort which has:
-assume nominus0The compiler uses Fortran 90/77 standard
semantics in the
Sent from my iPhone
On Jul 8, 2009, at 12:32 AM, "bastian dot schick at sciopta dot com" > wrote:
If the following code is compiled with -Os for ARM or ColdFire, the
exit
condition for the loop is removed.
Replacing *tbl++ with tbl[i] or using unsigned long instead of
volatile
unsigned
--- Comment #1 from pinskia at gmail dot com 2009-07-08 08:13 ---
Subject: Re: New: Optimizer handles loops with volatiles and post-incr. wrong
Sent from my iPhone
On Jul 8, 2009, at 12:32 AM, "bastian dot schick at sciopta dot com"
wrote:
> If the following code is compiled with
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-07-08 08:21 ---
patches should be sent to gcc-patc...@gcc.gnu.org with a changelog entry
and a note how it was tested.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40677
--- Comment #2 from bastian dot schick at sciopta dot com 2009-07-08 08:24
---
(In reply to comment #1)
>
> Sent from my iPhone
Oh, dude (which one :-)
> On Jul 8, 2009, at 12:32 AM, "bastian dot schick at sciopta dot com"
> > wrote:
>
> > If the following code is compiled with -O
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-07-08 08:25 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #3 from ramana at gcc dot gnu dot org 2009-07-08 08:49 ---
On trunk with -fno-tree-vrp I see the correct code being generated.
bs:
@ Function supports interworking.
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
--- Comment #4 from bastian dot schick at sciopta dot com 2009-07-08 09:06
---
(In reply to comment #3)
> On trunk with -fno-tree-vrp I see the correct code being generated.
It seems to be related to Bug #30785 (test for null pointer).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?
--- Comment #3 from rubidium at openttd dot org 2009-07-08 09:12 ---
I cannot reproduce this error anymore in gcc-lto (lto merged with rev 149291)
4.5.0 20090706 (experimental) revision 149340.
However... I don't have the setup I've ran the previous test on, as such I have
build it with
--- Comment #5 from ramana at gcc dot gnu dot org 2009-07-08 09:12 ---
Richi,
Can you comment on this one ?
Ramana
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
-
Compile the attached source code with options -Os -mthumb -march=armv5te, gcc
generates:
push{r3, r4, r5, lr}
.LCFI0:
mov r4, r0
ldr r0, [r0]
bl _Z3foof
ldr r1, [r4, #4]
@ sp needed for prologue
add r5, r0, #0
--- Comment #1 from carrot at google dot com 2009-07-08 09:36 ---
Created an attachment (id=18155)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18155&action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40680
--- Comment #3 from pault at gcc dot gnu dot org 2009-07-08 09:48 ---
Well. I suppose that I should accept the bug :-)
I will commit the fix to 4.4 over the weekend, so please try to test it to
destruction on 4.5.
Paul
--
pault at gcc dot gnu dot org changed:
What
--- Comment #6 from mikpe at it dot uu dot se 2009-07-08 09:59 ---
(In reply to comment #2)
> Replacing *tbl++ by tbl[i] gives this ARM code:
> .L2:
> mov r3, #10
> str r3, [r2], #4
> cmp r2, #0
> bne .L2
> bx lr
>
> See, gcc
--- Comment #2 from ramana at gcc dot gnu dot org 2009-07-08 10:00 ---
However Confirmed with trunk for Thumb1. The extra move doesn't appear for ARM
or Thumb2 .
The code below is what is generated for Thumb2 or ARM .
.type _ZN3CCC5funcAEv, %function
_ZN3CCC5funcAEv:
--- Comment #1 from ramana at gcc dot gnu dot org 2009-07-08 10:01 ---
Can you attach a pre-processed file for someone to look at this ? This bug
report seems incomplete.
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #7 from rguenth at gcc dot gnu dot org 2009-07-08 10:10 ---
Indeed the overflow invokes undefined behavior.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #3 from Thomas dot Lange at sun dot com 2009-07-08 10:23
---
(In reply to comment #2)
> why don't you add a 'virtual'
> to your destructor and int f(int) functions, because they are implicitly
> virtual anyway'.
That is exactly the point this is about!
I want a way so the c
--- Comment #4 from Thomas dot Lange at sun dot com 2009-07-08 10:30
---
Side note: Of course having such an option is much more useful where the
declaration of class A and B are in different header files and probably even in
different modules.
(For example: such cases are often found
Bug in lto revision 149340 (gcc 4.5 revision 149291 works fine)
The used command line:
/usr/local/lto/bin/g++-lto -v -save-temps -O2 -fomit-frame-pointer -flto -DUNIX
-Wall -Wno-multichar -Wsign-compare -Wundef -Wwrite-strings -Wpointer-arith
-Wno-uninitialized -W -Wno-unused-parameter -Wformat=2
--- Comment #1 from rubidium at openttd dot org 2009-07-08 10:42 ---
Created an attachment (id=18156)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18156&action=view)
The .ii file of save-temps
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40681
--- Comment #6 from hp at gcc dot gnu dot org 2009-07-08 10:47 ---
(In reply to comment #0)
If it's just about the version, perhaps you can make -V working again.
Requires a working --enable-version-specific-runtime-libs of course. :)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4
--- Comment #7 from hp at gcc dot gnu dot org 2009-07-08 10:49 ---
(In reply to comment #6)
> If it's just about the version, perhaps you can make -V working again.
Oh same version. Change the above to "make -b working again".
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40458
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfir
In a recent discussion on comp.std.c++
"rvalue references returned from a function",
as pointed by Niels Dekker and Micael Dark,
a defect report:
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#391
was accepted into C++0x WP. This has a significant impact on GCC.
The current behav
--- Comment #4 from bje at gcc dot gnu dot org 2009-07-08 11:15 ---
Reported as fixed by the original submitter.
--
bje at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from sezeroz at gmail dot com 2009-07-08 11:37 ---
Will there be a backport of this to the branches 4.3 and 4.4?
--
sezeroz at gmail dot com changed:
What|Removed |Added
---
--- Comment #1 from paolo dot carlini at oracle dot com 2009-07-08 11:41
---
Note, in general work on C++0x features doesn't really belong to Bugzilla,
unless existing code crashes on new testcases, things like that. You understand
that in general the situation would otherwise quickly e
--- Comment #4 from dominiq at lps dot ens dot fr 2009-07-08 11:47 ---
It seems that gfortran.dg/proc_ptr_21.f90 is failing on i686-pc-linux-gnu and
Intel64(?), see
http://gcc.gnu.org/ml/gcc-testresults/2009-07/msg00755.html
http://gcc.gnu.org/ml/gcc-regression/2009-07/msg00078.html
-
--- Comment #3 from bje at gcc dot gnu dot org 2009-07-08 11:49 ---
This is fixed in lto revision 149354. I ran make check-gcc and watched /tmp.
Temporary files were removed as the testsuite ran.
--
bje at gcc dot gnu dot org changed:
What|Removed
--- Comment #10 from kkojima at gcc dot gnu dot org 2009-07-08 11:54
---
I don't think this is a regression, unfortunately.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30807
--- Comment #5 from burnus at gcc dot gnu dot org 2009-07-08 12:37 ---
(In reply to comment #4)
> It seems that gfortran.dg/proc_ptr_21.f90 is failing on i686-pc-linux-gnu and
> Intel64(?), see
I can - somewhat - reproduce it. It does not fail but valgrind shows
(x86-64-linux and i686-l
--- Comment #2 from dragan at plusplus dot co dot yu 2009-07-08 12:38
---
Although this is a feature request in the context that the old behavior
was correctly implemented and it will be different in C++0x, it still presents
a bug in the current C++0x implementation. It creates copies o
--- Comment #3 from paolo dot carlini at oracle dot com 2009-07-08 12:47
---
To be clear, I'm not telling you anything specific about the development
process. Actually, that's exactly the point, this is ongoing development of
experimental features, no guarantees, no guarantees of perfec
--- Comment #8 from bastian dot schick at sciopta dot com 2009-07-08 13:06
---
(In reply to comment #6)
> (In reply to comment #2)
> > Replacing *tbl++ by tbl[i] gives this ARM code:
> > .L2:
> > mov r3, #10
> > str r3, [r2], #4
> > cmp r2, #0
> >
--- Comment #9 from rguenth at gcc dot gnu dot org 2009-07-08 13:11 ---
induction variable optimization is different w/o volatile.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40679
On Linux/ia32, revision 149362 gave
FAIL: gfortran.dg/proc_ptr_21.f90 -O1 execution test
FAIL: gfortran.dg/proc_ptr_21.f90 -O2 execution test
FAIL: gfortran.dg/proc_ptr_21.f90 -O3 -fomit-frame-pointer execution test
FAIL: gfortran.dg/proc_ptr_21.f90 -O3 -fomit-frame-pointer -funroll-all-loo
--- Comment #3 from pault at gcc dot gnu dot org 2009-07-08 13:22 ---
Created an attachment (id=18157)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18157&action=view)
Fix for bug - not regtested yet
This handles host_assoc_function_*.f90 correctly but is not yet regtested.
The t
--- Comment #5 from manu at gcc dot gnu dot org 2009-07-08 13:25 ---
(In reply to comment #3)
>
> Note that getInt is completely inlined and there is no location involving
> that function available anymore :/ The difficulties of C++ and late
> diagnostics ...
Don't we keep abstract_or
--- Comment #1 from dominiq at lps dot ens dot fr 2009-07-08 13:28 ---
See pr40591 comments #4 and #5.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40683
--- Comment #8 from manu at gcc dot gnu dot org 2009-07-08 13:28 ---
I am going to close this as FIXED, since it cannot be reproduced anymore. If
anyone manages to reproduce it in GCC 4.5, please reopen.
--
manu at gcc dot gnu dot org changed:
What|Removed
--- Comment #6 from pault at gcc dot gnu dot org 2009-07-08 13:28 ---
(In reply to comment #5)
> That is solved by adding:
>i = 0
> to subroutine test (while any other number causes the abortion).
>
Indeed - that was in the test originally; I do not know what happened to it.
I'll
--- Comment #2 from pault at gcc dot gnu dot org 2009-07-08 13:29 ---
(In reply to comment #1)
> See pr40591 comments #4 and #5.
>
Indeed! I'll fix it tonight.
Thanks, HJ
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #7 from dominiq at lps dot ens dot fr 2009-07-08 13:31 ---
pr40683 is a duplicate.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40591
--- Comment #4 from hjl at gcc dot gnu dot org 2009-07-08 14:30 ---
Subject: Bug 40557
Author: hjl
Date: Wed Jul 8 14:30:12 2009
New Revision: 149371
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149371
Log:
2009-07-08 H.J. Lu
Backport from mainline:
2009-0
--- Comment #11 from burnus at gcc dot gnu dot org 2009-07-08 14:55 ---
Created an attachment (id=18158)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18158&action=view)
Patch - lightly tested
Attached patch fixes the problem [independent of
"-f(no-)signed-zeros"/-ffast-math].
Th
--- Comment #4 from edmar at freescale dot com 2009-07-08 15:06 ---
I did not run any test suite, nor prepared any test case suitable for inclusion
in dejagnu suite.
I opened a bug hopping the information I gave would help resolve the issue
faster.
--
http://gcc.gnu.org/bugzilla/sho
// { dg-options "-std=c++0x" }
struct A
{
};
template
typename S::A
foo (S c, T t, U u)
{
}
struct B
{
struct C
{
template
C (U t)
{
A a;
A b = foo (this, a, t);
}
} c;
B () : c (A ())
{
}
};
int
main ()
{
B f;
}
ICEs in tsubst (seeing ADDR_EXPR ther
The following testcase fails on g++ 4.4.0 and 4.3.2:
#include
enum Enum {
Foo
};
class A
{
public:
A(int y) : x(y) {}
explicit A(Enum) : x(1) {}
int x;
};
static void fun(A a = Foo)
{
if (a.x != static_cast(Foo)) {
abort();
}
}
int main()
{
--- Comment #16 from rth at gcc dot gnu dot org 2009-07-08 16:41 ---
Subject: Bug 38900
Author: rth
Date: Wed Jul 8 16:41:23 2009
New Revision: 149373
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149373
Log:
PR target/38900
* config/i386/i386.h (CONDITIONAL_RE
--- Comment #7 from mikpe at it dot uu dot se 2009-07-08 16:43 ---
4.4-20090630 plus this fix bootstrapped fine, fixed the test case, built a
working 2.6.31-rc2 Linux kernel, and built a working Erlang VM.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40668
--- Comment #12 from kargl at gcc dot gnu dot org 2009-07-08 16:49 ---
Created an attachment (id=18160)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18160&action=view)
dejagnu testr case
Test that sign(x, +-0) conforms to F95.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4
--- Comment #13 from kargl at gcc dot gnu dot org 2009-07-08 16:50 ---
Created an attachment (id=18161)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18161&action=view)
dejagnu test case
Test case for sign(x,+-0) when the new -fno-sign-zero option is used.
--
http://gcc.gnu.o
--- Comment #14 from kargl at gcc dot gnu dot org 2009-07-08 16:56 ---
(In reply to comment #11)
> Created an attachment (id=18158)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18158&action=view) [edit]
> Patch - lightly tested
>
> Attached patch fixes the problem [independent of
--- Comment #17 from rth at gcc dot gnu dot org 2009-07-08 16:59 ---
Subject: Bug 38900
Author: rth
Date: Wed Jul 8 16:59:15 2009
New Revision: 149374
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149374
Log:
PR target/38900
* config/i386/i386.h (CONDITIONAL_RE
--- Comment #18 from rth at gcc dot gnu dot org 2009-07-08 17:03 ---
Fixed.
--
rth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #3 from janis at gcc dot gnu dot org 2009-07-08 17:08 ---
I can reproduce the error with plugin.exp not struct-layout-1.exp. This fixes
it for me, does it for you guys?
Index: gcc/testsuite/lib/gcc.exp
===
---
--- Comment #8 from blp at cs dot stanford dot edu 2009-07-08 17:30 ---
Wow, that's amazingly fast turnaround. Thanks so much guys!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40668
--- Comment #4 from tjruwase at google dot com 2009-07-08 17:59 ---
Subject: Re: [4.5 Regression] Errors in "make -k
check-gcc RUNTESTFLAGS=plugin.exp"
Your fix works for me.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40625
--- Comment #1 from mark at gcc dot gnu dot org 2009-07-08 18:08 ---
Subject: Bug 40659
Author: mark
Date: Wed Jul 8 18:07:47 2009
New Revision: 149377
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149377
Log:
2009-07-08 Mark Wielaard
PR debug/40659
* dwarf
Our HDF5 software has been having some data conversion problem with GCC's
optimization for a few years. One example is to convert data from short to
int. You can find the program at
ftp://ftp.hdfgroup.uiuc.edu/pub/outgoing/slu/tmp/ctest.c
When I use "gcc -O2" or "gcc -O3" to compile it, I get
--- Comment #2 from mark at gcc dot gnu dot org 2009-07-08 18:21 ---
Patch pushed.
--
mark at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIR
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-07-08 18:22 ---
You are violating C/C++ aliasing rules:
d = (uint8_t*)&aligned;
/* This line causes the trouble. */
*((int*)d) = (int)(*((short*)s));
You are writing into a long long via an int which
--- Comment #142 from pinskia at gcc dot gnu dot org 2009-07-08 18:22
---
*** Bug 40686 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pault at gcc dot gnu dot org 2009-07-08 19:00 ---
Subject: Bug 40683
Author: pault
Date: Wed Jul 8 19:00:17 2009
New Revision: 149383
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149383
Log:
2008-07-08 Paul Thomas
PR fortran/40683
* gfo
--- Comment #4 from pault at gcc dot gnu dot org 2009-07-08 19:05 ---
(In reply to comment #3)
> Created an attachment (id=18157)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18157&action=view) [edit]
> Fix for bug - not regtested yet
>
> This handles host_assoc_function_*.f90 co
--- Comment #15 from burnus at gcc dot gnu dot org 2009-07-08 19:35 ---
Subject: Bug 40675
Author: burnus
Date: Wed Jul 8 19:34:49 2009
New Revision: 149390
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149390
Log:
2009-07-08 Tobias Burnus
PR fortran/40675
--- Comment #3 from aapo dot rantalainen at gmail dot com 2009-07-08 19:36
---
Above code doesn't compile:
int main(int argc, char *argv[])
{
int a=1;
switch (a)
{
case 1:
int b=2;
break;
}
return 0;
}
Error "a label can only be part of a statement and a declara
--- Comment #4 from pinskia at gcc dot gnu dot org 2009-07-08 19:42 ---
(In reply to comment #3)
> Above code doesn't compile:
Yes it should not be compile. The error message has been improved to tell you
what the problem is (that is what Manu was saying in his comment #2).
--
htt
--- Comment #8 from janis at gcc dot gnu dot org 2009-07-08 19:48 ---
Fixed awhile ago by changing -mabi=altivec to the default for powerpc*-linux.
--
janis at gcc dot gnu dot org changed:
What|Removed |Added
---
Hi,
I think there is a bug in g++ 4.4 concerning the implementation of auto.
7.1.6.4/7 in N2914
The following program compiles, but it should be rejected by g++.
int main()
{
auto i = 10, d = 5.0; // error! shall not compile in C++0x
return 0;
}
$ /opt/gcc-4.4/bin/g++ -v
Using built-
--- Comment #1 from bernhard dot merkle at googlemail dot com 2009-07-08
20:07 ---
Created an attachment (id=18162)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18162&action=view)
program which should not compile
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40687
--- Comment #1 from dodji at gcc dot gnu dot org 2009-07-08 20:11 ---
I could reproduce on trunk.
I am testing the patchlet below:
diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index b4bd465..d042f98 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -12949,8 +12949,9 @@ type_unification_real (tre
Hi,
I think there is another bug in g++ 4.4 concerning the implementation of auto
with direct and copy initialization 7.1.6.4/3 in N2914
The following program should compile, but is rejected by g++.
int main()
{
auto v1 = 1; // copy initialization syntax
auto v2(2); // direct initializ
--- Comment #1 from bernhard dot merkle at googlemail dot com 2009-07-08
20:16 ---
Created an attachment (id=18163)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18163&action=view)
program which should compile
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40688
Hi,
I think there is a bug in g++ 4.4 concerning the implementation of initializer
list. N2672
The following program does not compiles, but it should be accepted by g++.
// /opt/gcc-4.4/bin/g++ --std=c++0x -Wall
int main()
{
class X
{
public:
X(): data {1,2,3,4,5} {}
private:
const sho
--- Comment #1 from bernhard dot merkle at googlemail dot com 2009-07-08
20:29 ---
Created an attachment (id=18164)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18164&action=view)
program which should compile
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40689
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-07-08 20:38 ---
Before filing more bugs please verify the bugs exist on a recent version
of the development trunk for GCC 4.5. C++0x is considered incomplete
technology preview only.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi
On powerpc*-unknown-linux-gnu several vectorization tests ICE in verify_stmts
after the error message "invalid conversion in gimple call":
gcc.dg/vect/no-scevccp-outer-7.c
gcc.dg/vect/no-scevccp-outer-13.c
gcc.dg/vect/slp-perm-1.c
gcc.dg/vect/slp-perm-2.c
gcc.dg/vect/slp-perm-3
--- Comment #4 from janis at gcc dot gnu dot org 2009-07-08 20:46 ---
On powerpc*-linux this test begins failing in the same way with this patch:
http://gcc.gnu.org/viewcvs?view=rev&rev=146831
r146831 | rguenth | 2009-04-27 11:18:38 + (Mon, 27 Apr 2009)
--
http://gcc.g
--- Comment #2 from janis at gcc dot gnu dot org 2009-07-08 20:46 ---
On powerpc*-linux the test begins to fail in the same way with this patch:
http://gcc.gnu.org/viewcvs?view=rev&rev=146831
r146831 | rguenth | 2009-04-27 11:18:38 + (Mon, 27 Apr 2009)
--
http://gcc.gn
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-07-08 20:49 ---
I think this is really PR 30210.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40690
--- Comment #16 from burnus at gcc dot gnu dot org 2009-07-08 20:55 ---
Close as FIXED (on the trunk [= 4.5]).
Greg, thanks for the report. Using a 4.5/trunk build (e.g. one of the nightly
builds) gfortran will offer the option -fno-sign-zero which allows your
program to work.
However
--- Comment #3 from bernhard dot merkle at googlemail dot com 2009-07-08
20:56 ---
makes sense, thanks for the hint.
is there doc to which N papers the 4.5 trunk relates ?
e.g. like http://gcc.gnu.org/projects/cxx0x.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40689
Use of operator! (logical not) from valarray with slice fails. For example,
--
#include
void test01()
{
const std::valarray vi(12);
std::valarray vb1(12);
std::valarray vb2(3);
std::slice s(0,3,4);
vb1 = !vi;
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-07-08 21:03 ---
It is.
*** This bug has been marked as a duplicate of 30210 ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #15 from rguenth at gcc dot gnu dot org 2009-07-08 21:03
---
*** Bug 40690 has been marked as a duplicate of this bug. ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #17 from gdsjaar at sandia dot gov 2009-07-08 21:03 ---
Subject: Re: Support -fnosign-zero for SIGN
intrinsic for Fortran 77 compatibility
Thanks for the quick response. I agree that the ultimate fix is to
remove that idiom from the code; however, when dealing with decad
--- Comment #16 from rguenth at gcc dot gnu dot org 2009-07-08 21:04
---
Mike - you said you have patches for this?
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-07-08 21:05 ---
I don't think so. Likely nobody bothered to update that document recently.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40689
--- Comment #5 from janis at gcc dot gnu dot org 2009-07-08 21:28 ---
The test started failing with the patch reported in comment #8 because it
enabled type checking; sorry for the noise.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39959
--- Comment #3 from janis at gcc dot gnu dot org 2009-07-08 21:29 ---
The test started failing with the patch reported in comment #2 because it
enabled type checking; sorry for the noise.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39960
--- Comment #5 from manu at gcc dot gnu dot org 2009-07-08 21:34 ---
(In reply to comment #4)
> (In reply to comment #3)
> > Above code doesn't compile:
>
> Yes it should not be compile. The error message has been improved to tell you
> what the problem is (that is what Manu was saying
--- Comment #20 from pthaugen at gcc dot gnu dot org 2009-07-08 21:53
---
Created an attachment (id=18165)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18165&action=view)
Reduced testcase
The attatched testcase exhibits the problem with the load-hit-store. It's
resulting from ch
--- Comment #5 from manu at gcc dot gnu dot org 2009-07-08 22:08 ---
Are there some cases where a declaration such T x = y can be considered an use
of 'x' by itself?
The following patch warns for this, but it also produces warnings for some
testcases in the testsuite.
Index: gcc/cp/ini
Linux kernel, in particularly xen-blkfront.c, doesn't compile with GCC trunk.
4.5.0 20090625 was still fine, 4.5.0 20090630 is already wrong.
Simplified testcase:
#define M1(x) (((x) & 0x0002) ? 0x2 : ((x) & 0x1))
#define M2(x) (((x) & 0x000c) ? M1 ((x) >> 2) << 2 : M1 (x))
struct A { cha
--- Comment #1 from janis at gcc dot gnu dot org 2009-07-08 22:27 ---
Subject: Bug 40691
Author: janis
Date: Wed Jul 8 22:26:50 2009
New Revision: 149393
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149393
Log:
PR libstdc++/40691
* include/bugs/valarray-after.
--- Comment #1 from jakub at gcc dot gnu dot org 2009-07-08 23:09 ---
Caused by r149060. Will debug tomorrow.
Alternative testcase that doesn't warn about VLA at file scope:
#define M1(x) (((x) & 0x0002) ? 0x2 : ((x) & 0x1))
#define M2(x) (((x) & 0x000c) ? M1 ((x) >> 2) << 2 : M
1 - 100 of 132 matches
Mail list logo
