* [Bug fortran/115070] [13/14/15 Regression] ICE using IEEE_ARITHMETIC in a derived type method with class, intent(out)
2024-05-13 14:23 [Bug fortran/115070] New: ICE using IEEE_ARITHMETIC in a derived type method with intent(out) statement bardeau at iram dot fr
@ 2024-05-13 17:09 ` anlauf at gcc dot gnu.org
2024-05-13 17:24 ` anlauf at gcc dot gnu.org
` (7 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: anlauf at gcc dot gnu.org @ 2024-05-13 17:09 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115070
anlauf at gcc dot gnu.org changed:
What |Removed |Added
----------------------------------------------------------------------------
Known to work| |12.3.1
Ever confirmed|0 |1
Target Milestone|--- |13.3
Priority|P3 |P4
Last reconfirmed| |2024-05-13
Known to fail| |13.2.1, 14.1.0, 15.0
Summary|ICE using IEEE_ARITHMETIC |[13/14/15 Regression] ICE
|in a derived type method |using IEEE_ARITHMETIC in a
|with intent(out) statement |derived type method with
| |class, intent(out)
Status|UNCONFIRMED |NEW
--- Comment #1 from anlauf at gcc dot gnu.org ---
Confirmed as a regression. 12-branch works here, current 13-branch fails.
Replacing class by type also avoids the ICE.
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug fortran/115070] [13/14/15 Regression] ICE using IEEE_ARITHMETIC in a derived type method with class, intent(out)
2024-05-13 14:23 [Bug fortran/115070] New: ICE using IEEE_ARITHMETIC in a derived type method with intent(out) statement bardeau at iram dot fr
2024-05-13 17:09 ` [Bug fortran/115070] [13/14/15 Regression] ICE using IEEE_ARITHMETIC in a derived type method with class, intent(out) anlauf at gcc dot gnu.org
@ 2024-05-13 17:24 ` anlauf at gcc dot gnu.org
2024-05-15 6:31 ` pault at gcc dot gnu.org
` (6 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: anlauf at gcc dot gnu.org @ 2024-05-13 17:24 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115070
--- Comment #2 from anlauf at gcc dot gnu.org ---
Replacing the scalar argument 'obs' by something with rank > 0 avoids the ICE,
but then assumed-rank is not accepted with intent(out). Another bug...
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug fortran/115070] [13/14/15 Regression] ICE using IEEE_ARITHMETIC in a derived type method with class, intent(out)
2024-05-13 14:23 [Bug fortran/115070] New: ICE using IEEE_ARITHMETIC in a derived type method with intent(out) statement bardeau at iram dot fr
2024-05-13 17:09 ` [Bug fortran/115070] [13/14/15 Regression] ICE using IEEE_ARITHMETIC in a derived type method with class, intent(out) anlauf at gcc dot gnu.org
2024-05-13 17:24 ` anlauf at gcc dot gnu.org
@ 2024-05-15 6:31 ` pault at gcc dot gnu.org
2024-05-16 10:00 ` bardeau at iram dot fr
` (5 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: pault at gcc dot gnu.org @ 2024-05-15 6:31 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115070
Paul Thomas <pault at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |fxcoudert at gmail dot com,
| |pault at gcc dot gnu.org
--- Comment #3 from Paul Thomas <pault at gcc dot gnu.org> ---
(In reply to anlauf from comment #2)
> Replacing the scalar argument 'obs' by something with rank > 0 avoids the
> ICE,
> but then assumed-rank is not accepted with intent(out). Another bug...
The tree output with 12-branch is:
__attribute__((fn spec (". r w ")))
void __copy_my_mod_My_type (struct my_type & restrict src, struct my_type &
restrict dst)
{
*dst = *src;
}
__attribute__((fn spec (". w ")))
void my_sub (struct __class_my_mod_My_type_t & restrict obs)
{
c_char fpstate.0[33];
try
{
_gfortran_ieee_procedure_entry ((void *) &fpstate.0);
if (obs->_vptr->_final != 0B)
{
{
struct array00_my_type desc.1;
desc.1.dtype = {.elem_len=4, .rank=0, .type=5};
desc.1.data = (void * restrict) obs->_data;
desc.1.span = (integer(kind=8)) desc.1.dtype.elem_len;
obs->_vptr->_final (&desc.1, obs->_vptr->_size, 0);
}
}
(void) __builtin_memcpy ((void *) obs->_data, (void *)
obs->_vptr->_def_init, (unsigned long) obs->_vptr->_size);
}
finally
{
_gfortran_ieee_procedure_exit ((void *) &fpstate.0);
}
}
13- through 15-branches lack the default copy of the default initializer. This
disappeared with the fix for pr112407 and is required by the standard if the
derived type has no default initializer. This suggests a workaround, which
indeed "works":
type my_type
integer :: a = 0
end type my_type
I cannot see anything in the ieee procedures that would cause this but then I
know zip-all about ieee.
Putting Francois-Xavier in copy in the hope that he can shed some light.
Cheers
Paul
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug fortran/115070] [13/14/15 Regression] ICE using IEEE_ARITHMETIC in a derived type method with class, intent(out)
2024-05-13 14:23 [Bug fortran/115070] New: ICE using IEEE_ARITHMETIC in a derived type method with intent(out) statement bardeau at iram dot fr
` (2 preceding siblings ...)
2024-05-15 6:31 ` pault at gcc dot gnu.org
@ 2024-05-16 10:00 ` bardeau at iram dot fr
2024-05-16 10:17 ` fxcoudert at gcc dot gnu.org
` (4 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: bardeau at iram dot fr @ 2024-05-16 10:00 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115070
--- Comment #4 from Sebastien Bardeau <bardeau at iram dot fr> ---
Thanks for the hints. It seems to me that an intent(out) class without
component initialization values is probably out of the standard (unpredictable
results). So on my side the work-around I choose is to provide an
initialization value.
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug fortran/115070] [13/14/15 Regression] ICE using IEEE_ARITHMETIC in a derived type method with class, intent(out)
2024-05-13 14:23 [Bug fortran/115070] New: ICE using IEEE_ARITHMETIC in a derived type method with intent(out) statement bardeau at iram dot fr
` (3 preceding siblings ...)
2024-05-16 10:00 ` bardeau at iram dot fr
@ 2024-05-16 10:17 ` fxcoudert at gcc dot gnu.org
2024-05-16 10:59 ` fxcoudert at gcc dot gnu.org
` (3 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: fxcoudert at gcc dot gnu.org @ 2024-05-16 10:17 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115070
Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |fxcoudert at gcc dot gnu.org
--- Comment #5 from Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> ---
The only thing IEEE_ARITHMETIC does here is call _gfortran_ieee_procedure_entry
/ _gfortran_ieee_procedure_exit to save and restore the floating-point state.
The middle-end code that errors out is this:
/* ??? If this is a local variable, and it has not been seen in any
outer BIND_EXPR, then it's probably the result of a duplicate
declaration, for which we've already issued an error. It would
be really nice if the front end wouldn't leak these at all.
Currently the only known culprit is C++ destructors, as seen
in g++.old-deja/g++.jason/binding.C.
Another possible culpit are size expressions for variably modified
types which are lost in the FE or not gimplified correctly. */
if (VAR_P (decl)
&& !DECL_SEEN_IN_BIND_EXPR_P (decl)
&& !TREE_STATIC (decl) && !DECL_EXTERNAL (decl)
&& decl_function_context (decl) == current_function_decl)
{
gcc_assert (seen_error ());
return GS_ERROR;
}
I don't have a debug build available right now, so I don't know which variable
is causing the issue or why. But it seems like a very weird interplay between
IEEE and DT (which are normally completely orthogonal), so maybe we're just
catching it "by chance" and the bug is preexisting (but silent).
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug fortran/115070] [13/14/15 Regression] ICE using IEEE_ARITHMETIC in a derived type method with class, intent(out)
2024-05-13 14:23 [Bug fortran/115070] New: ICE using IEEE_ARITHMETIC in a derived type method with intent(out) statement bardeau at iram dot fr
` (4 preceding siblings ...)
2024-05-16 10:17 ` fxcoudert at gcc dot gnu.org
@ 2024-05-16 10:59 ` fxcoudert at gcc dot gnu.org
2024-05-17 14:32 ` pault at gcc dot gnu.org
` (2 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: fxcoudert at gcc dot gnu.org @ 2024-05-16 10:59 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115070
--- Comment #6 from Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> ---
So the var_decl in question is fpstate.0:
<var_decl 0x1034e1200 fpstate.0
type <array_type 0x1036c4b28
type <integer_type 0x1035003f0 c_char public unsigned QI
size <integer_cst 0x1034bce70 constant 8>
unit-size <integer_cst 0x1034bce88 constant 1>
align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x1035003f0 precision:8 min <integer_cst 0x1034bced0 0> max <integer_cst
0x1034bceb8 255>
pointer_to_this <pointer_type 0x103503bb8>>
BLK
size <integer_cst 0x103546988 constant 264>
unit-size <integer_cst 0x103546aa8 constant 33>
align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x1036c4b28
domain <integer_type 0x1036c4a80 type <integer_type 0x1035007e0>
DI
size <integer_cst 0x1034bcd80 constant 64>
unit-size <integer_cst 0x1034bcd98 constant 8>
align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x1036c4a80 precision:64 min <integer_cst 0x1034bd050 0> max <integer_cst
0x103546a60 32>>
pointer_to_this <pointer_type 0x1036c4bd0>>
addressable used ignored BLK s.f90:10:17 size <integer_cst 0x103546988 264>
unit-size <integer_cst 0x103546aa8 33>
align:8 warn_if_not_align:0 context <function_decl 0x1036c8100 my_sub>>
And if I look at the tree dump, it seems the variable is indeed not created
correctly:
__attribute__((fn spec (". w ")))
void my_sub (struct __class_my_mod_My_type_t & restrict obs)
{
try
{
_gfortran_ieee_procedure_entry ((void *) &fpstate.0);
see the missing declaration for fpstate.0. But it is created by
gfc_create_var(), like so many other local variables in the front-end, so I
have no idea why it's disappearing.
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug fortran/115070] [13/14/15 Regression] ICE using IEEE_ARITHMETIC in a derived type method with class, intent(out)
2024-05-13 14:23 [Bug fortran/115070] New: ICE using IEEE_ARITHMETIC in a derived type method with intent(out) statement bardeau at iram dot fr
` (5 preceding siblings ...)
2024-05-16 10:59 ` fxcoudert at gcc dot gnu.org
@ 2024-05-17 14:32 ` pault at gcc dot gnu.org
2024-05-21 9:20 ` jakub at gcc dot gnu.org
2024-05-21 12:03 ` pault at gcc dot gnu.org
8 siblings, 0 replies; 10+ messages in thread
From: pault at gcc dot gnu.org @ 2024-05-17 14:32 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115070
--- Comment #7 from Paul Thomas <pault at gcc dot gnu.org> ---
(In reply to Francois-Xavier Coudert from comment #6)
> So the var_decl in question is fpstate.0:
>
> <var_decl 0x1034e1200 fpstate.0
> type <array_type 0x1036c4b28
> type <integer_type 0x1035003f0 c_char public unsigned QI
> size <integer_cst 0x1034bce70 constant 8>
> unit-size <integer_cst 0x1034bce88 constant 1>
> align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
> 0x1035003f0 precision:8 min <integer_cst 0x1034bced0 0> max <integer_cst
> 0x1034bceb8 255>
> pointer_to_this <pointer_type 0x103503bb8>>
> BLK
> size <integer_cst 0x103546988 constant 264>
> unit-size <integer_cst 0x103546aa8 constant 33>
> align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
> 0x1036c4b28
> domain <integer_type 0x1036c4a80 type <integer_type 0x1035007e0>
> DI
> size <integer_cst 0x1034bcd80 constant 64>
> unit-size <integer_cst 0x1034bcd98 constant 8>
> align:64 warn_if_not_align:0 symtab:0 alias-set -1
> canonical-type 0x1036c4a80 precision:64 min <integer_cst 0x1034bd050 0> max
> <integer_cst 0x103546a60 32>>
> pointer_to_this <pointer_type 0x1036c4bd0>>
> addressable used ignored BLK s.f90:10:17 size <integer_cst 0x103546988
> 264> unit-size <integer_cst 0x103546aa8 33>
> align:8 warn_if_not_align:0 context <function_decl 0x1036c8100 my_sub>>
>
> And if I look at the tree dump, it seems the variable is indeed not created
> correctly:
>
> __attribute__((fn spec (". w ")))
> void my_sub (struct __class_my_mod_My_type_t & restrict obs)
> {
> try
> {
> _gfortran_ieee_procedure_entry ((void *) &fpstate.0);
>
> see the missing declaration for fpstate.0. But it is created by
> gfc_create_var(), like so many other local variables in the front-end, so I
> have no idea why it's disappearing.
Thanks for both the comments, Francois-Xavier. I will look to see if, somehow,
the way in which the finalization is stacked on the function tree is somehow
overwriting the ieee entry call and or the decl of fpstate.0.
Paul
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug fortran/115070] [13/14/15 Regression] ICE using IEEE_ARITHMETIC in a derived type method with class, intent(out)
2024-05-13 14:23 [Bug fortran/115070] New: ICE using IEEE_ARITHMETIC in a derived type method with intent(out) statement bardeau at iram dot fr
` (6 preceding siblings ...)
2024-05-17 14:32 ` pault at gcc dot gnu.org
@ 2024-05-21 9:20 ` jakub at gcc dot gnu.org
2024-05-21 12:03 ` pault at gcc dot gnu.org
8 siblings, 0 replies; 10+ messages in thread
From: jakub at gcc dot gnu.org @ 2024-05-21 9:20 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115070
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|13.3 |13.4
--- Comment #8 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 13.3 is being released, retargeting bugs to GCC 13.4.
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug fortran/115070] [13/14/15 Regression] ICE using IEEE_ARITHMETIC in a derived type method with class, intent(out)
2024-05-13 14:23 [Bug fortran/115070] New: ICE using IEEE_ARITHMETIC in a derived type method with intent(out) statement bardeau at iram dot fr
` (7 preceding siblings ...)
2024-05-21 9:20 ` jakub at gcc dot gnu.org
@ 2024-05-21 12:03 ` pault at gcc dot gnu.org
8 siblings, 0 replies; 10+ messages in thread
From: pault at gcc dot gnu.org @ 2024-05-21 12:03 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115070
Paul Thomas <pault at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org
--- Comment #9 from Paul Thomas <pault at gcc dot gnu.org> ---
Created attachment 58263
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58263&action=edit
Patch that fixes this PR
Somehow, when a null is returned from the call to gfc_trans_class_init_assign,
the messing around with blocks at the end of gfc_generate_function_code loses
the declaration. I tried giving the ieee calls their own block and merging it
to the top of 'body'. That fixed this PR but broke a number of ieee tests in
the testsuite.
This fix is not very elegant but it does work and even regtests OK.
I am continuing to work on it before submitting this patch.
Paul
^ permalink raw reply [flat|nested] 10+ messages in thread