[Bug middle-end/45694] New: fortran host associated variables+optimization==failure?

[Bug middle-end/45694] New: fortran host associated variables+optimization==failure?

[jpr at csc dot fi]

Hi,
(i first reported this to mingw32-w64's bug tracker:
http://sourceforge.net/tracker/?func=detail&aid=3067541&group_id=202880&atid=983354
and was forwarded here)

The attached fortran program aborts() (a host associated variable
changes value from host to hostee without asking) using
gfortran -O1 -o fail fail.f90; ./fail
on a 64bit windows 7 (mingw32-w64) platform.

Very probably platform dependent as i can't reproduce this elsewhere.
Also 32bit compile on the same platform works as does unoptimized
compilation.

On a larger application i see sevaral failures of the same kind, seems
to depend also on the number and/or size of the local variables in the
procedures..

Regards, Juha

PS. I entered middle-end as the bugs 'component' as  an optimization flag seems
to be needed to trigger this...


-- 
           Summary: fortran host associated variables+optimization==failure?
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: middle-end
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: jpr at csc dot fi
GCC target triplet: x86_64-w64-mingw32


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

[Bug middle-end/45694] fortran host associated variables+optimization==failure?

[jpr at csc dot fi]

------- Comment #1 from jpr at csc dot fi  2010-09-16 19:31 -------
Created an attachment (id=21812)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21812&action=view)
failing fortran code


-- 


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

[Bug target/45694] fortran host associated variables+optimization==failure?

[jpr at csc dot fi]

------- Comment #2 from jpr at csc dot fi  2010-09-20 06:54 -------
Created an attachment (id=21842)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21842&action=view)
somewhat reduced testcase

Hi,

I tried debugging this more. Attached is a somewhat reduced testcase. I also 
had a look at the assembler generated by 
"x86_64-w64-mingw32-gfortran -save-temps -O1 fail1.f90".

The loadinp looks like  

...
loadinp_:
        subq    $56, %rsp
        movl    $1952671091, 32(%rsp)
        movw    $28521, 36(%rsp)
        movb    $110, 38(%rsp)
        leaq    32(%rsp), %r10
        call    parse_sect.1525
... so it stores the  'section' string to stack and loads %r10 with
the stack address and calls the parse_sect:
....
parse_sect.1525:
        pushq   %rdi
        pushq   %rsi
        pushq   %rbx
        movl    $4032, %eax
        call    ___chkstk
        movq    %r10, %rsi
   ....
which then uses the stack address in %r10. The thing is that the 
__chkstk() call  seems to change the contents of the
%r10. At least doing
...
movq %r10,%r12
call __chkstk
movq %r12,%r10
...
seems to cure the example. What is really going on, anyone?

Br, Juha


-- 


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

[Bug target/45694] [MinGW64] fortran host associated variables+optimization==failure?

[jpr at csc dot fi]

------- Comment #3 from jpr at csc dot fi  2010-09-20 11:05 -------
Even simpler testcase, now in C.


#include <stdio.h>
#include <stdlib.h>

void a()
{
  char s[2];

  void b() {
    char p[4096];

    if ( strcmp(s,"s")!=0 ) abort();
    strcpy( p,"p");
  }

  strcpy( s,"s" );
  b();
}

main()
{
  a();
}


-- 


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

[Bug target/45694] [MinGW64] fortran host associated variables+optimization==failure?

[jpr at csc dot fi]

------- Comment #4 from jpr at csc dot fi  2010-09-20 11:12 -------
For the testcase in comment #3 the ___chkstk call is also 
generated with -O0 (and trying to use %r10 across the call...)

Juha


-- 


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

[Bug target/45694] [MinGW64] fortran host associated variables+optimization==failure?

[jpr at csc dot fi]

------- Comment #5 from jpr at csc dot fi  2010-09-20 11:36 -------
And still reduced testcase, fails at -O0.

void main()
{
  char s;
  void b() {
    char p[4096];
    if ( s!='s' ) abort();
  }
  s='s';
  b();
}


-- 


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

[Bug target/45694] [MinGW64] fortran host associated variables+optimization==failure?

[t66667 at gmail dot com]

------- Comment #6 from t66667 at gmail dot com  2010-09-20 11:41 -------
(In reply to comment #3)
> Even simpler testcase, now in C.
> 
> 
> #include <stdio.h>
> #include <stdlib.h>
> 
> void a()
> {
>   char s[2];
> 
>   void b() {
>     char p[4096];
You deliberately use a very large storage for a very little data.
And it fails on m64 and not m32 which is rather weird and odd.
So I went to the bottom of this number which appears to be 3920.
3920 = ok
Any number beyond 3920 fails on m64 wtf?
I have no idea what is going on.
It just seems to me interesting to test out your case...
Yes O0 fails also... who knows...
> 
>     if ( strcmp(s,"s")!=0 ) abort();
>     strcpy( p,"p");
>   }
> 
>   strcpy( s,"s" );
>   b();
> }
> 
> main()
> {
>   a();
> }
> 


-- 


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

[Bug target/45694] [MinGW64] fortran host associated variables+optimization==failure?

[jpr at csc dot fi]

------- Comment #7 from jpr at csc dot fi  2010-09-20 11:46 -------
Hi,
yes the stack size is relevant here, because otherwise gcc does not
call ___chkstk(), which seems to be the trouble here. 4K stack usage
is not very big IMHO.
-Juha

(In reply to comment #6)
> (In reply to comment #3)
> > Even simpler testcase, now in C.
> > 
> > 
> > #include <stdio.h>
> > #include <stdlib.h>
> > 
> > void a()
> > {
> >   char s[2];
> > 
> >   void b() {
> >     char p[4096];
> You deliberately use a very large storage for a very little data.
> And it fails on m64 and not m32 which is rather weird and odd.
> So I went to the bottom of this number which appears to be 3920.
> 3920 = ok
> Any number beyond 3920 fails on m64 wtf?
> I have no idea what is going on.
> It just seems to me interesting to test out your case...
> Yes O0 fails also... who knows...
> > 
> >     if ( strcmp(s,"s")!=0 ) abort();
> >     strcpy( p,"p");
> >   }
> > 
> >   strcpy( s,"s" );
> >   b();
> > }
> > 
> > main()
> > {
> >   a();
> > }
> > 
> 


-- 


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

[Bug target/45694] [MinGW64] fortran host associated variables+optimization==failure?

[t66667 at gmail dot com]

------- Comment #8 from t66667 at gmail dot com  2010-09-20 11:59 -------
(In reply to comment #7)
> Hi,
> yes the stack size is relevant here, because otherwise gcc does not
> call ___chkstk(), which seems to be the trouble here. 4K stack usage
> is not very big IMHO.
I went deeper... and found out with gcc-4.5-branch the number is different...
3952 = ok
Any number greater then 3952 fails on gcc-4.5...
And again this only applies to m64 not m32...

And very weird it seems that 3952 - 3920 = 32 ...

> -Juha
> 
> (In reply to comment #6)
> > (In reply to comment #3)
> > > Even simpler testcase, now in C.
> > > 
> > > 
> > > #include <stdio.h>
> > > #include <stdlib.h>
> > > 
> > > void a()
> > > {
> > >   char s[2];
> > > 
> > >   void b() {
> > >     char p[4096];
> > You deliberately use a very large storage for a very little data.
> > And it fails on m64 and not m32 which is rather weird and odd.
> > So I went to the bottom of this number which appears to be 3920.
> > 3920 = ok
> > Any number beyond 3920 fails on m64 wtf?
> > I have no idea what is going on.
> > It just seems to me interesting to test out your case...
> > Yes O0 fails also... who knows...
> > > 
> > >     if ( strcmp(s,"s")!=0 ) abort();
> > >     strcpy( p,"p");
> > >   }
> > > 
> > >   strcpy( s,"s" );
> > >   b();
> > > }
> > > 
> > > main()
> > > {
> > >   a();
> > > }
> > > 
> > 
> 


-- 


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

[Bug target/45694] [MinGW64] fortran host associated variables+optimization==failure?

[ktietz at gcc dot gnu dot org]

------- Comment #9 from ktietz at gcc dot gnu dot org  2010-09-20 12:07 -------
(In reply to comment #8)

This issue is caused by the fact that __chkstk clobbers r10 (see its
constrains), which is used here as argument-register for this nested function.
So something is broken here about register-clobbering. I would welcome if my
modified stack-allocation for windows would get reviewed and applied. This new
implementation avoid this useless register-clobbering ... But well, this seems
to me like a bug in interpretation of register clobbering here ...


-- 


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

[Bug target/45694] [MinGW64] fortran host associated variables+optimization==failure?

[t66667 at gmail dot com]

------- Comment #10 from t66667 at gmail dot com  2010-09-21 05:57 -------
(In reply to comment #9)
> (In reply to comment #8)
> 
> This issue is caused by the fact that __chkstk clobbers r10 (see its
> constrains), which is used here as argument-register for this nested function.
> So something is broken here about register-clobbering. I would welcome if my
> modified stack-allocation for windows would get reviewed and applied. This new
> implementation avoid this useless register-clobbering ... But well, this seems
> to me like a bug in interpretation of register clobbering here ...
> 

http://gcc.gnu.org/ml/gcc-patches/2010-09/msg01631.html


-- 


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

[Bug target/45694] [MinGW64] fortran host associated variables+optimization==failure?

[t66667 at gmail dot com]

------- Comment #11 from t66667 at gmail dot com  2010-09-21 10:28 -------
Hi,
(In reply to comment #0)
> Hi,
> (i first reported this to mingw32-w64's bug tracker:
> http://sourceforge.net/tracker/?func=detail&aid=3067541&group_id=202880&atid=983354
> and was forwarded here)
Kai has posted a patch here you can try.
http://gcc.gnu.org/ml/gcc-patches/2010-09/msg01634.html


-- 


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

[Bug target/45694] [MinGW64] fortran host associated variables+optimization==failure?

[ktietz at gcc dot gnu dot org]

------- Comment #12 from ktietz at gcc dot gnu dot org  2010-09-21 17:58 -------
Subject: Bug 45694

Author: ktietz
Date: Tue Sep 21 17:58:32 2010
New Revision: 164489

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=164489
Log:
2010-09-21  Kai Tietz  <kai.tietz@onevision.com>

        PR target/45694
        * config/i386/i386.c (ix86_expand_prologue): Save r10 in case that
        static chain-register is used for 64-bit.


Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/config/i386/i386.c


-- 


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

[Bug target/45694] [MinGW64] fortran host associated variables+optimization==failure?

[ktietz at gcc dot gnu dot org]

------- Comment #13 from ktietz at gcc dot gnu dot org  2010-09-21 19:05 -------
Subject: Bug 45694

Author: ktietz
Date: Tue Sep 21 19:05:18 2010
New Revision: 164495

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=164495
Log:
2010-09-21  Kai Tietz  <kai.tietz@onevision.com>

        PR target/45694
        * config/i386/i386.c (ix86_expand_prologue): Save r10 in case that
        static chain-register is used for 64-bit.


Modified:
    branches/gcc-4_5-branch/gcc/ChangeLog
    branches/gcc-4_5-branch/gcc/config/i386/i386.c


-- 


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

[Bug target/45694] [MinGW64] fortran host associated variables+optimization==failure?

[ktietz at gcc dot gnu dot org]

------- Comment #14 from ktietz at gcc dot gnu dot org  2010-09-21 19:09 -------
Issue fixed on mainline and backported to 4.5 branch


-- 

ktietz at gcc dot gnu dot org changed:

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


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

[Bug target/45694] [MinGW64] fortran host associated variables+optimization==failure?

[t66667 at gmail dot com]

------- Comment #15 from t66667 at gmail dot com  2010-09-22 12:20 -------
Hello,

Thank you so much for getting this problem fixed.


-- 


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