From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf1-x42a.google.com (mail-pf1-x42a.google.com [IPv6:2607:f8b0:4864:20::42a]) by sourceware.org (Postfix) with ESMTPS id 3D77B3857C4F for ; Sat, 24 Jun 2023 14:24:13 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 3D77B3857C4F Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-pf1-x42a.google.com with SMTP id d2e1a72fcca58-666ecb21f86so1516747b3a.3 for ; Sat, 24 Jun 2023 07:24:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1687616652; x=1690208652; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=TF8dAy9I8IkUBySD5psrzOkXhCA9yGpS1Z2lE/k1imE=; b=rFi69JsjlfAbgZhVBbmoR3/jRl13k3ONatr6gZdnOIirkR1l//leasFGVbthmTu4ln GC0ulzQasuYsrA0q11k/W9DLP2P/14inizGUP+j6rPVSu9yaDv0Cq/545YMw86VPKJQ4 yff33YNguFNwfomHv3T+JhKg72GCIdyqr4t/b/d4WRLfbaS7cbzEjZ7tcBNLVxTxD9vf euhvV5OPogWNm4NeLyG9H3A6Bl7dBuaWxqO+FHfJjZX7zRSY/8SUw1HRycs3utx+1uDs uI4Q+DxzR1UdWltdKRPIy4QbAld9kYi/65/Nr2YWz1CcPrE2dq0egmL+/kFKJI6oJrLE XwQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1687616652; x=1690208652; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=TF8dAy9I8IkUBySD5psrzOkXhCA9yGpS1Z2lE/k1imE=; b=Z2xjwj5F00rEbISPHfhH2k7Ww2+fEk8QHWR0ZwsHQ2mINtu939Q/o95bBbowv6PSBj BLK+k4slhQRnDdKfYVTubPudM1MeO7Z/d1npEUDbYEOeiKAHP+Az7rPJH9KCYBf7cxBu gOfYLwahsUODvAa+YzxHf+0dHqiDblyy0xUvCeN8QxKyEwxG9c708B2J6V3zZy67X73B uJ40JhzwgJEEs1BiT5S9osip1inuxe6o6MgcGGkrwgPOpo2STf9uz4cIEUi8a54rRrNo MrcujF2LCIrSRUY2UIXyP2/DmmIu0xdctGOU8p4YyHx9uYQVtN2VDsTAKcvJhQToqZhn ZWJA== X-Gm-Message-State: AC+VfDyHlmj0A+wWXc11FA/J6O7+dQ8imAqXmxPd+h+X7HB8HoGHJVBr v8um63Za2c2W8J0O2Swz4V0= X-Google-Smtp-Source: ACHHUZ7exQ8j08rcVcPTA3+NoWhtEjhHweqRVkONMlQY1vAsry9/qTN/wfMUnCZsvz1A7qN9X+CtTQ== X-Received: by 2002:a05:6a00:1595:b0:668:7292:b2c4 with SMTP id u21-20020a056a00159500b006687292b2c4mr22969084pfk.4.1687616652210; Sat, 24 Jun 2023 07:24:12 -0700 (PDT) Received: from [172.31.0.109] ([136.36.130.248]) by smtp.gmail.com with ESMTPSA id f19-20020aa782d3000000b0062dba4e4706sm1129561pfn.191.2023.06.24.07.24.11 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 24 Jun 2023 07:24:11 -0700 (PDT) Message-ID: Date: Sat, 24 Jun 2023 08:24:10 -0600 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.12.0 Subject: Re: [PATCH] Improve DSE to handle stores before __builtin_unreachable () Content-Language: en-US To: Jan Hubicka Cc: Richard Biener , gcc-patches@gcc.gnu.org References: <20230620070009.C11983858D1E@sourceware.org> <7bddf09a-1535-8bcb-94da-8ad18b51963f@gmail.com> From: Jeff Law In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,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 6/22/23 07:42, Jan Hubicka wrote: >> >> >> On 6/22/23 00:31, Richard Biener wrote: >>> I think there's a difference in that __builtin_trap () is observable >>> while __builtin_unreachable () is not and reaching __builtin_unreachable >>> () invokes undefined behavior while reaching __builtin_trap () does not. >>> >>> So the isolation code marking the trapping code volatile should be >>> enough and the trap () is just there to end the basic block >>> (and maybe be on the safe side to really trap). >> Agreed WRT observability -- but that's not really the point of the trap and >> if we wanted we could change that behavior. >> >> The trap is there to halt execution immediately rather than letting it keep >> running. That was a design decision from a security standpoint. If we've >> detected that we're executing undefined behavior, stop rather than >> potentially letting a malicious actor turn a bug into an exploit. > > Also as discussed some time ago, the volatile loads between traps has > effect of turning previously pure/const functions into non-const which > is somewhat sad, so it is still on my todo list to change it this stage1 > to something more careful. We discussed internal functions trap_store > and trap_load which will expand to load/store + trap but will make it > clear that side effect does not count to modref. It's been a long time since I looked at this code -- isn't it the case that we already must have had a load/store and that all we've done is change its form (to enable more DCE) and added the volatile marker? Meaning that it couldn't have been pure/cost before, could it? Or is it the case that you want to not have the erroneous path be the sole reason to spoil pure/const detection -- does that happen often in practice? jeff