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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
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]
```
The bits/ headers have different include behavior (mostly due to ranges)
that makes it significantly harder to find a configuration working for
C++14, 17, and 20. Instead, create a dedicated modulemap for C++20.
llvm IR naming of private constants (CodeGenModule::createUnnamedGlobalFrom(),
line 1136) will name private symbols without caring about possible name clashes.
We will create these name clashes by marking such private symbols as weak ones,
re-using previously emitted symbols (e.g. in JITDylib::defineImpl() where they
get added to MUDefsOverridden and thus re-used instead of re-emitted).
Let me see what happens when we keep private symbols private. In principle, the
interpreter should have no means fo accessing them from another transaction -
private symbols seem to be function-local ones.
Fixes https://github.com/root-project/root/pull/12183
UNIX terminals, e.g. vt100, send escape sequences for many special
key combinations. Entering the history search mode assigned a specific
meaning to the ESC character and disabled the processing of escape
sequences, thus accidentally printing some characters that are part
of a CSI.
As a workaround, avoid changing the meaning of ESC; users can still
use the well-known `ESC ESC` sequence (or any other editor command,
e.g. move left/right) to exit the history search mode.
This change only affects UNIX terminals.
Closes issue #10209.
These commands, bound respectively to `ESC l` and `ESC u`, should {lower,upper}case
the next word; however, only the first character was changed.
Fixes#10136.
This editor command (usually binded to Ctrl+T), transposes the character located
at the cursor and the one to its left.
However, its behavior was incorrect if the cursor was at end of the line,
invoking `std::string::operator[]()` passing an index that is out of bounds.
In that case, as per GNU Readline behavior, it should swap the two last
characters.
Closes#10133.
This change is equivalent to the popular GNU Readline keybinding
```
"\e[3;5~": kill-word
```
As a requirement, the `[3;5~` CSI was added in StreamReaderUnix.cpp. No
additional changes required to StreamReaderWin.cpp.
Writes the `\033[2J\033[H` sequence to clear the visible part of the screen.
For Windows, this requires to temporarily enable processing of VT control
sequences.
Enable fast word movement à la Xterm (using Ctrl+Left and Ctrl+Right). Most
users coming from a GUI (GTK+, Win32, etc.) will find this convenient, but also
Archlinux users, given that the default `inputrc` file for GNU Readline providesthese bindings (see https://wiki.archlinux.org/title/Readline#Fast_word_movement).
This makes all functions end up in the same text section, which is
important for TCling on macOS to catch exceptions from constructors:
Stack unwinding requires information about program addresses to find
out which objects to destroy and what code should be called to handle
the exception. These addresses are relocated against a single __text
section when loading the produced MachO binary, which breaks if the
call sites of global constructors end up in a separate init section.
Fixes ROOT-10703 and ROOT-10962
(cherry picked from commit 028fcca0fa76111877751df876cf13968be602f9)
This new release includes some improvements:
* Improvements in the array handling in the Error Estimation Framework
* Fixed numerical stability of the pow pushforward
* Fixed handling of for-loop conditions in reverse mode
* LLVM15 Support
See more at: https://github.com/vgvassilev/clad/blob/v1.1/docs/internalDocs/ReleaseNotes.md
The function EnforceInitOrder() was using ImplicitlyDefineFunction()
as a shortcut to define a function returning an int. Future upgrades
of LLVM will add an assert in that function because it is not allowed
to be used when compiling C++, which Cling obviously does.
Do not register LLVMSupport as a library when it should be a component
LLVM component must be registered as LLVM_LINK_COMPONENTS to be
compatible with LLVM Dylib. Otherwise they are loaded twice in the final
binary, once through LLVM Dylmib and once through individual component,
and this results in some options being registered twice.
Fixroot-project/cling#440
m_JIT.getSymbolAddress() invokes the symbol materializers, which compile (which
is sort of okay) but also try autoloading (which totally is not okay).
Instead, implement a function to search existing JIT symbols.
This can be accelerated by looking up the whole set of symbols, instead of doing it
symbol by symbol. I leave that refactoring for later...
With the upgrade to llvm-13, the JIT lost the ability to re-use existing weak
symbols that the JIT had already emitted, instead only looking at dlsym. This
causes a significant increase in JITted symbols, and thus a significant slow-down
of cling / its JIT.
This restores the old behavior, with an identical set of symbols that jet jitted.
With the upgrade, BackendPasses was modifying a TargetMachine that was
not used by SimpleCompiler.
Change that by
- using a SimpleCompiler that uses IncrementalJIT::TM;
- moving the TM creation to IncrementalJIT, and giving access to it
This reduces the runtime of https://github.com/root-project/root/issues/11927
to
- before llvm upgrade: 2.69s
- llvm13, without this commit: ???
- llvm13, with this commit: 2.89s
i.e, a slow-down of 7% (that is likely caused by the different emission
mechanism of Orc-v2; to be confirmed...)
This feature, originally added in commit 22b1606f, was reverted to
make the LLVM upgrade to version 13 easier. This commit adds back
all functionality as it was just before the LLVM upgrade.
LLVM currently has an issue that a completely empty source file is
stored as a nullptr, but DIFile::getSource() does not correctly deal
with this situation. A crash can be observed if just attempting to
launch root.exe with EXTRA_CLING_ARGS="-gdwarf-5 -gembed-source".
See https://reviews.llvm.org/D137152 and https://reviews.llvm.org/D138658
for discussions with upstream.
* Fix compilation with VS 2022 v17.4
This fixes the issue #10875 _HAS_CONDITIONAL_EXPLICIT=0 won't work with VS 2022 17.4
* In fact with LLVM 13 this workaround is not needed anymore
