[llvm-bugs] [Bug 39815] PowerPC64: Code hits SEGV during PPCDAGToDAGISel pass
https://bugs.llvm.org/show_bug.cgi?id=39815 Zhang Kang changed: What|Removed |Added CC||shkzh...@cn.ibm.com Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #3 from Zhang Kang --- Should be fixed by rL350161:https://reviews.llvm.org/rL350161, thanks for reporting! -- 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 40184] New: Clang 8.0 SVN (up to 350161) crashed for building Notepad2 (https://github.com/zufuliu/notepad2) for ARM64 in Release configuration
https://bugs.llvm.org/show_bug.cgi?id=40184
Bug ID: 40184
Summary: Clang 8.0 SVN (up to 350161) crashed for building
Notepad2 (https://github.com/zufuliu/notepad2) for
ARM64 in Release configuration
Product: clang
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: C++
Assignee: unassignedclangb...@nondot.org
Reporter: zufu...@163.com
CC: blitzrak...@gmail.com, dgre...@apple.com,
erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org,
richard-l...@metafoo.co.uk
Created attachment 21280
--> https://bugs.llvm.org/attachment.cgi?id=21280&action=edit
Stacktrace for Clang svn 347735 and 350161
Step to Produce:
1. Install latest Visual Studio 2017 15.9.4 and Windows 10 SDK 10.0.17763.0
2. Install LLVM for Visual Studio from
https://github.com/zufuliu/llvm-utils/releases, using LLVM_VS2017.zip. This
MSBuild source code is very similar to source in
http://llvm.org/svn/llvm-project/llvm/trunk/tools/msbuild, except I added ARM64
support (and other small changes):
--target=aarch64-pc-windows-msvc $(ClangClAdditionalOptions)
%(AdditionalOptions)
3. Get source code for https://github.com/zufuliu/notepad2, Open
build\VS2017\Notepad2.sln, select LLVMDebug + ARM64 and LLVMRelease + ARM64 to
build both project, result:
LLVMDebug + ARM64 LLVMRelease + ARM64
metapathOK OK
Notepad2OK Clang Crashed for both c++17
and c++2a
Host Windows 10 x64 Pro 1803 v10.0.17134.472 on i5-4570.
Detail stacktrace ("/showFilenames -v" is added to LLVM -> Additional Compiler
Options) for c++2a (c++17 is very similar) is in attachment.
SVN r347735 from http://llvm.org/builds/:
1>Assertion failed:
Subtarget.isCallingConvWin64(MF.getFunction().getCallingConv()) && "Funclets
should only be present on Win64", file
C:\src\llvm_package_347735\llvm\lib\Target\AArch64\AArch64FrameLowering.cpp,
line 1506
Self build 350161 trunk:
1>Assertion failed: unsigned(ObjectIdx+NumFixedObjects) < Objects.size() &&
"Invalid Object Idx!", file
H:\llvm\llvm\include\llvm/CodeGen/MachineFrameInfo.h, line 489
--
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 40185] New: c11: Warning instead of error for missing type specifier.
https://bugs.llvm.org/show_bug.cgi?id=40185
Bug ID: 40185
Summary: c11: Warning instead of error for missing type
specifier.
Product: clang
Version: trunk
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: anders.granlun...@gmail.com
CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org,
neeil...@live.com, richard-l...@metafoo.co.uk
Test case (prog.c):
int main()
{
typedef t;
}
Compilation command line:
clang prog.c -Wall -Wextra -std=c11 -pedantic-errors
Observed behaviour:
The following warnings were outputed:
prog.c:3:13: warning: type specifier missing, defaults to 'int'
[-Wimplicit-int]
typedef t;
~~~ ^
prog.c:3:13: warning: unused typedef 't' [-Wunused-local-typedef]
2 warnings generated.
Expected behaviour:
The first warning should be an error instead since -pedantic-errors was
used.
Note:
GCC gives the expected 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] Issue 11234 in oss-fuzz: llvm/llvm-opt-fuzzer--x86_64-strength_reduce: Timeout in llvm_llvm-opt-fuzzer--x86_64-strength_reduce
Comment #4 on issue 11234 by ClusterFuzz-External: llvm/llvm-opt-fuzzer--x86_64-strength_reduce: Timeout in llvm_llvm-opt-fuzzer--x86_64-strength_reduce https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=11234#c4 ClusterFuzz has detected this issue as fixed in range 201812290409:201812300411. Detailed report: https://oss-fuzz.com/testcase?key=5743328872628224 Project: llvm Fuzzer: libFuzzer_llvm_llvm-opt-fuzzer--x86_64-strength_reduce Fuzz target binary: llvm-opt-fuzzer--x86_64-strength_reduce Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: Timeout (exceeds 25 secs) Crash Address: Crash State: llvm_llvm-opt-fuzzer--x86_64-strength_reduce Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201802210603:201802211531 Fixed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201812290409:201812300411 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5743328872628224 See https://github.com/google/oss-fuzz/blob/master/docs/reproducing.md for instructions to reproduce this bug locally. 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 11234 in oss-fuzz: llvm/llvm-opt-fuzzer--x86_64-strength_reduce: Timeout in llvm_llvm-opt-fuzzer--x86_64-strength_reduce
Updates: Labels: ClusterFuzz-Verified Status: Verified Comment #5 on issue 11234 by ClusterFuzz-External: llvm/llvm-opt-fuzzer--x86_64-strength_reduce: Timeout in llvm_llvm-opt-fuzzer--x86_64-strength_reduce https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=11234#c5 ClusterFuzz testcase 5743328872628224 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 40186] New: +sec not support for ARM
https://bugs.llvm.org/show_bug.cgi?id=40186 Bug ID: 40186 Summary: +sec not support for ARM Product: tools Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: llvm-as Assignee: unassignedb...@nondot.org Reporter: ste...@agner.ch CC: llvm-bugs@lists.llvm.org The Linux kernel uses -Wa,-march=armv7-a+sec to build code with secure monitor calls. When using the integrated assembler clang fails with: clang-8: error: the clang compiler does not support '-Wa,-march=armv7-a+sec' -- 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 40187] New: clang::DominatorTree::buildDominatorTree crashes for codes with infinite while loops
https://bugs.llvm.org/show_bug.cgi?id=40187
Bug ID: 40187
Summary: clang::DominatorTree::buildDominatorTree crashes for
codes with infinite while loops
Product: clang
Version: 7.0
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: aadi.n...@gmail.com
CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org,
neeil...@live.com, richard-l...@metafoo.co.uk
Created attachment 21281
--> https://bugs.llvm.org/attachment.cgi?id=21281&action=edit
A tar of the folder containing the RAV code as well as some test cases
The buildDominatorTree function gives a segmentation fault when trying to build
a dominator tree within a RecursiveASTVisitor Visit function for a code
containing an infinite loop (specifically where the condition is 1) like this
code-
int main() {
int x, y, z;
x = 10;
while(1) {
x++;
if(x == 100) {
break;
}
}
return 0;
}
Assigning the value 1 to a variable and using the variable as a condition does
not cause an issue-
int main() {
int x, y, z;
x = 10;
y = 1;
while(y) {
x++;
if(x == 100) {
break;
}
}
return 0;
}
The code for reproducing the error as well as the test cases are in the tar
file
Found when using Clang 7 and LLVM 7 installed from the Debian packages
--
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 12341 in oss-fuzz: llvm/llvm-dwarfdump-fuzzer: ASSERT: Arch != llvm::Triple::ArchType::UnknownArch
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-12-30 Type: Bug New issue 12341 by ClusterFuzz-External: llvm/llvm-dwarfdump-fuzzer: ASSERT: Arch != llvm::Triple::ArchType::UnknownArch https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=12341 Detailed report: https://oss-fuzz.com/testcase?key=5706904108531712 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: Arch != llvm::Triple::ArchType::UnknownArch llvm::dwarf::CallFrameString llvm::dwarf::CFIProgram::dump Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201812180233:201812190234 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5706904108531712 Issue filed automatically. See https://github.com/google/oss-fuzz/blob/master/docs/reproducing.md 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. -- 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 40188] New: [DebugInfo@O2] Bogus parameter value presented for struct argument
https://bugs.llvm.org/show_bug.cgi?id=40188
Bug ID: 40188
Summary: [DebugInfo@O2] Bogus parameter value presented for
struct argument
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: CONFIRMED
Keywords: wrong-debug
Severity: normal
Priority: P
Component: Scalar Optimizations
Assignee: unassignedb...@nondot.org
Reporter: jeremy.morse.l...@gmail.com
CC: chackz0...@gmail.com, dblai...@gmail.com,
greg.bedw...@sony.com,
international.phan...@gmail.com,
llvm-bugs@lists.llvm.org, paul.robin...@am.sony.com
Blocks: 38768
Using r350008 and the command line "clang-8 -O2 -g test.cpp -o a.out
-fno-inline", in the code below a bogus value is reported for the value of
'eyelids' when entering the 'foo' function. The code:
8<
struct bees {
int a;
int b;
};
int
foo(struct bees eyelids)
{
return eyelids.a + eyelids.b;
}
int
main()
{
struct bees xyzzy = { 1, 2 };
return foo(xyzzy);
}
>8
Gdbs interpretation on stepping into foo:
(gdb) frame
#0 foo (eyelids=...) at test.cpp:8
8 {
(gdb) print eyelids
$1 = {a = 1, b = 4195504}
Compiling with g++ 6.3 reports eyelids.b=2 at the same location. Examining
clangs output with llvm-dwarfdump, we generate the following expression for
"eyelids" for the body of "foo":
DW_OP_reg5 RDI, DW_OP_piece 0x4, DW_OP_reg0 RAX, DW_OP_piece 0x4
when the value of eyelids is actually only passed in rdi (upper and lower
portions). Compiling with g++ and -gstrict-dwarf correctly gives only
"DW_OP_reg5 RDI". The body of "foo" moves eyelids.b to eax initially, it
appears that the location of that fragment gets hoisted to cover the beginning
of the function, even when eax isn't def'd yet. I'm 95% confident the code that
does that is here [0], which appears to assume the first DBG_VALUE of a
parameter can have its location forwarded to the function start.
That assumption might have been valid given that there's code in SelectionDAG
[1] that emits DBG_VALUEs for parameters at the start of functions, although
for byvals only. Perhaps it used to produce entry DBG_VALUEs for every
parameter in the past?
There's a test in-tree that already exhibits this behaviour,
test/DebugInfo/ARM/partial-subreg.ll , which builds the 'self' parameter from
stack into registers over several instructions, but the location covers the
whole function, incorrectly. I ran into this problem when fiddling elsewhere,
the reproducer is to generalise the problem.
[0]
https://github.com/llvm-mirror/llvm/blob/6cd86b7cd2bb90a97d8a75196d6c0a4365c49a8b/lib/CodeGen/AsmPrinter/DebugHandlerBase.cpp#L219
[1]
https://github.com/llvm-mirror/llvm/blob/27f17bfee31bec92b918f4ca6a6f7a2a37e4d00c/lib/CodeGen/SelectionDAG/ScheduleDAGSDNodes.cpp#L818
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
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 40189] New: LLDB expressions always error if a C++ local variable is named after a keyword
https://bugs.llvm.org/show_bug.cgi?id=40189
Bug ID: 40189
Summary: LLDB expressions always error if a C++ local variable
is named after a keyword
Product: lldb
Version: 7.0
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: All Bugs
Assignee: lldb-...@lists.llvm.org
Reporter: jacobly@gmail.com
CC: llvm-bugs@lists.llvm.org
This is only triggered by the debug info produced by gcc, not by clang. It
seems that uses of e.g. __func__ and __PRETTY_FUNCTION__ cause gcc to emit
debug info for a local variable named after the corresponding keyword, where
clang does not emit anything. I have confirmed this happens with g++ 8.2.0 and
lldb 7.0.0, 7.0.1, and trunk.
Quick repro:
$ echo 'int main(int argc){__func__;}' | g++ -g -x c++ - && lldb -o 'br s -n
main' -o 'pr la' -o 'expr argc' a.out
which produces
error: expected unqualified-id
which occurs because of a syntax error on the line
using $__lldb_local_vars::__func__;
Note that C programs don't generate such using lines, and therefore don't
exhibit this bug. I encountered this bug while debugging llvm (accidentally
compiled with gcc) in any function that uses assert, e.g. compileModule in
tools/llc/llc.cpp.
I confirmed that a workaround is to add hardcoded exceptions to
AddLocalVariableDecls in tools/lldb/source/Expression/ExpressionSourceCode.cpp,
but I'm not sure if that is the correct way to fix this.
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 12346 in oss-fuzz: llvm/llvm-dwarfdump-fuzzer: ASSERT: (DebugLineData.getAddressSize() == 0 || DebugLineData.getAddressSize() == getAdd
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-12-31 Type: Bug New issue 12346 by ClusterFuzz-External: llvm/llvm-dwarfdump-fuzzer: ASSERT: (DebugLineData.getAddressSize() == 0 || DebugLineData.getAddressSize() == getAdd https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=12346 Detailed report: https://oss-fuzz.com/testcase?key=5719170266693632 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: (DebugLineData.getAddressSize() == 0 || DebugLineData.getAddressSize() == getAdd llvm::DWARFDebugLine::Prologue::parse llvm::DWARFDebugLine::LineTable::parse Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201708280446:201708291805 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5719170266693632 Issue filed automatically. See https://github.com/google/oss-fuzz/blob/master/docs/reproducing.md 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. -- 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
