[llvm-bugs] [Bug 33724] New: clang++ 4.0.1 crashes on probably invalid input
https://bugs.llvm.org/show_bug.cgi?id=33724 Bug ID: 33724 Summary: clang++ 4.0.1 crashes on probably invalid input Product: clang Version: 4.0 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: C++ Assignee: unassignedclangb...@nondot.org Reporter: jeffrey.don...@gmail.com CC: dgre...@apple.com, llvm-bugs@lists.llvm.org Files are too large, they're at: https://s3.amazonaws.com/jgd-public/line-thickness-bbac64.cpp https://s3.amazonaws.com/jgd-public/line-thickness-bbac64.sh /usr/local/llvm/bin/clang++ -DQT_CORE_LIB -DQT_GUI_LIB -DQT_WIDGETS_LIB -I/mnt/raid/projects/shelf/c++/simulated-annealing/build -I/mnt/raid/projects/shelf/c++/simulated-annealing -I/mnt/raid/projects/shelf/c++/simulated-annealing/build/sa-app_autogen/include -isystem /usr/local/qt-5/5.7/gcc_64/include -isystem /usr/local/qt-5/5.7/gcc_64/include/QtWidgets -isystem /usr/local/qt-5/5.7/gcc_64/include/QtGui -isystem /usr/local/qt-5/5.7/gcc_64/include/QtCore -isystem /usr/local/qt-5/5.7/gcc_64/./mkspecs/linux-g++ -Wall -Wextra -pedantic -fPIC -g -fPIC -pthread -std=gnu++1z -o CMakeFiles/sa-app.dir/source/line-thickness.cpp.o -c /mnt/raid/projects/shelf/c++/simulated-annealing/source/line-thickness.cpp /mnt/raid/projects/shelf/c++/simulated-annealing/source/line-thickness.cpp:9:1: error: unknown type name 'ThicknessMap' ThicknessMap g_thickness_map; ^ /mnt/raid/projects/shelf/c++/simulated-annealing/source/line-thickness.cpp:13:16: error: use of undeclared identifier 'bucket_of_value' int bucket = bucket_of_value(b); ^ clang-4.0: /space/software/mkclang-4.0.1/llvm-4.0.1/tools/clang/include/clang/AST/DeclTemplate.h:1679: void clang::ClassTemplateSpecializationDecl::setPointOfInstantiation(clang::SourceLocation): Assertion `Loc.isValid() && "point of instantiation must be valid!"' failed. #0 0x01a381e5 llvm::sys::PrintStackTrace(llvm::raw_ostream&) (/usr/local/llvm-4.0.1/bin/clang-4.0+0x1a381e5) #1 0x01a388b6 SignalHandler(int) (/usr/local/llvm-4.0.1/bin/clang-4.0+0x1a388b6) #2 0x7fe0db5af390 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x11390) #3 0x7fe0da0f3428 gsignal /build/glibc-bfm8X4/glibc-2.23/signal/../sysdeps/unix/sysv/linux/raise.c:54:0 #4 0x7fe0da0f502a abort /build/glibc-bfm8X4/glibc-2.23/stdlib/abort.c:91:0 #5 0x7fe0da0ebbd7 __assert_fail_base /build/glibc-bfm8X4/glibc-2.23/assert/assert.c:92:0 #6 0x7fe0da0ebc82 (/lib/x86_64-linux-gnu/libc.so.6+0x2dc82) #7 0x02dd292f clang::Sema::InstantiateClass(clang::SourceLocation, clang::CXXRecordDecl*, clang::CXXRecordDecl*, clang::MultiLevelTemplateArgumentList const&, clang::TemplateSpecializationKind, bool) (/usr/local/llvm-4.0.1/bin/clang-4.0+0x2dd292f) #8 0x02dd3e13 clang::Sema::InstantiateClassTemplateSpecialization(clang::SourceLocation, clang::ClassTemplateSpecializationDecl*, clang::TemplateSpecializationKind, bool) (/usr/local/llvm-4.0.1/bin/clang-4.0+0x2dd3e13) #9 0x02e3c2b2 clang::Sema::RequireCompleteTypeImpl(clang::SourceLocation, clang::QualType, clang::Sema::TypeDiagnoser*) (/usr/local/llvm-4.0.1/bin/clang-4.0+0x2e3c2b2) #10 0x02cc7cd9 clang::Sema::AddMemberOperatorCandidates(clang::OverloadedOperatorKind, clang::SourceLocation, llvm::ArrayRef, clang::OverloadCandidateSet&, clang::SourceRange) (/usr/local/llvm-4.0.1/bin/clang-4.0+0x2cc7cd9) #11 0x02cdb48d clang::Sema::CreateOverloadedArraySubscriptExpr(clang::SourceLocation, clang::SourceLocation, clang::Expr*, clang::Expr*) (/usr/local/llvm-4.0.1/bin/clang-4.0+0x2cdb48d) #12 0x02b940af (anonymous namespace)::TransformTypos::TryTransform(clang::Expr*) (/usr/local/llvm-4.0.1/bin/clang-4.0+0x2b940af) #13 0x02b75d93 clang::Sema::CorrectDelayedTyposInExpr(clang::Expr*, clang::VarDecl*, llvm::function_ref (clang::Expr*)>) (/usr/local/llvm-4.0.1/bin/clang-4.0+0x2b75d93) #14 0x02b90523 clang::Sema::ActOnFinishFullExpr(clang::Expr*, clang::SourceLocation, bool, bool, bool) (/usr/local/llvm-4.0.1/bin/clang-4.0+0x2b90523) #15 0x02d0a325 clang::Sema::BuildReturnStmt(clang::SourceLocation, clang::Expr*) (/usr/local/llvm-4.0.1/bin/clang-4.0+0x2d0a325) #16 0x02d097d5 clang::Sema::ActOnReturnStmt(clang::SourceLocation, clang::Expr*, clang::Scope*) (/usr/local/llvm-4.0.1/bin/clang-4.0+0x2d097d5) #17 0x02751479 clang::Parser::ParseReturnStatement() (/usr/local/llvm-4.0.1/bin/clang-4.0+0x2751479) #18 0x0274c44a clang::Parser::ParseStatementOrDeclarationAfterAttributes(llvm::SmallVector&, clang::Parser::AllowedContsructsKind, clang::SourceLocation*, clang::Parser::ParsedAttributesWithRange&) (/usr/local/llvm-4.0.1/bin/clang-4.0+0x274c44a) #19 0x0274bb10 clang::Parser::ParseStatementOrDeclaration(llvm::SmallVector&, clang::Parser::AllowedContsructsKind, clang::SourceLocation*) (/usr/local/llvm
[llvm-bugs] [Bug 32940] Failure to recognise consecutive load chain from i64 types on 32-bit target
https://bugs.llvm.org/show_bug.cgi?id=32940 Simon Pilgrim changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Simon Pilgrim --- Fixed by rL307114 - thanks Nirav -- 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 25003] x86-64 assembler: using traditional 8-bit regs DH, CH, AH, BH with REX instructions should error
https://bugs.llvm.org/show_bug.cgi?id=25003 Simon Pilgrim changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED CC||llvm-...@redking.me.uk --- Comment #2 from Simon Pilgrim --- rL252743 -- 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 33725] New: std::basic_stringbuf can't handle put areas > 2GB
https://bugs.llvm.org/show_bug.cgi?id=33725
Bug ID: 33725
Summary: std::basic_stringbuf can't handle put areas > 2GB
Product: libc++
Version: 4.0
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P
Component: All Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: zi...@kayari.org
CC: llvm-bugs@lists.llvm.org, mclow.li...@gmail.com
This crashes on x86_64:
#include
int main()
{
std::string str(2147483648, 'a');
std::stringbuf sb(str, std::ios::ate|std::ios::out);
sb.sputc('a');
}
The problem is that the xnext pointer for the put area is below the xbeg
pointer, so the sputc write happens outside the std::string member.
#include
#include
struct SB : std::stringbuf
{
SB() : std::stringbuf(std::ios::ate|std::ios::out) { }
const char* pubpbase() const { return pbase(); }
const char* pubpptr() const { return pptr(); }
};
int main()
{
std::string str(2147483648, 'a');
SB sb;
sb.str(str);
assert(sb.pubpbase() <= sb.pubpptr());
}
a.out: ss.cc:16: int main(): Assertion `sb.pubpbase() <= sb.pubpptr()' failed.
The problem is that a 64-bit value is passed to basic_streambuf::pbump(int)
which overflows, producing a large negative value that gets added to the pbase
pointer. You need to call pbump in a loop when the argument is greater than
MAX_INT.
--
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 33726] New: "string.h" called by "string.h" itself but not found
https://bugs.llvm.org/show_bug.cgi?id=33726 Bug ID: 33726 Summary: "string.h" called by "string.h" itself but not found Product: clang Version: unspecified Hardware: Macintosh OS: MacOS X Status: NEW Severity: normal Priority: P Component: C++11 Assignee: unassignedclangb...@nondot.org Reporter: m...@tiferrei.com CC: dgre...@apple.com, llvm-bugs@lists.llvm.org Created attachment 18769 --> https://bugs.llvm.org/attachment.cgi?id=18769&action=edit Output log from compilation Hello there, I was trying to compile a simple AST parser from this guide: https://jonasdevlieghere.com/understanding-the-clang-ast/ but I run into some trouble where the string.h file, indirectly referenced by AST.h is not found... even though this file seems to be calling a local version of itself. I have attached the output log. I'm sorry if this is a beginner question, I'm new to all this Clang world. Thank you, Tiago -- 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 33727] New: std::basic_stringbuf only works with DefaultConstructible allocators
https://bugs.llvm.org/show_bug.cgi?id=33727
Bug ID: 33727
Summary: std::basic_stringbuf only works with
DefaultConstructible allocators
Product: libc++
Version: 4.0
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P
Component: All Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: zi...@kayari.org
CC: llvm-bugs@lists.llvm.org, mclow.li...@gmail.com
This doesn't compile:
#include
#include
#include
template
struct Alloc : std::allocator
{
template struct rebind { using other = Alloc; };
Alloc(int id) : id(id) { }
template Alloc(const Alloc& a) : id(a.id) { }
int id;
};
using string = std::basic_string, Alloc>;
using stringbuf = std::basic_stringbuf,
Alloc>;
int main()
{
string s(Alloc(1));
stringbuf b(s);
assert( b.str().get_allocator() == s.get_allocator() );
}
The basic_stringbuf constructor default-initializes its basic_string member,
which default-initializes its allocator.
--
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 33683] libLLVM-4.0.so should not be built with -fno-rtti (was Missing symbol `typeinfo for llvm::raw_ostream' in libLLVM-4.0.so)
https://bugs.llvm.org/show_bug.cgi?id=33683 Jonathan Roelofs changed: What|Removed |Added Resolution|--- |WONTFIX Status|REOPENED|RESOLVED --- Comment #6 from Jonathan Roelofs --- You'll have to build it yourself without the flag, or petition your package maintainer to do so. -- 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 33728] New: clang aborts when compiling
https://bugs.llvm.org/show_bug.cgi?id=33728 Bug ID: 33728 Summary: clang aborts when compiling Product: clang Version: 4.0 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: C++ Assignee: unassignedclangb...@nondot.org Reporter: nadiasver...@gmail.com CC: dgre...@apple.com, llvm-bugs@lists.llvm.org FAILED: /usr/bin/clang++-4.0 -DARTICLE_DLL -DBASE_DLL -DCORE_DLL -DCORE_DLL_EXPORTS -DFMT_SHARED -DGSL_THROW_ON_CONTRACT_VIOLATION -DIDL_DLL -DIDL_IMPORTS_DLL_EXPORTS -DMINIZIP_DLL -DMODEL_DLL -DPRESENTATION_DLL -DPRODUCT_DLL -DRE2DLL -DRESOURCE_DLL -DSESSION_DLL -DSIGNATURE_DLL -DTCU_DLL -DUTIL_DLL -DZLIB_DLL -Dcore_EXPORTS -I. -I../../../../../include -I../../../../../idl/include -isystem ../../../../../.mm/linux/amd64/release/include -I../../../../../.mm/linux/amd64/release/include/gsl -I../../../../../.mm/linux/amd64/release/include/libuv -I../../../../../ -I../../../../../third-party/pybind11-2.1/include -I/usr/include/python3.5m -I../../../../../generated -Werror -std=c++14 -stdlib=libc++ -fvisibility=hidden -fPIC -fdiagnostics-color=always -O3 -DNDEBUG -fPIC -MD -MT CMakeFiles/core.dir/generated/article_submodule.cpp.o -MF CMakeFiles/core.dir/generated/article_submodule.cpp.o.d -o CMakeFiles/core.dir/generated/article_submodule.cpp.o -c ../../../../../generated/article_submodule.cpp clang: error: unable to execute command: Killed clang: error: clang frontend command failed due to signal (use -v to see invocation) clang version 4.0.1-svn305187-1~exp1 (branches/release_40) Target: x86_64-unknown-linux-gnu Thread model: posix InstalledDir: /usr/bin -- 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 32892] Runtime shouldn't send people to Intel to report bugs!
https://bugs.llvm.org/show_bug.cgi?id=32892 NODA, Kai changed: What|Removed |Added CC||noda...@gmail.com Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from NODA, Kai --- Fixed by https://reviews.llvm.org/D35018 -- 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 33729] New: Drop xlocale.h usage on glibc systems
https://bugs.llvm.org/show_bug.cgi?id=33729 Bug ID: 33729 Summary: Drop xlocale.h usage on glibc systems Product: libc++ Version: 4.0 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: unassignedclangb...@nondot.org Reporter: kre...@email.com CC: llvm-bugs@lists.llvm.org, mclow.li...@gmail.com Starting with glibc 2.26, their copy of xlocale.h will be dropped. That file is included in include/__locale in libc++. Simple removal of glibc condition should be enough. See also: https://sourceware.org/git/?p=glibc.git;a=commit;h=f0be25b6336db7492e47d2e8e72eb8af53b5506d -- 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 25454] Invalid cast on csmith generated code: argument of incompatible type!
https://bugs.llvm.org/show_bug.cgi?id=25454 serge.guel...@telecom-bretagne.eu changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from serge.guel...@telecom-bretagne.eu --- Fixed in https://reviews.llvm.org/rL307554 -- 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 33730] New: Compile-time explosion in Live Debug Variables
https://bugs.llvm.org/show_bug.cgi?id=33730
Bug ID: 33730
Summary: Compile-time explosion in Live Debug Variables
Product: new-bugs
Version: trunk
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: rob.loug...@gmail.com
CC: llvm-bugs@lists.llvm.org
The following program takes over 40 minutes to compile with -g (3.5 GHz
Core-i7):
=== foo.c ==
extern int foobar(int, int, int, int, int);
int F(int i1, int i2, int i3, int i4, int i5) {
return foobar(i1, i2, i3, i4, i5);
}
#define L3(a, b, c, d, e) \
F(a,b,c,d,e) + F(a,b,c,d,e) + F(a,b,c,d,e) + F(a,b,c,d,e) + F(a,b,c,d,e) + \
F(a,b,c,d,e) + F(a,b,c,d,e) + F(a,b,c,d,e) + F(a,b,c,d,e) + F(a,b,c,d,e) + \
F(a,b,c,d,e) + F(a,b,c,d,e) + F(a,b,c,d,e) + F(a,b,c,d,e) + F(a,b,c,d,e)
#define L2(a, b, c, d, e) \
L3(a,b,c,d,e) + L3(a,b,c,d,e) + L3(a,b,c,d,e) + L3(a,b,c,d,e) + L3(a,b,c,d,e)
+ \
L3(a,b,c,d,e) + L3(a,b,c,d,e) + L3(a,b,c,d,e) + L3(a,b,c,d,e) + L3(a,b,c,d,e)
#define L1(a, b, c, d, e) \
L2(a,b,c,d,e) + L2(a,b,c,d,e) + L2(a,b,c,d,e) + L2(a,b,c,d,e) + L2(a,b,c,d,e)
+ \
L2(a,b,c,d,e) + L2(a,b,c,d,e) + L2(a,b,c,d,e) + L2(a,b,c,d,e) + L2(a,b,c,d,e)
int foo(int a, int b, int c, int d, int e) {
return L1(a,b,c,d,e);
}
$ time clang foo.c -O2 -c -g -mllvm -stats 2>&1 | grep livedebug
6384827 livedebugvars - Number of DBG_VALUEs inserted
real42m55.033s
user42m39.912s
sys 0m12.339s
>From the stats, we can see that Live Debug Variables has inserted over 6
million DBG_VALUEs. Compiling without -g it takes less than a minute:
$ time clang foo.c -O2 -c
real0m47.132s
user0m47.067s
sys 0m0.012s
The program creates 1500 identical inlined calls to foobar(). Each inlined
call generates 5 DBG_VALUEs for i1, i2, etc. All of the inlined calls are
contained within the same basic-block.
Live Debug Variables is split into 3 parts. The first part is an initial
analysis pass which removes the DBG_VALUEs (those that refer to virtual
registers), and replaces them with data structures that track the live user
variables. This pass occurs before register allocation.
As mentioned above, each variable i1, i2, etc. has 1500 DBG_VALUEs. Each of
these produces a separate entry in the data structure as they have different
debug locations (so there are now 1500 user variables for i1, 1500 for i2,
etc.).
Each set of 1500 user variables have the same location (virtual register
containing a copy of the incoming parameter a, b, c, etc.). When computing the
live intervals, each user variable ends up with an interval corresponding
mostly to the live interval of the virtual register. This covers almost the
entire basic-block, spanning all of the inlined calls. I believe this is the
fundamental cause of the problem. Each of the original DBG_VALUEs are
associated to only a small part of the entire live interval, corresponding to a
single inlined call. However, by giving all the user variables the live range
of the virtual register they become associated to all the inlined calls.
The next part of Live Debug Variables occurs during register allocation. When
splitting a virtual register Live Debug Variables is called to split the
corresponding user values. In the above program, each virtual register is the
location for 1500 user values. This means when the register allocator splits a
virtual register we end up splitting 1500 user values in Live Debug Variables.
When splitting a user value the interval corresponding to the location is
replaced by two new intervals (and two new locations). If one of the new
locations is subsequently split again the number of intervals will grow to
record all the live intervals. In the above test program, each debug value is
split over a thousand times (roughly once per inlined function), resulting in
over a thousand intervals per value (each set of 1500 values are split
identically).
Finally, after register allocation, the Debug Variables pass uses the updated
data structures to emit new DBG_VALUEs with physical registers (the call to
emitDebugValues() actually occurs during the Virtual Register Rewriter).
The emitDebugValues() function iterates over the user values and emits a new
DBG_VALUE for each interval/location after mapping the virtual registers to
physical (it also attempts to coalesce locations). As we have approx.
1500*1500*5 intervals it is easy to see why over 6 million DBG_VALUEs are
inserted (after coalescing).
The large number of DBG_VALUEs are a consequence of the initial live interval
given to the user values. As discussed above, each of the original virtual
registers are split repeatedly, until we end up wi
[llvm-bugs] [Bug 33731] New: [opt; GVN] input program causes "Instruction does not dominate uses" error
https://bugs.llvm.org/show_bug.cgi?id=33731 Bug ID: 33731 Summary: [opt; GVN] input program causes "Instruction does not dominate uses" error Product: new-bugs Version: 4.0 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: eric.schwe...@pgroup.com CC: llvm-bugs@lists.llvm.org Created attachment 18772 --> https://bugs.llvm.org/attachment.cgi?id=18772&action=edit reproduce the instruction does not dominate uses bug See the attached reproducer. To recreate the problem: % opt -verify reduced.bc -o /dev/null % opt -gvn reduced.bc -o /dev/null Instruction does not dominate all uses! %.pre = sext i32 %1 to i64 %6 = mul i64 %.pre, 4 LLVM ERROR: Broken function found, compilation aborted! % opt -version LLVM (http://llvm.org/): LLVM version 4.0.1 DEBUG build with assertions. Default target: x86_64-unknown-linux-gnu Host CPU: haswell -- 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 33732] New: -fsanitize-coverage=trace-cmp passes parameters incorrectly
https://bugs.llvm.org/show_bug.cgi?id=33732
Bug ID: 33732
Summary: -fsanitize-coverage=trace-cmp passes parameters
incorrectly
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: gli...@google.com
CC: dvyu...@google.com, k...@google.com,
llvm-bugs@lists.llvm.org
Consider the following program:
==dummy.ii
char *_copy_from_user(void *to, const void *from, unsigned n);
long dev_write(struct file *filep, const char *buffer) {
char s[16];
_copy_from_user(s, buffer, 1);
if (s[0] == 's')
return 1;
return 0;
}
==
When compiled as follows:
$ clang -O2 -fsanitize-coverage=trace-pc -fsanitize-coverage=trace-cmp -x c
dummy.ii -c -o dummy.o -w
it produces the following assembly:
$ objdump -dr dummy.o
dummy.o: file format elf64-x86-64
Disassembly of section .text:
:
0: 53 push %rbx
1: 48 83 ec 10 sub$0x10,%rsp
5: 48 89 f3mov%rsi,%rbx
8: e8 00 00 00 00 callq d
9: R_X86_64_PC32__sanitizer_cov_trace_pc-0x4
d: 48 89 e7mov%rsp,%rdi
10: ba 01 00 00 00 mov$0x1,%edx
15: 48 89 demov%rbx,%rsi
18: e8 00 00 00 00 callq 1d
19: R_X86_64_PC32 _copy_from_user-0x4
1d: 8b 1c 24mov(%rsp),%ebx
20: be 73 00 00 00 mov$0x73,%esi
25: 89 df mov%ebx,%edi
27: e8 00 00 00 00 callq 2c
28: R_X86_64_PC32 __sanitizer_cov_trace_cmp1-0x4
2c: 31 c0 xor%eax,%eax
2e: 80 fb 73cmp$0x73,%bl
31: 0f 94 c0sete %al
34: 48 83 c4 10 add$0x10,%rsp
38: 5b pop%rbx
39: c3 retq
Note that the first parameter to __sanitizer_cov_trace_cmp1() is a 4-byte value
taken directly from the stack, despite __sanitizer_cov_trace_cmp1() expects a
1-byte value.
This looks like a violation of the x86_64 ABI, which mandates that byte-sized
arguments are extended (in this case zero-extended) to the full register.
If I change the s[] size to, say, 1, Clang generates correct code:
d: 48 8d 7c 24 0f lea0xf(%rsp),%rdi
12: ba 01 00 00 00 mov$0x1,%edx
17: 48 89 demov%rbx,%rsi
1a: e8 00 00 00 00 callq 1f
1b: R_X86_64_PC32 _copy_from_user-0x4
1f: 0f b6 5c 24 0f movzbl 0xf(%rsp),%ebx
24: be 73 00 00 00 mov$0x73,%esi
29: 89 df mov%ebx,%edi
2b: e8 00 00 00 00 callq 30
2c: R_X86_64_PC32 __sanitizer_cov_trace_cmp1-0x4
--
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 33718] HexagonInstrInfo.cpp - enum constant in boolean context warning
https://bugs.llvm.org/show_bug.cgi?id=33718 Krzysztof Parzyszek changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED Assignee|unassignedb...@nondot.org |kparz...@codeaurora.org --- Comment #2 from Krzysztof Parzyszek --- Fixed in r307566. -- 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 27204] [PPC] Suboptimal code generated for integer load followed by conversion to floating point
https://bugs.llvm.org/show_bug.cgi?id=27204 l...@ca.ibm.com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from l...@ca.ibm.com --- commit rL307553 -- 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 33733] New: Invalid literal check for macro arguments
https://bugs.llvm.org/show_bug.cgi?id=33733
Bug ID: 33733
Summary: Invalid literal check for macro arguments
Product: clang
Version: 3.9
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: C++11
Assignee: unassignedclangb...@nondot.org
Reporter: j.llvm@lorenz-ho.me
CC: dgre...@apple.com, llvm-bugs@lists.llvm.org
Hi,
Minimal example:
$ cat main.cpp
#include
#define macro(x) #x
int main()
{
std::cout << macro("abc"S) << std::endl;
return 0;
}
g++ 5.4.0:
$ g++ -std=c++11 -Wall -Wextra main.cpp -o main
# (compiles without warnings or errors)
$ ./main
"abc"S
clang++ 3.9.1:
$ clang++ -std=c++11 -Wall -Wextra main.cpp -o main
main.cpp:6:26: error: invalid suffix on literal; C++11 requires a space
between literal and identifier [-Wreserved-user-defined-literal]
std::cout << macro("abc"S) << std::endl;
Assumption:
clang++ checks for the space between literal and identifier (it's only a check)
before precompilation, which is probably wrong, because literal evaluation is
not part of the precompiler?
Thanks on advance,
Johannes
--
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 33734] New: TextDiagnostic.cpp buildFixItInsertionLine assertion check failure of HintByteOffset
https://bugs.llvm.org/show_bug.cgi?id=33734
Bug ID: 33734
Summary: TextDiagnostic.cpp buildFixItInsertionLine assertion
check failure of HintByteOffset
Product: clang
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: Frontend
Assignee: unassignedclangb...@nondot.org
Reporter: c...@google.com
CC: llvm-bugs@lists.llvm.org
Clang-tidy performance-unnecessary-value-param checks causes this assertion
failure in TextDiagnostic.cpp,
when a function's definition and declaration are at the same line of different
files,
and the declaration line is longer then the definition line.
If clang-tidy is built without assertion checks, it does not abort,
but the "displayed" suggested fix line is wrong.
The actual applied fix is correct.
The following test case is reduced from one Android source file.
Note that t.h declares f1 at line 5 and f2 at line 6.
t.cc defines f1 at line 3 and f2 at line 6.
Declaration lines of f1 and f2 in t.h are longer than
the header lines of f1 and f2 in t.cc.
$ cat t.h
struct ABC {
ABC(const ABC&);
int get(int) const;
};
int f1(int n, ABC v); // line 5
int f2(int n, ABC v); // line 6
$ cat t.cc
#include "t.h"
// line 2
int f1(int n, ABC v) {
return v.get(n);
}
int f2(int n, ABC v) {
return v.get(n);
}
## Current output from clang-tidy release build, without
-DLLVM_ENABLE_ASSERTIONS
(clang-tidy did not abort, but suggested fix line for f2 is wrong)
clang_tidy -checks=*,-anal*,-cppcoreguide*,-llvm*,-hicpp* -header-filter=.*
/tmp/t.cc --
2 warnings generated.
/tmp/t.cc:3:19: warning: the parameter 'v' is copied for each invocation but
only used as a const reference; consider making it a const reference
[performance-unnecessary-value-param]
int f1(int n, ABC v) {
~~~ ^
/tmp/t.cc:6:19: warning: the parameter 'v' is copied for each invocation but
only used as a const reference; consider making it a const reference
[performance-unnecessary-value-param]
int f2(int n, ABC v) {
~~~ ^
const & const &
## Current output from clang-tidy release build, with
-DLLVM_ENABLE_ASSERTIONS=On
(clang-tidy has assertion error)
.../llvm.307566/build/bin/clang-tidy
-checks=*,-anal*,-cppcoreguide*,-llvm*,-hicpp* -header-filter=.* /tmp/t.cc --
2 warnings generated.
/tmp/t.cc:3:19: warning: the parameter 'v' is copied for each invocation but
only used as a const reference; consider making it a const reference
[performance-unnecessary-value-param]
int f1(int n, ABC v) {
~~~ ^
/tmp/t.cc:6:19: warning: the parameter 'v' is copied for each invocation but
only used as a const reference; consider making it a const reference
[performance-unnecessary-value-param]
clang-tidy:
.../llvm.307566/llvm/tools/clang/lib/Frontend/TextDiagnostic.cpp:1083:
std::string buildFixItInsertionLine(unsigned int, const
{anonymous}::SourceColumnMap&, llvm::ArrayRef, const
clang::SourceManager&, const clang::DiagnosticOptions*): Assertion
`HintByteOffset < static_cast(map.bytes())+1' failed.
Aborted (core dumped)
## Expected output:
.../llvm.FID/build/bin/clang-tidy
-checks=*,-anal*,-cppcoreguide*,-llvm*,-hicpp* -header-filter=.* /tmp/t.cc --
2 warnings generated.
/tmp/t.cc:3:19: warning: the parameter 'v' is copied for each invocation but
only used as a const reference; consider making it a const reference
[performance-unnecessary-value-param]
int f1(int n, ABC v) {
~~~ ^
const &
/tmp/t.cc:6:19: warning: the parameter 'v' is copied for each invocation but
only used as a const reference; consider making it a const reference
[performance-unnecessary-value-param]
int f2(int n, ABC v) {
~~~ ^
const &
--
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 33735] New: Clang cannot parse xstring in Visual Studio 2017
https://bugs.llvm.org/show_bug.cgi?id=33735 Bug ID: 33735 Summary: Clang cannot parse xstring in Visual Studio 2017 Product: clang Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: libclang Assignee: unassignedclangb...@nondot.org Reporter: dpldob...@protonmail.com CC: kli...@google.com, llvm-bugs@lists.llvm.org I get the following error when parsing: c:/Program Files (x86)/Microsoft Visual Studio/2017/Community/VC/Tools/MSVC/14.10.25017/include\xstring:1905:26: error: constexpr variable '_Memcpy_move_offset' must be initialized by a constant expression static constexpr size_t _Memcpy_move_offset = offsetof(_Mydata_t, _Bx); ^ I understand this is a non-conforming C++ construct. However, shouldn't there be a way for Clang to cope with it by using a certain set of flags? Shouldn't "-fms-extensions" and/or "-fms-compatibility" have worked? The same bug has been asked about at http://clang-developers.42468.n3.nabble.com/Working-around-unconformant-offsetof-in-msvc-td4056311.html . -- 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 33736] New: default member initialization and noexcept problems
https://bugs.llvm.org/show_bug.cgi?id=33736
Bug ID: 33736
Summary: default member initialization and noexcept problems
Product: clang
Version: 4.0
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P
Component: C++
Assignee: unassignedclangb...@nondot.org
Reporter: joe.sy...@gmail.com
CC: dgre...@apple.com, llvm-bugs@lists.llvm.org
I'm seeing an error that is similar to the question raised at
https://stackoverflow.com/questions/43819314. That question seems to not have
any consensus as to what the problem may be.
The following code produces a compile-time error in clang++ 4.0.0 and later,
but works fine in gcc as well as previous versions of clang.
#include
struct A {
A() noexcept = default;
A(const A&) noexcept = default;
std::shared_ptr _a {};
};
int main() {
return 0;
}
It's worth noting that if I remove the copy constructor, this compiles fine.
If I remove the noexcept qualification from the default constructor it also
compiles fine.
The error I'm getting is as follows:
:4:5: error: default member initializer for '_a' needed within
definition of enclosing class 'A' outside of member functions
A() noexcept = default;
^
/opt/compiler-explorer/clang-4.0.0/bin/../include/c++/v1/type_traits:1306:29:
note: in instantiation of template class 'std::__1::is_class' requested
here
template ::value>
^
/opt/compiler-explorer/clang-4.0.0/bin/../include/c++/v1/type_traits:1311:71:
note: in instantiation of default argument for '__libcpp_abstract'
required here
template struct _LIBCPP_TEMPLATE_VIS is_abstract : public
__libcpp_abstract<_Tp> {};
^~
/opt/compiler-explorer/clang-4.0.0/bin/../include/c++/v1/type_traits:1384:39:
note: in instantiation of template class 'std::__1::is_abstract'
requested here
!is_abstract<_T2>::value> {};
^
/opt/compiler-explorer/clang-4.0.0/bin/../include/c++/v1/memory:3918:39: note:
in instantiation of template class 'std::__1::is_convertible'
requested here
typename enable_if::value, __nat>::type = __nat())
^
/opt/compiler-explorer/clang-4.0.0/bin/../include/c++/v1/memory:3883:28: note:
while substituting deduced template arguments into function template
'shared_ptr' [with _Yp = int]
class _LIBCPP_TEMPLATE_VIS shared_ptr
^
:7:26: note: default member initializer declared here
std::shared_ptr _a {};
--
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 33538] Constant hoisting crashes AddressingModeMatcher::matchOperationAddr
https://bugs.llvm.org/show_bug.cgi?id=33538 Leo Li changed: What|Removed |Added Status|NEW |RESOLVED CC||a...@google.com Assignee|pir...@google.com |a...@google.com Resolution|--- |FIXED --- Comment #2 from Leo Li --- Fixed via: rL307587 rL307294 rL306704 -- 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 33737] New: Operand size suffixes are not supported on loop instructions
https://bugs.llvm.org/show_bug.cgi?id=33737 Bug ID: 33737 Summary: Operand size suffixes are not supported on loop instructions Product: libraries Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: Backend: X86 Assignee: unassignedb...@nondot.org Reporter: tbl...@icloud.com CC: llvm-bugs@lists.llvm.org loop((n)?z)?[wdq] are valid instruction mnemonics in GAS, but not in the LLVM assembler. -- 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 33738] New: LLD relocates weak symbols in static library incorrectly when using version script
https://bugs.llvm.org/show_bug.cgi?id=33738 Bug ID: 33738 Summary: LLD relocates weak symbols in static library incorrectly when using version script Product: lld Version: unspecified Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: ELF Assignee: unassignedb...@nondot.org Reporter: smee...@fb.com CC: compn...@compnerd.org, gri...@accesssoftek.com, llvm-bugs@lists.llvm.org, rafael.espind...@gmail.com, r...@google.com Created attachment 18773 --> https://bugs.llvm.org/attachment.cgi?id=18773&action=edit Reduced test case Refer to the attached reproduction tarball. If you run make and then disassemble libg.so, you should see something along the lines of 1000 : 1000: 55 push %rbp 1001: 48 89 e5mov%rsp,%rbp 1004: b0 00 mov$0x0,%al 1006: e8 f5 ef ff ff callq 0 100b: 5d pop%rbp 100c: c3 retq The callq to 0 is incorrect. Both ld.bfd and ld.gold produce something along the lines of 226: e8 e5 ff ff ff callq 210 Bizarrely (at least to me), it's the presence of the version script that causes this problem. If I remove that, LLD also produces the call to f@plt. The static library is also required to manifest the problem. Linking against f.o directly works both with and without the version script (it just pulls f into the library). I personally also find it odd that the call to f with a static library goes through the PLT instead of pulling f into the library, but it's consistent with bfd and gold, at least. -- 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 33739] New: Nested friend qualifiers seem to be ignored
https://bugs.llvm.org/show_bug.cgi?id=33739 Bug ID: 33739 Summary: Nested friend qualifiers seem to be ignored Product: clang Version: 4.0 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: C++ Assignee: unassignedclangb...@nondot.org Reporter: m...@trust-in-soft.com CC: dgre...@apple.com, llvm-bugs@lists.llvm.org Created attachment 18774 --> https://bugs.llvm.org/attachment.cgi?id=18774&action=edit nested friend statement testcase [class.friend]p6 allows a complete function to be declared inline in a friend statement. That function may contain local classes, which can in turn have other friend statements. These inner statements seem to be ignored. The attached simple example fails to compile with clang 3.8, 3.9 and 4.0. It compiles with gcc 5.4. -- 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 33536] LLVM Assertion failure with new-experimental-pass-manager and ThinLTO
https://bugs.llvm.org/show_bug.cgi?id=33536 Chandler Carruth changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #2 from Chandler Carruth --- I thought this was the same as a bug with a stale domtree I was working on, but it was actually different. The other bug fix didn't help. Fixed this finally in r307625 -- it was actually a bug in the ThinLTO bitcode writer. -- 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
