[llvm-bugs] [Bug 26809] New: Windows SDK not selectable
https://llvm.org/bugs/show_bug.cgi?id=26809 Bug ID: 26809 Summary: Windows SDK not selectable Product: clang Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: Driver Assignee: unassignedclangb...@nondot.org Reporter: o...@mirix.org CC: llvm-bugs@lists.llvm.org Classification: Unclassified At the moment Clang chooses the latest version of the Windows SDK that is installed on a particular machine and it is impossible to select a specific version of the Windows SDK. There is software that can only be compiled against specific versions of the Windows SDK or must be tested against specific versions when multiple versions are installed. So while selecting the most recent version is the intended behaviour for most use cases, it would be helpful to be able to select a specific version. -- 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 24268] clang_visitChildren skips elements
https://llvm.org/bugs/show_bug.cgi?id=24268 Milian Wolff changed: What|Removed |Added Status|NEW |RESOLVED Version|3.7 |3.8 Resolution|--- |FIXED --- Comment #5 from Milian Wolff --- Resolved now by http://reviews.llvm.org/D17486 NOTE: You have to pass CXTranslationUnit_KeepGoing to clang_parseTranslationUnit2 to get the requested behavior. -- 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 26810] New: Redundant movs and an extra spill while using all xmm registers
https://llvm.org/bugs/show_bug.cgi?id=26810
Bug ID: 26810
Summary: Redundant movs and an extra spill while using all xmm
registers
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Register Allocator
Assignee: unassignedb...@nondot.org
Reporter: egor.koche...@intel.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
Created attachment 15974
--> https://llvm.org/bugs/attachment.cgi?id=15974&action=edit
The reproducer (1 source file, assemblies for clang and GCC, auxiliary
Makefile)
When compiling the loop below, clang produces the binary that runs ~25% slower
than that of GCC.
constexpr unsigned nIterations = 7680; //< an arbitrary large number
__m128d v[8];
__m128d m1[nIterations];
__m128d m2[8];
for (unsigned i = 0; i < nIterations; ++i) {
const __m128d M = m1 [i];
__m128d a;
a = _mm_mul_pd(M, m2[0]);
v[0] = _mm_add_pd(v[0], a);
a = _mm_mul_pd(M, m2[1]);
v[1] = _mm_add_pd(v[1], a);
a = _mm_mul_pd(M, m2[2]);
v[2] = _mm_add_pd(v[2], a);
a = _mm_mul_pd(M, m2[3]);
v[3] = _mm_add_pd(v[3], a);
a = _mm_mul_pd(M, m2[4]);
v[4] = _mm_add_pd(v[4], a);
a = _mm_mul_pd(M, m2[5]);
v[5] = _mm_add_pd(v[5], a);
a = _mm_mul_pd(M, m2[6]);
v[6] = _mm_add_pd(v[6], a);
a = _mm_mul_pd(M, m2[7]);
v[7] = _mm_add_pd(v[7], a);
}
In particular, there are weird movs around calculating v[6]:
0x08048c4e <+334>:movapd %xmm5,%xmm6
0x08048c52 <+338>:movapd %xmm4,%xmm5
0x08048c56 <+342>:movapd %xmm3,%xmm4
0x08048c5a <+346>:movapd %xmm2,%xmm3
Also, throughout the loop clang uses 3 spills for storing values of v[1], v[6]
and v[7], while GCC uses only two spills (for v[0] and v[1]).
Attached is the source file, annotated assembly for clang and an assembly for
GCC for the function 'loop', and the (optional) Makefile.
The source needs to be compiled with '-m32' to limit the number of xmm
registers available. -O2 and -Ofast produce the same results (though the
register names are changing).
--
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 26811] New: Assertion failed: TyposInContext < ~0U && "Recursive call of CorrectDelayedTyposInExpr"
https://llvm.org/bugs/show_bug.cgi?id=26811
Bug ID: 26811
Summary: Assertion failed: TyposInContext < ~0U && "Recursive
call of CorrectDelayedTyposInExpr"
Product: new-bugs
Version: unspecified
Hardware: PC
OS: Windows NT
Status: NEW
Severity: normal
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: yaron.ke...@gmail.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
clang -fsyntax-only -target x86_64-pc-linuxof:
template class A {
void set(A x) { s(bset, x); }
};
results in the assertion.
clang version 3.9.0 (trunk 262315)
--
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 26812] New: possible overflow issue in std::allocator::allocate
https://llvm.org/bugs/show_bug.cgi?id=26812
Bug ID: 26812
Summary: possible overflow issue in std::allocator::allocate
Product: libc++
Version: 3.8
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: All Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: ionelpopesc...@yahoo.com
CC: llvm-bugs@lists.llvm.org, mclow.li...@gmail.com
Classification: Unclassified
std::allocator::allocate is currently implemented like this:
_LIBCPP_INLINE_VISIBILITY pointer allocate(size_type __n,
allocator::const_pointer = 0)
{return static_cast(_VSTD::__allocate(__n * sizeof(_Tp)));}
If __n > allocator::max_size() this will cause an overflow ant the result will
not be throwing a std::bad_alloc, but instead it will allocate a size
determined by overflow.
It should be better implemented like this:
_LIBCPP_INLINE_VISIBILITY pointer allocate(size_type __n,
allocator::const_pointer = 0)
{
if (__n > max_size()) {
#ifndef _LIBCPP_NO_EXCEPTIONS
throw std::bad_alloc();
#endif
}
return static_cast(_VSTD::__allocate(__n * sizeof(_Tp)));
}
--
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 26813] New: lld-linked FreeBSD libc contains .text relocations
https://llvm.org/bugs/show_bug.cgi?id=26813 Bug ID: 26813 Summary: lld-linked FreeBSD libc contains .text relocations Product: lld Version: unspecified Hardware: PC OS: FreeBSD Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: unassignedb...@nondot.org Reporter: ema...@freebsd.org CC: llvm-bugs@lists.llvm.org Blocks: 23214 Classification: Unclassified Found during ongoing attempts to link the FreeBSD base system with lld. For processing .text relocations the runtime loader temporarily maps the segment with write permission. I discovered that we have an issue in FreeBSD's runtime loader: it expects the first PT_LOAD segment to be .text, and unprotects only that one. (That issue is tracked in http://bugs.freebsd.org/207631.) This uncovered two lld issues, however. First, lld should set DT_TEXTREL or DF_TEXTREL if the output contains relocations in non-writable segments. DF_TEXTREL If this flag is not set, no relocation entry should cause a modification to a non-writable segment, as specified by the segment permissions in the program header table. If this flag is set, one or more relocation entries might request modifications to a non-writable segment, and the dynamic linker can prepare accordingly. The real issue here though is that the relocation exists at all. feynman% findtextrel lib/libc.so.7 | head lib/libc.so.7: ELF object contains text relocation records: lib/libc.so.7: off: 0x9d0ac, func: __sys_numa_setaffinity lib/libc.so.7: off: 0x9d0cc, func: __sys_numa_getaffinity lib/libc.so.7: off: 0x9d0ec, func: _procctl ... feynman% readelf -r lib/libc.so.7 | grep 9d0ac 0009d0ac 09ab0002 R_X86_64_PC32 001a62c4 .cerror + fffc These all come from the autogenerated libc syscall wrappers. #define RSYSCALL(name) ENTRY(__sys_##name);\ WEAK_REFERENCE(__sys_##name, name); \ WEAK_REFERENCE(__sys_##name, _##name); \ mov $SYS_##name,%eax; KERNCALL; \ jb HIDENAME(cerror); ret; \ END(__sys_##name) -- 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 26814] New: lld needs to set DF_TEXTREL if the output contains relocations in non-writable segments
https://llvm.org/bugs/show_bug.cgi?id=26814 Bug ID: 26814 Summary: lld needs to set DF_TEXTREL if the output contains relocations in non-writable segments Product: lld Version: unspecified Hardware: PC OS: FreeBSD Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: unassignedb...@nondot.org Reporter: ema...@freebsd.org CC: llvm-bugs@lists.llvm.org Classification: Unclassified PR 26813 reports an issue where an lld-linked FreeBSD libc contains .text relocations, which should not be the case. However, if the output does contain .text relocations the DF_TEXTREL flag needs to be set (and perhaps the DT_TEXTREL tag). Split into a separate PR for tracking. See http://www.sco.com/developers/gabi/2007-03-26/ch5.dynamic.html#df_textrel > DF_TEXTREL > > If this flag is not set, no relocation entry should cause a modification > to a non-writable segment, as specified by the segment permissions in the > program header table. If this flag is set, one or more relocation entries > might request modifications to a non-writable segment, and the dynamic > linker can prepare accordingly. -- 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 26815] New: Clang really shouldn't have ASM tests in it
https://llvm.org/bugs/show_bug.cgi?id=26815 Bug ID: 26815 Summary: Clang really shouldn't have ASM tests in it Product: clang Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: -New Bugs Assignee: unassignedclangb...@nondot.org Reporter: renato.go...@linaro.org CC: llvm-bugs@lists.llvm.org Classification: Unclassified After enough discussions in the mailing list, and what I believe is now the consensus, we should move all ASM tests to LLVM and transform all Clang tests into IR tests. The few cases that people were arguing about: 1. NEON intrinsics need to lower to NEON instructions one-to-one. That's not true. I love that the back-end combines vmul+vadd into vmla, and it should still do it. Testing for a sequence of IR instructions instead (or builtin) is not worse. 2. Inline ASM needs to be as is in asm output. No it doesn't. There are a number of cases where we (and GAS) do slight transformations on the asm and output a different code (ex. add r0, -1 -> sub r0, 1). Furthermore, inline asm has a nice IR representation, which we can also test. 3. Specific code-gen issues. If C code gets translated into IR and then assembly, we can obviously always find an IR that will produce the same assembly. To do that, simple -emit-llvm. -- Having said that, the move itself will be *very* tedious, but it is necessary. Given that most people were complaining about the ARM and AArch64 tests, I think it's only fair that we, ARM folks, share the load into moving things. I'll copy as many people as I can into this bug so we can coordinate our efforts, but I'd like to have a much cleaner Clang test by 3.9.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 26809] Windows SDK version not selectable
https://llvm.org/bugs/show_bug.cgi?id=26809 Reid Kleckner changed: What|Removed |Added Status|NEW |RESOLVED CC||r...@google.com Resolution|--- |WORKSFORME --- Comment #1 from Reid Kleckner --- Clang will not autodetect your SDK installation if you set the INCLUDE environment variable, as you would do if you were running MSVC manually. However, we could definitely have an easier to use mechanism for doing this. I've wanted to add something like -fwindows-sdk-dir for a long time. Patches welcome. -- 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 26340] Cuda device constant doesn't work
https://llvm.org/bugs/show_bug.cgi?id=26340 Artem Belevich changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Artem Belevich --- Fixed in r262498 -- 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 26816] New: [ScalarEvolution] Iteration order over Set depends on pointer values
https://llvm.org/bugs/show_bug.cgi?id=26816
Bug ID: 26816
Summary: [ScalarEvolution] Iteration order over Set depends on
pointer values
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Global Analyses
Assignee: unassignedb...@nondot.org
Reporter: mattias.v.eriks...@ericsson.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
I am seeing some non-deterministic behavior in the output files in some tests
that I am running.
I have been tracking the problem and I think it is caused by a new for loop in
ScalarEvolutionExpander. The iteration order over Set below will depend on
pointer values. I am not sure how to fix this.
Value *SCEVExpander::FindValueInExprValueMap(const SCEV *S,
const Instruction *InsertPt) {
SetVector *Set = SE.getSCEVValues(S);
// If the expansion is not in CanonicalMode, and the SCEV contains any
// sub scAddRecExpr type SCEV, it is required to expand the SCEV literally.
if (CanonicalMode || !SE.containsAddRecurrence(S)) {
// If S is scConstant, it may be worse to reuse an existing Value.
if (S->getSCEVType() != scConstant && Set) {
// Choose a Value from the set which dominates the insertPt.
// insertPt should be inside the Value's parent loop so as not to break
// the LCSSA form.
for (auto const &Ent : *Set) {
--
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 26807] --start-lib/--end-lib sometimes ignored with LTO
https://llvm.org/bugs/show_bug.cgi?id=26807 Rafael Ávila de Espíndola changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #2 from Rafael Ávila de Espíndola --- The bug is in gold. I will reply there. -- 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 17193] ARM EABI 64-bit DIV+REM merge into a single divmod call
https://llvm.org/bugs/show_bug.cgi?id=17193 Renato Golin changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Renato Golin --- Fixed in r262507 -- 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 26818] New: lld incorrectly resolves function pointer relocation in dso
https://llvm.org/bugs/show_bug.cgi?id=26818
Bug ID: 26818
Summary: lld incorrectly resolves function pointer relocation
in dso
Product: lld
Version: unspecified
Hardware: PC
OS: FreeBSD
Status: NEW
Severity: normal
Priority: P
Component: All Bugs
Assignee: unassignedb...@nondot.org
Reporter: ema...@freebsd.org
CC: llvm-bugs@lists.llvm.org
Blocks: 23214
Classification: Unclassified
Consider this test program:
% cat lib.c
#include
int(*fp)(const char *, ...) = printf;
void
fn(void)
{
fp("hello %s\n", "world");
}
% cat main.c
void fn(void);
int
main(int argc, char *argv[])
{
fn();
}
Linking with ld.bfd:
% cc -fPIC -shared -o lib.so lib.c
% cc -fPIC -Wl,-rpath=. lib.so main.c
% ./a.out
hello world
And there's a relocation for 'fp' for printf:
% readelf -s lib.so | grep fp
7: 00200808 8 OBJECT GLOBAL DEFAULT 22 fp
47: 00200808 8 OBJECT GLOBAL DEFAULT 22 fp
% readelf -r lib.so | grep 200808
002007c8 00070006 R_X86_64_GLOB_DAT 00200808 fp + 0
00200808 00040001 R_X86_64_64 printf + 0
Linking with ld.lld:
% cc -fuse-ld=lld -fPIC -shared -o lib.so lib.c
% cc -fuse-ld=lld -fPIC -Wl,-rpath=. lib.so main.c
% ./a.out
zsh: segmentation fault (core dumped) ./a.out
And no relocation for the function pointer:
% readelf -s lib.so | grep fp
6: 3018 8 OBJECT GLOBAL DEFAULT 19 fp
21: 3018 8 OBJECT GLOBAL DEFAULT 19 fp
% readelf -r lib.so
Relocation section '.rela.dyn' at offset 0x438 contains 5 entries:
Offset Info Type Sym. ValueSym. Name +
Addend
2138 00030006 R_X86_64_GLOB_DAT __cxa_finalize +
0
2140 00020006 R_X86_64_GLOB_DAT
_Jv_RegisterClasses + 0
3008 0008 R_X86_64_RELATIVE
3008
3010 0008 R_X86_64_RELATIVE
2018
2148 00060006 R_X86_64_GLOB_DAT 3018 fp + 0
Relocation section '.rela.plt' at offset 0x4b0 contains 2 entries:
Offset Info Type Sym. ValueSym. Name +
Addend
3038 00030007 R_X86_64_JUMP_SLO __cxa_finalize +
0
3040 00070007 R_X86_64_JUMP_SLO 1150 printf + 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 26819] New: [aarch64] optimize obscured vector integer comparisons against zero
https://llvm.org/bugs/show_bug.cgi?id=26819
Bug ID: 26819
Summary: [aarch64] optimize obscured vector integer comparisons
against zero
Product: libraries
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: Backend: AArch64
Assignee: unassignedb...@nondot.org
Reporter: spatel+l...@rotateright.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
I think the AArch64 backend is missing a couple of folds related to vector
integer comparisons ( related x86 bug: bug 26701 ).
I'm not sure why anyone would write NEON code like this, but it could happen?
// Are elements of 'a' > -1? Ie, is 'a' positive?
int32x2_t test_vcgt_s32(int32x2_t a) {
return vcgt_s32(a, vceq_s32(a, a));
}
$ ./clang -O1 ...
test_vcge_s32:
sshrv0.2s, v0.2s, #31
mvn v0.8b, v0.8b
ret
The IR is optimized from a compare+sext to a shift+not in InstCombine.
But this can be optimized to: is 'a' >= 0?
So is this the optimal codegen?
cmgev0.2s, v0.2s, #0
ret
Similarly, for:
// Are elements of 'a' <= -1? Ie, is 'a' negative?
int32x2_t test_vcle_s32(int32x2_t a) {
return vcle_s32(a, vceq_s32(a, a) );
}
$ ./clang -O1 ...
test_vcle_s32:
movid1, #0x
cmgev0.2s, v1.2s, v0.2s
ret
Should this be:
cmltv0.2s, v0.2s, #0
ret
--
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 22470] [R600/SI] Glitch in Dota 2
https://llvm.org/bugs/show_bug.cgi?id=22470 Lorenzo Bona changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Lorenzo Bona --- (In reply to comment #1) > IS this still a problem? Sorry, forgot to close this bug. Yes, this has been solved long time ago, I can't remember when. Thank you. -- 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 23214] [META] Using LLD as FreeBSD's system linker
https://llvm.org/bugs/show_bug.cgi?id=23214 Bug 23214 depends on bug 26732, which changed state. Bug 26732 Summary: lld needs to provide _DYNAMIC symbol when creating a shared library https://llvm.org/bugs/show_bug.cgi?id=26732 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 26732] lld needs to provide _DYNAMIC symbol when creating a shared library
https://llvm.org/bugs/show_bug.cgi?id=26732 ema...@freebsd.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from ema...@freebsd.org --- Committed as r262348 -- 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 26729] lld: define special symbols _etext and _edata
https://llvm.org/bugs/show_bug.cgi?id=26729 ema...@freebsd.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from ema...@freebsd.org --- Committed as r262019 -- 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 23214] [META] Using LLD as FreeBSD's system linker
https://llvm.org/bugs/show_bug.cgi?id=23214 Bug 23214 depends on bug 26729, which changed state. Bug 26729 Summary: lld: define special symbols _etext and _edata https://llvm.org/bugs/show_bug.cgi?id=26729 What|Removed |Added Status|ASSIGNED|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 26820] New: [phabricator] Bogus "changed before commit".
https://llvm.org/bugs/show_bug.cgi?id=26820 Bug ID: 26820 Summary: [phabricator] Bogus "changed before commit". Product: new-bugs Version: unspecified Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: chisophu...@gmail.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified Consider: http://reviews.llvm.org/D17676?vs=49402&id=49666#toc It seems like whatever is detecting what is "changed before commit" is diffing the patch on the one hand with something having compiler-rt/trunk/ prepended to all file paths. Obviously, this makes this "changed before commit" completely useless. -- 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 26822] New: [seh] Jump out of finally causes verifier error
https://llvm.org/bugs/show_bug.cgi?id=26822
Bug ID: 26822
Summary: [seh] Jump out of finally causes verifier error
Product: clang
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: LLVM Codegen
Assignee: unassignedclangb...@nondot.org
Reporter: david.majne...@gmail.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
consider:
void f() {
__try {
} __finally {
goto lbl;
}
lbl:;
}
$ clang -cc1 -triple x86_64-pc-windows-msvc18.0.0 -fms-extensions -x c t.c
-emit-llvm-only
t.c:4:5: warning: jump out of __finally block has undefined behavior
goto lbl;
^
Referring to a basic block in another function!
br label %lbl
fatal error: error in backend: Broken function found, compilation aborted!
--
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 26824] New: [seh] continue out of finally crashes clang
https://llvm.org/bugs/show_bug.cgi?id=26824
Bug ID: 26824
Summary: [seh] continue out of finally crashes clang
Product: clang
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: LLVM Codegen
Assignee: unassignedclangb...@nondot.org
Reporter: david.majne...@gmail.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
consider:
void f() {
for (;;) {
__try {
} __finally {
continue;
}
}
}
run with:
clang -cc1 -triple x86_64-pc-windows-msvc18.0.0 -emit-llvm-only -fms-extensions
-x c t.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 26825] New: Clang faults generating coverage for macro expansion
https://llvm.org/bugs/show_bug.cgi?id=26825 Bug ID: 26825 Summary: Clang faults generating coverage for macro expansion Product: clang Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: -New Bugs Assignee: unassignedclangb...@nondot.org Reporter: dcalla...@fb.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified Created attachment 15975 --> https://llvm.org/bugs/attachment.cgi?id=15975&action=edit C++ source (no #includes) Clang fails when compiling the attached file clang++ -std=c++11 -c -fprofile-instr-generate -fcoverage-mapping bug.cpp -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 26730] lld: inconsistent joined/separate arg single-letter option support
https://llvm.org/bugs/show_bug.cgi?id=26730 Rui Ueyama changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 23214] [META] Using LLD as FreeBSD's system linker
https://llvm.org/bugs/show_bug.cgi?id=23214 Bug 23214 depends on bug 26730, which changed state. Bug 26730 Summary: lld: inconsistent joined/separate arg single-letter option support https://llvm.org/bugs/show_bug.cgi?id=26730 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 26826] New: scan-build does not catch returning pointers to local storage
https://llvm.org/bugs/show_bug.cgi?id=26826 Bug ID: 26826 Summary: scan-build does not catch returning pointers to local storage Product: clang Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Static Analyzer Assignee: kreme...@apple.com Reporter: swilli...@taranawireless.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified The attached file shows a function returns a pointer to an array in its local stack frame to its caller. This is dangerous, because an interrupt or other intervening function call made by the caller before referencing this returned pointer can clobber this region of memory, resulting in garbage values. I would have expected the static analyzer to flag this as questionable, but scan-build clang -O3 -Wall -c returns_pointer_to_local.c yields only: scan-build: Using '/home/swilliams-local/src/llvm-build/bin/clang-3.9' for static analysis scan-build: Removing directory '/tmp/scan-build-2016-03-02-165148-28031-1' because it contains no reports. scan-build: No bugs 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 26827] New: [AArch64] [Cortex-A53] mis-schedule due to store merge in DAG combiner
https://llvm.org/bugs/show_bug.cgi?id=26827 Bug ID: 26827 Summary: [AArch64] [Cortex-A53] mis-schedule due to store merge in DAG combiner Product: new-bugs Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: weimi...@codeaurora.org CC: llvm-bugs@lists.llvm.org Classification: Unclassified Created attachment 15979 --> https://llvm.org/bugs/attachment.cgi?id=15979&action=edit test case llc -mcpu=cortex-a53 < test/CodeGen/AArch64/qc-merge-store.ll -- 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 26471] [Polly] Start writing sphinx documentation for Polly
https://llvm.org/bugs/show_bug.cgi?id=26471 Tanya Lattner changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from Tanya Lattner --- Please confirm this is correct: http://polly.llvm.org/docs/ -- 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
