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 [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 9D8B83858D28 for ; Tue, 13 Sep 2022 14:08:04 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 9D8B83858D28 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1663078084; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references; bh=PAMdwTG8LmTM6cnPnfJIMWlXi05J8YhKglwxDv1WB3I=; b=Y1Z+cutWghwmS9yOIHi6wk06p/FtfYXNe62GEyjWpWJIT+N88CzJKhgCZ87aj8dk90ywEX Du5WazINyyNmGkV6XNqBRx99DeutAoB6C4EPsc1xdESUNAd9rOj/iSoR/IhZGVZA/4ru3S DU5Me8oJ+2f07rQeVh5hI8ECozzMCUA= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-96-jl90zrTAP_qx_rwwTCA6pQ-1; Tue, 13 Sep 2022 10:07:59 -0400 X-MC-Unique: jl90zrTAP_qx_rwwTCA6pQ-1 Received: from smtp.corp.redhat.com (int-mx09.intmail.prod.int.rdu2.redhat.com [10.11.54.9]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 67284100ABBC; Tue, 13 Sep 2022 14:07:21 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.39.192.41]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 23F2049BB61; Tue, 13 Sep 2022 14:07:20 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.17.1/8.17.1) with ESMTPS id 28DE7IX33911705 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Tue, 13 Sep 2022 16:07:18 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.17.1/8.17.1/Submit) id 28DE7HTH3910622; Tue, 13 Sep 2022 16:07:17 +0200 Date: Tue, 13 Sep 2022 16:07:17 +0200 From: Jakub Jelinek To: Chung-Lin Tang Cc: Tobias Burnus , gcc-patches Subject: Re: [PATCH, libgomp] Fix chunk_size<1 for dynamic schedule Message-ID: Reply-To: Jakub Jelinek References: <13568991-7359-9149-04fa-cde2245f108c@codesourcery.com> MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 3.1 on 10.11.54.9 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, score=-4.0 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW,SPF_HELO_NONE,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE 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 Thu, Aug 04, 2022 at 09:17:09PM +0800, Chung-Lin Tang wrote: > On 2022/6/28 10:06 PM, Jakub Jelinek wrote: > > On Thu, Jun 23, 2022 at 11:47:59PM +0800, Chung-Lin Tang wrote: > > > with the way that chunk_size < 1 is handled for gomp_iter_dynamic_next: > > > > > > (1) chunk_size <= -1: wraps into large unsigned value, seems to work though. > > > (2) chunk_size == 0: infinite loop > > > > > > The (2) behavior is obviously not desired. This patch fixes this by changing > > > > Why? It is a user error, undefined behavior, we shouldn't slow down valid > > code for users who don't bother reading the standard. > > This is loop init code, not per-iteration. The overhead really isn't that much. But still, we slow down valid code for the sake of garbage. That is a task for sanitizers, not production libraries. > > The question should be, if GCC having infinite loop behavior is reasonable, > even if it is undefined in the spec. Sure, it is perfectly valid implementation of the undefined behavior. UB can leads to tons of surprising behavior, hangs etc. and this is exactly the same category. On Thu, Aug 04, 2022 at 01:31:50PM +0000, Koning, Paul via Gcc-patches wrote: > I wouldn't think so. The way I see "undefined code" is that you can't complain > about "wrong code" produced by the compiler. But for the compiler to malfunction > on wrong input is an entirely differerent matter. For one thing, it's hard to fix > your code if the compiler fails. How would you locate the offending source line? The compiler isn't malfunctioning here. It is similar to calling a library function with bogus arguments, say memcpy with NULL source or destination or some invalid pointer not pointing anywhere valid, etc. The spec clearly says zero or negative chunk size is not valid, you use it, you get what you ask for. Furthermore, it is easy to find out when it hangs on which construct it is and check if that construct is valid. I'm strongly against slowing valid code for this. If you want to implement -fsanitize=openmp and either in that case perform checks on the generated code side or link with an instrumented version of libgomp that explains users what errors they do, that is fine. Jakub