[pushed] fortran: Minor fix to -ffrontend-optimize description (was: typo on homepage)

[Gerald Pfeifer]

On Mon, 8 Apr 2024, Johannes Nendwich via Gcc wrote:
> on https://gcc.gnu.org/onlinedocs/gfortran/Code-Gen-Options.html
> there is at the end the part
> 
>-ffrontend-optimize
> 
>This option performs front-end optimization, based on manipulating
> parts the Fortran parse tree.
> 
> Might it be that it should say "... manipulating parts _of_ the Fortran 
> parse tree."?

Yes, I believe you're right, so went ahead and pushed the following 
change.

Thank you,
Gerald


commit a071fcda136d00f8321d0adc773007f4f45020ea
Author: Gerald Pfeifer 
Date:   Fri Aug 23 10:02:15 2024 +0200

fortran: Minor fix to -ffrontend-optimize description

gcc/fortran:
* invoke.texi (Code Gen Options): Add a missing word.

diff --git a/gcc/fortran/invoke.texi b/gcc/fortran/invoke.texi
index 6bc42afe2c4..8b3f8118848 100644
--- a/gcc/fortran/invoke.texi
+++ b/gcc/fortran/invoke.texi
@@ -2117,7 +2117,7 @@ if @option{-ffrontend-optimize} is in effect.
 @cindex Front-end optimization
 @item -ffrontend-optimize
 This option performs front-end optimization, based on manipulating
-parts the Fortran parse tree.  Enabled by default by any @option{-O} option
+parts of the Fortran parse tree.  Enabled by default by any @option{-O} option
 except @option{-O0} and @option{-Og}.  Optimizations enabled by this option
 include:
 @itemize @bullet

Re: gcc-wwwdocs branch python-formatting created. e1e17c97a8ae35cfb6b2f7428fb52b05f82450d1

[Gerald Pfeifer]

On Mon, 19 Aug 2024, Eric Gallager via Gcc-cvs-wwwdocs wrote:
> This is an automated email from the git hooks/post-receive script. It was
> generated because a ref change was pushed to the repository containing
> the project "gcc-wwwdocs".
> 
> The branch, python-formatting has been created
> at  e1e17c97a8ae35cfb6b2f7428fb52b05f82450d1 (commit)
> 
> - Log -
> ---

Hmm, are you intentionally creating a branch for the wwwdocs repository 
(i.e., our web pages)? I don't recall us having used one before.

If you have any Python-related fixes, go ahead I'd say.

Gerald

Re: smtgcc translation validation

[Gerald Pfeifer]

On Sat, 30 Sep 2023, Krister Walfridsson via Gcc wrote:
> I have now released the new implementation for translation validation I talked
> about at the GNU Tools Cauldron last week:
>   https://github.com/kristerw/smtgcc

Wouldn't it be appropriate/nice to promote this a bit more strongly from 
gcc.gnu.org?

One example I can think of is https://gcc.gnu.org/extensions.html .

Another might be https://gcc.gnu.org/bugs/ to help understand whether 
something is a user bug or GCC bug?

Happy to accept patches, or if you want to suggest some text massage that 
into HTML and add it.

Gerald

Re: Simple GCC projects page

[Gerald Pfeifer]

On Tue, 20 Mar 2018, Christopher Higgs via gcc wrote:
> If this belongs in a different mailbox, please let me know where it 
> should be sent.

This was the right address, though sadly it somehow fell through the 
cracks originally.

> I would like to start contributing to GCC. In viewing the relevant pages 
> it became clear that they have not been updated for some time, which 
> makes starting to contribute a bit more challenging.
> 
> To name a few on the Simple GCC projects page:1. A few references are 
> made to the java front-end.

Indeed, and this is something we (specifically Eric) addressed, together 
with various other issues on this page.

> Under code cleanliness, the bullet for enormous files lists files in the 
> 150-500K sizes. These sizes are not current and there are at least a 
> couple of files in the MB range (the C++ parser.c file for example).

Eric updated these as well, alas some have further grown; I'll see to do a 
new tally and update that.

> Simplifying parser action code. GCC seems to have migrated away from 
> parser generators in favor of ad hoc approaches. Does this project still 
> apply?

I don't think so, and will push a patch to remove this and associated 
items in a minute.

A belated thank you for your feedback; I'll be looking for further issue 
and will happily look into anything else you may find.

Gerald

Re: new mirror greece

[Gerald Pfeifer]

On Thu, 29 Jun 2023, Konstantinos Draziotis via Gcc wrote:
> I'd like to let you know that I have successfully set up a mirror 
> (http/https server) in Greece for gcc.

Thank you, Konstantinos!

> Location : Thessaloniki / Greece
> Admin Name  : K. A. Draziotis
> Admin Email : drazi...@gmail.com
> Sponsor Name: Aristotle University of Thessaloniki
> Sponsor URL : https://auth.gr
> HTTP/HTTPS URL: fosszone.csd.auth.gr/gnu/gcc

I was going to add this to https://gcc.gnu.org/mirrors.html, alas
  fosszone.csd.auth.gr/gnu/gcc
responds neither to http nor https in my tests?

Can you please advise?

(Maybe you can suggest a patch against that page?)

Gerald

Re: [RFC] MAINTAINERS: require a BZ account field

[Gerald Pfeifer]

On Wed, 3 Jul 2024, Sam James wrote:
>> Now, a bigger question: Why would anyone need to know my gcc.gnu.org 
>> username (or e-mail address) in the Bugzilla context? 
> Isn't it answered in the original proposal? It makes CCing the committer 
> of a bisect result way easier.

No, it's not. And no, it does not in my case, for example.

Hence my counter proposal (with emphasis added):
  
  A counter proposal for the original request would be an OPTIONAL field 
  to include in case the e-mail address listed in the MAINTAINERS file 
  does NOT serve as the Bugzilla account.

Gerald

Re: [RFC] MAINTAINERS: require a BZ account field

[Gerald Pfeifer]

On Mon, 24 Jun 2024, Jonathan Wakely via Gcc wrote:
>> 1) MAINTAINERS should list a field containing either the gcc.gnu.org
>> email in full, or their gcc username (bikeshedding semi-welcome);
> I like the proposal. I'd say it should be fine to just put the gcc
> username (without the @gcc.gnu.org part) because the lines are long
> enough already, and repeating the domain on every line is redundant.

Plus it would look like an e-mail address to use which in many cases 
(like mine) may not be desirable.

Now, a bigger question: Why would anyone need to know my gcc.gnu.org 
username (or e-mail address) in the Bugzilla context? 

A counter proposal for the original request would be an optional field to 
include in case the e-mail address listed in the MAINTAINERS file does not 
serve as the Bugzilla account.

Gerald

Re: Minor correction

[Gerald Pfeifer]

On Sun, 2 Jul 2023, ppw0--- via Gcc wrote:
> just wanted to let you know that while going over 
> https://gcc.gnu.org/onlinedocs/gcc/x86-Options.html , I've noticed 
> certain sections, namely haswell, broadwell, skylake, knl, knm, 
> skylake-avx512, cannonlake, icelake-client, icelake-server, cascadelake, 
> cooperlake, tigerlake, sapphirerapids, rocketlake and graniterapids, 
> have the MOVBE instruction mentioned twice.

Thank you for your report and sorry it took us a while to get back to 
this; I'll fix this in a minute.

Gerald

PS: A more descriptive subject might have helped attracting the attention 
of the respective maintainers.

[committed] PATCH for Re: Stepping down as maintainer for ARC and Epiphany

[Gerald Pfeifer]

On Wed, 5 Jul 2023, Joern Rennecke wrote:
> I haven't worked with these targets in years and can't really do 
> sensible maintenance or reviews of patches for them. I am currently 
> working on optimizations for other ports like RISC-V.

I noticed MAINTAINERS was not updated, so pushed the patch below.

Gerald


commit f94598ffaf5affbc9421ff230502357b07c55d9c
Author: Gerald Pfeifer 
Date:   Mon May 20 16:43:05 2024 +0200

MAINTAINERS: Update Joern Rennecke's status

This is per his mail to gcc@gcc.gnu.org on 7 Jul 2023.

ChangeLog:
* MAINTAINERS: Move Joern Rennecke from arc and epiphany maintainer
to Write After Approval.

diff --git a/MAINTAINERS b/MAINTAINERS
index 8e0add6bef8..e2870eef2ef 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -56,7 +56,6 @@ aarch64 port  Kyrylo Tkachov  

 alpha port Richard Henderson   
 amdgcn portJulian Brown
 amdgcn portAndrew Stubbs   
-arc port   Joern Rennecke  
 arc port   Claudiu Zissulescu  
 arm port   Nick Clifton
 arm port   Richard Earnshaw
@@ -68,7 +67,6 @@ c6x port  Bernd Schmidt   

 cris port  Hans-Peter Nilsson  
 c-sky port Xianmiao Qu 
 c-sky port Yunhai Shang
-epiphany port  Joern Rennecke  
 fr30 port  Nick Clifton
 frv port   Nick Clifton
 frv port   Alexandre Oliva 
@@ -634,6 +632,7 @@ Joe Ramsay  

 Rolf Rasmussen 
 Fritz Reese
 Volker Reichelt

+Joern Rennecke 
 Bernhard Reutner-Fischer   
 Tom Rix
 Thomas Rodgers 

Re: GCC testing on FreeBSD

[Gerald Pfeifer]

Hi Jonathan,

On Fri, 26 Apr 2024, Jonathan Wakely wrote:
> How are you testing on FreeBSD?
> 
> When I build GCC trunk on FreeBSD 14.0 and try to run the libstdc++
> testsuite it fails due to lots of these errors:
> 
> Excess errors:
> /usr/local/bin/ld: /tmp//ccev946q.o: relocation R_X86_64_32 against
> symbol `_ZTIN10__cxxabiv115__forced_unwindE@@CXXABI_1.3.2' can not be
> used when making a PDE object; recompile with -fPIE
> /usr/local/bin/ld: failed to set dynamic section sizes: bad value

my first reaction was to recommend using binutils instead of /usr/bin/ld 
which is LLD 16.0.6 or similar (since a while ago FreeBSD switched to that
toolchain as part of the base system).

My nightly tester has been using GNU ld since

  # 2012-03-11  Configure using --with-as=$localbase/bin/as and
  # --with-ld=$localbase/bin/ld on *.freebsd.org.

in the script invoked by cron, even before FreeBSD made that switch.

Seeing /usr/local/bin/ld in the error message it appears you are doing 
that already, though?

> Which suggests that -fPIE is missing from the default test flags.
> 
> Have you seen this? Do you do something locally to work around it?

All I have in terms of adjustments to the FreeBSD systems I build on via 
that script are the following

  CONFIGUREFLAGS="--with-gmp=$LOCALBASE --with-as=$LOCALBASE/bin/as 
$CONFIGUREFLAGS"
  LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$LOCALBASE/lib
  PATH=$LOCALBASE/bin:$PATH

where LOCALBASE looks like it would be /usr/local in your case. Nothing 
explicit around PIE there.

Looking at the logs of a serialized build I triggered manually where I 
remove the --with-ld configure option, I see 

  checking linker PIE support with copy reloc... no
  checking for -fno-PIE option... yes
  checking for -no-pie option... yes

and then build invocations like

  c++ -std=c++11  -fno-PIE -c ...

during all-stage1-target-libgcc which ultimately fails with - mystery?! -

  ld: error: unable to find library -lc
  collect2: error: ld returned 1 exit status
  gmake[3]: *** [Makefile:1005: libgcc_s.so] Error 1

(Disclaimer: all my tests on FreeBSD 13.2, not FreeBSD 14 as in your 
case.)


Looking at the lang/gcc* ports that I maintained for two decades until 
Lorenzo (copied now) kindly took them over two years ago I see the 
following change among others for newer versions:

  % git show b6a5871a0cf40
  commit b6a5871a0cf40dfc194217704e2dc03e2e91fb62
  Author: Lorenzo Salvadore 
  Date:   Fri Feb 3 20:12:49 2023 +0100

lang/gcc10: Mark PIE_UNSAFE

Building the port with WITH_PIE fails if the BOOTSTRAP option is
enabled. Mark PIE_UNSAFE when this option is enabled until a better
solution is found.

PR: 268901

where https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268901 is the PR 
referenced.

PIE_UNSAFE=yes in a port's Makefile (the equivalent to a spec file in RPM 
land) is used as follows in ports/Mk/Features/pie.mk:

  .  if !defined(PIE_UNSAFE)
  PIE_CFLAGS?=-fPIE -fPIC
  CFLAGS+=${PIE_CFLAGS}
  CXXFLAGS+=  ${PIE_CFLAGS}
  LDFLAGS+=   -pie
  STATIC_PIE_ARGS+=   -static-pie
  .  endif


You are not using the Ports Infrastructure, I believe, so the above does 
not directly apply, may provide some additional background, though?


Hope this helps - and please chime in Lorenzo and Andreas!

Gerald

Thomas Schwinge appointed co-maintainer of the nvptx backend

[Gerald Pfeifer]

It's my pleasure to announce Thomas Schwinge as co-maintainer of the
nvptx backend.

Congratulations and Happy Hacking, Thomas! Please go ahead and update 
MAINTAINERS accordingly.

Gerald (on behalf of the steering committee)

Re: "file name" vs "filename"

[Gerald Pfeifer]

On Sun, 1 Apr 2018, Sandra Loosemore wrote:
>> Our docs currently are about even and I think it would be good to
>> settle on one?
>> 
>>    % grep "filename" $GCC/gcc/doc/*.texi | wc -l
>>    92
>>    % grep "file name" $GCC/gcc/doc/*.texi | wc -l
>>    103
>> 
>> (Once we have consensus, I'll add that to codingconventions.html
>> and start by making the web pages consistent.)
>> 
> The C and C++ standards documents use "file name"; there are other places
> ("bit-field") where the GCC manual has adopted the C standard terminology.
> 
> In this case it might be more appropriate to adopt the POSIX conventions,
> since I suspect most of the uses in the GCC documentation refer to the host
> environment rather than the target language.  This looks like the POSIX
> glossary:
> 
> http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html
> 
> Here "filename" is given as the correct spelling, except that that glossary
> distinguishes between "filename" and "pathname" (a "filename" is the same as a
> "pathname component").  So perhaps many of the "file name"/"filename" uses in
> the GCC manual ought to be "pathname" instead?

On Mon, 2 Apr 2018, Joseph Myers wrote:
> See the GNU Coding Standards:
> 
>   Please do not use the term ``pathname'' that is used in Unix
>   documentation; use ``file name'' (two words) instead.  We use the term
>   ``path'' only for search paths, which are lists of directory names.

Based on this it appears "file name" is the one to follow, so I went ahead
and documented this at https://gcc.gnu.org/codingconventions.html with a 
patch at https://gcc.gnu.org/pipermail/gcc-cvs-wwwdocs/2023/010210.html .

Should we strive to use pathname (or path name) more broadly as Sandra
wondered? I'm a bit hesitant...

My next step is updating wwwdocs to consistently use "file name.

Thoughts?

Gerald

[wwwdocs] testing: Tweak the link to upstream FTensor (was: Anyone using FTensor to test GCC (or otherwise)?)

[Gerald Pfeifer]

On Tue, 14 Feb 2023, NightStrike wrote:
>> Alas http://www.wlandry.net/Projects/FTensor has been down for a while,
>> and there does not appear to be a new location?
> https://wlandry.net/Projects/FTensor/ works

Ah, indeed. Thank you! Somehow that must have been the one combination I 
did not try.

I pushed the little patch below.

Gerald

commit b74309c36e59105ef0d8e0d91a85a5bfa884e175
Author: Gerald Pfeifer 
Date:   Fri Feb 17 02:19:19 2023 +0100

Tweak the link to upstream FTensor.

diff --git a/htdocs/testing/testing-ftensor.html 
b/htdocs/testing/testing-ftensor.html
index 2e67b4d8..7b1f4675 100644
--- a/htdocs/testing/testing-ftensor.html
+++ b/htdocs/testing/testing-ftensor.html
@@ -11,7 +11,7 @@
 FTensor build and test guide
 
 This page is a guide to running the testing and timing programs for the
-http://www.wlandry.net/Projects/FTensor";>FTensor
+https://wlandry.net/Projects/FTensor";>FTensor
 tensor class library as part of GCC integration testing.
 
 Resource usage

Anyone using FTensor to test GCC (or otherwise)?

[Gerald Pfeifer]

>From previous times we have FTensor
  https://gcc.gnu.org/testing/testing-ftensor.html
documented as one of the ways to test GCC.

Alas http://www.wlandry.net/Projects/FTensor has been down for a while, 
and there does not appear to be a new location?


Is anyone actually still using FTensor to test GCC (or otherwise)?

I'm wondering whether to simply delete that page...

Gerald

Re: Buildbot (Sourceware): gcc - failed configure (failure) (master)

[Gerald Pfeifer]

On Mon, 30 Jan 2023, Steve Kargl via Gcc wrote:
> Bingo.  In the case of non-[a-zA-Z] characters in the
> Subject (or Fromi or To) line, the spam folder is normally
> named /dev/null.

Hmm, so any digit, parenthesis, or bracket in the Subject, and mails gets 
to /dev/null?

Or having an umlaut or other special character in one's name - which is
pretty common in parts of the world like Central Europe?


"Be conservative in what you send, be liberal in what you accept."
[Postel's Law]

Gerald

Renaming git master?

[Gerald Pfeifer]

[ gcc-patches -> gcc ]

On Mon, 29 Mar 2021, Jonathan Wakely wrote:
>> [LLVM] renamed the 'master' branch. I'll adjust the link tomorrow.
> Done by this patch, pushed to master (which I think we should rename).

Did I miss any discussions? Our documentation at 
  https://gcc.gnu.org/git.html
still refers to master (though, probably dating back to the SVN days there 
are quite a number of references to trunk, too).

`git branch -l` shows 
  master
  remotes/origin/HEAD -> origin/master
  remotes/origin/trunk


1. Is there something we may want to adjust in the Git repository?

2. How about https://gcc.gnu.org/git.html ? 

   (If someone tells me what to use instead of "master" I can propose a 
   patch.)
 
Gerald

Re: Revert Sphinx documentation [Was: Issues with Sphinx]

[Gerald Pfeifer]

On Mon, 14 Nov 2022, Jonathan Wakely wrote:
> I formatted my new region/endregion pragmas on one line because that
> seemed to be how it should be done for rSt, e.g. we had:
> 
> ``#pragma GCC push_options`` ``#pragma GCC pop_options``
> 
> But I think the attached patch is more correct for how we document
> pragmas in texinfo.
> 
> OK for trunk?

Looks good to my eyes. Thank you for caring for such details, Jonathan!

Gerald

Re: Revert Sphinx documentation [Was: Issues with Sphinx]

[Gerald Pfeifer]

On Mon, 14 Nov 2022, Martin Liška wrote:
> The situation with the Sphinx migration went out of control. The TODO 
> list overwhelmed me and there are road-blocks that can't be easily fixed 
> with what Sphinx currently supports.

This migration was/is a huge and complex undertaking, and you have been 
patiently chipping away at obstacle after obstacle.

So while it probably is disappointing it did not go through this time,
you made a lot of progress and important contributions - and we all 
learned quite a bit more, also in terms of (not so obvious) requirements,
dependencies, and road blocks left which you summarized.


Timing was tricky for me being on the road last week and I am definitely
committed to keep helping with this transition. Maybe soon after we are in 
stage 1 again?

And would it make sense to convert at least our installation docs and
https://gcc.gnu.org/install/ for the GCC 13 release?

Gerald

Re: Announcement: Porting the Docs to Sphinx - tomorrow

[Gerald Pfeifer]

On Tue, 8 Nov 2022, Martin Liška wrote:
> After the migration, people should be able to build (and install) GCC 
> even if they miss Sphinx (similar happens now if you miss makeinfo). 

My nightly *install* (not build) on amd64-unknown-freebsd12.2 broke 
(from what I can tell due to this - it's been working fine most of 
the last several 1000 days):

  if [ -f doc/g++.1 ]; then rm -f 
/home/gerald/gcc-ref12-amd64/share/man/man1/g++.1; /usr/bin/install -c -m 644 
doc/g++.1 /home/gerald/gcc-ref12-amd64/share/man/man1/g++.1; chmod a-x 
/home/gerald/gcc-ref12-amd64/share/man/man1/g++.1; fimake -C 
/scratch/tmp/gerald/GCC-HEAD/gcc/../doc man 
SOURCEDIR=/scratch/tmp/gerald/GCC-HEAD/gcc/fortran/doc/gfortran 
BUILDDIR=/scratch/tmp/gerald/OBJ--0954/gcc/doc/gfortran/man SPHINXBUILD=
  make[3]: make[3]: don't know how to make w. Stop
  make[3]: stopped in /scratch/tmp/gerald/GCC-HEAD/doc
  gmake[2]: *** [/scratch/tmp/gerald/GCC-HEAD/gcc/fortran/Make-lang.in:164: 
doc/gfortran/man/man/gfortran.1] Error 2
  gmake[2]: Leaving directory '/scratch/tmp/gerald/OBJ--0954/gcc'
  gmake[1]: *** [Makefile:5310: install-strip-gcc] Error 2
  gmake[1]: Leaving directory '/scratch/tmp/gerald/OBJ--0954'
  gmake: *** [Makefile:2734: install-strip] Error 2

(This appears to be the case with "make -j1 install-strip". Not sure where 
that "w" target is coming from?)

Gerald

Re: gcc.gnu.org/wiki/ – broken because /moin_static1910/ files fail with 404

[Gerald Pfeifer]

On Fri, 11 Nov 2022, Mark Wielaard wrote:
> I don't know how this happened, but I assume the moin_static1910 link
> under /www/gcc/htdocs to the site-package MoinMoin/web/static/htdocs
> somehow got misplaced. I added a symlink and all seems fine again.

Thank you, Mark!

I believe this was on me. - I'm pretty sure it happened as I did some 
changes (around install/) in support of Martin's work. User error. :-(

Gerald

Re: unreachable intro to gcc page linked to on readings page

[Gerald Pfeifer]

On Wed, 24 Aug 2022, Jonathan Wakely wrote:
>> a broken link points to
>>
>>   An introduction to GCC by Brian J. Gough.
>>   . http://www.network-theory.co.uk/gcc/intro/
> There are much more recent archived copies like
> https://web.archive.org/web/20181113021321/http://www.network-theory.co.uk/gcc/intro/
> I'm not sure it's worth updating the link to an archived copy of that
> page, because all the links for buying a PDF or printed copy are
> probably dead now anyway.
> 
> We could link to https://archive.org/details/B-001-002-835 instead, or
> to the archived HTML version. The newest capture of the HTML version
> seems to be this, although I didn't check that all pages are archived:
> https://web.archive.org/web/20181206025406/http://www.network-theory.co.uk/docs/gccintro/
> My preference would be to link to that latter. Although it's quite
> dated, the sections on basic compilation and compiler flags are still
> relevant for beginners.
> 
> Gerald?

I searched around a bit myself (since indeed the original and printed 
versions seem to be gone) and landed at

   https://archive.org/details/B-001-002-835

as well. I probably would have gone for that, though the 
web.archive.org/web link you found works equally if you want to point 
there instead.

Gerald (who appears in the Acknowledgement section of that book :-)

Re: Reqister to become gcc mirror site

[Gerald Pfeifer]

Hi Ceasar,

On Tue, 22 Feb 2022, Ceasar Sun wrote:
> We sent the follow message two weeks ago, buy didn't get response yet.
> So, send this again  and sorry for the inconvenience ~

I am sorry this didn't see an answer earlier.  It looks like you are
actively mirroring our download site already?

> I'm Ceasar Sun ,  from Free Software Lab, NCHC ,  Taiwan.
> We provide several free software mirror service in Taiwan : free.nchc.org.tw
> We would like to become a gcc mirror site and the service would be presented
> as :
> 
> Country :  Taiwan ,TW
> City: Hsinchu
> Site: https://free.nchc.org.tw/gcc/
> Contact e-mail : fs...@nchc.org.tw
> Contact Name : FSLab Team , NCHC
> 
> So, which upstream gcc site we should use ?

It's best if you use gcc.gnu.org directly. Is this what you are now
doing?  Is there anything you need?  (I believe it's probably best to
mirror using rsync.)

As a next step we then just need to add you to our mirros page at
https://gcc.gnu.org/mirrors.html, something like the following:

diff --git a/htdocs/mirrors.html b/htdocs/mirrors.html
index 75c71b95..8e35bc08 100644
--- a/htdocs/mirrors.html
+++ b/htdocs/mirrors.html
@@ -38,6 +38,7 @@ mirrors.  The following sites mirror the gcc.gnu.org 
download site
 The Netherlands, Nijmegen: https://ftp.nluug.nl/languages/gcc/";>ftp.nluug.nl, thanks to Jan 
Cristiaan van Winkel (j...@atcomputing.nl)
 Russia, Novosibirsk: http://mirror.linux-ia64.org/gnu/gcc/";>http://mirror.linux-ia64.org/gnu/gcc/,
 thanks to Daniel Volchixin (dan...@volchixin.co.uk)
 Slovakia, Bratislava: http://gcc.fyxm.net/";>gcc.fyxm.net, 
thanks to Jan Teluch (ad...@2600.sk)
+Taiwan, Hsinchu: https://free.nchc.org.tw/gcc/";>nchc.org.tw, 
thanks to FSLab Team, NCHC (fs...@nchc.org.tw)
 UK: https://mirrorservice.org/sites/sourceware.org/pub/gcc/";>mirrorservice.org,
 thanks to mir...@mirrorservice.org
 US, San Francisco: https://bigsearcher.com/mirrors/gcc/";>https://bigsearcher.com/mirrors/gcc/,
 thanks to i...@bigsearcher.com
 US, San Jose: http://www.netgull.com/gcc/";>http://www.netgull.com, thanks to 
ad...@netgull.com

What do you think? Are there any changes to this proposed patch you
suggest?

Thank you,
Gerald

Re: Old installation docs

[Gerald Pfeifer]

On Wed, 20 Oct 2021, Joseph Myers wrote:
> Those should have been removed in GCC commit 
> 431d26e1dd18c1146d3d4dcd3b45a3b04f7f7d59, it seems that forgot to remove 
> the link in the HTML version.

I'm surprised my link checker has not found this broken link; I'll need 
to look into that.

Thanks for spotting Jonathan, and absolutely agreed with Joseph: yank it
(or I'll do, if you prefer).

Gerald

Re: replacing the VRP threader

[Gerald Pfeifer]

On Wed, 22 Sep 2021, Aldy Hernandez via Gcc wrote:
> Well, it turns out we're considerably better than reported.
> 
> Andrew just found a one-line change in the path solver that improves
> our VRP threading goodness to 18.5% and our overall jump threading
> gains to 1.28%.

Would that make a great news item, gcc-12/changes.html for sure, maybe 
even our home page (possibly with a subpage under projects/ like in the 
old days)?

Gerald

Re: [TCWG CI] 471.omnetpp slowed down by 8% after gcc: Avoid invalid loop transformations in jump threading registry.

[Gerald Pfeifer]

On Wed, 29 Sep 2021, Maxim Kuvyrkov via Gcc wrote:
> Configurations that track master branches have 3-day intervals.  
> Configurations that track release branches — 6 days.  If a regression is 
> detected it is narrowed down to component first — binutils, gcc or glibc 
> — and then the commit range of the component is bisected down to a 
> specific commit.  All.  Done.  Automatically.
> 
> I will make a presentation on this CI at the next GNU Tools Cauldron.

Yes, please! :-)

On Fri, 1 Oct 2021, Maxim Kuvyrkov via Gcc wrote:
> It’s our next big improvement — to provide a dashboard with current 
> performance numbers and historical stats.

Awesome. And then we can even link from gcc.gnu.org.

Gerald

Re: Aldy Hernandez and Andrew MacLeod as VRP maintainers

[Gerald Pfeifer]

On Thu, 17 Jun 2021, Aldy Hernandez via Gcc wrote:
> On 6/17/21 12:18 AM, Jeff Law wrote:
>> I am pleased to announce that the GCC Steering Committee has appointed Aldy
>> Hernandez and Ian MacLeod as maintainers for the VRP subsystem (EVRP, VRP,
>> Ranger).
> I don't know who this Ian is, but I'm sure we'll get along splendidly :).

:-)

Happy Vrpping (or would that we warping, maybe)?

Gerald

Re: Mailing list reconfiguration: VERP Sender: header affected

[Gerald Pfeifer]

On Thu, 3 Jun 2021, Martin Liška via Overseers wrote:
> On 6/2/21 4:52 PM, Frank Ch. Eigler via Gcc wrote:
>> If you use Sender:-based filtering for sorting your incoming email
>> stream, I suggest switching to observing List-Id: instead, or else
>> using a regexp/substring style of Sender: matching.
> Which we recommend in the ection Filtering here:
> https://gcc.gnu.org/lists.html

Now we do. ;-)  We did recommend Sender: until

  commit 8beab8102fd97e0bc745a285e619c08c52d74b6f
  Author: Segher Boessenkool 
  Date:   Tue Jun 1 15:50:57 2021 +

lists: Correct procmail recipe

Thanks for the note, Frank!
Gerald

Re: a small typo in the documentation, FYI

[Gerald Pfeifer]

On Tue, 7 Jul 2020, Nino Pereira via Gcc wrote:
> The top line in
> https://gcc.gnu.org/onlinedocs/gcc-4.6.3/gfortran/BOZ-literal-constants.html
> 
> says " The syntax is: `prefix quote digits quote', were the prefix is
> either b, o or z,"
> 
> Here, 'were' must be 'where'

Thank you for the report, Nino.  I just committed a patch to fix this.

Gerald

Re: Build failure in fixincludes on x86_64

[Gerald Pfeifer]

On Wed, 26 May 2021, Richard Earnshaw via Gcc wrote:
>> ../../git/gcc/fixincludes/fixtests.c: In function ‘run_test’:
>> ../../git/gcc/fixincludes/fixtests.c:155:1: internal compiler error:
>> in operator[], at vec.h:890
>>   155 | }
>>   | ^
> Same failure on arm.

Same failure on x86 (32-bit, i586-unknown-freebsd11.4).

Gerald

Re: Links broken for C++ in web page "GCC online documentation: Latest releases"

[Gerald Pfeifer]

On Wed, 28 Apr 2021, Pablo M. Ronchi via Gcc wrote:
> https://gcc.gnu.org/onlinedocs/
> 
> under the subheadings:
> 
> Latest releases
>  GCC 11.1 manuals:
> 
> The following items have all their links broken (HTML,... tarball):
> 
> ...
> GCC 11.1 Standard C++ Library Manual (also in PDF or XML or an HTML tarball)
> GCC 11.1 Standard C++ Library Reference Manual (also in PDF or XML GPL or XML
> GFDL or an HTML tarball)
> ...

Thank you for your report, Pablo.  Can you confirm this is working
for you now?


The one link that is (still) broken for me is
  "XML GFDL" for the "GCC 11.1 Standard C++ Library Reference Manual"

Let me copy the libstdc++ list for help/clarification.

Gerald

Re: gcc-11-20210426 is now available

[Gerald Pfeifer]

On Mon, 26 Apr 2021, GCC Administrator via Gcc wrote:
> Snapshot gcc-11-20210426 is now available on
>   https://gcc.gnu.org/pub/gcc/snapshots/11-20210426/
> and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

Thanks for re-running the snapshot, Joseph, and updating 
the infrastructure (cf. 
https://gcc.gnu.org/pipermail/gcc/2021-April/235907.html)

To reduce potential confusion by users, I removed the bogus
11-20210425 snapshot from our download server.

Gerald

Re: Has FSF stopped processing copyright paperwork

[Gerald Pfeifer]

On Mon, 26 Apr 2021, Romain GEISSLER via Gcc wrote:
> Few weeks later, I would like to know if anyone on the list knows if FSF is
> still processing copyright assignment these days. Basically shall people
> willing to sign one just have to be patient as processing is still on-going,
> or if processing copyright assignment is fully frozen.

I got notified of copyright assignments related to GCC by 
copyright-cl...@fsf.org on April 5th, April 8th, April 22nd 
(two instances) and April 26th (today).

So the process seems to be operational.

Gerald

Re: removing toxic emailers

[Gerald Pfeifer]

On Fri, 16 Apr 2021, Frosku wrote:
> In my view, if people employed by a small number of American companies
> succeed in disassociating GCC from GNU/FSF, which is representative of
> the free software grassroots community

I find this insistant focus by some on "American companies" 
interesting - and quite pointless. And my passport is burgundy.

It also is a completely unwarranted attack on the integrity of the
maintainers, contributors, and other leaders of GCC. Regardless of
the color of their passports. 

Personally I care about quality of what we ship, supporting our 
users, and upholding the principles of free software/open source.
And I am willing to bet this applies to the vast majority of us.

So please stop those unfounded allegations.

Gerald

PS: Our release managers, for example, are British (Joseph), Czech 
(Jakub), and German (Richi), IIRC.  The majority of the FSF board, 
FSF leadership, and RMS himself are American from what I can tell.

Re: GCC association with the FSF

[Gerald Pfeifer]

On Sat, 10 Apr 2021, Giacomo Tesio wrote:
> In fact, the mail boxes of the Steering Committee's members are 
> stored on their corporate servers.

You keep making statements which are simply wrong.

None of my GCC-related e-mails touch the servers of my employer,
nor servers under the control of my employer, nor servers running
one of my employer's products.

Membership in the steering committee is personal, not related to
the respective employeers, and transcends employment.

Oh, and FWIW: my employer legally is not even allowed to access 
my work mailbox.

> Yet I only asked to fix the Steering Committee AFTER the only 
> credible no-profit protecting free software (FSF) was removed.

Please stop spreading FUD and insulting steering committee members.

Gerald

Re: GCC association with the FSF

[Gerald Pfeifer]

On Fri, 9 Apr 2021, Giacomo Tesio wrote:
> GCC is clearly an US-only project.

This is simply incorrect.

> A US-corporate one. Totally SFW (in the US).

As is this.

> This is not intended as an insult.
> It's just a fact.

Ex falso quodlibet.

Gerald

Re: GCC association with the FSF

[Gerald Pfeifer]

On Sat, 10 Apr 2021, Richard Kenner via Gcc wrote:
> I really think that most of the people replying on this thread have a
> much more encompassing view of "GCC governance" than actually exists.

There are a number of people arguing here who have contributed little 
to nothing to GCC, whose names even did not trigger memories - unlike 
David M. or Jonathan, for example, or Nathan or Alexandre.

We generally welcome contributions - technical and otherwise.

When it comes to deciding the direction of a project like GCC - technical 
and otherwise - in my mind it primarily should be those actually involved 
and contributing.

(And, for the record, I have no doubt that all of the other contributors
who have spoken up care a lot about free software and the future of GCC
in that context. That does not necessarily require the FSF, though.)

Gerald

Re: RMS removed from the GCC Steering Committee (was: Remove RMS...)

[Gerald Pfeifer]

On Thu, 1 Apr 2021, Giacomo Tesio wrote:
> Oh well, sure, but luckily the solution is just as fast and easy as
> it was to remove RMS: pick just one person for each nationality and
> remove the others.

Why nationalities? That strikes me as a rather specific view focusing on 
one of many attributes (and I believe there's more nationalities than you 
might think, and a bigger variety of backgrounds).

> People all over the world, whatever their country, should be sure to 
> be treated fairly and equally by the GCC leaders even if they want to
> contribute something that does not match the culture or interests you
> represent.

I will argue that is the case as of today and would like to see potential 
counter examples (if any) so that we can address those -or- file the point
above as FUD.

Note that contributions are generally reviewed and accepted by our group 
of maintainers per the MAINTAINERS file (not the steering commitee) and 
releases driven by our release managers.

Gerald

libstdc++-v3/doc/xml/manual/backwards_compatibility.xml

[Gerald Pfeifer]

I noticed this section on "Backwards Compatibility" in the libstdc++
docs that talks about

 - glibc 2.0.x
 - GCC 3.2 (August 2002)
 - GCC 4.1 (February 2006) 

and links to "Migrating to GCC 4.1" and "Migration guide for GCC-3.2"
documents.

Does this still make sense (and serve real users or developers) or
should this be trimmed quite a bit?

Gerald

Re: C++11 code in the gcc 10 branch

[Gerald Pfeifer]

On Mon, 21 Dec 2020, FX via Gcc wrote:
> I’m trying to bootstrap a GCC 10 compiler on macOS with clang, and I am 
> getting errors in stage 1, because there is C++11 code that is rejected 
> by clang (because the bootstrap involves compiling stage 1 with 
> -std=gnu++98, online on master (see top-level configure.ac).

I got reports from users, too (for FreeBSD with clang as system 
compiler), and have them test this patch which looks fine so far.

> These errors are not seen, I believe, when GCC is the bootstrap 
> compiler, because GCC will issue a warning instead of an error (as 
> clang does).
> 
> One place with such issue is in aarch64-builtins.c, which contains a 
> C++11 constructor. I can fix it with this:

When are you going to apply your fix that Richard S. approved on the
21st?

Gerald

More consistency for Git log messages?

[Gerald Pfeifer]

Having spent a bit more time with GCC sources (as opposed to wwwdocs) 
recently and looking for prior art to guide me, I noticed there's a 
lot of options to specific the ChangeLog file(s) to use.

And correspondingly a lot of inconsistency.

Right now we seem to allow for

 1. gcc/cp/ChangeLog
 2. gcc/cp/ChangeLog:
 3. gcc/cp
 4. gcc/cp:
 5. gcc/cp/

and probably more.

Can we streamline this a bit and converge on one of the forms 3-5?

Personally I'd suggest 3 (the shortest) or 5 (the directory), but whatever 
... as long as things become more consistent, which is easier on newbies
and reading logs (or automatically processing them later on).

Gerald

arm-related links in need of updates

[Gerald Pfeifer]

I noticed there's a couple of links on arm.com that changed recently
(probably in the last month or so).  

Can you please help and get those updated?  (Even those that redirect.)


On http://gcc.gnu.org/gcc-10/changes.html

  https://developer.arm.com/docs/101028/0009/data-processing-intrinsics
  https://developer.arm.com/docs/101028/0010/custom-datapath-extension

On http://gcc.gnu.org/readings.html
  http://infocenter.arm.com/help/index.jsp
  http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.subset.swdev.abi/

In gcc/gcc/doc/extend.texi

  
http://infocenter.arm.com/help/topic/com.arm.doc.ihi0053c/IHI0053C_acle_2_0.pdf
  
http://infocenter.arm.com/help/topic/com.arm.doc.ihi0073a/IHI0073A_arm_neon_intrinsics_ref.pdf

In gcc/gcc/invoke.texi

  
http://infocenter.arm.com/help/topic/com.arm.doc.ecm0359818/ECM0359818_armv8m_security_extensions_reqs_on_dev_tools_1_0.pdf

Thank you,
Gerald

Re: [IMPORTANT] ChangeLog related changes

[Gerald Pfeifer]

On Mon, 1 Jun 2020, Jonathan Wakely via Gcc-patches wrote:
> The libstdc++ manual is written in Docbook XML, but we commit both the
> XML and generated HTML pages to Git. Sometimes a small XML file can
> result in dozens of mechanical changes to the generated HTML files,
> which we record in the ChangeLog as:
> 
> * doc/html/*: Regenerated.
> 
> With the new checks we need to name every generated file individually.
> 
> If we add that directory to the ignored_prefixes list, we won't need
> to name them. But then the doc/html/* entry will give an error, and
> changes to the HTML files can be committed without any ChangeLog
> entry. Should we just stop mentioning the HTML in the ChangeLog?
> 
> We could do something like the attached patch, but it seems overkill
> for this one special case.

The change makes sense, but indeed it feels like a very specialized
case in a general script.

Thinking out of the box (and admittedly with a dose of igorance, which
means I am likely missing something): Is not keeping the libstdc++/doc 
HTML in Git a viable option?  Only creating that HTML as part of releases 
and maybe snapshots?

Gerald

0800-GIT-HELP: Doing a simple backport

[Gerald Pfeifer]

I hope the offer by some of you to support people like me who Git
appears to hate with a fervor still stands? ;-)

And I volunteer to enhance our documentation if it appears useful.


Usecase: I've got a patch approved and pushed to HEAD, and approved 
for active release branches - 13a46321516e2efd3bbb1f1899c539c6724240a9 .

Now I want to backport from HEAD to the GCC 10 tree, so checked out a
copy, found git cherry-pick, and gave it a try:

  git cherry-pick 13a46321516e2efd3bbb1f1899c539c6724240a9
  Auto-merging gcc/ChangeLog
  CONFLICT (content): Merge conflict in gcc/ChangeLog
  error: could not apply 13a46321516... i386: Define __ILP32__ and _ILP32 for 
all 32-bit targets
  hint: after resolving the conflicts, mark the corrected paths
  hint: with 'git add ' or 'git rm '
  hint: and commit the result with 'git commit'

What now?  I can manually fix up gcc/ChangeLog, but `git diff` then 
shows a fairly big diff (essentially all changes since the one I am
trying to cherry pick)?

So ... is git cherry-pick even the right tool?

And if so, how do I best go about conflicts happening as part of 
that, ChangeLog or otherwise?


Thanks, 
Gerald

Re: subversion status on gcc.gnu.org

[Gerald Pfeifer]

On Fri, 20 Mar 2020, Frank Ch. Eigler via Overseers wrote:
> Both svn: and ssh+svn: now work for your archeological needs.
> Further, URLs such as
> 
> https://gcc.gnu.org/viewcvs?rev=279160&root=gcc&view=rev
> https://gcc.gnu.org/r123456
> 
> are mapped to gitweb searches that try to locate the matching
> From-SVN: rABCDEF commit.  This way, historical URLs from bugzilla
> should work.

That. Is. Cool. :-)

Thank you! 


Should we document this somewhere?  (Our web pages do not appear to
contain "gcc.gnu.org/r", so probably not.)


On a related note, contribute.html has a link to 
https://gcc.gnu.org/viewcvs/gcc/trunk/contrib/check_GNU_style.sh?view=markup
and gcc-4.8/changes.html has a linkto
https://gcc.gnu.org/viewcvs/trunk/libgfortran/libgfortran.h?content-type=text%2Fplain&view=co
which are broken now.  

Do you have an idea how to go about those?  (Happy to make those changes
then.)

Thanks,
Gerald

Re: text/x-* attachments strippe

[Gerald Pfeifer]

On Mon, 9 Mar 2020, Thomas König wrote:
> I also seem to have missed all discussion on this change (if there was 
> anything). I do not understand why such a huge change was implemented 
> that way, and who did this. Perhaos the person(s) responsible could 
> speak up about this.

Let's be careful - most people working on this are volunteers, and 
it's great that they took care and spent evenings and weekends.

Could this have gone a bit smoother? Yes.  More collaborative? Maybe.

But it's been old system and quite an upgrade, so changes (including
some inconvenient ones) are to be expected.  I have found and reported
and (with the little I can) helped address some issues and will continue
to do so -- and am confident this is heading in the right direction.

Gerald

Re: List-Id header being stripped

[Gerald Pfeifer]

On Mon, 9 Mar 2020, Florian Weimer wrote:
> So the difference is
> 
> List-Id: 
> 
> vs
> 
> List-Id: Gcc mailing list 
> 
> I guess now you need to perform a substring match.

Or remove the string.  Is that doable?

(It does not add value, and "Gcc" is wrong spelling anyway.)

Gerald

[committed] wwwdocs: New GCC mirror from Rabat, Morocco

[Gerald Pfeifer]

On Sun, 5 Jan 2020, Gerald Pfeifer wrote:
> Happy to have you as a mirror, and if you'd like to submit a patch
> for https://gcc.gnu.org/mirrors.html that'd be great. Otherwise we
> can create one.

I applied this patch that I created on behalf of Sami.

Gerald


- Log -
commit c69ec31fe4eec31ec6f1c76ebec23ad69cfb85d3
Author: Gerald Pfeifer 
Date:   Wed Feb 5 22:38:24 2020 +0100

Add mirror.marwan.ma.

diff --git a/htdocs/mirrors.html b/htdocs/mirrors.html
index 1917d04a..6813de72 100644
--- a/htdocs/mirrors.html
+++ b/htdocs/mirrors.html
@@ -30,6 +30,10 @@ mirrors.  The following sites mirror the gcc.gnu.org 
download site
 Greece: ftp://ftp.ntua.gr/pub/gnu/gcc/";>ftp.ntua.gr, thanks 
to ftpadm at ntua.gr
 Hungary, Budapest: http://robotlab.itk.ppke.hu/gcc/";>robotlab.itk.ppke.hu, thanks to 
Adam Rak (neurhlp at gmail.com)
 Japan: http://ftp.tsukuba.wide.ad.jp/software/gcc/";>ftp.tsukuba.wide.ad.jp, 
thanks to Kohei Takahashi (tsukuba-ftp-servers at tsukuba.wide.ad.jp)
+Morocco:
+  https://mirror.marwan.ma/gcc/";>mirror.marwan.ma
+ (rsync://mirror.marwan.ma/gcc/),
+  thanks to Sami Ait Ali Oulahcen (s...@marwan.ma)
 The Netherlands, Dronten:
 ?? http://mirror.koddos.net/gcc/";>http://mirror.koddos.net/gcc/ |
 ?? rsync://mirror.koddos.net/gcc/,

Re: git conversion in progress

[Gerald Pfeifer]

On Wed, 22 Jan 2020, Jakub Jelinek wrote:
>> The rsync.html page can be removed too, since that was a way to download
>> the entire svn repo.  With git clone, you get the entire repo, so rsync
>> isn't needed anymore.
> I disagree, it isn't just about downloading a svn repo, but mailing list
> archives too:

And notably our download site (for use by mirror sites):

> gcc-ftp   gcc ftp area ()

I'll take the AI to document this explicitly after my current set
of outstanding changes.

Gerald

Re: Add News-feed item for git transition

[Gerald Pfeifer]

On Wed, 22 Jan 2020, Richard Earnshaw (lists) wrote:
> We're missing a statement on the main news feed about the git transition.

Lovely, thanks.

Gerald

PS: Lovely referring to you creating the patch, not the missing 
announcement. ;-)

Re: git conversion in progress

[Gerald Pfeifer]

On Mon, 13 Jan 2020, Joseph Myers wrote:
> In addition, once git.html is more complete (has the list of branches 
> added, at least) we need to update the GCC home page to link to the new 
> pages in place of those for SVN, redirect the old pages to the new ones, 
> and generally update references to SVN in wwwdocs and the GCC manuals.

I have removed all references to svnwrite.html and svn.html from our
own pages, added redirects to gitwrite.html and git.html, respectively,
and after svnwrite.html a few days ago now also removed svn.html.

There's some further changes I have in the queue, but the web site side
of things should be mostly converted now, modulo

 - more Git-specifics as you had pointed out,
 - bugs/reghunt.html which Jonathan offered to look into, and 
 - simtest-howto.html which looks a little dead to me.

Gerald

Re: Updating "regression hunting" to the Git world (was: [wwwdocs] Adjustments of "regression hunting" instructions to the post-SVN world.)

[Gerald Pfeifer]

On Mon, 20 Jan 2020, Jonathan Wakely wrote:
>> If you have further updates to that page, please go ahead and
>> simply make them (or let me know).
> It still says "The following SVN commands are ..."

Yes, that's another piece I'll tackle today/tomorrow.

>> Also contrib/reghunt appears in need of *quite* some updates.
>> Or do we want to retire it?
> I've never read that web page or looked at contrib/reghunt before, 
> but most of it can probably be done by 'git bisect' run. The web page
> should be rewritten in terms of using git bisect. I can take a stab 
> at that if nobody else wants to.

That would be great, thank you!

Gerald

Re: New redirects for git

[Gerald Pfeifer]

On Mon, 13 Jan 2020, Jakub Jelinek wrote:
> Thanks to everybody who have helped with this.

Thank you for putting this in place, Jakub!

Gerald

Updating "regression hunting" to the Git world (was: [wwwdocs] Adjustments of "regression hunting" instructions to the post-SVN world.)

[Gerald Pfeifer]

On Sun, 19 Jan 2020, Gerald Pfeifer wrote (on gcc-patches@):
> With Git a clone carries the whole repository, so remove instructions
> on obtaining a local copy of the repository and related instructions
> on SVN usage.

I just updated https://gcc.gnu.org/bugs/reghunt.html , mostly by 
removing obsolete aspects related to SVN:

   https://gcc.gnu.org/ml/gcc-patches/2020-01/msg01121.html


If you have further updates to that page, please go ahead and 
simply make them (or let me know).


Also contrib/reghunt appears in need of *quite* some updates.  
Or do we want to retire it?

Gerald

Re: [wwwdocs] Generalize instructions and remove notes on repository mirroring via rsync.

[Gerald Pfeifer]

[ gcc-patches -> gcc ]

On Sat, 18 Jan 2020, Gerald Pfeifer wrote:
> Remove all references how to perform local checkouts, to SVN, and
> mirroring the repository.  Instead generalize descriptions since
> with the move to Git syncing the repository with rsync and then
> checking out locally became mostly pointless.

The rsync overview shows

  gcc-svn gcc svn repository ()
  gcc-cvs gcc cvs repository ()

I assume it's intentional that git is not listed there?

Should gcc-cvs really be listed there still?  (If no, should we
at this point prune the old CVS tree on the server?)

Gerald

Re: git conversion in progress

[Gerald Pfeifer]

On Thu, 16 Jan 2020, Jonathan Wakely wrote:
> On Thu, 16 Jan 2020 at 09:55, Georg-Johann Lay  wrote:
>> Hi, the front page reads "Our sources are readily and freely available
>> via SVN...", similar recommendation for SVN in
> Yes, it's been said more than once that the web pages will be updated
> once the docs for using git are ready.

I've been replacing references to SVN by ones to Git as time permits,
and hit that instance this evening:

  https://gcc.gnu.org/ml/gcc-patches/2020-01/msg00990.html

Given that SVN does not work any more (in the sense that it's not
updated any longer, it still appears accessible if frozen), I don't
think that's harmful, and I believe what we have in place now isn't
actually too bad?

Gerald

1-800-GIT-HELP: Fixing a commit message?

[Gerald Pfeifer]

It turns out I fumbled the commit message on the commit below to wwwdocs.

Instead of 
Redirect cvswrite.html to gitwrite.html instead of svnwrite.html.
I committed this with a message of 
Redirect cvs.html to git.html instead of svn.html.
and pushed already.

In CVS I could manually edit the ,v files; in SVN I believe we did
not want to allow for fixing commit messages a posteriori -- how 
about our Git setup?  Policy-wise and practically?

Gerald

== from gcc-patches ==
From: Gerald Pfeifer 
To: gcc-patc...@gcc.gnu.org
Date: Thu, 16 Jan 2020 19:15:28 +0100 (CET)
Subject: [PATCH] Redirect cvswrite.html to gitwrite.html instead of 
svnwrite.html.

I doubt there's many references to https://gcc.gnu.org/cvs.html 
left, but just in case - Git is the new SVN is the new CVS. :-)

Gerald
---
 htdocs/.htaccess | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/htdocs/.htaccess b/htdocs/.htaccess
index acaac093..a28af129 100644
--- a/htdocs/.htaccess
+++ b/htdocs/.htaccess
@@ -58,7 +58,7 @@ Redirect permanent /java/ 
https://gcc.gnu.org/
 
 Redirect permanent /bugs.html  https://gcc.gnu.org/bugs/
 Redirect permanent /c9xstatus.html 
https://gcc.gnu.org/c99status.html
-Redirect permanent /cvswrite.html  
https://gcc.gnu.org/svnwrite.html
+Redirect permanent /cvswrite.html  
https://gcc.gnu.org/gitwrite.html
 Redirect permanent /gnats.html https://gcc.gnu.org/bugs/
 Redirect permanent /proj-bp.html   
https://gcc.gnu.org/projects/bp/main.html
 Redirect permanent /proj-cpplib.html   
https://gcc.gnu.org/projects/cpplib.html
-- 
2.24.1

Re: Proposal for the transition timetable for the move to GIT

[Gerald Pfeifer]

On Thu, 9 Jan 2020, Joseph Myers wrote:
>> Is there any chance we could get one more trunk snapshot before the
>> conversion starts -- even if that means firing up the snapshot process
>> Friday?  It'd be quite useful for the ongoing Fedora build testing.
> I could run a snapshot manually.  I was planning to run at least one 
> snapshot (for some branch) manually *after* the conversion to test the 
> conversion of the gcc_release script to use git (in snapshot mode that 
> doesn't make any commits so could be done while the git repository is 
> still read-only for checking).

Saturday's the GCC 9 snapshots are on, Sunday's GCC 10, so with a
GCC 10 snapshot out yesterday, perhaps run a GCC 9 snapshot today
or tomorrow and then fall back to the regular cadence?

Gerald

Re: Proposal for the transition timetable for the move to GIT

[Gerald Pfeifer]

On Fri, 10 Jan 2020, Maxim Kuvyrkov wrote:
> I was wrong re. r182541, I didn't notice that it is the first commit on 
> branch.  This renders the analysis in favor of reposurgeon conversion, 
> not svn-git.

Kudos for that statement, Maxim.

And thanks a bunch for all the work you have been doing, even if
the other conversion was picked in the end.  Like others have said,
without that we would not be where we are now.

Thank you,
Gerald

Re: New GCC mirror from Rabat, Morocco

[Gerald Pfeifer]

Hi Sami,

On Sun, 6 Oct 2019, Sami Ait Ali Oulahcen wrote:
> We'd like to start mirroring the GCC.

apologies, it appears none of us did get back to you last year?

Happy to have you as a mirror, and if you'd like to submit a patch
for https://gcc.gnu.org/mirrors.html that'd be great. Otherwise we
can create one.

> URLs:
> http://mirror.marwan.ma/gcc/
> https://mirror.marwan.ma/gcc/
> rsync://mirror.marwan.ma/gcc/
> Location: Rabat, Morocco
> Contact:  Sami Ait Ali Oulahcen (noc{at}marwan{dot}ma)
> 
> Please let us know of the central rsync address, and the recommended pull 
> frequency.

We've got a little page at https://gcc.gnu.org/rsync.html that has
information on our rsync service.

`rsync rsync://gcc.gnu.org/` lists a long list of targets, and the
one you'll probably want is gcc-ftp, so

  rsync --archive --delete --compress rsync://gcc.gnu.org/gcc-ftp /loc/al/dir

I guess?

(Let me know whether/what works for you, and I'll make sure to 
enhance our documentation.)


As for frequence, once a day, maybe a bit after snapshot runs happen,
so around midnight your timezone should work fine.

Thank you,
Gerald

Re: http://www.netgull.com mirror broken

[Gerald Pfeifer]

On Wed, 4 Dec 2019, Dan Allen wrote:
> http://www.netgull.com has gcc snapshots and releases, but in the past 
> few weeks only the diffs are there - none of the actual source tarballs 
> are present.
> 
> I am not sure how to get this message through to netball, but I figured 
> you had a better chance than I.

At https://gcc.gnu.org/mirrors.html we have

  US, San Jose: http://www.netgull.com, thanks to admin at netgull.com

so let me relay this to ad...@netgull.com.  


NetGull, would you mind looking into this?  It appears you have stopped
mirroring gcc.gnu.org beginning of December?

Thank you,
Gerald


PS: I just removed all snapshots carrying a date of 2018, which reduces
storage requirements by 7GB.

Re: GCC 7.5 Released

[Gerald Pfeifer]

On Fri, 15 Nov 2019, Richard Biener wrote:
>> I disabled snapshots from the GCC 7 branch on gcc.gnu.org.
> Huh, I thought I did - I usually do this when creating the RC
> (and I didn't see a new snapshot during the RC phase).

ftp://gcc.gnu.org/pub/gcc/snapshots/7-20191107/ came after
ftp://gcc.gnu.org/pub/gcc/snapshots/7.5.0-RC-20191105/ which
is how I noticed.

(The snapshot that would have come yesterday did not materialize,
so the GCC 7 branch is closed for real.)

Gerald

Re: GCC 7.5 Released

[Gerald Pfeifer]

On Thu, 14 Nov 2019, Richard Biener wrote:
> This is also the last release from the GCC 7 branch which 
> will receive no further fixes from now on.

I disabled snapshots from the GCC 7 branch on gcc.gnu.org.  (It
appears you made that change in SVN and ~gccadmin/scripts on that
machine, but not the actual crontab?)

Gerald

Re: Hello, I would like to know how to download gcc 9.2 in windows from here. https://ftp.gnu.org/gnu/gcc/gcc-9.2.0/ Thanks.

[Gerald Pfeifer]

On Tue, 5 Nov 2019, Aditya Guharoy wrote:
> I would like to know how to download gcc 9.2 in windows from here.
> https://ftp.gnu.org/gnu/gcc/gcc-9.2.0/

We distribute source code, that in turn can then be built for
various platforms (such as Windows).

If you enter "gcc windows binary" in your favorite search engine,
you should find pre-built binary downloads.

Gerald

PS: Questions like this are better addressed to gcc-h...@gcc.gnu.org;
gcc@gcc.gnu.org is for the development of GCC.

Re: git conversion of GCC wwwdocs repository

[Gerald Pfeifer]

On Wed, 25 Sep 2019, Jonathan Wakely wrote:
> I mean that there's not much value in having my past commits listed as
> coming from various "different" authors:
> 
> Jonathan Wakely 
> Jonathan Wakely 
> Jonathan Wakely 
> Jonathan Wakely 
> Jonathan Wakely 
> 
> All of those "identities" are the same person, so making all my
> commits use the same Author is arguably correct, even if I was using
> different addresses at different times.

In my case that address really is ger...@pfeifer.com (which I should
keep for the rest of my life).

I noticed today that old commits show up as ger...@gcc.gnu.org, whereas
those from after the conversion show up as ger...@pfeifer.com.  Is there
a way to unify that to ger...@pfeifer.com throughout?

Gerald

Re: GCC wwwdocs move to git done

[Gerald Pfeifer]

On Wed, 9 Oct 2019, Joseph Myers wrote:
> I've done the move of GCC wwwdocs to git (using the previously posted and 
> discussed scripts), including setting up the post-receive hook to do the 
> same things previously covered by the old CVS hooks, and minimal updates 
> to the web pages dealing with the CVS setup for wwwdocs.

Really, really, cool.  Thanks a huge bunch, Joseph!

> Note 2: changes may be needed to the process for updating www.gnu.org 
> and Gerald's validator.

The validator *should* be working in this new world now.

And I am in contact with webmas...@gnu.org and will update this round
as things evolve.  (Not an urgency, just important.)

Gerald

Re: GCC Git hooks

[Gerald Pfeifer]

On Mon, 16 Sep 2019, Joel Brobecker wrote:
> You mean the email notification sent by the hooks when a commit
> gets pushed? If yes, here is an example:
> 
> https://www.sourceware.org/ml/gdb-cvs/2019-09/msg00041.html

Thank you, Joel!  I got a little worried how to best parse that ;-),
but then Joseph recommended against it and...

On Mon, 16 Sep 2019, Joseph Myers wrote:
> Rather, I suggest using the emails only as a signal that something has 
> been pushed to the repository.  You can then e.g. use "git rev-parse HEAD" 
> before and after updating the local checkout to see what the old and new 
> HEAD commits were, and "git diff --name-only" to list the modified, new or 
> removed files (as in the posted hook).

...luckily provided an alternative.  Thanks for that, Joseph!  I had
a look and have started to adjust my script following your recommendation.

>From my perspective this should not hold off anything.  I can keep 
adjusting even once the switch has taken place and validate changes
manually during that period.

When, roughly, do you expect the switch can be ready?  I assume we'll
have some sort of flag day?  (I got in contact with webmas...@gnu.org 
who are asking the same questions.)

Gerald

Re: GCC Git hooks

[Gerald Pfeifer]

On Sun, 15 Sep 2019, Joseph Myers wrote:
> Apart from general review of the test conversion / conversion and hook 
> scripts, which everyone can do, I think the main thing would be to advise 
> on what needs to happen to avoid breaking the www.gnu.org copy of the site 
> and your HTML validation system for commits.

I reached out to the GNU webmasters for the former.  

On the latter, let's just flip the switch whenever you're ready, and I'll 
see to adjust my script within a day or two and manually perform checks 
until that's done.  (If you can create a sample e-mail notification for 
me, I'll use that to start looking into it.)

Thanks,
Gerald

Re: GCC Git hooks

[Gerald Pfeifer]

On Sat, 14 Sep 2019, Jason Merrill wrote:
> Separately, Joseph volunteered to deal with converting the gcc-www 
> repository to git and dealing with those hooks.

This is great, thank you!

I was absolutely going to join Cauldron this week, but something personal 
is consuming me all of this month (and I am also off work), so I wanted 
to at least write a note with some thoughts, and this would have been one 
of the items -- converting wwwdocs without waiting for anything else --
... and then I got swamped the last days.

Thank you for picking this up, and for volunteering Joseph!

Let me know how I can help, and I will do my best.  (Even if I'll be
offline most of the next three weeks, I can get online most days and
spend some time.)

Yeah. :)

Gerald

[wwwdocs PATCH] for Re: autovectorization in gcc

[Gerald Pfeifer]

On Thu, 10 Jan 2019, Jonathan Wakely wrote:
>> [ https://gcc.gnu.org/projects/tree-ssa/vectorization.html ]
> I'm not disputing that there could be better documentation, but that
> page is not the place to find it. That page should probably get a
> notice added saying that the project is complete and that the page is
> now only of historical interest.

Like this? ;-)

Committed.

Gerald

Index: projects/tree-ssa/vectorization.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/projects/tree-ssa/vectorization.html,v
retrieving revision 1.42
diff -u -r1.42 vectorization.html
--- projects/tree-ssa/vectorization.html30 Sep 2018 14:38:57 -  
1.42
+++ projects/tree-ssa/vectorization.html18 Aug 2019 10:55:46 -
@@ -2,15 +2,17 @@
 
 
 
-Auto-vectorization in GCC
+Auto-vectorization in GCC
 https://gcc.gnu.org/gcc.css"; />
 
 
 
 Auto-vectorization in GCC
 
-The goal of this project is to develop a loop and basic block 
vectorizer in
-GCC, based on the tree-ssa framework.
+The goal of this project was to develop a loop and basic block
+vectorizer in GCC, based on the tree-ssa framework.
+It has been completed and the functionality has been part of GCC
+for years.
 
 Table of Contents

Renaming vec_step in tree-vect-loop.c (to fix build on powerpc/clang)

[Gerald Pfeifer]

I have seen an increasing number of reports of GCC failing to
build with clang on powerpc (on FreeBSD, though that's probably
immaterial).

Turns out that clang has vec_step as a reserved word on powerpc
with AltiVec.

We OTOH use vec_step s as a variable name in gcc/tree-vect-loop.c.


The best approach I can see is to rename vec_step.  Before I prepare
a patch: what alternate name/spelling would you prefer?

Thanks,
Gerald

Re: Building libssp on a system without gets()

[Gerald Pfeifer]

On Sun, 5 Aug 2018, Florian Weimer wrote:
>> some folks in FreeBSD-land have worked to remove all uses of gets() 
>> and in fact the gets() function itself.
>>
>> Generally GCC builds just fine in such an environment, except for
>> libssp where libssp/gets-chk.c has the following:
>>
>>char *
>>__gets_chk (char *s, size_t slen)
>>{
>>  char *ret, *buf;
>>
>>  if (slen >= (size_t) INT_MAX)
>> ==>return gets (s);   <==
>>
>>  if (slen <= 8192)
>>buf = alloca (slen + 1);
>>  else
>>buf = malloc (slen + 1);
>>  if (buf == NULL)
>> ==>return gets (s);   <==
>>
>>
>> Here gets() is used in two edge/error cases only.
>>
>>
>> What do you think of abort()ing on systems where gets() is not 
>> available, via a bit of autoconf magic?  Is this something you 
>> may be able to help with?
> If the system doesn't have gets, you will not need __gets_chk, either.

Thanks, Florian, makes sense.

Jakub, any chance you can have a look?  (I had, and my configure
foo isn't strong enough.)

Gerald

Re: Old options in self tests?

[Gerald Pfeifer]

On Thu, 4 Oct 2018, Anthony Green wrote:
> I was building a C compiler from a source tree that does not include 
> the sources for the fortran front-end.  It seems that this is no longer 
> supported, and the fortran sources must be available even if you're only 
> building C/C++.
> 
> I'll stop stripping out gcc/fortran, but I'm wondering if anybody else
> considers this a misfeature.

It looks like a mistfeature to me (even if not as bad as it would
have been in the past when we provided more finely grained tarballs
for snapshots and releases).

Gerald

Re: GCC 6.5 Status Report (2018-10-12)

[Gerald Pfeifer]

Hi Jakub,

On Fri, 12 Oct 2018, Jakub Jelinek wrote:
> If you have regression bugfixes or documentation fixes that should be
> still backported to the branch, please test them and check them in
> before Friday, October 19th

I'd like to push back 
  https://gcc.gnu.org/ml/gcc-patches/2018-10/msg00076.html
to the GCC 6 branch as well, after having gone head -> 8 -> 7 so far.

Strictly speaking it's not a regression, but appears low risk and
addresses a user reported issue.  

Okay?

Gerald

PATCH for Re: Broken mirror site

[Gerald Pfeifer]

On Tue, 2 Oct 2018, David McCallum wrote:
> At this time, your Canadian mirror site at http://gcc.parentingamerica.com/
> is broken. There is only a page with the text "It works!"... which appears
> to be untrue.

Thanks for letting us know, David!

James, heads up!

For now I committed the patch below.

Gerald

Index: mirrors.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/mirrors.html,v
retrieving revision 1.254
diff -u -r1.254 mirrors.html
--- mirrors.html30 Sep 2018 14:38:46 -  1.254
+++ mirrors.html7 Oct 2018 12:40:08 -
@@ -19,7 +19,6 @@
 
-Canada: http://gcc.parentingamerica.com";>http://gcc.parentingamerica.com, 
thanks to James Miller (jmiller at parentingamerica.com).
 France (no snapshots): ftp://ftp.lip6.fr/pub/gcc/";>ftp.lip6.fr, thanks to ftpmaint at 
lip6.fr
 France, Brittany: ftp://ftp.irisa.fr/pub/mirrors/gcc.gnu.org/gcc/";>ftp.irisa.fr, thanks 
to ftpmaint at irisa.fr
 France, Versailles: ftp://ftp.uvsq.fr/pub/gcc/";>ftp.uvsq.fr, 
thanks to ftpmaint at uvsq.fr

Re: Heads up: Our web pages are now HTML 5

[Gerald Pfeifer]

On Mon, 3 Sep 2018, Gerald Pfeifer wrote:
> PS: There are a few older pages that I'm going to give a bit more
> love and care the coming week or so, and our main page is the only 
> one left XHTML for the time being - WIP.

To give you all an update, the number of pages still requiring 
some level of attention as part of this migration should be down 
to at most a handful.

I'll do a full testrun tonight, but should any of you run into any
problems or have questions, please let me know!

Gerald

Heads up: Our web pages are now HTML 5

[Gerald Pfeifer]

As those of you watching gcc-patches@ will have noticed (or will 
notice beginning of your week), I was busy this weekend completing 
my project to convert the GCC web pages to HTML 5 (from previously 
XHTML).

What does this mean for you?

Really not a lot, practically, since most of the changes required
were moving remaining cases of direct formatting to CSS and fixing
up a thing here or there.  So, if anything, things have become more
straightforward and easier to work with.  And while marked HTML 5 
now, everything pretty much still would also validate as XHTML.

So you can essentially continue to go about things as before.

Except, it's now simpler!  For in addition to pushing CSS references 
into individual pages, all of them now also carry a proper DOCTYPE, 
without any preprocessing required.  So you can easily edit things 
locally with whatever tool you desire and upload to validator.w3.org 
as is (just ignoring a warning or two) for testing.


My earlier message to gcc-patches has a view more details:
https://gcc.gnu.org/ml/gcc-patches/2018-09/msg00026.html .

I have already updated my automated testbot for any of your commits 
to wwwdocs, and am standing by to watch and lend a helping hand should 
any be required or desired.


Let me know if you have any questions or suggestions.  

Happy hacking, and keep your doc/web page contributions coming! :-)

Gerald


PS: There are a few older pages that I'm going to give a bit more
love and care the coming week or so, and our main page is the only 
one left XHTML for the time being - WIP.

Building libssp on a system without gets()

[Gerald Pfeifer]

Hi Jakub,

some folks in FreeBSD-land have worked to remove all uses of gets() 
and in fact the gets() function itself.

Generally GCC builds just fine in such an environment, except for
libssp where libssp/gets-chk.c has the following:

   char *
   __gets_chk (char *s, size_t slen)
   {
 char *ret, *buf;

 if (slen >= (size_t) INT_MAX)
==>return gets (s);   <==

 if (slen <= 8192)
   buf = alloca (slen + 1);
 else
   buf = malloc (slen + 1);
 if (buf == NULL)
==>return gets (s);   <==


Here gets() is used in two edge/error cases only.


What do you think of abort()ing on systems where gets() is not 
available, via a bit of autoconf magic?  Is this something you 
may be able to help with?

Gerald

PS: https://reviews.freebsd.org/D12298 has some background re FreeBSD.

Re: bootstrap failure due to declaration mismatch in r260956

[Gerald Pfeifer]

On Wed, 30 May 2018, Martin Sebor wrote:
> I think your r260956 is missing the following hunk:

If this fixes the bootstrap for you (also ran into this myself
just now), can you please go ahead and commit?

We can always sort out things later, if there are details to be
tweaked, but fixing a bootstrap failure with a simple one-liner
like this, let's not get process-heavy and just do it. ;-)

Gerald

[wwwdocs PATCH] for Re: Policy for reverting someone else commit?

[Gerald Pfeifer]

On Sun, 20 May 2018, Richard Biener wrote:
> IIRC there is a 24h rule that global maintainers can invoke. Not 
> sure if that is formally documented somewhere.

Yes, we have a reversion policy; it is documented at

  https://gcc.gnu.org/develop.html

And, after me just having applied the patch below, now 
directly reachable at

  https://gcc.gnu.org/develop.html#reversion 

Gerald

Index: develop.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/develop.html,v
retrieving revision 1.180
diff -u -r1.180 develop.html
--- develop.html25 Apr 2018 08:44:26 -  1.180
+++ develop.html20 May 2018 20:20:35 -
@@ -154,7 +154,7 @@
 so it is unlikely that many conflicts will occur.
 
 
-Patch Reversion
+Patch Reversion
 
 If a patch is committed which introduces a regression on any target
 which the Steering Committee considers to be important and if:

[wwwdocs] PATCH for Re: Remove *.mirror.babylon.network

[Gerald Pfeifer]

On Wed, 21 Mar 2018, Tim Semeijn wrote:
> For the foreseeable future we will not be able to provide our mirrors
> anymore. Could you please remove:
> 
> nl.mirror.babylon.network
> fr.mirror.babylon.network

Thank you for letting us know, Tim, and your service in the past!
Both are really appreciated.

I made this change per the patch below.

Gerald

Index: mirrors.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/mirrors.html,v
retrieving revision 1.249
diff -u -r1.249 mirrors.html
--- mirrors.html19 Mar 2018 00:26:23 -  1.249
+++ mirrors.html4 Apr 2018 06:55:17 -
@@ -21,11 +21,6 @@
 Canada: http://gcc.skazkaforyou.com";>http://gcc.skazkaforyou.com, thanks to 
Sergey Ivanov (mirrors at skazkaforyou.com)
 France (no snapshots): ftp://ftp.lip6.fr/pub/gcc/";>ftp.lip6.fr, thanks to ftpmaint at 
lip6.fr
 France, Brittany: ftp://ftp.irisa.fr/pub/mirrors/gcc.gnu.org/gcc/";>ftp.irisa.fr, thanks 
to ftpmaint at irisa.fr
-France, Gravelines:
-  http://fr.mirror.babylon.network/gcc/";>http://fr.mirror.babylon.network/gcc/
 |
-  ftp://fr.mirror.babylon.network/gcc/";>ftp://fr.mirror.babylon.network/gcc/
 |
-  rsync://fr.mirror.babylon.network/gcc/,
-  thanks to Tim Semeijn (noc@babylon.network) at Babylon Network.
 France, Versailles: ftp://ftp.uvsq.fr/pub/gcc/";>ftp.uvsq.fr, 
thanks to ftpmaint at uvsq.fr
 Germany, Berlin: ftp://ftp.fu-berlin.de/unix/languages/gcc/";>ftp.fu-berlin.de, thanks 
to ftp at fu-berlin.de
 Germany: ftp://ftp.gwdg.de/pub/misc/gcc/";>ftp.gwdg.de, thanks 
to emoenke at gwdg.de
@@ -34,11 +29,6 @@
 Greece: ftp://ftp.ntua.gr/pub/gnu/gcc/";>ftp.ntua.gr, thanks 
to ftpadm at ntua.gr
 Hungary, Budapest: http://robotlab.itk.ppke.hu/gcc/";>robotlab.itk.ppke.hu, thanks to 
Adam Rak (neurhlp at gmail.com)
 Japan: http://ftp.tsukuba.wide.ad.jp/software/gcc/";>ftp.tsukuba.wide.ad.jp, 
thanks to Kohei Takahashi (tsukuba-ftp-servers at tsukuba.wide.ad.jp)
-The Netherlands, Amsterdam:
-  http://nl.mirror.babylon.network/gcc/";>http://nl.mirror.babylon.network/gcc/
 |
-  ftp://nl.mirror.babylon.network/gcc/";>ftp://nl.mirror.babylon.network/gcc/
 |
-  rsync://nl.mirror.babylon.network/gcc/,
-  thanks to Tim Semeijn (noc@babylon.network) at Babylon Network.
 The Netherlands, Dronten:
   http://mirror.koddos.net/gcc/";>http://mirror.koddos.net/gcc/ |
   rsync://mirror.koddos.net/gcc/,

[cpp,doc] PATCH for Re: CPP documentation minor typo

[Gerald Pfeifer]

On Tue, 20 Feb 2018, Bogdan Harjoc wrote:
> __VA_OPT__ was documented after 7.3.0 and the eprintf example for it
> ends with two backslashes instead of one:
> 
> https://gcc.gnu.org/onlinedocs/cpp/Variadic-Macros.html

Thank you for reporting this, Bogdan.

I just fixed this per the patch below.

Gerald

2018-04-02  Gerald Pfeifer  

* doc/cpp.texi (Variadic Macros): Fix line continuation in an
example.

Index: doc/cpp.texi
===
--- doc/cpp.texi(revision 259011)
+++ doc/cpp.texi(working copy)
@@ -1710,7 +1710,7 @@
 not have any tokens, the @code{@w{__VA_OPT__}} expands to nothing:
 
 @smallexample
-#define eprintf(format, @dots{}) \\
+#define eprintf(format, @dots{}) \
   fprintf (stderr, format __VA_OPT__(,) __VA_ARGS__)
 @end smallexample
 

"file name" vs "filename"

[Gerald Pfeifer]

And now to the most important question of all. ;-)  Should we use
"file name" or "filename" when referring to the name of a file?

Our docs currently are about even and I think it would be good to
settle on one?

  % grep "filename" $GCC/gcc/doc/*.texi | wc -l
  92
  % grep "file name" $GCC/gcc/doc/*.texi | wc -l
  103

(Once we have consensus, I'll add that to codingconventions.html
and start by making the web pages consistent.)

Gerald

[wwwdocs] PATCH for Re: GCC mirror - Please read it

[Gerald Pfeifer]

On Sat, 3 Feb 2018, BigSearcher Info wrote:
> please let me know if you need the mirror I set for the GCC community 
> some weeks ago.

Thank you for doing that and letting us know, and sorry for the
delay in responding.

I just added this to the official GCC mirrors list per the patch
below.

Cheers,
Gerald

Index: mirrors.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/mirrors.html,v
retrieving revision 1.248
diff -u -r1.248 mirrors.html
--- mirrors.html4 Mar 2018 09:59:46 -   1.248
+++ mirrors.html19 Mar 2018 00:25:09 -
@@ -47,6 +47,7 @@
 Russia, Novosibirsk: http://mirror.linux-ia64.org/gnu/gcc/";>http://mirror.linux-ia64.org/gnu/gcc/,
 thanks to Daniel Volchixin 
 Slovakia, Bratislava: http://gcc.fyxm.net/";>gcc.fyxm.net, 
thanks to Jan Teluch (admin at 2600.sk)
 UK: ftp://ftp.mirrorservice.org/sites/sourceware.org/pub/gcc/";>ftp://ftp.mirrorservice.org/sites/sourceware.org/pub/gcc/,
 thanks to mirror at mirrorservice.org
+US, San Francisco: https://bigsearcher.com/mirrors/gcc/";>https://bigsearcher.com/mirrors/gcc/,
 thanks to i...@bigsearcher.com
 US, San Jose: http://www.netgull.com/gcc/";>http://www.netgull.com, thanks to admin 
at netgull.com
 US: http://mirrors-usa.go-parts.com/gcc/";>http://mirrors-usa.go-parts.com/gcc,
 thanks to Dan Derebenskiy 
 US, Michigan: http://mirrors.concertpass.com/gcc/";>http://mirrors.concertpass.com/gcc/,
 thanks to ad...@mirrors.concertpass.com.

www.sgi.com/tech/stl/ is gone

[Gerald Pfeifer]

...redirecting to a dummy page.  Unfortunately there are a fair
number of references in the libstdc++ docs, see below.

I'll take care of anything outside of libstdc++; can you please
have a look as far as the libstdc++ docs go?

Gerald


http://gcc.gnu.org/onlinedocs/libstdc++/faq.html

  □ http://www.sgi.com/tech/stl/
  □ http://www.sgi.com/tech/stl/FAQ.html
  □ http://www.sgi.com/tech/stl/whats_new.html

http://gcc.gnu.org/onlinedocs/libstdc++/manual/debug_mode_design.html

  □ http://www.sgi.com/tech/stl/

http://gcc.gnu.org/onlinedocs/libstdc++/manual/ext_numerics.html

  □ http://www.sgi.com/tech/stl/iota.html

http://gcc.gnu.org/onlinedocs/libstdc++/manual/ext_sgi.html

  □ http://www.sgi.com/tech/stl/HashFunction.html
  □ http://www.sgi.com/tech/stl/hash.html

http://gcc.gnu.org/onlinedocs/libstdc++/manual/policy_data_structures.html

  □ http://www.sgi.com/tech/stl/

http://gcc.gnu.org/onlinedocs/libstdc++/manual/using_concurrency.html

  □ http://www.sgi.com/tech/stl/Allocators.html
  □ http://www.sgi.com/tech/stl/thread_safety.html

http://gcc.gnu.org/onlinedocs/libstdc++/manual/utilities.html

  □ http://www.sgi.com/tech/stl/functors.html

[wwwdocs] PATCH for Re: Create a new mirror

[Gerald Pfeifer]

On Wed, 28 Feb 2018, KoDDoS Mirror wrote:
> We added missing cronjob to update it. It should be updated in 
> less than 6 hours.

Yep, it did.  I just applied the patch below.

Thank you for mirroring and letting us know!

Gerald


Index: mirrors.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/mirrors.html,v
retrieving revision 1.246
diff -u -r1.246 mirrors.html
--- mirrors.html22 Oct 2017 11:46:12 -  1.246
+++ mirrors.html4 Mar 2018 09:52:45 -
@@ -40,6 +40,10 @@
   ftp://nl.mirror.babylon.network/gcc/";>ftp://nl.mirror.babylon.network/gcc/
 |
   rsync://nl.mirror.babylon.network/gcc/,
   thanks to Tim Semeijn (noc@babylon.network) at Babylon Network.
+The Netherlands, Dronten:
+  http://mirror.koddos.net/gcc/";>http://mirror.koddos.net/gcc/ |
+  rsync://mirror.koddos.net/gcc/,
+  thanks to Martin (mir...@koddos.net) at KoDDoS.
 The Netherlands, Nijmegen: ftp://ftp.nluug.nl/mirror/languages/gcc";>ftp.nluug.nl, thanks to Jan 
Cristiaan van Winkel (jc at ATComputing.nl)
 Russia, Novosibirsk: http://mirror.linux-ia64.org/gnu/gcc/";>http://mirror.linux-ia64.org/gnu/gcc/,
 thanks to Daniel Volchixin 
 Slovakia, Bratislava: http://gcc.fyxm.net/";>gcc.fyxm.net, 
thanks to Jan Teluch (admin at 2600.sk)

Re: Create a new mirror

[Gerald Pfeifer]

Hi Martin,

On Mon, 6 Nov 2017, KoDDoS Mirror wrote:
> The mirror is setup. Here is a patch as I do not have write access to 
> push it.

I was just going to commit the following patch (sorry for the
delay), alas noticed your mirror does not seem to, umm, mirror?

The expectation is that you'll mirror additions/deletions on a
regular base (ideally no less than daily).  Are you planning to
put that in place?

Gerald

Index: mirrors.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/mirrors.html,v
retrieving revision 1.246
diff -u -r1.246 mirrors.html
--- mirrors.html22 Oct 2017 11:46:12 -  1.246
+++ mirrors.html26 Feb 2018 21:16:57 -
@@ -40,6 +40,10 @@
   ftp://nl.mirror.babylon.network/gcc/";>ftp://nl.mirror.babylon.network/gcc/
 |
   rsync://nl.mirror.babylon.network/gcc/,
   thanks to Tim Semeijn (noc@babylon.network) at Babylon Network.
+The Netherlands, Dronten:
+  http://mirror.koddos.net/gcc/";>http://mirror.koddos.net/gcc/ |
+  rsync://mirror.koddos.net/gcc/,
+  thanks to Martin (mir...@koddos.net) at KoDDoS.
 The Netherlands, Nijmegen: ftp://ftp.nluug.nl/mirror/languages/gcc";>ftp.nluug.nl, thanks to Jan 
Cristiaan van Winkel (jc at ATComputing.nl)
 Russia, Novosibirsk: http://mirror.linux-ia64.org/gnu/gcc/";>http://mirror.linux-ia64.org/gnu/gcc/,
 thanks to Daniel Volchixin 
 Slovakia, Bratislava: http://gcc.fyxm.net/";>gcc.fyxm.net, 
thanks to Jan Teluch (admin at 2600.sk)

[PATCH] for Re: netgull.com mirror doesn't have gcc release .sig files.

[Gerald Pfeifer]

On Tue, 8 Jul 2014, Richard Biener wrote:
>> The reason you do not see .sig files on our netgull.com mirror is
>> that it mirrors gcc.gnu.org, which does not carry those, whereas
>> ftp.gnu.org and hence its mirrors has them.
>>
>> Richi, Jakub, can you also add those .sig files to the copies on
>> gcc.gnu.org going forward?
> Nothing against that ... can you add an action item to releasing.html 
> please?

Done thusly.

Sorry for the delay (ahem).

Gerald

Index: releasing.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/releasing.html,v
retrieving revision 1.48
diff -u -r1.48 releasing.html
--- releasing.html  17 Jan 2018 13:10:17 -  1.48
+++ releasing.html  23 Feb 2018 07:54:01 -
@@ -60,6 +60,9 @@
 
 Upload the release to ftp.gnu.org.
 
+Ensure that the upload on gcc.gnu.org also comes with
+cryptographic signatures (.sig files).
+
 Increment the version number in gcc/BASE-VER. 
 gcc/DEV-PHASE remains empty. Check the file in.
 

Re: Create a new mirror

[Gerald Pfeifer]

Hi Martin,

On Tue, 31 Oct 2017, KoDDoS Mirror wrote:
> We would like to create a new mirror for GCC in Dronten, Netherlands.
> 
> Can you let us know how to process?

you can just ahead, and let us know (ideally with a patch against
http://gcc.gnu.org/mirrors.html ); that's all then. :-)

Cheers,
Gerald

[wwwdocs] PATCH for Re: New mirror site

[Gerald Pfeifer]

On Sat, 2 Sep 2017, Daniel Volchixin wrote:
> URL: http://mirror.linux-ia64.org/gnu/gcc/
> Country/City: Russia / Novosibirsk
> Contact email / name: dan...@volchixin.co.uk (Daniel Volchixin)

Thank you for hosting this mirror, Daniel and letting us know.

I added this to our mirrors page with the page below.  (And sorry
for the delay.)

Geral

Index: mirrors.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/mirrors.html,v
retrieving revision 1.245
diff -u -r1.245 mirrors.html
--- mirrors.html1 Aug 2017 12:00:24 -   1.245
+++ mirrors.html22 Oct 2017 11:44:09 -
@@ -41,6 +41,7 @@
   rsync://nl.mirror.babylon.network/gcc/,
   thanks to Tim Semeijn (noc@babylon.network) at Babylon Network.
 The Netherlands, Nijmegen: ftp://ftp.nluug.nl/mirror/languages/gcc";>ftp.nluug.nl, thanks to Jan 
Cristiaan van Winkel (jc at ATComputing.nl)
+Russia, Novosibirsk: http://mirror.linux-ia64.org/gnu/gcc/";>http://mirror.linux-ia64.org/gnu/gcc/,
 thanks to Daniel Volchixin 
 Slovakia, Bratislava: http://gcc.fyxm.net/";>gcc.fyxm.net, 
thanks to Jan Teluch (admin at 2600.sk)
 UK: ftp://ftp.mirrorservice.org/sites/sourceware.org/pub/gcc/";>ftp://ftp.mirrorservice.org/sites/sourceware.org/pub/gcc/,
 thanks to mirror at mirrorservice.org
 US, San Jose: http://www.netgull.com/gcc/";>http://www.netgull.com, thanks to admin 
at netgull.com

Re: broken link on this page https://gcc.gnu.org/gcc-7/changes.html for link to "Profile Mode" page:

[Gerald Pfeifer]

On Fri, 4 Aug 2017, Jonathan Wakely wrote:
> Thanks for letting us know, I've fixed the link.

Thanks, Jonathan.

https://gcc.gnu.org/onlinedocs/gcc-7.1.0/libstdc++/manual/manual/profile_mode.html
   ^

Should we do something about "manual/manual" in the above, though?

Gerald

Re: Remove broken GCC 7.1 GCJ manual links

[Gerald Pfeifer]

Hi Krisztian,

On Thu, 29 Jun 2017, Paczári Krisztián wrote:
> GCJ has been removed from GCC 7.1, so these broken links should also be 
> removed from the documentation page (https://gcc.gnu.org/onlinedocs/) 
> and probably from the scripts generating them: "GCC 7.1 GCJ Manual (also 
> in PDF or PostScript or an HTML tarball)"

thanks for the heads-up.  Just to confirm that Jakub has addressed
this two weeks ago.  If you seen anything left or anything else, please
advise.

Gerald

Re: [og7] Git branch "openacc-gcc-7-branch"

[Gerald Pfeifer]

On Tue, 18 Jul 2017, Thomas Schwinge wrote:
> This being a Git-only branch, should it nevertheless be listed on
> , in the "Active Development Branches"
> section, replacing "gomp-4_0-branch" there?

I would say so (with an according note).

Thanks for thinking of that.  (Once we have git in place, which 
will allow for a cp or mv, I'm thinking to break this portion out 
and call it branches.html or so.)

Gerald

Re: Remove ca.mirror.babylon.network

[Gerald Pfeifer]

On Sun, 16 Jul 2017, Tim Semeijn wrote:
> We will soon decommission our Canadian mirror due to restructuring.
> Please remove the following server from the mirror list:
> 
> ca.mirror.babylon.network/gcc

Thank for you the head-up, Tim.  I applied the patch below to make
this change accordingly.

> Our French mirrors will remain active.

Good to know; kept in place.

Gerald

Index: mirrors.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/mirrors.html,v
retrieving revision 1.243
diff -u -r1.243 mirrors.html
--- mirrors.html22 Apr 2017 13:47:58 -  1.243
+++ mirrors.html16 Jul 2017 05:37:55 -
@@ -19,11 +19,6 @@
 -->
 Canada: http://gcc.parentingamerica.com";>http://gcc.parentingamerica.com, 
thanks to James Miller (jmiller at parentingamerica.com).
 Canada: http://gcc.skazkaforyou.com";>http://gcc.skazkaforyou.com, thanks to 
Sergey Ivanov (mirrors at skazkaforyou.com)
-Canada, Quebec:
-  http://ca.mirror.babylon.network/gcc/";>http://ca.mirror.babylon.network/gcc/
 |
-  ftp://ca.mirror.babylon.network/gcc/";>ftp://ca.mirror.babylon.network/gcc/
 |
-  rsync://ca.mirror.babylon.network/gcc/,
-  thanks to Tim Semeijn (noc@babylon.network) at Babylon Network.
 France (no snapshots): ftp://ftp.lip6.fr/pub/gcc/";>ftp.lip6.fr, thanks to ftpmaint at 
lip6.fr
 France, Brittany: ftp://ftp.irisa.fr/pub/mirrors/gcc.gnu.org/gcc/";>ftp.irisa.fr, thanks 
to ftpmaint at irisa.fr
 France, Gravelines:

Re: gcc-6-branch snapshots disabled?

[Gerald Pfeifer]

On Fri, 14 Jul 2017, Mikael Pettersson wrote:
> Seems like the weekly snapshots from gcc-6-branch were disabled before
> the 6.4.0 release but not re-enabled afterwards.  The snapshots from
> trunk and gcc-{7,5}-branch are being generated as usual.

You are right, I observed the same and just enabled snapshots
for the gcc-6-branch again.

The next snapshot should appear coming Wednesday per 
maintainer-scripts/crontab in the GCC repository.

Gerald

Re: Steering committee, please, consider using lzip instead of xz

[Gerald Pfeifer]

On Thu, 8 Jun 2017, Antonio Diaz Diaz wrote:
> You mean SUSE Linux Enterprise Server is using a format that does 
> not guarantee safe interoperability among implementations[1] to
> "power mission-critical workloads"!?

I am not aware of a single customer complaint.

> For the case of SLES[2] I would say that avoiding xz is a must. IMHO 
> SLES users are better served by falling back to the .gz tarball until 
> the next major version of SLES is released than by suffering xz forever.

Users and customers have this thing where they prefer to make decisions
like this as opposed to the operating system vendor prescribing what 
they may or must not use.  

And this is something free software projects and Enterprise software
tend to have in common:  Ultimately many decisions are motivated bottom
up (from the users/customers), not top down.  My recommendation is you
keep pushing the strengths and advantages of lzip to broaden its user
base and when/if we'll see more user requests, that may be a trigger
to adjust how GCC's releases and snapshots are published.

Gerald, who happens to be the maintainer of lzip in the FreeBSD 
Ports Collection

Re: Potential Bug in GCC5?

[Gerald Pfeifer]

Hi Yubin,

On Sun, 11 Jun 2017, Yubin Ruan wrote:
> I don't know whether this bug has been reported(I have check GCC 
> Bugzillia though) or has been resolved:
> 
> This program:
> 
> #include 
> int main()
> {
>   char a = 'a';
>   printf("Size of char : %d\n",sizeof(a));
>   printf("Size of char : %d\n",sizeof('a'));
>   return 0;
> }
> 
> when compiled with:
> 
> gcc -Wall testgcc.c -o testgcc -fexec-charset=utf-16
> 
> will triggers GCC's bug report reminder:
> 
>   ...
>   internal compiler error: character 0xa is not unibyte in execution 
> character set

as a user / bug reporter I quite like internal compiler errors in
that there is no argument of whether there is a bug here or not. ;-)

(The question is whether it is what we call "ICE on valid", that is,
an internal compiler error on valid input, or "ICE on invalid", where
the latter is a bug as well, but clearly not as severe as the former.)

> Is it appropriate for me to create a bug report on GCC's bugzillia?

Yes.  We prefer that you reproduce with a current version of GCC,
since for GCC 5 (let alone older) most new bug reports likely won't
be fixed any more, and newer versions may have fixed an issue already
after all, but in principle also accept reports against older versions.

I reproduced this with GCC 7.1.1 and filed a bug report:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81050

Gerald

PS: GCC 7.1.1 shows the following with -Wall, though -Wall is not
necessary to reproduce the issue:

x.c: In function ‘main’:
x.c:4:16: warning: multi-character character constant [-Wmultichar]
   char a = 'a';
^~~
x.c:4:16: warning: overflow in implicit constant conversion [-Woverflow]
x.c:5:14: warning: embedded ‘\0’ in format [-Wformat-contains-nul]
   printf("Size of char : %d\n",sizeof(a));
  ^
x.c:5:14: warning: too many arguments for format [-Wformat-extra-args]
x.c:6:43: warning: multi-character character constant [-Wmultichar]
   printf("Size of char : %d\n",sizeof('a'));
   ^~~
x.c:6:14: warning: embedded ‘\0’ in format [-Wformat-contains-nul]
   printf("Size of char : %d\n",sizeof('a'));
  ^
x.c:6:14: warning: too many arguments for format [-Wformat-extra-args]
x.c:8:0: internal compiler error: character 0xa is not unibyte in 
execution character set
 }

PPS: The warnings added with -Wall here don't appear to be helpful, 
either.  In fact, "embedded ‘\0’ in format" appears confusing/incorrect 
to me?

Re: Web page for binaries

[Gerald Pfeifer]

Hi FX,

On Tue, 2 May 2017, FX wrote:
> I’m suggesting we apply the following patch to provide links to macOS 
> package managers, where users can download binaries for GCC on macOS. I 
> have included the two major ones, Homebrew and MacPorts.

did you mean to send this to gcc-patches@ ?

The change looks fine to me, but note that this page (like all of
our installation instructions) is generated from gcc/doc/install.texi.

Gerald

Re: Who broke options.h?

[Gerald Pfeifer]

On Tue, 25 Apr 2017, Jakub Jelinek wrote:
> Committed to trunk, 7.x will need to wait until 7.1 is released, 
> the rc1 is already in the works and this isn't anything new, I 
> see the same thing already in GCC 4.0.

Thanks, Jakub!  Are you planning to apply this to GCC 7 after the
release of 7.1?

And would you mind backporting this to active release branches?
(If not, okay if I do?)

Gerald

[wwwdocs] PATCH for Re: Austriaon gcc mirror is offline

[Gerald Pfeifer]

On Sat, 22 Apr 2017, Branko wrote:
> On your https://gcc.gnu.org/mirrors.html page, first mirror listed is 
> Austrian ftp://gd.tuwien.ac.at/gnu/gcc.
> 
> I've noticed that it is offline for a few days. I tried firing email to 
> Antonin.Sprinzl at tuwien.ac.at as listed on a page, but it keeps being 
> dropped with the reply ( "Generic address unknown" ), so I'm contacting 
> you.

Thank you for letting us know, Branko.

I disabled the Austrian mirror in our listing per the patch below.
If/when you hear anything fron Antonin or otherwise, an update would
be great.

Gerald (whose alma mater tuwien.ac.at coincidentally is)

Index: mirrors.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/mirrors.html,v
retrieving revision 1.242
diff -u -r1.242 mirrors.html
--- mirrors.html14 Apr 2017 22:47:47 -  1.242
+++ mirrors.html22 Apr 2017 13:44:35 -
@@ -14,7 +14,9 @@
 (Phoenix, Arizona, USA) directly:
 
 
+
 Canada: http://gcc.parentingamerica.com";>http://gcc.parentingamerica.com, 
thanks to James Miller (jmiller at parentingamerica.com).
 Canada: http://gcc.skazkaforyou.com";>http://gcc.skazkaforyou.com, thanks to 
Sergey Ivanov (mirrors at skazkaforyou.com)
 Canada, Quebec:

PATCH for Re: mirrors

[Gerald Pfeifer]

On Sat, 8 Apr 2017, Ionut Vatavu wrote:
> I would like to announce a new mirror in Germany Gunzenhausen:
> 
> http://www.bothelp.net/mirrors/gcc - updated daily by rsync

Thanks, Ionut.

This is now part of our mirrors list per the patch below.

Gerald

Index: mirrors.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/mirrors.html,v
retrieving revision 1.241
diff -u -r1.241 mirrors.html
--- mirrors.html7 Feb 2017 21:50:17 -   1.241
+++ mirrors.html14 Apr 2017 22:46:41 -
@@ -31,6 +31,7 @@
   thanks to Tim Semeijn (noc@babylon.network) at Babylon Network.
 France, Versailles: ftp://ftp.uvsq.fr/pub/gcc/";>ftp.uvsq.fr, 
thanks to ftpmaint at uvsq.fr
 Germany, Berlin: ftp://ftp.fu-berlin.de/unix/languages/gcc/";>ftp.fu-berlin.de, thanks 
to ftp at fu-berlin.de
+Germany, Gunzenhausen: http://www.bothelp.net/mirrors/gcc/";>www.bothelp.net, thanks to Ionut 
Vatavu (iva...@googlemail.com).
 Germany: ftp://ftp.gwdg.de/pub/misc/gcc/";>ftp.gwdg.de, thanks 
to emoenke at gwdg.de
 Germany: ftp://ftp.mpi-sb.mpg.de/pub/gnu/mirror/gcc.gnu.org/pub/gcc/";>ftp.mpi-sb.mpg.de,
 thanks to ftpadmin at mpi-sb.mpg.de
 Germany: http://gcc.cybermirror.org";>http://gcc.cybermirror.org, thanks to 
Sascha Schwarz (cm at cybermirror.org)