Hi Gerald,
On 21.01.23 12:58, Gerald Pfeifer wrote:
Is it maybe a little tough to bump the minimal requirement to something
only released yesterday? Or is this not an issue looking at the use cases?
(Genuine question. Maybe nothing to worry at all.)
On the technical side, the newer newlib version is not yet required. But
it looks as if it soon makes a lot of sense to have it:
For the AMGCN stack builtins, they currently expand to the same registers
and offset calculations as hard-coded in newlib (older version or if the
builtin is not available). – If the stack allocation is changed to
non-threadprivate, this will change the location. With the builtins, just
recompiling newlib (+libgomp) will work (API preserved but not ABI).
[Andrew to provide the stack patch; then me for the 2-line patch to enable
OpenMP's reverse offload.]
(Hen-egg problem in terms of compilation as newlib is compiled by GCC.
Probably only detectable by running it on the offload device and checking
whether it fails - not practical for a cross-compiler build.)
For AMDGCN's vectorization functions: Those can lead to a significant
performance
advantage. I know that newlib only used some builtins if they are available.
I think AMDGCN will emit code using the new libm functions, which in turn
newlib only generates if GCC supports certain new builtins. (hen-egg problem,
if my assumptions are correct.)
[I think Kwok will provide this patch - he did implement the funcs in newlib.]
nvptx: Thomas' patch for libgfortran(*) effectively requires the newer newlib -
albeit one could imaging that there could be a configure check.
[(*) "nvptx, libgfortran: Switch out of "minimal" mode",
approved but awaiting approval of another patch)]
Thus:
As nvptx/amdgcn is (mostly) about offloading code, newlib is compiled usually
alongside
GCC (e.g. in SUSE, Debian/Ubuntu, ...); additionally, there is static linking
such that
mixing old vs. new libraries is less likely. Hence, requiring the newest
version of newlib
together with the newest compiler shouldn't be a problem in my opinion.
And the if documented now, it cannot be forgotten by the time the pending
patches get
committed... ;-)
And, this predates your patch, in one instance we refer to Newlib (upper
case9, in the other to newlib (lower case). Would it make sense to
converge to one?
Maybe, but the question is what to use? The project's webpage has on the first
page:
"patch submissions to Newlib" and "automate the testing of newlib".
As uppercase, we have:
gcc/d/implement-d.texi:@code{CRuntime_Newlib} is set when Newlib is the default
C library.
gcc/doc/install.texi:Use Newlib (4.3.0 or newer).
gcc/doc/invoke.texi:This option requires Newlib Nano IO, so GCC must be
configured with
gcc/doc/invoke.texi:Newlib.
gcc/doc/invoke.texi:Specify the PRU MCU variant to use. Check Newlib for the
exact list of
gcc/doc/sourcebuild.texi:Target supports Newlib.
gcc/doc/sourcebuild.texi:the code size of Newlib formatted I/O functions.
gcc/po/gcc.pot:"Newlib Nano IO."
(Add a missing "Requires " to complete the sentence.)
and as lowercase:
gcc/doc/install.texi:Specifies that @samp{newlib} is
gcc/doc/install.texi:@samp{newlib}.
gcc/doc/install.texi:RTEMS configurations, which currently use newlib. The
option is
denotes a configure argument.)
gcc/doc/invoke.texi:newlib board library linking. The default is
@code{or1ksim}.
gcc/doc/invoke.texi:select linker and preprocessor options for use with newlib.
gcc/doc/sourcebuild.texi:@item newlib
(Side remark: While some @sample{newlib} in install.texi refer to a value to
a configure argument, in the quote above it refers to the library itself.)
gcc/po/gcc.pot:msgid "Configure the newlib board specific runtime. The default is
or1ksim."
gcc/po/gcc.pot:"This used to select linker and preprocessor options for use with
newlib."
libstdc++-v3/doc/xml/manual/configure.xml: vintage (2.3 and newer), 'gnu'
is automatically selected. On newlib-based
libstdc++-v3/doc/xml/manual/configure.xml: systems
(<code>'--with_newlib=yes'</code>) and OpenBSD, 'newlib' is
libstdc++-v3/doc/xml/manual/evolution.xml:<para>A new clocale model for newlib is
available.</para>
Thoughts?
Thanks for the comments!
Tobias
-----------------
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht
München, HRB 106955
