[llvm-bugs] [Bug 45689] Failure to optimize away range check of modulo based on known ranges
https://bugs.llvm.org/show_bug.cgi?id=45689 Florian Hahn changed: What|Removed |Added Status|NEW |RESOLVED CC||florian_h...@apple.com Resolution|--- |FIXED --- Comment #1 from Florian Hahn --- This looks fixed in current trunk, both clang & GCC produce f(int, int): mov eax, 1 ret Please re-open if I missed anything. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 49362] New: Should --weaken-symbol(s) be prevented from marking undef globals as weak?
https://bugs.llvm.org/show_bug.cgi?id=49362 Bug ID: 49362 Summary: Should --weaken-symbol(s) be prevented from marking undef globals as weak? Product: tools Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: llvm-objcopy/strip Assignee: unassignedb...@nondot.org Reporter: jh7370.2...@my.bristol.ac.uk CC: alexander.v.shaposhni...@gmail.com, jake.h.ehrl...@gmail.com, jh7370.2...@my.bristol.ac.uk, llvm-bugs@lists.llvm.org, ruppre...@google.com GNU objcopy --weaken-symbol does not change mentioned symbols to STB_WEAK binding if they are undefined. This means --weaken-symbol=globalundef will do nothing. For llvm-objcopy, if a symbol is explicitly requested by --weaken-symbol it goes ahead with it, even for undefined symbols. This seems like a reasonable thing to do on the surface - the user has asked to do something so we should let them (plus there's no other way to convert a global undef to a weak). However, it gets more complicated when you consider interactions with --regex and --wildcard: it a user specifies --weaken-symbol=.*, should it change weak undefined symbols? If there are any undefined symbols, they'll become weak undefined symbols, which means there may be problems at link time. What do people think? I'm inclined to leave this difference in place, but am happy to here the opinions of 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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 49363] New: [AMDGPU][MC][GFX9+] VOP3P op_sel_hi should be set to 1 for unused operands
https://bugs.llvm.org/show_bug.cgi?id=49363 Bug ID: 49363 Summary: [AMDGPU][MC][GFX9+] VOP3P op_sel_hi should be set to 1 for unused operands Product: libraries Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: Backend: AMDGPU Assignee: unassignedb...@nondot.org Reporter: dpreobrazhen...@luxoft.com CC: llvm-bugs@lists.llvm.org This is required to produce the same code as generated by sp3. Also llvm assembler should be able to decode VOP3P instructions for any op_sel_hi values. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 49313] relative refstring.h include in libcxxabi makes too strong assumptions
https://bugs.llvm.org/show_bug.cgi?id=49313 Nico Weber changed: What|Removed |Added Fixed By Commit(s)||https://reviews.llvm.org/rG ||72b18a86e11ebc970be96a8c2b1 ||1aa3a31c14c5d 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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 49273] ConstantRangeTest.cpp missing things in "exhaustive" test
https://bugs.llvm.org/show_bug.cgi?id=49273 Paul Robinson changed: What|Removed |Added Fixed By Commit(s)||2b729548f00bcab8c4dc6967bca ||0e6661324f27e Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #3 from Paul Robinson --- (In reply to Nikita Popov from comment #2) > This issues will be resolved by https://reviews.llvm.org/D88356, which > replaces the fragile manual range construction logic in this test with a > more generic approach. Resolved by https://reviews.llvm.org/rG2b729548f00bcab8c4dc6967bca0e6661324f27e -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 49364] New: llvm-objcopy should remove .symtab_shndx if enough symbols are removed
https://bugs.llvm.org/show_bug.cgi?id=49364 Bug ID: 49364 Summary: llvm-objcopy should remove .symtab_shndx if enough symbols are removed Product: tools Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: llvm-objcopy/strip Assignee: unassignedb...@nondot.org Reporter: jh7370.2...@my.bristol.ac.uk CC: alexander.v.shaposhni...@gmail.com, jake.h.ehrl...@gmail.com, jh7370.2...@my.bristol.ac.uk, llvm-bugs@lists.llvm.org, ruppre...@google.com llvm-objcopy is intended to emit the SHT_SYMTAB_SHNDX table if and only if it is required. The table is required if at least one section with an index >= SHN_LORESERVE has at least one symbol. When adding/removing sections, or when adding new symbols, this process appears to work correctly. However, if all symbols in sections with index >= SHN_LORESERVE are removed (but not the sections themselves), llvm-objcopy still emits the .symtab_shndx section. The problem is that the `HasSymbol` section member, which is used to identify whether a section with index >= SHN_LORESERVE should cause emission of the SHT_SYMTAB_SHNDX section, is not updated after a symbol has been removed. Consequently, the check to see whether the table should be added spuriously thinks it should. Running llvm-objcopy without any switches on the output of an operation that should have removed the table, but didn't, results in the table being discarded. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 49365] New: x86 code generator uses shld/shrd incorrectly
https://bugs.llvm.org/show_bug.cgi?id=49365 Bug ID: 49365 Summary: x86 code generator uses shld/shrd incorrectly Product: clang Version: 8.0 Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: C Assignee: unassignedclangb...@nondot.org Reporter: ap...@cryptogams.org CC: blitzrak...@gmail.com, dgre...@apple.com, erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org, richard-l...@metafoo.co.uk Created attachment 24576 --> https://bugs.llvm.org/attachment.cgi?id=24576&action=edit minimal reproducer code snippet Hi, Even though I've clicked on version 8.0 as problematic, the problem was observed even with clang versions 9, 10, and 11... On a potentially related note, when the attached snippet is compiled separately, it doesn't matter if I ask for 32- or 64-bit code. While in real-life application, when the subroutine is declared static and can be inlined, only the 32-bit build appears to be affected by the bug. (Well, with exception for clang 11, which did manage to compile even 32-bit application correctly.) While the attached reproducer snippet compiles to 'shld' instruction, in the course of distilling the problem I could observe a similar behaviour even with 'shrd'. Moreover, at some point I even observed the compiler generating correct code if I removed the last '&(BITS-1)' operation. (Yes, thus subjecting it to undefined behaviour.) The underlying problem appears to be that it's assumed that 'shld'/'shrd' would handle %cl==64 by performing an actual 64-bit shift. I'm not claiming that the assumption is actually made, only that it appears that way judging from generated machine code:-) The rest of the details is in the commentary section of the attached snippet. Cheers. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 49366] New: CGRecordLayoutBuilder.cpp:747 assert triggered when capturing a VLA in a untied task
https://bugs.llvm.org/show_bug.cgi?id=49366
Bug ID: 49366
Summary: CGRecordLayoutBuilder.cpp:747 assert triggered when
capturing a VLA in a untied task
Product: OpenMP
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Clang Compiler Support
Assignee: unassignedclangb...@nondot.org
Reporter: rpena...@bsc.es
CC: llvm-bugs@lists.llvm.org
The following code triggers the assert
https://github.com/llvm/llvm-project/blob/a01a406bba8ac624a876f8d5720e1d4949a5b0fa/clang/lib/CodeGen/CGRecordLayoutBuilder.cpp#L747
void foo(int n) {
#pragma omp task untied
{
int array[n];
}
}
Assertion `Prior->FD->hasAttr() && "should not have reused
this field's tail padding"' failed.
PLEASE submit a bug report to mailto:pm-to...@bsc.es and include the crash
backtrace, preprocessed source, and associated run script.
Stack dump:
0. Program arguments: /home/user/llvm-mono/build/bin/clang-13 -cc1 -triple
x86_64-unknown-linux-gnu -emit-obj -mrelax-all --mrelax-relocations
-disable-free -main-file-name t1.c -mrelocation-model static
-mframe-pointer=all -fmath-errno -fno-rounding-math -mconstructor-aliases
-munwind-tables -target-cpu x86-64 -tune-cpu generic -fno-split-dwarf-inlining
-debugger-tuning=gdb -fcoverage-compilation-dir=/home/user/tmp -resource-dir
/home/user/llvm-mono/build/lib/clang/13.0.0 -internal-isystem
/usr/local/include -internal-isystem
/home/user/llvm-mono/build/lib/clang/13.0.0/include -internal-externc-isystem
/usr/include/x86_64-linux-gnu -internal-externc-isystem /include
-internal-externc-isystem /usr/include -fdebug-compilation-dir=/home/user/tmp
-ferror-limit 19 -fopenmp -fopenmp-cuda-parallel-target-regions
-fgnuc-version=4.2.1 -fcolor-diagnostics -faddrsig -o /tmp/t1-71672c.o -x c
t1.c
1. parser at end of file
2. Per-file LLVM IR generation
3. t1.c:1:6: Generating code for declaration 'foo'
Kind regards,
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 49367] New: [AMDGPU][MC][GFX908][GFX90A][GFX10+] Missing v_pk_fmac_f16_dpp
https://bugs.llvm.org/show_bug.cgi?id=49367 Bug ID: 49367 Summary: [AMDGPU][MC][GFX908][GFX90A][GFX10+] Missing v_pk_fmac_f16_dpp Product: libraries Version: trunk Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: Backend: AMDGPU Assignee: unassignedb...@nondot.org Reporter: dpreobrazhen...@luxoft.com CC: llvm-bugs@lists.llvm.org -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 28274 in oss-fuzz: llvm:llvm-dwarfdump-fuzzer: Null-dereference READ in llvm::DWARFFormValue::dumpSectionedAddress
Updates: Labels: Deadline-Approaching Comment #1 on issue 28274 by sheriffbot: llvm:llvm-dwarfdump-fuzzer: Null-dereference READ in llvm::DWARFFormValue::dumpSectionedAddress https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=28274#c1 This bug is approaching its deadline for being fixed, and will be automatically derestricted within 7 days. If a fix is planned within 2 weeks after the deadline has passed, a grace extension can be granted. - Your friendly Sheriffbot -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 49368] New: main::Class vs. Class not found for inferior calls
https://bugs.llvm.org/show_bug.cgi?id=49368
Bug ID: 49368
Summary: main::Class vs. Class not found for inferior calls
Product: lldb
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: All Bugs
Assignee: lldb-...@lists.llvm.org
Reporter: jan.kratoch...@redhat.com
CC: jdevliegh...@apple.com, llvm-bugs@lists.llvm.org
template class D {
public:
T t;
T &m() {
return t;
}
};
int main() {
struct C { unsigned i = 42; };
D d;
return d.m().i; // breakpoint
}
(lldb) p d.m()
error: error: function 'D::m' is used but not defined in this translation
unit, and cannot be defined in any other translation unit because its type does
not have linkage
:1:3: used here
d.m()
^
$ llvm-nm -C a.out
00401160 t D::m()
(gdb) p d.m()
$1 = (C &) @0x7fffcf58: {i = 42}
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 48856] Assertion failed: Cat && "no category for builtin comparison?", file clang\lib\Sema\SemaDeclCXX.cpp, line 7792
https://bugs.llvm.org/show_bug.cgi?id=48856 Matheus Izvekov changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #11 from Matheus Izvekov --- Fixed by https://github.com/llvm/llvm-project/commit/4a8530fc3039f128eddc38737f0172bb3d489bcf -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 16390] [Windows] C++ objects are passed as byval when using Itanium C++ ABI
https://bugs.llvm.org/show_bug.cgi?id=16390 Reid Kleckner changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Reid Kleckner --- > I'd much rather force users to pick between a mingw ABI and a win32 ABI which > encompasses both C and C++. I'm pretty sure this got sorted out by the *-windows-gnu *-windows-msvc triple changes. We definitely pass C++ objects indirectly for *-windows-gnu/itanium triples. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 17410] Allow reinterpret_cast in constant expression when -fms-compatibility is enabled
https://bugs.llvm.org/show_bug.cgi?id=17410 Reid Kleckner changed: What|Removed |Added Resolution|--- |WONTFIX Status|NEW |RESOLVED --- Comment #2 from Reid Kleckner --- MSVC has warned on this since 19.15: https://gcc.godbolt.org/z/ToG3o4 https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-4-c4668?view=msvc-160 warning C4644: usage of the macro-based offsetof pattern in constant expressions is non-standard; use offsetof defined in the C++ standard library instead Someone filed a similar issue with microsoft: https://developercommunity.visualstudio.com/t/field-offset-macro-in-winnth-can-generate-c4644-an/331780 At this point, I don't think clang needs to implement an extension for this. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 18115] Compile time extremely long while compiling template
https://bugs.llvm.org/show_bug.cgi?id=18115 Reid Kleckner changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #9 from Reid Kleckner --- I have a faster machine, but now this example takes 0m21.393s to compile for me. We can close 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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 49369] New: __cpp_nontype_template_args >= 201907L but floating-point template arguments rejected
https://bugs.llvm.org/show_bug.cgi?id=49369
Bug ID: 49369
Summary: __cpp_nontype_template_args >= 201907L but
floating-point template arguments rejected
Product: clang
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: C++2a
Assignee: unassignedclangb...@nondot.org
Reporter: ca...@carter.net
CC: blitzrak...@gmail.com, erik.pilking...@gmail.com,
llvm-bugs@lists.llvm.org, richard-l...@metafoo.co.uk
Clang 12.0.0-rc2 (and trunk) define __cpp_nontype_template_args to 201907L
indicating support for P1907R1 "Inconsistencies with non-type template
parameters"
(http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1907r1.html). This
proposal changes the constraint on non-type template arguments to require that
they have structural type, or [other cases that aren't germane] (N4878
[temp.param]/6). A _structural_ _type_ is a scalar type, or [other cases that
aren't germane] (N4878 [temp.param]/7). Scalar types include floating-point
types (N4878 [basic.types.general]/9). Nonetheless, this well-formed TU:
template int f() { return 42; }
int main() {
#if defined(__cpp_nontype_template_args) && \
__cpp_nontype_template_args >= 201911L
return f<3.14>();
#endif
}
when compiled with "-std=c++2a" generates diagnostics:
:6:12: error: no matching function for call to 'f'
return f<3.14>();
^~~
:1:21: note: candidate template ignored: invalid
explicitly-specified argument for 1st template parameter
template int f() { return 42; }
^
1 error generated.
Is there any chance that either the implementation of P1907R1 could be
completed or the value of __cpp_nontype_template_args reduced (to indicate
incomplete support) in time for Clang 12?
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
