[llvm-bugs] [Bug 36777] Fails to emit symbols when extern "C++" used in version script for symbols with [abi:cxx11] tag
https://bugs.llvm.org/show_bug.cgi?id=36777 Fangrui Song changed: What|Removed |Added CC||i...@maskray.me Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Fangrui Song --- This should have been fixed at some point. The output of `llvm-readelf --dyn-syms t.so` matches that of `readelf --dyn-syms t.so` The check lines need some adjustment: # CHECK: Name: _Z14accepts_stringRKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE@@VER1 # CHECK-NEXT: Value: 0 # CHECK-NEXT: Size: 0 # CHECK-NEXT: Binding: Global # CHECK-NEXT: Type: Function # CHECK-NEXT: Other: 0 # CHECK-NEXT: Section: .text # CHECK: Name: _Z14returns_stringB5cxx11v@@VER1 # CHECK-NEXT: Value: 0 # CHECK-NEXT: Size: 0 # CHECK-NEXT: Binding: Global # CHECK-NEXT: Type: Function # CHECK-NEXT: Other: 0 # CHECK-NEXT: Section: .text _Z14returns_stringB5cxx11v has local binding so it is not in .dynsym -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 40914] New: memory.copy on alloca addresses crashes
https://bugs.llvm.org/show_bug.cgi?id=40914
Bug ID: 40914
Summary: memory.copy on alloca addresses crashes
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: CONFIRMED
Severity: enhancement
Priority: P
Component: Backend: WebAssembly
Assignee: tliv...@google.com
Reporter: tliv...@google.com
CC: llvm-bugs@lists.llvm.org
llc -mattr=+bulk-memory fails with the following IR:
target triple = "wasm32-unknown-unknown"
declare void @llvm.memcpy.p0i8.p0i8.i32(i8*, i8*, i32, i1)
define void @memcpy_alloca() {
%p = alloca i8
call void @llvm.memcpy.p0i8.p0i8.i32(i8* undef, i8* %p, i32 16, i1 false)
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
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 40913] New: False positive about Use of memory after it is freed for OpenJDK
https://bugs.llvm.org/show_bug.cgi?id=40913 Bug ID: 40913 Summary: False positive about Use of memory after it is freed for OpenJDK Product: clang Version: trunk Hardware: Other OS: Linux Status: NEW Severity: normal Priority: P Component: Static Analyzer Assignee: dcough...@apple.com Reporter: zhaixi...@loongson.cn CC: dcough...@apple.com, llvm-bugs@lists.llvm.org Hi, Bug reported by the clang static analyzer. Description: Use of memory after it is freed File: /home/loongson/zhaixiang/jdk12-mips-llvm/src/java.base/share/native/libverify/check_code.c[1] Line: 1328 Preprocessed file[2] is available. I argue that Use of memory after it is freed is *False Positive* - 8< 8< 8< 8< 8< 8< --- src/java.base/share/native/libverify/check_code.c:1328:22: warning: Use of memory after it is freed clazz_info = cp_index_to_class_fullinfo(context, key, ^~~~ - 8< 8< 8< 8< 8< 8< --- Full analyzer log and invocation[3] is available too. Please change include file path, for example, /home/loongson/zhaixiang/jdk12-mips-llvm/src/java.base/share/native/libjava change to YOUR_OPENJDK_SRC_DIR/src/java.base/share/native/libjava Perhaps it doesn't need to include the *build* directories, otherwise it is difficult to reproduce the issue :) Cheers, Leslie Zhai [1] http://hg.openjdk.java.net/jdk/jdk12/file/0276cba45aac/src/java.base/share/native/libverify/check_code.c#l1328 [2] https://raw.githubusercontent.com/xiangzhai/jdk-dev/master/check_code.c [3] https://raw.githubusercontent.com/xiangzhai/jdk-dev/master/check_code_analyzer.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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 40912] New: ISel crashes on SIMD setcc / setlt
https://bugs.llvm.org/show_bug.cgi?id=40912 Bug ID: 40912 Summary: ISel crashes on SIMD setcc / setlt Product: libraries Version: trunk Hardware: PC OS: Linux Status: CONFIRMED Severity: enhancement Priority: P Component: Backend: WebAssembly Assignee: tliv...@google.com Reporter: tliv...@google.com CC: llvm-bugs@lists.llvm.org, s...@google.com Reported error was LLVM ERROR: Cannot select: t65: v4i32 = setcc t13, t17, setlt:ch t13: v4f32 = fmul nnan ninf nsz contract afn reassoc t11, t11 t11: v4f32,ch = load<(load 16 from %ir.lsr.iv190192, !tbaa !32)> t0, t2, undef:i32 t2: i32,ch = CopyFromReg t0, Register:i32 %107 t1: i32 = Register %107 t10: i32 = undef t11: v4f32,ch = load<(load 16 from %ir.lsr.iv190192, !tbaa !32)> t0, t2, undef:i32 t2: i32,ch = CopyFromReg t0, Register:i32 %107 t1: i32 = Register %107 t10: i32 = undef t17: v4f32 = fsub nnan ninf nsz contract afn reassoc t16, t14 t16: v4f32 = BUILD_VECTOR ConstantFP:f32<4.00e+00>, ConstantFP:f32<4.00e+00>, ConstantFP:f32<4.00e+00>, ConstantFP:f32<4.00e+00> t15: f32 = ConstantFP<4.00e+00> t15: f32 = ConstantFP<4.00e+00> t15: f32 = ConstantFP<4.00e+00> t15: f32 = ConstantFP<4.00e+00> t14: v4f32 = fmul nnan ninf nsz contract afn reassoc t12, t12 t12: v4f32,ch = load<(load 16 from %ir.lsr.iv184186, !tbaa !35)> t0, t4, undef:i32 t4: i32,ch = CopyFromReg t0, Register:i32 %108 t3: i32 = Register %108 t10: i32 = undef t12: v4f32,ch = load<(load 16 from %ir.lsr.iv184186, !tbaa !35)> t0, t4, undef:i32 t4: i32,ch = CopyFromReg t0, Register:i32 %108 t3: i32 = Register %108 t10: i32 = undef -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 40911] New: vector ctlz is not expanded
https://bugs.llvm.org/show_bug.cgi?id=40911 Bug ID: 40911 Summary: vector ctlz is not expanded Product: libraries Version: trunk Hardware: PC OS: Linux Status: CONFIRMED Severity: enhancement Priority: P Component: Backend: WebAssembly Assignee: tliv...@google.com Reporter: tliv...@google.com CC: llvm-bugs@lists.llvm.org, s...@google.com But it should be. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 39799] LLD's /GUARD:CF relocation scanning heuristic ignores address-taken import thunks
https://bugs.llvm.org/show_bug.cgi?id=39799 Reid Kleckner changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Reid Kleckner --- Fixed in r355141, but it sounds like the Rust issue was actually https://reviews.llvm.org/D53540#1326473, which will be fixed when Rust pulls that in. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 40910] New: clang-format broken after lambda with return type template with boolean literal
https://bugs.llvm.org/show_bug.cgi?id=40910
Bug ID: 40910
Summary: clang-format broken after lambda with return type
template with boolean literal
Product: clang
Version: 8.0
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Formatter
Assignee: unassignedclangb...@nondot.org
Reporter: nikol...@nikolaus-demmel.de
CC: djas...@google.com, kli...@google.com,
llvm-bugs@lists.llvm.org
Clang format breaks on lambdas with return types that have literal booleans in
template arguments, e.g.
[]() -> foo { ; }();
The same works fine e.g. with integer literals. I tried version 7, 8, and
current version 9 from the Ubuntu Xenial apt repo and the behaviour is the same
everywhere. I narrowed it down to the following small test case:
template
using foo = void;
// works:
[]() -> foo<1> { ; }();
// broken:
[]() -> foo { ; }();
namespace bar {
// broken:
auto foo{[]() -> foo { ; }};
} // namespace bar
I would expect clang-format (without additional options) to not change anything
here (which is the case if I replace 'true' / 'false' with e.g. '1', but the
actual result is as follows, which is particularly problematic in the presence
of namespaces as you can see:
template
using foo = void;
// works:
[]() -> foo<1> { ; }();
// broken:
[]() -> foo { ; }
();
namespace bar {
// broken:
auto foo{[]() -> foo{;
} // namespace bar
}
;
} // namespace bar
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 40909] New: Cherry-pick r352465 to 8.0
https://bugs.llvm.org/show_bug.cgi?id=40909 Bug ID: 40909 Summary: Cherry-pick r352465 to 8.0 Product: libraries Version: trunk Hardware: PC URL: https://reviews.llvm.org/rL352465 OS: All Status: NEW Severity: enhancement Priority: P Component: Backend: AArch64 Assignee: unassignedb...@nondot.org Reporter: mar...@martin.st CC: arnaud.degrandmai...@arm.com, efrie...@quicinc.com, h...@chromium.org, llvm-bugs@lists.llvm.org, peter.sm...@linaro.org, ties.st...@arm.com Blocks: 40331 This is a fix for the AArch64/Windows target, it's been in trunk for a month now without any known issues afaik. I just recently ran into the issue that this commit fixed, when testing with an older snapshot, and found that the issue was fixed in latest master. I know it's very late in the 8.0 cycle though, so if deemed not critical enough, perhaps it's relevant for 8.0.1 at least? Referenced Bugs: https://bugs.llvm.org/show_bug.cgi?id=40331 [Bug 40331] [meta] 8.0.0 Release Blockers -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 40908] New: Segfault in StmtPrinter::VisitIntegerLiteral for __int128 values
https://bugs.llvm.org/show_bug.cgi?id=40908
Bug ID: 40908
Summary: Segfault in StmtPrinter::VisitIntegerLiteral for
__int128 values
Product: clang
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: arthur.j.odw...@gmail.com
CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org,
neeil...@live.com, richard-l...@metafoo.co.uk
// https://godbolt.org/z/qFl8Dd
template<__int128 C>
void f() {
static_assert(C == 42);
}
void g() {
f<1>();
}
Partial stack trace:
#3 0x7f2b12b96890 __restore_rt
(/lib/x86_64-linux-gnu/libpthread.so.0+0x12890)
#4 0x55fbc7832253 llvm::raw_ostream::write(unsigned char)
(/opt/compiler-explorer/clang-trunk-20190228/bin/clang-9+0x252b253)
#5 0x55fbc960b3ba (anonymous
namespace)::StmtPrinter::VisitIntegerLiteral(clang::IntegerLiteral*)
(/opt/compiler-explorer/clang-trunk-20190228/bin/clang-9+0x43043ba)
#6 0x55fbc960c68d (anonymous namespace)::StmtPrinter::Visit(clang::Stmt*)
(/opt/compiler-explorer/clang-trunk-20190228/bin/clang-9+0x430568d)
#7 0x55fbc960cdaa (anonymous namespace)::StmtPrinter::Visit(clang::Stmt*)
(/opt/compiler-explorer/clang-trunk-20190228/bin/clang-9+0x4305daa)
#8 0x55fbc9612708 (anonymous
namespace)::StmtPrinter::VisitBinaryOperator(clang::BinaryOperator*)
(/opt/compiler-explorer/clang-trunk-20190228/bin/clang-9+0x430b708)
#9 0x55fbc960bce3 (anonymous namespace)::StmtPrinter::Visit(clang::Stmt*)
(/opt/compiler-explorer/clang-trunk-20190228/bin/clang-9+0x4304ce3)
#10 0x55fbc960df82 clang::Stmt::printPretty(llvm::raw_ostream&,
clang::PrinterHelper*, clang::PrintingPolicy const&, unsigned int,
llvm::StringRef, clang::ASTContext const*) const
(/opt/compiler-explorer/clang-trunk-20190228/bin/clang-9+0x4306f82)
#11 0x55fbc91b32f7
clang::Sema::findFailedBooleanCondition[abi:cxx11](clang::Expr*)
(/opt/compiler-explorer/clang-trunk-20190228/bin/clang-9+0x3eac2f7)
#12 0x55fbc8ed05c2
clang::Sema::BuildStaticAssertDeclaration(clang::SourceLocation, clang::Expr*,
clang::StringLiteral*, clang::SourceLocation, 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
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 40907] New: Cherry-pick r355136 to 8.0 branch
https://bugs.llvm.org/show_bug.cgi?id=40907 Bug ID: 40907 Summary: Cherry-pick r355136 to 8.0 branch Product: libraries Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: Backend: AArch64 Assignee: unassignedb...@nondot.org Reporter: efrie...@quicinc.com CC: arnaud.degrandmai...@arm.com, llvm-bugs@lists.llvm.org, peter.sm...@linaro.org, ties.st...@arm.com Blocks: 40331 https://reviews.llvm.org/rL355136 It's not a regression, and I'm not sure if the 8.0 branch is still taking cherry-picks, but it would be nice to have for AArch64 Windows. Should be low risk since it doesn't affect other targets. Referenced Bugs: https://bugs.llvm.org/show_bug.cgi?id=40331 [Bug 40331] [meta] 8.0.0 Release Blockers -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 40184] Assertion failed: Subtarget.isCallingConvWin64(MF.getFunction().getCallingConv()) && "Funclets should only be present on Win64"
https://bugs.llvm.org/show_bug.cgi?id=40184 Eli Friedman changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #16 from Eli Friedman --- Merged to trunk. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 40855] ExceptionDataRecord::EpilogueCount returns wrong amount in some cases on aarch64
https://bugs.llvm.org/show_bug.cgi?id=40855 Eli Friedman changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #9 from Eli Friedman --- llvm-readobj is fixed. Bug 40876 tracks the related compiler bug. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 40906] New: clang-format vertical alignment of 2d array declarations, arrays of structs, and excessively long arrays.
https://bugs.llvm.org/show_bug.cgi?id=40906 Bug ID: 40906 Summary: clang-format vertical alignment of 2d array declarations, arrays of structs, and excessively long arrays. Product: clang Version: unspecified Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: Formatter Assignee: unassignedclangb...@nondot.org Reporter: micas...@cisco.com CC: djas...@google.com, kli...@google.com, llvm-bugs@lists.llvm.org Two-dimensional arrays, arrays of structs, and excessively long single-dimension arrays that are formatted by clang-format end up being extraordinarily lengthy as each element in each struct will be assigned a separate line instead of being organized as a matrix. Ideally, clang-format would format the 2nd dimension, or the entire struct (in an array of structs), on one line, with each member variable aligned vertically so as to appear as a table or matrix. The following examples showing the need for this feature/improvement are from the ClamAV project. I will note that for the time being we also disable clang-format to align consecutive macros, which is a feature already in [review](https://reviews.llvm.org/D28462) that I am looking forward to using. Array of Structs Declarations: * libclamav/filestypes.c: * https://github.com/Cisco-Talos/clamav-devel/blob/dev/0.102/libclamav/filetypes.c#L57 * https://github.com/Cisco-Talos/clamav-devel/blob/dev/0.102/libclamav/filetypes.c#L226 * https://github.com/Cisco-Talos/clamav-devel/blob/dev/0.102/libclamav/matcher.h#L183 * Note, this one contains edge case where the 2nd dimension contains an additional struct as a member variable. * https://github.com/Cisco-Talos/clamav-devel/blob/dev/0.102/libclamav/msxml.c#L52 * https://github.com/Cisco-Talos/clamav-devel/blob/dev/0.102/libclamav/swf.h#L131 2D Array Declarations: * https://github.com/Cisco-Talos/clamav-devel/blob/dev/0.102/libclamav/htmlnorm.c#L129 * https://github.com/Cisco-Talos/clamav-devel/blob/dev/0.102/libclamav/pe_icons.c#L254 * libclamav/disasm.c contains many examples, although the variables in these examples are unfortunately not aligned: * https://github.com/Cisco-Talos/clamav-devel/blob/dev/0.102/libclamav/disasm.c#L83 * https://github.com/Cisco-Talos/clamav-devel/blob/dev/0.102/libclamav/disasm.c#L94 * https://github.com/Cisco-Talos/clamav-devel/blob/dev/0.102/libclamav/disasm.c#L105 * https://github.com/Cisco-Talos/clamav-devel/blob/dev/0.102/libclamav/disasm.c#L114 * etc... A related issue with single-dimension arrays where existing line-breaks need to be respected is probably not addressable. * https://github.com/Cisco-Talos/clamav-devel/blob/dev/0.102/libclamav/sf_base64decode.c#L31 * https://github.com/Cisco-Talos/clamav-devel/blob/dev/0.102/libclamav/binhex.c#L36 * https://github.com/Cisco-Talos/clamav-devel/blob/dev/0.102/libclamav/htmlnorm.c#L103 * https://github.com/Cisco-Talos/clamav-devel/blob/dev/0.102/libclamav/matcher-ac.c#L71 * https://github.com/Cisco-Talos/clamav-devel/blob/dev/0.102/libclamav/textdet.c#L58 Additional detail about how the ClamAV project is using clang-format are listed in this blog post: https://blog.clamav.net/2019/02/clamav-adopts-clang-format.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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 40905] New: [x86] load/splat scalar constants for use with scalar FP logic ops?
https://bugs.llvm.org/show_bug.cgi?id=40905
Bug ID: 40905
Summary: [x86] load/splat scalar constants for use with scalar
FP logic ops?
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
Seen in:
https://reviews.llvm.org/D58282
declare <4 x double> @llvm.copysign.v4f64(<4 x double>, <4 x double>)
define double @copysign_v4f64(<4 x double> %x, <4 x double> %y) nounwind {
%v = call <4 x double> @llvm.copysign.v4f64(<4 x double> %x, <4 x double> %y)
%r = extractelement <4 x double> %v, i32 0
ret double %r
}
We convert this to a scalar op, but the x86 FP logic ops only allow load
folding with vector constants so:
$ ./llc -o - -mattr=avx copysign.ll
LCPI0_0:
.quad -9223372036854775808## double -0
.quad -9223372036854775808## double -0
LCPI0_1:
.quad 9223372036854775807 ## double NaN
.quad 9223372036854775807 ## double NaN
.section__TEXT,__text,regular,pure_instructions
.globl _copysign_v4f64
.p2align4, 0x90
_copysign_v4f64:
vandps LCPI0_0(%rip), %xmm1, %xmm1
vandps LCPI0_1(%rip), %xmm0, %xmm0
vorps %xmm1, %xmm0, %xmm0
vzeroupper
retq
--
Should we broadcast scalar constants instead? The answer may depend on whether
we are optimizing for size and/or subtarget.
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 40239] Incompatible C++ headers when compiling with -fopenmp-targets=nvptx64-nvidia-cuda
https://bugs.llvm.org/show_bug.cgi?id=40239 Alexey Bataev changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 39999] Print symbol section in the "Section" column for llvm-nm sysv output format
https://bugs.llvm.org/show_bug.cgi?id=3 Sunil Srivastava changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #3 from Sunil Srivastava --- The commit to fix this was reverted due to an ASAN failure. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 39998] Print symbol type in the "Type" column for llvm-nm sysv output format
https://bugs.llvm.org/show_bug.cgi?id=39998 Sunil Srivastava changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #4 from Sunil Srivastava --- The commit to fix this was reverted due to an ASAN failure. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 40904] New: regex_search on MacOS gives wrong results when \D found in a character class
https://bugs.llvm.org/show_bug.cgi?id=40904
Bug ID: 40904
Summary: regex_search on MacOS gives wrong results when \D
found in a character class
Product: libc++
Version: unspecified
Hardware: Macintosh
OS: All
Status: NEW
Severity: normal
Priority: P
Component: All Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: t...@kera.name
CC: llvm-bugs@lists.llvm.org, mclow.li...@gmail.com
Pre-C++20, there's no way to turn on /s, so instead of a pattern like /ab.cd/
(where the third character could be a newline) we must write something like
/ab[/d/D]cd/ (using the union of "digits" and "non-digits" to match "any
character").
Unfortunately, libc++ doesn't match properly on this.
Example:
#include
#include
#include
#include
int main()
{
const std::string input = "abZcd";
char const* pattern = R"REGEX(^ab[\d\D]cd)REGEX";
std::regex::flag_type flags = std::regex_constants::ECMAScript;
std::regex re(pattern, flags);
std::cout << std::boolalpha << std::regex_search(input.cbegin(),
input.cend(), re) << '\n';
}
Output is "false" with:
$ clang --version
Apple LLVM version 10.0.0 (clang-1000.10.44.4)
Target: x86_64-apple-darwin18.2.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin
But "true" (as expected) with g++ (GCC) 8.2.0.
Looking into it a bit, here are the results with some variants:
PatternInputShould match?Matches?
-
/^ab[\d\D]cd/ abZcdYes No <--- !
/^ab[\d\D]cd/ ab5cdYes No <--- !
/^ab[\D]cd/abZcdYes No <--- !
/^ab\Dcd/ abZcdYes Yes
/^ab[\d]cd/ab5cdYes Yes
/^ab\dcd/ ab5cdYes Yes
/^ab\dcd/ abZcdNo No
/^ab\Dcd/ ab5cdNo No
The common feature amongst the three failures is the \D inside a character
class.
The behaviour is the same when switching to std::regex_match.
For added fun, I get the expected results on Linux:
$ clang++ --version
clang version 5.0.0-3~16.04.1 (tags/RELEASE_500/final)
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
Related to bug 21363 (locale fun)?
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 11592 in oss-fuzz: llvm/llvm-isel-fuzzer--aarch64-gisel: Timeout in llvm_llvm-isel-fuzzer--aarch64-gisel
Updates: Labels: -Reproducible Unreproducible Comment #7 on issue 11592 by ClusterFuzz-External: llvm/llvm-isel-fuzzer--aarch64-gisel: Timeout in llvm_llvm-isel-fuzzer--aarch64-gisel https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=11592#c7 ClusterFuzz testcase 5640844342722560 appears to be flaky, updating reproducibility label. -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 40903] New: [AMDGPU][MC][GFX7][GFX8] src0 of v_movrelsd_b32 should accept vgprs only
https://bugs.llvm.org/show_bug.cgi?id=40903 Bug ID: 40903 Summary: [AMDGPU][MC][GFX7][GFX8] src0 of v_movrelsd_b32 should accept vgprs only Product: libraries Version: trunk Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: Backend: AMDGPU Assignee: unassignedb...@nondot.org Reporter: dpreobrazhen...@luxoft.com CC: llvm-bugs@lists.llvm.org In contrast with other 'movrels' opcodes, v_movrelsd_b32 accepts an sgpr/constant as src0. This is incorrect. These operands are not supported by SP3 for v_movrelsd_b32. Compare: v_movrels_b32 v0, v0 // ok v_movrels_b32 v0, s0 // error v_movrels_b32 v0, 0 // error v_movrelsd_b32 v0, v0 // ok v_movrelsd_b32 v0, s0 // ok (but should trigger an error) v_movrelsd_b32 v0, 0 // ok (but should trigger an error) -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 40902] New: Can't compile with GCC 9 headers
https://bugs.llvm.org/show_bug.cgi?id=40902 Bug ID: 40902 Summary: Can't compile with GCC 9 headers Product: clang Version: 8.0 Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: Frontend Assignee: unassignedclangb...@nondot.org Reporter: steinar+l...@gunderson.no CC: llvm-bugs@lists.llvm.org, neeil...@live.com, richard-l...@metafoo.co.uk Hi, Any include of with Clang 8.0.0-+rc2-1~exp1 and headers from GCC 9.0.1 20190223 gives: In file included from test.cc:1: In file included from /usr/lib/gcc/x86_64-linux-gnu/9/../../../../include/c++/9/map:60: In file included from /usr/lib/gcc/x86_64-linux-gnu/9/../../../../include/c++/9/bits/stl_tree.h:67: In file included from /usr/lib/gcc/x86_64-linux-gnu/9/../../../../include/c++/9/ext/alloc_traits.h:36: /usr/lib/gcc/x86_64-linux-gnu/9/../../../../include/c++/9/bits/alloc_traits.h:604:44: error: 'copy' is a protected member of 'std::__is_alloc_insertable_impl' : __is_alloc_insertable_impl::template copy<_Alloc> ^ /usr/lib/gcc/x86_64-linux-gnu/9/../../../../include/c++/9/bits/alloc_traits.h:595:7: note: declared protected here using copy = decltype(_M_select<_Alloc, const _Tp&>(0)); ^ /usr/lib/gcc/x86_64-linux-gnu/9/../../../../include/c++/9/bits/alloc_traits.h:616:44: error: 'move' is a protected member of 'std::__is_alloc_insertable_impl' : __is_alloc_insertable_impl::template move<_Alloc> ^ /usr/lib/gcc/x86_64-linux-gnu/9/../../../../include/c++/9/bits/alloc_traits.h:598:7: note: declared protected here using move = decltype(_M_select<_Alloc, _Tp>(0)); ^ 2 errors generated. GCC 9 compiles the same headers just fine. I'm not sure if this should be fixed in GCC or in Clang, though. clang version 8.0.0-+rc2-1~exp1 (tags/RELEASE_800/rc2) Target: x86_64-pc-linux-gnu Thread model: posix InstalledDir: /usr/bin Found candidate GCC installation: /usr/bin/../lib/gcc/i686-linux-gnu/8 Found candidate GCC installation: /usr/bin/../lib/gcc/i686-linux-gnu/9 Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/4.8 Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/4.8.4 Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/4.9 Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/4.9.2 Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/5 Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/5.5.0 Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/6 Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/6.5.0 Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/7 Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/7.4.0 Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/8 Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/9 Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/8 Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/9 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8.4 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9.2 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5.5.0 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6.5.0 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7.4.0 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/8 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/9 Selected GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/9 Candidate multilib: .;@m64 Selected multilib: .;@m64 -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 40861] llvm-readobj reads past end of dynamic segment if it does not end in DT_NULL
https://bugs.llvm.org/show_bug.cgi?id=40861 George Rimar changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from George Rimar --- r355073 -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
