[llvm-bugs] [Bug 32369] New: Segfault in 'Reassociate expressions' pass

2017-03-22 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=32369

Bug ID: 32369
   Summary: Segfault in 'Reassociate expressions' pass
   Product: new-bugs
   Version: trunk
  Hardware: Other
OS: Linux
Status: NEW
  Severity: normal
  Priority: P
 Component: new bugs
  Assignee: unassignedb...@nondot.org
  Reporter: octopl...@yandex.com
CC: llvm-bugs@lists.llvm.org

On ppc64le I get:

#0 0x1124bf18 llvm::sys::PrintStackTrace(llvm::raw_ostream&)
(/home/trippels/llvm_build/bin/clang-5.0+0x1124bf18)
#1 0x1124c040 PrintStackTraceSignalHandler(void*)
(/home/trippels/llvm_build/bin/clang-5.0+0x1124c040)
#2 0x1124969c llvm::sys::RunSignalHandlers()
(/home/trippels/llvm_build/bin/clang-5.0+0x1124969c)
#3 0x11249b80 SignalHandler(int)
(/home/trippels/llvm_build/bin/clang-5.0+0x11249b80)
#4 0x3fffb7a20478  0x478 llvm::ReassociatePass::run(llvm::Function&,
llvm::AnalysisManager&)
#5 0x3fffb7a20478 
#6 0x3fffb7a20478 (anonymous
namespace)::ReassociateLegacyPass::runOnFunction(llvm::Function&) (+0x478)
#7 0x3fffc59db730
#8 0x11133108 llvm::FPPassManager::runOnFunction(llvm::Function&)
(/home/trippels/llvm_build/bin/clang-5.0+0x11133108)
#9 0x11133c9c (anonymous
namespace)::CGPassManager::runOnModule(llvm::Module&)
(/home/trippels/llvm_build/bin/clang-5.0+0x11133c9c)
#10 0x10d38488 llvm::legacy::PassManagerImpl::run(llvm::Module&)
(/home/trippels/llvm_build/bin/clang-5.0+0x10d38488)
#11 0x11e565b4 llvm::legacy::PassManager::run(llvm::Module&)
(/home/trippels/llvm_build/bin/clang-5.0+0x11e565b4)
#12 0x10d37890 clang::EmitBackendOutput(clang::DiagnosticsEngine&,
clang::HeaderSearchOptions const&, clang::CodeGenOptions const&,
clang::TargetOptions const&, clang::LangOptions const&, llvm::DataLayout
const&, llvm::Module*, clang::BackendAction,
std::unique_ptr >)
(/home/trippels/llvm_build/bin/clang-5.0+0x10d37890)
#13 0x10d37b7c
clang::BackendConsumer::HandleTranslationUnit(clang::ASTContext&)
(/home/trippels/llvm_build/bin/clang-5.0+0x10d37b7c)
#14 0x1145d0e0 clang::ParseAST(clang::Sema&, bool, bool)
(/home/trippels/llvm_build/bin/clang-5.0+0x1145d0e0)
#15 0x11c31dfc clang::ASTFrontendAction::ExecuteAction()
(/home/trippels/llvm_build/bin/clang-5.0+0x11c31dfc)
#16 0x1214f728 clang::CodeGenAction::ExecuteAction()
(/home/trippels/llvm_build/bin/clang-5.0+0x1214f728)
#17 0x118936a0 clang::FrontendAction::Execute()
(/home/trippels/llvm_build/bin/clang-5.0+0x118936a0)
#18 0x11c2ea10
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&)
(/home/trippels/llvm_build/bin/clang-5.0+0x11c2ea10)
#19 0x118945d8
clang::ExecuteCompilerInvocation(clang::CompilerInstance*)
(/home/trippels/llvm_build/bin/clang-5.0+0x118945d8)
#20 0x1185e620 cc1_main(llvm::ArrayRef, char const*,
void*) (/home/trippels/llvm_build/bin/clang-5.0+0x1185e620)
#21 0x1193bd48 main
(/home/trippels/llvm_build/bin/clang-5.0+0x1193bd48)
#22 0x105366d8 generic_start_main.isra.0
(/home/trippels/llvm_build/bin/clang-5.0+0x105366d8)
#23 0x104f75b4 __libc_start_main
(/home/trippels/llvm_build/bin/clang-5.0+0x104f75b4)
/home/trippels/llvm_build/bin/clang-5.0(_ZN4llvm3sys15PrintStackTraceERNS_11raw_ostreamE+0x38)[0x1124bf18]
/home/trippels/llvm_build/bin/clang-5.0[0x1124c040]
/home/trippels/llvm_build/bin/clang-5.0(_ZN4llvm3sys17RunSignalHandlersEv+0xcc)[0x1124969c]
/home/trippels/llvm_build/bin/clang-5.0[0x11249b80]
[0x3fffb7a20478]
[0x3fffc59db730]
/home/trippels/llvm_build/bin/clang-5.0(_ZN4llvm15ReassociatePass3runERNS_8FunctionERNS_15AnalysisManagerIS1_JEEE+0xda8)[0x11133108]
/home/trippels/llvm_build/bin/clang-5.0[0x11133c9c]
/home/trippels/llvm_build/bin/clang-5.0(_ZN4llvm13FPPassManager13runOnFunctionERNS_8FunctionE+0x388)[0x10d38488]
/home/trippels/llvm_build/bin/clang-5.0[0x11e565b4]
/home/trippels/llvm_build/bin/clang-5.0(_ZN4llvm6legacy15PassManagerImpl3runERNS_6ModuleE+0x410)[0x10d37890]
/home/trippels/llvm_build/bin/clang-5.0(_ZN4llvm6legacy11PassManager3runERNS_6ModuleE+0x1c)[0x10d37b7c]
/home/trippels/llvm_build/bin/clang-5.0(_ZN5clang17EmitBackendOutputERNS_17DiagnosticsEngineERKNS_19HeaderSearchOptionsERKNS_14CodeGenOptionsERKNS_13TargetOptionsERKNS_11LangOptionsERKN4llvm10DataLayoutEPNSE_6ModuleENS_13BackendActionESt10unique_ptrINSE_17raw_pwrite_streamESt14default_deleteISM_EE+0xa60)[0x1145d0e0]
/home/trippels/llvm_build/bin/clang-5.0[0x11c31dfc]
/home/trippels/llvm_build/bin/clang-5.0(_ZN5clang8ParseASTERNS_4SemaEbb+0x4f8)[0x1214f728]
/home/trippels/llvm_build/bin/clang-5.0(_ZN5clang17ASTFrontendAction13ExecuteActionEv+0x70)[0x118936a0]
/home/trippels/llvm_build/bin/clang-5.0(_ZN5clang13CodeGenAction13ExecuteActionEv+0x110)[0x11c2ea10]
/home/trippels/llvm_build/bin/clang-5.0(_ZN5clang14FrontendAction7ExecuteEv+0xf8)[0x118945d8]
/home/trippels/llvm_build/bin/clang-5.0(_ZN

[llvm-bugs] [Bug 32370] New: -Wcomma does not play well with -std=c89

2017-03-22 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=32370

Bug ID: 32370
   Summary: -Wcomma does not play well with -std=c89
   Product: clang
   Version: trunk
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P
 Component: Frontend
  Assignee: unassignedclangb...@nondot.org
  Reporter: sne...@dei.uc.pt
CC: llvm-bugs@lists.llvm.org

Beginning with an offending sample:

```
void f(void) {
  int i = 0, j = 0;
  for(;i < 10; ++i, ++j) {}
}

```

Compiling with `clang -std=c89 -Wcomma` we get

```
test.c:3:19: warning: possible misuse of comma operator here [-Wcomma]
  for(;i < 10; ++i, ++j) {}
  ^
test.c:3:16: note: cast expression to void to silence warning
  for(;i < 10; ++i, ++j) {}
   ^~~
   (void)( )
```

However, this example clearly belongs to the whitelisted class of comma
operator cases, and indeed in C++ and C99 modes clang behaves as expected.

I looked a little bit into why this happens, and the culprit appears to be the
following. The whitelisting of expressions happens in
[lib/Sema/SemaExpr.cpp](https://github.com/llvm-mirror/clang/blob/9a1877f04c1a225ff4acae5524d18be91f7fba3f/lib/Sema/SemaExpr.cpp#L10383-L10395):

```
  // Scope isn't fine-grained enough to whitelist the specific cases, so
  // instead, skip more than needed, then call back into here with the
  // CommaVisitor in SemaStmt.cpp.
  // The whitelisted locations are the initialization and increment portions
  // of a for loop.  The additional checks are on the condition of
  // if statements, do/while loops, and for loops.
  const unsigned ForIncrementFlags =
  Scope::ControlScope | Scope::ContinueScope | Scope::BreakScope;
  const unsigned ForInitFlags = Scope::ControlScope | Scope::DeclScope;
  const unsigned ScopeFlags = getCurScope()->getFlags();
  if ((ScopeFlags & ForIncrementFlags) == ForIncrementFlags ||
  (ScopeFlags & ForInitFlags) == ForInitFlags)
return;

```

But, in
[lib/Parse/ParseStmt.cpp](https://github.com/llvm-mirror/clang/blob/9a1877f04c1a225ff4acae5524d18be91f7fba3f/lib/Parse/ParseStmt.cpp#L1532-L1549),
we have that these flags are only activated in C99 or C++ modes:

```
  // C99 6.8.5p5 - In C99, the for statement is a block.  This is not
  // the case for C90.  Start the loop scope.
  //
  // ...
  //
  unsigned ScopeFlags = 0;
  if (C99orCXXorObjC)
ScopeFlags = Scope::DeclScope | Scope::ControlScope;
```

Therefore, it appears using these flags will not work in C90 to whitelist for
expressions.

-- 
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 24705] Regression? 3.7 and 3.8 eats line-break between function definitions

2017-03-22 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=24705

Mikael Simonsson  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #2 from Mikael Simonsson  ---
I stopped using "AllowShortFunctionsOnASingleLine" due to this bug, but I can't
replicate this with Clang 4.0.0. Marking as 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 32369] Segfault in 'Reassociate expressions' pass

2017-03-22 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=32369

octoploid  changed:

   What|Removed |Added

 Resolution|--- |INVALID
 Status|NEW |RESOLVED

--- Comment #2 from octoploid  ---
gcc trunk miscompiles LLVM, thus invalid.

-- 
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 32275] llvm-stress causes type legalizer to crash

2017-03-22 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=32275

Jonas Paulsson  changed:

   What|Removed |Added

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

--- Comment #3 from Jonas Paulsson  ---
r298357

-- 
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 13649] Unexpected warning when compiling MachineScheduler.cpp

2017-03-22 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=13649

Simon Pilgrim  changed:

   What|Removed |Added

 CC||llvm-...@redking.me.uk
 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #1 from Simon Pilgrim  ---
Fixed a long time ago in trunk

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

[llvm-bugs] [Bug 30649] llvm/lib/Target/X86/Disassembler/X86DisassemblerDecoder.cpp:658: possible copy'n'paste error ?

2017-03-22 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=30649

Simon Pilgrim  changed:

   What|Removed |Added

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

--- Comment #2 from Simon Pilgrim  ---
rL298495

-- 
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 30996] [META] PVS Studio Warnings

2017-03-22 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=30996
Bug 30996 depends on bug 30649, which changed state.

Bug 30649 Summary: 
llvm/lib/Target/X86/Disassembler/X86DisassemblerDecoder.cpp:658: possible 
copy'n'paste error ?
https://bugs.llvm.org/show_bug.cgi?id=30649

   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 32371] New: shuffle (concat_vectors v4f64) hits assertion with AVX512

2017-03-22 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=32371

Bug ID: 32371
   Summary: shuffle (concat_vectors v4f64) hits assertion with
AVX512
   Product: libraries
   Version: trunk
  Hardware: PC
OS: Windows NT
Status: NEW
  Severity: normal
  Priority: P
 Component: Backend: X86
  Assignee: unassignedb...@nondot.org
  Reporter: zvi.racko...@intel.com
CC: llvm-bugs@lists.llvm.org

Starting from r294774 the following test miscompiles:

llc -mcpu=skx

  define <8 x double> @foo2(<4 x double> %v) {
%res = shufflevector <4 x double> %v, <4 x double> undef, <8 x i32>

ret <8 x double> %res
  }


llvm/lib/Target/X86/X86ISelLowering.cpp:9919: llvm::SDValue
lowerVectorShuffleAsBroadcast(const llvm::SDLoc &, llvm::MVT, llvm::SDValue,
llvm::SDValue, ArrayRef, const llvm::X86Subtarget &, llvm::SelectionDAG
&): Assertion `SrcVT.getVectorNumElements() ==
BroadcastVT.getVectorNumElements() && "Unexpected vector num elements"' failed.

Here's the DAG at the time the assert fires:

SelectionDAG has 11 nodes:
  t0: ch = EntryToken
t2: v4f64,ch = CopyFromReg t0, Register:v4f64 %vreg0
  t4: v8f64 = concat_vectors t2, undef:v4f64
t6: v8f64 = vector_shuffle<2,2,2,2,2,2,2,2> t4, undef:v8f64
  t9: ch,glue = CopyToReg t0, Register:v8f64 %ZMM0, t6
  t10: ch = X86ISD::RET_FLAG t9, TargetConstant:i32<0>, Register:v8f64 %ZMM0,
t9:1

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

[llvm-bugs] [Bug 32281] lld doesn't give error about missing archive symbol table

2017-03-22 Thread via llvm-bugs 
http://bugs.llvm.org/show_bug.cgi?id=32281

Teresa Johnson  changed:

   What|Removed |Added

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

--- Comment #8 from Teresa Johnson  ---
I just checked and the new warning is emitted. The only thing that is somewhat
sub-optimal IMO is that the warning is sandwiched between 2 undefs (between the
1st and 2nd undef). It would probably be more noticeable if there was a way to
get it emitted first. But I will go ahead and close this bug. 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 32372] New: llvm-stress causes DAGCombiner crash

2017-03-22 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=32372

Bug ID: 32372
   Summary: llvm-stress causes DAGCombiner crash
   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 18145
  --> https://bugs.llvm.org/attachment.cgi?id=18145&action=edit
reduced test case

Reduced test case, when run with

llc -mtriple=s390x-linux-gnu -mcpu=z13

results in

llc: /home/jonas/llvm/llvm-dev/lib/CodeGen/SelectionDAG/SelectionDAG.cpp:746:
bool llvm::SelectionDAG::RemoveNodeFromCSEMaps(llvm::SDNode*): Assertion
`N->getOpcode() != ISD::DELETED_NODE && "DELETED_NODE in CSEMap!"' failed.

At first glance, it seems that the
CombineTo(N, (N0.getNode() == Load) ? NewLoad : N0);
in visitAND() should be guarded with a check if N or N0 has already been
deleted?


backtracking:


21: DAG.dump() = SelectionDAG has 21 nodes:
  t0: ch = EntryToken
  t2: i64,ch = CopyFromReg t0, Register:i64 %vreg2
  t32: i32,ch = load t0, t2, undef:i64
  t38: i32,ch = load t0, t2, undef:i64
  t44: i32 = Constant<-1>
  t41: i32 = and t32, Constant:i32<255>
  t42: i32 = and t38, Constant:i32<255>
t43: i32 = urem t41, t42
  t22: v16i8 = BUILD_VECTOR Constant:i32<0>, Constant:i32<0>,
Constant:i32<0>, Constant:i32<0>, Constant:i32<0>, Constant:i32<0>,
Constant:i32<0>, t43, undef:i32, undef:i32, undef:i32, undef:i32, undef:i32,
undef:i32, undef:i32, undef:i32
t24: ch = CopyToReg t0, Register:v16i8 %vreg0, t22
t28: ch = CopyToReg t0, Register:i32 %vreg1, t32
t39: ch = store t38:1, Constant:i32<-3825>,
undef:i64, undef:i64
  t29: ch = TokenFactor t24, t28, t39

Combining: t42: i32 = and t38, Constant:i32<255>

SDValue DAGCombiner::visitAND()  ->

(gdb) p N->dump()
t42: i32 = and t38, Constant:i32<255>
CombineTo(Load, NewLoad.getValue(0), NewLoad.getValue(1));
(gdb) p N0->dump()

t38: i32,ch = load t0, t2, undef:i64  ->

(gdb) p N->dump()
t42: i32 = <>
(gdb) p N0->dump()
t38: i32,ch = <>

// Fold the AND away, taking care not to fold to the old load node if we
// replaced it.
CombineTo(N, (N0.getNode() == Load) ? NewLoad : N0); ->

Replacing.1 t42: i32 = <>

With: t32: i32,ch = load t0, t2, undef:i64
 and 0 other values
llc: /home/jonas/llvm/llvm-dev/lib/CodeGen/SelectionDAG/SelectionDAG.cpp:746:
bool llvm::SelectionDAG::RemoveNodeFromCSEMaps(llvm::SDNode*): Assertion
`N->getOpcode() != ISD::DELETED_NODE && "DELETED_NODE in CSEMap!"' failed.

-- 
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 32373] New: [win] We might have to make __readgsqword a real intrinsic for VC2017

2017-03-22 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=32373

Bug ID: 32373
   Summary: [win] We might have to make __readgsqword a real
intrinsic for VC2017
   Product: clang
   Version: unspecified
  Hardware: PC
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P
 Component: Headers
  Assignee: unassignedclangb...@nondot.org
  Reporter: nicolaswe...@gmx.de
CC: llvm-bugs@lists.llvm.org

https://bugs.chromium.org/p/chromium/issues/detail?id=683729#c39
https://bugs.chromium.org/p/chromium/issues/detail?id=683729#c43
https://bugs.chromium.org/p/chromium/issues/detail?id=683729#c49

-- 
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 32374] New: Loop Strength Reduction generating incorrect result

2017-03-22 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=32374

Bug ID: 32374
   Summary: Loop Strength Reduction generating incorrect result
   Product: new-bugs
   Version: trunk
  Hardware: PC
OS: All
Status: NEW
  Severity: enhancement
  Priority: P
 Component: new bugs
  Assignee: unassignedb...@nondot.org
  Reporter: a...@azul.com
CC: llvm-bugs@lists.llvm.org

When running loop strength reduce on an IR, it generates the incorrect result.

Source code snippet:
intarg = longarg = 0;
for (firstiv = 117; firstiv > 3; --firstiv) {
   var = dummy_call();
}
for (secondiv = 6; secondiv < 126; secondiv++) {
   intarg+= (secondiv * secondiv);
   Test.iArrFld[secondiv + 1] -= (int)(--f1);
}
sum = intarg+ longarg+ firstiv + secondiv;

Here sum should be intarg + 0 + 3 + 126, where intarg = sum of squares from 6
to 125 (inclusive) [1] 
Quick calculation shows sum = 659202

I will attached the original IR and LSR optimized IR for this code.
Reproduce the problem as:
lli test.ll
659202

opt -loop-reduce -S test.ll > testlsr.ll 
lli testlsr.ll 
659455


[1] FYI: Can use sum of squares of first n numbers to calculate the sum of (6*6
+ 7 *7 +.. + 125*125) as S(125) - S(5)

-- 
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 18932] SelectionDAG assertion

2017-03-22 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=18932

Simon Pilgrim  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 CC||llvm-...@redking.me.uk
 Status|NEW |RESOLVED

--- Comment #5 from Simon Pilgrim  ---
This was fixed in clang 3.6

-- 
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 32376] New: dyld: lazy symbol binding failed: bad lazy bind info

2017-03-22 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=32376

Bug ID: 32376
   Summary: dyld: lazy symbol binding failed: bad lazy bind info
   Product: lld
   Version: unspecified
  Hardware: PC
OS: All
Status: NEW
  Severity: enhancement
  Priority: P
 Component: MachO
  Assignee: unassignedb...@nondot.org
  Reporter: superjo...@gmail.com
CC: llvm-bugs@lists.llvm.org

Created attachment 18148
  --> https://bugs.llvm.org/attachment.cgi?id=18148&action=edit
tmp_exe.ll

When linking the attached LLVM IR file with LLD, linking succeeds but running
the program gives this error:

$ clang -o tmp_exe.o -c tmp_exe.ll
$ ~/local/bin/lld -flavor darwin -demangle -dynamic -arch x86_64
-macosx_version_min 10.10.0 -pie -o ./tmp_exe ./tmp_exe.o -lSystem
$ ./tmp_exe

dyld: lazy symbol binding failed: bad lazy bind info
dyld: bad lazy bind info
Abort trap: 6

When linking with the system linker, the program runs fine:

$ ld -flavor darwin -demangle -dynamic -arch x86_64 -macosx_version_min 10.10.0
-pie -o ./tmp_exe ./tmp_exe.o -lSystem
$ ./tmp_exe



-- 
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 32377] New: __STDC_NO_THREADS__ undefined with glibc

2017-03-22 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=32377

Bug ID: 32377
   Summary: __STDC_NO_THREADS__ undefined with glibc
   Product: clang
   Version: 3.9
  Hardware: PC
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P
 Component: Driver
  Assignee: unassignedclangb...@nondot.org
  Reporter: cl...@evan.coeusgroup.com
CC: llvm-bugs@lists.llvm.org

glibc doesn't support the C11 threads API but clang doesn't define
__STDC_NO_THREADS__, even in C11 mode, as is required by the C11 spec (ยง
6.10.8.3).

I know this is partially a libc issue, since it's really up to the standard
library (not the compiler) to support the API.  glibc does contain a `#define
__STDC_NO_THREADS__ 1` (as of 2.16) in stdc-predef.h, but clang doesn't
automatically include that file (GCC does).

I'm working around this issue right now by including stdc-predef.h (indirectly,
for portability reasons; limits.h -> features.h -> stdc-predef.h), but AFAIK
this shouldn't be necessary for a conformant implementation of C11.  I should
be able to have something like

  #if defined(__STDC_VERSION__) && \
  (__STDC_VERSION__ >= 201102L) && \
  !defined(__STDC_NO_THREADS__)
  #  include 
  #endif

as the first few lines in my code, and have it work as expected.

It seems like the most straightforward solution would be to include
 on glibc just like GCC does
().

-- 
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 32298] llvm::DIExpression::FragmentInfo: Assertion `hasVal' failed

2017-03-22 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=32298

Adrian Prantl  changed:

   What|Removed |Added

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

--- Comment #15 from Adrian Prantl  ---
Author: adrian
Date:   Wed Mar 22 16:50:16 2017 +

Fix PR32298 by adding an early exit to getFrameIndexExprs().

Also add an assertion for the case that there are multiple FI
expressions with a DW_OP_LLVM_fragment; which should violate internal
constraints in DbgVariable.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@298518

Should be fixed now; let me know if I missed something.

-- 
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 32190] Assertion fails in debug mode with totally valid LLVM module Due to invalid FragmentInfo

2017-03-22 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=32190

Adrian Prantl  changed:

   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 32298] llvm::DIExpression::FragmentInfo: Assertion `hasVal' failed

2017-03-22 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=32298

Adrian Prantl  changed:

   What|Removed |Added

 Resolution|FIXED   |DUPLICATE

--- Comment #16 from Adrian Prantl  ---


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

-- 
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 32378] New: [Dwarf] Incorrect lexical scope information for constant arrays.

2017-03-22 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=32378

Bug ID: 32378
   Summary: [Dwarf] Incorrect lexical scope information for
constant arrays.
   Product: clang
   Version: trunk
  Hardware: PC
OS: Windows NT
Status: NEW
  Severity: enhancement
  Priority: P
 Component: -New Bugs
  Assignee: unassignedclangb...@nondot.org
  Reporter: andrea.dibia...@gmail.com
CC: llvm-bugs@lists.llvm.org

Reproducible:

/ test.cpp ///
void bar(int);
void foo() {
  {
const int someArray[] = {1, 2};
bar(someArray[0]);
  }

  {
const int someArray[] = {3, 4, 5};
bar(someArray[0]);
  }
}
//

> clang -g -O0 -c test.cpp
> objdump --dwarf=info test.o


 <1><2a>: Abbrev Number: 2 (DW_TAG_subprogram)
<39>   DW_AT_linkage_name: (indirect string, offset: 0x57): _Z3foov
 <2><43>: Abbrev Number: 3 (DW_TAG_variable)
<44>   DW_AT_name: (indirect string, offset: 0x40): someArray
<48>   DW_AT_type: <0x6e>
<4c>   DW_AT_decl_file   : 1
<4d>   DW_AT_decl_line   : 4
<4e>   DW_AT_location: 9 byte block: 3 0 0 0 0 0 0 0 0  (DW_OP_addr: 0)
 <2><58>: Abbrev Number: 3 (DW_TAG_variable)
<59>   DW_AT_name: (indirect string, offset: 0x40): someArray
<5d>   DW_AT_type: <0x8d>
<61>   DW_AT_decl_file   : 1
<62>   DW_AT_decl_line   : 9
<63>   DW_AT_location: 9 byte block: 3 8 0 0 0 0 0 0 0  (DW_OP_addr: 8)


Both 'someArray' arrays are associated to the subprogram lexical scope.
That is wrong because each one should be associated to a distinct lexical scope
nested within the subprogram scope.

GCC (I am using version 5.4.0 20160609) instead emits those two arrays in
distinct lexical blocks:

> gcc -g -O0 -c test.cpp
> objdump --dwarf=info test.o


 <1><2d>: Abbrev Number: 2 (DW_TAG_subprogram)
<34>   DW_AT_linkage_name: (indirect string, offset: 0x0): _Z3foov
 <2><4e>: Abbrev Number: 3 (DW_TAG_lexical_block)
<4f>   DW_AT_low_pc  : 0x4
<57>   DW_AT_high_pc : 0xd
<5f>   DW_AT_sibling : <0x79>
 <3><63>: Abbrev Number: 4 (DW_TAG_variable)
<64>   DW_AT_name: (indirect string, offset: 0x1a): someArray
<68>   DW_AT_decl_file   : 1
<69>   DW_AT_decl_line   : 4
<6a>   DW_AT_type: <0xc4>
<6e>   DW_AT_location: 9 byte block: 3 0 0 0 0 0 0 0 0  (DW_OP_addr: 0)
 <3><78>: Abbrev Number: 0
 <2><79>: Abbrev Number: 5 (DW_TAG_lexical_block)
<7a>   DW_AT_low_pc  : 0x11
<82>   DW_AT_high_pc : 0xd
 <3><8a>: Abbrev Number: 4 (DW_TAG_variable)
<8b>   DW_AT_name: (indirect string, offset: 0x1a): someArray
<8f>   DW_AT_decl_file   : 1
<90>   DW_AT_decl_line   : 9
<91>   DW_AT_type: <0xd9>
<95>   DW_AT_location: 9 byte block: 3 8 0 0 0 0 0 0 0  (DW_OP_addr: 8)

This is very likely to be another instance of bug 19238 and bug 23164.

-- 
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 32379] New: 64-bit bitfield and/or miscompiled on ARM

2017-03-22 Thread via llvm-bugs 
http://bugs.llvm.org/show_bug.cgi?id=32379

Bug ID: 32379
   Summary: 64-bit bitfield and/or miscompiled on ARM
   Product: libraries
   Version: trunk
  Hardware: PC
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P
 Component: Backend: ARM
  Assignee: unassignedb...@nondot.org
  Reporter: arie...@mail.tau.ac.il
CC: llvm-bugs@lists.llvm.org

## Versions

This occurs on Debian's 3.9.1, Rust's fork of 3.9.1, and godbolt's 4.0 & trunk.

## STR

$ cat trouble.c
#include 
#include 
#include 

__attribute__((noinline))
uint64_t test_function(uint64_t data, bool f1, bool f2) {
  if (f1) data &= ~2;
  if (f2) data |= 2;
  return data;
}

int main() {
  int data = (int)test_function(2, false, false);
  printf("%d\n", data);
  return 0;
}
$ clang-3.9 test.c --target=armv7-unknown-linux-gnueabihf -O
$ ./a.out
0
$

## Expected Result

Code should print 2

## Actual Result

Code prints 0, as the following assembly is emitted:
test_function(unsigned long long, bool, bool):
mov r12, r0
cmp r2, #0
bfc r12, #1, #1
moveq   r12, r0
bfi r12, r3, #1, #1
mov r0, r12
bx  lr

The `bfi` instruction trashes the original value of r0.

This was originally reported as Rust bug
https://github.com/rust-lang/rust/issues/40593.

-- 
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 32373] [win] We might have to make __readgsqword a real intrinsic for VC2017

2017-03-22 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=32373

Hans Wennborg  changed:

   What|Removed |Added

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

--- Comment #3 from Hans Wennborg  ---
r298538

-- 
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 23277] __builtin_object_size(null_pointer) returns the wrong result

2017-03-22 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=23277

George Burgess  changed:

   What|Removed |Added

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

--- Comment #13 from George Burgess  ---
Fixed by r298430+r298431.

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 21420] [Meta] Android+Clang platform support

2017-03-22 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=21420
Bug 21420 depends on bug 23277, which changed state.

Bug 23277 Summary: __builtin_object_size(null_pointer) returns the wrong result
https://bugs.llvm.org/show_bug.cgi?id=23277

   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 32382] New: LLVM may create invalid DWARF 4+ expressions

2017-03-22 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=32382

Bug ID: 32382
   Summary: LLVM may create invalid DWARF 4+ expressions
   Product: libraries
   Version: trunk
  Hardware: PC
OS: All
Status: NEW
  Severity: enhancement
  Priority: P
 Component: DebugInfo
  Assignee: unassignedb...@nondot.org
  Reporter: apra...@apple.com
CC: llvm-bugs@lists.llvm.org

As I recently confirmed on a thread on the dwarf-discuss mailing list
(http://lists.dwarfstd.org/private.cgi/dwarf-discuss-dwarfstd.org/2017-March/004335.html),
LLVM's DwarfExpression implementation can generate illegal DWARF 4+. This
hasn't been noticed thus far, because for relatively simple DWARF expressions
the difference doesn't matter, but as we get better about preserving debug
locations, this is becoming urgent.

To give a simplified overview, DWARF 4+ location descriptions come in multiple
flavors:
- Register location descriptions
  - describe a variable in a register
  - consist of only a DW_OP_reg
- Memory location descriptions
  - describe the address of a variable
- Implicit location descriptions
  - describe the value of a variable
  - end with DW_OP_stack_value & friends
- Composite location descriptions
  - use DW_OP_piece & friends to combine multiple location
descriptions of any of the previous kinds

Based on this, there are three main problems with LLVM's implementation:
1. DW_OP_reg is not allowed outside of register location descriptions.
2. We are sometimes missing a DW_OP_stack_value.
   2a. In DWARF 2&3 we should not emit anything that needs a
   DW_OP_stack_value that is not a constant.
3. LLVM uses DW_OP_breg when it means "deref the contents of that register",
   which is only correct if no arithmetic operators follow.
   Because of the missing DW_OP_stack_value the location will be classified as
   a memory location description and thus it usually works out.

In the last couple of days I refactored DwarfExpression to make fixing all of
these issues easy. We can now defer the decision on which kind of location
description to emit (and thus whether to use DW_OP_reg vs. DW_OP_breg
(+DW_OP_stack_value)) until we know the remainder of the expression.

The bugfixes won't affect any straightforward location descriptions (i.e.:
DW_OP_(b)reg without any operators, and DW_OP_breg DW_OP_deref will remain the
same) so I'm not expecting any dramatic fallout from fixing this PR, but please
do keep an eye on your debugger bots and let me know if your tools have come to
depend on LLVM bugs and we need to do some debugger tuning to make things work.
I will keep an eye on LLDB and make sure that it doesn't suffer from the same
problems as 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 31610] 4 AMDGPU tests just started to fail on Debian unstable

2017-03-22 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=31610

Konstantin Zhuravlyov  changed:

   What|Removed |Added

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

--- Comment #18 from Konstantin Zhuravlyov  ---
r298551

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

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

2017-03-22 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=32061
Bug 32061 depends on bug 31610, which changed state.

Bug 31610 Summary: 4 AMDGPU tests just started to fail on Debian unstable
https://bugs.llvm.org/show_bug.cgi?id=31610

   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 32383] New: Assertion `PartiallyIncomplete || ElementSize == (Ty->getSizeInBits() / 8)' failed.

2017-03-22 Thread via llvm-bugs 
http://bugs.llvm.org/show_bug.cgi?id=32383

Bug ID: 32383
   Summary: Assertion `PartiallyIncomplete || ElementSize ==
(Ty->getSizeInBits() / 8)' failed.
   Product: libraries
   Version: trunk
  Hardware: PC
OS: Windows NT
Status: NEW
  Severity: enhancement
  Priority: P
 Component: DebugInfo
  Assignee: unassignedb...@nondot.org
  Reporter: pe...@pcc.me.uk
CC: llvm-bugs@lists.llvm.org

$ cat 1.cc
# 1 "" 3
typedef union {
}

YYSTYPE;
void fn1() { YYSTYPE a[1]; }
$ cat 2.cc
union YYSTYPE {
  YYSTYPE *yylval_r;
} a;
$ clang-cl /Zi -flto -c 1.cc
$ clang-cl /Zi -flto -c 2.cc
$ llvm-link -o - 2.obj 1.obj | llc -o /dev/null
[...] llvm::codeview::TypeIndex llvm::CodeViewDebug::lowerTypeArray(const
llvm::DICompositeType *): Assertion `PartiallyIncomplete || ElementSize ==
(Ty->getSizeInBits() / 8)' failed.

-- 
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 32384] New: [AArch64] missing lowering of memcpy

2017-03-22 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=32384

Bug ID: 32384
   Summary: [AArch64] missing lowering of memcpy
   Product: libraries
   Version: trunk
  Hardware: PC
OS: All
Status: NEW
  Severity: enhancement
  Priority: P
 Component: Backend: AArch64
  Assignee: unassignedb...@nondot.org
  Reporter: dav...@freebsd.org
CC: efrie...@codeaurora.org, james.mol...@arm.com,
llvm-bugs@lists.llvm.org, ma...@braunis.de,
t.p.northo...@gmail.com

Consider the following code, reduced from SingleSource/Misc/salsa20.c in the
llvm test-suite, built with -O3 -mgeneral-regs-only -fomit-frame-pointer.

#include 

void tinky(uint32_t out[16],uint32_t in[16]) {
  uint32_t x[16];
  for (int i = 0; i < 16; ++i) x[i] = in[i];
  for (int i = 0; i < 16; ++i) out[i] = x[i] + in[i];
}


llvm generates a call to memcpy to put the input array on the stack

 :
   0:   d10183ffsub sp, sp, #0x60
   4:   a9044ff4stp x20, x19, [sp,#64]
   8:   aa0003f3mov x19, x0
   c:   910003e0mov x0, sp
  10:   321a03e2orr w2, wzr, #0x40
  14:   a9057bfdstp x29, x30, [sp,#80]
  18:   910143fdadd x29, sp, #0x50
  1c:   aa0103f4mov x20, x1
  20:   9400bl  0 
  24:   b94003e8ldr w8, [sp]
  28:   b9400289ldr w9, [x20]
  2c:   0b080128add w8, w9, w8
[...]

while GCC just used `stp`:

   0:   d10103ffsub sp, sp, #0x40
   4:   91004024add x4, x1, #0x10
   8:   eb04001fcmp x0, x4
   c:   91004003add x3, x0, #0x10
  10:   a9402c2aldp x10, x11, [x1]
  14:   aa22orr x2, x1, x0
  18:   a9412428ldp x8, x9, [x1,#16]
  1c:   a9002feastp x10, x11, [sp]
  20:   a9421c26ldp x6, x7, [x1,#32]
  24:   a90127e8stp x8, x9, [sp,#16]
  28:   a9431424ldp x4, x5, [x1,#48]
  2c:   a9021fe6stp x6, x7, [sp,#32]
  30:   a90317e4stp x4, x5, [sp,#48]
  34:   92400c42and x2, x2, #0xf
  38:   fa433022ccmpx1, x3, #0x2, cc

As the IR shows, both alignment and size are constant, and the size is
relatively small (well, 64), so I guess this call could be lowered (providing
`EmitTargetCodeForMemcpy()`) for the architecture. Thoughts?

define void @tinky(i32* nocapture, i32* nocapture readonly) local_unnamed_addr
#0 {
  %3 = bitcast i32* %1 to i8*
  %4 = alloca [16 x i32], align 4
  %5 = bitcast [16 x i32]* %4 to i8*
  call void @llvm.lifetime.start(i64 64, i8* nonnull %5) #2
  call void @llvm.memcpy.p0i8.p0i8.i64(i8* nonnull %5, i8* %3, i64 64, i32 4,
i1 false)
  %6 = getelementptr inbounds [16 x i32], [16 x i32]* %4, i64 0, i64 0
  %7 = load i32, i32* %6, align 4, !tbaa !1
  %8 = load i32, i32* %1, align 4, !tbaa !1
  %9 = add i32 %8, %7

-- 
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 32385] New: Assertion failure inheriting a constructor of const template parameter

2017-03-22 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=32385

Bug ID: 32385
   Summary: Assertion failure inheriting a constructor of const
template parameter
   Product: clang
   Version: 4.0
  Hardware: PC
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P
 Component: Frontend
  Assignee: unassignedclangb...@nondot.org
  Reporter: da...@doublewise.net
CC: llvm-bugs@lists.llvm.org

The following code leads to an assertion failure:

struct base {
};

template
struct inherit : T {
using T::T;
};

int main() {
inherit{};
}



This code worked in 3.9



david@localhost ~/test> clang++ source/main.cpp -std=c++1z
clang-4.0:
/var/tmp/portage/sys-devel/clang-4.0.0/work/x/y/cfe-4.0.0.src/lib/AST/DeclarationName.cpp:418:
clang::DeclarationName
clang::DeclarationNameTable::getCXXSpecialName(clang::DeclarationName::NameKind,
clang::CanQualType): Assertion `!Ty.hasQualifiers() &&"Constructor type must be
unqualified"' failed.
#0 0x7ff447f99988 llvm::sys::PrintStackTrace(llvm::raw_ostream&)
(/usr/lib64/llvm/4/bin/../lib64/libLLVMSupport.so.4+0xf8988)
#1 0x7ff447f9752e llvm::sys::RunSignalHandlers()
(/usr/lib64/llvm/4/bin/../lib64/libLLVMSupport.so.4+0xf652e)
#2 0x7ff447f978e2
(/usr/lib64/llvm/4/bin/../lib64/libLLVMSupport.so.4+0xf68e2)
#3 0x7ff446b3a0e0 (/lib64/libc.so.6+0x330e0)
#4 0x7ff446b3a074 gsignal (/lib64/libc.so.6+0x33074)
#5 0x7ff446b3b4da abort (/lib64/libc.so.6+0x344da)
#6 0x7ff446b32df7 (/lib64/libc.so.6+0x2bdf7)
#7 0x7ff446b32ea2 (/lib64/libc.so.6+0x2bea2)
#8 0x7ff4459d8fcf
clang::DeclarationNameTable::getCXXSpecialName(clang::DeclarationName::NameKind,
clang::CanQual)
(/usr/lib64/llvm/4/bin/../lib64/../lib64/libclangAST.so.4+0x1b4fcf)
#9 0x7ff44509f195
(/usr/lib64/llvm/4/bin/../lib64/../lib64/libclangSema.so.4+0x583195)
#10 0x7ff44509f3cc
clang::Sema::SubstDeclarationNameInfo(clang::DeclarationNameInfo const&,
clang::MultiLevelTemplateArgumentList const&)
(/usr/lib64/llvm/4/bin/../lib64/../lib64/libclangSema.so.4+0x5833cc)
#11 0x7ff4450cd122 clang::Decl*
clang::TemplateDeclInstantiator::instantiateUnresolvedUsingDecl(clang::UnresolvedUsingValueDecl*,
bool) (/usr/lib64/llvm/4/bin/../lib64/../lib64/libclangSema.so.4+0x5b1122)
#12 0x7ff44509d1f2 clang::Sema::InstantiateClass(clang::SourceLocation,
clang::CXXRecordDecl*, clang::CXXRecordDecl*,
clang::MultiLevelTemplateArgumentList const&,
clang::TemplateSpecializationKind, bool)
(/usr/lib64/llvm/4/bin/../lib64/../lib64/libclangSema.so.4+0x5811f2)
#13 0x7ff4450c5785
clang::Sema::InstantiateClassTemplateSpecialization(clang::SourceLocation,
clang::ClassTemplateSpecializationDecl*, clang::TemplateSpecializationKind,
bool) (/usr/lib64/llvm/4/bin/../lib64/../lib64/libclangSema.so.4+0x5a9785)
#14 0x7ff4450fd6ab
clang::Sema::RequireCompleteTypeImpl(clang::SourceLocation, clang::QualType,
clang::Sema::TypeDiagnoser*)
(/usr/lib64/llvm/4/bin/../lib64/../lib64/libclangSema.so.4+0x5e16ab)
#15 0x7ff4450fd985 clang::Sema::RequireCompleteType(clang::SourceLocation,
clang::QualType, clang::Sema::TypeDiagnoser&)
(/usr/lib64/llvm/4/bin/../lib64/../lib64/libclangSema.so.4+0x5e1985)
#16 0x7ff444e783b6
clang::Sema::BuildCXXTypeConstructExpr(clang::TypeSourceInfo*,
clang::SourceLocation, llvm::MutableArrayRef,
clang::SourceLocation)
(/usr/lib64/llvm/4/bin/../lib64/../lib64/libclangSema.so.4+0x35c3b6)
#17 0x7ff444e99d62
clang::Sema::ActOnCXXTypeConstructExpr(clang::OpaquePtr,
clang::SourceLocation, llvm::MutableArrayRef,
clang::SourceLocation)
(/usr/lib64/llvm/4/bin/../lib64/../lib64/libclangSema.so.4+0x37dd62)
#18 0x7ff44540c077
clang::Parser::ParseCXXTypeConstructExpression(clang::DeclSpec const&)
(/usr/lib64/llvm/4/bin/../lib64/../lib64/libclangParse.so.4+0x78077)
#19 0x7ff4453fff82 clang::Parser::ParseCastExpression(bool, bool, bool&,
clang::Parser::TypeCastState)
(/usr/lib64/llvm/4/bin/../lib64/../lib64/libclangParse.so.4+0x6bf82)
#20 0x7ff445401a9d clang::Parser::ParseCastExpression(bool, bool,
clang::Parser::TypeCastState)
(/usr/lib64/llvm/4/bin/../lib64/../lib64/libclangParse.so.4+0x6da9d)
#21 0x7ff445401b39
clang::Parser::ParseAssignmentExpression(clang::Parser::TypeCastState)
(/usr/lib64/llvm/4/bin/../lib64/../lib64/libclangParse.so.4+0x6db39)
#22 0x7ff445401bb9
clang::Parser::ParseExpression(clang::Parser::TypeCastState)
(/usr/lib64/llvm/4/bin/../lib64/../lib64/libclangParse.so.4+0x6dbb9)
#23 0x7ff445442362 clang::Parser::ParseExprStatement()
(/usr/lib64/llvm/4/bin/../lib64/../lib64/libclangParse.so.4+0xae362)
#24 0x7ff445441097
clang::Parser::ParseStatementOrDeclarationAfterAttributes(llvm::SmallVector&, clang::Parser::AllowedContsructsKind, clang::SourceLocation*,
clang::Parser::ParsedAttributesWithRange&)
(/usr/lib64/llvm/4/bin/../lib64/../lib64/libclangParse.so.4+0xad097)
#25 0x7ff4454412bf
clang::Parser::Parse

[llvm-bugs] [Bug 32348] conversion from double to signed long long with instruction fptosi is folded into undef value in optimization mode

2017-03-22 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=32348

Zixuan Wu  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

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