[llvm-bugs] [Bug 45655] New: Request to hook up -fno-builtin-aligned_alloc

via llvm-bugs llvm-bugs at lists.llvm.org
Thu Apr 23 17:57:48 PDT 2020


https://bugs.llvm.org/show_bug.cgi?id=45655

            Bug ID: 45655
           Summary: Request to hook up -fno-builtin-aligned_alloc
           Product: clang
           Version: trunk
          Hardware: PC
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: C11
          Assignee: uday at polymagelabs.com
          Reporter: chang-sun.lin.jr at intel.com
                CC: blitzrakete at gmail.com, dgregor at apple.com,
                    erik.pilkington at gmail.com, llvm-bugs at lists.llvm.org,
                    richard-llvm at metafoo.co.uk

For users that have a different aligned_alloc implementation such as jemalloc:
http://jemalloc.net/

it might be desirable to turn off TLI recognition of aligned_alloc (commit
D76970) without having to turn off all builtins with -fno-builtin or
-ffreestanding. -fno-builtin-aligned_alloc doesn't look like it's recognized by
the front end (and doesn't result in a nobuiltin attribute on the call).

As an example of a difference, the above jemalloc library is strict POSIX and
will set errno if a non-power-of-2 alignment is given. When the code below is
compiled with clang -O2 and jemalloc, the printf will print "(nil) 0" because
jemalloc will produce NULL, but InstCombine assumes the call will succeed and
replaces errno with 0. Having a way to turn off recognition just for this
function, would be very helpful to fix the inconsistency.

#include <stdlib.h>
#include <stdio.h>
#include <errno.h>

int main() {
  void *p;

  errno = 0;
  p = (int *)aligned_alloc(0x81,1);
  printf("%p %d\n", p, errno);

  return 0;
}

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20200424/e859c3fe/attachment.html>


More information about the llvm-bugs mailing list