[llvm-bugs] Issue 9947 in oss-fuzz: llvm/llvm-demangle-fuzzer: Stack-overflow in Db::parseEncoding
Comment #2 on issue 9947 by ClusterFuzz-External: llvm/llvm-demangle-fuzzer: Stack-overflow in Db::parseEncoding https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=9947#c2 ClusterFuzz has detected this issue as fixed in range 201808200140:201808202008. Detailed report: https://oss-fuzz.com/testcase?key=5096757879898112 Project: llvm Fuzzer: libFuzzer_llvm_llvm-demangle-fuzzer Fuzz target binary: llvm-demangle-fuzzer Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: Stack-overflow Crash Address: 0x7fff0004dfe0 Crash State: Db::parseEncoding Db::parseName Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201808160456:201808170407 Fixed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201808200140:201808202008 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5096757879898112 See https://github.com/google/oss-fuzz/blob/master/docs/reproducing.md for more information. If you suspect that the result above is incorrect, try re-doing that job on the test case report page. -- 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 9947 in oss-fuzz: llvm/llvm-demangle-fuzzer: Stack-overflow in Db::parseEncoding
Updates: Labels: ClusterFuzz-Verified Status: Verified Comment #3 on issue 9947 by ClusterFuzz-External: llvm/llvm-demangle-fuzzer: Stack-overflow in Db::parseEncoding https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=9947#c3 ClusterFuzz testcase 5096757879898112 is verified as fixed, so closing issue as verified. 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 7192 in oss-fuzz: llvm/llvm-demangle-fuzzer: Stack-overflow in AbiTagAttr::printLeft
Comment #5 on issue 7192 by ClusterFuzz-External: llvm/llvm-demangle-fuzzer: Stack-overflow in AbiTagAttr::printLeft https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=7192#c5 ClusterFuzz has detected this issue as fixed in range 201808200140:201808202008. Detailed report: https://oss-fuzz.com/testcase?key=4676153374670848 Project: llvm Fuzzer: libFuzzer_llvm_llvm-demangle-fuzzer Fuzz target binary: llvm-demangle-fuzzer Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: Stack-overflow Crash Address: 0x7ffd3e4d2fd8 Crash State: AbiTagAttr::printLeft Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201803190520:201803200524 Fixed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201808200140:201808202008 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=4676153374670848 See https://github.com/google/oss-fuzz/blob/master/docs/reproducing.md for more information. If you suspect that the result above is incorrect, try re-doing that job on the test case report page. -- 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 7192 in oss-fuzz: llvm/llvm-demangle-fuzzer: Stack-overflow in AbiTagAttr::printLeft
Updates: Labels: ClusterFuzz-Verified Status: Verified Comment #6 on issue 7192 by ClusterFuzz-External: llvm/llvm-demangle-fuzzer: Stack-overflow in AbiTagAttr::printLeft https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=7192#c6 ClusterFuzz testcase 4676153374670848 is verified as fixed, so closing issue as verified. 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 7096 in oss-fuzz: llvm/llvm-demangle-fuzzer: Stack-overflow in QualifiedName::printLeft
Comment #5 on issue 7096 by ClusterFuzz-External: llvm/llvm-demangle-fuzzer: Stack-overflow in QualifiedName::printLeft https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=7096#c5 ClusterFuzz has detected this issue as fixed in range 201808200140:201808202008. Detailed report: https://oss-fuzz.com/testcase?key=6649544751185920 Project: llvm Fuzzer: libFuzzer_llvm_llvm-demangle-fuzzer Fuzz target binary: llvm-demangle-fuzzer Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: Stack-overflow Crash Address: 0x7ffca2aaaff8 Crash State: QualifiedName::printLeft Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201803190520:201803200524 Fixed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201808200140:201808202008 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=6649544751185920 See https://github.com/google/oss-fuzz/blob/master/docs/reproducing.md for more information. If you suspect that the result above is incorrect, try re-doing that job on the test case report page. -- 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 7096 in oss-fuzz: llvm/llvm-demangle-fuzzer: Stack-overflow in QualifiedName::printLeft
Updates: Labels: ClusterFuzz-Verified Status: Verified Comment #6 on issue 7096 by ClusterFuzz-External: llvm/llvm-demangle-fuzzer: Stack-overflow in QualifiedName::printLeft https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=7096#c6 ClusterFuzz testcase 6649544751185920 is verified as fixed, so closing issue as verified. 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 38656] New: Unnecessary register spilling
https://bugs.llvm.org/show_bug.cgi?id=38656
Bug ID: 38656
Summary: Unnecessary register spilling
Product: new-bugs
Version: 6.0
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: maarten.bosm...@vortech.nl
CC: llvm-bugs@lists.llvm.org
Clang compiles the loop in this function
void stencil1(int start, int stop, ptrdiff_t stride,
float *restrict a, float *restrict b,
float (*restrict c)[stride]) {
const float *restrict c1 = &c[1][0];
const float *restrict c2 = &c[2][0];
const float *restrict c3 = &c[3][0];
const float *restrict c4 = &c[4][0];
const float *restrict c5 = &c[5][0];
const float *restrict c6 = &c[6][0];
const float *restrict c7 = &c[7][0];
const float *restrict c8 = &c[8][0];
for (int i = start; i <= stop; i++) {
a[i] += b[1] * c1[i] + b[2] * c2[i]
+ b[3] * c3[i] + b[4] * c4[i]
+ b[5] * c5[i] + b[6] * c6[i]
+ b[7] * c7[i] + b[8] * c8[i];
}
}
as (using AVX2)
.LBB0_6: # =>This Inner Loop Header: Depth=1
lea rbx, [r11 + r13]
vmulps ymm0, ymm8, ymmword ptr [r10 + 4*r11]
mov r14, qword ptr [rsp - 88] # 8-byte Reload
vfmadd231ps ymm0, ymm9, ymmword ptr [r14 + 4*rbx] # ymm0 = (ymm9 * mem) +
ymm0
mov rax, qword ptr [rsp - 96] # 8-byte Reload
vfmadd231ps ymm0, ymm10, ymmword ptr [rax + 4*rbx] # ymm0 = (ymm10 * mem) +
ymm0
vfmadd231ps ymm0, ymm11, ymmword ptr [r8 + 4*rbx] # ymm0 = (ymm11 * mem) +
ymm0
mov rax, qword ptr [rsp - 104] # 8-byte Reload
vfmadd231ps ymm0, ymm12, ymmword ptr [rax + 4*rbx] # ymm0 = (ymm12 * mem) +
ymm0
vfmadd231ps ymm0, ymm13, ymmword ptr [r12 + 4*rbx] # ymm0 = (ymm13 * mem) +
ymm0
vfmadd231ps ymm0, ymm14, ymmword ptr [r15 + 4*rbx] # ymm0 = (ymm14 * mem) +
ymm0
vfmadd231ps ymm0, ymm15, ymmword ptr [rdi + 4*rbx] # ymm0 = (ymm15 * mem) +
ymm0
vaddps ymm0, ymm0, ymmword ptr [r9 + 4*r11]
vmovups ymmword ptr [r9 + 4*r11], ymm0
add r11, 8
cmp rbp, r11
jne .LBB0_6
The b values are broadcasted to ymm8-ymm15 before the loop, which is nice.
The same is not done for all the adresses of c1..c8. Some of them are stored in
registers, but others are loaded from the stack first in rax (and weirdly r14).
I think this harms performance. There should be enough registers free to hoist
the loading of the addresses outside the loop so the three mov instructions can
be removed from the loop.
If the c1..c8 variables are pointer arguments to a function instead of coming
out of a VLA calculation, the register spilling does not occur.
Godbolt link:
https://godbolt.org/#z:OYLghAFBqd5QCxAYwPYBMCmBRdBLAF1QCcAaPECAKxAEZSAbAQwDtQB9T5UgZ1QFdiyTCADkAUgBMAZjwtkDflgDU46QGEeBdFgBmAOgRrs4gAwBBM%2BYBuqPOmVbM8vA1oQ5BRwSbECpZU9vVAAHAJCCYnxdXXYvLWJ7TFIrZTT0tN0GVCYvACpiTAS8ZC8mAKyc/MLi0uUAIxSLDIzK3OUIAqLIkq9kAEpxAFYAIWKsYYARftUAdhGrVPS0Fi1lNuruxLrkWlVpSdVJADZkYZHaKfPTK%2BkF5uXUVa8N5S7avsl9w6lT88krqMbkNJmp7uYMis1q93j0dtJvkc/qNpICRsDQXclmkoS9su1Yds%2BgAWRG/M6jYlojFg7HKXHrfGbD70oZkk4UkZDam3cGQp7QplvGpwvrHdnIkbHHkg2kPHECvFVYVbXr02YSzmzGWYvmPZ6M5WEtXIAAcmvOpp1css8vWJA6QTwiK0vgIYMC%2B3UakOWlCHrwUgWkhGM3E8zpGSY50DIKOCwODXOlzjeXpKZGsZ%2BIaTowBqfp%2BczVztLRaQdzI1RBeQ1eLcYr9XOVJrLfroNLZfSjfO3Jrffb8cr0prI/bka7aR7o21Ndng%2BnIytNeX46xdvDHcssy3VldBBKyls9m8zmQrkk9Q8LHiPj8ASCfrCE8yQuNdXKhoJIqJDSaEK7BkYR/E16HpRUv2ZUVC3/ScgLfED4QCeCjUQklYMAiDgNVHYhmQrCEJwsUMLLFDvyI9V8INbCWTNMMIwsOldAda8vGdH1vDdAMvQ4p8AyDIN6L1Mto1GLN4w4ptRhTQ4012GMpiHKSRnzWTCwU2VO0nRdqzU2sNOzEZKxbPS2yzF8u0XPs9IHcTFxHPSx3MrTLJzZTZz0%2Bc7Lcy1FLk1dzPXACpx3RZQosY8HCcFwGEkJhWM4%2B9AhvYIwmUCIojwGI4m8RIsBIloaOgz8it/RoLNeTo0PpQZRnGTApiEulovPWKr1dJKnwCT9ypc8lkx1AJ%2BrzQaLOGqtBqRTkTOuKYCoycbrNmkEho5c4HOWyZ5u7NaZ0m8bl1BIFGptTcrFEfpGDEIZRFIFgxFMW7UDEdRHAEIRMCOaRaFuggHouy6AGsQEkYl9GJIZjgATlNIZiWOU1TFNSQockK7RGJW77tER7SGe0Rbp4EBTFIP6cYu0g4FgJA0AAWxCVxMDICgIDphmGCZlBgGR0hdFcAgmaJiB6n%2B0h6jkXwAE8xB%2B0g6dp5wCAAeRYBhpfJ0gsFp1hgA50X8EKUo8GsIpRcwAAPTBkH4AWZduzxMAYUWelp/7LuYNgQE4dhuAYPB6iJyBLtCA8BTEABaLR0B9ZAoah5Rw4AdSYBgGATpXdCYNZw%2B1oQjAOBAs4Ad0dtPw90FhUHD/gWGIVBU/D7JQh4BOK6ruQ/ZYTBCfe4Q6Hd66sdF/HzdNY5w%2BOUlgGQZBlFNfQvggXBCAdKRvoCdRUHpxniC%2B2gZnUX63cuhBMCYLBiEoIGQekcHTWJWhpGOWgofh2ZTVmWZjnRzHSFd2hTAk2xrjfGhNiakzdpTGAiAUBb3ZkzcglA2Y7xQAoHWcRiA10BrzfmgtKAiw1uLFgUs7Zyy3grG8Ks1b60wNrNgesNYGytgeE2RMNYWytjbEQohZYOydhrF2kCPYcC4Iwf2gcIDBwiHgMOohI7aBjnHBOydU7p0ztnXOyB86TELjwEuqjy6V2rrXeuDBG6oGbq3IxHc5Dd14L3EQ%2B90Y3TusPMQo9x6T3pMIjokQsEzCXvgIgu815gU3tvDmISZDSAPkfcm/QT5nwvlfUgwMTj6CGLMYkccEamEfqDYkaN%2BG/3/oA1xGtQG8HAWTR6l0qYwOQZExBrM4EoPPDPWgpocEMAFsQIWBDcZEJITw268tFZUPVrjLWOsGFTLwIbFhpt2GW2trbEZ5AbyO2dokV28TGA6y9qIv2Ad4BSNDqsCOGcs5eBzr4LRPpdH6LLjXOuqcfS4z4IIPuTj%2BEuOAU9dxY8J6khKLPTp%2BhTAQo6MvYJe8N6tMiV9IYsSIHxMSefTmkjUkgyGHfaQppTS0CGNIIYUNH6mihj/W6pSgFuIJlUkmNSAbo0kEPCpYg4m1MuibPpMj7rEiAA%3D%3D
--
You are receiving this
[llvm-bugs] [Bug 38657] New: Test using strcmp fails after r339410
https://bugs.llvm.org/show_bug.cgi?id=38657
Bug ID: 38657
Summary: Test using strcmp fails after r339410
Product: new-bugs
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: douglas_y...@playstation.sony.com
CC: llvm-bugs@lists.llvm.org
One of our internal tests started to fail after r339410 was committed. Here is
a repro that can demonstrate the problem:
/* test.cpp */
#include
#include
struct String {
charcontent[100];
String (const char* a) {
strcpy(content, a);
}
operator const char* () const {
return content;
}
};
int main()
{
char const* str1 = String("three");
assert(strcmp(str1, "three") == 0);
return 0;
}
Next, compile the code using a compiler built from r339410 or newer and with
optimizations enabled (-O2), and when the resulting executing is run, you will
see the following output:
$ clang -O2 test.cpp -o test.out; ./test.out
test.out: test.cpp:17: int main(): Assertion `strcmp(str1, "three") == 0'
failed.
--
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 38657] Test using strcmp fails after r339410
https://bugs.llvm.org/show_bug.cgi?id=38657
Dimitry Andric changed:
What|Removed |Added
CC||dimi...@andric.com
Status|NEW |RESOLVED
Resolution|--- |INVALID
--- Comment #3 from Dimitry Andric ---
As far as I can see, the code is invalid. The String() temporary object created
in the first line of main() is immediately destructed afterwards, making str1
point to invalidated memory.
Demonstration:
/* test.cpp */
#include
#include
#include
struct String {
charcontent[100];
String (const char* a) {
strcpy(content, a);
}
~String () {
printf("destroying String\n");
}
operator const char* () const {
return content;
}
};
int main()
{
char const* str1 = String("three");
printf("checking assertion\n");
assert(strcmp(str1, "three") == 0);
return 0;
}
$ clang -O2 pr38657-2.cpp -o pr38657-2
$ ./pr38657-2
destroying String
checking assertion
Assertion failed: (strcmp(str1, "three") == 0), function main, file
pr38657-2.cpp, line 23.
Abort trap (core dumped)
E.g., you should ensure the String object is not destroyed before checking the
assertion.
--
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 38658] New: [X86] Failure to lower VSELECT on pre-SSE41 targets
https://bugs.llvm.org/show_bug.cgi?id=38658
Bug ID: 38658
Summary: [X86] Failure to lower VSELECT on pre-SSE41 targets
Product: libraries
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: Backend: X86
Assignee: unassignedb...@nondot.org
Reporter: llvm-...@redking.me.uk
CC: andrea.dibia...@gmail.com, craig.top...@gmail.com,
llvm-bugs@lists.llvm.org, spatel+l...@rotateright.com
define <16 x i8> @sdiv(<16 x i8>) {
%2 = sdiv <16 x i8> %0,
ret <16 x i8> %2
}
llc -mcpu=btver1
LLVM ERROR: Cannot select: t158: v8i16 = vselect t249, t250, t152
t249: v8i16 = X86ISD::VSRAI t153, Constant:i8<15>
Better VSELECT support in SelectionDAGLegalize::ExpandNode?
--
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 10004 in oss-fuzz: llvm/llvm-dwarfdump-fuzzer: ASSERT: Storage.hasVal
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevlieg...@apple.com, igm...@gmail.com, eney...@google.com, llvm-b...@lists.llvm.org, j...@chromium.org, v...@apple.com, mitchphi...@outlook.com, xpl...@gmail.com, akils...@apple.com Labels: ClusterFuzz Stability-Memory-AddressSanitizer Reproducible Engine-libfuzzer Proj-llvm Reported-2018-08-21 Type: Bug New issue 10004 by ClusterFuzz-External: llvm/llvm-dwarfdump-fuzzer: ASSERT: Storage.hasVal https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=10004 Detailed report: https://oss-fuzz.com/testcase?key=5203222753968128 Project: llvm Fuzzer: libFuzzer_llvm_llvm-dwarfdump-fuzzer Fuzz target binary: llvm-dwarfdump-fuzzer Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: ASSERT Crash Address: Crash State: Storage.hasVal llvm::DWARFDebugLine::Prologue::parse llvm::DWARFDebugLine::LineTable::parse Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201711160610:201712080609 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5203222753968128 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 need to contact the OSS-Fuzz team with a question, concern, or any other feedback, 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] [Bug 38657] Test using strcmp fails after r339410
https://bugs.llvm.org/show_bug.cgi?id=38657
Douglas Yung changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|INVALID |---
--- Comment #5 from Douglas Yung ---
Sorry, when cutting down the test, I think I may have invalidated it. Here is
the original test case:
/* test.cpp */
#include
#include
struct String {
char content[100];
String (const String& a) {
strcpy(content, a.content);
}
String (const char* a) {
strcpy(content, a);
}
operator const char* () const {
return content;
}
};
String operator+ (const String& a, const String& b) {
String res("Error!");
if (strcmp(a, "one") == 0 && strcmp(b, "one") == 0) {
res = String("two");
}
if (strcmp(a, "one") == 0 && strcmp(b, "two") == 0) {
res = String("three");
}
return res;
}
int main()
{
String res1 = String("one") + String("two");
assert(strcmp(res1, "three") == 0);
char const* str1 = String("one") + String("two");
assert(strcmp(str1, "three") == 0);
String res2 = String("one") + "one";
assert(strcmp(res2, "two") == 0);
char const* str2 = String("one") + "one";
assert(strcmp(str2, "two") == 0);
String res3 = "one" + String("two");
assert(strcmp(res3, "three") == 0);
char const* str3 = "one" + String("two");
assert(strcmp(str3, "three") == 0);
return 0;
}
On my machine with gcc 5.5 and -O2, the code does NOT fail, while with clang
r399410 it does.
--
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 38659] New: Compile issue on clang 6.0.0
https://bugs.llvm.org/show_bug.cgi?id=38659 Bug ID: 38659 Summary: Compile issue on clang 6.0.0 Product: new-bugs Version: unspecified Hardware: Other OS: All Status: NEW Severity: enhancement Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: ndow...@yahoo.com CC: llvm-bugs@lists.llvm.org On i386 when building angelscript I get: If building for amd64 I don’t. The workaround for i386 is to build using gcc gmake[1]: Entering directory '/wrkdirs/usr/ports/lang/angelscript/work/sdk/angelscript/projects/gnuc' c++ -O2 -pipe -fstack-protector -fno-strict-aliasing -Wall -fPIC -fno-strict-aliasing -o obj/as_atomic.o -c ../../source/as_atomic.cpp c++ -O2 -pipe -fstack-protector -fno-strict-aliasing -Wall -fPIC -fno-strict-aliasing -o obj/as_builder.o -c ../../source/as_builder.cpp c++ -O2 -pipe -fstack-protector -fno-strict-aliasing -Wall -fPIC -fno-strict-aliasing -o obj/as_bytecode.o -c ../../source/as_bytecode.cpp c++ -O2 -pipe -fstack-protector -fno-strict-aliasing -Wall -fPIC -fno-strict-aliasing -o obj/as_callfunc.o -c ../../source/as_callfunc.cpp c++ -O2 -pipe -fstack-protector -fno-strict-aliasing -Wall -fPIC -fno-strict-aliasing -o obj/as_callfunc_arm.o -c ../../source/as_callfunc_arm.cpp c++ -O2 -pipe -fstack-protector -fno-strict-aliasing -Wall -fPIC -fno-strict-aliasing -o obj/as_callfunc_mips.o -c ../../source/as_callfunc_mips.cpp c++ -O2 -pipe -fstack-protector -fno-strict-aliasing -Wall -fPIC -fno-strict-aliasing -o obj/as_callfunc_ppc.o -c ../../source/as_callfunc_ppc.cpp c++ -O2 -pipe -fstack-protector -fno-strict-aliasing -Wall -fPIC -fno-strict-aliasing -o obj/as_callfunc_ppc_64.o -c ../../source/as_callfunc_ppc_64.cpp c++ -O2 -pipe -fstack-protector -fno-strict-aliasing -Wall -fPIC -fno-strict-aliasing -o obj/as_callfunc_sh4.o -c ../../source/as_callfunc_sh4.cpp c++ -O2 -pipe -fstack-protector -fno-strict-aliasing -Wall -fPIC -fno-strict-aliasing -o obj/as_callfunc_x86.o -c ../../source/as_callfunc_x86.cpp fatal error: error in backend: No open frame c++: error: clang frontend command failed with exit code 70 (use -v to see invocation) FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512 Target: i386-unknown-freebsd10.4 Thread model: posix c++: note: diagnostic msg: PLEASE submit a bug report to https://bugs.freebsd.org/submit/ and include the crash backtrace, preprocessed source, and associated run script. c++: note: diagnostic msg: PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: Preprocessed source(s) and associated run script(s) are located at: c++: note: diagnostic msg: /tmp/as_callfunc_x86-315a7c.cpp c++: note: diagnostic msg: /tmp/as_callfunc_x86-315a7c.sh c++: note: diagnostic msg: gmake[1]: *** [Makefile:157: obj/as_callfunc_x86.o] Error 70 gmake[1]: *** Waiting for unfinished jobs gmake[1]: Leaving directory '/wrkdirs/usr/ports/lang/angelscript/work/sdk/angelscript/projects/gnuc' ===> Compilation failed unexpectedly. Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure to the maintainer. *** Error code 1 Stop. make: stopped in /usr/ports/lang/angelscript build of lang/angelscript | angelscript-2.32.0 ended at Thu Aug 16 10:19:44 CST 2018 build time: 00:00:15 !!! build failure encountered !!! [00:01:51] Error: Build failed in phase: build [00:01:51] Cleaning up [00:01:52] Unmounting file systems -- 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 38623] Assertion in CodeGen fails when a reference to a global variable is captured by a block
https://bugs.llvm.org/show_bug.cgi?id=38623 Alexey Bataev changed: What|Removed |Added Status|RESOLVED|REOPENED 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 38660] New: Merge r340191 to 7.0 branch: [OPENMP] Fix crash on the emission of the weak function declaration.
https://bugs.llvm.org/show_bug.cgi?id=38660 Bug ID: 38660 Summary: Merge r340191 to 7.0 branch: [OPENMP] Fix crash on the emission of the weak function declaration. Product: clang Version: 7.0 Hardware: PC OS: All Status: NEW Severity: release blocker Priority: P Component: LLVM Codegen Assignee: unassignedclangb...@nondot.org Reporter: a.bat...@hotmail.com CC: llvm-bugs@lists.llvm.org Fixes compiler crash when it tries to emit functions for the offloading devices, which should not be emitted (like weak references). -- 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 38288] clang miscompiles with "-newgvn" at -O3 in 32-bit mode on valid code
https://bugs.llvm.org/show_bug.cgi?id=38288 Florian Hahn changed: What|Removed |Added Resolution|--- |FIXED Fixed By Commit(s)||r340031 Status|REOPENED|RESOLVED --- Comment #4 from Florian Hahn --- Thanks, it seems I tested this with rL340031 applied when I closed this issue. Closing now that rL340031 landed. -- 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 38661] New: PPC32 fails to extend i1 in stack arguments
https://bugs.llvm.org/show_bug.cgi?id=38661
Bug ID: 38661
Summary: PPC32 fails to extend i1 in stack arguments
Product: libraries
Version: trunk
Hardware: Other
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Backend: PowerPC
Assignee: unassignedb...@nondot.org
Reporter: jist...@redhat.com
CC: llvm-bugs@lists.llvm.org
GitHub user @LionNatsu managed to reduce rust#50960 to a simple LLVM-IR test:
https://github.com/rust-lang/rust/issues/50960#issuecomment-414482775
target datalayout = "E-m:e-p:32:32-i64:64-n32"
target triple = "powerpc-unknown-linux-gnu"
declare zeroext i1 @a_strange_function(i1 zeroext, i1 zeroext, i1 zeroext,
i1 zeroext, i1 zeroext, i1 zeroext, i1 zeroext, i1 zeroext, i1 zeroext, i1
zeroext)
define i32 @main(i32, i8**) {
top:
%2 = call zeroext i1 @a_strange_function(i1 zeroext true, i1 zeroext
true, i1 zeroext true, i1 zeroext true, i1 zeroext true, i1 zeroext true, i1
zeroext true, i1 zeroext true, i1 zeroext true, i1 zeroext true)
ret i32 0
}
The call is generated like this:
li 3, 1
li 4, 1
li 5, 1
li 6, 1
stb 3, 12(1)
stb 3, 8(1)
li 3, 1
li 7, 1
li 8, 1
li 9, 1
li 10, 1
bl a_strange_function@PLT
Those "stb" should be "stw" to properly fill the "i1 zeroext" argument to i32,
as ABI requires. Otherwise we've only written the most-significant byte of the
full argument that the callee will read.
As it happens, Rust's callee was compiled with GCC, but we can also see a
problem in the function definition if compiled with LLVM. Something like:
define zeroext i1 @a_strange_function(i1 zeroext, i1 zeroext, i1 zeroext,
i1 zeroext, i1 zeroext, i1 zeroext, i1 zeroext, i1 zeroext, i1 zeroext, i1
zeroext) {
%result = and i1 %8, %9
ret i1 %result
}
This produces:
lbz 3, 12(1)
lbz 4, 8(1)
and 3, 4, 3
clrlwi 3, 3, 31
blr
Those "lbz" are bug-compatible with what the caller did above, but still wrong
for the ABI. It should either read the whole word, or just read the
least-significant bytes at 15(1) and 11(1).
These problems do not arise with "llc -O0" or "-O1", which also means these two
won't be bug-compatible if they're compiled with different optimization levels.
Of course they should both stick to ABI.
--
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 38662] New: Merge r339091 into LLVM 7.0 release branch: Fix failing lit test shtest-format.py
https://bugs.llvm.org/show_bug.cgi?id=38662 Bug ID: 38662 Summary: Merge r339091 into LLVM 7.0 release branch: Fix failing lit test shtest-format.py Product: new-bugs Version: 7.0 Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: douglas_y...@playstation.sony.com CC: llvm-bugs@lists.llvm.org Hi, can we please merge r339091 into the release_70 branch? We are hitting this issue with our internal build bot which uses python 2. -- 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 38657] Test using strcmp fails after r339410
https://bugs.llvm.org/show_bug.cgi?id=38657
Eli Friedman changed:
What|Removed |Added
Resolution|--- |INVALID
Status|REOPENED|RESOLVED
--- Comment #8 from Eli Friedman ---
Yes, still a use-after-free. There are a few easy ways to verify this. One, it
crashes if you change "struct String" to allocate storage on the heap, e.g.:
struct String {
char *content;
String (const String& a) {
content = new char[100];
strcpy(content, a.content);
}
String (const char* a) {
content = new char[100];
strcpy(content, a);
}
operator const char* () const {
return content;
}
~String() { delete content; }
};
Two, if you build with -fsanitize=address, you'll get a "stack-use-after-scope"
error.
--
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 11645] CFG for destructors in '||'/'&&' lacks precision
https://bugs.llvm.org/show_bug.cgi?id=11645 Artem Dergachev changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #51 from Artem Dergachev --- We're doing pretty well here, i guess the CFG was fixed by Manuel Klimek in 2014. I attached the current CFG.svg for easier reading. The CFG contains all three temporary destructors and one automatic destructor. There's an extra correlated branch that controls conditional execution of ~B() which makes the CFG look like a triple-diamond instead of a double-diamond. The analyzer understands such branching it by remembering which temporaries were created in a special path-sensitive state trait. Additionally, i made sure that copy elision is marked up in the CFG: the construct-expression on [B5.2] contains a forward reference to the future actual constructor on [B5.8], alongside with heads-up on future bind-temporary at [B5.5] and materialize-temporary at [B5.7]. Other constructors are not elidable, so they only have forward references to bind/materialize temporary (for A(x) and B(y)) and to the variable declaration (for 'C b'). The analyzer was taught to make use of this information. There are other problems of this sort that were not addressed, eg. GNU *binary* ?: operator is broken, but && and || seem fine. Additionally, complexity of the CFG seems to grow linearly, and every temporary destructor appears in the CFG exactly once; i didn't look deeply into this, but it seems to be the case. Automatic destructor for 'C b' in our example will appear twice (depending on which branch of the if-statement is taken), but this doesn't seem to be exploitable. I'm attaching a CFG-chained-destructors.svg in which the initializer for 'C b' is replaced with (A(1) && A(2)) || (A(3) && A(4)) || (A(5) && A(6)) || (A(7) && A(8)). == Raw dump of the current CFG for easier comparing: int test(int x, int y) [B8 (ENTRY)] Succs (1): B7 [B1] 1: [B5.9].~C() (Implicit destructor) 2: bar 3: [B1.2] (ImplicitCastExpr, FunctionToPointerDecay, int (*)(void)) 4: [B1.3]() 5: return [B1.4]; Preds (1): B3 Succs (1): B0 [B2] 1: foo 2: [B2.1] (ImplicitCastExpr, FunctionToPointerDecay, int (*)(void)) 3: [B2.2]() 4: return [B2.3]; 5: [B5.9].~C() (Implicit destructor) Preds (1): B3 Succs (1): B0 [B3] 1: ~A() (Temporary object destructor) 2: b 3: [B3.2].operator bool 4: [B3.2] 5: [B3.4] (ImplicitCastExpr, UserDefinedConversion, _Bool) T: if [B3.5] Preds (2): B4 B5 Succs (2): B2 B1 [B4] 1: ~B() (Temporary object destructor) Preds (1): B5 Succs (1): B3 [B5] 1: [B7.9] || [B6.9] 2: [B5.1] (ImplicitCastExpr, IntegralCast, int) 3: [B5.2] (CXXConstructExpr, [B5.5], [B5.7], [B5.8], class C) 4: [B5.3] (ImplicitCastExpr, ConstructorConversion, class C) 5: [B5.4] (BindTemporary) 6: [B5.5] (ImplicitCastExpr, NoOp, const class C) 7: [B5.6] 8: [B5.7] (CXXConstructExpr, [B5.9], class C) 9: C b = A(x) || B(y); 10: ~C() (Temporary object destructor) T: (Temp Dtor) [B6.4] Preds (2): B6 B7 Succs (2): B4 B3 [B6] 1: y 2: [B6.1] (ImplicitCastExpr, LValueToRValue, int) 3: [B6.2] (CXXConstructExpr, [B6.4], [B6.6], class B) 4: [B6.3] (BindTemporary) 5: B([B6.4]) (CXXFunctionalCastExpr, ConstructorConversion, class B) 6: [B6.5] 7: [B6.6].operator bool 8: [B6.6] 9: [B6.8] (ImplicitCastExpr, UserDefinedConversion, _Bool) Preds (1): B7 Succs (1): B5 [B7] 1: x 2: [B7.1] (ImplicitCastExpr, LValueToRValue, int) 3: [B7.2] (CXXConstructExpr, [B7.4], [B7.6], class A) 4: [B7.3] (BindTemporary) 5: A([B7.4]) (CXXFunctionalCastExpr, ConstructorConversion, class A) 6: [B7.5] 7: [B7.6].operator bool 8: [B7.6] 9: [B7.8] (ImplicitCastExpr, UserDefinedConversion, _Bool) T: [B7.9] || ... Preds (1): B8 Succs (2): B5 B6 [B0 (EXIT)] Preds (2): B1 B2 -- 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 38641] clang miscompiles at -O2 and above on valid code
https://bugs.llvm.org/show_bug.cgi?id=38641 Michael Berg 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 38662] Merge r339091 into LLVM 7.0 release branch: Fix failing lit test shtest-format.py
https://bugs.llvm.org/show_bug.cgi?id=38662 Hans Wennborg changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED CC||h...@chromium.org --- Comment #1 from Hans Wennborg --- Merged in r340349 -- 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 38406] [meta] 7.0.0 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=38406 Bug 38406 depends on bug 38662, which changed state. Bug 38662 Summary: Merge r339091 into LLVM 7.0 release branch: Fix failing lit test shtest-format.py https://bugs.llvm.org/show_bug.cgi?id=38662 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 38406] [meta] 7.0.0 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=38406 Bug 38406 depends on bug 38660, which changed state. Bug 38660 Summary: Merge r340191 to 7.0 branch: [OPENMP] Fix crash on the emission of the weak function declaration. https://bugs.llvm.org/show_bug.cgi?id=38660 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 38660] Merge r340191 to 7.0 branch: [OPENMP] Fix crash on the emission of the weak function declaration.
https://bugs.llvm.org/show_bug.cgi?id=38660 Hans Wennborg changed: What|Removed |Added CC||h...@chromium.org Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Hans Wennborg --- Okay, r340351. -- 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 38623] Assertion in CodeGen fails when a reference to a global variable is captured by a block
https://bugs.llvm.org/show_bug.cgi?id=38623 Hans Wennborg changed: What|Removed |Added Resolution|--- |FIXED CC||h...@chromium.org Status|REOPENED|RESOLVED --- Comment #4 from Hans Wennborg --- Merged in r340352. -- 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 38406] [meta] 7.0.0 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=38406 Bug 38406 depends on bug 38623, which changed state. Bug 38623 Summary: Assertion in CodeGen fails when a reference to a global variable is captured by a block https://bugs.llvm.org/show_bug.cgi?id=38623 What|Removed |Added Status|REOPENED|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 38406] [meta] 7.0.0 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=38406 Bug 38406 depends on bug 38654, which changed state. Bug 38654 Summary: MultiSource/Benchmarks/DOE-ProxyApps-C++/CLAMP fails to build with newer libstdc++ https://bugs.llvm.org/show_bug.cgi?id=38654 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 38654] MultiSource/Benchmarks/DOE-ProxyApps-C++/CLAMP fails to build with newer libstdc++
https://bugs.llvm.org/show_bug.cgi?id=38654 Hans Wennborg changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED CC||h...@chromium.org --- Comment #3 from Hans Wennborg --- Merged to 7.0 in r340353. -- 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 33132] test-suite/ABI-Testsuite/test/mangling/test.cpp depends on dual c++11 ABI
https://bugs.llvm.org/show_bug.cgi?id=33132 Hans Wennborg changed: What|Removed |Added Status|NEW |RESOLVED CC||h...@chromium.org Resolution|--- |FIXED --- Comment #6 from Hans Wennborg --- Merged to 7.0 in r340354. -- 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 38406] [meta] 7.0.0 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=38406 Bug 38406 depends on bug 33132, which changed state. Bug 33132 Summary: test-suite/ABI-Testsuite/test/mangling/test.cpp depends on dual c++11 ABI https://bugs.llvm.org/show_bug.cgi?id=33132 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 38663] New: lld from llvm 6 crashes with stack overflow @CopyRewriter::getNewSource when doing PGO + LTO of Firefox
https://bugs.llvm.org/show_bug.cgi?id=38663 Bug ID: 38663 Summary: lld from llvm 6 crashes with stack overflow @CopyRewriter::getNewSource when doing PGO + LTO of Firefox Product: new-bugs Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: mh+l...@glandium.org CC: llvm-bugs@lists.llvm.org, sylves...@debian.org When building Firefox with clang 6, and enabling both PGO and LTO, the linker crashes on linux 64-bits with what appears to be an infinite recursion through CopyRewriter::getNewSource. After some bisecting, I found the following: - r322684 is the first revision that is broken on the release_60 branch. - that revision is a cherry pick of r322313 from trunk, which is similarly broken. - trunk was fixed by r322325, which, funnily enough, predates when r322313 was cherry-picked (and supposedly came with no functional change). I guess the release_60 branch is dead at this point, but if it's not, this should be addressed. This doesn't affect clang 7 (obviously, since r322325 fixed 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 38634] Merge r340158 to 7.0 branch: Add SVE System registers
https://bugs.llvm.org/show_bug.cgi?id=38634 Hans Wennborg changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED CC||h...@chromium.org --- Comment #1 from Hans Wennborg --- Merged to 7.0 in r340355. -- 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 38406] [meta] 7.0.0 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=38406 Bug 38406 depends on bug 38634, which changed state. Bug 38634 Summary: Merge r340158 to 7.0 branch: Add SVE System registers https://bugs.llvm.org/show_bug.cgi?id=38634 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 38608] Fragment variable size verification fails during LTO in presence of ODR violations
https://bugs.llvm.org/show_bug.cgi?id=38608 Reid Kleckner changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #8 from Reid Kleckner --- Oh, yeah, let's do that. I thought the fragment verifier error was newer than that. *** This bug has been marked as a duplicate of bug 24923 *** -- 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 38664] New: wasm32: Typo in wasm.memory.grow intrinsics opcode #
https://bugs.llvm.org/show_bug.cgi?id=38664 Bug ID: 38664 Summary: wasm32: Typo in wasm.memory.grow intrinsics opcode # Product: libraries Version: trunk Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: Backend: WebAssembly Assignee: unassignedb...@nondot.org Reporter: a...@crichton.co CC: dan433...@gmail.com, llvm-bugs@lists.llvm.org When using the `llvm.wasm.memory.grow.i32` intrinsics I've noticed that the resulting wasm file fails to run through `wasm2wat`, apparently because it's being codegened as the `memory.size` instruction (oh dear!). Upon looking at the various definitions [1] it looks like the grow intrinsic is defined with the 0x3f opcode (same as current_memory above), but it looks like 0x40 is needed instead? [1]: https://github.com/llvm-mirror/llvm/blob/5249baad0eaf2909da62f28252b05993263608f5/lib/Target/WebAssembly/WebAssemblyInstrMemory.td#L471-L492 -- 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 38406] [meta] 7.0.0 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=38406 Bug 38406 depends on bug 38649, which changed state. Bug 38649 Summary: multiply lowering of divide-by-constant of large immediates doesn't occur on haswell https://bugs.llvm.org/show_bug.cgi?id=38649 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 38649] multiply lowering of divide-by-constant of large immediates doesn't occur on haswell
https://bugs.llvm.org/show_bug.cgi?id=38649 Hans Wennborg changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED CC||h...@chromium.org --- Comment #4 from Hans Wennborg --- (In reply to Craig Topper from comment #3) > Fixed this specific case in r340303. > > This probably does exist in 7.0 Merged it in r340359. Thanks! -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 38665] New: __builtin_mul_overflow with mixed sign gives different results compared to GCC
https://bugs.llvm.org/show_bug.cgi?id=38665
Bug ID: 38665
Summary: __builtin_mul_overflow with mixed sign gives different
results compared to GCC
Product: clang
Version: 7.0
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: LLVM Codegen
Assignee: unassignedclangb...@nondot.org
Reporter: jo...@netbsd.org
CC: llvm-bugs@lists.llvm.org
Try to build:
#include
int f(size_t a, size_t b) {
ptrdiff_t x;
return __builtin_mul_overflow(a, b, &x);
}
with clang and gcc for x86_64.
(1) GCC seems to interpret this as uint64_t x uint64_t -> uint64_t
multiplication
(2) Clang seems to widen the types and goes for int128_t instead (__muloti4).
This difference in interpretation seems to break the memory overflow checks in
GNU m4.
--
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 38664] wasm32: Typo in wasm.memory.grow intrinsics opcode #
https://bugs.llvm.org/show_bug.cgi?id=38664 Heejin Ahn changed: What|Removed |Added CC||ahee...@gmail.com Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Heejin Ahn --- Oh dear! Fixed in https://reviews.llvm.org/rL340373. I think we don't really have many tests for instruction encodings and we should add them, but don't think this should be blocked on adding them. -- 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 38507] undefined symbol: __ubsan_handle_cfi_check_fail when linking a large rust project
https://bugs.llvm.org/show_bug.cgi?id=38507 Vlad Tsyrklevich changed: What|Removed |Added Resolution|--- |INVALID Status|NEW |RESOLVED --- Comment #4 from Vlad Tsyrklevich --- Closing this as it's not a bug, just a missing link parameter. -- 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 35914] lld needs to set the link timeStamp on Windows builds, probably to a hash of the binary
https://bugs.llvm.org/show_bug.cgi?id=35914 Nico Weber changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #30 from Nico Weber --- This is done. lld-link now defaults to writing timeStamp to the current time. There's /timestamp: to pass in a custom value (chromium uses that currently), and there's /Brepro to set it to a hash (but: issue 38429), and for chrome win7 appcompat complained when the hash interpreted as a time was in the distant past.) -- 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 38644] multimap::clear() missing exception specifier
https://bugs.llvm.org/show_bug.cgi?id=38644 Marshall Clow (home) changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Marshall Clow (home) --- Fixed in revision 340385. -- 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 38666] New: Replace pass by const reference with pass by value
https://bugs.llvm.org/show_bug.cgi?id=38666
Bug ID: 38666
Summary: Replace pass by const reference with pass by value
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Scalar Optimizations
Assignee: unassignedb...@nondot.org
Reporter: david.bolvan...@gmail.com
CC: llvm-bugs@lists.llvm.org
Example:
int f(const int &p) {
return p;
}
=>
int f_optimized(const int p) {
return p;
}
Idea: clone function to modify parameters(if external linkage; modify directly
if static one), modify callsites -> replace const references with copies if
sizeof(T) <= sizeof(T *).
Maybe a new opt pass or part of a current one (which one?) ?
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
