[llvm-bugs] [Bug 44147] Non-deterministic debug info with LTO
https://bugs.llvm.org/show_bug.cgi?id=44147 Jeremy Morse changed: What|Removed |Added Resolution|--- |DUPLICATE Status|CONFIRMED |RESOLVED --- Comment #13 from Jeremy Morse --- David wrote: > Likely duplicate of bug 43909? Yup, that definitely looks to be it; and the patch in https://reviews.llvm.org/D70376 is better; thanks for the cross-reference. Mike wrote: > I tried with the 3 patches from that branch, but without assertions, and the > non-determinism I mentioned in comment 9 are gone. Cool, it must have been switching from WeakVH to LVIValueHandle. The patch in the other bug looks like it'll go in shortly, and it appears to fix the same issue in a better way. I'll mark this as a duplicate; please re-open if D70376 doesn't actually fix it for you. *** This bug has been marked as a duplicate of bug 43909 *** -- 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 44169] New: Wrong return type in std::strchr
https://bugs.llvm.org/show_bug.cgi?id=44169 Bug ID: 44169 Summary: Wrong return type in std::strchr Product: clang Version: 9.0 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: C++ Assignee: unassignedclangb...@nondot.org Reporter: b...@bertptrs.nl CC: blitzrak...@gmail.com, dgre...@apple.com, erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org, richard-l...@metafoo.co.uk Created attachment 22876 --> https://bugs.llvm.org/attachment.cgi?id=22876&action=edit Minimal example showcasing the bug According to the standard, the return type of std::strchr should be of the same constness as the input string. This means that if you provide a char*, you should get a char*, and if you provide a const char*, you should get a const char* back. It seems that Clang 9 (using libstdc++ 6.0.27 as the standard library implementation) returns a char* regardless of input constness. Attached is a simple program that reproduces the issue. It compiles when using GCC (version 9.2) but doesn't in 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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 44170] New: Duplicate file names in DWARF v5 line tables
https://bugs.llvm.org/show_bug.cgi?id=44170 Bug ID: 44170 Summary: Duplicate file names in DWARF v5 line tables Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: DebugInfo Assignee: unassignedb...@nondot.org Reporter: lab...@google.com CC: dblai...@gmail.com, jdevliegh...@apple.com, keith.wal...@arm.com, llvm-bugs@lists.llvm.org, paul_robin...@playstation.sony.com [Filing this as a debug info bug, but in all likelihood this is a bug in how clang generates llvm ir.] If compile the a file with just a slightly more complicated path (e.g. add a leading "./"), the file will end up twice in the line table. = $ clang -gmlt -gdwarf-5 -o a.o ./a.c -c && llvm-dwarfdump -debug-line a.o ... include_directories[ 0] = "/tmp/X" include_directories[ 1] = "." file_names[ 0]: name: "a.c" dir_index: 0 md5_checksum: e6ab1d5b7f82464c963a8522037dfa72 file_names[ 1]: name: "a.c" dir_index: 1 md5_checksum: e6ab1d5b7f82464c963a8522037dfa72 AddressLine Column File ISA Discriminator Flags -- -- -- -- --- - - 0x 1 0 1 0 0 is_stmt = If I remove the "./" then the file is present just once, and all the line table entries correctly reference entry 0. I found this while playing around with lldb and dwarf 5. It seems lldb has some code, which assumes a file will be present only once in a line table, and so things fail in subtle ways, because sometimes it will pick file zero, which has no line entries associated with it. Lldb probably shouldn't be making that assumption, but regardless of that, this looks like a bug in llvm/clang. The code in question definitely comes from the primary source file, so the line tables should reference it as such. This is probably caused by the fact that we do some form of path simplification on the path which goes in the the DICompileUnit, but not on the line !dbg attachments. I guess both should undergo the same kinds of simplifications. -- 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 43040] riscv - error in backend: Cannot select: 0x55d7f7ff1300: f32 = fcopysign 0x55d7f7ff1c58, 0x55d7f7fe9fb8
https://bugs.llvm.org/show_bug.cgi?id=43040 Luís Marques changed: What|Removed |Added Resolution|--- |FIXED Status|REOPENED|RESOLVED --- Comment #4 from Luís Marques --- A fix for this has be committed upstream. Thank you. -- 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 42076] Compiler assert on Risc-V code
https://bugs.llvm.org/show_bug.cgi?id=42076 Luís Marques changed: What|Removed |Added CC||l...@luismarques.eu Status|NEW |RESOLVED Resolution|--- |WORKSFORME --- Comment #3 from Luís Marques --- This has been working correctly for a long while, it was probably just an issue with the early floating-point support. Marking as resolved. -- 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 44145] libcxx fails with -Wdeprecated-copy
https://bugs.llvm.org/show_bug.cgi?id=44145 David Bolvansky changed: What|Removed |Added Resolution|--- |WORKSFORME Status|NEW |RESOLVED --- Comment #6 from David Bolvansky --- I reenabled it and sanitizers are fine with it. I dont’t know why they failed that time. Anyway, nothing to fix here. 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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 42820] [RISCV][RV64] Lost zero extension while returning complex floating value
https://bugs.llvm.org/show_bug.cgi?id=42820 Luís Marques changed: What|Removed |Added CC||l...@luismarques.eu Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #3 from Luís Marques --- Solved by D65497. -- 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 42114] Risc-V C compiler assert
https://bugs.llvm.org/show_bug.cgi?id=42114 Luís Marques changed: What|Removed |Added Resolution|--- |WORKSFORME CC||l...@luismarques.eu Status|NEW |RESOLVED --- Comment #2 from Luís Marques --- This is no longer an issue in the non-experimental RISC-V target. Marking as resolved. -- 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 42115] Risc-V C compiler assert #2
https://bugs.llvm.org/show_bug.cgi?id=42115 Luís Marques changed: What|Removed |Added Resolution|--- |WORKSFORME Status|NEW |RESOLVED CC||l...@luismarques.eu --- Comment #2 from Luís Marques --- This is no longer an issue in the non-experimental RISC-V target. Marking as resolved. -- 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 43316] RISCV64 Segmentation fault (core dumped) Running pass 'Function Pass Manager' on module '../ruby-2.5.5/transcode.c'.
https://bugs.llvm.org/show_bug.cgi?id=43316 Luís Marques changed: What|Removed |Added CC||l...@luismarques.eu Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #2 from Luís Marques --- This is a duplicate of the bug 43041. This issue was solved by commit c894c6c98335425c01b8a257691bbf3825ab555f (https://reviews.llvm.org/D66752). *** This bug has been marked as a duplicate of bug 43041 *** -- 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 42117] Risc-V C compiler assert when casting from a double to an int!
https://bugs.llvm.org/show_bug.cgi?id=42117 Luís Marques changed: What|Removed |Added CC||l...@luismarques.eu Resolution|--- |WORKSFORME Status|NEW |RESOLVED --- Comment #3 from Luís Marques --- This works correctly in non-experimental RISC-V targets, such as LLVM 9.x. Marking as resolved. Geoffrey Rogers: snapshot builds here would refer to using a nightly build, compiling from the git master tree, etc. Check the LLVM build instructions. -- 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 44133] compiler error omp declare reduction inside of template function
https://bugs.llvm.org/show_bug.cgi?id=44133 Steffen Seckler changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #8 from Steffen Seckler --- found another example that still doesn't work, with undefined reference warnings. I have attached the corresponding code: https://bugs.llvm.org/attachment.cgi?id=22877 -- 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 43447] RISC-V instruction selection cannot lower fpext half to float
https://bugs.llvm.org/show_bug.cgi?id=43447 Luís Marques changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED CC||l...@luismarques.eu --- Comment #1 from Luís Marques --- This now works. I believe this was fixed by the commit 1baa50396d9b8766a2e3d775f2ea14c42e2fc05c https://reviews.llvm.org/D69246 -- 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 44171] New: GWP ASAN documentation doesn't describe how to include/link the GWP header + link
https://bugs.llvm.org/show_bug.cgi?id=44171 Bug ID: 44171 Summary: GWP ASAN documentation doesn't describe how to include/link the GWP header + link Product: Documentation Version: trunk Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: General docs Assignee: unassignedb...@nondot.org Reporter: alex.gay...@gmail.com CC: llvm-bugs@lists.llvm.org https://llvm.org/docs/GwpAsan.html#allocator-support includes an example of what code integrating GWP ASAN could look like. However, the code does not indicate which header you're supposed to include, or which linker incantations are required. Including such details would make GWP ASAN much more accessible. -- 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 42976] Risc-V clang does not recognize floating point registers in inline asm
https://bugs.llvm.org/show_bug.cgi?id=42976
Luís Marques changed:
What|Removed |Added
Resolution|--- |WORKSFORME
Status|NEW |RESOLVED
CC||l...@luismarques.eu
--- Comment #1 from Luís Marques ---
This works correctly:
$ cat test.c
void foo() {
asm ("fadd.s f1, f2, f3");
asm ("fadd.d fa0, fa1, fa2");
}
$ clang --target=riscv32 -O2 -S test.c -o-
(...)
foo:# @foo
# %bb.0:# %entry
#APP
fadd.s f1, f2, f3
#NO_APP
#APP
fadd.d fa0, fa1, fa2
#NO_APP
ret
(...)
If anything, I wonder if that works more than it should, since we accept that
inline assembly even when not targetting the floating-point extensions.
--
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 42866] Floating point arguments are passed in integer registers for risc-v with -march=rv64g
https://bugs.llvm.org/show_bug.cgi?id=42866 Luís Marques changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID CC||l...@luismarques.eu --- Comment #1 from Luís Marques --- This is correct. Targeting the floating-point extensions doesn't necessarily mean you are using the hardfloat ABIs. To ensure that floating-point arguments are passed in the floating-point registers for rv64g be sure to also pass to clang the option `-mabi=lp64d`. I believe you can now also pass the option --target=riscv64-linux and you'll implicitly get the `march` and `mabi` options that you intended, and the values will be passed in the floating-point registers (might require compiling clang from recent sources). -- 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 44172] New: Provide a .so that overrides malloc/free with GWP-ASAN
https://bugs.llvm.org/show_bug.cgi?id=44172 Bug ID: 44172 Summary: Provide a .so that overrides malloc/free with GWP-ASAN Product: compiler-rt Version: unspecified Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: compiler-rt Assignee: unassignedb...@nondot.org Reporter: alex.gay...@gmail.com CC: llvm-bugs@lists.llvm.org It'd be very useful if GWP-ASAN included a .so that could trivially be LD_PRELOAD'd to override malloc/free to use GWP-ASAN + fallback to libc's malloc. This would specifically make using GWP-ASAN in contexts such as server-software, where the person doing the deployment uses OS provided libraries such as OpenSSL or binaries like Python, and simply wants to easily apply GWP-ASAN across their fleet. -- 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 17027 in oss-fuzz: llvm:llvm-dwarfdump-fuzzer: ASSERT: FullLength == length()
Updates: Labels: Deadline-Approaching Comment #2 on issue 17027 by sheriff...@chromium.org: llvm:llvm-dwarfdump-fuzzer: ASSERT: FullLength == length() https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=17027#c2 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 44173] New: Backport r370113 to 9.0.1
https://bugs.llvm.org/show_bug.cgi?id=44173 Bug ID: 44173 Summary: Backport r370113 to 9.0.1 Product: libraries Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: Backend: RISC-V Assignee: unassignedb...@nondot.org Reporter: luismarq...@lowrisc.org CC: a...@lowrisc.org, llvm-bugs@lists.llvm.org Please backport r370113 to LLVM 9.0.1 Git commit: c894c6c98335425c01b8a257691bbf3825ab555f https://reviews.llvm.org/D66752 Original bug report: https://bugs.llvm.org/show_bug.cgi?id=43041 -- 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 44174] New: A range of ScopeRecord does not match the code enclosed by __try
https://bugs.llvm.org/show_bug.cgi?id=44174
Bug ID: 44174
Summary: A range of ScopeRecord does not match the code
enclosed by __try
Product: clang
Version: 9.0
Hardware: PC
OS: Windows NT
Status: NEW
Severity: normal
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: leamov...@gmail.com
CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org,
neeil...@live.com, richard-l...@metafoo.co.uk
A range of ScopeRecord does not match the code enclosed by __try
I hit a potential bug that clang generates a wrong Windows SEH structure.
Here's an NMAKE project to reproduce the issue.
https://github.com/msmania/seh-debug/tree/191128-report-to-llvm
My build environment consists of:
- Clang 9.0 x86_64-pc-windows-msvc
(downloaded from http://releases.llvm.org/download.html)
- Visual Studio 2019 Community
- Windows 10 SDK 10.0.18362.0
To build, you open "x64 Native Tools Command Prompt for VS 2019" and run NMAKE.
You may need to update `Makefile` to adjust installation paths such as
$(MSVCDIR), $(WIN10KITINCLUDE), or $(CLANG).
This Makefile builds src/main.cpp with two compilers clang++ and MSVC. An
executable will be generated as bin-clang/amd64/t.exe and bin/amd64/t.exe
respectively.
These executables run without any crash, but embedded SEH information in
clang's output looks not correct, especially translation from `__try` block
into a range of ScopeTable's record. MSVC's output looks correct on the other
hand. This will cause a second chance exception even from __try block.
For example, let's think about this code.
__try {
CoInitialize(nullptr);
}
__except (ExceptionFilter(GetExceptionInformation())) {
__debugbreak();
}
It's compiled like this. Analyzing SEH info in the binary, the first xor,
setting the first argument to 0, is not included in the ScopeRecord.
77 7ff7`64dc1153 31c9xor ecx,ecx
77 7ff7`64dc1155 ff155527callqword ptr
[t!_imp_CoInitialize (7ff7`64dc38b0)]
This case should be ok because `xor ecx,ecx` will never throw an exception, but
in a more complex scenario, incorrect ScopeRecord will cause an unexpected
behavior.
More examples and detailed explanations are available in the links below:
Clang:
https://github.com/msmania/seh-debug/blob/191128-report-to-llvm/seh-clang.md
MSVC:
https://github.com/msmania/seh-debug/blob/191128-report-to-llvm/seh-msvc.md
--
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 44018] clang on MIPS: Do not know how to split this operator's operand
https://bugs.llvm.org/show_bug.cgi?id=44018 Simon Atanasyan changed: What|Removed |Added Resolution|--- |FIXED Status|CONFIRMED |RESOLVED --- Comment #1 from Simon Atanasyan --- Fixed at https://github.com/llvm/llvm-project/commit/f4d32ae75b -- 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 19171 in oss-fuzz: llvm:clang-fuzzer: Segv on unknown address in llvm::detail::IEEEFloat::roundSignificandWithExponent
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevlieg...@apple.com, igm...@gmail.com, d...@google.com, mit...@google.com, bigchees...@gmail.com, eney...@google.com, llvm-b...@lists.llvm.org, j...@chromium.org, v...@apple.com, mitchphi...@outlook.com, xpl...@gmail.com, akils...@apple.com Labels: ClusterFuzz Reproducible Stability-Memory-MemorySanitizer Engine-libfuzzer OS-Linux Proj-llvm Security_Severity-High Reported-2019-11-28 Type: Bug-Security New issue 19171 by ClusterFuzz-External: llvm:clang-fuzzer: Segv on unknown address in llvm::detail::IEEEFloat::roundSignificandWithExponent https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=19171 Detailed Report: https://oss-fuzz.com/testcase?key=5706795951849472 Project: llvm Fuzzing Engine: libFuzzer Fuzz Target: clang-fuzzer Job Type: libfuzzer_msan_llvm Platform Id: linux Crash Type: Segv on unknown address Crash Address: Crash State: llvm::detail::IEEEFloat::roundSignificandWithExponent llvm::detail::IEEEFloat::convertFromDecimalString llvm::detail::IEEEFloat::convertFromString Sanitizer: memory (MSAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_msan_llvm&range=201911200438:201911230451 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5706795951849472 Issue filed automatically. See https://google.github.io/oss-fuzz/advanced-topics/reproducing 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. Comments on individual Monorail issues are not monitored. -- 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 44175] New: unused member variable causes code to compile for member to function for undefined function
https://bugs.llvm.org/show_bug.cgi?id=44175
Bug ID: 44175
Summary: unused member variable causes code to compile for
member to function for undefined function
Product: clang
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: C++17
Assignee: unassignedclangb...@nondot.org
Reporter: marcp...@gmail.com
CC: blitzrak...@gmail.com, erik.pilking...@gmail.com,
llvm-bugs@lists.llvm.org, richard-l...@metafoo.co.uk
https://godbolt.org/z/VygQuN
If the class is not instantiated and the variable is not static then the
reference to a non-existing method is not reported as an error.
#include
#include
struct Foo {
virtual void hello(int) = 0;
};
struct Bar : public Foo {
void hello(int) override {};
};
struct Bad { };
template
struct is_Foo {
using hello_fn_t = void (T::*)(int);
void (T::*hello)(int) = &T::hello;
constexpr static bool value=true;
};
template >
void say(T& t)
{
static_assert(U::value, "not a Foo");
puts("hello\n");
//U u; // Line 22
//t.hello(4); // Line 23
}
int main()
{
//Bar b;;
//Foo& f = b;
//say(b);
//say(f);
Bad bad;
say(bad);
}
Found while exploring a GCC bug
to gcc-bugzilla-account-request
https://godbolt.org/z/SFZmZJ
In clang you get
no member names 'hello' in 'Bad'
which is the expected result.
In all GCC versions using --std=c++17 from 5.2 onwards the code compiles.
#include
#include
struct Foo {
virtual void hello(int) = 0;
};
struct Bar : public Foo {
void hello(int) override {};
};
struct Bad { };
template
struct is_Foo {
using hello_fn_t = void (T::*)(int);
constexpr static void (T::*hello)(int) = &T::hello;
static constexpr bool value=true;
};
template
auto say(T& t) -> std::enable_if_t::value, void>{
//U u; // Line 22
//t.hello(4); // Line 23
puts("hello\n");
}
int main()
{
//Bar b;;
//Foo& f = b;
//say(b);
//say(f);
Bad bad;
say(bad);
}
If you change say to
template >
void say(T& t)
{
U u; // Line 22
//t.hello(4); // Line 23
}
you get the same errors in clang, but no errors in gcc.
--
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 44176] New: Regression in a29aa47106205ec95c12e0ebac4260c5de878a6a [OpenCL] Move addr space deduction to Sema.
https://bugs.llvm.org/show_bug.cgi?id=44176 Bug ID: 44176 Summary: Regression in a29aa47106205ec95c12e0ebac4260c5de878a6a [OpenCL] Move addr space deduction to Sema. Product: clang Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: OpenCL Assignee: unassignedclangb...@nondot.org Reporter: dr...@jwdt.org CC: anastasia.stul...@arm.com, llvm-bugs@lists.llvm.org Created attachment 22879 --> https://bugs.llvm.org/attachment.cgi?id=22879&action=edit Test case failing to compile The attached example, that was compiling correctly before a29aa47106205ec95c12e0ebac4260c5de878a6a, fails to compile with a29aa47106205ec95c12e0ebac4260c5de878a6a with the command line clang++ -cl-std=clc++ -x cl -emit-llvm --target=spir64-unknown-unknown -cl-denorms-are-zero -cl-mad-enable -cl-no-signed-zeros -ferror-limit=1000 -Xclang -finclude-default-header -Dcl_clang_storage_class_specifiers -Wno-invalid-constexpr -c test.cl -o test.bc with the following errors ../Merger/GPUTPCGMPolynomialField.h:226:27: error: cannot initialize a parameter of type 'float *' with an lvalue of type 'float [20]' GetPolynomsTrd(x, y, z, f); ^ ../Merger/GPUTPCGMPolynomialField.h:198:86: note: passing argument to parameter 'f' here inline void GPUTPCGMPolynomialField::GetPolynomsTrd(float x, float y, float z, float f[NTRDM]) ^ ../Merger/GPUTPCGMPolynomialField.h:241:27: error: cannot initialize a parameter of type 'float *' with an lvalue of type 'float [20]' GetPolynomsTrd(x, y, z, f); ^ ../Merger/GPUTPCGMPolynomialField.h:198:86: note: passing argument to parameter 'f' here inline void GPUTPCGMPolynomialField::GetPolynomsTrd(float x, float y, float z, float f[NTRDM]) ^ In file included from ../Base/opencl-common/GPUReconstructionOCL.cl:63: In file included from ../Base/GPUReconstructionIncludesDevice.h:50: ../Merger/GPUTPCGMPropagator.cxx:59:64: error: cannot initialize a parameter of type 'float *' with an lvalue of type 'float [3]' mField->GetFieldIts(X * cs - Y * sn, X * sn + Y * cs, Z, bb); ^~ ../Merger/GPUTPCGMPolynomialField.h:269:83: note: passing argument to parameter 'B' here inline void GPUTPCGMPolynomialField::GetFieldIts(float x, float y, float z, float B[3]) const ^ In file included from ../Base/opencl-common/GPUReconstructionOCL.cl:63: In file included from ../Base/GPUReconstructionIncludesDevice.h:50: ../Merger/GPUTPCGMPropagator.cxx:62:64: error: cannot initialize a parameter of type 'float *' with an lvalue of type 'float [3]' mField->GetFieldTrd(X * cs - Y * sn, X * sn + Y * cs, Z, bb); ^~ ../Merger/GPUTPCGMPolynomialField.h:223:83: note: passing argument to parameter 'B' here inline void GPUTPCGMPolynomialField::GetFieldTrd(float x, float y, float z, float B[3]) const ^ In file included from ../Base/opencl-common/GPUReconstructionOCL.cl:63: In file included from ../Base/GPUReconstructionIncludesDevice.h:50: ../Merger/GPUTPCGMPropagator.cxx:66:61: error: cannot initialize a parameter of type 'float *' with an lvalue of type 'float [3]' mField->GetField(X * cs - Y * sn, X * sn + Y * cs, Z, bb); ^~ ../Merger/GPUTPCGMPolynomialField.h:167:80: note: passing argument to parameter 'B' here inline void GPUTPCGMPolynomialField::GetField(float x, float y, float z, float B[3]) const ^ In file included from ../Base/opencl-common/GPUReconstructionOCL.cl:63: In file included from ../Base/GPUReconstructionIncludesDevice.h:50: ../Merger/GPUTPCGMPropagator.cxx:87:31: error: cannot initialize a parameter of type 'float *' with an lvalue of type 'float [3]' GetBxByBz(Alpha, X, Y, Z, B); ^ ../Merger/GPUTPCGMPropagator.cxx:31:89: note: passing argument to parameter 'B' here void GPUTPCGMPropagator::GetBxByBz(float Alpha, float X, float Y, float Z, float B[3]) const ^ ../Merger/GPUTPCGMPropagator.cxx:159:47: error: cannot initialize a parameter of type 'float *' with an lvalue of type 'float [3]' GetBxByBz(newAlpha, t0.X(), t0.Y(), t0.Z(), B); ^ ../Merger/GPUTPCGMPropagator.cxx:31:89: note: passing argument
[llvm-bugs] [Bug 44177] New: Constexpr array not seen as constexpr
https://bugs.llvm.org/show_bug.cgi?id=44177
Bug ID: 44177
Summary: Constexpr array not seen as constexpr
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: OpenCL
Assignee: unassignedclangb...@nondot.org
Reporter: dr...@jwdt.org
CC: anastasia.stul...@arm.com, llvm-bugs@lists.llvm.org
Created attachment 22880
--> https://bugs.llvm.org/attachment.cgi?id=22880&action=edit
Testcase
The attached code (which works correctly with standard C++, and also with CUDA)
fails in OpenCL because the constexpr array zSize is not interpreted as
constexpr.
Command to reproduce:
clang++ -cl-std=clc++ -Xclang -finclude-default-header -o test test2.cl
Error message:
test2.cl:54:57: error: constexpr function never produces a constant expression
[-Winvalid-constexpr]
GPU_HOST_DEVICE constexpr GPUArray InverseZBinSize()
^
test2.cl:57:57: note: subexpression not valid in a constant expression
return GPUArray{{0.5f * ZBins / (zSize[0]), 0.5f * ZBins
/ (zSize[1]), 0.5f * ZBins / (zSize[2]),
--
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 44178] New: [InstCombine] Miscompile of bitcast/zext/trunc/bitcast on vectors for big-endian targets
https://bugs.llvm.org/show_bug.cgi?id=44178
Bug ID: 44178
Summary: [InstCombine] Miscompile of bitcast/zext/trunc/bitcast
on vectors for big-endian targets
Product: new-bugs
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: mikael.hol...@ericsson.com
CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org
In
llvm/test/Transforms/InstCombine/cast.ll
there is a test like this:
target datalayout = "E-p:64:64:64-p1:32:32:32-p2:64:64:64-p3:64:64:64-
a0:0:8-f32:32:32-f64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:32:64-
v64:64:64-v128:128:128-n8:16:32:64"
[...]
define <3 x i32> @test60(<4 x i32> %call4) {
; CHECK-LABEL: @test60(
; CHECK-NEXT:[[P10:%.*]] = shufflevector <4 x i32> [[CALL4:%.*]],
<4 x i32> undef, <3 x i32>
; CHECK-NEXT:ret <3 x i32> [[P10]]
;
%p11 = bitcast <4 x i32> %call4 to i128
%p9 = trunc i128 %p11 to i96
%p10 = bitcast i96 %p9 to <3 x i32>
ret <3 x i32> %p10
}
If we assume the input vector is e.g. <1, 2, 3, 4> then I assume %p11
would be the (hex) value 1234, %p9 would be the 234 and %p10 would then
be the vector <2, 3, 4>.
Note that the datalayout says we're using big endian.
But the CHECK-NEXT checks that the result is made up of the elements at
index 0, 1 and 2 from the input vector, which would be <1, 2, 3>.
Similarly, test61 tests bitcast/zext/bitcast, and there I think zeroes are
added at the wrong end for big-endian targets.
The transform was added in https://reviews.llvm.org/rL103354.
The problem is in optimizeVectorResize in InstCombineCasts.cpp where we do
if (SrcTy->getNumElements() > DestTy->getNumElements()) {
// If we're shrinking the number of elements, just shuffle in the low/high
// elements from the input depending on endian and use undef as the
// second shuffle input.
V2 = UndefValue::get(SrcTy);
for (unsigned i = 0, e = DestTy->getNumElements(); i != e; ++i)
if (IC.getDataLayout().isBigEndian())
ShuffleMask.push_back(i + SrcTy->getNumElements() -
DestTy->getNumElements());
else
ShuffleMask.push_back(i);
} else {
// If we're increasing the number of elements, shuffle in all of the
// elements from InVal and fill the rest of the result elements with zeros
// from a constant zero.
V2 = Constant::getNullValue(SrcTy);
unsigned SrcElts = SrcTy->getNumElements();
for (unsigned i = 0, e = SrcElts; i != e; ++i)
ShuffleMask.push_back(i);
// The excess elements reference the first element of the zero input.
for (unsigned i = 0, e = DestTy->getNumElements()-SrcElts; i != e; ++i)
ShuffleMask.push_back(SrcElts);
}
Endianness needs to be taken into account above.
Also see discussion on llvm-dev here:
http://lists.llvm.org/pipermail/llvm-dev/2019-November/137297.html
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
