[Bug target/64172] [4.9/5 Regression] Wrong code with GCC vector extensions on ARM when compiled without NEON
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64172 --- Comment #14 from Vladimir Makarov vmakarov at gcc dot gnu.org --- Author: vmakarov Date: Fri Feb 20 18:59:02 2015 New Revision: 220877 URL: https://gcc.gnu.org/viewcvs?rev=220877root=gccview=rev Log: 2015-02-20 Vladimir Makarov vmaka...@redhat.com PR target/64172 * ira-color.c (color_pass): Prevent splitting multi-register pseudos. Modified: trunk/gcc/ChangeLog trunk/gcc/ira-color.c
[Bug target/64172] [4.9/5 Regression] Wrong code with GCC vector extensions on ARM when compiled without NEON
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64172
--- Comment #13 from Vladimir Makarov vmakarov at gcc dot gnu.org ---
I've investigated the generated code. The problem is in IRA live-range
splitting on the region borders. The pseudo to consider is 157 which contains
local_prng.d in the following code
void randmemset (prng_t *prng, uint8_t *buf, size_t size)
{
prng_t local_prng = *prng;
while (size 0)
{
uint32_t e = local_prng.p0.a - ((local_prng.p0.b 27) +
(local_prng.p0.b (32 - 27)));
local_prng.p0.a = local_prng.p0.b ^ ((local_prng.p0.c 17) ^
(local_prng.p0.c (32 - 17)));
local_prng.p0.b = local_prng.p0.c + local_prng.p0.d;
local_prng.p0.c = local_prng.p0.d + e;
local_prng.p0.d = e + local_prng.p0.a;
*buf++ = local_prng.p0.d;
size--;
}
= *prng = local_prng;
}
The pseudo gets different hard regs in different regions
Disposition:
...
8:r155 l0 mem 40:r157 l1 8 25:r157 l2 66:r157 l0 4
...
In the loop above, it gets 6, outside the loop it gets 4. On the exit from the
loop, IRA generates
157:TI = 308:TI
308 is created from 157 to be used in the loop.
The insn is split on 4 insns:
449: r157:TI#0=r308:TI#0
450: r157:TI#4=r308:TI#4
451: r157:TI#8=r308:TI#8
452: r157:TI#12=r308:TI#12
In order words, in terms of hard regs we do 6-4; 7-5; 8-6; 9-7. The two
last insns use wrong values.
I'll think how to fix it better. I hope that the fix will be ready at the end
of next week.
[Bug target/64172] [4.9/5 Regression] Wrong code with GCC vector extensions on ARM when compiled without NEON
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64172 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added Target|arm-none-linux-gnueabi, |arm-none-linux-gnueabi, |arm-none-eabi |arm-none-eabi,arm-none-linu ||x-gnueabihf CC||ramana at gcc dot gnu.org, ||vmakarov at gcc dot gnu.org --- Comment #12 from Ramana Radhakrishnan ramana at gcc dot gnu.org --- Confirmed.
[Bug target/64172] [4.9/5 Regression] Wrong code with GCC vector extensions on ARM when compiled without NEON
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64172 Mikael Pettersson mikpelinux at gmail dot com changed: What|Removed |Added CC||mikpelinux at gmail dot com --- Comment #11 from Mikael Pettersson mikpelinux at gmail dot com --- Started with r204752 (+ r204771 follow-up fix). That patch caused some regressions, but most of them seem to have been latent target bugs.
[Bug target/64172] [4.9/5 Regression] Wrong code with GCC vector extensions on ARM when compiled without NEON
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64172 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P2 --- Comment #10 from Richard Biener rguenth at gcc dot gnu.org --- (In reply to jos...@codesourcery.com from comment #9) On Thu, 4 Dec 2014, ktkachov at gcc dot gnu.org wrote: Hmm, is passing vectors around when vector instructions are not present expected to work? All you need to conform to the VFP AAPCS variant is loads/stores. Even single-precision-only VFP has the required loads/stores to support that AAPCS variant. When fixing up various problems in an early version of the VFP ABI support patch some years ago, one of the things I implemented was making sure generic vector types would be passed the same (which would be the same as the corresponding NEON vector types) whether or not NEON instructions were available. In the current version of the code, I think what's relevant is in aapcs_vfp_sub_candidate: case VECTOR_TYPE: /* Use V2SImode and V4SImode as representatives of all 64-bit and 128-bit vector types, whether or not those modes are supported with the present options. */ The test in the present bug doesn't even seem to have vectors as function arguments / returns so the ABI shouldn't even be involved - I'd have expected the generic vector code to be lowered completely to non-vector code before the back end gets involved. That indeed happens if the target doesn't provide optabs with vector modes. See tree-vect-generic.c.
[Bug target/64172] [4.9/5 Regression] Wrong code with GCC vector extensions on ARM when compiled without NEON
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64172 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code Target||arm-none-linux-gnueabi Target Milestone|--- |4.9.3 Summary|[4.9 Regression] Wrong code |[4.9/5 Regression] Wrong |with GCC vector extensions |code with GCC vector |on ARM when compiled|extensions on ARM when |without NEON|compiled without NEON --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- So it works with GCC 4.8?
[Bug target/64172] [4.9/5 Regression] Wrong code with GCC vector extensions on ARM when compiled without NEON
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64172 --- Comment #3 from Siarhei Siamashka siarhei.siamashka at gmail dot com --- (In reply to Richard Biener from comment #2) So it works with GCC 4.8? Yes, the testcase works with GCC 4.8. It started to fail only with GCC 4.9 and only on ARM hardware. Originally reported at https://bugs.freedesktop.org/show_bug.cgi?id=81229 This looks like some sort of stack corruption, because the assert catches modification of a part of data which is not supposed to be changed in this particular testcase.
[Bug target/64172] [4.9/5 Regression] Wrong code with GCC vector extensions on ARM when compiled without NEON
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64172 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2014-12-04 CC||ktkachov at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #5 from ktkachov at gcc dot gnu.org --- (In reply to ktkachov from comment #4) I can't reproduce with -O2 and -mfpu=neon. And -mfpu=vfp doesn't reproduce for me either I should say
[Bug target/64172] [4.9/5 Regression] Wrong code with GCC vector extensions on ARM when compiled without NEON
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64172 --- Comment #4 from ktkachov at gcc dot gnu.org --- I can't reproduce with -O2 and -mfpu=neon. Can you please give the exact configuration of your GCC? The output of 'arm-none-linux-gnueabi-gcc -v' should be good
[Bug target/64172] [4.9/5 Regression] Wrong code with GCC vector extensions on ARM when compiled without NEON
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64172 --- Comment #6 from Siarhei Siamashka siarhei.siamashka at gmail dot com --- (In reply to ktkachov from comment #4) I can't reproduce with -O2 and -mfpu=neon. Can you please give the exact configuration of your GCC? The output of 'arm-none-linux-gnueabi-gcc -v' should be good My apologies, you are right. Adding -march=armv7-a option appears to be also needed (-O2 -march=armv7-a) and I had it as part of my GCC configuration: Using built-in specs. COLLECT_GCC=arm-none-linux-gnueabi-gcc-4.9.2 COLLECT_LTO_WRAPPER=/usr/libexec/gcc/arm-none-linux-gnueabi/4.9.2/lto-wrapper Target: arm-none-linux-gnueabi Configured with: /var/tmp/portage/cross-arm-none-linux-gnueabi/gcc-4.9.2/work/gcc-4.9.2/configure --host=x86_64-pc-linux-gnu --target=arm-none-linux-gnueabi --build=x86_64-pc-linux-gnu --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/arm-none-linux-gnueabi/gcc-bin/4.9.2 --includedir=/usr/lib/gcc/arm-none-linux-gnueabi/4.9.2/include --datadir=/usr/share/gcc-data/arm-none-linux-gnueabi/4.9.2 --mandir=/usr/share/gcc-data/arm-none-linux-gnueabi/4.9.2/man --infodir=/usr/share/gcc-data/arm-none-linux-gnueabi/4.9.2/info --with-gxx-include-dir=/usr/lib/gcc/arm-none-linux-gnueabi/4.9.2/include/g++-v4 --with-python-dir=/share/gcc-data/arm-none-linux-gnueabi/4.9.2/python --enable-languages=c,c++ --enable-obsolete --enable-secureplt --disable-werror --with-system-zlib --disable-nls --enable-checking=release --with-bugurl=https://bugs.gentoo.org/ --with-pkgversion='Gentoo 4.9.2' --enable-libstdcxx-time --enable-poison-system-directories --with-sysroot=/usr/arm-none-linux-gnueabi --disable-bootstrap --enable-__cxa_atexit --enable-clocale=gnu --disable-multilib --disable-altivec --disable-fixed-point --disable-libgcj --disable-libgomp --disable-libmudflap --disable-libssp --disable-libquadmath --enable-lto --without-cloog --enable-libsanitizer --with-arch=armv7-a --with-float=hard Thread model: posix gcc version 4.9.2 (Gentoo 4.9.2)
[Bug target/64172] [4.9/5 Regression] Wrong code with GCC vector extensions on ARM when compiled without NEON
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64172 ktkachov at gcc dot gnu.org changed: What|Removed |Added Target|arm-none-linux-gnueabi |arm-none-linux-gnueabi, ||arm-none-eabi Status|WAITING |NEW Known to work||4.8.4 Known to fail||4.9.2, 5.0 --- Comment #7 from ktkachov at gcc dot gnu.org --- Thanks, confirmed.
[Bug target/64172] [4.9/5 Regression] Wrong code with GCC vector extensions on ARM when compiled without NEON
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64172 --- Comment #8 from ktkachov at gcc dot gnu.org --- Hmm, is passing vectors around when vector instructions are not present expected to work?
[Bug target/64172] [4.9/5 Regression] Wrong code with GCC vector extensions on ARM when compiled without NEON
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64172 --- Comment #9 from joseph at codesourcery dot com joseph at codesourcery dot com --- On Thu, 4 Dec 2014, ktkachov at gcc dot gnu.org wrote: Hmm, is passing vectors around when vector instructions are not present expected to work? All you need to conform to the VFP AAPCS variant is loads/stores. Even single-precision-only VFP has the required loads/stores to support that AAPCS variant. When fixing up various problems in an early version of the VFP ABI support patch some years ago, one of the things I implemented was making sure generic vector types would be passed the same (which would be the same as the corresponding NEON vector types) whether or not NEON instructions were available. In the current version of the code, I think what's relevant is in aapcs_vfp_sub_candidate: case VECTOR_TYPE: /* Use V2SImode and V4SImode as representatives of all 64-bit and 128-bit vector types, whether or not those modes are supported with the present options. */ The test in the present bug doesn't even seem to have vectors as function arguments / returns so the ABI shouldn't even be involved - I'd have expected the generic vector code to be lowered completely to non-vector code before the back end gets involved.
