Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #172955 > unrolled thread

Clang vs GCC on block scope declaration of inline function

Back to article view | Back to comp.lang.c

Contents

  Clang vs GCC on block scope declaration of inline function arnab chatterjee <arnabchatterjeeofficial@gmail.com> - 2023-08-28 01:30 -0700
    Re: Clang vs GCC on block scope declaration of inline function Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-08-28 06:46 -0700
      Re: Clang vs GCC on block scope declaration of inline function arnab chatterjee <arnabchatterjeeofficial@gmail.com> - 2023-08-28 21:30 -0700
    Re: Clang vs GCC on block scope declaration of inline function Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-28 16:20 +0000
      Re: Clang vs GCC on block scope declaration of inline function arnab chatterjee <arnabchatterjeeofficial@gmail.com> - 2023-08-28 21:30 -0700

#172955 — Clang vs GCC on block scope declaration of inline function

Hello all,

I'd like to confirm if there's a bug in GCC's compilation of the following code:

int main(void) { void f(void); f(); }
inline void f(void) {}

gcc successfully generates an executable, but clang gives the following error:
" undefined reference to `f' ".

It seems to me that a linker error is expected here, because (all) file scope
declarations of `f' specify inline without extern,so its given definition should
be an inline definition, not an external one (also not prohibiting the latter).

Consequently, adding a (non-inline) external definition of `f' in another file
makes the linker complain about "multiple definition of `f'" when the first file
is compiled with gcc, but an executable is generated when compiled with clang.

Also, explicitly specifying inline in the block scope declaration makes gcc's
outcome consistent with that of clang (ld reports "undefined reference to `f'").

Regards,
cHaR.

[toc] | [next] | [standalone]

#172997

arnab chatterjee <arnabchatterjeeofficial@gmail.com> writes:

> Hello all,
>
> I'd like to confirm if there's a bug in GCC's compilation of the
> following code:
>
> int main(void) { void f(void); f(); }
> inline void f(void) {}
>
> gcc successfully generates an executable, but clang gives the
> following error:  " undefined reference to `f' ".

My reading of the C standard is that what gcc does and what clang
does are both allowed by the standard.  The declarations of f()
give it external linkage.  There is a use of f().  Because of the
use, there must be an external definition of f(), but there isn't
one.  Because there isn't, the program has undefined behavior.
Hence either working or giving a link error is allowed.

> It seems to me that a linker error is expected here, because (all)
> file scope declarations of `f' specify inline without extern,so its
> given definition should be an inline definition, not an external one
> (also not prohibiting the latter).

It might be reasonable to expect a link error, but it is not
required, by virtue of the situation being undefined behavior.

> Consequently, adding a (non-inline) external definition of `f' in
> another file makes the linker complain about "multiple definition of
> `f'" when the first file is compiled with gcc, but an executable is
> generated when compiled with clang.

My reading of this result is that what gcc does does not conform
to what the C standard says.  AFAICT the program is conforming
and has no undefined behavior, so it should work.  In this case
clang is right, and gcc is wrong.

> Also, explicitly specifying inline in the block scope declaration
> makes gcc's outcome consistent with that of clang (ld reports
> "undefined reference to `f'").

That should make no difference.  The one-file case is still
undefined behavior, the two-file case is still well-defined
behavior.

[toc] | [prev] | [next] | [standalone]

#173135

On Monday, August 28, 2023 at 7:16:32 PM UTC+5:30, Tim Rentsch wrote:
> arnab chatterjee <arnabchatte...@gmail.com> writes: 
> 
> > Hello all, 
> > 
> > I'd like to confirm if there's a bug in GCC's compilation of the 
> > following code: 
> > 
> > int main(void) { void f(void); f(); } 
> > inline void f(void) {} 
> > 
> > gcc successfully generates an executable, but clang gives the 
> > following error: " undefined reference to `f' ".
> My reading of the C standard is that what gcc does and what clang 
> does are both allowed by the standard. The declarations of f() 
> give it external linkage. There is a use of f(). Because of the 
> use, there must be an external definition of f(), but there isn't 
> one. Because there isn't, the program has undefined behavior. 
> Hence either working or giving a link error is allowed.
> > It seems to me that a linker error is expected here, because (all) 
> > file scope declarations of `f' specify inline without extern,so its 
> > given definition should be an inline definition, not an external one 
> > (also not prohibiting the latter).
> It might be reasonable to expect a link error, but it is not 
> required, by virtue of the situation being undefined behavior.
> > Consequently, adding a (non-inline) external definition of `f' in 
> > another file makes the linker complain about "multiple definition of 
> > `f'" when the first file is compiled with gcc, but an executable is 
> > generated when compiled with clang.
> My reading of this result is that what gcc does does not conform 
> to what the C standard says. AFAICT the program is conforming 
> and has no undefined behavior, so it should work. In this case 
> clang is right, and gcc is wrong.
> > Also, explicitly specifying inline in the block scope declaration 
> > makes gcc's outcome consistent with that of clang (ld reports 
> > "undefined reference to `f'").
> That should make no difference. The one-file case is still 
> undefined behavior, the two-file case is still well-defined 
> behavior.

I see; I had not considered the possibility that absence of external definition
in the first case (even though one is required) would cause undefined behavior.

Thank you for clarifying the difference between the single file and multi file
examples;I think I'll submit a bug report describing only the two-file scenario.

[toc] | [prev] | [next] | [standalone]

#173019

On 2023-08-28, arnab chatterjee <arnabchatterjeeofficial@gmail.com> wrote:
> Hello all,
>
> I'd like to confirm if there's a bug in GCC's compilation of the following code:
>
> int main(void) { void f(void); f(); }
> inline void f(void) {}

How are you invoking GCC?

If you've not specified a dialect to GCC, you're working in GNU C.

GNU C had inline functions long before C99 standardized them, and
of course they are not exactly the same as ISO C inline functions.

Just sayin'.

-- 
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

[toc] | [prev] | [next] | [standalone]

#173136

On Monday, August 28, 2023 at 9:51:03 PM UTC+5:30, Kaz Kylheku wrote:
> On 2023-08-28, arnab chatterjee <arnabchatte...@gmail.com> wrote: 
> > Hello all, 
> > 
> > I'd like to confirm if there's a bug in GCC's compilation of the following code: 
> > 
> > int main(void) { void f(void); f(); } 
> > inline void f(void) {}
> How are you invoking GCC? 
> 
> If you've not specified a dialect to GCC, you're working in GNU C. 
> 
> GNU C had inline functions long before C99 standardized them, and 
> of course they are not exactly the same as ISO C inline functions. 
> 
> Just sayin'. 
> 
> -- 
> TXR Programming Language: http://nongnu.org/txr 
> Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal 
> Mastodon: @Kazi...@mstdn.ca

I used gcc 13.0.1 as: gcc-13 -std=c17 -Wall -Wextra -pedantic
Also tried with -std=c99 and -std=c2x dialects along with -O2 and -O3 enabled
(hoping higher optimization might trigger some warning), but outcome was same.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.c

csiph-web