Re:[gfortran] Patch Ping**2

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Re:[gfortran] Patch Ping**2

Paul Thomas-4
Tobi,

Do my recent patches and test cases survive this patch? I note that the
dates on you patch predate mine.  From a cursory peek, we might be trampling
on each others toes. Did you already bootstrap and regtest the patch on the
current mailine?

Paul T
Reply | Threaded
Open this post in threaded view
|

Re: [gfortran] Patch Ping**2

Tobias Schlüter
Paul Thomas wrote:
> Do my recent patches and test cases survive this patch? I note that the
> dates on you patch predate mine.  From a cursory peek, we might be trampling
> on each others toes. Did you already bootstrap and regtest the patch on the
> current mailine?

I jsut got back home, and my build / testsuite run has finished.  Alas, I'm
seeing a bug deep in the innards of the compiler in one of my new testcases:
the tree-checking phase complains.  I'll have a look at this tomorrow.

- Tobi

Reply | Threaded
Open this post in threaded view
|

Re: [gfortran] Patch Ping**2

Tobias Schlüter
Tobias Schl?ter wrote:

> Paul Thomas wrote:
>
>>Do my recent patches and test cases survive this patch? I note that the
>>dates on you patch predate mine.  From a cursory peek, we might be trampling
>>on each others toes. Did you already bootstrap and regtest the patch on the
>>current mailine?
>
>
> I jsut got back home, and my build / testsuite run has finished.  Alas, I'm
> seeing a bug deep in the innards of the compiler in one of my new testcases:
> the tree-checking phase complains.  I'll have a look at this tomorrow.
This turned out to be a gimplifier bug, now PR22035.  Something as simple as
   COMPLEX z, w
   z = (1.,2.)
   if (z/=w) call abort
   end
ICEs on the mainline currently.

I will commit the patch and the other testcase to the mainline, and the patch
together with both patches to the 4.0 branch.  The testcase which is broken
will have to wait for the above bug -- which is completely unrelated, except
that it happened to appear in this testcase -- to get fixed.

Since the patch didn't apply cleanly anymore, I attached the updated version
I'm committing.

- Tobi

Index: trans-expr.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/fortran/trans-expr.c,v
retrieving revision 1.49
diff -u -p -r1.49 trans-expr.c
--- trans-expr.c 1 Jun 2005 07:18:20 -0000 1.49
+++ trans-expr.c 12 Jun 2005 13:54:18 -0000
@@ -379,7 +379,7 @@ gfc_conv_variable (gfc_se * se, gfc_expr
           /* Dereference scalar hidden result.  */
   if (gfc_option.flag_f2c && sym->ts.type == BT_COMPLEX
       && (sym->attr.function || sym->attr.result)
-      && !sym->attr.dimension)
+      && !sym->attr.dimension && !sym->attr.pointer)
     se->expr = gfc_build_indirect_ref (se->expr);
 
           /* Dereference non-character pointer variables.
@@ -1315,9 +1315,6 @@ gfc_conv_function_call (gfc_se * se, gfc
   se->expr = build3 (CALL_EXPR, TREE_TYPE (fntype), se->expr,
      arglist, NULL_TREE);
 
-  if (sym->result)
-    sym = sym->result;
-
   /* If we have a pointer function, but we don't want a pointer, e.g.
      something like
         x = f()
Index: trans-types.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/fortran/trans-types.c,v
retrieving revision 1.45
diff -u -p -r1.45 trans-types.c
--- trans-types.c 26 May 2005 18:36:10 -0000 1.45
+++ trans-types.c 12 Jun 2005 13:54:18 -0000
@@ -1268,11 +1268,6 @@ gfc_sym_type (gfc_symbol * sym)
  return TREE_TYPE (sym->backend_decl);
     }
 
-  /* The frontend doesn't set all the attributes for a function with an
-     explicit result value, so we use that instead when present.  */
-  if (sym->attr.function && sym->result)
-    sym = sym->result;
-
   type = gfc_typenode_for_spec (&sym->ts);
   if (gfc_option.flag_f2c
       && sym->attr.function
@@ -1299,7 +1294,7 @@ gfc_sym_type (gfc_symbol * sym)
   /* If this is a character argument of unknown length, just use the
      base type.  */
   if (sym->ts.type != BT_CHARACTER
-      || !(sym->attr.dummy || sym->attr.function || sym->attr.result)
+      || !(sym->attr.dummy || sym->attr.function)
       || sym->ts.cl->backend_decl)
     {
       type = gfc_get_nodesc_array_type (type, sym->as,
@@ -1467,17 +1462,13 @@ gfc_get_derived_type (gfc_symbol * deriv
 int
 gfc_return_by_reference (gfc_symbol * sym)
 {
-  gfc_symbol *result;
-
   if (!sym->attr.function)
     return 0;
 
-  result = sym->result ? sym->result : sym;
-
-  if (result->attr.dimension)
+  if (sym->attr.dimension)
     return 1;
 
-  if (result->ts.type == BT_CHARACTER)
+  if (sym->ts.type == BT_CHARACTER)
     return 1;
 
   /* Possibly return complex numbers by reference for g77 compatibility.
@@ -1486,7 +1477,7 @@ gfc_return_by_reference (gfc_symbol * sy
      require an explicit interface, as no compatibility problems can
      arise there.  */
   if (gfc_option.flag_f2c
-      && result->ts.type == BT_COMPLEX
+      && sym->ts.type == BT_COMPLEX
       && !sym->attr.intrinsic && !sym->attr.always_explicit)
     return 1;
   
Reply | Threaded
Open this post in threaded view
|

Re: [gfortran] Patch Ping**2

Tobias Schlüter
Tobias Schl?ter wrote:
> This turned out to be a gimplifier bug, now PR22035.  Something as simple as
>    COMPLEX z, w
>    z = (1.,2.)
>    if (z/=w) call abort
>    end
> ICEs on the mainline currently.

... if optimization is enabled, in case you want to try this yourself.

- Tobi
Reply | Threaded
Open this post in threaded view
|

RE: [gfortran] Patch Ping**2

Paul Thomas-4
In reply to this post by Paul Thomas-4
Tobi,

I patched my source by hand, bootstrapped and regtested on Cygwin_NT/Athlon
2300.  It even works as intended!

OK by me.

Paul
Reply | Threaded
Open this post in threaded view
|

Re: [gfortran] Patch Ping**2

Tobias Schlüter
In reply to this post by Tobias Schlüter
Tobias Schl?ter wrote:

> Tobias Schl?ter wrote:
>>I jsut got back home, and my build / testsuite run has finished.  Alas, I'm
>>seeing a bug deep in the innards of the compiler in one of my new testcases:
>>the tree-checking phase complains.  I'll have a look at this tomorrow.
>
>
> This turned out to be a gimplifier bug, now PR22035.  Something as simple as
>    COMPLEX z, w
>    z = (1.,2.)
>    if (z/=w) call abort
>    end
> ICEs on the mainline currently.
>
> I will commit the patch and the other testcase to the mainline, and the patch
> together with both patches to the 4.0 branch.  The testcase which is broken
> will have to wait for the above bug -- which is completely unrelated, except
> that it happened to appear in this testcase -- to get fixed.

The testcase is now on the mainline as well.

- Tobi