[llvm-bugs] [Bug 45367] New: Aggregates containing elements with constexpr constructors are not statically initalized

2020-03-31 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=45367

Bug ID: 45367
   Summary: Aggregates containing elements with constexpr
constructors are not statically initalized
   Product: clang
   Version: 10.0
  Hardware: PC
OS: Windows NT
Status: NEW
  Severity: normal
  Priority: P
 Component: C++2a
  Assignee: unassignedclangb...@nondot.org
  Reporter: billy.on...@gmail.com
CC: blitzrak...@gmail.com, erik.pilking...@gmail.com,
llvm-bugs@lists.llvm.org, richard-l...@metafoo.co.uk

Created attachment 23295
  --> https://bugs.llvm.org/attachment.cgi?id=23295&action=edit
repro.cpp

Previously reported as https://github.com/microsoft/STL/issues/661

In the following example, should_be_statically_initalized should be eligible
for static initialization, then the dynamic initializer for foo that calls
bar() should run, resulting in the asserts in main(). However, clang only seems
to give these static initializers if the varaible is {}'d.

C:\Users\billy\Desktop>type repro.cpp
#include 

struct FakeAtomic {
int example;

constexpr FakeAtomic() noexcept : example{} {}
int operator++() { return ++example; }
int operator++(int) { return example++; }
int load() const { return example; }
};

struct Meow {
FakeAtomic data[2];
char padding[64];
};

int bar();

int foo = bar();
#ifdef WORKAROUND
Meow should_be_statically_initalized[256]{};
#else
Meow should_be_statically_initalized[256];
#endif

int bar() { return should_be_statically_initalized[0].data[0]++; }

int main() {
assert(foo == 0);
assert(should_be_statically_initalized[0].data[0].load() == 1);
}

C:\Users\billy\Desktop>clang-cl /EHsc /W4 /WX .\repro.cpp

C:\Users\billy\Desktop>.\repro.exe
Assertion failed: should_be_statically_initalized[0].data[0].load() == 1, file
.\repro.cpp, line 30

C:\Users\billy\Desktop>clang-cl /DWORKAROUND /EHsc /W4 /WX .\repro.cpp

C:\Users\billy\Desktop>.\repro.exe

C:\Users\billy\Desktop>

-- 
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs

[llvm-bugs] [Bug 45368] New: c++2a: string::reserve still shrinks capacity (P0966)

2020-03-31 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=45368

Bug ID: 45368
   Summary: c++2a: string::reserve still shrinks capacity (P0966)
   Product: libc++
   Version: unspecified
  Hardware: PC
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P
 Component: All Bugs
  Assignee: unassignedclangb...@nondot.org
  Reporter: rprich...@google.com
CC: llvm-bugs@lists.llvm.org, mclow.li...@gmail.com

libc++ documents that it has implemented P0966R1[1][2], "string::reserve Should
Not Shrink", but as far as I can tell, string::reserve still shrinks the
capacity.

#include 
#include 
int main() {
  std::string foo;
  foo.reserve(2000);
  printf("%zu\n", foo.capacity());
  foo.reserve(1000);
  printf("%zu\n", foo.capacity());
  return 0;
}

$ /x/llvm-upstream/stage1-install/bin/clang++ -stdlib=libc++ test.cpp &&
LD_LIBRARY_PATH=/x/llvm-upstream/stage1-install/lib ./a.out

2015
1007

[1] https://libcxx.llvm.org/cxx2a_status.html
[2] http://wg21.link/P0966R1

The P0966R1 change was implemented in D54992[3] / svn commit 347789[4].

[3] https://reviews.llvm.org/D54992
[4] https://reviews.llvm.org/rL347789

P0966R1 allows reserve() and reserve(0) to do different things, so they need to
be overloads rather than use a default argument of 0, and the libc++ commit
does split the function into two overloaded functions. libc++'s
string::reserve(size_type) function still lowers the capacity, though. Its
shrink_to_fit() still calls reserve(), which calls reserve(0).

http://eel.is/c++draft/string.capacity#itemdecl:6 reads:

constexpr void reserve(size_type res_arg);

Effects: A directive that informs a basic_­string of a planned change in
size, so that the storage allocation can be managed accordingly. After
reserve(), capacity() is greater or equal to the argument of reserve if
reallocation happens; and equal to the previous value of capacity() otherwise.
Reallocation happens at this point if and only if the current capacity is less
than the argument of reserve().

The libc++ commit added a test that looks like it verifies that reserve doesn't
shrink, but it doesn't really do that. In string.capacity/reserve.pass.cpp:

 template 
 void
 test(S s, typename S::size_type res_arg)
 {
 typename S::size_type old_cap = s.capacity();
 ((void)old_cap); // Prevent unused warning
 S s0 = s;
 if (res_arg <= s.max_size())
 {
 s.reserve(res_arg);
 assert(s == s0);
 assert(s.capacity() >= res_arg);
 assert(s.capacity() >= s.size());
+#if TEST_STD_VER > 17
+assert(s.capacity() >= old_cap); // resize never shrinks as of
P0966
+#endif

(I think the comment meant to say "reserve never shrinks" rather than "resize
never shrinks"?)

This call to test() looks like it would catch the issue:

{
typedef std::string S;
...
{
S s(100, 'a');
s.erase(50);
test(s, 5);

We have a string, `s` with size() == 50 and capacity() >= 100. Calling
reserve(5) should leave the capacity() >= 100 as of P0966R1, but libc++ shrinks
the string to a little above 50. However, main() passes the string by-value to
test(), and the copy constructor makes a new string that's shrunk-to-fit. i.e.
AFAICT, the sections in main() that use erase() aren't testing the intended
situation.

-- 
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs

[llvm-bugs] [Bug 45369] New: Missing symbols when llvm is build with LTO

2020-03-31 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=45369

Bug ID: 45369
   Summary: Missing symbols when llvm is build with LTO
   Product: libraries
   Version: 10.0
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P
 Component: Backend: X86
  Assignee: unassignedb...@nondot.org
  Reporter: kloczko.tom...@gmail.com
CC: craig.top...@gmail.com, llvm-bugs@lists.llvm.org,
llvm-...@redking.me.uk, spatel+l...@rotateright.com

I've build my own llvm packages using gcc 10 from Fedora rawhide.
That package is with LTO optimised.

When I've installed my own llvm I found that now I cannot build mesa because
some symbols are missing during linking mesa

[tkloczko@barrel mesa-20.0.2]$ /usr/bin/ninja -v -j1 -C x86_64-redhat-linux-gnu
ninja: Entering directory `x86_64-redhat-linux-gnu'
[1/41] /usr/bin/python3 ../bin/git_sha1_gen.py --output src/git_sha1.h
 [2/15] g++  -o src/amd/vulkan/libvulkan_radeon.so
'src/amd/vulkan/9198681@@vulkan_radeon@sha/meson-generated_.._radv_entrypoints.c.o'
'src/amd/vulkan/9198681@@vulkan_radeon@sha/meson-generated_.._radv_extensions.c.o'
'src/amd/vulkan/9198681@@vulkan_radeon@sha/meson-generated_.._vk_format_table.c.o'
'src/amd/vulkan/9198681@@vulkan_radeon@sha/winsys_amdgpu_radv_amdgpu_bo.c.o'
'src/amd/vulkan/9198681@@vulkan_radeon@sha/winsys_amdgpu_radv_amdgpu_cs.c.o'
'src/amd/vulkan/9198681@@vulkan_radeon@sha/winsys_amdgpu_radv_amdgpu_surface.c.o'
'src/amd/vulkan/9198681@@vulkan_radeon@sha/winsys_amdgpu_radv_amdgpu_winsys.c.o'
'src/amd/vulkan/9198681@@vulkan_radeon@sha/radv_android.c.o'
'src/amd/vulkan/9198681@@vulkan_radeon@sha/radv_cmd_buffer.c.o'
'src/amd/vulkan/9198681@@vulkan_radeon@sha/radv_debug.c.o'
'src/amd/vulkan/9198681@@vulkan_radeon@sha/radv_device.c.o'
'src/amd/vulkan/9198681@@vulkan_radeon@sha/radv_descriptor_set.c.o'
'src/amd/vulkan/9198681@@vulkan_radeon@sha/radv_formats.c.o'
'src/amd/vulkan/9198681@@vulkan_radeon@sha/radv_image.c.o'
'src/amd/vulkan/9198681@@vulkan_radeon@sha/radv_llvm_helper.cpp.o'
'src/amd/vulkan/9198681@@vulkan_radeon@sha/radv_meta.c.o'
'src/amd/vulkan/9198681@@vulkan_radeon@sha/radv_meta_blit.c.o'
'src/amd/vulkan/9198681@@vulkan_radeon@sha/radv_meta_blit2d.c.o'
'src/amd/vulkan/9198681@@vulkan_radeon@sha/radv_meta_buffer.c.o'
'src/amd/vulkan/9198681@@vulkan_radeon@sha/radv_meta_bufimage.c.o'
'src/amd/vulkan/9198681@@vulkan_radeon@sha/radv_meta_clear.c.o'
'src/amd/vulkan/9198681@@vulkan_radeon@sha/radv_meta_copy.c.o'
'src/amd/vulkan/9198681@@vulkan_radeon@sha/radv_meta_decompress.c.o'
'src/amd/vulkan/9198681@@vulkan_radeon@sha/radv_meta_fast_clear.c.o'
'src/amd/vulkan/9198681@@vulkan_radeon@sha/radv_meta_fmask_expand.c.o'
'src/amd/vulkan/9198681@@vulkan_radeon@sha/radv_meta_resolve.c.o'
'src/amd/vulkan/9198681@@vulkan_radeon@sha/radv_meta_resolve_cs.c.o'
'src/amd/vulkan/9198681@@vulkan_radeon@sha/radv_meta_resolve_fs.c.o'
'src/amd/vulkan/9198681@@vulkan_radeon@sha/radv_nir_lower_ycbcr_textures.c.o'
'src/amd/vulkan/9198681@@vulkan_radeon@sha/radv_nir_to_llvm.c.o'
'src/amd/vulkan/9198681@@vulkan_radeon@sha/radv_pass.c.o'
'src/amd/vulkan/9198681@@vulkan_radeon@sha/radv_pipeline.c.o'
'src/amd/vulkan/9198681@@vulkan_radeon@sha/radv_pipeline_cache.c.o'
'src/amd/vulkan/9198681@@vulkan_radeon@sha/radv_shader.c.o'
'src/amd/vulkan/9198681@@vulkan_radeon@sha/radv_shader_args.c.o'
'src/amd/vulkan/9198681@@vulkan_radeon@sha/radv_shader_info.c.o'
'src/amd/vulkan/9198681@@vulkan_radeon@sha/radv_query.c.o'
'src/amd/vulkan/9198681@@vulkan_radeon@sha/radv_util.c.o'
'src/amd/vulkan/9198681@@vulkan_radeon@sha/radv_wsi.c.o'
'src/amd/vulkan/9198681@@vulkan_radeon@sha/si_cmd_buffer.c.o'
'src/amd/vulkan/9198681@@vulkan_radeon@sha/radv_wsi_x11.c.o'
'src/amd/vulkan/9198681@@vulkan_radeon@sha/radv_wsi_wayland.c.o'
'src/amd/vulkan/9198681@@vulkan_radeon@sha/radv_wsi_display.c.o'
-Wl,--as-needed -Wl,--no-undefined -shared -fPIC -Wl,--start-group
-Wl,-soname,libvulkan_radeon.so -O2 -g -pipe -Wall -Werror=format-security
-Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fstack-protector-strong
-grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic
-fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection
-flto=auto -flto-partition=none -Wl,-z,relro -Wl,--as-needed -Wl,-z,now
-specs=/usr/lib/rpm/redhat/redhat-hardened-ld -flto=auto -flto-partition=none
-fuse-linker-plugin src/amd/common/libamd_common.a
src/amd/llvm/libamd_common_llvm.a src/amd/addrlib/libaddrlib.a
src/vulkan/wsi/libvulkan_wsi.a src/vulkan/util/libvulkan_util.a
src/util/libxmlconfig.a src/util/libmesa_util.a
src/util/format/libmesa_format.a src/amd/compiler/libaco.a
src/compiler/nir/libnir.a src/compiler/libcompiler.a -Wl,-Bsymbolic
-Wl,--gc-sections -lLLVM-10 -pthread /usr/lib64/libdrm_amdgpu.so
/usr/lib64/libelf.so -ldl -lm /usr/lib64/libxcb-dri3.so
/usr/lib64/libwayland-

[llvm-bugs] [Bug 45370] New: wrong/misleading "SHF_MERGE section size must be a multiple of sh_entsize"

2020-03-31 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=45370

Bug ID: 45370
   Summary: wrong/misleading "SHF_MERGE section size must be a
multiple of sh_entsize"
   Product: lld
   Version: unspecified
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P
 Component: ELF
  Assignee: unassignedb...@nondot.org
  Reporter: and...@tao11.riddles.org.uk
CC: llvm-bugs@lists.llvm.org, smithp...@googlemail.com

Corresponding FreeBSD bug linked as "see also"; see that bug's own "see also"
link for where this came from.

In ObjFile::shouldMerge in lld/ELF/InputFiles.cpp:

  if (sec.sh_size % entSize)
fatal(toString(this) + ":(" + name + "): SHF_MERGE section size (" +
  Twine(sec.sh_size) + ") must be a multiple of sh_entsize (" +
  Twine(entSize) + ")");

  uint64_t flags = sec.sh_flags;
  if (!(flags & SHF_MERGE))
return false;

Notice that the size is being checked _before_ the SHF_MERGE flag is checked.
This means that either the logic is incorrect, or the error message is
incorrect (since this error will then occur for sections without SHF_MERGE).

If this size check is only needed for mergeable sections, then surely it should
be made _after_ SHF_MERGE is checked for.

Since this check is skipped when -O0 is in effect, I do not believe it is
actually necessary to check that size is a multiple of sh_entsize when _not_
merging sections. If I'm wrong about that, though, then the check would need to
be both moved to somewhere else and changed to not mention SHF_MERGE in the
error message.

-- 
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs

[llvm-bugs] [Bug 45371] New: opt -separate-const-offset-from-gep fails with Assertion `isa(Val) && "cast() argument of incompatible type!"' failed.

2020-03-31 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=45371

Bug ID: 45371
   Summary: opt -separate-const-offset-from-gep fails with
Assertion `isa(Val) && "cast() argument of
incompatible type!"' failed.
   Product: libraries
   Version: trunk
  Hardware: PC
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P
 Component: Scalar Optimizations
  Assignee: unassignedb...@nondot.org
  Reporter: mikael.hol...@ericsson.com
CC: llvm-bugs@lists.llvm.org

Created attachment 23296
  --> https://bugs.llvm.org/attachment.cgi?id=23296&action=edit
bbi-40415_aarch64.ll reproducer

Reproduce with:
 opt -mtriple aarch64-unknown-linux-gnu -separate-const-offset-from-gep -S -o -
bbi-40415_aarch64.ll

Result:

opt: ../include/llvm/Support/Casting.h:263: typename cast_retty::ret_type llvm::cast(Y *) [X = llvm::BinaryOperator, Y = llvm::User]:
Assertion `isa(Val) && "cast() argument of incompatible type!"' failed.
PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash
backtrace.
Stack dump:
0.  Program arguments: ../../master/llvm/build-all-builtins/bin/opt
-mtriple aarch64-unknown-linux-gnu -separate-const-offset-from-gep -S -o -
bbi-40415_aarch64.ll 
1.  Running pass 'Function Pass Manager' on module 'bbi-40415_aarch64.ll'.
2.  Running pass 'Split GEPs to a variadic base and a constant offset for
better CSE' on function '@g'
 #0 0x0429aa64 PrintStackTraceSignalHandler(void*)
(../../master/llvm/build-all-builtins/bin/opt+0x429aa64)
 #1 0x0429862e llvm::sys::RunSignalHandlers()
(../../master/llvm/build-all-builtins/bin/opt+0x429862e)
 #2 0x0429ae6c SignalHandler(int)
(../../master/llvm/build-all-builtins/bin/opt+0x429ae6c)
 #3 0x7f06058ce890 __restore_rt
(/lib/x86_64-linux-gnu/libpthread.so.0+0x12890)
 #4 0x7f0604377e97 raise
/build/glibc-OTsEL5/glibc-2.27/signal/../sysdeps/unix/sysv/linux/raise.c:51:0
 #5 0x7f0604379801 abort /build/glibc-OTsEL5/glibc-2.27/stdlib/abort.c:81:0
 #6 0x7f060436939a __assert_fail_base
/build/glibc-OTsEL5/glibc-2.27/assert/assert.c:89:0
 #7 0x7f0604369412 (/lib/x86_64-linux-gnu/libc.so.6+0x30412)
 #8 0x0418c322 (anonymous
namespace)::ConstantOffsetExtractor::distributeExtsAndCloneChain(unsigned int)
(../../master/llvm/build-all-builtins/bin/opt+0x418c322)
 #9 0x0418c1dc (anonymous
namespace)::ConstantOffsetExtractor::distributeExtsAndCloneChain(unsigned int)
(../../master/llvm/build-all-builtins/bin/opt+0x418c1dc)
#10 0x04189ae8 (anonymous
namespace)::SeparateConstOffsetFromGEP::splitGEP(llvm::GetElementPtrInst*)
(../../master/llvm/build-all-builtins/bin/opt+0x4189ae8)
#11 0x04188638 (anonymous
namespace)::SeparateConstOffsetFromGEP::runOnFunction(llvm::Function&)
(../../master/llvm/build-all-builtins/bin/opt+0x4188638)
#12 0x03af5374 llvm::FPPassManager::runOnFunction(llvm::Function&)
(../../master/llvm/build-all-builtins/bin/opt+0x3af5374)
#13 0x03af5628 llvm::FPPassManager::runOnModule(llvm::Module&)
(../../master/llvm/build-all-builtins/bin/opt+0x3af5628)
#14 0x03af5c7d llvm::legacy::PassManagerImpl::run(llvm::Module&)
(../../master/llvm/build-all-builtins/bin/opt+0x3af5c7d)
#15 0x02370d9f main
(../../master/llvm/build-all-builtins/bin/opt+0x2370d9f)
#16 0x7f060435ab97 __libc_start_main
/build/glibc-OTsEL5/glibc-2.27/csu/../csu/libc-start.c:344:0
#17 0x0235b02a _start
(../../master/llvm/build-all-builtins/bin/opt+0x235b02a)
Abort (core dumped)

-- 
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs

[llvm-bugs] [Bug 45372] New: Cannot Find Conversion Operator

2020-03-31 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=45372

Bug ID: 45372
   Summary: Cannot Find Conversion Operator
   Product: clang
   Version: trunk
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P
 Component: C++
  Assignee: unassignedclangb...@nondot.org
  Reporter: marcel.k...@uni-muenster.de
CC: blitzrak...@gmail.com, dgre...@apple.com,
erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org,
richard-l...@metafoo.co.uk

In the following MWE https://godbolt.org/z/F3gHe2 clang states that the
conversion operator to int does not exist.

clang only complains about function f, while explicitly calling the operator
does not result in an error.

Additionally gcc and msvc accept this code.

This behaviour is present in the versions 6 to trunk.

-- 
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs

[llvm-bugs] [Bug 45314] Redundant vmov{q,d} in 32-bit splat

2020-03-31 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=45314

Sanjay Patel  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED
 Fixed By Commit(s)||464b9aeafe29

--- Comment #12 from Daan Sprenkels  ---
I submitted an initial patch at .

--- Comment #13 from Sanjay Patel  ---
Should be fixed with:
https://reviews.llvm.org/rG464b9aeafe29
Thanks for the patch, Daan!

-- 
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs

[llvm-bugs] [Bug 45373] New: std::shuffle freeze up

2020-03-31 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=45373

Bug ID: 45373
   Summary: std::shuffle freeze up
   Product: libc++
   Version: unspecified
  Hardware: Macintosh
OS: MacOS X
Status: NEW
  Severity: release blocker
  Priority: P
 Component: All Bugs
  Assignee: unassignedclangb...@nondot.org
  Reporter: sda...@protonmail.com
CC: llvm-bugs@lists.llvm.org, mclow.li...@gmail.com

Created attachment 23297
  --> https://bugs.llvm.org/attachment.cgi?id=23297&action=edit
C++ source file showcasing the problem.

Using std::shuffle with a generator that yields the same value for all calls
causes std::shuffle to freeze up. I attached a C++ source file showcasing the
problem.

Replicates on:
Apple clang version 11.0.0 (clang-1100.0.33.12)
Target: x86_64-apple-darwin19.3.0
Thread model: posix

Replication:
clang++ -o bug.exe -std=c++17 bug.cpp && ./bug.exe

The application will freeze when trying to shuffle the elements.
The application will no longer freeze if the 17th element is removed from
samples.

-- 
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs

[llvm-bugs] Issue 21468 in oss-fuzz: llvm:clang-fuzzer: Null-dereference READ in clang::Sema::DiagnoseUnexpandedParameterPack

2020-03-31 Thread ClusterFuzz-External via monorail via llvm-bugs 
Updates:
Labels: ClusterFuzz-Verified
Status: Verified

Comment #1 on issue 21468 by ClusterFuzz-External: llvm:clang-fuzzer: 
Null-dereference READ in clang::Sema::DiagnoseUnexpandedParameterPack
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=21468#c1

ClusterFuzz testcase 5157853330669568 is verified as fixed in 
https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=202003300253:202003310247

If this is incorrect, please file a bug on 
https://github.com/google/oss-fuzz/issues/new

-- 
You received this message because:
  1. You were specifically CC'd on the issue

You may adjust your notification preferences at:
https://bugs.chromium.org/hosting/settings

Reply to this email to add a comment.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs

[llvm-bugs] Issue 21522 in oss-fuzz: llvm:clang-fuzzer: Stack-overflow in GetFullTypeForDeclarator

2020-03-31 Thread ClusterFuzz-External via monorail via llvm-bugs 
Updates:
Labels: ClusterFuzz-Verified
Status: Verified

Comment #1 on issue 21522 by ClusterFuzz-External: llvm:clang-fuzzer: 
Stack-overflow in GetFullTypeForDeclarator
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=21522#c1

ClusterFuzz testcase 5386516181549056 is verified as fixed in 
https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=202003300253:202003310247

If this is incorrect, please file a bug on 
https://github.com/google/oss-fuzz/issues/new

-- 
You received this message because:
  1. You were specifically CC'd on the issue

You may adjust your notification preferences at:
https://bugs.chromium.org/hosting/settings

Reply to this email to add a comment.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs

[llvm-bugs] Issue 18251 in oss-fuzz: llvm:llvm-isel-fuzzer--wasm32-O2: Abrt in llvm::llvm_unreachable_internal

2020-03-31 Thread ClusterFuzz-External via monorail via llvm-bugs 
Updates:
Labels: ClusterFuzz-Verified
Status: Verified

Comment #3 on issue 18251 by ClusterFuzz-External: 
llvm:llvm-isel-fuzzer--wasm32-O2: Abrt in llvm::llvm_unreachable_internal
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=18251#c3

ClusterFuzz testcase 5635591105937408 is verified as fixed in 
https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=202003300253:202003310247

If this is incorrect, please file a bug on 
https://github.com/google/oss-fuzz/issues/new

-- 
You received this message because:
  1. You were specifically CC'd on the issue

You may adjust your notification preferences at:
https://bugs.chromium.org/hosting/settings

Reply to this email to add a comment.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs

[llvm-bugs] Issue 13350 in oss-fuzz: llvm/llvm-opt-fuzzer--x86_64-loop_vectorize: ASSERT: getTypeSizeInBits(SrcTy) <= getTypeSizeInBits(Ty) && "getNoopOrZeroExtend cannot

2020-03-31 Thread ClusterFuzz-External via monorail via llvm-bugs 
Updates:
Labels: ClusterFuzz-Verified
Status: Verified

Comment #4 on issue 13350 by ClusterFuzz-External: 
llvm/llvm-opt-fuzzer--x86_64-loop_vectorize: ASSERT: getTypeSizeInBits(SrcTy) 
<= getTypeSizeInBits(Ty) && "getNoopOrZeroExtend cannot
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=13350#c4

ClusterFuzz testcase 5647164997369856 is verified as fixed in 
https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=202003300253:202003310247

If this is incorrect, please file a bug on 
https://github.com/google/oss-fuzz/issues/new

-- 
You received this message because:
  1. You were specifically CC'd on the issue

You may adjust your notification preferences at:
https://bugs.chromium.org/hosting/settings

Reply to this email to add a comment.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs

[llvm-bugs] Issue 21394 in oss-fuzz: llvm:clang-format-fuzzer: Null-dereference READ in clang::format::TokenAnnotator::calculateFormattingInformation

2020-03-31 Thread ClusterFuzz-External via monorail via llvm-bugs 
Updates:
Labels: ClusterFuzz-Verified
Status: Verified

Comment #1 on issue 21394 by ClusterFuzz-External: llvm:clang-format-fuzzer: 
Null-dereference READ in 
clang::format::TokenAnnotator::calculateFormattingInformation
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=21394#c1

ClusterFuzz testcase 5674913957675008 is verified as fixed in 
https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=202003300253:202003310247

If this is incorrect, please file a bug on 
https://github.com/google/oss-fuzz/issues/new

-- 
You received this message because:
  1. You were specifically CC'd on the issue

You may adjust your notification preferences at:
https://bugs.chromium.org/hosting/settings

Reply to this email to add a comment.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs

[llvm-bugs] [Bug 42618] CVP: adding nuw flags not correct in the presence of undef

2020-03-31 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=42618

Nuno Lopes  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #1 from Nuno Lopes  ---
We now have langref stating that jump on undef is UB. So this one is good.

-- 
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs

[llvm-bugs] Issue 21521 in oss-fuzz: llvm:clang-fuzzer: Stack-overflow in clang::DeclSpec::Finish

2020-03-31 Thread ClusterFuzz-External via monorail via llvm-bugs 
Updates:
Labels: ClusterFuzz-Verified
Status: Verified

Comment #1 on issue 21521 by ClusterFuzz-External: llvm:clang-fuzzer: 
Stack-overflow in clang::DeclSpec::Finish
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=21521#c1

ClusterFuzz testcase 5688640635404288 is verified as fixed in 
https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=202003300253:202003310247

If this is incorrect, please file a bug on 
https://github.com/google/oss-fuzz/issues/new

-- 
You received this message because:
  1. You were specifically CC'd on the issue

You may adjust your notification preferences at:
https://bugs.chromium.org/hosting/settings

Reply to this email to add a comment.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs

[llvm-bugs] [Bug 45374] New: [PowerPC] Assertion failed: `!DeadOrKillToUnset && "Shouldn't kill same register twice"'

2020-03-31 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=45374

Bug ID: 45374
   Summary: [PowerPC] Assertion failed: `!DeadOrKillToUnset &&
"Shouldn't kill same register twice"'
   Product: new-bugs
   Version: 10.0
  Hardware: Other
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P
 Component: new bugs
  Assignee: unassignedb...@nondot.org
  Reporter: v.chur...@gmail.com
CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org

Stacktrace:

```
removeRedundantLIs at
/home/vchuravy/julia/deps/srccache/llvm-10.0.0/lib/Target/PowerPC/PPCPreEmitPeephole.cpp:113
runOnMachineFunction at
/home/vchuravy/julia/deps/srccache/llvm-10.0.0/lib/Target/PowerPC/PPCPreEmitPeephole.cpp:184
runOnFunction at
/home/vchuravy/julia/deps/srccache/llvm-10.0.0/lib/CodeGen/MachineFunctionPass.cpp:73
runOnFunction at
/home/vchuravy/julia/deps/srccache/llvm-10.0.0/lib/IR/LegacyPassManager.cpp:1481
runOnModule at
/home/vchuravy/julia/deps/srccache/llvm-10.0.0/lib/IR/LegacyPassManager.cpp:1517
runOnModule at
/home/vchuravy/julia/deps/srccache/llvm-10.0.0/lib/IR/LegacyPassManager.cpp:1582
run at
/home/vchuravy/julia/deps/srccache/llvm-10.0.0/lib/IR/LegacyPassManager.cpp:1694
run at
/home/vchuravy/julia/deps/srccache/llvm-10.0.0/lib/IR/LegacyPassManager.cpp:1725
operator() at /home/vchuravy/julia/src/aotcompile.cpp:509
jl_dump_native at /home/vchuravy/julia/src/aotcompile.cpp:518
```

```
(gdb) p MBB.dump()  
bb.14.SP_return:
; predecessors: %bb.13
  liveins: $x3
  renamable $x3 = LDtocL @jl_false, killed renamable $x3, implicit $x2 :: (load
8 from got)
  renamable $x3 = LD 0, killed renamable $x3 :: (dereferenceable load 8 from
@jl_false, !tbaa !11669)
  dead $r4 = LI 130, implicit-def $x4, debug-location !29895;
/nobackup/users/vchuravy/builds/julia-dbg-10/usr/share/julia/stdlib/v1.5/Pkg/src/REP$
Mode/completions.jl:104
  $x1 = ADDI8 $x1, 240, debug-location !29895;
/nobackup/users/vchuravy/builds/julia-dbg-10/usr/share/julia/stdlib/v1.5/Pkg/src/REPLMode/completio$
s.jl:104
  $x0 = LD 16, $x1, debug-location !29895;
/nobackup/users/vchuravy/builds/julia-dbg-10/usr/share/julia/stdlib/v1.5/Pkg/src/REPLMode/completions.j$
:104
  $x30 = LD -16, $x1, debug-location !29895 :: (load 8 from %fixed-stack.0,
align 16); /nobackup/users/vchuravy/builds/julia-dbg-10/usr/share/juli$
/stdlib/v1.5/Pkg/src/REPLMode/completions.jl:104
  $x29 = LD -24, $x1, debug-location !29895 :: (load 8 from %fixed-stack.1);
/nobackup/users/vchuravy/builds/julia-dbg-10/usr/share/julia/stdlib/v$
.5/Pkg/src/REPLMode/completions.jl:104
  $x28 = LD -32, $x1, debug-location !29895 :: (load 8 from %fixed-stack.2,
align 16); /nobackup/users/vchuravy/builds/julia-dbg-10/usr/share/juli$
/stdlib/v1.5/Pkg/src/REPLMode/completions.jl:104
  MTLR8 killed $x0, implicit-def $lr8, debug-location !29895;
/nobackup/users/vchuravy/builds/julia-dbg-10/usr/share/julia/stdlib/v1.5/Pkg/src/REP$
Mode/completions.jl:104
  $x27 = LD -40, $x1, debug-location !29895 :: (load 8 from %fixed-stack.3);
/nobackup/users/vchuravy/builds/julia-dbg-10/usr/share/julia/stdlib/v$
.5/Pkg/src/REPLMode/completions.jl:104
  $x26 = LD -48, $x1, debug-location !29895 :: (load 8 from %fixed-stack.4,
align 16); /nobackup/users/vchuravy/builds/julia-dbg-10/usr/share/juli$
/stdlib/v1.5/Pkg/src/REPLMode/completions.jl:104
  $x25 = LD -56, $x1, debug-location !29895 :: (load 8 from %fixed-stack.5);
/nobackup/users/vchuravy/builds/julia-dbg-10/usr/share/julia/stdlib/v$
.5/Pkg/src/REPLMode/completions.jl:104
  BLR8 implicit $lr8, implicit $rm, implicit killed $x3, implicit killed $x4,
debug-location !29895; /nobackup/users/vchuravy/builds/julia-dbg-10/u
sr/share/julia/stdlib/v1.5/Pkg/src/REPLMode/completions.jl:104
```

```
111   int KillIdx = AfterBBI->findRegisterUseOperandIdx(Reg, true,
TRI);
112   if (KillIdx != -1) {
113 assert(!DeadOrKillToUnset && "Shouldn't kill same register
twice");
114 DeadOrKillToUnset = &AfterBBI->getOperand(KillIdx);
115 LLVM_DEBUG(dbgs()
116<< " Kill flag of " << *DeadOrKillToUnset << "
from "
117<< *AfterBBI << " is a unsetting candidate\n");
(gdb) p AfterBBI->dump()
  BLR8 implicit $lr8, implicit $rm, implicit killed $x3, implicit killed $x4,
debug-location !29895;
/nobackup/users/vchuravy/builds/julia-dbg-10/usr/share/julia/stdlib/v1.5/Pkg/src/REPLMode/completions.jl:104
```

This is the same configuration as https://bugs.llvm.org/show_bug.cgi?id=45366

-- 
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs

[llvm-bugs] [Bug 45375] New: Missing function parameter names messes with AlwaysBreakAfterReturnType and BreakBeforeBraces

2020-03-31 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=45375

Bug ID: 45375
   Summary: Missing function parameter names messes with
AlwaysBreakAfterReturnType and BreakBeforeBraces
   Product: clang
   Version: unspecified
  Hardware: PC
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P
 Component: Formatter
  Assignee: unassignedclangb...@nondot.org
  Reporter: rb...@eudoxos.de
CC: djas...@google.com, kli...@google.com,
llvm-bugs@lists.llvm.org

Consider these two functions:

```
template 
XY
xy1(X, Y y)
{
  return XY{};
}

template  
XY 
xy2(X, Y)
{
  return XY{};
}
```

Note the absence of parameter names in the second function template.

Using this config

```
BasedOnStyle:  LLVM
AlwaysBreakAfterReturnType: All
AlwaysBreakTemplateDeclarations: Yes
BreakBeforeBraces: Allman
```

the formatter ignores the `AlwaysBreakAfterReturnType`:

```
template 
XY
xy1(X, Y y)
{
  return XY{};
}

template 
XY xy2(X, Y)
{
  return XY{};
}
```

It gets more extreme when dropping the `AlwaysBreakTemplateDeclarations` rule.

```
BasedOnStyle:  LLVM
AlwaysBreakAfterReturnType: All
BreakBeforeBraces: Allman
```

The formatter now yields completely different results for the two functions:

```
template 
XY
xy1(X, Y y)
{
  return XY{};
}

template  XY xy2(X, Y) { return XY{}; }
```

See also: https://stackoverflow.com/q/60903794/2173029

-- 
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs

[llvm-bugs] [Bug 45376] New: Merge 673e81e into the 10.0 branch

2020-03-31 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=45376

Bug ID: 45376
   Summary: Merge 673e81e into the 10.0 branch
   Product: new-bugs
   Version: 10.0
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P
 Component: new bugs
  Assignee: unassignedb...@nondot.org
  Reporter: tstel...@redhat.com
CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org
Blocks: 45309

Is it OK to merge the following revision(s) to the 10.0 branch?


Referenced Bugs:

https://bugs.llvm.org/show_bug.cgi?id=45309
[Bug 45309] [meta] 10.0.1 Release Blockers
-- 
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs

[llvm-bugs] [Bug 40125] Poor code generated for __builtin_sub_overflow with constant RHS

2020-03-31 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=40125

John McCall  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #5 from John McCall  ---
If we're generating good code now (and it looks like we are), I think the bug
can be resolved.

-- 
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs

[llvm-bugs] [Bug 45377] New: [tsan] Unexpectedly warns about double lock of a mutex

2020-03-31 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=45377

Bug ID: 45377
   Summary: [tsan] Unexpectedly warns about double lock of a mutex
   Product: compiler-rt
   Version: unspecified
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P
 Component: tsan
  Assignee: unassignedb...@nondot.org
  Reporter: lewissba...@gmail.com
CC: llvm-bugs@lists.llvm.org

Created attachment 23298
  --> https://bugs.llvm.org/attachment.cgi?id=23298&action=edit
Example program that demonstrates issue.

Compile the attached program tsan.cpp with clang trunk (github commit
6a9ad5f3f4ac66f0cae592e911f4baeb6ee5eca6).

Command-line args: -std=c++2a -stdlib=libc++ -fsanitize=thread

Running the program occasionally (about 1 in 4 for me) fails with a
ThreadSanitizer warning about a mutex being double locked despite the code only
ever using scoped lock-guards.

See the attached file (tsan_log.txt) for output of the program when run with
tsan trace output enabled.

The log seems to indicate that tsan has observed two threads simultaneously
acquiring a lock on the same mutex - two threads both execute MutexPostLock for
the same mutex without an intervening MutexUnlock event.

Tests were run on Ubuntu 18.04 with kernel 5.5.2-050502-generic.
Also tested with kernel 5.6.0-050600-generic and observed the same problem.

It is unclear whether this is due to tsan, libc++ or pthread.

-- 
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs

[llvm-bugs] [Bug 45092] [SystemZ] - Valid instructions are rejected with "%r0 used in an address"

2020-03-31 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=45092

Ulrich Weigand  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from Ulrich Weigand  ---
Now fixed as c726c920e040.

-- 
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs

[llvm-bugs] Issue 19951 in oss-fuzz: llvm:llvm-dwarfdump-fuzzer: ASSERT: hasVal

2020-03-31 Thread sheriffbot via monorail via llvm-bugs 
Updates:
Labels: Deadline-Approaching

Comment #1 on issue 19951 by sheriffbot: llvm:llvm-dwarfdump-fuzzer: ASSERT: 
hasVal
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=19951#c1

This bug is approaching its deadline for being fixed, and will be automatically 
derestricted within 7 days. If a fix is planned within 2 weeks after the 
deadline has passed, a grace extension can be granted.

- Your friendly Sheriffbot

-- 
You received this message because:
  1. You were specifically CC'd on the issue

You may adjust your notification preferences at:
https://bugs.chromium.org/hosting/settings

Reply to this email to add a comment.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs

[llvm-bugs] [Bug 45378] New: [X86] recent codegen regression for vector load and reduce

2020-03-31 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=45378

Bug ID: 45378
   Summary: [X86] recent codegen regression for vector load and
reduce
   Product: libraries
   Version: trunk
  Hardware: PC
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P
 Component: Backend: X86
  Assignee: unassignedb...@nondot.org
  Reporter: fedor.v.serg...@gmail.com
CC: craig.top...@gmail.com, llvm-bugs@lists.llvm.org,
llvm-...@redking.me.uk, spatel+l...@rotateright.com

The following IR testcase started producing suboptimal codegen on recent X86
hardware (haswell+):

] cat load-and-reduce.ll
declare i64 @llvm.experimental.vector.reduce.or.v2i64(<2 x i64>) 
declare void @TrapFunc(i64)

define void @parseHeaders(i64 * %ptr) {
  %vptr = bitcast i64 * %ptr to <2 x i64> *
  %vload = load <2 x i64>, <2 x i64> * %vptr, align 8
  %vreduce = call i64 @llvm.experimental.vector.reduce.or.v2i64(<2 x i64>
%vload)
  %vcheck = icmp eq i64 %vreduce, 0
  br i1 %vcheck, label %ret, label %trap
trap:
  %v2 = extractelement <2 x i64> %vload, i32 1
  call void @TrapFunc(i64 %v2)
  ret void
ret:
  ret void
}
] bin/llc -filetype=asm load-and-reduce.ll -mtriple=x86_64-unknown-linux-gnu
-mcpu=skylake -o - | grep -A8 movdq
vmovdqu (%rdi), %xmm0
vpbroadcastq8(%rdi), %xmm1
vpor%xmm1, %xmm0, %xmm1
vmovq   %xmm1, %rax
testq   %rax, %rax
je  .LBB0_2
# %bb.1:# %trap
vpextrq $1, %xmm0, %rdi
callq   TrapFunc
]

There are two loads here, which does not seem to be efficient solution here.

Note, that for ivybridge- it generates load+shuffle instead of a load+load,
which looks like a better codegen:

] bin/llc -filetype=asm load-and-reduce.ll -mtriple=x86_64-unknown-linux-gnu
-mcpu=ivybridge -o - | grep -A8 movdq
vmovdqu (%rdi), %xmm0
vpshufd $78, %xmm0, %xmm1   # xmm1 = xmm0[2,3,0,1]
vpor%xmm1, %xmm0, %xmm1
vmovq   %xmm1, %rax
testq   %rax, %rax
je  .LBB0_2
# %bb.1:# %trap
vpextrq $1, %xmm0, %rdi
callq   TrapFunc
]

This appears to be a rather recent change in behavior, caused by 
commit e48b536be66b60b05fa77b85258e6cf2ec417220
Author: Sanjay Patel 
Date:   Sun Feb 16 10:32:56 2020 -0500

[x86] form broadcast of scalar memop even with >1 use

Before that commit all X86 targets generate the same load+shuffle sequence.

-- 
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs

[llvm-bugs] [Bug 45379] New: Implement -fsanitize=bounds-strict

2020-03-31 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=45379

Bug ID: 45379
   Summary: Implement -fsanitize=bounds-strict
   Product: compiler-rt
   Version: unspecified
  Hardware: PC
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P
 Component: ubsan
  Assignee: unassignedb...@nondot.org
  Reporter: keesc...@chromium.org
CC: llvm-bugs@lists.llvm.org

Created attachment 23300
  --> https://bugs.llvm.org/attachment.cgi?id=23300&action=edit
bounds checking PoC

I'd like Clang's UBSan bounds checker to disallow the old-style 0-byte and
1-byte array declarations as being seen as a variant of a flexible array
member.

As it turns out, GCC has "-fsanitize=bounds-strict" which gets me close to what
I'd like (it still allows 0-byte):


(Built with gcc -fsanitize=bounds)
$ ./bounds-gcc abc
flex (should always be okay): ok (no trap!)
zero (should be okay, treated as flex): ok (no trap!)
one (should fail): FAIL (this should have trapped!)
non_flex (should fail): FAIL (this should have trapped!)
non_trailing (absolutely should fail): Illegal instruction (core dumped)

(Built with gcc -fsanitize=bounds-strict)
$ ./bounds-gcc abc
flex (should always be okay): ok (no trap!)
zero (should be okay, treated as flex): ok (no trap!)
one (should fail): Illegal instruction (core dumped)

(Built with clang -fsanitize=bounds)
$ ./bounds-clang abc
flex (should always be okay): ok (no trap!)
zero (should be okay, treated as flex): ok (no trap!)
one (should fail): FAIL (this should have trapped!)
non_flex (should fail): Illegal instruction (core dumped)


Could Clang's UBSan grow the "strict" version of this to check 1-byte arrays?

-- 
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs

[llvm-bugs] [Bug 45309] [meta] 10.0.1 Release Blockers

2020-03-31 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=45309
Bug 45309 depends on bug 45301, which changed state.

Bug 45301 Summary: 'Can't simplify this node' when building ppc64_defconfig 
Linux kernel
https://bugs.llvm.org/show_bug.cgi?id=45301

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

-- 
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs

[llvm-bugs] [Bug 45301] 'Can't simplify this node' when building ppc64_defconfig Linux kernel

2020-03-31 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=45301

Nathan Chancellor  changed:

   What|Removed |Added

 Resolution|FIXED   |---
 Status|RESOLVED|REOPENED

--- Comment #6 from Nathan Chancellor  ---
Reopening to properly track for llvm-10.0.1.

-- 
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs

[llvm-bugs] [Bug 45309] [meta] 10.0.1 Release Blockers

2020-03-31 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=45309
Bug 45309 depends on bug 44878, which changed state.

Bug 44878 Summary: crash with --emit-relocs and --strip-debug when debug 
sections present
https://bugs.llvm.org/show_bug.cgi?id=44878

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

-- 
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs

[llvm-bugs] [Bug 44878] crash with --emit-relocs and --strip-debug when debug sections present

2020-03-31 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=44878

Nathan Chancellor  changed:

   What|Removed |Added

 CC||natechancel...@gmail.com
 Blocks||45309
 Resolution|FIXED   |---
 Status|RESOLVED|REOPENED

--- Comment #4 from Nathan Chancellor  ---
lld 10.0.0 will be broken with the Linux kernel after
https://git.kernel.org/bpf/bpf-next/c/af73d78bd384aa9b8789aa6e7ddbb165f971276f
(x86_64 defconfig specifically), which will be in 5.7-rc1.

Can we please have 6c73246179376442705b3a545f4e1f1478777a04 merged into LLVM
10.0.1, where I have verified that it builds, fixes the issue, and passes the
test it added?


Referenced Bugs:

https://bugs.llvm.org/show_bug.cgi?id=45309
[Bug 45309] [meta] 10.0.1 Release Blockers
-- 
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs

[llvm-bugs] Issue 21539 in oss-fuzz: llvm:clang-fuzzer: Stack-overflow in clang::Lexer::Lex

2020-03-31 Thread ClusterFuzz-External via monorail via llvm-bugs 
Status: New
Owner: 
CC: k...@google.com, masc...@google.com, jdevlieg...@apple.com, 
igm...@gmail.com, d...@google.com, mit...@google.com, bigchees...@gmail.com, 
eney...@google.com, llvm-b...@lists.llvm.org, j...@chromium.org, 
v...@apple.com, mitchphi...@outlook.com, xpl...@gmail.com, akils...@apple.com 
Labels: ClusterFuzz Stability-Memory-AddressSanitizer Reproducible 
Engine-libfuzzer OS-Linux Proj-llvm Reported-2020-04-01
Type: Bug

New issue 21539 by ClusterFuzz-External: llvm:clang-fuzzer: Stack-overflow in 
clang::Lexer::Lex
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=21539

Detailed Report: https://oss-fuzz.com/testcase?key=5157608832106496

Project: llvm
Fuzzing Engine: libFuzzer
Fuzz Target: clang-fuzzer
Job Type: libfuzzer_asan_llvm
Platform Id: linux

Crash Type: Stack-overflow
Crash Address: 0x7ffd22b06a88
Crash State:
  clang::Lexer::Lex
  clang::Preprocessor::Lex
  clang::Parser::ParseBlockLiteralExpression
  
Sanitizer: address (ASAN)

Crash Revision: 
https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&revision=202003310247

Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5157608832106496

Issue filed automatically.

See https://google.github.io/oss-fuzz/advanced-topics/reproducing for 
instructions to reproduce this bug locally.
When you fix this bug, please
  * mention the fix revision(s).
  * state whether the bug was a short-lived regression or an old bug in any 
stable releases.
  * add any other useful information.
This information can help downstream consumers.

If you need to contact the OSS-Fuzz team with a question, concern, or any other 
feedback, please file an issue at https://github.com/google/oss-fuzz/issues. 
Comments on individual Monorail issues are not monitored.

-- 
You received this message because:
  1. You were specifically CC'd on the issue

You may adjust your notification preferences at:
https://bugs.chromium.org/hosting/settings

Reply to this email to add a comment.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs

[llvm-bugs] Issue 21540 in oss-fuzz: llvm:clang-fuzzer: Stack-overflow in llvm::detail::IEEEFloat::IEEEFloat

2020-03-31 Thread ClusterFuzz-External via monorail via llvm-bugs 
Status: New
Owner: 
CC: k...@google.com, masc...@google.com, jdevlieg...@apple.com, 
igm...@gmail.com, d...@google.com, mit...@google.com, bigchees...@gmail.com, 
eney...@google.com, llvm-b...@lists.llvm.org, j...@chromium.org, 
v...@apple.com, mitchphi...@outlook.com, xpl...@gmail.com, akils...@apple.com 
Labels: ClusterFuzz Stability-Memory-AddressSanitizer Reproducible 
Engine-libfuzzer OS-Linux Proj-llvm Reported-2020-04-01
Type: Bug

New issue 21540 by ClusterFuzz-External: llvm:clang-fuzzer: Stack-overflow in 
llvm::detail::IEEEFloat::IEEEFloat
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=21540

Detailed Report: https://oss-fuzz.com/testcase?key=5358227245236224

Project: llvm
Fuzzing Engine: libFuzzer
Fuzz Target: clang-fuzzer
Job Type: libfuzzer_asan_llvm
Platform Id: linux

Crash Type: Stack-overflow
Crash Address: 0x74775ff8
Crash State:
  llvm::detail::IEEEFloat::IEEEFloat
  BuildFloatingLiteral
  clang::Sema::ActOnNumericConstant
  
Sanitizer: address (ASAN)

Regressed: 
https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=202003300253:202003310247

Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5358227245236224

Issue filed automatically.

See https://google.github.io/oss-fuzz/advanced-topics/reproducing for 
instructions to reproduce this bug locally.
When you fix this bug, please
  * mention the fix revision(s).
  * state whether the bug was a short-lived regression or an old bug in any 
stable releases.
  * add any other useful information.
This information can help downstream consumers.

If you need to contact the OSS-Fuzz team with a question, concern, or any other 
feedback, please file an issue at https://github.com/google/oss-fuzz/issues. 
Comments on individual Monorail issues are not monitored.

-- 
You received this message because:
  1. You were specifically CC'd on the issue

You may adjust your notification preferences at:
https://bugs.chromium.org/hosting/settings

Reply to this email to add a comment.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs

[llvm-bugs] [Bug 45380] New: Expression evaluation causes inferior crash on ARM32 remote target

2020-03-31 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=45380

Bug ID: 45380
   Summary: Expression evaluation causes inferior crash on ARM32
remote target
   Product: lldb
   Version: unspecified
  Hardware: PC
OS: Windows NT
Status: NEW
  Severity: enhancement
  Priority: P
 Component: All Bugs
  Assignee: lldb-...@lists.llvm.org
  Reporter: emrekultur...@google.com
CC: jdevliegh...@apple.com, llvm-bugs@lists.llvm.org

When debugging armeabi-v7a Android device, the call to process->CanJIT() at
UserExpression.cpp:190 eventually causes the inferior to crash:

190:  if (process == nullptr || !process->CanJIT())
191:execution_policy = eExecutionPolicyNever;

AFAIU, LLDB tries to allocate memory on the inferior by calling mmap().
However, this mmap() execution triggers:

Fatal signal 11 (SIGSEGV), code 2 (SEGV_ACCERR),
fault addr 0xadc42fe6 in tid 25574
(xample.app32bit), pid 25574 (xample.app32bit)

The 0xadc42fe6 address in this error message falls inside the `r--p` section of
the `app_process32` binary, and trying to execute (or write) to that location
would trigger such a crash. 



Repro Instructions:

1. Download Android Studio (3.5 through 4.1). (This is probably much easier
than manually setting up remote-android LLDB connections)
2. In Android Studio, create new project and select "Native C++ Activity" from
the wizard.
3. Set a breakpoint at native-lib.cpp:9
4. Modify app/build.gradle, and add the following:
   defaultConfig { ndk { abiFilters = ["armeabi-v7a"] } }
   so that you build 32-bit ARM only.
5. Hit Debug while targeting an ARM Android device (I tried only with 64-bit
devices).
6. When the breakpoint hits, open the LLDB console and type p hello to trigger
the crash.


How I debugged this issue so far:

// I'm on Windows 10 with Visual Studio
1. Build your own liblldb.dll with symbols
2. Put your DLL and symbols to $INSTALL\Android Studio 4.1 Canary
4\bin\lldb\bin while overwriting the existing liblldb.dll file there.
3. When the breakpoint hits, before you type (p hello) expression, attach to
the existing LLDBFrontend process (which had loaded liblldb.dll library).

-- 
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs

[llvm-bugs] [Bug 4068] [Meta] Compiling the Linux kernel with clang

2020-03-31 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=4068
Bug 4068 depends on bug 45297, which changed state.

Bug 45297 Summary: Crash when building Linux kernel's AMDGPU driver for 
powerpc64le
https://bugs.llvm.org/show_bug.cgi?id=45297

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

-- 
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs

[llvm-bugs] [Bug 45297] Crash when building Linux kernel's AMDGPU driver for powerpc64le

2020-03-31 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=45297

Kai Luo  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #7 from Kai Luo  ---
Fix landed https://reviews.llvm.org/rG8eb40e41f6ec99985a292e342ec303a0bd6f5f41

-- 
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs

[llvm-bugs] [Bug 45309] [meta] 10.0.1 Release Blockers

2020-03-31 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=45309
Bug 45309 depends on bug 45297, which changed state.

Bug 45297 Summary: Crash when building Linux kernel's AMDGPU driver for 
powerpc64le
https://bugs.llvm.org/show_bug.cgi?id=45297

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

-- 
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs

[llvm-bugs] [Bug 45381] New: Stack overflow with recursive linker script

2020-03-31 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=45381

Bug ID: 45381
   Summary: Stack overflow with recursive linker script
   Product: lld
   Version: unspecified
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P
 Component: All Bugs
  Assignee: unassignedb...@nondot.org
  Reporter: raul+l...@tambre.ee
CC: llvm-bugs@lists.llvm.org, smithp...@googlemail.com

script:

GROUP(script)

clang++ -fuse-ld=ld.lld script

  #5 0x00e8b646 llvm::sys::fs::openFileForRead(llvm::Twine const&,
int&, llvm::sys::fs::OpenFlags, llvm::SmallVectorImpl*)
/opt/llvm-project/llvm/lib/Support/Unix/Path.inc:984:7
  #6 0x00e8ead7 llvm::sys::fs::openNativeFileForRead(llvm::Twine
const&, llvm::sys::fs::OpenFlags, llvm::SmallVectorImpl*)
/opt/llvm-project/llvm/lib/Support/Unix/Path.inc:1021:24
  #7 0x00ed619a llvm::ErrorOr > >
getFileAux(llvm::Twine const&, long, unsigned long,
unsigned long, bool, bool)
/opt/llvm-project/llvm/lib/Support/MemoryBuffer.cpp:263:8
  #8 0x00ed60bd llvm::MemoryBuffer::getFile(llvm::Twine const&, long,
bool, bool) /opt/llvm-project/llvm/lib/Support/MemoryBuffer.cpp:247:10
  #9 0x01080be8 lld::elf::readFile(llvm::StringRef)
/opt/llvm-project/lld/ELF/InputFiles.cpp:113:25
 #10 0x0101bc99 lld::elf::LinkerDriver::addFile(llvm::StringRef, bool)
/opt/llvm-project/lld/ELF/Driver.cpp:194:15
 #11 0x011535c2 lld::elf::(anonymous
namespace)::ScriptParser::addFile(llvm::StringRef)
/opt/llvm-project/lld/ELF/ScriptParser.cpp:304:3
 #12 0x0115115f lld::elf::(anonymous
namespace)::ScriptParser::readInput()
/opt/llvm-project/lld/ELF/ScriptParser.cpp:363:3
 #13 0x01150dc7 lld::elf::(anonymous
namespace)::ScriptParser::readGroup()
/opt/llvm-project/lld/ELF/ScriptParser.cpp:339:3
 #14 0x0114ffb9 lld::elf::(anonymous
namespace)::ScriptParser::readLinkerScript()
/opt/llvm-project/lld/ELF/ScriptParser.cpp:240:5
 #15 0x0114fc2c lld::elf::readLinkerScript(llvm::MemoryBufferRef)
/opt/llvm-project/lld/ELF/ScriptParser.cpp:1592:3
 #16 0x0101bde5 lld::elf::LinkerDriver::addFile(llvm::StringRef, bool)
/opt/llvm-project/lld/ELF/Driver.cpp:206:5
 #17 0x011535c2 lld::elf::(anonymous
namespace)::ScriptParser::addFile(llvm::StringRef)
/opt/llvm-project/lld/ELF/ScriptParser.cpp:304:3
 #18 0x0115115f lld::elf::(anonymous
namespace)::ScriptParser::readInput()
/opt/llvm-project/lld/ELF/ScriptParser.cpp:363:3
 #19 0x01150dc7 lld::elf::(anonymous
namespace)::ScriptParser::readGroup()
/opt/llvm-project/lld/ELF/ScriptParser.cpp:339:3
 #20 0x0114ffb9 lld::elf::(anonymous
namespace)::ScriptParser::readLinkerScript()
/opt/llvm-project/lld/ELF/ScriptParser.cpp:240:5
[repeating]

-- 
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs