[Bug ipa/67368] Inlining failed due to no_sanitize_address and always_inline conflict
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67368 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #5 from Andrew Pinski --- Dup of bug 89124. *** This bug has been marked as a duplicate of bug 89124 ***
[Bug ipa/67368] Inlining failed due to no_sanitize_address and always_inline conflict
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67368 Loïc Yhuel changed: What|Removed |Added CC||loic.yhuel at gmail dot com --- Comment #4 from Loïc Yhuel --- (In reply to Andrey Ryabinin from comment #3) > Nope, it was prohibited because no_sanitize_address didn't work for inlined > function https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59600. So this case should work : functions inlined into a no_sanitize_address function would have the sanitizer disabled. Unlike the opposite, which could crash, this one only could fail to detect issues at runtime, so perhaps it should only be a warning.
[Bug ipa/67368] Inlining failed due to no_sanitize_address and always_inline conflict
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67368 Andrey Ryabinin changed: What|Removed |Added CC||ryabinin.a.a at gmail dot com --- Comment #3 from Andrey Ryabinin --- (In reply to Yury Gribov from comment #2) > (In reply to Richard Biener from comment #1) > > so it fails on purpose (not sure why though). And it ignores always-inline. > > I wonder if we should, for always-inline functions, inline anyway and output > > a warning instead. > > We prohibited this combination during ASan integration to kernel. Both > always_inline and no_sanitize_address are strong requirements for compiler > i.e. dropping any of these in favor of another would have unexpected effects > and hurt usability. Nope, it was prohibited because no_sanitize_address didn't work for inlined function https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59600.
[Bug ipa/67368] Inlining failed due to no_sanitize_address and always_inline conflict
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67368
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2015-08-27
CC||hubicka at gcc dot gnu.org,
||y.gribov at samsung dot com
Component|c++ |ipa
Ever confirmed|0 |1
--- Comment #1 from Richard Biener rguenth at gcc dot gnu.org ---
/* Don't inline a function with mismatched sanitization attributes. */
else if (!sanitize_attrs_match_for_inline_p (caller-decl, callee-decl))
{
e-inline_failed = CIF_ATTRIBUTE_MISMATCH;
inlinable = false;
static bool
sanitize_attrs_match_for_inline_p (const_tree caller, const_tree callee)
{
/* Don't care if sanitizer is disabled */
if (!(flag_sanitize SANITIZE_ADDRESS))
return true;
if (!caller || !callee)
return true;
return !!lookup_attribute (no_sanitize_address,
DECL_ATTRIBUTES (caller)) ==
!!lookup_attribute (no_sanitize_address,
DECL_ATTRIBUTES (callee));
so it fails on purpose (not sure why though). And it ignores always-inline.
I wonder if we should, for always-inline functions, inline anyway and output
a warning instead.
[Bug ipa/67368] Inlining failed due to no_sanitize_address and always_inline conflict
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67368 --- Comment #2 from Yury Gribov y.gribov at samsung dot com --- (In reply to Richard Biener from comment #1) so it fails on purpose (not sure why though). And it ignores always-inline. I wonder if we should, for always-inline functions, inline anyway and output a warning instead. We prohibited this combination during ASan integration to kernel. Both always_inline and no_sanitize_address are strong requirements for compiler i.e. dropping any of these in favor of another would have unexpected effects and hurt usability.
