--- Comment #22 from d dot g dot gorbachev at gmail dot com 2009-04-20
19:31 ---
(In reply to comment #21)
Sorry, it seems it's because of malloc(), not a GCC bug...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36054
--- Comment #21 from d dot g dot gorbachev at gmail dot com 2009-02-13
15:25 ---
Created an attachment (id=17293)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17293&action=view)
precompiled source
The same issue with GCC 4.3.3 (i686-pc-linux-gnu).
C source:
http://svn.savannah.
--- Comment #20 from hjl dot tools at gmail dot com 2008-05-06 16:10
---
It is a bug in testcase. But g++ doesn't diagnose it properly. I opened
PR 36159 for it.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--
--- Comment #19 from pinskia at gcc dot gnu dot org 2008-05-05 09:14
---
(In reply to comment #17)
> Comment #c16 doesn't make sense. Of course malloc(3) can't be changed to
> return
> alignment, that would break all programs out there, violate many standards,
> etc.
Right now malloc
--- Comment #18 from tim at klingt dot org 2008-05-05 09:09 ---
hm, if that code is broken, what about the following one on x86_64
(__sync_bool_compare_and_swap_16 requires an alignment of 16 byte)?
struct __attribute__((aligned(16))) foo_t
{
foo_t(int a = 0, int b = 0): a_(a), b_(b
--- Comment #17 from jakub at gcc dot gnu dot org 2008-05-05 08:53 ---
Comment #c16 doesn't make sense. Of course malloc(3) can't be changed to
return
alignment, that would break all programs out there, violate many standards,
etc.
There are posix_memalign and memalign, which work just
--- Comment #16 from pinskia at gcc dot gnu dot org 2008-05-05 07:50
---
malloc has the same issue really. And from what I heard last time, glibc does
not want to change malloc to return the alignment.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36054
--- Comment #15 from pinskia at gcc dot gnu dot org 2008-05-05 07:49
---
See http://gcc.gnu.org/ml/gcc/2006-10/msg00166.html and a couple others about a
way to have an aligned operator new.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36054
--- Comment #14 from Joey dot ye at intel dot com 2008-05-05 07:29 ---
HJ,
AVX will have the similar problem on x86_64, whose new only returns object
aligned at 16 bytes. Dynamically allocated __m256 won't be guaranteed at 32
bytes boundary.
--
http://gcc.gnu.org/bugzilla/show_bug
--- Comment #13 from Joey dot ye at intel dot com 2008-05-05 07:22 ---
It is helpful. Root cause is that memory allocated by new is only aligned to 8
bytes under i386. In your case, object Environment is allocated by new and its
constructor tried to use movdqa to initialize its members.
--- Comment #12 from tim at klingt dot org 2008-05-01 13:14 ---
> Since it doesn't link, I can only check the .s file. There are a couple of
> constructor called Environment, which one is the problemetic function?
sorry for not providing a stripped down test case ...
the specific constr
--- Comment #11 from Joey dot ye at intel dot com 2008-05-01 04:31 ---
Tim,
Since it doesn't link, I can only check the .s file. There are a couple of
constructor called Environment, which one is the problemetic function?
grep Environment kernel_build.s|grep glob
...
.globl _ZN4nova11E
--- Comment #10 from ubizjak at gmail dot com 2008-04-30 12:31 ---
(In reply to comment #7)
> > -m32?
>
> Better, but a bunch of 45 errors like below remained.
>
> % g++ -g -O3 -march=core2 -mfpmath=sse -msse -ftemplate-depth-4096
> -Wnon-virtual-dtor -fPIC kernel_build.ii > log 2>&1
--- Comment #9 from Joey dot ye at intel dot com 2008-04-30 10:56 ---
(In reply to comment #8)
> -m32 doesn't work. You have to use 4.3.0 release branch. Recent mainline
> change
Correction: -m32 is a must, but doesn't fix all. Options I'm using:
g++ -g -O3 -march=core2 -mfpmath=sse -m
--- Comment #8 from Joey dot ye at intel dot com 2008-04-30 10:53 ---
(In reply to comment #6)
> (In reply to comment #4)
> > > have you tried to compile with -march=core2 -mfpmath=sse -msse?
> > Yes, I've compiled it as following:
> > % g++ -g -O3 -march=core2 -mfpmath=sse -msse -ftempl
--- Comment #7 from victork at gcc dot gnu dot org 2008-04-30 10:51 ---
> -m32?
Better, but a bunch of 45 errors like below remained.
% g++ -g -O3 -march=core2 -mfpmath=sse -msse -ftemplate-depth-4096
-Wnon-virtual-dtor -fPIC kernel_build.ii > log 2>&1
/usr/lib/gcc/i486-linux-gnu/4.3
--- Comment #6 from ubizjak at gmail dot com 2008-04-30 10:37 ---
(In reply to comment #4)
> > have you tried to compile with -march=core2 -mfpmath=sse -msse?
> Yes, I've compiled it as following:
> % g++ -g -O3 -march=core2 -mfpmath=sse -msse -ftemplate-depth-4096
> -Wnon-virtual-dtor -
--- Comment #5 from tim at klingt dot org 2008-04-30 09:58 ---
odd, it compiled fine for me:
[EMAIL PROTECTED]:~/workspace/nova$ g++-4.3 -g -O3 -march=core2 -mfpmath=sse
-msse
-ftemplate-depth-4096 -Wnon-virtual-dtor -fPIC kernel_build.ii -c
[EMAIL PROTECTED]:~/workspace/nova$
[EMAI
--- Comment #4 from victork at gcc dot gnu dot org 2008-04-30 09:44 ---
> have you tried to compile with -march=core2 -mfpmath=sse -msse?
Yes, I've compiled it as following:
% g++ -g -O3 -march=core2 -mfpmath=sse -msse -ftemplate-depth-4096
-Wnon-virtual-dtor -fPIC kernel_build.ii
--
--- Comment #3 from tim at klingt dot org 2008-04-30 08:40 ---
have you tried to compile with -march=core2 -mfpmath=sse -msse? i guess, that
is required to compile the preprocessed source file correctly ...
i will try gcc-4.4, when i find the time to compile it ...
--
http://gcc.gn
--- Comment #2 from victork at gcc dot gnu dot org 2008-04-30 02:48 ---
Hello,
I've tried to complile the attached kernel_build.ii on my SUSE SLES 10 x86_64
machine, but got a bunch of compile errors like this:
In file included from /usr/lib/gcc/i486-linux-gnu/4.3.1/include/xmmintrin.h
--- Comment #1 from tim at klingt dot org 2008-04-26 16:27 ---
Created an attachment (id=15533)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15533&action=view)
preprocessed source file
preprocessed source file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36054
22 matches
Mail list logo
