--- Comment #6 from pault at gcc dot gnu dot org 2008-10-28 06:25 ---
(In reply to comment #3)
I suspect this is only hiding the problem though.
Indeed it is - the old problem returns with
integer :: i(-1:1) = 1, j(3) = 1, k(3)
k = j(I + (/1,1,1/))
end
for
--- Comment #1 from jakub at gcc dot gnu dot org 2008-10-28 07:47 ---
Smaller testcase:
int
foo (void)
{
int a = 0, b = 0;
unsigned int c = 0;
return (a | b == b) (c | 1);
}
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from jakub at gcc dot gnu dot org 2008-10-28 07:54 ---
Even smaller:
int a;
unsigned int b;
int
foo (void)
{
return (a | 1) (b | 1);
}
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
There some confusing/wrong error messages with the -std=c++0x option.
All three example statements below work fine without -std=c++0x and with
gcc versions = 4.3. Seems to be a gcc bug and no C++0x demand (at least
the first 2 example statements).
typedef enum { AA=1, BB=2 } my_enum;
typedef
--- Comment #3 from jakub at gcc dot gnu dot org 2008-10-28 10:36 ---
Subject: Bug 37931
Author: jakub
Date: Tue Oct 28 10:34:51 2008
New Revision: 141406
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=141406
Log:
PR middle-end/37931
* fold-const.c
--- Comment #4 from jakub at gcc dot gnu dot org 2008-10-28 10:38 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--
dodji at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dodji at gcc dot gnu dot org
|dot org
--- Comment #7 from mikael dot morin at tele2 dot fr 2008-10-28 12:21
---
This is happening because
(1) gfc_trans_constant_array_constructor sets loop-temp_dim to 1.
(2) gfc_conv_loop_setup choses the last ss whose shape is known (that of i).
(3) gfc_conv_loop_setup sets loop bounds
$ cat test.cpp
namespace x {
extern char *foo;
};
using namespace x;
char *foo;
char bar()
{
return *foo;
}
$ g++ test.cpp -fsyntax-only
test.cpp: In function char bar():
test.cpp:8: error: reference to foo is ambiguous
test.cpp:5: error: candidates are: char* foo
test.cpp:2:
Consider the testcase below.
$ cat test.cpp
namespace x {
extern const char ** const foo;
extern const char ** const bar;
};
using namespace x;
namespace {
const char* X;
};
const char ** const foo = X;
const char ** const x::bar = X;
$ g++ test.cpp -Wall -Wunused
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org
|dot org
I just saw that at least omp_set_schedule but maybe all new OpenMP 3 functions
are not documented in libgomp.texi.
--
Summary: omp_set_schedule not documented in libgomp.texi
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords:
I have found an error in the optimizer that is causing it to over-optimze a
conditional operator, ?:. The optimizer will always choose the first option
regardless of the value of the condition. In the code, the call to setHelpInt1
is always passed the value for UP even though DOWN is the correct
--- Comment #2 from jeff_harris at kentrox dot com 2008-10-28 13:27 ---
Compiled as: g++ -Wall -O2 -v -save-temps badref2.cpp
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37936
--- Comment #5 from dominiq at lps dot ens dot fr 2008-10-28 13:30 ---
On *-Darwin9 I get:
i = transfer(-1,1.0)
1
Error: Arithmetic overflow converting REAL(4) to INTEGER(4) at (1). This check
can be disabled with the option -fno-range-check
If I use the option
--- Comment #1 from jeff_harris at kentrox dot com 2008-10-28 13:27 ---
Created an attachment (id=16572)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16572action=view)
Source code for bug
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37936
--- Comment #3 from paolo dot carlini at oracle dot com 2008-10-28 13:34
---
Cannot be reproduced in mainline and 4_3-branch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37936
REAL(c_double) matches double and is OK. However,
COMPLEX(c_double) is invalid as the proper kind parameter
is c_double_complex matching double _Complex
Internally, both yield the same value and also sizeof(0.0_c_double) and
sizeof(real(cmplx(0.0, c_double_cmpl)) is the
--- Comment #6 from sgk at troutmask dot apl dot washington dot edu
2008-10-28 14:03 ---
Subject: Re: gfortran error and ICE at automatic type conversion with transfer
intrinsic
On Tue, Oct 28, 2008 at 01:30:28PM -, dominiq at lps dot ens dot fr wrote:
--- Comment #5 from
--- Comment #9 from mikael dot morin at tele2 dot fr 2008-10-28 14:06
---
So that they are not lost, patches are here:
http://gcc.gnu.org/ml/fortran/2008-10/msg00153.html
http://gcc.gnu.org/ml/fortran/2008-10/msg00181.html
http://gcc.gnu.org/ml/fortran/2008-10/msg00212.html
See the
--- Comment #18 from mikael dot morin at tele2 dot fr 2008-10-28 14:08
---
The final patch is here:
http://gcc.gnu.org/ml/fortran/2008-10/msg00104.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35840
--- Comment #7 from dominiq at lps dot ens dot fr 2008-10-28 14:36 ---
What does ... print?
NaN on both ppc/intel-Darwin9.
My patch simply fixes the ICE in gfortran.
I think the conversion of NaN to int is buggy since the behavior is
platform/option dependent. Your patch just
In one bootstrap/regtest on 16way Itanium 2 I saw
FAIL: libgomp.c/atomic-4.c execution test
FAIL: libgomp.c/nqueens-1.c execution test
FAIL: libgomp.c/pr29947-1.c execution test
FAIL: libgomp.c/sort-1.c execution test
FAIL: libgomp.c++/task-3.C -O3 -fomit-frame-pointer execution test
FAIL:
--- Comment #8 from mikael dot morin at tele2 dot fr 2008-10-28 14:42
---
Created an attachment (id=16573)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16573action=view)
second fix
This patch solves the problem by releasing the (4) condition, making the loop
bounds reset
--- Comment #1 from jakub at gcc dot gnu dot org 2008-10-28 15:02 ---
BTW, using + reduction in the same loop (and with asm optimization barrier for
that variable) I see the reduction computed value always correct, so the loop
body is executed the correct number of times. That means in
--- Comment #8 from sgk at troutmask dot apl dot washington dot edu
2008-10-28 15:03 ---
Subject: Re: gfortran error and ICE at automatic type conversion with transfer
intrinsic
On Tue, Oct 28, 2008 at 02:36:07PM -, dominiq at lps dot ens dot fr wrote:
What does ... print?
--- Comment #1 from manu at gcc dot gnu dot org 2008-10-28 15:10 ---
I think this is just some bit missing in our Wunused. We currently do this for
explicit static, so it shouldn't be hard to do it for the implicit one.
--
manu at gcc dot gnu dot org changed:
What
--- Comment #7 from pluto at agmk dot net 2008-10-28 15:18 ---
(In reply to comment #5)
This is a glibc bug then.
hmm, Ulrich Drepper rejects this bug report.
http://sources.redhat.com/bugzilla/show_bug.cgi?id=6693#c1
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36568
--- Comment #4 from manu at gcc dot gnu dot org 2008-10-28 15:24 ---
I can reproduce in vanilla 4.2.4 and 4.1.2 but cannot reproduce in 4.3.2 and
trunk. Not sure if this is a regression from 4.0 or earlier but in any case it
is fixed in 4.3.2 and mainline and there no more planned
--- Comment #1 from manu at gcc dot gnu dot org 2008-10-28 15:27 ---
Confirmed also in mainline.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from manu at gcc dot gnu dot org 2008-10-28 15:41 ---
Jason, what you think about this?
In any case, there are some issues with this code:
First, it would be better to print the type of the expression (%qT) rather than
the expression itself (%qE), because it is
--- Comment #9 from deji_aking at yahoo dot ca 2008-10-28 15:47 ---
(In reply to comment #7)
What does ... print?
NaN on both ppc/intel-Darwin9.
My patch simply fixes the ICE in gfortran.
I think the conversion of NaN to int is buggy since the behavior is
platform/option
--- Comment #10 from sgk at troutmask dot apl dot washington dot edu
2008-10-28 16:19 ---
Subject: Re: gfortran error and ICE at automatic type conversion with transfer
intrinsic
On Tue, Oct 28, 2008 at 03:47:30PM -, deji_aking at yahoo dot ca wrote:
--- Comment #9 from
--- Comment #24 from howarth at nitro dot med dot uc dot edu 2008-10-28
16:21 ---
I still don't understand how the stage1 build of libcpp manages to ignore the
CFLAGS setting in the libccp level Makefile. This would suggest that the stage
1
build of libcpp is entirely handled by the
--- Comment #25 from bonzini at gnu dot org 2008-10-28 16:28 ---
Subject: Re: [4.4 Regression] CPPFLAGS now unset for
stage 1 build of libcpp files.
You do know that A=B in the command line overrides A=C in the makefile
right? :-)
Does the patch work?
--
--- Comment #26 from howarth at nitro dot med dot uc dot edu 2008-10-28
16:34 ---
No, I said earlier that the proposed patch doesn't work. Note that INCINTL
doesn't even appear in either the toplevel Makefile or the Makefile in intl
with your patch. It does appear in the libcpp
--- Comment #27 from bonzini at gnu dot org 2008-10-28 16:39 ---
Ah, I missed that. But yes, only libcpp/Makefile is supposed to have INCINTL.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37923
The CRIS port no longer emits an addi insn for (a N) + b, where N = {1, 2}.
Trivial test-case:
/* Make sure ADDI is combined and emitted successfully.
See also PRX. */
/* { dg-do compile } */
/* { dg-options -O2 } */
/* { dg-final { scan-assembler addi } } */
/* { dg-final {
--
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 #1 from hp at gcc dot gnu dot org 2008-10-28 16:54 ---
Forgot to mention that combine simplifies the ASHIFT to a MULT, despite not
being in an address. The corresponding address mode exists, and having the
same shape for both the separate insns and the addressing mode
--- Comment #28 from howarth at nitro dot med dot uc dot edu 2008-10-28
16:55 ---
Doh, it may be an issue with the fink packaging system. They have a command...
NoSetCPPFLAGS: True
which I assumed was unsetting CPPFLAGS within fink but it very well may
be just setting CPPFLAGS to a
--- Comment #2 from hp at gcc dot gnu dot org 2008-10-28 16:56 ---
...and the ASHIFT is what is incoming to combine, despite there being a
multiplication in the code, all fine and by definition.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37939
--- Comment #11 from deji_aking at yahoo dot ca 2008-10-28 17:07 ---
(In reply to comment #10)
Subject: Re: gfortran error and ICE at automatic type conversion with
transfer
intrinsic
When I run
program test
integer i
i = transfer(-1,1.0)
--- Comment #9 from dominiq at lps dot ens dot fr 2008-10-28 17:18 ---
The patch in comment #8 works as expected on my tests and regtest without
regression but conflicts with the patch for pr35681 in
http://gcc.gnu.org/ml/fortran/2008-10/msg00256.html.
Some synchronization seems
--- Comment #2 from burnus at gcc dot gnu dot org 2008-10-28 17:37 ---
Segfault with return values of allocatable functions.
A code which does not work is the following TR15581-conform program.
It seqfaults (SIGABRT) and valgrind shows errors of the kind:
==12853== Invalid write of
--- Comment #12 from dominiq at lps dot ens dot fr 2008-10-28 17:51 ---
(In reply to comment #8)
i = NaN is an assignment not a bitwise copy. This isn't platform
dependent nor option dependent. You simply can't assign a NaN to
an INTEGER.
Before the assignment, there is an attempt
--- Comment #9 from sje at cup dot hp dot com 2008-10-28 18:26 ---
Further investigation shows that it is not the size of common that is the
problem. The bug is related to the new union of st_parameter_43 and
st_parameter_44. Specifically, st_parameter_44 contains pos which is type
--- Comment #10 from mikael dot morin at tele2 dot fr 2008-10-28 18:27
---
Created an attachment (id=16574)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16574action=view)
first fix
This patch tries to solve the problem by changing the (2) condition.
It tries to use an ss whose
The following code has an extra semi-colon at the end of the function prototype
declaring bad_func1:
void bad_func1 (unsigned long long arg1, const char *arg2 ; );
void bad_func2 ()
{
const char *foo = foo;
bad_func1 (0, foo);
}
GCC 3.4 reports an error:
elm3b187%
--- Comment #13 from sgk at troutmask dot apl dot washington dot edu
2008-10-28 18:40 ---
Subject: Re: gfortran error and ICE at automatic type conversion with transfer
intrinsic
On Tue, Oct 28, 2008 at 05:51:06PM -, dominiq at lps dot ens dot fr wrote:
i = NaN is an
--- Comment #2 from pault at gcc dot gnu dot org 2008-10-28 18:42 ---
(In reply to comment #1)
Tobias,
Isn't the problem the following?
parm.22.dim[0].lbound = 1;
parm.22.dim[0].ubound = D.1616;
parm.22.dim[0].stride = NON_LVALUE_EXPR D.1622;
parm.22.data = (void *)
--- Comment #11 from mikael dot morin at tele2 dot fr 2008-10-28 18:43
---
(In reply to comment #9)
Some synchronization seems needed.
Well, may patch is made against trunk, so I will leave it as is for now.
If Daniel commits his patch for PR35861, I can provide an updated patch.
--- Comment #12 from domob at gcc dot gnu dot org 2008-10-28 18:46 ---
(In reply to comment #11)
Well, may patch is made against trunk, so I will leave it as is for now.
If Daniel commits his patch for PR35861, I can provide an updated patch.
I quickly looked at it, and it should be
--- Comment #14 from burnus at gcc dot gnu dot org 2008-10-28 18:56 ---
When I run
program test
integer i
i = transfer(-1,1.0)
print *, i
end
I get -2147483648 with gcc-4.2, ifort, and pgf90 on x86_64 Linux, and same
value with xlf on AIX with
--- Comment #5 from jakub at gcc dot gnu dot org 2008-10-28 19:04 ---
Subject: Bug 37924
Author: jakub
Date: Tue Oct 28 19:02:36 2008
New Revision: 141413
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=141413
Log:
PR c/37924
* combine.c (make_compound_operation):
--- Comment #6 from jakub at gcc dot gnu dot org 2008-10-28 19:06 ---
Fixed in 4.4 so far.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Known to
--- Comment #4 from eric dot weddington at atmel dot com 2008-10-28 19:56
---
Reopening bug.
New test case gcc.dg/pr37663.c fails for AVR with:
/usr/local/avrdev/gcc/gcc/gcc/testsuite/gcc.dg/pr37663.c: In function 'foo':
/usr/local/avrdev/gcc/gcc/gcc/testsuite/gcc.dg/pr37663.c:11:
gcc -c -O3 -floop-block test_graphite.c
test_graphite.c: In function 'compress':
test_graphite.c:17: internal compiler error: in build_graphite_scops, at
graphite.c:1823
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
--- Comment #1 from mitul dot thakkar at amd dot com 2008-10-28 20:05
---
Created an attachment (id=16575)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16575action=view)
Reduced Test Case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37943
--- Comment #5 from jakub at gcc dot gnu dot org 2008-10-28 20:07 ---
Subject: Bug 37663
Author: jakub
Date: Tue Oct 28 20:06:08 2008
New Revision: 141414
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=141414
Log:
PR tree-optimization/37663
* gcc.dg/pr37663.c:
--- Comment #6 from jakub at gcc dot gnu dot org 2008-10-28 20:09 ---
Next time, please don't reopen the original PR. Whether the test fails on avr
or not doesn't have anything to do with the fact that the original bug has been
fixed. IMHO either open a new PR and link it to the
Regression test failure:
FAIL: gcc.dg/pr33645-3.c scan-assembler-not var1_t
Executing on host: /usr/local/avrdev/gcc/build/gcc/xgcc
-B/usr/local/avrdev/gcc/build/gcc/
/usr/local/avrdev/gcc/gcc/gcc/testsuite/gcc.dg/pr33645-3.c -O2
-fno-unit-at-a-time -DSTACK_SIZE=2048 -DNO_TRAMPOLINES -S
--- Comment #16 from burnus at gcc dot gnu dot org 2008-10-28 20:15 ---
Well, I think it may be more complicated. Have I mentioned
how much I hate TRANSFER. :(
Well, I didn't do much with TRANSFER, but I fully understand you.
To make matters worse, with trunk I see
call
--- Comment #1 from jsm28 at gcc dot gnu dot org 2008-10-28 20:25 ---
*** This bug has been marked as a duplicate of 23144 ***
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from jsm28 at gcc dot gnu dot org 2008-10-28 20:25 ---
*** Bug 37940 has been marked as a duplicate of this bug. ***
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
RTEMS has FreeBSD style structures:
Sockaddr and Sockaddr_In should have the 8bit Len and Family variable instead
of
16 family in gcc/ada/socthi.ads.
Bug prevents at least binding local address to socket, connecting tcp socket or
sending udp data.
diff g-socthi.ads g-socthi-rtems.ads
--- Comment #1 from jakub at gcc dot gnu dot org 2008-10-28 21:37 ---
*** This bug has been marked as a duplicate of 37339 ***
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from jakub at gcc dot gnu dot org 2008-10-28 21:37 ---
*** Bug 37944 has been marked as a duplicate of this bug. ***
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #4 from sje at cup dot hp dot com 2008-10-28 21:51 ---
I have posted a patch in which I propose removing this test. It has not gotten
any feedback yet.
http://gcc.gnu.org/ml/gcc-patches/2008-10/msg00826.html
--
sje at cup dot hp dot com changed:
What
--- Comment #1 from joel at gcc dot gnu dot org 2008-10-28 22:00 ---
This does not impact the SVN trunk.
This requires adding g-socthi-rtems.ads and corresponding Makefile.in change. I
will prepare and test a complete patch.
We wondered if this is broken for FreeBSD as well. We use
--- Comment #11 from dje at gcc dot gnu dot org 2008-10-28 22:35 ---
Created an attachment (id=16576)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16576action=view)
disallow illegal displacement wrapped in PRE_MODIFY or PRE_INC/DEC
I think this patch accomplishes the effect but
--- Comment #12 from dje at gcc dot gnu dot org 2008-10-28 23:13 ---
Created an attachment (id=16577)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16577action=view)
another refinement
Jakub suggested a further refinement to hoist a common sub-expression.
--
dje at gcc dot gnu
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-10-28 23:22 ---
The section does not change so there is no need for the .section in the
scan-assembler:
.globl __ZTV1f
.weak_definition __ZTV1f
.section __DATA,__const_coal,coalesced
.align 3
__ZTV1f:
Following (valid I believe) code causes internal compiler error:
enum class E : char
{
e1,
e2
};
inline E operator| (E a1, E a2)
{
char ret = static_castchar (a1)
| static_castchar (a2);
return static_castE(ret);
}
g++-4.4.0-alpha20081010 -v -c -std=c++0x
--- Comment #4 from jakub at gcc dot gnu dot org 2008-10-28 23:33 ---
Not P1, as it is just a testcase issue, not compiler bug.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from piotr dot rak at gmail dot com 2008-10-28 23:35 ---
Created an attachment (id=16578)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16578action=view)
Test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37946
--- Comment #29 from howarth at nitro dot med dot uc dot edu 2008-10-28
23:37 ---
I have verified that the fink build system wasn't in fact setting CPPFLAGS to
null
or anything else. So this problem is real when CPPFLAGS doesn't exist,
--
The following programm prints out 1, it should print 4 (like it does with
gcc-3.3.6:
// Start of test.c
#include stdlib.h
#include stdio.h
struct test
{
unsigned long counter;
};
unsigned long inc(struct test *tp)
{
tp-counter += 3;
return 1;
}
int main()
{
struct test *p;
--- Comment #1 from micirio at gmx dot net 2008-10-29 01:29 ---
Created an attachment (id=16579)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16579action=view)
test.i
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37947
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-10-29 01:34 ---
counter += inc(counter);
That is undefined code as you access counter without a sequence point where you
assign it.
So it is valid for GCC to change the above to:
int tmp = counter;
tmp += inc(counter);
counter
--- Comment #3 from micirio at gmx dot net 2008-10-29 01:44 ---
Thanks for the quick answer. Is it possible to get a warning if I write
undefined code like this? -Wall didn't tell me anything.
I'm asking, because I need to convert an existing (old) project where I found
this line that
--- Comment #6 from grosser at gcc dot gnu dot org 2008-10-29 04:37 ---
Fix committed.
--
grosser at gcc dot gnu dot org changed:
What|Removed |Added
--
grosser at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |grosser at gcc dot gnu dot
|dot org
--- Comment #33 from jvdelisle at gcc dot gnu dot org 2008-10-29 04:45
---
Subject: Bug 37707
Author: jvdelisle
Date: Wed Oct 29 04:44:15 2008
New Revision: 141420
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=141420
Log:
2008-10-28 Jerry DeLisle [EMAIL PROTECTED]
PR
--- Comment #34 from jvdelisle at gcc dot gnu dot org 2008-10-29 04:47
---
Fixed on 4.3, closing
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #35 from jvdelisle at gcc dot gnu dot org 2008-10-29 04:48
---
Subject: Bug 37707
Author: jvdelisle
Date: Wed Oct 29 04:47:20 2008
New Revision: 141421
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=141421
Log:
2008-10-28 Jerry DeLisle [EMAIL PROTECTED]
PR
+++ This bug was initially created as a clone of Bug #37364 +++
Testcase in PR 37364:
http://gcc.gnu.org/bugzilla/attachment.cgi?id=16536
shows IRA generates slower code for -mtune=core2.
$ gcc -m32 -O2 -mssse3 -mfpmath=sse 36.c
$ time -p ./a.out
real 7.97
$ gcc -m32 -O2 -mssse3 -mfpmath=sse
--- Comment #1 from hjl dot tools at gmail dot com 2008-10-29 05:44 ---
It looks like the cost of loading/storing FP values aren't appropriate for
Core 2. With this patch:
[EMAIL PROTECTED] i386]$ diff -up i386.c.foo i386.c
--- i386.c.foo 2008-10-28 21:56:19.0 -0700
+++ i386.c
89 matches
Mail list logo
