[llvm-bugs] [Bug 38115] New: CMAKE_OBJCOPY not set
https://bugs.llvm.org/show_bug.cgi?id=38115
Bug ID: 38115
Summary: CMAKE_OBJCOPY not set
Product: compiler-rt
Version: 6.0
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: fuzzer
Assignee: unassignedb...@nondot.org
Reporter: pro...@itc.rwth-aachen.de
CC: llvm-bugs@lists.llvm.org
When building current trunk version of LLVM including project/compiler-rt I see
the following error:
/bin/sh: --localize-hidden: command not found
Searching the source for this flag shows
projects/compiler-rt/lib/fuzzer/CMakeLists.txt to be the only file specifying
--localize-hidden. The error indicates that CMAKE_OBJCOPY might be empty.
Adding a cmake-message next to the line shows that the variable is indead
empty.
I suggest to use a default value ("true"?) in case the variable is not defined.
I found these matches for CMAKE_OBJCOPY in the configured build directory:
BUILD $ grep CMAKE_OBJCOPY . -riI
./projects/compiler-rt/lib/fuzzer/libcxx_fuzzer_x86_64-bins/CMakeCache.txt:CMAKE_OBJCOPY:FILEPATH=/usr/bin/objcopy
./projects/compiler-rt/lib/fuzzer/libcxx_fuzzer_x86_64-bins/CMakeCache.txt://ADVANCED
property for variable: CMAKE_OBJCOPY
./projects/compiler-rt/lib/fuzzer/libcxx_fuzzer_x86_64-bins/CMakeCache.txt:CMAKE_OBJCOPY-ADVANCED:INTERNAL=1
./lib/cmake/llvm/AddLLVM.cmake: COMMAND ${CMAKE_OBJCOPY} --only-keep-debug
$ $.debug
./lib/cmake/llvm/AddLLVM.cmake: COMMAND ${CMAKE_OBJCOPY}
--add-gnu-debuglink=$.debug $
./lib/cmake/llvm/LLVMExternalProjectUtils.cmake: list(APPEND compiler_args
-DCMAKE_OBJCOPY=${LLVM_RUNTIME_OUTPUT_INTDIR}/llvm-objcopy)
./lib/cmake/llvm/LLVMExternalProjectUtils.cmake:
-DCMAKE_OBJCOPY=${CMAKE_OBJCOPY}
--
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 38116] New: overflow at realpath()
https://bugs.llvm.org/show_bug.cgi?id=38116 Bug ID: 38116 Summary: overflow at realpath() Product: lld Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: unassignedb...@nondot.org Reporter: morta...@gmail.com CC: llvm-bugs@lists.llvm.org File: llvm-mirror/clang/blob/master/lib/Frontend/ModuleDependencyCollector.cpp#L108 i.e if (!realpath(SrcPath.str().c_str(), CanonicalPath)) According to the documentation of realpath() the output buffer needs to be at least of size PATH_MAX specifying output buffers large enough to handle the maximum-size possible result from path manipulation functions. (In that instance, buf's size comes from uv__fs_pathmax_size(). That function attempts to use pathconf(path, _PC_PATH_MAX) as noted in the realpath(3) docs) But over here uv__fs_pathmax_size() nor pathconf(path, _PC_PATH_MAX) is used. Passing an inadequately-sized output buffer to a path manipulation function can result in a buffer overflow. Such functions include realpath() readlink() PathAppend() and 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 38117] New: Intrinisc::getName does not generate different names for different unnamed type arguments
https://bugs.llvm.org/show_bug.cgi?id=38117 Bug ID: 38117 Summary: Intrinisc::getName does not generate different names for different unnamed type arguments Product: libraries Version: trunk Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: Core LLVM classes Assignee: unassignedb...@nondot.org Reporter: florian.h...@arm.com CC: llvm-bugs@lists.llvm.org Currently different unnamed types are mangled to the same type string, which means getDeclaration falls over when called for overloaded intrinsics like llvm.ssa.copy with different unnamed types. Some more details & discussion can be found here: https://reviews.llvm.org/D48541 (abandoned for now) -- 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 29030] Generic ARM cpu targets
https://bugs.llvm.org/show_bug.cgi?id=29030 Florian Hahn changed: What|Removed |Added Resolution|--- |FIXED CC||florian.h...@arm.com Status|NEW |RESOLVED --- Comment #1 from Florian Hahn --- On ARM, I think both -mcpu=native and -march=native try to detect the host CPU and use that. You can specify a architecture version like armv7 via -march, e.g. -march=armv7 Please feel free to re-open the issue if I am missing something. -- 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 38118] New: LLVM does not compile with Visual Studio 17 2018 Preview
https://bugs.llvm.org/show_bug.cgi?id=38118
Bug ID: 38118
Summary: LLVM does not compile with Visual Studio 17 2018
Preview
Product: libraries
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: Loop Optimizer
Assignee: unassignedb...@nondot.org
Reporter: steve...@gmail.com
CC: llvm-bugs@lists.llvm.org
BuildPasses.cpp does not compile with that compiler, but does compile with
non-preview versions.
C:\dev\src\llvm\build\lib\Passes>CL.exe /c /IC:\dev\src\llvm\build\lib\Passes
/IC:\dev\src\llvm\lib\Passes /IC:\dev\src\llvm\build\include
/IC:\dev\src\llvm\include /Zi /W4 /WX- /diagnostics:classic /MP /O2 /Ob1 /Oi /D
WIN32 /D _WINDOWS /D NDEBUG /D _HAS_EXCEPTIONS=0 /D GTEST_HAS_RTTI=0 /D
_CRT_SECURE_NO_DEPRECATE /D _CRT_SECURE_NO_WARNINGS /D
_CRT_NONSTDC_NO_DEPRECATE /D _CRT_NONSTDC_NO_WARNINGS /D
_SCL_SECURE_NO_DEPRECATE /D _SCL_SECURE_NO_WARNINGS /D UNICODE /D _UNICODE /D
__STDC_CONSTANT_MACROS /D __STDC_FORMAT_MACROS /D __STDC_LIMIT_MACROS /D
"CMAKE_INTDIR=\"RelWithDebInfo\"" /D _UNICODE /D UNICODE /Gm- /MD /GS
/fp:precise /Zc:wchar_t /Zc:forScope /Zc:inline /Zc:rvalueCast /GR-
/Fo"LLVMPasses.dir\RelWithDebInfo\\"
/Fd"LLVMPasses.dir\RelWithDebInfo\LLVMPasses.pdb" /Gd /TP /wd4141 /wd4146
/wd4180 /wd4244 /wd4258 /wd4267 /wd4291 /wd4345 /wd4351 /wd4355 /wd4456 /wd4457
/wd4458 /wd4459 /wd4503 /wd4624 /wd4722 /wd4800 /wd4100 /wd4127 /wd4512 /wd4505
/wd4610 /wd4510 /wd4702 /wd4245 /wd4706 /wd4310 /wd4701 /wd4703 /wd4389 /wd4611
/wd4805 /wd4204 /wd4577 /wd4091 /wd4592 /wd4319 /wd4324 /FC /errorReport:prompt
/we4238 /Zc:strictStrings -w14062 /EHs-c-
C:\dev\src\llvm\lib\Passes\PassBuilder.cpp
Microsoft (R) C/C++ Optimizing Compiler Version 19.15.26608.1 for x64
Copyright (C) Microsoft Corporation. All rights reserved.
PassBuilder.cpp
c:\dev\src\llvm\lib\passes\passregistry.def(121): error C2275:
'std::remove_reference::type': illegal use of this type
as an expression
c:\dev\src\llvm\lib\passes\passregistry.def(120): note: see declaration of
'std::remove_reference::type'
c:\dev\src\llvm\lib\passes\passregistry.def(121): error C2923:
'llvm::RequireAnalysisPass':
'std::remove_reference::type' is not a valid template
type argument for parameter 'AnalysisT'
c:\dev\src\llvm\lib\passes\passregistry.def(120): note: see declaration of
'std::remove_reference::type'
c:\dev\src\llvm\lib\passes\passregistry.def(121): error C2955:
'llvm::RequireAnalysisPass': use of class template requires template argument
list
c:\dev\src\llvm\include\llvm\ir\passmanager.h(1247): note: see declaration of
'llvm::RequireAnalysisPass'
c:\dev\src\llvm\lib\passes\passregistry.def(120): error C2672:
'llvm::PassManager>::addPass': no
matching overloaded function found
with
[
IRUnitT=llvm::Function
]
I reduced it to:
#include
template struct PassInfoMixin
{
};
template
struct Templ : PassInfoMixin>
{
};
struct A
{
};
struct TargetMachine
{
A foo() { return {}; }
};
bool parseFunctionPass() {
TargetMachine *TM;
Templfoo())>::type> t;
return false;
}
C:\dev\src\playground\cpp>cl.exe rmref.cpp
Microsoft (R) C/C++ Optimizing Compiler Version 19.15.26608.1 for x64
Copyright (C) Microsoft Corporation. All rights reserved.
rmref.cpp
rmref.cpp(24): error C2275: 'std::remove_reference::type': illegal use of
this type as an expression
rmref.cpp(24): note: see declaration of 'std::remove_reference::type'
rmref.cpp(24): error C2923: 'Templ': 'std::remove_reference::type' is not a
valid template type argument for parameter 'T'
rmref.cpp(24): note: see declaration of 'std::remove_reference::type'
rmref.cpp(24): error C2133: 't': unknown size
rmref.cpp(24): error C2512: 'Templ': no appropriate default constructor
available
rmref.cpp(9): note: see declaration of 'Templ'
--
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 38119] New: lld generates unlinkable corrupt object from large objects with complex symbols.
https://bugs.llvm.org/show_bug.cgi?id=38119 Bug ID: 38119 Summary: lld generates unlinkable corrupt object from large objects with complex symbols. Product: lld Version: unspecified Hardware: PC OS: FreeBSD Status: NEW Severity: normal Priority: P Component: ELF Assignee: unassignedb...@nondot.org Reporter: takaw...@init-main.com CC: llvm-bugs@lists.llvm.org When linking -- 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 38120] New: LTO build gives assertion
https://bugs.llvm.org/show_bug.cgi?id=38120
Bug ID: 38120
Summary: LTO build gives assertion
Product: new-bugs
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: f...@flametop.co.uk
CC: elevi...@accesssoftek.com, llvm-bugs@lists.llvm.org
Change 'r336059 - [Evaluator] Improve evaluation of call instruction' appears
to have introduced a compiler assertion when compiling this example code.
NB. This code sample is technically invalid C++ as it breaks the one definition
rules, but it used to compile benignly before the change.
$ cat a.cpp
class dYj typedef *(*vfY)(class lYY *);
struct Mxl {
Mxl(vfY, int, const char *, int, const char *, const char *, const char *,
bool);
vfY AvQ;
};
Mxl::Mxl(vfY, int, const char *, int, const char *, const char *, const char *,
bool) {}
$ cat b.cpp
class dYj;
struct Mxl {
Mxl(dYj *(class lYY *), int, const char *, int, const char *, const char *,
const char *, bool = true);
} a(0, 0, 0, 0, 0, 0, 0);
$ clang++ -c a.cpp -o a.cpp.o -flto
$ clang++ -c b.cpp -o b.cpp.o -flto
$ llvm-lto a.cpp.o b.cpp.o
gives the assertion:
llvm-lto: Casting.h:255: typename llvm::cast_retty::ret_type
llvm::cast(Y*) [with X = llvm::Function; Y = llvm::Constant; typename
llvm::cast_retty::ret_type = llvm::Function*]:
Assertion `isa(Val) && "cast() argument of incompatible type!"' failed.
It would seem better if the compiler could give an error in this case rather
than aborting with an assertion.
--
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 38121] New: gcov profiling is broken on big endian machines
https://bugs.llvm.org/show_bug.cgi?id=38121 Bug ID: 38121 Summary: gcov profiling is broken on big endian machines Product: compiler-rt Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: profile Assignee: unassignedb...@nondot.org Reporter: mcastelluc...@mozilla.com CC: llvm-bugs@lists.llvm.org, sfert...@ca.ibm.com, syza...@ca.ibm.com, uweig...@de.ibm.com The tests I added in r336365 (two of which are supposed to pass both before and after the patch) seem to fail on big endian machines, e.g. on s390x (https://reviews.llvm.org/D48538#1154385) and on ppc64be because the hit counts are wrong. -- 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 7771 in oss-fuzz: llvm/llvm-opt-fuzzer--x86_64-gvn: Null-dereference READ in llvm::FuncletPadInst::FuncletPadInst
Updates: Labels: Deadline-Approaching Comment #4 on issue 7771 by sheriff...@chromium.org: llvm/llvm-opt-fuzzer--x86_64-gvn: Null-dereference READ in llvm::FuncletPadInst::FuncletPadInst https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=7771#c4 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 http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 38050] -fdebug-prefix-map is a no-op for .S files
https://bugs.llvm.org/show_bug.cgi?id=38050 Paul Robinson changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #4 from Paul Robinson --- D48988 committed in r336680 (LLVM) D48989 committed in r336685 (Clang) -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 38091] No support for gcc "error" function attribute
https://bugs.llvm.org/show_bug.cgi?id=38091 NARUSE, Yui changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #2 from NARUSE, Yui --- (In reply to Richard Smith from comment #1) > It looks to me like it's just the *implementation* of the rb_scan_args check > that depends on the optimizer in order to implement the check (that is, it > generates the "bad" call unconditionally, but within a sea of conditional > expressions that make the call unreachable in the good cases), and that the > diagnose_if attribute is actually better suited to this kind of enforcement > than the GCC error attribute is. Indeed, the __attribute__((error)) > enforcement will not work at -O0, and is compiled out in that case (by > checking the __OPTIMIZE__ macro), but a diagnose_if approach would work at > -O0. > > Please correct me if I've misunderstood any of the details here. But I'm > inclined to say that Clang provides a superior alternative here. Indeed. I sometimes tried to use diagnose_if but failed because of Bug 38095 and Bug 38111. Now I have a workaround and understand that the idea of Bug 38091 is come from misunderstanding. I committed https://github.com/ruby/ruby/commit/4b2f2225e4a94cd2eeb8f9c8f867192f50dd6b32, and mark this ticket as RESOLVED, thanks! -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 38122] New: Current clang segfaults while trying to build itself
https://bugs.llvm.org/show_bug.cgi?id=38122 Bug ID: 38122 Summary: Current clang segfaults while trying to build itself Product: clang Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: -New Bugs Assignee: unassignedclangb...@nondot.org Reporter: b...@linaro.org CC: llvm-bugs@lists.llvm.org Created attachment 20546 --> https://bugs.llvm.org/attachment.cgi?id=20546&action=edit GlobalOpt-e07546.cpp (xz compressed to fit size limit) This happens when using the Android toolchain builder on current llvm/clang (the builder essentially builds a stage1 compiler for the host it's running on, then uses that compiler to build a stage2 compiler in Android config): 1. parser at end of file 2. Per-module optimization passes 3. Running pass 'CallGraph Pass Manager' on module '/home/bernhard.rosenkranzer/upstream-toolchain/toolchain/llvm/lib/Transforms/IPO/GlobalOpt.cpp'. /home/bernhard.rosenkranzer/upstream-toolchain/out/stage1-install/bin/clang-7[0x177bda4] /home/bernhard.rosenkranzer/upstream-toolchain/out/stage1-install/bin/clang-7(_ZN4llvm3sys17RunSignalHandlersEv+0xee)[0x1779c9e] /home/bernhard.rosenkranzer/upstream-toolchain/out/stage1-install/bin/clang-7[0x177bf62] /lib/x86_64-linux-gnu/libpthread.so.0(+0x10330)[0x7f8c2a937330] /home/bernhard.rosenkranzer/upstream-toolchain/out/stage1-install/bin/clang-7(_ZN4llvm12scc_iteratorIPNS_9CallGraphENS_11GraphTraitsIS2_EEE11DFSVisitOneEPNS_13CallGraphNodeE+0x18c)[0xe72a1c] /home/bernhard.rosenkranzer/upstream-toolchain/out/stage1-install/bin/clang-7[0x10fff9c] /home/bernhard.rosenkranzer/upstream-toolchain/out/stage1-install/bin/clang-7(_ZN4llvm6legacy15PassManagerImpl3runERNS_6ModuleE+0x347)[0x1307687] /home/bernhard.rosenkranzer/upstream-toolchain/out/stage1-install/bin/clang-7(_ZN5clang17EmitBackendOutputERNS_17DiagnosticsEngineERKNS_19HeaderSearchOptionsERKNS_14CodeGenOptionsERKNS_13TargetOptionsERKNS_11LangOptionsERKN4llvm10DataLayoutEPNSE_6ModuleENS_13BackendActionENSt3__110unique_ptrINSE_17raw_pwrite_streamENSL_14default_deleteISN_+0x4583)[0x18ee0b3] /home/bernhard.rosenkranzer/upstream-toolchain/out/stage1-install/bin/clang-7[0x1ec87af] /home/bernhard.rosenkranzer/upstream-toolchain/out/stage1-install/bin/clang-7(_ZN5clang8ParseASTERNS_4SemaEbb+0x214)[0x22d2f04] /home/bernhard.rosenkranzer/upstream-toolchain/out/stage1-install/bin/clang-7(_ZN5clang14FrontendAction7ExecuteEv+0x7b)[0x1e32d2b] /home/bernhard.rosenkranzer/upstream-toolchain/out/stage1-install/bin/clang-7(_ZN5clang16CompilerInstance13ExecuteActionERNS_14FrontendActionE+0x4c8)[0x1da6fc8] /home/bernhard.rosenkranzer/upstream-toolchain/out/stage1-install/bin/clang-7(_ZN5clang25ExecuteCompilerInvocationEPNS_16CompilerInstanceE+0x6d4)[0x1ec2fb4] /home/bernhard.rosenkranzer/upstream-toolchain/out/stage1-install/bin/clang-7(_Z8cc1_mainN4llvm8ArrayRefIPKcEES2_Pv+0x471)[0xc23b71] /home/bernhard.rosenkranzer/upstream-toolchain/out/stage1-install/bin/clang-7(main+0xa19)[0xc1fd69] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5)[0x7f8c29a3ef45] /home/bernhard.rosenkranzer/upstream-toolchain/out/stage1-install/bin/clang-7[0xc1f029] clang-7: error: unable to execute command: Segmentation fault (core dumped) clang-7: error: clang frontend command failed due to signal (use -v to see invocation) Android (dev based on r328903) clang version 7.0.2 (https://android.googlesource.com/toolchain/clang 695bff9aae9838e22bfe52909106a76e09782fca) (https://git.llvm.org/git/llvm 321acf353eee88d5e2a2fa6999c57634b9779479) (based on LLVM 7.0.2svn) Target: x86_64-unknown-linux-gnu Thread model: posix InstalledDir: /home/bernhard.rosenkranzer/upstream-toolchain/out/stage1-install/bin clang-7: note: diagnostic msg: PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash backtrace, preprocessed source, and associated run script. clang-7: note: diagnostic msg: PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: Preprocessed source(s) and associated run script(s) are located at: clang-7: note: diagnostic msg: /tmp/GlobalOpt-e07546.cpp clang-7: note: diagnostic msg: /tmp/GlobalOpt-e07546.sh clang-7: note: diagnostic msg: (The odd "7.0.2" version and the "based on 328903" claim are relics from the build scripts; actual source I'm building is 336677.) -- 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 38107] Aggressive optimization when computing GEP result.
https://bugs.llvm.org/show_bug.cgi?id=38107 Eli Friedman changed: What|Removed |Added Resolution|--- |INVALID Status|NEW |RESOLVED CC||efrie...@codeaurora.org --- Comment #2 from Eli Friedman --- Pointer subtraction is UB if the result pointer doesn't point to the same object as the argument pointer. Given "p" and "p-1" are pointers to the same object, neither one can be null. -- 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 38123] New: Combine and-mask+icmp eq -> icmp ule when mask was all-ones in low bits
https://bugs.llvm.org/show_bug.cgi?id=38123 Bug ID: 38123 Summary: Combine and-mask+icmp eq -> icmp ule when mask was all-ones in low bits Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: Scalar Optimizations Assignee: unassignedb...@nondot.org Reporter: lebedev...@gmail.com CC: llvm-bugs@lists.llvm.org https://rise4fun.com/Alive/W2u https://godbolt.org/g/sCX9A6 This pattern will be produced by Implicit Integer Trucation sanitizer, (https://reviews.llvm.org/D48958) in unsigned case, therefore it is probably a good idea to improve it. -- 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 38124] New: Windows-specific entry points are not marked as extern C
https://bugs.llvm.org/show_bug.cgi?id=38124 Bug ID: 38124 Summary: Windows-specific entry points are not marked as extern C Product: clang Version: trunk Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: C++ Assignee: unassignedclangb...@nondot.org Reporter: ja...@codeweavers.com CC: dgre...@apple.com, llvm-bugs@lists.llvm.org When building using clang (not clang-cl) with mingw, entry points like wmain or WinMain implemented in C++ are not found at link time. GCC just implicitly marks wmain, WinMain, wWinMain and DllMain as extern "C": https://github.com/gcc-mirror/gcc/commit/f9f68d3567c26e5324e8f365431cf1a0b13c26ef#diff-9fc0a55518658f06bb07fd3c9fd9352f clang also has logic for that in FunctionDecl::isMSVCRTEntryPoint, which is used in MicrosoftMangleContextImpl::shouldMangleCXXName, but it's not applied for mingw targets. -- 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 37495] LLDB shows wrong results when execute 'register read' at non-zero frame on Windows
https://bugs.llvm.org/show_bug.cgi?id=37495 Stella Stamenova changed: What|Removed |Added Fixed By Commit(s)||a66b5f7 CC||sti...@microsoft.com Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #1 from Stella Stamenova --- This was fixed in [a66b5f7] [windows] LLDB shows the wrong values when register read is executed at a frame other than zero -- 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 38125] New: clang miscompiles at -O2 and above on valid code
https://bugs.llvm.org/show_bug.cgi?id=38125
Bug ID: 38125
Summary: clang miscompiles at -O2 and above on valid code
Product: clang
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: LLVM Codegen
Assignee: unassignedclangb...@nondot.org
Reporter: helloqi...@gmail.com
CC: llvm-bugs@lists.llvm.org
It seems to be a recent regression.
$ clang-trunk -v
clang version 7.0.0 (trunk 336646)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /usr/local/bin
$ clang-trunk abc.c ; ./a.out
0
FFFA
$ clang-trunk -O2 abc.c ; ./a.out
0
5
$ cat abc.c
int printf(char *, ...);
int a, c;
unsigned short b;
short d;
void fn1(char p1) { a = a ^ p1; }
void fn2(long p1) {
a = p1 & 5;
fn1(p1 >> 56);
}
int main() {
for (; c >= 0; c--)
d = -3L;
d |= b;
fn2(d);
printf("%d\n", b);
printf("%X\n", a);
}
--
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 38050] -fdebug-prefix-map is a no-op for .S files
https://bugs.llvm.org/show_bug.cgi?id=38050
Dan McGregor changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED |---
CC||dan.mcgre...@usask.ca
--- Comment #5 from Dan McGregor ---
This *nearly* fixes the issue. It doesn't handle the case where the full path
to the assembly file is specified on the command line. This is after the code
was committed:
$ clang-7 -g -c -o hello.o $PWD/hello.c -fdebug-prefix-map=$PWD=/src_root
$ strings hello.o|grep $PWD
$ clang-7 -g -c -o crti.o $PWD/crti.S -fdebug-prefix-map=$PWD=/src_root
$ strings crti.o|grep $PWD
/tmp/test/crti.S
The compilation directory is changed correctly and the DW_TAG_label values are
correct, but not DW_TAG_compile_unit:
$ llvm-dwarfdump crti.o
crti.o: file format ELF64-x86-64
.debug_info contents:
0x: Compile Unit: length = 0x0119 version = 0x0002 abbr_offset =
0x addr_size = 0x08 (next unit at 0x011d)
0x000b: DW_TAG_compile_unit
DW_AT_stmt_list (0x)
DW_AT_low_pc (0x)
DW_AT_high_pc (0x0004)
DW_AT_name("/tmp/test/crti.S")
DW_AT_comp_dir("/src_root")
DW_AT_producer("clang version 7.0.0 (based on LLVM 7.0.0)")
DW_AT_language(DW_LANG_Mips_Assembler)
0x00ea: DW_TAG_label
DW_AT_name ("init")
DW_AT_decl_file ("/src_root/crti.S")
DW_AT_decl_line (16)
DW_AT_low_pc(0x)
DW_AT_prototyped(0x00)
0x0101: DW_TAG_unspecified_parameters
0x0102: NULL
0x0103: DW_TAG_label
DW_AT_name ("fini")
DW_AT_decl_file ("/src_root/crti.S")
DW_AT_decl_line (23)
DW_AT_low_pc(0x)
DW_AT_prototyped(0x00)
0x011a: DW_TAG_unspecified_parameters
0x011b: NULL
0x011c: NULL
--
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 38126] New: lld doesn't normalize pdb paths leading to paths such as debug_component\./base.dll.pdb
https://bugs.llvm.org/show_bug.cgi?id=38126
Bug ID: 38126
Summary: lld doesn't normalize pdb paths leading to paths such
as debug_component\./base.dll.pdb
Product: lld
Version: unspecified
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: COFF
Assignee: unassignedb...@nondot.org
Reporter: brucedaw...@chromium.org
CC: llvm-bugs@lists.llvm.org
Chrome's build system passes a mixture of forward and back slashes as path
separators. link.exe normalizes all of these and creates a minimal/canonical
path to the PDB inside of the PDB file. This can be seen with:
> dumpbin /headers base.dll | find /i "rsds"
Typical output is like this:
5B36C745 cv50 00461348 460348Format: RSDS,
{841F5EF3-1C48-4817-A3D5-C7F30CD90E9D}, 7,
c:\src\chromium3\src\out\debug_component\./base.dll.pdb
In particular note the "debug_component\./base.dll.pdb" portion. With link.exe
this is "debug_component\base.dll.pdb"
This is important because with recent versions of WPA (maybe only with the most
recent version?) this prevents symbol loading from working, completely.
This makes ETW profiling of Chrome somewhere between impossible and extremely
difficult so this is important to fix promptly.
Given an ETW trace you can see the paths which it is using for symbol lookup
with this command:
"xperf -i "testtrace_with_patched_base.etl" -tle -tti -a symcache -quiet
-imageid -dbgid"
However the dumpbin technique is much simpler.
--
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 38095] function attribute "diagnose_if" doesn't see const char *
https://bugs.llvm.org/show_bug.cgi?id=38095 Richard Smith changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 38127] New: explicit specialization in non-namespace scope
https://bugs.llvm.org/show_bug.cgi?id=38127
Bug ID: 38127
Summary: explicit specialization in non-namespace scope
Product: clang
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: C++
Assignee: unassignedclangb...@nondot.org
Reporter: zhong...@pku.org.cn
CC: dgre...@apple.com, llvm-bugs@lists.llvm.org
The code is as follows:
struct Type {
template
static void Foo() {}
template <>
void Foo<0>() {}
};
void call() { Type::Foo<0>(); }
clang++ accepts the code, but g++ rejects it:
code0.cpp:4:12: error: explicit specialization in non-namespace scope 'struct
Type'
template <>
^
code0.cpp:5:14: error: template-id 'Foo<0>' in declaration of primary template
void Foo<0>() {}
^
The diagnose of g++ looks reasonable, right?
--
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 9347 in oss-fuzz: llvm/clang-fuzzer: Stack-overflow in clang::Lexer::LexTokenInternal
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-07-11 Type: Bug New issue 9347 by ClusterFuzz-External: llvm/clang-fuzzer: Stack-overflow in clang::Lexer::LexTokenInternal https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=9347 Detailed report: https://oss-fuzz.com/testcase?key=6333018036764672 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: 0x7fffe30f0fc0 Crash State: clang::Lexer::LexTokenInternal clang::Lexer::Lex clang::Preprocessor::Lex Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201807080809:201807090754 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=6333018036764672 Issue filed automatically. See https://github.com/google/oss-fuzz/blob/master/docs/reproducing.md for more information. 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 35385] WASM backend generates invalid wasm for undeclared imports
https://bugs.llvm.org/show_bug.cgi?id=35385 Sam Clegg changed: What|Removed |Added Resolution|--- |FIXED Status|REOPENED|RESOLVED --- Comment #35 from Sam Clegg --- Fixed in rL336759 (I hope!) -- 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
