[Bug target/54300] [4.7 Regression] Erroneous optimization causes wrong Neon data management

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54300 Eric Batut changed: What|Removed |Added Known to work|4.8.0 | Known to fail|

[Bug target/54300] [4.7 Regression] Erroneous optimization causes wrong Neon data management

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54300 --- Comment #6 from Eric Batut 2013-01-11 10:42:04 UTC --- The patch by Christophe Lyon in the linked email was applied on trunk by Ramana at rev 188951 (June 25th 2012), but gcc-trunk still fails as of today (rev 195102). The vswp instruc

[Bug target/55073] Wrong Neon code generation at -O2 caused by -fschedule-insns

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55073 --- Comment #14 from Eric Batut 2012-11-30 16:20:10 UTC --- Created attachment 28840 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28840 Second repro case with source code, build script, assembly files and binary files

[Bug target/55073] Wrong Neon code generation at -O2 caused by -fschedule-insns

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55073 --- Comment #13 from Eric Batut 2012-11-30 16:16:36 UTC --- Richard, After a clean checkout of gcc's trunk and of the Android NDK r8b package and tools, I rebuilt arm-linux-androideabi-gcc on a Ubuntu VM using gcc 4.5.1. I then rebuilt

[Bug target/55073] Wrong Neon code generation at -O2 caused by -fschedule-insns

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55073 --- Comment #12 from Eric Batut 2012-11-30 15:16:47 UTC --- (In reply to comment #11) > Something else to check is that you are using the version of arm_neon.h that > comes with gcc-4.8. This file has to match the version of GCC it was de

[Bug target/55073] Wrong Neon code generation at -O2 caused by -fschedule-insns

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55073 --- Comment #9 from Eric Batut 2012-11-30 14:29:11 UTC --- Richard, I double-checked (update + rebuild), the end of my assembly files correctly states : .ident"GCC: (GNU) 4.8.0 20121130 (experimental)" Since -O1 is also broken o

[Bug target/55073] Wrong Neon code generation at -O2 caused by -fschedule-insns

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55073 --- Comment #7 from Eric Batut 2012-11-30 13:21:13 UTC --- Richard, I apologize, building at -O0 (and handrolling an assembly routine to do the same computation) proves me wrong : your values are the correct ones, and -O1 is also broken

[Bug target/55073] Wrong Neon code generation at -O2 caused by -fschedule-insns

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55073 --- Comment #6 from Eric Batut 2012-11-30 11:05:18 UTC --- Building the test case at O1 (which I tend to trust slightly more than O2 in the present case) gives the same set of values than the previous "OK" case : root@android:/data # ./r

[Bug target/55073] Wrong Neon code generation at -O2 caused by -fschedule-insns

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55073 --- Comment #5 from Eric Batut 2012-11-30 10:14:00 UTC --- Since this comes from several hours of stripping down a texture generation engine to the single function that provided different results, I must admit I have no idea what the corre

[Bug target/55073] Wrong Neon code generation at -O2 caused by -fschedule-insns

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55073 --- Comment #3 from Eric Batut 2012-11-30 09:52:19 UTC --- Hello Richard I updated my working copy of gcc to rev 193943, rebuilt the compiler, rebuilt the testcase I originally attached to this bug report, and I am still getting differe

[Bug target/54300] [4.7/4.8 Regression] Erroneous optimization causes wrong Neon data management

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54300 --- Comment #4 from Eric Batut 2012-10-25 12:56:33 UTC --- I did the test with -fno-strict-aliasing and the exact same problem occur. Do I need to provide more information on this issue for it to move to the "Confirmed" state? Best Rega

[Bug target/55073] New: Wrong Neon code generation at -O2 caused by -fschedule-insns

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55073 Bug #: 55073 Summary: Wrong Neon code generation at -O2 caused by -fschedule-insns Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIR

[Bug target/54252] [4.7/4.8 Regression] Bad alignment code generated for Neon loads

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54252 --- Comment #8 from Eric Batut 2012-08-30 15:52:20 UTC --- The original bug instance is fixed on trunk (rev 190803). I had what I think is another instance of the same bug, where the error message is "alignment of array elements is greater than e

[Bug target/54300] [4.7/4.8 Regression] Erroneous optimization causes wrong Neon data management

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54300 --- Comment #2 from Eric Batut 2012-08-20 16:11:35 UTC --- (In reply to comment #1) Hi Richard Using "-O2 -fno-strict-aliasing" generates the exact same (incorrect) code. > Your testcase is quite convoluted but it looks you may be violating C

[Bug target/54300] New: [4.7/4.8 Regression] Erroneous optimization causes wrong Neon data management

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54300 Bug #: 54300 Summary: [4.7/4.8 Regression] Erroneous optimization causes wrong Neon data management Classification: Unclassified Product: gcc Version: 4.8.0 Status: U

[Bug target/54252] New: [Neon] Bad alignment code generated for Neon loads

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54252 Bug #: 54252 Summary: [Neon] Bad alignment code generated for Neon loads Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: major

[Bug target/51980] ARM - Neon code polluted by useless stores to the stack with vuzpq / vzipq / vtrnq

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51980 Eric Batut changed: What|Removed |Added CC||ramana at gcc dot gnu.org,

[Bug target/48941] [arm gcc] NEON: Stack pointer operations performed even tho stack is not accessed at all in function.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48941 Eric Batut changed: What|Removed |Added CC||eric.batut at allegorithmic

[Bug target/51968] gcc trunk (ARM) ICEs in final_scan_insn in final.c:2716, with "could not split insn" error msg

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51968 --- Comment #9 from Eric Batut 2012-01-25 09:43:01 UTC --- (In reply to comment #8) > Fixed. Great, many thanks !

[Bug target/51980] New: ARM - Neon code polluted by useless stores to the stack with vuzpq / vzipq / vtrnq

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51980 Bug #: 51980 Summary: ARM - Neon code polluted by useless stores to the stack with vuzpq / vzipq / vtrnq Classification: Unclassified Product: gcc Version: 4.7.0 Stat

[Bug target/51968] gcc trunk (ARM) ICEs in final_scan_insn in final.c:2716, with "could not split insn" error msg

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51968 --- Comment #6 from Eric Batut 2012-01-24 11:17:33 UTC --- Our Neon codebase (lots of image processing filters) produce correct results with the patch applied to the latest trunk rev.

[Bug target/51968] gcc trunk (ARM) ICEs in final_scan_insn in final.c:2716, with "could not split insn" error msg

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51968 --- Comment #5 from Eric Batut 2012-01-24 11:12:23 UTC --- (In reply to comment #3) > Created attachment 26436 [details] > proposed patch > > I'll run this through a cross-build first, but I expect this will fix it. This patch makes gcc trunk n

[Bug target/51968] gcc trunk (ARM) ICEs in final_scan_insn in final.c:2716, with "could not split insn" error msg

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51968 --- Comment #1 from Eric Batut 2012-01-23 17:36:50 UTC --- Adding Richard Henderson, who committed rev 183051.

[Bug target/51968] New: gcc trunk (ARM) ICEs in final_scan_insn in final.c:2716, with "could not split insn" error msg

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51968 Bug #: 51968 Summary: gcc trunk (ARM) ICEs in final_scan_insn in final.c:2716, with "could not split insn" error msg Classification: Unclassified Product: gcc Version: 4.7.0