--- Comment #16 from fpbeekhof at gmail dot com 2009-04-05 08:16 ---
Ok, this was the original code that fails
// Prepare points of cube relative to point in matrix.
typename iPoint3D::value_type offset [8] [3] = {
{0, 0, 0}, {1, 0, 0}, {1, 0, 1}, {0, 0, 1},
{0, 1, 0
--- Comment #14 from fpbeekhof at gmail dot com 2009-04-04 20:14 ---
For simplicty, in the preprocessed source, edit the Makefile, set
CXXFLAGS= -pipe -I. -Wall -fopenmp -march=native
Then,
gccbug39573$ make clean; make
rm -f *.o *~ shapes
gcc -pipe -I. -Wall -fopenmp -march=native
--- Comment #11 from fpbeekhof at gmail dot com 2009-04-04 19:50 ---
No problem. I did a few more tests...
In short, it's the combination of -fopenmp and -march=native that makes fail on
AMD64.
Note: To test without openMP you can't use the preprocessed source.
# openmp
--- Comment #9 from fpbeekhof at gmail dot com 2009-04-04 18:13 ---
Subject: Re: Linking fails on AMD with -march=native, works
with generic x86_64
rguenth at gcc dot gnu dot org wrote:
> --- Comment #8 from rguenth at gcc dot gnu dot org 2009-04-04 18:03
> ---
>
--- Comment #7 from fpbeekhof at gmail dot com 2009-04-04 18:02 ---
I tried with "-march=native" but without "-ftree-vectorize", it still fails.
I tried with "-march=athlon64" but without "-ftree-vectorize", it still fails.
On an Intel machine,
--- Comment #5 from fpbeekhof at gmail dot com 2009-04-04 17:45 ---
Created an attachment (id=17586)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17586&action=view)
preprocessed source; with a Makefile!
Everything fails perfectly:
$ make clean; make
rm -f *.o *~ shapes
gc
--- Comment #2 from fpbeekhof at gmail dot com 2009-04-04 16:57 ---
The problem is the "-march=native" option. If I remove that, all is fine even
on AMD machines.
$ make CNF=gcc BACKEND=gsl
scons -j 2 CNF=gcc MODE= BACKEND=gsl CVMLCPP_PREFIX=/user/l1/beekhof/
scons: Reading
--- Comment #1 from fpbeekhof at gmail dot com 2009-04-03 12:01 ---
I've tried compiling the same code on several machines. Outcome: intel machines
are fine, AMD machines exhibit this behaviour.
The second AMD machine has ubuntu 8.04 on it, and a different compiler version:
$ g
s: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: fpbeekhof at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39573
--- Comment #23 from fpbeekhof at gmail dot com 2009-03-18 10:04 ---
My last comment (#22) of course does not address issues pointed out by jason in
#18.
Even if "we know that we are sure that either p1 == p2 or *p1 and *p2 do not
overlap because otherwise there would be an
--- Comment #22 from fpbeekhof at gmail dot com 2009-03-18 09:56 ---
Subject: Re: generated memcpy causes trouble in assignment
jakub at gcc dot gnu dot org wrote:
> --- Comment #20 from jakub at gcc dot gnu dot org 2009-03-18 09:10
> ---
> So let's use me
--- Comment #14 from fpbeekhof at gmail dot com 2009-03-17 13:28 ---
Subject: Re: generated memcpy causes trouble in assignment
paolo dot carlini at oracle dot com wrote:
> --- Comment #13 from paolo dot carlini at oracle dot com 2009-03-17
> 13:26 ---
> If it aff
--- Comment #11 from fpbeekhof at gmail dot com 2009-03-17 13:19 ---
Subject: Re: generated memcpy causes trouble in assignment
paolo dot carlini at oracle dot com wrote:
> --- Comment #10 from paolo dot carlini at oracle dot com 2009-03-17
> 13:15 ---
> The
--- Comment #9 from fpbeekhof at gmail dot com 2009-03-17 13:11 ---
Subject: Re: generated memcpy causes trouble in assignment
paolo dot carlini at oracle dot com wrote:
> --- Comment #8 from paolo dot carlini at oracle dot com 2009-03-17 12:33
> ---
> Yes, if t
--- Comment #7 from fpbeekhof at gmail dot com 2009-03-17 12:21 ---
Subject: Re: generated memcpy causes trouble in assignment
paolo dot carlini at oracle dot com wrote:
> --- Comment #5 from paolo dot carlini at oracle dot com 2009-03-17 11:28
> ---
> By the way
--- Comment #4 from fpbeekhof at gmail dot com 2009-03-17 11:15 ---
Subject: Re: generated memcpy causes trouble in assignment
paolo dot carlini at oracle dot com wrote:
> --- Comment #2 from paolo dot carlini at oracle dot com 2009-03-17 11:04
> ---
> by the way,
--- Comment #3 from fpbeekhof at gmail dot com 2009-03-17 11:13 ---
Subject: Re: generated memcpy causes trouble in assignment
rguenth at gcc dot gnu dot org wrote:
> --- Comment #1 from rguenth at gcc dot gnu dot org 2009-03-17 10:59
> ---
> calling memcpy wit
Product: gcc
Version: 4.2.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: fpbeekhof at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39480
--- Comment #3 from fpbeekhof at gmail dot com 2007-08-14 08:11 ---
Subject: Re: std::tr1::tgamma produces wrong results [for
(x-1) in stead of for x]
OOPS!
Thank you! And sorry for wasting your time...
pcarlini at suse dot de wrote:
> --- Comment #2 from pcarlini at suse
ead model: posix
gcc version 4.2.1 (Ubuntu 4.2.1-2ubuntu1)
Best,
Fokko Beekhof
--
Summary: std::tr1::tgamma produces wrong results [for (x-1) in
stead of for x]
Product: gcc
Version: 4.2.1
Status: UNCONFIRMED
Severity:
20 matches
Mail list logo
