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 [63.128.21.124]) by sourceware.org (Postfix) with ESMTP id 18735386EC2F for ; Tue, 17 Nov 2020 16:46:22 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 18735386EC2F Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-398-x0Obfu45NemKETVsf-aC1g-1; Tue, 17 Nov 2020 11:46:18 -0500 X-MC-Unique: x0Obfu45NemKETVsf-aC1g-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 73D5F8730A8; Tue, 17 Nov 2020 16:46:17 +0000 (UTC) Received: from tucnak.zalov.cz (ovpn-113-127.ams2.redhat.com [10.36.113.127]) by smtp.corp.redhat.com (Postfix) with ESMTPS id DFD271759F; Tue, 17 Nov 2020 16:46:16 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.16.1/8.16.1) with ESMTPS id 0AHGkDnc3334801 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Tue, 17 Nov 2020 17:46:14 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.16.1/8.16.1/Submit) id 0AHGkC6l3334800; Tue, 17 Nov 2020 17:46:12 +0100 Date: Tue, 17 Nov 2020 17:46:12 +0100 From: Jakub Jelinek To: Philipp Tomsich Cc: Philipp Tomsich , gcc-patches@gcc.gnu.org, Philipp Tomsich , Jeff Law Subject: Re: [PATCH v1 1/2] Simplify shifts wider than the bitwidth of types Message-ID: <20201117164612.GW3788@tucnak> Reply-To: Jakub Jelinek References: <1605553027-5331-1-git-send-email-philipp.tomsich@vrull.eu> MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 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=-6.0 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) 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: Tue, 17 Nov 2020 16:46:23 -0000 On Tue, Nov 17, 2020 at 05:29:57PM +0100, Philipp Tomsich wrote: > > > In other words, the change to VRP canonicalizes what a lshift_expr with an > > > shift-amount outside of the type width means... it doesn't assume anything > > > about the original language. > > > Do we assume that a LSHIFT_EXPR has the same semantics as for a > > > C-language shift-left? If so, then pre should not generate the LSHIFT_EXPR > > > for _9... or we might even catch this later in path isolation (as > > > undefined > > > behavior, insert a __builtin_trap() and emit a warning)? > > > > > > Note that in his comment to patch 2/2, Jim has noted that user code for > > > RISC-V may assume a truncation of the shift-operand... > > What I'd suggest doing would be to leave the invalid shift count in the > > IL in VRP, then extend the erroneous path isolation code to turn an > > invalid shift into a trap (conditionally of course). > > You had originally suggested to add this to VRP ... > Given the various comments to this patch, do you still want any of > this in VRP or > would you rather see this only in path isolation? Well, I said if we want to do it at all, it should be done in VRP, because there is not really a difference between ((int) x) << 32 and ((int) x) << y for y in [32, 137] etc. Otherwise it is the general question of what to do upon proven UB, and that is a topic discussed several years during Cauldron that it would be nice to have switches where users can choose what to do in that case, __builtin_unreachable (), __builtin_trap (), ... and another thing is where we should warn about it (tight e.g. to the __builtin_warning thing, because we don't want these warnings for dead code). So, e.g. if we had __builtin_warning (dunno where Martin S. is with that), we could e.g. queue a __builtin_warning and add __builtin_unreachable (or other possibilities), or e.g. during VRP just canonicalize proven always out of bound shifts to shifts by an out of bound constant and let some later pass warn and/or add __builtin_warning. Jakub