[llvm-bugs] [Bug 51020] New: Assertion `AL->size() == ActualAccesses.size() && "We don't have the same number of accesses in the block as on the " "access list"' failed.
https://bugs.llvm.org/show_bug.cgi?id=51020 Bug ID: 51020 Summary: Assertion `AL->size() == ActualAccesses.size() && "We don't have the same number of accesses in the block as on the " "access list"' failed. Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: Loop Optimizer Assignee: unassignedb...@nondot.org Reporter: mikael.hol...@ericsson.com CC: llvm-bugs@lists.llvm.org Created attachment 25010 --> https://bugs.llvm.org/attachment.cgi?id=25010&action=edit bbi-57909.ll reproducer llvm commit: 21fd87595297 Reproduce with: opt -verify-memoryssa -passes='function(loop-mssa(loop-unroll-full))' bbi-57909.ll -o /dev/null Result: opt: ../lib/Analysis/MemorySSA.cpp:2020: void llvm::MemorySSA::verifyOrderingDominationAndDefUses(llvm::Function&) const: Assertion `AL->size() == ActualAccesses.size() && "We don't have the same number of accesses in the block as on the " "access list"' failed. This starts happening with 94c269baf58 [NewPM] Verify LoopAnalysisResults after a loop pass All loop passes should preserve all analyses in LoopAnalysisResults. Add checks for those. Note that due to PR44815, we don't check LAR's ScalarEvolution. Apparently calling SE.verify() can change its results. Only verify MSSA when VerifyMemorySSA, normally it's very expensive. Reviewed By: asbirlea Differential Revision: https://reviews.llvm.org/D98820 -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 15141] X86: Inefficient lowering of constant vector variable shl
https://bugs.llvm.org/show_bug.cgi?id=15141 Bug 15141 depends on bug 36319, which changed state. Bug 36319 Summary: [ValueTracking] Add DemandedElts support to computeKnownBits/ComputeNumSignBits https://bugs.llvm.org/show_bug.cgi?id=36319 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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 36319] [ValueTracking] Add DemandedElts support to computeKnownBits/ComputeNumSignBits
https://bugs.llvm.org/show_bug.cgi?id=36319 Simon Pilgrim changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Simon Pilgrim --- Resolving this - all the basic DemandedElts support is in place. As with SelectionDAG, we're only adding handling to specific instructions when we have real use cases + useful test coverage - e.g. bitcast handling in D104472/rG656001e7b2b9 to fix [Bug #50123]. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 40391] [X86] Use ValueTracking to convert x86-specific vector shifts to generics
https://bugs.llvm.org/show_bug.cgi?id=40391 Bug 40391 depends on bug 36319, which changed state. Bug 36319 Summary: [ValueTracking] Add DemandedElts support to computeKnownBits/ComputeNumSignBits https://bugs.llvm.org/show_bug.cgi?id=36319 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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 51021] New: Wrong code with throwing const function
https://bugs.llvm.org/show_bug.cgi?id=51021
Bug ID: 51021
Summary: Wrong code with throwing const function
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Keywords: miscompilation
Severity: normal
Priority: P
Component: C++
Assignee: unassignedclangb...@nondot.org
Reporter: har...@gigawatt.nl
CC: blitzrak...@gmail.com, dgre...@apple.com,
erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org,
richard-l...@metafoo.co.uk
The GCC developers have clarified that the function attributes const and pure
do not imply that the functions do not throw. clang does assume that and as
such miscompiles the following program:
__attribute__((const)) void f() {
throw 0;
}
int main() {
try {
f();
} catch(int i) {
return 0;
}
return 1;
}
This program should return 0, not 1.
Godbolt link: https://godbolt.org/z/jj1PG7o78
(Please ignore the warning emitted by GCC, 'const' attribute on function
returning 'void'; I have reported that as part of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101376.)
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 51022] New: [llvm-cov] wrong coverage for a return statement with ternary operator
https://bugs.llvm.org/show_bug.cgi?id=51022
Bug ID: 51022
Summary: [llvm-cov] wrong coverage for a return statement with
ternary operator
Product: Runtime Libraries
Version: 12.0
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: libprofile library
Assignee: unassignedb...@nondot.org
Reporter: byone.h...@gmail.com
CC: llvm-bugs@lists.llvm.org
$./clang -v
clang version 12.0.0 (https://github.com/llvm/llvm-project.git
b6c8feb29fce39121884f7e08ec6eb0f58da3fb7)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /home/x/project/llvm-project/build/install/bin/.
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/8
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7.5.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/8
Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7.5.0
Candidate multilib: .;@m64
Candidate multilib: 32;@m32
Candidate multilib: x32;@mx32
Selected multilib: .;@m64
$cat test.c
———
static volatile signed char true_var = 1;
static const volatile signed char false_var = 0;
extern void abort ();
int f(int x)
{
return (x >> (sizeof (x) * __CHAR_BIT__ - 1)) ? -1 : 1;
}
volatile int one = 1;
int main (void)
{
/* Test that the function above returns different values for
different signs. */
if (f(one) == f(-one))
abort ();
return 0;
}
——
$clang -O0 -g -fcoverage-mapping -fprofile-instr-generate=test.profraw test.c;
./a.out; llvm-profdata merge test.profraw -o test.profdata; llvm-cov show a.out
-instr-profile=test.profdata test.c > test.lcov; cat test.lcov
2| |static volatile signed char true_var = 1;
3| |static const volatile signed char false_var = 0;
4| |extern void abort ();
5| |
6| |int f(int x)
7| 2|{
8| 1| return (x >> (sizeof (x) * __CHAR_BIT__ - 1)) ? -1 : 1;
9| 2|}
10| |
11| |volatile int one = 1;
12| |int main (void)
13| 1|{
14| | /* Test that the function above returns different values for
15| | different signs. */
16| 1| if (f(one) == f(-one))
17| 0|abort ();
18| 1| return 0;
19| 1|}
20| |
Line 8 should be executed twice.
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 51023] New: [llvm-cov]
https://bugs.llvm.org/show_bug.cgi?id=51023
Bug ID: 51023
Summary: [llvm-cov]
Product: Runtime Libraries
Version: 12.0
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: libprofile library
Assignee: unassignedb...@nondot.org
Reporter: byone.h...@gmail.com
CC: llvm-bugs@lists.llvm.org
$./clang -v
clang version 12.0.0 (https://github.com/llvm/llvm-project.git
b6c8feb29fce39121884f7e08ec6eb0f58da3fb7)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /home/x/project/llvm-project/build/install/bin/.
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/8
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7.5.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/8
Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7.5.0
Candidate multilib: .;@m64
Candidate multilib: 32;@m32
Candidate multilib: x32;@mx32
Selected multilib: .;@m64
$cat test.c
———
const volatile unsigned char true_var = 1;
static unsigned short int false_var = 0;
int a = 2, b, c, d;
int
foo ()
{
for (;; c++)
if ((b > 0) | (a & 1))
;
else
{
d = a;
return 0;
}
}
int
main ()
{
foo ();
if (d != 2)
__builtin_abort ();
return 0;
——
$clang -O0 -g -fcoverage-mapping -fprofile-instr-generate=test.profraw test.c;
./a.out; llvm-profdata merge test.profraw -o test.profdata; llvm-cov show a.out
-instr-profile=test.profdata test.c > test.lcov; cat test.lcov
3| |const volatile unsigned char true_var = 1;
4| |static unsigned short int false_var = 0;
5| |
6| |int a = 2, b, c, d;
7| |
8| |int
9| |foo ()
10| 1|{
11| 0| for (;; c++)
12| 1|if ((b > 0) | (a & 1))
13| 0| ;
14| 1|else
15| 1| {
16| 1| d = a;
17| 1| return 0;
18| 1| }
19| 1|}
20| |
21| |int
22| |main ()
23| 1|{
24| 1| foo ();
25| 1| if (d != 2)
26| 0|__builtin_abort ();
27| 1| return 0;
28| 1|}
Line 11 should be executed once.
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 11001] Bug with zero shifts in DAGTypeLegalizer:: ExpandShiftWithUnknownAmountBit
https://bugs.llvm.org/show_bug.cgi?id=11001
Simon Pilgrim changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW |RESOLVED
CC||llvm-...@redking.me.uk
--- Comment #3 from Simon Pilgrim ---
Resolving very old bug - we have both getShiftAmountTyForConstant and
getShiftAmountTy for a while to prevent premature shift type truncation:
EVT TargetLoweringBase::getShiftAmountTy(EVT LHSTy, const DataLayout &DL,
bool LegalTypes) const {
assert(LHSTy.isInteger() && "Shift amount is not an integer type!");
if (LHSTy.isVector())
return LHSTy;
return LegalTypes ? getScalarShiftAmountTy(DL, LHSTy)
: getPointerTy(DL);
}
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 51024] New: [llvm-cov] a goto statement leads to incorrect coverage of the next statement
https://bugs.llvm.org/show_bug.cgi?id=51024
Bug ID: 51024
Summary: [llvm-cov] a goto statement leads to incorrect
coverage of the next statement
Product: Runtime Libraries
Version: 12.0
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: libprofile library
Assignee: unassignedb...@nondot.org
Reporter: byone.h...@gmail.com
CC: llvm-bugs@lists.llvm.org
$./clang -v
clang version 12.0.0 (https://github.com/llvm/llvm-project.git
b6c8feb29fce39121884f7e08ec6eb0f58da3fb7)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /home/x/project/llvm-project/build/install/bin/.
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/8
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7.5.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/8
Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7.5.0
Candidate multilib: .;@m64
Candidate multilib: 32;@m32
Candidate multilib: x32;@mx32
Selected multilib: .;@m64
$cat test.c
———
const signed char true_var = 1;
volatile unsigned char false_var = 0;
extern void abort (void);
struct S
{
int n1, n2, n3, n4;
};
__attribute__((noinline)) struct S
foo (int x, int y, int z)
{
if (x != 10 || y != 9 || z != 8)
abort ();
struct S s = { 1, 2, 3, 4 };
return s;
}
__attribute__((noinline)) void **
bar (void **u, int *v)
{
void **w = u;
int *s = v, x, y, z;
void **p, **q;
static void *l[] = { &&lab1, &&lab1, &&lab2, &&lab3, &&lab4 };
if (!u)
return l;
q = *w++;
goto *q;
lab2:
p = q;
q = *w++;
x = s[2];
y = s[1];
z = s[0];
s -= 1;
struct S r = foo (x, y, z);
s[3] = r.n1;
s[2] = r.n2;
s[1] = r.n3;
s[0] = r.n4;
goto *q;
if( true_var > 0 )
{
lab3:
p = q;
q = *w++;
s += 1;
}
s[0] = 23;
lab1:
goto *q;
lab4:
return 0;
}
int
main (void)
{
void **u = bar ((void **) 0, (int *) 0);
void *t[] = { u[2], u[4] };
int s[] = { 7, 8, 9, 10, 11, 12 };
if (bar (t, &s[1]) != (void **) 0
|| s[0] != 4 || s[1] != 3 || s[2] != 2 || s[3] != 1
|| s[4] != 11 || s[5] != 12)
abort ();
return 0;
}
——
$clang -O0 -g -fcoverage-mapping -fprofile-instr-generate=test.profraw test.c;
./a.out; llvm-profdata merge test.profraw -o test.profdata; llvm-cov show a.out
-instr-profile=test.profdata test.c > test.lcov; cat test.lcov
5| |const signed char true_var = 1;
6| |volatile unsigned char false_var = 0;
7| |
8| |extern void abort (void);
9| |
10| |struct S
11| |{
12| | int n1, n2, n3, n4;
13| |};
14| |
15| |__attribute__((noinline)) struct S
16| |foo (int x, int y, int z)
17| 1|{
18| 1| if (x != 10 || y != 9 || z != 8)
19| 0|abort ();
20| 1| struct S s = { 1, 2, 3, 4 };
21| 1| return s;
22| 1|}
23| |
24| |__attribute__((noinline)) void **
25| |bar (void **u, int *v)
26| 2|{
27| 2| void **w = u;
28| 2| int *s = v, x, y, z;
29| 2| void **p, **q;
30| 2| static void *l[] = { &&lab1, &&lab1, &&lab2, &&lab3, &&lab4 };
31| |
32| 2| if (!u)
33| 1|return l;
34| |
35| 1| q = *w++;
36| 1| goto *q;
37| 1|lab2:
38| 1| p = q;
39| 1| q = *w++;
40| 1| x = s[2];
41| 1| y = s[1];
42| 1| z = s[0];
43| 1| s -= 1;
44| 1| struct S r = foo (x, y, z);
45| 1| s[3] = r.n1;
46| 1| s[2] = r.n2;
47| 1| s[1] = r.n3;
48| 1| s[0] = r.n4;
49| 1| goto *q;
50| 1| if( true_var > 0 )
51| 0| {
52| 0| lab3:
53| 0| p = q;
54| 0| q = *w++;
55| 0| s += 1;
56| 0| }
57| 1| s[0] = 23;
58| 0|lab1:
59| 0| goto *q;
60| 1|lab4:
61| 1| return 0;
62| 0|}
63| |
64| |int
65| |main (void)
66| 1|{
67| 1| void **u = bar ((void **) 0, (int *) 0);
68| 1| void *t[] = { u[2], u[4] };
69| 1| int s[] = { 7, 8, 9, 10, 11, 12 };
70| 1| if (bar (t, &s[1]) != (void **) 0
71| 1| || s[0] != 4 || s[1] != 3 || s[2] != 2 || s[3] != 1
72| 1| || s[4] != 11 || s[5] != 12)
73| 0|abort ();
74| 1| return 0;
75| 1|}
Line 50 and 57 should not be executed.
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://li
[llvm-bugs] [Bug 51025] New: [llvm-cov] The function array causes wrong coverage
https://bugs.llvm.org/show_bug.cgi?id=51025
Bug ID: 51025
Summary: [llvm-cov] The function array causes wrong coverage
Product: Runtime Libraries
Version: 12.0
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: libprofile library
Assignee: unassignedb...@nondot.org
Reporter: byone.h...@gmail.com
CC: llvm-bugs@lists.llvm.org
$./clang -v
clang version 12.0.0 (https://github.com/llvm/llvm-project.git
b6c8feb29fce39121884f7e08ec6eb0f58da3fb7)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /home/x/project/llvm-project/build/install/bin/.
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/8
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7.5.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/8
Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7.5.0
Candidate multilib: .;@m64
Candidate multilib: 32;@m32
Candidate multilib: x32;@mx32
Selected multilib: .;@m64
$cat test.c
———
const volatile int true_var = 1;
static volatile unsigned int false_var = 0;
#define _GNU_SOURCE
#include
#include
#include
static int malloc_depth = 0;
static char memory[128* 1024];
static size_t memory_p = 0;
void f1(void) {}
void f2(void) {}
typedef void (*fun_t)(void);
static const fun_t funs[2] = { f1, f2, };
static void * malloc_impl(size_t size) {
void * r = &memory[memory_p];
/* The malloc() and calloc() functions return a pointer to the allocated
* memory, which is suitably aligned for any built-in type. Use 16
* bytes here as the basic alignment requirement for user-defined malloc
* and calloc. See PR97594 for the details. */
#define ROUND_UP_FOR_16B_ALIGNMENT(x) ((x + 15) & (-16))
memory_p += ROUND_UP_FOR_16B_ALIGNMENT(size);
// force TOPN profile
funs[size % 2]();
return r;
}
// Override default malloc, check it it get s called recursively
void * malloc(size_t size) {
// Must not be called recursively. Malloc implementation does not support
it.
if (malloc_depth != 0) __builtin_trap();
if( false_var > 0 )
{
++malloc_depth;
void * r = malloc_impl(size);
--malloc_depth;
return r;
}
++malloc_depth;
void * r = malloc_impl(size);
--malloc_depth;
return r;
}
// Called from gcov
void *calloc(size_t nmemb, size_t size) {
// Must not be called recursively. Malloc implementation does not support
it.
if (malloc_depth != 0) __builtin_trap();
++malloc_depth;
void * r = malloc_impl(size * nmemb);
memset(r, 0, size * nmemb);
--malloc_depth;
return r;
}
void free(void *ptr){}
int main() {
void * p = malloc(8);
return p != 0 ? 0 : 1;
}
——
$clang -O0 -g -fcoverage-mapping -fprofile-instr-generate=test.profraw test.c;
./a.out; llvm-profdata merge test.profraw -o test.profdata; llvm-cov show a.out
-instr-profile=test.profdata test.c > test.lcov; cat test.lcov
4| |const volatile int true_var = 1;
5| |static volatile unsigned int false_var = 0;
6| |
7| |#define _GNU_SOURCE
8| |
9| |#include
10| |#include
11| |#include
12| |
13| |static int malloc_depth = 0;
14| |
15| |static char memory[128* 1024];
16| |static size_t memory_p = 0;
17| |
18| 6|void f1(void) {}
19| 1|void f2(void) {}
20| |
21| |typedef void (*fun_t)(void);
22| |static const fun_t funs[2] = { f1, f2, };
23| |
24| 7|static void * malloc_impl(size_t size) {
25| 7|void * r = &memory[memory_p];
26| |/* The malloc() and calloc() functions return a pointer to
the allocated
27| | * memory, which is suitably aligned for any built-in type.
Use 16
28| | * bytes here as the basic alignment requirement for
user-defined malloc
29| | * and calloc. See PR97594 for the details. */
30| 7|#define ROUND_UP_FOR_16B_ALIGNMENT(x) ((x + 15) & (-16))
31| |
32| 7|memory_p += ROUND_UP_FOR_16B_ALIGNMENT(size);
33| |
34| |// force TOPN profile
35| 7|printf("%d\n",size%2);
36| 7|funs[size % 2]();
37| 7|return r;
38| 7|}
39| |
40| |// Override default malloc, check it it get s called recursively
41| 7|void * malloc(size_t size) {
42| |// Must not be called recursively. Malloc implementation does
not support it.
43| 7|if (malloc_depth != 0) __builtin_trap();
44| |
45| 7|if( false_var > 0 )
46| 0|{
47| 0|+
[llvm-bugs] Issue 35929 in oss-fuzz: llvm:clang-fuzzer: ASSERT: !Info.Ctx.getLangOpts().CPlusPlus11 && "missing temporary materialization conver
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevl...@apple.com, igm...@gmail.com, d...@google.com, mit...@google.com, bigch...@gmail.com, eney...@google.com, llvm-...@lists.llvm.org, j...@chromium.org, v...@apple.com, mitch...@outlook.com, xpl...@gmail.com, akils...@apple.com Labels: ClusterFuzz Reproducible Stability-Memory-MemorySanitizer Engine-libfuzzer OS-Linux Proj-llvm Reported-2021-07-08 Type: Bug New issue 35929 by ClusterFuzz-External: llvm:clang-fuzzer: ASSERT: !Info.Ctx.getLangOpts().CPlusPlus11 && "missing temporary materialization conver https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=35929 Detailed Report: https://oss-fuzz.com/testcase?key=572840251762 Project: llvm Fuzzing Engine: libFuzzer Fuzz Target: clang-fuzzer Job Type: libfuzzer_msan_llvm Platform Id: linux Crash Type: ASSERT Crash Address: Crash State: !Info.Ctx.getLangOpts().CPlusPlus11 && "missing temporary materialization conver clang::StmtVisitorBase::Visit clang::StmtVisitorBase::Visit Sanitizer: memory (MSAN) Crash Revision: https://oss-fuzz.com/revisions?job=libfuzzer_msan_llvm&revision=202011180625 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=572840251762 Issue filed automatically. See https://google.github.io/oss-fuzz/advanced-topics/reproducing for instructions to reproduce this bug locally. 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. Comments on individual Monorail issues are not monitored. -- 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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 35928 in oss-fuzz: llvm:clang-fuzzer: ASSERT: CachedTokens[CachedLexPos-1].getLastLoc() == Tok.getAnnotationEndLoc() && "The a
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevl...@apple.com, igm...@gmail.com, d...@google.com, mit...@google.com, bigch...@gmail.com, eney...@google.com, llvm-...@lists.llvm.org, j...@chromium.org, v...@apple.com, mitch...@outlook.com, xpl...@gmail.com, akils...@apple.com Labels: ClusterFuzz Stability-Memory-AddressSanitizer Reproducible Engine-libfuzzer OS-Linux Proj-llvm Reported-2021-07-08 Type: Bug New issue 35928 by ClusterFuzz-External: llvm:clang-fuzzer: ASSERT: CachedTokens[CachedLexPos-1].getLastLoc() == Tok.getAnnotationEndLoc() && "The a https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=35928 Detailed Report: https://oss-fuzz.com/testcase?key=5646250320330752 Project: llvm Fuzzing Engine: libFuzzer Fuzz Target: clang-fuzzer Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: ASSERT Crash Address: Crash State: CachedTokens[CachedLexPos-1].getLastLoc() == Tok.getAnnotationEndLoc() && "The a clang::Preprocessor::AnnotatePreviousCachedTokens clang::Parser::TryAnnotateTypeOrScopeTokenAfterScopeSpec Sanitizer: address (ASAN) Crash Revision: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&revision=201901220414 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5646250320330752 Issue filed automatically. See https://google.github.io/oss-fuzz/advanced-topics/reproducing for instructions to reproduce this bug locally. 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. Comments on individual Monorail issues are not monitored. -- 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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 51026] New: clang on s390x: crashes in '@_ZN4llvm18CodeGenDAGPatterns17ParseInstructionsEv'
https://bugs.llvm.org/show_bug.cgi?id=51026 Bug ID: 51026 Summary: clang on s390x: crashes in '@_ZN4llvm18CodeGenDAGPatterns17ParseInstructionsEv' Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: release blocker Priority: P Component: Backend: SystemZ Assignee: unassignedb...@nondot.org Reporter: sylves...@debian.org CC: llvm-bugs@lists.llvm.org Seems that it happened in this commit: https://github.com/llvm/llvm-project/compare/64be5b7d8713..f1cbea3e5275 Maybe caused by? https://github.com/llvm/llvm-project/commit/37a92f3b03bf165245a9d0dc4830dcc6fed7c253 PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash backtrace, preprocessed source, and associated run script. Stack dump: 0. Program arguments: /build/llvm-toolchain-snapshot-13~++20210708091416+511af1b1ad00/build-llvm/./bin/clang++ -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -I/build/llvm-toolchain-snapshot-13~++20210708091416+511af1b1ad00/build-llvm/tools/clang/stage2-bins/utils/TableGen -I/build/llvm-toolchain-snapshot-13~++20210708091416+511af1b1ad00/llvm/utils/TableGen -I/build/llvm-toolchain-snapshot-13~++20210708091416+511af1b1ad00/build-llvm/tools/clang/stage2-bins/include -I/build/llvm-toolchain-snapshot-13~++20210708091416+511af1b1ad00/llvm/include -fuse-ld=gold -fPIC -Wno-unused-command-line-argument -Wno-unknown-warning-option -fPIC -fno-semantic-interposition -fvisibility-inlines-hidden -Werror=date-time -Werror=unguarded-availability-new -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic -Wno-long-long -Wc++98-compat-extra-semi -Wimplicit-fallthrough -Wcovered-switch-default -Wno-class-memaccess -Wno-noexcept-type -Wnon-virtual-dtor -Wdelete-non-virtual-dtor -Wsuggest-override -Wstring-conversion -Wmisleading-indentation -ffunction-sections -fdata-sections -O2 -DNDEBUG -g1 -fno-exceptions -std=c++14 -o CMakeFiles/obj.llvm-tblgen.dir/CodeGenDAGPatterns.cpp.o -c /build/llvm-toolchain-snapshot-13~++20210708091416+511af1b1ad00/llvm/utils/TableGen/CodeGenDAGPatterns.cpp 1. parser at end of file 2. Code generation 3. Running pass 'Function Pass Manager' on module '/build/llvm-toolchain-snapshot-13~++20210708091416+511af1b1ad00/llvm/utils/TableGen/CodeGenDAGPatterns.cpp'. 4. Running pass 'Live Variable Analysis' on function '@_ZN4llvm18CodeGenDAGPatterns17ParseInstructionsEv' Stack dump without symbol names (ensure you have llvm-symbolizer in your PATH or set the environment var `LLVM_SYMBOLIZER_PATH` to point to it): /build/llvm-toolchain-snapshot-13~++20210708091416+511af1b1ad00/build-llvm/bin/../lib/libLLVM-13.so.1(_ZN4llvm3sys15PrintStackTraceERNS_11raw_ostreamEi+0x38)[0x3ff9848f688] /build/llvm-toolchain-snapshot-13~++20210708091416+511af1b1ad00/build-llvm/bin/../lib/libLLVM-13.so.1(_ZN4llvm3sys17RunSignalHandlersEv+0x36)[0x3ff9848d8c6] /build/llvm-toolchain-snapshot-13~++20210708091416+511af1b1ad00/build-llvm/bin/../lib/libLLVM-13.so.1(_ZN4llvm3sys15CleanupOnSignalEm+0x152)[0x3ff9848e0b2] /build/llvm-toolchain-snapshot-13~++20210708091416+511af1b1ad00/build-llvm/bin/../lib/libLLVM-13.so.1(+0xd2fa28)[0x3ff983afa28] [0x3fffe477196] /build/llvm-toolchain-snapshot-13~++20210708091416+511af1b1ad00/build-llvm/bin/../lib/libLLVM-13.so.1(_ZN4llvm13LiveVariables10runOnBlockEPNS_17MachineBasicBlockEj+0x2f6)[0x3ff9882a386] /build/llvm-toolchain-snapshot-13~++20210708091416+511af1b1ad00/build-llvm/bin/../lib/libLLVM-13.so.1(_ZN4llvm13LiveVariables20runOnMachineFunctionERNS_15MachineFunctionE+0x3c4)[0x3ff9882b6e4] /build/llvm-toolchain-snapshot-13~++20210708091416+511af1b1ad00/build-llvm/bin/../lib/libLLVM-13.so.1(+0x1230702)[0x3ff988b0702] /build/llvm-toolchain-snapshot-13~++20210708091416+511af1b1ad00/build-llvm/bin/../lib/libLLVM-13.so.1(_ZN4llvm13FPPassManager13runOnFunctionERNS_8FunctionE+0x3ae)[0x3ff985f4a5e] /build/llvm-toolchain-snapshot-13~++20210708091416+511af1b1ad00/build-llvm/bin/../lib/libLLVM-13.so.1(_ZN4llvm13FPPassManager11runOnModuleERNS_6ModuleE+0x38)[0x3ff985f4c80] /build/llvm-toolchain-snapshot-13~++20210708091416+511af1b1ad00/build-llvm/bin/../lib/libLLVM-13.so.1(_ZN4llvm6legacy15PassManagerImpl3runERNS_6ModuleE+0x40c)[0x3ff985f601c] /build/llvm-toolchain-snapshot-13~++20210708091416+511af1b1ad00/build-llvm/bin/../lib/libclang-cpp.so.13(+0x1ad260c)[0x3ff9fed260c] /build/llvm-toolchain-snapshot-13~++20210708091416+511af1b1ad00/build-llvm/bin/../lib/libclang-cpp.so.13(_ZN5clang17EmitBackendOutputERNS_17DiagnosticsEngineERKNS_19HeaderSearchOptionsERKNS_14CodeGenOptionsERKNS_13TargetOptionsERKNS_11LangOptionsEN4llvm9StringRefEPNSE_6ModuleENS_13BackendActionESt10unique_ptrINSE_17raw_pwrite_streamESt14default_deleteISK_EE+0xcdc)[0x3ff9fed689c] /build/llvm-toolchain-snapshot-13~++20210708091416+511af1b1a
[llvm-bugs] [Bug 51027] New: False-positives from scan-build clang 12
https://bugs.llvm.org/show_bug.cgi?id=51027
Bug ID: 51027
Summary: False-positives from scan-build clang 12
Product: clang
Version: 12.0
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: C
Assignee: unassignedclangb...@nondot.org
Reporter: jorge_go...@hotmail.com
CC: blitzrak...@gmail.com, dgre...@apple.com,
erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org,
richard-l...@metafoo.co.uk
I used scan-build with clang 12 and I believe that has a lots of
"false-positive".
The problem is with operator &.
Simplified example:
int main(void) {
int v;
foo(&v);
printf("v=%d\n", v); /* clang reports uninitialized var used here */
}
Of course, that code analyzed is more complex.
But I think that code that analyze the operator &, need be revised.
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
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 51028] New: Constant firstprivate argument in target region not passed correctly to parallel region
https://bugs.llvm.org/show_bug.cgi?id=51028
Bug ID: 51028
Summary: Constant firstprivate argument in target region not
passed correctly to parallel region
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: OpenMP
Assignee: a.bat...@hotmail.com
Reporter: hube...@ornl.gov
CC: llvm-bugs@lists.llvm.org
Any constant non-scalar data type that is mapped firstprivate into a target
region will not be correctly copied to the parallel region if executing in
generic mode. This regression was caused by D105375. Here is a small
reproducer.
#include
#include
void foo(const std::complex X, std::complex Y) {
#pragma omp target firstprivate(X) map(from:Y)
{
printf ("Outside parallel: %f + %fi\n", X.real(), X.imag());
#pragma omp parallel firstprivate(X)
{
printf ("Inside parallel: %f + %fi\n", X.real(), X.imag());
Y = X;
}
}
}
int main() {
std::complex X = {1.0, 1.0};
std::complex Y;
foo(X, Y);
}
Outside parallel: 1.00 + 1.00i
Inside parallel: 0.00 + 0.00i
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 51029] New: -Wfatal-errors does not immediately abort compilation on the first error occurred (clang incorrectly keeps compiling the rest of the code)
https://bugs.llvm.org/show_bug.cgi?id=51029 Bug ID: 51029 Summary: -Wfatal-errors does not immediately abort compilation on the first error occurred (clang incorrectly keeps compiling the rest of the code) Product: clang Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: Frontend Assignee: unassignedclangb...@nondot.org Reporter: pavel.moroz...@gmail.com CC: llvm-bugs@lists.llvm.org, neeil...@live.com, richard-l...@metafoo.co.uk Note: This bug is not a duplicate of https://bugs.llvm.org/show_bug.cgi?id=7918. Invocation: $ clang t0.c -Wfatal-errors t0.c:773:11: fatal error: use of undeclared identifier 'xxx' Expected behavior: compilation is aborted immediately (clang stops compiling the rest of the code) Actual behavior: compilation is not aborted immediately (clang keeps compiling the rest of the code) Version: 12.0.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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 27686 in oss-fuzz: llvm: Fuzzing build failure
Comment #37 on issue 27686 by ClusterFuzz-External: llvm: Fuzzing build failure https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=27686#c37 Friendly reminder that the the build is still failing. Please try to fix this failure to ensure that fuzzing remains productive. Latest build log: https://oss-fuzz-build-logs.storage.googleapis.com/log-cb8382a0-2a24-4fee-a603-99e5bb488830.txt -- 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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 49210] Fuse v128.load64_zero + iXX.widen_low into Load-and-Extend
https://bugs.llvm.org/show_bug.cgi?id=49210
Thomas Lively changed:
What|Removed |Added
Resolution|--- |WORKSFORME
Status|NEW |RESOLVED
--- Comment #1 from Thomas Lively ---
This C file:
```
#include
__m128i fused(__m128i* ptr) {
return _mm_cvtepi16_epi32(_mm_loadl_epi64(ptr));
}
```
compiled with:
`emcc -msse4.1 -msimd128 fused.c -O2 -c -S -o -`
Produces this assembly, as expected:
```
fused: # @fused
.functype fused (i32) -> (v128)
# %bb.0:# %entry
local.get 0
i32x4.load16x4_s0:p2align=0
# fallthrough-return
end_function
```
Via this LLVM IR:
```
; ModuleID = '/usr/local/google/home/tlively/code/llvm-local/fused.c'
source_filename = "/usr/local/google/home/tlively/code/llvm-local/fused.c"
target datalayout = "e-m:e-p:32:32-i64:64-n32:64-S128-ni:1"
target triple = "wasm32-unknown-emscripten"
; Function Attrs: nofree norecurse nosync nounwind readonly willreturn
mustprogress
define hidden <4 x i32> @fused(<4 x i32>* nocapture readonly %ptr)
local_unnamed_addr #0 {
entry:
%0 = bitcast <4 x i32>* %ptr to <4 x i16>*
%1 = load <4 x i16>, <4 x i16>* %0, align 1, !tbaa !2
%conv.i.i.i = sext <4 x i16> %1 to <4 x i32>
ret <4 x i32> %conv.i.i.i
}
attributes #0 = { nofree norecurse nosync nounwind readonly willreturn
mustprogress "frame-pointer"="none" "min-legal-vector-width"="128"
"no-trapping-math"="true" "stack-protector-buffer-size"="8"
"target-cpu"="generic" "target-features"="+simd128" }
!llvm.module.flags = !{!0}
!llvm.ident = !{!1}
!0 = !{i32 1, !"wchar_size", i32 4}
!1 = !{!"clang version 13.0.0 (https://github.com/llvm/llvm-project
9b0ddc2662addaa563b632c577996e515e1a7802)"}
!2 = !{!3, !3, i64 0}
!3 = !{!"omnipotent char", !4, i64 0}
!4 = !{!"Simple C/C++ TBAA"}
```
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 48855] Assertion failed: !cast(GD.getDecl())->isConsteval() && "consteval function should never be emitted", file clang\lib\CodeGen\CodeGenModule.cpp, line 3530
https://bugs.llvm.org/show_bug.cgi?id=48855 Matheus Izvekov changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #3 from Matheus Izvekov --- This was fixed by https://github.com/llvm/llvm-project/commit/5a1c50410ccc1973a1a0a4acca0c01677c28e9b6 -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 51031] New: MapImported: Assertion `(Pos == ImportedDecls.end() || Pos->second == To) && "Try to import an already imported Decl"' failed.
https://bugs.llvm.org/show_bug.cgi?id=51031
Bug ID: 51031
Summary: MapImported: Assertion `(Pos == ImportedDecls.end() ||
Pos->second == To) && "Try to import an already
imported Decl"' failed.
Product: lldb
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: All Bugs
Assignee: lldb-...@lists.llvm.org
Reporter: peeter.j...@lzlabs.com
CC: jdevliegh...@apple.com, llvm-bugs@lists.llvm.org
attempting to drill into some global variable state:
lhe.h extern SYSBLK *sysblk;
sysblk.c SYSBLK *sysblk;
I hit the following MapImported assertion:
(lldb) p &sysblk->regs[0]
lldb: /home/pjoot/chirag/llvm-project/clang/lib/AST/ASTImporter.cpp:9444:
clang::Decl* clang::ASTImporter::MapImported(clang::Decl*, clang::Decl*):
Assertion `(Pos == ImportedDecls.end() || Pos->second == To) && "Try to import
an already imported Decl"' failed.
PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash
backtrace.
Stack dump:
0. Program arguments: /opt/lzlabs/lldb/bin/lldb -o "b main" -o "settings
set target.hide-invalid-legacy-frames false" -o "b rc_pli_enter_module" -o "b
LAE_dump" -o "b print_message" -o "b rc_pli_fatal_error" -o "b
__lz_runtime_init" -o "b __lz_runtime_term" --source
/opt/lzlabs/debug/lldb/macros/myLLDBinit -o "settings set target.charset
ibm-1047" -o "settings append target.source-map
/home/markus/git/raincode/RComp/installers/rpm/rpmbuild/BUILD/lz-sdm-compilers/llvm/runtime/src
/home/pjoot/rpmbuild/BUILD/lz-sdm-compilers/llvm/runtime/src" -o "settings
append target.source-map
/home/markus/git/raincode/RComp/installers/rpm/rpmbuild/BUILD/lz-sdm-compilers/llvm/runtime
/home/pjoot/rpmbuild/BUILD/lz-sdm-compilers/llvm/runtime" -o "settings append
target.source-map
/home/markus/git/raincode/lzlabs/RComp/installers/rpm/rpmbuild/BUILD/lz-sdm-compilers/llvm/runtime
/home/pjoot/rpmbuild/BUILD/lz-sdm-compilers/llvm/runtime" /usr/bin/lz_batch --
--debug -j tmp/jcl8553E.jcl
1. HandleCommand(command = "p &sysblk->regs[0]")
2. :2:1: current parser token ';'
3. :21162:1: parsing function body '$__lldb_expr'
4. :21162:1: in compound statement ('{}')
#0 0x7f2bb184747c llvm::sys::PrintStackTrace(llvm::raw_ostream&, int)
(/opt/lzlabs/lldb/lib64/libLLVMSupport.so.13git+0x19647c)
#1 0x7f2bb1845474 llvm::sys::RunSignalHandlers()
(/opt/lzlabs/lldb/lib64/libLLVMSupport.so.13git+0x194474)
#2 0x7f2bb1845c0d SignalHandler(int)
(/opt/lzlabs/lldb/lib64/libLLVMSupport.so.13git+0x194c0d)
#3 0x7f2bb2e7bb20 __restore_rt sigaction.c:0:0
#4 0x7f2bb09f437f raise (/lib64/libc.so.6+0x3737f)
#5 0x7f2bb09dedb5 abort (/lib64/libc.so.6+0x21db5)
#6 0x7f2bb09dec89 _nl_load_domain.cold.0 loadmsgcat.c:0:0
#7 0x7f2bb09eca76 .annobin___GI___assert_fail.end assert.c:0:0
#8 0x7f2ba9414150 clang::ASTImporter::MapImported(clang::Decl*,
clang::Decl*) (/opt/lzlabs/lldb/lib64/libclangAST.so.13git+0x1d8150)
#9 0x7f2ba9436a2a
clang::ASTNodeImporter::VisitTypedefNameDecl(clang::TypedefNameDecl*, bool)
(/opt/lzlabs/lldb/lib64/libclangAST.so.13git+0x1faa2a)
#10 0x7f2ba9455b4a clang::declvisitor::Base >::Visit(clang::Decl*)
(/opt/lzlabs/lldb/lib64/libclangAST.so.13git+0x219b4a)
#11 0x7f2ba9455cb7 clang::ASTImporter::ImportImpl(clang::Decl*)
(/opt/lzlabs/lldb/lib64/libclangAST.so.13git+0x219cb7)
#12 0x7f2bb26e392c
lldb_private::ClangASTImporter::ASTImporterDelegate::ImportImpl(clang::Decl*)
(/opt/lzlabs/lldb/lib64/liblldb.so.13git+0xc1992c)
#13 0x7f2ba94175f3 clang::ASTImporter::Import(clang::Decl*)
(/opt/lzlabs/lldb/lib64/libclangAST.so.13git+0x1db5f3)
#14 0x7f2ba941a654
clang::ASTNodeImporter::VisitTypedefType(clang::TypedefType const*)
(/opt/lzlabs/lldb/lib64/libclangAST.so.13git+0x1de654)
#15 0x7f2ba9420235 clang::TypeVisitor >::Visit(clang::Type const*)
(/opt/lzlabs/lldb/lib64/libclangAST.so.13git+0x1e4235)
#16 0x7f2ba9420447 clang::ASTImporter::Import(clang::Type const*)
(/opt/lzlabs/lldb/lib64/libclangAST.so.13git+0x1e4447)
#17 0x7f2ba94206b7 clang::ASTImporter::Import(clang::QualType)
(/opt/lzlabs/lldb/lib64/libclangAST.so.13git+0x1e46b7)
#18 0x7f2ba942dbf0
clang::ASTNodeImporter::VisitFunctionProtoType(clang::FunctionProtoType const*)
(/opt/lzlabs/lldb/lib64/libclangAST.so.13git+0x1f1bf0)
#19 0x7f2ba9420215 clang::TypeVisitor >::Visit(clang::Type const*)
(/opt/lzlabs/lldb/lib64/libclangAST.so.13git+0x1e4215)
#20 0x7f2ba9420447 clang::ASTImporter::Import(clang::Type const*)
(/opt/lzlabs/lldb/lib64/libclangAST.so.13git+0x1e4447)
#21 0x7f2ba94206b7 clang::ASTImporter::Import(clang::QualType)
(/opt/lzlabs/lldb/lib64/libclangAST.so.13git+0x1e46b7)
#22 0x7f2bb26dea10
lldb_private::ClangASTImporter::CopyType(lldb_private::TypeSystemClang&,
lldb_private::CompilerType const&)
(/opt/lzlabs/lldb/l
[llvm-bugs] [Bug 51032] New: C++20 lambdas in unevaluated context: crash on valid code
https://bugs.llvm.org/show_bug.cgi?id=51032
Bug ID: 51032
Summary: C++20 lambdas in unevaluated context: crash on valid
code
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: C++2a
Assignee: unassignedclangb...@nondot.org
Reporter: janpmoel...@gmx.de
CC: blitzrak...@gmail.com, erik.pilking...@gmail.com,
llvm-bugs@lists.llvm.org, richard-l...@metafoo.co.uk
clang (trunk) crashes on the following valid c++20 program:
///
template
struct foo_t {
foo_t(T ptr) {}
};
template
using alias = foo_t;
template
auto fun(T const& t) -> alias {
return alias{t};
}
int main() {
int i;
auto const error = fun(i);
}
///
PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash
backtrace, preprocessed source, and associated run script.
Stack dump:
0. Program arguments: /opt/compiler-explorer/clang-trunk/bin/clang++ -g -o
/app/output.s -mllvm --x86-asm-syntax=intel -S
--gcc-toolchain=/opt/compiler-explorer/gcc-snapshot -fcolor-diagnostics
-fno-crash-diagnostics --std=c++20
1. parser at end of file
2. :14:5: LLVM IR generation of declaration 'main'
3. :14:5: Generating code for declaration 'main'
#0 0x55bedd4185cf PrintStackTraceSignalHandler(void*) Signals.cpp:0:0
#1 0x55bedd4164c0 llvm::sys::CleanupOnSignal(unsigned long)
(/opt/compiler-explorer/clang-trunk/bin/clang+++0x33664c0)
#2 0x55bedd36abe8 CrashRecoverySignalHandler(int)
CrashRecoveryContext.cpp:0:0
#3 0x7fb1c17453c0 __restore_rt
(/lib/x86_64-linux-gnu/libpthread.so.0+0x153c0)
#4 0x55bedfc0547c clang::ASTContext::getTypeInfoImpl(clang::Type const*)
const (/opt/compiler-explorer/clang-trunk/bin/clang+++0x5b5547c)
#5 0x55bedfbf886d clang::ASTContext::getTypeInfo(clang::Type const*) const
(/opt/compiler-explorer/clang-trunk/bin/clang+++0x5b4886d)
#6 0x55bedfc0426b clang::ASTContext::getPreferredTypeAlign(clang::Type
const*) const (/opt/compiler-explorer/clang-trunk/bin/clang+++0x5b5426b)
#7 0x55bedfc066bb clang::ASTContext::getDeclAlign(clang::Decl const*,
bool) const (/opt/compiler-explorer/clang-trunk/bin/clang+++0x5b566bb)
#8 0x55bedd9c6505
clang::CodeGen::CodeGenFunction::EmitAutoVarAlloca(clang::VarDecl const&)
(/opt/compiler-explorer/clang-trunk/bin/clang+++0x3916505)
#9 0x55bedd9c727a
clang::CodeGen::CodeGenFunction::EmitVarDecl(clang::VarDecl const&)
(/opt/compiler-explorer/clang-trunk/bin/clang+++0x391727a)
#10 0x55bedd9c757d clang::CodeGen::CodeGenFunction::EmitDecl(clang::Decl
const&) (/opt/compiler-explorer/clang-trunk/bin/clang+++0x391757d)
#11 0x55bedd73f327
clang::CodeGen::CodeGenFunction::EmitDeclStmt(clang::DeclStmt const&)
(/opt/compiler-explorer/clang-trunk/bin/clang+++0x368f327)
#12 0x55bedd74eaf5
clang::CodeGen::CodeGenFunction::EmitSimpleStmt(clang::Stmt const*,
llvm::ArrayRef)
(/opt/compiler-explorer/clang-trunk/bin/clang+++0x369eaf5)
#13 0x55bedd7493e2 clang::CodeGen::CodeGenFunction::EmitStmt(clang::Stmt
const*, llvm::ArrayRef)
(/opt/compiler-explorer/clang-trunk/bin/clang+++0x36993e2)
#14 0x55bedd74e60c
clang::CodeGen::CodeGenFunction::EmitCompoundStmtWithoutScope(clang::CompoundStmt
const&, bool, clang::CodeGen::AggValueSlot)
(/opt/compiler-explorer/clang-trunk/bin/clang+++0x369e60c)
#15 0x55bedd79b101
clang::CodeGen::CodeGenFunction::EmitFunctionBody(clang::Stmt const*)
(/opt/compiler-explorer/clang-trunk/bin/clang+++0x36eb101)
#16 0x55bedd7a3a17
clang::CodeGen::CodeGenFunction::GenerateCode(clang::GlobalDecl,
llvm::Function*, clang::CodeGen::CGFunctionInfo const&)
(/opt/compiler-explorer/clang-trunk/bin/clang+++0x36f3a17)
#17 0x55bedd7e8ffe
clang::CodeGen::CodeGenModule::EmitGlobalFunctionDefinition(clang::GlobalDecl,
llvm::GlobalValue*) (/opt/compiler-explorer/clang-trunk/bin/clang+++0x3738ffe)
#18 0x55bedd7e5e25
clang::CodeGen::CodeGenModule::EmitGlobalDefinition(clang::GlobalDecl,
llvm::GlobalValue*) (/opt/compiler-explorer/clang-trunk/bin/clang+++0x3735e25)
#19 0x55bedd7e652b
clang::CodeGen::CodeGenModule::EmitGlobal(clang::GlobalDecl)
(/opt/compiler-explorer/clang-trunk/bin/clang+++0x373652b)
#20 0x55bedd7ec101
clang::CodeGen::CodeGenModule::EmitTopLevelDecl(clang::Decl*) (.part.5273)
CodeGenModule.cpp:0:0
#21 0x55bede34be51 (anonymous
namespace)::CodeGeneratorImpl::HandleTopLevelDecl(clang::DeclGroupRef)
ModuleBuilder.cpp:0:0
#22 0x55bede33fc42
clang::BackendConsumer::HandleTopLevelDecl(clang::DeclGroupRef)
(/opt/compiler-explorer/clang-trunk/bin/clang+++0x428fc42)
#23 0x55bedf19f1c4 clang::ParseAST(clang::Sema&, bool, bool)
(/opt/compiler-explorer/clang-trunk/bin/clang+++0x50ef1c4)
#24 0x0
[llvm-bugs] [Bug 51033] New: [DebugInfo] Poor support for x87 variable locations
https://bugs.llvm.org/show_bug.cgi?id=51033 Bug ID: 51033 Summary: [DebugInfo] Poor support for x87 variable locations Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Keywords: wrong-debug Severity: enhancement Priority: P Component: Common Code Generator Code Assignee: unassignedb...@nondot.org Reporter: jeremy.morse.l...@gmail.com CC: llvm-bugs@lists.llvm.org Blocks: 38768 Observed over in https://reviews.llvm.org/D105657 , both our current variable location implementation and the instruction referencing stuff I've been working on are unable to cope with x87 variable locations. Both are unable to actually express where in registers variable values go. The root cause is the baroqueness of x87 itself: it refers to registers as a stack, rather than just naming them directly. If we had a DBG_VALUE that referred to $st(1), we might need to issue additional DBG_VALUEs as the stack position of the value changed due to other FP instructions. It's a significant pain in the neck, and VarLoc LiveDebugValues doesn't try to solve it. InstrRef LiveDebugValues doesn't try either. I suspect that interest in this matter is low (what with i386 processors being out of fashion for at least a decade) but thought I'd open the ticket in case there's something out there who this is relevant to. Referenced Bugs: https://bugs.llvm.org/show_bug.cgi?id=38768 [Bug 38768] [meta][DebugInfo] Umbrella bug for poor debug experiences -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 50840] MSan use-of-uninitialized-value false positive after D88834
https://bugs.llvm.org/show_bug.cgi?id=50840 Vitaly Buka 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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 51034] New: Unable to call K&R declared function with float arguments in debugger after 6c9559b67b91966bfeff9e17808a3e84a92e64a0
https://bugs.llvm.org/show_bug.cgi?id=51034
Bug ID: 51034
Summary: Unable to call K&R declared function with float
arguments in debugger after
6c9559b67b91966bfeff9e17808a3e84a92e64a0
Product: new-bugs
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: douglas_y...@playstation.sony.com
CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org
Internally we run the GDB test suite and a couple of tests in there started
failing recently which I bisected to commit
6c9559b67b91966bfeff9e17808a3e84a92e64a0. The root of the problem seems to be
that after 6c9559b67, when trying to invoke a function from a debugging session
in gdb, if the function was declared in a K&R style, it does not seem to pass
float arguments to the function being called.
For example, consider the following code:
/* test.c */
#include
#define DELTA (0.001)
float float_val1 = 3.14159;
float float_val2 = -2.3765;
int t_float_values (float_arg1, float_arg2)
float float_arg1, float_arg2;
{
printf("float_arg1 = %f, float_arg2 = %f\n", float_arg1, float_arg2);
return ((float_arg1 - float_val1) < DELTA
&& (float_arg1 - float_val1) > -DELTA
&& (float_arg2 - float_val2) < DELTA
&& (float_arg2 - float_val2) > -DELTA);
}
int foo1() {
return t_float_values(3.14159,-2.3765);
}
int main(int argc, char *argv[]) {
return foo1();
}
/* test.c */
If you compile that code with debug information and then debug the binary using
gdb with the following commands, you can see the problem:
1. b main
2. r
3. p foo1()
4. p t_float_values(3.14159,-2.3765)
The return value of the commands in 3 and 4 should be the same. When test.c is
compiled with a compiler prior to 6c9559b67, that is indeed the case. But if
compiled with a compiler that includes 6c9559b67, the return value of 4 is 0
instead of 1 like it should be. Additionally, from the printf() statement, you
can see that the values of float_arg1 and float_arg2 are not being passed into
the function when it is invoked in 4.
GDB session using binary built by a "good" compiler:
Reading symbols from test.good.elf...
(gdb) b main
Breakpoint 1 at 0x401266: file test.c, line 23.
(gdb) r
Starting program: /home/dyung/sandbox/gdb/test.good.elf
Breakpoint 1, main (argc=1, argv=0x7fffe458) at test.c:23
23return foo1();
(gdb) p foo1()
float_arg1 = 3.141590, float_arg2 = -2.376500
$1 = 1
(gdb) p t_float_values(3.14159,-2.3765)
float_arg1 = 3.141590, float_arg2 = -2.376500
$2 = 1
GDB session using binary built by a "bad" compiler:
Reading symbols from test.bad.elf...
(gdb) b main
Breakpoint 1 at 0x401266: file test.c, line 23.
(gdb) r
Starting program: /home/dyung/sandbox/gdb/test.bad.elf
Breakpoint 1, main (argc=1, argv=0x7fffe458) at test.c:23
23return foo1();
(gdb) p foo1()
float_arg1 = 3.141590, float_arg2 = -2.376500
$1 = 1
(gdb) p t_float_values(3.14159,-2.3765)
float_arg1 = 0.00, float_arg2 = 0.00
$2 = 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
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 33492] [coroutines] Clang emits duplicate debug information for 'this' variable
https://bugs.llvm.org/show_bug.cgi?id=33492 Chuanqi Xu changed: What|Removed |Added CC||yedeng...@linux.alibaba.com Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Chuanqi Xu --- This problem should be fixed at https://reviews.llvm.org/D97533. And I confirmed that the reproducer wouldn't crash on trunk. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
