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

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

[Tobias Burnus]

[-- Attachment #1: Type: text/plain, Size: 1931 bytes --]

A new newlib version has been realized yesterday: newlib-4.3.0 (yearly snapshot)
https://sourceware.org/pipermail/newlib/2023/020141.html
https://sourceware.org/ftp/newlib/index.html → 2023-01-20: newlib-4.3.0.20230120.tar.gz (8.8 MB)

For both nvptx and GCN, the new version is recommended - mostly because of upcoming changes
and not because GCC mainline already needs them currently. But soon it will, hence:

The attached patch bumps the minimal version instead of keeping the old version and only
recommending the newer one.

Comments? Suggestions? – If there are none, I intent to commit the patch as obvious.

Tobias

PS: For AMDGCN, the newlib uses (if available) some new builtins: one provided by GCC 13
but having the currently same value as the hard coded registers that get used if the builtin
s not available - to permit a change to non-private stack variables (required for reverse offload;
will require recompilation of newlib).
And to support vectorized math functions. (The gcn builtins still have to be added to GCC 13;
if the builtins aren't available, newlib won't use them - hence, also will later require a
rebuild with the newer newlib).

For nvptx, newlib added some features to permit building a non-minimal version of libgfortran,
which also permits I/O. The libgfortran changes have been approved but the GCC nvptx patches
still have to be reviewed (and would also require a pending nvptx-tools pull request).

BTW: The gcn vect math and the nvptx changes went into newlib in the last few days. Thus, if
you have use the 'git' version it won't have the changes, unless you updated at least yesterday.
-----------------
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

[-- Attachment #2: install-newlib.diff --]
[-- Type: text/x-patch, Size: 1807 bytes --]

install.texi: Bump newlib version for nvptx + gcn

Before, newlib 3.2 was required for amdgcn and 3.1 for nvptx.
Now recommended is 4.3.0 which was just released on 2023-01-20.

While currently the old versions would work fine, upcoming GCC 
changes depend on a newer newlib. Thus, the minimal version is
bumped instead of just recommending the new version.

For GCN, the bump is in preparation for permitting non-threadlocal
stack variables and vectorized math functions - both scheduled for
GCC 13 and added to newlib in 4.3.0.

For nvptx, this includes an emulated clock (commit 6bb96d13a),
a calloc fix (5fca4e0f1) and changes to permit libgfortran to be
compiled with I/O support instead of only in minimal mode.
(Patch approved for GCC 13 but pending on a nvtpx patch.)

gcc/ChangeLog:

	* doc/install.texi (amdgcn, nvptx): Require newlib 4.3.0.

diff --git a/gcc/doc/install.texi b/gcc/doc/install.texi
index ccc8d15fd08..b1861a6a437 100644
--- a/gcc/doc/install.texi
+++ b/gcc/doc/install.texi
@@ -3855,7 +3855,7 @@ Instead of GNU Binutils, you will need to install LLVM 13.0.1, or later, and cop
 @file{bin/llvm-ar} to both @file{bin/amdgcn-amdhsa-ar} and
 @file{bin/amdgcn-amdhsa-ranlib}.
 
-Use Newlib (3.2.0, or newer).
+Use Newlib (4.3.0 or newer).
 
 To run the binaries, install the HSA Runtime from the
 @uref{https://rocm.github.io,,ROCm Platform}, and use
@@ -4672,7 +4672,7 @@ Instead of GNU binutils, you will need to install
 Tell GCC where to find it:
 @option{--with-build-time-tools=[install-nvptx-tools]/nvptx-none/bin}.
 
-You will need newlib 3.1.0 or later.  It can be
+You will need newlib 4.3.0 or later.  It can be
 automatically built together with GCC@.  For this, add a symbolic link
 to nvptx-newlib's @file{newlib} directory to the directory containing
 the GCC sources.

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

[Gerald Pfeifer]

[-- Attachment #1: Type: text/plain, Size: 672 bytes --]

On Sat, 21 Jan 2023, Tobias Burnus wrote:
> A new newlib version has been realized yesterday: newlib-4.3.0 (yearly
> snapshot)
:
> Comments? Suggestions? – If there are none, I intent to commit the patch 
> as obvious.

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.)

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?


Not an objection to the patch - you are the expert - just two (naive) 
questions.

Gerald

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

[Tobias Burnus]

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

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

[Gerald Pfeifer]

On Sat, 21 Jan 2023, Tobias Burnus wrote:
> 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:
:
> 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.

That sounds like a convincing argument. 

>> 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".

I also dug into the newlib web page and other sources and - while my 
personal preference slightly leans towards Newlib - believe newlib is
more established overall.

For the web pages, it's clearer than for our *.texi ones you dug into:

  ~/src/wwwdocs/htdocs> grep -r newlib . | wc -l
  15
  ~/src/wwwdocs/htdocs> grep -r Newlib . | wc -l
  3

> Thoughts?

Let's go for newlib (lowercase) I'd say; if you agree I can take care 
of wwwdocs

Cheers,
Gerald

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

[Tobias Burnus]

On 22.01.23 02:45, Gerald Pfeifer wrote:
>> 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".
> I also dug into the newlib web page and other sources and - while my
> personal preference slightly leans towards Newlib - believe newlib is
> more established overall.
>
> For the web pages, it's clearer than for our *.texi ones you dug into:
>
>    ~/src/wwwdocs/htdocs> grep -r newlib . | wc -l
>    15
>    ~/src/wwwdocs/htdocs> grep -r Newlib . | wc -l
>    3

You need to be careful with those counts as there is not only 'the [nN]ewlib library'
but also flags/configure arguments etc:

gcc/doc/install.texi:@item --with-newlib

gcc/doc/install.texi-@item --with-nds32-lib=@var{library}
gcc/doc/install.texi:Currently, the valid @var{library} is @samp{newlib} or @samp{mculib}.

gcc/doc/install.texi:to nvptx-newlib's @file{newlib} directory to the directory containing
gcc/doc/install.texi:@option{--enable-newlib-io-long-long} options when configuring.

gcc/doc/invoke.texi:@samp{--enable-newlib-nano-formatted-io}.
gcc/doc/invoke.texi:@item -mnewlib
gcc/doc/invoke.texi:@opindex mnewlib

(and a few more).

In the libstdc++-v3/doc/xml/, there are two 'newlib' and one 'Newlib'
(plus a bunch of newlib as filename/argument/config option).

Still, I concur that 'newlib' is still used a bit more often than 'Newlib'.

  * * *

In any case, I concur that it would be nice to unify .texi/.xml and diagnostic
output (twice in config/or1k/elf.opt) - and likewise the wwwdocs pages.
(That elf.opt file has twice 'newlib' and once 'Newlib'.)

-> adds this to the to-do list.

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

[wwwdocs] gcc-6: Consistently lower-case newlib (was: [Patch] install.texi: Bump newlib version for nvptx + gcn)

[Gerald Pfeifer]

On Mon, 23 Jan 2023, Tobias Burnus wrote:
> In any case, I concur that it would be nice to unify .texi/.xml and
> diagnostic
> output (twice in config/or1k/elf.opt) - and likewise the wwwdocs pages.
:
> ->adds this to the to-do list.

Let me help a litte and take care of wwwdocs. Pushed. :)

Gerald


commit 6168a4b67741682ed9168ffdb5cfc6e8bec9557f
Author: Gerald Pfeifer <gerald@pfeifer.com>
Date:   Mon Jan 23 12:35:53 2023 +0100

    gcc-6: Consistently lower-case newlib

diff --git a/htdocs/gcc-6/changes.html b/htdocs/gcc-6/changes.html
index a9f033b1..612ea48d 100644
--- a/htdocs/gcc-6/changes.html
+++ b/htdocs/gcc-6/changes.html
@@ -817,14 +817,14 @@ within strings:
 <h3 id="rtems">RTEMS</h3>
   <ul>
     <li>The RTEMS thread model implementation changed.  Mutexes now
-    use self-contained objects defined in Newlib &lt;sys/lock.h&gt;
+    use self-contained objects defined in newlib &lt;sys/lock.h&gt;
     instead of Classic API semaphores.  The keys for thread specific data and
     the <code>once</code> function are directly defined via &lt;pthread.h&gt;.
-    Self-contained condition variables are provided via Newlib
+    Self-contained condition variables are provided via newlib
     &lt;sys/lock.h&gt;.  The RTEMS thread model also supports C++11
     threads.</li>
 
-    <li>OpenMP support now uses self-contained objects provided by Newlib
+    <li>OpenMP support now uses self-contained objects provided by newlib
     &lt;sys/lock.h&gt; and offers a significantly better performance compared
     to the POSIX configuration of <code>libgomp</code>.  It is possible to
     configure thread pools for each scheduler instance via the environment