diff mbox series

install.texi (nvptx): Recommend nvptx-tools 2024-05-30 (was: Re: nvptx target: Global constructor, destructor support, via nvptx-tools 'ld')

Message ID ce8483b2-4c63-477a-9e3d-35dbad77d22b@baylibre.com
State New
Headers show
Series install.texi (nvptx): Recommend nvptx-tools 2024-05-30 (was: Re: nvptx target: Global constructor, destructor support, via nvptx-tools 'ld') | expand

Commit Message

Tobias Burnus June 3, 2024, 7:28 a.m. UTC
Thomas Schwinge wrote:
> In the following, I have then reconsidered that stance; we may actually
> "Implement global constructor, destructor support in a conceptually
> simpler way than using 'collect2' (the program): implement the respective
> functionality in the nvptx-tools 'ld'".  The latter is
> <https://github.com/SourceryTools/nvptx-tools/commit/96f8fc59a757767b9e98157d95c21e9fef22a93b>
> "ld: Global constructor/destructor support".

The attached patch makes clearer which version should be
installed by recommending this patch (= latest nvptx-tools)
in install.texi.

OK? Comments, remarks?

Tobias

PS: If the https://github.com/SourceryTools/nvptx-tools/pull/47
(nvptx-ld.cc: Improve C++11 compatibility with older compilers)
proofs worthwhile and gets merged, we should point to that commit
instead.

Comments

Richard Biener June 3, 2024, 8:23 a.m. UTC | #1
On Mon, 3 Jun 2024, Tobias Burnus wrote:

> Thomas Schwinge wrote:
> > In the following, I have then reconsidered that stance; we may actually
> > "Implement global constructor, destructor support in a conceptually
> > simpler way than using 'collect2' (the program): implement the respective
> > functionality in the nvptx-tools 'ld'".  The latter is
> > <https://github.com/SourceryTools/nvptx-tools/commit/96f8fc59a757767b9e98157d95c21e9fef22a93b>
> > "ld: Global constructor/destructor support".
> 
> The attached patch makes clearer which version should be
> installed by recommending this patch (= latest nvptx-tools)
> in install.texi.
> 
> OK? Comments, remarks?

Can we simply say "newerst" where I guess refering to a github repo
already implies this?

> Tobias
> 
> PS: If the https://github.com/SourceryTools/nvptx-tools/pull/47
> (nvptx-ld.cc: Improve C++11 compatibility with older compilers)
> proofs worthwhile and gets merged, we should point to that commit
> instead.
Tobias Burnus June 3, 2024, 8:37 a.m. UTC | #2
Richard Biener wrote:
> On Mon, 3 Jun 2024, Tobias Burnus wrote:
>> Thomas Schwinge wrote:
>>> In the following, I have then reconsidered that stance; we may actually
>>> "Implement global constructor, destructor support in a conceptually
>>> simpler way than using 'collect2' (the program): implement the respective
>>> functionality in the nvptx-tools 'ld'".  The latter is
>>> <https://github.com/SourceryTools/nvptx-tools/commit/96f8fc59a757767b9e98157d95c21e9fef22a93b>
>>> "ld: Global constructor/destructor support".
>> The attached patch makes clearer which version should be
>> installed by recommending this patch (= latest nvptx-tools)
>> in install.texi.
> Can we simply say "newerst" where I guess refering to a github repo
> already implies this?

Good question. The problem I see with just referring to a repository 
(even with newest) often means: yes, that software I have (whatever 
version). While if some reference goes to a 2024 version, I might not 
know what version I have but likely an older version → I will update.

Admittedly, as people tend to *not* read the documentation, this 
approach might fail as well. But, maybe, it is sufficient to update GCC 
15's release notes?*

It won't help those not reading with the release notes before building 
and the wording* had to be changed a bit as install.texi no longer 
states what version should be used, but it would be an alternative

(*) https://gcc.gnu.org/pipermail/gcc-patches/2024-June/653417.html

Tobias
Richard Biener June 3, 2024, 9:09 a.m. UTC | #3
On Mon, 3 Jun 2024, Tobias Burnus wrote:

> Richard Biener wrote:
> > On Mon, 3 Jun 2024, Tobias Burnus wrote:
> >> Thomas Schwinge wrote:
> >>> In the following, I have then reconsidered that stance; we may actually
> >>> "Implement global constructor, destructor support in a conceptually
> >>> simpler way than using 'collect2' (the program): implement the respective
> >>> functionality in the nvptx-tools 'ld'".  The latter is
> >>> <https://github.com/SourceryTools/nvptx-tools/commit/96f8fc59a757767b9e98157d95c21e9fef22a93b>
> >>> "ld: Global constructor/destructor support".
> >> The attached patch makes clearer which version should be
> >> installed by recommending this patch (= latest nvptx-tools)
> >> in install.texi.
> > Can we simply say "newerst" where I guess refering to a github repo
> > already implies this?
> 
> Good question. The problem I see with just referring to a repository (even
> with newest) often means: yes, that software I have (whatever version). While
> if some reference goes to a 2024 version, I might not know what version I have
> but likely an older version → I will update.
> 
> Admittedly, as people tend to *not* read the documentation, this approach
> might fail as well. But, maybe, it is sufficient to update GCC 15's release
> notes?*
> 
> It won't help those not reading with the release notes before building and the
> wording* had to be changed a bit as install.texi no longer states what version
> should be used, but it would be an alternative

install.texi also has the issue that it's not pre-packaged in a
easy to discover and readable file in the release tarballs and that
the online version is only for trunk.

> (*) https://gcc.gnu.org/pipermail/gcc-patches/2024-June/653417.html
> 
> Tobias
> 
> 
>
Tobias Burnus June 3, 2024, 10:26 a.m. UTC | #4
Richard Biener wrote:
> install.texi also has the issue that it's not pre-packaged in a
> easy to discover and readable file in the release tarballs and that
> the online version is only for trunk.

I always wondered why it is not included at 
https://gcc.gnu.org/onlinedocs/ — it would then also be linked from, 
e.g., https://gcc.gnu.org/gcc-14/index.html

Tobias
Richard Biener June 3, 2024, 11:16 a.m. UTC | #5
On Mon, 3 Jun 2024, Tobias Burnus wrote:

> Richard Biener wrote:
> > install.texi also has the issue that it's not pre-packaged in a
> > easy to discover and readable file in the release tarballs and that
> > the online version is only for trunk.
> 
> I always wondered why it is not included at https://gcc.gnu.org/onlinedocs/ —
> it would then also be linked from, e.g., https://gcc.gnu.org/gcc-14/index.html

I'm quite sure it's because nobody bothered to update
maintainer-scripts/update_web_docs_git.  The install docs are
generated into INSTALL/ in the release tarballs it seems but
it's html rather than a plain text file there.

Richard.

> Tobias
> 
>
Gerald Pfeifer June 8, 2024, 11:01 p.m. UTC | #6
On Mon, 3 Jun 2024, Richard Biener wrote:
> install.texi also has the issue that it's not pre-packaged in a
> easy to discover and readable file in the release tarballs and that
> the online version is only for trunk.

The latter is only partially true: we generally try to keep it applicable 
more broadly - to a fault at times, if you look at some of the recent 
pruning I had to do.

Gerald
diff mbox series

Patch

install.texi (nvptx): Recommend nvptx-tools 2024-05-30

gcc/
	* doc/install.texi (nvptx): Recommend nvptx-tools 2024-05-30 or newer.

diff --git a/gcc/doc/install.texi b/gcc/doc/install.texi
index 42b462a2ce2..4859f6743ab 100644
--- a/gcc/doc/install.texi
+++ b/gcc/doc/install.texi
@@ -4698,7 +4698,8 @@  Andes NDS32 target in big endian mode.
 Nvidia PTX target.
 
 Instead of GNU binutils, you will need to install
-@uref{https://github.com/SourceryTools/nvptx-tools,,nvptx-tools}.
+@uref{https://github.com/SourceryTools/nvptx-tools,,nvptx-tools}
+(recommended: 96f8fc5 of 2024-05-30 -- or newer).
 Tell GCC where to find it:
 @option{--with-build-time-tools=[install-nvptx-tools]/nvptx-none/bin}.