From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yw1-x1133.google.com (mail-yw1-x1133.google.com [IPv6:2607:f8b0:4864:20::1133]) by sourceware.org (Postfix) with ESMTPS id CC935385841D for ; Tue, 30 Aug 2022 17:24:49 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org CC935385841D Authentication-Results: sourceware.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=google.com Received: by mail-yw1-x1133.google.com with SMTP id 00721157ae682-33dc345ad78so285327427b3.3 for ; Tue, 30 Aug 2022 10:24:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc; bh=K81STEKLdjg2ogBYa+2+OnJNLgoiPwh3rn38KIDVBCI=; b=aBfKilifNLxQeE067HK7fl8/i1k2h9AJ2n/DKaMZqfDQdOze84r3SCbTTxzekLe/mG mOoltHBcALSFyr3ZC2USngg6AwqzUCH836QG+D6T+zjuNyFhq81ZaE7tGRvgAutWJi7N P3y94K9GSBKzYES0wLHzyzgmUiXDuuHfnB1jdbPEO8y9QlCZnMwe6qKGPfn2rG7QTotz /+fRSVaG4ISlpzHVaFIE5R+TVTU/P6S/Xn/1jXWWc3RMS1nyGQVb/6PDIb4NZEAq2Ixr poPCXKyLqPxsR5evDzVhX7s2BTFqmHz8aX8RMNY+GdmcRyCusq4UyBRSwWRvCOzWAXo8 me1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc; bh=K81STEKLdjg2ogBYa+2+OnJNLgoiPwh3rn38KIDVBCI=; b=YnBwIfvOifAkLIAUjXZjnnrhj3JD8fL66JOKlZAvMz6sz/AsBnCxC7OXTm3Wzz1OXL Xjd4Q2Ly1GZvF2vbxOMb5mXdaT4ngMM8enulw9FMZ4JvORfZEAFLUEyz36LHi74ix6HM jRxal+lBtm+1r3XVs6eexFaUMF5jiDPLPudYYbwSgy7smhON8mT2PIkRUkx8MR8axzXI ttXTVjaaRjC6PxXUQCYCwBJZwQZjgaeyHCNjI36Eh+tGu8ZxzIpR1pa/RwYLRKI0aINs cybnSWqScv8gW6xEquxgt5Cz/33BYrmpK0wSJ9HagGx3sgqOkGyGDPFSrDNrkZlM04dz 1J+A== X-Gm-Message-State: ACgBeo279BKPxWCA7DlWZY3h36oNfztoooEhsuBY9MBujbQ/jDjLbGi7 +vVEVDUBQZrfKR7l2gY3WadKgg2+YSOSq2TLLB2iEzMf8eRmgA== X-Google-Smtp-Source: AA6agR42qlUAYIen+uR4U2UNBqOF6VHOtJ0gLvfzJrM2hdsjkDBUsqsWESaNIuOvipDnJ4S4oieJDh8exppe+NcnRuo= X-Received: by 2002:a81:5a56:0:b0:33b:52a8:c360 with SMTP id o83-20020a815a56000000b0033b52a8c360mr14202188ywb.329.1661880287668; Tue, 30 Aug 2022 10:24:47 -0700 (PDT) MIME-Version: 1.0 References: <87edwyst58.fsf@oracle.com> <87bks1istm.fsf@oracle.com> In-Reply-To: <87bks1istm.fsf@oracle.com> From: Fangrui Song Date: Tue, 30 Aug 2022 10:24:36 -0700 Message-ID: Subject: Re: [COMMITTED] bpf: define __bpf__ as well as __BPF__ as a target macro To: "Jose E. Marchesi" Cc: gcc-patches@gcc.gnu.org Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-24.7 required=5.0 tests=BAYES_00,DKIMWL_WL_MED,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,ENV_AND_HDR_SPF_MATCH,GIT_PATCH_0,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE,USER_IN_DEF_DKIM_WL,USER_IN_DEF_SPF_WL 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 Tue, Aug 30, 2022 at 9:46 AM Jose E. Marchesi wrote: > > > > On Mon, Aug 29, 2022 at 1:16 PM Jose E. Marchesi via Gcc-patches > > wrote: > >> > >> > >> LLVM defines both __bpf__ and __BPF_ as target macros. > >> GCC was defining only __BPF__. > >> > >> This patch defines __bpf__ as a target macro for BPF. > >> Tested in bpf-unknown-none. > >> > >> gcc/ChangeLog: > >> > >> * config/bpf/bpf.cc (bpf_target_macros): Define __bpf__ as a > >> target macro. > >> --- > >> gcc/config/bpf/bpf.cc | 1 + > >> 1 file changed, 1 insertion(+) > >> > >> diff --git a/gcc/config/bpf/bpf.cc b/gcc/config/bpf/bpf.cc > >> index 7e37e080808..9cb56cfb287 100644 > >> --- a/gcc/config/bpf/bpf.cc > >> +++ b/gcc/config/bpf/bpf.cc > >> @@ -291,6 +291,7 @@ void > >> bpf_target_macros (cpp_reader *pfile) > >> { > >> builtin_define ("__BPF__"); > >> + builtin_define ("__bpf__"); > >> > >> if (TARGET_BIG_ENDIAN) > >> builtin_define ("__BPF_BIG_ENDIAN__"); > >> -- > >> 2.30.2 > >> > > > > Having multiple choices in this case seems to just add confusion to > > users and making code search slightly more inconvenient. > > > > How much code uses LLVM specific __bpf__? Can it be migrated? Should > > LLVM undefine the macro instead? > > I agree that it would be better to support just one form of the target > macro. Having two alternative forms can only lead to problems. > > But I think the train left the station long ago to do any better: there > are files in the kernel tree that rely on __bpf__ and there may be BPF > programs around doing the same thing. Ok, thanks.