[Bug fortran/60191] New: test case gfortran.dg/dynamic_dispatch_1/3.f03 fail on ARMv7

[Bug fortran/60191] New: test case gfortran.dg/dynamic_dispatch_1/3.f03 fail on ARMv7

[bernd.edlinger at hotmail dot de]

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

            Bug ID: 60191
           Summary: test case gfortran.dg/dynamic_dispatch_1/3.f03 fail on
                    ARMv7
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: bernd.edlinger at hotmail dot de

This test case fails only with -O0, that's interesting.

gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/home/ed/gnu/arm-linux-gnueabihf/libexec/gcc/armv7l-unknown-linux-gnueabihf/4.9.0/lto-wrapper
Target: armv7l-unknown-linux-gnueabihf
Configured with: ../gcc-4.9-20140209/configure
--prefix=/home/ed/gnu/arm-linux-gnueabihf
--enable-languages=c,c++,objc,obj-c++,fortran,ada,go --with-arch=armv7-a
--with-tune=cortex-a9 --with-fpu=vfpv3-d16 --with-float=hard
Thread model: posix
gcc version 4.9.0 20140209 (experimental) (GCC)

Debuging the first test case shows this:
The following function gets called:

(gdb) disass make_real
Dump of assembler code for function __m_MOD_make_real:
   0x000086d8 <+0>:    push    {r11}        ; (str r11, [sp, #-4]!)
   0x000086dc <+4>:    add    r11, sp, #0
   0x000086e0 <+8>:    sub    sp, sp, #20
   0x000086e4 <+12>:    str    r0, [r11, #-16]
   0x000086e8 <+16>:    ldr    r3, [r11, #-16]
   0x000086ec <+20>:    ldr    r3, [r3]
   0x000086f0 <+24>:    ldr    r3, [r3]
   0x000086f4 <+28>:    vmov    s15, r3
   0x000086f8 <+32>:    vcvt.f32.s32    s15, s15
   0x000086fc <+36>:    vstr    s15, [r11, #-8]
   0x00008700 <+40>:    ldr    r3, [r11, #-8]
   0x00008704 <+44>:    vmov    s15, r3
   0x00008708 <+48>:    vmov.f32    s0, s15
   0x0000870c <+52>:    sub    sp, r11, #0
   0x00008710 <+56>:    pop    {r11}        ; (ldr r11, [sp], #4)
   0x00008714 <+60>:    bx    lr

the result is returned in register s0 (42.0)
but the caller expects it in register r0.

   0x00008754 <+0>:    push    {r11, lr}
   0x00008758 <+4>:    add    r11, sp, #4
   0x0000875c <+8>:    sub    sp, sp, #8
   0x00008760 <+12>:    movw    r3, #35292    ; 0x89dc
   0x00008764 <+16>:    movt    r3, #0
   0x00008768 <+20>:    str    r3, [r11, #-8]
   0x0000876c <+24>:    movw    r3, #3032    ; 0xbd8
   0x00008770 <+28>:    movt    r3, #1
   0x00008774 <+32>:    str    r3, [r11, #-12]
   0x00008778 <+36>:    ldr    r3, [r11, #-8]
   0x0000877c <+40>:    ldr    r3, [r3, #32]
   0x00008780 <+44>:    sub    r2, r11, #12
   0x00008784 <+48>:    mov    r0, r2
   0x00008788 <+52>:    blx    r3
   0x0000878c <+56>:    vmov    s14, r0
=> 0x00008790 <+60>:    vldr    s15, [pc, #400]    ; 0x8928 <MAIN__+468>
   0x00008794 <+64>:    vcmp.f32    s14, s15
   0x00008798 <+68>:    vmrs    APSR_nzcv, fpscr
   0x0000879c <+72>:    beq    0x87a4 <MAIN__+80>
   0x000087a0 <+76>:    bl    0x8428 <_gfortran_abort>

[Bug fortran/60191] test case gfortran.dg/dynamic_dispatch_1/3.f03 fail on ARMv7

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
This sounds like the front-end is not producing the correct function type for
the call.

[Bug fortran/60191] test case gfortran.dg/dynamic_dispatch_1/3.f03 fail on ARMv7

[janus at gcc dot gnu.org]

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

--- Comment #2 from janus at gcc dot gnu.org ---
The function "make_real" is not invoked directly, but through the type-bound
"a%real", which is called three times in the test case. Does the failure occur
already at the first one (i.e. line 67)? Can you give a reduced test case?

The type-bound call is transformed into a procedure-pointer-component call,
i.e. "a._vptr->real (&a)". Do all the proc_ptr_comp_* test cases work on ARMv7?

Does the failure only happen with trunk or also with earlier versions?

[Bug fortran/60191] test case gfortran.dg/dynamic_dispatch_1/3.f03 fail on ARMv7

[bernd.edlinger at hotmail dot de]

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

--- Comment #3 from Bernd Edlinger <bernd.edlinger at hotmail dot de> ---
(In reply to janus from comment #2)
> The function "make_real" is not invoked directly, but through the type-bound
> "a%real", which is called three times in the test case. Does the failure
> occur already at the first one (i.e. line 67)? Can you give a reduced test
> case?

Yes it is in line 67. Maybe I will have
> The type-bound call is transformed into a procedure-pointer-component
> call, i.e. "a._vptr->real (&a)". Do all the proc_ptr_comp_* test cases work
> on ARMv7?

Yes, the test cases that failed with the last snapshot are:

FAIL: gfortran.dg/dynamic_dispatch_1.f03  -O0  execution test
FAIL: gfortran.dg/dynamic_dispatch_3.f03  -O0  execution test
FAIL: gfortran.dg/select_type_4.f90  -O2  execution test
FAIL: gfortran.dg/select_type_4.f90  -O3 -fomit-frame-pointer  execution test
FAIL: gfortran.dg/select_type_4.f90  -O3 -fomit-frame-pointer -funroll-loops 
execution test
FAIL: gfortran.dg/select_type_4.f90  -O3 -fomit-frame-pointer
-funroll-all-loops -finline-functions  execution test
FAIL: gfortran.dg/select_type_4.f90  -O3 -g  execution test
FAIL: gfortran.dg/stat_1.f90  -O0  execution test
FAIL: gfortran.dg/stat_1.f90  -O1  execution test
FAIL: gfortran.dg/stat_1.f90  -O2  execution test
FAIL: gfortran.dg/stat_1.f90  -O3 -fomit-frame-pointer  execution test
FAIL: gfortran.dg/stat_1.f90  -O3 -fomit-frame-pointer -funroll-loops 
execution test
FAIL: gfortran.dg/stat_1.f90  -O3 -fomit-frame-pointer -funroll-all-loops
-finline-functions  execution test
FAIL: gfortran.dg/stat_1.f90  -O3 -g  execution test
FAIL: gfortran.dg/stat_1.f90  -Os  execution test
FAIL: gfortran.dg/stat_2.f90  -O0  execution test
FAIL: gfortran.dg/stat_2.f90  -O1  execution test
FAIL: gfortran.dg/stat_2.f90  -O2  execution test
FAIL: gfortran.dg/stat_2.f90  -O3 -fomit-frame-pointer  execution test
FAIL: gfortran.dg/stat_2.f90  -O3 -fomit-frame-pointer -funroll-loops 
execution test
FAIL: gfortran.dg/stat_2.f90  -O3 -fomit-frame-pointer -funroll-all-loops
-finline-functions  execution test
FAIL: gfortran.dg/stat_2.f90  -O3 -g  execution test
FAIL: gfortran.dg/stat_2.f90  -Os  execution test
FAIL: gfortran.dg/vect/pr32380.f  -O   scan-tree-dump-times vect "vectorized 6
loops" 1

Maybe I will have some time to look at the other test cases next week.

> Does the failure only happen with trunk or also with earlier
> versions?

I did only try the trunk,
I'd expect the build-configuration (using hard float)
to influence the ABI.
This will likely not happen on a ARMv5, without FPU registers.

[Bug fortran/60191] test case gfortran.dg/dynamic_dispatch_1/3.f03 fail on ARMv7

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres <dominiq at lps dot ens.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING
   Last reconfirmed|                            |2014-02-16
     Ever confirmed|0                           |1

--- Comment #4 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
(In reply to Bernd from comment #3)
IIRC the tests gfortran.dg/stat_(1|2).f90 fail if the user's uid or gid are
different from those of the directory in which the tests are run (see pr42900).
If for some reason you cannot run the tests with user's IDs matching those of
the working directory, these tests will always fail.

For the other failures, are they regressions or is it the first time they are
tested on armv7l-unknown-linux-gnueabihf?

[Bug fortran/60191] test case gfortran.dg/dynamic_dispatch_1/3.f03 fail on ARMv7

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |NEW

--- Comment #5 from janus at gcc dot gnu.org ---
(In reply to Bernd Edlinger from comment #3)
> > The function "make_real" is not invoked directly, but through the type-bound
> > "a%real", which is called three times in the test case. Does the failure
> > occur already at the first one (i.e. line 67)? Can you give a reduced test
> > case?
> 
> Yes it is in line 67.

Ok, then I guess the following reduction should be enough to trigger the bug?


module m

  type :: t1
    integer :: i = 42
  contains
    procedure, pass :: real => make_real
  end type

contains

  real function make_real (arg)
    class(t1), intent(in) :: arg
    make_real = real (arg%i)
  end function make_real

end module m

  use m
  class(t1), pointer :: a
  type(t1), target :: b
  a => b
  if (a%real() .ne. real (42)) call abort
end


Additionally you could try if calling 'make_real' directly (without the
type-binding) works, i.e. replace the last line by:

  if (make_real(a) .ne. real (42)) call abort


> > The type-bound call is transformed into a procedure-pointer-component
> > call, i.e. "a._vptr->real (&a)". Do all the proc_ptr_comp_* test cases work
> > on ARMv7?
> 
> Yes, the test cases that failed with the last snapshot are:
> 
> FAIL: gfortran.dg/dynamic_dispatch_1.f03  -O0  execution test
> FAIL: gfortran.dg/dynamic_dispatch_3.f03  -O0  execution test
> FAIL: gfortran.dg/select_type_4.f90  -O2  execution test

This one might possibly be related. It also involves polymorphism (but no
type-bound procedures).

[Bug fortran/60191] test case gfortran.dg/dynamic_dispatch_1/3.f03 fail on ARMv7

[bernd.edlinger at hotmail dot de]

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

--- Comment #6 from Bernd Edlinger <bernd.edlinger at hotmail dot de> ---
(In reply to Dominique d'Humieres from comment #4)
> (In reply to Bernd from comment #3)
> IIRC the tests gfortran.dg/stat_(1|2).f90 fail if the user's uid or gid are
> different from those of the directory in which the tests are run (see
> pr42900). If for some reason you cannot run the tests with user's IDs
> matching those of the working directory, these tests will always fail.
> 

Ok, thanks. That would explain this one:

My target does not have a hard disk, so I mounted everything
with nfs and the user/group gets squashed by the server.
I log in with root at the target, but everything on the nfs share
is owned by nobody, nogroup I think. But I can fix that somehow.

> For the other failures, are they regressions or is it the first time they
> are tested on armv7l-unknown-linux-gnueabihf?

Given how hard it was to boot strap everything on that target,
(I started in december!), I don't think anybody did that before.
The target itself was built from scratch with cross-compilers.

[Bug fortran/60191] test case gfortran.dg/dynamic_dispatch_1/3.f03 fail on ARMv7

[bernd.edlinger at hotmail dot de]

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

--- Comment #7 from Bernd Edlinger <bernd.edlinger at hotmail dot de> ---
Created attachment 32150
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32150&action=edit
reduced test case

[Bug fortran/60191] test case gfortran.dg/dynamic_dispatch_1/3.f03 fail on ARMv7

[bernd.edlinger at hotmail dot de]

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

--- Comment #8 from Bernd Edlinger <bernd.edlinger at hotmail dot de> ---
(In reply to janus from comment #5)
> (In reply to Bernd Edlinger from comment #3)
> > > The function "make_real" is not invoked directly, but through the type-bound
> > > "a%real", which is called three times in the test case. Does the failure
> > > occur already at the first one (i.e. line 67)? Can you give a reduced test
> > > case?
> > 
> > Yes it is in line 67.
> 
> Ok, then I guess the following reduction should be enough to trigger the bug?
> 
> 
> module m
> 
>   type :: t1
>     integer :: i = 42
>   contains
>     procedure, pass :: real => make_real
>   end type
> 
> contains
> 
>   real function make_real (arg)
>     class(t1), intent(in) :: arg
>     make_real = real (arg%i)
>   end function make_real
> 
> end module m
> 
>   use m
>   class(t1), pointer :: a
>   type(t1), target :: b
>   a => b
>   if (a%real() .ne. real (42)) call abort
> end
> 
> 

The crash occurs if I add the line "procedure(make_real), pointer :: ptr"
to type t1.

> Additionally you could try if calling 'make_real' directly (without the
> type-binding) works, i.e. replace the last line by:
> 
>   if (make_real(a) .ne. real (42)) call abort
> 
> 

This line does not abort.


> > > The type-bound call is transformed into a procedure-pointer-component
> > > call, i.e. "a._vptr->real (&a)". Do all the proc_ptr_comp_* test cases work
> > > on ARMv7?
> > 
> > Yes, the test cases that failed with the last snapshot are:
> > 
> > FAIL: gfortran.dg/dynamic_dispatch_1.f03  -O0  execution test
> > FAIL: gfortran.dg/dynamic_dispatch_3.f03  -O0  execution test
> > FAIL: gfortran.dg/select_type_4.f90  -O2  execution test
> 
> This one might possibly be related. It also involves polymorphism (but no
> type-bound procedures).

I think dynamic_dispatch_3.f03 duplicates this one.
But I am not sure about select_type_4.f90:

$ gfortran -O1 -g select_type_4.f90 -o select_type_4
$ ./select_type_4 
   1.23000002    
          42
 Node with no data.
 Some other node type.
   4.55999994    

$ gfortran -O2 -g select_type_4.f90 -o select_type_4
$ ./select_type_4
    1.23000002    
          42

Program received signal SIGSEGV: Segmentation fault - invalid memory reference.

Backtrace for this error:
Segmentation fault

Program received signal SIGSEGV, Segmentation fault.
MAIN__ () at select_type_4.f90:166
166            if (cnt /= 4) call abort()

but this statement is executed for the third time when the chash happens:

Breakpoint 2, MAIN__ () at select_type_4.f90:166
166            if (cnt /= 4) call abort()
2: /x $r2 = 0x8db4
1: x/i $pc
=> 0x8b14 <MAIN__+608>:    ldr    r3, [r2]
(gdb) c
Continuing.
   1.23000002    

Breakpoint 2, MAIN__ () at select_type_4.f90:166
166            if (cnt /= 4) call abort()
2: /x $r2 = 0x8dcc
1: x/i $pc
=> 0x8b14 <MAIN__+608>:    ldr    r3, [r2]
(gdb) c
Continuing.
          42

Breakpoint 2, MAIN__ () at select_type_4.f90:166
166            if (cnt /= 4) call abort()
2: /x $r2 = 0xf15aea17
1: x/i $pc
=> 0x8b14 <MAIN__+608>:    ldr    r3, [r2]

this looks like some loop optimization problem.

[Bug fortran/60191] test case gfortran.dg/dynamic_dispatch_1/3.f03 fail on ARMv7

[burnus at gcc dot gnu.org]

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

Tobias Burnus <burnus at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |wrong-code
                 CC|                            |burnus at gcc dot gnu.org

--- Comment #10 from Tobias Burnus <burnus at gcc dot gnu.org> ---
(In reply to Bernd Edlinger from comment #9)
> Varargs functions return a float result in r0
> Normal functions returns a float result in s0.
> 
> If there were float arguments they would not be passed
> on FPU-Registers for varargs functions, but because fortran
> passes every in-parameter by reference that is not visible.

That sounds difficult to fix.

gfortran currently generates when it does not know the explicit interface
something like:
   float funct(...)
which for normal functions can be updated via the use of the function
   a = funct(1.0) ! => one argument of type real.

[This updated of the interface base on the usage is not yet implemented and
some PR exists for this; I think it is PR44471.]


The problem is with procedure pointers of the form
   procedure(real), pointer :: ptr

Those can point to any function returning a "real" - and one can have different
ones at different places in the program. - I have no idea how to solve this.
[Note: Fortran does not support variadic arguments.]


[Side note: Fortran also permits to use "procedure(make_real),pointer", which
provides the proper interface.]

[Bug fortran/60191] test case gfortran.dg/dynamic_dispatch_1/3.f03 fail on ARMv7

[bernd.edlinger at hotmail dot de]

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

--- Comment #12 from Bernd Edlinger <bernd.edlinger at hotmail dot de> ---
Created attachment 32448
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32448&action=edit
possible fix

Ok, the attached patch seems to fix at least the
dynamic_dispatch_X.f03 test cases on ARMv7 with float-abi=hard.
No regressions on X86_64 so far.
I will run the ARMv7 test suite over the next days.

[Bug fortran/60191] test case gfortran.dg/dynamic_dispatch_1/3.f03 fail on ARMv7

[mikael at gcc dot gnu.org]

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

Mikael Morin <mikael at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mikael at gcc dot gnu.org

--- Comment #13 from Mikael Morin <mikael at gcc dot gnu.org> ---
Patch posted at
http://gcc.gnu.org/ml/gcc-patches/2014-03/msg01690.html

I have no time to review it now, so I'm just adding a cross-reference to
where the error_mark_node thing comes from:
It comes from http://gcc.gnu.org/r195890 or namely pr54107.

[Bug fortran/60191] test case gfortran.dg/dynamic_dispatch_1/3.f03 fail on ARMv7

[edlinger at gcc dot gnu.org]

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

--- Comment #14 from edlinger at gcc dot gnu.org ---
Author: edlinger
Date: Fri Apr  4 13:54:16 2014
New Revision: 209091

URL: http://gcc.gnu.org/viewcvs?rev=209091&root=gcc&view=rev
Log:
2014-04-04  Bernd Edlinger  <bernd.edlinger@hotmail.de>

        PR fortran/60191
        * fortran/trans-types.c (gfc_get_function_type): In case of recursion
        build a variadic function type with empty argument list instead of a
        stdarg-like function type with incomplete argument list.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/fortran/trans-types.c

[Bug fortran/60191] test case gfortran.dg/dynamic_dispatch_1/3.f03 fail on ARMv7

[bernd.edlinger at hotmail dot de]

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

Bernd Edlinger <bernd.edlinger at hotmail dot de> changed:

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

--- Comment #15 from Bernd Edlinger <bernd.edlinger at hotmail dot de> ---
fixed.

[Bug fortran/60191] test case gfortran.dg/dynamic_dispatch_1/3.f03 fail on ARMv7

[edlinger at gcc dot gnu.org]

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

--- Comment #16 from edlinger at gcc dot gnu.org ---
Author: edlinger
Date: Thu Apr 10 20:13:23 2014
New Revision: 209282

URL: http://gcc.gnu.org/viewcvs?rev=209282&root=gcc&view=rev
Log:
moved this ChangeLog entry to fortran/ChangeLog
2014-04-04  Bernd Edlinger  <bernd.edlinger@hotmail.de>

        PR fortran/60191
        * fortran/trans-types.c (gfc_get_function_type): In case of recursion
        build a variadic function type with empty argument list instead of a
        stdarg-like function type with incomplete argument list.


Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/fortran/ChangeLog