--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Keywo
--- Comment #9 from burnus at gcc dot gnu dot org 2006-11-30 07:36 ---
(In reply to comment #7)
> Do you happen to know at what revision things went bad?
The example program, I extracted (comment #6), actually crashes here with
- gfortran 4.1.2 20061115
- gcc-Version 4.2.0 20061006
- gc
--
ubizjak at gmail dot com changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29852
--- Comment #11 from ubizjak at gmail dot com 2006-11-30 07:17 ---
Fixed, by intriducing x87 helpers.
Let's see those benchmarks fly again ;)
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #10 from uros at gcc dot gnu dot org 2006-11-30 06:55 ---
Subject: Bug 29852
Author: uros
Date: Thu Nov 30 06:54:47 2006
New Revision: 119356
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=119356
Log:
PR target/29852
* config/i386/i386.md (*truncxfsf2
--- Comment #30 from jvdelisle at gcc dot gnu dot org 2006-11-30 06:25
---
Good News. I did not have a clean apply of the patch. I reverted everything
and started over. There was one part of the patch I had to manually apply
before and I must have messed it up. Now everything works
--- Comment #17 from dberlin at gcc dot gnu dot org 2006-11-30 04:54
---
Subject: Re: Inordinate compile times on large routines
On 30 Nov 2006 04:36:05 -, lucier at math dot purdue dot edu
<[EMAIL PROTECTED]> wrote:
>
>
> --- Comment #16 from lucier at math dot purdue dot edu
in8.8.0
Configured with: ../configure --build=powerpc64-apple-darwin8.8.0
--host=powerpc64-apple-darwin8.8.0 --target=powerpc64-apple-darwin8.8.0
--enable-languages=c --prefix=/pkgs/gcc-4.2.0-64-test
--with-gmp=/pkgs/gmp-4.2.1-64/ --with-mpfr=/pkgs/gmp-4.2.1-64/
Thread model: posix
gcc version 4.2
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-11-30 04:29 ---
(In reply to comment #3)
> Thanks for the confirmation.
Well I am a maintainer of the SPU port so I really care about the failures and
how ever weird the testcase :).
> and const_tiny_rtx[0][(int) CDImode] isn't
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-11-30 04:18 ---
This is obvious what caused it:
+2006-11-28 Jan Hubicka <[EMAIL PROTECTED]>
+
+ * builtins.c: Include tree-flow.h.
+ (fold_builtin_memory_op): Be more aggressive on converting memcpy to
+ assignme
There is no reason to be moving %esp in this function.
$ cat cc.c
typedef unsigned long size_t;
extern void *memcpy (void *__restrict, const void *__restrict, size_t);
char *foo1(char*buf){
short tmp2;
int tmp4;
*buf++ = 42;
tmp2=0xfeed;
memcpy(buf,&tmp2,2);
buf += 2;
tmp4 = 0x123456
--- Comment #29 from jvdelisle at gcc dot gnu dot org 2006-11-30 03:32
---
to_write_subrecord = 0
have_written = 0
to_write_subrecord = 0
have_written = 0
to_write_subrecord = 0
have_written = 0
to_write_subrecord = 0
have_written = 0
ad infinitum
Now I wonder if the patch app
--- Comment #2 from bangerth at dealii dot org 2006-11-30 03:24 ---
Confirmed. PR 6628 is indeed fixed, but it appears as if it only has an effect
for typedefs outside class declarations:
-
typedef int ptr1() const; // no error
void foo ()
{
typedef int ptr2() cons
--- Comment #1 from bangerth at dealii dot org 2006-11-30 03:22 ---
The point is that the temporary isn't unused: you call operator=(char*) on it.
The compiler can't know if that has any side effects that you may intend to
have happen...
--
bangerth at dealii dot org changed:
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-11-30 03:02 ---
I think this is a dup of bug 25818.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|critical|normal
GCC build triplet|../gcc/configure -- |
The following code works with g77 but the executable from gfortran yields
segmentation fault
program test_entry
real a(10)
a(1) = 999.
call x
call y(a,10)
stop
end
subroutine x
real a(n)
write(6,*)'Hello World from subroutine x'
ret
--- Comment #9 from chaoyingfu at gcc dot gnu dot org 2006-11-30 01:10
---
Subject: Bug 29490
Author: chaoyingfu
Date: Thu Nov 30 01:10:16 2006
New Revision: 119349
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=119349
Log:
Merged revisions 118220-118221 via svnmerge from
svn+
--- Comment #6 from chaoyingfu at gcc dot gnu dot org 2006-11-30 01:10
---
Subject: Bug 29641
Author: chaoyingfu
Date: Thu Nov 30 01:10:16 2006
New Revision: 119349
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=119349
Log:
Merged revisions 118220-118221 via svnmerge from
svn+
--- Comment #11 from chaoyingfu at gcc dot gnu dot org 2006-11-30 01:10
---
Subject: Bug 29387
Author: chaoyingfu
Date: Thu Nov 30 01:10:16 2006
New Revision: 119349
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=119349
Log:
Merged revisions 118220-118221 via svnmerge from
svn
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-11-30 01:06 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-11-30 01:06 ---
Subject: Bug 29945
Author: pinskia
Date: Thu Nov 30 01:05:58 2006
New Revision: 119348
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=119348
Log:
2006-11-29 Andrew Pinski <[EMAIL PROTECTED]>
PR ta
--- Comment #3 from kkojima at gcc dot gnu dot org 2006-11-30 00:26 ---
Thanks for the confirmation. I've found that
#define CONST0_RTX(MODE) (const_tiny_rtx[0][(int) (MODE)])
and const_tiny_rtx[0][(int) CDImode] isn't initialized in
init_emit_once. With adding
for (mode = GET_CLA
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-11-30 00:03 ---
http://gcc.gnu.org/ml/gcc-testresults/2006-11/msg01285.html
Oh and it was the same emit_move_insn too. So confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |
--- Comment #1 from pinskia at physics dot uc dot edu 2006-11-30 00:03
---
Subject: Re: New: [4.3 Regression] segfault with
gcc.c-torture/compile/2804-1.c on sh-elf
>
> sh-elf compiler segfaults with a null argument for emit_move_insn
> when compiling gcc.c-torture/compile/2
>
> sh-elf compiler segfaults with a null argument for emit_move_insn
> when compiling gcc.c-torture/compile/2804-1.c with -O1.
I get this also for SPU-elf with gcc.c-torture/compile/2804-1.c
at -O3 -fomit-frame-pointer -funroll-loops.
Thanks,
Andrew Pinski
sh-elf compiler segfaults with a null argument for emit_move_insn
when compiling gcc.c-torture/compile/2804-1.c with -O1.
The gdb backtrace is
#0 emit_move_insn (x=0xb7c89e20, y=0x0) at ../../ORIG/trunk/gcc/expr.c:3275
#1 0x08262d94 in rest_of_handle_life () at ../../ORIG/trunk/gcc/flow.c:1
--
echristo at apple dot com changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |echristo at apple dot com
|dot org |
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-11-29 23:31 ---
The patch is testing right now.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29945
--- Comment #18 from pinskia at gcc dot gnu dot org 2006-11-29 23:22
---
*** Bug 30023 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-11-29 23:22 ---
*** This bug has been marked as a duplicate of 4131 ***
*** This bug has been marked as a duplicate of 4131 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from zackw at panix dot com 2006-11-29 23:16 ---
Created an attachment (id=12712)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12712&action=view)
optimal assembly for this test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30023
--- Comment #2 from zackw at panix dot com 2006-11-29 23:16 ---
Created an attachment (id=12711)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12711&action=view)
code generated from test case by gcc 4.1
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30023
--- Comment #1 from zackw at panix dot com 2006-11-29 23:15 ---
Created an attachment (id=12710)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12710&action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30023
The attached test case involves a global object with class type and a
constructor that just copies values from its arguments into instance variables.
It would be nice if GCC would recognize this case and generate an
initialized-data object instead of a global constructor invocation. (In this
part
--- Comment #8 from jv244 at cam dot ac dot uk 2006-11-29 22:26 ---
(In reply to comment #7)
> Joost,
>
> Do you happen to know at what revision things went bad?
I'm afraid I don't...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29975
--- Comment #29 from bergner at vnet dot ibm dot com 2006-11-29 22:23
---
Talking with Andrew on IRC, he said the test case in comment #27 fails for the
same reason as the test case in comment #24 (ie, it looks like an artificial
decl) and should be fixed with his PTR_PLUS_EXPR work.
--- Comment #7 from pault at gcc dot gnu dot org 2006-11-29 22:15 ---
Joost,
Do you happen to know at what revision things went bad?
As the likely author of the regression, I would be interested to know, so that
I can dig us out again.
Regards
Paul
--
http://gcc.gnu.org/bugzilla
--- Comment #28 from tkoenig at gcc dot gnu dot org 2006-11-29 22:12
---
(In reply to comment #27)
Hi Jerry,
> The program fails on x86-64-freebsd and never completes the first write. It
> just keeps going, and going, and going This is a target specific issue.
> My guess is th
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.0.4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30022
The following code snippet crashes the C++ frontend since GCC 4.0.0:
void foo()
{
int __attribute__((vector_size(8))) v;
v = 1/v;
}
bug.cc: In function 'void foo()':
bug.cc:4: internal compiler e
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30021
The following code snippet crashes the C++ frontend on mainline:
==
int main(void,char**);
==
bug.cc:1: error: '' has incomplete type
bug.cc:1: error: invalid use of 'void'
bug.cc:1: internal compiler error: tree check: expected class 'type'
--
tobi at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirme
--- Comment #9 from ubizjak at gmail dot com 2006-11-29 21:05 ---
(In reply to comment #8)
> The patch doesn't like me ;)
>
> [EMAIL PROTECTED]:~/src/trunk/gcc/config/i386$ patch -p0 < /tmp/p
> patching file i386.md
> Hunk #1 succeeded at 3892 (offset -49 lines).
> Hunk #2 succeeded at
--- Comment #6 from tobi at gcc dot gnu dot org 2006-11-29 20:45 ---
I retracted the patch because it causes regressions with user-defined
operators. I'm not convinced that this problem is worth doing anything
non-trivial as is required, so I'm un-assigning myself.
--
tobi at gcc do
--- Comment #4 from reichelt at gcc dot gnu dot org 2006-11-29 20:44
---
Fixed in GCC 4.1.2 and later.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from jakub at gcc dot gnu dot org 2006-11-29 20:21 ---
This is similar to PR27328 which was only fixed for omp parallel (and even then
only when not inlined or inlined at most once).
Started fixing these omp region with NULL region->exit and/or region->cond
issues today, b
--- Comment #28 from bergner at vnet dot ibm dot com 2006-11-29 20:11
---
Another problem with the current patch, is we get one testsuite regression
(gfortran.fortran-torture/compile/defined_type_2.f90 at -O1). For this simple
testcase, we end up generating bad assembler:
mr 9,sfp
--- Comment #2 from patchapp at dberlin dot org 2006-11-29 20:00 ---
Subject: Bug number PR27996
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2006-11/msg01989.html
--
http://gcc.gnu.org/bugzilla/sh
--- Comment #3 from patchapp at dberlin dot org 2006-11-29 19:55 ---
Subject: Bug number PR30015
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2006-11/msg01987.html
--
http://gcc.gnu.org/bugzilla/sh
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-11-29 19:50 ---
__builtin_memcpy(this,&f,sizeof(FIND_RESULT)); is most likely the cause.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30017
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-11-29 19:47 ---
Further reduced testcase:
class NAMES_ITEM { };
struct ATOM {
const NAMES_ITEM& getPredItem() const { }
};
class ATOMSET {
public:
class FIND_RESULT {
const NAMES_ITEM &pattern;
public:
F
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-11-29 19:47 ---
Also fails with 32bit.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
GCC target t
--- Comment #1 from burnus at gcc dot gnu dot org 2006-11-29 19:43 ---
Works now for me.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
Status|
I would expect gcc to issue the same or similar warning for both functions
below but the unreachable label in the switch statement isn't flagged even
with -Wall.
In addition, a new portability warning mode/option would be useful that would
point out cases like those below irrespective of -funsigne
Hi, I mixed up the following code to reset a ostringstream
ostringstream oss;
oss << "Stuff";
oss.str() = ""; // Should have been oss.str( "" );
The third line is creating a temporary variable and assigning it the new ""
value, then it disappears. Couldn't g++ have warned me of an unused temp?
--- Comment #3 from amylaar at gcc dot gnu dot org 2006-11-29 19:03 ---
Created an attachment (id=12709)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12709&action=view)
ChangeLog entries for softfp-diff-20061110
The previous version was missing the enumeration of two new files.
--- Comment #9 from lmillward at gcc dot gnu dot org 2006-11-29 19:02
---
Fixed in 4.1.2.
--
lmillward at gcc dot gnu dot org changed:
What|Removed |Added
Assign
--- Comment #8 from lmillward at gcc dot gnu dot org 2006-11-29 19:02
---
Subject: Bug 29022
Author: lmillward
Date: Wed Nov 29 19:01:50 2006
New Revision: 119332
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=119332
Log:
PR c++/29022
* parser.c (cp_parser_class
--- Comment #4 from fang at csl dot cornell dot edu 2006-11-29 19:00
---
Subject: Re: Add rvalue references (C++0x)
On 29 Nov 2006, hhinnant at apple dot com wrote:
> --- Comment #3 from hhinnant at apple dot com 2006-11-29 18:36 ---
> Recent work:
>
> http://mndfck.org/~ped
--- Comment #2 from amylaar at gcc dot gnu dot org 2006-11-29 18:52 ---
Created an attachment (id=12708)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12708&action=view)
ChangeLog entries for softfp-diff-20061110
These are the ChangeLog entries for the SH specific code.
The Chang
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-11-29 18:46 ---
doesn't fail with 32bits.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
GCC targe
--- Comment #2 from martinol at nrlssc dot navy dot mil 2006-11-29 18:41
---
Argh! Evidently on this system make and gmake are different!! Apologies.
Closed.
$ /usr/local/bin/make --version
GNU Make version 3.79.1, by Richard Stallman and Roland McGrath.
Built for mips-sgi-irix6.5
Co
--- Comment #3 from hhinnant at apple dot com 2006-11-29 18:36 ---
Recent work:
http://mndfck.org/~pedro.lamarao/projects/c++0x/
http://home.twcny.rr.com/hinnant/cpp_extensions/rvalue_ref_test/
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29939
--- Comment #8 from rguenth at gcc dot gnu dot org 2006-11-29 18:36 ---
The patch doesn't like me ;)
[EMAIL PROTECTED]:~/src/trunk/gcc/config/i386$ patch -p0 < /tmp/p
patching file i386.md
Hunk #1 succeeded at 3892 (offset -49 lines).
Hunk #2 succeeded at 3919 (offset -47 lines).
Hunk #
--- Comment #2 from burnus at gcc dot gnu dot org 2006-11-29 18:25 ---
Accept. Thanks for the bugreport and the patch.
I actually wanted to write:
The proposed solution is to change
lt = time()
local_time = *localtime (<);
UTC_time = *gmtime (<);
[...]
values[6] = local_
--- Comment #7 from ubizjak at gmail dot com 2006-11-29 18:20 ---
Created an attachment (id=12707)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12707&action=view)
Patch to enable x87 fprem and fprem1 for SSE math
I know that I've forgotten something ;)
--
ubizjak at gmail dot
--- Comment #6 from ubizjak at gmail dot com 2006-11-29 18:18 ---
(In reply to comment #5)
> Can we make sure to always emit proper truncation to SF/DFmode if not
> TARGET_MIX_SSE_I387? Just in case two fprem instructions follow each other
> and so we don't truncate by moving to memory
Building the trunk into an empty directoy with
"$GCCDIR/configure" --enable-languages=c,fortran
--prefix=/projects/tob/gcc-trunk && make && make install
on an openSUSE 10.2rc2 system fails with
'cc1: error: unrecognized command line option "-Wno-overlength-strings'.
This is with "make" since I
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-11-29 17:55 ---
Created an attachment (id=12706)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12706&action=view)
reduced testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30017
--- Comment #9 from janis at gcc dot gnu dot org 2006-11-29 17:37 ---
This was fixed by
http://gcc.gnu.org/viewcvs?view=rev&rev=118754
r118754 | rakdver | 2006-11-13 12:37:29 + (Mon, 13 Nov 2006)
which reverted the patch that caused the testcase to start failing.
--
h
--- Comment #7 from lmillward at gcc dot gnu dot org 2006-11-29 16:52
---
Fixed in 4.2.
--
lmillward at gcc dot gnu dot org changed:
What|Removed |Added
Summa
--- Comment #6 from lmillward at gcc dot gnu dot org 2006-11-29 16:51
---
Subject: Bug 29022
Author: lmillward
Date: Wed Nov 29 16:51:32 2006
New Revision: 119322
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=119322
Log:
PR c++/29022
* parser.c (cp_parser_class
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-11-29 16:33 ---
Reducing.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30017
Between r119279 and r119305 DVL failed to build with
./cc1plus -quiet -o /dev/null
/space/rguenther/src/c++bench/html/sandbox/DLV/dl.ii -O
dl.C: In function 'void printQueryI(std::ostream&, const INTERPRET&, const
GINTERPRET*)':
dl.C:800: internal compiler error: in cp_expr_size, at cp/cp-objcp-co
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-11-29 16:02 ---
Can we make sure to always emit proper truncation to SF/DFmode if not
TARGET_MIX_SSE_I387? Just in case two fprem instructions follow each other
and so we don't truncate by moving to memory or SSE registers. It wou
--- Comment #7 from baldrick at gcc dot gnu dot org 2006-11-29 16:00
---
Subject: Bug 23744
Author: baldrick
Date: Wed Nov 29 16:00:07 2006
New Revision: 119320
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=119320
Log:
PR tree-optimization/23744
* tree-vrp.c (v
--- Comment #4 from ubizjak at gmail dot com 2006-11-29 15:58 ---
(In reply to comment #3)
> So another possibility is to adjust the 387 patterns to be enabled even
> without
> TARGET_MIX_SSE_I387.
>
Considering the fact that even solaris x86_64 libm [1] uses these functions for
DFmod
--- Comment #2 from eesrjhc at bath dot ac dot uk 2006-11-29 15:48 ---
I think this is the same as PR 29867
--
eesrjhc at bath dot ac dot uk changed:
What|Removed |Added
I find no description for "triplet", so guessing at its use, and see no method
of attaching .ii so attempting to fit all info in this form.
Problem seems to be from reinterpret_cast between vectors and unions of vectors
with arrays of scalars.
Occurred in machine-generated code, have not been able
--- Comment #5 from lmillward at gcc dot gnu dot org 2006-11-29 15:20
---
Fixed on mainline.
--
lmillward at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from lmillward at gcc dot gnu dot org 2006-11-29 15:19
---
Subject: Bug 29022
Author: lmillward
Date: Wed Nov 29 15:19:39 2006
New Revision: 119318
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=119318
Log:
PR c++/29022
* parser.c (cp_parser_class
--- Comment #1 from burnus at gcc dot gnu dot org 2006-11-29 14:12 ---
Confirm. (Though I couldn't reproduce the problem with gcc 4.2 and gcc 4.1 and
the example program.)
The proposed solution is to change
local_time = *localtime (<);
UTC_time = *gmtime (<);
[...]
values[6]
In date_and_time.c, 'time' is called. If the routine then goes on to call
'gettimeofday', it extracts the milliseconds value from the 'gettimeofday'
call, but gets the seconds value from the old call to 'time'. This can result
in consecutive times of (say)
2006 11 29 124 34 999
200
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-11-29 10:49 ---
So another possibility is to adjust the 387 patterns to be enabled even without
TARGET_MIX_SSE_I387.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29852
--- Comment #2 from burnus at gcc dot gnu dot org 2006-11-29 10:38 ---
If one uses -mfpmath=387 or -mfpmath=sse,387, the speed also dramatically
increases.
Results with test case below on a Athlon64:
icc -O3 test.c; time ./a.out
d=12.216410, r=10.26
real0m2.549s; user
--- Comment #13 from mkl at pengutronix dot de 2006-11-29 09:55 ---
Created an attachment (id=12705)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12705&action=view)
fix target linker emulation for arm elf and eabi (take 3)
If you try to build a big-endian eabi toolchain, you need
88 matches
Mail list logo
