[llvm-bugs] [Bug 25552] New: extend -fwrapv to apply to left shifts
https://llvm.org/bugs/show_bug.cgi?id=25552 Bug ID: 25552 Summary: extend -fwrapv to apply to left shifts Product: clang Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: -New Bugs Assignee: unassignedclangb...@nondot.org Reporter: bonz...@gnu.org CC: llvm-bugs@lists.llvm.org Classification: Unclassified If you pass clang -fwrapv then this causes -fsanitize=undefined to no longer complain about signed integer overflows from addition. However the sanitizer will still complain about left shifts of negative values. -fwrapv should apply also to shifts. In addition -fwrapv in clang should suppress -Wshift-negative-value. (The GCC manuals only mention -fwrapv to affect add/sub/mult because GCC currently _never_ treats signed left shifts as having undefined behavior. GCC documentation however says very clearly, under -fstrict-overflow, that "Using '-fwrapv' means that integer signed overflow is fully defined: it wraps"). -- 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 23952] Crash on explicit destructor call in move assignment operator
https://llvm.org/bugs/show_bug.cgi?id=23952 davorin.uca...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WORKSFORME --- Comment #1 from davorin.uca...@gmail.com --- This crash does not occur any more in 3.7. -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 25553] New: Crash in BranchProbabilityInfoWrapperPass
https://llvm.org/bugs/show_bug.cgi?id=25553 Bug ID: 25553 Summary: Crash in BranchProbabilityInfoWrapperPass Product: libraries Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: Global Analyses Assignee: unassignedb...@nondot.org Reporter: john.kare.alsa...@gmail.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified Created attachment 15298 --> https://llvm.org/bugs/attachment.cgi?id=15298&action=edit Preprocessed source #0 0x67a23bc4 llvm::TerminatorInst::getNumSuccessors() const B:/Programmering/SandboxOS/AveryRust/vendor/llvm-sfi/include/llvm/IR\InstrTypes.h:60:0 #1 0x67a23bc4 llvm::BranchProbabilityInfo::calcUnreachableHeuristics(llvm::BasicBlock*) B:/Programmering/SandboxOS/AveryRust/vendor/llvm-sfi/lib/Analysis\BranchProbabilityInfo.cpp:124:0 #2 0x67a251ef llvm::BranchProbabilityInfo::calculate(llvm::Function&, llvm::LoopInfo const&) B:/Programmering/SandboxOS/AveryRust/vendor/llvm-sfi/lib/Analysis\BranchProbabilityInfo.cpp:674:0 #3 0x67a255d8 llvm::BranchProbabilityInfoWrapperPass::runOnFunction(llvm::Function&) B:/Programmering/SandboxOS/AveryRust/vendor/llvm-sfi/lib/Analysis\BranchProbabilityInfo.cpp:705:0 #4 0x11a048d5 llvm::FPPassManager::runOnFunction(llvm::Function&) B:/Programmering/SandboxOS/AveryRust/vendor/llvm-sfi/lib/IR\LegacyPassManager.cpp:1521:0 #5 0x11a0542b llvm::FPPassManager::runOnModule(llvm::Module&) B:/Programmering/SandboxOS/AveryRust/vendor/llvm-sfi/lib/IR\LegacyPassManager.cpp:1542:0 #6 0x11a03c3d runOnModule B:/Programmering/SandboxOS/AveryRust/vendor/llvm-sfi/lib/IR\LegacyPassManager.cpp:1598:0 #7 0x11a03c3d llvm::legacy::PassManagerImpl::run(llvm::Module&) B:/Programmering/SandboxOS/AveryRust/vendor/llvm-sfi/lib/IR\LegacyPassManager.cpp:1701:0 #8 0x6ebc2703 llvm::PrettyStackTraceString::~PrettyStackTraceString() B:/Programmering/SandboxOS/AveryRust/vendor/llvm-sfi/include/llvm/Support\PrettyStackTrace.h:49:0 #9 0x6ebc2703 EmitAssembly B:/Programmering/SandboxOS/AveryRust/vendor/llvm-sfi/tools/clang/lib/CodeGen\BackendUtil.cpp:653:0 #10 0x6ebc2703 clang::EmitBackendOutput(clang::DiagnosticsEngine&, clang::CodeGenOptions const&, clang::TargetOptions const&, clang::LangOptions const&, llvm::StringRef, llvm::Module*, clang::BackendAction, llvm::raw_pwrite_stream*) B:/Programmering/SandboxOS/AveryRust/vendor/llvm-sfi/tools/clang/lib/CodeGen\BackendUtil.cpp:666:0 #11 0x6edd3d40 clang::BackendConsumer::HandleTranslationUnit(clang::ASTContext&) B:/Programmering/SandboxOS/AveryRust/vendor/llvm-sfi/tools/clang/lib/CodeGen\CodeGenAction.cpp:193:0 #12 0x36111bbc clang::ParseAST(clang::Sema&, bool, bool) B:/Programmering/SandboxOS/AveryRust/vendor/llvm-sfi/tools/clang/lib/Parse\ParseAST.cpp:168:0 #13 0x00e20108 clang::FrontendAction::Execute() B:/Programmering/SandboxOS/AveryRust/vendor/llvm-sfi/tools/clang/lib/Frontend\FrontendAction.cpp:439:0 #14 0x00dfa315 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) B:/Programmering/SandboxOS/AveryRust/vendor/llvm-sfi/tools/clang/lib/Frontend\CompilerInstance.cpp:842:0 #15 0x6cc41c45 clang::ExecuteCompilerInvocation(clang::CompilerInstance*) B:/Programmering/SandboxOS/AveryRust/vendor/llvm-sfi/tools/clang/lib/FrontendTool\ExecuteCompilerInvocation.cpp:222:0 #16 0x004022c8 cc1_main(llvm::ArrayRef, char const*, void*) B:/Programmering/SandboxOS/AveryRust/vendor/llvm-sfi/tools/clang/tools/driver\cc1_main.cpp:116:0 #17 0x00409204 ExecuteCC1Tool B:/Programmering/SandboxOS/AveryRust/vendor/llvm-sfi/tools/clang/tools/driver\driver.cpp:301:0 #18 0x00409204 main B:/Programmering/SandboxOS/AveryRust/vendor/llvm-sfi/tools/clang/tools/driver\driver.cpp:366:0 #19 0x004013ed __tmainCRTStartup C:/repo/mingw-w64-crt-git/src/mingw-w64/mingw-w64-crt/crt\crtexe.c:334:0 #20 0x0040152b mainCRTStartup C:/repo/mingw-w64-crt-git/src/mingw-w64/mingw-w64-crt/crt\crtexe.c:214:0 #21 0x7ff833218102 BaseThreadInitThunk (C:\WINDOWS\system32\KERNEL32.DLL+0x18102) #22 0x7ff835acc264 RtlUserThreadStart (C:\WINDOWS\SYSTEM32\ntdll.dll+0x5c264) clang.exe: error: clang frontend command failed due to signal (use -v to see invocation) clang version 3.8.0 (http://llvm.org/git/clang.git 127c2b2f2d0614b49669f6710b2997b9db8f9557) (http://llvm.org/git/llvm.git 249c6c7d542d925edf04bd39868b6b1c188debcb) Target: x86_64-pc-avery Thread model: posix InstalledDir: B:\Programmering\SandboxOS\AveryRust\vendor\llvm-build\bin 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: -- You are receiving this mail because: You are on the CC list for the bug. ___
[llvm-bugs] [Bug 25554] New: [x86, SSE] rematerialized existing constants
https://llvm.org/bugs/show_bug.cgi?id=25554
Bug ID: 25554
Summary: [x86, SSE] rematerialized existing constants
Product: libraries
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: Backend: X86
Assignee: unassignedb...@nondot.org
Reporter: spatel+l...@rotateright.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
$ cat bad_vmov.c
#include
void foo(__m128i v0, __m128i v1, int *ret) {
__m128i one0 = _mm_set_epi32(0,0,0,1);
__m128i one1 = _mm_set_epi32(0,1,0,0);
if ( _mm_testz_si128(v0, one0) ) ret[0] = 10;
if ( _mm_testz_si128(v1, one1) ) ret[1] = 20;
}
Using:
./clang -v
clang version 3.8.0 (trunk 253253)
Target: x86_64-apple-darwin15.0.0
Thread model: posix
$ ./clang -O2 -S -o - bad_vmov.c -fomit-frame-pointer -msse4.1
...
movl$1, %eax
movd%rax, %xmm2
ptest%xmm2, %xmm0
jneLBB0_2
movl$10, (%rdi)
LBB0_2:
movl$1, %eax <--- $1 was already in %eax
movd%rax, %xmm0 <--- and %xmm2 already has this value
pslldq$8, %xmm0
ptest%xmm0, %xmm1
jneLBB0_4
movl$20, 4(%rdi)
LBB0_4:
retq
--
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 21435] LLVM no longer honours -stack-alignment=4
https://llvm.org/bugs/show_bug.cgi?id=21435 Reid Kleckner changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #15 from Reid Kleckner --- This is over a year old and the attached LLVM IR no longer parses with TOT llc. llc's command line interface isn't exactly stable or user facing either, so I don't think there's anything to do here. -- 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 5201] JIT stub offsets silently truncated to 32 bits in call instruction
https://llvm.org/bugs/show_bug.cgi?id=5201 Reid Kleckner changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #26 from Reid Kleckner --- The old JIT has been deleted, and MCJIT doesn't suffer from this problem. It sometimes has a different class of issues where it fatal errors during relocation resolution, but we already have issues open for that. -- 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 9072] [META][Win64] build and test issues on MinGW-w64
https://llvm.org/bugs/show_bug.cgi?id=9072 Reid Kleckner changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #12 from Reid Kleckner --- I believe this is fixed. We've built with mingw64 for a long time. This bot provides proof that it works: http://bb.pgr.jp/builders/ninja-clang-x64-mingw64-RA/ I don't think we need a meta bug for this now that it works. Any breakage can be filed separately. -- 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 9100] [META][Win64] Selfhosting clang/llvm on/for Windows x64
https://llvm.org/bugs/show_bug.cgi?id=9100 Bug 9100 depends on bug 9072, which changed state. Bug 9072 Summary: [META][Win64] build and test issues on MinGW-w64 https://llvm.org/bugs/show_bug.cgi?id=9072 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 25555] New: osx.cocoa.NSError checker false positive on overridden method
https://llvm.org/bugs/show_bug.cgi?id=2 Bug ID: 2 Summary: osx.cocoa.NSError checker false positive on overridden method Product: clang Version: unspecified Hardware: Macintosh OS: MacOS X Status: NEW Severity: normal Priority: P Component: Static Analyzer Assignee: kreme...@apple.com Reporter: levigro...@gmail.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified Created attachment 15300 --> https://llvm.org/bugs/attachment.cgi?id=15300&action=edit Sample project demonstrating the issue. The `osx.cocoa.NSError` checker reports an analysis warning on the child implementation of an overridden method which would not pass the checker. For instance, `NSFileCoordinator` declares `- (void)coordinateReadingItemAtURL:(NSURL *)url options:(NSFileCoordinatorReadingOptions)options error:(NSError **)outError byAccessor:(void (^)(NSURL *))reader` which fails this checker (reports "Method accepting NSError** should have a non-void return value to indicate whether or not an error occurred"). A subclass of `NSFileCoordinator` which overrides this method has no choice but to use the same method signature, and therefore will fail the checker. While it may be debatable this is to be considered a false positive, a couple possible solutions come to mind: 1. Have the checker understand this is an overridden method and present the warning on the parent class. 2. Provide a way to suppress this specific checker only for this and similar overrides (perhaps via a #pragma push/pop mechanism). Please see the attached Xcode 7.1.1 project, which exhibits this issue when Xcode Analyze is performed. Thank you, Levi -- 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 17313] Clang driver doesn't now how to handle *.inl file
https://llvm.org/bugs/show_bug.cgi?id=17313 Reid Kleckner changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #5 from Reid Kleckner --- There's nothing for us to do here. If the user wants to parse files ending in .inl in isolation, they can pass -x c++. -- 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 16756] JumpThreading takes 29% of the wall O3 compile time (C++ to object file) (was: Extremely slow compilation of innocuous C++ source)
https://llvm.org/bugs/show_bug.cgi?id=16756 Reid Kleckner changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Reid Kleckner --- Mehdi, sounds like this is 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 21435] LLVM no longer honours -stack-alignment=4
https://llvm.org/bugs/show_bug.cgi?id=21435 Jose Fonseca changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID |--- --- Comment #16 from Jose Fonseca --- (In reply to comment #15) > This is over a year old and the attached LLVM IR no longer parses with TOT > llc. > > llc's command line interface isn't exactly stable or user facing either, so > I don't think there's anything to do here. This bug is not specific llc... I provided the llc command line / IR merely to _facilitate_ reproing and fixing the bug. We saw the bug on Mesa + llvmpipe with JIT. The problem here is that LLVM is broken when incoming stack aligment is 4. You can probably repro the isse with `clang -mstack-alignment=4` and the right input. That said, it's clear that nothing happened. So probably nothing will ever happen. On Mac and Linux the ABI (both 32 and 64bits) states that stack alignment is always aligned 16bytes, so this is never a issue. (Maybe it matters for Microsoft, since on Windows 32 bits, the stack alignment is 4bytes.) But, if you don't want to fix, then at very least mark it as WONTFIX. Closing as INVALID on the grounds you can't no longer repro is IMO insult to the time I spent on obtaining a small repro, as per the bug guidelines. LLVM has very little stable interfaces, so if LLVM devs sleep it long enough you can close any bug on the basis you can repro... -- 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 16756] JumpThreading takes 29% of the wall O3 compile time (C++ to object file) (was: Extremely slow compilation of innocuous C++ source)
https://llvm.org/bugs/show_bug.cgi?id=16756 Mehdi Amini changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #7 from Mehdi Amini --- As of r253350, nothing changed since my last update, still ~30% of the total clang invocation is spent in JumpThreading. Did you get different measurements? I measured on OS X. -- 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 25556] New: Segfault in inferPrototypeAttributes
https://llvm.org/bugs/show_bug.cgi?id=25556 Bug ID: 25556 Summary: Segfault in inferPrototypeAttributes Product: tools Version: 3.7 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: opt Assignee: unassignedb...@nondot.org Reporter: pe...@trailofbits.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified opt produces a NULL-pointer dereference when trying to infer the prototype of a declaration of __isoc99_sscanf. If __isoc99_sscanf is declared as having only a single argument then the following code segfaults when trying to access the parameter type of param 1. File: llvm/lib/Transforms/IPO/FunctionAttrs.cpp Function: inferPrototypeAttributes 1714 case LibFunc::dunder_isoc99_sscanf: 1715if (FTy->getNumParams() < 1 || !FTy->getParamType(0)->isPointerTy() || 1716!FTy->getParamType(1)->isPointerTy()) 1717 return false; I have ensured that my declaration of __isoc99_sscanf is attributed with llvm::Attribute::NoBuiltin but this attribute appears to be ignored during this inference phase. The only checked attribute is llvm::Attribute::OptimizeNone. -- 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 24045] clang-cl link on Linux?
https://llvm.org/bugs/show_bug.cgi?id=24045 Reid Kleckner changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #3 from Reid Kleckner --- Sounds like it's working as intended. -- 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 24041] The "Attributes in Clang" docs are blank half the time
https://llvm.org/bugs/show_bug.cgi?id=24041 Aaron Ballman changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Aaron Ballman --- I believe that Tanya fixed this in Jul 2015. I have not seen further issues since then, but if someone does see this crop back up, they can reopen. -- 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 25557] New: clang accepts implicit conversion between vector types
https://llvm.org/bugs/show_bug.cgi?id=25557
Bug ID: 25557
Summary: clang accepts implicit conversion between vector types
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: philip.pfa...@gmail.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
Clang silently accepts implicit conversions between vector types.
Minimal example:
// clang++ -std=c++11 -mavx2
#include
#include
int main() {
uint8_t C[8] = {1,2,3,4,5,6,7,8};
__m256i V = _mm256_loadu_si256((__m256i*)C);
__m256i Two = _mm256_set1_epi32(2);
__m256 R = _mm256_div_ps(V, Two);
}
V and Two are here implicitly converted from __m256i to __m256. Both are
typedefs of float and longlong vectors, respectively.
I think clang should at least throw a warning here (which is what icc does) or,
even better, an error (the gcc behaviour).
--
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 25352] Cannot build LLVM trunk OS X 10.10.5 | Xcode Version 7.1 (7B91b) | CMake 3.4.0-rc1
https://llvm.org/bugs/show_bug.cgi?id=25352 Nik Yotis changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 25352] Cannot build LLVM trunk OS X 10.10.5 | Xcode Version 7.1 (7B91b) | CMake 3.4.0-rc1
https://llvm.org/bugs/show_bug.cgi?id=25352 Chris Bieneman changed: What|Removed |Added Status|RESOLVED|REOPENED CC||chris.biene...@me.com Resolution|INVALID |--- --- Comment #15 from Chris Bieneman --- The underlying issue here looks like the new test-suite CMake system doesn't work with multi-configuration generators. That is a real 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
[llvm-bugs] [Bug 25558] New: Clang interprets input as unicode in assembly file
https://llvm.org/bugs/show_bug.cgi?id=25558 Bug ID: 25558 Summary: Clang interprets input as unicode in assembly file Product: clang Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: -New Bugs Assignee: unassignedclangb...@nondot.org Reporter: viniciusti...@gmail.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified Created attachment 15305 --> https://llvm.org/bugs/attachment.cgi?id=15305&action=edit Example: macro.S and clang generated files macro.s and macro.ll When trying to build the following code: // macro.S // // clang -target arm-linux-gnueabihf -no-integrated-as -S -c -o macro.s macro.S // .macro my_macro, trace=1, uaccess=1 .if \uaccess mov r0, r0 .endif .endm foo: my_macro trace=0 // end Clang interprets the \uacce as an Unicode character and emits it in the assembly file. It even emits it in the bitcode file. -- 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 25540] Relocation R_PPC64_REL24 overflow
https://llvm.org/bugs/show_bug.cgi?id=25540 Ulrich Weigand changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Assignee|unassignedb...@nondot.org |uweig...@de.ibm.com --- Comment #2 from Ulrich Weigand --- Checked in as r253369. This should allow per-object .text section sizes of up to 32 MB. -- 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 25559] New: [GVN] Should be able to PRE a load from memset
https://llvm.org/bugs/show_bug.cgi?id=25559
Bug ID: 25559
Summary: [GVN] Should be able to PRE a load from memset
Product: libraries
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: normal
Priority: P
Component: Scalar Optimizations
Assignee: unassignedb...@nondot.org
Reporter: mcros...@codeaurora.org
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
Currently, GVN can pre loads from calloc like functions. For example, in the
below test case the store to 'res' will be converted from a load into a
constant zero.
#include
#include
int *test_calloc(int n, int *res)
{
if (n == 0)
return 0;
int *ptr = (int *)calloc(n, sizeof(int));
*res = ptr[n-1];
return ptr;
}
However, PRE falls apart with this example:
int *test_malloc_memset_zero(int n, int *res)
{
if (n == 0)
return 0;
int *ptr = (int *)malloc(n * sizeof(int));
bzero(ptr, n * sizeof(int));
*res = ptr[n-1];
return ptr;
}
--
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 24068] check-libcxx and check-libcxxabi doesn't work in bootstrap builds on OS X
https://llvm.org/bugs/show_bug.cgi?id=24068 Nico Weber changed: What|Removed |Added Status|NEW |RESOLVED CC||chris.biene...@me.com Resolution|--- |FIXED --- Comment #7 from Nico Weber --- The flag from r250003 seems to make it to check-libcxxabi too. So I think cbieneman fixed this with that revision. 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 25560] New: Emitting additional debug info would allow shrink-wrapping to be used on function with sanitize-like attribute
https://llvm.org/bugs/show_bug.cgi?id=25560 Bug ID: 25560 Summary: Emitting additional debug info would allow shrink-wrapping to be used on function with sanitize-like attribute Product: libraries Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: Common Code Generator Code Assignee: unassignedb...@nondot.org Reporter: qcolom...@apple.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified Created attachment 15307 --> https://llvm.org/bugs/attachment.cgi?id=15307&action=edit Without shrink-wrapping In r253116, we disabled shrink-wrapping on function having a sanitize-like attribute. The rational for that change was that the sanitizers need to be able to rebuild the stack frame anywhere in function and the produced code before (resp. after) the prologue (resp. epilogue) does not describe how to that. Indeed, frame settings are defined with cfa directives when the frame pointer gets actually pushed. However, before that we still have the information available directly in the frame pointer register, but this is not expressed in the debug info. Assuming this is possible to emit such information, it would be nice to teach the compiler how to do it and then reenable shrink-wrapping when sanitizers come into play. I’ve attached the assembly code of a function with and without shrink-wrapping enable for compiler-rt/test/asan/TestCases/null_deref.cc. -- 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 21435] LLVM no longer honours -stack-alignment=4
https://llvm.org/bugs/show_bug.cgi?id=21435 Reid Kleckner changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #24 from Reid Kleckner --- (In reply to comment #23) > Performance was never my worry here. Even with the crash fixed, it makes > sense for us to continue using frame pointer. My main concern was the crash. > > So it looks you can resolve this bug after all! OK, thanks for looking into it. I think we'll mark this fixed then. If someone runs into the performance issue, there are tons of workarounds: pass -fno-omit-frame-pointer, -mstackrealign, -mstack-alignment=32, or whatever. Those all use a different codepath from TargetOptions::StackAlignmentOverride, and should avoid the unaligned loads. -- 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 25561] New: Clang assertion failure on template instantiation
https://llvm.org/bugs/show_bug.cgi?id=25561
Bug ID: 25561
Summary: Clang assertion failure on template instantiation
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Frontend
Assignee: unassignedclangb...@nondot.org
Reporter: rtr...@google.com
CC: ismail.pazarb...@gmail.com, llvm-bugs@lists.llvm.org
Classification: Unclassified
In clang::Sema::ActOnExplicitInstantiation in lib/Sema/SemaTemplate.cpp:7259,
Clang hits an assertion when attempting to cast a TemplateDecl to a
ClassTemplateDecl.
7259: ClassTemplateDecl *ClassTemplate = cast(TD);
test.cc:
class A {};
template class B>
class C {
template class B;
};
clang -cc1 test.cc
clang: ../include/llvm/Support/Casting.h:237: typename cast_retty::ret_type llvm::cast(Y *) [X = clang::ClassTemplateDecl, Y =
clang::TemplateDecl]: Assertion `isa(Val) && "cast() argument of
incompatible type!"' failed.
...
Stack dump:
0.Program arguments: clang -cc1 test.cc
1.test.cc:4:22: current parser token ';'
2.test.cc:3:1: parsing struct/union/class body 'C'
Aborted (core dumped)
--
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 25562] New: Some failing tests are being reported as passes
https://llvm.org/bugs/show_bug.cgi?id=25562 Bug ID: 25562 Summary: Some failing tests are being reported as passes Product: lldb Version: unspecified Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: lldb-...@lists.llvm.org Reporter: ztur...@google.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified If I run this test manually, two of the tests fails. Example: d:\src\llvmbuild\ninja\lldb-test-traces>c:\python27_lldb\x86\python_d.exe D:\src\llvm\tools\lldb\test\dotest.py -q --arch=i686 --executable D:/src/llvmbuild/ninja/bin/lldb.exe -s D:/src/llvmbuild/ninja/lldb-test-traces -u CXXFLAGS -u CFLAGS --enable-crash-dialog -C d:\src\llvmbuild\ninja_release\bin\clang.exe D:\src\llvm\tools\lldb\packages\Python\lldbsuite\test\functionalities\process_launch --no-multiprocess The 'lldb-mi' executable cannot be located. The lldb-mi tests can not be run as a result. UNSUPPORTED: LLDB (d:\src\llvmbuild\ninja_release\bin\clang.exe-i686) :: test_environment_with_special_char_dsym (TestProcessLaunch.ProcessLaunchTestCase) (dsym tests) FAIL: LLDB (d:\src\llvmbuild\ninja_release\bin\clang.exe-i686) :: test_environment_with_special_char_dwarf (TestProcessLaunch.ProcessLaunchTestCase) FAIL: LLDB (d:\src\llvmbuild\ninja_release\bin\clang.exe-i686) :: test_environment_with_special_char_dwo (TestProcessLaunch.ProcessLaunchTestCase) UNSUPPORTED: LLDB (d:\src\llvmbuild\ninja_release\bin\clang.exe-i686) :: test_io_dsym (TestProcessLaunch.ProcessLaunchTestCase) (dsym tests) PASS: LLDB (d:\src\llvmbuild\ninja_release\bin\clang.exe-i686) :: test_io_dwarf (TestProcessLaunch.ProcessLaunchTestCase) PASS: LLDB (d:\src\llvmbuild\ninja_release\bin\clang.exe-i686) :: test_io_dwo (TestProcessLaunch.ProcessLaunchTestCase) UNSUPPORTED: LLDB (d:\src\llvmbuild\ninja_release\bin\clang.exe-i686) :: test_set_working_dir_dsym (TestProcessLaunch.ProcessLaunchTestCase) (dsym tests) When I run the multiprocess test runner via dosep, it's being reported as a success. 410 out of 410 test suites processed - TestAddDsymCommand.py Ran 410 test suites (1 failed) (0.243902%) Ran 318 test cases (4 failed) (1.257862%) Failing Tests (1) FAIL: LLDB (suite) :: TestBreakpointLanguage.py (Windows zturner-win81 8 6.2.9200 AMD64 Intel64 Family 6 Model 45 Stepping 7, GenuineIntel) [79964 refs] ninja: build stopped: subcommand failed. Stepping through the code, in dosep.py when it goes to print the summary list of failed tests, 'TestProcessLaunch.py' is in the list of passed tests. So something is wrong here, and a potentially unknown number of tests are currently being misreported. -- 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 24246] Assertion failed: isa(Val) && "cast() argument of incompatible type!", include/llvm/Support/Casting.h, line 237
https://llvm.org/bugs/show_bug.cgi?id=24246 Richard Smith changed: What|Removed |Added Status|RESOLVED|REOPENED CC||richard-l...@metafoo.co.uk Resolution|FIXED |--- Assignee|ri...@google.com|david.majne...@gmail.com --- Comment #5 from Richard Smith --- We've fixed the symptoms but not the actual bug -- getAs() on a valid type should never assert. The problem is that we're producing a broken type for the largest_type_select specialization -- the canonical type of the template specialization type is a record type, but desugaring the template specialization type does not produce that record type (because it thinks that it's not a sugar node). We should back out r249090 (the typo correction code was correct prior to this change) and fix the code that handles this MS extension to create a correct type here. David, can you take a look? -- 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 25563] New: [clang-cl] /W4 should probably turn on -Wextra
https://llvm.org/bugs/show_bug.cgi?id=25563 Bug ID: 25563 Summary: [clang-cl] /W4 should probably turn on -Wextra Product: clang Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: Driver Assignee: unassignedclangb...@nondot.org Reporter: nicolaswe...@gmx.de CC: llvm-bugs@lists.llvm.org Classification: Unclassified Currently, all /w flags in clang-cl just map to -Wall. /W4 in cl has a bunch of stuff that in clang is under -Wextra, so /w4 should probably map to -Wall -Wextra... -- 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 25564] New: MSVC: attachment points at wrong subprogram for function
https://llvm.org/bugs/show_bug.cgi?id=25564 Bug ID: 25564 Summary: MSVC: attachment points at wrong subprogram for function Product: libraries Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: DebugInfo Assignee: unassignedb...@nondot.org Reporter: a...@crichton.co CC: llvm-bugs@lists.llvm.org Classification: Unclassified Created attachment 15309 --> https://llvm.org/bugs/attachment.cgi?id=15309&action=edit Failing IR When compiling the attached IR with llc, I get: !dbg attachment points at wrong subprogram for function !1 = distinct !DISubprogram(name: "main", linkageName: "_ZN19backtrace_debuginfo4mainE", scope: !3, file: !2, line: 1, type: !4, isLocal: true, isDefinition: true, scopeLine: 1, flags: DIFlagPrototyped, isOptimized: true, templateParams: !5, variables: !5) void ()* @foo call void @bar(), !dbg !19 !19 = !DILocation(line: 1219, scope: !20, inlinedAt: !21) !25 = distinct !DILexicalBlock(scope: !26, file: !2, line: 1, column: 10) !26 = distinct !DISubprogram(name: "main", linkageName: "_ZN19backtrace_debuginfo4mainE", scope: !3, file: !2, line: 1, type: !4, isLocal: true, isDefinition: true, scopeLine: 1, flags: DIFlagPrototyped, isOptimized: true, templateParams: !5, variables: !5) LLVM ERROR: Broken function found, compilation aborted! But when the target is changed to x86_64-unknown-linux-gnu the file compiles successfully. I'm not 100% sure that we correctly emit debuginfo in the first place (not my area of expertise), and this may also be related to r252219 but I figured it was odd at least that it failed to compile with an MSVC target yet successfully compiled for a Linux one! -- 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 25553] Crash in BranchProbabilityInfoWrapperPass
https://llvm.org/bugs/show_bug.cgi?id=25553 John Kåre Alsaker changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #3 from John Kåre Alsaker --- It turns out this was my fault. I failed to update some modifications correctly. -- 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
