Re: [cfe-users] -Winvalid-noreturn warning

[David Blaikie via cfe-users]

FWIW, GCC does warn on similar code - the reason it doesn't warn here is
that the function is `inline` and never called, so GCC probably never
analyses it (I pasted your code here and added a few cases to demonstrate
GCC's quirks compared to Clang's here: https://godbolt.org/z/YM9q91bx1 )

So far as I can tell, noreturn isn't carried on function types, so it isn't
possible to do what you want at the moment. That's my rough understanding,
at least.

On Thu, Jan 6, 2022 at 5:23 PM Manu agarwal via cfe-users <
cfe-users@lists.llvm.org> wrote:

> Hi,
>
> We have the below code where this warning gets generated.
>
> #include
>
>
>
> [[noreturn]] inline void
>
> abc () noexcept
>
> {
>
> std::terminate ();
>
> }
>
>
>
> using MyNoReturn = void (*) () noexcept;
>
>  //using MyNoReturn = std::add_pointer_t;*// even this
> declaration, instead of the above, gives the same warning*
>
>
>
> [[noreturn]]
>
> inline void IDontReturn () noexcept
>
> {
>
> std::terminate ();
>
> }
>
>
> static MyNoReturn   gvar {IDontReturn};
>
>
>
> [[noreturn]]
>
> inline void
>
> CallIDontReturn () noexcept
>
> {
>
> gvar (); // *here is where clang
> gives warning: function declared 'noreturn' should not return
> [-Winvalid-noreturn]*
>
> }
>
> We have the used the below command to compile:
> clang++ -std=c++17 -Wall -o runusing usingst.cpp
>
> gcc does not show this warning.
>
> Please let us know how we can use 'using' clause to declare function
> pointer to a function that does not return, so that this warning does not
> show up.
>
> Regards,
> Manu
> ___
> 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] (bug?) ParsedAttr::getNumArgs() always return zero

[David Blaikie via cfe-users]

I'm /guessing/ this API doesn't respond with attributes clang doesn't
recognize (CC'd Aaron Ballman who would likely know the details better than
I do). Does the API correctly respond with a non-zero number of attributes
for any clang-supported attribute (listed here:
https://clang.llvm.org/docs/AttributeReference.html )

On Thu, Dec 2, 2021 at 5:23 AM Владимир Фролов via cfe-users <
cfe-users@lists.llvm.org> wrote:

> Dear colleguaes, it seems i have met the bug for processing of C++11
> custom language attributes.
>
> 1) I took example from
> https://github.com/llvm/llvm-project/blob/main/clang/examples/Attribute/Attribute.cpp
> 2) And make a short sample which reproduce the bug
> https://github.com/FROL256/clang_parse_ast_example
>
> The problem in that getNumArgs() is always zero, nevermind how many
> arguments we actually have in the attribute.
> I have tested this with clang 12. I think i could test it under clang 14
> if build sample as a part of llvm.
> But probably i just did some-thing wrong ... ?
>
> Anyway it would be nice to have this issue working with clang 12 because
> usually i work with prebuild packages of clang and libtooling on Linux Mint.
> Could you please look prepared sample and suggest sms if possible ...
> thanks! )
> --
> Best Regards,
>  Frolov V.A.
>
> ___
> 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] Clang (with Visual Studio) wrongly complains about missing variables

[David Blaikie via cfe-users]

On Thu, Sep 23, 2021 at 3:34 AM John Emmas via cfe-users <
cfe-users@lists.llvm.org> wrote:

> On 22/09/2021 18:21, Reid Kleckner via cfe-users wrote:
> > Looking back in the thread, I found the example code, and I see that
> > MSVC refuses to inline this helper, but clang will inline it. I
> > believe clang is permitted to inline it, MSVC will export the static
> > data member (_the_keyboard), so everything should work as long as you
> > provide a definition of _the_keyboard in the DLL and set -DBUILDING_DLL.
> >
>
> Thanks for coming in on this, Reid. As Jeff suggested, I transferred the
> question to llvm-dev where there's a small discussion going on now.  I
> must admit though, my personal view is that declaring something as
> __declspec(dllimport) should automatically exclude it from being inlined
> (I'm pretty sure that's what Microsoft itself does...)
>
> Ultimately, the main advantage of a DLL is that it offers dynamic
> linkage. In other words, DLL features can be updated simply by updating
> the DLL (i.e. without needing to update all the apps which use it). In
> the dim old days this could lead to something called "DLL Hell" but
> WinSxS has largely consigned that to history now.  So whilst inlining
> code from a DLL might seem like a good idea, it throws away the main
> advantage of DLL's without offering anything better.
>

Presumably it offers the benefit of inlining optimizations - so there's
probably some execution speed improvement to tradeoff. (& a way the user
can address the issue by moving functions out of line)

Over on llvm-dev I'm trying to persuade them that declaring something as
> __declspec(dllimport) should automatically exclude it from being
> inlined.  And to be honest, I'd be quite surprised if that's not what
> Microsoft intended.
>

I think if it's clearly demonstrated that that's Microsoft's implementation
- that no matter how hard you ask it to optimize and how simple the
function is, that it won't inline a dllexported function that's inline in a
header (both implicitly inline in a class definition, and probably check
the case of a standalone dllexported inline non-member function in a
header) that I'd say (though I have little sway/weight in this design
decision) clang-cl should implement the same behavior, because it is
observable/can be relied upon as you have (though also - dllexported
variables should be defined somewhere, generally) & an opt-in flag to what
is the current behavior (dllexport-inlining).

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

Re: [cfe-users] Clang (with Visual Studio) wrongly complains about missing variables

[David Blaikie via cfe-users]

Probably Reid and Hans are folks to start with for Windows support

On Wed, Sep 22, 2021 at 4:38 AM Jeffrey Walton via cfe-users <
cfe-users@lists.llvm.org> wrote:

> On Wed, Sep 22, 2021 at 7:21 AM John Emmas via cfe-users
>  wrote:
> >
> > On 21/09/2021 14:24, John Emmas via cfe-users wrote:
> > >
> > > clang-cl /? reveals that it'll handle the Microsoft variant of /Ob0
> > > ...
> > All the signs here are that Clang is still trying to inline stuff - even
> > when it's been told not to... so is there some way I could check if it
> > responds correctly to "/Ob0"?  Maybe ask a question on cfe-dev ?
>
> LLVM dev would probably be a good place to bring up the topic.
>
> Several people work on the Windows port. There's one person in
> particular who does most of the heavy lifting (but I don't recall the
> person's name). LLVM dev is where to find the people.
>
> Jeff
> ___
> 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] Clang (with Visual Studio) wrongly complains about missing variables

[David Blaikie via cfe-users]

I'm not sure it's the right/necessary solution, but one way would be to
move the function definition (for the_keyboard) out of line (define it in
some .cpp/.cc/whatever file, not in the header) - if you don't want it to
be inlined.

On Mon, Sep 20, 2021 at 6:56 AM John Emmas via cfe-users <
cfe-users@lists.llvm.org> wrote:

> On 20/09/2021 12:36, John Emmas via cfe-users wrote:
> >
> > But if I switch VS2019 to use Clang (when building the EXE) Clang's
> > linker will complain that it can't find the variable 'revision_num'.
> > But of course, 'revision_num' is an internal variable that's private
> > to the DLL [...] - so is there maybe some linker option that'll tell
> > Clang to ignore variables if the code never needs access to them?
> >
>
> Another possibility just occurred to me...  here's a real-world example
> from our code:-
>
> #if defined (BUILDING_DLL)
>#define DLL_API __declspec(dllexport)
> #else
>#define DLL_API __declspec(dllimport)
> #endif
>
> namespace Gtkmm2ext {
>
>class DLL_API Keyboard
>{
>  public:
>Keyboard ();
>~Keyboard ();
>
>static Keyboard& the_keyboard() { return *_the_keyboard };
>
>  protected:
>static Keyboard* _the_keyboard;
>};
>
> } /* namespace */
>
> The above example is from a DLL but when I try to build the
> corresponding EXE, Clang's linker complains that it can't find
> '_the_keyboard' - so did the compiler (maybe) implement its call to
> 'the_keyboard()' as inline code, rather than importing it from the DLL?
> Maybe for very simple code like this, Clang will try to be clever and
> implement stuff inline if it can?  And if so, is there some way to turn
> off that feature?  Thanks,
>
> John
> ___
> 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] [cfe-dev] Removing or obfuscating RTTI type name strings

[David Blaikie via cfe-users]

On Fri, Sep 3, 2021 at 2:55 PM Richard Smith via cfe-dev <
cfe-...@lists.llvm.org> wrote:

> On Fri, 27 Aug 2021 at 11:03, Andy Gibbs via cfe-users <
> cfe-users@lists.llvm.org> wrote:
>
>> Hi there,
>>
>> I'm hitting a rather difficult problem.  I have to compile with RTTI data
>> structures generated because, even though I am not using dynamic_cast or
>> typeid in my application code, I am linking and using a library that does
>> use dynamic_cast.  Therefore my code will crash if I compile with -fno-rtti.
>>
>> The problem is, then, that the size of my code is greatly increased, and
>> also (which is more important) critical information is being leached into
>> the resulting application binary by the RTTI type name string that is
>> generated.  Unlike normal symbols, these cannot be stripped from the
>> executable.
>>
>> Therefore I would like to make a change to the clang compiler to either
>> replace all the type name strings with a single "?" string (this would be
>> best) or doing something like a rot-x encryption on the complete string (I
>> would rather not do this since these strings are literally hundreds of
>> characters long given that the types are complex template types).
>>
>> My suggestion would be that I would attempt to add a -fno-rtti-names
>> parameter.  If this is of interest to the general clang community I would
>> be happy to submit a patch for consideration, but at the very least I need
>> something for my own purposes.
>>
>> This brings me to my request.  I would be very grateful if someone here
>> might be able to direct me into the right place for making such a change.
>>
>> Looking at the source code there is a
>> ItaniumRTTIBuilder::BuildTypeInfo(...) function in
>> CodeGen/ItaniumCXXABI.cpp (see
>> https://github.com/llvm/llvm-project/blob/fe177a1773e4f88dde1aa37d34a0d3f8cb582f14/clang/lib/CodeGen/ItaniumCXXABI.cpp#L3730).
>> In there, the first thing it does is lay down a field for the mangled type
>> name.  My guess is that it should be possible to substitute the line
>>
>> llvm::GlobalVariable *TypeName = GetAddrOfTypeName(Ty, Linkage);
>>
>> with something that generates a static string "?" and returns the address
>> of that.  Then it will build the table pointing at this string, I am
>> guessing.
>>
>> Is this a feasible approach or will this break loads of things elsewhere
>> in the compiler and/or c++ runtime?  I am not interested in a run-time
>> ability to get the mangled (or otherwise) name of the class, so if
>> replacing this string has no effect on, for example, the correction
>> function of dynamic_cast or typeid and only means that std::type_info::name
>> returns a bogus value, then I'm happy with that.
>>
>
> The address and (sometimes) contents of the _ZTS type_info name are used
> for type_info equality comparisons. The implementation of dynamic_cast
> internally uses type_info comparisons to find the destination type within
> the source type's type_info tree. So changing the contents of the string to
> be non-unique may lead to problems, especially if the ABI rule in question
> results in the use of strcmp. You could perhaps instead consider replacing
> the string contents with something like a hash of the mangled name of the
> type (though be aware that the ABI library will want to interpret it as a
> nul-terminated byte string).
>

The symbol hashing (while preserving the nul-terminated-ness, as you say -
so using base64 encoding of the hash or something like that) might have
some overlap with ideas that gets thrown around from time to time, to
reduce symbol name length generally (in the DWARF, and in the ELF symbol
tables - though the latter would mostly/only apply if you're OK with an ABI
break or possibly a floating ABI (ie: build all your C++ code with this
exact compiler, no prebuilt libraries, etc)) - so not /exactly/ the same
thing, but might have enough overlap to benefit from some common
machinery/family of options. I hadn't actually thought about the RTTI side
of things - I should check that in more detail, perhaps another
place/source of redundant names & potential size benefit of this overall
direction.

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

Re: [cfe-users] detect default in SwitchInst

[David Blaikie via cfe-users]

Ah, LLVM IR isn't really the place to determine how the source was written
- the names of those LLVM values aren't always preserved (generally in
optimized builds of clang the names will not be generated) - that said,
even some LLVM features rely on the names, so it's not totally unusable.
You can use "getName()" on the value to get these names and inspect them,
etc.

On Fri, Jul 16, 2021 at 1:42 PM Bella V  wrote:

> In my case, for a function having a default statement in switch i could
> see a BB with label as sw.default is created:
> switch i32 %0, label %sw.*default* [
> ]
> sw.default: br label %sw.epilog
>
> For a non-default switch statement function:
> switch i32 %1, label %sw.epilog [
> ]
>
>
>
> On Fri, Jul 16, 2021 at 1:00 PM David Blaikie  wrote:
>
>> LLVM IR switch instructions always have a default:
>> https://llvm.org/docs/LangRef.html#switch-instruction - that jumps over
>> the body of the switch. (when lowering C code to LLVM IR the default would
>> be put after the loop, and the breaks from any case statements would jump
>> over that default block)
>>
>> On Fri, Jul 16, 2021 at 12:34 PM Bella V via cfe-users <
>> cfe-users@lists.llvm.org> wrote:
>>
>>> Hello All,
>>>
>>>
>>>
>>> I'm trying to find whether SwitchInst has a default statement. I'm able
>>> to iterate through the case values using case_begin and case_end. If I try
>>> to detect default using case_default which returns an iterator which points
>>> to the default case.
>>>
>>> Code Example:
>>>
>>> case_default()->getCaseIndex() or case_default()->getSuccessorIndex()
>>> returns the same values for both default and non-default switch C code.
>>>
>>>
>>> Any suggestions to solve this problem?
>>>
>>>
>>> Regards.
>>> ___
>>> 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] detect default in SwitchInst

[David Blaikie via cfe-users]

LLVM IR switch instructions always have a default:
https://llvm.org/docs/LangRef.html#switch-instruction - that jumps over the
body of the switch. (when lowering C code to LLVM IR the default would be
put after the loop, and the breaks from any case statements would jump over
that default block)

On Fri, Jul 16, 2021 at 12:34 PM Bella V via cfe-users <
cfe-users@lists.llvm.org> wrote:

> Hello All,
>
>
>
> I'm trying to find whether SwitchInst has a default statement. I'm able to
> iterate through the case values using case_begin and case_end. If I try to
> detect default using case_default which returns an iterator which points to
> the default case.
>
> Code Example:
>
> case_default()->getCaseIndex() or case_default()->getSuccessorIndex()
> returns the same values for both default and non-default switch C code.
>
>
> Any suggestions to solve this problem?
>
>
> Regards.
> ___
> 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] No macros in DI metadata

[David Blaikie via cfe-users]

On Wed, Jul 14, 2021 at 10:16 AM Bella V  wrote:
>
> Thanks a lot! It works.
>
> Also there is no IR code generated for macros. Is there a way to relate 
> llvm::value's that refer to macros.

Not that I know of, no. If you're interested in doing source analysis
like this - you might want to use a Clang Tool rather than debug info:
https://clang.llvm.org/docs/LibTooling.html

>
> Many Thanks.
>
> On Tue, Jul 13, 2021 at 7:06 PM David Blaikie  wrote:
>>
>> You could check where the macro is defined, I guess?
>> If it's in a DIMacroFile i guess it's not a compiler builtin. It might
>> still be from a system header, etc, if that matters to you - so then
>> you'd have to filter by the DIMacroFile's 'file' attribute.
>>
>> On Tue, Jul 13, 2021 at 7:00 PM Bella V  wrote:
>> >
>> > Thanks David for the helpful information. Is there a way to filter the 
>> > predefined macros such as __clang__, __GNUC__, etc.
>> >
>> > I could not get the macros defined in my C code with the below code:
>> > DIMacroNodeArray Macros = DICompUnit->getMacros();
>> > for (auto *MN : Macros) {
>> > if (auto *M = dyn_cast(MN)) {
>> > outs()<< M->getName();
>> > }
>> > }
>> >
>> >
>> > On Tue, Jul 13, 2021 at 4:13 PM David Blaikie  wrote:
>> >>
>> >> Add -fdebug-macro
>> >>
>> >> On Tue, Jul 13, 2021 at 4:05 PM Bella V via cfe-users
>> >>  wrote:
>> >> >
>> >> > Hello All,
>> >> >
>> >> > I'm trying to build a list of macros in a compilation unit using 
>> >> > CU->getMacros().
>> >> > I do not see the macros field in DICompileUnit output.
>> >> > https://godbolt.org/z/b8cM1Yf7v
>> >> >
>> >> > Please let me know what I'm missing.
>> >> >
>> >> > Many Thanks.
>> >> >
>> >> > ___
>> >> > 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] No macros in DI metadata

[David Blaikie via cfe-users]

You could check where the macro is defined, I guess?
If it's in a DIMacroFile i guess it's not a compiler builtin. It might
still be from a system header, etc, if that matters to you - so then
you'd have to filter by the DIMacroFile's 'file' attribute.

On Tue, Jul 13, 2021 at 7:00 PM Bella V  wrote:
>
> Thanks David for the helpful information. Is there a way to filter the 
> predefined macros such as __clang__, __GNUC__, etc.
>
> I could not get the macros defined in my C code with the below code:
> DIMacroNodeArray Macros = DICompUnit->getMacros();
> for (auto *MN : Macros) {
> if (auto *M = dyn_cast(MN)) {
> outs()<< M->getName();
> }
> }
>
>
> On Tue, Jul 13, 2021 at 4:13 PM David Blaikie  wrote:
>>
>> Add -fdebug-macro
>>
>> On Tue, Jul 13, 2021 at 4:05 PM Bella V via cfe-users
>>  wrote:
>> >
>> > Hello All,
>> >
>> > I'm trying to build a list of macros in a compilation unit using 
>> > CU->getMacros().
>> > I do not see the macros field in DICompileUnit output.
>> > https://godbolt.org/z/b8cM1Yf7v
>> >
>> > Please let me know what I'm missing.
>> >
>> > Many Thanks.
>> >
>> > ___
>> > 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] No macros in DI metadata

[David Blaikie via cfe-users]

Add -fdebug-macro

On Tue, Jul 13, 2021 at 4:05 PM Bella V via cfe-users
 wrote:
>
> Hello All,
>
> I'm trying to build a list of macros in a compilation unit using 
> CU->getMacros().
> I do not see the macros field in DICompileUnit output.
> https://godbolt.org/z/b8cM1Yf7v
>
> Please let me know what I'm missing.
>
> Many Thanks.
>
> ___
> 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] fetch variable names through debugInfo attached to load instructors

[David Blaikie via cfe-users]

On Tue, May 25, 2021 at 1:13 PM Bella V  wrote:

> Thanks! It works.
>
> One sub-question: How do we analyze the member dereferenced struct
> variables as dbg.declares only has the declaration info as inside the
> function the struct variable types could have members dereferenced as well.
>
> Example:
>
> https://godbolt.org/z/zaeYn9do7
>
> dbg.declares have use_var info, i would like to fetch address.id as well.
>

You'd have to do some sort of alias analysis, I guess - seeing that the
load is from a pointer derived from the pointer that the alloca/dbg.declare
describes - analyzing what offset from that is loaded, using the DI
metadata to figure out which field that offset corresponds to.

In general optimizations shouldn't try to do this - optimizations should be
based on the IR alone, without attempting to be aware of the source
constructs used to create them.
For source analysis - the IR isn't a great tool for that, for the sort of
reasons you're seeing here, and the analysis should probably be written in
terms of Clang's AST instead.

- Dave


>
>
> On Thu, May 20, 2021 at 12:25 PM David Blaikie  wrote:
>
>> You'd have to analyze the dbg.declares and track that they refer to the
>> same thing as the geps/loads you're interested in - from the dbg.declares
>> (& dbg.values) you can follow those to find the variables they refer to.
>>
>> On Thu, May 20, 2021 at 12:18 PM Bella V via cfe-users <
>> cfe-users@lists.llvm.org> wrote:
>>
>>> Hello All,
>>>
>>> I read the documentation and I was able to fetch the variable names and
>>> source locations attached to metadata for call instructions
>>> (@llvm.dbg.declare) using dyn_cast. I wanted to check
>>> if we could fetch the variable names in the load/gep instructors using
>>> debugInfo. I want to collect the use variable object details within the
>>> function.
>>>
>>>
>>>
>>> I could only fetch the source locations (not the variable names) using
>>> !dbg attached to the load instructions. Any pointers if that is allowed.
>>>
>>>
>>> *C code:*
>>>
>>> int foo (bar_t *b, int len)
>>>
>>> {
>>>
>>> if (b == (bar_t *)NULL) {
>>>
>>> return 0;
>>>
>>> }
>>>
>>> return -1;
>>>
>>> }
>>>
>>>
>>>
>>> *IR optimised code through LTO:*
>>>
>>> ; Function Attrs: noinline nounwind optnone uwtable
>>>
>>> define i32 @foo(%struct.bar_t*, i32) #0 !dbg !10 {
>>>
>>>   %3 = load i64, i64* getelementptr inbounds ([1 x i64], [1 x i64]
>>>
>>>   %4 = add i64 %3, 1
>>>
>>>   %5 = alloca i32, align 4
>>>
>>>   %6 = alloca % struct.bar_t*, align 8
>>>
>>>   %7 = alloca i32, align 4
>>>
>>>   store % struct.bar_t* %0, % struct.bar_t** %6, align 8
>>>
>>>   call void @llvm.dbg.declare(metadata % struct.bar_t** %6, metadata
>>> !11, metadata !DIExpression()), !dbg !12
>>>
>>>   store i32 %1, i32* %7, align 4
>>>
>>>   call void @llvm.dbg.declare(metadata i32* %7, metadata !12, metadata
>>> !DIExpression()), !dbg !14
>>>
>>>   %8 = load % struct.bar_t*, % struct.bar_t** %6, align 8, !dbg !15
>>>
>>>   %9 = icmp eq % struct.bar_t* %8, null, !dbg !16
>>>
>>>   br i1 %9, label %10, label %11, !dbg !17
>>>
>>>
>>>
>>> Many Thanks.
>>> ___
>>> 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] fetch variable names through debugInfo attached to load instructors

[David Blaikie via cfe-users]

You'd have to analyze the dbg.declares and track that they refer to the
same thing as the geps/loads you're interested in - from the dbg.declares
(& dbg.values) you can follow those to find the variables they refer to.

On Thu, May 20, 2021 at 12:18 PM Bella V via cfe-users <
cfe-users@lists.llvm.org> wrote:

> Hello All,
>
> I read the documentation and I was able to fetch the variable names and
> source locations attached to metadata for call instructions
> (@llvm.dbg.declare) using dyn_cast. I wanted to check
> if we could fetch the variable names in the load/gep instructors using
> debugInfo. I want to collect the use variable object details within the
> function.
>
>
>
> I could only fetch the source locations (not the variable names) using
> !dbg attached to the load instructions. Any pointers if that is allowed.
>
>
> *C code:*
>
> int foo (bar_t *b, int len)
>
> {
>
> if (b == (bar_t *)NULL) {
>
> return 0;
>
> }
>
> return -1;
>
> }
>
>
>
> *IR optimised code through LTO:*
>
> ; Function Attrs: noinline nounwind optnone uwtable
>
> define i32 @foo(%struct.bar_t*, i32) #0 !dbg !10 {
>
>   %3 = load i64, i64* getelementptr inbounds ([1 x i64], [1 x i64]
>
>   %4 = add i64 %3, 1
>
>   %5 = alloca i32, align 4
>
>   %6 = alloca % struct.bar_t*, align 8
>
>   %7 = alloca i32, align 4
>
>   store % struct.bar_t* %0, % struct.bar_t** %6, align 8
>
>   call void @llvm.dbg.declare(metadata % struct.bar_t** %6, metadata !11,
> metadata !DIExpression()), !dbg !12
>
>   store i32 %1, i32* %7, align 4
>
>   call void @llvm.dbg.declare(metadata i32* %7, metadata !12, metadata
> !DIExpression()), !dbg !14
>
>   %8 = load % struct.bar_t*, % struct.bar_t** %6, align 8, !dbg !15
>
>   %9 = icmp eq % struct.bar_t* %8, null, !dbg !16
>
>   br i1 %9, label %10, label %11, !dbg !17
>
>
>
> Many Thanks.
> ___
> 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] Clang Sizeof give diff value for Microsoft and Linux

[David Blaikie via cfe-users]

On Wed, Feb 17, 2021 at 9:17 PM Vivek Pandey <
vivek.pan...@tallysolutions.com> wrote:

> Dear David,
>
>
>
> Greeting!
>
>
>
> Please find details inline.
>
>
>
> Looking forward to hear from you.
>
>
>
>
>
> Best Regards,
>
>
>
> Vivek
>
>
>
> *From:* David Blaikie 
> *Sent:* Thursday, February 18, 2021 2:50 AM
> *To:* Vivek Pandey 
> *Cc:* cfe-users@lists.llvm.org; Manu Agarwal <
> manu.agar...@tallysolutions.com>; Tuhin Sengupta <
> tuhin.sengu...@tallysolutions.com>
> *Subject:* Re: [cfe-users] Clang Sizeof give diff value for Microsoft and
> Linux
>
>
>
> On Wed, Feb 17, 2021 at 12:08 AM Vivek Pandey <
> vivek.pan...@tallysolutions.com> wrote:
>
> I think Clang, on/for windows, should give a compile time flag/option that
> can be used to control it (A flag when set make compile-time operator like
> sizeoff to behave like MSVC or non-MSVC)
>
>
> But that would break the ability for that code to call existing libraries
> (including the MS runtime), I think - which would be quite broken/unusable,
> so far as I know.
>
> [VP] If clang has that flag then it will definitely have libraries in both
> format.
>

What will have libraries in both formats? third parties will publish
libraries in both formats? But there wouldn't be any way for the compiler
to know which format the library was compiled in, or any error message for
the linker to provide - you'd get silently broken code. And it's the system
libraries I'm most concerned about (since it's not likely they would be
published in both formats).


> Plus the system libraries works on the whole image and not on individual
> objects within the image and thus don’t seems to break any compatibility.
>

I don't understand what you mean by "on the whole image" verses "on
individual objects".


> As in the current form it is breaking building of cross-platform
> application.
>
>
> What dependence does this application have on the size of certain
> structures? That seems quite not-cross-platform to me & the code probably
> should be changed to be flexible to the different size of layouts on
> different platforms.
>
> [VP] Our is an application that exchanges binary data between same
> application that runs on diff platforms (Windows/Linux/OSX/Android/iOS/….).
>
>

That's not portable for a bunch of reasons - the layout of structs (as
you've found), the size of types ("int" isn't the same size on all
platforms, for instance), etc.


> As I mentioned in my initial email it’s a structure/class declaration and
> we are using clang to build on all these different platform. Isn’t the
> behavior of ‘sizeof’ operator be consistent ?
>

Not at all - sizeof exists because the size of a struct is different on
different C++ platforms/implementations - to write portable code in C++ you
must write it in such a way that you don't depend on the answer being any
particular value, nor the same value across platforms. sizeof exists so you
can query the implementation you're currently running on and adjust your
program's behavior based on that result as needed.

- Dave


>
>
>
>
>
>
>
> With C++11 onward many things are incorporated in standard so that one
> code base can be used across platform. Now if compiler is blocking the flow
> then it seems moving back to pre C++11.
>
>
>
> *From:* David Blaikie 
> *Sent:* Friday, January 29, 2021 3:23 AM
> *To:* Vivek Pandey 
> *Cc:* cfe-users@lists.llvm.org; Manu Agarwal <
> manu.agar...@tallysolutions.com>; Tuhin Sengupta <
> tuhin.sengu...@tallysolutions.com>
> *Subject:* Re: [cfe-users] Clang Sizeof give diff value for Microsoft and
> Linux
>
>
>
> Clang on Windows is designed to be compatible with MSVC - which has
> different layout requirements than the Itanium ABI/GCC on Linux. I don't
> think there's a way to use the same ABI on both platforms - especially not
> if you are interacting with any code compiled by another compiler on both
> platforms (existing/foregin C++ precompiled libraries).
>
>
>
> On Thu, Jan 28, 2021 at 1:45 PM Vivek Pandey via cfe-users <
> cfe-users@lists.llvm.org> wrote:
>
> Hi Team,
>
>
>
> We are using Clang 11 for our product that has common C++ code base for
> Windows, Linux, Macintosh, ….
>
>
>
> We observed that sizeof operator gives different value on Windows and
> Linux/OSX, when the inheritance is from a common base class:
>
>
>
> Example Sample:
>
>
>
> #include 
>
>
>
> struct Base {}; // empty class
>
>
>
> struct Derived1 : Base {
>
> int i;
>
> };
>
>
>
> struct Derived2 : Base {
>
> Base c; // Base, occupies 1 byte, followed by padding for i
>
> int i;
>
> };
>
>
>
> struct Derived3 : Base {
>
> Derived1 c; // Derived1 is too derived from same Base class
>
> int i;
>
> };
>
>
>
> int main()
>
> {
>
> assert
> 

Re: [cfe-users] Clang Sizeof give diff value for Microsoft and Linux

[David Blaikie via cfe-users]

On Wed, Feb 17, 2021 at 12:08 AM Vivek Pandey <
vivek.pan...@tallysolutions.com> wrote:

> I think Clang, on/for windows, should give a compile time flag/option that
> can be used to control it (A flag when set make compile-time operator like
> sizeoff to behave like MSVC or non-MSVC)
>

But that would break the ability for that code to call existing libraries
(including the MS runtime), I think - which would be quite broken/unusable,
so far as I know.


> As in the current form it is breaking building of cross-platform
> application.
>

What dependence does this application have on the size of certain
structures? That seems quite not-cross-platform to me & the code probably
should be changed to be flexible to the different size of layouts on
different platforms.


>
>
> With C++11 onward many things are incorporated in standard so that one
> code base can be used across platform. Now if compiler is blocking the flow
> then it seems moving back to pre C++11.
>
>
>
> *From:* David Blaikie 
> *Sent:* Friday, January 29, 2021 3:23 AM
> *To:* Vivek Pandey 
> *Cc:* cfe-users@lists.llvm.org; Manu Agarwal <
> manu.agar...@tallysolutions.com>; Tuhin Sengupta <
> tuhin.sengu...@tallysolutions.com>
> *Subject:* Re: [cfe-users] Clang Sizeof give diff value for Microsoft and
> Linux
>
>
>
> Clang on Windows is designed to be compatible with MSVC - which has
> different layout requirements than the Itanium ABI/GCC on Linux. I don't
> think there's a way to use the same ABI on both platforms - especially not
> if you are interacting with any code compiled by another compiler on both
> platforms (existing/foregin C++ precompiled libraries).
>
>
>
> On Thu, Jan 28, 2021 at 1:45 PM Vivek Pandey via cfe-users <
> cfe-users@lists.llvm.org> wrote:
>
> Hi Team,
>
>
>
> We are using Clang 11 for our product that has common C++ code base for
> Windows, Linux, Macintosh, ….
>
>
>
> We observed that sizeof operator gives different value on Windows and
> Linux/OSX, when the inheritance is from a common base class:
>
>
>
> Example Sample:
>
>
>
> #include 
>
>
>
> struct Base {}; // empty class
>
>
>
> struct Derived1 : Base {
>
> int i;
>
> };
>
>
>
> struct Derived2 : Base {
>
> Base c; // Base, occupies 1 byte, followed by padding for i
>
> int i;
>
> };
>
>
>
> struct Derived3 : Base {
>
> Derived1 c; // Derived1 is too derived from same Base class
>
> int i;
>
> };
>
>
>
> int main()
>
> {
>
> assert
> (sizeof(Derived2)
> == 2*sizeof(int));
>
>
>
> assert
> 
> (sizeof(Derived3) == 3*sizeof(int));
>
> }
>
>
>
>   When we compile above program using Clang 11 and run it on
> windows and Linux  sizeof(Derived3) give different value.
>
>
>
> We don’t want a work-around via making first data member of derived class
> of type different from class that also is derived from same empty base
> class.
>
> Is there any flag that we can use so that it gives same result on all
> platform (Windows/Linux/OSX/Android/iOS/….)
>
> Or another way to solve this gracefully.
>
>
>
> Thank you!
>
>
>
> Best Regards,
>
> Vivek
>
>
>
> ___
> 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] Clang Sizeof give diff value for Microsoft and Linux

[David Blaikie via cfe-users]

Clang on Windows is designed to be compatible with MSVC - which has
different layout requirements than the Itanium ABI/GCC on Linux. I don't
think there's a way to use the same ABI on both platforms - especially not
if you are interacting with any code compiled by another compiler on both
platforms (existing/foregin C++ precompiled libraries).

On Thu, Jan 28, 2021 at 1:45 PM Vivek Pandey via cfe-users <
cfe-users@lists.llvm.org> wrote:

> Hi Team,
>
>
>
> We are using Clang 11 for our product that has common C++ code base for
> Windows, Linux, Macintosh, ….
>
>
>
> We observed that sizeof operator gives different value on Windows and
> Linux/OSX, when the inheritance is from a common base class:
>
>
>
> Example Sample:
>
>
>
> #include 
>
>
>
> struct Base {}; // empty class
>
>
>
> struct Derived1 : Base {
>
> int i;
>
> };
>
>
>
> struct Derived2 : Base {
>
> Base c; // Base, occupies 1 byte, followed by padding for i
>
> int i;
>
> };
>
>
>
> struct Derived3 : Base {
>
> Derived1 c; // Derived1 is too derived from same Base class
>
> int i;
>
> };
>
>
>
> int main()
>
> {
>
> assert (sizeof(Derived2)
> == 2*sizeof(int));
>
>
>
> assert (
> sizeof(Derived3) == 3*sizeof(int));
>
> }
>
>
>
>   When we compile above program using Clang 11 and run it on
> windows and Linux  sizeof(Derived3) give different value.
>
>
>
> We don’t want a work-around via making first data member of derived class
> of type different from class that also is derived from same empty base
> class.
>
> Is there any flag that we can use so that it gives same result on all
> platform (Windows/Linux/OSX/Android/iOS/….)
>
> Or another way to solve this gracefully.
>
>
>
> Thank you!
>
>
>
> Best Regards,
>
> Vivek
>
>
> ___
> 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] Get Source Location details from IR code (Function Pass)

[David Blaikie via cfe-users]

from the llvm::Function you can get a DISubprogram (Function's
getSubprogram), from there you could get the DISubprogram's type (getType)
and then poke around at the elements of the type, I guess.

On Tue, Jan 26, 2021 at 10:39 PM Bella V  wrote:

> Thank you for the clarification. How do we access DICompositeType: line
> numbers from Function  or Module 
>
> On Tue, Jan 26, 2021 at 9:43 PM David Blaikie  wrote:
>
>> the location of composite types isn't stored in a DILocation - it's
>> stored in the 'file'/'line' attributes of the DICompositeType (similarly,
>> the members have a 'file' and 'line' attribute).
>>
>> See for instance line 39 of the LLVM IR in https://godbolt.org/z/o3oce5 :
>>
>> !12 = distinct !DICompositeType(tag: DW_TAG_structure_type, name: "Foo",
>> file: !8, line: 1, size: 32, flags: DIFlagTypePassByValue, elements: !13,
>> identifier: "_ZTS3Foo")
>>
>> Note the 'file:' and 'line: fields there. (the file field refers to !8
>> which is !8 = !DIFile(filename: "./example.cpp", directory: "/home/ce"))
>>
>> On Tue, Jan 26, 2021 at 5:15 PM Bella V 
>> wrote:
>>
>>> Thanks for the answer.
>>> struct Foo
>>> {int x;};
>>>
>>> Void bar() {
>>> struct Foo f;
>>> f.x = 1;
>>> }
>>>
>>> I'm trying to access the DILocation for DICompositeType (Foo), that is
>>> the Source Location for struct Foo and struct members. Any pointers.
>>>
>>> Regards.
>>>
>>> On Sun, Jan 17, 2021 at 11:20 AM David Blaikie 
>>> wrote:
>>>
 Not sure I understand the question - llvm.dbg.declare can be
 queried/examined/etc through the usual LLVM IR APIs, yes - it's an
 intrinsic call, with operands, etc. It's a DbgVariableIntrinsic (
 https://llvm.org/doxygen/classllvm_1_1DbgVariableIntrinsic.html ) you
 can interrogate for information.

 On Fri, Jan 15, 2021 at 7:17 PM Bella V 
 wrote:
 >
 > Thank you. Also Is there a pragmatically way to access the metadata
 info for local variables within the llvm.dbg.declare.
 > ( llvm::Value does not have local variables).
 >
 > On Tue, Jan 12, 2021 at 1:55 PM David Blaikie 
 wrote:
 >>
 >> You'd have to get IR from somewhere that has attached debug info -
 such as clang -g
 >>
 >> On Tue, Jan 12, 2021 at 1:22 PM Bella V 
 wrote:
 >>>
 >>> Do we have to initially attach some metadata to the Value? Because
 in function pass, when I do F.getAllMetadata(MDs), i do not see any
 metadata appending to MDS.
 >>> F.hasMetadata() also returns false. What would be the way to get
 debugLoc in these scenario?
 >>>
 >>> Thanks and Regards.
 >>>
 >>> On Mon, Jan 11, 2021 at 6:31 PM David Blaikie 
 wrote:
 
 
 
  On Mon, Jan 11, 2021 at 4:33 PM Ayush Mittal via cfe-users <
 cfe-users@lists.llvm.org> wrote:
 >
 > Hello Cfe Users,
 >
 > Could you please point to an effective way to get Source Location
 details from an IR code.
 > From the documentation, I think this could be a way:
 > Function Pass-> LLVM Value-> MDN->DILocation-> Source Location.
 
 
  Yep, that's about it (I mean, you can do it in a pass, or not -
 but  yes, find an llvm::Value and get the debugLoc from that)
 
 >
 > Please include any example if the above approach is correct too.
 >
 > Thanks and Regards.
 > ___
 > 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] Get Source Location details from IR code (Function Pass)

[David Blaikie via cfe-users]

the location of composite types isn't stored in a DILocation - it's stored
in the 'file'/'line' attributes of the DICompositeType (similarly, the
members have a 'file' and 'line' attribute).

See for instance line 39 of the LLVM IR in https://godbolt.org/z/o3oce5 :

!12 = distinct !DICompositeType(tag: DW_TAG_structure_type, name: "Foo",
file: !8, line: 1, size: 32, flags: DIFlagTypePassByValue, elements: !13,
identifier: "_ZTS3Foo")

Note the 'file:' and 'line: fields there. (the file field refers to !8
which is !8 = !DIFile(filename: "./example.cpp", directory: "/home/ce"))

On Tue, Jan 26, 2021 at 5:15 PM Bella V  wrote:

> Thanks for the answer.
> struct Foo
> {int x;};
>
> Void bar() {
> struct Foo f;
> f.x = 1;
> }
>
> I'm trying to access the DILocation for DICompositeType (Foo), that is the
> Source Location for struct Foo and struct members. Any pointers.
>
> Regards.
>
> On Sun, Jan 17, 2021 at 11:20 AM David Blaikie  wrote:
>
>> Not sure I understand the question - llvm.dbg.declare can be
>> queried/examined/etc through the usual LLVM IR APIs, yes - it's an
>> intrinsic call, with operands, etc. It's a DbgVariableIntrinsic (
>> https://llvm.org/doxygen/classllvm_1_1DbgVariableIntrinsic.html ) you
>> can interrogate for information.
>>
>> On Fri, Jan 15, 2021 at 7:17 PM Bella V 
>> wrote:
>> >
>> > Thank you. Also Is there a pragmatically way to access the metadata
>> info for local variables within the llvm.dbg.declare.
>> > ( llvm::Value does not have local variables).
>> >
>> > On Tue, Jan 12, 2021 at 1:55 PM David Blaikie 
>> wrote:
>> >>
>> >> You'd have to get IR from somewhere that has attached debug info -
>> such as clang -g
>> >>
>> >> On Tue, Jan 12, 2021 at 1:22 PM Bella V 
>> wrote:
>> >>>
>> >>> Do we have to initially attach some metadata to the Value? Because in
>> function pass, when I do F.getAllMetadata(MDs), i do not see any metadata
>> appending to MDS.
>> >>> F.hasMetadata() also returns false. What would be the way to get
>> debugLoc in these scenario?
>> >>>
>> >>> Thanks and Regards.
>> >>>
>> >>> On Mon, Jan 11, 2021 at 6:31 PM David Blaikie 
>> wrote:
>> 
>> 
>> 
>>  On Mon, Jan 11, 2021 at 4:33 PM Ayush Mittal via cfe-users <
>> cfe-users@lists.llvm.org> wrote:
>> >
>> > Hello Cfe Users,
>> >
>> > Could you please point to an effective way to get Source Location
>> details from an IR code.
>> > From the documentation, I think this could be a way:
>> > Function Pass-> LLVM Value-> MDN->DILocation-> Source Location.
>> 
>> 
>>  Yep, that's about it (I mean, you can do it in a pass, or not - but
>> yes, find an llvm::Value and get the debugLoc from that)
>> 
>> >
>> > Please include any example if the above approach is correct too.
>> >
>> > Thanks and Regards.
>> > ___
>> > 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] Get Source Location details from IR code (Function Pass)

[David Blaikie via cfe-users]

Not sure I understand the question - llvm.dbg.declare can be
queried/examined/etc through the usual LLVM IR APIs, yes - it's an
intrinsic call, with operands, etc. It's a DbgVariableIntrinsic (
https://llvm.org/doxygen/classllvm_1_1DbgVariableIntrinsic.html ) you
can interrogate for information.

On Fri, Jan 15, 2021 at 7:17 PM Bella V  wrote:
>
> Thank you. Also Is there a pragmatically way to access the metadata info for 
> local variables within the llvm.dbg.declare.
> ( llvm::Value does not have local variables).
>
> On Tue, Jan 12, 2021 at 1:55 PM David Blaikie  wrote:
>>
>> You'd have to get IR from somewhere that has attached debug info - such as 
>> clang -g
>>
>> On Tue, Jan 12, 2021 at 1:22 PM Bella V  wrote:
>>>
>>> Do we have to initially attach some metadata to the Value? Because in 
>>> function pass, when I do F.getAllMetadata(MDs), i do not see any metadata 
>>> appending to MDS.
>>> F.hasMetadata() also returns false. What would be the way to get debugLoc 
>>> in these scenario?
>>>
>>> Thanks and Regards.
>>>
>>> On Mon, Jan 11, 2021 at 6:31 PM David Blaikie  wrote:



 On Mon, Jan 11, 2021 at 4:33 PM Ayush Mittal via cfe-users 
  wrote:
>
> Hello Cfe Users,
>
> Could you please point to an effective way to get Source Location details 
> from an IR code.
> From the documentation, I think this could be a way:
> Function Pass-> LLVM Value-> MDN->DILocation-> Source Location.


 Yep, that's about it (I mean, you can do it in a pass, or not - but  yes, 
 find an llvm::Value and get the debugLoc from that)

>
> Please include any example if the above approach is correct too.
>
> Thanks and Regards.
> ___
> 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] Get Source Location details from IR code (Function Pass)

[David Blaikie via cfe-users]

You'd have to get IR from somewhere that has attached debug info - such as
clang -g

On Tue, Jan 12, 2021 at 1:22 PM Bella V  wrote:

> Do we have to initially attach some metadata to the Value? Because in
> function pass, when I do F.getAllMetadata(MDs), i do not see any metadata
> appending to MDS.
> F.hasMetadata() also returns false. What would be the way to get debugLoc
> in these scenario?
>
> Thanks and Regards.
>
> On Mon, Jan 11, 2021 at 6:31 PM David Blaikie  wrote:
>
>>
>>
>> On Mon, Jan 11, 2021 at 4:33 PM Ayush Mittal via cfe-users <
>> cfe-users@lists.llvm.org> wrote:
>>
>>> Hello Cfe Users,
>>>
>>> Could you please point to an effective way to get Source Location
>>> details from an IR code.
>>> From the documentation, I think this could be a way:
>>> Function Pass-> LLVM Value-> MDN->DILocation-> Source Location.
>>>
>>
>> Yep, that's about it (I mean, you can do it in a pass, or not - but  yes,
>> find an llvm::Value and get the debugLoc from that)
>>
>>
>>> Please include any example if the above approach is correct too.
>>>
>>> Thanks and Regards.
>>> ___
>>> 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] Get Source Location details from IR code (Function Pass)

[David Blaikie via cfe-users]

On Mon, Jan 11, 2021 at 4:33 PM Ayush Mittal via cfe-users <
cfe-users@lists.llvm.org> wrote:

> Hello Cfe Users,
>
> Could you please point to an effective way to get Source Location details
> from an IR code.
> From the documentation, I think this could be a way:
> Function Pass-> LLVM Value-> MDN->DILocation-> Source Location.
>

Yep, that's about it (I mean, you can do it in a pass, or not - but  yes,
find an llvm::Value and get the debugLoc from that)


> Please include any example if the above approach is correct too.
>
> Thanks and Regards.
> ___
> 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] Missing AST Node for parsing code with std::vector::data()

[David Blaikie via cfe-users]

You might need to provide more details - at least a cursory example shows
the function call in the ast dump: https://godbolt.org/z/zvqTa3

On Thu, Dec 3, 2020 at 4:02 AM Владимир Фролов via cfe-users <
cfe-users@lists.llvm.org> wrote:

> Greetings! I'm using clang for source-to-source translation.
>
> Recently I got a problem with parsing code which use templates.
> First, here is the working example:
>
> struct MyTestVector2
> {
>  unsigned int _data[6];
>  unsigned int * data() { return &_data[0]; }
> };
> ...
> MyTestVector2 testData2;
> kernel_TestColor(,
> testData2.data(), tidX, tidY);
> This code processed normally and i gon correct "CXXMemberCallExpr" node
> for kernel_TestColor which i actually need.
> Then i changed MyTestVector2 to template:
>
> template
> struct MyTestVector2
> {
>  T _data[6];
>  T * data() { return &_data[0]; }
> };
>
> ...
> MyTestVector2 testData2;
> kernel_TestColor(,
> testData2.data(), tidX, tidY);
>
> This time i got
>
> `-DeclStmt 0x5816e128 
>   `-VarDecl 0x5816e0c0  col:31 invalid testData2
> 'MyTestVector2':'MyTestVector2'
>
> This time, The AST node for kernel_TestColor is just missed!
> The code is absolutely correct itself, it can be build and run.
>
> I'm using AST processing for code generation, so it is important for me to
> get  AST node for kernel_TestColor and then analyze its arguments.
> I understand that this seems to be not a bug, but ... may be, there is a
> way to make parser more tolerant to data types ... because what i actually
> need is just a strings of all parameters, so, just having "
> testData2.data()" at some level of AST for the second parameter of 
> kernel_TestColor
> would be enough for me.
>
> I would be appretiate for help or advice.
> Currently i use llvm 10.
> Thanks!
> --
> Best Regards,
>  Frolov V.A.
>
> ___
> 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] -Wconversion does not produce warnings when it should

[David Blaikie via cfe-users]

On Mon, Nov 16, 2020 at 4:49 PM Sven Köhler via cfe-users
 wrote:
>
> Am 16.11.20 um 21:49 schrieb David Blaikie via cfe-users:
> > On Mon, Nov 16, 2020 at 12:36 PM Sven Köhler via cfe-users
> >  wrote:
> >>
> >> Can you elaborate what is happening here?
> >
> > I believe/would guess the goal is to reduce false positives (where a
> > false positive is defined as "warning on code where the code does what
> > the author intended").
> >
> > In the taste of testb4 this code is "as good as" the unsigned int
> > equivalent, say (unigned x(unsigned a, unsigned b) { return a + b; })
> > - wraparound occurs in both cases, so the code perhaps isn't too
> > surprising/the semantics of widening/narrowing conversions don't
> > really impact the behavior.
>
> I do appreciate your explanation. But I do not appreciate the compiler
> guessing that wrap around is OK.
>
> The C standard could also be interpreted as "wrap around only occurs
> with types of rank equal to (unsigned) int and above" as all other types
> are promoted to int prior to any arithmetic.
> (My guess for the origin of this promotion would be that int is the
> natural word size of the underlying CPU.)
>
> With most modern architectures, int is 32 bit which is a reasonable size
> for wraparounds. Unfortunately, int doesn't always have a fixed size.
>
> > The uint16 version of the code and the
> > unsigned int version of the code would appear to the user to work in
> > the same way.
>
> I would appreciate that only if my understanding of the C language was
> that arithmetic on two uint16_t operands is performed with uint16_t
> precision. But that is simply false. It is performed with 32 bit
> precision (if int is 32 bit).
>
> > But, yeah, once the expressions are sufficiently complicated, as in
> > testa4, clang's attempt to silence benign cases of the warning gives
> > up and you get warnings. It's best-effort sort of stuff.
>
> I would vote for -Wconversion=strict or -Wimplicit-int-conversion=strict
> where we get a warning for every int conversion that loses precision.
>
> I would be very happy if there was a clang option to generate warnings
> in such cases.

In general, Clang warnings are designed to have very low false
positive rates so they're more likely to be enabled by users even on
existing codebases (eg: where the work to cleanup existing violations
of the warning is fruitful in terms of fixing bugs rather than only
suppressing a warning where it doesn't indicate any bug was present) -
so it may not be especially desirable to have such a strict form of
the warning in clang. Not to say "certainly not", but that it might be
a bit trickier to motivate/justify.

Might be that something more like a clang-tidy check could be more
suited to your needs.

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

Re: [cfe-users] -Wconversion does not produce warnings when it should

[David Blaikie via cfe-users]

On Mon, Nov 16, 2020 at 12:36 PM Sven Köhler via cfe-users
 wrote:
>
> Hi,
>
> consider the following code:
>
> uint16_t testa4(uint8_t x, uint8_t y) {
> return ( (uint16_t)x << 0 )
> | ( (uint16_t)y << 8 );
> }
> uint16_t testb3(uint16_t x, uint16_t y) {
> return x|y;
> }
> uint16_t testb4(uint16_t x, uint16_t y) {
> return x+y;
> }
> int testb4x(uint16_t x, uint16_t y) {
> return x+y;
> }
>
>
>
> I'm using clang 11.0.0 on Intel x86_64 and when I compile the above code
> with -Wconversion enabled, then I see only one warning, namely for testa4.
>
> However, according to the C standard, the expression after the return
> statement has type int in all 4 cases. So why is the warning not
> triggered for testb3 and testb4?
>
> In fact, it's convenient that testb3 does not trigger a warning. Yes, x
> and y are promoted to int before the bitwise or is performed, but the
> result indeed fits into an uint16_t, regardless of x and y. So if clang
> is smart and keeps track of the range of the expressions, then it is
> understandable that there is no warning for testb3. However, then the
> "keeping track of ranges" feature seems to fail for testa4, because
> there a warning is indeed produced even though the two operands of the
> bitwise-or are both uint16_t.
>
> However, the case of testb4 is different. If we set x an y to 0x,
> then the result will be 0x1FFFE. You can confirm that this is the case
> by running testb4x. Then, shouldn't testb4 trigger a warning? The result
> is clearly and int _and_ the result may not fit into an uint16_t.
>
>
> I'm lost. As far as I understand, -Wconversion should issue a warning
> when an int is converted to uint16_t without an explicit cast. For all I
> know, x+y and x|y are ints, yet there is no warning in testb3 and
> testb4. This seems like a bug to me.
>
>
> Can you elaborate what is happening here?

I believe/would guess the goal is to reduce false positives (where a
false positive is defined as "warning on code where the code does what
the author intended").

In the taste of testb4 this code is "as good as" the unsigned int
equivalent, say (unigned x(unsigned a, unsigned b) { return a + b; })
- wraparound occurs in both cases, so the code perhaps isn't too
surprising/the semantics of widening/narrowing conversions don't
really impact the behavior. The uint16 version of the code and the
unsigned int version of the code would appear to the user to work in
the same way.

But, yeah, once the expressions are sufficiently complicated, as in
testa4, clang's attempt to silence benign cases of the warning gives
up and you get warnings. It's best-effort sort of stuff.
___
cfe-users mailing list
cfe-users@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users

Re: [cfe-users] Adding linker flag `-save-temps` resolves the clang-8 error: "unable to make temporary file"

[David Blaikie via cfe-users]

Yep, pretty weird that it tries to write to an empty file name.

What's the exact raw clang command you used that printed that cc1 command
line?

On Mon, Oct 5, 2020 at 6:46 AM Danijel DOMAZET <
p-danijel.doma...@devialet.com> wrote:

> Hi David, Hi Fang-rui,
>
> Just to remind, when I add -save-temps flag, linking works, but without
> this option it fails with:
>
> clang-8: error: unable to make temporary file: No such file or directory
> clang-8: error: unable to make temporary file: No such file or directory
> clang-8: error: unable to make temporary file: No such file or directory
>
> Here is the output with flags -save-temps, -###:
>
>  "/usr/bin/clang-8" "-cc1" "-triple" "x86_64-unknown-windows-cygnus" "-S"
> "-save-temps=cwd" "-disable-free" "-disable-llvm-verifier"
> "-discard-value-names" "-main-file-name" "my_files\\my_file1.bc"
> "-mrelocation-model" "pic" "-pic-level" "2" "-mthread-model" "posix"
> "-fmath-errno" "-masm-verbose" "-mconstructor-aliases" "-munwind-tables"
> "-target-cpu" "x86-64" "-dwarf-column-info" "-debugger-tuning=gdb"
> "-momit-leaf-frame-pointer" "-v" "-resource-dir" "/usr/lib/clang/8.0.1"
> "-fdebug-compilation-dir" "/cygdrive/c/my_projects/prj1/Debug"
> "-ferror-limit" "19" "-fmessage-length" "0" "-fobjc-runtime=gcc"
> "-fseh-exceptions" "-fdiagnostics-show-option" "-o" "my_files\\my_file1.s"
> "-x" "ir" "my_files\\my_file1.bc" "-faddrsig"
>
> Here is the output without -save-temps, just -###:
>
>  "/usr/bin/clang-8" "-cc1" "-triple" "x86_64-unknown-windows-cygnus"
> "-emit-obj" "-mrelax-all" "-disable-free" "-disable-llvm-verifier"
> "-discard-value-names" "-main-file-name" "my_files\\my_file1.bc"
> "-mrelocation-model" "pic" "-pic-level" "2" "-mthread-model" "posix"
> "-fmath-errno" "-masm-verbose" "-mconstructor-aliases" "-munwind-tables"
> "-target-cpu" "x86-64" "-dwarf-column-info" "-debugger-tuning=gdb"
> "-momit-leaf-frame-pointer" "-v" "-resource-dir" "/usr/lib/clang/8.0.1"
> "-fdebug-compilation-dir" "/cygdrive/c/my_projects/prj1/Debug"
> "-ferror-limit" "19" "-fmessage-length" "0" "-fobjc-runtime=gcc"
> "-fseh-exceptions" "-fdiagnostics-show-option" "-o" "" "-x" "ir"
> "my_files\\my_file1.bc" "-faddrsig"
>
> So the "-o" "my_files\\my_file1.s"  vs  "-o" "" seems to be the
> difference. Is there an explanation?
>
> Also, some more output with the output with flags -save-temps, -###:
>
> "/usr/bin/ld" "-m" "i386pep" "--wrap" "_Znwm" "--wrap" "_Znam" "--wrap"
> "_ZnwmRKSt9nothrow_t" "--wrap" "_ZnamRKSt9nothrow_t" "--wrap" "_ZdlPv"
> "--wrap" "_ZdaPv" "--wrap" "_ZdlPvRKSt9nothrow_t" "--wrap"
> "_ZdaPvKSt9nothrow_t" "-Bdynamic" "--tsaware" "-o" "myexecutable"
> "/usr/lib/crt0.o" "/usr/lib/gcc/x86_64-pc-cygwin/10/crtbegin.o"
> "-LC:/mylibraries" "-L/usr/lib/gcc/x86_64-pc-cygwin/10"
> "-L/usr/x86_64-pc-cygwin/lib" "-L/usr/lib" "-L/usr/lib/w32api"
> "my_files\\my_file1.o" "my_files\\my_file2.o" " my_files\\my_file3.o"
> "-lnaturedsp" "-lgcc_s" "-gcc" "-lcygwin" "-ladvapi32" "-lshell32"
> "-luser32" "-lkernel32" "/usr/lib/default-manifest.o"
> "/usr/lib/gcc/x86_64-pc-cygwin/10/crtend.o"
>
> and with only -###:
>
>  "/usr/bin/ld" "-m" "i386pep" "--wrap" "_Znwm" "--wrap" "_Znam" "--wrap"
> "_ZnwmRKSt9nothrow_t" "--wrap" "_ZnamRKSt9nothrow_t" "--wrap" "_ZdlPv"
> "--wrap" "_ZdaPv" "--wrap" "_ZdlPvRKSt9nothrow_t" "--wrap"
> "_ZdaPvKSt9nothrow_t" "-Bdynamic" "--tsaware" "-o" "myexecutable"
> "/usr/lib/crt0.o" "/usr/lib/gcc/x86_64-pc-cygwin/10/crtbegin.o"
> "-LC:/mylibraries" "-L/usr/lib/gcc/x86_64-pc-cygwin/10"
> "-L/usr/x86_64-pc-cygwin/lib" "-L/usr/lib" "-L/usr/lib/w32api" "" "" ""
> "-lnaturedsp" "-lgcc_s" "-lgcc" "-lcygwin" "-ladvapi32" "-lshell32"
> "-luser32" "-lkernel32" "/usr/lib/default-manifest.o"
> "/usr/lib/gcc/x86_64-pc-cygwin/10/crtend.o"
>
> So, again  "my_files\\my_file1.o" "my_files\\my_file2.o" "
> my_files\\my_file3.o" is lost and substituted with empty strings  "" "" ""
> .
>
>
> Does this info help resolve my problem?
> Danijel
>
>
> On Thu, Aug 13, 2020 at 8:27 PM David Blaikie  wrote:
>
>> Oh, sorry, I didn't read the question in detail about how -save-temps
>> was making things work when they otherwise were not.
>>
>> If you run clang with -### it'll show the command lines it's using,
>> which should show you where it's trying to write the files so you can
>> change that/make them writable. I'm not sure which variable is used to
>> influence clang's temporary directory choice, though.
>>
>> On Thu, Aug 13, 2020 at 11:22 AM Danijel DOMAZET
>>  wrote:
>> >
>> > Thanks Fang-rui.
>> > I still haven't been able to fix the issue, I still use --save-temps,
>> and that makes linking very slow.
>> > Why does this error go away when I set --save-temps, any idea??
>> >
>> >
>> >
>> > On Thu, Aug 13, 2020 at 7:16 PM Fāng-ruì Sòng 
>> wrote:
>> >>
>> >> On Thu, Aug 13, 2020 at 8:59 AM David Blaikie 
>> wrote:
>> >> >
>> >> > On Thu, Aug 13, 2020 at 2:59 AM Danijel DOMAZET
>> >> >  wrote:
>> >> > >
>> >> > > Thanks David.
>> >> > > Why do you think this could be 

Re: [cfe-users] Compiling on network share using relative paths fails

[David Blaikie via cfe-users]

Can you confirm other tools given similar path specifications in similar
circumstances (command line/current working directory/etc) succeed where
clang fails? (MSVC, notepad, gcc, 'cat' (if Windows has a 'cat'))

On Wed, Sep 9, 2020 at 10:41 AM Telium Technical Support via cfe-users <
cfe-users@lists.llvm.org> wrote:

> I think this is a bug…but it’s so big that I can’t believe I’m the first
> person to find it.  Perhaps someone can help me find a workaround…
>
>
>
> I discovered that clang++ will not find a source file if it is located on
> a network share (if using a relative path). For example, I have place the
> same file "main.cpp" into C:\temp (a local drive) and T:\temp (a network
> SMB share).
>
>
>
> If I change pwd to C:\temp the following line works:
>
>
>
> C:\android\cmdline-tools\ndk\21.1.6352462/toolchains/llvm/prebuilt/windows-x86_64/bin/clang++
> main.cpp
>
>
>
> but if I change pwd to T:\temp the above line does NOT work (can't find
> file). However, if I specify the full path for the source file for clang++
> T:\temp\main.cpp then it works.
>
>
>
> Since my make files are generated (using qmake) I have no control over the
> paths passed to clang++. Can someone explain why clang++ can't find source
> files on network shares (using relative paths), and how to fix this?
>
>
>
> In case it matters, I’m running on Win10 64 bit.  I’ve tried putting
> source files on an SMB share, and a NFS share…and the results are the same.
> ___
> 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] How to debug cryptic error message?

[David Blaikie via cfe-users]

Unfortunately, probably the first thing I'd try is assembling with the GNU
assembler instead (using clang -fno-integrated-as, or using gcc as your
assembler driver should reach your system assembler which is probably gas).

LLVM's integrated assembler could use a better error message, to be sure.

On Tue, Aug 25, 2020 at 7:51 AM Gary Benson via cfe-users <
cfe-users@lists.llvm.org> wrote:

> Hi all,
>
> I'm trying to compile a generated assembler file using clang, but I'm
> getting a cryptic error message:
>
>   bash$ clang -c dw2-double-set-die-type_clang.s
>   :0: error: Undefined temporary symbol
>   :0: error: Undefined temporary symbol
>
> Are there command-line options I can use to narrow down what's causing
> this?  I'm using clang version 10.0.0 (Fedora 10.0.0-2.fc32) on x86_64
> if that matters.
>
> Thanks,
> Gary
>
> --
> Gary Benson - he / him / his
> Principal Software Engineer, Red Hat
>
> ___
> 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] inconsistent compilation error inside constexpr if

[David Blaikie via cfe-users]

On Sun, Aug 23, 2020 at 9:40 AM Manu agarwal  wrote:

> Hi David,
>
> Thanks for the reply. I missed to mention the environment and what i am
> trying to do.
>
>
>1. Environment is ClangCL (version 10.0), Microsoft Visual Studio.
>
>2. I assumed that since the 'constexpr if' evaluates to false, the
> external function's presence would not be checked. So, if my application is
> not of type 'client' ClientMain would not be called.  My actual code inside
> the constexpr if is the commented line of code that does not compile. To
> experiment i simply invoked ClientMain directly which compiled fine.
>
> Here is the assembly generated from the successful compilation (with the
> first line inside 'constexpr if' enabled).
>
> "??$*MyAppInit*@$02@MyAppTemplate@@SQ_NXZ": # @"??$MyAppInit@
> $02@MyAppTemplate@@SQ_NXZ"
> .Lfunc_begin2:
> .cv_func_id 2
> .cv_loc 2 1 32 0# Main.cpp:32:0
> # %bb.0:
> .cv_loc 2 1 39 0# Main.cpp:39:0
> *xor eax, eax*
> # kill: def $al killed $al killed
> $eax
> .Ltmp6:
> *ret*
> .Ltmp7:
> .Lfunc_end2:
>
> Here is how the compiler is invoked:
>
> *E:\LLVM\bin\clang-cl.exe  /c /Z7 /nologo /W3 /WX- /diagnostics:column /Od
> /D _DEBUG /D _CONSOLE /D _UNICODE /D UNICODE /EHsc /MTd /GS /fp:precise
> /permissive- /std:c++17 /FA /Fa"x64\Debug\\" /Fo"x64\Debug\\" /Gv /TP -m64
>  Main.cpp*
> *1>  Done executing task "CL".*
>
> Is my understanding of 'constexpr if' wrong ? won't the body get discarded
> in case it gets evaluated to false?
>

Yeah, that's not quite how constexpr works - I think you may've gained that
model partly by the combination of MSVC-compatible lazy-parsed templates
and constexpr.

The spec basically says something /very roughly/ like "dependent things in
a non-taken constexpr if branch remain dependent even after template
instantiation". But that means code that's invalid no matter what (like
"static_assert(false)") still trigger errors. See the latter parts of the
constexpr if section here: https://en.cppreference.com/w/cpp/language/if


>
> Regards,
> Manu
>
>
>
> --
> *From:* David Blaikie 
> *Sent:* Saturday, August 22, 2020 2:14 AM
> *To:* Manu agarwal 
> *Cc:* cfe-users@lists.llvm.org 
> *Subject:* Re: [cfe-users] inconsistent compilation error inside
> constexpr if
>
> From what I could test on godbolt, using LLVM evrsions back to 5.0,
> Clang does reject the "return ClientMain();" call you aren't seeing an
> error on. So I'm not sure what compiler/version/situation you're
> running, but at least at first blush it doesn't look like clang.
>
> On Fri, Aug 21, 2020 at 1:29 PM Manu agarwal via cfe-users
>  wrote:
> >
> > Hello,
> >
> > In the below code the compiler throws "undeclared identifier" when the
> commented line is uncommented. Whereas the line just before compiles fine.
> >
> > Regards,
> > Manu
> >
> > typedef bool (* DummyFunc)   ();
> >
> >
> > bool ExecDummy (DummyFunc fptr) {
> >
> > if (fptr)
> > return fptr ();
> >
> > return false;
> > }
> >
> > constexpr unsigned int IsMyAppClient = 0;
> >
> > constexpr bool CheckForTypeClient (unsigned int pAppType)
> > {
> > return ((pAppType & IsMyAppClient) != 0);
> > }
> >
> >
> > class  MyAppTemplate
> > {
> > public:
> > template 
> > staticboolMyAppInit ();
> > };
> >
> > template 
> > bool
> > MyAppTemplate::MyAppInit ()
> > {
> > if constexpr (CheckForTypeClient(T)) {
> >
> > return ClientMain ();// no error
> > //return ExecDummy(ClientMain);// error: use of
> undeclared identifier 'ClientMain'
> > }
> >
> > return false;
> > }
> >
> > int __cdecl
> > main (int pArgc, char* pArgv[])
> > {
> > constexpr int TVal = 3;
> >
> > MyAppTemplate::MyAppInit ();
> >
> > return 0;
> > }
> >
> >
> > ___
> > 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] inconsistent compilation error inside constexpr if

[David Blaikie via cfe-users]

From what I could test on godbolt, using LLVM evrsions back to 5.0,
Clang does reject the "return ClientMain();" call you aren't seeing an
error on. So I'm not sure what compiler/version/situation you're
running, but at least at first blush it doesn't look like clang.

On Fri, Aug 21, 2020 at 1:29 PM Manu agarwal via cfe-users
 wrote:
>
> Hello,
>
> In the below code the compiler throws "undeclared identifier" when the 
> commented line is uncommented. Whereas the line just before compiles fine.
>
> Regards,
> Manu
>
> typedef bool (* DummyFunc)   ();
>
>
> bool ExecDummy (DummyFunc fptr) {
>
> if (fptr)
> return fptr ();
>
> return false;
> }
>
> constexpr unsigned int IsMyAppClient = 0;
>
> constexpr bool CheckForTypeClient (unsigned int pAppType)
> {
> return ((pAppType & IsMyAppClient) != 0);
> }
>
>
> class  MyAppTemplate
> {
> public:
> template 
> staticboolMyAppInit ();
> };
>
> template 
> bool
> MyAppTemplate::MyAppInit ()
> {
> if constexpr (CheckForTypeClient(T)) {
>
> return ClientMain ();// no error
> //return ExecDummy(ClientMain);// error: use of 
> undeclared identifier 'ClientMain'
> }
>
> return false;
> }
>
> int __cdecl
> main (int pArgc, char* pArgv[])
> {
> constexpr int TVal = 3;
>
> MyAppTemplate::MyAppInit ();
>
> return 0;
> }
>
>
> ___
> 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] Adding linker flag `-save-temps` resolves the clang-8 error: "unable to make temporary file"

[David Blaikie via cfe-users]

Oh, sorry, I didn't read the question in detail about how -save-temps
was making things work when they otherwise were not.

If you run clang with -### it'll show the command lines it's using,
which should show you where it's trying to write the files so you can
change that/make them writable. I'm not sure which variable is used to
influence clang's temporary directory choice, though.

On Thu, Aug 13, 2020 at 11:22 AM Danijel DOMAZET
 wrote:
>
> Thanks Fang-rui.
> I still haven't been able to fix the issue, I still use --save-temps, and 
> that makes linking very slow.
> Why does this error go away when I set --save-temps, any idea??
>
>
>
> On Thu, Aug 13, 2020 at 7:16 PM Fāng-ruì Sòng  wrote:
>>
>> On Thu, Aug 13, 2020 at 8:59 AM David Blaikie  wrote:
>> >
>> > On Thu, Aug 13, 2020 at 2:59 AM Danijel DOMAZET
>> >  wrote:
>> > >
>> > > Thanks David.
>> > > Why do you think this could be about current dir?
>> > > Isn't it about TMP (or TEMP or TMPDIR) environment variables?
>>
>> Neither the driver option -save-temps nor the linker option
>> --save-temps (driver option -Wl,--save-temps) respects
>> TMP/TEMP/TMPDIR.
>> The temporary files are saved relative to the current working
>> directory, which can be changed via -working-directory=
>>
>> > Because I ran it locally, and observed that that's where the files
>> > were written to.
>> >
>> > >
>> > > Thanks,
>> > > Danijel Domazet
>> > >
>> > >
>> > > On Thu, Aug 13, 2020 at 12:11 AM David Blaikie  
>> > > wrote:
>> > >>
>> > >> Looks like it writes the files to the current directory - do you have
>> > >> permission to access the current directory?
>> > >>
>> > >> On Wed, Aug 12, 2020 at 6:28 AM Danijel DOMAZET via cfe-users
>> > >>  wrote:
>> > >> >
>> > >> > Hi clang users,
>> > >> > I am using Windows10 + Cygwin + Eclipse +  LLVM toolchain to build a 
>> > >> > C/C++
>> > >> > project.
>> > >> >
>> > >> > The files compile fine, but linking with `clang++` fails with multiple
>> > >> > `error: unable to make temporary file: No such file or directory`.
>> > >> >
>> > >> > clang++ -o test "source1.bc" "source2.bc" "source3.bc"
>> > >> > clang-8: error: unable to make temporary file: No such file or 
>> > >> > directory
>> > >> > clang-8: error: unable to make temporary file: No such file or 
>> > >> > directory
>> > >> > clang-8: error: unable to make temporary file: No such file or 
>> > >> > directory
>> > >> >
>> > >> > Linker generates one error per each object file.
>> > >> >
>> > >> > However, when I add the `-save-temps` option to linker, it works OK.
>> > >> >
>> > >> > I am launching Eclipse.exe from within Cygwin. I have tried to set 
>> > >> > TMP,
>> > >> > TEMP to /temp, /temp/, /cygdrive/c/temp, etc, but nothing worked.
>> > >> >
>> > >> > What could be the problem?
>> > >> >
>> > >> > Thanks,
>> > >> > Danijel Domazet
>> > >> >
>> > >> >
>> > >> >
>> > >> > - Confidential -
>> > >> > ___
>> > >> > cfe-users mailing list
>> > >> > cfe-users@lists.llvm.org
>> > >> > https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
>> > >
>> > >
>> > > - Confidential -
>>
>>
>>
>> --
>> 宋方睿
>
>
> - Confidential -
___
cfe-users mailing list
cfe-users@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users

Re: [cfe-users] Adding linker flag `-save-temps` resolves the clang-8 error: "unable to make temporary file"

[David Blaikie via cfe-users]

On Thu, Aug 13, 2020 at 2:59 AM Danijel DOMAZET
 wrote:
>
> Thanks David.
> Why do you think this could be about current dir?
> Isn't it about TMP (or TEMP or TMPDIR) environment variables?

Because I ran it locally, and observed that that's where the files
were written to.

>
> Thanks,
> Danijel Domazet
>
>
> On Thu, Aug 13, 2020 at 12:11 AM David Blaikie  wrote:
>>
>> Looks like it writes the files to the current directory - do you have
>> permission to access the current directory?
>>
>> On Wed, Aug 12, 2020 at 6:28 AM Danijel DOMAZET via cfe-users
>>  wrote:
>> >
>> > Hi clang users,
>> > I am using Windows10 + Cygwin + Eclipse +  LLVM toolchain to build a C/C++
>> > project.
>> >
>> > The files compile fine, but linking with `clang++` fails with multiple
>> > `error: unable to make temporary file: No such file or directory`.
>> >
>> > clang++ -o test "source1.bc" "source2.bc" "source3.bc"
>> > clang-8: error: unable to make temporary file: No such file or 
>> > directory
>> > clang-8: error: unable to make temporary file: No such file or 
>> > directory
>> > clang-8: error: unable to make temporary file: No such file or 
>> > directory
>> >
>> > Linker generates one error per each object file.
>> >
>> > However, when I add the `-save-temps` option to linker, it works OK.
>> >
>> > I am launching Eclipse.exe from within Cygwin. I have tried to set TMP,
>> > TEMP to /temp, /temp/, /cygdrive/c/temp, etc, but nothing worked.
>> >
>> > What could be the problem?
>> >
>> > Thanks,
>> > Danijel Domazet
>> >
>> >
>> >
>> > - Confidential -
>> > ___
>> > cfe-users mailing list
>> > cfe-users@lists.llvm.org
>> > https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
>
>
> - Confidential -
___
cfe-users mailing list
cfe-users@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users

Re: [cfe-users] Adding linker flag `-save-temps` resolves the clang-8 error: "unable to make temporary file"

[David Blaikie via cfe-users]

Looks like it writes the files to the current directory - do you have
permission to access the current directory?

On Wed, Aug 12, 2020 at 6:28 AM Danijel DOMAZET via cfe-users
 wrote:
>
> Hi clang users,
> I am using Windows10 + Cygwin + Eclipse +  LLVM toolchain to build a C/C++
> project.
>
> The files compile fine, but linking with `clang++` fails with multiple
> `error: unable to make temporary file: No such file or directory`.
>
> clang++ -o test "source1.bc" "source2.bc" "source3.bc"
> clang-8: error: unable to make temporary file: No such file or directory
> clang-8: error: unable to make temporary file: No such file or directory
> clang-8: error: unable to make temporary file: No such file or directory
>
> Linker generates one error per each object file.
>
> However, when I add the `-save-temps` option to linker, it works OK.
>
> I am launching Eclipse.exe from within Cygwin. I have tried to set TMP,
> TEMP to /temp, /temp/, /cygdrive/c/temp, etc, but nothing worked.
>
> What could be the problem?
>
> Thanks,
> Danijel Domazet
>
>
>
> - Confidential -
> ___
> 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] Binary modifications

[David Blaikie via cfe-users]

I don't think clang/llvm provides much in the way of infrastructure
that would help with that task. I've seen things like that done with
https://github.com/microsoft/detours fwiw.

On Fri, Jul 24, 2020 at 7:34 AM Mahmood Naderan via cfe-users
 wrote:
>
> Hi,
> I would like to know if it is possible to modify a binary file with
> some custom assembly instructions. Specifically, I want to add some
> jump instruction at the end of some basic blocks that I want to
> reorder. Is there any starting point for that?
>
> Regards,
> Mahmood
> ___
> 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] How is clang binary compatibility?

[David Blaikie via cfe-users]

In the sense of "can I link an object built with clang 10 with an
object built with clang 7" - generally: yes. That's defined by the
Itanium ABI, the same thing that lets you link Clang built objects
with GCC built objects, for instance.

On Sun, Jul 12, 2020 at 9:29 AM Danny Zhu via cfe-users
 wrote:
>
> Hi,
> I searched quite a while but can’t find any explicit documentation talking 
> about clang’s binary compatibility status among different builds. Can you 
> share some information about this? Especially I want know if clang 10 is 
> binary compatible with clang 7?
>
>
>
> Thanks,
> Danny
>
> ___
> 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] Please help

[David Blaikie via cfe-users]

On Sun, Jun 14, 2020 at 2:13 PM JacobK622 via cfe-users
 wrote:
>
> To, llvm/clang
>  Firstly I'd like to preface this by saying a few things:
>
> 1. I don't always know what is or isn't socially appropriate to 
> say/ask/do, so please don't get mad at me if I say/ask/do something 
> inappropriate just let me know and I'll try to do better.
>
> 2. Sometimes I word things oddly so if a phrase sounds weird or doesn't 
> make sense please let me know and I'll try to explain.
>
> 3. I want to make it VERY clear that the above statement should in no way 
> be misinterpreted to say that 'I think you're dumb' (because I don't.)
>
> 4. I'm not sure this is the correct email to send this to if it isn't:
> a. I'm sorry
> b. Would you please give me the correct email address? Thanks

Seems like a good a spot as any to post this (other places could
include the "include++" discord ( https://discord.com/invite/ZPErMGW
), the LLVM discord ( https://discord.com/invite/xS7Z362 ) or Stack
Overflow ( https://stackoverflow.com/questions/tagged/c%2B%2B )
(though that last one can be a bit rougher))

> Anyway...
>
> 1) How do I compile c/c++ programs for Windows using llvm/clang without the 
> use of Microsoft Visual Studio?

I don't believe that's possible - Microsoft's/Visual Studio's header
files/libraries are needed, even when using clang/llvm/lld to compile
and link.

> The main reason i wanted to use llvm/clang was/is because it is free/open 
> source so being required to use Microsoft Visual Studio (which is Proprietary 
> (I think) it also costs money) would defeat the purpose.

I don't believe you need to spend any money - I think the free (Visual
Studio Code or Visual Studio Express or something like that I think
provides the libraries/headers without having to pay for anything)
options exist.


> 2) How do I cross-compile applications for Windows and/or MacOS?

Not too familiar with that - I think it's something to do with -target
or -triple, but setting up any system library headers, etc, might be a
bit more involved.

> My email is jacobk...@protonmail.com feel free to email me at any time,
> although I may not respond immediately. (usually within 24hrs.)
> From, Jacob K
>
> Sent with ProtonMail Secure Email.
>
> ___
> 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] Implicit or explicit public inheritance in the AST

[David Blaikie via cfe-users]

Looks like comparing getAccessSpecifierAsWritten with
getAccessSpecifier might help:
https://clang.llvm.org/doxygen/classclang_1_1CXXBaseSpecifier.html#a6abcd6d5d707f4cab88bab1fc916bfad

On Mon, Jun 8, 2020 at 1:09 PM Csaba Raduly via cfe-users
 wrote:
>
> Hi all,
>
> If I run `clang++ -std=c++17 -Xclang -ast-dump` on the following code:
>
> struct B {};
>
> struct D1 : B {};
>
> struct D2 : public B {};
>
> the output is
>
> |-CXXRecordDecl 0x8000bdd48  col:8 referenced struct B 
> definition
> | |-DefinitionData pass_in_registers empty aggregate standard_layout 
> trivially_copyable pod trivial literal has_constexpr_non_copy_move_ctor 
> can_const_default_init
> | | |-DefaultConstructor exists trivial constexpr needs_implicit 
> defaulted_is_constexpr
> | | |-CopyConstructor simple trivial has_const_param needs_implicit 
> implicit_has_const_param
> | | |-MoveConstructor exists simple trivial needs_implicit
> | | |-CopyAssignment trivial has_const_param needs_implicit 
> implicit_has_const_param
> | | |-MoveAssignment exists simple trivial needs_implicit
> | | `-Destructor simple irrelevant trivial needs_implicit
> | `-CXXRecordDecl 0x8000bde58  col:8 implicit struct B
> |-CXXRecordDecl 0x8000bdef8  col:8 struct D1 definition
> | |-DefinitionData pass_in_registers empty aggregate standard_layout 
> trivially_copyable trivial literal has_constexpr_non_copy_move_ctor 
> can_const_default_init
> | | |-DefaultConstructor exists trivial constexpr needs_implicit 
> defaulted_is_constexpr
> | | |-CopyConstructor simple trivial has_const_param needs_implicit 
> implicit_has_const_param
> | | |-MoveConstructor exists simple trivial needs_implicit
> | | |-CopyAssignment trivial has_const_param needs_implicit 
> implicit_has_const_param
> | | |-MoveAssignment exists simple trivial needs_implicit
> | | `-Destructor simple irrelevant trivial needs_implicit
> | |-public 'B'
> | `-CXXRecordDecl 0x80015c878  col:8 implicit struct D1
> `-CXXRecordDecl 0x80015c918  col:8 struct D2 definition
>   |-DefinitionData pass_in_registers empty aggregate standard_layout 
> trivially_copyable trivial literal has_constexpr_non_copy_move_ctor 
> can_const_default_init
>   | |-DefaultConstructor exists trivial constexpr needs_implicit 
> defaulted_is_constexpr
>   | |-CopyConstructor simple trivial has_const_param needs_implicit 
> implicit_has_const_param
>   | |-MoveConstructor exists simple trivial needs_implicit
>   | |-CopyAssignment trivial has_const_param needs_implicit 
> implicit_has_const_param
>   | |-MoveAssignment exists simple trivial needs_implicit
>   | `-Destructor simple irrelevant trivial needs_implicit
>   |-public 'B'
>   `-CXXRecordDecl 0x80015ca68  col:8 implicit struct D2
> I can see no difference between the CXXRecordDecl for D1 and D2. Is there a 
> way to tell, when visiting the AST, whether the inheritance of the derived 
> class was specified implicitly or explicitly? (Hopefully yes, just not 
> visible in the output of ast-dump).
>
>
> Csaba
> Sent from my 12-core Windows machine, using Gmail.
> --
> You can get very substantial performance improvements
> by not doing the right thing. - Scott Meyers, An Effective C++11/14 Sampler
> So if you're looking for a completely portable, 100% standards-conformant way
> to get the wrong information: this is what you want. - Scott Meyers 
> (C++TDaWYK)
> ___
> 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] Linking problem with implicit instantiation of constructor/destructor

[David Blaikie via cfe-users]

I don't believe this code is valid according to C++. I believe it would
require an explicit instantiation of the ctor/dtor somewhere to make that
code valid - though I don't have chapter and verse on the spec at hand just
now to back that up.

On Fri, Apr 17, 2020 at 6:54 AM Jaroslav Zeman via cfe-users <
cfe-users@lists.llvm.org> wrote:

> Hello,
>
> I've run into wieird problem when trying to compile and link our programs
> with
> clang++ on linux instead of g++. It occurs, when:
>  - template class member definitions are separated from the definition of
> the
> class
> - no explicit instantiation is done
> - member definitions are available only in some of the units, where the
> template is being used.
> (Yeah, our code is a mess)
>
> This is simple expamle:
> // - template.h 
> template< typename T >
> struct Template {
>   Template();
>   ~Template();
> };
>
> void doSomething(Template& t);
>
> // - template.cpp 
> #include "template.h"
>
> template< typename T >
> Template< T >::Template() { }
>
> template< typename T>
> Template< T >::~Template() { }
>
> void doSomething(Template& t) {
>   Template new_t;
>   t = new_t;
> }
>
> // - main.cpp 
> #include "template.h"
>
> int main(int argc_, char** argv_) {
>
>   Template t;
>   doSomething(t);
>
>   return 0;
> }
> // - end of code
>
> When compiled with clang++:
> $ clang++ -o test main.cpp template.cpp
> /usr/bin/ld: /tmp/main-e2fa2c.o: in function `main':
> main.cpp:(.text+0x2f): undefined reference to `Template::Template()'
> /usr/bin/ld: main.cpp:(.text+0x4d): undefined reference to
> `Template::~Template()'
> /usr/bin/ld: main.cpp:(.text+0x82): undefined reference to
> `Template::~Template()'
>
> reading the object files using nm tool shows, the symbol for destructor
> instantiated in template.cpp is _ZN8TemplateIiED2Ev, but the main.o
> requires
> symbol _ZN8TemplateIiED1Ev. Notice the difference in one digit: D2 vs D1.
>
> So symbol ...D1... is required, but only ...D2... is available. The D1
> version
> is generated by clang only for explicit instantiation. g++ generates both
> D1
> and D2 for any type of instantiation.
>
> Can this be considered a bug of clang++? Or does this behaior have some
> purpose?
>
> Regards,
> JZ
>
>
> ___
> 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 building llvm from source

[David Blaikie via cfe-users]

What make command did you run?

On Sat, Mar 7, 2020 at 8:09 AM Mahmood Naderan via cfe-users <
cfe-users@lists.llvm.org> wrote:

> Hi,
> I want to use a specific revision number and for the cmake command below
>
> cmake ~/codestitcher/source/llvm-3.9 -DCMAKE_BUILD_TYPE=Release
> -DLLVM_TARGETS_TO_BUILD=host -DLLVM_ENABLE_CXX1Y=ON -DLLVM_BUILD_TESTS=OFF
> -DLLVM_BINUTILS_INCDIR=~/codestitcher/source/binutils-2.30/include
> -DLLVM_BUILD_TOOLS=OFF -DCMAKE_C_COMPILER=gcc -DCMAKE_CXX_COMPILER=g++
>
>
> I get this error for make command
>
> [ 43%] Building CXX object
> lib/Analysis/CMakeFiles/LLVMAnalysis.dir/CFGPrinter.cpp.o
> [ 43%] Linking CXX static library ../../libLLVMScalarOpts.a
> [ 43%] Built target LLVMScalarOpts
> [ 43%] Generating LLVMLTORevision.h
> -- Found Subversion: /bin/svn (found version "1.7.14")
> CMake Error at
> ~/tools/cmake-3.15.4/share/cmake-3.15/Modules/FindSubversion.cmake:124
> (message):
>   Command "/bin/svn info
>   ~/codestitcher/source/llvm-3.9" failed with output:
>
>   svn: E155036: Please see the 'svn upgrade' command
>
>   svn: E155036: Working copy
>   '~/codestitcher/source/llvm-3.9' is too old (format
>   10, created by Subversion 1.6)
>
> Call Stack (most recent call first):
>   ~/codestitcher/source/llvm-3.9/cmake/modules/VersionFromVCS.cmake:19
> (subversion_wc_info)
>
> ~/codestitcher/source/llvm-3.9/cmake/modules/GenerateVersionFromCVS.cmake:27
> (add_version_info_from_vcs)
>
> ~/codestitcher/source/llvm-3.9/cmake/modules/GenerateVersionFromCVS.cmake:33
> (append_info)
>
>
> make[2]: *** [lib/LTO/LLVMLTORevision.h] Error 1
> make[2]: *** Deleting file `lib/LTO/LLVMLTORevision.h'
> make[1]: *** [lib/LTO/CMakeFiles/LLVMLTO.dir/all] Error 2
> make[1]: *** Waiting for unfinished jobs
> [ 43%] Building CXX object
> lib/Analysis/CMakeFiles/LLVMAnalysis.dir/CFLAndersAliasAnalysis.cpp.o
> [ 43%] Building CXX object
> lib/Analysis/CMakeFiles/LLVMAnalysis.dir/CFLSteensAliasAnalysis.cpp.o
> [ 43%] Building CXX object
> lib/Analysis/CMakeFiles/LLVMAnalysis.dir/CGSCCPassManager.cpp.o
> [ 43%] Building CXX object
> lib/Analysis/CMakeFiles/LLVMAnalysis.dir/CallGraph.cpp.o
> [ 43%] Building CXX object
> lib/Analysis/CMakeFiles/LLVMAnalysis.dir/CallGraphSCCPass.cpp.o
>
>
> Is there any workaround for that?
>
> Regards,
> Mahmood
>
>
> ___
> 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] How to determine if variable is templated?

[David Blaikie via cfe-users]

Guessing these sort of functions would be relevant:
https://clang.llvm.org/doxygen/classclang_1_1VarDecl.html#a617bcdd5baaab0ccba71a96cd9c2ed03

On Sun, Feb 16, 2020 at 5:43 PM Robert Ankeney via cfe-users <
cfe-users@lists.llvm.org> wrote:

> Suppose I have some code like:
>
> template
> Type tVar;
> function(tVar);
>
> How can I determine that tVar is templated from the VarDecl or a
> MemberExpr? I don't see any obvious function in QualType or Type.
>
> Thanks,
> Robert
>
> ___
> 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] clangd --clang-tidy: // NOLINT only works sometimes

[David Blaikie via cfe-users]

+Sam in case he's got some thoughts or can rope in others who might.

On Sun, Jan 26, 2020 at 1:03 PM tastytea via cfe-users <
cfe-users@lists.llvm.org> wrote:

> Hi,
> I recently started using clangd (9.0.1) with --clang-tidy. I noticed
> that suppressing diagnostics only sometimes works.
>
> For example:
> using std::array; // NOLINT(misc-unused-using-decls)
> works with clang-tidy and clangd, but
> curl_global_init(CURL_GLOBAL_ALL); // NOLINT(hicpp-signed-bitwise)
> works only with clang-tidy, not with clangd.
>
> I found the review[1] of the feature when it was introduced but I don't
> really understand what's going on there…
>
> Is this a bug or can some warnings not be suppressed?
>
> Kind regards, tastytea
>
> [1] 
> ___
> 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] DeclRefExpr question

[David Blaikie via cfe-users]

I'd guess you'd call "getDecl" to get the decl the DeclRefExpr is
referencing, then dyn_cast that (the decl is a ValueDecl*) to VarDecl to
see if it's a variable that's being referenced (could be a function, etc,
etc) then do whatever you want to do with that VarDecl.

On Tue, Dec 3, 2019 at 1:33 PM Robert Ankeney via cfe-users <
cfe-users@lists.llvm.org> wrote:

> Let's assume I have a DeclRefExpr that is referenceing some variable that
> is declared as "static const int var;". How can I determine the variable is
> static? There is no isStaticLocal() or getStorageClass() call as there
> would be for the VarDecl. Is there something within the QualType that gets
> me that info?
>
> Many thanks,
> Robert
>
> ___
> 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] dumb question about record-command-line

[David Blaikie via cfe-users]

Depends on your platform, but probably in some section or another in the
object/executable. Try running objdump (or llvm-objdump) -h on the object
or executable with/without the switch and see which new section shows up.
Then you can use objdump -s (I think it's -s, check the man page, etc) to
dump the contents of that section.

On Tue, Nov 19, 2019 at 8:44 AM Jerry Scharf via cfe-users <
cfe-users@lists.llvm.org> wrote:

> Hi,
>
> I have an exceeding dumb question.
>
> If I turn on -frecord-command-line, how do I view it in the object
> files, libraries and executables? No matter what I incant to google, it
> only wants to tell me what the command line arguments are.
>
> thanks in advance,
>
> jerry
>
>
> ___
> 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

[David Blaikie via cfe-users]

Looks like valgrind catches some things around here:

==115793== Conditional jump or move depends on uninitialised value(s)
==115793==at 0x402671: main (t-sqrlo.c:106)
==115793==
==115793== Conditional jump or move depends on uninitialised value(s)
==115793==at 0x40268A: main (t-sqrlo.c:107)
==115793==



On Thu, Nov 7, 2019 at 9:42 AM David Blaikie  wrote:

> UBSan doesn't cover this sort of thing - MSan is the sanitizer for
> catching uninitialized values. (MSan is, unfortunately, a bit more finicky
> to use because the whole program (including the standard library) must be
> compiled with the feature enabled for it to work correctly - I don't have
> an MSan enabled environment to test whether it would've caught this bug or
> not)
>
> On Thu, Nov 7, 2019 at 9:15 AM Hans Åberg  wrote:
>
>>
>> > On 7 Nov 2019, at 15:24, Hans Wennborg  wrote:
>> >
>> > Looking at LLVM's -print-after-all shows a diff after GVN which seems
>> > to come from this if-statement in tests/mpn/t-sqrlo.c:
>> >
>> >  if (pp[-1] != p_before || pp[n] != p_after
>> >  || scratch[-1] != s_before || scratch[itch] != s_after
>> >  || mpn_cmp (refp, pp, n) != 0)
>> > {
>> >
>> > It looks like the "scratch[-1] != s_before" expression was previously
>> > folded to false, but now it's folded to undef (and the branch ends up
>> > going the other way). That matches the commit message from the
>> > bisection.
>>
>> GMP bugs may be reported to their bug list, and the UBSan might be
>> strengthened to capture this.
>>
>>
>>
___
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

[David Blaikie via cfe-users]

UBSan doesn't cover this sort of thing - MSan is the sanitizer for catching
uninitialized values. (MSan is, unfortunately, a bit more finicky to use
because the whole program (including the standard library) must be compiled
with the feature enabled for it to work correctly - I don't have an MSan
enabled environment to test whether it would've caught this bug or not)

On Thu, Nov 7, 2019 at 9:15 AM Hans Åberg  wrote:

>
> > On 7 Nov 2019, at 15:24, Hans Wennborg  wrote:
> >
> > Looking at LLVM's -print-after-all shows a diff after GVN which seems
> > to come from this if-statement in tests/mpn/t-sqrlo.c:
> >
> >  if (pp[-1] != p_before || pp[n] != p_after
> >  || scratch[-1] != s_before || scratch[itch] != s_after
> >  || mpn_cmp (refp, pp, n) != 0)
> > {
> >
> > It looks like the "scratch[-1] != s_before" expression was previously
> > folded to false, but now it's folded to undef (and the branch ends up
> > going the other way). That matches the commit message from the
> > bisection.
>
> GMP bugs may be reported to their bug list, and the UBSan might be
> strengthened to capture this.
>
>
>
___
cfe-users mailing list
cfe-users@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users

Re: [cfe-users] Why is clang defining NULL as __null ??

[David Blaikie via cfe-users]

clang generally also understands __null (for the same reasons GCC does - to
provide better diagnostics when using NULL in non-pointer contexts). See,
for example, this warning (not an error): https://godbolt.org/z/KvdW7a

Can't say I know much about the NDK or what version of clang it has, what
flags you might be passing, or why else it might be having trouble with
__null, unfortunately.

On Mon, Nov 4, 2019 at 9:15 AM pendyala syam via cfe-users <
cfe-users@lists.llvm.org> wrote:

> I have a .cpp file which has usage of *NULL* at several places. When I
> try to compile this cpp file for Android/x86 platform using clang++ on
> Windows machine + standalone tool chain, I am running into "expected
> expression" error at the places where *NULL* is used. I find the
> definition of *NULL* in stddef.h of clang headers provided by Android NDK
> as below.
>
> #if defined(__need_NULL)#undef NULL#ifdef __cplusplus#  if 
> !defined(__MINGW32__) && !defined(_MSC_VER)#define NULL __null#  else#
> define NULL 0#  endif#else#  define NULL ((void*)0)#endif
>
> As far as I know, __null is specific to GNU compiler. In my case both
> _MSC_VER and __MINGW32__ are undefined because I am compiling for Android
> platform using clang++ and standalone tool chain. So it is hitting into define
> NULL __null. Since clang++ has no clue of what __null is, it is resulting
> into "expected expression" error.
>
> My question is, why is clang using macros(like __null) provided by GNU
> compiler? Or am I missing something here?
>
> Could somebody please help me understand. Thanks
> ___
> 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

[David Blaikie via cfe-users]

On Thu, Oct 31, 2019 at 1:51 PM Hans Åberg  wrote:

>
> > On 31 Oct 2019, at 21:40, David Blaikie  wrote:
> >
> >> On Thu, Oct 31, 2019 at 12:00 PM Hans Åberg  wrote:
> >>
> >> > On 31 Oct 2019, at 18:40, David Blaikie  wrote:
> >> >
> >> >> Right, but that is something one would avoid when computing
> arithmetical results.
> >> >
> >> > One would try to, yes - but that's sort of what the whole discussion
> is resolving around: Is the code correct? I don't know. I wouldn't assume
> it is (I'm not assuming it isn't either) - but without a reduced test case
> that gets to the root of the difference in behavior, we don't know if the
> code is correct.
> >>
> >> Nor whether it is a compiler bug.
> >
> > Indeed - but you can imagine that, on average (just due to there being
> way more code compiled by the compiler, than the code of the compiler
> itself) the bug is in external code, not the compiler.
>
> GMP is not the average program, though.
>
> > 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. 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.


> > Apologies for the snark in the title of this article, but it covers some
> of the ideas:
> https://blog.codinghorror.com/the-first-rule-of-programming-its-always-your-fault/
> & other articles around discuss similar ideas.
>
> This article is pretty naive: Yes, it is a good starting point to check
> ones own code first, but eventually one learns to identify compiler bugs as
> well. It is very time consuming, though.
>

Certainly - which is why it's not practical for compiler engineers to be
spending all that time on everyone's bugs, right?


> > Yes, there are compiler bugs - but you've sort of got to continue under
> the assumption that that's not the issue until you've got some fairly
> compelling evidence of one (very narrow test case where you can look at all
> the code & visually inspect/discuss/reason about its standards conformance
> - currently "all of GMP" is too big to apply that level of scrutiny).
>
> GMP is indeed very complex, not only from a programming point of view, but
> also the underlying algorithms.
>

Yep - which makes it all the harder for me or someone else on the LLVM
project to likely be able to find any potential compiler bugs in it.

- Dave
___
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

[David Blaikie via cfe-users]

On Thu, Oct 31, 2019 at 12:00 PM Hans Åberg  wrote:

>
> > On 31 Oct 2019, at 18:40, David Blaikie  wrote:
> >
> >> Right, but that is something one would avoid when computing
> arithmetical results.
> >
> > One would try to, yes - but that's sort of what the whole discussion is
> resolving around: Is the code correct? I don't know. I wouldn't assume it
> is (I'm not assuming it isn't either) - but without a reduced test case
> that gets to the root of the difference in behavior, we don't know if the
> code is correct.
>
> Nor whether it is a compiler bug.
>

Indeed - but you can imagine that, on average (just due to there being way
more code compiled by the compiler, than the code of the compiler itself)
the bug is in external code, not the compiler. 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.

Apologies for the snark in the title of this article, but it covers some of
the ideas:
https://blog.codinghorror.com/the-first-rule-of-programming-its-always-your-fault/
&
other articles around discuss similar ideas.

Yes, there are compiler bugs - but you've sort of got to continue under the
assumption that that's not the issue until you've got some fairly
compelling evidence of one (very narrow test case where you can look at all
the code & visually inspect/discuss/reason about its standards conformance
- currently "all of GMP" is too big to apply that level of scrutiny).

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

Re: [cfe-users] clang-tidy bug?

[David Blaikie via cfe-users]

On Thu, Oct 31, 2019 at 11:19 AM Aaron Ballman 
wrote:

> On Thu, Oct 31, 2019 at 1:31 PM David Blaikie  wrote:
> >
> >
> >
> > On Thu, Oct 31, 2019 at 8:45 AM Aaron Ballman 
> wrote:
> >>
> >> On Wed, Oct 30, 2019 at 9:23 PM David Blaikie 
> wrote:
> >> >
> >> > Two separate issues here
> >> >
> >> > 1) the fixit hint, as one of a set of alternatives, isn't likely to
> be removed/changed - the (albeit quirky) convention of using extra () to
> indicate an intentional assignment in a condition has been around for a
> while. So if you use the extra parens without writing an assignment, the
> compiler's going to suggest you resolve this "conflict" with the style -
> either you didn't intend the extra (), or you intended to use assignment.
> Those are the two alternative suggestions being made.
> >> >
> >> > 2) automatically applying one fixit hint of several ambiguous ones
> seems like a bug to me - Aaron - do you know anything about this? Is this
> accurate/intended/etc?
> >>
> >> I also think that's a bug. It looks like it's coming from
> >> Sema::DiagnoseEqualityWithExtraParens(). It looks like it presents
> >> both fixits, which strikes me as a bad thing to do when automatically
> >> applying fixits.
> >
> >
> > These fixits should be attached to notes, though, right? & Clang
> produces all sorts of fixits on notes that are not semantics-preserving, I
> think? ("oh, I think you meant to write this other thing")
>
> Yes, they're both attached to notes but the notes point to the same
> location as the error.
>
> > My understanding is that the fixits are correct (in the clang diagnostic
> experience - "here's a warning, here are some ideas of what you might've
> intended that would address the warning") - but it seems incorrect to
> automatically apply especially ambiguous suggesitons like this. How would
> clang-tidy choose between the two alternatives?
>
> I don't think it has a way to select between alternatives; I don't
> think that was a use case we had envisioned for automatically applying
> fix-its.
>

I wasn't thinking a way to select - but I'd expect an automated tool to,
when presented with an ambiguity, decide that not doing anything was the
best course of action (same as if the warning had no notes).


>
> ~Aaron
>
> >
> >>
> >>
> >> ~Aaron
> >>
> >> >
> >> > On Tue, Oct 29, 2019 at 10:13 AM Robert Ankeney 
> wrote:
> >> >>
> >> >> This was just a example of what I ran into when I used
> run-clang-tidy.py across a compilation database with a
> -export-fixes=fix.yaml and then ra
> >> >>  clang-apply-replacements. Mainly I object to the suggestion+fixit
> to switch to an assignment. Most coding standards would disallow assignments
> >> >> in if conditionals. If anything, I would think a suggestion of "if
> (true == isValid)" would be more appropriate.
> >> >>
> >> >> Thanks for the feedback!
> >> >> Robert
> >> >>
> >> >> On Mon, Oct 28, 2019 at 2:17 PM David Blaikie 
> wrote:
> >> >>>
> >> >>> clang-tidy in the command line you gave didn't seem to modify the
> file for me, did it modify the file for you?
> >> >>>
> >> >>> Are you objecting to the suggestion, or that it was automatically
> applied? I would think it'd be a bug to apply any fixit/hint if there are
> multiple possible suggestions.
> >> >>>
> >> >>> But the existence of the suggestion (without the application of it)
> to the user seems right to me. The use of extra () to suppress the
> assignment-in-conditional warning (-Wparentheses) has been around for quite
> a while, so it's possible that the user intended assignment rather than
> comparison when they added the extra parentheses.
> >> >>>
> >> >>> - Dave
> >> >>>
> >> >>> On Sun, Oct 27, 2019 at 11:32 AM Robert Ankeney via cfe-users <
> cfe-users@lists.llvm.org> wrote:
> >> 
> >>  For the following code (wrong.cpp):
> >> 
> >>  bool check(bool isValid)
> >>  {
> >>  bool retVal = false;
> >> 
> >>  if (( isValid == true ))
> >>  {
> >>  retVal = true;
> >>  }
> >> 
> >>  return retVal;
> >>  }
> >> 
> >>  when I run:
> >>  clang-tidy -checks=modernize-use-default-member-init wrong.cpp
> >> 
> >>  I get:
> >>  4 warnings and 1 error generated.
> >>  Error while processing /llvm/match/ctBad/wrong.cpp.
> >>  /llvm/match/ctBad/wrong.cpp:5:19: error: equality comparison with
> extraneous parentheses [clang-diagnostic-parentheses-equality]
> >>  if (( isValid == true ))
> >>  ~ ^~  ~
> >>    =
> >>  /llvm/match/ctBad/wrong.cpp:5:19: note: remove extraneous
> parentheses around the comparison to silence this warning
> >>  /llvm/match/ctBad/wrong.cpp:5:19: note: use '=' to turn this
> equality comparison into an assignment
> >> 
> >>  Note it turns the if into:
> >>  if ( isValid = true )
> >> 
> >>  Seems like a very bad idea. Removing the redundant parentheses
> seems fine, but changing 

Re: [cfe-users] Clang9 UBSan and GMP

[David Blaikie via cfe-users]

On Thu, Oct 31, 2019 at 2:30 AM Hans Åberg  wrote:

>
> > On 31 Oct 2019, at 01:53, David Blaikie  wrote:
> >
> >> Yes, but assuming that the GMP adheres to the C standard, there should
> be no difference in the arithmetical values produced.
> >
> > Not necessarily - C (well, I don't know the C standard as well as I know
> the C++ standard, admittedly) does allow various variations (implementation
> and unspecified behavior, for instance). eg: order of evaluation of
> function arguments (not that this is likely to vary due to optimizations -
> and doesn't with clang to the best of my knowledge, but as an example of
> the /sort/ of thing):
> >
> >   int f() {
> > static int i = 0;
> > return i++;
> >   }
> >   int f2(int i, int j) {
> > return i;
> >   }
> >   int main() {
> > return f2(f(), f());
> >   }
> >
> > This program could exit with 0 or 1 - both results are valid
> interpretations of the program per the standard. (again, I don't know the C
> spec quite as well, so I'm not sure exactly what it says about this code)
>
> Right, but that is something one would avoid when computing arithmetical
> results.
>

One would try to, yes - but that's sort of what the whole discussion is
resolving around: Is the code correct? I don't know. I wouldn't assume it
is (I'm not assuming it isn't either) - but without a reduced test case
that gets to the root of the difference in behavior, we don't know if the
code is correct.
___
cfe-users mailing list
cfe-users@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users

Re: [cfe-users] clang-tidy bug?

[David Blaikie via cfe-users]

Two separate issues here

1) the fixit hint, as one of a set of alternatives, isn't likely to be
removed/changed - the (albeit quirky) convention of using extra () to
indicate an intentional assignment in a condition has been around for a
while. So if you use the extra parens without writing an assignment, the
compiler's going to suggest you resolve this "conflict" with the style -
either you didn't intend the extra (), or you intended to use assignment.
Those are the two alternative suggestions being made.

2) automatically applying one fixit hint of several ambiguous ones seems
like a bug to me - Aaron - do you know anything about this? Is this
accurate/intended/etc?

On Tue, Oct 29, 2019 at 10:13 AM Robert Ankeney  wrote:

> This was just a example of what I ran into when I used run-clang-tidy.py
> across a compilation database with a -export-fixes=fix.yaml and then ra
>  clang-apply-replacements. Mainly I object to the suggestion+fixit to
> switch to an assignment. Most coding standards would disallow assignments
> in if conditionals. If anything, I would think a suggestion of "if (true
> == isValid)" would be more appropriate.
>
> Thanks for the feedback!
> Robert
>
> On Mon, Oct 28, 2019 at 2:17 PM David Blaikie  wrote:
>
>> clang-tidy in the command line you gave didn't seem to modify the file
>> for me, did it modify the file for you?
>>
>> Are you objecting to the suggestion, or that it was automatically
>> applied? I would think it'd be a bug to apply any fixit/hint if there are
>> multiple possible suggestions.
>>
>> But the existence of the suggestion (without the application of it) to
>> the user seems right to me. The use of extra () to suppress the
>> assignment-in-conditional warning (-Wparentheses) has been around for quite
>> a while, so it's possible that the user intended assignment rather than
>> comparison when they added the extra parentheses.
>>
>> - Dave
>>
>> On Sun, Oct 27, 2019 at 11:32 AM Robert Ankeney via cfe-users <
>> cfe-users@lists.llvm.org> wrote:
>>
>>> For the following code (wrong.cpp):
>>>
>>> bool check(bool isValid)
>>> {
>>> bool retVal = false;
>>>
>>> if (( isValid == true ))
>>> {
>>> retVal = true;
>>> }
>>>
>>> return retVal;
>>> }
>>>
>>> when I run:
>>> clang-tidy -checks=modernize-use-default-member-init wrong.cpp
>>>
>>> I get:
>>> 4 warnings and 1 error generated.
>>> Error while processing /llvm/match/ctBad/wrong.cpp.
>>> /llvm/match/ctBad/wrong.cpp:5:19: error: equality comparison with
>>> extraneous parentheses [clang-diagnostic-parentheses-equality]
>>> if (( isValid == true ))
>>> ~ ^~  ~
>>>   =
>>> /llvm/match/ctBad/wrong.cpp:5:19: note: remove extraneous parentheses
>>> around the comparison to silence this warning
>>> /llvm/match/ctBad/wrong.cpp:5:19: note: use '=' to turn this equality
>>> comparison into an assignment
>>>
>>> Note it turns the if into:
>>> if ( isValid = true )
>>>
>>> Seems like a very bad idea. Removing the redundant parentheses seems
>>> fine, but changing the comparison to an assignment does not. Is this a bug?
>>>
>>> Thanks,
>>> Robert
>>>
>>> ___
>>> 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

[David Blaikie via cfe-users]

On Wed, Oct 30, 2019 at 4:25 PM Hans Åberg  wrote:

>
> > On 30 Oct 2019, at 23:50, David Blaikie  wrote:
> >
> >> On Wed, Oct 30, 2019 at 2:29 PM Hans Åberg  wrote:
> >> Indeed, very hard to figure out. If it is some hidden undefined
> behavior causing it, the UBSan should have caught it, but it does not.
> >>
> > Right - but especially with numerics (especially floating point) there's
> loads of room for valid but different behavior between different compilers
> - behavior that isn't UB. How much precision a certain mathematical
> equation maintains is really at the whim of the optimizers in a lot of ways.
>
> I believe that GMP is just using integer types, and then uses that to make
> multiprecision integers, rational numbers, and floating point numbers. At
> least MPFR uses only the integer and rational number part of GMP, and
> builds multiprecision floating point numbers on top of that, which is
> necessary because of special requirements of the standards they adhere to.
>

Ah, fair enough - that narrows down the points of failure a little.

>> The link that Matthew gave says that the GMP developers experienced a
> number of such issues with Clang. One can though turn off the optimizer,
> and the tests pass.
> >
> > Sure - most of the numeric effects would only appear with optimizations.
> Without them every numeric operation's just done in registers, then written
> right back to memory (so no chance of excess precision leaking in by
> storing the value in an 80bit floating point register between multiple
> operations, or any risk of fused operations that produces extra precision,
> etc).
> >
> > The only way to know is to trace down/reduce the point where the values
> diverge & stare at the code to see who's right.
>
> GMP has been used in three years in a sequenced operation that must be
> exact and without errors to solve the problem [1], and I would think it
> used GCC with optimizations. So that puts Clang in a tough spot. :-)
>

Not as much as it would seem - again, the spec allows for a fair bit of
flexibility in a bunch of ways. (admittedly, within integer arithmetic
without invoking UB (but, again, that's not proven - UBSan isn't guaranteed
to catch everything)) Different compilers optimize code in different ways -
that the code "works"/produces the desired behavior on one compiler/under
some optimizations and not others doesn't give us much idea about whether
the code or the compiler is correct. Different behavior is acceptable in
C++ in a bunch of ways & compilers rely on that flexibility.

- Dave


>
> 1. https://gmplib.org/list-archives/gmp-discuss/2019-April/006319.html
>
>
>
___
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

[David Blaikie via cfe-users]

On Wed, Oct 30, 2019 at 2:29 PM Hans Åberg  wrote:

> Indeed, very hard to figure out. If it is some hidden undefined behavior
> causing it, the UBSan should have caught it, but it does not.


Right - but especially with numerics (especially floating point) there's
loads of room for valid but different behavior between different compilers
- behavior that isn't UB. How much precision a certain mathematical
equation maintains is really at the whim of the optimizers in a lot of ways.


> The link that Matthew gave says that the GMP developers experienced a
> number of such issues with Clang. One can though turn off the optimizer,
> and the tests pass.
>

Sure - most of the numeric effects would only appear with optimizations.
Without them every numeric operation's just done in registers, then written
right back to memory (so no chance of excess precision leaking in by
storing the value in an 80bit floating point register between multiple
operations, or any risk of fused operations that produces extra precision,
etc).

The only way to know is to trace down/reduce the point where the values
diverge & stare at the code to see who's right.

- Dave


>
>
> > On 30 Oct 2019, at 22:17, David Blaikie  wrote:
> >
> > I ran the test & understand it a bit better now - so the abort is part
> of the code, when the test fails, the test harness uses abort to fail.
> >
> > So this isn't "clang causes abort" (it didn't select a bad instruction,
> etc) this is "clang causes test failure" - this could be any number of
> things in terms of compiler optimizations due to overly dependent code (or
> due to miscompiles, to be sure). It's possible the test relies on specific
> numeric results that the C++ programming language doesn't guarantee (either
> overly high precision, or overly low precision - C++ allows extra precision
> in computations which can break numerical code that's relying on certain
> precision, for instance).
> >
> > So, yeah, really hard to say where the fault lies without further
> investigation.
> >
> > On Fri, Oct 25, 2019 at 4:13 PM Hans Åberg  wrote:
> > The GMP developers felt it was a compiler bug, so I think I will leave
> it at that. But thanks for the tips.
> >
> >
> > > On 26 Oct 2019, at 00:32, David Blaikie  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)
> >
>
>
___
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

[David Blaikie via cfe-users]

I ran the test & understand it a bit better now - so the abort is part of
the code, when the test fails, the test harness uses abort to fail.

So this isn't "clang causes abort" (it didn't select a bad instruction,
etc) this is "clang causes test failure" - this could be any number of
things in terms of compiler optimizations due to overly dependent code (or
due to miscompiles, to be sure). It's possible the test relies on specific
numeric results that the C++ programming language doesn't guarantee (either
overly high precision, or overly low precision - C++ allows extra precision
in computations which can break numerical code that's relying on certain
precision, for instance).

So, yeah, really hard to say where the fault lies without further
investigation.

On Fri, Oct 25, 2019 at 4:13 PM Hans Åberg  wrote:

> The GMP developers felt it was a compiler bug, so I think I will leave it
> at that. But thanks for the tips.
>
>
> > On 26 Oct 2019, at 00:32, David Blaikie  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)
>
>
___
cfe-users mailing list
cfe-users@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users

Re: [cfe-users] clang-tidy bug?

[David Blaikie via cfe-users]

clang-tidy in the command line you gave didn't seem to modify the file for
me, did it modify the file for you?

Are you objecting to the suggestion, or that it was automatically applied?
I would think it'd be a bug to apply any fixit/hint if there are multiple
possible suggestions.

But the existence of the suggestion (without the application of it) to the
user seems right to me. The use of extra () to suppress the
assignment-in-conditional warning (-Wparentheses) has been around for quite
a while, so it's possible that the user intended assignment rather than
comparison when they added the extra parentheses.

- Dave

On Sun, Oct 27, 2019 at 11:32 AM Robert Ankeney via cfe-users <
cfe-users@lists.llvm.org> wrote:

> For the following code (wrong.cpp):
>
> bool check(bool isValid)
> {
> bool retVal = false;
>
> if (( isValid == true ))
> {
> retVal = true;
> }
>
> return retVal;
> }
>
> when I run:
> clang-tidy -checks=modernize-use-default-member-init wrong.cpp
>
> I get:
> 4 warnings and 1 error generated.
> Error while processing /llvm/match/ctBad/wrong.cpp.
> /llvm/match/ctBad/wrong.cpp:5:19: error: equality comparison with
> extraneous parentheses [clang-diagnostic-parentheses-equality]
> if (( isValid == true ))
> ~ ^~  ~
>   =
> /llvm/match/ctBad/wrong.cpp:5:19: note: remove extraneous parentheses
> around the comparison to silence this warning
> /llvm/match/ctBad/wrong.cpp:5:19: note: use '=' to turn this equality
> comparison into an assignment
>
> Note it turns the if into:
> if ( isValid = true )
>
> Seems like a very bad idea. Removing the redundant parentheses seems fine,
> but changing the comparison to an assignment does not. Is this a bug?
>
> Thanks,
> Robert
>
> ___
> 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

[David Blaikie via cfe-users]

On Fri, Oct 25, 2019 at 5:55 PM Matthew Fernandez <
matthew.fernan...@gmail.com> wrote:

> 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).
>

That's my fault - Hans not subscribed to the list, so the emails have to be
approved by a moderator (me) & I hadn't gotten around to it. Approved them
all so they should now show up.


> 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 <
> cfe-users@lists.llvm.org> 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

[David Blaikie via cfe-users]

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

Re: [cfe-users] Clang9 UBSan and GMP

[David Blaikie via cfe-users]

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)

On Fri, Oct 25, 2019 at 3:12 PM Hans Åberg  wrote:

> The sources are available at [1]; it is written in C, not C++. I was was
> hoping that that something like UBSan would shed light on it, but the
> original question is answered: it changes optimization. The GMP developers
> say that they have caught some compiler bugs, but that is hard to do and
> time consuming.
>
> 1. https://gmplib.org
>
>
> > On 25 Oct 2019, at 23:38, David Blaikie  wrote:
> >
> > It's hard to know if it's the compiler's fault without a test case - due
> to the nature of undefined behavior and other things (implementation
> defined behavior and unspecified behavior) in C++, that the program behaves
> as expected with another compiler or another set of flags doesn't give a
> strong indication as to where the problem is (in the code, in one of the
> compilers, etc).
> >
>
>
___
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

[David Blaikie via cfe-users]

It's hard to know if it's the compiler's fault without a test case - due to
the nature of undefined behavior and other things (implementation defined
behavior and unspecified behavior) in C++, that the program behaves as
expected with another compiler or another set of flags doesn't give a
strong indication as to where the problem is (in the code, in one of the
compilers, etc).

- Dave

On Fri, Oct 25, 2019 at 2:22 PM Hans Åberg  wrote:

> It is not my code, it belongs to gmp-6.1.2, I merely happened to come a
> cross it. It passes on gcc9, so there is something that clang9 does.
>
>
> > On 25 Oct 2019, at 23:15, David Blaikie  wrote:
> >
> > It's pretty hard to conclude whether it's a bug in your code or in the
> compiler, or both, without narrowing down a test case.
>
>
___
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

[David Blaikie via cfe-users]

It's pretty hard to conclude whether it's a bug in your code or in the
compiler, or both, without narrowing down a test case.

On Fri, Oct 25, 2019 at 2:01 PM Hans Åberg  wrote:

> So then there probably is an issue with the optimization.
>
> Just run 'gmp-6.1.2’ with MacPorts clang 9.0.0; I got:
> ../../../gmp-6.1.2/test-driver: line 107: 70037 Abort trap: 6
>  "$@" > $log_file 2>&1
> FAIL: t-sqrlo
>
> With Apple clang 11.0.0 (clang-1100.0.33.8), I got another ‘make check’
> error, also only when using optimization:
> ../../../gmp-6.1.2/test-driver: line 107: 30266 Segmentation fault: 11
> "$@" > $log_file 2>&1
> FAIL: t-toom53
>
>
> > On 25 Oct 2019, at 22:53, David Blaikie  wrote:
> >
> > UBSan adds code to check things, it necessarily changes optimizations by
> having those checks in. It shouldn't affect the behavior of programs that
> don't exhibit UB (but I imagine it could affect the behavior of programs
> relying on specific IB  (Implementation Defined Behavior)).
> >
> > Reducing a test case to better understand your code & be able to
> portably demonstrate the issue would help to get traction on understanding
> the behavior, seeing if it's a clang bug, etc.
>
>
___
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

[David Blaikie via cfe-users]

Hard to know what might be happening - what sort of failure you're seeing,
etc. Perhaps UBSan is stabilizing/changing unspecified rather than
undefined behavior - or the test is failing due to some undefined behavior
that UBSan doesn't catch, etc.

On Fri, Oct 25, 2019 at 11:25 AM Hans Åberg  wrote:

> The ‘make check’ of GMP 6.1.2. One of the tests fail, but with any UBSan
> ‘undefined’ option enabled (in ‘configure’), none.
>
> > On 25 Oct 2019, at 18:35, David Blaikie  wrote:
> >
> > You mentioned "the check gives one error" - which check?
>
>
___
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

[David Blaikie via cfe-users]

UBSan adds code to check things, it necessarily changes optimizations by
having those checks in. It shouldn't affect the behavior of programs that
don't exhibit UB (but I imagine it could affect the behavior of programs
relying on specific IB  (Implementation Defined Behavior)).

Reducing a test case to better understand your code & be able to portably
demonstrate the issue would help to get traction on understanding the
behavior, seeing if it's a clang bug, etc.

On Fri, Oct 25, 2019 at 1:49 PM Hans Åberg  wrote:

> It is just an abort trap. The ‘make check' also passes if turning off
> optimization. I would have expected UBSan to not change anything in
> optimization, but merely report the issues it finds. Apparently it finds
> nothing, so it may suggest a compiler bug.
>
>
> > On 25 Oct 2019, at 22:34, David Blaikie  wrote:
> >
> > Hard to know what might be happening - what sort of failure you're
> seeing, etc. Perhaps UBSan is stabilizing/changing unspecified rather than
> undefined behavior - or the test is failing due to some undefined behavior
> that UBSan doesn't catch, etc.
> >
>
>
___
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

[David Blaikie via cfe-users]

You mentioned "the check gives one error" - which check?

On Fri, Oct 25, 2019 at 8:21 AM Hans Åberg via cfe-users <
cfe-users@lists.llvm.org> wrote:

> [Please cc me, as I am not on the list.]
>
> When compiling GMP 6.1.2 with MacPorts clang9 on MacOS 10.15, the check
> gives one error, but if turning on UBSan ‘undefined’, it passes without a
> report. Should it not report what it thinks is the issue?
>
>
> ___
> 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] Why re-compile clang with clang?

[David Blaikie via cfe-users]

Not a requirement, but a suggestion - generally clang/llvm are optimized
best with themselves. So it's generally considered the "optimal" setup.

On Sat, Oct 19, 2019 at 10:48 AM Pratyush Das via cfe-users <
cfe-users@lists.llvm.org> wrote:

> Hi,
>
> I noticed here -
> https://clang.llvm.org/docs/LibASTMatchersTutorial.html#step-0-obtaining-clang
>  that
> it is recommended to recompile clang after building it for the first time
> with itself. Why is that required?
>
> Thanks,
>
> --
> Pratyush Das(Reik)
> ___
> 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] Why does clang not always produce constant value for same static constexpr

[David Blaikie via cfe-users]

On Wed, Sep 25, 2019 at 2:03 PM Christopher Williams 
wrote:

> Thank you Dave. I have an understanding of constexpr evaluation, and
> realise the compiler is free to do what it likes in all but test4... I
> suppose I'd really like to know if there is an actual limit/threshold in
> place. If test3 is changed to use 100 characters it does as I expect, any
> more than that e.g. 101 and it bails. I also compiled with
> -Rpass-analysis='.*' -mllvm -print-after-all, and it *seems* the bail is in
> Induction Variable Simplify / Scalar Evolution, but I assume the actual
> problem could be before that.
>

Possible it's somewhere else, but without further evidence Induction
Variable Simplify/Scalar Evolution sounds like a perfectly plausible place
where such a threshold could be implemented so far as I know/could guess.


>
> --
> Chris
>
> On 25/09/2019 20:57, David Blaikie wrote:
>
> constexpr is a red herring here - except in 4, where you've used the
> constexpr keyword to create a constexpr context, in 1-3 these are just
> normal function calls the compiler optimizes as it sees fit - and it seems
> it saw fit to unroll and optimize to a constant cases 1 and 2, but not case
> 3 (perhaps because it was too long/some other middle-end optimization
> decided to bail out).
>
> I couldn't say for sure exactly which LLVM optimization bailed out early,
> or whether LLVM is using the same general approach as GCC here.
>
> Adding/removing the constexpr keyword from count_x shouldn't affect
> anything in cases 1-3 (in either Clang or GCC, really). But looks like it
> makes a big difference to GCC - perhaps GCC tries to evaluate constexpr in
> the frontend even when the language doesn't require it. Sounds like a
> recipe for some problematic compile-time to me... but don't know.
>
> - Dave
>
> On Wed, Sep 25, 2019 at 12:37 PM Christopher Williams via cfe-users <
> cfe-users@lists.llvm.org> wrote:
>
>> Given the code below, clang produces a constant value for test1, test2
>> and test4. Why doesn't it for test3?
>> This is more of a curious query, than a request for help, but if someone
>> does have the answer, I'd appreciate as much detail as possible.
>> ||
>>
>> |staticconstexprintcount_x(constchar*str){intcount{};for(;*str
>> !=0;++str){count +=*str
>>
>> =='x';}returncount;}#defineSTRx1"123456789x"#defineSTRx4STRx1STRx1STRx1STRx1#defineSTRx8STRx4STRx4#defineSTRx16STRx8STRx8inttest1(){returncount_x(STRx4);}inttest2(){returncount_x(STRx8);}inttest3(){returncount_x(STRx16);}inttest4(){constexprautok
>> =count_x(STRx16);returnk;}|
>>
>>
>> |test1():# @test1()mov eax,4ret test2():# @test2()mov eax,8ret
>> test3():# @test3()xor eax,eax mov dl,49mov ecx,offset
>> .L.str.2+1.LBB2_1:# =>This Inner Loop Header: Depth=1xor esi,esi cmp
>> dl,120sete sil add eax,esi movzx edx,byte ptr [rcx]add rcx,1test
>> dl,dl jne .LBB2_1 ret test4():# @test4()mov eax,16ret
>> .L.str.2:.asciz
>>
>> "123456789x123456789x123456789x123456789x123456789x123456789x123456789x123456789x123456789x123456789x123456789x123456789x123456789x123456789x123456789x123456789x"|
>>
>> gcc does:
>>
>> |test1():mov eax,4ret test2():mov eax,8ret test3():mov eax,16ret
>> test4():mov eax,16ret|
>>
>> Compilation command lines used:
>>
>> |clang++-Ofast-std=c++2a-S -o --c src/test.cpp |grep -Ev$'^\t+\\.'gcc9
>> -Ofast-std=c++2a-S -o --c src/test.cpp |grep -Ev$'^\t+\\.'|
>>
>> Compiler Explorer: https://godbolt.org/z/V-3MEp
>>
>>
>>
>> ___
>> 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] Why does clang not always produce constant value for same static constexpr

[David Blaikie via cfe-users]

constexpr is a red herring here - except in 4, where you've used the
constexpr keyword to create a constexpr context, in 1-3 these are just
normal function calls the compiler optimizes as it sees fit - and it seems
it saw fit to unroll and optimize to a constant cases 1 and 2, but not case
3 (perhaps because it was too long/some other middle-end optimization
decided to bail out).

I couldn't say for sure exactly which LLVM optimization bailed out early,
or whether LLVM is using the same general approach as GCC here.

Adding/removing the constexpr keyword from count_x shouldn't affect
anything in cases 1-3 (in either Clang or GCC, really). But looks like it
makes a big difference to GCC - perhaps GCC tries to evaluate constexpr in
the frontend even when the language doesn't require it. Sounds like a
recipe for some problematic compile-time to me... but don't know.

- Dave

On Wed, Sep 25, 2019 at 12:37 PM Christopher Williams via cfe-users <
cfe-users@lists.llvm.org> wrote:

> Given the code below, clang produces a constant value for test1, test2
> and test4. Why doesn't it for test3?
> This is more of a curious query, than a request for help, but if someone
> does have the answer, I'd appreciate as much detail as possible.
> ||
>
> |staticconstexprintcount_x(constchar*str){intcount{};for(;*str
> !=0;++str){count +=*str
>
> =='x';}returncount;}#defineSTRx1"123456789x"#defineSTRx4STRx1STRx1STRx1STRx1#defineSTRx8STRx4STRx4#defineSTRx16STRx8STRx8inttest1(){returncount_x(STRx4);}inttest2(){returncount_x(STRx8);}inttest3(){returncount_x(STRx16);}inttest4(){constexprautok
> =count_x(STRx16);returnk;}|
>
>
> |test1():# @test1()mov eax,4ret test2():# @test2()mov eax,8ret
> test3():# @test3()xor eax,eax mov dl,49mov ecx,offset
> .L.str.2+1.LBB2_1:# =>This Inner Loop Header: Depth=1xor esi,esi cmp
> dl,120sete sil add eax,esi movzx edx,byte ptr [rcx]add rcx,1test
> dl,dl jne .LBB2_1 ret test4():# @test4()mov eax,16ret
> .L.str.2:.asciz
>
> "123456789x123456789x123456789x123456789x123456789x123456789x123456789x123456789x123456789x123456789x123456789x123456789x123456789x123456789x123456789x123456789x"|
>
> gcc does:
>
> |test1():mov eax,4ret test2():mov eax,8ret test3():mov eax,16ret
> test4():mov eax,16ret|
>
> Compilation command lines used:
>
> |clang++-Ofast-std=c++2a-S -o --c src/test.cpp |grep -Ev$'^\t+\\.'gcc9
> -Ofast-std=c++2a-S -o --c src/test.cpp |grep -Ev$'^\t+\\.'|
>
> Compiler Explorer: https://godbolt.org/z/V-3MEp
>
>
>
> ___
> 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] Should clang++ -g produce debugging info for all types?

[David Blaikie via cfe-users]

On Fri, Aug 9, 2019 at 6:03 PM Bob Eastbrook 
wrote:

> On Mon, Aug 5, 2019 at 1:36 PM David Blaikie  wrote:
>
> > Does it work with gdb?
>
> It works with gdb.  More info:
>
> g++ & gdb -- works, even without debuginfo for libstdc++
>

^ for std::string I'd expect this. For std::fstream, I expect you'd see the
same problem/failure (gcc and clang both rely on fstream being homed in the
standard library's debug info (because of vtables/key functions), but clang
takes it a step further and does this for std::string too (because of
template explicit instantiation decl/def))


> clang++ & gdb -- works
> g++ & lldb -- works
>

^ again, I expect that would fail with std::fstream, demonstrating that the
same problem exists for both clang and GCC, just clang takes it a bit
further - but it's not fundamentally different between the two.


> clang++ & lldb -- fails
>
> I now notice these warnings in lldb after installing the debuginfo
> packages:
>
> warning: (x86_64) /lib64/libstdc++.so.6 unsupported DW_FORM values:
> 0x1f20 0x1f21
> warning: (x86_64) /lib64/libgcc_s.so.1 unsupported DW_FORM values: 0x1f20
> 0x1f21
>
> I searched the web for details on that error, but came up empty.
> Could it be that the debuginfo packages are just not compatible with
> lldb?
>

Ooh, yeah, that's possible/likely. Unknown forms can't be ignored because
forms dictate the encoding, so without recognizing the form, the DWARF
can't be parsed (unknown /attributes/ using known forms are fine - because
they can be parsed and the values ignored).

Yeah, looks like 1f20 (DW_FORM_GNU_ref_alt) and 1f21 (DW_FORM_GNU_strp_alt)
are results of the 'dwz' tool that compacts DWARF debug info.

Not sure if it'd be enough to teach lldb how to parse but ignore any
attribute using these forms - I would guess not, I suspect that would
result in holes in the debug info where these forms are used. So you'd
probably have to modify/fix/patch lldb to actually be able to understand
these forms - which might not be too hard. Hmm, nope, probably fairly
involved, since it means reading a new/different file (judging by this
patch and the link to the DWARF standards proposal in it:
http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20150518/277186.html
 ).

Summary:
Yeah, short of making some relatively significant changes to lldb, I think
you'll probably just have to stick with larger debug info by using
-fstandalone-debug, since the debug info provided by your distribution uses
GNU extensions that lldb doesn't currently support. :/


>
> > I'd try gdb + gcc + binutils ld (or gold) + libstdc++ (use std::fstream
> as an example of something that gcc will home to the libstdc++ debug info -
> dwarfdump your executable and you'll see it doesn't contain the definition
> of basic_fstream, but verify the debugger can still render the full
> definition). If that works, swap out various parts of that & see where it
> falls apart.
>
> Good strategy.  I don't quite have the hang of dwarfdump yet though,
> but I'll continue to investigate.
>
___
cfe-users mailing list
cfe-users@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users

Re: [cfe-users] Should clang++ -g produce debugging info for all types?

[David Blaikie via cfe-users]

Does it work with gdb? I'm guessing maybe lldb doesn't support the build-id
feature that redhat uses (
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/developer_guide/intro.debuginfo
)
?

I'd try gdb + gcc + binutils ld (or gold) + libstdc++ (use std::fstream as
an example of something that gcc will home to the libstdc++ debug info -
dwarfdump your executable and you'll see it doesn't contain the definition
of basic_fstream, but verify the debugger can still render the full
definition). If that works, swap out various parts of that & see where it
falls apart.

On Tue, Jul 30, 2019 at 9:50 AM Bob Eastbrook 
wrote:

> On Thu, Jul 25, 2019 at 8:35 PM David Blaikie  wrote:
>
> > No, it shouldn't - clang attempts to avoid emitting duplicate debug info
> across the program (it assumes you built the whole program and all
> libraries with debug info), gcc assumes the same thing though in slightly
> different/fewer ways.
> >
> > The solution is to install the -dbg build of your libstdc++ package
> (assuming you're using libstdc++), it will include debug info for the
> standard library, including std::string.
>
> Thanks for the pointer.  Based on what you told me, I was able to dig
> deeper and found these relevant links:
>
> https://bugs.llvm.org/show_bug.cgi?id=24202#c1
>
> https://stackoverflow.com/questions/41745527/cannot-view-stdstring-when-compiled-with-clang
>
> I installed the debug version of libstd++ on my Fedora system with
> "dnf debuginfo-install libstdc++" and I now see a debug version of
> libstdc++:
>
> $ file /usr/lib/debug/lib64/libstdc++.so.6.0.26-9.1.1-1.fc30.x86_64.debug
> /usr/lib/debug/lib64/libstdc++.so.6.0.26-9.1.1-1.fc30.x86_64.debug:
> ELF 64-bit LSB shared object, x86-64, version 1 (GNU/Linux),
> dynamically linked,
> BuildID[sha1]=3b2e1aaafd0cb7e1ebd75627d4cde2504c927159, with
> debug_info, not stripped
>
> I don't have things working though.  I still don't see std::string
> info when debugging.  My executable is linked against the non-debug
> version:
>
> $ ldd a.out
> linux-vdso.so.1 (0x7ffec03fe000)
> libstdc++.so.6 => /lib64/libstdc++.so.6 (0x7f2fccd31000)
> libm.so.6 => /lib64/libm.so.6 (0x7f2fccbeb000)
> libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x7f2fccbd1000)
> libc.so.6 => /lib64/libc.so.6 (0x7f2fcca0b000)
> /lib64/ld-linux-x86-64.so.2 (0x7f2fccf45000)
>
> Is that my problem?  Or does LLDB somehow know to use the version in
> /usr/lib/debug/lib64?
>
> I'm also puzzled about why the debug version was put in /usr/lib and
> not /usr/lib64.
>
___
cfe-users mailing list
cfe-users@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users

Re: [cfe-users] Should clang++ -g produce debugging info for all types?

[David Blaikie via cfe-users]

No, it shouldn't - clang attempts to avoid emitting duplicate debug info
across the program (it assumes you built the whole program and all
libraries with debug info), gcc assumes the same thing though in slightly
different/fewer ways.

The solution is to install the -dbg build of your libstdc++ package
(assuming you're using libstdc++), it will include debug info for the
standard library, including std::string.

To see a case where GCC does the same thing - try a variable of type
std::fstream. GCC, similarly, will produce only a declaration for the
basic_fstream type, not the definition.

(& here's a lightning talk that discusses, briefly, some of this:
https://www.youtube.com/watch?v=XvkLHIASlp8 )

On Thu, Jul 25, 2019 at 11:41 AM Bob Eastbrook via cfe-users <
cfe-users@lists.llvm.org> wrote:

> On Fedora 30, "clang++ -g main.cc" does not emit debugging information
> for types such as std::string.  I can only get complete debugging
> information by including "-fno-limit-debug-info".
>
> On Ubuntu 19.04, "clang++ -g" emits debugging info for std::string as
> expected.
>
> Which behavior of "-g" is correct?  Can anyone explain why each
> platform behaves differently?
> ___
> 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] -Warray-bounds

[David Blaikie via cfe-users]

Supporting the oldest form doesn't seem to be a priority for a warning - if
you have a very old codebase, probably not worth building it with warnings
enabled. Updating code to use more modern/idiomatic forms is within scope
for Clang's warnings, within reason, I think.

- Dave

On Fri, Dec 28, 2018 at 1:26 PM Jay K via cfe-users <
cfe-users@lists.llvm.org> wrote:

> This is an old topic:
>
>
> http://clang-developers.42468.n3.nabble.com/Warray-bounds-seems-over-zealous-on-Clang-td3162669.html
>
> But some points were left not covered.
>
> 1. "code hygiene" I'd say is that, the code should
> just be portable to "all" compilers, and have the same meaning
> with all of them, with a minimum of ifdefs.
>
> 2. Furthermore, regarding "same meaning" to all of them,
> there are these choices:
>
> typedef struct A1 {
>   int a;
>   int b[0];
> } A1;
>
> typedef struct A2 {
>   int a;
>   int b[];
> } A2;
>
> typedef struct A3 {
>   int a;
>   int b[1];
> } A3;
>
> int a1 = sizeof(A1);
> int a2 = sizeof(A2);
> int a3 = sizeof(A3);
>
> They are all valid with clang and probably gcc.
> But they are not likely all valid with additional compilers and through
> time.
> [1] seems like the most portable and oldest form, and might as well just
> keep using it indefinitely.
>
> But it gets a warning.
> If one were to ifdef clang to avoid it, one would lose interopation across
> compilers, as
> the various forms do not have the same meaning.
> Everyone would have to compile with the same compiler/defines.
> Else the types would vary in size.
>
> So I come back to believing that the best choices are either:
>  - do not warn for size=1 at end of aggregate
>  - possibly a separate setting for specifically that
>
> That is what gcc does also it appears (both).
>
> I ran across all this exact situation -- ifdef gnuc/clang in some code,
> with comment that everyone has to compile the same, chosing between 0 and 1
> for zero sized array.
>
>
> Thank you,
>  - Jay
> ___
> 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] My compiler crashes .... but the online godbolt one doesn't ?!

[David Blaikie via cfe-users]

On Wed, Dec 12, 2018 at 1:30 AM Andy Gibbs  wrote:

> On 10 December 2018 18:17, David Blaikie wrote:
>
> Possible that the online one isn't built with assertions enabled (you
> could test this with other known crashers to see if they reproduce on
> godbolt with assertion crash dumps or only with raw segfaults)? If that's
> the case,t hen it's possible that the codepath that should assert continues
> on and perhaps either has unexpected or even undefined behavior but not a
> crash.
>
> Yes, it seems this is right.  I have done a number of further tests and it
> seems that the godbolt compilers are built without asserts.
>
> This, however, is a possible problem generally, isn't it?  I build my
> compilers always with release-asserts but I would guess it common that
> compiler builds are simply release builds.  And this means, if there is a
> bug in the compiler, it may generate invalid code with no warning at all
> (my bug report gives an example of this) where in fact, if it were built
> with asserts then the bug would have been made visible (and maybe fixed!).
>
> I know there can always be bugs which still act invisibly, but given that
> clang is good at sticking asserts everywhere in its code :o) isn't it worth
> ensuring asserts are always enabled?  i.e. build 'release-asserts' even
> when asked to do a release build?
>

Assertions are expensive (at one point the LLVM build system had a warning
about builds with assertions enabled, that they may be 10x slower than
without assertions) - so it's not practical for most folks to run with them
enabled for all their builds.

- Dave


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

Re: [cfe-users] problem with `candidate template ignored: invalid explicitly-specified argument'

[David Blaikie via cfe-users]

Sure, that'd be great - http://bugs.llvm.org

On Tue, Nov 6, 2018 at 3:02 AM Werner LEMBERG  wrote:

>
> > Yeah, looks like a bug in Clang to me - CC'ing Richard Smith in case
> > this is quick/easy/obvious to him.
>
> Thanks to all for checking!  Shall I open an issue for clang?
>
>
> Werner
>
___
cfe-users mailing list
cfe-users@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users

Re: [cfe-users] problem with `candidate template ignored: invalid explicitly-specified argument'

[David Blaikie via cfe-users]

Yeah, looks like a bug in Clang to me - CC'ing Richard Smith in case this
is quick/easy/obvious to him. Here's my slightly modified test case
comparing Clang and GCC's behavior, and adding a non-member overload
situation to demonstrate that that works on both compilers:
https://godbolt.org/z/cTq06R

On Sat, Nov 3, 2018 at 3:19 PM Werner LEMBERG via cfe-users <
cfe-users@lists.llvm.org> wrote:

>
> Folks,
>
>
> below is a MWE that compiles fine with g++ but fails with clang
> (tested version 6.0.1 on a GNU/Linux box):
>
>   clang-problem.cpp:19:7: error:
>   no matching member function for call to 'zip'
> bex.zip <::fun> ();
> ^
>   clang-problem.cpp:13:8: note: candidate template ignored:
>   invalid explicitly-specified argument for template parameter 'mf'
> void zip () { }
>  ^
>
> To my best knowledge, the code is valid C++.  This means there are two
> possible corrolaries: either I'm wrong, and it is not valid C++
> according to the standard, or clang++ has a bug.  Hopefully, it's the
> former.
>
> Can you point out a solution?
>
>
> Werner
>
>
> ==
>
>
> class A {
> public:
>   template 
>   void zip () { }
>   void fun () { }
> };
>
> class B : public A
> {
> public:
>   using A::zip; // Fails to involve A::zip in overloading resolution
>   template 
>   void zip () { }
> } bex;
>
>
> void x ()
> {
>   bex.zip <::fun> ();
> }
>
> ___
> 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] Using llvm-ar & llvm-ranlib vs ar & ranlib for creating static libraries when thinLTO is enabled.

[David Blaikie via cfe-users]

(Teresa, perhaps you can correct me if I'm wrong here)

On Thu, Aug 9, 2018 at 2:21 PM Mateusz Zych via cfe-users <
cfe-users@lists.llvm.org> wrote:

> Hi :)
>
> I am trying to compile simple project consisting of an executable "app"
> and static library "bar".
> Note that I'm enabling thinLTO for both "app" and "bar".
>
> 
> //   bar.h//
> 
> #ifndef BAR
> #define BAR
>
> void bar ();
>
> #endif
> 
>
> 
> //  bar.cpp   //
> 
> #include "bar.h"
> #include 
>
> void bar ()
> {
> std::cout << "Bar" << std::endl;
> }
> 
>
> 
> //  app.cpp   //
> 
> #include "bar.h"
> #include 
>
> int main()
> {
> std::cout << "App" << std::endl;
> bar();
> }
> 
>
>
> When I'm using llvm-ar and llvm-ranlib to create static library everything
> works fine:
>
> $ clang++ -flto=thin -c bar.cpp -o bar.o
> $ llvm-ar cr bar.a bar.o
> $ llvm-ranlib bar.a
> $ clang++ -flto=thin -c app.cpp -o app.o
> $ clang++ -flto=thin -o app app.o bar.a
>
>
> However using default ar and ranlib provided by my GNU/Linux distribution
> results in linking failure:
>
> $ clang++ -flto=thin -c bar.cpp -o bar.o
> $ ar cr bar.a bar.o
> $ ranlib bar.a
> $ clang++ -flto=thin -c app.cpp -o app.o
> $ clang++ -flto=thin -o app app.o bar.a
> bar.a: *error adding symbols: Archive has no index; run ranlib to add one*
> clang: error: linker command failed with exit code 1 (use -v to see
> invocation)
>
>
> Note that for GCC using default ar and ranlib works fine:
>
> $ g++ -flto -c bar.cpp -o bar.o
> $ ar cr bar.a bar.o
> $ ranlib bar.a
> $ g++ -flto -c app.cpp -o app.o
> $ g++ -flto -o app app.o bar.a
>
>
> Obviously using gcc-ar and gcc-ranlib also works fine:
>
> $ g++ -flto -c bar.cpp -o bar.o
> $ gcc-ar cr bar.a bar.o
> $ gcc-ranlib bar.a
> $ g++ -flto -c app.cpp -o app.o
> $ g++ -flto -o app app.o bar.a
>
>
> My question is: *Can I use ar and ranlib provided by GNU/Linux with
> clang++?*
>

Not when using LTO, so far as I know. Otherwise, yes. (no idea if
llvm-ar/llvm-ranlib are totally general purpose replacements for those
tools, but I guess they are roughly/generally so)


>
> If not, then to properly setup clang as a default compiler on GNU/Linux
> machine,
> I should not only run update-alternatives for cc and c++ commands,
> but also somehow do that for ar and ranlib commands?
>
> $ sudo update-alternatives --config cc
> $ sudo update-alternatives --config c++
>
>
> That's very problematic since update-alternatives doesn't work with ar and
> ranlib:
>
> $ sudo update-alternatives --config ar
> update-alternatives: error: no alternatives for ar
> $ sudo update-alternatives --config ranlib
> update-alternatives: error: no alternatives for ranlib
>
>
Looks like you can teach update-alternatives to support new commands with
the --install option?


>
> If default ar and ranlib is expected to not work with clang++,
> then how should I setup Clang as a default compiler on GNU/Linux?
>
> Thanks, Mateusz Zych
> ___
> 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] cfe-users proof of life

[David Blaikie via cfe-users]

Yeah - it's here, but not sure it's really all that much use in my humble
opinion. I think the idea was to make it more accessible (you can send mail
without subscribing) & to separate the user questions from the developer
questions - but I'm not sure there are enough users here to bootstrap much
of a community discussion. Likely places like Stackoverflow, etc, achieve
that better?

On Thu, May 3, 2018 at 1:37 PM Matthew Fernandez via cfe-users <
cfe-users@lists.llvm.org> wrote:

> 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
>
___
cfe-users mailing list
cfe-users@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users

Re: [cfe-users] [llvm-bugs] Question about debug symbol

[David Blaikie via cfe-users]

(moving this thread from llvm-bugs (which is just for our automated bug
database emails) to cfe-users)

GCC uses an optimization for debug info that Clang has, but does not enable
on platforms where the default debugger is LLDB (because LLDB doesn't
handle debug info that has this optimization enabled).

If you aren't using LLDB, you can explicitly pass "-fno-standalone-debug"
to get the optimized behavior and that should match or be better than GCC's
(in my experiments, LLVM's is about half the size of GCC's when using this
flag).

If you are using LLDB, I'm not sure there's much you can do.

On Mon, Oct 17, 2016 at 7:35 AM 석진무 via llvm-bugs 
wrote:

> Hello LLVM admins,
>
> I'm jinmoo seok, live in seout, Korea.
>
>
>
> i have some problem about debug symbol.
>
> i want to how to solve this problem, so i email you.
>
>
>
> source code is :
>
> #include
>
> int main() {
>
> std::cout << "hello world" << std::endl;
>
> return 0;
>
> }
>
>
>
> this is simple source.
>
> but when i build it width debug symbol using clang, binary size is 100kb.
>
> when using gcc, binary size is 19kb
>
>
>
> i tryed "readelf -wi "
>
> readelf: dwarf_loclist_form_expr_b: Invalid argument 
> [dwarf_loclist_from_expr_b(279)]
> <237>   DW_AT_data_member_location: 0 byte block:   ()
> <4><23a>: Abbrev Number: 9 (DW_TAG_member)
> <23b>   DW_AT_name: (indirect string) __precision_
> <23f>   DW_AT_type: <0x799>
> <243>   DW_AT_decl_file   : 2
> <244>   DW_AT_decl_line   : 363
>
> this message is repeatedly output.
>
> what does message mean?
>
>
>
> and i tryed "readelf -s "
>
>  0 NOTYPE  LOCAL  DEFAULT   31
>
> this message is output too many.
>
> why debug_str size is too big?
>
>
>
> i test both clang34 and clang38
>
> clang38's binary size is nearly as twice as clang34's binary.
>
>
>
> i wan't to why this problem happen.
>
>
>
> My environment:
>
> i386
>
> freebsd11
>
>
>
>
> ___
> llvm-bugs mailing list
> llvm-b...@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
>
___
cfe-users mailing list
cfe-users@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users

Re: [cfe-users] uniquely identifying names

[David Blaikie via cfe-users]

Do you want to identify the same entity across a valid program's various
source files? Across changes to that program? (what changes?)

If you want to do the former, then producing the mangled name of the entity
is probably what you want. (some part of the ABI code in Clang could give
you that, I would assume - but not sure exactly where)

On Tue, Aug 30, 2016 at 2:33 AM folkert  wrote:

> Maybe I could expand a name into its full name and use that.
> e.g.:
>
> namespace bla { class myclass { void mymethod() { } } }
>
> then the full name of mymethod would be bla::myclass::mymethod would be
> unique enough to me (including filename).
> Can I somehow get this out of it?
>
> On Fri, Aug 26, 2016 at 03:33:20PM +, David Blaikie wrote:
> > There's no structural identity of code in Clang that I know of - I know
> > someone's building a tool for doing structural similarity for things like
> > plagiarism detection (I think there are some patches on the clang mailing
> > list).
> >
> > But if you only need identity within a single process, the pointer value
> of
> > the pointer to any AST construct is a unique identity you can use.
> >
> > (line/file/column isn't sufficiently unique - you could have a file that
> is
> > included under different macro situations and each time it defines a
> > different function, but all those functions would appear to be defined on
> > the same line/file of that included file - or a macro that defines
> multiple
> > functions - both can be resolved by looking at the more complete location
> > information (including macro locations, etc))
> >
> > On Fri, Aug 26, 2016 at 5:11 AM folkert via cfe-users <
> > cfe-users@lists.llvm.org> wrote:
> >
> > > Hi,
> > >
> > > The Sun java compiler allows you to (from java) walk the AST and
> > > investigate it. Each token is stored in an object. Each object has a
> > > hash() method which uniquely identifies it.
> > >
> > > Now I was wondering: can I do so with the LLVM tooling as well? I could
> > > of course if I want to identify e.g. a function name just pick the
> line-
> > > and column number and maybe include the function name itself as well
> but
> > > that would constantly change when lines are added and/or removed.
> > >
> > > Any suggestions?
> > >
> > >
> > > regards,
> > >
> > > Folkert van Heusden
> > >
> > > --
> > > -
> > > Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.com
> > > ___
> > > cfe-users mailing list
> > > cfe-users@lists.llvm.org
> > > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
> > >
>
>
> Folkert van Heusden
>
> --
> Always wondered what the latency of your webserver is? Or how much more
> latency you get when you go through a proxy server/tor? The numbers
> tell the tale and with HTTPing you know them!
>  http://www.vanheusden.com/httping/
> ---
> Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.com
>
___
cfe-users mailing list
cfe-users@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users

Re: [cfe-users] -Wunreachable-code warnings can no longer be suppressed?

[David Blaikie via cfe-users]

On Fri, Aug 5, 2016 at 3:56 PM Chris Peterson via cfe-users <
cfe-users@lists.llvm.org> wrote:

> I suppressed a -Wunreachable-code warning in Firefox earlier this year
> [1] by adding extra parentheses, as suggested by Xcode's clang on OS X:
>
> objdir-osx/dom/bindings/TestJSImplGenBinding.cpp:47639:20: note: silence
> by adding parentheses to mark code as explicitly dead
> if (false && !CallerSubsumes(temp)) {
>  ^
>  /* DISABLES CODE */ ()
>
> This is generated C++ code in Firefox, so changing the code generator to
> emit the extra parentheses was easier than complicating the code
> generator's logic for this particular case.
>
> Unfortunately, this Firefox warning is back [2] because clang 3.9 on
> Linux no longer recognizes the parentheses suppression. Is this an
> intentional change to -Wunreachable-code or a regression? I don't see
> the warning string "silence by adding parentheses to mark code as
> explicitly dead" in the clang code on GitHub [3], but I see a few clang
> tests that appear to expect that warning string.
>

The string is here:
https://github.com/llvm-mirror/clang/blob/master/include/clang/Basic/DiagnosticSemaKinds.td#L499

Should still work. Nearest I could test seems to:

blaikie@blaikie-linux:/tmp/dbginfo$ cat suppress.cpp
void f1();
bool f2(int);
void f3(int temp) {
  if (false && !f2(temp))
f1();
}
blaikie@blaikie-linux:/tmp/dbginfo$ clang++-tot suppress.cpp
-Wunreachable-code -fsyntax-only
suppress.cpp:5:5: warning: code will never be executed [-Wunreachable-code]
f1();
^~
suppress.cpp:4:16: note: silence by adding parentheses to mark code as
explicitly dead
  if (false && !f2(temp))
   ^
   /* DISABLES CODE */ ( )
suppress.cpp:4:17: warning: code will never be executed [-Wunreachable-code]
  if (false && !f2(temp))
^~
suppress.cpp:4:7: note: silence by adding parentheses to mark code as
explicitly dead
  if (false && !f2(temp))
  ^
  /* DISABLES CODE */ ( )
2 warnings generated.

Then successfully suppressed:

blaikie@blaikie-linux:/tmp/dbginfo$ cat suppress.cpp
void f1();
bool f2(int);
void f3(int temp) {
  if ((false) && !f2(temp))
f1();
}
blaikie@blaikie-linux:/tmp/dbginfo$ clang++-tot suppress.cpp
-Wunreachable-code -fsyntax-only
blaikie@blaikie-linux:/tmp/dbginfo$

That's with Clang from trunk/current SVN/git/etc. Could you provide a small
example that fails (warns/doesn't suppress) with 3.9/ToT but succeeds
(successfully suppresses the warning) with earlier?



>
> thanks,
> chris
>
> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1223265
> [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1291397
> [3] https://github.com/llvm-mirror/clang
> ___
> 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] dereferencing null pointers

[David Blaikie via cfe-users]

Short answer: No, unfortunately.

Longer answer: The runtime failure should help you catch these. Clang does
have a diagnostic for /really/ obvious cases of null dereference:

null.c:3:3: warning: indirection of non-volatile null pointer will be
deleted, not trap [-Wnull-dereference]
  *((int*)NULL) = 3;
  ^

But that doesn't seem to cover array deref - you could file a
bug/provide a patch to enhance that warning to cover the array deref
case.


On Sun, Apr 24, 2016 at 3:10 AM, Zenith432 via cfe-users <
cfe-users@lists.llvm.org> wrote:

> target is  x86_64-apple-darwin15.4.0 (Apple LLVM 7.3.0)
>
> This function
> = vec.c =
> #include 
>
> int vec(int index)
> {
> return ((int*) NULL)[index];
> }
> ===
>
>  [Yes, I know it's undefined behavior in ansi C].
>
> Compiled with "clang -c -O0 -o vec.o vec.c" yields this code
>
> =
> 55  pushq   %rbp
> 00014889e5  movq%rsp, %rbp
> 000431c0xorl%eax, %eax
> 000689c1movl%eax, %ecx
> 0008897dfc  movl%edi, -0x4(%rbp)
> 000b486355fcmovslq  -0x4(%rbp), %rdx
> 000f8b0491  movl_vec(%rcx,%rdx,4),
> %eax
> 00125d  popq%rbp
> 0013c3  retq
> =
>
> Compiled with "clang -c -Os -o vec.o vec.c" yields this code
> =
> 55  pushq   %rbp
> 00014889e5  movq%rsp, %rbp
> 00040f0bud2
> =
>
> Questions:
> 1) Is there a way to suppress the optimization that generates a trap, and
> have -Os yield working code like -O0?
> 2) Barring that, is there some way to have this code generate a
> compile-time diagnostic instead of emitting a run-time trap?
>
> Thank You.
> ___
> 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] Clang 3.9 running 50% slower than 3.7

[David Blaikie via cfe-users]

On Wed, Mar 16, 2016 at 7:25 AM, jps...@gmail.com via cfe-users <
cfe-users@lists.llvm.org> wrote:

> Hi, I recently installed "Release" clang (svn r263305) from source on my
> OSX machine, and it's compiling a 20 file C++ program about 50% slower than
> the natively installed clang 3.7 (that came with xcode, I believe, although
> I don't use xcode). I currently have both sets of tools installed and am
> able to switch back and forth and verify using time that clang 3.7 takes
> about 30 seconds and clang 3.9 takes about 45 seconds, on average (all
> flags, settings, etc. are the same for both). I did build with "Release" as
> the build type, although I also did set DLLVM_ENABLE_ASSERTIONS=ON (could
> this be the problem?).
>

Yes, the build system should print a warning telling you that an assertions
enabled build can be up to ten times slower. Performance
comparisons/measurements of an assertions enabled compiler aren't something
we really do/tune for.


> More details below. Please let me know if you have any ideas about why
> this newer clang would be noticable slower.
>
> Generally, I'm just trying to use clang as a user, not a clang developer,
> so if you have general recommendations for how to configure this, please
> let me know.
>
> Thank you,
> Jim
>
> How I configured and installed:
>
> cmake -G "Unix Makefiles" -DCMAKE_BUILD_TYPE=Release
> -DLLVM_ENABLE_ASSERTIONS=ON ../llvm
> make
> cmake -DCMAKE_INSTALL_PREFIX=$CLANG_PREFIX -P cmake_install.cmake
>
>
> Here are some specifics:
>
> $ uname -a
> Darwin localhost 15.0.0 Darwin Kernel Version 15.0.0: Wed Aug 26 16:57:32
> PDT 2015; root:xnu-3247.1.106~1/RELEASE_X86_64 x86_64
>
> $ clang --version
> clang version 3.9.0 (trunk 263305)
> Target: x86_64-apple-darwin15.0.0
> Thread model: posix
> InstalledDir: /Users/jim/toolchains/llvm/bin
>
> ___
> 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] optimize template-heavy project with duplicate code removal

[David Blaikie via cfe-users]

On Thu, Sep 24, 2015 at 4:46 PM, chen xu  wrote:

> That's very helpful. Thanks a lot. I will try them out.
>
> By the way, when linking two libraries, say, they both instantiate classes
> from the same template class (e.g. defined in a 'common' component), into
> an executable, will the linker remove the duplicate class instance?
>

The linker will remove the duplicate code, but not the duplicate debug info
(unless you use -fdebug-types-section - which will actually make your
object files a little bigger, but the executable will be smaller since the
duplicates will be removed)


>
>
> --
> Date: Thu, 24 Sep 2015 15:29:09 -0700
>
> Subject: Re: [cfe-users] optimize template-heavy project with duplicate
> code removal
> From: dblai...@gmail.com
> To: chen...@outlook.com
> CC: cfe-users@lists.llvm.org
>
>
>
> On Thu, Sep 24, 2015 at 3:12 PM, chen xu  wrote:
>
> Thanks, David.  The build type is Debug. Today I tried removing the debug
> info (-g), the size of the executable could be cut 90%, to around 100MB,
> which looks not bad. Do you know whether there is a way to separate debug
> info file from the executable file on Linux?
>
>
> Yep, -gsplit-dwarf - latest versions of GDB can cope with this debug info
>
> You can also compress the debug info: -Wa,--compress-debug-sections
>
> If you want linked debug info (rather than split debug info), consider
> enabling type units to deduplicate debug info in your final executable
> (-fdebug-types-section).
>
>
>  Mainly our code is already there, refactoring might require big effort..
> Also, does clang support -fno-implicit-templates? if yes, maybe we could
> use it to eliminate duplicate template instances to control the final size.
>
>
> Not sure, off hand, whether Clang supports that.
>
>
>
> --
> Date: Wed, 23 Sep 2015 16:59:04 -0700
> Subject: Re: [cfe-users] optimize template-heavy project with duplicate
> code removal
> From: dblai...@gmail.com
> To: chen...@outlook.com
> CC: cfe-users@lists.llvm.org
>
>
> debug or non-debug build?
>
> & no, for a full release build, measuring the final executable size,
> there's not much you can do with the compiler.
>
> you can try to factor common portions out of your templates (eg: remove
> template parameters where possible - if, for example, a member function of
> a class template doesn't need all the template parameters - pull it out
> into a standalone function template that takes fewer template parameters,
> and call it from the member one)
>
> On Wed, Sep 23, 2015 at 4:43 PM, chen xu via cfe-users <
> cfe-users@lists.llvm.org> wrote:
>
> Hi, our project heavily uses c++ template, and the resulting executable is
> almost 1.5G Bytes, which is too big to be acceptable. Adding -O2 or -Os
> does not seem helping. Is there any way (like link option, etc) to reduce
> the size?
>
> ___
> 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] optimize template-heavy project with duplicate code removal

[David Blaikie via cfe-users]

On Thu, Sep 24, 2015 at 3:12 PM, chen xu  wrote:

> Thanks, David.  The build type is Debug. Today I tried removing the debug
> info (-g), the size of the executable could be cut 90%, to around 100MB,
> which looks not bad. Do you know whether there is a way to separate debug
> info file from the executable file on Linux?
>

Yep, -gsplit-dwarf - latest versions of GDB can cope with this debug info

You can also compress the debug info: -Wa,--compress-debug-sections

If you want linked debug info (rather than split debug info), consider
enabling type units to deduplicate debug info in your final executable
(-fdebug-types-section).


>  Mainly our code is already there, refactoring might require big effort..
> Also, does clang support -fno-implicit-templates? if yes, maybe we could
> use it to eliminate duplicate template instances to control the final size.
>

Not sure, off hand, whether Clang supports that.


>
> --
> Date: Wed, 23 Sep 2015 16:59:04 -0700
> Subject: Re: [cfe-users] optimize template-heavy project with duplicate
> code removal
> From: dblai...@gmail.com
> To: chen...@outlook.com
> CC: cfe-users@lists.llvm.org
>
>
> debug or non-debug build?
>
> & no, for a full release build, measuring the final executable size,
> there's not much you can do with the compiler.
>
> you can try to factor common portions out of your templates (eg: remove
> template parameters where possible - if, for example, a member function of
> a class template doesn't need all the template parameters - pull it out
> into a standalone function template that takes fewer template parameters,
> and call it from the member one)
>
> On Wed, Sep 23, 2015 at 4:43 PM, chen xu via cfe-users <
> cfe-users@lists.llvm.org> wrote:
>
> Hi, our project heavily uses c++ template, and the resulting executable is
> almost 1.5G Bytes, which is too big to be acceptable. Adding -O2 or -Os
> does not seem helping. Is there any way (like link option, etc) to reduce
> the size?
>
> ___
> 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