[llvm-bugs] [Bug 35950] opt is defunct when code built without optimizations
https://bugs.llvm.org/show_bug.cgi?id=35950 Jiri Slaby changed: What|Removed |Added Resolution|INVALID |--- CC||c.ca...@imperial.ac.uk, ||d...@su-root.co.uk Status|RESOLVED|REOPENED --- Comment #2 from Jiri Slaby --- (In reply to David Blaikie from comment #1) > 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. Hmm, that is not nice and even incorrect. If somebody wants such behaviour, introduce a new compiler option and do not abuse -O0. Or introduce an option to disable this new behaviour. -O0 is even implicit -- users do not actually "disable" optimizations, they just do not enable any. And even if they do -O0, that does not necessarily mean they do not want to optimize later. The problem with the current approach is that many users do not optimize during compilation, but optimize the code in runtime (via PassManagers) and multiple times in different ways. Klee is one of the examples. And given this behaviour changed in clang 5, klee is unable to optimize, so this is clearly a regression. -- 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 5231 in oss-fuzz: llvm/llvm-isel-fuzzer--aarch64-O2: ASSERT: (!N.getNode() || N.getValueType() == MVT::Other) && "DAG root value is not a cha
Comment #3 on issue 5231 by ClusterFuzz-External: llvm/llvm-isel-fuzzer--aarch64-O2: ASSERT: (!N.getNode() || N.getValueType() == MVT::Other) && "DAG root value is not a cha https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=5231#c3 ClusterFuzz has detected this issue as fixed in range 201801150720:201801160714. Detailed report: https://oss-fuzz.com/testcase?key=5148675740270592 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: (!N.getNode() || N.getValueType() == MVT::Other) && "DAG root value is not a cha llvm::SelectionDAG::ReplaceAllUsesWith llvm::SelectionDAG::ReplaceAllUsesWith Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201801090613:201801100627 Fixed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201801150720:201801160714 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5148675740270592 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 5231 in oss-fuzz: llvm/llvm-isel-fuzzer--aarch64-O2: ASSERT: (!N.getNode() || N.getValueType() == MVT::Other) && "DAG root value is not a cha
Updates: Labels: ClusterFuzz-Verified Status: Verified Comment #4 on issue 5231 by ClusterFuzz-External: llvm/llvm-isel-fuzzer--aarch64-O2: ASSERT: (!N.getNode() || N.getValueType() == MVT::Other) && "DAG root value is not a cha https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=5231#c4 ClusterFuzz testcase 5148675740270592 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 35958] New: [GlobalISel] CodeModel::Large sequences are not emitted
https://bugs.llvm.org/show_bug.cgi?id=35958
Bug ID: 35958
Summary: [GlobalISel] CodeModel::Large sequences are not
emitted
Product: new-bugs
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: roger.ferreriba...@arm.com
CC: llvm-bugs@lists.llvm.org, qcolom...@apple.com
Created attachment 19680
--> https://bugs.llvm.org/attachment.cgi?id=19680&action=edit
C Testcase
Hi all,
the following testcase needs to be built with -mcmodel=large as it accesses
huge arrays.
-- t.c
#define BIG(1024*1024*1024)
int foo1[BIG];
int foo2[BIG];
int main(void)
{
return foo1[0] + foo2[0];
}
-- end of t.c
unfortunately GlobalISel seems to be unable to select the "large" sequence of
instructions.
$ aarch64-linux-gnu-clang -DADJUST=0 -o t.exe t.c -mcmodel=large
/tmp/t-0e2765.o: In function `main':
t.c:(.text+0x4): relocation truncated to fit: R_AARCH64_ADR_PREL_PG_HI21
against symbol `foo1' defined in COMMON section in /tmp/t-0e2765.o
clang-6.0: error: linker command failed with exit code 1 (use -v to see
invocation)
Looking at the generated GMir
%bb.1: derived from LLVM BB %entry
%1:_(s32) = G_CONSTANT i32 0
%4:_(p0) = G_GLOBAL_VALUE @foo1
%3:_(p0) = COPY %4(p0)
%7:_(p0) = G_GLOBAL_VALUE @foo2
%6:_(p0) = COPY %7(p0)
...
looks like G_GLOBAL_VALUE is lowered by the InstructionSelector to the pseudo
MOVaddr:
Selecting:
%4:gpr(p0) = G_GLOBAL_VALUE @foo1
(... tons of gibberish ...)
Into:
%4:gpr64(p0) = MOVaddr target-flags(aarch64-page) @foo1,
target-flags(aarch64-pageoff, aarch64-nc) @foo1
which is later expanded to
%x8 = ADRP target-flags(aarch64-page) @foo1
renamable %x8 = ADDXri %x8, target-flags(aarch64-pageoff, aarch64-nc) @foo1, 0
which ends being
adrpx8, foo1
add x8, x8, :lo12:foo1
which will cause the linker failure.
Disabling GlobalISel via -mllvm -global-isel=0 we see that the expected
sequence is generated
movzx9, #:abs_g0_nc:foo1
movkx9, #:abs_g1_nc:foo1
movkx9, #:abs_g2_nc:foo1
movkx9, #:abs_g3:foo1
SelectionDAG strategy is a bit different: it wraps the ISD::GlobalAddress
during legalization into a AArch64ISD::WrapperLarge and then uses a Pat<...> to
expand it.
Kind regards,
Roger
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 35959] New: print warnings normally in /fallback mode
https://bugs.llvm.org/show_bug.cgi?id=35959 Bug ID: 35959 Summary: print warnings normally in /fallback mode Product: clang Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: Driver Assignee: unassignedclangb...@nondot.org Reporter: tras...@gmail.com CC: llvm-bugs@lists.llvm.org clang prints warning(clang) in fallback mode so MSBuild does not fail the build because of errors printed by clang. But actually warnings could and should be printed normally (so MSBuild/VS picks them up) as I still want to benefit from clang's rich diagnostics even if it fails at some point. Proof-of-concept: Index: TextDiagnostic.cpp === --- TextDiagnostic.cpp (revision 322481) +++ TextDiagnostic.cpp (working copy) @@ -725,7 +725,7 @@ // makes it more clear whether a message is coming from clang or cl.exe, // and it prevents MSBuild from concluding that the build failed just because // there is an "error:" in the output. - if (CLFallbackMode) + if (CLFallbackMode && Level >= DiagnosticsEngine::Error) OS << "(clang)"; OS << ": "; -- 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 35960] New: Installation ignores LLVM_INSTALL_TOOLCHAIN_ONLY
https://bugs.llvm.org/show_bug.cgi?id=35960 Bug ID: 35960 Summary: Installation ignores LLVM_INSTALL_TOOLCHAIN_ONLY Product: lld Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P Component: All Bugs Assignee: unassignedb...@nondot.org Reporter: d...@znu.io CC: llvm-bugs@lists.llvm.org The lld project ignores LLVM_INSTALL_TOOLCHAIN_ONLY when installing and therefore a bunch of archives are copied to the destination directory when they shouldn't 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 http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 35961] New: lld-link /fallback option
https://bugs.llvm.org/show_bug.cgi?id=35961 Bug ID: 35961 Summary: lld-link /fallback option Product: lld Version: unspecified Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: All Bugs Assignee: unassignedb...@nondot.org Reporter: tras...@gmail.com CC: llvm-bugs@lists.llvm.org lld-link should have a /fallback option like clang-cl to fall back to MS link.exe on 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 http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 5400 in oss-fuzz: llvm/llvm-dwarfdump-fuzzer: Heap-buffer-overflow in llvm::StringMapImpl::LookupBucketFor
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevlieg...@apple.com, igm...@gmail.com, llvm-b...@lists.llvm.org, v...@apple.com, mitchphi...@outlook.com, xpl...@gmail.com, akils...@apple.com Labels: ClusterFuzz Stability-Memory-AddressSanitizer Reproducible Engine-libfuzzer Proj-llvm Reported-2018-01-16 Type: Bug-Security New issue 5400 by ClusterFuzz-External: llvm/llvm-dwarfdump-fuzzer: Heap-buffer-overflow in llvm::StringMapImpl::LookupBucketFor https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=5400 Detailed report: https://oss-fuzz.com/testcase?key=4880755009257472 Project: llvm Fuzzer: libFuzzer_llvm_llvm-dwarfdump-fuzzer Fuzz target binary: llvm-dwarfdump-fuzzer Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: Heap-buffer-overflow READ 1 Crash Address: 0x60b0020e Crash State: llvm::StringMapImpl::LookupBucketFor std::__1::pair, bool> llvm::StringMapllvm:: llvm::object::WasmObjectFile::parseLinkingSectionComdat Sanitizer: address (ASAN) Recommended Security Severity: Medium Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201801090613:201801100627 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=4880755009257472 Issue filed automatically. See https://github.com/google/oss-fuzz/blob/master/docs/reproducing.md for more information. 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 have questions for the OSS-Fuzz team, 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 http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 34873] [X86] Execution domain fixing should be able to turn PBLENDW into BLENDPS/BLENDPD
https://bugs.llvm.org/show_bug.cgi?id=34873 Simon Pilgrim changed: What|Removed |Added Fixed By Commit(s)||322524,322526 Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Simon Pilgrim --- Fixed by rL322524 and rL322526 (fixes compile warning) -- 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 35209] Crash in ::AddressingModeMatcher::matchOperationAddr(llvm::User*, unsigned int, unsigned int, bool*)
https://bugs.llvm.org/show_bug.cgi?id=35209 Alexander Richardson changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #12 from Alexander Richardson --- I have just tested again with the latest LLVM HEAD and I can no longer reproduce this issue. It is possible that other optimizations added since then have made the issue go away. The code in question uses a lot of unions and probably should be compiled with -fno-strict-aliasing. If it happens again I will reopen this issue. -- 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 35804] [meta] 6.0.0 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=35804 Bug 35804 depends on bug 35722, which changed state. Bug 35722 Summary: [ThinLTO] asserts `!(Pair.first != Ty && Pair.second == Ty) && "mapping to a source type"` https://bugs.llvm.org/show_bug.cgi?id=35722 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 35722] [ThinLTO] asserts `!(Pair.first != Ty && Pair.second == Ty) && "mapping to a source type"`
https://bugs.llvm.org/show_bug.cgi?id=35722 Hans Wennborg changed: What|Removed |Added CC||h...@chromium.org Status|ASSIGNED|RESOLVED Fixed By Commit(s)||r322103,r322545 Resolution|--- |FIXED --- Comment #8 from Hans Wennborg --- Merged in r322545. -- 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 35962] New: [AMDGPU][MC] Incorrect encoding of VDATA for image atomics
https://bugs.llvm.org/show_bug.cgi?id=35962 Bug ID: 35962 Summary: [AMDGPU][MC] Incorrect encoding of VDATA for image atomics 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 VDATA specified in the instruction is not encoded; VADDR is encoded instead. For example (VI): image_atomic_add v6, v255, s[8:15] dmask:0x1 0x00,0x01,0x48,0xf0,0xff,0xff,0x02,0x00 // VADDR=VDATA=0xff image_atomic_add v252, v2, s[8:15] dmask:0x1 0x00,0x01,0x48,0xf0,0x02,0x02,0x02,0x00 // VADDR=VDATA=0x02 -- 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 35963] New: [AMDGPU][MC] Incorrect parsing of image modifiers
https://bugs.llvm.org/show_bug.cgi?id=35963 Bug ID: 35963 Summary: [AMDGPU][MC] Incorrect parsing of image modifiers 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 Image modifiers are parsed incorrectly which is clear from the output (VI). Disassembled code differs from the original. For example, the following instructions are assembled to the same binary code: image_atomic_add v5, v1, s[8:15] dmask:0x1 image_atomic_add v5, v1, s[8:15] unorm image_atomic_add v5, v1, s[8:15] glc image_atomic_add v5, v1, s[8:15] slc 0x00,0x01,0x48,0xf0,0x01,0x01,0x02,0x00 When disassembled, the code is: image_atomic_add v5, v1, s[8:15] dmask:0x1 -- 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 35964] New: Profile Instruction Generate/Coverage mapping: High overhead at runtime with many threads
https://bugs.llvm.org/show_bug.cgi?id=35964 Bug ID: 35964 Summary: Profile Instruction Generate/Coverage mapping: High overhead at runtime with many threads Product: new-bugs Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: dennis.fels...@sap.com CC: llvm-bugs@lists.llvm.org Created attachment 19681 --> https://bugs.llvm.org/attachment.cgi?id=19681&action=edit Source code Creating coverage information with -fprofile-instr-generate -fcoverage-mapping usually doesn't create a high overhead. When using dozens of threads the overhead seems to grow significantly in the end running 24 times as slow with 40 threads. See the following table created on a 2x Intel E5-2660v3 system: Threads No Coverage [s] Coverage [s] Factor 1 0.011 0.011 1.0 2 0.071 0.257 3.6 3 0.216 1.4196.57 4 0.377 4.735 12.56 5 0.678 8.097 11.94 10 3.25037.037 11.40 2017.223 392.021 22.76 4084.129 2087.047 24.81 -- 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 3809 in oss-fuzz: llvm/llvm-special-case-list-fuzzer: Out-of-memory in llvm_llvm-special-case-list-fuzzer
Updates: Labels: Deadline-Approaching Comment #7 on issue 3809 by sheriff...@chromium.org: llvm/llvm-special-case-list-fuzzer: Out-of-memory in llvm_llvm-special-case-list-fuzzer https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=3809#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 35965] New: TableGen doesn't constrain temporary registers
https://bugs.llvm.org/show_bug.cgi?id=35965
Bug ID: 35965
Summary: TableGen doesn't constrain temporary registers
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: GlobalISel
Assignee: unassignedb...@nondot.org
Reporter: diana.pi...@linaro.org
CC: llvm-bugs@lists.llvm.org
Created attachment 19683
--> https://bugs.llvm.org/attachment.cgi?id=19683&action=edit
Reproducer: llc -mtriple armv7-gnueabihf -global-isel
-debug-only=instruction-select [...]
When trying to select this pattern (ARMInstrVFP.td):
def : VFPNoNEONPat<(i32 (fp_to_sint SPR:$a)),
(COPY_TO_REGCLASS (VTOSIZS SPR:$a), GPR)>;
We get:
[...]
Selecting:
%1:gprb(s32) = G_FPTOSI %0(s32)
Into:
%2:_(s32) = VTOSIZS %0(s32), 14, %noreg
%1:gpr(s32) = COPY %2(s32)
[...]
LLVM ERROR: VReg has no regclass after selection (in function: test_fptosi)
Note: In order to reproduce, you'll have to mark G_FPTOSI as legal in
ARMLegalizerInfo.cpp (since I haven't committed that part yet):
setAction({G_FPTOSI, s32}, Legal);
setAction({G_FPTOSI, 1, s32}, Legal);
--
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 35966] New: Branch targets in BPF disassembler listing are incorrect
https://bugs.llvm.org/show_bug.cgi?id=35966 Bug ID: 35966 Summary: Branch targets in BPF disassembler listing are incorrect Product: tools Version: 5.0 Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: llvm-objdump Assignee: unassignedb...@nondot.org Reporter: j...@sager.me.uk CC: llvm-bugs@lists.llvm.org Created attachment 19684 --> https://bugs.llvm.org/attachment.cgi?id=19684&action=edit Code and a README to illustrate the bug On disassemling a toy BPF program the disassembly output shows incorrect targets for the jump instructions. The listing displays the value of the offset field in the instruction rather than the location of the target. There is more detail in the README.txt file in the attached zip file llvm_bug_sager_20180116.zip. -- 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 35967] New: syntax_option_type is not a proper bitmask
https://bugs.llvm.org/show_bug.cgi?id=35967 Bug ID: 35967 Summary: syntax_option_type is not a proper bitmask Product: libc++ Version: 6.0 Hardware: All OS: Linux Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: unassignedclangb...@nondot.org Reporter: miyuki-l...@miyuki.ru CC: llvm-bugs@lists.llvm.org, mclow.li...@gmail.com According to [re.synopt]: "The type syntax_option_type is an implementation-defined bitmask type" [bitmask.types] defines some requirements for such types, specifically: "Here, the names C0, C1, etc. represent bitmask elements for this particular bitmask type. All such elements have distinct, nonzero values" Contrarily to this requirement, in libc++ std::regex_constants::ECMAScript is 0. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 35750] __builtin_mul_overflow with mixed sign int operands incorrect result
https://bugs.llvm.org/show_bug.cgi?id=35750 Hans Wennborg changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #5 from Hans Wennborg --- (In reply to Vedant Kumar from comment #4) > This is fixed in r321771. > > @Hans this commit fixes a regression from 5.0. Could we merge that commit > into the release_60 branch? Sounds good. Merged in r322555. -- 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 35804] [meta] 6.0.0 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=35804 Bug 35804 depends on bug 35750, which changed state. Bug 35750 Summary: __builtin_mul_overflow with mixed sign int operands incorrect result https://bugs.llvm.org/show_bug.cgi?id=35750 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 35804] [meta] 6.0.0 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=35804 Bug 35804 depends on bug 35823, which changed state. Bug 35823 Summary: Merge r321754 into 6.0.0 branch https://bugs.llvm.org/show_bug.cgi?id=35823 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 35823] Merge r321754 into 6.0.0 branch
https://bugs.llvm.org/show_bug.cgi?id=35823 Hans Wennborg changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #5 from Hans Wennborg --- Merged in r322557. -- 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 35804] [meta] 6.0.0 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=35804 Bug 35804 depends on bug 35830, which changed state. Bug 35830 Summary: Merge r321789 into 6.0.0 branch: [GVNHoist] Fix: PR35222 gvn-hoist incorrectly erases load in case of a loop https://bugs.llvm.org/show_bug.cgi?id=35830 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 35830] Merge r321789 into 6.0.0 branch: [GVNHoist] Fix: PR35222 gvn-hoist incorrectly erases load in case of a loop
https://bugs.llvm.org/show_bug.cgi?id=35830 Hans Wennborg changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #2 from Hans Wennborg --- Merged in r322558. -- 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 35968] New: Parameters are not aligned as expected
https://bugs.llvm.org/show_bug.cgi?id=35968
Bug ID: 35968
Summary: Parameters are not aligned as expected
Product: clang
Version: 5.0
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Formatter
Assignee: unassignedclangb...@nondot.org
Reporter: tawfic_alsam...@yahoo.com
CC: djas...@google.com, kli...@google.com,
llvm-bugs@lists.llvm.org
Hello,
I have the following setting:
IndentWidth: 4
AlignAfterOpenBracket: Align
BreakBeforeBraces: Allman
AlwaysBreakBeforeMultilineStrings: false
ColumnLimit: 90
BinPackArguments: false
BinPackParameters: false
And when I run clang-format:
Got:
ret = testXUnreportedInfo(
"a", "bb", "");
Expected:
ret = testXUnreportedInfo("a",
"bb",
"");
--
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 24341] Store merging in DAGCombine if first stores are not consecutive
https://bugs.llvm.org/show_bug.cgi?id=24341 Nirav Dave changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #1 from Nirav Dave --- This was fixed in rL300561. -- 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 35848] Merge r321964 into the 6.0 branch: Correct types of pointers to doacross_num_done
https://bugs.llvm.org/show_bug.cgi?id=35848 Hans Wennborg changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #2 from Hans Wennborg --- Merged in r322560. -- 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 35804] [meta] 6.0.0 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=35804 Bug 35804 depends on bug 35848, which changed state. Bug 35848 Summary: Merge r321964 into the 6.0 branch: Correct types of pointers to doacross_num_done https://bugs.llvm.org/show_bug.cgi?id=35848 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 35969] New: clang crashes at -O1 and above: : Assertion `SuccTN && "Unreachable successor found at reachable insertion"' failed.
https://bugs.llvm.org/show_bug.cgi?id=35969 Bug ID: 35969 Summary: clang crashes at -O1 and above: : Assertion `SuccTN && "Unreachable successor found at reachable insertion"' failed. Product: clang Version: trunk Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: LLVM Codegen Assignee: unassignedclangb...@nondot.org Reporter: helloqi...@gmail.com CC: llvm-bugs@lists.llvm.org As the title. $ clang-trunk -v clang version 7.0.0 (trunk 322539) Target: x86_64-unknown-linux-gnu Thread model: posix InstalledDir: /usr/local/bin $ clang-trunk -O1 abc.c abc.c:34:3: warning: expression result unused [-Wunused-value] i; ^ clang-7.0: /home/absozero/trunk/llvm/include/llvm/Support/GenericDomTreeConstruction.h:786: static void llvm::DomTreeBuilder::SemiNCAInfo::VisitInsertion(DomTreeT&, llvm::DomTreeBuilder::SemiNCAInfo::BatchUpdatePtr, llvm::DomTreeBuilder::SemiNCAInfo::TreeNodePtr, unsigned int, llvm::DomTreeBuilder::SemiNCAInfo::TreeNodePtr, llvm::DomTreeBuilder::SemiNCAInfo::InsertionInfo&) [with DomTreeT = llvm::DominatorTreeBase; llvm::DomTreeBuilder::SemiNCAInfo::BatchUpdatePtr = llvm::DomTreeBuilder::SemiNCAInfo >::BatchUpdateInfo*; llvm::DomTreeBuilder::SemiNCAInfo::TreeNodePtr = llvm::DomTreeNodeBase*; typename DomTreeT::NodeType = llvm::BasicBlock]: Assertion `SuccTN && "Unreachable successor found at reachable insertion"' failed. #0 0x021829ea llvm::sys::PrintStackTrace(llvm::raw_ostream&) (/home/absozero/trunk/root-clang/bin/clang-7.0+0x21829ea) #1 0x0218088e llvm::sys::RunSignalHandlers() (/home/absozero/trunk/root-clang/bin/clang-7.0+0x218088e) #2 0x021809e2 SignalHandler(int) (/home/absozero/trunk/root-clang/bin/clang-7.0+0x21809e2) #3 0x7fd89aaed330 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x10330) #4 0x7fd89966ac37 gsignal /build/eglibc-oGUzwX/eglibc-2.19/signal/../nptl/sysdeps/unix/sysv/linux/raise.c:56:0 #5 0x7fd89966e028 abort /build/eglibc-oGUzwX/eglibc-2.19/stdlib/abort.c:91:0 #6 0x7fd899663bf6 __assert_fail_base /build/eglibc-oGUzwX/eglibc-2.19/assert/assert.c:92:0 #7 0x7fd899663ca2 (/lib/x86_64-linux-gnu/libc.so.6+0x2fca2) #8 0x01c4d9dc llvm::DomTreeBuilder::SemiNCAInfo >::VisitInsertion(llvm::DominatorTreeBase&, llvm::DomTreeBuilder::SemiNCAInfo >::BatchUpdateInfo*, llvm::DomTreeNodeBase*, unsigned int, llvm::DomTreeNodeBase*, llvm::DomTreeBuilder::SemiNCAInfo >::InsertionInfo&) (/home/absozero/trunk/root-clang/bin/clang-7.0+0x1c4d9dc) #9 0x01c4db6f llvm::DomTreeBuilder::SemiNCAInfo >::InsertReachable(llvm::DominatorTreeBase&, llvm::DomTreeBuilder::SemiNCAInfo >::BatchUpdateInfo*, llvm::DomTreeNodeBase*, llvm::DomTreeNodeBase*) (/home/absozero/trunk/root-clang/bin/clang-7.0+0x1c4db6f) #10 0x01c4e1f0 llvm::DomTreeBuilder::SemiNCAInfo >::InsertEdge(llvm::DominatorTreeBase&, llvm::DomTreeBuilder::SemiNCAInfo >::BatchUpdateInfo*, llvm::BasicBlock*, llvm::BasicBlock*) (/home/absozero/trunk/root-clang/bin/clang-7.0+0x1c4e1f0) #11 0x01c4e404 llvm::DomTreeBuilder::SemiNCAInfo >::ApplyNextUpdate(llvm::DominatorTreeBase&, llvm::DomTreeBuilder::SemiNCAInfo >::BatchUpdateInfo&) (/home/absozero/trunk/root-clang/bin/clang-7.0+0x1c4e404) #12 0x01c525aa llvm::DomTreeBuilder::SemiNCAInfo >::ApplyUpdates(llvm::DominatorTreeBase&, llvm::ArrayRef >) (/home/absozero/trunk/root-clang/bin/clang-7.0+0x1c525aa) #13 0x01c52770 llvm::DeferredDominance::flush() (/home/absozero/trunk/root-clang/bin/clang-7.0+0x1c52770) #14 0x01fb5720 llvm::JumpThreadingPass::runImpl(llvm::Function&, llvm::TargetLibraryInfo*, llvm::LazyValueInfo*, llvm::AAResults*, llvm::DeferredDominance*, bool, std::unique_ptr >, std::unique_ptr >) (/home/absozero/trunk/root-clang/bin/clang-7.0+0x1fb5720) #15 0x01fb6550 (anonymous namespace)::JumpThreading::runOnFunction(llvm::Function&) [clone .part.626] [clone .constprop.643] (/home/absozero/trunk/root-clang/bin/clang-7.0+0x1fb6550) #16 0x01c97253 llvm::FPPassManager::runOnFunction(llvm::Function&) (/home/absozero/trunk/root-clang/bin/clang-7.0+0x1c97253) #17 0x0171149e (anonymous namespace)::CGPassManager::runOnModule(llvm::Module&) (/home/absozero/trunk/root-clang/bin/clang-7.0+0x171149e) #18 0x01c96ded llvm::legacy::PassManagerImpl::run(llvm::Module&) (/home/absozero/trunk/root-clang/bin/clang-7.0+0x1c96ded) #19 0x02340fce clang::EmitBackendOutput(clang::DiagnosticsEngine&, clang::HeaderSearchOptions const&, clang::CodeGenOptions const&, clang::TargetOptions const&, clang::LangOptions const&, llvm::DataLayout const&, llvm::Module*, clang::BackendAction, std::unique_ptr >) (/home/absozero/trunk/root-clang/bin/clang-7.0+0x2340fce) #20 0x02b8ea97 clang::BackendConsumer::HandleTranslationUnit(clang::ASTContext&) (/home/absozero
[llvm-bugs] [Bug 31912] [X86] Need to add CLWB intrinsic to match gcc/icc
https://bugs.llvm.org/show_bug.cgi?id=31912 Craig Topper changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Craig Topper --- Yes it was. Guess I forgot I had filed a 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 35970] New: Implement addrspace machine memory operand printing / parsing in MIR
https://bugs.llvm.org/show_bug.cgi?id=35970 Bug ID: 35970 Summary: Implement addrspace machine memory operand printing / parsing in MIR Product: libraries Version: trunk Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: Common Code Generator Code Assignee: unassignedb...@nondot.org Reporter: franci...@yahoo.com CC: llvm-bugs@lists.llvm.org Created attachment 19686 --> https://bugs.llvm.org/attachment.cgi?id=19686&action=edit Copy of the test. -debug printing prints the address space of a MachinePointerInfo if it is != 0: %15:vgpr_32 = BUFFER_LOAD_SSHORT_OFFEN %18, %sgpr96_sgpr97_sgpr98_sgpr99, %sgpr3, 0, 0, 0, 0, implicit %exec; mem:LD2[(addrspace=5)] When printing MIR and parsing it again we lose the information of the address space if there is no IR value attached to the MachinePointerInfo. Example: test/CodeGen/AMDGPU/extload-align.ll We print: %15:vgpr_32 = BUFFER_LOAD_SSHORT_OFFEN %18, %sgpr96_sgpr97_sgpr98_sgpr99, %sgpr3, 0, 0, 0, 0, implicit %exec :: (load 2) Note the ":: (load 2)" which is missing the addrspace 5. When we parse it back, the addrspace is assumed to be 0. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 35971] New: Compilation error when casting an explicit template argument which is a member-function
https://bugs.llvm.org/show_bug.cgi?id=35971 Bug ID: 35971 Summary: Compilation error when casting an explicit template argument which is a member-function Product: clang Version: 3.8 Hardware: All OS: All Status: NEW Severity: normal Priority: P Component: C++ Assignee: unassignedclangb...@nondot.org Reporter: bstanimir...@gmail.com CC: dgre...@apple.com, llvm-bugs@lists.llvm.org Casting an explicit template argument which is a member-function leads to error on all versions of clang. Live demo here: https://godbolt.org/g/9Xynvm Curiously this compiles with clang 5.0 and newer and -std=c++17 (but not with c++14 or 11) This makes it impossible to pass a pointer to a member function of a parent class from the point of view of a child class. Live demo here https://godbolt.org/g/uenNSm (This doesn't even work with -std=c++17) Both examples compile fine on gcc and msvc -- 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 5426 in oss-fuzz: llvm/llvm-isel-fuzzer--aarch64-gisel: ASSERT: N->getOpcode() != ISD::DELETED_NODE && "DELETED_NODE in CSEMap!"
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevlieg...@apple.com, igm...@gmail.com, llvm-b...@lists.llvm.org, v...@apple.com, mitchphi...@outlook.com, xpl...@gmail.com, akils...@apple.com Labels: ClusterFuzz Stability-Memory-AddressSanitizer Reproducible Engine-libfuzzer Proj-llvm Reported-2018-01-16 Type: Bug New issue 5426 by ClusterFuzz-External: llvm/llvm-isel-fuzzer--aarch64-gisel: ASSERT: N->getOpcode() != ISD::DELETED_NODE && "DELETED_NODE in CSEMap!" https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=5426 Detailed report: https://oss-fuzz.com/testcase?key=6674322379767808 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: N->getOpcode() != ISD::DELETED_NODE && "DELETED_NODE in CSEMap!" llvm::SelectionDAG::RemoveNodeFromCSEMaps llvm::SelectionDAG::ReplaceAllUsesOfValuesWith Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201801020611:201801030610 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=6674322379767808 Issue filed automatically. See https://github.com/google/oss-fuzz/blob/master/docs/reproducing.md for more information. 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 have questions for the OSS-Fuzz team, 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 http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 35972] New: [X86] "Unexpected illegal type!" in LegalizeDAG.cpp
https://bugs.llvm.org/show_bug.cgi?id=35972
Bug ID: 35972
Summary: [X86] "Unexpected illegal type!" in LegalizeDAG.cpp
Product: new-bugs
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: ilia.tara...@intel.com
CC: llvm-bugs@lists.llvm.org
This test fails at compilation with "Unexpected illegal type!" in
LegalizeDAG.cpp:
= nice.c ==
void foo (int p, int n)
{
int i;
char * a = 0;
for (i = n; i < 0; i++)
{
if (! p)
a[i] = a[0];
}
}
===
>>> clang -v
clang version 6.0.0 (trunk 322555)
Target: x86_64-unknown-linux-gnu
Thread model: posix
...
>>> clang -m32 -c -O2 -march=skx nice.c
clang-7.0: .../llvm/lib/CodeGen/SelectionDAG/LegalizeDAG.cpp:1002: void
{anonymous}::SelectionDAGLegalize::LegalizeOp(llvm::SDNode*): Assertion
`(TLI.getTypeAction(*DAG.getContext(), Op.getValueType()) ==
TargetLowering::TypeLegal || TLI.isTypeLegal(Op.getValueType()) ||
Op.getOpcode() == ISD::TargetConstant || Op.getOpcode() == ISD::Register) &&
"Unexpected illegal type!"' failed.
#0 0x041b222d llvm::sys::PrintStackTrace(llvm::raw_ostream&)
.../llvm/lib/Support/Unix/Signals.inc:398:0
#1 0x041b22be PrintStackTraceSignalHandler(void*)
.../llvm/lib/Support/Unix/Signals.inc:462:0
#2 0x041b07a4 llvm::sys::RunSignalHandlers()
.../llvm/lib/Support/Signals.cpp:49:0
#3 0x041b1bc5 SignalHandler(int)
.../llvm/lib/Support/Unix/Signals.inc:252:0
#4 0x7f59024775e0 __restore_rt (/lib64/libpthread.so.0+0xf5e0)
#5 0x7f590106f1f7 __GI_raise (/lib64/libc.so.6+0x351f7)
#6 0x7f59010708e8 __GI_abort (/lib64/libc.so.6+0x368e8)
#7 0x7f5901068266 __assert_fail_base (/lib64/libc.so.6+0x2e266)
#8 0x7f5901068312 (/lib64/libc.so.6+0x2e312)
#9 0x04df218e (anonymous
namespace)::SelectionDAGLegalize::LegalizeOp(llvm::SDNode*)
.../llvm/lib/CodeGen/SelectionDAG/LegalizeDAG.cpp:996:0
#10 0x04e12942 llvm::SelectionDAG::Legalize()
.../llvm/lib/CodeGen/SelectionDAG/LegalizeDAG.cpp:4726:0
#11 0x04ec4552 llvm::SelectionDAGISel::CodeGenAndEmitDAG()
.../llvm/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp:834:0
#12 0x04ec307e
llvm::SelectionDAGISel::SelectBasicBlock(llvm::ilist_iterator, false, true>,
llvm::ilist_iterator, false, true>, bool&)
.../llvm/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp:665:0
#13 0x04ec89a0
llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&)
.../llvm/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp:1627:0
#14 0x04ec1d5f
llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&)
.../llvm/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp:467:0
#15 0x02f91748 (anonymous
namespace)::X86DAGToDAGISel::runOnMachineFunction(llvm::MachineFunction&)
.../llvm/lib/Target/X86/X86ISelDAGToDAG.cpp:176:0
#16 0x0363b55f
llvm::MachineFunctionPass::runOnFunction(llvm::Function&)
.../llvm/lib/CodeGen/MachineFunctionPass.cpp:62:0
#17 0x03a88a42 llvm::FPPassManager::runOnFunction(llvm::Function&)
.../llvm/lib/IR/LegacyPassManager.cpp:1520:0
#18 0x03a88bd5 llvm::FPPassManager::runOnModule(llvm::Module&)
.../llvm/lib/IR/LegacyPassManager.cpp:1541:0
#19 0x03a88f61 (anonymous
namespace)::MPPassManager::runOnModule(llvm::Module&)
.../llvm/lib/IR/LegacyPassManager.cpp:1597:0
#20 0x03a89652 llvm::legacy::PassManagerImpl::run(llvm::Module&)
.../llvm/lib/IR/LegacyPassManager.cpp:1700:0
#21 0x03a89893 llvm::legacy::PassManager::run(llvm::Module&)
.../llvm/lib/IR/LegacyPassManager.cpp:1732:0
#22 0x04456281 (anonymous
namespace)::EmitAssemblyHelper::EmitAssembly(clang::BackendAction,
std::unique_ptr >)
.../llvm/tools/clang/lib/CodeGen/BackendUtil.cpp:822:0
#23 0x04458a7a clang::EmitBackendOutput(clang::DiagnosticsEngine&,
clang::HeaderSearchOptions const&, clang::CodeGenOptions const&,
clang::TargetOptions const&, clang::LangOptions const&, llvm::DataLayout
const&, llvm::Module*, clang::BackendAction,
std::unique_ptr >)
.../llvm/tools/clang/lib/CodeGen/BackendUtil.cpp:1191:0
#24 0x04fa3af1
clang::BackendConsumer::HandleTranslationUnit(clang::ASTContext&)
.../llvm/tools/clang/lib/CodeGen/CodeGenAction.cpp:294:0
#25 0x05c70f9a clang::ParseAST(clang::Sema&, bool, bool)
.../llvm/tools/clang/lib/Parse/ParseAST.cpp:161:0
#26 0x04ab5024 clang::ASTFrontendAction::ExecuteAction()
.../llvm/tools/clang/lib/Frontend/FrontendAction.cpp:1007:0
#27 0x04fa1bc2 clang::CodeGenAction::ExecuteAction()
.../llvm/tools/clang/lib/CodeGen/CodeGenAction.cpp:1032:0
#28 0x04ab4a65 clang::FrontendAction::Execute()
.../llvm/tools/clang/lib/Frontend/FrontendAction.cpp:908:0
#29 0x04a54a84
clang::CompilerInstance::ExecuteActio
[llvm-bugs] [Bug 35974] New: Segmentation fault when emitting diagnostic
https://bugs.llvm.org/show_bug.cgi?id=35974 Bug ID: 35974 Summary: Segmentation fault when emitting diagnostic Product: clang Version: 5.0 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: -New Bugs Assignee: unassignedclangb...@nondot.org Reporter: gamefreak1...@gmail.com CC: llvm-bugs@lists.llvm.org Created attachment 19687 --> https://bugs.llvm.org/attachment.cgi?id=19687&action=edit The required Clang output I have attached Clang's output (including the backtrace) and the two files it told me to include. I do not get a crash when I run the reproduction script, but Clang said "PLEASE submit a bug report". -- 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 35931] hwasan does not link with lld due to pc-relative relocations to .text
https://bugs.llvm.org/show_bug.cgi?id=35931 Evgenii Stepanov changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #4 from Evgenii Stepanov --- r322588 -- 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 35971] Compilation error when casting an explicit template argument which is a member-function
https://bugs.llvm.org/show_bug.cgi?id=35971 Richard Smith changed: What|Removed |Added Resolution|--- |INVALID CC||richard-l...@metafoo.co.uk Status|NEW |RESOLVED --- Comment #1 from Richard Smith --- (In reply to Borislav Stanimirov from comment #0) > Both examples compile fine on gcc and msvc That is a bug in those compilers. The C++11 and C++14 rules are quite clear about the permitted syntactic forms of non-type template arguments. [temp.arg.nontype]/1.3 says the argument shall be: "[...] a pointer to member expressed as described in [expr.unary.op]" GCC does correctly implement the rule for the non-pointer-to-member case: https://godbolt.org/g/jb6gwU ... strongly suggesting that this is just an oversight on their part. (MSVC has apparently never followed the rules here.) The rule in question was changed in C++17 to allow arbitrary constant expressions of the right type as non-type template arguments: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4198.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 http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 35921] Attribute Target MultiVersioning differences with gcc
https://bugs.llvm.org/show_bug.cgi?id=35921 Erich Keane changed: What|Removed |Added Status|NEW |RESOLVED Fixed By Commit(s)||322592 Resolution|--- |FIXED --- Comment #3 from Erich Keane --- I did the COMDAT fix. No idea about the fvisibility=hidden, but I'd rather match GCC for that until they decide it is a bug themselves (or someone with a strong opinion here can give me a good answer on it). -- 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 35975] New: Line-number/machine-code offsets break "set next statement" on Windows
https://bugs.llvm.org/show_bug.cgi?id=35975 Bug ID: 35975 Summary: Line-number/machine-code offsets break "set next statement" on Windows Product: clang Version: unspecified Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: LLVM Codegen Assignee: unassignedclangb...@nondot.org Reporter: brucedaw...@chromium.org CC: llvm-bugs@lists.llvm.org A Chromium developer reported that aggressive use of the VC++ debugger command Set Next Statement worked very reliably with VC++ compiled binaries but frequently causes crashes with clang-cl compiled binaries. The tracking Chromium bug is crbug.com/793819. Specifically, the debug information is generated such that invoking Set Next Statement for a particular line of C++ code causes the assembly language instruction pointer to be set to the *third* instruction used to implement that line of code, instead of the *first* instruction. That means that two instructions of setup are skipped, which leads to unpredictable results. As a simple repro, run debug browser_tests.exe --single_process --gtest_filter=CaptivePortalBrowserTest.Login and then in this code: "SetUpCaptivePortalService(browser()->profile(), GURL(kMockCaptivePortalTestUrl));" add a breakpoint. When it gets hit, you can move the statement somewhere else (like repeat the EXPECT_EQ call) and then move it again to the SetUpCaptivePortalService call. It'll crash in the std::string constructor. The relevant source code is here: // Double-check that the captive portal service isn't enabled by default for // browser tests. EXPECT_EQ(CaptivePortalService::DISABLED_FOR_TESTING, CaptivePortalService::get_state_for_testing()); CaptivePortalService::set_state_for_testing( CaptivePortalService::SKIP_OS_CHECK_FOR_TESTING); EnableCaptivePortalDetection(browser()->profile(), true); // Set the captive portal service to use URLRequestMockCaptivePortalJob's // mock URL, by default. SetUpCaptivePortalService(browser()->profile(), GURL(kMockCaptivePortalTestUrl)); The machine code around the SetUpCaptivePortalService call is here: 0285668C E8 3F 02 00 00 call CaptivePortalBrowserTest::EnableCaptivePortalDetection (028568D0h) 02856691 8D 4E 5C lea ecx,[esi+5Ch] 02856694 8D 05 5B FC 5C 00lea eax,[string "http://mock.captive.portal.test/";... (05CFC5Bh)] 0285669A 83 EC 04 sub esp,4 0285669D 89 04 24 mov dword ptr [esp],eax 028566A0 E8 7B 72 61 FE call base::BasicStringPiece<...>::BasicStringPiece (0E6D920h) 028566A5 8D 8E 94 00 00 00lea ecx,[esi+94h] 028566AB 8B 56 5C mov edx,dword ptr [esi+5Ch] 028566AE 8B 7E 60 mov edi,dword ptr [esi+60h] 028566B1 83 EC 08 sub esp,8 028566B4 89 14 24 mov dword ptr [esp],edx 028566B7 89 7C 24 04 mov dword ptr [esp+4],edi 028566BB 89 46 10 mov dword ptr [esi+10h],eax 028566BE FF 15 A8 28 DF 0Acalldword ptr [__imp_GURL::GURL (0ADF28A8h)] 028566C4 8B 4E 40 mov ecx,dword ptr [esi+40h] 028566C7 89 46 0C mov dword ptr [esi+0Ch],eax 028566CA E8 91 73 61 FE callInProcessBrowserTest::browser (0E6DA60h) 028566CF 89 C1mov ecx,eax 028566D1 E8 AA 73 61 FE callBrowser::profile (0E6DA80h) 028566D6 8D 8E 94 00 00 00lea ecx,[esi+94h] 028566DC 83 EC 08 sub esp,8 028566DF 8B 56 40 mov edx,dword ptr [esi+40h] 028566E2 89 4E 08 mov dword ptr [esi+8],ecx 028566E5 89 D1mov ecx,edx 028566E7 89 04 24 mov dword ptr [esp],eax 028566EA 8B 46 08 mov eax,dword ptr [esi+8] 028566ED 89 44 24 04 mov dword ptr [esp+4],eax 028566F1 E8 6A 02 00 00 call CaptivePortalBrowserTest::SetUpCaptivePortalService (02856960h) Crucially, if you set a breakpoint on the call to SetUpCaptivePortalService or if you Set Next Statement to that line of code then you get dropped onto 0285669A. That means that the stack gets adjusted properly (which is good) but it means that ECX and EAX are not set up. Those are set up starting on 02856691 and if you Set Next Statement from EXPECT_EQ to SetUpCaptivePortalService then they have the wrong values. They are supposed to be: EAX = 005CFC5B ECX = 0019D89C but they are actually: EAX = ECX = 0019D8B4 EAX and ECX are supposed to hold the address of the string used for the constructor's input and the address of the object. These seem like important things. The b
[llvm-bugs] [Bug 35976] New: Merge r321459 and commit for D42102 into the 6.0 branch
https://bugs.llvm.org/show_bug.cgi?id=35976 Bug ID: 35976 Summary: Merge r321459 and commit for D42102 into the 6.0 branch Product: new-bugs Version: 6.0 Hardware: PC OS: All Status: NEW Severity: release blocker Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: dimi...@andric.com CC: llvm-bugs@lists.llvm.org Please merge the following asmparser related fixes into the 6.0 branch: * https://reviews.llvm.org/rL321459 (fixes bug 35741) * https://reviews.llvm.org/D42102 (fixes bug 35749 and bug 35831), not yet committed but I will update this bug then. -- 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 35741] After r315899, comments after x86 prefixes cause errors
https://bugs.llvm.org/show_bug.cgi?id=35741 Dimitry Andric changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED Blocks|35804 | 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] [Bug 10988] x86 MC encoder and disassembler bugs umbrella
https://bugs.llvm.org/show_bug.cgi?id=10988 Bug 10988 depends on bug 35741, which changed state. Bug 35741 Summary: After r315899, comments after x86 prefixes cause errors https://bugs.llvm.org/show_bug.cgi?id=35741 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 35913] Revert r315899 in the 6.0 branch
https://bugs.llvm.org/show_bug.cgi?id=35913 Dimitry Andric changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |MOVED --- Comment #8 from Dimitry Andric --- Closing this in favor of bug 35976. -- 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 35804] [meta] 6.0.0 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=35804 Bug 35804 depends on bug 35913, which changed state. Bug 35913 Summary: Revert r315899 in the 6.0 branch https://bugs.llvm.org/show_bug.cgi?id=35913 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |MOVED -- 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 35977] New: Vector shift misoptimized with AVX512
https://bugs.llvm.org/show_bug.cgi?id=35977 Bug ID: 35977 Summary: Vector shift misoptimized with AVX512 Product: libraries Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: Backend: X86 Assignee: unassignedb...@nondot.org Reporter: benny@gmail.com CC: llvm-bugs@lists.llvm.org, llvm-...@redking.me.uk Created attachment 19688 --> https://bugs.llvm.org/attachment.cgi?id=19688&action=edit IR test case The attached testcase (reduced from llvmpipe) is erroneously optimized away when AVX512 is enabled. $ llc -mcpu=skylake < t.ll test: # @test .cfi_startproc # %bb.0:# %entry vmovq (%rdi), %xmm0 # xmm0 = mem[0],zero vpxor %xmm1, %xmm1, %xmm1 vpunpcklbw %xmm0, %xmm1, %xmm0 # xmm0 = xmm1[0],xmm0[0],xmm1[1],xmm0[1],xmm1[2],xmm0[2],xmm1[3],xmm0[3],xmm1[4],xmm0[4],xmm1[5],xmm0[5],xmm1[6],xmm0[6],xmm1[7],xmm0[7] vmovdqa %xmm0, (%rsi) retq $ llc -mcpu=skylake-avx512 < t.ll test: # @test vxorps %xmm0, %xmm0, %xmm0 vmovaps %xmm0, (%rsi) retq This seems to have started with r321085, but seems like an unrelated latent bug in shuffle lowering. -- 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 35978] New: llvm::Optional not trivially copyable if T is trivially copyable
https://bugs.llvm.org/show_bug.cgi?id=35978 Bug ID: 35978 Summary: llvm::Optional not trivially copyable if T is trivially copyable Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: Support Libraries Assignee: unassignedb...@nondot.org Reporter: chisophu...@gmail.com CC: llvm-bugs@lists.llvm.org This causes clang-tidy's performance-unnecessary-value-param to fire on it (which presumably indicates a performance problem). -- 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 35979] New: [X86] FXSAVE, XSAVE/XRSTOR missing from Sandybridge scheduler model
https://bugs.llvm.org/show_bug.cgi?id=35979 Bug ID: 35979 Summary: [X86] FXSAVE, XSAVE/XRSTOR missing from Sandybridge scheduler model 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 FXRSTOR is present, but wrong. See PR35956 -- 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 5441 in oss-fuzz: llvm/clang-fuzzer: Heap-buffer-overflow in extractSubobject
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevlieg...@apple.com, igm...@gmail.com, llvm-b...@lists.llvm.org, v...@apple.com, mitchphi...@outlook.com, xpl...@gmail.com, akils...@apple.com Labels: ClusterFuzz Stability-Memory-AddressSanitizer Reproducible Engine-libfuzzer Proj-llvm Reported-2018-01-17 Type: Bug-Security New issue 5441 by ClusterFuzz-External: llvm/clang-fuzzer: Heap-buffer-overflow in extractSubobject https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=5441 Detailed report: https://oss-fuzz.com/testcase?key=4897207787454464 Project: llvm Fuzzer: libFuzzer_llvm_clang-fuzzer Fuzz target binary: clang-fuzzer Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: Heap-buffer-overflow READ 4 Crash Address: 0x607043d0 Crash State: extractSubobject handleLValueToRValueConversion IntExprEvaluator::VisitCastExpr Sanitizer: address (ASAN) Recommended Security Severity: Medium Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201712090607:201712100011 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=4897207787454464 Issue filed automatically. See https://github.com/google/oss-fuzz/blob/master/docs/reproducing.md for more information. 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 have questions for the OSS-Fuzz team, 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 http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 35980] New: Compiler aborts in O1 in ffmpeg build
https://bugs.llvm.org/show_bug.cgi?id=35980
Bug ID: 35980
Summary: Compiler aborts in O1 in ffmpeg build
Product: clang
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: LLVM Codegen
Assignee: unassignedclangb...@nondot.org
Reporter: santosh.zanju...@amd.com
CC: llvm-bugs@lists.llvm.org
The issue is seen with flag O1 and above. I shall try to find svn revision
that caused the problem and also come up with a reproducible test.
amd@gukvm36p20:~/santosh/tmp/ffmpeg-3.3.3$ export FLAGS="-m64 -O1 -fuse-ld=lld
-std=c11 "; /home/amd/santosh/llvm/trunk/install/bin//clang $FLAGS -I. -I./
-D_ISOC99_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE
-D_POSIX_C_SOURCE=200112 -D_XOPEN_SOURCE=600 -DHAVE_AV_CONFIG_H -c -o
libavcodec/a64multienc.o libavcodec/a64multienc.c
clang-7.0: warning: argument unused during compilation: '-fuse-ld=lld'
[-Wunused-command-line-argument]
clang-7.0:
/home/amd/santosh/llvm/trunk/llvm/lib/CodeGen/CodeGenPrepare.cpp:1945: void
{anonymous}::ExtAddrMode::SetCombinedField({anonymous}::ExtAddrMode::FieldName,
llvm::Value*, const llvm::SmallVectorImpl<{anonymous}::ExtAddrMode>&):
Assertion `BaseReg == nullptr' failed.
#0 0x2afe8d25a93a llvm::sys::PrintStackTrace(llvm::raw_ostream&)
(/home/amd/santosh/llvm/trunk/install/bin/../lib/libLLVM-7.0svn.so+0x69d93a)
#1 0x2afe8d2586fe llvm::sys::RunSignalHandlers()
(/home/amd/santosh/llvm/trunk/install/bin/../lib/libLLVM-7.0svn.so+0x69b6fe)
#2 0x2afe8d258864 SignalHandler(int)
(/home/amd/santosh/llvm/trunk/install/bin/../lib/libLLVM-7.0svn.so+0x69b864)
#3 0x2afe904e47f0 (/lib/x86_64-linux-gnu/libc.so.6+0x357f0)
#4 0x2afe904e477f gsignal
/build/glibc-mXZSwJ/glibc-2.24/signal/../sysdeps/unix/sysv/linux/raise.c:58:0
#5 0x2afe904e637a abort /build/glibc-mXZSwJ/glibc-2.24/stdlib/abort.c:91:0
#6 0x2afe904dcb47 __assert_fail_base
/build/glibc-mXZSwJ/glibc-2.24/assert/assert.c:92:0
#7 0x2afe904dcbf2 (/lib/x86_64-linux-gnu/libc.so.6+0x2dbf2)
#8 0x2afe8d42eeaa (anonymous
namespace)::CodeGenPrepare::optimizeMemoryInst(llvm::Instruction*,
llvm::Value*, llvm::Type*, unsigned int)
(/home/amd/santosh/llvm/trunk/install/bin/../lib/libLLVM-7.0svn.so+0x871eaa)
#9 0x2afe8d42fa91 (anonymous
namespace)::CodeGenPrepare::optimizeInst(llvm::Instruction*, bool&)
(/home/amd/santosh/llvm/trunk/install/bin/../lib/libLLVM-7.0svn.so+0x872a91)
#10 0x2afe8d43211e (anonymous
namespace)::CodeGenPrepare::runOnFunction(llvm::Function&) [clone .part.1154]
(/home/amd/santosh/llvm/trunk/install/bin/../lib/libLLVM-7.0svn.so+0x87511e)
#11 0x2afe8d3620c3 llvm::FPPassManager::runOnFunction(llvm::Function&)
(/home/amd/santosh/llvm/trunk/install/bin/../lib/libLLVM-7.0svn.so+0x7a50c3)
#12 0x2afe8d362194 llvm::FPPassManager::runOnModule(llvm::Module&)
(/home/amd/santosh/llvm/trunk/install/bin/../lib/libLLVM-7.0svn.so+0x7a5194)
#13 0x2afe8d362e11 llvm::legacy::PassManagerImpl::run(llvm::Module&)
(/home/amd/santosh/llvm/trunk/install/bin/../lib/libLLVM-7.0svn.so+0x7a5e11)
#14 0x55dcd78f8c1e clang::EmitBackendOutput(clang::DiagnosticsEngine&,
clang::HeaderSearchOptions const&, clang::CodeGenOptions const&,
clang::TargetOptions const&, clang::LangOptions const&, llvm::DataLayout
const&, llvm::Module*, clang::BackendAction,
std::unique_ptr >)
(/home/amd/santosh/llvm/trunk/install/bin/clang-7.0+0x5abc1e)
#15 0x55dcd7d9dec9
clang::BackendConsumer::HandleTranslationUnit(clang::ASTContext&)
(/home/amd/santosh/llvm/trunk/install/bin/clang-7.0+0xa50ec9)
#16 0x55dcd7f49f08 clang::ParseAST(clang::Sema&, bool, bool)
(/home/amd/santosh/llvm/trunk/install/bin/clang-7.0+0xbfcf08)
#17 0x55dcd7d9d0ef clang::CodeGenAction::ExecuteAction()
(/home/amd/santosh/llvm/trunk/install/bin/clang-7.0+0xa500ef)
#18 0x55dcd7cf89c6 clang::FrontendAction::Execute()
(/home/amd/santosh/llvm/trunk/install/bin/clang-7.0+0x9ab9c6)
#19 0x55dcd7cc38d6
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&)
(/home/amd/santosh/llvm/trunk/install/bin/clang-7.0+0x9768d6)
#20 0x55dcd7d943f2
clang::ExecuteCompilerInvocation(clang::CompilerInstance*)
(/home/amd/santosh/llvm/trunk/install/bin/clang-7.0+0xa473f2)
#21 0x55dcd78a01c8 cc1_main(llvm::ArrayRef, char const*,
void*) (/home/amd/santosh/llvm/trunk/install/bin/clang-7.0+0x5531c8)
#22 0x55dcd789a75c main
(/home/amd/santosh/llvm/trunk/install/bin/clang-7.0+0x54d75c)
#23 0x2afe904cf3f1 __libc_start_main
/build/glibc-mXZSwJ/glibc-2.24/csu/../csu/libc-start.c:325:0
#24 0x55dcd789c29a _start
(/home/amd/santosh/llvm/trunk/install/bin/clang-7.0+0x54f29a)
Stack dump:
0. Program arguments: /home/amd/santosh/llvm/trunk/install/bin/clang-7.0
-cc1 -triple x86_64-unknown-linux-gnu -emit-obj -disable-free -main-file-name
a64multienc.c -mrelocation-model static -mthread-model posix -fmath-errno
-m
[llvm-bugs] [Bug 35981] New: Merge r322350 and related commits into 6.0 branch
https://bugs.llvm.org/show_bug.cgi?id=35981 Bug ID: 35981 Summary: Merge r322350 and related commits into 6.0 branch Product: clang Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: -New Bugs Assignee: h...@chromium.org Reporter: rtr...@google.com CC: llvm-bugs@lists.llvm.org Blocks: 35804 r322350 fixes a bug after r321395 & r321396 and reported in the buildbots. That change disables hashing in the affected case. After that, a few small changes to get the test case fixed up. The complete list of changes requested to be merged: Actual code change: r322350 Fixing up test case: r322405 r322420 r322593 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
