[Bug target/38496] Gcc misaligns arrays when stack is forced follow the x8632 ABI
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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
Re: [Bug target/38496] 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-bugzi...@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
--- 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-bugzi...@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
[Bug target/38496] Gcc misaligns arrays when stack is forced follow the x8632 ABI
--- 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
Re: [Bug target/38496] 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-bugzi...@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
--- 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-bugzi...@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
[Bug target/38496] Gcc misaligns arrays when stack is forced follow the x8632 ABI
--- 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
--- 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
--- 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.% 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
[Bug target/38496] Gcc misaligns arrays when stack is forced follow the x8632 ABI
--- 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
[Bug target/38496] Gcc misaligns arrays when stack is forced follow the x8632 ABI
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
