public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "hubicka at ucw dot cz" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug lto/99828] inlining failed in call to ‘always_inline’ ‘memcpy’: --param max-inline-insns-auto limit reached Date: Wed, 31 Mar 2021 09:16:05 +0000 [thread overview] Message-ID: <bug-99828-4-iy6ip0Mp4m@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-99828-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99828 --- Comment #7 from Jan Hubicka <hubicka at ucw dot cz> --- > Yeah, and then maybe diagnose this "ODR violation". Still I think we do have this kinds of divergence (like glibcs fortification), so I am not sure we want to warn by default. > > __attribute__((__always_inline__)) void *memcpy(); > void *foo = memcpy; > > should be ill-formed (but yeah, maybe this ship has sailed...). Yep. We took wrong move calling alwys_inline always_inline at the time it really meant disregard_inline_limits (that is correclty named internally) and then giving it the semantics of really always inlining. > > Now, I do wonder why during cgraph merging we prefer the non-definition > declaration ... the code "works fine" if it's not memcpy but memcpyx > (and thus not __builtin_memcpy but also memcpyx). Hmm, we follow resolution file here and linker doesn't know about the attributes. I guess disabling merging here is something to do (it was alwyas on my TODO list but not very high). We eventualy ought to also support keeping multiple inline bodies for different decls we decide to not merge that is bit harder to get right. > > I also wonder if we can get a better reduction of the kernel problem > due to all the diagnostics I get: > > 1.i:1:42: warning: 'always_inline' function might not be inlinable > [-Wattribute] > 1 | __attribute__((__always_inline__)) void *memcpy(); > | ^~~~~~ > 3.i:5:1: warning: conflicting types for built-in function 'memcpy'; expected > 'void *(void *, const void *, long unsigned int)' > [-Wbuiltin-declaration-mismatch] > 5 | memcpy(void *dest, void *src, long len) { > | ^~~~~~ > 1.i:1:42: warning: type of 'memcpy' does not match original declaration > [-Wlto-type-mismatch] > 1 | __attribute__((__always_inline__)) void *memcpy(); > | ^ Hmm these warnings come from different places but indeed it is bit too much :) Honza
next prev parent reply other threads:[~2021-03-31 9:16 UTC|newest] Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-03-30 13:14 [Bug lto/99828] New: " marxin at gcc dot gnu.org 2021-03-30 13:55 ` [Bug lto/99828] " rguenth at gcc dot gnu.org 2021-03-30 14:01 ` rguenth at gcc dot gnu.org 2021-03-30 17:44 ` andi-gcc at firstfloor dot org 2021-03-30 19:29 ` rguenther at suse dot de 2021-03-30 19:50 ` hubicka at ucw dot cz 2021-03-31 7:22 ` rguenth at gcc dot gnu.org 2021-03-31 9:16 ` hubicka at ucw dot cz [this message] 2021-03-31 9:29 ` marxin at gcc dot gnu.org 2021-03-31 10:05 ` rguenther at suse dot de 2021-03-31 11:56 ` marxin at gcc dot gnu.org 2022-09-22 10:58 ` jirislaby at gmail dot com 2022-09-22 10:59 ` jirislaby at gmail dot com 2022-09-22 11:20 ` rguenth at gcc dot gnu.org 2022-09-23 6:11 ` jirislaby at gmail dot com 2022-09-23 18:11 ` andi at firstfloor dot org 2022-09-23 19:50 ` marxin at gcc dot gnu.org
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=bug-99828-4-iy6ip0Mp4m@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).