public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug fortran/107595] New: ICE in ix86_push_argument, at config/i386/i386.cc:4335
@ 2022-11-09 17:55 gscfq@t-online.de
2022-11-09 21:17 ` [Bug fortran/107595] [13 Regression] " hjl.tools at gmail dot com
` (6 more replies)
0 siblings, 7 replies; 8+ messages in thread
From: gscfq@t-online.de @ 2022-11-09 17:55 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug fortran/107595] [13 Regression] ICE in ix86_push_argument, at config/i386/i386.cc:4335
2022-11-09 17:55 [Bug fortran/107595] New: ICE in ix86_push_argument, at config/i386/i386.cc:4335 gscfq@t-online.de
@ 2022-11-09 21:17 ` hjl.tools at gmail dot com
2022-11-09 22:28 ` kargl at gcc dot gnu.org
` (5 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: hjl.tools at gmail dot com @ 2022-11-09 21:17 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug fortran/107595] [13 Regression] ICE in ix86_push_argument, at config/i386/i386.cc:4335
2022-11-09 17:55 [Bug fortran/107595] New: ICE in ix86_push_argument, at config/i386/i386.cc:4335 gscfq@t-online.de
2022-11-09 21:17 ` [Bug fortran/107595] [13 Regression] " hjl.tools at gmail dot com
@ 2022-11-09 22:28 ` kargl at gcc dot gnu.org
2022-11-09 22:29 ` kargl at gcc dot gnu.org
` (4 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: kargl at gcc dot gnu.org @ 2022-11-09 22:28 UTC (permalink / raw)
To: gcc-bugs
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. */
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug fortran/107595] [13 Regression] ICE in ix86_push_argument, at config/i386/i386.cc:4335
2022-11-09 17:55 [Bug fortran/107595] New: ICE in ix86_push_argument, at config/i386/i386.cc:4335 gscfq@t-online.de
2022-11-09 21:17 ` [Bug fortran/107595] [13 Regression] " hjl.tools at gmail dot com
2022-11-09 22:28 ` kargl at gcc dot gnu.org
@ 2022-11-09 22:29 ` kargl at gcc dot gnu.org
2022-11-10 7:25 ` rguenth at gcc dot gnu.org
` (3 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: kargl at gcc dot gnu.org @ 2022-11-09 22:29 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug fortran/107595] [13 Regression] ICE in ix86_push_argument, at config/i386/i386.cc:4335
2022-11-09 17:55 [Bug fortran/107595] New: ICE in ix86_push_argument, at config/i386/i386.cc:4335 gscfq@t-online.de
` (2 preceding siblings ...)
2022-11-09 22:29 ` kargl at gcc dot gnu.org
@ 2022-11-10 7:25 ` rguenth at gcc dot gnu.org
2022-11-10 19:11 ` anlauf at gcc dot gnu.org
` (2 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: rguenth at gcc dot gnu.org @ 2022-11-10 7:25 UTC (permalink / raw)
To: gcc-bugs
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).
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug fortran/107595] [13 Regression] ICE in ix86_push_argument, at config/i386/i386.cc:4335
2022-11-09 17:55 [Bug fortran/107595] New: ICE in ix86_push_argument, at config/i386/i386.cc:4335 gscfq@t-online.de
` (3 preceding siblings ...)
2022-11-10 7:25 ` rguenth at gcc dot gnu.org
@ 2022-11-10 19:11 ` anlauf at gcc dot gnu.org
2022-11-10 19:12 ` [Bug fortran/107595] " pinskia at gcc dot gnu.org
2022-11-17 21:29 ` anlauf at gcc dot gnu.org
6 siblings, 0 replies; 8+ messages in thread
From: anlauf at gcc dot gnu.org @ 2022-11-10 19:11 UTC (permalink / raw)
To: gcc-bugs
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?
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug fortran/107595] ICE in ix86_push_argument, at config/i386/i386.cc:4335
2022-11-09 17:55 [Bug fortran/107595] New: ICE in ix86_push_argument, at config/i386/i386.cc:4335 gscfq@t-online.de
` (4 preceding siblings ...)
2022-11-10 19:11 ` anlauf at gcc dot gnu.org
@ 2022-11-10 19:12 ` pinskia at gcc dot gnu.org
2022-11-17 21:29 ` anlauf at gcc dot gnu.org
6 siblings, 0 replies; 8+ messages in thread
From: pinskia at gcc dot gnu.org @ 2022-11-10 19:12 UTC (permalink / raw)
To: gcc-bugs
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 |
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug fortran/107595] ICE in ix86_push_argument, at config/i386/i386.cc:4335
2022-11-09 17:55 [Bug fortran/107595] New: ICE in ix86_push_argument, at config/i386/i386.cc:4335 gscfq@t-online.de
` (5 preceding siblings ...)
2022-11-10 19:12 ` [Bug fortran/107595] " pinskia at gcc dot gnu.org
@ 2022-11-17 21:29 ` anlauf at gcc dot gnu.org
6 siblings, 0 replies; 8+ messages in thread
From: anlauf at gcc dot gnu.org @ 2022-11-17 21:29 UTC (permalink / raw)
To: gcc-bugs
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?
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2022-11-17 21:29 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-11-09 17:55 [Bug fortran/107595] New: ICE in ix86_push_argument, at config/i386/i386.cc:4335 gscfq@t-online.de
2022-11-09 21:17 ` [Bug fortran/107595] [13 Regression] " hjl.tools at gmail dot com
2022-11-09 22:28 ` kargl at gcc dot gnu.org
2022-11-09 22:29 ` kargl at gcc dot gnu.org
2022-11-10 7:25 ` rguenth at gcc dot gnu.org
2022-11-10 19:11 ` anlauf at gcc dot gnu.org
2022-11-10 19:12 ` [Bug fortran/107595] " pinskia at gcc dot gnu.org
2022-11-17 21:29 ` anlauf at gcc dot gnu.org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).