Path: csiph.com!eternal-september.org!feeder.eternal-september.org!nntp.eternal-september.org!.POSTED!not-for-mail From: Tim Rentsch Newsgroups: comp.lang.c Subject: Re: gcc and 'include' Date: Tue, 31 Mar 2026 00:26:09 -0700 Organization: A noiseless patient Spider Lines: 116 Message-ID: <861ph01mum.fsf@linuxsc.com> References: <10q4ceb$38i2d$1@dont-email.me> <20260327041042.00006946@yahoo.com> <86wlyy2fe7.fsf@linuxsc.com> <20260327164757.00001882@yahoo.com> <86jyux2ras.fsf@linuxsc.com> <20260329114618.000039da@yahoo.com> <86a4vp1h0n.fsf@linuxsc.com> <20260330200851.00002b49@yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Date: Tue, 31 Mar 2026 07:26:11 +0000 (UTC) Injection-Info: dont-email.me; posting-host="e91bae0a57aea678d37e66cfcf4f5608"; logging-data="3278374"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18XL2weHwLaEDB+TYcYkC09l87fDEz7dc0=" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:t4bz7JO44cOLs19xltQUP/nF88w= sha1:oW24nbifpEXLVolQoVbrlOmhdhs= Xref: csiph.com comp.lang.c:397322 Michael S writes: > On Mon, 30 Mar 2026 08:19:52 -0700 > Tim Rentsch wrote: > >> Michael S writes: >> >>> On Fri, 27 Mar 2026 09:03:23 -0700 >>> Tim Rentsch wrote: >>> >>>> Michael S writes: >>>> >>>>> On Thu, 26 Mar 2026 19:08:16 -0700 >>>>> Tim Rentsch wrote: >>>>> >>>>>> Michael S writes: >>>>>> >>>>>>> On Thu, 26 Mar 2026 22:36:59 +0000 >>>>>>> Bart wrote: >>>>>>> >>>>>>>> Take this program: >>>>>>>> >>>>>>>> #include >>>>>>>> >>>>>>>> inline int F(){return rand();} >>>>>>>> >>>>>>>> int main(void) { >>>>>>>> return F(); >>>>>>>> } >>>>>>>> >>>>>>>> This compiles fine with gcc using -O1 -O2 -O3. >>>>>>>> >>>>>>>> But compile without optimising, and it fails to link as it >>>>>>>> can't find a function 'F'. >>>>>>>> >>>>>>>> Is it supposed to behave like that? I assume no discrete >>>>>>>> function F is being generated because of the 'inline' >>>>>>>> attribute, but you'd think it would ignore that if >>>>>>>> inlining wasn't enabled. >>>>>>>> >>>>>>>> [...] >>>>>>> >>>>>>> Sounds like a bug introduced during transition to c99/gnu99 >>>>>>> front end. >>>>>>> With gcc4.x, which defaults to gnu89 it still works. >>>>>>> Also works with the latest gcc -std=gnu89 >>>>>>> But there is no hope that gcc maintaines will ever admit that it >>>>>>> is a bug. >>>>>> >>>>>> It isn't a bug. The C standard allows this behavior. >>>>> >>>>> So, by C standard, there is no situation in which 'inline' >>>>> with no addition qualifuers like 'static' or 'extern' can be >>>>> used with predictabe outcome? >>>> >>>> That depends on just how you mean the question. If we have this >>>> source file >>>> >>>> inline int >>>> F(){ >>>> return 0; >>>> } >>>> >>>> int >>>> main(void){ >>>> return F(); >>>> } >>>> >>>> then we might get an undefined reference for F(). However if we >>>> expand that source file just slightly, to >>>> >>>> inline int >>>> F(){ >>>> return 0; >>>> } >>>> >>>> int >>>> main(void){ >>>> return F(); >>>> } >>>> >>>> int F(); >>>> >>>> then the program has well-defined behavior. This result obtains >>>> because the function F() now has a declaration that is (implicitly) >>>> external, and without specifying 'inline', in addition to the >>>> original inline definition. >>> >>> It is indeed well-defined. But well-defined behavior does not >>> match the most probable intention of programmer, which is to >>> create a body of F() in case that it was not actually inlined and >>> to *not* create it otherwise. >> >> I simply disagree. The behavior you describe is what people expect >> for static inline functions. It doesn't make sense that they would >> expect the same thing for non-static inline functions, if they had >> taken some time to think about it. >> >>> For something like MSVC it does not matter, because by default it >>> does not link unused functions into executive. But something like >>> gcc by default links everything in. >> >> That depends on what you mean by "by default". gcc does not >> produce an actual function body for any optimization level >> above -O0. Surely the most common practice these days is to >> enable some optimization level above -O0. > > In the comment above I was talking specifically about that: > https://godbolt.org/z/4TazP4sq1 I don't know what you were expecting me to learn by looking at that page. As far as I can tell it adds no information beyond what has already been presented. Also I'm surprised that you didn't say anything in reaction to the first paragraph of my comments. No conclusion, just surprised.