[Bug fortran/107595] New: ICE in ix86_push_argument, at config/i386/i386.cc:4335

[Bug fortran/107595] New: ICE in ix86_push_argument, at config/i386/i386.cc:4335

[gscfq@t-online.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107595

            Bug ID: 107595
           Summary: ICE in ix86_push_argument, at config/i386/i386.cc:4335
           Product: gcc
           Version: 13.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: gscfq@t-online.de
  Target Milestone: ---

Affects versions down to at least r5 :
(GNU Extension: Old-style initialization )


$ cat z1.f90
program p
   type t
      integer :: a
      integer, pointer :: b
   end type
   type(t) x /t(4, null())/
   print *, x%b
end


$ cat z2.f90
program p
   type t
      integer :: a
      integer, pointer :: b
   end type
   type(t) :: x = t(4, null())
   print *, x%b
end


$ gfortran-13-20221106 -c z2.f90
$
$ gfortran-13-20221106 -c z1.f90
z1.f90:8:3:

    8 | end
      |   ^
internal compiler error: Segmentation fault
0xf4697f crash_signal
        ../../gcc/toplev.cc:314
0x134e81d ix86_push_argument
        ../../gcc/config/i386/i386.cc:4335
0x9bcce3 expand_call(tree_node*, rtx_def*, int)
        ../../gcc/calls.cc:2688
0xb1cb29 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
        ../../gcc/expr.cc:11868
0x13138ac expand_expr
        ../../gcc/expr.h:310
0x13138ac output_constant
        ../../gcc/varasm.cc:5250
0x1314d97 output_constant
        ../../gcc/varasm.cc:5158
0x1314d97 output_constructor_regular_field
        ../../gcc/varasm.cc:5545
0x1314d97 output_constructor
        ../../gcc/varasm.cc:5812
0x1316ba9 output_constant
        ../../gcc/varasm.cc:5158
0x1316ba9 assemble_variable_contents
        ../../gcc/varasm.cc:2231
0x13218dc assemble_variable(tree_node*, int, int, int)
        ../../gcc/varasm.cc:2410
0x1324f84 varpool_node::assemble_decl()
        ../../gcc/varpool.cc:596
0xa2b037 output_in_order
        ../../gcc/cgraphunit.cc:2151
0xa2b037 symbol_table::compile()
        ../../gcc/cgraphunit.cc:2355
0xa2e97f symbol_table::compile()
        ../../gcc/cgraphunit.cc:2546
0xa2e97f symbol_table::finalize_compilation_unit()
        ../../gcc/cgraphunit.cc:2543

[Bug fortran/107595] [13 Regression] ICE in ix86_push_argument, at config/i386/i386.cc:4335

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107595

H.J. Lu <hjl.tools at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2022-11-09
             Status|UNCONFIRMED                 |WAITING
     Ever confirmed|0                           |1

--- Comment #1 from H.J. Lu <hjl.tools at gmail dot com> ---
I can't reproduce it on x86-64.  The code is

static bool
ix86_push_argument (unsigned int npush)
{
  /* If SSE2 is available, use vector move to put large argument onto
     stack.  NB:  In 32-bit mode, use 8-byte vector move.  */
  return ((!TARGET_SSE2 || npush < (TARGET_64BIT ? 16 : 8)) 
          && TARGET_PUSH_ARGS
          && !ACCUMULATE_OUTGOING_ARGS);
}

It shouldn't segfault.

[Bug fortran/107595] [13 Regression] ICE in ix86_push_argument, at config/i386/i386.cc:4335

[kargl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107595

kargl at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kargl at gcc dot gnu.org
           Keywords|ice-on-valid-code           |

--- Comment #2 from kargl at gcc dot gnu.org ---
I've remove the ice-on-valid-code designation.
Restore it if you believe otherwise.

Allowing old style (aka nonstandard) initialization of variable
declared with a user-defined derived type should be deprecated.
There is no reason to avoid standard conforming code:

   type(t) x /t(4, null())/
   type(t) :: x = t(4, null())



diff --git a/gcc/fortran/decl.cc b/gcc/fortran/decl.cc
index 0f9b2ced4c2..5627ea24245 100644
--- a/gcc/fortran/decl.cc
+++ b/gcc/fortran/decl.cc
@@ -2969,6 +2977,14 @@ variable_decl (int elem)
          goto cleanup;
        }

+      if (current_ts.type == BT_DERIVED)
+       {
+         gfc_error ("Old style initialization incompatiable with a variable "
+                    "declared with a user-defined derived type at %C");
+         m = MATCH_ERROR;
+         goto cleanup;
+       }
+
       /* For structure components, read the initializer as a special
          expression and let the rest of this function apply the initializer
          as usual.  */

[Bug fortran/107595] [13 Regression] ICE in ix86_push_argument, at config/i386/i386.cc:4335

[kargl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107595

kargl at gcc dot gnu.org changed:

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

--- Comment #3 from kargl at gcc dot gnu.org ---
Change status to NEW as I see the same issue as Gerhard.

[Bug fortran/107595] [13 Regression] ICE in ix86_push_argument, at config/i386/i386.cc:4335

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107595

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |13.0

--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
It ICEs because 'cfun' is NULL and x86 has

#define ACCUMULATE_OUTGOING_ARGS \
  ((TARGET_ACCUMULATE_OUTGOING_ARGS \
    && optimize_function_for_speed_p (cfun)) \
   || (cfun->machine->func_type != TYPE_NORMAL \
       && crtl->stack_realign_needed) \
   || TARGET_STACK_PROBE \
   || TARGET_64BIT_MS_ABI \
   || (TARGET_MACHO && crtl->profile))

we are assembling a static variable with an initializer containing a call
(that's not a valid initializer).

 <var_decl 0x7ffff6523c60 x
    type <record_type 0x7ffff6711b28 t TI
        size <integer_cst 0x7ffff6517c90 constant 128>
        unit-size <integer_cst 0x7ffff6517ca8 constant 16>
        align:64 warn_if_not_align:0 symtab:0 alias-set 9 canonical-type
0x7ffff6711b28
        fields <field_decl 0x7ffff67131c8 a type <integer_type 0x7ffff65325e8
integer(kind=4)>
            SI t.f90:3:18
            size <integer_cst 0x7ffff6517e88 constant 32>
            unit-size <integer_cst 0x7ffff6517ea0 constant 4>
            align:32 warn_if_not_align:0 offset_align 128 decl_not_flexarray: 0
            offset <integer_cst 0x7ffff6517c78 constant 0>
            bit-offset <integer_cst 0x7ffff6517cc0 constant 0> context
<record_type 0x7ffff6711b28 t> chain <field_decl 0x7ffff6713260 b>>
        chain <type_decl 0x7ffff67132f8 D.4263>>
    asm_written used static TI t.f90:6:12 size <integer_cst 0x7ffff6517c90 128>
unit-size <integer_cst 0x7ffff6517ca8 16>
    align:128 warn_if_not_align:0 context <function_decl 0x7ffff6712d00 p>
initial <constructor 0x7ffff6700a20>
    (mem/c:TI (symbol_ref:DI ("x.1") [flags 0x2] <var_decl 0x7ffff6523c60 x>)
[9 x+0 S16 A128])>

The initializer is

{.a=4, .b=null ()}

the frontend would need to lower such initializers to runtime initialization
(or not use static storage).

[Bug fortran/107595] [13 Regression] ICE in ix86_push_argument, at config/i386/i386.cc:4335

[anlauf at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107595

--- Comment #5 from anlauf at gcc dot gnu.org ---
(In reply to Richard Biener from comment #4)
> The initializer is
> 
> {.a=4, .b=null ()}
> 
> the frontend would need to lower such initializers to runtime initialization
> (or not use static storage).

Right.  The tree-dump for z2 has

  static struct t x = {.a=4, .b=0B};

which is what is expected, while z1 currently gives

  static struct t x = {.a=4, .b=null ()};

That looks like sth. that is fixable.

(There is at least one other compiler that supports the same extension.)

On the other hand, since I get the same ICE with all versions down to v7,
why is this marked as a regression?

[Bug fortran/107595] ICE in ix86_push_argument, at config/i386/i386.cc:4335

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107595

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|13.0                        |---
            Summary|[13 Regression] ICE in      |ICE in ix86_push_argument,
                   |ix86_push_argument, at      |at config/i386/i386.cc:4335
                   |config/i386/i386.cc:4335    |

[Bug fortran/107595] ICE in ix86_push_argument, at config/i386/i386.cc:4335

[anlauf at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107595

anlauf at gcc dot gnu.org changed:

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

--- Comment #6 from anlauf at gcc dot gnu.org ---
Slight reduction of the testcase:

program p
  type t
     integer, pointer :: b
  end type
! type(t) :: x = t(null())   ! OK
  type(t)    x  /t(null())/  ! ICE
  if (associated (x%b)) stop
end

Comparing the -fdump-fortran-original for both variants:

@@ -15,7 +15,7 @@
     result: associated
   symtree: 'null'        || symbol: 'null'         
     type spec : (INTEGER 4)
-    attributes: (PROCEDURE INTRINSIC-PROC  FUNCTION IMPLICIT-TYPE
ARRAY-OUTER-DEPENDENCY)
+    attributes: (PROCEDURE  FUNCTION IMPLICIT-TYPE ARRAY-OUTER-DEPENDENCY)
     result: null
   symtree: 'p'           || symbol: 'p'            
     type spec : (UNKNOWN 0)
@@ -27,8 +27,8 @@
     result: t
   symtree: 'x'           || symbol: 'x'            
     type spec : (DERIVED t)
-    attributes: (VARIABLE IMPLICIT-SAVE)
-    value: t(NULL())
+    attributes: (VARIABLE  DATA)
+    value: t(null[()])

   code:
   IF _gfortran_associated[[((p:x % b) ((arg not-present)))]]


Are we just missing the resolution of NULL() in the failing case early enough?