IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
`--enable-new-dtags` is needed in some toolchains to emit the new ELF dynamic
tags, i.e. RUNPATH.
Per ld(1) manual page: `By default, the new dynamic tags are not created.`
Clang diagnostic verification was unhappy with the previous state of
affairs. Move affected `expected-(warning|note)` markers to `Macros.h`.
Apparently, as Jonas Hahnfeld found, this failure originated in commit
8deb57c04a5ceea96533d095092fcd4f71d1df94, but is not to be reverted
per discussion in https://github.com/root-project/root/pull/12454.
The order in which declarations are removed makes a difference, e.g.
`MaybeRemoveDeclFromModule()` may require access to type information to
make up the mangled name.
Thus, we segregate declarations to be removed in `TagDecl`s (i.e., struct
/ union / class / enum) and other declarations. Removal of `TagDecl`s
is deferred until all the other declarations have been processed.
Declarations in each group are iterated in reverse order.
Fixes#12457.
Since adding bits/utility.h in commit e9a8c48e4f, a C++14 build with
GCC 12 (and potentially also other compiler versions) failed with
```
While building module 'Core':
While building module 'std' imported from input_line_1:1:
In file included from <module-includes>:38:
/opt/gcc/12.2.0/include/c++/12.2.0/functional:337:35: error: missing '#include <bits/utility.h>'; 'tuple_size' must be declared before it is used
= typename enable_if<(__i < tuple_size<_Tuple>::value),
^
/opt/gcc/12.2.0/include/c++/12.2.0/bits/utility.h:49:12: note: declaration here is not visible
struct tuple_size;
^
```
Apparently, once the module is declared, it must also be enabled for
C++14 and not restricted with cplusplus17.
In principle, for a TemplateDecl, `isDefinition()` issues a recursive
call passing the templated decl as a parameter. A `ConceptDecl` is
derived from `TemplateDecl`, however, it should always be considered
a definition.
Also, update the DeclShadowing test incorporating a C++20 concept.
Fixes#12779.
Make `FilteringDiagConsumer` also ignore -Wunused-result. Whether or not
such diagnostic is filtered depends on `CompilationOptions::IgnorePromptDiags`.
In particular, `IgnorePromptDiags` should _only_ be enabled for code parsed
via `Interpreter::EvaluateInternal()`. Thus, as of this commit `IgnorePromptDiags`
defaults to 0 in `makeDefaultCompilationOpts()`
The observable effect of this change is ignoring `-Wunused-result` for
wrapped code, e.g.
```c++
[[nodiscard]] int f() { return 0; }
// This yields `warning: ignoring return value of function declared with 'nodiscard' attribute [-Wunused-result]`
void g() { f(); }
f(); // but this should not
```
It is needed for C++11 support of #include <chrono>. Failures:
```
Processing /home/sftnight/build/night/LABEL/ROOT-fedora36/SPEC/default/V/master/root/tutorials/multicore/mt201_parallelHistoFill.C...
In file included from input_line_10:1:
/home/sftnight/build/night/LABEL/ROOT-fedora36/SPEC/default/V/master/root/tutorials/multicore/mt201_parallelHistoFill.C:55:51: error: no member named 'duration' in namespace 'std::chrono'
std::this_thread::sleep_for(std::chrono::duration<double, std::nano>(500));
~~~~~~~~~~~~~^
```
and
```
root [11] #include <bits/chrono.h>
/home/sftnight/build/night/LABEL/ROOT-fedora36/SPEC/default/V/master/build/etc/cling/std.modulemap:432:10: error: module 'std.bits/chrono.h' requires feature 'cplusplus17'
module "bits/chrono.h" [optional] {
^
ROOT_prompt_11:1:10: note: submodule of top-level module 'std' implicitly imported here
^
```
isysroot influences where clang will pick up libc++. Without this, and with
Xcode 14.3, cling will use libc++ from Xcode (or the command line tools) rather
than stdc++ from the macOS SDK, as clang would normally use. Passing the isysroot
(which point to the SDK) fixes this.
This solves build errors such as:
```
While building module 'Core':
While building module 'std' imported from input_line_1:1:
In file included from <module-includes>:17:
In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/math.h:309:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/type_traits:462:1: error: cannot template a using declaration
using _BoolConstant _LIBCPP_NODEBUG_TYPE = integral_constant<bool, _Val>;
^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/type_traits:462:21: error: C++ requires a type specifier for all declarations
using _BoolConstant _LIBCPP_NODEBUG_TYPE = integral_constant<bool, _Val>;
^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/type_traits:462:68: error: use of undeclared identifier '_Val'
using _BoolConstant _LIBCPP_NODEBUG_TYPE = integral_constant<bool, _Val>;
^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/type_traits:462:73: error: expected '(' for function-style cast or type construction
using _BoolConstant _LIBCPP_NODEBUG_TYPE = integral_constant<bool, _Val>;
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^
```
This reverts commit a4c07502a3e76c82f30828200f5fe4ae935ac166.
While this itself might not cause build issues, the related commit 90ffa89ae4 does;
handle them together.
This reverts commit 90ffa89ae46b48c634547d6abd861a524a5d27c7.
It causes build failures on GCC 12.2.1 / c++17 with
```
[ 70%] Generating G__Core.cxx, ../lib/Core.pcm
In file included from input_line_7:111:
/home/linev/build/webgui/include/ROOT/RDirectoryEntry.hxx:31:33: error: missing '#include <bits/chrono.h>'; 'system_clock' must be declared before it is used
using clock_t = std::chrono::system_clock;
^
/usr/include/c++/12/bits/chrono.h:1110:12: note: declaration here is not visible
struct system_clock
^
In module 'std' imported from input_line_1:1:
/usr/include/c++/12/bits/move.h:204:11: error: missing '#include <bits/chrono.h>'; 'time_point' must be defined before it is used
_Tp __tmp = _GLIBCXX_MOVE(__a);
^
/home/linev/build/webgui/include/ROOT/RDirectoryEntry.hxx:89:4: note: in instantiation of function template specialization 'std::swap<std::chrono::time_point<std::chrono::system_clock, std::chrono::duration<long, std::ratio<1, 1000000000>>>>' requested here
swap(fDate, other.fDate);
^
/usr/include/c++/12/bits/chrono.h:856:14: note: definition here is not reachable
struct time_point
```
Since the upgrade to LLVM 13, the JIT infrastructure takes ownership
of the Module. After JIT compilation, we get back a (const) pointer
to the compiled module.
This fixes the Cling test ErrorRecovery/StoredState.C.
These headers are part of cling, not user code, so starting
with the current directory is pointless and can actually be
counterproductive.
This helps with https://github.com/root-project/root/issues/12409
but not enough; any dictionary header will still try to access "./".
This is required on RISC-V where Linux uses the lp64d ABI that allows
the usage of floating point registers to pass arguments. It seems to
work out-of-the-box upstream in clang-repl which passes through the
function initTargetOptions in clang/lib/CodeGen/BackendUtil.cpp with
the same effect.
RuntimeDyld does not support RISC-V, so it makes sense to enable
JITLink by default. This also makes relocations work without support
for a large code model.
See the equivalent change upstream in https://reviews.llvm.org/D129092,
committed for LLVM 15 in a4e2c1f762
The routines __aarch64_* are defined in the static library libgcc.a
and not necessarily included in libCling or otherwise present in the
process, so the interpreter has a hard time finding them.
Fixes#12294
Recent gcc updates somehow make experimental/string_view available through
module string_view. Then it wrongly decides it needs to include
"bits/ranges_base.h" which is a c++14 header and breaks the compilation in case
of c++11.
This patch adds a proper experimental/string_view to disallow such shadowing.
* Fix modules and modules.idx generation on Windows and disable a few more modules causing potential crashes
* Introduce a new TROOT::GetSharedLibDir() method to reduce the need of #ifdef R__WIN32
* Use the value of ROOT_GET_LIBRARY_OUTPUT_DIR instead of CMAKE_RUNTIME_OUTPUT_DIRECTORY (which is the same anyway)
* cleanup the code
* Remove unnecessary check
Otherwise LLJIT's constructor will ask the LLJITBuilder's JTMB to
create a DataLayout. As we don't propagate the JTMB (yet -- we
probably should!), this will be wrong if target features influence
the DataLayout.
This should fix#12293.
We know exactly which target triple and features the CompilerInstance
wants, we don't need to (and probably must not) second-guess that. This
brings us closer to upstream clang-repl and also includes the change of
https://reviews.llvm.org/D128853 which is crucial for RISC-V.
I missed this in commit 3ff7c1e8e2 and it seems to work by chance on
macOS, but this is needed on Linux: Before, CLING_JTLINK=1 on x86_64
complained about "Unspported personality pointer encoding 0x00" and
crashed entirely on RISC-V.
We introduce an enum which mirrors the type kind and we use it in the getAs and
castAs operations to allow the compiler/interpreter to see all of the functions
and potentially inline them.
This patch brings the performance to similar levels with what we have in the
master.
These interfaces assume we know the type and we should compare if the underlying
type is the one we expect when using the setters and getters. Unfortunately,
this is not the case and we need to further investigate.
This interface allows us to set a value and deduce its corresponding type very
efficiently. This is useful when we use cling::Value to model input arguments
for a function call in the JIT (eg. via TClingCallFunc).
That patch essentially makes cling::Value to hold a value and a type that
correctly models the compiled code.
The improvements are:
* We provide getX and setX interfaces instead of returning the address for the
non const methods. This allows us to be more consistent in terms of
lifetimes as now users cannot take the address of block of memory which can
be freed by the cling::Value.
* We remove the storage types and we rely on the clang::Type which we have in
the cling::Value.
Here we enumerate most of the builtin types and we the generate template
specializations for all of them which are capable to perform the correct
conversions.
The custom memory manager is only needed to avoid freeing the memory
segments; the default InProcessMemoryManager (which is mostly copied)
already does slab allocation to keep all segments together which is
needed for exception handling support.
A limitation of this rudimentary support is that CLING_DEBUG and
CLING_PROFILE do not work, they need to be registered as plugins.
Add missing `const` in `{DelayCall,MacroDirective}Info::operator==`
and `operator!=`. This fixes the following warnings in C++20
```
interpreter/cling/lib/Interpreter/Transaction.cpp:173:23: warning: ISO C++20 considers use of overloaded operator '!=' (with operand types 'cling::Transaction::DelayCallInfo' and 'cling::Transaction::DelayCallInfo') to be ambiguous despite there being a unique best viable function with non-reversed arguments [-Wambiguous-reversed-operator]
interpreter/cling/lib/Interpreter/Transaction.cpp:218:21: warning: ISO C++20 considers use of overloaded operator '==' (with operand types 'cling::Transaction::MacroDirectiveInfo' and 'cling::Transaction::MacroDirectiveInfo') to be ambiguous despite there being a unique best viable function [-Wambiguous-reversed-operator]
```
