Im trying to install GCC 4.4.0 (i tried also with: gcc-4.3.3) my configure is:
../gcc-4.4.0/configure --enable-shared --enable-threads=gnat
--enable-__cxa_atexit --enable-clocale=gnu --enable-languages=c,ada
--prefix=/opt/gnu-gcc/gcc-4.4.0 --with-gmp=/usr --with-mpfr=/usr/local
--enable-libada --wi
--- Comment #2 from jakub at gcc dot gnu dot org 2009-07-09 05:54 ---
Can't reproduce.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40693
--- Comment #10 from bje at gcc dot gnu dot org 2009-07-09 05:52 ---
(In reply to comment #8)
> I tried with the 'trunk' (instead of 'lto') and found the same issue.
I really don't think this is a bug with the lto branch. If you still think
it's a problem on trunk, then please re-open
--- Comment #4 from bje at gcc dot gnu dot org 2009-07-09 05:39 ---
The original ICE has now been replaced with:
$ ./xgcc -B. -flto -shared acosh.o acosl.o
lto1: internal compiler error: in lto_read_file_options, at lto-opts.c:348
Please submit a full bug report,
with preprocessed sourc
--- Comment #3 from bje at gcc dot gnu dot org 2009-07-09 05:38 ---
On powerpc-linux, the original ICE has been replaced with:
$ ./xgcc -B. -flto -shared ctanf.o ctanhl.o ctanh.o
lto1: internal compiler error: in lto_read_file_options, at lto-opts.c:348
Please submit a full bug report,
--- Comment #2 from bje at gcc dot gnu dot org 2009-07-09 05:10 ---
Rainer, can you please re-check this against the tip of the lto branch and
report back? Thanks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39025
--- Comment #5 from bje at gcc dot gnu dot org 2009-07-09 05:09 ---
Building with --with-libelf is the right approach. I don't think it works 100%
correctly, though, so I will take this bug and investigate.
--
bje at gcc dot gnu dot org changed:
What|Removed
--
bje at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed
--- Comment #2 from bje at gcc dot gnu dot org 2009-07-09 04:47 ---
Confirmed in lto revision 149393.
--
bje at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from bje at gcc dot gnu dot org 2009-07-09 04:43 ---
Confirmed in lto revision 149393.
--
bje at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from shane dot beasley at aleri dot com 2009-07-09 02:55
---
I should add that I boiled this down from a much larger specimen that had all
the copy constructors and assignment operators. Here, I'm just using the
default ones. The problem exists in both cases.
--
http
Apologies if this is a duplicate, but I can't find another quite like this...
struct Class
{
// undefined
void Method();
};
template < typename w_type >
struct NoPtr
{
// inline
NoPtr( bool = false ) : m_ptr( 0 ) { }
// inline; calls a method
~NoPtr() { if ( m_ptr ) m_pt
--- Comment #9 from jvdelisle at gcc dot gnu dot org 2009-07-09 02:02
---
Fixed.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSI
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2009-07-09 02:01
---
Fixed on trunk.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
St
--- Comment #36 from jvdelisle at gcc dot gnu dot org 2009-07-09 01:59
---
Fixed on trunk.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
S
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2009-07-09 01:55
---
Subject: Bug 40662
Author: jvdelisle
Date: Thu Jul 9 01:54:47 2009
New Revision: 149399
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149399
Log:
2009-07-08 Jerry DeLisle
PR libfortran/40330
--- Comment #35 from jvdelisle at gcc dot gnu dot org 2009-07-09 01:55
---
Subject: Bug 40330
Author: jvdelisle
Date: Thu Jul 9 01:54:47 2009
New Revision: 149399
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149399
Log:
2009-07-08 Jerry DeLisle
PR libfortran/4033
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2009-07-09 01:20
---
Subject: Bug 40662
Author: jvdelisle
Date: Thu Jul 9 01:20:23 2009
New Revision: 149398
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149398
Log:
2009-07-08 Jerry DeLisle
PR libfortran/40330
--- Comment #34 from jvdelisle at gcc dot gnu dot org 2009-07-09 01:20
---
Subject: Bug 40330
Author: jvdelisle
Date: Thu Jul 9 01:20:23 2009
New Revision: 149398
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149398
Log:
2009-07-08 Jerry DeLisle
PR libfortran/4033
--- Comment #3 from jyasskin at gmail dot com 2009-07-09 00:57 ---
It does not reproduce with Ubuntu gcc-4.3. I didn't try 4.4. If anyone cares, I
submitted a workaround at
http://llvm.org/viewvc/llvm-project/llvm/trunk/include/llvm/Support/IRBuilder.h?r1=75084&r2=75083&pathrev=75084
whi
--- Comment #2 from paolo dot carlini at oracle dot com 2009-07-09 00:38
---
Before anything else, please make sure you can reproduce the issue with 4.3.x
or 4.4.x, because 4.2.x is not maintained anymore. Preferably, use an official
FSF release for that.
--
paolo dot carlini at ora
--- Comment #5 from paolo dot carlini at oracle dot com 2009-07-09 00:36
---
And again...
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #2 from paolo dot carlini at oracle dot com 2009-07-09 00:35
---
To be sure, let's CC Jason about these auto issues...
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #2 from paolo dot carlini at oracle dot com 2009-07-09 00:35
---
To be sure, let's CC Jason about these auto issues...
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #1 from bje at gcc dot gnu dot org 2009-07-09 00:15 ---
Falk, can you please check again with the tip of the lto branch? I don't have
access to an Alpha system to check for myself. Thanks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39108
--- Comment #2 from bje at gcc dot gnu dot org 2009-07-09 00:14 ---
Confirmed. The proposed fix is not correct, though, as the type of the first
argument to munmap _is_ void* according to POSIX.
--
bje at gcc dot gnu dot org changed:
What|Removed
--- Comment #6 from bje at gcc dot gnu dot org 2009-07-09 00:10 ---
Confirmed.
--
bje at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at
--- Comment #1 from m dot rosellini at f5 dot com 2009-07-09 00:10 ---
I forgot to add: You need to compile this with -O2 and -march=pentium.
The way that negative constants are handled in the code emitted for
__sync_blah_and_blah is incorrect when the pointer type is 64-bits and the
pl
--- Comment #17 from meissner at linux dot vnet dot ibm dot com 2009-07-08
23:42 ---
Subject: Re: [4.5 Regression] Altivec builtins have inaccurate return types
On Wed, Jul 08, 2009 at 09:04:03PM -, rguenth at gcc dot gnu dot org wrote:
>
>
> --- Comment #16 from rguenth at
--- Comment #1 from reid dot kleckner at gmail dot com 2009-07-08 23:14
---
I tried to create an attachment, but it won't take files over 1MB so I uploaded
the two files here:
http://web.mit.edu/rnk/www/buggycppfile.cpp
http://web.mit.edu/rnk/www/buggycppfile.ii
--
reid dot kleckner
I was compiling LLVM and Clang when I ran into this ICE. I found the failing
compile job and ran it again with -E to produce buggycppfile.cpp which fails to
compile. I then did the following as instructed in the bug reporting
instructions:
[...@knuckles CodeGen]$ g++ buggycppfile.cpp -o buggycpp
#include
#include
int
main(int ac, char *av[])
{
int64_t x;
int64_t like_a_constant = -1;
int64_t unlike_a_constant = -1;
if (ac == 0) unlike_a_constant = 5;
x = 0;
__sync_add_and_fetch(&x, like_a_constant);
printf("%016llx\n", x);
x = 0;
__sync_add_and_fet
--- 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
--- 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.
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 #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
--- 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 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 #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 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 #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 #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 #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 #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 #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
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 #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
--- 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 #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 #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 #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
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 #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
--- 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
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: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 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 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
--- 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
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 #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
---
--- 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 #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 #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 #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 #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 #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 #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 #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
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 #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
--- 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 #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 #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 #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 #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 #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 #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 #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 #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 #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
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()
{
// { 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
--- 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
--- 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 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 #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 #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 #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 #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 #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 #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 #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
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 #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
--- 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 #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 #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 #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 #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
1 - 100 of 132 matches
Mail list logo
