[llvm-bugs] [Bug 44394] New: clang-cl is generating call to non-existing lib function for win32 with /fp:except option
https://bugs.llvm.org/show_bug.cgi?id=44394
Bug ID: 44394
Summary: clang-cl is generating call to non-existing lib
function for win32 with /fp:except option
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: LLVM Codegen
Assignee: unassignedclangb...@nondot.org
Reporter: zamazan...@tut.by
CC: llvm-bugs@lists.llvm.org, neeil...@live.com,
richard-l...@metafoo.co.uk
With recent ffp-exception-behavior=maytrap/strict, fp:except in clang-cl became
generate FPE aware code.
But in case of floorf and ceilf it generates call to non-existing library
function.
clang-cl.exe -m32 /Ox /fp:except testFloor.cpp /FA
testFloor.cpp:
#include
float ret(float v) { return floorf(v); }
resulting assember:
push eax
movss xmm0, dword ptr [esp + 8]
movss dword ptr [esp], xmm0
call _floorf #no such function!!!
pop eax
ret
Expected behaviour:
there is no floorf lib function. Like with cosf and other math functions,
floorf in MSVC is implemented as inline function.
So, it should be call to _floor (with apropriate conversion first).
--
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 44395] New: Invalid code generation for win32/32bit windows target
https://bugs.llvm.org/show_bug.cgi?id=44395
Bug ID: 44395
Summary: Invalid code generation for win32/32bit windows target
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: LLVM Codegen
Assignee: unassignedclangb...@nondot.org
Reporter: zamazan...@tut.by
CC: llvm-bugs@lists.llvm.org, neeil...@live.com,
richard-l...@metafoo.co.uk
clang(trunk) with -m32 on windows (win32 target) generates wrong code for the
following code ( https://godbolt.org/z/RKzU5M )
#include
#include
#include
struct Id { unsigned handle; };
struct QueryView { __m128 val; unsigned i; };
extern void perform_query(std::function);
template void foo ( QueryView &qv, const BT & block)
{
block( Id{qv.i}, _mm_setzero_ps() );
}
template void bar ( const BT & block)
{
perform_query([&](QueryView& qv) { block(qv.val); });
}
void external_call ( QueryView & qv ) {
{
foo(qv, [&](Id id, const __m128 two)->void{ bar([&](__m128 &
arg)->void{arg = two;});});
}}
the body of function std::function capture will (reasonably) make aligned read
on argument of __m128 type
While unaligned_stack_store will store __m128 register on stack unaligned,
tightly with Id structure.
This results in crash during runtime (unaligned load).
LLVM code (relevant part)
%3 = alloca inalloca <{ %struct.Id, <4 x float> }>, align 4
Assembly disasm (relevant part):
pusheax
sub esp, 16
mov eax, esp
xorps xmm0, xmm0
mov dword ptr [eax], ecx
movups xmmword ptr [eax + 4], xmm0 #unaligned!
Possible fix: https://reviews.llvm.org/D71915
--
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 28122] clang crashes on C++ code with invalid assignment to complex number: Assertion `getValueKind() == VK_LValue' failed
https://bugs.llvm.org/show_bug.cgi?id=28122 Luke changed: What|Removed |Added CC||lukebe...@hotmail.com Status|RESOLVED|REOPENED Resolution|DUPLICATE |--- -- 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 44396] New: llvm crashes on C++ code on i386 architecture on the project 'gpsim'
https://bugs.llvm.org/show_bug.cgi?id=44396 Bug ID: 44396 Summary: llvm crashes on C++ code on i386 architecture on the project 'gpsim' Product: clang Version: 9.0 Hardware: PC OS: FreeBSD Status: NEW Severity: enhancement Priority: P Component: C++ Assignee: unassignedclangb...@nondot.org Reporter: y...@tsoft.com CC: blitzrak...@gmail.com, dgre...@apple.com, erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org, richard-l...@metafoo.co.uk Clang/LLVM 9.0 crash when it compiles the FreeBSD port misc/gpsim (version 0.31.0) which is this SourceForge project: http://gpsim.sourceforge.net/#src This seems to only happen with i386/clang-9 combination. The FreeBSD build log: http://beefy17.nyi.freebsd.org/data/head-i386-default/p521042_s356139/logs/gpsim-0.31.0.log (IPv6 URL) ---excerpt from the above log--- .parser at end of file 2. Code generation 3. Running pass 'Function Pass Manager' on module 'gui_scope.cc'. 4. Running pass 'X86 EFLAGS copy lowering' on function '@_ZN12Scope_Window7getSpanEv' #0 0x038a9ff4 (/usr/bin/c+++0x38a9ff4) #1 0x038aa3fe (/usr/bin/c+++0x38aa3fe) #2 0x038a806e (/usr/bin/c+++0x38a806e) #3 0x038aa95c (/usr/bin/c+++0x38aa95c) #4 0x249da759 (/lib/libthr.so.3+0x12759) c++: error: unable to execute command: Abort trap (core dumped) c++: error: clang frontend command failed due to signal (use -v to see invocation) FreeBSD clang version 9.0.1 (g...@github.com:llvm/llvm-project.git c1a0a213378a458fbea1a5c77b315c7dce08fd05) (based on LLVM 9.0.1) -- 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 44397] New: MC produces a R_X86_64_PC32, gas produces a R_X86_64_PLT32
https://bugs.llvm.org/show_bug.cgi?id=44397 Bug ID: 44397 Summary: MC produces a R_X86_64_PC32, gas produces a R_X86_64_PLT32 Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: MC Assignee: unassignedb...@nondot.org Reporter: raf...@espindo.la CC: gri...@accesssoftek.com, llvm-bugs@lists.llvm.org, r...@google.com Given jne foo .long foo - . MC produces two R_X86_64_PC32 relocations. The gnu assembler produces a R_X86_64_PLT32 for the first one and a R_X86_64_PC32 to the second one. The advantage of producing a R_X86_64_PLT32 for branches is that the linker doesn't have to enforce pointer equality in the same way it has to do for R_X86_64_PC32. The corresponding bug in the gnu assembler is https://sourceware.org/bugzilla/show_bug.cgi?id=22791 -- 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 19730 in oss-fuzz: llvm:clang-fuzzer: Stack-overflow in llvm::detail::IEEEFloat::convertFromDecimalString
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 Stability-Memory-AddressSanitizer Reproducible Engine-libfuzzer OS-Linux Proj-llvm Reported-2019-12-29 Type: Bug New issue 19730 by ClusterFuzz-External: llvm:clang-fuzzer: Stack-overflow in llvm::detail::IEEEFloat::convertFromDecimalString https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=19730 Detailed Report: https://oss-fuzz.com/testcase?key=5660590353940480 Project: llvm Fuzzing Engine: libFuzzer Fuzz Target: clang-fuzzer Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: Stack-overflow Crash Address: 0x7ffdc2d2bff8 Crash State: llvm::detail::IEEEFloat::convertFromDecimalString clang::NumericLiteralParser::GetFloatValue BuildFloatingLiteral Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201912230431:201912240428 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5660590353940480 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 44398] New: Unqualified calls of std::ref lead to ADL issues
https://bugs.llvm.org/show_bug.cgi?id=44398
Bug ID: 44398
Summary: Unqualified calls of std::ref lead to ADL issues
Product: libc++
Version: unspecified
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P
Component: All Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: arthur.j.odw...@gmail.com
CC: llvm-bugs@lists.llvm.org, mclow.li...@gmail.com
https://bugs.llvm.org/show_bug.cgi?id=20092 is related, but for `get` instead
of `ref`.
// https://gcc.godbolt.org/z/8VfprT
#include
struct S {
friend void ref(S);
friend void deref(S);
};
int main() {
S s;
auto rw = std::ref(s);// OK
auto rw2 = std::ref(rw); // massive error spew
}
Currently <__functional_base> has
template
inline _LIBCPP_INLINE_VISIBILITY
reference_wrapper<_Tp>
ref(reference_wrapper<_Tp> __t) _NOEXCEPT
{
return ref(__t.get());
}
It should have
return _VSTD::ref(__t.get());
or simply (LWG 3146)
return __t;
There's also an unqualified ADL `ref` in :
// https://gcc.godbolt.org/z/EHw3Gy
#include
#include
struct D {
void operator()(int *) const;
friend void ref(D);
friend void deref(D);
};
int main() {
D d;
std::unique_ptr u(nullptr, d);
std::shared_ptr s = std::move(u);
}
--
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 19731 in oss-fuzz: llvm:clang-fuzzer: Stack-overflow in ComplexExprEvaluator::VisitBinaryOperator
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 Stability-Memory-AddressSanitizer Reproducible Engine-libfuzzer OS-Linux Proj-llvm Reported-2019-12-29 Type: Bug New issue 19731 by ClusterFuzz-External: llvm:clang-fuzzer: Stack-overflow in ComplexExprEvaluator::VisitBinaryOperator https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=19731 Detailed Report: https://oss-fuzz.com/testcase?key=5681202136875008 Project: llvm Fuzzing Engine: libFuzzer Fuzz Target: clang-fuzzer Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: Stack-overflow Crash Address: 0x7ffc5c513c20 Crash State: ComplexExprEvaluator::VisitBinaryOperator clang::StmtVisitorBasebool>::Visit Evaluate Sanitizer: address (ASAN) Crash Revision: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&revision=201912240428 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5681202136875008 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 44399] New: Memory Consumption Reduction for Large Array Initialization?
https://bugs.llvm.org/show_bug.cgi?id=44399 Bug ID: 44399 Summary: Memory Consumption Reduction for Large Array Initialization? Product: clang Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: Frontend Assignee: unassignedclangb...@nondot.org Reporter: phdoftheho...@gmail.com CC: llvm-bugs@lists.llvm.org, neeil...@live.com, richard-l...@metafoo.co.uk I have a large number of files that I want to turn into data initializers for (static/global/const) arrays and then compile into my program. I generally rely on these arrays to be optimizer-transparent. Occasionally, they go up to 50~60 Megabytes. The files are often dumped by xxd. A C++ header file representing 40 MB using XXD goes to about a 250 MB or so file. When I want to do work (constexpr processing in some cases) on some of these arrays of (unsigned) char, I spend a lot of time just compiling and memory usage shoots up. When I spent a lot of time tracking down the parts of what I end up paying for, for just using a single entry out of an e.g. 20 MB array I would use ~2.1 GB of memory. For example, for a 20 MB file named "image.bin", I would use xxd -i image.bin image.bin.h" and then attempt to return a single item from that array through main() to just test the cost of parsing and holding onto that data in the compiler: #include"___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 44400] New: _LIBCPP_DEBUG=1 std::string::iterator thinks the end iterator is "non-dereferenceable"
https://bugs.llvm.org/show_bug.cgi?id=44400
Bug ID: 44400
Summary: _LIBCPP_DEBUG=1 std::string::iterator thinks the end
iterator is "non-dereferenceable"
Product: libc++
Version: unspecified
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P
Component: All Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: arthur.j.odw...@gmail.com
CC: llvm-bugs@lists.llvm.org, mclow.li...@gmail.com
Bug 41274 may be related somehow.
// https://godbolt.org/z/PeZLZi
int main(int, char**)
{
std::string In2("abcd/efg");
std::string::iterator it = In2.end();
assert(*it == '\0'); // FAILS
(void) fs::u8path(In2.begin()); // FAILS
}
For something like a std::vector, the "end()" iterator indeed would be
non-dereferenceable. But for a std::string, the "end()" iterator points to the
null terminator, which is a valid character. There is at least one libc++ test
that relies on being able to dereference the "end()" iterator of a std::string:
libcxx/test/std/input.output/filesystems/class.path/path.nonmember/path.factory.pass.cpp
Possible resolutions include:
- Make the one-character fix to basic_string::__dereferenceable (change < to
<=).
- Rewrite `fs::u8path` so that it doesn't try to read the null terminator.
(This is physically impossible, I think?)
- Decide that the current "path.factory.pass.cpp" has UB and eliminate it from
the test suite (perhaps with accompanying LWG issue about this trap for the
unwary).
--
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
