[Bug fortran/115070] [13/14/15 Regression] ICE using IEEE_ARITHMETIC in a derived type method with class, intent(out)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115070 Paul Thomas changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org --- Comment #9 from Paul Thomas --- Created attachment 58263 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58263=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
[Bug fortran/115070] [13/14/15 Regression] ICE using IEEE_ARITHMETIC in a derived type method with class, intent(out)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115070 Jakub Jelinek changed: What|Removed |Added Target Milestone|13.3|13.4 --- Comment #8 from Jakub Jelinek --- GCC 13.3 is being released, retargeting bugs to GCC 13.4.
[Bug fortran/115070] [13/14/15 Regression] ICE using IEEE_ARITHMETIC in a derived type method with class, intent(out)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115070
--- Comment #7 from Paul Thomas ---
(In reply to Francois-Xavier Coudert from comment #6)
> So the var_decl in question is fpstate.0:
>
> type type size
> unit-size
> align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
> 0x1035003f0 precision:8 min max 0x1034bceb8 255>
> pointer_to_this >
> BLK
> size
> unit-size
> align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
> 0x1036c4b28
> domain
> DI
> size
> unit-size
> align:64 warn_if_not_align:0 symtab:0 alias-set -1
> canonical-type 0x1036c4a80 precision:64 min max
> >
> pointer_to_this >
> addressable used ignored BLK s.f90:10:17 size 264> unit-size
> align:8 warn_if_not_align:0 context >
>
> 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 *) );
>
> 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
[Bug fortran/115070] [13/14/15 Regression] ICE using IEEE_ARITHMETIC in a derived type method with class, intent(out)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115070
--- Comment #6 from Francois-Xavier Coudert ---
So the var_decl in question is fpstate.0:
unit-size
align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x1035003f0 precision:8 min max
pointer_to_this >
BLK
size
unit-size
align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x1036c4b28
domain
DI
size
unit-size
align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x1036c4a80 precision:64 min max >
pointer_to_this >
addressable used ignored BLK s.f90:10:17 size
unit-size
align:8 warn_if_not_align:0 context >
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 *) );
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.
[Bug fortran/115070] [13/14/15 Regression] ICE using IEEE_ARITHMETIC in a derived type method with class, intent(out)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115070
Francois-Xavier Coudert changed:
What|Removed |Added
CC||fxcoudert at gcc dot gnu.org
--- Comment #5 from Francois-Xavier Coudert ---
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).
[Bug fortran/115070] [13/14/15 Regression] ICE using IEEE_ARITHMETIC in a derived type method with class, intent(out)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115070 --- Comment #4 from Sebastien Bardeau --- 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.
[Bug fortran/115070] [13/14/15 Regression] ICE using IEEE_ARITHMETIC in a derived type method with class, intent(out)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115070
Paul Thomas changed:
What|Removed |Added
CC||fxcoudert at gmail dot com,
||pault at gcc dot gnu.org
--- Comment #3 from Paul Thomas ---
(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 *) );
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 (, 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 *) );
}
}
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
[Bug fortran/115070] [13/14/15 Regression] ICE using IEEE_ARITHMETIC in a derived type method with class, intent(out)
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...
[Bug fortran/115070] [13/14/15 Regression] ICE using IEEE_ARITHMETIC in a derived type method with class, intent(out)
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.
