Bug 29925 - Wrong code with -ftree-vectorize
Summary: Wrong code with -ftree-vectorize
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: tree-optimization (show other bugs)
Version: 4.1.2
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords: wrong-code
Depends on:
Blocks:
 
Reported: 2006-11-21 12:22 UTC by Jean-Marc Valin
Modified: 2007-07-01 08:35 UTC (History)
3 users (show)

See Also:
Host:
Target: x86_64-*-*
Build:
Known to work: 4.3.0
Known to fail: 4.1.2
Last reconfirmed: 2006-11-21 12:34:43


Attachments
C file that reproduces the problem (264 bytes, text/x-csrc)
2006-11-21 12:23 UTC, Jean-Marc Valin
Details
Wrong assembly generated (907 bytes, application/octet-stream)
2006-11-21 12:30 UTC, Jean-Marc Valin
Details
Correct (non-vectorized) code (704 bytes, application/octet-stream)
2006-11-21 12:32 UTC, Jean-Marc Valin
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jean-Marc Valin 2006-11-21 12:22:14 UTC
I just hit what seems to be a wrong code generation bug in gcc. The bug happens only when compiling the attached file with:
gcc -g -O1 -ffast-math -ftree-vectorize gcc_bug.c -o gcc_bug

Removing any one of -O1 -ffast-math -ftree-vectorize makes the problem go away. When I run the complete code (which is in the Speex codec BTW), not only do I get the wrong result, but there is a "read past array" that happens. With the reduced example, only the read error is visible and valgrind reports:

==9508== Invalid read of size 8
==9508==    at 0x4004E3: interp_pitch (gcc_bug.c:17)
==9508==    by 0x4005D2: main (gcc_bug.c:29)
==9508==  Address 0x4D64224 is 500 bytes inside a block of size 504 alloc'd
==9508==    at 0x4A1FB37: calloc (vg_replace_malloc.c:279)
==9508==    by 0x4005A8: main (gcc_bug.c:25)

This is on an Ubuntu 64-bit Edgy machine with gcc -v:

Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu --enable-libstdcxx-debug --enable-mpfr --enable-checking=release x86_64-linux-gnu
Thread model: posix
gcc version 4.1.2 20060928 (prerelease) (Ubuntu 4.1.1-13ubuntu5)
Comment 1 Jean-Marc Valin 2006-11-21 12:23:45 UTC
Created attachment 12658 [details]
C file that reproduces the problem

Compile with:
gcc -g -O1 -ffast-math -ftree-vectorize gcc_bug.c -o gcc_bug
to reproduce the problem and run under valgrind.
Comment 2 Jean-Marc Valin 2006-11-21 12:30:43 UTC
Created attachment 12659 [details]
Wrong assembly generated

This is the result of:
gcc -O1 -ffast-math -ftree-vectorize -S gcc_bug.c
which generates wrong code.
Comment 3 Jean-Marc Valin 2006-11-21 12:32:17 UTC
Created attachment 12660 [details]
Correct (non-vectorized) code

This is the code generated with:
gcc -O1 -ffast-math -S gcc_bug.c
and works correctly.
Comment 4 Richard Biener 2006-11-21 12:34:43 UTC
Confirmed.
Comment 5 Jean-Marc Valin 2006-11-21 14:29:31 UTC
Some additional info. valgrind reports that the read includes 4 bytes (out of 8) outside of the array, but in fact given the inputs, it shouldn't even read that close to the array bound in the first place. So the address computation is completely wrong. Also, strange is that simply replacing maxj by its value (3) in:
tmp += exc[i-pitch+k+maxj-6];
makes the problem disappear.
Comment 6 Ira Rosen 2006-12-14 12:41:59 UTC
I couldn't reproduce the problem on x86. I ran it with valgrind --leak-check=yes, is it correct?

Ira
Comment 7 Jean-Marc Valin 2006-12-14 13:28:20 UTC
Could be x86-64 only, I don't know. I don't have a plain x86 with gcc 4.1 to test on.
Comment 8 Jean-Marc Valin 2006-12-30 06:42:37 UTC
Shouldn't the priority of this bug be increased considering that it produces wrong code on valid input and the affected package (Speex) is included in most Linux distributions (fortunately most of these don't enable -ftree-vectorize by default I think)?
Comment 9 patchapp@dberlin.org 2007-03-05 08:01:29 UTC
Subject: Bug number PR tree-optimization/29925

A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-03/msg00254.html
Comment 10 irar 2007-03-11 13:47:50 UTC
Subject: Bug 29925

Author: irar
Date: Sun Mar 11 13:47:40 2007
New Revision: 122819

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122819
Log:
	PR tree-optimization/29925
	* tree-data-ref.c (analyze_offset): Add a return value (bool) to
	indicate success/failure of the analysis. Add negation to subtrahend
	in case of subtraction. Fail if both operands contain constants.
	(create_data_ref): Fail if analyze_offset fails.


Added:
    branches/gcc-4_2-branch/gcc/testsuite/gcc.dg/vect/fast-math-vect-pr29925.c
Modified:
    branches/gcc-4_2-branch/gcc/ChangeLog
    branches/gcc-4_2-branch/gcc/testsuite/ChangeLog
    branches/gcc-4_2-branch/gcc/tree-data-ref.c

Comment 11 irar 2007-03-12 06:56:54 UTC
Subject: Bug 29925

Author: irar
Date: Mon Mar 12 06:56:41 2007
New Revision: 122833

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122833
Log:
	PR tree-optimization/29925
	* tree-data-ref.c (analyze_offset): Add a return value (bool) to
	indicate success/failure of the analysis. Add negation to subtrahend
	in case of subtraction. Fail if both operands contain constants.
	(create_data_ref): Fail if analyze_offset fails.


Added:
    branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/vect/fast-math-vect-pr29925.c
Modified:
    branches/gcc-4_1-branch/gcc/ChangeLog
    branches/gcc-4_1-branch/gcc/testsuite/ChangeLog
    branches/gcc-4_1-branch/gcc/tree-data-ref.c

Comment 12 dorit 2007-07-01 08:35:03 UTC
A fix was committed, looks like the patch can be closed.