of a red herring that returns the same tree it is given (as
> > > TYPE_PRECISION (char_type_node) == BITS_PER_UNIT), so it's the
> > > "TYPE_SIZE_UNIT (type)" which needs to be checked for the embedded
> > VAR_DECL with a TREE_TYPE of error_mark_node.
> > >
; > TYPE_PRECISION (char_type_node) == BITS_PER_UNIT), so it's the
> > "TYPE_SIZE_UNIT (type)" which needs to be checked for the embedded
> VAR_DECL with a TREE_TYPE of error_mark_node.
> >
> > As Andrew Pinski writes in comment #3, this one is trickier than av
ed
> for the embedded VAR_DECL with a TREE_TYPE of error_mark_node.
>
> As Andrew Pinski writes in comment #3, this one is trickier than average.
>
> A more comprehensive fix might be to write deep_error_operand_p which does
> more of a tree traversal checking error_operand_p within the unary
which does
more of a tree traversal checking error_operand_p within the unary and binary
operators of an expression tree.
Please let me know what you think/recommend.
Best regards,
Roger
--
> -Original Message-
> From: Richard Biener
> Sent: 30 April 2024 08:38
> To: Roger Sayle
>
On Tue, Apr 30, 2024 at 1:06 AM Roger Sayle wrote:
>
>
> This patch solves another ICE-after-error problem in the C family
> front-ends. Upon a conflicting type redeclaration, the ambiguous
> type is poisoned with an error_mark_node to indicate to the middle-end
> that the type is suspect, but ca
This patch solves another ICE-after-error problem in the C family
front-ends. Upon a conflicting type redeclaration, the ambiguous
type is poisoned with an error_mark_node to indicate to the middle-end
that the type is suspect, but care has to be taken by the front-end to
avoid passing these malf
