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

["joseph at codesourcery dot com" <gcc-bugzilla at gcc dot gnu dot org>]

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