[Bug fortran/96986] [8/9/10/11 Regression] Explicit interface required: volatile argument for ENTRY subroutine

2021-01-01 Thread foreese at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96986

--- Comment #3 from Fritz Reese  ---
(In reply to anlauf from comment #2)
...
> So I'd say the code in comment#0 is invalid, although the compiler is not
> required to diagnose this.
> 
> If you agree, we will close the issue as INVALID.

The error message blames fun_a() while neither fun_a() nor its containing
subroutine volatile_test() have a VOLATILE dummy argument. Do you think
15.4.2.2 still applies?

[Bug fortran/105310] New: ICE when UNION is after the 8th field in a DEC STRUCTURE with -finit-derived -finit-local-zero

2022-04-19 Thread foreese at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105310

Bug ID: 105310
   Summary: ICE when UNION is after the 8th field in a DEC
STRUCTURE with -finit-derived -finit-local-zero
   Product: gcc
   Version: 7.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: foreese at gcc dot gnu.org
  Target Milestone: ---

Created attachment 52833
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52833&action=edit
Test case exhibiting the ICE

Consider:

$ cat testunion.for
  PROGRAM TESTU
IMPLICIT NONE
STRUCTURE /FOO/
  INTEGER(4) :: a,b,c,d,e,f,g,h
  UNION
  MAP
  ENDMAP
  ENDUNION
ENDSTRUCTURE
RECORD /FOO/ bar
bar.a = 1
  END

$ gfortran -O0 -c -ffixed-form -finit-local-zero -finit-derived -fdec-structure
testunion.for
testunion.for:15:0:

   end

internal compiler error: Segmentation fault
0xa72a2f crash_signal
/data/gcc-7.4.0/gcc/toplev.c:337
0xcb6a54 compute_reloc_for_constant(tree_node*)
/data/gcc-7.4.0/gcc/varasm.c:4120
0xcb6b5c compute_reloc_for_constant(tree_node*)
/data/gcc-7.4.0/gcc/varasm.c:4174
0xcbc802 get_variable_section(tree_node*, bool)
/data/gcc-7.4.0/gcc/varasm.c:1148
0xcc0cb7 assemble_variable(tree_node*, int, int, int)
/data/gcc-7.4.0/gcc/varasm.c:2225
0xcc4ce2 varpool_node::assemble_decl()
/data/gcc-7.4.0/gcc/varpool.c:588
0x7426fc output_in_order
/data/gcc-7.4.0/gcc/cgraphunit.c:2289
0x742ac3 symbol_table::compile()
/data/gcc-7.4.0/gcc/cgraphunit.c:2530
0x744b16 symbol_table::compile()
/data/gcc-7.4.0/gcc/cgraphunit.c:2629
0x744b16 symbol_table::finalize_compilation_unit()
/data/gcc-7.4.0/gcc/cgraphunit.c:2626
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.


ICE occurs with 7.4 and higher, where the -fdec-structure and -finit-derived
options were introduced.

The ICE occurs at -O0 but not for higher optimization levels. The ICE occurs
only when there are (8*2^n) fields preceding the union, regardless of which
fields are in the union.

[Bug fortran/105310] ICE when UNION is after the 8th field in a DEC STRUCTURE with -finit-derived -finit-local-zero

2022-04-19 Thread foreese at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105310

Fritz Reese  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2022-04-19
   Assignee|unassigned at gcc dot gnu.org  |foreese at gcc dot 
gnu.org

--- Comment #1 from Fritz Reese  ---
Created attachment 52834
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52834&action=edit
Patch which fixes the bug based on trunk

The bug is caused by gfc_conv_union_initializer in gcc/fortran/trans-expr.cc,
which accepts a pointer to a vector of constructor trees (vec*) as an argument, then appends one or two field constructors to the
vector. The problem is the use of CONSTRUCTOR_APPEND_ELT(v, ...) within
gfc_conv_union_initializer, which modifies the vector pointer v when a
reallocation of the vector occurs, but the pointer is passed by value.
Therefore, when a vector reallocation occurs, the vector caller's
(gfc_conv_structure) vector pointer is not updated and subsequently points to
freed memory. Chaos ensues.

The bug only occurs when gfc_conv_union_initializer itself triggers the
reallocation, which is whenever the vector is "full" (v->m_vecpfx.m_alloc ==
v->m_vecpfx.m_num). Since the vector defaults to allocating 8 elements and
doubles in size for every reallocation, the bug only occurs when there are 8,
16, 32, etc... fields with initializers prior to the union, causing the vector
of constructors to be resized when entering gfc_conv_union_initializer. The
-finit-derived and -finit-local-zero options together ensure each field has an
initializer, triggering the bug.

The patch fixes the bug by passing the vector pointer to
gfc_conv_union_initializer by reference, matching the signature of
vec_safe_push from within the CONSTRUCTOR_APPEND_ELT macro.