[llvm-bugs] [Bug 30227] RelativeRel is used, but not initialized for AMDGPU
https://llvm.org/bugs/show_bug.cgi?id=30227 George Rimar changed: What|Removed |Added Status|NEW |RESOLVED CC||gri...@accesssoftek.com Resolution|--- |FIXED --- Comment #1 from George Rimar --- r280291 -- 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 30231] New: __builtin_dwarf_cfa suspect on ARM
https://llvm.org/bugs/show_bug.cgi?id=30231 Bug ID: 30231 Summary: __builtin_dwarf_cfa suspect on ARM Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Backend: ARM Assignee: unassignedb...@nondot.org Reporter: hfin...@anl.gov CC: llvm-bugs@lists.llvm.org Classification: Unclassified Please see: https://llvm.org/bugs/show_bug.cgi?id=26761#c3 and: https://llvm.org/bugs/show_bug.cgi?id=26761#c4 But, in short, it looks like ARM probably needs to lower __builtin_dwarf_cfa like Mips and PowerPC do (by lowering ISD::EH_DWARF_CFA directly), and not using the default x86-inspired method. See r280350. -- 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 25780] [META] Using Clang as the FreeBSD/ppc system compiler
https://llvm.org/bugs/show_bug.cgi?id=25780 Bug 25780 depends on bug 26761, which changed state. Bug 26761 Summary: clang 3.8.0 messes up __builtin_dwarf_cfa (), at least for TARGET_ARCH=powerpc and powerpc64 (gcc/g++ mismatch) https://llvm.org/bugs/show_bug.cgi?id=26761 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 26761] clang 3.8.0 messes up __builtin_dwarf_cfa (), at least for TARGET_ARCH=powerpc and powerpc64 (gcc/g++ mismatch)
https://llvm.org/bugs/show_bug.cgi?id=26761 Hal Finkel changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #10 from Hal Finkel --- (In reply to comment #9) > Patch posted for review: https://reviews.llvm.org/D24038 r280350. Also, PR30231 filed to track the potential issue on ARM. -- 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 30236] New: Fails deduction of parameter pack for pack of function parameter types
https://llvm.org/bugs/show_bug.cgi?id=30236
Bug ID: 30236
Summary: Fails deduction of parameter pack for pack of function
parameter types
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: C++14
Assignee: unassignedclangb...@nondot.org
Reporter: r...@gmx.net
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
template
void f( void(...t)(T) );
template
void g( void(t)(T) );
int main() {
void h(int);
f(h); // Error
g(h); // Ok?
}
This seems inconsistent, because the deduction of the pack T in the call to f
is done by performing deduction of void(T) against void(int), that is, the
deduction step necessary for the call to g (which succeeds).
The error message suggests that deduction is performed with the decayed type of
'g':
> could not match 'void (T)' against 'void (*)(int)'
Presumably it would succeed if A is left as 'void(int)'.
--
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 30237] New: lld does not implement -f option
https://llvm.org/bugs/show_bug.cgi?id=30237 Bug ID: 30237 Summary: lld does not implement -f option Product: lld Version: unspecified Hardware: PC OS: FreeBSD Status: NEW Severity: normal Priority: P Component: ELF Assignee: unassignedb...@nondot.org Reporter: ema...@freebsd.org CC: llvm-bugs@lists.llvm.org Blocks: 23214 Classification: Unclassified FreeBSD's libstdc++ build (used on tier-2 architectures) uses GNU ld's -f option, which sets the DT_AUXILIARY field to the specified name. Multiple -f options may be specified and the DT_AUXILIARY entries will be added in the order in which they appear. -- 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 30238] New: Is there a consumable format for the compiler diagnostics?
https://llvm.org/bugs/show_bug.cgi?id=30238 Bug ID: 30238 Summary: Is there a consumable format for the compiler diagnostics? Product: clang Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P Component: Static Analyzer Assignee: kreme...@apple.com Reporter: trevorjameshic...@gmail.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified There are a lot of options for formatting the output of clang's diagnostics: -fshow-column -fshow-source-location -fno-caret-diagnostics -fno-color-diagnostics -fdiagnostics-format=clang -fdiagnostics-show-option -fdiagnostics-show-category=name -fno-diagnostics-fixit-info -fno-diagnostics-print-source-range-info -fdiagnostics-parseable-fixits -fno-elide-type -fno-diagnostics-show-template-tree Yet none of these produce diagnostics in a structured format. How can one easily consume these diagnostics via another program? I'm dealing with a huge codebase, and it would be helpful to parse all of the diagnostics and order them by warning type, file, etc. I was hoping I could dump this information in XML instead of wrangling with regexes. Are there any plans to make that possible? What is the best way to parse all of this information reliably? related SO question: http://stackoverflow.com/questions/36657869/how-do-i-dump-gcc-warnings-into-a-structured-format -- 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 28892] AVX512: fmsub intrinsic generates fmadd instruction
https://llvm.org/bugs/show_bug.cgi?id=28892 Elena Demikhovsky changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Elena Demikhovsky --- fixed in 280368 -- 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 30239] New: clang-cl crash when compiling parts of Firefox
https://llvm.org/bugs/show_bug.cgi?id=30239 Bug ID: 30239 Summary: clang-cl crash when compiling parts of Firefox Product: new-bugs Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: froy...@gmail.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified Created attachment 17197 --> https://llvm.org/bugs/attachment.cgi?id=17197&action=edit preprocessed sources and runscripts for crash clang-cl started crashing when building Firefox after updating recently (r280364). A version of clang-cl (sorry, don't have the SVN revision) from last week or so would at least compile the code without crashing. The crashes say to submit the backtrace, but no backtrace was printed out. I've attached bugreport.tar.gz containing preprocessed sources for the two files that crash, plus associated runscripts as provided by clang-cl. -- 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 30229] Clang generates stacksave/stackrestore incorrectly when a loop has VLA and alloca
https://llvm.org/bugs/show_bug.cgi?id=30229 Reid Kleckner changed: What|Removed |Added Status|NEW |RESOLVED CC||r...@google.com Resolution|--- |DUPLICATE --- Comment #1 from Reid Kleckner --- This is a well-known issue that's basically infeasible to fix without seriously violating user expectations in some way. GCC's new behavior also seems surprising, and could easily lead to stack overflow in your example. The other way to fix this it to have alloca call malloc behind the scenes in this situation. However, oftentimes users are using alloca because they are trying to avoid malloc for async signal safety reasons. If you don't mind, I'm going to dupe against the old bug. What's new is that GCC has decided to make this code work. *** This bug has been marked as a duplicate of bug 16099 *** -- 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 30240] New: std::string: append(first, last) error when aliasing
https://llvm.org/bugs/show_bug.cgi?id=30240
Bug ID: 30240
Summary: std::string: append(first, last) error when aliasing
Product: libc++
Version: unspecified
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: All Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: llvm-b...@daryl.haresign.com
CC: llvm-bugs@lists.llvm.org, mclow.li...@gmail.com
Classification: Unclassified
The standard says:
| template
| basic_string& append(InputIterator first, InputIterator last);
|
| Requires: [first, last) is a valid range.
|
| Effects: Equivalent to append(basic_string(first, last)).
|
| Returns: *this.
http://eel.is/c++draft/string::append#20
Given that, I would expect the following to work:
| std::string str("hello world//");
|
| str.append(str.begin(), str.end());
| str.append(str.begin(), str.end());
And I should end up with 'str' containing:
| hello world//hello world//hello world//hello world//
libcxx, however, appears to try to avoid creating a temporary string if it can:
https://github.com/llvm-mirror/libcxx/blob/master/include/string#L2159
If the capacity is not enough for the new string, it will resize the storage:
https://github.com/llvm-mirror/libcxx/blob/master/include/string#L2175
Unfortunately '__grow_by()' destroys the old storage before the string is
copied.
This means the above code doesn't work as expected. You can see the result
of calling the above code here, compiled against libcxx and libstdc++:
http://coliru.stacked-crooked.com/a/b099fd5dada88798
--
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 30239] clang-cl crash when compiling parts of Firefox
https://llvm.org/bugs/show_bug.cgi?id=30239 Reid Kleckner changed: What|Removed |Added Status|NEW |RESOLVED CC||r...@google.com Resolution|--- |FIXED --- Comment #1 from Reid Kleckner --- I wasn't about to reproduce the crash on either file with clang built from this morning. The command line enables codeview debug info, and I suspect this was a crash I introduced and fixed yesterday between r280255 and r280287 (4 hour window). I'm going to speculatively mark this fixed, but let me know if things are still broken with a fresh clang. -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 30223] Clang 4.0 Regression: r279460 causes segmentation fault
https://llvm.org/bugs/show_bug.cgi?id=30223 Luke changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WORKSFORME -- 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 30241] New: llvm-objdump -p omits dynamic headers (in comparison to GNU objdump)
https://llvm.org/bugs/show_bug.cgi?id=30241 Bug ID: 30241 Summary: llvm-objdump -p omits dynamic headers (in comparison to GNU objdump) Product: new-bugs Version: unspecified Hardware: PC OS: FreeBSD Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: ema...@freebsd.org CC: llvm-bugs@lists.llvm.org Classification: Unclassified In FreeBSD we're looking at using llvm-objdump as a replacement for GNU objdump and investigating common use cases that produce different output. GNU objdump -p displays the phdr, .dynamic section, and symver info: = % /usr/local/bin/objdump -p /tank/emaste/src/llvm/build-nodebug/bin/lldb /tank/emaste/src/llvm/build-nodebug/bin/lldb: file format elf64-x86-64-freebsd Program Header: PHDR off0x0040 vaddr 0x00400040 paddr 0x00400040 align 2**3 filesz 0x01c0 memsz 0x01c0 flags r-x INTERP off0x0200 vaddr 0x00400200 paddr 0x00400200 align 2**0 filesz 0x0015 memsz 0x0015 flags r-- LOAD off0x vaddr 0x0040 paddr 0x0040 align 2**21 filesz 0x9aa4 memsz 0x9aa4 flags r-x LOAD off0xa000 vaddr 0x0060a000 paddr 0x0060a000 align 2**21 filesz 0x0aa8 memsz 0x0af0 flags rw- DYNAMIC off0xa050 vaddr 0x0060a050 paddr 0x0060a050 align 2**3 filesz 0x0270 memsz 0x0270 flags rw- NOTE off0x0218 vaddr 0x00400218 paddr 0x00400218 align 2**2 filesz 0x0030 memsz 0x0030 flags r-- EH_FRAME off0x93b4 vaddr 0x004093b4 paddr 0x004093b4 align 2**2 filesz 0x014c memsz 0x014c flags r-- STACK off0x vaddr 0x paddr 0x align 2**3 filesz 0x memsz 0x flags rw- Dynamic Section: NEEDED libthr.so.3 NEEDED liblldb.so.4.0.0 NEEDED librt.so.1 NEEDED libexecinfo.so.1 NEEDED libtinfo.so.6 NEEDED libz.so.6 NEEDED libm.so.5 NEEDED libc++.so.1 NEEDED libcxxrt.so.1 NEEDED libc.so.7 RPATH$ORIGIN/../lib RUNPATH $ORIGIN/../lib INIT 0x004034a8 FINI 0x00407ff8 HASH 0x00400248 GNU_HASH 0x004008b8 STRTAB 0x00401650 SYMTAB 0x00400948 STRSZ0x11c4 SYMENT 0x0018 DEBUG0x PLTGOT 0x0060a318 PLTRELSZ 0x0a50 PLTREL 0x0007 JMPREL 0x00402a58 RELA 0x00402950 RELASZ 0x0108 RELAENT 0x0018 FLAGS0x0001 FLAGS_1 0x0080 VERNEED 0x00402930 VERNEEDNUM 0x0001 VERSYM 0x00402814 Version References: required from libc.so.7: 0x077a28b0 0x00 02 FBSD_1.0 = llvm-objdump emits only the phdr: = % /tank/emaste/src/llvm/build-nodebug/bin/llvm-objdump -p /tank/emaste/src/llvm/build-nodebug/bin/lldb /tank/emaste/src/llvm/build-nodebug/bin/lldb: file format ELF64-x86-64 Program Header: PHDR off0x0040 vaddr 0x00400040 paddr 0x00400040 align 2**3 filesz 0x01c0 memsz 0x01c0 flags r-x INTERP off0x0200 vaddr 0x00400200 paddr 0x00400200 align 2**0 filesz 0x0015 memsz 0x0015 flags r-- LOAD off0x vaddr 0x0040 paddr 0x0040 align 2**21 filesz 0x9aa4 memsz 0x9aa4 flags r-x LOAD off0xa000 vaddr 0x0060a000 paddr 0x0060a000 align 2**21 filesz 0x0aa8 memsz 0x0af0 flags rw- DYNAMIC off0xa050 vaddr 0x0060a050 paddr 0x0060a050 align 2**3 filesz 0x0270 memsz 0x0270 flags rw- UNKNOWN off0x0218 vaddr 0x00400218 paddr 0x00400218 align 2**2
[llvm-bugs] [Bug 30242] New: Missing support for K and M suffixes
https://llvm.org/bugs/show_bug.cgi?id=30242 Bug ID: 30242 Summary: Missing support for K and M suffixes Product: lld Version: unspecified Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: ELF Assignee: unassignedb...@nondot.org Reporter: rafael.espind...@gmail.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified Both bfd and gold accept foo = 1K; bar = 1M; in linker scripts but lld rejects: line 1: malformed number: 1K foo = 1K; -- 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 30243] New: Add support for the FILL command
https://llvm.org/bugs/show_bug.cgi?id=30243 Bug ID: 30243 Summary: Add support for the FILL command Product: lld Version: unspecified Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: ELF Assignee: unassignedb...@nondot.org Reporter: rafael.espind...@gmail.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified Both gold and lld support setting the fill of the current section with 'FILL(0x90);' -- 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 30244] New: TSAN analyze step fails on the bots
https://llvm.org/bugs/show_bug.cgi?id=30244 Bug ID: 30244 Summary: TSAN analyze step fails on the bots Product: compiler-rt Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: compiler-rt Assignee: unassignedb...@nondot.org Reporter: kra...@google.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified Recently, the sanitizer autoconf bot turned red: http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-autoconf/builds/24680/steps/tsan%20analyze/logs/stdio The failure is described as: + /mnt/b/sanitizer-buildbot4/sanitizer-x86_64-linux-autoconf/build/llvm/projects/compiler-rt/lib/tsan/check_analyze.sh /tmp/tsan_exe.L3wvOKAx ... read1 tot 412; size 1428; rsp 1; push 6; pop 6; call 2; load 6; store 11; sh 28; mov 95; lea 8; cmp 60 ... FAILED read1 must contain push 5 + echo @@@STEP_FAILURE@@@ @@@STEP_FAILURE@@@ On the previous buildbot run, it was 5: http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-autoconf/builds/24679/steps/tsan%20analyze/logs/stdio read2 tot 386; size 1361; rsp 1; push 5; pop 5; call 2; load 8; store 11; sh 28; mov 89; lea 4; cmp 64 The CL affected the code is (unsurprisingly) related to codegen: https://reviews.llvm.org/rL280364 And the last commit to check_analyze.sh tells us: """ r268382 | dvyukov | 2016-05-03 06:59:41 -0700 (Tue, 03 May 2016) | 11 lines tsan: update tsan_analyze to what tip clang generates We used to depend on host gcc. But some distributions got new gcc recently which broke the check. Generally, we can't depend that an arbitrary host gcc generates something stable. Switch to clang. This has an additional advantage of catching regressions in clang codegen. """ I guess, we have caught a regression in clang codegen, but I am failing to decipher what it means for us: shall we fix the codegen or just update the expectation? -- 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 30245] New: Compiler-rt linking broken
https://llvm.org/bugs/show_bug.cgi?id=30245 Bug ID: 30245 Summary: Compiler-rt linking broken Product: lld Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: ELF Assignee: unassignedb...@nondot.org Reporter: eugene.zele...@gmail.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified Compiler-rt linking with lld become broken today. Looks like problem was introduced in r280310. [ 65%] Linking CXX shared library ../../../../lib64/clang/4.0.0/lib/linux/libclang_rt.asan-i386.so can't create dynamic relocation R_386_GOTOFF against readonly segment can't create dynamic relocation R_386_GOTOFF against symbol __dso_handle can't create dynamic relocation R_386_GOTOFF against readonly segment can't create dynamic relocation R_386_GOTOFF against symbol __DTOR_END__ can't create dynamic relocation R_386_GOTOFF against readonly segment can't create dynamic relocation R_386_GOTOFF against readonly segment can't create dynamic relocation R_386_GOTOFF against readonly segment can't create dynamic relocation R_386_GOTOFF against readonly segment can't create dynamic relocation R_386_GOTOFF against readonly segment can't create dynamic relocation R_386_GOTOFF against readonly segment can't create dynamic relocation R_386_GOTOFF against readonly segment can't create dynamic relocation R_386_GOTOFF against readonly segment can't create dynamic relocation R_386_GOTOFF against readonly segment can't create dynamic relocation R_386_GOTOFF against readonly segment can't create dynamic relocation R_386_GOTOFF against readonly segment can't create dynamic relocation R_386_GOTOFF against readonly segment can't create dynamic relocation R_386_GOTOFF against readonly segment can't create dynamic relocation R_386_GOTOFF against readonly segment can't create dynamic relocation R_386_GOTOFF against readonly segment can't create dynamic relocation R_386_GOTOFF against readonly segment can't create dynamic relocation R_386_GOTOFF against readonly segment can't create dynamic relocation R_386_GOTOFF against readonly segment can't create dynamic relocation R_386_GOTOFF against readonly segment can't create dynamic relocation R_386_GOTOFF against readonly segment can't create dynamic relocation R_386_GOTOFF against readonly segment can't create dynamic relocation R_386_GOTOFF against readonly segment can't create dynamic relocation R_386_GOTOFF against readonly segment can't create dynamic relocation R_386_GOTOFF against readonly segment can't create dynamic relocation R_386_GOTOFF against readonly segment can't create dynamic relocation R_386_GOTOFF against readonly segment can't create dynamic relocation R_386_GOTOFF against readonly segment can't create dynamic relocation R_386_GOTOFF against readonly segment can't create dynamic relocation R_386_GOTOFF against readonly segment can't create dynamic relocation R_386_GOTOFF against readonly segment can't create dynamic relocation R_386_GOTOFF against readonly segment can't create dynamic relocation R_386_GOTOFF against readonly segment can't create dynamic relocation R_386_GOTOFF against readonly segment can't create dynamic relocation R_386_GOTOFF against readonly segment can't create dynamic relocation R_386_GOTOFF against readonly segment can't create dynamic relocation R_386_GOTOFF against symbol .L.str.1 can't create dynamic relocation R_386_GOTOFF against symbol .L.str -- 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 30246] New: PPC64: IfConverter::IfConvertDiamondCommon: Assertion `!NodePtr->isKnownSentinel()' failed
https://llvm.org/bugs/show_bug.cgi?id=30246 Bug ID: 30246 Summary: PPC64: IfConverter::IfConvertDiamondCommon: Assertion `!NodePtr->isKnownSentinel()' failed Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Common Code Generator Code Assignee: unassignedb...@nondot.org Reporter: hfin...@anl.gov CC: llvm-bugs@lists.llvm.org Classification: Unclassified Created attachment 17199 --> https://llvm.org/bugs/attachment.cgi?id=17199&action=edit bugpoint reduced test case Running llc on the attached input asserts: include/llvm/ADT/ilist_iterator.h:112: llvm::ilist_iterator::reference llvm::ilist_iterator::operator*() const [with NodeTy = llvm::MachineInstr; bool IsReverse = false; llvm::ilist_iterator::reference = llvm::MachineInstr&]: Assertion `!NodePtr->isKnownSentinel()' failed. >From IfConverter::IfConvertDiamondCommon. This is on ppc64le. -- 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 29025] <12 x i8> shuffle is lowered to a sequence of extracts and inserts.
https://llvm.org/bugs/show_bug.cgi?id=29025 Michael Kuperstein changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Michael Kuperstein --- Fixed in r280418. -- 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 29170] wrong code at -Os and above on x86_64-linux-gnu in 32-bit mode
https://llvm.org/bugs/show_bug.cgi?id=29170 Michael Kuperstein changed: 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 30247] New: Clang prohibits friendship based on typedefs
https://llvm.org/bugs/show_bug.cgi?id=30247 Bug ID: 30247 Summary: Clang prohibits friendship based on typedefs Product: clang Version: 3.8 Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: -New Bugs Assignee: unassignedclangb...@nondot.org Reporter: mattreecebent...@gmail.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified This: template class class_iterator; typedef class_iteratoriterator; typedef class_iteratorconst_iterator; friend class class_iterator; friend class class_iterator; works. This: template class class_iterator; typedef class_iteratoriterator; typedef class_iteratorconst_iterator; friend class iterator; friend class const_iterator; Does not. -- 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 20372] Left-over files in /tmp from check-clang
https://llvm.org/bugs/show_bug.cgi?id=20372 Reid Kleckner changed: What|Removed |Added Status|NEW |RESOLVED CC||r...@google.com Resolution|--- |DUPLICATE --- Comment #1 from Reid Kleckner --- *** This bug has been marked as a duplicate of bug 18335 *** -- 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 28727] PowerPC - bug in generation of @ha/@l pair for symbol+addend
https://llvm.org/bugs/show_bug.cgi?id=28727
Hal Finkel changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|--- |FIXED
--- Comment #10 from Hal Finkel ---
(In reply to comment #9)
> Thanks for digging up the change, Hal. Your comment sounds correct. In fact,
>
> +if (GlobalAddressSDNode *GA = dyn_cast(ImmOpnd)) {
> + const GlobalValue *GV = GA->getGlobal();
> + MaxDisplacement = GV->getAlignment() - 1;
> +}
>
> looks suspect. MaxDisplacement can only be 7 or less otherwise the TOC bits
> can potentially (and do in our failure) carry into the 32K displacement.
r280441 should fix this. Thanks again for helping to figure this out!
--
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 30248] New: [ThinLTO] Assertion `(!*MappedOp || M.getVM().count(CMD->getValue()) || M.getVM().getMappedMD(Op)) && "Expected Value to be memoized"' failed.
https://llvm.org/bugs/show_bug.cgi?id=30248
Bug ID: 30248
Summary: [ThinLTO] Assertion `(!*MappedOp ||
M.getVM().count(CMD->getValue()) ||
M.getVM().getMappedMD(Op)) && "Expected Value to be
memoized"' failed.
Product: lld
Version: unspecified
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: All Bugs
Assignee: unassignedb...@nondot.org
Reporter: t...@fb.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
Created attachment 17201
--> https://llvm.org/bugs/attachment.cgi?id=17201&action=edit
source file
repro:
clang++ -g2 -std=c++11 -flto=thin -c -o main.o main.cpp
clang++ -g2 -std=c++11 -flto=thin -c -o dst.o dst.cpp
clang++ -g2 -std=c++11 -flto=thin -c -o src.o src.cpp
clang++ -o /dev/null -B/usr/local/bin/gold -flto=thin main.o dst.o src.o
ld: /data/users/twoh/llvms/svn/llvm/lib/Transforms/Utils/ValueMapper.cpp:525:
llvm::Optional
{anonymous}::MDNodeMapper::tryToMapOperand(const llvm::Metadata*): Assertion
`(!*MappedOp || M.getVM().count(CMD->getValue()) || M.getVM().getMappedMD(Op))
&& "Expected Value to be memoized"' failed.
clang-4.0: error: unable to execute command: Aborted (core dumped)
clang-4.0: error: linker command failed due to signal (use -v to see
invocation)
Tested with revision 280435
--
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 30249] New: AVX512 fails to select CMP of i1.
https://llvm.org/bugs/show_bug.cgi?id=30249
Bug ID: 30249
Summary: AVX512 fails to select CMP of i1.
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Backend: X86
Assignee: unassignedb...@nondot.org
Reporter: mku...@google.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
define i64 @foo() {
%v = select i1 undef, i64 1, i64 2
ret i64 %v
}
bin/llc ~/llvm/temp/i1512.ll -mattr=+avx512f -mattr=+avx2
SelectionDAG has 11 nodes:
t0: ch = EntryToken
t18: i32 = X86ISD::CMP undef:i1, Constant:i1<-1>
t20: i64 = X86ISD::ADC Constant:i64<1>, Constant:i64<0>, t18
t7: ch,glue = CopyToReg t0, Register:i64 %RAX, t20
t8: ch = X86ISD::RET_FLAG t7, TargetConstant:i32<0>, Register:i64 %RAX, t7:1
[...]
LLVM ERROR: Cannot select: 0x2ec28d0: i32 = X86ISD::CMP undef:i1,
Constant:i1<-1>
0x2ec2240: i1 = undef
0x2ec2710: i1 = Constant<-1>
In function: foo
--
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 30250] New: tex1Dfetch fails to compile
https://llvm.org/bugs/show_bug.cgi?id=30250 Bug ID: 30250 Summary: tex1Dfetch fails to compile Product: clang Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: CUDA Assignee: unassignedclangb...@nondot.org Reporter: jia.ka...@gmail.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified * version: llvm r280452, clang r280436 * reproduce steps: cat > texture.cu <(src, offset); } EOF ./build/bin/clang++ texture.cu -o /dev/null --cuda-gpu-arch=sm_52 * clang would report: ptxas fatal : Unresolved extern function '__tex_1d_v4f32_s32' clang-4.0: error: ptxas command failed with exit code 255 (use -v to see invocation) -- 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 27356] [ppc] missed chance to use rlwnm
https://llvm.org/bugs/show_bug.cgi?id=27356 Hal Finkel changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Hal Finkel --- (In reply to comment #1) > (In reply to comment #0) > > Double-check to make sure because my PPC is beyond rusty, but I think this > > is: > > > > subfic r4, r4, 32 > > rlwnm r3, r3, r4, 31, 31 > > Yes. I've used cvc4 to verify that this is true (assuming that y < 32 -- > three cheers for undefined behavior!). > > Also, for y < 64, we also can use rldcl(x, subfic(y, 64), 63). Patterns added in r280454. Thanks! -- 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 27203] [ppc] hoist repeated constant for better code size and speed
https://llvm.org/bugs/show_bug.cgi?id=27203 Hal Finkel changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #11 from Hal Finkel --- (In reply to comment #10) > http://reviews.llvm.org/rL268858 adds a hook to allow 'andc' generation for > PPC which would bypass the problem (in most cases?). > Indeed it does (test changes all look good, and I added the test case from this PR as well). r280457. Thanks again for the suggestion. -- 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 30251] New: ioctl for request TIOCGWINSZ on STDOUT_FILENO not working on OS X
https://llvm.org/bugs/show_bug.cgi?id=30251
Bug ID: 30251
Summary: ioctl for request TIOCGWINSZ on STDOUT_FILENO not
working on OS X
Product: lldb
Version: unspecified
Hardware: Macintosh
OS: MacOS X
Status: NEW
Severity: normal
Priority: P
Component: All Bugs
Assignee: lldb-...@lists.llvm.org
Reporter: 6172839...@gmail.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
When debugging a process in LLDB using the ``process launch -c /bin/sh'', using
ioctl with request TIOCGWINSZ on STDOUT_FILENO always gives the width and
height of the window as zero and zero.
Test program:
#include
#include
#include
void main(){
struct winsize tty_window_size;
ioctl(STDOUT_FILENO, TIOCGWINSZ, &tty_window_size);
printf("Rows: %i, Cols: %i\n", tty_window_size.ws_row,
tty_window_size.ws_col);
}
When run from terminal:
$ ./test_ioctl
Rows: 24, Cols: 80
$ lldb -v
lldb-320.4.156
$ lldb ./test_ioctl
(lldb) target create "./a.out"
(lldb) process launch -c /bin/sh
Rows: 0, Cols: 0
(lldb) q
--
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 28630] Wrong code generation for VSX floating-point loads with fast-isel
https://llvm.org/bugs/show_bug.cgi?id=28630 Hal Finkel changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #2 from Hal Finkel --- Seems this was fixed by r277823. -- 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 30252] New: reviews.llvm.org/F* links aren't accessible without logging in to phabricator
https://llvm.org/bugs/show_bug.cgi?id=30252 Bug ID: 30252 Summary: reviews.llvm.org/F* links aren't accessible without logging in to phabricator Product: Website Version: unspecified Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: Phabricator Assignee: unassignedb...@nondot.org Reporter: llvm-b...@justinbogner.com CC: kli...@google.com, llvm-bugs@lists.llvm.org Classification: Unclassified Phab seems to allow pastes or screenshots or whatever, but if you try to look at them it demands you log in. This is problematic for things like https://reviews.llvm.org/D24144, where the review (which is, correctly, public) œrefers to things inside the walled garden. -- 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
