From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from server.nextmovesoftware.com (server.nextmovesoftware.com [69.48.154.134]) by sourceware.org (Postfix) with ESMTPS id B1D693857C4F for ; Tue, 30 Apr 2024 08:23:08 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org B1D693857C4F Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=nextmovesoftware.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=nextmovesoftware.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org B1D693857C4F Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=69.48.154.134 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1714465390; cv=none; b=PUuQDlL+EfXKSiqGHTawBfW6+7NSHMXcQUhGP9RSwLESH9wZ9Ca7z8JW14bZekHA2Pp4JjMZLwTYUPtDJvu1vvMpPx6b4rrHNERWGCaQ5LIFtKbaktklg9Iq/BpWNeBrTlfuEoAz6XSANTURm6lYIVV5saaZiS3zttj/tg4NrqE= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1714465390; c=relaxed/simple; bh=Tor14Sb99wszy5haoolGFR6mPtuzvYQH16BEmcR7llA=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=geECoiudebMph3vbREdO7FiJT1HIOT8cPnbuKa1X0KzZiClaEvuc/dFYw91jKHscqWrng34puljaO+ErwwAsjv+IeQDGYtReHFuxQZ8h/1p5+qhwxG2upB0bVX1ugYTrR3HWfM3MRO9TLuA+M0dbY7ehMnHOvVzz0RkxHe2N4qc= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=nextmovesoftware.com; s=default; h=Content-Transfer-Encoding:Content-Type: MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:Cc:To:From:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=lxqPWvPh5LTZBrLt6l6ENRSb1TcUIQ/j5uDso5qpbjg=; b=KbgfSwdSIL/RbRy/2F4j2SHvr5 YKj7R+qQv8ahhbdJcOkz2onOcckBQd7xEs7DyrpDIbJ64fNP4Q0FcWHVCiYQZJxb38JrqiKUm/dTV 1olLXatIzsCG1MJ3tRSPo5ZGAWevHv66WpPQew/jOPH8mjy1hqRInr9TMlhHf3TdXApDGBoss6rMC RW2wXiQKuiw1prpXiHbQYASOh4jmN4sJKSMoYU7PFoTEgRo1oajTRunelpRyLM1wDjZ0lwQ49bk3S N1g7CdOvCBxR6RLW6OGrj1arhErO5EpZeZ/NsVrnNWdXgV0ZJ6jSfTmlcUDbwh3TwueptxbGJM+F4 dA3EiQzQ==; Received: from [168.86.199.132] (port=57912 helo=Dell) by server.nextmovesoftware.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96.2) (envelope-from ) id 1s1ilY-00Beju-0D; Tue, 30 Apr 2024 04:23:08 -0400 From: "Roger Sayle" To: "'Richard Biener'" Cc: References: <010401da9a89$d5a33150$80e993f0$@nextmovesoftware.com> In-Reply-To: Subject: RE: [C PATCH] PR c/109618: ICE-after-error from error_mark_node. Date: Tue, 30 Apr 2024 09:23:06 +0100 Message-ID: <003d01da9ad7$a1978980$e4c69c80$@nextmovesoftware.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQIXEg8nyKdlMXL+BlQmQGSL0vaxvAEXVQfTsP7FOfA= Content-Language: en-gb X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.nextmovesoftware.com X-AntiAbuse: Original Domain - gcc.gnu.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nextmovesoftware.com X-Get-Message-Sender-Via: server.nextmovesoftware.com: authenticated_id: roger@nextmovesoftware.com X-Authenticated-Sender: server.nextmovesoftware.com: roger@nextmovesoftware.com X-Source: X-Source-Args: X-Source-Dir: X-Spam-Status: No, score=-6.3 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,SPF_PASS,TXREP,WEIRD_PORT autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Hi Richard, Thanks for looking into this. It=E2=80=99s not the call to size_binop_loc (for CEIL_DIV_EXPR) that's = problematic, but the call to fold_convert_loc (loc, size_type_node, value) on line 4009 of = c-common.cc. At this point, value is (NOP_EXPR:sizetype (VAR_DECL:error_mark_node)). Ultimately, it's the code in match.pd /* Handle cases of two conversions = in a row. */ with the problematic line being (match.pd:4748): unsigned int inside_prec =3D element_precision (inside_type);=20 Here inside_type is error_mark_node, and so tree type checking in = element_precision throws an internal_error. There doesn=E2=80=99t seem to be a good way to fix this in = element_precision, and it's complicated to reorganize the logic in match.pd's "with clause" inside = the (ocvt (icvt@1 @0)), but perhaps a (ocvt (icvt:non_error_type@1 @0))? The last place/opportunity the front-end could sanitize this operand = before passing the dubious tree to the middle-end is c_sizeof_or_alignof_type = (which alas doesn't appear in the backtrace due to inlining). #5 0x000000000227b0e9 in internal_error ( gmsgid=3Dgmsgid@entry=3D0x249c7b8 "tree check: expected class %qs, = have %qs (%s) in %s, at %s:%d") at ../../gcc/gcc/diagnostic.cc:2232 #6 0x000000000081e32a in tree_class_check_failed = (node=3D0x7ffff6c1ef30, cl=3Dcl@entry=3Dtcc_type, file=3Dfile@entry=3D0x2495f3f = "../../gcc/gcc/tree.cc", line=3Dline@entry=3D6795, function=3Dfunction@entry=3D0x24961fe = "element_precision") at ../../gcc/gcc/tree.cc:9005 #7 0x000000000081ef4c in tree_class_check (__t=3D, = __class=3Dtcc_type, __f=3D0x2495f3f "../../gcc/gcc/tree.cc", __l=3D6795, __g=3D0x24961fe "element_precision") at ../../gcc/gcc/tree.h:4067 #8 element_precision (type=3D, = type@entry=3D0x7ffff6c1ef30) at ../../gcc/gcc/tree.cc:6795 #9 0x00000000017f66a4 in generic_simplify_CONVERT_EXPR (loc=3D201632, code=3D, type=3D0x7ffff6c3e7e0, _p0=3D0x7ffff6dc95c0) at generic-match-6.cc:3386 #10 0x0000000000c1b18c in fold_unary_loc (loc=3D201632, code=3DNOP_EXPR, type=3D0x7ffff6c3e7e0, op0=3D0x7ffff6dc95c0) at = ../../gcc/gcc/fold-const.cc:9523 #11 0x0000000000c1d94a in fold_build1_loc (loc=3D201632, = code=3DNOP_EXPR, type=3D0x7ffff6c3e7e0, op0=3D0x7ffff6dc95c0) at = ../../gcc/gcc/fold-const.cc:14165 #12 0x000000000094068c in c_expr_sizeof_expr (loc=3Dloc@entry=3D201632, = expr=3D...) at ../../gcc/gcc/tree.h:3771 #13 0x000000000097f06c in c_parser_sizeof_expression = (parser=3D) at ../../gcc/gcc/c/c-parser.cc:9932 I hope this explains what's happening. The size_binop_loc call is a bit = of a red herring that returns the same tree it is given (as TYPE_PRECISION = (char_type_node) =3D=3D 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 = 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 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 > Cc: gcc-patches@gcc.gnu.org > Subject: Re: [C PATCH] PR c/109618: ICE-after-error from = error_mark_node. >=20 > On Tue, Apr 30, 2024 at 1:06=E2=80=AFAM 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 care has to be taken by the front-end to > > avoid passing these malformed trees into the middle-end during error > > recovery. In this case, a var_decl with a poisoned type appears = within > > a sizeof() expression (wrapped in NOP_EXPR) which causes problems. > > > > This revision of the patch tests seen_error() to avoid tree = traversal > > (STRIP_NOPs) in the most common case that an error hasn't occurred. > > Both this version (and an earlier revision that didn't test > > seen_error) have survived bootstrap and regression testing on = x86_64-pc-linux- > gnu. > > As a consolation, this code also contains a minor performance > > improvement, by avoiding trying to create (and folding away) a > > CEIL_DIV_EXPR in the common case that "char" is a single-byte. The > > current code relies on the middle-end's tree folding to recognize = that > > CEIL_DIV_EXPR of integer_one_node is a no-op, that can be optimized = away. > > > > Ok for mainline? >=20 > Where does it end up ICEing? I see size_binop_loc guards against > error_mark_node operands already, maybe it should use error_operand_p > instead? >=20 > > > > 2024-04-30 Roger Sayle > > > > gcc/c-family/ChangeLog > > PR c/109618 > > * c-common.cc (c_sizeof_or_alignof_type): If seen_error() = check > > whether value is (a VAR_DECL) of type error_mark_node, or a > > NOP_EXPR thereof. Avoid folding CEIL_DIV_EXPR for the = common > > case where char_type is a single byte. > > > > gcc/testsuite/ChangeLog > > PR c/109618 > > * gcc.dg/pr109618.c: New test case. > > > > > > Thanks in advance, > > Roger > > -- > >