[Bug c++/67368] New: Inlining failed due to no_sanitize_address and always_inline conflict

[Bug c++/67368] New: Inlining failed due to no_sanitize_address and always_inline conflict

[wojciech.mula at microgen dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67368

            Bug ID: 67368
           Summary: Inlining failed due to no_sanitize_address and
                    always_inline conflict
           Product: gcc
           Version: 4.9.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: wojciech.mula at microgen dot com
  Target Milestone: ---

When compiling program

-- bug.cpp --
#include <emmintrin.h>

__attribute__((no_sanitize_address))                                           
 void foo() {
   __m128i z = _mm_setzero_si128();
}
-- eof --

using following command

$ g++ -c -fsanitize=address bug.cpp

GCC reports:

In file included from bug.cpp:1:0:
[...]/x86_64-unknown-linux-gnu/4.9.2/include/emmintrin.h: In function ‘void
foo()’:
[...]/x86_64-unknown-linux-gnu/4.9.2/include/emmintrin.h:749:1: error: inlining
failed in call to always_inline ‘__m128i _mm_setzero_si128()’: function
attribute mismatch
 _mm_setzero_si128 (void)
 ^
bug.cpp:5:36: error: called from here
      __m128i z = _mm_setzero_si128();

Compiler version (built from the sources):

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=[...]/libexec/gcc/x86_64-unknown-linux-gnu/4.9.2/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: [...]/source/gcc-4.9.2/configure --prefix=[...]
--with-local-prefix=[...] --enable-languages=c,c++ --disable-multilib
Thread model: posix
gcc version 4.9.2 (GCC)

I've checked the sample program on https://gcc.godbolt.org/ and for versions
5.1.0 & 5.2.0 there is the same problem. However 4.9.2 from Ubuntu is not
affected.
>From gcc-bugs-return-495711-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Aug 27 08:42:34 2015
Return-Path: <gcc-bugs-return-495711-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 42650 invoked by alias); 27 Aug 2015 08:42:33 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 42566 invoked by uid 48); 27 Aug 2015 08:42:30 -0000
From: "redi at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug libstdc++/67361] std::regex_error::what() should say something about the error_code
Date: Thu, 27 Aug 2015 08:42:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: libstdc++
X-Bugzilla-Version: 4.9.4
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: redi at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_status cf_reconfirmed_on everconfirmed
Message-ID: <bug-67361-4-b7mgRALjIv@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-67361-4@http.gcc.gnu.org/bugzilla/>
References: <bug-67361-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-08/txt/msg01853.txt.bz2
Content-length: 500

https://gcc.gnu.org/bugzilla/show_bug.cgi?idg361

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2015-08-27
     Ever confirmed|0                           |1

--- Comment #2 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Yes, that would be even better!

[Bug ipa/67368] Inlining failed due to no_sanitize_address and always_inline conflict

[rguenth at gcc dot gnu.org]

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

[y.gribov at samsung dot com]

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.

[Bug ipa/67368] Inlining failed due to no_sanitize_address and always_inline conflict

[ryabinin.a.a at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67368

Andrey Ryabinin <ryabinin.a.a at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ryabinin.a.a at gmail dot com

--- Comment #3 from Andrey Ryabinin <ryabinin.a.a at gmail dot com> ---
(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

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67368

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |DUPLICATE
             Status|NEW                         |RESOLVED

--- Comment #5 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Dup of bug 89124.

*** This bug has been marked as a duplicate of bug 89124 ***