[llvm-bugs] Issue 6883 in oss-fuzz: llvm/llvm-isel-fuzzer--x86_64-O2: ASSERT: (OptimizedDiv.getOpcode() != ISD::UDIVREM) && (OptimizedDiv.getOpcode() != ISD::
Comment #2 on issue 6883 by ClusterFuzz-External: llvm/llvm-isel-fuzzer--x86_64-O2: ASSERT: (OptimizedDiv.getOpcode() != ISD::UDIVREM) && (OptimizedDiv.getOpcode() != ISD:: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=6883#c2 ClusterFuzz has detected this issue as fixed in range 201803130518:201803140522. Detailed report: https://oss-fuzz.com/testcase?key=5229179646771200 Project: llvm Fuzzer: libFuzzer_llvm_llvm-isel-fuzzer--x86_64-O2 Fuzz target binary: llvm-isel-fuzzer--x86_64-O2 Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: ASSERT Crash Address: Crash State: (OptimizedDiv.getOpcode() != ISD::UDIVREM) && (OptimizedDiv.getOpcode() != ISD:: DAGCombiner::visit DAGCombiner::combine Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201801040618:201801050611 Fixed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201803130518:201803140522 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5229179646771200 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 6883 in oss-fuzz: llvm/llvm-isel-fuzzer--x86_64-O2: ASSERT: (OptimizedDiv.getOpcode() != ISD::UDIVREM) && (OptimizedDiv.getOpcode() != ISD::
Updates: Labels: ClusterFuzz-Verified Status: Verified Comment #3 on issue 6883 by ClusterFuzz-External: llvm/llvm-isel-fuzzer--x86_64-O2: ASSERT: (OptimizedDiv.getOpcode() != ISD::UDIVREM) && (OptimizedDiv.getOpcode() != ISD:: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=6883#c3 ClusterFuzz testcase 5229179646771200 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 36537] LLD can create GNU hash section with 0 buckets (incompatible with Android)
https://bugs.llvm.org/show_bug.cgi?id=36537 George Rimar changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from George Rimar --- r327481 -- 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 35740] lld crash
https://bugs.llvm.org/show_bug.cgi?id=35740 George Rimar changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from George Rimar --- r324463 -- 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 36687] Defective out-of-tree builds with LLVM_LINK_LLVM_DYLIB=ON
https://bugs.llvm.org/show_bug.cgi?id=36687 lab...@google.com changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #4 from lab...@google.com --- Should be fixed as of r327490. Remember that you need to set LLVM_LINK_LLVM_DYLIB also for the standalone lldb build. -- 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 36722] New: clang-format-6.0 ignores AlignConsecutiveDeclarations and AlignConsecutiveAssignments for section of code
https://bugs.llvm.org/show_bug.cgi?id=36722
Bug ID: 36722
Summary: clang-format-6.0 ignores AlignConsecutiveDeclarations
and AlignConsecutiveAssignments for section of code
Product: clang
Version: 6.0
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Formatter
Assignee: unassignedclangb...@nondot.org
Reporter: l...@derickrethans.nl
CC: djas...@google.com, kli...@google.com,
llvm-bugs@lists.llvm.org
Created attachment 20058
--> https://bugs.llvm.org/attachment.cgi?id=20058&action=edit
Original file
The attached file "bson.c", when processed with the attached clang-format file
".clang-format", produces the following diff (also attached):
--- bson.c 2018-03-14 11:24:38.895642438 +
+++ bson.c.formatted2018-03-14 11:24:49.051771534 +
@@ -29,13 +29,13 @@
#else
{
HashPosition pos;
- zval** property;
+ zval** property;
for (i = 0; i < 10; i++) {
- char* string_key = NULL;
- uint string_key_len = 0;
- ulong num_key= 0;
- zend_class_entry* map_ce = NULL;
+ char* string_key = NULL;
+ uint string_key_len = 0;
+ ulong num_key = 0;
+ zend_class_entry* map_ce = NULL;
php_phongo_bson_typemap_types map_type;
}
}
This only seems to happen due to some interaction with the code in the
php_phongo_bson_visit_binary function, and only for the #else block. If I
remove the surrounding { .. }, it works as expected. This is of course a
trimmed down version of the function.
--
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 36555] _GLOBAL_OFFSET_TABLE_ does not point to the beginning of .got.plt
https://bugs.llvm.org/show_bug.cgi?id=36555 Peter Smith changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #13 from Peter Smith --- Committed D44259 as r327248. Some follow up work will be needed for non x86 targets to implement Target::writeGotPltHeader() to put the value of _DYNAMIC into _GLOBAL_OFFSET_TABLE[0] as and when they need 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 36723] New: Invalid code generation from SIMD intrinsics when function is inlined
https://bugs.llvm.org/show_bug.cgi?id=36723 Bug ID: 36723 Summary: Invalid code generation from SIMD intrinsics when function is inlined Product: clang Version: 4.0 Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: -New Bugs Assignee: unassignedclangb...@nondot.org Reporter: sylvain.laper...@scality.com CC: llvm-bugs@lists.llvm.org Created attachment 20061 --> https://bugs.llvm.org/attachment.cgi?id=20061&action=edit testcase Hi, The attached code is not compiled correctly by Clang 4.x when the code is inlined. To reproduce the issue, the code code can be compiled with: clang++ -std=c++11 -O2 -msse4.1 -o testcase testcase.cpp Then, it can be ran with ./testcase 25532 0 I had to pass the values on the command-line, otherwise everything is computed at compile-time :D, and with no optimisation enabled the bug doesn't occurs. The code seems "undefined behavior"-free, but I may have missed something. Valgrind and `-fsanitize=undefined` don't complains. The function sub_test is correctly compiled (checked with objdump): 00400990 <_Z8sub_testooj>: 400990: 66 41 0f 6e c0 movd %r8d,%xmm0 400995: 66 0f 70 c0 00 pshufd $0x0,%xmm0,%xmm0 40099a: 66 48 0f 6e ce movq %rsi,%xmm1 40099f: 66 48 0f 6e d7 movq %rdi,%xmm2 4009a4: 66 0f 6c d1 punpcklqdq %xmm1,%xmm2 4009a8: 66 48 0f 6e c9 movq %rcx,%xmm1 4009ad: 66 48 0f 6e da movq %rdx,%xmm3 4009b2: 66 0f 6c d9 punpcklqdq %xmm1,%xmm3 4009b6: 66 0f 6f cb movdqa %xmm3,%xmm1 4009ba: 66 0f 66 ca pcmpgtd %xmm2,%xmm1 4009be: 66 0f db c8 pand %xmm0,%xmm1 4009c2: 66 0f fa d3 psubd %xmm3,%xmm2 4009c6: 66 0f fe d1 paddd %xmm1,%xmm2 4009ca: 66 48 0f 7e d0 movq %xmm2,%rax 4009cf: 66 48 0f 3a 16 d2 01pextrq $0x1,%xmm2,%rdx 4009d6: c3 retq 4009d7: 66 0f 1f 84 00 00 00nopw 0x0(%rax,%rax,1) 4009de: 00 00 *BUT* when the function is inlined (in main), the code becomes buggy: […] 400af3: 66 48 0f 6e c0 movq %rax,%xmm0 400af8: 66 48 0f 6e ca movq %rdx,%xmm1 400afd: 66 0f 6c c8 punpcklqdq %xmm0,%xmm1 400b01: 66 48 0f 6e c1 movq %rcx,%xmm0 400b06: 66 48 0f 6e d6 movq %rsi,%xmm2 400b0b: 66 0f 6c d0 punpcklqdq %xmm0,%xmm2 400b0f: 66 0f 6f c2 movdqa %xmm2,%xmm0 400b13: 66 0f 66 c1 pcmpgtd %xmm1,%xmm0 400b17: 66 0f 72 d0 1f psrld $0x1f,%xmm0 400b1c: 66 0f fa ca psubd %xmm2,%xmm1 400b20: 66 0f fe c8 paddd %xmm0,%xmm1 400b24: 66 48 0f 7e c8 movq %xmm1,%rax 400b29: 66 48 0f 3a 16 c9 01pextrq $0x1,%xmm1,%rcx […] The `pand` (corresponding to `_mm_and_si128`) is replaced by a `psrld` (just after the `pcmpgtd`) The bug was first encountered on MacOS with the following version of Clang % g++ --version Configured with: --prefix=/Library/Developer/CommandLineTools/usr --with-gxx-include-dir=/usr/include/c++/4.2.1 Apple LLVM version 9.0.0 (clang-900.0.39.2) Target: x86_64-apple-darwin16.7.0 Thread model: posix InstalledDir: /Library/Developer/CommandLineTools/usr/bin Which correspond to Clang 4.0.3 according to https://en.wikipedia.org/wiki/Xcode#Latest_versions I was able to reproduce it on Ubuntu 14.04, using the Clang 4.0 from "deb http://apt.llvm.org/trusty/ llvm-toolchain-trusty-4.0 main" % clang++ --version clang version 4.0.1-svn305264-1~exp1 (branches/release_40) Target: x86_64-unknown-linux-gnu Thread model: posix InstalledDir: /usr/bin Note that the generated code is correct with Clang 3.4 (tested on Ubuntu 14.04) % clang++ --version Ubuntu clang version 3.4-1ubuntu3 (tags/RELEASE_34/final) (based on LLVM 3.4) Target: x86_64-pc-linux-gnu Thread model: posix No problem as well with Clang 5.0 (tested on Archlinux) % clang++ --version clang version 5.0.1 (tags/RELEASE_501/final) Target: x86_64-unknown-linux-gnu Thread model: posix InstalledDir: /usr/bin So this seems specific to the 4.x branch. I don't know the policy (do bugs get fixed in the 4.x branch or is "upgrade your compiler" the official fix?) so I report it just in case. -- 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://list
[llvm-bugs] [Bug 36724] New: [UBSan/Win] Linker fails on code that uses int64_t multiplication in 32 bit build
https://bugs.llvm.org/show_bug.cgi?id=36724
Bug ID: 36724
Summary: [UBSan/Win] Linker fails on code that uses int64_t
multiplication in 32 bit build
Product: compiler-rt
Version: 6.0
Hardware: PC
OS: Windows NT
Status: NEW
Severity: normal
Priority: P
Component: compiler-rt
Assignee: unassignedb...@nondot.org
Reporter: markus.maier...@gmail.com
CC: llvm-bugs@lists.llvm.org
* MSVC2015 32 Bit
* LLVM/Clang 6.0.0 with official installer, bin folder added to PATH
* Host OS: Windows 10 1703 x64
The following code fails to link with clang-cl when building with
-fsanitize=undefined:
__
// file main.cpp
#include
#include
using namespace std;
int main()
{
int64_t test = 1;
test *= 1000;
cout << "1 * 1000 = " << test << endl;
return 0;
}
__
When changing int64_t to uint64_t, the code builds and runs as expected.
My build commands with "VS2015 x86 Native tools command prompt" including
output:
c:\build>clang-cl -fsanitize=undefined -v main.cpp
clang version 6.0.0 (tags/RELEASE_600/final)
Target: i686-pc-windows-msvc
Thread model: posix
InstalledDir: C:\Program Files (x86)\LLVM\bin
"C:\\Program Files (x86)\\LLVM\\bin\\clang-cl.exe" -cc1 -triple
i686-pc-windows-msvc19.0.24215 -emit-obj -mrelax-all
-mincremental-linker-compatible -disable-free -disable-llvm-verifier
-discard-value-names -main-file-name main.cpp -mrelocation-model static
-mthread-model posix -mdisable-fp-elim -relaxed-aliasing -fmath-errno
-masm-verbose -mconstructor-aliases -target-cpu pentium4 -D_MT
-flto-visibility-public-std --dependent-lib=libcmt --dependent-lib=oldnames
-stack-protector 2 -fms-volatile -fdiagnostics-format msvc -dwarf-column-info
-debugger-tuning=gdb -v -resource-dir "C:\\Program Files
(x86)\\LLVM\\lib\\clang\\6.0.0" -internal-isystem "C:\\Program Files
(x86)\\LLVM\\lib\\clang\\6.0.0\\include" -internal-isystem "C:\\Program Files
(x86)\\Microsoft Visual Studio 14.0\\VC\\INCLUDE" -internal-isystem
"C:\\Program Files (x86)\\Microsoft Visual Studio 14.0\\VC\\ATLMFC\\INCLUDE"
-internal-isystem "C:\\Program Files (x86)\\Windows
Kits\\10\\include\\10.0.10240.0\\ucrt" -internal-isystem "C:\\Program Files
(x86)\\Windows Kits\\NETFXSDK\\4.6.1\\include\\um" -internal-isystem
"C:\\Program Files (x86)\\Windows Kits\\8.1\\includeshared"
-internal-isystem "C:\\Program Files (x86)\\Windows Kits\\8.1\\includeum"
-internal-isystem "C:\\Program Files (x86)\\Windows
Kits\\8.1\\includewinrt" -fdeprecated-macro -fdebug-compilation-dir
"c:\\build" -ferror-limit 19 -fmessage-length 120 "--dependent-lib=C:\\Program
Files
(x86)\\LLVM\\lib\\clang\\6.0.0\\lib\\windows\\clang_rt.ubsan_standalone-i386.lib"
"--dependent-lib=C:\\Program Files
(x86)\\LLVM\\lib\\clang\\6.0.0\\lib\\windows\\clang_rt.ubsan_standalone_cxx-i386.lib"
-fsanitize=alignment,array-bounds,bool,builtin,enum,float-cast-overflow,float-divide-by-zero,integer-divide-by-zero,nonnull-attribute,null,pointer-overflow,return,returns-nonnull-attribute,shift-base,shift-exponent,signed-integer-overflow,unreachable,vla-bound
-fsanitize-recover=alignment,array-bounds,bool,builtin,enum,float-cast-overflow,float-divide-by-zero,integer-divide-by-zero,nonnull-attribute,null,pointer-overflow,returns-nonnull-attribute,shift-base,shift-exponent,signed-integer-overflow,vla-bound
-fno-use-cxa-atexit -fms-extensions -fms-compatibility
-fms-compatibility-version=19.0.24215 -std=c++14 -fdelayed-template-parsing
-fobjc-runtime=gcc -fdiagnostics-show-option -fcolor-diagnostics -o
"C:\\Users\\m2_maier\\AppData\\Local\\Temp\\main-366977.obj" -x c++ main.cpp
clang -cc1 version 6.0.0 based upon LLVM 6.0.0 default target
i686-pc-windows-msvc
#include "..." search starts here:
#include <...> search starts here:
C:\Program Files (x86)\LLVM\lib\clang\6.0.0\include
C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\INCLUDE
C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\ATLMFC\INCLUDE
C:\Program Files (x86)\Windows Kits\10\include\10.0.10240.0\ucrt
C:\Program Files (x86)\Windows Kits\NETFXSDK\4.6.1\include\um
C:\Program Files (x86)\Windows Kits\8.1\include\\shared
C:\Program Files (x86)\Windows Kits\8.1\include\\um
C:\Program Files (x86)\Windows Kits\8.1\include\\winrt
End of search list.
"C:\\Program Files (x86)\\Microsoft Visual Studio 14.0\\VC\\bin\\link.exe"
-out:main.exe -nologo
"C:\\Users\\markus\\AppData\\Local\\Temp\\main-366977.obj"
Creating library main.lib and object main.exp
main-366977.obj : error LNK2019: unresolved external symbol ___mulodi4
referenced in function _main
main.exe : fatal error LNK1120: 1 unresolved externals
clang-cl.exe: error: linker command failed with exit code 1120 (use -v to see
invocation)
c:\build>
--
You are receiving this mail because:
You are on the CC list for the bug.
[llvm-bugs] [Bug 36725] New: Evaluate Intel X86 register-register move scheduling info
https://bugs.llvm.org/show_bug.cgi?id=36725 Bug ID: 36725 Summary: Evaluate Intel X86 register-register move scheduling info Product: new-bugs Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: cour...@google.com CC: llvm-bugs@lists.llvm.org -- 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 36726] New: [X86][SSE] Split gpr/vector WriteMove, WriteLoad, WriteStore scheduler classes
https://bugs.llvm.org/show_bug.cgi?id=36726 Bug ID: 36726 Summary: [X86][SSE] Split gpr/vector WriteMove, WriteLoad, WriteStore scheduler classes 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: llvm-bugs@lists.llvm.org Blocks: 32325 We currently use WriteMove, WriteLoad, WriteStore for x86 gpr, vector and mask registers. These need to be split to better account for differences in behaviour without requiring full overloading of the scheduling of individual instructions. Referenced Bugs: https://bugs.llvm.org/show_bug.cgi?id=32325 [Bug 32325] [META][X86] Improve implementation and use of X86 scheduler models -- 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 36727] New: Add support for R_AARCH64_TLSLE_LDST8_TPREL_LO12 relocation.
https://bugs.llvm.org/show_bug.cgi?id=36727 Bug ID: 36727 Summary: Add support for R_AARCH64_TLSLE_LDST8_TPREL_LO12 relocation. Product: lld Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: ELF Assignee: unassignedb...@nondot.org Reporter: peter.sm...@linaro.org CC: llvm-bugs@lists.llvm.org In https://reviews.llvm.org/D44355 an attempt was made to fold the sequence: mrs x1, TPIDR_EL0 add x2, x1, :tprel_hi12:local_exec_var add x3, x2, :tprel_lo12_nc:local_exec_var ldr w0, [x3] to: mrs x1, TPIDR_EL0 add x2, x1, :tprel_hi12:local_exec_var ldr w0, [x2, :tprel_lo12_nc:local_exec_var] Which unfortunately had to be reverted for ELF because no ELF linker supported the R_AARCH64_TLSLE_LDST8_TPREL_LO12 relocation that is needed for: ldr w0, [x2, :tprel_lo12_nc:local_exec_var]. Existing ELF linkers only implement R_AARCH64_TLSLE_ADD_TPREL_LO12_NC to support add x3, x2, :tprel_lo12_nc:local_exec_var It would be nice to implement this relocation to eventually enable this relaxation to be done for ELF targets. This will take some time as support will need to be added to the binutils linkers as well. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 36728] New: Assertion failed: (!ParamType.hasQualifiers() && "non-type template parameter type cannot be qualified")
https://bugs.llvm.org/show_bug.cgi?id=36728
Bug ID: 36728
Summary: Assertion failed: (!ParamType.hasQualifiers() &&
"non-type template parameter type cannot be
qualified")
Product: clang
Version: 6.0
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: C++
Assignee: unassignedclangb...@nondot.org
Reporter: bren...@wolfram.com
CC: dgre...@apple.com, llvm-bugs@lists.llvm.org
This triggers an assert in clang:
template
struct helper {
static constexpr T value = helper::value * data;
};
Assertion failed: (!ParamType.hasQualifiers() && "non-type template parameter
type cannot be qualified"), function CheckTemplateArgument, file
/Users/brenton/llvm-development/llvm60/llvm/tools/clang/lib/Sema/SemaTemplate.cpp,
line 6023.
0 libLLVM.dylib0x000119c2558c
llvm::sys::PrintStackTrace(llvm::raw_ostream&) + 60
1 libLLVM.dylib0x000119c25b59
PrintStackTraceSignalHandler(void*) + 25
2 libLLVM.dylib0x000119c21619 llvm::sys::RunSignalHandlers() +
425
3 libLLVM.dylib0x000119c25ed2 SignalHandler(int) + 354
4 libsystem_platform.dylib 0x7fffc8f89b3a _sigtramp + 26
5 clang-6.00x0001097a06aa
clang::ConcreteTypeLoc::getNextTypeLoc() const + 42
6 libsystem_c.dylib0x7fffc8e0e420 abort + 129
7 libsystem_c.dylib0x7fffc8dd5893 basename_r + 0
8 clang-6.00x00010859da0a
clang::Sema::CheckTemplateArgument(clang::NonTypeTemplateParmDecl*,
clang::QualType, clang::Expr*, clang::TemplateArgument&,
clang::Sema::CheckTemplateArgumentKind) + 1210
9 clang-6.00x0001085b3efa
clang::Sema::CheckTemplateArgument(clang::NamedDecl*,
clang::TemplateArgumentLoc&, clang::NamedDecl*, clang::SourceLocation,
clang::SourceLocation, unsigned int,
llvm::SmallVectorImpl&,
clang::Sema::CheckTemplateArgumentKind) + 1274
10 clang-6.00x0001085a9c94
clang::Sema::CheckTemplateArgumentList(clang::TemplateDecl*,
clang::SourceLocation, clang::TemplateArgumentListInfo&, bool,
llvm::SmallVectorImpl&, bool) + 1316
11 clang-6.00x0001085a8051
clang::Sema::CheckTemplateIdType(clang::TemplateName, clang::SourceLocation,
clang::TemplateArgumentListInfo&) + 737
12 clang-6.00x000107c4769f
clang::Sema::ActOnCXXNestedNameSpecifier(clang::Scope*, clang::CXXScopeSpec&,
clang::SourceLocation, clang::OpaquePtr,
clang::SourceLocation, clang::SourceLocation,
llvm::MutableArrayRef, clang::SourceLocation,
clang::SourceLocation, bool) + 1839
13 clang-6.00x00010779c772
clang::Parser::ParseOptionalCXXScopeSpecifier(clang::CXXScopeSpec&,
clang::OpaquePtr, bool, bool*, bool, clang::IdentifierInfo**,
bool) + 3954
14 clang-6.00x000107829662
clang::Parser::TryAnnotateTypeOrScopeToken() + 2610
15 clang-6.00x00010778ca46
clang::Parser::ParseCastExpression(bool, bool, bool&,
clang::Parser::TypeCastState, bool) + 14582
16 clang-6.00x000107786975
clang::Parser::ParseCastExpression(bool, bool, clang::Parser::TypeCastState,
bool) + 101
17 clang-6.00x000107784df3
clang::Parser::ParseAssignmentExpression(clang::Parser::TypeCastState) + 243
18 clang-6.00x000107769510
clang::Parser::ParseInitializer() + 64
19 clang-6.00x0001077693a5
clang::Parser::ParseCXXMemberInitializer(clang::Decl*, bool,
clang::SourceLocation&) + 853
20 clang-6.00x000107767ff4
clang::Parser::ParseCXXClassMemberDeclaration(clang::AccessSpecifier,
clang::AttributeList*, clang::Parser::ParsedTemplateInfo const&,
clang::ParsingDeclRAIIObject*) + 7652
21 clang-6.00x000107769d95
clang::Parser::ParseCXXClassMemberDeclarationWithPragmas(clang::AccessSpecifier&,
clang::Parser::ParsedAttributesWithRange&, clang::TypeSpecifierType,
clang::Decl*) + 2021
22 clang-6.00x00010776358a
clang::Parser::ParseCXXMemberSpecification(clang::SourceLocation,
clang::SourceLocation, clang::Parser::ParsedAttributesWithRange&, unsigned int,
clang::Decl*) + 4042
23 clang-6.00x000107760d34
clang::Parser::ParseClassSpecifier(clang::tok::TokenKind,
clang::SourceLocation, clang::DeclSpec&, clang::Parser::ParsedTemplateInfo
const&, clang::AccessSpecifier, bool, clang::Parser::DeclSpecContext,
clang::Parser::ParsedAttributesWithRange&) + 12036
24 clang-6.00x00010773b6bd
clang::Parser::ParseDeclarationSpecifiers(clang::DeclSpec&,
clang::Parser::ParsedTemplateInfo const&, clang::AccessSpecifier,
clang::Parser::DeclSpecContext, clang::Parser::LateParsedAttrList*) + 13789
25 clang-6.00x00010780d940
clang::Parser::ParseSingleDeclarationAfterTemplate(clang::DeclaratorContext,
clang::Parser:
[llvm-bugs] [Bug 36252] [AMDGPU][MC][CODEGEN] Incorrect definition of GATHER4 opcodes
https://bugs.llvm.org/show_bug.cgi?id=36252 Dmitry changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Dmitry --- Closed by commit rL327278: http://llvm.org/viewvc/llvm-project?rev=327278&view=rev -- 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 36729] New: Chromium miscompile after r326991
https://bugs.llvm.org/show_bug.cgi?id=36729
Bug ID: 36729
Summary: Chromium miscompile after r326991
Product: new-bugs
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: h...@chromium.org
CC: craig.top...@gmail.com, llvm-bugs@lists.llvm.org
I don't fully understand the root cause here, but this what I've got so far.
After r326991, a large unit test in the Chromium Fuchsia port started failing.
The way this test runs is complicated (runs in some sort of emulated
environment) and I'm not familiar with it, so I'm not sure exactly what's going
wrong. I think something is crashing, but it's hard to tell from the logs.
(Example failed build here:
https://ci.chromium.org/buildbot/tryserver.chromium.linux/fuchsia_x64/86148)
Luckily, there's only a single function whose machine code changes after
r326991: Skia's grayA_to_rgbA_portable. I've verified that if I put
__attribute__((optnone)) on that, the tests pass.
Here's a mostly stand-alone repro to show the difference:
#include
static void grayA_to_rgbA_portable(uint32_t dst[], const void* vsrc, int count)
{
const uint8_t* src = (const uint8_t*)vsrc;
for (int i = 0; i < count; i++) {
uint8_t g = src[0],
a = src[1];
src += 2;
g = (g*a+127)/255;
dst[i] = (uint32_t)a << 24
| (uint32_t)g << 16
| (uint32_t)g << 8
| (uint32_t)g << 0;
}
}
void grayA_to_rgbA(uint32_t dst[], const void* src, int count) {
grayA_to_rgbA_portable(dst, src, count);
}
$ diff -u <(/work/llvm.combined/build.release.good/bin/clang++ -fPIC -m64
-march=x86-64 -fomit-frame-pointer -O2 -std=c++14 -x c++ -c /tmp/SkOpts.ii -S
-o -) <(/work/llvm.combined/build.release.bad/bin/clang++ -fPIC -m64
-march=x86-64 -fomit-frame-pointer -O2 -std=c++14 -x c++ -c /tmp/SkOpts.ii -S
-o -)
The diff shows a PSHUFD going missing in the new version, the rest of the diff
is just register names. I haven't dug into the assembly enough to tell why this
is breaking anything.
Craig, does this make any sense to you? Was your change supposed to alter
codegen or was it just reorganizing the code?
--
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 36730] New: __builtin_constant_p does not work on powerpc
https://bugs.llvm.org/show_bug.cgi?id=36730
Bug ID: 36730
Summary: __builtin_constant_p does not work on powerpc
Product: libraries
Version: 6.0
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Backend: PowerPC
Assignee: unassignedb...@nondot.org
Reporter: nruslan_de...@yahoo.com
CC: llvm-bugs@lists.llvm.org
Found that at least for 64-bit and 128-bit types, clang/llvm does not seem to
detect that the specified value is a constant (PPC64 target).
(GCC seems to work fine for both types.)
Example:
static inline unsigned char func1(__uint128_t a)
{
if (__builtin_constant_p(a)) {
return 1;
}
return 0;
}
unsigned char test_func1()
{
return func1(0);
}
static inline unsigned char func2(unsigned long long a)
{
if (__builtin_constant_p(a)) {
return 1;
}
return 0;
}
unsigned char test_func2()
{
return func2(0);
}
Generated code:
(clang -Wall -O2 -target powerpc64-linux-gnu -S test.c)
test_func1: # @test_func1
.p2align3
.quad .Lfunc_begin0
.quad .TOC.@tocbase
.quad 0
.text
.Lfunc_begin0:
# %bb.0:
li 3, 0
blr
...
test_func2: # @test_func2
.p2align3
.quad .Lfunc_begin1
.quad .TOC.@tocbase
.quad 0
.text
.Lfunc_begin1:
# %bb.0:
li 3, 0
blr
--
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 36731] New: FastISel causes assertion "i8 shifts should be handled by autogenerated table"
https://bugs.llvm.org/show_bug.cgi?id=36731
Bug ID: 36731
Summary: FastISel causes assertion "i8 shifts should be handled
by autogenerated table"
Product: new-bugs
Version: 6.0
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: v.chur...@gmail.com
CC: llvm-bugs@lists.llvm.org
Created attachment 20062
--> https://bugs.llvm.org/attachment.cgi?id=20062&action=edit
Reduced input file
I am currently looking into upgrading the Julia frontend to use LLVM 6.0
With FastISel on I run into the assertion:
> I->getType()->isIntegerTy(8) && "i8 shifts should be handled by autogenerated
> table"' failed.
I reduced dumped the module with bugpoint to the attached input file, which
triggers the assertion with `llc -fast-isel bugpoint.ll`.
```
usr/tools/llc -fast-isel ~/bugpoint.ll
llc:
/builds/vchuravy/julia/deps/srccache/llvm-6.0.0/lib/Target/X86/X86FastISel.cpp:1793:
bool {anonymous}::X86FastISel::X86SelectShift(const llvm::Instruction*):
Assertion `!I->getType()->isIntegerTy(8) && "i8 shifts should be handled by
autogenerated table"' failed.
#0 0x7f77a964940a llvm::sys::PrintStackTrace(llvm::raw_ostream&)
/builds/vchuravy/julia/deps/srccache/llvm-6.0.0/lib/Support/Unix/Signals.inc:402:0
#1 0x7f77a964720e llvm::sys::RunSignalHandlers()
/builds/vchuravy/julia/deps/srccache/llvm-6.0.0/lib/Support/Signals.cpp:50:0
#2 0x7f77a9647382 SignalHandler(int)
/builds/vchuravy/julia/deps/srccache/llvm-6.0.0/lib/Support/Unix/Signals.inc:242:0
#3 0x7f77a877b4b0 (/lib/x86_64-linux-gnu/libc.so.6+0x354b0)
#4 0x7f77a877b428 gsignal
/build/glibc-Cl5G7W/glibc-2.23/signal/../sysdeps/unix/sysv/linux/raise.c:54:0
#5 0x7f77a877d02a abort /build/glibc-Cl5G7W/glibc-2.23/stdlib/abort.c:91:0
#6 0x7f77a8773bd7 __assert_fail_base
/build/glibc-Cl5G7W/glibc-2.23/assert/assert.c:92:0
#7 0x7f77a8773c82 (/lib/x86_64-linux-gnu/libc.so.6+0x2dc82)
#8 0x7f77aab571e9 llvm::MachineRegisterInfo::getRegClass(unsigned int)
const
/builds/vchuravy/julia/deps/srccache/llvm-6.0.0/include/llvm/CodeGen/MachineRegisterInfo.h:602:0
#9 0x7f77aab571e9 X86FastEmitPseudoSelect
/builds/vchuravy/julia/deps/srccache/llvm-6.0.0/lib/Target/X86/X86FastISel.cpp:2326:0
#10 0x7f77aab571e9 X86SelectSelect
/builds/vchuravy/julia/deps/srccache/llvm-6.0.0/lib/Target/X86/X86FastISel.cpp:2400:0
#11 0x7f77aab571e9 (anonymous
namespace)::X86FastISel::fastSelectInstruction(llvm::Instruction const*)
/builds/vchuravy/julia/deps/srccache/llvm-6.0.0/lib/Target/X86/X86FastISel.cpp:3596:0
#12 0x7f77a9b8df08 llvm::FastISel::selectInstruction(llvm::Instruction
const*)
/builds/vchuravy/julia/deps/srccache/llvm-6.0.0/lib/CodeGen/SelectionDAG/FastISel.cpp:1437:0
#13 0x7f77a9ce1a1c
llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&)
/builds/vchuravy/julia/deps/srccache/llvm-6.0.0/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp:1505:0
#14 0x7f77a9ce3f25
llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) [clone
.part.881] [clone .constprop.905]
/builds/vchuravy/julia/deps/srccache/llvm-6.0.0/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp:467:0
#15 0x7f77aab91fb4 (anonymous
namespace)::X86DAGToDAGISel::runOnMachineFunction(llvm::MachineFunction&)
/builds/vchuravy/julia/deps/srccache/llvm-6.0.0/lib/Target/X86/X86ISelDAGToDAG.cpp:177:0
#16 0x7f77a99267d5
llvm::MachineFunctionPass::runOnFunction(llvm::Function&)
/builds/vchuravy/julia/deps/srccache/llvm-6.0.0/lib/CodeGen/MachineFunctionPass.cpp:62:0
#17 0x7f77a974409b llvm::FPPassManager::runOnFunction(llvm::Function&)
/builds/vchuravy/julia/deps/srccache/llvm-6.0.0/lib/IR/LegacyPassManager.cpp:1520:0
#18 0x7f77a974415c llvm::FPPassManager::runOnModule(llvm::Module&)
/builds/vchuravy/julia/deps/srccache/llvm-6.0.0/lib/IR/LegacyPassManager.cpp:1541:0
#19 0x7f77a9743c9d llvm::legacy::PassManagerImpl::run(llvm::Module&)
/builds/vchuravy/julia/deps/srccache/llvm-6.0.0/lib/IR/LegacyPassManager.cpp:1597:0
#20 0x00418e5d compileModule(char**, llvm::LLVMContext&) [clone
.constprop.391]
/builds/vchuravy/julia/deps/srccache/llvm-6.0.0/tools/llc/llc.cpp:572:0
#21 0x0040bc2d main
/builds/vchuravy/julia/deps/srccache/llvm-6.0.0/tools/llc/llc.cpp:346:0
#22 0x7f77a8766830 __libc_start_main
/build/glibc-Cl5G7W/glibc-2.23/csu/../csu/libc-start.c:325:0
#23 0x0040bde9 _start (usr/tools/llc+0x40bde9)
Stack dump:
0. Program arguments: usr/tools/llc -fast-isel
/afs/csail.mit.edu/u/v/vchuravy/bugpoint.ll
1. Running pass 'Function Pass Manager' on module
'/afs/csail.mit.edu/u/v/vchuravy/bugpoint.ll'.
2. Running pass 'X86 DAG->DAG Instruction Selection' on function
'@julia_bin_5346'
```
--
You are receiving this mail because:
You are on the CC list for the bug._
[llvm-bugs] Issue 4704 in oss-fuzz: llvm/llvm-isel-fuzzer--aarch64-gisel: Abrt in handleLLVMFatalError
Updates: Labels: Deadline-Approaching Comment #7 on issue 4704 by sheriff...@chromium.org: llvm/llvm-isel-fuzzer--aarch64-gisel: Abrt in handleLLVMFatalError https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=4704#c7 This bug is approaching its deadline for being fixed, and will be automatically derestricted within 7 days. If a fix is planned within 2 weeks after the deadline has passed, a grace extension can be granted. - Your friendly Sheriffbot -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 4702 in oss-fuzz: llvm/llvm-isel-fuzzer--aarch64-gisel: Direct-leak in llvm::BitcodeReaderValueList::getValueFwdRef
Updates: Labels: Deadline-Approaching Comment #7 on issue 4702 by sheriff...@chromium.org: llvm/llvm-isel-fuzzer--aarch64-gisel: Direct-leak in llvm::BitcodeReaderValueList::getValueFwdRef https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=4702#c7 This bug is approaching its deadline for being fixed, and will be automatically derestricted within 7 days. If a fix is planned within 2 weeks after the deadline has passed, a grace extension can be granted. - Your friendly Sheriffbot -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 4705 in oss-fuzz: llvm/llvm-isel-fuzzer--x86_64-O2: ASSERT: LC != RTLIB::UNKNOWN_LIBCALL && "Unsupported SREM!"
Updates: Labels: Deadline-Approaching Comment #4 on issue 4705 by sheriff...@chromium.org: llvm/llvm-isel-fuzzer--x86_64-O2: ASSERT: LC != RTLIB::UNKNOWN_LIBCALL && "Unsupported SREM!" https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=4705#c4 This bug is approaching its deadline for being fixed, and will be automatically derestricted within 7 days. If a fix is planned within 2 weeks after the deadline has passed, a grace extension can be granted. - Your friendly Sheriffbot -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 4701 in oss-fuzz: llvm/llvm-isel-fuzzer--x86_64-O2: Direct-leak in llvm::MDTuple::getImpl
Updates: Labels: Deadline-Approaching Comment #7 on issue 4701 by sheriff...@chromium.org: llvm/llvm-isel-fuzzer--x86_64-O2: Direct-leak in llvm::MDTuple::getImpl https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=4701#c7 This bug is approaching its deadline for being fixed, and will be automatically derestricted within 7 days. If a fix is planned within 2 weeks after the deadline has passed, a grace extension can be granted. - Your friendly Sheriffbot -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 4714 in oss-fuzz: llvm/llvm-isel-fuzzer--aarch64-O2: ASSERT: Offset <= INT_MAX && "Offset too big to fit in int."
Updates: Labels: Deadline-Approaching Comment #4 on issue 4714 by sheriff...@chromium.org: llvm/llvm-isel-fuzzer--aarch64-O2: ASSERT: Offset <= INT_MAX && "Offset too big to fit in int." https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=4714#c4 This bug is approaching its deadline for being fixed, and will be automatically derestricted within 7 days. If a fix is planned within 2 weeks after the deadline has passed, a grace extension can be granted. - Your friendly Sheriffbot -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 4712 in oss-fuzz: llvm/llvm-isel-fuzzer--aarch64-O2: ASSERT: TRI.getRegSizeInBits(*getRegClass(DstReg)) == TRI.getRegSizeInBits(*getRegClass(
Updates: Labels: Deadline-Approaching Comment #4 on issue 4712 by sheriff...@chromium.org: llvm/llvm-isel-fuzzer--aarch64-O2: ASSERT: TRI.getRegSizeInBits(*getRegClass(DstReg)) == TRI.getRegSizeInBits(*getRegClass( https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=4712#c4 This bug is approaching its deadline for being fixed, and will be automatically derestricted within 7 days. If a fix is planned within 2 weeks after the deadline has passed, a grace extension can be granted. - Your friendly Sheriffbot -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 4706 in oss-fuzz: llvm/llvm-opt-fuzzer--x86_64-instcombine: ASSERT: VSTOffset == 0 || !F->hasName()
Updates: Labels: Deadline-Approaching Comment #4 on issue 4706 by sheriff...@chromium.org: llvm/llvm-opt-fuzzer--x86_64-instcombine: ASSERT: VSTOffset == 0 | | !F->hasName() https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=4706#c4 This bug is approaching its deadline for being fixed, and will be automatically derestricted within 7 days. If a fix is planned within 2 weeks after the deadline has passed, a grace extension can be granted. - Your friendly Sheriffbot -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 36732] New: llvm.experimental.vector.reduce.{fadd, fmul} select fails when passed a non-undef accumulator
https://bugs.llvm.org/show_bug.cgi?id=36732
Bug ID: 36732
Summary: llvm.experimental.vector.reduce.{fadd,fmul} select
fails when passed a non-undef accumulator
Product: new-bugs
Version: unspecified
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: gonzalob...@gmail.com
CC: chandl...@gmail.com, hfin...@anl.gov,
llvm-bugs@lists.llvm.org, llvm-...@redking.me.uk
The docs of the llvm.experimental.vector.reduce.{fadd,fmul} intrinsics state:
> If the intrinsic call has fast-math flags, then the reduction will not
> preserve the associativity of an equivalent scalarized counterpart. If it
> does not have fast-math flags, then the reduction will be ordered, implying
> that the operation respects the associativity of a scalarized reduction.
>
> Arguments:
> The first argument to this intrinsic is a scalar accumulator value, which is
> only used when there are no fast-math flags attached. This argument may be
> undef when fast-math flags are used.
While undef + fast-math flags works fine, I haven't been able to get the
non-fast-math + accumulator version to work. They fail to select. I'm using
LLVM6 with assertions enabled.
For example:
declare float @llvm.experimental.vector.reduce.fadd.f32.f32.v4f32(float, <4 x
float>)
define internal float
@_ZN32simd_intrinsic_generic_reduction3foo17ha7e2b586cf5567bdE(<4 x float>*
noalias nocapture dereferenceable(16)) unnamed_addr #0 {
%2 = alloca float, align 4
%3 = load <4 x float>, <4 x float>* %0, align 16
%4 = call float @llvm.experimental.vector.reduce.fadd.f32.f32.v4f32(float
1.00e+00, <4 x float> %3)
store float %4, float* %2, align 4
%5 = load float, float* %2, align 4
br label %6
; :6: ; preds = %1
ret float %5
}
produces
LLVM ERROR: Cannot select: 0x3f478b0: f32 = vecreduce_strict_fadd 0x3f479e8,
0x3f477e0
0x3f479e8: f32,ch = load 0x3ea4c28, 0x3f47b88, undef:i64
0x3f47b88: i64 = X86ISD::Wrapper TargetConstantPool:i64
0
0x3f47848: i64 = TargetConstantPool 0
0x3f47778: i64 = undef
0x3f477e0: v4f32,ch = load 0x3ea4c28, 0x3f476a8,
undef:i64
0x3f476a8: i64,ch = CopyFromReg 0x3ea4c28, Register:i64 %1
0x3f47640: i64 = Register %1
0x3f47778: i64 = undef
In function: _ZN32simd_intrinsic_generic_reduction3foo17ha7e2b586cf5567bdE
Compiler returned: 1
and
declare float @llvm.experimental.vector.reduce.fmul.f32.f32.v4f32(float, <4 x
float>)
define internal float
@_ZN32simd_intrinsic_generic_reduction3foo17ha7e2b586cf5567bdE(<4 x float>*
noalias nocapture dereferenceable(16)) unnamed_addr #0 {
%2 = alloca float, align 4
%3 = load <4 x float>, <4 x float>* %0, align 16
%4 = call float @llvm.experimental.vector.reduce.fmul.f32.f32.v4f32(float
1.00e+00, <4 x float> %3)
store float %4, float* %2, align 4
%5 = load float, float* %2, align 4
br label %6
; :6: ; preds = %1
ret float %5
}
produces this
LLVM ERROR: Cannot select: 0x4da88a0: f32 = vecreduce_strict_fmul 0x4da89d8,
0x4da87d0
0x4da89d8: f32,ch = load 0x4d05c28, 0x4da8b78, undef:i64
0x4da8b78: i64 = X86ISD::Wrapper TargetConstantPool:i64
0
0x4da8838: i64 = TargetConstantPool 0
0x4da8768: i64 = undef
0x4da87d0: v4f32,ch = load 0x4d05c28, 0x4da8698,
undef:i64
0x4da8698: i64,ch = CopyFromReg 0x4d05c28, Register:i64 %1
0x4da8630: i64 = Register %1
0x4da8768: i64 = undef
In function: _ZN32simd_intrinsic_generic_reduction3foo17ha7e2b586cf5567bdE
Compiler returned: 1
--
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 36733] New: PYTHON_EXECUTABLE i spython2.7 while PYTHON_LIBRARY is libpython3.6m.so
https://bugs.llvm.org/show_bug.cgi?id=36733 Bug ID: 36733 Summary: PYTHON_EXECUTABLE i spython2.7 while PYTHON_LIBRARY is libpython3.6m.so Product: Build scripts Version: 6.0 Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: cmake Assignee: unassignedb...@nondot.org Reporter: dilyan.palau...@aegee.org CC: llvm-bugs@lists.llvm.org Letting ccmake to find everything automatically prints: PYTHON_EXECUTABLE */usr/binpython2.7 PYTHON_INCLUDE_DIR */usr/local/include/python3.6m PYTHON_LIBRARY */usr/local/lib/libpython3.6m.so PYTHON_LIBRARY_DEBUG*PYTHON_LIBRARY_DEBUG-NOTFOUND and PYTHON_EXECUTABLE does not match to PYTHON_LIBRARY. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 36734] New: llvm.experimental.vector.reduce.{fadd, fmul} incorrect for non-unit accumulators
https://bugs.llvm.org/show_bug.cgi?id=36734
Bug ID: 36734
Summary: llvm.experimental.vector.reduce.{fadd,fmul} incorrect
for non-unit accumulators
Product: new-bugs
Version: unspecified
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: gonzalob...@gmail.com
CC: chandl...@gmail.com, hfin...@anl.gov,
llvm-bugs@lists.llvm.org, llvm-...@redking.me.uk
This IR:
declare float @llvm.experimental.vector.reduce.fadd.f32.f32.v4f32(float, <4 x
float>)
declare float @llvm.experimental.vector.reduce.fmul.f32.f32.v4f32(float, <4 x
float>)
define internal float
@_ZN32simd_intrinsic_generic_reduction3foo17ha7e2b586cf5567bdE(<4 x float>*
noalias nocapture dereferenceable(16)) unnamed_addr #0 {
%2 = alloca float, align 4
%3 = load <4 x float>, <4 x float>* %0, align 16
%4 = call fast float
@llvm.experimental.vector.reduce.fadd.f32.f32.v4f32(float -1.00e+00, <4 x
float> %3)
store float %4, float* %2, align 4
%5 = load float, float* %2, align 4
br label %6
; :6: ; preds = %1
ret float %5
}
define internal float
@_ZN32simd_intrinsic_generic_reduction3bar17he2463f63ae652611E(<4 x float>*
noalias nocapture dereferenceable(16)) unnamed_addr #0 {
%2 = alloca float, align 4
%3 = load <4 x float>, <4 x float>* %0, align 16
%4 = call fast float
@llvm.experimental.vector.reduce.fmul.f32.f32.v4f32(float -1.00e+00, <4 x
float> %3)
store float %4, float* %2, align 4
%5 = load float, float* %2, align 4
br label %6
; :6: ; preds = %1
ret float %5
}
lowers to:
simd_intrinsic_generic_reduction::foo: # @simd_intrinsic_generic_reduction::foo
movaps xmm0, xmmword ptr [rdi]
movaps xmm1, xmm0
movhlps xmm1, xmm1 # xmm1 = xmm1[1,1]
addps xmm1, xmm0
movaps xmm0, xmm1
shufps xmm0, xmm0, 229 # xmm0 = xmm0[1,1,2,3]
addps xmm0, xmm1
movss dword ptr [rsp - 4], xmm0
ret
simd_intrinsic_generic_reduction::bar: # @simd_intrinsic_generic_reduction::bar
movaps xmm0, xmmword ptr [rdi]
movaps xmm1, xmm0
movhlps xmm1, xmm1 # xmm1 = xmm1[1,1]
mulps xmm1, xmm0
movaps xmm0, xmm1
shufps xmm0, xmm0, 229 # xmm0 = xmm0[1,1,2,3]
mulps xmm0, xmm1
movss dword ptr [rsp - 4], xmm0
ret
which is incorrect for any non unit accumulator (0. for fadd, and 1 for fmul).
For example, here -1 is the accumulator, and for the input (1, -2, 3, 4) this
should produce -1 + 1 - 2 + 3 + 4 = 5, but it produces 6 (it never adds the
accumulator to the result). Basically, these intrinsics only appear to work
correctly for an accumulator value of 0 for add, and 1 for mul...
--
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 36730] __builtin_constant_p does not work on powerpc
https://bugs.llvm.org/show_bug.cgi?id=36730 Eli Friedman changed: What|Removed |Added CC||efrie...@codeaurora.org Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Eli Friedman --- *** This bug has been marked as a duplicate of bug 4898 *** -- 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 36735] New: Assertion failed while cross compiling on macOS for Linux [Assertion failed: (!CodeSynthesisContexts.empty() && "Cannot perform an instantiation without some context on th
https://bugs.llvm.org/show_bug.cgi?id=36735
Bug ID: 36735
Summary: Assertion failed while cross compiling on macOS for
Linux [Assertion failed:
(!CodeSynthesisContexts.empty() && "Cannot perform an
instantiation without some context on the "
"instantiation stack")]
Product: clang
Version: trunk
Hardware: PC
OS: MacOS X
Status: NEW
Severity: normal
Priority: P
Component: Frontend
Assignee: unassignedclangb...@nondot.org
Reporter: juan.arri...@nablazerolabs.com
CC: llvm-bugs@lists.llvm.org
Successfully built clang from source exactly as instructed in
https://clang.llvm.org/get_started.html.
Attempted to cross-compile a hello world executable.
Source (hello.cpp):
#include
int main() {
std::cout << "Hello, world!\n";
}
Command:
$ clang++ hello.cpp -std=c++17 -target x86_64-pc-linux -stdlib=libc++
Output:
In file included from hello.cpp:1:
In file included from /usr/local/bin/../include/c++/v1/iostream:37:
/usr/local/bin/../include/c++/v1/__config:192:12: fatal error: 'features.h'
file not found
# include
^~~~
Assertion failed: (!CodeSynthesisContexts.empty() && "Cannot perform an
instantiation without some context on the " "instantiation stack"), function
SubstType, file
/usr/local/src/llvm/tools/clang/lib/Sema/SemaTemplateInstantiate.cpp, line
1580.
0 clang-7.00x00010e3df8f8
llvm::sys::PrintStackTrace(llvm::raw_ostream&) + 40
1 clang-7.00x00010e3dffb6 SignalHandler(int) + 470
2 libsystem_platform.dylib 0x7fff5c1a8f5a _sigtramp + 26
3 libsystem_platform.dylib 0x7ffee3108b10 _sigtramp + 2264267728
4 libsystem_c.dylib0x7fff5bfd3312 abort + 127
5 libsystem_c.dylib0x7fff5bf9b368 basename_r + 0
6 clang-7.00x00010fbce3e4
clang::Sema::SubstType(clang::TypeSourceInfo*,
clang::MultiLevelTemplateArgumentList const&, clang::SourceLocation,
clang::DeclarationName, bool) + 180
7 clang-7.00x00010fc1155e
clang::TemplateDeclInstantiator::VisitNonTypeTemplateParmDecl(clang::NonTypeTemplateParmDecl*)
+ 1086
8 clang-7.00x00010fc162e2
clang::Sema::SubstDecl(clang::Decl*, clang::DeclContext*,
clang::MultiLevelTemplateArgumentList const&) + 162
9 clang-7.00x00010fb3101d
clang::Sema::DeclareImplicitDeductionGuides(clang::TemplateDecl*,
clang::SourceLocation) + 2173
10 clang-7.00x00010fa03509
DeclareImplicitMemberFunctionsWithName(clang::Sema&, clang::DeclarationName,
clang::SourceLocation, clang::DeclContext const*) + 521
11 clang-7.00x00010fa076dd LookupDirect(clang::Sema&,
clang::LookupResult&, clang::DeclContext const*) + 77
12 clang-7.00x00010fa038ab CppNamespaceLookup(clang::Sema&,
clang::LookupResult&, clang::ASTContext&, clang::DeclContext*, (anonymous
namespace)::UnqualUsingDirectiveSet&) + 75
13 clang-7.00x00010fa03209
clang::Sema::CppLookupName(clang::LookupResult&, clang::Scope*) + 3049
14 clang-7.00x00010fa07259
clang::Sema::LookupName(clang::LookupResult&, clang::Scope*, bool) + 1337
15 clang-7.00x00010f75ccda
clang::Sema::HandleDeclarator(clang::Scope*, clang::Declarator&,
llvm::MutableArrayRef) + 2106
16 clang-7.00x00010fb4c6cb
clang::Sema::ActOnTemplateDeclarator(clang::Scope*,
llvm::MutableArrayRef, clang::Declarator&) + 27
17 clang-7.00x00010f3fe93d
clang::Parser::ParseDeclarationAfterDeclaratorAndAttributes(clang::Declarator&,
clang::Parser::ParsedTemplateInfo const&, clang::Parser::ForRangeInit*) + 141
18 clang-7.00x00010f48106a
clang::Parser::ParseSingleDeclarationAfterTemplate(clang::DeclaratorContext,
clang::Parser::ParsedTemplateInfo const&, clang::ParsingDeclRAIIObject&,
clang::SourceLocation&, clang::AccessSpecifier, clang::AttributeList*) + 2570
19 clang-7.00x00010f480383
clang::Parser::ParseTemplateDeclarationOrSpecialization(clang::DeclaratorContext,
clang::SourceLocation&, clang::AccessSpecifier, clang::AttributeList*) + 1283
20 clang-7.00x00010f47fc2d
clang::Parser::ParseDeclarationStartingWithTemplate(clang::DeclaratorContext,
clang::SourceLocation&, clang::AccessSpecifier, clang::AttributeList*) + 237
21 clang-7.00x00010f3f7bbf
clang::Parser::ParseDeclaration(clang::DeclaratorContext,
clang::SourceLocation&, clang::Parser::ParsedAttributesWithRange&) + 351
22 clang-7.00x00010f48eb7e
clang::Parser::ParseExternalDeclaration(clang::Parser::ParsedAttributesWithRange&,
clang::ParsingDeclSpec*) + 174
23 clang-7.00x00010f412380
clang::Parser::ParseInnerNamespace(std::__1::vector >&,
std::__1::vector >&,
std::__1::vec
[llvm-bugs] [Bug 36736] New: We should probably reject --just symbols with .o or .so
https://bugs.llvm.org/show_bug.cgi?id=36736 Bug ID: 36736 Summary: We should probably reject --just symbols with .o or .so Product: lld Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: ELF Assignee: unassignedb...@nondot.org Reporter: raf...@espindo.la CC: llvm-bugs@lists.llvm.org In .o files st_value is an offset and in a .so the values will change at runtime. -- 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 36737] New: --just-symbols file should count as an input
https://bugs.llvm.org/show_bug.cgi?id=36737 Bug ID: 36737 Summary: --just-symbols file should count as an input Product: lld Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: ELF Assignee: unassignedb...@nondot.org Reporter: raf...@espindo.la CC: llvm-bugs@lists.llvm.org This fails with lld but works with bfd and gold: ld.lld --just-symbols tsym -o t ld.lld: error: no input files ld.lld: error: target emulation unknown: -m or at least one .o file required -- 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 36738] New: [SCEV] Inconsistent SCEV formation for zext
https://bugs.llvm.org/show_bug.cgi?id=36738
Bug ID: 36738
Summary: [SCEV] Inconsistent SCEV formation for zext
Product: libraries
Version: trunk
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P
Component: Global Analyses
Assignee: unassignedb...@nondot.org
Reporter: pankaj.cha...@intel.com
CC: llvm-bugs@lists.llvm.org
Created attachment 20063
--> https://bugs.llvm.org/attachment.cgi?id=20063&action=edit
test case
SCEV is behaving inconsistently when forming SCEV for this zext instruction in
the attached test case-
%conv5 = zext i32 %dec to i64
If we request a SCEV for the instruction, it returns-
(zext i32 {{-1,+,1}<%for.body>,+,-1}<%for.body7> to i64)
This can be seen by invoking-
$ opt -analyze -scalar-evolution inconsistent-scev-zext.ll
But when computing the backedge taken count of the containing loop for.body7,
it is able to push zext inside the AddRec and forms the following for the same
instruction-
{(zext i32 {-1,+,1}<%for.body> to i64),+,-1}<%for.body7>
This allows ScalarEvolution to compute a valid backedge taken count for the
loop.
Reference to email discussion regarding the bug-
http://lists.llvm.org/pipermail/llvm-dev/2018-February/121107.html
--
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 36739] New: Fix tests which check that the lldb-mi driver exits properly
https://bugs.llvm.org/show_bug.cgi?id=36739 Bug ID: 36739 Summary: Fix tests which check that the lldb-mi driver exits properly Product: lldb Version: unspecified Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: lldb-...@lists.llvm.org Reporter: v...@apple.com CC: llvm-bugs@lists.llvm.org Virtually everything in TestMiExit.py has been xfailed for a while. -- 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 36740] New: Fix tests which check the lldb-mi -gdb-set and -gdb-show commands
https://bugs.llvm.org/show_bug.cgi?id=36740 Bug ID: 36740 Summary: Fix tests which check the lldb-mi -gdb-set and -gdb-show commands Product: lldb Version: unspecified Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: lldb-...@lists.llvm.org Reporter: v...@apple.com CC: llvm-bugs@lists.llvm.org Virtually everything in TestMiGdbSetShow.py has been xfailed for a while. -- 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 36741] New: Fix tests which check the lldb-mi -symbol-xxx commands
https://bugs.llvm.org/show_bug.cgi?id=36741 Bug ID: 36741 Summary: Fix tests which check the lldb-mi -symbol-xxx commands Product: lldb Version: unspecified Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: lldb-...@lists.llvm.org Reporter: v...@apple.com CC: llvm-bugs@lists.llvm.org Virtually everything in TestMiSymbol.py has been xfailed for a while. -- 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 36742] New: SEGV in llvm-readobj -unwind on X86-64 COFF binary
https://bugs.llvm.org/show_bug.cgi?id=36742
Bug ID: 36742
Summary: SEGV in llvm-readobj -unwind on X86-64 COFF binary
Product: new-bugs
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: w.parker.thomp...@gmail.com
CC: llvm-bugs@lists.llvm.org
Created attachment 20064
--> https://bugs.llvm.org/attachment.cgi?id=20064&action=edit
Reproduction binary
When parsing the unwinding information in a x86-64 COFF binary (attached)
llvm-readobj segfaults.
Reproduction:
llvm-readobj -unwind ./msvs_whatever_64_O1_psftp_stripped
bt:
Format: COFF-x86-64
Arch: x86_64
AddressSize: 64bit
UnwindInformation [
RuntimeFunction {
StartAddress: (0x0)
EndAddress: (0x4)
UnwindInfoAddress: (0x8)
#0 0x55992cc2f6b9 llvm::sys::PrintStackTrace(llvm::raw_ostream&)
(./bin/llvm-readobj+0x1d46b9)
#1 0x55992cc2da06 llvm::sys::RunSignalHandlers()
(./bin/llvm-readobj+0x1d2a06)
#2 0x55992cc2db5c SignalHandler(int) (./bin/llvm-readobj+0x1d2b5c)
#3 0x7fc4bb7f9da0 __restore_rt (/usr/lib/libpthread.so.0+0x11da0)
#4 0x55992cbace25
llvm::object::COFFObjectFile::getSectionContents(llvm::object::coff_section
const*, llvm::ArrayRef&) const (./bin/llvm-readobj+0x151e25)
#5 0x55992cb5dbbb
llvm::Win64EH::Dumper::printRuntimeFunction(llvm::Win64EH::Dumper::Context
const&, llvm::object::coff_section const*, unsigned long,
llvm::Win64EH::RuntimeFunction const&) (./bin/llvm-readobj+0x102bbb)
#6 0x55992cb5e1d9
llvm::Win64EH::Dumper::printData(llvm::Win64EH::Dumper::Context const&)
(./bin/llvm-readobj+0x1031d9)
#7 0x55992cad0201 (anonymous namespace)::COFFDumper::printUnwindInfo()
(./bin/llvm-readobj+0x75201)
#8 0x55992cb48f7e dumpObject(llvm::object::ObjectFile const*,
llvm::ScopedPrinter&) (./bin/llvm-readobj+0xedf7e)
#9 0x55992caaa5d8 main (./bin/llvm-readobj+0x4f5d8)
#10 0x7fc4ba317f4a __libc_start_main (/usr/lib/libc.so.6+0x20f4a)
#11 0x55992cac157a _start (./bin/llvm-readobj+0x6657a)
Stack dump:
0. Program arguments: ./bin/llvm-readobj -unwind
msvs_whatever_64_O1_psftp_stripped
[1]26476 segmentation fault (core dumped) ./bin/llvm-readobj -unwind
--
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 36743] New: Cannot select: X86ISD::CALL ICE with -mx32 -O2 -fno-plt
https://bugs.llvm.org/show_bug.cgi?id=36743
Bug ID: 36743
Summary: Cannot select: X86ISD::CALL ICE with -mx32 -O2
-fno-plt
Product: new-bugs
Version: 6.0
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: ste...@uplinklabs.net
CC: llvm-bugs@lists.llvm.org
A straightforward reduced test case:
==> /tmp/testcase-cc8b84.c <==
# 1 ""
# 1 "testcase.c"
main() { a(); }
==> /tmp/testcase-cc8b84.sh <==
# Crash reproducer for clang version 6.0.0 (tags/RELEASE_600/final)
# Driver args: "-v" "-O2" "-fno-plt" "-mx32" "-c" "testcase.c"
# Original command: "/usr/bin/clang-6.0" "-cc1" "-triple"
"x86_64-pc-linux-gnux32" "-emit-obj" "-disable-free" "-disable-llvm-verifier"
"-discard-value-names" "-main-file-name" "testcase.c" "-mrelocation-model"
"pic" "-pic-level" "2" "-pic-is-pie" "-mthread-model" "posix" "-fmath-errno"
"-masm-verbose" "-mconstructor-aliases" "-fno-plt" "-munwind-tables"
"-fuse-init-array" "-target-cpu" "x86-64" "-dwarf-column-info"
"-debugger-tuning=gdb" "-momit-leaf-frame-pointer" "-v" "-coverage-notes-file"
"/home/steven/Development/ec2-packages/libc++/testcase.gcno" "-resource-dir"
"/usr/lib/clang/6.0.0" "-internal-isystem" "/usr/local/include"
"-internal-isystem" "/usr/lib/clang/6.0.0/include" "-internal-externc-isystem"
"/include" "-internal-externc-isystem" "/usr/include" "-O2"
"-fdebug-compilation-dir" "/home/steven/Development/ec2-packages/libc++"
"-ferror-limit" "19" "-fmessage-length" "190" "-stack-protector" "2"
"-fobjc-runtime=gcc" "-fdiagnostics-show-option" "-fcolor-diagnostics"
"-vectorize-loops" "-vectorize-slp" "-o" "testcase.o" "-x" "c" "testcase.c"
"/usr/bin/clang-6.0" "-cc1" "-triple" "x86_64-pc-linux-gnux32" "-emit-obj"
"-disable-free" "-disable-llvm-verifier" "-discard-value-names"
"-main-file-name" "testcase.c" "-mrelocation-model" "pic" "-pic-level" "2"
"-pic-is-pie" "-mthread-model" "posix" "-fmath-errno" "-masm-verbose"
"-mconstructor-aliases" "-fno-plt" "-munwind-tables" "-fuse-init-array"
"-target-cpu" "x86-64" "-dwarf-column-info" "-debugger-tuning=gdb"
"-momit-leaf-frame-pointer" "-v" "-coverage-notes-file"
"/home/steven/Development/ec2-packages/libc++/testcase.gcno" "-O2"
"-ferror-limit" "19" "-fmessage-length" "190" "-stack-protector" "2"
"-fobjc-runtime=gcc" "-fdiagnostics-show-option" "-fcolor-diagnostics"
"-vectorize-loops" "-vectorize-slp" "-x" "c" "testcase-cc8b84.c"
Attempting to compile with clang 6.0 with "-fno-plt -mx32" at any optimization
level higher than -O0 will break at isel. This problem exists in both 6.0 and
trunk:
$ /usr/bin/clang -v -O2 -fno-plt -mx32 -c testcase.c
clang version 6.0.0 (tags/RELEASE_600/final)
Target: x86_64-pc-linux-gnux32
Thread model: posix
InstalledDir: /usr/bin
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-pc-linux-gnu/5.5.0
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-pc-linux-gnu/6.4.1
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-pc-linux-gnu/7.3.1
Found candidate GCC installation:
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/5.5.0
Found candidate GCC installation:
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/6.4.1
Found candidate GCC installation:
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/7.3.1
Found candidate GCC installation: /usr/lib/gcc/x86_64-pc-linux-gnu/5.5.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-pc-linux-gnu/6.4.1
Found candidate GCC installation: /usr/lib/gcc/x86_64-pc-linux-gnu/7.3.1
Found candidate GCC installation: /usr/lib64/gcc/x86_64-pc-linux-gnu/5.5.0
Found candidate GCC installation: /usr/lib64/gcc/x86_64-pc-linux-gnu/6.4.1
Found candidate GCC installation: /usr/lib64/gcc/x86_64-pc-linux-gnu/7.3.1
Selected GCC installation: /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/7.3.1
Candidate multilib: .;@m64
Candidate multilib: 32;@m32
Candidate multilib: x32;@mx32
Selected multilib: x32;@mx32
Found CUDA installation: /opt/cuda, version 9.1
"/usr/bin/clang-6.0" -cc1 -triple x86_64-pc-linux-gnux32 -emit-obj
-disable-free -disable-llvm-verifier -discard-value-names -main-file-name
testcase.c -mrelocation-model pic -pic-level 2 -pic-is-pie -mthread-model posix
-fmath-errno -masm-verbose -mconstructor-aliases -fno-plt -munwind-tables
-fuse-init-array -target-cpu x86-64 -dwarf-column-info -debugger-tuning=gdb
-momit-leaf-frame-pointer -v -coverage-notes-file
/home/steven/Development/ec2-packages/libc++/testcase.gcno -resource-dir
/usr/lib/clang/6.0.0 -internal-isystem /usr/local/include -internal-isystem
/usr/lib/clang/6.0.0/include -internal-externc-isystem /include
-internal-externc-isystem /usr/include -O2 -fdebug-compilation-dir
/home/steven/Development/ec2-packages/libc++ -ferror-limit 19 -fmessage-length
190 -stack-protector 2 -fobjc-runtime=gcc -fdiagnostics-show-option
-fcolor-diagnostics -vectorize-loops -vector
[llvm-bugs] [Bug 26958] InstCombine: fadd (fsub nnan ninf 0.0, X), X => 0 incorrect for X = NaN
https://bugs.llvm.org/show_bug.cgi?id=26958 Sanjay Patel changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #1 from Sanjay Patel --- (In reply to Andres Noetzli from comment #0) > This behavior is implemented in SimplifyFAddInst() in InstructionSimplify. > The optimization just checks whether nnan and ninf appear at least once > somewhere on the fadd and the fsub instruction but as the example above > indicates, this condition seems too weak. The condition is both too weak and too strong. This bug was filed first, but we have more comments in bug 27151, so let me mark this as a duplicate since they are for the same problem. *** This bug has been marked as a duplicate of bug 27151 *** -- 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 36729] Chromium miscompile after r326991
https://bugs.llvm.org/show_bug.cgi?id=36729 Hans Wennborg changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #3 from Hans Wennborg --- This was all a wild goose chase. The problem is r326867 which caused some V8 tests to fail flakily on Fuchsia. -- 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 36624] ThinLTO + CFG + RTTI results in broken binaries on Windows
https://bugs.llvm.org/show_bug.cgi?id=36624 Reid Kleckner changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #9 from Reid Kleckner --- Should be fixed after r327557. -- 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 36744] New: llvm-objdump -unwind-info SEGVs on ntdll.dll
https://bugs.llvm.org/show_bug.cgi?id=36744 Bug ID: 36744 Summary: llvm-objdump -unwind-info SEGVs on ntdll.dll Product: new-bugs Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: w.parker.thomp...@gmail.com CC: llvm-bugs@lists.llvm.org When processing a .pdata of ntdll, the NumRFs calculation appears to be longer than the actual array of RuntimeFunction's in the section. Reproduction (binary attached): llvm-objdump -unwind-info ntdll.dll Function Table: Start Address: 0x95370 End Address: 0x953e7 Unwind Info Address: 0x12a148 Version: 2 Flags: 0 Size of prolog: 44 Number of Codes: 20 No frame pointer used Unwind Codes: #0 0x55d6465b8289 llvm::sys::PrintStackTrace(llvm::raw_ostream&) (./bin/llvm-objdump+0x526289) #1 0x55d6465b6876 llvm::sys::RunSignalHandlers() (./bin/llvm-objdump+0x524876) #2 0x55d6465b69cc SignalHandler(int) (./bin/llvm-objdump+0x5249cc) #3 0x7f5d11079da0 __restore_rt (/usr/lib/libpthread.so.0+0x11da0) #4 0x7f5d0fccea08 __memmove_avx_unaligned_erms (/usr/lib/libc.so.6+0x157a08) #5 0x55d6465a0dcd llvm::raw_ostream::copy_to_buffer(char const*, unsigned long) (./bin/llvm-objdump+0x50edcd) #6 0x55d6465a0e62 llvm::raw_ostream::write(char const*, unsigned long) (./bin/llvm-objdump+0x50ee62) #7 0x55d6462b45d5 printWin64EHUnwindInfo(llvm::Win64EH::UnwindInfo const*) (./bin/llvm-objdump+0x2225d5) #8 0x55d6462b8d93 llvm::printCOFFUnwindInfo(llvm::object::COFFObjectFile const*) (./bin/llvm-objdump+0x226d93) #9 0x55d6462b2513 DumpObject(llvm::object::ObjectFile*, llvm::object::Archive const*) (./bin/llvm-objdump+0x220513) #10 0x55d64627b4bb main (./bin/llvm-objdump+0x1e94bb) #11 0x7f5d0fb97f4a __libc_start_main (/usr/lib/libc.so.6+0x20f4a) #12 0x55d64629bbea _start (./bin/llvm-objdump+0x209bea) -- 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 36745] New: Debug info for variadic templates
https://bugs.llvm.org/show_bug.cgi?id=36745
Bug ID: 36745
Summary: Debug info for variadic templates
Product: clang
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: C++
Assignee: unassignedclangb...@nondot.org
Reporter: kiranchandramo...@gmail.com
CC: dgre...@apple.com, llvm-bugs@lists.llvm.org
template
T accumulator(T v) {
return v;
}
template
T accumulator(T first, Args... args) {
return first + accumulator(args...);
}
int main()
{
long sum = accumulator(1, 3, 5, 7);
return sum;
}
The testcase is given above. This testcase is an example for variadic
templates. The debug info generated for this testcase by clang seems to be
incorrect. The accumulator is passed the values (1,3,5,7). All the non-first
elements are shown with value 7 at the breakpoint. Ideally they should be
first=1, args=3, args=5, args=7
Breakpoint 2, accumulator (first=1, args=7, args=7, args=7)
at simple_var.cpp:8
8 return first + accumulator(args...);
--
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 36746] New: Allow 'quit' to take an exit code
https://bugs.llvm.org/show_bug.cgi?id=36746 Bug ID: 36746 Summary: Allow 'quit' to take an exit code Product: lldb Version: 6.0 Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: All Bugs Assignee: lldb-...@lists.llvm.org Reporter: alb...@apple.com CC: llvm-bugs@lists.llvm.org When running lldb, it is not possible to return an exit code from the process using the 'quit' command: (lldb) quit 1 $ echo $? 0 Note that a workaround is to directly call os._exit(1) (since sys.exit is apparently caught by the interpreter to prevent accidental exiting) (lldb) script os._exit(1) $ echo $? 1 -- 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 27151] InstructionSimplify turns NaN to 0.0
https://bugs.llvm.org/show_bug.cgi?id=27151 Sanjay Patel changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Sanjay Patel --- Should be fixed with: https://reviews.llvm.org/rL327575 -- 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 6918 in oss-fuzz: llvm/llvm-opt-fuzzer--x86_64-guard_widening: Out-of-memory in llvm_llvm-opt-fuzzer--x86_64-guard_widening
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevlieg...@apple.com, igm...@gmail.com, llvm-b...@lists.llvm.org, v...@apple.com, mitchphi...@outlook.com, xpl...@gmail.com, akils...@apple.com Labels: ClusterFuzz Reproducible Engine-libfuzzer Proj-llvm Reported-2018-03-14 Type: Bug New issue 6918 by ClusterFuzz-External: llvm/llvm-opt-fuzzer--x86_64-guard_widening: Out-of-memory in llvm_llvm-opt-fuzzer--x86_64-guard_widening https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=6918 Detailed report: https://oss-fuzz.com/testcase?key=6022654722048000 Project: llvm Fuzzer: libFuzzer_llvm_llvm-opt-fuzzer--x86_64-guard_widening Fuzz target binary: llvm-opt-fuzzer--x86_64-guard_widening Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: Out-of-memory (exceeds 2048 MB) Crash Address: Crash State: llvm_llvm-opt-fuzzer--x86_64-guard_widening Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201802190622:201802200626 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=6022654722048000 Issue filed automatically. See https://github.com/google/oss-fuzz/blob/master/docs/reproducing.md for more information. When you fix this bug, please * mention the fix revision(s). * state whether the bug was a short-lived regression or an old bug in any stable releases. * add any other useful information. This information can help downstream consumers. If you have questions for the OSS-Fuzz team, please file an issue at https://github.com/google/oss-fuzz/issues. -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 36747] New: Structured bindings in conditions crash when using member get
https://bugs.llvm.org/show_bug.cgi?id=36747
Bug ID: 36747
Summary: Structured bindings in conditions crash when using
member get
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: C++
Assignee: unassignedclangb...@nondot.org
Reporter: blitzrak...@gmail.com
CC: dgre...@apple.com, llvm-bugs@lists.llvm.org
Created attachment 20066
--> https://bugs.llvm.org/attachment.cgi?id=20066&action=edit
Crash log
Here's a minimal example that I came up with
// clang++ -std=c++17 -Wbinding-in-condition -o main main.cpp
#include
struct X {
template
int get() { return 0; }
operator bool() { return true; }
};
namespace std {
template<>
struct tuple_size { static constexpr std::size_t value = 1; };
template<>
struct tuple_element<0, X> { using type = int; };
}
int main() {
if (auto[a] = X())
return a;
}
The above crashes with the attached log.
--
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 6920 in oss-fuzz: llvm/llvm-opt-fuzzer--x86_64-loop_unroll: Out-of-memory in llvm_llvm-opt-fuzzer--x86_64-loop_unroll
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevlieg...@apple.com, igm...@gmail.com, llvm-b...@lists.llvm.org, v...@apple.com, mitchphi...@outlook.com, xpl...@gmail.com, akils...@apple.com Labels: ClusterFuzz Reproducible Engine-libfuzzer Proj-llvm Reported-2018-03-15 Type: Bug New issue 6920 by ClusterFuzz-External: llvm/llvm-opt-fuzzer--x86_64-loop_unroll: Out-of-memory in llvm_llvm-opt-fuzzer--x86_64-loop_unroll https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=6920 Detailed report: https://oss-fuzz.com/testcase?key=5068383318966272 Project: llvm Fuzzer: libFuzzer_llvm_llvm-opt-fuzzer--x86_64-loop_unroll Fuzz target binary: llvm-opt-fuzzer--x86_64-loop_unroll Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: Out-of-memory (exceeds 2048 MB) Crash Address: Crash State: llvm_llvm-opt-fuzzer--x86_64-loop_unroll Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201802210603:201802211531 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5068383318966272 Issue filed automatically. See https://github.com/google/oss-fuzz/blob/master/docs/reproducing.md for more information. When you fix this bug, please * mention the fix revision(s). * state whether the bug was a short-lived regression or an old bug in any stable releases. * add any other useful information. This information can help downstream consumers. If you have questions for the OSS-Fuzz team, please file an issue at https://github.com/google/oss-fuzz/issues. -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 6921 in oss-fuzz: llvm: Stack-overflow in clang::format::TokenAnnotator::annotate
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevlieg...@apple.com, igm...@gmail.com, llvm-b...@lists.llvm.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-03-15 Type: Bug New issue 6921 by ClusterFuzz-External: llvm: Stack-overflow in clang::format::TokenAnnotator::annotate https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=6921 Detailed report: https://oss-fuzz.com/testcase?key=5436377727500288 Project: llvm Fuzzer: libFuzzer_llvm_clang-format-fuzzer Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: Stack-overflow Crash Address: 0x7fff53cf9ff8 Crash State: clang::format::TokenAnnotator::annotate Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201710131923:201710132321 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5436377727500288 Issue filed automatically. See https://github.com/google/oss-fuzz/blob/master/docs/reproducing.md for more information. When you fix this bug, please * mention the fix revision(s). * state whether the bug was a short-lived regression or an old bug in any stable releases. * add any other useful information. This information can help downstream consumers. If you have questions for the OSS-Fuzz team, please file an issue at https://github.com/google/oss-fuzz/issues. -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 6924 in oss-fuzz: llvm/llvm-opt-fuzzer--x86_64-strength_reduce: Out-of-memory in llvm_llvm-opt-fuzzer--x86_64-strength_reduce
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevlieg...@apple.com, igm...@gmail.com, llvm-b...@lists.llvm.org, v...@apple.com, mitchphi...@outlook.com, xpl...@gmail.com, akils...@apple.com Labels: ClusterFuzz Reproducible Engine-libfuzzer Proj-llvm Reported-2018-03-15 Type: Bug New issue 6924 by ClusterFuzz-External: llvm/llvm-opt-fuzzer--x86_64-strength_reduce: Out-of-memory in llvm_llvm-opt-fuzzer--x86_64-strength_reduce https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=6924 Detailed report: https://oss-fuzz.com/testcase?key=4964208518103040 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: Out-of-memory (exceeds 2048 MB) 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 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=4964208518103040 Issue filed automatically. See https://github.com/google/oss-fuzz/blob/master/docs/reproducing.md for more information. When you fix this bug, please * mention the fix revision(s). * state whether the bug was a short-lived regression or an old bug in any stable releases. * add any other useful information. This information can help downstream consumers. If you have questions for the OSS-Fuzz team, please file an issue at https://github.com/google/oss-fuzz/issues. -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
