[llvm-bugs] [Bug 40813] New: Crash when trying to get layout information of undeductible auto type
https://bugs.llvm.org/show_bug.cgi?id=40813
Bug ID: 40813
Summary: Crash when trying to get layout information of
undeductible auto type
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: libclang
Assignee: unassignedclangb...@nondot.org
Reporter: emi...@crisal.io
CC: kli...@google.com, llvm-bugs@lists.llvm.org,
richard-l...@metafoo.co.uk
https://github.com/rust-lang-nursery/rust-bindgen crashes when ran on:
class BrowsingContext {
auto Tie(void* aUnused) const;
};
When trying to call getSizeOf on the auto type.
LLVM asserts:
/home/emilio/src/llvm-project/clang/lib/AST/ASTContext.cpp:2052:
clang::TypeInfo clang::ASTContext::getTypeInfoImpl(const clang::Type *) const:
Assertion `!A->getDeducedType().isNull() && "cannot request the size of an
undeduced or dependent auto type"' failed.
Got a patch, just figuring out how to write a test :)
--
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 40814] New: False positive due to truncation of constant when comparing against non-default AS pointer
https://bugs.llvm.org/show_bug.cgi?id=40814
Bug ID: 40814
Summary: False positive due to truncation of constant when
comparing against non-default AS pointer
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Static Analyzer
Assignee: dcough...@apple.com
Reporter: david.stenb...@ericsson.com
CC: dcough...@apple.com, llvm-bugs@lists.llvm.org
Seen on r354452.
When running:
$ clang --target=amdgcn --analyze ptr-cmp.cl
on the following test case:
#include
void bar(__global int *p) __attribute__((nonnull(1)));
void foo(__global int *p) {
if ((uint64_t)p <= 1UL << 32)
bar(p);
}
you get a warning for the call to bar():
ptr-cmp.cl:7:5: warning: Null pointer passed as an argument to a 'nonnull'
parameter
bar(p);
^~
which I think is a false positive. If you change the constant so that any of
its lower 32 bits are set, you don't get a warning. Same goes if you change the
comparison to a less-than operation.
I'm not very well-versed with the analyzer codebase, but as far as I can tell
the issue here seems to be that in SimpleSValBuilder::evalBinOpNN() the
right-hand side is converted to a void pointer for the default address space,
rather than the left-hand side's address space:
case nonloc::ConcreteIntKind: {
// FIXME: at the moment the implementation
// of modeling "pointers as integers" is not complete.
if (!BinaryOperator::isComparisonOp(op))
return UnknownVal();
// Transform the integer into a location and compare.
// FIXME: This only makes sense for comparisons. If we want to, say,
// add 1 to a LocAsInteger, we'd better unpack the Loc and add to it,
// then pack it back into a LocAsInteger.
llvm::APSInt i = rhs.castAs().getValue();
BasicVals.getAPSIntType(Context.VoidPtrTy).apply(i);
<-
return evalBinOpLL(state, op, lhsL, makeLoc(i), resultTy);
which in this case means that the constant is truncated from 8 to 4 bytes, so
we get ((uint64_t)p <= 0U) instead.
This can be seen by dumping the state afterwards in
ExprEngine::VisitBinaryOperator():
Store (direct and default bindings), 0x0 :
Expressions by stack frame:
#0 Calling foo
(LC1, S1356) p : &p
(LC1, S1370) p : &SymRegion{reg_$0<__global int * p>}
(LC1, S1373) (uint64_t)p : &SymRegion{reg_$0<__global int * p>} [as 128 bit
integer]
(LC1, S1386) 1UL << 32 : 4294967296 U64b
(LC1, S1390) 1UL << 32 : 4294967296 U128b
(LC1, S1393) (uint64_t)p <= 1UL << 32 : (reg_$0<__global int * p>) <= 0U
<--
Ranges are empty.
--
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 40786] obj2yaml symbol output missing section index for SHN_ABS and SHN_COMMON symbols
https://bugs.llvm.org/show_bug.cgi?id=40786 George Rimar changed: What|Removed |Added Resolution|--- |FIXED Status|CONFIRMED |RESOLVED --- Comment #2 from George Rimar --- r354661 -- 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 40815] New: Wrong generation of 256/512 bits vperm* from 128 mov
https://bugs.llvm.org/show_bug.cgi?id=40815
Bug ID: 40815
Summary: Wrong generation of 256/512 bits vperm* from 128 mov
Product: clang
Version: 7.0
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: LLVM Codegen
Assignee: unassignedclangb...@nondot.org
Reporter: gael.guenneb...@gmail.com
CC: llvm-bugs@lists.llvm.org, neeil...@live.com,
richard-l...@metafoo.co.uk
Clang 6 and 7, with -O2 and either AVX or AVX512 wrongly optimize some sequence
of 128 bits load/stores when the source memory has already been loaded in a 256
or 512 bits register.
See the self-contained demo:
https://godbolt.org/z/oFhMze
This issue has been discovered in Eigen
(http://eigen.tuxfamily.org/bz/show_bug.cgi?id=1684). The above demo includes
both a self-contained example and some Eigen-based examples at the bottom.
The problem is much clearer in AVX512 than in AVX as it generates:
vmovaps zmm0, zmmword ptr [rip + .LCPI2_0] # zmm0 =
[3,4,5,6,2,3,4,5,1,2,3,4,0,1,2,3]
vpermps zmm0, zmm0, zmmword ptr [rdi]
instead of:
# zmm0 = [12,13,14,15,8,9,10,11,4,5,6,7,0,1,2,3]
vpermps zmm0, zmm0, zmmword ptr [rdi]
(btw, I'm very impressed that it folded all this code to a single vpermps, too
bad its wrong)
With the "trunk" version on godbolt, the issue does not show up as clang/llvm
does not try to generate vperm* but instead it generates a sequence of
vinsert*.
I still reported this issue because:
1- It is not clear whether this issue has been properly identified and is not
simply hidden in trunk waiting to pop-up again.
2- It would be worth fixing the 7 branch.
3- Do you have any suggestion for us to workaround this issue with clang6/7 on
Eigen's side? The only full-proof solution I have so far is to ban
clang6/7+AVX{512} with a #error... That would be extremely bad as this would
mean about x8 slowdowns of matrix products, linear solves and the likes with
clang6/7 on AVX512.
4- Very minor: performance-wise, on AVX512 the vperm approach is usually
significantly faster than a sequence of vinsert, though vperm require a full
cache-line to old the indices.
--
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 40816] New: InnerLoopVectorizer::emitSCEVChecks(llvm::Loop *, llvm::BasicBlock *): Assertion `!Cost->foldTailByMasking() && "Cannot SCEV check stride or overflow when folding tail"' f
https://bugs.llvm.org/show_bug.cgi?id=40816 Bug ID: 40816 Summary: InnerLoopVectorizer::emitSCEVChecks(llvm::Loop *, llvm::BasicBlock *): Assertion `!Cost->foldTailByMasking() && "Cannot SCEV check stride or overflow when folding tail"' failed. Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: Loop Optimizer Assignee: unassignedb...@nondot.org Reporter: mikael.hol...@ericsson.com CC: llvm-bugs@lists.llvm.org Created attachment 21501 --> https://bugs.llvm.org/attachment.cgi?id=21501&action=edit reproducer Reproduce with: opt -S -o - -loop-vectorize bbi-23939_x86.ll -mtriple=x86_64-unknown-unknown -mcpu=skylake-avx512 -enable-interleaved-mem-accesses=0 This seems to be similar to https://bugs.llvm.org/show_bug.cgi?id=39417 but the fix for that in r345959 doesn't seem to help 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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 40817] New: Param sym names of unnamed funcs are incorrectly lowered
https://bugs.llvm.org/show_bug.cgi?id=40817
Bug ID: 40817
Summary: Param sym names of unnamed funcs are incorrectly
lowered
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Backend: PTX
Assignee: unassignedb...@nondot.org
Reporter: jas...@jawset.com
CC: llvm-bugs@lists.llvm.org
Created attachment 21502
--> https://bugs.llvm.org/attachment.cgi?id=21502&action=edit
PTX reproducer
Reproduce using llc on attached .ll file.
Note the missing "__unnamed_" prefix in the operand name.
.func (.param .b32 func_retval0) __unnamed_1(
.param .b64 __unnamed_1_param_0
) {
// ...
ld.param.u64 %rd1, [_param_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
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 13265 in oss-fuzz: llvm/llvm-isel-fuzzer--aarch64-gisel: ASSERT: ScalarDef->getOpcode() == TargetOpcode::G_CONSTANT
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevlieg...@apple.com, igm...@gmail.com, mit...@google.com, bigchees...@gmail.com, eney...@google.com, llvm-b...@lists.llvm.org, j...@chromium.org, v...@apple.com, mitchphi...@outlook.com, xpl...@gmail.com, akils...@apple.com Labels: ClusterFuzz Stability-Memory-AddressSanitizer Reproducible Engine-libfuzzer Proj-llvm Reported-2019-02-22 Type: Bug New issue 13265 by ClusterFuzz-External: llvm/llvm-isel-fuzzer--aarch64-gisel: ASSERT: ScalarDef->getOpcode() == TargetOpcode::G_CONSTANT https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=13265 Detailed report: https://oss-fuzz.com/testcase?key=5718860483788800 Project: llvm Fuzzer: libFuzzer_llvm_llvm-isel-fuzzer--aarch64-gisel Fuzz target binary: llvm-isel-fuzzer--aarch64-gisel Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: ASSERT Crash Address: Crash State: ScalarDef->getOpcode() == TargetOpcode::G_CONSTANT AArch64InstructionSelector::select llvm::InstructionSelect::runOnMachineFunction Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201902200434:201902220416 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5718860483788800 Issue filed automatically. See https://github.com/google/oss-fuzz/blob/master/docs/reproducing.md for instructions to reproduce this bug locally. When you fix this bug, please * mention the fix revision(s). * state whether the bug was a short-lived regression or an old bug in any stable releases. * add any other useful information. This information can help downstream consumers. If you need to contact the OSS-Fuzz team with a question, concern, or any other feedback, please file an issue at https://github.com/google/oss-fuzz/issues. -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 40818] New: --compress-debug-sections causes loss of symbols and invalid relocations
https://bugs.llvm.org/show_bug.cgi?id=40818 Bug ID: 40818 Summary: --compress-debug-sections causes loss of symbols and invalid relocations Product: tools Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: llvm-objcopy Assignee: unassignedb...@nondot.org Reporter: jh7370.2...@my.bristol.ac.uk CC: alexander.v.shaposhni...@gmail.com, jake.h.ehrl...@gmail.com, jh7370.2...@my.bristol.ac.uk, llvm-bugs@lists.llvm.org, ruppre...@google.com It's entirely reasonable to have a relocation targeting a section symbol in the debug sections. However, I just discovered that if you run --compress-debug-sections on an ELF containing such a reference, it succeeds, but the symbols are lost. This can potentially lead to relocations with invalid or incorrect symbol references. This bug is blocking me landing https://reviews.llvm.org/D58510, because one of the tests updated in that change references such a symbol, whereas before it was (probably unintentionally) not referencing any symbol at all. I also think it essentially renders --compress-debug-sections useless in any real case. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 28418] opt never finishes compiling with -gvn option
https://bugs.llvm.org/show_bug.cgi?id=28418 John Brawn changed: What|Removed |Added Status|NEW |RESOLVED CC||john.br...@arm.com Resolution|--- |FIXED --- Comment #2 from John Brawn --- This was fixed in LLVM 4.0.0 by r275483. -- 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 25404] Crash on typedef in OpenCL 2.0
https://bugs.llvm.org/show_bug.cgi?id=25404 Anastasia Stulova changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #14 from Anastasia Stulova --- If I compile the following code line with -cl-std=CL2.0 or -cl-std=c++ it has no assertion any more. So I am closing this. -- 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 40819] New: Crash during compilation
https://bugs.llvm.org/show_bug.cgi?id=40819 Bug ID: 40819 Summary: Crash during compilation Product: clang Version: 7.0 Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: Frontend Assignee: unassignedclangb...@nondot.org Reporter: m...@mark-ingram.com CC: llvm-bugs@lists.llvm.org, neeil...@live.com, richard-l...@metafoo.co.uk Created attachment 21503 --> https://bugs.llvm.org/attachment.cgi?id=21503&action=edit Crash dump Crash when compiling C++ code. 0x7FF7C98ABF27 (0x0238EB076930 0x0238EB06D910 0x0238EB0772E8 0x0238F3E7F630) 0x7FF7C98ABE0E (0x02380012 0x7FF7CA7C1603 0x0009 0x02380013) 0x7FF7C8DF1254 (0x 0x 0x0238EB021AB0 0x0238EB090380) 0x7FF7C854227D (0x0238EB090380 0x0238EB06B2F0 0x0238EB00A890 0x7FF7C859A2F9) 0x7FF7C8506847 (0x00F77678DD01 0x 0x 0x0238EB060930) 0x7FF7C859AF5C (0x0238EB05D740 0x0F81E1798573 0x0238EB00E96C 0x03E3) 0x7FF7C6BA6E48 (0x 0x 0x00F77678E680 0x00F77678E430) 0x7FF7C6BA4317 (0x 0x 0x 0x) 0x7FF7C9A45780 (0x 0x 0x 0x) 0x7FFB31E23DC4 (0x 0x 0x 0x), BaseThreadInitThunk() + 0x14 bytes(s) 0x7FFB33533691 (0x 0x 0x 0x), RtlUserThreadStart() + 0x21 bytes(s) C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\Common7\IDE\clang-cl.exe : error : clang frontend command failed due to signal (use -v to see invocation) clang version 7.0.0 (tags/RELEASE_700/final) Target: x86_64-pc-windows-msvc Thread model: posix InstalledDir: C:\PROGRA~1\LLVM\bin -- 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 13272 in oss-fuzz: llvm/clang-fuzzer: ASSERT: N.ugt(ArraySize) && "bounds check failed for in-bounds index"
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevlieg...@apple.com, igm...@gmail.com, mit...@google.com, bigchees...@gmail.com, eney...@google.com, llvm-b...@lists.llvm.org, j...@chromium.org, v...@apple.com, mitchphi...@outlook.com, xpl...@gmail.com, akils...@apple.com Labels: ClusterFuzz Stability-Memory-AddressSanitizer Reproducible Engine-libfuzzer Proj-llvm Reported-2019-02-22 Type: Bug New issue 13272 by ClusterFuzz-External: llvm/clang-fuzzer: ASSERT: N.ugt(ArraySize) && "bounds check failed for in-bounds index" https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=13272 Detailed report: https://oss-fuzz.com/testcase?key=5663648423346176 Project: llvm Fuzzer: libFuzzer_llvm_clang-fuzzer Fuzz target binary: clang-fuzzer Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: ASSERT Crash Address: Crash State: N.ugt(ArraySize) && "bounds check failed for in-bounds index" HandleLValueArrayAdjustment ArrayExprEvaluator::VisitCXXConstructExpr Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201806260706:201806270010 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5663648423346176 Issue filed automatically. See https://github.com/google/oss-fuzz/blob/master/docs/reproducing.md for instructions to reproduce this bug locally. When you fix this bug, please * mention the fix revision(s). * state whether the bug was a short-lived regression or an old bug in any stable releases. * add any other useful information. This information can help downstream consumers. If you need to contact the OSS-Fuzz team with a question, concern, or any other feedback, please file an issue at https://github.com/google/oss-fuzz/issues. -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 13201 in oss-fuzz: llvm/llvm-opt-fuzzer--x86_64-instcombine: Abrt in llvm::llvm_unreachable_internal
Comment #2 on issue 13201 by ClusterFuzz-External: llvm/llvm-opt-fuzzer--x86_64-instcombine: Abrt in llvm::llvm_unreachable_internal https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=13201#c2 ClusterFuzz has detected this issue as fixed in range 201902200434:201902220416. Detailed report: https://oss-fuzz.com/testcase?key=5700350986682368 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: Abrt Crash Address: 0x0001 Crash State: llvm::llvm_unreachable_internal llvm::InstCombiner::visitFCmpInst llvm::InstCombiner::run Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201810170227:20181623 Fixed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201902200434:201902220416 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5700350986682368 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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 13201 in oss-fuzz: llvm/llvm-opt-fuzzer--x86_64-instcombine: Abrt in llvm::llvm_unreachable_internal
Updates: Labels: ClusterFuzz-Verified Status: Verified Comment #3 on issue 13201 by ClusterFuzz-External: llvm/llvm-opt-fuzzer--x86_64-instcombine: Abrt in llvm::llvm_unreachable_internal https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=13201#c3 ClusterFuzz testcase 5700350986682368 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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 11638 in oss-fuzz: llvm/llvm-opt-fuzzer--x86_64-loop_vectorize: ASSERT: !KeyInfoT::isEqual(Val, EmptyKey) && !KeyInfoT::isEqual(Val, TombstoneKey) && "E
Updates: Labels: Deadline-Approaching Comment #4 on issue 11638 by sheriff...@chromium.org: llvm/llvm-opt-fuzzer--x86_64-loop_vectorize: ASSERT: !KeyInfoT::isEqual(Val, EmptyKey) && !KeyInfoT::isEqual(Val, TombstoneKey) && "E https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=11638#c4 This bug is approaching its deadline for being fixed, and will be automatically derestricted within 7 days. If a fix is planned within 2 weeks after the deadline has passed, a grace extension can be granted. - Your friendly Sheriffbot -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 11631 in oss-fuzz: llvm/llvm-isel-fuzzer--aarch64-O2: ASSERT: isa(Val) && "cast() argument of incompatible type!"
Updates: Labels: Deadline-Approaching Comment #3 on issue 11631 by sheriff...@chromium.org: llvm/llvm-isel-fuzzer--aarch64-O2: ASSERT: isa(Val) && "cast() argument of incompatible type!" https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=11631#c3 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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 40820] New: [AMDGPU][MC] Unclear limitations on use of expressions
https://bugs.llvm.org/show_bug.cgi?id=40820 Bug ID: 40820 Summary: [AMDGPU][MC] Unclear limitations on use of expressions 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 Most assembler constructs allow use of expressions, however in many cases there is an unclear limitation: an expression must start with a number. Examples: set x = 3 s_getreg_b32 s2, hwreg(10 + x) // ok s_getreg_b32 s2, hwreg(x + 10) // error Full list of parser functions which enforce this limitation: - parseHwreg - parseSendMsgOp - parseSWaitCntOps - parseSOppBrTarget - parseIntWithPrefix - parseOperandArrayWithPrefix - parseOModOperand - parseDfmtNfmt -- 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 11635 in oss-fuzz: llvm/clang-fuzzer: ASSERT: DeclAccess != AS_none
Updates: Labels: Deadline-Approaching Comment #3 on issue 11635 by sheriff...@chromium.org: llvm/clang-fuzzer: ASSERT: DeclAccess != AS_none https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=11635#c3 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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 40821] New: Headers/arm-fp16-header.c & Headers/arm-neon-header.c tests fail on ppc64
https://bugs.llvm.org/show_bug.cgi?id=40821 Bug ID: 40821 Summary: Headers/arm-fp16-header.c & Headers/arm-neon-header.c tests fail on ppc64 Product: clang Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: -New Bugs Assignee: unassignedclangb...@nondot.org Reporter: mgo...@gentoo.org CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org, neeil...@live.com, richard-l...@metafoo.co.uk Created attachment 21505 --> https://bugs.llvm.org/attachment.cgi?id=21505&action=edit clang-8.0.0_rc2_20190222-115204.log.xz Proxying a bug reported by Gentoo ppc64 user. Failing Tests (2): Clang :: Headers/arm-fp16-header.c Clang :: Headers/arm-neon-header.c Apparently the tests somehow depend on glibc having 32-bit stubs (?) on non-ARM platforms. I'm pasting the most relevant error below, and attaching a full build log. Command Output (stderr): -- + : 'RUN: at line 1' + /var/tmp/portage/sys-devel/clang-8.0.0_rc2/work/x/y/cfe-8.0.0rc2.src-abi_ppc_64.ppc64/bin/clang -fsyntax-only -ffreestanding --target=aarch64-none-eabi -march=armv8.2-a+fp16 -std=c89 -xc /var/tmp/portage/sys-devel/clang-8.0.0_rc2/work/x/y/cfe-8.0.0rc2.src/test/Headers/arm-fp16-header.c In file included from /var/tmp/portage/sys-devel/clang-8.0.0_rc2/work/x/y/cfe-8.0.0rc2.src/test/Headers/arm-fp16-header.c:19: In file included from /var/tmp/portage/sys-devel/clang-8.0.0_rc2/work/x/y/cfe-8.0.0rc2.src-abi_ppc_64.ppc64/bin/../../../../lib/clang/8.0.0/include/arm_fp16.h:27: In file included from /usr/include/stdint.h:26: In file included from /usr/include/bits/libc-header-start.h:33: In file included from /usr/include/features.h:452: /usr/include/gnu/stubs.h:8:11: fatal error: 'gnu/stubs-32.h' file not found # include ^~~~ 1 error generated. -- 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 40473] Slow OpenMP reduction on NVIDIA GPUs - 100x performance regression
https://bugs.llvm.org/show_bug.cgi?id=40473 Alexey Bataev changed: What|Removed |Added Status|NEW |RESOLVED Fixed By Commit(s)||r354479 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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 40822] New: common glob interceptor doesn't handle GLOB_DOFFS correctly
https://bugs.llvm.org/show_bug.cgi?id=40822
Bug ID: 40822
Summary: common glob interceptor doesn't handle GLOB_DOFFS
correctly
Product: compiler-rt
Version: 6.0
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: asan
Assignee: unassignedb...@nondot.org
Reporter: ade...@gmail.com
CC: llvm-bugs@lists.llvm.org
It looks like unpoison_glob_t doesn't properly account for GLOB_DOOFFS when
iterating over the glob results. By not adding pglob->gl_offs to the iteration
index, it ends up calling strlen on a null pointer.
Here's what the manpage for glob has to say about GLOB_DOOFFS:
GLOB_DOOFFS
Reserve pglob->gl_offs slots at the beginning of the list of
strings in pglob->pathv. The reserved slots contain null pointers.
I found this while trying to reproduce an old memory leak in libgssapi-krb5
(http://krbdev.mit.edu/rt/Ticket/Display.html?id=7981). At one time, the
library called glob with GLOB_DOOFFS (it doesn't any more).
$ cat test.c
#include
#include
#include
#include
#include
#include
#include
#include
int main(int argc, char* argv[]) {
int fd = creat("foo", S_IRWXU | S_IRWXG | S_IRWXO);
if (fd == -1) {
perror("creat");
return 1;
}
int rc = close(fd);
if (rc) {
perror("close");
return rc;
}
glob_t globbuf;
memset(&globbuf, 0, sizeof(globbuf));
int flags = 0;
#ifdef TEST_DOOFFS
globbuf.gl_offs = 1;
flags |= GLOB_DOOFFS;
#endif
rc = glob("foo", flags, NULL, &globbuf);
if (rc) {
perror("glob");
globfree(&globbuf);
return rc;
}
for (int i = 0; i < globbuf.gl_pathc; i++) {
int index = i;
#ifdef TEST_DOOFFS
index += globbuf.gl_offs;
#endif
printf("%s\n", globbuf.gl_pathv[index]);
}
globfree(&globbuf);
return 0;
}
$ clang -g -o test test.c && ./test
foo
$ clang -g -o test -DTEST_DOOFFS=1 test.c && ./test
foo
$ clang -fsanitize=address -g -o test test.c && ./test
foo
$ clang -fsanitize=address -g -o test -DTEST_DOOFFS=1 test.c && ./test
AddressSanitizer:DEADLYSIGNAL
=
==28548==ERROR: AddressSanitizer: SEGV on unknown address 0x (pc
0x7f39228a85a1 bp 0x7ffc5b5f9110 sp 0x7ffc5b5f T0)
==28548==The signal is caused by a READ memory access.
==28548==Hint: address points to the zero page.
#0 0x7f39228a85a0
/build/glibc-OTsEL5/glibc-2.27/string/../sysdeps/x86_64/multiarch/strlen-avx2.S:59
#1 0x45d83b in unpoison_glob_t(void*, __sanitizer::__sanitizer_glob_t*)
(/tmp/test+0x45d83b)
#2 0x45e3d2 in glob (/tmp/test+0x45e3d2)
#3 0x512422 in main /tmp/test.c:28:8
#4 0x7f392273bb96 in __libc_start_main
/build/glibc-OTsEL5/glibc-2.27/csu/../csu/libc-start.c:310
#5 0x419e29 in _start (/tmp/test+0x419e29)
AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV
/build/glibc-OTsEL5/glibc-2.27/string/../sysdeps/x86_64/multiarch/strlen-avx2.S:59
==28548==ABORTING
--
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 40823] New: Incompatible version number format in CheckCompilerVer
https://bugs.llvm.org/show_bug.cgi?id=40823 Bug ID: 40823 Summary: Incompatible version number format in CheckCompilerVer Product: Build scripts Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: cmake Assignee: unassignedb...@nondot.org Reporter: jas...@jawset.com CC: llvm-bugs@lists.llvm.org CheckCompilerVersion.cmake uses set(MSVC_MIN 19.00.24213.1) but cmake only extracts major.minor for MSVC. This prevents Cmake from building with clang and a new enough MSVC version like 19.00.24215.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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 40824] New: LLVM produces invalid assembler
https://bugs.llvm.org/show_bug.cgi?id=40824 Bug ID: 40824 Summary: LLVM produces invalid assembler Product: tools Version: 7.0 Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: llc Assignee: unassignedb...@nondot.org Reporter: b...@smart-cactus.org CC: llvm-bugs@lists.llvm.org Created attachment 21506 --> https://bugs.llvm.org/attachment.cgi?id=21506&action=edit LLVM IR which reproduces issue Optimising and then compiling the attached LLVM IR with LLVM 7.0.1 produces invalid assembler: $ opt -O3 Repro.ll > opt.bc $ llc opt.bc -o llc.s -O3 $ as llc.s llc.s: Assembler messages: llc.s:367: Error: junk at end of line, first unrecognized character is `,' -- 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 40825] New: [x86-64] Suboptimal codegen on uint128 negation
https://bugs.llvm.org/show_bug.cgi?id=40825 Bug ID: 40825 Summary: [x86-64] Suboptimal codegen on uint128 negation Product: new-bugs Version: trunk Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: arthur.j.odw...@gmail.com CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org Moved discussion from 40486. Sanjay Patel says: Arthur O'Dwyer said: > If you're still looking for work ;) I see improvement, but not perfection, > in Uint128::negate(). Here's an example. > https://godbolt.org/z/BGRoQ4 > xorl %eax, %eax > xorl %ecx, %ecx > subq (%rdi), %rcx > sbbq 8(%rdi), %rax > movq %rcx, (%rdi) > movq %rax, 8(%rdi) > retq > I'm not sure if GCC's codegen is perfect, or if there's a way to use "sbbq" > to save an instruction here somehow. > negq (%rdi) > adcq $0, 8(%rdi) > negq 8(%rdi) > ret Hmmm...those 2 tests are independent of what we've done so far: 1. In the uint128 case, we're not forming the overflow intrinsic in IR (CGP) because that's not a legal type (native type for x86). 2. In the uint64 case, we are forming the overflow intrinsic now (so it's better than before), but the x86 lowering needs to be improved. Since they end up with identical asm, I'm hoping that is a single x86-specific backend fix in lowering X86ISD::SUB to 'neg'. Do you mind filing a new bug report with those examples? It's hard to keep all of these problems organized with the overlap. -- 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 40826] New: Lost metadata information during optimization
https://bugs.llvm.org/show_bug.cgi?id=40826 Bug ID: 40826 Summary: Lost metadata information during optimization Product: new-bugs Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: jan.ves...@rutgers.edu CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org Created attachment 21507 --> https://bugs.llvm.org/attachment.cgi?id=21507&action=edit link-proj2.ll I've run into a situation when some operations don't have debug location information. I'm not sure if it's a bug or intended behaviour. The example is attached. proj-link2.ll is the original unoptimized snippet, proj-opt2.ll is the result after running opt -O3. thanks, Jan -- 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 40559] Predefined __FLT16_MANT_DIG__ defined on targets that don't support _Float16
https://bugs.llvm.org/show_bug.cgi?id=40559 Nemanja Ivanovic changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #2 from Nemanja Ivanovic --- Fix committed in https://reviews.llvm.org/rL354512 -- 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 40827] New: lldb crashes on a file compiled with clang-3.8 at -O3
https://bugs.llvm.org/show_bug.cgi?id=40827
Bug ID: 40827
Summary: lldb crashes on a file compiled with clang-3.8 at -O3
Product: lldb
Version: unspecified
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: All Bugs
Assignee: lldb-...@lists.llvm.org
Reporter: qrzh...@gatech.edu
CC: llvm-bugs@lists.llvm.org
It affects the latest lldb trunk version.
It only happens with clang-3.8 at -O3. 4.0 and later versions work fine.
$ lldb-trunk -v
lldb version 9.0.0 (https://llvm.org/svn/llvm-project/lldb/trunk revision
354654)
clang revision 354654
llvm revision 354654
$ cat abc.c
char a;
int main() {
int i;
int b[] = {7, 7, 7};
a = b[2];
i = 0;
for (; i < 5; i++)
;
optimize_me_not();
}
$ cat outer.c
optimize_me_not() {}
$ cat cmds
b 9
r
p i
kill
q
$ clang-3.8 -O3 -g outer.c abc.c
$ lldb-trunk -s cmds -b a.out
(lldb) target create "a.out"
Current executable set to 'a.out' (x86_64).
(lldb) command source -s 0 'cmds'
Executing commands in '/home/absozero/projects/LLDB-testing/reduce/cmds'.
(lldb) b 9
Breakpoint 1: where = a.out`main + 10 at abc.c:9:3, address =
0x004004aa
(lldb) r
a.out was compiled with optimization - stepping may behave oddly; variables may
not be available.
#0 0x5573e13b3d4a (lldb-trunk+0x25d4a)
#1 0x5573e13b2074 (lldb-trunk+0x24074)
#2 0x5573e13b21b2 (lldb-trunk+0x241b2)
#3 0x7f89a0687890 __restore_rt
(/lib/x86_64-linux-gnu/libpthread.so.0+0x12890)
#4 0x7f8998b78c40 (/lib/x86_64-linux-gnu/libc.so.6+0x18ec40)
#5 0x7f899a6a6641 lldb_private::DataBufferHeap::CopyData(void const*,
unsigned long)
(/home/absozero/trunk/root-clang/bin/../lib/liblldb.so.9svn+0xd62641)
#6 0x7f899a4e94d7 lldb_private::DWARFExpression::CopyOpcodeData(unsigned
long, unsigned long, unsigned char)
(/home/absozero/trunk/root-clang/bin/../lib/liblldb.so.9svn+0xba54d7)
#7 0x7f899a9b8674
SymbolFileDWARF::ParseVariableDIE(lldb_private::SymbolContext const&, DWARFDIE
const&, unsigned long)
(/home/absozero/trunk/root-clang/bin/../lib/liblldb.so.9svn+0x1074674)
#8 0x7f899a9b93c4
SymbolFileDWARF::ParseVariables(lldb_private::SymbolContext const&, DWARFDIE
const&, unsigned long, bool, bool, lldb_private::VariableList*)
(/home/absozero/trunk/root-clang/bin/../lib/liblldb.so.9svn+0x10753c4)
#9 0x7f899a9ba150
SymbolFileDWARF::ParseVariablesForContext(lldb_private::SymbolContext const&)
(/home/absozero/trunk/root-clang/bin/../lib/liblldb.so.9svn+0x1076150)
#10 0x7f899a5a8e82
lldb_private::SymbolVendor::ParseVariablesForContext(lldb_private::SymbolContext
const&) (/home/absozero/trunk/root-clang/bin/../lib/liblldb.so.9svn+0xc64e82)
#11 0x7f899a56312e lldb_private::Block::GetBlockVariableList(bool)
(/home/absozero/trunk/root-clang/bin/../lib/liblldb.so.9svn+0xc1f12e)
#12 0x7f899a450b14
lldb_private::FormatEntity::Format(lldb_private::FormatEntity::Entry const&,
lldb_private::Stream&, lldb_private::SymbolContext const*,
lldb_private::ExecutionContext const*, lldb_private::Address const*,
lldb_private::ValueObject*, bool, bool)
(/home/absozero/trunk/root-clang/bin/../lib/liblldb.so.9svn+0xb0cb14)
#13 0x7f899a4500b1
lldb_private::FormatEntity::Format(lldb_private::FormatEntity::Entry const&,
lldb_private::Stream&, lldb_private::SymbolContext const*,
lldb_private::ExecutionContext const*, lldb_private::Address const*,
lldb_private::ValueObject*, bool, bool)
(/home/absozero/trunk/root-clang/bin/../lib/liblldb.so.9svn+0xb0c0b1)
#14 0x7f899a4500b1
lldb_private::FormatEntity::Format(lldb_private::FormatEntity::Entry const&,
lldb_private::Stream&, lldb_private::SymbolContext const*,
lldb_private::ExecutionContext const*, lldb_private::Address const*,
lldb_private::ValueObject*, bool, bool)
(/home/absozero/trunk/root-clang/bin/../lib/liblldb.so.9svn+0xb0c0b1)
#15 0x7f899a450167
lldb_private::FormatEntity::Format(lldb_private::FormatEntity::Entry const&,
lldb_private::Stream&, lldb_private::SymbolContext const*,
lldb_private::ExecutionContext const*, lldb_private::Address const*,
lldb_private::ValueObject*, bool, bool)
(/home/absozero/trunk/root-clang/bin/../lib/liblldb.so.9svn+0xb0c167)
#16 0x7f899a626288
lldb_private::StackFrame::DumpUsingSettingsFormat(lldb_private::Stream*, bool,
char const*)
(/home/absozero/trunk/root-clang/bin/../lib/liblldb.so.9svn+0xce2288)
#17 0x7f899a6265b0
lldb_private::StackFrame::GetStatus(lldb_private::Stream&, bool, bool, bool,
char const*)
(/home/absozero/trunk/root-clang/bin/../lib/liblldb.so.9svn+0xce25b0)
#18 0x7f899a62d25a
lldb_private::StackFrameList::GetStatus(lldb_private::Stream&, unsigned int,
unsigned int, bool, unsigned int, bool, char const*)
(/home/absozero/trunk/root-clang/bin/../lib/liblldb.so.9svn+0xce925a)
#19 0x7f899a65a0e0 lldb_private::Thread::GetStatus(lldb_private::Stream&,
unsigned int, unsigned int, u
[llvm-bugs] Issue 13326 in oss-fuzz: llvm/clang-fuzzer: Stack-overflow in clang::DiagnosticIDs::isUnrecoverable
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevlieg...@apple.com, igm...@gmail.com, mit...@google.com, bigchees...@gmail.com, eney...@google.com, llvm-b...@lists.llvm.org, j...@chromium.org, v...@apple.com, mitchphi...@outlook.com, xpl...@gmail.com, akils...@apple.com Labels: ClusterFuzz Stability-Memory-AddressSanitizer Reproducible Engine-libfuzzer Proj-llvm Reported-2019-02-23 Type: Bug New issue 13326 by ClusterFuzz-External: llvm/clang-fuzzer: Stack-overflow in clang::DiagnosticIDs::isUnrecoverable https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=13326 Detailed report: https://oss-fuzz.com/testcase?key=5648705695252480 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: 0x7ffc43762d28 Crash State: clang::DiagnosticIDs::isUnrecoverable clang::DiagnosticIDs::ProcessDiag clang::DiagnosticsEngine::EmitCurrentDiagnostic Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201901220414:201902020421 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5648705695252480 Issue filed automatically. See https://github.com/google/oss-fuzz/blob/master/docs/reproducing.md for instructions to reproduce this bug locally. When you fix this bug, please * mention the fix revision(s). * state whether the bug was a short-lived regression or an old bug in any stable releases. * add any other useful information. This information can help downstream consumers. If you need to contact the OSS-Fuzz team with a question, concern, or any other feedback, please file an issue at https://github.com/google/oss-fuzz/issues. -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 40528] [DTU] DomTreeUpdater's Eager strategy fails to update DomTree, Lazy strategy works OK; need to fix or clarify the documentation
https://bugs.llvm.org/show_bug.cgi?id=40528 Chijun Sima changed: What|Removed |Added Status|REOPENED|RESOLVED Fixed By Commit(s)||r354437 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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 40828] New: Merge r354721 to the 8.0 branch
https://bugs.llvm.org/show_bug.cgi?id=40828 Bug ID: 40828 Summary: Merge r354721 to the 8.0 branch Product: clang Version: 8.0 Hardware: All OS: OpenBSD Status: NEW Severity: release blocker Priority: P Component: Driver Assignee: unassignedclangb...@nondot.org Reporter: b...@comstyle.com CC: llvm-bugs@lists.llvm.org, neeil...@live.com, richard-l...@metafoo.co.uk Blocks: 40331 Merge r354721 back to the 8.0 branch. OpenBSD Driver adjustment now that we use lld as the base linker. 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 40829] New: Merge r354723 to the 8.0 branch
https://bugs.llvm.org/show_bug.cgi?id=40829 Bug ID: 40829 Summary: Merge r354723 to the 8.0 branch Product: clang Version: 8.0 Hardware: All OS: OpenBSD Status: NEW Severity: release blocker Priority: P Component: Frontend Assignee: unassignedclangb...@nondot.org Reporter: b...@comstyle.com CC: llvm-bugs@lists.llvm.org, neeil...@live.com, richard-l...@metafoo.co.uk Blocks: 40331 Merge r354723 back to the 8.0 branch. Frontend adjustment for OpenBSD switching to libc++. 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
