[Bug c/96810] This is a case that gcc shoud not compile successfully, but gcc acts opposite.

[weiwt.fnst at cn dot fujitsu.com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96810

--- Comment #5 from Wei Wentao  ---
Sorry for the last comment.I don't know how this happened.
Let's get to the point.

>>And while the bug described in the comment is really hard to diagnose at
>>compile time and in most cases impossible, what clang diagnoses is the fact
>>that
>>the target construct has implicit map(tofrom:A) clause and because the target
>>data maps only a small part of it, it mapping in target construct will fail.
>>Still, clang implements it incorrectly,

>>Both are completely valid and e.g. the latter could work just fine at runtime
>>if bar performs #pragma omp target enter data (arg1[:30]) for arg2 0 and exit
>>data for arg2 non-zero.

Thank you for your explanation. I agree with that. May I think that clang can
at least emit a diagnostic while gcc did nothing?
Since clang can find the problem in implicit the map, why can't it and gcc find
the problem in the explicit map?
Does it mean that there are some areas in gcc need to be improved? That is what
I am wondering about.

[Bug libfortran/96890] Wrong answer with intrinsic IALL

[kargl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96890

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #2 from kargl at gcc dot gnu.org ---
(In reply to anlauf from comment #1)
> Confirmed.
> 
> Obvious fix:
> 
> diff --git a/libgfortran/m4/iall.m4 b/libgfortran/m4/iall.m4
> index df57367c100..8f3b7741486 100644
> --- a/libgfortran/m4/iall.m4
> +++ b/libgfortran/m4/iall.m4
> @@ -35,7 +35,7 @@ ARRAY_FUNCTION(0,
>  `  result &= *src;')
>  
>  MASKED_ARRAY_FUNCTION(0,
> -`  result = 0;',
> +`  result = ('rtype_name`) -1;',
>  `  if (*msrc)
>  result &= *src;')
>  
> and regenerating the iall_i*.c files.
> 
> How does one do this BTW?

At one point, you did it by using --maintainer-mode with configure.
With the move to git and other changes, I don't know if this has
changed.

[Bug target/96246] [AVX512] unefficient code generatation for vpblendm*

[crazylht at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96246

Hongtao.liu  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|REOPENED|RESOLVED

--- Comment #9 from Hongtao.liu  ---
.

[Bug target/96906] Failure to optimize __builtin_ia32_psubusw128 compared to 0 to __builtin_ia32_pminuw128 compared to operand

[crazylht at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96906

--- Comment #3 from Hongtao.liu  ---
(gdb) f 6 
#6  0x00f04a33 in expand_vect_cond_optab_fn (stmt=0x7fffea1193f0,
optab=vcond_optab) at ../../../gcc/gnu-toolchain/master/gcc/internal-fn.c:2612
2612  expand_insn (icode, 6, ops);
(gdb) p icode
$22 = CODE_FOR_vcondv8hiv8hi

Shouldn't CODE_FOR_vconduv8hiv8hi be used? then sign info could be handled by
extra param in ix86_expand_int_vcond.

[Bug target/96861] Integer min/max optimization failed under -march=skylake-avx512

[crazylht at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96861

--- Comment #3 from Hongtao.liu  ---
(In reply to Hongtao.liu from comment #2)
> .

Difference comes from

  /* Cost the integer to sse and sse to integer moves.  */
  cost += n_sse_to_integer * ix86_cost->sse_to_integer;
  /* ???  integer_to_sse but we only have that in the RA cost table.
 Assume sse_to_integer/integer_to_sse are the same which they
 are at the moment.  */
  cost += n_integer_to_sse * ix86_cost->sse_to_integer;

Maybe need to increase ix86->sse_to_integer, i'm test the following.

--- a/gcc/config/i386/x86-tune-costs.h
+++ b/gcc/config/i386/x86-tune-costs.h
@@ -1769,7 +1769,7 @@ struct processor_costs skylake_cost = {
   {6, 6, 6, 10, 20},   /* cost of unaligned loads.  */
   {8, 8, 8, 8, 16},/* cost of unaligned stores.  */
   2, 2, 4, /* cost of moving XMM,YMM,ZMM register
*/
-  2,   /* cost of moving SSE register to
integer.  */
+  6,   /* cost of moving SSE register to
integer.  */
   20, 8,   /* Gather load static, per_elt.  */
   22, 10,  /* Gather store static, per_elt.  */
   64,  /* size of l1 cache.  */

[Bug target/96906] Failure to optimize __builtin_ia32_psubusw128 compared to 0 to __builtin_ia32_pminuw128 compared to operand

[crazylht at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96906

--- Comment #2 from Hongtao.liu  ---
(In reply to Hongtao.liu from comment #1)
> For vector compare to integer mask, gcc use UNSPEC, that's why it's not
> handled by general part, maybe peephole2 should be added for this.

Or in ix86_expand_int_vcond

[Bug target/96906] Failure to optimize __builtin_ia32_psubusw128 compared to 0 to __builtin_ia32_pminuw128 compared to operand

[crazylht at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96906

Hongtao.liu  changed:

   What|Removed |Added

 CC||crazylht at gmail dot com

--- Comment #1 from Hongtao.liu  ---
For vector compare to integer mask, gcc use UNSPEC, that's why it's not handled
by general part, maybe peephole2 should be added for this.

[Bug target/96861] Integer min/max optimization failed under -march=skylake-avx512

[crazylht at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96861

Hongtao.liu  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #2 from Hongtao.liu  ---
.

[Bug target/96246] [AVX512] unefficient code generatation for vpblendm*

[crazylht at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96246

--- Comment #8 from Hongtao.liu  ---
Should be fixed in GCC11.

[Bug target/96855] [11 Regression] r11-571 regression FAIL: gcc.target/i386/pr92658-1.c

[crazylht at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96855

Hongtao.liu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #5 from Hongtao.liu  ---
Should be fixed in GCC11.

[Bug target/96857] [11 Regression] FAIL: gcc.target/i386/avx512bw-pr95488-1.c scan-assembler-times vpmullw[^\n]*zmm 2 on Linux/x86_64 (-m64 -march=cascadelake)

[crazylht at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96857

Hongtao.liu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from Hongtao.liu  ---
Should be fixed in GCC11.

[Bug target/96856] [11 Regression] FAIL: gcc.target/i386/pr92645-4.c scan-tree-dump-times optimized "VEC_PACK_TRUNC" 1

[crazylht at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96856

Hongtao.liu  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED

--- Comment #4 from Hongtao.liu  ---
Should be fixed in GCC11.

[Bug target/96855] [11 Regression] r11-571 regression FAIL: gcc.target/i386/pr92658-1.c

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96855

--- Comment #4 from CVS Commits  ---
The master branch has been updated by hongtao Liu :

https://gcc.gnu.org/g:8bd5530bfa136663f1fa79e9a1d3932b5adf15bd

commit r11-2990-g8bd5530bfa136663f1fa79e9a1d3932b5adf15bd
Author: liuhongt 
Date:   Mon Aug 31 10:54:13 2020 +0800

Adjust testcase.

gcc/testsuite/ChangeLog:
PR target/96246
PR target/96855
PR target/96856
PR target/96857
* g++.target/i386/avx512bw-pr96246-2.C: Add runtime check for
AVX512BW.
* g++.target/i386/avx512vl-pr96246-2.C: Add runtime check for
AVX512BW and AVX512VL
* g++.target/i386/avx512f-helper.h: New header.
* gcc.target/i386/pr92658-avx512f.c: Add
-mprefer-vector-width=512 to avoid impact of different default
mtune which gcc is built with.
* gcc.target/i386/avx512bw-pr95488-1.c: Ditto.
* gcc.target/i386/pr92645-4.c: Add -mno-avx512f to avoid
impact of different default march which gcc is built with.

[Bug target/96857] [11 Regression] FAIL: gcc.target/i386/avx512bw-pr95488-1.c scan-assembler-times vpmullw[^\n]*zmm 2 on Linux/x86_64 (-m64 -march=cascadelake)

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96857

--- Comment #2 from CVS Commits  ---
The master branch has been updated by hongtao Liu :

https://gcc.gnu.org/g:8bd5530bfa136663f1fa79e9a1d3932b5adf15bd

commit r11-2990-g8bd5530bfa136663f1fa79e9a1d3932b5adf15bd
Author: liuhongt 
Date:   Mon Aug 31 10:54:13 2020 +0800

Adjust testcase.

gcc/testsuite/ChangeLog:
PR target/96246
PR target/96855
PR target/96856
PR target/96857
* g++.target/i386/avx512bw-pr96246-2.C: Add runtime check for
AVX512BW.
* g++.target/i386/avx512vl-pr96246-2.C: Add runtime check for
AVX512BW and AVX512VL
* g++.target/i386/avx512f-helper.h: New header.
* gcc.target/i386/pr92658-avx512f.c: Add
-mprefer-vector-width=512 to avoid impact of different default
mtune which gcc is built with.
* gcc.target/i386/avx512bw-pr95488-1.c: Ditto.
* gcc.target/i386/pr92645-4.c: Add -mno-avx512f to avoid
impact of different default march which gcc is built with.

[Bug target/96246] [AVX512] unefficient code generatation for vpblendm*

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96246

--- Comment #7 from CVS Commits  ---
The master branch has been updated by hongtao Liu :

https://gcc.gnu.org/g:8bd5530bfa136663f1fa79e9a1d3932b5adf15bd

commit r11-2990-g8bd5530bfa136663f1fa79e9a1d3932b5adf15bd
Author: liuhongt 
Date:   Mon Aug 31 10:54:13 2020 +0800

Adjust testcase.

gcc/testsuite/ChangeLog:
PR target/96246
PR target/96855
PR target/96856
PR target/96857
* g++.target/i386/avx512bw-pr96246-2.C: Add runtime check for
AVX512BW.
* g++.target/i386/avx512vl-pr96246-2.C: Add runtime check for
AVX512BW and AVX512VL
* g++.target/i386/avx512f-helper.h: New header.
* gcc.target/i386/pr92658-avx512f.c: Add
-mprefer-vector-width=512 to avoid impact of different default
mtune which gcc is built with.
* gcc.target/i386/avx512bw-pr95488-1.c: Ditto.
* gcc.target/i386/pr92645-4.c: Add -mno-avx512f to avoid
impact of different default march which gcc is built with.

[Bug target/96856] [11 Regression] FAIL: gcc.target/i386/pr92645-4.c scan-tree-dump-times optimized "VEC_PACK_TRUNC" 1

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96856

--- Comment #3 from CVS Commits  ---
The master branch has been updated by hongtao Liu :

https://gcc.gnu.org/g:8bd5530bfa136663f1fa79e9a1d3932b5adf15bd

commit r11-2990-g8bd5530bfa136663f1fa79e9a1d3932b5adf15bd
Author: liuhongt 
Date:   Mon Aug 31 10:54:13 2020 +0800

Adjust testcase.

gcc/testsuite/ChangeLog:
PR target/96246
PR target/96855
PR target/96856
PR target/96857
* g++.target/i386/avx512bw-pr96246-2.C: Add runtime check for
AVX512BW.
* g++.target/i386/avx512vl-pr96246-2.C: Add runtime check for
AVX512BW and AVX512VL
* g++.target/i386/avx512f-helper.h: New header.
* gcc.target/i386/pr92658-avx512f.c: Add
-mprefer-vector-width=512 to avoid impact of different default
mtune which gcc is built with.
* gcc.target/i386/avx512bw-pr95488-1.c: Ditto.
* gcc.target/i386/pr92645-4.c: Add -mno-avx512f to avoid
impact of different default march which gcc is built with.

Re: [PATCH 3/4 v3] ivopts: Consider cost_step on different forms during unrolling

[Kewen.Lin via Gcc-patches]

Hi Segher,

on 2020/9/2 下午6:25, Segher Boessenkool wrote:
> Hi!
> 
> On Wed, Sep 02, 2020 at 11:16:00AM +0800, Kewen.Lin wrote:
>> on 2020/9/1 上午3:41, Segher Boessenkool wrote:
>>> On Tue, Aug 25, 2020 at 08:46:55PM +0800, Kewen.Lin wrote:
 1) Currently address_cost hook on rs6000 always return zero, but at least
 from Power7, pre_inc/pre_dec kind instructions are cracked, it means we
 have to take the address update into account (scalar normal operation).
>>>
>>> From Power4 on already (not sure about Power6, but does anyone care?)
>>
>> Thanks for the information, it looks this issue exists for a long time.
> 
> Well, *is* it an issue?  The addressing doesn't get more expensive...
> For example, an
>   ldu 3,16(4)
> is cracked to an
>   ld 3,16(4)
> and an
>   addi 4,4,16
> (the addi is not on the critical path of the load).  So it seems to me
> this shouldn't increase the addressing cost at all?  (The instruction of
> course is really two insns in one.)
> 

Good question!  I agree that they can execute in parallel, but it depends
on how we interprete the addressing cost, if it's for required execution
resource, I think it's off, since comparing with ld, the ldu has two iops
and extra ALU requirement.  I'm not sure its usage elsewhere, but in the
context of IVOPTs on Power, for one normal candidate, its step cost is 4,
the cost for group (1) is zero, total cost is 4 for this combination.
for the scenario like:
ldx rx, iv // (1)
...
iv = iv + step // (2)

While for ainc_use candidate (like ldu), its step cost is 4, but the cost
for group (1) is (-4 // minus step cost), total cost is 0.  It looks to
say the step update is free.

We can also see (1) and (2) can also execute in parallel (same iteration).
If we consider the next iteration, it will have the dependency, but it's
the same for ldu.  So basically they are similar, I think it's unfair to
have this difference in the cost modeling.  The cracked addi should have
its cost here.  Does it make sense?

Apart from that, one P9 specific point is that the update form load isn't
preferred,  the reason is that the instruction can not retire until both
parts complete, it can hold up subsequent instructions from retiring.
If the addi stalls (starvation), the instruction can not retire and can
cause things stuck.  It seems also something we can model here?

BR,
Kewen

Re: [PATCH] [AVX512] [PR87767] Optimize memory broadcast for constant vector under AVX512

[Hongtao Liu via Gcc-patches]

On Wed, Sep 2, 2020 at 5:58 PM Jakub Jelinek  wrote:
>
> On Wed, Sep 02, 2020 at 09:57:08AM +0800, Hongtao Liu via Gcc-patches wrote:
> > +
> > +  first = XVECEXP (constant, 0, 0);
> > +  /* There could be some rtx like
> > +  (mem/u/c:V16QI (symbol_ref/u:DI ("*.LC1")))
> > +  but with "*.LC1" refer to V2DI constant vector.  */
> > +  if (GET_MODE (constant) != mode)
> > + {
> > +   constant = simplify_subreg (mode, constant, GET_MODE (constant), 0);
> > +   if (constant == NULL_RTX || GET_CODE (constant) != CONST_VECTOR)
> > + return;
> > + }
>
> The
>   first = XVECEXP (constant, 0, 0);
> line needs to be after this if, not before it, otherwise it will miscompile
> things or just ICE.
>

Changed.

> > @@ -2197,6 +2272,10 @@ remove_partial_avx_dependency (void)
> > if (!NONDEBUG_INSN_P (insn))
> >   continue;
> >
> > +   /* Hanlde AVX512 embedded broadcast here to save compile time.  */
>
> s/Hanlde/Handle/
>

Changed, sorry for the typo.

> > +  for (insn = get_insns (); insn; insn = NEXT_INSN (insn))
> > +{
> > +  if (!INSN_P (insn))
> > + continue;
> > +  replace_constant_pool_with_broadcast (insn);
> > +}
>
> Perhaps instead do:
>   for (insn = get_insns (); insn; insn = NEXT_INSN (insn))
> if (INSN_P (insn))
>   replace_constant_pool_with_broadcast (insn);
> ?
>

Changed.

> > +  /* opt_pass methods: */
> > +  virtual bool gate (function *)
> > +{
> > +  /* Return false if rpad pass gate is true.
> > +  replace_constant_pool_with_broadcast is called
> > +  from both this pass and rpad pass.  */
> > +  return (TARGET_AVX512F
> > +   && !(TARGET_AVX
> > +&& TARGET_SSE_PARTIAL_REG_DEPENDENCY
> > +&& TARGET_SSE_MATH
> > +&& optimize
> > +&& optimize_function_for_speed_p (cfun)));
>
> I think this could be a maintainance nightmare.
> Perhaps instead add
>

Yes, a common interface should be added as bellow, changed.

> static bool
> remove_partial_avx_dependency_gate ()
> {
>   return (TARGET_AVX
>   && TARGET_SSE_PARTIAL_REG_DEPENDENCY
>   && TARGET_SSE_MATH
>   && optimize
>   && optimize_function_for_speed_p (cfun));
> }
> after the remove_partial_avx_dependency function definition,
> change pass_remove_partial_avx_dependency gate body to
>   return remove_partial_avx_dependency_gate ();
> and in pass_constant_pool_broadcast::gate do
>   return (TARGET_AVX512F && !remove_partial_avx_dependency_gate ();
> (with the comment you have there)?
>
> LGTM with those changes.
>
> Jakub
>

Thanks for the review, update patch.

-- 
BR,
Hongtao
From acf3825279190ca0540bb4704f66568fdbe06ce8 Mon Sep 17 00:00:00 2001
From: liuhongt 
Date: Wed, 8 Jul 2020 17:14:36 +0800
Subject: [PATCH] Optimize memory broadcast for constant vector under AVX512.

For constant vector having one duplicated value, there's no need to put
whole vector in the constant pool, using embedded broadcast instead.

2020-07-09  Hongtao Liu  

gcc/ChangeLog:

	PR target/87767
	* config/i386/i386-features.c
	(replace_constant_pool_with_broadcast): New function.
	(constant_pool_broadcast): Ditto.
	(class pass_constant_pool_broadcast): New pass.
	(make_pass_constant_pool_broadcast): Ditto.
	(remove_partial_avx_dependency): Call
	replace_constant_pool_with_broadcast under TARGET_AVX512F, it
	would save compile time when both pass rpad and cpb are
	available.
	(remove_partial_avx_dependency_gate): New function.
	(class pass_remove_partial_avx_dependency::gate): Call
	remove_partial_avx_dependency_gate.
	* config/i386/i386-passes.def: Insert new pass after combine.
	* config/i386/i386-protos.h
	(make_pass_constant_pool_broadcast): Declare.
	* config/i386/sse.md (*avx512dq_mul3_bcst):
	New define_insn.
	(*avx512f_mul3_bcst): Ditto.
	* config/i386/avx512fintrin.h (_mm512_set1_ps,
	_mm512_set1_pd,_mm512_set1_epi32, _mm512_set1_epi64): Adjusted.

gcc/testsuite/ChangeLog:

	PR target/87767
	* gcc.target/i386/avx2-broadcast-pr87767-1.c: New test.
	* gcc.target/i386/avx512f-broadcast-pr87767-1.c: New test.
	* gcc.target/i386/avx512f-broadcast-pr87767-2.c: New test.
	* gcc.target/i386/avx512f-broadcast-pr87767-3.c: New test.
	* gcc.target/i386/avx512f-broadcast-pr87767-4.c: New test.
	* gcc.target/i386/avx512f-broadcast-pr87767-5.c: New test.
	* gcc.target/i386/avx512f-broadcast-pr87767-6.c: New test.
	* gcc.target/i386/avx512f-broadcast-pr87767-7.c: New test.
	* gcc.target/i386/avx512vl-broadcast-pr87767-1.c: New test.
	* gcc.target/i386/avx512vl-broadcast-pr87767-1.c: New test.
	* gcc.target/i386/avx512vl-broadcast-pr87767-2.c: New test.
	* gcc.target/i386/avx512vl-broadcast-pr87767-3.c: New test.
	* gcc.target/i386/avx512vl-broadcast-pr87767-4.c: New test.
	* gcc.target/i386/avx512vl-broadcast-pr87767-5.c: New test.
	* gcc.target/i386/avx512vl-broadcast-pr87767-6.c: New test.
---
 gcc/config/i386/avx512fintrin.h   |  

[PATCH v2] c: Silently ignore pragma region [PR85487]

[Austin Morton via Gcc-patches]

#pragma region is a feature introduced by Microsoft in order to allow
manual grouping and folding of code within Visual Studio.  It is
entirely ignored by the compiler.  Clang has supported this feature
since 2012 when in MSVC compatibility mode, and enabled it across the
board in 2018.

As it stands, you cannot use #pragma region within GCC without
disabling unknown pragma warnings, which is not advisable.

I propose GCC adopt "#pragma region" and "#pragma endregion" in order
to alleviate these issues.  Because the pragma has no purpose at
compile time, the implementation is trivial.


Microsoft Documentation on the feature:
https://docs.microsoft.com/en-us/cpp/preprocessor/region-endregion

LLVM change which enabled pragma region across the board:
https://reviews.llvm.org/D42248
---
 gcc/ChangeLog|  5 +
 gcc/c-family/ChangeLog   |  5 +
 gcc/c-family/c-pragma.c  | 10 ++
 gcc/doc/cpp.texi |  6 ++
 gcc/testsuite/ChangeLog  |  5 +
 gcc/testsuite/gcc.dg/pragma-region.c | 21 +
 6 files changed, 52 insertions(+)
 create mode 100644 gcc/testsuite/gcc.dg/pragma-region.c

diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 9db853dcd..d0ba77b55 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,8 @@
+2020-09-02  Austin Morton  
+
+ PR c/85487
+ * doc/cpp.texi (Pragmas): Document pragma region/endregion
+
 2020-08-26  Göran Uddeborg  

  PR gcov-profile/96285
diff --git a/gcc/c-family/ChangeLog b/gcc/c-family/ChangeLog
index 1eaa99f31..ccf06095f 100644
--- a/gcc/c-family/ChangeLog
+++ b/gcc/c-family/ChangeLog
@@ -1,3 +1,8 @@
+2020-09-02  Austin Morton  
+
+ PR c/85487
+ * c-pragma.c (handle_pragma_region): Declare.
+
 2020-08-11  Jakub Jelinek  

  PR c/96545
diff --git a/gcc/c-family/c-pragma.c b/gcc/c-family/c-pragma.c
index e3169e68f..de0411d07 100644
--- a/gcc/c-family/c-pragma.c
+++ b/gcc/c-family/c-pragma.c
@@ -1166,6 +1166,13 @@ handle_pragma_message (cpp_reader *ARG_UNUSED(dummy))
 TREE_STRING_POINTER (message));
 }

+/* Silently ignore region pragmas.  */
+
+static void
+handle_pragma_region (cpp_reader *ARG_UNUSED(dummy))
+{
+}
+
 /* Mark whether the current location is valid for a STDC pragma.  */

 static bool valid_location_for_stdc_pragma;
@@ -1584,6 +1591,9 @@ init_pragma (void)

   c_register_pragma_with_expansion (0, "message", handle_pragma_message);

+  c_register_pragma (0, "region", handle_pragma_region);
+  c_register_pragma (0, "endregion", handle_pragma_region);
+
 #ifdef REGISTER_TARGET_PRAGMAS
   REGISTER_TARGET_PRAGMAS ();
 #endif
diff --git a/gcc/doc/cpp.texi b/gcc/doc/cpp.texi
index 33f876ab7..c868ed695 100644
--- a/gcc/doc/cpp.texi
+++ b/gcc/doc/cpp.texi
@@ -3789,6 +3789,12 @@ file will never be read again, no matter what.
It is a less-portable
 alternative to using @samp{#ifndef} to guard the contents of header files
 against multiple inclusions.

+@item #pragma region
+@itemx #pragma endregion
+These pragmas are silently ignored by the compiler.  Any trailing text is
+also silently ignored.  They exist only to facilitate code organization
+and folding in supported editors.
+
 @end ftable

 @node Other Directives
diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog
index 5c1a45716..d90067555 100644
--- a/gcc/testsuite/ChangeLog
+++ b/gcc/testsuite/ChangeLog
@@ -1,3 +1,8 @@
+2020-09-02  Austin Morton  
+
+ PR c/85487
+ * gcc.dg/pragma-region.c: New test.
+
 2020-08-26  Jeff Law  

  * gcc.target/i386/387-7.c: Add dg-require-effective-target c99_runtime.
diff --git a/gcc/testsuite/gcc.dg/pragma-region.c
b/gcc/testsuite/gcc.dg/pragma-region.c
new file mode 100644
index 0..72cc2c144
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pragma-region.c
@@ -0,0 +1,21 @@
+/* Verify #pragma region and #pragma endregion do not emit warnings.  */
+
+/* { dg-options "-Wunknown-pragmas" } */
+
+#pragma region
+
+#pragma region name
+
+#pragma region "name"
+
+#pragma region()
+
+#pragma region("name")
+
+#pragma endregion
+
+#pragma endregion garbage
+
+#pragma endregion()
+
+#pragma endregion("garbage")
-- 
2.17.1

[PATCH] Add C++2a synchronization support

[Thomas Rodgers]

Note - ignore previous version of this patch, didn't filter out
Makefile.in

Adds support for -
atomic wait/notify_one/notify_all
counting_semaphore
binary_semaphore
latch

* include/Makefile.am (bits_headers): Add new header.
* include/Makefile.in: Regenerate.
* include/bits/atomic_base.h (__atomic_base<_Itp>::wait): Define.
(__atomic_base<_Itp>::notify_one): Likewise.
(__atomic_base<_Itp>::notify_all): Likewise.
(__atomic_base<_Ptp*>::wait): Likewise.
(__atomic_base<_Ptp*>::notify_one): Likewise.
(__atomic_base<_Ptp*>::notify_all): Likewise.
(__atomic_impl::wait): Likewise.
(__atomic_impl::notify_one): Likewise.
(__atomic_impl::notify_all): Likewise.
(__atomic_float<_Fp>::wait): Likewise.
(__atomic_float<_Fp>::notify_one): Likewise.
(__atomic_float<_Fp>::notify_all): Likewise.
(__atomic_ref<_Tp>::wait): Likewise.
(__atomic_ref<_Tp>::notify_one): Likewise.
(__atomic_ref<_Tp>::notify_all): Likewise.
(atomic_wait<_Tp>): Likewise.
(atomic_wait_explicit<_Tp>): Likewise.
(atomic_notify_one<_Tp>): Likewise.
(atomic_notify_all<_Tp>): Likewise.
* include/bits/atomic_wait.h: New file.
* include/bits/atomic_timed_wait.h: New file.
* include/bits/semaphore_base.h: New file.
* include/std/atomic (atomic::wait): Define.
(atomic::wait_one): Likewise.
(atomic::wait_all): Likewise.
(atomic<_Tp>::wait): Likewise.
(atomic<_Tp>::wait_one): Likewise.
(atomic<_Tp>::wait_all): Likewise.
(atomic<_Tp*>::wait): Likewise.
(atomic<_Tp*>::wait_one): Likewise.
(atomic<_Tp*>::wait_all): Likewise.
* include/std/latch: New file.
* include/std/semaphore: New file.
* include/std/version: Add __cpp_lib_semaphore and
__cpp_lib_latch defines.
* testsuite/29_atomic/atomic/wait_notify/atomic_refs.cc: New test.
* testsuite/29_atomic/atomic/wait_notify/bool.cc: Likewise.
* testsuite/29_atomic/atomic/wait_notify/integrals.cc: Likewise.
* testsuite/29_atomic/atomic/wait_notify/floats.cc: Likewise.
* testsuite/29_atomic/atomic/wait_notify/pointers.cc: Likewise.
* testsuite/29_atomic/atomic/wait_notify/generic.cc: Liekwise.
* testsuite/29_atomic/atomic/wait_notify/generic.h: New File.
* testsuite/30_thread/semaphore/1.cc: New test.
* testsuite/30_thread/semaphore/2.cc: Likewise.
* testsuite/30_thread/semaphore/least_max_value_neg.cc: Likewise.
* testsuite/30_thread/semaphore/try_acquire.cc: Likewise.
* testsuite/30_thread/semaphore/try_acquire_for.cc: Likewise.
* testsuite/30_thread/semaphore/try_acquire_posix.cc: Likewise.
* testsuite/30_thread/semaphore/try_acquire_until.cc: Likewise.
* testsuite/30_thread/latch/1.cc: New test.
* testsuite/30_thread/latch/2.cc: New test.
* testsuite/30_thread/latch/3.cc: New test.
---
 libstdc++-v3/include/Makefile.am  |   5 +
 libstdc++-v3/include/Makefile.in  |   5 +
 libstdc++-v3/include/bits/atomic_base.h   | 172 +-
 libstdc++-v3/include/bits/atomic_timed_wait.h | 281 
 libstdc++-v3/include/bits/atomic_wait.h   | 301 ++
 libstdc++-v3/include/bits/semaphore_base.h| 283 
 libstdc++-v3/include/std/atomic   |  73 +
 libstdc++-v3/include/std/latch|  90 ++
 libstdc++-v3/include/std/semaphore|  92 ++
 libstdc++-v3/include/std/version  |   2 +
 .../atomic/wait_notify/atomic_refs.cc | 103 ++
 .../29_atomics/atomic/wait_notify/bool.cc |  59 
 .../29_atomics/atomic/wait_notify/floats.cc   |  32 ++
 .../29_atomics/atomic/wait_notify/generic.cc  |  31 ++
 .../29_atomics/atomic/wait_notify/generic.h   | 160 ++
 .../atomic/wait_notify/integrals.cc   |  65 
 .../29_atomics/atomic/wait_notify/pointers.cc |  59 
 libstdc++-v3/testsuite/30_threads/latch/1.cc  |  27 ++
 libstdc++-v3/testsuite/30_threads/latch/2.cc  |  27 ++
 libstdc++-v3/testsuite/30_threads/latch/3.cc  |  50 +++
 .../testsuite/30_threads/semaphore/1.cc   |  27 ++
 .../testsuite/30_threads/semaphore/2.cc   |  27 ++
 .../semaphore/least_max_value_neg.cc  |  30 ++
 .../30_threads/semaphore/try_acquire.cc   |  55 
 .../30_threads/semaphore/try_acquire_for.cc   |  85 +
 .../30_threads/semaphore/try_acquire_posix.cc | 153 +
 .../30_threads/semaphore/try_acquire_until.cc |  94 ++
 27 files changed, 2387 insertions(+), 1 deletion(-)
 create mode 100644 libstdc++-v3/include/bits/atomic_timed_wait.h
 create mode 100644 libstdc++-v3/include/bits/atomic_wait.h
 create mode 100644 libstdc++-v3/include/bits/semaphore_base.h
 create mode 100644 libstdc++-v3/include/std/latch
 create 

[PATCH] Add C++2a synchronization support

[Thomas Rodgers]

Adds support for -
atomic wait/notify_one/notify_all
counting_semaphore
binary_semaphore
latch

* include/Makefile.am (bits_headers): Add new header.
* include/Makefile.in: Regenerate.
* include/bits/atomic_base.h (__atomic_base<_Itp>::wait): Define.
(__atomic_base<_Itp>::notify_one): Likewise.
(__atomic_base<_Itp>::notify_all): Likewise.
(__atomic_base<_Ptp*>::wait): Likewise.
(__atomic_base<_Ptp*>::notify_one): Likewise.
(__atomic_base<_Ptp*>::notify_all): Likewise.
(__atomic_impl::wait): Likewise.
(__atomic_impl::notify_one): Likewise.
(__atomic_impl::notify_all): Likewise.
(__atomic_float<_Fp>::wait): Likewise.
(__atomic_float<_Fp>::notify_one): Likewise.
(__atomic_float<_Fp>::notify_all): Likewise.
(__atomic_ref<_Tp>::wait): Likewise.
(__atomic_ref<_Tp>::notify_one): Likewise.
(__atomic_ref<_Tp>::notify_all): Likewise.
(atomic_wait<_Tp>): Likewise.
(atomic_wait_explicit<_Tp>): Likewise.
(atomic_notify_one<_Tp>): Likewise.
(atomic_notify_all<_Tp>): Likewise.
* include/bits/atomic_wait.h: New file.
* include/bits/atomic_timed_wait.h: New file.
* include/bits/semaphore_base.h: New file.
* include/std/atomic (atomic::wait): Define.
(atomic::wait_one): Likewise.
(atomic::wait_all): Likewise.
(atomic<_Tp>::wait): Likewise.
(atomic<_Tp>::wait_one): Likewise.
(atomic<_Tp>::wait_all): Likewise.
(atomic<_Tp*>::wait): Likewise.
(atomic<_Tp*>::wait_one): Likewise.
(atomic<_Tp*>::wait_all): Likewise.
* include/std/latch: New file.
* include/std/semaphore: New file.
* include/std/version: Add __cpp_lib_semaphore and
__cpp_lib_latch defines.
* testsuite/29_atomic/atomic/wait_notify/atomic_refs.cc: New test.
* testsuite/29_atomic/atomic/wait_notify/bool.cc: Likewise.
* testsuite/29_atomic/atomic/wait_notify/integrals.cc: Likewise.
* testsuite/29_atomic/atomic/wait_notify/floats.cc: Likewise.
* testsuite/29_atomic/atomic/wait_notify/pointers.cc: Likewise.
* testsuite/29_atomic/atomic/wait_notify/generic.cc: Liekwise.
* testsuite/29_atomic/atomic/wait_notify/generic.h: New File.
* testsuite/30_thread/semaphore/1.cc: New test.
* testsuite/30_thread/semaphore/2.cc: Likewise.
* testsuite/30_thread/semaphore/least_max_value_neg.cc: Likewise.
* testsuite/30_thread/semaphore/try_acquire.cc: Likewise.
* testsuite/30_thread/semaphore/try_acquire_for.cc: Likewise.
* testsuite/30_thread/semaphore/try_acquire_posix.cc: Likewise.
* testsuite/30_thread/semaphore/try_acquire_until.cc: Likewise.
* testsuite/30_thread/latch/1.cc: New test.
* testsuite/30_thread/latch/2.cc: New test.
* testsuite/30_thread/latch/3.cc: New test.
---
 libstdc++-v3/include/Makefile.am  |   5 +
 libstdc++-v3/include/Makefile.in  |   5 +
 libstdc++-v3/include/bits/atomic_base.h   | 172 +-
 libstdc++-v3/include/bits/atomic_timed_wait.h | 281 
 libstdc++-v3/include/bits/atomic_wait.h   | 301 ++
 libstdc++-v3/include/bits/semaphore_base.h| 283 
 libstdc++-v3/include/std/atomic   |  73 +
 libstdc++-v3/include/std/latch|  90 ++
 libstdc++-v3/include/std/semaphore|  92 ++
 libstdc++-v3/include/std/version  |   2 +
 .../atomic/wait_notify/atomic_refs.cc | 103 ++
 .../29_atomics/atomic/wait_notify/bool.cc |  59 
 .../29_atomics/atomic/wait_notify/floats.cc   |  32 ++
 .../29_atomics/atomic/wait_notify/generic.cc  |  31 ++
 .../29_atomics/atomic/wait_notify/generic.h   | 160 ++
 .../atomic/wait_notify/integrals.cc   |  65 
 .../29_atomics/atomic/wait_notify/pointers.cc |  59 
 libstdc++-v3/testsuite/30_threads/latch/1.cc  |  27 ++
 libstdc++-v3/testsuite/30_threads/latch/2.cc  |  27 ++
 libstdc++-v3/testsuite/30_threads/latch/3.cc  |  50 +++
 .../testsuite/30_threads/semaphore/1.cc   |  27 ++
 .../testsuite/30_threads/semaphore/2.cc   |  27 ++
 .../semaphore/least_max_value_neg.cc  |  30 ++
 .../30_threads/semaphore/try_acquire.cc   |  55 
 .../30_threads/semaphore/try_acquire_for.cc   |  85 +
 .../30_threads/semaphore/try_acquire_posix.cc | 153 +
 .../30_threads/semaphore/try_acquire_until.cc |  94 ++
 27 files changed, 2387 insertions(+), 1 deletion(-)
 create mode 100644 libstdc++-v3/include/bits/atomic_timed_wait.h
 create mode 100644 libstdc++-v3/include/bits/atomic_wait.h
 create mode 100644 libstdc++-v3/include/bits/semaphore_base.h
 create mode 100644 libstdc++-v3/include/std/latch
 create mode 100644 libstdc++-v3/include/std/semaphore
 create mode 100644 

git hooks update

[Joseph Myers]

I've updated the gcc-reposurgeon-8 test repository 
(git+ssh://gcc.gnu.org/home/gccadmin/gcc-reposurgeon-8.git) to use the 
same copy of the git hooks as used by binutils-gdb, glibc and other 
repositories on sourceware.

All the features from local hook changes are now handled, with this new 
version, through new configuration variables (in project.config on 
refs/meta/config) and three new scripts referenced in project.config: 
commit_checker, commit_email_formatter and update_hook in 
~gccadmin/hooks-bin.  This version also has various upstream improvements.  
In particular, the email-new-commits-only variable means that no commit 
emails should be sent for commits added to refs under refs/heads/devel/, 
refs/users/ or refs/vendors/ that were already in the repository (so with 
the new hooks, merges to and rebases of such branches should not generate 
floods of commit emails).

Please test whether the hooks are working as expected with the expected 
checks properly implemented in gcc-reposurgeon-8.  If they're working OK, 
we can switch over in the production repository by changing the 
/git/gcc.git/hooks symlink to point to 
/sourceware/projects/src-home/git-hooks/hooks instead of 
/home/gccadmin/git-hooks/hooks, and uncommenting the 
allow-non-fast-forward settings in project.config in the production 
repository.

Once we've switched over, we'll be using a copy of the hooks that is 
shared by other projects, rather than a GCC-specific copy, and so should 
avoid making local changes there.

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

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

[Martin Sebor via Gcc-patches]

Ping: https://gcc.gnu.org/pipermail/gcc-patches/2020-August/552266.html

On 8/25/20 12:44 PM, Martin Sebor wrote:

Joseph, do you have any more comments on the rest of the most recent
revision of the patch?

https://gcc.gnu.org/pipermail/gcc-patches/2020-August/552266.html

Martin

On 8/19/20 6:09 PM, Joseph Myers wrote:

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).

Re: [PATCH] c++: Disable -frounding-math during manifestly constant evaluation [PR96862]

[Marc Glisse]

On Wed, 2 Sep 2020, Jason Merrill via Gcc-patches wrote:


On 9/1/20 6:13 AM, Marc Glisse wrote:

On Tue, 1 Sep 2020, Jakub Jelinek via Gcc-patches wrote:


As discussed in the PR, fold-const.c punts on floating point constant
evaluation if the result is inexact and -frounding-math is turned on.
 /* Don't constant fold this floating point operation if the
    result may dependent upon the run-time rounding mode and
    flag_rounding_math is set, or if GCC's software emulation
    is unable to accurately represent the result.  */
 if ((flag_rounding_math
  || (MODE_COMPOSITE_P (mode) && !flag_unsafe_math_optimizations))
 && (inexact || !real_identical (, )))
   return NULL_TREE;
Jonathan said that we should be evaluating them anyway, e.g. conceptually
as if they are done with the default rounding mode before user had a 
chance

to change that, and e.g. in C in initializers it is also ignored.
In fact, fold-const.c for C initializers turns off various other options:

/* Perform constant folding and related simplification of initializer
  expression EXPR.  These behave identically to "fold_buildN" but ignore
  potential run-time traps and exceptions that fold must preserve.  */

#define START_FOLD_INIT \
 int saved_signaling_nans = flag_signaling_nans;\
 int saved_trapping_math = flag_trapping_math;\
 int saved_rounding_math = flag_rounding_math;\
 int saved_trapv = flag_trapv;\
 int saved_folding_initializer = folding_initializer;\
 flag_signaling_nans = 0;\
 flag_trapping_math = 0;\
 flag_rounding_math = 0;\
 flag_trapv = 0;\
 folding_initializer = 1;

#define END_FOLD_INIT \
 flag_signaling_nans = saved_signaling_nans;\
 flag_trapping_math = saved_trapping_math;\
 flag_rounding_math = saved_rounding_math;\
 flag_trapv = saved_trapv;\
 folding_initializer = saved_folding_initializer;

So, shall cxx_eval_outermost_constant_expr instead turn off all those
options (then warning_sentinel wouldn't be the right thing to use, but 
given

the 8 or how many return stmts in cxx_eval_outermost_constant_expr, we'd
need a RAII class for this.  Not sure about the folding_initializer, that
one is affecting complex multiplication and division constant evaluation
somehow.


I don't think we need to turn off flag_signaling_nans or flag_trapv. I 
think we want to turn off flag_trapping_math so we can fold 1./0 to inf 
(still in a context where folding is mandatory). Setting 
folding_initializer seems consistent with that, enabling infinite results 
in complex folding (it also forces folding of __builtin_constant_p, which 
may be redundant with force_folding_builtin_constant_p).


C++ says that division by zero has undefined behavior, and that an expression 
with undefined behavior is not constant, so we shouldn't fold 1./0 to inf 
anyway.  The same is true of other trapping operations.  So clearing 
flag_signaling_nans, flag_trapping_math, and flag_trapv seems wrong for C++. 
And folding_initializer seems to be used for the same sort of thing.


So we should actually force flag_trapping_math to true during constexpr
evaluation? And folding_initializer to false, and never mind trapv but
maybe disable wrapv?

#include 
constexpr double a = std::numeric_limits::infinity();
constexpr double b = a + a;
constexpr double c = a - a;
constexpr double d = 1. / a;
constexpr double e = 1. / d;

clang rejects c and e. MSVC rejects e. Intel warns on c.

Gcc rejects only e, and accepts the whole thing if I pass
-fno-trapping-math.

Almost any FP operation is possibly trapping, 1./3. sets FE_INEXACT just 
as 1./0. sets FE_DIVBYZERO. But the standard says


char array[1 + int(1 + 0.2 - 0.1 - 0.1)]; // Must be evaluated during 
translation

So it doesn't seem like it cares about that? Division by zero is the only 
one that gets weirdly special-cased...


--
Marc Glisse

Re: Future debug options: -f* or -g*?

[David Blaikie via Gcc]

On Wed, Sep 2, 2020 at 4:12 AM Mark Wielaard  wrote:

> Hi David,
>
> On Mon, 2020-08-31 at 20:10 -0700, David Blaikie wrote:
> > Hey Mark - saw a little of/bits about your presentation at LPC 2020 GNU
> > Tools Track (& your thread on on the gdb list about debug_names).
> Wondering
> > if you (or anyone else you know who's contributing to debug info in GCC)
> > have some thoughts on this flag naming issue. It'd be great to get some
> > alignment between GCC and Clang here, so as we both add new flags going
> > forward, at least they're at least categorically consistent for users,
> even
> > if we aren't necessarily implementing the exact same flags/flag names
> > (though in the -gsplit-dwarf case, it'd be good for any new
> semantics/name
> > to match exactly).
>
> To be honest I don't have any deep insights here. Sadly it is just a
> bit of a mess.


Happen to know any other interested parties (other GCC DWARF contributors
who might have an opinion on flag naming) who might want to weigh in/help
us converge here?


> Not helped by the fact that some debugging formats, like
> DWARF have a number in their name (dwarf2) that might not reflect
> actually reflext the version of that format (except for it being not-
> dwarf1). That is why I was suggesting to use -fdwarf(32|64) instead of
> -gdwarf(32|64) to use for 32 bits vs 64 bits offsets in dwarf(2|3|4|5),
> because there are already too many -gdwarf[number] options.
>
> The idea of having any of the -fs not imply -g and having
> any of the -gs imply -g seems a good one.
>

Cool cool.


> But in general I think these suboptions are all a bit nonsense though.
> They are great for tinkering and playing with corner cases of the
> debugging format. But I don't think we are helping real developers with
> them. To make any of them useful they should be in one of the standard
> options that people actually use. Nobody has time (or the specialized
> knowledge) to really care about all these suboptions. Once people feel
> they need to use any of these suboptions we already lost or the user
> has such specialized knowledge that they will know about specific
> changes in these options or between compilers.
>

Perhaps - I think there are different use cases. A big one in LLVM we call
-fstandalone-debug: Are you building everything with debug info, or only
one or two files/can the compiler assume other files will be built with
debug info. (this affects basically the same things as
-femit-class-debug-always). Split DWARF for users with distributed build
systems. Several options can weight object size compared to linked
executable size - such as using base address selection entries in range and
location lists (reducing relocations). Obviously I'm biased here - I live
in this stuff & have users/use cases that are... not the norm.


> So just like we have -Wall or -Wextra has groups of warning options
> people are likely to use and we have -O1, -O2 and -O3 (I personally
> believe -flto should just be in -O3 instead of being a separate
> option),


I imagine quite a few users build with optimization for particular CPUs -
though, again, partly my bias of working on a homogenous/controlled
environment in data centers, rather than trying to build a binary to send
to random users in the world. But I'd guess games and things that want to
eek out performance probably want to use modern CPU features if available.


> we should simply focus on making -g1, -g2 and -g3 have good
> defaults. Where -g1 is the minimum needed to do some
> profiling/tracing/debugging without needing to map all addresses back
> to source completely but can leave out full type trees for example, -g2
> is the default for being able to do a useful interactive debugging
> session and -g3 adds some (expensive) extras like .debug_macros and
> maybe .debug_names, etc.
>

Maybe. I'd guess a fair few users (especially in their continuous
integration systems, etc) might have some different tradeoffs in terms of
compile/link time and debugging/debugger startup time (indexes are a
particularly potent example of this - pay some link time for some debugger
startup improvement - but if I don't use a debugger very often, I may not
want to pay that link time cost all the time).


> With respect to -gsplit-dwarf I think it was (in hindsight) a mistake
> to put things in a separate (.dwo) file. It is a bit confusing to users
> and complicates build systems immensely. I am hoping to implement
> -gsplit-dwarf=single using SHF_EXCLUDED for gcc and then make that the
> default.
>

Yeah, we've got support for that model in Clang - but to be honest, one of
the major motivations for implementing Split DWARF was Google's internal
use (big distributed build system) & the split mode isn't a mistake in this
context - not having to ship all the DWARF bytes to the machine doing the
link is a significant savings. (even if we ship all those bytes to another
machine to make a dwp) and smaller files to pull down when a user wants to
debug 

[Bug fortran/96910] New: intrinsic assignment does not duplicate allocatable component of nested derived type

[dlhough at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96910

Bug ID: 96910
   Summary: intrinsic assignment does not duplicate allocatable
component of nested derived type
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dlhough at gmail dot com
  Target Milestone: ---

In the following code, I would expect a new allocation to be made for copy%nest
in the assignment copy=original in the same fashion as a new allocation is
created for copy%child. However, copy%nest and original%nest are at the same
address following the assignment as demonstrated by the print statements.


module TestAllocatableCopy_m
   implicit none
   private

   type, public :: Child_t
   end type

   type, public :: Test_t
  type(Test_t), allocatable :: nest 
  type(Child_t), allocatable :: child
   end type

end module

program TestAllocatableCopy
   use TestAllocatableCopy_m
   implicit none

   type(Test_t), target :: original
   type(Test_t), target :: copy
   class(Test_t), pointer :: nestPtr
   class(Child_t), pointer :: childPtr

   allocate(original%nest)
   allocate(original%child)

   nestPtr => original%nest
   childPtr => original%child

   copy = original

   ! prints "Child: F" with GCC 10.2
   print *, "Child:", associated(childPtr, copy%child)

   ! prints "Nest: T" with GCC 10.2
   ! expected: "Nest: F"
   print *, "Nest:", associated(nestPtr, copy%nest)

end program


Compilation command:
gfortran -v -save-temps -Wall -Wextra  ../../test/TestAllocatableCopy.f90 
Driving: gfortran -v -save-temps -Wall -Wextra
../../test/TestAllocatableCopy.f90 -l gfortran -l m -shared-libgcc
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib
--libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++,d --with-isl
--with-linker-hash-style=gnu --with-system-zlib --enable-__cxa_atexit
--enable-cet=auto --enable-checking=release --enable-clocale=gnu
--enable-default-pie --enable-default-ssp --enable-gnu-indirect-function
--enable-gnu-unique-object --enable-install-libiberty --enable-linker-build-id
--enable-lto --enable-multilib --enable-plugin --enable-shared
--enable-threads=posix --disable-libssp --disable-libstdcxx-pch
--disable-libunwind-exceptions --disable-werror
gdc_include_dir=/usr/include/dlang/gdc
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 10.2.0 (GCC) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall' '-Wextra' '-shared-libgcc'
'-mtune=generic' '-march=x86-64'
 /usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/f951
../../test/TestAllocatableCopy.f90 -quiet -dumpbase TestAllocatableCopy.f90
-mtune=generic -march=x86-64 -auxbase TestAllocatableCopy -Wall -Wextra
-version -fintrinsic-modules-path
/usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/finclude
-fpre-include=/usr/include/finclude/math-vector-fortran.h -o
TestAllocatableCopy.s
GNU Fortran (GCC) version 10.2.0 (x86_64-pc-linux-gnu)
compiled by GNU C version 10.2.0, GMP version 6.2.0, MPFR version
4.1.0, MPC version 1.1.0, isl version isl-0.21-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU Fortran2008 (GCC) version 10.2.0 (x86_64-pc-linux-gnu)
compiled by GNU C version 10.2.0, GMP version 6.2.0, MPFR version
4.1.0, MPC version 1.1.0, isl version isl-0.21-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall' '-Wextra' '-shared-libgcc'
'-mtune=generic' '-march=x86-64'
 as -v --64 -o TestAllocatableCopy.o TestAllocatableCopy.s
GNU assembler version 2.35 (x86_64-pc-linux-gnu) using BFD version (GNU
Binutils) 2.35
Reading specs from
/usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../lib/libgfortran.spec
rename spec lib to liborig
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall' '-Wextra' '-shared-libgcc'
'-mtune=generic' '-march=x86-64'
COMPILER_PATH=/usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/:/usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/:/usr/lib/gcc/x86_64-pc-linux-gnu/:/usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/:/usr/lib/gcc/x86_64-pc-linux-gnu/
LIBRARY_PATH=/usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/:/usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../lib/:/lib/../lib/:/usr/lib/../lib/:/usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall' '-Wextra' '-shared-libgcc'
'-mtune=generic' '-march=x86-64'
 /usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/collect2 -plugin
/usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/liblto_plugin.so
-plugin-opt=/usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/lto-wrapper

Re: [PATCH v3] c++: Fix P0960 in member init list and array [PR92812]

[Marek Polacek via Gcc-patches]

On Wed, Sep 02, 2020 at 05:06:45PM -0400, Jason Merrill wrote:
> On 9/2/20 4:37 PM, Marek Polacek wrote:
> > I've added do_aggregate_paren_init to factor some common code.  It's not
> > perfect because the enclosing conditions couldn't really be factored out,
> 
> This condition:
> 
> > +  && (list_length (init) > 1
> > +  /* A single-element list: handle non-standard extensions
> > + like compound literals.  This also prevents triggering
> > + aggregate ()-initialization in compiler-generated code
> > + for =default.  */
> > +  || (list_length (init) == 1
> > +  && !same_type_ignoring_top_level_qualifiers_p
> > +  (type, TREE_TYPE (TREE_VALUE (init))
> 
> seems like it could move into do_aggregate_paren_init as well, even if it's
> redundant with code in the caller in some cases; we never want to add { } to
> a single parenthesized expression of the same type.

True, done in this patch.

> And don't we need to
> check for the same-type situation for the array case in check_initializer?

Yea, I think so.  It can be reached using either

  char c[4]("foo");
 
which is already handled by the string literal case, or with an array prvalue:

  using T = int[2];
  T t(T{1, 1});

> Incidentally, for checking whether a list is length 1 or more, probably
> slightly more efficient to look at TREE_CHAIN directly like
> do_aggregate_paren_init does in this patch, rather than use list_length.

Done.

How does this look?  Testing in progress, but dg.exp and old-deja.exp
is clean.

Ok if testing passes?

-- >8 --
This patch nails down the remaining P0960 case in PR92812:

  struct A {
int ar[2];
A(): ar(1, 2) {} // doesn't work without this patch
  };

Note that when the target object is not of array type, this already
works:

  struct S { int x, y; };
  struct A {
S s;
A(): s(1, 2) { } // OK in C++20
  };

because build_new_method_call_1 takes care of the P0960 magic.

It proved to be quite hairy.  When the ()-list has more than one
element, we can always create a CONSTRUCTOR, because the code was
previously invalid.  But when the ()-list has just one element, it
gets all kinds of difficult.  As usual, we have to handle a("foo")
so as not to wrap the STRING_CST in a CONSTRUCTOR.  Always turning
x(e) into x{e} would run into trouble as in c++/93790.  Another
issue was what to do about x({e}): previously, this would trigger
"list-initializer for non-class type must not be parenthesized".
I figured I'd make this work in C++20, so that given

  struct S { int x, y; };

you can do

   S a[2];
   [...]
   A(): a({1, 2}) // initialize a[0] with {1, 2} and a[1] with {}

It also turned out that, as an extension, we support compound literals:

  F (): m((S[1]) { 1, 2 })

so this has to keep working as before.  Moreover, make sure not to trigger
in compiler-generated code, like =default, where array assignment is allowed.

I've factored out a function that turns a TREE_LIST into a CONSTRUCTOR
to simplify handling of P0960.

paren-init35.C also tests this with vector types.

gcc/cp/ChangeLog:

PR c++/92812
* cp-tree.h (do_aggregate_paren_init): Declare.
* decl.c (do_aggregate_paren_init): New.
(grok_reference_init): Use it.
(check_initializer): Likewise.
* init.c (perform_member_init): Handle initializing an array from
a ()-list.  Use do_aggregate_paren_init.

gcc/testsuite/ChangeLog:

PR c++/92812
* g++.dg/cpp0x/constexpr-array23.C: Adjust dg-error.
* g++.dg/cpp0x/initlist69.C: Likewise.
* g++.dg/diagnostic/mem-init1.C: Likewise.
* g++.dg/init/array28.C: Likewise.
* g++.dg/cpp2a/paren-init33.C: New test.
* g++.dg/cpp2a/paren-init34.C: New test.
* g++.dg/cpp2a/paren-init35.C: New test.
* g++.old-deja/g++.brendan/crash60.C: Adjust dg-error.
* g++.old-deja/g++.law/init10.C: Likewise.
* g++.old-deja/g++.other/array3.C: Likewise.
---
 gcc/cp/cp-tree.h  |   1 +
 gcc/cp/decl.c |  62 +
 gcc/cp/init.c |  26 +++-
 .../g++.dg/cpp0x/constexpr-array23.C  |   6 +-
 gcc/testsuite/g++.dg/cpp0x/initlist69.C   |   4 +-
 gcc/testsuite/g++.dg/cpp2a/paren-init33.C | 128 ++
 gcc/testsuite/g++.dg/cpp2a/paren-init34.C |  25 
 gcc/testsuite/g++.dg/cpp2a/paren-init35.C |  21 +++
 gcc/testsuite/g++.dg/diagnostic/mem-init1.C   |   4 +-
 gcc/testsuite/g++.dg/init/array28.C   |   2 +-
 .../g++.old-deja/g++.brendan/crash60.C|   2 +-
 gcc/testsuite/g++.old-deja/g++.law/init10.C   |   2 +-
 gcc/testsuite/g++.old-deja/g++.other/array3.C |   3 +-
 13 files changed, 239 insertions(+), 47 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp2a/paren-init33.C
 create mode 100644 gcc/testsuite/g++.dg/cpp2a/paren-init34.C
 create 

[Bug fortran/96909] New: ICE with nested polymorphic allocatable component

[dlhough at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96909

Bug ID: 96909
   Summary: ICE with nested polymorphic allocatable component
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dlhough at gmail dot com
  Target Milestone: ---

The following code compiles successfully if the "nest" component is declared as
type() rather than class().


module Test_m
   implicit none
   private

   type, public :: Test_t
  class(Test_t), allocatable :: nest 
   end type

end module



Command line output:

gfortran -v -save-temps -Wall -Wextra -c ../../test/TestAllocatableCopy.f90 
Using built-in specs.
COLLECT_GCC=gfortran
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib
--libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++,d --with-isl
--with-linker-hash-style=gnu --with-system-zlib --enable-__cxa_atexit
--enable-cet=auto --enable-checking=release --enable-clocale=gnu
--enable-default-pie --enable-default-ssp --enable-gnu-indirect-function
--enable-gnu-unique-object --enable-install-libiberty --enable-linker-build-id
--enable-lto --enable-multilib --enable-plugin --enable-shared
--enable-threads=posix --disable-libssp --disable-libstdcxx-pch
--disable-libunwind-exceptions --disable-werror
gdc_include_dir=/usr/include/dlang/gdc
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 10.2.0 (GCC) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall' '-Wextra' '-c' '-mtune=generic'
'-march=x86-64'
 /usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/f951
../../test/TestAllocatableCopy.f90 -quiet -dumpbase TestAllocatableCopy.f90
-mtune=generic -march=x86-64 -auxbase TestAllocatableCopy -Wall -Wextra
-version -fintrinsic-modules-path
/usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/finclude
-fpre-include=/usr/include/finclude/math-vector-fortran.h -o
TestAllocatableCopy.s
GNU Fortran (GCC) version 10.2.0 (x86_64-pc-linux-gnu)
compiled by GNU C version 10.2.0, GMP version 6.2.0, MPFR version
4.1.0, MPC version 1.1.0, isl version isl-0.21-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU Fortran2008 (GCC) version 10.2.0 (x86_64-pc-linux-gnu)
compiled by GNU C version 10.2.0, GMP version 6.2.0, MPFR version
4.1.0, MPC version 1.1.0, isl version isl-0.21-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
gfortran: internal compiler error: Segmentation fault signal terminated program
f951
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[Bug c++/96908] New: [c++20] substitution failure if lambda in default template param

[bastien.penavayre at epitech dot eu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96908

Bug ID: 96908
   Summary: [c++20] substitution failure if lambda in default
template param
   Product: gcc
   Version: 9.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bastien.penavayre at epitech dot eu
  Target Milestone: ---

code:
```
template // 'auto = []{}' would do the same
void func() {}

template
void func2() {}

template
void f()
{
func(); //substituion failure
func2(); //substituion failure
}

int main()
{
func(); // ok
func2(); // ok
}
```

output:
```
source>: In function 'void f()':
:10:10: error: no matching function for call to 'func()'

   10 | func(); //substituion failure
  |  ^
:2:6: note: candidate: 'template > void func()'
2 | void func() {}
  |  ^~~~
:2:6: note:   template argument deduction/substitution failed:
:11:11: error: no matching function for call to 'func2()'
   11 | func2(); //substituion failure
  |   ^
:5:6: note: candidate: 'template > void func2()'
5 | void func2() {}
  |  ^
:5:6: note:   template argument deduction/substitution failed:
Compiler returned: 1
```

can be tested in godbolt: https://godbolt.org/z/xjTPoj

Re: [PATCH] c++: Add __builtin_bit_cast to implement std::bit_cast [PR93121]

[Jason Merrill via Gcc-patches]

On 8/27/20 6:19 AM, Richard Biener wrote:

On Thu, 27 Aug 2020, Jakub Jelinek wrote:


On Fri, Jul 31, 2020 at 04:28:05PM -0400, Jason Merrill via Gcc-patches wrote:

On 7/31/20 6:06 AM, Jakub Jelinek wrote:

On Fri, Jul 31, 2020 at 10:54:46AM +0100, Jonathan Wakely wrote:

Does the standard require that somewhere?  Because that is not what the
compiler implements right now.


https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78620


But does that imply that all CONSTRUCTORs without CONSTRUCTOR_NO_CLEARING
need to be treated that way?  I mean, aren't such CONSTRUCTORs used also for
other initializations?


Yes, they are also used to represent constant values of classes that are
initialized by constexpr constructor.


And, are the default copy constructors or assignment operators supposed to
also copy the padding bits, or do they become unspecified again through
that?


For a non-union class, a defaulted copy is defined as memberwise copy, not a
copy of the entire object representation.  So I guess strictly speaking the
padding bits do become unspecified.  But I think if the copy is trivial, in
practice all implementations do copy the object representation; perhaps the
specification should adjust accordingly.


Sorry for not responding earlier.  I think at least in GCC there is no
guarantee the copying is copying the object representation rather than
memberwise copy, both are possible, depending e.g. whether SRA happens or
not.


Note we've basically settled on that SRA needs to copy padding and that
GIMPLE copies all bytes for aggregate copies and thus

   x = {}

is equivalent to a memset.


So, shouldn't we have a new CONSTRUCTOR flag that will represent whether
padding bits are cleared or not and then use it e.g. in the gimplifier?
Right now the gimplifier only adds first zero initialization if
CONSTRUCTOR_NO_CLEARING is not set and some initializers are not present,
so if there is a new flag, we'd need to in that case find out if there are
any padding bits and do the zero initialization in that case.
A question is if GIMPLE var = {}; statement (empty CONSTRUCTOR) is handled
as zero initialization of also the padding bits, or if we should treat it
that way only if the CONSTRUCTOR on the rhs has the new bit set and e.g.
when lowering memset 0 into var = {}; set the bit too.
 From what I understood on IRC, D has similar need for zero initialization of
padding.


Now indeed the gimplifier will turn a aggregate CTOR initialization
to memberwise init without caring for padding.  Which means GENERIC
has the less strict semantics and we indeed would need some CTOR flag
to tell whether padding is implicitely zero or undefined?


CONSTRUCTOR_NO_CLEARING would seem to already mean that, but the C++ 
front end uses it just to indicate whether some fields are 
uninitialized.  I suppose C++ could use a LANG_FLAG for that instead of 
the generic flag.



In the testcase below, what is and what is not UB?

#include 

struct S { int a : 31; int b; };
struct T { int a, b; };

constexpr int
foo ()
{
   S a = S ();
   S b = { 0, 0 };
   S c = a;
   S d;
   S e;
   d = a;
   e = S ();
   int u = std::bit_cast (T, a).a; // Is this well defined due to value 
initialization of a?
   int v = std::bit_cast (T, b).a; // But this is invalid, right?  There is no 
difference in the IL though.
   int w = std::bit_cast (T, c).a; // And this is also invalid, or are default 
copy ctors required to copy padding bits?
   int x = std::bit_cast (T, d).a; // Similarly for default copy assignment 
operators...
   int y = std::bit_cast (T, e).a; // And this too?
   int z = std::bit_cast (T, S ()).a; // This one is well defined?
   return u + v + w + x + y + z;
}

constexpr int x = foo ();

Jakub

[Bug middle-end/96903] [11 regression] excess errors from gcc.dg/pr89350.c after r11-2973

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96903

Martin Sebor  changed:

   What|Removed |Added

 Blocks||88443
 Ever confirmed|0   |1
  Component|testsuite   |middle-end
   Last reconfirmed||2020-09-02
   Keywords||diagnostic
 Status|UNCONFIRMED |ASSIGNED

--- Comment #1 from Martin Sebor  ---
Also reported on x86_64 here:
  https://gcc.gnu.org/pipermail/gcc-patches/2020-September/553124.html


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88443
[Bug 88443] [meta-bug] bogus/missing -Wstringop-overflow warnings

[Bug fortran/96902] internal compiler error in gimplify_scan_omp_clauses with "!$omp target enter data" directive

[michalak at ucar dot edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96902

michalak at ucar dot edu changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #2 from michalak at ucar dot edu ---
I have built the top of the new GCC repository (c71644776f, dated today) and
verified that the bug is in fact fixed. I am marking the ticket as resolved.
Thank you for the quick and helpful reply. Best regards. -John

[Bug libfortran/96890] Wrong answer with intrinsic IALL

[anlauf at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96890

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

  Component|fortran |libfortran
 Status|UNCONFIRMED |NEW
 CC||anlauf at gcc dot gnu.org
   Last reconfirmed||2020-09-02
 Ever confirmed|0   |1
   Priority|P3  |P4

--- Comment #1 from anlauf at gcc dot gnu.org ---
Confirmed.

Obvious fix:

diff --git a/libgfortran/m4/iall.m4 b/libgfortran/m4/iall.m4
index df57367c100..8f3b7741486 100644
--- a/libgfortran/m4/iall.m4
+++ b/libgfortran/m4/iall.m4
@@ -35,7 +35,7 @@ ARRAY_FUNCTION(0,
 `  result &= *src;')

 MASKED_ARRAY_FUNCTION(0,
-`  result = 0;',
+`  result = ('rtype_name`) -1;',
 `  if (*msrc)
 result &= *src;')

and regenerating the iall_i*.c files.

How does one do this BTW?

[Bug c++/96905] ICE with consteval function: internal compiler error: in cp_gimplify_expr, at cp/cp-gimplify.c:827

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96905

--- Comment #3 from Jakub Jelinek  ---
Yeah, we certainly never want to genericize them.

Re: [PATCH v2] c++: Fix P0960 in member init list and array [PR92812]

[Jason Merrill via Gcc-patches]

On 9/2/20 4:37 PM, Marek Polacek wrote:

On Wed, Sep 02, 2020 at 12:00:29PM -0400, Jason Merrill via Gcc-patches wrote:

On 9/1/20 6:23 PM, Marek Polacek wrote:

This patch nails down the remaining P0960 case in PR92812:

struct A {
  int ar[2];
  A(): ar(1, 2) {} // doesn't work without this patch
};

Note that when the target object is not of array type, this already
works:

struct S { int x, y; };
struct A {
  S s;
  A(): s(1, 2) { } // OK in C++20
};

because build_new_method_call_1 takes care of the P0960 magic.

It proved to be quite hairy.  When the ()-list has more than one
element, we can always create a CONSTRUCTOR, because the code was
previously invalid.  But when the ()-list has just one element, it
gets all kinds of difficult.  As usual, we have to handle a("foo")
so as not to wrap the STRING_CST in a CONSTRUCTOR.  Always turning
x(e) into x{e} would run into trouble as in c++/93790.  Another
issue was what to do about x({e}): previously, this would trigger
"list-initializer for non-class type must not be parenthesized".
I figured I'd make this work in C++20, so that given

struct S { int x, y; };

you can do

 S a[2];
 [...]
 A(): a({1, 2}) // initialize a[0] with {1, 2} and a[1] with {}

It also turned out that, as an extension, we support compound literals:

F (): m((S[1]) { 1, 2 })

so this has to keep working as before.

Moreover, make sure not to trigger in compiler-generated code, like
=default, where array assignment is allowed.

paren-init35.C also tests this with vector types.

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?

gcc/cp/ChangeLog:

PR c++/92812
* init.c (do_paren_init_for_array_p): New.
(perform_member_init): Use it.  If true, build up a CONSTRUCTOR
from the list of arguments.

gcc/testsuite/ChangeLog:

PR c++/92812
* g++.dg/cpp0x/constexpr-array23.C: Adjust dg-error.
* g++.dg/cpp0x/initlist69.C: Likewise.
* g++.dg/diagnostic/mem-init1.C: Likewise.
* g++.dg/init/array28.C: Likewise.
* g++.dg/cpp2a/paren-init33.C: New test.
* g++.dg/cpp2a/paren-init34.C: New test.
* g++.dg/cpp2a/paren-init35.C: New test.
* g++.old-deja/g++.brendan/crash60.C: Adjust dg-error.
* g++.old-deja/g++.law/init10.C: Likewise.
* g++.old-deja/g++.other/array3.C: Likewise.
---
   gcc/cp/init.c |  64 -
   .../g++.dg/cpp0x/constexpr-array23.C  |   6 +-
   gcc/testsuite/g++.dg/cpp0x/initlist69.C   |   4 +-
   gcc/testsuite/g++.dg/cpp2a/paren-init33.C | 128 ++
   gcc/testsuite/g++.dg/cpp2a/paren-init34.C |  25 
   gcc/testsuite/g++.dg/cpp2a/paren-init35.C |  21 +++
   gcc/testsuite/g++.dg/diagnostic/mem-init1.C   |   4 +-
   gcc/testsuite/g++.dg/init/array28.C   |   2 +-
   .../g++.old-deja/g++.brendan/crash60.C|   2 +-
   gcc/testsuite/g++.old-deja/g++.law/init10.C   |   2 +-
   gcc/testsuite/g++.old-deja/g++.other/array3.C |   3 +-
   11 files changed, 243 insertions(+), 18 deletions(-)
   create mode 100644 gcc/testsuite/g++.dg/cpp2a/paren-init33.C
   create mode 100644 gcc/testsuite/g++.dg/cpp2a/paren-init34.C
   create mode 100644 gcc/testsuite/g++.dg/cpp2a/paren-init35.C

diff --git a/gcc/cp/init.c b/gcc/cp/init.c
index d4540db3605..2edc9651ad6 100644
--- a/gcc/cp/init.c
+++ b/gcc/cp/init.c
@@ -756,6 +756,41 @@ maybe_warn_list_ctor (tree member, tree init)
 "of the underlying array", member, begin);
   }
+/* Return true if we should attempt to perform the P0960 magic when
+   initializing an array TYPE from a parenthesized list of values LIST.  */
+
+static bool
+do_paren_init_for_array_p (tree list, tree type)
+{
+  if (cxx_dialect < cxx20)
+/* P0960 is a C++20 feature.  */
+return false;
+
+  const int len = list_length (list);
+  if (len == 0)
+/* Value-initialization.  */
+return false;
+  else if (len > 1)
+/* If the list had more than one element, the code is ill-formed
+   pre-C++20, so we should attempt to ()-init.  */
+return true;
+
+  /* Lists with one element are trickier.  */
+  tree elt = TREE_VALUE (list);
+
+  /* For a("foo"), don't wrap the STRING_CST in { }.  */
+  if (char_type_p (TYPE_MAIN_VARIANT (TREE_TYPE (type)))
+  && TREE_CODE (tree_strip_any_location_wrapper (elt)) == STRING_CST)
+return false;


Hmm, yet another place we need to implement the special treatment of
strings?  Can't we factor this better?  Could there be a general e.g.
maybe_aggregate_paren_init function to turn a list into a CONSTRUCTOR that's
used in various places?


I've added do_aggregate_paren_init to factor some common code.  It's not
perfect because the enclosing conditions couldn't really be factored out,


This condition:


+  && (list_length (init) > 1
+  /* A single-element list: handle non-standard extensions
+ 

[Bug d/96869] __vectors unsupported in hardware should be rejected at compile-time

[ibuclaw at gdcproject dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96869

Iain Buclaw  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from Iain Buclaw  ---
Done.

[Bug d/96869] __vectors unsupported in hardware should be rejected at compile-time

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96869

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Iain Buclaw :

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

commit r11-2988-gf0a3bab43fda3084eaf1bdaac58936757f30ea35
Author: Iain Buclaw 
Date:   Mon Aug 31 22:42:10 2020 +0200

d: __vectors unsupported in hardware should be rejected at compile-time.

gcc/d/ChangeLog:

PR d/96869
* d-builtins.cc (build_frontend_type): Don't expose intrinsics that
use unsupported vector types.
* d-target.cc (Target::isVectorTypeSupported): Restrict to
supporting
only if TARGET_VECTOR_MODE_SUPPORTED_P is true.  Don't allow
complex
or boolean vector types.

gcc/testsuite/ChangeLog:

PR d/96869
* gdc.dg/simd.d: Removed.
* gdc.dg/cast1.d: New test.
* gdc.dg/gdc213.d: Compile with target vect_sizes_16B_8B.
* gdc.dg/gdc284.d: Likewise.
* gdc.dg/gdc67.d: Likewise.
* gdc.dg/pr96869.d: New test.
* gdc.dg/simd1.d: New test.
* gdc.dg/simd10447.d: New test.
* gdc.dg/simd12776.d: New test.
* gdc.dg/simd13841.d: New test.
* gdc.dg/simd13927.d: New test.
* gdc.dg/simd15123.d: New test.
* gdc.dg/simd15144.d: New test.
* gdc.dg/simd16087.d: New test.
* gdc.dg/simd16697.d: New test.
* gdc.dg/simd17237.d: New test.
* gdc.dg/simd17695.d: New test.
* gdc.dg/simd17720a.d: New test.
* gdc.dg/simd17720b.d: New test.
* gdc.dg/simd19224.d: New test.
* gdc.dg/simd19627.d: New test.
* gdc.dg/simd19628.d: New test.
* gdc.dg/simd19629.d: New test.
* gdc.dg/simd19630.d: New test.
* gdc.dg/simd2a.d: New test.
* gdc.dg/simd2b.d: New test.
* gdc.dg/simd2c.d: New test.
* gdc.dg/simd2d.d: New test.
* gdc.dg/simd2e.d: New test.
* gdc.dg/simd2f.d: New test.
* gdc.dg/simd2g.d: New test.
* gdc.dg/simd2h.d: New test.
* gdc.dg/simd2i.d: New test.
* gdc.dg/simd2j.d: New test.
* gdc.dg/simd7951.d: New test.
* gdc.dg/torture/array2.d: New test.
* gdc.dg/torture/array3.d: New test.
* gdc.dg/torture/simd16488a.d: New test.
* gdc.dg/torture/simd16488b.d: New test.
* gdc.dg/torture/simd16703.d: New test.
* gdc.dg/torture/simd19223.d: New test.
* gdc.dg/torture/simd19607.d: New test.
* gdc.dg/torture/simd3.d: New test.
* gdc.dg/torture/simd4.d: New test.
* gdc.dg/torture/simd7411.d: New test.
* gdc.dg/torture/simd7413a.d: New test.
* gdc.dg/torture/simd7413b.d: New test.
* gdc.dg/torture/simd7414.d: New test.
* gdc.dg/torture/simd9200.d: New test.
* gdc.dg/torture/simd9304.d: New test.
* gdc.dg/torture/simd9449.d: New test.
* gdc.dg/torture/simd9910.d: New test.

[Bug c/96907] [docs] document builtins for fputc and putc

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96907

--- Comment #1 from Andrew Pinski  ---
putc was added by g-b53b5aa509

fputc has been there since before 2003.

[Bug c++/81999] templated lambda in template context: cannot call operator() explicitly with template parameters (expected primary-expression before ...)

[bastien.penavayre at epitech dot eu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81999

bastien penavayre  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED

--- Comment #3 from bastien penavayre  ---
missing template keyword

Re: [PATCH] c++: Disable -frounding-math during manifestly constant evaluation [PR96862]

[Jason Merrill via Gcc-patches]

On 9/1/20 6:13 AM, Marc Glisse wrote:

On Tue, 1 Sep 2020, Jakub Jelinek via Gcc-patches wrote:


As discussed in the PR, fold-const.c punts on floating point constant
evaluation if the result is inexact and -frounding-math is turned on.
 /* Don't constant fold this floating point operation if the
    result may dependent upon the run-time rounding mode and
    flag_rounding_math is set, or if GCC's software emulation
    is unable to accurately represent the result.  */
 if ((flag_rounding_math
  || (MODE_COMPOSITE_P (mode) && 
!flag_unsafe_math_optimizations))

 && (inexact || !real_identical (, )))
   return NULL_TREE;
Jonathan said that we should be evaluating them anyway, e.g. conceptually
as if they are done with the default rounding mode before user had a 
chance

to change that, and e.g. in C in initializers it is also ignored.
In fact, fold-const.c for C initializers turns off various other options:

/* Perform constant folding and related simplification of initializer
  expression EXPR.  These behave identically to "fold_buildN" but ignore
  potential run-time traps and exceptions that fold must preserve.  */

#define START_FOLD_INIT \
 int saved_signaling_nans = flag_signaling_nans;\
 int saved_trapping_math = flag_trapping_math;\
 int saved_rounding_math = flag_rounding_math;\
 int saved_trapv = flag_trapv;\
 int saved_folding_initializer = folding_initializer;\
 flag_signaling_nans = 0;\
 flag_trapping_math = 0;\
 flag_rounding_math = 0;\
 flag_trapv = 0;\
 folding_initializer = 1;

#define END_FOLD_INIT \
 flag_signaling_nans = saved_signaling_nans;\
 flag_trapping_math = saved_trapping_math;\
 flag_rounding_math = saved_rounding_math;\
 flag_trapv = saved_trapv;\
 folding_initializer = saved_folding_initializer;

So, shall cxx_eval_outermost_constant_expr instead turn off all those
options (then warning_sentinel wouldn't be the right thing to use, but 
given

the 8 or how many return stmts in cxx_eval_outermost_constant_expr, we'd
need a RAII class for this.  Not sure about the folding_initializer, that
one is affecting complex multiplication and division constant evaluation
somehow.


I don't think we need to turn off flag_signaling_nans or flag_trapv. I 
think we want to turn off flag_trapping_math so we can fold 1./0 to inf 
(still in a context where folding is mandatory). Setting 
folding_initializer seems consistent with that, enabling infinite 
results in complex folding (it also forces folding of 
__builtin_constant_p, which may be redundant with 
force_folding_builtin_constant_p).


C++ says that division by zero has undefined behavior, and that an 
expression with undefined behavior is not constant, so we shouldn't fold 
1./0 to inf anyway.  The same is true of other trapping operations.  So 
clearing flag_signaling_nans, flag_trapping_math, and flag_trapv seems 
wrong for C++.  And folding_initializer seems to be used for the same 
sort of thing.



The following patch has been bootstrapped/regtested on x86_64-linux and
i686-linux, but see above, maybe we want something else.

2020-09-01  Jakub Jelinek  

PR c++/96862
* constexpr.c (cxx_eval_outermost_constant_expr): Temporarily disable
flag_rounding_math during manifestly constant evaluation.


OK.


* g++.dg/cpp1z/constexpr-96862.C: New test.

--- gcc/cp/constexpr.c.jj    2020-08-31 14:10:15.826921458 +0200
+++ gcc/cp/constexpr.c    2020-08-31 15:41:26.429964532 +0200
@@ -6680,6 +6680,8 @@ cxx_eval_outermost_constant_expr (tree t
    allow_non_constant, strict,
    manifestly_const_eval || !allow_non_constant };

+  /* Turn off -frounding-math for manifestly constant evaluation.  */
+  warning_sentinel rm (flag_rounding_math, ctx.manifestly_const_eval);
  tree type = initialized_type (t);
  tree r = t;
  bool is_consteval = false;
--- gcc/testsuite/g++.dg/cpp1z/constexpr-96862.C.jj    2020-08-31 
15:50:07.847473028 +0200
+++ gcc/testsuite/g++.dg/cpp1z/constexpr-96862.C    2020-08-31 
15:49:40.829861168 +0200

@@ -0,0 +1,20 @@
+// PR c++/96862
+// { dg-do compile { target c++17 } }
+// { dg-additional-options "-frounding-math" }
+
+constexpr double a = 0x1.0p+100 + 0x1.0p-100;
+const double b = 0x1.0p+100 + 0x1.0p-100;
+const double & = 0x1.0p+100 + 0x1.0p-100;
+static_assert (0x1.0p+100 + 0x1.0p-100 == 0x1.0p+100, "");
+
+void
+foo ()
+{
+  constexpr double d = 0x1.0p+100 + 0x1.0p-100;
+  const double e = 0x1.0p+100 + 0x1.0p-100;
+  const double & = 0x1.0p+100 + 0x1.0p-100;
+  static_assert (0x1.0p+100 + 0x1.0p-100 == 0x1.0p+100, "");
+}
+
+const double  = a;
+const double  = b;

Jakub

[Bug c++/96905] ICE with consteval function: internal compiler error: in cp_gimplify_expr, at cp/cp-gimplify.c:827

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96905

--- Comment #2 from Marek Polacek  ---
It looks like we've never cp_genericized the consteval function.

[Bug c++/96905] ICE with consteval function: internal compiler error: in cp_gimplify_expr, at cp/cp-gimplify.c:827

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96905

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 CC||jakub at gcc dot gnu.org,
   ||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1
   Last reconfirmed||2020-09-02

--- Comment #1 from Marek Polacek  ---
Confirmed.  Started with r277733 -- the introduction of consteval.

[Bug c/96907] New: [docs] document builtins for fputc and putc

[ndesaulniers at google dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96907

Bug ID: 96907
   Summary: [docs] document builtins for fputc and putc
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ndesaulniers at google dot com
CC: rv at rasmusvillemoes dot dk, segher at kernel dot 
crashing.org
  Target Milestone: ---

In https://reviews.llvm.org/D86508, I'm going through and working on improving
Clang's compatibility with GCC in terms of supported compiler __builtin_
functions.  I noticed that __has_builtin works with putc, __builtin_putc,
fputc, and __builtin_fputc in GCC.  I think putc and fputc could be added to
this page. https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html

Re: [PATCH v2] c++: Fix P0960 in member init list and array [PR92812]

[Marek Polacek via Gcc-patches]

On Wed, Sep 02, 2020 at 12:00:29PM -0400, Jason Merrill via Gcc-patches wrote:
> On 9/1/20 6:23 PM, Marek Polacek wrote:
> > This patch nails down the remaining P0960 case in PR92812:
> > 
> >struct A {
> >  int ar[2];
> >  A(): ar(1, 2) {} // doesn't work without this patch
> >};
> > 
> > Note that when the target object is not of array type, this already
> > works:
> > 
> >struct S { int x, y; };
> >struct A {
> >  S s;
> >  A(): s(1, 2) { } // OK in C++20
> >};
> > 
> > because build_new_method_call_1 takes care of the P0960 magic.
> > 
> > It proved to be quite hairy.  When the ()-list has more than one
> > element, we can always create a CONSTRUCTOR, because the code was
> > previously invalid.  But when the ()-list has just one element, it
> > gets all kinds of difficult.  As usual, we have to handle a("foo")
> > so as not to wrap the STRING_CST in a CONSTRUCTOR.  Always turning
> > x(e) into x{e} would run into trouble as in c++/93790.  Another
> > issue was what to do about x({e}): previously, this would trigger
> > "list-initializer for non-class type must not be parenthesized".
> > I figured I'd make this work in C++20, so that given
> > 
> >struct S { int x, y; };
> > 
> > you can do
> > 
> > S a[2];
> > [...]
> > A(): a({1, 2}) // initialize a[0] with {1, 2} and a[1] with {}
> > 
> > It also turned out that, as an extension, we support compound literals:
> > 
> >F (): m((S[1]) { 1, 2 })
> > 
> > so this has to keep working as before.
> > 
> > Moreover, make sure not to trigger in compiler-generated code, like
> > =default, where array assignment is allowed.
> > 
> > paren-init35.C also tests this with vector types.
> > 
> > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
> > 
> > gcc/cp/ChangeLog:
> > 
> > PR c++/92812
> > * init.c (do_paren_init_for_array_p): New.
> > (perform_member_init): Use it.  If true, build up a CONSTRUCTOR
> > from the list of arguments.
> > 
> > gcc/testsuite/ChangeLog:
> > 
> > PR c++/92812
> > * g++.dg/cpp0x/constexpr-array23.C: Adjust dg-error.
> > * g++.dg/cpp0x/initlist69.C: Likewise.
> > * g++.dg/diagnostic/mem-init1.C: Likewise.
> > * g++.dg/init/array28.C: Likewise.
> > * g++.dg/cpp2a/paren-init33.C: New test.
> > * g++.dg/cpp2a/paren-init34.C: New test.
> > * g++.dg/cpp2a/paren-init35.C: New test.
> > * g++.old-deja/g++.brendan/crash60.C: Adjust dg-error.
> > * g++.old-deja/g++.law/init10.C: Likewise.
> > * g++.old-deja/g++.other/array3.C: Likewise.
> > ---
> >   gcc/cp/init.c |  64 -
> >   .../g++.dg/cpp0x/constexpr-array23.C  |   6 +-
> >   gcc/testsuite/g++.dg/cpp0x/initlist69.C   |   4 +-
> >   gcc/testsuite/g++.dg/cpp2a/paren-init33.C | 128 ++
> >   gcc/testsuite/g++.dg/cpp2a/paren-init34.C |  25 
> >   gcc/testsuite/g++.dg/cpp2a/paren-init35.C |  21 +++
> >   gcc/testsuite/g++.dg/diagnostic/mem-init1.C   |   4 +-
> >   gcc/testsuite/g++.dg/init/array28.C   |   2 +-
> >   .../g++.old-deja/g++.brendan/crash60.C|   2 +-
> >   gcc/testsuite/g++.old-deja/g++.law/init10.C   |   2 +-
> >   gcc/testsuite/g++.old-deja/g++.other/array3.C |   3 +-
> >   11 files changed, 243 insertions(+), 18 deletions(-)
> >   create mode 100644 gcc/testsuite/g++.dg/cpp2a/paren-init33.C
> >   create mode 100644 gcc/testsuite/g++.dg/cpp2a/paren-init34.C
> >   create mode 100644 gcc/testsuite/g++.dg/cpp2a/paren-init35.C
> > 
> > diff --git a/gcc/cp/init.c b/gcc/cp/init.c
> > index d4540db3605..2edc9651ad6 100644
> > --- a/gcc/cp/init.c
> > +++ b/gcc/cp/init.c
> > @@ -756,6 +756,41 @@ maybe_warn_list_ctor (tree member, tree init)
> >  "of the underlying array", member, begin);
> >   }
> > +/* Return true if we should attempt to perform the P0960 magic when
> > +   initializing an array TYPE from a parenthesized list of values LIST.  */
> > +
> > +static bool
> > +do_paren_init_for_array_p (tree list, tree type)
> > +{
> > +  if (cxx_dialect < cxx20)
> > +/* P0960 is a C++20 feature.  */
> > +return false;
> > +
> > +  const int len = list_length (list);
> > +  if (len == 0)
> > +/* Value-initialization.  */
> > +return false;
> > +  else if (len > 1)
> > +/* If the list had more than one element, the code is ill-formed
> > +   pre-C++20, so we should attempt to ()-init.  */
> > +return true;
> > +
> > +  /* Lists with one element are trickier.  */
> > +  tree elt = TREE_VALUE (list);
> > +
> > +  /* For a("foo"), don't wrap the STRING_CST in { }.  */
> > +  if (char_type_p (TYPE_MAIN_VARIANT (TREE_TYPE (type)))
> > +  && TREE_CODE (tree_strip_any_location_wrapper (elt)) == STRING_CST)
> > +return false;
> 
> Hmm, yet another place we need to implement the special treatment of
> strings?  Can't we factor this better?  Could there be a general e.g.
> maybe_aggregate_paren_init function to turn a list into a 

[Bug target/96906] New: Failure to optimize __builtin_ia32_psubusw128 compared to 0 to __builtin_ia32_pminuw128 compared to operand

[gabravier at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96906

Bug ID: 96906
   Summary: Failure to optimize __builtin_ia32_psubusw128 compared
to 0 to __builtin_ia32_pminuw128 compared to operand
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gabravier at gmail dot com
  Target Milestone: ---

typedef int16_t v8i16 __attribute__((vector_size(16)));

v8i16 cmple_epu16(v8i16 x, v8i16 y)
{
return __builtin_ia32_psubusw128(x, y) == 0;
}

With -msse4.1, this can be optimized to `return __builtin_ia32_pminuw128(x, y)
== x;`. This transformation is done by LLVM, but not by GCC. 

PS: I'm not 100% sure this is faster but it logically should be, since the
`pminuw` version doesn't have to handle zeroing an SSE register.

Types are confused in inlining

[Gary Oblock via Gcc]

I'm not accusing inlining of having problems but I really
need to understand what's going on in this situation so I can
fix my optimization.

The error given is:
main.c: In function ‘main’:
main.c:5:1: error: non-trivial conversion in ‘ssa_name’
5 | main(void)
  | ^
struct type_t *
unsigned long
_101 = dedangled_97;
during GIMPLE pass: fixup_cfg
etc.
etc.

I put a conditional breakpoint in gdb where both
_101 and dedangled_97 were created and low
and behold they were both set to "unsigned long".
Does anybody have a clue as to how "_101" got
changed from "unsigned long" to "struct type_t *"?
Note, the later is a meaningful type in my program.
I'm trying to replace all instances of the former as
part of structure reorganization optimization.) I should
mention that this GIMPLE stmt is the one that moves
the value computed in an inlined function into the body
of code where the inling took place.

Thanks,

Gary Oblock





CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for 
the sole use of the intended recipient(s) and contains information that is 
confidential and proprietary to Ampere Computing or its subsidiaries. It is to 
be used solely for the purpose of furthering the parties' business 
relationship. Any unauthorized review, copying, or distribution of this email 
(or any attachments thereto) is strictly prohibited. If you are not the 
intended recipient, please contact the sender immediately and permanently 
delete the original and any copies of this email and any attachments thereto.

[Bug testsuite/96904] [11 regression] excess errors from old-deja.exp=g++.old-deja/g++.abi/cxa_vec.C after r11-2979

[seurer at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96904

--- Comment #2 from seurer at gcc dot gnu.org ---
Yup, thanks

Re: [PATCH] dwarf: Multi-register CFI address support

[Tom Tromey]

> "Andrew" == Andrew Stubbs  writes:

Andrew> 
http://llvm.org/docs/AMDGPUDwarfExtensionsForHeterogeneousDebugging.html#composite-location-description-operations

Thanks.  Adding that to the appropriate spot in the patch would be
great.

Tom

[Bug c++/60304] Including disables -Wconversion-null in C++ 98 mode

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60304

Jonathan Wakely  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #30 from Jonathan Wakely  ---
The testcase warns in C++98 mode (and is ill-formed in other modes) and the
macros are gone now anyway. While I'm curious why the preprocessed code in
comment 28 doesn't warn, I think we can call this fixed now.

[Bug c++/60304] Including disables -Wconversion-null in C++ 98 mode

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60304

--- Comment #29 from CVS Commits  ---
The master branch has been updated by Jonathan Wakely :

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

commit r11-2985-gf049cda373d29ea1bce4065b24cbb392cdc5b172
Author: Jonathan Wakely 
Date:   Wed Sep 2 18:51:28 2020 +0100

c++: Stop defining true, false and bool as macros in 

Since r216679 these macros have only been defined in C++98 mode, rather
than all modes. That is permitted as a GNU extension because that header
doesn't exist in the C++ standard until C++11, so we can make it do
whatever we want for C++98. But as discussed in the PR c++/60304
comments, these macros shouldn't ever be defined for C++.

This patch removes the macro definitions for C++98 too.

The new test already passed for C++98 (and the conversion is ill-formed
in C++11 and later) so this new test is arguably unnecessary.

gcc/ChangeLog:

PR c++/60304
* ginclude/stdbool.h (bool, false, true): Never define for C++.

gcc/testsuite/ChangeLog:

PR c++/60304
* g++.dg/warn/Wconversion-null-5.C: New test.

Re: [PATCH] dwarf: Multi-register CFI address support

[Andrew Stubbs]

On 02/09/2020 18:49, Tom Tromey wrote:

"Andrew" == Andrew Stubbs  writes:


Andrew> To be fair, the DWARF standard makes a similar assumption; the
Andrew> engineers working on LLVM and GDB, at AMD, have therefore invented
Andrew> some new DWARF operators that they plan to propose for a future
Andrew> standard. Only one is relevant here, however:
Andrew> DW_OP_LLVM_piece_end. (Unfortunately this clashes with an AArch64
Andrew> extension, but I think we can cope using an alias -- only GCC dumps
Andrew> will be confusing.)

Andrew> +/* AMD GCN extensions (originally for LLVM).  */
Andrew> +// This clashes with DW_OP_AARCH64_operation, so use an alias instead
Andrew> +// DW_OP (DW_OP_LLVM_piece_end, 0xea)
Andrew> +#define DW_OP_LLVM_piece_end DW_OP_AARCH64_operation
Andrew>  DW_END_OP
  
Is it too late to pick a non-clashing value?


Also, we have tried pretty hard in recent years to document all of gcc's
DWARF extensions.  Please add a link to the documentation for this one.
If there aren't docs -- I guess it would be ideal if you could write
them.  Putting them on the GCC wiki is fine.


I didn't select this number; I'm just following out-of-tree LLVM and GDB 
usage from AMD. It's allocated from the user extension range, so I 
imagine it'll enter the standard with a different number (and probably 
name).


The documentation is here:

http://llvm.org/docs/AMDGPUDwarfExtensionsForHeterogeneousDebugging.html#composite-location-description-operations

Andrew

Re: [PATCH] c++: Stop defining true, false and bool as macros in

[Nathan Sidwell]

On 9/2/20 3:13 PM, Jonathan Wakely wrote:

Since r216679 these macros have only been defined in C++98 mode, rather
than all modes. That is permitted as a GNU extension because that header
doesn't exist in the C++ standard until C++11, so we can make it do
whatever we want for C++98. But as discussed in the PR c++/60304
comments, these macros shouldn't ever be defined for C++.

This patch removes the macro definitions for C++98 too.

The new test already passed for C++98 (and the conversion is ill-formed
in C++11 and later) so this new test is arguably unnecessary.

gcc/ChangeLog:

PR c++/60304
* ginclude/stdbool.h (bool, false, true): Never define for C++.

gcc/testsuite/ChangeLog:

PR c++/60304
* g++.dg/warn/Wconversion-null-5.C: New test.


Back in 2012 Gerald argued that we should keep these macros in case
there is code depending on them. We've not been defining them in C++11
and later modes (including our default -std=gnu++14) for nearly six
years now (GCC 5.1 shipped with the change).  I'm not aware of any
reports of problems. I think it's time to stop defining them at all.

Bootstrapped and tested on powerpc64le-linux, OK for trunk?


seems reasonable, thanks



--
Nathan Sidwell

[Bug c++/96905] New: ICE with consteval function: internal compiler error: in cp_gimplify_expr, at cp/cp-gimplify.c:827

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96905

Bug ID: 96905
   Summary: ICE with consteval function: internal compiler error:
in cp_gimplify_expr, at cp/cp-gimplify.c:827
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

template
struct duration
{
  static consteval int
  gcd(int m, int n) noexcept
  {
while (m != 0 && n != 0)
{
  int rem = m % n;
  m = n;
  n = rem;
}
return m + n;
  }
};

template class duration;

Compiled with -std=gnu++20 this ICEs:

ice.C: In static member function 'static consteval int duration::gcd(int,
int) [with Rep = int]':
ice.C:7:5: internal compiler error: in cp_gimplify_expr, at
cp/cp-gimplify.c:827
7 | while (m != 0 && n != 0)
  | ^
0x603457 cp_gimplify_expr(tree_node**, gimple**, gimple**)
/home/jwakely/src/gcc/gcc/gcc/cp/cp-gimplify.c:827
0xd3f160 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/home/jwakely/src/gcc/gcc/gcc/gimplify.c:13571
0xd435c6 gimplify_stmt(tree_node**, gimple**)
/home/jwakely/src/gcc/gcc/gcc/gimplify.c:6822
0xd40e43 gimplify_statement_list
/home/jwakely/src/gcc/gcc/gcc/gimplify.c:1856
0xd40e43 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/home/jwakely/src/gcc/gcc/gcc/gimplify.c:14106
0xd435c6 gimplify_stmt(tree_node**, gimple**)
/home/jwakely/src/gcc/gcc/gcc/gimplify.c:6822
0xd44291 gimplify_bind_expr
/home/jwakely/src/gcc/gcc/gcc/gimplify.c:1411
0xd40209 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/home/jwakely/src/gcc/gcc/gcc/gimplify.c:13863
0xd4dcdc gimplify_stmt(tree_node**, gimple**)
/home/jwakely/src/gcc/gcc/gcc/gimplify.c:6822
0xd4dcdc gimplify_and_add(tree_node*, gimple**)
/home/jwakely/src/gcc/gcc/gcc/gimplify.c:486
0x8de1d3 gimplify_must_not_throw_expr
/home/jwakely/src/gcc/gcc/gcc/cp/cp-gimplify.c:577
0x8de1d3 cp_gimplify_expr(tree_node**, gimple**, gimple**)
/home/jwakely/src/gcc/gcc/gcc/cp/cp-gimplify.c:717
0xd3f160 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/home/jwakely/src/gcc/gcc/gcc/gimplify.c:13571
0xd58ac7 gimplify_stmt(tree_node**, gimple**)
/home/jwakely/src/gcc/gcc/gcc/gimplify.c:6822
0xd58ac7 gimplify_body(tree_node*, bool)
/home/jwakely/src/gcc/gcc/gcc/gimplify.c:14898
0xd58efd gimplify_function_tree(tree_node*)
/home/jwakely/src/gcc/gcc/gcc/gimplify.c:15052
0xb9f997 cgraph_node::analyze()
/home/jwakely/src/gcc/gcc/gcc/cgraphunit.c:671
0xba29b7 analyze_functions
/home/jwakely/src/gcc/gcc/gcc/cgraphunit.c:1235
0xba357d symbol_table::finalize_compilation_unit()
/home/jwakely/src/gcc/gcc/gcc/cgraphunit.c:2991
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug analyzer/96894] Analyzer assumes pointer is NULL, even if pointer was tested to be non-null before

[dmalcolm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96894

David Malcolm  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2020-09-02
 Status|UNCONFIRMED |ASSIGNED

--- Comment #1 from David Malcolm  ---
Thanks for filing this; confirmed.

[PATCH] c++: Stop defining true, false and bool as macros in

[Jonathan Wakely via Gcc-patches]

Since r216679 these macros have only been defined in C++98 mode, rather
than all modes. That is permitted as a GNU extension because that header
doesn't exist in the C++ standard until C++11, so we can make it do
whatever we want for C++98. But as discussed in the PR c++/60304
comments, these macros shouldn't ever be defined for C++.

This patch removes the macro definitions for C++98 too.

The new test already passed for C++98 (and the conversion is ill-formed
in C++11 and later) so this new test is arguably unnecessary.

gcc/ChangeLog:

PR c++/60304
* ginclude/stdbool.h (bool, false, true): Never define for C++.

gcc/testsuite/ChangeLog:

PR c++/60304
* g++.dg/warn/Wconversion-null-5.C: New test.


Back in 2012 Gerald argued that we should keep these macros in case
there is code depending on them. We've not been defining them in C++11
and later modes (including our default -std=gnu++14) for nearly six
years now (GCC 5.1 shipped with the change).  I'm not aware of any
reports of problems. I think it's time to stop defining them at all.

Bootstrapped and tested on powerpc64le-linux, OK for trunk?


commit f049cda373d29ea1bce4065b24cbb392cdc5b172
Author: Jonathan Wakely 
Date:   Wed Sep 2 18:51:28 2020

c++: Stop defining true, false and bool as macros in 

Since r216679 these macros have only been defined in C++98 mode, rather
than all modes. That is permitted as a GNU extension because that header
doesn't exist in the C++ standard until C++11, so we can make it do
whatever we want for C++98. But as discussed in the PR c++/60304
comments, these macros shouldn't ever be defined for C++.

This patch removes the macro definitions for C++98 too.

The new test already passed for C++98 (and the conversion is ill-formed
in C++11 and later) so this new test is arguably unnecessary.

gcc/ChangeLog:

PR c++/60304
* ginclude/stdbool.h (bool, false, true): Never define for C++.

gcc/testsuite/ChangeLog:

PR c++/60304
* g++.dg/warn/Wconversion-null-5.C: New test.

diff --git a/gcc/ginclude/stdbool.h b/gcc/ginclude/stdbool.h
index 72be438692f..1b56498d96f 100644
--- a/gcc/ginclude/stdbool.h
+++ b/gcc/ginclude/stdbool.h
@@ -39,13 +39,6 @@ see the files COPYING3 and COPYING.RUNTIME respectively.  If 
not, see
 /* Supporting _Bool in C++ is a GCC extension.  */
 #define _Bool  bool
 
-#if __cplusplus < 201103L
-/* Defining these macros in C++98 is a GCC extension.  */
-#define bool   bool
-#define false  false
-#define true   true
-#endif
-
 #endif /* __cplusplus */
 
 /* Signal that all the definitions are present.  */
diff --git a/gcc/testsuite/g++.dg/warn/Wconversion-null-5.C 
b/gcc/testsuite/g++.dg/warn/Wconversion-null-5.C
new file mode 100644
index 000..05980ea91ab
--- /dev/null
+++ b/gcc/testsuite/g++.dg/warn/Wconversion-null-5.C
@@ -0,0 +1,6 @@
+// PR c++/60304
+// { dg-do compile { target c++98_only } }
+// { dg-options "-Wconversion-null" }
+
+#include 
+int * foo() {return false;} // { dg-warning "converting 'false' to pointer" }

[Bug testsuite/96904] [11 regression] excess errors from old-deja.exp=g++.old-deja/g++.abi/cxa_vec.C after r11-2979

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96904

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #1 from Jonathan Wakely  ---
Should be fixed at r11-2984

[Bug middle-end/96900] [9/10/11 Regression] bogus -Warray-bounds on strlen with valid pointer obtained from just-past-the-end

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96900

--- Comment #2 from Martin Sebor  ---
The underlying cause is fold_nonarray_ctor_reference() returning a scalar zero
for apparently out-of-bounds references when determining the initializer for
s.a from [sizeof s.a].  Its caller, constant_byte_string(), then interprets
that as an array of single element initialized to zero, but it incorrectly
returns the offset from the beginning of s (i.e., 4 rather than 3 minus 3 for
sizeof s.a).   Its caller, c_strlen(), then uses the size of the one-element
initializer (for "") and the offset (positive 1) as the basis for issuing the
warning.

[Bug testsuite/96904] New: [11 regression] excess errors from old-deja.exp=g++.old-deja/g++.abi/cxa_vec.C after r11-2979

[seurer at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96904

Bug ID: 96904
   Summary: [11 regression] excess errors from
old-deja.exp=g++.old-deja/g++.abi/cxa_vec.C after
r11-2979
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

g:6bdbf0f37bda2587a4e82cbb956de7a159a397ae, r11-2979

make -k check-gcc RUNTESTFLAGS=old-deja.exp=g++.old-deja/g++.abi/cxa_vec.C
FAIL: g++.old-deja/g++.abi/cxa_vec.C  -std=gnu++98 (test for excess errors)
FAIL: g++.old-deja/g++.abi/cxa_vec.C  -std=gnu++14 (test for excess errors)
FAIL: g++.old-deja/g++.abi/cxa_vec.C  -std=gnu++17 (test for excess errors)
FAIL: g++.old-deja/g++.abi/cxa_vec.C  -std=gnu++2a (test for excess errors)
# of unexpected failures4
# of unresolved testcases   4


Executing on host:
/home/seurer/gcc/git/build/gcc-test/gcc/testsuite/g++63/../../xg++
-B/home/seurer/gcc/git/build/gcc-test/gcc/testsuite/g++63/../../
/home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.old-deja/g++.abi/cxa_vec.C   
-fdiagnostics-plain-output  -nostdinc++
-I/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/libstdc++-v3/include/powerpc64-unknown-linux-gnu
-I/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/libstdc++-v3/include
-I/home/seurer/gcc/git/gcc-test/libstdc++-v3/libsupc++
-I/home/seurer/gcc/git/gcc-test/libstdc++-v3/include/backward
-I/home/seurer/gcc/git/gcc-test/libstdc++-v3/testsuite/util -fmessage-length=0 
-std=gnu++98  -pedantic-errors -Wno-long-long   
-L/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libstdc++-v3/src/.libs

-B/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libstdc++-v3/src/.libs

-L/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libstdc++-v3/src/.libs
-B/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libitm/
-L/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libitm/.libs
-lm  -o ./cxa_vec.exe(timeout = 300)
spawn -ignore SIGHUP
/home/seurer/gcc/git/build/gcc-test/gcc/testsuite/g++63/../../xg++
-B/home/seurer/gcc/git/build/gcc-test/gcc/testsuite/g++63/../../
/home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.old-deja/g++.abi/cxa_vec.C
-fdiagnostics-plain-output -nostdinc++
-I/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/libstdc++-v3/include/powerpc64-unknown-linux-gnu
-I/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/libstdc++-v3/include
-I/home/seurer/gcc/git/gcc-test/libstdc++-v3/libsupc++
-I/home/seurer/gcc/git/gcc-test/libstdc++-v3/include/backward
-I/home/seurer/gcc/git/gcc-test/libstdc++-v3/testsuite/util -fmessage-length=0
-std=gnu++98 -pedantic-errors -Wno-long-long
-L/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libstdc++-v3/src/.libs
-B/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libstdc++-v3/src/.libs
-L/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libstdc++-v3/src/.libs
-B/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libitm/
-L/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libitm/.libs
-lm -o ./cxa_vec.exe^M
/home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.old-deja/g++.abi/cxa_vec.C: In
function 'void test0()':^M
/home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.old-deja/g++.abi/cxa_vec.C:90:12:
error: 'set_terminate' is not a member of 'std'^M
/home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.old-deja/g++.abi/cxa_vec.C: In
function 'void test1()':^M
/home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.old-deja/g++.abi/cxa_vec.C:123:12:
error: 'set_terminate' is not a member of 'std'^M
/home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.old-deja/g++.abi/cxa_vec.C: In
function 'void test2()':^M
/home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.old-deja/g++.abi/cxa_vec.C:157:12:
error: 'set_terminate' is not a member of 'std'^M
/home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.old-deja/g++.abi/cxa_vec.C: In
function 'void test3()':^M
/home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.old-deja/g++.abi/cxa_vec.C:191:12:
error: 'set_terminate' is not a member of 'std'^M
/home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.old-deja/g++.abi/cxa_vec.C: In
function 'void test4()':^M
/home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.old-deja/g++.abi/cxa_vec.C:229:12:
error: 'set_terminate' is not a member of 'std'^M
compiler exited with status 1
FAIL: g++.old-deja/g++.abi/cxa_vec.C  -std=gnu++98 (test for excess errors)
Excess errors:
/home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.old-deja/g++.abi/cxa_vec.C:90:12:
error: 'set_terminate' is not a member of 'std'
/home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.old-deja/g++.abi/cxa_vec.C:123:12:
error: 'set_terminate' is not a member of 'std'

[Bug testsuite/96903] New: [11 regression] excess errors from gcc.dg/pr89350.c after r11-2973

[seurer at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96903

Bug ID: 96903
   Summary: [11 regression] excess errors from gcc.dg/pr89350.c
after r11-2973
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

g:0c344a649d803a83ed35f629d292b98143935ffa, r11-2973

make  -k check-gcc RUNTESTFLAGS="dg.exp=gcc.dg/pr89350.c"
...
Executing on host: /home/seurer/gcc/git/build/gcc-test/gcc/xgcc
-B/home/seurer/gcc/git/build/gcc-test/gcc/
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/pr89350.c   
-fdiagnostics-plain-output   -O2 -Wall -S -o pr89350.s(timeout = 300)
spawn -ignore SIGHUP /home/seurer/gcc/git/build/gcc-test/gcc/xgcc
-B/home/seurer/gcc/git/build/gcc-test/gcc/
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/pr89350.c
-fdiagnostics-plain-output -O2 -Wall -S -o pr89350.s
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/pr89350.c: In function
'main':
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/pr89350.c:16:7: warning:
'__builtin_memcpy' writing 1 or more bytes into a region of size 0 overflows
the destination [-Wstringop-overflow=]
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/pr89350.c:6:6: note:
destination object 'buf'
FAIL: gcc.dg/pr89350.c  (test for bogus messages, line 16)
PASS: gcc.dg/pr89350.c (test for excess errors)
testcase /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/dg.exp completed in
0 seconds

=== gcc Summary ===

# of expected passes1
# of unexpected failures1

[r11-2979 Regression] FAIL: g++.old-deja/g++.abi/cxa_vec.C -std=gnu++98 (test for excess errors) on Linux/x86_64 (-m64)

[sunil.k.pandey via Gcc-patches]

On Linux/x86_64,

6bdbf0f37bda2587a4e82cbb956de7a159a397ae is the first bad commit
commit 6bdbf0f37bda2587a4e82cbb956de7a159a397ae
Author: Jonathan Wakely 
Date:   Wed Sep 2 13:27:57 2020 +0100

libstdc++: Break header cycle between  and 

caused

FAIL: g++.old-deja/g++.abi/cxa_vec.C  -std=gnu++14 (test for excess errors)
FAIL: g++.old-deja/g++.abi/cxa_vec.C  -std=gnu++17 (test for excess errors)
FAIL: g++.old-deja/g++.abi/cxa_vec.C  -std=gnu++2a (test for excess errors)
FAIL: g++.old-deja/g++.abi/cxa_vec.C  -std=gnu++98 (test for excess errors)

with GCC configured with

../../gcc/configure 
--prefix=/local/skpandey/gccwork/toolwork/gcc-bisect-master/master/r11-2979/usr 
--enable-clocale=gnu --with-system-zlib --with-demangler-in-ld 
--with-fpmath=sse --enable-languages=c,c++,fortran --enable-cet --without-isl 
--enable-libmpx x86_64-linux --disable-bootstrap

To reproduce:

$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="old-deja.exp=g++.old-deja/g++.abi/cxa_vec.C 
--target_board='unix{-m64}'"

(Please do not reply to this email, for question about this report, contact me 
at skpgkp2 at gmail dot com)

Re: [PATCH] dwarf: Multi-register CFI address support

[Tom Tromey]

> "Andrew" == Andrew Stubbs  writes:

Andrew> To be fair, the DWARF standard makes a similar assumption; the
Andrew> engineers working on LLVM and GDB, at AMD, have therefore invented
Andrew> some new DWARF operators that they plan to propose for a future
Andrew> standard. Only one is relevant here, however:
Andrew> DW_OP_LLVM_piece_end. (Unfortunately this clashes with an AArch64
Andrew> extension, but I think we can cope using an alias -- only GCC dumps
Andrew> will be confusing.)

Andrew> +/* AMD GCN extensions (originally for LLVM).  */
Andrew> +// This clashes with DW_OP_AARCH64_operation, so use an alias instead
Andrew> +// DW_OP (DW_OP_LLVM_piece_end, 0xea)
Andrew> +#define DW_OP_LLVM_piece_end DW_OP_AARCH64_operation
Andrew>  DW_END_OP
 
Is it too late to pick a non-clashing value?

Also, we have tried pretty hard in recent years to document all of gcc's
DWARF extensions.  Please add a link to the documentation for this one.
If there aren't docs -- I guess it would be ideal if you could write
them.  Putting them on the GCC wiki is fine.

Tom

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: [r11-2979 Regression] FAIL: g++.old-deja/g++.abi/cxa_vec.C -std=gnu++98 (test for excess errors) on Linux/x86_64 (-m64 -march=cascadelake)

[Jonathan Wakely via Gcc-patches]

On 02/09/20 10:22 -0700, sunil.k.pandey wrote:

On Linux/x86_64,

6bdbf0f37bda2587a4e82cbb956de7a159a397ae is the first bad commit
commit 6bdbf0f37bda2587a4e82cbb956de7a159a397ae
Author: Jonathan Wakely 
Date:   Wed Sep 2 13:27:57 2020 +0100

   libstdc++: Break header cycle between  and 

caused

FAIL: g++.old-deja/g++.abi/cxa_vec.C  -std=gnu++14 (test for excess errors)
FAIL: g++.old-deja/g++.abi/cxa_vec.C  -std=gnu++17 (test for excess errors)
FAIL: g++.old-deja/g++.abi/cxa_vec.C  -std=gnu++2a (test for excess errors)
FAIL: g++.old-deja/g++.abi/cxa_vec.C  -std=gnu++98 (test for excess errors)

with GCC configured with

../../gcc/configure 
--prefix=/local/skpandey/gccwork/toolwork/gcc-bisect-master/master/r11-2979/usr 
--enable-clocale=gnu --with-system-zlib --with-demangler-in-ld 
--with-fpmath=sse --enable-languages=c,c++,fortran --enable-cet --without-isl 
--enable-libmpx x86_64-linux --disable-bootstrap

To reproduce:

$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="old-deja.exp=g++.old-deja/g++.abi/cxa_vec.C --target_board='unix{-m64\ 
-march=cascadelake}'"

(Please do not reply to this email, for question about this report, contact me 
at skpgkp2 at gmail dot com)


The test is invalid, but worked until I changed  to stop
including .

This patch fixes it, pushed to master as obvious.


commit ce90d203cea33a4bfd4e415f601fe4486ecbb45d
Author: Jonathan Wakely 
Date:   Wed Sep 2 18:37:17 2020

testsuite: Add missing  header to testcase

This test no longer compiles because  stopped including
, so std::set_terminate is not defined.

gcc/testsuite/ChangeLog:

* g++.old-deja/g++.abi/cxa_vec.C: Include  for
std::set_terminate.

diff --git a/gcc/testsuite/g++.old-deja/g++.abi/cxa_vec.C b/gcc/testsuite/g++.old-deja/g++.abi/cxa_vec.C
index d52637281fe..de647c4eb69 100644
--- a/gcc/testsuite/g++.old-deja/g++.abi/cxa_vec.C
+++ b/gcc/testsuite/g++.old-deja/g++.abi/cxa_vec.C
@@ -15,6 +15,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 

Re: Deque rotate on current node

[François Dumont via Gcc-patches]

On 01/09/20 3:25 pm, Jonathan Wakely wrote:

On 01/09/20 14:06 +0200, François Dumont wrote:

Hi

No chance to review this small patch ?


I did review it, and I wasn't convinced it was a good change. It only
helps a particular usage pattern, and might hurt in other cases.


    I shouldn't have illustrate the target of this patch with its 
impact on the use case of an initial push_front. It is clearly not its 
purpose and I agree that it doesn't really improve this use case, it 
doesn't make it worst neither however.





I don't agree with your assertion that you use std::deque when you
only use push_front() and you use std::list if you need both
push_front() and push_back().

Ideally we'd keep the most recently reallocated node around for reuse,
and then in the situation you describe the first push_front would
allocate a new node, but if you immediately do pop_back() we wouldn't
deallocate the node. But I haven't figured out a way to do that
caching without an ABI break.
AFAIR I looked at a solution too and couldn't find any ABI compatible. 
This is why I thought this patch could be a limited answer to this.


The patch also has no tests. Are our existing tests sufficient to
cover this case? Do we want a test that verifies that we don't
allocate a new node if doing push_front() into an empty deque?


I initially thought that this patch didn't need any specific test but as 
this patch purpose is performance we could indeed add a performance 
test. This is what I've done in attachment. We can now clearly see the 
impact:


Before:

deque.cc     push_back/pop_front      1167r 1167u    
0s  528mem    0pf


After:

deque.cc     push_back/pop_front      1018r 1017u    
0s    0mem    0pf


Some CPU enhancements coming from the limitation on memory usage.

I'll do the same with push_front/pop_back if you eventually validate the 
patch.


But even if the results are great I agree that the conditions to benefit 
from it are limited. You need the deque to be empty when you push_back 
at node past-the-end position to benefit from it.


If you think that this kind of situation is too rare to deserve a 
special piece of code in deque implementation then ok, I won't bother 
you with this proposal anymore.


François


diff --git a/libstdc++-v3/include/bits/deque.tcc b/libstdc++-v3/include/bits/deque.tcc
index 7d1ec86456a..e0fb7f07bc4 100644
--- a/libstdc++-v3/include/bits/deque.tcc
+++ b/libstdc++-v3/include/bits/deque.tcc
@@ -486,6 +486,19 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
   _M_push_back_aux(const value_type& __t)
 #endif
   {
+	if (empty())
+	  {
+	// Move iterators to point to the current node begin.
+	this->_M_impl._M_start._M_cur = this->_M_impl._M_start._M_first;
+	this->_M_impl._M_finish._M_cur = this->_M_impl._M_finish._M_first;
+#if __cplusplus >= 201103L
+	emplace_back(std::forward<_Args>(__args)...);
+#else
+	push_back(__t);
+#endif
+	return;
+	  }
+
 	if (size() == max_size())
 	  __throw_length_error(
 	  __N("cannot create std::deque larger than max_size()"));
@@ -525,6 +538,19 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
   _M_push_front_aux(const value_type& __t)
 #endif
   {
+	if (empty())
+	  {
+	// Move iterators to point to the current node end.
+	this->_M_impl._M_finish._M_cur = this->_M_impl._M_finish._M_last - 1;
+	this->_M_impl._M_start._M_cur = this->_M_impl._M_start._M_last - 1;
+#if __cplusplus >= 201103L
+	emplace_front(std::forward<_Args>(__args)...);
+#else
+	push_front(__t);
+#endif
+	return;
+	  }
+
 	if (size() == max_size())
 	  __throw_length_error(
 	  __N("cannot create std::deque larger than max_size()"));
diff --git a/libstdc++-v3/testsuite/performance/23_containers/insert_erase/deque.cc b/libstdc++-v3/testsuite/performance/23_containers/insert_erase/deque.cc
new file mode 100644
index 000..1eed79d1202
--- /dev/null
+++ b/libstdc++-v3/testsuite/performance/23_containers/insert_erase/deque.cc
@@ -0,0 +1,45 @@
+// Copyright (C) 2020 Free Software Foundation, Inc.
+//
+// This file is part of the GNU ISO C++ Library.  This library is free
+// software; you can redistribute it and/or modify it under the
+// terms of the GNU General Public License as published by the
+// Free Software Foundation; either version 3, or (at your option)
+// any later version.
+
+// This library is distributed in the hope that it will be useful,
+// but WITHOUT ANY WARRANTY; without even the implied warranty of
+// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+// GNU General Public License for more details.
+
+// You should have received a copy of the GNU General Public License along
+// with this library; see the file COPYING3.  If not see
+// .
+
+
+#include 
+#include 
+#include 
+
+int main()
+{
+  using namespace __gnu_test;
+
+  time_counter time;
+  resource_counter resource;
+
+  const int nb = 2;
+  std::deque dq;
+

[r11-2979 Regression] FAIL: g++.old-deja/g++.abi/cxa_vec.C -std=gnu++98 (test for excess errors) on Linux/x86_64 (-m64 -march=cascadelake)

[sunil.k.pandey via Gcc-patches]

On Linux/x86_64,

6bdbf0f37bda2587a4e82cbb956de7a159a397ae is the first bad commit
commit 6bdbf0f37bda2587a4e82cbb956de7a159a397ae
Author: Jonathan Wakely 
Date:   Wed Sep 2 13:27:57 2020 +0100

libstdc++: Break header cycle between  and 

caused

FAIL: g++.old-deja/g++.abi/cxa_vec.C  -std=gnu++14 (test for excess errors)
FAIL: g++.old-deja/g++.abi/cxa_vec.C  -std=gnu++17 (test for excess errors)
FAIL: g++.old-deja/g++.abi/cxa_vec.C  -std=gnu++2a (test for excess errors)
FAIL: g++.old-deja/g++.abi/cxa_vec.C  -std=gnu++98 (test for excess errors)

with GCC configured with

../../gcc/configure 
--prefix=/local/skpandey/gccwork/toolwork/gcc-bisect-master/master/r11-2979/usr 
--enable-clocale=gnu --with-system-zlib --with-demangler-in-ld 
--with-fpmath=sse --enable-languages=c,c++,fortran --enable-cet --without-isl 
--enable-libmpx x86_64-linux --disable-bootstrap

To reproduce:

$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="old-deja.exp=g++.old-deja/g++.abi/cxa_vec.C 
--target_board='unix{-m64\ -march=cascadelake}'"

(Please do not reply to this email, for question about this report, contact me 
at skpgkp2 at gmail dot com)

[Bug fortran/96902] internal compiler error in gimplify_scan_omp_clauses with "!$omp target enter data" directive

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96902

Jakub Jelinek  changed:

   What|Removed |Added

  Component|libgomp |fortran
 CC||burnus at gcc dot gnu.org
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Keywords||openmp
Version|9.1.0   |10.2.1
   Last reconfirmed||2020-09-02

--- Comment #1 from Jakub Jelinek  ---
This got fixed with r11-2079-g102502e32ea4e8a75d6b252ba319d09d735d9aa7 on the
trunk.

[Bug libgomp/96902] New: internal compiler error in gimplify_scan_omp_clauses with "!$omp target enter data" directive

[michalak at ucar dot edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96902

Bug ID: 96902
   Summary: internal compiler error in gimplify_scan_omp_clauses
with "!$omp target enter data" directive
   Product: gcc
   Version: 9.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgomp
  Assignee: unassigned at gcc dot gnu.org
  Reporter: michalak at ucar dot edu
CC: jakub at gcc dot gnu.org
  Target Milestone: ---

Created attachment 49177
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49177=edit
Source file that can reproduce the ICE when compiled with gfortran and OpenMP
offload

>the exact version of GCC;

gcc version 10.1.0 (GCC)

>the system type;

Target: x86_64-pc-linux-gnu
Centos7, Intel Xeon (Sandybridge)
Thread model: posix
Supported LTO compression algorithms: zlib
OFFLOAD_TARGET_NAMES=nvptx-none

>the options given when GCC was configured/built;

Configured with: ../gcc-10.1.0/configure --enable-offload-targets=nvptx-none
--with-cuda-driver-include=/opt/nvidia/hpc_sdk/Linux_x86_64/20.7/cuda/11.0/include
--with-cuda-driver-lib=/opt/nvidia/hpc_sdk/Linux_x86_64/20.7/cuda/11.0/lib64
--disable-bootstrap --disable-multilib --enable-languages=c,c++,fortran,lto
--prefix=/home/michalak/gcc-offload/install

>the complete command line that triggers the bug;

gfortran -fopenmp -save-temps -c bug1.F90

>the compiler output (error messages, warnings, etc.);

% gfortran -fopenmp -save-temps -c bug1.F90
bug1.F90:13:0:

   13 | !$omp target enter data map(to:this)
  |
internal compiler error: in gimplify_scan_omp_clauses, at gimplify.c:9013
0xac3ad9 gimplify_scan_omp_clauses
../../gcc-10.1.0/gcc/gimplify.c:9013
0xac787e gimplify_omp_target_update
../../gcc-10.1.0/gcc/gimplify.c:12944
0xac787e gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc-10.1.0/gcc/gimplify.c:14147
0xacad26 gimplify_stmt(tree_node**, gimple**)
../../gcc-10.1.0/gcc/gimplify.c:6825
0xacb92f gimplify_bind_expr
../../gcc-10.1.0/gcc/gimplify.c:1424
0xac8a86 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc-10.1.0/gcc/gimplify.c:13809
0xacad26 gimplify_stmt(tree_node**, gimple**)
../../gcc-10.1.0/gcc/gimplify.c:6825
0xacc320 gimplify_body(tree_node*, bool)
../../gcc-10.1.0/gcc/gimplify.c:14857
0xacc825 gimplify_function_tree(tree_node*)
../../gcc-10.1.0/gcc/gimplify.c:15030
0x95d2cf cgraph_node::analyze()
../../gcc-10.1.0/gcc/cgraphunit.c:670
0x960117 analyze_functions
../../gcc-10.1.0/gcc/cgraphunit.c:1227
0x960632 symbol_table::finalize_compilation_unit()
../../gcc-10.1.0/gcc/cgraphunit.c:2974

>the preprocessed file (*.i*) that triggers the bug

The compiler does not get far enough to generate a *.i file.  I am pasting the
file "bug1.F90" below and attaching.

Thank you, -John 

--- Contents of bug1.F90 (also attached):

 module diffus

   type diffu_t
 integer nlap
 contains
   procedure :: init
   end type diffu_t

   contains

   module subroutine init ( this )
 class(diffu_t),   intent(inout) :: this
!$omp target enter data map(to:this)
   end subroutine init

 end module diffus

[Bug libstdc++/86419] codecvt::in() and out() incorrectly return ok in some cases.

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86419

--- Comment #6 from Jonathan Wakely  ---
Thanks for the analysis.

[Bug libstdc++/56109] Add light-weight ABI-compatible debug checks to standard containers

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56109

Jonathan Wakely  changed:

   What|Removed |Added

   Assignee|redi at gcc dot gnu.org|unassigned at gcc dot 
gnu.org
 Status|ASSIGNED|NEW

--- Comment #3 from Jonathan Wakely  ---
The __google_stl_* checks were added by these commits ...

Strict weak ordering checks in algos and RB trees:
8cc511b5e5c0814584644c90cb0d65d27182eddd

Invariant checks and range checks in vector:
ceeb7c3b17883b21f523ab0bef937f654b12eceb

Range checks in deque: 0681de38f1f402ad5f1fd9cf9959f304c36f7c10

Non-empty checks in vector: 2b4e2a67ff643ebdc4dababd95010699918ad9e0
Dead stores in vector dtor: e1a3b2e088d16544b6b64e483e12ae77a813a274
Invariant checks in vector: 7a058129926f4838bc1344f3674c1a35052a03e4
Range checks in vector and vstring, scribbling in cleared vstring:
13480920300b3cf5f09d408fe249c873fbef1ee0

All the range checks and non-empty checks should be already enabled by
_GLIBCXX_ASSERTIONS.

The invariant checking and strict weak order checks may be too expensive to add
to _GLIBCXX_ASSERTIONS.

We could consider adding the dead stores in the destructors to wipe out the
memory, so that subsequent accesses fail fast. Those stores should be optimised
away so will have no cost in optimised builds, but might help in -O0 builds
when debugging.

[Bug c++/96901] [11 Regression] Many libstdc++ tests FAIL on i686-linux due to a PCH FE bug

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96901

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
Created attachment 49176
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49176=edit
gcc11-pr96901.patch

Untested fix.

[Bug c++/96901] [11 Regression] Many libstdc++ tests FAIL on i686-linux due to a PCH FE bug

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96901

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Target Milestone|--- |11.0
   Priority|P3  |P1
   Last reconfirmed||2020-09-02
 Ever confirmed|0   |1

[Bug middle-end/96900] [9/10/11 Regression] bogus -Warray-bounds on strlen with valid pointer obtained from just-past-the-end

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96900

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
  Known to fail||10.2.0, 11.0, 9.3.0
Summary|bogus -Warray-bounds on |[9/10/11 Regression] bogus
   |strlen with valid pointer   |-Warray-bounds on strlen
   |obtained from   |with valid pointer obtained
   |just-past-the-end   |from just-past-the-end

--- Comment #1 from Martin Sebor  ---
The false positive was introduced in r274837:

commit 14b7950f126f84fa585e3a057940ff10d4c5b3f8
Author: Martin Sebor 
Date:   Thu Aug 22 23:09:26 2019 +

PR middle-end/91490 - bogus argument missing terminating nul warning on
strlen of a flexible array member

gcc/c-family/ChangeLog:

PR middle-end/91490
* c-common.c (braced_list_to_string): Add argument and overload.
Handle flexible length arrays and unions.

gcc/ChangeLog:

PR middle-end/91490
* builtins.c (c_strlen): Rename argument and introduce new local.
Set no-warning bit on original argument.
* expr.c (string_constant): Pass argument type to
fold_ctor_reference.
Fold empty and zero constructors into empty strings.
* gimple-fold.c (fold_nonarray_ctor_reference): Return a STRING_CST
for missing initializers.
* tree.c (build_string_literal): Handle optional argument.
* tree.h (build_string_literal): Add defaulted argument.
* gimple-ssa-warn-restrict.c (maybe_diag_access_bounds): Check
no-warning bit on original expression.

[Bug c++/96901] New: [11 Regression] Many libstdc++ tests FAIL on i686-linux due to a PCH FE bug

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96901

Bug ID: 96901
   Summary: [11 Regression] Many libstdc++ tests FAIL on
i686-linux due to a PCH FE bug
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

I'm seeing following regressions between Monday and Tuesday evening CET trunk
bootstraps:
 Running target unix
+FAIL: 20_util/bind/42593.cc (test for excess errors)
+FAIL: 20_util/bind/48698.cc (test for excess errors)
+FAIL: 20_util/is_compound/value.cc (test for excess errors)
+FAIL: 20_util/is_fundamental/value.cc (test for excess errors)
+FAIL: 20_util/is_signed/value.cc (test for excess errors)
+FAIL: 20_util/is_unsigned/value.cc (test for excess errors)
+FAIL: 20_util/unique_ptr/assign/nullptr.cc (test for excess errors)
+UNRESOLVED: 20_util/unique_ptr/assign/nullptr.cc compilation failed to produce
executable
+FAIL: 20_util/unique_ptr/cons/convertible_neg.cc (test for excess errors)
+FAIL: 20_util/unique_ptr/cons/incomplete.cc (test for excess errors)
+FAIL: 20_util/unique_ptr/cons/nullptr.cc (test for excess errors)
+UNRESOLVED: 20_util/unique_ptr/cons/nullptr.cc compilation failed to produce
executable
+FAIL:
20_util/unique_ptr/requirements/explicit_instantiation/explicit_instantiation.cc
(test for excess errors)
+FAIL: 21_strings/basic_string/allocator/wchar_t/noexcept.cc (test for excess
errors)
+FAIL: 22_locale/conversions/string/requirements/typedefs-2.cc (test for excess
errors)
+FAIL: 23_containers/list/allocator/noexcept.cc (test for excess errors)
+FAIL: 23_containers/map/modifiers/insert/2.cc (test for excess errors)
+UNRESOLVED: 23_containers/map/modifiers/insert/2.cc compilation failed to
produce executable
+FAIL: 23_containers/map/modifiers/insert/5.cc (test for excess errors)
+UNRESOLVED: 23_containers/map/modifiers/insert/5.cc compilation failed to
produce executable
+FAIL: 23_containers/multimap/modifiers/insert/2.cc (test for excess errors)
+UNRESOLVED: 23_containers/multimap/modifiers/insert/2.cc compilation failed to
produce executable
+FAIL: 23_containers/multimap/modifiers/insert/22102.cc (test for excess
errors)
+UNRESOLVED: 23_containers/multimap/modifiers/insert/22102.cc compilation
failed to produce executable
+FAIL: 23_containers/multimap/modifiers/insert/4.cc (test for excess errors)
+UNRESOLVED: 23_containers/multimap/modifiers/insert/4.cc compilation failed to
produce executable
+FAIL: 23_containers/multiset/allocator/swap.cc (test for excess errors)
+UNRESOLVED: 23_containers/multiset/allocator/swap.cc compilation failed to
produce executable
+FAIL: 23_containers/set/allocator/swap.cc (test for excess errors)
+UNRESOLVED: 23_containers/set/allocator/swap.cc compilation failed to produce
executable
+FAIL: 23_containers/unordered_map/insert/map_single_move-2.cc (test for excess
errors)
+UNRESOLVED: 23_containers/unordered_map/insert/map_single_move-2.cc
compilation failed to produce executable
+FAIL: 23_containers/unordered_map/modifiers/reserve.cc (test for excess
errors)
+UNRESOLVED: 23_containers/unordered_map/modifiers/reserve.cc compilation
failed to produce executable
+FAIL: 23_containers/vector/allocator/noexcept.cc (test for excess errors)
+FAIL: 23_containers/vector/bool/allocator/noexcept.cc (test for excess errors)
+FAIL: 25_algorithms/max/constexpr.cc (test for excess errors)
+FAIL: 25_algorithms/min/constexpr.cc (test for excess errors)
+FAIL: 26_numerics/random/cauchy_distribution/cons/default.cc (test for excess
errors)
+UNRESOLVED: 26_numerics/random/cauchy_distribution/cons/default.cc compilation
failed to produce executable
+FAIL: 26_numerics/random/extreme_value_distribution/cons/default.cc (test for
excess errors)
+UNRESOLVED: 26_numerics/random/extreme_value_distribution/cons/default.cc
compilation failed to produce executable
+FAIL: 26_numerics/random/normal_distribution/cons/default.cc (test for excess
errors)
+UNRESOLVED: 26_numerics/random/normal_distribution/cons/default.cc compilation
failed to produce executable
+FAIL: 26_numerics/random/student_t_distribution/cons/default.cc (test for
excess errors)
+UNRESOLVED: 26_numerics/random/student_t_distribution/cons/default.cc
compilation failed to produce executable
+FAIL: 28_regex/match_results/ctors/wchar_t/default.cc (test for excess errors)
+UNRESOLVED: 28_regex/match_results/ctors/wchar_t/default.cc compilation failed
to produce executable
 FAIL: 29_atomics/atomic_float/1.cc execution test
+FAIL: 30_threads/thread/adl.cc (test for excess errors)
+FAIL: experimental/net/buffer/traits.cc (test for excess errors)
+FAIL: experimental/net/execution_context/make_service.cc (test for excess
errors)
 FAIL: experimental/net/internet/resolver/ops/lookup.cc execution test
+FAIL: experimental/optional/relops/2.cc (test for excess errors)

[Bug c++/96877] Erroneous warning when default initializing function pointer types defined using std::declval

[insertinterestingnamehere at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96877

--- Comment #6 from Ian Henriksen  
---
Thanks, this makes sense. I originally got this idea from
https://stackoverflow.com/a/27489923. The discussion there implied there was
some kind of ambiguity in the standard and showed some examples where exception
specification appeared to be carried through as a part of the type in order to
satisfy the rules about assigning to function pointers with noexcept
specifiers. After revisiting their examples I've found that there's actually
inconsistency with how actual values are handled vs how values from
std::declval are handled. For example, the following is accepted as valid C++11
by both gcc and clang:


#include 
#include 

void (*function_ptr)(void *) noexcept = nullptr;
using function_type = decltype(function_ptr);

using function_type_2 = std::remove_reference())>::type;

function_type thing1;
function_type_2 thing2;
static_assert(noexcept(thing1(nullptr)), "");
static_assert(!noexcept(thing2(nullptr)), "");
static_assert(std::is_same::value, "");


See https://godbolt.org/z/YbzGM3.

It's not obvious to me what the correct behavior would be based off of the
actual wording of the standard, but this is bizarre. This behavior is
consistent across clang and the last 3 major gcc releases, but the implicit
inclusion of the exception specification in the type does not seem like
something that should be relied upon.

[Bug middle-end/96900] New: bogus -Warray-bounds on strlen with valid pointer obtained from just-past-the-end

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96900

Bug ID: 96900
   Summary: bogus -Warray-bounds on strlen with valid pointer
obtained from just-past-the-end
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

When a valid pointer into an array that has been derived from a past-the-end
pointer to a member array of an initialized constant struct is used in a call
to a string built-in like strlen GCC issues a bogus -Warray-bounds warning
indicating that the offset into the array is out of its bounds.

$ cat q.c && gcc -S -Wall q.c
struct S { char n, a[3]; };

const char a[3] = { 2, 1, 0 };
const struct S s = { 3, { 2, 1, 0 } };

int f (void)
{
  const char *p = [sizeof a];
  return __builtin_strlen (p - sizeof a);  // no warning (good)
}

int g (void)
{
  const char *p = [sizeof s.a];
  return __builtin_strlen (p - sizeof s.a);// bogus -Warray-bounds
}

q.c: In function ‘g’:
q.c:15:10: warning: offset ‘1’ outside bounds of constant string
[-Warray-bounds]
   15 |   return __builtin_strlen (p - sizeof s.a);// bogus -Warray-bounds
  |  ^
q.c:4:16: note: ‘s’ declared here
4 | const struct S s = { 3, { 2, 1, 0 } };
  |^

Re: dg-options after board/cflags

[Jose E. Marchesi via Gcc-patches]

> On Wed, Sep 2, 2020 at 8:31 AM Jose E. Marchesi via Gcc-patches
>  wrote:
>>
>>
>> Hi people!
>>
>> While adding a bpf-sim.exp to dejagnu, I noticed that the flags in
>> board/cflags were included in the final compilation line _after_ the
>> flags in the test's dg-options.
>>
>> Since the test options are more particular than the board options, I
>> would expect them to be placed after any board-defined flags, so I
>> prepared the patch below for dejagnu, which does the right thing for the
>> gcc.target/bpf testsuite.
>>
>> However:
>>
>> 1. There could be tests around that depend (erroneously) on some of
>>their dg-options to not have effect (or a different effect) because
>>they are annulled (or modified) by some flag in a board file.
>>
>> 2. This could also impact other programs using dejagnu.
>>
>> How do you people recommend to proceed?
>> Should we fix dejagnu and then fix buggy tests?
>> Or the other way around?  :-)
>>
>> diff --git a/lib/target.exp b/lib/target.exp
>> index 36ae639..f0bfe20 100644
>> --- a/lib/target.exp
>> +++ b/lib/target.exp
>> @@ -455,7 +455,7 @@ proc default_target_compile {source destfile type 
>> options} {
>> }
>> if {[regexp "^additional_flags=" $i]} {
>> regsub "^additional_flags=" $i "" tmp
>> -   append add_flags " $tmp"
>> +   append additional_flags " $tmp"
>> }
>> if {[regexp "^ldflags=" $i]} {
>> regsub "^ldflags=" $i "" tmp
>> @@ -703,6 +703,8 @@ proc default_target_compile {source destfile type 
>> options} {
>> }
>>  }
>>
>> +append add_flags " $additional_flags"
>> +
>>  verbose "doing compile"
>>
>>  set sources ""
>> @@ -728,7 +730,7 @@ proc default_target_compile {source destfile type 
>> options} {
>> append add_flags " -o $destfile"
>> }
>>  }
>> -
>> +
>>  # This is obscure: we put SOURCES at the end when building an
>>  # object, because otherwise, in some situations, libtool will
>>  # become confused about the name of the actual source file.
>
> Does your dejagnu contain
>
> commit 5256bd82343000c76bc0e48139003f90b6184347
> Author: H.J. Lu 
> Date:   Thu Feb 26 17:53:48 2015 +1100
>
> * lib/target.exp (default_target_compile): Prepend multilib_flags,
> instead of appending it.
>
> Some GCC testcases need explicit GCC options to properly run. For
> example gcc.target/i386/pr32219-1.c has -fpie specified explicitly:
>
> /* { dg-options "-O2 -fpie" } */
>
> But with multlib, eg:
> make check-gcc RUNTESTFLAGS="--target_board='unix{-fpic}'"
>
> -fpic is appended to the command line options, which overrides the command
> line options specified by dg-options.  multlib flags should be placed at
> the beginning of the command line options, not at the end.  This patch
> updates default_target_compile to prepend multilib_flags, instead of
> appending it.

Yeah, this is dejagnu master.

Your patch dealt with board/multilib_flags, but the same problem exists
for board/cflags and many other flag-containing options.

[Bug c++/93317] return type deduction fails for templated unary function

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93317

--- Comment #3 from Jonathan Wakely  ---
Oops, wrong bug number, I meant PR 64194

*** This bug has been marked as a duplicate of bug 64194 ***

[Bug c++/64194] [C++14] for function template with auto return

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64194

Jonathan Wakely  changed:

   What|Removed |Added

 CC||max.kan...@nu-cost.com

--- Comment #13 from Jonathan Wakely  ---
*** Bug 93317 has been marked as a duplicate of this bug. ***

[Bug libstdc++/92978] std::gcd mishandles mixed-signedness

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92978

--- Comment #4 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Jonathan Wakely
:

https://gcc.gnu.org/g:31782bd45331ef3006f624d7b1cc9cd11b4abb84

commit r10-8703-g31782bd45331ef3006f624d7b1cc9cd11b4abb84
Author: Jonathan Wakely 
Date:   Fri Aug 28 22:45:24 2020 +0100

libstdc++: Fix std::gcd and std::lcm for unsigned integers [PR 92978]

This fixes a bug with mixed signed and unsigned types, where converting
a negative value to the unsigned result type alters the value. The
solution is to obtain the absolute values of the arguments immediately
and to perform the actual GCD or LCM algorithm on two arguments of the
same type.

In order to operate on the most negative number without overflow when
taking its absolute, use an unsigned type for the result of the abs
operation. For example, -INT_MIN will overflow, but -(unsigned)INT_MIN
is (unsigned)INT_MAX+1U which is the correct value.

libstdc++-v3/ChangeLog:

PR libstdc++/92978
* include/std/numeric (__abs_integral): Replace with ...
(__detail::__absu): New function template that returns an
unsigned type, guaranteeing it can represent the most
negative signed value.
(__detail::__gcd, __detail::__lcm): Require arguments to
be unsigned and therefore already non-negative.
(gcd, lcm): Convert arguments to absolute value as unsigned
type before calling __detail::__gcd or __detail::__lcm.
* include/experimental/numeric (gcd, lcm): Likewise.
* testsuite/26_numerics/gcd/gcd_neg.cc: Adjust expected
errors.
* testsuite/26_numerics/lcm/lcm_neg.cc: Likewise.
* testsuite/26_numerics/gcd/92978.cc: New test.
* testsuite/26_numerics/lcm/92978.cc: New test.
* testsuite/experimental/numeric/92978.cc: New test.

(cherry picked from commit 82db1a42e9254c9009bbf8ac01366da4d1ab6df5)

Re: dg-options after board/cflags

[H.J. Lu via Gcc-patches]

On Wed, Sep 2, 2020 at 8:31 AM Jose E. Marchesi via Gcc-patches
 wrote:
>
>
> Hi people!
>
> While adding a bpf-sim.exp to dejagnu, I noticed that the flags in
> board/cflags were included in the final compilation line _after_ the
> flags in the test's dg-options.
>
> Since the test options are more particular than the board options, I
> would expect them to be placed after any board-defined flags, so I
> prepared the patch below for dejagnu, which does the right thing for the
> gcc.target/bpf testsuite.
>
> However:
>
> 1. There could be tests around that depend (erroneously) on some of
>their dg-options to not have effect (or a different effect) because
>they are annulled (or modified) by some flag in a board file.
>
> 2. This could also impact other programs using dejagnu.
>
> How do you people recommend to proceed?
> Should we fix dejagnu and then fix buggy tests?
> Or the other way around?  :-)
>
> diff --git a/lib/target.exp b/lib/target.exp
> index 36ae639..f0bfe20 100644
> --- a/lib/target.exp
> +++ b/lib/target.exp
> @@ -455,7 +455,7 @@ proc default_target_compile {source destfile type 
> options} {
> }
> if {[regexp "^additional_flags=" $i]} {
> regsub "^additional_flags=" $i "" tmp
> -   append add_flags " $tmp"
> +   append additional_flags " $tmp"
> }
> if {[regexp "^ldflags=" $i]} {
> regsub "^ldflags=" $i "" tmp
> @@ -703,6 +703,8 @@ proc default_target_compile {source destfile type 
> options} {
> }
>  }
>
> +append add_flags " $additional_flags"
> +
>  verbose "doing compile"
>
>  set sources ""
> @@ -728,7 +730,7 @@ proc default_target_compile {source destfile type 
> options} {
> append add_flags " -o $destfile"
> }
>  }
> -
> +
>  # This is obscure: we put SOURCES at the end when building an
>  # object, because otherwise, in some situations, libtool will
>  # become confused about the name of the actual source file.

Does your dejagnu contain

commit 5256bd82343000c76bc0e48139003f90b6184347
Author: H.J. Lu 
Date:   Thu Feb 26 17:53:48 2015 +1100

* lib/target.exp (default_target_compile): Prepend multilib_flags,
instead of appending it.

Some GCC testcases need explicit GCC options to properly run. For
example gcc.target/i386/pr32219-1.c has -fpie specified explicitly:

/* { dg-options "-O2 -fpie" } */

But with multlib, eg:
make check-gcc RUNTESTFLAGS="--target_board='unix{-fpic}'"

-fpic is appended to the command line options, which overrides the command
line options specified by dg-options.  multlib flags should be placed at
the beginning of the command line options, not at the end.  This patch
updates default_target_compile to prepend multilib_flags, instead of
appending it.


-- 
H.J.

Re: [committed] libstdc++: Fix std::gcd and std::lcm for unsigned integers [PR 92978]

[Jonathan Wakely via Gcc-patches]

On 28/08/20 23:11 +0100, Jonathan Wakely wrote:

This fixes a bug with mixed signed and unsigned types, where converting
a negative value to the unsigned result type alters the value. The
solution is to obtain the absolute values of the arguments immediately
and to perform the actual GCD or LCM algorithm on two arguments of the
same type.

In order to operate on the most negative number without overflow when
taking its absolute, use an unsigned type for the result of the abs
operation. For example, -INT_MIN will overflow, but -(unsigned)INT_MIN
is (unsigned)INT_MAX+1U which is the correct value.

libstdc++-v3/ChangeLog:

PR libstdc++/92978
* include/std/numeric (__abs_integral): Replace with ...
(__detail::__absu): New function template that returns an
unsigned type, guaranteeing it can represent the most
negative signed value.
(__detail::__gcd, __detail::__lcm): Require arguments to
be unsigned and therefore already non-negative.
(gcd, lcm): Convert arguments to absolute value as unsigned
type before calling __detail::__gcd or __detail::__lcm.
* include/experimental/numeric (gcd, lcm): Likewise.
* testsuite/26_numerics/gcd/gcd_neg.cc: Adjust expected
errors.
* testsuite/26_numerics/lcm/lcm_neg.cc: Likewise.
* testsuite/26_numerics/gcd/92978.cc: New test.
* testsuite/26_numerics/lcm/92978.cc: New test.
* testsuite/experimental/numeric/92978.cc: New test.

Tested powerpc64le-linux. Committed to trunk.



[snip]


diff --git a/libstdc++-v3/testsuite/experimental/numeric/92978.cc 
b/libstdc++-v3/testsuite/experimental/numeric/92978.cc
new file mode 100644
index 000..8408fd4d9ce
--- /dev/null
+++ b/libstdc++-v3/testsuite/experimental/numeric/92978.cc
@@ -0,0 +1,48 @@
+// Copyright (C) 2020 Free Software Foundation, Inc.
+//
+// This file is part of the GNU ISO C++ Library.  This library is free
+// software; you can redistribute it and/or modify it under the
+// terms of the GNU General Public License as published by the
+// Free Software Foundation; either version 3, or (at your option)
+// any later version.
+
+// This library is distributed in the hope that it will be useful,
+// but WITHOUT ANY WARRANTY; without even the implied warranty of
+// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+// GNU General Public License for more details.
+
+// You should have received a copy of the GNU General Public License along
+// with this library; see the file COPYING3.  If not see
+// .
+
+// { dg-do compile { target c++14 } }
+
+#include 
+#include 
+
+void
+test01()
+{
+  // PR libstdc++/92978
+  static_assert( std::experimental::gcd(-120, 10U) == 10,
+  "mixed signed/unsigned" );
+  static_assert( std::experimental::gcd(120U, -10) == 10,
+  "mixed signed/unsigned" );
+
+  static_assert( std::lcm(-42, 21U) == 42U );


This test is supposed to be usingthe experimental functions, but this
calls std::lcm (and so the test fails if run as C++14).

Fixed with the attached patch, committed to trunk.

commit c71644776f4e8477289a4de16239dbb420db6945
Author: Jonathan Wakely 
Date:   Wed Sep 2 17:20:37 2020

libstdc++: Fix test to use correct function

This was copied from a test for std::lcm but I forgot to change one of
the calls to use the experimental version of the function.

libstdc++-v3/ChangeLog:

PR libstdc++/92978
* testsuite/experimental/numeric/92978.cc: Use experimental::lcm
not std::lcm.

diff --git a/libstdc++-v3/testsuite/experimental/numeric/92978.cc b/libstdc++-v3/testsuite/experimental/numeric/92978.cc
index 8408fd4d9ce..e2a4b1adefa 100644
--- a/libstdc++-v3/testsuite/experimental/numeric/92978.cc
+++ b/libstdc++-v3/testsuite/experimental/numeric/92978.cc
@@ -29,7 +29,7 @@ test01()
   static_assert( std::experimental::gcd(120U, -10) == 10,
   "mixed signed/unsigned" );
 
-  static_assert( std::lcm(-42, 21U) == 42U );
+  static_assert( std::experimental::lcm(-42, 21U) == 42U );
 }
 
 void

[Bug libstdc++/92978] std::gcd mishandles mixed-signedness

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92978

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Jonathan Wakely :

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

commit r11-2983-gc71644776f4e8477289a4de16239dbb420db6945
Author: Jonathan Wakely 
Date:   Wed Sep 2 17:20:37 2020 +0100

libstdc++: Fix test to use correct function

This was copied from a test for std::lcm but I forgot to change one of
the calls to use the experimental version of the function.

libstdc++-v3/ChangeLog:

PR libstdc++/92978
* testsuite/experimental/numeric/92978.cc: Use experimental::lcm
not std::lcm.

[Bug target/69194] [5/6 Regression] internal compiler error: in extract_insn, at recog.c:2286

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69194

Jonathan Wakely  changed:

   What|Removed |Added

 CC||max.kan...@nu-cost.com

--- Comment #7 from Jonathan Wakely  ---
*** Bug 93317 has been marked as a duplicate of this bug. ***

[Bug c++/93317] return type deduction fails for templated unary function

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93317

Jonathan Wakely  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|NEW |RESOLVED

--- Comment #2 from Jonathan Wakely  ---
Fixed on trunk by r11-2420, so this looks like a dup of PR 69194.

*** This bug has been marked as a duplicate of bug 69194 ***

[Bug c++/60304] Including disables -Wconversion-null in C++ 98 mode

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60304

Jonathan Wakely  changed:

   What|Removed |Added

 CC||dmalcolm at gcc dot gnu.org

--- Comment #28 from Jonathan Wakely  ---
However, the preprocessed version doesn't warn even with current trunk:

# 1 "b.C"
# 1 "/home/jwakely/gcc/9/lib/gcc/x86_64-pc-linux-gnu/9.3.1/include/stdbool.h" 1
3 4
# 2 "b.C" 2
int * foo() {return 
# 2 "b.C" 3 4
   false
# 2 "b.C"
;}

Dave, any idea why your fix for PR 71302 causes us to warn for the following,
but not when it's already been preprocessed (as above)?

#include 
int* foo() {return false;}

It's not a big deal, since we do issue the expected warning during normal
compilation, and I'm going to try to remove the macros from  anyway.

Re: [PATCH] c++: Fix P0960 in member init list and array [PR92812]

[Jason Merrill via Gcc-patches]

On 9/1/20 6:23 PM, Marek Polacek wrote:

This patch nails down the remaining P0960 case in PR92812:

   struct A {
 int ar[2];
 A(): ar(1, 2) {} // doesn't work without this patch
   };

Note that when the target object is not of array type, this already
works:

   struct S { int x, y; };
   struct A {
 S s;
 A(): s(1, 2) { } // OK in C++20
   };

because build_new_method_call_1 takes care of the P0960 magic.

It proved to be quite hairy.  When the ()-list has more than one
element, we can always create a CONSTRUCTOR, because the code was
previously invalid.  But when the ()-list has just one element, it
gets all kinds of difficult.  As usual, we have to handle a("foo")
so as not to wrap the STRING_CST in a CONSTRUCTOR.  Always turning
x(e) into x{e} would run into trouble as in c++/93790.  Another
issue was what to do about x({e}): previously, this would trigger
"list-initializer for non-class type must not be parenthesized".
I figured I'd make this work in C++20, so that given

   struct S { int x, y; };

you can do

S a[2];
[...]
A(): a({1, 2}) // initialize a[0] with {1, 2} and a[1] with {}

It also turned out that, as an extension, we support compound literals:

   F (): m((S[1]) { 1, 2 })

so this has to keep working as before.

Moreover, make sure not to trigger in compiler-generated code, like
=default, where array assignment is allowed.

paren-init35.C also tests this with vector types.

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?

gcc/cp/ChangeLog:

PR c++/92812
* init.c (do_paren_init_for_array_p): New.
(perform_member_init): Use it.  If true, build up a CONSTRUCTOR
from the list of arguments.

gcc/testsuite/ChangeLog:

PR c++/92812
* g++.dg/cpp0x/constexpr-array23.C: Adjust dg-error.
* g++.dg/cpp0x/initlist69.C: Likewise.
* g++.dg/diagnostic/mem-init1.C: Likewise.
* g++.dg/init/array28.C: Likewise.
* g++.dg/cpp2a/paren-init33.C: New test.
* g++.dg/cpp2a/paren-init34.C: New test.
* g++.dg/cpp2a/paren-init35.C: New test.
* g++.old-deja/g++.brendan/crash60.C: Adjust dg-error.
* g++.old-deja/g++.law/init10.C: Likewise.
* g++.old-deja/g++.other/array3.C: Likewise.
---
  gcc/cp/init.c |  64 -
  .../g++.dg/cpp0x/constexpr-array23.C  |   6 +-
  gcc/testsuite/g++.dg/cpp0x/initlist69.C   |   4 +-
  gcc/testsuite/g++.dg/cpp2a/paren-init33.C | 128 ++
  gcc/testsuite/g++.dg/cpp2a/paren-init34.C |  25 
  gcc/testsuite/g++.dg/cpp2a/paren-init35.C |  21 +++
  gcc/testsuite/g++.dg/diagnostic/mem-init1.C   |   4 +-
  gcc/testsuite/g++.dg/init/array28.C   |   2 +-
  .../g++.old-deja/g++.brendan/crash60.C|   2 +-
  gcc/testsuite/g++.old-deja/g++.law/init10.C   |   2 +-
  gcc/testsuite/g++.old-deja/g++.other/array3.C |   3 +-
  11 files changed, 243 insertions(+), 18 deletions(-)
  create mode 100644 gcc/testsuite/g++.dg/cpp2a/paren-init33.C
  create mode 100644 gcc/testsuite/g++.dg/cpp2a/paren-init34.C
  create mode 100644 gcc/testsuite/g++.dg/cpp2a/paren-init35.C

diff --git a/gcc/cp/init.c b/gcc/cp/init.c
index d4540db3605..2edc9651ad6 100644
--- a/gcc/cp/init.c
+++ b/gcc/cp/init.c
@@ -756,6 +756,41 @@ maybe_warn_list_ctor (tree member, tree init)
 "of the underlying array", member, begin);
  }
  
+/* Return true if we should attempt to perform the P0960 magic when

+   initializing an array TYPE from a parenthesized list of values LIST.  */
+
+static bool
+do_paren_init_for_array_p (tree list, tree type)
+{
+  if (cxx_dialect < cxx20)
+/* P0960 is a C++20 feature.  */
+return false;
+
+  const int len = list_length (list);
+  if (len == 0)
+/* Value-initialization.  */
+return false;
+  else if (len > 1)
+/* If the list had more than one element, the code is ill-formed
+   pre-C++20, so we should attempt to ()-init.  */
+return true;
+
+  /* Lists with one element are trickier.  */
+  tree elt = TREE_VALUE (list);
+
+  /* For a("foo"), don't wrap the STRING_CST in { }.  */
+  if (char_type_p (TYPE_MAIN_VARIANT (TREE_TYPE (type)))
+  && TREE_CODE (tree_strip_any_location_wrapper (elt)) == STRING_CST)
+return false;


Hmm, yet another place we need to implement the special treatment of 
strings?  Can't we factor this better?  Could there be a general e.g. 
maybe_aggregate_paren_init function to turn a list into a CONSTRUCTOR 
that's used in various places?



+  /* Don't trigger in compiler-generated code for = default.  */
+  if (current_function_decl && DECL_DEFAULTED_FN (current_function_decl))
+return false;
+
+  /* Handle non-standard extensions like compound literals.  */
+  return !same_type_ignoring_top_level_qualifiers_p (type, TREE_TYPE (elt));


Isn't the defaulted function case caught by the same-type check?

Jason

[Bug c++/60304] Including disables -Wconversion-null in C++ 98 mode

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60304

--- Comment #27 from Jonathan Wakely  ---
The original testcase gets a warning even for -std=c++98 now, thanks to
dmalcolm's r268589 (included in GCC 9.1).

[committed] MSP430: Fix -mlarge documentation to indicate size_t is a 20-bit type

[Jozef Lawrynowicz]

Minor documentation fix, committed as obvious.
>From 0edc2c1a2445dffc7b839d833263c78f7cab01dc Mon Sep 17 00:00:00 2001
From: Jozef Lawrynowicz 
Date: Wed, 2 Sep 2020 16:34:43 +0100
Subject: [PATCH] MSP430: Fix -mlarge documentation to indicate size_t is a
 20-bit type

gcc/ChangeLog:

* doc/invoke.texi (MSP430 options): Fix -mlarge description to
indicate size_t is a 20-bit type.
---
 gcc/doc/invoke.texi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 5d29a7fa23c..bca8c856dc8 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -24777,7 +24777,7 @@ any scripts that would be selected by the 
@option{-mmcu=} option.
 
 @item -mlarge
 @opindex mlarge
-Use large-model addressing (20-bit pointers, 32-bit @code{size_t}).
+Use large-model addressing (20-bit pointers, 20-bit @code{size_t}).
 
 @item -msmall
 @opindex msmall
-- 
2.28.0

[Bug libstdc++/96851] operator< on std::array does not work in constexpr, for sizeof(T) == 1, and N > 1

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96851

Jonathan Wakely  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

--- Comment #7 from Jonathan Wakely  ---
Fixed for GCC 10.3, thanks for the report.

Re: [committed] libstdc++: Fix three-way comparison for std::array [PR 96851]

[Jonathan Wakely via Gcc-patches]

On 02/09/20 15:51 +0100, Jonathan Wakely wrote:

The spaceship operator for std::array uses memcmp when the
__is_byte trait is true, but memcmp isn't usable in
constexpr contexts. Also, memcmp should only be used for unsigned byte
types, because it gives the wrong answer for signed chars with negative
values.

We can simply check std::is_constant_evaluated() so that we don't use
memcmp during constant evaluation.

To fix the problem of using memcmp for inappropriate types, this patch
adds new __is_memcmp_ordered and __is_memcmp_ordered_with traits. These
say whether using memcmp will give the right answer for ordering
operations such as lexicographical_compare and three-way comparisons.
The new traits can be used in several places, and can also be used to
implement my suggestion in PR 93059 comment 37 to use memcmp for
unsigned integers larger than one byte on big endian targets.

libstdc++-v3/ChangeLog:

PR libstdc++/96851
* include/bits/cpp_type_traits.h (__is_memcmp_ordered):
New trait that says if memcmp can be used for ordering.
(__is_memcmp_ordered_with): Likewise, for two types.
* include/bits/deque.tcc (__lex_cmp_dit): Use new traits
instead of __is_byte and __numeric_traits.
(__lexicographical_compare_aux1): Likewise.
* include/bits/ranges_algo.h (__lexicographical_compare_fn):
Likewise.
* include/bits/stl_algobase.h (__lexicographical_compare_aux1)
(__is_byte_iter): Likewise.
* include/std/array (operator<=>): Likewise. Only use memcmp
when std::is_constant_evaluated() is false.
* testsuite/23_containers/array/comparison_operators/96851.cc:
New test.
* testsuite/23_containers/array/tuple_interface/get_neg.cc:
Adjust dg-error line numbers.


For the gcc-10 branch I've committed the attached backport, which adds
the new traits and uses them everywhere appropriate, but doesn't
extend the memcmp optimisation to all unsigned integers for big endian
targets.

Tested x86_64-linux. Committed to gcc-10.

commit 33c34c4c2466fd4fd050ed8e2d5996c35ebdeef6
Author: Jonathan Wakely 
Date:   Wed Sep 2 15:17:24 2020

libstdc++: Fix three-way comparison for std::array [PR 96851]

The spaceship operator for std::array uses memcmp when the
__is_byte trait is true, but memcmp isn't usable in
constexpr contexts. Also, memcmp should only be used for unsigned byte
types, because it gives the wrong answer for signed chars with negative
values.

We can simply check std::is_constant_evaluated() so that we don't use
memcmp during constant evaluation.

To fix the problem of using memcmp for inappropriate types, this patch
adds new __is_memcmp_ordered and __is_memcmp_ordered_with traits. These
say whether using memcmp will give the right answer for ordering
operations such as lexicographical_compare and three-way comparisons.
The new traits can be used in several places.

Unlike the trunk commit this was backported from, this commit for the
branch doesn't extend the memcmp optimisations to all unsigned integers
on big endian targets. Only narrow character types and std::byte will
use memcmp.

libstdc++-v3/ChangeLog:

PR libstdc++/96851
* include/bits/cpp_type_traits.h (__is_memcmp_ordered):
New trait that says if memcmp can be used for ordering.
(__is_memcmp_ordered_with): Likewise, for two types.
* include/bits/ranges_algo.h (__lexicographical_compare_fn):
Use new traits instead of __is_byte and __numeric_traits.
* include/bits/stl_algobase.h (__lexicographical_compare_aux1)
(__is_byte_iter): Likewise.
* include/std/array (operator<=>): Likewise. Only use memcmp
when std::is_constant_evaluated() is false.
* testsuite/23_containers/array/comparison_operators/96851.cc:
New test.
* testsuite/23_containers/array/tuple_interface/get_neg.cc:
Adjust dg-error line numbers.

(cherry picked from commit 2f983fa69005b603ea1758a013b4134d5b0f24a8)

diff --git a/libstdc++-v3/include/bits/cpp_type_traits.h b/libstdc++-v3/include/bits/cpp_type_traits.h
index 979ad9c2c69..ca83f590eb4 100644
--- a/libstdc++-v3/include/bits/cpp_type_traits.h
+++ b/libstdc++-v3/include/bits/cpp_type_traits.h
@@ -482,6 +482,50 @@ __INT_N(__GLIBCXX_TYPE_INT_N_3)
 : __is_nonvolatile_trivially_copyable<_Tp>
 { };
 
+  // Whether memcmp can be used to determine ordering for a type
+  // e.g. in std::lexicographical_compare or three-way comparisons.
+  // True for unsigned narrow character types (and std::byte).
+  template::__value>
+struct __is_memcmp_ordered
+{
+  static const bool __value = _Tp(-1) > _Tp(1); // is unsigned
+};
+
+  template
+struct __is_memcmp_ordered<_Tp, false>
+{
+  static const bool __value = false;
+};

Re: [committed] libstdc++: Break header cycle between and

[Jonathan Wakely via Gcc-patches]

On 02/09/20 14:15 +0100, Jonathan Wakely wrote:

The  and  headers each include each other, which makes
building them as header-units "exciting". The  header only needs
the definition of std::exception (in order to derive from it) which is
already in its own header, so just include that.

libstdc++-v3/ChangeLog:

* include/bits/stl_iterator.h: Include 
for definitions of __try, __catch and __throw_exception_again.
(counted_iterator::operator++(int)): Use __throw_exception_again
instead of throw.
* libsupc++/new: Include  not .
* libsupc++/new_opvnt.cc: Include .
* testsuite/18_support/destroying_delete.cc: Include
 for std::is_same_v definition.
* testsuite/20_util/variant/index_type.cc: Qualify size_t.

Tested powerpc64le-linux. Committed to trunk.




commit 6bdbf0f37bda2587a4e82cbb956de7a159a397ae
Author: Jonathan Wakely 
Date:   Wed Sep 2 13:27:57 2020

   libstdc++: Break header cycle between  and 

   The  and  headers each include each other, which makes
   building them as header-units "exciting". The  header only needs
   the definition of std::exception (in order to derive from it) which is
   already in its own header, so just include that.

   libstdc++-v3/ChangeLog:

   * include/bits/stl_iterator.h: Include 
   for definitions of __try, __catch and __throw_exception_again.
   (counted_iterator::operator++(int)): Use __throw_exception_again
   instead of throw.
   * libsupc++/new: Include  not .
   * libsupc++/new_opvnt.cc: Include .
   * testsuite/18_support/destroying_delete.cc: Include
for std::is_same_v definition.
   * testsuite/20_util/variant/index_type.cc: Qualify size_t.

diff --git a/libstdc++-v3/include/bits/stl_iterator.h 
b/libstdc++-v3/include/bits/stl_iterator.h
index f0cf4c55c09..da740e3732e 100644
--- a/libstdc++-v3/include/bits/stl_iterator.h
+++ b/libstdc++-v3/include/bits/stl_iterator.h
@@ -79,6 +79,7 @@
#if __cplusplus > 201703L
# include 
# include 
+# include 
# include 
#endif

@@ -2062,7 +2063,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
return _M_current++;
  } __catch(...) {
++_M_length;
-   throw;
+   __throw_exception_again;
  }

  }


I've also changed the line above on the gcc-10 branch. Even though
both GCC and Clang accept it with -fno-exceptions (rather
mysteriously) it should be using the __throw_exception_again macro
instead.

commit 7eb76b3b1721247bc2c9ab6a41c1655158ed3411
Author: Jonathan Wakely 
Date:   Wed Sep 2 14:50:34 2020

libstdc++: Use __throw_exception_again macro for -fno-exceptions

libstdc++-v3/ChangeLog:

* include/bits/stl_iterator.h (counted_iterator::operator++(int)):
Use __throw_exception_again macro.

diff --git a/libstdc++-v3/include/bits/stl_iterator.h b/libstdc++-v3/include/bits/stl_iterator.h
index 19b1d53f781..d6bb085b3c6 100644
--- a/libstdc++-v3/include/bits/stl_iterator.h
+++ b/libstdc++-v3/include/bits/stl_iterator.h
@@ -2013,7 +2013,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 	return _M_current++;
 	  } __catch(...) {
 	++_M_length;
-	throw;
+	__throw_exception_again;
 	  }
 
   }

[Bug libstdc++/96851] operator< on std::array does not work in constexpr, for sizeof(T) == 1, and N > 1

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96851

--- Comment #6 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Jonathan Wakely
:

https://gcc.gnu.org/g:33c34c4c2466fd4fd050ed8e2d5996c35ebdeef6

commit r10-8702-g33c34c4c2466fd4fd050ed8e2d5996c35ebdeef6
Author: Jonathan Wakely 
Date:   Wed Sep 2 15:17:24 2020 +0100

libstdc++: Fix three-way comparison for std::array [PR 96851]

The spaceship operator for std::array uses memcmp when the
__is_byte trait is true, but memcmp isn't usable in
constexpr contexts. Also, memcmp should only be used for unsigned byte
types, because it gives the wrong answer for signed chars with negative
values.

We can simply check std::is_constant_evaluated() so that we don't use
memcmp during constant evaluation.

To fix the problem of using memcmp for inappropriate types, this patch
adds new __is_memcmp_ordered and __is_memcmp_ordered_with traits. These
say whether using memcmp will give the right answer for ordering
operations such as lexicographical_compare and three-way comparisons.
The new traits can be used in several places.

Unlike the trunk commit this was backported from, this commit for the
branch doesn't extend the memcmp optimisations to all unsigned integers
on big endian targets. Only narrow character types and std::byte will
use memcmp.

libstdc++-v3/ChangeLog:

PR libstdc++/96851
* include/bits/cpp_type_traits.h (__is_memcmp_ordered):
New trait that says if memcmp can be used for ordering.
(__is_memcmp_ordered_with): Likewise, for two types.
* include/bits/ranges_algo.h (__lexicographical_compare_fn):
Use new traits instead of __is_byte and __numeric_traits.
* include/bits/stl_algobase.h (__lexicographical_compare_aux1)
(__is_byte_iter): Likewise.
* include/std/array (operator<=>): Likewise. Only use memcmp
when std::is_constant_evaluated() is false.
* testsuite/23_containers/array/comparison_operators/96851.cc:
New test.
* testsuite/23_containers/array/tuple_interface/get_neg.cc:
Adjust dg-error line numbers.

(cherry picked from commit 2f983fa69005b603ea1758a013b4134d5b0f24a8)

[Bug c++/60304] Including disables -Wconversion-null in C++ 98 mode

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60304

--- Comment #26 from Jonathan Wakely  ---
(In reply to Manuel López-Ibáñez from comment #22)
> My point is that the fix cannot be only limited to tweaking stdbool.h, as
> long as any C++ mode still defines false as a macro.

As I said in comment 18, C++ programs can't do that. Ever.

I'm going to try again to remove those macros from  for C++ ...

dg-options after board/cflags

[Jose E. Marchesi via Gcc-patches]

Hi people!

While adding a bpf-sim.exp to dejagnu, I noticed that the flags in
board/cflags were included in the final compilation line _after_ the
flags in the test's dg-options.

Since the test options are more particular than the board options, I
would expect them to be placed after any board-defined flags, so I
prepared the patch below for dejagnu, which does the right thing for the
gcc.target/bpf testsuite.

However:

1. There could be tests around that depend (erroneously) on some of
   their dg-options to not have effect (or a different effect) because
   they are annulled (or modified) by some flag in a board file.

2. This could also impact other programs using dejagnu.

How do you people recommend to proceed?
Should we fix dejagnu and then fix buggy tests?
Or the other way around?  :-)

diff --git a/lib/target.exp b/lib/target.exp
index 36ae639..f0bfe20 100644
--- a/lib/target.exp
+++ b/lib/target.exp
@@ -455,7 +455,7 @@ proc default_target_compile {source destfile type options} {
}
if {[regexp "^additional_flags=" $i]} {
regsub "^additional_flags=" $i "" tmp
-   append add_flags " $tmp"
+   append additional_flags " $tmp"
}
if {[regexp "^ldflags=" $i]} {
regsub "^ldflags=" $i "" tmp
@@ -703,6 +703,8 @@ proc default_target_compile {source destfile type options} {
}
 }
 
+append add_flags " $additional_flags"
+
 verbose "doing compile"
 
 set sources ""
@@ -728,7 +730,7 @@ proc default_target_compile {source destfile type options} {
append add_flags " -o $destfile"
}
 }
-
+
 # This is obscure: we put SOURCES at the end when building an
 # object, because otherwise, in some situations, libtool will
 # become confused about the name of the actual source file.

[Bug tree-optimization/96897] Failure to optimize sub+not involving constant to add

[gabravier at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96897

Gabriel Ravier  changed:

   What|Removed |Added

Summary|Failure to optimize |Failure to optimize sub+not
   |not+not+dec+and+not to  |involving constant to add
   |add+or  |

--- Comment #2 from Gabriel Ravier  ---
Better test case (I'd assume) :

int f(int x)
{
return ~(constant - x);
}

which should be optimizable to `x + ~constant`.

[Bug libstdc++/96851] operator< on std::array does not work in constexpr, for sizeof(T) == 1, and N > 1

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96851

--- Comment #5 from Jonathan Wakely  ---
(In reply to milasudril from comment #4)
> Actually, I did not even try without the c++20 flag:

That's irrelevant. The bug happens when using c++20, so the bug report should
include the options necessary to reproduce it. Whether you tried without c++20
is irrelevant, what matters is that you *did* use c++20 when encountering the
bug. So the bug report should say so.

> Thus I wouldn't expect it to work in C++17 or below. If it did, it could be
> considered a bug.

Yes, but that doesn't mean you don't need to say which options you used when
encountering the bug.

People trying to reproduce the bug should not need to guess how to reproduce
the bug. *I* know it needs C++20 and *you* know it needs C++20, but knowing the
details of each C++ feature should not be necessary for other people to triage
bug reports or try to reproduce them.

[Bug libstdc++/96851] operator< on std::array does not work in constexpr, for sizeof(T) == 1, and N > 1

[milasudril at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96851

--- Comment #4 from milasudril at gmail dot com ---
Actually, I did not even try without the c++20 flag:

template< class T, std::size_t N >
bool operator<( const std::array& lhs,
const std::array& rhs );
(3) (until C++20)

...

template< class T, std::size_t N >
constexpr /* see below */ operator<=>( const std::array& lhs,
   const std::array& rhs );
(7) (since C++20)

https://en.cppreference.com/w/cpp/container/array/operator_cmp

Thus I wouldn't expect it to work in C++17 or below. If it did, it could be
considered a bug.

[Patch] Fortran: Fixes for pointer function call as variable (PR96896)

[Tobias Burnus]

During some discussion such an example as attached came up:
  f() = 0.0
where 'f' is a function which returns a pointer to an array.
This gets handled as
  _F.D0 => f()
  _F.D0 = 0.0
However, the first line did fail with a rank error as the rank
was taken from the RHS.

Changing this to the LHS express failed due to 'use_assoc',
which added an 'extern' to the variable and 'proc_pointer'
also caused problems – in principle, either problem could
have also occurred for the RHS.

Side effect: The error message is better for rank mismatch
as for 'f() = a' no pointer assignment is involved (in terms
of the user code) but before we had the error message
'Different ranks in pointer assignment'.

OK?

Tobias

-
Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany
Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Alexander 
Walter
Fortran: Fixes for pointer function call as variable (PR96896)

gcc/fortran/ChangeLog:

	PR fortran/96896
	* resolve.c (get_temp_from_expr): Also reset proc_pointer +
	use_assoc attribute.
	(resolve_ptr_fcn_assign): Use information from the LHS.

gcc/testsuite/ChangeLog:

	PR fortran/96896
	* gfortran.dg/ptr_func_assign_4.f08:
	* gfortran.dg/ptr-func-3.f90: New test.

 gcc/fortran/resolve.c   |  4 +-
 gcc/testsuite/gfortran.dg/ptr-func-3.f90| 56 +
 gcc/testsuite/gfortran.dg/ptr_func_assign_4.f08 |  4 +-
 3 files changed, 61 insertions(+), 3 deletions(-)

diff --git a/gcc/fortran/resolve.c b/gcc/fortran/resolve.c
index e4232717e42..a3e1e427ba7 100644
--- a/gcc/fortran/resolve.c
+++ b/gcc/fortran/resolve.c
@@ -11173,9 +11173,11 @@ get_temp_from_expr (gfc_expr *e, gfc_namespace *ns)
   /* Add the attributes and the arrayspec to the temporary.  */
   tmp->n.sym->attr = gfc_expr_attr (e);
   tmp->n.sym->attr.function = 0;
+  tmp->n.sym->attr.proc_pointer = 0;
   tmp->n.sym->attr.result = 0;
   tmp->n.sym->attr.flavor = FL_VARIABLE;
   tmp->n.sym->attr.dummy = 0;
+  tmp->n.sym->attr.use_assoc = 0;
   tmp->n.sym->attr.intent = INTENT_UNKNOWN;
 
   if (as)
@@ -11595,7 +11597,7 @@ resolve_ptr_fcn_assign (gfc_code **code, gfc_namespace *ns)
   return false;
 }
 
-  tmp_ptr_expr = get_temp_from_expr ((*code)->expr2, ns);
+  tmp_ptr_expr = get_temp_from_expr ((*code)->expr1, ns);
 
   /* get_temp_from_expression is set up for ordinary assignments. To that
  end, where array bounds are not known, arrays are made allocatable.
diff --git a/gcc/testsuite/gfortran.dg/ptr-func-3.f90 b/gcc/testsuite/gfortran.dg/ptr-func-3.f90
new file mode 100644
index 000..0f1af64002a
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/ptr-func-3.f90
@@ -0,0 +1,56 @@
+! { dg-do run }
+! PR fortran/96896
+
+call test1
+call reshape_test
+end
+
+subroutine test1
+implicit none
+integer, target :: B
+integer, pointer :: A(:)
+allocate(A(5))
+A = 1
+B = 10
+get_A() = get_B()
+if (any (A /= 10)) stop 1
+get_A() = get_A()
+if (any (A /= 10)) stop 2
+deallocate(A)
+contains
+  function get_A()
+integer, pointer :: get_A(:)
+get_A => A
+  end
+  function get_B()
+integer, pointer :: get_B
+get_B => B
+  end
+end
+
+subroutine reshape_test
+implicit none
+real, target, dimension (1:9) :: b
+integer :: i
+b = 1.0
+myshape(b) = 3.0
+do i = 1, 3
+  myfunc (b,i,2) = b(i) + i
+  b(i) = b(i) + 2.0
+end do
+if (any (b /= [real::5,5,5,4,5,6,3,3,3])) stop 3
+contains
+  function myfunc(b,i,j)
+real, target, dimension (1:9) :: b
+real, pointer :: myfunc
+real, pointer :: p(:,:)
+integer :: i,j 
+p => myshape(b)
+myfunc => p(i,j)
+  end function myfunc
+  function myshape(b)
+real, target, dimension (1:9) :: b
+real, pointer :: myshape(:,:)
+myshape(1:3,1:3) => b
+  end function myshape
+end subroutine reshape_test
diff --git a/gcc/testsuite/gfortran.dg/ptr_func_assign_4.f08 b/gcc/testsuite/gfortran.dg/ptr_func_assign_4.f08
index 46ef2ac5566..49ba9bcd3d9 100644
--- a/gcc/testsuite/gfortran.dg/ptr_func_assign_4.f08
+++ b/gcc/testsuite/gfortran.dg/ptr_func_assign_4.f08
@@ -10,8 +10,8 @@ program p
   integer :: c
 
   c = 3
-  func (b(2, 2)) = b ! { dg-error "Different ranks" }
-  func (c) = b   ! { dg-error "Different ranks" }
+  func (b(2, 2)) = b ! { dg-error "Incompatible ranks 1 and 2 in assignment" }
+  func (c) = b   ! { dg-error "Incompatible ranks 1 and 2 in assignment" }
 
 contains
   function func(arg) result(r)

[Bug target/96814] [11 Regression] wrong code with -march=cascadelake since r11-1445-g502d63b6d6141597

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96814

Martin Liška  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org

--- Comment #2 from Martin Liška  ---
So before the revision we generated:

  _1 = { 0, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1 };
  _2 = VEC_COND_EXPR <_1, { -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1,
-1, -1, -1 }, { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 }>;
  _3 = VIEW_CONVERT_EXPR(_2);
  x = _3;

but now we have:

   :
  _1 = { -1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 };
  _24 = VIEW_CONVERT_EXPR(_1);
  _25 = { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 };
  _26 = BIT_FIELD_REF <_25, 1, 0>;
  _27 = _26;
  _28 = { -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1 };
  _29 = BIT_FIELD_REF <_28, 1, 0>;
  _30 = _29;
  _31 = _24 & 1;
  _32 = _31 != 0 ? _27 : _30;
...
  _151 = _24 & 32768;
  _152 = _151 != 0 ? _147 : _150;
  _2 = {_32, _40, _48, _56, _64, _72, _80, _88, _96, _104, _112, _120, _128,
_136, _144, _152};
  _3 = .VCOND_MASK (_2, { -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1,
-1, -1, -1 }, { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 });
  _4 = VIEW_CONVERT_EXPR(_3);
  x = _4;
  i_15 = 0;
  goto ; [INV]

It's because veclower sees:

  _1 = { -1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 };
  _2 = VEC_COND_EXPR <_1, { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, {
-1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1 }>;
  _3 = VEC_COND_EXPR <_2, { -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1,
-1, -1, -1 }, { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 }>;
  _4 = VIEW_CONVERT_EXPR(_3);

and if I see correctly the creation of the mask _2 is broken in RTL (probably
one can't build one from a vector costructor)?
Anyway SSA_NAMEs like _128 don't have any use.

@Richi: Can you please help me with that? I'm looking into it for quite some
time :/

[Bug libstdc++/96851] operator< on std::array does not work in constexpr, for sizeof(T) == 1, and N > 1

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96851

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Jonathan Wakely :

https://gcc.gnu.org/g:2f983fa69005b603ea1758a013b4134d5b0f24a8

commit r11-2981-g2f983fa69005b603ea1758a013b4134d5b0f24a8
Author: Jonathan Wakely 
Date:   Wed Sep 2 15:17:24 2020 +0100

libstdc++: Fix three-way comparison for std::array [PR 96851]

The spaceship operator for std::array uses memcmp when the
__is_byte trait is true, but memcmp isn't usable in
constexpr contexts. Also, memcmp should only be used for unsigned byte
types, because it gives the wrong answer for signed chars with negative
values.

We can simply check std::is_constant_evaluated() so that we don't use
memcmp during constant evaluation.

To fix the problem of using memcmp for inappropriate types, this patch
adds new __is_memcmp_ordered and __is_memcmp_ordered_with traits. These
say whether using memcmp will give the right answer for ordering
operations such as lexicographical_compare and three-way comparisons.
The new traits can be used in several places, and can also be used to
implement my suggestion in PR 93059 comment 37 to use memcmp for
unsigned integers larger than one byte on big endian targets.

libstdc++-v3/ChangeLog:

PR libstdc++/96851
* include/bits/cpp_type_traits.h (__is_memcmp_ordered):
New trait that says if memcmp can be used for ordering.
(__is_memcmp_ordered_with): Likewise, for two types.
* include/bits/deque.tcc (__lex_cmp_dit): Use new traits
instead of __is_byte and __numeric_traits.
(__lexicographical_compare_aux1): Likewise.
* include/bits/ranges_algo.h (__lexicographical_compare_fn):
Likewise.
* include/bits/stl_algobase.h (__lexicographical_compare_aux1)
(__is_byte_iter): Likewise.
* include/std/array (operator<=>): Likewise. Only use memcmp
when std::is_constant_evaluated() is false.
* testsuite/23_containers/array/comparison_operators/96851.cc:
New test.
* testsuite/23_containers/array/tuple_interface/get_neg.cc:
Adjust dg-error line numbers.