date:20170530

[llvm-bugs] [Bug 33242] New: Address Sanitizer (ASAN) flags incorrect heap-use-after-free on PowerPC

2017-05-30 Thread via llvm-bugs

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

Bug ID: 33242
   Summary: Address Sanitizer (ASAN) flags incorrect
heap-use-after-free on PowerPC
   Product: compiler-rt
   Version: 4.0
  Hardware: Other
OS: Linux
Status: NEW
  Severity: normal
  Priority: P
 Component: compiler-rt
  Assignee: unassignedb...@nondot.org
  Reporter: david.h...@mongodb.com
CC: llvm-bugs@lists.llvm.org

We are using ASAN builds within our testing infrastructure to find potential
errors. Recently we have upgraded to LLVM 4.0 on our PowerPC test machine and
have encountered the error below. The error is highly sporadic as we have only
reproduced it twice while attempting to get to the bottom of the error.

Most interesting is that the error stems from T52, which is working with a data
structure that would in no way be related to that seen in T2.

The data structure allocated/freed in T2 is a "WT_DICTIONARY" the item being
accessed (inline) on T52 would be a "WT_INSERT" allocated elsewhere. 

On its face, we suspect that the issue here could be error in accounting within
ASAN on PowerPC.

Error as Reported:

=
==40049==ERROR: AddressSanitizer: heap-use-after-free on address 0x0a1804122c18
at pc 0x1053ef84 bp 0x3fff7852b420 sp 0x3fff7852b440
READ of size 8 at 0x0a1804122c18 thread T52
#0 0x1053ef80 in __col_insert_search
/home/jenkins/jenkins/workspace/wiredtiger-test-format-stress-sanitizer-ppc/build_posix/../src/include/column.i:189:15
#1 0x1053c2b4 in __wt_col_search
/home/jenkins/jenkins/workspace/wiredtiger-test-format-stress-sanitizer-ppc/build_posix/../src/btree/col_srch.c:297:18
#2 0x106c8cbc in __cursor_col_search
/home/jenkins/jenkins/workspace/wiredtiger-test-format-stress-sanitizer-ppc/build_posix/../src/btree/bt_cursor.c:320:2
#3 0x106d12e0 in __btcur_update
/home/jenkins/jenkins/workspace/wiredtiger-test-format-stress-sanitizer-ppc/build_posix/../src/btree/bt_cursor.c:1066:3
#4 0x106d273c in __wt_btcur_update
/home/jenkins/jenkins/workspace/wiredtiger-test-format-stress-sanitizer-ppc/build_posix/../src/btree/bt_cursor.c:1167:10
#5 0x105a7e28 in __curfile_update
/home/jenkins/jenkins/workspace/wiredtiger-test-format-stress-sanitizer-ppc/build_posix/../src/cursor/cur_file.c:293:2
#6 0x10159e44 in col_update
/home/jenkins/jenkins/workspace/wiredtiger-test-format-stress-sanitizer-ppc/build_posix/test/format/../../../test/format/ops.c:1501:16
#7 0x101513ec in ops
/home/jenkins/jenkins/workspace/wiredtiger-test-format-stress-sanitizer-ppc/build_posix/test/format/../../../test/format/ops.c:781:11
#8 0x10107658 in __asan::AsanThread::ThreadStart(unsigned long,
__sanitizer::atomic_uintptr_t*)
/home/dhows/downloads/llvm/projects/compiler-rt/lib/asan/asan_thread.cc:256
#9 0x1003bec8 in asan_thread_start(void*)
/home/dhows/downloads/llvm/projects/compiler-rt/lib/asan/asan_interceptors.cc:296
#10 0x3fff84ca8940 in start_thread (/lib64/power8/libpthread.so.0+0x8940)
#11 0x3fff849f763c in __clone (/lib64/power8/libc.so.6+0x11763c)

0x0a1804122c18 is located 8 bytes inside of 24-byte region
[0x0a1804122c10,0x0a1804122c28)
freed by thread T2 here:
#0 0x100f30ac in __interceptor_cfree.localalias.0
/home/dhows/downloads/llvm/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:55
#1 0x1028ee18 in __wt_free_int
/home/jenkins/jenkins/workspace/wiredtiger-test-format-stress-sanitizer-ppc/build_posix/../src/os_common/os_alloc.c:311:2
#2 0x102f1018 in __rec_dictionary_free
/home/jenkins/jenkins/workspace/wiredtiger-test-format-stress-sanitizer-ppc/build_posix/../src/reconcile/rec_write.c:6510:3
#3 0x102e89c0 in __rec_destroy
/home/jenkins/jenkins/workspace/wiredtiger-test-format-stress-sanitizer-ppc/build_posix/../src/reconcile/rec_write.c:996:2
#4 0x102e304c in __rec_destroy_session
/home/jenkins/jenkins/workspace/wiredtiger-test-format-stress-sanitizer-ppc/build_posix/../src/reconcile/rec_write.c:1008:2
#5 0x102cfbf0 in __wt_reconcile
/home/jenkins/jenkins/workspace/wiredtiger-test-format-stress-sanitizer-ppc/build_posix/../src/reconcile/rec_write.c:499:3
#6 0x10218bc0 in __evict_review
/home/jenkins/jenkins/workspace/wiredtiger-test-format-stress-sanitizer-ppc/build_posix/../src/evict/evict_page.c:559:8
#7 0x102162b8 in __wt_evict
/home/jenkins/jenkins/workspace/wiredtiger-test-format-stress-sanitizer-ppc/build_posix/../src/evict/evict_page.c:149:2
#8 0x101fc504 in __evict_page
/home/jenkins/jenkins/workspace/wiredtiger-test-format-stress-sanitizer-ppc/build_posix/../src/evict/evict_lru.c:2168:2
#9 0x101f5ae8 in __evict_lru_pages
/home/jenkins/jenkins/workspace/wiredtiger-test-format-stress-sanitizer-ppc/build_posix/../src/evict/evict_lru.c:1160:14
#10 0x101f4d9c in __wt_evict_thread_run

[llvm-bugs] [Bug 33226] [coroutines] ICE "Pass 'Coroutine Elision' is not initialized" with -fcoroutines-ts -O0

2017-05-30 Thread via llvm-bugs

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

gornisha...@gmail.com changed:

   What|Removed |Added

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

--- Comment #7 from gornisha...@gmail.com ---
Fixed:

Differential Revision: https://reviews.llvm.org/D33701

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@304277
91177308-0d34-0410-b5e6-96231b3b80d8

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

[llvm-bugs] [Bug 33241] New: compiling chromium Segmentation fault

2017-05-30 Thread via llvm-bugs

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

Bug ID: 33241
   Summary: compiling chromium Segmentation fault
   Product: clang
   Version: unspecified
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P
 Component: -New Bugs
  Assignee: unassignedclangb...@nondot.org
  Reporter: tof...@protonmail.com
CC: llvm-bugs@lists.llvm.org

[user@SA src]$ ninja -C out/my_build chrome
ninja: Entering directory `out/my_build'
[17688/28773] CXX obj/v8/v8_base/wasm-compiler.o
FAILED: obj/v8/v8_base/wasm-compiler.o 
../../third_party/llvm-build/Release+Asserts/bin/clang++ -MMD -MF
obj/v8/v8_base/wasm-compiler.o.d -DV8_DEPRECATION_WARNINGS -DUSE_UDEV
-DUSE_AURA=1 -DUSE_PANGO=1 -DUSE_CAIRO=1 -DUSE_GLIB=1 -DUSE_NSS_CERTS=1
-DUSE_X11=1 -DDISABLE_NACL -DFULL_SAFE_BROWSING -DSAFE_BROWSING_CSD
-DSAFE_BROWSING_DB_LOCAL -DCHROMIUM_BUILD -DFIELDTRIAL_TESTING_ENABLED
-DCR_CLANG_REVISION=\"303910-1\" -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE
-D_LARGEFILE64_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS
-DCOMPONENT_BUILD -D_DEBUG -DDYNAMIC_ANNOTATIONS_ENABLED=1
-DWTF_USE_DYNAMIC_ANNOTATIONS=1 -D_GLIBCXX_DEBUG=1 -DBUILDING_V8_SHARED
-DENABLE_DISASSEMBLER -DOBJECT_PRINT -DVERIFY_HEAP -DV8_TRACE_MAPS
-DV8_ENABLE_CHECKS -DV8_INTL_SUPPORT -DENABLE_HANDLE_ZAPPING -DV8_USE_SNAPSHOT
-DV8_USE_EXTERNAL_STARTUP_DATA -DV8_TARGET_ARCH_X64 -DDEBUG
-DU_USING_ICU_NAMESPACE=0 -DU_ENABLE_DYLOAD=0
-DICU_UTIL_DATA_IMPL=ICU_UTIL_DATA_FILE -DUCHAR_TYPE=uint16_t
-DUSING_V8_BASE_SHARED -I../.. -Igen -I../../v8
-I../../third_party/icu/source/common -I../../third_party/icu/source/i18n
-I../../v8/include -fno-strict-aliasing --param=ssp-buffer-size=4
-fstack-protector -Wno-builtin-macro-redefined -D__DATE__= -D__TIME__=
-D__TIMESTAMP__= -funwind-tables -fPIC -pipe
-B../../third_party/binutils/Linux_x64/Release/bin -fcolor-diagnostics -m64
-march=x86-64 -pthread -Wall -Werror -Wextra -Wno-missing-field-initializers
-Wno-unused-parameter -Wno-c++11-narrowing -Wno-covered-switch-default
-Wno-unneeded-internal-declaration -Wno-inconsistent-missing-override
-Wno-undefined-var-template -Wno-nonportable-include-path
-Wno-address-of-packed-member -Wno-unused-lambda-capture
-Wno-user-defined-warnings -fno-omit-frame-pointer -g0
--sysroot=../../build/linux/debian_jessie_amd64-sysroot -fvisibility=hidden
-Xclang -load -Xclang
../../third_party/llvm-build/Release+Asserts/lib/libFindBadConstructs.so
-Xclang -add-plugin -Xclang find-bad-constructs -Xclang
-plugin-arg-find-bad-constructs -Xclang check-auto-raw-pointer -Xclang
-plugin-arg-find-bad-constructs -Xclang check-ipc -Wheader-hygiene
-Wstring-conversion -Wtautological-overlap-compare -Wsign-compare
-Winconsistent-missing-override -Wshorten-64-to-32 -O3 -fno-ident
-fdata-sections -ffunction-sections -Wno-undefined-bool-conversion
-Wno-tautological-undefined-compare -std=gnu++11 -fno-rtti -fno-exceptions
-fvisibility-inlines-hidden -c ../../v8/src/compiler/wasm-compiler.cc -o
obj/v8/v8_base/wasm-compiler.o
#0 0x01d11124
(/home/user/chromium/src/third_party/llvm-build/Release+Asserts/bin/clang+0x1d11124)
#1 0x01d11446
(/home/user/chromium/src/third_party/llvm-build/Release+Asserts/bin/clang+0x1d11446)
#2 0x7ffb4e5c3c30 __restore_rt (/lib64/libpthread.so.0+0x10c30)
#3 0x018c2b94 llvm::Use::getUser() const
(/home/user/chromium/src/third_party/llvm-build/Release+Asserts/bin/clang+0x18c2b94)
#4 0x014c3e78 llvm::isKnownNonNullAt(llvm::Value const*,
llvm::Instruction const*, llvm::DominatorTree const*)
(/home/user/chromium/src/third_party/llvm-build/Release+Asserts/bin/clang+0x14c3e78)
#5 0x019bda15
(/home/user/chromium/src/third_party/llvm-build/Release+Asserts/bin/clang+0x19bda15)
#6 0x019b2643
(/home/user/chromium/src/third_party/llvm-build/Release+Asserts/bin/clang+0x19b2643)
#7 0x0198f14b
(/home/user/chromium/src/third_party/llvm-build/Release+Asserts/bin/clang+0x198f14b)
#8 0x01990fed
(/home/user/chromium/src/third_party/llvm-build/Release+Asserts/bin/clang+0x1990fed)
#9 0x019915fc
llvm::InstructionCombiningPass::runOnFunction(llvm::Function&)
(/home/user/chromium/src/third_party/llvm-build/Release+Asserts/bin/clang+0x19915fc)
#10 0x0188adbf llvm::FPPassManager::runOnFunction(llvm::Function&)
(/home/user/chromium/src/third_party/llvm-build/Release+Asserts/bin/clang+0x188adbf)
#11 0x02728526
(/home/user/chromium/src/third_party/llvm-build/Release+Asserts/bin/clang+0x2728526)
#12 0x0188b515 llvm::legacy::PassManagerImpl::run(llvm::Module&)
(/home/user/chromium/src/third_party/llvm-build/Release+Asserts/bin/clang+0x188b515)
#13 0x01e9daeb clang::EmitBackendOutput(clang::DiagnosticsEngine&,
clang::HeaderSearchOptions const&, clang::CodeGenOptions const&,
clang::TargetOptions const&, clang::LangOptions const&, llvm::DataLayout
const&, llvm::Module*,

[llvm-bugs] [Bug 33240] New: Enhancement request: attribute((warn_untested_result))

2017-05-30 Thread via llvm-bugs

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

Bug ID: 33240
   Summary: Enhancement request:
__attribute__((warn_untested_result))
   Product: clang
   Version: unspecified
  Hardware: PC
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P
 Component: -New Bugs
  Assignee: unassignedclangb...@nondot.org
  Reporter: j...@perches.com
CC: llvm-bugs@lists.llvm.org

Duplicate request submitted to gcc

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

A possibly useful addition similar to:

__attribute__((warn_unused_result))

might be

__attribute__((warn_untested_result))

for things like allocation failures that
are not verified before use.

For instance:

void *malloc(size_t size);

could become

void * __attribute__((warn_untested_result)) malloc(size_t size)

so that

#include 

struct foo {
int bar;
};

struct foo *alloc_foo(void)
{
struct foo *baz = malloc(sizeof(struct foo));
baz->bar = 1;
return baz;
}

The compiler could emit a warning on the set
of baz->bar as an intermediate test of baz
is not performed before any use of baz.

struct foo *alloc_foo(void)
{
struct foo *baz = malloc(sizeof(struct foo));
if (baz) baz->bar = 1;
return baz;
}

This variant would not emit a warning.

Similarly, alloc_foo could use that new attribute.

Martin Sebor also mentioned that non-allocation
functions like fopen could also use this __attribute__
mechanism.

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

[llvm-bugs] [Bug 33239] New: SHN_ABS symbols cause --gc-sections to crash

2017-05-30 Thread via llvm-bugs

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

Bug ID: 33239
   Summary: SHN_ABS symbols cause --gc-sections to crash
   Product: lld
   Version: unspecified
  Hardware: PC
OS: All
Status: NEW
  Severity: enhancement
  Priority: P
 Component: ELF
  Assignee: unassignedb...@nondot.org
  Reporter: smee...@fb.com
CC: compn...@compnerd.org, gri...@accesssoftek.com,
llvm-bugs@lists.llvm.org, rafael.espind...@gmail.com,
r...@google.com

% touch empty.bin
% ld.lld -m elf_x86_64 -b binary --relocatable -o empty.o empty.bin
% ld.lld -shared --gc-sections -o libempty.so empty.o
ld.lld: ../../../include/llvm/Support/Casting.h:104: static bool
llvm::isa_impl_cl::doit(const From*) [with To =
lld::elf::InputSectionBase; From = lld::elf::SectionBase]: Assertion `Val &&
"isa<> used on a null pointer"' failed.

The assertion is triggered via the cast in [1]. The symbol for which it fails
is _binary_empty_bin_size, which is absolute and has a null Section.

I'm using the first ld.lld command because it was how I came across the issue;
I believe it would generalize to any SHN_ABS symbol, however. I'm not sure if
there are scenarios in which a non-absolute symbol would trigger the assertion.

[1]
https://reviews.llvm.org/diffusion/L/browse/lld/trunk/ELF/MarkLive.cpp;304274$223?color=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
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs

[llvm-bugs] [Bug 33185] SimplifyBinOp can make incorrect transformation in the presence of phi nodes

2017-05-30 Thread via llvm-bugs

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

Daniel Berlin  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

--- Comment #13 from Daniel Berlin  ---
r304272

(it actually turns out to be more closely related to whether we have to
recursively translate ops or not)

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

[llvm-bugs] [Bug 33238] New: Wrong isl ast schedule generated

2017-05-30 Thread via llvm-bugs

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

Bug ID: 33238
   Summary: Wrong isl ast schedule generated
   Product: Polly
   Version: unspecified
  Hardware: PC
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P
 Component: Other
  Assignee: polly-...@googlegroups.com
  Reporter: huih...@codeaurora.org
CC: llvm-bugs@lists.llvm.org

Created attachment 18547
  --> https://bugs.llvm.org/attachment.cgi?id=18547=edit
test input

Attaching the test.ll as test input

Run command "opt -polly-codegen -S test.ll -debug"

Polly produce the isl ast schedule of:

{
  if (p_0 >= 3) {
for (int c0 = 0; c0 < (p_0 + 2) / 4; c0 += 1) {
  Stmt0(c0);
  if (p_0 >= 4 * c0 + 3) {
Stmt2(c0);
if (p_0 >= 4 * c0 + 4) {
  Stmt4(c0);
  if (p_0 >= 4 * c0 + 5)
Stmt6(c0);
}
  }
}
if ((p_0 - 1) % 4 == 0) {
  Stmt7();
} else if (p_0 % 4 == 0) {
  Stmt5();
} else if ((p_0 + 1) % 4 == 0) {
  Stmt3();
}
  } else {
Stmt0(0);
  }
  Stmt1();
}

else
{  /* original code */ }

However, the correct schedule should be:

{
  if (p_0 >= 3) {
for (int c0 = 0; c0 < (p_0 + 2) / 4; c0 += 1) {
  Stmt0(c0);
  if (p_0 >= 4 * c0 + 3) {
Stmt2(c0);
if (p_0 >= 4 * c0 + 4) {
  Stmt4(c0);
  if (p_0 >= 4 * c0 + 5)
Stmt6(c0);
}
  }
}
if ((p_0 - 1) % 4 == 0) {
  Stmt7();
} else if (p_0 % 4 == 0) {
  Stmt5();
} else if ((p_0 + 1) % 4 == 0) {
  Stmt3();
}
  } else {
Stmt0(0);
  }
  if((n <= 2) || ((n - 2)%4 == 0))
Stmt1();
}

else
{  /* original code */ }

Notice that for Statement Stmt1(), Polly produce universe domain, Stmt1 is
being executed unconditionally. However, if going through the basic blocks of
the input test.ll file, Stmt1 will only be executed under condition "((n <= 2)
|| ((n - 2)%4 == 0))"

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

[llvm-bugs] [Bug 33237] New: clang-cl: Ignore or implement /diagnostics:caret, /Zc:ternary, and (on x64) /Gr and /Gz

2017-05-30 Thread via llvm-bugs

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

Bug ID: 33237
   Summary: clang-cl: Ignore or implement /diagnostics:caret,
/Zc:ternary, and (on x64) /Gr and /Gz
   Product: clang
   Version: 4.0
  Hardware: PC
OS: Windows NT
Status: NEW
  Severity: normal
  Priority: P
 Component: -New Bugs
  Assignee: unassignedclangb...@nondot.org
  Reporter: sfi...@hotmail.com
CC: llvm-bugs@lists.llvm.org

Created attachment 18546
  --> https://bugs.llvm.org/attachment.cgi?id=18546=edit
Hello World

This behavior isn't the end of the world, but it makes it harder to
simultaneously use cl.exe and clang-cl.exe for testing.

C:\Temp>type meow.cpp
#include 

int main() {
puts("Cute fluffy kittens!");
}

C:\Temp>cl
Microsoft (R) C/C++ Optimizing Compiler Version 19.11.25326 for x64
Copyright (C) Microsoft Corporation.  All rights reserved.

usage: cl [ option... ] filename... [ /link linkoption... ]

C:\Temp>cl /EHsc /nologo /W4 meow.cpp
meow.cpp

C:\Temp>cl /EHsc /nologo /W4 /diagnostics:caret meow.cpp
meow.cpp

C:\Temp>cl /EHsc /nologo /W4 /Zc:ternary meow.cpp
meow.cpp

C:\Temp>cl /EHsc /nologo /W4 /Gr meow.cpp
meow.cpp

C:\Temp>cl /EHsc /nologo /W4 /Gz meow.cpp
meow.cpp

C:\Temp>clang-cl -v
clang version 4.0.0 (tags/RELEASE_400/final)
Target: x86_64-pc-windows-msvc
Thread model: posix
InstalledDir: S:\WCFB01\vctools\NonShip\ClangLLVM\bin

C:\Temp>clang-cl /EHsc /nologo /W4 meow.cpp

C:\Temp>clang-cl /EHsc /nologo /W4 /diagnostics:caret meow.cpp
clang-cl.exe: error: no such file or directory: '/diagnostics:caret'

C:\Temp>clang-cl /EHsc /nologo /W4 /Zc:ternary meow.cpp
clang-cl.exe: warning: argument unused during compilation: '/Zc:ternary'
[-Wunused-command-line-argument]

C:\Temp>clang-cl /EHsc /nologo /W4 /Gr meow.cpp
error: invalid argument '-fdefault-calling-conv=' not allowed with
'x86_64-pc-windows-msvc19.11.25326'

C:\Temp>clang-cl /EHsc /nologo /W4 /Gz meow.cpp
error: invalid argument '-fdefault-calling-conv=' not allowed with
'x86_64-pc-windows-msvc19.11.25326'

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

[llvm-bugs] [Bug 32608] Post RA scheduler incorrectly renames callee saved register

2017-05-30 Thread via llvm-bugs

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

Carrot  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

--- Comment #1 from Carrot  ---
This is fixed by r304001.

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

[llvm-bugs] [Bug 33236] New: clang-cl emits bogus error: cannot decompose this type; 'std::tuple_size::value' is not a valid integral constant expression

2017-05-30 Thread via llvm-bugs

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

Bug ID: 33236
   Summary: clang-cl emits bogus error: cannot decompose this
type; 'std::tuple_size::value' is not a valid
integral constant expression
   Product: clang
   Version: 4.0
  Hardware: PC
OS: Windows NT
Status: NEW
  Severity: normal
  Priority: P
 Component: -New Bugs
  Assignee: unassignedclangb...@nondot.org
  Reporter: sfi...@hotmail.com
CC: llvm-bugs@lists.llvm.org

Created attachment 18545
  --> https://bugs.llvm.org/attachment.cgi?id=18545=edit
Self-contained test case

Note: This is using my implementation of LWG 2770 tuple_size SFINAE, which will
ship in VS 2017's first toolset update (aka "15.3").

C:\Temp>type meow.cpp
#include 
#include 

struct S {
int x;
};

int main() {
S s{99};
auto [m1] = s;
auto& [r1] = s;
assert(m1 == 99);
assert( == );

const S cs{1729};
auto [m2] = cs;
auto& [r2] = cs;
assert(m2 == 1729);
assert( == );
}

C:\Temp>cl
Microsoft (R) C/C++ Optimizing Compiler Version 19.11.25326 for x64
Copyright (C) Microsoft Corporation.  All rights reserved.

usage: cl [ option... ] filename... [ /link linkoption... ]

C:\Temp>cl /EHsc /nologo /W4 /std:c++latest meow.cpp && meow
meow.cpp

C:\Temp>clang-cl -v
clang version 4.0.0 (tags/RELEASE_400/final)
Target: x86_64-pc-windows-msvc
Thread model: posix
InstalledDir: S:\WCFB01\vctools\NonShip\ClangLLVM\bin

C:\Temp>clang-cl /EHsc /nologo /W4 /std:c++latest meow.cpp && meow
meow.cpp(17,11):  error: cannot decompose this type; 'std::tuple_size::value' is not a valid integral constant expression
auto& [r2] = cs;
  ^
1 error generated.

I believe that this is the same issue as what I reported to the reflectors on
April 3, 2017. C1XX has implemented my preferred resolution.

--
Subject: [isocpp-lib] New issue - Core and Library disagree on tuple_size
SFINAE (LWG 2770)

LWG 2770's resolution taught tuple_size to SFINAE. However, Core's wording for
structured bindings disagrees with what the Library provides.

N4659 23.5.3.6 [tuple.helper]/4: "template  class tuple_size;
template  class tuple_size; template  class
tuple_size; Let TS denote tuple_size of the cv-unqualified
type T. If the expression TS::value is well-formed when treated as an
unevaluated operand, then each of the three templates shall meet the
UnaryTypeTrait requirements (23.15.1) with a base characteristic of
integral_constant Otherwise, they shall have no member
value."

When the Library provides SFINAE, Meow is complete, it's just that
Meow::value or Meow::type is non-existent. This is the
long-standing practice followed by invoke_result, etc.

However, Core expects different behavior:

11.5 [dcl.struct.bind]/3: "Otherwise, if the qualified-id std::tuple_size
names a complete type, the expression std::tuple_size::value shall be a
well-formed integral constant expression and"

This wording was introduced in Issaquah as the resolution of GB 20 (thanks to
Casey for the programmer-archaeology). He found no discussion, just "ready for
vote on Friday".

I encountered this because I implemented tuple_size SFINAE with the traditional
approach (it is a complete class with no members), yet libc++ had a test
expecting tuple_size to be an incomplete class. I argue that the
Core wording should change - it should not inspect the completeness of
tuple_size, but should instead inspect the well-formedness of
tuple_size::value, which is what the Library is already doing when
implementing tuple_size.

Thanks,
STL

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

[llvm-bugs] [Bug 33235] New: clang-cl doesn't treat __declspec(nothrow) as noexcept; fails to compile

2017-05-30 Thread via llvm-bugs

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

Bug ID: 33235
   Summary: clang-cl doesn't treat __declspec(nothrow) as
noexcept; fails to compile
   Product: clang
   Version: 4.0
  Hardware: PC
OS: Windows NT
Status: NEW
  Severity: normal
  Priority: P
 Component: -New Bugs
  Assignee: unassignedclangb...@nondot.org
  Reporter: sfi...@hotmail.com
CC: llvm-bugs@lists.llvm.org

Created attachment 18543
  --> https://bugs.llvm.org/attachment.cgi?id=18543=edit
Self-contained test case

C:\Temp>type meow.cpp
struct Base {
__declspec(nothrow) Base() { }
};

struct Derived : Base {
Derived() noexcept = default;
};

int main() { }

C:\Temp>cl
Microsoft (R) C/C++ Optimizing Compiler Version 19.11.25326 for x64
Copyright (C) Microsoft Corporation.  All rights reserved.

usage: cl [ option... ] filename... [ /link linkoption... ]

C:\Temp>cl /EHsc /nologo /W4 /std:c++latest meow.cpp
meow.cpp

C:\Temp>clang-cl -v
clang version 4.0.0 (tags/RELEASE_400/final)
Target: x86_64-pc-windows-msvc
Thread model: posix
InstalledDir: S:\WCFB01\vctools\NonShip\ClangLLVM\bin

C:\Temp>clang-cl /EHsc /nologo /W4 /std:c++latest meow.cpp
meow.cpp(6,5):  error: exception specification of explicitly defaulted default
constructor does not match the calculated one
Derived() noexcept = default;
^
1 error generated.

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

[llvm-bugs] [Bug 33234] New: LLVM misses loadpre opportunities

2017-05-30 Thread via llvm-bugs

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

Bug ID: 33234
   Summary: LLVM misses loadpre opportunities
   Product: clang
   Version: trunk
  Hardware: PC
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P
 Component: LLVM Codegen
  Assignee: unassignedclangb...@nondot.org
  Reporter: daniel...@gmail.com
CC: llvm-bugs@lists.llvm.org

#cat t.cc
void foo(int *p, int t, int *a, int *b, int *c) {
  for (int i = 0; i < t; i++) {
if (a[i]) {
  *p += b[i];
} else {
  *p *= c[i];
}
  }
}
#clang -O2 -S t.cc -fno-unroll-loops
testl   %esi, %esi
jle .LBB0_6
# BB#1:
movl%esi, %eax
.p2align4, 0x90
.LBB0_2:# =>This Inner Loop Header: Depth=1
cmpl$0, (%rdx)
je  .LBB0_4
# BB#3: #   in Loop: Header=BB0_2 Depth=1
movl(%rdi), %esi
addl(%rcx), %esi
jmp .LBB0_5
.p2align4, 0x90
.LBB0_4:#   in Loop: Header=BB0_2 Depth=1
movl(%rdi), %esi
imull   (%r8), %esi
.LBB0_5:#   in Loop: Header=BB0_2 Depth=1
movl%esi, (%rdi)
addq$4, %rdx
addq$4, %rcx
addq$4, %r8
decq%rax
jne .LBB0_2
.LBB0_6:
retq

#gcc -O2 -S t.cc -fno-unroll-loops
testl   %esi, %esi
jle .L1
movl(%rdi), %r9d
xorl%eax, %eax
jmp .L5
.p2align 4,,10
.p2align 3
.L9:
addl(%rcx,%rax,4), %r9d
addq$1, %rax
movl%r9d, (%rdi)
cmpl%eax, %esi
jle .L1
.L5:
movl(%rdx,%rax,4), %r10d
testl   %r10d, %r10d
jne .L9
imull   (%r8,%rax,4), %r9d
addq$1, %rax
movl%r9d, (%rdi)
cmpl%eax, %esi
jg  .L5
.L1:
rep
ret

For the gcc version, there are only 2 loads + 1 store each iteration. For llvm
version, there are 3 loads + 1 store each iteration.

The problem is that llvm failed to move the load of *p outside of the loop.

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

[llvm-bugs] [Bug 33233] New: [x86] Failing to tail-call memcpy and memmove due to extern C

2017-05-30 Thread via llvm-bugs

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

Bug ID: 33233
   Summary: [x86] Failing to tail-call memcpy and memmove due to
extern C
   Product: new-bugs
   Version: 4.0
  Hardware: PC
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P
 Component: new bugs
  Assignee: unassignedb...@nondot.org
  Reporter: h...@chromium.org
CC: llvm-bugs@lists.llvm.org
Blocks: 26299

For the following code, we're failing to generate tail calls:


#include 

void* libc_memcpy(void* dest, const void* src, size_t n) {
  return memcpy(dest, src, n);
}

void* libc_memmove(void* dest, const void* src, size_t n) {
  return memmove(dest, src, n);
}

$ bin/clang -target i686-unknown-linux-gnu -S -O3 -o - /tmp/a.cc
.text
.file   "/tmp/a.cc"
.globl  _Z11libc_memcpyPvPKvj   # -- Begin function
_Z11libc_memcpyPvPKvj
.p2align4, 0x90
.type   _Z11libc_memcpyPvPKvj,@function
_Z11libc_memcpyPvPKvj:  # @_Z11libc_memcpyPvPKvj
# BB#0: # %entry
pushl   %esi
subl$8, %esp
movl16(%esp), %esi
subl$4, %esp
pushl   28(%esp)
pushl   28(%esp)
pushl   %esi
calll   memcpy
addl$16, %esp
movl%esi, %eax
addl$8, %esp
popl%esi
retl
[snip]


Pretty horrible. Without the header:

#include 
extern "C" {
void* memcpy(void* dest, const void* src, size_t n);
void* memmove(void* dest, const void* src, size_t n);
}

void* libc_memcpy(void* dest, const void* src, size_t n) {
  return memcpy(dest, src, n);
}

void* libc_memmove(void* dest, const void* src, size_t n) {
  return memmove(dest, src, n);
}

Same thing.



But, if I remove the extern "C":

#include 
void* memcpy(void* dest, const void* src, size_t n);
void* memmove(void* dest, const void* src, size_t n);

void* libc_memcpy(void* dest, const void* src, size_t n) {
  return memcpy(dest, src, n);
}

void* libc_memmove(void* dest, const void* src, size_t n) {
  return memmove(dest, src, n);
}

$ bin/clang -target i686-unknown-linux-gnu -S -O3 -o - /tmp/a.cc
.text
.file   "/tmp/a.cc"
.globl  _Z11libc_memcpyPvPKvj   # -- Begin function
_Z11libc_memcpyPvPKvj
.p2align4, 0x90
.type   _Z11libc_memcpyPvPKvj,@function
_Z11libc_memcpyPvPKvj:  # @_Z11libc_memcpyPvPKvj
.cfi_startproc
# BB#0: # %entry
jmp _Z6memcpyPvPKvj # TAILCALL
.Lfunc_end0:
[snip]

Beautiful!

Why does extern "C" matter here?


Referenced Bugs:

https://bugs.llvm.org/show_bug.cgi?id=26299
[Bug 26299] [meta][X86] Size optimization opportunities (in particular for
32-bit Chromium on Windows)
-- 
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs

[llvm-bugs] [Bug 33232] New: Clang should report that char[] is NOT trivially destructible

2017-05-30 Thread via llvm-bugs

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

Bug ID: 33232
   Summary: Clang should report that char[] is NOT trivially
destructible
   Product: clang
   Version: 4.0
  Hardware: PC
OS: Windows NT
Status: NEW
  Severity: normal
  Priority: P
 Component: -New Bugs
  Assignee: unassignedclangb...@nondot.org
  Reporter: sfi...@hotmail.com
CC: llvm-bugs@lists.llvm.org

Created attachment 18542
  --> https://bugs.llvm.org/attachment.cgi?id=18542=edit
Self-contained test case

For historical (TR1-era) reasons, MSVC's STL implements
std::is_trivially_destructible with __has_trivial_destructor(). We do so
directly, with no additional logic, so we expect this builtin to follow the
Standard's specification exactly. C1XX provides such behavior, but Clang
doesn't.

If it were absolutely necessary, we could change MSVC's STL to implement
std::is_trivially_destructible with an __is_trivially_destructible builtin, but
then Clang would have to implement that - and it would be a headache for other
reasons.

C:\Temp>type meow.cpp
/***
N4659 23.15.4.3 [meta.unary.prop]:

Template: template  struct is_destructible;
Condition: Either T is a reference type, or T is a complete object type for
which the expression
declval().~U() is well-formed when treated as an unevaluated operand
(Clause 8),
where U is remove_all_extents.
Preconditions: T shall be a complete type, cv void, or an array of unknown
bound.

Template: template  struct is_trivially_destructible;
Condition: is_destructible_v is true and the indicated destructor is known
to be trivial.
Preconditions: T shall be a complete type, cv void, or an array of unknown
bound.

Template: template  struct is_nothrow_destructible;
Condition: is_destructible_v is true and the indicated destructor is known
not to throw any exceptions (8.3.7).
Preconditions: T shall be a complete type, cv void, or an array of unknown
bound.
***/

template  struct is_destructible {
static constexpr bool value = __is_destructible(T);
};

template  struct is_trivially_destructible {
static constexpr bool value = __has_trivial_destructor(T);
};

template  struct is_nothrow_destructible {
static constexpr bool value = __is_nothrow_destructible(T);
};

int main() {
static_assert(!is_destructible::value, "BOOM");
static_assert(!is_destructible::value, "BOOM");
static_assert(!is_destructible::value, "BOOM");
static_assert(!is_destructible::value, "BOOM");

static_assert(!is_trivially_destructible::value, "BOOM");
static_assert(!is_trivially_destructible::value, "BOOM");
static_assert(!is_trivially_destructible::value, "BOOM");
static_assert(!is_trivially_destructible::value,
"BOOM");

static_assert(!is_nothrow_destructible::value, "BOOM");
static_assert(!is_nothrow_destructible::value, "BOOM");
static_assert(!is_nothrow_destructible::value, "BOOM");
static_assert(!is_nothrow_destructible::value,
"BOOM");
}

C:\Temp>cl
Microsoft (R) C/C++ Optimizing Compiler Version 19.11.25326 for x64
Copyright (C) Microsoft Corporation.  All rights reserved.

usage: cl [ option... ] filename... [ /link linkoption... ]

C:\Temp>cl /EHsc /nologo /W4 meow.cpp
meow.cpp

C:\Temp>clang-cl -v
clang version 4.0.0 (tags/RELEASE_400/final)
Target: x86_64-pc-windows-msvc
Thread model: posix
InstalledDir: S:\WCFB01\vctools\NonShip\ClangLLVM\bin

C:\Temp>clang-cl /EHsc /nologo /W4 meow.cpp
meow.cpp(37,5):  error: static_assert failed "BOOM"
static_assert(!is_trivially_destructible::value, "BOOM");
^ ~
meow.cpp(38,5):  error: static_assert failed "BOOM"
static_assert(!is_trivially_destructible::value, "BOOM");
^ ~~~
meow.cpp(39,5):  error: static_assert failed "BOOM"
static_assert(!is_trivially_destructible::value, "BOOM");
^ ~~
meow.cpp(40,5):  error: static_assert failed "BOOM"
static_assert(!is_trivially_destructible::value,
"BOOM");
^ 
4 errors generated.

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

[llvm-bugs] [Bug 33231] New: poor handling of io errors?

2017-05-30 Thread via llvm-bugs

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

Bug ID: 33231
   Summary: poor handling of io errors?
   Product: lld
   Version: unspecified
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P
 Component: All Bugs
  Assignee: unassignedb...@nondot.org
  Reporter: matthias.krue...@famsik.de
CC: llvm-bugs@lists.llvm.org

lld @ 3710f10def28ec96b20b86dea048f9f11260734e / 
git-svn-id: https://llvm.org/svn/llvm-project/lld/trunk@304206
91177308-0d34-0410-b5e6-96231b3b80d8

I was doing a 2 stage (first stage optimized for performance, seconds stage:)

cmake ../llvm -G "Ninja" \
-DCMAKE_BUILD_TYPE="Debug" \
-DLLVM_BINUTILS_INCDIR=/usr/include \
-DCMAKE_C_FLAGS="-march=native -Og  -g3" \
-DCMAKE_CXX_FLAGS="-march=native -Og  -g3" \
-DLLVM_OPTIMIZED_TABLEGEN=1 \
-DCMAKE_AR="${rootDir}/stage_1/build/bin/llvm-ar" \
-DCMAKE_RANLIB="${rootDir}/stage_1/build/bin/llvm-ranlib" \
-DLLVM_USE_LINKER="${rootDir}/stage_1/build/bin/ld.lld"  \
-DLLVM_USE_SANITIZER="Address;Undefined" \
-DLLVM_PARALLEL_LINK_JOBS=1 \
-DLLVM_ENABLE_EXPENSIVE_CHECKS=1 \

build.
Everything went well until it came to linking the clang-5.0 binary.
After approximately one hour and 30 minutes, lld was still hogging disk IO
seemingly, (most of the time, there were around 10-20 megabyte/s read and a
fews kilobyte/s write here and there) and I killed the process.
There was close to no cpu consumption by lld and the clang binary was staying
at around 1.2 gigabyte of size.

It looked like lld hung. Unfortunately I killed it and didn't think about
attaching gdb. :(

Later I discovered that SMART disk monitoring threw some errors:
May 30 22:25:56 t420 smartd[1277]: Device: /dev/sda [SAT], 32 Currently
unreadable (pending) sectors
May 30 22:25:56 t420 smartd[1277]: Device: /dev/sda [SAT], 32 Offline
uncorrectable sectors

I wonder if lld hung because of these disk errors.

Does lld handle such errors gracefully?

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

[llvm-bugs] [Bug 33230] New: Clang on Windows should define __STDCPP_THREADS__ to be 1

2017-05-30 Thread via llvm-bugs

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

Bug ID: 33230
   Summary: Clang on Windows should define __STDCPP_THREADS__ to
be 1
   Product: clang
   Version: 4.0
  Hardware: PC
OS: Windows NT
Status: NEW
  Severity: normal
  Priority: P
 Component: -New Bugs
  Assignee: unassignedclangb...@nondot.org
  Reporter: sfi...@hotmail.com
CC: llvm-bugs@lists.llvm.org

Created attachment 18541
  --> https://bugs.llvm.org/attachment.cgi?id=18541=edit
Self-contained test case

C:\Temp>type meow.cpp
/***
N4659 19.8 [cpp.predefined]/2:
"The following macro names are conditionally defined by the implementation:
[...]
__STDCPP_THREADS__
Defined, and has the value integer literal 1, if and only if
a program can have more than one thread of execution (4.7)."
***/

#ifdef __STDCPP_THREADS__
#if __STDCPP_THREADS__ == 1
#include 
int main() { puts("Success!"); }
#else
#error WOOF
#endif
#else
#error BOOM
#endif

C:\Temp>cl
Microsoft (R) C/C++ Optimizing Compiler Version 19.11.25326 for x64
Copyright (C) Microsoft Corporation.  All rights reserved.

usage: cl [ option... ] filename... [ /link linkoption... ]

C:\Temp>cl /EHsc /nologo /W4 meow.cpp && meow
meow.cpp
Success!

C:\Temp>clang-cl -v
clang version 4.0.0 (tags/RELEASE_400/final)
Target: x86_64-pc-windows-msvc
Thread model: posix
InstalledDir: S:\WCFB01\vctools\NonShip\ClangLLVM\bin

C:\Temp>clang-cl /EHsc /nologo /W4 meow.cpp && meow
meow.cpp(17,6):  error: BOOM
#error BOOM
 ^
1 error generated.

C:\Temp>clang-cl /EHsc /nologo /W4 /std:c++latest meow.cpp && meow
meow.cpp(17,6):  error: BOOM
#error BOOM
 ^
1 error generated.

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

[llvm-bugs] [Bug 33229] New: llvm.addcarry is incorrectly lowered

2017-05-30 Thread via llvm-bugs

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

Bug ID: 33229
   Summary: llvm.addcarry is incorrectly lowered
   Product: libraries
   Version: trunk
  Hardware: PC
OS: All
Status: NEW
  Severity: enhancement
  Priority: P
 Component: Common Code Generator Code
  Assignee: unassignedb...@nondot.org
  Reporter: dav...@freebsd.org
CC: deadal...@gmail.com, fil...@gmail.com,
llvm-bugs@lists.llvm.org, llvm-...@redking.me.uk,
simon.f.whitta...@gmail.com,
warren_ris...@playstation.sony.com

Based on a report from Warren Ristow:

target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-unknown-linux-gnu"

define i32 @tinkywinky() {
entry:
  %0 = tail call i8 @llvm.x86.addcarry.u64(i8 0, i64 0, i64 0, i8* null)
  ret i32 0
}

declare i8 @llvm.x86.addcarry.u64(i8, i64, i64, i8*)


$ ./llc carry.ll
Value type is non-standard value, Other.
UNREACHABLE executed at ../include/llvm/CodeGen/MachineValueType.h:623!
#0 0x01dbc95a llvm::sys::PrintStackTrace(llvm::raw_ostream&)
(./llc+0x1dbc95a)
#1 0x01dba74e llvm::sys::RunSignalHandlers() (./llc+0x1dba74e)
#2 0x01dba89c SignalHandler(int) (./llc+0x1dba89c)
#3 0x7f2f9be1ec30 __restore_rt (/lib64/libpthread.so.0+0x10c30)
#4 0x7f2f9a98a765 __GI_raise (/lib64/libc.so.6+0x34765)
#5 0x7f2f9a98c36a __GI_abort (/lib64/libc.so.6+0x3636a)
#6 0x01d606aa (./llc+0x1d606aa)
#7 0x00813ce8 llvm::MVT::getSizeInBits() const (./llc+0x813ce8)
#8 0x01c61615 llvm::SelectionDAG::getConstant(unsigned long,
llvm::SDLoc const&, llvm::EVT, bool, bool) (./llc+0x1c61615)
#9 0x0120f858 llvm::X86TargetLowering::PerformDAGCombine(llvm::SDNode*,
llvm::TargetLowering::DAGCombinerInfo&) const (./llc+0x120f858)
#10 0x01ba7d69 (anonymous
namespace)::DAGCombiner::combine(llvm::SDNode*) (./llc+0x1ba7d69)
#11 0x01ba9560 (anonymous
namespace)::DAGCombiner::Run(llvm::CombineLevel) (./llc+0x1ba9560)
#12 0x01bab9ac llvm::SelectionDAG::Combine(llvm::CombineLevel,
llvm::AAResults*, llvm::CodeGenOpt::Level) (./llc+0x1bab9ac)
#13 0x01c7f1aa llvm::SelectionDAGISel::CodeGenAndEmitDAG()
(./llc+0x1c7f1aa)
#14 0x01c89821
llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&)
(./llc+0x1c89821)
#15 0x01c8b810
llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) [clone
.part.805] (./llc+0x1c8b810)
#16 0x0115f624 (anonymous
namespace)::X86DAGToDAGISel::runOnMachineFunction(llvm::MachineFunction&)
(./llc+0x115f624)
#17 0x015b3705
llvm::MachineFunctionPass::runOnFunction(llvm::Function&) (./llc+0x15b3705)
#18 0x0189e073 llvm::FPPassManager::runOnFunction(llvm::Function&)
(./llc+0x189e073)
#19 0x0189e134 llvm::FPPassManager::runOnModule(llvm::Module&)
(./llc+0x189e134)
#20 0x0189eda1 llvm::legacy::PassManagerImpl::run(llvm::Module&)
(./llc+0x189eda1)
#21 0x007ce8b5 compileModule(char**, llvm::LLVMContext&)
(./llc+0x7ce8b5)
#22 0x0075fd58 main (./llc+0x75fd58)
#23 0x7f2f9a976731 __libc_start_main (/lib64/libc.so.6+0x20731)
#24 0x007c20e9 _start (./llc+0x7c20e9)
Stack dump:
0.  Program arguments: ./llc carry.ll
1.  Running pass 'Function Pass Manager' on module 'carry.ll'.
2.  Running pass 'X86 DAG->DAG Instruction Selection' on function
'@tinkywinky'

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

[llvm-bugs] [Bug 33170] Merge r298179 into the 4.0 branch : Make library calls sensitive to regparm module flag (Fixes PR3997).

2017-05-30 Thread via llvm-bugs

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

Tom Stellard  changed:

   What|Removed |Added

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

--- Comment #4 from Tom Stellard  ---
Merged: r304242

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

[llvm-bugs] [Bug 32061] [meta] 4.0.1 Release Blockers

2017-05-30 Thread via llvm-bugs

https://bugs.llvm.org/show_bug.cgi?id=32061
Bug 32061 depends on bug 33170, which changed state.

Bug 33170 Summary: Merge r298179 into the 4.0 branch : Make library calls 
sensitive to regparm module flag (Fixes PR3997).
https://bugs.llvm.org/show_bug.cgi?id=33170

   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
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs

[llvm-bugs] [Bug 27307] clang-cl rejects -fno-delayed-template-parsing

2017-05-30 Thread via llvm-bugs

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

Stephan T. Lavavej  changed:

   What|Removed |Added

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

--- Comment #1 from Stephan T. Lavavej  ---
Works in Clang/LLVM 4.0:

C:\Temp>clang-cl /EHsc /nologo /W4 -fno-ms-compatibility meow.cpp && meow
Microsoft one-phase!

C:\Temp>clang-cl /EHsc /nologo /W4 -fno-ms-compatibility
-fno-delayed-template-parsing meow.cpp && meow
Standard two-phase!

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

[llvm-bugs] [Bug 32061] [meta] 4.0.1 Release Blockers

2017-05-30 Thread via llvm-bugs

https://bugs.llvm.org/show_bug.cgi?id=32061
Bug 32061 depends on bug 33174, which changed state.

Bug 33174 Summary: Merge r298177 into the 4.0 branch : [X86] Add 
NumRegisterParameters Module Flag.
https://bugs.llvm.org/show_bug.cgi?id=33174

   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
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs

[llvm-bugs] [Bug 32797] Merge r293630 into the 4.0 branch : [cmake] Support running tests in stand-alone builds

2017-05-30 Thread via llvm-bugs

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

Tom Stellard  changed:

   What|Removed |Added

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

--- Comment #4 from Tom Stellard  ---
Merged: r304238

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

[llvm-bugs] [Bug 33174] Merge r298177 into the 4.0 branch : [X86] Add NumRegisterParameters Module Flag.

2017-05-30 Thread via llvm-bugs

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

Tom Stellard  changed:

   What|Removed |Added

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

--- Comment #4 from Tom Stellard  ---
Accidentally updated the wrong bug, r304238 is the merge commit from a
different bug.

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

[llvm-bugs] [Bug 32061] [meta] 4.0.1 Release Blockers

2017-05-30 Thread via llvm-bugs

https://bugs.llvm.org/show_bug.cgi?id=32061
Bug 32061 depends on bug 32797, which changed state.

Bug 32797 Summary: Merge r293630 into the 4.0 branch : [cmake] Support running 
tests in stand-alone builds
https://bugs.llvm.org/show_bug.cgi?id=32797

   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
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs

[llvm-bugs] [Bug 33174] Merge r298177 into the 4.0 branch : [X86] Add NumRegisterParameters Module Flag.

2017-05-30 Thread via llvm-bugs

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

Tom Stellard  changed:

   What|Removed |Added

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

--- Comment #3 from Tom Stellard  ---
Merged: r304238

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

[llvm-bugs] [Bug 32061] [meta] 4.0.1 Release Blockers

2017-05-30 Thread via llvm-bugs

https://bugs.llvm.org/show_bug.cgi?id=32061
Bug 32061 depends on bug 33174, which changed state.

Bug 33174 Summary: Merge r298177 into the 4.0 branch : [X86] Add 
NumRegisterParameters Module Flag.
https://bugs.llvm.org/show_bug.cgi?id=33174

   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
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs

[llvm-bugs] [Bug 33228] New: new llvm::sys::fs::is_local_impl(statvfs&)' is toxic to Solaris build

2017-05-30 Thread via llvm-bugs

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

Bug ID: 33228
   Summary: new llvm::sys::fs::is_local_impl(statvfs&)' is toxic
to Solaris build
   Product: libraries
   Version: trunk
  Hardware: Sun
OS: Solaris
Status: NEW
  Severity: normal
  Priority: P
 Component: Support Libraries
  Assignee: unassignedb...@nondot.org
  Reporter: fedor.serg...@oracle.com
CC: llvm-bugs@lists.llvm.org

After updating to the trunk from release_40 branch my x86-Solaris-11 build
starts failing:

=
[  0%] Built target LLVMDemangle
[  0%] Building CXX object lib/Support/CMakeFiles/LLVMSupport.dir/Path.cpp.o
In file included from /LLVM/llvm-50/llvm/lib/Support/Path.cpp:1220:0:
/LLVM/llvm-50/llvm/lib/Support/Unix/Path.inc: In function 'bool
llvm::sys::fs::is_local_impl(statvfs&)':
/LLVM/llvm-50/llvm/lib/Support/Unix/Path.inc:103:35: error: 'struct statvfs'
has no member named 'f_flags'
 #define STATVFS_F_FLAG(vfs) (vfs).f_flags
   ^
/LLVM/llvm-50/llvm/lib/Support/Unix/Path.inc:385:13: note: in expansion of
macro 'STATVFS_F_FLAG'
   return !!(STATVFS_F_FLAG(Vfs) & MNT_LOCAL);
 ^
/fsergeev/LLVM/llvm-50/llvm/lib/Support/Unix/Path.inc:385:35: error:
'MNT_LOCAL' was not declared in this scope
   return !!(STATVFS_F_FLAG(Vfs) & MNT_LOCAL);
   ^
gmake[2]: *** [lib/Support/CMakeFiles/LLVMSupport.dir/Path.cpp.o] Error 1
gmake[1]: *** [lib/Support/CMakeFiles/LLVMSupport.dir/all] Error 2
gmake: *** [all] Error 2
=

Obviously statvfs usage is not compatible with Solaris interfaces.

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

[llvm-bugs] [Bug 32146] Enable -verify-machineinstrs with EXPENSIVE_CHECKS

2017-05-30 Thread via llvm-bugs

https://bugs.llvm.org/show_bug.cgi?id=32146
Bug 32146 depends on bug 12416, which changed state.

Bug 12416 Summary: MachineInstr verifier fails
https://bugs.llvm.org/show_bug.cgi?id=12416

   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
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs

[llvm-bugs] [Bug 12416] MachineInstr verifier fails

2017-05-30 Thread via llvm-bugs

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

Matthias Braun  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED
 CC||ma...@braunis.de

--- Comment #3 from Matthias Braun  ---
I changed the machine verifier checks in 2015 to make it legal for a register
use to only have parts of its values live, so this shouldn't abort anymore.

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

[llvm-bugs] [Bug 33065] false(?) -Wsequence warning

2017-05-30 Thread via llvm-bugs

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

Stephen Hines  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |INVALID

--- Comment #10 from Stephen Hines  ---
Moving this back to Resolved/Invalid. Unfortunately, the C and C++ Standards
Committees don't always see eye-to-eye on every potential related issue. This
is one such example. I have no evidence that Clang is leveraging the ordering
of these arguments to do something different in C vs. C++ today, but that
doesn't prevent them from doing something like that in the future. The right
thing is to fix your code based on the warning, since the warning does complain
exactly about what the C standard requires here.

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

[llvm-bugs] [Bug 33227] New: Defect with llvm::reverse used in for loop with a comparison

2017-05-30 Thread via llvm-bugs

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

Bug ID: 33227
   Summary: Defect with llvm::reverse used in for loop with a
comparison
   Product: libraries
   Version: trunk
  Hardware: PC
OS: All
Status: NEW
  Severity: normal
  Priority: P
 Component: Support Libraries
  Assignee: unassignedb...@nondot.org
  Reporter: colse...@hotmail.com
CC: llvm-bugs@lists.llvm.org

Created attachment 18539
  --> https://bugs.llvm.org/attachment.cgi?id=18539=edit
Example

std::vector V(10);
for (unsigned I : Fwd ? V : llvm::reverse(V))
  llvm::errs() << I << "\n";

In this example compilation succeeds without even a warning but failure occurs
when Fwd is true.

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

[llvm-bugs] [Bug 33226] New: [coroutines] ICE "Pass 'Coroutine Elision' is not initialized" with -fcoroutines-ts -O0

2017-05-30 Thread via llvm-bugs

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

Bug ID: 33226
   Summary: [coroutines] ICE "Pass 'Coroutine Elision' is not
initialized" with -fcoroutines-ts -O0
   Product: clang
   Version: trunk
  Hardware: PC
OS: All
Status: NEW
  Severity: enhancement
  Priority: P
 Component: C++
  Assignee: unassignedclangb...@nondot.org
  Reporter: enieb...@boost.org
CC: dgre...@apple.com, llvm-bugs@lists.llvm.org

Repro steps (with trunk latest on a Mac):

> mkdir ~/llvm-build

> cd ~/llvm-build

# -DLLVM_TARGETS_TO_BUILD='X86' seems to matter here:
> cmake -DCMAKE_INSTALL_PREFIX:PATH=~/llvm-install 
> -DCMAKE_BUILD_TYPE:STRING=Release -DLLVM_TARGETS_TO_BUILD='X86' ~/llvm

> make && make install

# Any empty input file will do
> echo // comment > test.cpp

> ~/llvm-install/bin/clang++ -fcoroutines-ts -O0 -c test.cpp

Result:

eniebler-mbp:llvm-ninja eniebler$ ~/llvm-install/bin/clang++ -fcoroutines-ts
-O0 -c test.cpp
Pass 'Coroutine Elision' is not initialized.
Verify if there is a pass dependency cycle.
Required Passes:
0  clang-5.00x00010ac06808
llvm::sys::PrintStackTrace(llvm::raw_ostream&) + 40
1  clang-5.00x00010ac06e76 SignalHandler(int) + 342
2  libsystem_platform.dylib 0x7fffbca5eb3a _sigtramp + 26
3  clang-5.00x00010c8f3ba8 (anonymous
namespace)::DarwinX86AsmBackend::getCompactUnwindRegNum(unsigned int)
const::CU64BitRegs + 132176
4  clang-5.00x00010b432c54
addCoroutineOpt0Passes(llvm::PassManagerBuilder const&,
llvm::legacy::PassManagerBase&) + 52
5  clang-5.00x00010a82a573
llvm::PassManagerBuilder::addExtensionsToPM(llvm::PassManagerBuilder::ExtensionPointTy,
llvm::legacy::PassManagerBase&) const + 307
6  clang-5.00x00010a82b4a2
llvm::PassManagerBuilder::populateModulePassManager(llvm::legacy::PassManagerBase&)
+ 770
7  clang-5.00x00010adafc53
clang::EmitBackendOutput(clang::DiagnosticsEngine&, clang::HeaderSearchOptions
const&, clang::CodeGenOptions const&, clang::TargetOptions const&,
clang::LangOptions const&, llvm::DataLayout const&, llvm::Module*,
clang::BackendAction, std::__1::unique_ptr) + 13123
8  clang-5.00x00010af580c9
clang::BackendConsumer::HandleTranslationUnit(clang::ASTContext&) + 889
9  clang-5.00x00010b7e7405 clang::ParseAST(clang::Sema&,
bool, bool) + 469
10 clang-5.00x00010b1788a3 clang::FrontendAction::Execute()
+ 67
11 clang-5.00x00010b1366e8
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 1080
12 clang-5.00x00010b1bb1de
clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 5326
13 clang-5.00x00010a094cfc cc1_main(llvm::ArrayRef, char const*, void*) + 1196
14 clang-5.00x00010a093b60 main + 12096
15 libdyld.dylib0x7fffbc84f235 start + 1
Stack dump:
0.  Program arguments: /Users/eniebler/llvm-install/bin/clang-5.0 -cc1
-triple x86_64-apple-macosx10.12.0 -Wdeprecated-objc-isa-usage
-Werror=deprecated-objc-isa-usage -emit-obj -mrelax-all -disable-free
-disable-llvm-verifier -discard-value-names -main-file-name test.cpp
-mrelocation-model pic -pic-level 2 -mthread-model posix -mdisable-fp-elim
-masm-verbose -munwind-tables -target-cpu penryn -target-linker-version 274.1
-dwarf-column-info -debugger-tuning=lldb -coverage-notes-file
/Users/eniebler/llvm-ninja/test.gcno -resource-dir
/Users/eniebler/llvm-install/lib/clang/5.0.0 -stdlib=libc++ -O0
-fdeprecated-macro -fdebug-compilation-dir /Users/eniebler/llvm-ninja
-ferror-limit 19 -fmessage-length 247 -stack-protector 1 -fblocks
-fcoroutines-ts -fobjc-runtime=macosx-10.12.0 -fencode-extended-block-signature
-fcxx-exceptions -fexceptions -fmax-type-align=16 -fdiagnostics-show-option
-fcolor-diagnostics -o test.o -x c++ test.cpp
1.   parser at end of file
clang-5.0: error: unable to execute command: Segmentation fault: 11
clang-5.0: error: clang frontend command failed due to signal (use -v to see
invocation)
clang version 5.0.0 (http://llvm.org/git/clang.git
1c50ce32c7bb476416a210cfbcbb5e934c266538) (http://llvm.org/git/llvm.git
f0c3d71794d1695efe08bdf83c6b1824dcf07c80)
Target: x86_64-apple-darwin16.5.0
Thread model: posix
InstalledDir: /Users/eniebler/llvm-install/bin
clang-5.0: note: diagnostic msg: PLEASE submit a bug report to
http://llvm.org/bugs/ and include the crash backtrace, preprocessed source, and
associated run script.
clang-5.0: note: diagnostic msg:


PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
Preprocessed source(s) and associated run script(s) are located at:
clang-5.0: note: diagnostic msg:
/var/folders/0_/77jy5prn181b5wn2xzl1cbfc18wy7r/T/test-a028ed.cpp
clang-5.0: note:

[llvm-bugs] [Bug 33101] Merge r296485 into the 4.0 branch: Driver: Update devtoolset usage for RHEL

2017-05-30 Thread via llvm-bugs

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

Tom Stellard  changed:

   What|Removed |Added

 Resolution|--- |WONTFIX
 Status|NEW |RESOLVED

--- Comment #2 from Tom Stellard  ---
We did some more testing on this and we found a bug that requires an additional
patch to fix, so we'll leave this out of 4.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
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs

[llvm-bugs] [Bug 32061] [meta] 4.0.1 Release Blockers

2017-05-30 Thread via llvm-bugs

https://bugs.llvm.org/show_bug.cgi?id=32061
Bug 32061 depends on bug 33101, which changed state.

Bug 33101 Summary: Merge r296485 into the 4.0 branch: Driver: Update devtoolset 
usage for RHEL
https://bugs.llvm.org/show_bug.cgi?id=33101

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WONTFIX

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

[llvm-bugs] [Bug 32200] Failed test on 4.0 Release Candidate 4

2017-05-30 Thread via llvm-bugs

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

Tom Stellard  changed:

   What|Removed |Added

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

--- Comment #16 from Tom Stellard  ---
Merged: r304213

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

[llvm-bugs] [Bug 32061] [meta] 4.0.1 Release Blockers

2017-05-30 Thread via llvm-bugs

https://bugs.llvm.org/show_bug.cgi?id=32061
Bug 32061 depends on bug 32200, which changed state.

Bug 32200 Summary: Failed test on 4.0 Release Candidate 4
https://bugs.llvm.org/show_bug.cgi?id=32200

   What|Removed |Added

 Status|REOPENED|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
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs

[llvm-bugs] [Bug 33225] New: Lops with memcpy suffer from poor LSR treatment on SystemZ.

2017-05-30 Thread via llvm-bugs

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

Bug ID: 33225
   Summary: Lops with memcpy suffer from poor LSR treatment on
SystemZ.
   Product: libraries
   Version: trunk
  Hardware: PC
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P
 Component: Loop Optimizer
  Assignee: unassignedb...@nondot.org
  Reporter: pauls...@linux.vnet.ibm.com
CC: llvm-bugs@lists.llvm.org

Created attachment 18538
  --> https://bugs.llvm.org/attachment.cgi?id=18538=edit
reduced testcase

This is the same issue as with vector load / store: only a 12 bit displacement
is supported with MVC, which implements the memcpy.

I tried to extend LSR to treat this the same way as with a Load or Store, but
that does not work, since it seems that a memcpy Fixup does not get any Offset,
but it is rather the Formula (of type Basic) which has an UnfoldedOffset.

I tried then with

@@ -1290,6 +1290,11 @@ void Cost::RateFormula(const TargetTransformInfo ,
 if ((isa(Fixup.UserInst) || isa(Fixup.UserInst)) &&
 !TTI.isFoldableMemAccessOffset(Fixup.UserInst, Offset))
   NumBaseAdds++;
+
+if (Offset == 0 && F.UnfoldedOffset != 0 &&
+isa(Fixup.UserInst) &&
+!TTI.isFoldableMemAccessOffset(Fixup.UserInst, F.UnfoldedOffset))
+  NumBaseAdds++;

, but this did only handle a very few cases. It did add the right cost, but it
seemed that there was no other formula to be rated higher. 

It turns out that even though this was a fairly small single-block loop
containing basically 8 memcpy calls, the EstimateSearchSpaceComplexity() still
return a too high value, so the formulas with the foldable offsets
unfortunately got pruned.

The loop becomes:

.LBB0_2:# %for.body75
# =>This Inner Loop Header: Depth=1
lay%r3, -4096(%r1)
mvc0(48,%r1), 0(%r3)
lay%r3, -288(%r2)
mvc0(48,%r3), 0
lay%r3, -240(%r2)
mvc0(48,%r3), 0
lay%r3, -192(%r2)
mvc0(48,%r3), 0
lay%r3, -144(%r2)
mvc0(48,%r3), 0(%r1)
mvc0(48), 0
mvc0(48), 0
mvc0(48,%r2), 0
lay%r1, 8192(%r1)
la%r2, 384(%r2)
j.LBB0_2

with another heuristic for narrowing the search space (-lsr-exp-narrow), it
seems the better formula is still there:

.LBB0_2:# %for.body75
# =>This Inner Loop Header: Depth=1
lay%r3, -4096(%r2)
mvc0(48,%r1), 0(%r3)
mvc0(48,%r1), 0
mvc0(48,%r1), 0
mvc0(48,%r1), 0
mvc0(48,%r1), 0(%r2)
mvc0(48), 0
mvc0(48), 0
mvc0(48,%r1), 0
lay%r2, 8192(%r2)
la%r1, 384(%r1)
j.LBB0_2

This actually works even without my little patch per above. Comparing
-lsr-exp-narrow across SPEC, it increases the total number of load-adress
instructions (unfolded offsets), with or without my patch, so it does not seem
good to just switch generally.

Is there any possibility of squeezing in the offset heuristic somewhere in this
pruning process? Is there anything else here that I missed?

Run reduced test case with

llc -O3 -mtriple=s390x-linux-gnu -mcpu=z13 ./tc_mvcs.ll

llc -O3 -mtriple=s390x-linux-gnu -mcpu=z13 ./tc_mvcs.ll -lsr-exp-narrow

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

[llvm-bugs] [Bug 30384] r280609: Host.cpp fails to build using Xcode 4.6.3: use of undeclared identifier '__get_cpuid_max'

2017-05-30 Thread via llvm-bugs

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

Alina Sbirlea  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #6 from Alina Sbirlea  ---
The fix revision stayed in. Marking as 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
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs

[llvm-bugs] [Bug 33224] New: clang places implicitly declared C functions at compile unit scope

2017-05-30 Thread via llvm-bugs

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

Bug ID: 33224
   Summary: clang places implicitly declared C functions at
compile unit scope
   Product: clang
   Version: trunk
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P
 Component: Frontend
  Assignee: unassignedclangb...@nondot.org
  Reporter: momchil.veli...@arm.com
CC: llvm-bugs@lists.llvm.org

Created attachment 18537
  --> https://bugs.llvm.org/attachment.cgi?id=18537=edit
testcase

Compiling the following testcase with `clang -std=c90 -c x.c`

> int f() {
>g();
>return 0;
> }
> 
>  int (*p)() = g;

completes successfully.

The identifier `g` is not declared at the place, where it appears in the
context of the function call expression. In that case, the C90 Standard says
(6.3.3.2 Function calls):

> If the expression that precedes the parenthesized argument list in a 
> function
> call consists solely by an identifier, and if no declaration is visible 
> for this
> identifier, the identifier is implicitly declared as if, in the innermost 
> block
> containing the function call, the declaration
> 
> extern int identifier();
> 
> appeared.

Therefore, the above program should be equivalent to:

> int f() {
>extern int g();
>g();
>return 0;
> }
> 
>  int (*p)() = g;

for which clang terminates with an error. The C90 Standard (6.1.2.1 Scopes of
identifiers), says:

> If the declarator or type specifier that declared the identifier appears 
> inside a block [...],
> the identifier has block scope, which terminates at the } that closes the 
> associated block.

so, this should be the correct behavior in both testcases.

However, clang places the implicitly declared function at translation
unit scope, which causes the identifier to be visible in the initializer
in the original testcase, in effect accepting an invalid program.

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

[llvm-bugs] [Bug 33180] OpenCL r303986 broke all ARM bots

2017-05-30 Thread via llvm-bugs

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

Anastasia Stulova  changed:

   What|Removed |Added

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

--- Comment #2 from Anastasia Stulova  ---
Fixed by https://reviews.llvm.org/rL304191

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

[llvm-bugs] [Bug 33223] New: cxa_demangle failes for inherited constructors

2017-05-30 Thread via llvm-bugs

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

Bug ID: 33223
   Summary: cxa_demangle failes for inherited constructors
   Product: libc++abi
   Version: unspecified
  Hardware: PC
OS: All
Status: NEW
  Severity: enhancement
  Priority: P
 Component: All Bugs
  Assignee: unassignedb...@nondot.org
  Reporter: tbergham...@google.com
CC: llvm-bugs@lists.llvm.org, mclow.li...@gmail.com

libc++abi fails to demangle the mangled name generated by clang for an
inherited constructor.

Example name where cxa_demangle fails: _ZN5bCI25aEi

Source code for generating the mangled name:
class a {
 public:
  a(int);
};
class b : a {
  using a::a;
};
void c() { b(1); }

Clang version used to generate the name:
clang version 5.0.0 (trunk 303332) (llvm/trunk 303340)
Target: x86_64-unknown-linux-gnu
Thread model: posix

Additional context:
https://bugs.llvm.org/show_bug.cgi?id=33177
http://sourcerytools.com/pipermail/cxx-abi-dev/2016-May/002918.html

Open question: What should be the output of __cxa_demangle when demangling an
inherited constructor? What do people think about "b::b(int)" (hides
that it is an inherited constructor) or "b::a(int)" (hides that it is a
constructor) for the above case?

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

[llvm-bugs] [Bug 32496] Merge r294264 into the 4.0 branch : [LVI] Switch from BFS to DFS exploration order

2017-05-30 Thread via llvm-bugs

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

Tom Stellard  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #4 from Tom Stellard  ---
Based on code owner feedback, I think this is a little too risky to merge.

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

[llvm-bugs] [Bug 33154] inconsistent formatting of javascript function braces

2017-05-30 Thread via llvm-bugs

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

Martin Probst  changed:

   What|Removed |Added

 Resolution|--- |WONTFIX
 Status|NEW |RESOLVED

--- Comment #4 from Martin Probst  ---
I took a look. The problem is that detecting an automatic semicolon on "}
(ident|statement)" throws off the indentation counting.

I'll mark this as WONTFIX for now, it'd require substantial refactoring of how
clang-format handles indentation.

I'd recommend using a JS linter (jslint, tslint, ...) to detect missing semis,
and fixing them manually.

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

[llvm-bugs] [Bug 33221] New: [UBSAN] segfault with -fsanitize=undefined

2017-05-30 Thread via llvm-bugs

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

Bug ID: 33221
   Summary: [UBSAN] segfault with -fsanitize=undefined
   Product: compiler-rt
   Version: unspecified
  Hardware: PC
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P
 Component: compiler-rt
  Assignee: unassignedb...@nondot.org
  Reporter: d.khali...@partner.samsung.com
CC: llvm-bugs@lists.llvm.org

Created attachment 18534
  --> https://bugs.llvm.org/attachment.cgi?id=18534=edit
ubsan fix for vptr check

Hello everyone.

I have a situation when UBSAN got segfault.

Test case (that code actually close example of the code in package
groff-1.22.3.)

$cat test.cc

class Base {
public:
  Base *next;
  virtual void print() {}
};

class Derived : public Base {
public:
  void print() {}
};

enum { SIZE = 2 };

int main() {
  Derived *list = (Derived *)new char[SIZE * sizeof(Derived)];
  list->next = list + 1;
  return 0;
}

$clang++ -o test test.cc -fsanitize=undefined -fsanitize=address
$./test

And we will get following backtrace:

==3737==ERROR: AddressSanitizer: SEGV on unknown address 0x (pc
0x0051a9f2 bp 0x00531bf8 sp 0x7ffc38852540 T0)
==3737==The signal is caused by a READ memory access.
==3737==Hint: address points to the zero page.
#0 0x51a9f1 in getVtablePrefix
/llvm/projects/compiler-rt/lib/ubsan/ubsan_type_hash_itanium.cc:200
#1 0x51a9f1 in __ubsan::checkDynamicType(void*, void*, unsigned long)
/llvm/projects/compiler-rt/lib/ubsan/ubsan_type_hash_itanium.cc:223
#2 0x518942 in
HandleDynamicTypeCacheMiss(__ubsan::DynamicTypeCacheMissData*, unsigned long,
unsigned long, __ubsan::ReportOptions)
/llvm/projects/compiler-rt/lib/ubsan/ubsan_handlers_cxx.cc:37
#3 0x519232 in __ubsan_handle_dynamic_type_cache_miss
/llvm/projects/compiler-rt/lib/ubsan/ubsan_handlers_cxx.cc:87
#4 0x51addd in main (/test/ubsan/test+0x51addd)
#5 0x7ff8cad7ef44 in __libc_start_main
/build/eglibc-MjiXCM/eglibc-2.19/csu/libc-start.c:287
#6 0x41ac9b in _start (/test/ubsan/test+0x41ac9b)


As far as I understood vptr is initializing by constructor of the object. In
this code that doesn't happen, this code use operator new () of type char which
doesn't have default constructor. Standard says:
if default constructor is not specified
(7.3) no initialization is performed.
So, vptr could have a junk data, at the beginning of the object, which 
cause a segfault in function getVtablePrefix.

Should we check Vptr with 
if (!IsAccessibleMemoryRange((uptr)Vptr, sizeof(VtablePrefix)))
instead 
if (!Vptr)

I've attached patch for this issue.

Thanks.

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

[llvm-bugs] [Bug 33220] New: Exception handling bug with mingw-w64

2017-05-30 Thread via llvm-bugs

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

Bug ID: 33220
   Summary: Exception handling bug with mingw-w64
   Product: new-bugs
   Version: 4.0
  Hardware: PC
OS: other
Status: NEW
  Severity: enhancement
  Priority: P
 Component: new bugs
  Assignee: unassignedb...@nondot.org
  Reporter: svyatoslav.scherb...@jetbrains.com
CC: llvm-bugs@lists.llvm.org

Created attachment 18533
  --> https://bugs.llvm.org/attachment.cgi?id=18533=edit
test

$ cat bug.cpp

class Foo {
public:
~Foo() {}
};

void __attribute__((noinline)) bar() {
Foo foo;
throw 42;
}

int main() {
try {
bar();
} catch (int x) {
}
return 0;
}


The attached program doesn't run right if compiled by clang++ with '-O2' for
x86_64-w64-mingw32 (tested with mingw-w64 6.3.0).
The program abnormally terminates instead of catching the exception:

$ clang++ -O2 -target x86_64-w64-mingw32 bug.cpp && ./a.exe

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
terminate called after throwing an instance of 'int'


The bug seems to be triggered by the function 'bar' which has personality
function '__gxx_personality_seh0' specified but doesn't have any landingpad
after the optimization:

___
; Function Attrs: noinline noreturn uwtable
define void @_Z3barv() local_unnamed_addr #0 personality i8* bitcast (i32
(...)* @__gxx_personality_seh0 to i8*) {
entry:
  %exception = tail call i8* @__cxa_allocate_exception(i64 4) #3
  %0 = bitcast i8* %exception to i32*
  store i32 42, i32* %0, align 16, !tbaa !2
  tail call void @__cxa_throw(i8* %exception, i8* bitcast (i8** @_ZTIi to i8*),
i8* null) #4
  unreachable
}
___

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

[llvm-bugs] [Bug 33031] Cannot scavenge register without an emergency spill slot!

2017-05-30 Thread via llvm-bugs

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

kristof.be...@arm.com changed:

   What|Removed |Added

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

--- Comment #10 from kristof.be...@arm.com ---
Fixed in r304196.

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

[llvm-bugs] [Bug 33194] a heisenbug: clang crashes on valid code at -O3 with "-mllvm -enable-newgvn": Assertion `isa(V) && "This should not be used for MemoryAccesses"' failed

2017-05-30 Thread via llvm-bugs

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

Daniel Berlin  changed:

   What|Removed |Added

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

--- Comment #8 from Daniel Berlin  ---
r304194

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

47 matches

Mail list logo