[Bug c/111811] [14 Regression] ICE with vector float bitfield after error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111811 Richard Biener changed: What|Removed |Added Priority|P3 |P4
[Bug c/111811] [14 Regression] ICE with vector float bitfield after error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111811
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
Last reconfirmed||2023-11-12
Summary|ICE with vector float |[14 Regression] ICE with
|bitfield after error|vector float bitfield after
||error
CC||pinskia at gcc dot gnu.org,
||rguenth at gcc dot gnu.org
Target Milestone|--- |14.0
--- Comment #1 from Andrew Pinski ---
Confirmed.
if (TREE_CODE (field) == FIELD_DECL
&& DECL_INITIAL (field)
&& TREE_TYPE (field) != error_mark_node)
{
unsigned HOST_WIDE_INT width
= tree_to_uhwi (DECL_INITIAL (field));
tree type = TREE_TYPE (field);
if (width != TYPE_PRECISION (type)) <--- Crash
{
Obvious introduced by the TYPE_PRECISION change to ICE on vector types:
r14-2150-gfe48f2651334bc
[Bug c/111811] [14 Regression] ICE with vector float bitfield after error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111811
Andrew Pinski changed:
What|Removed |Added
Keywords||accepts-invalid
--- Comment #2 from Andrew Pinski ---
But we should also be rejecting:
```
struct A {
__attribute__((__vector_size__(4))) int d : 1;
};
struct A b = {0};
```
Which we currently accepts before and ICE now.
Note for the float case, we could in theory change:
```
/* Detect invalid bit-field type. */
if (TREE_CODE (*type) != INTEGER_TYPE
&& TREE_CODE (*type) != BOOLEAN_TYPE
&& TREE_CODE (*type) != ENUMERAL_TYPE
&& TREE_CODE (*type) != BITINT_TYPE)
{
error_at (loc, "bit-field %qs has invalid type", name);
*type = unsigned_type_node;
}
```
to use error_mark_node instead of unsigned_type_node here and that would fix
the ICE for the original testcase but not the above testcase.
[Bug c/111811] [14 Regression] ICE with vector float bitfield after error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111811 Richard Biener changed: What|Removed |Added CC||jsm28 at gcc dot gnu.org --- Comment #3 from Richard Biener --- I agree, this shouldn't be a valid bit-field type. We apply the vector_size attribute before parsing/applying :1. There must be code to reject float : 1, not sure where that is.
[Bug c/111811] [14 Regression] ICE with vector float bitfield after error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111811
--- Comment #4 from joseph at codesourcery dot com ---
The checks are in check_bitfield_type_and_width. I expect the attribute -
in this position a declaration attribute - gets applied after that (and
while applying it results in a change to the type, and thus in the
declaration being laid out again, this check doesn't get repeated).
In this case, the existing check is correct but not sufficient. In
another case the check is arguably too early:
struct s { int __attribute__ ((__mode__ (DI))) x : 50; };
Considering int __attribute__ ((__mode__ (DI))) as a DImode integer type,
that bit-field width is valid - but it's rejected because the check is
carried out on int, before the attribute gets applied. Getting that case
to work might require extracting early those declaration attributes that
actually affect the type, so they can be applied to the type before the
declaration gets constructed and such checks are carried out.
[Bug c/111811] [14 Regression] ICE with vector float bitfield after error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111811
--- Comment #5 from rguenther at suse dot de ---
On Mon, 13 Nov 2023, joseph at codesourcery dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111811
>
> --- Comment #4 from joseph at codesourcery dot com dot com> ---
> The checks are in check_bitfield_type_and_width. I expect the attribute -
> in this position a declaration attribute - gets applied after that (and
> while applying it results in a change to the type, and thus in the
> declaration being laid out again, this check doesn't get repeated).
>
> In this case, the existing check is correct but not sufficient. In
> another case the check is arguably too early:
>
> struct s { int __attribute__ ((__mode__ (DI))) x : 50; };
>
> Considering int __attribute__ ((__mode__ (DI))) as a DImode integer type,
> that bit-field width is valid - but it's rejected because the check is
> carried out on int, before the attribute gets applied. Getting that case
> to work might require extracting early those declaration attributes that
> actually affect the type, so they can be applied to the type before the
> declaration gets constructed and such checks are carried out.
Ah, and when applying the vector_size attribute the FIELD_DECL hasn't been
updated to indicate we identified it as bitfield (so we could reject
the attribute) ...
I'll leave this to frontend folks to sort out.
