From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com [IPv6:2a00:1450:4864:20::133]) by sourceware.org (Postfix) with ESMTPS id 3240F3858CDA for ; Tue, 9 Apr 2024 07:44:14 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 3240F3858CDA Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 3240F3858CDA Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2a00:1450:4864:20::133 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712648655; cv=none; b=sb7fuyOBPqFy4CDfGyx850cowY7RBdsOVsHXWR8PZ8qsXnm79pvpAgZ+BXK4JkonbXi1w+Wxazt5kfqUk0ZWBttRt+COSPwLnSPBS+eiEtirs3wr5ZWLwSRiq8KBLdogPnRK/6OYSp3xIA7pHVW5BWM1p5wqrAYxhMqUFrruIO8= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712648655; c=relaxed/simple; bh=Xw/Syv5S05Pf0U0PO/LvE8/GkraX/Scs7hcGHqJ5r9w=; h=DKIM-Signature:MIME-Version:From:Date:Message-ID:Subject:To; b=p02HgYibePSr7u0PyRTr6/63OZQCUqx8gN/H4THiO7K8NCq1bBs8g1f0MyfyWArhWK8WwzFXBK0K1G5CK/dOOYL8Vk25jWgdGp3Qomt0ks2Xd0Y4DbMYiM1axQz+Xk8qpkPgXfd77+BbwWhcyE1GqdYKweOHZIcEd60e49nerZQ= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-lf1-x133.google.com with SMTP id 2adb3069b0e04-516d3776334so5269614e87.1 for ; Tue, 09 Apr 2024 00:44:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1712648652; x=1713253452; darn=gcc.gnu.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=1xZHY1jHLfwiMJ2VLJTf9rZiH5sx1AczWI0PG0mSoEE=; b=IRfdPZnPTpn4Trr5UoNFYqKsAe+cOdz2TYr85oCMN1eZqa5bfuxi6IIIHgZcVSWtqc 1xQ+J4C1FqOwRLyktvYK81R5rCkv7VpfsV2yR7CHrt3Lc81MrAO+zQSBK38RZqRetGVM 8Oa7LTAhESo6dZA0Tb+fKkJ4WBFFkllHx0K+fykn8nYtrf3nXCKiY052MjS2dgbWDrq/ LqwN03NYFY0o7mj387GAr5PzhGyUjXvrMgvhtO0NooRL2cH6MKgTkGbA1S1VWDdd+OI9 kSnmd1WXqyt7hwcrp/1KoUTvZuJV6O5RGv3ZYjqe7X2y86y6FuBSdDGvaXPoNBbzDUqE OtXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712648652; x=1713253452; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=1xZHY1jHLfwiMJ2VLJTf9rZiH5sx1AczWI0PG0mSoEE=; b=sSrQ+kV4uX4iIEQdFjZZ72X/yrAUqqfXHrorLPVUbQYvdyKZ5eGxakeKz2TZQ/x+3O LHVkC20knowIE7Sg5nxtwJy9BAcZWfr35yf9xA5ffjo1SPKGSX4OtW5LaU9O3WP/T4OR bSAcBTOG868bI4yx8HkjD/DFocVUkjdvoIIn83m7CMuaNF8hjacAtujdaEnJqcB3Beu6 F5kyMt/b/44B+WPNWQ/YhXPoU5nePfW1imaQJ9PBRFsqyt0LQSaWDipPMILWzkpEt8BK VRKRlbdSw7Fwj3qCpzG5IUZ7lcOkfDQG0c2KyA6XECLDPpdHWMZ1vWZ/+AwPjogC7+YL BHPQ== X-Forwarded-Encrypted: i=1; AJvYcCVhWce7cF7tkSriA+f4Hwn/wvsJCc6A4BvweeXW7EO0lOfRh/zNvQPIVr9a33RCYzUYvs2Rt6R+YgVNH1dCa+lTmiV5TPGaWA== X-Gm-Message-State: AOJu0YxFj2Z/UcB97zGBJDSpMaFkXeHRAeEflIanAt5Y4khfu+h//daI g2lF+2mXXG05vgLGCUuuYHHCv23R59F87ObqkAQrNB7GQdbPhEOQwJr1IKJMkRATbIUaqdIMxur heL54g6tPqHngWda9wlrNr9c/G/I= X-Google-Smtp-Source: AGHT+IF52P1Ng8sAe+SwHaoNNnosrXeMrsVkfsf8hkyS5eAdQh2U+TBcGWv4fBWc5QNZcY/1WGDgtWqNSC4M2MvcvYk= X-Received: by 2002:a05:6512:224d:b0:516:d16e:9059 with SMTP id i13-20020a056512224d00b00516d16e9059mr8663211lfu.42.1712648652343; Tue, 09 Apr 2024 00:44:12 -0700 (PDT) MIME-Version: 1.0 References: <56A9A5FB-8294-47CB-A6C4-22FD5561C71A@googlemail.com> In-Reply-To: From: Richard Biener Date: Tue, 9 Apr 2024 09:44:01 +0200 Message-ID: Subject: Re: [PATCH/RFC] On the use of -funreachable-traps to deal with PR 109627 To: Jakub Jelinek Cc: Jeff Law , Iain Sandoe , Jason Merrill , GCC Patches Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,KAM_NUMSUBJECT,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=no 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 Tue, Apr 9, 2024 at 9:11=E2=80=AFAM Jakub Jelinek wro= te: > > On Tue, Apr 09, 2024 at 09:03:59AM +0200, Richard Biener wrote: > > > With the possibility of sounding like a broken record, I think > > > __builtin_unreachable is fundamentally flawed. It generates no code > > > and just lets the program continue if ever "reached". This is a > > > security risk and (IMHO) just plain silly. We're in a situation that= is > > > never supposed to happen, so continuing to execute code is just askin= g > > > for problems. > > > > > > If it were up to me, I'd have __builtin_unreachable emit a trap or > > > similar construct that should (in general) halt execution. > > > > __builtin_unreachable tells the compiler it's OK to omit a path to it > > while __builtin_trap doesn't. So once we replace the former with the > > latter we have to keep the path. Maybe that's OK. I do agree that > > the RTL representation of expanding __builtin_unreachable () to > > "nothing" is bad. Expanding to a trap always would be OK with me. > > Even that would prevent tons of needed optimizations, especially the > reason why __builtin_unreachable () has been added in the first place > - for asm goto which always branches and so the kernel can put > __builtin_unreachable () after it to say that it won't fall through. > I think the kernel folks would be upset if we change that. > > So, can't we instead just emit a trap when in the last cfglayout -> cfgrt= l > switch we see that the last bb in the function doesn't have any successor= s? That's probably a good middle-ground if we can identify that "last" switch easily (why not do it at each such switch?) Richard. > Jakub >