[Bug fortran/96911] bug with Intrinsic shifta/shiftl/shiftr

[zhen...@compiler-dev.com]

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

--- Comment #6 from zhen...@compiler-dev.com ---
(In reply to kargl from comment #2)
> (In reply to zhen.xu from comment #0)
> > Dealing with Intrinsic shifta/shiftl/shiftr, gfortran refuses proper numbers
> > in the code below and throws "Error: Integer too big for its kind". 
> > 
> > The code is checked with ifort.
> > 
> > ---code--
> > program test
> >   print *, shifta(-128_1, 1);
> >   print *, shifta(-32768_2, 1);
> >   print *, shifta(-2147483648_4, 1);
> >   print *, shifta(-9223372036854775808_8, 1);
> > 
> >   print *, shiftl(-128_1, 1);
> >   print *, shiftl(-32768_2, 1);
> >   print *, shiftl(-2147483648_4, 1);
> >   print *, shiftl(-9223372036854775808_8, 1);
> > 
> >   print *, shiftr(-128_1, 1);
> >   print *, shiftr(-32768_2, 1);
> >   print *, shiftr(-2147483648_4, 1);
> >   print *, shiftr(-9223372036854775808_8, 1);
> > 
> > end
> > --
> 
> There are no negative integer withs gfortran.  -128_1 is a unary minus
> operator and 128_1 is a invalid operand. 128_1 would be greater than
> huge(1_1).  The only way to get the most "negative integer" is
> to do -huge(1_1) - 1 (assuming twos-complement arithmetic applies).

You are right! I made a mistake, please ignore my previous reply.

The right testcase should be below and it throws out the same prompt.
---
program testint
  integer(1) :: x = -128_1
  print *, x
end
---

[Bug fortran/96911] bug with Intrinsic shifta/shiftl/shiftr

[zhen...@compiler-dev.com]

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

--- Comment #5 from zhen...@compiler-dev.com ---
(In reply to kargl from comment #2)
> (In reply to zhen.xu from comment #0)
> > Dealing with Intrinsic shifta/shiftl/shiftr, gfortran refuses proper numbers
> > in the code below and throws "Error: Integer too big for its kind". 
> > 
> > The code is checked with ifort.
> > 
> > ---code--
> > program test
> >   print *, shifta(-128_1, 1);
> >   print *, shifta(-32768_2, 1);
> >   print *, shifta(-2147483648_4, 1);
> >   print *, shifta(-9223372036854775808_8, 1);
> > 
> >   print *, shiftl(-128_1, 1);
> >   print *, shiftl(-32768_2, 1);
> >   print *, shiftl(-2147483648_4, 1);
> >   print *, shiftl(-9223372036854775808_8, 1);
> > 
> >   print *, shiftr(-128_1, 1);
> >   print *, shiftr(-32768_2, 1);
> >   print *, shiftr(-2147483648_4, 1);
> >   print *, shiftr(-9223372036854775808_8, 1);
> > 
> > end
> > --
> 
> There are no negative integer withs gfortran.  -128_1 is a unary minus
> operator and 128_1 is a invalid operand. 128_1 would be greater than
> huge(1_1).  The only way to get the most "negative integer" is
> to do -huge(1_1) - 1 (assuming twos-complement arithmetic applie
You are right(In reply to anlauf from comment #1)
> Error: Integer too big for its kind at (1). This check can be disabled with
> the option '-fno-range-check'
> 
> Why don't you read what gfortran is telling you, and acting appropriately?

Sorry, I made a mistake. You are right.
(In reply to anlauf from comment #1)
> Error: Integer too big for its kind at (1). This check can be disabled with
> the option '-fno-range-check'
> 
> Why don't you read what gfortran is telling you, and acting appropriately?

You are right! I made a mistake, please ignore my previous reply.

The right testcase should be below and it throws out the same prompt.
---
program testint
  integer(1) :: x = -128_1
  print *, x
end
---

[Bug fortran/96911] bug with Intrinsic shifta/shiftl/shiftr

[zhen...@compiler-dev.com]

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

--- Comment #4 from zhen...@compiler-dev.com ---
(In reply to kargl from comment #2)
> (In reply to zhen.xu from comment #0)
> > Dealing with Intrinsic shifta/shiftl/shiftr, gfortran refuses proper numbers
> > in the code below and throws "Error: Integer too big for its kind". 
> > 
> > The code is checked with ifort.
> > 
> > ---code--
> > program test
> >   print *, shifta(-128_1, 1);
> >   print *, shifta(-32768_2, 1);
> >   print *, shifta(-2147483648_4, 1);
> >   print *, shifta(-9223372036854775808_8, 1);
> > 
> >   print *, shiftl(-128_1, 1);
> >   print *, shiftl(-32768_2, 1);
> >   print *, shiftl(-2147483648_4, 1);
> >   print *, shiftl(-9223372036854775808_8, 1);
> > 
> >   print *, shiftr(-128_1, 1);
> >   print *, shiftr(-32768_2, 1);
> >   print *, shiftr(-2147483648_4, 1);
> >   print *, shiftr(-9223372036854775808_8, 1);
> > 
> > end
> > --
> 
> There are no negative integer withs gfortran.  -128_1 is a unary minus
> operator and 128_1 is a invalid operand. 128_1 would be greater than
> huge(1_1).  The only way to get the most "negative integer" is
> to do -huge(1_1) - 1 (assuming twos-complement arithmetic applies).

But how can the code below be compiled by gfortran well and print out -128
properly?

program testint
  integer(1) :: x = -128
  print *, x
end

[Bug fortran/96911] bug with Intrinsic shifta/shiftl/shiftr

[zhen...@compiler-dev.com]

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

--- Comment #3 from zhen...@compiler-dev.com ---
(In reply to anlauf from comment #1)
> Error: Integer too big for its kind at (1). This check can be disabled with
> the option '-fno-range-check'
> 
> Why don't you read what gfortran is telling you, and acting appropriately?


The fact is -128 is surely not too big for integer(1). The below code is
compiled by gfortran and can print out -128 properly.

program testint
  integer(1) :: x = -128
  print *, x
end

[Bug target/53784] Scalar vector binary operation - compilation fails with -std=c90/c99/c11 (-fexcess-precision=standard)

[e...@coeus-group.com]

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

Evan Nemerson  changed:

   What|Removed |Added

 CC||e...@coeus-group.com

--- Comment #4 from Evan Nemerson  ---
This also occurs on s390x.  Just like ot i686, -std=c99 or
-fexcess-precision=standard triggers it.

U

[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||missed-optimization

--- Comment #3 from Martin Sebor  ---
This is also a missed optimization opportunity.  Another test case that shows
both the bogus warning and the suboptimal codegen is the following.  Because
there is no explicit initializer for a.b, fold_nonarray_ctor_reference()
returns a scalar zero, which again triggers the warning and prevents the strlen
call from being folded.  The optimization never worked in this case so that
part is not a regression.

$ cat z.c && gcc -O2 -S -Wall -fdump-tree-optimized=/dev/stdout z.c
struct A { char n, a[4], b[4]; };
const struct A a = { };

int f (void)
{
  const char *p = [2];
  return __builtin_strlen (p - 2);
}
z.c: In function ‘f’:
z.c:7:10: warning: offset ‘5’ outside bounds of constant string
[-Warray-bounds]
7 |   return __builtin_strlen (p - 2);
  |  ^~~~
z.c:2:16: note: ‘a’ declared here
2 | const struct A a = { };
  |^

;; Function f (f, funcdef_no=0, decl_uid=1935, cgraph_uid=1, symbol_order=1)

f ()
{
  long unsigned int _1;
  int _3;

   [local count: 1073741824]:
  _1 = __builtin_strlen (  [(void *) + 5B]);
  _3 = (int) _1;
  return _3;

}

[Bug middle-end/95189] [9/10 Regression] memcmp being wrongly stripped like strcmp

[amonakov at gcc dot gnu.org]

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

Alexander Monakov  changed:

   What|Removed |Added

 CC||amonakov at gcc dot gnu.org

--- Comment #15 from Alexander Monakov  ---
Is the patch eligible for backporting?

Users are hitting this as shown by dups and questions elsewhere like
https://stackoverflow.com/questions/63724679/wrong-gcc-9-and-higher-optimization-of-memcmp-with-fno-inline

[Bug target/96918] Failure to optimize vector shift left+shift right+or to pshuf

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Or the generic code could try to expand vector rotates by multiplies of
BITS_PER_UNIT as vector permutations, perhaps only if there is no optab for it.
 Or trying to expand both permutation and rotate and determine at expansion
time using costs which sequence is cheaper.

[Bug tree-optimization/96820] ICE in verify_sra_access_forest with array and out of bounds reference

[cvs-commit at gcc dot gnu.org]

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

--- Comment #7 from CVS Commits  ---
The master branch has been updated by Martin Jambor :

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

commit r11-3003-g8ad3fc6ca46c603d9c3efe8e6d4a8f2ff1a893a4
Author: Martin Jambor 
Date:   Thu Sep 3 22:43:49 2020 +0200

sra: Avoid SRAing if there is an aout-of-bounds access (PR 96820)

The testcase causes and ICE in the SRA verifier on x86_64 when
compiling with -m32 because build_user_friendly_ref_for_offset looks
at an out-of-bounds array_ref within an array_ref which accesses an
offset which does not fit into a signed 32bit integer and turns it
into an array-ref with a negative index.

The best thing is probably to bail out early when encountering an out
of bounds access to a local stack-allocated aggregate (and let the DSE
just delete such statements) which is what the patch does.

I also glanced over to the initial candidate vetting routine to make
sure the size would fit into HWI and noticed that it uses unsigned
variants whereas the rest of SRA operates on signed offsets and
sizes (because get_ref_and_extent does) and so changed that for the
sake of consistency.  These ancient checks operate on sizes of types
as opposed to DECLs but I hope that any issues potentially arising
from that are basically hypothetical.

gcc/ChangeLog:

2020-08-28  Martin Jambor  

PR tree-optimization/96820
* tree-sra.c (create_access): Disqualify candidates with accesses
beyond the end of the original aggregate.
(maybe_add_sra_candidate): Check that candidate type size fits
signed uhwi for the sake of consistency.

gcc/testsuite/ChangeLog:

2020-08-28  Martin Jambor  

PR tree-optimization/96820
* gcc.dg/tree-ssa/pr96820.c: New test.

[Bug target/62191] extra shift generated for vector integer division by constant 2

[gabravier at gmail dot com]

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

Gabriel Ravier  changed:

   What|Removed |Added

 CC||gabravier at gmail dot com

--- Comment #2 from Gabriel Ravier  ---
The first arithmetic shift doesn't seem to be emitted anymore, so presumably
this should be fixed now. I can't mark it as fixed myself, but I can confirm it
seems to be so.

[Bug tree-optimization/96930] New: Failure to optimize out 64-bit arithmetic when it can't happen with division transformed into right shift

[gabravier at gmail dot com]

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

Bug ID: 96930
   Summary: Failure to optimize out 64-bit arithmetic when it
can't happen with division transformed into right
shift
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gabravier at gmail dot com
  Target Milestone: ---

unsigned f(unsigned a, unsigned b)
{
return a / (unsigned long long)(1U << b);
}

This can be optimized to `return a >> b;`. This transformation is done by LLVM,
but not by GCC.

[Bug tree-optimization/96929] New: Failure to optimize right shift of -1 to -1

[gabravier at gmail dot com]

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

Bug ID: 96929
   Summary: Failure to optimize right shift of -1 to -1
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gabravier at gmail dot com
  Target Milestone: ---

int f(int b)
{
return -1 >> b;
}

This can be optimized to `return -1;`. This transformation is done by LLVM, but
not by GCC.

[Bug target/96918] Failure to optimize vector shift left+shift right+or to pshuf

[glisse at gcc dot gnu.org]

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

--- Comment #5 from Marc Glisse  ---
typedef unsigned short v8i16 __attribute__((vector_size(16)));

v8i16 bswap_epi16(v8i16 x)
{
return (x << 8) | (x >> 8);
}

We do recognize a rotate already in GENERIC

  return x r<< 8;

But this is expanded to

movdqa  %xmm0, %xmm1
psrlw   $8, %xmm0
psllw   $8, %xmm1
por %xmm1, %xmm0

probably the target could advertise a rotate insn for that mode, restricted to
an argument of 8?

IIRC, I didn't use vector extensions for the corresponding shift intrinsics
because for large shift amounts they set the result to 0. But for a constant
scalar, we could lower the builtin to a shift (or fold to 0).

[Bug target/96139] Vector element extract mistypes long long int down to long int

[cvs-commit at gcc dot gnu.org]

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

--- Comment #6 from CVS Commits  ---
The master branch has been updated by Will Schmidt :

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

commit r11-3002-gd8f3474ff81b07fd2e758337957711db17eb801e
Author: Will Schmidt 
Date:   Mon Jul 20 10:51:37 2020 -0500

[PATCH, rs6000] Fix vector long long subtype (PR96139)

Hi,
  This corrects an issue with the powerpc vector long long subtypes.
As reported by SjMunroe, when building some code with -Wall, and
attempting to print an element of a "long long vector" with a
long long printf format string, we will report an error because
the vector sub-type was improperly defined as int.

When defining a V2DI_type_node we use a TARGET_POWERPC64 ternary to
define the V2DI_type_node with "vector long" or "vector long long".
We also need to specify the proper sub-type when we define the type.

PR target/96139

2020-09-03  Will Schmidt  

gcc/ChangeLog:
* config/rs6000/rs6000-call.c (rs6000_init_builtin): Update
V2DI_type_node
and unsigned_V2DI_type_node definitions.

gcc/testsuite/ChangeLog:
* gcc.target/powerpc/pr96139-a.c: New test.
* gcc.target/powerpc/pr96139-b.c: New test.
* gcc.target/powerpc/pr96139-c.c: New test.

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

[cvs-commit at gcc dot gnu.org]

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Jakub Jelinek :

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

commit r11-3001-gba6730bd18371a3dff1e37d2c2ee27233285b597
Author: Jakub Jelinek 
Date:   Thu Sep 3 21:53:40 2020 +0200

c++: Fix another PCH hash_map issue [PR96901]

The recent libstdc++ changes caused lots of libstdc++-v3 tests FAILs
on i686-linux, all of them in the same spot during constexpr evaluation
of a recursive _S_gcd call.
The problem is yet another hash_map that used the default hasing of
tree keys through pointer hashing which is preserved across PCH write/read.
During PCH handling, the addresses of GC objects are changed, which means
that the hash values of the keys in such hash tables change without those
hash tables being rehashed.  Which in the fundef_copies_table case usually
means we just don't find a copy of a FUNCTION_DECL body for recursive uses
and start from scratch.  But when the hash table keeps growing, the "dead"
elements in the hash table can sometimes reappear and break things.
In particular what I saw under the debugger is when the fundef_copies_table
hash map has been used on the outer _S_gcd call, it didn't find an entry
for
it, so returned a slot with *slot == NULL, which is treated as that the
function itself is used directly (i.e. no recursion), but that addition of
a hash table slot caused the recursive _S_gcd call to actually find
something in the hash table, unfortunately not the new *slot == NULL spot,
but a different one from the pre-PCH streaming which contained the returned
toplevel (non-recursive) call entry for it, which means that for the
recursive _S_gcd call we actually used the same trees as for the outer ones
rather than a copy of those, which breaks constexpr evaluation.

2020-09-03  Jakub Jelinek  

PR c++/96901
* tree.h (struct decl_tree_traits): New type.
(decl_tree_map): New typedef.

* constexpr.c (fundef_copies_table): Change type from
hash_map * to decl_tree_map *.

[Bug c++/96922] primary expression error when using parenthesis around requires expression for some concepts

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

  Component|libstdc++   |c++

--- Comment #4 from Jonathan Wakely  ---
You've just changed it back again to libstdc++!

[Bug c++/96905] [10/11 Regression] 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 #5 from Jakub Jelinek  ---
Tried
--- gcc/cp/semantics.c.jj   2020-09-01 09:17:50.0 +0200
+++ gcc/cp/semantics.c  2020-09-03 21:20:20.678830381 +0200
@@ -4517,7 +4517,7 @@ expand_or_defer_fn_1 (tree fn)
   return false;
 }

-  if (DECL_OMP_DECLARE_REDUCTION_P (fn))
+  if (DECL_IMMEDIATE_FUNCTION_P (fn) || DECL_OMP_DECLARE_REDUCTION_P (fn))
 return false;

   return true;
--- gcc/cp/decl2.c.jj   2020-07-28 15:39:09.780759362 +0200
+++ gcc/cp/decl2.c  2020-09-03 21:23:15.973278453 +0200
@@ -2172,7 +2172,7 @@ void
 mark_needed (tree decl)
 {
   TREE_USED (decl) = 1;
-  if (TREE_CODE (decl) == FUNCTION_DECL)
+  if (TREE_CODE (decl) == FUNCTION_DECL && !DECL_IMMEDIATE_FUNCTION_P (decl))
 {
   /* Extern inline functions don't become needed when referenced.
 If we know a method will be emitted in other TU and no new
--- gcc/cp/pt.c.jj  2020-09-01 09:17:28.042110726 +0200
+++ gcc/cp/pt.c 2020-09-03 21:14:14.497159429 +0200
@@ -23891,8 +23891,10 @@ mark_decl_instantiated (tree result, int
 {
   mark_definable (result);
   mark_needed (result);
+  if (DECL_IMMEDIATE_FUNCTION_P (result))
+   ;
   /* Always make artificials weak.  */
-  if (DECL_ARTIFICIAL (result) && flag_weak)
+  else if (DECL_ARTIFICIAL (result) && flag_weak)
comdat_linkage (result);
   /* For WIN32 we also want to put explicit instantiations in
 linkonce sections.  */
but that is still not enough, the above are just some hacks to avoid creating
cgraph nodes for immediate functions, but e.g. c_parse_final_cleanups still
creates them.

[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

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

--- Comment #7 from anlauf at gcc dot gnu.org ---
Fixed on master.

[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues

[manu at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639
Bug 24639 depends on bug 94774, which changed state.

Bug 94774 Summary: Uninitialized variable retval in function 
try_substitute_return_value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94774

   What|Removed |Added

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

[Bug tree-optimization/94774] Uninitialized variable retval in function try_substitute_return_value

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED
 CC||manu at gcc dot gnu.org

--- Comment #4 from Manuel López-Ibáñez  ---
Seems fixed.

[Bug c++/94905] [10 Regression] Bogus warning -Werror=maybe-uninitialized

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

Summary|Bogus warning   |[10 Regression] Bogus
   |-Werror=maybe-uninitialized |warning
   ||-Werror=maybe-uninitialized
   Target Milestone|--- |10.4
 Ever confirmed|0   |1
   Last reconfirmed||2020-09-03
 Status|UNCONFIRMED |NEW

--- Comment #10 from Manuel López-Ibáñez  ---
(In reply to Arseny Solokha from comment #3)
> The best I've been able to come up with is the following, reduced from APL
> 1.8:

It is warning about this, but it should not warn:

  # DEBUG rD.2406 => (intD.9) (ivtmp.24_6 /[ex] 4) + 1
  [./example.cpp:8:27] # VUSE <.MEM_11>
  pretmp_8 = MEM[(intD.9 *) + ivtmp.24_13 * 1];


This is regression but not sure when it was introduced.

[Bug c++/94905] Bogus warning -Werror=maybe-uninitialized

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #9 from Manuel López-Ibáñez  ---
(In reply to Chris Moller from comment #8)
> Created attachment 48825 [details]
> Preprocessed testcase

This is way too large, nobody can analyze what is really going on with such a
large testcase: https://gcc.gnu.org/wiki/A_guide_to_testcase_reduction

[Bug libfortran/96890] Wrong answer with intrinsic IALL

[cvs-commit at gcc dot gnu.org]

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

--- Comment #6 from CVS Commits  ---
The master branch has been updated by Harald Anlauf :

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

commit r11-3000-g8cbcc17041fdfd3ccc928161ae86e7f9b456
Author: Harald Anlauf 
Date:   Thu Sep 3 20:33:14 2020 +0200

PR fortran/96890 - Wrong answer with intrinsic IALL

The IALL intrinsic would always return 0 when the DIM and MASK arguments
were present since the initial value of repeated BIT-AND operations was
set to 0 instead of -1.

libgfortran/ChangeLog:

* m4/iall.m4: Initial value for result should be -1.
* generated/iall_i1.c (miall_i1): Generated.
* generated/iall_i16.c (miall_i16): Likewise.
* generated/iall_i2.c (miall_i2): Likewise.
* generated/iall_i4.c (miall_i4): Likewise.
* generated/iall_i8.c (miall_i8): Likewise.

gcc/testsuite/ChangeLog:

* gfortran.dg/iall_masked.f90: New test.

[Bug c++/88323] implement C++20 language features.

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88323
Bug 88323 depends on bug 92812, which changed state.

Bug 92812 Summary: Implement P1975R0: Fixing the wording of parenthesized 
aggregate-initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92812

   What|Removed |Added

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

[Bug c++/92812] Implement P1975R0: Fixing the wording of parenthesized aggregate-initialization

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #12 from Marek Polacek  ---
Resolved for GCC 11.

[Bug c++/92812] Implement P1975R0: Fixing the wording of parenthesized aggregate-initialization

[cvs-commit at gcc dot gnu.org]

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

--- Comment #11 from CVS Commits  ---
The master branch has been updated by Marek Polacek :

https://gcc.gnu.org/g:753b4679bc46f6806cf45d9afc3783c6d3b63589

commit r11-2999-g753b4679bc46f6806cf45d9afc3783c6d3b63589
Author: Marek Polacek 
Date:   Wed Aug 26 08:27:33 2020 -0400

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

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.

[Bug middle-end/95848] missing -Wuninitialized passing structs by value (VOPS)

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org
Summary|missing -Wuninitialized |missing -Wuninitialized
   |passing structs by value|passing structs by value
   ||(VOPS)

--- Comment #1 from Manuel López-Ibáñez  ---
This uses VOPS, so it probably needs new code to handle that.  Perhaps PR41953

h ()
{
  struct S s;

   [local count: 1073741824]:
  [./example.cpp:7:3] # DEBUG BEGIN_STMT
  [./example.cpp:8:3] # DEBUG BEGIN_STMT
  [./example.cpp:8:6] # .MEM_2 = VDEF <.MEM_1(D)>
  fs (s); [tail call]
  # .MEM_3 = VDEF <.MEM_2>
  s ={v} {CLOBBER};
  [./example.cpp:9:1] # VUSE <.MEM_3>
  return;
}

There is no difference in the logs that explain why g() is treated differently,
so that must be a special case for const* parameters.

[Bug c++/96926] [9/10/11 Regression] Tuple element w/ member reference to incomplete template type rejected

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
Created attachment 49180
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49180=edit
Manually reduced code

[Bug tree-optimization/96928] New: Failure to optimize one's complement abs pattern

[gabravier at gmail dot com]

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

Bug ID: 96928
   Summary: Failure to optimize one's complement abs pattern
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gabravier at gmail dot com
  Target Milestone: ---

int f(int a)
{
return (a < 0) ? ~a : a;
}

This can be optimized to `return (a >> 31) ^ a;`. This transformation is done
by LLVM, but not by GCC.

[Bug c/96629] spurious maybe uninitialized variable warning with difficult control-flow analysis

[yyc1992 at gmail dot com]

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

--- Comment #3 from Yichao Yu  ---
Just curious, is it some particular structure that is upsetting it or did it
simply hit some depth limit.

[Bug c/96629] spurious maybe uninitialized variable warning with difficult control-flow analysis

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

Summary|spurious uninitialized  |spurious maybe
   |variable warning with   |uninitialized variable
   |branches at -O1 and higher  |warning with difficult
   ||control-flow analysis
 CC||manu at gcc dot gnu.org

--- Comment #2 from Manuel López-Ibáñez  ---
Yes, the pass seems to give up:

[CHECK]: Found unguarded use: d2_29 = PHI 
[WORKLIST]: Update worklist with phi: d2_29 = PHI 
[CHECK]: examining phi: d2_29 = PHI 
[CHECK]: Found unguarded use: mem (d2_29); [tail call]

[Bug c++/96862] -frounding-math -std=c++2a error: '(1.29e+2 * 6.9314718055994529e-1)' is not a constant expression

[cvs-commit at gcc dot gnu.org]

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

--- Comment #10 from CVS Commits  ---
The master branch has been updated by Jakub Jelinek :

https://gcc.gnu.org/g:6641d6d3fe79113f8d9f3ced355aea79bffda822

commit r11-2998-g6641d6d3fe79113f8d9f3ced355aea79bffda822
Author: Jakub Jelinek 
Date:   Thu Sep 3 20:11:43 2020 +0200

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

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.  */

  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;

  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.

2020-09-03  Jakub Jelinek  

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

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

[Bug other/96927] [11 regression] ICE in libstdc++-v3/include/chrono:442

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
Looks like PR96901 to me.

[Bug other/96927] New: [11 regression] ICE in libstdc++-v3/include/chrono:442

[seurer at gcc dot gnu.org]

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

Bug ID: 96927
   Summary: [11 regression]  ICE in
libstdc++-v3/include/chrono:442
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

I am seeing ICEs in some of the C++ conformance tests with a bootstrap build. 
I think they are all like the following.  I am not sure what exact revision
caused them as they do not occur with every run nor on every system but it is
in the range r11-2828 to r11-2985.  I'll try to narrow it down a bit.


seurer@makalu-lp1:~/gcc/git/build/gcc-test$
/home/seurer/gcc/git/build/gcc-trunk-bootstrap/./gcc/xg++ -shared-libgcc
-B/home/seurer/gcc/git/build/gcc-trunk-bootstrap/./gcc -nostdinc++
-L/home/seurer/gcc/git/build/gcc-trunk-bootstrap/powerpc64-unknown-linux-gnu/libstdc++-v3/src
-L/home/seurer/gcc/git/build/gcc-trunk-bootstrap/powerpc64-unknown-linux-gnu/libstdc++-v3/src/.libs
-L/home/seurer/gcc/git/build/gcc-trunk-bootstrap/powerpc64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs
-B/home/seurer/gcc/git/install/gcc-trunk-bootstrap/powerpc64-unknown-linux-gnu/bin/
-B/home/seurer/gcc/git/install/gcc-trunk-bootstrap/powerpc64-unknown-linux-gnu/lib/
-isystem
/home/seurer/gcc/git/install/gcc-trunk-bootstrap/powerpc64-unknown-linux-gnu/include
-isystem
/home/seurer/gcc/git/install/gcc-trunk-bootstrap/powerpc64-unknown-linux-gnu/sys-include
-fchecking=1
-B/home/seurer/gcc/git/build/gcc-trunk-bootstrap/powerpc64-unknown-linux-gnu/./libstdc++-v3/src/.libs
-fmessage-length=0 -fno-show-column -ffunction-sections -fdata-sections -g -O2
-D_GNU_SOURCE -DLOCALEDIR="." -nostdinc++
-I/home/seurer/gcc/git/build/gcc-trunk-bootstrap/powerpc64-unknown-linux-gnu/libstdc++-v3/include/powerpc64-unknown-linux-gnu
-I/home/seurer/gcc/git/build/gcc-trunk-bootstrap/powerpc64-unknown-linux-gnu/libstdc++-v3/include
-I/home/seurer/gcc/git/gcc-trunk-bootstrap/libstdc++-v3/libsupc++
-I/home/seurer/gcc/git/gcc-trunk-bootstrap/libstdc++-v3/include/backward
-I/home/seurer/gcc/git/gcc-trunk-bootstrap/libstdc++-v3/testsuite/util
/home/seurer/gcc/git/gcc-trunk-bootstrap/libstdc++-v3/testsuite/20_util/is_empty/value.cc
-include bits/stdc++.h -fdiagnostics-plain-output -S -o value.s
In file included from
/home/seurer/gcc/git/gcc-trunk-bootstrap/libstdc++-v3/include/precompiled/stdc++.h:101:
/home/seurer/gcc/git/build/gcc-trunk-bootstrap/powerpc64-unknown-linux-gnu/libstdc++-v3/include/chrono:
In substitution of 'template constexpr
std::chrono::duration >::duration(const
std::chrono::duration<_Rep1, _Period1>&) [with _Rep2 = long int; _Period2 =
std::ratio<1>;  = ]':
/home/seurer/gcc/git/build/gcc-trunk-bootstrap/powerpc64-unknown-linux-gnu/libstdc++-v3/include/chrono:614:
  required from 'constexpr typename
std::common_type,
std::chrono::duration<_Rep2, _Period2> >::type std::chrono::operator-(const
std::chrono::duration<_Rep1, _Period1>&, const std::chrono::duration<_Rep2,
_Period2>&) [with _Rep1 = long int; _Period1 = std::ratio<1, 10>; _Rep2
= long int; _Period2 = std::ratio<1>; typename
std::common_type,
std::chrono::duration<_Rep2, _Period2> >::type = std::chrono::duration >]'
/home/seurer/gcc/git/build/gcc-trunk-bootstrap/powerpc64-unknown-linux-gnu/libstdc++-v3/include/chrono:975:
  required from 'constexpr std::chrono::time_point<_Clock, typename
std::common_type<_Dur1, std::chrono::duration<_Rep2, _Period2> >::type>
std::chrono::operator-(const std::chrono::time_point<_Clock, _Duration1>&,
const std::chrono::duration<_Rep2, _Period2>&) [with _Clock =
std::filesystem::__file_clock; _Dur1 = std::chrono::duration >; _Rep2 = long int; _Period2 = std::ratio<1>;
typename std::common_type<_Dur1, std::chrono::duration<_Rep2, _Period2> >::type
= std::chrono::duration >]'
/home/seurer/gcc/git/build/gcc-trunk-bootstrap/powerpc64-unknown-linux-gnu/libstdc++-v3/include/chrono:3254:
  required from 'static std::chrono::time_point std::filesystem::__file_clock::_S_from_sys(const
std::chrono::time_point&) [with _Dur =
std::chrono::duration >]'
/home/seurer/gcc/git/build/gcc-trunk-bootstrap/powerpc64-unknown-linux-gnu/libstdc++-v3/include/chrono:3221:
  required from here
/home/seurer/gcc/git/build/gcc-trunk-bootstrap/powerpc64-unknown-linux-gnu/libstdc++-v3/include/chrono:441:
  in 'constexpr' expansion of 'std::chrono::duration >::_S_gcd(((intmax_t)std::ratio<1>::den), ((intmax_t)std::ratio<1,
10>::den))'
/home/seurer/gcc/git/build/gcc-trunk-bootstrap/powerpc64-unknown-linux-gnu/libstdc++-v3/include/chrono:442:
internal compiler error: Segmentation fault
0x10df176b crash_signal
/home/seurer/gcc/git/gcc-trunk-bootstrap/gcc/toplev.c:327
0x102aed7c cxx_eval_call_expression
/home/seurer/gcc/git/gcc-trunk-bootstrap/gcc/cp/constexpr.c:2622
0x102b131f cxx_eval_constant_expression

[Bug target/90129] Wrong error: inlining failed in call to always_inline ‘_mm256_adds_epi16’: target specific option mismatch

[thiago at kde dot org]

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

Thiago Macieira  changed:

   What|Removed |Added

 CC||thiago at kde dot org

--- Comment #3 from Thiago Macieira  ---
Another test:

$ cat test.c
#include 

__attribute__((target("arch=haswell")))
int hsw_test32(float f)
{
__m128 m = _mm_set_ss(f);
m = _mm_cmpeq_ss(m, m);
return _mm_movemask_ps(m);
}
$ gcc -c test.c 
In file included from
/usr/lib64/gcc/x86_64-suse-linux/10/include/immintrin.h:29,
 from test.c:1:
test.c: In function ‘hsw_test32’:
/usr/lib64/gcc/x86_64-suse-linux/10/include/xmmintrin.h:814:1: error: inlining
failed in call to ‘always_inline’ ‘_mm_movemask_ps’: target specific option
mismatch
[...]
$ clang -c test.c && echo No error
No error
$ gcc -march=haswell -c test.c && echo No error
No error

[Bug fortran/96911] bug with Intrinsic shifta/shiftl/shiftr

[kargl at gcc dot gnu.org]

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

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 zhen.xu from comment #0)
> Dealing with Intrinsic shifta/shiftl/shiftr, gfortran refuses proper numbers
> in the code below and throws "Error: Integer too big for its kind". 
> 
> The code is checked with ifort.
> 
> ---code--
> program test
>   print *, shifta(-128_1, 1);
>   print *, shifta(-32768_2, 1);
>   print *, shifta(-2147483648_4, 1);
>   print *, shifta(-9223372036854775808_8, 1);
> 
>   print *, shiftl(-128_1, 1);
>   print *, shiftl(-32768_2, 1);
>   print *, shiftl(-2147483648_4, 1);
>   print *, shiftl(-9223372036854775808_8, 1);
> 
>   print *, shiftr(-128_1, 1);
>   print *, shiftr(-32768_2, 1);
>   print *, shiftr(-2147483648_4, 1);
>   print *, shiftr(-9223372036854775808_8, 1);
> 
> end
> --

There are no negative integer withs gfortran.  -128_1 is a unary minus
operator and 128_1 is a invalid operand. 128_1 would be greater than
huge(1_1).  The only way to get the most "negative integer" is
to do -huge(1_1) - 1 (assuming twos-complement arithmetic applies).

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

[dmjpp at hotmail dot com]

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

--- Comment #7 from Dimitrij Mijoski  ---
I think a found a related bug in the UTF8 to UCS2 codecvt,
codecvt_utf8. It can be tested with the following example:

#include 

auto test_u8_ucs2_in()
{
// 2 code points, one is 3 bytes and the other is 4 bytes in UTF-8.
// in UTF-16 the first is sinlge unit, the second is surrogate pair
// in UCS2 only the first CP is allowed.
const char* in = u8"\u\U0010";
char16_t out[2] = { 'y' , 'y' };

auto cvt_ptr = make_unique>();
auto& cvt = *cvt_ptr;
auto state = mbstate_t{};
auto in_ptr = in;
auto out_ptr = out;

state = {};
in_ptr = nullptr;
out_ptr = nullptr;
auto res = cvt.in(state, in, in + 2, in_ptr, out, out, out_ptr);
assert(res == cvt.partial); //BUG, returns OK, should be Partial 
assert(out_ptr == out);
assert(in_ptr == in);

state = {};
in_ptr = nullptr;
out_ptr = nullptr;
res = cvt.in(state, in, in + 2, in_ptr, out, out + 1, out_ptr);
assert(res == cvt.partial); // BUG, returns ERROR, should be Partial
assert(out_ptr == out);
assert(in_ptr == in);

state = {};
in_ptr = nullptr;
out_ptr = nullptr;
res = cvt.in(state, in, in + 3, in_ptr, out, out, out_ptr);
assert(res == cvt.partial); //BUG, return OK, should be Partial
assert(out_ptr == out);
assert(in_ptr == in);


state = {};
in_ptr = nullptr;
out_ptr = nullptr;
res = cvt.in(state, in, in + 3, in_ptr, out, out + 1, out_ptr);
assert(res == cvt.ok);
assert(out_ptr == out + 1);
assert(in_ptr == in + 3);
cout << "UCS2 sequence: " << hex << out[0] << ' ' << out[1] << '\n';

state = {};
in_ptr = nullptr;
out_ptr = nullptr;
res = cvt.in(state, in, in + 6, in_ptr, out, out + 1, out_ptr);
assert(res == cvt.partial); // BUG, return OK, should be Partial
assert(out_ptr == out + 1);
assert(in_ptr == in + 3);

state = {};
in_ptr = nullptr;
out_ptr = nullptr;
res = cvt.in(state, in, in + 6, in_ptr, out, out + 2, out_ptr);
assert(res == cvt.partial); // BUG, returns ERROR, should be Partial
assert(out_ptr == out + 1);
assert(in_ptr == in + 3);

state = {};
in_ptr = nullptr;
out_ptr = nullptr;
res = cvt.in(state, in, in + 7, in_ptr, out, out + 1, out_ptr);
assert(res == cvt.partial); // BUG, returns OK, should be Partial
assert(out_ptr == out + 1);
assert(in_ptr == in + 3);

state = {};
in_ptr = nullptr;
out_ptr = nullptr;
res = cvt.in(state, in, in + 7, in_ptr, out, out + 2, out_ptr);
assert(res == cvt.error);
assert(out_ptr == out + 1);
assert(in_ptr == in + 3);
}


The bug lies in the same function utf16_in() I mentioned in comment #5, in
lines 544-547
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libstdc%2B%2B-v3/src/c%2B%2B11/codecvt.cc;h=0311b15177d0439757e0347f7934b5a09b78f8e3;hb=HEAD#l544

Those lines:

 544 if (s == surrogates::allowed)
 545   return codecvt_base::partial;
 546 else
 547   return codecvt_base::error; // No surrogates in UCS2

Should simply be one line: 

 544   return codecvt_base::partial;

[Bug c++/96926] [9/10/11 Regression] Tuple element w/ member reference to incomplete template type rejected

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
Hmm, this might be a bad reduction. __is_constructible_impl really *is*
incomplete here. In the real code it isn't.

[Bug c++/96926] [9/10/11 Regression] Tuple element w/ member reference to incomplete template type rejected

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Known to fail||10.2.1, 11.0, 9.3.1
  Known to work||8.3.0
   Last reconfirmed||2020-09-03
 Ever confirmed|0   |1
 CC||jason at gcc dot gnu.org

--- Comment #1 from Jonathan Wakely  ---
template  struct b;
template  struct __is_constructible_impl;
template  struct g;
template  using c = typename g::d;
template  struct m {
  template  static bool h() {
return b<__is_constructible_impl...>::i;
  }
};
template  class o {
  template  using ad = m;
  template  using k = c::template h(),
bool>;
  template > o(ab...);
};
struct q {
  o n;
};
struct r {
  q f;
  r();
};
int main() { r a; }

This is accepted by EDG, Clang and GCC 8. Rejected by GCC 9+ since r262172
(fixing PR c++/80290)

[Bug c++/96926] New: [9/10/11 Regression] Tuple element w/ member reference to incomplete template type rejected

[redi at gcc dot gnu.org]

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

Bug ID: 96926
   Summary: [9/10/11 Regression] Tuple element w/ member reference
to incomplete template type rejected
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
CC: cuzdav at gmail dot com, johnilacqua at hotmail dot com,
mpolacek at gcc dot gnu.org, unassigned at gcc dot gnu.org,
webrown.cpp at gmail dot com
  Target Milestone: ---

+++ This bug was initially created as a clone of Bug #96592 +++

This code seems a regression introduced in g++ 10.1, is still in 10.2 and
remains in the trunk.  It works on 9.x and as far back as g++ 6, plus all
versions of clang since 6, icc, msvc, etc.

There are many independent changes that can make it work, including: 
  * making SomeQuery constructor a template constructor (on SessionU)
  * changing the reference to a pointer
  * explicitly declaring Session as an incomplete type and not using
templates


#include 

template 
struct SomeQuery {
SessionT& session_;
SomeQuery(SessionT& session) : session_(session) {}
};

template 
struct Handler {
std::tuple> queries_;
Handler(SessionT& session) : queries_(session) {}
};

struct Session {
Handler handler_;
Session() : handler_{*this} {}
};

int main() {
Session session;
}


It looks like the tuple class is doing some concept checking that isn't quite
working, but I haven't dug deeply enough to determine if it's a library or
underlying compiler issue.

Live example on Compiler Explorer
https://godbolt.org/z/7naPMx


+++ PR 96592 comment 6 +++

As further evidence the compile is confused, the preprocessed source from GCC
10 can be compiled by GCC 8, but not GCC 9, 10 or trunk.

It started to be rejected with r262172 (fixing PR c++/80290), but the problem
was latent until r10-908 made std::tuple vulnerable to it.

I'll start reducing the preprocessed source ...

[Bug middle-end/96925] missing warning on sprintf into destination at negative offset

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Blocks||56456
   Keywords||diagnostic

--- Comment #1 from Martin Sebor  ---
The warning for the strcpy is issued by the wrestrict pass which doesn't
consider sprintf.  -Wrestrict is implemented separately for sprintf but without
the same bounds checking.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456
[Bug 56456] [meta-bug] bogus/missing -Warray-bounds

[Bug libstdc++/96922] primary expression error when using parenthesis around requires expression for some concepts

[rene.r...@fu-berlin.de]

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

Rene Rahn  changed:

   What|Removed |Added

  Component|c++ |libstdc++

--- Comment #3 from Rene Rahn  ---
> This is nothing to do with libstdc++, changing component to c++.

Sorry, I thought I selected c++. Thank you for correcting this.

[Bug middle-end/96925] New: missing warning on sprintf into destination at negative offset

[msebor at gcc dot gnu.org]

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

Bug ID: 96925
   Summary: missing warning on sprintf into destination at
negative offset
   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: ---

Only the first of the two invalid calls below is diagnosed.  Both should be.

$ cat z.c && gcc -O2 -S -Wall -xc -fdump-tree-optimized=/dev/stdout z.c
extern char a[];

void f (int i)
{
  if (i >= 0) i = -1;
  __builtin_strcpy (a + i, "3");   // warning (good)
}

void g (int i)
{
  if (i >= 0) i = -1;
  __builtin_sprintf (a + i, "%i", 3);   // missing warning
}
z.c: In function ‘f’:
z.c:6:3: warning: ‘__builtin_memcpy’ offset [-2147483648, -1] is out of the
bounds of object ‘a’ with type ‘char[]’ [-Warray-bounds]
6 |   __builtin_strcpy (a + i, "3");   // warning (good)
  |   ^
z.c:1:13: note: ‘a’ declared here
1 | extern char a[];
  | ^

;; Function f (f, funcdef_no=0, decl_uid=1931, cgraph_uid=1, symbol_order=0)

f (int i)
{
  sizetype _1;
  char * _2;

   [local count: 1073741824]:
  i_4 = MIN_EXPR ;
  _1 = (sizetype) i_4;
  _2 =  + _1;
  __builtin_memcpy (_2, "3", 2); [tail call]
  return;

}



;; Function g (g, funcdef_no=1, decl_uid=1934, cgraph_uid=2, symbol_order=1)

g (int i)
{
  sizetype _1;
  char * _2;

   [local count: 1073741824]:
  i_4 = MIN_EXPR ;
  _1 = (sizetype) i_4;
  _2 =  + _1;
  __builtin_sprintf (_2, "%i", 3); [tail call]
  return;

}

[Bug libstdc++/96592] [10 Regression] Tuple element w/ member reference to incomplete template type rejected

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  ---
As further evidence the compile is confused, the preprocessed source from GCC
10 can be compiled by GCC 8, but not GCC 9, 10 or trunk.

It started to be rejected with r262172 (fixing PR c++/80290), but the problem
was latent until r10-908 made std::tuple vulnerable to it.

I'll start reducing the preprocessed source ...

[Bug libstdc++/96592] [10 Regression] Tuple element w/ member reference to incomplete template type rejected

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

Summary|[10/11 Regression] Tuple|[10 Regression] Tuple
   |element w/ member reference |element w/ member reference
   |to incomplete template type |to incomplete template type
   |rejected|rejected

--- Comment #5 from Jonathan Wakely  ---
I've committed a fix to master which makes NO SENSE, but seems to work.

I'll try to figure out what the compiler is confused about and file a bug for
that.

[Bug libstdc++/96592] [10/11 Regression] Tuple element w/ member reference to incomplete template type rejected

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:032a4b42cc5f2105f622690ce2552f1c30e1d227

commit r11-2997-g032a4b42cc5f2105f622690ce2552f1c30e1d227
Author: Jonathan Wakely 
Date:   Thu Sep 3 16:26:16 2020 +0100

libstdc++: Add workaround for weird std::tuple error [PR 96592]

This "fix" makes no sense, but it avoids an error from G++ about
std::is_constructible being incomplete. The real problem is elsewhere,
but this "fixes" the regression for now.

libstdc++-v3/ChangeLog:

PR libstdc++/96592
* include/std/tuple (_TupleConstraints): Use
alternative is_constructible instead of std::is_constructible.
* testsuite/20_util/tuple/cons/96592.cc: New test.

[Bug c++/83591] -Wduplicated-branches fires in system headers in template instantiation

[twan at vitestro dot com]

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

--- Comment #6 from twan at vitestro dot com ---
I ran into this same issue on gcc 7.2.0. 

This issue seems to be resolved in gcc 9.3.0.

[Bug c++/83591] -Wduplicated-branches fires in system headers in template instantiation

[twan at vitestro dot com]

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

twan at vitestro dot com changed:

   What|Removed |Added

 CC||twan at vitestro dot com

--- Comment #5 from twan at vitestro dot com ---
I ran into this same issue on gcc 7.2.0. 

This issue seems to be resolved in gcc 9.3.0.

[Bug target/96808] MMA built-in dies with incorrect sharing of tree nodes error

[bergner at gcc dot gnu.org]

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

Peter Bergner  changed:

   What|Removed |Added

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

--- Comment #4 from Peter Bergner  ---
Pushed to GCC 10, so fixed everywhere.

[Bug libstdc++/96592] [10/11 Regression] Tuple element w/ member reference to incomplete template type rejected

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
I think this is a compiler bug. The same libstdc++ code compiles OK with clang.

The error doesn't really make any sense. std::is_constructible is certainly not
incomplete.

In file included from /home/jwakely/gcc/10/include/c++/10.2.1/bits/move.h:57,
 from
/home/jwakely/gcc/10/include/c++/10.2.1/bits/stl_pair.h:59,
 from /home/jwakely/gcc/10/include/c++/10.2.1/utility:70,
 from /home/jwakely/gcc/10/include/c++/10.2.1/tuple:38,
 from 96592-0.C:1:
/home/jwakely/gcc/10/include/c++/10.2.1/type_traits: In instantiation of
'struct std::__and_, const
SomeQuery&>, std::__not_&, SomeQuery > > > >':
/home/jwakely/gcc/10/include/c++/10.2.1/tuple:487:7:   required from 'static
constexpr bool std::_TupleConstraints<,
_Types>::__is_explicitly_constructible() [with _UTypes = {const
SomeQuery&}; bool  = true; _Types = {SomeQuery}]'
/home/jwakely/gcc/10/include/c++/10.2.1/tuple:549:65:   required by
substitution of 'template
>::_TCC<_Cond>::__is_explicitly_constructible&>(),
bool>::type  > constexpr std::tuple
>::tuple(const SomeQuery&) [with bool _NotEmpty = true; typename
std::enable_if
>::_TCC<_Cond>::__is_explicitly_constructible&>(),
bool>::type  = ]'
/home/jwakely/gcc/10/include/c++/10.2.1/type_traits:901:30:   required from
'struct std::__is_constructible_impl, const
SomeQuery&>'
/home/jwakely/gcc/10/include/c++/10.2.1/type_traits:906:12:   required from
'struct std::is_constructible, const SomeQuery&>'
/home/jwakely/gcc/10/include/c++/10.2.1/type_traits:138:12:   required from
'struct std::__and_, const
SomeQuery&>, std::is_convertible&,
SomeQuery > >'
/home/jwakely/gcc/10/include/c++/10.2.1/tuple:475:7:   required from 'static
constexpr bool std::_TupleConstraints<,
_Types>::__is_implicitly_constructible() [with _UTypes = {const
SomeQuery&}; bool  = true; _Types = {SomeQuery}]'
/home/jwakely/gcc/10/include/c++/10.2.1/tuple:543:65:   required by
substitution of 'template
>::_TCC<_Cond>::__is_implicitly_constructible&>(),
bool>::type  > constexpr std::tuple
>::tuple(const SomeQuery&) [with bool _NotEmpty = true; typename
std::enable_if
>::_TCC<_Cond>::__is_implicitly_constructible&>(),
bool>::type  = ]'
96592-0.C:17:31:   required from here
/home/jwakely/gcc/10/include/c++/10.2.1/type_traits:138:12: error: incomplete
type 'std::is_constructible, const SomeQuery&>'
used in nested name specifier
  138 | struct __and_<_B1, _B2>
  |^~~~
In file included from 96592-0.C:1:
/home/jwakely/gcc/10/include/c++/10.2.1/tuple: In instantiation of 'static
constexpr bool std::_TupleConstraints<,
_Types>::__is_explicitly_constructible() [with _UTypes = {const
SomeQuery&}; bool  = true; _Types = {SomeQuery}]':
/home/jwakely/gcc/10/include/c++/10.2.1/tuple:549:65:   required by
substitution of 'template
>::_TCC<_Cond>::__is_explicitly_constructible&>(),
bool>::type  > constexpr std::tuple
>::tuple(const SomeQuery&) [with bool _NotEmpty = true; typename
std::enable_if
>::_TCC<_Cond>::__is_explicitly_constructible&>(),
bool>::type  = ]'
/home/jwakely/gcc/10/include/c++/10.2.1/type_traits:901:30:   required from
'struct std::__is_constructible_impl, const
SomeQuery&>'
/home/jwakely/gcc/10/include/c++/10.2.1/type_traits:906:12:   required from
'struct std::is_constructible, const SomeQuery&>'
/home/jwakely/gcc/10/include/c++/10.2.1/type_traits:138:12:   required from
'struct std::__and_, const
SomeQuery&>, std::is_convertible&,
SomeQuery > >'
/home/jwakely/gcc/10/include/c++/10.2.1/tuple:475:7:   required from 'static
constexpr bool std::_TupleConstraints<,
_Types>::__is_implicitly_constructible() [with _UTypes = {const
SomeQuery&}; bool  = true; _Types = {SomeQuery}]'
/home/jwakely/gcc/10/include/c++/10.2.1/tuple:543:65:   required by
substitution of 'template
>::_TCC<_Cond>::__is_implicitly_constructible&>(),
bool>::type  > constexpr std::tuple
>::tuple(const SomeQuery&) [with bool _NotEmpty = true; typename
std::enable_if
>::_TCC<_Cond>::__is_implicitly_constructible&>(),
bool>::type  = ]'
96592-0.C:17:31:   required from here
/home/jwakely/gcc/10/include/c++/10.2.1/tuple:487:7: error: 'value' is not a
member of 'std::__and_, const
SomeQuery&>, std::__not_&, SomeQuery > > > >'
  487 |>::value;
  |   ^




If I make this change it compiles with GCC (but with a -Wsystem-headers warning
about using a fold expression in C++11/14 code):

--- /home/jwakely/gcc/10/include/c++/10.2.1/tuple~  2020-09-03
16:05:45.063179301 +0100
+++ /home/jwakely/gcc/10/include/c++/10.2.1/tuple   2020-09-03
16:05:47.804179675 +0100
@@ -466,9 +466,8 @@
   template
static constexpr bool __is_implicitly_constructible()
{
- return __and_...,
-   is_convertible<_UTypes, _Types>...
-   >::value;
+ return (__is_constructible(_Types, _UTypes) && ...)
+&& __and_...>::value;

[Bug target/96808] MMA built-in dies with incorrect sharing of tree nodes error

[cvs-commit at gcc dot gnu.org]

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

--- Comment #3 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Peter Bergner
:

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

commit r10-8706-gabd9341c2f1ae5f7aa73950cdaac58ef3a2f0190
Author: Peter Bergner 
Date:   Tue Sep 1 13:47:44 2020 -0500

rs6000: MMA built-in dies with incorrect sharing of tree nodes error

When we expand our MMA built-ins into gimple, we erroneously reused the
accumulator memory reference for both the source input value as well as
the destination output value.  This led to a tree sharing error.
The solution is to create separate memory references for the input
and output values.

2020-09-01  Peter Bergner  

gcc/
PR target/96808
* config/rs6000/rs6000-call.c (rs6000_gimple_fold_mma_builtin): Do
not
reuse accumulator memory reference for source and destination
accesses.

gcc/testsuite/
PR target/96808
* gcc.target/powerpc/pr96808.c: New test.

(cherry picked from commit 8bc0f24d7a20d89383859907b875a26ce59dc6c8)

[Bug libfortran/96890] Wrong answer with intrinsic IALL

[anlauf at gcc dot gnu.org]

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

--- Comment #5 from anlauf at gcc dot gnu.org ---
(In reply to Steve Kargl from comment #4)
> Ping Thomas.  I recall seeing that he recently was
> asking about --enable-maintainer-mode in a git 
> world.

Hacking the Makfile in x86_64-pc-linux-gnu/libgfortran/Makefile
and manually activating the dependency

$(i_iall_c): m4/iall.m4 $(I_M4_DEPS1)
$(M4) -Dfile=$@ -I$(srcdir)/m4 iall.m4 > $@

does the job, too.

Ugh.

[Bug tree-optimization/96923] Failure to optimize a select-related bool pattern to or+not

[gabravier at gmail dot com]

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

--- Comment #1 from Gabriel Ravier  ---
_Bool f2(_Bool a, _Bool b)
{
return a ? !b : 1;
}

This similar pattern can be optimized to `return !(a & b);`. This
transformation is done by LLVM, but not by GCC.

[Bug fortran/96911] bug with Intrinsic shifta/shiftl/shiftr

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 Resolution|--- |INVALID
 Status|UNCONFIRMED |RESOLVED
 CC||anlauf at gcc dot gnu.org

--- Comment #1 from anlauf at gcc dot gnu.org ---
Error: Integer too big for its kind at (1). This check can be disabled with the
option '-fno-range-check'

Why don't you read what gfortran is telling you, and acting appropriately?

[Bug libfortran/96890] Wrong answer with intrinsic IALL

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #4 from Steve Kargl  ---
On Thu, Sep 03, 2020 at 02:32:32PM +, anlauf at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96890
> 
> --- Comment #3 from anlauf at gcc dot gnu.org ---
> (In reply to kargl from comment #2)
> > 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.
> 
> Well, --enable-maintainer-mode exists, but then I hit for libgomp:
> 

Yes, that's the option.

> WARNING: 'aclocal-1.16' is missing on your system.
> 
> % aclocal --version
> aclocal (GNU automake) 1.15.1

Yep. This is a pain of --enable-maintainer-mode, it 
runs the autotools over the src hierarchy.  There is
supposedly another way to regenerate the libgfortran
source from the m4 files, but I cannot remember it.

> 
> Giving up for someone else to take it up.
> 

Ping Thomas.  I recall seeing that he recently was
asking about --enable-maintainer-mode in a git 
world.

[Bug libfortran/96890] Wrong answer with intrinsic IALL

[anlauf at gcc dot gnu.org]

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

--- Comment #3 from anlauf at gcc dot gnu.org ---
(In reply to kargl from comment #2)
> 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.

Well, --enable-maintainer-mode exists, but then I hit for libgomp:

WARNING: 'aclocal-1.16' is missing on your system.

% aclocal --version
aclocal (GNU automake) 1.15.1

Giving up for someone else to take it up.

[Bug c++/96922] primary expression error when using parenthesis around requires expression for some concepts

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Last reconfirmed||2020-09-03
   Keywords||rejects-valid
  Component|libstdc++   |c++
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #2 from Jonathan Wakely  ---
This is nothing to do with libstdc++, changing component to c++.

Reduced:

template struct trait { static constexpr bool value = true; };

// Not working for concepts with variadic templates
template 
concept constructible_from = trait::value;

template 
requires (constructible_from) // does not work with parenthesis
void foo();

template 
requires constructible_from // works without parenthesis
void bar();

// Working without variadic templates
template 
concept constructible_from_one = trait::value;

template 
requires (constructible_from_one) 
void foo();

Compiles with -std=c++20 but not -std=c++17 -fconcepts

I don't see anything in the Concepts TS grammar which would make this invalid.

[Bug target/96918] Failure to optimize vector shift left+shift right+or to pshuf

[gabravier at gmail dot com]

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

--- Comment #4 from Gabriel Ravier  ---
Oh, now I realise that those headers are actually in fact part of directly
GCC-provided headers and not some external package. I must say though, if those
functions are internal implementation detail and not intended to be stable, I
wonder why they are mentioned so many times in GCC docs (not gccint, the normal
manual), such as here:

'-mcrc32'
 This option enables built-in functions '__builtin_ia32_crc32qi',
 '__builtin_ia32_crc32hi', '__builtin_ia32_crc32si' and
 '__builtin_ia32_crc32di' to generate the 'crc32' machine
 instruction.

or here:

 The following built-in function is always available.

'void __builtin_ia32_pause (void)'
 Generates the 'pause' machine instruction with a compiler memory
 barrier.

or here:

 The following built-in functions are made available by '-mmmx'.  All of
them generate the machine instruction that is part of the name.

 v8qi __builtin_ia32_paddb (v8qi, v8qi)
 v4hi __builtin_ia32_paddw (v4hi, v4hi)
 v2si __builtin_ia32_paddd (v2si, v2si)
 v8qi __builtin_ia32_psubb (v8qi, v8qi)
 v4hi __builtin_ia32_psubw (v4hi, v4hi)
[long list continues, and this is also available for other switches like it]

Which seems to imply that these aren't implementation detail, unless them being
part of the manual is accidental. I don't mind using the Intel intrinsics, but
I still find this quite odd if they are intended to be internal. Could you
clarify this ?

[Bug tree-optimization/96920] [10/11 Regression] ICE segmentation fault in tree-vectorizer at -O3

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code

--- Comment #2 from Richard Biener  ---
So with outer loop vectorization we fail to update an inner PHI backedge value.

(gdb) p debug_gimple_stmt ($2)
vect_prev_57.20_22 = PHI 

[Bug tree-optimization/96920] [10/11 Regression] ICE segmentation fault in tree-vectorizer at -O3

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |10.3
Summary|ICE segmentation fault in   |[10/11 Regression] ICE
   |tree-vectorizer at -O3  |segmentation fault in
   ||tree-vectorizer at -O3
  Component|fortran |tree-optimization
 Status|UNCONFIRMED |ASSIGNED
  Known to fail||10.2.0, 11.0
  Known to work||9.3.0
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
   Last reconfirmed||2020-09-03
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed, I'll take a look.

[Bug d/96924] New: d: ICE in create_tmp_var, at gimple-expr.c:482

[ibuclaw at gdcproject dot org]

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

Bug ID: 96924
   Summary: d: ICE in create_tmp_var, at gimple-expr.c:482
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: ibuclaw at gdcproject dot org
  Reporter: ibuclaw at gdcproject dot org
  Target Milestone: ---

Codegen pass is generating a SAVE_EXPR when it really shouldn't.
---
struct Memo
{
string source;
this(this);
}

void compile(string src, size_t end)
{
Memo[] stack;
stack  ~= Memo(src[end .. $]);
}

[Bug tree-optimization/96923] New: Failure to optimize a select-related bool pattern to or+not

[gabravier at gmail dot com]

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

Bug ID: 96923
   Summary: Failure to optimize a select-related bool pattern to
or+not
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gabravier at gmail dot com
  Target Milestone: ---

_Bool f2(_Bool a, _Bool b)
{
return !a ? !b : 0;
}

This can be optimized to `return !(a | b);`. This transformation is done by
LLVM, but not by GCC.

[Bug libstdc++/89510] [9 Regression] new_allocator::construct needs to be constrained

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #5 from Jonathan Wakely  ---
Fixed for 9.4

[Bug libstdc++/89510] [9 Regression] new_allocator::construct needs to be constrained

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:7f84245366067259bc5604f5abf8b1e0c8e16b71

commit r9-8845-g7f84245366067259bc5604f5abf8b1e0c8e16b71
Author: Jonathan Wakely 
Date:   Thu Apr 30 15:47:52 2020 +0100

libstdc++: Avoid errors in allocator's noexcept-specifier (PR 89510)

This fixes a regression due to the conditional noexcept-specifier on
std::allocator::construct and std::allocator::destroy, as well as the
corresponding members of new_allocator, malloc_allocator, and
allocator_traits. Those noexcept-specifiers were using expressions which
might be ill-formed, which caused errors outside the immediate context
when checking for the presence of construct and destroy in SFINAE
contexts.

The fix is to use the is_nothrow_constructible and
is_nothrow_destructible type traits instead, because those traits are
safe to use even when the construction/destruction itself is not valid.

The is_nothrow_constructible trait will be false for a type that is not
also nothrow-destructible, even if the new-expression used in the
construct function body is actually noexcept. That's not the correct
answer, but isn't a problem because providing a noexcept-specifier on
these functions is not required by the standard anyway. If the answer is
false when it should be true, that's suboptimal but OK (unlike giving
errors for valid code, or giving a true answer when it should be false).

PR libstdc++/89510
* include/bits/alloc_traits.h (allocator_traits::_S_construct)
(allocator_traits::_S_destroy)
(allocator_traits>::construct): Use traits in
noexcept-specifiers.
* include/bits/allocator.h (allocator::construct)
(allocator::destroy): Likewise.
* include/ext/malloc_allocator.h (malloc_allocator::construct)
(malloc_allocator::destroy): Likewise.
* include/ext/new_allocator.h (new_allocator::construct)
(new_allocator::destroy): Likewise.
* testsuite/20_util/allocator/89510.cc: New test.
* testsuite/ext/malloc_allocator/89510.cc: New test.
* testsuite/ext/new_allocator/89510.cc: New test.

(cherry picked from commit b1983f4582bbe060b7da83578acb9ed653681fc8)

[Bug libstdc++/96922] primary expression error when using parenthesis around requires expression for some concepts

[rene.r...@fu-berlin.de]

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

--- Comment #1 from Rene Rahn  ---
Also note, that this does not happen in c++20 mode using gcc-10.2 (see link to
compiler explorer).

[Bug libstdc++/96922] New: primary expression error when using parenthesis around requires expression for some concepts

[rene.r...@fu-berlin.de]

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

Bug ID: 96922
   Summary: primary expression error when using parenthesis around
requires expression for some concepts
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rene.r...@fu-berlin.de
  Target Milestone: ---

Hi GCC team, 

I found a strange behavior when using c++17 mode with -fconcepts on gcc 10 as
well as gcc 9. Basically, if we use a concept that uses variadic templates then
the compiler emits a primary expression error when putting parenthesis around
the requires expression. This does not happen if we leave the parenthesis away
or if the concept does not use variadic templates.

Here the example I ran into (https://godbolt.org/z/95d4Y3):
```cpp
#include 

// Not working for concepts with variadic templates
template 
concept constructible_from = std::is_constructible_v;

template 
requires (constructible_from) // does not work with parenthesis
void foo();

template 
requires constructible_from // works without parenthesis
void bar();

// Working without variadic templates
template 
concept constructible_from_one = std::is_constructible_v;

template 
requires (constructible_from_one) 
void foo();

```

Thank you very much for your help.

[Bug tree-optimization/96921] New: Failure to optimize combined boolean not patterns

[gabravier at gmail dot com]

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

Bug ID: 96921
   Summary: Failure to optimize combined boolean not patterns
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gabravier at gmail dot com
  Target Milestone: ---

_Bool f(_Bool a, _Bool b)
{
return 1 - ((1 - a) & (1 - b));
}

This can be optimized to `return a | b;`. This transformation is done by LLVM,
but not by GCC.

[Bug c/96916] warning: ‘strndup’ specified bound 18446744073709551615 exceeds maximum object size 9223372036854775807 [-Wstringop-overflow=]

[msebor at gcc dot gnu.org]

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

--- Comment #3 from Martin Sebor  ---
For strndup POSIX mentions the following application usage:

Implementations are free to malloc() a buffer containing either (size + 1)
bytes or (strnlen(s, size) + 1) bytes. Applications should not assume that
strndup() will allocate ( size + 1) bytes when strlen(s) is smaller than size.

[Bug c/96916] warning: ‘strndup’ specified bound 18446744073709551615 exceeds maximum object size 9223372036854775807 [-Wstringop-overflow=]

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID
 CC||msebor at gcc dot gnu.org

--- Comment #2 from Martin Sebor  ---
Yes, the warning is by design and is issued for any built-in function that
takes an argument specifying the size of an object (malloc, memcpy, etc.). 
It's meant to help identify calls to allocation functions that are certain to
fail or that will overflow the destination.  Passing in PTRDIFF_MAX instead
should avoid the warning (as would of course calling strdup).

[Bug fortran/96920] New: ICE segmentation fault in tree-vectorizer at -O3

[hj8758558 at gmail dot com]

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

Bug ID: 96920
   Summary: ICE segmentation fault in tree-vectorizer at -O3
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hj8758558 at gmail dot com
  Target Milestone: ---

Created attachment 49179
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49179=edit
Example Fortran source file to trigger ICE in tree-vectorizer.

When I compile the attached code example with gfortran 10.x series at -O3, I
get the following compiler seg fault. The code compiles okay with gfortran 9.1.

The only previous bug report that I found that might be related is:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95539


$ gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/users/joshua.hykes/opt/gcc/linux-64/gcc-10.2.0/bin/../libexec/gcc/x86_64-pc-linux-gnu/10.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with:
/users/joshua.hykes/opt/gcc/linux-64/gcc-10.2.0-build/../gcc-10.2.0-src/configure
--prefix=/users/joshua.hykes/opt/gcc/linux-64/gcc-10.2.0-build/../gcc-10.2.0/
--enable-languages=c,c++,fortran,go
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.2.0 (GCC)



$ cat ice.f90
 subroutine ice(npoint, nterm, x, g)
 implicit none
 integernorder
 parameter (norder=10)
 integer j
 integer k
 integer ii
 integer nterm
 integer npoint
 real b(norder)
 real c(norder)
 real d(norder)
 real x(npoint)
 real g(npoint)
 real gg
 real prev
 real prev2
 !
 j = 1
   100   continue
 j = j+1
 if (nterm == j)  then
do ii=1,npoint
   k = nterm
   gg= d(k)
   prev= 0.0
   do k=k-1,1,-1
  prev2= prev
  prev= gg
  gg = d(k)+(x(ii)-b(k))*prev-c(k+1)*prev2
   enddo
   g(ii) = gg
enddo
 endif
 go to 100
 end


$ gfortran -O3 -c ice.f90
during GIMPLE pass: vect
ice.f90:1:0:

1 |  subroutine ice(npoint, nterm, x, g)
  |
internal compiler error: Segmentation fault
0xbeddaf crash_signal
   
/users/joshua.hykes/opt/gcc/linux-64/gcc-10.2.0-build/../gcc-10.2.0-src/gcc/toplev.c:328
0x2b14706162ef ???
   
/usr/src/debug/glibc-2.17-c758a686/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0
0xd01227 find_uses_to_rename_use
   
/users/joshua.hykes/opt/gcc/linux-64/gcc-10.2.0-build/../gcc-10.2.0-src/gcc/tree-ssa-loop-manip.c:393
0xd01227 find_uses_to_rename_bb
   
/users/joshua.hykes/opt/gcc/linux-64/gcc-10.2.0-build/../gcc-10.2.0-src/gcc/tree-ssa-loop-manip.c:468
0xd02e57 find_uses_to_rename
   
/users/joshua.hykes/opt/gcc/linux-64/gcc-10.2.0-build/../gcc-10.2.0-src/gcc/tree-ssa-loop-manip.c:500
0xd02e57 rewrite_into_loop_closed_ssa_1(bitmap_head*, unsigned int, int, loop*)
   
/users/joshua.hykes/opt/gcc/linux-64/gcc-10.2.0-build/../gcc-10.2.0-src/gcc/tree-ssa-loop-manip.c:666
0xe17043 vectorize_loops()
   
/users/joshua.hykes/opt/gcc/linux-64/gcc-10.2.0-build/../gcc-10.2.0-src/gcc/tree-vectorizer.c:1197
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug target/96918] Failure to optimize vector shift left+shift right+or to pshuf

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
The __builtin_ia32_* builtins are implementation detail, we don't guarantee
them between releases, they can be added or removed, the only supported thing
are the _mm* intrinsics in the headers.  E.g. sometimes we replace a builtin
with just generic C code if it can do e.g. with generic vectors what the
builtin was doing before.
So, for testcases, unless we test for something that can't be reproduced with
the intrinsics and can be only reproduced with the builtins, we strongly prefer
using the supported intrinsics.

[Bug gcov-profile/96919] New: [GCOV] uncovered line of stack allocation while using virutal destructor

[youngseok.roh.de at gmail dot com]

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

Bug ID: 96919
   Summary: [GCOV] uncovered line of stack allocation while using
virutal destructor
   Product: gcc
   Version: 8.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: gcov-profile
  Assignee: unassigned at gcc dot gnu.org
  Reporter: youngseok.roh.de at gmail dot com
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

I have different result since GCC8. It looks like connecting to the virtual
destructor.

<~ GCC 7.4.0>
$ cat main.cpp.gcov 
-:0:Source:main.cpp
-:0:Graph:main.gcno
-:0:Data:main.gcda
-:0:Runs:1
-:0:Programs:1
-:1:#include "hello.h"
-:2:
1:3:int main(int argc, char* argv[]) {
2:4:  Hello hello;
1:5:  hello.foo();
1:6:  return 0;
-:7:}
-:8:

$ cat main.cpp.gcov 
-:0:Source:main.cpp
-:0:Graph:main.gcno
-:0:Data:main.gcda
-:0:Runs:1
-:0:Programs:1
-:1:#include "hello.h"
-:2:
1:3:int main(int argc, char* argv[]) {
#:4:  Hello hello;
1:5:  hello.foo();
1:6:  return 0;
-:7:}
-:8:

Example code is here, and commands as well.
$ cat hello.h
class Base {
public:
  Base() = default;
  virtual ~Base() = default;
  virtual void foo() = 0;
};
class Hello : public Base {
public:
  Hello() = default;
  ~Hello() = default;
  void foo() override;
};

$ cat hello.cpp 
#include "hello.h"
#include 

using namespace std;

void Hello::foo() {
  cout << "hello" << endl;
}

$ cat main.cpp
#include "hello.h"

int main(int argc, char* argv[]) {
  Hello hello;
  hello.foo();
  return 0;
}

g++ -g -c --coverage -O0 -std=c++11 hello.cpp
g++ -g -c --coverage -O0 -std=c++11 main.cpp
g++ -o test hello.o main.o --coverage -O0

[Bug target/96918] Failure to optimize vector shift left+shift right+or to pshuf

[gabravier at gmail dot com]

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

--- Comment #2 from Gabriel Ravier  ---
Yes, you can reproduce this with _mm_shuffle_epi8, _mm_slli_epi16 and
_mm_srli_epi16. I'm assuming GCC developers are more familiar with the internal
intrinsics than with the Intel-provided intrinsics, so I didn't bother
converting it to Intel intrinsics, is that wrong ?

[Bug target/96918] Failure to optimize vector shift left+shift right+or to pshuf

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Biener  ---
Note it's not so interesting to handle testcases with __builtin_ia32_* which
are internal but I guess the same can be replicated using intrinsics?

[Bug target/96898] [nvptx] libatomic support

[vries at gcc dot gnu.org]

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

Tom de Vries  changed:

   What|Removed |Added

 CC||jakub at redhat dot com

--- Comment #1 from Tom de Vries  ---
Hmm, so libatomic needs to fall back onto protect_start and protect_end.

It would make sense for the openmp/openacc programs to have that map onto
GOMP_start/GOMP_stop.

But this introduces a dependency of libatomic on libgomp.  Not ideal, I
suppose.

Maybe we could (at least for the nvptx case) move the global lock out of
libgomp into libatomic, and have a dependency of libgomp on libatomic instead.

[Bug target/96918] New: Failure to optimize vector shift left+shift right+or to pshuf

[gabravier at gmail dot com]

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

Bug ID: 96918
   Summary: Failure to optimize vector shift left+shift right+or
to pshuf
   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_TYPE__ v8i16 __attribute__((vector_size(16)));
typedef char v16i8 __attribute__((vector_size(16)));

v8i16 bswap_epi16(v8i16 x)
{
return __builtin_ia32_psllwi128(x, 8) | __builtin_ia32_psrlwi128(x, 8);
}

This can be optimized to `return (v8i16)__builtin_ia32_pshufb128((v16i8)x,
v16i8{1, 0, 3, 2, 5, 4, 7, 6, 9, 8, 11, 10, 13, 12, 15, 14});`. This
transformation is done by LLVM, but not by GCC.

[Bug tree-optimization/96915] ICE in tree-switch-conversion

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
tree-cfg.c only handles INTEGER_CST, so either we should check for just that in
the assertion, or better just drop it.  Dependence on some other pass
performing some optimization is IMHO bad, what if that pass hasn't run for some
reason, due to debug counters or whatever else.
If it doesn't want to handle INTEGER_CSTs, then it can always punt on them with
a reason that some other pass should handle those cases.

[Bug tree-optimization/96915] ICE in tree-switch-conversion

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
  /* A switch on a constant should have been optimized in tree-cfg-cleanup.  */
  gcc_checking_assert (!TREE_CONSTANT (m_index_expr));

guess a POLY_INT_CST isn't really a constant so this check needs adjustment
(using TREE_CONSTANT is odd anyway).  The question is what goes wrong when
m_index_expr is constant?  I hope nothing.

[Bug c/96916] warning: ‘strndup’ specified bound 18446744073709551615 exceeds maximum object size 9223372036854775807 [-Wstringop-overflow=]

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||diagnostic

--- Comment #1 from Richard Biener  ---
There's an implementation-defined limit of object sizes induced by the
representation of the difference of addresses into such object which
is then exactly half the address space.

[Bug lto/94311] LTO produces line info entries with invalid line numbers

[cvs-commit at gcc dot gnu.org]

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

--- Comment #18 from CVS Commits  ---
The master branch has been updated by Jakub Jelinek :

https://gcc.gnu.org/g:3536ff2de8317c430546fd97574d44c5146cef2b

commit r11-2995-g3536ff2de8317c430546fd97574d44c5146cef2b
Author: Jakub Jelinek 
Date:   Thu Sep 3 12:51:01 2020 +0200

lto: Cache location_ts including BLOCKs in GIMPLE streaming [PR94311]

As mentioned in the PR, when compiling valgrind even on fairly small
testcase where in one larger function the location keeps oscillating
between a small line number and 8000-ish line number in the same file
we very quickly run out of all possible location_t numbers and because of
that emit non-sensical line numbers in .debug_line.
There are ways how to decrease speed of depleting location_t numbers
in libcpp, but the main reason of this is that we use
stream_input_location_now for streaming in location_t for gimple_location
and phi arg locations.  libcpp strongly prefers that the locations
it is given are sorted by the different files and by line numbers in
ascending order, otherwise it depletes quickly no matter what and is much
more costly (many extra file changes etc.).
The reason for not caching those were the BLOCKs that were streamed
immediately after the location and encoded into the locations (and for PHIs
we failed to stream the BLOCKs altogether).
This patch enhances the location cache to handle also BLOCKs (but not for
everything, only for the spots we care about the BLOCKs) and also optimizes
the size of the LTO stream by emitting a single bit into a pack whether the
BLOCK changed from last case and only streaming the BLOCK tree if it
changed.

2020-09-03  Jakub Jelinek  

PR lto/94311
* gimple.h (gimple_location_ptr, gimple_phi_arg_location_ptr): New
functions.
* streamer-hooks.h (struct streamer_hooks): Add
output_location_and_block callback.  Fix up formatting for
output_location.
(stream_output_location_and_block): Define.
* lto-streamer.h (class lto_location_cache): Fix comment typo.  Add
current_block member.
(lto_location_cache::input_location_and_block): New method.
(lto_location_cache::lto_location_cache): Initialize current_block.
(lto_location_cache::cached_location): Add block member.
(struct output_block): Add current_block member.
(lto_output_location): Formatting fix.
(lto_output_location_and_block): Declare.
* lto-streamer.c (lto_streamer_hooks_init): Initialize
streamer_hooks.output_location_and_block.
* lto-streamer-in.c (lto_location_cache::cmp_loc): Also compare
block members.
(lto_location_cache::apply_location_cache): Handle blocks.
(lto_location_cache::accept_location_cache,
lto_location_cache::revert_location_cache): Fix up function
comments.
(lto_location_cache::input_location_and_block): New method.
(lto_location_cache::input_location): Implement using
input_location_and_block.
(input_function): Invoke apply_location_cache after streaming in
all
bbs.
* lto-streamer-out.c (clear_line_info): Set current_block.
(lto_output_location_1): New function, moved from
lto_output_location,
added block handling.
(lto_output_location): Implement using lto_output_location_1.
(lto_output_location_and_block): New function.
* gimple-streamer-in.c (input_phi): Use input_location_and_block
to input and cache both location and block.
(input_gimple_stmt): Likewise.
* gimple-streamer-out.c (output_phi): Use
stream_output_location_and_block.
(output_gimple_stmt): Likewise.

[Bug c++/96905] [10/11 Regression] 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

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|--- |10.3
Summary|ICE with consteval  |[10/11 Regression] ICE with
   |function: internal compiler |consteval function:
   |error: in cp_gimplify_expr, |internal compiler error: in
   |at cp/cp-gimplify.c:827 |cp_gimplify_expr, at
   ||cp/cp-gimplify.c:827
 CC||jason at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
The problem is in
#0  cgraph_node::create (decl=) at
../../gcc/cgraph.c:508
#1  0x00f2b79c in cgraph_node::get_create (decl=) at ../../gcc/cgraph.c:541
#2  0x00b0a700 in mark_needed (decl=)
at ../../gcc/cp/decl2.c:2181
#3  0x00cb25b6 in mark_decl_instantiated (result=, extern_p=0) at ../../gcc/cp/pt.c:23893
#4  0x00cb6b35 in do_type_instantiation (t=, storage=, complain=1) at ../../gcc/cp/pt.c:25041
#5  0x00befb77 in cp_parser_explicit_instantiation
(parser=0x7fffea8238e8) at ../../gcc/cp/parser.c:17588

for DECL_IMMEDIATE_FUNCTION_P FUNCTION_DECLs, we really don't want to register
them with the middle-end.  The big question is, do we really care about
explicit vs. implicit instantiation for them.  I mean, if something calls the
consteval function, it doesn't really matter if we instantiate them implicitly
or explicitly.  Where it could matter is diagnostics, if the consteval function
is never called or never called instantiated with a particular template
arguments, and its definition is invalid with those template arguments (but not
invalid to be rejected when parsed uninstantiated).
So if we care about the implicit vs. explicit instantiation of consteval,
perhaps we should just not create the cgraph node in mark_needed for
DECL_IMMEDIATE_FUNCTION_P?

[Bug c++/96917] New: decltype(auto) variable initialized with lambda by-reference capture has incorrect type

[andrey.vihrov at gmail dot com]

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

Bug ID: 96917
   Summary: decltype(auto) variable initialized with lambda
by-reference capture has incorrect type
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: andrey.vihrov at gmail dot com
  Target Milestone: ---

Consider

#include 

int main()
{
int x = 5;

[&]() {
decltype(auto) b = x;
static_assert(std::is_same::value, "types should
match");
};
}

When compiled simply with "g++ x.cpp", this gives

x.cpp: In lambda function:
x.cpp:9:59: error: static assertion failed: types should match
9 | static_assert(std::is_same::value, "types
should match");
  |   ^

Note that replacing decltype(auto) with decltype(x) fixes the error. Clang
accepts both assertions.

Although it is not specified explicitly, from
http://eel.is/c++draft/expr.prim.lambda.capture it may seem that the variable
captured by reference has the original type and not the reference type inside
the lambda. Please correct me if this is wrong.

gcc -v:
Using built-in specs.
COLLECT_GCC=gcc
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)

[Bug tree-optimization/96915] ICE in tree-switch-conversion

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

  Known to fail||10.1.1

--- Comment #1 from ktkachov at gcc dot gnu.org ---
Reproduced on the GCC 10 branch as well. Since SVE ACLE intrinsics were only
added in GCC 10 it's technically not a regression

[Bug c/96916] New: warning: ‘strndup’ specified bound 18446744073709551615 exceeds maximum object size 9223372036854775807 [-Wstringop-overflow=]

[rjones at redhat dot com]

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

Bug ID: 96916
   Summary: warning: ‘strndup’ specified bound
18446744073709551615 exceeds maximum object size
9223372036854775807 [-Wstringop-overflow=]
   Product: gcc
   Version: 10.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rjones at redhat dot com
  Target Milestone: ---

I'm not certain this is really a bug, but I don't understand it.  A simple
reproducer:

--
#include 
#include 
#include 
#include 

const char *
copyn (const char *str, size_t n)
{
  return strndup (str, n);
}

const char *
copy (const char *str)
{
  return copyn (str, SIZE_MAX);
}
--

$ gcc -O2 -Wall -c test.c
In function ‘copyn’,
inlined from ‘copy’ at test.c:15:10:
test.c:9:10: warning: ‘strndup’ specified bound 18446744073709551615 exceeds
maximum object size 9223372036854775807 [-Wstringop-overflow=]
9 |   return strndup (str, n);
  |  ^~~~

$ gcc --version
gcc (GCC) 10.2.1 20200826 (Red Hat 10.2.1-3)
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


Note that it seems as if the compiler is claiming that strndup cannot cope with
a string larger than ssize_t (rather than size_t), which is unexpected.

[Bug tree-optimization/96915] New: ICE in tree-switch-conversion

[ktkachov at gcc dot gnu.org]

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

Bug ID: 96915
   Summary: ICE in tree-switch-conversion
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ktkachov at gcc dot gnu.org
  Target Milestone: ---
Target: aarch64*-*-*

The following SVE intrinsics code ICEs with -O3 -march=armv8.2-a+sve

#include 

void b (void);

void
a ()
{
  switch (svcntd())
  case 2:
  case 4:
b();
}

during GIMPLE pass: switchconv
foo.c: In function 'a':
foo.c:12:1: internal compiler error: in expand, at tree-switch-conversion.c:988
   12 | }
  | ^
0xe475f1 tree_switch_conversion::switch_conversion::expand(gswitch*)
$SRC/gcc/tree-switch-conversion.c:988
0xe478ae execute
$SRC/gcc/tree-switch-conversion.c:2401
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug target/87767] Missing AVX512 memory broadcast for constant vector

[jakub at gcc dot gnu.org]

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

--- Comment #12 from Jakub Jelinek  ---
What I mean is that we should try to simplify the md file, instead of adding
hundreds of new *_bcst patterns.
We have e.g.
(define_insn "*3"
  [(set (match_operand:VI_AVX2 0 "register_operand" "=x,v")
(plusminus:VI_AVX2
  (match_operand:VI_AVX2 1 "vector_operand" "0,v")
  (match_operand:VI_AVX2 2 "vector_operand" "xBm,vm")))]
  "TARGET_SSE2 && ix86_binary_operator_ok (, mode, operands)"
  "@
   p\t{%2, %0|%0, %2}
   vp\t{%2, %1, %0|%0, %1, %2}"
  [(set_attr "isa" "noavx,avx")
   (set_attr "type" "sseiadd")
   (set_attr "prefix_data16" "1,*")
   (set_attr "prefix" "orig,vex")
   (set_attr "mode" "")])

(define_insn "*sub3_bcst"
  [(set (match_operand:VI48_AVX512VL 0 "register_operand" "=v")
(minus:VI48_AVX512VL
  (match_operand:VI48_AVX512VL 1 "register_operand" "v")
  (vec_duplicate:VI48_AVX512VL
(match_operand: 2 "memory_operand" "m"]
  "TARGET_AVX512F && ix86_binary_operator_ok (MINUS, mode, operands)"
  "vpsub\t{%2, %1, %0|%0, %1, %2}"
  [(set_attr "type" "sseiadd")
   (set_attr "prefix" "evex")
   (set_attr "mode" "")])

What I meant is we could have just:
(define_insn "*3"
  [(set (match_operand:VI_AVX2 0 "register_operand" "=x,v")
(plusminus:VI_AVX2
  (match_operand:VI_AVX2 1 "vector_bcst_operand" "0,v")
  (match_operand:VI_AVX2 2 "vector_bcst_operand" "xBm,vBb")))]
  "TARGET_SSE2 && ix86_binary_operator_ok (, mode, operands)"
  "@
   p\t{%2, %0|%0, %2}
   vp\t{%2, %1, %0|%0, %1, %2}"
  [(set_attr "isa" "noavx,avx")
   (set_attr "type" "sseiadd")
   (set_attr "prefix_data16" "1,*")
   (set_attr "prefix" "orig,vex")
   (set_attr "mode" "")])
where vector_bcst_operand is either vector_operand, or for TARGET_AVX512F
a VEC_DUPLICATE of the right mode with a MEM inside of it with the element mode
of the VEC_DUPLICATE mode, similarly Bb constraint is either m, or for
TARGET_AVX512F also again the VEC_DUPLICATE with MEM inside of it, and that
ix86_binary_operator_ok would treat a VEC_DUPLICATE wrapping MEM the same as
MEM (in particular ensure one e.g. doesn't have one VEC_DUPLICATE and one MEM
operand, or two VEC_DUPLICATE operands) and that the output code would handle
emitting an operand with VEC_DUPLICATE of a MEM properly.
Or perhaps the constraint there could be just for the broadcast and one could
write vmBb.  Still, I think the predicate needs to be accurate, i.e. for some
instructions we want e.g. vector_operand or TARGET_AVX512F and
bcst_mem_operand,
for others vector_operand or TARGET_AVX512VL and bcst_mem_operand etc.

Anyway, if we go down this route, might be best to handle just a couple of
patterns, then ask for review and see what Kirill (or if Uros would be
interested) think about it and only later convert more.

[Bug target/96914] missing MVE intrinsics

[clyon at gcc dot gnu.org]

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

Christophe Lyon  changed:

   What|Removed |Added

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

[Bug target/96914] New: missing MVE intrinsics

[clyon at gcc dot gnu.org]

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

Bug ID: 96914
   Summary: missing MVE intrinsics
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: clyon at gcc dot gnu.org
  Target Milestone: ---

Applying the same process as in PR71233, I have noticed a few MVE intrinsics
are not implemented:
__arm_vcvtnq_u32_f32
__arm_vqdmlashq_m_n_s16
__arm_vqdmlashq_m_n_s32
__arm_vqdmlashq_m_n_s8
__arm_vqdmlashq_n_s16
__arm_vqdmlashq_n_s32
__arm_vqdmlashq_n_s8


FTR, I downloaded the full list from
https://developer.arm.com/architectures/instruction-sets/simd-isas/helium/helium-intrinsics
I parsed it with the same script provided in PR71233, I preprocessed a sample
hello-mve.c containing only:
#include 
with -mcpu=cortex-m55 -mfloat-abi=hard
and checked if any of the intrinsics defined in the doc was missing from the
preprocessed hello-mve.i, after removing the brackets from intrinsic names such
as [__arm_]vidupq_x[_n]_u16

This results in the short list above.

[Bug target/87767] Missing AVX512 memory broadcast for constant vector

[crazylht at gmail dot com]

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

--- Comment #11 from Hongtao.liu  ---
(In reply to Jakub Jelinek from comment #10)
> Do we really need separate _bcst patterns btw?  Wouldn't it be better to
> just have some predicate and corresponding constaint that would allow normal

In currently implementation, vec_duplicate would be used for memory_operand in
broadcast patterns. I'm not sure if vec_duplicate could be used in
define_predicate, or am i misunderstood?

> MEM vectors as well as these broadcast from single element and just use that
> predicate wherever the broadcasts are allowed?  Probably would need multiple
> of them though, even when the main would turn to be just memory_operand if
> TARGET_AVX512F is false, some instructions only use EVEX encoding if some
> other TARGET_AVX* is on...

[Bug target/87767] Missing AVX512 memory broadcast for constant vector

[jakub at gcc dot gnu.org]

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

--- Comment #10 from Jakub Jelinek  ---
Do we really need separate _bcst patterns btw?  Wouldn't it be better to just
have some predicate and corresponding constaint that would allow normal MEM
vectors as well as these broadcast from single element and just use that
predicate wherever the broadcasts are allowed?  Probably would need multiple of
them though, even when the main would turn to be just memory_operand if
TARGET_AVX512F is false, some instructions only use EVEX encoding if some other
TARGET_AVX* is on...

[Bug target/87767] Missing AVX512 memory broadcast for constant vector

[crazylht at gmail dot com]

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

--- Comment #9 from Hongtao.liu  ---
I think it's fixed in GCC11, but still there're lots of "_bcst" patterns need
to be added.

[Bug target/96769] -mpure-code produces suboptimal code for immediate generation for thumb-1

[clyon at gcc dot gnu.org]

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

Christophe Lyon  changed:

   What|Removed |Added

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

--- Comment #1 from Christophe Lyon  ---
Patch proposal sent:
https://gcc.gnu.org/pipermail/gcc-patches/2020-September/553196.html

[Bug target/87767] Missing AVX512 memory broadcast for constant vector

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:433734126996b6fc4fc99b594421510f928a7bb9

commit r11-2991-g433734126996b6fc4fc99b594421510f928a7bb9
Author: liuhongt 
Date:   Wed Jul 8 17:14:36 2020 +0800

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.

[Bug tree-optimization/96912] Failure to optimize pblendvb pattern

[glisse at gcc dot gnu.org]

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

--- Comment #2 from Marc Glisse  ---
With consistent types, we recognize a VEC_COND_EXPR. With inconsistent types, I
guess we would need to reinterpret x and y as v16i8, and reinterpret the result
back to v2i64.

(please keep #include  in your testcases so we can just copy-paste
and compile them, or use long long instead of int64_t)

[Bug tree-optimization/96912] Failure to optimize pblendvb pattern

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Last reconfirmed||2020-09-03
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
On GIMPLE this could be pattern-matched to a VEC_PERM_EXPR <> which is
how to represent blends.  Of course matching this on RTL is possible as well.

The difficulty is of course the mismatch in element sizes where the
mask appears to be byte granular while the data to be blended is double-words.

[Bug target/96899] [10 Regression] [SH] Bootstrap fails when building libgomp

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #3 from John Paul Adrian Glaubitz  ---
I managed to successfully perform a local build natively with an updated
version of QEMU.

I have updated QEMU on the build servers as well and rescheduled the gcc-10
package.

Let's see if it builds fine now, then we can hopefully close this as invalid.

[Bug gcov-profile/96913] gcc-11: __gcov_merge_topn hangs

[slyfox at gcc dot gnu.org]

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

--- Comment #1 from Sergei Trofimovich  ---
Created attachment 49178
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49178=edit
_json.gcda

Attaching _json.gcda in case it will shed the light if file was written
incorrectly previously or it's a deserialization problem.

[Bug gcov-profile/96913] New: gcc-11: __gcov_merge_topn hangs

[slyfox at gcc dot gnu.org]

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

Bug ID: 96913
   Summary: gcc-11: __gcov_merge_topn hangs
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: gcov-profile
  Assignee: unassigned at gcc dot gnu.org
  Reporter: slyfox at gcc dot gnu.org
CC: hubicka at gcc dot gnu.org, marxin at gcc dot gnu.org,
mliska at suse dot cz
  Target Milestone: ---

The hang happens on real tauthon-2.8.2 interpreter from PR96394 (no nice
reproducer yet).

In this instance I tried to build tauthon-2.8.2 against gcc-master. It hangs
early when tries to merge topn entry:

"""
#0  0x7fd73865e0ce in __GI___libc_read (fd=3, buf=0x406284 <__gcov_var+36>,
nbytes=4096) at ../sysdeps/unix/sysv/linux/read.c:26
#1  0x7fd7385f0090 in __GI__IO_file_xsgetn (fp=0x1295bc0, data=, n=4096) at libioP.h:948
#2  0x7fd7385e4d1f in __GI__IO_fread (buf=0x406284 <__gcov_var+36>, size=1,
count=4096, fp=0x1295bc0) at iofread.c:38
#3  0x7fd72ab4237e in gcov_read_words (words=2) at
../../../gcc/libgcc/../gcc/gcov-io.c:491
#4  0x7fd72ab42483 in __gcov_read_counter () at
../../../gcc/libgcc/../gcc/gcov-io.c:528
#5  0x7fd72ab4190e in gcov_get_counter_target () at
../../../gcc/libgcc/libgcov.h:383
#6  0x7fd72ab41c6b in __gcov_merge_topn (counters=0x7fd72ab4d320
<__gcov4.encoder_clear>, n_counters=24) at
../../../gcc/libgcc/libgcov-merge.c:114
#7  0x7fd72ab43569 in merge_one_data (
filename=0x1154290
"/tmp/portage/dev-lang/tauthon-2.8.2/work/x86_64-pc-linux-gnu/build/temp.linux-x86_64-2.8/tmp/portage/dev-lang/tauthon-2.8.2/work/tauthon-2.8.2/Modules/_json.gcda",
gi_ptr=0x7fd72ab4a180, summary=0x7ffde7d6e9c0) at
../../../gcc/libgcc/libgcov-driver.c:314
#8  0x7fd72ab43b1a in dump_one_gcov (gi_ptr=0x7fd72ab4a180,
gf=0x7ffde7d6ea00, run_counted=0, run_max=125)
at ../../../gcc/libgcc/libgcov-driver.c:492
#9  0x7fd72ab43cba in gcov_do_dump (list=0x7fd72ab4a180, run_counted=0) at
../../../gcc/libgcc/libgcov-driver.c:555
#10 0x7fd72ab43d28 in __gcov_dump_one (root=0x7fd72ab4e5c0 <__gcov_root>)
at ../../../gcc/libgcc/libgcov-driver.c:578
#11 0x7fd72ab43d5d in __gcov_exit () at
../../../gcc/libgcc/libgcov-driver.c:600
#12 0x7fd738c460a3 in _dl_fini () at dl-fini.c:139
#13 0x7fd7385af564 in __run_exit_handlers (status=0, listp=0x7fd73872a738
<__exit_funcs>, run_list_atexit=run_list_atexit@entry=true,
run_dtors=run_dtors@entry=true) at exit.c:108
#14 0x7fd7385af70a in __GI_exit (status=) at exit.c:139
#15 0x7fd73899534e in Py_Exit () from
/tmp/portage/dev-lang/tauthon-2.8.2/work/x86_64-pc-linux-gnu/libtauthon2.8.so.1.0
#16 0x7fd738995533 in handle_system_exit () from
/tmp/portage/dev-lang/tauthon-2.8.2/work/x86_64-pc-linux-gnu/libtauthon2.8.so.1.0
#17 0x7fd73899588e in PyErr_PrintEx () from
/tmp/portage/dev-lang/tauthon-2.8.2/work/x86_64-pc-linux-gnu/libtauthon2.8.so.1.0
#18 0x7fd738995e44 in PyErr_Print () from
/tmp/portage/dev-lang/tauthon-2.8.2/work/x86_64-pc-linux-gnu/libtauthon2.8.so.1.0
#19 0x7fd7389b851e in RunModule () from
/tmp/portage/dev-lang/tauthon-2.8.2/work/x86_64-pc-linux-gnu/libtauthon2.8.so.1.0
#20 0x7fd7389b9075 in Py_Main () from
/tmp/portage/dev-lang/tauthon-2.8.2/work/x86_64-pc-linux-gnu/libtauthon2.8.so.1.0
#21 0x004012ac in main ()
"""

Looks like the problem is in decoding of some tag in __gcov_merge_topn(). There
count of entries is huge:

"""
(gdb) frame 6
#6  0x7fd72ab41c6b in __gcov_merge_topn (counters=0x7fd72ab4d320
<__gcov4.encoder_clear>, n_counters=24) at
../../../gcc/libgcc/libgcov-merge.c:114
114   gcov_type value = gcov_get_counter_target ();
(gdb) list __gcov_merge_topn
96 -- counter
97 */
98
99  void
100 __gcov_merge_topn (gcov_type *counters, unsigned n_counters)
101 {
102   gcc_assert (!(n_counters % GCOV_TOPN_MEM_COUNTERS));
103
104   for (unsigned i = 0; i < (n_counters / GCOV_TOPN_MEM_COUNTERS); i++)
105 {
(gdb)
106   /* First value is number of total executions of the profiler.  */
107   gcov_type all = gcov_get_counter_ignore_scaling (-1);
108   gcov_type n = gcov_get_counter_ignore_scaling (-1);
109
110   counters[GCOV_TOPN_MEM_COUNTERS * i] += all;
111
112   for (unsigned j = 0; j < n; j++)
113 {
114   gcov_type value = gcov_get_counter_target ();
115   gcov_type count = gcov_get_counter_ignore_scaling (-1);
(gdb)
116
117   // TODO: we should use atomic here
118   gcov_topn_add_value (counters + GCOV_TOPN_MEM_COUNTERS * i,
value,
119count, 0, 0);
120 }
121 }
122 }
123 #endif /* L_gcov_merge_topn */
124
125 #endif /* inhibit_libc */
(gdb) print n
$1 = 140325305737200
(gdb) print j
$2 = 1896248771
"""

Compiler:

"""
$ 

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

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
It's indeed odd that we have a VEC_COND_EXPR creating a boolean vector.  With
GCC 10 veclower saw

  _1 = { 0, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -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, -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, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0 }>;

and _2 is vector while _1 is vector now we have

  _1 = { -1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 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, 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, -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, -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, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0 }>;

where _2 is vector, appearantly inverting _1.  This is either
new or missed folding I guess (I see this in .original already).

Now, veclower better shouldn't touch this - definitely a vector
ctor from SSA names isn't something we want...   Though in principle
we should generate correct code here or give up.

So I'd say we hit a latent issue here?

I see we're doing a bad job in constant folding as well, mostly because
our representation of vector is special:

 
unit-size 
align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x766472a0 precision:1 min  max >
SI
size 
unit-size 
align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x76647348 nunits:32>
constant npatterns:1 nelts-per-pattern:1
elt:0:  
constant 0>>

see how we're having a vector type of a QImode boolean with size 8.
The folding code assumes it can work with TYPE_SIZE of the component:

case BIT_FIELD_REF:
  if (TREE_CODE (arg0) == VECTOR_CST
  && (type == TREE_TYPE (TREE_TYPE (arg0))
  || (VECTOR_TYPE_P (type)
  && TREE_TYPE (type) == TREE_TYPE (TREE_TYPE (arg0
  && tree_fits_uhwi_p (op1)
  && tree_fits_uhwi_p (op2))
{
  tree eltype = TREE_TYPE (TREE_TYPE (arg0));
  unsigned HOST_WIDE_INT width = tree_to_uhwi (TYPE_SIZE (eltype));
  unsigned HOST_WIDE_INT n = tree_to_uhwi (arg1);

but that's not true for these types.

diff --git a/gcc/fold-const.c b/gcc/fold-const.c
index 1f861630225..0cc80adf632 100644
--- a/gcc/fold-const.c
+++ b/gcc/fold-const.c
@@ -12581,7 +12581,9 @@ fold_ternary_loc (location_t loc, enum tree_code code,
t
ree type,
  && tree_fits_uhwi_p (op2))
{
  tree eltype = TREE_TYPE (TREE_TYPE (arg0));
- unsigned HOST_WIDE_INT width = tree_to_uhwi (TYPE_SIZE (eltype));
+ unsigned HOST_WIDE_INT width
+   = (TREE_CODE (eltype) == BOOLEAN_TYPE
+  ? TYPE_PRECISION (eltype) : tree_to_uhwi (TYPE_SIZE (eltype)));
  unsigned HOST_WIDE_INT n = tree_to_uhwi (arg1);
  unsigned HOST_WIDE_INT idx = tree_to_uhwi (op2);

diff --git a/gcc/tree-vect-generic.c b/gcc/tree-vect-generic.c
index 6d5d65195ae..e9dbe07dccc 100644
--- a/gcc/tree-vect-generic.c
+++ b/gcc/tree-vect-generic.c
@@ -137,7 +137,7 @@ tree_vec_extract (gimple_stmt_iterator *gsi, tree type,
 }
   if (bitpos)
 {
-  if (TREE_CODE (type) == BOOLEAN_TYPE)
+  if (0 && TREE_CODE (type) == BOOLEAN_TYPE)
{
  tree itype
= build_nonstandard_integer_type (tree_to_uhwi (bitsize), 0);


makes the generated code a bit easier to follow but I guess still ends up
miscompiling things?

Note if I add -fdisable-tree-veclower ISEL ICEs.

So I'd see where this VEC_COND_EXPR comes from.

[Bug tree-optimization/96912] New: Failure to optimize pattern

[gabravier at gmail dot com]

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

Bug ID: 96912
   Summary: Failure to optimize pattern
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gabravier at gmail dot com
  Target Milestone: ---

typedef char v16i8 __attribute__((vector_size(16)));
typedef int64_t v2i64 __attribute__((vector_size(16)));

v2i64 blend_epi8(v2i64 x, v2i64 y, v16i8 mask)
{
v2i64 tmp = (mask < 0);
return (~tmp & x) | (tmp & y);
}

This can be optimized to `return (v2i64)__builtin_ia32_pblendvb128((v16i8)x,
(v16i8)y, mask);`. This transformation is done by LLVM, but not by GCC.