--- Comment #71 from pinskia at gcc dot gnu dot org 2010-07-23 01:50
---
*** Bug 45036 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #69 from ubizjak at gmail dot com 2009-09-17 08:59 ---
*** Bug 39369 has been marked as a duplicate of this bug. ***
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #63 from simon dot sasburg at gmail dot com 2009-07-04 12:41
---
GCC still generates a segfaulting executable when used with the testcase in the
report, most likely because my assembler doesn't support the 3-argument .comm
directive.
When using the '-mpe-aligned-commons' i
--- Comment #64 from dave dot korn dot cygwin at gmail dot com 2009-07-04
12:47 ---
(In reply to comment #63)
GCC still generates a segfaulting executable when used with the testcase in
the
report, most likely because my assembler doesn't support the 3-argument .comm
directive.
--- Comment #65 from simon dot sasburg at gmail dot com 2009-07-04 13:17
---
Indeed, i should have expected this, and after rereading the comments here you
even mentioned this problem already. Sorry for the noise.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37216
--- Comment #66 from dave dot korn dot cygwin at gmail dot com 2009-07-04
13:21 ---
(In reply to comment #65)
Indeed, i should have expected this, and after rereading the comments here you
even mentioned this problem already. Sorry for the noise.
That's OK. GCC attempts to detect
--- Comment #62 from pinskia at gcc dot gnu dot org 2009-06-03 21:26
---
*** Bug 40333 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #61 from ubizjak at gmail dot com 2009-05-28 21:45 ---
Fixed for 4.5.0.
--
ubizjak at gmail dot com changed:
What|Removed |Added
Status|NEW
--- Comment #58 from dave dot korn dot cygwin at gmail dot com 2009-05-23
11:46 ---
Created an attachment (id=17906)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17906action=view)
Revised patch
Revised version of the patch that defines the autoconf feature test macro to
0/1
--- Comment #59 from dave dot korn dot cygwin at gmail dot com 2009-05-23
14:08 ---
Created an attachment (id=17909)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17909action=view)
D'oh. Quick respin.
Huh. Alignment is passed to the backend as number of bits, but of course the
--- Comment #57 from dave dot korn dot cygwin at gmail dot com 2009-05-20
21:16 ---
Bah. In case anyone else was about to point this out to me,
+gcc_GAS_CHECK_FEATURE([.comm with alignment], gcc_cv_as_comm_has_align,
+ [2,19,52],,
+ [.comm foo,1,32],,
--- Comment #56 from dave dot korn dot cygwin at gmail dot com 2009-05-20
04:25 ---
Created an attachment (id=17895)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17895action=view)
Target option and autoconf test to enable aligned common support.
Currently putting the attached
--- Comment #54 from dave dot korn dot cygwin at gmail dot com 2009-05-14
06:25 ---
I've started work on the binutils support for this. Work-in-progress patch at
http://sourceware.org/ml/binutils/2009-05/msg00228.html
Once that's complete, I could deal with the GCC end too.
What
--- Comment #55 from ubizjak at gmail dot com 2009-05-14 07:51 ---
(In reply to comment #54)
I've started work on the binutils support for this. Work-in-progress patch at
http://sourceware.org/ml/binutils/2009-05/msg00228.html
Once that's complete, I could deal with the GCC end
--- Comment #53 from dannysmith at users dot sourceforge dot net
2009-04-16 02:59 ---
This thread is alos relevant.
http://gcc.gnu.org/ml/gcc/2009-04/msg00462.html
Adding Dave Korn to cc:
--
dannysmith at users dot sourceforge dot net changed:
What|Removed
--- Comment #52 from ubizjak at gmail dot com 2009-02-16 07:41 ---
*** Bug 39194 has been marked as a duplicate of this bug. ***
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #51 from ubizjak at gmail dot com 2009-01-30 09:56 ---
*** Bug 39039 has been marked as a duplicate of this bug. ***
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #47 from sherpya at netfarm dot it 2008-10-07 11:50 ---
ffmpeg uses aligned vars inside an object from an external nasm/yasm compiled
module, so it's very unlikely gcc can be aware of this, the patch should solve
implicit sse code generation, but I think there are no
--- Comment #50 from brian at dessent dot net 2008-10-07 12:46 ---
Subject: Re: [cygming] Invalid alignment for SSE store to
.comm data generated with -O3
Oh, I see what you mean now. Yeah, predicating it on just TARGET_SSE
isn't sufficient.
I'm starting to think the idea of a
--- Comment #45 from nickc at redhat dot com 2008-10-07 11:37 ---
Created an attachment (id=16475)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16475action=view)
Enable -fno-common with -msse for Cygwin/Mingw
--
nickc at redhat dot com changed:
What|Removed
--- Comment #46 from nickc at redhat dot com 2008-10-07 11:38 ---
Hi Brian,
IMHO, we should just have gcc automatically enable -fno-common on PE if
SSE is enabled. That's what the MS tools do, AFAICT.
Something like the newly uploaded patch ?
Cheers
Nick
--
--- Comment #48 from brian at dessent dot net 2008-10-07 12:01 ---
Subject: Re: [cygming] Invalid alignment for SSE store to
.comm data generated with -O3
sherpya at netfarm dot it wrote:
I'll test your patch for the first post of the bugreport, and I'll test also
ffmpeg but I'm
--- Comment #44 from nickc at redhat dot com 2008-10-07 10:57 ---
Subject: Re: [cygming] Invalid alignment for SSE store
to .comm data generated with -O3
sherpya at netfarm dot it wrote:
I mean that with -fno-common alignment works, even with non patched 4.2, my
question is due to
--- Comment #49 from sherpya at netfarm dot it 2008-10-07 12:15 ---
not exactly, Simon Sasburg compiled with -march=core2 I'm not explicitly
telling to gcc to compile sse code, arch is i686 and opt is -O2 so there is no
sse code generated by gcc, ffmpeg declares aligned vars in fft.c
--- Comment #33 from nickc at redhat dot com 2008-10-06 12:43 ---
Subject: Re: [cygming] Invalid alignment for SSE store
to .comm data generated with -O3
Hi,
http://people.netfarm.it/~sherpya/gcc/info.7z
Just a quick check: If you build with -fno-common does the executable
then
--- Comment #34 from sherpya at netfarm dot it 2008-10-06 14:13 ---
$ nm ffmpeg_g.exe |grep ff_cos_16
00dd84e0 B _ff_cos_16
00de04c0 B _ff_cos_16384
except snow and svq1 tests, crashing because of bugs in tree opts on win32
sse code is working fine
--
--- Comment #35 from nickc at redhat dot com 2008-10-06 16:43 ---
Subject: Re: [cygming] Invalid alignment for SSE store
to .comm data generated with -O3
Hi sherpya,
--- Comment #34 from sherpya at netfarm dot it 2008-10-06 14:13 ---
$ nm ffmpeg_g.exe |grep ff_cos_16
--- Comment #36 from sherpya at netfarm dot it 2008-10-06 17:14 ---
so how with -fno-common can make aligned work?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37216
--- Comment #37 from nickc at redhat dot com 2008-10-06 17:24 ---
Subject: Re: [cygming] Invalid alignment for SSE store
to .comm data generated with -O3
Hi,
so how with -fno-common can make aligned work?
Hang on - I thought that you had said that when ffmpeg_g.exe was built
with
--- Comment #38 from sherpya at netfarm dot it 2008-10-06 17:27 ---
yes alignment works, and even my test align program with 4.2 without patches
gives correct alignment to local and global symbols
Local Aligned 16: 0
Local Aligned 32: 0
Global Aligned 16: 0
Global Aligned 32: 0
16 -
--- Comment #39 from nickc at redhat dot com 2008-10-06 18:16 ---
Subject: Re: [cygming] Invalid alignment for SSE store
to .comm data generated with -O3
yes alignment works, and even my test align program with 4.2 without patches
gives correct alignment to local and global
--- Comment #40 from sherpya at netfarm dot it 2008-10-06 18:54 ---
I mean that with -fno-common alignment works, even with non patched 4.2, my
question is due to the fact that it's not so clear for me what no-common does
and adding -fno-common what are side effects?
do using
--- Comment #41 from dannysmith at users dot sourceforge dot net
2008-10-06 20:18 ---
(In reply to comment #35)
As I suspected. The PE/COFF file format does not provide for specifying
the alignment of commons.
Hmm, I wonder if gcc should complain if it finds aligned commons
--- Comment #42 from brian at dessent dot net 2008-10-06 23:29 ---
Subject: Re: [cygming] Invalid alignment for SSE store to
.comm data generated with -O3
When you are comparing gcc 4.2 to current trunk, are you keeping the
linker (binutils) version the same? As mentioned in
--- Comment #43 from sherpya at netfarm dot it 2008-10-07 01:32 ---
binutils 2.18.91.20080917 on both
there are changes for the local alignment in the gas code but gcc does not use
them without my attached gcc_align_fix.diff patch (not sure 100%)
newer binutils are not working well on
--- Comment #31 from nickc at redhat dot com 2008-10-04 08:27 ---
Subject: Re: [cygming] Invalid alignment for SSE store
to .comm data generated with -O3
the patch looks ok but unfortunately does not always solves the problem,
something in the chain misalignes the symbol
This
--- Comment #32 from sherpya at netfarm dot it 2008-10-04 21:40 ---
this archive:
http://people.netfarm.it/~sherpya/gcc/info.7z
contains
ffmpeg_g.exe - non stripped final executable
fft.c/o/s - source, object file and asm generated
related vars are:
ff_cos_16, ff_cos_32 etc
$ nm
--- Comment #28 from nickc at redhat dot com 2008-10-03 16:52 ---
Subject: Re: [cygming] Invalid alignment for SSE store
to .comm data generated with -O3
Hi Danny,
This test case:
t1.c:(.text+0x5): undefined reference to `_i'
Hmm, I cannot reproduce this, however...
--- Comment #29 from nickc at redhat dot com 2008-10-03 16:54 ---
Created an attachment (id=16458)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16458action=view)
Revised patch which handles (size == 0)
--
nickc at redhat dot com changed:
What|Removed
--- Comment #30 from sherpya at netfarm dot it 2008-10-03 17:06 ---
the patch looks ok but unfortunately does not always solves the problem,
something in the chain misalignes the symbol
This does not happen always but in some circumstances :(
--
--- Comment #27 from dannysmith at users dot sourceforge dot net
2008-10-01 10:22 ---
(In reply to comment #13)
Created an attachment (id=16425)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16425action=view) [edit]
Revised patch with correct section switching
That patch
--- Comment #24 from nickc at redhat dot com 2008-09-30 14:05 ---
Subject: Re: [cygming] Invalid alignment for SSE store
to .comm data generated with -O3
a printf in the code for ff_cos_16 causes the compiler to align the var,
but at this point it crashes in another place using sse
--- Comment #25 from sherpya at netfarm dot it 2008-09-30 14:10 ---
(In reply to comment #24)
Subject: Re: [cygming] Invalid alignment for SSE store
to .comm data generated with -O3
a printf in the code for ff_cos_16 causes the compiler to align the var,
but at this point it
--- Comment #26 from dannysmith at users dot sourceforge dot net
2008-10-01 01:33 ---
(In reply to comment #14)
Hi Guys,
I am not able to reproduce the build problems that were reported with the
first version of my patch, but then again I do not have a native cygwin build
--- Comment #13 from nickc at redhat dot com 2008-09-29 14:13 ---
Created an attachment (id=16425)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16425action=view)
Revised patch with correct section switching
--
nickc at redhat dot com changed:
What|Removed
--- Comment #14 from nickc at redhat dot com 2008-09-29 14:16 ---
Hi Guys,
I am not able to reproduce the build problems that were reported with the
first version of my patch, but then again I do not have a native cygwin build
system or a system in which I can bootstrap mingw32. I
--- Comment #15 from sherpya at netfarm dot it 2008-09-29 15:39 ---
I also got the error on the first patch, gcc 4.4 from svn, binutils
2.18.91.20080917
I still have problems with 2.19 binutils snapshots (unable to correctly create
and link dll)
unfortunately the current gcc svn does
--- Comment #16 from sherpya at netfarm dot it 2008-09-29 15:40 ---
Created an attachment (id=16426)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16426action=view)
lcomm + alignment
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37216
--- Comment #17 from sherpya at netfarm dot it 2008-09-29 16:30 ---
with both patches I can achieve align 16
align 16 on globals still fails
Local Aligned 16: 0
Local Aligned 32: 0
Global Aligned 16: 0
Global Aligned 32: 16
the program is:
#include stdio.h
#include stdlib.h
#include
--- Comment #18 from brian at dessent dot net 2008-09-29 17:58 ---
Subject: Re: [cygming] Invalid alignment for SSE store to
.comm data generated with -O3
The __to_xstring error is PR37522. You should still be able to
bootstrap with --enable-languages=c for the purposes of testing
--- Comment #19 from dannysmith at users dot sourceforge dot net
2008-09-29 18:43 ---
Created an attachment (id=16427)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16427action=view)
Nick's aligned common testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37216
--- Comment #20 from sherpya at netfarm dot it 2008-09-29 19:33 ---
align testcase looks ok, but anyway I'm mainly interested to have code aligned
to 16. volatile around variables is not enough in my test program.
Nick's testcase is ok even on (local-only align) patched gcc 4.2
I've
--- Comment #21 from brian at dessent dot net 2008-09-29 20:06 ---
Subject: Re: [cygming] Invalid alignment for SSE store to
.comm data generated with -O3
This is an example of what I'm talking about: the bar() function is
optimized away to simply return 0 because the compiler
--- Comment #22 from sherpya at netfarm dot it 2008-09-29 23:17 ---
still no success while compiling ffmpeg :(
Program received signal SIGSEGV, Segmentation fault.
0x0074fe94 in ff_fft_calc_3dn ()
(gdb) bt
#0 0x0074fe94 in ff_fft_calc_3dn ()
#1 0x007506f5 in ff_fft_calc_3dn ()
#2
--- Comment #23 from sherpya at netfarm dot it 2008-09-29 23:22 ---
a printf in the code for ff_cos_16 causes the compiler to align the var,
but at this point it crashes in another place using sse code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37216
--- Comment #12 from kunzjacq at yahoo dot fr 2008-09-28 08:11 ---
same for me on mingw, bootstrap fails with patch. I get:
/e/mingw_build/build-gcc/./gcc/xgcc -B/e/mingw_build/build-gcc/./gcc/
-L/e/mingw_build/build-gcc/mingw32/winsup/mingw -L/e/mingw_build/build
--- Comment #11 from simon dot sasburg at gmail dot com 2008-09-26 07:32
---
I tried the attached patch, but gcc failed to build for me on cygwin with it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37216
--- Comment #8 from nickc at redhat dot com 2008-09-12 15:52 ---
Created an attachment (id=16303)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16303action=view)
Implement alignment for non-local commons
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37216
--- Comment #9 from nickc at redhat dot com 2008-09-12 15:54 ---
Hi Brian,
Please could you try out the uploaded patch which is an implementation of
your idea to add an extra alignment directive when emitting commons. It seems
to work for the test case you gave, but I have not yet
--- Comment #10 from brian at dessent dot net 2008-09-12 23:59 ---
Subject: Re: [cygming] Invalid alignment for SSE store to
.comm data generated with -O3
One thing I was unsure about is this method switches to the .bss section
without switching back to .text (or whatever)
--- Comment #5 from ubizjak at gmail dot com 2008-08-24 20:12 ---
Confirmed and added maintainer CC.
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #6 from brian at dessent dot net 2008-08-24 20:59 ---
Subject: Re: [cygming] Invalid alignment for SSE store to
.comm data generated with -O3
It seems to me the issue is that prior to 2007-11-05[1], the PE
assembler could not set section alignment flags correctly so .bss
--- Comment #7 from brian at dessent dot net 2008-08-24 21:15 ---
Subject: Re: [cygming] Invalid alignment for SSE store to
.comm data generated with -O3
Another route would be to set the .bss minimum back to 2**4 again.
Actually that's not really great either because it doesn't
63 matches
Mail list logo
