[llvm-bugs] [Bug 40062] New: lldb cannot deduce dynamic most derived type for types with lambda type as template argument
https://bugs.llvm.org/show_bug.cgi?id=40062
Bug ID: 40062
Summary: lldb cannot deduce dynamic most derived type for types
with lambda type as template argument
Product: lldb
Version: unspecified
Hardware: PC
OS: MacOS X
Status: NEW
Severity: normal
Priority: P
Component: All Bugs
Assignee: lldb-...@lists.llvm.org
Reporter: e...@olofsson.info
CC: llvm-bugs@lists.llvm.org
main.cpp:
struct CStoreFunctor
{
virtual ~CStoreFunctor() = default;
};
template
struct TCStoreFunctor : public CStoreFunctor
{
TCStoreFunctor(t_CFunctor _fFunctor)
: m_fFunctor(_fFunctor)
{
}
t_CFunctor m_fFunctor;
};
struct CTestFunctor
{
void operator() () const
{
}
};
int main()
{
TCStoreFunctor Test0{{}};
CStoreFunctor *pTest0 = &Test0;
auto fTest = []
{
}
;
TCStoreFunctor Test1{fTest};
CStoreFunctor *pTest1 = &Test1;
return 0;
}
# clang++ testdebug.cpp -g -o test -std=c++17
# lldb test
(lldb) break set --file main.cpp --line 39
(lldb) run
(lldb) p pTest0
(TCStoreFunctor *) $0 = 0x7ffeefbff7a8
(lldb) p pTest1
(CStoreFunctor *) $1 = 0x7ffeefbff780
I tracked this down to ItaniumABILanguageRuntime::GetTypeInfoFromVTableAddress
where the type name is:
0x7ffeefbff780: static-type = 'CStoreFunctor *' has vtable symbol 'vtable
for TCStoreFunctor'
It's then using this name 'TCStoreFunctor' to lookup the type with
FindTypes. The problem is that the dwarf info has another name for
this type:
(lldb) script
>>> for type in lldb.target.GetModuleAtIndex(0).GetTypes():
... print type.GetName()
...
TCStoreFunctor<(lambda at main.cpp:31:15)>
TCStoreFunctor<(anonymous class)> *
--
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 40063] New: memcmp with constant string arguments produces wrong result
https://bugs.llvm.org/show_bug.cgi?id=40063 Bug ID: 40063 Summary: memcmp with constant string arguments produces wrong result Product: clang Version: 6.0 Hardware: PC OS: FreeBSD Status: NEW Severity: normal Priority: P Component: LLVM Codegen Assignee: unassignedclangb...@nondot.org Reporter: br...@clisp.org CC: llvm-bugs@lists.llvm.org, neeil...@live.com, richard-l...@metafoo.co.uk Created attachment 21244 --> https://bugs.llvm.org/attachment.cgi?id=21244&action=edit Test case A memcmp() call with constant arguments is apparently inlined by clang and produces a wrong result. How to reproduce: $ cc foo.c $ nm a.out | grep memcmp $ ./a.out Expected output: A negative number. Actual output: 1 OS: FreeBSD 12.0 on x86_64 clang version: $ cc --version FreeBSD clang version 6.0.1 (tags/RELEASE_601/final 335540) (based on LLVM 6.0.1) Target: x86_64-unknown-freebsd12.0 Thread model: posix InstalledDir: /usr/bin -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 40064] New: llvm-readelf does not accept combined args as GNU readelf does
https://bugs.llvm.org/show_bug.cgi?id=40064 Bug ID: 40064 Summary: llvm-readelf does not accept combined args as GNU readelf does Product: tools Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: llvm-readobj Assignee: unassignedb...@nondot.org Reporter: jh7370.2...@my.bristol.ac.uk CC: jh7370.2...@my.bristol.ac.uk, llvm-bugs@lists.llvm.org Similar to bug 31679 for llvm-objdump, llvm-readelf does not accept multiple short switches combined into a single argument: > llvm-readelf -hS .\Inputs\main.o llvm-readelf.exe: Unknown command line argument '-hS'. Try: 'llvm-readelf.exe -help' llvm-readelf.exe: Did you mean '-S'? GNU readelf does understand this sort of combination. The solution to bug 31679 is likely the same solution required for this bug. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 40065] New: Add llvm-symbolizer component to tools product
https://bugs.llvm.org/show_bug.cgi?id=40065 Bug ID: 40065 Summary: Add llvm-symbolizer component to tools product Product: Bugzilla Admin Version: unspecified Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: Products Assignee: unassignedb...@nondot.org Reporter: jh7370.2...@my.bristol.ac.uk CC: kristof.be...@gmail.com, llvm-bugs@lists.llvm.org, r...@google.com, t.p.northo...@gmail.com Hi guys, Please could you add an llvm-symbolizer component to the tools product. I have a number of bugs I'm about to file in that area. I'm happy to be on the default CC list for this new component too. -- 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 40066] New: Failed access analysis and missing vectorization of loop containing std::min/std::max
https://bugs.llvm.org/show_bug.cgi?id=40066
Bug ID: 40066
Summary: Failed access analysis and missing vectorization of
loop containing std::min/std::max
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Global Analyses
Assignee: unassignedb...@nondot.org
Reporter: moritz.kreut...@siemens.com
CC: llvm-bugs@lists.llvm.org
Hi,
Clang trunk fails to vectorize the following loop with "cannot identify array
bounds":
for (int i = 0; i < end; ++i) // does not vectorize
{
dst[i] = std::min(dst[i], dst[i]/src[i]);
}
If we don't use std::min, but a simple ternary operator, Clang is able to
vectorize the resulting loop:
for (int i = 0; i < end; ++i) // vectorizes
{
dst[i] = dst[i] < dst[i]/src[i] ? dst[i] : dst[i]/src[i];
}
The problem does not seem to be std::min in itself, because Clang is able to
vectorize the following loop (note the different logic and the absence of an
implicit temporary for dst[i]/src[i]):
for (int i = 0; i < end; ++i) // vectorizes
{
dst[i] = std::min(dst[i], src[i]);
}
If we replace std::min with a custom implementation, returning the result by
value instead of "const &" (as it is done in libstdc++), we can also get the
first version to vectorize.
Obligatory godbolt: https://godbolt.org/z/6xjhz-
All in all, it seems like mixing references and values is the problem here. I
have tried patching D23686, D52116, and D52117, to no avail. From my feeling,
the first loop is something which should be vectorizable, even with the default
implementation of std::min (return a const reference ) in libstdc++ (in the
end, the call should be inlined and the compiler should be able to see through
everything). But maybe I'm missing something obvious, so any help is greatly
appreciated.
Thanks in advance,
Moritz
--
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 40067] New: llvm-symbolizer: Add -a and --addresses as aliases for --print-address
https://bugs.llvm.org/show_bug.cgi?id=40067 Bug ID: 40067 Summary: llvm-symbolizer: Add -a and --addresses as aliases for --print-address Product: new-bugs Version: unspecified Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: jh7370.2...@my.bristol.ac.uk CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org llvm-symbolizer has a --print-address option which prints the input address before the corresponding output. This is the same behaviour as GNU's addr2line --addresses switch (aka -a). It would be nice to add these two aliases to llvm-symbolizer to improve GNU compatibility. -- 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 40068] New: llvm-symbolizer: add --basenames/-s functionality
https://bugs.llvm.org/show_bug.cgi?id=40068 Bug ID: 40068 Summary: llvm-symbolizer: add --basenames/-s functionality Product: new-bugs Version: unspecified Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: jh7370.2...@my.bristol.ac.uk CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org GNU addr2line has a --basenames (aka -s) switch which is used when printing file paths. Instead of printing the full directory path, it prints only the base filename: C:\Work\TempWork> addr2line 0x20 -e main.elf C:\Work\TempWork/main.cpp:14 C:\Work\TempWork> addr2line 0x20 -e main.elf --basenames main.cpp:14 I propose we add this to llvm-symbolizer. Adding this should be pretty simple and would improve our GNU compatibility. It also makes the output more readable when used (if we don't care about full paths), especially when dealing with deep directory structures. There may well be other use-cases that I can't immediately think of as well. -- 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 40069] New: llvm-symbolizer: Add -C as alias for --demangle
https://bugs.llvm.org/show_bug.cgi?id=40069 Bug ID: 40069 Summary: llvm-symbolizer: Add -C as alias for --demangle Product: new-bugs Version: unspecified Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: jh7370.2...@my.bristol.ac.uk CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org llvm-symbolizer has a --demangle switch, which means that any printed symbol names are demangled. GNU addr2line provides -C as an alias for this switch. We should add this alias to improve command-line compatibility. -- 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 40070] New: llvm-symbolizer: Accept addresses on the command-line
https://bugs.llvm.org/show_bug.cgi?id=40070 Bug ID: 40070 Summary: llvm-symbolizer: Accept addresses on the command-line Product: new-bugs Version: unspecified Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: jh7370.2...@my.bristol.ac.uk CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org GNU addr2line can read addresses from either stdin or the command-line. It uses stdin only if there are none on the command-line. We should add support for this in llvm-symbolizer too. Example add2line usage: C:\Work> addr2line 0x10 0x30 -e .\Inputs\main.elf C:\Work\Inputs/main.cpp:13 C:\Work\Inputs/main.cpp:28 This is equivalent to piping 0x10 and 0x30 on stdin. -- 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 40071] New: llvm-symbolizer: Add -e/--exe as aliases for --obj
https://bugs.llvm.org/show_bug.cgi?id=40071 Bug ID: 40071 Summary: llvm-symbolizer: Add -e/--exe as aliases for --obj Product: new-bugs Version: unspecified Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: jh7370.2...@my.bristol.ac.uk CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org If specified, llvm-symbolizer uses the value of the --obj argument as the input file. GNU addr2line uses -e/--exe for the same thing, and does not recognise --obj. It would improve command-line compatibility if we added both -e and --exe as aliases for --obj to llvm-symbolizer. -- 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 40072] New: llvm-symbolizer: Improve GNU compatibility of --functions switch
https://bugs.llvm.org/show_bug.cgi?id=40072 Bug ID: 40072 Summary: llvm-symbolizer: Improve GNU compatibility of --functions switch Product: new-bugs Version: unspecified Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: jh7370.2...@my.bristol.ac.uk CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org There are a few compatibility issues between llvm-symbolizer's --functions switch and GNU addr2line's --functions switch. It would be good to fix these: 1) -f is not an alias for --functions. 2) --functions expects to take an argument in llvm-symbolizer, but not in GNU addr2line. 3) GNU's default behaviour is to not print function names by default (i.e. --functions=none), but llvm-symbolizer does --functions=linkage. We should investigate why this decision was made to be different, and consider the impact of changing (I don't think we can change the default, but it's probably worth investigating anyway). -- 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 40073] New: llvm-symbolizer: Add -i/--inlines as aliases of --inlining
https://bugs.llvm.org/show_bug.cgi?id=40073 Bug ID: 40073 Summary: llvm-symbolizer: Add -i/--inlines as aliases of --inlining Product: new-bugs Version: unspecified Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: jh7370.2...@my.bristol.ac.uk CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org llvm-symbolizer provides the --inlining switch to print information about inlined functions. GNU addr2line uses a different spelling for this switch (--inlines), and also provides a short alias (-i). These switches provide the same behaviour as llvm-symbolizer's switch, so we should add them to improve command-line compatibility. -- 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 40074] New: Duplicate definition of symbol error to do with mergable comdat constant symbols on Windows/COFF
https://bugs.llvm.org/show_bug.cgi?id=40074
Bug ID: 40074
Summary: Duplicate definition of symbol error to do with
mergable comdat constant symbols on Windows/COFF
Product: libraries
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: normal
Priority: P
Component: OrcJIT
Assignee: unassignedb...@nondot.org
Reporter: cont...@machiel.info
CC: 1101.deb...@gmail.com, llvm-bugs@lists.llvm.org
It happens when the same literal is defined twice, each in a different module
and after the second module has been added to the RTDyldObjectLinkingLayer.
So for example in some module:
define float @someFunction() {
entry:
ret float 2.00e+00
}
In some other module:
define float @someOtherFunction() {
entry:
ret float 2.00e+00
}
When materializing the second function, you will get this error:
JIT session error: Duplicate definition of symbol '__real@4000'
The symbol names come from comdat symbols that are created in
TargetLoweringObjectFileImpl.cpp
TargetLoweringObjectFileCOFF::getSectionForConstant
For COFF, I have the OverrideObjectFlagsWithResponsibilityFlags and
AutoClaimResponsibilityForObjectSymbols set to true on the
RTDyldObjectLinkingLayer or my function symbols are not found at all.
The same code compiles and runs just fine on Linux/Elf, even with the COFF
workarounds enabled there as well.
A workaround I found is to set HasCOFFComdatConstants to false in
MCAsmInfoCOFF.cpp
--
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 40075] New: llvm-symbolizer: Add --no-demangle as alias for --demangle=0
https://bugs.llvm.org/show_bug.cgi?id=40075 Bug ID: 40075 Summary: llvm-symbolizer: Add --no-demangle as alias for --demangle=0 Product: new-bugs Version: unspecified Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: jh7370.2...@my.bristol.ac.uk CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org llvm-symbolizer demangles symbol names by default. To suppress this, you need to use --demangle=0. This syntax is a little unusual in my view to disable functionality. A more normal way would be to use an option like "--no-demangle". It would be nice if this is added as an alias, so that new users are less surprised. -- 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 40076] New: llvm-symbolizer: Add -p as alias for --pretty-print
https://bugs.llvm.org/show_bug.cgi?id=40076 Bug ID: 40076 Summary: llvm-symbolizer: Add -p as alias for --pretty-print Product: new-bugs Version: unspecified Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: jh7370.2...@my.bristol.ac.uk CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org GNU addr2line and llvm-symbolizer both implement the --pretty-print option. GNU addr2line also provides -p as a short alias for it. llvm-symbolizer should to to improve command-line compatibility. -- 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 40077] New: [X86][AVX] Prefer VPSRAV to VPSRA style shifts for known splats
https://bugs.llvm.org/show_bug.cgi?id=40077
Bug ID: 40077
Summary: [X86][AVX] Prefer VPSRAV to VPSRA style shifts for
known splats
Product: libraries
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: Backend: X86
Assignee: unassignedb...@nondot.org
Reporter: llvm-...@redking.me.uk
CC: andrea.dibia...@gmail.com, craig.top...@gmail.com,
llvm-bugs@lists.llvm.org, llvm-...@redking.me.uk,
pe...@cordes.ca, spatel+l...@rotateright.com
As detailed on https://reviews.llvm.org/rL340813, many recent machines have
better throughput for the 'per-element' variable vector shifts than the old
style 'scalar-count-in-xmm' variable shifts if we know that the shift amount is
already splatted:
Probably the wrong place to report this, but I looked at some other sequences:
; AVX-LABEL: splatvar_shift_v4i32:
; AVX: # %bb.0:
; AVX-NEXT:vpmovzxdq {{.*#+}} xmm1 = xmm1[0],zero,xmm1[1],zero # 1 uop /
1c latency
; AVX-NEXT:vpsrad %xmm1, %xmm0, %xmm0# 2 uops / 2c latency
on Intel since Haswell at least
; AVX-NEXT:retq
For Skylake, variable-shifts (vpsraVd) are single uop, but count-in-xmm shifts
are 2 uops. Probably they're implemented internally as broadcast to feed the
SIMD variable-shift hardware.
The above is 3 uops / 3c latency on SKL.
So for AVX2 Skylake (but not Broadwell or earlier) we want this 2 uop / 2c
latency implementation:
vpbroadcastd %xmm1, %xmm1 = xmm1[0],xmm1[1],xmm1[2],xmm1[3] # 1 uop /
1c latency
vpsravd %xmm1, %xmm0, %xmm0 # 1 uop / 1c latency
on SKL. 3 / 3 on BDW and earlier.
Same for SKX AVX512 with vpsravw and so on. There are some test cases where we
use the same shift-count register multiple times, and it would be significantly
better to broadcast it and use variable-shifts instead of
count-from-the-low-element shifts.
But on Ryzen, and Broadwell and earlier, variable-shifts cost more.
(Interestingly, on Ryzen they run on a different execution port from normal
count-in-xmm shifts; still a single uop (per lane) but 3c latency and not fully
pipelined. Ryzen has shift-in-xmm shifts as efficient as immediate shifts,
unlike Intel where shift-in-xmm is always 2 uops (port5 + shift port).
KNL is horrible for pslld xmm,xmm (13c throughput/latency), but it has the same
throughput as immediate for variable shifts like VPSRLVD z,z,z. I don't totally
trust Agner's numbers for x,x shifts; maybe he only used the non-VEX encoding?
Anyway, for AVX512 we should prefer broadcast + variable-shift instead of
pmovzxb/wq / regular shift, because it's better on SKX and at least as good on
KNL. This includes 16-bit elements for AVX512BW, unlike AVX2.
(With AVX1, we don't have variable shifts so the earlier implementation with
vpsrad is our best option.)
--
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 40078] New: Poor diagnostic from MRI addlib when no prior open/create command
https://bugs.llvm.org/show_bug.cgi?id=40078 Bug ID: 40078 Summary: Poor diagnostic from MRI addlib when no prior open/create command Product: tools Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: llvm-ar Assignee: unassignedb...@nondot.org Reporter: edd-l...@mr-edd.co.uk CC: llvm-bugs@lists.llvm.org When using an MRI script such as the following, with no initial CREATE or OPEN command... ADDLIB example.a SAVE ... we see the following on stderr: llvm-ar.exe: creating llvm-ar.exe: The program issued a command but the command length is incorrect. llvm-ar exits with code 1 as I would expect, but this diagnostic isn't useful. The first line of the stderr is perhaps an indication that it's trying to create an archive with no name. -- 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 39992] llvm-dwarfdump fails to compute R_X86_64_DTPOFF64 relocation in object
https://bugs.llvm.org/show_bug.cgi?id=39992 George Rimar changed: What|Removed |Added Resolution|--- |FIXED Status|CONFIRMED |RESOLVED --- Comment #2 from George Rimar --- r349476 -- 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 40079] New: CloneMachineInstr doesn't clone machine instructions' register ties, but claims it does
https://bugs.llvm.org/show_bug.cgi?id=40079 Bug ID: 40079 Summary: CloneMachineInstr doesn't clone machine instructions' register ties, but claims it does Product: new-bugs Version: trunk Hardware: All OS: All Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: har...@gigawatt.nl CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org CloneMachineInstr creates a new machine instruction by copying all operands one by one. Copying operands does not preserve all information. In particular, copying operands one by one does not and cannot preserve register ties. CloneMachineInstr's documentation suggests that it does preserve register ties: MachineFunction.cpp:326: > /// Create a new MachineInstr which is a copy of the 'Orig' instruction, > /// identical in all ways except the instruction has no parent, prev, or next. MachineFunction.h:691: > /// Create a new MachineInstr which is a copy of \p Orig, identical in all > /// ways except the instruction has no parent, prev, or next. Bundling flags > /// are reset. > /// > /// Note: Clones a single instruction, not whole instruction bundles. > /// Does not perform target specific adjustments; consider using > /// TargetInstrInfo::duplicate() instead. Register ties are not about instruction bundles and not target-specific (even if the reason for the ties is), so I'm not seeing anything in there to say that ties should be reset. Either CloneMachineInstr should document that it does not and should not preserve this, or it should be fixed so that it does preserve it. Seen in a project based on LLVM 4.0.1, but checked against git master (f6775ea3ff7d9b047204560b02db191b6dbfb907): CloneMachineInstr (MachineFunction.cpp:329) invokes MachineInstr's copy-like-constructor. MachineInstr's constructor (MachineInstr.cpp:134) calls addOperand for each of the source instruction's operands. addOperand invokes MachineOperand's copy constructor (MachineInstr.cpp:262), but then explicitly drops ties (MachineInstr.cpp:270) and only sets up ties again when the instruction is marked so (MachineInstr.cpp:282). When the source instruction has tied imp-use registers, there is nothing to restore those ties. -- 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 40080] New: [LoopVectorizer] crash with -force-vector-width=2
https://bugs.llvm.org/show_bug.cgi?id=40080 Bug ID: 40080 Summary: [LoopVectorizer] crash with -force-vector-width=2 Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: Loop Optimizer Assignee: unassignedb...@nondot.org Reporter: pauls...@linux.vnet.ibm.com CC: llvm-bugs@lists.llvm.org Created attachment 21245 --> https://bugs.llvm.org/attachment.cgi?id=21245&action=edit reduced testcase This test case contains a loop with a load that gets a disabling (30) cost, so normally this would not get vectorized. Still, if vectorization is forced bad code is generated, which should probably be investigated: opt -mtriple=s390x-unknown-linux -mcpu=z13 -o out.opt.ll tc_LV_width2.ll -O3 -S -force-vector-width=2 -unroll-count=1 Instruction does not dominate all uses! %17 = phi <2 x double> [ %10, %pred.load.continue ], [ %16, %pred.load.if3 ] %2 = shufflevector <2 x double> %vector.recur, <2 x double> %17, <2 x i32> -- 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 40081] New: [DAGCombiner] Extend DAGCombiner::MatchRotate to handle funnel shifts
https://bugs.llvm.org/show_bug.cgi?id=40081 Bug ID: 40081 Summary: [DAGCombiner] Extend DAGCombiner::MatchRotate to handle funnel shifts Product: libraries Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: Common Code Generator Code Assignee: unassignedb...@nondot.org Reporter: llvm-...@redking.me.uk CC: llvm-bugs@lists.llvm.org, spatel+l...@rotateright.com Now that the ISD::FSHL/FSHR opcodes are available we should be able to refactor the existing rotation pattern matching logic to handle funnel shifts as well. This should also allow us to remove the X86ISelLowering's X86ISD::SHLD/SHRD matching code in combineOr. -- 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 40082] New: OpenMP Runtime testcase failures with -fno-PIC
https://bugs.llvm.org/show_bug.cgi?id=40082 Bug ID: 40082 Summary: OpenMP Runtime testcase failures with -fno-PIC Product: OpenMP Version: unspecified Hardware: Other OS: Linux Status: NEW Severity: normal Priority: P Component: Runtime Library Assignee: unassignedb...@nondot.org Reporter: stef...@ca.ibm.com CC: llvm-bugs@lists.llvm.org The following tests fail if run with -fno-PIC on PowerPC on Little Endian Linux. openmp/runtime/test/ompt/misc/control_tool.c openmp/runtime/test/ompt/synchronization/taskwait.c Once we switch to no-PIC default for PowerPC Little Endian Linux these tests will be XFAILED on that platform. Investigation is required here to fund out why they behave differently under no-PIC. -- 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 40083] New: [x86] psubus matching failure with undef elements
https://bugs.llvm.org/show_bug.cgi?id=40083
Bug ID: 40083
Summary: [x86] psubus matching failure with undef elements
Product: new-bugs
Version: unspecified
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: spatel+l...@rotateright.com
CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org
This example came up in the discussion for D55780:
unsigned long long test_sub_2(__m128i x) {
__m128i c = _mm_set1_epi8(70);
return _mm_subs_epu8(x, c)[0];
}
Currently this becomes in IR:
define i64 @test_sub_2(<2 x i64> %x) {
%t0 = bitcast <2 x i64> %x to <16 x i8>
%cmp = icmp ugt <16 x i8> %t0,
%bop = add <16 x i8> %0,
%sel = select <16 x i1> %cmp, <16 x i8> %bop, <16 x i8>
%bc = bitcast <16 x i8> %sel to <2 x i64>
%ext = extractelement <2 x i64> %bc, i32 0
ret i64 %ext
}
And that becomes this in x86 asm:
vpmaxub LCPI0_0(%rip), %xmm0, %xmm1
vpcmpeqb%xmm1, %xmm0, %xmm1
vpaddb LCPI0_1(%rip), %xmm0, %xmm0
vpand %xmm0, %xmm1, %xmm0
vmovq %xmm0, %rax
---
We want this to become psubus again, but undefs are getting in the way.
It's possible that we also want to add an IR transform to turn the
bitcast+extract into an extracting shufflevector+bitcast.
--
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 40084] New: [Win] libFuzzer: deadly signal
https://bugs.llvm.org/show_bug.cgi?id=40084
Bug ID: 40084
Summary: [Win] libFuzzer: deadly signal
Product: compiler-rt
Version: unspecified
Hardware: PC
OS: Windows NT
Status: NEW
Severity: normal
Priority: P
Component: fuzzer
Assignee: unassignedb...@nondot.org
Reporter: mikhail.strelni...@gmail.com
CC: llvm-bugs@lists.llvm.org
C:\>type fuzz.cpp
struct a
{
a * b;
int c = 0;
a() {
b = this;
}
~a() {
for (auto k = c; 0 != k;) {
}
}
};
struct e {
};
extern "C" int LLVMFuzzerTestOneInput(unsigned char const *, size_t)
try {
a _;
throw e{};
}
catch (e const &) {
return 0;
}
(compiling with
https://prereleases.llvm.org/win-snapshots/LLVM-8.0.0-r347735-win64.exe)
C:\>"C:\Program Files\LLVM\bin\clang++.exe" -O3 -fuse-ld=lld
-fsanitize=fuzzer,address fuzz.cpp -std=c++2a -o fuzz.exe && fuzz.exe
INFO: Seed: 3469642180
INFO: Loaded 1 modules (2 inline 8-bit counters): 2 [7FF7603D5448,
7FF7603D544A),
INFO: Loaded 1 PC tables (2 PCs): 2 [7FF7603AFCA0,7FF7603AFCC0),
INFO: -max_len is not provided; libFuzzer will not generate inputs larger than
4096 bytes
==14168== ERROR: libFuzzer: deadly signal
#0 0x7ff76028d424 in __sanitizer_print_stack_trace
C:\src\llvm_package_347735\llvm\projects\compiler-rt\lib\asan\asan_stack.cc:38
#1 0x7ff760235e98 in fuzzer::PrintStackTrace
C:\src\llvm_package_347735\llvm\projects\compiler-rt\lib\fuzzer\FuzzerUtil.cpp:206
#2 0x7ff760256b61 in fuzzer::Fuzzer::CrashCallback
C:\src\llvm_package_347735\llvm\projects\compiler-rt\lib\fuzzer\FuzzerLoop.cpp:237
#3 0x7ff760256b24 in fuzzer::Fuzzer::StaticCrashSignalCallback
C:\src\llvm_package_347735\llvm\projects\compiler-rt\lib\fuzzer\FuzzerLoop.cpp:209
#4 0x7ff7602312a1 in fuzzer::ExceptionHandler
C:\src\llvm_package_347735\llvm\projects\compiler-rt\lib\fuzzer\FuzzerUtilWindows.cpp
#5 0x7ff8bc7a53ab in UnhandledExceptionFilter+0x1bb
(C:\WINDOWS\System32\KERNELBASE.dll+0x1800853ab)
#6 0x7ff8c05d80ca in memset+0x1c8a
(C:\WINDOWS\SYSTEM32\ntdll.dll+0x1800a80ca)
#7 0x7ff8c05bfd25 in _C_specific_handler+0x95
(C:\WINDOWS\SYSTEM32\ntdll.dll+0x18008fd25)
#8 0x7ff8c05d467e in _chkstk+0x11e
(C:\WINDOWS\SYSTEM32\ntdll.dll+0x1800a467e)
#9 0x7ff8c0534bee in RtlWalkFrameChain+0x14be
(C:\WINDOWS\SYSTEM32\ntdll.dll+0x180004bee)
#10 0x7ff8c05d33ed in KiUserExceptionDispatcher+0x2d
(C:\WINDOWS\SYSTEM32\ntdll.dll+0x1800a33ed)
#11 0x7ff7602aeef1 in LLVMFuzzerTestOneInput+0x181
(C:\fuzz.exe+0x14007eef1)
#12 0x7ff760369f8f in _CallSettingFrame
d:\agent\_work\3\s\src\vctools\crt\vcruntime\src\eh\amd64\handlers.asm:49
#13 0x7ff760348bbe in __FrameHandler3::FrameUnwindToState
d:\agent\_work\3\s\src\vctools\crt\vcruntime\src\eh\frame.cpp:1211
#14 0x7ff76030a573 in __FrameHandler3::FrameUnwindToEmptyState
d:\agent\_work\3\s\src\vctools\crt\vcruntime\src\eh\risctrnsctrl.cpp:236
#15 0x7ff760349d91 in __InternalCxxFrameHandler<__FrameHandler3>
d:\agent\_work\3\s\src\vctools\crt\vcruntime\src\eh\frame.cpp:312
#16 0x7ff76030b0b8 in __CxxFrameHandler3
d:\agent\_work\3\s\src\vctools\crt\vcruntime\src\eh\risctrnsctrl.cpp:262
#17 0x7ff8c05d46fe in _chkstk+0x19e
(C:\WINDOWS\SYSTEM32\ntdll.dll+0x1800a46fe)
#18 0x7ff8c053600b in RtlUnwindEx+0x51b
(C:\WINDOWS\SYSTEM32\ntdll.dll+0x18000600b)
#19 0x7ff8c05bfd68 in _C_specific_handler+0xd8
(C:\WINDOWS\SYSTEM32\ntdll.dll+0x18008fd68)
#20 0x7ff8c05d467e in _chkstk+0x11e
(C:\WINDOWS\SYSTEM32\ntdll.dll+0x1800a467e)
#21 0x7ff8c0534bee in RtlWalkFrameChain+0x14be
(C:\WINDOWS\SYSTEM32\ntdll.dll+0x180004bee)
#22 0x7ff8c05389e5 in RtlRaiseException+0x315
(C:\WINDOWS\SYSTEM32\ntdll.dll+0x1800089e5)
#23 0x7ff8bc775298 in RaiseException+0x68
(C:\WINDOWS\System32\KERNELBASE.dll+0x180055298)
#24 0x7ff760309fb0 in _CxxThrowException
d:\agent\_work\3\s\src\vctools\crt\vcruntime\src\eh\throw.cpp:129
#25 0x7ff7602aeeb0 in LLVMFuzzerTestOneInput+0x140
(C:\fuzz.exe+0x14007eeb0)
#26 0x7ff76025854f in fuzzer::Fuzzer::ExecuteCallback
C:\src\llvm_package_347735\llvm\projects\compiler-rt\lib\fuzzer\FuzzerLoop.cpp:571
#27 0x7ff760259f86 in fuzzer::Fuzzer::ReadAndExecuteSeedCorpora
C:\src\llvm_package_347735\llvm\projects\compiler-rt\lib\fuzzer\FuzzerLoop.cpp:761
#28 0x7ff76025a682 in fuzzer::Fuzzer::Loop
C:\src\llvm_package_347735\llvm\projects\compiler-rt\lib\fuzzer\FuzzerLoop.cpp:806
#29 0x7ff76026b4f8 in fuzzer::FuzzerDriver
C:\src\llvm_package_347735\llvm\projects\compiler-rt\lib\fuzzer\FuzzerDriver.cpp:764
#30 0x7ff760231022 in main
C:\src\llvm_package_347735\llvm\projects\compiler-rt\lib\fuzzer\FuzzerMain.cpp:20
#31 0x7ff760309c77 in __scrt_common_main_seh
d:\agent\_work\3\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl:288
#32 0x7ff8c0307e93 in BaseThreadInitThunk+0x13
(C:\WINDOWS\System32
[llvm-bugs] [Bug 40085] New: Incompatibility when inheriting MSVC's STL tuple
https://bugs.llvm.org/show_bug.cgi?id=40085
Bug ID: 40085
Summary: Incompatibility when inheriting MSVC's STL tuple
Product: clang
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: normal
Priority: P
Component: C++
Assignee: unassignedclangb...@nondot.org
Reporter: gufi...@gmail.com
CC: blitzrak...@gmail.com, dgre...@apple.com,
erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org,
richard-l...@metafoo.co.uk
Created attachment 21246
--> https://bugs.llvm.org/attachment.cgi?id=21246&action=edit
Compilation output containing the error
Clang is incompatible with some uses of std::tuple using the visual studio STL.
More specifically, when inheriting from it.
struct Foo : private std::tuple {
void bar() {
std::get<0>(*this) = 1;
}
};
int main() {
Foo f;
f.bar();
}
The code above compiles perfectly using GCC (libstdc++), Clang on linux
(libstdc++), and MSVC (using it's own STL).
The mix of clang and MSVC's STL result the compilation error sent as
attachement.
--
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 40086] New: llvm-objdump failed to compute relocation: R_X86_64_DTPOFF64
https://bugs.llvm.org/show_bug.cgi?id=40086
Bug ID: 40086
Summary: llvm-objdump failed to compute relocation:
R_X86_64_DTPOFF64
Product: tools
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: normal
Priority: P
Component: llvm-objdump
Assignee: unassignedb...@nondot.org
Reporter: jh7370.2...@my.bristol.ac.uk
CC: llvm-bugs@lists.llvm.org
This is very similar to bug 39992, but the fix for that issue did not fix this
issue for me:
For a simple input like the following:
// bar.cpp
thread_local int bar = 42;
int main(){
return bar;
}
Compiling with clang and debug information, and running llvm-objdump produces
an error:
C:\llvm\build\Debug\bin\clang.exe --target=x86_64-pc-linux -c bar.cpp -g
C:\llvm\build\Debug\bin\llvm-objdump bar.o -d -S
bar.o: file format ELF64-x86-64
Disassembly of section .text:
main:
error: failed to compute relocation: R_X86_64_DTPOFF64, Invalid data was
encountered while parsing the file
; int main(){
0: 55 pushq %rbp
...
I'm guessing the issue is a similar cause as bug 39992, but I haven't dug into
it yet.
--
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 40065] Add llvm-symbolizer component to tools product
https://bugs.llvm.org/show_bug.cgi?id=40065 Reid Kleckner changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Reid Kleckner --- Component created, everything refiled, I'd say this is done. -- 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 40087] New: Clang rejects well-formed C11 program using [*]
https://bugs.llvm.org/show_bug.cgi?id=40087
Bug ID: 40087
Summary: Clang rejects well-formed C11 program using [*]
Product: clang
Version: trunk
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: anders.granlun...@gmail.com
CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org,
neeil...@live.com, richard-l...@metafoo.co.uk
Conside the following program (prog.c):
void f(int a[sizeof(int [*])]);
int main()
{
}
Compile it with the following command line:
clang prog.c -std=c11 -pedantic-errors
It incorrectly gives the following error:
error: star modifier used outside of function prototype
Compiling the program should give no error since it is well-formed according to
C11.
--
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 40088] New: Accepts ill-formed C11 program with redundant extern in declaration that does not declare anything.
https://bugs.llvm.org/show_bug.cgi?id=40088
Bug ID: 40088
Summary: Accepts ill-formed C11 program with redundant extern
in declaration that does not declare anything.
Product: clang
Version: trunk
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: anders.granlun...@gmail.com
CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org,
neeil...@live.com, richard-l...@metafoo.co.uk
Test case (prog.c)
int main()
{
struct S;
extern struct S;
}
Compilation command:
clang prog.c -std=c11 -pedantic-errors
Expected output:
An error message since we are using -pedantic-errors and the second
declaration does not declare anything.
Actual output:
No error message.
Note:
gcc correctly reject this program with an error message.
--
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 40089] New: Bad errors if exceeding constexpr iteration limit
https://bugs.llvm.org/show_bug.cgi?id=40089
Bug ID: 40089
Summary: Bad errors if exceeding constexpr iteration limit
Product: clang
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: blub...@gmail.com
CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org,
neeil...@live.com, richard-l...@metafoo.co.uk
Input:
constexpr int x(int y)
{
return y;
}
constexpr int z()
{
for (int i=0;i<0x7fff;i++)
if (x(i) != x(i)) return 1;
return 0;
}
template int ee() { return e; }
int p() { return ee(); }
Expected: Anything containing
:2:1: note: constexpr evaluation hit maximum step limit; possible
infinite loop?
{
^
:8:21: note: in call to 'x(209714)'
if (x(i) != x(i)) return 1;
^
Actual:
:14:18: error: no matching function for call to 'ee'
int p() { return ee(); }
^~~
:12:21: note: candidate template ignored: invalid explicitly-specified
argument for template parameter 'e'
template int ee() { return e; }
^
and nothing else.
GCC gives much better results:
: In function 'int p()':
:14:26: error: no matching function for call to 'ee()'
int p() { return ee(); }
^
:12:21: note: candidate: 'template int ee()'
template int ee() { return e; }
^~
:12:21: note: template argument deduction/substitution failed:
:14:22: in 'constexpr' expansion of 'z()'
:7:5: error: 'constexpr' loop iteration count exceeds limit of 262144
(use -fconstexpr-loop-limit= to increase the limit)
for (int i=0;i<0x7fff;i++)
^~~
:14:22: note: in template argument for type 'int'
int p() { return ee(); }
~^~
Bonus: Replace the last line with
template int ee();
to get bad errors from both Clang and GCC. Alternatively,
constexpr bool w = z();
yields good errors from both; inlining x() also gives good errors. (GCC
mentions -fconstexpr-loop-limit=, but Clang doesn't mention -fconstexpr-steps=;
not sure if that's intentional.)
--
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 40090] New: [x86-64] missed optimization: can use the zero flag which is set by BSR
https://bugs.llvm.org/show_bug.cgi?id=40090
Bug ID: 40090
Summary: [x86-64] missed optimization: can use the zero flag
which is set by BSR
Product: new-bugs
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: arthur.j.odw...@gmail.com
CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org
I was trying to trick Clang into generating optimal code for a 128-bit "count
leading zeros" function. I started with the most naive version:
using u128 = __uint128_t;
using u64 = uint64_t;
int countleadingzerosA(u128 x)
{
return (x >> 64) ? __builtin_clzll(u64(x >> 64)) + 64
: __builtin_clzll(u64(x));
}
testq %rsi, %rsi
je .LBB1_2
bsrq %rsi, %rax
xorl $63, %eax
orl $64, %eax
retq
.LBB1_2:
bsrq %rdi, %rax
xorl $63, %eax
retq
By examining the generated code (-O3), I was able to produce this version:
int countleadingzerosB(u128 x)
{
int lo = 63 - __builtin_clzll(u64(x)) + 64;
int hi = 63 - __builtin_clzll(u64(x >> 64));
return 63 - ((x >> 64) ? hi : lo);
}
bsrq %rdi, %rax
xorl $64, %eax
bsrq %rsi, %rcx
testq %rsi, %rsi
cmovel %eax, %ecx
movl $63, %eax
subl %ecx, %eax
retq
I believe there are two missed optimizations here that MIGHT be relatively
straightforward to implement.
Number 1: According to https://www.felixcloutier.com/x86/BSR.html the
instruction `bsrq %rsi, %rcx` sets ZF in exactly the same way as `testq %rsi,
%rsi`, so the `testq` instruction is redundant.
Number 2: If dataflow can remember that the value in %rax is in the range
[0..63], then it should be able to apply the same SUB-to-XOR strength reduction
that it did in countleadingzerosA: we can replace the final two instructions
with `xorl $63, %ecx; movl %ecx, %eax` and then the `movl` can be eliminated by
register allocation.
I can easily work around number 2 by just doing `return 63 ^ ...` instead of
`return 63 - ...`; I was just surprised that the compiler would do SUB-to-XOR
in some places but then seemingly miss it in others.
--
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 40091] New: SimplifyDemandedVectorElts' handling of undef
https://bugs.llvm.org/show_bug.cgi?id=40091
Bug ID: 40091
Summary: SimplifyDemandedVectorElts' handling of undef
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Common Code Generator Code
Assignee: unassignedb...@nondot.org
Reporter: david.gr...@arm.com
CC: llvm-bugs@lists.llvm.org, llvm-...@redking.me.uk
;target datalayout = "e-m:e-i8:8:32-i16:16:32-i64:64-i128:128-n32:64-S128"
;target triple = "aarch64-arm-none-eabi"
define i64 @test(i64 %aa) {
entry:
%a = bitcast i64 %aa to <1 x i64>
%k = icmp sgt <1 x i64> %a, zeroinitializer
%l = zext <1 x i1> %k to <1 x i64>
%o = and <1 x i64> %l, %a
%p = xor <1 x i64> %l,
%q = and <1 x i64> %p,
%r = or <1 x i64> %q, %o
%s = bitcast <1 x i64> %r to <8 x i8>
%t = shufflevector <8 x i8> %s, <8 x i8> %s, <8 x i32>
%u = bitcast <8 x i8> %t to i64
ret i64 %u
}
I would expect this to always return 0x8989898989898989 (the third element of
that big constant in there), but currently returns 0x. It seems
that the icmp is folded to undef (perhaps because it is not needed by demand
bits), which then gets folded through into pretty much everything else (even
through the zext). I am under the impression that undef should be bitwise (not
vector-lane-wise), but I may be wrong there.
Bisects back to r349264, which adds OR handling to SimplifyDemandedVectorElts
(but it looks like a bit of a knock-on effect).
--
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 40092] New: SROA segfault.
https://bugs.llvm.org/show_bug.cgi?id=40092 Bug ID: 40092 Summary: SROA segfault. Product: new-bugs Version: 7.0 Hardware: Macintosh OS: All Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: jeffersoncarpent...@gmail.com CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org Created attachment 21248 --> https://bugs.llvm.org/attachment.cgi?id=21248&action=edit Source file that when compiled causes clang++ to crash. The attached code file causes clang++ to segfault when I compile it with the command: clang++ -std=c++17 -O3 -c ./crash.cpp -o crash.o -- 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 40093] New: Crash while building libc++ poisoned test program
https://bugs.llvm.org/show_bug.cgi?id=40093 Bug ID: 40093 Summary: Crash while building libc++ poisoned test program Product: clang Version: trunk Hardware: Macintosh OS: MacOS X Status: NEW Severity: normal Priority: P Component: C++ Assignee: unassignedclangb...@nondot.org Reporter: mclow.li...@gmail.com CC: blitzrak...@gmail.com, dgre...@apple.com, erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org, richard-l...@metafoo.co.uk Created attachment 21250 --> https://bugs.llvm.org/attachment.cgi?id=21250&action=edit Crash log While testing a proposed change to libc++ (https://reviews.llvm.org/D55777), clang crashed. The test in question was "test/support/test.support/test_poisoned_hash_helper.pass.cpp". I have attached: 1) The console log 2) The preprocessed source 3) The run script 4) The crash log -- 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 40063] memcmp with constant string arguments produces wrong result
https://bugs.llvm.org/show_bug.cgi?id=40063 Eli Friedman changed: What|Removed |Added CC||efrie...@codeaurora.org Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #2 from Eli Friedman --- This was fixed in r330656. -- 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 28668] [InstCombine] missing folds for bit manipulation intrinsics
https://bugs.llvm.org/show_bug.cgi?id=28668
Sanjay Patel changed:
What|Removed |Added
Fixed By Commit(s)||r277694, r349530
CC||nikita@gmail.com
Resolution|--- |FIXED
Status|NEW |RESOLVED
--- Comment #3 from Sanjay Patel ---
This fixes the ctlz/cttz parts of this bug:
https://reviews.llvm.org/rL349530
My comments ("all ones") in the description were incorrect - these should be
the correct folds:
define i1 @ctlz_cmp(i32 %a) {
%cmp = icmp slt i32 %a, 0
ret i1 %cmp
}
define i1 @cttz_cmp(i32 %a) {
%1 = and i32 %a, 1
%cmp = icmp ne i32 %1, 0
ret i1 %cmp
}
--
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 39600] [REGRESSION] clang hangs or crashes
https://bugs.llvm.org/show_bug.cgi?id=39600 Bruno Ricci changed: What|Removed |Added CC||bruno.bugs.cont...@gmail.co ||m Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Bruno Ricci --- Seems to be fixed in trunk (tested with r349259) -- 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 40094] New: lld-link ignores IMAGE_COMDAT_SELECT_* attributes
https://bugs.llvm.org/show_bug.cgi?id=40094 Bug ID: 40094 Summary: lld-link ignores IMAGE_COMDAT_SELECT_* attributes Product: lld Version: unspecified Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: COFF Assignee: unassignedb...@nondot.org Reporter: r...@google.com CC: llvm-bugs@lists.llvm.org lld-link currently ignores "Selection field" of a COMDAT symbol which is described in the spec: https://docs.microsoft.com/en-us/windows/desktop/debug/pe-format#comdat-sections-object-only lld-link's current behavior is IMAGE_COMDAT_SELECT_ANY. So, there are two or more COMDAT section, lld-link just picks any section from them, even though MSVC link.exe may print out an error if their attributes are not of SELECT_ANY. This is simply a missing feature and needs to be implemented to lld-link. -- 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 11929 in oss-fuzz: llvm/clang-fuzzer: Stack-overflow in ConvertDeclSpecToType
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevlieg...@apple.com, igm...@gmail.com, eney...@google.com, llvm-b...@lists.llvm.org, j...@chromium.org, v...@apple.com, mitchphi...@outlook.com, xpl...@gmail.com, akils...@apple.com Labels: ClusterFuzz Stability-Memory-AddressSanitizer Reproducible Engine-libfuzzer Proj-llvm Reported-2018-12-19 Type: Bug New issue 11929 by ClusterFuzz-External: llvm/clang-fuzzer: Stack-overflow in ConvertDeclSpecToType https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=11929 Detailed report: https://oss-fuzz.com/testcase?key=5646780918661120 Project: llvm Fuzzer: libFuzzer_llvm_clang-fuzzer Fuzz target binary: clang-fuzzer Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: Stack-overflow Crash Address: 0x7fff9d25bfb8 Crash State: ConvertDeclSpecToType GetDeclSpecTypeForDeclarator clang::Sema::GetTypeForDeclarator Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201807230239:201807240240 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5646780918661120 Issue filed automatically. See https://github.com/google/oss-fuzz/blob/master/docs/reproducing.md for instructions to reproduce this bug locally. When you fix this bug, please * mention the fix revision(s). * state whether the bug was a short-lived regression or an old bug in any stable releases. * add any other useful information. This information can help downstream consumers. If you need to contact the OSS-Fuzz team with a question, concern, or any other feedback, please file an issue at https://github.com/google/oss-fuzz/issues. -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 40095] New: STL iterator std::copy/for loop produces inefficient code
https://bugs.llvm.org/show_bug.cgi?id=40095
Bug ID: 40095
Summary: STL iterator std::copy/for loop produces inefficient
code
Product: libraries
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: Loop Optimizer
Assignee: unassignedb...@nondot.org
Reporter: husseyde...@gmail.com
CC: llvm-bugs@lists.llvm.org
This code was tested with libstdc++ on Godbolt.
>From looking at Godbolt versions, I noticed that clang 6.0 will convert this
code:
unsigned copy_equal(const std::vector &__restrict vec)
{
unsigned ret;
unsigned char *__restrict result = reinterpret_cast(&ret);
auto last = vec.cbegin() + sizeof(unsigned);
auto first = vec.cbegin();
while (first != last) {
*result = *first;
++first;
++result;
}
return ret;
}
as expected to this (clang -O3 -m32):
copy_equal(std::vector > const&):
# @copy_equal(std::vector >
const&)
mov eax, dword ptr [esp + 4]
mov eax, dword ptr [eax]
mov eax, dword ptr [eax]
ret
GCC has done this same optimization since 4.9, although it aligns the stack
first.
h
unsigned copy_reverse(const std::vector &__restrict vec)
{
unsigned ret;
unsigned char *__restrict result = reinterpret_cast(&ret);
auto last = vec.cbegin() + sizeof(unsigned);
auto first = vec.cbegin();
for (auto n = last - first; n > 0; --n) {
*result = *first;
++first;
++result;
}
return ret;
}
we get this:
copy_reverse(std::vector >
const&):# @copy_reverse(std::vector > const&)
xor eax, eax
testal, al
jne .LBB0_1
pushebx
pushesi
pusheax
mov eax, dword ptr [esp + 16]
mov edx, 4
mov ecx, esp
cmp edx, 32
mov eax, dword ptr [eax]
jb .LBB0_6
xor esi, esi
.LBB0_4:# =>This Inner Loop Header: Depth=1
movups xmm0, xmmword ptr [eax + esi]
movups xmm1, xmmword ptr [eax + esi + 16]
movups xmmword ptr [esp + esi], xmm0
movups xmmword ptr [esp + esi + 16], xmm1
add esi, 32
jne .LBB0_4
testedx, edx
je .LBB0_8
.LBB0_6:
lea edx, [eax + 4]
xor esi, esi
sub edx, ecx
sub edx, eax
lea edx, [esp + edx]
.LBB0_7:# =>This Inner Loop Header: Depth=1
movzx ebx, byte ptr [eax + esi]
mov byte ptr [ecx + esi], bl
inc esi
cmp edx, esi
jne .LBB0_7
.LBB0_8:
mov eax, dword ptr [esp]
add esp, 4
pop esi
pop ebx
ret
.LBB0_1:
ret
or, with -mno-sse,
copy_reverse(std::vector >
const&):# @copy_reverse(std::vector > const&)
xor eax, eax
testal, al
jne .LBB0_1
pushebx
pusheax
mov ecx, dword ptr [esp + 12]
mov edx, 4
mov ecx, dword ptr [ecx]
.LBB0_3:# =>This Inner Loop Header: Depth=1
movzx ebx, byte ptr [ecx + eax]
mov byte ptr [esp + eax], bl
inc eax
cmp edx, eax
jne .LBB0_3
mov eax, dword ptr [esp]
add esp, 4
pop ebx
ret
While the recommended way is the first one (even suggested on
cppreference.com), the second one is important because libstdc++ uses that for
their copy iterator on STL containers:
template <>
struct __copy_move {
template
static _OI __copy_m(_II __first, _II __last, _OI __result) {
typedef typename iterator_traits<_II>::difference_type _Distance;
for (_Distance __n = __last - __first; __n > 0; --__n) {
*__result = *__first;
++__first;
++__result;
}
return __result;
}
};
As a result, std::copy on libstdc++ is inefficient here.
This affects all targets, although x86_64 seems to generate slightly better
code than others, and i386 generating slightly worse code than the others.
x86_64 output:
copy_reverse(std::vector >
const&):# @copy_reverse(std::vector > const&)
mov rax, qword ptr [rdi]
mov cl, byte ptr [rax]
mov byte ptr [rsp - 4], cl
mov cl, byte ptr [rax + 1]
mov byte ptr [rsp - 3], cl
mov cl, byte ptr [rax + 2]
mov byte ptr [rsp - 2], cl
mov al, byte ptr [rax + 3]
mov byte ptr [rsp - 1], al
mov eax, dword ptr [rsp - 4]
ret
Comparison: https://godbolt.org/z/wwr8Sz
--
You are receiving this mail because:
You are on the CC list for the bug._
[llvm-bugs] Issue 11931 in oss-fuzz: llvm/clang-format-fuzzer: Null-dereference READ in clang::format::AnnotatingParser::consumeToken
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevlieg...@apple.com, igm...@gmail.com, eney...@google.com, llvm-b...@lists.llvm.org, j...@chromium.org, v...@apple.com, mitchphi...@outlook.com, xpl...@gmail.com, akils...@apple.com Labels: ClusterFuzz Stability-Memory-AddressSanitizer Reproducible Engine-libfuzzer Proj-llvm Reported-2018-12-19 Type: Bug New issue 11931 by ClusterFuzz-External: llvm/clang-format-fuzzer: Null-dereference READ in clang::format::AnnotatingParser::consumeToken https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=11931 Detailed report: https://oss-fuzz.com/testcase?key=5157188067131392 Project: llvm Fuzzer: libFuzzer_llvm_clang-format-fuzzer Fuzz target binary: clang-format-fuzzer Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: Null-dereference READ Crash Address: 0x0010 Crash State: clang::format::AnnotatingParser::consumeToken clang::format::AnnotatingParser::parseLine clang::format::TokenAnnotator::annotate Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201709130450:201709140449 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5157188067131392 Issue filed automatically. See https://github.com/google/oss-fuzz/blob/master/docs/reproducing.md for instructions to reproduce this bug locally. When you fix this bug, please * mention the fix revision(s). * state whether the bug was a short-lived regression or an old bug in any stable releases. * add any other useful information. This information can help downstream consumers. If you need to contact the OSS-Fuzz team with a question, concern, or any other feedback, please file an issue at https://github.com/google/oss-fuzz/issues. -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 40096] New: Clang source code incompatibility with C++20
https://bugs.llvm.org/show_bug.cgi?id=40096
Bug ID: 40096
Summary: Clang source code incompatibility with C++20
Product: clang
Version: unspecified
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: C++
Assignee: unassignedclangb...@nondot.org
Reporter: 1998zhan...@gmail.com
CC: blitzrak...@gmail.com, dgre...@apple.com,
erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org,
richard-l...@metafoo.co.uk
Created attachment 21253
--> https://bugs.llvm.org/attachment.cgi?id=21253&action=edit
p1008r1.pdf
A paper(see attachment p1008r1.pdf) voted into the C++20 working draft changes
the definition of aggregate such that classes with any user-declared ctors are
no longer aggregates.
The MSVC team builds Clang regularly to detect regressions, BTW, we always use
the latest version, and found this failure under our build configuration with
the -std:c++latest switch. We are using the following backwards-compatible
patch(see clangllvm_latest_c2127.patch) going forward, which you are free to
upstream it if C+20 compatibility is on the library's radar.
You can reproduce this issue on the next released MSVC.
Repro steps:
1 git clone -c core.autocrlf=false https://github.com/llvm-mirror/llvm
D:\llvm\src\
2 git clone -c core.autocrlf=false https://github.com/llvm-mirror/clang
D:\llvm\src\tools\clang
3 open a VS 2017 x86 command prompt and browse to D:\llvm
4 set _CL_=/wd4996 /D_HAS_AUTO_PTR_ETC=1 /D_HAS_TR1_NAMESPACE=1 /std:c++latest
5 mkdir build_x86 && pushd build_x86
6 cmake -G "Visual Studio 15 2017" -DCMAKE_SYSTEM_VERSION=10.0.17134.0 ..\src\
7 msbuild /maxcpucount:4 /p:Platform=Win32 /p:Configuration=RelWithDebInfo
build_x86\ALL_BUILD.vcxproj /t:Rebuild
Failures:
D:\llvm\src\tools\clang\lib\Tooling\Refactoring\ASTSelection.cpp(354): error
C2440: 'initializing': cannot convert from 'initializer list' to
'`anonymous-namespace'::SelectedNodeWithParents'
D:\llvm\src\tools\clang\lib\Tooling\Refactoring\ASTSelection.cpp(355): note: No
constructor could take the source type, or constructor overload resolution was
ambiguous
D:\llvm\src\tools\clang\lib\Tooling\Refactoring\ASTSelection.cpp(362): error
C2440: 'initializing': cannot convert from 'initializer list' to
'`anonymous-namespace'::SelectedNodeWithParents'
D:\llvm\src\tools\clang\lib\Tooling\Refactoring\ASTSelection.cpp(363): note: No
constructor could take the source type, or constructor overload resolution was
ambiguous
clangllvm_latest_c2440.patch：
diff --git a/lib/Tooling/Refactoring/ASTSelection.cpp
b/lib/Tooling/Refactoring/ASTSelection.cpp
index 7123fc3..b8f996d 100644
--- a/lib/Tooling/Refactoring/ASTSelection.cpp
+++ b/lib/Tooling/Refactoring/ASTSelection.cpp
@@ -250,8 +250,6 @@ static bool hasAnyDirectChildrenWithKind(const
SelectedASTNode &Node,
namespace {
struct SelectedNodeWithParents {
- SelectedNodeWithParents(SelectedNodeWithParents &&) = default;
- SelectedNodeWithParents &operator=(SelectedNodeWithParents &&) = default;
SelectedASTNode::ReferenceType Node;
llvm::SmallVector Parents;
diff --git a/tools/clang-refactor/TestSupport.h
b/tools/clang-refactor/TestSupport.h
index 61aa660..779006b 100644
--- a/tools/clang-refactor/TestSupport.h
+++ b/tools/clang-refactor/TestSupport.h
@@ -59,9 +59,6 @@ struct TestSelectionRangesInFile {
};
std::vector GroupedRanges;
- TestSelectionRangesInFile(TestSelectionRangesInFile &&) = default;
- TestSelectionRangesInFile &operator=(TestSelectionRangesInFile &&) =
default;
-
bool foreachRange(const SourceManager &SM,
llvm::function_ref Callback) const;
--
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
