[Bug c/65077] New: memcpy generates incorrect code with floating point numbers and -O1

[Bug c/65077] New: memcpy generates incorrect code with floating point numbers and -O1

[anders.blomdell at control dot lth.se]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65077

            Bug ID: 65077
           Summary: memcpy generates incorrect code with floating point
                    numbers and -O1
           Product: gcc
           Version: 4.9.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: anders.blomdell at control dot lth.se

Created attachment 34774
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34774&action=edit
Program that triggers bug

The attached code (heavily downsized), generates incorrect code with -O1 and if
compiled with -fPIC or -fpic it generates incorrect code for most optimizations
(-O1, -O2, -O3, -Os, -Ofast).

Here is the command line and output.

> gcc -v -save-temps -o bug bug.c -fno-strict-aliasing -fwrapv -fno-aggressive-loop-optimizations  -O1 -Wall -Werror

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.9.2/lto-wrapper
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla
--enable-bootstrap --enable-shared --enable-threads=posix
--enable-checking=release --enable-multilib --with-system-zlib
--enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object
--enable-linker-build-id --with-linker-hash-style=gnu
--enable-languages=c,c++,objc,obj-c++,fortran,ada,go,lto --enable-plugin
--enable-initfini-array --disable-libgcj
--with-isl=/builddir/build/BUILD/gcc-4.9.2-20141101/obj-x86_64-redhat-linux/isl-install
--with-cloog=/builddir/build/BUILD/gcc-4.9.2-20141101/obj-x86_64-redhat-linux/cloog-install
--enable-gnu-indirect-function --with-tune=generic --with-arch_32=i686
--build=x86_64-redhat-linux
Thread model: posix
gcc version 4.9.2 20141101 (Red Hat 4.9.2-1) (GCC) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-o' 'bug' '-fno-strict-aliasing'
'-fwrapv' '-fno-aggressive-loop-optimizations' '-O1' '-Wall' '-Werror'
'-mtune=generic' '-march=x86-64'
 /usr/libexec/gcc/x86_64-redhat-linux/4.9.2/cc1 -E -quiet -v bug.c
-mtune=generic -march=x86-64 -Wall -Werror -fno-strict-aliasing -fwrapv
-fno-aggressive-loop-optimizations -O1 -fpch-preprocess -o bug.i
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-redhat-linux/4.9.2/include-fixed"
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-redhat-linux/4.9.2/../../../../x86_64-redhat-linux/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc/x86_64-redhat-linux/4.9.2/include
 /usr/local/include
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-o' 'bug' '-fno-strict-aliasing'
'-fwrapv' '-fno-aggressive-loop-optimizations' '-O1' '-Wall' '-Werror'
'-mtune=generic' '-march=x86-64'
 /usr/libexec/gcc/x86_64-redhat-linux/4.9.2/cc1 -fpreprocessed bug.i -quiet
-dumpbase bug.c -mtune=generic -march=x86-64 -auxbase bug -O1 -Wall -Werror
-version -fno-strict-aliasing -fwrapv -fno-aggressive-loop-optimizations -o
bug.s
GNU C (GCC) version 4.9.2 20141101 (Red Hat 4.9.2-1) (x86_64-redhat-linux)
    compiled by GNU C version 4.9.2 20141101 (Red Hat 4.9.2-1), GMP version
6.0.0, MPFR version 3.1.2, MPC version 1.0.2
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C (GCC) version 4.9.2 20141101 (Red Hat 4.9.2-1) (x86_64-redhat-linux)
    compiled by GNU C version 4.9.2 20141101 (Red Hat 4.9.2-1), GMP version
6.0.0, MPFR version 3.1.2, MPC version 1.0.2
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 03cfec3867418ce243292e9ba51d447c
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-o' 'bug' '-fno-strict-aliasing'
'-fwrapv' '-fno-aggressive-loop-optimizations' '-O1' '-Wall' '-Werror'
'-mtune=generic' '-march=x86-64'
 as -v --64 -o bug.o bug.s
GNU assembler version 2.24 (x86_64-redhat-linux) using BFD version version 2.24
COMPILER_PATH=/usr/libexec/gcc/x86_64-redhat-linux/4.9.2/:/usr/libexec/gcc/x86_64-redhat-linux/4.9.2/:/usr/libexec/gcc/x86_64-redhat-linux/:/usr/lib/gcc/x86_64-redhat-linux/4.9.2/:/usr/lib/gcc/x86_64-redhat-linux/
LIBRARY_PATH=/usr/lib/gcc/x86_64-redhat-linux/4.9.2/:/usr/lib/gcc/x86_64-redhat-linux/4.9.2/../../../../lib64/:/lib/../lib64/:/usr/lib/../lib64/:/usr/lib/gcc/x86_64-redhat-linux/4.9.2/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-o' 'bug' '-fno-strict-aliasing'
'-fwrapv' '-fno-aggressive-loop-optimizations' '-O1' '-Wall' '-Werror'
'-mtune=generic' '-march=x86-64'
 /usr/libexec/gcc/x86_64-redhat-linux/4.9.2/collect2 -plugin
/usr/libexec/gcc/x86_64-redhat-linux/4.9.2/liblto_plugin.so
-plugin-opt=/usr/libexec/gcc/x86_64-redhat-linux/4.9.2/lto-wrapper
-plugin-opt=-fresolution=bug.res -plugin-opt=-pass-through=-lgcc
-plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lc
-plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s --build-id
--no-add-needed --eh-frame-hdr --hash-style=gnu -m elf_x86_64 -dynamic-linker
/lib64/ld-linux-x86-64.so.2 -o bug
/usr/lib/gcc/x86_64-redhat-linux/4.9.2/../../../../lib64/crt1.o
/usr/lib/gcc/x86_64-redhat-linux/4.9.2/../../../../lib64/crti.o
/usr/lib/gcc/x86_64-redhat-linux/4.9.2/crtbegin.o
-L/usr/lib/gcc/x86_64-redhat-linux/4.9.2
-L/usr/lib/gcc/x86_64-redhat-linux/4.9.2/../../../../lib64 -L/lib/../lib64
-L/usr/lib/../lib64 -L/usr/lib/gcc/x86_64-redhat-linux/4.9.2/../../.. bug.o
-lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s
--no-as-needed /usr/lib/gcc/x86_64-redhat-linux/4.9.2/crtend.o
/usr/lib/gcc/x86_64-redhat-linux/4.9.2/../../../../lib64/crtn.o

[Bug c/65077] memcpy generates incorrect code with floating point numbers and -O1

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65077

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |INVALID

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
You are writing beyond P in

      (s)->u.f1 = p;

the testcase works with -m32 (where S is of the same size as P).

[Bug c/65077] memcpy generates incorrect code with floating point numbers and -O1

[anders.blomdell at control dot lth.se]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65077

--- Comment #2 from anders.blomdell at control dot lth.se ---
Created attachment 34777
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34777&action=edit
preprocessed program

[Bug c/65077] memcpy generates incorrect code with floating point numbers and -O1

[anders.blomdell at control dot lth.se]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65077

--- Comment #3 from anders.blomdell at control dot lth.se ---
Created attachment 34778
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34778&action=edit
Shell-script for testing flag variations

[Bug c/65077] memcpy generates incorrect code with floating point numbers and -O1

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65077

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
   Last reconfirmed|                            |2015-02-16
                 CC|                            |rguenth at gcc dot gnu.org
         Resolution|INVALID                     |---
     Ever confirmed|0                           |1

--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
Ah, the issue is actually that we simply disregard passing pointers through
floating point values in points-to analysis:

          if (FLOAT_TYPE_P (TREE_TYPE (lhsop)))
            /* If the operation produces a floating point result then
               assume the value is not produced to transfer a pointer.  */
            ;

which results in

  # PT =
  s_13 = MEM[(char * {ref-all})&intSptr];

and DSE removing the store to

  # .MEM_15 = VDEF <.MEM_11>
  s_13->u.f1 = p_6;

we have similar handling for

          else if (truth_value_p (code))
            /* Truth value results are not pointer (parts).  Or at least
               very very unreasonable obfuscation of a part.  */
            ;

so if you insist on writing rediculous testcases...

[Bug c/65077] memcpy generates incorrect code with floating point numbers and -O1

[anders.blomdell at control dot lth.se]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65077

--- Comment #5 from anders.blomdell at control dot lth.se ---
No, but my users insists on using Matlab/Simulink, and the testcase is a
heavily downsized version of what is done in their S-functions.

[Bug c/65077] memcpy generates incorrect code with floating point numbers and -O1

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65077

--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to anders.blomdell from comment #5)
> No, but my users insists on using Matlab/Simulink, and the testcase is a
> heavily downsized version of what is done in their S-functions.

I mean - seriously storing a pointer as FP values of the upper/lower word
of the pointer?  So I suppose this is what Matlab/Simulink generate internally
and what gets compiled - thus this is machine generated?

A workaround is to use -fno-tree-pta btw (for 64bit pointers the out-of-bound
write still occurs, but that may be due to your simplification?).

[Bug tree-optimization/65077] [4.9/5 Regression] memcpy generates incorrect code with floating point numbers and -O1

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65077

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |wrong-code
             Status|REOPENED                    |ASSIGNED
          Component|c                           |tree-optimization
      Known to work|                            |4.8.2
   Target Milestone|---                         |4.9.3
            Summary|memcpy generates incorrect  |[4.9/5 Regression] memcpy
                   |code with floating point    |generates incorrect code
                   |numbers and -O1             |with floating point numbers
                   |                            |and -O1

--- Comment #7 from Richard Biener <rguenth at gcc dot gnu.org> ---
The

          if (FLOAT_TYPE_P (TREE_TYPE (lhsop)))
            /* If the operation produces a floating point result then
               assume the value is not produced to transfer a pointer.  */
            ;

case is new in 4.9 (4.8 didn't have it - doing this improves points-to
results for scientific benchmarks which have both pointers and FP values
in aggregates).  Changed by r197158:

2013-03-27  Richard Biener  <rguenther@suse.de>

       PR tree-optimization/37021
       * tree-vect-data-refs.c (vect_check_strided_load): Allow
       REALPART/IMAGPART_EXPRs around the supported refs.
       * tree-ssa-structalias.c (find_func_aliases): Assume that
       floating-point values are not used to transfer pointers.

[Bug tree-optimization/65077] [4.9/5 Regression] memcpy generates incorrect code with floating point numbers and -O1

[anders.blomdell at control dot lth.se]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65077

--- Comment #8 from anders.blomdell at control dot lth.se ---
(In reply to Richard Biener from comment #6)
> (In reply to anders.blomdell from comment #5)
> > No, but my users insists on using Matlab/Simulink, and the testcase is a
> > heavily downsized version of what is done in their S-functions.
> 
> I mean - seriously storing a pointer as FP values of the upper/lower word
> of the pointer?  So I suppose this is what Matlab/Simulink generate
> internally
> and what gets compiled - thus this is machine generated?
Nope, part of C-code that users should include in their S-functions.
Code used to work with gcc-4.8.3. This will become a major problem :-(

> 
> A workaround is to use -fno-tree-pta btw (for 64bit pointers the out-of-bound
> write still occurs, but that may be due to your simplification?).
The out of bound write is because I'm a klutz, the bug occurs with this as well

S theS;

double *getP(void *p) {
  union u {
    void *p;
    int i[2];
  } u;
  u.p = &theS;
  P[0] = u.i[0];
  P[1] = u.i[1];
  return P;
}

[Bug tree-optimization/65077] [4.9/5 Regression] memcpy generates incorrect code with floating point numbers and -O1

[anders.blomdell at control dot lth.se]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65077

--- Comment #9 from anders.blomdell at control dot lth.se ---
(In reply to Richard Biener from comment #7)
>        * tree-ssa-structalias.c (find_func_aliases): Assume that
>        floating-point values are not used to transfer pointers.

Assume nothing (except the worst) when dealing with MathWorks code :-(

[Bug tree-optimization/65077] [4.9/5 Regression] memcpy generates incorrect code with floating point numbers and -O1

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65077

--- Comment #10 from Richard Biener <rguenth at gcc dot gnu.org> ---
Created attachment 34781
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34781&action=edit
untested patch

Patch which fixes the testcase and doesn't regress the vectorization testcase
from PR37021.

[Bug tree-optimization/65077] [4.9/5 Regression] memcpy generates incorrect code with floating point numbers and -O1

[anders.blomdell at control dot lth.se]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65077

--- Comment #11 from anders.blomdell at control dot lth.se ---
(In reply to Richard Biener from comment #10)
> Created attachment 34781 [details]
> untested patch
Apllied patch to Fedora SRPM, rebuilt, installed, rerun my testcase:

Works! :-)

> Patch which fixes the testcase and doesn't regress the vectorization
> testcase from PR37021.

Thanks, you are one order of magnitude faster at fixing bugs than my computer
is at compiling them, and at least two orders of magnitude faster than I'm at
isolating bugs. Kudos!

[Bug tree-optimization/65077] [4.9/5 Regression] memcpy generates incorrect code with floating point numbers and -O1

[anders.blomdell at control dot lth.se]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65077

anders.blomdell at control dot lth.se changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #34774|0                           |1
        is obsolete|                            |

--- Comment #12 from anders.blomdell at control dot lth.se ---
Created attachment 34784
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34784&action=edit
Somewhat better testcase (less type-cheating)

[Bug tree-optimization/65077] [4.9 Regression] memcpy generates incorrect code with floating point numbers and -O1

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65077

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to work|                            |5.0
            Summary|[4.9/5 Regression] memcpy   |[4.9 Regression] memcpy
                   |generates incorrect code    |generates incorrect code
                   |with floating point numbers |with floating point numbers
                   |and -O1                     |and -O1
      Known to fail|                            |4.9.2

--- Comment #13 from Richard Biener <rguenth at gcc dot gnu.org> ---
Fixed on trunk sofar.

[Bug tree-optimization/65077] [4.9 Regression] memcpy generates incorrect code with floating point numbers and -O1

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65077

--- Comment #14 from Richard Biener <rguenth at gcc dot gnu.org> ---
Author: rguenth
Date: Mon Feb 16 18:15:19 2015
New Revision: 220741

URL: https://gcc.gnu.org/viewcvs?rev=220741&root=gcc&view=rev
Log:
2015-02-16  Richard Biener  <rguenther@suse.de>

    PR tree-optimization/65077
    * tree-ssa-structalias.c (get_constraint_for_1): Handle
    IMAGPART_EXPR, REALPART_EXPR and BIT_FIELD_REF.
    (find_func_aliases): Allow float values to carry pointers again.

    * gcc.dg/torture/pr65077.c: New testcase.

Added:
    trunk/gcc/testsuite/gcc.dg/torture/pr65077.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/tree-ssa-structalias.c

[Bug tree-optimization/65077] [4.9 Regression] memcpy generates incorrect code with floating point numbers and -O1

[anders.blomdell at control dot lth.se]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65077

--- Comment #15 from anders.blomdell at control dot lth.se ---
(In reply to Richard Biener from comment #4)
> we have similar handling for
> 
>           else if (truth_value_p (code))
>             /* Truth value results are not pointer (parts).  Or at least
>                very very unreasonable obfuscation of a part.  */
>             ;

Isn't this unreachable due to 

+      case BIT_FIELD_REF:

in the patch? Or would it be hit if somebody tries to encode pointers with a
packed bitfield struct/union?

No, I won't write a ridiculous testcase to check :-)

Again, great thanks.

[Bug tree-optimization/65077] [4.9 Regression] memcpy generates incorrect code with floating point numbers and -O1

[rguenther at suse dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65077

--- Comment #16 from rguenther at suse dot de <rguenther at suse dot de> ---
On Mon, 16 Feb 2015, anders.blomdell at control dot lth.se wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65077
> 
> --- Comment #15 from anders.blomdell at control dot lth.se ---
> (In reply to Richard Biener from comment #4)
> > we have similar handling for
> > 
> >           else if (truth_value_p (code))
> >             /* Truth value results are not pointer (parts).  Or at least
> >                very very unreasonable obfuscation of a part.  */
> >             ;
> 
> Isn't this unreachable due to 
> 
> +      case BIT_FIELD_REF:
> 
> in the patch? Or would it be hit if somebody tries to encode pointers with a
> packed bitfield struct/union?

No, truth_value_p is computations such as x = (a == b) or x = (a && b)

> No, I won't write a ridiculous testcase to check :-)
> 
> Again, great thanks.

[Bug tree-optimization/65077] [4.9 Regression] memcpy generates incorrect code with floating point numbers and -O1

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65077

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |agriff at tin dot it

--- Comment #17 from Richard Biener <rguenth at gcc dot gnu.org> ---
*** Bug 66086 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/65077] [4.9 Regression] memcpy generates incorrect code with floating point numbers and -O1

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65077

--- Comment #18 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 4.9.3 has been released.

[Bug tree-optimization/65077] [4.9 Regression] memcpy generates incorrect code with floating point numbers and -O1

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65077

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.9.3                       |4.9.4