[llvm-bugs] [Bug 25023] New: Byte order mark (BOM) leads to diagnostic: expected "FILENAME" or
https://llvm.org/bugs/show_bug.cgi?id=25023
Bug ID: 25023
Summary: Byte order mark (BOM) leads to diagnostic: expected
"FILENAME" or
Product: clang
Version: 3.7
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: libclang
Assignee: unassignedclangb...@nondot.org
Reporter: nikolai.kos...@theqtcompany.com
CC: kli...@google.com, llvm-bugs@lists.llvm.org
Classification: Unclassified
Created attachment 14978
--> https://llvm.org/bugs/attachment.cgi?id=14978&action=edit
Input files and test program using libclang.
...if CXTranslationUnit_PrecompiledPreamble and clang_reparseTranslationUnit()
is used. The preamble might be truncated due to that.
Consider the UTF-8 source file containing a BOM at the beginning (EF BB BF):
$ cat -v bomfile.cpp
M-oM-;M-?#include
int main() { return 0; }
...and the program making use of libclang, which can be configured to use a
preamble and set the reparse count:
$ cat libclangclient.cpp
#include
#include
#include
int main(int argc, char *argv[])
{
if (argc != 4) {
fprintf(stderr, "Usage: $0 \n");
return 0;
}
const bool usePreamble = (argv[2][0] == '1');
int reparseCount = atoi(argv[3]);
CXIndex index = clang_createIndex(0, /*displayDiagnostics*/ 1); // ...to
compare
const unsigned options = usePreamble ?
CXTranslationUnit_PrecompiledPreamble : CXTranslationUnit_None;
CXTranslationUnit tu = clang_parseTranslationUnit(index, argv[1], 0, 0,
NULL, 0, options);
for (;reparseCount; --reparseCount)
clang_reparseTranslationUnit(tu, 0, 0,
clang_defaultReparseOptions(tu));
const unsigned diagnosticCount = clang_getNumDiagnostics(tu);
for(unsigned i = 0; i < diagnosticCount; i++) {
const CXDiagnostic diagnostic = clang_getDiagnostic(tu, i);
const CXSourceLocation location =
clang_getDiagnosticLocation(diagnostic);
unsigned line, column;
clang_getSpellingLocation(location, NULL, &line, &column, NULL);
const CXString text = clang_getDiagnosticSpelling(diagnostic);
fprintf(stderr, "-- Extracted diagnostic: %u:%u: %s\n", line, column,
clang_getCString(text));
clang_disposeString(text);
}
return 0;
}
The output of the program consists of two lines:
* The first line comes from libclang due to clang_createIndex(0,1)
* The second line is generated with the help of clang_getDiagnostic().
Consider the runs with the following configurations:
$ ./libclangclient bomfile.cpp 0 0# OK, as expected
bomfile.cpp:1:13: fatal error: 'nonExistingHeader.h' file not found
-- Extracted diagnostic: 1:13: 'nonExistingHeader.h' file not found
$ ./libclangclient bomfile.cpp 1 0# OK, as expected
bomfile.cpp:1:13: fatal error: 'nonExistingHeader.h' file not found
-- Extracted diagnostic: 1:13: 'nonExistingHeader.h' file not found
$ ./libclangclient bomfile.cpp 0 1# OK, as expected
bomfile.cpp:1:13: fatal error: 'nonExistingHeader.h' file not found
-- Extracted diagnostic: 1:13: 'nonExistingHeader.h' file not found
$ ./libclangclient bomfile.cpp 1 1# OPS
bomfile.cpp:1:13: fatal error: 'nonExistingHeader.h' file not found
-- Extracted diagnostic: 1:33: expected "FILENAME" or
$ ./libclangclient bomfile.cpp 1 2# OPS
bomfile.cpp:1:13: fatal error: 'nonExistingHeader.h' file not found
-- Extracted diagnostic: 1:33: expected "FILENAME" or
Observations:
(1) As soon as the preamble option is activated and reparse count >= 1 a
misleading diagnostic will be printed. In real world source files with a
BOM much more diagnostics will be generated after that one (as if the
header file was not included...).
(2) Copy bomfile.cpp and append an extra '>' to the include line:
$ ./libclangclient bomfile_with_extra_angle.cpp 1 1
bomfile_with_extra_angle.cpp:1:34: warning: extra tokens at end of
#include directive [-Wextra-tokens]
bomfile_with_extra_angle.cpp:1:13: fatal error: 'nonExistingHeader.h'
file not found
-- Extracted diagnostic: 1:13: 'nonExistingHeader.h' file not found
--
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 25024] New: i trying to add a pass which will provide redundacy for fault tolerence but after when i am optimizing a bitcode with this pass it is showing segmentation fault
https://llvm.org/bugs/show_bug.cgi?id=25024 Bug ID: 25024 Summary: i trying to add a pass which will provide redundacy for fault tolerence but after when i am optimizing a bitcode with this pass it is showing segmentation fault Product: new-bugs Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: bamnepriyanka...@gmail.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified Created attachment 14979 --> https://llvm.org/bugs/attachment.cgi?id=14979&action=edit segmentation fault in a added pass If there is any other pass available for providing redundancy and i am not known of that please 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 25025] New: Compiling with -fms-extensions creates empty LC_LINKER_OPTION load command
https://llvm.org/bugs/show_bug.cgi?id=25025 Bug ID: 25025 Summary: Compiling with -fms-extensions creates empty LC_LINKER_OPTION load command Product: clang Version: 3.7 Hardware: Macintosh OS: MacOS X Status: NEW Severity: normal Priority: P Component: -New Bugs Assignee: unassignedclangb...@nondot.org Reporter: sebast...@theophil.net CC: llvm-bugs@lists.llvm.org Classification: Unclassified Created attachment 14980 --> https://llvm.org/bugs/attachment.cgi?id=14980&action=edit Reproduction I'm getting an annoying warning from ld since a while back. ld complains ld: warning: unknown linker option from object file ignored: '' in blabla.o When I dump the load commands in blabla.o using otool -l blabla.o I see this: Load command 4 cmd LC_LINKER_OPTION cmdsize 16 count 1 count 1 does not match number of strings 0 Indeed, there seems to be an empty linker option. I can reproduce this with a file from Microsoft's Casablanca REST SDK. I've attached a subset of the source code with which the problem can be reproduced. Unzip the files and compile: c++ -std=c++1y -I ./src/pch -I ./include/ -I path_to_boost/boost_1_59_0/ ./src/pplx/apple/pplxapple.cpp -fms-extensions -c -o pplxapple.o Removing -fms-extensions removes the empty linker option -- 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 23890] -fuse-ld doesn't recognize lld and path to ld
https://llvm.org/bugs/show_bug.cgi?id=23890 Rafael Ávila de Espíndola changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #5 from Rafael Ávila de Espíndola --- I don't think we should have that special logic in clang. What we have now instead is the ability to run lld from a symlink name ld.lld2 which runs the ELF2 linker. There is also discussion about supporting any absolute path in -fuse-ld. -- 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 23913] Use lld for stage 2 Clang build
https://llvm.org/bugs/show_bug.cgi?id=23913 Bug 23913 depends on bug 23890, which changed state. Bug 23890 Summary: -fuse-ld doesn't recognize lld and path to ld https://llvm.org/bugs/show_bug.cgi?id=23890 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX -- 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 25024] i trying to add a pass which will provide redundacy for fault tolerence but after when i am optimizing a bitcode with this pass it is showing segmentation fault
https://llvm.org/bugs/show_bug.cgi?id=25024 James Molloy changed: What|Removed |Added Status|NEW |RESOLVED CC||james.mol...@arm.com Resolution|--- |INVALID --- Comment #1 from James Molloy --- Hi, What do you expect us to do with this? You created a plugin pass, and it segfaults (which is probably an assertion failure if assertions were enabled). That's not something that we can help with, it's a bug in your code. What was the action you expected us to take here? Cheers, James -- 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 25026] New: updating gems fails at Updating bigdecimal
https://llvm.org/bugs/show_bug.cgi?id=25026 Bug ID: 25026 Summary: updating gems fails at Updating bigdecimal Product: new-bugs Version: 3.3 Hardware: Macintosh OS: MacOS X Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: cont...@jjay.net CC: llvm-bugs@lists.llvm.org Classification: Unclassified running > sudo gem update on the el capitan system from Apple fails. The process fails to build native extensions. -- 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 25027] New: Assertion failed when compiling RegAllocGreedy.cpp, line 980
https://llvm.org/bugs/show_bug.cgi?id=25027 Bug ID: 25027 Summary: Assertion failed when compiling RegAllocGreedy.cpp, line 980 Product: new-bugs Version: 3.3 Hardware: Macintosh OS: MacOS X Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: cont...@jjay.net CC: llvm-bugs@lists.llvm.org Classification: Unclassified when running gem update on el capitan, I have this issue : Updating json Building native extensions. This could take a while... ERROR: Error installing json: ERROR: Failed to build gem native extension. /usr/local/opt/ruby/bin/ruby -r ./siteconf20151002-8518-192duuc.rb extconf.rb creating Makefile make "DESTDIR=" clean make "DESTDIR=" compiling generator.c Assertion failed: (NumGlobalIntvs && "No global intervals configured"), function splitAroundRegion, file RegAllocGreedy.cpp, line 980. -- 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 25028] New: [mips64] Incorrect dwarf info
https://llvm.org/bugs/show_bug.cgi?id=25028 Bug ID: 25028 Summary: [mips64] Incorrect dwarf info Product: new-bugs Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: d...@codeplay.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified Created attachment 14983 --> https://llvm.org/bugs/attachment.cgi?id=14983&action=edit Bitcode Hi, I have got a case where the mips64el compiler creates incorrect dwarf info, as far as I can understand. The bitcode is originally generated from an Android RenderScript source file, attached for reference. It contains two functions (test1 and test2), both marked with the attribute no-frame-pointer-elim, which should keep the usage of the register $fp (r30). I am building the final object with: llc -relocation-model=pic -filetype=obj -mtriple=mips64el-none-linux-android -o dummy.o dummy.bc Looking into the generated assembler for the function test2: test2: 98: 60 fd bd 67 daddiu $sp, $sp, -672 9c: 98 02 bf ff sd $ra, 664($sp) a0: 90 02 be ff sd $fp, 656($sp) a4: 88 02 bc ff sd $gp, 648($sp) a8: 80 02 b7 ff sd $23, 640($sp) ac: 78 02 b6 ff sd $22, 632($sp) b0: 70 02 b5 ff sd $21, 624($sp) b4: 68 02 b4 ff sd $20, 616($sp) b8: 60 02 b3 ff sd $19, 608($sp) bc: 58 02 b2 ff sd $18, 600($sp) c0: 50 02 b1 ff sd $17, 592($sp) c4: 48 02 b0 ff sd $16, 584($sp) c8: 25 f0 a0 03 move $fp, $sp cc: e0 ff 1c 64 daddiu $gp, $zero, -32 d0: 24 e8 bc 03 and $sp, $sp, $gp d4: 00 08 04 00 sll $1, $4, 0 d8: 44 02 a1 af sw $1, 580($sp) dc: 44 02 a1 93 lbu $1, 580($sp) e0: 45 02 a2 93 lbu $2, 581($sp) e4: 46 02 a3 93 lbu $3, 582($sp) e8: 47 02 a4 93 lbu $4, 583($sp) ec: 43 02 a4 a3 sb $4, 579($sp) f0: 42 02 a3 a3 sb $3, 578($sp) f4: 41 02 a2 a3 sb $2, 577($sp) f8: 40 02 a1 a3 sb $1, 576($sp) fc: 01 00 01 64 daddiu $1, $zero, 1 100: 3c 0c 01 00 dsll32 $1, $1, 16 104: 18 00 02 3c lui $2, 24 108: 02 00 03 3c lui $3, 2 10c: 03 00 04 3c lui $4, 3 110: 61 00 05 24 addiu $5, $zero, 97 114: 3c 02 a5 a3 sb $5, 572($sp) ... The address 110 in .text should correspond to the assignment in the source file char_local = 'a';. Its value is subsequently stored at the position $sp + 572 . Note that the $fp and $sp match at the address c8, however the $sp is further moved at the address d0, potentially implying $sp != $fp hereafter. Looking at the dwarf info, it says that the base address for the function test2 is the $fp: <1><46>: Abbrev Number: 3 (DW_TAG_subprogram) <47> DW_AT_low_pc : 0x0 <4f> DW_AT_high_pc : 0x94 <53> DW_AT_frame_base : 1 byte block: 6e (DW_OP_reg30 (r30)) <55> DW_AT_name: (indirect string, offset: 0xc6): test1 <59> DW_AT_decl_file : 1 <5a> DW_AT_decl_line : 5 <5b> DW_AT_prototyped : 1 <5b> DW_AT_type: <0x36d> <5f> DW_AT_external: 1 and that the local variable char_local is at $fp + 572: <2>: Abbrev Number: 5 (DW_TAG_variable) DW_AT_location: 3 byte block: 91 bc 4 (DW_OP_fbreg: 572) DW_AT_name: (indirect string, offset: 0x111): char_local DW_AT_decl_file : 1 DW_AT_decl_line : 17 DW_AT_type: <0x2a> which is wrong as the $fp != $sp. Tested with the tip of LLVM. -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 25029] New: Regression: Assert static clang::DependentScopeDeclRefExpr* clang::DependentScopeDeclRefExpr::Create(const clang::ASTContext&, clang::NestedNameSpecifierLoc, clang::Source
https://llvm.org/bugs/show_bug.cgi?id=25029
Bug ID: 25029
Summary: Regression: Assert static
clang::DependentScopeDeclRefExpr*
clang::DependentScopeDeclRefExpr::Create(const
clang::ASTContext&, clang::NestedNameSpecifierLoc,
clang::SourceLocation, const
clang::DeclarationNameInfo&, const
clang::TemplateArgumentListInfo*)
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: C++11
Assignee: unassignedclangb...@nondot.org
Reporter: andrey@gmail.com
CC: dgre...@apple.com, llvm-bugs@lists.llvm.org
Classification: Unclassified
The following code works as expected in 3.6 but ICEs with assertion failure in
3.8:
// begin bbc6.cc
struct A {
template
static T f(T)
{ return T(); }
};
template
struct C {
decltype(operator T (A::f(T))) t;
int f();
};
// end bbc6.cc
Expected output (Clang 3.6):
/tmp/bbc6.cc:8:28: error: 'T' does not refer to a value
decltype(operator T (A::f(T))) t;
^
/tmp/bbc6.cc:6:17: note: declared here
template
^
1 error generated.
Actual output (Clang 3.8):
x86_64-pc-linux-gnu-clang-3.8:
/var/tmp/portage/sys-devel/llvm-/work/llvm-/tools/clang/lib/AST/ExprCXX.cpp:451:
static clang::DependentScopeDeclRefExpr*
clang::DependentScopeDeclRefExpr::Create(const clang::ASTContext&,
clang::NestedNameSpecifierLoc, clang::SourceLocation, const
clang::DeclarationNameInfo&, const clang::TemplateArgumentListInfo*): Assertion
`QualifierLoc && "should be created for dependent qualifiers"' failed.
#0 0x7fab789ec0f7 llvm::sys::PrintStackTrace(llvm::raw_ostream&)
(/usr/bin/../lib64/libLLVMSupport.so.3.8+0xcb0f7)
#1 0x7fab789eb0b6 llvm::sys::RunSignalHandlers()
(/usr/bin/../lib64/libLLVMSupport.so.3.8+0xca0b6)
#2 0x7fab789eb52f SignalHandler(int)
(/usr/bin/../lib64/libLLVMSupport.so.3.8+0xca52f)
#3 0x7fab76746440 __restore_rt (/lib64/libc.so.6+0x33440)
#4 0x7fab767463c7 __GI_raise (/lib64/libc.so.6+0x333c7)
#5 0x7fab7674775a __GI_abort (/lib64/libc.so.6+0x3475a)
#6 0x7fab7673f3ad __assert_fail_base (/lib64/libc.so.6+0x2c3ad)
#7 0x7fab7673f462 (/lib64/libc.so.6+0x2c462)
#8 0x7fab73a10fa5 (/usr/bin/../lib64/../lib64/libclangAST.so.3.8+0x1fcfa5)
#9 0x7fab726f7e65 clang::Sema::BuildDependentDeclRefExpr(clang::CXXScopeSpec
const&, clang::SourceLocation, clang::DeclarationNameInfo const&,
clang::TemplateArgumentListInfo const*)
(/usr/bin/../lib64/../lib64/libclangSema.so.3.8+0x42ae65)
#10 0x7fab726f7ee5 clang::Sema::ActOnDependentIdExpression(clang::CXXScopeSpec
const&, clang::SourceLocation, clang::DeclarationNameInfo const&, bool,
clang::TemplateArgumentListInfo const*)
(/usr/bin/../lib64/../lib64/libclangSema.so.3.8+0x42aee5)
#11 0x7fab72566b06 clang::Sema::ActOnIdExpression(clang::Scope*,
clang::CXXScopeSpec&, clang::SourceLocation, clang::UnqualifiedId&, bool, bool,
std::unique_ptr >, bool, clang::Token*)
(/usr/bin/../lib64/../lib64/libclangSema.so.3.8+0x299b06)
#12 0x7fab72c84dd5 clang::Parser::tryParseCXXIdExpression(clang::CXXScopeSpec&,
bool, clang::Token&) (/usr/bin/../lib64/../lib64/libclangParse.so.3.8+0x78dd5)
#13 0x7fab72c84f10 clang::Parser::ParseCXXIdExpression(bool)
(/usr/bin/../lib64/../lib64/libclangParse.so.3.8+0x78f10)
#14 0x7fab72c6f0b7 clang::Parser::ParseCastExpression(bool, bool, bool&,
clang::Parser::TypeCastState)
(/usr/bin/../lib64/../lib64/libclangParse.so.3.8+0x630b7)
#15 0x7fab72c7199d clang::Parser::ParseCastExpression(bool, bool,
clang::Parser::TypeCastState)
(/usr/bin/../lib64/../lib64/libclangParse.so.3.8+0x6599d)
#16 0x7fab72c71a2f
clang::Parser::ParseAssignmentExpression(clang::Parser::TypeCastState)
(/usr/bin/../lib64/../lib64/libclangParse.so.3.8+0x65a2f)
#17 0x7fab72c71aa9 clang::Parser::ParseExpression(clang::Parser::TypeCastState)
(/usr/bin/../lib64/../lib64/libclangParse.so.3.8+0x65aa9)
#18 0x7fab72c5d7b3 clang::Parser::ParseDecltypeSpecifier(clang::DeclSpec&)
(/usr/bin/../lib64/../lib64/libclangParse.so.3.8+0x517b3)
#19 0x7fab72c8394f
clang::Parser::ParseOptionalCXXScopeSpecifier(clang::CXXScopeSpec&,
clang::OpaquePtr, bool, bool*, bool, clang::IdentifierInfo**)
(/usr/bin/../lib64/../lib64/libclangParse.so.3.8+0x7794f)
#20 0x7fab72cc70aa clang::Parser::TryAnnotateCXXScopeToken(bool)
(/usr/bin/../lib64/../lib64/libclangParse.so.3.8+0xbb0aa)
#21 0x7fab72c50e6b clang::Parser::ParseDeclarationSpecifiers(clang::DeclSpec&,
clang::Parser::ParsedTemplateInfo const&, clang::AccessSpecifier,
clang::Parser::DeclSpecContext, clang::Parser::LateParsedAttrList*)
(/usr/bin/../lib64/../lib64/libclangParse.so.3.8+0x44e6b)
#22 0x7fab72c65710
clang::Parser::ParseCXXClassMemberDeclaration(clang::AccessSpecifier,
clang::AttributeList*, clang::Parser::ParsedTemplateInfo const&,
clang::Parsi
[llvm-bugs] [Bug 25030] New: Instprinter for AArch64 'adr/adrp' prints the wrong label
https://llvm.org/bugs/show_bug.cgi?id=25030 Bug ID: 25030 Summary: Instprinter for AArch64 'adr/adrp' prints the wrong label Product: libraries Version: trunk Hardware: PC OS: FreeBSD Status: NEW Severity: normal Priority: P Component: Backend: AArch64 Assignee: unassignedb...@nondot.org Reporter: dav...@freebsd.org CC: llvm-bugs@lists.llvm.org Classification: Unclassified GNU objdump: ### 00011000 <_start>: 11000: 1021adr x1, 11004 Disassembly of section .R_AARCH64_ADR_PREL_PG_H121: 00011012 : 11012: 9001adrpx1, 11000 <_start> ### llvm-objdump: Disassembly of section .R_AARCH64_ADR_PREL_LO21: _start: 11000: 21 00 00 10 adr x1, #4 Disassembly of section .R_AARCH64_ADR_PREL_PG_H121: $x.2: 11012: 01 00 00 90 adrpx1, #0 # Testcase: # .section .R_AARCH64_ADR_PREL_LO21,"ax",@progbits .globl _start _start: adr x1,msg msg: .asciz "Hello, world\n" msgend: .section .R_AARCH64_ADR_PREL_PG_H121,"ax",@progbits adrp x1,mystr mystr: .asciz "blah" .size mystr, 4 # This is particularly inconvenient because I use it for checking relocations in lld. I think the issue is that AArch64InstPrinter::printAdrpLabel() just prints the immediate shifted left by 12 position but doesn't add to this value the value of PC with its bottom 12 bits cleared (i.e. Address of instruction & ~0xFFF). I haven't found a way to easily get the PC -- ideas? -- 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 18926] [Meta] ARM Integrated assembler support
https://llvm.org/bugs/show_bug.cgi?id=18926 Bug 18926 depends on bug 21695, which changed state. Bug 21695 Summary: Integrated assembler fails to set the target architecture from .arch https://llvm.org/bugs/show_bug.cgi?id=21695 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 21695] Integrated assembler fails to set the target architecture from .arch
https://llvm.org/bugs/show_bug.cgi?id=21695 Roman Divacky changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Roman Divacky --- Fixed in r249165 -- 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 23057] fuzz clang
https://llvm.org/bugs/show_bug.cgi?id=23057 Bug 23057 depends on bug 21821, which changed state. Bug 21821 Summary: [fuzz] Assertion `!isNull() && "Cannot retrieve a NULL type pointer"' failed. https://llvm.org/bugs/show_bug.cgi?id=21821 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 25027] Assertion failed when compiling RegAllocGreedy.cpp, line 980
https://llvm.org/bugs/show_bug.cgi?id=25027 Quentin Colombet changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WORKSFORME --- Comment #5 from Quentin Colombet --- It works for me as trunk r246785, though I have to remove -fobjc-default-synthesize-properties but clang does not recognize this flag. Could you install the latest LLVM release and see if you are able to reproduce it? -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 21821] [fuzz] Assertion `!isNull() && "Cannot retrieve a NULL type pointer"' failed.
https://llvm.org/bugs/show_bug.cgi?id=21821 Kaelyn Takata changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Kaelyn Takata --- Not sure when this was fixed, but the test case does not crash with Clang 3.7.0 (or ToT). -- 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 25031] New: PowerPC code generation bug: relative branch cannot be resolved by linker
https://llvm.org/bugs/show_bug.cgi?id=25031 Bug ID: 25031 Summary: PowerPC code generation bug: relative branch cannot be resolved by linker Product: new-bugs Version: 3.7 Hardware: Other 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 Classification: Unclassified Created attachment 14988 --> https://llvm.org/bugs/attachment.cgi?id=14988&action=edit a potential patch There is an issue in the algorithm in PPCBranchSelector.cpp. The algorithm pre-computes the size of each basic block in a function including any additional padding needed between adjacent blocks due to alignment directives. Unfortunately, this is a dynamic programming problem as the adjustment of branches can alter the padding needed as the instruction stream is rewritten. A small example: MBB1: (say this is 16 byte aligned) instr1 instr2 bcc ..., another_galaxy MBB2: bcc ..., another_solar_system .align 4 MBB3: (alignment is specified 16 bytes) Here we would precompute that MBB2 gets 0 bytes of padding. However, this must be recomputed as after expanding the two distant branches, the .align 4 will cause 8 bytes of padding, throwing off the precomputed size of MBB2 and any branches that compute the distance using the size of MBB2. This can cause a label to drift too far away. -- 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 25032] New: PPCVSXSwapRemoval assertion failure
https://llvm.org/bugs/show_bug.cgi?id=25032 Bug ID: 25032 Summary: PPCVSXSwapRemoval assertion failure Product: new-bugs Version: 3.7 Hardware: Other 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 Classification: Unclassified Created attachment 14989 --> https://llvm.org/bugs/attachment.cgi?id=14989&action=edit skip degenerate DBG_VALUE instructions The assertion "Inconsistency: def of vector reg not found in swap map!" has been found to fail in the module PPCVSXSwapRemoval.cpp when encountering a DBG_VALUE instruction with undefined inputs. See the attachment for a potential patch. -- 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 25026] updating gems fails at Updating bigdecimal
https://llvm.org/bugs/show_bug.cgi?id=25026 cont...@jjay.net changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from cont...@jjay.net --- The issue was solved by updating clang from 3.3 to 3.6. -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 25019] race in process return code collection in python test runner
https://llvm.org/bugs/show_bug.cgi?id=25019 Todd Fiala changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Todd Fiala --- This should be addressed with: ``` svn commit Sendingtest/test_runner/lib/process_control.py Sendingtest/test_runner/test/process_control_tests.py Transmitting file data .. Committed revision 249182. ``` -- 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 6158] analyzer crash on C++ file
https://llvm.org/bugs/show_bug.cgi?id=6158 Mohammed El-Afifi changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |WORKSFORME --- Comment #7 from Mohammed El-Afifi --- I tested the other day with the latest trunk: llvm(r248683), clang(r248683), and compiler-rt(r248683) and the problem didn't show up again; there were no "Cast kind X not handled" messages. I uploaded the minimal test file(originally proposed by Dmitry G. Dyachenko) in a previous comment; I used that file to confirm the bug was solved. I think the bug may be closed now. -- 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 25033] New: wrong code at -O3 on x86_64-linux-gnu
https://llvm.org/bugs/show_bug.cgi?id=25033
Bug ID: 25033
Summary: wrong code at -O3 on x86_64-linux-gnu
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 following code is miscompiled by the current clang trunk on
x86_64-linux-gnu at -O2 and -O3 in 32-bit mode (but not in 64-bit mode).
This is a regression from 3.7.x.
It seems different from PR 24991, which disappears with -g enabled.
$ clang-trunk -v
clang version 3.8.0 (trunk 249170)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /usr/local/tools/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.2
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/5.1.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.4
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.2
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5.1.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-trunk -m64 -O2 small.c; ./a.out
$ clang-trunk -m32 -Os small.c; ./a.out
$ clang-3.7.0 -m32 -O2 small.c; ./a.out
$
$ clang-trunk -m32 -O2 small.c
$ ./a.out
Aborted (core dumped)
$ clang-trunk -m32 -O2 -g small.c
$ ./a.out
Aborted (core dumped)
$
int a, b, c, e, f, g, h;
char d;
int
main ()
{
f = 0;
h = d > 0;
c = g;
e--;
a = b <= 0;
e && (g = 0);
g--;
d ^= 1;
if (d != 1)
__builtin_abort ();
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 25034] New: Segmentation fault while injecting instruction
https://llvm.org/bugs/show_bug.cgi?id=25034 Bug ID: 25034 Summary: Segmentation fault while injecting instruction Product: new-bugs Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: bamnepriyanka...@gmail.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified Created attachment 14991 --> https://llvm.org/bugs/attachment.cgi?id=14991&action=edit This is the code Hey i am getting segmentation fault while i am trying to insert an instruction.While debbuging i found it is because of CallInst::Create() this method can u please check and tell me what is wrong in that function . -- 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
