--- 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)
A
--- 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
su
--- 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.
T
--- 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 c
--- 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 |A
--- 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:
gfc
--- 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 er
--- 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).
--
http://gcc.gnu.or
--- 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 wi
--- 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 |Adde
--- 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=gcc&view=rev&rev=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):
http://gcc.gnu.org/ml/gcc-patches/2009-
--- 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=gcc&view=rev&rev=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 gc
--- 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 gen
--- 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 const
--
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 -fstack-prote
--- 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=gcc&view=rev&rev=150486
Log:
PR target/40906
* config/i386/i386.c (ix86_split_lo
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 librar
--- Comment #20 from hjl at gcc dot gnu dot org 2009-08-05 14:45 ---
Subject: Bug 40834
Author: hjl
Date: Wed Aug 5 14:45:15 2009
New Revision: 150487
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150487
Log:
2009-07-28 H.J. Lu
Backport from mainline:
2009-
--- Comment #14 from hjl at gcc dot gnu dot org 2009-08-05 14:45 ---
Subject: Bug 40570
Author: hjl
Date: Wed Aug 5 14:45:15 2009
New Revision: 150487
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150487
Log:
2009-07-28 H.J. Lu
Backport from mainline:
2009-
--- Comment #5 from pault at gcc dot gnu dot org 2009-08-05 14:47 ---
Created an attachment (id=18305)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18305&action=view)
A provisional patch for the PR
(In reply to comment #3)
> The real issue is that mold->expr_type is EXPR_VARIABLE
--- Comment #6 from janus at gcc dot gnu dot org 2009-08-05 14:50 ---
(In reply to comment #2)
> > * 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 following should fix it:
In
--- Comment #1 from rainer at emrich-ebersheim dot de 2009-08-05 14:51
---
The upstream fix is here:
http://git.savannah.gnu.org/cgit/libtool.git/commit/?id=b5282894cf194b878322bf2688bd90571bef1c69
Please, update the gcc version accordingly.
--
http://gcc.gnu.org/bugzilla/show_bug
--- Comment #1 from jakub at gcc dot gnu dot org 2009-08-05 14:56 ---
Created an attachment (id=18306)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18306&action=view)
gcc44-pr40971.patch
Patch I'm going to bootstrap/regtest.
--
jakub at gcc dot gnu dot org changed:
--- Comment #18 from uweigand at gcc dot gnu dot org 2009-08-05 14:59
---
(In reply to comment #16)
> Uli, can you please have a look at Richard's and Paolo's patches and does one
> or the other seem like a "better" fix?
I've yet another suggestion :-) See my message at:
http://gcc.g
--- Comment #7 from pault at gcc dot gnu dot org 2009-08-05 15:00 ---
I am not going to have time for this right now.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #2 from rainer at emrich-ebersheim dot de 2009-08-05 15:01
---
doesn't reproduce.
--
rainer at emrich-ebersheim dot de changed:
What|Removed |Added
--- Comment #8 from manu at gcc dot gnu dot org 2009-08-05 15:07 ---
OK, setting it back to NEW, but I don't have any idea about how to approach
this.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
-
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40971
--- Comment #2 from manu at gcc dot gnu dot org 2009-08-05 15:33 ---
Perhaps we could just mention both '&' and '()'? It seems a bit difficult to
check all the conditions that you mention.
BTW, shouldn't it say 'member function'? Can this be anything different than a
member function?
--- Comment #10 from manu at gcc dot gnu dot org 2009-08-05 16:01 ---
I think we should close this as WONTFIX.
* In GCC 4.5 we only warn at -O1 with a "may be", no warning with -O{0,2,3,s}.
So it seems just a matter of optimizers exposing/hiding things.
* The testcase is a bit obscure,
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=gcc&view=rev&rev=150493
Log:
2009-08-05 Paul Thomas
PR fortran/40847
* ire
--- 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."
a
--- 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 fail
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"
"CC_FOR_TARGET=/mnt/
--- 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=18307&action=view)
Patch which I am testing
This patch fixes the problem including a+1 and a+2 not aliasing each other.
It adds tw
--- 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 th
--- 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=gcc&view=rev&rev=150497
Log:
PR target/40906
* config/i386/i386.c (ix86_split_lo
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
S
--- 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 to
--- 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:
> http://gcc.gnu.org/ml/gcc-tes
--- 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 f_t
--- 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), %L
--- 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
--- 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
Motivated by PR 40969.
Currently, we generate a function declaration for
procedure() :: 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 40949 and PR 40969.
--- 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: trans-t
--- 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 (n
--- 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
#define umul_ppmm(xh, xl, a, b) \
__asm__ ("| Inlined umul_ppmm\n" \
"move%.l %2,%/d0\n" \
"move%.
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 a
--- 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 4
--
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
Oth
--- 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=gcc&view=rev&rev=150500
Log:
2009-08-05 Tobias Burnus
PR fortran/40969
R
--- 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=gcc&view=rev&rev=150500
Log:
2009-08-05 Tobias Burnus
PR fortran/40969
--- 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.
--
http:
--- 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=gcc&view=rev&rev=150501
Log:
PR target/40906
* config/i386/i386.c (ix86_split_lo
--- 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=18308&action=view)
C++ test case that fails with plausible patch
This is cut down from libstdc++-v3 sources. I am not sure it is sti
--- 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 is not included in
tr1/cfenv. Or, the configure test for the facilities in (generated
--- 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=18309&action=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 a
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...
http://gcc.g
)
ivtmp.1799_745 = PHI
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
--enable-languages=c,c++,fortran
--
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 chang
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=/s
--
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
6_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
--enable-languages=c,c++,fortran,objc,java --with-gmp=/sw
--with-libiconv-prefix=/sw --with-ppl=/sw --with-cloog=/sw --with-system-zlib
--x-includ
--- Comment #2 from howarth at nitro dot med dot uc dot edu 2009-08-06
01:28 ---
Interestingly...
gfortran -O2 -fgraphite-identity -floop-interchange air.f90 -o air
compiles the air benchmark without errors but the resulting code produces...
AIRFLOW IN A BOX
Vers
--
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
Hi
This example fails, because in function "f", the scheduler incorrectly swapped
floating point store to "c" and load of mmx registers.
Compile with -O2 -march=pentium-mmx
--
Summary: The scheduler incorrectly swaps MMX and floating point
instructions
1 - 100 of 102 matches
Mail list logo
