From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS22989 209.51.188.0/24 X-Spam-Status: No, score=-4.5 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,MAILING_LIST_MULTI,RCVD_IN_DNSWL_LOW,SPF_HELO_NONE, SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 898231F55A for ; Fri, 21 Feb 2020 22:47:50 +0000 (UTC) Received: from localhost ([::1]:36990 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1j5H5I-0007ip-Ed for normalperson@yhbt.net; Fri, 21 Feb 2020 17:47:48 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:43958) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1j5H5D-0007ie-MN for bug-gnulib@gnu.org; Fri, 21 Feb 2020 17:47:44 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1j5H5C-0004h0-EY for bug-gnulib@gnu.org; Fri, 21 Feb 2020 17:47:43 -0500 Received: from smtp.polymtl.ca ([132.207.4.11]:37252) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1j5H5C-0004fJ-7z for bug-gnulib@gnu.org; Fri, 21 Feb 2020 17:47:42 -0500 Received: from simark.ca (simark.ca [158.69.221.121]) (authenticated bits=0) by smtp.polymtl.ca (8.14.7/8.14.7) with ESMTP id 01LMlMU2002028 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 21 Feb 2020 17:47:27 -0500 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp.polymtl.ca 01LMlMU2002028 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=polymtl.ca; s=default; t=1582325247; bh=GENoHuS2mHOw3mVKFglErK4kC1lBjsbYe3qpuhbHoiA=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=ZVN81voKfgw9gRyDxJa6ItqCgajZWG9yRKl78UY90qBSc5TtHbtGcSVtL9APGq5m2 pmVljZjfCeU6zNUR7g7lcVu5jMNkeo8cHWy7SDPgp9IJDguwCmHvX6GKY5mOKKEtEl IK1TGA5nPRm3mWr+YQ8q+oIaD+EgSa1yZuiiPlOc= Received: from [172.16.0.95] (192-222-181-218.qc.cable.ebox.net [192.222.181.218]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id C9EB41E598; Fri, 21 Feb 2020 17:47:21 -0500 (EST) Subject: Re: Missing extern "C" in count-one-bits.h? To: Paul Eggert Cc: bug-gnulib@gnu.org References: <314f76bd-3892-b81d-9e7f-ea8865a5ac13@cs.ucla.edu> Message-ID: Date: Fri, 21 Feb 2020 17:47:19 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: <314f76bd-3892-b81d-9e7f-ea8865a5ac13@cs.ucla.edu> Content-Type: text/plain; charset=utf-8 Content-Language: tl X-Poly-FromMTA: (simark.ca [158.69.221.121]) at Fri, 21 Feb 2020 22:47:22 +0000 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by smtp.polymtl.ca id 01LMlMU2002028 X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 132.207.4.11 X-BeenThere: bug-gnulib@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Gnulib discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnulib-bounces+normalperson=yhbt.net@gnu.org Sender: "bug-gnulib" Reply-to: Simon Marchi From: Simon Marchi via Gnulib discussion list On 2020-02-21 3:59 p.m., Paul Eggert wrote: > On 2/20/20 12:15 PM, Simon Marchi wrote: >> The disagreement between the symbol names between count-one-bits.o and= arm-get-next-pcs.o >> seems to show that there is a missing `extern "C"` in the count-one-bi= ts.h header? >=20 > Thanks, I'll take your word for it. (I don't use C++.) I installed the = attached patch into Gnulib. Apparently these modules have been used by C = code only, until now. Thanks, that does the job. I'll try to provide a minimal reproducer next time, I just haven't learne= d yet how to use gnulib in a standalone way (outside of what GDB uses). >> And apparently, gcc decided to compile the definition in the header an= d include >> it in arm-get-next-pcs.o, while clang did not.=C2=A0 Is that the compi= ler's choice, >> or is it because the macros and preprocessor conditionals in count-one= -bits.h >> evaluated to something different for the two compilers? >=20 > It's a compiler's choice whether a function is inlined. When I call cou= nt_one_bits in C, gcc -O2 doesn't create a function for count_one_bits in= the calling module; it simply issues the popcnt insn, or calls the appro= priate GCC library function on platforms that don't have a popcnt insn. P= erhaps you were compiling with some other level of optimization, or perha= ps C++ does this differently; but regardless of how the compiler does it = the resulting code is supposed to work of course. I indeed build without optimizations, to be able to debug, it's likely th= at clang with optimizations would also reduce that to just popcnt. Anyway, thanks for the help, I'll go work on updating GDB's gnulib import= ! Simon