public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c/29884] New: gcc-4.1.1, gcc-4.0.1 generate segfaulting SSE code
@ 2006-11-18 6:02 sergstesh at yahoo dot com
2006-11-18 6:10 ` [Bug c/29884] " sergstesh at yahoo dot com
` (6 more replies)
0 siblings, 7 replies; 8+ messages in thread
From: sergstesh at yahoo dot com @ 2006-11-18 6:02 UTC (permalink / raw)
To: gcc-bugs
Hello,
this bug is most likely related to
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29818
, but now it's gcc-4.1.1, gcc-4.0.1, not gcc-3.4.6.
Actually, it's the same code using which I discovered
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29818
, just this is the full version of the code, not the shortened one.
This bug was discovered while I was debugging the code and added a missing
functional part.
--
Summary: gcc-4.1.1, gcc-4.0.1 generate segfaulting SSE code
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: blocker
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sergstesh at yahoo dot com
GCC build triplet: Linux comp.home.net 2.6.12-27mdk-i686-up-4GB #1 Tue Sep
26 12:41
GCC host triplet: Linux comp.home.net 2.6.12-27mdk-i686-up-4GB #1 Tue Sep
26 12:41
GCC target triplet: Linux comp.home.net 2.6.12-27mdk-i686-up-4GB #1 Tue Sep
26 12:41
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29884
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug c/29884] gcc-4.1.1, gcc-4.0.1 generate segfaulting SSE code
2006-11-18 6:02 [Bug c/29884] New: gcc-4.1.1, gcc-4.0.1 generate segfaulting SSE code sergstesh at yahoo dot com
@ 2006-11-18 6:10 ` sergstesh at yahoo dot com
2006-11-18 6:15 ` sergstesh at yahoo dot com
` (5 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: sergstesh at yahoo dot com @ 2006-11-18 6:10 UTC (permalink / raw)
To: gcc-bugs
------- Comment #1 from sergstesh at yahoo dot com 2006-11-18 06:10 -------
Created an attachment (id=12637)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12637&action=view)
the "C" file causing the failure
If I run this file, it fails with:
"
checkpoint 1
&signal_spectrum_L[0]=80491e0
&signal_spectrum_R[0]=8049140
checkpoint 2
half_number_of_samples=16 bin_number=1
bin_number=1
&signal_spectrum_L[1]=80491e4
checkpoint 3
Segmentation fault
".
Which means that this:
102 v_r_signal_L.v = *(vFloat *)&signal_spectrum_L[bin_number];
is the offending line.
Please pay attention to these lines:
157 *(vFloat *)&signal_spectrum_L[bin_number] = v_r_signal_L.v;
158 *(vFloat *)&signal_spectrum_R[bin_number] = v_r_signal_R.v;
159
160 signal_spectrum_L[number_of_samples_minus_bin_number] =
v_i_signal_L.f[0];
161 signal_spectrum_R[number_of_samples_minus_bin_number] =
v_i_signal_R.f[0];
162
163 signal_spectrum_L[number_of_samples_minus_bin_number_minus_1] =
v_i_signal_L.f[1];
164 signal_spectrum_R[number_of_samples_minus_bin_number_minus_1] =
v_i_signal_R.f[1];
165
166 signal_spectrum_L[number_of_samples_minus_bin_number_minus_3] =
v_i_signal_L.f[3];
167 signal_spectrum_R[number_of_samples_minus_bin_number_minus_3] =
v_i_signal_R.f[3];
- they are well below the offending line #102 in the same loop body, so
at first site they shouldn't matter - segfaults occurs before them.
Well, it's not the case, they do matter, if they are commented out, the
segfault does not occur, the program completes normally.
The above line #157..167 are the missing functional piece I discovered
while debugging, it's writeback.
I'll upload the .i files, as required, so you'll be able to compile
the files and hopefully reproduce the bug.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29884
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug c/29884] gcc-4.1.1, gcc-4.0.1 generate segfaulting SSE code
2006-11-18 6:02 [Bug c/29884] New: gcc-4.1.1, gcc-4.0.1 generate segfaulting SSE code sergstesh at yahoo dot com
2006-11-18 6:10 ` [Bug c/29884] " sergstesh at yahoo dot com
@ 2006-11-18 6:15 ` sergstesh at yahoo dot com
2006-11-18 6:18 ` sergstesh at yahoo dot com
` (4 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: sergstesh at yahoo dot com @ 2006-11-18 6:15 UTC (permalink / raw)
To: gcc-bugs
------- Comment #2 from sergstesh at yahoo dot com 2006-11-18 06:15 -------
Created an attachment (id=12638)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12638&action=view)
.i source causing segfault
This is the .i file which causes segfault.
Line #157..167 are not commented out.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29884
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug c/29884] gcc-4.1.1, gcc-4.0.1 generate segfaulting SSE code
2006-11-18 6:02 [Bug c/29884] New: gcc-4.1.1, gcc-4.0.1 generate segfaulting SSE code sergstesh at yahoo dot com
2006-11-18 6:10 ` [Bug c/29884] " sergstesh at yahoo dot com
2006-11-18 6:15 ` sergstesh at yahoo dot com
@ 2006-11-18 6:18 ` sergstesh at yahoo dot com
2006-11-18 11:00 ` [Bug target/29884] " pinskia at gcc dot gnu dot org
` (3 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: sergstesh at yahoo dot com @ 2006-11-18 6:18 UTC (permalink / raw)
To: gcc-bugs
------- Comment #3 from sergstesh at yahoo dot com 2006-11-18 06:18 -------
Created an attachment (id=12639)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12639&action=view)
.i source file not causing segfault
This is .i source file with line #157..167 commented out, and there is no
segfault in this case.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29884
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug target/29884] gcc-4.1.1, gcc-4.0.1 generate segfaulting SSE code
2006-11-18 6:02 [Bug c/29884] New: gcc-4.1.1, gcc-4.0.1 generate segfaulting SSE code sergstesh at yahoo dot com
` (2 preceding siblings ...)
2006-11-18 6:18 ` sergstesh at yahoo dot com
@ 2006-11-18 11:00 ` pinskia at gcc dot gnu dot org
2006-11-18 11:07 ` pinskia at gcc dot gnu dot org
` (2 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2006-11-18 11:00 UTC (permalink / raw)
To: gcc-bugs
--
pinskia at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
Severity|blocker |normal
Component|c |target
GCC build triplet|Linux comp.home.net 2.6.12- |i686-pc-linux-gnu
|27mdk-i686-up-4GB #1 Tue Sep|
|26 12:41 |
GCC host triplet|Linux comp.home.net 2.6.12- |i686-pc-linux-gnu
|27mdk-i686-up-4GB #1 Tue Sep|
|26 12:41 |
GCC target triplet|Linux comp.home.net 2.6.12- |i686-pc-linux-gnu
|27mdk-i686-up-4GB #1 Tue Sep|
|26 12:41 |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29884
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug target/29884] gcc-4.1.1, gcc-4.0.1 generate segfaulting SSE code
2006-11-18 6:02 [Bug c/29884] New: gcc-4.1.1, gcc-4.0.1 generate segfaulting SSE code sergstesh at yahoo dot com
` (3 preceding siblings ...)
2006-11-18 11:00 ` [Bug target/29884] " pinskia at gcc dot gnu dot org
@ 2006-11-18 11:07 ` pinskia at gcc dot gnu dot org
2006-11-18 15:18 ` sergstesh at yahoo dot com
2006-11-18 18:05 ` pinskia at gcc dot gnu dot org
6 siblings, 0 replies; 8+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2006-11-18 11:07 UTC (permalink / raw)
To: gcc-bugs
------- Comment #4 from pinskia at gcc dot gnu dot org 2006-11-18 11:07 -------
963 v_r_signal_L.v = *(vFloat *)&signal_spectrum_L[bin_number];
(gdb) p signal_spectrum_L
$1 = (AUDIO_DATA_TYPE *) 0x80491e0
(gdb) p bin_number
$2 = 1
(gdb) p &signal_spectrum_L[bin_number]
$3 = (AUDIO_DATA_TYPE *) 0x80491e4
This is not a bug, the alignment requirement for vector loads are 16byte
aligned and you just violated that.
You should use the SSE intrinsics for unaligned loads here.
--
pinskia at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution| |INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29884
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug target/29884] gcc-4.1.1, gcc-4.0.1 generate segfaulting SSE code
2006-11-18 6:02 [Bug c/29884] New: gcc-4.1.1, gcc-4.0.1 generate segfaulting SSE code sergstesh at yahoo dot com
` (4 preceding siblings ...)
2006-11-18 11:07 ` pinskia at gcc dot gnu dot org
@ 2006-11-18 15:18 ` sergstesh at yahoo dot com
2006-11-18 18:05 ` pinskia at gcc dot gnu dot org
6 siblings, 0 replies; 8+ messages in thread
From: sergstesh at yahoo dot com @ 2006-11-18 15:18 UTC (permalink / raw)
To: gcc-bugs
------- Comment #5 from sergstesh at yahoo dot com 2006-11-18 15:17 -------
IIRC, misaligned data should cause performance penalty, not segmentation fault.
Look at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29818 , at the case when
there is no segfault:
"
when the code runs fine (i.e. compiled by gcc-4.1.1), the screen output is:
"
checkpoint 1
&inp_array_1[0]=80498e0
checkpoint 2
bn=1
&inp_array_1[1]=80498e4
checkpoint 3
checkpoint 4
...
"
- as you see '&inp_array_1[1]=80498e4', and its WRT to line numbers 31..35 in:
29 while(half_nos - bn >= NUMBER_OF_ELEMENTS_IN_VECTOR)
30 {
31 fprintf(stderr, "bn=%u\n", bn);
32 fprintf(stderr, "&inp_array_1[%u]=%0lx\n", bn, (unsigned
long)&inp_array_1[bn]);
33
34 fprintf(stderr, "checkpoint 3\n");
35 vtmp1.v = *(vFloat *)&inp_array_1[bn];
36 fprintf(stderr, "checkpoint 4\n");
37
38 bn += NUMBER_OF_ELEMENTS_IN_VECTOR;
39 } // while(half_nos - bn >= NUMBER_OF_ELEMENTS_IN_VECTOR)
.
In this case the address is 80498e4, i.e. no a multiple of 16, still, the
code does not segfault, even though a misaligned operation:
35 vtmp1.v = *(vFloat *)&inp_array_1[bn];
is executed.
This is what I found in the documentation:
http://gcc.gnu.org/onlinedocs/gcc-4.1.1/gcc/i386-and-x86_002d64-Options.html#i386-and-x86_002d64-Options
:
"
-mpreferred-stack-boundary=num
Attempt to keep the stack boundary aligned to a 2 raised to num byte
boundary. If -mpreferred-stack-boundary is not specified, the default is 4 (16
bytes or 128 bits), except when optimizing for code size (-Os), in which case
the default is the minimum correct alignment (4 bytes for x86, and 8 bytes for
x86-64).
On Pentium and PentiumPro, double and long double values should be aligned
to an 8 byte boundary (see -malign-double) or suffer significant run time
performance penalties. On Pentium III, the Streaming SIMD Extension (SSE) data
type __m128 suffers similar penalties if it is not 16 byte aligned.
...
"
- from the above I expected to "suffer significant run time performance
penalties", but not a segfault.
Could you please:
1) point me to the documentation which says that misaligned SSE data will
cause segfault;
2) if such a document does not exist, update the documentation, preferably
pointing also to Intel documentation stating that misaligned SSE data causes
segmentation fault;
3) explain, how/why the code in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29818
does not segfault even though it has the same misalignment as here
?
Thanks in advance.
--
sergstesh at yahoo dot com changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |UNCONFIRMED
Resolution|INVALID |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29884
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug target/29884] gcc-4.1.1, gcc-4.0.1 generate segfaulting SSE code
2006-11-18 6:02 [Bug c/29884] New: gcc-4.1.1, gcc-4.0.1 generate segfaulting SSE code sergstesh at yahoo dot com
` (5 preceding siblings ...)
2006-11-18 15:18 ` sergstesh at yahoo dot com
@ 2006-11-18 18:05 ` pinskia at gcc dot gnu dot org
6 siblings, 0 replies; 8+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2006-11-18 18:05 UTC (permalink / raw)
To: gcc-bugs
------- Comment #6 from pinskia at gcc dot gnu dot org 2006-11-18 18:05 -------
There are two SSE instructions for loading memory, one that does unaligned
loads and one that does aligned loads. And the default instruction used for
vectors pointers is the aligned one. This is standard SSE way of doing it and
not a GCC specific issue. Most likely because the data is aligned just off by
4 bytes.
--
pinskia at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution| |INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29884
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2006-11-18 18:05 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2006-11-18 6:02 [Bug c/29884] New: gcc-4.1.1, gcc-4.0.1 generate segfaulting SSE code sergstesh at yahoo dot com
2006-11-18 6:10 ` [Bug c/29884] " sergstesh at yahoo dot com
2006-11-18 6:15 ` sergstesh at yahoo dot com
2006-11-18 6:18 ` sergstesh at yahoo dot com
2006-11-18 11:00 ` [Bug target/29884] " pinskia at gcc dot gnu dot org
2006-11-18 11:07 ` pinskia at gcc dot gnu dot org
2006-11-18 15:18 ` sergstesh at yahoo dot com
2006-11-18 18:05 ` pinskia at gcc dot gnu dot org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).