From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.lore.kernel.org (Postfix) with ESMTP id C74FAC6FD18 for ; Wed, 29 Mar 2023 15:10:46 +0000 (UTC) Subject: Re: [meta-oe][PATCH] librelp: fix function inline errors in debug build To: openembedded-devel@lists.openembedded.org From: "Yash Shinde" X-Originating-Location: Mumbai, Maharashtra, IN (103.51.138.249) X-Originating-Platform: Windows Chrome 111 User-Agent: GROUPS.IO Web Poster MIME-Version: 1.0 Date: Wed, 29 Mar 2023 08:10:37 -0700 References: In-Reply-To: Message-ID: <28476.1680102637231692864@lists.openembedded.org> Content-Type: multipart/alternative; boundary="bLkbgkmRuErDNBgbA1GC" List-Id: X-Webhook-Received: from li982-79.members.linode.com [45.33.32.79] by aws-us-west-2-korg-lkml-1.web.codeaurora.org with HTTPS for ; Wed, 29 Mar 2023 15:10:46 -0000 X-Groupsio-URL: https://lists.openembedded.org/g/openembedded-devel/message/101821 --bLkbgkmRuErDNBgbA1GC Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable >=20 >=20 >=20 > Hi Yash, >=20 >=20 >=20 >=20 >=20 >=20 >=20 > First, if we're going to take this approach, you should revert my > work-around as part of this commit: >=20 >=20 >=20 > commit ca10312c4c7e88d67f4b487ae9afcbfdf92898d6 > Author:=C2=A0=C2=A0=C2=A0=C2=A0 Randy MacLeod ( Randy= .MacLeod@... ) > Date: Wed Mar 1 19:24:27 2023 >=20 > librelp: make inline errors be warnings in debug build > ... >=20 >=20 Will send a v2 if needed. >=20 >=20 >=20 > BUT... >=20 >=20 >=20 > The problem isn't so much that the code doesn't get in-lined when doing a > debug build but > that it fails to compile.=C2=A0 I think this is a compiler regressions si= nce > I was not able to reproduce the error when compiling natively using > Ubuntu-22.04 (gcc-11.3) but > was able to reproduce it using Fedora-37, gcc --version : gcc (GCC) 12.2.= 1 > 20221121 (Red Hat 12.2.1-4) >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Does the change you made actually build with the two compiler versions > above? >=20 >=20 I tested the changes in LINCD sources which have GCC 12.2. I didn=E2=80=99t= check the above mentioned version. >=20 >=20 >=20 >=20 > Is there documentation that states that >=20 > static inline void >=20 > is not as portable as: >=20 > __attribute__((always_inline)) > static inline void >=20 >=20 >=20 >=20 >=20 > I suspect there is not but I'm not a compiler geek! >=20 >=20 As you mentioned in https://github.com/rsyslog/librelp/issues/256#issue-160= 5905115 ( https://github.com/rsyslog/librelp/issues/256#:~:text=3DOh%20and%= 20it%20only%20happens%20when%20using%20%2DOg%20not%20%2DO%5B0%2D3%5D ) , it= happens only when complied without any optimization and as per https://gcc= .gnu.org/onlinedocs/gcc/Inline.html ( https://gcc.gnu.org/onlinedocs/gcc/In= line.html#:~:text=3DGCC%20does%20not%20inline,const%20char)%20__attribute__= ((always_inline))%3B ) it=E2=80=99s mentioned that: >=20 > GCC does not inline any functions when not optimizing unless you specify > the =E2=80=98always_inline=E2=80=99 attribute for the function, like this= : > /* Prototype.=C2=A0 */ inline void foo (const char) > __attribute__((always_inline)); >=20 Please let me know if we are on the same page. >=20 >=20 >=20 > ../Randy >=20 >=20 Regards, Yash --bLkbgkmRuErDNBgbA1GC Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hi Yash,

 

First, if we're going to take this approach, you should revert my work-a= round as part of this commit:

commit ca10312c4c7e88d67f4b487ae9afcbfdf92898d6
Author:  =    Randy MacLeod <Randy.MacLeod@...>
Date: Wed Mar 1 1= 9:24:27 2023

    librelp: make inline errors be w= arnings in debug build
        ...

Will send a v2 if needed.

BUT...

The problem isn't so much that the code doesn't get in-lined when doing = a debug build but
that it fails to compile.  I think this is a co= mpiler regressions since
I was not able to reproduc= e the error when compiling natively using Ubuntu-22.04 (gcc-11.3) but
= was able to reproduce it using Fedora-37, gcc --version : gcc= (GCC) 12.2.1 20221121 (Red Hat 12.2.1-4)

 

Does the change you made actually build with the two compiler versions a= bove?

I tested the changes in LINCD sources which have GCC 12.2. I didn’t c= heck the above mentioned version.


Is there documentation that states that

static inline =
void

is not as portable as:

__attribute__((always_inline)) static inline void

 

I suspect there is not but I'm not a compiler geek!

As you mentioned in https://github.com/= rsyslog/librelp/issues/256#issue-1605905115, it happens only when compl= ied without any optimization and as per https= ://gcc.gnu.org/onlinedocs/gcc/Inline.html it’s mentioned that:
 
GCC does not inline any functions when not optimizing unless you speci= fy the ‘always_inline’ attribute for the function, like this:&n= bsp;
/* Prototype.  */ inline void foo (const char) __attribute__((alw= ays_inline)); 
Please let me know if we are on the same page.

../Randy

Regards,

Yash

--bLkbgkmRuErDNBgbA1GC-- From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.lore.kernel.org (Postfix) with ESMTP id C12BEC6FD18 for ; Wed, 29 Mar 2023 15:12:16 +0000 (UTC) Subject: Re: [meta-oe][PATCH] librelp: fix function inline errors in debug build To: openembedded-devel@lists.openembedded.org From: "Yash Shinde" X-Originating-Location: Mumbai, Maharashtra, IN (103.51.138.249) X-Originating-Platform: Windows Chrome 111 User-Agent: GROUPS.IO Web Poster MIME-Version: 1.0 Date: Wed, 29 Mar 2023 08:12:12 -0700 References: In-Reply-To: Message-ID: <28476.1680102637231692864@lists.openembedded.org> X-Old-Date: Wed, 29 Mar 2023 08:10:37 -0700 Content-Type: multipart/alternative; boundary="bLkbgkmRuErDNBgbA1GC" List-Id: X-Webhook-Received: from li982-79.members.linode.com [45.33.32.79] by aws-us-west-2-korg-lkml-1.web.codeaurora.org with HTTPS for ; Wed, 29 Mar 2023 15:12:16 -0000 X-Groupsio-URL: https://lists.openembedded.org/g/openembedded-devel/message/101821 Message-ID: <20230329151212.nr6OxBTg4xTE03zv2X3UZEqXz8VcdCkkfnM4jNKeN0I@z> --bLkbgkmRuErDNBgbA1GC Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable >=20 >=20 >=20 > Hi Yash, >=20 >=20 >=20 >=20 >=20 >=20 >=20 > First, if we're going to take this approach, you should revert my > work-around as part of this commit: >=20 >=20 >=20 > commit ca10312c4c7e88d67f4b487ae9afcbfdf92898d6 > Author:=C2=A0=C2=A0=C2=A0=C2=A0 Randy MacLeod ( Randy= .MacLeod@... ) > Date: Wed Mar 1 19:24:27 2023 >=20 > librelp: make inline errors be warnings in debug build > ... >=20 >=20 Will send a v2 if needed. >=20 >=20 >=20 > BUT... >=20 >=20 >=20 > The problem isn't so much that the code doesn't get in-lined when doing a > debug build but > that it fails to compile.=C2=A0 I think this is a compiler regressions si= nce > I was not able to reproduce the error when compiling natively using > Ubuntu-22.04 (gcc-11.3) but > was able to reproduce it using Fedora-37, gcc --version : gcc (GCC) 12.2.= 1 > 20221121 (Red Hat 12.2.1-4) >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Does the change you made actually build with the two compiler versions > above? >=20 >=20 I tested the changes in LINCD sources which have GCC 12.2. I didn=E2=80=99t= check the above mentioned version. >=20 >=20 >=20 >=20 > Is there documentation that states that >=20 > static inline void >=20 > is not as portable as: >=20 > __attribute__((always_inline)) > static inline void >=20 >=20 >=20 >=20 >=20 > I suspect there is not but I'm not a compiler geek! >=20 >=20 As you mentioned in https://github.com/rsyslog/librelp/issues/256#issue-160= 5905115 ( https://github.com/rsyslog/librelp/issues/256#:~:text=3DOh%20and%= 20it%20only%20happens%20when%20using%20%2DOg%20not%20%2DO%5B0%2D3%5D ) , it= happens only when complied without any optimization and as per https://gcc= .gnu.org/onlinedocs/gcc/Inline.html ( https://gcc.gnu.org/onlinedocs/gcc/In= line.html#:~:text=3DGCC%20does%20not%20inline,const%20char)%20__attribute__= ((always_inline))%3B ) it=E2=80=99s mentioned that: >=20 > GCC does not inline any functions when not optimizing unless you specify > the =E2=80=98always_inline=E2=80=99 attribute for the function, like this= : > /* Prototype.=C2=A0 */ inline void foo (const char) > __attribute__((always_inline)); >=20 Please let me know if we are on the same page. >=20 >=20 >=20 > ../Randy >=20 >=20 Regards, Yash --bLkbgkmRuErDNBgbA1GC Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi Yash,

 

First, if we're going to take this approach, you should revert my work-a= round as part of this commit:

commit ca10312c4c7e88d67f4b487ae9afcbfdf92898d6
Author:  =    Randy MacLeod <R= andy.MacLeod@...>
Date: Wed Mar 1 19:24:27 2023

&nbs= p;   librelp: make inline errors be warnings in debug build
=         ...

Will send a v2 if needed.

BUT...

The problem isn't so much that the code doesn't get in-lined when doing = a debug build but
that it fails to compile.  I think this is a co= mpiler regressions since
I was not able to reproduc= e the error when compiling natively using Ubuntu-22.04 (gcc-11.3) but
= was able to reproduce it using Fedora-37, gcc --version : gcc= (GCC) 12.2.1 20221121 (Red Hat 12.2.1-4)

 

Does the change you made actually build with the two compiler versions a= bove?

I tested the changes in LINCD sources which have GCC 12.2. I didn’t c= heck the above mentioned version.


Is there documentation that states that

static inline void

is not as portable as:

__attribute__((always_inline)) static inline void

 

I suspect there is not but I'm not a compiler geek!

As you mentioned in https://github.com/= rsyslog/librelp/issues/256#issue-1605905115, it happens only when compl= ied without any optimization and as per https://gcc.gnu.org/onlinedocs/gcc/Inline.html it’s mentioned= that:
 
GCC does not inline any functions when not optimizing unless you speci= fy the ‘always_inline’ attribute for the function, like this:&n= bsp;
/* Prototype.  */ inline void foo (const char) __attribute__((alw= ays_inline)); 
Please let me know if we are on the same page.

../Randy

Regards,

Yash

--bLkbgkmRuErDNBgbA1GC--