[Bug c/29818] New: code with SSE segfaults with gcc-3.4.6, runs fine with gcc-4.1.1

[Bug c/29818] New: code with SSE segfaults with gcc-3.4.6, runs fine with gcc-4.1.1

[sergstesh at yahoo dot com]

A (now pretty simple) piece of code segfaults when compiled with gcc-3.4.6,
but runs fine with gcc-4.1.1.

The offending line is:

   vtmp1.v = *(vFloat *)&inp_array_1[bn];

-please wait until upload the source file.

Both gcc-3.4.6 and gcc-4.1.1 were built by myself; the same code segfaults
when compiled using stock Mandrivaa gcc-3.3.6 and runs fine when compiled
using stock Mandriva gcc-4.0.1, so, I guess, it doesn't really matter
how I built gcc-3.4.6 and gcc-4.1.1.

Anyway, gcc-3.4.6 and gcc-4.1.1 were built using my

http://appsfromscratch.berlios.de/

tool, I can send the log files showing pretty standard, except for
local installation dir, configuration options.

When the code fails (i.e. compiled by gcc-3.4.6), the screen output is:

"
checkpoint 1
&inp_array_1[0]=80498e0
checkpoint 2
bn=1
&inp_array_1[1]=80498e4
checkpoint 3
Segmentation fault
";

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
bn=5
&inp_array_1[5]=80498f4
checkpoint 3
checkpoint 4
bn=9
&inp_array_1[9]=8049904
checkpoint 3
checkpoint 4
inp_array_1[0]=1
inp_array_1[1]=2
inp_array_1[2]=3
inp_array_1[3]=4
inp_array_1[4]=5
inp_array_1[5]=6
inp_array_1[6]=7
inp_array_1[7]=8
inp_array_1[8]=9
inp_array_1[9]=10
inp_array_1[10]=11
inp_array_1[11]=12
inp_array_1[12]=13
inp_array_1[13]=14
inp_array_1[14]=15
inp_array_1[15]=16
inp_array_1[16]=17
inp_array_1[17]=18
inp_array_1[18]=19
inp_array_1[19]=20
inp_array_1[20]=21
inp_array_1[21]=22
inp_array_1[22]=23
inp_array_1[23]=24
inp_array_1[24]=25
inp_array_1[25]=26
inp_array_1[26]=27
inp_array_1[27]=28
inp_array_1[28]=29
inp_array_1[29]=30
inp_array_1[30]=31
inp_array_1[31]=32
".


The command line used for compilation:

/AppsFromScratchWD/install/gcc-3.4.6/bin/gcc -save-temps -O2 -Wall -msse
-mfpmath=sse -o sse_bug sse_bug.c 
.

The command line used to run:

./sse_bug
.


-- 
           Summary: code with SSE segfaults with gcc-3.4.6, runs fine with
                    gcc-4.1.1
           Product: gcc
           Version: 3.4.6
            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=29818

[Bug c/29818] code with SSE segfaults with gcc-3.4.6, runs fine with gcc-4.1.1

[sergstesh at yahoo dot com]

------- Comment #1 from sergstesh at yahoo dot com  2006-11-13 16:40 -------
Created an attachment (id=12606)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12606&action=view)
source code which causes the segfault under gcc-3.4.6 and runs fine under
gcc-4.1.1

The file is the result -save-temps command line option used during compilation.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29818

[Bug target/29818] code with SSE segfaults with gcc-3.4.6, runs fine with gcc-4.1.1

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|blocker                     |normal
          Component|c                           |target


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29818

[Bug target/29818] code with SSE segfaults with gcc-3.4.6, runs fine with gcc-4.1.1

[pinskia at gcc dot gnu dot org]

------- Comment #2 from pinskia at gcc dot gnu dot org  2006-11-14 00:53 -------
You should note that 3.4.x is no longer being maintained so this bug will most
likely be closed as fixed as you already mention it works in 4.1.1.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29818

[Bug target/29818] code with SSE segfaults with gcc-3.4.6, runs fine with gcc-4.1.1

[sergstesh at yahoo dot com]

------- Comment #3 from sergstesh at yahoo dot com  2006-11-14 01:04 -------
(In reply to comment #2)
> You should note that 3.4.x is no longer being maintained so this bug will most
> likely be closed as fixed as you already mention it works in 4.1.1.
> 

That's too bad.

I am developing pretty heavy SSE-based code, and performance-wise gcc-3.4.6 is
the best so far. Sorry, I cant' post the code, but here are performance
figures (output of 'time' command):

with gcc-4.1.1 -O3:
567.341u 2.098s 9:35.75 98.9%   0+0k 0+0io 0pf+0w
567.055u 2.229s 9:37.18 98.6%   0+0k 0+0io 0pf+0w

with gcc-3.4.6 -O2:
543.440u 2.038s 9:13.76 98.5%   0+0k 0+0io 0pf+0w
542.925u 2.149s 9:16.29 97.9%   0+0k 0+0io 0pf+0w
.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29818

[Bug target/29818] code with SSE segfaults with gcc-3.4.6, runs fine with gcc-4.1.1

[pcarlini at suse dot de]

------- Comment #4 from pcarlini at suse dot de  2006-11-14 01:17 -------
(In reply to comment #3)
> I am developing pretty heavy SSE-based code, and performance-wise gcc-3.4.6 is
> the best so far. Sorry, I cant' post the code, but here are performance
> figures (output of 'time' command):

Then, you are not helping the project: a closed branch is not re-opened because
of a bug and posting performance numbers without a *reduced* snippet
pinpointing the specific issue is not useful to the developers (the only
possible effect is making someone slightly nervous ;)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29818

[Bug target/29818] code with SSE segfaults with gcc-3.4.6, runs fine with gcc-4.1.1

[sergstesh at yahoo dot com]

------- Comment #5 from sergstesh at yahoo dot com  2006-11-14 01:36 -------
(In reply to comment #4)
> (In reply to comment #3)
> > I am developing pretty heavy SSE-based code, and performance-wise gcc-3.4.6 is
> > the best so far. Sorry, I cant' post the code, but here are performance
> > figures (output of 'time' command):
> 
> Then, you are not helping the project: a closed branch is not re-opened because
> of a bug and posting performance numbers without a *reduced* snippet
> pinpointing the specific issue is not useful to the developers (the only
> possible effect is making someone slightly nervous ;)
> 

The "real" piece of code I'm working on is 14923 lines long (the "C" file, not
the "i" file). I can think of obfuscating it to the point it becomes not clear
what it is doing functionally.

We can make a deal: I obfuscate and publish the code, you guys fix the
bug preserving, if possible, performance.

The code is really complex, and it's not realistic for me to make it smaller.

By the way, using gcc-3.4.6 with '-O3' makes performance much worse, worse
than the one obtained with gcc-4.1.1.

On the other hand, '-O3' applied to gcc-4.1.1 does not change the performance
that drastic, though I do not remember at the moment whether the performance
improves or deteriorates.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29818

[Bug target/29818] code with SSE segfaults with gcc-3.4.6, runs fine with gcc-4.1.1

[bangerth at dealii dot org]

------- Comment #6 from bangerth at dealii dot org  2006-11-14 02:29 -------
(In reply to comment #5)
> We can make a deal: I obfuscate and publish the code, you guys fix the
> bug preserving, if possible, performance.
> 
> The code is really complex, and it's not realistic for me to make it smaller.

I guess our side of the deal would be: if you don't want to help us, we don't
want to help you. You need to give us some more information to entice us to
spend our leisure time on it. This is free software, after all.

W.


-- 

bangerth at dealii dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bangerth at dealii dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29818

[Bug target/29818] code with SSE segfaults with gcc-3.4.6, runs fine with gcc-4.1.1

[sergstesh at yahoo dot com]

------- Comment #7 from sergstesh at yahoo dot com  2006-11-14 02:54 -------
(In reply to comment #6)
> (In reply to comment #5)
> > We can make a deal: I obfuscate and publish the code, you guys fix the
> > bug preserving, if possible, performance.
> > 
> > The code is really complex, and it's not realistic for me to make it smaller.
> 
> I guess our side of the deal would be: if you don't want to help us, we don't
> want to help you. You need to give us some more information to entice us to
> spend our leisure time on it. This is free software, after all.
> 
> W.
> 


I don't quite understand what you want. Will it be enough if I give you the
code which shows the above performance difference ?

Are you interested to do the research and improvement ?

I am simply saying I do not want to spend my time changing the code to be able
to publish it if you are not going to deal with the performance issue anyway.

I think it's common interest to have a well performing compiler, especially
taking into account that the newer version performs somewhat worse than the
older one.

If you are talking about the size - believe me the code is really sensitive,
that's why I am afraid to change it significantly.

For example, initially there were parts organized like this:

<bunch_of_actions_of_type_A>
<bunch_of_actions_of_type_B>


- it was easier to think of the implementation this way.

Logically it was possible to interleave pieces of

<bunch_of_actions_of_type_A>

and

<bunch_of_actions_of_type_B>,

so I tried this change, and it improved performance.

I tried other things like interleaved/separate buffers, but the result
deteriorated.

So, I am where am, and I'm afraid if I changed the code the performance
phenomena would change with it.

I probably can still make the code smaller - there are kind of unrolled by
myself loops in it (but not quite, i.e. it's not only array elements in the
unrolled pieces), so I can probably decrease the number of iterations.

So, say, instead of 60 similar pieces in each portion you'll have 30 or 20
ones. But it will still be thousands of lines.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29818

[Bug target/29818] code with SSE segfaults with gcc-3.4.6, runs fine with gcc-4.1.1

[sergstesh at yahoo dot com]

------- Comment #8 from sergstesh at yahoo dot com  2006-11-17 01:27 -------
Please see

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29874

- another proof that gcc-3.4.6 generates better SSE code than gcc-4.1.1, and
the
proof uses only widely available and well known GPL'ed code.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29818

[Bug target/29818] code with SSE segfaults with gcc-3.4.6, runs fine with gcc-4.1.1

[pinskia at gcc dot gnu dot org]

------- Comment #9 from pinskia at gcc dot gnu dot org  2006-11-17 01:45 -------
(In reply to comment #8)
> Please see
> 

Can you try the patch mentioned in:
http://gcc.gnu.org/ml/gcc-patches/2006-11/msg01005.html

(I am about to submit a new version of the patch but it does not change
functionality of the patch, just some style issues).

If that does not work, this is most likely an issue with unions and vector
accesses which is really PR 28367.  I am working slowly on these two issues
because I have other work I need to do for Sony.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29818

[Bug target/29818] code with SSE segfaults with gcc-3.4.6, runs fine with gcc-4.1.1

[sergstesh at yahoo dot com]

------- Comment #10 from sergstesh at yahoo dot com  2006-11-17 02:03 -------
(In reply to comment #9)
> (In reply to comment #8)
> > Please see
> > 
> 
> Can you try the patch mentioned in:
> http://gcc.gnu.org/ml/gcc-patches/2006-11/msg01005.html
> 
> (I am about to submit a new version of the patch but it does not change
> functionality of the patch, just some style issues).
> 
> If that does not work, this is most likely an issue with unions and vector
> accesses which is really PR 28367.  I am working slowly on these two issues
> because I have other work I need to do for Sony.
> 

I am confused.

Is this patch supposed to fix segmentation fault described in this report,
so the patch needs to be applied to gcc-3.4.6

OR

this patch is supposed to improve performance of gcc-4.1.1 WRT SSE ?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29818

[Bug target/29818] code with SSE segfaults with gcc-3.4.6, runs fine with gcc-4.1.1

[bangerth at dealii dot org]

------- Comment #11 from bangerth at dealii dot org  2006-11-17 02:09 -------

I'm only a bug master and don't do any work on the compiler anyway, so my
say isn't worth much, but here's my take:

You propose that you can give us 15,000 lines of obfuscated code through which
we will have to dig ourselves to find out what is causing the slowdown, and
then fix the problem. At the same time you sit at the sidelines and wait for
us to work on the code that you have purposefully made hard to read.

What you apparently don't understand is that many of us work on gcc in our
spare time. If you want us to do something for you, you will have to help us
some. That might include trying to find out which part of the code slowed 
down, or to make the code significantly slower. Typically, the bug reports
that come with the smallest testcases receive the most attention.

You just have to realize that you don't pay us to do the crappy work of 
taking apart an obfuscated code. Since nobody pays us to work on random
bug reports, we typically pick the ones that are the most interesting or
that are the easiest to tackle since they come with a short testcase. We
do have an interest in making gcc better, but we reserve the right to
decide which parts of the compiler to make better, unless you pay someone
to do some specific piece of work.


> I am simply saying I do not want to spend my time changing the code to be able
> to publish it if you are not going to deal with the performance issue anyway.

We may. You can increase your chances by helping us.

W.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29818

[Bug target/29818] code with SSE segfaults with gcc-3.4.6, runs fine with gcc-4.1.1

[bangerth at dealii dot org]

------- Comment #12 from bangerth at dealii dot org  2006-11-17 02:12 -------
(In reply to comment #11)
> down, or to make the code significantly slower. Typically, the bug reports
                                          ^^^^^^ smaller, sorry W.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29818

[Bug target/29818] code with SSE segfaults with gcc-3.4.6, runs fine with gcc-4.1.1

[sergstesh at yahoo dot com]

------- Comment #13 from sergstesh at yahoo dot com  2006-11-17 02:23 -------
(In reply to comment #11)
> I'm only a bug master and don't do any work on the compiler anyway, so my
> say isn't worth much, but here's my take:
> 
> You propose that you can give us 15,000 lines of obfuscated code through which
> we will have to dig ourselves to find out what is causing the slowdown, and
> then fix the problem. At the same time you sit at the sidelines and wait for
> us to work on the code that you have purposefully made hard to read.
> 
> What you apparently don't understand is that many of us work on gcc in our
> spare time. If you want us to do something for you, you will have to help us
> some. That might include trying to find out which part of the code slowed 
> down, or to make the code significantly slower. Typically, the bug reports
> that come with the smallest testcases receive the most attention.
> 
> You just have to realize that you don't pay us to do the crappy work of 
> taking apart an obfuscated code. Since nobody pays us to work on random
> bug reports, we typically pick the ones that are the most interesting or
> that are the easiest to tackle since they come with a short testcase. We
> do have an interest in making gcc better, but we reserve the right to
> decide which parts of the compiler to make better, unless you pay someone
> to do some specific piece of work.
> 
> 
> > I am simply saying I do not want to spend my time changing the code to be able
> > to publish it if you are not going to deal with the performance issue anyway.
> 
> We may. You can increase your chances by helping us.
> 
> W.
> 


I opened another bug report, and mentioned it above, specifically devoted
to the performance issue:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29874
.

The example is based on FFTW, which is GPL - not a line of my code.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29818

[Bug target/29818] code with SSE segfaults with gcc-3.4.6, runs fine with gcc-4.1.1

[pinskia at gcc dot gnu dot org]

------- Comment #14 from pinskia at gcc dot gnu dot org  2006-11-19 01:27 -------
This like the other you filed is not a GCC bug, you are accessing a SSE vector
that is not aligned so you have to use the SSE intrinsic that does unaligned
access.


-- 

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

[Bug target/29818] code with SSE segfaults with gcc-3.4.6, runs fine with gcc-4.1.1

[sergstesh at yahoo dot com]

------- Comment #15 from sergstesh at yahoo dot com  2006-11-19 01:59 -------
Is the alignment requirement always applicable in all the cases, or just
for gcc-3.4.6 ?

Remember, in this case gcc-4.1.1 produces code which doesn't segfault.

Is it that gcc-4.1.1 optimizes out the failing line ?
Is it that gcc-4.1.1 falsely aligns the memory location in question ?
Is it that gcc-4.1.1 uses misaligned load into SSE registers by default ?

Is there any page in gcc manual clearly saying:

"align your data properly or your program will segfault"

?

I am specifically interested in the "or your program will segfault" part ?


-- 

sergstesh at yahoo dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |UNCONFIRMED
         Resolution|INVALID                     |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29818

[Bug target/29818] code with SSE segfaults with gcc-3.4.6, runs fine with gcc-4.1.1

[pinskia at gcc dot gnu dot org]

------- Comment #16 from pinskia at gcc dot gnu dot org  2006-11-19 02:06 -------
(In reply to comment #15)
> Is the alignment requirement always applicable in all the cases, or just
> for gcc-3.4.6 ?

It segfaults for me with gcc-4.1.2.

> 
> Remember, in this case gcc-4.1.1 produces code which doesn't segfault.

That could be because malloc/stack locations just happen to be 16byte aligned

> 
> Is it that gcc-4.1.1 optimizes out the failing line ?
No.

> Is it that gcc-4.1.1 falsely aligns the memory location in question ?

Well it can be 8byte aligned and accidently also 16byte aligned (which does
happen every once in a while).

> Is it that gcc-4.1.1 uses misaligned load into SSE registers by default ?
No because I could reproduce the failure in 4.1.2

> 
> Is there any page in gcc manual clearly saying:
> 
> "align your data properly or your program will segfault"
> 
> ?
> 
> I am specifically interested in the "or your program will segfault" part ?

This is call debugging your program.  Also you really should read web pages
about SSE programming because it seems like you don't understand how to use.

Also using mode with vector mode is deprecated and you should be using
vector_size instead.


-- 

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

[Bug target/29818] code with SSE segfaults with gcc-3.4.6, runs fine with gcc-4.1.1

[sergstesh at yahoo dot com]

------- Comment #17 from sergstesh at yahoo dot com  2006-11-19 02:20 -------
Regarding

"
> Is it that gcc-4.1.1 falsely aligns the memory location in question ?

Well it can be 8byte aligned and accidently also 16byte aligned (which does
happen every once in a while).
"

The original report shows:

"
&inp_array_1[1]=80498e4
checkpoint 3
Segmentation fault
"

, i.e. the failing address is not 8 bytes aligned, it's 4 bytes aligned.

Regarding

"
> I am specifically interested in the "or your program will segfault" part ?

This is call debugging your program.  Also you really should read web pages
about SSE programming because it seems like you don't understand how to use.
"

I did read documentation on the issue, beginning from gcc manual.

You correctly point out that by default aligned loads are used, which
are faster, and Intel documentation says that misaligned address in such
a case causes general protection fault. Which can be dealt with by kernel.

The point is that I do not recall in the gcc manual mentioning of the default
aligned load.

Adding one sentence (if it's not yet there) would make life of both end users
and developers easier - the developers will have to deal with smaller amount
of bug reports like this one.

Regarding

"
Also using mode with vector mode is deprecated and you should be using
vector_size instead.
"

- sure, just gcc-3.4.6 doesn't understand this. I do not remember how
the gcc version macro is called, so I used the code which was compatible with
both gcc-3.4.6 and gcc-4.1.1, though it produces warning on gcc-4.1.1.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29818