Vincent Lefevre wrote:
On 2009-08-04 15:44:05 -0700, Joe Buck wrote:
But AFAIK neither Posix nor the C89 standard nor the C99 standard
say anything about -D and -U flags. It's the Single UNIX specification
that is the issue, and it refers to a command that is spelled c89,
or (in later
On 2009-08-05 10:07:49 +0100, Dave Korn wrote:
GCC does not install an executable called c99. Or one called
c89. So what any standard requires of them is irrelevant to us,
except that we would want to make it possible to support that mode
of operation. And we do; with our predictable
Vincent Lefevre wrote:
On 2009-08-05 10:07:49 +0100, Dave Korn wrote:
GCC does not install an executable called c99. Or one called
c89. So what any standard requires of them is irrelevant to us,
except that we would want to make it possible to support that mode
of operation. And we do; with
Well, this is what happened to me:
libtool: link: /gnu/gcc/obj-patched-gnat2/./gcc/xgcc
-B/gnu/gcc/obj-patched-gnat
2/./gcc/ -B/opt/gcc-tools/i686-pc-cygwin/bin/
-B/opt/gcc-tools/i686-pc-cygwin/li
b/ -isystem /opt/gcc-tools/i686-pc-cygwin/include -isystem
/opt/gcc-tools/i686-p
2009/8/5 Jim Wilson wil...@codesourcery.com:
On Tue, 2009-08-04 at 11:09 +0530, Mohamed Shafi wrote:
i am not able to implement the alignment for short.
The following is are the macros that i used for this
#define PARM_BOUNDARY 8
#define STACK_BOUNDARY 64
The target is 32bit . The first
On Wed, 5 Aug 2009, Dave Korn wrote:
to integrate this behaviour into the driver. Perhaps we could even do the old
behave-differently-according-to-argv[0] trick, although I'm not sure if that
isn't slightly discouraged these days.
The proper thing is to build a separate driver binary
On Tue, Aug 04, 2009 at 05:58:05PM -0700, Vincent Lefevre wrote:
On 2009-08-04 15:44:05 -0700, Joe Buck wrote:
But AFAIK neither Posix nor the C89 standard nor the C99 standard
say anything about -D and -U flags. It's the Single UNIX specification
that is the issue, and it refers to a
I believe that I could legitimately approve that patch myself (it's
pretty trivial and I didn't author it), but I'd prefer to get approval
from one of the SPARC maintainers. Here's your chance:
http://gcc.gnu.org/ml/gcc-patches/2009-04/msg01027.html
OK.
--
Eric Botcazou
From: Eric Botcazou ebotca...@adacore.com
Date: Wed, 5 Aug 2009 17:59:01 +0200
I believe that I could legitimately approve that patch myself (it's
pretty trivial and I didn't author it), but I'd prefer to get approval
from one of the SPARC maintainers. Here's your chance:
Hi,
Please someone change the status of these bug reports to be available in the
search engine of bugtracker:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40819
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40977
Thanks
Regards
On Wed, Aug 5, 2009 at 11:14 PM, ami_stuffami_st...@o2.pl wrote:
Hi,
Please someone change the status of these bug reports to be available in the
search engine of bugtracker:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40819
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40977
?
You have to
Hi,
You have to be more specific on what you refer to with search engine
of bugtracker.
http://gcc.gnu.org/bugzilla/query.cgi
Sorry, these bugs are available for search, but not with m68k keyword.
Maybe this can be fixed.
Regards
On Wed, Aug 5, 2009 at 11:25 PM, ami_stuffami_st...@o2.pl wrote:
Hi,
You have to be more specific on what you refer to with search engine
of bugtracker.
http://gcc.gnu.org/bugzilla/query.cgi
Sorry, these bugs are available for search, but not with m68k keyword.
Maybe this can be fixed.
Hi,
Ok, I didn't use advenced search. Problem solved.
Regards
On Jul 25, 2009, at 12:54 PM, Paolo Bonzini wrote:
Am i missing something?
No, it is a bug due to the build-with-C++ patches. Please file a
PR and, in the meanwhile, try --enable-stage1-languages=c,c++ or --
enable-build-with-cxx.
I filed PR40950 for this.
I also filed PR40968 for
--- Comment #10 from bonzini at gnu dot org 2009-08-05 06:09 ---
preprocessed testcase?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40952
--- Comment #1 from burnus at gcc dot gnu dot org 2009-08-05 07:19 ---
Works for me on x86-64-linux and seems also to work on several other systems
according to the testresults mailing list.
(Only failure - your ia64 system:
http://gcc.gnu.org/ml/gcc-testresults/2009-08/msg00487.html)
--- Comment #3 from burnus at gcc dot gnu dot org 2009-08-05 08:00 ---
Regarding gfc_copy_attr: The following program should print on x86-64(-linux)
the warnings:
warning: 'dllexport' attribute directive ignored
warning: 'stdcall' attribute directive ignored
abstract interface
--- Comment #2 from pault at gcc dot gnu dot org 2009-08-05 08:41 ---
(In reply to comment #1)
Works for me on x86-64-linux and seems also to work on several other systems
according to the testresults mailing list.
Works for me too at revision 150482 on x86_64/FC9
Cheers
Paul
--
--- Comment #1 from pault at gcc dot gnu dot org 2009-08-05 08:57 ---
* expr.c (simplify_const_ref)
* symbol.c (gfc_set_default_type, generate_isocbinding_symbol)
These two produce leaks.
* trans-decl.c (create_function_arglist)
This is OK - the new cl is threaded into the list.
--- Comment #3 from manu at gcc dot gnu dot org 2009-08-05 10:01 ---
By the way, we would prefer a preprocessed testcase, as minimal as possible.
See http://gcc.gnu.org/bugs.html#report
Thanks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39757
--- Comment #9 from jwakely dot gcc at gmail dot com 2009-08-05 10:03
---
This example has four slightly different errors:
struct B {};
struct D : B {};
struct X {};
int foo(B*);
int i = foo( (B*)0 );
int j = foo( (D*)0 );
D* pd = 0;
int k = foo( pd );
X* px = 0;
int l = foo(
--- Comment #4 from jv244 at cam dot ac dot uk 2009-08-05 10:11 ---
(In reply to comment #3)
The code generation of Graphite can be exponential, didn't I mentioned
it yet?
however, I'm relatively certain that I tested graphite when it was introduced
in 4.4, and it didn't impact
--- Comment #2 from manu at gcc dot gnu dot org 2009-08-05 10:16 ---
At the moment the parser detects and reports the error, it doesn't know that it
is parsing an array subscript. We could test for typical errors before trying
to parse the expression but that would pessimize valid code.
--- Comment #5 from jv244 at cam dot ac dot uk 2009-08-05 10:59 ---
Checked against the 4.4 branch, with the following timings:
4.4 w/o1.79
w 1.80
4.5 w/o4.23
w144.30
--
jv244 at cam dot ac dot uk changed:
What|Removed
--- Comment #2 from janus at gcc dot gnu dot org 2009-08-05 11:27 ---
(In reply to comment #1)
* trans-decl.c (create_function_arglist)
This is OK - the new cl is threaded into the list.
Actually I think that this is not done properly. The code in question is:
--- Comment #3 from janus at gcc dot gnu dot org 2009-08-05 11:44 ---
The code from trans-decl.c (create_function_arglist) cited in comment #2 was
committed by Tobias as r148517 just a few weeks ago, as a fix for PR 40383.
Tobias, do you remember any of your thoughts when writing this?
--- Comment #2 from abnikant dot singh at atmel dot com 2009-08-05 11:52
---
It compiles fine with both avr-gcc-4.3.3 and avr-gcc-4.4.0
--
abnikant dot singh at atmel dot com changed:
What|Removed |Added
--- Comment #2 from abnikant dot singh at atmel dot com 2009-08-05 11:56
---
gcc.c-torture/compile/pr32606.c compiles fine with both avr-gcc-4.3.3 and
avr-gcc-4.4.0
--
abnikant dot singh at atmel dot com changed:
What|Removed |Added
Following wrong code compiles and executes properly with 'g++ -Wall -O2', but
compiles and terminates with std::bad_alloc() 'g++ -Wall'. In both cases
expected behaviour would have been an error from compiler stating that it is
not possible to initialize a const long with a const double . gcc
--- Comment #21 from manu at gcc dot gnu dot org 2009-08-05 12:09 ---
Are there any failing testcases for this PR? Perhaps we can turn this into a
meta-bug, or if there are no testcases right now, it would be better to close
it (we have already enough open PRs).
--
--- Comment #1 from paolo dot carlini at oracle dot com 2009-08-05 12:25
---
This is just triggering undefined behavior: after the constructor call dim is
bound to a temporary long created on the fly from the double _dim, which
disappears by the time newValue is called. Nothing to do
--- Comment #2 from paolo dot carlini at oracle dot com 2009-08-05 12:29
---
Oh, you just want a warning for this. Indeed, ICC spills one with -Wall. Maybe
Manuel has an opinion...
--
paolo dot carlini at oracle dot com changed:
What|Removed
--- Comment #3 from paolo dot carlini at oracle dot com 2009-08-05 12:34
---
Eh, eh...
*** This bug has been marked as a duplicate of 986 ***
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #24 from paolo dot carlini at oracle dot com 2009-08-05 12:34
---
*** Bug 40970 has been marked as a duplicate of this bug. ***
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #6 from jakub at gcc dot gnu dot org 2009-08-05 12:36 ---
Subject: Bug 40924
Author: jakub
Date: Wed Aug 5 12:36:34 2009
New Revision: 150483
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=150483
Log:
PR rtl-optimization/40924
* dse.c (canon_address):
--- Comment #4 from burnus at gcc dot gnu dot org 2009-08-05 12:50 ---
(In reply to comment #3)
Tobias, do you remember any of your thoughts when writing this?
Well, they are essentially written in the patch email (linked from the PR
40383):
--- Comment #7 from jakub at gcc dot gnu dot org 2009-08-05 12:54 ---
Subject: Bug 40924
Author: jakub
Date: Wed Aug 5 12:54:21 2009
New Revision: 150484
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=150484
Log:
PR rtl-optimization/40924
* dse.c (canon_address):
--- Comment #8 from jakub at gcc dot gnu dot org 2009-08-05 12:55 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #25 from manu at gcc dot gnu dot org 2009-08-05 13:21 ---
If anyone has any hint on where this could be caught, suggestions are welcome.
The explanation of Alexandre Oliva in comment #8 is totally obscure to me and
perhaps outdated given the age of this PR.
--
manu at
--- Comment #5 from janus at gcc dot gnu dot org 2009-08-05 13:21 ---
(In reply to comment #4)
(In reply to comment #3)
Tobias, do you remember any of your thoughts when writing this?
Well, they are essentially written in the patch email (linked from the PR
Yeah, ok, the general
--- Comment #10 from jason at redhat dot com 2009-08-05 13:42 ---
Subject: Re: Error message about no matching function for
call with derived class arguments could be improved
On 08/04/2009 06:42 PM, manu at gcc dot gnu dot org wrote:
I don't even know if we have different codepaths
--- Comment #4 from manu at gcc dot gnu dot org 2009-08-05 13:55 ---
What happens when a function must have a particular return type because it is
accessed through a pointer, but we want to mark it as noreturn?
Example: gcc/java/jcf.h (jcf_unexpected_eof)
I am not sure this warning is
What changed from 4.4 to 4.5 is that we now get to compile larger
SCoPs with Graphite. In 4.5, Graphite can deal with reductions and
other unhandled constructs like the NE_EXPR that Fortran is frequently
using for representing the exit condition of DO loops.
--- Comment #6 from sebpop at gmail dot com 2009-08-05 14:04 ---
Subject: Re: [4.5 Regression][graphite] slow
compilation
What changed from 4.4 to 4.5 is that we now get to compile larger
SCoPs with Graphite. In 4.5, Graphite can deal with reductions and
other unhandled
--
spop at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |spop at gcc dot gnu dot org
|dot org
extern void bar (char *);
void
foo (int f, long a)
{
{
char d[32768];
bar (d);
}
double b = f;
while (a)
{
char c[8];
__builtin_memcpy (c, b, sizeof (c));
if (*(double *) c != 2.0)
break;
}
}
ICEs on powerpc-linux when compiled with -O -m32
--- Comment #3 from uros at gcc dot gnu dot org 2009-08-05 14:42 ---
Subject: Bug 40906
Author: uros
Date: Wed Aug 5 14:41:54 2009
New Revision: 150486
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=150486
Log:
PR target/40906
* config/i386/i386.c
This prevents the build of libgomp.dll for example:
*** Warning: linker path does not have real file for library -lpthread.
*** I have the capability to make that library automatically link in when
*** you link to this library. But I can only do this if you have a
*** shared version of the
We should consider marking module procedures with PRIVATE attribute as STATIC
(in the C sense) such that they can be eliminated. In the following program,
two could be optimized away as it cannot be called from outside the module.
However, this does not happen with
gfortran -O3 -c test.f90
--- Comment #6 from pault at gcc dot gnu dot org 2009-08-05 16:10 ---
Subject: Bug 40847
Author: pault
Date: Wed Aug 5 16:10:19 2009
New Revision: 150493
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=150493
Log:
2009-08-05 Paul Thomas pa...@gcc.gnu.org
PR
--- Comment #1 from jakub at gcc dot gnu dot org 2009-08-05 16:24 ---
I don't believe this is a valid OpenMP testcase.
The standard says:
The behavior is unspecified if any intermediate result required to compute the
iteration count cannot be represented in the type determined above.
--- Comment #7 from ramana at gcc dot gnu dot org 2009-08-05 16:42 ---
Invalid testcase as per comment #6.
(In reply to comment #4)
I see the same problem when I try to compile transmission release 1.73. The
error happens with file libtransmission/fdlimit.c. Works till -O1 but fails
I'm using a gcc-4.4.1 cross-compiler to build another instance of gcc-4.4.1 for
the target system. make fails with the following error message:
make[2]: Entering directory
`/mnt/clfs/sources/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3'
make AR_FLAGS=rc CC_FOR_BUILD=gcc
--- Comment #3 from jwakely dot gcc at gmail dot com 2009-08-05 16:40
---
c.f isn't even valid, it should be C::f
I didn't check the code, but that message isn't used for member variables or
nested types, so if it does only apply to member functions then I think
changing '' to '()'
--- Comment #7 from pinskia at gcc dot gnu dot org 2009-08-05 17:52 ---
Created an attachment (id=18307)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18307action=view)
Patch which I am testing
This patch fixes the problem including a+1 and a+2 not aliasing each other.
It adds two
--- Comment #4 from bangerth at gmail dot com 2009-08-05 17:54 ---
(In reply to comment #3)
c.f isn't even valid, it should be C::f
I didn't check the code, but that message isn't used for member variables or
nested types, so if it does only apply to member functions then I think
--- Comment #5 from bangerth at gmail dot com 2009-08-05 17:57 ---
However, one of my gripes with the previous error message is that it's
just too obscure: where did I forget the '', and why would I have wanted
to write them in the first place? It could have said did you forget to
take
--- Comment #3 from hjl dot tools at gmail dot com 2009-08-05 18:04 ---
A patch is posed at
http://gcc.gnu.org/ml/gcc-patches/2009-08/msg00277.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #4 from uros at gcc dot gnu dot org 2009-08-05 18:05 ---
Subject: Bug 40906
Author: uros
Date: Wed Aug 5 18:04:42 2009
New Revision: 150497
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=150497
Log:
PR target/40906
* config/i386/i386.c
Using array new as a default initializer of a constructor argument, when the
object being newed itself contains a constructor, crashes the compiler with
an error similar to the following:
% g++ -c gcc_bug.cpp
gcc_bug.cpp:13: internal compiler error: in copy_tree_r, at
tree-inline.c:3160
--- Comment #6 from manu at gcc dot gnu dot org 2009-08-05 18:19 ---
Examples where the ampersand probably makes more sense are:
g++.dg/rtti/typeid8.C
g++.dg/conversion/memfn2.C
g++.old-deja/g++.other/asm2.C
Not so sure about:
g++.dg/template/pseudodtor3.C
g++.dg/template/using14.C
--- Comment #2 from brian dot e dot bliss at intel dot com 2009-08-05
18:46 ---
My interpretation of that rule is that this is a legal testcase as long as ub
is even at runtime. If ub is odd, then the behavior is undefined.
Anyway - that is a subject for bug 39495. What I'm trying
--- Comment #7 from bangerth at gmail dot com 2009-08-05 18:47 ---
(In reply to comment #6)
Examples where the ampersand probably makes more sense are:
g++.dg/rtti/typeid8.C
g++.dg/conversion/memfn2.C
g++.old-deja/g++.other/asm2.C
Possibly, but in all those cases, it may also
--- Comment #4 from hjl dot tools at gmail dot com 2009-08-05 18:47 ---
A patch is posted at
http://gcc.gnu.org/ml/gcc-patches/2009-08/msg00284.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #3 from hjl dot tools at gmail dot com 2009-08-05 18:58 ---
(In reply to comment #1)
Works for me on x86-64-linux and seems also to work on several other systems
according to the testresults mailing list.
(Only failure - your ia64 system:
--- Comment #4 from kargl at gcc dot gnu dot org 2009-08-05 19:06 ---
(In reply to comment #3)
(In reply to comment #1)
Works for me on x86-64-linux and seems also to work on several other systems
according to the testresults mailing list.
(Only failure - your ia64 system:
--- Comment #5 from hjl dot tools at gmail dot com 2009-08-05 19:07 ---
(gdb) bt
#0 0xa0010621 in __kernel_syscall_via_break ()
#1 0x203e7630 in raise () from /lib/tls/libc.so.6.1
#2 0x203ea010 in abort () from /lib/tls/libc.so.6.1
#3 0x400014b0 in
--- Comment #6 from hjl dot tools at gmail dot com 2009-08-05 19:09 ---
21if ( a1 != *a2 ) abort();
(gdb) p a1
$1 = 0
(gdb) p *a2
$2 = 42
(gdb)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40969
--- Comment #7 from hjl dot tools at gmail dot com 2009-08-05 19:22 ---
When we see
external f_to_f, i_to_i, c_to_c
external f_to_f8, i_to_i8, c_to_c8
and do
typelist = gfc_chainon_list (typelist, void_type_node);
Later, we see
call f_to_f (b, %VAL (a), %REF (c),
--- Comment #8 from hjl dot tools at gmail dot com 2009-08-05 19:28 ---
(In reply to comment #7)
When we see
external f_to_f, i_to_i, c_to_c
external f_to_f8, i_to_i8, c_to_c8
and do
typelist = gfc_chainon_list (typelist, void_type_node);
Later, we see
--- Comment #9 from burnus at gcc dot gnu dot org 2009-08-05 19:33 ---
(In reply to comment #6)
21if ( a1 != *a2 ) abort();
(gdb) p a1
$1 = 0
(gdb) p *a2
$2 = 42
Thanks! I think the following patch should cure this. I think we will still
have issues with LTO but those are
Motivated by PR 40969.
Currently, we generate a function declaration for
procedure(empty or interface) :: proc
and another one for
call proc(something) ! or var = proc(something)
If no explicit interface is known, the function argument is undefined, which
causes problems with LTO, cf. PR
--- Comment #10 from hjl dot tools at gmail dot com 2009-08-05 19:49
---
(In reply to comment #9)
Thanks! I think the following patch should cure this. I think we will still
have issues with LTO but those are inevitable and need to be solved on the
middle end.
Index:
--- Comment #11 from hjl dot tools at gmail dot com 2009-08-05 19:52
---
This patch works:
--- ./trans-types.c.foo 2009-08-05 07:26:53.0 -0700
+++ ./trans-types.c 2009-08-05 12:51:00.0 -0700
@@ -2324,7 +2324,10 @@ gfc_get_function_type (gfc_symbol * sym)
while
--- Comment #12 from burnus at gcc dot gnu dot org 2009-08-05 20:03 ---
(In reply to comment #10)
It failed at a different place:
61if ( c1 != *c2) abort();
(gdb) p c1
$1 = 43 + 0 * I
(gdb) p *c2
$2 = -1 + 2 * I
Hmm, I honestly have no idea why this fails. In my
--- Comment #8 from janus at gcc dot gnu dot org 2009-08-05 20:25 ---
I guess I'll take over then. Got a patch.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
Hi,
When I compile source code with GCC 4.4.1 (-m68060 -O3 -fomit-frame-pointer):
#include stdint.h
#define umul_ppmm(xh, xl, a, b) \
__asm__ (| Inlined umul_ppmm\n \
move%.l %2,%/d0\n \
Motivated by PR 40969. See also PR 40976.
For functions where the result is returned by argument, one should use C++'s
named return value optimization (NRV),
cf. http://en.wikipedia.org/wiki/Return_value_optimization
That presumably also allows to mark PURE functions which return their result
--- Comment #13 from burnus at gcc dot gnu dot org 2009-08-05 20:36 ---
(In reply to comment #11)
This patch works:
+ if (typelist || sym-attr.if_source != IFSRC_UNKNOWN)
+typelist = gfc_chainon_list (typelist, void_type_node);
That patch essentially undoes the patch of PR
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |burnus at gcc dot gnu dot
|dot org
--- Comment #1 from burnus at gcc dot gnu dot org 2009-08-05 20:43 ---
See also vaguely related PR 40978.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from burnus at gcc dot gnu dot org 2009-08-05 20:47 ---
Subject: Bug 40949
Author: burnus
Date: Wed Aug 5 20:47:19 2009
New Revision: 150500
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=150500
Log:
2009-08-05 Tobias Burnus bur...@net-b.de
PR
--- Comment #14 from burnus at gcc dot gnu dot org 2009-08-05 20:47 ---
Subject: Bug 40969
Author: burnus
Date: Wed Aug 5 20:47:19 2009
New Revision: 150500
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=150500
Log:
2009-08-05 Tobias Burnus bur...@net-b.de
PR
--- Comment #9 from jamborm at gcc dot gnu dot org 2009-08-05 20:51 ---
The long-dead declaration is brought back to life by the following
line in gimplify_var_or_parm_decl() in gimplify.c:
tree value_expr = DECL_VALUE_EXPR (decl);
I don't know why that happens yet.
--
--- Comment #6 from burnus at gcc dot gnu dot org 2009-08-05 20:51 ---
Patch broke IA64 and was reverted (cf. 40969). Proper fix is PR 40976 which
should solve several of the remaining LTO problems as well.
--
burnus at gcc dot gnu dot org changed:
What|Removed
--- Comment #15 from burnus at gcc dot gnu dot org 2009-08-05 20:52 ---
FIXED by reverting the bug.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from uros at gcc dot gnu dot org 2009-08-05 21:17 ---
Subject: Bug 40906
Author: uros
Date: Wed Aug 5 21:16:52 2009
New Revision: 150501
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=150501
Log:
PR target/40906
* config/i386/i386.c
--- Comment #6 from ubizjak at gmail dot com 2009-08-05 21:19 ---
Fixed.
--
ubizjak at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #11 from sje at cup dot hp dot com 2009-08-05 21:36 ---
Created an attachment (id=18308)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18308action=view)
C++ test case that fails with plausible patch
This is cut down from libstdc++-v3 sources. I am not sure it is
--- Comment #1 from paolo dot carlini at oracle dot com 2009-08-05 22:26
---
You should try to figure out the reason of those errors: whether, for some
reason, _GLIBCXX_HAVE_FENV_H is undefined, thus fenv.h is not included in
tr1/cfenv. Or, the configure test for the facilities in
--- Comment #1 from mikpe at it dot uu dot se 2009-08-05 22:42 ---
I can reproduce this ICE on i686-linux with gcc-4.3-20090802 and
gcc-4.4-20090804. gcc-4.5 has some nasty new build requirements for c++ so I
didn't try it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40975
--- Comment #12 from bonzini at gnu dot org 2009-08-05 23:09 ---
Created an attachment (id=18309)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18309action=view)
another patch
This failure is related to NRV, which is why there is no C failure.
If I take care of it the patch is
The Polyhedron 2005 induct benchmark averages 12.44 seconds run-time when
compiled with...
gfortran -ffast-math -funroll-loops -msse3 -O3 induct.f90 -o induct
but averages 20.2 seconds when compiled with -fgraphite-identity added to the
compilation flags.
This issue remains after...
)
ivtmp.1799_745 = PHI var.1825_744(157), D.2584_20(158)
air.f90:1064:0: internal compiler error: verify_stmts failed
Using built-in specs.
Target: x86_64-apple-darwin10
Configured with: ../gcc-4.5-20090805/configure --prefix=/sw
--prefix=/sw/lib/gcc4.5 --mandir=/sw/share/man --infodir=/sw/share/info
--
spop at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |spop at gcc dot gnu dot org
|dot org
--- Comment #1 from spop at gcc dot gnu dot org 2009-08-06 00:26 ---
This makes me think that Tobias' regtester does not test the polyhedron
benchmarks in the extra tests, or it does not report anymore the failures.
I will investigate this issue.
--
spop at gcc dot gnu dot org
This error doesn't occur with...
gfortran -O2 -fgraphite-identity aermod.f90 -o aermod
..or...
gfortran -O2 -fgraphite-identity -floop-interchange aermod.f90 -o aermod
Using built-in specs.
Target: x86_64-apple-darwin10
Configured with: ../gcc-4.5-20090805/configure --prefix=/sw
--prefix=/sw/lib
--
spop at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |spop at gcc dot gnu dot org
|dot org
-4.5-20090805/configure --prefix=/sw
--prefix=/sw/lib/gcc4.5 --mandir=/sw/share/man --infodir=/sw/share/info
--enable-languages=c,c++,fortran,objc,java --with-gmp=/sw
--with-libiconv-prefix=/sw --with-ppl=/sw --with-cloog=/sw --with-system-zlib
--x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6
1 - 100 of 105 matches
Mail list logo
