On Thu, 12 Sep 2024, Dmitry Baryshkov <dmitry.baryshkov@xxxxxxxxxx> wrote:
> On Thu, Sep 12, 2024 at 02:50:04PM GMT, Marc Gonzalez wrote:
>> On 12/09/2024 14:28, Dmitry Baryshkov wrote:
>> > On Thu, Sep 12, 2024 at 02:14:10PM GMT, Marc Gonzalez wrote:
>> >> On 12/09/2024 13:15, Jani Nikula wrote:
>> >>> On Thu, 12 Sep 2024, Marc Gonzalez wrote:
>> >>>> On 11/09/2024 12:23, Jani Nikula wrote:
>> >>>>> On Tue, 10 Sep 2024, Marc Gonzalez wrote:
>> >>>>>> On 10/09/2024 16:51, Dmitry Baryshkov wrote:
>> >>>>>>> On Tue, Sep 10, 2024 at 01:03:43PM GMT, Jani Nikula wrote:
>> >>>>>>>> See also commit 6863f5643dd7 ("kbuild: allow Clang to find unused static
>> >>>>>>>> inline functions for W=1 build").
>> >>>
>> >>> [snip]
>> >>>
>> >>>>> GCC doesn't catch unused static inlines, while Clang does.
>> >>>>
>> >>>> It makes no sense to me that adding "inline" would prevent
>> >>>> GCC from diagnosing the issue... GCC should simply ignore
>> >>>> the "inline" keyword when definition is not in a header file
>> >>>> (maybe they don't store "origin").
>> >>>
>> >>> Please just read the commit message for the commit I reference above for
>> >>> details. There's not much more I could say about it.
>> >>
>> >> OK, I read 6863f5643dd7.
>> >>
>> >> My remark still stands.
>> >>
>> >> GCC's decision to not warn for unused static inline functions
>> >> in source files (not headers) is questionable at best.
>> >
>> > What's the difference between source file and a header after the CPP
>> > run?
>>
>> That question is moot, since the source file / header file
>> convention exists only _before_ the preprocessor runs.
>>
>> If you meant to ask
>> "How is the implementation supposed to track the origin",
>> then I would hand wave and say "internal annotations".
>
> No, I asked what I meant. #include doesn't have any semantics. You can
> #include "source.c" in the same way. So asking the compiler to make a
> difference between source file and the header isn't going to work (Note,
> gcc has some notion of system header files and I think a pragma that
> changes the behaviour a bit, but we are not talking about such cases,
> are we?).
Just saying, this sub-thread might be more fruitful on some GCC bug or
list.
BR,
Jani.
--
Jani Nikula, Intel
