Re: [PATCH v10 2/5] Convert references with "counted_by" attributes to/from .ACCESS_WITH_SIZE.

[Joseph Myers]

On Thu, 30 May 2024, Qing Zhao wrote:

>   In order to make this working, the routine digest_init in c-typeck.cc
>   is updated to fold calls to .ACCESS_WITH_SIZE to its first argument
>   when require_constant is TRUE.

The new changes here are OK.

-- 
Joseph S. Myers
josmy...@redhat.com

Re: [RFC/PATCH] Replace {FLOAT,{,LONG_}DOUBLE}_TYPE_SIZE with new hook

[Joseph Myers]

On Wed, 29 May 2024, Kewen.Lin wrote:

> > Note that when removing a target macro, it's a good idea to add it to the 
> > "Old target macros that have moved to the target hooks structure." list 
> > (of #pragma GCC poison) in system.h to ensure any new target that was 
> > originally written before the change doesn't accidentally get into GCC 
> > while still using the old macros.
> > 
> 
> Thanks for the comments on target macro removal!  I found it means
> that we can't use such macros any more even if they have become port
> specific.  For some targets such as pa, they redefine these macros in

Yes, that's intentional.  If you need subtarget headers to define 
something for use in the new target hook for those targets, make them 
define e.g. SUBTARGET_LONG_DOUBLE_MODE or similar instead, rather than 
using the old poisoned macro names.

-- 
Joseph S. Myers
josmy...@redhat.com

Re: [C23 PATCH]: allow aliasing for types derived from structs with variable size

[Joseph Myers]

On Sun, 26 May 2024, Martin Uecker wrote:

> +/* Helper function for comptypes.  For two compatible types, return 1
> +   if they pass consistency checks.  In particular we test that
> +   TYPE_CANONICAL ist set correctly, i.e. the two types can alias.  */

s/ist/is/.  OK with that fix.

-- 
Joseph S. Myers
josmy...@redhat.com

Re: [C23 PATCH, v2] fix aliasing for structures/unions with incomplete types

[Joseph Myers]

On Sun, 26 May 2024, Martin Uecker wrote:

> This is the patch I sent previously, but I tried to improve the
> description and added a long comment.  This patch is needed so
> that we do not have to update TYPE_CANONICAL of structures / unions
> when a tagged type is completed that is (recursively) pointed to 
> by a member of the structure / union.
> 
> Bootstrapped and regression tested on x86_64.
> 
> 
> C23: fix aliasing for structures/unions with incomplete types
> 
> When incomplete structure/union types are completed later, compatibility
> of struct types that contain pointers to such types changes.  When forming
> equivalence classes for TYPE_CANONICAL, we therefor need to be 
> conservative
> and treat all structs with the same tag which are pointer targets as
> equivalent for purposed of determining equivalency of structure/union
> types which contain such types as member. This avoids having to update
> TYPE_CANONICAL of such structure/unions recursively. The pointer types
> themselves are updated in c_update_type_canonical.
> 
> gcc/c/
> * c-typeck.cc (comptypes_internal): Add flag to track
> whether a struct is the target of a pointer.
> (tagged_types_tu_compatible): When forming equivalence
> classes, treat nested pointed-to structs as equivalent.
> 
> gcc/testsuite/
> * gcc.dg/c23-tag-incomplete-alias-1.c: New test.

This patch is OK.

-- 
Joseph S. Myers
josmy...@redhat.com

Re: [C PATCH, v2]: allow aliasing of compatible types derived from enumeral types [PR115157]

[Joseph Myers]

On Fri, 24 May 2024, Martin Uecker wrote:

> This is another version of this patch with two changes:
> 
> - I added a fix (with test) for PR 115177 which is just the same
> issue for hardbools which are internally implemented as enums.
> 
> - I fixed the golang issue. Since the addition of the main variant
> to the seen decls is unconditional I removed also the addition
> of the type itself which now seems unnecessary.
> 
> Bootstrapped and regression tested on x86_64.

The front-end changes and the testcases are OK.

-- 
Joseph S. Myers
josmy...@redhat.com

Re: [RFC/PATCH] Replace {FLOAT,{,LONG_}DOUBLE}_TYPE_SIZE with new hook

[Joseph Myers]

On Fri, 24 May 2024, Kewen.Lin wrote:

> Following your suggestion and comments, I made this patch
> for mode_for_floating_type first, considering this touches
> a few FE and port specific code, I think I have to split
> it into a patch series.  Before making that, I'd like to
> ensure this meets what you expected, and also seek for the

The general idea seems reasonable (I haven't reviewed it in detail).  
Note that when removing a target macro, it's a good idea to add it to the 
"Old target macros that have moved to the target hooks structure." list 
(of #pragma GCC poison) in system.h to ensure any new target that was 
originally written before the change doesn't accidentally get into GCC 
while still using the old macros.

-- 
Joseph S. Myers
josmy...@redhat.com

Re: configure adds -std=gnu++11 to CXX variable

[Joseph Myers via Gcc]

On Tue, 28 May 2024, Jakub Jelinek via Gcc wrote:

> -std=gnu23 support is still incomplete even in GCC 14.

It doesn't involve ABI issues, however, unlike C++, so using the option 
with GCC 14 is comparatively safe.  (It might run into a few aliasing bugs 
related to tag compatibility right now, but hopefully we'll have fixes for 
those backported for 14.2 as wrong-code issues.  And of course code 
testing __STDC_VERSION__ with GCC 14 or before needs to handle 
incompleteness of the implementation.)  Once we have #embed implemented 
(and so are substantially feature-complete, modulo the optional standard 
function attributes [[unsequenced]] and [[reproducible]]) it should be 
reasonable to change the default to -std=gnu23 (though we'll need to see 
what the distribution build impact from such a change is, especially 
regarding bool, true and false becoming keywords).

This certainly doesn't guarantee there won't be future C features with ABI 
issues from using an unstable version, however (if some C2y draft adds a 
new feature, then it's implemented, then the specification changes in an 
ABI-incompatible way - for an old example, consider how early C9x drafts 
had an enum-based definition of _Bool, which changed later to a built-in 
type like in C++, thereby changing from the size of int to a single byte).  
Indeed the API for some library functions in TS 18661-1 changed for the 
versions in C23, but that can be handled in glibc through symbol 
versioning (done some time ago for the totalorder functions, not yet done 
for fromfp functions).

-- 
Joseph S. Myers
josmy...@redhat.com

Re: [C PATCH]: allow aliasing of compatible types derived from enumeral types [PR115157]

[Joseph Myers]

On Tue, 21 May 2024, Martin Uecker wrote:
> 
> C: allow aliasing of compatible types derived from enumeral types 
> [PR115157]
> 
> Aliasing of enumeral types with the underlying integer is now allowed
> by setting the aliasing set to zero.  But this does not allow aliasing
> of derived types which are compatible as required by ISO C.  Instead,
> initially set structural equality.  Then set TYPE_CANONICAL and update
> pointers and main variants when the type is completed (as done for
> structures and unions in C23).
> 
> PR 115157
> 
> gcc/c/
> * c-decl.cc (shadow_tag-warned,parse_xref_tag,start_enum,
> finish_enum): Set SET_TYPE_STRUCTURAL_EQUALITY / TYPE_CANONICAL.
> * c-obj-common.cc (get_alias_set): Remove special case.
> (get_aka_type): Add special case.
> 
> gcc/
> * godump.cc (go_output_typedef): use TYPE_MAIN_VARIANT instead
> of TYPE_CANONICAL.
> 
> gcc/testsuite/
> * gcc.dg/enum-alias-1.c: New test.
> * gcc.dg/enum-alias-2.c: New test.
> * gcc.dg/enum-alias-3.c: New test.

OK, in the absence of objections on middle-end or Go grounds within the 
next week.

-- 
Joseph S. Myers
josmy...@redhat.com

Re: [C PATCH, v2] Fix for redeclared enumerator initialized with different type [PR115109]

[Joseph Myers]

On Tue, 21 May 2024, Martin Uecker wrote:

> > The constraint violated is the general one "If an identifier has no 
> > linkage, there shall be no more than one declaration of the identifier (in 
> > a declarator or type specifier) with the same scope and in the same name 
> > space, except that: ... enumeration constants and tags may be redeclared 
> > as specified in 6.7.3.3 and 6.7.3.4, respectively." (where 6.7.3.3 says 
> > "Enumeration constants can be redefined in the same scope with the same 
> > value as part of a redeclaration of the same enumerated type." - as the 
> > redefinition is not with the same value, the "as specified in 6.7.3.3" is 
> > not satisfied and so the general constraint against redeclarations with no 
> > linkage applies).
> 
> This assumes that the value in question is the one of the initializer and not 
> the
> one after initialization (with no clear rules how this works in this case), 

There are no initializers here.  The constant-expression after '=' in the 
syntax for enumerator is not an initializer, and none of the rules for 
initializers apply to it.  (If the initializer with an out-of-range value 
also gets used in an expression, the constraint on constants would be 
violated, "Each constant shall have a type and the value of a constant 
shall be in the range of representable values for its type." - but the 
constraint on multiple declarations applies whether it's used or not.)

-- 
Joseph S. Myers
josmy...@redhat.com

Re: [C PATCH, v2] Fix for redeclared enumerator initialized with different type [PR115109]

[Joseph Myers]

On Sun, 19 May 2024, Martin Uecker wrote:

> c23 specifies that the type of a redeclared enumerator is the one of the
> previous declaration.  Convert initializers with different type 
> accordingly
> and add -Woverflow warning.

It doesn't make sense to use -Woverflow.  Either the value is the same (in 
which case it fits in the desired type), or it's different (and you should 
get the "conflicting redeclaration of enumerator" error or some equivalent 
error, whether or not the value in the redeclaration fits in the previous 
type).

Note that this includes both explicit values and values determined by 
adding 1 implicitly.  E.g.

  enum e { A = 0, B = UINT_MAX };
  enum e { B = UINT_MAX, A };

is not valid, because in the redefinition, A gets the value 1 greater than 
UINT_MAX (which is not representable in unsigned int) - there is *not* an 
addition in type unsigned int, or in type enum e.

The constraint violated is the general one "If an identifier has no 
linkage, there shall be no more than one declaration of the identifier (in 
a declarator or type specifier) with the same scope and in the same name 
space, except that: ... enumeration constants and tags may be redeclared 
as specified in 6.7.3.3 and 6.7.3.4, respectively." (where 6.7.3.3 says 
"Enumeration constants can be redefined in the same scope with the same 
value as part of a redeclaration of the same enumerated type." - as the 
redefinition is not with the same value, the "as specified in 6.7.3.3" is 
not satisfied and so the general constraint against redeclarations with no 
linkage applies).

-- 
Joseph S. Myers
josmy...@redhat.com

Re: [C PATCH] Fix for some variably modified types not being recognized [PR114831]

[Joseph Myers]

On Sat, 18 May 2024, Martin Uecker wrote:

> We did not propagate C_TYPE_VARIABLY_MODIFIED to pointers in all
> cases.   I added this directly in two places, but maybe we should
> check all cases of build_pointer_type or integrate this into 
> c_build_pointer_type and use this everywhere (but I do not fully 
> understand the pointer mode logic there).

This is OK.  I think there's at least one further bug in this area: 
composite types of pointer types (which happen to use 
build_pointer_type_for_mode) don't seem to propagate 
C_TYPE_VARIABLY_MODIFIED either.  Maybe there are other cases as well; 
checking all uses of build_pointer_type functions would make sense.

-- 
Joseph S. Myers
josmy...@redhat.com

[gcc r14-10213] Update gcc sv.po

[Joseph Myers via Gcc-cvs]

https://gcc.gnu.org/g:81c627d47c2063b7f143c974e9733ce43c0d142e

commit r14-10213-g81c627d47c2063b7f143c974e9733ce43c0d142e
Author: Joseph Myers 
Date:   Thu May 16 21:21:48 2024 +

Update gcc sv.po

* sv.po: Update.

Diff:
---
 gcc/po/sv.po | 514 +--
 1 file changed, 185 insertions(+), 329 deletions(-)

diff --git a/gcc/po/sv.po b/gcc/po/sv.po
index c28ce798df8d..9151df652e0d 100644
--- a/gcc/po/sv.po
+++ b/gcc/po/sv.po
@@ -29,10 +29,10 @@
 # thunksnutt
 msgid ""
 msgstr ""
-"Project-Id-Version: gcc 14.1-b20240218\n"
+"Project-Id-Version: gcc 14.1.0\n"
 "Report-Msgid-Bugs-To: https://gcc.gnu.org/bugs/\n;
 "POT-Creation-Date: 2024-05-02 19:44+\n"
-"PO-Revision-Date: 2024-04-10 22:53+0200\n"
+"PO-Revision-Date: 2024-05-16 22:03+0200\n"
 "Last-Translator: Göran Uddeborg \n"
 "Language-Team: Swedish \n"
 "Language: sv\n"
@@ -1652,7 +1652,7 @@ msgstr "Varna för typkonvertering som slänger 
kvalificerare."
 #: c-family/c.opt:519
 #, no-c-format
 msgid "Warn about a cast to reference type that does not use a related 
user-defined conversion function."
-msgstr ""
+msgstr "Varna för en typkonvertering till en referenstyp som inte använder en 
relaterad användardefinierad konverteringsfunktion."
 
 #: c-family/c.opt:523 c-family/c.opt:527
 #, no-c-format
@@ -1977,10 +1977,9 @@ msgid "Warn when __builtin_frame_address or 
__builtin_return_address is used uns
 msgstr "Varna när __builtin_frame_address eller __builtin_return_address 
används osäkert."
 
 #: c-family/c.opt:811
-#, fuzzy, no-c-format
-#| msgid "global module fragment contents must be from preprocessor inclusion"
+#, no-c-format
 msgid "Warn about the global module fragment not containing only preprocessing 
directives."
-msgstr "globala modulfragments innehåll måste komma från 
preprocessorinkludering"
+msgstr "Varna för att det globala modulfragmentet inte endast innehåller 
preprocessordirektiv."
 
 #: c-family/c.opt:815
 #, no-c-format
@@ -2508,8 +2507,7 @@ msgid "Warn about suspicious length parameters to certain 
string functions if th
 msgstr "Varna för misstänkta längdparametrar till vissa strängfunktioner om 
argumentet använder sizeof."
 
 #: c-family/c.opt:1323
-#, fuzzy, no-c-format
-#| msgid "Warn about inproper usages of flexible array members according to 
the level of -fstrict-flex-arrays."
+#, no-c-format
 msgid "Warn about improper usages of flexible array members according to the 
level of -fstrict-flex-arrays."
 msgstr "Varna för felaktig användning av flexibla vektorelement enligt nivån 
på -fstrict-flex-arrays."
 
@@ -4136,14 +4134,12 @@ msgid "turn on internal debugging of the compiler 
(internal switch)"
 msgstr "slå på intern felsökning av kompilatorn (intern flagga)"
 
 #: m2/lang.opt:95
-#, fuzzy, no-c-format
-#| msgid "turn on internal debugging of the compiler (internal switch)"
+#, no-c-format
 msgid "turn on tracing of procedure line numbers (internal switch)"
-msgstr "slå på intern felsökning av kompilatorn (intern flagga)"
+msgstr "slå på spårning av procedurers radnummer (intern flagga)"
 
 #: m2/lang.opt:99
-#, fuzzy, no-c-format
-#| msgid "recognise the specified suffix as a definition module filename"
+#, no-c-format
 msgid "recognize the specified suffix as a definition module filename"
 msgstr "känn igen det angivna suffixet som ett definitionsmudulsfilnamn"
 
@@ -4188,10 +4184,9 @@ msgid "set all location values to a specific value 
(internal switch)"
 msgstr "sätt alla platsvärden till ett specifikt värde (intern flagga)"
 
 #: m2/lang.opt:135
-#, fuzzy, no-c-format
-#| msgid "turn on internal debugging of the compiler (internal switch)"
+#, no-c-format
 msgid "turn on internal debug tracing for quad,token,line,all (internal 
switch)"
-msgstr "slå på intern felsökning av kompilatorn (intern flagga)"
+msgstr "slå på intern felsökningsspårning för quad,token,line,all (intern 
flagga)"
 
 #: m2/lang.opt:139
 #, no-c-format
@@ -4234,8 +4229,7 @@ msgid "compile all implementation modules and program 
module at once"
 msgstr "kompilera alla implementationsmoduler och programmoduler på en gång"
 
 #: m2/lang.opt:175
-#, fuzzy, no-c-format
-#| msgid "recognise the specified suffix as implementation and module 
filenames"
+#, no-c-format
 msgid "recognize the specified suffix as implementation and module filenames"
 msgstr "känn igen det angivna suffixet som implementation och modulfilnamn"
 
@@ -4340,8 +4334,7 @@ msgid "optimize non var unbounded parameters by passing 
it by

[gcc r15-584] Update gcc sv.po

[Joseph Myers via Gcc-cvs]

https://gcc.gnu.org/g:0b2c333e1a3c0bb800add1daab5b6fc8ba5c1cef

commit r15-584-g0b2c333e1a3c0bb800add1daab5b6fc8ba5c1cef
Author: Joseph Myers 
Date:   Thu May 16 21:20:36 2024 +

Update gcc sv.po

* sv.po: Update.

Diff:
---
 gcc/po/sv.po | 514 +--
 1 file changed, 185 insertions(+), 329 deletions(-)

diff --git a/gcc/po/sv.po b/gcc/po/sv.po
index c28ce798df8d..9151df652e0d 100644
--- a/gcc/po/sv.po
+++ b/gcc/po/sv.po
@@ -29,10 +29,10 @@
 # thunksnutt
 msgid ""
 msgstr ""
-"Project-Id-Version: gcc 14.1-b20240218\n"
+"Project-Id-Version: gcc 14.1.0\n"
 "Report-Msgid-Bugs-To: https://gcc.gnu.org/bugs/\n;
 "POT-Creation-Date: 2024-05-02 19:44+\n"
-"PO-Revision-Date: 2024-04-10 22:53+0200\n"
+"PO-Revision-Date: 2024-05-16 22:03+0200\n"
 "Last-Translator: Göran Uddeborg \n"
 "Language-Team: Swedish \n"
 "Language: sv\n"
@@ -1652,7 +1652,7 @@ msgstr "Varna för typkonvertering som slänger 
kvalificerare."
 #: c-family/c.opt:519
 #, no-c-format
 msgid "Warn about a cast to reference type that does not use a related 
user-defined conversion function."
-msgstr ""
+msgstr "Varna för en typkonvertering till en referenstyp som inte använder en 
relaterad användardefinierad konverteringsfunktion."
 
 #: c-family/c.opt:523 c-family/c.opt:527
 #, no-c-format
@@ -1977,10 +1977,9 @@ msgid "Warn when __builtin_frame_address or 
__builtin_return_address is used uns
 msgstr "Varna när __builtin_frame_address eller __builtin_return_address 
används osäkert."
 
 #: c-family/c.opt:811
-#, fuzzy, no-c-format
-#| msgid "global module fragment contents must be from preprocessor inclusion"
+#, no-c-format
 msgid "Warn about the global module fragment not containing only preprocessing 
directives."
-msgstr "globala modulfragments innehåll måste komma från 
preprocessorinkludering"
+msgstr "Varna för att det globala modulfragmentet inte endast innehåller 
preprocessordirektiv."
 
 #: c-family/c.opt:815
 #, no-c-format
@@ -2508,8 +2507,7 @@ msgid "Warn about suspicious length parameters to certain 
string functions if th
 msgstr "Varna för misstänkta längdparametrar till vissa strängfunktioner om 
argumentet använder sizeof."
 
 #: c-family/c.opt:1323
-#, fuzzy, no-c-format
-#| msgid "Warn about inproper usages of flexible array members according to 
the level of -fstrict-flex-arrays."
+#, no-c-format
 msgid "Warn about improper usages of flexible array members according to the 
level of -fstrict-flex-arrays."
 msgstr "Varna för felaktig användning av flexibla vektorelement enligt nivån 
på -fstrict-flex-arrays."
 
@@ -4136,14 +4134,12 @@ msgid "turn on internal debugging of the compiler 
(internal switch)"
 msgstr "slå på intern felsökning av kompilatorn (intern flagga)"
 
 #: m2/lang.opt:95
-#, fuzzy, no-c-format
-#| msgid "turn on internal debugging of the compiler (internal switch)"
+#, no-c-format
 msgid "turn on tracing of procedure line numbers (internal switch)"
-msgstr "slå på intern felsökning av kompilatorn (intern flagga)"
+msgstr "slå på spårning av procedurers radnummer (intern flagga)"
 
 #: m2/lang.opt:99
-#, fuzzy, no-c-format
-#| msgid "recognise the specified suffix as a definition module filename"
+#, no-c-format
 msgid "recognize the specified suffix as a definition module filename"
 msgstr "känn igen det angivna suffixet som ett definitionsmudulsfilnamn"
 
@@ -4188,10 +4184,9 @@ msgid "set all location values to a specific value 
(internal switch)"
 msgstr "sätt alla platsvärden till ett specifikt värde (intern flagga)"
 
 #: m2/lang.opt:135
-#, fuzzy, no-c-format
-#| msgid "turn on internal debugging of the compiler (internal switch)"
+#, no-c-format
 msgid "turn on internal debug tracing for quad,token,line,all (internal 
switch)"
-msgstr "slå på intern felsökning av kompilatorn (intern flagga)"
+msgstr "slå på intern felsökningsspårning för quad,token,line,all (intern 
flagga)"
 
 #: m2/lang.opt:139
 #, no-c-format
@@ -4234,8 +4229,7 @@ msgid "compile all implementation modules and program 
module at once"
 msgstr "kompilera alla implementationsmoduler och programmoduler på en gång"
 
 #: m2/lang.opt:175
-#, fuzzy, no-c-format
-#| msgid "recognise the specified suffix as implementation and module 
filenames"
+#, no-c-format
 msgid "recognize the specified suffix as implementation and module filenames"
 msgstr "känn igen det angivna suffixet som implementation och modulfilnamn"
 
@@ -4340,8 +4334,7 @@ msgid "optimize non var unbounded parameters by passing 
it by

Re: [PATCH 1/4] rs6000: Make all 128 bit scalar FP modes have 128 bit precision [PR112993]

[Joseph Myers]

On Mon, 13 May 2024, Kewen.Lin wrote:

> > In fact replacing all of X_TYPE_SIZE with a single hook might be worthwhile
> > though this removes the "convenient" defaulting, requiring each target to
> > enumerate all standard C ABI type modes.  But that might be also a good 
> > thing.
> > 
> 
> I guess the main value by extending from floating point types to all is to
> unify them?  (Assuming that excepting for floating types the others would
> not have multiple possible representations like what we faces on 128bit fp).

For integer types, giving the number of bits makes sense as an interface - 
there isn't an issue with different modes.

So I think it's appropriate for floating and integer types to have 
separate hooks - with the one for floating types returning a mode, and the 
one for integer types returning a number of bits.  (And also keep the 
existing separate hook for _FloatN / _FloatNx modes.)

That may also make for more convenient defaults (whether a target has long 
double wider than double is largely independent of what sizes it uses for 
integer types).

-- 
Joseph S. Myers
josmy...@redhat.com

Re: [PATCH] PR middle-end/111701: signbit(x*x) vs -fsignaling-nans

[Joseph Myers]

On Wed, 8 May 2024, Richard Biener wrote:

> So it's reasonable to require -fnon-call-exceptions (which now enables
> -fexceptions) and -fno-delete-dead-exceptions to have GCC preserve
> a change of control flow side-effect of x*x?  We do not preserve
> FP exception bits set by otherwise unused operations, that is, we
> do not consider that side-effect to be observable even with
> -ftrapping-math.  In fact I most uses of flag_trapping_math
> are related to a possible control flow side-effect of FP math.

I think lots are about avoiding changing exceptions raised (flags set) by 
an operation that is seen as being used.

> Exact preservation of FP exception flags will likely have to disable
> all FP optimization if one considers FE_INEXACT and FE_UNDERFLOW.

It's very likely that as per previous discussions we need some different 
set of options from the current ones to properly reflect the various ways 
in which preserving how operations interact with the floating-point 
environments (exception flags, exceptions changing flow of control, 
rounding modes; various of which may also depend on whether the results of 
operations appear to the compiler to be used) may inhibit optimization.

-- 
Joseph S. Myers
josmy...@redhat.com

Re: [PATCH] driver: Move -fdiagnostics-urls= early like -fdiagnostics-color= [PR114980]

[Joseph Myers]

On Wed, 8 May 2024, Xi Ruoyao wrote:

> In GCC 14 we started to emit URLs for "command-line option  is
> valid for  but not " and "-Werror= argument
> '-Werror=' is not valid for " warnings.  So we should
> have moved -fdiagnostics-urls= early like -fdiagnostics-color=, or
> -fdiagnostics-urls= wouldn't be able to control URLs in these warnings.
> 
> No test cases are added because with TERM=xterm-256colors PR114980
> already triggers some test failures.
> 
> gcc/ChangeLog:
> 
>   PR driver/114980
>   * opts-common.cc (prune_options): Move -fdiagnostics-urls=
>   early like -fdiagnostics-color=.

OK.

-- 
Joseph S. Myers
josmy...@redhat.com

Re: [PATCH 1/4] rs6000: Make all 128 bit scalar FP modes have 128 bit precision [PR112993]

[Joseph Myers]

On Wed, 8 May 2024, Kewen.Lin wrote:

> to widen IFmode to TFmode.  To make build_common_tree_nodes
> be able to find the correct mode for long double type node,
> it introduces one hook mode_for_longdouble to offer target
> a way to specify the mode used for long double type node.

I don't really like layering a hook on top of the old target macro as a 
way to address a deficiency in the design of that target macro (floating 
types should have their mode, not a poorly defined precision value, 
specified directly by the target).

A better hook design might be something like mode_for_floating_type (enum 
tree_index), where the argument is TI_FLOAT_TYPE, TI_DOUBLE_TYPE or 
TI_LONG_DOUBLE_TYPE, replacing all definitions and uses of 
FLOAT_TYPE_SIZE, DOUBLE_TYPE_SIZE and LONG_DOUBLE_TYPE_SIZE with the 
single new hook and appropriate definitions for each target (with a 
default definition that uses SFmode for float and DFmode for double and 
long double, which would be suitable for many targets).

-- 
Joseph S. Myers
josmy...@redhat.com

Re: [PATCH 3/4] gcc/c-family/c-opts: fix quoting for `-fdeps-format=` error message

[Joseph Myers]

On Sat, 4 May 2024, Ben Boeckel wrote:

> diff --git a/gcc/c-family/c-opts.cc b/gcc/c-family/c-opts.cc
> index be3058dca63..4a164ad0c0b 100644
> --- a/gcc/c-family/c-opts.cc
> +++ b/gcc/c-family/c-opts.cc
> @@ -370,7 +370,7 @@ c_common_handle_option (size_t scode, const char *arg, 
> HOST_WIDE_INT value,
>if (!strcmp (arg, "p1689r5"))
>   cpp_opts->deps.fdeps_format = FDEPS_FMT_P1689R5;
>else
> - error ("%<-fdeps-format=%> unknown format %<%s%>", arg);
> + error ("%<-fdeps-format=%> unknown format %q", arg);
>break;

That can't be right.  The GCC %q is a modifier that needs to have an 
actual format specifier it modifies (so %qs - which produces the same 
output as %<%s%> - but not %q by itself).

-- 
Joseph S. Myers
josmy...@redhat.com

Re: [PATCH] PR middle-end/111701: signbit(x*x) vs -fsignaling-nans

[Joseph Myers]

On Fri, 3 May 2024, Richard Biener wrote:

> So what I do not necessarily agree with is that we need to preserve
> the multiplication with -fsignaling-nans.  Do we consider a program doing
> 
> handler() { exit(0); }
> 
>  x = sNaN;
> ...
>  sigaction(SIGFPE, ... handler)
>  x*x;
>  format_hard_drive();
> 
> and expecting the program to exit(0) rather than formating the hard-disk
> to be expecting something the C standard guarantees?  And is it enough
> for the program to enable -fsignaling-nans for this?
> 
> If so then the first and foremost bug is that 'x*x' doesn't have
> TREE_SIDE_EFFECTS
> set and thus we do not preserve it when optimizing __builtin_signbit () of it.

Signaling NaNs don't seem relevant here.  "Signal" means "set the 
exception flag" - and 0 * Inf raises the same "invalid" exception flag as 
sNaN * sNaN.  Changing flow of control on an exception is outside the 
scope of standard C and requires nonstandard extensions such as 
feenableexcept.  (At present -ftrapping-math covers both kinds of 
exception handling - the default setting of a flag, and the nonstandard 
change of flow of control.)

-- 
Joseph S. Myers
josmy...@redhat.com

Re: Updated Sourceware infrastructure plans

[Joseph Myers via Gcc]

On Sat, 4 May 2024, Ben Boeckel via Gcc wrote:

>   - every push is stored in a ghostflow-director-side unique ref
> (`refs/mr/ID/heads/N` where `N` is an incrementing integer) to avoid
> forge-side garbage collection (especially problematic on Github;
> I've not noticed GitLab collecting so eagerly)

That's the sort of thing I was talking about for ensuring all the versions 
of every pull request remain available - it doesn't need anything more 
than providing such refs (that someone can get with git clone --mirror if 
they wish).  (And there has been and is work on ensure git scales well to 
repositories with millions of refs, such as you get with PR-based systems 
storing all PRs or all versions of PRs as refs.)

-- 
Joseph S. Myers
josmy...@redhat.com

Re: Updated Sourceware infrastructure plans

[Joseph Myers via Gcc]

On Thu, 2 May 2024, Fangrui Song wrote:

> > On the other hand, GitHub structures the concept of pull requests 
> > around branches and enforces a branch-centric workflow. A pull request 
> > centers on the difference (commits) between the base branch and the 
> > feature branch. GitHub does not employ a stable identifier for commit 
> > tracking. If commits are rebased, reordered, or combined, GitHub can 
> > easily become confused.

I'd say we have two kinds of patch submission (= two kinds of pull request 
in a pull request workflow) to consider in the toolchain, and it's 
important that a PR-based system supports both of them well (and supports 
a submission changing from one kind to the other, and preferably 
dependencies between multiple PRs where appropriate).

* Simple submissions that are intended to end up as a single commit on the 
mainline (squash merge).  The overall set of changes to be applied to the 
mainline is subject to review, and the commit message also is subject to 
review (review of commit messages isn't always something that PR-based 
systems seem to handle that well).  But for the most part there isn't a 
need to rebase these - fixes as a result of review can go as subsequent 
commits on the source branch (making it easy to review either the 
individual fixes, or the whole updated set of changes), and merging from 
upstream into that branch is also OK.  (If there *is* a rebase, the 
PR-based system should still preserve the history of and comments on 
previous versions, avoid GCing them and avoid getting confused.)

* Complicated submissions of patch series, that are intended to end up as 
a sequence of commits on the mainline (non-squash merge preserving the 
sequence of commits).  In this case, fixes (or updating from upstream) 
*do* involve rebases to show what the full new sequence of commits should 
be (and all individual commits and their commit messages should be subject 
to review, not just the overall set of changes to be applied).  Again, 
rebases need handling by the system in a history-preserving way.

GitHub (as an example - obviously not appropriate itself for the 
toolchain) does much better on simple submissions (either with squash 
merges, or with merges showing the full history if you don't care about a 
clean bisectable history), apart from review of commit messages, than it 
does on complicated submissions or dependencies between PRs (I think 
systems sometimes used for PR dependencies on GitHub may actually be 
third-party add-ons).

Pull request systems have obvious advantages over mailing lists for 
tracking open submissions - but it's still very easy for an active project 
to end up with thousands of open PRs, among which it's very hard to find 
anything.

-- 
Joseph S. Myers
josmy...@redhat.com

Re: [PATCH] libcpp: Adjust __STDC_VERSION__ for C23

[Joseph Myers]

On Thu, 25 Apr 2024, Jakub Jelinek wrote:

> Hi!
> 
> While the C23 standard isn't officially release yet,
> in 2011 we've changed __STDC_VERSION__ value for C11 already
> in the month in which the new __STDC_VERSION__ value has been
> finalized, so we want to change this now or wait
> until we implement all the C23 features?
> 
> Note, seems Clang up to 17 also used 202000L for -std=c2x but
> Clang 18+ uses 202311L as specified in the latest C23 drafts.
> 
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for
> trunk?

In the spirit of the principle that these macros indicate intent rather 
than completeness, it's probably reasonable to change now.  The main 
missing feature still to be implemented is #embed, hopefully we can get 
that done for GCC 15.

-- 
Joseph S. Myers
josmy...@redhat.com

Re: [RISC-V] Support for trapping math in RISC-V

[Joseph Myers via Gcc]

On Wed, 24 Apr 2024, Krishna Narayanan via Gcc wrote:

> Hi all,
> Is the RISC-V community planning to add support for trapping math in RISC-V
> in the near future!?
> This LLVM thread
> https://discourse.llvm.org/t/trapping-math-for-risc-v/72168/7  suggests a
> software emulation of traps, is the GNU team also on similar lines to this
> implementation or has some different views.

That strategy sounds both very slow and not even complete (it doesn't 
cover the case of exact underflow, which doesn't raise the exception flag, 
but should signal the exception when trapping is enabled).

Traps are not part of standard C.  I'm not aware of any implementations of 
the TS 18661-5 interfaces to alternate exception handling either.

-- 
Joseph S. Myers
josmy...@redhat.com

Re: [PATCH] libgcc: Do use weakrefs for glibc 2.34 on GNU Hurd

[Joseph Myers]

On Mon, 29 Apr 2024, Jakub Jelinek wrote:

> On Mon, Apr 29, 2024 at 01:44:24PM +0000, Joseph Myers wrote:
> > > glibc 2.34 and later doesn't have separate libpthread (libpthread.so.0 is 
> > > a
> > > dummy shared library with just some symbol versions for compatibility, but
> > > all the pthread_* APIs are in libc.so.6).
> > 
> > I suspect this has caused link failures in the glibc testsuite for Hurd, 
> > which still has separate libpthread.
> > 
> > https://sourceware.org/pipermail/libc-testresults/2024q2/012556.html
> 
> So like this then?  I can't really test it on Hurd, but will certainly
> test on x86_64-linux/i686-linux.
> 
> 2024-04-29  Jakub Jelinek  
> 
>   * gthr.h (GTHREAD_USE_WEAK): Don't redefine to 0 for glibc 2.34+
>   on GNU Hurd.

Yes, this fixes the problem seem for Hurd with build-many-glibcs.py.

-- 
Joseph S. Myers
josmy...@redhat.com

Re: [PATCH] libgcc: Don't use weakrefs for glibc 2.34

[Joseph Myers]

On Thu, 25 Apr 2024, Jakub Jelinek wrote:

> Hi!
> 
> glibc 2.34 and later doesn't have separate libpthread (libpthread.so.0 is a
> dummy shared library with just some symbol versions for compatibility, but
> all the pthread_* APIs are in libc.so.6).

I suspect this has caused link failures in the glibc testsuite for Hurd, 
which still has separate libpthread.

https://sourceware.org/pipermail/libc-testresults/2024q2/012556.html

-- 
Joseph S. Myers
josmy...@redhat.com

Re: [RFC][PATCH v1 2/4] C and C++ FE changes to support flexible array members in unions and alone in structures.

[Joseph Myers]

On Fri, 19 Apr 2024, Qing Zhao wrote:

> gcc/c/ChangeLog:
> 
>   * c-decl.cc (finish_struct): Change errors to pedwarns for the cases
>   flexible array members in union or alone in structures.

The C front-end changes are OK for GCC 15 once everything else in the 
series is ready for inclusion (in particular, the testsuite changes).

-- 
Joseph S. Myers
josmy...@redhat.com

Re: [RFC][PATCH v1 1/4] Documentation change

[Joseph Myers]

On Tue, 23 Apr 2024, Qing Zhao wrote:

> However, I am not very confident on the wording of the doc, is the 
> current wording good enough for this? Or do you have any suggestion on 
> how to make it better?

I'm not convinced the statement about size (in relation to a structure 
with the member omitted) is useful for unions the way it is for 
structures.  The structure with the member omitted is a relevant concept 
for thinking about a structure with a flexible array member (the flexible 
array member essentially goes after that structure); it's much less 
relevant for thinking about a union with a flexible array member.

(The statement that the size is zero when all members are flexible array 
members still seems a useful one to make.)

-- 
Joseph S. Myers
josmy...@redhat.com

Re: [RFC][PATCH v1 3/4] Add testing cases for flexible array members in unions and alone in structures.

[Joseph Myers]

On Fri, 19 Apr 2024, Qing Zhao wrote:

> gcc/testsuite/ChangeLog:
> 
>   * gcc.dg/flex-array-in-union-1.c: New test.
>   * gcc.dg/flex-array-in-union-2.c: New test.

There should also be a -pedantic-errors test that these constructs get 
errors with -pedantic-errors.

The tests mix two cases: flexible arrays in unions, and flexible arrays on 
their own in structures.  That means the test names are misleading; either 
they should be renamed, or the struct tests should be split out.

Note that "no named members" also includes the case where there are 
unnamed bit-fields together with a flexible array member, so that should 
be tested as well.

Since this patch series involves changes for both C and C++, it would be 
best for the tests to be c-c++-common tests.  But if that's problematic 
for some reason - if there's still too much difference in behavior between 
C and C++ - then there should at least be tests for C++ that are as 
similar as possible to the tests for C.

-- 
Joseph S. Myers
josmy...@redhat.com

Re: [RFC][PATCH v1 1/4] Documentation change

[Joseph Myers]

On Fri, 19 Apr 2024, Qing Zhao wrote:

> +The size of the union is as if the flexiable array member were omitted
> +except that it may have more trailing padding than the omission would imply.

"trailing padding" is more a concept for structures than for unions (where 
padding depends on which union member is active).  But I suppose it's 
still true that the union can be larger than without the flexible member, 
because of alignment considerations.

union u { char c; int a[]; };

needs to be sufficiently aligned for int, which means the size is a 
multiple of the size of int, whereas if the flexible array member weren't 
present, the size could be 1 byte.

-- 
Joseph S. Myers
josmy...@redhat.com

Re: [PATCH v9 1/5] Provide counted_by attribute to flexible array member field (PR108896)

[Joseph Myers]

This version of patch 1/5 is OK for GCC 15.

-- 
Joseph S. Myers
josmy...@redhat.com

Re: Updated Sourceware infrastructure plans

[Joseph Myers via Gcc]

On Mon, 22 Apr 2024, Mark Wielaard wrote:

> >   A system that uses git as the source of 
> > truth for all the pull request data and has refs through which all this 
> > can be located (with reasonably straightforward, documented formats for 
> > the data, not too closely tied to any particular implementation of a 
> > pull-request system), so that a single clone --mirror has all the data, 
> > might be suitable (people have worked on ensuring git scales well with 
> > very large numbers of refs, which you'd probably get in such a system 
> > storing all the data in git);
> 
> Yes, git is pretty nice for storing lots of variants of somewhat
> identical sources/texts. But this also seems to imply that when we
> offer a system to store "contributor" git trees/forks of projects to
> easily create "pull requests" then we can never remove such users/forks
> and must disallow rebasing any trees that have been "submitted".

For example, GitHub has some version of the source branch for a pull 
request under refs/pull/ in the target respository - that doesn't rely on 
the source branch or repository staying around.  However, that's only one 
version - it doesn't work so well when the source branch is rebased 
(though GitHub itself is reported to keep all forks of a repository in a 
single repository internally, rarely garbage collected, so the previous 
versions probably remain there, just not accessible from any ref).  But 
you could certainly have a convention for ref naming that ensures all 
versions of a PR are available even when it's rebased.  Things like the 
"git evolve" proposal  could also be 
relevant (maybe that particular proposal wasn't intended for the goal of 
ensuring all submitted versions of a change remain permanently available, 
but at least it's dealing with a similar problem - and the more you have a 
standard way of representing this kind of information in git, rather than 
something very specific to a particular system built on top of git, the 
better).

-- 
Joseph S. Myers
josmy...@redhat.com

Re: [PATCH] c-family: Allow arguments with NULLPTR_TYPE as sentinels [PR114780]

[Joseph Myers]

On Fri, 19 Apr 2024, Jakub Jelinek wrote:

> Ok for trunk and later 13.3 if it passes bootstrap/regtest (so far just
> checked on the sentinel related C/C++ tests)?
> 
> 2024-04-19  Jakub Jelinek  
> 
>   PR c/114780
>   * c-common.cc (check_function_sentinel): Allow as sentinel any
>   argument of NULLPTR_TYPE.
> 
>   * gcc.dg/format/sentinel-2.c: New test.

OK.

-- 
Joseph S. Myers
josmy...@redhat.com

Re: [PATCH] c, v3: Fix ICE with -g and -std=c23 related to incomplete types [PR114361]

[Joseph Myers]

On Mon, 15 Apr 2024, Jakub Jelinek wrote:

> 2024-04-15  Martin Uecker  
>   Jakub Jelinek  
> 
>   PR lto/114574
>   PR c/114361
> gcc/c/
>   * c-decl.cc (shadow_tag_warned): For flag_isoc23 and code not
>   ENUMERAL_TYPE use SET_TYPE_STRUCTURAL_EQUALITY.
>   (parser_xref_tag): Likewise.
>   (start_struct): For flag_isoc23 use SET_TYPE_STRUCTURAL_EQUALITY.
>   (c_update_type_canonical): New function.
>   (finish_struct): Put NULL as second == operand rather than first.
>   Assert TYPE_STRUCTURAL_EQUALITY_P.  Call c_update_type_canonical.
>   * c-typeck.cc (composite_type_internal): Use
>   SET_TYPE_STRUCTURAL_EQUALITY.  Formatting fix.
> gcc/testsuite/
>   * gcc.dg/pr114574-1.c: New test.
>   * gcc.dg/pr114574-2.c: New test.
>   * gcc.dg/pr114361.c: New test.
>   * gcc.dg/c23-tag-incomplete-1.c: New test.
>   * gcc.dg/c23-tag-incomplete-2.c: New test.

OK.

-- 
Joseph S. Myers
josmy...@redhat.com

[gcc r14-10042] Update gcc sv.po

[Joseph Myers via Gcc-cvs]

https://gcc.gnu.org/g:e8f0540f23762ca155fe9ed70d6adb864be096b5

commit r14-10042-ge8f0540f23762ca155fe9ed70d6adb864be096b5
Author: Joseph Myers 
Date:   Fri Apr 19 20:02:56 2024 +

Update gcc sv.po

* sv.po: Update.

Diff:
---
 gcc/po/sv.po | 785 +++
 1 file changed, 195 insertions(+), 590 deletions(-)

diff --git a/gcc/po/sv.po b/gcc/po/sv.po
index d8a55cf55d3..32e63d610ac 100644
--- a/gcc/po/sv.po
+++ b/gcc/po/sv.po
@@ -32,7 +32,7 @@ msgstr ""
 "Project-Id-Version: gcc 14.1-b20240218\n"
 "Report-Msgid-Bugs-To: https://gcc.gnu.org/bugs/\n;
 "POT-Creation-Date: 2024-02-16 21:35+\n"
-"PO-Revision-Date: 2024-04-02 09:51+0200\n"
+"PO-Revision-Date: 2024-04-10 22:53+0200\n"
 "Last-Translator: Göran Uddeborg \n"
 "Language-Team: Swedish \n"
 "Language: sv\n"
@@ -62421,10 +62421,9 @@ msgid "%<#pragma omp assumes%> may only be used at 
file or namespace scope"
 msgstr "%<#pragma omp assumes%> kan endast användas med fil- eller 
namnrymdsräckvidd"
 
 #: cp/parser.cc:51053
-#, fuzzy, gcc-internal-format
-#| msgid "%<#pragma GCC ivdep%> must be inside a function"
+#, gcc-internal-format
 msgid "%<#pragma GCC %s%> must be inside a function"
-msgstr "%<#pragma GCC ivdep%> måste vara inuti en funktion"
+msgstr "%<#pragma GCC %s%> måste vara inuti en funktion"
 
 #: cp/parser.cc:51195
 #, gcc-internal-format
@@ -63989,16 +63988,14 @@ msgid "  since %q+#D declared in base class"
 msgstr "  eftersom %q+#D är deklarerad i basklassen"
 
 #: cp/search.cc:2281
-#, fuzzy, gcc-internal-format
-#| msgid "virtual function %q+D overriding final function"
+#, gcc-internal-format
 msgid "explicit object member function overrides virtual function"
-msgstr "virtuell funktion %q+D åsidosätter slutlig funktion"
+msgstr "en explicit objektmedlemsfunktion åsidosätter en virtuell funktion"
 
 #: cp/search.cc:2284
-#, fuzzy, gcc-internal-format
-#| msgid "resolver indirect function declared here"
+#, gcc-internal-format
 msgid "virtual function declared here"
-msgstr "upplösning av indirekt funktion deklarerad här"
+msgstr "den virtuella funktionen deklarerad här"
 
 #: cp/semantics.cc:1109
 #, gcc-internal-format
@@ -64081,22 +64078,19 @@ msgid "arguments to destructor are not allowed"
 msgstr "argument till destruerare är inte tillåtet"
 
 #: cp/semantics.cc:3175
-#, fuzzy, gcc-internal-format
-#| msgid "% is unavailable for static member functions"
+#, gcc-internal-format
 msgid "% is unavailable for explicit object member functions"
-msgstr "% är inte tillgängligt i en statisk medlemsfunktion"
+msgstr "% är inte tillgängligt i explicita objektmedlemsfunktioner"
 
 #: cp/semantics.cc:3187
-#, fuzzy, gcc-internal-format
-#| msgid "use the apostrophe directive %qs instead"
+#, gcc-internal-format
 msgid "use explicit object parameter %qs instead"
-msgstr "använd apostrofdirektivet %qs istället"
+msgstr "använd en explicit objektparameter %qs istället"
 
 #: cp/semantics.cc:3191
-#, fuzzy, gcc-internal-format
-#| msgid "invalid template non-type parameter"
+#, gcc-internal-format
 msgid "name the explicit object parameter"
-msgstr "ogiltig mallparameter som inte är en typ"
+msgstr "namnge den explicita objektdparametern"
 
 #: cp/semantics.cc:3196
 #, gcc-internal-format
@@ -64255,10 +64249,9 @@ msgid "%qT is not an enumeration type"
 msgstr "%qT är inte ett uppräkningstyp"
 
 #: cp/semantics.cc:4650
-#, fuzzy, gcc-internal-format
-#| msgid "requested alignment is not an integer constant"
+#, gcc-internal-format
 msgid "%<__type_pack_element%> index is not an integral constant"
-msgstr "begärd minnesjustering är inte en heltalskonstant"
+msgstr "indexet till %<__type_pack_element%> är inte en heltalskonstant"
 
 #: cp/semantics.cc:4656
 #, gcc-internal-format
@@ -64266,10 +64259,9 @@ msgid "%<__type_pack_element%> index is negative"
 msgstr "indexet till %<__type_pack_element%> är negativt"
 
 #: cp/semantics.cc:4662
-#, fuzzy, gcc-internal-format
-#| msgid "Reference statement index out of range"
+#, gcc-internal-format
 msgid "%<__type_pack_element%> index is out of range"
-msgstr "Referenssatsindex utanför intervallet"
+msgstr "indexet till %<__type_pack_element%> är utanför intervallet"
 
 #. Parameter packs can only be used in templates
 #: cp/semantics.cc:4785
@@ -64303,10 +64295,9 @@ msgid "% within non-standard-layout type 
%qT is conditionally-support
 msgstr "% inom

Re: Updated Sourceware infrastructure plans

[Joseph Myers via Gcc]

On Thu, 18 Apr 2024, Frank Ch. Eigler via Gcc wrote:

> Hi -
> 
> > [...]  I suggest that a basic principle for such a system is that it
> > should be *easy* to obtain and maintain a local copy of the history
> > of all pull requests.  That includes all versions of a pull request,
> > if it gets rebased, and all versions of comments, if the system
> > allows editing comments.  A system that uses git as the source of
> > truth for all the pull request data and has refs [...]
> 
> Do you know of a system with these characteristics?

I haven't studied the features supported by different systems, though (for 
example) there are some discussions in comments on 
https://lwn.net/Articles/867956/ of various systems.

-- 
Joseph S. Myers
josmy...@redhat.com

Re: Updated Sourceware infrastructure plans

[Joseph Myers via Gcc]

On Thu, 18 Apr 2024, Mark Wielaard wrote:

> But we like to get more feedback on what people really think a
> "pull-request" style framework should look like. We used to have a
> gerrit setup which wasn't really popular. And we already have a
> sourcehut mirror that can be used to turn your "pull-requests" into a
> git send-email style submission (without having to setup any
> email/smtp yourself): https://sr.ht/~sourceware/

The xz backdoor showed up one issue with some implementations of 
pull-request systems: GitHub removed access to the repository, and with it 
access to the past pull requests, so disrupting investigation into the 
sequence of bad-faith contributions.  I suggest that a basic principle for 
such a system is that it should be *easy* to obtain and maintain a local 
copy of the history of all pull requests.  That includes all versions of a 
pull request, if it gets rebased, and all versions of comments, if the 
system allows editing comments.  A system that uses git as the source of 
truth for all the pull request data and has refs through which all this 
can be located (with reasonably straightforward, documented formats for 
the data, not too closely tied to any particular implementation of a 
pull-request system), so that a single clone --mirror has all the data, 
might be suitable (people have worked on ensuring git scales well with 
very large numbers of refs, which you'd probably get in such a system 
storing all the data in git); a system that requires use of rate-limited 
APIs to access pull request data, not designed for maintaining such a 
local copy, rather less so.

There are some other considerations as well, such as ensuring the proposed 
commit message is just as much subject to review as the proposed code 
changes, and allowing both pull requests that propose a single commit 
(with subsequent fixups in the PR branch intended to be squashed) and pull 
requests that propose a series of commits (where fixups found in the 
review process need to be integrated into the relevant individual commit 
and the branch rebased before merge).

-- 
Joseph S. Myers
josmy...@redhat.com

Re: Deprecation/removal of nios2 target support

[Joseph Myers via Gcc]

On Wed, 17 Apr 2024, Sandra Loosemore wrote:

> Therefore I'd like to mark Nios II as obsolete in GCC 14 now, and remove
> support from all toolchain components after the release is made.  I'm not sure
> there is an established process for obsoleting/removing support in other
> components; besides binutils, GDB, and GLIBC, there's QEMU, newlib/libgloss,
> and the Linux kernel.  But, we need to get the ball rolling somewhere.

CC:ing Arnd Bergmann regarding the obsolescence in the Linux kernel.

-- 
Joseph S. Myers
josmy...@redhat.com

Re: [PATCH v8 1/5] Provide counted_by attribute to flexible array member field (PR108896)

[Joseph Myers]

On Wed, 10 Apr 2024, Qing Zhao wrote:

> Okay, the above is very clear, thanks a lot for the explanation.
> So, basically, for “counted-by” attribute:
> **The following is good:
> struct f { 
>   int b;
>   int c;
>   int a[]  __attribute__ ((counted_by (b))) };
> struct f {
>   int b;
>   int c;
>   int a[] __attribute__ ((counted_by (b))) };
> 
> **The following should error:
> 
> struct f { 
>   int b;
>   int c;
>   int a[]  __attribute__ ((counted_by (b))) };
> struct f {
>   int b;
>   int c;
>   int a[] __attribute__ ((counted_by (c))) };  /* error here */
> 
> For the same tag in different scopes case:
> 
> struct f { 
>   int b;
>   int c;
>   int a[]  __attribute__ ((counted_by (b))) }  y0;
> 
> void test1(void) 
> {   
> struct f {
>   int b;
>   int c;
>   int a[] __attribute__ ((counted_by (c))) } x;
> 
>   y0 = x;  /* will report incompatible type error here */
> }
> 
> Are the above complete?

Yes, that looks like what should be tested (with the addition of the case 
of same tag, different scopes, same counted_by so compatible).

-- 
Joseph S. Myers
josmy...@redhat.com

Re: [PATCH v8 1/5] Provide counted_by attribute to flexible array member field (PR108896)

[Joseph Myers]

On Wed, 10 Apr 2024, Qing Zhao wrote:

> A stupid question first, the same scope means the same file? (Or same 
> function)

struct X { int a; };
struct X { int a; };

is an example of the same scope (file scope, in this case).  The 
structures must have the same contents (in an appropriate sense) and are 
then considered the same type.

struct X { int a; };
void f() { struct X { int a; }; }

is not the same scope - but C23 makes the types compatible (not the same).  
It's OK to have incompatible types with the same tag in different scopes 
as well

struct X { int a; };
void f() { struct X { long b; }; }

but if you use them in a way requiring compatibility, then the contents 
must be compatible

struct X { int a; } v;
void f() { struct X { int a; } *p =  }

> Is there a testing case for this feature in current GCC source tree I can 
> take a look? (and
> Then I can use it to construct the new testing case for the counted-by 
> attribute).

See gcc.dg/c23-tag-*.c for many tests of different cases involving the tag 
compatibility rules (and gcc.dg/gnu23-tag-* where GNU extensions are 
involved).

-- 
Joseph S. Myers
josmy...@redhat.com

Re: [PATCH v8 5/5] Add the 6th argument to .ACCESS_WITH_SIZE

[Joseph Myers]

The C front-end changes in this patch are OK for GCC 15.

-- 
Joseph S. Myers
josmy...@redhat.com

Re: [PATCH v8 2/5] Convert references with "counted_by" attributes to/from .ACCESS_WITH_SIZE.

[Joseph Myers]

On Fri, 29 Mar 2024, Qing Zhao wrote:

> +/* For a SUBDATUM field of a structure or union DATUM, generate a REF to
> +   the object that represents its counted_by per the attribute counted_by
> +   attached to this field if it's a flexible array member field, otherwise
> +   return NULL_TREE.
> +   set COUNTED_BY_TYPE to the TYPE of the counted_by field.

Use an uppercase letter at the start of a sentence, "Set".

> +static tree
> +build_counted_by_ref (tree datum, tree subdatum, tree *counted_by_type)
> +{
> +  tree type = TREE_TYPE (datum);
> +  if (!(c_flexible_array_member_type_p (TREE_TYPE (subdatum
> +return NULL_TREE;

There are redundant parentheses here around the call to 
c_flexible_array_member_type_p.

The C front-end changes in this patch are OK for GCC 15 (after GCC 14 has 
branched, and once a version of patch 1 has also been approved) with those 
fixes.

-- 
Joseph S. Myers
josmy...@redhat.com

Re: [PATCH v8 4/5] Use the .ACCESS_WITH_SIZE in bound sanitizer.

[Joseph Myers]

The C front-end changes in this patch are OK for GCC 15.

-- 
Joseph S. Myers
josmy...@redhat.com

Re: [PATCH v8 1/5] Provide counted_by attribute to flexible array member field (PR108896)

[Joseph Myers]

On Fri, 29 Mar 2024, Qing Zhao wrote:

> +  /* Issue error when there is a counted_by attribute with a different
> + field as the argument for the same flexible array member field.  */

There's another case of this to consider, though I'm not sure where best 
to check for it (Martin might have suggestions) - of course this case will 
need testcases as well.

Suppose, as allowed in C23, a structure is defined twice in the same 
scope, but the two definitions of the structure use inconsistent 
counted_by attributes.  I'd say that, when the declarations are in the 
same scope (thus required to be consistent), it should be an error for the 
two definitions of what is meant to be the same structure to use 
incompatible counted_by attributes (even though the member declarations 
are otherwise the same).

In C23 structures defined with the same tag in different scopes are 
compatible given requirements including compatible types for corresponding 
elements.  It would seem most appropriate to me for such structures with 
incompatible counted_by attributes to be considered *not* compatible types 
(but it would be valid to define structures with the same tag, different 
scopes, and elements the same except for counted_by - just not to use them 
in any way requiring them to be compatible).

> +The @code{counted_by} attribute may be attached to the C99 flexible array
> +member of a structure.  It indicates that the number of the elements of the
> +array is given by the field "@var{count}" in the same structure as the

As noted previously, the "" quotes should be removed there (or replaced by 
``'' quotes).

-- 
Joseph S. Myers
josmy...@redhat.com

[committed] wwwdocs: gcc-14: Add release notes for C23 features

[Joseph Myers]

Add release notes for C23 features added in GCC 14.  This doesn't
cover any non-C23 new C features; any such features should also have
release notes added.

diff --git a/htdocs/gcc-14/changes.html b/htdocs/gcc-14/changes.html
index 934cd1ad..045893cf 100644
--- a/htdocs/gcc-14/changes.html
+++ b/htdocs/gcc-14/changes.html
@@ -206,6 +206,31 @@ a work-in-progress.
 
 
 
+C
+
+
+  Some more C23 features have been implemented:
+
+  Bit-precise integer types (_BitInt (N)
+  and unsigned _BitInt (N)): integer types with
+  a specified number of bits.  These are only supported on
+  IA-32/x86-64 at present.
+  Structure, union and enumeration types may be defined more
+  than once in the same scope with the same contents and the same
+  tag; if such types are defined with the same contents and the
+  same tag in different scopes, the types are compatible.
+  The stdckdint.h header for checked
+  integer arithmetic.
+
+  
+  In addition to those C23 features, there are new command-line
+  options -std=c23, -std=gnu23
+  and -Wc11-c23-compat.  These are equivalent to the
+  previous options -std=c2x, -std=gnu2x
+  and -Wc11-c2x-compat, which are deprecated but remain
+  supported.
+
+
 C++
 
 

-- 
Joseph S. Myers
josmy...@redhat.com

gcc-wwwdocs branch master updated. 6eeeb6a53c2e57e3f02f97da176589cf15877247

[Joseph Myers 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  6eeeb6a53c2e57e3f02f97da176589cf15877247 (commit)
  from  a33ad5c5681a0ce2dfba0a90b4043f399b7a7d55 (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 6eeeb6a53c2e57e3f02f97da176589cf15877247
Author: Joseph Myers 
Date:   Thu Apr 4 17:04:33 2024 +

gcc-14: Add release notes for C23 features

Add release notes for C23 features added in GCC 14.  This doesn't
cover any non-C23 new C features; any such features should also have
release notes added.

diff --git a/htdocs/gcc-14/changes.html b/htdocs/gcc-14/changes.html
index 934cd1ad..045893cf 100644
--- a/htdocs/gcc-14/changes.html
+++ b/htdocs/gcc-14/changes.html
@@ -206,6 +206,31 @@ a work-in-progress.
 
 
 
+C
+
+
+  Some more C23 features have been implemented:
+
+  Bit-precise integer types (_BitInt (N)
+  and unsigned _BitInt (N)): integer types with
+  a specified number of bits.  These are only supported on
+  IA-32/x86-64 at present.
+  Structure, union and enumeration types may be defined more
+  than once in the same scope with the same contents and the same
+  tag; if such types are defined with the same contents and the
+  same tag in different scopes, the types are compatible.
+  The stdckdint.h header for checked
+  integer arithmetic.
+
+  
+  In addition to those C23 features, there are new command-line
+  options -std=c23, -std=gnu23
+  and -Wc11-c23-compat.  These are equivalent to the
+  previous options -std=c2x, -std=gnu2x
+  and -Wc11-c2x-compat, which are deprecated but remain
+  supported.
+
+
 C++
 
 

---

Summary of changes:
 htdocs/gcc-14/changes.html | 25 +
 1 file changed, 25 insertions(+)


hooks/post-receive
-- 
gcc-wwwdocs

[gcc r14-9778] Update gcc sv.po

[Joseph Myers via Gcc-cvs]

https://gcc.gnu.org/g:f37555028717cb1454ee258afdf68aea1c7a50e9

commit r14-9778-gf37555028717cb1454ee258afdf68aea1c7a50e9
Author: Joseph Myers 
Date:   Wed Apr 3 20:47:47 2024 +

Update gcc sv.po

* sv.po: Update.

Diff:
---
 gcc/po/sv.po | 203 ---
 1 file changed, 82 insertions(+), 121 deletions(-)

diff --git a/gcc/po/sv.po b/gcc/po/sv.po
index 514eb7c764a..d8a55cf55d3 100644
--- a/gcc/po/sv.po
+++ b/gcc/po/sv.po
@@ -32,7 +32,7 @@ msgstr ""
 "Project-Id-Version: gcc 14.1-b20240218\n"
 "Report-Msgid-Bugs-To: https://gcc.gnu.org/bugs/\n;
 "POT-Creation-Date: 2024-02-16 21:35+\n"
-"PO-Revision-Date: 2024-03-24 12:59+0100\n"
+"PO-Revision-Date: 2024-04-02 09:51+0200\n"
 "Last-Translator: Göran Uddeborg \n"
 "Language-Team: Swedish \n"
 "Language: sv\n"
@@ -54589,16 +54589,14 @@ msgid "import declared %q#D here"
 msgstr "importdeklarerad %q#D här"
 
 #: cp/decl.cc:2306 cp/decl.cc:16628
-#, fuzzy, gcc-internal-format
-#| msgid "conflicting exporting declaration %qD"
+#, gcc-internal-format
 msgid "conflicting exporting for declaration %qD"
-msgstr "motstridande exporterande deklaration av %qD"
+msgstr "motstridande exporterande för deklaration av %qD"
 
 #: cp/decl.cc:2308 cp/decl.cc:16630
-#, fuzzy, gcc-internal-format
-#| msgid "previously declared here"
+#, gcc-internal-format
 msgid "previously declared here without exporting"
-msgstr "tidigare deklarerad här"
+msgstr "tidigare deklarerad här utan att exporteras"
 
 #: cp/decl.cc:2335
 #, gcc-internal-format
@@ -54781,16 +54779,14 @@ msgid "  enters % statement"
 msgstr "  går in i %-sats"
 
 #: cp/decl.cc:3829 cp/decl.cc:4003
-#, fuzzy, gcc-internal-format
-#| msgid "ISO C99 does not support %qE"
+#, gcc-internal-format
 msgid "  does not destroy %qD"
-msgstr "ISO C99 stödjer inte %qE"
+msgstr "  förstör inte %qD"
 
 #: cp/decl.cc:3831 cp/decl.cc:3986
-#, fuzzy, gcc-internal-format
-#| msgid "%s does not take any feature options"
+#, gcc-internal-format
 msgid "  does not clean up handled exception"
-msgstr "%s tar inte några funktionsflaggor"
+msgstr "  städar inte upp det hanterade undantaget"
 
 #: cp/decl.cc:3922
 #, gcc-internal-format
@@ -55631,10 +55627,9 @@ msgid "constraints on a non-templated function"
 msgstr "begränsning av en funktion som inte är en mall"
 
 #: cp/decl.cc:10590
-#, fuzzy, gcc-internal-format
-#| msgid "friend declaration not in class definition"
+#, gcc-internal-format
 msgid "constrained non-template friend declaration must be a definition"
-msgstr "vändeklaration är inte i klassdefinition"
+msgstr "begränsad vändeklaration som inte är en mall måste vara en definition"
 
 #: cp/decl.cc:10597
 #, gcc-internal-format
@@ -55697,10 +55692,9 @@ msgid "static member function %qD cannot have 
cv-qualifier"
 msgstr "statisk medlemsfunktion %qD kan inte ha cv-kvalificerare"
 
 #: cp/decl.cc:10818
-#, fuzzy, gcc-internal-format
-#| msgid "static member function %qD cannot have cv-qualifier"
+#, gcc-internal-format
 msgid "explicit object member function %qD cannot have cv-qualifier"
-msgstr "statisk medlemsfunktion %qD kan inte ha cv-kvalificerare"
+msgstr "explicit objektmedlemsfunktion %qD kan inte ha cv-kvalificerare"
 
 #: cp/decl.cc:10823
 #, gcc-internal-format
@@ -55713,16 +55707,14 @@ msgid "static member function %qD cannot have 
ref-qualifier"
 msgstr "statisk medlemsfunktion %qD kan inte ha ref-kvalificerare"
 
 #: cp/decl.cc:10826
-#, fuzzy, gcc-internal-format
-#| msgid "static member function %qD cannot have ref-qualifier"
+#, gcc-internal-format
 msgid "explicit object member function %qD cannot have ref-qualifier"
-msgstr "statisk medlemsfunktion %qD kan inte ha ref-kvalificerare"
+msgstr "explicit objektmedlemsfunktion %qD kan inte ha ref-kvalificerare"
 
 #: cp/decl.cc:10832 cp/decl.cc:13715 cp/decl.cc:13725 cp/parser.cc:11972
-#, fuzzy, gcc-internal-format
-#| msgid "template parameter %qD declared here"
+#, gcc-internal-format
 msgid "explicit object parameter declared here"
-msgstr "mallparametern %qD deklarerad här"
+msgstr "explicit objektparameter deklarerad här"
 
 #: cp/decl.cc:10844
 #, gcc-internal-format
@@ -56304,31 +56296,27 @@ msgstr "onödiga parenteser i deklaration av %qs"
 #: cp/decl.cc:13277
 #, gcc-internal-format
 msgid "remove parentheses"
-msgstr "ta port parenteser"
+msgstr "ta bort parenteser"
 
 #: cp/decl.cc:13345
-#, fuzzy, gcc-internal-format
-#| msgid "alias templat

Re: [C PATCH] fix aliasing for structures/unions with incomplete types

[Joseph Myers]

On Tue, 2 Apr 2024, Martin Uecker wrote:

> Am Dienstag, dem 02.04.2024 um 20:42 + schrieb Joseph Myers:
> > On Tue, 2 Apr 2024, Martin Uecker wrote:
> > 
> > > [C23]fix aliasing for structures/unions with incomplete types
> > > 
> > > When incomplete structure/union types are completed later, compatibility
> > > of struct types that contain pointers to such types changes.  When forming
> > > equivalence classes for TYPE_CANONICAL, we therefor need to be 
> > > conservative
> > > and treat all structs with the same tag which are pointer targets as
> > > equivalent.
> > 
> > I don't see how what it done is actually about "which are pointer 
> > targets".
> 
> Right, I see now that the description needs to be improved. This refers
> only to targets of pointers included somewhere in the type we process
> for purposes of determining the equivalence class of this type (but
> not for other contexts).

A detailed self-contained description of the TYPE_CANONICAL / aliasing 
logic also needs to go somewhere in a comment in the source code rather 
than only in commit messages / emails.

-- 
Joseph S. Myers
josmy...@redhat.com

Re: [C PATCH] fix aliasing for structures/unions with incomplete types

[Joseph Myers]

On Tue, 2 Apr 2024, Martin Uecker wrote:

> [C23]fix aliasing for structures/unions with incomplete types
> 
> When incomplete structure/union types are completed later, compatibility
> of struct types that contain pointers to such types changes.  When forming
> equivalence classes for TYPE_CANONICAL, we therefor need to be conservative
> and treat all structs with the same tag which are pointer targets as
> equivalent.

I don't see how what it done is actually about "which are pointer 
targets".

> @@ -1355,6 +1356,7 @@ comptypes_internal (const_tree type1, const_tree type2,
>/* Do not remove mode information.  */
>if (TYPE_MODE (t1) != TYPE_MODE (t2))
>   return false;
> +  data->pointedto = true;
>return comptypes_internal (TREE_TYPE (t1), TREE_TYPE (t2), data);

This appears to be more like "which are the targets of pointers that *have 
just been compared in the present comptypes call*".  Not which are targets 
of some other pointers not involved in that call.

Maybe some such logic based only on pointers compared in the present call 
makes sense for some purposes, but it's not clear to me that either this 
or any similar approach is a good approach for TYPE_CANONICAL - couldn't 
that mean that two types are considered equivalent for TYPE_CANONICAL at 
one point in the translation unit, but no longer equivalent at some later 
point when the comparison takes place in the context of comparing two 
other pointer types?

-- 
Joseph S. Myers
josmy...@redhat.com

Re: [C PATCH] Fix ICE with -g and -std=c23 related to incomplete types [PR114361]

[Joseph Myers]

On Tue, 2 Apr 2024, Martin Uecker wrote:

> Fix ICE with -g and -std=c23 related to incomplete types [PR114361]
> 
> We did not copy TYPE_CANONICAL to the incomplete variants when
> completing a structure.
> 
> PR c/114361
> 
> gcc/c/
> * c-decl.c (finish_struct): Set TYPE_CANONICAL when completing
>   strucute types.
> 
> gcc/testsuite/
> * gcc.dg/pr114361.c: New test.
> * gcc.dg/c23-tag-incomplete-1.c: New test.
> * gcc.dg/c23-tag-incomplete-2.c: New test.

OK.

-- 
Joseph S. Myers
josmy...@redhat.com

Re: [PATCH] c-family: Cast __atomic_load_*/__atomic_exchange_* result to _BitInt rather then VCE it [PR114469]

[Joseph Myers]

On Wed, 27 Mar 2024, Jakub Jelinek wrote:

> Hi!
> 
> As written in the PR, torture/bitint-64.c test fails with -O2 -flto
> and the reason is that on _BitInt arches where the padding bits
> are undefined, the padding bits in the _Atomic vars are also undefined,
> but when __atomic_load or __atomic_exchange on a _BitInt _Atomic variable
> with some padding bits is lowered into __atomic_load_{1,2,4,8,16} or
> __atomic_exchange_*, the mode precision unsigned result is VIEW_CONVERT_EXPR
> converted to _BitInt and because of the VCE nothing actually sign/zero
> extends it as needed for later uses - the var is no longer addressable and
> expansion assumes such automatic vars are properly extended.
> 
> The following patch fixes that by using NOP_EXPR on it (the
> VIEW_CONVERT_EXPR after it will then be optimized away during
> gimplification, didn't want to repeat it in the code as else result = build1
> (VIEW_CONVERT_EXPR, ...); twice.
> 
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

This is OK.  A natural question arising is whether anything else might 
generate a VIEW_CONVERT_EXPR for code that somehow reinterprets memory as 
of type _BitInt, and then later fail to ensure required sign/zero 
extension, or whether this is the only place where a VIEW_CONVERT_EXPR of 
_BitInt type can cause problems.

-- 
Joseph S. Myers
josmy...@redhat.com

Re: [PATCH v7 1/5] Provide counted_by attribute to flexible array member field (PR108896)

[Joseph Myers]

On Tue, 26 Mar 2024, Qing Zhao wrote:

> > What happens when there are multiple counted_by attributes on the same 
> > field?  As far as I can see, all but one end up being ignored (by the code 
> > that actually uses the attribute).
> 
> In general, is there any rule for handling multiple same attributes in 
> GCC? i.e, from left to right, the last one wins? Or something else? I’d 
> like to following the consistent rule with other places in GCC.

Sometimes, they are meaningful and all can be respected.  (An example is 
the format_arg attribute, where ngettext legitimately has two such 
attributes.)

When not meaningful, an error is appropriate.  For example, with section 
attributes you can get

error ("section of %q+D conflicts with previous declaration",
   *node);

if different sections are named.  I think that's a suitable model for the 
new attribute here: allow duplicates if they name the same field, but give 
errors if they name different fields, just as with the section attribute.

Once you give an error for multiple attributes naming different fields, 
which one wins is just a question of error recovery; the specific choice 
doesn't matter much, as long as you don't get an ICE in later processing.

-- 
Joseph S. Myers
josmy...@redhat.com

Re: [PATCH v7 1/5] Provide counted_by attribute to flexible array member field (PR108896)

[Joseph Myers]

On Tue, 26 Mar 2024, Qing Zhao wrote:

> >> +@cindex @code{counted_by} variable attribute
> >> +@item counted_by (@var{count})
> >> +The @code{counted_by} attribute may be attached to the C99 flexible array
> >> +member of a structure.  It indicates that the number of the elements of 
> >> the
> >> +array is given by the field named "@var{count}" in the same structure as 
> >> the
> >> +flexible array member.
> > 
> > You shouldn't use ASCII quotes like that in Texinfo (outside @code etc. 
> > where they represent literal quotes in programming language source code).  
> > You can say ``@var{count}'' if you wish to quote the name.
> A little confused with the above..
> So, what should I change in the above statement?

I don't think you actually need quotes (or "named") at all; just

  the field @var{count}

in place of

  the field named "@var{count}"

would suffice.  But if you use quotes (for an English-language quotation, 
as opposed to when the quotes themselves are part of programming-language 
source code given in the manual), in Texinfo you should use ``'' rather 
than "".

-- 
Joseph S. Myers
josmy...@redhat.com

[gcc r13-8495] c: Fix ICE for nested enum redefinitions with/without fixed underlying type [PR112571]

[Joseph Myers via Gcc-cvs]

https://gcc.gnu.org/g:f2af129b68bc6b20f79a9a44b28c96650baa702c

commit r13-8495-gf2af129b68bc6b20f79a9a44b28c96650baa702c
Author: Joseph Myers 
Date:   Wed Jan 31 21:39:53 2024 +

c: Fix ICE for nested enum redefinitions with/without fixed underlying type 
[PR112571]

Bug 112571 reports an ICE-on-invalid for cases where an enum is
defined, without a fixed underlying type, inside the enum type
specifier for a definition of that same enum with a fixed underlying
type.

The ultimate cause is attempting to access ENUM_UNDERLYING_TYPE in a
case where it is NULL.  Avoid this by clearing
ENUM_FIXED_UNDERLYING_TYPE_P in thie case of inconsistent definitions.

Bootstrapped wth no regressions for x86_64-pc-linux-gnu.

(Note: for this GCC 13 branch backport, the tests were changed to use
-std=c2x not -std=c23, and c23-enum-9.c was changed to expect
different diagnostics because GCC 13 branch doesn't have the C23 tag
compatibility support for redefinitions of tagged types and
enumerators.)

PR c/112571

gcc/c/
* c-decl.cc (start_enum): Clear ENUM_FIXED_UNDERLYING_TYPE_P when
defining without a fixed underlying type an enumeration previously
declared with a fixed underlying type.

gcc/testsuite/
* gcc.dg/c23-enum-9.c, gcc.dg/c23-enum-10.c: New tests.

(cherry picked from commit d22d1a9346f27db41459738c6eb404f8f0956e6f)

Diff:
---
 gcc/c/c-decl.cc| 7 +--
 gcc/testsuite/gcc.dg/c23-enum-10.c | 6 ++
 gcc/testsuite/gcc.dg/c23-enum-9.c  | 8 
 3 files changed, 19 insertions(+), 2 deletions(-)

diff --git a/gcc/c/c-decl.cc b/gcc/c/c-decl.cc
index 1b53f2d0785..7dcb1141bf7 100644
--- a/gcc/c/c-decl.cc
+++ b/gcc/c/c-decl.cc
@@ -9587,8 +9587,11 @@ start_enum (location_t loc, struct c_enum_contents 
*the_enum, tree name,
 
   if (ENUM_FIXED_UNDERLYING_TYPE_P (enumtype)
   && fixed_underlying_type == NULL_TREE)
-error_at (loc, "% declared with but defined without "
- "fixed underlying type");
+{
+  error_at (loc, "% declared with but defined without "
+   "fixed underlying type");
+  ENUM_FIXED_UNDERLYING_TYPE_P (enumtype) = false;
+}
 
   the_enum->enum_next_value = integer_zero_node;
   the_enum->enum_type = enumtype;
diff --git a/gcc/testsuite/gcc.dg/c23-enum-10.c 
b/gcc/testsuite/gcc.dg/c23-enum-10.c
new file mode 100644
index 000..894893133a5
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/c23-enum-10.c
@@ -0,0 +1,6 @@
+/* PR c/112571.  */
+/* { dg-do compile } */
+/* { dg-options "-std=c2x" } */
+
+enum X : typeof (enum X { A }); /* { dg-error "declared with but defined 
without fixed underlying type" } */
+/* { dg-error "invalid 'enum' underlying type" "invalid" { target *-*-* } .-1 
} */
diff --git a/gcc/testsuite/gcc.dg/c23-enum-9.c 
b/gcc/testsuite/gcc.dg/c23-enum-9.c
new file mode 100644
index 000..b9a6afe0c77
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/c23-enum-9.c
@@ -0,0 +1,8 @@
+/* PR c/112571.  */
+/* { dg-do compile } */
+/* { dg-options "-std=c2x" } */
+
+enum h : typeof (enum h { D }) { D }; /* { dg-error "declared with but defined 
without fixed underlying type" } */
+/* { dg-error "invalid 'enum' underlying type" "invalid" { target *-*-* } .-1 
} */
+/* { dg-error "redeclaration of 'enum h'" "enumeration" { target *-*-* } .-2 } 
*/
+/* { dg-error "redeclaration of enumerator" "enumerator" { target *-*-* } .-3 
} */

Re: [PATCH v7 3/5] Use the .ACCESS_WITH_SIZE in builtin object size.

[Joseph Myers]

On Wed, 20 Mar 2024, Qing Zhao wrote:

> +   the size of the element can be retrived from the result type of the call,
> +   which is the pointer to the array type.  */

Again, start a sentence with an uppercase letter.

> +  /* if not for dynamic object size, return.  */

> +  /* result type is a pointer type to the original flexible array type.  */

Likewise.

-- 
Joseph S. Myers
josmy...@redhat.com

Re: [PATCH v7 2/5] Convert references with "counted_by" attributes to/from .ACCESS_WITH_SIZE.

[Joseph Myers]

On Wed, 20 Mar 2024, Qing Zhao wrote:

> +  /* get the TYPE of the counted_by field.  */

Start comments with an uppercase letter.

> +   The type of the first argument of this function is a POINTER type
> +   to the orignal flexible array type.

s/orignal/original/

> +   If HANDLE_COUNTED_BY is true, check the counted_by attribute and generate
> +   call to .ACCESS_WITH_SIZE. otherwise, ignore the attribute.  */

A sentence should start with an uppercase letter, "Otherwise".

> -  /* Ordinary case; arg is a COMPONENT_REF or a decl.  */
> +  /* Ordinary case; arg is a COMPONENT_REF or a decl,or a call to
> +  .ACCESS_WITH_SIZE.  */

There should be a space after a comma.

> +/* Get the corresponding reference from the call to a .ACCESS_WITH_SIZE.
> + * i.e the first argument of this call. return NULL_TREE otherwise.  */
> +extern tree get_ref_from_access_with_size (tree);

Again, start a sentence with an uppercase letter.

> +case CALL_EXPR:
> +  /* for a call to .ACCESS_WITH_SIZE, check the first argument.  */

Likewise.

> +  /* for a call to .ACCESS_WITH_SIZE, check the first argument.  */

Likewise.

-- 
Joseph S. Myers
josmy...@redhat.com

Re: [PATCH v7 1/5] Provide counted_by attribute to flexible array member field (PR108896)

[Joseph Myers]

On Wed, 20 Mar 2024, Qing Zhao wrote:

> +  /* This attribute only applies to a C99 flexible array member type.  */
> +  else if (! c_flexible_array_member_type_p (TREE_TYPE (decl)))
> +{
> +  error_at (DECL_SOURCE_LOCATION (decl),
> + "%qE attribute is not allowed for a non"
> + " flexible array member field",

"non-flexible" not "non flexible" ("non" shouldn't appear as a word on its 
own).

> +  /* Error when the field is not found in the containing structure.  */
> +  if (!counted_by_field)
> +error_at (DECL_SOURCE_LOCATION (field_decl),
> +   "Argument %qE to the %qE attribute is not a field declaration"
> +   " in the same structure as %qD", fieldname,

Diagnostics should start with a lowercase letter, "argument" not 
"Argument".

> +  if (TREE_CODE (TREE_TYPE (real_field)) != INTEGER_TYPE)
> + error_at (DECL_SOURCE_LOCATION (field_decl),
> +   "Argument %qE to the %qE attribute is not a field declaration"
> +   " with an integer type", fieldname,

Likewise.

Generally checks for integer types should allow any INTEGRAL_TYPE_P, 
rather than just INTEGER_TYPE.  For example, it should be valid to use 
this attribute with a field with _BitInt type.  (It would be fairly 
useless with a _BitInt larger than size_t, but maybe e.g. someone knows 
the size in their code must fit into 24 bits and so uses unsigned 
_BitInt(24) for the field.)

Of course there should be corresponding testcases for _Bool / enum / 
_BitInt count fields.

What happens when there are multiple counted_by attributes on the same 
field?  As far as I can see, all but one end up being ignored (by the code 
that actually uses the attribute).  I think multiple such attributes using 
different identifiers should be diagnosed, even if all the identifiers are 
indeed integer fields in the same structure - it doesn't seem meaningful 
to say that multiple fields give the count of elements.  (Multiple 
attributes with the *same* identifier are probably OK to allow; maybe that 
could arise in code using complicated macros that end up adding the 
attribute more than once.)

> +@cindex @code{counted_by} variable attribute
> +@item counted_by (@var{count})
> +The @code{counted_by} attribute may be attached to the C99 flexible array
> +member of a structure.  It indicates that the number of the elements of the
> +array is given by the field named "@var{count}" in the same structure as the
> +flexible array member.

You shouldn't use ASCII quotes like that in Texinfo (outside @code etc. 
where they represent literal quotes in programming language source code).  
You can say ``@var{count}'' if you wish to quote the name.

> +The field that represents the number of the elements should have an
> +integer type.  Otherwise, the compiler will report a warning and ignore
> +the attribute.
> +When the field that represents the number of the elements is assigned a
> +negative integer value, the compiler will treat the value as zero.

In general it's best for documentation to be in the present tense (so the 
compiler *reports* a warning rather than "will report", *treats* the value 
as zero rather than "will treat").

> +It's the user's responsibility to make sure the above requirements to
> +be kept all the time.  Otherwise the compiler will report warnings,
> +at the same time, the results of the array bound sanitizer and the
> +@code{__builtin_dynamic_object_size} is undefined.

Likewise.

-- 
Joseph S. Myers
josmy...@redhat.com

[gcc r14-9656] Update gcc sv.po

[Joseph Myers via Gcc-cvs]

https://gcc.gnu.org/g:18555b914316e8c1fb11ee821f2ee839d834e58e

commit r14-9656-g18555b914316e8c1fb11ee821f2ee839d834e58e
Author: Joseph Myers 
Date:   Mon Mar 25 18:28:48 2024 +

Update gcc sv.po

* sv.po: Update.

Diff:
---
 gcc/po/sv.po | 700 ---
 1 file changed, 279 insertions(+), 421 deletions(-)

diff --git a/gcc/po/sv.po b/gcc/po/sv.po
index 072bedbd9d5..514eb7c764a 100644
--- a/gcc/po/sv.po
+++ b/gcc/po/sv.po
@@ -32,7 +32,7 @@ msgstr ""
 "Project-Id-Version: gcc 14.1-b20240218\n"
 "Report-Msgid-Bugs-To: https://gcc.gnu.org/bugs/\n;
 "POT-Creation-Date: 2024-02-16 21:35+\n"
-"PO-Revision-Date: 2024-03-17 20:14+0100\n"
+"PO-Revision-Date: 2024-03-24 12:59+0100\n"
 "Last-Translator: Göran Uddeborg \n"
 "Language-Team: Swedish \n"
 "Language: sv\n"
@@ -40363,16 +40363,14 @@ msgid "either %<-fopenacc%> or %<-fopenmp%> must be 
set"
 msgstr "antingen %<-fopenacc%> eller %<-fopenmp%> måste vara satt"
 
 #: config/gcn/mkoffload.cc:1039
-#, fuzzy, gcc-internal-format
-#| msgid "unhandled expression"
+#, gcc-internal-format
 msgid "unhandled architecture"
-msgstr "ohanterat uttryck"
+msgstr "ohanterad arkitektur"
 
 #: config/gcn/mkoffload.cc:1079 config/gcn/mkoffload.cc:1231
-#, fuzzy, gcc-internal-format
-#| msgid "cannot open %s"
+#, gcc-internal-format
 msgid "cannot open %qs"
-msgstr "kan inte öppna %s"
+msgstr "kan inte öppna %qs"
 
 #: config/gcn/mkoffload.cc:1217 config/nvptx/mkoffload.cc:841
 #, gcc-internal-format
@@ -40729,16 +40727,14 @@ msgid "%<-mstringop-strategy=rep_8byte%> not 
supported for 32-bit code"
 msgstr "%<-mstringop-strategy=rep_8byte%> stödjs inte för 32-bitarskod"
 
 #: config/i386/i386-options.cc:2143
-#, fuzzy, gcc-internal-format
-#| msgid "%<-muintr%> not supported for 32-bit code"
+#, gcc-internal-format
 msgid "%<-mapxf%> is not supported for 32-bit code"
-msgstr "%<-muintr%> stödjs inte för 32-bitarskod"
+msgstr "%<-mapxf%> stödjs inte för 32-bitarskod"
 
 #: config/i386/i386-options.cc:2145
-#, fuzzy, gcc-internal-format
-#| msgid "%<-mlam=%> option: [u48|u57] not supported for 32-bit code"
+#, gcc-internal-format
 msgid "%<-mapx-features=%> option is not supported for 32-bit code"
-msgstr "%<-mlam=%> flaggan: [u48|u57] stödjs inte för 32-bitarskod"
+msgstr "flaggan %<-mapx-features=%>- stödjs inte för 32-bitarskod"
 
 #: config/i386/i386-options.cc:2148
 #, gcc-internal-format
@@ -41318,10 +41314,9 @@ msgid "the ABI of passing C structures with zero-width 
bit-fields has changed in
 msgstr "ABI:et för att skicka C-poster med bitfält med nollbredd har ändrats i 
GCC %{12.1%}"
 
 #: config/i386/i386.cc:2722 config/i386/i386.cc:4091 config/i386/i386.cc:4101
-#, fuzzy, gcc-internal-format
-#| msgid "SSE register return with SSE disabled"
+#, gcc-internal-format
 msgid "SSE register return with SSE2 disabled"
-msgstr "SSE-registerretur med SSE avaktiverat"
+msgstr "SSE-registerretur med SSE2 avaktiverat"
 
 #: config/i386/i386.cc:2724
 #, gcc-internal-format
@@ -41329,10 +41324,9 @@ msgid "SSE register return with SSE disabled"
 msgstr "SSE-registerretur med SSE avaktiverat"
 
 #: config/i386/i386.cc:2731
-#, fuzzy, gcc-internal-format
-#| msgid "SSE register argument with SSE disabled"
+#, gcc-internal-format
 msgid "SSE register argument with SSE2 disabled"
-msgstr "SSE-registerargument med SSE avaktiverat"
+msgstr "SSE-registerargument med SSE2 avaktiverat"
 
 #: config/i386/i386.cc:2733
 #, gcc-internal-format
@@ -41436,10 +41430,9 @@ msgid "the alignment of %<_Atomic %T%> fields changed 
in %{GCC 11.1%}"
 msgstr "justeringen av %<_Atomic %T%>-fält ändrades i %{GCC 11.1%}"
 
 #: config/i386/i386.cc:22794
-#, fuzzy, gcc-internal-format
-#| msgid "no low registers available for popping high registers"
+#, gcc-internal-format
 msgid "no register available for profiling %<-mcmodel=large%s%>"
-msgstr "inga låga register tillgängliga för att poppa höga register"
+msgstr "inga register tillgängliga för profilering %<-mcmodel=large%s%>"
 
 #: config/i386/i386.cc:22890
 #, gcc-internal-format
@@ -41447,10 +41440,9 @@ msgid "profiling %<-mcmodel=large%> with PIC is not 
supported"
 msgstr "profileringen %<-mcmodel=large%> med PIC stödjs inte"
 
 #: config/i386/i386.cc:23603
-#, fuzzy, gcc-internal-format
-#| msgid "%<__bfloat16%> is redefined from typedef % to real 
%<__bf16%> since GCC V13

Re: [PATCH] c-family, c++: Handle EXCESS_PRECISION_EXPR in pretty printers

[Joseph Myers]

On Fri, 22 Mar 2024, Jakub Jelinek wrote:

> Hi!
> 
> I've noticed that the c-c++-common/gomp/depobj-3.c test FAILs on i686-linux:
> PASS: c-c++-common/gomp/depobj-3.c  -std=c++17  at line 17 (test for 
> warnings, line 15)
> FAIL: c-c++-common/gomp/depobj-3.c  -std=c++17  at line 39 (test for 
> warnings, line 37)
> PASS: c-c++-common/gomp/depobj-3.c  -std=c++17  at line 43 (test for errors, 
> line 41)
> PASS: c-c++-common/gomp/depobj-3.c  -std=c++17  (test for warnings, line 45)
> FAIL: c-c++-common/gomp/depobj-3.c  -std=c++17 (test for excess errors)
> Excess errors:
> /home/jakub/src/gcc/gcc/testsuite/c-c++-common/gomp/depobj-3.c:37:38: 
> warning: the 'destroy' expression ''excess_precision_expr' not supported by 
> dump_expr' should be the same as the 'depobj' argument 
> 'obj' [-Wopenmp]
> The following patch replaces that 'excess_precision_expr' not supported by 
> dump_expr
> with (float)(((long double)a) + (long double)5)
> Still ugly and doesn't actually fix the FAIL (will deal with that
> incrementally), but at least valid C/C++ and shows the excess precision
> handling in action.
> 
> Ok for trunk if this passes bootstrap/regtest?
> 
> 2024-03-22  Jakub Jelinek  
> 
> gcc/c/
>   * c-pretty-print.cc (pp_c_cast_expression,
>   c_pretty_printer::expression): Handle EXCESS_PRECISION_EXPR like
>   NOP_EXPR.

The c-pretty-print.cc changes are OK.

-- 
Joseph S. Myers
josmy...@redhat.com

Re: [PATCH V2] Document -fexcess-precision=16.

[Joseph Myers]

On Wed, 20 Mar 2024, liuhongt wrote:

> gcc/ChangeLog:
> 
>   * doc/invoke.texi: Document -fexcess-precision=16.

OK.

-- 
Joseph S. Myers
josmy...@redhat.com

Re: [PATCH] Document -fexcess-precision=16.

[Joseph Myers]

On Tue, 19 Mar 2024, Hongtao Liu wrote:

> On Tue, Mar 19, 2024 at 12:16 AM Joseph Myers  wrote:
> >
> > On Mon, 18 Mar 2024, liuhongt wrote:
> >
> > > +If @option{-fexcess-precision=16} is specified, casts and assignments of
> > > +@code{_Float16} and @code{bfloat16_t} cause value to be rounded to their
> > > +semantic types if they're supported by the target.
> >
> > Isn't that option about rounding results of all operations, whether or not
> > a cast or assignment is involved?  That's certainly what the brief mention
> > of this option in extend.texi says, and fits the intent that
> > -fexcess-precision=16 corresponds to FLT_EVAL_METHOD == 16.
> Yes, how about this.
> 
> 
> +If @option{-fexcess-precision=16} is specified, each operation of
> +@code{_Float16} and @code{bfloat16_t} causes value to be rounded to their
> +semantic types if they're supported by the target.

I'm sure sure it's quite right to say the operation causes the value to be 
rounded, considering it's results not arguments that are rounded, and from 
the user perspective the rounding is an implementation detail, it's just 
computing the results in the semantic type.  So maybe more like:

  If @option{-fexcess-precision=16} is specified, constants and the
  results of expressions with types @code{_Float16} and @code{__bf16}
  are computed without excess precision.

(Also, I've suggested there to use the built-in type name __bf16; the name 
__bfloat16 from avx512bf16vlintrin.h would also be a possibility.  As far 
as I know, the bfloat16_t name is only in C++.)

-- 
Joseph S. Myers
josmy...@redhat.com

Re: [PATCH] Document -fexcess-precision=16.

[Joseph Myers]

On Mon, 18 Mar 2024, liuhongt wrote:

> +If @option{-fexcess-precision=16} is specified, casts and assignments of
> +@code{_Float16} and @code{bfloat16_t} cause value to be rounded to their
> +semantic types if they're supported by the target.

Isn't that option about rounding results of all operations, whether or not 
a cast or assignment is involved?  That's certainly what the brief mention 
of this option in extend.texi says, and fits the intent that 
-fexcess-precision=16 corresponds to FLT_EVAL_METHOD == 16.

-- 
Joseph S. Myers
josmy...@redhat.com

Re: [PATCH] gcc_update: Add missing generated files

[Joseph Myers]

On Fri, 1 Mar 2024, Jonathan Wakely wrote:

> I'm seeing errors for --enable-maintainer-mode builds due to incorrectly
> regenerating these files. They should be touched by gcc_update so they
> aren't regenerated unnecessarily.
> 
> contrib/ChangeLog:
> 
>   * gcc_update: Add more generated files in libcc1, lto-plugin,
>   fixincludes, and libstdc++-v3.

OK.

-- 
Joseph S. Myers
josmy...@redhat.com

Re: [PATCH] libgcc: Fix quotient and/or remainder negation in __divmodbitint4 [PR114327]

[Joseph Myers]

On Fri, 15 Mar 2024, Jakub Jelinek wrote:

> Hi!
> 
> While for __mulbitint3 we actually don't negate anything and perform the
> multiplication in unsigned style always, for __divmodbitint4 if the operands
> aren't unsigned and are negative, we negate them first and then try to
> negate them as needed at the end.
> quotient is negated if just one of the operands was negated and the other
> wasn't or vice versa, and remainder is negated if the first operand was
> negated.
> The case which doesn't work correctly is if due to limited range of the
> operands we perform the division/modulo in some smaller number of limbs
> and then extend it to the desired precision of the quotient and/or
> remainder results.  If they aren't negated, the extension is done with
> memset to 0, if they are negated, the extension was done with memset
> to -1.  The problem is that if the quotient or remainder is zero,
> then bitint_negate negates it again to zero (that is ok), but we should
> then extend with memset to 0, not memset to -1.
> 
> The following patch achieves that by letting bitint_negate also check if
> the negated operand is zero and changes the memset argument based on that.
> 
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

OK.

-- 
Joseph S. Myers
josmy...@redhat.com

Re: [PATCH] libcpp: Fix __has_include_next ICE in the last directory of the path [PR80755]

[Joseph Myers]

On Thu, 21 Dec 2023, Lewis Hyatt wrote:

> In libcpp/files.cc, the function _cpp_has_header(), which implements
> __has_include and __has_include_next, does not check for a NULL return value
> from search_path_head(), leading to an ICE tripping an assert when
> _cpp_find_file() tries to use it. Fix it by checking for that case and
> silently returning false instead.
> 
> As suggested by the PR author, it is easiest to make a testcase by using
> the -idirafter option. To enable that, also modify the dg-additional-options
> testsuite procedure to make the global $srcdir available, since -idirafter
> requires the full path.
> 
> libcpp/ChangeLog:
> 
>   PR preprocessor/80755
>   * files.cc (search_path_head): Add SUPPRESS_DIAGNOSTIC argument
>   defaulting to false.
>   (_cpp_has_header): Silently return false if the search path has been
>   exhausted, rather than issuing a diagnostic and then hitting an
>   assert.
> 
> gcc/testsuite/ChangeLog:
> 
>   * lib/gcc-defs.exp (dg-additional-options): Make $srcdir usable in a
>   dg-additional-options directive.
>   * c-c++-common/cpp/has-include-next-2-dir/has-include-next-2.h: New 
> test.
>   * c-c++-common/cpp/has-include-next-2.c: New test.

OK.

-- 
Joseph S. Myers
josmy...@redhat.com

Re: [PATCH] libcpp: Fix macro expansion for argument of __has_include [PR110558]

[Joseph Myers]

On Tue, 12 Dec 2023, Lewis Hyatt wrote:

> When the file name for a #include directive is the result of stringifying a
> macro argument, libcpp needs to take some care to get the whitespace
> correct; in particular stringify_arg() needs to see a CPP_PADDING token
> between macro tokens so that it can figure out when to output space between
> tokens. The CPP_PADDING tokens are not normally generated when handling a
> preprocessor directive, but for #include-like directives, libcpp sets the
> state variable pfile->state.directive_wants_padding to TRUE so that the
> CPP_PADDING tokens will be output, and then everything works fine for
> computed includes.
> 
> As the PR points out, things do not work fine for __has_include. Fix that by
> setting the state variable the same as is done for #include.
> 
> libcpp/ChangeLog:
> 
>   PR preprocessor/110558
>   * macro.cc (builtin_has_include): Set
>   pfile->state.directive_wants_padding prior to lexing the
>   file name, in case it comes from macro expansion.
> 
> gcc/testsuite/ChangeLog:
> 
>   PR preprocessor/110558
>   * c-c++-common/cpp/has-include-2.c: New test.
>   * c-c++-common/cpp/has-include-2.h: New test.

OK.

-- 
Joseph S. Myers
josmy...@redhat.com

[gcc r14-9431] Update gcc sv.po

[Joseph Myers via Gcc-cvs]

https://gcc.gnu.org/g:9b3243858bed000b0ee8c3cf718f61b0e75e72ec

commit r14-9431-g9b3243858bed000b0ee8c3cf718f61b0e75e72ec
Author: Joseph Myers 
Date:   Mon Mar 11 19:36:52 2024 +

Update gcc sv.po

* sv.po: Update.

Diff:
---
 gcc/po/sv.po | 437 ---
 1 file changed, 177 insertions(+), 260 deletions(-)

diff --git a/gcc/po/sv.po b/gcc/po/sv.po
index f24eb1bbd34..536fe50f1c0 100644
--- a/gcc/po/sv.po
+++ b/gcc/po/sv.po
@@ -32,7 +32,7 @@ msgstr ""
 "Project-Id-Version: gcc 14.1-b20240218\n"
 "Report-Msgid-Bugs-To: https://gcc.gnu.org/bugs/\n;
 "POT-Creation-Date: 2024-02-16 21:35+\n"
-"PO-Revision-Date: 2024-03-03 17:38+0100\n"
+"PO-Revision-Date: 2024-03-10 13:32+0100\n"
 "Last-Translator: Göran Uddeborg \n"
 "Language-Team: Swedish \n"
 "Language: sv\n"
@@ -1635,10 +1635,9 @@ msgid "Warn about C++26 constructs in code compiled with 
an older standard."
 msgstr "Varna för C++26-konstruktioner i kod kompilerad med en äldre standard."
 
 #: c-family/c.opt:507
-#, fuzzy, no-c-format
-#| msgid "Warn about suspicious divisions of two sizeof expressions that don't 
work correctly with pointers."
+#, no-c-format
 msgid "Warn about suspicious calls to calloc-like functions where sizeof 
expression is the earlier size argument and not the latter."
-msgstr "Varna för misstänkta divisioner av två sizeof-uttryck som inte 
fungerar korrekt med pekare."
+msgstr "Varna för misstänkta anrop av calloc-liknande funktioner där 
sizeof-uttryck är det tidigare storleksargumentet och inte det senare."
 
 #: c-family/c.opt:511
 #, no-c-format
@@ -1758,10 +1757,9 @@ msgid "Warn when a declaration is found after a 
statement."
 msgstr "Varna när en deklaration hittas efter en sats."
 
 #: c-family/c.opt:612
-#, fuzzy, no-c-format
-#| msgid "Warn about unprototyped function declarations."
+#, no-c-format
 msgid "Warn for missing parameter types in function declarations."
-msgstr "Varna för funktionsdeklarationer utan prototyp."
+msgstr "Varna för saknade parametertyper i funktionsdeklarationer."
 
 #: c-family/c.opt:616
 #, no-c-format
@@ -2174,10 +2172,9 @@ msgid "Warn when the template keyword is missing after a 
member access token in
 msgstr "Varna när nyckelordet template saknas efter en medlemsåtkomstsymbol i 
en beroende medlems åtkomstuttryck om den medlemmen är en mall."
 
 #: c-family/c.opt:994
-#, fuzzy, no-c-format
-#| msgid "Warn about global functions without previous declarations."
+#, no-c-format
 msgid "Warn about global variables without previous declarations."
-msgstr "Varna för globala funktioner utan tidigare deklaration."
+msgstr "Varna för globala variabler utan tidigare deklaration."
 
 #: c-family/c.opt:1001
 #, no-c-format
@@ -2265,10 +2262,9 @@ msgid "Warn about potentially suboptimal choices related 
to OpenACC parallelism.
 msgstr "Varna för potentiellt suboptimala val relaterade till 
OpenACC-parallellism."
 
 #: c-family/c.opt:1101
-#, fuzzy, no-c-format
-#| msgid "Warn about \"suspicious\" constructs."
+#, no-c-format
 msgid "Warn about suspicious OpenMP code."
-msgstr "Varna för ”misstänkta” konstruktioner."
+msgstr "Varna för misstänkt OpenMP-kod."
 
 #: c-family/c.opt:1105
 #, no-c-format
@@ -2606,10 +2602,9 @@ msgid "Warn if a comparison always evaluates to true or 
false."
 msgstr "Varna om en logisk jämförelse alltid beräknas till sant eller falskt."
 
 #: c-family/c.opt:1413
-#, fuzzy, no-c-format
-#| msgid "template-id not allowed for destructor"
+#, no-c-format
 msgid "Warn about simple-template-id in a constructor or destructor."
-msgstr "mall-id är inte tillåtet för destruerare"
+msgstr "Varna för simple-template-id i en konstruerare eller destruerare."
 
 #: c-family/c.opt:1417
 #, no-c-format
@@ -2918,10 +2913,9 @@ msgid "Print hierarchical comparisons when template 
types are mismatched."
 msgstr "Skriv ut hierarkiska jämförelser när malltyper inte stämmer överens."
 
 #: c-family/c.opt:1818
-#, fuzzy, no-c-format
-#| msgid "default argument mismatch in overload resolution"
+#, no-c-format
 msgid "Note all candidates during overload resolution failure."
-msgstr "standardargument stämmer inte överens i upplösning av överlagring"
+msgstr "Notera alla kandidater under misslyckad upplösning av överlagring."
 
 #: c-family/c.opt:1822
 #, no-c-format
@@ -3084,10 +3078,9 @@ msgid "Warn about macros that have conflicting header 
units definitions."
 msgstr "Varna för makron som har motstridiga huvudenhetsdefinitioner."
 
 #: c-family/c.opt:1992
-#, 

Re: [PATCH] doc: Fix docs for -dD regarding predefined macros

[Joseph Myers]

On Tue, 5 Mar 2024, Jakub Jelinek wrote:

> I can't bisect that far, supposedly predefined macros weren't included back
> in 1996 when this was written but maybe it changed in 1999 or even earlier.

It looks like this changed in 3.0 (so probably with the move to cpplib to 
provide the default preprocessor implementation), but I don't know why.

-- 
Joseph S. Myers
josmy...@redhat.com

Re: [PATCH v5 RESEND] C, ObjC: Add -Wunterminated-string-initialization

[Joseph Myers]

On Mon, 26 Feb 2024, Alejandro Colomar wrote:

> > The idea seems reasonable, but the patch needs documentation for the new 
> > option in invoke.texi.
> 
> Thanks!  Will do.
> 
> I don't see an obvious order in that file.  Where would you put the
> option?  Do you want me to sort(1) it first, and then insert the new
> option in alphabetic order?

Sandra might have a better idea of how the warning options ought to be 
ordered in the manual.  (Obviously, don't mix reordering with any content 
changes.)

-- 
Joseph S. Myers
josmy...@redhat.com

Re: [PATCH v5 RESEND] C, ObjC: Add -Wunterminated-string-initialization

[Joseph Myers]

On Sun, 25 Feb 2024, Alejandro Colomar wrote:

> or if it's just that everyone was busy doing
> other stuff.

Yes, that's right.  The patch was already listed on my patch review 
backlog, but that backlog is long.

-- 
Joseph S. Myers
josmy...@redhat.com

Re: [PATCH v5 RESEND] C, ObjC: Add -Wunterminated-string-initialization

[Joseph Myers]

On Sun, 25 Feb 2024, Mike Stump wrote:

> On Feb 6, 2024, at 2:45 AM, Alejandro Colomar  wrote:
> > 
> > Warn about the following:
> > 
> >char  s[3] = "foo";
> 
> No ObjC specific impact here, so no need for ObjC review.
> 
> As a member of the peanut gallery, I like the patch.
> 
> Joseph, this is been submitted 5 times over the past year.  Any thoughts?

The idea seems reasonable, but the patch needs documentation for the new 
option in invoke.texi.

-- 
Joseph S. Myers
josmy...@redhat.com

Re: [PATCH] c: Improve some diagnostics for __builtin_stdc_bit_* [PR114042]

[Joseph Myers]

On Fri, 23 Feb 2024, Jakub Jelinek wrote:

> Hi!
> 
> The PR complains that for the __builtin_stdc_bit_* "builtins" the
> diagnostics doesn't mention the name of the builtin the user used, but
> instead __builtin_{clz,ctz,popcount}g instead (which is what the FE
> immediately lowers it to).
> 
> The following patch repeats the checks from check_builtin_function_arguments
> which are there done on BUILT_IN_{CLZ,CTZ,POPCOUNT}G, such that they
> diagnose it with the name of the "builtin" user actually used before it
> is gone.
> 
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

OK.

-- 
Joseph S. Myers
josmy...@redhat.com

Re: [PATCH] c: Handle scoped attributes in __has*attribute and scoped attribute parsing changes in -std=c11 etc. modes [PR114007]

[Joseph Myers]

On Thu, 22 Feb 2024, Jakub Jelinek wrote:

> But sure, if you prefer the COLON_SCOPE version of the patch, I can commit
> that.  There is no PREV_WHITE in the preprocessor, there is

Yes, I prefer the COLON_SCOPE version.

-- 
Joseph S. Myers
josmy...@redhat.com

Re: [PATCH v1 05/13] Reuse MinGW from i386 for AArch64

[Joseph Myers]

On Thu, 22 Feb 2024, Richard Earnshaw (lists) wrote:

> On 21/02/2024 21:34, rep.dot@gmail.com wrote:
> > On 21 February 2024 19:34:43 CET, Evgeny Karpov 
> >  wrote:
> >>
> > 
> > Please use git send-email. Your mail ends up as empty as here, otherwise.
> 
> I don't see anything wrong with it; niether does patchwork 
> (https://patchwork.sourceware.org/project/gcc/list/?series=31191) nor 
> does the Linaro CI bot.  So perhaps it's your mailer that's 
> misconfigured.

The first part of the multipart/mixed message is empty (well, two blank 
lines).  The second part, the patch, has Content-Disposition: attachment, 
so it's correct for a mailer not to show it inline (instead showing an 
empty message with an attachment - which is how it appeared to me).

-- 
Joseph S. Myers
josmy...@redhat.com

Re: [PATCH] c: Handle scoped attributes in __has*attribute and scoped attribute parsing changes in -std=c11 etc. modes [PR114007]

[Joseph Myers]

On Thu, 22 Feb 2024, Jakub Jelinek wrote:

> Hi!
> 
> We aren't able to parse __has_attribute (vendor::attr) (and __has_c_attribute
> and __has_cpp_attribute) in strict C < C23 modes.  While in -std=gnu* modes
> or in -std=c23 there is CPP_SCOPE token, in -std=c* (except for -std=c23)
> there are is just a pair of CPP_COLON tokens.
> The c-lex.cc hunk adds support for that.
> 
> That leads to a question if we should return 1 or 0 from
> __has_attribute (gnu::unused) or not, because while
> [[gnu::unused]] is parsed fine in -std=gnu*/-std=c23 modes (sure, with
> pedwarn for < C23), we do not parse it at all in -std=c* (except for
> -std=c23), we only parse [[__extension__ gnu::unused]] there.  While
> the __extension__ in there helps to avoid the pedwarn, I think it is
> better to be consistent between GNU and strict C < C23 modes and
> parse [[gnu::unused]] too; on the other side, I think parsing
> [[__extension__ gnu : : unused]] is too weird and undesirable.
> 
> So, the following patch adds a flag during preprocessing at the point
> where we normally create CPP_SCOPE tokens out of 2 consecutive colons
> on the first CPP_COLON to mark the consecutive case (as we are tight
> on the bits, I've reused the PURE_ZERO flag, which is used just by the
> C++ FE and only ever set (both C and C++) on CPP_NUMBER tokens, this
> new flag has the same value and is only ever used on CPP_COLON tokens)
> and instead of checking loose_scope_p argument (i.e. whether it is
> [[__extension__ ...]] or not), it just parses CPP_SCOPE or CPP_COLON
> with CLONE_SCOPE flag followed by another CPP_COLON the same.
> The latter will never appear in >= C23 or -std=gnu* modes, though
> guarding its use say with flag_iso && !flag_isoc23 && doesn't really
> work because the __extension__ case temporarily clears flag_iso flag.

This patch (the one using COLON_SCOPE, *not* the one using PREV_WHITE) is 
OK.

PREV_WHITE is about whether there is whitespace between the tokens in the 
macro expansion, for the purposes of stringization - I don't think it's 
appropriate to use here.  For example, given

  #define COLON() :

then

  [[gnu COLON()COLON() unused]] int x;

should preferably not be valid; stringizing the results of expanding 
COLON()COLON() will produce "::" (PREV_WHITE not set), but that wouldn't 
be a valid attribute in C23 and I don't think anyone could reasonably 
expect it to be valid with previous standard versions.

-- 
Joseph S. Myers
josmy...@redhat.com

Re: Nested restrict pointers: missed optimization & client with UB?

[Joseph Myers via Gcc]

On Tue, 13 Feb 2024, Ties Klappe via Gcc wrote:

> Thank you both for your quick replies.
> 
> @Joseph, thank you for linking me to the other issue. If I understand
> correctly what the point is, would you then agree that the program main
> when calling foo2 has *defined* behavior?

I think that's the case, yes.

-- 
Joseph S. Myers
josmy...@redhat.com

Re: Nested restrict pointers: missed optimization & client with UB?

[Joseph Myers via Gcc]

On Tue, 13 Feb 2024, Ties Klappe via Gcc wrote:

> int foo2(int *restrict *p, int *restrict *q)
> {
> **p = 10;
> **q = 11;
> return **p;
> }

In this case, *p and *q might be the same restricted pointer object.  See 
the more detailed explanation at 
.

-- 
Joseph S. Myers
josmy...@redhat.com

Re: [PATCH] Add %[zt][diox] support to pretty-print

[Joseph Myers]

On Sat, 10 Feb 2024, Jakub Jelinek wrote:

>   * c-format.cc (gcc_diag_length_specs): Add t and z modifiers.
>   (PP_FORMAT_CHAR_TABLE, gcc_gfc_char_table): Add entries for t and
>   z modifiers.

Please also add some tests of format checking for these modifiers in 
gcc.dg/format/gcc_*.c.

-- 
Joseph S. Myers
josmy...@redhat.com

Re: [RFC] GCC Security policy

[Joseph Myers]

On Fri, 9 Feb 2024, Siddhesh Poyarekar wrote:

> > I think disallowing running as root would be a big problem in practice -
> > the typical problem case is when people build software as non-root and run
> > "make install" as root, and for some reason "make install" wants to
> > (re)build or (re)link something.
> 
> Isn't that a problematic practice though?  Or maybe have those invocations be
> separated out as CC_ROOT?

Ideally dependencies would be properly set up so that everything is built 
in the original build, and ideally there would be no need to relink at 
install time (I'm not sure of the exact circumstances in which it might be 
needed, or on what OSes to e.g. encode the right library paths in final 
installed executables).  In practice I think it's common for some building 
to take place at install time.

There is a more general principle here of composability: it's not helpful 
for being able to write scripts or makefiles combining invocations of 
different utilities and have them behave predictably if some of those 
utilities start making judgements about whether it's a good idea to run 
them in a particular environment rather than just doing their job 
independent of irrelevant aspects of the environment.  The semantics of 
invoking "gcc" have nothing to do with whether it's run as root; it should 
never need to look up what user it's running as at all.  (And it's 
probably also a bad idea for lots of separate utilities to gain their own 
ways to run in a restricted environment, for similar reasons; rather than 
teaching "gcc" a way to create a restricted environment itself, ensure 
there are easy-to-use more general utilities for running arbitrary 
programs on untrusted input in a contained environment.)

-- 
Joseph S. Myers
josmy...@redhat.com

Re: [RFC] GCC Security policy

[Joseph Myers]

On Fri, 9 Feb 2024, Siddhesh Poyarekar wrote:

> For privilege management we could add a --allow-root driver flag that allows
> gcc to run as root.  Without the flag one could either outright refuse to run
> or drop privileges and run.  Dropping privileges will be a bit tricky to
> implement because it would need a user to drop privileges to and then there
> would be the question of how to manage file access to read the compiler input
> and write out the compiler output.  If there's no such user, gcc could refuse
> to run as root by default.  I wonder though if from a security posture
> perspective it makes sense to simply discourage running as root all the time
> and not bother trying to make it work with dropped privileges and all that.
> Of course it would mean that this would be less of a "project"; it'll be a
> simple enough patch to refuse to run until --allow-root is specified.

I think disallowing running as root would be a big problem in practice - 
the typical problem case is when people build software as non-root and run 
"make install" as root, and for some reason "make install" wants to 
(re)build or (re)link something.

-- 
Joseph S. Myers
josmy...@redhat.com

Re: [pushed] diagnostics, analyzer: add optional per-diagnostic property bags to SARIF

[Joseph Myers]

On Fri, 1 Dec 2023, David Malcolm wrote:

>   * diagnostic-core.h (emit_diagnostic_valist): New overload decl.

This has broken regeneration of gcc.pot (overloads can't have the message 
extracted for translation in different argument positions).

emit_diagnostic_valist used incompatibly as both 
--keyword=emit_diagnostic_valist:4
--flag=emit_diagnostic_valist:4:gcc-internal-format and 
--keyword=emit_diagnostic_valist:5
--flag=emit_diagnostic_valist:5:gcc-internal-format

See commit 6c8e584430bc5dc01b4438f3c38a2a10fcba7685 for previous fixes for 
this involving the same function, or 
40fecdd62f7d293a214dd71b81de5e0f1099bba7 and 
db30e21cbff7b9b2acd13ab83e25e3bf52f9696f for older fixes for similar 
issues.

-- 
Joseph S. Myers
josmy...@redhat.com

[committed] c: Fix boolean conversion of floating constant as integer constant expression [PR113776]

[Joseph Myers]

My fix for bug 111059 and bug 111911 caused a conversion of a floating
constant to boolean to wrongly no longer be considered an integer
constant expression, because logic to insert a NOP_EXPR in
c_objc_common_truthvalue_conversion for an argument not an integer
constant expression itself now took place after rather than before the
conversion to bool.  In the specific case of casting a floating
constant to bool, the result is an integer constant expression even
though the argument isn't (build_c_cast deals with ensuring that casts
to integer type of anything of floating type more complicated than a
single floating constant don't get wrongly treated as integer constant
expressions even if they fold to constants), so fix the logic in
c_objc_common_truthvalue_conversion to handle that special case.

Bootstrapped with no regressions for x86_64-pc-linux-gnu.

PR c/113776

gcc/c
* c-typeck.cc (c_objc_common_truthvalue_conversion): Return an
integer constant expression for boolean conversion of floating
constant.

gcc/testsuite/
* gcc.dg/pr113776-1.c, gcc.dg/pr113776-2.c, gcc.dg/pr113776-3.c,
gcc.dg/pr113776-4.c: New tests.

---

Applied to mainline.  The original commit this is fixing has only gone
on mainline so far; any backports of that original commit will need to
take care to include this fix (and adjust for GCC 13 branch not having
-std=c23 and older versions not having enums with fixed underlying
type).

diff --git a/gcc/c/c-typeck.cc b/gcc/c/c-typeck.cc
index 3b519c48ae0..ddeab1e2a8a 100644
--- a/gcc/c/c-typeck.cc
+++ b/gcc/c/c-typeck.cc
@@ -13572,7 +13572,17 @@ c_objc_common_truthvalue_conversion (location_t 
location, tree expr, tree type)
   break;
 }
 
-  int_const = (TREE_CODE (expr) == INTEGER_CST && !TREE_OVERFLOW (expr));
+  /* Conversion of a floating constant to boolean goes through here
+ and yields an integer constant expression.  Otherwise, the result
+ is only an integer constant expression if the argument is.  */
+  int_const = ((TREE_CODE (expr) == INTEGER_CST && !TREE_OVERFLOW (expr))
+  || ((TREE_CODE (expr) == REAL_CST
+   || TREE_CODE (expr) == COMPLEX_CST)
+  && (TREE_CODE (type) == BOOLEAN_TYPE
+  || (TREE_CODE (type) == ENUMERAL_TYPE
+  && ENUM_UNDERLYING_TYPE (type) != NULL_TREE
+  && (TREE_CODE (ENUM_UNDERLYING_TYPE (type))
+  == BOOLEAN_TYPE);
   int_operands = EXPR_INT_CONST_OPERANDS (expr);
   if (int_operands && TREE_CODE (expr) != INTEGER_CST)
 {
diff --git a/gcc/testsuite/gcc.dg/pr113776-1.c 
b/gcc/testsuite/gcc.dg/pr113776-1.c
new file mode 100644
index 000..36190fbc3fe
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr113776-1.c
@@ -0,0 +1,5 @@
+/* { dg-do compile } */
+/* { dg-options "-std=c11 -pedantic" } */
+
+char d[(_Bool)0.5 == 1 ? 1 : -1];
+char f[(_Bool)0.0 == 0 ? 1 : -1];
diff --git a/gcc/testsuite/gcc.dg/pr113776-2.c 
b/gcc/testsuite/gcc.dg/pr113776-2.c
new file mode 100644
index 000..9e88210892a
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr113776-2.c
@@ -0,0 +1,4 @@
+/* { dg-do compile } */
+/* { dg-options "-std=c11 -pedantic" } */
+
+enum e { A = (_Bool) 0.0, B = (_Bool) 0.5, C = (_Bool) 1.0 };
diff --git a/gcc/testsuite/gcc.dg/pr113776-3.c 
b/gcc/testsuite/gcc.dg/pr113776-3.c
new file mode 100644
index 000..c615994a89f
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr113776-3.c
@@ -0,0 +1,7 @@
+/* { dg-do compile } */
+/* { dg-options "-std=c23 -pedantic" } */
+
+enum ebool : bool { BF, BT };
+
+char d[(enum ebool)0.5 == 1 ? 1 : -1];
+char f[(enum ebool)0.0 == 0 ? 1 : -1];
diff --git a/gcc/testsuite/gcc.dg/pr113776-4.c 
b/gcc/testsuite/gcc.dg/pr113776-4.c
new file mode 100644
index 000..1b57557746e
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr113776-4.c
@@ -0,0 +1,6 @@
+/* { dg-do compile } */
+/* { dg-options "-std=c23 -pedantic" } */
+
+enum ebool : bool { BF, BT };
+
+enum e { A = (enum ebool) 0.0, B = (enum ebool) 0.5, C = (enum ebool) 1.0 };

-- 
Joseph S. Myers
josmy...@redhat.com

Re: [PATCH 0/4] Add DF_LIVE_SUBREG data and apply to IRA and LRA

[Joseph Myers]

This series appears to be missing documentation for the new option in 
invoke.texi.

-- 
Joseph S. Myers
josmy...@redhat.com

Re: [PATCH] libgcc, v2: Fix up _BitInt division [PR113604]

[Joseph Myers]

On Wed, 31 Jan 2024, Jakub Jelinek wrote:

> Hi!
> 
> On Sat, Jan 27, 2024 at 08:53:42AM +0100, Jakub Jelinek wrote:
> > The following testcase ends up with SIGFPE in __divmodbitint4.
> > The problem is a thinko in my attempt to implement Knuth's algorithm.
> 
> Here is an updated version of the patch, the libgcc part is the same,
> but I've added a new testcase which tests the behavior of all the changed
> cases, so it has a case where uv1:uv0 / vv1 is 1:1, where it is
> 1:0 and rhat + vv1 overflows and where it is 1:0 and rhat + vv1 does not
> overflow, and includes tests also from Zdenek's other failing tests.
> 
> Previously successfully bootstrapped/regtested on x86_64-linux and
> i686-linux, the new version has been retested with
> make check-gcc GCC_TEST_RUN_EXPENSIVE=1 
> RUNTESTFLAGS="GCC_TEST_RUN_EXPENSIVE=1 dg-torture.exp='bitint-53.c 
> bitint-55.c'"
> Ok for trunk?

OK.

-- 
Joseph S. Myers
josmy...@redhat.com

Re: Updated musttail patches

[Joseph Myers]

On Fri, 2 Feb 2024, Andi Kleen wrote:

> This patchkit implements a [[musttail]] attribute for C/C++.
> 
> v4:
> Addressed all feedback except clang::musttail is still supported
> (I don't want to force an #ifdef to most users) and I'm also still

I'm fine with supporting [[clang::musttail]].  What shouldn't be supported 
is plain unnamespaced [[musttail]], at least for C, and I don't see any 
tests that that's not supported (there are tests of [[musttail]] on things 
that aren't returns, but that's mixing two different issues - 
[[gnu::musttail]] shouldn't be accepted on non-returns, while [[musttail]] 
shouldn't be accepted anywhere, including on returns, because it's not a 
standard attribute).

-- 
Joseph S. Myers
josmy...@redhat.com

Re: [Patch, stage-1, RFC]: i386: attribute regparm/stdcall and vaargs

[Joseph Myers via Gcc]

On Fri, 2 Feb 2024, Bernhard Reutner-Fischer via Gcc wrote:

> Hi Joseph!
> 
> On Tue, 30 Jan 2024 14:54:49 + (UTC)
> Joseph Myers  wrote:
> 
> > On Tue, 30 Jan 2024, Bernhard Reutner-Fischer via Gcc wrote:
> > 
> > >   * builtin-attrs.def (ATTR_TM_NOTHROW_RT_LIST): Use ATTR_NOTHROW_LIST
> > >   instead of ATTR_TM_NOTHROW_LIST, thus removing ATTR_TM_REGPARM.  
> > 
> > That doesn't make sense.  ATTR_TM_NOTHROW_RT_LIST is specifically a 
> > transactional memory attribute list, but you're removing all transactional 
> > memory attributes from it.  A list without the "*tm regparm" internal 
> > attribute would have a different name.
> > 
> 
> AFAICS there is no pre-existing attr list with just returns_twice and
> nothrow. Would ATTR_NOTHROW_RT_LIST be more appropriate as name, and
> should i move this up to before the format attribute lists, before
> DEF_FORMAT_ATTRIBUTE?

Yes, both of those seem appropriate for such an attribute list.

I do not know what attributes are appropriate for _ITM_beginTransaction.

-- 
Joseph S. Myers
josmy...@redhat.com

Re: [Patch, stage-1, RFC]: i386: attribute regparm/stdcall and vaargs

[Joseph Myers]

On Fri, 2 Feb 2024, Bernhard Reutner-Fischer via Gcc wrote:

> Hi Joseph!
> 
> On Tue, 30 Jan 2024 14:54:49 + (UTC)
> Joseph Myers  wrote:
> 
> > On Tue, 30 Jan 2024, Bernhard Reutner-Fischer via Gcc wrote:
> > 
> > >   * builtin-attrs.def (ATTR_TM_NOTHROW_RT_LIST): Use ATTR_NOTHROW_LIST
> > >   instead of ATTR_TM_NOTHROW_LIST, thus removing ATTR_TM_REGPARM.  
> > 
> > That doesn't make sense.  ATTR_TM_NOTHROW_RT_LIST is specifically a 
> > transactional memory attribute list, but you're removing all transactional 
> > memory attributes from it.  A list without the "*tm regparm" internal 
> > attribute would have a different name.
> > 
> 
> AFAICS there is no pre-existing attr list with just returns_twice and
> nothrow. Would ATTR_NOTHROW_RT_LIST be more appropriate as name, and
> should i move this up to before the format attribute lists, before
> DEF_FORMAT_ATTRIBUTE?

Yes, both of those seem appropriate for such an attribute list.

I do not know what attributes are appropriate for _ITM_beginTransaction.

-- 
Joseph S. Myers
josmy...@redhat.com

Re: [PATCH v3 4/5] Add tests for C/C++ musttail attributes

[Joseph Myers]

On Thu, 1 Feb 2024, Marek Polacek wrote:

> On Wed, Jan 31, 2024 at 11:39:56PM -0800, Andi Kleen wrote:
> > > This will run the test only once with -std=c++11.  We'll get better 
> > > coverage
> > > with dropping the line above and using
> > > 
> > > /* { dg-do compile { target { tail_call && { c || c++11 } } } } */
> > > 
> > > but here it may not matter.
> > 
> > The problem is that older C/C++ standards don't support [[]] attributes.
> > It would make sense to say >= gnu++11 || >= c23 but I don't know how to
> > express that.
>  
> That's what the c++11 target does.  Unfortunately for C we don't have
> anything like that, hence the additional-options adding c23.

For C we don't loop over the testsuite building with different standard 
options - such a conditional only makes sense for C++ in the context of 
building the same tests several times for different standards, when some 
tests need to be conditional on the standard for which they are built.

-- 
Joseph S. Myers
josmy...@redhat.com

Re: [PATCH v3 2/5] C++: Support clang compatible [[musttail]] (PR83324)

[Joseph Myers]

On Wed, 31 Jan 2024, Jakub Jelinek wrote:

> On Wed, Jan 31, 2024 at 12:21:38PM -0800, Andi Kleen wrote:
> > > > +   case RID_RETURN:
> > > > + {
> > > > +   bool musttail_p = false;
> > > > +   std_attrs = process_stmt_hotness_attribute (std_attrs, 
> > > > attrs_loc);
> > > > +   if (lookup_attribute ("", "musttail", std_attrs))
> > > > + {
> > > > +   musttail_p = true;
> > > > +   std_attrs = remove_attribute ("", "musttail", 
> > > > std_attrs);
> > > > + }
> 
> Using "" looks wrong to me, that is for standard attributes which
> are also gnu attributes, say [[noreturn]]/[[gnu::noreturn]].
> That is not the case here.  Even the __attribute__((musttail)) form will have
> gnu namespace.

And it's incorrect to use [[musttail]] (C23 syntax, no namespace) in any 
circumstances, at least for C, as it's not a standard attribute - so tests 
should verify that [[musttail]] is diagnosed as ignored even in contexts 
where [[gnu::musttail]] is valid.  (It can't be standardized as 
[[musttail]] because of the rule that standard attributes must be 
ignorable; the proposed syntax for a TS and possible future 
standardization after that is "return goto".)

-- 
Joseph S. Myers
josmy...@redhat.com

[committed] c: Fix ICE for nested enum redefinitions with/without fixed underlying type [PR112571]

[Joseph Myers]

Bug 112571 reports an ICE-on-invalid for cases where an enum is
defined, without a fixed underlying type, inside the enum type
specifier for a definition of that same enum with a fixed underlying
type.

The ultimate cause is attempting to access ENUM_UNDERLYING_TYPE in a
case where it is NULL.  Avoid this by clearing
ENUM_FIXED_UNDERLYING_TYPE_P in thie case of inconsistent definitions.

Bootstrapped wth no regressions for x86_64-pc-linux-gnu.

PR c/112571

gcc/c/
* c-decl.cc (start_enum): Clear ENUM_FIXED_UNDERLYING_TYPE_P when
defining without a fixed underlying type an enumeration previously
declared with a fixed underlying type.

gcc/testsuite/
* gcc.dg/c23-enum-9.c, gcc.dg/c23-enum-10.c: New tests.

---

Applied to mainline.  Should also be backported to GCC 13 branch (the
oldest version with support for enums with fixed underlying types),
after waiting to see if any problems arise with the patch on mainline,
subject to changing -std=c23 to -std=c2x for the older version and
making sure the patch does indeed work on the older version (there
have been significant changes renaming to redefinitions of tagged
types in GCC 14 as part of Martin's tag compatibility work).

diff --git a/gcc/c/c-decl.cc b/gcc/c/c-decl.cc
index 8d18a3e11f4..934e557dc3b 100644
--- a/gcc/c/c-decl.cc
+++ b/gcc/c/c-decl.cc
@@ -9905,8 +9905,11 @@ start_enum (location_t loc, struct c_enum_contents 
*the_enum, tree name,
 
   if (ENUM_FIXED_UNDERLYING_TYPE_P (enumtype)
   && fixed_underlying_type == NULL_TREE)
-error_at (loc, "% declared with but defined without "
- "fixed underlying type");
+{
+  error_at (loc, "% declared with but defined without "
+   "fixed underlying type");
+  ENUM_FIXED_UNDERLYING_TYPE_P (enumtype) = false;
+}
 
   the_enum->enum_next_value = integer_zero_node;
   the_enum->enum_type = enumtype;
diff --git a/gcc/testsuite/gcc.dg/c23-enum-10.c 
b/gcc/testsuite/gcc.dg/c23-enum-10.c
new file mode 100644
index 000..dd5f3453b1f
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/c23-enum-10.c
@@ -0,0 +1,6 @@
+/* PR c/112571.  */
+/* { dg-do compile } */
+/* { dg-options "-std=c23" } */
+
+enum X : typeof (enum X { A }); /* { dg-error "declared with but defined 
without fixed underlying type" } */
+/* { dg-error "invalid 'enum' underlying type" "invalid" { target *-*-* } .-1 
} */
diff --git a/gcc/testsuite/gcc.dg/c23-enum-9.c 
b/gcc/testsuite/gcc.dg/c23-enum-9.c
new file mode 100644
index 000..10bb493ca3c
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/c23-enum-9.c
@@ -0,0 +1,8 @@
+/* PR c/112571.  */
+/* { dg-do compile } */
+/* { dg-options "-std=c23" } */
+
+enum h : typeof (enum h { D }) { D }; /* { dg-error "declared with but defined 
without fixed underlying type" } */
+/* { dg-error "invalid 'enum' underlying type" "invalid" { target *-*-* } .-1 
} */
+/* { dg-error "nested redefinition" "nested" { target *-*-* } .-2 } */
+/* { dg-error "conflicting redefinition" "conflicting" { target *-*-* } .-3 } 
*/

-- 
Joseph S. Myers
josmy...@redhat.com

[committed] c: Fix ICEs casting expressions with integer constant operands to bool [PR111059, PR111911]

[Joseph Myers]

C front-end bugs 111059 and 111911 both report ICEs with conversions
to boolean of expressions with integer constant operands that can
appear in an integer constant expression as long as they are not
evaluated (such as division by zero).

The issue is a nested C_MAYBE_CONST_EXPR, with the inner one generated
in build_binary_op to indicate that a subexpression has been fully
folded and should not be folded again, and the outer one in
build_c_cast to indicate that the expression has integer constant
operands.  To avoid the inner one from build_binary_op,
c_objc_common_truthvalue_conversion should be given an argument
properly marked as having integer constant operands rather than that
information having been removed by the caller - but because c_convert
would then also wrap a C_MAYBE_CONST_EXPR with a NOP_EXPR converting
to boolean, it seems most convenient to have
c_objc_common_truthvalue_conversion produce the NE_EXPR directly in
the desired type (boolean in this case), before generating any
C_MAYBE_CONST_EXPR there, rather than it always producing a comparison
in integer_type_node and doing a conversion to boolean in the caller.

The same issue as in those PRs also applies for conversion to enums
with a boolean fixed underlying type; that case is also fixed and
tests added for it.  Note that not all the tests added failed before
the patch (in particular, the issue was specific to casts and did not
apply for implicit conversions, but some tests of those are added as
well).

Bootstrapped with no regressions for x86_64-pc-linux-gnu.

PR c/111059
PR c/111911

gcc/c/
* c-tree.h (c_objc_common_truthvalue_conversion): Add third
argument.
* c-convert.cc (c_convert): For conversions to boolean, pass third
argument to c_objc_common_truthvalue_conversion rather than
converting here.
* c-typeck.cc (build_c_cast): Ensure arguments with integer
operands are marked as such for conversion to boolean.
(c_objc_common_truthvalue_conversion): Add third argument TYPE.

gcc/testsuite/
* gcc.c-torture/compile/pr111059-1.c,
gcc.c-torture/compile/pr111059-2.c,
gcc.c-torture/compile/pr111059-3.c,
gcc.c-torture/compile/pr111059-4.c,
gcc.c-torture/compile/pr111059-5.c,
gcc.c-torture/compile/pr111059-6.c,
gcc.c-torture/compile/pr111059-7.c,
gcc.c-torture/compile/pr111059-8.c,
gcc.c-torture/compile/pr111059-9.c,
gcc.c-torture/compile/pr111059-10.c,
gcc.c-torture/compile/pr111059-11.c,
gcc.c-torture/compile/pr111059-12.c,
gcc.c-torture/compile/pr111911-1.c,
gcc.c-torture/compile/pr111911-2.c: New tests.

---

Applied to mainline.  Should be backported to active release branches
after waiting to see if any problems arise on mainline (before GCC 13,
the parts relating to enums with fixed underlying type will need to be
removed; for GCC 13, those tests will need to use -std=gnu2x not
-std=gnu23).

diff --git a/gcc/c/c-convert.cc b/gcc/c/c-convert.cc
index 3e52926f276..7c1064c6691 100644
--- a/gcc/c/c-convert.cc
+++ b/gcc/c/c-convert.cc
@@ -150,8 +150,7 @@ c_convert (tree type, tree expr, bool init_const)
 
 case BOOLEAN_TYPE:
 convert_to_boolean:
-  return fold_convert_loc
-   (loc, type, c_objc_common_truthvalue_conversion (input_location, expr));
+  return c_objc_common_truthvalue_conversion (input_location, expr, type);
 
 case POINTER_TYPE:
   /* The type nullptr_t may be converted to a pointer type.  The result is
diff --git a/gcc/c/c-tree.h b/gcc/c/c-tree.h
index cf29534c091..1fba9c8dae7 100644
--- a/gcc/c/c-tree.h
+++ b/gcc/c/c-tree.h
@@ -755,7 +755,8 @@ bool c_type_variably_modified_p (tree t)
 
 
 extern bool char_type_p (tree);
-extern tree c_objc_common_truthvalue_conversion (location_t, tree);
+extern tree c_objc_common_truthvalue_conversion (location_t, tree,
+tree = integer_type_node);
 extern tree require_complete_type (location_t, tree);
 extern bool same_translation_unit_p (const_tree, const_tree);
 extern int comptypes (tree, tree);
diff --git a/gcc/c/c-typeck.cc b/gcc/c/c-typeck.cc
index 66c6abc9f07..12d1a5a5fa1 100644
--- a/gcc/c/c-typeck.cc
+++ b/gcc/c/c-typeck.cc
@@ -6363,6 +6363,22 @@ build_c_cast (location_t loc, tree type, tree expr)
" from %qT to %qT", otype, type);
 
   ovalue = value;
+  /* If converting to boolean a value with integer operands that
+is not itself represented as an INTEGER_CST, the call below
+to note_integer_operands may insert a C_MAYBE_CONST_EXPR, but
+build_binary_op as called by c_common_truthvalue_conversion
+may also insert a C_MAYBE_CONST_EXPR to indicate that a
+subexpression has been fully folded.  To avoid nested
+C_MAYBE_CONST_EXPR, ensure that
+c_objc_common_truthvalue_conversion receives an argument
+properly marked as having 

Re: [Patch, stage-1, RFC]: i386: attribute regparm/stdcall and vaargs

[Joseph Myers via Gcc]

On Tue, 30 Jan 2024, Bernhard Reutner-Fischer via Gcc wrote:

>   * builtin-attrs.def (ATTR_TM_NOTHROW_RT_LIST): Use ATTR_NOTHROW_LIST
>   instead of ATTR_TM_NOTHROW_LIST, thus removing ATTR_TM_REGPARM.

That doesn't make sense.  ATTR_TM_NOTHROW_RT_LIST is specifically a 
transactional memory attribute list, but you're removing all transactional 
memory attributes from it.  A list without the "*tm regparm" internal 
attribute would have a different name.

-- 
Joseph S. Myers
josmy...@redhat.com

Re: [Patch, stage-1, RFC]: i386: attribute regparm/stdcall and vaargs

[Joseph Myers]

On Tue, 30 Jan 2024, Bernhard Reutner-Fischer via Gcc wrote:

>   * builtin-attrs.def (ATTR_TM_NOTHROW_RT_LIST): Use ATTR_NOTHROW_LIST
>   instead of ATTR_TM_NOTHROW_LIST, thus removing ATTR_TM_REGPARM.

That doesn't make sense.  ATTR_TM_NOTHROW_RT_LIST is specifically a 
transactional memory attribute list, but you're removing all transactional 
memory attributes from it.  A list without the "*tm regparm" internal 
attribute would have a different name.

-- 
Joseph S. Myers
josmy...@redhat.com

Re: [PATCH v4 0/4]New attribute "counted_by" to annotate bounds for C99 FAM(PR108896)

[Joseph Myers]

On Mon, 29 Jan 2024, Qing Zhao wrote:

> Thank you!
> 
> Joseph and Richard,  could you also comment on this?

I think Martin's suggestions are reasonable.

-- 
Joseph S. Myers
josmy...@redhat.com

Re: Fix ICE with -g and -std=c23 when forming composite types [PR113438]

[Joseph Myers]

On Sat, 27 Jan 2024, Martin Uecker wrote:

> Debug output ICEs when we do not set TYPE_STUB_DECL, fix this.
> 
> 
> Fix ICE with -g and -std=c23 when forming composite types [PR113438]
> 
> Set TYPE_STUB_DECL to an artificial decl when creating a new structure
> as a composite type.
> 
> PR c/113438
> 
> gcc/c/
> * c-typeck.cc (composite_type_internal): Set TYPE_STUB_DECL.
> 
> gcc/testsuite/
> * gcc.dg/pr113438.c: New test.

OK.

-- 
Joseph S. Myers
josmy...@redhat.com

Re: [PATCH v2 3/5] C: Implement musttail attribute for returns

[Joseph Myers]

On Fri, 26 Jan 2024, Andi Kleen wrote:

> > > I don't have tests for that but since it's not new behavior I suppose
> > > that's sufficient.
> > 
> > Each attribute should have tests that invalid uses are appropriately 
> > diagnosed.  See gcc.dg/c23-attr-fallthrough-2.c for examples of such tests 
> > in the case of the [[fallthrough]] attribute.  Some invalid uses may be 
> > diagnosed by existing code that's generic across attributes, others 
> > require specific code for the individual attribute.
> 
> Okay I can add a test for the other statement and declaration cases like
> below.
> 
> Any other change you need for approval?

I use testcases as a key part of the review of a patch, to see if the 
behavior is as I'd expect, so will need to see the updated patch series.

As we're in regression-fixing mode for GCC 14, a new feature like this 
will need to wait for consideration until after GCC 14 branches.

> > The default parsing of an attribute without an entry in the table of 
> > attribute handlers is that arbitrary balanced token sequences are parsed 
> > and discarded as arguments.
> 
> And it triggers a warning too (see below)

For attribute arguments, the key test is [[gnu::musttail()]] on a return 
statement where the attribute would be valid were it not for the attribute 
arguments.

> BTW I noticed that [[musttail]] ; (empty statement with attribute) gives an 
> error, which
> is probably a (unrelated) bug, afaik that should be legal for C23.

That's defined in the standard as an attribute declaration, not an 
attribute on a statement (empty statements can't have attributes).  The 
only currently supported attribute valid in an attribute declaration is 
[[fallthrough]].

When you give an attribute in C23 syntax without a namespace (so 
[[musttail]] as opposed to [[gnu::musttail]]), if it's not a known 
standard attribute then it fails the constraint in 6.7.12.1p2, "The 
identifier in a standard attribute shall be one of: [list]".

-- 
Joseph S. Myers
josmy...@redhat.com

Re: [PATCH v2 3/5] C: Implement musttail attribute for returns

[Joseph Myers]

On Thu, 25 Jan 2024, Andi Kleen wrote:

> On Thu, Jan 25, 2024 at 08:08:23PM +0000, Joseph Myers wrote:
> > On Wed, 24 Jan 2024, Andi Kleen wrote:
> > 
> > > Implement a C23 clang compatible musttail attribute similar to the earlier
> > > C++ implementation in the C parser.
> > 
> > I'd expect diagnostics, and associated tests of those diagnostics, for:
> > 
> > * musttail attribute used with any arguments, even empty 
> > [[gnu::musttail()]], much like e.g. [[fallthrough()]] or 
> > [[maybe_unused()]] gets diagnosed.
> 
> These happen naturally because the attribute doesn't get removed when
> not in front of return, and it gets warned about like any other unknown 
> attribute:
> 
> tattr.c:5:9: warning: ‘musttail’ attribute ignored [-Wattributes]
> 5 | [[gnu::musttail]] i++;
>   | ^
> 
> I don't have tests for that but since it's not new behavior I suppose
> that's sufficient.

Each attribute should have tests that invalid uses are appropriately 
diagnosed.  See gcc.dg/c23-attr-fallthrough-2.c for examples of such tests 
in the case of the [[fallthrough]] attribute.  Some invalid uses may be 
diagnosed by existing code that's generic across attributes, others 
require specific code for the individual attribute.

The default parsing of an attribute without an entry in the table of 
attribute handlers is that arbitrary balanced token sequences are parsed 
and discarded as arguments.  To diagnose such arguments (in contexts when 
the attribute is otherwise valid), an entry in the table of attribute 
handlers is appropriate.

-- 
Joseph S. Myers
josmy...@redhat.com

Re: [PATCH v2 3/5] C: Implement musttail attribute for returns

[Joseph Myers]

On Wed, 24 Jan 2024, Andi Kleen wrote:

> Implement a C23 clang compatible musttail attribute similar to the earlier
> C++ implementation in the C parser.

I'd expect diagnostics, and associated tests of those diagnostics, for:

* musttail attribute used with any arguments, even empty 
[[gnu::musttail()]], much like e.g. [[fallthrough()]] or 
[[maybe_unused()]] gets diagnosed.

* musttail attribute used on a declaration, or as part of an attribute 
declaration (attributes on their own before a semicolon - whether musttail 
on its own, or together with the fallthrough attribute that is valid in 
that case).

* musttail attribute used on any statement other than a return statement.

All of these should definitely apply to the gnu:: form and probably to 
clang:: as well.  Some of these might already be diagnosed, but I don't 
see them in the added testcases.

For the first one of these, it may help to include the attribute in the 
c_common_gnu_attributes table so the common attribute parsing code knows 
that this one doesn't accept arguments (and with an attribute handler that 
always rejects it on declarations, much like 
handle_fallthrough_attribute).

-- 
Joseph S. Myers
josmy...@redhat.com

Re: [PATCH] c: Call c_fully_fold on __atomic_* operands in atomic_bitint_fetch_using_cas_loop [PR113518]

[Joseph Myers]

On Tue, 23 Jan 2024, Jakub Jelinek wrote:

> Hi!
> 
> As the following testcase shows, I forgot to call c_fully_fold on the
> __atomic_*/__sync_* operands called on _BitInt address, the expressions
> are then used inside of TARGET_EXPR initializers etc. and are never fully
> folded later, which means we can ICE e.g. on C_MAYBE_CONST_EXPR trees
> inside of those.
> 
> The following patch fixes it, while the function currently is only called
> in the C FE because C++ doesn't support BITINT_TYPE, I think guarding the
> calls on !c_dialect_cxx () is safer.
> 
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

OK.

-- 
Joseph S. Myers
josmy...@redhat.com

Re: [C PATCH] Fix ICE for composite type for structs with unsigned bitfields [PR113492]

[Joseph Myers]

On Sat, 20 Jan 2024, Martin Uecker wrote:

> C23: Fix ICE for composite type for structs with unsigned bitfields [PR113492]
> 
> This patch fixes a bug when forming a composite type from structs that
> contain an unsigned bitfield declared with int while using 
> -funsigned-bitfields.
> In such structs the unsigned integer type was not compatible to the
> regular unsigned integer type used elsewhere in the C FE.
> 
>   PR c/113492
> 
> gcc/c:
>   * c-decl.cc (grokdeclarator): Use c_common_unsigned_type instead of
>   unsigned_type_for to create the unsigned type for bitfields declared
>   with int when using -funsigned-bitfields.
> 
> gcc/testsuite:
>   * gcc.dg/pr113492.c: New test.

OK.

-- 
Joseph S. Myers
josmy...@redhat.com

Re: [PATCH 01/14] c++: Implement __is_integral built-in trait

[Joseph Myers]

On Wed, 17 Jan 2024, Jonathan Wakely wrote:

> So we can remove the dependency on __STRICT_ISO__ for 128-bit integer
> types, and implementing std::is_integral with a built-in seems like
> the perfect time to do that. But that seems like stage 1 material, as
> we need to go through the library and see what needs to change.

As noted on IRC, for C23 there would also be library issues in making 
__int128 an extended integer type.  If it's an extended integer type, then 
C23 would require  to define int128_t, uint128_t, int_least128_t 
and uint_least128_t, along with the macros INT128_WIDTH, UINT128_WIDTH, 
INT_LEAST128_WIDTH, UINT_LEAST128_WIDTH (trivial), and INT128_C and 
UINT128_C (require an integer constant suffix), and INT128_MAX, 
INT128_MIN, UINT128_MAX, INT_LEAST128_MAX, INT_LEAST128_MIN, 
UINT_LEAST128_MAX (most simply defined using an integer constant suffix, 
though don't strictly require one).  And  would have to define 
all the printf and scanf format macros for int128_t, uint128_t, 
int_least128_t and uint_least128_t - so library support would be needed 
for those (the format macros themselves should probably expand to "w128d" 
and similar, a C23 feature already supported for narrower types by glibc 
and by GCC format checking, rather than inventing new features there).

So because an extended integer type (without padding bits) in C23 is 
expected to have all the library support from  and , 
you need integer constant suffixes and printf/scanf support before you can 
declare __int128 an extended integer type for C23.

(If adding printf and scanf support for int128_t to glibc, it probably 
makes sense to add user-visible functions such as strtoi128 at the same 
time - no such functions are in the standard, but something like them 
would be needed internally as part of the scanf implementation, and it's 
likely they would be useful for users as well.)

-- 
Joseph S. Myers
josmy...@redhat.com