[llvm-bugs] [Bug 35393] New: Windows clang-cl.exe: Unable to compile C++17 code

2017-11-23 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=35393

Bug ID: 35393
   Summary: Windows clang-cl.exe: Unable to compile C++17 code
   Product: clang
   Version: trunk
  Hardware: PC
OS: Windows NT
Status: NEW
  Severity: enhancement
  Priority: P
 Component: Driver
  Assignee: unassignedclangb...@nondot.org
  Reporter: registrira...@live.com
CC: llvm-bugs@lists.llvm.org

Compiling with /std:c++17 or -XClang -std=c++17

#include "stdafx.h"
#include 


int main()
{
std::string_view myOne = "Haha";

std::printf ("%s", myOne.data ());

return 0;
}

fails as the toolset is not using:

C:\\Program Files (x86)\\Microsoft Visual
Studio\\Preview\\Community\\VC\\Tools\\MSVC\\14.12.25827\\include"

but 

C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include

-- 
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 35395] New: [Modules TS] definition of X must be imported from module 'Y.' before it is required

2017-11-23 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=35395

Bug ID: 35395
   Summary: [Modules TS] definition of X must be imported from
module 'Y.' before it is required
   Product: clang
   Version: trunk
  Hardware: PC
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P
 Component: Modules
  Assignee: unassignedclangb...@nondot.org
  Reporter: bo...@codesynthesis.com
CC: dgre...@apple.com, llvm-bugs@lists.llvm.org

Created attachment 19459
  --> https://bugs.llvm.org/attachment.cgi?id=19459&action=edit
Reproducing script.

The attached reproducer causes the following unexpected error:

In file included from driver.cxx:1:
/tmp/repro/std.mxx:20:15: error: definition of '' must be imported from module
'mystd.' before it is required
  fpos(): _M_state () {}
  ^
/tmp/repro/std.mxx:31:27: note: in instantiation of member function
'mystd::fpos<__mbstate_t>::fpos' requested here
fpos<__mbstate_t> p;
  ^
driver.cxx:6:6: note: in instantiation of member function
'mystd::basic_istringstream::seekg' requested here
  is.seekg (0);
 ^
/tmp/repro/std.mxx:1:9: note: previous definition is here
typedef struct

Note that naming the struct fixes '' but does not get rid of the error. I am
also observing what appears to be related error (haven't come up with a
reproducer for it yet):

/home/boris/work/build2/libbutl/libbutl/standard-version.cxx:57:22: error:
declaration of 'strtoull' must be imported from module 'std.core.'
before it
  is required
uint64_t r (std::strtoull (b, &e, 10));
 ^
/home/boris/work/build2/tests/modules/gcc/gcc-install/lib/gcc/x86_64-pc-linux-gnu/8.0.0/../../../../include/c++/8.0.0/cstdlib:245:22:
note: previous
  declaration is here
  using ::__gnu_cxx::strtoull;

-- 
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 35394] New: source code inside a label after a loop is wrongly labeled as not executed in llvm-cov

2017-11-23 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=35394

Bug ID: 35394
   Summary: source code inside a label after a loop is wrongly
labeled as not executed in llvm-cov
   Product: clang
   Version: trunk
  Hardware: PC
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P
 Component: -New Bugs
  Assignee: unassignedclangb...@nondot.org
  Reporter: yangyib...@nju.edu.cn
CC: llvm-bugs@lists.llvm.org

$ clang -v
clang version 6.0.0-svn318792-1~exp1 (trunk)
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/5
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/5.4.1
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/6
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/6.3.0
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/7
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5.4.1
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6.3.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7.2.0
Selected GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0
Candidate multilib: .;@m64
Selected multilib: .;@m64

$ cat small.c
int main()
{
int i=0, k=0;
if (1) {
if (1) {
goto lbl;
}
} else {
lbl:
for (; k < 2; k++)
;

i = i+1;
}

printf("%d\n", i);
return 0;
}

$ clang -w -O0 -g -fcoverae-mapping -fprofile-instr-generate=small.profraw
small.c; ./a.out; llvm-profdata merge small.profraw -o small.profdata; llvm-cov
show a.out -instr-profile=small.profdata small.c > small.gcov
1

$ cat small.gcov
1|   |int main()
2|  1|{
3|  1|int i=0, k=0;
4|  1|if (1) {
5|  1|if (1) {
6|  1|goto lbl;
7|  1|}
8|  0|} else {
9|  1|lbl:
   10|  3|for (; k < 2; k++)
   11|  2|;
   12|  0|
   13|  0|i = i+1;
   14|  0|}
   15|  1|
   16|  1|printf("%d\n", i);
   17|  1|return 0;
   18|  1|}

Line #13 is executed but the output showed that this line is not executed in
llvm-cov.

-- 
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 35396] New: lit crashes

2017-11-23 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=35396

Bug ID: 35396
   Summary: lit crashes
   Product: new-bugs
   Version: trunk
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P
 Component: new bugs
  Assignee: unassignedb...@nondot.org
  Reporter: matthias.krue...@famsik.de
CC: llvm-bugs@lists.llvm.org

[...]
llvm-lit:
/home/matthias/LLVM/LLVM_dev/stage_3_tests/llvm/utils/lit/lit/formats/googletest.py:43:
warning: unable to discover google-tests in
'/home/matthias/LLVM/LLVM_dev/stage_3_tests/objects/projects/compiler-rt/lib/asan/tests/dynamic/./Asan-x86_64-inline-Dynamic-Test':
Command
'['/home/matthias/LLVM/LLVM_dev/stage_3_tests/objects/projects/compiler-rt/lib/asan/tests/dynamic/./Asan-x86_64-inline-Dynamic-Test',
'--gtest_list_tests']' returned non-zero exit status 1. Process output: 
=
==18957==ERROR: AddressSanitizer: odr-violation (0x0022ab00):
  [1] size=2 ''
/home/matthias/LLVM/LLVM_dev/stage_3_tests/llvm/projects/compiler-rt/lib/asan/tests/asan_asm_test.cc:260:3
  [2] size=2 ''
/home/matthias/LLVM/LLVM_dev/stage_3_tests/llvm/utils/unittest/googletest/src/gtest.cc:5254:47
These globals were registered at these points:
  [1]:
#0 0x7fe9eb5bfd6e 
(/home/matthias/LLVM/LLVM_dev/stage_3_tests/objects/./lib/clang/6.0.0/lib/linux/libclang_rt.asan-x86_64.so+0x83d6e)
#1 0x2e1449 
(/home/matthias/LLVM/LLVM_dev/stage_3_tests/objects/projects/compiler-rt/lib/asan/tests/dynamic/Asan-x86_64-calls-Dynamic-Test+0x2e1449)

  [2]:
#0 0x7fe9eb5bfd6e 
(/home/matthias/LLVM/LLVM_dev/stage_3_tests/objects/./lib/clang/6.0.0/lib/linux/libclang_rt.asan-x86_64.so+0x83d6e)
#1 0x298069 
(/home/matthias/LLVM/LLVM_dev/stage_3_tests/objects/projects/compiler-rt/lib/asan/tests/dynamic/Asan-x86_64-calls-Dynamic-Test+0x298069)

==18957==HINT: if you don't care about these errors you may set
ASAN_OPTIONS=detect_odr_violation=0
SUMMARY: AddressSanitizer: odr-violation: global '' at
/home/matthias/LLVM/LLVM_dev/stage_3_tests/llvm/projects/compiler-rt/lib/asan/tests/asan_asm_test.cc:260:3
==18957==ABORTING
llvm-lit:
/home/matthias/LLVM/LLVM_dev/stage_3_tests/llvm/utils/lit/lit/formats/googletest.py:43:
warning: unable to discover google-tests in
'/home/matthias/LLVM/LLVM_dev/stage_3_tests/objects/projects/compiler-rt/lib/asan/tests/dynamic/./Asan-x86_64-calls-Dynamic-Test':
Command
'['/home/matthias/LLVM/LLVM_dev/stage_3_tests/objects/projects/compiler-rt/lib/asan/tests/dynamic/./Asan-x86_64-calls-Dynamic-Test',
'--gtest_list_tests']' returned non-zero exit status 1. Process output: 
llvm-lit:
/home/matthias/LLVM/LLVM_dev/stage_3_tests/llvm/utils/lit/lit/discovery.py:244:
warning: input
'/home/matthias/LLVM/LLVM_dev/stage_3_tests/objects/projects/compiler-rt/test/asan/Unit/dynamic'
contained no tests
llvm-lit:
/home/matthias/LLVM/LLVM_dev/stage_3_tests/llvm/utils/lit/lit/llvm/config.py:331:
note: using clang: /home/matthias/LLVM/LLVM_dev/stage_3_tests/objects/bin/clang
llvm-lit:
/home/matthias/LLVM/LLVM_dev/stage_3_tests/llvm/utils/lit/lit/TestingConfig.py:101:
fatal: unable to parse config file
'/home/matthias/LLVM/LLVM_dev/stage_3_tests/llvm/tools/lldb/lit/lit.cfg',
traceback: Traceback (most recent call last):
  File
"/home/matthias/LLVM/LLVM_dev/stage_3_tests/llvm/utils/lit/lit/TestingConfig.py",
line 88, in load_from_path
exec(compile(data, path, 'exec'), cfg_globals, None)
  File
"/home/matthias/LLVM/LLVM_dev/stage_3_tests/llvm/tools/lldb/lit/lit.cfg", line
119, in 
if re.match(r'icc', config.cc):
  File "/usr/lib64/python2.7/re.py", line 141, in match
return _compile(pattern, flags).match(string)
TypeError: expected string or buffer

FAILED: CMakeFiles/check-all 



Here is the corresponding cmake call:
https://github.com/matthiaskrgr/llvm_bootstrap/blob/master/build_git.sh#L361

-- 
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 35397] New: [AMDGPU][MC][GFX8][GFX9] Use of bound_ctrl is incompatible with SP3

2017-11-23 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=35397

Bug ID: 35397
   Summary: [AMDGPU][MC][GFX8][GFX9] Use of bound_ctrl is
incompatible with SP3
   Product: libraries
   Version: trunk
  Hardware: PC
OS: All
Status: NEW
  Severity: enhancement
  Priority: P
 Component: Backend: AMDGPU
  Assignee: unassignedb...@nondot.org
  Reporter: dpreobrazhen...@luxoft.com
CC: llvm-bugs@lists.llvm.org

SP3 handles bound_ctrl differently in gfx8 and gfx9.
This causes incompatibility and inconsistency issues.

-
Modifier  SP3 meaningdecoded by SP3 as
 gfx8  gfx9gfx8 gfx9
-
bound_ctrl=0 set bit   clr bit bound_ctrl=0 
bound_ctrl=1 set bit   set bit bound_ctrl=0 bound_ctrl=1
clr bit   clr bit 
-

Our assembler is incompatible with SP3 implementation: 

-
ModifierLLVM Asm meaning   decoded by LLVM Asm as
-
bound_ctrl=0set bitbound_ctrl=0
bound_ctrl=1N/A
   clr bit
-

I believe we should improve current implementation:
- make it more compatible with SP3;
- make it more consistent.

I see the following options:

a) Do not change anything;
b) Strictly follow SP3 implementation;
c) Mimic SP3 gfx8 implementation for both gfx8 and gfx9;
d) Mimic SP3 gfx9 implementation for both gfx8 and gfx9.

Artem and Sam suggested option c) while I tend to prefer option d).
Matt, what is your opinion?

-- 
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 35398] New: [Modules TS] assertion in lib/AST/Decl.cpp:1397: D->getCachedLinkage() == LV.getLinkage()

2017-11-23 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=35398

Bug ID: 35398
   Summary: [Modules TS] assertion in lib/AST/Decl.cpp:1397:
D->getCachedLinkage() == LV.getLinkage()
   Product: clang
   Version: trunk
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P
 Component: Modules
  Assignee: unassignedclangb...@nondot.org
  Reporter: bo...@codesynthesis.com
CC: dgre...@apple.com, llvm-bugs@lists.llvm.org

Created attachment 19460
  --> https://bugs.llvm.org/attachment.cgi?id=19460&action=edit
Reproducing script.

The attached reproducer triggers an assertion:

lib/AST/Decl.cpp:1397: clang::LinkageInfo
clang::LinkageComputer::getLVForDecl(const clang::NamedDecl*,
clang::LVComputationKind): Assertion `D->getCachedLinkage() == LV.getLinkage()'
failed.

D is function ansec(). Interestingly, making ansec() static gets rid of the
assertion.

-- 
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 34765] [mc][gfx9] Integer ADD/SUB with carry-in/out do not match the Gfx9 specification.

2017-11-23 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=34765

Dmitry  changed:

   What|Removed |Added

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

--- Comment #1 from Dmitry  ---
Closed by commit rL318675:
http://llvm.org/viewvc/llvm-project?rev=318675&view=rev

-- 
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 35148] [AMDGPU][MC][GFX9][disassembler] incorrect default value of op_sel_hi for v_mad_mix*

2017-11-23 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=35148

Dmitry  changed:

   What|Removed |Added

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

--- Comment #1 from Dmitry  ---
Closed by commit rL318526:
http://llvm.org/viewvc/llvm-project?rev=318526&view=rev

-- 
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 35399] New: lzcnt causes erroneous code generation (x86_64)

2017-11-23 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=35399

Bug ID: 35399
   Summary: lzcnt causes erroneous code generation (x86_64)
   Product: clang
   Version: 5.0
  Hardware: PC
OS: Windows NT
Status: NEW
  Severity: normal
  Priority: P
 Component: -New Bugs
  Assignee: unassignedclangb...@nondot.org
  Reporter: michel.bern...@gmail.com
CC: llvm-bugs@lists.llvm.org

Created attachment 19461
  --> https://bugs.llvm.org/attachment.cgi?id=19461&action=edit
Code compiled with : clang++ lzcnt.cpp -Wall -pedantic -O2 -mlzcnt -S

The use of lzcnt has an unexpected behavior, when using the -mlzcnt flag with
optimizations.

Compiling :

uint64_t test64_2(uint64_t x, bool& b1, bool& b2)
{
uint64_t a = (x == 0 ? 64 : __builtin_clzll(x));
b1 = (a != 64);
b2 = !b1;
return a;
}

Generates :

test64_2(unsigned long, bool&, bool&): # @test64_2(unsigned long, bool&, bool&)
  lzcntq %rdi, %rax
  setae (%rsi)
  setae (%rdx)
  retq

Which sets the two bools to the same value, even though 'b2 = !b1;' and I can't
see any undefined behavior.
This concerns all 16, 32 and 64 bits versions of lzcnt. Omitting -mlzcnt
produces the expected behavior for __builtin_clz versions, using bsr.

-- 
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 35400] New: Too much narrowing when converting dbg.declare to dbg.value

2017-11-23 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=35400

Bug ID: 35400
   Summary: Too much narrowing when converting dbg.declare to
dbg.value
   Product: libraries
   Version: trunk
  Hardware: PC
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P
 Component: DebugInfo
  Assignee: unassignedb...@nondot.org
  Reporter: mattias.v.eriks...@ericsson.com
CC: llvm-bugs@lists.llvm.org

Created attachment 19462
  --> https://bugs.llvm.org/attachment.cgi?id=19462&action=edit
Reproduce with: opt -sroa -S dbgvaluesext.ll

I think this is a bug in how a llvm.dbg.declare is converted to llvm.dbg.value.

Input, the variable "bl" is 64 bit on the stack:
define i64 @refAddshSat(i32 %param32) {
bb2:
  %local64 = alloca i64
  call void @llvm.dbg.declare(metadata i64* %local64, metadata !10, metadata
!DIExpression()), !dbg !12
  %_tmp20 = sext i32 %param32 to i64
  store i64 %_tmp20, i64* %local64
  %_tmp24 = load i64, i64* %local64
  ret i64 %_tmp24
}
!10 = !DILocalVariable(name: "bl", scope: !9, line: 58, type: !11)
!11 = !DIBasicType(name: "long long", size: 64, encoding: DW_ATE_signed)


After SROA we get "bl" as a 32 bit temporary, this looks incorrect to me:
define i64 @refAddshSat(i32 %param32) {
bb2:
  %_tmp20 = sext i32 %param32 to i64
  call void @llvm.dbg.value(metadata i32 %param32, metadata !4, metadata
!DIExpression()), !dbg !11
  ret i64 %_tmp20
}
!4 = !DILocalVariable(name: "bl", scope: !5, line: 58, type: !10)
!10 = !DIBasicType(name: "long long", size: 64, encoding: DW_ATE_signed)

-- 
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 35399] lzcnt causes erroneous code generation (x86_64)

2017-11-23 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=35399

Craig Topper  changed:

   What|Removed |Added

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

--- Comment #2 from Craig Topper  ---
Fixed in r318934.

-- 
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 35401] New: Inconsistency: enumerator name is found only if not qualified

2017-11-23 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=35401

Bug ID: 35401
   Summary: Inconsistency: enumerator name is found only if not
qualified
   Product: clang
   Version: trunk
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P
 Component: C++14
  Assignee: unassignedclangb...@nondot.org
  Reporter: jenda.tu...@gmail.com
CC: llvm-bugs@lists.llvm.org

This code does compile. If we replace (1) with (2), it does compile, which is
weird and likely wrong.

namespace N { enum E : int; }
enum N::E : int {A,B};

int bar() {
//return int(::A); // 1
return int(A); // 2
}

Clang reject the commented line in function bar(), but accepts the line below.
I think it should either accept both or reject both. Gcc does reject both. 

However, maybe compilers should accept both lines, because N4296 says in
7.2/11:
> Each enum-name and each unscoped enumerator is declared in the scope that
> immediately contains the enum-specifier.
which is to global scope.

The problem originally appeared in this SO question:
https://stackoverflow.com/q/47383199/6209703

-- 
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] Issue 3890 in oss-fuzz: llvm/clangd-fuzzer: Null-dereference READ in void llvm::yaml::skip

2017-11-23 Thread monor… via monorail via llvm-bugs 

Updates:
Labels: ClusterFuzz-Top-Crash

Comment #2 on issue 3890 by  
monor...@clusterfuzz-external.iam.gserviceaccount.com: llvm/clangd-fuzzer:  
Null-dereference READ in void llvm::yaml::skip

https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=3890#c2

Testcase 5861264459825152 is a top crash on ClusterFuzz for linux platform.  
Please prioritize fixing this crash.


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

[llvm-bugs] [Bug 35402] New: error in backend: Cannot select: 0x55ce75ede940: ch = PPCISD::STBRX

2017-11-23 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=35402

Bug ID: 35402
   Summary: error in backend: Cannot select: 0x55ce75ede940: ch =
PPCISD::STBRX
   Product: clang
   Version: trunk
  Hardware: PC
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P
 Component: LLVM Codegen
  Assignee: unassignedclangb...@nondot.org
  Reporter: j...@jms.id.au
CC: llvm-bugs@lists.llvm.org

Created attachment 19463
  --> https://bugs.llvm.org/attachment.cgi?id=19463&action=edit
clang command line

I am building the Linux kernel for PowerPC, cross compiling from x86.

clang version 5.0.0-4 (tags/RELEASE_500/final)

The bug reproduces with clang version 6.0.0 (trunk 318937).


  CC [M]  drivers/net/ethernet/mellanox/mlx4/resource_tracker.o
fatal error: error in backend: Cannot select: 0x55ce75ede940: ch =
PPCISD::STBRX
  0x55ce75f74b28, 0x55ce75edf090, 0x55ce75ed94c8, ValueType:ch:i48
  0x55ce75edf090: i32 = truncate 0x55ce75e9b398
0x55ce75e9b398: i64 = srl 0x55ce75ed8ca8, Constant:i32<16>
  0x55ce75ed8ca8: i64,ch = CopyFromReg 0x55ce744f44e8, Register:i64 %vreg26
0x55ce75f9bd08: i64 = Register %vreg26
  0x55ce75f74238: i32 = Constant<16>
  0x55ce75ed94c8: i64 = add 0x55ce75edeb48, Constant:i64<10>
0x55ce75edeb48: i64,ch = CopyFromReg 0x55ce744f44e8, Register:i64 %vreg20
  0x55ce75f74f38: i64 = Register %vreg20
0x55ce75e9b330: i64 = Constant<10>
In function: mlx4_QP_FLOW_STEERING_ATTACH_wrapper
clang: error: clang frontend command failed with exit code 70 (use -v to see
invocation)
clang version 5.0.0-4 (tags/RELEASE_500/final)
Target: powerpc64le--linux-gnu
Thread model: posix

-- 
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 35403] New: Code in nesting if statement is wrongly labeled as not executed in llvm-cov

2017-11-23 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=35403

Bug ID: 35403
   Summary: Code in nesting if statement is wrongly labeled as not
executed in llvm-cov
   Product: clang
   Version: trunk
  Hardware: PC
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P
 Component: -New Bugs
  Assignee: unassignedclangb...@nondot.org
  Reporter: yangyib...@nju.edu.cn
CC: llvm-bugs@lists.llvm.org

$ clang -v
clang version 6.0.0-svn318792-1~exp1 (trunk)
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/5
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/5.4.1
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/6
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/6.3.0
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/7
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5.4.1
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6.3.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7.2.0
Selected GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0
Candidate multilib: .;@m64
Selected multilib: .;@m64

$ cat small.c
int main()
{
int i=1, j=1, k=1;
if (i > 0) {
if (j == 1) {
if (k == 1)
return 0;
} else {
;
}
k++;
}
}

$ clang -w -O0 -g -fcoverage-mapping -fprofile-instr-generate=small.profraw
small.c; ./a.out; llvm-profdata merge small.profraw -o small.profdata; llvm-cov
show a.out -instr-profile=small.profdata small.c > small.gcov

$ cat small.gcov
1|   |int main()
2|  1|{
3|  1|int i=1, j=1, k=1;
4|  1|if (i > 0) {
5|  1|if (j == 1) {
6|  1|if (k == 1)
7|  1|return 0;
8|  0|} else {
9|  0|;
   10|  0|}
   11|  1|k++;
   12|  0|}
   13|  1|}



We can find that in Line 7# the program is exit. Thus Line 11# is wrongly
marked as executed in llvm-cov.

-- 
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 35404] New: Else statement inside an if statement lead to incorrect coverage information in llvm-cov

2017-11-23 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=35404

Bug ID: 35404
   Summary: Else statement inside an if statement lead to
incorrect coverage information in llvm-cov
   Product: clang
   Version: trunk
  Hardware: PC
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P
 Component: -New Bugs
  Assignee: unassignedclangb...@nondot.org
  Reporter: yangyib...@nju.edu.cn
CC: llvm-bugs@lists.llvm.org

$ clang -v
clang version 6.0.0-svn318792-1~exp1 (trunk)
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/5
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/5.4.1
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/6
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/6.3.0
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/7
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5.4.1
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6.3.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7.2.0
Selected GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0
Candidate multilib: .;@m64
Selected multilib: .;@m64

$ cat small.c
int main()
{
int i=1, j=1;
if (i > 0) {
if (j > 0)
return 0;
else
j++;
}
return 1;
}

$ clang -w -O0 -g -fcoverage-mapping -fprofile-instr-generate=small.profraw
small.c; ./a.out; llvm-profdata merge small.profraw -o small.profdata; llvm-cov
show a.out -instr-profile=small.profdata small.c > small.gcov

$ cat small.gcov
1|   |int main()
2|  1|{
3|  1|int i=1, j=1;
4|  1|if (i > 0) {
5|  1|if (j > 0)
6|  1|return 0;
7|  0|else
8|  0|j++;
9|  1|}
   10|  1|return 1;
   11|  1|}

Line #10 is wrongly marked as executed. While removing Line #7 and Line #8, the
result is correct.

-- 
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 35405] New: Coroutine suspend/resume in loop not always optimized away

2017-11-23 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=35405

Bug ID: 35405
   Summary: Coroutine suspend/resume in loop not always optimized
away
   Product: clang
   Version: trunk
  Hardware: PC
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P
 Component: -New Bugs
  Assignee: unassignedclangb...@nondot.org
  Reporter: stra...@fb.com
CC: llvm-bugs@lists.llvm.org

It seems like Clang+LLVM has some trouble optimizing my code. In a loop, I am
suspending a coroutine then calling
std::experimental::coroutine_handle::resume. See main_v0_loop in the program
below.

I expect Clang+LLVM to optimize the loop away completely, but the generated
code repeatedly suspends and resumes the coroutine.

Clang+LLVM *is* able to properly optimize similar loops. It also is able to
properly optimize the loop if I unroll the loop, but not always. See the other
main_* functions in the program below.

Let me know if (and how) I should reduce the program further.

Program:
https://godbolt.org/g/m2YSsW

main_v0_loop: gen_pop-push 1000 times, then gen_pop once (suspending the
coroutine forever). Conceptually, the gen_pop-s are done asynchronously on a
different "thread".
main_v1_loop: push-gen_pop 1000 times. Conceptually, the gen_pop-s are done
synchronously on the main "thread".
main_v2_loop: push-pop 1000 times.
main_v3_loop: push-gen_pop 1000 times, then gen_pop once (suspending the
coroutine forever). Conceptually, the gen_pop-s are done asynchronously on a
different "thread".

main_v0_single: Like main_v0_loop, but iterate only once and manually unroll
the loop.
main_v1_single: Like main_v1_loop, but iterate only once and manually unroll
the loop.
main_v2_single: Like main_v2_loop, but iterate only once and manually unroll
the loop.
main_v3_single: Like main_v3_loop, but iterate only once and manually unroll
the loop.

main_v0_triple: Like main_v0_loop, but iterate only 3 times and manually unroll
the loop.
main_v1_triple: Like main_v1_loop, but iterate only 3 times and manually unroll
the loop.
main_v2_triple: Like main_v2_loop, but iterate only 3 times and manually unroll
the loop.
main_v3_triple: Like main_v3_loop, but iterate only 3 times and manually unroll
the loop.

Clang+LLVM version: 6.0.0 trunk 318899 (according to Godbolt's Compiler
Explorer )

Clang driver flags: -std=c++17 -fcoroutines-ts -stdlib=libc++ -O2 -DNDEBUG=1
-fno-exceptions

Platform: Linux x86_64 (I think; I used Godbolt's Compiler Explorer
)

Expected results:
X: The generated code for main_v0_*, main_v1_*, and main_v3_* has no calls to
operator new or operator delete (due to the coroutine created by pop_once or
keep_popping).
Y: The generated code for all functions has no indirect jumps (due to the call
to coroutine_handle::resume).
Z: The generated code for all functions is just 'ret', since the function has
no side effects.

Observed results:
X: As expected, the generated code for all functions has no calls to operator
new or operator delete.
Y: The generated code for main_v0_loop, main_v0_triple, main_v3_loop, and
main_v3_triple has indirect jumps. The generated code for all other functions
has no indirect jumps as expected.
Z: The generated code for main_v0_loop, main_v0_triple, main_v3_loop, and
main_v3_triple is non-trivial. The generated code for all other functions is
just 'ret' as expected.

-- 
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 35406] New: [Indvars] Incorrect hoisting of udiv/urem

2017-11-23 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=35406

Bug ID: 35406
   Summary: [Indvars] Incorrect hoisting of udiv/urem
   Product: libraries
   Version: trunk
  Hardware: PC
OS: Windows NT
Status: NEW
  Severity: enhancement
  Priority: P
 Component: Scalar Optimizations
  Assignee: unassignedb...@nondot.org
  Reporter: serguei.kat...@azul.com
CC: llvm-bugs@lists.llvm.org

Indvars does an incorrect transformation for the following reproducer:
=
; ModuleID = 'repro.ll'
;target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128-ni:1"
target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128:1"
target triple = "x86_64-unknown-linux-gnu"

define i32 @test(i8* %p, i64* %p1) {
entry:
  br label %loop1

loop1:
  %local_0_ = phi i32 [ 8, %entry ], [ %9, %loop2.exit ]
  %local_2_ = phi i32 [ 63864, %entry ], [ %local_2_43, %loop2.exit ]
  %local_3_ = phi i32 [ 51, %entry ], [ %local_3_44, %loop2.exit ]
  %0 = udiv i32 14, %local_0_
  %1 = icmp ugt i32 %local_0_, 14
  br i1 %1, label %exit, label %general_case24

general_case24:
;  %2 = urem i32 60392, %0
  %2 = udiv i32 60392, %0
  br i1 false, label %loop2, label %loop2.exit

loop2:
  %local_1_56 = phi i32 [ %2, %general_case24 ], [ %3, %loop2 ]
  %local_2_57 = phi i32 [ 1, %general_case24 ], [ %7, %loop2 ]
  %3 = add i32 %local_1_56, -1
  %4 = load i64* %p1, align 8
;  %4 = load atomic i64, i64* %p1 unordered, align 8
  %5 = sext i32 %3 to i64
  %6 = sub i64 %4, %5
;  store atomic i64 %6, i64* %p1 unordered, align 8
  store i64 %6, i64* %p1, align 8
  %7 = add nuw nsw i32 %local_2_57, 1
  %8 = icmp ugt i32 %local_2_57, 7
  br i1 %8, label %loop2.exit, label %loop2

loop2.exit:
  %local_2_43 = phi i32 [ %local_2_, %general_case24 ], [ 9, %loop2 ]
  %local_3_44 = phi i32 [ %local_3_, %general_case24 ], [ %local_1_56, %loop2 ]
  %9 = add nuw nsw i32 %local_0_, 1
  %10 = icmp ugt i32 %local_0_, 129
  br i1 %10, label %exit, label %loop1

exit:
  ret i32 0
}

opt --indvars -S repro.ll
results in

...
loop1:; preds = %loop2.exit, %entry
  %indvars.iv = phi i32 [ %indvars.iv.next, %loop2.exit ], [ 8, %entry ]
  %0 = udiv i32 14, %indvars.iv
  %1 = udiv i32 60392, %0
  %2 = zext i32 %1 to i64
  %3 = udiv i32 14, %indvars.iv
  %4 = icmp ugt i32 %indvars.iv, 14
  br i1 %4, label %exit, label %general_case24
...

  %1 = udiv i32 60392, %0
instruction causes a division by zero in case %indvars.iv == 15.

-- 
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 35407] New: clang++: error: unable to execute command: Segmentation fault (core dumped)

2017-11-23 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=35407

Bug ID: 35407
   Summary: clang++: error: unable to execute command:
Segmentation fault (core dumped)
   Product: new-bugs
   Version: 5.0
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P
 Component: new bugs
  Assignee: unassignedb...@nondot.org
  Reporter: ralf.habac...@freenet.de
CC: llvm-bugs@lists.llvm.org

Created attachment 19465
  --> https://bugs.llvm.org/attachment.cgi?id=19465&action=edit
run script

clang++: error: clang frontend command failed due to signal (use -v to see
invocation)
Android clang version 5.0.300080  (based on LLVM 5.0.300080)
Target: armv5te-none-linux-android
Thread model: posix
InstalledDir:
/home/ralf.habacker/Android/android-ndk-r16/toolchains/llvm/prebuilt/linux-x86_64/bin
clang++: 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++: note: diagnostic msg: 


PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
Preprocessed source(s) and associated run script(s) are located at:
clang++: note: diagnostic msg: /tmp/BlendColor-bc9dd4.cpp
clang++: note: diagnostic msg: /tmp/BlendColor-bc9dd4.sh
clang++: note: diagnostic msg: 

(gdb) bt
#0  0x00f1ded3 in ?? ()
#1  0x00f1d5a3 in ?? ()
#2  0x00f17cfa in ?? ()
#3  0x00f11bbb in ?? ()
#4  0x029cf6ce in ?? ()
#5  0x010f27c2 in llvm::FPPassManager::runOnFunction(llvm::Function&)
()
#6  0x0304b6c3 in llvm::FPPassManager::runOnModule(llvm::Module&) ()
#7  0x0304bad1 in llvm::legacy::PassManagerImpl::run(llvm::Module&) ()
#8  0x0156bd15 in 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 >) ()
#9  0x016cd04b in
clang::BackendConsumer::HandleTranslationUnit(clang::ASTContext&) ()
#10 0x0178036f in clang::ParseAST(clang::Sema&, bool, bool) ()
#11 0x016c97f3 in clang::CodeGenAction::ExecuteAction() ()
#12 0x011b1535 in clang::FrontendAction::Execute() ()
#13 0x0116b20f in
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) ()
#14 0x0112736a in
clang::ExecuteCompilerInvocation(clang::CompilerInstance*) ()
#15 0x0111c686 in cc1_main(llvm::ArrayRef, char const*,
void*) ()
#16 0x01125c0e in main ()

-- 
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