[Bug c/29884] New: gcc-4.1.1, gcc-4.0.1 generate segfaulting SSE code

[Bug c/29884] New: gcc-4.1.1, gcc-4.0.1 generate segfaulting SSE code

[sergstesh at yahoo dot com]

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

[Bug c/29884] gcc-4.1.1, gcc-4.0.1 generate segfaulting SSE code

[sergstesh at yahoo dot com]

------- 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

[Bug c/29884] gcc-4.1.1, gcc-4.0.1 generate segfaulting SSE code

[sergstesh at yahoo dot com]

------- 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

[Bug c/29884] gcc-4.1.1, gcc-4.0.1 generate segfaulting SSE code

[sergstesh at yahoo dot com]

------- 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

[Bug target/29884] gcc-4.1.1, gcc-4.0.1 generate segfaulting SSE code

[pinskia at gcc dot gnu dot org]

-- 

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

[Bug target/29884] gcc-4.1.1, gcc-4.0.1 generate segfaulting SSE code

[pinskia at gcc dot gnu dot org]

------- 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

[Bug target/29884] gcc-4.1.1, gcc-4.0.1 generate segfaulting SSE code

[sergstesh at yahoo dot com]

------- 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

[Bug target/29884] gcc-4.1.1, gcc-4.0.1 generate segfaulting SSE code

[pinskia at gcc dot gnu dot org]

------- 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