All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Yash Shinde" <yashinde145@gmail.com>
To: openembedded-devel@lists.openembedded.org
Subject: Re: [meta-oe][PATCH] librelp: fix function inline errors in debug build
Date: Wed, 29 Mar 2023 08:10:37 -0700	[thread overview]
Message-ID: <28476.1680102637231692864@lists.openembedded.org> (raw)
In-Reply-To: <f6a4a396-84a6-9787-ad8a-d4e283a6442d@windriver.com>

[-- Attachment #1: Type: text/plain, Size: 2181 bytes --]

> 
> 
> 
> Hi Yash,
> 
> 
> 
> 
> 
> 
> 
> First, if we're going to take this approach, you should revert my
> work-around as part of this commit:
> 
> 
> 
> commit ca10312c4c7e88d67f4b487ae9afcbfdf92898d6
> Author:     Randy MacLeod <Randy.MacLeod@...> ( Randy.MacLeod@... )
> Date: Wed Mar 1 19:24:27 2023
> 
> 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 compiler regressions since
> 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)
> 
> 
> 
> 
> 
> 
> 
> Does the change you made actually build with the two compiler versions
> above?
> 
> 

I tested the changes in LINCD sources which have GCC 12.2. I didn’t check 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 ( https://github.com/rsyslog/librelp/issues/256#:~:text=Oh%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/Inline.html#:~:text=GCC%20does%20not%20inline,const%20char)%20__attribute__((always_inline))%3B ) it’s mentioned that:

> 
> GCC does not inline any functions when not optimizing unless you specify
> the ‘always_inline’ attribute for the function, like this:
> /* Prototype.  */ inline void foo (const char)
> __attribute__((always_inline));
> 

Please let me know if we are on the same page.

> 
> 
> 
> ../Randy
> 
> 

Regards,

Yash

[-- Attachment #2: Type: text/html, Size: 2682 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: "Yash Shinde" <yashinde145@gmail.com>
To: openembedded-devel@lists.openembedded.org
Subject: Re: [meta-oe][PATCH] librelp: fix function inline errors in debug build
Date: Wed, 29 Mar 2023 08:12:12 -0700	[thread overview]
Message-ID: <28476.1680102637231692864@lists.openembedded.org> (raw)
Message-ID: <20230329151212.nr6OxBTg4xTE03zv2X3UZEqXz8VcdCkkfnM4jNKeN0I@z> (raw)
In-Reply-To: <f6a4a396-84a6-9787-ad8a-d4e283a6442d@windriver.com>

[-- Attachment #1: Type: text/plain, Size: 2181 bytes --]

> 
> 
> 
> Hi Yash,
> 
> 
> 
> 
> 
> 
> 
> First, if we're going to take this approach, you should revert my
> work-around as part of this commit:
> 
> 
> 
> commit ca10312c4c7e88d67f4b487ae9afcbfdf92898d6
> Author:     Randy MacLeod <Randy.MacLeod@...> ( Randy.MacLeod@... )
> Date: Wed Mar 1 19:24:27 2023
> 
> 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 compiler regressions since
> 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)
> 
> 
> 
> 
> 
> 
> 
> Does the change you made actually build with the two compiler versions
> above?
> 
> 

I tested the changes in LINCD sources which have GCC 12.2. I didn’t check 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 ( https://github.com/rsyslog/librelp/issues/256#:~:text=Oh%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/Inline.html#:~:text=GCC%20does%20not%20inline,const%20char)%20__attribute__((always_inline))%3B ) it’s mentioned that:

> 
> GCC does not inline any functions when not optimizing unless you specify
> the ‘always_inline’ attribute for the function, like this:
> /* Prototype.  */ inline void foo (const char)
> __attribute__((always_inline));
> 

Please let me know if we are on the same page.

> 
> 
> 
> ../Randy
> 
> 

Regards,

Yash

[-- Attachment #2: Type: text/html, Size: 2636 bytes --]

  reply	other threads:[~2023-03-29 15:10 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20230329075827.437650-1-yashinde145@gmail.com>
2023-03-29 13:36 ` [meta-oe][PATCH] librelp: fix function inline errors in debug build Randy MacLeod
2023-03-29 15:10   ` Yash Shinde [this message]
2023-03-29 15:12     ` Yash Shinde
2023-03-29 15:49   ` [oe] " Khem Raj
2023-03-30  4:10   ` Shinde, Yash
2023-03-30  4:10   ` Shinde, Yash
2023-03-29 12:36 Yash Shinde
  -- strict thread matches above, loose matches on Subject: below --
2023-03-29 12:32 Yash Shinde

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=28476.1680102637231692864@lists.openembedded.org \
    --to=yashinde145@gmail.com \
    --cc=openembedded-devel@lists.openembedded.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.