[llvm-bugs] [Bug 25294] New: Cannot jump to switch label when using blocks and ARC
https://llvm.org/bugs/show_bug.cgi?id=25294
Bug ID: 25294
Summary: Cannot jump to switch label when using blocks and ARC
Product: clang
Version: unspecified
Hardware: Macintosh
OS: MacOS X
Status: NEW
Severity: normal
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: w...@iki.fi
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
clang reports version: Apple LLVM version 7.0.0 (clang-700.1.76)
Target: x86_64-apple-darwin14.5.0
Consider the following code:
//---
int foo(int i)
{
NSString* str = [NSString new];
int(^func)() = nil;
switch(i)
{
case 0: func = ^{ return (int)str.length; }; break;
case 1: func = ^{ return (int)str.length; }; break;
}
return func();
}
//---
When compiling with ARC enabled, it gives the following error:
test.m:10:7: error: cannot jump from switch statement to this case label
case 1: func = ^{ return (int)str.length; }; break;
^
test.m:5:15: note: jump enters lifetime of block which strongly captures a
variable
NSString* str = [NSString new];
Note that these functions do not cause an error:
//---
int foo2(int i)
{
int value = i * 2;
int(^func)() = nil;
switch(i)
{
case 0: func = ^{ return value * 2; }; break;
case 1: func = ^{ return value * 3; }; break;
}
return func();
}
int(^foo3(int i))()
{
NSString* str = [NSString new];
switch(i)
{
case 0: return ^{ return (int)str.length; };
case 1: return ^{ return (int)str.length; };
}
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 25295] New: error: clang frontend command failed due to signal
https://llvm.org/bugs/show_bug.cgi?id=25295 Bug ID: 25295 Summary: error: clang frontend command failed due to signal Product: clang Version: 3.7 Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: -New Bugs Assignee: unassignedclangb...@nondot.org Reporter: idz...@126.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified Created attachment 15147 --> https://llvm.org/bugs/attachment.cgi?id=15147&action=edit Preprocessed source... I:\test\bug>clang++ a.cpp -O 0x04FCB8E2 (0x04FF3738 0x0028E418 0x 0x) 0x05059030 (0x0028E418 0x 0x 0x) 0x04FF3738 (0x 0x 0x 0x) 0x0028E418 (0x 0x 0x 0x) 0x (0x76F3E0E2 0x0028E4E8 0x0028E4E8 0x0028E5A8) clang++.exe: error: clang frontend command failed due to signal (use -v to see invocation) clang version 3.7.0 (tags/RELEASE_370/final) Target: i686-w64-windows-gnu Thread model: posix clang++.exe: 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++.exe: note: diagnostic msg: PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: Preprocessed source(s) and associated run script(s) are located at: clang++.exe: note: diagnostic msg: C:\Users\idzeta\AppData\Local\Temp\a-4c3fdf.cpp clang++.exe: note: diagnostic msg: C:\Users\idzeta\AppData\Local\Temp\a-4c3fdf.sh clang++.exe: note: diagnostic msg: Clang built and used with MinGW64 GCC 5.2.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 25296] New: LLDB have a lof of strict aliasing violation (based on GCC warnings)
https://llvm.org/bugs/show_bug.cgi?id=25296 Bug ID: 25296 Summary: LLDB have a lof of strict aliasing violation (based on GCC warnings) Product: lldb Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: lldb-...@lists.llvm.org Reporter: tbergham...@google.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified Compiling LLDB with GCC produces a lot of strict-aliasing warning. These warnings are currently turned of (in LLDBConfig.cmake) to reduce the noise they generate, but they should be fixed at some point as they might be real problems. After fixing all (most) of them the warning should be re-enabled to prevent the regression in new strict aliasing violations. -- 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 25297] New: Orc Compiler stopped work on Windows with MSVC + windows 7
https://llvm.org/bugs/show_bug.cgi?id=25297 Bug ID: 25297 Summary: Orc Compiler stopped work on Windows with MSVC + windows 7 Product: compiler-rt Version: 3.7 Hardware: PC OS: Windows 2000 Status: NEW Severity: normal Priority: P Component: compiler-rt Assignee: unassignedb...@nondot.org Reporter: mbsteixe...@gmail.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified Run any Kaleidoscope-orc on windows 7 and it will crash. There no function pointer. For example : def incr(x) x+1; incr(1); <-- it does not jit. My real case it crashes executing writeBytesUnaligned(0, Target, Value + RE.Addend); that is in the RuntimeDyldCOFFx86_64.h include file, line 99. -- 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 25168] BranchFolding drops MBBs referenced by CATCHRET/setjmp LEA
https://llvm.org/bugs/show_bug.cgi?id=25168 Joseph Tremoulet changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #16 from Joseph Tremoulet --- Fix checked in @r251113 -- 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 25222] clang is miscompiled
https://llvm.org/bugs/show_bug.cgi?id=25222 Sanjay Patel changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Sanjay Patel --- The patch was recommitted with a fix at: http://reviews.llvm.org/rL250743 Please let me know if you see any other problems from it. 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 25299] New: Assertion failure: use_empty() && "Uses remain when a value is destroyed!"
https://llvm.org/bugs/show_bug.cgi?id=25299
Bug ID: 25299
Summary: Assertion failure: use_empty() && "Uses remain when a
value is destroyed!"
Product: libraries
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: Scalar Optimizations
Assignee: unassignedb...@nondot.org
Reporter: a...@crichton.co
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
When running `opt -O2` over the bytecode attached here, this assertion is
generated:
While deleting: { i8*, i32 } %
Use still stuck around after Def is destroyed: %eh.lpad-body = phi { i8*, i32
} [ , %next.i.i.i.i ], [ , %unwind_custom_.i.i ], [ %20,
%next.i.i.i.18.i ], [ %20,
%"_ZN41collections..vec..Vec$LT$ast..TyParam$GT$10drop.5810217h641412e555c9adeeE.exit.i"
], [ %20,
%"_ZN41collections..vec..Vec$LT$ast..TyParam$GT$10drop.5810217h641412e555c9adeeE.exit.i"
], [ %20, %clean_custom_.i ]
Use still stuck around after Def is destroyed: %eh.lpad-body = phi { i8*, i32
} [ , %next.i.i.i.i ], [ , %unwind_custom_.i.i ], [ %20,
%next.i.i.i.18.i ], [ %20,
%"_ZN41collections..vec..Vec$LT$ast..TyParam$GT$10drop.5810217h641412e555c9adeeE.exit.i"
], [ %20,
%"_ZN41collections..vec..Vec$LT$ast..TyParam$GT$10drop.5810217h641412e555c9adeeE.exit.i"
], [ %20, %clean_custom_.i ]
opt: ../../../../src/llvm/lib/IR/Value.cpp:82: virtual llvm::Value::~Value():
Assertion `use_empty() && "Uses remain when a value is destroyed!"' failed.
Program received signal SIGABRT, Aborted.
0x76e09cc9 in __GI_raise (sig=sig@entry=6) at
../nptl/sysdeps/unix/sysv/linux/raise.c:56
56 ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0 0x76e09cc9 in __GI_raise (sig=sig@entry=6) at
../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1 0x76e0d0d8 in __GI_abort () at abort.c:89
#2 0x76e02b86 in __assert_fail_base (fmt=0x76f53830 "%s%s%s:%u:
%s%sAssertion `%s' failed.\n%n",
assertion=assertion@entry=0x18ae888 "use_empty() && \"Uses remain when a
value is destroyed!\"", file=file@entry=0x18ae0a8
"../../../../src/llvm/lib/IR/Value.cpp", line=line@entry=82,
function=function@entry=0x21a3cc0
"virtual llvm::Value::~Value()")
at assert.c:92
#3 0x76e02c32 in __GI___assert_fail (assertion=0x18ae888 "use_empty()
&& \"Uses remain when a value is destroyed!\"", file=0x18ae0a8
"../../../../src/llvm/lib/IR/Value.cpp", line=82,
function=0x21a3cc0 "virtual
llvm::Value::~Value()") at assert.c:101
#4 0x0170eb9f in llvm::Value::~Value() ()
#5 0x016c0a87 in llvm::LandingPadInst::~LandingPadInst() ()
#6 0x015c87dc in llvm::BasicBlock::~BasicBlock() ()
#7 0x015c8909 in llvm::BasicBlock::~BasicBlock() ()
#8 0x015c6fd2 in llvm::BasicBlock::eraseFromParent() ()
#9 0x01337685 in (anonymous
namespace)::SimplifyCFGOpt::SimplifyResume(llvm::ResumeInst*,
llvm::IRBuilder >&) [clone .isra.757]
()
#10 0x01341bc3 in llvm::SimplifyCFG(llvm::BasicBlock*,
llvm::TargetTransformInfo const&, unsigned int, llvm::AssumptionCache*) ()
#11 0x011e417a in simplifyFunctionCFG(llvm::Function&,
llvm::TargetTransformInfo const&, llvm::AssumptionCache*, int) ()
#12 0x016e6bc3 in llvm::FPPassManager::runOnFunction(llvm::Function&)
()
#13 0x013fd3c0 in (anonymous
namespace)::CGPassManager::runOnModule(llvm::Module&) ()
#14 0x016e728f in llvm::legacy::PassManagerImpl::run(llvm::Module&) ()
#15 0x00604082 in main ()
We ended up finding this when trying to upgrade from LLVM 3.7 to the current
trunk, and I tried running bugpoint over the bytecode but it unfortunately
didn't do too well about minimizing it. If you need any more info though please
just let me know!
--
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 25300] New: Certain environment variables crash lldb-server
https://llvm.org/bugs/show_bug.cgi?id=25300 Bug ID: 25300 Summary: Certain environment variables crash lldb-server Product: lldb Version: 3.7 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: lldb-...@lists.llvm.org Reporter: bob.eric.nel...@gmail.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified -- 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 25291] clang crashes on valid code at -Os and above on x86_64-linux-gnu (in 64-bit mode)
https://llvm.org/bugs/show_bug.cgi?id=25291 Tim Northover changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Tim Northover --- Should be fixed by r251145. -- 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 21193] Out of line template function declaration not matching any declaration causing null deference at clang/lib/Sema/SemaExpr.cpp:1786
https://llvm.org/bugs/show_bug.cgi?id=21193 Reid Kleckner changed: What|Removed |Added Status|NEW |RESOLVED CC||r...@google.com Resolution|--- |FIXED --- Comment #1 from Reid Kleckner --- This appears 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 25301] New: very chatty error on expr "(?)"
https://llvm.org/bugs/show_bug.cgi?id=25301
Bug ID: 25301
Summary: very chatty error on expr "(?)"
Product: clang
Version: unspecified
Hardware: PC
OS: Windows NT
Status: NEW
Severity: normal
Priority: P
Component: Frontend
Assignee: unassignedclangb...@nondot.org
Reporter: amcca...@google.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
consider:
void f() {
while (?) {
;
}
}
clang generates the following diagnostics:
error: expected expression
while (?) {
^
error: expected expression
while (?) {
^
error: expected ':'
while (?) {
^
:
note: to match this '?'
while (?) {
^
error: expected expression
while (?) {
^
--
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 25302] New: crash on invalid wild garbage
https://llvm.org/bugs/show_bug.cgi?id=25302
Bug ID: 25302
Summary: crash on invalid wild garbage
Product: clang
Version: unspecified
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: C++
Assignee: unassignedclangb...@nondot.org
Reporter: nlewy...@google.com
CC: dgre...@apple.com, llvm-bugs@lists.llvm.org
Classification: Unclassified
This is the best I've gotten to reduce out of creduce, out of a nearly-valid
input source. Reducing this is a huge pain, if I touch it, it breaks (ceases to
crash).
Testcase:
_1 fn1(_2, _3, _4) {
_1 < _4;
_1 = _5 __value> _1 * _1;
_1 = _6<_UIntType32> __value;
_Shift<_UIntType, __w> __value > __sum;
_M_carry = _M_x[long_lag ? From stdforward < F > (static_int < From);
::iterator_category a;
0 (_1, _1, _1,
_1) typename argle::
type p1_ typename 0::type p2_;
}
class A : Closure {
typedef Closure base;
FunctionSignature function, ::base::
};
I'm very sorry. Here's the crash:
clang:
/usr/local/google/home/nlewycky/llvm/src/tools/clang/include/clang/AST/Type.h:585:
const clang::ExtQualsTypeCommonBase* clang::QualType::getCommonPtr() const:
Assertion `!isNull() && "Cannot retrieve a NULL type pointer"' failed.
0 clang 0x02adfb88
llvm::sys::PrintStackTrace(llvm::raw_ostream&) + 44
1 clang 0x02adfe9d
2 clang 0x02ade62f llvm::sys::RunSignalHandlers() + 118
3 clang 0x02adea6f
4 libpthread.so.0 0x7f939e850340
5 libc.so.6 0x7f939da78cc9 gsignal + 57
6 libc.so.6 0x7f939da7c0d8 abort + 328
7 libc.so.6 0x7f939da71b86
8 libc.so.6 0x7f939da71c32
9 clang 0x02c77293
10 clang 0x02ce8f26
11 clang 0x04b88b29
12 clang 0x04b89566
clang::FormatASTNodeDiagnosticArgument(clang::DiagnosticsEngine::ArgumentKind,
long, llvm::StringRef, llvm::StringRef,
llvm::ArrayRef >,
llvm::SmallVectorImpl&, void*, llvm::ArrayRef) + 761
13 clang 0x02bf65c5
14 clang 0x02bf4ecd clang::Diagnostic::FormatDiagnostic(char
const*, char const*, llvm::SmallVectorImpl&) const + 4465
15 clang 0x02bf3d54
clang::Diagnostic::FormatDiagnostic(llvm::SmallVectorImpl&) const + 220
16 clang 0x031626d2
clang::TextDiagnosticPrinter::HandleDiagnostic(clang::DiagnosticsEngine::Level,
clang::Diagnostic const&) + 110
17 clang 0x02bfec51
clang::DiagnosticIDs::EmitDiag(clang::DiagnosticsEngine&,
clang::DiagnosticIDs::Level) const + 113
18 clang 0x02bfebd3
clang::DiagnosticIDs::ProcessDiag(clang::DiagnosticsEngine&) const + 705
19 clang 0x02bf6675
20 clang 0x02bf3488
clang::DiagnosticsEngine::EmitCurrentDiagnostic(bool) + 230
21 clang 0x04014e1b
clang::Sema::EmitCurrentDiagnostic(unsigned int) + 1225
22 clang 0x04002e52
23 clang 0x0403caef
clang::Sema::BuildCXXNestedNameSpecifier(clang::Scope*, clang::IdentifierInfo&,
clang::SourceLocation, clang::SourceLocation, clang::QualType, bool,
clang::CXXScopeSpec&, clang::NamedDecl*, bool, bool*) + 5979
24 clang 0x0403cdd6
clang::Sema::ActOnCXXNestedNameSpecifier(clang::Scope*, clang::IdentifierInfo&,
clang::SourceLocation, clang::SourceLocation,
clang::OpaquePtr, bool, clang::CXXScopeSpec&, bool, bool*) +
162
25 clang 0x03d8880e
clang::Parser::ParseOptionalCXXScopeSpecifier(clang::CXXScopeSpec&,
clang::OpaquePtr, bool, bool*, bool, clang::IdentifierInfo**)
+ 5080
26 clang 0x03d4d1d4
clang::Parser::ParseDeclaratorInternal(clang::Declarator&, void
(clang::Parser::*)(clang::Declarator&)) + 448
27 clang 0x03d4cf92
clang::Parser::ParseDeclarator(clang::Declarator&) + 50
28 clang 0x03d626ab
clang::Parser::ParseCXXMemberDeclaratorBeforeInitializer(clang::Declarator&,
clang::VirtSpecifiers&, clang::ActionResult&,
clang::Parser::LateParsedAttrList&) + 73
29 clang 0x03d65203
clang::Parser::ParseCXXClassMemberDeclaration(clang::AccessSpecifier,
clang::AttributeList*, clang::Parser::ParsedTemplateInfo const&,
clang::ParsingDeclRAIIObject*) + 7877
30 clang 0x03d65fe8
clang::Parser::ParseCXXClassMemberDeclarationWithPragmas(clang::AccessSpecifier&,
clang::Parser::ParsedAttributesWithRange&, clang::TypeSpecifierType,
clang::Decl*) + 1478
31 clang 0x03d6695f
clang::Parser::ParseCXXMemberSpecification(clang::SourceLocation,
clang::SourceLocation, clang::Parser::ParsedAttributesWithRange&, unsigned int,
clang::Decl*) + 2413
32 clang 0x03d6166f
clang::Parser::ParseClassSpecifier(clang::tok::TokenKind,
clang::Sour
[llvm-bugs] [Bug 25303] New: Unclosed namespace causes cryptic errors
https://llvm.org/bugs/show_bug.cgi?id=25303
Bug ID: 25303
Summary: Unclosed namespace causes cryptic errors
Product: clang
Version: unspecified
Hardware: PC
OS: Windows NT
Status: NEW
Severity: normal
Priority: P
Component: C++
Assignee: unassignedclangb...@nondot.org
Reporter: amcca...@google.com
CC: dgre...@apple.com, llvm-bugs@lists.llvm.org
Classification: Unclassified
consider:
namespace Foo {
namespace Bar { void thud(); }
void qux() {
::Bar::thud();
}
clang generates the following diagnostics:
error: no member named 'Bar' in the global namespace; did you mean simply
'Bar'?
::Bar::thud();
^
Bar
note: 'Bar' declared here
namespace Bar { void thud(); }
^
error: expected '}'
}
^
note: to match this '{'
namespace Foo {
^
2 errors generated.
It would have been nicer to recover by inserting a '}' before 'namespace Bar'.
--
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 25304] New: Support GCC's -fno-eliminate-unused-debug-types
https://llvm.org/bugs/show_bug.cgi?id=25304 Bug ID: 25304 Summary: Support GCC's -fno-eliminate-unused-debug-types Product: clang Version: trunk Hardware: All OS: All Status: NEW Severity: enhancement Priority: P Component: LLVM Codegen Assignee: unassignedclangb...@nondot.org Reporter: dblai...@gmail.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified Clang has no way to emit all debug info in the translation unit, regardless of whether or not those entities are used. GCC has a flag to opt in to such verbosity: "-fno-eliminate-unused-debug-types Normally, when producing DWARF 2 output, GCC avoids producing debug symbol output for types that are nowhere used in the source file being compiled. Sometimes it is useful to have GCC emit debugging information for all types declared in a compilation unit, regardless of whether or not they are actually used in that compilation unit, for example if, in the debugger, you want to cast a value to a type that is not actually used in your program (but is declared). More often, however, this results in a significant amount of wasted space." - https://gcc.gnu.org/onlinedocs/gcc/Debugging-Options.html I have no personal use for this option, but it's a sometimes-useful flag someone might want to implement at some point. -- 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 25304] Support GCC's -fno-eliminate-unused-debug-types
https://llvm.org/bugs/show_bug.cgi?id=25304 David Blaikie changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from David Blaikie --- Oops, didn't find the original bug first. *** This bug has been marked as a duplicate of bug 15184 *** -- 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 25305] New: Clang-cl generates a call to an undefined symbol __udivti3
https://llvm.org/bugs/show_bug.cgi?id=25305 Bug ID: 25305 Summary: Clang-cl generates a call to an undefined symbol __udivti3 Product: clang Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: LLVM Codegen Assignee: unassignedclangb...@nondot.org Reporter: driveha...@gmail.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified Created attachment 15150 --> https://llvm.org/bugs/attachment.cgi?id=15150&action=edit Build with: clang-cl main.c While attempting to build a (very) old version of libtomcrypt with Clang-cl (64-bit r250698), it appears a call to an undefined function is being generated: main-ff9827.obj : error LNK2019: unresolved external symbol __udivti3 referenced in function main I've attached a minimal reproduce case. This appears to be due to the "__attribute__((mode(TI)))" on the typedef. -- 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 25306] New: __attribute__((returns_nonnull)) does not work for std::add_pointer_t
https://llvm.org/bugs/show_bug.cgi?id=25306
Bug ID: 25306
Summary: __attribute__((returns_nonnull)) does not work for
std::add_pointer_t
Product: clang
Version: 3.7
Hardware: PC
OS: Windows NT
Status: NEW
Severity: normal
Priority: P
Component: Frontend
Assignee: unassignedclangb...@nondot.org
Reporter: frankhb1...@gmail.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
Case:
// clang++ -std=c++14 a.cc
#include
template
__attribute__((returns_nonnull)) std::add_pointer_t t()
{
static T obj;
return &obj;
}
int main()
{}
Diagnostics:
a.cc:4:16: warning: 'returns_nonnull' attribute only applies to return values
that are pointers
[-Wignored-attributes]
__attribute__((returns_nonnull)) std::add_pointer_t t()
On the other hand, G++ works.
--
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 25303] Unclosed namespace causes cryptic errors
https://llvm.org/bugs/show_bug.cgi?id=25303 Richard Smith changed: What|Removed |Added Status|NEW |RESOLVED CC||richard-l...@metafoo.co.uk Resolution|--- |WONTFIX --- Comment #1 from Richard Smith --- (In reply to comment #0) > It would have been nicer to recover by inserting a '}' before 'namespace > Bar'. That would require extreme lookahead or reverting a lot of parser state, both of which are not feasible. Nothing is obviously wrong here until we reach the ill-formed call to ::Bar::thud, and that error is indistinguishable from the nested name specifier on the call being wrong, which is what we say. I don't think this is feasible for us to improve, unless you have some specific suggestion for how we would detect the problem. -- 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
