From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::234]) by sourceware.org (Postfix) with ESMTPS id 1000A3858D28 for ; Wed, 18 Jan 2023 07:05:34 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 1000A3858D28 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-lj1-x234.google.com with SMTP id f20so35595060lja.4 for ; Tue, 17 Jan 2023 23:05:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=6OY5bEtsvIBVyWXVyQRTfLzFQISdRqoALL4CbeXDkF0=; b=Ob7NdXxEPi4hH0SQVKjECsH+1MYk2V6tD325i4lNqKjdb9VHhixEPPGgGTg9SwqObJ L9iZ6/4R9zNJf8CvD4OYQo0WJZxuaYNUTIqqqNNEHzFvM3DC6QIh8h+xWsaCcMK+kEL8 Q+4ImCpMCPJtVJzI7MY17j7Yf2ayvEsWA+VRELEH68m2ts8NWwd4j1v5CjHSdSNbyB0Y rNTfvHRbk8Zmh/V/3ESIO6yF1JfhNz0FzhlZ0nkYtP4NZHyfFSDPQL3MiFTM0DgI5OLQ 3a97cB1bEmZB8n/UytkPWZWAxPcDCPLeVvnXUlVXqhBHCIKNaSPWRplg1PrPjWyCsmV9 OKCw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=6OY5bEtsvIBVyWXVyQRTfLzFQISdRqoALL4CbeXDkF0=; b=BfD5v45p4FBSu3fnDA+mzVJxwcA4JujoFr85Wp0ooftz3+guU31tZWBMEtHeKmSSiG J4fU3/8VlD/taeeayW7vrciNaTTGzw5c/Z7BSEWCn3iD7YEYlAmEma68Wl+qSWEtwQ3T 4wuqi90uavX5B4HR6gjYL26Dv+CyXiSNm35AT3MIMgez/62/bLIUKWtsOoddNxAlO5t8 M1WaXZHK6CDReE6fUgqHZC7d295BBjZKFTyA+5NdtcJVeVpwsbrvO0LGiRbK/u6GorTx LEasdVhfJFfKj9Wvz3Os8xgufDfU2FmpI/39xssjZGg/EFa9lyTDJAeHiy2BeukbAwhx l79Q== X-Gm-Message-State: AFqh2kqVNe0oN5e1oAOgwKPFSdPmcWojS1eJLSSEQtUgd0yNLJvPxTxR NsXUomIpAayPsWs/rGHBGFTeCbahwetvn4vvymo= X-Google-Smtp-Source: AMrXdXvJ2BmaGjj9B4eYVZwGIwc3ceOtQh8KSjtrHtuAUzjsfG6l8LKjQMshU+wGWZXzncFhJM6MvgtmHdocW9mqTGk= X-Received: by 2002:a2e:9b97:0:b0:27a:233e:1845 with SMTP id z23-20020a2e9b97000000b0027a233e1845mr508617lji.297.1674025532259; Tue, 17 Jan 2023 23:05:32 -0800 (PST) MIME-Version: 1.0 References: <18ac74c8afb663aa0dc2503a571d0d17ebb2e759.camel@espressif.com> In-Reply-To: From: Richard Biener Date: Wed, 18 Jan 2023 08:05:19 +0100 Message-ID: Subject: Re: [RFC] tree-optimization: fix optimize-out variables passed into func to alloc To: Andrew Pinski Cc: Alexey Lapshin , "gcc-patches@gcc.gnu.org" , "Michael Xiao (XIAOXUFENG)" , Alexey Gerenkov , Anton Maklakov , "d@dcepelik.cz" , "hubicka@ucw.cz" , Ivan Grokhotkov Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-7.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,GIT_PATCH_0,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,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 List-Id: On Tue, Jan 17, 2023 at 10:41 PM Andrew Pinski via Gcc-patches wrote: > > On Tue, Jan 17, 2023 at 7:36 AM Alexey Lapshin via Gcc-patches > 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 > >