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.
>
> Examp
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
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 wrot
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
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)
O
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
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 gener
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-use
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:
> >
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
> > bel
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/At
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 a
101 - 112 of 112 matches
Mail list logo
