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