[Bug c++/105071] New: Incorrect code with -Os and complex<double>

[Bug c++/105071] New: Incorrect code with -Os and complex<double>

[dlong at cadence dot com]

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

            Bug ID: 105071
           Summary: Incorrect code with -Os and complex<double>
           Product: gcc
           Version: 9.3.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: dlong at cadence dot com
  Target Milestone: ---

Created attachment 52691
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52691&action=edit
.ii file for test case

64-bit Intel, RedHat Enterprise Linux 7.4

$ cat foo.cc
#include <complex>
#include <stdio.h>

using namespace std;

void broken(complex<double> x)
{
  complex<double> x2=x*x;
  complex<double> x3=x2*x;
  complex<double> x4=x3*x;
  complex<double> x5=x4*x;
  complex<double> d=1.0+2.0/x+4.0/x2+8.0/x3+16.0/x4+32.0/x5;
  fprintf(stderr, "%e%+ej\n", real(d), imag(d));
}

int main(int argc, char **argv) {
  broken(complex<double>(1.0, 0.000000e+00));
  return 0;
}
$ g++-9 -Wall -o foo foo.cc && ./foo  # correct
6.300000e+01+0.000000e+00j
$ g++-9 -Wall -O2 -o foo foo.cc && ./foo  # also correct
6.300000e+01+0.000000e+00j
$ g++-9 -Wall -Os -o foo foo.cc && ./foo  # wrong
1.000000e+00+0.000000e+00j

If the +32.0/x5 at the end of the computation of d is
omitted, then -Os also gives the correct result.

$ g++-9 -v
Using built-in specs.
COLLECT_GCC=g++-9
COLLECT_LTO_WRAPPER=/grid/common/pkgsData/gcc-v9.3.0p3/Linux/RHEL7.0-2017-x86_64/libexec/gcc/x86_64-redhat-linux/9.3.0/lto-wrapper
Target: x86_64-redhat-linux
Configured with: /tmp/gcc-v9.3.0p3/gcc.source/configure
--prefix=/grid/common/pkgsData/gcc-v9.3.0p3/Linux/RHEL7.0-2017-x86_64
--with-pkgversion=Cadence --disable-libgcj --enable-threads=posix
--enable-shared --enable-checking=release --with-system-zlib
--enable-__cxa_atexit --disable-libunwind-exceptions
--with-linker-hash-style=gnu --enable-languages=c,c++,fortran --disable-nls
--enable-gnu-unique-object --enable-bootstrap --enable-plugin
--enable-initfini-array --enable-linker-build-id --enable-gnu-indirect-function
--enable-install-libiberty
--with-ld=/grid/common/pkgsData/gcc-v9.3.0p3/Linux/RHEL7.0-2017-x86_64/bin/ld
--with-as=/grid/common/pkgsData/gcc-v9.3.0p3/Linux/RHEL7.0-2017-x86_64/bin/as
--build=x86_64-redhat-linux --host=x86_64-redhat-linux --with-tune=generic
--enable-multiarch
Thread model: posix
gcc version 9.3.0 (Cadence)

[Bug middle-end/105071] [9 Regression] Incorrect code with -Os and complex<double>

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |9.5
      Known to work|                            |10.1.0, 8.1.0, 8.5.0
           Keywords|                            |wrong-code
            Summary|Incorrect code with -Os and |[9 Regression] Incorrect
                   |complex<double>             |code with -Os and
                   |                            |complex<double>
          Component|c++                         |middle-end
      Known to fail|                            |9.1.0, 9.3.0, 9.4.0

[Bug middle-end/105071] [9 Regression] Incorrect code with -Os and complex<double>

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rguenth at gcc dot gnu.org
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2022-03-28

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
Confirmed.

[Bug middle-end/105071] [9 Regression] Incorrect code with -Os and complex<double>

[marxin at gcc dot gnu.org]

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

Martin Liška <marxin at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|needs-bisection             |
                 CC|                            |jamborm at gcc dot gnu.org,
                   |                            |marxin at gcc dot gnu.org

--- Comment #2 from Martin Liška <marxin at gcc dot gnu.org> ---
Fixed on master with r10-3311-gff6686d2e5f797d6, if I add -fno-ipa-sra for the
revision, it's still correct.

[Bug middle-end/105071] [9 Regression] Incorrect code with -Os and complex<double>

[jamborm at gcc dot gnu.org]

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

--- Comment #3 from Martin Jambor <jamborm at gcc dot gnu.org> ---
(In reply to Martin Liška from comment #2)
> Fixed on master with r10-3311-gff6686d2e5f797d6, if I add -fno-ipa-sra for
> the revision, it's still correct.

But it also works if you add -fno-inline ! ;-) 

Anyway, this is a duplicate of PR 97456 which I guess I should have also
backported to GCC 9 but did not.

I'll bootstrap and test the patch on the branch tomorrow.

[Bug middle-end/105071] [9 Regression] Incorrect code with -Os and complex<double>

[jamborm at gcc dot gnu.org]

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

--- Comment #4 from Martin Jambor <jamborm at gcc dot gnu.org> ---
I have asked for permission to backport the fix in 
https://gcc.gnu.org/pipermail/gcc-patches/2022-March/592520.html

[Bug middle-end/105071] [9 Regression] Incorrect code with -Os and complex<double>

[cvs-commit at gcc dot gnu.org]

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

--- Comment #5 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-9 branch has been updated by Martin Jambor
<jamborm@gcc.gnu.org>:

https://gcc.gnu.org/g:1dc4bed43760c4e291e072aa0c8c450f5775e25f

commit r9-10000-g1dc4bed43760c4e291e072aa0c8c450f5775e25f
Author: Martin Jambor <mjambor@suse.cz>
Date:   Wed Mar 30 13:47:24 2022 +0200

    cplxlower: Avoid a transform when looking at a default definition

    In PR 97456, IPA-SRA triggers a bug in tree-complex.c where it
    converts:

     <bb 2>
       a$_M_value_21 = COMPLEX_EXPR <ISRA.18_10(D), ISRA.18_10(D)>;

    (where ISRA.18 is IPA-SRA created PARM_DECL with DECL_IGNORED_P set,
    which is why it only happens with IPA-SRA) into:

      <bb 2>
        a$_M_value_21 = COMPLEX_EXPR <a$_M_value$real_10(D),
a$_M_value$real_10(D)>;

    i.e. it replaces two uses of the parameter default-def with two
    uninitialized default-defs of a new variable - all in hope to produce
    code with better debug info.

    This patch fixes it by avoiding the transform when the SSA_NAME to be
    replaced is a default definition.

    gcc/ChangeLog:

    2020-10-19  Martin Jambor  <mjambor@suse.cz>

            PR tree-optimization/97456
            PR middle-end/105071
            * tree-complex.c (set_component_ssa_name): Do not replace ignored
decl
            default definitions with new component vars.  Reorder if
conditions.

    gcc/testsuite/ChangeLog:

    2020-10-19  Martin Jambor  <mjambor@suse.cz>

            PR tree-optimization/97456
            * gcc.dg/tree-ssa/pr97456.c: New test.

    (cherry picked from commit 619f91eaa8c8a50f1f9d3e7b96ee837037f0e806)

[Bug middle-end/105071] [9 Regression] Incorrect code with -Os and complex<double>

[jamborm at gcc dot gnu.org]

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

Martin Jambor <jamborm at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |DUPLICATE
             Status|NEW                         |RESOLVED

--- Comment #6 from Martin Jambor <jamborm at gcc dot gnu.org> ---
Now fixed also on the gcc-9 branch. Sorry for not doing it earlier but I had
not seen PR 97456 there before.

*** This bug has been marked as a duplicate of bug 97456 ***