Message ID | 18ac74c8afb663aa0dc2503a571d0d17ebb2e759.camel@espressif.com |
---|---|
State | New |
Headers |
Return-Path: <gcc-patches-bounces+patchwork=sourceware.org@gcc.gnu.org> X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id AE9D93858C62 for <patchwork@sourceware.org>; Tue, 17 Jan 2023 15:36:21 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org AE9D93858C62 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1673969781; bh=I44UFgy3fxjOcaIkucdERU/HLhK6gm0ZHxaOIT39fcU=; h=To:CC:Subject:Date:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:From:Reply-To:From; b=NRezV8w8mTzNzBO/VpsPvj1X2zB2LUcjW+G6GtB1fwnHp9BASecTOuKQ3RrWW9bKE KOrnPZXSUUyNnHr4UWk/sqXhEWJAcz0yeVI8JZcgoSTs2LQDSzVVlAaEtX8D3vpS5e qiyZBQwDAvOPMbWLUvBQ85ZADXumjYtw88eS2y8E= X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from APC01-SG2-obe.outbound.protection.outlook.com (mail-sgaapc01on2127.outbound.protection.outlook.com [40.107.215.127]) by sourceware.org (Postfix) with ESMTPS id B352E3858C00 for <gcc-patches@gcc.gnu.org>; Tue, 17 Jan 2023 15:35:52 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org B352E3858C00 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=JkI0dbywe1aJTiG/EIFjy0bv3pA3AVlqQoZkXYbJqlIm5tOyByC0qmkCWfZBKwzznDS37AiwwaTh02aER7XNLdqfKo5G28hT7atgyztZHjqVEXoSvBVw7yIFXTvM1BV+Xhw4HyRVtC80VQvqJqaiaVIk+su56LtVG+3N1PIGcZ/65UheCMuFcC/KrvN9R78BKpgb+o/hWZqaQ/XEldYib9A2Rryh33j7hyVo4tEZW6N3EOsPAygCxcrpJZpf38HHRZQdQDWu3eqhDApwvsRAe+wYzxp3xbEIsaEz7KrzrEmYRvgJlHvJ6HyrKQOd3YG+FtvkMUEq1NW3PUvSwF49xg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=I44UFgy3fxjOcaIkucdERU/HLhK6gm0ZHxaOIT39fcU=; b=X+uBG4AX89cHSFK8ks2XoojFo5X8qlbyCfELMzptD17XPpMFqOij+pVnvMb223qlGN0hPwKOe7ldjSmybQtlWXBnpK0zpbqFYTconZqPO2jskZPJXqbl14gswR+bZTxt94GuVT8wSMRORWUg42AnG6oeO1rberHxJ4i6myXyUNoKLec/oapJHNqmq0VkhYkVYnxNohlPqC1m7AnbU3V8xQZ/7+Az9GgwM774zx7211uIGqsNVMuBey0LXI9LLg7dNSf5CY9IooTPlA/TvwV5DA3k1FbWA/A62NKaTlEehNRGslRTG55pkB3U1bGrfa7MpApZgfVgmDcqYCTWPzzBkQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=espressif.com; dmarc=pass action=none header.from=espressif.com; dkim=pass header.d=espressif.com; arc=none Received: from TYZPR04MB5736.apcprd04.prod.outlook.com (2603:1096:400:1fa::7) by PUZPR04MB6463.apcprd04.prod.outlook.com (2603:1096:301:f9::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5986.23; Tue, 17 Jan 2023 15:35:45 +0000 Received: from TYZPR04MB5736.apcprd04.prod.outlook.com ([fe80::79e3:f2cb:464c:aed2]) by TYZPR04MB5736.apcprd04.prod.outlook.com ([fe80::79e3:f2cb:464c:aed2%3]) with mapi id 15.20.5986.023; Tue, 17 Jan 2023 15:35:45 +0000 To: "gcc-patches@gcc.gnu.org" <gcc-patches@gcc.gnu.org> CC: "Michael Xiao (XIAOXUFENG)" <xiaoxufeng@espressif.com>, Alexey Gerenkov <alexey.gerenkov@espressif.com>, Anton Maklakov <anton.maklakov@espressif.com>, "d@dcepelik.cz" <d@dcepelik.cz>, "hubicka@ucw.cz" <hubicka@ucw.cz>, Ivan Grokhotkov <ivan@espressif.com> Subject: [RFC] tree-optimization: fix optimize-out variables passed into func to alloc Thread-Topic: [RFC] tree-optimization: fix optimize-out variables passed into func to alloc Thread-Index: AQHZKoldxTk7Eo3Kq0OQrID1YmAQfg== Date: Tue, 17 Jan 2023 15:35:45 +0000 Message-ID: <18ac74c8afb663aa0dc2503a571d0d17ebb2e759.camel@espressif.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-ms-traffictypediagnostic: TYZPR04MB5736:EE_|PUZPR04MB6463:EE_ x-ms-office365-filtering-correlation-id: e357836b-4a5b-4aed-064e-08daf8a08000 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: vc3F0Yxz+cWbF2LPMZ0VGKQmKechyZ4nsdCHz7swVRczf0NA8ocPEdQFTLZ4L17DxEaOwSpZ9nK2n/lbUN8w7X/mQQOjwk5IWGg1cg5R0If9uPUNmkBL/GETtnSACWvZSHtlpO/BmolnP1K+4pTIKLSvlch1N/Vd3x8xJvZL4uLH0AKT1Pll4ky+zp/dvPVlEhsTOYzdFA+KMrWgrGggkkJQ8ASoSD9RZ63Ydj4oMWyOOdNAMHGTUOei91lCZTl7JE+FJNsgxBTRFl1C5fBl4HTOnmzKlUehgLXX7lDbJe7AiYL20gcr+sgeyxbiWygcVnAzxp+5VrkAuIUtww1g13fqN7KHWTOLW5jRi5xtZmCExsXON9PpE6eW2kwBZUGkEFNReSs6nAyakPvNYjjYBOiM66lvCfTW7pBpY1dfwR+203+o6Go/tgRVdy7TRrfLhIIkk822TLehya2cmqE31gsY1vVNpN70eGwUc1WAokh6CJWPPatdliUGEfueWJ+d3LcoevgVIG4zO4jYCgthgSDnBCHpjup+H8wx9SNBNHkVLxsZojxR77jOwnGfQ8Y0wKTdbxUNCHaAkIMO+GgPCKv3Q9auNGhPD7rukxAh2S2ouB+dpuf2oD16ePhMrxS5cvvk7wz5bV2Hb2Cki9LuHIAXUl7eglgE22/FTr/QI5tw7dmROE3BeiHUGWSqmG0Q x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:TYZPR04MB5736.apcprd04.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230022)(39850400004)(136003)(346002)(366004)(376002)(396003)(451199015)(76116006)(8676002)(4326008)(66946007)(66556008)(66476007)(66446008)(64756008)(86362001)(91956017)(2906002)(6506007)(107886003)(6486002)(26005)(478600001)(186003)(8936002)(6512007)(71200400001)(36756003)(54906003)(6916009)(38100700002)(122000001)(44832011)(2616005)(316002)(41300700001)(83380400001)(38070700005)(5660300002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?q?nRbPzzjIhUiqQilGZnWJVy2eN23t?= =?utf-8?q?YkhjASVWNrhYdU2GmHMmtqM9xfRTB5ETBbn4t+Ydlzf82oaF/3kbwHraKRXWTaheI?= =?utf-8?q?MNY7F/dyPNylLRwXivuQyHY4Au5EvUe0WXLDHwAGM4g4in9E/c/gA9Szw2Fwhf6X4?= =?utf-8?q?tz2mu5V+3DoWQxSXm0+uG/O/DW4nApDSe4OWxgiAP1KMH4Bzw0EfnFMBfazKMSdHB?= =?utf-8?q?RgM8H2rD7BfxVv5bhm25O9jLYd1GYtLQDewPIB8nq3QqmFdPB87Y9ssl8tBEVdUNo?= =?utf-8?q?RaG84O44LqgT0doegXLLsBZnzjayxHP32pslFXSb4PZWG5OjnR9t1AMasVDNUo1Ua?= =?utf-8?q?mZlTD993hZJu32p12iHaB5blEqo3DT1gvooIrPD6Qq+EhxglBBUtu1mTe56z0NqA/?= =?utf-8?q?00NN6VZlPUyLfBwe+Mh3/QxAxrDCTffUIYKs2Gtb0A6JUJc0c5istBIle5nmwT59x?= =?utf-8?q?GfZaSJ3Nz0k617v5xe2RXIrvIgT74HCQ+elVHhlxNagXQ8vRv8TXjwB66+4xaDbTd?= =?utf-8?q?dj0AVVhsT1sM8wAIRjM4SGoadyhiDIjYR4SQXSG+v9ioKU957LX1dUk7H8cROUURn?= =?utf-8?q?cr7PGNHI7hVw/hOx+Yaq6i3SngejXBME35W9aFQGHH10sRPMWCo8k5UrBMP+gOHcT?= =?utf-8?q?ztzLIajFrwre/b4EXEfo6wB5xYMJ/Np7fXnVvNtlM8MgHJAzWtDgGW/gAljNqmgKD?= =?utf-8?q?LSTNID0WorNBGe3GIM6BjtLtC5pO1siFd2bdh8wWSWyCMp7LSXJxd7kb4fkSU20xy?= =?utf-8?q?LrSIQw08cYfIJfaDRMN+kTaKJpNTSWo1JWjvhdAuVjCj3mMtON0+fWXQffLQNkuDP?= =?utf-8?q?bJHzCVwrg4qGmXeGf1mQcsal4PBis1TQUpa3iuwJapgif5gN/vHsmhSprF6JMjhKb?= =?utf-8?q?m/r+Nyyqn3+KVUbCos0WpUXHM69CF156X9Gmd2G+JXhxATBRXOV9qauKyhmUmKVzm?= =?utf-8?q?Y8SXLrgG3XEqj2/xSW5GVfiBv/20maxyuhJAs5OUCVG2LUrn99AkmcEyUk/VI1xRN?= =?utf-8?q?rjlY543GEdR9gC+SfbFBCeSpC1FqCLaoXp5MNb5znY71Dz/JZ517spQJiYLUGY5yx?= =?utf-8?q?aATghSYALxJHyvOcfBe0NlOfHlL8wdeUIIksCUIgEi7e/H/T/utLYxmXGCqNDoBRm?= =?utf-8?q?xua9oXspuiYJZlxYB+9c5BfVvwWaEYrQ7L3zlk3DObHM+mCU5eswKOGYoIAG97r6k?= =?utf-8?q?WNKCLjqifX0YZQRjIxacGm/AeuUVQ3guwaCi7P52e0FsrVlrQ58y7rOrSRxAtWPCu?= =?utf-8?q?yCF6HaLVYM8S7RVB9iLNicGIL5qTaRB4d8l2hYu2zww+7KB+HCazi9vdHgSam0YZD?= =?utf-8?q?Ykii4zFe7ldPC5pptQKX+0QDmQUVFoKuXuCbpkKzmOjTD6uV/JaEhaMUUE4nuHdER?= =?utf-8?q?6+vnv6ULlmnZQtzbqeonspcPVMl7IRYMp2GIHUwXLfX801humpjVH2N82aa+unYTK?= =?utf-8?q?NCj7z3G2fxC7pbcqhEzNBNjJx65AxcNNPwfyFRNASYQQccptJBb0XZCj7yEQ+kA3a?= =?utf-8?q?3QfPkLlT/XU/FkFls+RDK156jMfNz1A10RaqgthAT4y8xyoEGYn9MQw=3D?= Content-Type: text/plain; charset="utf-8" Content-ID: <42AACF6C6D70B446AB697A1E319F87B9@apcprd04.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: espressif.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: TYZPR04MB5736.apcprd04.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: e357836b-4a5b-4aed-064e-08daf8a08000 X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jan 2023 15:35:45.1818 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5faf27fd-3557-4294-9545-8ea74a409f39 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: pExaLMvhuhjJpkIJX7Zrta8414zfUBDneMDP0JA/vOP/BpWGgs9IZJjdRqHzNnVy+3zhn3kEP9SjljDtL0XWlE3pE50pyfa/fyvIzgptecI= X-MS-Exchange-Transport-CrossTenantHeadersStamped: PUZPR04MB6463 X-Spam-Status: No, score=-12.4 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, GIT_PATCH_0, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list <gcc-patches.gcc.gnu.org> List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc-patches>, <mailto:gcc-patches-request@gcc.gnu.org?subject=unsubscribe> List-Archive: <https://gcc.gnu.org/pipermail/gcc-patches/> List-Post: <mailto:gcc-patches@gcc.gnu.org> List-Help: <mailto:gcc-patches-request@gcc.gnu.org?subject=help> List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc-patches>, <mailto:gcc-patches-request@gcc.gnu.org?subject=subscribe> From: Alexey Lapshin via Gcc-patches <gcc-patches@gcc.gnu.org> Reply-To: Alexey Lapshin <alexey.lapshin@espressif.com> Errors-To: gcc-patches-bounces+patchwork=sourceware.org@gcc.gnu.org Sender: "Gcc-patches" <gcc-patches-bounces+patchwork=sourceware.org@gcc.gnu.org> |
Series |
[RFC] tree-optimization: fix optimize-out variables passed into func to alloc
|
|
Commit Message
Alexey Lapshin
Jan. 17, 2023, 3:35 p.m. UTC
After updating to GCC newer than 11.4.0 we found that some code started to fail if it was built with size optimization (-Os). You can find testsuite for reproduction in the attached patch. The simplified version affected code looks like this: void alloc_function (unsigned char **data_p) { *data_p = malloc (8); assert(*data_p != NULL); } int main () { int *data; alloc_function (&data); printf ("data pointer is %p", data); // prints NULL(compile with -Os) } If the type of passed argument is equal to the type in alloc_function declaration it works perfectly. Also helps change one or both types to void. I found that issue started to appear from commit d119f34c952f8718fdbabc63e2f369a16e92fa07 if-statement which leads to this issue was found and after being removed seems it works well. Could you please elaborate on what cases exactly this checking should optimize? I think it should also contain at least one more check for accessing variable's memory to write.. --- gcc/testsuite/gcc.dg/tree-ssa/alloc-in-func.c | 17 +++++++++++++++++ gcc/tree-ssa-alias.cc | 2 -- 2 files changed, 17 insertions(+), 2 deletions(-) create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/alloc-in-func.c -- 2.34.1
Comments
On Tue, Jan 17, 2023 at 7:36 AM Alexey Lapshin via Gcc-patches <gcc-patches@gcc.gnu.org> wrote: > > After updating to GCC newer than 11.4.0 we found that some code started > to fail if it was built with size optimization (-Os). > You can find testsuite for reproduction in the attached patch. > > The simplified version affected code looks like this: > > void alloc_function (unsigned char **data_p) { > *data_p = malloc (8); > assert(*data_p != NULL); > } > int main () { > int *data; > alloc_function (&data); > printf ("data pointer is %p", data); // prints NULL(compile with -Os) > } This code is violating C/C++ aliasing rules. You store to data via a "unsigned char*" and then do a load via "int*". You can just use -fno-strict-aliasing if you want your code to just work. Thanks, Andrew Pinski > > If the type of passed argument is equal to the type in alloc_function > declaration it works perfectly. Also helps change one or both types to > void. > > I found that issue started to appear from commit > d119f34c952f8718fdbabc63e2f369a16e92fa07 > if-statement which leads to this issue was found and after being > removed seems it works well. > > Could you please elaborate on what cases exactly this checking should > optimize? > I think it should also contain at least one more check for accessing > variable's memory to write.. > > > --- > gcc/testsuite/gcc.dg/tree-ssa/alloc-in-func.c | 17 +++++++++++++++++ > gcc/tree-ssa-alias.cc | 2 -- > 2 files changed, 17 insertions(+), 2 deletions(-) > create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/alloc-in-func.c > > diff --git a/gcc/testsuite/gcc.dg/tree-ssa/alloc-in-func.c > b/gcc/testsuite/gcc.dg/tree-ssa/alloc-in-func.c > new file mode 100644 > index 00000000000..b30c1cedcb9 > --- /dev/null > +++ b/gcc/testsuite/gcc.dg/tree-ssa/alloc-in-func.c > @@ -0,0 +1,17 @@ > +/* { dg-do run } */ > +/* { dg-options "-Os" } */ > + > +#define assert(x) if (!(x)) __builtin_abort () > + > +static inline void alloc_function (unsigned char **data_p) > +{ > + *data_p = (unsigned char *) __builtin_malloc (10); > + assert (*data_p != (void *)0); > +} > + > +int main () > +{ > + int *data = (void *)0; > + alloc_function ((unsigned char **) &data); > + assert (data != (void *)0); > +} > diff --git a/gcc/tree-ssa-alias.cc b/gcc/tree-ssa-alias.cc > index b8f107dfa52..9068db300e5 100644 > --- a/gcc/tree-ssa-alias.cc > +++ b/gcc/tree-ssa-alias.cc > @@ -2608,8 +2608,6 @@ modref_may_conflict (const gcall *stmt, > if (num_tests >= max_tests) > return true; > alias_stats.modref_tests++; > - if (!alias_sets_conflict_p (base_set, base_node->base)) > - continue; > num_tests++; > } > > -- > 2.34.1 >
On Tue, Jan 17, 2023 at 10:41 PM Andrew Pinski via Gcc-patches <gcc-patches@gcc.gnu.org> wrote: > > On Tue, Jan 17, 2023 at 7:36 AM Alexey Lapshin via Gcc-patches > <gcc-patches@gcc.gnu.org> wrote: > > > > After updating to GCC newer than 11.4.0 we found that some code started > > to fail if it was built with size optimization (-Os). > > You can find testsuite for reproduction in the attached patch. > > > > The simplified version affected code looks like this: > > > > void alloc_function (unsigned char **data_p) { > > *data_p = malloc (8); > > assert(*data_p != NULL); > > } > > int main () { > > int *data; > > alloc_function (&data); > > printf ("data pointer is %p", data); // prints NULL(compile with -Os) > > } > > This code is violating C/C++ aliasing rules. > You store to data via a "unsigned char*" and then do a load via "int*". > You can just use -fno-strict-aliasing if you want your code to just work. You can also use void **data_p as a workaround, GCC treats void * similar to a character type for aliasing rules (note that this is a GCC extension and not guaranteed to work by the C/C++ standards). Richard. > Thanks, > Andrew Pinski > > > > > If the type of passed argument is equal to the type in alloc_function > > declaration it works perfectly. Also helps change one or both types to > > void. > > > > I found that issue started to appear from commit > > d119f34c952f8718fdbabc63e2f369a16e92fa07 > > if-statement which leads to this issue was found and after being > > removed seems it works well. > > > > Could you please elaborate on what cases exactly this checking should > > optimize? > > I think it should also contain at least one more check for accessing > > variable's memory to write.. > > > > > > --- > > gcc/testsuite/gcc.dg/tree-ssa/alloc-in-func.c | 17 +++++++++++++++++ > > gcc/tree-ssa-alias.cc | 2 -- > > 2 files changed, 17 insertions(+), 2 deletions(-) > > create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/alloc-in-func.c > > > > diff --git a/gcc/testsuite/gcc.dg/tree-ssa/alloc-in-func.c > > b/gcc/testsuite/gcc.dg/tree-ssa/alloc-in-func.c > > new file mode 100644 > > index 00000000000..b30c1cedcb9 > > --- /dev/null > > +++ b/gcc/testsuite/gcc.dg/tree-ssa/alloc-in-func.c > > @@ -0,0 +1,17 @@ > > +/* { dg-do run } */ > > +/* { dg-options "-Os" } */ > > + > > +#define assert(x) if (!(x)) __builtin_abort () > > + > > +static inline void alloc_function (unsigned char **data_p) > > +{ > > + *data_p = (unsigned char *) __builtin_malloc (10); > > + assert (*data_p != (void *)0); > > +} > > + > > +int main () > > +{ > > + int *data = (void *)0; > > + alloc_function ((unsigned char **) &data); > > + assert (data != (void *)0); > > +} > > diff --git a/gcc/tree-ssa-alias.cc b/gcc/tree-ssa-alias.cc > > index b8f107dfa52..9068db300e5 100644 > > --- a/gcc/tree-ssa-alias.cc > > +++ b/gcc/tree-ssa-alias.cc > > @@ -2608,8 +2608,6 @@ modref_may_conflict (const gcall *stmt, > > if (num_tests >= max_tests) > > return true; > > alias_stats.modref_tests++; > > - if (!alias_sets_conflict_p (base_set, base_node->base)) > > - continue; > > num_tests++; > > } > > > > -- > > 2.34.1 > >
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/alloc-in-func.c b/gcc/testsuite/gcc.dg/tree-ssa/alloc-in-func.c new file mode 100644 index 00000000000..b30c1cedcb9 --- /dev/null +++ b/gcc/testsuite/gcc.dg/tree-ssa/alloc-in-func.c @@ -0,0 +1,17 @@ +/* { dg-do run } */ +/* { dg-options "-Os" } */ + +#define assert(x) if (!(x)) __builtin_abort () + +static inline void alloc_function (unsigned char **data_p) +{ + *data_p = (unsigned char *) __builtin_malloc (10); + assert (*data_p != (void *)0); +} + +int main () +{ + int *data = (void *)0; + alloc_function ((unsigned char **) &data); + assert (data != (void *)0); +} diff --git a/gcc/tree-ssa-alias.cc b/gcc/tree-ssa-alias.cc index b8f107dfa52..9068db300e5 100644 --- a/gcc/tree-ssa-alias.cc +++ b/gcc/tree-ssa-alias.cc @@ -2608,8 +2608,6 @@ modref_may_conflict (const gcall *stmt, if (num_tests >= max_tests) return true; alias_stats.modref_tests++; - if (!alias_sets_conflict_p (base_set, base_node->base)) - continue; num_tests++; }