[llvm-bugs] [Bug 40112] LLDB crashes (SEGV) by pressing ↑ in the first entry in print
https://bugs.llvm.org/show_bug.cgi?id=40112 George Rimar changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #3 from George Rimar --- r351313 -- 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 40329] New: Operator overload matching failure with enum as first operand
https://bugs.llvm.org/show_bug.cgi?id=40329
Bug ID: 40329
Summary: Operator overload matching failure with enum as first
operand
Product: clang
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: C++
Assignee: unassignedclangb...@nondot.org
Reporter: kevin.bra...@arm.com
CC: blitzrak...@gmail.com, dgre...@apple.com,
erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org,
richard-l...@metafoo.co.uk
Created attachment 21334
--> https://bugs.llvm.org/attachment.cgi?id=21334&action=edit
Compilable example
The attached code using a C++98-compatible "SafeEnum" compiles and "works" with
all other compilers tried than clang. I say "works" because it isn't really
"safe", but it at least compiles.
In summary, we have
template
struct SafeEnum {
/**
* Type of the representation.
*/
typedef LayoutType representation_t;
/**
* Construction of an enumeration value.
*/
SafeEnum(LayoutType value) : _value(value) { }
friend bool operator!=(SafeEnum lhs, SafeEnum rhs);
};
struct hci_error_code_t : SafeEnum {
enum type {
SUCCESS = 0x00
};
hci_error_code_t(type value);
explicit hci_error_code_t(uint8_t raw_value);
};
hci_error_code_t hci_status;
Then, all compilers will accept
if (4 != hci_status) // so much for type safety
or
if (hci_status != hci_error_code_t::SUCCESS)
But clang alone will not accept
if (hci_error_code_t::SUCCESS != hci_status)
It seems the overload using the argument conversion from hci_error_code_t::type
-> uint8_t -> SafeEnum isn't found if it's the first
argument, but is if it's the second.
Clearly the SafeEnum class doesn't do what is intended, and can be replaced by
`enum class`, but it seems something is off in clang's overload resolution - I
can find no reason in why argument order should matter here.
--
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 40330] New: Block destructor calls destructor on variable captured by reference
https://bugs.llvm.org/show_bug.cgi?id=40330 Bug ID: 40330 Summary: Block destructor calls destructor on variable captured by reference Product: clang Version: unspecified Hardware: Macintosh OS: MacOS X Status: NEW Severity: enhancement Priority: P Component: C++ Assignee: unassignedclangb...@nondot.org Reporter: sebast...@theophil.net CC: blitzrak...@gmail.com, dgre...@apple.com, erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org, richard-l...@metafoo.co.uk Created attachment 21335 --> https://bugs.llvm.org/attachment.cgi?id=21335&action=edit Reproduction In the attached reproduction, - I create an object T on the stack, - then capture this object by reference in a lambda - and in the lambda create a block that again captures this t by reference. This seems correct so far because at the point of creation, object T is a reference. Then I convert the (stack allocated) block to a heap allocated block using _Block_copy and release it using _Block_release. This tries to call the destructor on the reference to T, which seems to be a bug. The bug occurs on the latest version of clang for Xcode which reports itself as Apple LLVM version 10.0.0 (clang-1000.11.45.2) -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 40331] New: [meta] 8.0.0 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=40331 Bug ID: 40331 Summary: [meta] 8.0.0 Release Blockers Product: new-bugs Version: 8.0 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P Component: new bugs Assignee: h...@chromium.org Reporter: h...@chromium.org CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org This is the tracking bug for blockers of the 8.0.0 release. The release branch was created from trunk at r351319. -- 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 40332] New: [x86, AVX512] failed to merge mask select across extract_subvector
https://bugs.llvm.org/show_bug.cgi?id=40332
Bug ID: 40332
Summary: [x86, AVX512] failed to merge mask select across
extract_subvector
Product: libraries
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: Backend: X86
Assignee: unassignedb...@nondot.org
Reporter: spatel+l...@rotateright.com
CC: craig.top...@gmail.com, llvm-bugs@lists.llvm.org,
llvm-...@redking.me.uk, spatel+l...@rotateright.com
As noted in https://reviews.llvm.org/D56756 - we have this and similar
regression tests in test/CodeGen/X86/avx512-shuffles/partial_permute.ll:
define <4 x i32> @test_masked_z_8xi32_to_4xi32_perm_mask3(<8 x i32> %vec, <4 x
i32> %mask) {
; CHECK-LABEL: test_masked_z_8xi32_to_4xi32_perm_mask3:
; CHECK: # %bb.0:
; CHECK-NEXT:vmovdqa {{.*#+}} ymm2 = <5,3,2,5,u,u,u,u>
; CHECK-NEXT:vpermd %ymm0, %ymm2, %ymm0
; CHECK-NEXT:vptestnmd %xmm1, %xmm1, %k1
; CHECK-NEXT:vmovdqa32 %xmm0, %xmm0 {%k1} {z}
; CHECK-NEXT:vzeroupper
; CHECK-NEXT:retq
%shuf = shufflevector <8 x i32> %vec, <8 x i32> undef, <4 x i32>
%cmp = icmp eq <4 x i32> %mask, zeroinitializer
%res = select <4 x i1> %cmp, <4 x i32> %shuf, <4 x i32> zeroinitializer
ret <4 x i32> %res
}
Ideally, the masking would be included in the shuffle:
vmovdqa {{.*#+}} ymm2 = <5,3,2,5,u,u,u,u>
vptestnmd %xmm1, %xmm1, %k1
vpermd %ymm0, %ymm2, %ymm0 {%k1} {z}
--
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 40333] New: [RISCV] [RV64] SelectionDAG loop due to ANY_EXTEND turned into SIGN_EXTEND and back again to ANY_EXTEND
https://bugs.llvm.org/show_bug.cgi?id=40333 Bug ID: 40333 Summary: [RISCV] [RV64] SelectionDAG loop due to ANY_EXTEND turned into SIGN_EXTEND and back again to ANY_EXTEND Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: Backend: RISC-V Assignee: unassignedb...@nondot.org Reporter: rofir...@gmail.com CC: llvm-bugs@lists.llvm.org Created attachment 21337 --> https://bugs.llvm.org/attachment.cgi?id=21337&action=edit Reduced reproducer Hi all, there is a target-specific combiner in RISCVISelLowering.cpp to convert x = ANY_EXTEND into x = SIGN_EXTEND. Once this happens, there is AND that uses 'x' in "AND x, Constant:i64<255>" and then TargetLowering::SimplifyDemandedBits determines that we don't need a SIGN_EXTEND in this case and changes it back to ANY_EXTEND causing the loop. Combining: t12: i64 = zero_extend t11 Creating new node: t25: i64 = any_extend t10 Creating constant: t26: i64 = Constant<255> Creating new node: t27: i64 = and t25, Constant:i64<255> ... into: t27: i64 = and t25, Constant:i64<255> [...] Combining: t25: i64 = any_extend t10 \ Target combiner Creating new node: t28: i64 = sign_extend t10 | | Replacing.1 t25: i64 = any_extend t10 | | With: t28: i64 = sign_extend t10 | and 0 other values / Combining: t27: i64 = and t28, Constant:i64<255> \ TLO::SimplifyDemandedBits Creating new node: t29: i64 = any_extend t10 | | Replacing.2 t28: i64 = sign_extend t10| | With: t29: i64 = any_extend t10 / The attached testcase is a bugpoint-minimized input from an input in the llvm-test-suite. $ llc -mtriple=riscv64 bugpoint-reduced-simplified.ll -o - -debug Kind regards, Roger -- 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 40334] New: MSP430 changes for release branch
https://bugs.llvm.org/show_bug.cgi?id=40334 Bug ID: 40334 Summary: MSP430 changes for release branch Product: new-bugs Version: 8.0 Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: an...@korobeynikov.info CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org Please merge r351345, r351344 and r351228 to release branch -- 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 40335] New: [clang-format] Don't force non-breaking macro calls
https://bugs.llvm.org/show_bug.cgi?id=40335
Bug ID: 40335
Summary: [clang-format] Don't force non-breaking macro calls
Product: new-bugs
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: dennis.fels...@sap.com
CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org
Hi,
Function calls and initialization lists can include line breaks in their
arguments and clang-format keeps them as they are. When using the EXPECT_THAT
and ElementsAre calls in gmock though clang-format rewrites all arguments to a
single line. Is it possible to make the behaviour of EXPECT_THAT(v,
ElementsAre(...)) more consistent with regular function calls so that the
elements stay on their own lines?
See the following example:
$ clang-format --version
clang-format version 9.0.0 (https://github.com/llvm-mirror/clang
7e968f8a6a2b7d07835493c04dd1989d46970599) (https://github.com/llvm-mirror/llvm
0cb1621554afa8612836c4edfc890fe337320008)
$ cat .clang-format
Language: Cpp
BasedOnStyle: WebKit
Cpp11BracedListStyle: true
$ cat x.cpp
#include
#include
using namespace testing;
int g(int x)
{
return x;
}
int f(int x, int y)
{
return x + y;
}
int main()
{
std::vector v = {1,
2};
g(f(1,
2));
EXPECT_THAT(v, ElementsAre(1,
2));
}
$ clang-format x.cpp
#include
#include
using namespace testing;
int g(int x)
{
return x;
}
int f(int x, int y)
{
return x + y;
}
int main()
{
std::vector v = {1,
2};
g(f(1,
2));
EXPECT_THAT(v, ElementsAre(1,
2));
}
clang-format 4 did just fine here and kept the format that I expect.
Best regards
Dennis
--
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 40336] New: clang-cl diag when using exceptions is unfriendly
https://bugs.llvm.org/show_bug.cgi?id=40336
Bug ID: 40336
Summary: clang-cl diag when using exceptions is unfriendly
Product: clang
Version: unspecified
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: Frontend
Assignee: unassignedclangb...@nondot.org
Reporter: nicolaswe...@gmx.de
CC: llvm-bugs@lists.llvm.org, neeil...@live.com,
richard-l...@metafoo.co.uk
Compare:
C:\src\llvm-mono>cl /c test.cc /nologo
test.cc
test.cc(6): warning C4530: C++ exception handler used, but unwind semantics are
not enabled. Specify /EHsc
C:\src\llvm-mono>out\gn\bin\clang-cl /c test.cc
test.cc(6,3): error: cannot use 'try' with exceptions disabled
try {
For regular clang, exceptions are enabled by default so it's not an issue
there. But clang-cl should mention "/EHsc" in its diag, probably?
--
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 12400 in oss-fuzz: llvm/llvm-opt-fuzzer--x86_64-instcombine: Timeout in llvm_llvm-opt-fuzzer--x86_64-instcombine
Comment #2 on issue 12400 by ClusterFuzz-External: llvm/llvm-opt-fuzzer--x86_64-instcombine: Timeout in llvm_llvm-opt-fuzzer--x86_64-instcombine https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=12400#c2 ClusterFuzz has detected this issue as fixed in range 201901150426:201901160416. Detailed report: https://oss-fuzz.com/testcase?key=5665858515369984 Project: llvm Fuzzer: libFuzzer_llvm_llvm-opt-fuzzer--x86_64-instcombine Fuzz target binary: llvm-opt-fuzzer--x86_64-instcombine Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: Timeout (exceeds 25 secs) Crash Address: Crash State: llvm_llvm-opt-fuzzer--x86_64-instcombine Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201812310412:201901010410 Fixed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201901150426:201901160416 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5665858515369984 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 12488 in oss-fuzz: llvm/clang-fuzzer: Stack-overflow in clang::Lexer::LexTokenInternal
Comment #1 on issue 12488 by ClusterFuzz-External: llvm/clang-fuzzer: Stack-overflow in clang::Lexer::LexTokenInternal https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=12488#c1 ClusterFuzz has detected this issue as fixed in range 201901150426:201901160416. Detailed report: https://oss-fuzz.com/testcase?key=5737567926878208 Project: llvm Fuzzer: libFuzzer_llvm_clang-fuzzer Fuzz target binary: clang-fuzzer Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: Stack-overflow Crash Address: 0x7ffd6a671e60 Crash State: clang::Lexer::LexTokenInternal clang::Lexer::Lex clang::Preprocessor::Lex Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201901080410:201901090413 Fixed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201901150426:201901160416 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5737567926878208 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] [Bug 40337] New: [yaml2obj]Relocations should reference symbols from their linked symbol table
https://bugs.llvm.org/show_bug.cgi?id=40337 Bug ID: 40337 Summary: [yaml2obj]Relocations should reference symbols from their linked symbol table Product: new-bugs Version: unspecified Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: jh7370.2...@my.bristol.ac.uk CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org If you attempt to write a dynamic relocation section, i.e. one that references .dynsym, or indeed any relocation section where the sh_link does not point at .symtab, the symbols referenced by the yaml are treated as symbols in the static symbol table, not necessarily the linked symbol table. Example: !ELF FileHeader: Class: ELFCLASS64 Data:ELFDATA2LSB Type:ET_DYN Machine: EM_X86_64 Sections: - Name: .text Type: SHT_PROGBITS - Name: .rela.dyn Type: SHT_RELA Flags:[ SHF_ALLOC ] Link: .dynsym Info: .text Address: 0x200 AddressAlign: 0x100 EntSize: 0x18 Relocations: - Offset: 0x10 Symbol: _Z3fooi # Ends up with symbol index 0 (i.e. not referencing anything) Type: R_X86_64_PC32 Addend: 0x4 - Offset: 0x10 Symbol: blah# Ends up with symbol index 1 (i.e. _Z3fooi) Type: R_X86_64_PC32 Addend: 0x4 Symbols: Global: - Name: blah DynamicSymbols: Global: - Name: _Z3fooi -- 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 12400 in oss-fuzz: llvm/llvm-opt-fuzzer--x86_64-instcombine: Timeout in llvm_llvm-opt-fuzzer--x86_64-instcombine
Updates: Labels: ClusterFuzz-Verified Status: Verified Comment #3 on issue 12400 by ClusterFuzz-External: llvm/llvm-opt-fuzzer--x86_64-instcombine: Timeout in llvm_llvm-opt-fuzzer--x86_64-instcombine https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=12400#c3 ClusterFuzz testcase 5665858515369984 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 40338] New: Merge r351351 into the 8.0 branch
https://bugs.llvm.org/show_bug.cgi?id=40338 Bug ID: 40338 Summary: Merge r351351 into the 8.0 branch Product: libraries Version: 8.0 Hardware: PC OS: Linux Status: NEW Severity: release blocker Priority: P Component: Backend: AMDGPU Assignee: unassignedb...@nondot.org Reporter: mar...@gmail.com CC: llvm-bugs@lists.llvm.org Hi, I forgot to commit it yesterday before the release_80 branch was created. So here is the late request to merge it. I'd like it in the 8.0 release. Thanks. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 12488 in oss-fuzz: llvm/clang-fuzzer: Stack-overflow in clang::Lexer::LexTokenInternal
Updates: Labels: ClusterFuzz-Verified Status: Verified Comment #2 on issue 12488 by ClusterFuzz-External: llvm/clang-fuzzer: Stack-overflow in clang::Lexer::LexTokenInternal https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=12488#c2 ClusterFuzz testcase 5737567926878208 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 40339] New: [yaml2obj]DynamicSymbols presence should not prevent explicit addresses for .dynsym and .dynstr
https://bugs.llvm.org/show_bug.cgi?id=40339 Bug ID: 40339 Summary: [yaml2obj]DynamicSymbols presence should not prevent explicit addresses for .dynsym and .dynstr Product: new-bugs Version: unspecified Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: jh7370.2...@my.bristol.ac.uk CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org The following yaml input for yaml2obj will result in an address of 0 for both .dynsym and .dynstr despite the explicit address value. There is no good reason for this that I can think of: !ELF FileHeader: Class: ELFCLASS64 Data:ELFDATA2LSB Type:ET_DYN Machine: EM_X86_64 Sections: - Name: .dynstr Type: SHT_STRTAB Flags:[ SHF_ALLOC ] Address: 0x1000 EntSize: 0x1 - Name: .dynsym Type: SHT_DYNSYM Flags:[ SHF_ALLOC ] Address: 0x2000 EntSize: 0x18 DynamicSymbols: Global: - Name: foo -- 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 40340] New: [X86] Add selective commutation support for insertps
https://bugs.llvm.org/show_bug.cgi?id=40340
Bug ID: 40340
Summary: [X86] Add selective commutation support for insertps
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: craig.top...@gmail.com, llvm-bugs@lists.llvm.org,
llvm-...@redking.me.uk, spatel+l...@rotateright.com
https://godbolt.org/z/bhohSK
#include
__m128 ii(__m128 x, __m128 *y) {
return _mm_insert_ps(*y, x, (1<<6) | (1<<4) | 5);
}
define <4 x float> @_Z2iiDv4_fPS_(<4 x float>, <4 x float>* nocapture readonly)
{
%3 = load <4 x float>, <4 x float>* %1, align 16
%4 = tail call <4 x float> @llvm.x86.sse41.insertps(<4 x float> %3, <4 x
float> %0, i8 85)
ret <4 x float> %4
}
declare <4 x float> @llvm.x86.sse41.insertps(<4 x float>, <4 x float>, i8) #1
_Z2iiDv4_fPS_: # @_Z2iiDv4_fPS_
vmovaps (%rdi), %xmm1
vinsertps $85, %xmm0, %xmm1, %xmm0 # xmm0 = zero,xmm0[1],zero,xmm1[3]
retq
When we have 1 "inline" element from each source and zeros everywhere else we
should be able to commute the immediate to allow the memory fold.
--
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 39676] clang segfault
https://bugs.llvm.org/show_bug.cgi?id=39676 Reid Kleckner changed: What|Removed |Added CC||r...@google.com Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Reid Kleckner --- I downloaded the sources, and this doesn't reproduce with the latest clang for me. -- 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 40310] [SLP] slp-vectorizer-hor miscompiles unrolled AND
https://bugs.llvm.org/show_bug.cgi?id=40310 Fedor Sergeev changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #19 from Fedor Sergeev --- Fixed by https://reviews.llvm.org/rL351349 -- 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 40331] [meta] 8.0.0 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=40331 Bug 40331 depends on bug 40310, which changed state. Bug 40310 Summary: [SLP] slp-vectorizer-hor miscompiles unrolled AND https://bugs.llvm.org/show_bug.cgi?id=40310 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 40342] New: Bad RuleMatcher static_cast in GlobalISelEmitter
https://bugs.llvm.org/show_bug.cgi?id=40342 Bug ID: 40342 Summary: Bad RuleMatcher static_cast in GlobalISelEmitter Product: new-bugs Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: jacobly@gmail.com CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org Created attachment 21339 --> https://bugs.llvm.org/attachment.cgi?id=21339&action=edit Add RTTI to the Matcher class causing build failure. I was making some changes to TableGen's GlobalISelEmitter.cpp and I started getting random crashes. After adding LLVM-style RTTI to Matcher and its 3 subclasses I was able to catch an incorrect static_cast in GroupMatcher::emit which is trying to cast from Matcher to RuleMatcher when the actual type is GroupMatcher. This appears to cause so few issues because the passed parameter is only used by a couple of the emitPredicateOpcodes overrides. This item seems to be added to the Matcher array in GlobalISelEmitter::optimizeRules on the line OptRules.push_back(CurrentGroup.get());. Repro is to apply the attached patch and attempt a debug build which triggers a cast assertion. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 40331] [meta] 8.0.0 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=40331 Bug 40331 depends on bug 40310, which changed state. Bug 40310 Summary: [SLP] slp-vectorizer-hor miscompiles unrolled AND https://bugs.llvm.org/show_bug.cgi?id=40310 What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 40310] [SLP] slp-vectorizer-hor miscompiles unrolled AND
https://bugs.llvm.org/show_bug.cgi?id=40310 Simon Pilgrim changed: What|Removed |Added Status|RESOLVED|REOPENED Fixed By Commit(s)||351349 Resolution|FIXED |--- --- Comment #20 from Simon Pilgrim --- Keeping this open until its merged into the 8.00 release branch -- 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 37358] SIMD Misoptimization during "Promote 'by reference' arguments to scalars on SCC"
https://bugs.llvm.org/show_bug.cgi?id=37358 Alex Crichton changed: What|Removed |Added Status|CONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #17 from Alex Crichton --- Thanks so much for landing the fix! We're updating rust-lang/rust in https://github.com/rust-lang/rust/pull/57675 and I'll start running some tests with that once it's in-tree. In the meantime I'll go head and close this as resolved, and I'll follow-up with more issues if they crop up, but I suspect we should be good to go! -- 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 39106] [meta] 7.0.1 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=39106 Bug 39106 depends on bug 37358, which changed state. Bug 37358 Summary: SIMD Misoptimization during "Promote 'by reference' arguments to scalars on SCC" https://bugs.llvm.org/show_bug.cgi?id=37358 What|Removed |Added Status|CONFIRMED |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 40343] New: [X86] Merge r351381 to 8.0 branch
https://bugs.llvm.org/show_bug.cgi?id=40343 Bug ID: 40343 Summary: [X86] Merge r351381 to 8.0 branch Product: libraries Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: Backend: X86 Assignee: unassignedb...@nondot.org Reporter: craig.top...@gmail.com CC: craig.top...@gmail.com, llvm-bugs@lists.llvm.org, llvm-...@redking.me.uk, spatel+l...@rotateright.com This fixes a potential miscompile with some AVX shift intrinsics. -- 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 40329] Operator overload matching failure with enum as first operand
https://bugs.llvm.org/show_bug.cgi?id=40329 Richard Smith changed: What|Removed |Added Fixed By Commit(s)||351382 Resolution|--- |FIXED Status|CONFIRMED |RESOLVED --- Comment #3 from Richard Smith --- Fixed in r351382. -- 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 37303] LLD + -fsanitize=address segfaults in scandir.
https://bugs.llvm.org/show_bug.cgi?id=37303 Peter Wu changed: What|Removed |Added Resolution|--- |FIXED Fixed By Commit(s)||r351396 Status|REOPENED|RESOLVED --- Comment #11 from Peter Wu --- Fixed in r351396, Rui will request a cherry-pick for the 8.0 release branch. -- 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 40344] New: designated initializers accepted when c++11 standard requested
https://bugs.llvm.org/show_bug.cgi?id=40344 Bug ID: 40344 Summary: designated initializers accepted when c++11 standard requested Product: clang Version: trunk Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: C++11 Assignee: unassignedclangb...@nondot.org Reporter: andi.m.mccl...@gmail.com CC: blitzrak...@gmail.com, dgre...@apple.com, erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org, richard-l...@metafoo.co.uk Created attachment 21342 --> https://bugs.llvm.org/attachment.cgi?id=21342&action=edit main.cpp WHY I CARE VERSIONS My tests were: Apple LLVM version 9.0.0 (clang-900.0.39.2) Target: x86_64-apple-darwin17.3.0 -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 40345] New: Function merging pass miscompiles identical vararg functions
https://bugs.llvm.org/show_bug.cgi?id=40345
Bug ID: 40345
Summary: Function merging pass miscompiles identical vararg
functions
Product: libraries
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: Interprocedural Optimizations
Assignee: unassignedb...@nondot.org
Reporter: v...@apple.com
CC: llvm-bugs@lists.llvm.org
Example:
```
#include
void escape(int);
void simple_va(const char* fmt, ...)
{
va_list args;
va_start(args, fmt);
int i = va_arg(args, int);
escape(i);
va_end(args);
}
void simple_va2(const char* fmt, ...)
{
va_list args;
va_start(args, fmt);
int i = va_arg(args, int);
escape(i);
va_end(args);
}
```
Clang emits (https://godbolt.org/z/C54W53):
```
; Function Attrs: minsize optsize uwtable
define dso_local void @_Z9simple_vaPKcz(i8* nocapture readnone, ...)
local_unnamed_addr #3 {
tail call void (i8*, ...) @_Z10simple_va2PKcz(i8* nocapture readnone %0) #3
ret void
}
```
--
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 40344] designated initializers accepted when c++11 standard requested
https://bugs.llvm.org/show_bug.cgi?id=40344 Andi McClure changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #1 from Andi McClure --- I DID NOT MEAN TO PRESS THE "SUBMIT" BUTTON. I sincerely apologize. By the way, your "submit" and "add an attachment" buttons are very close together. -- 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 40346] New: Clang generates unnecessary vectorized code for _mm_popcnt_u64
https://bugs.llvm.org/show_bug.cgi?id=40346
Bug ID: 40346
Summary: Clang generates unnecessary vectorized code for
_mm_popcnt_u64
Product: libraries
Version: 7.0
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Backend: X86
Assignee: unassignedb...@nondot.org
Reporter: m...@adhokshajmishraonline.in
CC: craig.top...@gmail.com, llvm-bugs@lists.llvm.org,
llvm-...@redking.me.uk, spatel+l...@rotateright.com
Created attachment 21343
--> https://bugs.llvm.org/attachment.cgi?id=21343&action=edit
Test source code, dumped assmebler source code, and LLVM IR code
Clang is generating technically correct (behaviour of code is preserved), but
very slow code with no POPCNT instruction, and too much vectorization when
_mm_popcnt_u64() intrinsic is used with -O2 and -O3.
NOTE
1. When code is compiled with -O1, there is no unnecessary vectorization, and
generated code almost expected, but compiler fails to take false dependency of
these instructions into account, which results in slower code.
2. I tested the poc with LZCNT and TZCNT as well. Again, compiler does not
account for false dependency; although no unnecessary vectorization is present.
Behaviour in (1) and (2) is consistent with bug #33869.
G++ on the other han, generates correct code, and deals with false dependency
correctly. Code generated by G++ has been provided for reference.
Platform Details
CPU: Intel(R) Core(TM) i7-6700HQ CPU
OS:Arch Linux x86_64 Kernel Version 4.20.1-arch1-1-ARCH
Compilers: g++ (GCC) 8.2.1 20181127
clang version 7.0.1 (tags/RELEASE_701/final)
Test Code
==
#include
#include
#include
int main(int argc, char* argv[]) {
using namespace std;
uint64_t size = 10<<20;
uint64_t* buffer = new uint64_t[size/8];
char* charbuffer = reinterpret_cast(buffer);
for (unsigned i=0; i startP,endP;
{
startP = chrono::system_clock::now();
count=0;
for( unsigned k = 0; k < 1; k++){
// Tight unrolled loop with uint64_t
for (uint64_t i=0;i(endP-startP).count();
cout << "Counter\t" << count << "\tSpeed\t" <<
(1.0*size)/(duration) << " GB/s" << endl;
}
free(charbuffer);
}
OUTPUT (POPCNT)
===
By GCC
--
[code snipped]
...
movr13,rax
xorebx,ebx
xoredx,edx
xoreax,eax
popcnt rax,QWORD PTR [r14+0x8]
popcnt rdx,QWORD PTR [r14]
addrdx,rax
xoreax,eax
popcnt rax,QWORD PTR [r14+0x10]
addrdx,rax
xoreax,eax
popcnt rax,QWORD PTR [r14+0x18]
addrdx,rax
moveax,0x2710
nopDWORD PTR [rax+0x0]
addrbx,rdx
deceax
jne1150
addr14,0x20
cmpr14,rbp
jne111c
...
[code snipped]
By Clang
Note: please refer to attachment for complete listing.
[code snipped]
...
vpbroadcastq ymm2,QWORD PTR [rip+0xe26]
vpbroadcastq ymm4,QWORD PTR [rip+0xe25]
vpbroadcastq ymm7,QWORD PTR [rip+0xe24]
vbroadcastsd ymm0,QWORD PTR [rip+0xe23]
vmovups YMMWORD PTR [rsp+0x80],ymm0
vmovdqa ymm5,YMMWORD PTR [rip+0xd9a]
vmovdqa ymm6,YMMWORD PTR [rip+0xdb2]
vbroadcastsd ymm0,QWORD PTR [rip+0xe09]
vmovups YMMWORD PTR [rsp+0x60],ymm0
vpbroadcastq ymm0,QWORD PTR [rip+0xe02]
vmovdqu YMMWORD PTR [rsp+0x40],ymm0
vpbroadcastq ymm8,QWORD PTR [rip+0xdfb]
xorr15d,r15d
vmovdqu YMMWORD PTR [rsp+0xe0],ymm2
vmovdqu YMMWORD PTR [rsp+0xc0],ymm4
vmovdqu YMMWORD PTR [rsp+0xa0],ymm7
vmovdqu YMMWORD PTR [rsp+0x20],ymm8
nopDWORD PTR [rax+0x0]
vmovq xmm1,r15
moveax,0x5
vmovdqa ymm11,YMMWORD PTR [rip+0xd0e]
vpxor xmm3,xmm3,xmm3
vpxor xmm15,xmm15,xmm15
vpxor xmm0,xmm0,xmm0
nop
vpaddq ymm12,ymm11,ymm2
vpaddq ymm13,ymm11,ymm4
vpaddq ymm14,ymm11,ymm7
vpcmpeqd ymm2,ymm2,ymm2
vpgatherqq ymm4,QWORD PTR [rbx+ymm11*8],ymm2
vpcmpeqd ymm2,ymm2,ymm2
vpgatherqq ymm8,QWORD PTR [rbx+ymm12*8],ymm2
vpcmpeqd ymm2,ymm2,ymm2
vpgatherqq ymm10,QWORD PTR [rbx+ymm13*8],ymm2
vpcmpeqd ymm2,ymm2,ymm2
vpgatherqq ymm9,QWORD PTR [rbx+ymm14*8],ymm2
vpand ymm2,ymm4,ymm5
vpshufb ymm2,ymm6,ymm2
vpsrlw ymm4,ymm4,0x4
vpand ymm4,ymm4,ymm5
vpshufb ymm4,ymm6,ymm4
vpaddb ymm2,ymm4,ymm2
vpsadbw ymm2,ymm2,YMMWORD PTR [rip+0xd09]
vpaddq ymm1,ymm2,ymm1
vmovdqu YMMWORD PTR [rsp],ymm1
vpand ymm2,ymm8,ymm5
vpshufb ymm2,ymm6,ymm2
vpsrlw ymm4,ymm8,0x4
vpand ymm4,ymm4,ymm5
vpshufb ymm4,ymm6,ymm4
vpaddb ymm2,ymm4,ymm2
vpsadbw ymm2,ymm2,YMMWORD PTR [rip+0xcdc]
...
[code snipped]
OUTPUT (TZCNT)
==
By GCC
--
[code snipped]
...
movr13,rax
xorebx,ebx
xoredi,edi
xoredx,edx
tzcnt rdi,QWORD PTR [r14]
tzcnt rdx,QWORD PTR [r14+0x8]
xoresi,esi
tzcnt rsi,QWORD PTR [r14+0x10]
xorecx,ecx
tzcnt rcx,QWORD PTR [r14+0x18]
addrdx,rdi
addrdx,rsi
moveax,0x2710
addrdx,rcx
nopDWORD PTR [rax+0x0]
addrbx,rdx
deceax
jne1150
addr14,0
[llvm-bugs] [Bug 40347] New: designated initializers (c99 feature) accepted when c++11 standard requested
https://bugs.llvm.org/show_bug.cgi?id=40347
Bug ID: 40347
Summary: designated initializers (c99 feature) accepted when
c++11 standard requested
Product: clang
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: C++11
Assignee: unassignedclangb...@nondot.org
Reporter: andi.m.mccl...@gmail.com
CC: blitzrak...@gmail.com, dgre...@apple.com,
erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org,
richard-l...@metafoo.co.uk
Created attachment 21344
--> https://bugs.llvm.org/attachment.cgi?id=21344&action=edit
BUILD SCRIPT FOR MAIN.CPP
REPRO STEPS
Here's a simple program.
//
#include "stdio.h"
#define LEFT 0
#define RIGHT 1
const char *test[] = {
[LEFT] = "left",
[RIGHT] = "right",
};
int main() {
printf("%s\n", test[LEFT]);
return 0;
}
//
I save this as main.cpp. I build this using the attached CMakeLists.txt, which
happens to produce the invocation line:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++
-std=c++11 -o CMakeFiles/clangtest.dir/main.cpp.o -c
/Users/mcc/work/h/clangbug/main.cpp
EXPECTED BEHAVIOR
This program should not compile. The [LEFT]= [RIGHT]= stuff is an example of
the "designated initializer" feature. This is a feature of C99, but I
understand it is not a feature of C++11. I do not find it in the N3242 draft
(section 8.5, "Initializers") and several people I trust assure me that it is
not a C++11 feature.
The fact I requested -std=c++11 implies that the C++11 standard is what I
wanted, not some significantly amended standard.
OBSERVED BEHAVIOR
The program works and prints "left".
If I add to the command line -Werror=c99-extensions, or add to the CMakeLists
set (CMAKE_CXX_FLAGS -Werror=c99-extensions), it fails with the helpful error
message "designated initializers are a C99 feature".
COMMENTS / "WHY I CARE"
The context of this bug report is that I have a program which must work cross
platform. In particular it must compile in standard OS X Clang, in standard
Android Native Development Kit Clang, and in standard Microsoft Visual Studio.
I do not always have access to my Visual Studio workstation, and so it is a
great imposition if when I sit down at my Visual Studio workstation I discover
only then that the program does not compile. The best way I know to ensure that
it will compile in Visual Studio is to target the standard, which Microsoft is
much better now at following than they used to be. I try to get my compilers to
target the standard by placing this in my CMakeLists.txt:
set (CMAKE_CXX_STANDARD 11)
set (CMAKE_CXX_EXTENSIONS OFF)
The way CMake interprets my request for EXTENSIONS OFF when targeting clang is
to insert -std=c++11 when invoking clang. If EXTENSIONS is ON or is not set, it
passes -std=gnu++11 . In other words, at least one major open source project
jumped to the same conclusion I did in my "EXPECTED BEHAVIOR", that std=c++11
means the unadorned standard and this is in fact the reasoning for separating
c++11 and gnu++11.
Today I needed to do a quick test of my project on Windows. I checked out and
built. It did not work. MSVC failed (correctly) on the designated initializer
line. That had snuck in at some point and I did not know it was not valid C++.
I had to waste time at a very inconvenient moment trying to understand why it
wasn't compiling. Ironically, I think? that MSVC in other modes *will* support
C99 features in C++, but for this build I had requested the C++11 standard so
apparently that's what it applied. -std=c++11 had not succeeded at the task I
wanted it for.
THE THIRD STAGE OF GRIEF IS BARGAINING
I don't know what kinds of considerations resulted in -std=C++11 mode including
C99 extensions. Maybe this is as-intended. (I'd personally prefer Clang allow
C99 features in C++, *if* I wasn't on a project where portability is
important.) However *even if* this is as-intended, this is *still* a bug
insofar as it is a documentation bug. If I look at
https://clang.llvm.org/docs/ClangCommandLineReference.html
all it says re: -std is
"-std=, --std=, --std
Language standard to compile for"
`man clang` on OS X says the same.
There is a separate page,
https://clang.llvm.org/cxx_status.html
which discusses C++ compliance status. It flatly says "Clang 3.3 and later
implement all of the ISO C++ 2011 standard." and gives *no* indication of a
major divergence like C99 extensions. (Given the level of detail on this page,
I would call such an omission actively misleading.)
The important thing to me is things should be predictable. I should be able to
predict what my builds will do based on the documentation.
I would expect that the -std= documentation would tell me what the options for
-std are, or how to look up what th
[llvm-bugs] [Bug 40348] New: At least -mno-outline and -mllvm should be redirected somehow to the linker when using LTO
https://bugs.llvm.org/show_bug.cgi?id=40348 Bug ID: 40348 Summary: At least -mno-outline and -mllvm should be redirected somehow to the linker when using LTO Product: new-bugs Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: mh+l...@glandium.org CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org If you use `-mno-outline` along `-flto` with clang, the linker (which does the actual compiling) is not instructed that it should disable the outliner. Same if you use `-mllvm -enable-machine-outliner=never`. Other flags, like -march=something are translated to linker plugin options when used at link time. Some flags, when used at compile time, end up in the object files and are used automatically at link time with LTO (-march does that too, in fact). -- 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 40349] New: "max" and "min" in std namespace even when not included
https://bugs.llvm.org/show_bug.cgi?id=40349
Bug ID: 40349
Summary: "max" and "min" in std namespace even when
not included
Product: libc++
Version: unspecified
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: All Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: andi.m.mccl...@gmail.com
CC: llvm-bugs@lists.llvm.org, mclow.li...@gmail.com
REPRO STEPS
Here's a simple program.
#include
int main() {
int x = std::max(3, 4);
return x;
}
For purposes of this repro, it appears you can replace with literally any
STL header, , , , as far as I can tell anything.
I performed this test both on my local computer (OS X 10.13.2, Apple LLVM
version 9.0.0 (clang-900.0.39.2) target x86_64-apple-darwin17.3.0) and on
"godbolt.org", where I tested it with "x86-64 clang 7.0.0 " and tested with and
without each of -stdlib=libc++ and -stdlib=libstdc++ and with and without
-std=c++11.
OBSERVED BEHAVIOR
Program compiles. Returns status code 4 when run.
EXPECTED BEHAVIOR
This program should not compile. Both cppreference.com and the N3242 draft
standard for C++ place std::max and std::min in . N3242 specifies
that , and should all include and
lists no other includes. There is no reason why std::max would be accessible.
WHY I CARE
When Clang is loosey goosey about following the standard but MSVC is strict,
this creates problems for me because I accidentally write noncompliant code,
run it for long periods locally believing it is correct code, and then as soon
as I check out and build on Windows I discover I have to perform a bunch of
modifications. (I have filed another bug,
https://bugs.llvm.org/show_bug.cgi?id=40347 , which goes into some detail as to
why this is bad for me.) The program up top does NOT compile on Visual Studio
15.0 (Aka Visual Studio 2017).
MSVC has not always been as good about following the standards as it is right
now. However, one thing MSVC has been consistent about for a LONG time has been
that std::max and std::min ALWAYS require to be included, and I
ALWAYS forget to require because I'm locally using clang, and so
the minute I check out new code on Windows I have to run around adding #include
. This specific thing has been an annoyance for years.
A COMPROMISE?
Maybe there is some good reason clang/libc++ does not follow the standard on
this, such as backward compatibility. I personally do find it annoying to have
to include and when casually coding I like it that std::max and
std::min are always just there. BUT, if this behavior is as-intended, I would
like to have some way of getting a standard-compliant STL *on-demand*, such as
a documented command-line argument to clang "-stdlib=please actually follow the
standard", so I can get consistency across platforms.
--
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 40350] New: Logic error that should not be reported (Converting a pointer value of type 'NSNumber *' to a primitive boolean value)
https://bugs.llvm.org/show_bug.cgi?id=40350
Bug ID: 40350
Summary: Logic error that should not be reported (Converting a
pointer value of type 'NSNumber *' to a primitive
boolean value)
Product: clang
Version: unspecified
Hardware: Macintosh
OS: MacOS X
Status: NEW
Severity: enhancement
Priority: P
Component: Static Analyzer
Assignee: dcough...@apple.com
Reporter: o...@aggressive.se
CC: dcough...@apple.com, llvm-bugs@lists.llvm.org
Common code like this:
NSNumber *num = [attributes objectForKey:key];
if (num)
{
num.intValue ... etc.
}
Generates this warning/error:
"Converting a pointer value of type 'NSNumber *' to a primitive boolean value;
instead, either compare the pointer to nil or call -boolValue"
Should not be reported, or be smarter - like if the number is actually being
used as a boolean and not as any other number. Like this:
//this should be ok, here it's clear how the variable is being used:
NSNumber *num = [attributes objectForKey:key];
if (num)
{
_someValue = num.intValue;
}
//this is not ok:
NSNumber *num = [attributes objectForKey:key];
if (num)
{
int somNumber = 5;
attributes[key] = @(someNumber); //num is only used as a bool.
}
--
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 40351] New: ThinLTO/X86/cfi-devirt.ll test appears flaky
https://bugs.llvm.org/show_bug.cgi?id=40351 Bug ID: 40351 Summary: ThinLTO/X86/cfi-devirt.ll test appears flaky Product: libraries Version: trunk Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: Interprocedural Optimizations Assignee: unassignedb...@nondot.org Reporter: v...@tsyrklevich.net CC: llvm-bugs@lists.llvm.org, pe...@pcc.me.uk, tejohn...@google.com While trying to identify instances of an msan test flake, I also found that this test is flaking on multiple bots, e.g. some example failures: http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-bootstrap-msan/builds/9865/steps/annotate/logs/stdio http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-bootstrap-msan/builds/9862/steps/check-llvm%20check-clang%20stage3%2Fmsan/logs/stdio http://lab.llvm.org:8011/builders/clang-with-thin-lto-ubuntu/builds/14927/steps/test-stage1-compiler/logs/stdio Unfortunately the test failure itself doesn't print any useful indication as to where it's failing: FAIL: LLVM :: ThinLTO/X86/cfi-devirt.ll (23018 of 29363) TEST 'LLVM :: ThinLTO/X86/cfi-devirt.ll' FAILED Script: -- : 'RUN: at line 5'; /b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm_build2_msan/bin/opt -thinlto-bc -thinlto-split-lto-unit -o /b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm_build2_msan/test/ThinLTO/X86/Output/cfi-devirt.ll.tmp.o /b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm/test/ThinLTO/X86/cfi-devirt.ll : 'RUN: at line 9'; /b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm_build2_msan/bin/llvm-lto2 run /b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm_build2_msan/test/ThinLTO/X86/Output/cfi-devirt.ll.tmp.o -save-temps -pass-remarks=.-verify-machineinstrs=0-o /b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm_build2_msan/test/ThinLTO/X86/Output/cfi-devirt.ll.tmp3 -r=/b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm_build2_msan/test/ThinLTO/X86/Output/cfi-devirt.ll.tmp.o,test,px -r=/b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm_build2_msan/test/ThinLTO/X86/Output/cfi-devirt.ll.tmp.o,_ZN1A1nEi,p -r=/b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm_build2_msan/test/ThinLTO/X86/Output/cfi-devirt.ll.tmp.o,_ZN1B1fEi,p -r=/b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm_build2_msan/test/ThinLTO/X86/Output/cfi-devirt.ll.tmp.o,_ZN1C1fEi,p -r=/b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm_build2_msan/test/ThinLTO/X86/Output/cfi-devirt.ll.tmp.o,empty,p -r=/b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm_build2_msan/test/ThinLTO/X86/Output/cfi-devirt.ll.tmp.o,_ZTV1B, -r=/b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm_build2_msan/test/ThinLTO/X86/Output/cfi-devirt.ll.tmp.o,_ZTV1C, -r=/b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm_build2_msan/test/ThinLTO/X86/Output/cfi-devirt.ll.tmp.o,_ZN1A1nEi, -r=/b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm_build2_msan/test/ThinLTO/X86/Output/cfi-devirt.ll.tmp.o,_ZN1B1fEi, -r=/b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm_build2_msan/test/ThinLTO/X86/Output/cfi-devirt.ll.tmp.o,_ZN1C1fEi, -r=/b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm_build2_msan/test/ThinLTO/X86/Output/cfi-devirt.ll.tmp.o,_ZTV1B,px -r=/b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm_build2_msan/test/ThinLTO/X86/Output/cfi-devirt.ll.tmp.o,_ZTV1C,px 2>&1 | /b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm_build2_msan/bin/FileCheck /b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm/test/ThinLTO/X86/cfi-devirt.ll --check-prefix=REMARK : 'RUN: at line 24'; /b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm_build2_msan/bin/llvm-dis /b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm_build2_msan/test/ThinLTO/X86/Output/cfi-devirt.ll.tmp3.1.4.opt.bc -o - | /b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm_build2_msan/bin/FileCheck /b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm/test/ThinLTO/X86/cfi-devirt.ll --check-prefix=CHECK-IR : 'RUN: at line 28'; /b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm_build2_msan/bin/llvm-lto2 run /b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm_build2_msan/test/ThinLTO/X86/Output/cfi-devirt.ll.tmp.o -save-temps -use-new-pm -pass-remarks=.-verify-machineinstrs=0-o /b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm_build2_msan/test/ThinLTO/X86/Output/cfi-devirt.ll.tmp3 -r=/b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm_build2_msan/test/ThinLTO/X86/Output/cfi-devirt.ll.tmp.o,test,px -r=/b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm_build2_msan/test/ThinLTO/X86/Output/cfi-devirt.ll.tmp.o,_ZN1A1nEi,p -r=/b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm_build2_msan/test/ThinLTO/X86/Output/cfi-devirt.ll.tmp.o,_ZN1B1fEi,p -r=/b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm_build2_msan/test/ThinLTO/X86/Output/cfi-devirt.ll.tmp.o,
