[llvm-bugs] [Bug 44944] New: error when following instructions to build the documentation

2020-02-18 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=44944

Bug ID: 44944
   Summary: error when following instructions to build the
documentation
   Product: Documentation
   Version: trunk
  Hardware: Macintosh
OS: MacOS X
Status: NEW
  Severity: enhancement
  Priority: P
 Component: General docs
  Assignee: unassignedb...@nondot.org
  Reporter: jean.christophe.hel...@traduction-libre.org
CC: llvm-bugs@lists.llvm.org

The llvm-project/llvm/docs/README.txt file reads:



If you instead would like to generate and view the HTML locally, install
Sphinx  and then do:

   cd 
   cmake -DLLVM_ENABLE_SPHINX=true -DSPHINX_OUTPUT_HTML=true 
   make -j3 docs-llvm-html
   $BROWSER /docs//html/index.html



When I follow the instructions (macos) I get the following output:


===
➜  llvm git:(master) mkdir html;cd html
➜  html git:(master) cmake -DLLVM_ENABLE_SPHINX=true -DSPHINX_OUTPUT_HTML=true
cmake /Users/suzume/Documents/Code/llvm-project/llvm/docs/
===
CMake Warning (dev) in CMakeLists.txt:
 No project() command is present.  The top-level CMakeLists.txt file must
 contain a literal, direct call to the project() command.  Add a line of
 code such as

   project(ProjectName)

 near the top of the file, but after cmake_minimum_required().

 CMake is pretending there is a "project(Project)" command on the first
 line.
This warning is for project developers.  Use -Wno-dev to suppress it.

-- The C compiler identification is AppleClang 11.0.0.1133
-- The CXX compiler identification is AppleClang 11.0.0.1133
-- Check for working C compiler:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc
-- Check for working C compiler:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc
-- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++
-- Check for working CXX compiler:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++
-- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
CMake Error at CMakeLists.txt:106 (include):
 include could not find load file:

   AddSphinxTarget


CMake Warning (dev) in CMakeLists.txt:
 No cmake_minimum_required command is present.  A line of code such as

   cmake_minimum_required(VERSION 3.16)

 should be added at the top of the file.  The version specified may be lower
 if you wish to support older CMake versions for this project.  For more
 information run "cmake --help-policy CMP".
This warning is for project developers.  Use -Wno-dev to suppress it.

-- Configuring incomplete, errors occurred!
See also
"/Users/suzume/Documents/Code/llvm-project/llvm/html/CMakeFiles/CMakeOutput.log".

===

So maybe there is something missing in the documentation.

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

[llvm-bugs] [Bug 44945] New: llvm-tblgen crashes

2020-02-18 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=44945

Bug ID: 44945
   Summary: llvm-tblgen crashes
   Product: tools
   Version: 10.0
  Hardware: PC
OS: Windows NT
Status: NEW
  Severity: enhancement
  Priority: P
 Component: TableGen
  Assignee: unassignedb...@nondot.org
  Reporter: yuryb...@gmail.com
CC: llvm-bugs@lists.llvm.org

I compile LLVM 10.0.0-rc2 but llvm-tblgen crashes with this stack dump:

0.  Program arguments:
D:\libs\vcpkg\buildtrees\llvm\x86-windows-dbg\bin\llvm-tblgen.exe
-gen-dfa-packetizer -I
D:/libs/vcpkg/buildtrees/llvm/src/c8aac023bc-a535e33c48/llvm/lib/Target/Hexagon
-I D:/libs/vcpkg/buildtrees/llvm/src/c8aac023bc-a535e33c48/llvm/include -I
D:/libs/vcpkg/buildtrees/llvm/src/c8aac023bc-a535e33c48/llvm/lib/Target
D:/libs/vcpkg/buildtrees/llvm/src/c8aac023bc-a535e33c48/llvm/lib/Target/Hexagon/Hexagon.td
--write-if-changed -o lib/Target/Hexagon/HexagonGenDFAPacketizer.inc -d
lib/Target/Hexagon/HexagonGenDFAPacketizer.inc.d 
0x7B6AB020 (0x0178F020 0x0001 0x6703EAAE 0x0178EFF0), _calloc_base() +
0x7A0 bytes(s)
0x7B6ADB3C (0x0178F020 0x0001 0x 0x), _free_dbg() + 0x7C
bytes(s)
0x7B6AE110 (0x0178F020 0x054B 0x0178EE10 0x0178EE04), free() + 0x20
bytes(s)
0x004A879F (0x0178EE10 0x0178EFF0 0x00494AFE 0x0178F098),
llvm::SmallVectorImpl::~SmallVectorImpl() +
0x2F bytes(s),
D:\libs\vcpkg\buildtrees\llvm\src\c8aac023bc-a535e33c48\llvm\include\llvm\ADT\SmallVector.h,
line 336 + 0x11 byte(s)
0x004A86F0 (0x0178F098 0x0178F020 0x0001 0x0004),
llvm::SmallVector::~SmallVector() +
0x30 bytes(s),
D:\libs\vcpkg\buildtrees\llvm\src\c8aac023bc-a535e33c48\llvm\include\llvm\ADT\SmallVector.h,
line 844 + 0x8 byte(s)
0x00494AFE (0x0178EE10 0x0178F13C 0x 0x0001),
llvm::DfaEmitter::visitDfaState() + 0x37E bytes(s),
D:\libs\vcpkg\buildtrees\llvm\src\c8aac023bc-a535e33c48\llvm\utils\TableGen\DFAEmitter.cpp,
line 85 + 0x8 byte(s)
0x00494729 (0x0178F38C 0x054B 0x 0x),
llvm::DfaEmitter::constructDfa() + 0xB9 bytes(s),
D:\libs\vcpkg\buildtrees\llvm\src\c8aac023bc-a535e33c48\llvm\utils\TableGen\DFAEmitter.cpp,
line 94 + 0x3F byte(s)
0x0049411A (0x0178F1DC 0x0007 0x0178F970 0x0178F65C),
llvm::DfaEmitter::emit() + 0x2A bytes(s),
D:\libs\vcpkg\buildtrees\llvm\src\c8aac023bc-a535e33c48\llvm\utils\TableGen\DFAEmitter.cpp,
line 100
0x004B884D (0x0178F970 0x04D40994 0x04FBBC30 0xCC00), `anonymous
namespace'::DFAPacketizerEmitter::emitForItineraries() + 0x5DD bytes(s),
D:\libs\vcpkg\buildtrees\llvm\src\c8aac023bc-a535e33c48\llvm\utils\TableGen\DFAPacketizerEmitter.cpp,
line 336
0x004B8DA5 (0x0178F970 0x0178F7C4 0x 0x04620AC8), `anonymous
namespace'::DFAPacketizerEmitter::run() + 0x205 bytes(s),
D:\libs\vcpkg\buildtrees\llvm\src\c8aac023bc-a535e33c48\llvm\utils\TableGen\DFAPacketizerEmitter.cpp,
line 227 + 0x27 byte(s)
0x004B8EF2 (0x0178FB34 0x0178F970 0x0178FB74 0x0178F7D4),
llvm::EmitDFAPacketizer() + 0x52 bytes(s),
D:\libs\vcpkg\buildtrees\llvm\src\c8aac023bc-a535e33c48\llvm\utils\TableGen\DFAPacketizerEmitter.cpp,
line 360 + 0x17 byte(s)
0x0069E9E5 (0x0178F970 0x0178FB34 0x0178FBB8 0x0020BC76), `anonymous
namespace'::LLVMTableGenMain() + 0x165 bytes(s),
D:\libs\vcpkg\buildtrees\llvm\src\c8aac023bc-a535e33c48\llvm\utils\TableGen\TableGen.cpp,
line 179 + 0xD byte(s)
0x00834E67 (0x01808BB4 0x0069E880 0x0020BC76 0x), llvm::TableGenMain()
+ 0x237 bytes(s),
D:\libs\vcpkg\buildtrees\llvm\src\c8aac023bc-a535e33c48\llvm\lib\TableGen\Main.cpp,
line 108 + 0x10 byte(s)
0x0069EEF7 (0x000E 0x01808B78 0x01809458 0x000E), main() + 0x87
bytes(s),
D:\libs\vcpkg\buildtrees\llvm\src\c8aac023bc-a535e33c48\llvm\utils\TableGen\TableGen.cpp,
line 263 + 0x19 byte(s)
0x008A0E93 (0x37EB8D13 0x0020BC76 0x0020BC76 0x00C9A000), invoke_main() + 0x33
bytes(s),
d:\agent\_work\6\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl, line
78 + 0x2D byte(s)
0x008A0D17 (0x0178FC44 0x008A0F18 0x0178FC54 0x747C6359),
__scrt_common_main_seh() + 0x157 bytes(s),
d:\agent\_work\6\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl, line
288 + 0x5 byte(s)
0x008A0BAD (0x0178FC54 0x747C6359 0x00C9A000 0x747C6340), __scrt_common_main()
+ 0xD bytes(s),
d:\agent\_work\6\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl, line
331
0x008A0F18 (0x00C9A000 0x747C6340 0x0178FCB0 0x76F27B74), mainCRTStartup() +
0x8 bytes(s),
d:\agent\_work\6\s\src\vctools\crt\vcstartup\src\startup\exe_main.cpp, line 17
0x747C6359 (0x00C9A000 0x0C3C8E3F 0x 0x), BaseThreadInitThunk()
+ 0x19 bytes(s)
0x76F27B74 (0x 0x76F48EFD 0x 0x),
RtlGetAppContainerNamedObjectPath() + 0xE4 bytes(s)
0x76F27B44 (0x0020BC76 0x00C9A000 0x 0x),
RtlGetAppContainerNamedObjectPath() + 0xB4 bytes(s)

I'm using MSVC 19.24.28316.0 compiler.

-- 
You are receiving this mail because:
You are on the CC list for the bug._

[llvm-bugs] [Bug 44946] New: template template argument deduction fail due to the imaginary conflict

2020-02-18 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=44946

Bug ID: 44946
   Summary: template template argument deduction fail due to the
imaginary conflict
   Product: clang
   Version: 8.0
  Hardware: PC
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P
 Component: C++11
  Assignee: unassignedclangb...@nondot.org
  Reporter: v...@bk.ru
CC: blitzrak...@gmail.com, dgre...@apple.com,
erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org,
richard-l...@metafoo.co.uk

enum class Enum {null};

template  struct Pattern {};
template  struct Breaker {};

struct Derived
: Pattern
, Breaker<220> // <- this must not mades a collision with Pattern
because int is not a Enum
{};

template  class P, Enum e> // here is Enum, int must not be
accepted
void matcher(P);

int main()
{
matcher(Derived{});//'matcher' candidate ignored: failed template argument
deduction
return 0;
}

//affected versions: 8,9,10,11

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

[llvm-bugs] [Bug 44947] New: Spaces between type and variable name in IIFE lambda in brace init removed by formatter

2020-02-18 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=44947

Bug ID: 44947
   Summary: Spaces between type and variable name in IIFE lambda
in brace init removed by formatter
   Product: clang
   Version: 9.0
  Hardware: PC
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P
 Component: Formatter
  Assignee: unassignedclangb...@nondot.org
  Reporter: l...@morgenst.de
CC: djas...@google.com, kli...@google.com,
llvm-bugs@lists.llvm.org

The following code

```
int foo {[]() {
  int bar{ 0 };
  return 0;
}()};
```

is formatted into

```
int foo{ []() {
  intbar{ 0 };
  return 0;
}() };
```

by clang-format-9 when using -style="{AlignConsecutiveDeclarations: true,
Cpp11BracedListStyle: false}".

The resulting code no longer compiles - note the missing space between `int`
and the variable name.

Changing either formatting option will fix the problem, it's the combination
that leads to the erroneous output.

The code is also correctly formatted if the outer braces (initialization of
foo) are replaced by a `=` assignment.

I don't have a later clang-format version than 9 installed locally, but trying
this code snippet in https://zed0.co.uk/clang-format-configurator with
10.0.0+b452de0 and these two formatting options, the output suddenly gets blank
(-> crash?).

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

[llvm-bugs] [Bug 44948] New: Crash with template code and -fopenmp

2020-02-18 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=44948

Bug ID: 44948
   Summary: Crash with template code and -fopenmp
   Product: OpenMP
   Version: unspecified
  Hardware: PC
OS: Linux
Status: NEW
  Keywords: compile-fail, regression
  Severity: enhancement
  Priority: P
 Component: Clang Compiler Support
  Assignee: unassignedclangb...@nondot.org
  Reporter: v.reich...@netcologne.de
CC: llvm-bugs@lists.llvm.org

The following code snippet triggers a segfault when compiled with "-fopenmp"
(although the code does not contain any OpenMP pragma at all):

=
template struct A
{
  ~A();
  T t;
};

template A::~A()
{
  delete t.p;
}
=

This is a recent regression that was introduced between commits 65e843c9e0b
(OK) and 377b0e2b06f (broken).


Stack dump:
0.  Program arguments: /LLVM-trunk/bin/clang++ -fopenmp -c CLbug.cc 
1.   parser at end of file
 #0 0x027b066a llvm::sys::PrintStackTrace(llvm::raw_ostream&)
(/LLVM-trunk/bin/clang+++0x27b066a)
 #1 0x027ae1d4 llvm::sys::RunSignalHandlers()
(/LLVM-trunk/bin/clang+++0x27ae1d4)
 #2 0x027ae42b llvm::sys::CleanupOnSignal(unsigned long)
(/LLVM-trunk/bin/clang+++0x27ae42b)
 #3 0x02728978 CrashRecoverySignalHandler(int)
(/LLVM-trunk/bin/clang+++0x2728978)
 #4 0x7f6debd23680 __restore_rt (/lib64/libpthread.so.0+0xf680)
 #5 0x04b1b413 clang::QualType::getSplitDesugaredType(clang::QualType)
(/LLVM-trunk/bin/clang+++0x4b1b413)
 #6 0x047ea768 clang::ASTContext::getBaseElementType(clang::QualType)
const (/LLVM-trunk/bin/clang+++0x47ea768)
 #7 0x03ff7dc2 clang::StmtVisitorBase::Visit(clang::Stmt*)
(/LLVM-trunk/bin/clang+++0x3ff7dc2)
 #8 0x03ff8202 clang::EvaluatedExprVisitorBase::VisitStmt(clang::Stmt*)
(/LLVM-trunk/bin/clang+++0x3ff8202)
 #9 0x03ff7e3b clang::StmtVisitorBase::Visit(clang::Stmt*)
(/LLVM-trunk/bin/clang+++0x3ff7e3b)
#10 0x03ff4cf4 (anonymous
namespace)::DeferredDiagnosticsEmitter::visitUsedDecl(clang::SourceLocation,
clang::Decl*) (/LLVM-trunk/bin/clang+++0x3ff4cf4)
#11 0x03ff49c7 (anonymous
namespace)::DeferredDiagnosticsEmitter::visitUsedDecl(clang::SourceLocation,
clang::Decl*) (/LLVM-trunk/bin/clang+++0x3ff49c7)
#12 0x03ff512b clang::Sema::emitDeferredDiags()
(/LLVM-trunk/bin/clang+++0x3ff512b)
#13 0x03ff536a
clang::Sema::ActOnEndOfTranslationUnitFragment(clang::Sema::TUFragmentKind)
(.part.1636) (/LLVM-trunk/bin/clang+++0x3ff536a)
#14 0x03ff5a6e clang::Sema::ActOnEndOfTranslationUnit()
(/LLVM-trunk/bin/clang+++0x3ff5a6e)
#15 0x03f1e063
clang::Parser::ParseTopLevelDecl(clang::OpaquePtr&, bool)
(/LLVM-trunk/bin/clang+++0x3f1e063)
#16 0x03f141b9 clang::ParseAST(clang::Sema&, bool, bool)
(/LLVM-trunk/bin/clang+++0x3f141b9)
#17 0x0352ca28 clang::CodeGenAction::ExecuteAction()
(/LLVM-trunk/bin/clang+++0x352ca28)
#18 0x02f3d309 clang::FrontendAction::Execute()
(/LLVM-trunk/bin/clang+++0x2f3d309)
#19 0x02f00c42
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&)
(/LLVM-trunk/bin/clang+++0x2f00c42)
#20 0x03002940
clang::ExecuteCompilerInvocation(clang::CompilerInstance*)
(/LLVM-trunk/bin/clang+++0x3002940)
#21 0x008f5371 cc1_main(llvm::ArrayRef, char const*,
void*) (/LLVM-trunk/bin/clang+++0x8f5371)
#22 0x008f15b7 ExecuteCC1Tool(llvm::SmallVectorImpl&)
(/LLVM-trunk/bin/clang+++0x8f15b7)
#23 0x02de1035 void llvm::function_ref::callback_fn
>, std::__cxx11::basic_string,
std::allocator >*, bool*) const::'lambda'()>(long)
(/LLVM-trunk/bin/clang+++0x2de1035)
#24 0x02728ae2
llvm::CrashRecoveryContext::RunSafely(llvm::function_ref)
(/LLVM-trunk/bin/clang+++0x2728ae2)
#25 0x02de1b15
clang::driver::CC1Command::Execute(llvm::ArrayRef
>, std::__cxx11::basic_string,
std::allocator >*, bool*) const (.part.168)
(/LLVM-trunk/bin/clang+++0x2de1b15)
#26 0x02dbe607
clang::driver::Compilation::ExecuteCommand(clang::driver::Command const&,
clang::driver::Command const*&) const (/LLVM-trunk/bin/clang+++0x2dbe607)
#27 0x02dbeee7
clang::driver::Compilation::ExecuteJobs(clang::driver::JobList const&,
llvm::SmallVectorImpl >&) const
(/LLVM-trunk/bin/clang+++0x2dbeee7)
#28 0x02dc71a1
clang::driver::Driver::ExecuteCompilation(clang::driver::Compilation&,
llvm::SmallVectorImpl >&)
(/LLVM-trunk/bin/clang+++0x2dc71a1)
#29 0x0085b7c3 main (/LLVM-trunk/bin/clang+++0x85b7c3)
clang-11: error: clang frontend command failed due to signal (use -v to see
invocation)
clang version 11.0.0 (https://github.com/llvm/llvm-project.git
0863f6757953684400162f2ad418f3e8e28af278)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /LLVM-trunk/bin

-- 
You are receiving this mail because:
You are on the CC list for the bug.___

[llvm-bugs] [Bug 44949] New: SROA and LVI interpreting undef differently

2020-02-18 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=44949

Bug ID: 44949
   Summary: SROA and LVI interpreting undef differently
   Product: libraries
   Version: trunk
  Hardware: PC
OS: All
Status: NEW
  Severity: normal
  Priority: P
 Component: Global Analyses
  Assignee: unassignedb...@nondot.org
  Reporter: w...@google.com
CC: llvm-bugs@lists.llvm.org

Created attachment 23135
  --> https://bugs.llvm.org/attachment.cgi?id=23135&action=edit
test1.ll before SROA

I see some problem which I think is caused by the fact that SROA and LVI
interpret “undef” differently.

I attached the IR before SROA in test1.ll, after SROA in test2.ll and the IR
after CVP in test3.ll (which utilizes LVI):
opt -sroa -S test1.ll > test2.ll
opt -correlated-propagation -S test2.ll > test3.ll

In test2.ll after SROA:
_ZNKSt3__u12basic_stringIcNS_11char_traitsIcEENS_9allocatorIcEEE5c_strEv.exit34:
  …
while.cond:
  %ref.tmp.sroa.79.0 = phi i64 [ undef,
%_ZNKSt3__u12basic_stringIcNS_11char_traitsIcEENS_9allocatorIcEEE5c_strEv.exit34
], [ %ref.tmp.sroa.79.23.insert.mask15,
%_ZNSt3__u12basic_stringIcNS_11char_traitsIcEENS_9allocatorIcEEED2Ev.exit ]
.sroa.79.23.insert.mask15,
%_ZNSt3__u12basic_stringIcNS_11char_traitsIcEENS_9allocatorIcEEED2Ev.exit ]
  …
cleanup.thread.i63:   ; preds = %if.end
  %ref.tmp.sroa.79.0..sroa_idx11 = getelementptr inbounds
%"class.std::__u::basic_string", %"class.std::__u::basic_string"* %result.i61,
i64 0, i32 0, i32 0, i32 0, i32 0, i32 0, i32 2
  %ref.tmp.sroa.79.0.copyload = load i64, i64* %ref.tmp.sroa.79.0..sroa_idx11,
align 8
  …
cleanup.i71:  ; preds = %if.end
  %ref.tmp.sroa.79.23.insert.mask = and i64 %ref.tmp.sroa.79.0,
72057594037927935
   …
if.then.i.i75:; preds = %cleanup.i71
   …
ReadLink.exit76:  ; preds = %if.then.i.i75,
%cleanup.i71, %cleanup.thread.i63
  %ref.tmp.sroa.79.1 = phi i64 [ %ref.tmp.sroa.79.0.copyload,
%cleanup.thread.i63 ], [ %ref.tmp.sroa.79.23.insert.mask, %if.then.i.i75 ], [
%ref.tmp.sroa.79.23.insert.mask, %cleanup.i71 ]
  …
_ZNSt3__u12basic_stringIcNS_11char_traitsIcEENS_9allocatorIcEEEaSEOS5_.exit: ;
preds = %if.then.i.i83, %ReadLink.exit76
  %ref.tmp.sroa.79.0..sroa_idx12 = getelementptr inbounds
%"class.std::__u::basic_string", %"class.std::__u::basic_string"* %target, i64
0, i32 0, i32 0, i32 0, i32 0, i32 0, i32 2
  store i64 %ref.tmp.sroa.79.1, i64* %ref.tmp.sroa.79.0..sroa_idx12, align 8
  %ref.tmp.sroa.79.23.insert.mask15 = and i64 %ref.tmp.sroa.79.1,
72057594037927935
  …
  br label %while.cond


%ref.tmp.sroa.79.0 is initialized to undef before the while loop in SROA
because no matter what value it has, its upper 8bits will be zero out in block
%cleanup.i71 anyway before stored into %target in block
_ZNSt3__u12basic_stringIcNS_11char_traitsIcEENS_9allocatorIcEEEaSEOS5_.exit, so
%target’s corresponding bits will always be zeroed out if %cleanup.i71 is taken
and those bits zeroed out in %target are what the program cares about. 

In LVI called by CVP,   for the phi in while.cond:
%ref.tmp.sroa.79.0 = phi i64 [ undef,
%_ZNKSt3__u12basic_stringIcNS_11char_traitsIcEENS_9allocatorIcEEE5c_strEv.exit34
], [ %ref.tmp.sroa.79.23.insert.mask15,
%_ZNSt3__u12basic_stringIcNS_11char_traitsIcEENS_9allocatorIcEEED2Ev.exit ]

LVI thinks %ref.tmp.sroa.79.23.insert.mask15 is a contant range [0 ~
0x100) which is correct because  “%ref.tmp.sroa.79.23.insert.mask15
= and i64 %ref.tmp.sroa.79.1, 72057594037927935” in block
%_ZNSt3__u12basic_stringIcNS_11char_traitsIcEENS_9allocatorIcEEEaSEOS5_.exit,
another phi operand is undef, so LVI thinks %ref.tmp.sroa.79.0 is a constant
range [0 ~ 0x100) too, and remove the instruction
“%ref.tmp.sroa.79.23.insert.mask = and i64 %ref.tmp.sroa.79.0,
72057594037927935” in cleanup.i71 (72057594037927935 is 0xff).
This.causes an intermittent error because now the related bits in target won’t
be zeroed out anymore in the first iteration of the while loop.

The problem is the undef inserted by SROA is meaningful only when the
instruction “%ref.tmp.sroa.79.23.insert.mask = and i64 %ref.tmp.sroa.79.0”,
72057594037927935” is in place in block %cleanup.i71. However, LVI understands
the undef literally to be any value, so it can assume it to be value “0” and
the instruction “%ref.tmp.sroa.79.23.insert.mask = and i64 %ref.tmp.sroa.79.0”
is of no use. 

I didn’t find similar case described in
https://www.cs.utah.edu/~regehr/papers/undef-pldi17.pdf. is it something wrong
in my understanding of the problem or is it a new case related with undef 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
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs

[llvm-bugs] [Bug 22594] exclude specified paths from analysis with scan-build

2020-02-18 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=22594

Sylvestre Ledru  changed:

   What|Removed |Added

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

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

[llvm-bugs] [Bug 44950] New: Please cherry-pick e32522ca178a into the 10.0 release branch

2020-02-18 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=44950

Bug ID: 44950
   Summary: Please cherry-pick e32522ca178a into the 10.0 release
branch
   Product: libraries
   Version: trunk
  Hardware: PC
OS: All
Status: NEW
  Severity: enhancement
  Priority: P
 Component: Scalar Optimizations
  Assignee: unassignedb...@nondot.org
  Reporter: florian_h...@apple.com
CC: llvm-bugs@lists.llvm.org

I think it would be good to pick e32522ca178a "[SLPVectorizer] Do not assume
extracelement idx is a ConstantInt. " into the 10.0 release branch.

It fixes a crash in the SLPVectorizer that was introduced since the last
release I think. https://reviews.llvm.org/rGe32522ca178a

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

[llvm-bugs] [Bug 44951] New: SLH assertion error: Should never have a PHI in the initial checking block as it always has a single predecessor!

2020-02-18 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=44951

Bug ID: 44951
   Summary: SLH assertion error: Should never have a PHI in the
initial checking block as it always has a single
predecessor!
   Product: libraries
   Version: trunk
  Hardware: PC
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P
 Component: Backend: X86
  Assignee: unassignedb...@nondot.org
  Reporter: ruppre...@google.com
CC: craig.top...@gmail.com, llvm-bugs@lists.llvm.org,
llvm-...@redking.me.uk, spatel+l...@rotateright.com

Created attachment 23138
  --> https://bugs.llvm.org/attachment.cgi?id=23138&action=edit
reproducer

IR reproducer (original input is a crash w/ -mspeculative-load-hardening
-fexperimental-new-pass-manager -O3):

$ cat repro.ll  # Also attached to the bug
; ModuleID = 'repro.ll'
source_filename = "repro.cc"
target datalayout =
"e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-unknown-linux-gnu"

@y = external dso_local global i8, align 1
@ap = external dso_local local_unnamed_addr global i32, align 4

; Function Attrs: speculative_load_hardening
define dso_local void @f1() local_unnamed_addr #0 {
entry:
  %0 = load i32, i32* @ap, align 4
  switch i32 %0, label %sw.epilog [
i32 0, label %sw.bb
i32 1, label %sw.bb1
i32 2, label %sw.bb4
i32 3, label %sw.bb7
  ]

sw.bb:; preds = %entry
  call void @f2(i8* nonnull undef, i8* null)
  unreachable

sw.bb1:   ; preds = %entry
  call void @f2(i8* nonnull undef, i8* null)
  unreachable

sw.bb4:   ; preds = %entry
  call void @f2(i8* nonnull undef, i8* nonnull @y)
  br label %sw.bb7

sw.bb7:   ; preds = %sw.bb4, %entry
  ret void

sw.epilog:; preds = %entry
  unreachable
}

; Function Attrs: speculative_load_hardening
declare dso_local void @f2(i8*, i8*) unnamed_addr #0

; Function Attrs: speculative_load_hardening
define dso_local void @f3() local_unnamed_addr #0 {
for.body.lr.ph:
  %call4 = call { i8*, i32 } @f4(i8* nonnull undef)
  %0 = extractvalue { i8*, i32 } %call4, 0
  %tobool.i.i = icmp eq i8* %0, null
  br i1 %tobool.i.i, label %for.cond.cleanup9, label %for.body10.outer

for.body10.outer: ; preds = %if.then.i,
%for.body.lr.ph
  %ph = phi i8* [ %add.ptr.i, %if.then.i ], [ undef, %for.body.lr.ph ]
  br label %for.body10

for.cond.cleanup9:; preds = %for.body.lr.ph
  %call = call zeroext i1 @f6(i8* nonnull undef)
  unreachable

for.body10:   ; preds = %for.body10,
%for.body10.outer
  call void @f1()
  %call.i = call zeroext i1 @f7()
  br i1 %call.i, label %if.then.i, label %for.body10

if.then.i:; preds = %for.body10
  call void @f2(i8* nonnull undef, i8* %ph)
  %add.ptr.i = getelementptr inbounds i8, i8* %ph, i64 undef
  br label %for.body10.outer
}

; Function Attrs: speculative_load_hardening
declare dso_local i1 @f6(i8*) local_unnamed_addr #0

; Function Attrs: speculative_load_hardening
declare dso_local { i8*, i32 } @f4(i8*) local_unnamed_addr #0

; Function Attrs: speculative_load_hardening
declare dso_local i1 @f7() local_unnamed_addr #0

attributes #0 = { speculative_load_hardening }

$ clang++ -O3 -fexperimental-new-pass-manager -c repro.ll
clang++: llvm-project/llvm/lib/Target/X86/X86SpeculativeLoadHardening.cpp:743:
auto (anonymous
namespace)::X86SpeculativeLoadHardeningPass::tracePredStateThroughCFG(llvm::MachineFunction
&, ArrayRef<(anonymous
namespace)::X86SpeculativeLoadHardeningPass::BlockCondInfo>)::(anonymous
class)::operator()(llvm::MachineBasicBlock &, llvm::MachineBasicBlock &, int,
llvm::MachineInstr *, llvm::MachineInstr *&, ArrayRef) const:
Assertion `(InsertPt == CheckingMBB.end() || !InsertPt->isPHI()) && "Should
never have a PHI in the initial checking block as it " "always has a single
predecessor!"' failed.
Stack dump:
0.  Program arguments: clang++ -O3 -fexperimental-new-pass-manager -c
repro.ll 
1.  Code generation
2.  Running pass 'Function Pass Manager' on module 'repro.ll'.
3.  Running pass 'X86 speculative load hardening' on function '@f3'
 #0 0x07f89b17 llvm::sys::PrintStackTrace(llvm::raw_ostream&)
llvm-project/llvm/lib/Support/Unix/Signals.inc:564:11
<...stack unwinder...>
#11 0x068c3f43 (anonymous
namespace)::X86SpeculativeLoadHardeningPass::tracePredStateThroughCFG(llvm::MachineFunction&,
llvm::ArrayRef<(anonymous
namespace)::X86SpeculativeLoadHardeningPass::BlockCondInfo>)::$_5::operator()(llvm::MachineBasicBlock&,
llvm::MachineBasicBlock&, int, llvm::MachineInstr*, llvm::MachineInstr*&,
llvm::ArrayRef) const
l

[llvm-bugs] [Bug 44952] New: Clang doesn't accept default arguments followed by parameter pack

2020-02-18 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=44952

Bug ID: 44952
   Summary: Clang doesn't accept default arguments followed by
parameter pack
   Product: clang
   Version: trunk
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P
 Component: Frontend
  Assignee: unassignedclangb...@nondot.org
  Reporter: aaronpuch...@alice-dsl.net
CC: llvm-bugs@lists.llvm.org, neeil...@live.com,
richard-l...@metafoo.co.uk

Clang emits an error for the following code:

template
int f(int a = 5, Args... args);

int main() {
  return f(1, 2, 3);
}

:2:26: error: missing default argument on parameter 'args'
int f(int a = 5, Args... args);
 ^
:5:10: note: in instantiation of function template specialization
'f' requested here
  return f(1, 2, 3);
 ^

But [dcl.fct.default]p4 says "In a given function declaration, each parameter
subsequent to a parameter with a default argument shall have a default argument
supplied in this or a previous declaration, unless the parameter was expanded
from a parameter pack, or shall be a function parameter pack."

So unless I'm missing something, this should be allowed.

(Reported by pftbest on IRC.)

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

[llvm-bugs] Issue 19132 in oss-fuzz: llvm:clang-fuzzer: Segv on unknown address in clang::CXXRecordDecl::data

2020-02-18 Thread sheriffbot via monorail via llvm-bugs 
Updates:
Labels: Deadline-Approaching

Comment #1 on issue 19132 by sheriffbot: llvm:clang-fuzzer: Segv on unknown 
address in clang::CXXRecordDecl::data
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=19132#c1

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

- Your friendly Sheriffbot

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

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

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

[llvm-bugs] Issue 19136 in oss-fuzz: llvm:clang-fuzzer: Segv on unknown address in clang::Sema::SetCtorInitializers

2020-02-18 Thread sheriffbot via monorail via llvm-bugs 
Updates:
Labels: Deadline-Approaching

Comment #1 on issue 19136 by sheriffbot: llvm:clang-fuzzer: Segv on unknown 
address in clang::Sema::SetCtorInitializers
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=19136#c1

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

- Your friendly Sheriffbot

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

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

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

[llvm-bugs] Issue 19152 in oss-fuzz: llvm:clang-fuzzer: Segv on unknown address in clang::StmtVisitorBase::Visit

2020-02-18 Thread sheriffbot via monorail via llvm-bugs 
Updates:
Labels: Deadline-Approaching

Comment #1 on issue 19152 by sheriffbot: llvm:clang-fuzzer: Segv on unknown 
address in clang::StmtVisitorBase::Visit
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=19152#c1

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

- Your friendly Sheriffbot

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

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

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

[llvm-bugs] [Bug 44953] New: "Declaration may not be in a Comdat" when using D3DX12 headers and PCH files

2020-02-18 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=44953

Bug ID: 44953
   Summary: "Declaration may not be in a Comdat" when using D3DX12
headers and PCH files
   Product: clang
   Version: trunk
  Hardware: PC
OS: Windows NT
Status: NEW
  Severity: enhancement
  Priority: P
 Component: C++11
  Assignee: unassignedclangb...@nondot.org
  Reporter: alexandre.ga...@ubisoft.com
CC: blitzrak...@gmail.com, dgre...@apple.com,
erik.pilking...@gmail.com, h...@chromium.org,
llvm-bugs@lists.llvm.org, richard-l...@metafoo.co.uk,
r...@google.com

When including D3DX12 [1] headers in .PCH headers (/Yc), and using them in TUs
(/Yu), clang-cl fails with the following error:

Declaration may not be in a Comdat!
%struct.CD3DX12_DEFAULT* @"?D3D12_DEFAULT@@3UCD3DX12_DEFAULT@@B"
fatal error: error in backend: Broken module found, compilation
aborted!
Stack dump:
0.  Program arguments: F:\llvm-project\build\bin\clang-cl.exe
/Yuprecomp.h a.cpp /c
1.   parser at end of file
2.  Per-function optimization
 #0 0x7ffa8b5ba839 (C:\WINDOWS\System32\KERNELBASE.dll+0x3a839)
 #1 0x7ff7690e5dda llvm::CrashRecoveryContext::HandleExit(int)
F:\llvm-project\llvm\lib\Support\CrashRecoveryContext.cpp:436:0
 #2 0x7ff769129484 llvm::sys::Process::Exit(int)
F:\llvm-project\llvm\lib\Support\Process.cpp:95:0
 #3 0x7ff7688982c9 LLVMErrorHandler
F:\llvm-project\clang\tools\driver\cc1_main.cpp:73:0
 #4 0x7ff7690e60ea llvm::report_fatal_error(class llvm::Twine const
&, bool) F:\llvm-project\llvm\lib\Support\ErrorHandling.cpp:108:0
 #5 0x7ff7690e6001 llvm::report_fatal_error(char const *, bool)
F:\llvm-project\llvm\lib\Support\ErrorHandling.cpp:83:0
 #6 0x7ff769f2ff38 `anonymous
namespace'::VerifierLegacyPass::doFinalization
F:\llvm-project\llvm\lib\IR\Verifier.cpp:5189:0
 #7 0x7ff768cda3af llvm::FPPassManager::doFinalization(class
llvm::Module &) F:\llvm-project\llvm\lib\IR\LegacyPassManager.cpp:1536:0
 #8 0x7ff768cd96e0
llvm::legacy::FunctionPassManagerImpl::doFinalization(class llvm::Module &)
F:\llvm-project\llvm\lib\IR\LegacyPassManager.cpp:1382:0
 #9 0x7ff76a3d11e1 clang::EmitBackendOutput(class
clang::DiagnosticsEngine &, class clang::HeaderSearchOptions const &, class
clang::CodeGenOptions const &, class clang::TargetOptions const &, class
clang::LangOptions const &, class llvm::DataLayout const &, class llvm::Module
*, enum clang::BackendAction, class std::unique_ptr>)
F:\llvm-project\clang\lib\CodeGen\BackendUtil.cpp:1582:0
#10 0x7ff76a75a4c6
clang::BackendConsumer::HandleTranslationUnit(class clang::ASTContext &)
F:\llvm-project\clang\lib\CodeGen\CodeGenAction.cpp:339:0
#11 0x7ff76c175c43 clang::ParseAST(class clang::Sema &, bool, bool)
F:\llvm-project\clang\lib\Parse\ParseAST.cpp:178:0
#12 0x7ff76a6b2edd clang::FrontendAction::Execute(void)
F:\llvm-project\clang\lib\Frontend\FrontendAction.cpp:944:0
#13 0x7ff76924e70b clang::CompilerInstance::ExecuteAction(class
clang::FrontendAction &)
F:\llvm-project\clang\lib\Frontend\CompilerInstance.cpp:969:0
#14 0x7ff7692b405d clang::ExecuteCompilerInvocation(class
clang::CompilerInstance *)
F:\llvm-project\clang\lib\FrontendTool\ExecuteCompilerInvocation.cpp:292:0
#15 0x7ff768897eda cc1_main(class llvm::ArrayRef,
char const *, void *) F:\llvm-project\clang\tools\driver\cc1_main.cpp:240:0
#16 0x7ff768894f03 ExecuteCC1Tool
F:\llvm-project\clang\tools\driver\driver.cpp:328:0
#17 0x7ff76a4bb536 llvm::function_ref::callback_fn<`lambda
at F:\llvm-project\clang\lib\Driver\Job.cpp:417:22'>
F:\llvm-project\llvm\include\llvm\ADT\STLExtras.h:108:0
#18 0x7ff7690e5c02 llvm::CrashRecoveryContext::RunSafely(class
llvm::function_ref<(void)>)
F:\llvm-project\llvm\lib\Support\CrashRecoveryContext.cpp:228:0
#19 0x7ff76a4bae04 clang::driver::CC1Command::Execute(class
llvm::ArrayRef>, class
std::basic_string, class
std::allocator> *, bool *) const
F:\llvm-project\clang\lib\Driver\Job.cpp:417:0
#20 0x7ff76921411f clang::driver::Compilation::ExecuteCommand(class
clang::driver::Command const &, class clang::driver::Command const *&) const
F:\llvm-project\clang\lib\Driver\Compilation.cpp:182:0
#21 0x7ff769214489 clang::driver::Compilation::ExecuteJobs(class
clang::driver::JobList const &, class llvm::SmallVectorImpl> &) const
F:\llvm-project\clang\lib\Driver\Compilation.cpp:233:0
#22 0x7ff769228ed7 clang::driver::Driver::ExecuteCompilation(class
clang::driver::Compilation &, class llvm::SmallVectorImpl> &)
F:\llvm-project\clang\lib\Driver\Driver.cpp:1479:0
#23 0x7ff76889447e main
F:\llv

[llvm-bugs] [Bug 44922] crash in llvm::JumpThreadingPass::ThreadThroughTwoBasicBlocks with -O2 -fsanitize=object-size

2020-02-18 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=44922

Fangrui Song  changed:

   What|Removed |Added

 Status|CONFIRMED   |RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from Fangrui Song  ---
Fixed by 13a97305ba77f44eccba16087320c8aa016ac6da (D74747)

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

[llvm-bugs] [Bug 44954] New: Crash in SLP Vectorizer

2020-02-18 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=44954

Bug ID: 44954
   Summary: Crash in SLP Vectorizer
   Product: new-bugs
   Version: unspecified
  Hardware: PC
OS: All
Status: NEW
  Severity: enhancement
  Priority: P
 Component: new bugs
  Assignee: unassignedb...@nondot.org
  Reporter: cl...@evan.coeusgroup.com
CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org

Created attachment 23139
  --> https://bugs.llvm.org/attachment.cgi?id=23139&action=edit
clang output, including backtrace

When attempting to compile libaom with emscripten using SIMDe
(), the compiler crashes in the SLP
Vectorizer.  I managed to reduce the test case to a manageable size, and after
reporting it to emscripten
() they said the
bug appears to not to be specific to emscripten and should be reported to LLVM,
so here it is.

You can find the non-preprocessed test case as well as details on how to
reproduce in emscripten (basically, -O2 -s SIMD=1) on the emscripten bug
report, which may be helpful; it's pretty small, and only pulls in stddef.h,
stdint.h, and string.h.

I'll attach the preprocessed source and script generated by clang, as well as
the full clang output (including the backtrace).

Please let me know if you need any additional information.

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

[llvm-bugs] [Bug 44955] New: clang++ 10.0 fails with libstdc++ from gcc 10-20200216

2020-02-18 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=44955

Bug ID: 44955
   Summary: clang++ 10.0 fails with libstdc++ from gcc 10-20200216
   Product: new-bugs
   Version: 10.0
  Hardware: PC
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P
 Component: new bugs
  Assignee: unassignedb...@nondot.org
  Reporter: b...@lindev.ch
CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org

Not 100% sure whether this is a libstdc++ bug or a clang bug. (Also filed a bug
report against libstdc++ at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93818).

Using libstdc++ from gcc 10-20200216 breaks using it with clang 10 in C++20
mode.

/usr/bin/../lib64/gcc/x86_64-openmandriva-linux-gnu/10.0.0/../../../../include/c++/10.0.0/ranges:1329:17:
error: missing 'typename' prior to dependent type name
'iterator_traits >::iterator_category'
  using _Cat = iterator_traits>::iterator_category;
   ^~~
/usr/bin/../lib64/gcc/x86_64-openmandriva-linux-gnu/10.0.0/../../../../include/c++/10.0.0/ranges:1512:47:
error: ambiguous deduction for template arguments of '_RangeAdaptor'
inline constexpr __adaptor::_RangeAdaptor filter
  ^
/usr/bin/../lib64/gcc/x86_64-openmandriva-linux-gnu/10.0.0/../../../../include/c++/10.0.0/ranges:1073:2:
note: candidate function [with _Callable = std::ranges::views::(lambda at
/usr/bin/../lib64/gcc/x86_64-openmandriva-linux-gnu/10.0.0/../../../../include/c++/10.0.0/ranges:1513:9)]
_RangeAdaptor(const _Callable& = {})
^
/usr/bin/../lib64/gcc/x86_64-openmandriva-linux-gnu/10.0.0/../../../../include/c++/10.0.0/ranges:1078:2:
note: candidate function [with _Callable = std::ranges::views::(lambda at
/usr/bin/../lib64/gcc/x86_64-openmandriva-linux-gnu/10.0.0/../../../../include/c++/10.0.0/ranges:1513:9)]
_RangeAdaptor(_Callable __callable)
^
/usr/bin/../lib64/gcc/x86_64-openmandriva-linux-gnu/10.0.0/../../../../include/c++/10.0.0/ranges:1552:19:
error: missing 'typename' prior to dependent type name
'iterator_traits >::iterator_category'
using _Cat = iterator_traits>::iterator_category;
 ^
/usr/bin/../lib64/gcc/x86_64-openmandriva-linux-gnu/10.0.0/../../../../include/c++/10.0.0/ranges:1853:47:
error: ambiguous deduction for template arguments of '_RangeAdaptor'
inline constexpr __adaptor::_RangeAdaptor transform
  ^
/usr/bin/../lib64/gcc/x86_64-openmandriva-linux-gnu/10.0.0/../../../../include/c++/10.0.0/ranges:1073:2:
note: candidate function [with _Callable = std::ranges::views::(lambda at
/usr/bin/../lib64/gcc/x86_64-openmandriva-linux-gnu/10.0.0/../../../../include/c++/10.0.0/ranges:1854:9)]
_RangeAdaptor(const _Callable& = {})
^
/usr/bin/../lib64/gcc/x86_64-openmandriva-linux-gnu/10.0.0/../../../../include/c++/10.0.0/ranges:1078:2:
note: candidate function [with _Callable = std::ranges::views::(lambda at
/usr/bin/../lib64/gcc/x86_64-openmandriva-linux-gnu/10.0.0/../../../../include/c++/10.0.0/ranges:1854:9)]
_RangeAdaptor(_Callable __callable)
^
/usr/bin/../lib64/gcc/x86_64-openmandriva-linux-gnu/10.0.0/../../../../include/c++/10.0.0/ranges:2000:47:
error: ambiguous deduction for template arguments of '_RangeAdaptor'
inline constexpr __adaptor::_RangeAdaptor take
  ^
/usr/bin/../lib64/gcc/x86_64-openmandriva-linux-gnu/10.0.0/../../../../include/c++/10.0.0/ranges:1073:2:
note: candidate function [with _Callable = std::ranges::views::(lambda at
/usr/bin/../lib64/gcc/x86_64-openmandriva-linux-gnu/10.0.0/../../../../include/c++/10.0.0/ranges:2001:9)]
_RangeAdaptor(const _Callable& = {})
^
/usr/bin/../lib64/gcc/x86_64-openmandriva-linux-gnu/10.0.0/../../../../include/c++/10.0.0/ranges:1078:2:
note: candidate function [with _Callable = std::ranges::views::(lambda at
/usr/bin/../lib64/gcc/x86_64-openmandriva-linux-gnu/10.0.0/../../../../include/c++/10.0.0/ranges:2001:9)]
_RangeAdaptor(_Callable __callable)
^
/usr/bin/../lib64/gcc/x86_64-openmandriva-linux-gnu/10.0.0/../../../../include/c++/10.0.0/ranges:2092:47:
error: ambiguous deduction for template arguments of '_RangeAdaptor'
inline constexpr __adaptor::_RangeAdaptor take_while
  ^
/usr/bin/../lib64/gcc/x86_64-openmandriva-linux-gnu/10.0.0/../../../../include/c++/10.0.0/ranges:1073:2:
note: candidate function [with _Callable = std::ranges::views::(lambda at
/usr/bin/../lib64/gcc/x86_64-openmandriva-linux-gnu/10.0.0/../../../../include/c++/10.0.0/ranges:2093:9)]
_RangeAdaptor(const _Callable& = {})
^
/usr/bin/../lib64/gcc/x86_64-openmandriva-linux-gnu/10.0.0/../../../../include/c++/1

[llvm-bugs] [Bug 44956] New: Clang 10.0-r2 includes unsupported headers from msvc >= 16.4 on Windows when in C++2a

2020-02-18 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=44956

Bug ID: 44956
   Summary: Clang 10.0-r2 includes unsupported headers from msvc
>= 16.4 on Windows when in C++2a
   Product: clang
   Version: 10.0
  Hardware: PC
OS: Windows NT
Status: NEW
  Severity: enhancement
  Priority: P
 Component: C++2a
  Assignee: unassignedclangb...@nondot.org
  Reporter: mjkl...@gmail.com
CC: blitzrak...@gmail.com, erik.pilking...@gmail.com,
llvm-bugs@lists.llvm.org, richard-l...@metafoo.co.uk

Context
---

 - `clang` 10.0-r2
 - Windows 10
 - `msvc` 16.4.4/16.4.5/16.5-preview
 - (`build2` v0.12.0 as build system, but it doesn't seem specific; `build2`
will find the latest msvc install on the system to provide it to clang; all the
following commands are extracts from `build2`'s verbose output)

How To Reproduce


main.cxx:
```
#include  // any header potentially including 

int main() {}
```

Execute:
```
clang++ -std=c++2a -D_MT -D_DLL -w -x c++ -MQ ^ -M -MG
"C:\Users\klaim\temp\minimaltest\main.cxx"
```

(or with build2:
buildfile:
```
cxx.std = latest

using cxx

exe{test} : cxx{main}
```

Execute: `b config.cxx=clang++`
)


Observed:
-

```
In file included from C:\Users\klaim\temp\minimaltest\main.cxx:1:
In file included from C:\Program Files (x86)\Microsoft Visual
Studio\2019\Community\VC\Tools\MSVC\14.24.28314\include\utility:15:
C:\Program Files (x86)\Microsoft Visual
Studio\2019\Community\VC\Tools\MSVC\14.24.28314\include\concepts:14:2: error:
Despite the presence of some Clang-related bits, this header currently does not
support
  Clang. You can define _SILENCE_CLANG_CONCEPTS_MESSAGE to silence this
message and acknowledge that this is unsupported.
#error Despite the presence of some Clang-related bits, this header currently
does not support Clang. \
 ^
^: C:\Users\klaim\temp\minimaltest\main.cxx \
  C:\Program\ Files\ (x86)\Microsoft\ Visual\
Studio\2019\Community\VC\Tools\MSVC\14.24.28314\include\utility \
  C:\Program\ Files\ (x86)\Microsoft\ Visual\
Studio\2019\Community\VC\Tools\MSVC\14.24.28314\include\yvals_core.h \
  C:\Program\ Files\ (x86)\Microsoft\ Visual\
Studio\2019\Community\VC\Tools\MSVC\14.24.28314\include\vcruntime.h \
  C:\Program\ Files\ (x86)\Microsoft\ Visual\
Studio\2019\Community\VC\Tools\MSVC\14.24.28314\include\sal.h \
  C:\Program\ Files\ (x86)\Microsoft\ Visual\
Studio\2019\Community\VC\Tools\MSVC\14.24.28314\include\concurrencysal.h \
  C:\Program\ Files\LLVM\lib\clang\10.0.0\include\vadefs.h \
  C:\Program\ Files\ (x86)\Microsoft\ Visual\
Studio\2019\Community\VC\Tools\MSVC\14.24.28314\include\vadefs.h \
  C:\Program\ Files\ (x86)\Microsoft\ Visual\
Studio\2019\Community\VC\Tools\MSVC\14.24.28314\include\xkeycheck.h \
  C:\Program\ Files\ (x86)\Microsoft\ Visual\
Studio\2019\Community\VC\Tools\MSVC\14.24.28314\include\type_traits \
  C:\Program\ Files\ (x86)\Microsoft\ Visual\
Studio\2019\Community\VC\Tools\MSVC\14.24.28314\include\xstddef \
  C:\Program\ Files\ (x86)\Microsoft\ Visual\
Studio\2019\Community\VC\Tools\MSVC\14.24.28314\include\cstddef \
  C:\Program\ Files\LLVM\lib\clang\10.0.0\include\stddef.h \
  C:\Program\ Files\LLVM\lib\clang\10.0.0\include\__stddef_max_align_t.h \
  C:\Program\ Files\ (x86)\Microsoft\ Visual\
Studio\2019\Community\VC\Tools\MSVC\14.24.28314\include\xtr1common \
  C:\Program\ Files\ (x86)\Microsoft\ Visual\
Studio\2019\Community\VC\Tools\MSVC\14.24.28314\include\cstdlib \
  C:\Program\ Files\ (x86)\Windows\ Kits\10\Include\10.0.17763.0\ucrt\math.h \
  C:\Program\ Files\ (x86)\Windows\
Kits\10\Include\10.0.17763.0\ucrt\corecrt_math.h \
  C:\Program\ Files\ (x86)\Windows\ Kits\10\Include\10.0.17763.0\ucrt\corecrt.h
\
  C:\Program\ Files\ (x86)\Windows\ Kits\10\Include\10.0.17763.0\ucrt\stdlib.h
\
  C:\Program\ Files\ (x86)\Windows\
Kits\10\Include\10.0.17763.0\ucrt\corecrt_malloc.h \
  C:\Program\ Files\ (x86)\Windows\
Kits\10\Include\10.0.17763.0\ucrt\corecrt_search.h \
  C:\Program\ Files\ (x86)\Windows\
Kits\10\Include\10.0.17763.0\ucrt\corecrt_wstdlib.h \
  C:\Program\ Files\LLVM\lib\clang\10.0.0\include\limits.h \
  C:\Program\ Files\ (x86)\Microsoft\ Visual\
Studio\2019\Community\VC\Tools\MSVC\14.24.28314\include\limits.h \
  C:\Program\ Files\ (x86)\Microsoft\ Visual\
Studio\2019\Community\VC\Tools\MSVC\14.24.28314\include\initializer_list \
  C:\Program\ Files\ (x86)\Microsoft\ Visual\
Studio\2019\Community\VC\Tools\MSVC\14.24.28314\include\concepts
1 error generated.
```

Expected


To compile successfully, in the same way clang 9.0.1 compiles successfully in
the same context.

Observations


1. As mentionned, switching clang to 9.0.1 removes the issue.
2. The issue appears only with `-std=c++2a`, not with `-std=1z` (C++17)
3. Looking at `` line 15 we can see:

-- 
You are receiving this mail because:
You are on the CC list for the bu

[llvm-bugs] [Bug 44957] New: Option to randomly shuffle instructions during compilation

2020-02-18 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=44957

Bug ID: 44957
   Summary: Option to randomly shuffle instructions during
compilation
   Product: clang
   Version: unspecified
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P
 Component: C++
  Assignee: unassignedclangb...@nondot.org
  Reporter: iuri.ch...@gmail.com
CC: blitzrak...@gmail.com, dgre...@apple.com,
erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org,
richard-l...@metafoo.co.uk

I would like to fuzz my lock-free code to improve my confidence in its
correctness. For that, it would be truly awesome if the compiler offered an
option like:
-shuffle-instruction-order=

The idea is akin to fuzzing: instructions would be randomly shuffled in legal
ways during the optimization phase. The idea is to bruteforce hidden undefined
behavior out of lock-free code, it could help answer questions like "do I have
all the barriers I need?", and "are my transactions well-defined?".

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

[llvm-bugs] [Bug 44954] Crash in SLP Vectorizer

2020-02-18 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=44954

Florian Hahn  changed:

   What|Removed |Added

   See Also||https://bugs.llvm.org/show_
   ||bug.cgi?id=44950
 Status|CONFIRMED   |RESOLVED
 Fixed By Commit(s)||e32522ca178a
 Resolution|--- |FIXED

--- Comment #5 from Florian Hahn  ---
Looks like this has been fixed by https://reviews.llvm.org/rGe32522ca178a

I've also proposed to cherry-pick this patch on the 10.0 release branch:
https://bugs.llvm.org/show_bug.cgi?id=44950

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

[llvm-bugs] [Bug 44958] New: Struct with a mutable member can't be used in constant expression even when the member isn't accessed

2020-02-18 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=44958

Bug ID: 44958
   Summary: Struct with a mutable member can't be used in constant
expression even when the member isn't accessed
   Product: clang
   Version: trunk
  Hardware: PC
OS: All
Status: NEW
  Severity: enhancement
  Priority: P
 Component: C++2a
  Assignee: unassignedclangb...@nondot.org
  Reporter: ldio...@apple.com
CC: blitzrak...@gmail.com, erik.pilking...@gmail.com,
llvm-bugs@lists.llvm.org, richard-l...@metafoo.co.uk

The following code doesn't compile because it claims that a read from the
mutable member `i` is performed when calling `.size()`, but this seems wrong:

$ cat <
struct array {
T data_[N];
constexpr long size() const { return N; }
};
struct T { mutable int i; };
constexpr array a = {T{3}};
static_assert(a.size());
EOF

Also, GCC compiles this fine. Godbolt link: https://godbolt.org/z/LPrhxh

The error is:

:8:15: error: static_assert expression is not an integral constant
expression
static_assert(a.size());
  ^~~~
:8:17: note: member call on mutable member 'i' is not allowed in a
constant expression
static_assert(a.size());
^
:6:24: note: declared here
struct T { mutable int i; };
   ^
1 error generated.


We seem to be hitting this diagnostic specifically;

   
https://github.com/llvm/llvm-project/blob/47282b1b4/clang/lib/AST/ExprConstant.cpp#L3061

However, this seems wrong because we're not doing a lvalue-to-rvalue conversion
anywhere AFAICT. This failure seems to have started with:

commit 2b4fa5348ee157b6b1a1af44d0137ca8c7a71573
Author: Richard Smith 
Date:   Sun Sep 29 05:08:46 2019 +

For P0784R7: compute whether a variable has constant destruction if it
has a constexpr destructor.

For constexpr variables, reject if the variable does not have constant
destruction. In all cases, do not emit runtime calls to the destructor
for variables with constant destruction.

llvm-svn: 373159

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

[llvm-bugs] [Bug 44959] New: Concept causes infinite loops at compile time (-Wstack-exhausted)

2020-02-18 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=44959

Bug ID: 44959
   Summary: Concept causes infinite loops at compile time
(-Wstack-exhausted)
   Product: clang
   Version: trunk
  Hardware: PC
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P
 Component: C++2a
  Assignee: unassignedclangb...@nondot.org
  Reporter: l...@marehr.dialup.fu-berlin.de
CC: blitzrak...@gmail.com, erik.pilking...@gmail.com,
llvm-bugs@lists.llvm.org, richard-l...@metafoo.co.uk

The following code should compile:

```c++
#include 

template 
concept semialphabet = requires(T const &t, T const &u) {t == u;};

template 
concept always_false = false;

template  struct alphabet_base {
  friend bool operator==(derived_type, derived_type) { return false; };
};

template 
struct semialphabet_any : alphabet_base, size> {
  template  && semialphabet>>
  operator other_alph_t();
};

template 
struct aminoacid_base : public alphabet_base {
  template  && semialphabet>>
  aminoacid_base(other_aa_type);
};

struct aa10li : public aminoacid_base {
  using base_t = aminoacid_base;
  using base_t::base_t;
};

semialphabet_any<10> letter0;

static_assert(!std::is_convertible_v, aa10li>);
```

I would expect that the expression `always_false &&
semialphabet` evaluates from left to right and sees that this
expression is the same as `false && semialphabet` and thus does
not evaluate `semialphabet`. If I define `semialphabet` via
SFINAE instead of concepts short-circuiting works.


https://godbolt.org/z/KBgLpi

Error message:

```
:14:8: warning: stack nearly exhausted; compilation time may suffer,
and crashes due to stack overflow are likely [-Wstack-exhausted]

struct semialphabet_any : alphabet_base, size> {
   ^
:4:58: note: in instantiation of requirement here
concept semialphabet = requires(T const &t, T const &u) {t == u;};
 ^~
:4:24: note: while substituting template arguments into constraint
expression here
concept semialphabet = requires(T const &t, T const &u) {t == u;};
   ^~
:15:94: note: while checking the satisfaction of concept
'semialphabet >' requested here
  template  && semialphabet>>
   
 ^~
:16:3: note: in instantiation of default argument for 'operator
type-parameter-0-0 >' required here
  operator other_alph_t();
  ^~~
:4:58: note: while substituting deduced template arguments into
function template 'operator type-parameter-0-0' [with other_alph_t =
semialphabet_any<10>, $1 = (no value)]
concept semialphabet = requires(T const &t, T const &u) {t == u;};
 ^
:4:58: note: (skipping 1516 contexts in backtrace; use
-ftemplate-backtrace-limit=0 to see all)
/opt/compiler-explorer/gcc-9.2.0/lib/gcc/x86_64-linux-gnu/9.2.0/../../../../include/c++/9.2.0/type_traits:1322:2:
note: in instantiation of default argument for '__test,
aa10li>' required here
__test(int);
^~~
/opt/compiler-explorer/gcc-9.2.0/lib/gcc/x86_64-linux-gnu/9.2.0/../../../../include/c++/9.2.0/type_traits:1329:24:
note: while substituting deduced template arguments into function template
'__test' [with _From1 = semialphabet_any<10>, _To1 = aa10li, $2 = (no value)]
  typedef decltype(__test<_From, _To>(0)) type;
   ^
/opt/compiler-explorer/gcc-9.2.0/lib/gcc/x86_64-linux-gnu/9.2.0/../../../../include/c++/9.2.0/type_traits:1336:14:
note: in instantiation of template class
'std::__is_convertible_helper, aa10li, false>' requested
here
: public __is_convertible_helper<_From, _To>::type
 ^
/opt/compiler-explorer/gcc-9.2.0/lib/gcc/x86_64-linux-gnu/9.2.0/../../../../include/c++/9.2.0/type_traits:2964:44:
note: in instantiation of template class
'std::is_convertible, aa10li>' requested here
  inline constexpr bool is_convertible_v = is_convertible<_From, _To>::value;
   ^
:32:21: note: in instantiation of variable template specialization
'std::is_convertible_v, aa10li>' requested here
static_assert(!std::is_convertible_v, aa10li>);
^
Compiler returned: 255
```

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

[llvm-bugs] [Bug 44960] New: Assertion `E->isRValue() && "missing lvalue-to-rvalue conv in bool condition"

2020-02-18 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=44960

Bug ID: 44960
   Summary: Assertion `E->isRValue() && "missing lvalue-to-rvalue
conv in bool condition"
   Product: new-bugs
   Version: 10.0
  Hardware: PC
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P
 Component: new bugs
  Assignee: unassignedb...@nondot.org
  Reporter: b...@lindev.ch
CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org

Created attachment 23143
  --> https://bugs.llvm.org/attachment.cgi?id=23143&action=edit
Reduced test case

Trying to build the attached piece of code (extracted from gjs) with clang++
10.0-rc2 results in an assertion failure.

The attached code is already reduced (but creduce messed it up slightly because
it crashed with the same assertion error -- not a surprise given it uses LLVM
libraries).

$ clang++ -o bug.o bug.cpp
bug.cpp:1:20: error: C++ requires a type specifier for all declarations
template  b() {
   ^
bug.cpp:6:25: error: expected ';' after expression
   d d
^
;   
bug.cpp:6:24: warning: expression result unused [-Wunused-value]
   d d
   ^
bug.cpp:6:27: error: expected ';' after expression
   d d
  ^
  ; 
bug.cpp:8:22: error: expected ';' after expression
   1)
 ^
 ;  
bug.cpp:3:3: warning: ignoring return value of function declared with const
attribute [-Wunused-value]
  __builtin_expect(({
  ^~~~ ~~
clang-10:
/builddir/build/BUILD/llvm-project-release-10.x/clang/lib/AST/ExprConstant.cpp:2326:
bool EvaluateAsBooleanCondition(const clang::Expr *, bool &, (anonymous
namespace)::EvalInfo &): Assertion `E->isRValue() && "missing lvalue-to-rvalue
conv in bool condition"' failed.
Stack dump:
0.  Program arguments: /usr/bin/clang-10 -cc1 -triple x86_64-pc-linux-gnu
-emit-obj -mrelax-all -disable-free -main-file-name bug.cpp -mrelocation-model
static -mthread-model posix -mframe-pointer=all -fmath-errno -fno-rounding-math
-masm-verbose -mconstructor-aliases -munwind-tables -target-cpu x86-64
-dwarf-column-info -fno-split-dwarf-inlining -debugger-tuning=gdb -resource-dir
/usr/lib64/clang/10.0.0 -internal-isystem
/usr/bin/../lib64/gcc/x86_64-openmandriva-linux-gnu/10.0.0/../../../../include/c++/10.0.0
-internal-isystem
/usr/bin/../lib64/gcc/x86_64-openmandriva-linux-gnu/10.0.0/../../../../include/c++/10.0.0/x86_64-openmandriva-linux-gnu
-internal-isystem
/usr/bin/../lib64/gcc/x86_64-openmandriva-linux-gnu/10.0.0/../../../../include/c++/10.0.0/backward
-internal-isystem /usr/local/include -internal-isystem
/usr/lib64/clang/10.0.0/include -internal-externc-isystem /include
-internal-externc-isystem /usr/include -fdeprecated-macro
-fdebug-compilation-dir /home/bero/temp/abf/gjs/BUILD/gjs-1.58.5 -ferror-limit
19 -fmessage-length 0 -fgnuc-version=4.2.1 -fobjc-runtime=gcc -fcxx-exceptions
-fexceptions -fdiagnostics-show-option -fcolor-diagnostics -faddrsig -o
/tmp/bug-18832a.o -x c++ bug.cpp 
1.   parser at end of file
2.  bug.cpp:1:24: parsing function body 'b'
3.  bug.cpp:1:24: in compound statement ('{}')
 #0 0x7f9853752f02 (/usr/lib64/libLLVMSupport.so.10.0+0x21bf02)
 #1 0x7f98537504ae llvm::sys::RunSignalHandlers()
(/usr/lib64/libLLVMSupport.so.10.0+0x2194ae)
 #2 0x7f9853753128 (/usr/lib64/libLLVMSupport.so.10.0+0x21c128)
 #3 0x7f98531ad980 __restore_rt (/lib64/libc.so.6+0x44980)
 #4 0x7f98531ad8f7 raise (/lib64/libc.so.6+0x448f7)
 #5 0x7f985318e53d abort (/lib64/libc.so.6+0x2553d)
 #6 0x7f985318e411 _nl_load_domain.cold (/lib64/libc.so.6+0x25411)
 #7 0x7f985319e912 (/lib64/libc.so.6+0x35912)
 #8 0x7f9851ef71c9 (/usr/lib64/libclangAST.so.10.0+0x5201c9)
 #9 0x7f9851f04ae4 (/usr/lib64/libclangAST.so.10.0+0x52dae4)
#10 0x7f9851f11565 (/usr/lib64/libclangAST.so.10.0+0x53a565)
#11 0x7f9851ed8a3b (/usr/lib64/libclangAST.so.10.0+0x501a3b)
#12 0x7f9851edba67 (/usr/lib64/libclangAST.so.10.0+0x504a67)
#13 0x7f9851ed6ba9 clang::Expr::EvaluateAsRValue(clang::Expr::EvalResult&,
clang::ASTContext const&, bool) const (/usr/lib64/libclangAST.so.10.0+0x4ffba9)
#14 0x7f9850d2e72b (/usr/lib64/libclangSema.so.10.0+0x3d672b)
#15 0x7f9850d280b6 (/usr/lib64/libclangSema.so.10.0+0x3d00b6)
#16 0x7f9850d19096 (/usr/lib64/libclangSema.so.10.0+0x3c1096)
#17 0x7f9850d19b63 (/usr/lib64/libclangSema.so.10.0+0x3c1b63)
#18 0x7f9850d1a79a clang::Sema::CheckCompletedExpr(clang::Expr*,
clang::SourceLocation, bool) (/usr/lib64/libclangSema.so.10.0+0x3c279a)
#19 0x7f98510ac019 clang::Sema::ActO

[llvm-bugs] [Bug 44958] Struct with a mutable member can't be used in constant expression even when the member isn't accessed

2020-02-18 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=44958

Richard Smith  changed:

   What|Removed |Added

 Fixed By Commit(s)||llvmorg-11-init-3580-ge28d9
   ||bae4b3
 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Severity|enhancement |normal

--- Comment #1 from Richard Smith  ---
Thanks, fixed.

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

[llvm-bugs] [Bug 44934] frame pointer should be omitted for -pg -mfentry

2020-02-18 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=44934

Nick Desaulniers  changed:

   What|Removed |Added

 Blocks||4068
 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from Nick Desaulniers  ---
https://reviews.llvm.org/rG8b9cb120812449dbe67d2252ebf619c4c9cac816


Referenced Bugs:

https://bugs.llvm.org/show_bug.cgi?id=4068
[Bug 4068] [Meta] Compiling the Linux kernel with clang
-- 
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs

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

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

Bug 44934 Summary: frame pointer should be omitted for -pg -mfentry
https://bugs.llvm.org/show_bug.cgi?id=44934

   What|Removed |Added

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

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

[llvm-bugs] Issue 20780 in oss-fuzz: llvm:clang-fuzzer: ASSERT: !isIncompleteType() && "This doesn't make sense for incomplete types"

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

New issue 20780 by ClusterFuzz-External: llvm:clang-fuzzer: ASSERT: 
!isIncompleteType() && "This doesn't make sense for incomplete types"
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=20780

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

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

Crash Type: ASSERT
Crash Address: 
Crash State:
  !isIncompleteType() && "This doesn't make sense for incomplete types"
  clang::Type::isConstantSizeType
  HandleSizeof
  
Sanitizer: address (ASAN)

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

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

Issue filed automatically.

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

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

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

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

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

[llvm-bugs] [Bug 41627] SDAG tries to legalize token and aborts

2020-02-18 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=41627

Brian Gesiak  changed:

   What|Removed |Added

   Assignee|unassignedb...@nondot.org   |modoca...@gmail.com
 Status|NEW |RESOLVED
 CC||modoca...@gmail.com
 Resolution|--- |FIXED

--- Comment #1 from Brian Gesiak  ---
The stack of diffs ending with https://reviews.llvm.org/D71903 should resolve
this issue, insofar as Clang no longer produces IR that isn't then lowered by
the LLVM coroutine passes it also schedules, even when using the new pass
manager.

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

[llvm-bugs] [Bug 42867] fatal error: error in backend: Cannot select: intrinsic %llvm.coro.resume when enabling the new pass manager

2020-02-18 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=42867

Brian Gesiak  changed:

   What|Removed |Added

   Assignee|unassignedb...@nondot.org   |modoca...@gmail.com
 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #2 from Brian Gesiak  ---
The stack of diffs ending with https://reviews.llvm.org/D71903 ports the C++20
aspects of the LLVM coroutine passes to classes compatible with the new pass
manager (it doesn't yet support Swift's "returned continuation" coroutines),
which should resolve this issue in LLVM trunk (and these will most likely be
included in the LLVM 11 release).

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

[llvm-bugs] [Bug 32462] llvm-nm doesn't handle STT_GNU_IFUNC

2020-02-18 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=32462

Fangrui Song  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||i...@maskray.me
 Resolution|--- |FIXED

--- Comment #1 from Fangrui Song  ---
Fixed by https://reviews.llvm.org/D71803
ba1cdba4c48cfee5e400e103af8353f4901ecb9a (will be included by LLVM 10.0.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
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs

[llvm-bugs] [Bug 31850] Revisit how we handle conflicts with section symbols

2020-02-18 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=31850

Fangrui Song  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED
 CC||i...@maskray.me

--- Comment #1 from Fangrui Song  ---
Fixed by https://reviews.llvm.org/D30235

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