[llvm-bugs] Issue 4711 in oss-fuzz: llvm/llvm-isel-fuzzer--aarch64-O2: ASSERT: getMinSignedBits() <= 64 && "Too many bits for int64_t"
Comment #4 on issue 4711 by ClusterFuzz-External: llvm/llvm-isel-fuzzer--aarch64-O2: ASSERT: getMinSignedBits() <= 64 && "Too many bits for int64_t" https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=4711#c4 ClusterFuzz has detected this issue as fixed in range 201801140616:201801150720. Detailed report: https://oss-fuzz.com/testcase?key=6669237549531136 Project: llvm Fuzzer: libFuzzer_llvm_llvm-isel-fuzzer--aarch64-O2 Fuzz target binary: llvm-isel-fuzzer--aarch64-O2 Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: ASSERT Crash Address: Crash State: getMinSignedBits() <= 64 && "Too many bits for int64_t" llvm::APInt::getSExtValue llvm::BasicAAResult::DecomposeGEPExpression Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201712190608:201712210617 Fixed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201801140616:201801150720 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=6669237549531136 See https://github.com/google/oss-fuzz/blob/master/docs/reproducing.md for more information. If you suspect that the result above is incorrect, try re-doing that job on the test case report page. -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 4711 in oss-fuzz: llvm/llvm-isel-fuzzer--aarch64-O2: ASSERT: getMinSignedBits() <= 64 && "Too many bits for int64_t"
Updates: Labels: ClusterFuzz-Verified Status: Verified Comment #5 on issue 4711 by ClusterFuzz-External: llvm/llvm-isel-fuzzer--aarch64-O2: ASSERT: getMinSignedBits() <= 64 && "Too many bits for int64_t" https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=4711#c5 ClusterFuzz testcase 6669237549531136 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 35945] New: Error while building with GCC 4.9 on Raspbian (Raspberry Pi)
https://bugs.llvm.org/show_bug.cgi?id=35945
Bug ID: 35945
Summary: Error while building with GCC 4.9 on Raspbian
(Raspberry Pi)
Product: libc++abi
Version: 6.0
Hardware: PC
OS: Linux
Status: NEW
Severity: release blocker
Priority: P
Component: All Bugs
Assignee: unassignedb...@nondot.org
Reporter: benni.b...@gmail.com
CC: llvm-bugs@lists.llvm.org, mclow.li...@gmail.com
Build with:
$ g++ --version
g++ (Raspbian 4.9.2-10) 4.9.2
Copyright (C) 2014 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Error message:
[ 46%] Building CXX object
projects/libcxxabi/src/CMakeFiles/cxxabi_objects.dir/cxa_default_handlers.cpp.o
/home/pi/projects/llvm/llvm/projects/libcxxabi/src/cxa_default_handlers.cpp: In
function ‘void demangling_terminate_handler()’:
/home/pi/projects/llvm/llvm/projects/libcxxabi/src/cxa_default_handlers.cpp:39:56:
error: invalid operands of types ‘char [8]’ and ‘const uint64_t {aka const long
long unsigned int}’ to binary ‘operator&’
(unwind_exception->exception_class &
get_vendor_and_language) ==
^
/home/pi/projects/llvm/llvm/projects/libcxxabi/src/cxa_default_handlers.cpp:44:58:
error: ISO C++ forbids comparison between pointer and integer [-fpermissive]
unwind_exception->exception_class ==
kOurDependentExceptionClass ?
^
Build from same repository on x86_64 was successful:
$ clang++ --version
clang version 7.0.0 (http://llvm.org/git/clang.git
de6dd39fdb9873632f1b157ce0eb20867d9e31e4) (http://llvm.org/git/llvm.git
bbe71a0c6f29caf58e145cba814a6357a595a480)
Target: x86_64-unknown-linux-gnu
Thread model: posix
Successful build on x86_64 with:
$ g++-6 --version
g++-6 (Ubuntu/Linaro 6.3.0-18ubuntu2~16.04) 6.3.0 20170519
Copyright (C) 2016 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
--
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 35946] New: error with let l:lines = "all" in clang-format.py
https://bugs.llvm.org/show_bug.cgi?id=35946
Bug ID: 35946
Summary: error with let l:lines = "all" in clang-format.py
Product: clang
Version: 5.0
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Formatter
Assignee: unassignedclangb...@nondot.org
Reporter: george.dim...@gmail.com
CC: djas...@google.com, kli...@google.com,
llvm-bugs@lists.llvm.org
clang version 5.0.1
Arch linux
Snippet of init.vim file:
function FormatCPPFile()
let l:lines = "all"
pyf /usr/share/clang/clang-format.py
endfunction
autocmd FileType cpp map :call FormatCPPFile()
Here's what I get in nvim (NVIM v0.2.2) when C-I was pressed:
error: invalid : pair
No output from clang-format (crashed?).
Please report to bugs.llvm.org.
Looks like the problem is here:
nvim -d cfe-5.0.0.src/tools/clang-format/clang-format.py
cfe-5.0.1.src/tools/clang-format/clang-format.py
Here is the difference:
(cfe-5.0.0) line 65: lines = vim.eval('l:lines')
(cfe-5.0.1) line 65: lines = ['-lines', vim.eval('l:lines')]
--
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 35947] New: lib/Transforms/InstCombine/InstructionCombining.cpp broken -- cannot link.
https://bugs.llvm.org/show_bug.cgi?id=35947 Bug ID: 35947 Summary: lib/Transforms/InstCombine/InstructionCombining.cpp broken -- cannot link. Product: libraries Version: 6.0 Hardware: PC OS: Windows NT Status: NEW Severity: release blocker Priority: P Component: Core LLVM classes Assignee: unassignedb...@nondot.org Reporter: ken.dom...@gmail.com CC: llvm-bugs@lists.llvm.org Fix by EugeneZelenko on Oct 24 2017 broke the linking of LLVM-C applications on Windows. LLVMInitializeInstCombine is declared extern "C" in the LLVM-C header Initialization.h, but not declared extern "C" surrounding the definition for the function in lib/Transforms/InstCombine/InstructionCombining.cpp. The inconsistency can cause a link fail. It's in release_60 and master. Could someone please fix this? One solution that works is to re-add the removed #include "llvm-c/Initialization.h" -- 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 35905] [Value Propagation] Test case seems to get into an infinite loop and seg faults.
https://bugs.llvm.org/show_bug.cgi?id=35905 Jonas Paulsson changed: What|Removed |Added Resolution|--- |WORKSFORME Status|NEW |RESOLVED --- Comment #5 from Jonas Paulsson --- > I couldn't repro with opt built from r322377, so it seems likely this is the > same as bug 35807. Thanks for taking a look. -- 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 35948] New: Why FeatureSlowPMULLD is not set for Haswell+?
https://bugs.llvm.org/show_bug.cgi?id=35948 Bug ID: 35948 Summary: Why FeatureSlowPMULLD is not set for Haswell+? Product: libraries Version: 6.0 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P Component: Backend: X86 Assignee: unassignedb...@nondot.org Reporter: nekotek...@gmail.com CC: llvm-bugs@lists.llvm.org Hello, it seems that LLVM sets this flag for Silvermont processors, but not others. On Haswell or Skylake processors (for example), PMULLD has latency 10, when other vector multiplication instructions have latency 5. https://bugs.llvm.org/show_bug.cgi?id=28128 seems related. -- 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 35949] New: [X86] Properly test headers with Wdocumentation
https://bugs.llvm.org/show_bug.cgi?id=35949 Bug ID: 35949 Summary: [X86] Properly test headers with Wdocumentation Product: clang Version: unspecified Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: Headers Assignee: unassignedclangb...@nondot.org Reporter: llvm-...@redking.me.uk CC: craig.top...@gmail.com, douglas_y...@playstation.sony.com, katya_roman...@playstation.sony.com, llvm-bugs@lists.llvm.org, spatel+l...@rotateright.com As mentioned on D41523, we should ensure that all the x86 builtin codegen tests are being properly tested with Wdocumentation to check for any anomalies in the doxygen within x86intrin.h etc. Initial tests suggested that just adding -Wdocumentation to the RUN command doesn't seem to work so further investigation is necessary. -- 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 3740 in oss-fuzz: llvm/clang-fuzzer: ASSERT: cast(SubExpr)->getQualifier() && "fixed to a member ref with no nes
Updates: Labels: Deadline-Approaching Comment #7 on issue 3740 by sheriff...@chromium.org: llvm/clang-fuzzer: ASSERT: cast(SubExpr)->getQualifier() && "fixed to a member ref with no nes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=3740#c7 This bug is approaching its deadline for being fixed, and will be automatically derestricted within 7 days. If a fix is planned within 2 weeks after the deadline has passed, a grace extension can be granted. - Your friendly Sheriffbot -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 3749 in oss-fuzz: llvm/llvm-dwarfdump-fuzzer: Heap-buffer-overflow in llvm::StringMapImpl::LookupBucketFor
Updates: Labels: Deadline-Approaching Comment #7 on issue 3749 by sheriff...@chromium.org: llvm/llvm-dwarfdump-fuzzer: Heap-buffer-overflow in llvm::StringMapImpl::LookupBucketFor https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=3749#c7 This bug is approaching its deadline for being fixed, and will be automatically derestricted within 7 days. If a fix is planned within 2 weeks after the deadline has passed, a grace extension can be granted. - Your friendly Sheriffbot -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 3737 in oss-fuzz: llvm/clang-fuzzer: Abrt in llvm::llvm_unreachable_internal
Updates: Labels: Deadline-Approaching Comment #7 on issue 3737 by sheriff...@chromium.org: llvm/clang-fuzzer: Abrt in llvm::llvm_unreachable_internal https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=3737#c7 This bug is approaching its deadline for being fixed, and will be automatically derestricted within 7 days. If a fix is planned within 2 weeks after the deadline has passed, a grace extension can be granted. - Your friendly Sheriffbot -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 3764 in oss-fuzz: llvm/clang-fuzzer: ASSERT: ClassDecl->hasFlexibleArrayMember() && "Incomplete array type is not valid"
Updates: Labels: Deadline-Approaching Comment #7 on issue 3764 by sheriff...@chromium.org: llvm/clang-fuzzer: ASSERT: ClassDecl->hasFlexibleArrayMember() && "Incomplete array type is not valid" https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=3764#c7 This bug is approaching its deadline for being fixed, and will be automatically derestricted within 7 days. If a fix is planned within 2 weeks after the deadline has passed, a grace extension can be granted. - Your friendly Sheriffbot -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 35950] New: opt is defunct when code built without optimizations
https://bugs.llvm.org/show_bug.cgi?id=35950
Bug ID: 35950
Summary: opt is defunct when code built without optimizations
Product: libraries
Version: 5.0
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Global Analyses
Assignee: unassignedb...@nondot.org
Reporter: jirisl...@gmail.com
CC: llvm-bugs@lists.llvm.org
$ cat a.c
void foo()
{
int a;
for (a = 0; a < 100; a++)
;
}
$ clang -emit-llvm a.c -S -o - -O2
...
; Function Attrs: norecurse nounwind readnone uwtable
define void @foo() local_unnamed_addr #0 {
ret void
}
...
That one behaved correctly ^
Now no optimizations by clang:
$ clang -emit-llvm a.c -S -o a.bc
$ opt a.bc -O2 -o aopt.bc
$ llvm-dis aopt.bc
$ cat aopt.ll
...
; Function Attrs: noinline nounwind optnone uwtable
define void @foo() local_unnamed_addr #0 {
%1 = alloca i32, align 4
store i32 0, i32* %1, align 4
br label %2
; :2: ; preds = %6, %0
%3 = load i32, i32* %1, align 4
%4 = icmp slt i32 %3, 100
br i1 %4, label %5, label %9
; :5: ; preds = %2
br label %6
; :6: ; preds = %5
%7 = load i32, i32* %1, align 4
%8 = add nsw i32 %7, 1
store i32 %8, i32* %1, align 4
br label %2
; :9: ; preds = %2
ret void
}
That is not definitely OK ^^^
As can be seen, no optimization happened via `opt'.
When I remove the optnone attribute from the clang's -O0 build manually, opt
starts optimizing again.
Now if I try clang 4, it works as expected -- the function gets trimmed. The
difference in the assembly is indeed in `optnone':
$ diff -u <(clang-4.0 -emit-llvm a.c -S -o -) <(clang -emit-llvm a.c -S -o
-)|wdiff -d|colordiff
[--- /dev/fd/63-]{+++ /dev/fd/62+} 2018-01-15 15:12:37.253849366 +0100
@@ -3,7 +3,7 @@
target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-unknown-linux-gnu"
; Function Attrs: noinline nounwind {+optnone+} uwtable
define void @foo() #0 {
%1 = alloca i32, align 4
store i32 0, i32* %1, align 4
@@ -27,8 +27,10 @@
ret void
}
attributes #0 = { noinline nounwind {+optnone+} uwtable
"correctly-rounded-divide-sqrt-fp-math"="false" "disable-tail-calls"="false"
"less-precise-fpmad"="false" "no-frame-pointer-elim"="true"
"no-frame-pointer-elim-non-leaf" "no-infs-fp-math"="false"
"no-jump-tables"="false" "no-nans-fp-math"="false"
"no-signed-zeros-fp-math"="false" "no-trapping-math"="false"
"stack-protector-buffer-size"="8" "target-cpu"="x86-64"
"target-features"="+fxsr,+mmx,+sse,+sse2,+x87" "unsafe-fp-math"="false"
"use-soft-float"="false" }
[-!llvm.ident-]
{+!llvm.module.flags+} = !{!0}
{+!llvm.ident = !{!1}+}
!0 = {+!{i32 1, !"wchar_size", i32 4}
!1 =+} !{!"clang version [-4.0.1 (tags/RELEASE_401/final 305264)"}-] {+5.0.1
(tags/RELEASE_501/final 312548)"}+}
--
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 35951] New: clang permits assignment to vector/extvector elements in a const method
https://bugs.llvm.org/show_bug.cgi?id=35951
Bug ID: 35951
Summary: clang permits assignment to vector/extvector elements
in a const method
Product: clang
Version: unspecified
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: C++
Assignee: unassignedclangb...@nondot.org
Reporter: llvm-...@redking.me.uk
CC: dav...@freebsd.org, dgre...@apple.com,
fil...@gmail.com, llvm-bugs@lists.llvm.org,
richard-l...@metafoo.co.uk, rjmcc...@apple.com
The following cases compile successfully on clang but not gcc:
https://godbolt.org/g/jhQeot
#if __CLANG__
typedef float float4 __attribute__((ext_vector_type(4)));
struct OhNo {
float4 v;
void AssignMe() const { v.x = 1; }
};
#endif
typedef float float4_2 __attribute__((__vector_size__(16)));
struct OhNo2 {
float4_2 v;
void AssignMe() const { v[0] = 1; }
};
I'd expect clang to report an error that we are trying to assign a value to a
read-only variable, similar to:
struct OhNo3 {
float v[4];
void AssignMe() const { v[0] = 1; }
};
error: read-only variable is not assignable:
void AssignMe() const { v[0] = 1; }
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 35952] New: CXXNewExpr returns invalid end loc for valid code "new struct Foo; "
https://bugs.llvm.org/show_bug.cgi?id=35952
Bug ID: 35952
Summary: CXXNewExpr returns invalid end loc for valid code "new
struct Foo;"
Product: clang
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: C++
Assignee: unassignedclangb...@nondot.org
Reporter: hok...@google.com
CC: dgre...@apple.com, llvm-bugs@lists.llvm.org
Reproduce code:
```
void NewExprCheck::registerMatchers(MatchFinder *Finder) {
Finder->addMatcher(cxxNewExpr().bind("x"), this);
}
void NewExprCheck::check(const MatchFinder::MatchResult &Result) {
const auto *E = Result.Nodes.getNodeAs("x");
E->getEndLoc().dump(Result.Context->getSourceManager());
}
```
For the following test code:
```
struct Foo {}
void f() {
new struct Foo; // invalid end loc
new Foo; // valid end loc
}
```
--
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 35950] opt is defunct when code built without optimizations
https://bugs.llvm.org/show_bug.cgi?id=35950 David Blaikie changed: What|Removed |Added CC||dblai...@gmail.com Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #1 from David Blaikie --- This behavior is intentional. -O0 IR carries with it that contract that it should not be optimized - so opt satisfies that request by running the optimization passes, but they all do nothing to modify -O0 IR. This is important when preserving the semantic request of -O0 in IR that is merged from multiple other IR files, some of which may be compiled with -O0 and some with optimizations enabled. -- 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 35953] New: Compiler crashing while trying to compile precompiled header on windows
https://bugs.llvm.org/show_bug.cgi?id=35953
Bug ID: 35953
Summary: Compiler crashing while trying to compile precompiled
header on windows
Product: clang
Version: 5.0
Hardware: PC
OS: Windows NT
Status: NEW
Severity: normal
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: a...@arvid.io
CC: llvm-bugs@lists.llvm.org
Created attachment 19677
--> https://bugs.llvm.org/attachment.cgi?id=19677&action=edit
Repro & generated bug report
Using clang on windows, trying to compile the Catch2 single-header
(http://catch-lib.net) version 2.1.0 results in a crash.
Only if compiled as a precompiled header, though ('-x c++-header').
Attached is a full repro and the generated bug report by clang.
--
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 35954] New: Merge clang r322390 into 6.0 branch: [Lex] Avoid out-of-bounds dereference in LexAngledStringLiteral.
https://bugs.llvm.org/show_bug.cgi?id=35954 Bug ID: 35954 Summary: Merge clang r322390 into 6.0 branch: [Lex] Avoid out-of-bounds dereference in LexAngledStringLiteral. Product: clang Version: 6.0 Hardware: All OS: All Status: NEW Severity: normal Priority: P Component: Frontend Assignee: unassignedclangb...@nondot.org Reporter: vsap...@apple.com CC: llvm-bugs@lists.llvm.org Blocks: 35804 This commit https://reviews.llvm.org/rC322390 fixes stack buffer overflow discovered by OSS-Fuzz https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=3832 Referenced Bugs: https://bugs.llvm.org/show_bug.cgi?id=35804 [Bug 35804] [meta] 6.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 http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 3832 in oss-fuzz: llvm/clang-fuzzer: Stack-buffer-overflow in clang::Lexer::LexAngledStringLiteral
Comment #8 on issue 3832 by vsap...@gmail.com: llvm/clang-fuzzer: Stack-buffer-overflow in clang::Lexer::LexAngledStringLiteral https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=3832#c8 Bug was fixed in Clang in revision 322390. With provided test case it became reproducible in March 2017. Based on the code the bug was present before that, probably other changes made it easier to reproduce. -- 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 35955] New: llvm-tblgen for X86GenInstrInfo.inc.tmp takes a long time due to lots of instregex use
https://bugs.llvm.org/show_bug.cgi?id=35955 Bug ID: 35955 Summary: llvm-tblgen for X86GenInstrInfo.inc.tmp takes a long time due to lots of instregex use Product: libraries Version: trunk Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: Backend: X86 Assignee: unassignedb...@nondot.org Reporter: nicolaswe...@gmx.de CC: llvm-bugs@lists.llvm.org In a highly-parallel build (-j250), full build time is limited by llvm-tblgen taking 1 minute to generate X86GenInstrInfo.inc.tmp and X86GenSubtargetInfo.inc.tmp each. Command: cd /Users/thakis/src/llvm-build-goma/lib/Target/X86 && time /Users/thakis/src/llvm-build-goma/bin/llvm-tblgen -gen-instr-info -I /Users/thakis/src/llvm-rw/lib/Target/X86 -I /Users/thakis/src/llvm-rw/include -I /Users/thakis/src/llvm-rw/lib/Target /Users/thakis/src/llvm-rw/lib/Target/X86/X86.td -o /Users/thakis/src/llvm-build-goma/lib/Target/X86/X86GenInstrInfo.inc.tmp Profile: 43.05 s 100.0% 0 s llvm-tblgen (26142) 43.05 s 100.0% 0 s Main Thread 0x7659e 43.05 s 99.9% 0 s start 43.04 s 99.9% 0 smain 43.04 s 99.9% 0 s llvm::TableGenMain(char*, bool (*)(llvm::raw_ostream&, llvm::RecordKeeper&)) 40.53 s 94.1% 0 s (anonymous namespace)::LLVMTableGenMain(llvm::raw_ostream&, llvm::RecordKeeper&) 40.53 s 94.1% 0 s llvm::EmitInstrInfo(llvm::RecordKeeper&, llvm::raw_ostream&) 38.05 s 88.3% 0 sllvm::CodeGenTarget::getSchedModels() const 38.05 s 88.3% 0 s llvm::CodeGenSchedModels::CodeGenSchedModels(llvm::RecordKeeper&, llvm::CodeGenTarget const&) 37.93 s 88.1% 3.00 ms llvm::CodeGenSchedModels::collectSchedClasses() 37.88 s 87.9% 12.00 ms llvm::CodeGenSchedModels::createInstRWClass(llvm::Record*) 37.85 s 87.9% 38.00 ms llvm::SetTheory::expand(llvm::Record*) 37.77 s 87.7% 28.67 s (anonymous namespace)::InstRegexOp::apply(llvm::SetTheory&, llvm::DagInit*, llvm::SmallSetVector&, llvm::ArrayRef) 9.02 s 20.9% 1.45 s llvm::Regex::match(llvm::StringRef, llvm::SmallVectorImpl*) 41.00 ms0.0%0 s llvm::Regex::Regex(llvm::StringRef, unsigned int) Looking through http://llvm-cs.pcc.me.uk/utils/TableGen/CodeGenSchedule.cpp#60 and its callers on that stack suggests that reordering could help a lot here. All the instregex calls are pretty new (r315175, r316492, etc); maybe you could try to speed this up some? -- 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 35956] New: [X86] Scheduler information for FXRSTOR on Sandybridge looks bogus
https://bugs.llvm.org/show_bug.cgi?id=35956
Bug ID: 35956
Summary: [X86] Scheduler information for FXRSTOR on Sandybridge
looks bogus
Product: libraries
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: Backend: X86
Assignee: unassignedb...@nondot.org
Reporter: craig.top...@gmail.com
CC: llvm-bugs@lists.llvm.org
I highly doubt this is correct. Every other scheduler model shows an order of
magnitude more uops and instructions.
def SBWriteResGroup47 : SchedWriteRes<[SBPort4,SBPort5,SBPort01,SBPort23]> {
let Latency = 5;
let NumMicroOps = 5;
let ResourceCycles = [1,2,1,1];
}
def: InstRW<[SBWriteResGroup47], (instregex "FXRSTOR")>;
--
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 35957] New: When declaring variable with __auto_type, name should not be in scope until after initializer
https://bugs.llvm.org/show_bug.cgi?id=35957 Bug ID: 35957 Summary: When declaring variable with __auto_type, name should not be in scope until after initializer Product: clang Version: 5.0 Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: Frontend Assignee: unassignedclangb...@nondot.org Reporter: oliver.klei...@c-01a.de CC: llvm-bugs@lists.llvm.org Created attachment 19679 --> https://bugs.llvm.org/attachment.cgi?id=19679&action=edit example program code When declaring a variable with __auto_type and initializing it with a variable in an outer scope, having the same name, clang fails with "error: variable 'var' declared with deduced type '__auto_type' cannot appear in its own initializer" The GCC docs (https://gcc.gnu.org/onlinedocs/gcc/Typeof.html, at bottom) state that "[..]the name of the variable is not in scope until after the initializer." Note that GCC behaviour is similar to a variable declaration with a standard type-specifier. I attach a small example that demonstrates both cases. -- 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
