[LLVMdev] gfortran: array constructor problems

[Chris Lattner]

On Wed, 6 Sep 2006, Michael McCracken wrote:
>> If you don't feel up to that, I'd be ok relaxing the assert, assuming that
>> the generated code is in fact correct.
>
> Here's a patch that fixes the error - if a constant array was being
> initialized as a list of structures, the 'tree's generated for the
> structures weren't being set as constant, even though the overall tree
> was. This caused a problem when being translated into LLVM.

Ok

> This works on my test case, which looked like this:
>
> type :: foo
> integer :: a
> integer :: b
> end type foo
> type (foo), parameter :: A(2) = (/ foo(1,2), foo(2,4) /)
>
> There is at least one other point in gfc_conv_array_initializer()
> where they build tree lists of structures using gfc_conv_structure().
> That part should probably set each tree's constant flag as well,
> probably on line 2843. However, I couldn't test that change, since the
> only way I could think of to get to that code path will crash gfortran
> somewhere else, and I didn't want to work on that just yet.

I'm trying to understand the logic the front-end is going through here (a 
crash course in the fortran f.e., something completely new to me), and it 
doesn't seem like this is the best place to fix this.  To me, the problem 
seems to be that the code making the subelement should mark it constant, 
not the user of the subelement.

In particular, what do you think of this patch?:

Index: trans-expr.c
===================================================================
--- trans-expr.c        (revision 117639)
+++ trans-expr.c        (working copy)
@@ -1853,6 +1853,12 @@
            tail = val;
          }
      }
+
+  if (init)
+    {
+      TREE_CONSTANT (head) = 1;
+      TREE_INVARIANT (tmp) = 1;
+    }
    se->expr = head;
  }


I still haven't had a chance to build an llvm-gfortran, so I'd appreciate 
it if you could let me know if this works as well as your other patch, 
without other side effects.  If so, I'll propose this as a patch on gcc 
mainline, which seems to also have this problem.

Thanks,

-Chris

-- 
http://nondot.org/sabre/
http://llvm.org/