Re: [PATCH] [X86_64]: Enable support for next generation AMD Zen3 CPU

[Joseph Myers]

On Fri, 4 Dec 2020, Richard Biener via Gcc-patches wrote:

> Per rule changes to targets are allowed at any point per discretion of target
> maintainers.  Heck, we even accept _new_ targets during stage3/4!

For architectures that are neither primary nor secondary targets, that's 
definitely the case (the other side being that if the maintainer keeps 
putting major changes in and as a result the back-end is unstable at the 
time of branching, the branch won't be delayed for that).

For primary and secondary architectures, more care is needed to consider 
the risk of a change (but basic enabling for a new processor as in this 
patch is certainly on the safer side).

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

Re: V3 [PATCH] Use SHF_GNU_RETAIN to preserve symbol definitions

[Joseph Myers]

On Wed, 2 Dec 2020, H.J. Lu via Gcc-patches wrote:

> > Not sure if this is a GCC bug or indicates that glibc's libc_freeres_fn or
> > related macros need to change to work with both old and new GCC.
> 
> We may need to update glibc for GCC 11.  Can you open a glibc bug and
> CC me?

https://sourceware.org/bugzilla/show_bug.cgi?id=27002

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

Re: V3 [PATCH] Use SHF_GNU_RETAIN to preserve symbol definitions

[Joseph Myers]

This patch (GCC commit 6fbec038f7a7ddf29f074943611b53210d17c40c) has 
broken the glibc build (at least with current binutils master).  The 
errors are of the form:

In file included from :
gconv_dl.c: In function 'free_mem':
gconv_dl.c:202:18: error: 'free_mem' causes a section type conflict with 
'do_release_all'
  202 | libc_freeres_fn (free_mem)
  |  ^~~~
./../include/libc-symbols.h:316:15: note: in definition of macro 
'libc_freeres_fn'
  316 |   static void name (void)
  |   ^~~~
gconv_dl.c:191:1: note: 'do_release_all' was declared here
  191 | do_release_all (void *nodep)
  | ^~

Not sure if this is a GCC bug or indicates that glibc's libc_freeres_fn or 
related macros need to change to work with both old and new GCC.

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

Re: [pushed] Darwin, D : Adjust the X spec to cater for duplicate use.

[Joseph Myers]

On Tue, 1 Dec 2020, Iain Sandoe wrote:

> Joseph; I don’t know if you have any advice on a ‘better’ long-term
> solution; in some ways I am surprised that the compiler built with
> duplicate specifications for a flag - perhaps the uses merged in some
> way.  Since the use of ‘X’ in D is an upstream decision and the use of

It's fine to have an option supported by multiple languages (here Driver 
counts as a language) as long as the syntax in each language (regarding 
any option arguments etc.) is compatible.  There are several options that 
are language-specific options for C-family languages and for Fortran, but 
not for other languages, for example.

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

preprocessor: Fix #line overflow check [PR97602]

[Joseph Myers]

The preprocessor check for overflow (of linenum_type = unsigned int)
when reading the line number in a #line directive is incomplete; it
checks "reg < reg_prev" which doesn't cover all cases where
multiplying by 10 overflowed.  Fix this by checking for overflow
before rather than after it occurs (using essentially the same logic
as used by e.g. glibc printf when reading width and precision values
from strings).

Bootstrapped with no regressions for x86_64-pc-linux-gnu.  Applied to 
mainline.

libcpp/
2020-11-27  Joseph Myers  

PR preprocessor/97602
* directives.c (strtolinenum): Check for overflow before it
occurs.  Correct comment.

gcc/testsuite/
2020-11-27  Joseph Myers  

PR preprocessor/97602
* gcc.dg/cpp/line9.c, gcc.dg/cpp/line10.c: New tests.

diff --git a/gcc/testsuite/gcc.dg/cpp/line10.c 
b/gcc/testsuite/gcc.dg/cpp/line10.c
new file mode 100644
index 000..9f5f0799847
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/cpp/line10.c
@@ -0,0 +1,5 @@
+/* Test #line overflow checks: bug 97602.  */
+/* { dg-do preprocess } */
+/* { dg-options "-pedantic" } */
+
+#line 4294967296 /* { dg-warning "line number out of range" } */
diff --git a/gcc/testsuite/gcc.dg/cpp/line9.c b/gcc/testsuite/gcc.dg/cpp/line9.c
new file mode 100644
index 000..8060aff204d
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/cpp/line9.c
@@ -0,0 +1,5 @@
+/* Test #line overflow checks: bug 97602.  */
+/* { dg-do preprocess } */
+/* { dg-options "-pedantic" } */
+
+#line 50 /* { dg-warning "line number out of range" } */
diff --git a/libcpp/directives.c b/libcpp/directives.c
index fa66b5c5f71..75115600e3a 100644
--- a/libcpp/directives.c
+++ b/libcpp/directives.c
@@ -915,12 +915,11 @@ read_flag (cpp_reader *pfile, unsigned int last)
 /* Subroutine of do_line and do_linemarker.  Convert a number in STR,
of length LEN, to binary; store it in NUMP, and return false if the
number was well-formed, true if not. WRAPPED is set to true if the
-   number did not fit into 'unsigned long'.  */
+   number did not fit into 'linenum_type'.  */
 static bool
 strtolinenum (const uchar *str, size_t len, linenum_type *nump, bool *wrapped)
 {
   linenum_type reg = 0;
-  linenum_type reg_prev = 0;
 
   uchar c;
   *wrapped = false;
@@ -929,11 +928,12 @@ strtolinenum (const uchar *str, size_t len, linenum_type 
*nump, bool *wrapped)
   c = *str++;
   if (!ISDIGIT (c))
return true;
+  if (reg > ((linenum_type) -1) / 10)
+   *wrapped = true;
   reg *= 10;
-  reg += c - '0';
-  if (reg < reg_prev) 
+  if (reg > ((linenum_type) -1) - (c - '0'))
*wrapped = true;
-  reg_prev = reg;
+  reg += c - '0';
 }
   *nump = reg;
   return false;

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

RE: [PATCH] fold-const: Don't consider NaN non-negative [PR97965]

[Joseph Myers]

On Thu, 26 Nov 2020, Roger Sayle wrote:

> NaNs have a sign-bit, so copyexpr (and negate and ABS_EXPR) are 
> well-defined, and it's reasonable for nonnegative_p to reflect this.  
> IMHO, the true bug is that we can't fold away (any) comparisons against 
> NaN when flag_trapping_math, irrespective of qNaN, -qNaN, sNaN or -sNaN.

I think the comment documenting the semantics of any function mentioning 
"nonnegative" needs to say explicitly which of at least three possible 
things it means, and then callers should be checked to see if that matches 
the semantics they want.

1. !(argument < 0)

2. argument >= 0

3. !signbit(argument)

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

Re: [PATCH] fold-const: Don't consider NaN non-negative [PR97965]

[Joseph Myers]

On Thu, 26 Nov 2020, Richard Biener wrote:

> Is copysign (x, NaN) supposed to be well-defined?  We'd stop folding

copysign with NaN arguments (including sNaN) is well-defined and copies 
the sign bit without raising any exceptions.

> this then, no?  I think the ABS_EXPR < 0 to false folding is
> simply incomplete and should first check whether the operands are
> ordered?  That said, NaN is nonnegative but NaN < 0 isn't false(?)

Comparisons involving NaN with < <= > >= == all return false.

For example, with -fno-trapping-math, it's valid to fold fabs (anything) < 
0 to false (preserving any side effects from evaluating "anything"), but 
it's not valid to fold fabs (anything) >= 0 to true, because NaN < 0 and 
NaN >= 0 are both false.  With -ftrapping-math, neither can be folded if 
the argument might be a NaN.

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

Re: [C PATCH] Do not drop qualifiers for _Atomic in typeof

[Joseph Myers]

On Wed, 25 Nov 2020, Uecker, Martin wrote:

> So OK to apply with the following Changelog?

OK fixed as noted.

> 2020-11-25  Martin Uecker  
> 
> gcc/c/

Should mention the PR number in the ChangeLog entry (the part that will 
end up automatically added to the ChangeLog file), not just the summary 
line.

> * c-parsers.c (c_parser_declaration_or_fndef): Remove redundant 
> code

It's c-parser.c.  The git hooks will complain if the file names mentioned 
don't match the files changed in the commit.

> gcc/ginclude/
>   * ginclude/stdatomic.h: Use comma operator to drop qualifiers.

gcc/ginclude/ doesn't have its own ChangeLog, this entry goes in gcc/.

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

Re: [PATCH 00/31] VAX: Bring the port up to date (yes, MODE_CC conversion is included)

[Joseph Myers]

On Wed, 25 Nov 2020, Maciej W. Rozycki wrote:

>  For the other pieces that are missing perhaps my work I did many years 
> ago to port glibc 2.4 (the last one I was able to cook up without NPTL), 
> and specifically libm within, to the never-upstreamed VAX/Linux target 
> might be useful to complete the effort, as there seems to be an overlap 
> here.  That port hasn't been fully verified though and I do not promise 
> doing any work related to it anytime either.  The glibc patches continue 
> being available online to download and use under the terms of the GNU GPL 
> for anyone though.

I think I mentioned before: if you wish to bring a VAX port back to 
current glibc, I think it would make more sense to use software IEEE 
floating point rather than adding new support to glibc for a non-IEEE 
floating-point format.

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

Re: [PATCH] unshare expressions in attribute arguments

[Joseph Myers]

On Fri, 20 Nov 2020, Martin Sebor via Gcc-patches wrote:

> The VLA bounds are evaluated in function definitions so there
> must be a point where that's done.  I don't know where that
> happens but unless at that point the most significant bound
> is still associated with the param (AFAIK, it never really
> is at the tree level) it wouldn't help me.

grokdeclarator combines VLA bounds with the *expr passed in using a 
COMPOUND_EXPR.  These later get stored in arg_info->pending_sizes, and the 
evaluation happens via the add_stmt call in store_parm_decls.

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

c: Allow comparison of pointers to complete and incomplete types for C11 [PR95630]

[Joseph Myers]

As noted in bug 95630, C11 removed a restriction in C99 on comparing
pointers to compatible complete and incomplete types (this was one of
the changes in N1439, which was largely a terminological change to
make incomplete types a subset of object types rather than a different
kind of type).  Implement that change by using pedwarn_c99 with
OPT_Wpedantic for this diagnostic.

Bootstrapped with no regressions for x86_64-pc-linux-gnu.  Applied to 
mainline.

gcc/c/
2020-11-23  Joseph Myers  

PR c/95630
* c-typeck.c (build_binary_op): Use pedwarn_c99 with OPT_Wpedantic
for comparisons of complete and incomplete pointers.

gcc/testsuite/
2020-11-23  Joseph Myers  

PR c/95630
* gcc.dg/c11-compare-incomplete-1.c,
gcc.dg/c11-compare-incomplete-2.c,
gcc.dg/c99-compare-incomplete-1.c,
gcc.dg/c99-compare-incomplete-2.c: New tests.

diff --git a/gcc/c/c-typeck.c b/gcc/c/c-typeck.c
index 286f3d9cd6c..cdc491a25fd 100644
--- a/gcc/c/c-typeck.c
+++ b/gcc/c/c-typeck.c
@@ -12266,8 +12266,8 @@ build_binary_op (location_t location, enum tree_code 
code,
  result_type = common_pointer_type (type0, type1);
  if (!COMPLETE_TYPE_P (TREE_TYPE (type0))
  != !COMPLETE_TYPE_P (TREE_TYPE (type1)))
-   pedwarn (location, 0,
-"comparison of complete and incomplete pointers");
+   pedwarn_c99 (location, OPT_Wpedantic,
+"comparison of complete and incomplete pointers");
  else if (TREE_CODE (TREE_TYPE (type0)) == FUNCTION_TYPE)
pedwarn (location, OPT_Wpedantic, "ISO C forbids "
 "ordered comparisons of pointers to functions");
diff --git a/gcc/testsuite/gcc.dg/c11-compare-incomplete-1.c 
b/gcc/testsuite/gcc.dg/c11-compare-incomplete-1.c
new file mode 100644
index 000..b1c05cf221e
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/c11-compare-incomplete-1.c
@@ -0,0 +1,52 @@
+/* Test comparisons of pointers to complete and incomplete types are
+   accepted in C11 mode.  */
+/* { dg-do compile } */
+/* { dg-options "-std=c11 -pedantic-errors" } */
+
+int
+f (int (*p)[], int (*q)[3])
+{
+  return p < q;
+}
+
+int
+f2 (int (*p)[], int (*q)[3])
+{
+  return p <= q;
+}
+
+int
+f3 (int (*p)[], int (*q)[3])
+{
+  return p > q;
+}
+
+int
+f4 (int (*p)[], int (*q)[3])
+{
+  return p >= q;
+}
+
+int
+g (int (*p)[], int (*q)[3])
+{
+  return q < p;
+}
+
+int
+g2 (int (*p)[], int (*q)[3])
+{
+  return q <= p;
+}
+
+int
+g3 (int (*p)[], int (*q)[3])
+{
+  return q > p;
+}
+
+int
+g4 (int (*p)[], int (*q)[3])
+{
+  return q >= p;
+}
diff --git a/gcc/testsuite/gcc.dg/c11-compare-incomplete-2.c 
b/gcc/testsuite/gcc.dg/c11-compare-incomplete-2.c
new file mode 100644
index 000..8e809e87e9a
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/c11-compare-incomplete-2.c
@@ -0,0 +1,52 @@
+/* Test comparisons of pointers to complete and incomplete types are
+   diagnosed in C11 mode with -Wc99-c11-compat.  */
+/* { dg-do compile } */
+/* { dg-options "-std=c11 -pedantic-errors -Wc99-c11-compat" } */
+
+int
+f (int (*p)[], int (*q)[3])
+{
+  return p < q; /* { dg-warning "complete and incomplete" } */
+}
+
+int
+f2 (int (*p)[], int (*q)[3])
+{
+  return p <= q; /* { dg-warning "complete and incomplete" } */
+}
+
+int
+f3 (int (*p)[], int (*q)[3])
+{
+  return p > q; /* { dg-warning "complete and incomplete" } */
+}
+
+int
+f4 (int (*p)[], int (*q)[3])
+{
+  return p >= q; /* { dg-warning "complete and incomplete" } */
+}
+
+int
+g (int (*p)[], int (*q)[3])
+{
+  return q < p; /* { dg-warning "complete and incomplete" } */
+}
+
+int
+g2 (int (*p)[], int (*q)[3])
+{
+  return q <= p; /* { dg-warning "complete and incomplete" } */
+}
+
+int
+g3 (int (*p)[], int (*q)[3])
+{
+  return q > p; /* { dg-warning "complete and incomplete" } */
+}
+
+int
+g4 (int (*p)[], int (*q)[3])
+{
+  return q >= p; /* { dg-warning "complete and incomplete" } */
+}
diff --git a/gcc/testsuite/gcc.dg/c99-compare-incomplete-1.c 
b/gcc/testsuite/gcc.dg/c99-compare-incomplete-1.c
new file mode 100644
index 000..dfafc39145e
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/c99-compare-incomplete-1.c
@@ -0,0 +1,52 @@
+/* Test comparisons of pointers to complete and incomplete types are
+   diagnosed in C99 mode: -pedantic.  */
+/* { dg-do compile } */
+/* { dg-options "-std=c99 -pedantic" } */
+
+int
+f (int (*p)[], int (*q)[3])
+{
+  return p < q; /* { dg-warning "complete and incomplete" } */
+}
+
+int
+f2 (int (*p)[], int (*q)[3])
+{
+  return p <= q; /* { dg-warning "complete and incomplete" } */
+}
+
+int
+f3 (int (*p)[], int (*q)[3])
+{
+  return p > q; /* { dg-warning "complete and incomplete" } */
+}
+
+int
+f4 (int (*p)[], int 

Re: [C PATCH] Do not drop qualifiers for _Atomic in typeof

[Joseph Myers]

On Mon, 23 Nov 2020, Uecker, Martin wrote:

> Joseph,
> 
> here is the patch to not drop qualifiers for _Atomic in
> typeof. I am not sure whether this is appropriate in
> stage3, but I wanted to leave it here for you to comment
> and so that it does not lost.
> 
> First, I noticed that the change to drop qualifiers
> in lvalue conversion also implies that __auto_type now
> always uses the non-qualified type. I think this is more
> correct, and also what other compilers and C++'s auto do.
> The first change here in c-parser would remove the now
> redundant code to drop qualifiers for _Atomic types.
> 
> The second change would remove the code to drop qualifiers
> for _Atomic types for typeof. I would then use the
> comma operator for stdatomic to remove all qualifiers.
> Here, the question is whether this may have same
> unintended side effects.

This is OK, with references to bugs 65455 and 92935 as I think it fixes 
those.

Any change to qualifiers for typeof risks breaking something relying on 
the details of when the result is or is not qualified, but given that in 
previous GCC versions that was poorly defined and inconsistent, making 
these changes to make it more consistent seems reasonable.

It is probably still the case that _Typeof as proposed for ISO C would 
need special handling of function and function pointer types for the same 
reason as _Generic has such handling (_Noreturn not being part of the 
function type as defined by ISO C).

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

Re: Add -std=c2x, -std=gnu2x, -Wc11-c2x-compat, C2X _Static_assert support

[Joseph Myers]

On Mon, 23 Nov 2020, Martin Liška wrote:

> On 10/18/18 1:59 AM, Joseph Myers wrote:
> > -   || strcmp (language_string, "GNU C17") == 0)
> > +   || strcmp (language_string, "GNU C17") == 0
> > +   || strcmp (language_string, "GNU C2X"))
> 
> Hello Joseph.
> 
> Shouldn't this hunk be '|| strcmp (language_string, "GNU C2X") == 0' ?

Yes.

(There is a question of at what point we decide to assume that C2X will be 
published on the schedule approved by ISO processes and change references 
to refer to C23 and add all the corresponding option names referring to 
C23.)

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

Re: [C PATCH] Drop qualifiers during lvalue conversion

[Joseph Myers]

On Thu, 19 Nov 2020, Uecker, Martin wrote:

> Apparently I did not have enough coffee when
> generalizing this to the other qualifiers. 
> 
> Ok, with the following test?

OK.

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

Re: [C PATCH] Drop qualifiers during lvalue conversion

[Joseph Myers]

On Thu, 19 Nov 2020, Uecker, Martin wrote:

> Here is another version of the patch. The
> only difference is the additional the check 
> using 'tree_ssa_useless_type_conversion'.

The code changes in this one are OK.  However, in the test:

> +void f(void)
> +{
> + const int j;
> + typeof((0,j)) i10; i10 = j;;
> + typeof(+j) i11; i11 = j;;
> + typeof(-j) i12; i12 = j;;
> + typeof(1?j:0) i13; i13 = j;;
> + typeof((int)j) i14; i14 = j;;
> + typeof((const int)j) i15; i15 = j;;
> +}

This test function seems fine.

> +void g(void)
> +{
> + volatile int j;
> + typeof((0,j)) i21; i21 = j;;
> + typeof(+j) i22; i22 = j;;
> + typeof(-j) i23; i23 = j;;
> + typeof(1?j:0) i24; i24 = j;;
> + typeof((int)j) i25; i25 = j;;
> + typeof((volatile int)j) i26; i26 = j;;
> +}
> +
> +void h(void)
> +{
> + _Atomic int j;
> + typeof((0,j)) i32; i32 = j;;
> + typeof(+j) i33; i33 = j;;
> + typeof(-j) i34; i34 = j;;
> + typeof(1?j:0) i35; i35 = j;;
> + typeof((int)j) i36; i36 = j;;
> + typeof((_Atomic int)j) i37; i37 = j;;
> +}
> +
> +void e(void)
> +{
> + int* restrict j;
> + typeof((0,j)) i43; i43 = j;;
> + typeof(1?j:0) i44; i44 = j;;
> + typeof((int*)j) i45; i45 = j;;
> + typeof((int* restrict)j) i46; i46 = j;;
> +}

But these tests don't look like they do anything useful (i.e. verify that 
typeof loses the qualifier), because testing by assignment like that only 
works with const.  You could do e.g.

volatile int j;
extern int i;
extern typeof((0,j)) i;

instead to verify the qualifier is removed.

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

Re: [PATCH] options, lto: Optimize streaming of optimization nodes

[Joseph Myers]

On Wed, 18 Nov 2020, Jakub Jelinek via Gcc-patches wrote:

> Hi!
> 
> Reposting with self-contained description per Joseph's request:
> 
> Honza mentioned that especially for the new param machinery, most of
> streamed values are probably going to be the default values.  Perhaps
> somehow we could stream them more effectively.
> 
> This patch implements it and brings further savings, the size
> goes down from 574 bytes to 273 bytes, i.e. less than half.
> Not trying to handle enums because the code doesn't know if (enum ...) 10
> is even valid, similarly non-parameters because those really generally
> don't have large initializers, and params without Init (those are 0
> initialized and thus don't need to be handled).
> 
> Bootstrapped/regtested again on x86_64-linux and i686-linux, ok for trunk?
> 
> 2020-11-18  Jakub Jelinek  
> 
>   * optc-save-gen.awk: Initialize var_opt_init.  In
>   cl_optimization_stream_out for params with default values larger than
>   10, xor the default value with the actual parameter value.  In
>   cl_optimization_stream_in repeat the above xor.

OK.

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

Re: [PATCH] configury: --enable-link-serialization support

[Joseph Myers]

On Wed, 18 Nov 2020, Jakub Jelinek via Gcc-patches wrote:

> Bootstrapped/regtested again last night on x86_64-linux and i686-linux, ok
> for trunk?

OK.

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

Re: [PATCH] plugins: Allow plugins to handle global_options changes

[Joseph Myers]

On Wed, 18 Nov 2020, Jakub Jelinek via Gcc-patches wrote:

> On Wed, Nov 18, 2020 at 10:39:46AM +0100, Richard Biener wrote:
> > We already have --{enable,disable}-plugin, so could remove it when
> > those are not enabled.
> 
> Here is a variant that does that:
> 
> 2020-11-18  Jakub Jelinek  
> 
>   * opts.h (struct cl_var): New type.
>   (cl_vars): Declare.
>   * optc-gen.awk: Generate cl_vars array.

This version is OK.

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

Re: [PATCH] Practical Improvement to libgcc Complex Divide

[Joseph Myers]

On Tue, 8 Sep 2020, Patrick McGehearty via Gcc-patches wrote:

> This project started with an investigation related to
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59714.  Study of Beebe[1]
> provided an overview of past and recent practice for computing complex
> divide. The current glibc implementation is based on Robert Smith's
> algorithm [2] from 1962.  A google search found the paper by Baudin
> and Smith [3] (same Robert Smith) published in 2012. Elen Kalda's
> proposed patch [4] is based on that paper.

Thanks, I've now read Baudin and Smith so can review the patch properly.  
I'm fine with the overall algorithm, so my comments generally relate to 
how the code should best be integrated into libgcc while keeping it 
properly machine-mode-generic as far as possible.

> I developed two sets of test set by randomly distributing values over
> a restricted range and the full range of input values. The current

Are these tests available somewhere?

> Support for half, float, double, extended, and long double precision
> is included as all are handled with suitable preprocessor symbols in a
> single source routine. Since half precision is computed with float
> precision as per current libgcc practice, the enhanced algorithm
> provides no benefit for half precision and would cost performance.
> Therefore half precision is left unchanged.
> 
> The existing constants for each precision:
> float: FLT_MAX, FLT_MIN;
> double: DBL_MAX, DBL_MIN;
> extended and/or long double: LDBL_MAX, LDBL_MIN
> are used for avoiding the more common overflow/underflow cases.

In general, libgcc code works with modes, not types; hardcoding references 
to a particular mapping between modes and types is problematic.  Rather, 
the existing code in c-cppbuiltin.c that has a loop over modes should be 
extended to provide whatever information is needed, as macros defined for 
each machine mode.

  /* For libgcc-internal use only.  */
  if (flag_building_libgcc)
{
  /* Properties of floating-point modes for libgcc2.c.  */
  opt_scalar_float_mode mode_iter;
  FOR_EACH_MODE_IN_CLASS (mode_iter, MODE_FLOAT)
{
[...]

For example, that defines macros such as __LIBGCC_DF_FUNC_EXT__ and 
__LIBGCC_DF_MANT_DIG__.  The _FUNC_EXT__ definition involves that code 
computing a mapping to types.

I'd suggest defining additional macros such as __LIBGCC_DF_MAX__ in the 
same code - for each supported floating-point mode.  They can be defined 
to __FLT_MAX__ etc. (the predefined macros rather than the ones in 
float.h) - the existing code that computes a suffix for functions can be 
adjusted so it also computes the string such as "FLT", "DBL", "LDBL", 
"FLT128" etc.

(I suggest defining to __FLT_MAX__ rather than to the expansion of 
__FLT_MAX__ because that avoids any tricky interactions with the logic to 
compute such expansions lazily.  I suggest __FLT_MAX__ rather than the 
FLT_MAX name from float.h because that way you avoid any need to define 
feature test macros to access names such as FLT128_MAX.)

> diff --git a/gcc/c-family/c-cppbuiltin.c b/gcc/c-family/c-cppbuiltin.c
> index 74ecca8..02c06d8 100644
> --- a/gcc/c-family/c-cppbuiltin.c
> +++ b/gcc/c-family/c-cppbuiltin.c
> @@ -1343,6 +1343,11 @@ c_cpp_builtins (cpp_reader *pfile)
>builtin_define_with_value ("__LIBGCC_INIT_SECTION_ASM_OP__",
>INIT_SECTION_ASM_OP, 1);
>  #endif
> +  /* For libgcc float/double optimization */
> +#ifdef HAVE_adddf3
> +  builtin_define_with_int_value ("__LIBGCC_HAVE_HWDBL__",
> +  HAVE_adddf3);
> +#endif

This is another thing to handle more generically - possibly with something 
like the mode_has_fma function, and defining a macro for each mode, named 
after the mode, rather than only for DFmode.  For an alternative, see the 
discussion below.

> diff --git a/libgcc/ChangeLog b/libgcc/ChangeLog
> index ccfd6f6..8bd66c5 100644
> --- a/libgcc/ChangeLog
> +++ b/libgcc/ChangeLog
> @@ -1,3 +1,10 @@
> +2020-08-27  Patrick McGehearty 
> +
> + * libgcc2.c (__divsc3, __divdc3, __divxc3, __divtc3): Enhance
> + accuracy of complex divide by avoiding underflow/overflow when
> + ratio underflows or when arguments have very large or very
> + small exponents.

Note that diffs to ChangeLog files should not now be included in patches; 
the ChangeLog content needs to be included in the proposed commit message 
instead for automatic ChangeLog generation.

> +#if defined(L_divsc3)
> +#define RBIG ((FLT_MAX)/2.0)
> +#define RMIN (FLT_MIN)
> +#define RMIN2(0x1.0p-21)
> +#define RMINSCAL (0x1.0p+19)
> +#define RMAX2((RBIG)*(RMIN2))
> +#endif

I'd expect all of these to use generic macros based on the mode.  For the 
division by 2.0, probably also divide by integer 2 not 2.0 to avoid 
unwanted conversions to/from double.

> +#if defined(L_divdc3)
> +#define RBIG ((DBL_MAX)/2.0)
> +#define RMIN (DBL_MIN)
> +#define RMIN2(0x1.0p-53)
> +#define 

Re: [PATCH][driver] Don't add suffix for non-files

[Joseph Myers]

On Tue, 27 Oct 2020, Tamar Christina via Gcc-patches wrote:

> Hi All,
> 
> This patch fixes an issue where on systems that are
> HAVE_TARGET_EXECUTABLE_SUFFIX the driver calls convert_filename in order to
> add the suffix to the filename.  However while it excludes `-` it doesn't
> exclude the null device.  This patches changes the check to exclude anything
> that is not a file by calling not_actual_file_p instead.
> 
> This also fixes a bug in not_actual_file_p which was accidentally testing
> a the global variable output_file instead of the supplied argument.  This
> hasn't been an issue so far because because not_actual_file_p was only used
> on output_file till now.
> 
> This fixes the adding of an extension to the nul device which is against
> the recommendations on msdn[0] and makes it harder for the next tool in line
> to detect it.
> 
> Bootstrapped Regtested on x86_64-w64-mingw32 and no issues.
> Did do a bootstrap on x86_64-pc-linux-gnu but no regtest as it's not a
> HAVE_TARGET_EXECUTABLE_SUFFIX system.
> 
> [0] https://docs.microsoft.com/en-us/windows/win32/fileio/naming-a-file
> 
> Ok for master? and backport to GCC 8, 9 and 10.

OK.

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

Re: [C PATCH RFC] Drop qualifiers during lvalue conversion

[Joseph Myers]

On Sun, 15 Nov 2020, Uecker, Martin wrote:

> > I think it might be safest to avoid doing any conversion in the case where 
> > the value is still of array type at this point (C90 non-lvalue arrays).
> 
> I added a test for arrays, but I am not sure what effect it has.
> What would be C90 non-lvalue arrays?  Anything I can test?

In C90, a non-lvalue array (an array member of a non-lvalue structure or 
union, obtained by a function return / assignment / conditional expression 
/ comma expression of structure or union type) did not get converted to a 
pointer.  This meant there was nothing much useful that could be done with 
such arrays, because you couldn't access their values (technically I think 
you could pass them in variable arguments and retrieve them in the called 
function with va_arg, but that doesn't help because it just gives another 
non-lvalue copy of the value that you still can't do anything useful 
with).

The possible breakage I'm concerned about isn't something that can readily 
be tested for; it's that if you create an unqualified array type directly 
with build_qualified_type (not going through c_build_qualified_type), you 
may break the invariants regarding how arrays of qualified element types 
are represented internally in GCC, and so cause subtle problems in code 
relying on such invariants.  (Cf. the problem with inconsistency in that 
area that I fixed with 
 (commit 
46df282378908dff9219749cd4cd576c155b2971).)  Avoiding these conversions in 
the case of arrays, as this version of the patch does, seems the simplest 
way to avoid any such issues arising.

> diff --git a/gcc/gimplify.c b/gcc/gimplify.c
> index 2566ec7f0af..f83b161b2e8 100644
> --- a/gcc/gimplify.c
> +++ b/gcc/gimplify.c
> @@ -5518,6 +5518,18 @@ gimplify_modify_expr_rhs (tree *expr_p, tree *from_p, 
> tree *to_p,
>   return GS_OK;
> }
>  
> + case NOP_EXPR:
> +   /* Pull out compound literal expressions from a NOP_EXPR.
> +  Those are created in the C FE to drop qualifiers during
> +  lvalue conversion.  */
> +   if (TREE_CODE (TREE_OPERAND (*from_p, 0)) == COMPOUND_LITERAL_EXPR)

A NOP_EXPR might sometimes be doing an actual conversion (say the compound 
literal is (int){ INT_MAX }, converted to short).  I think this should 
check tree_ssa_useless_type_conversion to make sure it's safe to remove 
the conversion.

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

Ping^3 Re: float.h: C2x NaN and Inf macros

[Joseph Myers]

Ping^3.  This patch 
 is 
still pending review (the DFP sNaN followup has been approved).  (The 
independent C2x  patches 
 and 
 are 
also pending review.)

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

Re: [PATCH][RFC] Make mingw-w64 printf/scanf attribute alias to ms_printf/ms_scanf only for C89

[Joseph Myers]

On Fri, 13 Nov 2020, Liu Hao via Gcc-patches wrote:

> 在 2020/11/13 2:46, Joseph Myers 写道:
> > I'd expect these patches to include updates to the gcc.dg/format/ms_*.c 
> > tests to reflect the changed semantics (or new tests there if some of the 
> > changes don't result in any failures in the existing tests).
> > 
> 
> Does the attached patch suffice?

This is testing the sort of thing I'd expect tests for regarding 'L' and 
'll'.  What about the changes for 'I' - do those result in changes to how 
the compiler behaves, which should also have tests?

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

float.h: Handle C2x __STDC_WANT_IEC_60559_EXT__

[Joseph Myers]

TS 18661-1 and 18661-2 have various definitions conditional on
__STDC_WANT_IEC_60559_BFP_EXT__ and __STDC_WANT_IEC_60559_DFP_EXT__
macros.  When those TSes were integrated into C2x, most of the feature
test macro conditionals were removed (with declarations for decimal FP
becoming conditional only on whether decimal FP is supported by the
implementation and those for binary FP becoming unconditionally
required).

A few tests of those feature test macros remained for declarations
that appeared only in Annex F and not in the main part of the
standard.  A change accepted for C2x at the last WG14 meeting (but not
yet added to the working draft in git) was to replace both those
macros by __STDC_WANT_IEC_60559_EXT__; if __STDC_WANT_IEC_60559_EXT__
is defined, the specific declarations in the headers will then depend
on which features are supported by the implementation, as for
declarations not controlled by a feature test macro at all.

Thus, add a check of __STDC_WANT_IEC_60559_EXT__ for CR_DECIMAL_DIG in
float.h, the only case of this change relevant to GCC.

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

gcc/
2020-11-14  Joseph Myers  

* ginclude/float.h (CR_DECIMAL_DIG): Also define for
[__STDC_WANT_IEC_60559_EXT__].

gcc/testsuite/
2020-11-14  Joseph Myers  

* gcc.dg/cr-decimal-dig-3.c: New test.

diff --git a/gcc/ginclude/float.h b/gcc/ginclude/float.h
index 9c4b0385568..0442f26ec56 100644
--- a/gcc/ginclude/float.h
+++ b/gcc/ginclude/float.h
@@ -250,7 +250,8 @@ see the files COPYING3 and COPYING.RUNTIME respectively.  
If not, see
 
 #endif /* C2X */
 
-#ifdef __STDC_WANT_IEC_60559_BFP_EXT__
+#if (defined __STDC_WANT_IEC_60559_BFP_EXT__ \
+ || defined __STDC_WANT_IEC_60559_EXT__)
 /* Number of decimal digits for which conversions between decimal
character strings and binary formats, in both directions, are
correctly rounded.  */
diff --git a/gcc/testsuite/gcc.dg/cr-decimal-dig-3.c 
b/gcc/testsuite/gcc.dg/cr-decimal-dig-3.c
new file mode 100644
index 000..8e07b67dd52
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/cr-decimal-dig-3.c
@@ -0,0 +1,14 @@
+/* Test C2x CR_DECIMAL_DIG: defined for __STDC_WANT_IEC_60559_EXT__.  */
+/* { dg-do compile } */
+/* { dg-options "-std=c2x" } */
+
+#define __STDC_WANT_IEC_60559_EXT__
+#include 
+
+#ifndef CR_DECIMAL_DIG
+#error "CR_DECIMAL_DIG not defined"
+#endif
+
+#if CR_DECIMAL_DIG < DECIMAL_DIG + 3
+#error "CR_DECIMAL_DIG too small"
+#endif

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

c: C2x binary constants

[Joseph Myers]

C2x adds binary integer constants (approved at the last WG14 meeting,
though not yet added to the working draft in git).  Configure libcpp
to consider these a standard feature in C2x mode, with appropriate
updates to diagnostics including support for diagnosing them with
-std=c2x -Wc11-c2x-compat.

Bootstrapped with no regressions for x86_64-pc-linux-gnu.  Applied to 
mainline.

gcc/testsuite/
2020-11-13  Joseph Myers  

* gcc.dg/binary-constants-2.c, gcc.dg/binary-constants-3.c,
gcc.dg/system-binary-constants-1.c: Update expected diagnostics.
* gcc.dg/c11-binary-constants-1.c,
gcc.dg/c11-binary-constants-2.c, gcc.dg/c2x-binary-constants-1.c,
gcc.dg/c2x-binary-constants-2.c, gcc.dg/c2x-binary-constants-3.c:
New tests.

libcpp/
2020-11-13  Joseph Myers  

* expr.c (cpp_classify_number): Update diagnostic for binary
constants for C.  Also diagnose binary constants for
-Wc11-c2x-compat.
* init.c (lang_defaults): Enable binary constants for GNUC2X and
STDC2X.

diff --git a/gcc/testsuite/gcc.dg/binary-constants-2.c 
b/gcc/testsuite/gcc.dg/binary-constants-2.c
index 6c3928aa2a0..5339d57b991 100644
--- a/gcc/testsuite/gcc.dg/binary-constants-2.c
+++ b/gcc/testsuite/gcc.dg/binary-constants-2.c
@@ -9,8 +9,8 @@
 int
 foo (void)
 {
-#if FOO /* { dg-warning "binary constants are a GCC extension" } */
+#if FOO /* { dg-warning "binary constants are a C2X feature or GCC extension" 
} */
   return 23;
 #endif
-  return 0b1101; /* { dg-warning "binary constants are a GCC extension" } */
+  return 0b1101; /* { dg-warning "binary constants are a C2X feature or GCC 
extension" } */
 }
diff --git a/gcc/testsuite/gcc.dg/binary-constants-3.c 
b/gcc/testsuite/gcc.dg/binary-constants-3.c
index 410fc4cd725..5b49cb4efbb 100644
--- a/gcc/testsuite/gcc.dg/binary-constants-3.c
+++ b/gcc/testsuite/gcc.dg/binary-constants-3.c
@@ -9,8 +9,8 @@
 int
 foo (void)
 {
-#if FOO /* { dg-error "binary constants are a GCC extension" } */
+#if FOO /* { dg-error "binary constants are a C2X feature or GCC extension" } 
*/
   return 23;
 #endif
-  return 0b1101; /* { dg-error "binary constants are a GCC extension" } */
+  return 0b1101; /* { dg-error "binary constants are a C2X feature or GCC 
extension" } */
 }
diff --git a/gcc/testsuite/gcc.dg/c11-binary-constants-1.c 
b/gcc/testsuite/gcc.dg/c11-binary-constants-1.c
new file mode 100644
index 000..fdc7df4bfad
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/c11-binary-constants-1.c
@@ -0,0 +1,11 @@
+/* Test that binary constants are diagnosed in C11 mode: -pedantic.  */
+/* { dg-do compile } */
+/* { dg-options "-std=c11 -pedantic" } */
+
+int a = 0b1; /* { dg-warning "binary constants" } */
+#if 0b101 /* { dg-warning "binary constants" } */
+#endif
+
+int b = 0B1; /* { dg-warning "binary constants" } */
+#if 0B101 /* { dg-warning "binary constants" } */
+#endif
diff --git a/gcc/testsuite/gcc.dg/c11-binary-constants-2.c 
b/gcc/testsuite/gcc.dg/c11-binary-constants-2.c
new file mode 100644
index 000..6b48a5d005b
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/c11-binary-constants-2.c
@@ -0,0 +1,11 @@
+/* Test that binary constants are diagnosed in C11 mode: -pedantic-errors.  */
+/* { dg-do compile } */
+/* { dg-options "-std=c11 -pedantic-errors" } */
+
+int a = 0b1; /* { dg-error "binary constants" } */
+#if 0b101 /* { dg-error "binary constants" } */
+#endif
+
+int b = 0B1; /* { dg-error "binary constants" } */
+#if 0B101 /* { dg-error "binary constants" } */
+#endif
diff --git a/gcc/testsuite/gcc.dg/c2x-binary-constants-1.c 
b/gcc/testsuite/gcc.dg/c2x-binary-constants-1.c
new file mode 100644
index 000..bbb2bc842c9
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/c2x-binary-constants-1.c
@@ -0,0 +1,5 @@
+/* Test C2x binary constants.  Valid syntax and types.  */
+/* { dg-do compile } */
+/* { dg-options "-std=c2x -pedantic-errors" } */
+
+#include "binary-constants-1.c"
diff --git a/gcc/testsuite/gcc.dg/c2x-binary-constants-2.c 
b/gcc/testsuite/gcc.dg/c2x-binary-constants-2.c
new file mode 100644
index 000..4379427d6ce
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/c2x-binary-constants-2.c
@@ -0,0 +1,11 @@
+/* Test that binary constants are accepted in C2X mode: compat warnings.  */
+/* { dg-do compile } */
+/* { dg-options "-std=c2x -Wc11-c2x-compat" } */
+
+int a = 0b1; /* { dg-warning "C2X feature" } */
+#if 0b101 /* { dg-warning "C2X feature" } */
+#endif
+
+int b = 0B1; /* { dg-warning "C2X feature" } */
+#if 0B101 /* { dg-warning "C2X feature" } */
+#endif
diff --git a/gcc/testsuite/gcc.dg/c2x-binary-constants-3.c 
b/gcc/testsuite/gcc.dg/c2x-binary-constants-3.c
new file mode 100644
index 000..7604791fa85
--- /dev/null
+++ b/gcc/testsuite/gcc.dg

float.h: C2x *_IS_IEC_60559 macros

[Joseph Myers]

C2x adds float.h macros that say whether float, double and long double
match an IEC 60559 (IEEE 754) format and operations.  Add these
macros to GCC's float.h.

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

Although this changes the same part of float.h as
<https://gcc.gnu.org/pipermail/gcc-patches/2020-October/557136.html>
(pending review), there are no actual dependencies between the
patches; new tests are named to avoid conflicts with the tests added
in that patch.

gcc/c-family/
2020-11-13  Joseph Myers  

* c-cppbuiltin.c (builtin_define_float_constants): Define
*_IS_IEC_60559__ macros.

gcc/
2020-11-13  Joseph Myers  

* ginclude/float.h [__STDC_VERSION__ > 201710L] (FLT_IS_IEC_60559,
DBL_IS_IEC_60559, LDBL_IS_IEC_60559): New macros.

gcc/testsuite/
2020-11-13  Joseph Myers  

* gcc.dg/c11-float-6.c, gcc.dg/c2x-float-10.c: New tests.

diff --git a/gcc/c-family/c-cppbuiltin.c b/gcc/c-family/c-cppbuiltin.c
index e5ebb79e22a..5a839d7fa6f 100644
--- a/gcc/c-family/c-cppbuiltin.c
+++ b/gcc/c-family/c-cppbuiltin.c
@@ -316,6 +316,16 @@ builtin_define_float_constants (const char *name_prefix,
   sprintf (name, "__FP_FAST_FMA%s", fma_suffix);
   builtin_define_with_int_value (name, 1);
 }
+
+  /* For C2x *_IS_IEC_60559.  0 means the type does not match an IEC
+ 60559 format, 1 that it matches a format but not operations and 2
+ that it matches a format and operations (but may not conform to
+ Annex F; we take this as meaning exceptions and rounding modes
+ need not be supported).  */
+  sprintf (name, "__%s_IS_IEC_60559__", name_prefix);
+  builtin_define_with_int_value (name,
+(fmt->ieee_bits == 0
+ ? 0 : (fmt->round_towards_zero ? 1 : 2)));
 }
 
 /* Define __DECx__ constants for TYPE using NAME_PREFIX and SUFFIX. */
diff --git a/gcc/ginclude/float.h b/gcc/ginclude/float.h
index 9c4b0385568..70149564ff1 100644
--- a/gcc/ginclude/float.h
+++ b/gcc/ginclude/float.h
@@ -248,6 +248,15 @@ see the files COPYING3 and COPYING.RUNTIME respectively.  
If not, see
 #define DBL_NORM_MAX   __DBL_NORM_MAX__
 #define LDBL_NORM_MAX  __LDBL_NORM_MAX__
 
+/* Whether each type matches an IEC 60559 format (1 for format, 2 for
+   format and operations).  */
+#undef FLT_IS_IEC_60559
+#undef DBL_IS_IEC_60559
+#undef LDBL_IS_IEC_60559
+#define FLT_IS_IEC_60559   __FLT_IS_IEC_60559__
+#define DBL_IS_IEC_60559   __DBL_IS_IEC_60559__
+#define LDBL_IS_IEC_60559  __LDBL_IS_IEC_60559__
+
 #endif /* C2X */
 
 #ifdef __STDC_WANT_IEC_60559_BFP_EXT__
diff --git a/gcc/testsuite/gcc.dg/c11-float-6.c 
b/gcc/testsuite/gcc.dg/c11-float-6.c
new file mode 100644
index 000..b0381e57884
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/c11-float-6.c
@@ -0,0 +1,17 @@
+/* Test *_IS_IEC_60559 not defined for C11.  */
+/* { dg-do preprocess } */
+/* { dg-options "-std=c11 -pedantic-errors" } */
+
+#include 
+
+#ifdef FLT_IS_IEC_60559
+#error "FLT_IS_IEC_60559 defined"
+#endif
+
+#ifdef DBL_IS_IEC_60559
+#error "DBL_IS_IEC_60559 defined"
+#endif
+
+#ifdef LDBL_IS_IEC_60559
+#error "LDBL_IS_IEC_60559 defined"
+#endif
diff --git a/gcc/testsuite/gcc.dg/c2x-float-10.c 
b/gcc/testsuite/gcc.dg/c2x-float-10.c
new file mode 100644
index 000..7b53a6ab050
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/c2x-float-10.c
@@ -0,0 +1,33 @@
+/* Test *_IS_IEC_60559 macros.  */
+/* { dg-do compile } */
+/* { dg-options "-std=c2x -pedantic-errors" } */
+
+#include 
+
+#ifndef FLT_IS_IEC_60559
+#error "FLT_IS_IEC_60559 undefined"
+#endif
+
+#ifndef DBL_IS_IEC_60559
+#error "DBL_IS_IEC_60559 undefined"
+#endif
+
+#ifndef LDBL_IS_IEC_60559
+#error "LDBL_IS_IEC_60559 undefined"
+#endif
+
+#if defined __pdp11__ || defined __vax__
+_Static_assert (FLT_IS_IEC_60559 == 0);
+_Static_assert (DBL_IS_IEC_60559 == 0);
+_Static_assert (LDBL_IS_IEC_60559 == 0);
+#else
+_Static_assert (FLT_IS_IEC_60559 == 2);
+_Static_assert (DBL_IS_IEC_60559 == 2);
+#if LDBL_MANT_DIG == 106 || LDBL_MIN_EXP == -16382
+/* IBM long double and m68k extended format do not meet the definition
+   of an IEC 60559 interchange or extended format.  */
+_Static_assert (LDBL_IS_IEC_60559 == 0);
+#else
+_Static_assert (LDBL_IS_IEC_60559 == 2);
+#endif
+#endif

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

Re: [PATCH] C-Family, Objective-C : Implement Objective-C nullability Part 1 [PR90707].

[Joseph Myers]

On Thu, 12 Nov 2020, Iain Sandoe wrote:

> OK for the C-family changes?

OK.

> +When @var{nullability kind} is @var{"unspecified"} or @var{0}, nothing is

I think you mean @code or @samp for the second and third @var on this 
line, they look like literal code not metasyntactic variables.  Likewise 
below.

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

c: C2x __has_c_attribute

[Joseph Myers]

C2x adds the __has_c_attribute preprocessor operator, similar to C++
__has_cpp_attribute.

GCC implements __has_cpp_attribute as exactly equivalent to
__has_attribute.  (The documentation says they differ regarding the
values returned for standard attributes, but that's actually only a
matter of the particular nonzero value returned not being specified in
the documentation for __has_attribute; the implementation makes no
distinction between the two.)

I don't think having them exactly equivalent is actually correct,
either for __has_cpp_attribute or for __has_c_attribute.
Specifically, I think it is only correct for __has_cpp_attribute or
__has_c_attribute to return nonzero if the given attribute is
supported, with the particular pp-tokens passed to __has_cpp_attribute
or __has_c_attribute, with [[]] syntax, not if it's only accepted in
__attribute__ or with gnu:: added in [[]].  For example, they should
return nonzero for gnu::packed, but zero for plain packed, because
[[gnu::packed]] is accepted but [[packed]] is ignored as not a
standard attribute.

This patch implements that for __has_c_attribute, leaving any changes
to __has_cpp_attribute for the C++ maintainers.  A new
BT_HAS_STD_ATTRIBUTE is added for __has_c_attribute (which I think,
based on the above, would actually be correct to use for
__has_cpp_attribute as well).  The code in c_common_has_attribute that
deals with scopes has its C++ conditional removed; instead, whether
the language is C or C++ is used only to determine the numeric values
returned for standard attributes (and which standard attributes are
handled there at all).  A new argument is passed to
c_common_has_attribute to distinguish BT_HAS_STD_ATTRIBUTE from
BT_HAS_ATTRIBUTE, and that argument is used to stop attributes with no
scope specified from being accepted with __has_c_attribute unless they
are one of the known standard attributes and so handled specially.

Although the standard specify constants ending with 'L' as the values
for the standard attributes, there is no correctness issue with the
lack of code in GCC to add that 'L' to the expansion:
__has_c_attribute and __has_cpp_attribute are expanded in #if after
other macro expansion has occurred, with no semantics being specified
if they occur outside #if, so there is no way for a conforming program
to inspect the exact text of the expansion of those macros, only to
use the resulting pp-number in a #if expression, where long and int
have the same set of values.

Bootstrapped with no regressions for x86_64-pc-linux-gnu.  Applied to 
mainline.

gcc/
2020-11-12  Joseph Myers  

* doc/cpp.texi (__has_attribute): Document when scopes are allowed
for C.
(__has_c_attribute): New.

gcc/c-family/
2020-11-12  Joseph Myers  

* c-lex.c (c_common_has_attribute): Take argument std_syntax.
Allow scope for C.  Handle standard attributes for C.  Do not
accept unscoped attributes if std_syntax and not handled as
standard attributes.
* c-common.h (c_common_has_attribute): Update prototype.

gcc/testsuite/
2020-11-12  Joseph Myers  

* gcc.dg/c2x-has-c-attribute-1.c, gcc.dg/c2x-has-c-attribute-2.c,
gcc.dg/c2x-has-c-attribute-3.c, gcc.dg/c2x-has-c-attribute-4.c:
New tests.

libcpp/
2020-11-12  Joseph Myers  

* include/cpplib.h (struct cpp_callbacks): Add bool argument to
has_attribute.
(enum cpp_builtin_type): Add BT_HAS_STD_ATTRIBUTE.
* init.c (builtin_array): Add __has_c_attribute.
(cpp_init_special_builtins): Handle BT_HAS_STD_ATTRIBUTE.
* macro.c (_cpp_builtin_macro_text): Handle BT_HAS_STD_ATTRIBUTE.
Update call to has_attribute for BT_HAS_ATTRIBUTE.
* traditional.c (fun_like_macro): Handle BT_HAS_STD_ATTRIBUTE.

diff --git a/gcc/c-family/c-common.h b/gcc/c-family/c-common.h
index 94f4868915a..f47097442eb 100644
--- a/gcc/c-family/c-common.h
+++ b/gcc/c-family/c-common.h
@@ -1042,7 +1042,7 @@ extern bool c_cpp_diagnostic (cpp_reader *, enum 
cpp_diagnostic_level,
  enum cpp_warning_reason, rich_location *,
  const char *, va_list *)
  ATTRIBUTE_GCC_DIAG(5,0);
-extern int c_common_has_attribute (cpp_reader *);
+extern int c_common_has_attribute (cpp_reader *, bool);
 extern int c_common_has_builtin (cpp_reader *);
 
 extern bool parse_optimize_options (tree, bool);
diff --git a/gcc/c-family/c-lex.c b/gcc/c-family/c-lex.c
index e81e16ddc26..6cd3df7c96f 100644
--- a/gcc/c-family/c-lex.c
+++ b/gcc/c-family/c-lex.c
@@ -300,7 +300,7 @@ get_token_no_padding (cpp_reader *pfile)
 
 /* Callback for has_attribute.  */
 int
-c_common_has_attribute (cpp_reader *pfile)
+c_common_has_attribute (cpp_reader *pfile, bool std_syntax)
 {
   int result = 0;
   tree attr_name = NULL_TREE;
@@ -319,35 +319,37 @@ c_common_has_attribute (cpp_reader *pfile)
   attr_name = get_identifier ((const char

Re: [PATCH 1/3] C-family, Objective-C [1/3] : Implement Wobjc-root-class [PR77404].

[Joseph Myers]

On Thu, 12 Nov 2020, Iain Sandoe wrote:

> OK for the c-family parts?

OK.

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

Re: [PATCH][RFC] Make mingw-w64 printf/scanf attribute alias to ms_printf/ms_scanf only for C89

[Joseph Myers]

I'd expect these patches to include updates to the gcc.dg/format/ms_*.c 
tests to reflect the changed semantics (or new tests there if some of the 
changes don't result in any failures in the existing tests).

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

Re: [PATCH] Better __ashlDI3, __ashrDI3 and __lshrDI3 functions, plus fixed __bswapsi2 function

[Joseph Myers]

On Wed, 11 Nov 2020, Jakub Jelinek via Gcc-patches wrote:

> So indeed, 0x80 << 24 is UB in C99/C11 and C++98, unclear in C89 and
> well defined in C++11 and later.  I don't know if C2X is considering
> mandating two's complement and making it well defined like C++20 did.

C2x requires two's complement but that's only about representation; there 
are no changes so far to what shifts are undefined.

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

Re: [PATCH] C-family : Add attribute 'unavailable'.

[Joseph Myers]

This patch seems to be missing documentation for the new attribute in 
extend.texi.

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

Re: [C PATCH RFC] Drop qualifiers during lvalue conversion

[Joseph Myers]

On Sat, 7 Nov 2020, Uecker, Martin wrote:

> In 'gcc.dg/cond-constqual-1.c' we test for the opposite
> behavior for conditional operators. I do not know why.
> We could just invert the test.

That's probably a relic of the old idea that rvalues might actually have 
qualified type in some cases; it seems reasonable to invert the test.

>   t = (const T) { { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 } };
>   test ();
> }
> 
> Not sure what to do about it, maybe 'convert' is not
> the right function to use.

I think 'convert' is fine, but new code is probably needed in whatever 
implements the optimization for assignment from compound literals so that 
it works when there is a conversion that only changes qualifiers.

> diff --git a/gcc/c/c-typeck.c b/gcc/c/c-typeck.c
> index 96840377d90..aeacd30badd 100644
> --- a/gcc/c/c-typeck.c
> +++ b/gcc/c/c-typeck.c
> @@ -2080,6 +2080,8 @@ convert_lvalue_to_rvalue (location_t loc, struct c_expr 
> exp,
>  exp = default_function_array_conversion (loc, exp);
>    if (!VOID_TYPE_P (TREE_TYPE (exp.value)))
>  exp.value = require_complete_type (loc, exp.value);
> +  if (convert_p && !error_operand_p (exp.value))
> +exp.value = convert (build_qualified_type (TREE_TYPE (exp.value), 
> TYPE_UNQUALIFIED),
> exp.value);

I think it might be safest to avoid doing any conversion in the case where 
the value is still of array type at this point (C90 non-lvalue arrays).

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

Ping^2 Re: float.h: C2x NaN and Inf macros

[Joseph Myers]

Ping^2.  This patch 
 is 
still pending review (the DFP sNaN followup has been approved).

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

Re: [PATCH] mixing of labels and code in C2X

[Joseph Myers]

On Fri, 6 Nov 2020, Uecker, Martin wrote:

> Am Freitag, den 06.11.2020, 22:07 + schrieb Joseph Myers:
> > On Fri, 6 Nov 2020, Uecker, Martin wrote:
> > 
> > > Hi Joseph,
> > > 
> > > here is the revised patch. I remove the 'fallthrough'
> > > code as suggested, so everything becomes even simpler.
> > > Some tests had to be changed then, but it seems Ok to
> > > me.
> > 
> > This patch is missing the new tests.
> > 
> > > + * gcc.dg/c11-labels-1.c: New test.
> > > + * gcc.dg/c11-labels-2.c: New test.
> > > + * gcc.dg/c11-labels-3.c: New test.
> > > + * gcc.dg/c2x-labels-1.c: New test.
> > > + * gcc.dg/c2x-labels-2.c: New test.
> > > + * gcc.dg/c2x-labels-3.c: New test.
> 
> My bad. Here there are.

Thanks.  This version is OK (note that ChangeLog entries now need to be 
included in the commit message, not as changes to the ChangeLog files, and 
the nightly cron job will update the ChangeLog files).

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

Re: [PATCH] mixing of labels and code in C2X

[Joseph Myers]

On Fri, 6 Nov 2020, Uecker, Martin wrote:

> Hi Joseph,
> 
> here is the revised patch. I remove the 'fallthrough'
> code as suggested, so everything becomes even simpler.
> Some tests had to be changed then, but it seems Ok to
> me.

This patch is missing the new tests.

> + * gcc.dg/c11-labels-1.c: New test.
> + * gcc.dg/c11-labels-2.c: New test.
> + * gcc.dg/c11-labels-3.c: New test.
> + * gcc.dg/c2x-labels-1.c: New test.
> + * gcc.dg/c2x-labels-2.c: New test.
> + * gcc.dg/c2x-labels-3.c: New test.

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

Re: [PATCH] Objective-C/C++ (C-family) : Add missing 'atomic' property attribute.

[Joseph Myers]

On Fri, 6 Nov 2020, Iain Sandoe wrote:

> Hi
> 
> Arguably, this is actually a bug fix since the ‘atomic’ attribute is
> paired with the ‘nonatomic’ one.  However it is the default and was
> omitted when the @property implementation was added.
> 
> ‘atomic’ in Objective-C terms is not specified in relation to _Atomic
> or std::atomic (the _Atomic keyword is not accepted in that context).
> 
> tested across several Darwin versions and on x86_64-linux-gnu
> 
> OK for the C-family parts?

OK.

(_Atomic isn't accepted for Objective-C at all at present; see the comment 
on the relevant sorry in c-parser.c.)

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

Re: [PATCH] Objective-C : Implement NSObject attribute.

[Joseph Myers]

On Fri, 6 Nov 2020, Iain Sandoe wrote:

> Hi
> 
> Originally, I had this as a Darwin-only patch, however GNUStep
> also makes use of NSObject and similar constructs, so this really
> needs to be available to linux-gnu as well.
> 
> tested across several Darwin versions and on x86_64-linux-gnu.
> 
> OK for the c-family changes?

OK.

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

float.h: C2x decimal signaling NaN macros

[Joseph Myers]

C2x adds macros for decimal floating-point signaling NaNs to
.  Add these macros to GCC's  implementation.

Note that the current C2x draft has these under incorrect names
D32_SNAN, D64_SNAN, D128_SNAN.  The intent was to change the naming
convention to be consistent with other  macros when they were
moved to , so DEC32_SNAN, DEC64_SNAN, DEC128_NAN, which this
patch uses (as does the current draft integration of TS 18661-3 as an
Annex to C2x, for its _Decimal* and _Decimal*x types).

This patch is relative to a tree with
<https://gcc.gnu.org/pipermail/gcc-patches/2020-October/557136.html>
and
<https://gcc.gnu.org/pipermail/gcc-patches/2020-November/558126.html>
(both pending review) applied.

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

gcc/
2020-11-05  Joseph Myers  

* ginclude/float.h (DEC32_SNAN, DEC64_SNAN, DEC128_SNAN): New C2x
macros.

gcc/testsuite/
2020-11-05  Joseph Myers  

* gcc.dg/dfp/c2x-float-dfp-7.c, gcc.dg/dfp/c2x-float-dfp-8.c: New
tests.
* gcc.dg/c2x-float-no-dfp-3.c: Also check that DEC32_SNAN,
DEC64_SNAN and DEC128_SNAN are not defined.

diff --git a/gcc/ginclude/float.h b/gcc/ginclude/float.h
index 77446995515..0fa00461230 100644
--- a/gcc/ginclude/float.h
+++ b/gcc/ginclude/float.h
@@ -601,6 +601,14 @@ see the files COPYING3 and COPYING.RUNTIME respectively.  
If not, see
 #undef DEC_NAN
 #define DEC_NAN(__builtin_nand32 (""))
 
+/* Signaling NaN in each decimal floating-point type.  */
+#undef DEC32_SNAN
+#define DEC32_SNAN (__builtin_nansd32 (""))
+#undef DEC64_SNAN
+#define DEC64_SNAN (__builtin_nansd64 (""))
+#undef DEC128_SNAN
+#define DEC128_SNAN(__builtin_nansd128 (""))
+
 #endif /* C2X */
 
 #endif /* __DEC32_MANT_DIG__ */
diff --git a/gcc/testsuite/gcc.dg/c2x-float-no-dfp-3.c 
b/gcc/testsuite/gcc.dg/c2x-float-no-dfp-3.c
index d8a239c787e..aa790c8e21d 100644
--- a/gcc/testsuite/gcc.dg/c2x-float-no-dfp-3.c
+++ b/gcc/testsuite/gcc.dg/c2x-float-no-dfp-3.c
@@ -12,3 +12,15 @@
 #ifdef DEC_NAN
 # error "DEC_NAN defined"
 #endif
+
+#ifdef DEC32_SNAN
+# error "DEC32_SNAN defined"
+#endif
+
+#ifdef DEC64_SNAN
+# error "DEC64_SNAN defined"
+#endif
+
+#ifdef DEC128_SNAN
+# error "DEC128_SNAN defined"
+#endif
diff --git a/gcc/testsuite/gcc.dg/dfp/c2x-float-dfp-7.c 
b/gcc/testsuite/gcc.dg/dfp/c2x-float-dfp-7.c
new file mode 100644
index 000..dec6b500656
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/dfp/c2x-float-dfp-7.c
@@ -0,0 +1,45 @@
+/* Test DEC*_SNAN macros defined in  with DFP support.  */
+/* { dg-do run } */
+/* { dg-options "-std=c2x" } */
+
+#include 
+
+#ifndef DEC32_SNAN
+# error "DEC32_SNAN not defined"
+#endif
+
+#ifndef DEC64_SNAN
+# error "DEC64_SNAN not defined"
+#endif
+
+#ifndef DEC128_SNAN
+# error "DEC128_SNAN not defined"
+#endif
+
+volatile _Decimal32 d32 = DEC32_SNAN;
+volatile _Decimal64 d64 = DEC64_SNAN;
+volatile _Decimal128 d128 = DEC128_SNAN;
+
+extern void abort (void);
+extern void exit (int);
+
+int
+main (void)
+{
+  (void) _Generic (DEC32_SNAN, _Decimal32 : 0);
+  if (!__builtin_isnan (DEC32_SNAN))
+abort ();
+  if (!__builtin_isnan (d32))
+abort ();
+  (void) _Generic (DEC64_SNAN, _Decimal64 : 0);
+  if (!__builtin_isnan (DEC64_SNAN))
+abort ();
+  if (!__builtin_isnan (d64))
+abort ();
+  (void) _Generic (DEC128_SNAN, _Decimal128 : 0);
+  if (!__builtin_isnan (DEC128_SNAN))
+abort ();
+  if (!__builtin_isnan (d128))
+abort ();
+  exit (0);
+}
diff --git a/gcc/testsuite/gcc.dg/dfp/c2x-float-dfp-8.c 
b/gcc/testsuite/gcc.dg/dfp/c2x-float-dfp-8.c
new file mode 100644
index 000..4169602fd9c
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/dfp/c2x-float-dfp-8.c
@@ -0,0 +1,45 @@
+/* Test DEC*_SNAN macros.  Test requiring runtime exceptions
+   support.  */
+/* { dg-do run } */
+/* { dg-require-effective-target fenv_exceptions_dfp } */
+/* { dg-options "-std=c2x" } */
+
+#include 
+#include 
+
+volatile _Decimal32 d32 = DEC32_SNAN;
+volatile _Decimal64 d64 = DEC64_SNAN;
+volatile _Decimal128 d128 = DEC128_SNAN;
+
+extern void abort (void);
+extern void exit (int);
+
+int
+main (void)
+{
+  feclearexcept (FE_ALL_EXCEPT);
+  d32 += d32;
+  if (!fetestexcept (FE_INVALID))
+abort ();
+  feclearexcept (FE_ALL_EXCEPT);
+  d32 += d32;
+  if (fetestexcept (FE_INVALID))
+abort ();
+  feclearexcept (FE_ALL_EXCEPT);
+  d64 += d64;
+  if (!fetestexcept (FE_INVALID))
+abort ();
+  feclearexcept (FE_ALL_EXCEPT);
+  d64 += d64;
+  if (fetestexcept (FE_INVALID))
+abort ();
+  feclearexcept (FE_ALL_EXCEPT);
+  d128 += d128;
+  if (!fetestexcept (FE_INVALID))
+abort ();
+  feclearexcept (FE_ALL_EXCEPT);
+  d128 += d128;
+  if (fetestexcept (FE_INVALID))
+abort ();
+  exit (0);
+}

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

builtins: Add DFP signaling NaN built-in functions

[Joseph Myers]

Add built-in functions __builtin_nansd32, __builtin_nansd64 and
__builtin_nansd128 to return signaling NaNs of decimal floating-point
types, analogous to the functions already present for binary
floating-point types.

This patch, independent of
<https://gcc.gnu.org/pipermail/gcc-patches/2020-October/557136.html>
(pending review), is in preparation for adding the  macros
for such signaling NaNs that are in C2x, analogous to the macros for
other types that are in that patch.

Bootstrapped with no regressions for x86_64-pc-linux-gnu.  Also ran
the new tests for powerpc64le-linux-gnu to confirm they do work in the
case (hardware DFP) where floating-point exceptions are supported for
DFP.  OK to commit?

gcc/
2020-11-05  Joseph Myers  

* builtins.def (BUILT_IN_NANSD32, BUILT_IN_NANSD64)
(BUILT_IN_NANSD128): New built-in functions.
* fold-const-call.c (fold_const_call): Handle the new built-in
functions.
* doc/extend.texi (__builtin_nansd32, __builtin_nansd64)
(__builtin_nansd128): Document.
* doc/sourcebuild.texi (Effective-Target Keywords): Document
fenv_exceptions_dfp.

gcc/testsuite/
2020-11-05  Joseph Myers  

* lib/target-supports.exp
(check_effective_target_fenv_exceptions_dfp): New.
* gcc.dg/dfp/builtin-snan-1.c, gcc.dg/dfp/builtin-snan-2.c: New
tests.

diff --git a/gcc/builtins.def b/gcc/builtins.def
index 68f2da6cda4..b4494c712a1 100644
--- a/gcc/builtins.def
+++ b/gcc/builtins.def
@@ -518,6 +518,9 @@ DEF_GCC_BUILTIN(BUILT_IN_NANSF, "nansf", 
BT_FN_FLOAT_CONST_STRING, ATTR_
 DEF_GCC_BUILTIN(BUILT_IN_NANSL, "nansl", 
BT_FN_LONGDOUBLE_CONST_STRING, ATTR_CONST_NOTHROW_NONNULL)
 DEF_GCC_FLOATN_NX_BUILTINS (BUILT_IN_NANS, "nans", NAN_TYPE, 
ATTR_CONST_NOTHROW_NONNULL)
 #undef NAN_TYPE
+DEF_GCC_BUILTIN(BUILT_IN_NANSD32, "nansd32", 
BT_FN_DFLOAT32_CONST_STRING, ATTR_CONST_NOTHROW_NONNULL)
+DEF_GCC_BUILTIN(BUILT_IN_NANSD64, "nansd64", 
BT_FN_DFLOAT64_CONST_STRING, ATTR_CONST_NOTHROW_NONNULL)
+DEF_GCC_BUILTIN(BUILT_IN_NANSD128, "nansd128", 
BT_FN_DFLOAT128_CONST_STRING, ATTR_CONST_NOTHROW_NONNULL)
 DEF_C99_BUILTIN(BUILT_IN_NEARBYINT, "nearbyint", BT_FN_DOUBLE_DOUBLE, 
ATTR_CONST_NOTHROW_LEAF_LIST)
 DEF_C99_BUILTIN(BUILT_IN_NEARBYINTF, "nearbyintf", BT_FN_FLOAT_FLOAT, 
ATTR_CONST_NOTHROW_LEAF_LIST)
 DEF_C99_BUILTIN(BUILT_IN_NEARBYINTL, "nearbyintl", 
BT_FN_LONGDOUBLE_LONGDOUBLE, ATTR_CONST_NOTHROW_LEAF_LIST)
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index 7a6ecce6a84..e6a9bdf1099 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -13865,6 +13865,18 @@ to be a signaling NaN@.  The @code{nans} function is 
proposed by
 @uref{http://www.open-std.org/jtc1/sc22/wg14/www/docs/n965.htm,,WG14 N965}.
 @end deftypefn
 
+@deftypefn {Built-in Function} _Decimal32 __builtin_nansd32 (const char *str)
+Similar to @code{__builtin_nans}, except the return type is @code{_Decimal32}.
+@end deftypefn
+
+@deftypefn {Built-in Function} _Decimal64 __builtin_nansd64 (const char *str)
+Similar to @code{__builtin_nans}, except the return type is @code{_Decimal64}.
+@end deftypefn
+
+@deftypefn {Built-in Function} _Decimal128 __builtin_nansd128 (const char *str)
+Similar to @code{__builtin_nans}, except the return type is @code{_Decimal128}.
+@end deftypefn
+
 @deftypefn {Built-in Function} float __builtin_nansf (const char *str)
 Similar to @code{__builtin_nans}, except the return type is @code{float}.
 @end deftypefn
diff --git a/gcc/doc/sourcebuild.texi b/gcc/doc/sourcebuild.texi
index 49316a5d0ff..b3c5e530423 100644
--- a/gcc/doc/sourcebuild.texi
+++ b/gcc/doc/sourcebuild.texi
@@ -2356,6 +2356,11 @@ Target provides @file{fenv.h} include file.
 Target supports @file{fenv.h} with all the standard IEEE exceptions
 and floating-point exceptions are raised by arithmetic operations.
 
+@item fenv_exceptions_dfp
+Target supports @file{fenv.h} with all the standard IEEE exceptions
+and floating-point exceptions are raised by arithmetic operations for
+decimal floating point.
+
 @item fileio
 Target offers such file I/O library functions as @code{fopen},
 @code{fclose}, @code{tmpnam}, and @code{remove}.  This is a link-time
diff --git a/gcc/fold-const-call.c b/gcc/fold-const-call.c
index 11ed47db3d9..3548fab78cd 100644
--- a/gcc/fold-const-call.c
+++ b/gcc/fold-const-call.c
@@ -1300,6 +1300,9 @@ fold_const_call (combined_fn fn, tree type, tree arg)
 
 CASE_CFN_NANS:
 CASE_FLT_FN_FLOATN_NX (CFN_BUILT_IN_NANS):
+case CFN_BUILT_IN_NANSD32:
+case CFN_BUILT_IN_NANSD64:
+case CFN_BUILT_IN_NANSD128:
   return fold_const_builtin_nan (type, arg, false);
 
 case CFN_REDUC_PLUS:
diff --git a/gcc/testsuite/gcc.dg/dfp/builtin-snan-1.c 
b/gcc/testsuite/gcc.dg/dfp/builtin-snan-1.c
new file mode 100644
index 000..49a32c87546
--- /dev/null
+++ 

Re: [PATCH v5] rtl: builtins: (not just) rs6000: Add builtins for fegetround, feclearexcept and feraiseexcept [PR94193]

[Joseph Myers]

On Wed, 4 Nov 2020, Richard Biener wrote:

> AFAICS you do nothing to marshall with the actually used libc
> implementation which AFAIU can choose arbitrary values for
> the FE_* macros.  I'm not sure we require the compiler to be
> configured for one specific C library and for example require
> matching FE_* macro definitions for all uses of the built
> compiler.

The compiler is definitely expected to match a given C library.  This 
applies for  and other typedefs, for example (various of which 
are used for printf format checking).  It also applies to FE_* in some 
cases where relevant for __atomic_feraiseexcept for floating-point atomic 
compound assignment.

> Now, I wonder whether _GCC_ should provide the FE_* macros, thus
> move (parts of) fenv.h to GCC like we do for stdint.h?

I think that would be a bad idea.  fenv.h involves library functionality 
that can sometimes need to do things beyond simply modifying hardware 
registers.  Consider e.g. the TLS exception and rounding mode state for 
soft-float powerpc-linux-gnu.  Or the TLS decimal rounding mode in libdfp.  
Or how exception enabling can involve a prctl call on powerpc.  Getting 
libgcc involved in storing such TLS state seems problematic.  And whether 
an FE_* macro should be defined may depend on whether the library supports 
the underlying functionality (consider the case of FE_TONEARESTFROMZERO 
for RISC-V, where defining it should mean library code actually works in 
that rounding mode, not just that hardware supports it).

The natural way to handle the rule in C2x that "The strictly conforming 
programs that shall be accepted by a conforming freestanding 
implementation that defines __STDC_IEC_60559_BFP__ or 
__STDC_IEC_60559_DFP__ may also use features in the contents of the 
standard headers  and  and the numeric conversion 
functions (7.22.1) of the standard header ." would be to say 
that GCC provides the compiler pieces of a freestanding implementation, 
not necessarily the whole freestanding implementation.  (Those macros 
would only be defined via implicit preinclusion of stdc-predef.h anyway.)

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

Re: [PATCH v5] rtl: builtins: (not just) rs6000: Add builtins for fegetround, feclearexcept and feraiseexcept [PR94193]

[Joseph Myers]

On Wed, 4 Nov 2020, Raoni Fassina Firmino via Gcc-patches wrote:

> IMHO, It seems like it is not necessary if there not a libc that have
> different values for the FE_* macros. I didn't check other archs, but if
> is the case for some other arch I think it could be changed if and when
> some other arch implements expands for these builtins.

SPARC is the case I know of where the FE_* values vary depending on target 
libc (see the SPARC_LOW_FE_EXCEPT_VALUES target macro).

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

c: Implement C2x nodiscard attribute

[Joseph Myers]

C2x adds the nodiscard standard attribute, with an optional string
argument, as in C++; implement it for C.

Bootstrapped with no regressions for x86_64-pc-linux-gnu.  Applied to 
mainline.

gcc/c/
2020-11-04  Joseph Myers  

* c-decl.c (handle_nodiscard_attribute): New.
(std_attribute_table): Add nodiscard.
* c-parser.c (c_parser_std_attribute): Expect argument to
nodiscard attribute to be a string.  Do not special-case ignoring
nodiscard.
* c-typeck.c (maybe_warn_nodiscard): New.
(build_compound_expr, emit_side_effect_warnings): Call
maybe_warn_nodiscard.
(c_process_expr_stmt, c_finish_stmt_expr): Also call
emit_side_effect_warnings if warn_unused_result.

gcc/testsuite/
2020-11-04  Joseph Myers  

* gcc.dg/c2x-attr-nodiscard-1.c, gcc.dg/c2x-attr-nodiscard-2.c,
gcc.dg/c2x-attr-nodiscard-3.c, gcc.dg/c2x-attr-nodiscard-4.c: New
tests.
* gcc.dg/c2x-attr-syntax-5.c: Remove nodiscard test.

diff --git a/gcc/c/c-decl.c b/gcc/c/c-decl.c
index a5d0b158a26..d4179aad189 100644
--- a/gcc/c/c-decl.c
+++ b/gcc/c/c-decl.c
@@ -4400,6 +4400,31 @@ lookup_name_fuzzy (tree name, enum 
lookup_name_fuzzy_kind kind, location_t loc)
 }
 
 
+/* Handle the standard [[nodiscard]] attribute.  */
+
+static tree
+handle_nodiscard_attribute (tree *node, tree name, tree /*args*/,
+   int /*flags*/, bool *no_add_attrs)
+{
+  if (TREE_CODE (*node) == FUNCTION_DECL)
+{
+  if (VOID_TYPE_P (TREE_TYPE (TREE_TYPE (*node
+   warning_at (DECL_SOURCE_LOCATION (*node),
+   OPT_Wattributes, "%qE attribute applied to %qD with void "
+   "return type", name, *node);
+}
+  else if (RECORD_OR_UNION_TYPE_P (*node)
+  || TREE_CODE (*node) == ENUMERAL_TYPE)
+/* OK */;
+  else
+{
+  pedwarn (input_location,
+  OPT_Wattributes, "%qE attribute can only be applied to "
+  "functions or to structure, union or enumeration types", name);
+  *no_add_attrs = true;
+}
+  return NULL_TREE;
+}
 /* Table of supported standard (C2x) attributes.  */
 const struct attribute_spec std_attribute_table[] =
 {
@@ -4411,6 +4436,8 @@ const struct attribute_spec std_attribute_table[] =
 handle_fallthrough_attribute, NULL },
   { "maybe_unused", 0, 0, false, false, false, false,
 handle_unused_attribute, NULL },
+  { "nodiscard", 0, 1, false, false, false, false,
+handle_nodiscard_attribute, NULL },
   { NULL, 0, 0, false, false, false, false, NULL, NULL }
 };
 
diff --git a/gcc/c/c-parser.c b/gcc/c/c-parser.c
index b921c4e3852..fc97aa3f95f 100644
--- a/gcc/c/c-parser.c
+++ b/gcc/c/c-parser.c
@@ -4950,7 +4950,8 @@ c_parser_std_attribute (c_parser *parser, bool for_tm)
 && attribute_takes_identifier_p (name));
bool require_string
  = (ns == NULL_TREE
-&& strcmp (IDENTIFIER_POINTER (name), "deprecated") == 0);
+&& (strcmp (IDENTIFIER_POINTER (name), "deprecated") == 0
+|| strcmp (IDENTIFIER_POINTER (name), "nodiscard") == 0));
TREE_VALUE (attribute)
  = c_parser_attribute_arguments (parser, takes_identifier,
  require_string, false);
@@ -4960,13 +4961,12 @@ c_parser_std_attribute (c_parser *parser, bool for_tm)
 parens.require_close (parser);
   }
  out:
-  if (ns == NULL_TREE && !for_tm && !as && !is_attribute_p ("nodiscard", name))
+  if (ns == NULL_TREE && !for_tm && !as)
 {
   /* An attribute with standard syntax and no namespace specified
 is a constraint violation if it is not one of the known
-standard attributes (of which nodiscard is the only one
-without a handler in GCC).  Diagnose it here with a pedwarn
-and then discard it to prevent a duplicate warning later.  */
+standard attributes.  Diagnose it here with a pedwarn and
+then discard it to prevent a duplicate warning later.  */
   pedwarn (input_location, OPT_Wattributes, "%qE attribute ignored",
   name);
   return error_mark_node;
diff --git a/gcc/c/c-typeck.c b/gcc/c/c-typeck.c
index 981cbe891a7..0d75ed4f8b1 100644
--- a/gcc/c/c-typeck.c
+++ b/gcc/c/c-typeck.c
@@ -5490,6 +5490,82 @@ build_conditional_expr (location_t colon_loc, tree 
ifexp, bool ifexp_bcp,
   return ret;
 }
 
+/* EXPR is an expression, location LOC, whose result is discarded.
+   Warn if it is a call to a nodiscard function (or a COMPOUND_EXPR
+   whose right-hand operand is such a call, possibly recursively).  */
+
+static void
+maybe_warn_nodiscard (location_t loc, tree expr)
+{
+  if (VOID_TYPE_P (TREE_TYPE (expr)))
+return;
+  while (TREE_CODE (expr) == COMPOUND_EXPR)
+{
+  expr = TREE_OPERAND (expr, 1);
+

Re: [04/32] cpp lexer

[Joseph Myers]

On Tue, 3 Nov 2020, Nathan Sidwell wrote:

> @@ -888,9 +915,9 @@ struct GTY(()) cpp_hashnode {
>unsigned int directive_index : 7;  /* If is_directive,
>  then index into directive table.
>  Otherwise, a NODE_OPERATOR.  */
> -  unsigned char rid_code;/* Rid code - for front ends.  */
> +  unsigned int rid_code : 8; /* Rid code - for front ends.  */
> +  unsigned int flags : 9;/* CPP flags.  */
>ENUM_BITFIELD(node_type) type : 2; /* CPP node type.  */
> -  unsigned int flags : 8;/* CPP flags.  */
>  
>/* 6 bits spare (plus another 32 on 64-bit hosts).  */

I'd expect this "6 bits spare" comment to be updated when expanding the 
flags field.

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

Re: PowerPC: Add __float128 conversions to/from Decimal

[Joseph Myers]

On Mon, 2 Nov 2020, Segher Boessenkool wrote:

> > Also note that if you want to use printf as opposed to strfromf128 for 
> > IEEE binary128 you'll need to use __printfieee128 (the version that 
> > expects long double to be IEEE binary128) which was introduced in glibc 
> > 2.32, so that doesn't help with the glibc version dependencies.
> 
> libiberty has printf functions of its own, I was wondering if those work
> fine; if they do, that would solve all problems here.

I don't see any meaningful kind of printf implementation in libiberty.  
There are implementations of various printf functions in terms of other 
printf functions (including vprintf in terms of vfprintf in terms of 
_doprnt in terms of fprintf), but nothing that actually does the main work 
of converting a floating-point value to a string without calling out to 
some libc printf function.

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

Re: [PATCH] mixing of labels and code in C2X

[Joseph Myers]

On Sun, 1 Nov 2020, Uecker, Martin wrote:

> @@ -5693,27 +5692,54 @@ c_parser_compound_statement_nostart (c_parser *parser)
>     last_label = true;
>     last_stmt = false;
>     mark_valid_location_for_stdc_pragma (false);
> -   c_parser_label (parser);
> +   c_parser_label (parser, std_attrs);
> +
> +   /* Allow '__attribute__((fallthrough));'.  */
> +   if (c_parser_next_token_is_keyword (parser, RID_ATTRIBUTE))
> + {
> +   location_t loc = c_parser_peek_token (parser)->location;
> +   tree attrs = c_parser_gnu_attributes (parser);
> +   if (attribute_fallthrough_p (attrs))
> + {
> +   if (c_parser_next_token_is (parser, CPP_SEMICOLON))
> + {
> +   tree fn = build_call_expr_internal_loc (loc,
> +   IFN_FALLTHROUGH,
> +   void_type_node, 
> 0);
> +   add_stmt (fn);
> + }
> +   else
> +  warning_at (loc, OPT_Wattributes, "% 
> attribute "
> +   "not followed by %<;%>");
> + }
> +   else if (attrs != NULL_TREE)
> + warning_at (loc, OPT_Wattributes, "only attribute 
> %"
> + " can be applied to a null statement");
> + }

I don't think this is necessary or correct here.

This code is being moved from c_parser_label.  The syntax that 
c_parser_label was supposed to handle, as shown in the comment above the 
function, is:

   label:
 identifier : gnu-attributes[opt]
 case constant-expression :
 default :

   GNU extensions:

   label:
 case constant-expression ... constant-expression :

That is: attributes on a label that is an identifier were parsed, and 
applied to the identifier, by code that's unchanged (beyond applying 
standard attributes rather than just warning in the caller that they are 
unused) by this patch.  So this code could only fire in c_parser_label for 
a case or default label, a case in which GNU attributes on the label are 
not part of the syntax.

Previously, a case or default label could not be followed by a 
declaration, so there was no particular concern about consuming prefix GNU 
attributes on such a following declaration; the declaration would still 
result in a syntax error (and fallthrough attributes were the only valid 
case needing to be handled).  Now that such a declaration is valid, I 
think the attributes should be be parsed specially here, but left to apply 
to that declaration.  The code in c_parser_declaration_or_fndef that 
handles GNU fallthrough attributes should suffice to handle one in this 
case; other warnings for empty declarations should suffice in the case 
where there are other attributes but no declaration following.

> @@ -5843,12 +5879,10 @@ c_parser_all_labels (c_parser *parser)
> GNU C accepts any expressions without commas, non-constant
> expressions being rejected later.  Any standard
> attribute-specifier-sequence before the first label has been parsed
> -   in the caller, to distinguish statements from declarations.  Any
> -   attribute-specifier-sequence after the label is parsed in this
> -   function.  */
> +   in the caller, to distinguish statements from declarations.  */

I don't think this change to the comment is accurate.  As shown in the 
(unmodified) syntax comment, GNU attributes on a label that is an 
identifier (the only kind that has them) are still parsed in this 
function.  It's only fallthrough attributes after case and default labels 
(which weren't part of that syntax comment anyway) that are no longer 
parsed here.

> @@ -5898,8 +5932,13 @@ c_parser_label (c_parser *parser)
>    if (tlab)
>   {
>     decl_attributes (, attrs, 0);
> +   decl_attributes (, std_attrs, 0);
>     label = add_stmt (build_stmt (loc1, LABEL_EXPR, tlab));
>   }
> +  if (attrs
> +   && c_parser_next_tokens_start_declaration (parser))
> +   warning_at (loc2, OPT_Wattributes, "GNU-style attribute between"
> +   " label and declaration appertains to the label.");

No trailing '.' on diagnostics.

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

Ping Re: float.h: C2x NaN and Inf macros

[Joseph Myers]

Ping.  This patch 
 is 
pending review.

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

Re: PowerPC: Add __float128 conversions to/from Decimal

[Joseph Myers]

On Thu, 29 Oct 2020, Segher Boessenkool wrote:

> > Doing these conversions accurately is nontrivial.  Converting via strings 
> > is the simple approach (i.e. the one that moves the complexity somewhere 
> > else).  There are more complicated but more efficient approaches that can 
> > achieve correct conversions with smaller bounds on resource usage (and 
> > there are various papers published in this area), but those involve a lot 
> > more code (and precomputed data, with a speed/space trade-off in how much 
> > you precompute; the BID code in libgcc has several MB of precomputed data 
> > for that purpose).
> 
> Does the printf code in libgcc handle things correctly for IEEE QP float
> as long double, do you know?

As far as I know, the code in libgcc for conversions *from* decimal *to* 
binary (so the direction that uses strtof128 as opposed to the one using 
strfrom128, in the binary128 case) works correctly, if the underlying libc 
has accurate string/numeric conversion operations.

Binary to decimal is another matter, even for cases such as float to 
_Decimal64.  I've just filed bug 97635 for that.

Also note that if you want to use printf as opposed to strfromf128 for 
IEEE binary128 you'll need to use __printfieee128 (the version that 
expects long double to be IEEE binary128) which was introduced in glibc 
2.32, so that doesn't help with the glibc version dependencies.

When I investigated and reported several bugs in the conversion operations 
in libdfp, I noted (e.g. https://github.com/libdfp/libdfp/issues/29 ) that 
the libgcc versions were working correctly for those tests (and filed and 
subsequently fixed one glibc strtod bug, missing inexact exceptions, that 
I'd noticed while looking at such issues in libdfp).  But the specific 
case I tested for badly rounded conversions was the case of conversions 
from decimal to binary, not the case of conversions from binary to 
decimal, which, as noted above, turn out to be buggy in libgcc.

Lots of bugs have been fixed in the glibc conversion code over the years 
(more on the strtod side than in the code shared by printf and strfrom 
functions).  That code uses multiple-precision operations from GMP, which 
avoids some complications but introduces others (it also needs to e.g. 
deal with locale issues, which are irrelevant for libgcc conversions).

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

Re: [PATCH] Treat { 0 } specially for structs with the designated_init attribute.

[Joseph Myers]

On Wed, 22 Jul 2020, Asher Gordon via Gcc-patches wrote:

> Hello Joseph, Martin,
> 
> Asher Gordon  writes:
> 
> > Joseph Myers  writes:
> >
> >> I don't see you in the FSF copyright assignment list; could you
> >> complete
> >> https://git.savannah.gnu.org/cgit/gnulib.git/plain/doc/Copyright/request-assign.future
> >> (unless you're already covered by an employer assignment)?
> >
> > Done.
> 
> My copyright assignment finally got finished, so you should be able to
> apply my patches now.
> 
> For your convenience, I have attached the three patches below:

I've tested and committed the first patch.  The second one introduces some 
test failures:

< PASS: gcc.dg/Wdesignated-init-2.c  (test for warnings, line 14)
< PASS: gcc.dg/Wdesignated-init-2.c  (test for warnings, line 15)
---
> FAIL: gcc.dg/Wdesignated-init-2.c  (test for warnings, line 14)
> FAIL: gcc.dg/Wdesignated-init-2.c  (test for warnings, line 15)

< PASS: gcc.dg/init-excess-2.c  (test for warnings, line 30)
---
> FAIL: gcc.dg/init-excess-2.c  (test for warnings, line 30)

Could you investigate those and send versions of the second and third 
patches that don't introduce any test regressions?

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

Re: PowerPC: Add __float128 conversions to/from Decimal

[Joseph Myers]

On Thu, 29 Oct 2020, Segher Boessenkool wrote:

> Hi!
> 
> On Thu, Oct 29, 2020 at 12:45:15PM -0400, Michael Meissner wrote:
> > On Wed, Oct 28, 2020 at 07:04:31PM -0500, Segher Boessenkool wrote:
> > > > +#if HAVE_KF_MODE
> > > > +  strfromf128 (buf, BUFMAX, BFP_FMT, (BFP_VIA_TYPE) x);
> > > > +#else
> > > >sprintf (buf, BFP_FMT, (BFP_VIA_TYPE) x);
> > > > +#endif
> > > 
> > > Does strfromf128 exist everywhere we build this?  It isn't a standard
> > > function.
> > 
> > Yes, it is in ISO/IEC TS 18661-3, which is the document that describes most 
> > of
> > the *f128 functions.
> 
> But this means it does *not* exist most places we build this?  Not the
> whole world is Linux (and even then, it is probably a too recent
> addition).

strfromf128 and strtof128 were added for powerpc64le-linux-gnu in glibc 
2.26.  (The variants that are namespace-clean in the absence of 18661-3, 
which may be relevant when being used for long double, __strfromieee128 
and __strtoieee128, were added in 2.32.)

Doing these conversions accurately is nontrivial.  Converting via strings 
is the simple approach (i.e. the one that moves the complexity somewhere 
else).  There are more complicated but more efficient approaches that can 
achieve correct conversions with smaller bounds on resource usage (and 
there are various papers published in this area), but those involve a lot 
more code (and precomputed data, with a speed/space trade-off in how much 
you precompute; the BID code in libgcc has several MB of precomputed data 
for that purpose).

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

stdbool.h: Update true and false expansions for C2x

[Joseph Myers]

C2x has changed the expansions of the true and false macros in
 so that they have type _Bool (including in #if conditions,
i.e. an unsigned type in that context).  Use the new expansions in
GCC's  for C2x.

See bug 82272 for related discussion (but this patch does *not*
implement the warning discussed there).

Note that it's possible there may be a further change to make bool,
true and false keywords (there was support in principle for that at
the April WG14 meeting).  But currently these expansions of type _Bool
are what C2x requires and there isn't actually a paper before WG14 at
present that would introduce the new keywords.

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

gcc/
2020-10-28  Joseph Myers  

* ginclude/stdbool.c [__STDC_VERSION__ > 201710L] (true, false):
Define with type _Bool.

gcc/testsuite/
2020-10-28  Joseph Myers  

* gcc.dg/c11-bool-1.c, gcc.dg/c2x-bool-1.c, gcc.dg/c99-bool-4.c:
New tests.

diff --git a/gcc/ginclude/stdbool.h b/gcc/ginclude/stdbool.h
index 1b56498d96f..23554223d67 100644
--- a/gcc/ginclude/stdbool.h
+++ b/gcc/ginclude/stdbool.h
@@ -31,8 +31,13 @@ see the files COPYING3 and COPYING.RUNTIME respectively.  If 
not, see
 #ifndef __cplusplus
 
 #define bool   _Bool
+#if defined __STDC_VERSION__ && __STDC_VERSION__ > 201710L
+#define true   ((_Bool)+1u)
+#define false  ((_Bool)+0u)
+#else
 #define true   1
 #define false  0
+#endif
 
 #else /* __cplusplus */
 
diff --git a/gcc/testsuite/gcc.dg/c11-bool-1.c 
b/gcc/testsuite/gcc.dg/c11-bool-1.c
new file mode 100644
index 000..0412624a706
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/c11-bool-1.c
@@ -0,0 +1,50 @@
+/* Test macro expansions in  in C11.  */
+/* { dg-do run } */
+/* { dg-options "-std=c11 -pedantic-errors" } */
+
+#include 
+
+#define str(x) xstr(x)
+#define xstr(x) #x
+
+extern void abort (void);
+extern void exit (int);
+extern int strcmp (const char *, const char *);
+
+#if false - 1 >= 0
+#error "false unsigned in #if"
+#endif
+
+#if false != 0
+#error "false not 0 in #if"
+#endif
+
+#if true - 2 >= 0
+#error "true unsigned in #if"
+#endif
+
+#if true != 1
+#error "true not 1 in #if"
+#endif
+
+int
+main (void)
+{
+  if (strcmp (str (bool), "_Bool") != 0)
+abort ();
+  if (_Generic (true, int : 1) != 1)
+abort ();
+  if (true != 1)
+abort ();
+  if (strcmp (str (true), "1") != 0)
+abort ();
+  if (_Generic (false, int : 1) != 1)
+abort ();
+  if (false != 0)
+abort ();
+  if (strcmp (str (false), "0") != 0)
+abort ();
+  if (strcmp (str (__bool_true_false_are_defined), "1") != 0)
+abort ();
+  exit (0);
+}
diff --git a/gcc/testsuite/gcc.dg/c2x-bool-1.c 
b/gcc/testsuite/gcc.dg/c2x-bool-1.c
new file mode 100644
index 000..b64da1f7b43
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/c2x-bool-1.c
@@ -0,0 +1,50 @@
+/* Test macro expansions in  in C2x.  */
+/* { dg-do run } */
+/* { dg-options "-std=c2x -pedantic-errors" } */
+
+#include 
+
+#define str(x) xstr(x)
+#define xstr(x) #x
+
+extern void abort (void);
+extern void exit (int);
+extern int strcmp (const char *, const char *);
+
+#if false - 1 < 0
+#error "false signed in #if"
+#endif
+
+#if false != 0
+#error "false not 0 in #if"
+#endif
+
+#if true - 2 < 0
+#error "true signed in #if"
+#endif
+
+#if true != 1
+#error "true not 1 in #if"
+#endif
+
+int
+main (void)
+{
+  if (strcmp (str (bool), "_Bool") != 0)
+abort ();
+  if (_Generic (true, _Bool : 1) != 1)
+abort ();
+  if (true != 1)
+abort ();
+  if (strcmp (str (true), "((_Bool)+1u)") != 0)
+abort ();
+  if (_Generic (false, _Bool : 1) != 1)
+abort ();
+  if (false != 0)
+abort ();
+  if (strcmp (str (false), "((_Bool)+0u)") != 0)
+abort ();
+  if (strcmp (str (__bool_true_false_are_defined), "1") != 0)
+abort ();
+  exit (0);
+}
diff --git a/gcc/testsuite/gcc.dg/c99-bool-4.c 
b/gcc/testsuite/gcc.dg/c99-bool-4.c
new file mode 100644
index 000..5cae18ad0ce
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/c99-bool-4.c
@@ -0,0 +1,46 @@
+/* Test macro expansions in  in C99.  */
+/* { dg-do run } */
+/* { dg-options "-std=c99 -pedantic-errors" } */
+
+#include 
+
+#define str(x) xstr(x)
+#define xstr(x) #x
+
+extern void abort (void);
+extern void exit (int);
+extern int strcmp (const char *, const char *);
+
+#if false - 1 >= 0
+#error "false unsigned in #if"
+#endif
+
+#if false != 0
+#error "false not 0 in #if"
+#endif
+
+#if true - 2 >= 0
+#error "true unsigned in #if"
+#endif
+
+#if true != 1
+#error "true not 1 in #if"
+#endif
+
+int
+main (void)
+{
+  if (strcmp (str (bool), "_Bool") != 0)
+abort ();
+  if (true != 1)
+abort ();
+  if (strcmp (str (true), "1") != 0)
+abort ();
+  if (false != 0)
+abort ();
+  if (strcmp (str (false), "0") != 0)
+abort ();
+  if (strcmp (str (__bool_true_false_are_defined), "1") != 0)
+abort ();
+  exit (0);
+}

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

c: Allow omitted parameter names for C2x

[Joseph Myers]

C2x allows parameter names to be omitted in function definitions, as
in C++; add support for this feature.  As with other features that
only result in previously rejected code being accepted, this feature
is now accepted as an extension for previous standard versions, with a
pedwarn-if-pedantic that is disabled by -Wno-c11-c2x-compat.  The
logic for avoiding unused-parameter warnings for unnamed parameters is
in code shared between C and C++, so no changes are needed there.

Bootstrapped with no regressions for x86_64-pc-linux-gnu.  Applied to 
mainline.

gcc/c/
2020-10-28  Joseph Myers  

* c-decl.c (store_parm_decls_newstyle): Use pedwarn_c11 not
error_at for omitted parameter name.

gcc/testsuite/
2020-10-28  Joseph Myers  

* gcc.dg/c11-parm-omit-1.c, gcc.dg/c11-parm-omit-2.c,
gcc.dg/c11-parm-omit-3.c, gcc.dg/c11-parm-omit-4.c,
gcc.dg/c2x-parm-omit-1.c, gcc.dg/c2x-parm-omit-2.c,
gcc.dg/c2x-parm-omit-3.c, gcc.dg/c2x-parm-omit-4.c: New tests.
* gcc.dg/noncompile/pr79758.c: Do not expect error for omitted
parameter name.

diff --git a/gcc/c/c-decl.c b/gcc/c/c-decl.c
index 1673b958555..a5d0b158a26 100644
--- a/gcc/c/c-decl.c
+++ b/gcc/c/c-decl.c
@@ -9630,7 +9630,9 @@ store_parm_decls_newstyle (tree fndecl, const struct 
c_arg_info *arg_info)
warn_if_shadowing (decl);
}
   else
-   error_at (DECL_SOURCE_LOCATION (decl), "parameter name omitted");
+   pedwarn_c11 (DECL_SOURCE_LOCATION (decl), OPT_Wpedantic,
+"ISO C does not support omitting parameter names in "
+"function definitions before C2X");
 }
 
   /* Record the parameter list in the function declaration.  */
diff --git a/gcc/testsuite/gcc.dg/c11-parm-omit-1.c 
b/gcc/testsuite/gcc.dg/c11-parm-omit-1.c
new file mode 100644
index 000..83d1b508286
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/c11-parm-omit-1.c
@@ -0,0 +1,5 @@
+/* Test omitted parameter names not in C11: -pedantic-errors.  */
+/* { dg-do compile } */
+/* { dg-options "-std=c11 -pedantic-errors" } */
+
+void f (int) { } /* { dg-error "omitting parameter names" } */
diff --git a/gcc/testsuite/gcc.dg/c11-parm-omit-2.c 
b/gcc/testsuite/gcc.dg/c11-parm-omit-2.c
new file mode 100644
index 000..2efd4505db3
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/c11-parm-omit-2.c
@@ -0,0 +1,5 @@
+/* Test omitted parameter names not in C11: -pedantic.  */
+/* { dg-do compile } */
+/* { dg-options "-std=c11 -pedantic" } */
+
+void f (int) { } /* { dg-warning "omitting parameter names" } */
diff --git a/gcc/testsuite/gcc.dg/c11-parm-omit-3.c 
b/gcc/testsuite/gcc.dg/c11-parm-omit-3.c
new file mode 100644
index 000..5bf27a03aff
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/c11-parm-omit-3.c
@@ -0,0 +1,5 @@
+/* Test omitted parameter names not in C11: -pedantic -Wno-c11-c2x-compat.  */
+/* { dg-do compile } */
+/* { dg-options "-std=c11 -pedantic -Wno-c11-c2x-compat" } */
+
+void f (int) { }
diff --git a/gcc/testsuite/gcc.dg/c11-parm-omit-4.c 
b/gcc/testsuite/gcc.dg/c11-parm-omit-4.c
new file mode 100644
index 000..ea4cbfa9928
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/c11-parm-omit-4.c
@@ -0,0 +1,6 @@
+/* Test omitted parameter names not in C11: accepted by default in the
+   absence of -pedantic.  */
+/* { dg-do compile } */
+/* { dg-options "-std=c11" } */
+
+void f (int) { }
diff --git a/gcc/testsuite/gcc.dg/c2x-parm-omit-1.c 
b/gcc/testsuite/gcc.dg/c2x-parm-omit-1.c
new file mode 100644
index 000..0dc89bb0270
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/c2x-parm-omit-1.c
@@ -0,0 +1,5 @@
+/* Test omitted parameter names in C2x.  */
+/* { dg-do compile } */
+/* { dg-options "-std=c2x -pedantic-errors" } */
+
+void f (int) { }
diff --git a/gcc/testsuite/gcc.dg/c2x-parm-omit-2.c 
b/gcc/testsuite/gcc.dg/c2x-parm-omit-2.c
new file mode 100644
index 000..7d689332813
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/c2x-parm-omit-2.c
@@ -0,0 +1,10 @@
+/* Test omitted parameter names in C2x.  Warning test: there should be
+   no warning for an unnamed parameter being unused.  */
+/* { dg-do compile } */
+/* { dg-options "-std=c2x -pedantic-errors -Wall -Wextra" } */
+
+int
+f (int a, int, int c, int d) /* { dg-warning "unused parameter 'd'" } */
+{
+  return a + c;
+}
diff --git a/gcc/testsuite/gcc.dg/c2x-parm-omit-3.c 
b/gcc/testsuite/gcc.dg/c2x-parm-omit-3.c
new file mode 100644
index 000..dac258b0fb8
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/c2x-parm-omit-3.c
@@ -0,0 +1,23 @@
+/* Test omitted parameter names in C2x.  Execution test.  */
+/* { dg-do run } */
+/* { dg-options "-std=c2x -pedantic-errors" } */
+
+extern void abort (void);
+extern void exit (int);
+
+void
+f (int a, int [++a], int b)
+{
+  /* Verify array size expression of unnamed parameter is processed as
+ expected.  */
+  if (a != 2 || b != 3)
+ab

c: Allow duplicate C2x standard attributes

[Joseph Myers]

N2557, accepted into C2x at the October WG14 meeting, removes the
requirement that duplicates of standard attributes cannot appear
within an attribute list (so allowing e.g. [[deprecated, deprecated]],
where previously that was disallowed but [[deprecated]] [[deprecated]]
was OK).  Remove the code checking for this (standard attributes
aren't in any released version of the C standard) and update tests
accordingly.

Bootstrapped with no regressions on x86_64-pc-linux-gnu.  Applied to 
mainline.

gcc/c/
2020-10-27  Joseph Myers  

* c-parser.c (c_parser_std_attribute_specifier): Allow duplicate
standard attributes.

gcc/testsuite/
2020-10-27  Joseph Myers  

* gcc.dg/c2x-attr-deprecated-4.c, gcc.dg/c2x-attr-fallthrough-4.c,
gcc.dg/c2x-attr-maybe_unused-4.c: Allow duplicate attributes.

diff --git a/gcc/c/c-parser.c b/gcc/c/c-parser.c
index b6a7ef4c92b..d49e508ce6d 100644
--- a/gcc/c/c-parser.c
+++ b/gcc/c/c-parser.c
@@ -4977,9 +4977,6 @@ c_parser_std_attribute (c_parser *parser, bool for_tm)
 static tree
 c_parser_std_attribute_specifier (c_parser *parser, bool for_tm)
 {
-  bool seen_deprecated = false;
-  bool seen_fallthrough = false;
-  bool seen_maybe_unused = false;
   location_t loc = c_parser_peek_token (parser)->location;
   if (!c_parser_require (parser, CPP_OPEN_SQUARE, "expected %<[%>"))
 return NULL_TREE;
@@ -5005,55 +5002,8 @@ c_parser_std_attribute_specifier (c_parser *parser, bool 
for_tm)
   tree attribute = c_parser_std_attribute (parser, for_tm);
   if (attribute != error_mark_node)
{
- bool duplicate = false;
- tree name = get_attribute_name (attribute);
- tree ns = get_attribute_namespace (attribute);
- if (ns == NULL_TREE)
-   {
- /* Some standard attributes may appear at most once in
-each attribute list.  Diagnose duplicates and remove
-them from the list to avoid subsequent diagnostics
-such as the more general one for multiple
-"fallthrough" attributes in the same place (including
-in separate attribute lists in the same attribute
-specifier sequence, which is not a constraint
-violation).  */
- if (is_attribute_p ("deprecated", name))
-   {
- if (seen_deprecated)
-   {
- error ("attribute % can appear at most "
-"once in an attribute-list");
- duplicate = true;
-   }
- seen_deprecated = true;
-   }
- else if (is_attribute_p ("fallthrough", name))
-   {
- if (seen_fallthrough)
-   {
- error ("attribute % can appear at most "
-"once in an attribute-list");
- duplicate = true;
-   }
- seen_fallthrough = true;
-   }
- else if (is_attribute_p ("maybe_unused", name))
-   {
- if (seen_maybe_unused)
-   {
- error ("attribute % can appear at most "
-"once in an attribute-list");
- duplicate = true;
-   }
- seen_maybe_unused = true;
-   }
-   }
- if (!duplicate)
-   {
- TREE_CHAIN (attribute) = attributes;
- attributes = attribute;
-   }
+ TREE_CHAIN (attribute) = attributes;
+ attributes = attribute;
}
   if (c_parser_next_token_is_not (parser, CPP_COMMA))
break;
diff --git a/gcc/testsuite/gcc.dg/c2x-attr-deprecated-4.c 
b/gcc/testsuite/gcc.dg/c2x-attr-deprecated-4.c
index f1848a20cd5..7698434cc6d 100644
--- a/gcc/testsuite/gcc.dg/c2x-attr-deprecated-4.c
+++ b/gcc/testsuite/gcc.dg/c2x-attr-deprecated-4.c
@@ -1,13 +1,11 @@
-/* Test C2x deprecated attribute: duplicates.  */
+/* Test C2x deprecated attribute: duplicates (allowed after N2557).  */
 /* { dg-do compile } */
 /* { dg-options "-std=c2x -pedantic-errors" } */
 
-[[deprecated, __deprecated__]] int a; /* { dg-error "can appear at most once" 
} */
-[[__deprecated__, deprecated("message")]] int b; /* { dg-error "can appear at 
most once" } */
-int c [[deprecated("message"), deprecated]]; /* { dg-error "can appear at most 
once" } */
-[[deprecated, deprecated]]; /* { dg-error "can appear at most once" } */
+[[deprecated, __deprecated__]] int a;
+[[__deprecated__, deprecated("message")]] int b;
+int c [[deprecated("message"), deprecated]];
+[[deprecated, deprecated]];
 /* { dg-error "ignored" "ignored" { target *-*-

Re: *PING^4* [PATCH] doc: gcc.c: Update documentation for spec files

[Joseph Myers]

First, as a general principle I don't think it's really a good idea to 
have the documentation for specs duplicated in two places.  It would be 
better to have it in exactly one place, and so avoid having two copies 
getting out of sync in future.

I'd say that specs are an internal implementation detail, liable to change 
in future releases without worrying about backwards compatibility (beyond 
the basic cases such as the example of --with-specs given in 
install.texi), and so the user manual should only have a brief description 
and a reference to gcc.c for the details of what individual specs do, 
rather than listing the details of each individual spec.  That would mean 
making sure the comments in gcc.c give all the information currently in 
invoke.texi from "Here is a table of all defined @samp{%}-sequences" 
onwards, and then replacing that text in invoke.texi with a reference to 
gcc.c.  (I'm less sure about the earlier parts of the description of spec 
files in invoke.texi, but I think everything describing the individual 
spec characters and functions makes more sense in gcc.c.)

This patch says "The @code{sanitize} spec function takes no arguments.", 
but actually it appears to take one argument.

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

float.h: C2x NaN and Inf macros

[Joseph Myers]

C2x adds macros for NaNs and infinities to , some of them
previously in  (and some still in  as well in C2x as
an obsolescent feature).  Add these macros to GCC's 
implementation.

This omits the macros for DFP signaling NaNs, leaving those to be
added in a separate patch which will also need to add corresponding
built-in functions (GCC doesn't currently have built-in functions for
DFP signaling NaNs, only quiet ones).  However, it includes the
_FloatN / _FloatNx macros (conditional on
__STDC_WANT_IEC_60559_TYPES_EXT__) in the current draft version of the
integration of TS 18661-3 into C2x as an Annex.

As GCC allows duplicate macro definitions with different expansions in
system headers, it should be OK if  defines INFINITY or NAN
with a slightly different expansion (e.g. different choice of whether
there is whitespace between tokens); tests are added including
 and  in either order.  Because  uses #undef
on all macros before defining them, even with -Wsystem-headers there
could only ever be issues when  is included after .

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

gcc/
2020-10-27  Joseph Myers  

* ginclude/float.h (INFINITY, NAN, FLT_SNAN, DBL_SNAN, LDBL_SNAN)
(FLT16_SNAN, FLT32_SNAN, FLT64_SNAN, FLT128_SNAN, FLT32X_SNAN)
(FLT64X_SNAN, FLT128X_SNAN, DEC_INFINITY, DEC_NAN): New C2x
macros.
* doc/sourcebuild.texi (Effective-Target Keywords): Document inff.

gcc/testsuite/
2020-10-27  Joseph Myers  

* lib/target-supports.exp (check_effective_target_inff): New.
* gcc.dg/c11-float-4.c, gcc.dg/c11-float-5.c,
gcc.dg/c11-float-dfp-2.c, gcc.dg/c2x-float-2.c,
gcc.dg/c2x-float-3.c, gcc.dg/c2x-float-4.c, gcc.dg/c2x-float-5.c,
gcc.dg/c2x-float-6.c, gcc.dg/c2x-float-7.c, gcc.dg/c2x-float-8.c,
gcc.dg/c2x-float-9.c, gcc.dg/c2x-float-no-dfp-3.c,
gcc.dg/c2x-float-no-dfp-4.c, gcc.dg/dfp/c2x-float-dfp-4.c,
gcc.dg/dfp/c2x-float-dfp-5.c, gcc.dg/dfp/c2x-float-dfp-6.c,
gcc.dg/torture/float128-nan-floath.c,
gcc.dg/torture/float128x-nan-floath.c,
gcc.dg/torture/float16-nan-floath.c,
gcc.dg/torture/float32-nan-floath.c,
gcc.dg/torture/float32x-nan-floath.c,
gcc.dg/torture/float64-nan-floath.c,
gcc.dg/torture/float64x-nan-floath.c,
gcc.dg/torture/floatn-nan-floath.h: New tests.

diff --git a/gcc/doc/sourcebuild.texi b/gcc/doc/sourcebuild.texi
index 49316a5d0ff..726f1c96dab 100644
--- a/gcc/doc/sourcebuild.texi
+++ b/gcc/doc/sourcebuild.texi
@@ -1443,6 +1443,10 @@ Target has runtime support for any options added with
 @item inf
 Target supports floating point infinite (@code{inf}) for type
 @code{double}.
+
+@item inff
+Target supports floating point infinite (@code{inf}) for type
+@code{float}.
 @end table
 @subsubsection Fortran-specific attributes
 
diff --git a/gcc/ginclude/float.h b/gcc/ginclude/float.h
index 9c4b0385568..77446995515 100644
--- a/gcc/ginclude/float.h
+++ b/gcc/ginclude/float.h
@@ -248,6 +248,32 @@ see the files COPYING3 and COPYING.RUNTIME respectively.  
If not, see
 #define DBL_NORM_MAX   __DBL_NORM_MAX__
 #define LDBL_NORM_MAX  __LDBL_NORM_MAX__
 
+/* Infinity in type float, or overflow if infinity not supported.  */
+#undef INFINITY
+#define INFINITY   (__builtin_inff ())
+
+/* Quiet NaN, if supported for float.  */
+#if __FLT_HAS_QUIET_NAN__
+#undef NAN
+#define NAN(__builtin_nanf (""))
+#endif
+
+/* Signaling NaN, if supported for each type.  All formats supported
+   by GCC support either both quiet and signaling NaNs, or neither
+   kind of NaN.  */
+#if __FLT_HAS_QUIET_NAN__
+#undef FLT_SNAN
+#define FLT_SNAN   (__builtin_nansf (""))
+#endif
+#if __DBL_HAS_QUIET_NAN__
+#undef DBL_SNAN
+#define DBL_SNAN   (__builtin_nans (""))
+#endif
+#if __LDBL_HAS_QUIET_NAN__
+#undef LDBL_SNAN
+#define LDBL_SNAN  (__builtin_nansl (""))
+#endif
+
 #endif /* C2X */
 
 #ifdef __STDC_WANT_IEC_60559_BFP_EXT__
@@ -284,6 +310,10 @@ see the files COPYING3 and COPYING.RUNTIME respectively.  
If not, see
 #define FLT16_DECIMAL_DIG  __FLT16_DECIMAL_DIG__
 #undef FLT16_TRUE_MIN
 #define FLT16_TRUE_MIN __FLT16_DENORM_MIN__
+#if defined __STDC_VERSION__ && __STDC_VERSION__ > 201710L
+#undef FLT16_SNAN
+#define FLT16_SNAN (__builtin_nansf16 (""))
+#endif /* C2X */
 #endif /* __FLT16_MANT_DIG__.  */
 
 #ifdef __FLT32_MANT_DIG__
@@ -309,6 +339,10 @@ see the files COPYING3 and COPYING.RUNTIME respectively.  
If not, see
 #define FLT32_DECIMAL_DIG  __FLT32_DECIMAL_DIG__
 #undef FLT32_TRUE_MIN
 #define FLT32_TRUE_MIN __FLT32_DENORM_MIN__
+#if defined __STDC_VERSION__ && __STDC_VERSION__ > 201710L
+#undef FLT32_SNAN
+#define FLT32_SNAN (__builtin_nansf32 (""))
+#endif /* C2X */
 #endif /* __FLT32_MANT_DIG__.  */
 
 #ifdef __FLT64_MANT_DIG__
@@ -334,6 +368,10 @@ see the files C

Re: Fix fnspecs for math builtins

[Joseph Myers]

On Mon, 26 Oct 2020, Jan Hubicka wrote:

> Hi,
> this patch makes us to use ".C" and ".P" fnspecs where
> applicable.  I also noticed that gamma and variants are
> declared as storing to memory while they are not (gamma_r does)

I think the point is that they store to the global signgam.

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

Re: [patch] Add an if-exists-then-else spec function

[Joseph Myers]

This is OK.

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

Re: [PATCH v3] c, c++: Implement -Wsizeof-array-div [PR91741]

[Joseph Myers]

The C parts are OK.

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

Re: Patch ping

[Joseph Myers]

On Thu, 22 Oct 2020, Jakub Jelinek via Gcc-patches wrote:

> https://gcc.gnu.org/pipermail/gcc-patches/2020-September/554804.html
>   - PR97164 - reject forming arrays with elt sizes not divisible by elt 
> alignment

OK.

> https://gcc.gnu.org/pipermail/gcc-patches/2020-October/556153.html
>   - fix up plugin header install

OK.

The other patches need a self-contained submission showing the proposed 
commit message for that version of the patch, not just a discussion from 
the middle of a thread that can't be understood on its own without going 
through the rest of the discussion (and possibly previous patch versions) 
and doesn't say what form of explanation is proposed as a commit message.

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

Re: [RFC] Automatic linking of libatomic via gcc.c or ...? [PR81358] (dependency for libgomp on nvptx dep, configure overriddable, ...)

[Joseph Myers]

On Thu, 15 Oct 2020, Tobias Burnus wrote:

> Hi Joseph, hi Jakub,
> 
> (a) For the driver route:
> 
> On 10/15/20 12:22 AM, Joseph Myers wrote:
> > I think it should be somewhere in the expansion of %(link_gcc_c_sequence)
> > (i.e. LINK_GCC_C_SEQUENCE_SPEC, which has various target-specific
> > definitions), since that's what expands to something like -lgcc -lc -lgcc.
> > Maybe after the first -lgcc and before the -lc, since libatomic has
> > references to libc functions.
> 
> Lightly tested draft patch attached. (--enable-autolink-libatomic is 'no' by
> default)

I think the configure option should be on by default.

I'd expect only gcc.c to define LINK_LIBATOMIC_SPEC rather than 
duplicating it in gnu-user.h.

I'd expect either a default definition of LINK_LIBATOMIC_SPEC to "" when 
the configure option is disabled, or else conditionals in the macros that 
use LINK_LIBATOMIC_SPEC to avoid them using an undefined macro.

> When trying the patch, one runs into the problem that -latomic
> fails in the target configure for libgomp ("error: C compiler
> cannot create executables"). Any suggestion? (That's on x86_64-gnu-linux.)

Yes, making this change means you need to ensure the build of target 
libraries and testcases can find the in-build-tree libatomic (and that 
tests can find it at runtime as needed in the shared library case), just 
like it already needs to be able to find the in-build-tree libgcc.

In the case of libgcc, the libgcc build process copies the libraries into 
the host-side gcc/ object directory.  Maybe doing that for libatomic would 
be simpler than teaching lots of separate places how to find libatomic in 
the build tree (though for any tests that might use shared libatomic at 
runtime, it's still necessary to ensure that works for testing GCC).

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

Re: [RFC] Automatic linking of libatomic via gcc.c or ...? [PR81358] (dependency for libgomp on nvptx dep, configure overriddable, ...)

[Joseph Myers]

On Wed, 14 Oct 2020, Tobias Burnus wrote:

> Question: Where do you think should it be in the driver?

I think it should be somewhere in the expansion of %(link_gcc_c_sequence) 
(i.e. LINK_GCC_C_SEQUENCE_SPEC, which has various target-specific 
definitions), since that's what expands to something like -lgcc -lc -lgcc.  
Maybe after the first -lgcc and before the -lc, since libatomic has 
references to libc functions.

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

Re: [ Preprocessor ] [ Common ] Feature: Macros for identifying the wide and narrow execution string literal encoding

[Joseph Myers]

On Thu, 8 Oct 2020, JeanHeyd Meneide via Gcc-patches wrote:

> * gcc/doc/cpp.texi: Document new predefined macro.

This documentation doesn't seem sufficient to use the macros.  Do they 
expand to (narrow) string literals?  To an unquoted sequence of 
characters?  I think from the implementation that the answer is strings 
(so, in particular, not usable for testing anything in #if conditionals), 
but the documentation ought to say so.  The test ought to verify the form 
of the expansion as well (even if it can't do anything useful at execution 
time, because if you make the macros reflect the command-line options they 
are character set names that are meaningful on the host, and any 
conversion functionality on the target may not use the same names as the 
host).

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

Re: [r11-3641 Regression] FAIL: gcc.dg/torture/pta-ptrarith-1.c -Os scan-tree-dump alias "ESCAPED = {[^\n}]* i f [^\n}]*}" on Linux/x86_64 (-m32 -march=cascadelake)

[Joseph Myers]

On Sun, 4 Oct 2020, H.J. Lu via Gcc-patches wrote:

> This email is generated by an automated script.  Does GCC BZ have
> an email gateway?

Bugzilla has a REST API that you can use to interact with it via JSON 
messages over HTTP.  contrib/mark_spam.py has an example to mark bugs as 
spam.  glibc's scripts/list-fixed-bugs.py has an example extracting bug 
data for bugs matching a given search.  There are lots of other things you 
can do with that API, including filing new bugs.  (You probably want to 
make sure you e.g. only file one bug for a commit, not 1000 bugs for a 
commit that introduces 1000 test failures.)

https://bugzilla.readthedocs.io/en/latest/api/

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

Re: [Patch] libgomp: Add, if existing, -latomic to libgomp.spec --as-needed (was: Re: [RFC] Offloading and automatic linking of libraries)

[Joseph Myers]

On Fri, 2 Oct 2020, Tobias Burnus wrote:

> However, this flag can be added into the offload-target's libgomp.spec,
> which avoids all kind of issues. That's what this patch now does.
> 
> I tested it with x86_64-gnu-linux w/o + w/ nvptx-none. Result:
> * x86_64-gnu-linux's libgomp.spec:
>   "*link_gomp: -lgomp %{static: -ldl } --as-needed -latomic --no-as-needed"
> * nvptx-none's libgomp.spec:
>   "*link_gomp: -lgomp  -latomic"
> 
> On x86-64, a simple test program did not use and also did not link libatomic.
> 
> OK?

Do all testsuites that link using libgomp.spec also use the testsuite 
logic from atomic-dg.exp to locate libatomic for build-tree testing 
(otherwise -latomic will fail if it can't be found and there isn't an 
installed system copy that the driver might fall back on, even with 
--as-needed)?

My view as noted in bug 81358 is that --as-needed -latomic --no-as-needed 
should *always* be used (given --as-needed supported and libatomic built), 
not restricted to when libgomp is needed.  But while adding it only for 
libgomp might make a useful improvement while reducing the extent to which 
global testsuite / configure test changes need to be made at the same 
time, some testsuite support should still be needed if not already in use.

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

Re: [PATCH 1/9] PowerPC: Map long double built-in functions if IEEE 128-bit long double.

[Joseph Myers]

On Thu, 24 Sep 2020, Michael Meissner via Gcc-patches wrote:

> To map the math functions, typically this patch changes l to f128.
> However there are some exceptions that are handled with this patch.

glibc 2.32 added __*ieee128 names for the *f128 functions, to allow the 
long double functions to be called in a namespace-clean way (when the 
defined feature test macros do not enable the TS 18661-3 function names). 
So I think GCC should also prefer to map to those names where possible, 
rather than the *f128 names.

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

Re: [RFC] Offloading and automatic linking of libraries

[Joseph Myers]

On Thu, 24 Sep 2020, Tobias Burnus wrote:

> Hi all,
> 
> we got the user comment that it is far from obvious to
> use  -foffload=-latomic if the following error shows up:
> 
> unresolved symbol __atomic_compare_exchange_16
> collect2: error: ld returned 1 exit status
> mkoffload: fatal error: /powerpc64le-none-linux-gnu-accel-nvptx-none-gcc
> returned 1 exit status
> 
> In principle, the same issue pops up with -lm and -lgfortran,
> which on the host are automatically linked for g++ (-lm) and
> for gfortran (both) but not gcc.

As discussed in bug 81358, I think --as-needed -latomic --no-as-needed 
should be used by the driver by default (when the compiler is configured 
with libatomic supported).  The same ought to apply for the offloading 
libatomic as well: it should be linked in automatically when needed.

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

Re: [PATCH V2 0/4] Unify C and C++ handling of loops and switches

[Joseph Myers]

On Thu, 17 Sep 2020, Jason Merrill via Gcc-patches wrote:

> The C++ changes are OK.  A C maintainer will need to sign off on the changes
> there.

The C front-end changes are OK.

Note: for a long time there used to be actual (undesired) semantic 
differences between the C and C++ loop handling, but that was fixed with a 
testcase added (see bug 44715), so I'm not expecting this patch to change 
C semantics at all.

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

Re: [PING 2][PATCH 2/5] C front end support to detect out-of-bounds accesses to array parameters

[Joseph Myers]

On Wed, 16 Sep 2020, Martin Sebor via Gcc-patches wrote:

> Attached is an updated revision of the patch.  Besides the tweaks
> above it also contains a cosmetic change to the warning issued
> for mismatches in unspecified VLA bounds: it points at the decl
> with more of them to guide the user to specify them rather than
> make them all unspecified.

The previous version of the patch had a while loop as previously discussed 
to handle skipping multiple consecutive cdk_attrs.

+  next = pd->declarator;
+  while (next && next->kind == cdk_attrs)
+   next = next->declarator;

This version is back to an "if", but I don't see anything else in the new 
version of that function that actually means the "if" would skip multiple 
consecutive cdk_attrs as desired.

The patch is OK with the "while" restored there.  If for some reason the 
"while" breaks something, we'll need to look in more detail at exactly 
what case isn't being handled correctly by "while".

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

Re: [patch] Fix dangling references in thunks at -O0

[Joseph Myers]

This introduces an ICE building the glibc testsuite for alpha (bisected), 
s390 and sparc (symptoms appear the same, not bisected to confirm the 
exact revision).  See bug 97078.

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

Re: Problem with static const objects and LTO

[Joseph Myers]

On Wed, 16 Sep 2020, Jeff Law via Gcc-patches wrote:

> ISTM this is a lot like the problem we have where we inline functions
> with static data.   To fix those we use STB_GNU_UNIQUE.  But I don't see
> any code in the C front-end which would utilize STB_GNU_UNIQUE.  It's
> support seems limited to C++.
> 
> 
> How is this supposed to work for C?

C inline functions don't try to address this.  The standard has a rule "An 
inline definition of a function with external linkage shall not contain a 
definition of a modifiable object with static or thread storage duration, 
and shall not contain a reference to an identifier with internal 
linkage.", which avoids some cases of this, but you can still get multiple 
copies of objects (with static storage duration, not modifiable, no 
linkage, i.e. static const defined inside an inline function) as noted in 
a footnote "Since an inline definition is distinct from the corresponding 
external definition and from any other corresponding inline definitions in 
other translation units, all corresponding objects with static storage 
duration are also distinct in each of the definitions.".

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

Re: [PING][PATCH] improve validation of attribute arguments (PR c/78666)

[Joseph Myers]

On Wed, 9 Sep 2020, Martin Sebor via Gcc-patches wrote:

> Ping: https://gcc.gnu.org/pipermail/gcc-patches/2020-August/552500.html
> 
> Aldy provided a bunch of comments on this patch but I'm still looking
> for a formal approval.

This patch is OK.

> > Some testing revealed that the code has different semantics for
> > strings: it compares them including all nuls embedded in them,
> > while I think the right semantics for attributes is to only consider
> > strings up and including the first nul (i.e., apply the usual string
> > semantics).  A test case for this corner case is as follows:
> > 
> >    __attribute__ ((section ("foo\0bar"))) void f (void);
> >    __attribute__ ((section ("foo"))) void f (void) { }
> > 
> > Without operand_equal_p() GCC accepts this and puts f in section
> > foo.  With the operand_equal_p() change above, it complains:
> > 
> > ignoring attribute ‘section ("foo\x00bar")’ because it conflicts with
> > previous ‘section ("foor")’ [-Wattributes]
> > 
> > I would rather not change the behavior in this corner case just to
> > save a few lines of code.  If it's thought that string arguments
> > to attributes (some or all) should be interpreted differently than
> > in other contexts it seems that such a change should be made
> > separately and documented in the manual.

I think that for at least the section attribute, embedded NULs are 
suspect.  In that case, so are wide strings, but for some attributes wide 
strings should be accepted and handled sensibly (but aren't, see bug 
91182).

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

Re: [PING 2][PATCH 2/5] C front end support to detect out-of-bounds accesses to array parameters

[Joseph Myers]

On Wed, 9 Sep 2020, Martin Sebor via Gcc-patches wrote:

> Joseph, do you have any concerns with or comments on the most
> recent patch or is it okay as is?
> 
> https://gcc.gnu.org/pipermail/gcc-patches/2020-August/552266.html

I'm not yet convinced by the logic for extracting an array bound from a 
parameter declared using a typedef for an array type.

Say you have

typedef int A[3];

void f (A *x[*]);

so an argument that is an array, using [*], of pointers to arrays, where 
those latter arrays are specified using the typedef.  As I read the logic, 
first the pointer declarator is handled (ignored), then the array 
declarator results in [*] being stored in spec, then the "if (pd->kind == 
cdk_id)" handling comes into play - and because spec is "*" and vbchain is 
NULL_TREE, the upper bound of A gets extracted, but the upper bound of A 
should be irrelevant here because it's a type that's the target of a 
pointer.  The information from parm->specs->type logically comes before, 
not after, the information from the declarator.

As far as I can see, if one declaration gets part of the parameter type 
(involving VLAs) from a typedef and another declaration gets that part of 
the type directly in the declaration, the two spec strings constructed 
might differ in the number of VLA bounds mentioned in the spec strings.  
Is the code using those strings robust to handling the case where some of 
the VLA bounds are missing because they came from a typedef?

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

Re: [PATCH] c, c++: Implement -Wsizeof-array-div [PR91741]

[Joseph Myers]

On Mon, 14 Sep 2020, Marek Polacek via Gcc-patches wrote:

> so I followed suit.  In the C++ FE this was rather easy, because
> finish_parenthesized_expr already set TREE_NO_WARNING.  In the C FE
> it was trickier; I've added a NOP_EXPR to discern between the non-()
> and () versions.

This sort of thing is normally handled for C via original_code in c_expr.  
I suppose that doesn't work in this case because the code dealing with 
parenthesized expressions has a special case for sizeof:

  if (expr.original_code != C_MAYBE_CONST_EXPR
  && expr.original_code != SIZEOF_EXPR)
expr.original_code = ERROR_MARK;

Handling this in some way via c_expr seems better to me than generating 
NOP_EXPR.  I suppose you could invent a PAREN_SIZEOF_EXPR used by (sizeof 
foo) and ((sizeof foo)) etc. as an original_code setting (and handled the 
same as SIZEOF_EXPR by whatever other warnings look for SIZEOF_EXPR 
there), or else add fields to c_expr to allow more such information to be 
tracked there.

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

Re: [PATCH] mixing of labels and code in C2X

[Joseph Myers]

On Sun, 13 Sep 2020, Uecker, Martin wrote:

> Hi Joseph,
> 
> here is the (unfinished) patch to support
> mixing of labels in C2X.

I think there should be explicit tests for old standard versions 
(c11-labels-1.c etc.) that these usages are errors with -pedantic-errors 
with the old -std option, are warnings with -pedantic, and are quietly 
accepted with neither.  In addition to using -pedantic-errors with the new 
standard version test to confirm it's not diagnosed, and a test with the 
new version and -Wc11-c2x-compat.

By way of example of further places that I think need changing in the 
patch: at present, c_parser_label gives an error (that you correctly 
change to a pedwarn_c11) if the label is followed by a declaration - and 
then parses the declaration itself rather than leaving it to be parsed in 
the caller.  So c_parser_compound_statement_nostart would parse a label 
followed by a declaration, and at that point last_label would be set to 
true, meaning that a second declaration would be rejected, when in C2x it 
should be accepted.  You can see this even without the patch with a test 
such as:

void
f (void)
{
 label : int a; int b; 
}

I think that instead c_parser_label should never try to parse a 
declaration following the label; that should be left for the caller to 
handle.  To avoid c_parser_label needing to return information about 
standard attributes on a following declaration, maybe it shouldn't parse 
standard attributes either (note that means that c_parser_all_labels would 
need to handle parsing and warning about and discarding standard 
attributes after each label instead - such attributes might be ones on a 
statement, or ones on the next label in a sequence of labels).

Then of course the checks of last_label in 
c_parser_compound_statement_nostart would need to become checks for 
whether to pedwarn_c11 about the use of a label in a given context, once 
the code knows whether there is a declaration, rather than preventing 
parsing a declaration there at all.  So probably c_parser_label would no 
longer have the pedwarn_c11 either; that would all be left to its callers.

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

Re: gcc git hook

[Joseph Myers]

On Thu, 10 Sep 2020, Nathan Sidwell wrote:

> Is it possible for the git hooks to reject pushes with overly-long subject
> lines?
> 
> I occasionally see pushes that forgot to add a separate title line, and so the
> whole of the commit description gets used.

Is that where the whole description is a single long unwrapped line?  
(The case of no blank line after the first line - a message starting with 
a multi-line paragraph - should already be diagnosed.)

We've disabled the check on lengths of lines in commit messages:

# We do not want to force a maximum line length in commit
# revision logs, as they get in the way of copy-pasting
# debugging session, error messages, logs, etc.
max-rh-line-length = 0

But we could add a local check in our commit_checker script for just the 
length of the first line (alongside the checks for a first line that looks 
like a ChangeLog header or is just a single word).

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

Re: [PATCH v1] [include] Add codes for DWARF v5 .dwp sections to dwarf2.h

[Joseph Myers]

On Wed, 9 Sep 2020, Caroline Tice via Gcc-patches wrote:

> For DWARF v5 Dwarf Package Files (.dwp files), the section identifier
> encodings have changed. This patch updates dwarf2.h to contain the new
> encodings.  (see http://dwarfstd.org/doc/DWARF5.pdf, section 7.3.5).
> 
> This patch has already been committed in binutils, but it needs to go into GCC
> as well to avoid the binutils patch being overwritten/lost.
> 
> I tested this by running the regression testsuite; there were no regressions.
> 
> Is this ok to commit?

In my view, anyone with write access should feel free to merge changes to 
shared files from the binutils-gdb tree at any time, without needing 
separate approval.

The only exception would be if there is deliberate divergence.  The only 
case I know of for deliberate divergence is to allow autotools versions to 
be updated separately in the two trees, since even updating one tree is 
quite involved (the last time that happened, it was a while between when 
Simon did the update in binutils-gdb and when I did the corresponding 
update for GCC; between the updates, care was needed about merging changes 
to auto*-related files).

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

RE: [PING] floatformat.h: Add bfloat16 support.

[Joseph Myers]

On Tue, 8 Sep 2020, Willgerodt, Felix via Gcc-patches wrote:

> Thanks for your review. It seems like the format issue was introduced by 
> my email client when hitting reply. Sorry for that! The original patch 
> is formatted correctly, as I used git send-email: 
> https://gcc.gnu.org/pipermail/gcc-patches/2020-August/552079.html
> 
> Could you double-check and push the patch for me? This is the first time 
> I contribute to gcc and I therefore don't have write access.

I've now pushed this patch.

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

Re: [PING] floatformat.h: Add bfloat16 support.

[Joseph Myers]

On Mon, 7 Sep 2020, Willgerodt, Felix via Gcc-patches wrote:

> @@ -133,6 +133,9 @@ extern const struct floatformat 
> floatformat_ia64_quad_little;
>  /* IBM long double (double+double).  */  extern const struct floatformat 
> floatformat_ibm_long_double_big;  extern const struct floatformat 
> floatformat_ibm_long_double_little;
> +/* bfloat16.  */
> +extern const struct floatformat floatformat_bfloat16_big; extern const 
> +struct floatformat floatformat_bfloat16_little;

There seems to be something odd about the diff formatting here.  I'd 
expect each declaration to be on its own line, not "extern const" at the 
end of a line and the rest of a declaration on the next line.  OK with 
that fixed.

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

Re: [PATCH] separate reading past the end from -Wstringop-overflow

[Joseph Myers]

On Tue, 1 Sep 2020, Jeff Law via Gcc-patches wrote:

> > With this commit:
> > https://gcc.gnu.org/pipermail/gcc-patches/2020-September/553109.html
> > the remaining failures should now be gone.  Please let me know if
> > any persist.
> There's a related glibc build failure, but I think Joseph ack'd a fix for it
> today.

Note I'm not sure if Maciej will be committing that fix soon or not.

There is also at least one glibc testsuite build failure that appears on 
those architectures where the glibc build didn't fail.

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

Re: [PATCH] avoid erroneous argument types when checking built-in signatures (PR c/96596)

[Joseph Myers]

On Thu, 27 Aug 2020, Martin Sebor via Gcc-patches wrote:

> The attached change has match_builtin_function_types() fail
> for erroneous argument types to prevent an ICE due to assuming
> they are necessarily valid.

OK.

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

Re: [PATCH 4/6] Add `+' for Jobserver Integration

[Joseph Myers]

On Thu, 20 Aug 2020, Giuliano Belinassi via Gcc-patches wrote:

>  libbacktrace/Makefile.in |   2 +-
>  zlib/Makefile.in |  64 ++--

These directories use makefiles generated by automake.  Rather than 
modifying the generated files, you need to modify the sources (whether 
that's Makefile.am, or code in automake itself - if in automake itself, we 
should wait for an actual new automake release before updating the version 
used in GCC).

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

Re: [PATCH] libgccjit: Fix several memory leaks in the driver

[Joseph Myers]

On Thu, 9 Jul 2020, Alex Coplan wrote:

> 2020-07-09  Alex Coplan  
> 
>   * gcc.c (set_static_spec): New.
>   (set_static_spec_owned): New.
>   (set_static_spec_shared): New.
>   (driver::maybe_putenv_COLLECT_LTO_WRAPPER): Use
>   set_static_spec_owned() to take ownership of lto_wrapper_file
>   such that it gets freed in driver::finalize.
>   (driver::maybe_run_linker): Use set_static_spec_shared() to
>   ensure that we don't try and free() the static string "ld",
>   also ensuring that any previously-allocated string in
>   linker_name_spec is freed. Likewise with argv0.
>   (driver::finalize): Use set_static_spec_shared() when resetting
>   specs that previously had allocated strings; remove if(0)
>   around call to free().

OK with a comment added to set_static_spec, documenting the semantics of 
the function and its arguments.

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

Re: [Patch] configure: Also check C++11 (flags) for ${build} compiler not only for ${host}

[Joseph Myers]

On Thu, 20 Aug 2020, Tobias Burnus wrote:

> Thanks for the first review; new version attached.

Thanks, this version is OK for GCC (but the GCC version will need updating 
if autoconf-archive ends up with a different version of these changes).

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

Re: [Patch] configure: Also check C++11 (flags) for ${build} compiler not only for ${host}

[Joseph Myers]

On Thu, 13 Aug 2020, Tobias Burnus wrote:

> diff --git a/config/ax_cxx_compile_stdcxx.m4 b/config/ax_cxx_compile_stdcxx.m4
> index 9413da624d2..0cd515fc65b 100644
> --- a/config/ax_cxx_compile_stdcxx.m4
> +++ b/config/ax_cxx_compile_stdcxx.m4
> @@ -25,6 +25,10 @@
>  #   regardless, after defining HAVE_CXX${VERSION} if and only if a
>  #   supporting mode is found.
>  #
> +#   If the fourth argument is the CXX/CXXFLAG/CPPFLAG suffix, e.g.
> +#   "_FOR_BUILD".

It appears you're requiring _FOR_BUILD here and considering other suffixes 
invalid, which would prevent any other use, e.g. _FOR_TARGET.

When building GCC, _FOR_TARGET is of course irrelevant because the 
top-level build support in the source tree is only intended to work with 
the version of GCC in that source tree so can assume what language 
features it supports.  It's less clear that no other suffix will ever be 
relevant elsewhere, given that this is autoconf-archive code rather than 
just used by GCC.

> +  m4_if([$4], [], [],
> +[$4], [_FOR_BUILD], [],
> +[m4_fatal([invalid fourth argument `$4' to 
> AX_CXX_COMPILE_STDCXX])])dnl

So I'm not convinced this check that the suffix should be empty or 
_FOR_BUILD is a good idea.

> +  m4_if([$4], [_FOR_BUILD],
> +[ax_cv_cxx_compile_cxx$1_orig_cxx="$CXX"
> + ax_cv_cxx_compile_cxx$1_orig_cxxflags="$CXXFLAGS"
> + ax_cv_cxx_compile_cxx$1_orig_cppflags="$CPPFLAGS"
> + CXX="$CXX$4"
> + CXXFLAGS="$CXXFLAGS$4"
> + CPPFLAGS="$CPPFLAGS$4"])

And then it might be better for this to be a check for the suffix not 
being empty, rather than it being exactly _FOR_BUILD (even if you keep the 
check that other suffixes are invalid, cutting down the number of places 
hardcoding _FOR_BUILD seems a good idea).

>m4_if([$2], [], [dnl
>  AC_CACHE_CHECK(whether $CXX supports C++$1 features by default,
> -ax_cv_cxx_compile_cxx$1,
> +ax_cv_cxx_compile_cxx$1$4,
>
> [AC_COMPILE_IFELSE([AC_LANG_SOURCE([_AX_CXX_COMPILE_STDCXX_testbody_$1])],
>  [ax_cv_cxx_compile_cxx$1=yes],
>  [ax_cv_cxx_compile_cxx$1=no])])

I think this needs to update the variable name in the assignments of the 
result of the check, and then in the subsequent check for whether to set 
ac_success=yes, not just in the second argument to AC_CACHE_CHECK.

> +  m4_if([$4], [_FOR_BUILD],
> +[CXX$4="$CXX"
> + CXXFLAGS$4="$CXXFLAGS"
> + CPPFLAGS$4="$CPPFLAGS"
> + CXX="$ax_cv_cxx_compile_cxx$1_orig_cxx"
> + CXXFLAGS="$ax_cv_cxx_compile_cxx$1_orig_cxxflags"
> + CPPFLAGS="$ax_cv_cxx_compile_cxx$1_orig_cppflags"])

I think this also would be better checking for $4 not being empty rather 
than for it being exactly _FOR_BUILD.

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

Re: [PATCH 2/5] C front end support to detect out-of-bounds accesses to array parameters

[Joseph Myers]

On Wed, 19 Aug 2020, Martin Sebor via Gcc-patches wrote:

> > I think you need a while loop there, not just an if, to account for the
> > case of multiple consecutive cdk_attrs.  At least the GNU attribute syntax
> > 
> > direct-declarator:
> > [...]
> >   ( gnu-attributes[opt] declarator )
> > 
> > should produce multiple consecutive cdk_attrs for each level of
> > parentheses with attributes inside.
> 
> I had considered a loop but couldn't find a way to trigger what you
> describe (or a test in the testsuite that would do it) so I didn't
> use one.  I saw loops like that in other places but I couldn't get
> even those to uncover such a test case.  Here's what I tried:
> 
>   #define A(N) __attribute__ ((aligned (N), may_alias))
>   int n;
>   void f (int (* A (2) A (4) (* A (2) A (4) (* A (2) A (4) [n])[n])));
> 
> Sequences of consecutive attributes are all chained together.
> 
> I've added the loop here but I have no test for it.  It would be
> good to add one if it really is needed.

The sort of thing I'm thinking of would be, where A is some attribute:

void f (int (A (A (A arg;

(that example doesn't involve an array, but it illustrates the syntax I'd 
expect to produce multiple consecutive cdk_attrs).

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

Re: [PATCH] middle-end: Fix PR middle-end/85811: Introduce tree_expr_maybe_nan_p et al.

[Joseph Myers]

On Mon, 17 Aug 2020, Segher Boessenkool wrote:

> Ah, so "When both arguments are NaNs, the return value should be a qNaN"
> means the QNaN corresponding to eother x or y.  I see, thanks!

Yes.  (The precise choice of NaN result given a NaN input is the subject 
of various "should"s, in 6.2.3 NaN propagation, with the choice between 
multiple input NaNs to provide the payload unspecified.  E.g. RISC-V 
doesn't propagate NaN payloads at all.  On x86, the rules for choosing a 
NaN result with more than one NaN input are different between x87 and SSE 
arithmetic.  The compiler can ignore these issues, as long as it gets the 
choice between quiet and signaling NaN correct.)

The IEEE 754-2008 min/max operations also do not specify the precise 
choice of result when the arguments are +0 and -0 in some order, or when 
they are equal decimal floating-point values with different quantum 
exponent.  The new operations in IEEE 754-2019 treat -0 as less than +0, 
but still leave the quantum exponent case unspecified.

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

Re: [PATCH] middle-end: Fix PR middle-end/85811: Introduce tree_expr_maybe_nan_p et al.

[Joseph Myers]

On Sat, 15 Aug 2020, Segher Boessenkool wrote:

> Hi!
> 
> On Sat, Aug 15, 2020 at 12:10:42PM +0100, Roger Sayle wrote:
> > I'll quote Joseph Myers (many thanks) who describes things clearly as:
> > > (a) When both arguments are NaNs, the return value should be a qNaN,
> > > but sometimes it is an sNaN if at least one argument is an sNaN.
> 
> Where is this defined?  I can't find it in C11, in 18661, and of course
> it isn't what GCC does (it requires -fsignaling to even acknowledge the
> existence of signaling NaNs :-) )

The semantics of fmax and fmin are those of the maxNum and minNum 
operations in IEEE 754-2008 (that were removed in IEEE 754-2019); see the 
table of IEEE operation bindings that 18661-1 adds to Annex F.

  minNum(x, y) is the canonicalized number x if x < y, y if y < x, the 
  canonicalized number if one operand is a number and the other a quiet 
  NaN. Otherwise it is either x or y, canonicalized (this means results 
  might differ among implementations). When either x or y is a 
  signalingNaN, then the result is according to 6.2.

  maxNum(x, y) is the canonicalized number y if x < y, x if y < x, the 
  canonicalized number if one operand is a number and the other a quiet 
  NaN. Otherwise it is either x or y, canonicalized (this means results 
  might differ among implementations). When either x or y is a 
  signalingNaN, then the result is according to 6.2.

where the relevant wording from 6.2 is

  Under default exception handling, any operation signaling an invalid 
  operation exception and for which a floating-point result is to be 
  delivered shall deliver a quiet NaN.

  Signaling NaNs shall be reserved operands that, under default exception 
  handling, signal the invalid operation exception (see 7.2) for every 
  general-computational and signaling-computational operation except for 
  the conversions described in 5.12. For non-default treatment, see 8.

(and maxNum and minNum are in 5.3 "Homogeneous general-computational 
operations").

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

Re: [PATCH] c: Fix -Wunused-but-set-* warning with _Generic [PR96571]

[Joseph Myers]

On Fri, 14 Aug 2020, Jakub Jelinek via Gcc-patches wrote:

> Hi!
> 
> The following testcase shows various problems with -Wunused-but-set*
> warnings and _Generic construct.  I think it is best to treat the selector
> and the ignored expressions as (potentially) read, because when they are
> parsed, the vars in there are already marked as TREE_USED.
> 
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

OK.

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

Re: [PATCH 2/5] C front end support to detect out-of-bounds accesses to array parameters

[Joseph Myers]

On Thu, 13 Aug 2020, Martin Sebor via Gcc-patches wrote:

> > * Maybe cdk_pointer is followed by cdk_attrs before cdk_id.  In this case
> > the code won't return.
> 
> I think I see the problem you're pointing out (I just don't see how
> to trigger it or test that it doesn't happen).  If the tweak in
> the attached update doesn't fix it a test case would be helpful.

I think you need a while loop there, not just an if, to account for the 
case of multiple consecutive cdk_attrs.  At least the GNU attribute syntax

   direct-declarator:
[...]
 ( gnu-attributes[opt] declarator )

should produce multiple consecutive cdk_attrs for each level of 
parentheses with attributes inside.

> > * Maybe the code is correct to continue because we're in the case of an
> > array of pointers (cdk_array follows).  But as I understand it, the intent
> > is to set up an "arg spec" that describes only the (multidimensional)
> > array that is the parameter itself - not any array pointed to.  And it
> > looks to me like, in the case of an array of pointers to arrays, both sets
> > of array bounds would end up in the spec constructed.
> 
> Ideally, I'd like to check even pointers to arrays and so they should
> be recorded somewhere.  The middle end code doesn't do any checking
> of those yet for out-of-bounds accesses.  It wasn't a goal for
> the first iteration so I've tweaked the code to avoid recording them.

Could you expand the comment on get_parm_array_spec to specify exactly 
what you think the function should be putting in the returned attribute, 
in what order, in cases where there are array declarators (constant, 
empty, [*] and VLA) intermixed with other kinds of declarators and the 
type from the type specifiers may or may not be an array type itself?  
That will provide a basis for subsequent rounds of review of whether the 
function is actually behaving as expected.

As far as I can see, the logic

+  if (TREE_CODE (nelts) == INTEGER_CST)
+   {
+ /* Skip all constant bounds except the most significant one.
+The interior ones are included in the array type.  */
+ if (next && (next->kind == cdk_array || next->kind == cdk_pointer))
+   continue;

will skip constant bounds in an array that's the target of a pointer 
declarator, but not any other kind of bounds.  Is that what you intend - 
that all the other kind of bounds in pointed-to arrays will be recorded in 
this string?

> > Then, the code
> > 
> > +  if (pd->kind == cdk_id)
> > +   {
> > + /* Extract the upper bound from a parameter of an array type.  */
> > 
> > also seems misplaced.  If the type specifiers for the parameter are a
> > typedef for an array type, that array type should be processed *before*
> > the declarator to get the correct semantics (as if the bounds from those
> > type specifiers were given in the declarator), not at the end which gets
> > that type out of order with respect to array declarators.  (Processing
> > before the declarator also means clearing the results of that processing
> > if a pointer declarator is encountered at any point, because in that case
> > the array type in the type specifiers is irrelevant.)
> 
> I'm not sure I follow you here.  Can you show me what you mean on
> a piece of code?  This test case (which IIUC does what you described)
> works as expected:
> 
> $ cat q.c && gcc -O2 -S -Wall q.c
> typedef int A[7][9];
> 
> void f (A[3][5]);

So this is equivalent to A[3][5][7][9].  The c_declarator structures have 
the one for the [3] (the top-level bound) inside the one for the [5].  
The [5] bound is skipped by the "Skip all constant bounds except the most 
significant one." logic.  When the [3] bound is reached, the "break;" at 
the end of that processing means the "Extract the upper bound from a 
parameter of an array type." never gets executed.  Try replacing the [3] 
bound by a VLA bound.  As I read the code, it will end up generating a 
spec string that records first the VLA, then the [7], when it should be 
first the 9 (skipped), then the 7 (skipped), then the 5 (skipped), then 
the VLA.  Or if it's "void f (A *[variable][5]);", it will do the same 
thing (VLA, then 7, although both the 7 and the 9 are part of the 
pointed-to type).

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

Re: [PATCH 2/5] C front end support to detect out-of-bounds accesses to array parameters

[Joseph Myers]

On Fri, 7 Aug 2020, Martin Sebor via Gcc-patches wrote:

> > I don't see anything in the tests in this patch to cover this sort of case
> > (arrays of pointers, including arrays of pointers to arrays etc.).
> 
> I've added a few test cases and reworked the declarator parsing
> (get_parm_array_spec) a bit, fixing some bugs.

I don't think get_parm_array_spec is yet logically right (and I don't see 
tests of the sort of cases I'm concerned about, such as arrays of pointers 
to arrays, or pointers with attributes applied to them).

You have logic

+  if (pd->kind == cdk_pointer
+ && (!next || next->kind == cdk_id))
+   {
+ /* Do nothing for the common case of a pointer.  The fact that
+the parameter is one can be deduced from the absence of
+an arg spec for it.  */
+ return attrs;
+   }

which is correct as far as it goes (when it returns with nothing done, 
it's correct to do so, because the argument is indeed a pointer), but 
incomplete:

* Maybe cdk_pointer is followed by cdk_attrs before cdk_id.  In this case 
the code won't return.

* Maybe the code is correct to continue because we're in the case of an 
array of pointers (cdk_array follows).  But as I understand it, the intent 
is to set up an "arg spec" that describes only the (multidimensional) 
array that is the parameter itself - not any array pointed to.  And it 
looks to me like, in the case of an array of pointers to arrays, both sets 
of array bounds would end up in the spec constructed.

What I think is correct is for both cdk_pointer and cdk_function to result 
in the spec built up so far being cleared (regardless of what follows 
cdk_pointer or cdk_function), rather than early return, so that the spec 
present at the end is for the innermost sequence of array declarators 
(possibly with attributes involved as well).  (cdk_function shouldn't 
actually be an issue, since functions can't return arrays or functions, 
but logically it seems appropriate to treat it like cdk_pointer.)

Then, the code

+  if (pd->kind == cdk_id)
+   {
+ /* Extract the upper bound from a parameter of an array type.  */

also seems misplaced.  If the type specifiers for the parameter are a 
typedef for an array type, that array type should be processed *before* 
the declarator to get the correct semantics (as if the bounds from those 
type specifiers were given in the declarator), not at the end which gets 
that type out of order with respect to array declarators.  (Processing 
before the declarator also means clearing the results of that processing 
if a pointer declarator is encountered at any point, because in that case 
the array type in the type specifiers is irrelevant.)

The logic

+ /* Skip all constant bounds except the most significant one.
+The interior ones are included in the array type.  */
+ if (next && (next->kind == cdk_array || next->kind == cdk_pointer))
+   continue;

is another example of code that fails to look past cdk_attrs.

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

Re: [PATCH v2] libgcc: Use `-fasynchronous-unwind-tables' for LIB2_DIVMOD_FUNCS

[Joseph Myers]

On Thu, 6 Aug 2020, Maciej W. Rozycki via Gcc-patches wrote:

>  Given that for the `riscv64-linux-gnu' target and the ilp32d multilib 
> glibc currently fails to link against libgcc.a built at -O0 I first ran 
> reference testing with target libraries built at -O2, but comparing that 
> to change-under-test -O2 results revealed another issue with GCC target 
> libraries built at -O0 causing link failures across testsuites, namely 
> libgcov.a referring atomic primitives where libatomic.a has not been 
> linked in.  I haven't figured out yet if the issue is in libgcov, the 
> testsuite or the specs.  Examples of failures:

That --as-needed -latomic --no-as-needed should be used by default to link 
in libatomic when required (with consequent changes needed for all 
testsuites) is a known issue; see bug 81358.  Having such references in 
libgcov simply makes that known issue more visible.

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

Re: [PATCH] Treat { 0 } specially for structs with the designated_init attribute.

[Joseph Myers]

On Mon, 3 Aug 2020, Asher Gordon via Gcc-patches wrote:

> Hello,
> 
> Asher Gordon  writes:
> 
> > My copyright assignment finally got finished, so you should be able to
> > apply my patches now.
> 
> Is there any reason my patches haven't been applied yet? Is there
> anything else I need to do?

These patches are on my list for review as and when I get time, if no-one 
else gets to them first.  I don't believe there is anything else you need 
to do at present.

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

Re: [PATCH] CSKY: Add -mfloat-abi= option.

[Joseph Myers]

My glibc bot is showing the build of libgcc for csky-linux-gnuabiv2 
(configured --with-float=hard --disable-multilib) has recently broken, 
likely from this change.

https://sourceware.org/pipermail/libc-testresults/2020q3/006566.html

The errors are of the form:

/tmp/cc7H0Zu7.s: Assembler messages:
/tmp/cc7H0Zu7.s:24: Error: The instruction is not recognized.
/tmp/cc7H0Zu7.s:28: Error: The instruction is not recognized.
/tmp/cc7H0Zu7.s:42: Error: The instruction is not recognized.
/tmp/cc7H0Zu7.s:52: Error: The instruction is not recognized.
/tmp/cc7H0Zu7.s:63: Error: The instruction is not recognized.
/tmp/cc7H0Zu7.s:67: Error: The instruction is not recognized.
/tmp/cc7H0Zu7.s:73: Error: The instruction is not recognized.
Makefile:501: recipe for target '_powisf2.o' failed

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

Re: [PATCH] c: Fix bogus vector initialisation error [PR96377]

[Joseph Myers]

On Fri, 31 Jul 2020, Richard Sandiford wrote:

> Tested on aarch64-linux-gnu, aarch64_be-elf and x86_64-linux-gnu.
> OK to instal?

OK.

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

Re: [PATCH] Require CET support only for the final GCC build

[Joseph Myers]

On Wed, 29 Jul 2020, Richard Biener wrote:

> Note that any workable solution is fine with me, I just
> don't feel comfortable approving the solution involving
> ../curr_stage and friends.  Joseph, would HJs latest
> patch be OK technically?

Yes, I think that's OK.

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

Re: [PATCH 2/5] C front end support to detect out-of-bounds accesses to array parameters

[Joseph Myers]

On Tue, 28 Jul 2020, Martin Sebor via Gcc-patches wrote:

> +  /* A list of VLA variable bounds or null if not specified.  */
> +  tree vbchain = NULL_TREE;
> +  if (parm->declarator->kind == cdk_array)

> +   if (pd->kind != cdk_array)
> + break;

> +   /* Skip all constant bounds except the most significant
> +  one.  The interior ones are included in the array type.  */
> +   if (next && next->kind == cdk_array)
> + continue;

Anything working with declarators should typically have logic to skip 
cdk_attrs declarators.

For example, a parameter is declared as an array using [] in that 
declarator if the innermost c_declarator that is not cdk_id or cdk_attrs 
is of kind cdk_array.  (It's the innermost not the outermost because of C 
declarator syntax.)  The array bounds for the parameter array itself (as 
opposed to any other bounds if the parameter is e.g. an array of pointers 
to arrays) are then those in all the cdk_array declarators after the last 
declarator (if any) that's not cdk_array, cdk_attrs or cdk_id (cdk_id only 
comes in the last place).

If e.g. the parameter has the nested cdk_declarator sequence

cdk_function
cdk_pointer
cdk_array
cdk_attrs
cdk_array
cdk_pointer
cdk_array
cdk_attrs
cdk_array
cdk_array
cdk_id

then it's a three-dimensional array of pointers to two-dimensional arrays 
of pointers to functions.

I don't see anything in the tests in this patch to cover this sort of case 
(arrays of pointers, including arrays of pointers to arrays etc.).

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

Re: [PATCH v3] genemit.c (main): split insn-emit.c for compiling parallelly

[Joseph Myers]

On Fri, 24 Jul 2020, Jojo R wrote:

> + -csplit insn-$*.c /parallel\ compilation/ -k -s 
> {$(insn-generated-split-num)} -f insn-$* -b "%d.c"
> + -( [ ! -s insn-$*0.c ] && for i in {1..$(insn-generated-split-num)}; do 
> touch insn-$*$$i.c; done && echo "" > insn-$*.c)

Ignoring errors (disk full, out of memory, etc.) here is not appropriate.  
If csplit fails, the build must fail.

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

Re: [PATCH 1/2] Add new RTX instruction class FILLER_INSN

[Joseph Myers]

New insn types should be documented in rtl.texi (I think in the "Insns" 
section).

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

Re: [PATCH PR96053] Add "#pragma GCC no_reduc_chain"

[Joseph Myers]

A new pragma needs to be documented in extend.texi.  Such documentation 
should be comprehensible to users who don't know anything about the 
internals of GCC or other compilers, so that they can understand when it 
would be appropriate to use the pragma in their source code.

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

Re: [committed] libstdc++: Add std::from_chars for floating-point types

[Joseph Myers]

On Tue, 21 Jul 2020, Jonathan Wakely via Gcc-patches wrote:

> I also noticed some strings give an underflow error with glibc's
> strtod, but are valid for the Microsoft implementation. For example,
> this one:
> https://github.com/microsoft/STL/blob/master/tests/std/tests/P0067R5_charconv/double_from_chars_test_cases.hpp#L265
> 
> Without the final '1' digit glibc returns DBL_MIN, but with the final
> '1' digit (so a number larger than DBL_MIN) it underflows. Is that
> expected?

That's DBL_TRUE_MIN, not DBL_MIN.  The IEEE rule is that, with default 
exception handling, an exact subnormal result does not raise the underflow 
exception flag, whereas an inexact tiny result raises both inexact and 
underflow flags; glibc mostly doesn't try to ensure an (exact) underflow 
exception is signaled for the case of exact underflow with traps on that 
exception enabled, only correct flags raised with default exception 
handling.

(The way tininess is determined depends on the architecture.  glibc strtod 
handles both cases, before-rounding and after-rounding architectures, 
modulo oddities where implementations of some CPU architectures don't 
appear to be consistent in their before-rounding / after-rounding choice.  
Note that on after-rounding architectures it depends on the result after 
rounding with normal precision but unbounded exponent range.  One 
consequence of that is that the bound on the number of digits after the 
decimal point that may need to be considered, beyond just knowing whether 
any of them are nonzero, to determine the correctly rounded result and 
exceptions, is e.g. 1076 for binary64, not 1075; that is, two digits are 
needed beyond those needed for an exact representation of the least 
subnormal value, although only one such digit is needed for the correctly 
rounded result if you ignore after-rounding tininess detection.)

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