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