Re: [C PATCH] -Wstringop-overflow for parameters with forward-declared sizes

[Joseph Myers]

On Fri, 26 May 2023, Martin Uecker via Gcc-patches wrote:

> c: -Wstringop-overflow for parameters with forward-declared sizes
> 
> Warnings from -Wstringop-overflow do not appear for parameters declared
> as VLAs when the bound refers to a parameter forward declaration. This
> is fixed by splitting the loop that passes through parameters into two,
> first only recording the positions of all possible size expressions
> and then processing the parameters.
> 
> PR c/109970
> 
> gcc/c-family:
> 
> * c-attribs.cc (build_attr_access_from_parms): Split loop to first
> record all parameters.
> 
> gcc/testsuite:
> 
> * gcc.dg/pr109970.c: New test.
> 

OK.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [V8][PATCH 2/2] Update documentation to clarify a GCC extension [PR77650]

[Joseph Myers]

On Fri, 26 May 2023, Qing Zhao via Gcc-patches wrote:

> Another question:   is it better for me to rearrange the Patch 1/2 and Patch 
> 2/2 a little bit, 
> to put the FE , doc change and corresponding testing case together into one 
> patch, (you have approved the FE part of change in Patch 1/2).
> and then the mid-end change to tree-ojbect-size.cc and the corresponding 
> testing cases to another patch?

I don't really see this patch as needing to be split up into multiple 
parts at all.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [V1][PATCH 1/3] Provide element_count attribute to flexible array member field (PR108896)

[Joseph Myers]

On Fri, 26 May 2023, Qing Zhao via Gcc-patches wrote:

> > What if the string is a wide string?  I don't expect that to work (either 
> > as a matter of interface design, or in the present code), but I think that 
> > case should have a specific check and error.
> 
> Dump question: how to check whether the string is a wide string? -:)

By examining the element type; the only valid case for the attribute would 
be an element type of (const) char.  (I think it's reasonable to reject 
all of char8_t, char16_t, char32_t, wchar_t strings in this context.)

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [V8][PATCH 2/2] Update documentation to clarify a GCC extension [PR77650]

[Joseph Myers]

On Thu, 25 May 2023, Qing Zhao via Gcc-patches wrote:

> > On May 25, 2023, at 4:51 PM, Joseph Myers  wrote:
> > 
> > The documentation in this case is OK, though claims about how a future 
> > version will behave have a poor track record (we tend to end up with such 
> > claims persisting in the documentation even though the change in question 
> > didn't get made and might sometimes no longer be considered desirable).
> Then, do you have any suggestions on this claim? Shall we delete it from 
> the doc? Or keep it?

My suggestion would be just to say the feature is deprecated without 
saying what a future version will do - also make sure to say it's 
deprecated in the GCC 14 release notes, and then if GCC 15 starts to warn, 
put something in the GCC 15 release notes as well.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [V1][PATCH 1/3] Provide element_count attribute to flexible array member field (PR108896)

[Joseph Myers]

What happens if the field giving the number of elements is in a contained 
anonymous structure or union?

struct s {
  struct { size_t count; };
  int array[] __attribute__ ((element_count ("count")));
};

This ought to work - a general principle in C is that anonymous structures 
and unions are transparent as far as name lookup for fields is concerned.  
But I don't see any testcases for it and I'm not sure it would work with 
the present code.

What if the string is a wide string?  I don't expect that to work (either 
as a matter of interface design, or in the present code), but I think that 
case should have a specific check and error.

What happens in the case where -fexec-charset specifies a 
non-ASCII-compatible character set?  I expect that to work OK with the 
existing code, because translation of string literals to the execution 
character set is disabled in __attribute__ parsing, but having a testcase 
for it would be good.

What happens if the field referenced for the element count does not have 
integer type?  I'd expect an error, but don't see one in the code or tests 
here.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [V8][PATCH 2/2] Update documentation to clarify a GCC extension [PR77650]

[Joseph Myers]

The documentation in this case is OK, though claims about how a future 
version will behave have a poor track record (we tend to end up with such 
claims persisting in the documentation even though the change in question 
didn't get made and might sometimes no longer be considered desirable).

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [C PATCH v3] Fix ICEs related to VM types in C 2/2

[Joseph Myers]

On Mon, 22 May 2023, Martin Uecker via Gcc-patches wrote:

> +static void
> +add_decl_expr(location_t loc, enum decl_context decl_context, tree type, 
> tree *expr)

Missing space before '(', and the line should be wrapped to be no more 
than 80 columns.

The C front-end changes are OK with those fixes.  The testsuite changes 
are also OK.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [V7][PATCH 2/2] Update documentation to clarify a GCC extension [PR77650]

[Joseph Myers]

On Fri, 19 May 2023, Qing Zhao via Gcc-patches wrote:

> +GCC extension accepts a structure containing an ISO C99 @dfn{flexible array

"The GCC extension" or "A GCC extension".

> +@item
> +A structure containing a C99 flexible array member, or a union containing
> +such a structure, is the middle field of another structure, for example:

There might be more than one middle field, and I think this case also 
includes where it's the *first* field - any field other than the last.

> +@smallexample
> +struct flex  @{ int length; char data[]; @};
> +
> +struct mid_flex @{ int m; struct flex flex_data; int n; @};
> +@end smallexample
> +
> +In the above, @code{mid_flex.flex_data.data[]} has undefined behavior.

And it's not literally mid_flex.flex_data.data[] that has undefined 
behavior, but trying to access a member of that array.

> +Compilers do not handle such case consistently, Any code relying on

"such a case", and "," should be "." at the end of a sentence.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [C PATCH] Remove dead code related to type compatibility across TUs.

[Joseph Myers]

On Fri, 19 May 2023, Martin Uecker via Gcc-patches wrote:

> Repost for stage 1.
> 
> 
> C: Remove dead code related to type compatibility across TUs.
> 
> Code to detect struct/unions across the same TU is not needed
> anymore. Code for determining compatibility of tagged types is
> preserved as it will be used for C2X. Some errors in the unused
> code are fixed.
> 
> Bootstrapped with no regressions for x86_64-pc-linux-gnu.
> 
> gcc/c/
> * c-decl.cc (set_type_context): Remove.
> (pop_scope, diagnose_mismatched_decls, pushdecl):
> Remove dead code.
> * c-typeck.cc (comptypes_internal): Remove dead code.
> (same_translation_unit_p): Remove.
> (tagged_types_tu_compatible_p): Some fixes.

OK.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [C PATCH v2] Fix ICEs related to VM types in C [PR106465, PR107557, PR108423, PR109450]

[Joseph Myers]

On Fri, 19 May 2023, Martin Uecker via Gcc-patches wrote:

> Thanks Joseph! 
> 
> Revised version attached. Ok?

The C front-end changes and tests are OK.

> But I wonder whether we generally need to do something 
> about
> 
>   sizeof *x
> 
> when x is NULL or not initialized. This is quite commonly
> used in C code and if the type is not of variable size,
> it is also unproblematic.  So the UB for variable size is
> unfortunate and certainly also affects existing code in
> the wild.  In practice it does not seem to cause
> problems because there is no lvalue conversion and this
> then seems to work.  Maybe we document this as an 
> extension?  (and make sure in the C FE that it
> works)  This would also make this idiom valid:

There's certainly a tricky question of what exactly it means to evaluate 
*x as far as producing an lvalue but without converting it to an rvalue - 
but right now the C standard wording on unary '*' is clear that "if it 
points to an object, the result is an lvalue designating the object" and 
"If an invalid value has been assigned to the pointer, the behavior of the 
unary * operator is undefined.", i.e. it's the evaluation as far as 
producing an lvalue that produces undefined behavior, rather than the 
lvalue conversion (that doesn't happen in sizeof) that does so.  And 
indeed we probably would be able to define semantics that avoid UB if 
desired.

-- 
Joseph S. Myers
jos...@codesourcery.com

[committed] c: Do not allow thread-local tentative definitions for C2x

[Joseph Myers]

C2x makes it clear that thread-local declarations can never be
tentative definitions (the legacy feature of C where you can e.g. do
"int i;" more than once at file scope, possibly with one of the
declarations initialized, and it counts as exactly one definition),
but are always definitions in the absence of "extern".  The wording
about external definitions was unclear in the thread-local case in C11
/ C17 (both about what counts as a tentative definition, and what is a
"definition" at all), not having been updated to cover the addition of
thread-local storage.

Implement this C2x requirement.  Arguably this is a defect fix that
would be appropriate to apply for all standard versions, but for now
the change is conditional on flag_isoc2x (however, it doesn't handle
_Thread_local / thread_local any different from GNU __thread).  Making
the change unconditional results in various TLS tests failing to
compile (gcc.dg/c11-thread-local-1.c gcc.dg/tls/thr-init-1.c
gcc.dg/tls/thr-init-2.c gcc.dg/torture/tls/thr-init-2.c
objc.dg/torture/tls/thr-init.m), though it's not clear if those tests
reflect any real code similarly trying to make use of thread-local
tentative definitions.

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

gcc/c/
* c-decl.cc (diagnose_mismatched_decls): Do not handle
thread-local declarations as tentative definitions for C2x.
(finish_decl): Do not allow thread-local definition with
incomplete type for C2x.

gcc/testsuite/
* gcc.dg/c2x-thread-local-2.c: New test.

diff --git a/gcc/c/c-decl.cc b/gcc/c/c-decl.cc
index 945e45bff89..b5b491cf2da 100644
--- a/gcc/c/c-decl.cc
+++ b/gcc/c/c-decl.cc
@@ -2442,8 +2442,20 @@ diagnose_mismatched_decls (tree newdecl, tree olddecl,
  return false;
}
 
-  /* Multiple initialized definitions are not allowed (6.9p3,5).  */
-  if (DECL_INITIAL (newdecl) && DECL_INITIAL (olddecl))
+  /* Multiple initialized definitions are not allowed (6.9p3,5).
+For this purpose, C2x makes it clear that thread-local
+declarations without extern are definitions, not tentative
+definitions, whether or not they have initializers.  The
+wording before C2x was unclear; literally it would have made
+uninitialized thread-local declarations into tentative
+definitions only if they also used static, but without saying
+explicitly whether or not other cases count as
+definitions at all.  */
+  if ((DECL_INITIAL (newdecl) && DECL_INITIAL (olddecl))
+ || (flag_isoc2x
+ && DECL_THREAD_LOCAL_P (newdecl)
+ && !DECL_EXTERNAL (newdecl)
+ && !DECL_EXTERNAL (olddecl)))
{
  auto_diagnostic_group d;
  error ("redefinition of %q+D", newdecl);
@@ -5714,10 +5726,12 @@ finish_decl (tree decl, location_t init_loc, tree init,
  /* A static variable with an incomplete type
 is an error if it is initialized.
 Also if it is not file scope.
+Also if it is thread-local (in C2x).
 Otherwise, let it through, but if it is not `extern'
 then it may cause an error message later.  */
  ? (DECL_INITIAL (decl) != NULL_TREE
-|| !DECL_FILE_SCOPE_P (decl))
+|| !DECL_FILE_SCOPE_P (decl)
+|| (flag_isoc2x && DECL_THREAD_LOCAL_P (decl)))
  /* An automatic variable with an incomplete type
 is an error.  */
  : !DECL_EXTERNAL (decl)))
diff --git a/gcc/testsuite/gcc.dg/c2x-thread-local-2.c 
b/gcc/testsuite/gcc.dg/c2x-thread-local-2.c
new file mode 100644
index 000..d199ff23848
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/c2x-thread-local-2.c
@@ -0,0 +1,40 @@
+/* Test that thread-local declarations are not considered tentative definitions
+   in C2x.  */
+/* { dg-do compile } */
+/* { dg-options "-std=c2x -pedantic-errors" } */
+
+thread_local int a; /* { dg-message "previous" } */
+thread_local int a; /* { dg-error "redefinition" } */
+
+static thread_local int b; /* { dg-message "previous" } */
+static thread_local int b; /* { dg-error "redefinition" } */
+
+thread_local int c; /* { dg-message "previous" } */
+thread_local int c = 1; /* { dg-error "redefinition" } */
+
+static thread_local int d; /* { dg-message "previous" } */
+static thread_local int d = 1; /* { dg-error "redefinition" } */
+
+thread_local int e = 1; /* { dg-message "previous" } */
+thread_local int e; /* { dg-error "redefinition" } */
+
+static thread_local int f = 1; /* { dg-message "previous" } */
+static thread_local int f; /* { dg-error "redefinition" } */
+
+/* Not being a tentative definition means that incomplete arrays are an error
+   rather than defaulting to size 1.  */
+thread_local int g[]; /* { dg-error "storage size" } */
+static thread_local int h[]; /* { dg-error "array size missing" } */
+extern thread_local int i[];
+
+thread_local int 

Re: [PING] [C PATCH] Fix ICEs related to VM types in C [PR106465, PR107557, PR108423, PR109450]

[Joseph Myers]

On Thu, 18 May 2023, Martin Uecker via Gcc-patches wrote:

> +  /* we still have to evaluate size expressions */

Comments should start with a capital letter and end with ".  ".

> diff --git a/gcc/testsuite/gcc.dg/nested-vla-1.c 
> b/gcc/testsuite/gcc.dg/nested-vla-1.c
> new file mode 100644
> index 000..408a68524d8
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/nested-vla-1.c
> @@ -0,0 +1,37 @@
> +/* { dg-do run } */
> +/* { dg-options "-std=gnu99" } */

I'm concerned with various undefined behavior in this and other tests; 
they look very fragile, relying on some optimizations and not others 
taking place.  I think they should be adjusted to avoid undefined behavior 
if all the evaluations from the abstract machine (in particular, of sizeof 
operands with variable size) take place, and other undefined behavior from 
calling functions through function pointers with incompatible type.

> + struct bar { char x[++n]; } (*bar2)(void) = bar;/* { dg-warning 
> "incompatible pointer type" } */
> +
> + if (2 != n)
> + __builtin_abort();
> +
> + if (2 != sizeof((*bar2)()))
> + __builtin_abort();

You're relying on the compiler not noticing that a function is being 
called through an incompatible type and thus not turning the call (which 
should be evaluated, because the operand of sizeof has a type with 
variable size) into a call to abort.

> diff --git a/gcc/testsuite/gcc.dg/nested-vla-2.c 
> b/gcc/testsuite/gcc.dg/nested-vla-2.c
> new file mode 100644
> index 000..504eec48c80
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/nested-vla-2.c
> @@ -0,0 +1,33 @@
> +/* { dg-do run } */
> +/* { dg-options "-std=gnu99" } */
> +
> +
> +int main()
> +{
> + int n = 1;
> +
> + typeof(char (*)[++n]) bar(void) { }
> +
> + if (2 != n)
> + __builtin_abort();
> +
> + if (2 != sizeof(*bar()))
> + __builtin_abort();

In this test, *bar() is evaluated, i.e. an undefined pointer is 
dereferenced; it would be better to return a valid pointer to a 
sufficiently large array to avoid that undefined behavior.

> diff --git a/gcc/testsuite/gcc.dg/pr106465.c b/gcc/testsuite/gcc.dg/pr106465.c
> new file mode 100644
> index 000..b03e2442f12
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/pr106465.c
> @@ -0,0 +1,86 @@
> +/* PR c/106465
> + * { dg-do run }
> + * { dg-options "-std=gnu99" }
> + * */
> +
> +int main()
> +{
> + int n = 3;
> + 
> + void g1(int m, struct { char p[++m]; }* b)  /* { dg-warning 
> "anonymous struct" } */
> + {
> + if (3 != m)
> + __builtin_abort();
> +
> + if (3 != sizeof(b->p))
> + __builtin_abort();
> + }

> + g1(2, (void*)0);

Similarly, this is dereferencing a null pointer in the evaluated operand 
of sizeof.

-- 
Joseph S. Myers
jos...@codesourcery.com

[committed] c: Handle printf %B like %b for C2x

[Joseph Myers]

WG14 decided to change the printf %B format from a recommended
extension to an optional feature defined in normative text.  Thus,
change the format checking to handle %B like %b, so not diagnosing it
with -Wformat -std=c2x -pedantic, just as with other optional
normatively defined features (such as decimal floating point and its
associated formats, for example).

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

gcc/c-family/
* c-format.cc (print_char_table): Handle %B like %b.

gcc/testsuite/
* gcc.dg/format/c2x-printf-1.c: Test %B here.
* gcc.dg/format/ext-9.c: Do not test %B here.

diff --git a/gcc/c-family/c-format.cc b/gcc/c-family/c-format.cc
index 32858ef7c17..b4eeebcb30e 100644
--- a/gcc/c-family/c-format.cc
+++ b/gcc/c-family/c-format.cc
@@ -722,13 +722,12 @@ static const format_char_info print_char_table[] =
   { "F",   0, STD_C99, { T99_D,   BADLEN,  BADLEN,  T99_D,   BADLEN,  T99_LD,  
BADLEN,  BADLEN,  BADLEN,  T2X_D32, T2X_D64, T2X_D128, BADLEN,  BADLEN,  
BADLEN,  BADLEN,  BADLEN,  BADLEN,   BADLEN,   BADLEN }, "-wp0 +#'I", "",   
NULL },
   { "aA",  0, STD_C99, { T99_D,   BADLEN,  BADLEN,  T99_D,   BADLEN,  T99_LD,  
BADLEN,  BADLEN,  BADLEN,  T2X_D32, T2X_D64, T2X_D128, BADLEN,  BADLEN,  
BADLEN,  BADLEN,  BADLEN,  BADLEN,   BADLEN,   BADLEN }, "-wp0 +#",   "",   
NULL },
   /* C2X conversion specifiers.  */
-  { "b",   0, STD_C2X, { T2X_UI,  T2X_UC,  T2X_US,  T2X_UL,  T2X_ULL, TEX_ULL, 
T2X_ST,  T2X_UPD, T2X_UIM, BADLEN,  BADLEN,  BADLEN,   T2X_U8,  T2X_U16, 
T2X_U32, T2X_U64, T2X_UF8, T2X_UF16, T2X_UF32, T2X_UF64 }, "-wp0#", "i",  
NULL },
+  { "bB",  0, STD_C2X, { T2X_UI,  T2X_UC,  T2X_US,  T2X_UL,  T2X_ULL, TEX_ULL, 
T2X_ST,  T2X_UPD, T2X_UIM, BADLEN,  BADLEN,  BADLEN,   T2X_U8,  T2X_U16, 
T2X_U32, T2X_U64, T2X_UF8, T2X_UF16, T2X_UF32, T2X_UF64 }, "-wp0#", "i",  
NULL },
   /* X/Open conversion specifiers.  */
   { "C",   0, STD_EXT, { TEX_WI,  BADLEN,  BADLEN,  BADLEN,  BADLEN,  BADLEN,  
BADLEN,  BADLEN,  BADLEN,  BADLEN,  BADLEN,  BADLEN,   BADLEN,  BADLEN,  
BADLEN,  BADLEN,  BADLEN,  BADLEN,   BADLEN,   BADLEN }, "-w","",   
NULL },
   { "S",   1, STD_EXT, { TEX_W,   BADLEN,  BADLEN,  BADLEN,  BADLEN,  BADLEN,  
BADLEN,  BADLEN,  BADLEN,  BADLEN,  BADLEN,  BADLEN,   BADLEN,  BADLEN,  
BADLEN,  BADLEN,  BADLEN,  BADLEN,   BADLEN,   BADLEN }, "-wp",   "R",  
NULL },
   /* GNU conversion specifiers.  */
   { "m",   0, STD_EXT, { T89_V,   BADLEN,  BADLEN,  BADLEN,  BADLEN,  BADLEN,  
BADLEN,  BADLEN,  BADLEN,  BADLEN,  BADLEN,  BADLEN,   BADLEN,  BADLEN,  
BADLEN,  BADLEN,  BADLEN,  BADLEN,   BADLEN,   BADLEN }, "-wp",   "",   
NULL },
-  { "B",   0, STD_EXT, { T2X_UI,  T2X_UC,  T2X_US,  T2X_UL,  T2X_ULL, TEX_ULL, 
T2X_ST,  T2X_UPD, T2X_UIM, BADLEN,  BADLEN,  BADLEN,   T2X_U8,  T2X_U16, 
T2X_U32, T2X_U64, T2X_UF8, T2X_UF16, T2X_UF32, T2X_UF64 }, "-wp0#", "i",  
NULL },
   { NULL,  0, STD_C89, NOLENGTHS, NULL, NULL, NULL }
 };
 
diff --git a/gcc/testsuite/gcc.dg/format/c2x-printf-1.c 
b/gcc/testsuite/gcc.dg/format/c2x-printf-1.c
index ca43d7997e5..9be7d4753d1 100644
--- a/gcc/testsuite/gcc.dg/format/c2x-printf-1.c
+++ b/gcc/testsuite/gcc.dg/format/c2x-printf-1.c
@@ -28,6 +28,18 @@ foo (unsigned int u, unsigned short us, unsigned char uc, 
unsigned long ul,
   /* Use of 'L' and 'q' for long long is an extension.  */
   printf ("%Lb", ull); /* { dg-warning "does not support" } */
   printf ("%qb", ull); /* { dg-warning "does not support" } */
+  /* Similar tests with %B.  */
+  printf ("%B %hB %hhB %lB %llB %jB %zB %tB\n", u, us, uc, ul, ull, uj, z, ut);
+  printf ("%*.*llB\n", 1, 2, ull);
+  printf ("%-B\n", u);
+  printf ("%#B\n", u);
+  printf ("%08B\n", u);
+  printf ("%+B\n", u); /* { dg-warning "flag" } */
+  printf ("% B\n", u); /* { dg-warning "flag" } */
+  printf ("%-08B\n", u); /* { dg-warning "ignored" } */
+  printf ("%08.5B\n", u); /* { dg-warning "ignored" } */
+  printf ("%LB", ull); /* { dg-warning "does not support" } */
+  printf ("%qB", ull); /* { dg-warning "does not support" } */
   /* Use of %wN and %wfN with each valid conversion specifier.  */
   printf ("%w8d %w16d %w32d %w64d %wf8d %wf16d %wf32d %wf64d",
  i8, i16, i32, i64, if8, if16, if32, if64);
@@ -35,6 +47,8 @@ foo (unsigned int u, unsigned short us, unsigned char uc, 
unsigned long ul,
  i8, i16, i32, i64, if8, if16, if32, if64);
   printf ("%w8b %w16b %w32b %w64b %wf8b %wf16b %wf32b %wf64b",
  u8, u16, u32, u64, uf8, uf16, uf32, uf64);
+  printf ("%w8B %w16B %w32B %w64B %wf8B %wf16B %wf32B %wf64B",
+ u8, u16, u32, u64, uf8, uf16, uf32, uf64);
   printf ("%w8o %w16o %w32o %w64o %wf8o %wf16o %wf32o %wf64o",
  u8, u16, u32, u64, uf8, uf16, uf32, uf64);
   printf ("%w8u %w16u %w32u %w64u %wf8u %wf16u %wf32u %wf64u",
diff --git a/gcc/testsuite/gcc.dg/format/ext-9.c 
b/gcc/testsuite/gcc.dg/format/ext-9.c
index 0aeb365e767..8f091292b72 100644
--- a/gcc/testsuite/gcc.dg/format/ext-9.c
+++ 

[committed] c: Remove restrictions on declarations in 'for' loops for C2X

[Joseph Myers]

C2X removes a restriction that the only declarations in the
declaration part of a 'for' loop are declarations of objects with
storage class auto or register.  Implement this change, making the
diagnostics into pedwarn_c11 calls instead of errors (as usual for
features added in a new standard version that were invalid code in a
previous version), so now pedwarn-if-pedantic for older standards and
diagnosed also with -Wc11-c2x-compat.

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

gcc/c/
* c-decl.cc (check_for_loop_decls): Use pedwarn_c11 for
diagnostics.

gcc/testsuite/
* gcc.dg/c11-fordecl-1.c, gcc.dg/c11-fordecl-2.c,
gcc.dg/c11-fordecl-3.c, gcc.dg/c11-fordecl-4.c,
gcc.dg/c2x-fordecl-1.c, gcc.dg/c2x-fordecl-2.c,
gcc.dg/c2x-fordecl-3.c, gcc.dg/c2x-fordecl-4.c: New tests.
* gcc.dg/c99-fordecl-2.c: Test diagnostic for typedef declaration
in for loop here.
* gcc.dg/pr67784-2.c, gcc.dg/pr68320.c, objc.dg/foreach-7.m: Do
not expect errors for typedef declaration in for loop.

diff --git a/gcc/c/c-decl.cc b/gcc/c/c-decl.cc
index 90d7cd27cd5..f8ede362bfd 100644
--- a/gcc/c/c-decl.cc
+++ b/gcc/c/c-decl.cc
@@ -11032,7 +11032,9 @@ check_for_loop_decls (location_t loc, bool 
turn_off_iso_c99_error)
  only applies to those that are.  (A question on this in comp.std.c
  in November 2000 received no answer.)  We implement the strictest
  interpretation, to avoid creating an extension which later causes
- problems.  */
+ problems.
+
+ This constraint was removed in C2X.  */
 
   for (b = current_scope->bindings; b; b = b->prev)
 {
@@ -11048,33 +11050,35 @@ check_for_loop_decls (location_t loc, bool 
turn_off_iso_c99_error)
  {
location_t decl_loc = DECL_SOURCE_LOCATION (decl);
if (TREE_STATIC (decl))
- error_at (decl_loc,
-   "declaration of static variable %qD in % loop "
-   "initial declaration", decl);
+ pedwarn_c11 (decl_loc, OPT_Wpedantic,
+  "declaration of static variable %qD in % "
+  "loop initial declaration", decl);
else if (DECL_EXTERNAL (decl))
- error_at (decl_loc,
-   "declaration of % variable %qD in % loop 
"
-   "initial declaration", decl);
+ pedwarn_c11 (decl_loc, OPT_Wpedantic,
+  "declaration of % variable %qD in % "
+  "loop initial declaration", decl);
  }
  break;
 
case RECORD_TYPE:
- error_at (loc,
-   "% declared in % loop initial "
-   "declaration", id);
+ pedwarn_c11 (loc, OPT_Wpedantic,
+  "% declared in % loop initial "
+  "declaration", id);
  break;
case UNION_TYPE:
- error_at (loc,
-   "% declared in % loop initial declaration",
-   id);
+ pedwarn_c11 (loc, OPT_Wpedantic,
+  "% declared in % loop initial "
+  "declaration",
+  id);
  break;
case ENUMERAL_TYPE:
- error_at (loc, "% declared in % loop "
-   "initial declaration", id);
+ pedwarn_c11 (loc, OPT_Wpedantic,
+  "% declared in % loop "
+  "initial declaration", id);
  break;
default:
- error_at (loc, "declaration of non-variable "
-   "%qD in % loop initial declaration", decl);
+ pedwarn_c11 (loc, OPT_Wpedantic, "declaration of non-variable "
+  "%qD in % loop initial declaration", decl);
}
 
   n_decls++;
diff --git a/gcc/testsuite/gcc.dg/c11-fordecl-1.c 
b/gcc/testsuite/gcc.dg/c11-fordecl-1.c
new file mode 100644
index 000..4aceb335e18
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/c11-fordecl-1.c
@@ -0,0 +1,27 @@
+/* Test for C99 declarations in for loops.  Test constraints are diagnosed for
+   C11.  Based on c99-fordecl-2.c.  */
+/* { dg-do compile } */
+/* { dg-options "-std=c11 -pedantic-errors" } */
+
+void
+foo (void)
+{
+  int j = 0;
+  for (int i = 1, bar (void); i <= 10; i++) /* { dg-error "bar" } */
+j += i;
+
+  for (static int i = 1; i <= 10; i++) /* /* { dg-error "static" } */
+j += i;
+
+  for (extern int i; j <= 500; j++) /* { dg-error "extern" } */
+j += 5;
+
+  for (enum { FOO } i = FOO; i < 10; i++) /* { dg-error "FOO" } */
+j += i;
+
+  for (enum BAR { FOO } i = FOO; i < 10; i++) /* { dg-error "FOO" } */
+/* { dg-error "BAR" "enum tag in for loop" { target *-*-* } .-1 } */
+j += i;
+  for (typedef int T;;) /* { dg-error "non-variable" } */
+;
+}
diff --git a/gcc/testsuite/gcc.dg/c11-fordecl-2.c 
b/gcc/testsuite/gcc.dg/c11-fordecl-2.c
new file mode 100644
index 000..0be1a0d13fa
--- /dev/null

[committed] c: Ignore _Atomic on function return type for C2x

[Joseph Myers]

For C2x it was decided that _Atomic would be completely ignored on
function return types (just as was done for qualifiers in C11 DR#423),
to eliminate the potential for an rvalue returned by a function having
_Atomic-qualified type when an rvalue resulting from lvalue-to-rvalue
conversion could not have such a type.  Implement this for GCC.

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

gcc/c/
* c-decl.cc (grokdeclarator): Ignore _Atomic on function return
type for C2x.

gcc/testsuite/
* gcc.dg/qual-return-9.c, gcc.dg/qual-return-10.c: New tests.

diff --git a/gcc/c/c-decl.cc b/gcc/c/c-decl.cc
index 1b53f2d0785..90d7cd27cd5 100644
--- a/gcc/c/c-decl.cc
+++ b/gcc/c/c-decl.cc
@@ -7412,9 +7412,12 @@ grokdeclarator (const struct c_declarator *declarator,
   them for noreturn functions.  The resolution of C11
   DR#423 means qualifiers (other than _Atomic) are
   actually removed from the return type when
-  determining the function type.  */
+  determining the function type.  For C2X, _Atomic is
+  removed as well.  */
int quals_used = type_quals;
-   if (flag_isoc11)
+   if (flag_isoc2x)
+ quals_used = 0;
+   else if (flag_isoc11)
  quals_used &= TYPE_QUAL_ATOMIC;
if (quals_used && VOID_TYPE_P (type) && really_funcdef)
  pedwarn (specs_loc, 0,
diff --git a/gcc/testsuite/gcc.dg/qual-return-10.c 
b/gcc/testsuite/gcc.dg/qual-return-10.c
new file mode 100644
index 000..c7dd6adc4c6
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/qual-return-10.c
@@ -0,0 +1,12 @@
+/* Test qualifiers on function return types in C2X (C2X version of
+   qual-return-6.c): those qualifiers are now ignored for all purposes,
+   including _Atomic, but should still get warnings.  */
+/* { dg-do compile } */
+/* { dg-options "-std=c2x -Wignored-qualifiers" } */
+
+const int f1 (void); /* { dg-warning "qualifiers ignored" } */
+volatile int f2 (void) { return 0; } /* { dg-warning "qualifiers ignored" } */
+const volatile void f3 (void) { } /* { dg-warning "qualifiers ignored" } */
+const void f4 (void); /* { dg-warning "qualifiers ignored" } */
+_Atomic int f5 (void); /* { dg-warning "qualifiers ignored" } */
+_Atomic int f6 (void) { return 0; } /* { dg-warning "qualifiers ignored" } */
diff --git a/gcc/testsuite/gcc.dg/qual-return-9.c 
b/gcc/testsuite/gcc.dg/qual-return-9.c
new file mode 100644
index 000..7762782edf0
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/qual-return-9.c
@@ -0,0 +1,32 @@
+/* Test qualifiers on function return types in C2X (C2X version of
+   qual-return-5.c): those qualifiers are now ignored for all purposes,
+   including _Atomic.  */
+/* { dg-do compile } */
+/* { dg-options "-std=c2x -pedantic-errors" } */
+
+int f1 (void);
+const int f1 (void);
+volatile int f1 (void) { return 0; }
+
+int *restrict f2 (void) { return 0; }
+int *f2 (void);
+
+const volatile long f3 (void);
+long f3 (void);
+
+const volatile void f4 (void) { }
+void f4 (void);
+
+_Atomic int f5 (void);
+int f5 (void);
+
+int f6 (void);
+_Atomic int f6 (void) { return 0; }
+
+/* The standard seems unclear regarding the case where restrict is
+   applied to a function return type that may not be
+   restrict-qualified; assume here that it is disallowed.  */
+restrict int f7 (void); /* { dg-error "restrict" } */
+
+typedef void FT (void);
+FT *restrict f8 (void); /* { dg-error "restrict" } */

-- 
Joseph S. Myers
jos...@codesourcery.com

[committed] c: Update __has_c_attribute values for C2x

[Joseph Myers]

WG14 decided that __has_c_attribute should return the same value
(equal to the intended __STDC_VERSION__ value) for all standard
attributes in C2x, with values associated with when an attribute was
added to the working draft (or had semantics added or changed in the
working draft) only being used in earlier stages of development of
that draft.  The intent is that the values for existing attributes
increase in future standard versions only if there are new features /
semantic changes for those attributes.  Implement this change for GCC.

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

gcc/c-family/
* c-lex.cc (c_common_has_attribute): Use 202311 as
__has_c_attribute return for all C2x attributes.

gcc/testsuite/
* gcc.dg/c2x-has-c-attribute-2.c: Expect 202311L return value from
__has_c_attribute for all C2x attributes.

diff --git a/gcc/c-family/c-lex.cc b/gcc/c-family/c-lex.cc
index 6eb0fae2f53..dcd061c7cb1 100644
--- a/gcc/c-family/c-lex.cc
+++ b/gcc/c-family/c-lex.cc
@@ -392,17 +392,13 @@ c_common_has_attribute (cpp_reader *pfile, bool 
std_syntax)
}
  else
{
- if (is_attribute_p ("deprecated", attr_name))
-   result = 201904;
- else if (is_attribute_p ("fallthrough", attr_name))
-   result = 201910;
- else if (is_attribute_p ("nodiscard", attr_name))
-   result = 202003;
- else if (is_attribute_p ("maybe_unused", attr_name))
-   result = 202106;
- else if (is_attribute_p ("noreturn", attr_name)
-  || is_attribute_p ("_Noreturn", attr_name))
-   result = 202202;
+ if (is_attribute_p ("deprecated", attr_name)
+ || is_attribute_p ("fallthrough", attr_name)
+ || is_attribute_p ("maybe_unused", attr_name)
+ || is_attribute_p ("nodiscard", attr_name)
+ || is_attribute_p ("noreturn", attr_name)
+ || is_attribute_p ("_Noreturn", attr_name))
+   result = 202311;
}
  if (result)
attr_name = NULL_TREE;
diff --git a/gcc/testsuite/gcc.dg/c2x-has-c-attribute-2.c 
b/gcc/testsuite/gcc.dg/c2x-has-c-attribute-2.c
index 3c34ab6cbd9..dc92b95e907 100644
--- a/gcc/testsuite/gcc.dg/c2x-has-c-attribute-2.c
+++ b/gcc/testsuite/gcc.dg/c2x-has-c-attribute-2.c
@@ -2,56 +2,56 @@
 /* { dg-do preprocess } */
 /* { dg-options "-std=c2x -pedantic-errors" } */
 
-#if __has_c_attribute ( nodiscard ) != 202003L
+#if __has_c_attribute ( nodiscard ) != 202311L
 #error "bad result for nodiscard"
 #endif
 
-#if __has_c_attribute ( __nodiscard__ ) != 202003L
+#if __has_c_attribute ( __nodiscard__ ) != 202311L
 #error "bad result for __nodiscard__"
 #endif
 
-#if __has_c_attribute(maybe_unused) != 202106L
+#if __has_c_attribute(maybe_unused) != 202311L
 #error "bad result for maybe_unused"
 #endif
 
-#if __has_c_attribute(__maybe_unused__) != 202106L
+#if __has_c_attribute(__maybe_unused__) != 202311L
 #error "bad result for __maybe_unused__"
 #endif
 
-#if __has_c_attribute (deprecated) != 201904L
+#if __has_c_attribute (deprecated) != 202311L
 #error "bad result for deprecated"
 #endif
 
-#if __has_c_attribute (__deprecated__) != 201904L
+#if __has_c_attribute (__deprecated__) != 202311L
 #error "bad result for __deprecated__"
 #endif
 
-#if __has_c_attribute (fallthrough) != 201910L
+#if __has_c_attribute (fallthrough) != 202311L
 #error "bad result for fallthrough"
 #endif
 
-#if __has_c_attribute (__fallthrough__) != 201910L
+#if __has_c_attribute (__fallthrough__) != 202311L
 #error "bad result for __fallthrough__"
 #endif
 
-#if __has_c_attribute (noreturn) != 202202L
+#if __has_c_attribute (noreturn) != 202311L
 #error "bad result for noreturn"
 #endif
 
-#if __has_c_attribute (__noreturn__) != 202202L
+#if __has_c_attribute (__noreturn__) != 202311L
 #error "bad result for __noreturn__"
 #endif
 
-#if __has_c_attribute (_Noreturn) != 202202L
+#if __has_c_attribute (_Noreturn) != 202311L
 #error "bad result for _Noreturn"
 #endif
 
-#if __has_c_attribute (___Noreturn__) != 202202L
+#if __has_c_attribute (___Noreturn__) != 202311L
 #error "bad result for ___Noreturn__"
 #endif
   
 /* Macros in the attribute name are expanded.  */
 #define foo deprecated
-#if __has_c_attribute (foo) != 201904L
+#if __has_c_attribute (foo) != 202311L
 #error "bad result for foo"
 #endif

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: More C type errors by default for GCC 14

[Joseph Myers]

On Fri, 12 May 2023, Florian Weimer wrote:

> This sone seems to be a good candidate for additional errors, though:
> 
>   warned_here = pedwarn
> (loc, warn_return_type >= 0 ? OPT_Wreturn_type : 0,
>  "% with no value, in function returning non-void");
> 
> It's a clear type volation that can lead to obscure bugs.  Maybe the
> converse as well.

This one is valid before C99 (the pedwarn is conditional on flag_isoc99, 
otherwise it's a warning).  The converse is unconditionally invalid 
(though the case where the returned expression from the function with void 
return type itself has void type is valid in C++ and only a 
pedwarn-if-pedantic for C; that case is a reasonable extension).

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [wish] Flexible array members in unions

[Joseph Myers]

On Thu, 11 May 2023, Kees Cook via Gcc wrote:

> Okay, understood. If this is a C-only thing, we can ignore the C++
> impact.

We're a lot more careful lately in WG14 about checking for C++ 
compatibility issues and expecting approval from the liaison group for 
anything with possible compatibility concerns for syntax in the common 
subset of C and C++.  So, no, we can't ignore the C++ impact for adding 
empty types; it would need careful consideration in the liaison group.

> What depends on the "different objects have different addresses"
> principle? And why do unions not break this -- they could point to the
> same locations within the object? And don't flexible arrays already need
> special handling in this regard?

"including a pointer to an object and a subobject at its beginning" and 
"one is a pointer to one past the end of one array object and the other is 
a pointer to the start of a different array object that happens to 
immediately follow the first array object in the address space" are both 
cases included in the semantics for comparison operators.  If you allow 
zero-size objects you get more special cases there (and quite possibly 
affect optimizations based on points-to analysis that can determine 
pointers are based on different objects, if an object is not known at 
compile time to have nonzero size).

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [wish] Flexible array members in unions

[Joseph Myers]

On Thu, 11 May 2023, Kees Cook via Gcc wrote:

> Why are zero-sized objects missing in Standard C? Or, perhaps, the better
> question is: what's needed to support the idea of a zero-sized object?

Zero-sized objects break the principle that different objects have 
different addresses, and the principle of being able to subtract pointers 
to different elements of an array.  There would also be serious C++ 
compatibility concerns, since C++ allows a struct with no members but it 
has nonzero size, unlike the GNU C extension where a struct with no 
members has size zero.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [wish] Flexible array members in unions

[Joseph Myers]

On Thu, 11 May 2023, Kees Cook via Gcc wrote:

> On Thu, May 11, 2023 at 06:29:10PM +0200, Alejandro Colomar wrote:
> > On 5/11/23 18:07, Alejandro Colomar wrote:
> > [...]
> > > Would you allow flexible array members in unions?  Is there any
> > > strong reason to disallow them?
> 
> Yes please!! And alone in a struct, too.
> 
> AFAICT, there is no mechanical/architectural reason to disallow them
> (especially since they _can_ be constructed with some fancy tricks,
> and they behave as expected.) My understanding is that it's disallowed
> due to an overly strict reading of the very terse language that created
> flexible arrays in C99.

Standard C has no such thing as a zero-size object or type, which would 
lead to problems with a struct or union that only contains a flexible 
array member there.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: More C type errors by default for GCC 14

[Joseph Myers]

On Wed, 10 May 2023, Eli Zaretskii via Gcc wrote:

> That is not the case we are discussing, AFAIU.  Or at least no one has
> yet explained why accepting those old K programs will adversely
> affect the ability of GCC to compile C2x programs.

At block scope,

  auto x = 1.5;

declares x to have type double in C2x (C++-style auto), but type int in 
C89 (and is invalid for versions in between).  In this case, there is an 
incompatible semantic change between implicit int and C++-style auto.  
Giving an error before we make -std=gnu2x the default seems like a 
particularly good idea, to further alert anyone who has been ignoring the 
warnings about implicit int that semantics will change incompatibly.

In cases where the standard requires a diagnostic, some are errors, some 
are pedwarns-by-default or unconditional pedwarns, some are 
pedwarns-if-pedantic - the choice depending on how suspicious the 
construct in question is and whether it corresponds to a meaningful 
extension (this is not making an automatic choice for every such situation 
in the standard, it's a case-by-case judgement by maintainers).  By now, 
the cases discussed in this thread are sufficiently suspicious - 
sufficiently likely to result in unintended execution at runtime (not, of 
course, reliably detected because programs with such dodgy code are very 
unlikely to have thorough automated tests covering all their code) - that 
is it in the interests of users for them to be errors by default (for C99 
and later modes, in the cases that were valid in C89).

It might also make sense to review other pedwarns-by-default and 
unconditional pedwarns to consider if any of those should be errors by 
default, though I suspect most of those are less significant.

Enabling some of -Wall by default (as warnings, not errors) might well 
also be beneficial to users, though case would be needed to exclude those 
warnings that involve stylistic choices (e.g. -Wparentheses) or have false 
positives that are hard to fix - not all of -Wall is for code that is 
objectively suspicious independent of the chosen coding style.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [PATCH] Add RTX codes for BITREVERSE and COPYSIGN.

[Joseph Myers]

On Sat, 6 May 2023, Roger Sayle wrote:

> An analysis of backend UNSPECs reveals that two of the most common UNSPECs
> across target backends are for copysign and bit reversal.  This patch
> adds RTX codes for these expressions to allow their representation to
> be standardized, and them to optimized by the middle-end RTL optimizers.

Note we have bug 50481 requesting (target-independent) built-in functions 
for bit reversal (so this patch could be useful as a basis for 
implementing such built-in functions, with appropriate lowering or libgcc 
implementation for targets without relevant instructions).

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [PATCH] c: Fix up error-recovery on non-empty VLA initializers [PR109409]

[Joseph Myers]

On Fri, 14 Apr 2023, Jakub Jelinek via Gcc-patches wrote:

> Hi!
> 
> On the following testcase we ICE, because after we emit the
> variable-sized object may not be initialized except with an empty initializer
> error we don't really reset the initializer to error_mark_node and then at
> -Wformat checking time we ICE on seeing STRING_CST initializer for a VLA.
> 
> The following patch just arranges for error_mark_node to be returned after
> the error diagnostics.
> 
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

OK.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [PATCH] c: Fix up error-recovery on functions initialized as variables [PR109412]

[Joseph Myers]

On Fri, 14 Apr 2023, Jakub Jelinek via Gcc-patches wrote:

> Hi!
> 
> The change to allow empty initializers in C broke error-recovery on the
> following testcase.  We are emitting function %qD is initialized like a
> variable error early; if the initializer is non-empty, we just emit
> another error that the initializer is invalid.  Previously if it was empty,
> we'd emit another error that scalar is being initialized by empty
> initializer (not really correct), but now we instead just try to
> build_zero_cst for the FUNCTION_TYPE and ICE on it.
> 
> The following patch just emits the same diagnostics for the empty
> initializers as we emit for the non-empty ones.
> 
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

OK.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: Fix ICEs related to VM types in C [PR106465, PR107557, PR108424, PR109450]

[Joseph Myers]

On Tue, 11 Apr 2023, Martin Uecker via Gcc-patches wrote:

> Ok, here is another attempt on fixing issues with size expression.
> Not all are regressions, but it does not make sense to try to split
> it up.

This wording implies this is version 2 or later of the patch, could you 
please give a reference to whatever previous patch posting / discussion 
there may have been?

>   Fix ICEs related to VM types in C [PR106465, PR107557, PR108424, 
> PR109450]

108424 seems to be the wrong PR number.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: MIN/MAX and trapping math and NANs

[Joseph Myers]

On Tue, 11 Apr 2023, Michael Matz via Gcc wrote:

> Note that this makes minNum/maxNum (and friends) not associative.  Also, 
> different languages and different hardware implement fmin/fmax different 
> and sometimes in conflict with 754-2008 (e.g. on SSE2 maxsd isn't 
> commutative but maxNum is!).  This can be considered a defect in 754-2008.  
> As result these operations were demoted in 754-2019 and new functions 
> minimumNumber (and friends) recommended (those propagate a qNaN).

Yes.  fmax/fmin correspond to the IEEE 754-2008 operations.  C2x has new 
functions corresponding to the IEEE 754-2019 operations.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [PATCH 2/2] Remove Negative(gwarf-) from gdwarf

[Joseph Myers]

On Fri, 24 Mar 2023, Richard Biener via Gcc-patches wrote:

> Prior to the removal of STABS support the gdwarf, gstabs, ... options
> formed a cycle with their Negative(..) option attribute.  But that
> didn't actually have any effect since most of the options also
> are Joined or JoinedOrMissing for which there's no pruning of options
> and so once ran into the set_debug_level diagnostics reporting
> conflicting debug formats.
> 
> The following removes the remains of that cycle, which is a
> Negative option from gdwarf to gdwarf-.  With RejectNegative
> added the expected effect of -gdwarf-4 -gdwarf would be to
> enable DWARF5 support (but this doesn't happen for some reason).
> I think the more sensible behavior is that seen and implemented
> in opts.cc, the more specific -gdwarf-4 determines the DWARF level
> and a later or earlier -gdwarf becomes a no-op.  So the
> Negative(..) annotation on gdwarf is just confusing.
> 
> Bootstrapped and tested on x86_64-unknown-linux-gnu, OK?

OK.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [PATCH 1/2] Disallow -gno-dwarf, gno-dwarf-N, -gno-gdb and -gno-vms

[Joseph Myers]

On Fri, 24 Mar 2023, Richard Biener via Gcc-patches wrote:

> The following adds RejectNegative to the gdwarf, gdwarf-, ggdb and gvms
> options since the current behavior is to treat the negative variant
> the same as the positive variant.  In particular -ggdb -gno-gdb
> do not cancel, and plain -gno-dwarf will enable (dwarf!) debug output.
> 
> Rejecting the negative forms avoids interpreting sensible behavior
> to combinations of options like -gdwarf-5 -gno-dwarf-3 and sticks to
> the behavior that later -g options simply override earlier ones and
> the only negative form is -g0.
> 
> Bootstrapped and tested on x86_64-unknown-linux-gnu, OK?

OK.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: Fwd: [V5][PATCH 2/2] Update documentation to clarify a GCC extension

[Joseph Myers]

On Thu, 23 Mar 2023, Qing Zhao via Gcc-patches wrote:

> +Wgnu-variable-sized-type-not-at-end
> +C C++ Var(warn_variable_sized_type_not_at_end) Warning
> +Warn about structures or unions with C99 flexible array members are not
> +at the end of a structure.

I think there's at least one word missing here, e.g. "that" before "are".

> +Please use warning option  @option{-Wgnu-variable-sized-type-not-at-end} to
> +identify all such cases in the source code and modify them.  This extension
> +will be deprecated from gcc in the next release.

We don't generally say "in the next release" in the manual (or "deprecated 
from gcc").  Maybe it *is* deprecated, maybe it will be *removed*, or will 
*start to warn by default*, in some specified version number (giving a 
version number seems better than "next release"), but "will be deprecated" 
is odd.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: Fwd: [V5][PATCH 1/2] Handle component_ref to a structre/union field including flexible array member [PR101832]

[Joseph Myers]

On Thu, 23 Mar 2023, Qing Zhao via Gcc-patches wrote:

> gcc/c/ChangeLog:
> 
> PR tree-optimization/101832
> * c-decl.cc (finish_struct): Set TYPE_INCLUDE_FLEXARRAY for
> struct/union type.

The C front-end changes are OK (supposing the original patch has correct 
whitespace, since it seems to be messed up here).

-- 
Joseph S. Myers
jos...@codesourcery.com

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

[Joseph Myers]

On Mon, 20 Mar 2023, Sandra Loosemore wrote:

> Joseph, could you maybe review the last piece?  A direct pointer to it in
> Arsen's git is
> 
> https://git.sr.ht/~arsen/gcc/commit/bc734311cbca1085a1728f79b7eebef8cc7aeac3

That's OK, assuming I understand correctly that makeinfo will still 
succeed with a warning when it's an older version (gcc.gnu.org, where 
update_web_docs_git runs, has version 6.5).

-- 
Joseph S. Myers
jos...@codesourcery.com

stor-layout: Set TYPE_TYPELESS_STORAGE consistently for type variants

[Joseph Myers]

I've observed an LTO wrong-code bug with a large testcase in GCC 12,
that results from TYPE_TYPELESS_STORAGE not being set consistently on
type variants.

Specifically, in the LTO stage of compilation, there is an aggregate
type passed to get_alias_set, whose TYPE_MAIN_VARIANT does not have
TYPE_TYPELESS_STORAGE set.  However, the TYPE_CANONICAL of that main
variant *does* have have TYPE_TYPELESS_STORAGE set; note that the use
of TYPE_CANONICAL in get_alias_set comes after the check of
TYPE_TYPELESS_STORAGE.  The effect is that when (one-argument)
record_component_aliases is called, the recursive call to
get_alias_set gives alias set 0, and the aggregate type ends up not
being considered to alias its members, with wrong-code consequences.

I haven't managed to produce a self-contained executable testcase to
demonstrate this, but it clearly seems appropriate for
TYPE_TYPELESS_STORAGE to be consistent on type variants, so this patch
makes it so, which appears to be sufficient to resolve the bug.  I've
attached a reduced test that does at least demonstrate main-variant
versions of a type (SB in this test) being written out to LTO IR both
with and without TYPE_TYPELESS_STORAGE, although not the subsequent
consequences of a type without TYPE_TYPELESS_STORAGE with a
TYPE_CANONICAL (as constructed after LTO type merging) with
TYPE_TYPELESS_STORAGE and following wrong-code.

Bootstrapped with no regressions for x86_64-pc-linux-gnu.  OK to commit?

* stor-layout.cc (finalize_type_size): Copy TYPE_TYPELESS_STORAGE
to variants.

diff --git a/gcc/stor-layout.cc b/gcc/stor-layout.cc
index 45bf2d18639..023de8c37db 100644
--- a/gcc/stor-layout.cc
+++ b/gcc/stor-layout.cc
@@ -1996,6 +1996,7 @@ finalize_type_size (tree type)
   unsigned int user_align = TYPE_USER_ALIGN (type);
   machine_mode mode = TYPE_MODE (type);
   bool empty_p = TYPE_EMPTY_P (type);
+  bool typeless = AGGREGATE_TYPE_P (type) && TYPE_TYPELESS_STORAGE (type);
 
   /* Copy it into all variants.  */
   for (variant = TYPE_MAIN_VARIANT (type);
@@ -2020,6 +2021,8 @@ finalize_type_size (tree type)
  TYPE_PRECISION (variant) = precision;
  SET_TYPE_MODE (variant, mode);
  TYPE_EMPTY_P (variant) = empty_p;
+ if (AGGREGATE_TYPE_P (variant))
+   TYPE_TYPELESS_STORAGE (variant) = typeless;
}
 }
 }

-- 
Joseph S. Myers
jos...@codesourcery.comstruct S {
  int a;
  char b[8];
};
template  class SB {
public:
  operator bool() { return true; };
  S x;
};
class T : public SB<0> {};
template  class m1 {
public:
  m1(TT) {}
  void m2() {};
};
class U {
public:
  U(int, T c) {
auto v = m1([] {});
if (c)
  v.m2();
  }
};
void f() {
  T c = {};
  U(0, c);
}

Re: Patch ping

[Joseph Myers]

On Wed, 1 Mar 2023, Jakub Jelinek via Gcc-patches wrote:

> Hi!
> 
> I'd like to ping a few pending patches:
> 
> https://gcc.gnu.org/pipermail/gcc-patches/2022-November/607534.html
>   - PR107846 - P1 - c-family: Account for integral promotions of left shifts 
> for -Wshift-overflow warning

OK.

> https://gcc.gnu.org/pipermail/gcc-patches/2022-November/606973.html
>   - PR107465 - P2 - c-family: Fix up -Wsign-compare BIT_NOT_EXPR handling

OK.

> https://gcc.gnu.org/pipermail/gcc-patches/2022-November/607104.html
>   - PR107465 - P2 - c-family: Incremental fix for -Wsign-compare BIT_NOT_EXPR 
> handling

OK.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [v3][PATCH 2/2] Update documentation to clarify a GCC extension (PR77650)

[Joseph Myers]

On Thu, 23 Feb 2023, Qing Zhao via Gcc-patches wrote:

> But the following:
> 
> struct flex1  { int length1; char data1[]; };
> struct flex2  { int length2; char data2[]; };
> union union_flex { struct flex1 f1; struct flex2 f2; };  /* this is C 
> standard.  */
> 
> struct out_flex { int n; union union_flex flex_data1;};  /* this is GNU 
> extension.  */
> 
> Should add this item into the documentation?

"union that contains a structure with a flexible array member" is just 
like "structure with a flexible array member".  I suppose the 
documentation should try to make that clear, without repeating it too much 
for every separate case.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: Fwd: [v3][PATCH 2/2] Update documentation to clarify a GCC extension (PR77650)

[Joseph Myers]

On Thu, 23 Feb 2023, Qing Zhao via Gcc-patches wrote:

> +@item
> +The structure with a C99 flexible array member is the field of
> +another union, for example:
> +
> +@smallexample
> +struct flex1  @{ int length1; char data1[]; @}
> +struct flex2  @{ int length2; char data2[]; @}
> +
> +union out_flex @{ struct flex1 flex_data1; struct flex2 flex_data2; @}

I don't think this is an extension; structures with flexible array members 
are OK in unions in standard C.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [PING, v2] Add '-Wno-complain-wrong-lang', and use it in 'gcc/testsuite/lib/target-supports.exp:check_compile' and elsewhere

[Joseph Myers]

On Tue, 21 Feb 2023, Thomas Schwinge wrote:

> Is the attached v2
> "Add '-Wno-complain-wrong-lang', and use it in 
> 'gcc/testsuite/lib/target-supports.exp:check_compile' and elsewhere"
> OK?

OK.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [PING, v2] Add '-Wno-complain-wrong-lang', and use it in 'gcc/testsuite/lib/target-supports.exp:check_compile' and elsewhere

[Joseph Myers]

On Tue, 21 Feb 2023, Thomas Schwinge wrote:

> Is the attached v2
> "Add '-Wno-complain-wrong-lang', and use it in 
> 'gcc/testsuite/lib/target-supports.exp:check_compile' and elsewhere"
> OK?

OK.

-- 
Joseph S. Myers
jos...@codesourcery.com
-- 
Gcc-rust mailing list
Gcc-rust@gcc.gnu.org
https://gcc.gnu.org/mailman/listinfo/gcc-rust

Re: [C PATCH] Detect all variably modified types [PR108375]

[Joseph Myers]

On Fri, 17 Feb 2023, Martin Uecker via Gcc-patches wrote:

> Here is a patch for PR108375.

This patch is OK.

> and another C FE patch for PR105660:
> https://gcc.gnu.org/pipermail/gcc-patches/2023-February/611817.html

This one is also OK.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: Git 'hooks/post_receive.py': UnicodeDecodeError: 'utf8' codec can't decode byte 0xff in position 2766: invalid start byte

[Joseph Myers]

On Thu, 16 Feb 2023, Martin Liška wrote:

> Well, the https://github.com/AdaCore/git-hooks were ported to Python 3 
> some time ago and I thought we've been using the updated version. But it 
> seems we're still on python2.7 :((
> 
> Joseph, can we update it, please?

If someone wishes to update them I'd encourage doing so (this particular 
error might be https://github.com/AdaCore/git-hooks/issues/19).  The 
update would need testing first (using the gcc-reposurgeon-8 repository 
which we've used for such test purposes) and there would need to be a 
check for any changes to configuration semantics or defaults since the 
version we're using that indicate a need to update 
refs/meta/config:project.config.

-- 
Joseph S. Myers
jos...@codesourcery.com

[committed] c: Allow conversions of null pointer constants to nullptr_t

[Joseph Myers]

WG14 has agreed to allow conversions (explicit and implicit) from null
pointer constants to nullptr_t; update GCC's nullptr_t implementation
to match.

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

gcc/c/
* c-convert.cc (c_convert): Allow conversion of a null pointer
constant to nullptr_t.
* c-typeck.cc (null_pointer_constant_p): Remove static.
(convert_for_assignment): Allow conversion of a null pointer
constant to nullptr_t.
(digest_init): Handle NULLPTR_TYPE among scalar conversions.
* c-tree.h (null_pointer_constant_p): Declare.

gcc/testsuite/
* gcc.dg/c2x-nullptr-1.c: Test conversion of null pointer
constants to nullptr_t.
* gcc.dg/c2x-nullptr-3.c: Do not expect errors for conversion of
null pointer constants to nullptr_t.  Do test errors for
conversion of other values to nullptr_t and for unary '+' on
nullptr_t.

diff --git a/gcc/c/c-convert.cc b/gcc/c/c-convert.cc
index dccd245dfc3..0f35dc4fe9a 100644
--- a/gcc/c/c-convert.cc
+++ b/gcc/c/c-convert.cc
@@ -157,6 +157,19 @@ c_convert (tree type, tree expr, bool init_const)
   ret = convert_to_pointer (type, e);
   goto maybe_fold;
 
+case NULLPTR_TYPE:
+  /* A null pointer constant or value of type nullptr_t may be
+converted to nullptr_t.  The latter case has already been
+handled.  build_c_cast will create an additional NOP_EXPR to
+ensure the result of the conversion is not itself a null
+pointer constant.  */
+  if (null_pointer_constant_p (expr))
+   {
+ ret = build_int_cst (type, 0);
+ goto maybe_fold;
+   }
+  break;
+
 case REAL_TYPE:
   ret = convert_to_real (type, e);
   goto maybe_fold;
@@ -201,12 +214,14 @@ c_convert (tree type, tree expr, bool init_const)
 }
 
   /* If we are converting to nullptr_t, don't say "non-scalar type" because
- the nullptr_t type is a scalar type.  Only nullptr_t shall be converted
- to nullptr_t.  */
+ the nullptr_t type is a scalar type.  Only nullptr_t or a null pointer
+ constant shall be converted to nullptr_t.  */
   if (code == NULLPTR_TYPE)
 {
   error ("conversion from %qT to %qT", TREE_TYPE (e), type);
-  inform (input_location, "only %qT can be converted to %qT", type, type);
+  inform (input_location,
+ "only %qT or a null pointer constant can be converted to %qT",
+ type, type);
 }
   else
 error ("conversion to non-scalar type requested");
diff --git a/gcc/c/c-tree.h b/gcc/c/c-tree.h
index 00ccf87e6e6..e5eefe6bbba 100644
--- a/gcc/c/c-tree.h
+++ b/gcc/c/c-tree.h
@@ -728,6 +728,7 @@ extern location_t c_last_sizeof_loc;
 
 extern struct c_switch *c_switch_stack;
 
+extern bool null_pointer_constant_p (const_tree);
 extern bool char_type_p (tree);
 extern tree c_objc_common_truthvalue_conversion (location_t, tree);
 extern tree require_complete_type (location_t, tree);
diff --git a/gcc/c/c-typeck.cc b/gcc/c/c-typeck.cc
index 157b77eda95..e37b0973cd6 100644
--- a/gcc/c/c-typeck.cc
+++ b/gcc/c/c-typeck.cc
@@ -89,7 +89,6 @@ static bool require_constant_value;
 static bool require_constant_elements;
 static bool require_constexpr_value;
 
-static bool null_pointer_constant_p (const_tree);
 static tree qualify_type (tree, tree);
 static int tagged_types_tu_compatible_p (const_tree, const_tree, bool *,
 bool *);
@@ -130,7 +129,7 @@ static int comptypes_internal (const_tree, const_tree, bool 
*, bool *);
 
 /* Return true if EXP is a null pointer constant, false otherwise.  */
 
-static bool
+bool
 null_pointer_constant_p (const_tree expr)
 {
   /* This should really operate on c_expr structures, but they aren't
@@ -7837,6 +7836,8 @@ convert_for_assignment (location_t location, location_t 
expr_loc, tree type,
   in_late_binary_op = save;
   return ret;
 }
+  else if (codel == NULLPTR_TYPE && null_pointer_constant)
+return convert (type, rhs);
 
   switch (errtype)
 {
@@ -8596,7 +8597,7 @@ digest_init (location_t init_loc, tree type, tree init, 
tree origtype,
 
   if (code == INTEGER_TYPE || code == REAL_TYPE || code == FIXED_POINT_TYPE
   || code == POINTER_TYPE || code == ENUMERAL_TYPE || code == BOOLEAN_TYPE
-  || code == COMPLEX_TYPE || code == VECTOR_TYPE)
+  || code == COMPLEX_TYPE || code == VECTOR_TYPE || code == NULLPTR_TYPE)
 {
   tree unconverted_init = inside_init;
   if (TREE_CODE (TREE_TYPE (init)) == ARRAY_TYPE
diff --git a/gcc/testsuite/gcc.dg/c2x-nullptr-1.c 
b/gcc/testsuite/gcc.dg/c2x-nullptr-1.c
index 04f9901bb12..4e440234d52 100644
--- a/gcc/testsuite/gcc.dg/c2x-nullptr-1.c
+++ b/gcc/testsuite/gcc.dg/c2x-nullptr-1.c
@@ -11,8 +11,9 @@ void f2 (int *) { }
 void f3 (_Bool) { }
 nullptr_t cmp (void) { return nullptr; }
 
-/* The type nullptr_t shall not be converted to any type other than void, bool 
or
-   a pointer type.  No type 

[committed] c: Update checks on constexpr pointer initializers

[Joseph Myers]

WG14 has agreed a change of the rules on constexpr pointer
initializers, so that a (constant) null value that is not a null
pointer constant is accepted in that context, rather than only
accepting null pointer constants.  (In particular, this means that a
constexpr variable of pointer type can be used to initializer another
such variable.)  Remove the null pointer constant restriction in GCC,
instead checking just whether the value is null.

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

gcc/c/
* c-typeck.cc (check_constexpr_init): Remove argument
null_pointer_constant.  Only check pointer initializers for being
null.
(digest_init): Update calls to check_constexpr_init.

gcc/testsuite/
* gcc.dg/c2x-constexpr-1.c: Test initialization of constexpr
pointers with null values that are not null pointer constants.
* gcc.dg/c2x-constexpr-3.c: Test initialization of constexpr
pointers with non-null values, not with null values that are not
null pointer constants.

diff --git a/gcc/c/c-typeck.cc b/gcc/c/c-typeck.cc
index 224a9cbdc3d..157b77eda95 100644
--- a/gcc/c/c-typeck.cc
+++ b/gcc/c/c-typeck.cc
@@ -8186,23 +8186,20 @@ constexpr_init_fits_real_type (tree type, tree init)
 
 /* Check whether INIT (location LOC) is valid as a 'constexpr'
initializer for type TYPE, and give an error if not.  INIT has
-   already been folded and verified to be constant.
-   NULL_POINTER_CONSTANT, INT_CONST_EXPR and ARITH_CONST_EXPR say
-   whether it is a null pointer constant, integer constant expression
-   or arithmetic constant expression, respectively.  If TYPE is not a
-   scalar type, this function does nothing.  */
+   already been folded and verified to be constant.  INT_CONST_EXPR
+   and ARITH_CONST_EXPR say whether it is an integer constant
+   expression or arithmetic constant expression, respectively.  If
+   TYPE is not a scalar type, this function does nothing.  */
 
 static void
 check_constexpr_init (location_t loc, tree type, tree init,
- bool null_pointer_constant, bool int_const_expr,
- bool arith_const_expr)
+ bool int_const_expr, bool arith_const_expr)
 {
   if (POINTER_TYPE_P (type))
 {
-  /* The initializer must be a null pointer constant.  */
-  if (!null_pointer_constant)
-   error_at (loc, "% pointer initializer is not a "
- "null pointer constant");
+  /* The initializer must be null.  */
+  if (TREE_CODE (init) != INTEGER_CST || !integer_zerop (init))
+   error_at (loc, "% pointer initializer is not null");
   return;
 }
   if (INTEGRAL_TYPE_P (type))
@@ -8582,8 +8579,7 @@ digest_init (location_t init_loc, tree type, tree init, 
tree origtype,
  "initializer element is not a constant expression");
   else if (require_constexpr)
check_constexpr_init (init_loc, type, inside_init,
- null_pointer_constant, int_const_expr,
- arith_const_expr);
+ int_const_expr, arith_const_expr);
 
   /* Added to enable additional -Wsuggest-attribute=format warnings.  */
   if (TREE_CODE (TREE_TYPE (inside_init)) == POINTER_TYPE)
@@ -8638,8 +8634,7 @@ digest_init (location_t init_loc, tree type, tree init, 
tree origtype,
  "initializer element is not a constant expression");
   else if (require_constexpr)
check_constexpr_init (init_loc, type, unconverted_init,
- null_pointer_constant, int_const_expr,
- arith_const_expr);
+ int_const_expr, arith_const_expr);
 
   return inside_init;
 }
diff --git a/gcc/testsuite/gcc.dg/c2x-constexpr-1.c 
b/gcc/testsuite/gcc.dg/c2x-constexpr-1.c
index 97b54f17428..898953020e7 100644
--- a/gcc/testsuite/gcc.dg/c2x-constexpr-1.c
+++ b/gcc/testsuite/gcc.dg/c2x-constexpr-1.c
@@ -176,6 +176,12 @@ constexpr int v97[100] = { [v82.x.f] = 7 };
 static int v98[v94];
 constexpr _Complex double v99 = 1.0;
 constexpr _Complex float v100 = 12345;
+constexpr int *v101 = (int *) 0;
+constexpr void *v102 = (void *) (void *) 0;
+constexpr void *v103 = v101;
+constexpr void *v104 = v84;
+struct s105 { void *p; };
+constexpr struct s105 v106 = { (int *) 0 };
 
 void
 f0 ()
@@ -251,6 +257,11 @@ f0 ()
   (constexpr union u58) { { 0 } }; /* { dg-warning "braces around scalar 
initializer" } */
   (constexpr _Complex double) { 1.0 };
   (constexpr _Complex float) { 12345 };
+  (constexpr int *) { (int *) 0 };
+  (constexpr void *) { (void *) (void *) 0 };
+  (constexpr void *) { v101 };
+  (constexpr void *) { v84 };
+  (constexpr struct s105) { (int *) 0 };
   /* It's not entirely clear if constexpr declarations are allowed in this
  position in a for loop; presume they are, as implicitly auto just as if no
  storage class specifiers were used.  */
diff --git 

Re: [PATCH 1/2] Handle component_ref to a structre/union field including flexible array member [PR101832]

[Joseph Myers]

On Wed, 8 Feb 2023, Siddhesh Poyarekar wrote:

> On 2023-02-08 14:09, Joseph Myers wrote:
> > What must be avoided is -pedantic diagnostics for
> > 
> > struct flex1 { int n; int data[1]; };
> > struct out_flex_end1 { int m; struct flex1 flex_data; };
> > 
> > regardless of whether considered flexible or not, since that's clearly
> > valid in standard C.
> > 
> 
> Are you sure about "regardless of whether considered flexible or not", since
> ISTM the validity of the above in standard C is limited to when it's
> considered a non-flexible array.  So with -pedantic it shouldn't warn, but it
> also then shouldn't consider it a flexible array.
> 
> In other words, perhaps it makes sense to imply -fstrict-flex-arrays with
> -pedantic?

There should be no code generation effects from -pedantic.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [PATCH 1/2] Handle component_ref to a structre/union field including flexible array member [PR101832]

[Joseph Myers]

On Wed, 8 Feb 2023, Qing Zhao via Gcc-patches wrote:

> But I noticed that “flexible_array_type_p” later was moved from FE to
>  middle-end and put into tree.cc, tree.h as a general utility routine, and to 
> 
> /* Determine whether TYPE is a structure with a flexible array member,
>or a union containing such a structure (possibly recursively).  */
> 
> However, since this routine does not cover the cases when the structure 
> with flexible array member was recursively embedded into structures, (which 
> we 
> agreed that it should be considered as a flexible sized type). 
> 
> Therefore, I feel that It might not be proper to include this routine in 
> middle end 
> (and actually no other places In middle end use this routine so far).

I think we've established that diagnostics and at least some middle-end 
purposes need different conditions.  Diagnostics for nesting a structure 
with a flexible array member inside another structure should only count [] 
as a flexible array member, whereas permitting flexible array uses in the 
middle end should allow [0] and [1] under some circumstances (depending on 
command-line options).

> But:
> 
> struct flex0 { int n; int data[0]; };
> struct out_flex_end0 { int m; struct flex0 flex_data; }; 
> struct outer_flex_end0 { int p; struct out_flex_end0 out_flex_data; }; 
> 
> In the above, only “flex0” is flexible sized type by default. 
> But “out_flex_end0” and “out_flex_end0” are Not considered as flexible sized 
> type by default? 

It would be OK (and I'm not saying here that this is necessarily 
desirable), since that's at the end of another structure rather than in 
the middle, to consider them flexible for the purposes of code generation.

What must be avoided is -pedantic diagnostics for

struct flex1 { int n; int data[1]; };
struct out_flex_end1 { int m; struct flex1 flex_data; };

regardless of whether considered flexible or not, since that's clearly 
valid in standard C.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [PATCH 1/2] Handle component_ref to a structre/union field including flexible array member [PR101832]

[Joseph Myers]

On Tue, 7 Feb 2023, Qing Zhao via Gcc-patches wrote:

> Then, this routine (flexible_array_type_p) is mainly for diagnostic purpose.
> It cannot be used to determine whether the structure/union type recursively
> include a flexible array member at the end.
> 
> Is my understanding correct?

My comments were about basic principles of what gets diagnosed, and the 
need for different predicates in different contexts; I wasn't trying to 
assert anything about how that maps onto what functions should be used in 
what contexts.

> >> 2. Only C99 standard flexible array member be included, [0] and [1] are 
> >> not included, for example:
> > 
> > Obviously we can't diagnose use of structures with [1] trailing members, 
> > because it's perfectly valid to embed those structures at any position 
> > inside other structures.  And the same is the case for the [0] extension 
> > when it's used to mean "empty array" rather than "flexible array".
> 
> With the -fstrict-flex-arrays available, we should be able to diagnose
> the flexible array member per gnu extension (i.e [0] or [1]) the same as []. 

There are different sorts of diagnostic that might be involved.

* Simply having [0] or [1] at the end of a structure embedded in another 
structure isn't appropriate to diagnose, because [0] and [1] have 
perfectly good meanings in such a context that aren't trying to be 
flexible array members at all.  [0] might be an empty type (possibly one 
that wouldn't be empty when built with a different configuration).  [1] 
might be the use of arrays in C to produce a passed-by-reference type.

* Trying to use such an embedded [0] or [1] array as if it were a flexible 
array member - i.e. accessing any member of the [0] array, or any member 
other than the [0] member of the [1] array - *is* a sign of the 
problematic use as a flexible array member, that might be appropriate to 
diagnose.  (Actually I'd guess the array index tends to be non-constant in 
accesses, and it would be odd to use a non-constant index when you mean 
that constant always to be 0, which it would need to be in the 
non-flexible case.)

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [PATCH 1/2] Handle component_ref to a structre/union field including flexible array member [PR101832]

[Joseph Myers]

On Tue, 7 Feb 2023, Qing Zhao via Gcc-patches wrote:

> 1.  Structure with flexible array member embedded into other structures 
> recursively, for example:
> 
> struct A {
>   int n;
>   char data[];
> };
> 
> struct B {
>   int m;
>   struct A a;
> };
> 
> struct C {
>   int q;
>   struct B b;
> };
> 
> In the above, “struct C” will not be caught by this routine.

Because struct B is diagnosed with -pedantic when it embed struct A, there 
is no need for -pedantic to diagnose struct C as well when it embeds 
struct B.

> 2. Only C99 standard flexible array member be included, [0] and [1] are 
> not included, for example:

Obviously we can't diagnose use of structures with [1] trailing members, 
because it's perfectly valid to embed those structures at any position 
inside other structures.  And the same is the case for the [0] extension 
when it's used to mean "empty array" rather than "flexible array".

Note that my comments above are about what diagnostics are appropriate 
under the standard.  They are *not* about how code generation might allow 
for possible uses of certain source code constructs as if they were 
flexible array members.  The two contexts may very well require different 
notions of what counts as a flexible array member.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [pushed] wwwdocs: projects/tree-ssa: Use our own copy of GCC Summit 2007 proceedings

[Joseph Myers]

On Mon, 6 Feb 2023, Gerald Pfeifer wrote:

> gccsummit.org is gone with the wind; luckily we have our own copy of the 
> 2006 proceedings.
> 
> If any of you has copies of 2007 and later, can you please drop  me a 
> copy and I'll put them on gcc.gnu.org as well?

Aren't they all on the wiki?  https://en.wikipedia.org/wiki/GCC_Summit has 
direct links to them.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [PATCH 1/2] Handle component_ref to a structre/union field including flexible array member [PR101832]

[Joseph Myers]

On Mon, 6 Feb 2023, Qing Zhao via Gcc-patches wrote:

> In GCC14:
> 
> 1. Include this new warning -Wgnu-varaible-sized-type-not-at-end to -Wall
> 2. Deprecate this extension from GCC. (Or delay this to next release?).

Any deprecation, or inclusion in -Wall, would best come with evidence 
about the prevalance of use (possibly unintentional, probably undesirable) 
of these extensions.  For example, maybe someone could do a distribution 
rebuild with a patch to enable these warnings and report the results?

Various misuses of flexible array members are only pedwarns-if-pedantic 
because of such uses - and while the original motivating case 
 was 
_G_config.h, which has since been fixed (though existing installed headers 
from old glibc would need fixincluding, at least if it becomes an error), 
it's very plausible there are uses of these extensions elsewhere.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [PATCH 2/2] Documentation Update.

[Joseph Myers]

On Thu, 2 Feb 2023, Siddhesh Poyarekar wrote:

> I dug into this on the glibc end and it looks like this commit:
> 
> commit 63fb8f9aa9d19f85599afe4b849b567aefd70a36
> Author: Zack Weinberg 
> Date:   Mon Feb 5 14:13:41 2018 -0500
> 
> Post-cleanup 2: minimize _G_config.h.
> 
> ripped all of that gunk out.  AFAICT there's no use of struct __gconv_info
> anywhere else in the code.
> 
> I reckon it is safe to say now that glibc no longer needs this misfeature.

It would be worth testing whether any change warns anywhere else in glibc 
(not necessarily in installed headers).  And to have fixincludes for the 
installed _G_config.h from old glibc if we start rejecting such code.

-- 
Joseph S. Myers
jos...@codesourcery.com

[committed] c: Update nullptr_t comparison checks

[Joseph Myers]

WG14 has agreed to allow equality comparisons between pointers and
nullptr_t values that are not null pointer constants (this was
previously an exceptional case where such nullptr_t values were
handled differently from null pointer constants; other places in the
standard allowed nullptr_t values, whether or not those values are
null pointer constants, in the same contexts as null pointer
constants); see the wording at the end of N3077.  Update GCC's
implementation to match this change.

There are also changes to allow null pointer constants of integer or
pointer type to be converted to nullptr_t (by assignment, cast or
conversion as if by assignment), which I'll deal with separately.

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

gcc/c/
* c-typeck.cc (build_binary_op): Allow comparisons between
pointers and nullptr_t values that are not null pointer constants.

gcc/testsuite/
* gcc.dg/c2x-constexpr-3.c: Do not expect comparison of nullptr_t
and pointer to be disallowed.
* gcc.dg/c2x-nullptr-1.c: Test comparisons of nullptr_t and
pointers are allowed.
* gcc.dg/c2x-nullptr-3.c: Do not test that comparisons of
nullptr_t and pointers are disallowed.

diff --git a/gcc/c/c-typeck.cc b/gcc/c/c-typeck.cc
index 9d65130154d..224a9cbdc3d 100644
--- a/gcc/c/c-typeck.cc
+++ b/gcc/c/c-typeck.cc
@@ -12749,12 +12749,16 @@ build_binary_op (location_t location, enum tree_code 
code,
  && (code1 == INTEGER_TYPE || code1 == REAL_TYPE
  || code1 == FIXED_POINT_TYPE || code1 == COMPLEX_TYPE))
short_compare = 1;
-  else if (code0 == POINTER_TYPE && null_pointer_constant_p (orig_op1))
+  else if (code0 == POINTER_TYPE
+  && (code1 == NULLPTR_TYPE
+  || null_pointer_constant_p (orig_op1)))
{
  maybe_warn_for_null_address (location, op0, code);
  result_type = type0;
}
-  else if (code1 == POINTER_TYPE && null_pointer_constant_p (orig_op0))
+  else if (code1 == POINTER_TYPE
+  && (code0 == NULLPTR_TYPE
+  || null_pointer_constant_p (orig_op0)))
{
  maybe_warn_for_null_address (location, op1, code);
  result_type = type1;
diff --git a/gcc/testsuite/gcc.dg/c2x-constexpr-3.c 
b/gcc/testsuite/gcc.dg/c2x-constexpr-3.c
index 4f6b8ed6779..44a3ed358e1 100644
--- a/gcc/testsuite/gcc.dg/c2x-constexpr-3.c
+++ b/gcc/testsuite/gcc.dg/c2x-constexpr-3.c
@@ -219,7 +219,6 @@ f0 ()
   (constexpr signed char []) { u8"\xff" }; /* { dg-error "'constexpr' 
initializer not representable in type of object" } */
   constexpr typeof (nullptr) not_npc = nullptr;
   int *ptr = 0;
-  (void) (ptr == not_npc); /* { dg-error "invalid operands" } */
   /* auto may only be used with another storage class specifier, such as
  constexpr, if the type is inferred.  */
   auto constexpr int a_c_t = 1; /* { dg-error "'auto' used with 'constexpr'" } 
*/
diff --git a/gcc/testsuite/gcc.dg/c2x-nullptr-1.c 
b/gcc/testsuite/gcc.dg/c2x-nullptr-1.c
index 9f2cb6c8256..04f9901bb12 100644
--- a/gcc/testsuite/gcc.dg/c2x-nullptr-1.c
+++ b/gcc/testsuite/gcc.dg/c2x-nullptr-1.c
@@ -141,6 +141,23 @@ test2 (int *p)
   (void) (p != _Generic(0, int : nullptr));
   (void) (_Generic(0, int : nullptr) == p);
   (void) (_Generic(0, int : nullptr) != p);
+
+  /* "(nullptr_t)nullptr" has type nullptr_t but isn't an NPC; these
+ comparisons are valid after C2X CD comments GB-071 and FR-073 were
+ resolved by the wording in N3077.  */
+  (void) ((nullptr_t)nullptr == p);
+  (void) ((nullptr_t)nullptr != p);
+  (void) (p == (nullptr_t)nullptr);
+  (void) (p != (nullptr_t)nullptr);
+  (void) (cmp () == p);
+  (void) (cmp () != p);
+  (void) (p == cmp ());
+  (void) (p != cmp ());
+  /* "(void *)nullptr" is not an NPC, either.  */
+  (void) ((void *)nullptr == cmp ());
+  (void) ((void *)nullptr != cmp ());
+  (void) (cmp () == (void *)nullptr);
+  (void) (cmp () != (void *)nullptr);
 }
 
 /* Test ?:.  */
diff --git a/gcc/testsuite/gcc.dg/c2x-nullptr-3.c 
b/gcc/testsuite/gcc.dg/c2x-nullptr-3.c
index 34e3e03ba9d..591ab7e6158 100644
--- a/gcc/testsuite/gcc.dg/c2x-nullptr-3.c
+++ b/gcc/testsuite/gcc.dg/c2x-nullptr-3.c
@@ -19,21 +19,6 @@ test1 (int *p)
   (void) (nullptr != 1); /* { dg-error "invalid operands" } */
   (void) (1 != nullptr); /* { dg-error "invalid operands" } */
   (void) (1 > nullptr); /* { dg-error "invalid operands" } */
-
-  /* "(nullptr_t)nullptr" has type nullptr_t but isn't an NPC.  */
-  (void) ((nullptr_t)nullptr == p); /* { dg-error "invalid operands" } */
-  (void) ((nullptr_t)nullptr != p); /* { dg-error "invalid operands" } */
-  (void) (p == (nullptr_t)nullptr); /* { dg-error "invalid operands" } */
-  (void) (p != (nullptr_t)nullptr); /* { dg-error "invalid operands" } */
-  (void) (cmp () == p); /* { dg-error "invalid operands" } */
-  (void) (cmp () != p); /* { dg-error "invalid operands" } */
-  (void) (p == cmp ()); /* { dg-error 

[committed] c: Update checks on constexpr floating-point initializers

[Joseph Myers]

WG14 has agreed some changes (detailed at the end of N3082) to the
rules on constexpr initializers for floating types.  Update GCC's
implementation to match: binary initializers are now allowed for
decimal types, and real initializers for complex types, but signaling
NaN initializers can't be used for a different type with the same
mode.

There are also changes to the constexpr rules for pointer types
(allowing null pointer address constants that aren't null pointer
constants), which I'll deal with separately.

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

gcc/c/
* c-typeck.cc: Include "realmpfr.h".
(constexpr_init_fits_real_type): Do not allow signaling NaN
conversions to different types with the same mode.  Handle
conversions from binary to decimal types.
(check_constexpr_init): Do not disallow real initializers for
complex types.  Do not disallow binary initializers for decimal
floating types.

gcc/testsuite/
* gcc.dg/c2x-constexpr-1.c: Test constexpr initializers of complex
types with real initializers are allowed.
* gcc.dg/c2x-constexpr-3.c: Do not test for constexpr initializers
of complex types with real initializers being disallowed.
* gcc.dg/c2x-constexpr-8.c: Add tests of signaling NaN complex
initializers.
* gcc.dg/c2x-constexpr-9.c: Add more tests.
* gcc.dg/dfp/c2x-constexpr-dfp-1.c: Add tests of binary floating
initializers for decimal types.
* gcc.dg/dfp/c2x-constexpr-dfp-2.c: Change tests of binary
initializers for decimal types.  Add more tests of decimal
initializers for binary types.

diff --git a/gcc/c/c-typeck.cc b/gcc/c/c-typeck.cc
index 2737b14ea18..9d65130154d 100644
--- a/gcc/c/c-typeck.cc
+++ b/gcc/c/c-typeck.cc
@@ -52,6 +52,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "stringpool.h"
 #include "attribs.h"
 #include "asan.h"
+#include "realmpfr.h"
 
 /* Possible cases of implicit conversions.  Used to select diagnostic messages
and control folding initializers in convert_for_assignment.  */
@@ -8121,8 +8122,9 @@ print_spelling (char *buffer)
 }
 
 /* Check whether INIT, a floating or integer constant, is
-   representable in TYPE, a real floating type with the same radix.
-   Return true if OK, false if not.  */
+   representable in TYPE, a real floating type with the same radix or
+   a decimal floating type initialized with a binary floating
+   constant.  Return true if OK, false if not.  */
 static bool
 constexpr_init_fits_real_type (tree type, tree init)
 {
@@ -8130,8 +8132,16 @@ constexpr_init_fits_real_type (tree type, tree init)
   gcc_assert (TREE_CODE (init) == INTEGER_CST || TREE_CODE (init) == REAL_CST);
   if (TREE_CODE (init) == REAL_CST
   && TYPE_MODE (TREE_TYPE (init)) == TYPE_MODE (type))
-/* Same mode, no conversion required.  */
-return true;
+{
+  /* Same mode, no conversion required except for the case of
+signaling NaNs if the types are incompatible (e.g. double and
+long double with the same mode).  */
+  if (REAL_VALUE_ISSIGNALING_NAN (TREE_REAL_CST (init))
+ && !comptypes (TYPE_MAIN_VARIANT (type),
+TYPE_MAIN_VARIANT (TREE_TYPE (init
+   return false;
+  return true;
+}
   if (TREE_CODE (init) == INTEGER_CST)
 {
   tree converted = build_real_from_int_cst (type, init);
@@ -8140,6 +8150,33 @@ constexpr_init_fits_real_type (tree type, tree init)
TYPE_PRECISION (TREE_TYPE (init)));
   return !fail && wi::eq_p (w, wi::to_wide (init));
 }
+  if (REAL_VALUE_ISSIGNALING_NAN (TREE_REAL_CST (init)))
+return false;
+  if ((REAL_VALUE_ISINF (TREE_REAL_CST (init))
+   && MODE_HAS_INFINITIES (TYPE_MODE (type)))
+  || (REAL_VALUE_ISNAN (TREE_REAL_CST (init))
+ && MODE_HAS_NANS (TYPE_MODE (type
+return true;
+  if (DECIMAL_FLOAT_TYPE_P (type)
+  && !DECIMAL_FLOAT_TYPE_P (TREE_TYPE (init)))
+{
+  /* This is valid if the real number represented by the
+initializer can be exactly represented in the decimal
+type.  Compare the values using MPFR.  */
+  REAL_VALUE_TYPE t;
+  real_convert (, TYPE_MODE (type), _REAL_CST (init));
+  mpfr_t bin_val, dec_val;
+  mpfr_init2 (bin_val, REAL_MODE_FORMAT (TYPE_MODE (TREE_TYPE (init)))->p);
+  mpfr_init2 (dec_val, REAL_MODE_FORMAT (TYPE_MODE (TREE_TYPE (init)))->p);
+  mpfr_from_real (bin_val, _REAL_CST (init), MPFR_RNDN);
+  char string[256];
+  real_to_decimal (string, , sizeof string, 0, 1);
+  bool res = (mpfr_strtofr (dec_val, string, NULL, 10, MPFR_RNDN) == 0
+ && mpfr_equal_p (bin_val, dec_val));
+  mpfr_clear (bin_val);
+  mpfr_clear (dec_val);
+  return res;
+}
   /* exact_real_truncate is not quite right here, since it doesn't
  allow even an exact conversion to subnormal 

[committed] c: Disallow braces around C2x auto initializers

[Joseph Myers]

WG14 agreed at this week's meeting to remove support for braces around
auto scalar initializers, as incompatible with C++ auto handling of
braced initializers; thus remove that support in GCC.

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

gcc/c/
* c-parser.cc (c_parser_declaration_or_fndef): Do not allow braces
around auto initializer.

gcc/testsuite/
* gcc.dg/c2x-auto-1.c, gcc.dg/c2x-auto-3.c: Expect braces around
auto initializers to be disallowed.

diff --git a/gcc/c/c-parser.cc b/gcc/c/c-parser.cc
index 803b04b8dc1..69230002bc8 100644
--- a/gcc/c/c-parser.cc
+++ b/gcc/c/c-parser.cc
@@ -2480,18 +2480,7 @@ c_parser_declaration_or_fndef (c_parser *parser, bool 
fndef_ok,
  int flag_sanitize_save = flag_sanitize;
  if (nested && !empty_ok)
flag_sanitize = 0;
- if (std_auto_type_p
- && c_parser_next_token_is (parser, CPP_OPEN_BRACE))
-   {
- matching_braces braces;
- braces.consume_open (parser);
- init = c_parser_expr_no_commas (parser, NULL);
- if (c_parser_next_token_is (parser, CPP_COMMA))
-   c_parser_consume_token (parser);
- braces.skip_until_found_close (parser);
-   }
- else
-   init = c_parser_expr_no_commas (parser, NULL);
+ init = c_parser_expr_no_commas (parser, NULL);
  if (std_auto_type_p)
finish_underspecified_init (underspec_name,
underspec_state);
diff --git a/gcc/testsuite/gcc.dg/c2x-auto-1.c 
b/gcc/testsuite/gcc.dg/c2x-auto-1.c
index f8460fb3bfb..c50daccfe89 100644
--- a/gcc/testsuite/gcc.dg/c2x-auto-1.c
+++ b/gcc/testsuite/gcc.dg/c2x-auto-1.c
@@ -4,14 +4,14 @@
 
 auto i = 1;
 extern int i;
-static auto l = { 0L };
+static auto l = 0L;
 extern long l;
 extern auto const d = 0.0; /* { dg-warning "initialized and declared 'extern'" 
} */
 extern const double d;
 double dx;
 auto ((i2)) = 3;
 extern int i2;
-const auto i3 [[]] = { 4, };
+const auto i3 [[]] = 4;
 extern int i4;
 thread_local auto f = 1.0f;
 float ff;
diff --git a/gcc/testsuite/gcc.dg/c2x-auto-3.c 
b/gcc/testsuite/gcc.dg/c2x-auto-3.c
index a34ce31f6be..1ab3cc74d35 100644
--- a/gcc/testsuite/gcc.dg/c2x-auto-3.c
+++ b/gcc/testsuite/gcc.dg/c2x-auto-3.c
@@ -62,3 +62,10 @@ f5 ()
 {
   static int auto e10 = 3; /* { dg-error "multiple storage classes in 
declaration specifiers" } */
 }
+
+void
+f6 ()
+{
+  static auto l = { 0L }; /* { dg-error "expected expression" } */
+  const auto i3 [[]] = { 4, }; /* { dg-error "expected expression" } */
+}

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [PATCH] driver: fix -gz=none error message with missing zstd

[Joseph Myers]

On Fri, 27 Jan 2023, Martin Liška wrote:

> We wrongly report:
> 
> $ echo "int main () {}" | gcc -xc -gz=none -
> gcc: error: -gz=zstd is not supported in this configuration
> 
> if zstd compression is not supported by binutils. We should emit the
> error message only if -gz=zstd.
> 
>   PR driver/108572
> 
> Ready to be installed?
> Thanks,
> Martin
> 
> gcc/ChangeLog:
> 
>   * gcc.cc (LINK_COMPRESS_DEBUG_SPEC): Report error only for
>   -gz=zstd.

OK.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [committed] C-SKY: Define SYSROOT_SUFFIX_SPEC.

[Joseph Myers]

On Fri, 13 Jan 2023, Xianmiao Qu via Gcc-patches wrote:

> The earlier patch
>   https://gcc.gnu.org/pipermail/gcc-patches/2021-July/575418.html
> refine the way to generate sysroot suffix, but it can't find the
> right path for all CPUs. The SYSROOT_SUFFIX_SPEC should be defined
> to fix it.

I think this caused the build failures with build-many-glibcs.py shown by 
my bot.  SYSROOT_SUFFIX_SPEC should not be defined for a 
--disable-multilib build; in such a build you can expect a single sysroot 
without a suffix involved.  Thus, you should put the SYSROOT_SUFFIX_SPEC 
definition in a separate header only used if test "x${enable_multilib}" = 
xyes (as in the config.gcc code removed in the older patch you refer to 
above), or something similar.

https://sourceware.org/pipermail/libc-testresults/2023q1/010706.html

The error is:

/scratch/jmyers/glibc-bot/install/compilers/csky-linux-gnuabiv2/csky-glibc-linux-gnuabiv2/bin/ld:
 cannot find -lc: No such file or directory

(linking shared libgcc).

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [PATCH] c: ICE with nullptr as case expression [PR108424]

[Joseph Myers]

On Wed, 18 Jan 2023, Marek Polacek via Gcc-patches wrote:

> In this ICE-on-invalid, we crash on
> 
>   gcc_assert (INTEGRAL_TYPE_P (type));
> 
> in perform_integral_promotions, because a nullptr is an INTEGER_CST,
> but not INTEGRAL_TYPE_P, and check_case_value is only checking the
> former.  In the test I'm testing other "shall be an integral constant
> expression" contexts as well.
> 
> Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?

OK.  (INTEGER_CST of pointer type is detected in c_add_case_label.)

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: Renaming git master?

[Joseph Myers]

On Sun, 15 Jan 2023, Gerald Pfeifer wrote:

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

If you wish to add additional symbolic-refs / make master into a 
symbolic-ref, please make sure to change hooks-bin, 
refs/meta/config:project.config and anything else required about the hooks 
to treat the new name the same as master, *before not after* adding the 
new name.

https://gcc.gnu.org/pipermail/gcc/2021-August/236953.html

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [PATCH] c: Don't emit DEBUG_BEGIN_STMTs for K function argument declarations [PR105972]

[Joseph Myers]

On Wed, 11 Jan 2023, Jakub Jelinek via Gcc-patches wrote:

> The following patch ensures we don't emit any such DEBUG_BEGIN_STMTs for the
> K function parameter declarations even in nested functions.
> 
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
> 
> 2023-01-11  Jakub Jelinek  
> 
>   PR c/105972
>   * c-parser.cc (c_parser_declaration_or_fndef): Disable debug non-bind
>   markers for K function parameter declarations of nested functions.
> 
>   * gcc.dg/pr105972.c: New test.

OK.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [PATCH] longlong.h: Do no use asm input cast for clang

[Joseph Myers]

On Tue, 10 Jan 2023, Adhemerval Zanella Netto via Gcc-patches wrote:

> That's my original intention [1], but Joseph stated that GCC is the upstream
> source of this file.  Joseph, would you be ok for a similar patch to glibc
> since gcc is reluctant to accept it?

I don't think it's a good idea for the copies to diverge.  I also think 
the file is more heavily used in GCC (as part of the libgcc sources, 
effectively) than in glibc and so it's best to use GCC as the upstream for 
this shared file.

Ideally maybe most of the macros in this file would be replaced by 
built-in functions (that are guaranteed to expand inline rather than 
possibly circularly calling a libgcc function defined using the same 
macro), so that the inline asm could be avoided (when building libgcc, or 
when building glibc with a new-enough compiler).  But that would be a 
substantial project.

-- 
Joseph S. Myers
jos...@codesourcery.com

[committed] c: Check for modifiable static compound literals in inline definitions

[Joseph Myers]

The C rule against modifiable objects with static storage duration in
inline definitions should apply to compound literals (using the C2x
feature of storage-class specifiers for compound literals) just as to
variables.  Add a call to record_inline_static for compound literals
to make sure this case is detected.

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

gcc/c/
* c-decl.cc (build_compound_literal): Call record_inline_static.

gcc/testsuite/
* gcc.dg/c2x-complit-8.c: New test.

diff --git a/gcc/c/c-decl.cc b/gcc/c/c-decl.cc
index e47ca6718b3..d76ffb3380d 100644
--- a/gcc/c/c-decl.cc
+++ b/gcc/c/c-decl.cc
@@ -6260,6 +6260,13 @@ build_compound_literal (location_t loc, tree type, tree 
init, bool non_const,
   DECL_USER_ALIGN (decl) = 1;
 }
   store_init_value (loc, decl, init, NULL_TREE);
+  if (current_scope != file_scope
+  && TREE_STATIC (decl)
+  && !TREE_READONLY (decl)
+  && DECL_DECLARED_INLINE_P (current_function_decl)
+  && DECL_EXTERNAL (current_function_decl))
+record_inline_static (input_location, current_function_decl,
+ decl, csi_modifiable);
 
   if (TREE_CODE (type) == ARRAY_TYPE && !COMPLETE_TYPE_P (type))
 {
diff --git a/gcc/testsuite/gcc.dg/c2x-complit-8.c 
b/gcc/testsuite/gcc.dg/c2x-complit-8.c
new file mode 100644
index 000..fb614ab7802
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/c2x-complit-8.c
@@ -0,0 +1,70 @@
+/* Test C2x storage class specifiers in compound literals: inline function
+   constraints.  */
+/* { dg-do compile } */
+/* { dg-options "-std=c2x -pedantic-errors" } */
+
+inline void
+f1 ()
+{
+  (static int) { 123 }; /* { dg-error "static but declared in inline function 
'f1' which is not static" } */
+  (static thread_local int) { 456 } ; /* { dg-error "static but declared in 
inline function 'f1' which is not static" } */
+  (int) { 789 };
+  (register int) { 1234 };
+}
+
+inline void
+f1e ()
+{
+  (static int) { 123 };
+  (static thread_local int) { 456 } ;
+}
+
+static inline void
+f1s ()
+{
+  (static int) { 123 };
+  (static thread_local int) { 456 } ;
+}
+
+inline void
+f2 ()
+{
+  (static const int) { 123 };
+  (static thread_local const int) { 456 };
+}
+
+inline void
+f2e ()
+{
+  (static const int) { 123 };
+  (static thread_local const int) { 456 };
+}
+
+static inline void
+f2s ()
+{
+  (static const int) { 123 };
+  (static thread_local const int) { 456 };
+}
+
+inline void
+f3 ()
+{
+  (static constexpr int) { 123 };
+}
+
+inline void
+f3e ()
+{
+  (static constexpr int) { 123 };
+}
+
+static inline void
+f3s ()
+{
+  (static constexpr int) { 123 };
+}
+
+extern void f1e ();
+extern void f2e ();
+extern void f3e ();

-- 
Joseph S. Myers
jos...@codesourcery.com

[committed] c: C2x semantics for __builtin_tgmath

[Joseph Myers]

__builtin_tgmath implements  semantics for integer generic
arguments that handle cases involving _FloatN / _FloatNx types as
specified in TS 18661-3 plus some defect fixes.

C2x has further changes to the semantics for  macros with
such types, which should also be considered defect fixes (although
handled through the integration of TS 18661-3 in C2x rather than
through an issue tracking process).  Specifically, the rules were
changed because of problems raised with using the macros with the
evaluation format types such as float_t and _Float32_t: the older
version of the rules didn't allow passing _FloatN / _FloatNx types to
the narrowing macros returning float or double, or passing float /
double / long double to the narrowing macros returning _FloatN /
_FloatNx, which was a problem with the evaluation format types which
could be either kind of type depending on the value of
FLT_EVAL_METHOD.

Thus the new rules allow cases of mixing types which were not allowed
before - which is not itself a problem for __builtin_tgmath - and, as
part of the changes, the handling of integer arguments was also
changed: if there is any _FloatNx generic argument, integer generic
arguments are treated as _Float32x (not double), while the rule about
treating integer arguments to narrowing macros returning _FloatN or
_FloatNx as _Float64 not double was removed (no longer needed now
double is a valid argument to such macros).

Implement the changes for __builtin_tgmath.  (The changes also added a
rule that if any argument is _DecimalNx, integer arguments are treated
as _Decimal64x, but GCC doesn't support _DecimalNx types so nothing is
done about that.)

I have a corresponding glibc patch to update glibc test expectations
for C2x and also ensure that appropriate semantics are followed when
GCC 7 through 12 are used with  (avoiding __builtin_tgmath
in cases where it doesn't match the C2x semantics).

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

gcc/
* doc/extend.texi (__builtin_tgmath): Do not restate standard rule
for handling real integer types.

gcc/c/
* c-parser.cc (c_parser_postfix_expression): Handle integer
generic arguments to functions passed to __builtin_tgmath as
_Float32x if any argument has _FloatNx or _Complex _FloatNx type.
Do not handle integer arguments to some narrowing functions as
_Float64.

gcc/testsuite/
* gcc.dg/builtin-tgmath-3.c: Update expectations and add more
tests.

diff --git a/gcc/c/c-parser.cc b/gcc/c/c-parser.cc
index 7d6960fffbb..3a5998007a9 100644
--- a/gcc/c/c-parser.cc
+++ b/gcc/c/c-parser.cc
@@ -10276,16 +10276,17 @@ c_parser_postfix_expression (c_parser *parser)
   types are treated as _Decimal64 if any type-generic
   argument is decimal, or if the only alternatives for
   type-generic arguments are of decimal types, and are
-  otherwise treated as double (or _Complex double for
-  complex integer types, or _Float64 or _Complex _Float64
-  if all the return types are the same _FloatN or
-  _FloatNx type).  After that adjustment, types are
-  combined following the usual arithmetic conversions.
-  If the function only accepts complex arguments, a
-  complex type is produced.  */
+  otherwise treated as _Float32x (or _Complex _Float32x
+  for complex integer types) if any type-generic argument
+  has _FloatNx type, otherwise as double (or _Complex
+  double for complex integer types).  After that
+  adjustment, types are combined following the usual
+  arithmetic conversions.  If the function only accepts
+  complex arguments, a complex type is produced.  */
bool arg_complex = all_complex;
bool arg_binary = all_binary;
bool arg_int_decimal = all_decimal;
+   bool arg_int_floatnx = false;
for (unsigned int j = 1; j <= nargs; j++)
  {
if (parm_kind[j] == tgmath_fixed)
@@ -10380,20 +10381,17 @@ c_parser_postfix_expression (c_parser *parser)
goto out;
  }
  }
+   tree rtype = TYPE_MAIN_VARIANT (type);
+   if (TREE_CODE (rtype) == COMPLEX_TYPE)
+ rtype = TREE_TYPE (rtype);
+   if (SCALAR_FLOAT_TYPE_P (rtype))
+ for (unsigned int j = 0; j < NUM_FLOATNX_TYPES; j++)
+   if (rtype == FLOATNX_TYPE_NODE (j))
+ {
+   arg_int_floatnx = true;
+   break;
+ }
  }
-   /* For a macro rounding its result to a narrower type, map
-  integer types to _Float64 not double if the return type
-  is a _FloatN or _FloatNx type.  */
-   bool arg_int_float64 = false;
-   if 

Re: [PATCH] Darwin, crts: Provide scalb and significand as a crt [PR107631]

[Joseph Myers]

On Tue, 3 Jan 2023, Iain Sandoe wrote:

>  1. Modula-2 should not forward the builtins unless the target supports them,
> either by expansion or the relevant lib functions.  So that would need 
> some
>configury and conditional build code.

Note that such configure tests could only readily be in the library 
configure scripts, not in the compiler configure scripts - you can't do 
target compile or link tests in host-side configure.  (To a limited extent 
it's possible to grep target headers in host-side configure, though not to 
actually preprocess them since the compiler required for such 
preprocessing doesn't exist at that point.)

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [PATCH] Darwin, crts: Provide scalb and significand as a crt [PR107631]

[Joseph Myers]

On Sat, 31 Dec 2022, Iain Sandoe wrote:

> builtins.def unconditionally defines these builtins to be DEF_EXT_LIB_BUILTIN
> which expands to the libcall, this is currently hard-wired to FALLBACK_P = 
> true.
> 
> but, AFAIU the builtins.def descriptions:
> 
>  FALLBACK_P should be false if the libc (or libm, I suppose, if that’s 
> different)
>  does not have the function, perhaps that’s an underlying bug or at least an
>  oversight?
> 
>  (or, of course, I misunderstood the intent of that param)

FALLBACK_P true means that it's the user's responsibility, if calling 
__builtin_X, to make sure the library function X is also available in 
cases where the call doesn't get expected inline - that is, that the API 
for that __builtin_X function is that it may call an underlying library 
function X, which is expected to exist and have a compatible interface.

Information about whether a function is present in libc / libm is 
generally only relevant when __builtin_X might expand to call Y instead of 
X; then GCC needs to know whether Y is available.

> - at present, it seems that this crt might be the least invasive 
> solution (since ‘significand*()’ are not obsolete AFAIU, we still need 
> to provide those implementations, regardless of any subsitution of 
> scalbn*() in Modula-2).

The significand functions can be considered obsolete and were never in any 
standard (thus glibc does not provide a version for _Float128, for 
example).

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [PATCH] Darwin, crts: Provide scalb and significand as a crt [PR107631]

[Joseph Myers]

On Fri, 30 Dec 2022, Iain Sandoe via Gcc-patches wrote:

> This patch is providing functions used by the modula-2 implementation.
> 
> At present, I've used a crt rather than adding symbols to libgcc, since
> it is not clear if the modula-2 might alter the use of scalb to scalbn
> (although that will not solve the missing significand* symbols).
> 
> I plan to apply the patch early next week (it is Darwin-specific) unless
> there are any comments on the implementation.

I think it would be better to change Modula-2 to avoid using these 
obsolescent functions, rather than providing them in GCC.  (But if 
provided, the libgcc runtime license exception should be used.)

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: stdc_bit_ceil(3) and wrapping

[Joseph Myers]

On Fri, 30 Dec 2022, Alejandro Colomar via Gcc wrote:

> For the C standard, shifts have wrap around semantics for unsigned types:

Only if the shift count is nonnegative and strictly less than the width of 
the type.  This is about shifting by an amount equal to the width of the 
type, which has undefined behavior.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: stdc_bit_ceil(3) and wrapping

[Joseph Myers]

On Fri, 30 Dec 2022, Alejandro Colomar via Gcc wrote:

> I was wondering if there was any reason to make that UB in the standard, when
> unsigned wrapping has always been well-defined, and this is a case that is
> likely to be implemented with some operation that wraps around, right?  I

It's likely to be implemented by a shift, that might be by the number of 
bits in the argument in the overflow case, and shift by the width of the 
argument is undefined behavior; some architectures wrap the shift count 
modulo the width (do you actually want 1 or 0 as the result of 
stdc_bit_ceil?), some wrap the shift count modulo a larger value (e.g. 
treating 1 << 32 as 0 but 1 << 64 as 1) and for some architectures the 
result depends on the particular shift instruction used (meaning undefined 
behavior on the form of the result of an integer expression possibly 
comparing unequal to itself because the compiler duplicated the expression 
and then used different instructions to compute it in different places).

> Would you consider either or both of being more generous in the GNU
> implementation and guarantee wrap around, and/or suggest that the standard
> guarantees the wrap around?

The CD ballot has closed, and this doesn't appear to be one of the 338 
comments raised on that ballot, and I don't really expect time at next 
month's meeting to deal with additional technical comments not on that 
list, when we have only 15 hours to deal with 338 comments.  Once we have 
an issue tracking process for the C standard again (hopefully involving an 
issue tracker that the public can readily submit issues in), I'd suggest 
raising such concerns there (unless there's a CD2 ballot; technical 
comments are best avoided at a DIS ballot if possible).

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [RFC/PATCH] Remove the workaround for _Float128 precision [PR107299]

[Joseph Myers]

On Thu, 22 Dec 2022, Segher Boessenkool wrote:

> Hi!
> 
> On Wed, Dec 21, 2022 at 09:40:24PM +0000, Joseph Myers wrote:
> > On Wed, 21 Dec 2022, Segher Boessenkool wrote:
> > > > --- a/gcc/tree.cc
> > > > +++ b/gcc/tree.cc
> > > > @@ -9442,15 +9442,6 @@ build_common_tree_nodes (bool signed_char)
> > > >if (!targetm.floatn_mode (n, extended).exists ())
> > > > continue;
> > > >int precision = GET_MODE_PRECISION (mode);
> > > > -  /* Work around the rs6000 KFmode having precision 113 not
> > > > -128.  */
> > > 
> > > It has precision 126 now fwiw.
> > > 
> > > Joseph: what do you think about this patch?  Is the workaround it
> > > removes still useful in any way, do we need to do that some other way if
> > > we remove this?
> 
> You didn't address these questions.  We don't see negative effects from
> removing this workaround, but it isn't clear (to me) what problems were
> there that caused you to do this workaround.  Do you remember maybe?  Or
> can we just delete it and try to forget such worries :-)

The purpose was to ensure that _Float128's TYPE_PRECISION was at least as 
large as that of long double, in the case where they both have binary128 
format.  I think at that time, in GCC 7, it was possible for _Float128 to 
be KFmode and long double to be TFmode, with those being different modes 
with the same format.

In my view, it would be best not to have different modes with the same 
format - not simply ensure types with the same format have the same mode, 
but avoid multiple modes with the same format existing in the compiler at 
all.  That is, TFmode should be the same mode as one of KFmode and IFmode 
(one name should be defined as a macro for the other name, or something 
similar).  If you don't have different modes with the same format, many of 
the problems go away.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [RFC/PATCH] Remove the workaround for _Float128 precision [PR107299]

[Joseph Myers]

On Wed, 21 Dec 2022, Segher Boessenkool wrote:

> > --- a/gcc/tree.cc
> > +++ b/gcc/tree.cc
> > @@ -9442,15 +9442,6 @@ build_common_tree_nodes (bool signed_char)
> >if (!targetm.floatn_mode (n, extended).exists ())
> > continue;
> >int precision = GET_MODE_PRECISION (mode);
> > -  /* Work around the rs6000 KFmode having precision 113 not
> > -128.  */
> 
> It has precision 126 now fwiw.
> 
> Joseph: what do you think about this patch?  Is the workaround it
> removes still useful in any way, do we need to do that some other way if
> we remove this?

I think it's best for the TYPE_PRECISION, for any type with the binary128 
format, to be 128 (not 126).

It's necessary that _Float128, _Float64x and long double all have the same 
TYPE_PRECISION when they have the same (binary128) format, or at least 
that TYPE_PRECISION for _Float128 >= that for long double >= that for 
_Float64x, so that the rules in c_common_type apply properly.

How the TYPE_PRECISION compares to that of __ibm128, or of long double 
when that's double-double, is less important.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [C PATCH] remove same_translation_unit_p

[Joseph Myers]

On Tue, 20 Dec 2022, Martin Uecker via Gcc-patches wrote:

> Here is a patch to remove the unused function
> same_translation_unit_p and related code. The
> code to check for structural equivalency of
> structs / unions is kept (with some fixes)
> because it will be needed for C2X.

Could you repost this in development stage 1, since this is not a bug fix?

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [PATCH 2/3] Make __float128 use the _Float128 type, PR target/107299

[Joseph Myers]

On Thu, 15 Dec 2022, Kewen.Lin via Gcc-patches wrote:

> By investigating the exposed NaN failures, I found it's due to that it wants
> to convert _Float128 type constant to long double type constant, it goes
> through function real_convert which clears the signalling bit in the context
> of !HONOR_SNANS (arg).
> 
>   if (r->cl == rvc_nan)
> r->signalling = 0;
> 
> The test cases don't have the explicit option -fsignaling-nans, I'm inclined
> to believe it's intentional since there is only a sNaN generation.  If so,
> we don't want this kind of conversion which is useless and can clear 
> signalling
> bit unexpectedly, one shortcut is to just copy the corresponding 
> REAL_VALUE_TYPE
> and rebuild with the given type if the modes are the same.

I think this approach - treating floating-point conversions to a type with 
the same mode consistently as a copy rather than a convertFormat operation 
- is reasonable.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [PATCH Rust front-end v4 46/46] gccrs: Add README, CONTRIBUTING and compiler logo

[Joseph Myers]

On Tue, 13 Dec 2022, Martin Liška wrote:

> If the Rust folks are willing to use Sphinx, then yes, I'm going to 
> prepare a common infrastructure (baseconf.py, common license files and a 
> common Makefile). So something similar to what I prepared for the Sphinx 
> conversion that didn't make it.

I suggest putting this in a directory such as gcc/doc/sphinx/ (rather than 
the top-level doc/ that was used in the Sphinx conversion).

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [PATCH Rust front-end v4 46/46] gccrs: Add README, CONTRIBUTING and compiler logo

[Joseph Myers]

On Fri, 9 Dec 2022, Martin Liška wrote:

> On 12/6/22 11:14, arthur.co...@embecosm.com wrote:
> > |We still need to write out a documentation section, but these READMEs will 
> > help in the meantime.|
> 
> Hello.
> 
> Just a quick comment: The Sphinx conversion didn't make it for all GCC 
> manuals. However, you can still use Sphinx for a newly created manual, 
> similarly to what libgccjit or Ada manuals do.

I would also encourage people using Sphinx for a newly created manual to 
consider setting up common build infrastructure for such manuals, possibly 
based on that used in the attempted Sphinx conversion.  It may be easier 
to get common infrastructure for such manuals into shape if it's initially 
only being used for one or two manuals - that is, if the addition of such 
infrastructure isn't done at the same time as converting any existing 
manuals to use Sphinx, or even converting any existing manuals using 
Sphinx to use such infrastructure.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [PATCH Rust front-end v4 46/46] gccrs: Add README, CONTRIBUTING and compiler logo

[Joseph Myers]

On Fri, 9 Dec 2022, Martin Liška wrote:

> On 12/6/22 11:14, arthur.co...@embecosm.com wrote:
> > |We still need to write out a documentation section, but these READMEs will 
> > help in the meantime.|
> 
> Hello.
> 
> Just a quick comment: The Sphinx conversion didn't make it for all GCC 
> manuals. However, you can still use Sphinx for a newly created manual, 
> similarly to what libgccjit or Ada manuals do.

I would also encourage people using Sphinx for a newly created manual to 
consider setting up common build infrastructure for such manuals, possibly 
based on that used in the attempted Sphinx conversion.  It may be easier 
to get common infrastructure for such manuals into shape if it's initially 
only being used for one or two manuals - that is, if the addition of such 
infrastructure isn't done at the same time as converting any existing 
manuals to use Sphinx, or even converting any existing manuals using 
Sphinx to use such infrastructure.

-- 
Joseph S. Myers
jos...@codesourcery.com-- 
Gcc-rust mailing list
Gcc-rust@gcc.gnu.org
https://gcc.gnu.org/mailman/listinfo/gcc-rust

[committed] c: Diagnose auto constexpr used with a type

[Joseph Myers]

The constraints on auto in C2x disallow use with other storage-class
specifiers unless the type is inferred from an initializer.  That
includes constexpr; add the missing checks for this case (the
combination of auto, constexpr and a type specifier).

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

gcc/c/
* c-decl.cc (declspecs_add_type, declspecs_add_scspec): Check for
auto, constexpr and a type used together.

gcc/testsuite/
* gcc.dg/c2x-constexpr-1.c: Do not use auto, constexpr and a type
together.
* gcc.dg/c2x-constexpr-3.c: Add tests of auto, constexpr and type
used together.

diff --git a/gcc/c/c-decl.cc b/gcc/c/c-decl.cc
index 111f05e2a40..e47ca6718b3 100644
--- a/gcc/c/c-decl.cc
+++ b/gcc/c/c-decl.cc
@@ -11430,6 +11430,10 @@ declspecs_add_type (location_t loc, struct c_declspecs 
*specs,
   else if (specs->thread_p)
error ("%qs used with %",
   specs->thread_gnu_p ? "__thread" : "_Thread_local");
+  else if (specs->constexpr_p)
+   /* auto may only be used with another storage class specifier,
+  such as constexpr, if the type is inferred.  */
+   error ("% used with %");
   else
specs->storage_class = csc_auto;
 }
@@ -12363,6 +12367,10 @@ declspecs_add_scspec (location_t loc,
  return specs;
}
   n = csc_auto;
+  /* auto may only be used with another storage class specifier,
+such as constexpr, if the type is inferred.  */
+  if (specs->constexpr_p)
+   error ("%qE used with %", scspec);
   break;
 case RID_EXTERN:
   n = csc_extern;
@@ -12393,6 +12401,10 @@ declspecs_add_scspec (location_t loc,
error ("%qE used with %", scspec);
   else if (specs->storage_class == csc_typedef)
error ("%qE used with %", scspec);
+  else if (specs->storage_class == csc_auto)
+   /* auto may only be used with another storage class specifier,
+  such as constexpr, if the type is inferred.  */
+   error ("%qE used with %", scspec);
   else if (specs->thread_p)
error ("%qE used with %qs", scspec,
   specs->thread_gnu_p ? "__thread" : "_Thread_local");
diff --git a/gcc/testsuite/gcc.dg/c2x-constexpr-1.c 
b/gcc/testsuite/gcc.dg/c2x-constexpr-1.c
index f7f64e2d300..d43d95ddd7c 100644
--- a/gcc/testsuite/gcc.dg/c2x-constexpr-1.c
+++ b/gcc/testsuite/gcc.dg/c2x-constexpr-1.c
@@ -180,10 +180,10 @@ f0 ()
 {
   constexpr int fv0 = 3;
   static_assert (fv0 == 3);
-  auto constexpr int fv1 = 4;
+  auto constexpr fv1 = 4;
   static_assert (fv1 == 4);
   register constexpr float fv2 = 1.0;
-  constexpr auto int fv3 = 123;
+  constexpr auto fv3 = 123;
   static_assert (fv3 == 123);
   constexpr register void *fv4 = (void *) 0;
   const int *fv5 = &(constexpr int) { 234 };
diff --git a/gcc/testsuite/gcc.dg/c2x-constexpr-3.c 
b/gcc/testsuite/gcc.dg/c2x-constexpr-3.c
index 16e56db2835..29fedc03afd 100644
--- a/gcc/testsuite/gcc.dg/c2x-constexpr-3.c
+++ b/gcc/testsuite/gcc.dg/c2x-constexpr-3.c
@@ -225,4 +225,12 @@ f0 ()
   constexpr typeof (nullptr) not_npc = nullptr;
   int *ptr = 0;
   (void) (ptr == not_npc); /* { dg-error "invalid operands" } */
+  /* auto may only be used with another storage class specifier, such as
+ constexpr, if the type is inferred.  */
+  auto constexpr int a_c_t = 1; /* { dg-error "'auto' used with 'constexpr'" } 
*/
+  constexpr auto int c_a_t = 1; /* { dg-error "'auto' used with 'constexpr'" } 
*/
+  auto int constexpr a_t_c = 1; /* { dg-error "'constexpr' used with 'auto'" } 
*/
+  constexpr int auto c_t_a = 1; /* { dg-error "'auto' used with 'constexpr'" } 
*/
+  int auto constexpr t_a_c = 1; /* { dg-error "'constexpr' used with 'auto'" } 
*/
+  int constexpr auto t_c_a = 1; /* { dg-error "'auto' used with 'constexpr'" } 
*/
 }

-- 
Joseph S. Myers
jos...@codesourcery.com

[committed] testsuite: Add test for C90 auto with implicit int

[Joseph Myers]

Add a test for the case of auto with implicit int in C90 mode, which
is incompatible with C2x semantics (I missed adding such a test when
implementing C2x auto).

Tested for x86_64-pc-linux-gnu.

* gcc.dg/c90-auto-1.c: New test.

diff --git a/gcc/testsuite/gcc.dg/c90-auto-1.c 
b/gcc/testsuite/gcc.dg/c90-auto-1.c
new file mode 100644
index 000..f00f767c50a
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/c90-auto-1.c
@@ -0,0 +1,12 @@
+/* Test auto with implicit int for C90.  */
+/* { dg-do compile } */
+/* { dg-options "-std=c90 -pedantic-errors" } */
+
+void
+f (void)
+{
+  /* This should have type int following C90 rules, whereas in C2x it
+ would have type double.  */
+  auto x = 1.5;
+  int *p = 
+}

-- 
Joseph S. Myers
jos...@codesourcery.com

[committed] preprocessor: Enable __VA_OPT__ for C2x

[Joseph Myers]

C2x supports __VA_OPT__, so adjust libcpp not to pedwarn for uses of
it (or of not passing any variable arguments to a variable-arguments
macro) in standard C2x mode.

I didn't try to duplicate existing tests for the details of the
feature, just verified -pedantic-errors handling is as expected.  And
there's a reasonable argument (bug 98859) that __VA_OPT__ shouldn't be
diagnosed in older standard modes at all (as opposed to not passing
any variable arguments to a variable-arguments macro, for which older
versions of the C standard require a diagnostic as a constraint
violation); that argument applies to C as much as to C++, but I
haven't made any changes in that regard.

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

libcpp/
* init.cc (lang_defaults): Enable va_opt for STDC2X.
* lex.cc (maybe_va_opt_error): Adjust diagnostic message for C.
* macro.cc (_cpp_arguments_ok): Update comment.

gcc/testsuite/
* gcc.dg/cpp/c11-vararg-1.c, gcc.dg/cpp/c2x-va-opt-1.c: New tests.

diff --git a/gcc/testsuite/gcc.dg/cpp/c11-vararg-1.c 
b/gcc/testsuite/gcc.dg/cpp/c11-vararg-1.c
new file mode 100644
index 000..6b1bc38bb2c
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/cpp/c11-vararg-1.c
@@ -0,0 +1,9 @@
+/* Test error in C11 for no arguments passed for variable arguments to a
+   macro.  */
+/* { dg-do preprocess } */
+/* { dg-options "-std=c11 -pedantic-errors" } */
+
+#define M(X, ...) X
+
+M (x); /* { dg-error "requires at least one argument" } */
+M (x, y);
diff --git a/gcc/testsuite/gcc.dg/cpp/c2x-va-opt-1.c 
b/gcc/testsuite/gcc.dg/cpp/c2x-va-opt-1.c
new file mode 100644
index 000..bd438f74571
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/cpp/c2x-va-opt-1.c
@@ -0,0 +1,11 @@
+/* Test __VA_OPT__ and no "..." arguments in a call to a variable-arguments
+   macro accepted for C2X.  */
+/* { dg-do preprocess } */
+/* { dg-options "-std=c2x -pedantic-errors" } */
+
+#define CALL(F, ...) F (7 __VA_OPT__(,) __VA_ARGS__)
+#define M(X, ...) X
+
+CALL (a);
+CALL (b, 1);
+M (x);
diff --git a/libcpp/init.cc b/libcpp/init.cc
index 5f34e3515d2..ea683f0cfaf 100644
--- a/libcpp/init.cc
+++ b/libcpp/init.cc
@@ -114,7 +114,7 @@ static const struct lang_flags lang_defaults[] =
   /* STDC99   */  { 1,  0,  1,  1,  0,  0,1,  1,   0,   0,   0,0, 
0, 1,   0,  0,   0, 0,   0,   0,  0,  0,0 },
   /* STDC11   */  { 1,  0,  1,  1,  1,  0,1,  1,   1,   0,   0,0, 
0, 1,   0,  0,   0, 0,   0,   0,  0,  0,0 },
   /* STDC17   */  { 1,  0,  1,  1,  1,  0,1,  1,   1,   0,   0,0, 
0, 1,   0,  0,   0, 0,   0,   0,  0,  0,0 },
-  /* STDC2X   */  { 1,  0,  1,  1,  1,  1,1,  1,   1,   0,   0,1, 
1, 0,   1,  0,   1, 1,   0,   1,  1,  0,1 },
+  /* STDC2X   */  { 1,  0,  1,  1,  1,  1,1,  1,   1,   0,   0,1, 
1, 0,   1,  1,   1, 1,   0,   1,  1,  0,1 },
   /* GNUCXX   */  { 0,  1,  1,  1,  0,  1,0,  1,   0,   0,   0,0, 
0, 0,   0,  1,   1, 0,   0,   0,  0,  0,1 },
   /* CXX98*/  { 0,  1,  0,  1,  0,  1,1,  1,   0,   0,   0,0, 
0, 1,   0,  0,   1, 0,   0,   0,  0,  0,1 },
   /* GNUCXX11 */  { 1,  1,  1,  1,  1,  1,0,  1,   1,   1,   1,0, 
0, 0,   0,  1,   1, 0,   0,   0,  0,  0,1 },
diff --git a/libcpp/lex.cc b/libcpp/lex.cc
index b1107920c94..9a21a3e9ecc 100644
--- a/libcpp/lex.cc
+++ b/libcpp/lex.cc
@@ -2135,8 +2135,14 @@ maybe_va_opt_error (cpp_reader *pfile)
   /* __VA_OPT__ should not be accepted at all, but allow it in
 system headers.  */
   if (!_cpp_in_system_header (pfile))
-   cpp_error (pfile, CPP_DL_PEDWARN,
-  "__VA_OPT__ is not available until C++20");
+   {
+ if (CPP_OPTION (pfile, cplusplus))
+   cpp_error (pfile, CPP_DL_PEDWARN,
+  "__VA_OPT__ is not available until C++20");
+ else
+   cpp_error (pfile, CPP_DL_PEDWARN,
+  "__VA_OPT__ is not available until C2X");
+   }
 }
   else if (!pfile->state.va_args_ok)
 {
diff --git a/libcpp/macro.cc b/libcpp/macro.cc
index 7d5a0d0fd2e..452e14a1e66 100644
--- a/libcpp/macro.cc
+++ b/libcpp/macro.cc
@@ -1093,7 +1093,7 @@ _cpp_arguments_ok (cpp_reader *pfile, cpp_macro *macro, 
const cpp_hashnode *node
 
   if (argc < macro->paramc)
 {
-  /* In C++20 (here the va_opt flag is used), and also as a GNU
+  /* In C++20 and C2X (here the va_opt flag is used), and also as a GNU
 extension, variadic arguments are allowed to not appear in
 the invocation at all.
 e.g. #define debug(format, args...) something

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: Using [[may_alias]] in C23/C++23 on a union works in neither post-"union" position, or at the end of the definition

[Joseph Myers]

On Mon, 5 Dec 2022, Gavin Ray via Gcc wrote:

> union [[may_alias]] broken2 {};

With [[]] syntax it's [[gnu::may_alias]], since it's not a standard 
attribute.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [PATCH] Various pages: SYNOPSIS: Use VLA syntax in function parameters

[Joseph Myers]

On Sat, 3 Dec 2022, Alejandro Colomar via Gcc wrote:

> What do you think about it?  I'm not asking for your opinion about adding it
> to GCC, but rather for replacing the current '.' in the man-pages before I
> release later this month.  Do you think I should apply that change?

I think man pages should not use any novel syntax - even syntax newly 
added to the C standard or GCC, unless required to express the standard 
prototype for a function.  They should be written for maximal 
comprehensibility to C users in general, who are often behind on knowledge 
standard features let alone the more obscure extensions - and certainly 
don't know about random, highly speculative suggestions for possible 
features suggested in random mailing list threads.  So: don't use any 
invented syntax (even if you explain it somewhere in the man pages), don't 
use any syntax newly introduced in C23 unless strictly necessary and 
you're sure it's already extremely widely understood among C users, be 
wary of syntax introduced in C11.  If a new feature in this area were 
introduced in C29, waiting at least several years after that standard is 
released (*not* just after the feature gets added to a draft) to start 
using the new syntax in man pages would be a good idea.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [PATCH] libcpp: suppress builtin macro redefined warnings for __LINE__

[Joseph Myers]

On Fri, 2 Dec 2022, Longjun Luo via Gcc-patches wrote:

> They are ./gcc/testsuite/gcc.dg/cpp/warn-redefined.c and
> ./gcc/testsuite/gcc.dg/cpp/warn-redefined-2.c
> 
> These two cases redefine the __TIME__ macro when using the option
> '-Wbuiltin-macro-redefined'.
> 
> I think I shoud add a test to verify __LINE__ macro in these two cases.

I think it should be a test that doesn't use either 
-Wbuiltin-macro-redefined or -Wno-builtin-macro-redefined - a test of how 
the compiler behaves by default.

> So, the patch itself has no problem. What I need do is to rich its test cases
> and update change log, right?

The patch needs review, but I'm fine with the principle that 
-Wno-builtin-macro-redefined should apply to __LINE__ as it does to 
various other built-in macros.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [PATCH] libcpp: suppress builtin macro redefined warnings for __LINE__

[Joseph Myers]

On Fri, 2 Dec 2022, Longjun Luo via Gcc-patches wrote:

> 
> On 12/2/2022 1:01 AM, Joseph Myers wrote:
> > On Thu, 1 Dec 2022, Longjun Luo via Gcc-patches wrote:
> > 
> > > diff --git a/gcc/testsuite/gcc.dg/builtin-redefine.c
> > > b/gcc/testsuite/gcc.dg/builtin-redefine.c
> > > index 882b2210992..9d5b42252ee 100644
> > > --- a/gcc/testsuite/gcc.dg/builtin-redefine.c
> > > +++ b/gcc/testsuite/gcc.dg/builtin-redefine.c
> > > @@ -71,7 +71,6 @@
> > >   /* { dg-bogus "Expected built-in is not defined" "" { target *-*-* } .-1
> > > } */
> > >   #endif
> > >   -#define __LINE__ 0   /* { dg-warning "-:\"__LINE__\" redef" }
> > > */
> > >   #define __INCLUDE_LEVEL__ 0  /* { dg-warning "-:\"__INCLUDE_LEVEL__\"
> > > redef" } */
> > >   #define __COUNTER__ 0/* { dg-warning "-:\"__COUNTER__\" redef" }
> > > */
> > Is there some existing test that verifies that this redefinition is still
> > diagnosed by default (in the absence of -Wno-builtin-macro-redefined)?
> 
> I am not sure I have fully understood your meaning. The problem here is that
> if I try to redefine __LINE__ macro in the situation that projects use the
> option '-Werror', the compile will fail.

There are two cases:

(a) Is redefinition of __LINE__ diagnosed *without* 
-Wno-builtin-macro-redefined?

(b) Is redefinition of __LINE__ diagnosed *with* 
-Wno-builtin-macro-redefined?

My understanding is that both (a) and (b) have answer "yes" at present, 
and your patch would change the answer to (b) to "no", without changing 
the answer to (a).

My question is about whether there is a test verifying the answer to (a).  
If not, I think the patch should add one.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [PATCH] libcpp: suppress builtin macro redefined warnings for __LINE__

[Joseph Myers]

On Thu, 1 Dec 2022, Longjun Luo via Gcc-patches wrote:

> diff --git a/gcc/testsuite/gcc.dg/builtin-redefine.c 
> b/gcc/testsuite/gcc.dg/builtin-redefine.c
> index 882b2210992..9d5b42252ee 100644
> --- a/gcc/testsuite/gcc.dg/builtin-redefine.c
> +++ b/gcc/testsuite/gcc.dg/builtin-redefine.c
> @@ -71,7 +71,6 @@
>  /* { dg-bogus "Expected built-in is not defined" "" { target *-*-* } .-1 } */
>  #endif
>  
> -#define __LINE__ 0   /* { dg-warning "-:\"__LINE__\" redef" } */
>  #define __INCLUDE_LEVEL__ 0  /* { dg-warning "-:\"__INCLUDE_LEVEL__\" redef" 
> } */
>  #define __COUNTER__ 0/* { dg-warning "-:\"__COUNTER__\" redef" } */

Is there some existing test that verifies that this redefinition is still 
diagnosed by default (in the absence of -Wno-builtin-macro-redefined)?

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: Java front-end and library patches.

[Joseph Myers]

On Wed, 30 Nov 2022, Zopolis0 via Gcc-patches wrote:

> > * Each patch should have its own explanation of what it is doing and why,
> > in the message body (not in an attachment).  Just the commit summary line
> > and ChangeLog entries aren't enough, we need the actual substantive commit
> > message explaining the patch.
> 
> The thing is, most of the patches do not need an explanation. Patches
> 1-13 are just re-adding code,

Then state that in the message body (with a reference to the commit that 
removed the code).

Just because code was removed in a given form doesn't mean it should be 
added back in that form.  For example, patch 13, "Re-add 
flag_evaluation_order, reorder_operands_p, and add reorder bool argument 
to tree_swap_operands_p", seems suspicious.  That sort of global state 
affecting IR semantics is best avoided; rather, the Java gimplification 
support should deal with ensuring the correct ordering for operations in 
the GIMPLE generated.  Note that C++ flag_strong_eval_order (for C++17 
evaluation order requirements) is specific to the front end; it doesn't 
require anything in expr.cc or fold-const.cc or other language-independent 
files.  So you should do something similar for Java rather than adding 
back global language-independent state for this.

Patches 1 and 2 don't seem to have reached the mailing list.

> 20-43 and 47 are just applying treewide
> changes that Java missed out on,

So say for each one exactly which commit it's applying the changes for.

> > How has the series been validated?
> 
> I'm not exactly sure what you mean by this.

What target triplets did you run the GCC testsuite on (before and after 
the changes, with no regressions), with what results for the Java-specific 
tests?

> I plan to
> replace Classpath with the OpenJDK, and double down on the machine
> code aspect of GCJ, dropping bytecode and interpreted support.

This sort of thing is key information to include in the summary message 
for any future versions of the patch series.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [PATCH] Various pages: SYNOPSIS: Use VLA syntax in function parameters

[Joseph Myers]

On Tue, 29 Nov 2022, Michael Matz via Gcc wrote:

> like.  But I'm generally doubtful of this whole feature within C itself.  
> It serves a purpose in documentation, so in man-pages it seems fine enough 
> (but then still could use a different puncuator to not be confusable with 
> C syntax).

In man-pages you don't need to invent syntax at all.  You can write

int f(char buf[n], int n);

and in the context of a man page it will be clear to readers what is 
meant, though such a syntax would be problematic in actual C source files 
because of issues with circular dependencies between parameters and with n 
already being declared in an outer scope.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [PATCH] Various pages: SYNOPSIS: Use VLA syntax in function parameters

[Joseph Myers]

On Tue, 29 Nov 2022, Alex Colomar via Gcc wrote:

> I guess asking the compiler to do two passes on the param list isn't as bad as
> asking to do unbound lookahead.  In this case it's bound:  look ahead till the
> end of the param list; get as much info as possible, and then do it again to
> complete.  Anything not yet clear after two passes is not valid.

Unbounded here means an unbounded number of tokens, as opposed to e.g. 
looking one token ahead after seeing an identifier in statement context to 
determine if it's a label.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: Java front-end and library patches.

[Joseph Myers]

On Fri, 25 Nov 2022, Zopolis0 via Gcc-patches wrote:

> Firstly, to get feedback and reviews on the 56 already existing
> patches, even though most are just re-adding code or making idiomatic
> changes, so that when the final issue is solved everything has already
> been approved (hopefully) and the merge is good to go.

I think a lot more explanation is needed to get much useful feedback.

* Each patch should have its own explanation of what it is doing and why, 
in the message body (not in an attachment).  Just the commit summary line 
and ChangeLog entries aren't enough, we need the actual substantive commit 
message explaining the patch.

* An overall explanation is needed of what the patch series is doing and 
why.  Why is it now considered useful to add this front end back?  Which 
version is the basis of the one being added back - the version removed 
from GCC (that used ECJ for converting Java source to Java byte-code), or 
some other version?  How has the series been validated?  Would you propose 
to maintain the front end and libraries in future?  Would you re-open any 
bugs against the front end or libraries that were closed (as WONTFIX or 
otherwise) as a result of it being removed from the tree (maybe when it 
was removed, maybe later when the last release series with the front end 
ceased to be supported)?  And so on.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [PATCH] c: Fix compile time hog in c_genericize [PR107127]

[Joseph Myers]

On Wed, 23 Nov 2022, Jakub Jelinek via Gcc-patches wrote:

> Hi!
> 
> The complex multiplications result in deeply nested set of many SAVE_EXPRs,
> which takes even on fast machines over 5 minutes to walk.
> This patch fixes that by using walk_tree_without_duplicates where it is
> instant.
> 
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
> 
> 2022-11-23  Andrew Pinski  
>   Jakub Jelinek  
> 
>   PR c/107127
>   * c-gimplify.cc (c_genericize): Use walk_tree_without_duplicates
>   instead of walk_tree for c_genericize_control_r.
> 
>   * gcc.dg/pr107127.c: New test.

OK.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [PATCH] c: Propagate erroneous types to declaration specifiers [PR107805]

[Joseph Myers]

On Tue, 22 Nov 2022, Florian Weimer via Gcc-patches wrote:

> Without this change, finish_declspecs cannot tell that whether there
> was an erroneous type specified, or no type at all.  This may result
> in additional diagnostics for implicit ints, or missing diagnostics
> for multiple types.
> 
>   PR c/107805
> 
> gcc/c/
>   * c-decl.cc (declspecs_add_type): Propagate error_mark_bode
>   from type to specs.
> 
> gcc/testsuite/
>   * gcc.dg/pr107805-1.c: New test.
>   * gcc.dg/pr107805-1.c: Likewise.

OK.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [PATCH] range-op: Implement floating point division fold_range [PR107569]

[Joseph Myers]

On Tue, 22 Nov 2022, Jan-Benedict Glaw wrote:

> I'm running a slightly hacked [glibc]/scripts/build-many-glibcs.py to
> to CI builds for glibc as well by now (hacked to allow for GCC master
> being used) and this GCC commit
> (2d5c4a16dd833aa083f13dd3e78e3ef38afe6ebb) triggers glibc's
> elf/check-localplt testcase to fail, though just for
> sparc64-linux-gnu. (As I just started with glibc checks, it took me a
> while to realize this was a real regression and not a flaw in my
> setup.)

I think the appropriate fix is to update the relevant localplt.data (to 
add the relevant libgcc symbol marked with "?" as optional), I don't think 
there's a GCC bug here.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [PATCH] [range-ops] Implement sqrt.

[Joseph Myers]

On Thu, 17 Nov 2022, Jakub Jelinek via Gcc-patches wrote:

> On Thu, Nov 17, 2022 at 06:59:45PM +0000, Joseph Myers wrote:
> > On Thu, 17 Nov 2022, Aldy Hernandez via Gcc-patches wrote:
> > 
> > > So... is the optimization wrong?  Are we not allowed to substitute
> > > that NAN if we know it's gonna happen?  Should we also allow F F F F F
> > > in the test?  Or something else?
> > 
> > This seems like the usual ambiguity about what transformations 
> > -ftrapping-math (on by default) is meant to prevent.
> > 
> > Generally it's understood to prevent transformations that add *or remove* 
> > exceptions, so folding a case that raises "invalid" to a NaN (with 
> > "invalid" no longer raised) is invalid with -ftrapping-math.  But that 
> > doesn't tend to be applied if the operation raising the exceptions has a 
> > result that is otherwise unused - in such a case the operation may still 
> > be removed completely (the exception isn't properly treated as a side 
> > effect to avoid dead code elimination; cf. Marc Glisse's -ffenv-access 
> > patches from August 2020).  And it may often also not be applied to 
> > "inexact".
> 
> The problem is that the above model I'm afraid is largely incompatible with
> the optimizations ranger provides.

That model is more an empirical description of when the nominal 
-ftrapping-math semantics tend to be respected, than a coherent design for 
any kind of API commitment to what the option does or what the default 
trapping-math rules are.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [PATCH] [range-ops] Implement sqrt.

[Joseph Myers]

On Thu, 17 Nov 2022, Aldy Hernandez via Gcc-patches wrote:

> So... is the optimization wrong?  Are we not allowed to substitute
> that NAN if we know it's gonna happen?  Should we also allow F F F F F
> in the test?  Or something else?

This seems like the usual ambiguity about what transformations 
-ftrapping-math (on by default) is meant to prevent.

Generally it's understood to prevent transformations that add *or remove* 
exceptions, so folding a case that raises "invalid" to a NaN (with 
"invalid" no longer raised) is invalid with -ftrapping-math.  But that 
doesn't tend to be applied if the operation raising the exceptions has a 
result that is otherwise unused - in such a case the operation may still 
be removed completely (the exception isn't properly treated as a side 
effect to avoid dead code elimination; cf. Marc Glisse's -ffenv-access 
patches from August 2020).  And it may often also not be applied to 
"inexact".

There have been various past discussions of possible ways to split up the 
different effects of options such as -ftrapping-math into finer-grained 
options allowing more control of what transformations are permitted - see 
e.g. 
 
and bug 54192.  There is also the question in that context of which 
sub-options should be enabled by default at all.

-- 
Joseph S. Myers
jos...@codesourcery.com

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

[Joseph Myers]

diff --git a/htdocs/gcc-13/changes.html b/htdocs/gcc-13/changes.html
index 41d07e57..d033628b 100644
--- a/htdocs/gcc-13/changes.html
+++ b/htdocs/gcc-13/changes.html
@@ -112,9 +112,41 @@ a work-in-progress.
 
   https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3042.htm;>N3042,
  Introduce the nullptr constant
+  https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2963.htm;>N2963,
+  Enhanced Enumerations (fixed underlying types)
+  https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2975.pdf;>N2975,
+   Relax requirements for variadic parameter lists
+  https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3007.htm;>N3007,
+  Type inference for object definitions (auto)
+  https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3018.htm;>N3018,
+   The constexpr specifier for object definitions
+  https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3038.htm;>N3038,
+   Introduce storage-class specifiers for compound literals
+  typeof (previously supported as an extension)
+   and typeof_unqual
+  New
+   keywords alignas, alignof, bool,
+   false, static_assert, 
thread_local,
+   true
+  https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2764.pdf;>N2764,
+  The noreturn attribute
   Support for empty initializer braces
+  __STDC_VERSION_*_H__ header version macros
+  Removal of ATOMIC_VAR_INIT
+  unreachable macro
+  in stddef.h
+  Removal of trigraphs
+  Removal of unprototyped functions
+  printf and scanf format checking
+  with -Wformat for %wN
+  and %wfN format length modifiers
+  https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2836.pdf;>N2836,
+   Identifier Syntax using Unicode Standard Annex 31
 
   
+  In addition to those C23 features, existing features adopted in
+  C23 have been adjusted to follow C23 requirements and are not diagnosed
+  with -std=c2x -Wpedantic.
   New warnings:
 
   -Wenum-int-mismatch warns about mismatches between an

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [PATCH] [range-ops] Implement sqrt.

[Joseph Myers]

On Sun, 13 Nov 2022, Jakub Jelinek via Gcc-patches wrote:

> So, I wonder if we don't need to add a target hook where targets will be
> able to provide upper bound on error for floating point functions for
> different floating point modes and some way to signal unknown accuracy/can't
> be trusted, in which case we would give up or return just the range for
> VARYING.

Note that the figures given in the glibc manual are purely empirical 
(largest errors observed for inputs in the glibc testsuite on a system 
that was then used to update the libm-test-ulps files); they don't 
constitute any kind of guarantee about either the current implementation 
or the API, nor are they formally verified, nor do they come from 
exhaustive testing (though worst cases from exhaustive testing for float 
may have been added to the glibc testsuite in some cases).  (I think the 
only functions known to give huge errors for some inputs, outside of any 
IBM long double issues, are the Bessel functions and cpow functions.  But 
even if other functions don't have huge errors, and some 
architecture-specific implementations might have issues, there are 
certainly some cases where errors can exceed the 9ulp threshold on what 
the libm tests will accept in libm-test-ulps files, which are thus 
considered glibc bugs.  (That's 9ulp from the correctly rounded value, 
computed in ulp of that value.  For IBM long double it's 16ulp instead, 
treating the format as having a fixed 106 bits of precision.  Both figures 
are empirical ones chosen based on what bounds sufficed for most libm 
functions some years ago; ideally, with better implementations of some 
functions we could probably bring those numbers down.))

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [PATCH 1/5] c: Set the locus of the function result decl

[Joseph Myers]

On Sun, 13 Nov 2022, Bernhard Reutner-Fischer via Gcc-patches wrote:

> Bootstrapped and regtested on x86_86-unknown-linux with no regressions.
> Ok for trunk?
> 
> Cc: Joseph Myers 
> ---
> gcc/c/ChangeLog:
> 
>   * c-decl.cc (start_function): Set the result decl source
>   location to the location of the typespec.

OK.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [PATCH] Various pages: SYNOPSIS: Use VLA syntax in function parameters

[Joseph Myers]

On Mon, 14 Nov 2022, Alejandro Colomar via Gcc wrote:

> > To quote the convenor in WG14 reflector message 18575 (17 Nov
> > 2020) when I asked about its status, "The author asked me not to put those
> > on the agenda.  He will supply updated versions later.".
> 
> Since his email is not in the paper, would you mind forwarding him this
> suggestion of mine of renaming it to avoid confusion with string lengths?  Or
> maybe point him to the mailing list discussion[1]?
> 
> [1]:
> 

I don't have his email address (I don't see any emails from him on the 
reflector since I joined it in 2001).

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [BUG] README: Reference to non-existent path?

[Joseph Myers]

On Mon, 14 Nov 2022, Alejandro Colomar via Gcc wrote:

> Okay, let's see the online readable version of the manual:
> 
> $ ls gcc/doc/gcc.info*
> ls: cannot access 'gcc/doc/gcc.info*': No such file or directory

That reference is for releases - those files are in release tarballs, but 
not in git or snapshots.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [PATCH] Various pages: SYNOPSIS: Use VLA syntax in function parameters

[Joseph Myers]

On Sun, 13 Nov 2022, Alejandro Colomar via Gcc wrote:

> SYNOPSIS:
> 
> unary-operator:  . identifier

That's not what you mean.  See the standard syntax.

unary-expression:
  [other alternatives]
  unary-operator cast-expression

unary-operator: one of
  & * + - ~ !

> -  It is not an lvalue.
> 
>-  This means sizeof() and _Lengthof() cannot be applied to them.

sizeof can be applied to non-lvalues.

>-  This prevents ambiguity with a designator in an initializer-list within
> a nested braced-initializer.

No, it doesn't.  See my previous points about syntactic disambiguation 
being a separate matter from "one parse would result in a constraint 
violation, so choose another parse that doesn't" (necessarily, because the 
constraint violation that results could in general be at an arbitrary 
distance from the point where a choice of parse has to be made).  Or see 
e.g. the disambiguation rule about enum type specifiers: there is an 
explicit rule "If an enum type specifier is present, then the longest 
possible sequence of tokens that can be interpreted as a specifier 
qualifier list is interpreted as part of the enum type specifier." that 
ensures that "enum e : long int;" interprets "long int" as the enum type 
specifier, rather than "long" as the enum type specifier and "int" as 
another type specifier in the sequence of declaration specifiers, even 
though the latter parse would result in a constraint violation later.

Also, requiring unbounded lookahead to determine what kind of construct is 
being parsed may be considered questionable for C.  (If you have an 
initializer starting .a.b.c.d.e, possibly with array element access as 
well, those could all be designators or .a might be a reference to a 
parameter of struct or union type and .b.c.d.e a sequence of references to 
members within it and disambiguation under your rule would depend on 
whether an '=' follows such an unbounded sequence.)

> -  The type of a .identifier is always an incomplete type.
> 
>-  This prevents circular dependencies involving sizeof() or _Lengthof().

We have typeof as well, which can be applied to expressions with 
incomplete type.

> -  Shadowing rules apply.
> 
>-  This prevents ambiguity.

"Shadowing rules apply" isn't much of a specification.  You need detailed 
wording that would be added to 6.2.1 Scopes of identifiers (or equivalent 
elsewhere) to make it clear exactly what scopes apply for identifiers 
looked up using this construct.

>-
>void foo(struct bar { int x; char c[.x] } a, int x);
> 
>Explanation:
>-  Because of shadowing rules, [.x] refers to the struct member.

I really don't think standardizing VLAs-in-structures would be a good 
idea.  Certainly it would be a massive pain to specify meaningful 
semantics for them and this outline doesn't even attempt to work through 
the consequences of removing the rule that "If an identifier is declared 
as having a variably modified type, it shall be an ordinary identifier (as 
defined in 6.2.3), have no linkage, and have either block scope or 
function prototype scope.".

The idea that .x as an expression might refer to either a member or a 
parameter is also a massive change to the namespace rules, where at 
present those are in completely different namespaces and so in any given 
context a name only needs looking up as one or the other.

Again, proposals should be *minimal*.  And even when they are, many issues 
may well arise in practice (see the long list of constexpr issues in my 
commit message for that C2x feature, for example, which I expect to turn 
into multiple NB comments and at least two accompanying documents).

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [PATCH] Various pages: SYNOPSIS: Use VLA syntax in function parameters

[Joseph Myers]

On Sun, 13 Nov 2022, Alejandro Colomar via Gcc wrote:

> Maybe allowing integral types and pointers would be enough.  However,
> foreseeing that the _Lengthof() proposal (BTW, which paper was it?) will
> succeed, and combining it with this one, _Lengthof(pointer) would ideally give
> the length of the array, so allowing pointers would conflict.

Do you mean N2529 Romero, New pointer-proof keyword to determine array 
length?  To quote the convenor in WG14 reflector message 18575 (17 Nov 
2020) when I asked about its status, "The author asked me not to put those 
on the agenda.  He will supply updated versions later.".

-- 
Joseph S. Myers
jos...@codesourcery.com

ginclude: C2x header version macros

[Joseph Myers]

C2x adds __STDC_VERSION_*_H__ macros to individual headers with
interface changes compared to C17.  All the new header features in
headers provided by GCC have now been implemented, so define those
macros to the value given in the current working draft.

Bootstrapped with no regressions for x86_64-pc-linux-gnu.  OK to
commit?

gcc/
* ginclude/float.h [__STDC_VERSION__ > 201710L]
(__STDC_VERSION_FLOAT_H__): New macro.
* ginclude/stdarg.h [__STDC_VERSION__ > 201710L]
(__STDC_VERSION_STDARG_H__): New macro.
* ginclude/stdatomic.h [__STDC_VERSION__ > 201710L]
(__STDC_VERSION_STDATOMIC_H__): New macro.
* ginclude/stddef.h [__STDC_VERSION__ > 201710L]
(__STDC_VERSION_STDDEF_H__): New macro.
* ginclude/stdint-gcc.h [__STDC_VERSION__ > 201710L]
(__STDC_VERSION_STDINT_H__): New macro.
* glimits.h [__STDC_VERSION__ > 201710L]
(__STDC_VERSION_LIMITS_H__): New macro.

gcc/testsuite/
* gcc.dg/c11-float-8.c, gcc.dg/c11-limits-1.c,
gcc.dg/c11-stdarg-4.c, gcc.dg/c11-stdatomic-3.c,
gcc.dg/c11-stddef-1.c, gcc.dg/c11-stdint-1.c,
gcc.dg/c2x-float-13.c, gcc.dg/c2x-limits-1.c,
gcc.dg/c2x-stdarg-5.c, gcc.dg/c2x-stdatomic-1.c,
gcc.dg/c2x-stddef-1.c, gcc.dg/c2x-stdint-1.c: New tests.

diff --git a/gcc/ginclude/float.h b/gcc/ginclude/float.h
index bc5439d664f..172b9de477f 100644
--- a/gcc/ginclude/float.h
+++ b/gcc/ginclude/float.h
@@ -624,4 +624,8 @@ see the files COPYING3 and COPYING.RUNTIME respectively.  
If not, see
 
 #endif /* __DEC32_MANT_DIG__ */
 
+#if defined __STDC_VERSION__ && __STDC_VERSION__ > 201710L
+#define __STDC_VERSION_FLOAT_H__   202311L
+#endif
+
 #endif /* _FLOAT_H___ */
diff --git a/gcc/ginclude/stdarg.h b/gcc/ginclude/stdarg.h
index c704c9ffcf2..5149f7b3f4f 100644
--- a/gcc/ginclude/stdarg.h
+++ b/gcc/ginclude/stdarg.h
@@ -125,6 +125,10 @@ typedef __gnuc_va_list va_list;
 
 #endif /* not __svr4__ */
 
+#if defined __STDC_VERSION__ && __STDC_VERSION__ > 201710L
+#define __STDC_VERSION_STDARG_H__  202311L
+#endif
+
 #endif /* _STDARG_H */
 
 #endif /* not _ANSI_STDARG_H_ */
diff --git a/gcc/ginclude/stdatomic.h b/gcc/ginclude/stdatomic.h
index a56ba5d9639..e16b072ccde 100644
--- a/gcc/ginclude/stdatomic.h
+++ b/gcc/ginclude/stdatomic.h
@@ -248,4 +248,8 @@ extern void atomic_flag_clear (volatile atomic_flag *);
 extern void atomic_flag_clear_explicit (volatile atomic_flag *, memory_order);
 #define atomic_flag_clear_explicit(PTR, MO)   __atomic_clear ((PTR), (MO))
 
+#if defined __STDC_VERSION__ && __STDC_VERSION__ > 201710L
+#define __STDC_VERSION_STDATOMIC_H__   202311L
+#endif
+
 #endif  /* _STDATOMIC_H */
diff --git a/gcc/ginclude/stddef.h b/gcc/ginclude/stddef.h
index 2767edf51de..7980045e712 100644
--- a/gcc/ginclude/stddef.h
+++ b/gcc/ginclude/stddef.h
@@ -454,6 +454,7 @@ typedef struct {
 
 #if defined __STDC_VERSION__ && __STDC_VERSION__ > 201710L
 #define unreachable() (__builtin_unreachable ())
+#define __STDC_VERSION_STDDEF_H__  202311L
 #endif
 
 #endif /* _STDDEF_H was defined this time */
diff --git a/gcc/ginclude/stdint-gcc.h b/gcc/ginclude/stdint-gcc.h
index 6be01ae28b8..eab651d968a 100644
--- a/gcc/ginclude/stdint-gcc.h
+++ b/gcc/ginclude/stdint-gcc.h
@@ -362,4 +362,8 @@ typedef __UINTMAX_TYPE__ uintmax_t;
 
 #endif
 
+#if defined __STDC_VERSION__ && __STDC_VERSION__ > 201710L
+#define __STDC_VERSION_STDINT_H__  202311L
+#endif
+
 #endif /* _GCC_STDINT_H */
diff --git a/gcc/glimits.h b/gcc/glimits.h
index 8d74c8b88d6..994f7e33bbe 100644
--- a/gcc/glimits.h
+++ b/gcc/glimits.h
@@ -156,6 +156,8 @@ see the files COPYING3 and COPYING.RUNTIME respectively.  
If not, see
 # define BOOL_MAX 1
 # undef BOOL_WIDTH
 # define BOOL_WIDTH 1
+
+# define __STDC_VERSION_LIMITS_H__ 202311L
 #endif
 
 #endif /* _LIMITS_H___ */
diff --git a/gcc/testsuite/gcc.dg/c11-float-8.c 
b/gcc/testsuite/gcc.dg/c11-float-8.c
new file mode 100644
index 000..7fb1e0a5683
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/c11-float-8.c
@@ -0,0 +1,9 @@
+/* Test __STDC_VERSION_FLOAT_H__ not in C11.  */
+/* { dg-do preprocess } */
+/* { dg-options "-std=c11 -pedantic-errors" } */
+
+#include 
+
+#ifdef __STDC_VERSION_FLOAT_H__
+#error "__STDC_VERSION_FLOAT_H__ defined"
+#endif
diff --git a/gcc/testsuite/gcc.dg/c11-limits-1.c 
b/gcc/testsuite/gcc.dg/c11-limits-1.c
new file mode 100644
index 000..6dc5737024d
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/c11-limits-1.c
@@ -0,0 +1,9 @@
+/* Test __STDC_VERSION_LIMITS_H__ not in C11.  */
+/* { dg-do preprocess } */
+/* { dg-options "-std=c11 -pedantic-errors" } */
+
+#include 
+
+#ifdef __STDC_VERSION_LIMITS_H__
+#error "__STDC_VERSION_LIMITS_H__ defined"
+#endif
diff --git a/gcc/testsuite/gcc.dg/c11-stdarg-4.c 
b/gcc/testsuite/gcc.dg/c11-stdarg-4.c
new file mode 100644
index 000..06bff1f0445
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/c11-stdarg-4.c
@@ -0,0 +1,9 @@
+/* Test __STDC_VERSION_STDARG_H__ not in C11.  */

Re: [PATCH] Various pages: SYNOPSIS: Use VLA syntax in function parameters

[Joseph Myers]

On Sat, 12 Nov 2022, Alejandro Colomar via Gcc wrote:

> > > No, assigning to a function parameter from within another parameter
> > > declaration wouldn't make sense.  They should be readonly.  Side effects
> > > should be forbidden, I think.
> > 
> > Such assignments are already allowed.  In a function definition, the side
> > effects (including in size expressions for array parameters adjusted to
> > pointers) take place before entry to the function body.
> 
> Then, I'm guessing that rules need to change in a way that .initializer cannot
> appear as the left operand of an assignment-expression.

I think needing such a very special case rule tends to indicate that some 
alternative syntax, not needing such a rule, would be better.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [PATCH] Various pages: SYNOPSIS: Use VLA syntax in function parameters

[Joseph Myers]

On Sat, 12 Nov 2022, Alejandro Colomar via Gcc wrote:

> Since it's to be used as an rvalue, not as a lvalue, I guess a
> postfix-expression wouldn't be the right one.

Several forms of postfix-expression are only rvalues.

> > (with a special rule about how the identifier is interpreted, different
> > from the normal scope rules)?  If so, then ".a = 1" could either match
> > assignment-expression directly (assigning to the postfix-expression ".a").
> 
> No, assigning to a function parameter from within another parameter
> declaration wouldn't make sense.  They should be readonly.  Side effects
> should be forbidden, I think.

Such assignments are already allowed.  In a function definition, the side 
effects (including in size expressions for array parameters adjusted to 
pointers) take place before entry to the function body.

And, in any case, if you did have a constraint disallowing such 
assignments, it wouldn't suffice for syntactic disambiguation (see the 
previous point I made about that; I have some rough notes towards a WG14 
paper on syntactic disambiguation, but haven't converted them into a 
coherent paper).

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [PATCH] Various pages: SYNOPSIS: Use VLA syntax in function parameters

[Joseph Myers]

On Sat, 12 Nov 2022, Alejandro Colomar via Gcc wrote:

> > struct s { int a; };
> > void f(int a, int b[((struct s) { .a = 1 }).a]);
> 
> Is it really ambiguous?  Let's show some currently-valid code:

Well, I still don't know what the syntax addition you propose is.  Is it

postfix-expression : . identifier

(with a special rule about how the identifier is interpreted, different 
from the normal scope rules)?  If so, then ".a = 1" could either match 
assignment-expression directly (assigning to the postfix-expression ".a").  
Or it could match designation[opt] initializer, where ".a" is a 
designator.  And as I've noted many times in discussions of C2x proposals 
on the WG14 reflector, if some sequence of tokens can match the syntax in 
more than one way, there always needs to be explicit normative text to 
disambiguate the intended parse - it's not enough that one parse might 
lead later to a violation of some other constraint (not that either parse 
leads to a constraint violation in this case).

Or is the syntax

array-declarator : direct-declarator [ . assignment-expression ]

(with appropriate variants with static and type-qualifier-list and for 
array-abstract-declarator as well, and with different identifier 
interpretation rules inside the assignment-expression)?  If so, then there 
are big problems parsing [ . ( a ) + ( b ) ], where 'a' is a typedef name 
in an outer scope, because the appropriate parse would depend on whether 
'a' is shadowed by a parameter - unless of course you add appropriate 
wording like that present in some places about not being able to use this 
syntax to shadow a typedef name.

Or is it just

array-declarator : direct-declarator [ . identifier ]

which might avoid some of these problems at the expense of being less 
expressive?

If you're proposing a C syntax addition, you always need to be clear about 
exactly what the new cases in the syntax would be, and how you resolve 
ambiguities with any other existing part of the syntax, how you interact 
with rules on scopes, namespaces and linkage of identifiers, etc.

-- 
Joseph S. Myers
jos...@codesourcery.com

c: C2x constexpr

[Joseph Myers]

[Global / middle-end reviewers, note there is a dfp.cc change here
that needs review.]

Implement C2x constexpr (a feature based on the C++ one but much more
minimal, with only constexpr variables, not functions).

I believe this implementation is fully functional for use of this
feature.  However, there are several things that seem unclear about
the specification that I'll need to raise in NB comments.  There are
also areas where there may be followup bug fixes because the
implementation doesn't reject some more obscure cases that ought to be
rejected: cases where a constexpr initializer for floating type meets
the constraints for a constant expression in initializers but not
those for an arithmetic constant expression (previously we haven't had
to track whether something is an arithmetic constant expression in
detail, unlike with integer constant expressions), and some cases
where a tag or struct or union member gets declared indirectly in the
declaration specifiers or declarator of a constexpr declaration, which
is not permitted (modulo lack of clarity in the specification) for
underspecified declarations in general (the cases of a declaration in
the initializer, or a tagged type being directly declared as a type
specifier, are already detected).

Cases of ambiguity in the specification include:

* Many questions (previously raised in WG14 discussions) over the rule
  about what conversions do or do not involve a change of value that's
  not allowed in a constexpr initializer, that aren't properly
  addressed by the normative text (and where the footnote on the
  subject isn't very clear either, and the examples don't necessarily
  follow from the normative text).  I've made a series of choices
  there, that include disallowing all conversions between real and
  complex types or between binary and decimal floating types in
  constexpr initializers, that might not necessarily agree with how
  things end up getting clarified.

  The dfp.cc change also arises here, to allow quiet NaN initializers
  of one DFP type to be used in a constexpr initializer for another
  DFP type (as is possible for signaling NaNs) by ensuring the result
  of such a conversion is properly marked as canonical (note that most
  of the DFP code doesn't actually do anything with NaN payloads at
  all).

* Various issues with what exactly counts as part of a declaration for
  the purposes of the rule on underspecified declarations not
  declaring any identifiers other than ordinary identifiers (and not
  declaring more than one ordinary identifier, though the latter is
  undefined behavior).  These include cases where the declaration of a
  struct / union / enum type appears inside typeof or alignas in the
  declaration specifiers (the latter also applies with auto), or in
  the declarator (e.g. an array size or in a parameter declaration).
  The issues are similar to those involved in C90 DR#115 and C99 DRs
  #277 and #341; the intent may not be the same in all the different
  cases involved, but it's not clear that the normative wording in the
  various places is sufficient to deduce the differences in intent.

* The wording about producing a compound literal constant using member
  access is present in one place but another place only applies that
  to named constants.

* It's not clear when a structure or union constant (a constexpr
  variable or compound literal with structure or union type, or a
  member with such type extracted by a series of member access
  operations) can itself be used in an initializer (constexpr or
  otherwise).  Based on general wording for initializers not having
  been changed, the working draft might only strictly allow it at
  automatic storage duration (but elsewhere it would be undefined
  behavior, not a constraint violation, so no diagnostic required) -
  since that's the only case mentioned where a single expression of
  structure or union type can be used to initialize an object of such
  a type.  But it definitely seems to be allowed in even constexpr
  initializers at automatic storage duration - and since generally
  constexpr initializers (any storage duration) are *more* constrained
  than ordinary static storage duration initializers, it would seem
  odd for it not to be allowed at static storage duration.

* When you do allow such initializers, it's then not entirely clear
  how the constraint that constexpr pointer initializers must be null
  pointer constants should be applied (given that a constexpr object
  of pointer type is a null pointer but *not* a null pointer
  constant).  My guess would be that a constexpr struct or union
  containing such a field should still be allowed as an initializer,
  but the wording could be read otherwise.

* It also becomes important with constexpr exactly what kind of
  constant expression an implicit zero initializer is; the wording for
  default initialization only really deals with the value of the
  initializer and not what kind of constant it