[llvm-bugs] [Bug 38099] New: Column Limit = 0 and Comment Alignement not working
https://bugs.llvm.org/show_bug.cgi?id=38099
Bug ID: 38099
Summary: Column Limit = 0 and Comment Alignement not working
Product: clang
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: Formatter
Assignee: unassignedclangb...@nondot.org
Reporter: gnue...@gmail.com
CC: djas...@google.com, kli...@google.com,
llvm-bugs@lists.llvm.org
Format the following Code (with ColumnLimit: 0) :
enum EFlags : uint32_t
{
eA= 1 << 0, /*!< Some multiine comment
Some multiline comment, bla bla bla bla */
eA= 1 << 98127398172391723, /*!< Some multiine comment
Some multiline comment, bla bla bla
bla */
};
results in
enum EFlags : uint32_t
{
eA = 1 << 0, /*!< Some multiine comment
Some multiline comment, bla bla bla bla */
eA = 1 << 98127398172391723, /*!< Some multiine comment
Some multiline comment, bla bla bla
bla */
};
Where as (ColumnLimit>0, here 500)
Results in
enum EFlags : uint32_t
{
eA = 1 << 0, /*!< Some multiine comment
Some multiline comment, bla bla bla
bla */
eA = 1 << 98127398172391723, /*!< Some multiine comment
Some multiline comment, bla bla bla
bla */
};
There is something different going on for ColumnLimit:0 and I thing it should
look like the last resut.
--
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 38101] New: [llvm-mca] implement a better framework for error handling.
https://bugs.llvm.org/show_bug.cgi?id=38101 Bug ID: 38101 Summary: [llvm-mca] implement a better framework for error handling. Product: new-bugs Version: unspecified Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: andrea.dibia...@gmail.com CC: clement.cour...@gmail.com, greg.bedw...@sony.com, lebedev...@gmail.com, llvm-bugs@lists.llvm.org, llvm-...@redking.me.uk, matthew.da...@sony.com, spatel+l...@rotateright.com Blocks: 37696 We need to set up a proper framework for handling warnings and errors. There are a few places in InstrBuilder where we call llvm::report_fatal_error. This will become a problem when we decide to finalize bug 37696 and we move towards llvm-mca as a library. We don't want to have calls to report_fatal_error from inside of the library code. Instead, errors and warnings should be correctly diagnosed outside of InstrBuilder. This is a blocker for bug 37696. Referenced Bugs: https://bugs.llvm.org/show_bug.cgi?id=37696 [Bug 37696] [llvm-mca] llvm-mca as a library -- 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 38102] New: clang-cl: ICE passing __uint128_t as a template parameter
https://bugs.llvm.org/show_bug.cgi?id=38102 Bug ID: 38102 Summary: clang-cl: ICE passing __uint128_t as a template parameter Product: clang Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: C++ Assignee: unassignedclangb...@nondot.org Reporter: deg...@gmail.com CC: dgre...@apple.com, llvm-bugs@lists.llvm.org In this gist I have a workaround for the above bug of the original code. I've attached the requested files. The (my) code is used in testing with PractRand and shows no FAIL!!! until 256 gigabytes, which conforms very positively that the (my) code is compiled correctly by LLVM. This code does compile with GCC (according to the original author). -- 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 36269] Clang 7 hits segmentation fault when compiling with -fsanitize=undefined
https://bugs.llvm.org/show_bug.cgi?id=36269 Vincent Le Bourlot changed: What|Removed |Added CC||llvm-bugs@lists.llvm.org Component|C++'1z |-New Bugs -- 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 38071] R600TargetLowering::LowerOperation uses helper function with wrong subtarget, resulting in incorrect data being read
https://bugs.llvm.org/show_bug.cgi?id=38071 Tom Stellard 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 38103] New: Bad for loop copy optimization when using -fno-builtin-memcpy -fno-builtin-memmove
https://bugs.llvm.org/show_bug.cgi?id=38103
Bug ID: 38103
Summary: Bad for loop copy optimization when using
-fno-builtin-memcpy -fno-builtin-memmove
Product: clang
Version: 6.0
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: C++
Assignee: unassignedclangb...@nondot.org
Reporter: gchate...@google.com
CC: dgre...@apple.com, llvm-bugs@lists.llvm.org
Straightforward copy using a for loop with known size at compile time leads to
very poor assembly.
> #include
>
> template
> void Copy(char* __restrict dst, const char* __restrict src) {
> for (size_t i = 0; i < kBlockSize; ++i) dst[i] = src[i];
> }
>
> template void Copy<15>(char* __restrict dst, const char* __restrict src);
https://godbolt.org/g/YFq3o6
This can be mitigated by the introduction of a temporary buffer like so:
> template
> void Copy(char* __restrict dst, const char* __restrict src) {
> char tmp[kBlockSize];
> for (size_t i = 0; i < kBlockSize; ++i) tmp[i] = src[i];
> for (size_t i = 0; i < kBlockSize; ++i) dst[i] = tmp[i];
> }
https://godbolt.org/g/48Dghk
It works up to 25B and produce bad code from 26B onwards.
Check the resulting code for 32B for instance: https://godbolt.org/g/jZwcrv
--
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 38104] New: LLD's termination code does not allow code coverage analysis to work properly.
https://bugs.llvm.org/show_bug.cgi?id=38104
Bug ID: 38104
Summary: LLD's termination code does not allow code coverage
analysis to work properly.
Product: lld
Version: unspecified
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: ELF
Assignee: unassignedb...@nondot.org
Reporter: gri...@accesssoftek.com
CC: llvm-bugs@lists.llvm.org
Created attachment 20542
--> https://bugs.llvm.org/attachment.cgi?id=20542&action=edit
callstack
I am not sure we can call it a bug of LLD, though it seems at least something
worth to document. (And maybe to improve somehow).
Currently, LLD uses _exit for error() and fatal() calls:
https://github.com/llvm-mirror/lld/blob/master/Common/ErrorHandler.cpp#L60
That does not allow to test code coverage properly sometimes.
Imagine the following code:
#include
#include
__attribute__((noreturn)) void fatal() {
exit(0);
}
int main() {
fatal();
return 0;
}
If we compile and run it as
clang++ test.c --coverage -fPIC -std=c++11 -fprofile-arcs -ftest-coverage -o
test
./test
We'll see the .gcno and .gcda created and will be able to generate the coverage
report:
~/LLVM/build/bin/llvm-cov gcov test.gcda
But if we change "exit" to "_exit", then no .gcda file is created after running
the app.
That happens because _exit does not do enough cleaning, buffers flushing etc.
The same happens with LLD. If I change "_exit" to "exit" at a mentioned line,
it allows obtaining the correct reports about code coverage.
There is a problem about race conditions though. When using exit() LLD hangs
during
running the tests when multithreading is enabled. I was able to catch
and debug it (reproduces on invalid-cie-length.s test case for me).
Screenshot attached shows how 2 threads are stuck in destructors and waiting
for something.
The issue happens in the following code:
https://github.com/llvm-mirror/llvm/blob/master/lib/Support/Parallel.cpp#L94
At line 103 we call the Task() functor. Here Task() calls fatal() inside, which
is "noreturn" and
calls _exit originally. After changing _exit() to exit(), the code starts to
execute static destructors
and we stuck because of that in the ~ThreadPoolExecutor which waits for ~Latch
infinitely
because line 105 ("Done.dec();") is never executed.
The case above happens because we call fatal() in the parrallel_foreach thread.
That particular fatal() is coming from EhFrame parser:
https://github.com/llvm-mirror/lld/blob/master/ELF/EhFrame.cpp#L46
It should be possible to workaround that race condition if we will use error()
instead of fatal(), which usually does not exit immediately.
It might be enough for building coverage report purposes.
--
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 38031] Unsupported ARM Neon intrinsics in Target-specific DAG combine function for VLDDUP
https://bugs.llvm.org/show_bug.cgi?id=38031 Dave Green changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #3 from Dave Green --- The tests we have indeed did go green. Thanks for the fix! -- 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 7701 in oss-fuzz: llvm/llvm-isel-fuzzer--aarch64-O2: ASSERT: isa(Val) && "cast() argument of incompatible type!"
Updates: Labels: Deadline-Approaching Comment #4 on issue 7701 by sheriff...@chromium.org: llvm/llvm-isel-fuzzer--aarch64-O2: ASSERT: isa(Val) && "cast() argument of incompatible type!" https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=7701#c4 This bug is approaching its deadline for being fixed, and will be automatically derestricted within 7 days. If a fix is planned within 2 weeks after the deadline has passed, a grace extension can be granted. - Your friendly Sheriffbot -- 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
[llvm-bugs] Issue 7742 in oss-fuzz: llvm/llvm-isel-fuzzer--wasm32-O2: Null-dereference READ in llvm::WebAssemblyAsmPrinter::EmitFunctionBodyStart
Updates: Labels: Deadline-Approaching Comment #4 on issue 7742 by sheriff...@chromium.org: llvm/llvm-isel-fuzzer--wasm32-O2: Null-dereference READ in llvm::WebAssemblyAsmPrinter::EmitFunctionBodyStart https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=7742#c4 This bug is approaching its deadline for being fixed, and will be automatically derestricted within 7 days. If a fix is planned within 2 weeks after the deadline has passed, a grace extension can be granted. - Your friendly Sheriffbot -- 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
[llvm-bugs] Issue 7698 in oss-fuzz: llvm/llvm-dwarfdump-fuzzer: Heap-buffer-overflow in llvm::DataExtractor::getU16
Updates: Labels: Deadline-Approaching Comment #5 on issue 7698 by sheriff...@chromium.org: llvm/llvm-dwarfdump-fuzzer: Heap-buffer-overflow in llvm::DataExtractor::getU16 https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=7698#c5 This bug is approaching its deadline for being fixed, and will be automatically derestricted within 7 days. If a fix is planned within 2 weeks after the deadline has passed, a grace extension can be granted. - Your friendly Sheriffbot -- 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
[llvm-bugs] [Bug 38105] New: LTO builds fail when dllimport functions are called locally
https://bugs.llvm.org/show_bug.cgi?id=38105
Bug ID: 38105
Summary: LTO builds fail when dllimport functions are called
locally
Product: new-bugs
Version: unspecified
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: dma...@mozilla.com
CC: llvm-bugs@lists.llvm.org, l...@inglorion.net,
r...@google.com, tejohn...@google.com
When a function is declared dllimport but called directly (i.e. in the same
binary), a non-LTO build will issue a warning but still succeed (same as MSVC).
LTO and ThinLTO builds fail with linkage complaints.
This is preventing Firefox's use of LTO on Windows:
https://bugzilla.mozilla.org/show_bug.cgi?id=1448976
clang version 7.0.0 (trunk 336407)
$ cat a.cpp
__declspec(dllimport) int foo();
int main() { return foo(); }
$ cat b.cpp
int foo() { return 42; }
$ cat test.sh
#!/bin/bash
rm -rf *.obj *.exe
clang-cl $FLAG -O2 -c a.cpp b.cpp
lld-link -nodefaultlib -entry:main a.obj b.obj
$ ./test.sh
lld-link.exe: warning: a.obj: locally defined symbol imported: ?foo@@YAHXZ
(defined in b.obj) [LNK4217]
$ FLAG=-flto ./test.sh
Global is external, but doesn't have external or weak linkage!
i32 ()* @"?foo@@YAHXZ"
LLVM ERROR: Broken module found, compilation aborted!
$ FLAG=-flto=thin ./test.sh
lld-link.exe: error: undefined symbol: ?foo@@YAHXZ
>>> referenced by lto.tmp:(main)
--
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 38106] New: Undefined reference error when "static const" variable is initialized in line (but works out of line)
https://bugs.llvm.org/show_bug.cgi?id=38106
Bug ID: 38106
Summary: Undefined reference error when "static const" variable
is initialized in line (but works out of line)
Product: clang
Version: 6.0
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: LLVM Codegen
Assignee: unassignedclangb...@nondot.org
Reporter: albert.szilv...@autodesk.com
CC: llvm-bugs@lists.llvm.org
The following code demonstrates the issue.
#include
class Foo
{
public:
const static long long foo = 5;
const long long* x = &foo;
};
//const long long Foo::foo = 5; // uncomment this and remove the initialization
in the class to make it link.
int main(int argc, const char * argv[]) {
Foo foo;
std::cout << *(foo.x) << std::endl;
return 0;
}
Similar to https://bugs.llvm.org/show_bug.cgi?id=26006
--
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 38047] Regression in compile time during Jump Threading passes between LLVM 6 and 7
https://bugs.llvm.org/show_bug.cgi?id=38047 Alex Crichton 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 38107] New: Aggressive optimization when computing GEP result.
https://bugs.llvm.org/show_bug.cgi?id=38107
Bug ID: 38107
Summary: Aggressive optimization when computing GEP result.
Product: clang
Version: 6.0
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: LLVM Codegen
Assignee: unassignedclangb...@nondot.org
Reporter: zahira.ammarguel...@intel.com
CC: llvm-bugs@lists.llvm.org
Let's look at this test case:
#include
char * __strrchr_c_a (const char *__s, int __c) {
register unsigned long int __d0, __d1;
register char *__res;
__c = __c << 8;
__asm__
("cmpb %h2,%b2\n\t"
"cmove %1,%0\n\t"
: "=d" (__res), "=&S" (__d0), "=&a" (__d1)
: "0" (1), "1" (__s), "2" (__c));
return __res - 1;
}
int main() {
char * res = __strrchr_c_a("Hello, world!", 'S');
(res) ? printf("failed\n") : printf("passed\n");
}
bash-4.2$ gcc -O0 t1.c
bash-4.2$ ./a.out
passed
bash-4.2$ gcc -O2 t1.c
bash-4.2$ ./a.out
passed
bash-4.2$
Clang over optimizes.
bash-4.2$ clang -O0 t1.c
bash-4.2$ ./a.out
passed
bash-4.2$ clang -O2 t1.c
bash-4.2$ ./a.out
failed
bash-4.2$
ValueTracking is too aggressive optimizing away the argument to the tail call.
--
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 38108] New: Wrong optimizations and missed optimizations involving pointers to subobjects
https://bugs.llvm.org/show_bug.cgi?id=38108
Bug ID: 38108
Summary: Wrong optimizations and missed optimizations involving
pointers to subobjects
Product: clang
Version: 6.0
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: LLVM Codegen
Assignee: unassignedclangb...@nondot.org
Reporter: c...@trust-in-soft.com
CC: llvm-bugs@lists.llvm.org
Please consider the functions below and the code generated by Clang 6.0.0 and
trunk according to Matt Godbolt's Compiler Explorer
(https://godbolt.org/g/Z4auAE ):
// C code
#include
#include
struct s {
int a;
char t[8];
int b;
} s;
int r1, r2, r3, r4;
void f(char *);
void std_fun(int x, int z) {
char *p = s.t;
r1 = s.a;
r2 = s.b;
memset(p+x, 0, z);
r3 = s.a;
r4 = s.b;
}
void std_fun_twist(int x, int z) {
char *p = (char*)&s + offsetof(struct s, t);
r1 = s.a;
r2 = s.b;
memset(p+x, 0, z);
r3 = s.a;
r4 = s.b;
}
void custom_fun(void) {
struct s s;
char *p = s.t;
r1 = s.a;
r2 = s.b;
f(p);
r3 = s.a;
r4 = s.b;
}
void signed_ptr_offset(int x) {
char *p = s.t;
r1 = s.a;
r2 = s.b;
p[x]=1;
r3 = s.a;
r4 = s.b;
}
void signed_ptr_offset_twist(int x) {
char *p = (char*)&s + offsetof(struct s, t);
r1 = s.a;
r2 = s.b;
p[x]=1;
r3 = s.a;
r4 = s.b;
}
void array(int x) {
r1 = s.a;
r2 = s.b;
s.t[x]=1;
r3 = s.a;
r4 = s.b;
}
___
Generated Assembly (Clang 6.0.0):
std_fun:# @std_fun
pushq %rbx
movls(%rip), %ebx
movl%ebx, r1(%rip)
movls+12(%rip), %eax
movl%eax, r2(%rip)
movslq %edi, %rax
leaqs+4(%rax), %rdi
movslq %esi, %rdx
xorl%esi, %esi
callq memset
movl%ebx, r3(%rip)
movls+12(%rip), %eax
movl%eax, r4(%rip)
popq%rbx
retq
std_fun_twist: # @std_fun_twist
pushq %rbx
movls(%rip), %ebx
movl%ebx, r1(%rip)
movls+12(%rip), %eax
movl%eax, r2(%rip)
movslq %edi, %rax
leaqs+4(%rax), %rdi
movslq %esi, %rdx
xorl%esi, %esi
callq memset
movl%ebx, r3(%rip)
movls+12(%rip), %eax
movl%eax, r4(%rip)
popq%rbx
retq
custom_fun: # @custom_fun
subq$24, %rsp
leaq12(%rsp), %rdi
callq f
movl8(%rsp), %eax
movl20(%rsp), %ecx
movl%eax, r3(%rip)
movl%ecx, r4(%rip)
addq$24, %rsp
retq
signed_ptr_offset: # @signed_ptr_offset
movls(%rip), %eax
movl%eax, r1(%rip)
movls+12(%rip), %ecx
movslq %edi, %rdx
movb$1, s+4(%rdx)
movl%ecx, r2(%rip)
movl%eax, r3(%rip)
movls+12(%rip), %eax
movl%eax, r4(%rip)
retq
signed_ptr_offset_twist:# @signed_ptr_offset_twist
movls(%rip), %eax
movl%eax, r1(%rip)
movls+12(%rip), %ecx
movslq %edi, %rdx
movb$1, s+4(%rdx)
movl%ecx, r2(%rip)
movl%eax, r3(%rip)
movls+12(%rip), %eax
movl%eax, r4(%rip)
retq
array: # @array
movls(%rip), %eax
movl%eax, r1(%rip)
movls+12(%rip), %ecx
movslq %edi, %rdx
movb$1, s+4(%rdx)
movl%ecx, r2(%rip)
movl%eax, r3(%rip)
movls+12(%rip), %eax
movl%eax, r4(%rip)
retq
___
The point of interest for each function is whether Clang generates code to
reload the value of the struct members a and b after the struct has been
accessed, the access being made from a pointer initially pointing to member t.
The values are to be stored in variables r3 and r4. A sequence such as the
following indicates that Clang considers that the value of the member a must be
the same after the call to memset as it was before:
callq memset
movl%ebx, r3(%rip)
Note that the variable p is always a pointer to char, and s is always a
variable, which means that the functions cannot be said to be incorrect because
of “strict aliasing” violations. Incidentally, adding "-fno-strict-aliasing" to
the commandline does not change the generated code.
1/ WRONG OPTIMIZATION
In the functions std_fun_twist and signed_ptr_offset_twist, r3 is assigned
without reloading the member a. I do not think that there exist any possible
justification for this optimization in a real compiler used for, for instance,
OS code. Some programmers will use char pointers to access the representation
of structs. The str
[llvm-bugs] [Bug 38009] Module Verifier bug makes llc/opt refuses to accept bitcode file generated by clang-6.0
https://bugs.llvm.org/show_bug.cgi?id=38009 Steven Wu changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from Steven Wu --- should be fixed by r336560 -- 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 38034] 3 libfuzzer tests hanging on aarch64 (buildbot failing)
https://bugs.llvm.org/show_bug.cgi?id=38034 Matt Morehouse changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #2 from Matt Morehouse --- The tests were disabled for AArch64, and bot is green again. -- 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 38106] Undefined reference error when "static const" variable is initialized in line (but works out of line)
https://bugs.llvm.org/show_bug.cgi?id=38106
David Blaikie changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|--- |INVALID
CC||dblai...@gmail.com
--- Comment #1 from David Blaikie ---
This code (with the static member definition commented out) exhibits undefined
behavior due to an ODR use of 'foo' without a definition of 'foo'.
The "const static long long foo = 5;" (even with the "= 5") is only a
declaration of foo and must have an out of line definition (the initial value
("= 5") can remain in the declaration if you want/for various reasons).
If you want to keep the initial value inline at the declaration, then omit the
initial value in the definition (write it as "const long long Foo::foo;").
--
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 37944] ItaniumDemangle - struct Db alignment warnings
https://bugs.llvm.org/show_bug.cgi?id=37944 Serge Pavlov changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #5 from Serge Pavlov --- This issue was fixed in revision 336311 (and 336312 in libcxxabi). -- 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 38109] New: Explicit specialization after instantiation error
https://bugs.llvm.org/show_bug.cgi?id=38109
Bug ID: 38109
Summary: Explicit specialization after instantiation error
Product: clang
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: C++
Assignee: unassignedclangb...@nondot.org
Reporter: steve...@gmail.com
CC: dgre...@apple.com, llvm-bugs@lists.llvm.org
Clang does not accept code which CL.exe accepts. The example works if I remove
the dllexport.
C:\dev\src\playground\cpp>C:\dev\src\llvm\build\releaseprefix\msbuild-bin\cl.exe
explicit_instantiation.cpp
explicit_instantiation.cpp
explicit_instantiation.cpp(12,21): error: explicit specialization of 's_foo'
after instantiation
template<> B* A::s_foo = nullptr;
^
explicit_instantiation.cpp(5,15): note: implicit instantiation first required
here
static T* s_foo;
^
1 error generated.
C:\dev\src\playground\cpp>cl.exe explicit_instantiation.cpp
Microsoft (R) C/C++ Optimizing Compiler Version 19.14.26430 for x64
Copyright (C) Microsoft Corporation. All rights reserved.
explicit_instantiation.cpp
Microsoft (R) Incremental Linker Version 14.14.26430.0
Copyright (C) Microsoft Corporation. All rights reserved.
/out:explicit_instantiation.exe
explicit_instantiation.obj
Creating library explicit_instantiation.lib and object
explicit_instantiation.exp
C:\dev\src\playground\cpp>type explicit_instantiation.cpp
template
class A
{
static T* s_foo;
};
class __declspec(dllexport) B : public A
{
};
template<> B* A::s_foo = nullptr;
int main()
{
return 0;
}
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 12218] llvm hangs in JumpThreading::runOnFunction
https://bugs.llvm.org/show_bug.cgi?id=12218 Brian Rzycki changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED CC||brzy...@gmail.com --- Comment #2 from Brian Rzycki --- I just tested clang_hang.c with LLVM tip and cannot reproduce the problem. brzycki@cc01 ~ $ /work/brzycki/tip/install/bin/clang --version clang version 7.0.0 Target: x86_64-unknown-linux-gnu Thread model: posix InstalledDir: /work/brzycki/tip/install/bin brzycki@cc01 ~ $ time /work/brzycki/tip/install/bin/clang clang_hang.c -w -O2 -c real0m3.302s user0m3.216s sys 0m0.076s brzycki@cc01 ~ $ time /work/brzycki/tip/install/bin/clang clang_hang.c -w -O3 -c real0m3.485s user0m3.420s sys 0m0.056s The commit I tested is from https://github.com/llvm-project/llvm-project-20170507.git using SHA: commit 17e2331a3dc55d28e2986556a1b25b080c3861a5 (HEAD -> master, origin/master, origin/HEAD) Author: Craig Topper Date: Mon Jul 9 18:23:55 2018 + [SelectionDAG] Add VT consistency checks to the creation of ISD::FMA. This is similar to what is done for binops. I don't know if this would have helped us catch the bug fixed in r336566 earlier or not, but I figured it couldn't hurt. -- 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 38110] New: Loop vectorizer assertion failure in truncateToMinimalBitwidths
https://bugs.llvm.org/show_bug.cgi?id=38110
Bug ID: 38110
Summary: Loop vectorizer assertion failure in
truncateToMinimalBitwidths
Product: libraries
Version: trunk
Hardware: Other
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Loop Optimizer
Assignee: unassignedb...@nondot.org
Reporter: uweig...@de.ibm.com
CC: llvm-bugs@lists.llvm.org
Created attachment 20543
--> https://bugs.llvm.org/attachment.cgi?id=20543&action=edit
Reduced test case
Running the attached test case through
opt -loop-vectorize -mcpu=z13
on the s390x-ibm-linux target results in an assertion failure:
Unhandled instruction type!
UNREACHABLE executed at
/home/uweigand/llvm/llvm-head/lib/Transforms/Vectorize/LoopVectorize.cpp:3292!
The unhandled instruction at this point seems to be a phi node.
This is a reduced test case from a real-world application. The corresponding
reduced C source code test case (same assertion failure) is:
void
test (unsigned int width, unsigned char *row,
unsigned short src, unsigned short *dst)
{
unsigned char *sp;
unsigned int i;
sp = row;
for (i = 0; i < width; i++, sp++)
{
if (*sp == src)
*sp = (unsigned char) *dst;
}
}
--
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 38111] New: function attribute "diagnose_if" doesn't show error if the argument uses statements and declarations in expressions
https://bugs.llvm.org/show_bug.cgi?id=38111
Bug ID: 38111
Summary: function attribute "diagnose_if" doesn't show error if
the argument uses statements and declarations in
expressions
Product: clang
Version: 6.0
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: Frontend
Assignee: unassignedclangb...@nondot.org
Reporter: nar...@airemix.jp
CC: llvm-bugs@lists.llvm.org
If the target function of "diagnose_if" attribute receives an argument which
uses GCC extension, statements and declarations in expressions, clang doesn't
show error.
If there're only statements, it works.
But if there're also declarations, it doesn't show any errors.
```
% cat b.c
int scan_args(char *fmt)
__attribute__((diagnose_if(fmt[0]!=2,"invalid format string","error")))
{
return 0;
}
int
main(int argc, char **argv) {
return scan_args(__extension__({"20";}));
}
% clang b.c
b.c:10:44: error: invalid format string
return scan_args(__extension__({"20";}));
^
b.c:2:20: note: from 'diagnose_if' attribute on 'scan_args':
__attribute__((diagnose_if(fmt[0]!=2,"invalid format string","error")))
^ ~
1 error generated.
```
```
% cat b.c
int scan_args(char *fmt)
__attribute__((diagnose_if(fmt[0]!=2,"invalid format string","error")))
{
return 0;
}
int
main(int argc, char **argv) {
return scan_args(__extension__({char *s="20";s;}));
}
% clang b.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 38112] New: -Wuninitialized ignored if type is "const" pointer
https://bugs.llvm.org/show_bug.cgi?id=38112
Bug ID: 38112
Summary: -Wuninitialized ignored if type is "const" pointer
Product: clang
Version: trunk
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P
Component: Frontend
Assignee: unassignedclangb...@nondot.org
Reporter: picke...@synopsys.com
CC: llvm-bugs@lists.llvm.org
Compile the following with '-Wuninitialized' and clang fails to diagnose the
uninitialized variable.
--- test.c ---
extern void foo(const char *p);
int main(){
char *p;
foo(p); // Should produce warning but doesn't
}
---
If "const" is removed from the parameter to "foo", the warning is emitted as
expected.
--
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 38113] New: aliasing pointer analsyis broken with 32-bit pointers
https://bugs.llvm.org/show_bug.cgi?id=38113 Bug ID: 38113 Summary: aliasing pointer analsyis broken with 32-bit pointers Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: Backend: AMDGPU Assignee: unassignedb...@nondot.org Reporter: airl...@gmail.com CC: llvm-bugs@lists.llvm.org radv has just started adding support for KHR_variable_pointers vulkan extension, however some tests are crashing in llvm with a "Pointer address space out of range" error. This is due to a select on 2 pointers in the 32-bit constant address space (6). However the code in lib/Target/AMDGPU/AMDGPUAliasAnalysis.cpp checks up to MAX_COMMON_ADDRESS which is 5 and throws the error for amdgcn. However this looks like the code hasn't really be updated to handle 32-bit address space pointers. https://reviews.llvm.org/D31520 was the change that added 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 38114] New: "DISubprogram attached to more than one function" with -argpromotion -instcombine after r336419
https://bugs.llvm.org/show_bug.cgi?id=38114
Bug ID: 38114
Summary: "DISubprogram attached to more than one function" with
-argpromotion -instcombine after r336419
Product: new-bugs
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: mikael.hol...@ericsson.com
CC: llvm-bugs@lists.llvm.org
Created attachment 20545
--> https://bugs.llvm.org/attachment.cgi?id=20545&action=edit
reproducer
With
opt -S -o - foo.ll -argpromotion -instcombine
I get
DISubprogram attached to more than one function
!1 = distinct !DISubprogram(name: "func_27", scope: !2, file: !2, line:
251, type: !3, isLocal: true, isDefinition: true, scopeLine: 252,
isOptimized: false, unit: !5)
i64 ()* @func_27
LLVM ERROR: Broken module found, compilation aborted!
If I add -print-before-all -print-after-all -print-module-scope I get
this as the last printouts:
*** IR Dump Before Module Verifier *** (function: func_27)
; ModuleID = 'foo.ll'
source_filename = "foo.ll"
@g_280 = external global i32
define i32 @func_1() {
bb1:
%l_55.115 = alloca i32*, align 8
%_tmp555 = load i32*, i32** %l_55.115, align 8
%0 = call i64 @func_27()
ret i32 undef
}
define internal i64 @func_27() !dbg !1 {
store i32* @g_280, i32** undef, align 8
ret i64 undef
}
define i16 @func_28() {
%_tmp5791 = call i32 @func_1()
ret i16 undef
}
!llvm.dbg.cu = !{}
!llvm.module.flags = !{!0}
!0 = !{i32 2, !"Debug Info Version", i32 3}
!1 = distinct !DISubprogram(name: "func_27", scope: !2, file: !2, line:
251, type: !3, isLocal: true, isDefinition: true, scopeLine: 252,
isOptimized: false, unit: !5)
!2 = !DIFile(filename: "foo.c", directory: "/bar")
!3 = !DISubroutineType(types: !4)
!4 = !{}
!5 = distinct !DICompileUnit(language: DW_LANG_C, file: !2, producer:
"My compiler", isOptimized: false, runtimeVersion: 0, emissionKind:
LineTablesOnly)
DISubprogram attached to more than one function
!1 = distinct !DISubprogram(name: "func_27", scope: !2, file: !2, line:
251, type: !3, isLocal: true, isDefinition: true, scopeLine: 252,
isOptimized: false, unit: !5)
i64 ()* @func_27
*** IR Dump After Module Verifier *** (function: func_27)
; ModuleID = 'foo.ll'
source_filename = "foo.ll"
@g_280 = external global i32
define i32 @func_1() {
bb1:
%l_55.115 = alloca i32*, align 8
%_tmp555 = load i32*, i32** %l_55.115, align 8
%0 = call i64 @func_27()
ret i32 undef
}
define internal i64 @func_27() !dbg !1 {
store i32* @g_280, i32** undef, align 8
ret i64 undef
}
define i16 @func_28() {
%_tmp5791 = call i32 @func_1()
ret i16 undef
}
!llvm.dbg.cu = !{}
!llvm.module.flags = !{!0}
!0 = !{i32 2, !"Debug Info Version", i32 3}
!1 = distinct !DISubprogram(name: "func_27", scope: !2, file: !2, line:
251, type: !3, isLocal: true, isDefinition: true, scopeLine: 252,
isOptimized: false, unit: !5)
!2 = !DIFile(filename: "foo.c", directory: "/bar")
!3 = !DISubroutineType(types: !4)
!4 = !{}
!5 = distinct !DICompileUnit(language: DW_LANG_C, file: !2, producer:
"My compiler", isOptimized: false, runtimeVersion: 0, emissionKind:
LineTablesOnly)
LLVM ERROR: Broken module found, compilation aborted!
As far as I can see in the printouts !1 is only used on func_27 and
still it complains.
func27 was changed during argpromotion:
ARG PROMOTION: Promoting to:
declare !dbg !0 internal i64 @func_27(i32*)
From:
define internal i64 @func_27(i32* %p1, i32* %p2) {
store i32* %p1, i32** undef
store i32* @g_280, i32** undef
ret i64 undef
}
so I'm not sure if the old func_27 is still hanging around in some way?
This started happening after r336419:
CallGraphSCCPass: iterate over all functions.
Previously we only iterated over functions reachable from the set of
external functions in the module. But since some of the passes under
this (notably the always-inliner and coroutine lowerer) are required for
correctness, they need to run over everything.
This just adds an extra layer of iteration over the CallGraph to keep
track of which functions we've already visited and get the next batch of
SCCs.
Should fix PR38029.
I've no idea if r336419 is really to blame here though or if it's just exposing
an already existing 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
