Created attachment 16893 [details]
tarfile demonstrating problem

tarfile containing Makefile, align.f, and printvp.c that can show this problem.

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.

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.

>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

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.

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

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.

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

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

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.

>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

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.

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

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

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

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
>

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

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

>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

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.

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.

*** Bug 40838 has been marked as a duplicate of this bug. ***

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.

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

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

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

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.