[cfe-dev] On preserving unused file-local definitions at -O0

[David Blaikie]

On Fri, Apr 11, 2014 at 1:14 PM, Robinson, Paul
<Paul_Robinson at playstation.sony.com> wrote:
>> -----Original Message-----
>> From: David Blaikie [mailto:dblaikie at gmail.com]
>> Sent: Friday, April 11, 2014 11:34 AM
>> To: Robinson, Paul
>> Cc: cfe-dev Developers; Eric Christopher
>> Subject: Re: [cfe-dev] On preserving unused file-local definitions at -
>> O0
>>
>> On Fri, Apr 11, 2014 at 9:46 AM, Robinson, Paul
>> <Paul_Robinson at playstation.sony.com> wrote:
>> >> For Clang, run the GDB suite with -femit_all_decls ?
>> >> --paulr
>> >
>> > Speling it korecly, -femit-all-decls (duh).
>>
>> Huh - I think I vaguely knew about that flag at some point & forgot
>> again (or never knew about it in the first place).
>>
>> Neat-ish. Poor name of the flag (given it's about definitions, not
>> declarations).
>>
>> Still want to try to get the GDB test suite clean with clang's default
>> configuration, ideally, one way or another. But actually the
>> difference in behavior between GCC's default and Clang's default or
>> Clang with -femit-all-decls is an interesting point. Clang either
>> emits 'everything' (unused static definitions and unused inline
>> definitions) or nothing. GCC is somewhere in the middle (emits unused
>> static definitions, but doesn't emit unused inline definitions) - so
>> perhaps that's a useful point to make to the GDB community that GCC
>> doesn't have a strong principle here... maybe. (I can see some
>> possible counterarguments already, though)
>>
>> - David
>
> Right, and you start straying into questions of whether the GDB test
> suite is more properly verifying GDB's behavior or the compiler's
> behavior.  I think it's a highly desirable goal to ensure that Clang's
> output can be consumed by GDB, which is not quite the same thing as
> ensuring that Clang's default behavior satisfies the assumptions made
> by the GDB test suite.
>
> All good fodder for an LLVM-social discussion, sometime.

Yep, all a bit vague/tricky.