[llvm-bugs] [Bug 28137] New: Clang crashes on dllexport class with a default argument constructor
https://llvm.org/bugs/show_bug.cgi?id=28137
Bug ID: 28137
Summary: Clang crashes on dllexport class with a default
argument constructor
Product: clang
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: normal
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: mattiwa...@gmail.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
Code to reproduce:
template
constexpr T Ident(T t)
{
return t;
}
class __declspec(dllexport) B
{
B(int = 0) {}
void f()
{
Ident(0);
}
};
Command line used: clang -cc1 -triple x86_64-pc-windows-msvc19
-fms-compatibility -std=c++14 -emit-llvm foo.cpp -o foo.ll. I am using clang
3.9 (trunk 272663) on Windows, and clang 3.8 on Linux.
Compiling the above asserts with DefaultArg && "sema forgot to instantiate
default args".
Stacktrace:
[...snip CRT spew...]
clang.exe!`anonymous namespace'::MicrosoftCXXABI::getAddrOfCXXCtorClosure(const
clang::CXXConstructorDecl * CD, clang::CXXCtorType CT) Line 3864
clang.exe!`anonymous namespace'::MicrosoftCXXABI::EmitCXXConstructors(const
clang::CXXConstructorDecl * D) Line 1199
clang.exe!clang::CodeGen::CodeGenModule::EmitTopLevelDecl(clang::Decl * D) Line
3795
clang.exe!`anonymous namespace'::CodeGeneratorImpl::EmitDeferredDecls() Line
162
clang.exe!`anonymous
namespace'::CodeGeneratorImpl::HandlingTopLevelDeclRAII::~HandlingTopLevelDeclRAII()
Line 57
clang.exe!`anonymous
namespace'::CodeGeneratorImpl::HandleTopLevelDecl(clang::DeclGroupRef DG) Line
150
clang.exe!clang::BackendConsumer::HandleTopLevelDecl(clang::DeclGroupRef D)
Line 120
clang.exe!clang::Sema::InstantiateFunctionDefinition(clang::SourceLocation
PointOfInstantiation, clang::FunctionDecl * Function, bool Recursive, bool
DefinitionRequired, bool AtEndOfTU) Line 3722
clang.exe!clang::Sema::MarkFunctionReferenced(clang::SourceLocation Loc,
clang::FunctionDecl * Func, bool MightBeOdrUse) Line 13076
clang.exe!clang::Sema::MarkAnyDeclReferenced(clang::SourceLocation Loc,
clang::Decl * D, bool MightBeOdrUse) Line 14041
clang.exe!MarkExprReferenced(clang::Sema & SemaRef, clang::SourceLocation Loc,
clang::Decl * D, clang::Expr * E, bool MightBeOdrUse) Line 13975
clang.exe!clang::Sema::MarkDeclRefReferenced(clang::DeclRefExpr * E) Line 14006
clang.exe!clang::Sema::FixOverloadedFunctionReference(clang::Expr * E,
clang::DeclAccessPair Found, clang::FunctionDecl * Fn) Line 13039
clang.exe!FinishOverloadedCallExpr(clang::Sema & SemaRef, clang::Scope * S,
clang::Expr * Fn, clang::UnresolvedLookupExpr * ULE, clang::SourceLocation
LParenLoc, llvm::MutableArrayRef Args, clang::SourceLocation
RParenLoc, clang::Expr * ExecConfig, clang::OverloadCandidateSet *
CandidateSet, clang::OverloadCandidate * * Best, clang::OverloadingResult
OverloadResult, bool AllowTypoCorrection) Line 11346
clang.exe!clang::Sema::BuildOverloadedCallExpr(clang::Scope * S, clang::Expr *
Fn, clang::UnresolvedLookupExpr * ULE, clang::SourceLocation LParenLoc,
llvm::MutableArrayRef Args, clang::SourceLocation RParenLoc,
clang::Expr * ExecConfig, bool AllowTypoCorrection, bool CalleesAddressIsTaken)
Line 11451
clang.exe!clang::Sema::ActOnCallExpr(clang::Scope * S, clang::Expr * Fn,
clang::SourceLocation LParenLoc, llvm::MutableArrayRef ArgExprs,
clang::SourceLocation RParenLoc, clang::Expr * ExecConfig, bool IsExecConfig)
Line 5194
clang.exe!clang::Parser::ParsePostfixExpressionSuffix(clang::ActionResult LHS) Line 1602
clang.exe!clang::Parser::ParseCastExpression(bool isUnaryExpression, bool
isAddressOfOperand, bool & NotCastExpr, clang::Parser::TypeCastState
isTypeCast) Line 1369
clang.exe!clang::Parser::ParseCastExpression(bool isUnaryExpression, bool
isAddressOfOperand, clang::Parser::TypeCastState isTypeCast) Line 482
clang.exe!clang::Parser::ParseAssignmentExpression(clang::Parser::TypeCastState
isTypeCast) Line 172
clang.exe!clang::Parser::ParseExpression(clang::Parser::TypeCastState
isTypeCast) Line 122
clang.exe!clang::Parser::ParseExprStatement() Line 403
clang.exe!clang::Parser::ParseStatementOrDeclarationAfterAttributes(llvm::SmallVector & Stmts, clang::Parser::AllowedContsructsKind Allowed,
clang::SourceLocation * TrailingElseLoc,
clang::Parser::ParsedAttributesWithRange & Attrs) Line 225
clang.exe!clang::Parser::ParseStatementOrDeclaration(llvm::SmallVector & Stmts, clang::Parser::AllowedContsructsKind Allowed,
clang::SourceLocation * TrailingElseLoc) Line 116
clang.exe!clang::Parser::ParseCompoundStatementBody(bool isStmtExpr) Line 987
clang.exe!clang::Parser::ParseFunctionStatementBody(clang::Decl * Decl,
clang::Parser::ParseScope & BodyScope) Line 1940
clang.exe!clang::Parser::ParseLexedMethodDef(clang::Parser::LexedMethod & LM)
Line 558
clang.exe!clang::Parser::LexedMethod::ParseLexedMethodDefs() Line 258
clang.exe!clang::Parser::ParseLexedMethodDefs(clang::Pa
[llvm-bugs] [Bug 27772] Remove exit-on-error from test/CodeGen/MIR/Generic/machine-function-missing-function.mir
https://llvm.org/bugs/show_bug.cgi?id=27772 Diana Picus changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Diana Picus --- *** This bug has been marked as a duplicate of bug 27770 *** -- 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 27773] Remove exit-on-error from test/CodeGen/MIR/Generic/machine-function-missing-name.mir
https://llvm.org/bugs/show_bug.cgi?id=27773 Diana Picus changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Diana Picus --- *** This bug has been marked as a duplicate of bug 27770 *** -- 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 28138] New: trunk/llvm/lib/Target/Hexagon/HexagonInstrInfo.cpp: 2 * wierd conditions ?
https://llvm.org/bugs/show_bug.cgi?id=28138 Bug ID: 28138 Summary: trunk/llvm/lib/Target/Hexagon/HexagonInstrInfo.cpp: 2 * wierd conditions ? Product: new-bugs Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: dcb...@hotmail.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified 1. trunk/llvm/lib/Target/Hexagon/HexagonInstrInfo.cpp:1533] -> [trunk/llvm/lib/Target/Hexagon/HexagonInstrInfo.cpp:1533]: (style) Same expression on both sides of '||'. Source code is if (MIa->hasUnmodeledSideEffects() || MIb->hasUnmodeledSideEffects() || MIa->hasOrderedMemoryRef() || MIa->hasOrderedMemoryRef()) Maybe better code if (MIa->hasUnmodeledSideEffects() || MIb->hasUnmodeledSideEffects() || MIa->hasOrderedMemoryRef() || MIb->hasOrderedMemoryRef()) 2. trunk/llvm/lib/Target/Hexagon/HexagonInstrInfo.cpp:3678] -> [trunk/llvm/lib/Target/Hexagon/HexagonInstrInfo.cpp:3678]: (style) Same expression on both sides of '&&'. Source code is if (isIntRegForSubInst(Src1Reg) && MI->getOperand(1).isImm() && isUInt<4>(MI->getOperand(1).getImm()) && MI->getOperand(2).isImm() && MI->getOperand(2).isImm() && isUInt<1>(MI->getOperand(2).getImm())) maybe better code if (isIntRegForSubInst(Src1Reg) && MI->getOperand(1).isImm() && isUInt<4>(MI->getOperand(1).getImm()) && MI->getOperand(2).isImm() && isUInt<1>(MI->getOperand(2).getImm())) -- 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 28140] New: clang-format formats __declspec(dllimport) weirdly
https://llvm.org/bugs/show_bug.cgi?id=28140 Bug ID: 28140 Summary: clang-format formats __declspec(dllimport) weirdly Product: clang Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: Formatter Assignee: unassignedclangb...@nondot.org Reporter: nicolaswe...@gmx.de CC: djas...@google.com, kli...@google.com, llvm-bugs@lists.llvm.org Classification: Unclassified In: template class __declspec(dllimport) num_put>>; Out: template class __declspec( dllimport) num_put>>; -- 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 28141] New: atomic_load(std::shared_ptr*) et. al. from not available when libc++ is built with gcc
https://llvm.org/bugs/show_bug.cgi?id=28141 Bug ID: 28141 Summary: atomic_load(std::shared_ptr*) et. al. from not available when libc++ is built with gcc Product: libc++ Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: unassignedclangb...@nondot.org Reporter: asiri.rathnay...@arm.com CC: llvm-bugs@lists.llvm.org, mclow.li...@gmail.com Classification: Unclassified Created attachment 16548 --> https://llvm.org/bugs/attachment.cgi?id=16548&action=edit Fix. These failures were uncovered after r272716 (apparently they were not running before). The attached patch should fix the following test failures: FAIL: libc++::atomic_compare_exchange_strong.pass.cpp FAIL: libc++::atomic_compare_exchange_strong_explicit.pass.cpp FAIL: libc++::atomic_compare_exchange_weak.pass.cpp FAIL: libc++::atomic_compare_exchange_weak_explicit.pass.cpp FAIL: libc++::atomic_exchange_explicit.pass.cpp FAIL: libc++::atomic_exchange.pass.cpp FAIL: libc++::atomic_load.pass.cpp FAIL: libc++::atomic_is_lock_free.pass.cpp FAIL: libc++::atomic_load_explicit.pass.cpp FAIL: libc++::atomic_store.pass.cpp FAIL: libc++::atomic_store_explicit.pass.cpp -- 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 28142] New: RegScavenger (as used by BranchFolding) pessimises liveness
https://llvm.org/bugs/show_bug.cgi?id=28142 Bug ID: 28142 Summary: RegScavenger (as used by BranchFolding) pessimises liveness Product: libraries Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: Common Code Generator Code Assignee: unassignedb...@nondot.org Reporter: ahmed.bouga...@gmail.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified This came up in http://reviews.llvm.org/D21085; on the original testcase: Looks like BranchFolding, when merging tails, indiscriminately marks every register defined but not killed (it might really be live, but not necessarily) before the tail as live-in the new tail block. It queries the RegisterScavenger, which walks the original block forward, using kill flags; maybe it should walk the tail block backward instead? That patch adds forward liveness computation to X86FixupBWInsts (using flags, via LivePhysRegs) as a stopgap. Instead, seems like we should: - teach RegScavenger to compute liveness backwards (or replace it with something else) - fix the various users; in this case, BranchFolding - remove the X86FixupBWInsts workaround, and probably more -- 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 28143] New: Redefinition of 'tan' provokes assert
https://llvm.org/bugs/show_bug.cgi?id=28143
Bug ID: 28143
Summary: Redefinition of 'tan' provokes assert
Product: new-bugs
Version: trunk
Hardware: Other
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: carlo.berto...@gmail.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
The following program:
extern int tan (void);
int main (void) {
tan();
return 0;
}
Compiled with:
clang t53.c -O
Returns the following assert
clang-3.9: /localhd/cbertol/trunk/src/include/llvm/IR/Instructions.h:1554:
llvm::Value *llvm::CallInst::getArgOperand(unsigned int) const: Assertion `i <
getNumArgOperands() && "Out of bounds!"' failed.
It looks like that llvm is trying to simplify 'tan' as if it were the math.h
declaration, and not the re-declaration.
Compiled on bare-metal ubuntu on power 8 with:
llvm a94e734
clang e03851a
Using clang 3.8.1 does not result in error, but linking error as 'tan' is not
defined.
--
You are receiving this mail because:
You are on the CC list for the bug.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 28144] New: [IPRA][AArch64] Simple correctness test failing on AArch64
https://llvm.org/bugs/show_bug.cgi?id=28144
Bug ID: 28144
Summary: [IPRA][AArch64] Simple correctness test failing on
AArch64
Product: libraries
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: normal
Priority: P
Component: Register Allocator
Assignee: unassignedb...@nondot.org
Reporter: mcros...@codeaurora.org
CC: llvm-bugs@lists.llvm.org, ma...@braunis.de,
mehdi.am...@apple.com, qcolom...@apple.com
Classification: Unclassified
Given the following test case:
extern int printf(const char*, ...);
void foo(unsigned int i, int array[2]) __attribute__((noinline));
void foo(unsigned int i, int array[2]) {
printf("%d %d %d\n", i, array[0], array[1]);
}
int main() {
int array[2], i;
array[0] = 0;
array[1] = 1;
foo(0, array);
array[0] = 0;
array[1] = 1;
foo(1, array);
return 0;
}
-
Target aarch64 and compile with "-O3" should produce:
0 0 1
1 0 1
Target aarch64 and compile with "-O3 -mllvm -enable-ipra" should incorrectly
produce:
0 0 1
1 -56 -128
--
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 28143] Redefinition of 'tan' provokes assert
https://llvm.org/bugs/show_bug.cgi?id=28143 David Majnemer changed: What|Removed |Added Status|NEW |RESOLVED CC||david.majne...@gmail.com Component|new bugs|Scalar Optimizations Resolution|--- |FIXED Assignee|unassignedb...@nondot.org |david.majne...@gmail.com Product|new-bugs|libraries --- Comment #1 from David Majnemer --- Fixed in r272802. -- 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 27809] LLVMTargetMachineEmit aborts process instead of reporting error via return value
https://llvm.org/bugs/show_bug.cgi?id=27809 Reid Kleckner changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Reid Kleckner --- (In reply to comment #8) > Backtrace follows. Note that according to the API of LLVMTargetMachineEmit > it is supposed to return and report errors via one of its parameters. > Instead LLVM is writing its own error messages to stderr and then calling > exit. You need to install a diagnostic handler in order for LLVM to not call exit. See LLVMContext::setDiagnosticHandler. -- 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 28145] New: Support -maccumulate-outgoing-args
https://llvm.org/bugs/show_bug.cgi?id=28145 Bug ID: 28145 Summary: Support -maccumulate-outgoing-args Product: clang Version: 3.8 Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: -New Bugs Assignee: unassignedclangb...@nondot.org Reporter: austinengl...@gmail.com CC: an...@korobeynikov.info, an...@samba.org, austinengl...@gmail.com, baldr...@free.fr, edwin+l...@etorok.net, eli.fried...@gmail.com, ema...@freebsd.org, geek4ci...@gmail.com, lionel_debr...@yahoo.fr, llvm-bugs@lists.llvm.org Classification: Unclassified This is needed by the Linux kernel. GCC's manpage says: -maccumulate-outgoing-args If enabled, the maximum amount of space required for outgoing arguments is computed in the function prologue. This is faster on most modern CPUs because of reduced dependencies, improved scheduling and reduced stack usage when the preferred stack boundary is not equal to 2. The drawback is a notable increase in code size. This switch implies -mno-push-args. clang should probably support it too. -- 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 28146] New: A zexted setcc generates a setcc + movzbl instead of xor + setcc
https://llvm.org/bugs/show_bug.cgi?id=28146
Bug ID: 28146
Summary: A zexted setcc generates a setcc + movzbl instead of
xor + setcc
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Backend: X86
Assignee: unassignedb...@nondot.org
Reporter: mku...@google.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
Consider:
#include
int main() {
unsigned x = 0;
unsigned y = 0;
#pragma nounroll
for (unsigned i = 0; i < 10; ++i) {
y += x ^ 13;
x += ((i + 100) >= 1000) * 3;
}
return y;
}
We generate:
.text
.globlmain
.p2align4, 0x90
.typemain,@function
main:
.cfi_startproc
xorl%eax, %eax
movl$100, %ecx
xorl%edi, %edi
.p2align4, 0x90
.LBB0_1:
movl%edi, %esi
xorl$13, %esi
addl%esi, %eax
cmpl$999, %ecx
seta%dl # <===
movzbl%dl, %edx # <===
leal(%rdx,%rdx,2), %edx
addl%edx, %edi
incl%ecx
cmpl$100100, %ecx
jne.LBB0_1
retq
.Lfunc_end0:
.sizemain, .Lfunc_end0-main
.cfi_endproc
Instead of:
.text
.globl main
.p2align 4, 0x90
.type main,@function
main:
.cfi_startproc
xorl %eax, %eax
movl $100, %ecx
xorl %edi, %edi
.p2align 4, 0x90
.LBB0_1:
movl %edi, %esi
xorl $13, %esi
addl %esi, %eax
xorl %edx, %edx # <===
cmpl $999, %ecx
seta %dl # <===
leal (%rdx,%rdx,2), %edx
addl %edx, %edi
incl %ecx
cmpl $100100, %ecx
jne .LBB0_1
retq
.Lfunc_end0:
.size main, .Lfunc_end0-main
.cfi_endproc
The xor encodes smaller than the movzbl, which in itself is a good reason to
generate the former. However, there is a more surprising performance issue -
even though both versions ought to avoid partial register stalls, using the xor
idiom turns out to be much faster.
On a Haswell machine:
$ bin/clang -O2 ~/llvm/temp/setcc.s -o ~/llvm/temp/setcc.exe && time
~/llvm/temp/setcc.exe
real0m1.045s
user0m1.043s
sys0m0.001s
$ bin/clang -O2 ~/llvm/temp/setcc-faster.s -o ~/llvm/temp/setcc.exe && time
~/llvm/temp/setcc.exe
real0m0.876s
user0m0.874s
sys0m0.002s
Could someone at Intel confirm that this is expected? IACA doesn't show
significant stalling for the slower version, but it exists in practice (for the
slower version, about ~15% stalls, and this can be significantly increased by
making the dependency chain longer.)
--
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 28138] trunk/llvm/lib/Target/Hexagon/HexagonInstrInfo.cpp: 2 * wierd conditions ?
https://llvm.org/bugs/show_bug.cgi?id=28138 Krzysztof Parzyszek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Krzysztof Parzyszek --- Fixed in r272836. -- 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 26630] [Hexagon] J2_jump instruction with a global address fails with: Assertion `isMBB() && "Wrong MachineOperand accessor"'
https://llvm.org/bugs/show_bug.cgi?id=26630 Krzysztof Parzyszek 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 13781] [Hexagon] LLVM should use combine with immediate for zero extension when -mcpu=v4 and above.
https://llvm.org/bugs/show_bug.cgi?id=13781 Krzysztof Parzyszek changed: What|Removed |Added Status|NEW |RESOLVED CC||kparz...@codeaurora.org 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 28147] New: llvm armv7hnl bug malloc(): memory corruption: 0x01bd6eb8
https://llvm.org/bugs/show_bug.cgi?id=28147 Bug ID: 28147 Summary: llvm armv7hnl bug malloc(): memory corruption: 0x01bd6eb8 Product: tools Version: trunk Hardware: Other OS: Linux Status: NEW Severity: normal Priority: P Component: llvmc Assignee: unassignedb...@nondot.org Reporter: nobodyd...@gmail.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified Created attachment 16551 --> https://llvm.org/bugs/attachment.cgi?id=16551&action=edit /tmp/extent-tree-79ed0f.c Full log https://gist.github.com/fedya/950977b3b98db52bccd5d3532b0ced60 System: Wandboard ARMv7 (armv7hl with neon) Hardware: Freescale i.MX6 Quad/DualLite (Device Tree) Kernel: Linux b22b71aa08bd 4.5.2-server-11omv #1 SMP Sun May 1 03:00:41 UTC 2016 armv7l armv7l armv7l GNU/Linux LLVM version llvm-3.8.0-5.272115.1-omv2015.0.armv7hl , where 5.272115.1 is svn revision https://github.com/OpenMandrivaAssociation/llvm/commit/f2ce4a2926a11fc6d8b335588c3afd3e30d99d73 InstalledDir: /usr/bin clang-3.8: note: diagnostic msg: PLEASE submit a bug report to http://llvm.org/bugs/ and include the crash backtrace, preprocessed source, and associated run script. clang-3.8: note: diagnostic msg: PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: Preprocessed source(s) and associated run script(s) are located at: clang-3.8: note: diagnostic msg: /tmp/radix-tree-32a672.c clang-3.8: note: diagnostic msg: /tmp/radix-tree-32a672.sh clang-3.8: note: diagnostic msg: -- 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 27924] [x86, SSE] failed to eliminate unused instruction
https://llvm.org/bugs/show_bug.cgi?id=27924 Sanjay Patel changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Sanjay Patel --- This should be fixed with: http://reviews.llvm.org/rL272828 And avoided altogether with: http://reviews.llvm.org/rL272807 -- 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 27553] A lto build of clang with lld has 2624 more symbols than with gold
https://llvm.org/bugs/show_bug.cgi?id=27553 Rafael Ávila de Espíndola changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Rafael Ávila de Espíndola --- Fixed in r272812. Last known difference documented in r272845. -- 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 28148] New: clang crashes on valid code at -Os and above in 32-bit mode on x86_64-linux-gnu: Assertion `(Blocks.empty() || LIB[getHeader()] == this) && "Incorrect LI specified for thi
https://llvm.org/bugs/show_bug.cgi?id=28148 Bug ID: 28148 Summary: clang crashes on valid code at -Os and above in 32-bit mode on x86_64-linux-gnu: Assertion `(Blocks.empty() || LIB[getHeader()] == this) && "Incorrect LI specified for this loop!"' failed Product: clang Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: -New Bugs Assignee: unassignedclangb...@nondot.org Reporter: s...@cs.ucdavis.edu CC: llvm-bugs@lists.llvm.org Classification: Unclassified The current clang trunk crashes when compiling the following code on x86_64-linux-gnu at -Os and above in the 32-bit mode (but not in the 64-bit mode). This is a regression from 3.8.x. $ clang -v clang version 3.9.0 (trunk 272769) Target: x86_64-unknown-linux-gnu Thread model: posix InstalledDir: /usr/local/clang-trunk/bin Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/4.9 Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/4.9.3 Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/5.3.0 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.4 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.4.7 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.6 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.6.4 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.7 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.7.3 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8.5 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9.3 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5.3.0 Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9 Candidate multilib: .;@m64 Candidate multilib: 32;@m32 Candidate multilib: x32;@mx32 Selected multilib: .;@m64 $ $ clang -m32 -O1 -w small.c $ clang -m64 -Os -w small.c $ clang-3.8 -m32 -Os -w small.c $ $ clang -m32 -Os -w small.c clang-3.9: /tmp/llvm-builder/llvm-source-trunk/include/llvm/Analysis/LoopInfoImpl.h:189: void llvm::LoopBase::addBasicBlockToLoop(BlockT*, llvm::LoopInfoBase&) [with BlockT = llvm::MachineBasicBlock; LoopT = llvm::MachineLoop]: Assertion `(Blocks.empty() || LIB[getHeader()] == this) && "Incorrect LI specified for this loop!"' failed. #0 0x01d1c865 llvm::sys::PrintStackTrace(llvm::raw_ostream&) (/usr/local/clang-trunk/bin/clang-3.9+0x1d1c865) #1 0x01d1a6f6 llvm::sys::RunSignalHandlers() (/usr/local/clang-trunk/bin/clang-3.9+0x1d1a6f6) #2 0x01d1a914 SignalHandler(int) (/usr/local/clang-trunk/bin/clang-3.9+0x1d1a914) #3 0x7f3e3fa73340 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x10340) #4 0x7f3e3ec91cc9 gsignal /build/eglibc-3GlaMS/eglibc-2.19/signal/../nptl/sysdeps/unix/sysv/linux/raise.c:56:0 #5 0x7f3e3ec950d8 abort /build/eglibc-3GlaMS/eglibc-2.19/stdlib/abort.c:91:0 #6 0x7f3e3ec8ab86 __assert_fail_base /build/eglibc-3GlaMS/eglibc-2.19/assert/assert.c:92:0 #7 0x7f3e3ec8ac32 (/lib/x86_64-linux-gnu/libc.so.6+0x2fc32) #8 0x0171060f llvm::LoopBase::addBasicBlockToLoop(llvm::MachineBasicBlock*, llvm::LoopInfoBase&) (/usr/local/clang-trunk/bin/clang-3.9+0x171060f) #9 0x0182a39a llvm::BranchFolder::SplitMBBAt(llvm::MachineBasicBlock&, llvm::MachineInstrBundleIterator, llvm::BasicBlock const*) (/usr/local/clang-trunk/bin/clang-3.9+0x182a39a) #10 0x0182af3a llvm::BranchFolder::CreateCommonTailOnlyBlock(llvm::MachineBasicBlock*&, llvm::MachineBasicBlock*, unsigned int, unsigned int&) (/usr/local/clang-trunk/bin/clang-3.9+0x182af3a) #11 0x0182bf2e llvm::BranchFolder::TryTailMergeBlocks(llvm::MachineBasicBlock*, llvm::MachineBasicBlock*) (/usr/local/clang-trunk/bin/clang-3.9+0x182bf2e) #12 0x0182c84f llvm::BranchFolder::TailMergeBlocks(llvm::MachineFunction&) [clone .part.332] (/usr/local/clang-trunk/bin/clang-3.9+0x182c84f) #13 0x0182d776 llvm::BranchFolder::OptimizeFunction(llvm::MachineFunction&, llvm::TargetInstrInfo const*, llvm::TargetRegisterInfo const*, llvm::MachineModuleInfo*, llvm::MachineLoopInfo*, bool) (/usr/local/clang-trunk/bin/clang-3.9+0x182d776) #14 0x0186a97b (anonymous namespace)::MachineBlockPlacement::runOnMachineFunction(llvm::MachineFunction&) [clone .part.208] (/usr/local/clang-trunk/bin/clang-3.9+0x186a97b) #15 0x016f47a5 llvm::MachineFunctionPass::runOnFunction(llvm::Function&) (/usr/local/clang-trunk/bin/clang-3.9+0x16f47a5) #16 0x01983453 llvm::FPPassManager::runOnFunction(llvm::Function&) (/usr/local/clang-trunk/bin/clang-3.9+0x1983453) #17 0x01983a9b llvm::legacy::PassManagerImpl::run(llvm::Module&) (/usr/
[llvm-bugs] [Bug 28149] New: Debug information for type is lost with LTO at -O0
https://llvm.org/bugs/show_bug.cgi?id=28149
Bug ID: 28149
Summary: Debug information for type is lost with LTO at -O0
Product: libraries
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: normal
Priority: P
Component: Common Code Generator Code
Assignee: unassignedb...@nondot.org
Reporter: wolfgang_p...@playstation.sony.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
// After r267296 the following simple example fails to retain debug
// information for the type 'MyStruct' in the final executable when
// built with LTO. Building with -O2 behaves as expected.
// To build (on native Linux):
// clang -std=c++11 -O0 -g -flto -c test.cpp
// clang -flto -o test test.o
// 'llvm-dwarfdump test' shows no information for 'MyStruct'
__attribute__((noinline)) void use(int, int) { }
struct MyStruct {
int w;
int x;
int y;
int z;
int foo();
int bar();
};
int MyStruct::foo() {
return 3;
}
int main() {
MyStruct str{1, 2, 3, 4};
use(str.x, str.y);
return 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 28150] New: [DebugInfo] Extend vtable debug info metadata to handle MS ABI
https://llvm.org/bugs/show_bug.cgi?id=28150 Bug ID: 28150 Summary: [DebugInfo] Extend vtable debug info metadata to handle MS ABI Product: clang Version: unspecified Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: LLVM Codegen Assignee: unassignedclangb...@nondot.org Reporter: r...@google.com CC: amcca...@google.com, amjad.ab...@intel.com, apra...@apple.com, david.majne...@gmail.com, dblai...@gmail.com, llvm-bugs@lists.llvm.org Blocks: 12283 Classification: Unclassified Currently DISubprograms have these vtable related fields: - containingType: The parent class. Appears to be redundant with 'scope' for virtual methods. We could repurpose this to point to the record that actually contains the vfptr, since the vftable is very frequently not at offset 0 from 'this', and requires non-virtual and virtual adjustments. - virtuality: Only has none, virtual, and pure_virtual. We might want to extend this to include a notion of 'introducing', or we could encode that information some other way. - virtualIndex: Should be the vftable index obviously. For dwarf this is relative to the address point, and we can make this the vftable index pretty easily. CodeView only includes vftable offsets for introducing virtual methods, so we could set this to a sentinel value (-1) to indicate that the virtual method was not introduced in this class, and its offset can be found in the DWARF describing the base class. Another issue is that we can't assume that the frontend will provide complete debug info type information for base classes unless we enable -fstandalone-debug-info. This means we can't walk the entire class hierarchy in order to generate this information. Each DICompositeType has to be self-contained. This means we can't figure out which DICompositeType introduced a virtual method by walking the class hierarchy. -- 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 28151] New: [DebugInfo] Extend member pointer DI metadata to support the MS ABI
https://llvm.org/bugs/show_bug.cgi?id=28151 Bug ID: 28151 Summary: [DebugInfo] Extend member pointer DI metadata to support the MS ABI Product: clang Version: unspecified Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: LLVM Codegen Assignee: unassignedclangb...@nondot.org Reporter: r...@google.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified We need to pass the member pointer representation information through the member pointer type. This only requires 2 bits, but I'm not sure where they should live in the DIDerivedType that we use for DW_TAG_ptr_to_member. I'm inclined to steal the bits from 'flags', rather than trying to reuse the 'offsetInBits' or 'line' fields, which are not used with DW_TAG_ptr_to_member. -- 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 28152] New: [codeview] Include nested classes in the class member list, at least when generating codeview
https://llvm.org/bugs/show_bug.cgi?id=28152
Bug ID: 28152
Summary: [codeview] Include nested classes in the class member
list, at least when generating codeview
Product: clang
Version: unspecified
Hardware: PC
OS: Windows NT
Status: NEW
Severity: normal
Priority: P
Component: LLVM Codegen
Assignee: unassignedclangb...@nondot.org
Reporter: r...@google.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
MSVC records information about nested classes in its equivalent of our member
list. We should do the same.
The existing DI representation encodes this information with a parent scope
pointer, but that information is only present when we bother to emit
information about the nested type. In this example, 'Nested' is not mentioned
anywhere in our debug info:
struct A { struct Nested {}; } a;
We want our member lists for any given type to always be the same so that the
type records are bitwise identical across TUs. IMO we should go ahead and add
nested classes to the member list.
--
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 28153] New: 64-bit divide by constant on 32-bit targets poorly optimised
https://llvm.org/bugs/show_bug.cgi?id=28153
Bug ID: 28153
Summary: 64-bit divide by constant on 32-bit targets poorly
optimised
Product: new-bugs
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: simon.ho...@arm.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
Given:
int64_t fn(int x) {
return x / (int64_t)1000;
}
We can see that this could trivially be implemented as a 32-bit divide, and in
turn replaced with a reciprocal multiply. Unfortunately, on 32-bit platforms
(tried ARM and x86) we get a call to a divide function instead:
asr r1, r0, #31
mov r2, #1000
mov r3, #0
bl __aeabi_ldivmod
Simply remove the cast from the constant to see preferable code:
ldr r1, .LCPI1_0
smmul r0, r0, r1
asr r1, r0, #6
add r0, r1, r0, lsr #31
asr r1, r0, #31
The cast to 64-bit comes from `X_PER_Y` constants where it might want to imply
64-bit promotion when used in multiplication. Changing the code isn't an
option because of the errors it could introduce (and it looks weird next to the
constants that do need to be 64-bit, too).
--
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 28154] New: [meta] Add support for CodeView, the MSVC-compatible debug information format
https://llvm.org/bugs/show_bug.cgi?id=28154 Bug ID: 28154 Summary: [meta] Add support for CodeView, the MSVC-compatible debug information format Product: libraries Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: DebugInfo Assignee: unassignedb...@nondot.org Reporter: r...@google.com CC: llvm-bugs@lists.llvm.org Blocks: 13707 Classification: Unclassified LLVM should be able to emit CodeView debug info, the format used by Microsoft's debuggers, profilers, etc. This is a meta bug to track functionality in this area. Please file CodeView issues and mark them as blocking this bug to track them. The current status is that using 'clang -g -gcodeview' (TODO: make -gcodeview imply -g) or 'clang-cl /Zi' or 'clang-cl /Z7' will emit CodeView into COFF objects. We describe local variables, globals, and functions, but there are major gaps. /Zi-style emission of type info into PDBs is not on the immediate roadmap. --- We had a bug from 2012 to implement this, but I'm reopening with a clean slate since the original reporter doesn't want to receive meta-bug update spam. -- 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 13707] [meta] VCPP compatibility issues
https://llvm.org/bugs/show_bug.cgi?id=13707 Bug 13707 depends on bug 12283, which changed state. Bug 12283 Summary: [meta] Add support for CodeView, the MSVC-compatible debug information format https://llvm.org/bugs/show_bug.cgi?id=12283 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 12283] [meta] Add support for CodeView, the MSVC-compatible debug information format
https://llvm.org/bugs/show_bug.cgi?id=12283 Reid Kleckner changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Reid Kleckner --- Some of the original reporters and commenters may not want to receive updates, so I'm going to open a new meta bug and then mark everything blocked on that. The original intent of this bug was just to get backtraces, and we got that long ago. You can get more updates over at https://llvm.org/bugs/show_bug.cgi?id=28154. -- 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 28155] New: crash at -Os and above in both 32-bit and 64-bit modes on x86_64-linux-gnu with "-g" (Assertion `TargetRegisterInfo::isVirtualRegister(VReg) && "Not a vreg?"' failed)
ng-3.9+0x17eeaeb)
#21 0x017eedff llvm::legacy::PassManagerImpl::run(llvm::Module&)
(/usr/local/clang-trunk/bin/clang-3.9+0x17eedff)
#22 0x01c959da clang::EmitBackendOutput(clang::DiagnosticsEngine&,
clang::CodeGenOptions const&, clang::TargetOptions const&, clang::LangOptions
const&, llvm::DataLayout const&, llvm::Module*, clang::BackendAction,
llvm::raw_pwrite_stream*) (/usr/local/clang-trunk/bin/clang-3.9+0x1c959da)
#23 0x0226a956
clang::BackendConsumer::HandleTranslationUnit(clang::ASTContext&)
(/usr/local/clang-trunk/bin/clang-3.9+0x226a956)
#24 0x025a29cb clang::ParseAST(clang::Sema&, bool, bool)
(/usr/local/clang-trunk/bin/clang-3.9+0x25a29cb)
#25 0x0226ad1e clang::CodeGenAction::ExecuteAction()
(/usr/local/clang-trunk/bin/clang-3.9+0x226ad1e)
#26 0x01f98da6 clang::FrontendAction::Execute()
(/usr/local/clang-trunk/bin/clang-3.9+0x1f98da6)
#27 0x01f7440e
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&)
(/usr/local/clang-trunk/bin/clang-3.9+0x1f7440e)
#28 0x0201dc9c
clang::ExecuteCompilerInvocation(clang::CompilerInstance*)
(/usr/local/clang-trunk/bin/clang-3.9+0x201dc9c)
#29 0x00a174f8 cc1_main(llvm::ArrayRef, char const*,
void*) (/usr/local/clang-trunk/bin/clang-3.9+0xa174f8)
#30 0x009ca627 main (/usr/local/clang-trunk/bin/clang-3.9+0x9ca627)
#31 0x7ffbc1a85f45 __libc_start_main
/build/eglibc-oGUzwX/eglibc-2.19/csu/libc-start.c:321:0
#32 0x00a134c4 _start (/usr/local/clang-trunk/bin/clang-3.9+0xa134c4)
Stack dump:
0.Program arguments: /usr/local/clang-trunk/bin/clang-3.9 -cc1 -triple
x86_64-unknown-linux-gnu -emit-obj -disable-free -main-file-name small.c
-mrelocation-model static -mthread-model posix -fmath-errno -masm-verbose
-mconstructor-aliases -munwind-tables -fuse-init-array -target-cpu x86-64
-momit-leaf-frame-pointer -dwarf-column-info -debug-info-kind=limited
-dwarf-version=4 -debugger-tuning=gdb -resource-dir
/usr/local/clang-trunk/bin/../lib/clang/3.9.0 -c-isystem . -c-isystem
/usr/local/include/csmith-2.2.0/ -internal-isystem /usr/local/include
-internal-isystem /usr/local/clang-trunk/bin/../lib/clang/3.9.0/include
-internal-externc-isystem /usr/include/x86_64-linux-gnu
-internal-externc-isystem /include -internal-externc-isystem /usr/include -O3
-w -fdebug-compilation-dir
/home/cnsun/ramdisk/reduction/20160615-clang-trunk-m32-g-O3-build-131611/delta
-ferror-limit 19 -fmessage-length 118 -fobjc-runtime=gcc
-fdiagnostics-show-option -fcolor-diagnostics -vectorize-loops -vectorize-slp
-o /tmp/small-6bd7c0.o -x c small.c
1. parser at end of file
2.Code generation
3.Running pass 'Function Pass Manager' on module 'small.c'.
4.Running pass 'X86 DAG->DAG Instruction Selection' on function '@main'
clang-3.9: error: unable to execute command: Aborted (core dumped)
clang-3.9: error: clang frontend command failed due to signal (use -v to see
invocation)
clang version 3.9.0 (trunk 272796)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /usr/local/bin
clang-3.9: note: diagnostic msg: PLEASE submit a bug report to
http://llvm.org/bugs/ and include the crash backtrace, preprocessed source, and
associated run script.
clang-3.9: note: diagnostic msg:
PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
Preprocessed source(s) and associated run script(s) are located at:
clang-3.9: note: diagnostic msg: /tmp/small-f378da.c
clang-3.9: note: diagnostic msg: /tmp/small-f378da.sh
clang-3.9: note: diagnostic msg:
$:
$: cat small.c
char a;
int volatile e;
short c, i;
short *d;
char fn1(int e) { return -a; }
short fn2(short p1, short p2) { return p1 * p2; }
int main () {
short g;
i = fn2(a, e);
*d = i;
g = fn2(c, 0 >= fn1(e));
if (g)
e;
return 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
