From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf1-x435.google.com (mail-pf1-x435.google.com [IPv6:2607:f8b0:4864:20::435]) by sourceware.org (Postfix) with ESMTPS id 906D93858D28 for ; Mon, 8 Apr 2024 23:11:54 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 906D93858D28 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 906D93858D28 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2607:f8b0:4864:20::435 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712617916; cv=none; b=Pr5fLfBxxtF1YvkpZgfTqHglmz1DWqkjhn8MPqJG47IC0Z7P5hsoiGd/uEEXdqsNxXodgIGSS4xwqbcI5Zcc+goPDk3PkG7UHrr7zkSfxT1YuVfcYthOioTgiSBjquZbDBf6P9Q2J29ONiLNHKzJG1YtB8ciijvrXyy1YEGh9sI= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712617916; c=relaxed/simple; bh=vnnEEoANlO4+InNkF879hx10dHdXxMpxW49+Z1PqE94=; h=DKIM-Signature:MIME-Version:From:Date:Message-ID:Subject:To; b=NM0tMT51S0jdM8DhvXE5xYJc3xQpYLFTkgViV9uJSrIwL/BWkgtn5YrLY9bVnaM/4aZtzvXXYqP2tqDq4CAb/on0326pEdbffcoxhZ/bVa1HCe9ItP0PFrEmju3X4qFoHWCxybzB2igwow/LDE4Ad7vY060ItPSRSXPngICtafM= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-pf1-x435.google.com with SMTP id d2e1a72fcca58-6ecee5c08e6so4643020b3a.3 for ; Mon, 08 Apr 2024 16:11:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1712617913; x=1713222713; 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=duYNv9XaVFQmVsuY8qt3sVx6TlpF8dWjMqZu59HOxA4=; b=k7khic5QTtwKAcLxkRoMJBJDTtsLVAz18iPGJX8GUG1SZ331f2SrnsKT5JAjXYLEuo 3OjSwtpb/QT2XL0vNpj5pfBbhWJ5V+Y4CXIqokIkhv0rTsW+PirPj0Sm3Sg5W/tt80Lo Tc86Xpg+3pPA+Y223HRK8cLDN0mVgqzp9qZhsaQciYbYIQXcVRPTCuzUzFEf6iGCrX6h r278RmQQvqzctdAs+bpDWCGLjfL/jPBs1QqDO5JmTfk/HsklDIi0LxAgTJEWjTj/gbsV I/QXlWiE0xYXEYwHTiiq8kJJT/2Ntm52+b+ZphelOH1zKuSXiqIhaol1Z7hKQtqJ3Pq4 LtFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712617913; x=1713222713; 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=duYNv9XaVFQmVsuY8qt3sVx6TlpF8dWjMqZu59HOxA4=; b=e5FRzygv72HRSbY0X7zsJRr9pOLt1pB4yZr+hMN01UV65JV2H2i+VKfmssOCNz8ijT TroZKOsBD8DF1yD81G/XfDoE/p8hOFTqIMICNP8fjGq1cmZUa15dkTiUn68KmY8x/A0Q Q9uoBbYJTcg+sG339ndvqXgBwszQI62hP8LV2DhV7Klq8Ht6hhJHZ1Z+PpOyDgTpU5Xo YM3dXamyGA2Pf4OFFDLNc4vE1ECklwmaArlUqBThtxsoVoxp9l2ACz3UShv3oH9PL2M/ Un8wn2r4u5yVy0+8drCLGURl7TYPtVi+e008dFeV8C+sXMQ1qhT+KKp42e21dpEK6BaV eSAQ== X-Forwarded-Encrypted: i=1; AJvYcCWWELLnOLuV0TJ26yq9mFAwwrGQ6eB1zcl0SHJl2IH3lVUzo6NHsoZSmB3hnHdcQg0vpwGGWVR5oWpMbpoG2I+qh9eTt0/6lQ== X-Gm-Message-State: AOJu0YwqjhLoJ/XWQAg7uP6Fjs+tGxb42Pqd1knWxG86mjAdB8tBMQ7h O2J68jDguwePRWdr9fCp7mgdmjVJ8f07bMQWgs8eEZxtrwkC64tJpgMWwZU6qbPNo1G4CVvwvLe UIj2AwUv4O2jo2iHMl4/3rMqIPVQ= X-Google-Smtp-Source: AGHT+IHC6yahP5ok7evWqGteXOVztfugp/Pbjr6p6f+iLL/9E6HwAixwqM6ePVfMOihZUnY07a+vW6ThoCIOGwssLXo= X-Received: by 2002:a05:6a20:9187:b0:1a7:8ef7:b65c with SMTP id v7-20020a056a20918700b001a78ef7b65cmr2788344pzd.57.1712617913296; Mon, 08 Apr 2024 16:11:53 -0700 (PDT) MIME-Version: 1.0 References: <56A9A5FB-8294-47CB-A6C4-22FD5561C71A@googlemail.com> In-Reply-To: <56A9A5FB-8294-47CB-A6C4-22FD5561C71A@googlemail.com> From: Andrew Pinski Date: Mon, 8 Apr 2024 16:11:41 -0700 Message-ID: Subject: Re: [PATCH/RFC] On the use of -funreachable-traps to deal with PR 109627 To: Iain Sandoe Cc: Jason Merrill , GCC Patches , Jakub Jelinek Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-7.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,GIT_PATCH_0,KAM_NUMSUBJECT,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,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 Mon, Apr 8, 2024 at 4:04=E2=80=AFPM Iain Sandoe wrote: > > Hi > > PR 109627 is about functions that have had their bodies completely elided= , but still have the wrappers for EH frames (either .cfi_xxx or LFSxx/LFExx= ). I was thinking about how to fix this once and for all. The easiest method I could think of was if __builtin_unreachable is the only thing in the CFG expand it as __builtin_trap. And then it should just work. It should not to hard to add that check in expand_gimple_basic_block and handle it that way. What do you think of that? I can code this up for GCC 15 if you want. Thanks, Andrew Pinski > > These are causing issues for some linkers because such functions result i= n FDEs with a 0 code extent. > > The simplest representation of this is (from PR109527) > > void foo () { __builtin_unreachable (); } > > The solution (so far) is to detect this case during final lowering and re= place the unreachable (which is expanded to nothing, at least for the targe= ts I=E2=80=99ve dealt with) by a trap; this results in two positive improve= ments (1) the FDE is now finite-sized so the linker consumes it and (2) act= ually the trap is considerably more user-friendly UB than falling through t= o some other arbitrary place. > > I was looking into using -funreachable-traps to do this for aarch64 Darwi= n - because the ad-hoc solutions that were applied to X86 and PPC are not e= asily usable for aarch64. > > -funreachabe-traps was added for similar reasons (helping make missing re= turns less unexpected) in r13-1204-gd68d3664253696 by Jason (and then there= have been further improvements resulting in the use of __builtin_unreachab= le trap () from Jakub) > > As I read the commit message for r13-1204, I would expect -funreachable-t= raps to work for the simple case above, but it does not. I think that is b= ecause the incremental patch below is needed. however, I am not sure if th= ere was some reason this was not done at the time? > > PR 109627 is currently a show-stopper for the aarch64-darwin branch since= libgomp and libgm2 fail to bootstrap - and other workarounds (e.g. -D__bui= ltin_unreachable=3D__builtin_trap) do not work got m2 (since it does not us= e the C preprocessor by default). > > Setting -funreachable-traps either per affected file, or globally for a t= arget resolves the issue in a neater manner. > > Any guidance / comments would be most welcome - if the direction seems sa= ne, I can repost this patch formally. > > (I have tested quite widely on Darwin and on a small number of Linux case= s too) > > thanks > Iain > > * I will note that applying this does result in some regressions in sever= al contracts test cases - but they also regress for -fsanitize=3Dundefined = -fsanitise-traps (not yet clear if that=E2=80=99s expected or we=E2=80=99ve= uncovered a bug in the contracts impl.). > > ---------- > > > diff --git a/gcc/builtins.cc b/gcc/builtins.cc > index f8d94c4b435..e2d26e45744 100644 > --- a/gcc/builtins.cc > +++ b/gcc/builtins.cc > @@ -5931,7 +5931,8 @@ expand_builtin_unreachable (void) > { > /* Use gimple_build_builtin_unreachable or builtin_decl_unreachable > to avoid this. */ > - gcc_checking_assert (!sanitize_flags_p (SANITIZE_UNREACHABLE)); > + gcc_checking_assert (!sanitize_flags_p (SANITIZE_UNREACHABLE) > + && !flag_unreachable_traps); > emit_barrier (); > } > > @@ -10442,7 +10443,7 @@ fold_builtin_0 (location_t loc, tree fndecl) > > case BUILT_IN_UNREACHABLE: > /* Rewrite any explicit calls to __builtin_unreachable. */ > - if (sanitize_flags_p (SANITIZE_UNREACHABLE)) > + if (sanitize_flags_p (SANITIZE_UNREACHABLE) || flag_unreachable_tr= aps) > return build_builtin_unreachable (loc); > break; > > =3D=3D=3D=3D