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.129.124]) by sourceware.org (Postfix) with ESMTPS id 3E4583851402 for ; Fri, 17 Mar 2023 15:04:21 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 3E4583851402 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=1679065460; h=from:from: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=G14Vn4szkgqIWYHtgzTvQunWS7eVIegn+8R02WbzVro=; b=ewgsHOkntv1FH+YO5HUh+nqPBUnI3Lfj/i3wcdUZe5LUIMxH6BMfd5lfb1rSrO3PYCO3ww O6RxkeHzAVxYdw4RTH1U2lBGeyc1JTHxsmLkD6FOdiOtKa1cItTD3K7f6UzIXGcFYqgNSS bK8qWbVL80eIKLs7iQZXmICQ1G1d+GA= Received: from mail-qk1-f197.google.com (mail-qk1-f197.google.com [209.85.222.197]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-657-E9mjGgxhN_CSJh-QawSIAQ-1; Fri, 17 Mar 2023 11:04:17 -0400 X-MC-Unique: E9mjGgxhN_CSJh-QawSIAQ-1 Received: by mail-qk1-f197.google.com with SMTP id 191-20020a3705c8000000b007459d84a0f9so2757917qkf.17 for ; Fri, 17 Mar 2023 08:04:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1679065456; h=user-agent:in-reply-to:content-disposition:mime-version:references :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=G14Vn4szkgqIWYHtgzTvQunWS7eVIegn+8R02WbzVro=; b=NLoO725+E2d8rNIpKp/v+GDCTjHZdwCd8Xb32yLqrQXcwg1HkkoSmgPv1Ayhmqug8A ggL898D8huNxfAKF6dqK9C2r3vs1fcVjBu73DYxnTqDvL9sZDM0bkWCdkTWTgZULBEh2 OFWCXDetHooJ7Kq+1yHFdAJfTh2cuqiCdOUitiD0LF/IPD8wAJlZ7eWgU35g8pmCEha/ eL9MOqhUd6gcx0oesXsdXMW5Ib5Wi7nf/ZM0kNO0kNp2naVkt7e/xZ7+CMOWQDLGqXGq yDiOVZPRcsneElJ3icmqehK4MdXecw6FWd9+ufzgZriyzRYfySRaUYhXAO6KB2e7aZ/S jrmQ== X-Gm-Message-State: AO0yUKW9PfXPhgBv9IYokT9StYbvY4kCu5lsGr78m+bbR9DDZhi6/yCH DEzpQjY12+jG0gEOPrYTcV6AuneYXuauXoClYzZTxBxU44Jof8fpuHk2lTdnzkumPqRtC4IT4WO +PWa7DBHr+63H3U4lxw== X-Received: by 2002:ac8:5cce:0:b0:3bf:c04a:8d47 with SMTP id s14-20020ac85cce000000b003bfc04a8d47mr14441876qta.18.1679065456509; Fri, 17 Mar 2023 08:04:16 -0700 (PDT) X-Google-Smtp-Source: AK7set8cPOKtSWG6N1z7NwirqUTTaKHaKE3wugKReGyxXs8uSjqbQ1aLBFYX8Vbot1dYs/3Fzrxjdw== X-Received: by 2002:ac8:5cce:0:b0:3bf:c04a:8d47 with SMTP id s14-20020ac85cce000000b003bfc04a8d47mr14441851qta.18.1679065456241; Fri, 17 Mar 2023 08:04:16 -0700 (PDT) Received: from redhat.com (2603-7000-9500-34a5-0000-0000-0000-1db4.res6.spectrum.com. [2603:7000:9500:34a5::1db4]) by smtp.gmail.com with ESMTPSA id z16-20020ac86b90000000b003b86b962030sm1410391qts.72.2023.03.17.08.04.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 17 Mar 2023 08:04:15 -0700 (PDT) Date: Fri, 17 Mar 2023 11:04:14 -0400 From: Marek Polacek To: Jakub Jelinek Cc: "Joseph S. Myers" , Richard Biener , gcc-patches@gcc.gnu.org Subject: Re: [PATCH] c, ubsan: Instrument even shortened divisions [PR109151] Message-ID: References: MIME-Version: 1.0 In-Reply-To: User-Agent: Mutt/2.2.9 (2022-11-12) 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.5 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_H2,SPF_HELO_NONE,SPF_NONE,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 Fri, Mar 17, 2023 at 09:14:04AM +0100, Jakub Jelinek wrote: > Hi! > > On the following testcase, the C FE decides to shorten the division because > it has a guarantee that INT_MIN / -1 division won't be encountered, the > first operand is widened from narrower unsigned and/or the second operand is > a constant other than all ones (in this case both are true). > The problem is that the narrower type in this case is _Bool and > ubsan_instrument_division only instruments it if op0's type is INTEGER_TYPE > or REAL_TYPE. Strangely this doesn't happen in C++ FE. I was curious. The difference is because C++ passes this (gdb) pge op0 (int) (short int) (VIEW_CONVERT_EXPR(d) == 1 | VIEW_CONVERT_EXPR(d) > 9) to shorten_binary_op while C passes: (gdb) pge op0 (int) (<<< Unknown tree: c_maybe_const_expr d >>> == 1 || <<< Unknown tree: c_maybe_const_expr d >>> > 9) so when we remove the '(int)' cast, we have different types underneath, either short or bool. In C, the BIT_IOR_EXPR -> TRUTH_OR_EXPR change is because we call c_convert -> convert_to_integer -> do_narrow. In C++, we never called do_narrow so shorten_binary_op gets the original tree. Anyway, thanks for the patch. Marek