[Bug target/38496] Gcc misaligns arrays when stack is forced follow the x8632 ABI

[Bug target/38496] Gcc misaligns arrays when stack is forced follow the x8632 ABI

[jackie.rosen at hushmail dot com]

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

Jackie Rosen <jackie.rosen at hushmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jackie.rosen at hushmail dot com

--- Comment #28 from Jackie Rosen <jackie.rosen at hushmail dot com> ---
*** Bug 260998 has been marked as a duplicate of this bug. ***
Seen from the domain http://volichat.com
Page where seen: http://volichat.com/adult-chat-rooms
Marked for reference. Resolved as fixed @bugzilla.

[Bug target/38496] Gcc misaligns arrays when stack is forced follow the x8632 ABI

[rguenth at gcc dot gnu dot org]

------- Comment #27 from rguenth at gcc dot gnu dot org  2009-10-23 09:45 -------
Appearantly I was misguided in comment #24 and likely was thinking about
the 4.4 dynamic stack re-alignment code which (guessing again) is probably
only in effect for AVX.


-- 


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

[Bug target/38496] Gcc misaligns arrays when stack is forced follow the x8632 ABI

[mikulas at artax dot karlin dot mff dot cuni dot cz]

------- Comment #26 from mikulas at artax dot karlin dot mff dot cuni dot cz  2009-07-31 01:18 -------
Very unfortunatelly, gcc does assume stack alignment.

The problem is not technical (the code to realign the stack is already there,
it's easy to activate it), the problem is ideological, because some gcc
developers think that they can declare their own ABI and the world will be
changing according to them.

See comments in the bug #40838. I added that alignment test at the beginning of
every libc function, the result is that 75% programs in /bin misalign the stack
and are non-conforming to GCC-developer's ideas about their new ABI.

I also posted a simple example there that does floating point math in the
function that is called as a callback from glibc --- and crashes because of SSE
and unaligned stack.

I really say that they should align the stack in SSE functions instead of
closing this bug with WONTFIX and shouting "everyone's code is bad because we
declared it so!"


-- 


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

[Bug target/38496] Gcc misaligns arrays when stack is forced follow the x8632 ABI

[whaley at cs dot utsa dot edu]

------- Comment #25 from whaley at cs dot utsa dot edu  2009-07-24 17:05 -------
Richard,

>GCC does not assume the stack is aligned to 16 bytes if it cannot prove that it is.

If this is true now, it is a change from previous behavior.  When I reported
this problem, gcc *assumed* 16-byte alignment on the stack being passed in, and
so gcc-compiled programs seg fault when called from ABI-compliant compliant
compilers (eg., icc or msvc++).  I agree with you that aligning the internal
stack to any multiple of 4 is compliant, but assuming greater than 4-byte
alignment on entry is not.

Are you saying that the new gcc has stopped assuming 16-byte alignment?  It
definitely made that assumption before . . .

Thanks,
Clint


-- 


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

[Bug target/38496] Gcc misaligns arrays when stack is forced follow the x8632 ABI

[rguenth at gcc dot gnu dot org]

------- Comment #24 from rguenth at gcc dot gnu dot org  2009-07-24 12:16 -------
GCC does not assume the stack is aligned to 16 bytes if it cannot prove that it
is.  That GCC aligns the stack to 16 bytes itself is compliant with the
requirement of 4 byte stack alignment.

So I completely miss your point (ignoring all but the initial bug description).


-- 


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

[Bug target/38496] Gcc misaligns arrays when stack is forced follow the x8632 ABI

[mikulas at artax dot karlin dot mff dot cuni dot cz]

------- Comment #23 from mikulas at artax dot karlin dot mff dot cuni dot cz  2009-07-23 14:34 -------
So, Joseph is basically arguing that it doesn't make sense to follow bad
standards. Fine. So let's ignore the "i386 ABI standard" thing for a moment a
look at the change from the practical point of view:

--- If we assume 16-bit stack alignment, who gets the advantage?

* some scientists doing number crunching, it will save stack realign. Most
desktop applications don't use SSE heavily (or not at all). Maybe video players
(most of them have sse in assembler though and don't rely on gcc for sse
generation).

--- If we assume 16-bit stack alignment, what problems will it bring?

* anything called from an inline assembler will have a possibility to fail.
Assembler programmers don't know about this alignment requirement and have been
writing "pushl $0; pushl $1; call function; addl $8, %esp" for ages.

* anything compiled by Intel CC, TCC or other compilers.
Intel CC assumes 4-byte alignment and uses some algorithm to realign only at
certain points (if the function can be only called from stack-aligned
functions, it doesn't have to have the stack realigned). If Intel CC does only
integer arithmetics, it aligns the stack only for 4 bytes.
Intel CC-generated code calls glibc that is being compiled by gcc, so failures
will come from there.

* anything autogenerated (java, dosbox, qemu, firefox 3.5...)

* anything compiled with gcc 2.95.* and earlier.

The worst thing about these failures is that they'll happen only very
sporadically, gcc autovectorizer doesn't generate vector functions in most of
the glibc, so most of the code will be seemingly unaffected. If at random place
in some library gcc vectorizes something and that random place will be called
from any of the above code, the crash will happen. So you'll get crashes at
random points.

To turn these random crashes into deterministic crashes, I suggest to try this.
Hack gcc to generate test $15, %esp; jnz abort at the beginning of every
function. Compile the whole Linux distribution with this gcc. Test it
(including various 3rd party Linux program). If it works, come back later to
this debate and propose how stacks should be 16-byte aligned.


-- 


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

[Bug target/38496] Gcc misaligns arrays when stack is forced follow the x8632 ABI

[jakub at gcc dot gnu dot org]

------- Comment #22 from jakub at gcc dot gnu dot org  2009-07-23 13:13 -------
*** Bug 40838 has been marked as a duplicate of this bug. ***


-- 

jakub at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mikulas at artax dot karlin
                   |                            |dot mff dot cuni dot cz


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

[Bug target/38496] Gcc misaligns arrays when stack is forced follow the x8632 ABI

[sliwa at cft dot edu dot pl]

------- Comment #21 from sliwa at cft dot edu dot pl  2009-03-18 13:25 -------
Yes, yes, using gcc has to be pain in the neck.

You are reluctant to fix an obvious mistake and instead of saying "sorry" are
keeping it broken.


-- 


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

[Bug target/38496] Gcc misaligns arrays when stack is forced follow the x8632 ABI

[joseph at codesourcery dot com]

------- Comment #20 from joseph at codesourcery dot com  2008-12-16 00:09 -------
Subject: Re:  Gcc misaligns arrays when stack is forced
 follow the x8632 ABI

On Mon, 15 Dec 2008, whaley at cs dot utsa dot edu wrote:

> If you thought the standard adopted by LSB was the wrong
> one, you should have participated in the process and fixed it.

Nonsense.  It's not the responsibility of the GCC community or any of its 
members to correct the misconceptions of any or all third parties, and 
never had been.  There is no more responsibility to correct LSB's mistakes 
than to correct misconceptions about the ABI written in a random webpage, 
student project or magazine article.  Both have exactly the same status as 
irrelevant to GCC unless and until GCC chooses to treat them as relevant.  
Millions of people write huge amounts of inaccurate information about 
things they don't understand and those who understand them have no 
responsibility to correct the information; the LSB and the IA32 GNU/Linux 
ABI is just one random such case among millions, with no special status.


-- 


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

[Bug target/38496] Gcc misaligns arrays when stack is forced follow the x8632 ABI

[whaley at cs dot utsa dot edu]

------- Comment #19 from whaley at cs dot utsa dot edu  2008-12-15 23:39 -------
>There is the problem, LSB did the incorrect thing of thinking the written standard applied to what really was being done when the LSB was doing its work.  Standards are made to be amended.  Witness how many RFCs there are and how many make previous ones outdated.

Actually, standards are made to make interoperation work, which only works if
people follow them.  Amending is fine, ignoring or extending them without
amending them is not.  The idea that LSB made the error rather than you folks
is hubris at best.  If you thought the standard adopted by LSB was the wrong
one, you should have participated in the process and fixed it.  It would have
been difficult on this stack point, because the convenience of avoiding two
operations in the preamble and one in the epilogue would almost certainly have
convinced any standards body to break backwards compatibility (and this ABI
standard has been around a long while).

gcc used to follow this standard, and later decided to break it.  You guys are
saying that not only do you not follow this standard, but you don't follow
*any* ABI standard.  OK, but don't tell me its because there is/was no
standard, because there both is and was.  Don't tell me it cannot be used with
modern architectures, because it obviously can.  Don't tell me its everyone
else's fault, and you guys are doing the right thing.  You broke a standard you
used to follow for the convenience of having an aligned stack (as your
contemporaneous e-mail shows), so you lost standards compliance for essentially
zero gain.  You are of course free to make your compiler do anything you want
to do, but this BS about their being no standard, or the standard being
unusable with SSE does not cut it.

Thanks,
Clint


-- 


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

[Bug target/38496] Gcc misaligns arrays when stack is forced follow the x8632 ABI

[pinskia at gmail dot com]

------- Comment #18 from pinskia at gmail dot com  2008-12-15 23:02 -------
Subject: Re:  Gcc misaligns arrays when stack is forced follow the x8632 ABI

On Mon, Dec 15, 2008 at 2:01 PM, whaley at cs dot utsa dot edu
<gcc-bugzilla@gcc.gnu.org> wrote:
> LSB was merely the umbrella bringing together a bunch of pre-existing standards
> for use in Linux.

There is the problem, LSB did the incorrect thing of thinking the
written standard applied to what really was being done when the LSB
was doing its work.  Standards are made to be amended.  Witness how
many RFCs there are and how many make previous ones outdated.

Thanks,
Andrew Pinski


-- 


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

Re: [Bug target/38496] Gcc misaligns arrays when stack is forced follow the x8632 ABI

[Andrew Pinski]

On Mon, Dec 15, 2008 at 2:01 PM, whaley at cs dot utsa dot edu
<gcc-bugzilla@gcc.gnu.org> wrote:
> LSB was merely the umbrella bringing together a bunch of pre-existing standards
> for use in Linux.

There is the problem, LSB did the incorrect thing of thinking the
written standard applied to what really was being done when the LSB
was doing its work.  Standards are made to be amended.  Witness how
many RFCs there are and how many make previous ones outdated.

Thanks,
Andrew Pinski

[Bug target/38496] Gcc misaligns arrays when stack is forced follow the x8632 ABI

[whaley at cs dot utsa dot edu]

------- Comment #17 from whaley at cs dot utsa dot edu  2008-12-15 22:01 -------
>LSB was written years after we had already did this back in gcc 3.0.  
>Please check the history before saying gcc followed a written standard  
>when none existed when this change was done.

LSB was merely the umbrella bringing together a bunch of pre-existing standards
for use in Linux.  I believe the ABI in question was done in 1997.  Is it your
position that gcc predates this standard, and follows it in every aspect save
stack alignment by pure chance?  You are correct that I do not have all the
history of gcc at my fingertips, but I rather suspect you do not as well.


-- 


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

[Bug target/38496] Gcc misaligns arrays when stack is forced follow the x8632 ABI

[pinskia at gmail dot com]

------- Comment #16 from pinskia at gmail dot com  2008-12-15 21:39 -------
Subject: Re:  Gcc misaligns arrays when stack is forced follow the x8632 ABI



Sent from my iPhone

On Dec 15, 2008, at 1:33 PM, "whaley at cs dot utsa dot edu"
<gcc-bugzilla@gcc.gnu.org 
 > wrote:

>
>
> ------- Comment #15 from whaley at cs dot utsa dot edu  2008-12-15  
> 21:32 -------
>> GCC chose to change the *unwritten* standard for the ABI in use for  
>> IA32 GNU/Linux.
>
> This is not true.  Prior to this change, gcc followed the *written*  
> standard
> provided by the LSB.

LSB was written years after we had already did this back in gcc 3.0.  
Please check the history before saying gcc followed a written standard  
when none existed when this change was done.

> You chose to violate the standard, or to put as you seem
> to prefer, you chose to declare that you followed no standard, as  
> the written
> standard previously used by pretty much all OSes on the x86 was  
> suddenly
> unusable.
>
>> The SCO document may have been useful before SSE, but processor  
>> architecture and language developments have made it problematic for  
>> many years.
>
> This is not even trivially true.  SSE requires no change in the ABI  
> to support:
> it is purely convenience to start with a known 16-byte alignment: an  
> andb and a
> register save/restore fixes the problem completely, without  
> abandoning the
> standard.  I believe gcc still abides by this "problematic for many  
> years"
> standard in all respects except stack alignment, which is a trivial  
> problem to
> solve and still abide by the standard.  So, you abandoned standard  
> compliance
> to solve a minor irritant, that you yourself have fixed in the new  
> 4.4 series.
> From 4.4 on, you broke the standard for no gain at all, since you  
> have now
> added the minor complexity of manually aligning the stack anyway.
>
> Of course the standard seems outdated to us: it is supporting an  
> architecture
> that is decades old, and that is the strength of it.  If you want  
> the shiny new
> stuff, you go to x86-64.
>
>
> -- 
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38496
>


-- 


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

Re: [Bug target/38496] Gcc misaligns arrays when stack is forced follow the x8632 ABI

[Andrew Thomas Pinski]

Sent from my iPhone

On Dec 15, 2008, at 1:33 PM, "whaley at cs dot utsa dot edu" <gcc-bugzilla@gcc.gnu.org 
 > wrote:

>
>
> ------- Comment #15 from whaley at cs dot utsa dot edu  2008-12-15  
> 21:32 -------
>> GCC chose to change the *unwritten* standard for the ABI in use for  
>> IA32 GNU/Linux.
>
> This is not true.  Prior to this change, gcc followed the *written*  
> standard
> provided by the LSB.

LSB was written years after we had already did this back in gcc 3.0.  
Please check the history before saying gcc followed a written standard  
when none existed when this change was done.

> You chose to violate the standard, or to put as you seem
> to prefer, you chose to declare that you followed no standard, as  
> the written
> standard previously used by pretty much all OSes on the x86 was  
> suddenly
> unusable.
>
>> The SCO document may have been useful before SSE, but processor  
>> architecture and language developments have made it problematic for  
>> many years.
>
> This is not even trivially true.  SSE requires no change in the ABI  
> to support:
> it is purely convenience to start with a known 16-byte alignment: an  
> andb and a
> register save/restore fixes the problem completely, without  
> abandoning the
> standard.  I believe gcc still abides by this "problematic for many  
> years"
> standard in all respects except stack alignment, which is a trivial  
> problem to
> solve and still abide by the standard.  So, you abandoned standard  
> compliance
> to solve a minor irritant, that you yourself have fixed in the new  
> 4.4 series.
> From 4.4 on, you broke the standard for no gain at all, since you  
> have now
> added the minor complexity of manually aligning the stack anyway.
>
> Of course the standard seems outdated to us: it is supporting an  
> architecture
> that is decades old, and that is the strength of it.  If you want  
> the shiny new
> stuff, you go to x86-64.
>
>
> -- 
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38496
>

[Bug target/38496] Gcc misaligns arrays when stack is forced follow the x8632 ABI

[whaley at cs dot utsa dot edu]

------- Comment #15 from whaley at cs dot utsa dot edu  2008-12-15 21:32 -------
>GCC chose to change the *unwritten* standard for the ABI in use for IA32 GNU/Linux.

This is not true.  Prior to this change, gcc followed the *written* standard
provided by the LSB.  You chose to violate the standard, or to put as you seem
to prefer, you chose to declare that you followed no standard, as the written
standard previously used by pretty much all OSes on the x86 was suddenly
unusable.

>The SCO document may have been useful before SSE, but processor architecture and language developments have made it problematic for many years.

This is not even trivially true.  SSE requires no change in the ABI to support:
it is purely convenience to start with a known 16-byte alignment: an andb and a
register save/restore fixes the problem completely, without abandoning the
standard.  I believe gcc still abides by this "problematic for many years"
standard in all respects except stack alignment, which is a trivial problem to
solve and still abide by the standard.  So, you abandoned standard compliance
to solve a minor irritant, that you yourself have fixed in the new 4.4 series. 
>From 4.4 on, you broke the standard for no gain at all, since you have now
added the minor complexity of manually aligning the stack anyway.

Of course the standard seems outdated to us: it is supporting an architecture
that is decades old, and that is the strength of it.  If you want the shiny new
stuff, you go to x86-64.


-- 


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

[Bug target/38496] Gcc misaligns arrays when stack is forced follow the x8632 ABI

[joseph at codesourcery dot com]

------- Comment #14 from joseph at codesourcery dot com  2008-12-15 18:17 -------
Subject: Re:  Gcc misaligns arrays when stack is forced
 follow the x8632 ABI

On Mon, 15 Dec 2008, whaley at cs dot utsa dot edu wrote:

> And also one without application here.  I am aware of no other standard for
> Linux ABI other than the one in the linux standard base.  Gcc did not choose
> another standard, it violated the one and only existing standard.  I am not

GCC chose to change the *unwritten* standard for the ABI in use for IA32 
GNU/Linux.  The LSB is not a plausible candidate for a written standard 
for that ABI; the set of such candidates is presently empty.  Maybe if 
there were a document supported by relevant stakeholders then it would be 
of value to follow it, but the LSB doesn't have that support (see also 
Ulrich's comments); it is effectively an attempt by third parties to 
observe the ABI and document their imperfect observations.

Just because no-one has written a useful standard document in a particular 
area does not mean a document that is not presently useful or accurate 
should be followed.  The ABI is undocumented; that is reality.  LSB is a 
good-faith attempt to document it, but for LSB to be useful for its 
intended purpose it needs to keep playing catch-up with reality.  The SCO 
document may have been useful before SSE, but processor architecture and 
language developments have made it problematic for many years.  The set of 
ABI standards suitable for use on IA32 GNU/Linux has been empty for many 
years.  For it to cease to be empty a document would need to be written 
that reflects reality and there would need to be long-term commitment from 
many interested parties to keep the document and the implementation in 
sync in future.  (A document that does not reflect reality would require 
even more commitment, to make an incompatible break from previous ABIs in 
use to move to a newer cleaner ABI.)


-- 


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

[Bug target/38496] Gcc misaligns arrays when stack is forced follow the x8632 ABI

[whaley at cs dot utsa dot edu]

------- Comment #13 from whaley at cs dot utsa dot edu  2008-12-15 14:52 -------
>No; "The nice thing about standards is that there are so many to choose from" is a well-known saying.

And also one without application here.  I am aware of no other standard for
Linux ABI other than the one in the linux standard base.  Gcc did not choose
another standard, it violated the one and only existing standard.  I am not
arguing that standards should never be changed, but rather that you shouldn't
violate an existing one without reason.  The reason gcc had to make this change
is mere convenience (it keeps you from doing a bit-level operation and a
register save in the preamble), which is not near strong enough a reason to
take something that used to support the standard (gcc before this decision) and
make it support absolutely no standard (your position now).  Please try to
avoid the mischaracterizations you are making: you have not switched from
standard A to standard B, you have switched from standard A to no standard.

>Then you should have made it clear much earlier in this discussion that
>Windows is your concern.  Because there is no one ABI for "i?86-*-*", and
>an ABI written for ELF-based Unix systems 1990-1996 is far, far less
>relevant to PECOFF-based Windows in 2008 than the limited relevance to
>Linux in 2008.

Actually, both windows and the linux base ABI handle arguments the exact same
way.  So, until gcc arbitrarily stopped supporting the standard, there *was*
uniformity in the x86 world . . .

But, it appears to me that while your standards compliance is permantly broken
(due, ironically, for backwards compatibility with your previous decision), the
problem I was having with gcc misaligning arrays when a standard-compliant ABI
is requested, has at least been solved in gcc 4.4.


-- 


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

[Bug target/38496] Gcc misaligns arrays when stack is forced follow the x8632 ABI

[joseph at codesourcery dot com]

------- Comment #12 from joseph at codesourcery dot com  2008-12-15 00:21 -------
Subject: Re:  Gcc misaligns arrays when stack is forced
 follow the x8632 ABI

On Fri, 12 Dec 2008, whaley at cs dot utsa dot edu wrote:

> >LSB may be a starting point for plausible hypotheses about the ABIs, but 
> >you need to evaluate it critically to see whether each statement is 
> >actually an accurate description of fact.
> 
> I.e., you are saying "we don't adhere to any standards: whatever we do is the
> standard".  Again, I wonder how you feel about that attitude when microsoft

No; "The nice thing about standards is that there are so many to choose 
from" is a well-known saying.  GCC chooses certain standards and documents 
those choices in the manuals.  For the >99.9999% of standards not 
documented as being used by GCC, you should not assume they have been 
chosen, or that they are of any more relevance to GCC than the standard 
for making a cup of tea.  Not choosing to implement a standard is not a 
bug - GCC does not make tea - though you might have a feature request to 
implement a new feature where a particular standard is followed.  You are 
free to procure software on the basis of which of many standards it 
chooses to implement and how accurately it does so; if producers of 
compilers that do not make tea find that compilers making tea are more 
widely used because they make tea, this may cause the tea-making feature 
to be added to more compilers.

Anyone can write a document that says anything and put any title on it.  
Anyone else can write a contradictory document with the same title and 
claim that document instead is the true standard.  That someone has 
written such a document gives it no special status for GCC whatever.  
There is nothing magical about being a "standard"; it's just another 
document describing something that may or may not be useful, may or may 
not describe something a particular piece of software aims to implement, 
and may or may not describe what a particular piece of software does 
implement.  If multiple implementations choose to try to implement the 
same document, or if it has been prepared to match what implementations 
do, it may then be of use in describing how to interoperate with those 
implementations.  If it was written to describe how someone wishes things 
would work but they don't work that way, any influence they have to change 
how things work will have to come from a source other than that they have 
written down their wishes and put the word "standard" wishfully on them.

> says it?  Would you like to argue that ODF is useless, since MSOffice binary
> formats are more accurate description of fact?  I don't like it when MS

ODF is useless for interoperating with MS Office if MS Office does not 
choose to use that standard for interoperation.  That's obviously a choice 
for the MS Office maintainers.  Anyone can invent a document format, write 
a description and call that description a standard, but writing the 
description doesn't make it any more or less appropriate for MS Office to 
implement the format.

Where OOXML differs from the formats in fact used by MS Office, this may 
very well be a bug in the specification, whose only use is likely to be 
interoperating with MS Office.  If all implementations of ODF do the same 
thing which contradicts the literal text of ODF, that is likely to be a 
bug in the specification as well, since the text is not serving the 
purpose of interoperation.

> kind of boggles my mind.  If a standard is out of date, you write a new
> standard, or admit you are violating it in certain respects, not make the
> absurd claim that whatever you happen to like doing this week is the standard.

GCC's manuals "violate" the ODF specification you mentioned above by being 
in Texinfo.  This is not a bug; it's simply there are millions of 
"standards" and almost all are more or less completely irrelevant to GCC.  
GCC no longer supports SCO Unix, so even if the document you like was an 
accurate description of how to interoperate with SCO Unix versions from 
1996 that does not make it relevant to GCC.

Anyone with the person-years to spend is free to write their own "new 
standard" describing what they think a particular ABI should be.  There is 
no particular reason for anyone else to care about that document unless it 
reflects reality or there is a genuine commitment from multiple involved 
parties to implement the document where it describes something different 
from reality.  That might apply, for example, if direction comes from the 
CPU vendor with agreement of multiple involved parties (c.f. the ARM EABI, 
or the Power.org effort I mentioned); maybe those producing x86 processors 
would like to coordinate the person-years of effort needed either to write 
a specification accurately describing the present ABI or develop a new and 
incompatible better ABI.  (The SCO copyrights prevent just patching the 
existing document, even if much of it could otherwise be reused.)

> Unfortunately, the place this problem is killing me is Windows, where I believe

Then you should have made it clear much earlier in this discussion that 
Windows is your concern.  Because there is no one ABI for "i?86-*-*", and 
an ABI written for ELF-based Unix systems 1990-1996 is far, far less 
relevant to PECOFF-based Windows in 2008 than the limited relevance to 
Linux in 2008.  You should rather be looking to Windows ABI documentation 
that may have been released by Microsoft, not SCO, and seeing if it 
correctly describes what is needed to interoperate with other tools for 
Windows.  (But remember that *-*-mingw* deliberately chooses backwards 
compatibility by default over full Windows ABI compatibility; see the 
discussion of the patch for PR 36834.  Note how there are many different 
Windows-specific calling conventions, that Unix ABIs aren't going to 
address at all.)

It would be quite right for the -mms-compat option suggested in that 
thread to do whatever is needed with stack alignment to interoperate with 
other Windows compilers.  If those follow an ABI document from MS then 
following that document with -mms-compat would be right.  If there is such 
a document but it does not reflect the reality of what Windows compilers 
(in particular from MS) generally do then following reality with 
-mms-compat would be right.  But -mms-compat would be a new feature; MinGW 
is a platform, interoperable with itself and with various Windows DLLs so 
it can produce binaries that work on Windows without needing any DLLs not 
provided with Windows rather than perfectly interoperating with all 
Windows objects, and Cygwin is even more its own platform.  Feel free to 
contribute patches to implement such a new feature if you would find it 
useful.


-- 


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

[Bug target/38496] Gcc misaligns arrays when stack is forced follow the x8632 ABI

[whaley at cs dot utsa dot edu]

------- Comment #11 from whaley at cs dot utsa dot edu  2008-12-12 01:48 -------
>LSB may be a starting point for plausible hypotheses about the ABIs, but 
>you need to evaluate it critically to see whether each statement is 
>actually an accurate description of fact.

I.e., you are saying "we don't adhere to any standards: whatever we do is the
standard".  Again, I wonder how you feel about that attitude when microsoft
says it?  Would you like to argue that ODF is useless, since MSOffice binary
formats are more accurate description of fact?  I don't like it when MS
purposely breaks a standard, and to find myself arguing with (I guess) another
open/free software guy that ignoring the standard is the correct thing to do,
kind of boggles my mind.  If a standard is out of date, you write a new
standard, or admit you are violating it in certain respects, not make the
absurd claim that whatever you happen to like doing this week is the standard.

Thanks to Lu for the pointer about better alignment behavior in later gccs. 
Unfortunately, the place this problem is killing me is Windows, where I believe
they are still rocking along with g77, and gcc 3.x . . .  

Thanks,
Clint


-- 


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

[Bug target/38496] Gcc misaligns arrays when stack is forced follow the x8632 ABI

[joseph at codesourcery dot com]

------- Comment #10 from joseph at codesourcery dot com  2008-12-12 01:25 -------
Subject: Re:  Gcc misaligns arrays when stack is forced
 follow the x8632 ABI

On Fri, 12 Dec 2008, whaley at cs dot utsa dot edu wrote:

> >I suppose that by "32-bit ABI for the x86" you mean a document with
> >1990-1996 SCO copyrights.
> 
> I was going by the linux standards base, which still links to:
>    http://www.caldera.com/developers/devspecs/abi386-4.pdf
> which I believe is still the current official ABI of Linux.
> 
> >This document should be considered of only marginal relevant to current
> >systems; it may have described an ABI for some particular system that is
> >>now obsolete, but is not an accurate description of (for example) the ABI
> >used on IA32 GNU/Linux
> 
> I thought that was precisely what the linux standards base was, and it says
> word (4-byte) alignment of the stack.

LSB is not of much practical relevance to Linux ABIs and is not maintained 
by the people who are actually familiar with those ABIs.  That's apart 
from all the other problems with it as mentioned e.g. at 
<http://udrepper.livejournal.com/8511.html>.

LSB may be a starting point for plausible hypotheses about the ABIs, but 
you need to evaluate it critically to see whether each statement is 
actually an accurate description of fact.  For another example, on 32-bit 
Power Architecture it references a 1995 Sun document - maybe that was 
right for PowerPC Solaris in 1995, but as a member of the Power.org 
working group preparing a document intended to describe the actual current 
ABI I can confidently say the 1995 document is substantially misleading 
regarding the true GNU/Linux ABI in use today.

> >which is a de facto ABI with no written document corresponding precisely.
> 
> This is a link where people mention that fact that gcc is behaving
> non-standardly, so people who want to interoperate with gcc better adopt their
> non-standard behavior.  How do you like it when MS does that?  It seems
> incredibly foolish to me that just because gcc doesn't want to do some trivial
> bit twiddling in the function prologue, you've decided to break the ABI, all so
> that you can lose performance when people need ABI compliance, as well as
> making interoperation much harder for everyone.

I would fully expect that the ABI for working with Windows is that used by 
the present MS compilers and libraries, and if the only ABI documents 
available are 12 years old (I haven't looked) I would consider them of 
limited relevance for determining the current Windows ABI.

The Power.org ABI working group has been going now for two years.  
Producing an accurate current ABI document where one hasn't been 
maintained for over a decade is a lot of work.  If done for IA32 GNU/Linux 
I fully expect it would document that the ABI has 16-byte stack alignment.  
And if some disagreement between code and ABI document were found after 
such a document were written, the fix might well be to change the document 
rather than the code.  Effectively, decisions such as the 16-byte 
alignment one have been made over the years, probably many times, that the 
documentation rather than the code should be changed - and unless and 
until there is a major effect to create a new ABI document, all those 
documentation changes are hidden and queued up and not collected in one 
place.  But each such decision is one that the bug is in the document not 
the code.  And the decision about where the bug lies is not substantially 
influenced by whether the document can in fact be changed or not.

See also Linus's recent comments <http://lkml.org/lkml/2008/12/1/387>.  
The "wrong documentation is irrelevant" applies equally here.  The SCO ABI 
is wrong documentation when Linux in 2008 is concerned, even if it was 
right for SCO Unix in 1996.  If it is the ABI for any system, Linux in 
2008 is not that system, and when looking at it you always need to be 
aware that it describes not the Linux ABI but one with some vague 
similarities to it.


-- 


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

[Bug target/38496] Gcc misaligns arrays when stack is forced follow the x8632 ABI

[hjl dot tools at gmail dot com]

------- Comment #9 from hjl dot tools at gmail dot com  2008-12-12 01:05 -------
(In reply to comment #8)
>
> This is a link where people mention that fact that gcc is behaving
> non-standardly, so people who want to interoperate with gcc better adopt their
> non-standard behavior.  How do you like it when MS does that?  It seems
> incredibly foolish to me that just because gcc doesn't want to do some trivial
> bit twiddling in the function prologue, you've decided to break the ABI, all so
> that you can lose performance when people need ABI compliance, as well as
> making interoperation much harder for everyone.
> 

It was a very unfortunate oversight to require 16byte stack alignment
while ABI only specifies 4 byte.  This problem has been fixed in gcc
4.4 and above. You can safely use -mpreferred-stack-boundary=2 with
gcc 4.4 and all stack variables will be properly aligned.  However,
we can't change the default back to 4 byte since it will break the
existing libraries/applications which expect 16byte aligned incoming
stack.


-- 

hjl dot tools at gmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hjl dot tools at gmail dot
                   |                            |com
OtherBugsDependingO|                            |33721
              nThis|                            |
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |WONTFIX


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

[Bug target/38496] Gcc misaligns arrays when stack is forced follow the x8632 ABI

[whaley at cs dot utsa dot edu]

------- Comment #8 from whaley at cs dot utsa dot edu  2008-12-12 00:51 -------
>I suppose that by "32-bit ABI for the x86" you mean a document with
>1990-1996 SCO copyrights.

I was going by the linux standards base, which still links to:
   http://www.caldera.com/developers/devspecs/abi386-4.pdf
which I believe is still the current official ABI of Linux.

>This document should be considered of only marginal relevant to current
>systems; it may have described an ABI for some particular system that is
>>now obsolete, but is not an accurate description of (for example) the ABI
>used on IA32 GNU/Linux

I thought that was precisely what the linux standards base was, and it says
word (4-byte) alignment of the stack.

>which is a de facto ABI with no written document corresponding precisely.

This is a link where people mention that fact that gcc is behaving
non-standardly, so people who want to interoperate with gcc better adopt their
non-standard behavior.  How do you like it when MS does that?  It seems
incredibly foolish to me that just because gcc doesn't want to do some trivial
bit twiddling in the function prologue, you've decided to break the ABI, all so
that you can lose performance when people need ABI compliance, as well as
making interoperation much harder for everyone.


-- 


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

[Bug target/38496] Gcc misaligns arrays when stack is forced follow the x8632 ABI

[joseph at codesourcery dot com]

------- Comment #7 from joseph at codesourcery dot com  2008-12-12 00:01 -------
Subject: Re:   New: Gcc misaligns arrays when stack is
 forced follow the x8632 ABI

On Thu, 11 Dec 2008, whaley at cs dot utsa dot edu wrote:

> I notice that gcc does not follow the 32-bit ABI for the x86, in that it forces
> the stack alignment to 16 bytes rather than the ABI-required 4 bytes.  This is
> a problem when interacting with compilers that are ABI-compliant.

I suppose that by "32-bit ABI for the x86" you mean a document with 
1990-1996 SCO copyrights.

This document should be considered of only marginal relevant to current 
systems; it may have described an ABI for some particular system that is 
now obsolete, but is not an accurate description of (for example) the ABI 
used on IA32 GNU/Linux, which is a de facto ABI with no written document 
corresponding precisely.  
<http://groups.google.com/group/ia32-abi/browse_thread/thread/4f9b3e5069943bf1> 
(and the messages linked from it) is a description of this area of the de 
facto ABI.

In principle GCC's documentation should for all target systems give a 
description of the ABI it is intended to implement for those systems with 
links to relevant documents and descriptions of how the ABI deviates from 
those documents.  In practice, it does not, but it is still the case that 
just because there exists a document claiming to be a psABI for a 
particular processor does not mean that GCC follows it or that it would be 
correct for GCC to follow it.  The older the document, the less likely it 
is relevant; some ABIs such as x86-64 are actively maintained (meaning 
that defects in the ABI document may be fixed - a disagreement between 
implementations and documents may be concluded to be a defect on either or 
both sides) while others are not.


-- 


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

[Bug target/38496] Gcc misaligns arrays when stack is forced follow the x8632 ABI

[whaley at cs dot utsa dot edu]

------- Comment #6 from whaley at cs dot utsa dot edu  2008-12-11 23:42 -------
>GCC can and will realign the loop in 4.4 and above if the function needs a bigger alignment than the required 4 byte.  So again I don't see any issues here really.

Is this the response to another request?  I am not talking about loops, but
arrays  . . .

At least when I run the demonstration tarfile above, gcc gives me 4-byte
aligned double arrays, even though -malign-double has been thrown, but give me
8-byte aligned arrays when I don't ask for an ABI-compliant stack.


-- 


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

[Bug target/38496] Gcc misaligns arrays when stack is forced follow the x8632 ABI

[pinskia at gcc dot gnu dot org]

------- Comment #5 from pinskia at gcc dot gnu dot org  2008-12-11 23:28 -------
GCC can and will realign the loop in 4.4 and above if the function needs a
bigger alignment than the required 4 byte.  So again I don't see any issues
here really.


-- 


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

[Bug target/38496] Gcc misaligns arrays when stack is forced follow the x8632 ABI

[whaley at cs dot utsa dot edu]

------- Comment #4 from whaley at cs dot utsa dot edu  2008-12-11 23:25 -------
>aligning the stack to 16 bytes is complaint

It might be complaint, but it certainly isn't compliant.  The ABI says that you
can assume 4-byte alignment, and not all 4-byte alignments are 16-byte aligned
(obviously).  Therefore, by assuming 16-byte alignment, gcc is not compliant
with the ABI.

The whole point of an ABI is so that code knows how to call each other.  The
place I know this happens is Windows, which follows the ABI and aligns the
stack to 4-byte boundaries.  Therefore, when a windows-compiled library
attempts to call a gcc-compiled routine, the gcc-compiled routine seg
faults/bus errors because it assumes an alignment that is not specified by the
ABI.

>> generates double precision arrays that are not aligned to 8-byte boundaries
>That is ok.  There is no interoperability here really. 

The problem for interoperability is that every sane compiler forces all array
boundaries to a multiple of the underlying type, to avoid cache line splits,
which essentially double the cost of a load.  I am aware that neither the C nor
Fortran standards guarantee native alignment, but every cache-based
architecture needs it for good performance and thus most code assumes it.  So,
aligning to 4-byte boundary is not OK (cache line splits), and it does cause
interoperability problems (code expects native alignment for arrays).

>Now with -malign-double they will get aligned but you just changed the ABI to have that requirement.

No, with -malign-double, they are still not aligned.  Wanting to follow the ABI
should not preclude native alignment on arrays.  Are you saying that when you
pass -malign-double with stack-boundary=2, you get 8-byte aligned arrays?

Thanks,
Clint


-- 


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

[Bug target/38496] Gcc misaligns arrays when stack is forced follow the x8632 ABI

[pinskia at gcc dot gnu dot org]

------- Comment #3 from pinskia at gcc dot gnu dot org  2008-12-11 23:04 -------
Your testcase does not show any issues at all.  doubles are not required to be
aligned to 8 byte boundaries at all, they are only required to be aligned to 4
byte boundaries.  Now with -malign-double they will get aligned but you just
changed the ABI to have that requirement.


-- 


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

[Bug target/38496] Gcc misaligns arrays when stack is forced follow the x8632 ABI

[pinskia at gcc dot gnu dot org]

------- Comment #2 from pinskia at gcc dot gnu dot org  2008-12-11 23:02 -------
aligning the stack to 16 bytes is complaint.
> generates double precision arrays that are not aligned to 8-byte boundaries

That is ok.  There is no interoperability here really.  

>This is a problem when interacting with compilers that are ABI-compliant.
Not really.  Can you show where it is an issue because right now you have not
given enough information to show there is an ABI issue.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|fortran                     |target
 GCC target triplet|                            |i?86-*-*
           Keywords|                            |ABI


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