Richard Guenther <richard.guent...@gmail.com> writes: > On Thu, Apr 5, 2012 at 6:22 AM, Mike Stump <mikest...@comcast.net> wrote: >> On Apr 4, 2012, at 7:56 PM, William J. Schmidt wrote: >>> There seems to be tacit agreement that the vector tests should use >>> -fno-common on all targets to avoid the recent spate of failures (see >>> discussion in 52571 and 52603). >> >>> OK for trunk? >> >> Ok. Any other solution I think will be real work and we shouldn't loose the >> testing between now and then by not having the test cases working. > > Ian, you are the "source" of all of these problems. While I did not notice > any degradations in SPEC (on x86) with handling commons "correctly" > now, the fact > that our testsuite needs -fno-common to make things vectorizable shows > that users might be impacted negatively by this, which is only a real problem > in corner cases. Why can the link editor not promote the definitions > alignment > when merging with a common with bigger alignment?
The defined symbol will be embedded in a data section along with other defined data symbols, at some offset O from the start of the section. The data section will have a required alignment A. It is entirely possible that there is no way to honor A and also ensure that A+O is aligned as requested by the common symbol. This whole issue only applies to vectorization involving global symbols defined with no initializer in C, when vectorization requires an alignment greater than that implied by the type of the symbol. It does not affect function arguments or local variables. It does not affect C++. Is vectorization of uninitialized global symbols really a common case? Another approach we could use is to say that when the vectorizer wants to increase the alignment of a common symbol, it would force the symbol to be defined rather than common. That would be safe, as it would lead to a multiple-definition error at link time in cases where it would be unsafe. I would be fine with making the compiler work that way for C, although of course there would have to be an option to disable it. I don't know enough about Fortran to know whether the same issues arise there. Perhaps in Fortran a common symbol is always a common symbol and can never be a defined symbol. If that is the case then for Fortran I think it would be safe to change the alignment of the common symbol. Of course we would need to have some way to indicate that in the middle-end--DECL_ALWAYS_COMMON or something. Ian
