This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug lto/50494] gcc.dg/vect/vect-reduc-2char.c fails spuriously on ppc with -flto
- From: "meissner at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Wed, 13 Feb 2013 22:38:12 +0000
- Subject: [Bug lto/50494] gcc.dg/vect/vect-reduc-2char.c fails spuriously on ppc with -flto
- Auto-submitted: auto-generated
- References: <bug-50494-4@http.gcc.gnu.org/bugzilla/>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50494
--- Comment #15 from Michael Meissner <meissner at gcc dot gnu.org> 2013-02-13 22:38:12 UTC ---
The patch does align the .rodata section to 16 byte alignment, but the code to
load up the auto vector from constant memory does not do vectorization.
If I use -fno-section-anchors, it aligns .rodata to 4 byte alignment, and does
not vectorize the code.
If I use -fno-merge-constants, it aligns .rodata to 16 byte alignment, and does
vectorize the code.
If I use -fno-merge-constants without -flto, it aligns .rodata to 16 byte
alignment, but it uses unaligned vector loads/stores.
So the patch does help in that the tests now pass that were randomly failing.
While it would be nice if we could get the initialization to be vectorized, I'm
not how performance critical this is.
Eric: if the alignment of the constant data that is used to initialize the auto
array is a mismatch, and you use Altivec instructions, when the compiler
auto-vectorizes the copy, the wrong data gets used.