From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 690673858D35; Wed, 17 Apr 2024 01:50:24 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 690673858D35 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1713318624; bh=4rrbkmW12LKbVDp5etlmNGrg/LSiIuoxtYAhqpf9sJ4=; h=From:To:Subject:Date:In-Reply-To:References:From; b=izmnPYeuCD2AjGMIB6LpzYVwaBW5PvM0G2K5O2rfxIj0r1rAERGU3KKCeMIeyIy6k fx+Fh3WkE6zGvJu3v2/QyVpPyByGG51EevCTwGmJBpxVpVZ+ZbK5IiHCoa0V5s5H4t uEU5OcaPfwLCLNv6RXALw3paoEQlFke+57dI+yIw= From: "lin1.hu at intel dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug middle-end/114700] middle-end optimization generates causes -fsanitize=undefined not to happen in some cases Date: Wed, 17 Apr 2024 01:50:23 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: middle-end X-Bugzilla-Version: unknown X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: lin1.hu at intel dot com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: attachments.created Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D114700 --- Comment #20 from Hu Lin --- Created attachment 57967 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=3D57967&action=3Dedit A new version When I tested this patch, I met another question. g++.dg/ubsan/vla-1.C will raise a ICE without (TREE_TYPE (@2) =3D=3D ssizetype at match.pd:3497. In the original step, GCC generates the intermediate language using variabl= es declared in other blocks. Like _5 =3D _1 + 1, this led to the ICE in 022t.s= sa. I don't know if it is a bug, and I didn't find a test to raise this ICE on tr= unk. So I add a condition to avoid this optimization in this case, any other comments on my newly added conditions? I paste some information that I think is important. vla-1.C.005t.original: The original line 12 is=20 __builtin___ubsan_handle_vla_bound_not_positive (&*.Lubsan_data0, (unsigned long) ((ssizetype) SAVE_EXPR )); The current is __builtin___ubsan_handle_vla_bound_not_positive (&*.Lubsan_data0, (unsigned long) (((ssizetype) SAVE_EXPR - 1) + 1)); vla-1.C.006t.gimple original: 22 i.0 =3D i; 23 if (i.0 <=3D 0) goto ; else goto ; 24 : 25 _1 =3D (unsigned long) i.0; 26 __builtin___ubsan_handle_vla_bound_not_positive (&*.Lubsan_data0, _1); 27 goto ; 28 : 29 : 30 _2 =3D (ssizetype) i.0; 31 _3 =3D _2 - 1; current: 22 i.0 =3D i; 23 if (i.0 <=3D 0) goto ; else goto ; 24 : 25 _1 =3D (ssizetype) i.0; 26 _2 =3D _1 - 1; 27 _3 =3D _2 + 1; 28 _4 =3D (unsigned long) _3; 29 __builtin___ubsan_handle_vla_bound_not_positive (&*.Lubsan_data0, _4); 30 goto ; 31 : 32 : 33 _5 =3D _1 - 1; vla-1.C.015t.cfg original: 37 int i.0; 38 39 : 40 saved_stack.5 =3D __builtin_stack_save (); 41 i.0 =3D i; 42 if (i.0 <=3D 0) 43 goto ; [INV] 44 else 45 goto ; [INV] 46 47 : 48 _1 =3D (unsigned long) i.0; 49 __builtin___ubsan_handle_vla_bound_not_positive (&*.Lubsan_data0, _1); 50 51 : 52 _2 =3D (ssizetype) i.0; 53 _3 =3D _2 - 1; current: 37 int i.0; 38 39 : 40 saved_stack.5 =3D __builtin_stack_save (); 41 i.0 =3D i; 42 if (i.0 <=3D 0) 43 goto ; [INV] 44 else 45 goto ; [INV] 46 47 : 48 _1 =3D (ssizetype) i.0; 49 _2 =3D _1 - 1; 50 _3 =3D _2 + 1; 51 _4 =3D (unsigned long) _3; 52 __builtin___ubsan_handle_vla_bound_not_positive (&*.Lubsan_data0, _4); 53 54 : 55 _5 =3D _1 - 1; 56 _6 =3D (sizetype) _5; 57 D.3273 =3D _6;=