Re: [cfe-users] Undefined behaviour in a small code snippet

[Matthew Fernandez via cfe-users]

I don’t have the reference on hand, but I’m pretty sure writing to one union 
member and reading the value back through another is undefined behaviour. I 
believe this is inherited from C99 or earlier. 

> On 19 Mar 2018, at 12:00, via cfe-users  wrote:
> 
> Send cfe-users mailing list submissions to
>cfe-users@lists.llvm.org
> 
> To subscribe or unsubscribe via the World Wide Web, visit
>http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
> or, via email, send a message with subject or body 'help' to
>cfe-users-requ...@lists.llvm.org
> 
> You can reach the person managing the list at
>cfe-users-ow...@lists.llvm.org
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of cfe-users digest..."
> 
> 
> Today's Topics:
> 
>   1. Undefined behaviour in a small code snippet
>  (Łukasz Szczur via cfe-users)
> 
> 
> --
> 
> Message: 1
> Date: Tue, 13 Mar 2018 01:14:51 +0100
> From: Łukasz Szczur via cfe-users 
> To: cfe-users@lists.llvm.org
> Subject: [cfe-users] Undefined behaviour in a small code snippet
> Message-ID:
>
> Content-Type: text/plain; charset="utf-8"
> 
> Hello,
> 
> The program at the bottom prints
> 1
> 2
> 1
> 2
> 
> Does the code contain undefined behaviour in C++17 (note that the structs
> have common initial sequence )?
> 
> Łukasz
> 
> 
> #include
> 
> using namespace std;
> 
> struct A {
>int first;
>int second;
> };
> 
> struct B {
>int first;
>int second;
> };
> 
> struct Test {
>union {
>A a;
>B b;
>};
> };
> 
> int main() {
>Test t;
>t.a.first = 1;
>t.b.second = 2;
>cout << t.a.first << '\n';
>cout << t.a.second << '\n';
>cout << t.b.first << '\n';
>cout << t.b.second << '\n';
>return 0;
> }
> -- next part --
> An HTML attachment was scrubbed...
> URL: 
> 
> 
> --
> 
> Subject: Digest Footer
> 
> ___
> cfe-users mailing list
> cfe-users@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
> 
> 
> --
> 
> End of cfe-users Digest, Vol 62, Issue 9
> 
___
cfe-users mailing list
cfe-users@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users

Re: [cfe-users] Problems with hexadecimal constant, _mm_set_epi64x and sign conversion

[Matthew Fernandez via cfe-users]

What version of Clang are you using? I cannot tell from the Travis config. I 
cannot reproduce this with -Wall -Wextra with any of the Clangs I happen to 
have on hand (3.8.0, 4.0.1, 5.0.0). 

> On 1 Apr 2018, at 12:00, via cfe-users  wrote:
> 
> Send cfe-users mailing list submissions to
>cfe-users@lists.llvm.org
> 
> To subscribe or unsubscribe via the World Wide Web, visit
>http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
> or, via email, send a message with subject or body 'help' to
>cfe-users-requ...@lists.llvm.org
> 
> You can reach the person managing the list at
>cfe-users-ow...@lists.llvm.org
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of cfe-users digest..."
> 
> 
> Today's Topics:
> 
>   1. Problems with hexadecimal constant,_mm_set_epi64x and sign
>  conversion (Jeffrey Walton via cfe-users)
> 
> 
> --
> 
> Message: 1
> Date: Sat, 31 Mar 2018 23:51:22 -0400
> From: Jeffrey Walton via cfe-users 
> To: "CFE-Users (Clang)" 
> Subject: [cfe-users] Problems with hexadecimal constant,
>_mm_set_epi64x and sign conversion
> Message-ID:
>
> Content-Type: text/plain; charset="UTF-8"
> 
> I'm having trouble with Travis during testing. The failed test is
> available at https://travis-ci.org/Tarsnap/scrypt/jobs/360781179.
> 
> Clang has rejected my attempts to use the constant (no suffix, ULL and LL):
> 
> MSG = _mm_add_epi32(MSG0, _mm_set_epi64x(0xE9B5DBA5B5C0FBCF,
> 0x71374491428A2F98));
> 
> MSG = _mm_add_epi32(MSG0, _mm_set_epi64x(0xE9B5DBA5B5C0FBCFULL,
> 0x71374491428A2F98ULL));
> 
> MSG = _mm_add_epi32(MSG0, _mm_set_epi64x(0xE9B5DBA5B5C0FBCFLL,
> 0x71374491428A2F98LL));
> 
> The message the compiler provides is:
> 
> crypto_sha256_shani.c:50:44: error: implicit conversion changes
> signedness: 'unsigned long' to 'long long' [-Werror,-Wsign-conversion]
> 
> The code came from Intel and I doubt it is defective.
> 
> How do I trick Clang to accept the hexadecimal value?
> 
> Thanks in advance.
> 
> 
> --
> 
> Subject: Digest Footer
> 
> ___
> cfe-users mailing list
> cfe-users@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
> 
> 
> --
> 
> End of cfe-users Digest, Vol 63, Issue 1
> 
___
cfe-users mailing list
cfe-users@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users

[cfe-users] cfe-users proof of life

[Matthew Fernandez via cfe-users]

Hello all,

Meta question: is cfe-users still a productive forum for getting Clang support? 
I ask because the vast majority of questions I see on here either receive no 
response or are forwarded to cfe-dev. I’m not trying to start an argument, but 
simply ask whether maybe there should only be one cfe list.

Thanks,
Matt
___
cfe-users mailing list
cfe-users@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users

Re: [cfe-users] how clang merge strings in .rodata section

[Matthew Fernandez via cfe-users]

> On Jul 6, 2018, at 12:00, via cfe-users  wrote:
> 
> Message: 1
> Date: Fri, 6 Jul 2018 09:54:05 +0200
> From: Hans Wennborg via cfe-users 
> To: "Jian, Xu" 
> Cc: "cfe-users@lists.llvm.org" 
> Subject: Re: [cfe-users] how clang merge strings in .rodata section
> Message-ID:
>   
> Content-Type: text/plain; charset="UTF-8"
> 
> On Thu, Jul 5, 2018 at 3:18 AM, Jian, Xu via cfe-users
>  wrote:
>> Hi,
>> 
>> The following c source code abc.c:
>> 
>> #include 
>> 
>> int g_val=10;
>> 
>> const char *g_str="abc";
>> 
>> const char *g_str1="c";
>> 
>> int main(void)
>> 
>> {
>> 
>>printf("%s %s: %d\n",g_str,g_str1,g_val);
>> 
>>return 0;
>> 
>> }
>> 
>> 
>> 
>> When compile with “clang abc.c -o abc” then dump .rodata section:
>> 
>> # readelf -p .rodata abc
>> 
>> 
>> 
>> String dump of section '.rodata':
>> 
>>  [ 0]  abc
>> 
>> [ 4]  %s %s: %d
>> 
>> 
>> 
>> When compile with “gcc abc.c -o abc” then dump .rodata section:
>> 
>> $ readelf -p .rodata abc
>> 
>> 
>> 
>> String dump of section '.rodata':
>> 
>>  [10]  abc
>> 
>>  [14]  c
>> 
>>  [16]  %s %s: %d^J
>> 
>> 
>> 
>> clang is able to merge short string (“c”) into the tail of a long string
>> (“abc”), while gcc will not.
>> 
>> Does anybody know how to disable this behavior (make it similar to gcc) ?
> 
> I don't think there is a way to disable it.
> 
> Why do you want to disable this behaviour?
> 
> - Hans
> 
> 
> --
> 
> Message: 2
> Date: Fri, 6 Jul 2018 08:22:57 +
> From: "Jian, Xu via cfe-users" 
> To: Hans Wennborg 
> Cc: "cfe-users@lists.llvm.org" 
> Subject: Re: [cfe-users] how clang merge strings in .rodata section
> Message-ID:
>   <21f00ce5ca12aa41a34a1a361177f7f901761...@mx201cl03.corp.emc.com>
> Content-Type: text/plain; charset="utf-8"
> 
> Hi Hans,
> We need to compare whether ELF files of two builds are identical.
> Because of string merge, the comparison has some trouble.
> 
> For example in case following code lines (may be in different files):
> ---
> const char* s_array[1]="s";
> const char *first_s="this first bigger s";
> const char *second_s="this second bigger s";
> ---
> 
> After clang build ELF out, sometimes the s_array[1] contail the position of 
> the tail of first_s in .rodata second, while sometimes second_s.
> This lead to .data section diff since s_array is in it.
> The ELF diffs, while nothing changed from functionality point of view.
> 
> Thanks.
> 
> -Original Message-
> From: hwennb...@google.com [mailto:hwennb...@google.com] On Behalf Of Hans 
> Wennborg
> Sent: Friday, July 6, 2018 3:54 PM
> To: Jian, Xu
> Cc: cfe-users@lists.llvm.org
> Subject: Re: [cfe-users] how clang merge strings in .rodata section
> 
> On Thu, Jul 5, 2018 at 3:18 AM, Jian, Xu via cfe-users 
>  wrote:
>> Hi,
>> 
>> The following c source code abc.c:
>> 
>> #include 
>> 
>> int g_val=10;
>> 
>> const char *g_str="abc";
>> 
>> const char *g_str1="c";
>> 
>> int main(void)
>> 
>> {
>> 
>>printf("%s %s: %d\n",g_str,g_str1,g_val);
>> 
>>return 0;
>> 
>> }
>> 
>> 
>> 
>> When compile with “clang abc.c -o abc” then dump .rodata section:
>> 
>> # readelf -p .rodata abc
>> 
>> 
>> 
>> String dump of section '.rodata':
>> 
>>  [ 0]  abc
>> 
>> [ 4]  %s %s: %d
>> 
>> 
>> 
>> When compile with “gcc abc.c -o abc” then dump .rodata section:
>> 
>> $ readelf -p .rodata abc
>> 
>> 
>> 
>> String dump of section '.rodata':
>> 
>>  [10]  abc
>> 
>>  [14]  c
>> 
>>  [16]  %s %s: %d^J
>> 
>> 
>> 
>> clang is able to merge short string (“c”) into the tail of a long 
>> string (“abc”), while gcc will not.
>> 
>> Does anybody know how to disable this behavior (make it similar to gcc) ?
> 
> I don't think there is a way to disable it.
> 
> Why do you want to disable this behaviour?
> 
> - Hans
> 
> --
> 
> Message: 3
> Date: Fri, 6 Jul 2018 11:01:25 +0200
> From: Hans Wennborg via cfe-users 
> To: "Jian, Xu" 
> Cc: "cfe-users@lists.llvm.org" 
> Subject: Re: [cfe-users] how clang merge strings in .rodata section
> Message-ID:
>   
> Content-Type: text/plain; charset="UTF-8"
> 
> On Fri, Jul 6, 2018 at 10:22 AM, Jian, Xu  wrote:
>> Hi Hans,
>> We need to compare whether ELF files of two builds are identical.
>> Because of string merge, the comparison has some trouble.
>> 
>> For example in case following code lines (may be in different files):
>> ---
>> const char* s_array[1]="s";
>> const char *first_s="this first bigger s";
>> const char *second_s="this second bigger s";
>> ---
>> 
>> After clang build ELF out, sometimes the s_array[1] contail the position of 
>> the tail of first_s in .rodata second, while sometimes second_s.
>> This lead to .data section diff since s_array is in it.
>> The ELF

Re: [cfe-users] Default compiler flags

[Matthew Fernandez via cfe-users]

This is probably something you have already considered but just to play devil’s 
advocate, could your needs be met by putting a script called “clang” in your 
users’ $PATH that simply does the following?

#!/usr/bin/env bash

/path/to/real/clang -march=broadwell "$@"

> On Sep 25, 2018, at 12:00, via cfe-users  wrote:
> 
> Date: Mon, 24 Sep 2018 21:53:49 -0500
> From: David Blaikie via cfe-users 
> To: Alexander Biddulph , Eric
>   Christopher 
> Cc: "cfe-users@lists.llvm.org" 
> Subject: Re: [cfe-users] Default compiler flags
> Message-ID:
>   
> Content-Type: text/plain; charset="utf-8"
> 
> Don't know of any quick way to do that in LLVM - I guess companies/folks
> who do this go into the source code in Clang's driver and mess with it.
> 
> - Dave
> 
> On Mon, Sep 17, 2018 at 10:10 PM Alexander Biddulph via cfe-users <
> cfe-users@lists.llvm.org> wrote:
> 
>> I am trying to compile clang/llvm to target a specific CPU architecture
>> (Intel Broadwell for instance). The intention here is that every time this
>> specific compiler is run it will only ever generate code for that specific
>> CPU.
>> 
>> To achieve this I would like to "bake-in" some command line arguments into
>> the built compiler (things like -march), but still allow the user to
>> provide extra command line arguments that may override the "baked-in"
>> defaults.
>> 
>> GCC provides a spec file to achieve this, but I can't find something
>> equivalent for clang/llvm. Does such a thing exist for clang/llvm?
>> ___
>> cfe-users mailing list
>> cfe-users@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users

___
cfe-users mailing list
cfe-users@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users

Re: [cfe-users] error: unknown target CPU 'pentium-m'

[Matthew Fernandez via cfe-users]

> On Oct 1, 2018, at 12:00, via cfe-users  wrote:
> 
> Date: Mon, 1 Oct 2018 21:41:23 +0300
> From: George Anchev via cfe-users 
> To: cfe-users@lists.llvm.org
> Subject: Re: [cfe-users] error: unknown target CPU 'pentium-m'
> Message-ID: <20181001214123.49bb8093@localhost>
> Content-Type: text/plain; charset=US-ASCII
> 
> Can anyone help please?
> 
> —
> George

It’s hard to guess what you’re doing or what your expected outcome is without 
seeing your command line, but perhaps you’re using -march?

$ clang -march=pentium-m main.c
error: unknown target CPU 'pentium-m’
$ clang -mtune=pentium-m main.c
$
___
cfe-users mailing list
cfe-users@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users

Re: [cfe-users] clang/llvm fails to vectorize a simple fill loop

[Matthew Fernandez via cfe-users]

> On Feb 4, 2019, at 04:47, via cfe-users  wrote:
> 
> Hi @all,
> 
> can anyone tell me, what is wrong with the following loop in Fill:
> 
> https://godbolt.org/z/hyZ2HO
> 
> Vectorization works for float, double and std::complex, but it fails 
> for std::complex.
> The remark "read with atomic ordering or volatile read" hints for something, 
> but neither do I know 
> exactly what, nor do I know how I can resolve the issue.

Just a guess, but sizeof(std::complex) == 16 on x86-64, so maybe 
something in the vectorization analysis decides (a) you can’t read a 16-byte 
value atomically with a SIMD instruction and (b) the source and destination may 
alias each other. This is sort of nonsensical because (b) is false and (a) 
shouldn’t factor into this decision. Maybe someone with more knowledge of the 
vectorizer can chime in.
___
cfe-users mailing list
cfe-users@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users

Re: [cfe-users] Linking error and memory bloating for .so file creation

[Matthew Fernandez via cfe-users]

> On Mar 7, 2019, at 00:24, Ankush Sharma via cfe-users 
>  wrote:
> 
> Hi Team,
>  
> During the linking stage for an “.so” file creation, an error message is 
> being flagged by clang.
> ld: error: dummy.so: write: Function not implemented
>  
> I'm not able to make a sense out of this message as it seems different from 
> an "undefined reference" error. There are multiple occurrence of this message 
> during the linking process.
> Also the linking doesn’t complete and the output “.so” keeps on bloating 
> reaching size upto 1TB or 100s of GB. Manual termination is required to stop 
> this process.
> 
> Any leads would be appreciated. 

Just a guess, but perhaps this is not a linking error at all. This looks to me 
like ld calling write() and the call itself returning ENOSYS. Is there 
something unusual about the filesystem you’re writing dummy.so to? If the write 
fails but the file size also increases, I wonder if what you’re seeing is some 
sort of I/O error. Anything exciting in dmesg and friends?___
cfe-users mailing list
cfe-users@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users

Re: [cfe-users] how to verify downloads without public key?

[Matthew Fernandez via cfe-users]

> On Apr 12, 2019, at 04:10, Larry Evans via cfe-users 
>  wrote:
> 
> I've just downloaded:
> 
> http://releases.llvm.org/8.0.0/clang+llvm-8.0.0-x86_64-linux-gnu-ubuntu-18.04.tar.xz
> http://releases.llvm.org/8.0.0/clang+llvm-8.0.0-x86_64-linux-gnu-ubuntu-18.04.tar.xz.sig
> 
> but when I tried to verify the download with:
> 
> gpg2 --verify clang+llvm-8.0.0-x86_64-linux-gnu-ubuntu-18.04.tar.xz.sig 
> clang+llvm-8.0.0-x86_64-linux-gnu-ubuntu-18.04.tar.xz
> 
> I got:
> 
> gpg: enabled debug flags: memstat
> gpg: Signature made Thu 21 Mar 2019 03:34:38 AM CDT
> gpg:using RSA key B6C8F98282B944E3B0D5C2530FC3042E345AD05D
> gpg: Can't check signature: No public key
> 
> How can I verify the download without a public key?

GPG needs to learn the public key of the signer first. You can retrieve this 
using the ID given on the downloads page:

gpg2 --recv-keys 345AD05D
___
cfe-users mailing list
cfe-users@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users

Re: [cfe-users] __builtin_constant_p(), __builtin_expect() and __builtin_types_compatible_p() and __has_builtin()

[Matthew Fernandez via cfe-users]

> On Aug 9, 2019, at 05:23, Chris Hall via cfe-users  
> wrote:
> 
> 
> I find that __builtin_constant_p() works as expected, but 
> __has_builtin(constant_p) denies it !

I believe you need __has_builtin(__builtin_constant_p).

> 
> Similarly __builtin_expect() and __builtin_types_compatible_p() !
> 
> Can I just assume these are all supported by all version of clang ?
> 
> Chris
> ___
> cfe-users mailing list
> cfe-users@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users

___
cfe-users mailing list
cfe-users@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users

Re: [cfe-users] __builtin_constant_p(), __builtin_expect() and __builtin_types_compatible_p() and __has_builtin()

[Matthew Fernandez via cfe-users]

> On Aug 9, 2019, at 14:58, Richard Smith via cfe-users 
>  wrote:
> 
> On Fri, 9 Aug 2019 at 10:32, Chris Hall via cfe-users 
> mailto:cfe-users@lists.llvm.org>> wrote:
> On 09/08/2019 15:00, Matthew Fernandez wrote:
> >> On Aug 9, 2019, at 05:23, Chris Hall via cfe-users wrote:
> >>
> >> I find that __builtin_constant_p() works as expected, but 
> >> __has_builtin(constant_p) denies it !
> 
> > I believe you need __has_builtin(__builtin_constant_p).
> 
> Ah :-(  So you do... sorry... I have no idea why I thought otherwise :-(
> 
> >> Similarly __builtin_expect() and __builtin_types_compatible_p() !
> 
> Except that __has_builtin(__builtin_types_compatible_p) also denies it.
> 
> #include 
> 
> int
> main(int argc, char* argv[])
> {
>   printf("__has_builtin(__builtin_types_compatible_p)=%d\n"
>"__builtin_types_compatible_p(int, int)=%d\n"
>"__builtin_types_compatible_p(int, long)=%d\n",
>   __has_builtin(__builtin_types_compatible_p),
> __builtin_types_compatible_p(int, int),
> __builtin_types_compatible_p(int, long)) ;
> }
> 
> outputs:
> 
> __has_builtin(__builtin_types_compatible_p)=0
> __builtin_types_compatible_p(int, int)=1
> __builtin_types_compatible_p(int, long)=0
> 
> I hope I haven't missed something blindingly obvious this time.
> 
> This is a historical accident.
> 
> __has_builtin detects builtin *functions*. We also have a bunch of things 
> that start with __builtin and look somewhat like functions, but that take 
> types as arguments so can't actually be functions -- instead, they're 
> keywords with custom parsing rules. __has_builtin doesn't detect those 
> (because they're not builtin functions).
> 
> We've fixed this for such things we added recently, such as 
> __builtin_bit_cast and __builtin_FILE, but the older ones like 
> __builtin_types_compatible_p and __builtin_choose_expr and __builtin_offsetof 
> are unfortunately not detectable by __has_builtin.
> 
> There is another way to detect these: use 
> !__is_identifier(__builtin_types_compatible_p). That will evaluate to 1 
> whenever __builtin_types_compatible_p is not a valid identifier (because it's 
> a keyword) -- that is, whenever the feature is available. However, 
> __is_identifier was added in April 2014, and nearly all the builtins that 
> __has_builtin can't detect are older than that. So this technique isn't 
> really useful.

This thread taught me something too, thanks :) The __is_identifier trick seems 
even more tricky to use than this implies. E.g. it returns true for 
__builtin_constant_p because that one is implemented as a function, as you 
describe. Does this mean to fully detect support for __builtin_foo I need 
something like `__has_builtin(foo) || __has_builtin(__builtin_foo) || 
!__is_identifier(__builtin_foo)`?

While we’re on this topic, are the semantics of __is_identifier just “is not a 
keyword”? I ask because even when it returns true for a __-prefixed symbol, 
it’s not an indication you can use it in user code because it’s still reserved 
for use by the implementation. In fact __is_identifier even returns true for 
itself, which I guess is technically correct.

> In practice, every version of Clang from the past 10 years supports 
> __builtin_types_compatible_p (in C mode). So you can just assume it exists.

This is what I do too, as it’s widely supported back to every reasonable 
version of GCC as well.___
cfe-users mailing list
cfe-users@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users

Re: [cfe-users] Porting preprocessor macros to be compatible with clang

[Matthew Fernandez via cfe-users]

> On Aug 20, 2019, at 07:27, Forumer 4umer via cfe-users 
>  wrote:
> 
> Hello,
> 
> I am sorry to ask for some help on this subject but I am not very comfortable 
> with preprocessor and especially with the differences between compilers.
> We have some (ugly) macros used to generate some data structures and methods 
> that works fine on Visual but I would like to use clang to get better errors 
> messages
> and to compare the compilation time.
> So I have created a repository to reproduce the problem and if someone could 
> give me some help...
> There is only one cpp file so a simple clang++ TestClang.cpp is enough to 
> reproduce.
> The repository is here: https://github.com/vrichomme/FixMacroOnClang.git 
> 

I think you’re going to have to give us more information about what the problem 
is that you’re seeing and what is the behaviour you expected.___
cfe-users mailing list
cfe-users@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users

Re: [cfe-users] Porting preprocessor macros to be compatible with clang

[Matthew Fernandez via cfe-users]

> On Aug 21, 2019, at 05:36, Forumer 4umer via cfe-users 
>  wrote:
> 
> So a bit more explanation, the macros are used to generate data structure and 
> methods and the following definition is used to declare a structure:
> 
> DEF_STRUCT(namedDate, namedDate, (std::string, name), (std::time_t, date))
> 
> On visual when I look at preprocessed file I get this (focus on line starting 
> with struct namedDate) :
> 
> namespace LibTech
> {
>   namespace DataTypes
>   {
>  #line 1 "E:\\DEV\\FixMacroOnClang\\DeclareDatatypes.h"
>  #line 17 "E:\\DEV\\FixMacroOnClang\\DeclareDatatypes.h"
>  #line 12 "E:\\DEV\\FixMacroOnClang\\Protocol.h"
>  #line 1 "E:\\DEV\\FixMacroOnClang\\DataTypesDef.h"
> 
> struct namedDate{ std::string name; std::time_t date; };
> 
>  #line 13 "E:\\DEV\\FixMacroOnClang\\Protocol.h"
>  #line 1 "E:\\DEV\\FixMacroOnClang\\DeclareDatatypes.h"
> #line 1 "E:\\DEV\\FixMacroOnClang\\macro\\UndefDataTypesDef.h"
> #line 14 "E:\\DEV\\FixMacroOnClang\\DeclareDatatypes.h"
> #line 17 "E:\\DEV\\FixMacroOnClang\\DeclareDatatypes.h"
> #line 14 "E:\\DEV\\FixMacroOnClang\\Protocol.h"
>   }
> 
> }
> 
> but when using clang I have this:
> 
> namespace LibTech
> {
>   namespace DataTypes
>   {
>  # 1 "E:\\DEV\\FixMacroOnClang/DeclareDatatypes.h" 1
>  # 12 "E:\\DEV\\FixMacroOnClang/Protocol.h" 2
>  # 1 "E:\\DEV\\FixMacroOnClang/DataTypesDef.h" 1
> 
> struct namedDate{ PP_GS 2 (TO_FIELD, (std::string, name), (std::time_t, 
> date)) };
> 
>  # 13 "E:\\DEV\\FixMacroOnClang/Protocol.h" 2
>  # 1 "E:\\DEV\\FixMacroOnClang/DeclareDatatypes.h" 1
>  # 13 "E:\\DEV\\FixMacroOnClang/DeclareDatatypes.h"
>  # 1 "E:\\DEV\\FixMacroOnClang/./macro/UndefDataTypesDef.h" 1
>  # 14 "E:\\DEV\\FixMacroOnClang/DeclareDatatypes.h" 2
>  # 14 "E:\\DEV\\FixMacroOnClang/Protocol.h" 2
> }
> }
> 
> as you can see the macros used inside preprocessor.h doesn't work with clang 
> I have macro PP_GS and TO_FIELD macros that are not expanded.
> 
> I cannot copy/paste all macro definitions because it won't be very easy to 
> read but here is how it starts:
> 
> #ifndef DEF_ID_BEGIN
> 
> //...
> 
> #define TO_FIELD(type, name) type name;
> #define DEF_STRUCT(type, dataTypeId, ...) struct type{ 
> PP_FOREACH_GROUP(TO_FIELD,__VA_ARGS__) };
> 
> #else
> 
> #include "./macro/UndefDataTypesDef.h"
> #undef TO_FIELD
> 
> #endif
> 
> and inside preprocessor.h
> 
> #define PP_PREFIX(Method) PP_##Method
> #define PP_SUFFIX(N) N
> #define PP_ENTRY(Method,N) PP_PREFIX(Method)PP_SUFFIX(N)
> #define PP_CALL_PP_SN( Method, Func, N, ...) PP_ENTRY(Method,N) PP_FW(Func, 
> __VA_ARGS__)
> 
> #define PP_FOREACH(Func, ...) PP_CALL_PP_SN( S, Func, PP_ARGCOUNT 
> PP_FW(__VA_ARGS__), __VA_ARGS__ )
> #define PP_FOREACH_GROUP(Func, ...) PP_CALL_PP_SN( GS, Func, PP_ARGCOUNT 
> PP_FW(__VA_ARGS__), __VA_ARGS__ )
> 
> 
> #define PP_RSEQ_N()\
> 63 ,62 ,61 ,60 ,\
> 59 ,58 ,57 ,56 ,55 ,54 ,53 ,52 ,51 ,50 ,\
> 49 ,48 ,47 ,46 ,45 ,44 ,43 ,42 ,41 ,40 ,\
> 39 ,38 ,37 ,36 ,35 ,34 ,33 ,32 ,31 ,30 ,\
> 29 ,28 ,27 ,26 ,25 ,24 ,23 ,22 ,21 ,20 ,\
> 19 ,18 ,17 ,16 ,15 ,14 ,13 ,12 ,11 ,10 ,\
> 9,8,7,6,5,4,3,2,1,0
> 
> #define PP_ARG_N( \
> _1  ,_2  ,_3  ,_4  ,_5  ,_6  ,_7  ,_8  ,_9  ,_10 ,\
> _11 ,_12 ,_13 ,_14 ,_15 ,_16 ,_17 ,_18 ,_19 ,_20 ,\
> _21 ,_22 ,_23 ,_24 ,_25 ,_26 ,_27 ,_28 ,_29 ,_30 ,\
> _31 ,_32 ,_33 ,_34 ,_35 ,_36 ,_37 ,_38 ,_39 ,_40 ,\
> _41 ,_42 ,_43 ,_44 ,_45 ,_46 ,_47 ,_48 ,_49 ,_50 ,\
> _51 ,_52 ,_53 ,_54 ,_55 ,_56 ,_57 ,_58 ,_59 ,_60 ,\
> _61 ,_62 ,_63 ,  N , ...) N
> 
> #define PP_FW(...) (__VA_ARGS__)
> #define PP_NARG_(...) PP_ARG_N PP_FW(__VA_ARGS__)
> #define PP_ARGCOUNT(...) PP_NARG_(__VA_ARGS__,PP_RSEQ_N())
> 
> but have a look here to see all the macros: 
> https://github.com/vrichomme/FixMacroOnClang/blob/master/preprocessor.h
> 
> Maybe one of the problem is with PP_FW(...) but not sure about that…

It seems like there are two problems: (1) TO_FIELD comes out with a trailing 
comma and so does not get expanded and (2) PP_GS and 2 tokens are not joined 
which would also impeded further expansion. I would expect to see a further ## 
somewhere in your macros. It looks like you’re using [0] when maybe you want 
something more like [1]?

  [0]: https://groups.google.com/forum/#!topic/comp.std.c/d-6Mj5Lko_s 

  [1]: 
https://stackoverflow.com/questions/11761703/overloading-macro-on-number-of-arguments
 


___
cfe-users mailing list
cfe-users@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users

Re: [cfe-users] Clang9 UBSan and GMP

[Matthew Fernandez via cfe-users]

Hans, it’s challenging to give sensible advice/guesses without knowing which 
test is failing. Maybe I missed this information in the replies (please CC the 
list if you want follow up answers from more than just David). I am not a GMP 
developer, but note that GMP is regularly tested with ubsan and results are 
included at https://gmplib.org/devel/tm/gmp/date.html 
.

> On Oct 25, 2019, at 15:32, David Blaikie via cfe-users 
>  wrote:
> 
> UBSan doesn't catch everything - you could also try ASan and/or valgrind, 
> etc. (MSan if you want, but that's a bit fussier/more work to use)
> 
> On Fri, Oct 25, 2019 at 3:16 PM Hans Åberg  > wrote:
> That is the reason I tried the UBSan, but as it changes optimization, it does 
> not wrok.
> 
> 
> > On 26 Oct 2019, at 00:14, David Blaikie  > > wrote:
> > 
> > Yeah, coming across compiler bugs does happen - but more often it's bugs in 
> > input programs. (one of the reasons compiler engineers aren't likely to 
> > jump on reproducing and reducing misbehaving programs, because on the odds, 
> > it's not a bug in the compiler)
> 
> ___
> cfe-users mailing list
> cfe-users@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users

___
cfe-users mailing list
cfe-users@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users

Re: [cfe-users] Clang9 UBSan and GMP

[Matthew Fernandez via cfe-users]

> On Oct 31, 2019, at 14:30, Hans Åberg via cfe-users 
>  wrote:
> 
>> 
>> On 31 Oct 2019, at 22:07, David Blaikie  wrote:
>> 
>>> On Thu, Oct 31, 2019 at 1:51 PM Hans Åberg  wrote:
>>> 
 On 31 Oct 2019, at 21:40, David Blaikie  wrote:
 
 Such that it's not practical for the compiler developers to do all the leg 
 work of investigating 3rd party code bugs to determine if it's a bug in 
 the compiler. It doesn't scale/we wouldn't have any time to work on the 
 compiler & most of the time we'd be finding user bugs, not compiler bugs.
>>> 
>>> The GMP developers feel exactly the same, dropping Clang support. It is 
>>> mostly a problem for MacOS users that do not have access to GCC.
>> 
>> Yep, that's certainly their call - there's a cost to maintaining 
>> compatibility with each compiler/toolchain/platform, etc.
> 
> Yes, it involves hard study of the various CPUs used.
> 
>> If you have a personal interest in GMP on MacOS, then perhaps the cost falls 
>> to you, if you're willing to pay it, to investigate this sort of thing & 
>> help support this particular library+compiler combination, if it's worth 
>> your time to do so.
> 
> Both GCC and Clang can be conveniently installed using MacPorts. The Apple 
> inhouse clang is weird.

I haven’t followed the rest of this thread closely, but do you have a reference 
for the GMP developers abandoning Clang on macOS? Or were you referring to 
their comment about Clang on the page I linked? Personally I regularly use GMP 
with a macOS-supplied Clang without any issues. Admittedly not for any extreme 
numerical computation, but my experience is that GMP works fine in this 
scenario.___
cfe-users mailing list
cfe-users@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users

Re: [cfe-users] clang sparc backend

[Matthew Fernandez via cfe-users]

> On May 1, 2020, at 21:57, suyash singh via cfe-users 
>  wrote:
> 
> does clang support sparc backend?
>  
> I tried " clang -target sparc " to compile a simple c program on 
> ubuntu(x86_64), clang detects sparc as a valid target but does not work with 
> it. 
> 
> /usr/bin/as: unrecognized option '-Av8'
> clang-11: error: assembler command failed with exit code 1
> 
> How can I get clang to work with sparc?

I don’t have a toolchain with Sparc support to test this, but you could try the 
integrated assembler, `clang -integrated-as …`
___
cfe-users mailing list
cfe-users@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users

Re: [cfe-users] Are these bugs for the clang compilers?

[Matthew Fernandez via cfe-users]

Hi Tianyou,

I am not enough of a physicist to know what “the qualification of the ground 
state energy in a quantum system” means, but this does not sound like a Clang 
bug to me. You did not say whether `a` in your example is a float or a double, 
but the minimum legal values for these types are the constants FLT_MIN and 
DBL_MIN. There is no need to try to compute them. Exceeding the range of values 
representable in a type — [FLT_MIN, FLT_MAX] or [DBL_MIN, DBL_MAX] — is 
undefined behavior, so the compiler is free to emit anything.

Thanks,
Matt

> On May 26, 2020, at 20:31, Tianyou via cfe-users  
> wrote:
> 
> Hello everyone,
> I found some questionable behaviors in the clang compiler.
> I tried to calculate the smallest number in my machine with clang. I did it 
> by looping as: 
> a = a / 1.73
> In g++, after 1358 loops, I found that a = 4.94066E-324, and the value of a 
> never changes from loop 1358 till the end 1500 loop.
> It is questionable for me that a non zero real number here a = 4.94066E-324 
> divided by a non zero and non one real number here 1.73 will keep the same 
> value. The phenomenon seems to the qualification of the ground state energy 
> in a quantum system.
> Is this bug for the clang compiler?
> I tested my code with, g++ (Apple LLVM version 10.0.0, clang-1000.10.44.4) on 
> Macintosh. I also tried a = a / 1.7, a = a / 1.77. 
> All have similar results. A ground state qualification and unchanged value of 
> a. 
> I guess that it is related to the binary system used by the computer system. 
> Here with my codes. 
> 
> Best wishes
> Tianyou Yi
> Postdoc researcher in National Tsing Hua University
> 
> Best wishes
> Tianyou Yi 
> Please send me to 
> yitianyo...@qq.com
> yitianyou9...@gzemail.cn
> 
> 
>  
> ___
> cfe-users mailing list
> cfe-users@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users

___
cfe-users mailing list
cfe-users@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users

Re: [cfe-users] Problem with installing clang-3.8.0

[Matthew Fernandez via cfe-users]

Hi,

Clang 3.8 is not available in the Ubuntu 20.04 repositories [0], so I guess you 
must have added a PPA or other source to get this. It would seem your source 
that is providing clang-3.8 does not also provide all its dependencies.

Thanks,
Matt

  [0]: 
https://packages.ubuntu.com/search?keywords=clang-3.8&searchon=names&suite=all§ion=all

> On May 26, 2020, at 23:02, Kwiatek, Michal (Nokia - PL/Wroclaw) via cfe-users 
>  wrote:
> 
> Hi,
> I have troubles with installing clang 3.8.0
> I am able to install versions such as 6.0 or 10 but I cannot install 3.8.0
> When I write: `sudo apt-get install clang-3.8.0` I get following message 
> (screen included)
> 
> 
> Os version: Ubuntu 20.04
>  08-02-28.png>___
> cfe-users mailing list
> cfe-users@lists.llvm.org 
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users 
> 
___
cfe-users mailing list
cfe-users@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users

Re: [cfe-users] Cannot build Clang etc. on Windows in Debug Mode

[Matthew Fernandez via cfe-users]

> On Jul 6, 2020, at 07:28, Oliver Niebuhr via cfe-users 
>  wrote:
> 
> Hello List.
> 
> I hope I have subscribed to the correct List - there are a lot of them :)
> 
> My Problem is:
> Since the last 2.5 Weeks I try to compile Clang Release/10.x in Debug
> Mode. Unfortunately the build always ends with those last Lines:

I think the list you’re after is cfe-dev: 
https://lists.llvm.org/mailman/listinfo/cfe-dev
___
cfe-users mailing list
cfe-users@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users

Re: [cfe-users] Making private types public

[Matthew Fernandez via cfe-users]

> On Jan 3, 2021, at 16:12, Volker Weißmann via cfe-users 
>  wrote:
> 
> Hello,
> 
> If you define a type privately (or protected) like this:
> 
> class c {
> 
> class priv{};
> 
> };
> 
> then the writing "c::priv" outside of the class c will generate the error 
> "'class c::priv' is private within this context". This is really bad for me, 
> because I'm currently writing a tool that generates Rust-C++ wrappers. I'm 
> thinking of writing a PR, that would add a command line option to clang that 
> would make clang treat all type definitions as if there would be a "public:" 
> in front of them. I'm asking if anyone wants to tell me that this is a bad 
> idea or wants to give me advice.

Maybe I misunderstand your use case, but if you’re generating the C++ why not 
just generate the inner type as accessible?

class c {

  public:
class no_longer_priv{};
};
___
cfe-users mailing list
cfe-users@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users

Re: [cfe-users] Locally built clang on macOS 10.15.7

[Matthew Fernandez via cfe-users]

> On Mar 11, 2021, at 02:27, Mark Jamsek via cfe-users 
>  wrote:
> 
> I checked out and built clang as per the docs Getting Started page[0].
> 
> When using clang, however, compilation of C and C++ projects fail to
> find the needed headers from their respective standard libraries.
> 
> I can get around this in C projects by setting the environment variable
> SDKROOT[1], and for C++ projects by setting the CPLUS_INCLUDE_PATH[2]…

Unfortunately I don’t have an answer for you and I suspect overriding 
environment variables is not the way to go, but to add to your bag of tricks 
C_INCLUDE_PATH also works for C and C++.
___
cfe-users mailing list
cfe-users@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users

Re: [cfe-users] Issue with clang-13

[Matthew Fernandez via cfe-users]

> On Dec 24, 2021, at 06:45, Csaba Raduly via cfe-users 
>  wrote:
> 
> Hi Sunil,
> 
> On Fri, 24 Dec 2021 at 14:51, Sunil Kumar via cfe-users
> mailto:cfe-users@lists.llvm.org>> wrote:
>> 
>> Hi,
>> I tried many times to install clang-13 in ubuntu-16.04. I followed the steps 
>> mentioned below.
>> 
>> git clone https://github.com/llvm/llvm-project.git
>> git checkout llvmorg-13.0.0
>> cd llvm-project
>> mkdir build
>> cd build
>> cmake -DLLVM_ENABLE_PROJECTS=clang -G "Unix Makefiles" ../llvm
>> make
>> 
>> After running make command, it failed to install clang eventually and showed 
>> some error mentioned below
>> 
>> make:342: recipe for target 'bin/clang-13' failed
>> make[2]: *** [bin/clang-13] Error 1
>> make[2]: *** Deleting file 'bin/clang-13' CMakeFiles/Makefile2:38992: recipe 
>> for target 'tools/clang/tools/driver/CMakeFiles/clang.dir/all' failed
>> make[1]: *** [tools/clang/tools/driver/CMakeFiles/clang.dir/all] Error 2
>> collect2: fatal error: ld terminated with signal 9 [Killed] compilation 
>> terminated.
>> -
>> Please help to resolve this bug.
> 
> It's not a bug in clang if you kill the linker program.
> 
> If it wasn't you who killed the linker program, perhaps it was the
> out-of-memory killer. You can try to solve the out-of-memory issue:
> 
> 1. Buy more memory for your computer, or
> 2. Delete the build directory, create it again, then add
> -DCMAKE_BUILD_TYPE=Release to the cmake command line, and build again.
> Debug builds require more memory, because of the large amount of debug
> info. Hopefully the release build will not run into out-of-memory.
> 
> Are you using a 32-bit system by any chance?

You could also try -DLLVM_USE_SPLIT_DWARF=ON to cmake. This and some other 
options to explore at https://www.llvm.org/docs/CMake.html 
.

___
cfe-users mailing list
cfe-users@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users

Re: [cfe-users] Issue with clang-13

[Matthew Fernandez via cfe-users]

> On Dec 24, 2021, at 09:56, Sunil Kumar  wrote:
> 
> Thanks Matthew. I am using the x86_64 system.
> I wanted to ask you one more question. After installing clang, how to install 
> openmp with the OMPT tool interface in clang-13. 

Sorry, this is something I am not familiar with. I thought openmp support was 
enabled by default. At least, I don’t recall ever having to explicitly enable 
it in the past. Perhaps someone else on the list can help.___
cfe-users mailing list
cfe-users@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users

Re: [cfe-users] Compile from source code string

[Matthew Fernandez via cfe-users]

> On Jan 17, 2022, at 14:35, 0dminnimda via cfe-users 
>  wrote:
> 
> I wanna use regular functionality of clang but instead of passing path to the 
> source I want to pass string as source code. Yes, it's preferably a code that 
> uses clang api and not just call to clang with source that was put into 
> input, as source files are usually big.
> Googled that, but not really successfully.
> No good source of info about that or code that's outdated.
> Would really appreciate any help.

The phrase “clang api” is a bit vague (libclang?), but it is possible to feed 
the compiler strings on the command line if you teach it the input language:

$ echo 'int main(void) { return 0; }' | clang -x c -

Hope this helps.
___
cfe-users mailing list
cfe-users@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users

Re: [cfe-users] Compile from source code string

[Matthew Fernandez via cfe-users]

> On Jan 17, 2022, at 21:59, 0dminnimda <0dminni...@gmail.com> wrote:
> 
> > The phrase “clang api” is a bit vague (libclang?)
> 
> If it's possible, then of course LibClang as it's backward compatible, but I 
> know that it's restricted in functionality, so if LibClang don't give such 
> freedom, then LibTooling.
> 
> > $ echo 'int main(void) { return 0; }' | clang -x c -
> 
> Thanks for the advice! This should work on unix, but what's about other 
> systems? That's why I wanted to go with code, because I target at least 
> Linux, Macos and Windows, and with code solution it'll be no different to 
> support all of them as well as it'll be bit more secure, I think.

I can’t see anything promising in libclang, but maybe runToolOnCode in 
libtooling might achieve what you’re after.
___
cfe-users mailing list
cfe-users@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users