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