extracted from Wine
/home/marcus/projects/gcc.trunk/BIN/bin/gcc -c -O2 -g typelib.i -m32
/tmp/cc23hzJL.s: Assembler messages:
/tmp/cc23hzJL.s:299: Error: can't resolve `.LFE8' {*UND* section} - `.Ltext0'
{.text section}
The -m32 (build for x86) is necessary.
--
Summary: label em
--- Comment #1 from marcus at jet dot franken dot de 2009-05-26 07:11
---
Created an attachment (id=17917)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17917&action=view)
typelib.i
gcc -m32 -g -O3 typelib.i
reduced testcase ... further reduction seems to remove the problem :/
--- Comment #1 from burnus at gcc dot gnu dot org 2009-05-26 08:32 ---
The following patch to gfc_match_nullify fixes it; however, I think one should
additionally add
gfc_free_expr (new_st.expr1);
new_st.expr1 = NULL;
gfc_free_expr (new_st.expr2);
new_st.expr2 = NULL;
to preven
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-05-26 08:41 ---
It's just optimized to nothing.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from irar at il dot ibm dot com 2009-05-26 08:58 ---
(In reply to comment #0)
> On Linux/ia64, revision 147829:
> http://gcc.gnu.org/ml/gcc-cvs/2009-05/msg00806.html
> caused:
> FAIL: Matrix4f -O3 compilation from source
Could you please provide some information, it doesn
--- Comment #13 from theresa dot adelt at greselius dot net 2009-05-26
09:00 ---
Subject: Re: compile fails with "Unclassifiable statement" error
mess
Hello!
Thank you so much for answering.
But I think this is not the problem.
I added the '&', but thereupon appeared a syntax erro
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-05-26 09:06 ---
-fno-inline-functions should probably be -fno-inline. -f[no-]inline-functions
is semantically a no-op (it just tunes some params).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40249
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-05-26 09:09 ---
Mine.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-05-26 09:11 ---
Sounds similar to PR40249.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-05-26 09:12 ---
Reduced testcase:
typedef unsigned int uint32_t;
static void IP(uint32_t v[2])
{
v[0] = ((v[0] << 1) | ((v[0] >> 31) & 1L)) & 0xL;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40252
--- Comment #14 from tobi at gcc dot gnu dot org 2009-05-26 09:38 ---
- you're lacking a comma before the place I asked you to add an ampersand,
sorry I missed that
- g95 is not gfortran
- please direct beginner's questions somewhere more appropriate
--
http://gcc.gnu.org/bugzilla/s
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-05-26 09:41 ---
Subject: Bug 40247
Author: rguenth
Date: Tue May 26 09:41:29 2009
New Revision: 147864
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147864
Log:
2009-05-26 Richard Guenther
PR testsuite/40247
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-05-26 09:41 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
rev. 147829 (SLP vectorization) causes 403.gcc to miscompare when built with
-O3 -funroll-loops -fpeel-loops -ffast-math -march=native on x86_64 AMD K8
and K10.
--
Summary: [4.5 Regression] SPEC2006 403.gcc miscompares
Product: gcc
Version: 4.5.0
Stat
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40254
--- Comment #70 from rguenth at gcc dot gnu dot org 2009-05-26 10:17
---
Subject: Bug 32044
Author: rguenth
Date: Tue May 26 10:17:19 2009
New Revision: 147865
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147865
Log:
2009-05-26 Richard Guenther
Backport from mainl
--- Comment #71 from rguenth at gcc dot gnu dot org 2009-05-26 10:17
---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNE
--- Comment #7 from dodji at gcc dot gnu dot org 2009-05-26 10:35 ---
Subject: Bug 40007
Author: dodji
Date: Tue May 26 10:35:16 2009
New Revision: 147866
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147866
Log:
Fix PR c++/40007
gcc/cp/ChangeLog:
PR c++/40007
--- Comment #8 from dodji at gcc dot gnu dot org 2009-05-26 10:36 ---
Fixed in trunk.
--
dodji at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSI
--- Comment #5 from hp at gcc dot gnu dot org 2009-05-26 10:56 ---
(In reply to comment #4)
> -fno-inline-functions should probably be -fno-inline. -f[no-]inline-functions
> is semantically a no-op (it just tunes some params).
Thanks! Superficial testing (adding that option, diffing ou
When compiling the Cuba library from http://www.feynarts.de/cuba/ version 1.6
with gcc 4.2.4 I get:
./src/divonne/Explore.c: In function 'Explore':
./src/divonne/Explore.c:17: internal compiler error: in root_var_init, at
tree-ssa-live.c:1034
The problem is specific to gcc 4.2.4 (it does not appe
--- Comment #1 from sliwa at cft dot edu dot pl 2009-05-26 11:08 ---
Created an attachment (id=17918)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17918&action=view)
Divonne_preprocessed.c
Compiler input that causes the internal error.
--
http://gcc.gnu.org/bugzilla/show_bug
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-05-26 11:34 ---
Interesting. On x86_64 we generate
(insn 6 5 7 3 20090518-1.c:3 (set (reg:CCZ 17 flags)
(compare:CCZ (reg/v:SI 61 [ i ])
(const_int 42 [0x2a]))) -1 (nil))
(insn 7 6 8 3 20090518-1.c:3 (set (reg
14.8.1/6 says:
"But when a function template with explicit template arguments is used, the
call does not have the correct syntactic form unless there is a function
template with that name visible at the point of the call. If no such name is
visible, the call is not syntactically well-formed and ar
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-05-26 11:38 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-05-26 11:38 ---
Subject: Bug 40252
Author: rguenth
Date: Tue May 26 11:38:03 2009
New Revision: 147867
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147867
Log:
2009-05-26 Richard Guenther
PR middle-end/40252
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-05-26 11:41 ---
Subject: Bug 40252
Author: rguenth
Date: Tue May 26 11:41:34 2009
New Revision: 147868
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147868
Log:
2009-05-26 Richard Guenther
PR middle-end/40252
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-05-26 11:55 ---
I have a patch.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|
--- Comment #3 from abel at gcc dot gnu dot org 2009-05-26 12:19 ---
I have further looked at seqno handling, and it seems that we can't rip it off
without changing the region walking logic pretty much. Seqnos are computed in
such a way that they mark the stage (the number of iteration
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-05-26 12:21 ---
This is fixed in 4.4.0.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-05-26 12:22 ---
The GCC 4.2 series is no longer maintained.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #3 from hjl dot tools at gmail dot com 2009-05-26 13:12 ---
As of revision 147844, the only remaining failure on Linux/x86-64 is
403.gcc in SPE CPU 2006:
Running 403.gcc ref base o3 default
403.gcc: copy #0 non-zero return code (rc=1, signal=0)
*
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-05-26 13:36 ---
*** Bug 40245 has been marked as a duplicate of this bug. ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-05-26 13:36 ---
*** This bug has been marked as a duplicate of 40254 ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #4 from hjl dot tools at gmail dot com 2009-05-26 13:58 ---
Fixed.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRM
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-05-26 14:18 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-05-26 14:18 ---
Subject: Bug 40248
Author: rguenth
Date: Tue May 26 14:17:38 2009
New Revision: 147874
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147874
Log:
2009-05-26 Richard Guenther
PR middle-end/40248
--- Comment #2 from kargl at gcc dot gnu dot org 2009-05-26 14:18 ---
(In reply to comment #1)
> The following patch to gfc_match_nullify fixes it; however, I think one should
> additionally add
>
> gfc_free_expr (new_st.expr1);
> new_st.expr1 = NULL;
> gfc_free_expr (new_st.expr2
On Linux/ia32, revision 147852
http://gcc.gnu.org/ml/gcc-cvs/2009-05/msg00829.html
miscompiled 252.eon in SPEC CPU 2K at -O2:
Running Benchmarks
Running 252.eon ref base o2x87 default
*** Miscompare of pixels_out.kajiya, see
/export/gnu/import/rrs/spec/2000/spec/benchspec/CINT2000/252.eon/run/
--- Comment #3 from rguenther at suse dot de 2009-05-26 14:36 ---
Subject: Re: [4.5 Regression] SPEC2006 403.gcc
miscompares
On Tue, 26 May 2009, pinskia at gcc dot gnu dot org wrote:
> --- Comment #2 from pinskia at gcc dot gnu dot org 2009-05-26 14:34
> ---
> Does -fno-st
The code for find_givs_in_stmt_scev (gcc/tree-ssa-loop-ivopts.c) used to be
(in 4.3.2) this:
lhs = GIMPLE_STMT_OPERAND (stmt, 0);
if (TREE_CODE (lhs) != SSA_NAME)
return false;
if (!simple_iv (loop, stmt, GIMPLE_STMT_OPERAND (stmt, 1), iv, true))
return false;
...which has changed
--- Comment #1 from paolo dot carlini at oracle dot com 2009-05-26 15:46
---
According to n2857, the predicate is true for trivial types, reference types,
class types with a trivial destructor or an array of such class types: void
doesn't belong to any of those.
--
paolo dot carlini
--- Comment #3 from burnus at gcc dot gnu dot org 2009-05-26 14:45 ---
> > The following patch to gfc_match_nullify fixes it; however, I think one
> > should additionally add
> > gfc_free_expr (new_st.expr1);
> > gfc_free_expr (new_st.expr2);
> > to prevent a memory leak.
>
> AFAIC
There is a discrepancy between boost:: and std:: type traits.
#include
#include
#include
int main(int argc, char *argv[]) {
fprintf(stderr, "std::has_trivial_destructor = %i\n",
std::has_trivial_destructor::value);
fprintf(stderr, "boost::has_trivial_destructor = %i\n",
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-05-26 15:50 ---
It looks more like the code in GCC 4.3 is wrong and should use lhs here.
Zdenek?
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #4 from kargl at gcc dot gnu dot org 2009-05-26 15:11 ---
(In reply to comment #3)
> > > The following patch to gfc_match_nullify fixes it; however, I think one
> > > should additionally add
> > > gfc_free_expr (new_st.expr1);
> > > gfc_free_expr (new_st.expr2);
> > > to
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-05-26 14:34 ---
Does -fno-strict-aliasing help?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40254
Hello everybody,
today, I noticed a bug in gcc 4.4.0. The compiler segfaulted during
the compilation process. I also tested the same code with gcc 4.3.3, which
works perfectly fine.
I narrowed it down to the following test program:
template cl
--- Comment #1 from tux008 at googlemail dot com 2009-05-26 16:31 ---
Created an attachment (id=17919)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17919&action=view)
precompiled file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40260
--- Comment #2 from tux008 at googlemail dot com 2009-05-26 16:33 ---
Created an attachment (id=17920)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17920&action=view)
test program which causes gcc 4.4.0 to segfault
compiling this test program provokes a segfault of gcc 4.4.0. gcc
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-05-26 16:37 ---
Fixed in 4.4.1 already.
*** This bug has been marked as a duplicate of 40013 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #6 from pinskia at gcc dot gnu dot org 2009-05-26 16:37 ---
*** Bug 40260 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #13 from janis at gcc dot gnu dot org 2009-05-26 16:52 ---
I submitted Joern's patch in
http://gcc.gnu.org/ml/gcc-patches/2009-04/msg00198.html
but it wasn't reviewed. The test still ICEs on trunk and 4.4 branch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39254
--- Comment #8 from dodji at gcc dot gnu dot org 2009-05-26 16:58 ---
A patch was submitted at
http://gcc.gnu.org/ml/gcc-patches/2009-05/msg01655.html.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39754
The diagnostic issued for the ill-formed definition of B::foo() below is
quite confusing. EDG eccp issues a better message: template argument list
must match the parameter list.
$ cat z.cpp && gcc -c z.cpp
template struct A { };
template > struct B: U { void foo (); };
template void B::foo ()
--- Comment #2 from rakdver at gcc dot gnu dot org 2009-05-26 17:50 ---
(In reply to comment #1)
> It looks more like the code in GCC 4.3 is wrong and should use lhs here.
> Zdenek?
simple_iv should return the same result in both cases, so it should not really
matter. Is there some re
The code for find_givs_in_stmt_scev (gcc/tree-ssa-loop-ivopts.c) used to be
(in 4.3.2) this:
lhs = GIMPLE_STMT_OPERAND (stmt, 0);
if (TREE_CODE (lhs) != SSA_NAME)
return false;
if (!simple_iv (loop, stmt, GIMPLE_STMT_OPERAND (stmt, 1), iv, true))
return false;
...which has changed
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-05-26 18:47 ---
*** Bug 40262 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40259
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-05-26 18:47 ---
*** This bug has been marked as a duplicate of 40259 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #5 from burnus at gcc dot gnu dot org 2009-05-26 19:23 ---
Subject: Bug 40246
Author: burnus
Date: Tue May 26 19:23:45 2009
New Revision: 147879
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147879
Log:
2009-05-26 Tobias Burnus
PR fortran/40246
*
--- Comment #4 from burnus at gcc dot gnu dot org 2009-05-26 19:29 ---
s/main_program/is_main_program/
CLOSE as WONTFIX. As Andrew pointed out, there are a couple of issues using
static memory:
1. The middle end does not optimize static variables that well as it does not
know about non
--- Comment #6 from hp at gcc dot gnu dot org 2009-05-26 19:30 ---
(In reply to comment #4)
> -fno-inline-functions should probably be -fno-inline. -f[no-]inline-functions
> is semantically a no-op (it just tunes some params).
I've verified that is a fix, but it is counter to the docum
--- Comment #6 from burnus at gcc dot gnu dot org 2009-05-26 19:30 ---
Fixed on the trunk (4.5). Thanks Xavier for reporting it!
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
-
--
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 #7 from hp at gcc dot gnu dot org 2009-05-26 19:44 ---
Changing to middle-end. Nothing near target-specific.
--
hp at gcc dot gnu dot org changed:
What|Removed |Added
--
hp at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |hp at gcc dot gnu dot org
|dot org |
--- Comment #16 from loufoque at gmail dot com 2009-05-26 20:10 ---
It seems the current patch makes char16_t and char32_t keywords.
According to the linked specifications, however, those should only be typedefs
to the actual keywords, which are _Char16_t and _Char32_t.
Those typedefs sh
--- Comment #17 from loufoque at gmail dot com 2009-05-26 20:16 ---
Ignore my previous comment; it seems that was changed since in the current
C++0x draft those are indeed keywords.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33979
Having some problems porting some code between C++0x and TR1. The C++0x version
works as expected, but the TR1 uniform_real distribution seems to be returning
elements outside the given range.
And example:
#include
#include
#ifdef __GXX_EXPERIMENTAL_CXX0X__
# include
# include
#else
# includ
Interpretation request tracking bug
* * *
Found at
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/c05874d85748d9e6
The problem is
function f() result(res)
res = f(something)
where "f" is both a specific and a generic function and "f(something)" matches
a the differ
--- Comment #4 from burnus at gcc dot gnu dot org 2009-05-26 21:20 ---
Subject: Bug 39178
Author: burnus
Date: Tue May 26 21:19:57 2009
New Revision: 147883
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147883
Log:
fortran/
2009-05-26 Tobias Burnus
PR fortran/39178
--- Comment #1 from paolo dot carlini at oracle dot com 2009-05-26 21:47
---
I suspect that your usage of the tr1 version doesn't conform to 5.1.1/9,
because the tr1 version of uniform_real is really trivial, there isn't much to
fix (see also the comment just before the implementation i
Newlib build fails during compiling libc/stdlib/ldtoa.c for m2a with
internal compiler error: in simplify_subreg, at simplify-rtx.c:4960
A reduced testcase is
void
foo (unsigned short *x, unsigned short *y)
{
unsigned short *p = x;
*y = 0;
if (*p++)
*y = 0x8000;
}
For m2a, movrt in
--
kkojima at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40265
--- Comment #20 from jvdelisle at gcc dot gnu dot org 2009-05-27 01:22
---
Subject: Bug 22423
Author: jvdelisle
Date: Wed May 27 01:21:22 2009
New Revision: 147887
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147887
Log:
2009-05-23 Jerry DeLisle
Backport from main
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2009-05-27 01:22
---
Subject: Bug 38668
Author: jvdelisle
Date: Wed May 27 01:21:22 2009
New Revision: 147887
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147887
Log:
2009-05-23 Jerry DeLisle
Backport from mainl
--- Comment #13 from jvdelisle at gcc dot gnu dot org 2009-05-27 01:22
---
Subject: Bug 39782
Author: jvdelisle
Date: Wed May 27 01:21:22 2009
New Revision: 147887
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147887
Log:
2009-05-23 Jerry DeLisle
Backport from main
--- Comment #15 from jvdelisle at gcc dot gnu dot org 2009-05-27 01:22
---
Subject: Bug 25561
Author: jvdelisle
Date: Wed May 27 01:21:22 2009
New Revision: 147887
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147887
Log:
2009-05-23 Jerry DeLisle
Backport from main
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2009-05-27 01:22
---
Subject: Bug 39667
Author: jvdelisle
Date: Wed May 27 01:21:22 2009
New Revision: 147887
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147887
Log:
2009-05-23 Jerry DeLisle
Backport from mainl
--- Comment #9 from jvdelisle at gcc dot gnu dot org 2009-05-27 01:22
---
Subject: Bug 38654
Author: jvdelisle
Date: Wed May 27 01:21:22 2009
New Revision: 147887
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147887
Log:
2009-05-23 Jerry DeLisle
Backport from mainl
--- Comment #17 from jvdelisle at gcc dot gnu dot org 2009-05-27 01:22
---
Subject: Bug 37754
Author: jvdelisle
Date: Wed May 27 01:21:22 2009
New Revision: 147887
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147887
Log:
2009-05-23 Jerry DeLisle
Backport from main
--- Comment #16 from jvdelisle at gcc dot gnu dot org 2009-05-27 01:22
---
Subject: Bug 39664
Author: jvdelisle
Date: Wed May 27 01:21:22 2009
New Revision: 147887
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147887
Log:
2009-05-23 Jerry DeLisle
Backport from main
--- Comment #13 from jvdelisle at gcc dot gnu dot org 2009-05-27 01:22
---
Subject: Bug 39665
Author: jvdelisle
Date: Wed May 27 01:21:22 2009
New Revision: 147887
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147887
Log:
2009-05-23 Jerry DeLisle
Backport from main
--- Comment #18 from jvdelisle at gcc dot gnu dot org 2009-05-27 01:47
---
Fixed on 4.4, closing
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from tkoenig at gcc dot gnu dot org 2009-05-27 05:27 ---
Subject: Bug 40187
Author: tkoenig
Date: Wed May 27 05:27:31 2009
New Revision: 147894
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147894
Log:
2009-05-27 Thomas Koenig
PR libfortran/40187
If I run gcc -fverbose-asm -mtune=native -march=native -S x.c
I get
cat x.s:
.file "x.c"
# GNU C (GCC) version 4.4.0 20090506 (Red Hat 4.4.0-4) (x86_64-redhat-linux)
# compiled by GNU C version 4.4.0 20090506 (Red Hat 4.4.0-4), GMP
version 4.2.4, MPFR version 2.4.1.
# GGC heuristics
86 matches
Mail list logo
