[llvm-bugs] [Bug 35010] Type punning in polly ACC
https://bugs.llvm.org/show_bug.cgi?id=35010 Philip changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #1 from Philip --- Fixed in r316872. -- 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 35131] New: [LoopIdiomRecognize] Incorrectly recognizes CTLZ
https://bugs.llvm.org/show_bug.cgi?id=35131
Bug ID: 35131
Summary: [LoopIdiomRecognize] Incorrectly recognizes CTLZ
Product: libraries
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: Scalar Optimizations
Assignee: unassignedb...@nondot.org
Reporter: i...@azulsystems.com
CC: llvm-bugs@lists.llvm.org
On the following test case loop is recognized as CTLZ, but in fact it is not:
define i32 @ctlz(i32 %n) {
entry:
br label %while.cond
while.cond: ; preds = %while.cond, %entry
%n.addr.0 = phi i32 [ %n, %entry ], [ %shr, %while.cond ]
%i.0 = phi i32 [ 0, %entry ], [ %inc, %while.cond ]
%shr = ashr i32 %n.addr.0, %i.0
%tobool = icmp eq i32 %shr, 0
%inc = add nsw i32 %i.0, 1
br i1 %tobool, label %while.end, label %while.cond
while.end:; preds = %while.cond
ret i32 %i.0
}
Problem here happens because "ashr i32 %n.addr.0, %i.0" is treated as if it was
"ashr i32 %n.addr.0, which is not true.
--
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 31579] ld.lld doesn't support --emmit-relocs (-q)
https://bugs.llvm.org/show_bug.cgi?id=31579 George Rimar changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #11 from George Rimar --- I think we have multiple users of --emit-relocs and no known issues about it. Closing. -- 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 34512] ld.lld crash (SEGV) with --emit-relocs + --gc-sections
https://bugs.llvm.org/show_bug.cgi?id=34512 Bug 34512 depends on bug 31579, which changed state. Bug 31579 Summary: ld.lld doesn't support --emmit-relocs (-q) https://bugs.llvm.org/show_bug.cgi?id=31579 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 35068] Possible bad optimisation of unsigned atomic fetch_sub(1) > 1 on x64
https://bugs.llvm.org/show_bug.cgi?id=35068 Craig Topper changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Craig Topper --- The inc/dec issues should be fixed after r316913 -- 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 34943] LoopUnrolling: APInts don't tolerate type mismatch.
https://bugs.llvm.org/show_bug.cgi?id=34943 Artem Dergachev changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #1 from Artem Dergachev --- Fixed in r316830. -- 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 35119] std::set_union accesses an element after it has been moved out.
https://bugs.llvm.org/show_bug.cgi?id=35119 Marshall Clow (home) changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Marshall Clow (home) --- Fixed in revision 316914. -- 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 35123] clang crashes with "-mllvm -enable-newgvn": Assertion `i_nocapture < OperandTraits::operands(this) && "getOperand() out of range!"' failed.
https://bugs.llvm.org/show_bug.cgi?id=35123
Davide Italiano changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|--- |FIXED
--- Comment #2 from Davide Italiano ---
Can't repro on ToT.
$ ./clang x.c -Os
x.c:9:14: warning: control reaches end of non-void function [-Wreturn-type]
char(fn1)() {}
^
x.c:17:18: warning: use of logical '&&' with constant operand
[-Wconstant-logical-operand]
c = (p1.f4 && 7) > (e && f || j);
^ ~
x.c:17:18: note: use '&' for a bitwise operation
c = (p1.f4 && 7) > (e && f || j);
^~
&
x.c:17:18: note: remove constant to silence this warning
c = (p1.f4 && 7) > (e && f || j);
~^~~~
x.c:17:29: warning: '&&' within '||' [-Wlogical-op-parentheses]
c = (p1.f4 && 7) > (e && f || j);
~~^~~~ ~~
x.c:17:29: note: place parentheses around the '&&' expression to silence this
warning
c = (p1.f4 && 7) > (e && f || j);
^
( )
x.c:26:5: warning: expression result unused [-Wunused-value]
g.f0;
~ ^~
4 warnings generated.
--
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 35132] New: Unwanted line break in #define
https://bugs.llvm.org/show_bug.cgi?id=35132 Bug ID: 35132 Summary: Unwanted line break in #define Product: clang Version: 5.0 Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: Formatter Assignee: unassignedclangb...@nondot.org Reporter: amaca...@gmail.com CC: djas...@google.com, kli...@google.com, llvm-bugs@lists.llvm.org Created attachment 19358 --> https://bugs.llvm.org/attachment.cgi?id=19358&action=edit source file Running clang-format with -style=file -i over attached C source file, with attached .clang-format results in line break between defined term and its definition and I cannot understand the reason behind this. -- 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 35133] New: PenaltyBreakComment does not seem to work
https://bugs.llvm.org/show_bug.cgi?id=35133 Bug ID: 35133 Summary: PenaltyBreakComment does not seem to work Product: clang Version: 5.0 Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: Formatter Assignee: unassignedclangb...@nondot.org Reporter: amaca...@gmail.com CC: djas...@google.com, kli...@google.com, llvm-bugs@lists.llvm.org Created attachment 19360 --> https://bugs.llvm.org/attachment.cgi?id=19360&action=edit source file Cannot understand preference to break after assignment instead of breaking comment in order not to exceed line length limit. -- 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 34956] -DLLVM_REVERSE_ITERATION:BOOL=ON in stage2 produces file comparison failures with stage3
https://bugs.llvm.org/show_bug.cgi?id=34956 Jack Howarth changed: What|Removed |Added Resolution|--- |INVALID Status|NEW |RESOLVED -- 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 35134] New: GCC does a better job with returning large structs
https://bugs.llvm.org/show_bug.cgi?id=35134
Bug ID: 35134
Summary: GCC does a better job with returning large structs
Product: libraries
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: Scalar Optimizations
Assignee: unassignedb...@nondot.org
Reporter: jmuizel...@mozilla.com
CC: llvm-bugs@lists.llvm.org
struct Foo {
int o[200];
};
struct Bar {
char p;
Foo f;
};
__attribute__((noinline))
Foo moo()
{
return {0};
}
void goo(Bar *f)
{
f->f = moo();
}
with -O3 -fno-exceptions -fomit-frame-pointer gives:
moo(): # @moo()
push rbx
mov rbx, rdi
xor esi, esi
mov edx, 800
call memset
mov rax, rbx
pop rbx
ret
goo(Bar*): # @goo(Bar*)
push r14
push rbx
sub rsp, 808
mov rbx, rdi
lea r14, [rsp + 8]
mov rdi, r14
call moo()
add rbx, 4
mov edx, 800
mov rdi, rbx
mov rsi, r14
call memcpy
add rsp, 808
pop rbx
pop r14
ret
in clang vs gcc's:
moo():
mov rdx, rdi
mov QWORD PTR [rdi], 0
mov QWORD PTR [rdi+792], 0
lea rdi, [rdi+8]
mov rcx, rdx
xor eax, eax
and rdi, -8
sub rcx, rdi
add ecx, 800
shr ecx, 3
rep stosq
mov rax, rdx
ret
goo(Bar*):
add rdi, 4
call moo()
rep ret
Notice the elided memcpy in goo()
--
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 35125] wrong code with opt "-newgvn -instcombine -newgvn"
https://bugs.llvm.org/show_bug.cgi?id=35125 Davide Italiano changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #12 from Davide Italiano --- r316953 -- 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 35135] New: [Unittests] Failures uncovered by randomly shuffling containers before sorting
https://bugs.llvm.org/show_bug.cgi?id=35135 Bug ID: 35135 Summary: [Unittests] Failures uncovered by randomly shuffling containers before sorting Product: new-bugs Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: mgr...@codeaurora.org CC: llvm-bugs@lists.llvm.org I have pushed a patch which randomly shuffles a container before calling std::sort or array_pod_sort: https://reviews.llvm.org/D39245 This is intended to uncover non-deterministic sorting order for elements with the same key. The patch cannot be merged unless the failures it uncovers can be fixed, otherwise bots will start breaking as soon as it merges. The following are the current ninja check-all failures with this patch (across all targets on an asserts build): Clang :: Driver/autocomplete.c Clang :: Misc/diag-template-diffing.cpp Clang :: Misc/error-limit-multiple-notes.cpp Clang :: OpenMP/task_firstprivate_codegen.cpp Clang :: OpenMP/task_private_codegen.cpp Clang :: OpenMP/taskloop_firstprivate_codegen.cpp Clang :: OpenMP/taskloop_lastprivate_codegen.cpp Clang :: OpenMP/taskloop_private_codegen.cpp Clang :: OpenMP/taskloop_simd_firstprivate_codegen.cpp Clang :: OpenMP/taskloop_simd_lastprivate 1 warning(s) in tests. _codegen.cpp Clang :: OpenMP/taskloop_simd_private_codegen.cpp Clang :: SemaCXX/builtin-ptrtomember-overload-1.cpp LLVM :: CodeGen/ARM/switch-minsize.ll LLVM :: CodeGen/Hexagon/args.ll LLVM :: CodeGen/Hexagon/expand-condsets-basic.ll LLVM :: CodeGen/Hexagon/gp-rel.ll LLVM :: CodeGen/Hexagon/packetize_cond_inst.ll LLVM :: CodeGen/Hexagon/simple_addend.ll LLVM :: CodeGen/Hexagon/swp-matmul-bitext.ll LLVM :: CodeGen/Hexagon/swp-stages4.ll LLVM :: CodeGen/Hexagon/swp-vsum.ll LLVM :: CodeGen/X86/switch-bt.ll LLVM :: CodeGen/X86/switch-density.ll LLVM :: CodeGen/X86/switch.ll LLVM :: CodeGen/X86/x86-shrink-wrapping.ll LLVM :: DebugInfo/X86/multiple-aranges.ll LLVM :: MC/Hexagon/align.s LLVM :: MC/Hexagon/asmMap.s LLVM :: MC/Hexagon/bug20416.s LLVM :: MC/Hexagon/double-vector-producer.s LLVM :: MC/Hexagon/duplex-registers.s LLVM :: MC/Hexagon/instructions/j.s LLVM :: Transforms/Util/PredicateInfo/testandor.ll In order to reproduce a failure you would need to apply the above patch and then change all calls to std::sort and array_pod_sort with llvm::sort in the source/header files related to your test case. Alternately, you can apply these 2 patches which convert std::sort & array_pod_sort to llvm::sort: llvm --> https://reviews.llvm.org/differential/diff/120879 clang --> https://reviews.llvm.org/differential/diff/120880 -- 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 35126] wrong code with opt "-instcombine -sroa -newgvn"
https://bugs.llvm.org/show_bug.cgi?id=35126 Davide Italiano changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #2 from Davide Italiano --- Except that I forgot to update polly my checkout :) This is a dupe of pr35125. -- 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 35126] wrong code with opt "-instcombine -sroa -newgvn"
https://bugs.llvm.org/show_bug.cgi?id=35126 Simon Pilgrim changed: What|Removed |Added Resolution|FIXED |DUPLICATE CC||llvm-...@redking.me.uk --- Comment #3 from Simon Pilgrim --- *** This bug has been marked as a duplicate of bug 35125 *** -- 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 35136] New: Some clang diagnostic produces overlapping FixIts which crashes clang-tidy
https://bugs.llvm.org/show_bug.cgi?id=35136
Bug ID: 35136
Summary: Some clang diagnostic produces overlapping FixIts
which crashes clang-tidy
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Frontend
Assignee: unassignedclangb...@nondot.org
Reporter: lebedev...@gmail.com
CC: llvm-bugs@lists.llvm.org
While working on https://reviews.llvm.org/D36836, i noticed that it's tests
trigger an assert in clang-tidy.
Here is the reproducer: (insert into
unittests/clang-tidy/ClangTidyDiagnosticConsumerTest.cpp)
class TestWithoutFixitsCheck : public ClangTidyCheck {
public:
TestWithoutFixitsCheck(StringRef Name, ClangTidyContext *Context)
: ClangTidyCheck(Name, Context) {}
void registerMatchers(ast_matchers::MatchFinder *Finder) override {
Finder->addMatcher(ast_matchers::functionDecl().bind("func"), this);
}
void check(const ast_matchers::MatchFinder::MatchResult &Result) override {
const auto *Func = Result.Nodes.getNodeAs("func");
diag(Func->getLocation(), "hello");
}
};
TEST(ClangTidyDiagnosticConsumer, DoesNotParseNotesAsFixIts) {
// Test that it does not die with an assert.
runCheckOnCode("void a() { 1 && 1; }");
}
In build with asserts, it fails with:
$ ninja check-clang-tools
[0/1] Running the Clang extra tools' regression tests
FAIL: Extra Tools Unit Tests ::
clang-tidy/./ClangTidyTests/ClangTidyDiagnosticConsumer.DoesNotParseNotesAsFixIts
(500 of 591)
TEST 'Extra Tools Unit Tests ::
clang-tidy/./ClangTidyTests/ClangTidyDiagnosticConsumer.DoesNotParseNotesAsFixIts'
FAILED
Note: Google Test filter =
ClangTidyDiagnosticConsumer.DoesNotParseNotesAsFixIts
[==] Running 1 test from 1 test case.
[--] Global test environment set-up.
[--] 1 test from ClangTidyDiagnosticConsumer
[ RUN ] ClangTidyDiagnosticConsumer.DoesNotParseNotesAsFixIts
Fix conflicts with existing fix! The new replacement overlaps with an existing
replacement.
New replacement: input.cc: 12:+5:""
Existing replacement: input.cc: 13:+2:"&"
ClangTidyTests:
/build/clang-tools-extra/clang-tidy/ClangTidyDiagnosticConsumer.cpp:86: virtual
void (anonymous
namespace)::ClangTidyDiagnosticRenderer::emitCodeContext(clang::FullSourceLoc,
DiagnosticsEngine::Level, SmallVectorImpl &,
ArrayRef): Assertion `false && "Fix conflicts with existing
fix!"' failed.
#0 0x0074fee4 PrintStackTraceSignalHandler(void*)
(/build/llvm-build-Clang-release/tools/clang/tools/extra/unittests/clang-tidy/./ClangTidyTests+0x74fee4)
#1 0x00750246 SignalHandler(int)
(/build/llvm-build-Clang-release/tools/clang/tools/extra/unittests/clang-tidy/./ClangTidyTests+0x750246)
#2 0x7f35c919c0c0 __restore_rt
(/lib/x86_64-linux-gnu/libpthread.so.0+0x110c0)
#3 0x7f35c7d1dfff gsignal (/lib/x86_64-linux-gnu/libc.so.6+0x32fff)
#4 0x7f35c7d1f42a abort (/lib/x86_64-linux-gnu/libc.so.6+0x3442a)
#5 0x7f35c7d16e67 (/lib/x86_64-linux-gnu/libc.so.6+0x2be67)
#6 0x7f35c7d16f12 (/lib/x86_64-linux-gnu/libc.so.6+0x2bf12)
#7 0x00ba787c (anonymous
namespace)::ClangTidyDiagnosticRenderer::emitCodeContext(clang::FullSourceLoc,
clang::DiagnosticsEngine::Level,
llvm::SmallVectorImpl&,
llvm::ArrayRef)
(/build/llvm-build-Clang-release/tools/clang/tools/extra/unittests/clang-tidy/./ClangTidyTests+0xba787c)
#8 0x00b07be4
clang::DiagnosticRenderer::emitDiagnostic(clang::FullSourceLoc,
clang::DiagnosticsEngine::Level, llvm::StringRef,
llvm::ArrayRef, llvm::ArrayRef,
llvm::PointerUnion)
(/build/llvm-build-Clang-release/tools/clang/tools/extra/unittests/clang-tidy/./ClangTidyTests+0xb07be4)
#9 0x00ba5559
clang::tidy::ClangTidyDiagnosticConsumer::HandleDiagnostic(clang::DiagnosticsEngine::Level,
clang::Diagnostic const&)
(/build/llvm-build-Clang-release/tools/clang/tools/extra/unittests/clang-tidy/./ClangTidyTests+0xba5559)
#10 0x00a08159
clang::DiagnosticIDs::ProcessDiag(clang::DiagnosticsEngine&) const
(/build/llvm-build-Clang-release/tools/clang/tools/extra/unittests/clang-tidy/./ClangTidyTests+0xa08159)
#11 0x00a01d5a clang::DiagnosticsEngine::EmitCurrentDiagnostic(bool)
(/build/llvm-build-Clang-release/tools/clang/tools/extra/unittests/clang-tidy/./ClangTidyTests+0xa01d5a)
#12 0x00f2dca9 clang::Sema::EmitCurrentDiagnostic(unsigned int)
(/build/llvm-build-Clang-release/tools/clang/tools/extra/unittests/clang-tidy/./ClangTidyTests+0xf2dca9)
#13 0x011f968a
clang::Sema::CheckLogicalOperands(clang::ActionResult&,
clang::ActionResult&, clang::SourceLocation,
clang::BinaryOperatorKind)
(/build/llvm-build-Clang-release/tools/clang/tools/extra/unittests/clang-tidy/./ClangTidyTests+0x11f968a)
#14 0x011f712b clang::Sema::CreateBuiltinBinOp(clang::SourceLocation,
clang::BinaryOperatorKind, clang::Expr*, clan
[llvm-bugs] [Bug 35137] New: ASan strotol interceptor breaks errno on Windows
https://bugs.llvm.org/show_bug.cgi?id=35137
Bug ID: 35137
Summary: ASan strotol interceptor breaks errno on Windows
Product: compiler-rt
Version: unspecified
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: compiler-rt
Assignee: unassignedb...@nondot.org
Reporter: r...@google.com
CC: llvm-bugs@lists.llvm.org
Running this program on Windows prints "errno: 34" without asan and "errno: 0"
with asan:
#include
#include
#include
#include
void print_strtol_results(const char *input) {
char *end = 0;
long result = strtol(input, &end, 10);
int err = errno;
printf("input: %s, end: %s, result: %ld, errno: %d\n", input, end, result,
err);
}
int main() {
//print_strtol_results("2147483647");
print_strtol_results("2147483648");
printf("&errno: %p, errno: %d\n", &errno, errno);
return 0;
}
This is because ASan intercepts many versions of strtol and redirects them all
to itself. It then delegates to ntdll!strtol, which doesn't set errno, because
errno is a CRT concept, and ntdll is layered below the CRT.
--
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 35138] New: Confusing error message with missing semicolon and assert
https://bugs.llvm.org/show_bug.cgi?id=35138
Bug ID: 35138
Summary: Confusing error message with missing semicolon and
assert
Product: clang
Version: trunk
Hardware: PC
OS: FreeBSD
Status: NEW
Severity: enhancement
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: kparz...@codeaurora.org
CC: llvm-bugs@lists.llvm.org
I just ran into this. This is not really a bug as much as it's an unfortunate
consequence of macro expansion. Maybe it's possible for clang to detect this as
"missing semicolon" anyway...
--- confusing.c ---
#include
int sammy(void);
int danny() {
int x = sammy()
assert(x != 0);
return x+1;
}
---
$ clang -c confusing.c
confusing.c:7:3: error: called object type 'int' is not a function or function
pointer
assert(x != 0);
^
/usr/include/assert.h:89:3: note: expanded from macro 'assert'
((expr) \
^
1 error generated.
--
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 35139] New: clang -flto doesn't respect -fno-unroll-loops option
https://bugs.llvm.org/show_bug.cgi?id=35139
Bug ID: 35139
Summary: clang -flto doesn't respect -fno-unroll-loops option
Product: clang
Version: unspecified
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P
Component: Driver
Assignee: unassignedclangb...@nondot.org
Reporter: s...@quanttec.com
CC: llvm-bugs@lists.llvm.org
When I let clang link together object files that I produced with -flto -Os, the
link time optimization seems to respect the -Os option. When I let it link
files produced with -flto -O2 -fno-unroll-loops the -fno-unroll-loops flag
seems to be ignored.
Test case:
The following 3 commands produce an executable with an unrolled loop (using
clang 5.0 and the files pasted below; verified by disassembling the
executable):
> clang -flto -O2 -fno-unroll-loops -c loop.c -o loop.o
> clang -O2 -fno-unroll-loops -c main.c -o main.o
> clang -flto -O2 -fno-unroll-loops loop.o main.o -o main
I'd expect this to produce an executable without an unrolled loop, even when
the last command only reads `clang -flto loop.o main.o -o main`, as is the case
when using -Os instead of -O2 when compiling loop.c and main.c.
Adding `-Xlinker -mllvm -Xlinker -unroll-count=0` to the last command actually
does stop LLVM from unrolling the loop.
-- loop.c --
__attribute__((noinline))
int loop(float *array, int count) {
float i1 = 1;
for (int i = 0; i < count; ++i, i1 += 1) {
array[i] += i1;
}
return count;
}
-- loop.h --
int loop(float *array, int count);
-- main.c --
#include "loop.h"
int main() {
volatile int zero = 0;
return loop(0, zero);
}
--
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 35140] New: MIPS: Thread local variable not flagged as thread local in object file
https://bugs.llvm.org/show_bug.cgi?id=35140
Bug ID: 35140
Summary: MIPS: Thread local variable not flagged as thread
local in object file
Product: libraries
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: Backend: MIPS
Assignee: unassignedb...@nondot.org
Reporter: a...@crichton.co
CC: llvm-bugs@lists.llvm.org
We've been getting weird linkage errors in rust-lang/rust [1] which I believe
we've minimized to this IR:
@foo = external hidden thread_local global i32
define i32 @bar() {
%a = load i32, i32* @foo
ret i32 %a
}
I don't personally know a lot about MIPS unfortunately, but I think this may
show the problem:
$ llc foo.ll -filetype=obj -o foo.o -mtriple=mipsel-unknown-linux-gnu
-relocation-model=pic
$ readelf -Ws foo.o
Symbol table '.symtab' contains 7 entries:
Num:Value Size TypeBind Vis Ndx Name
0: 0 NOTYPE LOCAL DEFAULT UND
1: 0 FILELOCAL DEFAULT ABS foo.ll
2: 0 SECTION LOCAL DEFAULT2
3: 0 NOTYPE GLOBAL DEFAULT UND __tls_get_addr
4: 0 NOTYPE GLOBAL DEFAULT UND _gp_disp
5: 56 FUNCGLOBAL DEFAULT2 bar
6: 0 NOTYPE GLOBAL HIDDEN UND foo
Note that the import of `foo` under "Type" says "NOTYPE", whereas normally TLS
variables have "TLS" mentioned there. Also note that if `hidden` is removed
from the IR or the `-relocation-model=pic` argument is dropped then the "Type"
listed is indeed "TLS".
Is this perhaps expected behavior and I'm barking up the wrong tree? I tried
compiling the equivalent C code with gcc to see what it output:
$ cat foo.c
extern __thread int foo __attribute__((visibility("hidden")));
int bar() {
return foo;
}
$ mipsel-linux-gnu-gcc foo.c -c && mipsel-linux-gnu-readelf -Ws foo.o
Symbol table '.symtab' contains 14 entries:
Num:Value Size TypeBind Vis Ndx Name
0: 0 NOTYPE LOCAL DEFAULT UND
1: 0 FILELOCAL DEFAULT ABS foo.c
2: 0 SECTION LOCAL DEFAULT1
3: 0 SECTION LOCAL DEFAULT3
4: 0 SECTION LOCAL DEFAULT4
5: 0 SECTION LOCAL DEFAULT9
6: 0 SECTION LOCAL DEFAULT5
7: 0 SECTION LOCAL DEFAULT6
8: 0 SECTION LOCAL DEFAULT7
9: 0 SECTION LOCAL DEFAULT 10
10: 0 SECTION LOCAL DEFAULT 11
11: 60 FUNCGLOBAL DEFAULT1 bar
12: 0 NOTYPE GLOBAL DEFAULT UND __gnu_local_gp
13: 0 TLS GLOBAL HIDDEN UND foo
Note that the reference to `foo` is flagged as TLS and HIDDEN, so that's what
caused me to think that this may be an accidental bug in LLVM's codegen
perhaps?
[1]: https://travis-ci.org/rust-lang/rust/jobs/293501043
--
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 20865] autoconf unconditionally defines _GNU_SOURCE
https://bugs.llvm.org/show_bug.cgi?id=20865 Richard Smith changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED CC||richard-l...@metafoo.co.uk --- Comment #1 from Richard Smith --- LLVM has not had an autoconf build system for a long time. -- 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 35141] New: reconsider when we automatically define _GNU_SOURCE
https://bugs.llvm.org/show_bug.cgi?id=35141 Bug ID: 35141 Summary: reconsider when we automatically define _GNU_SOURCE Product: clang Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: C++ Assignee: unassignedclangb...@nondot.org Reporter: richard-l...@metafoo.co.uk CC: dgre...@apple.com, llvm-bugs@lists.llvm.org Currently, Clang follows GCC in automatically defining _GNU_SOURCE when compiling C++ on a glibc platform. We should revisit this. We need _GNU_SOURCE for the following: 1) GNU extensions used by user code. 2) GNU extensions used in the implementation of libstdc++. 3) C99 and C11 extensions. For case #1, we could ask the user to provide -D_GNU_SOURCE explicitly on the command line when compiling C++, as they are required to when compiling C. This would break compatibility with GCC, though, so isn't obviously a win, but would equally allow us to accept valid code that -D_GNU_SOURCE rejects. Perhaps a separate flag for controlling this would be best. For case #2, we may be able to get away with a smaller set of extensions. In particular, _ISOC99_SOURCE and _ISOC11_SOURCE appear to be sufficient to support most or all of libstdc++, and also appear to be sufficient for libc++. Case #3 just needs _ISOC99_SOURCE / _ISOC11_SOURCE. (glibc should really be able to figure this one out for itself based on the value of __cplusplus, but it doesn't seem to do so today.) At the very least, we should define _ISOCxx_SOURCE automatically based on the C++ language mode, so that users need only pass -U_GNU_SOURCE to get a working C++ compilation without the extensions. (Unfortunately, even this is not easy right now, as the code adding this define is scattered throughout our target definitions.) -- 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 34865] Clang doesn't require references to be listed in lambda capture
https://bugs.llvm.org/show_bug.cgi?id=34865 Richard Smith changed: What|Removed |Added Resolution|--- |INVALID Status|NEW |RESOLVED CC||richard-l...@metafoo.co.uk --- Comment #3 from Richard Smith --- Clang is correct. Only odr-used variables need to be captured. Naming a reference initialized by a constant expression does not constitute an odr-use. See http://wiki.edg.com/pub/Wg21albuquerque/CoreWorkingGroup/cwg_defects.html#1472 which introduced the "references initialized by constant expressions don't need to be captured" rule. -- 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 35142] New: Mishandling SEH filters for available_externally functions
https://bugs.llvm.org/show_bug.cgi?id=35142
Bug ID: 35142
Summary: Mishandling SEH filters for available_externally
functions
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Core LLVM classes
Assignee: unassignedb...@nondot.org
Reporter: pe...@pcc.me.uk
CC: llvm-bugs@lists.llvm.org
$ cat 1.cc
static void try_body(int numerator, int denominator, int *myres) {
*myres = numerator / denominator;
}
inline int safe_div(int numerator, int denominator, int *res) {
int myres = 0;
int success = 1;
__try {
try_body(numerator, denominator, &myres);
} __except (1) {
success = -42;
}
*res = myres;
return success;
}
void *f() { return (void *)&safe_div; }
$ cat 2.cc
static void try_body(int numerator, int denominator, int *myres) {
*myres = numerator / denominator;
}
inline int safe_div(int numerator, int denominator, int *res) {
int myres = 0;
int success = 1;
__try {
try_body(numerator, denominator, &myres);
} __except (1) {
success = -42;
}
*res = myres;
return success;
}
void *g() { return (void *)&safe_div; }
$ clang-cl /c 1.cc 2.cc -flto=thin -m32
$ lld-link 1.obj 2.obj /nodefaultlib /entry:f /opt:lldlto=0 /lldsavetemps
LLVM ERROR: assembler label 'L?safe_div@@YAHHHPAH@Z$parent_frame_offset' can
not be undefined
What's going on here is that the linker is choosing 1.obj's definition of
safe_div as prevailing, and requesting that 2.obj's definition be dropped. It
does this by setting linkage to available_externally. This reveals two bugs.
The first is that the localrecover check in Verifier.cpp is insufficient; under
the current semantics it would need to account for available_externally linkage
by calling isDeclarationForLinker instead of isDeclaration.
Even if we did that, though, we'd still hit a verifier check for this test
case, and the fix for that bug is unclear. At the object file level, 2.obj
contains an SEH filter with information about the non-prevailing definition of
safe_seh. The fix I have in mind is that because it is impossible for there to
be an active stack frame for said non-prevailing definition, the behaviour of
the SEH filter is undefined, and we can simply treat the intrinsic call as
equivalent to unreachable if it refers to an undefined 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
[llvm-bugs] [Bug 34865] Clang doesn't require references to be listed in lambda capture
https://bugs.llvm.org/show_bug.cgi?id=34865
Richard Smith changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|INVALID |---
--- Comment #4 from Richard Smith ---
Reopening: while the warning may be correct, the location if the diagnostic is
not quite right. We should instead be pointing at the point of use:
test2.cpp:4:29: warning: lambda capture 'varRef' is not required to be captured
for this use [-Wunused-lambda-capture]
return [&varRef]{return varRef;}();
^
... and it'd be a good idea to add a note, something like:
test2.cpp:3:29: note: 'varRef' is a reference bound to a constant expression
evaluating to 'var'; that lvalue will be used in place of 'varRef' in the
lambda body
int& varRef = var;
^
--
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 35143] New: Failure to delete dead store
https://bugs.llvm.org/show_bug.cgi?id=35143
Bug ID: 35143
Summary: Failure to delete dead store
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Scalar Optimizations
Assignee: unassignedb...@nondot.org
Reporter: chisophu...@gmail.com
CC: llvm-bugs@lists.llvm.org
struct S {
int x[5];
};
S get_S();
void foo() {
S s = get_S();
s.x[5] = 8;
}
https://godbolt.org/g/QcpRBY
Clang does not delete the store to `s.x[5] = 8`.
Looking at the IR, the pointer out argument passed to get_S seems to be marked
as `sret`. I don't know if that is strong enough to allow inferring `noescape`
on the pointer, but even manually adding `noescape` I don't see that store
being deleted by the O2 pipeline.
--
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] Issue 3821 in oss-fuzz: llvm/clang-proto-fuzzer: ASSERT: (isa(ExactNotTaken) || !isa(MaxNotTake
Comment #2 on issue 3821 by k...@google.com: llvm/clang-proto-fuzzer:
ASSERT: (isa(ExactNotTaken) |
| !isa(MaxNotTake
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=3821#c2
C repro:
void foo(int *a) {
while (((1+(1+a[0]))+1)){
}
while ((a[0]+a[32])){
a[0]=1;
}
while (((1/(1+a[0]))+1)){
a[0]=(a[0]+1);
}
}
clang -cc1 -triple x86_64-unknown-linux-gnu -emit-obj z.cc -O2
lib/Analysis/ScalarEvolution.cpp:6567:
llvm::ScalarEvolution::ExitLimit::ExitLimit(const llvm::SCEV *, const
llvm::SCEV *, bool, ArrayRefllvm::SCEVPredicate *> *>): Assertion
`(isa(ExactNotTaken) |
| !isa(MaxNotTaken)) && "Exact is not allowed to be
less precise than Max"' failed.
--
You received this message because:
1. You were specifically CC'd on the issue
You may adjust your notification preferences at:
https://bugs.chromium.org/hosting/settings
Reply to this email to add a comment.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
