From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by sourceware.org (Postfix) with ESMTP id 8E08D3858C2C for ; Wed, 6 Oct 2021 16:22:24 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 8E08D3858C2C Received: from mail-lf1-f70.google.com (mail-lf1-f70.google.com [209.85.167.70]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-289-tJA8uhKJNoey-maPNPhikQ-1; Wed, 06 Oct 2021 12:22:23 -0400 X-MC-Unique: tJA8uhKJNoey-maPNPhikQ-1 Received: by mail-lf1-f70.google.com with SMTP id v2-20020ac25582000000b003fd1c161a31so2381570lfg.15 for ; Wed, 06 Oct 2021 09:22:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=R9R/DZSOhSVRTCtXUXi6aloPPr46Lb8trrKGfMCs2QU=; b=RN1wTyox/XOO+COumWjqT6dbWZlLDpx4EGBbl1bkdzcLbo6JEz/Dv4tIjeKSosREP0 KkT06HdwHNsQU2QbVC0As7vQAUVBAahLWqk6OduWMZoxfi3dbkr1i7QJmVHZxbkI5vin ayeoDS85apvwfzT6TYtjGQz/Kh1Tq6Qb++gZNgURy1pPBWYO7x1vAmLcdUPuQrlsyXx8 y1FA6lDiGIDqFaG8D1+51BgQYdewcdBD7AmkaMACpJIsg9aQUvc+yHCMC5UoX41LNkF1 t15G5f681gVVGVoW3leIT+559xnptAGUdeN+kBSOP8+9t2wOekSJZSxnHMv4L0EDeXgw 2Qgw== X-Gm-Message-State: AOAM532SGct/4siSrs4rmURurZEoo4NcK1QQLwr11GAQns6mycv0FNxt GK7YCE0r0cdDnI6gewjOop9WGhPqZc0sH8rOfBsBdBC3lR6JKPnv/j4R9ezN2BGSv3wFddn2Yg6 IyWKrxG6nSFB/Upwwo/N0wTZD6Z5MUlYJ4A== X-Received: by 2002:ac2:5f92:: with SMTP id r18mr10262262lfe.445.1633537341305; Wed, 06 Oct 2021 09:22:21 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw0o8N2C1YyEdwvaVzqdp6VJaSjRvzAhcJ98N4dXRkx8OYdRBa1/ilZ7MpEG9mfKY53EkJsG0lrKK76aS11DIk= X-Received: by 2002:ac2:5f92:: with SMTP id r18mr10262229lfe.445.1633537340996; Wed, 06 Oct 2021 09:22:20 -0700 (PDT) MIME-Version: 1.0 References: <20211004094313.1596556-1-aldyh@redhat.com> <87ilyab8ft.fsf@igel.home> In-Reply-To: From: Aldy Hernandez Date: Wed, 6 Oct 2021 18:22:09 +0200 Message-ID: Subject: Re: [RFC] More jump threading restrictions in the presence of loops. To: Martin Sebor , Jakub Jelinek Cc: Andreas Schwab , Martin Sebor , Michael Matz , Aldy Hernandez via Gcc-patches X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-5.6 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Oct 2021 16:22:27 -0000 On Wed, Oct 6, 2021 at 5:03 PM Martin Sebor wrote: > > On 10/6/21 7:47 AM, Aldy Hernandez via Gcc-patches wrote: > -Wmaybe-uninitialized certainly suffers from a high rate of false > positives (I count 40 open PRs). Even after all this time debugging > it I still struggle with the code for it but in all the bug reports > I've reviewed, only a small subset seems to be due to bugs or even > limitations in it. Most are inherent in its design goal to warn > for reads from variables that cannot be proven to have been > initialized. > > If this one is a bug with some chance of getting fixed it would > be good to distill it to a small test case (even though it's not > unlikely that there already is an existing report with the same > root cause). > > That said, from from your description and the IL above it sounds > to me like the uninitialized read here is possible (it takes place > when _881 != 0), and so -Wmaybe-uininitialized triggers as it's > supposed to. > > Either way, rather than suppressing the warning for the whole file > I would suggest to consider initializing the local variable instead. > Looking at the code in calls.c, I can't convince myself that > the variable cannot, in fact, be used uninitialized. > > Martin FWIW, libgomp/team.c suffers from the same problem if you remove the stop-gap in gomp_team_start(): struct gomp_thread_start_data *start_data = NULL; The use of start_data in the block predicated by "if (nested)" is the only path that can use start_data without passing through its initialization. But the only way to elide the initialization is from: if (!nested) { ... .... if (i == nthreads) goto do_release; } So the use of start_data either crosses the gomp_alloca initialization, or is predicated by if(nested). And the gimple shows a very similar pattern to what I described earlier: [local count: 59055800]: # start_data_876 = PHI do_release: if (_1 != 0) goto ; [55.90%] else goto ; [44.10%] [local count: 26046541]: goto ; [100.00%] [local count: 33009259]: _223 = &team_417(D)->barrier; gomp_barrier_wait (_223); goto ; [100.00%] [local count: 6962719]: [local count: 33009259]: # start_data_781 = PHI # old_threads_used_887 = PHI # affinity_count_825 = PHI # affinity_thr_904 = PHI # force_display_840 = PHI _589 = &MEM[(struct gomp_simple_barrier_t *)pool_410 + 64B].bar; gomp_barrier_wait (_589); [local count: 66018519]: # start_data_870 = PHI The use of start_data_781 coming in from BB265 (start_data_518(D)) would be uninitialized if the read wasn't guarded by "if (_1 != 0)". It seems uninit has issues seeing this pattern. Unfortunately reducing this has been, ahem...challenging, but the problem is still there, both within calls.c on aarch64 and on x86-64 for libgomp/team.c. Aldy