[vlc-devel] [PATCH 6/6] vlc_threads: use VLC_ATTR to apply attributes

Filip Roséen filip at atch.se
Tue Feb 28 23:12:33 CET 2017

Hi Rémi,

First of all I would like to apologize for trying to stand my ground
so firmly when the, as it turns out, expressed opinion is **not**

I am truly sorry.

On 2017-02-27 18:47, Rémi Denis-Courmont wrote:

> As I tried to explain, error and warning attributes will not work if the 
> function is inlined. Function call attributes do not apply if the function is 
> not called. This is how GCC decided to implement that GCC extension. Sure, it 
> would be easier another way. But I do not get to decide how GCC designs and 
> implements their extensions, and neither do you.

Yes, you are indeed correct - and below I will elaborate on my
reasoning and show other readers where/why I ended up with the wrong
conclusion (because it is somewhat interesting).

All the best,\
Filip (now a little wiser) Roséen

The faulty experiment

    #ifdef NOINLINE
    __attribute__((error(""))) int foo() { return 0; }

    int main()
    #ifdef DEADCODE
        return 0; foo();
        return foo();

I tried the above snippet with a bunch of different versions of `gcc`,
and toggled `-DNOINLINE` with `-DDEADCODE` in order to try all the

Not only did the behavior change between versions, the result did not
depend on whether `__attribute__((noinline))` was applied:

 - The *error-diagnostic* appeared for all cases where `main` returned
   the result of `foo`, and;
 - did not appear when `foo` was called in *deadcode*.

The missing point (why I failed my tests)

As it turns out, unless the `-O1` (or higher) optimization flag is
used, `gcc` will not decide to inline the call to `foo`, and the
*error-diagnostic* will be displayed.

*Rémi Denis-Courmount* is, as stated, correct in saying that the
`noinline` attribute is a required entity in order for the relevant
code to behave as it should because when compiled with optimization,
`gcc` will inline the call to `foo` leading to the *error-diagnostic*
not being triggered.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20170228/8439f49e/attachment.html>

More information about the vlc-devel mailing list