Re: [Patch] install.texi: Bump newlib version for nvptx + gcn

[Tobias Burnus <tobias@codesourcery.com>]

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