[llvm-bugs] [Bug 11966] possible union bug
https://bugs.llvm.org/show_bug.cgi?id=11966 Alexander Cherepanov changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #8 from Alexander Cherepanov --- Sure, reopening it now, sorry for the noise. -- 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 35033] New: clang-format reformats already formatted code (comment before preprocessor directive)
https://bugs.llvm.org/show_bug.cgi?id=35033
Bug ID: 35033
Summary: clang-format reformats already formatted code (comment
before preprocessor directive)
Product: clang
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: normal
Priority: P
Component: Formatter
Assignee: unassignedclangb...@nondot.org
Reporter: curde...@gmail.com
CC: djas...@google.com, kli...@google.com,
llvm-bugs@lists.llvm.org
Tested on clang-format trunk r316311 from 2017-10-23.
The following code:
```
{
// clang-format off
#define M 5
}
```
gets formmatted to:
```
{
// clang-format off
#define M 5
}
```
Reformatting again leads to the original code again... and it cycles.
Apparently, it has to do with comments before preprocessor directives and seems
to be related to bug #31911 (https://bugs.llvm.org/show_bug.cgi?id=31911).
--
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 35034] New: An R-value to L-value reference binding in a templated constructor
https://bugs.llvm.org/show_bug.cgi?id=35034
Bug ID: 35034
Summary: An R-value to L-value reference binding in a templated
constructor
Product: clang
Version: unspecified
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P
Component: C++11
Assignee: unassignedclangb...@nondot.org
Reporter: poltavsky.alexa...@gmail.com
CC: dgre...@apple.com, llvm-bugs@lists.llvm.org
A really nasty bug:
template
struct data {
template
data( U && value ) : _value{ T( std::forward( value ) ) } {}
T _value;
};
data< int& > d{ 10 }; //okay on Clang, not okay on GCC & MSVC
https://godbolt.org/g/TrgJCp
The initial intent for the code was to avoid strict init rules for uniform
initialization in a converting constructor.
--
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 35035] New: Clang-format makes inconsistent line endings in multiline comments on Windows
https://bugs.llvm.org/show_bug.cgi?id=35035 Bug ID: 35035 Summary: Clang-format makes inconsistent line endings in multiline comments on Windows Product: clang Version: 5.0 Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: Formatter Assignee: unassignedclangb...@nondot.org Reporter: mikhail.matro...@gmail.com CC: djas...@google.com, kli...@google.com, llvm-bugs@lists.llvm.org Created attachment 19327 --> https://bugs.llvm.org/attachment.cgi?id=19327&action=edit Source file before formatting You need a file with multiline comment containing a line with spaces only: /* */ Note how line between /* and */ contains two spaces. Save this with Windows line endings (CR+LF). Format with "Mozilla" style: "c:\Program Files (x86)\LLVM\bin\clang-format.exe" --style=Mozilla -i file.cpp Check the file. It now contains additional blank line separated with CR symbol only. Other line endings are still CR+LF. -- 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 35037] New: lldb provides imprecise informations to reproduce problems
https://bugs.llvm.org/show_bug.cgi?id=35037
Bug ID: 35037
Summary: lldb provides imprecise informations to reproduce
problems
Product: lldb
Version: unspecified
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: All Bugs
Assignee: lldb-...@lists.llvm.org
Reporter: dav...@freebsd.org
CC: apra...@apple.com, lha...@gmail.com,
llvm-bugs@lists.llvm.org, r...@google.com,
ztur...@google.com
I haven't (yet) looked into how hard this is to fix, but the current state is
definitely not ideal.
A failure will look like:
AssertionError: False is not True : Command 'expression auto $add = [](int a,
int b) { return a + b; }' returns successfully
Config=x86_64-/usr/bin/ccache
Session info generated @ Mon Oct 23 09:28:31 2017
To rerun this test, issue the following command from the 'test' directory:
./dotest.py -A x86_64 -C /usr/bin/ccache -v -t -N dsym lang/cpp/lambdas
If you copy-paste the command you get an error, because of:
dotest.py: error: unrecognized arguments: -N
Removing the `-N` bit from the invocation is not really enough, because by
default dotest.py picks the first `lldb` in $PATH, which is not necessarily the
correct one (it's actually, almost never the correct one in development).
$ python dotest.py -A x86_64 -C /usr/bin/ccache -v -t lang/cpp/lambdas
['dotest.py', '-A', 'x86_64', '-C', '/usr/bin/ccache', '-v', '-t',
'lang/cpp/lambdas']
LLDB library dir: /usr/bin
LLDB import library dir: /usr/bin
Traceback (most recent call last):
File "", line 1, in
ImportError: No module named lldb.embedded_interpreter
lldb version 3.8.0 ( revision )
Last but not least, I'm currrently bulding with an in-tree clang, so I'm
expecting tests to be run with that very clang. Either they're not (in which
case this might be taken in consideration for fix) or the cmdline to reproduce
lacks some relevant informations (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 35038] New: GVN drops nonnull metadata
https://bugs.llvm.org/show_bug.cgi?id=35038
Bug ID: 35038
Summary: GVN drops nonnull metadata
Product: libraries
Version: 5.0
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Scalar Optimizations
Assignee: unassignedb...@nondot.org
Reporter: yyc1...@gmail.com
CC: llvm-bugs@lists.llvm.org
Very similar to https://bugs.llvm.org/show_bug.cgi?id=30597 and
https://bugs.llvm.org/show_bug.cgi?id=31142 but for GVN this time.
Code to reproduce:
```
target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-unknown-linux-gnu"
define i8* @f(i8** %v0, i8** %v1) {
top:
%v2 = load i8*, i8** %v0, !nonnull !0
store i8* %v2, i8** %v1
%v3 = load i8*, i8** %v1
ret i8* %v3
}
!0 = !{}
```
Running GVN produces
```
target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-unknown-linux-gnu"
define i8* @f(i8** %v0, i8** %v1) {
top:
%v2 = load i8*, i8** %v0
store i8* %v2, i8** %v1
ret i8* %v2
}
```
while running instcombine produces
```
target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-unknown-linux-gnu"
define i8* @f(i8** %v0, i8** %v1) {
top:
%0 = bitcast i8** %v0 to i64*
%v21 = load i64, i64* %0, align 8, !range !0
%1 = bitcast i8** %v1 to i64*
store i64 %v21, i64* %1, align 8
%v3.cast = inttoptr i64 %v21 to i8*
ret i8* %v3.cast
}
!0 = !{i64 1, i64 0}
```
The GVN version has deleted the `!nonnull` metadata on the load.
--
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 34996] Possible incorrect message in file "libcxx/include/list" line 484
https://bugs.llvm.org/show_bug.cgi?id=34996 Marshall Clow (home) changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED Assignee|unassignedclangbugs@nondot. |mclow.li...@gmail.com |org | --- Comment #1 from Marshall Clow (home) --- fixed in revision 316343. Thanks for the catch! -- 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 35034] An R-value to L-value reference binding in a templated constructor
https://bugs.llvm.org/show_bug.cgi?id=35034 Alexandr Poltavsky 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] Issue 3219 in oss-fuzz: llvm: Heap-buffer-overflow in llvm::StringMapImpl::LookupBucketFor
Comment #6 on issue 3219 by v...@apple.com: llvm: Heap-buffer-overflow in llvm::StringMapImpl::LookupBucketFor https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=3219#c6 Fixed in r316357. The issue was in llvm 5.0. The root cause was a bug in Wasm object file parsing. -- 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 35040] New: lldb tests are failing when an in-tree clang is specified (missing ar/objcopy)
https://bugs.llvm.org/show_bug.cgi?id=35040 Bug ID: 35040 Summary: lldb tests are failing when an in-tree clang is specified (missing ar/objcopy) Product: lldb Version: unspecified Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: All Bugs Assignee: lldb-...@lists.llvm.org Reporter: dav...@freebsd.org CC: apra...@apple.com, dblai...@gmail.com, lha...@gmail.com, llvm-bugs@lists.llvm.org, r...@google.com, ztur...@google.com Example: == ERROR: test_dwarf (TestBSDArchives.BSDArchivesTestCase) Break inside a() and b() defined within libfoo.a. -- Error when building test subject. Build Command: make MAKE_DSYM=NO ARCH=x86_64 CC="/home/davide/work/build-lldb/bin/clang-5.0" Build Command Output: make: /home/davide/work/build-lldb/bin/ar: Command not found make: *** [libfoo.a(a.o)] Error 127 Test Directory: /home/davide/work/llvm-lldb/tools/lldb/packages/Python/lldbsuite/test/functionalities/archives == ERROR: test_dwo (TestBSDArchives.BSDArchivesTestCase) Break inside a() and b() defined within libfoo.a. -- Error when building test subject. Build Command: make MAKE_DSYM=NO MAKE_DWO=YES ARCH=x86_64 CC="/home/davide/work/build-lldb/bin/clang-5.0" Build Command Output: make: /home/davide/work/build-lldb/bin/ar: Command not found make: *** [libfoo.a(a.o)] Error 127 There's a bunch of these failing, and it's a little weird. They're failing because they're assuming that `ar` and `objcopy` (and maybe other bits of binutils` live in the llvm `bin/` directory, rather than `/usr/lib` (or `/usr/local/lib`, or anywhere else in $PATH). I'm not sure if this is intended, but, that said, I don't think it's great. We might: a) Add options to `dotest.py` to override the binaries, or, more generally the binutils directory in which the tests should look b) Fallback to $PATH in case there's no `ar` or `objcopy`. c) Create symlinks from `llvm-ar` and `llvm-objcopy` to `ar` and `objcopy` in the `bin` directory (I really don't like this one) d) If the compiler used is clang (dotest already has logic for that, prepend the `llvm-` prefix to the executables) e) you name it -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 35041] New: Type of regular expression in clang-format is not documented
https://bugs.llvm.org/show_bug.cgi?id=35041 Bug ID: 35041 Summary: Type of regular expression in clang-format is not documented Product: clang Version: trunk Hardware: All OS: All Status: NEW Severity: enhancement Priority: P Component: Documentation Assignee: unassignedclangb...@nondot.org Reporter: wim.lefl...@gmail.com CC: llvm-bugs@lists.llvm.org clang-format uses regular expressions to give priorities when sorting includes. It uses 'POSIX extended regular expressions' for this. But this is missing from the documentation. I found out because '\w' to match word characters doesn't work. You have to use [[:alnum:]]. The documentation could link to https://man.openbsd.org/re_format.7 -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 35042] New: clang disagrees with {gcc, icc, msvc} about ambiguous name
https://bugs.llvm.org/show_bug.cgi?id=35042
Bug ID: 35042
Summary: clang disagrees with {gcc,icc,msvc} about ambiguous
name
Product: clang
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: C++
Assignee: unassignedclangb...@nondot.org
Reporter: chisophu...@gmail.com
CC: dgre...@apple.com, llvm-bugs@lists.llvm.org
GCC and clang seem to disagree about whether the reference to `isa` in this
snippet is valid:
namespace myarch {
namespace isa {
}
}
using namespace myarch;
namespace llvm {
template
void isa() {}
}
using namespace llvm;
void f() {
isa();
}
Clang accepts this code. GCC says `error: reference to 'isa' is ambiguous`.
https://godbolt.org/g/ix2jsS
Also, ICC and MSVC seem to believe that it is ambiguous as well.
--
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 3679 in oss-fuzz: llvm/llvm-isel-fuzzer--aarch64-O2: Direct-leak in llvm::BitcodeReaderValueList::getValueFwdRef
Updates: Labels: ClusterFuzz-Top-Crash Comment #2 on issue 3679 by monor...@clusterfuzz-external.iam.gserviceaccount.com: llvm/llvm-isel-fuzzer--aarch64-O2: Direct-leak in llvm::BitcodeReaderValueList::getValueFwdRef https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=3679#c2 Testcase 5792447943671808 is a top crash on ClusterFuzz for linux platform. Please prioritize fixing this crash. If this is incorrect, please file a bug on https://github.com/google/oss-fuzz/issues/new -- 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 35043] New: lldb incorrectly reports multiple symbols when evaluating expressions (on Linux)
https://bugs.llvm.org/show_bug.cgi?id=35043
Bug ID: 35043
Summary: lldb incorrectly reports multiple symbols when
evaluating expressions (on Linux)
Product: lldb
Version: unspecified
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: All Bugs
Assignee: lldb-...@lists.llvm.org
Reporter: dav...@freebsd.org
CC: llvm-bugs@lists.llvm.org
I think this is a bug in the expression parser/symtab handling, but I can't say
for sure.
given the test in lambdas/main.cpp, after we set a breakpoint on the printf()
and we try to evaluate the lambda, we get:
(lldb) target create "made"
Current executable set to 'made' (x86_64).
(lldb) b main.cpp:14
Breakpoint 1: where = made`main + 32 at main.cpp:14, address =
0x004005f0
(lldb) r
Process 32489 launched:
'/home/davide/work/llvm-lldb/tools/lldb/packages/Python/lldbsuite/test/lang/cpp/lambdas/made'
(x86_64)
Process 32489 stopped
* thread #1, name = 'made', stop reason = breakpoint 1.1
frame #0: 0x004005f0 made`main(argc=1, argv=0x7fffe128) at
main.cpp:14
11
12 int main (int argc, char const *argv[])
13 {
-> 14 printf("Stop here\n"); //% self.runCmd("expression auto $add =
[](int a, int b) { return a + b; }")
15 //% self.expect("expression $add(2,3)",
substrs = ['= 5'])
16 return 0;
17 }
(lldb) expression auto $add = [](int a, int b) { return a + b; }
error: Multiple internal symbols found for 'a'
id = {0x03cf}, range = [0x777ec290-0x777ec298), name="a"
id = {0x051b}, range = [0x777ec290-0x777ec298), name="a"
id = {0x00fe}, range = [0x777ec290-0x777ec298), name="a"
error: Multiple internal symbols found for 'b'
id = {0x051a}, range = [0x777cfe70-0x777cfe78), name="b"
id = {0x03ce}, range = [0x777cfe70-0x777cfe78), name="b"
id = {0x00fd}, range = [0x777cfe70-0x777cfe78), name="b"
I don't think that's quite right, as `b` is not really redefined, it's just a
temporary binding that we use for the lambda argument.
This requires a little more knowledge of the internals than I currently have,
so hints on where to look would be appreciated.
I can attach the ELF object, if it's helpful
--
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 35044] New: [codeview] Dump (and maybe emit) debug info for C++17 structured bindings
https://bugs.llvm.org/show_bug.cgi?id=35044
Bug ID: 35044
Summary: [codeview] Dump (and maybe emit) debug info for C++17
structured bindings
Product: libraries
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: DebugInfo
Assignee: unassignedb...@nondot.org
Reporter: r...@google.com
CC: llvm-bugs@lists.llvm.org
MSVC emits a symbol record with unknown kind 0x1171 for this code:
struct Foo {
int a, b;
};
int f() {
Foo f = {1, 2};
auto & [x, y] = f;
return x + y;
}
We should:
1. Add dumping support for 0x1171
2. Figure out what the record achieves that can't be done with two local
variable records
3. Implement it if necessary
--
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 3737 in oss-fuzz: llvm/clang-fuzzer: Abrt in llvm::llvm_unreachable_internal
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevlieg...@apple.com, llvm-b...@lists.llvm.org, v...@apple.com Labels: ClusterFuzz Stability-Memory-AddressSanitizer Reproducible Engine-libfuzzer Proj-llvm Reported-2017-10-23 New issue 3737 by monor...@clusterfuzz-external.iam.gserviceaccount.com: llvm/clang-fuzzer: Abrt in llvm::llvm_unreachable_internal https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=3737 Detailed report: https://oss-fuzz.com/testcase?key=5416231357120512 Project: llvm Fuzzer: libFuzzer_llvm_clang-fuzzer Fuzz target binary: clang-fuzzer Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: Abrt Crash Address: 0x0001 Crash State: llvm::llvm_unreachable_internal clang::Sema::ActOnComment ActionCommentHandler::HandleComment Sanitizer: address (ASAN) Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5416231357120512 Issue filed automatically. See https://github.com/google/oss-fuzz/blob/master/docs/reproducing.md for more information. When you fix this bug, please * mention the fix revision(s). * state whether the bug was a short-lived regression or an old bug in any stable releases. * add any other useful information. This information can help downstream consumers. If you have questions for the OSS-Fuzz team, please file an issue at https://github.com/google/oss-fuzz/issues. -- 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 3688 in oss-fuzz: llvm/llvm-special-case-list-fuzzer: ASSERT: !Key.empty()
Comment #4 on issue 3688 by hiimmitc...@gmail.com: llvm/llvm-special-case-list-fuzzer: ASSERT: !Key.empty() https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=3688#c4 Patch for this issue provided in https://reviews.llvm.org/D39212. -- 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 35046] New: gcc/clang calling convension mismatch
https://bugs.llvm.org/show_bug.cgi?id=35046
Bug ID: 35046
Summary: gcc/clang calling convension mismatch
Product: clang
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: vanya...@gmail.com
CC: llvm-bugs@lists.llvm.org
Recently I have discovered that empty arguments are passed differently by gcc
and by clang.
struct empty
{};
void f(empty, empty, empty);
int main()
{
f(empty{}, empty{}, empty{});
}
GCC pushed 0 to stack for each empty struct while clang does nothing.
main(GCC):
sub rsp, 16
xor eax, eax
push rax
push rax
push rax
call f(empty, empty, empty)
xor eax, eax
add rsp, 40
ret
main(clang):
push rax
call f(empty, empty, empty)
xor eax, eax
pop rcx
ret
I would say that I like the code generated by clang more. As the struct is
empty no value needs to be passed. In a case the callee needs to take the
address of the argument it can allocate the argument in its own frame as the
argument is passed by value.
As the code generated differs I wondered if I can construct an example where
parameters get wrong values because of this. Turned out it wasn't very
difficult.
The following program
struct empty
{};
struct big
{
int a;
int b;
int c;
int d;
int e;
};
void print_7th(empty, empty, empty, empty, empty, empty, big seventh)
{
std::cout << seventh.a
<< ' ' << seventh.b
<< ' ' << seventh.c
<< ' ' << seventh.d
<< ' ' << seventh.e << std::endl;
}
int main()
{
empty e;
print_7th(e, e, e, e, e, e, big{1, 2, 3, 4, 5});
}
prints different output when print_7th and main are compiled with different
compilers:
./gcc-to-gcc
1 2 3 4 5
./clang-to-gcc
5 32767 0 0 635911936
./gcc-to-clang
192 0 -1204279016 32765 1
./clang-to-clang
1 2 3 4 5
Another easy way to see that compilers pass arguments differently is compiling
this code:
int sum(empty, empty, empty, empty, empty, empty, big seventh)
{
return seventh.a + seventh.b + seventh.c + seventh.d + seventh.e;
}
GCC generates:
sum:
mov eax, DWORD PTR [rsp+60]
add eax, DWORD PTR [rsp+56]
add eax, DWORD PTR [rsp+64]
add eax, DWORD PTR [rsp+68]
add eax, DWORD PTR [rsp+72]
ret
while clang generates:
sum:
mov eax, dword ptr [rsp + 12]
add eax, dword ptr [rsp + 8]
add eax, dword ptr [rsp + 16]
add eax, dword ptr [rsp + 20]
add eax, dword ptr [rsp + 24]
ret
I don't know which compiler is right in this case and which conform to SysV ABI
better. I would prefer GCC to adopt clang behavior as it is more efficient.
Because if we have two popular major compilers that both are widely used and
are incompatible with each other and we have to break compatibility of one of
them it's better to choose the better alternative. Also using empty struct as
parameters is common in C++ code, and it's great to make them free.
I have already reported this issue against gcc:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82693 I report this issue here
too, to let clang developers know about the issue too.
--
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 35046] gcc/clang calling convension mismatch
https://bugs.llvm.org/show_bug.cgi?id=35046 Ivan Sorokin changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Ivan Sorokin --- Looks like this issue was already submitted. Closing. *** This bug has been marked as a duplicate of bug 26337 *** -- 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 34222] PDB contains unknown symbol record kind 0x1168
https://bugs.llvm.org/show_bug.cgi?id=34222 Reid Kleckner changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #5 from Reid Kleckner --- LLD should properly link this symbol now after r316398. -- 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 11611] crash evaluating statement on function prototype
https://bugs.llvm.org/show_bug.cgi?id=11611 Alexander Shaposhnikov changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED CC||alexander.v.shaposhnikov@gm ||ail.com --- Comment #1 from Alexander Shaposhnikov --- Resolved in https://reviews.llvm.org/rL316399 -- 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 35047] New: load merging for (data[0]<<0) | (data[1]<<8) | ... endian agnostic load goes berserk with AVX2 variable-shift
https://bugs.llvm.org/show_bug.cgi?id=35047
Bug ID: 35047
Summary: load merging for (data[0]<<0) | (data[1]<<8) | ...
endian agnostic load goes berserk with AVX2
variable-shift
Product: new-bugs
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Keywords: performance
Severity: normal
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: pe...@cordes.ca
CC: llvm-bugs@lists.llvm.org
unsigned load_le32(unsigned char *data) {
unsigned le32 = (data[0]<<0) | (data[1]<<8) | (data[2]<<16) |
(data[3]<<24);
return le32;
}
// https://godbolt.org/g/X8i1pr
clang 6.0.0 (trunk 316311) -O3 -march=haswell -mno-avx
movl(%rdi), %eax
retq
-O3 -march=haswell (with AVX2)
.LCPI0_0:
.quad 16 # 0x10
.quad 24 # 0x18
load_le32: # @load_le32
movzbl (%rdi), %eax
movzbl 1(%rdi), %ecx
shll$8, %ecx
vpmovzxbq 2(%rdi), %xmm0 # xmm0 =
mem[0],zero,zero,zero,zero,zero,zero,zero,mem[1],zero,zero,zero,zero,zero,zero,zero
orl %eax, %ecx
vpsllvq .LCPI0_0(%rip), %xmm0, %xmm0
vmovd %xmm0, %edx
vpextrd $2, %xmm0, %eax
orl %edx, %eax
orl %ecx, %eax
retq
So if vpsllvq is available, clang uses it and doesn't notice that it could have
coalesced the loads into one. -fno-vectorize doesn't block this. (And if the
shift counts didn't line up this way, it's quite poorly vectorized. VPMOVZXBD
would have worked, then do 4 shifts, and then a horizontal reduction with OR,
using the same pattern as a horizontal sum. e.g. vpunpckhqdq / vpor / vmovq /
rorx $32, %rax, %rdx / or %edx, %eax)
(And BTW, for Haswell and later, movb 1(%rdi), %al merges into RAX without
stalling at all. It's a single micro-fused load+merge uop, so it's better than
a separate movzx load + OR instruction. See
https://stackoverflow.com/questions/45660139/how-exactly-do-partial-registers-on-haswell-skylake-perform-writing-al-seems-to)
clang 4.0.1 doesn't merge the loads.
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 35048] New: [coroutines] segmentation fault running pass Module Verifier
https://bugs.llvm.org/show_bug.cgi?id=35048 Bug ID: 35048 Summary: [coroutines] segmentation fault running pass Module Verifier Product: clang Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: C++ Assignee: unassignedclangb...@nondot.org Reporter: lewissba...@gmail.com CC: dgre...@apple.com, llvm-bugs@lists.llvm.org See godbolt code: https://godbolt.org/g/6JYFvu Instruction does not dominate all uses! = getelementptr inbounds, !dbg <0x7be4770> %9 = atomicrmw sub %"struct.task::promise_type"* (%"struct.task::promise_type"*)* #0 0x01e94b6a (/opt/compiler-explorer/clang-trunk-20171023/bin/clang-6.0+0x1e94b6a) #1 0x01e92c5e (/opt/compiler-explorer/clang-trunk-20171023/bin/clang-6.0+0x1e92c5e) #2 0x01e92dac (/opt/compiler-explorer/clang-trunk-20171023/bin/clang-6.0+0x1e92dac) #3 0x7fa477e49390 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x11390) #4 0x01922ba2 (/opt/compiler-explorer/clang-trunk-20171023/bin/clang-6.0+0x1922ba2) #5 0x01922fb7 (/opt/compiler-explorer/clang-trunk-20171023/bin/clang-6.0+0x1922fb7) #6 0x0192370e (/opt/compiler-explorer/clang-trunk-20171023/bin/clang-6.0+0x192370e) #7 0x0192966e (/opt/compiler-explorer/clang-trunk-20171023/bin/clang-6.0+0x192966e) #8 0x0192bd04 (/opt/compiler-explorer/clang-trunk-20171023/bin/clang-6.0+0x192bd04) #9 0x01a0bec9 (/opt/compiler-explorer/clang-trunk-20171023/bin/clang-6.0+0x1a0bec9) #10 0x01a19447 (/opt/compiler-explorer/clang-trunk-20171023/bin/clang-6.0+0x1a19447) #11 0x01a229da (/opt/compiler-explorer/clang-trunk-20171023/bin/clang-6.0+0x1a229da) #12 0x01a22c1c (/opt/compiler-explorer/clang-trunk-20171023/bin/clang-6.0+0x1a22c1c) #13 0x01a2332d (/opt/compiler-explorer/clang-trunk-20171023/bin/clang-6.0+0x1a2332d) #14 0x019cefba (/opt/compiler-explorer/clang-trunk-20171023/bin/clang-6.0+0x19cefba) #15 0x019cf0fe (/opt/compiler-explorer/clang-trunk-20171023/bin/clang-6.0+0x19cf0fe) #16 0x019cf45c (/opt/compiler-explorer/clang-trunk-20171023/bin/clang-6.0+0x19cf45c) #17 0x02824f01 (/opt/compiler-explorer/clang-trunk-20171023/bin/clang-6.0+0x2824f01) #18 0x02826675 (/opt/compiler-explorer/clang-trunk-20171023/bin/clang-6.0+0x2826675) #19 0x014e46a3 (/opt/compiler-explorer/clang-trunk-20171023/bin/clang-6.0+0x14e46a3) #20 0x019ceb74 (/opt/compiler-explorer/clang-trunk-20171023/bin/clang-6.0+0x19ceb74) #21 0x0204c164 (/opt/compiler-explorer/clang-trunk-20171023/bin/clang-6.0+0x204c164) #22 0x02816b24 (/opt/compiler-explorer/clang-trunk-20171023/bin/clang-6.0+0x2816b24) #23 0x029affc8 (/opt/compiler-explorer/clang-trunk-20171023/bin/clang-6.0+0x29affc8) #24 0x02816107 (/opt/compiler-explorer/clang-trunk-20171023/bin/clang-6.0+0x2816107) #25 0x023dc4ae (/opt/compiler-explorer/clang-trunk-20171023/bin/clang-6.0+0x23dc4ae) #26 0x023a98e6 (/opt/compiler-explorer/clang-trunk-20171023/bin/clang-6.0+0x23a98e6) #27 0x0246e482 (/opt/compiler-explorer/clang-trunk-20171023/bin/clang-6.0+0x246e482) #28 0x009e8818 (/opt/compiler-explorer/clang-trunk-20171023/bin/clang-6.0+0x9e8818) #29 0x0095523a (/opt/compiler-explorer/clang-trunk-20171023/bin/clang-6.0+0x95523a) #30 0x7fa476dce830 __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x20830) #31 0x009e6269 (/opt/compiler-explorer/clang-trunk-20171023/bin/clang-6.0+0x9e6269) Stack dump: 0. Program arguments: /opt/compiler-explorer/clang-trunk-20171023/bin/clang-6.0 -cc1 -triple x86_64-unknown-linux-gnu -S -disable-free -disable-llvm-verifier -discard-value-names -main-file-name example.cpp -mrelocation-model static -mthread-model posix -fmath-errno -masm-verbose -mconstructor-aliases -munwind-tables -fuse-init-array -target-cpu x86-64 -dwarf-column-info -debug-info-kind=limited -dwarf-version=4 -debugger-tuning=gdb -momit-leaf-frame-pointer -coverage-notes-file /tmp/compiler-explorer-compiler117924-58-4capm4.omaapjh5mi/output.gcno -resource-dir /opt/compiler-explorer/clang-trunk-20171023/lib/clang/6.0.0 -c-isystem /usr/include/x86_64-linux-gnu -cxx-isystem /usr/include/x86_64-linux-gnu -internal-isystem /opt/compiler-explorer/clang-trunk-20171023/bin/../include/c++/v1 -internal-isystem /usr/local/include -internal-isystem /opt/compiler-explorer/clang-trunk-20171023/lib/clang/6.0.0/include -internal-externc-isystem /usr/include/x86_64-linux-gnu -internal-externc-isystem /include -internal-externc-isystem /usr/include -O3 -std=c++1z -fdeprecated-macro -fdebug-compilation-dir /compiler-explorer -ferror-limit 19 -fmessage-length 0 -fcoroutines-ts -fobjc-runtime=gcc -fcxx-exceptions -fexceptions -fdiagnostics-show-option -
[llvm-bugs] [Bug 34869] Assertion failure in clang::BodyFarm::getBody()
https://bugs.llvm.org/show_bug.cgi?id=34869 George Karpenkov changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #20 from George Karpenkov --- I've pushed https://reviews.llvm.org/D39208 https://reviews.llvm.org/D39201 https://reviews.llvm.org/D39031 and https://reviews.llvm.org/D39015. Let's hope it actually works now :P -- 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 3727 in oss-fuzz: llvm/llvm-special-case-list-fuzzer: Global-buffer-overflow in p_bracket
Updates: Cc: vtsyrklev...@google.com Comment #2 on issue 3727 by k...@google.com: llvm/llvm-special-case-list-fuzzer: Global-buffer-overflow in p_bracket https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=3727#c2 (No comment was entered for this change.) -- 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 35049] New: [PowerPC] backtrace isn't complete
https://bugs.llvm.org/show_bug.cgi?id=35049
Bug ID: 35049
Summary: [PowerPC] backtrace isn't complete
Product: new-bugs
Version: trunk
Hardware: Other
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: eric.schwe...@pgroup.com
CC: llvm-bugs@lists.llvm.org
If we take a rather simple program like the following and compile it with
"clang -g -O0 prgm.c", we don't appear to get debug stack frame information
that covers all instructions.
% gdb a.out
Reading symbols from a.out...done.
(gdb) b foo
Breakpoint 1 at 0x162c: file backtrace.c, line 12.
(gdb) r
Starting program: ./a.out
Breakpoint 1, foo () at backtrace.c:12
12 return bar() * 2;
(gdb) disas
Dump of assembler code for function foo:
0x1610 <+0>: lis r2,4099
0x1614 <+4>: addir2,r2,-32512
0x1618 <+8>: mflrr0
0x161c <+12>:std r31,-8(r1)
0x1620 <+16>:std r0,16(r1)
0x1624 <+20>:stdur1,-112(r1)
0x1628 <+24>:mr r31,r1
=> 0x162c <+28>:bl 0x15f0
0x1630 <+32>:nop
0x1634 <+36>:li r4,1
0x1638 <+40>:slw r3,r3,r4
0x163c <+44>:extsw r3,r3
0x1640 <+48>:addir1,r1,112
0x1644 <+52>:ld r0,16(r1)
0x1648 <+56>:ld r31,-8(r1)
0x164c <+60>:mtlrr0
0x1650 <+64>:blr
0x1654 <+68>:.long 0x0
0x1658 <+72>:.long 0x0
0x165c <+76>:.long 0x0
End of assembler dump.
(gdb) b *0x164c
Breakpoint 2 at 0x164c: file backtrace.c, line 12.
(gdb) bt
#0 foo () at backtrace.c:12
#1 0x169c in main () at backtrace.c:20
(gdb) cont
Continuing.
Breakpoint 2, 0x164c in foo () at backtrace.c:12
12 return bar() * 2;
(gdb) bt
#0 0x164c in foo () at backtrace.c:12
#1 0x100a4700 in generic_start_main.isra () from /lib64/libc.so.6
#2 0x100a48f4 in __libc_start_main () from /lib64/libc.so.6
#3 0x in ?? ()
(gdb)
As can be seen in the above cut-and-paste, the backtrace for breakpoint 1 and
the backtrace fro breakpoint 2 are different even though they are in the same
function, foo().
Here is an example program:
"""
#include
__attribute__((noinline))
int bar()
{
return 1;
}
__attribute__((noinline))
int foo()
{
return bar() * 2;
}
int main()
{
int i = 100;
while (i > 0)
{
printf("result = %d\n", foo());
i--;
}
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] Issue 3695 in oss-fuzz: llvm/llvm-isel-fuzzer--aarch64-gisel: Direct-leak in llvm::MDTuple::getImpl
Updates: Labels: ClusterFuzz-Top-Crash Comment #2 on issue 3695 by monor...@clusterfuzz-external.iam.gserviceaccount.com: llvm/llvm-isel-fuzzer--aarch64-gisel: Direct-leak in llvm::MDTuple::getImpl https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=3695#c2 Testcase 5260607780552704 is a top crash on ClusterFuzz for linux platform. Please prioritize fixing this crash. If this is incorrect, please file a bug on https://github.com/google/oss-fuzz/issues/new -- 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 3727 in oss-fuzz: llvm/llvm-special-case-list-fuzzer: Global-buffer-overflow in p_bracket
Comment #3 on issue 3727 by k...@google.com: llvm/llvm-special-case-list-fuzzer: Global-buffer-overflow in p_bracket https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=3727#c3 Of course, this is just regexp: ==1==ERROR: AddressSanitizer: global-buffer-overflow on address 0x006a18bc at pc 0x0057f8e9 bp 0x7ffc38c8faf0 sp 0x7ffc38c8fae8 READ of size 1 at 0x006a18bc thread T0 SCARINESS: 12 (1-byte-read-global-buffer-overflow) #0 0x57f8e8 in p_b_coll_elem /src/llvm/lib/Support/regcomp.c:889:42 #1 0x57f8e8 in p_b_eclass /src/llvm/lib/Support/regcomp.c:848 #2 0x57f8e8 in p_b_term /src/llvm/lib/Support/regcomp.c:783 #3 0x57f8e8 in p_bracket /src/llvm/lib/Support/regcomp.c:698 #4 0x56d884 in p_ere_exp /src/llvm/lib/Support/regcomp.c:377:3 #5 0x56d884 in p_ere /src/llvm/lib/Support/regcomp.c:277 #6 0x56e1fb in p_ere_exp /src/llvm/lib/Support/regcomp.c:331:4 #7 0x56e1fb in p_ere /src/llvm/lib/Support/regcomp.c:277 #8 0x56b074 in llvm_regcomp /src/llvm/lib/Support/regcomp.c:232:3 #9 0x56a6dd in llvm::Regex::Regex(llvm::StringRef, unsigned int) /src/llvm/lib/Support/Regex.cpp:34:11 -- 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 3740 in oss-fuzz: llvm/clang-fuzzer: ASSERT: cast(SubExpr)->getQualifier() && "fixed to a member ref with no nes
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevlieg...@apple.com, llvm-b...@lists.llvm.org, v...@apple.com Labels: ClusterFuzz Stability-Memory-AddressSanitizer Reproducible Engine-libfuzzer Proj-llvm Reported-2017-10-24 New issue 3740 by monor...@clusterfuzz-external.iam.gserviceaccount.com: llvm/clang-fuzzer: ASSERT: cast(SubExpr)->getQualifier() && "fixed to a member ref with no nes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=3740 Detailed report: https://oss-fuzz.com/testcase?key=6571623730642944 Project: llvm Fuzzer: libFuzzer_llvm_clang-fuzzer Fuzz target binary: clang-fuzzer Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: ASSERT Crash Address: Crash State: cast(SubExpr)->getQualifier() && "fixed to a member ref with no nes clang::Sema::FixOverloadedFunctionReference FinishOverloadedCallExpr Sanitizer: address (ASAN) Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=6571623730642944 Issue filed automatically. See https://github.com/google/oss-fuzz/blob/master/docs/reproducing.md for more information. When you fix this bug, please * mention the fix revision(s). * state whether the bug was a short-lived regression or an old bug in any stable releases. * add any other useful information. This information can help downstream consumers. If you have questions for the OSS-Fuzz team, please file an issue at https://github.com/google/oss-fuzz/issues. -- 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
