From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg1-x529.google.com (mail-pg1-x529.google.com [IPv6:2607:f8b0:4864:20::529]) by sourceware.org (Postfix) with ESMTPS id 9B8003858423; Wed, 27 Oct 2021 15:36:20 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 9B8003858423 Received: by mail-pg1-x529.google.com with SMTP id h193so3316544pgc.1; Wed, 27 Oct 2021 08:36:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=ZlbO4BzY4vS3TtJ9DtGMhMd0Ji7XQbmR5Zg32YcBww4=; b=xD5NQZ/k9Ycn8Hh/PxAr0VGUgr/MhxAw8aifGv+8xVUk0ClTZDBbW/c7mWGNBlUWWe Z3y0yYPHsJA6arFLFntHojgMXyBIK7QPdhqqg0QDnPSl5Q03R5Y4w4XWR8mJEG2xXDje K0T7MZ6iD9+qdlrUKFqty95k0+GcB2jBcXNySiIpwRhuEUBwozJaUz7L5ZZC7EF0ZGTa 2EAqzPN4tu4dY7qttnOZlzCqoxnfAZN6N2OXl+W1iNFyKz7wS5U0y6F47QE9HHw5d8lH nVhwmFmPEuW1Vt/FGE7DREKioOz0/tHz/lzJDG3XruaLM3SlNkEhVCm91wXVveWl4aWA jJRw== X-Gm-Message-State: AOAM532f11U5gLqJKGzsN2prkCtCPaLS8H1uF1tT/dcz/0Bux+EbgnqG R98cna1ttIZb+CYqSPmPMV4ryhOiKSQ= X-Google-Smtp-Source: ABdhPJwn1jjQ+IQvQcwZGNweww+DzuRvhw7ODo0fAKfsQKo7SVU/6l0+o3JZS+fSNeNL3zGLxVt+Qw== X-Received: by 2002:a62:1455:0:b0:47b:e9ac:3966 with SMTP id 82-20020a621455000000b0047be9ac3966mr22620550pfu.80.1635348979433; Wed, 27 Oct 2021 08:36:19 -0700 (PDT) Received: from [192.168.0.41] (184-96-250-116.hlrn.qwest.net. [184.96.250.116]) by smtp.gmail.com with ESMTPSA id d6sm341061pfa.39.2021.10.27.08.36.16 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 27 Oct 2021 08:36:19 -0700 (PDT) Subject: Re: [r12-4725 Regression] FAIL: libgomp.c/doacross-1.c (test for excess errors) on Linux/x86_64 To: Jakub Jelinek Cc: gcc-patches@gcc.gnu.org, gcc-regression@gcc.gnu.org References: <20211027052219.DD6AF2864700@gskx-2.sc.intel.com> <20211027133028.GH304296@tucnak> From: Martin Sebor Message-ID: <35bce995-5d8f-a538-c5b0-77a185c04f18@gmail.com> Date: Wed, 27 Oct 2021 09:36:13 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: <20211027133028.GH304296@tucnak> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-5.4 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, KAM_NUMSUBJECT, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, 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-regression@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-regression mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2021 15:36:22 -0000 On 10/27/21 7:30 AM, Jakub Jelinek wrote: > On Tue, Oct 26, 2021 at 10:22:19PM -0700, sunil.k.pandey via Gcc-patches wrote: >> FAIL: libgomp.c/doacross-1.c (test for excess errors) I don't see this failure in my logs (or the other one) or any evidence of the libhomp tests having run. Does the libgomp test suite need something special to enable? > > At least this one is a clear false positive. > int a[256]; > ... > #pragma omp for schedule(static, 1) ordered (1) nowait > for (i = 0; i < 256; i++) > { > #pragma omp atomic write > a[i] = 1; > #pragma omp ordered depend(sink: i - 1) > if (i) > { > #pragma omp atomic read > l = a[i - 1]; // <-------- Here is the false positive warning: '__atomic_load_4' writing 4 bytes into a region of size 0 overflows the destination [-Wstring-overflow=] > // note: at offset [-8589934592, -8] into destination object ‘a’ of size 1024 > if (l < 2) > abort (); > } > The loop iterates i from 0 to 255 and the if body is guarded with i != 0, > so __atomic_load_4 (&a[i - 1]. > Due to the doacross loop vrp doesn't know that the loop iterates from 0 to > 256, because different threads are given just some subset of that interval, > so it is effectively VARYING. The warning is in the IL below: [local count: 30]: _865 = ivtmp.273_871 + 4294967294; _923 = (int) _865; _308 = (sizetype) _923; _707 = _308 * 4; _924 = &a + _707; _926 = __atomic_load_4 (_924, 0); The code calls range_of_expr (vr, val, stmt) where val is _707 and stmt is the assignment _924 = &a + _707. The result is the VR_RANGE [-8589934592, -8]. The code is in get_range() in tree-ssa-strlen.c of all places. The warning uses the range as is, treating it as signed. The debug_ranger() output for the block is below. Am I missing something here? =========== BB 167 ============ Imports: _926 Exports: _926 l.0_927 l.0_927 : _926(I) _243 int VARYING ivtmp.272_874 unsigned int [2147483648, +INF] Relational : (_865 != ivtmp.273_871) [local count: 30]: _865 = ivtmp.273_871 + 4294967294; _923 = (int) _865; _308 = (sizetype) _923; _707 = _308 * 4; _924 = &a + _707; _926 = __atomic_load_4 (_924, 0); l.0_927 = (int) _926; if (l.0_927 <= 1) goto ; [0.00%] else goto ; [100.00%] _308 : sizetype [18446744071562067968, 18446744073709551614] _707 : sizetype [18446744065119617024, 18446744073709551608] _923 : int [-INF, -2] _924 : int * [1B, +INF] 167->13 (T) _926 : unsigned int [0, 1][2147483648, +INF] 167->13 (T) l.0_927 : int [-INF, 1] 167->166 (F) _926 : unsigned int [2, 2147483647] 167->166 (F) l.0_927 : int [2, +INF] Martin > Perhaps it derives some quite useless range > from the i - 1 or i + 1 expressions on signed integer, but that doesn't mean > the warnings should assume the value is likely to be out of bounds. > And there is no warning on the a[i] either (which is also in bounds, but > if for the atomic load the warning code thinks i - 1 can be in > [-8589934592, -8] range, why doesn't it think that i can be in > [-8589934588, -4] range? > > Jakub >