Re: [wwwdocs] gcc-14: Mention that some warnings are now errors

[Gerald Pfeifer]

Hi Sebastian,

On Sat, 13 Apr 2024, Sebastian Huber wrote:
> +  The following warnings are now errors (see also
> +Porting to GCC 14):
> +
> +  -Werror=declaration-missing-parameter-type
> +  -Werror=implicit-function-declaration
> +  -Werror=implicit-int
> +  -Werror=incompatible-pointer-types
> +  -Werror=int-conversion
> +  -Werror=return-mismatch
> +

thanks for putting this together. Just a question, and maybe I'm confused:
these don't look like warnings to me?

Are you saying that what used to be -Wint-conversion is now an error by 
default and does not need to activated as such with any further options?

(That is, it appears as if those -Werror=... flags were used?)

And does this apply to all C versions/dialects?

Gerald

Re: [pushed] c++/modules: make bits_in/out move-constructible

[Gerald Pfeifer]

On Sat, 13 Apr 2024, Patrick Palka wrote:
> Pushed as obvious after verifying C++11 bootstrap is restored.

Thank you, Patrick! x86_64-unknown-freebsd13.2 is back to bootstrap again 
as well (with clang version 16.0.6).

Gerald

Re: [gcc-wwwdocs PATCH] Uncomment MCore part title

[Gerald Pfeifer]

On Fri, 12 Apr 2024, Haochen Jiang wrote:
> Uncomment that and commit as obvious.

Thank you!

Gerald

[pushed] wwwdocs: readings: Move shared-ptr.com to https

[Gerald Pfeifer]

Pushed.

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

diff --git a/htdocs/readings.html b/htdocs/readings.html
index e4e68909..ee77d969 100644
--- a/htdocs/readings.html
+++ b/htdocs/readings.html
@@ -283,7 +283,7 @@ names.
   Manufacturer: Renesas, various licensees.
   CPUs include: SH1, SH2, SH2-DSP, SH3, SH3-DSP, SH4, SH4A, SH5 series.
   https://www.renesas.com/us/en/products/microcontrollers-microprocessors/other-mcus-mpus/superh-risc-engine-family-mcus;>Renesas
 SuperH Processors
-  http://shared-ptr.com/sh_insns.html;>SuperH Instruction Set 
Summary
+  https://shared-ptr.com/sh_insns.html;>SuperH Instruction Set 
Summary
   GDB includes a simulator.
  
  
-- 
2.44.0

gcc-wwwdocs branch master updated. 45268b51ac5fc2833179f3d949765f7de050f259

[Gerald Pfeifer via Gcc-cvs-wwwdocs]

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, master has been updated
   via  45268b51ac5fc2833179f3d949765f7de050f259 (commit)
  from  e3cb19380191f624956a2dd5fd06538cca2eb2d4 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
commit 45268b51ac5fc2833179f3d949765f7de050f259
Author: Gerald Pfeifer 
Date:   Sat Mar 23 23:06:34 2024 +0100

readings: Move shared-ptr.com to https

diff --git a/htdocs/readings.html b/htdocs/readings.html
index e4e68909..ee77d969 100644
--- a/htdocs/readings.html
+++ b/htdocs/readings.html
@@ -283,7 +283,7 @@ names.
   Manufacturer: Renesas, various licensees.
   CPUs include: SH1, SH2, SH2-DSP, SH3, SH3-DSP, SH4, SH4A, SH5 series.
   https://www.renesas.com/us/en/products/microcontrollers-microprocessors/other-mcus-mpus/superh-risc-engine-family-mcus;>Renesas
 SuperH Processors
-  http://shared-ptr.com/sh_insns.html;>SuperH Instruction Set 
Summary
+  https://shared-ptr.com/sh_insns.html;>SuperH Instruction Set 
Summary
   GDB includes a simulator.
  
  

---

Summary of changes:
 htdocs/readings.html | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)


hooks/post-receive
-- 
gcc-wwwdocs

[pushed] wwwdocs: index: Avoid redirect for FOSDEM 2024 link

[Gerald Pfeifer]

Pushed.

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

diff --git a/htdocs/index.html b/htdocs/index.html
index 90f2a838..909cae75 100644
--- a/htdocs/index.html
+++ b/htdocs/index.html
@@ -55,7 +55,7 @@ mission statement.
 News
 
 
-https://inbox.sourceware.org/gcc/36fadb0549c3dca716eb3b923d66a11be2c67a61.ca...@redhat.com;>GCC
 developer room at FOSDEM 2024: Call for Participation open
+https://inbox.sourceware.org/gcc/36fadb0549c3dca716eb3b923d66a11be2c67a61.ca...@redhat.com/;>GCC
 developer room at FOSDEM 2024: Call for Participation open
 [2023-11-20] wwwdocs:
 FOSDEM 2024: Brussels, Belgium, February 3-4 2024
 
-- 
2.44.0

gcc-wwwdocs branch master updated. e3cb19380191f624956a2dd5fd06538cca2eb2d4

[Gerald Pfeifer via Gcc-cvs-wwwdocs]

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, master has been updated
   via  e3cb19380191f624956a2dd5fd06538cca2eb2d4 (commit)
  from  f9f15f6d3688894d2771d8380f1477e38050b3e1 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
commit e3cb19380191f624956a2dd5fd06538cca2eb2d4
Author: Gerald Pfeifer 
Date:   Sat Mar 23 23:03:07 2024 +0100

index: Avoid redirect for FOSDEM 2024 link

diff --git a/htdocs/index.html b/htdocs/index.html
index 90f2a838..909cae75 100644
--- a/htdocs/index.html
+++ b/htdocs/index.html
@@ -55,7 +55,7 @@ mission statement.
 News
 
 
-https://inbox.sourceware.org/gcc/36fadb0549c3dca716eb3b923d66a11be2c67a61.ca...@redhat.com;>GCC
 developer room at FOSDEM 2024: Call for Participation open
+https://inbox.sourceware.org/gcc/36fadb0549c3dca716eb3b923d66a11be2c67a61.ca...@redhat.com/;>GCC
 developer room at FOSDEM 2024: Call for Participation open
 [2023-11-20]
 FOSDEM 2024: Brussels, Belgium, February 3-4 2024
 

---

Summary of changes:
 htdocs/index.html | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)


hooks/post-receive
-- 
gcc-wwwdocs

Re: [PATCH wwwdocs] gcc-14: Some very common historic Autoconf probes that no longer work

[Gerald Pfeifer]

On Sat, 17 Feb 2024, Florian Weimer wrote:
> +
> +Older Autoconf versions (for example, Autoconf 2.13) generate core
> +probes that are incompatible with C99.  These include the basic
> +compiler functionality check:
:
:

Yes, thank you!

Gerald

PS: Feel free to copy me on wwwdocs patches.

Re: [COMMITTED htdocs] robots.txt: Disallow various wiki actions

[Gerald Pfeifer]

On Fri, 1 Mar 2024, Mark Wielaard wrote:
> It is fine for robots to crawl the wiki pages, but they should perform
> actions, generate huge diffs, search/highlight pages or generate
> calendars.

s/should/should not/ :-)

I see your patch does exactly that - thank you!

Gerald

Re: [wwwdocs] gcc-14/changes.html + projects/gomp/: OpenMP + OpenACC update

[Gerald Pfeifer]

On Tue, 27 Feb 2024, Tobias Burnus wrote:
> Minor update for older and more recent changes.

>   supported for stack variables in C and Fortran, including the OpenMP 5.1
> -  align modifier. For Fortran, OpenMP allocators can now be
> +  align modifier. In C and C++, the map clause 
> now
> +  accepts lvalue expressions. For Fortran, OpenMP allocators can now be

I would omit the comma after "C and C++".

+  acc_memcpy_to_device_async,
+  acc_memcyp_from_device and
+  acc_memcyp_from_device_async.

Oxford comma (i.e., comma before "and")?

Looks good to me (with or without my recommendations).

Thanks,
Gerald

Re: [PATCH wwwdocs] CSS: Color markup for /

[Gerald Pfeifer]

On Sat, 17 Feb 2024, Florian Weimer wrote:
> In addition to underlines and strikethroughs.  This makes it easier to 
> spot the differences in example code changes.

Looks like a good idea!

Thanks,
Gerald

Re: [PATCH] Notes on the warnings-as-errors change in GCC 14

[Gerald Pfeifer]

On Thu, 15 Feb 2024, Florian Weimer wrote:
>>> +GCC no longer casts all pointer types to all other pointer types.
>>
>> Do you mean it no longer does so implicitly, or not at all? That is,
>> there are now cases where even an explicit cast such as
>>
>>   foo_p = (foo_type*) bar_p
>>
>> no longer works? Or just
>>
>>   foo_p = bar_p
>>
>> no longer works for all combinations?
> The latter, other reviewers noted it as well, and I've got this now:
> “GCC no longer [allows implicitly casting] all pointer types to all”

Ah, got it. The wording above nicely clarifies it to me.

I am wondering whether "...every point type to every other pointer type" 
might be even more clear? (Open question, "no" being a very valid answer.)

>> I *think* we may need to use  here instead of plain '>', though I may 
>> be wrong.
> No, only  needs to be quoted.  This is true even for XML, not just
> HTML5.  Do you want me to change these to ?

No, no; if it validates, we're good. :-)

> What about this?
> 
>These failed probes tend to disable program features [together with]
>their tests[], resulting in silently dropping features.
> 
> This what I meant with “consistently”: implementations and tests are
> gone, so the testsuite doesn't flag it.

I like it!

>>> +In cases where this is a concern, generated config.log,
>>> +config.h and other source code files can be compared
>>> +using https://www.gnu.org/software/diffutils/;>diff,
>>> +to ensure there are no unexpected differences.
>> I wouldn't link to GNU diffutils here; just refer to the diff 
>> command - or even omit that aspect and leave it at "can be compared".
> diff is really useful for that, manual comparison isn't. 8-)
> I can drop the hyperlink.

Yes, I never would compare manually myself. :)

Let's drop the hyperlink then; people developing software would know diff.

>>> +Some build systems do not pass the CFLAGS environment
>>> +or make variable to all parts of the builds
>>
>> Is "make" a common variable? What is the context here?
> Hmm, I meant to allude $(CFLAGS) here.
> 
> “CFLAGS [] variable to all parts of the builds” should be
> sufficient.

Ah, reading this again I see it was "environment variable" or "make 
variable" - the beauty of natural languages and their ambiguity.

Yes, your suggested edit looks good!

> I need to add two more code examples to the Autoconf section, should I
> post a v2 with that, or add that in a subsequent commit?

Primarily as you prefer. My personal recommendation (not request) is to 
commit the current patch and then add on top.

Thanks again for your work documenting all this!

Gerald

Re: [PATCH] Notes on the warnings-as-errors change in GCC 14

[Gerald Pfeifer]

On Thu, 15 Feb 2024, Florian Weimer wrote:
>> Naive questions: Can definitions really be prototypes (in C)?
> Yes, I think so: definitions can be declarations, and function
> prototypes are declarations.  The standard uses the phrase “function
> definition that does not include a function prototype declarator”.
> Should I write “old-style function definition” instead?

I think that would have helped me (as a not too much of a language 
expert). Only make that change if you think it makes sense, though.

>>> +GCC will type-check function arguments after that, potentially
>>> +requiring further changes.  (Previously, the function declaration was
>>> +treated as not having no prototype.)
>> That second sentence uses double negation, which logically is the same as 
>> just the original statement.
> Other reviews suggests to change it to “not having [a] prototype”.

Ah, let's use that then.

>>> +By default, GCC still accepts returning an expression of
>>> +type void from within a function that itself
>>> +returns void, as a GNU extension that matches C++ rules
>>> +in this area.
 > Does the GNU extension match C++ (standard rules)?
> Yes.  Should I write “matches [standard] C++ rules”?

Looks good to me.

(At first I was confused, but I guess this is a GNU extension to the C 
standard - that matches standard C++ in this area?)

Gerald

[pushed] libstdc++: C++ item p2442 is version 1 only

[Gerald Pfeifer]

Following a mail exchange with Jonathan back in December; finally 
implementing what we discussed/he confirmed.

Gerald


libstdc++-v3:

* doc/xml/manual/status_cxx2023.xml: Fix C++ item p2442 to be
version 1.
* doc/html/manual/status.html: Regenerate.
---
 libstdc++-v3/doc/html/manual/status.html   | 4 ++--
 libstdc++-v3/doc/xml/manual/status_cxx2023.xml | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/libstdc++-v3/doc/html/manual/status.html 
b/libstdc++-v3/doc/html/manual/status.html
index 97f803063d0..dafd48035a6 100644
--- a/libstdc++-v3/doc/html/manual/status.html
+++ b/libstdc++-v3/doc/html/manual/status.html
@@ -1803,8 +1803,8 @@ or any notes about the implementation.
13.1  __cpp_lib_ranges_join_with = 202202L 
Windowing range adaptors: views::chunk
and views::slide 
-https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p2442r2.html; 
target="_top">
-P2442R2
+https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p2442r1.html; 
target="_top">
+P2442R1
 
13.1  __cpp_lib_ranges_slide = 202202L  views::chunk_by 
 https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p2443r1.html; 
target="_top">
diff --git a/libstdc++-v3/doc/xml/manual/status_cxx2023.xml 
b/libstdc++-v3/doc/xml/manual/status_cxx2023.xml
index 9d121af82df..4bf22f00bce 100644
--- a/libstdc++-v3/doc/xml/manual/status_cxx2023.xml
+++ b/libstdc++-v3/doc/xml/manual/status_cxx2023.xml
@@ -235,8 +235,8 @@ or any notes about the implementation.
Windowing range adaptors: views::chunk
and views::slide 
   
-http://www.w3.org/1999/xlink; 
xlink:href="https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p2442r2.html;>
-P2442R2
+http://www.w3.org/1999/xlink; 
xlink:href="https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p2442r1.html;>
+P2442R1
 
   
13.1 
-- 
2.43.0

[pushed] wwwdocs: index: Update link to FOSDEM announcement

[Gerald Pfeifer]

Pushed.

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

diff --git a/htdocs/index.html b/htdocs/index.html
index ed505637..032cc4b6 100644
--- a/htdocs/index.html
+++ b/htdocs/index.html
@@ -55,7 +55,7 @@ mission statement.
 News
 
 
-https://inbox.sourceware.org/36fadb0549c3dca716eb3b923d66a11be2c67a61.ca...@redhat.com;>GCC
 developer room at FOSDEM 2024: Call for Participation open
+https://inbox.sourceware.org/gcc/36fadb0549c3dca716eb3b923d66a11be2c67a61.ca...@redhat.com;>GCC
 developer room at FOSDEM 2024: Call for Participation open
 [2023-11-20] wwwdocs:
 FOSDEM 2024: Brussels, Belgium, February 3-4 2024
 
-- 
2.43.0

[pushed] install: Update gettext link

[Gerald Pfeifer]

This follows a web server redirect.

Gerald


gcc:
* doc/install.texi (Prerequisites): Update gettext link.
---
 gcc/doc/install.texi | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/gcc/doc/install.texi b/gcc/doc/install.texi
index c7794439107..173233096d1 100644
--- a/gcc/doc/install.texi
+++ b/gcc/doc/install.texi
@@ -477,8 +477,8 @@ is shown below:
 
 Necessary to build GCC with internationalization support via
 @option{--enable-nls}.  It can be downloaded from
-@uref{https://gnu.org/s/gettext/}.  If a GNU gettext distribution is
-found in a subdirectory of your GCC sources named @file{gettext}, it
+@uref{https://www.gnu.org/software/gettext/}. If a GNU gettext distribution
+is found in a subdirectory of your GCC sources named @file{gettext}, it
 will be built together with GCC, unless present in the system (either in
 libc or as a stand-alone library).
 
-- 
2.43.0

[pushed] wwwdocs: gcc-14: Fix typo in AVR section

[Gerald Pfeifer]

Note that  is not part of current HTML standards; can we simply 
remove it?

Gerald
---
 htdocs/gcc-14/changes.html | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/htdocs/gcc-14/changes.html b/htdocs/gcc-14/changes.html
index 6ac7c8b1..92bd0a7b 100644
--- a/htdocs/gcc-14/changes.html
+++ b/htdocs/gcc-14/changes.html
@@ -370,7 +370,7 @@ a work-in-progress.
precedence over __flmap.
For example, linking with
-Wl,--defsym,__RODATA_FLASH_START__=32k
-   choses the second 32KiB block.
+   chooses the second 32KiB block.
   The default uses the last 32KiB block, which is also the
hardware default for bit-field NVMCTRL_CTRLB.FLMAP.
   When a non-default block is used,
-- 
2.43.0

[pushed] wwwdocs: gcc-14: Fix markup in avr section.

[Gerald Pfeifer]

In addition, I believe it might be good to rephrase that sentence. Do you 
mean "the linker will not pull in that code from ... any more"?

Gerald

---
 htdocs/gcc-14/changes.html | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/htdocs/gcc-14/changes.html b/htdocs/gcc-14/changes.html
index cd5f5157..6ac7c8b1 100644
--- a/htdocs/gcc-14/changes.html
+++ b/htdocs/gcc-14/changes.html
@@ -390,7 +390,7 @@ a work-in-progress.
can be used:
 __asm (".global __flmap_lock"  "\n\t"
"__flmap_lock = 1");
-  When you do not want the code from#931, then define global
+  When you do not want the code from#931, then define global
symbol __do_flmap_init and the linker will no more drag
that code from libmcu.a.
   In order to return to the old placement of read-only data in RAM,
-- 
2.43.0

Re: [PATCH] Notes on the warnings-as-errors change in GCC 14

[Gerald Pfeifer]

Hi Florian,

that's been quite a bit. Thank you for putting this together so 
comprehensively and thoughtfully, with examples and background!

Note many of my points are suggestions or questions, especially if phrased 
as questions or using maybe or similar, so for your consideration.

On Fri, 2 Feb 2024, Florian Weimer wrote:
>  htdocs/gcc-14/porting_to.html | 465 
> ++
>  1 file changed, 465 insertions(+)
> +
> +Using pointers as integers and vice versa 
> (-Werror=int-conversion)

> +It makes sense to address missing int type, implicit

Should this be plural here ("int types") or some adding a 
word such as "declaration"? Genuine question.

> +Some of them will be caused by missing types resulting
> +in int, and the default int return type of
> +implicitly declared functions.

...resulting in implicit int... or something like that?
Not sure how to be phrase it.

> + Note that in some cases, it may be more appropriate to pass the
> +address of an integer variable instead of a cast of the variable's
> +value.

I'd omit the comma here since I don't feel the added emphasis is 
necessary.

(And maybe simply say "In some cases it may..."?)

> +GCC no longer casts all pointer types to all other pointer types.

Do you mean it no longer does so implicitly, or not at all? That is,
there are now cases where even an explicit cast such as

  foo_p = (foo_type*) bar_p

no longer works? Or just

  foo_p = bar_p

no longer works for all combinations?

> +To fix the compilation errors resulting from that, you can add the

"To fix compilation errors..."

> +appropriate casts, and maybe consider using code void *
> +in more places (particularly for old programs that predate the
> +introduction of void into the C language).

Here I got confused.

At first I thought I was reading that void * should be used 
for cases where void did not exist yet. Now I think I 
understand: this is about programs where void * was not used 
since it was not part of the language yet - and the encouragement is to 
update such old code by using it. 

If so, how about making the second case void *, too?

> +Programs that do not carefully track pointer types are likely to
> +contain aliasing violations, so consider building
> +with -fno-strict-aliasing as well.

I suggest omitting "as well" here.

> (Whether the casts
> +are written manually or performed by GCC automatically does not make a
> +difference in terms of strict aliasing violations.)

Here I'd just say "Whether casts are", omitting "the".

> +#include stddef.h>

I *think* we may need to use  here instead of plain '>', though I may 
be wrong.


> +To correct this, the callback function should be defined with the
> +correct type

"To address this ... be defined with the correct type"

(To avoid the double "correct"ion.)

> +
> +int
> +compare (const void *a1, const void *b1)
> +{
> +  char *const *a = a1;
> +  char *const *b = b1;
> +  return strcmp (*a, *b);
> +}
> +

Great that you include this example here, that really helps!

Just why "const void *a1" versus "char *const *a", that is, the different 
placement of const?

And should it be "const void **a1" and similarly for "b1"??

> +As mentioned initially, adding the cast here would not eliminate any
> +strict aliasing violation in the implementation of
> +the operate function.

Really great you are pointing this out explicitly; thank you!

> +It may be possible to avoid writing manual casts with
> +the -fplan9-extensions options and unnamed

...option... (singular)

> +unrelated to the actual objective of the probe.  These failed probes
> +tend to consistently disable program features and their tests, which
> +means that an unexpected probe failure may result in silently dropping
> +features.

Omit "consistently"? I'm not sure what it adds here. And simplify the 
second half, something like

  These failed probes tend to disable program features (and their tests), 
  resulting in silently dropping features.

> +In cases where this is a concern, generated config.log,
> +config.h and other source code files can be compared
> +using https://www.gnu.org/software/diffutils/;>diff,
> +to ensure there are no unexpected differences.

I wouldn't link to GNU diffutils here; just refer to the diff 
command - or even omit that aspect and leave it at "can be compared".

> +This phenomenon also impacts similar procedures part of CMake, Meson,
> +and various build tools for C extension modules of scripting
> +languages.

"...procedures in CMake..."?

> +
> +Autoconf has supported C99 compilers since at least version 2.69 in
> +its generic, core probes.  (Specific functionality probes may have
> +issues addressed in more recent versions.)  Versions before 2.69 may
> +have generic probes (for example for standard C support) that rely on
> +C features that were removed in 1999 and thus fail with GCC 14.

"...removed in C99..."? As opposed to compilers removing them in 1999?

> +Sources that cannot be ported to 

Re: [PATCH] Notes on the warnings-as-errors change in GCC 14

[Gerald Pfeifer]

On Fri, 2 Feb 2024, Florian Weimer wrote:
> +Certain warnings are now errors

That's quite a nice description, thank you, Florian!

> +The initial ISO C standard and its 1999 revision removed support for

May I suggest to wrap paragraphs in ...? Not strictly necessary any 
more, now that we switched to HTML 5, though more consistent and explicit.

> [For backwards]
> +compatibility, GCC 13 and earlier compiler versions diagnosed use of
> +these features as warnings only.  Although these warnings have been
> +enabled by default for many releases, experience shows that these
> +warnings are easily ignored, resulting in difficult-to-diagnose bugs.

Can we just say "GCC 13 and earlier" (or "GCC 13 and earlier versions")?

And "...shows that they are easily ignored, resulting in difficult to 
diagnose bugs"?

> +Several GNU/Linux distributions have shared patches from their porting
> +efforts on relevant upstream mailing lists and bug trackers, but of
> +course there is a strong overlap between programs that have these
> +historic C compatibility issues and are dormant today.

At first I thought something is missing here, then I realized it may be a 
difference between German (which also is my mother tongue) and English.

One way to address it would be saying "and those that are dormant", though
I believe something like

  ...but of course many programs that exhibit these historic C 
  compatibility issues are dormant today.

> +In most cases, simply adding the missing int keyword
> +addresses the error.  For example, a flag like
> +
> +
> +  static initialized;
> +
> +
> +might turn into:
> +
> +
> +  static int initialized;
> +

How about "For example, a variable like ... becomes"?

> +If the return type of a function is omitted, the correct type to
> +add could be int or void, depending on
> +whether the function returns a value or not.

"can be"

> +In some cases, the previously implied int type
> +was not correct.

I'd omit the comma here.

>  This mostly happens in function definitions
> +that are not prototypes

Naive questions: Can definitions really be prototypes (in C)?

> +declared outside the parameter list.  Using the correct
> +type maybe required to avoid int-conversion errors (see below).

Something feels odd with this sentence?

> +
> +  void
> +  write_string (int fd, const char *s)

const char *s) as well?

> +Some programs are built with -std=c11 or
> +similar -std options that do not contain the
> +string gnu, but these programs still use POSIX or other

...but still use... (omit "these programs")

> +If undeclared functions from the same project are called and there is
> +yet no suitable shared header file, you should add a declaration to a

"no suitable shared header file yet, you can add..."

> +However, this is an obsolete C feature that will change meaning in C23
> +(declaration a function with a prototype and accepting no arguments,
> +similar to C++).

"declaration of a function", or some other change here?

> +Incorrectly spelled type names in function declarations are treated as
> +errors in more cases, under a
> +new -Wdeclaration-missing-parameter-type warning.  The
> +second line in the following example is now treated as an error
> +(previously this resulted in an unnamed warning):

What is an "unnamed" warning? Can we simply omit "unnamed" here?

> +GCC will type-check function arguments after that, potentially
> +requiring further changes.  (Previously, the function declaration was
> +treated as not having no prototype.)

That second sentence uses double negation, which logically is the same as 
just the original statement.

> +
> +By default, GCC still accepts returning an expression of
> +type void from within a function that itself
> +returns void, as a GNU extension that matches C++ rules
> +in this area.

Does the GNU extension match C++ (standard rules)?


Wee, this is a patch. All the more kudos to you.. 

I'll be looking into the second half of the patch tomorrow; feel free to 
commit the aspects covered above (after considering my review).

Cheers,

Re: [committed][gcc-wwwdocs] Add blurb about bitfield signedness on mcore

[Gerald Pfeifer]

On Tue, 19 Dec 2023, Jeff Law wrote:
> Pushed to the trunk.

Is this minor follow-up okay, adding a full stop and shortening a bit?

Gerald

diff --git a/htdocs/gcc-14/changes.html b/htdocs/gcc-14/changes.html
index 6d917535..dbc77493 100644
--- a/htdocs/gcc-14/changes.html
+++ b/htdocs/gcc-14/changes.html
@@ -504,7 +504,7 @@ a work-in-progress.
 
 
   Bitfields are now signed by default per GCC policy.  If you need 
bitfields
-to be unsigned, then use -funsigned-bitfields
+to be unsigned, use -funsigned-bitfields.
   
 
 

Re: [wwwdocs] tweak for sourceware account request alias

[Gerald Pfeifer]

On Thu, 11 Jan 2024, Frank Ch. Eigler wrote:
> diff --git a/htdocs/gitwrite.html b/htdocs/gitwrite.html
:
> -overse...@gcc.gnu.org to add access to the GCC repository.
> +admin-reque...@sourceware.org to add access to the GCC 
> repository.

Thanks, Frank. I just pushed this. 

(Sorry, I had thought this was a FYI note and missed that it wasn't live.)

Gerald

Re: [PATCH] Document refactoring of the option -fcf-protection=x.

[Gerald Pfeifer]

On Wed, 10 Jan 2024, liuhongt wrote:
> To override -fcf-protection, -fcf-protection=none needs to be added
> and then with -fcf-protection=xxx.

I'm afraid I am struggling with the English of this, but need more time to 
untangle and suggest an alternative.

For the time being I pushed the follow-up below. Note that it's
  -fcf-protection
not
  -fcf-protection
i.e.,  closes .

Gerald


commit f834612fa014a65bd0a0380d2167d9ee05626a64
Author: Gerald Pfeifer 
Date:   Fri Jan 12 13:54:52 2024 +0800

gcc-14: Fix markup around -fcf-protection

diff --git a/htdocs/gcc-14/changes.html b/htdocs/gcc-14/changes.html
index ba57abe8..9c9dfa44 100644
--- a/htdocs/gcc-14/changes.html
+++ b/htdocs/gcc-14/changes.html
@@ -41,9 +41,9 @@ a work-in-progress.
   identify all such cases in the source code and modify them.
   
   https://gcc.gnu.org/onlinedocs/gcc/Instrumentation-Options.html;>-fcf-protection=[full|branch|return|none|check]
-  is refactored, to override -fcf-protection,
-  -fcf-protection=none needs to be added and then
-  with -fcf-protection=xxx.
+  is refactored, to override -fcf-protection,
+  -fcf-protection=none needs to be added and then
+  with -fcf-protection=xxx.
   
 
 

Re: [PATCH RFC] codingconventions: add lambda guidelines

[Gerald Pfeifer]

On Thu, 11 Jan 2024, Jason Merrill wrote:
> Now in patch form!

It appears quite clear to me.

(At first I thought we need to escape the '&' in "[&] (tree arg)" as
"", but checking with validator.w3.org apparently not so in this 
specific context.)

Gerald

Re: [PATCH,doc] install: Drop hppa*-hp-hpux10, remove old notes on hppa*-hp-hpux11

[Gerald Pfeifer]

On Sun, 17 Dec 2023, John David Anglin wrote:
> The sentence about 64-bit libffi for hpux also can be removed.  I ported 
> it a few years ago.

Thanks! I made this change on top and pushed the resulting changeset.

>> (I believe it would be great if you could have a look at that part of the
>> installation docs. I'm pretty confident there is quite a bit more we can
>> garbage collect or simplify.)
> Maybe I can do it tomorrow.

If you push any changes, can you please refer to PR target/69374?
And of course if I can help, let me know.

Gerald

[PATCH,doc] install: Drop hppa*-hp-hpux10, remove old notes on hppa*-hp-hpux11

[Gerald Pfeifer]

Hi Dave,

based on our earlier e-mail, I understand we don't support hppa*-hp-hpux10 
any longer, so let's remove them from the installation docs.

On the way remove references to GCC 2.95 and 3.0 from hppa*-hp-hpux11.

Okay?


(I believe it would be great if you could have a look at that part of the 
installation docs. I'm pretty confident there is quite a bit more we can 
garbage collect or simplify.)

Gerald


gcc:
PR target/69374
* doc/install.texi (Specific) : Remove section.
(Specific) : Remove references to GCC 2.95 and 3.0.
---
 gcc/doc/install.texi | 18 --
 1 file changed, 18 deletions(-)

diff --git a/gcc/doc/install.texi b/gcc/doc/install.texi
index 84d8834a9b5..17cef5a2bae 100644
--- a/gcc/doc/install.texi
+++ b/gcc/doc/install.texi
@@ -3742,8 +3742,6 @@ information have to.
 @item
 @uref{#hppa-hp-hpux,,hppa*-hp-hpux*}
 @item
-@uref{#hppa-hp-hpux10,,hppa*-hp-hpux10}
-@item
 @uref{#hppa-hp-hpux11,,hppa*-hp-hpux11}
 @item
 @uref{#x-x-linux-gnu,,*-*-linux-gnu}
@@ -4152,27 +4150,11 @@ a list of the predefines used with each standard.
 
 More specific information to @samp{hppa*-hp-hpux*} targets follows.
 
-@html
-
-@end html
-@anchor{hppa-hp-hpux10}
-@heading hppa*-hp-hpux10
-For hpux10.20, we @emph{highly} recommend you pick up the latest sed patch
-@code{PHCO_19798} from HP@.
-
-The C++ ABI has changed incompatibly in GCC 4.0.  COMDAT subspaces are
-used for one-only code and data.  This resolves many of the previous
-problems in using C++ on this target.  However, the ABI is not compatible
-with the one implemented under HP-UX 11 using secondary definitions.
-
 @html
 
 @end html
 @anchor{hppa-hp-hpux11}
 @heading hppa*-hp-hpux11
-GCC 3.0 and up support HP-UX 11.  GCC 2.95.x is not supported and cannot
-be used to compile GCC 3.0 and up.
-
 The libffi library haven't been ported to 64-bit HP-UX@ and doesn't build.
 
 Refer to @uref{binaries.html,,binaries} for information about obtaining
-- 
2.43.0

Re: [PATCH] install: Streamline the hppa*-hp-hpux* section

[Gerald Pfeifer]

On Sat, 16 Dec 2023, John David Anglin wrote:
> I have one comment.  The only target currently supported is 
> hppa64-hp-hpux11*. While gas is required, only the HP ld works.
> 
> Otherwise, the change looks fine.

Thank you, Dave!

I updated the patch accordingly, referring to gas (not gas/binutils) and 
being explicit around the flavor of ld to use, and pushed it.

Any further comments or suggestions, let me know.

Gerald


commit da70c5b17123b7c81155ef03fb4591b71a681344
Author: Gerald Pfeifer 
Date:   Sun Dec 17 15:13:39 2023 +0800

install: Streamline the hppa*-hp-hpux* section

gcc:

PR target/69374
* doc/install.texi (Specific) : Remove a note on
GCC 4.3.
Remove details on how the HP assembler, which we document as not
working, breaks.
: Note that only the HP linker is supported.

diff --git a/gcc/doc/install.texi b/gcc/doc/install.texi
index 5ec81098d47..84d8834a9b5 100644
--- a/gcc/doc/install.texi
+++ b/gcc/doc/install.texi
@@ -4121,30 +4121,13 @@ longer a multiple of 2 bytes.
 @end html
 @anchor{hppa-hp-hpux}
 @heading hppa*-hp-hpux*
-Support for HP-UX version 9 and older was discontinued in GCC 3.4.
-
-We require using gas/binutils on all hppa platforms.  Version 2.19 or
+We require using gas on all hppa platforms.  Version 2.19 or
 later is recommended.
 
 It may be helpful to configure GCC with the
 @uref{./configure.html#with-gnu-as,,@option{--with-gnu-as}} and
 @option{--with-as=@dots{}} options to ensure that GCC can find GAS@.
 
-The HP assembler should not be used with GCC.  It is rarely tested and may
-not work.  It shouldn't be used with any languages other than C due to its
-many limitations.
-
-Specifically, @option{-g} does not work (HP-UX uses a peculiar debugging
-format which GCC does not know about).  It also inserts timestamps
-into each object file it creates, causing the 3-stage comparison test to
-fail during a bootstrap.  You should be able to continue by saying
-@samp{make all-host all-target} after getting the failure from @samp{make}.
-
-Various GCC features are not supported.  For example, it does not support weak
-symbols or alias definitions.  As a result, explicit template instantiations
-are required when using C++.  This makes it difficult if not impossible to
-build many C++ applications.
-
 There are two default scheduling models for instructions.  These are
 PROCESSOR_7100LC and PROCESSOR_8000.  They are selected from the pa-risc
 architecture specified for the target machine when configuring.
@@ -4269,9 +4252,7 @@ options, including program core dumps.  Binutils 2.14 
corrects a
 problem on the 64-bit port resulting from HP's non-standard use of
 the .init and .fini sections for array initializers and finalizers.
 
-Although the HP and GNU linkers are both supported for the
-@samp{hppa64-hp-hpux11*} target, it is strongly recommended that the
-HP linker be used for link editing on this target.
+Only the HP linker is supported for the @samp{hppa64-hp-hpux11*} target.
 
 At this time, the GNU linker does not support the creation of long
 branch stubs.  As a result, it cannot successfully link binaries

[PATCH] install: Streamline the hppa*-hp-hpux* section

[Gerald Pfeifer]

John, Jeff,

I suggest to streamline the hppa*-hp-hpux* installation instructions as 
follows. Okay?

In fact in the following sections there is even more, and more specific 
material, which would be great could you have a look at and help trim.

Gerald



>From 52149282c3a77ccda6385f06f36323c71b26491a Mon Sep 17 00:00:00 2001
From: Gerald Pfeifer 
Date: Sun, 17 Dec 2023 09:33:40 +0800
Subject: [PATCH] install: Streamline the hppa*-hp-hpux* section

gcc:

PR target/69374
* doc/install.texi (Specific) : Remove a note on
GCC 4.3.
Remove details on how the HP assembler, which we document as not
working, breaks.
---
 gcc/doc/install.texi | 17 -
 1 file changed, 17 deletions(-)

diff --git a/gcc/doc/install.texi b/gcc/doc/install.texi
index 5ec81098d47..70d46feabf6 100644
--- a/gcc/doc/install.texi
+++ b/gcc/doc/install.texi
@@ -4121,8 +4121,6 @@ longer a multiple of 2 bytes.
 @end html
 @anchor{hppa-hp-hpux}
 @heading hppa*-hp-hpux*
-Support for HP-UX version 9 and older was discontinued in GCC 3.4.
-
 We require using gas/binutils on all hppa platforms.  Version 2.19 or
 later is recommended.
 
@@ -4130,21 +4128,6 @@ It may be helpful to configure GCC with the
 @uref{./configure.html#with-gnu-as,,@option{--with-gnu-as}} and
 @option{--with-as=@dots{}} options to ensure that GCC can find GAS@.
 
-The HP assembler should not be used with GCC.  It is rarely tested and may
-not work.  It shouldn't be used with any languages other than C due to its
-many limitations.
-
-Specifically, @option{-g} does not work (HP-UX uses a peculiar debugging
-format which GCC does not know about).  It also inserts timestamps
-into each object file it creates, causing the 3-stage comparison test to
-fail during a bootstrap.  You should be able to continue by saying
-@samp{make all-host all-target} after getting the failure from @samp{make}.
-
-Various GCC features are not supported.  For example, it does not support weak
-symbols or alias definitions.  As a result, explicit template instantiations
-are required when using C++.  This makes it difficult if not impossible to
-build many C++ applications.
-
 There are two default scheduling models for instructions.  These are
 PROCESSOR_7100LC and PROCESSOR_8000.  They are selected from the pa-risc
 architecture specified for the target machine when configuring.
-- 
2.43.0

[pushed] doc: Remove references to buildstat.html

[Gerald Pfeifer]

After addressing the references to the stale information Thomas pointed 
out on our web pages, this addresses our documentation.

(I can't believe we still had a reference to SuSE, more than twenty years 
after the name changed to SUSE.)

Gerald


gcc:

PR other/69374
* doc/install.texi (Installing GCC): Remove reference to
buildstat.html.
(Testing): Ditto.
(Final install): Remove section on submitting information for
buildstat.html. Adjust the request for feedback.
---
 gcc/doc/install.texi | 53 +---
 1 file changed, 1 insertion(+), 52 deletions(-)

diff --git a/gcc/doc/install.texi b/gcc/doc/install.texi
index fffad700af7..5ec81098d47 100644
--- a/gcc/doc/install.texi
+++ b/gcc/doc/install.texi
@@ -158,10 +158,6 @@ package-specific installation instructions.
 We recommend you browse the entire generic installation instructions before
 you proceed.
 
-Lists of successful builds for released versions of GCC are
-available at @uref{https://gcc.gnu.org/buildstat.html}.
-These lists are updated as new information becomes available.
-
 The installation procedure itself is broken into five steps.
 
 @ifinfo
@@ -3286,9 +3282,6 @@ Before you install GCC, we encourage you to run the 
testsuites and to
 compare your results with results from a similar configuration that have
 been submitted to the
 @uref{https://gcc.gnu.org/ml/gcc-testresults/,,gcc-testresults mailing list}.
-Some of these archived results are linked from the build status lists
-at @uref{https://gcc.gnu.org/buildstat.html}, although not everyone who
-reports a successful build runs the testsuites and submits the results.
 This step is optional and may require you to download additional software,
 but it can give you confidence in your new GCC installation or point out
 problems before you install and start using your new GCC@.
@@ -3593,51 +3586,7 @@ Alternatively, there are prebuilt online versions of the 
manuals for
 released versions of GCC on
 @uref{https://gcc.gnu.org/onlinedocs/,,the GCC web site}.
 
-If you are bootstrapping a released version of GCC then please
-quickly review the build status page for your release, available from
-@uref{https://gcc.gnu.org/buildstat.html}.
-If your system is not listed for the version of GCC that you built,
-send a note to
-@email{gcc@@gcc.gnu.org} indicating
-that you successfully built and installed GCC@.
-Include the following information:
-
-@itemize @bullet
-@item
-Output from running @file{@var{srcdir}/config.guess}.  Do not send
-that file itself, just the one-line output from running it.
-
-@item
-The output of @samp{gcc -v} for your newly installed @command{gcc}.
-This tells us which version of GCC you built and the options you passed to
-configure.
-
-@item
-If the build was for GNU/Linux, also include:
-@itemize @bullet
-@item
-The distribution name and version (e.g., Red Hat 7.1 or Debian 2.2.3);
-this information should be available from @file{/etc/issue}.
-
-@item
-The version of the Linux kernel, available from @samp{uname --version}
-or @samp{uname -a}.
-
-@item
-The version of glibc you used; for RPM-based systems like Red Hat,
-Mandrake, and SuSE type @samp{rpm -q glibc} to get the glibc version,
-and on systems like Debian and Progeny use @samp{dpkg -l libc6}.
-@end itemize
-For other systems, you can include similar information if you think it is
-relevant.
-
-@item
-Any other information that you think would be useful to people building
-GCC on the same configuration.  The new entry in the build status list
-will include a link to the archived copy of your message.
-@end itemize
-
-We'd also like to know if the
+If you built GCC yourself we would like to know if the
 @ifnothtml
 @ref{Specific, host/target specific installation notes}
 @end ifnothtml
-- 
2.43.0

[pushed] wwwdocs: projects/cli: Update ECMA reference

[Gerald Pfeifer]

Gerald

---
 htdocs/projects/cli.html | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/htdocs/projects/cli.html b/htdocs/projects/cli.html
index 394832b6..47ddb362 100644
--- a/htdocs/projects/cli.html
+++ b/htdocs/projects/cli.html
@@ -460,7 +460,7 @@ allowing the user to provide a native implementation if 
necessary.
 [1] wwwdocs:
 
 
-ECMA, https://www.ecma-international.org/publications-and-standards/standards/ecma-335/;>
+ECMA, https://ecma-international.org/publications-and-standards/standards/ecma-335/;>
 Common Language Infrastructure (CLI), 4th edition, June 2006.
 
 
-- 
2.43.0

[pushed] doc: Update nvptx-tools Github link

[Gerald Pfeifer]

I pushed this obvious change.

Gerald


gcc:

* doc/install.texi (Specific) : Update nvptx-tools
Github link.
---
 gcc/doc/install.texi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/doc/install.texi b/gcc/doc/install.texi
index c1128d9274c..fffad700af7 100644
--- a/gcc/doc/install.texi
+++ b/gcc/doc/install.texi
@@ -4779,7 +4779,7 @@ Andes NDS32 target in big endian mode.
 Nvidia PTX target.
 
 Instead of GNU binutils, you will need to install
-@uref{https://github.com/MentorEmbedded/nvptx-tools/,,nvptx-tools}.
+@uref{https://github.com/SourceryTools/nvptx-tools,,nvptx-tools}.
 Tell GCC where to find it:
 @option{--with-build-time-tools=[install-nvptx-tools]/nvptx-none/bin}.
 
-- 
2.43.0

Re: [gcc-wwwdocs PATCH] gcc-13/14: Mention recent update for x86_64 backend

[Gerald Pfeifer]

On Fri, 8 Dec 2023, Haochen Jiang wrote:
> +++ b/htdocs/gcc-13/changes.html

> +Based on ISA extensions enabled on Alder Lake, the switch further enables
> +the AVX-IFMA, AVX-VNNI-INT8, AVX-NE-CONVERT, CMPccXADD, ENQCMD and UINTR
> +ISA extensions.

Personally I would alphabetically sort all the options, like you have 
mostly done already. Just AVX-VNNI-INT8 and AVX-NE-CONVERT are not.

(Maybe you have a reason, and in any case this should not block this 
patch.)


> +++ b/htdocs/gcc-14/changes.html
> +  New ISA extension support for Intel AVX10.1 was added.
> +  AVX10.1 intrinsics are available via the -mavx10.1 or
> +  -mavx10.1-256 compiler switch with 256 bit vector size
> +  support. 512 bit vector size support for AVX10.1 intrinsics are

We usually write 256-bit and 512-bit as adjectives, cf. 
gcc.gnu.org/codingconventions.html .

> +  Part of new feature support for Intel APX was added, including EGPR,
> +  PUSH2POP2, PPX and NDD. 

Alphabetically?

> APX features are available via the
> +  -mapxf compiler switch.

Could we say "APX is enabled via..." or "APX support is available via..."?

> +  Xeon Phi CPUs support (a.k.a. Knight Landing and Knight Mill) are 
> marked
> +as deprecated. GCC will emit a warning when using the
> +-mavx5124fmaps, -mavx5124vnniw,
> +-mavx512er, -mavx512pf,
> +-mprefetchwt1, -march=knl,
> +-march=knm, -mtune=knl and 
> -mtune=knm
> +compiler switch. The support will be removed in GCC 15.
> +  

I believe "or" instead of "and" will be clearer.

And "compiler switches" (plural).

And just "Support" in the last sentence.


Thanks for submitting these! No need for further review before committing
(a minor variation).

Gerald

RE: [PATCH] [gcc-wwwdocs]gcc-13/14: Mention Intel new ISA and march support

[Gerald Pfeifer]

On Mon, 27 Nov 2023, Jiang, Haochen wrote:
>> How about changing this to use "and", as in
>>   "The switch enables the AMX-FP16, PREFETCHI ISA extensions."
>> ?
> Ok for me.

Done and pushed thusly.

Gerald


commit 617a25d7d89a9cce121e85b693eed1ee3f94354b
Author: Gerald Pfeifer 
Date:   Wed Dec 13 13:43:39 2023 +0800

gcc-13: Refine noteo on -march=graniterapids

diff --git a/htdocs/gcc-13/changes.html b/htdocs/gcc-13/changes.html
index 8ef3d639..ee6383a0 100644
--- a/htdocs/gcc-13/changes.html
+++ b/htdocs/gcc-13/changes.html
@@ -593,7 +593,7 @@ You may also want to check out our
   
   GCC now supports the Intel CPU named Granite Rapids through
 -march=graniterapids.
-The switch enables the AMX-FP16, PREFETCHI ISA extensions.
+The switch enables the AMX-FP16 and PREFETCHI ISA extensions.
   
   GCC now supports the Intel CPU named Granite Rapids D through
 -march=graniterapids-d.

[pushed] wwwdocs: benchmarks: Remove http://annwm.lbl.gov/bench/

[Gerald Pfeifer]

This has been unreachable for months (at least).

If any of you is aware of some other link to add to
https://gcc.gnu.org/benchmarks/ please let me know.

Gerald
---
 htdocs/benchmarks/index.html | 7 ---
 1 file changed, 7 deletions(-)

diff --git a/htdocs/benchmarks/index.html b/htdocs/benchmarks/index.html
index 6ccee355..ee3a2161 100644
--- a/htdocs/benchmarks/index.html
+++ b/htdocs/benchmarks/index.html
@@ -47,13 +47,6 @@ Environment (CSiBE), along with the testbed and 
measurement scripts.
 
 Related benchmarks and scripts
 
-
-Charles Leggett runs several benchmarks (Bench++, Haney, Stepanov, OOPACK)
-comparing various versions of GCC and KAI KCC with several optimization
-levels.  Results can be found at http://annwm.lbl.gov/bench/;>
-http://annwm.lbl.gov/bench/.
-
-
 
 SUSE runs various other C++ benchmarks and Polyhedron.
 Results can be found at https://gcc.opensuse.org;
-- 
2.43.0

[pushed] wwwdocs: conduct: Change further creativecommons.org links to https

[Gerald Pfeifer]

This feels a bit lick whack-a-mole to me, though I am hopefull to now have 
caught and covered all cases where your CoC pages link to addresses that 
permanently redirect.

Famous last words. :-)

(The redirect work, avoiding them primarily helps us to find "odd" cases.
The extra turnaround should be hardly noticable for most.)

Gerald

---
 htdocs/conduct-faq.html  | 2 +-
 htdocs/conduct-report.html   | 2 +-
 htdocs/conduct-response.html | 2 +-
 htdocs/conduct.html  | 2 +-
 4 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/htdocs/conduct-faq.html b/htdocs/conduct-faq.html
index 181a7674..ffa7bd20 100644
--- a/htdocs/conduct-faq.html
+++ b/htdocs/conduct-faq.html
@@ -63,7 +63,7 @@ your question either,
 email mailto:cond...@gcc.gnu.org;>cond...@gcc.gnu.org with any
 additional questions or feedback.
 
-http://creativecommons.org/licenses/by-sa/4.0/;>
+https://creativecommons.org/licenses/by-sa/4.0/;>
 https://licensebuttons.net/l/by-sa/4.0/88x31.png;>
 This work is licensed under a
diff --git a/htdocs/conduct-report.html b/htdocs/conduct-report.html
index 139cd6c7..097309ae 100644
--- a/htdocs/conduct-report.html
+++ b/htdocs/conduct-report.html
@@ -113,7 +113,7 @@ directly to another member, or to a member of the Steering 
Committee.
 of the committee's decision. To make such a request, contact a member of the
 Steering Committee with your request and motivation.
 
-http://creativecommons.org/licenses/by-sa/4.0/;>
+https://creativecommons.org/licenses/by-sa/4.0/;>
 https://licensebuttons.net/l/by-sa/4.0/88x31.png;>
 This work is licensed under a
diff --git a/htdocs/conduct-response.html b/htdocs/conduct-response.html
index d646b2e7..fb2c26f3 100644
--- a/htdocs/conduct-response.html
+++ b/htdocs/conduct-response.html
@@ -132,7 +132,7 @@ excluded from the response process. For these cases, anyone 
can make a report
 directly to any of the committee members, as documented in the reporting
 guidelines.
 
-http://creativecommons.org/licenses/by-sa/4.0/;>
+https://creativecommons.org/licenses/by-sa/4.0/;>
 https://licensebuttons.net/l/by-sa/4.0/88x31.png;>
 This work is licensed under a
diff --git a/htdocs/conduct.html b/htdocs/conduct.html
index 2e7628af..a4cd186f 100644
--- a/htdocs/conduct.html
+++ b/htdocs/conduct.html
@@ -114,7 +114,7 @@ email mailto:cond...@gcc.gnu.org;>cond...@gcc.gnu.org.
 that doesn't answer your questions, feel free
 to mailto:cond...@gcc.gnu.org;>contact us.
 
-http://creativecommons.org/licenses/by-sa/4.0/;>
+https://creativecommons.org/licenses/by-sa/4.0/;>
 https://licensebuttons.net/l/by-sa/4.0/88x31.png;>
 This work is licensed under a
-- 
2.43.0

Re: [wwwdocs][patch][OpenACC] gcc-14/changes.html: OpenACC - mention support for first 2.7 features

[Gerald Pfeifer]

On Fri, 24 Nov 2023, Tobias Burnus wrote:
> Comments before I commit it?

+  https://gcc.gnu.org/wiki/OpenACC;>OpenACC
+OpenACC 2.7: The self clause was added to be used on
+  compute constructs and the default clause for data
+  constructs.
+  
+  

Where does that  come from? I'm afraid this won't validate/render 
properly.

Gerald

[pushed] wwwdocs: reading: Update the MicroBlaze section

[Gerald Pfeifer]

MicroBlaze is now with AMD, spelt MicroBlaze not MicroBlace, and the
docs have a new address.
---
 htdocs/readings.html | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/htdocs/readings.html b/htdocs/readings.html
index 2e320945..e4e68909 100644
--- a/htdocs/readings.html
+++ b/htdocs/readings.html
@@ -192,9 +192,9 @@ names.
SID includes a MeP simulator.
  
 
- MicroBlace
-   Manufacturer: Xilinx
-   https://www.xilinx.com/htmldocs/xilinx11/mb_ref_guide.pdf;>
+ MicroBlaze
+   Manufacturer: AMD
+   https://docs.xilinx.com/v/u/en-US/ug984-vivado-microblaze-ref;>
  MicroBlaze Processor Reference Guide
GDB includes a simulator for an earlier version of the processor.
  
-- 
2.42.1

[pushed] wwwdocs: gcc-13: Refer to GCC (instead of gcc)

[Gerald Pfeifer]

Refer to the overall project as GCC.

Pushed.

Gerald
---
 htdocs/gcc-13/porting_to.html | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/htdocs/gcc-13/porting_to.html b/htdocs/gcc-13/porting_to.html
index db0bf2fa..c727d66f 100644
--- a/htdocs/gcc-13/porting_to.html
+++ b/htdocs/gcc-13/porting_to.html
@@ -73,7 +73,7 @@ may change behavior or fail to compile in C++23.  For 
example:
 implicit move, whereby the compiler does two separate overload resolutions:
 one treating the operand as an rvalue, and then (if that resolution fails)
 another one treating the operand as an lvalue.  In the standard this was
-introduced in C++11 and implemented in gcc in
+introduced in C++11 and implemented in GCC in
 https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=4ce8c5dea53d80736b9c0ba6faa7430ed65ed365;>
 r251035.  In
 https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=1722e2013f05f1f1f99379dbaa0c0df356da731f;>
-- 
2.42.1

Re: c: tree: target: C2x (...) function prototypes and va_start relaxation

[Gerald Pfeifer]

On Fri, 21 Oct 2022, Joseph Myers wrote:
> C2x allows function prototypes to be given as (...), a prototype
> meaning a variable-argument function with no named arguments.

I noticed this did not make it into gcc-13/changes.html ? Was that 
intentional?

Gerald

[pushed] doc: Complete and sort the list of front ends

[Gerald Pfeifer]

gcc:

PR other/69374
* doc/install.texi (Downloading the source): Sort the list of
front ends and add D, Go, and Modula-2.
---
 gcc/doc/install.texi | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/gcc/doc/install.texi b/gcc/doc/install.texi
index 9a5a7b5bb7d..c1ccb8ba02d 100644
--- a/gcc/doc/install.texi
+++ b/gcc/doc/install.texi
@@ -628,9 +628,9 @@ HTTPS as tarballs compressed with @command{gzip} or 
@command{bzip2}.
 Please refer to the @uref{https://gcc.gnu.org/releases.html,,releases web page}
 for information on how to obtain GCC@.
 
-The source distribution includes the C, C++, Objective-C, Fortran,
-and Ada (in the case of GCC 3.1 and later) compilers, as well as
-runtime libraries for C++, Objective-C, and Fortran.
+The source distribution includes the Ada, C, C++, Objective-C, D (GCC 9
+and later), Fortran, Go, and Modula-2 (GCC 13 and later) compilers, as
+well as runtime libraries for C++, Objective-C, and Fortran.
 For previous versions these were downloadable as separate components such
 as the core GCC distribution, which included the C language front end and
 shared components, and language-specific distributions including the
-- 
2.42.1

[pushed] doc: Remove obsolete notes on GCC 4.x on FreeBSD

[Gerald Pfeifer]

FreeBSD 6 and 7 have been end of life for years as have been GCC 4.x
releases, so no point in detailing specifics of changes around those.

gcc:

PR target/69374
* doc/install.texi (Specific) <*-*-freebsd*>: Remove older
contents referencing GCC 4.x.
---
 gcc/doc/install.texi | 8 
 1 file changed, 8 deletions(-)

diff --git a/gcc/doc/install.texi b/gcc/doc/install.texi
index b515cd1469f..9a5a7b5bb7d 100644
--- a/gcc/doc/install.texi
+++ b/gcc/doc/install.texi
@@ -4126,14 +4126,6 @@ This configuration is intended for embedded systems.
 @end html
 @anchor{x-x-freebsd}
 @heading *-*-freebsd*
-In order to better utilize FreeBSD base system functionality and match
-the configuration of the system compiler, GCC 4.5 and above as well as
-GCC 4.4 past 2010-06-20 leverage SSP support in libc (which is present
-on FreeBSD 7 or later) and the use of @code{__cxa_atexit} by default
-(on FreeBSD 6 or later).  The use of @code{dl_iterate_phdr} inside
-@file{libgcc_s.so.1} and boehm-gc (on FreeBSD 7 or later) is enabled
-by GCC 4.5 and above.
-
 We support FreeBSD using the ELF file format with DWARF 2 debugging
 for all CPU architectures.  There are
 no known issues with mixing object files and libraries with different
-- 
2.42.1

Re: [PATCH] [gcc-wwwdocs]gcc-13/14: Mention Intel new ISA and march support

[Gerald Pfeifer]

On Mon, 17 Jul 2023, Haochen Jiang via Gcc-patches wrote:
>GCC now supports the Intel CPU named Granite Rapids through
>  -march=graniterapids.
> +The switch enables the AMX-FP16, PREFETCHI ISA extensions.

Do I understand correclty that it enables AMX-FP16 and PREFETCHI?

How about changing this to use "and", as in
  "The switch enables the AMX-FP16, PREFETCHI ISA extensions."
?

Let me know, and I can make the change.

Gerald

Re: [patch][GCN] install.texi: Update GCN entry - @uref and LLVM version remark

[Gerald Pfeifer]

On Fri, 24 Nov 2023, Tobias Burnus wrote:
> Stumbled over this.

Same here. :-)

> Comments?

Thank you for fixing this.

Gerald

[pushed] doc: Update ISO C++ reference

[Gerald Pfeifer]

http->https it is, once again.

Gerald


gcc:

* doc/standards.texi (Standards): Update ISO C++ reference.
---
 gcc/doc/standards.texi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/doc/standards.texi b/gcc/doc/standards.texi
index 6eebb9426f3..4b18fa91289 100644
--- a/gcc/doc/standards.texi
+++ b/gcc/doc/standards.texi
@@ -240,7 +240,7 @@ new specification.  For further details see
 To select this standard in GCC, use the option @option{-std=c++20}.
 
 More information about the C++ standards is available on the ISO C++
-committee's web site at @uref{http://www.open-std.org/@/jtc1/@/sc22/@/wg21/}.
+committee's web site at @uref{https://www.open-std.org/@/jtc1/@/sc22/@/wg21/}.
 
 To obtain all the diagnostics required by any of the standard versions
 described above you should specify @option{-pedantic}
-- 
2.42.1

[pushed] wwwdocs: readings: Update OpenPOWER link

[Gerald Pfeifer]

This is the original patch and a follow-up to fix an embarrassing markup 
mistake.

Gerald


commit 17418f262b17680a07a4493631aa0743b5fe9780
Author: Gerald Pfeifer 
Date:   Fri Nov 24 09:33:26 2023 +0100

readings: Update OpenPOWER link

The original link now redirects to a very generic page; refer to the
OpenPOWER Foundation instead.

diff --git a/htdocs/readings.html b/htdocs/readings.html
index 26f2af7a..90ad35d9 100644
--- a/htdocs/readings.html
+++ b/htdocs/readings.html
@@ -269,7 +269,7 @@ names.
  
  rs6000 (powerpc, powerpcle)
   Manufacturer: IBM, Motorola
-  https://www.ibm.com/systems/power/openpower/;>Power ISA
+  https://openpowerfoundation.org>OpenPOWER Foundation
   https://openpowerfoundation.org/?resource_lib=64-bit-elf-v2-abi-specification-power-architecture;>64-Bit
 ELF V2 ABI - OpenPOWER ABI
   https://www.ibm.com/docs/en/ssw_aix_72/assembler/assembler_pdf.pdf;>AIX 
7.2 Assembler Language Reference
  

commit ed16b71d535241fab09e85991dbaf7896524c72e
Author: Gerald Pfeifer 
Date:   Sat Nov 25 10:45:23 2023 +0100

readings: Fix markup around OpenPOWER

diff --git a/htdocs/readings.html b/htdocs/readings.html
index 90ad35d9..2e320945 100644
--- a/htdocs/readings.html
+++ b/htdocs/readings.html
@@ -269,7 +269,7 @@ names.
  
  rs6000 (powerpc, powerpcle)
   Manufacturer: IBM, Motorola
-  https://openpowerfoundation.org>OpenPOWER Foundation
+  https://openpowerfoundation.org;>OpenPOWER Foundation
   https://openpowerfoundation.org/?resource_lib=64-bit-elf-v2-abi-specification-power-architecture;>64-Bit
 ELF V2 ABI - OpenPOWER ABI
   https://www.ibm.com/docs/en/ssw_aix_72/assembler/assembler_pdf.pdf;>AIX 
7.2 Assembler Language Reference
  

Re: [wwwdocs][patch][OpenMP] gcc-14/changes.html + projects/gomp/: OpenMP update

[Gerald Pfeifer]

On Fri, 24 Nov 2023, Tobias Burnus wrote:
> While I expect more changes, I want to cleanup my stashed changes.

Good approach!

+  The destory now optionally accepts the depend object as
+  argument.

Is "depend object" a well known technical term in that context? And is it 
"the depend object" or "a depend object"?

Gerald

Re: [wwwdocs][patch][GCN] gcc-14/changes.html: GCN - Mention improvements due to VGPR register use

[Gerald Pfeifer]

On Fri, 24 Nov 2023, Tobias Burnus wrote:
> As in a set of benchmarks, an geometric-mean improvement of 9% (noise to 
> 25%) was found, I think we should mention this improvement proudly.

Definitely!

> Comments?

The ", hence," broke my reading flow; maybe simply omit it? Either way, 
okay.

Gerald

Re: [pushed] wwwdocs: *: Remove unused buildstat pages

[Gerald Pfeifer]

On Mon, 20 Nov 2023, Thomas Schwinge wrote:
>> For GCC 9 to GCC 13 the per-release series buildstat pages have not
>> been populated at all, so remove them and reference from the respective
>> main release pages.
> ACK; I had recently run into such an empty page, and wanted to suggest
> the same.
> 
> We still need to update the docs some more.  Do we just remove all
> references (and related text), and/or refer to the gcc-testresults
> mailing list?

The libstdc++ docs refer to gcc-results and I'll see to add this to the 
web pages where applicable.

> In wwwdocs:
> 
> htdocs/branching.html:Add buildstat.html and update the 
> toplevel
> htdocs/branching.html:buildstat.html accordingly.
> 
> htdocs/faq.html:Reports of successful builds
> htdocs/faq.html-for several versions of GCC are also available at the web 
> site.
> 
> htdocs/releasing.html-For a new major release, ensure that the build 
> status page is present
> htdocs/releasing.html:and add a link from the main 
> buildstat.html page.

I have taken care of all these and will look into gcc/doc/install.texi in 
the coming days.

Thanks for bringing this up!

Gerald

[pushed] wwwdocs: conduct: Use licensebuttons.net

[Gerald Pfeifer]

i.creativecommons.org now has a permanent redirect for the images
we use to licensebuttons.net, so follow that.

Pushed.

Gerald
---
 htdocs/conduct-faq.html  | 3 ++-
 htdocs/conduct-report.html   | 3 ++-
 htdocs/conduct-response.html | 3 ++-
 htdocs/conduct.html  | 3 ++-
 4 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/htdocs/conduct-faq.html b/htdocs/conduct-faq.html
index 06f579b9..181a7674 100644
--- a/htdocs/conduct-faq.html
+++ b/htdocs/conduct-faq.html
@@ -64,7 +64,8 @@ email mailto:cond...@gcc.gnu.org;>cond...@gcc.gnu.org with any
 additional questions or feedback.
 
 http://creativecommons.org/licenses/by-sa/4.0/;>
-https://i.creativecommons.org/l/by-sa/4.0/88x31.png;>
+https://licensebuttons.net/l/by-sa/4.0/88x31.png;>
 This work is licensed under a
 https://creativecommons.org/licenses/by-sa/4.0/;>
 Creative Commons Attribution-ShareAlike 4.0 International License.
diff --git a/htdocs/conduct-report.html b/htdocs/conduct-report.html
index 1913185b..139cd6c7 100644
--- a/htdocs/conduct-report.html
+++ b/htdocs/conduct-report.html
@@ -114,7 +114,8 @@ of the committee's decision. To make such a request, 
contact a member of the
 Steering Committee with your request and motivation.
 
 http://creativecommons.org/licenses/by-sa/4.0/;>
-https://i.creativecommons.org/l/by-sa/4.0/88x31.png;>
+https://licensebuttons.net/l/by-sa/4.0/88x31.png;>
 This work is licensed under a
 https://creativecommons.org/licenses/by-sa/4.0/;>
 Creative Commons Attribution-ShareAlike 4.0 International License.
diff --git a/htdocs/conduct-response.html b/htdocs/conduct-response.html
index 42509828..d646b2e7 100644
--- a/htdocs/conduct-response.html
+++ b/htdocs/conduct-response.html
@@ -133,7 +133,8 @@ directly to any of the committee members, as documented in 
the reporting
 guidelines.
 
 http://creativecommons.org/licenses/by-sa/4.0/;>
-https://i.creativecommons.org/l/by-sa/4.0/88x31.png;>
+https://licensebuttons.net/l/by-sa/4.0/88x31.png;>
 This work is licensed under a
 https://creativecommons.org/licenses/by-sa/4.0/;>
 Creative Commons Attribution-ShareAlike 4.0 International License.
diff --git a/htdocs/conduct.html b/htdocs/conduct.html
index e04188de..2e7628af 100644
--- a/htdocs/conduct.html
+++ b/htdocs/conduct.html
@@ -115,7 +115,8 @@ that doesn't answer your questions, feel free
 to mailto:cond...@gcc.gnu.org;>contact us.
 
 http://creativecommons.org/licenses/by-sa/4.0/;>
-https://i.creativecommons.org/l/by-sa/4.0/88x31.png;>
+https://licensebuttons.net/l/by-sa/4.0/88x31.png;>
 This work is licensed under a
 https://creativecommons.org/licenses/by-sa/4.0/;>
 Creative Commons Attribution-ShareAlike 4.0 International License.
-- 
2.42.1

[pushed] wwwdocs: faq: Refer to gcc-testresults instead of buildstat.html

[Gerald Pfeifer]

This is the last obsolete reference to buildstat.html shared by Thomas 
and per my own `grep -r`.

Pushed.

Gerald

---
 htdocs/faq.html | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/htdocs/faq.html b/htdocs/faq.html
index 203661dc..5c713a70 100644
--- a/htdocs/faq.html
+++ b/htdocs/faq.html
@@ -99,8 +99,9 @@ about known problems with installing or using GCC on 
particular platforms.
 These are included in the sources for a release in INSTALL/specific.html,
 and the https://gcc.gnu.org/install/specific.html;>latest version
 is always available at the GCC web site.
-Reports of successful builds
-for several versions of GCC are also available at the web site.
+There you also find
+https://gcc.gnu.org/pipermail/gcc-testresults/;>reports around
+successful builds.
 
 
 Installation
-- 
2.42.1

[pushed] wwwdocs: branching: No longer refer to buildstat.html

[Gerald Pfeifer]

Thomas spotted this (among others) not being necessary any longer and 
kindly reported it.

Pushed.
---
 htdocs/branching.html | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/htdocs/branching.html b/htdocs/branching.html
index 0d48dce1..23ff92e8 100644
--- a/htdocs/branching.html
+++ b/htdocs/branching.html
@@ -52,9 +52,6 @@ populate it with initial copies of changes.html 
and
 based on the previous release branch to the directory corresponding to
 the newly created release branch.

-Add buildstat.html and update the toplevel
-buildstat.html accordingly.
-
 Update the toplevel index.html page to show the new active
 release branch, the current release series, and active development
 (mainline).  Update the version and development stage for mainline.
-- 
2.42.1

[pushed] wwwdocs: releasing: No longer refer to buildstat.html

[Gerald Pfeifer]

That's the counterpart to the branching.html change I just made, also 
reported by Thomas.

Pushed.

Gerald
---
 htdocs/releasing.html | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/htdocs/releasing.html b/htdocs/releasing.html
index 1cd56f72..c7365e64 100644
--- a/htdocs/releasing.html
+++ b/htdocs/releasing.html
@@ -85,9 +85,6 @@ web pages.
 Update the version numbers of the current and future releases on
 the main web page, and add a proper news item there as well.
 
-For a new major release, ensure that the build status page is present
-and add a link from the main buildstat.html page.
-
 Generate online documentation for the new release with
 update_web_docs_git.  The appropriate command to run (as gccadmin)
 to generate the documentation would be scripts/update_web_docs_git
-- 
2.42.1

Re: [committed] libstdc++: Minor update to installation docs

[Gerald Pfeifer]

On Mon, 18 Sep 2023, Jonathan Wakely via Gcc-patches wrote:
> @@ -103,8 +103,10 @@ ln -s libiconv-1.16 libiconv
>   
> If GCC 3.1.0 or later on is being used on GNU/Linux, an attempt
> will be made to use "C" library functionality necessary for
> -   C++ named locale support.  For GCC 4.6.0 and later, this
> -   means that glibc 2.3 or later is required.
> +   C++ named locale support, e.g. the newlocale
> +   and uselocale functions.
> +   For GCC 4.6.0 and later,
> +   this means that glibc 2.3 or later is required.

Do we still need to provide those details on GCC 3.1+ and GCC 4.6+?

Would it make sense to simply require glibc 2.3 (or higher)?

Gerald

Re: [PATCH htdocs v3] bugs: Mention -D_GLIBCXX_ASSERTIONS and -D_GLIBCXX_DEBUG

[Gerald Pfeifer]

On Thu, 26 Oct 2023, Sam James wrote:
> These options both enabled more checking within the C++ standard library 
> and can expose errors in submitted code.

This is a good addition, thank you! I was going to approve/push, but it's 
probably better for Jonathan to give the final okay.

Just one question:

> +... If either of these fail, this is a strong indicator
> +of an error in your code.

What does "fails" mean in this context? Are we looking at build failures?
Run-time failures?

Gerald

Re: [PATCH] wwwdocs: gcc-14: mark amdgcn fiji deprecated

[Gerald Pfeifer]

Hi Andrew,

On Fri, 20 Oct 2023, Andrew Stubbs wrote:
>>  Additionally, I wonder whether "Fiji" should be changed to "Fiji
>> (gfx803)" in the first line and whether the  "," should be removed in
>> "The ... configuration ... , and no longer includes".
> Fair enough, how's this version? (I like the comma, even if it is optional.)

it's definitely fine. I do have a recommendation and a question, though 
feel free to go about them as you prefer.

+  The default device architecture is now gfx900 (Vega).

How about starting with this as the first sub-item, as a "positive", 
then follow with the deprecation?

+
+  
+The Fiji (gfx803) device support is now deprecated and will be removed from

Could this be "Fiji (gfx803) device support" without the article?

Gerald

[pushed] wwwdocs: buildstat: Don't reference buildstats we no longer carry

[Gerald Pfeifer]

Having just removed the buildstats pages for GCC 9 to GCC 13 also
drop references from this main buildstats overview.

Pushed.

Gerald
---
 htdocs/buildstat.html | 8 ++--
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/htdocs/buildstat.html b/htdocs/buildstat.html
index cb27a979..08c9c2b7 100644
--- a/htdocs/buildstat.html
+++ b/htdocs/buildstat.html
@@ -10,14 +10,10 @@
 
 Build status for GCC
 
-These pages summarize build reports for GCC.
+These pages summarize build reports we gathered for older releases
+of GCC.
 
 
-GCC 13.x
-GCC 12.x
-GCC 11.x
-GCC 10.x
-GCC 9.x
 GCC 8.x
 GCC 7.x
 GCC 6.x
-- 
2.42.0

[pushed] wwwdocs: *: Remove unused buildstat pages

[Gerald Pfeifer]

[ Release managers, heads-up for when you branch future releases! ]

For GCC 9 to GCC 13 the per-release series buildstat pages have not
been populated at all, so remove them and reference from the respective
main release pages.

Pushed.
Gerald
---
 htdocs/gcc-10/buildstat.html | 27 ---
 htdocs/gcc-10/index.html |  3 ---
 htdocs/gcc-11/buildstat.html | 27 ---
 htdocs/gcc-11/index.html |  3 ---
 htdocs/gcc-12/buildstat.html | 27 ---
 htdocs/gcc-12/index.html |  3 ---
 htdocs/gcc-13/buildstat.html | 27 ---
 htdocs/gcc-13/index.html |  3 ---
 htdocs/gcc-9/buildstat.html  | 27 ---
 htdocs/gcc-9/index.html  |  3 ---
 10 files changed, 150 deletions(-)
 delete mode 100644 htdocs/gcc-10/buildstat.html
 delete mode 100644 htdocs/gcc-11/buildstat.html
 delete mode 100644 htdocs/gcc-12/buildstat.html
 delete mode 100644 htdocs/gcc-13/buildstat.html
 delete mode 100644 htdocs/gcc-9/buildstat.html

diff --git a/htdocs/gcc-10/buildstat.html b/htdocs/gcc-10/buildstat.html
deleted file mode 100644
index 5d18742e..
--- a/htdocs/gcc-10/buildstat.html
+++ /dev/null
@@ -1,27 +0,0 @@
-
-
-
-
-
-Build status for GCC 10
-https://gcc.gnu.org/gcc.css;>
-
-
-
-Build status for GCC 10
-
-This list summarizes build reports for GCC 10.x, with links to the
-archived mail messages that reported the builds and to test result
-summaries.
-
-Instructions for running the test suite and for submitting test results
-are part of
-http://gcc.gnu.org/install/test.html;>
-Installing GCC: Testing.
-Instructions for reporting a successful make bootstrap,
-including a list of information to include in such a report, are part of
-http://gcc.gnu.org/install/finalinstall.html;>
-Installing GCC: Final Installation.
-
-
-
diff --git a/htdocs/gcc-10/index.html b/htdocs/gcc-10/index.html
index a9547d18..5fb1e02e 100644
--- a/htdocs/gcc-10/index.html
+++ b/htdocs/gcc-10/index.html
@@ -63,9 +63,6 @@ GCC 10.4 relative to previous releases of GCC.
 supports several other languages aside from C, it now stands for the
 GNU Compiler Collection.
 
-A list of successful builds is updated
-as new information becomes available.
-
 The GCC developers would like to thank the numerous people that have
 contributed new features, improvements, bug fixes, and other changes as
 well as test results to GCC.
diff --git a/htdocs/gcc-11/buildstat.html b/htdocs/gcc-11/buildstat.html
deleted file mode 100644
index c86238c6..
--- a/htdocs/gcc-11/buildstat.html
+++ /dev/null
@@ -1,27 +0,0 @@
-
-
-
-
-
-Build status for GCC 11
-https://gcc.gnu.org/gcc.css;>
-
-
-
-Build status for GCC 11
-
-This list summarizes build reports for GCC 11.x, with links to the
-archived mail messages that reported the builds and to test result
-summaries.
-
-Instructions for running the test suite and for submitting test results
-are part of
-http://gcc.gnu.org/install/test.html;>
-Installing GCC: Testing.
-Instructions for reporting a successful make bootstrap,
-including a list of information to include in such a report, are part of
-http://gcc.gnu.org/install/finalinstall.html;>
-Installing GCC: Final Installation.
-
-
-
diff --git a/htdocs/gcc-11/index.html b/htdocs/gcc-11/index.html
index 7cd96f7e..bb41c492 100644
--- a/htdocs/gcc-11/index.html
+++ b/htdocs/gcc-11/index.html
@@ -54,9 +54,6 @@ GCC 11.3 relative to previous releases of GCC.
 supports several other languages aside from C, it now stands for the
 GNU Compiler Collection.
 
-A list of successful builds is updated
-as new information becomes available.
-
 The GCC developers would like to thank the numerous people that have
 contributed new features, improvements, bug fixes, and other changes as
 well as test results to GCC.
diff --git a/htdocs/gcc-12/buildstat.html b/htdocs/gcc-12/buildstat.html
deleted file mode 100644
index e066026f..
--- a/htdocs/gcc-12/buildstat.html
+++ /dev/null
@@ -1,27 +0,0 @@
-
-
-
-
-
-Build status for GCC 12
-https://gcc.gnu.org/gcc.css;>
-
-
-
-Build status for GCC 12
-
-This list summarizes build reports for GCC 12.x, with links to the
-archived mail messages that reported the builds and to test result
-summaries.
-
-Instructions for running the test suite and for submitting test results
-are part of
-http://gcc.gnu.org/install/test.html;>
-Installing GCC: Testing.
-Instructions for reporting a successful make bootstrap,
-including a list of information to include in such a report, are part of
-http://gcc.gnu.org/install/finalinstall.html;>
-Installing GCC: Final Installation.
-
-
-
diff --git a/htdocs/gcc-12/index.html b/htdocs/gcc-12/index.html
index f8c589e8..a76ef1dc 100644
--- a/htdocs/gcc-12/index.html
+++ b/htdocs/gcc-12/index.html
@@ -48,9 +48,6 @@ GCC 12.2 relative to previous releases of GCC.
 supports several other languages aside from C, it now stands for the
 GNU Compiler Collection.
 
-A list of successful builds is updated
-as new 

[pushed] wwwdocs: gcc-9: Editorial changes to porting_to.html

[Gerald Pfeifer]

Of course GCC 9 is not exactly fresh, though since I found this in a local 
tree still worth pushing.

Pushed.

Gerald
---
 htdocs/gcc-9/porting_to.html | 31 ---
 1 file changed, 16 insertions(+), 15 deletions(-)

diff --git a/htdocs/gcc-9/porting_to.html b/htdocs/gcc-9/porting_to.html
index 796c402e..fc85dae2 100644
--- a/htdocs/gcc-9/porting_to.html
+++ b/htdocs/gcc-9/porting_to.html
@@ -64,22 +64,23 @@ and provide solutions. Let us know if you have suggestions 
for improvements!
   that const qualified variables without mutable
   member are predetermined shared, but as an exception may be specified
   in the firstprivate clause.  OpenMP 4.0 dropped this rule,
-  but in the hope that the incompatible change will be reverted GCC kept
-  implementing the previous behavior.  Now that for OpenMP 5.0 it has been
+  but in the hope that this incompatible change will be reverted GCC kept
+  the previous behavior.  Now that for OpenMP 5.0 it has been
   confirmed this is not going to change, GCC 9 started implementing the
-  OpenMP 4.0 and later behavior.  When not using default
+  OpenMP 4.0 and later behavior.  When not using a default
   clause or when using default(shared), this makes no
-  difference, but if using default(none), previously the
-  choice was not specify the const qualified variables
-  on the construct at all, or specify in firstprivate clause.
-  In GCC 9 as well as for OpenMP 4.0 compliance, those variables need
-  to be specified on constructs in which they are used, either in
-  shared or in firstprivate clause.  Specifying
-  them in firstprivate clause is one way to achieve
-  compatibility with both older GCC versions and GCC 9, another option
+  difference. When using default(none), previously the
+  choice was not to specify const qualified variables
+  on the construct at all, or specify them in the
+  firstprivate clause.
+  In GCC 9 as well as for OpenMP 4.0 compliance those variables need
+  to be specified on constructs in which they are used, either in a
+  shared or in a firstprivate clause.  Specifying
+  them in a firstprivate clause is one way to achieve
+  compatibility with both older GCC versions and GCC 9. Another option
   is to drop the default(none) clause.  In C++,
   const variables with constant initializers which are not
-  odr-used in the region, but replaced with their constant initializer
+  odr-used in the region, but replaced with their constant initializer,
   are not considered to be referenced in the region for
   default(none) purposes.
 
@@ -93,8 +94,8 @@ and provide solutions. Let us know if you have suggestions 
for improvements!
 for (int i = 0; i  a; i += b)
   ;
 // The above used to compile with GCC 8 and older, but will
-// not anymore with GCC 9.  firstprivate(a, b) clause needs
-// to be added for C, for C++ it could be just firstprivate(a)
+// not anymore with GCC 9. A firstprivate(a, b) clause needs
+// to be added for C; for C++ it could be just firstprivate(a)
 // to make it compatible with all GCC releases.
   }
   const int huge_array[1024] wwwdocs: = { ... };
@@ -104,7 +105,7 @@ and provide solutions. Let us know if you have suggestions 
for improvements!
   use (huge_array[i] wwwdocs:);
 // Similarly, this used to compile with GCC 8 and older and
 // will not anymore.  Adding firstprivate(huge_array) is
-// probably undesirable here, so, either
+// probably undesirable here, so either
 // default(none) shared(huge_array) should be used and it will
 // only support GCC 9 and later, or default(none) should be
 // removed and then it will be compatible with all GCC releases
-- 
2.42.0

[pushed] wwwdocs: conduct: Link creativecommons.org via https

[Gerald Pfeifer]

Browers are starting to complain about http links, and the server
actually redirects.

On the way break really long lines.

Pushed.
Gerald
---
 htdocs/conduct-faq.html  | 4 +++-
 htdocs/conduct-report.html   | 4 +++-
 htdocs/conduct-response.html | 4 +++-
 htdocs/conduct.html  | 4 +++-
 4 files changed, 12 insertions(+), 4 deletions(-)

diff --git a/htdocs/conduct-faq.html b/htdocs/conduct-faq.html
index 5b7a82a3..9ac65fbc 100644
--- a/htdocs/conduct-faq.html
+++ b/htdocs/conduct-faq.html
@@ -64,4 +64,6 @@ email mailto:cond...@gcc.gnu.org;>cond...@gcc.gnu.org with any
 additional questions or feedback.
 
 http://creativecommons.org/licenses/by-sa/4.0/;>https://i.creativecommons.org/l/by-sa/4.0/88x31.png; />
-This work is licensed under a http://creativecommons.org/licenses/by-sa/4.0/;>Creative Commons 
Attribution-ShareAlike 4.0 International License.
+This work is licensed under a
+https://creativecommons.org/licenses/by-sa/4.0/;>
+Creative Commons Attribution-ShareAlike 4.0 International License.
diff --git a/htdocs/conduct-report.html b/htdocs/conduct-report.html
index 5f3fae90..58e4489e 100644
--- a/htdocs/conduct-report.html
+++ b/htdocs/conduct-report.html
@@ -114,7 +114,9 @@ of the committee's decision. To make such a request, 
contact a member of the
 Steering Committee with your request and motivation.
 
 http://creativecommons.org/licenses/by-sa/4.0/;>https://i.creativecommons.org/l/by-sa/4.0/88x31.png; />
-This work is licensed under a http://creativecommons.org/licenses/by-sa/4.0/;>Creative Commons 
Attribution-ShareAlike 4.0 International License.
+This work is licensed under a
+https://creativecommons.org/licenses/by-sa/4.0/;>
+Creative Commons Attribution-ShareAlike 4.0 International License.
 
 Text derived from
 the https://www.djangoproject.com/conduct/reporting/;>Django project
diff --git a/htdocs/conduct-response.html b/htdocs/conduct-response.html
index a25f6ae4..a261554d 100644
--- a/htdocs/conduct-response.html
+++ b/htdocs/conduct-response.html
@@ -133,7 +133,9 @@ directly to any of the committee members, as documented in 
the reporting
 guidelines.
 
 http://creativecommons.org/licenses/by-sa/4.0/;>https://i.creativecommons.org/l/by-sa/4.0/88x31.png; />
-This work is licensed under a http://creativecommons.org/licenses/by-sa/4.0/;>Creative Commons 
Attribution-ShareAlike 4.0 International License.
+This work is licensed under a
+https://creativecommons.org/licenses/by-sa/4.0/;>
+Creative Commons Attribution-ShareAlike 4.0 International License.
 
 Text derived from
 the https://www.djangoproject.com/conduct/enforcement-manual/;>Django
diff --git a/htdocs/conduct.html b/htdocs/conduct.html
index 87bd01bf..25790035 100644
--- a/htdocs/conduct.html
+++ b/htdocs/conduct.html
@@ -115,7 +115,9 @@ that doesn't answer your questions, feel free
 to mailto:cond...@gcc.gnu.org;>contact us.
 
 http://creativecommons.org/licenses/by-sa/4.0/;>https://i.creativecommons.org/l/by-sa/4.0/88x31.png; />
-This work is licensed under a http://creativecommons.org/licenses/by-sa/4.0/;>Creative Commons 
Attribution-ShareAlike 4.0 International License.
+This work is licensed under a
+https://creativecommons.org/licenses/by-sa/4.0/;>
+Creative Commons Attribution-ShareAlike 4.0 International License.
 
 Text derived from the https://www.djangoproject.com/conduct/;>Django
 project Code of Conduct, used under
-- 
2.42.0

[pushed] wwwdocs: conduct: Use instead of

[Gerald Pfeifer]

On the way break overly long lines.

Pushed.

Gerald
---
 htdocs/conduct-faq.html  | 3 ++-
 htdocs/conduct-report.html   | 3 ++-
 htdocs/conduct-response.html | 3 ++-
 htdocs/conduct.html  | 3 ++-
 4 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/htdocs/conduct-faq.html b/htdocs/conduct-faq.html
index 380e9166..5b7a82a3 100644
--- a/htdocs/conduct-faq.html
+++ b/htdocs/conduct-faq.html
@@ -63,4 +63,5 @@ your question either,
 email mailto:cond...@gcc.gnu.org;>cond...@gcc.gnu.org with any
 additional questions or feedback.
 
-http://creativecommons.org/licenses/by-sa/4.0/;>https://i.creativecommons.org/l/by-sa/4.0/88x31.png; />This work 
is licensed under a http://creativecommons.org/licenses/by-sa/4.0/;>Creative Commons 
Attribution-ShareAlike 4.0 International License.
+http://creativecommons.org/licenses/by-sa/4.0/;>https://i.creativecommons.org/l/by-sa/4.0/88x31.png; />
+This work is licensed under a http://creativecommons.org/licenses/by-sa/4.0/;>Creative Commons 
Attribution-ShareAlike 4.0 International License.
diff --git a/htdocs/conduct-report.html b/htdocs/conduct-report.html
index 87758745..5f3fae90 100644
--- a/htdocs/conduct-report.html
+++ b/htdocs/conduct-report.html
@@ -113,7 +113,8 @@ directly to another member, or to a member of the Steering 
Committee.
 of the committee's decision. To make such a request, contact a member of the
 Steering Committee with your request and motivation.
 
-http://creativecommons.org/licenses/by-sa/4.0/;>https://i.creativecommons.org/l/by-sa/4.0/88x31.png; />This work 
is licensed under a http://creativecommons.org/licenses/by-sa/4.0/;>Creative Commons 
Attribution-ShareAlike 4.0 International License.
+http://creativecommons.org/licenses/by-sa/4.0/;>https://i.creativecommons.org/l/by-sa/4.0/88x31.png; />
+This work is licensed under a http://creativecommons.org/licenses/by-sa/4.0/;>Creative Commons 
Attribution-ShareAlike 4.0 International License.
 
 Text derived from
 the https://www.djangoproject.com/conduct/reporting/;>Django project
diff --git a/htdocs/conduct-response.html b/htdocs/conduct-response.html
index c67e8b0b..a25f6ae4 100644
--- a/htdocs/conduct-response.html
+++ b/htdocs/conduct-response.html
@@ -132,7 +132,8 @@ excluded from the response process. For these cases, anyone 
can make a report
 directly to any of the committee members, as documented in the reporting
 guidelines.
 
-http://creativecommons.org/licenses/by-sa/4.0/;>https://i.creativecommons.org/l/by-sa/4.0/88x31.png; />This work 
is licensed under a http://creativecommons.org/licenses/by-sa/4.0/;>Creative Commons 
Attribution-ShareAlike 4.0 International License.
+http://creativecommons.org/licenses/by-sa/4.0/;>https://i.creativecommons.org/l/by-sa/4.0/88x31.png; />
+This work is licensed under a http://creativecommons.org/licenses/by-sa/4.0/;>Creative Commons 
Attribution-ShareAlike 4.0 International License.
 
 Text derived from
 the https://www.djangoproject.com/conduct/enforcement-manual/;>Django
diff --git a/htdocs/conduct.html b/htdocs/conduct.html
index 736e2f6d..87bd01bf 100644
--- a/htdocs/conduct.html
+++ b/htdocs/conduct.html
@@ -114,7 +114,8 @@ email mailto:cond...@gcc.gnu.org;>cond...@gcc.gnu.org.
 that doesn't answer your questions, feel free
 to mailto:cond...@gcc.gnu.org;>contact us.
 
-http://creativecommons.org/licenses/by-sa/4.0/;>https://i.creativecommons.org/l/by-sa/4.0/88x31.png; />This work 
is licensed under a http://creativecommons.org/licenses/by-sa/4.0/;>Creative Commons 
Attribution-ShareAlike 4.0 International License.
+http://creativecommons.org/licenses/by-sa/4.0/;>https://i.creativecommons.org/l/by-sa/4.0/88x31.png; />
+This work is licensed under a http://creativecommons.org/licenses/by-sa/4.0/;>Creative Commons 
Attribution-ShareAlike 4.0 International License.
 
 Text derived from the https://www.djangoproject.com/conduct/;>Django
 project Code of Conduct, used under
-- 
2.42.0

Re: gcc-patches From rewriting mailman settings (Was: [Linaro-TCWG-CI] gcc patch #75674: FAIL: 68 regressions)

[Gerald Pfeifer]

On Tue, 19 Sep 2023, Mark Wielaard wrote:
>> Although there were some positive responses (on list and on irc) it is
>> sometimes hard to know if there really is consensus for these kind of
>> infrastructure tweaks. But I believe there is at least no sustained
>> opposition to changing the gcc-patches mailman setting as proposed
>> above.
> This change is now done for gcc-patches.

Yeah, yeah, yeah. Thank you!

>> And if there are no complaints at Cauldron we could do the same for
>> the other patch lists the week after.

Sadly I missed Cauldron - have there been any complaints there?

Can you adjust the g...@gcc.gnu.org list and others @gcc.gnu.org as well?
I for one would love to see that.

Thanks,
Gerald

Re: [PATCH v6] RISC-V:Optimize the MASK opt generation

[Gerald Pfeifer]

On Mon, 2 Oct 2023, Kito Cheng wrote:
> Thanks for reporting this issue, I just realized multidimensional
> arrays are gawk extensions, could you try the attached patch to see if
> it can resolve the issue?

Yes, with that patch applied the build proceeds far beyond that point
(still running).

Thanks for the quick fix!

Gerald

Re: [PATCH v6] RISC-V:Optimize the MASK opt generation

[Gerald Pfeifer]

On Sun, 1 Oct 2023, Kito Cheng wrote:
> Committed to trunk, thanks Feng :)

Hmm, my nightly FreeBSD 12 tester now fails as follows:

  nawk -f /scratch/tmp/gerald/GCC-HEAD/gcc/opt-functions.awk \
-f /scratch/tmp/gerald/GCC-HEAD/gcc/opt-read.awk \
-f /scratch/tmp/gerald/GCC-HEAD/gcc/opth-gen.awk \
   < optionlist > tmp-options.h
  nawk: syntax error at source line 67 source file 
/scratch/tmp/gerald/GCC-HEAD/gcc/opt-read.awk
  context is
>>>other_masks[var_index][ 
<<< n_other_mask[var_index]++] = name
  nawk: illegal statement at source line 67 source file 
  /scratch/tmp/gerald/GCC-HEAD/gcc/opt-read.awk
  nawk -f /scratch/tmp/gerald/GCC-HEAD/gcc/opt-functions.awk \
-f /scratch/tmp/gerald/GCC-HEAD/gcc/opt-read.awk \
   -f /scratch/tmp/gerald/GCC-HEAD/gcc/optc-save-gen.awk \
   -v header_name="config.h system.h coretypes.h tm.h" < optionlist \
   > options-save.cc
  nawk: syntax error at source line 386 source file 
  /scratch/tmp/gerald/GCC-HEAD/gcc/opth-gen.awk
  nawk: syntax error at source line 67 source file 
  /scratch/tmp/gerald/GCC-HEAD/gcc/opt-read.awk
  context is
>>>other_masks[var_index][ 
<<< n_other_mask[var_index]++] = name
  nawk: illegal statement at source line 67 source file 
  /scratch/tmp/gerald/GCC-HEAD/gcc/opt-read.awk
  gmake[3]: *** [Makefile:2477: s-options-h] Error 2

Gerald

Re: [wwwdocs, committed] gcc-14/changes.html (OpenMP): Tweak manual-update wording

[Gerald Pfeifer]

On Mon, 25 Sep 2023, Tobias Burnus wrote:
> The 'description' words looked a bit misplaced when reading the full 
> sentence. Likewise "the libnuma" - I changed that to simply "libnuma". 
> (Alternatives would be "the libnuma library" or "the numa library".)
> 
> Hence, I fixed my own wording :-)

Looks good (for the record).

Thanks,
Gerald

[pushed] wwwdocs: conduct: Fix nested lists

[Gerald Pfeifer]

Looks like I never posted this push of mine from June 30th?

Just a little markup fix.

Gerald
---
 htdocs/conduct.html | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/htdocs/conduct.html b/htdocs/conduct.html
index 8fb62e86..da940a47 100644
--- a/htdocs/conduct.html
+++ b/htdocs/conduct.html
@@ -61,7 +61,7 @@ affect a person's ability to participate within them.
   Be careful in the words that you choose. Be kind to
   others. Do not insult or put down other participants. Harassment and other
   exclusionary behavior aren't acceptable. This includes, but is not limited
-  to:
+  to:
 
   
 Violent threats or language directed against another person.
@@ -73,6 +73,7 @@ affect a person's ability to participate within them.
 Advocating for, or encouraging, any of the above behavior.
 Repeated harassment of others. In general, if someone asks you to 
stop, then stop.
   
+  
 
   When we disagree, try to understand why. Disagreements,
   both social and technical, happen all the time and the GCC community is no
-- 
2.41.0

[pushed] wwwdocs: *: Use "back end" instead of "backend"

[Gerald Pfeifer]

Per http://gcc.gnu.org/codingconventions.html#Spelling

Pushed.

Gerald

---
 htdocs/egcs-1.0/index.html|  2 +-
 htdocs/egcs-1.1/features.html |  2 +-
 htdocs/egcs-1.1/index.html|  2 +-
 htdocs/gcc-11/changes.html|  2 +-
 htdocs/gcc-12/changes.html|  2 +-
 htdocs/gcc-2.95/features.html |  4 ++--
 htdocs/gcc-4.9/changes.html   | 11 ++-
 htdocs/gcc-5/changes.html |  4 ++--
 htdocs/news.html  |  2 +-
 9 files changed, 16 insertions(+), 15 deletions(-)

diff --git a/htdocs/egcs-1.0/index.html b/htdocs/egcs-1.0/index.html
index 4e674440..34e44931 100644
--- a/htdocs/egcs-1.0/index.html
+++ b/htdocs/egcs-1.0/index.html
@@ -148,7 +148,7 @@ serious problems in EGCS 1.0.1.
  Add missing entries to g77 lang-options.
  Fix problem with -fpedantic in the g77 compiler.
  Fix "backspace" problem with g77 on alphas.
- Fix x86 backend problem with Fortran literals and -fpic.
+ Fix x86 back end problem with Fortran literals and -fpic.
  Fix some of the problems with negative subscripts for g77 on
  alphas.
  Fixes for Fortran builds on cygwin32/mingw32.
diff --git a/htdocs/egcs-1.1/features.html b/htdocs/egcs-1.1/features.html
index b72445a7..259abd5b 100644
--- a/htdocs/egcs-1.1/features.html
+++ b/htdocs/egcs-1.1/features.html
@@ -63,7 +63,7 @@
 x86: Alignment of static store data and jump targets is per
Intel recommendations now.  Various improvements throughout the
x86 port to improve performance on Pentium processors (including
-improved epilogue sequences for Pentium chips and backend
+improved epilogue sequences for Pentium chips and back end
 improvements which should help register allocation on all x86
 variants.  Conditional move support has been fixed and enabled for
 PPro processors.
diff --git a/htdocs/egcs-1.1/index.html b/htdocs/egcs-1.1/index.html
index adeffd37..5db4e342 100644
--- a/htdocs/egcs-1.1/index.html
+++ b/htdocs/egcs-1.1/index.html
@@ -92,7 +92,7 @@ EGCS 1.1:
  Fix a few arm code generation bugs.
  Fixincludes will fix additional broken SCO OpenServer header 
  files.
- Fix a m68k backend bug which caused invalid offsets in reg+d 
+ Fix a m68k back end bug which caused invalid offsets in reg+d 
  addresses.
  Fix problems with 64bit AIX 4.3 support.
  Fix handling of long longs for varargs/stdarg functions on the 
diff --git a/htdocs/gcc-11/changes.html b/htdocs/gcc-11/changes.html
index 44389172..a00637c6 100644
--- a/htdocs/gcc-11/changes.html
+++ b/htdocs/gcc-11/changes.html
@@ -777,7 +777,7 @@ You may also want to check out our
 
   A number of new CPUs are supported through arguments to the
   -mcpu and -mtune options in both
-  the arm and aarch64 backends (GCC identifiers in parentheses):
+  the arm and aarch64 back ends (GCC identifiers in parentheses):
 
   Arm Cortex-A78 (cortex-a78).
   Arm Cortex-A78AE (cortex-a78ae).
diff --git a/htdocs/gcc-12/changes.html b/htdocs/gcc-12/changes.html
index b10f2aa4..b4e29d72 100644
--- a/htdocs/gcc-12/changes.html
+++ b/htdocs/gcc-12/changes.html
@@ -755,7 +755,7 @@ function Multiply (S1, S2 : Sign) return Sign is
 BPF
 
   Support for CO-RE (compile-once, run-everywhere) has been added
-  to the BPF backend.  CO-RE allows to compile portable BPF
+  to the BPF back end.  CO-RE allows to compile portable BPF
   programs that are able to run among different versions of the
   Linux kernel.
   
diff --git a/htdocs/gcc-2.95/features.html b/htdocs/gcc-2.95/features.html
index 0e4f6c47..98ca0dd4 100644
--- a/htdocs/gcc-2.95/features.html
+++ b/htdocs/gcc-2.95/features.html
@@ -49,7 +49,7 @@
   
   New Targets and Target Specific Improvements
   
-SPARC backend rewrite.
+SPARC back end rewrite.
 -mschedule=8000 will optimize code for PA8000 class processors;
  -mpa-risc-2-0 will generate code for PA2.0 processors
 Various micro-optimizations for the ia32 port. K6 optimizations
@@ -200,7 +200,7 @@ enabled by default in future releases.  Use the option
 
Work around bug in Sun V5.0 compilers which caused bootstrap
comparison failures on SPARC targets.
-   Fix SPARC backend bug which caused aborts in final.c.
+   Fix SPARC back end bug which caused aborts in final.c.
Fix sparc-hal-solaris2* configuration fragments.
Fix bug in sparc block profiling.
Fix obscure code generation bug for the PARISC targets.
diff --git a/htdocs/gcc-4.9/changes.html b/htdocs/gcc-4.9/changes.html
index 9090c0ea..26d4843a 100644
--- a/htdocs/gcc-4.9/changes.html
+++ b/htdocs/gcc-4.9/changes.html
@@ -498,10 +498,10 @@ auto incr(T x) { return x++; }
been added. The Advanced SIMD intrinsics have also been improved.
  
   The new local register allocator (LRA) is now on by default
-   for the AArch64 backend.
+   for the AArch64 back end.
  
   The REE (Redundant extension 

[pushed] wwwdocs: gcc-12: Improve language around vectorizer and -O2

[Gerald Pfeifer]

Pushed.

Gerald
---
 htdocs/gcc-12/changes.html | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/htdocs/gcc-12/changes.html b/htdocs/gcc-12/changes.html
index 3816d06f..b10f2aa4 100644
--- a/htdocs/gcc-12/changes.html
+++ b/htdocs/gcc-12/changes.html
@@ -127,10 +127,12 @@ You may also want to check out our
 General Improvements
 
 
-  Vectorization is enabled at -O2 which is now equivalent to 
the
-  original -O2 -ftree-vectorize -fvect-cost-model=very-cheap.
-  Note that default vectorizer cost model has been changed which used to 
behave
-  as -fvect-cost-model=cheap were specified.
+  Vectorization is enabled at -O2 which is now
+  equivalent to what would have been
+  -O2 -ftree-vectorize -fvect-cost-model=very-cheap
+  in the past. Note that the default vectorizer cost model has
+  been changed; it used to behave as if
+  -fvect-cost-model=cheap had been specified.
   
   
 GCC now supports the
-- 
2.41.0

Re: [wwwdocs] projects/gomp: Update implementation status and minor fixes

[Gerald Pfeifer]

On Fri, 25 Aug 2023, Tobias Burnus wrote:
> It also fixes a couple of bugs and adds links providing more details
> for two items (a PR link as in libgomp.texi and a section in the manual).

Nice changes, thanks.

+Some are only stubs; see manual (

Re: [committed] i386: Fix grammar typo in diagnostic

[Gerald Pfeifer]

On Mon, 7 Aug 2023, Marek Polacek via Gcc-patches wrote:
>> Less obvious (to me) is whether it's correct to say "GCC V13" here. I
>> don't think we refer to a version that way anywhere else, do we?
>> 
>> Would "since GCC 13.1.0" be better?
> x86_field_alignment uses
> 
>   inform (input_location, "the alignment of %<_Atomic %T%> "
>   "fields changed in %{GCC 11.1%}",
> 
> so maybe the below should use %{GCC 13.1%}.  "GCC V13" looks unusual
> to me.

I usually say "GCC 13" when referring to a major release.

("GCC V13" definitely is very unusual.)

Gerald

[pushed] wwwdocs: gcc-4.5: Update link to GNU MPC

[Gerald Pfeifer]

---
 htdocs/gcc-4.5/changes.html | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/htdocs/gcc-4.5/changes.html b/htdocs/gcc-4.5/changes.html
index 2e8f56a7..3d645bb3 100644
--- a/htdocs/gcc-4.5/changes.html
+++ b/htdocs/gcc-4.5/changes.html
@@ -18,7 +18,7 @@
 
   
 GCC now requires the https://www.multiprecision.org/mpc/;>MPC library in order to
+href="https://www.multiprecision.org;>MPC library in order to
 build.  See the https://gcc.gnu.org/install/prerequisites.html;>prerequisites
 page for version requirements.
-- 
2.41.0

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: [pushed] wwwdocs: Add GCC Code of Conduct

[Gerald Pfeifer]

On Tue, 20 Jun 2023, Jason Merrill via Gcc-patches wrote:
> As announced on gcc@.

Here is a minor follow-up that I just pushed.

Gerald


>From f87deaa12cccb4b7398a8ec3b306cb4185aae012 Mon Sep 17 00:00:00 2001
From: Gerald Pfeifer 
Date: Fri, 30 Jun 2023 14:59:27 +0200
Subject: [PATCH] conduct: Fix nested lists

---
 htdocs/conduct.html | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/htdocs/conduct.html b/htdocs/conduct.html
index 8fb62e86..da940a47 100644
--- a/htdocs/conduct.html
+++ b/htdocs/conduct.html
@@ -61,7 +61,7 @@ affect a person's ability to participate within them.
   Be careful in the words that you choose. Be kind to
   others. Do not insult or put down other participants. Harassment and other
   exclusionary behavior aren't acceptable. This includes, but is not limited
-  to:
+  to:
 
   
 Violent threats or language directed against another person.
@@ -73,6 +73,7 @@ affect a person's ability to participate within them.
 Advocating for, or encouraging, any of the above behavior.
 Repeated harassment of others. In general, if someone asks you to 
stop, then stop.
   
+  
 
   When we disagree, try to understand why. Disagreements,
   both social and technical, happen all the time and the GCC community is no
-- 
2.41.0

[pushed] wwwdocs: gcc-14: Add list markup for C++ release notes

[Gerald Pfeifer]

List items can only appear in lists. :-)

This fixes up

  commit b38079855ead7f7e358d17bc06642d031de5e29b
  Author: Marek Polacek 
  Date:   Thu Jun 22 14:44:43 2023 -0400

C++26 P2752R3 - Static storage for braced initializers implemented

Gerald

---
 htdocs/gcc-14/changes.html | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/htdocs/gcc-14/changes.html b/htdocs/gcc-14/changes.html
index 00165740..3f797642 100644
--- a/htdocs/gcc-14/changes.html
+++ b/htdocs/gcc-14/changes.html
@@ -76,6 +76,7 @@ a work-in-progress.
 
 C++
 
+
   Several C++26 features have been implemented:
 
   https://wg21.link/P2752R3;>P2752R3, Static storage for
@@ -83,6 +84,7 @@ a work-in-progress.
   
 
   
+
 
 
 
-- 
2.41.0

Re: [wwwdocs] gcc-14/changes.htm - Offloading: -lm/-lgfortran is autolinked

[Gerald Pfeifer]

On Fri, 16 Jun 2023, Tobias Burnus wrote:
> Thomas recently improved the offload experience by avoiding to use, e.g.
> 
>   gfortran -O3 -fopenmp qcd.f90 -lblas -foffload-options="-lgfortran -lm"
> 
> as libm and libgfortran now automatically get linked as 'gfortran' links
> -lgfortran and -lm on the host (only those libraries, not others). Thus,
> the commandline now looks much more natural:
> 
>   gfortran -O3 -fopenmp qcd.f90 -lblas

Nice!

> Attached patch documents it in the release notes.
> I loved to hear comments, suggestions, improvements (or even appraisals).

Looks good to me. (Personally I would have written "the math and 
Fortran runtime libraries", which is shorter, but pretty much a matter 
of preference. IOW, keep it as is unless you like it better, too. :-)

One idea might be to show the two invocations - before and after - in the 
release notes as well, at the end of that new entry. Totally up to you, 
too.


For the benefit of the doubt: Okay, thank you!

Gerald

[pushed] wwwdocs: readings: Adjust link to Arm architectures

[Gerald Pfeifer]

arm.com does some interesting special effects with URL; hopefully this 
simplification is somewhat resilient.

Pushed.

Gerald
---
 htdocs/readings.html | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/htdocs/readings.html b/htdocs/readings.html
index 6813b84f..26f2af7a 100644
--- a/htdocs/readings.html
+++ b/htdocs/readings.html
@@ -65,7 +65,7 @@ names.
   The 64-bit execution state of the ARM Architecture, first introduced
   by the ARMv8-A architecture.
   Manufacturer: Various, by license from ARM.
-  https://developer.arm.com/architectures/cpu-architecture;>ARM 
Documentation
+  https://developer.arm.com/architectures;>ARM Documentation
  
 
  andes (nds32)
@@ -84,7 +84,7 @@ names.
  ARM
   Manufacturer: Various, by license from ARM.
   CPUs include: ARM7TDMI, and the Cortex-A, Cortex-R and Cortex-M series.
-  https://developer.arm.com/architectures/cpu-architecture;>ARM 
Documentation
+  https://developer.arm.com/architectures;>ARM Documentation
   https://developer.arm.com/documentation/ihi0036/latest/;>Application 
Binary Interface (ABI) for the ARM Architecture
  
 
-- 
2.40.1

[pushed 1/N] install.texi: Remove alpha*-*-* section

[Gerald Pfeifer]

install.texi has become a bit blown up over the years, with good potential 
to trim chaff and simplify things for our users.

This is just one step of possibly many more.

Pushed.

Gerald


gcc/ChangeLog:

* doc/install.texi (Specific): Remove de facto empty alpha*-*-*
section.
---
 gcc/doc/install.texi | 11 ---
 1 file changed, 11 deletions(-)

diff --git a/gcc/doc/install.texi b/gcc/doc/install.texi
index fa91ce1953d..fadcf5aa2ef 100644
--- a/gcc/doc/install.texi
+++ b/gcc/doc/install.texi
@@ -3633,8 +3633,6 @@ information have to.
 @item
 @uref{#aarch64-x-x,,aarch64*-*-*}
 @item
-@uref{#alpha-x-x,,alpha*-*-*}
-@item
 @uref{#amdgcn-x-amdhsa,,amdgcn-*-amdhsa}
 @item
 @uref{#amd64-x-solaris2,,amd64-*-solaris2*}
@@ -3836,15 +3834,6 @@ types of branch protections.  Conversely,
 protections by default.  This mechanism is turned off by default if neither
 of the options are given at configure time.
 
-@html
-
-@end html
-@anchor{alpha-x-x}
-@heading alpha*-*-*
-This section contains general configuration information for all
-Alpha-based platforms using ELF@.  In addition to reading this
-section, please read all other sections that match your target.
-
 @html
 
 @end html
-- 
2.40.1

[pushed] wwwdocs: preprocess: Check whether input files exist

[Gerald Pfeifer]

This has not come up in all those years since the preprocess script
usually is invoked from other scripts, notably post commit hooks. It
can, however, be invoked manually, and error handling is generally a
good thing.

Instead of
   cat: foo/bar/index.html: No such file or directory
   New file /www/gcc/htdocs/foo/bar/index.html
and an empty output file, we now get
   Input file foo/bar/index.html not found.
when invoking `preprocess foo/bar/index.html`.

Pushed.
Gerald
---
 bin/preprocess | 5 +
 1 file changed, 5 insertions(+)

diff --git a/bin/preprocess b/bin/preprocess
index c62ba457..c6d34c4b 100755
--- a/bin/preprocess
+++ b/bin/preprocess
@@ -155,6 +155,11 @@ process_file()
 # Strip possibly leading "./".
 f=`echo $1 | sed -e 's#^\./##'`
 
+if [ ! -f "$SOURCETREE/$f" ] wwwdocs:; then
+echo "Input file $f not found."
+return
+fi
+
 if [ ! -d "$DESTTREE/`dirname $f`" ] wwwdocs:; then
 echo "Creating new directory `dirname $f`."
 mkdir -p $DESTTREE/`dirname $f`
-- 
2.40.1

[pushed] libstdc++: Move lafstern.org reference to https

[Gerald Pfeifer]

Pushed.

Gerald


libstdc++-v3/ChangeLog:

* doc/xml/manual/strings.xml: Move lafstern.org reference to https.
* doc/html/manual/strings.html: Regenerate.
---
 libstdc++-v3/doc/html/manual/strings.html | 2 +-
 libstdc++-v3/doc/xml/manual/strings.xml   | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/libstdc++-v3/doc/html/manual/strings.html 
b/libstdc++-v3/doc/html/manual/strings.html
index 3441119e926..ceb09f97eac 100644
--- a/libstdc++-v3/doc/html/manual/strings.html
+++ b/libstdc++-v3/doc/html/manual/strings.html
@@ -111,7 +111,7 @@
book Exceptional C++ and on his 
website as http://www.gotw.ca/gotw/029.htm; 
target="_top">GotW 29.
See?  Told you it was easy!
  Added June 2000: The May 2000 
issue of C++
- Report contains a fascinating http://lafstern.org/matt/col2_new.pdf; target="_top"> article by
+ Report contains a fascinating https://lafstern.org/matt/col2_new.pdf; target="_top"> article by
  Matt Austern (yes, the Matt 
Austern) on why
  case-insensitive comparisons are not as easy as they seem, and
  why creating a class is the wrong 
way to go
diff --git a/libstdc++-v3/doc/xml/manual/strings.xml 
b/libstdc++-v3/doc/xml/manual/strings.xml
index e9d4c8ce347..b0dab645a2d 100644
--- a/libstdc++-v3/doc/xml/manual/strings.xml
+++ b/libstdc++-v3/doc/xml/manual/strings.xml
@@ -145,7 +145,7 @@
See?  Told you it was easy!

  Added June 2000: The May 2000 issue of C++
- Report contains a fascinating http://www.w3.org/1999/xlink; 
xlink:href="http://lafstern.org/matt/col2_new.pdf;> article by
+ Report contains a fascinating http://www.w3.org/1999/xlink; 
xlink:href="https://lafstern.org/matt/col2_new.pdf;> article by
  Matt Austern (yes, the Matt Austern) on why
  case-insensitive comparisons are not as easy as they seem, and
  why creating a class is the wrong way to go
-- 
2.40.1

[pushed] wwwdocs: onlinedocs/13.1.0: Remove last trace of XHTML

[Gerald Pfeifer]

This is how I actually noticed the situation in gcc-13/buildstat.html
(and then I mixed the two up).

Jakub, do you have some old templates somewhere maybe?

Gerald

Pushed:
---
 htdocs/onlinedocs/13.1.0/index.html | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/htdocs/onlinedocs/13.1.0/index.html 
b/htdocs/onlinedocs/13.1.0/index.html
index 7b8c3d38..2abc06ac 100644
--- a/htdocs/onlinedocs/13.1.0/index.html
+++ b/htdocs/onlinedocs/13.1.0/index.html
@@ -4,7 +4,7 @@
 
 
 GCC 13.1 manuals
-https://gcc.gnu.org/gcc.css; />
+https://gcc.gnu.org/gcc.css;>
 
 
 
-- 
2.40.1

[pushed] wwwdocs: gcc-13/buildstat: Remove trace of XHTML

[Gerald Pfeifer]

Hi Jakub,

do you recall how this snuck in? None of other other pages has had
  <..." />
instead of
  <...">
for a while. Not a biggie at all, just curious.

Pushed.


On a related note, the buildstat pages for GCC 9, 10, 11, 12, and 13
all are empty and I suggest to remove them. Any concerns?

Gerald

---
 htdocs/gcc-13/buildstat.html | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/htdocs/gcc-13/buildstat.html b/htdocs/gcc-13/buildstat.html
index fd6ee9e7..a54d0214 100644
--- a/htdocs/gcc-13/buildstat.html
+++ b/htdocs/gcc-13/buildstat.html
@@ -4,7 +4,7 @@
 
 
 Build status for GCC 13
-https://gcc.gnu.org/gcc.css; />
+https://gcc.gnu.org/gcc.css;>
 
 
 
-- 
2.40.1

Re: [PATCH] wwwdocs: Clarify experimental status of C++17 prior to GCC 9

[Gerald Pfeifer]

On Wed, 22 Mar 2023, Jonathan Wakely via Gcc-patches wrote:
> We don't currently have a single page where you can find out when
> support for a given standard became non-experimental (you have to look
> through all the gcc-X/changes.html pages to find it). I think we should
> have that info on the cxx-status.html page. This adds it for C++17, and
> we can do the same for C++20 when we declare that stable.

I'm not sure why I only noticed this today. Just a little technicality
to fix this page. 

Pushed.

Gerald


Commit a09e584729 introduced an  without corresponding .
---
 htdocs/projects/cxx-status.html | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/htdocs/projects/cxx-status.html b/htdocs/projects/cxx-status.html
index 7f59e5a2..675fbcd0 100644
--- a/htdocs/projects/cxx-status.html
+++ b/htdocs/projects/cxx-status.html
@@ -402,7 +402,7 @@
 -->
   
 
-  C++20 Support in GCC
+  C++20 Support in GCC
 
   GCC has experimental support for the latest revision of the C++
   standard, which was published in 2020.
-- 
2.40.1

[pushed] wwwdocs: onlinedocs: Fix markup

[Gerald Pfeifer]

Pushed.

Gerald

---

Commit 7c0b3155efaecf8c9bfa5192ca99acc7356bec71 for GCC 13.1 "stole" an
opening  from the existing GCC 13.2 entry.
---
 htdocs/onlinedocs/index.html | 1 +
 1 file changed, 1 insertion(+)

diff --git a/htdocs/onlinedocs/index.html b/htdocs/onlinedocs/index.html
index 421d1d0b..e72f5bfa 100644
--- a/htdocs/onlinedocs/index.html
+++ b/htdocs/onlinedocs/index.html
@@ -111,6 +111,7 @@
   
 
 
+
  GCC 12.2 manuals:
   
 https://gcc.gnu.org/onlinedocs/gcc-12.2.0/gcc/;>GCC
-- 
2.40.1

Re: [PATCH] doc: Update install.texi for GCC 13

[Gerald Pfeifer]

On Fri, 21 Apr 2023, Rainer Orth wrote:
> * We used a mixture of Solaris 2 and Solaris references.  Since Solaris
>   1/SunOS 4 is ancient history by now, consistently use Solaris
>   everywhere.  Likewise, explicit references to Solaris 11 can go in
>   many places since Solaris 11.3 and 11.4 is all GCC supports.

Thanks for going through this - this is great. (I had a look recently 
and wanted to raise that we have some older cruft that looked like it 
could go.)

> Will commit to trunk soon.  Ok for the gcc-13 branch, too?

Yes, please. 

There's only a few suggestions/recommendations:

   "on Solaris" (without "a")-@uref{https://www.opencsw.org/,,OpenCSW}
  +@uref{https://www.opencsw.org/,,OpenCSW}.  However, the packages there
  +are mostly outdated or actually harmful on Solaris 11.3 and 11.4.
   @end itemize

Would it make sense to simple drop this, then?


In the following two cases

  +@file{/usr/gnu/bin/as}), are known to work.  The current version, from
  +GNU binutils 2.40, is known to work as well.  Recent versions of the

and

  +works, as does the latest version, from GNU binutils 2.40.  However, it

how about saying "The version from GNU binutil 2.40" and "as does the 
version from GNU binutils 2.50", respectively?

"current" and "latest" are fleeting concepts.


  +Solaris @command{ld}, it is recommended to configure with

Can we make this active form, i.e., "we recommend"? Or simply omit the 
"it is recommended to" part. Both are shorter and clearer; personally I 
recommend to latter.


  +library or the MPC library on a Solaris, the canonical

"on Solaris" (without "a")

Thank you,
Gerald

Re: [PATCH] update_web_docs_git: Add updated Texinfo to PATH

[Gerald Pfeifer]

On Thu, 20 Apr 2023, Arsen Arsenović wrote:
>> I understand, just am wondering whether and why the : is required? I 
>> don't think we are using this construct anywhere else?
> Without them, this would happen:
> 
>   ~$ "${foo:=foo}"
>   bash: foo: command not found
>   ~ 127 $ unset foo
>   ~$ echo "${foo:=foo}"
>   foo
>   ~$ 

Ah, of course!

That's why I tend to use FOO=${FOO-barbar} in such cases - which is a tad 
more characters. :)

> Thank you!  Hopefully we get this just in time for 13 :)

The release is currently planned for the 26th and the udpated script is 
now live.

I just ran it and things seem to work just fine. Do you spot anything
unexpected?

Gerald

Re: [PATCH] update_web_docs_git: Add updated Texinfo to PATH

[Gerald Pfeifer]

Hi Arsen,

On Fri, 14 Apr 2023, Arsen Arsenović wrote:
>> Did you intentionally not implement the following part of my suggestion
>>
>>if [ x${MAKEINFO}x = xx ]; then
>>:
> > that is, allowing to override from the command-line (or crontab)?
> (answering both the questions)
> 
> This := operator is a handy "default assign" operator.  It's a bit of an
> oddity of the POSIX shell, but it works well.  The line:
> 
>   : "${foo:=bar}"
> 
> is a convenient way of spelling "if foo is unset or null, set it to
> bar".  the initial ':' there serves to discard the result of this
> evaluation (so that only its side effect of updating foo if necessary is
> kept)

I understand, just am wondering whether and why the : is required? I 
don't think we are using this construct anywhere else?

(I was aware of the ${foo:=bar} syntax, just caught up by you pushing
that part of the logic to the lowest level whereas I had it at the top
level. That's purely on me.)

Please go ahead and push this (or a variant without the : commands) and
I'll then pick it up from there.

Gerald

Re: [PATCH v3] gcc-13: Add changelog for LoongArch.

[Gerald Pfeifer]

On Tue, 18 Apr 2023, Lulu Cheng wrote:
>  v1 -> v2: Modify syntax errors and description information.
>  v2 -> v3: Modify some description information.

Thank you, and thank you to Xuerui for their feedback!

Please go ahead and push this.

Gerald

Re: [PATCH] gcc-13: Add changelog for LoongArch.

[Gerald Pfeifer]

First of all thank you! These are quite some nice enhancements, and it's 
great to see them documented.

On Tue, 18 Apr 2023, Lulu Cheng wrote:
> +The new command-line option -mexplicit-relocs 
> decides whether
> + to use or not use the assembler relocation operator when dealing 
> with

Here it is sufficient to say "to use" (and skip "or not to use"), since 
"whether" indicates this kind of choice.

> + symbolic addresses. -mexplicit-relocs is enabled by 
> default
> + when GCC is configured to use a compatible assembler.

We could say "It" instead of listing the option again. That's just an 
idea, you can keep it as is if you prefer.

> +
> +Avoid using the GOT to access external symbols when the new
> + -mdirect-extern-access command-line option is 
> specified.
> +
> +The  href="https://gcc.gnu.org/onlinedocs/gcc/LoongArch-Variable-Attributes.html#LoongArch-Variable-Attributes;>model
> + variable attributes has been added.

"attribute" (singular) to match "has".

> +Built-in functions support Improvements

Maybe just say "Built-in functions"?

> +The rint and copysign mathematical 
> builtins
> + (and their float variants) are now inplemented as inline 

"implemented"

> + float variants) are now inplemented as inline LoongArch intrinsics 
> when using

"implemented"

> + (and their float variants) are now inplemented as inline LoongArch 
> intrinsics

"implemented"

> +Subprojects Support
  ^
> +  
> +libvtv now supports LoongArch architecture.
> +libitm now supports LoongArch architecture.
> + LoongArch supports address sanitizers other than 
> hwasan and tsan.
> +  

Here, and in the other cases, the closing  (that I marked aboved) 
should follow , since both the heading and the  are part of the
same list item.

(See the RISC-V entry, for example.)


This change is fine with the changes highlighted above. (If you prefer, I 
can have another look; it's not required, though.)

Gerald

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

[pushed] wwwdocs: codingconventions: Recommend "file name" over "filename"

[Gerald Pfeifer]

This is based on an exchange with Sandra and Joseph back in, umm, 
April 2018.

Pushed for now.

Gerald

---

This aligns with the C and C++ standards as well as the GNU Coding
Standards, though POSIX uses "filename" as a component of "pathname".
---
 htdocs/codingconventions.html | 5 +
 1 file changed, 5 insertions(+)

diff --git a/htdocs/codingconventions.html b/htdocs/codingconventions.html
index 8b3cb8bb..9b6d243d 100644
--- a/htdocs/codingconventions.html
+++ b/htdocs/codingconventions.html
@@ -469,6 +469,11 @@ and code.  The following table lists some simple cases:
 "run time" or "runtime"
 
   
+  
+file name
+filename
+
+  
   
 "floating-point" (adjective)
 "floating point"
-- 
2.40.0

Re: [PATCH] update_web_docs_git: Add updated Texinfo to PATH

[Gerald Pfeifer]

On Tue, 11 Apr 2023, Arsen Arsenović wrote:
> Ah!  Good idea.  What do you think of the following?

Did you intentionally not implement the following part of my suggestion

   if [ x${MAKEINFO}x = xx ]; then
   :

that is, allowing to override from the command-line (or crontab)?


And why the colons in

  +: "${MAKEINFO:=${makeinfo_git}/makeinfo}"
  +: "${TEXI2DVI:=${makeinfo_git}/texi2dvi}"
  +: "${TEXI2PDF:=${makeinfo_git}/texi2pdf}"

? I don't think we use these elsewhere. Do they serve a purpose or can we 
omit them and keep things simpler?


Please let me know, and I'll see to get this (or probably an updated 
patch) in place on gcc.gnu.org.

Thanks,
Gerald

Re: [PATCH] update_web_docs_git: Add updated Texinfo to PATH

[Gerald Pfeifer]

On Thu, 6 Apr 2023, Arsen Arsenović wrote:
> I must ask that whoever decides to apply/update the script tests
> texi2any with a simple example, like
> 
>   echo @node Top | ~/texinfo/install-git/bin/makeinfo --html -o -
> 
> ... before updating; this should be a representative enough smoke test.
> You should see some HTML output with little text in it.

Yep, and one warning:

  -: warning: must specify a title with a title command or @top

The following then proceeds without warning and the output looks fine:

  printf "@title foo\n@node Top" | 
/home/gccadmin/texinfo/install-git/bin/makeinfo  --html -o -

Gerald

Re: [PATCH] update_web_docs_git: Add updated Texinfo to PATH

[Gerald Pfeifer]

On Thu, 6 Apr 2023, Arsen Arsenović wrote:
> maintainer-scripts/ChangeLog:
> 
>   * update_web_docs_git: Add updated Texinfo to PATH

Do we really need to adjust PATH, or could we just introduce a MAKEINFO 
variable, something like

  if [ x${MAKEINFO}x = xx ]; then
if [ -x /home/gccadmin/texinfo/install-git/bin/makeinfo ]; then
  MAKEINFO=/home/gccadmin/texinfo/install-git/bin/makeinfo;
else
  MAKEINFO=makeinfo
fi
  fi

?

(This also still allows overriding upon invocation.)

Gerald

[pushed] libiberty: Remove a reference to the Glibc manual

[Gerald Pfeifer]

With this we have a sole 404 on all of gcc.gnu.org (at least with
documentation from trunk included). :-)

Gerald


---

longjmp is not specific to Glibc, and GCC supports lots of systems
that do not use Glibc. Plus this link has been broken in the web
version for ages without a good way to fix.

libiberty/ChangeLog:

* obstacks.texi (Preparing for Obstacks): Remove a (broken)
reference to the Glibc manual.
---
 libiberty/obstacks.texi | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/libiberty/obstacks.texi b/libiberty/obstacks.texi
index b2d2403210b..37d26c90f1b 100644
--- a/libiberty/obstacks.texi
+++ b/libiberty/obstacks.texi
@@ -172,8 +172,8 @@ The value of this variable is a pointer to a function that
 @code{obstack} uses when @code{obstack_chunk_alloc} fails to allocate
 memory.  The default action is to print a message and abort.
 You should supply a function that either calls @code{exit}
-(@pxref{Program Termination, , , libc, The GNU C Library Reference Manual}) or 
@code{longjmp} (@pxref{Non-Local
-Exits, , , libc, The GNU C Library Reference Manual}) and doesn't return.
+(@pxref{Program Termination, , , libc, The GNU C Library Reference Manual}) 
+or @code{longjmp} and doesn't return.
 
 @smallexample
 void my_obstack_alloc_failed (void)
-- 
2.39.2

Re: [PATCH] Introduce -nolibstdc++ option

[Gerald Pfeifer]

On Thu, 30 Mar 2023, Alexandre Oliva wrote:
> How about this, does this seem useful?

I like it - helpful and easy to understand. :-)

Gerald

Re: [pushed] wwwdocs: gcc-4.7: Adjust dwarfstd.org links

[Gerald Pfeifer]

On Thu, 30 Mar 2023, Mark Wielaard wrote:
>>> Business as usual - 301 Moved Permanently.
>> Just FYI, dwarfstd is now hosted by sourceware too. So I doubt these
>> URLs will change after this.

Famous last words. :-)

> Indeed, see
> https://inbox.sourceware.org/overseers/20230327222524.ga20...@gnu.wildebeest.org/
> 
> And thanks for taking care of these new redirects. Please do let us
> (dwarf-disc...@lists.dwarfstd.org) know if any old URL is broken.

Yes, I'll advise, though so far I am draw my hat for you handling this
migration so smoothly: all links still have been working, and a proper
redirect - "301, please adjust links" - been issued.

Gerald

Re: [wwwdocs] Mention the GNU C enum changes in gcc-13/changes.html

[Gerald Pfeifer]

On Fri, 24 Mar 2023, Jakub Jelinek wrote:
> Shall we mention it in porting_to.html as well?
> The only known affected package is (was?) the Linux kernel.

If in a rebuild of Fedora (or openSUSE) the only affected package is the 
kernel, we probably don't need to go for porting_to.html?

> --- a/htdocs/gcc-13/changes.html
> +++ b/htdocs/gcc-13/changes.html
> +The behavior of the GNU C extension support of enumerators which
> +  don't fit into int has been changed to match the C2X
> +  behavior.  Previously, in enumerations where at least one enumerator
> +  didn't fit into int, only those enumerators that didn't
> +  fit into int had the enum type and others
> +  had int type 

So far I understand, and it feels intuitive.

>and while the enum is being
> +  defined enumerators that didn't fit into int had some
> +  unspecified type with the sign and precision of its value.

This, however, really confuses me.

Should this be "while" (without "and")?

And what are we trying to say here? Can we essentially omit this since
it is a bit more specific, but mostly redundant with the earlier 
statement?

Otherwise, maybe first talk about the elements that fit type int and
then merge the two statements about those that don't?


> +  In GCC13, in such enumerations all enumerators have the
> +  enum type and while the enum is being
> +  defined enumerators that didn't fit into int have
> +  type of their value.

"don't" 

"the type of their value"?

>  If all enumerators fit into int
> +  type, as before all enumerators have int type, both
> +  while the enum is being defined and after it is defined.
> +  See https://gcc.gnu.org/PR36113;>PR36113 for details.
> +

Can we skip this? "In such enumerations" above refers to the special case,
and the simple case (where everything fits into int) has not changed, has 
it?

Gerald

[pushed] wwwdocs: gcc-4.7: Adjust dwarfstd.org links

[Gerald Pfeifer]

Business as usual - 301 Moved Permanently.

Gerald
---
 htdocs/gcc-4.7/changes.html | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/htdocs/gcc-4.7/changes.html b/htdocs/gcc-4.7/changes.html
index f98f108c..91159f1f 100644
--- a/htdocs/gcc-4.7/changes.html
+++ b/htdocs/gcc-4.7/changes.html
@@ -994,13 +994,13 @@ void set_portb (uint8_t value)
 GCC now supports various new GNU extensions to the DWARF debugging
 information format, like
 https://www.dwarfstd.org/ShowIssue.php?issue=100909.1;>entry
+href="https://dwarfstd.org/issues/100909.1.html;>entry
 value and https://www.dwarfstd.org/ShowIssue.php?issue=100909.2;>call
+href="https://dwarfstd.org/issues/100909.2.html;>call
 site information, https://www.dwarfstd.org/ShowIssue.php?issue=140425.1;>typed DWARF 
stack
+href="https://dwarfstd.org/issues/140425.1.html;>typed DWARF stack
 or https://www.dwarfstd.org/ShowIssue.php?issue=110722.1;>a
+href="https://dwarfstd.org/issues/110722.1.html;>a
 more compact macro representation.  Support for these extensions
 has been added to GDB 7.4. They can be disabled through the
 -gstrict-dwarf command-line option.
-- 
2.39.2

[pushed] doc: Remove anachronistic note related to languages built

[Gerald Pfeifer]

Jonathan's patch 
  https://gcc.gnu.org/pipermail/gcc-patches/2022-November/604796.html
lat November made me have a look for further instances, and indeed there
was another one referring to separate tarballs (which we have not been
shipping for a fair bit).

Since the item above already refers to `gcc -v` we can simply drop the
entire list item.

Pushed.

Gerald
---

This is another instance of what ce51e8439a49 (and originally
05432288d4e5) addressed in a different part. We stopped shipping
granular tarballs years ago.

gcc/ChangeLog:

* doc/install.texi: Remove anachronistic note
related to languages built and separate source tarballs.
---
 gcc/doc/install.texi | 7 ---
 1 file changed, 7 deletions(-)

diff --git a/gcc/doc/install.texi b/gcc/doc/install.texi
index 63fc949b447..15aef1394f4 100644
--- a/gcc/doc/install.texi
+++ b/gcc/doc/install.texi
@@ -3481,13 +3481,6 @@ The output of @samp{gcc -v} for your newly installed 
@command{gcc}.
 This tells us which version of GCC you built and the options you passed to
 configure.
 
-@item
-Whether you enabled all languages or a subset of them.  If you used a
-full distribution then this information is part of the configure
-options in the output of @samp{gcc -v}, but if you downloaded the
-``core'' compiler plus additional front ends then it isn't apparent
-which ones you built unless you tell us about it.
-
 @item
 If the build was for GNU/Linux, also include:
 @itemize @bullet
-- 
2.39.2

Re: Ping (gcc/configure.ac, docs): [PATCH v2 4/5] Update texinfo.tex, remove the @gol macro/alias

[Gerald Pfeifer]

On Tue, 21 Mar 2023, Arsen Arsenović wrote:
> Done!
> 
> Gerald, please update the scripts when you get a chance (but back the
> old ones up just in case!)

Done. Minus the backup, since everything is in Git anyways, isn't it? :-)

The script should run in about 1 hour and 45 minutes.

> If makeinfo is updated as I've asked in one of the other emails, will
> the script eventually automatically regenerate docs with the newer
> makeinfo?

Only what is covered by update_web_docs_git and then whenever our release 
managers create docs for a new release.

Which makes sense since we cannot guarantee older *.texi sources actually
building, or at least properly, with newer makeinfo releases. And there 
may be other factors, such as names of file changing,...


Which makes me realize we may have an issue building releases: 

Joseph, you are release manager - do you and your peers create releases on 
a local system or gcc.gnu.org? If the former, installing newer texinfo on 
gcc.gnu.org is not going to be sufficient.

Gerald

[pushed] wwwdocs: readings: Switch publibfp.dhe.ibm.com to https

[Gerald Pfeifer]

Pushed.

Gerald
---
 htdocs/readings.html | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/htdocs/readings.html b/htdocs/readings.html
index 3cdc47a9..6813b84f 100644
--- a/htdocs/readings.html
+++ b/htdocs/readings.html
@@ -310,8 +310,8 @@ names.
 
  z/Architecture (S/390)
   Manufacturer: IBM
-  http://publibfp.dhe.ibm.com/epubs/pdf/a227832c.pdf;>z/Architecture 
Principles of Operation
-  http://publibfp.dhe.ibm.com/epubs/pdf/dz9ar008.pdf;>ESA/390 
Principles of Operation
+  https://publibfp.dhe.ibm.com/epubs/pdf/a227832c.pdf;>z/Architecture 
Principles of Operation
+  https://publibfp.dhe.ibm.com/epubs/pdf/dz9ar008.pdf;>ESA/390 
Principles of Operation
   https://refspecs.linuxbase.org/ELF/zSeries/lzsabi0_zSeries.html;>Linux 
for z Systems ABI
   https://refspecs.linuxbase.org/ELF/zSeries/lzsabi0_s390.html;>Linux for 
S/390 ABI
  
-- 
2.39.2