This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug ipa/65873] New: [5/6 Regression] Failure to inline always_inline memcpy


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

            Bug ID: 65873
           Summary: [5/6 Regression] Failure to inline always_inline
                    memcpy
           Product: gcc
           Version: 5.1.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: ipa
          Assignee: unassigned at gcc dot gnu.org
          Reporter: jakub at gcc dot gnu.org

typedef __SIZE_TYPE__ size_t;

extern inline __attribute__ ((__always_inline__, __gnu_inline__,
__artificial__, __nothrow__, __leaf__)) void *
memcpy (void *__restrict __dest, const void *__restrict __src, size_t __len)
{
  return __builtin___memcpy_chk (__dest, __src, __len, __builtin_object_size
(__dest, 0));
}

__attribute__((optimize ("Ofast"))) void
bar (void *d, void *s, size_t l)
{
  memcpy (d, s, l);
}

fails to compile starting with r221706 (or r221707, neither of those versions
compile, r221704 works, r221710 fails).

This makes with -D_FORTIFY_SOURCE=2 all fortified functions unusable in
functions with explicit (non-default) optimize attribute.

As the always_inline function doesn't have a specific optimize attribute, I'd
say at least for always_inline functions it is undesirable to refuse to inline
them.  For target attribute, do we also refuse to inline, if say the whole CU
is compiled with -mavx2 and some function uses __attribute__((target ("sse2")))
and calls memcpy?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]