[Bug fortran/37850] New: FAIL: gfortran.dg/c_by_val_1.f & gfortran.dg/value_4.f90 execution test

[Bug fortran/37850] New: FAIL: gfortran.dg/c_by_val_1.f & gfortran.dg/value_4.f90 execution test

[mikael dot morin at tele2 dot fr]

I have seen nothing about it on the list yet, so I guess I'm the only one
impacted. 
Can someone confirm ?
I'll investigate and provide more information later. 


FAIL: gfortran.dg/c_by_val_1.f  -O0  execution test
FAIL: gfortran.dg/c_by_val_1.f  -O1  execution test
FAIL: gfortran.dg/c_by_val_1.f  -O2  execution test
FAIL: gfortran.dg/c_by_val_1.f  -O3 -fomit-frame-pointer  execution test
FAIL: gfortran.dg/c_by_val_1.f  -O3 -fomit-frame-pointer -funroll-loops 
execution test
FAIL: gfortran.dg/c_by_val_1.f  -O3 -fomit-frame-pointer -funroll-all-loops
-finline-functions  execution test
FAIL: gfortran.dg/c_by_val_1.f  -O3 -g  execution test
FAIL: gfortran.dg/c_by_val_1.f  -Os  execution test
FAIL: gfortran.dg/value_4.f90  -O0  execution test
FAIL: gfortran.dg/value_4.f90  -O1  execution test
FAIL: gfortran.dg/value_4.f90  -O2  execution test
FAIL: gfortran.dg/value_4.f90  -O3 -fomit-frame-pointer  execution test
FAIL: gfortran.dg/value_4.f90  -O3 -fomit-frame-pointer -funroll-loops 
execution test
FAIL: gfortran.dg/value_4.f90  -O3 -fomit-frame-pointer -funroll-all-loops
-finline-functions  execution test
FAIL: gfortran.dg/value_4.f90  -O3 -g  execution test
FAIL: gfortran.dg/value_4.f90  -Os  execution test


-- 
           Summary: FAIL: gfortran.dg/c_by_val_1.f & gfortran.dg/value_4.f90
                    execution test
           Product: gcc
           Version: 4.4.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: mikael dot morin at tele2 dot fr
  GCC host triplet: x86_64-unknown-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37850

[Bug fortran/37850] FAIL: gfortran.dg/c_by_val_1.f & gfortran.dg/value_4.f90 execution test

[dominiq at lps dot ens dot fr]

------- Comment #1 from dominiq at lps dot ens dot fr  2008-10-16 14:39 -------
> ... so I guess I'm the only one impacted. ...

Which revision? I don't have gfortran regression at r141150 on
i686-apple-darwin9 and r141139 powerpc-apple-darwin9.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37850

[Bug fortran/37850] FAIL: gfortran.dg/c_by_val_1.f & gfortran.dg/value_4.f90 execution test

[tkoenig at gcc dot gnu dot org]

------- Comment #2 from tkoenig at gcc dot gnu dot org  2008-10-16 20:20 -------
I can't reproduce this with today's trunk, rev. 141180

Any more details?


-- 

tkoenig at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tkoenig at gcc dot gnu dot
                   |                            |org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37850

[Bug fortran/37850] FAIL: gfortran.dg/c_by_val_1.f & gfortran.dg/value_4.f90 execution test

[mikael dot morin at tele2 dot fr]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2914 bytes --]



------- Comment #3 from mikael dot morin at tele2 dot fr  2008-10-17 12:39 -------
I'm at r141174. 
But I don't think it is one particular revision. 
I have seen this for a couple of weeks now. 
I thought it would be reverted soon. 
Now, I'm not sure it is a gcc bug. 
I have the feeling that my system is somehow broken, but I can't figure out
where. 

Here are the details:
$ /usr/local/bin/gfortran -v
Utilisation des specs internes.
Target: x86_64-unknown-linux-gnu
Configuré avec: ../src/configure --enable-languages=fortran --disable-multilib
Modèle de thread: posix
gcc version 4.4.0 20081016 (experimental) (GCC) 

$ /usr/local/bin/gcc -O0 -g -c value_4.c
$ /usr/local/bin/gfortran -ff2c -w -O0 -g value_4.o value_4.f90 -o value_4
$ ./value_4 
zsh: segmentation fault  ./value_4

(gdb) bt
#0  __muldc3 (a=8, b=0, c=0, d=1) at ../../../src/libgcc/../gcc/libgcc2.c:1834
#1  0x00007fb8c55fb351 in __muldc3 (a=8, b=0, c=0, d=1)
    at ../../../src/libgcc/../gcc/libgcc2.c:1889
#2  0x00007fb8c55fb351 in __muldc3 (a=8, b=0, c=0, d=1)
    at ../../../src/libgcc/../gcc/libgcc2.c:1889
#3  0x00007fb8c55fb351 in __muldc3 (a=8, b=0, c=0, d=1)
    at ../../../src/libgcc/../gcc/libgcc2.c:1889
#4  0x00007fb8c55fb351 in __muldc3 (a=-1, b=2, c=4, d=0)
    at ../../../src/libgcc/../gcc/libgcc2.c:1889
#5  0x00000000004007f7 in c_to_c__ (retval=0x7fffce012220, c1=0 + 0 * I, 
    c2=0x7fffce012228) at value_4.c:48
#6  0x000000000040092d in value_4 () at value_4.f90:39
#7  0x00000000004009e0 in main (argc=1, argv=0x7fffce012338)
    at ../../../src/libgfortran/fmain.c:21
#8  0x00007fb8c52a6146 in __libc_start_main () from /lib/libc.so.6
#9  0x0000000000400659 in _start ()


this is not fortran-related, reduced-testcase:

#include <complex.h>
int main ()
{
        complex float u = __muldc3 (1, 2, 3, 4); 
        return 0;
}


(gdb) bt
#0  __muldc3 (a=10, b=0, c=0, d=1) at ../../../src/libgcc/../gcc/libgcc2.c:1834
#1  0x0000000000400cc1 in __muldc3 (a=10, b=0, c=0, d=1)
    at ../../../src/libgcc/../gcc/libgcc2.c:1889
#2  0x0000000000400cc1 in __muldc3 (a=10, b=0, c=0, d=1)
    at ../../../src/libgcc/../gcc/libgcc2.c:1889
#3  0x0000000000400cc1 in __muldc3 (a=10, b=0, c=0, d=1)
    at ../../../src/libgcc/../gcc/libgcc2.c:1889
#4  0x0000000000400cc1 in __muldc3 (a=10, b=0, c=0, d=1)
    at ../../../src/libgcc/../gcc/libgcc2.c:1889
#5  0x0000000000400cc1 in __muldc3 (a=10, b=0, c=0, d=1)
    at ../../../src/libgcc/../gcc/libgcc2.c:1889
#6  0x0000000000400cc1 in __muldc3 (a=1, b=2, c=3, d=4)
    at ../../../src/libgcc/../gcc/libgcc2.c:1889
#7  0x00000000004004a1 in main () at value_4_f90.c:4


I looked at the offending line, but seen nothing wrong though I have never 
been playing with C complex. 
In fact the code looks like directly taken from the C99 standard, so I bet it's
correct. 

I will see if I can find a working revision. 


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37850

[Bug fortran/37850] FAIL: gfortran.dg/c_by_val_1.f & gfortran.dg/value_4.f90 execution test

[dominiq at lps dot ens dot fr]

------- Comment #4 from dominiq at lps dot ens dot fr  2008-10-17 12:54 -------
Looks like pr37808, supposed to be fixed at r 14178.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37850

[Bug c/37850] FAIL: gfortran.dg/c_by_val_1.f & gfortran.dg/value_4.f90 execution test

[mikael dot morin at tele2 dot fr]

------- Comment #5 from mikael dot morin at tele2 dot fr  2008-10-17 16:38 -------
I'v just tried r140349 and r141192. 
It's not better.


-- 

mikael dot morin at tele2 dot fr changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|fortran                     |c


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37850

[Bug c/37850] infinite recursive call to __mulsc3 when multiplying not-constant complexs

[mikael dot morin at tele2 dot fr]

------- Comment #6 from mikael dot morin at tele2 dot fr  2008-10-18 12:03 -------
updated testcase :
#include <complex.h>
int main ()
{
        float a = 1.;
        complex float v;
        v = I * 1.;  /* works */
        v = I * a;   /* fails */
        return 0;
}


Two conditions seem necessary for the bug to happen:
 - the testcase is compiled with -O0
 - gcc is configured and bootstrapped with CFLAGS="-O0 -g" (I suspect that -g
is unnecessary, but I don't want to test again)


-- 

mikael dot morin at tele2 dot fr changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|FAIL:                       |infinite recursive call to
                   |gfortran.dg/c_by_val_1.f &  |__mulsc3 when multiplying
                   |gfortran.dg/value_4.f90     |not-constant complexs
                   |execution test              |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37850

[Bug middle-end/37850] infinite recursive call to __mulsc3 when multiplying not-constant complexs

[rguenth at gcc dot gnu dot org]

------- Comment #7 from rguenth at gcc dot gnu dot org  2008-10-18 12:43 -------
This is because the implementation of __muldc3 uses

  return x + I * y;

which if built with -O0 results in a call to __muldc3 ... because this
is what complex lowering at -O0 produces:

<bb 2>:
  D.1235 = COMPLEX_EXPR <x, 0.0>;
  D.1236 = COMPLEX_EXPR <y, 0.0>;
  D.1241 = REALPART_EXPR <D.1236>;
  D.1242 = IMAGPART_EXPR <D.1236>;
  D.1237 = __muldc3 (D.1241, D.1242, 0.0, 1.0e+0);
  D.1243 = REALPART_EXPR <D.1235>;
  D.1244 = IMAGPART_EXPR <D.1235>;
  D.1245 = REALPART_EXPR <D.1237>;
  D.1246 = IMAGPART_EXPR <D.1237>;
  D.1247 = D.1243 + D.1245;
  D.1248 = D.1244 + D.1246;
  D.1238 = COMPLEX_EXPR <D.1247, D.1248>;
  <retval> = D.1238;
  return <retval>;

That said - you shouldn't build libgcc itself without optimization.

Still I see a missed optimization in that we do not fold

COMPLEX_EXPR <x, 0.0> + COMPLEX_EXPR <y, 0.0> * __complex__ (0.0, 1.0e+0);

I thought I added this capability.  And I did:

          /* Fold z * +-I to __complex__ (-+__imag z, +-__real z).
             This is not the same for NaNs or if signed zeros are
             involved.  */
          if (!HONOR_NANS (TYPE_MODE (TREE_TYPE (arg0)))
              && !HONOR_SIGNED_ZEROS (TYPE_MODE (TREE_TYPE (arg0)))
              && COMPLEX_FLOAT_TYPE_P (TREE_TYPE (arg0))
              && TREE_CODE (arg1) == COMPLEX_CST
              && real_zerop (TREE_REALPART (arg1)))

The question is whether the standard requires actual complex multiplication
carried out for y * I, as it seems to allow an imaginary type used for I
as well.

A probably better writing of the return statement is

  CTYPE res;
  __real res = x;
  __imag res = y;
  return res;

which should be valid, as the NaN cases are checked earlier.

Joseph?


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jsm28 at gcc dot gnu dot org
           Severity|normal                      |enhancement
             Status|UNCONFIRMED                 |NEW
          Component|c                           |middle-end
     Ever Confirmed|0                           |1
           Keywords|                            |build, missed-optimization
   Last reconfirmed|0000-00-00 00:00:00         |2008-10-18 12:43:35
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37850

[Bug middle-end/37850] infinite recursive call to __mulsc3 when multiplying not-constant complexs

[joseph at codesourcery dot com]

------- Comment #8 from joseph at codesourcery dot com  2008-10-18 18:06 -------
Subject: Re:  infinite recursive call to __mulsc3 when
 multiplying not-constant complexs

On Sat, 18 Oct 2008, rguenth at gcc dot gnu dot org wrote:

> The question is whether the standard requires actual complex multiplication
> carried out for y * I, as it seems to allow an imaginary type used for I
> as well.
> 
> A probably better writing of the return statement is
> 
>   CTYPE res;
>   __real res = x;
>   __imag res = y;
>   return res;
> 
> which should be valid, as the NaN cases are checked earlier.

The above is indeed a better representation of the return statement to 
avoid problems with NaNs, infinities and negative zero.

GCC does not implement imaginary types.  Nor do other compilers; no-one on 
the Power ABI working group had a Power architecture compiler supporting 
_Imaginary so we didn't include _Imaginary in the ABI draft (it has ABI 
implications for how you pass and return _Imaginary values, and the answer 
is not generally an obvious "like real values" given that float _Imaginary 
is not promoted to double _Imaginary when passed to variadic functions, so 
you have to deal with the case of float _Imaginary in variable arguments 
when doesn't arise for float).

Given that imaginary types are not used, multiplication by I is 
multiplication by (0.0 + 1.0i).  However, multiplying real y by (0.0 + 
1.0i) is not multiplying (y + 0.0i) by (0.0 + 1.0i); this is bug 24581.  
GCC does not implement the standard requirement that the operands of mixed 
real/complex arithmetic have a common real type found but without 
converting real operands to complex types (so float + double _Complex has 
the float argument converted to double not _Complex double, double + float 
_Complex has the float _Complex argument converted to double _Complex 
without changing the double argument).  The spurious conversions to 
complex types give additional opportunities for problems with NaNs, 
infinities and negative zero to arise.

That standard requirement should be reasonably straightforward to 
implement in the front end for all cases except division of a real value 
by a complex one.  Annex G doesn't suggest any particular requirements for 
real/complex division that would go wrong if the real number is converted 
to complex in that case so it may be appropriate to keep doing so in the 
front end.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37850

[Bug middle-end/37850] infinite recursive call to __mulsc3 when multiplying not-constant complexs

[froydnj at gcc dot gnu dot org]

------- Comment #9 from froydnj at gcc dot gnu dot org  2009-03-10 15:43 -------
Subject: Bug 37850

Author: froydnj
Date: Tue Mar 10 15:42:51 2009
New Revision: 144751

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144751
Log:
        PR middle-end/37850
        * libgcc2.c (__mulMODE3): Use explicit assignments to form the
        result.
        (__divMODE3): Likewise.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/libgcc2.c


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37850

[Bug middle-end/37850] infinite recursive call to __mulsc3 when multiplying not-constant complexs

[froydnj at gcc dot gnu dot org]

------- Comment #10 from froydnj at gcc dot gnu dot org  2009-03-10 15:49 -------
Fixed on trunk.


-- 

froydnj at gcc dot gnu dot org changed:

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


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37850

[Bug middle-end/37850] infinite recursive call to __mulsc3 when multiplying not-constant complexs

[hjl dot tools at gmail dot com]

-- 

hjl dot tools at gmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |4.4.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37850

[Bug middle-end/37850] infinite recursive call to __mulsc3 when multiplying not-constant complexs

[danglin at gcc dot gnu dot org]

------- Comment #11 from danglin at gcc dot gnu dot org  2009-09-18 14:34 -------
Subject: Bug 37850

Author: danglin
Date: Fri Sep 18 14:34:31 2009
New Revision: 151846

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=151846
Log:
        PR middle-end/41009
        Backport from mainline
        2009-03-10  Richard Guenther  <rguenther@suse.de>
        Nathan Froyd  <froydnj@codesourcery.com>

        PR middle-end/37850
        * libgcc2.c (__mulMODE3): Use explicit assignments to form the result.
        (__divMODE3): Likewise.


Modified:
    branches/gcc-4_3-branch/gcc/ChangeLog
    branches/gcc-4_3-branch/gcc/libgcc2.c


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37850