[llvm-bugs] [Bug 51826] New: Bad handling of aligned_alloc with invalid alignment

[via llvm-bugs]

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

            Bug ID: 51826
           Summary: Bad handling of aligned_alloc with invalid alignment
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Global Analyses
          Assignee: unassignedbugs at nondot.org
          Reporter: harald at gigawatt.nl
                CC: llvm-bugs at lists.llvm.org

As of DR #460
<http://www.open-std.org/jtc1/sc22/wg14/www/docs/summary.htm#dr_460>, passing
invalid alignments to aligned_alloc is no longer UB, but is required to result
in a null pointer being returned. That means, I think, the below program is
supposed to run successfully:

  #include <stdlib.h>
  int main() {
    if (aligned_alloc(3, 1))
      abort();
  }

With jemalloc (as glibc does not implement the new rule yet either) and
otherwise default options, it does run successfully, but at -O1, LLVM optimises
this to an unconditional call to abort().

Changing the example slightly by specifying an alignment of 0 instead:

  #include <stdlib.h>
  int main() {
    if (aligned_alloc(0, 1))
      abort();
  }

With jemalloc and otherwise default options, it again runs successfully. At
-O1, with clang 12, it unconditionally calls abort(). With clang trunk (tested
on godbolt.org), the compiler crashes:

<source>:3:21: warning: requested alignment is not a power of 2
[-Wnon-power-of-two-alignment]
  if (aligned_alloc(0, 1))
                    ^
PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash
backtrace, preprocessed source, and associated run script.
Stack dump:
0.      Program arguments: /opt/compiler-explorer/clang-trunk/bin/clang -g -o
/app/output.s -mllvm --x86-asm-syntax=intel -S
--gcc-toolchain=/opt/compiler-explorer/gcc-9.2.0 -fcolor-diagnostics
-fno-crash-diagnostics -O1 <source>
1.      <eof> parser at end of file
2.      Optimizer
 #0 0x000056154078684f PrintStackTraceSignalHandler(void*) Signals.cpp:0:0
 #1 0x0000561540784710 llvm::sys::CleanupOnSignal(unsigned long)
(/opt/compiler-explorer/clang-trunk/bin/clang+0x3584710)
 #2 0x00005615406d5088 CrashRecoverySignalHandler(int)
CrashRecoveryContext.cpp:0:0
 #3 0x00007f5fc06c23c0 __restore_rt
(/lib/x86_64-linux-gnu/libpthread.so.0+0x153c0)
 #4 0x00005615406b4c8a llvm::APInt::setBitsSlowCase(unsigned int, unsigned int)
(/opt/compiler-explorer/clang-trunk/bin/clang+0x34b4c8a)
 #5 0x000056153f92d0d9 computeKnownBitsFromAssume(llvm::Value const*,
llvm::KnownBits&, unsigned int, (anonymous namespace)::Query const&)
ValueTracking.cpp:0:0
[...]

https://godbolt.org/z/M7hW85vf4

-- 
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/20210912/29c2ca1e/attachment.html>