[llvm-bugs] [Bug 36186] New: False negatives for -Wconstant-conversion in enums

[via llvm-bugs]

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

Bug ID: 36186
   Summary: False negatives for -Wconstant-conversion in enums
   Product: clang
   Version: trunk
  Hardware: PC
OS: All
Status: NEW
  Severity: enhancement
  Priority: P
 Component: C++
  Assignee: unassignedclangb...@nondot.org
  Reporter: smee...@fb.com
CC: compn...@compnerd.org, dgre...@apple.com,
llvm-bugs@lists.llvm.org, richard-l...@metafoo.co.uk

% cat enum.cpp
enum { A = 128 };
void f(signed char);
void g() { f(A); }
% clang -target x86_64-linux -fsyntax-only -Wconstant-conversion enum.cpp

The implicit conversion from the enumeration type (which should be an unsigned
8 bit type) to the function parameter (a signed 8 bit type) causes a value
change from 128 to -128, but -Wconstant-conversion doesn't catch that. Upping
the enumeration value to anything above 255 shows the expected diagnostic.

-- 
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 36185] New: clang 3.8.1-24+rpi1 fails to compile Yosys on Raspbian Stretch (Raspberry Pi Zero v1.3)

[via llvm-bugs]

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

Bug ID: 36185
   Summary: clang 3.8.1-24+rpi1 fails to compile Yosys on Raspbian
Stretch (Raspberry Pi Zero v1.3)
   Product: clang
   Version: 3.8
  Hardware: Other
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P
 Component: -New Bugs
  Assignee: unassignedclangb...@nondot.org
  Reporter: paul.han...@colorado.edu
CC: llvm-bugs@lists.llvm.org

Created attachment 19789
  --> https://bugs.llvm.org/attachment.cgi?id=19789=edit
Error message

Yosys (https://github.com/YosysHQ/yosys) fails to build on a Raspberry Pi
(armv6--linux-gnueabihf).

The file which clang requested be attached, eval-c49a8b.cpp, is 5MB, so it and
all other versioning information can be found here:
https://github.com/phansel/yosys-clang-error

-- 
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 36184] New: Regression: Segfault in LICM after upgrading to 6.0.0

[via llvm-bugs]

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

Bug ID: 36184
   Summary: Regression: Segfault in LICM after upgrading to 6.0.0
   Product: libraries
   Version: trunk
  Hardware: PC
OS: Windows NT
Status: NEW
  Severity: enhancement
  Priority: P
 Component: Scalar Optimizations
  Assignee: unassignedb...@nondot.org
  Reporter: a...@crichton.co
CC: llvm-bugs@lists.llvm.org

Created attachment 19788
  --> https://bugs.llvm.org/attachment.cgi?id=19788=edit
crashing bytecode

We've *almost* upgraded to LLVM 6 in rust-lang/rust [1] but we seem to have hit
what is hopefully our last blocker, a segfault when optimizing IR on MSVC. The
attached IR will non-deterministically segfault in `opt` during the LICM
passes. I've reproduced this with:

for i in `seq 1 1000`; do
echo $i
opt -O2 -o /dev/null foo.ll || break
done

Sometimes it takes up to 100 runs to crash, but I've been able to crash on a
debug and a release build of LLVM, both on Linux and on Windows.

[1]: https://github.com/rust-lang/rust/pull/47828

-- 
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 36181] Microsoft mangling cannot mangle injected class name type

[via llvm-bugs]

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

Richard Smith  changed:

   What|Removed |Added

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

--- Comment #2 from Richard Smith  ---
Fixed in r323935.

-- 
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 36183] New: Invoke a Function Pass in clang getting: `use_empty() && Uses remain when value is destriyed!"', function ~Value

[via llvm-bugs]

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

Bug ID: 36183
   Summary: Invoke a Function Pass in clang getting: `use_empty()
&& Uses remain when value is destriyed!"', function
~Value
   Product: clang
   Version: trunk
  Hardware: PC
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P
 Component: -New Bugs
  Assignee: unassignedclangb...@nondot.org
  Reporter: golamka...@temple.edu
CC: llvm-bugs@lists.llvm.org

Created attachment 19784
  --> https://bugs.llvm.org/attachment.cgi?id=19784=edit
LLVM IR file

Hi, 
I build LLVM from the trunk on 30 January 2018. 
I write a simple function pass try to instrument a thread-local global
variable. And the value of the variable before instruction.

To build the pass, I put my pass folder under /lib/Transform and
made the necessary changes in the CMakeList file

When I try to invoke the pass using "opt" like below:

clang -O0 -emit-llvm test.c -c -o test_unoptimized.bc
opt -load $OBJ_ROOT/lib/SimplePass.so -instrument < test_unoptimized.bc >
test_unoptimized_new.bc
clang -g test_unoptimized_new.bc -o test_unoptimized_new

It works fine. But whenever I tried to invoke the pass without the involvement
of
like below:
clang  -Xclang -load -Xclang $LIB/SimplePass.so -O0 s  test.c -o test

I got the "use_empty()" error.

My pass looks like below:


#include "llvm/IR/Function.h"
#include "llvm/IR/LegacyPassManager.h"
#include "llvm/Pass.h"
#include "llvm/Support/raw_ostream.h"
#include "llvm/Transforms/IPO/PassManagerBuilder.h"
#include "llvm/IR/Constants.h"
#include "llvm/IR/IRBuilder.h"
#include "llvm/IR/Instructions.h"
#include "llvm/IR/LLVMContext.h"
#include "llvm/IR/Module.h"
#include 
#include 

using namespace llvm;

namespace {
struct SimplePass : public FunctionPass {
public:
  static char ID;
  SimplePass() : FunctionPass(ID) {}

  virtual bool runOnFunction(Function ) {
static LLVMContext ctx;

Module *parentModule = F.getParent();
GlobalVariable *gPCC;
Type *Int32Type = IntegerType::getInt32Ty(ctx);

BasicBlock  = F.getEntryBlock();
Instruction *instPt = ();
IRBuilder<> B(instPt);
LoadInst *LI;

Constant *value;

Constant *zero = ConstantInt::get(Int32Type, (uint64_t)0, false);
unsigned int callsite_index = 0;

if (!parentModule->getGlobalVariable("t_pcc")) {
  gPCC = new GlobalVariable(
*parentModule,
Int32Type,
false,
GlobalValue::CommonLinkage,
zero,
"t_pcc",
0,
GlobalVariable::InitialExecTLSModel);
gPCC->setAlignment(4);
} else {
  gPCC = parentModule->getGlobalVariable("t_pcc");
}

LI = B.CreateLoad(gPCC);

for (auto  : F) {
  for (auto  : BB) {
callsite_index++;
if (auto *callInst = dyn_cast()) {

  IRBuilder<> callSiteBuilder(callInst);

  value = ConstantInt::get(Int32Type, 10);

  callSiteBuilder.CreateStore(value, gPCC);
}
  }
}
errs() << "Instrumented Function: " << F.getName() << "\n";
return true;
  }

};
} // namespace

char SimplePass::ID = 0;


namespace{
static RegisterPass X("instrument", "Instrumentaion Pass", false,
false);
}

static void registerPCCSimple(const PassManagerBuilder &,
 legacy::PassManagerBase ) {
  PM.add(new SimplePass());
}
static RegisterStandardPasses
RegisterMyPass(PassManagerBuilder::EP_EarlyAsPossible,
   registerPCCSimple);




//End of the pass

I am attaching my pass and my LLVM IR(.i) file.
Thanks.

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

[llvm-bugs] [Bug 36182] New: [X86] KTEST instruction emitted for signed comparisons despite it always clearing S flag

[via llvm-bugs]

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

Bug ID: 36182
   Summary: [X86] KTEST instruction emitted for signed comparisons
despite it always clearing S flag
   Product: libraries
   Version: trunk
  Hardware: PC
OS: Windows NT
Status: NEW
  Severity: enhancement
  Priority: P
 Component: Backend: X86
  Assignee: unassignedb...@nondot.org
  Reporter: craig.top...@gmail.com
CC: llvm-bugs@lists.llvm.org

declare void @foo()

define void @bar(<16 x i32> %x, <16 x i32> %y) {
  %a = icmp eq <16 x i32> %x, zeroinitializer
  %b = icmp eq <16 x i32> %y, zeroinitializer
  %c = and <16 x i1> %a, %b
  %d = bitcast <16 x i1> %c to i16
  %e = icmp slt i16 %d, 0
  br i1 %e, label %end, label %call
call:
  call void @foo()
  br label %end
end:
  ret void
}






This IR

Produces this assembly

bar:# @bar
.cfi_startproc
# %bb.0:
pushq   %rax
.cfi_def_cfa_offset 16
vporq   %zmm1, %zmm0, %zmm0
vptestnmd   %zmm0, %zmm0, %k0
ktestw  %k0, %k0
js  .LBB0_2
# %bb.1:# %call
vzeroupper
callq   foo
.LBB0_2:# %end
popq%rax
vzeroupper
retq
.Lfunc_end0:
.size   bar, .Lfunc_end0-bar
.cfi_endproc
# -- End function


Which is broken because KTEST always 0s the S flag.

-- 
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 36181] New: Microsoft mangling cannot mangle injected class name type

[via llvm-bugs]

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

Bug ID: 36181
   Summary: Microsoft mangling cannot mangle injected class name
type
   Product: clang
   Version: trunk
  Hardware: PC
OS: All
Status: NEW
  Severity: enhancement
  Priority: P
 Component: C++
  Assignee: unassignedclangb...@nondot.org
  Reporter: smee...@fb.com
CC: compn...@compnerd.org, david.majne...@gmail.com,
dgre...@apple.com, llvm-bugs@lists.llvm.org,
r...@google.com

Using the reduced test case from https://bugs.llvm.org/show_bug.cgi?id=16887 (I
independently arrived at an almost equivalent reduced test case before finding
that one, sigh):

% cat reduced.h
template  struct A {
  friend void f(A) {}
};
void g() { f(A()); }

% touch empty.cpp
% clang -cc1 -triple x86_64-windows-msvc -emit-pch -o reduced.h.pch -x
c++-header reduced.h
% clang -cc1 -triple x86_64-windows-msvc -emit-llvm -include-pch reduced.h.pch
empty.cpp
Cannot mangle injected class name type.
UNREACHABLE executed

https://reviews.llvm.org/rL188536 changed this from an error to an unreachable.
It should indeed be unreachable for -fdelayed-template-parsing (and running
both of the above clang invocations with -fdelayed-template-parsing doesn't
crash), but it is reachable otherwise.

This is the same underlying issue as
https://bugs.llvm.org/show_bug.cgi?id=35473 and
https://bugs.llvm.org/show_bug.cgi?id=35939. I'm reporting this separately
because this is triggered with a precompiled header vs. modules, and there's a
reduced standalone test case.

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

[llvm-bugs] [Bug 32482] clang 5.0.0 (trunk 299152) crash if compile with -mms-bitfields and pack 1

[via llvm-bugs]

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

Alex Lorenz  changed:

   What|Removed |Added

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

--- Comment #5 from Alex Lorenz  ---
Fixed in r323921

-- 
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 36121] clang crashes at -O3: Running pass 'Combine pattern based expressions'

[via llvm-bugs]

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

Amjad Aboud  changed:

   What|Removed |Added

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

--- Comment #3 from Amjad Aboud  ---
Fixed at https://reviews.llvm.org/rL323926

-- 
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 31146] Clang Crash on malformed input

[via llvm-bugs]

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

Matt Davis  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||matthew.da...@sony.com
 Resolution|--- |FIXED

--- Comment #2 from Matt Davis  ---
I am closing this bug out, as it no longer crashes the frontend.  I was unable
to find the exact commit at which fixed this issue, but have a feeling it is
loosely related to PR24658 and PR25117.  The latter produces a similar stack
trace as to what this PR would produce.

-- 
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 36180] New: [x86] scalar FP code runs ~15% slower on Haswell when compiled with -mavx

[via llvm-bugs]

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

Bug ID: 36180
   Summary: [x86] scalar FP code runs ~15% slower on Haswell when
compiled with -mavx
   Product: libraries
   Version: trunk
  Hardware: PC
OS: All
Status: NEW
  Severity: enhancement
  Priority: P
 Component: Backend: X86
  Assignee: unassignedb...@nondot.org
  Reporter: spatel+l...@rotateright.com
CC: llvm-bugs@lists.llvm.org

Created attachment 19783
  --> https://bugs.llvm.org/attachment.cgi?id=19783=edit
himeno.c source file

I have a Haswell perf mystery that I can't explain. The himeno program (see
attachment) is an FP and memory benchmark that plows through large
multi-dimensional arrays doing 32-bit fadd/fsub/fmul.

To eliminate potentially questionable transforms and variation from the
vectorizers, build it as scalar-ops only like this:

$ ./clang -O2 himeno.c -fno-vectorize -fno-slp-vectorize  -o himeno_novec_sse
$ ./clang -O2 himeno.c -fno-vectorize -fno-slp-vectorize -mavx -o
himeno_novec_avx

And I'm testing on a 4.0GHz Haswell iMac running macOS 10.13.3:

$ ./himeno_novec_sse
mimax = 257 mjmax = 129 mkmax = 129
imax = 256 jmax = 128 kmax =128
cpu : 13.244777 sec.
Loop executed for 500 times
Gosa : 9.897132e-04 
MFLOPS measured : 5175.818966
Score based on MMX Pentium 200MHz : 160.391043

$ ./himeno_novec_avx
mimax = 257 mjmax = 129 mkmax = 129
imax = 256 jmax = 128 kmax =128
cpu : 15.533612 sec.
Loop executed for 500 times
Gosa : 9.897132e-04 
MFLOPS measured : 4413.176279
Score based on MMX Pentium 200MHz : 136.757864

There's an unfortunate amount of noise (~5%) in the perf on this system with
this benchmark, but these results are reproducible. I'm consistently seeing
~15% better perf with the non-AVX build.

If we look at the inner loop asm, they are virtually identical in terms of
operations. The SSE code just has a few extra instructions needed to copy
values because of the destructive ops, but the loads, stores, and math are the
same.

A IACA analysis of these loops says they should have virtually the same
throughput on HSW:

Block Throughput: 20.89 Cycles   Throughput Bottleneck: Backend
Loop Count:  22
Port Binding In Cycles Per Iteration:
--
|  Port  |   0   -  DV   |   1   |   2   -  D|   3   -  D|   4   |   5 
 |   6   |   7   |
--
| Cycles | 13.0 0.0  | 21.0  | 12.012.0  | 12.011.0  |  1.0  |  2.0
 |  2.0  |  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
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs

[llvm-bugs] [Bug 36179] New: Merge r323909 into the 6.0 branch : AMDGPU: Fold inline offset for loads properly in moveToVALU on GFX9

[via llvm-bugs]

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

Bug ID: 36179
   Summary: Merge r323909 into the 6.0 branch : AMDGPU: Fold
inline offset for loads properly in moveToVALU on GFX9
   Product: new-bugs
   Version: 6.0
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P
 Component: new bugs
  Assignee: unassignedb...@nondot.org
  Reporter: mar...@gmail.com
CC: llvm-bugs@lists.llvm.org
Blocks: 35804

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


Referenced Bugs:

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

[llvm-bugs] [Bug 36178] New: Merge r323908 into the 6.0 branch : AMDGPU: Add intrinsics llvm.amdgcn.cvt.{pknorm.i16, pknorm.u16, pk.i16, pk.u16}

[via llvm-bugs]

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

Bug ID: 36178
   Summary: Merge r323908 into the 6.0 branch : AMDGPU: Add
intrinsics llvm.amdgcn.cvt.{pknorm.i16, pknorm.u16,
pk.i16, pk.u16}
   Product: new-bugs
   Version: 6.0
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P
 Component: new bugs
  Assignee: unassignedb...@nondot.org
  Reporter: mar...@gmail.com
CC: llvm-bugs@lists.llvm.org
Blocks: 35804

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


Referenced Bugs:

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

[llvm-bugs] [Bug 36177] New: Merge r323913 into the 6.0 branch : [SeparateConstOffsetFromGEP] Fix up addrspace in the AMDGPU test

[via llvm-bugs]

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

Bug ID: 36177
   Summary: Merge r323913 into the 6.0 branch :
[SeparateConstOffsetFromGEP] Fix up addrspace in the
AMDGPU test
   Product: new-bugs
   Version: 6.0
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P
 Component: new bugs
  Assignee: unassignedb...@nondot.org
  Reporter: mar...@gmail.com
CC: llvm-bugs@lists.llvm.org
Blocks: 35804

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


Referenced Bugs:

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

[llvm-bugs] [Bug 36176] New: Merge r323907 into the 6.0 branch : [SeparateConstOffsetFromGEP] Preserve metadata when splitting GEPs

[via llvm-bugs]

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

Bug ID: 36176
   Summary: Merge r323907 into the 6.0 branch :
[SeparateConstOffsetFromGEP] Preserve metadata when
splitting GEPs
   Product: new-bugs
   Version: 6.0
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P
 Component: new bugs
  Assignee: unassignedb...@nondot.org
  Reporter: mar...@gmail.com
CC: llvm-bugs@lists.llvm.org
Blocks: 35804

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


Referenced Bugs:

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

[llvm-bugs] [Bug 36123] LTO: memory usage blows through roof due to X86RetpolineThunksPass

[via llvm-bugs]

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

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

[llvm-bugs] [Bug 35316] Compiler crash

[via llvm-bugs]

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

Nirav Dave  changed:

   What|Removed |Added

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

--- Comment #5 from Nirav Dave  ---
rL323880

-- 
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 36175] New: llvm 6.0 (external lld 6.0) cmake undef refs while linking ../../lib/libLTO.so

[via llvm-bugs]

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

Bug ID: 36175
   Summary: llvm 6.0 (external lld 6.0) cmake undef refs while
linking ../../lib/libLTO.so
   Product: Build scripts
   Version: 6.0
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P
 Component: cmake
  Assignee: unassignedb...@nondot.org
  Reporter: accounts-l...@holbrook.no
CC: llvm-bugs@lists.llvm.org

Using gcc 7.2.1 on 4.14.15-1-ARCH, build with tag `release_60` from
https://github.com/llvm-mirror/llvm with external lld  tag `release_60` from
https://github.com/llvm-mirror/lld using cmake args:

-DLLVM_EXTERNAL_LLD_SOURCE_DIR=/path/to/lldrepo/root
-DLLVM_TOOL_BUILD_LLD=1

[ 85%] Linking CXX shared library ../../lib/libLTO.so
../../lib/libLLVMNVPTXCodeGen.a(NVPTXAsmPrinter.cpp.o): In function
`llvm::NVPTXInstrInfo::~NVPTXInstrInfo()':
/mnt/data/src/llvm/llvm/lib/Target/NVPTX/NVPTXInstrInfo.h:26: undefined
reference to `vtable for llvm::NVPTXInstrInfo'
../../lib/libLLVMNVPTXCodeGen.a(NVPTXAsmPrinter.cpp.o): In function
`llvm::NVPTXTargetLowering::~NVPTXTargetLowering()':
/mnt/data/src/llvm/llvm/lib/Target/NVPTX/NVPTXISelLowering.h:440: undefined
reference to `vtable for llvm::NVPTXTargetLowering'
../../lib/libLLVMNVPTXCodeGen.a(NVPTXSubtarget.cpp.o): In function
`llvm::NVPTXSubtarget::NVPTXSubtarget(llvm::Triple const&,
std::__cxx11::basic_string
const&, std::__cxx11::basic_string const&, llvm::NVPTXTargetMachine const&)':
/mnt/data/src/llvm/llvm/lib/Target/NVPTX/NVPTXSubtarget.cpp:54: undefined
reference to `llvm::NVPTXInstrInfo::NVPTXInstrInfo()'
/mnt/data/src/llvm/llvm/lib/Target/NVPTX/NVPTXSubtarget.cpp:54: undefined
reference to
`llvm::NVPTXTargetLowering::NVPTXTargetLowering(llvm::NVPTXTargetMachine
const&, llvm::NVPTXSubtarget const&)'
../../lib/libLLVMNVPTXCodeGen.a(NVPTXTargetMachine.cpp.o): In function
`LLVMInitializeNVPTXTarget':
/mnt/data/src/llvm/llvm/lib/Target/NVPTX/NVPTXTargetMachine.cpp:70: undefined
reference to `llvm::initializeGenericToNVVMPass(llvm::PassRegistry&)'
/mnt/data/src/llvm/llvm/lib/Target/NVPTX/NVPTXTargetMachine.cpp:73: undefined
reference to `llvm::initializeNVPTXLowerArgsPass(llvm::PassRegistry&)'
/mnt/data/src/llvm/llvm/lib/Target/NVPTX/NVPTXTargetMachine.cpp:74: undefined
reference to `llvm::initializeNVPTXLowerAllocaPass(llvm::PassRegistry&)'
/mnt/data/src/llvm/llvm/lib/Target/NVPTX/NVPTXTargetMachine.cpp:75: undefined
reference to `llvm::initializeNVPTXLowerAggrCopiesPass(llvm::PassRegistry&)'
../../lib/libLLVMNVPTXCodeGen.a(NVPTXTargetMachine.cpp.o): In function
`(anonymous namespace)::NVPTXPassConfig::addAddressSpaceInferencePasses()':
/mnt/data/src/llvm/llvm/lib/Target/NVPTX/NVPTXTargetMachine.cpp:199: undefined
reference to `llvm::createNVPTXLowerAllocaPass()'
../../lib/libLLVMNVPTXCodeGen.a(NVPTXTargetMachine.cpp.o): In function
`(anonymous namespace)::NVPTXPassConfig::addIRPasses()':
/mnt/data/src/llvm/llvm/lib/Target/NVPTX/NVPTXTargetMachine.cpp:242: undefined
reference to `llvm::createNVPTXImageOptimizerPass()'
/mnt/data/src/llvm/llvm/lib/Target/NVPTX/NVPTXTargetMachine.cpp:244: undefined
reference to `llvm::createGenericToNVVMPass()'
/mnt/data/src/llvm/llvm/lib/Target/NVPTX/NVPTXTargetMachine.cpp:248: undefined
reference to `llvm::createNVPTXLowerArgsPass(llvm::NVPTXTargetMachine const*)'
../../lib/libLLVMNVPTXCodeGen.a(NVPTXTargetMachine.cpp.o): In function
`(anonymous namespace)::NVPTXPassConfig::addInstSelector()':
/mnt/data/src/llvm/llvm/lib/Target/NVPTX/NVPTXTargetMachine.cpp:277: undefined
reference to `llvm::createLowerAggrCopies()'
/mnt/data/src/llvm/llvm/lib/Target/NVPTX/NVPTXTargetMachine.cpp:279: undefined
reference to `llvm::createNVPTXISelDag(llvm::NVPTXTargetMachine&,
llvm::CodeGenOpt::Level)'
../../lib/libLLVMNVPTXCodeGen.a(NVPTXTargetMachine.cpp.o): In function
`llvm::NVPTXTargetObjectFile::NVPTXTargetObjectFile()':
/mnt/data/src/llvm/llvm/lib/Target/NVPTX/NVPTXTargetObjectFile.h:22: undefined
reference to `vtable for llvm::NVPTXTargetObjectFile'
collect2: error: ld returned 1 exit status
make[2]: *** [tools/lto/CMakeFiles/LTO.dir/build.make:269: lib/libLTO.so.6.0.0]
Error 1
make[1]: *** [CMakeFiles/Makefile2:18784: tools/lto/CMakeFiles/LTO.dir/all]
Error 2
make: *** [Makefile:152: all] Error 2

-- 
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 35923] [Dead Store Elimination, Alias Analysis] Incorrect optimization

[via llvm-bugs]

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

Jonas Paulsson  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #3 from Jonas Paulsson  ---
(In reply to Sanjay Patel from comment #2)
> Can you verify if this is fixed after:
> https://reviews.llvm.org/rL323759
> 
> I think this is the same bug as in bug 36129, but let's make sure there
> isn't some endian-ness problem that was also missed.

My test case seems to work on trunk now, and if I revert the commit above it
fails again, so I conclude that it is now fixed.

*** This bug has been marked as a duplicate of bug 36129 ***

-- 
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 36169] AggressiveInstCombine crash

[via llvm-bugs]

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

Jonas Paulsson  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|NEW |RESOLVED

--- Comment #1 from Jonas Paulsson  ---
This seems to be a duplicate of https://bugs.llvm.org/show_bug.cgi?id=36121. At
least https://reviews.llvm.org/D42622 remedies this test case.

*** This bug has been marked as a duplicate of bug 36121 ***

-- 
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 36170] New: clang-format removes space between macro name and definition in parens (thereby breaking the code)

[via llvm-bugs]

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

Bug ID: 36170
   Summary: clang-format removes space between macro name and
definition in parens (thereby breaking the code)
   Product: clang
   Version: 5.0
  Hardware: PC
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P
 Component: Formatter
  Assignee: unassignedclangb...@nondot.org
  Reporter: m...@maxbruckner.de
CC: djas...@google.com, kli...@google.com,
llvm-bugs@lists.llvm.org

Given the following macro:

#define true ((int)1)

clang-format produces the following, incorrect, output that doesn't compile:

#define true((int)1)

I tried to find a configuration option related to this, but I couldn't find
one. The problem is reproducible with the default configuration (without
.clang-format).

-- 
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 36134] opt crashes with -aggressive-instcombine: ../lib/Transforms/AggressiveInstCombine/TruncInstCombine.cpp:296: llvm::Value *llvm::TruncInstCombine::getReducedOperand(llvm::Value *

[via llvm-bugs]

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

Amjad Aboud  changed:

   What|Removed |Added

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

--- Comment #5 from Amjad Aboud  ---
Resolved at https://reviews.llvm.org/rL323862

-- 
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 36169] New: AggressiveInstCombine crash

[via llvm-bugs]

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

Bug ID: 36169
   Summary: AggressiveInstCombine crash
   Product: libraries
   Version: trunk
  Hardware: PC
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P
 Component: Scalar Optimizations
  Assignee: unassignedb...@nondot.org
  Reporter: pauls...@linux.vnet.ibm.com
CC: llvm-bugs@lists.llvm.org

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

bin/opt -mtriple=s390x-linux-gnu -mcpu=z13 tc_aggr_instcomb.ll -o out.ll
-inline -early-cse-memssa -simplifycfg -aggressive-instcombine -S

#0 0x02d318a8 llvm::sys::PrintStackTrace(llvm::raw_ostream&)
(bin/opt+0x2d318a8)
#1 0x02d2f846 llvm::sys::RunSignalHandlers() (bin/opt+0x2d2f846)
#2 0x02d2f9b8 SignalHandler(int) (bin/opt+0x2d2f9b8)
#3 0x0554dcee
#4 0x027bdaf0 llvm::Type::getScalarSizeInBits() const
(bin/opt+0x27bdaf0)
#5 0x020a436c llvm::TruncInstCombine::getBestTruncatedType()
(bin/opt+0x20a436c)
#6 0x020a44d0 llvm::TruncInstCombine::run(llvm::Function&)
(bin/opt+0x20a44d0)
#7 0x0209eb7e (anonymous
namespace)::AggressiveInstCombinerLegacyPass::runOnFunction(llvm::Function&)
(bin/opt+0x209eb7e)
#8 0x0277bede llvm::FPPassManager::runOnFunction(llvm::Function&)
(bin/opt+0x277bede)
#9 0x0210f8b4 (anonymous
namespace)::CGPassManager::runOnModule(llvm::Module&) (bin/opt+0x210f8b4)
#10 0x0277ccee llvm::legacy::PassManagerImpl::run(llvm::Module&)
(bin/opt+0x277ccee)
#11 0x013190ba main (bin/opt+0x13190ba)
#12 0x03fffd72306a __libc_start_main (/lib64/libc.so.6+0x2306a)
#13 0x01381a9e _start (bin/opt+0x1381a9e)
Stack dump:
0.  Program arguments: bin/opt -mtriple=s390x-linux-gnu -mcpu=z13
tc_aggr_instcomb.ll -o out.ll -inline -early-cse-memssa -simplifycfg
-aggressive-instcombine -S 
1.  Running pass 'CallGraph Pass Manager' on module 'tc_aggr_instcomb.ll'.
2.  Running pass 'Combine pattern based expressions' on function '@3'
Segmentation fault (core dumped)

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

[llvm-bugs] [Bug 36168] New: [DebugInfo] Wrong representation of enumerator values in debug info metadata

[via llvm-bugs]

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

Bug ID: 36168
   Summary: [DebugInfo] Wrong representation of enumerator values
in debug info metadata
   Product: clang
   Version: trunk
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P
 Component: LLVM Codegen
  Assignee: unassignedclangb...@nondot.org
  Reporter: momchil.veli...@arm.com
CC: llvm-bugs@lists.llvm.org

Created attachment 19780
  --> https://bugs.llvm.org/attachment.cgi?id=19780=edit
C language test case

There are a few issue with the representation of enumeration types in the debug
info metadata as well as in DWARF.

The representation of enumerator values uses a single `int64_t`, which does not
convey enough information about the enumerator value.  For example, when
compiling
the attached `e.c`, `clang` encodes  the values of `A5` and `A7` wrong in the
DWARF debug info:
```
$ clang -c -g e.c && llvm-dwarfdump --debug-info e.o | grep -A1 A[0-9]   
  DW_AT_name("A0")
  DW_AT_const_value (-128)
--
  DW_AT_name("A1")
  DW_AT_const_value (255)
--
  DW_AT_name("A2")
  DW_AT_const_value (-32768)
--
  DW_AT_name("A3")
  DW_AT_const_value (65535)
--
  DW_AT_name("A4")
  DW_AT_const_value (-2147483648)
--
  DW_AT_name("A5")
  DW_AT_const_value (-1)
--
  DW_AT_name("A6")
  DW_AT_const_value (-9223372036854775808)
--
  DW_AT_name("A7")
  DW_AT_const_value (-9223372036854775808)

```

Compiling the same program as C++ and using the `-fshort-enums` gets wrong the
value of A3 as well:

> $ clang -fshort-enums -x c++ -c -g e.c && llvm-dwarfdump --debug-info e.o | 
> grep -A1 A3
>   DW_AT_name  ("A3")
>   DW_AT_const_value   (-1)
> 

Similar issues are present with C++11 enumerations with  a fixed underlying
type, e.g. compiling the attached `e.cc`, yields wrong values for `A1`, `A3`,
`A5`, and `A7`:
```
$ clang -c -g e.cc && llvm-dwarfdump --debug-info e.o | grep -A1 A[0-9]
  DW_AT_name("A0")
  DW_AT_const_value (-128)
--
  DW_AT_name("A1")
  DW_AT_const_value (-1)
--
  DW_AT_name("A2")
  DW_AT_const_value (-32768)
--
  DW_AT_name("A3")
  DW_AT_const_value (-1)
--
  DW_AT_name("A4")
  DW_AT_const_value (-2147483648)
--
  DW_AT_name("A5")
  DW_AT_const_value (-1)
--
  DW_AT_name("A6")
  DW_AT_const_value (-9223372036854775808)
--
  DW_AT_name("A7")
  DW_AT_const_value (-9223372036854775808)
```

-- 
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 36167] New: Obvious occurence of segmantion fault isn't reported

[via llvm-bugs]

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

Bug ID: 36167
   Summary: Obvious occurence of  segmantion fault isn't reported
   Product: clang
   Version: 3.7
  Hardware: Other
OS: Linux
Status: NEW
  Severity: normal
  Priority: P
 Component: Static Analyzer
  Assignee: dcough...@apple.com
  Reporter: marzec.wojci...@gmail.com
CC: llvm-bugs@lists.llvm.org

Whole problem is described on:

https://stackoverflow.com/questions/4703/fragment-of-code-from-the-clang-documentation-page


Could you look at it?

-- 
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 36166] New: tools/gold/X86/comdat.ll is failing only on Debian Unstable

[via llvm-bugs]

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

Bug ID: 36166
   Summary: tools/gold/X86/comdat.ll is failing only on Debian
Unstable
   Product: libraries
   Version: trunk
  Hardware: PC
OS: Linux
Status: NEW
  Severity: release blocker
  Priority: P
 Component: Linker
  Assignee: unassignedb...@nondot.org
  Reporter: sylves...@debian.org
CC: h...@chromium.org, llvm-bugs@lists.llvm.org
Blocks: 35804

New regression from 5.0

Maybe caused by a new version of binutils or ld

/build/llvm-toolchain-6.0-6.0~svn323854/build-llvm/bin/llvm-as
/build/llvm-toolchain-6.0-6.0~svn323854/test/tools/gold/X86/comdat.ll -o
/build/llvm-toolchain-6.0-6.0~svn323854/build-llvm/test/tools/gold/X86/Output/comdat.ll.tmp1.o
/build/llvm-toolchain-6.0-6.0~svn323854/build-llvm/bin/llvm-as
/build/llvm-toolchain-6.0-6.0~svn323854/test/tools/gold/X86/Inputs/comdat.ll -o
/build/llvm-toolchain-6.0-6.0~svn323854/build-llvm/test/tools/gold/X86/Output/comdat.ll.tmp2.o
/usr/bin/ld.gold -shared -o
/build/llvm-toolchain-6.0-6.0~svn323854/build-llvm/test/tools/gold/X86/Output/comdat.ll.tmp3.o
-plugin /build/llvm-toolchain-6.0-6.0~svn323854/build-llvm/./lib/LLVMgold.so
/build/llvm-toolchain-6.0-6.0~svn323854/build-llvm/test/tools/gold/X86/Output/comdat.ll.tmp1.o
/build/llvm-toolchain-6.0-6.0~svn323854/build-llvm/test/tools/gold/X86/Output/comdat.ll.tmp2.o
  -m elf_x86_64   -plugin-opt=save-temps
/build/llvm-toolchain-6.0-6.0~svn323854/build-llvm/bin/FileCheck
--check-prefix=RES
/build/llvm-toolchain-6.0-6.0~svn323854/test/tools/gold/X86/comdat.ll <
/build/llvm-toolchain-6.0-6.0~svn323854/build-llvm/test/tools/gold/X86/Output/comdat.ll.tmp3.o.resolution.txt
/build/llvm-toolchain-6.0-6.0~svn323854/build-llvm/bin/llvm-readobj -t
/build/llvm-toolchain-6.0-6.0~svn323854/build-llvm/test/tools/gold/X86/Output/comdat.ll.tmp3.o
| /build/llvm-toolchain-6.0-6.0~svn323854/build-llvm/bin/FileCheck
--check-prefix=OBJ
/build/llvm-toolchain-6.0-6.0~svn323854/test/tools/gold/X86/comdat.ll
--
Exit Code: 1

Command Output (stderr):
--
/build/llvm-toolchain-6.0-6.0~svn323854/test/tools/gold/X86/comdat.ll:63:13:
error: expected string not found in input
; OBJ-NEXT: Other [
^
:233:8: note: scanning from here
 Type: Function (0x2)
   ^
:234:2: note: possible intended match here
 Other: 0
 ^


Referenced Bugs:

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

[llvm-bugs] [Bug 36165] New: [x86] LLVM assembles and can even codegen a R_X86_64_GOTTPOFF relocation outside of movq and addq instructions

[via llvm-bugs]

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

Bug ID: 36165
   Summary: [x86] LLVM assembles and can even codegen a
R_X86_64_GOTTPOFF relocation outside of movq and addq
instructions
   Product: new-bugs
   Version: unspecified
  Hardware: PC
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P
 Component: new bugs
  Assignee: unassignedb...@nondot.org
  Reporter: chandl...@gmail.com
CC: craig.top...@gmail.com, echri...@gmail.com,
llvm-bugs@lists.llvm.org

Consider the assembly below:
```
shlxit: # @shlxit
.cfi_startproc
# %bb.0:# %entry
pushq   %rax
.cfi_def_cfa_offset 16
movl(%rsi), %eax
cmpl%edi, %eax
jl  .LBB2_4
# %bb.1:# %if.then
shlxq   %rdx, g@GOTTPOFF(%rip), %rdx
movq%fs:(%rdx), %rdx
movq%rdx, (%rcx)
cmpl%edi, %eax
jne .LBB2_2
# %bb.3:# %if.else
callq   dummy2
jmp .LBB2_4
.LBB2_2:# %if.then2
callq   dummy1
.LBB2_4:# %if.end3
xorl%eax, %eax
popq%rcx
retq
```

LLVM will assemble this without complaint, but the GOTTPOFF relocation here is
bogus. Both LLD and BFD-LD complain:

```
> ./dev/bin/clang -fuse-ld=lld -march=haswell -fPIE -pie -O2 -o shlx_crash 
> shlx_crash.s shlx_crash.c 
>   
>  Tue 30 Jan 2018 
> 07:35:51 PM PST
/home/chandlerc/src/llvm/build/./dev/bin/ld.lld: error: shlx_crash.c:(function
shlxit): R_X86_64_GOTTPOFF must be used in MOVQ or ADDQ instructions only
clang-6.0: error: linker command failed with exit code 1 (use -v to see
invocation)
```
```
./dev/bin/clang -march=haswell -fPIE -pie -O2 -o shlx_crash shlx_crash.s
shlx_crash.c   
   
 Tue 30 Jan 2018 07:36:49
PM PST
/usr/lib/gcc/x86_64-pc-linux-gnu/6.4.0/../../../../x86_64-pc-linux-gnu/bin/ld:
/tmp/shlx_crash-c81319.o: TLS transition from R_X86_64_GOTTPOFF to
R_X86_64_TPOFF32 against `g' at 0x2c in section `.text' failed
/usr/lib/gcc/x86_64-pc-linux-gnu/6.4.0/../../../../x86_64-pc-linux-gnu/bin/ld:
final link failed: Bad value
clang-6.0: error: linker command failed with exit code 1 (use -v to see
invocation)
```

Amazingly, the Gold installed on my system accepts this without complaint.

It would seem good for the LLVM assembler to reject this out right however. We
don't need to get to the linker to notice that we've asked for an invalid
relocation here.


What is much more scary is that LLVM can actually form this relocation. There
is no IR you can feed `llc` today to form it, but we have generic folding logic
for SHLX64rr -> SHLX64rm in the X86 backend. It should be possible to write an
MIR test case (but I don't know MIR very well) which forms a movq with this
relocation and a SHLX64rr of the resulting register and the backend will fold
the load into a memory operand of SHLX64rm.

At least, I have an MI pass that ended up doing something roughly like this and
I observed LLVM generating this bogus relocation (and gold failing to diagnose
it) which resulted in garbage bytes in the executable and SIGILL during
execution.

-- 
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 35804] [meta] 6.0.0 Release Blockers

[via llvm-bugs]

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

Bug 35836 Summary: Assertion `ARM::GPRRegClass.contains(DestReg, SrcReg) && 
"Thumb1 can only copy GPR registers"' failed.
https://bugs.llvm.org/show_bug.cgi?id=35836

   What|Removed |Added

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

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

[llvm-bugs] [Bug 35836] Assertion `ARM::GPRRegClass.contains(DestReg, SrcReg) && "Thumb1 can only copy GPR registers"' failed.

[via llvm-bugs]

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

Hans Wennborg  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Fixed By Commit(s)||r323857
 Resolution|FIXED   |---
 CC||h...@chromium.org

--- Comment #5 from Hans Wennborg  ---
(In reply to Roger Ferrer Ibanez from comment #4)
> Fixed in https://reviews.llvm.org/rL323857

Let's keep the bug open until the fix has been merged to 6.0, which I will do
once it's baked in trunk a little bit.

-- 
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 35836] Assertion `ARM::GPRRegClass.contains(DestReg, SrcReg) && "Thumb1 can only copy GPR registers"' failed.

[via llvm-bugs]

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

Roger Ferrer Ibanez  changed:

   What|Removed |Added

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

--- Comment #4 from Roger Ferrer Ibanez  ---
Fixed in https://reviews.llvm.org/rL323857

-- 
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 35804] [meta] 6.0.0 Release Blockers

[via llvm-bugs]

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

Bug 35836 Summary: Assertion `ARM::GPRRegClass.contains(DestReg, SrcReg) && 
"Thumb1 can only copy GPR registers"' failed.
https://bugs.llvm.org/show_bug.cgi?id=35836

   What|Removed |Added

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

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

[llvm-bugs] [Bug 36164] New: [SelectionDAG] Seemingly incorrect updating of chains in UpdateChains()

[via llvm-bugs]

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

Bug ID: 36164
   Summary: [SelectionDAG] Seemingly incorrect updating of chains
in UpdateChains()
   Product: libraries
   Version: trunk
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P
 Component: Common Code Generator Code
  Assignee: unassignedb...@nondot.org
  Reporter: pauls...@linux.vnet.ibm.com
CC: llvm-bugs@lists.llvm.org

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

Incorrect updating of DAG chains during Select(), which leads to a node having
a deleted node as chain input.

Run with

llc -mtriple=s390x-linux-gnu -mcpu=z13 -disable-basicaa ./tc_DAG_badchain.ll

llc: lib/CodeGen/SelectionDAG/InstrEmitter.cpp:802: void
llvm::InstrEmitter::EmitMachineNode(llvm::SDNode*, bool, bool,
llvm::DenseMap&): Assertion `NumMIOperands >=
II.getNumOperands() && NumMIOperands <= II.getNumOperands()\
 + II.getNumImplicitDefs() + NumImpUses && "#operands for dag node doesn't
match .td file!"' failed.


Reduced DAG just before t50 gets selected:

  t378: i64,ch = load)(dereferenceable)> t0, t402,
undef:i64
  t313: i32,ch = load)(dereferenceable)>
t517, t398, undef:i64
  t521: ch = TokenFactor t516, t520:1
t518: ch = store)> t517, Constant:i32<3>, t400,
undef:i64
  t519: ch = TokenFactor t516, t518

  t482: ch = TokenFactor t519, t521
  t478: ch = TokenFactor t521, t519

  t524: i32 = TargetConstant<1>
  t49: i64 = add t378, Constant:i64<24>
t50: ch = store)> t482, t49, t402,
undef:i64

t475: i32,ch = LRL)(dereferenceable)> TargetGlobalAddress:i64<%0* @g_832> 0,
t478


The DAG has many (volatile) memory accesses with multiple token factors (see
below for full DAG)

The t378 load has one (value) use which is the t49 add which is then stored by
t50.

The t50 store gets morphed (with load and add folded into it) to 't50: i32,ch =
AGSI...', which is an addition of immediate to memory. This seems ok regarding
the chains, but I'm not 100% sure...

The problem then is with t475, which was chained via t478 eventually up to
t378. It does not seem to get the chain properly updated: After void
SelectionDAGISel::UpdateChains(), it becomes

t475: i32,ch = LRL)(dereferenceable)> TargetGlobalAddress:i64<%0* @g_832> 0,
<>:ch

This later leads to an incorrect operand during instruction emission and the
assert triggers for t475.

Complete DAG just before t50 gets selected:

CurDAG->dump() = SelectionDAG has 71 nodes:
  t0: ch = EntryToken
  t398: i64 = SystemZISD::PCREL_WRAPPER TargetGlobalAddress:i64<%0* @g_832> 0
  t400: i64 = SystemZISD::PCREL_WRAPPER TargetGlobalAddress:i64 0
  t402: i64 = SystemZISD::PCREL_WRAPPER TargetGlobalAddress:i64 0
  t378: i64,ch = load)(dereferenceable)> t0, t402,
undef:i64
  t313: i32,ch = load)(dereferenceable)> t0, t398, undef:i64
t315: i32,ch = load)(dereferenceable)> t313:1, t398, undef:i64
  t318: i32,ch = load)(dereferenceable)> t315:1, t398, undef:i64
t321: i32,ch = load)(dereferenceable)> t318:1, t398, undef:i64
  t324: i32,ch = load)(dereferenceable)> t321:1, t398, undef:i64
t327: i32,ch = load)(dereferenceable)> t324:1, t398, undef:i64
  t330: i32,ch = load)(dereferenceable)> t327:1, t398, undef:i64
t333: i32,ch = load)(dereferenceable)> t330:1, t398, undef:i64
  t336: i32,ch = load)(dereferenceable)> t333:1, t398, undef:i64
t339: i32,ch = load)(dereferenceable)> t336:1, t398, undef:i64
  t342: i32,ch = load)(dereferenceable)> t339:1, t398, undef:i64
t345: i32,ch = load)(dereferenceable)> t342:1, t398, undef:i64
  t348: i32,ch = load)(dereferenceable)> t345:1, t398, undef:i64
t351: i32,ch = load)(dereferenceable)>
t348:1, t398, undef:i64
  t354: i32,ch = load)(dereferenceable)>
t351:1, t398, undef:i64
  t358: i32,ch = load)(dereferenceable)>
t354:1, t398, undef:i64
  t361: i32,ch = load)(dereferenceable)>
t358:1, t398, undef:i64
  t364: i32,ch = load)(dereferenceable)>
t361:1, t398, undef:i64
  t387: i32,ch = load)(dereferenceable)>
t364:1, t398, undef:i64
  t391: i32,ch = load)(dereferenceable)>
t387:1, t398, undef:i64
t404: i64 = SystemZISD::PCREL_WRAPPER
TargetGlobalAddress:i64 0
  t5: ch = store)> t0,
Constant:i32<1>, t404, undef:i64
  t381: ch = store)> t0,
Constant:i32<1>, t400, undef:i64
t522: ch = TokenFactor t354:1, 

[llvm-bugs] [Bug 36089] [ThinLTO] asserts `!(Pair.first != Ty && Pair.second == Ty) && "mapping to a source type"` failed

[via llvm-bugs]

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

Hans Wennborg  changed:

   What|Removed |Added

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

--- Comment #4 from Hans Wennborg  ---
(In reply to Teresa Johnson from comment #3)
> Fixed by r323813

Merged to 6.0 in r323854. Thanks!

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

[llvm-bugs] [Bug 35804] [meta] 6.0.0 Release Blockers

[via llvm-bugs]

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

Bug 36089 Summary: [ThinLTO] asserts `!(Pair.first != Ty && Pair.second == Ty) 
&& "mapping to a source type"` failed
https://bugs.llvm.org/show_bug.cgi?id=36089

   What|Removed |Added

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

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

[llvm-bugs] [Bug 36163] New: LLVMConfig.cmake contains clang-tblgen in the list of LLVM_EXPORTED_TARGETS

[via llvm-bugs]

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

Bug ID: 36163
   Summary: LLVMConfig.cmake contains clang-tblgen in the list of
LLVM_EXPORTED_TARGETS
   Product: Packaging
   Version: unspecified
  Hardware: PC
OS: All
Status: NEW
  Severity: enhancement
  Priority: P
 Component: binary tarballs
  Assignee: unassignedb...@nondot.org
  Reporter: vvasi...@cern.ch
CC: llvm-bugs@lists.llvm.org

This does not allow us to build clang with prebuilt llvm.

-- 
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 35804] [meta] 6.0.0 Release Blockers

[via llvm-bugs]

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

Bug 36051 Summary: [6.0] compiler-rt fails to build on arm64 with ld.gold
https://bugs.llvm.org/show_bug.cgi?id=36051

   What|Removed |Added

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

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

[llvm-bugs] [Bug 36051] [6.0] compiler-rt fails to build on arm64 with ld.gold

[via llvm-bugs]

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

Hans Wennborg  changed:

   What|Removed |Added

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

--- Comment #4 from Hans Wennborg  ---
(In reply to Evgenii Stepanov from comment #3)
> Yes, sounds good.

Merged in r323850.

-- 
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 36162] New: Unlocking equivalent to scoped_lockable for Thread Safety Analysis

[via llvm-bugs]

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

Bug ID: 36162
   Summary: Unlocking equivalent to scoped_lockable for Thread
Safety Analysis
   Product: clang
   Version: trunk
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P
 Component: Static Analyzer
  Assignee: dcough...@apple.com
  Reporter: cos...@gmail.com
CC: llvm-bugs@lists.llvm.org

I'm trying to add thread safety annotations [1] to Chromium.

We have AutoLock type [2], which works like MutexLocker in the Clang
documentation [1], so it can be annotated with __attribute__((scoped_locker))
(SCOPED_CAPABILITY in the Clang documentation). Unfortunately, we also have an
AutoUnlock type [3] that's used to safely drop a lock while performing a block
of work.

Examples of usage:
https://cs.chromium.org/chromium/src/ipc/ipc_mojo_bootstrap.cc?q=AutoUnlock
https://cs.chromium.org/chromium/src/tools/gn/input_file_manager.cc?q=AutoUnlock

So, using thread safety annotations in Chromium is blocked on getting a
scoped_unlocker annotation that causes the type's constructor to remove the
lock from the set of held locks (used by the analyzer), and causes the type's
destructor to add the lock back to the set of held locks.

Shooting in the dark, I tried adding scoped_locker to AutoUnlock and annotating
the constructor with unlock_function and the destructor with
exclusive_lock_function, so this might be an alternative solution.

I will try to put together a patch for this, but I've never contributed to LLVM
before, and this isn't prioritized by my employer, so I'll probably be very
slow. Also, I won't be upset if someone else provides a patch before me.


[1] https://clang.llvm.org/docs/ThreadSafetyAnalysis.html
[2] https://cs.chromium.org/chromium/src/base/synchronization/lock.h?q=AutoLock
[3]
https://cs.chromium.org/chromium/src/base/synchronization/lock.h?q=AutoUnlock

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