[llvm-bugs] [Bug 40075] llvm-symbolizer: Add --no-demangle as alias for --demangle=0
https://bugs.llvm.org/show_bug.cgi?id=40075 Dmitry Venikov changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #2 from Dmitry Venikov --- rL351735 -- 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 40390] New: regex_match doesn't fail early when given a non-matching pattern with a start-of-input anchor
https://bugs.llvm.org/show_bug.cgi?id=40390
Bug ID: 40390
Summary: regex_match doesn't fail early when given a
non-matching pattern with a start-of-input anchor
Product: libc++
Version: unspecified
Hardware: PC
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
I first raised this on SO (https://stackoverflow.com/q/54237547/560648), on
which I have posted some benchmarks to back up the claim(s) below.
Take the following:
#include
int main()
{
static const size_t BufSize = 100;
char buf[BufSize] = {};
auto begin = std::cbegin(buf), end = std::cend(buf);
std::cmatch groups;
std::regex::flag_type flags = std::regex_constants::ECMAScript;
std::regex re("^what", flags);
std::regex_search(begin, end, groups, re);
}
This attempts to match the pattern "^what" against a block of 100 characters.
The match is not expected to succeed (in this case, the input is simply 100
'\0's, but the problem exists for any non-matching input).
However, I expect the match to fail as soon as the first character of input is
examined. By adjusting BufSize to increasingly large values, we observe that
the execution time increases also, suggesting that the regex engine is
examining the entire input even though the presence of the anchor "^"
guarantees that a match will never be found. It only needed to examine the
first character to know this. When BufSize reaches larger values like 100KB,
this becomes quite problematic.
It is clear from the implementation code
(https://github.com/llvm-mirror/libcxx/blob/master/include/regex#L5859-L5897)
that there is simply no logic in place to "fail fast" or "fail early" in a case
like this: the only way a "no match" result is returned is after examining the
whole input, regardless of the pattern.
It is my opinion that this is a quality of implementation issue, and one that
only appears in C++ implementations of regular expressions. This problem is
common to libstdc++, libc++ and also Visual Studio's stdlib impl. (I am raising
bugs against all three.)
As a workaround I'm having to artificially select a prefix of the input data in
order to get a fast result -- in the example above, that could be:
auto begin = std::cbegin(buf), end = std::cbegin(buf)+4;
However, not all examples are so trivial (indeed, the example above would be
much better approached with a simple string prefix comparison) and the
workaround not always so easy. When the pattern is more complex, it is not
always easy to find the best number of characters to send to the regex engine,
and the resulting code not particularly elegant. It would be much better if the
engine could be given the whole input without having to worry about scale.
Hopefully my expectation isn't unreasonable; Safari's implementation of regex
behaves as I'd expect. That is, the time to return a "no match" result is
constant (and fast) given the JS equivalent of the above example.
Is it possible that the regex_match implementation could be given a little more
intelligence?
(Apologies that I am not sufficiently familiar with libc++ version history to
select an appropriate version number for this 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
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 40391] New: [X86] Use ValueTracking to convert x86-specific vector shifts to generics
https://bugs.llvm.org/show_bug.cgi?id=40391 Bug ID: 40391 Summary: [X86] Use ValueTracking to convert x86-specific vector shifts to generics 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 Depends on: 36319 InstCombine already converts x86 vectors shifts to generic shifts for constant shift amount cases (simplifyX86varShift + simplifyX86immShift). For non-constant cases, ValueTracking (MaskedValueIsZero etc.) should be able to determine when the upper bits of the shift amounts are known to be zero and convert to generic shifts: https://godbolt.org/z/7uik05 Similarly, if we know that any of the upper bits are NOT zero then we should be able to convert either to zero or ashr(V, numbits-1) to match the x86 shift behaviour. The avx2+ per-element shifts case should be pretty straightforward, but it requires all elements to match. The older sse2+ uniform-element shift case is trickier as we need to correctly value track the bottom 64-bits of the shift amount (spread across multiple elements), [Bug #36319] would help us with this. Referenced Bugs: https://bugs.llvm.org/show_bug.cgi?id=36319 [Bug 36319] [ValueTracking] Add DemandedElts support to computeKnownBits/ComputeNumSignBits -- 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 40393] New: Clang crashes while building Linux kernel due to [llvm] r351626 - Reapply "[CGP] Check for existing inttotpr before creating new one"
https://bugs.llvm.org/show_bug.cgi?id=40393 Bug ID: 40393 Summary: Clang crashes while building Linux kernel due to [llvm] r351626 - Reapply "[CGP] Check for existing inttotpr before creating new one" Product: clang Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: LLVM Codegen Assignee: unassignedclangb...@nondot.org Reporter: maxim.kuvyr...@gmail.com CC: llvm-bugs@lists.llvm.org, neeil...@live.com, richard-l...@metafoo.co.uk Hi, Linaro's TCWG LLVM+Kernel tracking bisected kernel build regression down to this commit. Successfully identified regression in CI configuration llvm-master-aarch64-lts-defconfig for llvm between bad_rev be88539b85204041f727ec6499315884b3d886b0 and baseline_rev 4a22fb18c7935c6c1bae1af0b2e4a4c9e256ee04 . Culprit: commit 85a0467a11bc748a242a858dfb950fce2956fa79 Author: Roman Tereshin Date: Fri Jan 18 20:13:42 2019 + [CGP] Check for existing inttotpr before creating new one Make sure CodeGenPrepare doesn't emit multiple inttoptr instructions of the same integer value while sinking address computations, but rather CSEs them on the fly: excessive inttoptr's confuse SCEV into thinking that related pointers have nothing to do with each other. This problem blocks LoadStoreVectorizer from vectorizing some of the loads / stores in a downstream target. Reviewed By: hfinkel Differential Revision: https://reviews.llvm.org/D56838 llvm-svn: 351582 Results regressed from (for last_good == d4023bd2cb2606db1a734966b14f865a52c68285) reset_artifacts: -10 build_llvm: -1 linux_n_obj: all to (for first_bad == 85a0467a11bc748a242a858dfb950fce2956fa79) reset_artifacts: -10 build_llvm: -1 linux_n_obj: 5131 Artifacts of last_good build: https://ci.linaro.org/job/tcwg_kernel-bisect-llvm-master-aarch64-lts-defconfig/4/artifact/artifacts/build-d4023bd2cb2606db1a734966b14f865a52c68285/ Artifacts of first_bad build: https://ci.linaro.org/job/tcwg_kernel-bisect-llvm-master-aarch64-lts-defconfig/4/artifact/artifacts/build-85a0467a11bc748a242a858dfb950fce2956fa79/ Reproduce builds: mkdir investigate-llvm-85a0467a11bc748a242a858dfb950fce2956fa79 cd investigate-llvm-85a0467a11bc748a242a858dfb950fce2956fa79 git clone https://git.linaro.org/toolchain/jenkins-scripts wget https://ci.linaro.org/job/tcwg_kernel-bisect-llvm-master-aarch64-lts-defconfig/4/artifact/artifacts/manifests/build-baseline.sh ./jenkins-scripts/tcwg_kernel-build.sh @@ build-baseline.sh wget https://ci.linaro.org/job/tcwg_kernel-bisect-llvm-master-aarch64-lts-defconfig/4/artifact/artifacts/test.sh chmod +x test.sh cd llvm # Reproduce first_bad build git checkout --detach 85a0467a11bc748a242a858dfb950fce2956fa79 ../test.sh # Reproduce last_good build git checkout --detach d4023bd2cb2606db1a734966b14f865a52c68285 ../test.sh cd .. History of pending regressions and results: https://git.linaro.org/toolchain/ci/base-artifacts.git/log/?h=linaro-local/ci/tcwg_kernel/llvm-master-aarch64-lts-defconfig Bisect log: https://ci.linaro.org/job/tcwg_kernel-bisect-llvm-master-aarch64-lts-defconfig/4/artifact/artifacts/bisect.log/*view*/ Artifacts: https://ci.linaro.org/job/tcwg_kernel-bisect-llvm-master-aarch64-lts-defconfig/4/artifact/artifacts/ Build URL: https://ci.linaro.org/job/tcwg_kernel-bisect-llvm-master-aarch64-lts-defconfig/4/ Build log: https://ci.linaro.org/job/tcwg_kernel-bisect-llvm-master-aarch64-lts-defconfig/4/consoleText -- 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 11199 in oss-fuzz: llvm/clang-fuzzer: Stack-overflow in llvm::detail::IEEEFloat::convertFromStringSpecials
Updates: Labels: Deadline-Approaching Comment #1 on issue 11199 by sheriff...@chromium.org: llvm/clang-fuzzer: Stack-overflow in llvm::detail::IEEEFloat::convertFromStringSpecials https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=11199#c1 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 40394] New: [DAGCombiner] crash when forming shuffle from build vector
https://bugs.llvm.org/show_bug.cgi?id=40394
Bug ID: 40394
Summary: [DAGCombiner] crash when forming shuffle from build
vector
Product: libraries
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: Common Code Generator Code
Assignee: unassignedb...@nondot.org
Reporter: spatel+l...@rotateright.com
CC: llvm-bugs@lists.llvm.org
This will crash using llc built from trunk r351752:
target triple = "aarch64-unknown-linux-gnu"
define <4 x i32> @truncating_build_vector_crash(<4 x i16> %t0) {
%t1 = extractelement <4 x i16> %t0, i32 2
%vgetq_lane = zext i16 %t1 to i32
%t2 = insertelement <4 x i32> undef, i32 %vgetq_lane, i64 0
ret <4 x i32> %t2
}
--
The bug was introduced with:
https://reviews.llvm.org/D56281 / https://reviews.llvm.org/rL351198
I committed a fix that limits the transform to avoid the crash here:
https://reviews.llvm.org/rL351753
I think we should pull that commit into the 8.0 release to avoid the crash.
--
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 15388] 32bit Linux, the assignment operator of vector value cause FPU stack over-flow.
https://bugs.llvm.org/show_bug.cgi?id=15388 Eli Friedman changed: What|Removed |Added Resolution|--- |WORKSFORME Status|NEW |RESOLVED --- Comment #3 from Eli Friedman --- The given C code has worked correctly for a long time. (Once upon a time, we would generate MMX code for code using types like `typedef char char8 __attribute__((ext_vector_type(8)));`, but that was fixed around in clang 3.3.) -- 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 40313] With __PRETTY_FUNCTION__, dereferencing same pointer produces different results at compile time vs. runtime
https://bugs.llvm.org/show_bug.cgi?id=40313 Eli Friedman changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Eli Friedman --- https://reviews.llvm.org/rL351766 -- 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 40395] New: __uuidof at a template argument causes infinite template instantiation
https://bugs.llvm.org/show_bug.cgi?id=40395
Bug ID: 40395
Summary: __uuidof at a template argument causes infinite
template instantiation
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: C++'17
Assignee: unassignedclangb...@nondot.org
Reporter: mail+l...@tzik.jp
CC: blitzrak...@gmail.com, erik.pilking...@gmail.com,
llvm-bugs@lists.llvm.org, richard-l...@metafoo.co.uk
Extra SubstNonTypeTemplateParmExpr around __uuidof causes infinite template
instantiation.
Here is a repro below. The output contains multiple instantiation of
A<&__uuidof(B)> with different AST around __uuidof.
The AST of |piid| on the second instantiation is:
| | |-TemplateArgument expr
| | | `-ConstantExpr 0x1f94990 'const _GUID *'
| | | `-SubstNonTypeTemplateParmExpr 0x1f94970 'const _GUID *'
| | | `-ConstantExpr 0x1f630c8 'const _GUID *'
| | | `-UnaryOperator 0x1f630b0 'const _GUID *' prefix
'&' cannot overflow
| | | `-CXXUuidofExpr 0x1f63080 'const _GUID' lvalue
And it on the third instantiation is:
| | |-TemplateArgument expr
| | | `-ConstantExpr 0x1f97678 'const _GUID *'
| | | `-SubstNonTypeTemplateParmExpr 0x1f97658 'const _GUID *'
| | | `-ConstantExpr 0x1f94990 'const _GUID *'
| | | `-SubstNonTypeTemplateParmExpr 0x1f94970 'const _GUID *'
| | | `-ConstantExpr 0x1f630c8 'const _GUID *'
| | | `-UnaryOperator 0x1f630b0 'const _GUID *'
prefix '&' cannot overflow
| | | `-CXXUuidofExpr 0x1f63080 'const _GUID'
lvalue
That is, the value of __uuidof is wrapped by SubstNonTypeTemplateParmExpr
multiple times, and A<&__uuidof(B)> is instantiated for each variant of wrap
level.
$ clang++ -ftemplate-depth=3 -Xclang -ast-dump -fms-extensions -fsyntax-only
-std=c++17 foo.cc
foo.cc
struct _GUID {};
struct __declspec(uuid("{----}")) B {};
template
struct A {
virtual void baz() { A(); }
};
void f() {
A<&__uuidof(B)>();
}
--
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 40396] New: DEFINED(foo) always evaluates to true if foo is also defined in the script
https://bugs.llvm.org/show_bug.cgi?id=40396
Bug ID: 40396
Summary: DEFINED(foo) always evaluates to true if foo is also
defined in the script
Product: lld
Version: unspecified
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P
Component: ELF
Assignee: unassignedb...@nondot.org
Reporter: pkmx...@gmail.com
CC: llvm-bugs@lists.llvm.org, peter.sm...@linaro.org
$ cat test.ld
SECTIONS {
foo = DEFINED(foo) ? foo : 0x1000;
ASSERT ( foo == 0x1000 , "should not happen" )
}
$ echo | clang -xc - -c -o empty.o
$ ld.lld empty.o -Ttest.ld
ld.lld: error: should not happen
This is a documented usage in bfd's ld manual
(https://sourceware.org/binutils/docs/ld/Builtin-Functions.html#Builtin-Functions),
where foo should retain its value if it is already set prior to the statement
(via --defsym or other methods), or otherwise set to a default value 0x1000.
However, lld always evaluates it to 0.
The root cause seems to be rL323729 that adds all symbol assignments to the
symbol table as a dummy `Defined` absolute symbol of value 0, which causes the
DEFINED() builtin to always evaluate to true.
--
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 40397] New: OpenMP: default(none) implementation is standard-incompliant.
https://bugs.llvm.org/show_bug.cgi?id=40397
Bug ID: 40397
Summary: OpenMP: default(none) implementation is
standard-incompliant.
Product: OpenMP
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Clang Compiler Support
Assignee: unassignedclangb...@nondot.org
Reporter: lebedev...@gmail.com
CC: llvm-bugs@lists.llvm.org
Initially was https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88967
https://godbolt.org/z/8WHddH
void foo(int *x);
void test1(int * const begin, const int len) {
#pragma omp parallel default(none)
#pragma omp for
for(int x = 0; x < len; x++)
foo(begin + x);
}
gcc 8.2, clang trunk is ok with that code.
gcc trunk says:
: In function 'void test1(int*, int)':
:5:9: error: 'len' not specified in enclosing 'parallel'
5 | #pragma omp for
| ^~~
:4:9: error: enclosing 'parallel'
4 | #pragma omp parallel default(none)
| ^~~
:7:9: error: 'begin' not specified in enclosing 'parallel'
7 | foo(begin + x);
| ^
:4:9: error: enclosing 'parallel'
4 | #pragma omp parallel default(none)
| ^~~
Compiler returned: 1
Since 'default(none)' is specified, i fail to see how they are not specified..
I'm also not really seeing the reasoning in the openmp 4.0 "2.14.3.1 default
clause".
Did this change in newer openmp versions?
Reply from Jakub Jelinek:
It indeed changed, already in OpenMP 4.0 actually, but I've been long hoping
that the change will be reverted in later OpenMP standards, in the end that is
not what is going to happen.
OpenMP 3.1 and earlier had:
"Variables with const-qualified type having no mutable member are shared."
among the predetermined data sharing of variables for C/C++, and
"Variables with const-qualified type having no mutable member may be listed in
a
C/C++ firstprivate clause."
as an exception to the rule that variables with predetermined data sharing may
not be specified in OpenMP data sharing clauses.
That is gone in OpenMP 4.0, these variables are not predetermined anymore, so
with default(none) they must be specified in data sharing clauses if they are
referenced in the region. They can be specified in both shared and
firstprivate clauses now, e.g. lastprivate/reduction/linear aren't suitable
because they all need to write into the variable. If you want to write code
that will work with both OpenMP 3.1 and OpenMP 4.0+ (including 5.0, which
hasn't changed in this area), you need to use firstprivate(begin, len) in your
example, that used to be valid in OpenMP 3.1 due to the above exception and
keeps to be valid now.
I've asked the ifort/clang maintainers about why they keep violating the
standard, but haven't heard back from them. And I must say I was trying hard
to readd the above rule + exception, but haven't succeeded.
The exact wording why the above needs to be refused is:
"The default(none) clause requires that each variable that is referenced in the
construct, and that does not have a predetermined data-sharing attribute, must
have its data-sharing attribute explicitly determined by being listed in a
data-sharing attribute clause."
As it is not predetermined (anymore) and is not explicitly determined either,
it violates the requirement above.
--
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
