Possible cause for the regression:

r126744 | burnus | 2007-07-19 08:14:19 +0200 (Thu, 19 Jul 2007) | 14 lines
2007-07-19  Christopher D. Rickett  <crickett@lanl.gov>
        PR fortran/32600
        * trans-expr.c (gfc_conv_function_call): Inline C_LOC.

2007-07-19  Christopher D. Rickett  <crickett@lanl.gov>
        PR fortran/32600
        * libgfortran/intrinsics/iso_c_binding.c: Remove C_LOC.
        * libgfortran/intrinsics/iso_c_binding.h: Ditto.
        * libgfortran/gfortran.map: Ditto.

How is this a regression?  ISO_C_BINDING is new for 4.3.0 :).

> How is this a regression? ISO_C_BINDING is new for 4.3.0 :).

Well, it is not a regression versus 4.2, but it is nonetheless a regression: It was working before. How are such regressions marked?

 * * *

Simplified test case:

  USE ISO_C_BINDING
  TYPE(C_PTR), TARGET, SAVE :: argv
  INTERFACE
    SUBROUTINE glutInit_gl(argv) BIND(C)
      import
      TYPE(C_PTR) :: argv
    END SUBROUTINE glutInit_gl
  END INTERFACE
  CALL glutInit_gl(C_LOC(argv))
END


Dumped tree:

MAIN__ ()
{
  static void * argv;
  static integer(kind=4) options.0[7] = {68, 127, 0, 0, 0, 1, 0};

  _gfortran_set_options (7, (void *) &options.0);
  {
    static void * * C.906 = &argv;

    glutinit_gl (&C.906);
  }
}

Forget to write that the ICE is gone if one removed the SAVE

I've posted a workaround patch at http://gcc.gnu.org/ml/fortran/2008-02/msg00092.html. My analysis is currently as follow: we currently have

    static void * * C.906 = &argv;
    glutinit_gl (&C.906);

which leads to the ICE in expand_expr_addr_expr_1(). The code we emitted before, when C_LOC wasn't inlined, was:

    void * C.906 = _gfortran_c_loc (&argv);
    glutinit_gl (&C.906);

where _gfortran_c_loc was effectively:

    void * _gfortran_c_loc (void *p) { return p; }

As Tobias shown, the code taking care of taking the adress of argv (constructing "&argv") is in function gfc_conv_function_call (in trans-expr.c). I have tried to modify it by forcing a cast to pvoid_type_node, but it still gets the "static" attribute later. The variable creation is not done in that function, but later (and I cannot see why). If someone knows where, that would be great.

PS: I think that translating the ISO_C_BINDING inlined functions in gfc_conv_function_call() is actually too late. The intrinsic functions, for example, are intercepted somewhere earlier in the code path, and I think that would be better to do it in a similar way for intrinsic module functions (now, ISO_C_BINDING, and later, IEEE_*).

(In reply to comment #3)
> Simplified test case:
This now works with FX's patch.

However, using F03GL still fails with:
OpenGL_glut.f90: In function ‘glutinit_f03’:
OpenGL_glut.f90:1518: internal compiler error: in expand_expr_addr_expr_1, at expr.c:6835

For a reduced test case see comment 0. For that test case, one has the dump:

glutinit_f03 ()
{
  static integer(kind=4) argcp = 1;
  static void * argv[1] = {0};
  {
    static void *[1] * C.910 = &argv;
    glutinit_gl (&argcp, &C.910);
  }
}

That is, the ELSE branch needs to be fixed as well; the fix was only for rank == 0.

(In reply to comment #6)
> That is, the ELSE branch needs to be fixed as well; the fix was only for rank
> == 0.

OK, here is an updated patch:

Index: trans-expr.c
===================================================================
--- trans-expr.c        (revision 132257)
+++ trans-expr.c        (working copy)
@@ -2264,6 +2264,13 @@
              gfc_conv_array_parameter (se, arg->expr, argss, f);
            }
 
+         /* TODO -- the following two lines shouldn't be necessary, but
+            they're removed a bug is exposed later in the codepath.
+            This is workaround was thus introduced, but will have to be
+            removed; please see PR 35150 for details about the issue.  */
+         se->expr = convert (pvoid_type_node, se->expr);
+         se->expr = gfc_evaluate_now (se->expr, &se->pre);
+
          return 0;
        }
       else if (sym->intmod_sym_id == ISOCBINDING_FUNLOC)


I've started regtesting and will submit it for review afterwards.

Fixed on trunk:

Author: fxcoudert
Date: Fri Feb 15 21:12:24 2008
New Revision: 132353

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132353
Log:
	* trans-expr.c (gfc_conv_function_call): Force evaluation of
	se->expr.

	* gfortran.dg/c_loc_tests_12.f03: New test.

Added:
    trunk/gcc/testsuite/gfortran.dg/c_loc_tests_12.f03
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/trans-expr.c
    trunk/gcc/testsuite/ChangeLog