[Bug tree-optimization/96801] Refactoring of LIM introduced possible bug

[stefansf at linux dot ibm.com]

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

--- Comment #2 from Stefan Schulze Frielinghaus  
---
Can confirm. This is resolved with the mentioned commit. Thanks!

[Bug tree-optimization/96522] [9/10/11 Regression] Incorrect with with -O -fno-tree-pta

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
Created attachment 49137
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49137&action=edit
patch

The same holds true for copying alignment.  I don't think SLSR is "safe" here
since it also picks a new base from possibly outside of a controlling stmt.
But obviously transfering alignment is important - but we could implement
this by adjusting the access type instead.  I'm quite sure non-nullness
isn't so important.  Now, misalignment info isn't easy to transfer in the
generic routine.

I'm going to test the attached.  [for backporting the MR_DEPENDENCE hunk
can be stripped]

[Bug gcov-profile/96285] The documentation of -fprofile-exclude-files is unclear

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #4 from Martin Liška  ---
Fixed now.

[Bug c++/90629] Support for -Wmismatched-new-delete

[dcb314 at hotmail dot com]

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

David Binderman  changed:

   What|Removed |Added

 CC||dcb314 at hotmail dot com

--- Comment #2 from David Binderman  ---

Here is a little test case:

// bad alloc & dealloc

# include 

void
f()
{
char * p = new char [ 10];
delete p;

char * p2 = new char;
delete [] p2;

char * q = new char [ 10];
free( q);

char * q2 = (char *) malloc( 10);
delete [] q2;
}

Latest gcc finds no problems, latest clang finds two, for p and p2.
q and q2 not found.

Interestingly, I've just started compiling all of fedora distribution
with clang. I've only compiled [a-d]*.spec files so far, but I have 34 cases
found already. This implies about 220 cases in fedora.

So only duplicating what does clang for new and delete would find hundreds of
bugs in fedora. I'd be glad to help with testing any prototype implementation.

[Bug tree-optimization/96579] [8/9/10/11 Regression] ICE in gimple check: expected gimple_assign(error_mark), have gimple_nop() in gimple_assign_rhs1, at gimple.h:2605 since r7-950-g8a85cee26eabf5cf

[cvs-commit at gcc dot gnu.org]

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Richard Biener :

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

commit r11-2900-gff7463172e564c5dd2432d7af8eaa0124cbd4af7
Author: Richard Biener 
Date:   Thu Aug 27 10:02:22 2020 +0200

tree-optimization/96579 - another special-operands fix in reassoc

This makes sure to put special-ops expanded rhs left where
expression rewrite expects it.

2020-08-27  Richard Biener  

PR tree-optimization/96579
* tree-ssa-reassoc.c (linearize_expr_tree): If we expand
rhs via special ops make sure to swap operands.

* gcc.dg/pr96579.c: New testcase.

[Bug tree-optimization/96579] [8/9/10 Regression] ICE in gimple check: expected gimple_assign(error_mark), have gimple_nop() in gimple_assign_rhs1, at gimple.h:2605 since r7-950-g8a85cee26eabf5cf

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||11.0
Summary|[8/9/10/11 Regression] ICE  |[8/9/10 Regression] ICE in
   |in gimple check: expected   |gimple check: expected
   |gimple_assign(error_mark),  |gimple_assign(error_mark),
   |have gimple_nop() in|have gimple_nop() in
   |gimple_assign_rhs1, at  |gimple_assign_rhs1, at
   |gimple.h:2605 since |gimple.h:2605 since
   |r7-950-g8a85cee26eabf5cf|r7-950-g8a85cee26eabf5cf

--- Comment #5 from Richard Biener  ---
Fixed on trunk sofar.  Still not the failure mode I'm eventually expecting as
well ;)

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

[weiwt.fnst at cn dot fujitsu.com]

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

Bug ID: 96810
   Summary: This is a case that gcc shoud not compile
successfully, but gcc acts opposite.
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: weiwt.fnst at cn dot fujitsu.com
  Target Milestone: ---

In the examples below, gcc has opposite behavior when complie:

These examples are from:
https://www.openmp.org/wp-content/uploads/openmp-examples-5-0-1.pdf

4.5 Array Sections in Device Constructs
Example array_sections.2.c

As the declaration before the example says "This example shows the invalid
usage of two separate sections of the same array inside of a target construct"
and the text annotation in the example says, gcc shoud not compile
successfully.

However, gcc acts opposite when compile, details are as below:

test case:
-
Example array_sections.2.c
void foo ()
{
int A[30], *p;
#pragma omp target data map( A[0:4] )
  {
p = &A[0];
/* invalid because p[3] and A[3] are the same
 * location on the host but the array section
 * specified via p[...] is not a subset of A[0:4] */
#pragma omp target map( p[3:20] )
{
A[2] = 0;
p[8] = 0;
}
  }
}

test command:
-
#gcc -v
Target: x86_64-pc-linux-gnu
Configured with:./.../configure 
   --prefix=/.../ 
   --with-gmp=/.../gmp-6.1.0/ 
   --with-mpfr=/.../mpfr-3.1.4/ 
   --with-mpc=/.../mpc-1.0.3/ 
   --enable-multilib
Thread model: posix
gcc version 11.0.0 20200519 (experimental) (GCC)

#gcc -fopenmp -I/.../include Example array_sections.2.c

-

[Bug fortran/96811] New: Power: x**(negative integer) – use libgcc variant for power raised to negative value?

[burnus at gcc dot gnu.org]

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

Bug ID: 96811
   Summary: Power: x**(negative integer) – use libgcc variant for
power raised to negative value?
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: burnus at gcc dot gnu.org
  Target Milestone: ---

Fabio Azevedo has some observations at
https://gcc.gnu.org/pipermail/fortran/2020-August/054931.html

In particular:

  The only difference in behaviour I see is that when the exponent is
  negative, libgcc2 calculates 1/(x**(-n)) while libgfortran calculates
  (1/x)**(-n). The first version being more accurate.
[...]
  On the top of that x**n with x real for negative exponents appears to yield
  results more compatible with 1/(x**(-n)) than (1/x)**(-n).

libgcc/libgcc2.c has:

NAME (TYPE x, int m)
{
  unsigned int n = m < 0 ? -m : m;
  TYPE y = n % 2 ? x : 1;
  while (n >>= 1)
{
  x = x * x;
  if (n % 2)
y = y * x;
}
  return m < 0 ? 1/y : y;  // <<< division done at the end.
}


While libgfortran/m4/pow.m4 has (for noninteger x):

  if (n < 0)
{
  u = -n;
  x = pow / x;  // <<< division done already here; pow == 1
`   }
  else
{
   u = n;
}
  for (;;)
{
  if (u & 1)
pow *= x;
  u >>= 1;
  if (u)
x *= x;
  else
break;
}
}
  return pow;

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

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #1 from Jakub Jelinek  ---
The standard says this is unspecified behavior, but the unspecified behavior
happens at runtime, so if the compiler could detect it at compile time, it
would need to be at most a warning (if the code is never called, there is no
unspecified behavior).  Generally this isn't something that can be detected at
compile time, e.g. the target data can be in a different function from target,
or there could be target exit data that unmaps it in between and makes it
valid, or the fact that the pointer must alias the array could be not known to
the compiler, etc.
And the testcase is rejected at runtime:
libgomp: Trying to map into device [0x7ffc13463cbc..0x7ffc13463d0c) object when
[0x7ffc13463cb0..0x7ffc13463cc0) is already mapped

[Bug target/96744] [11 Regression] FAIL: gcc.target/i386/avx512bitalgvl-vpopcntb-1.c execution test

[crazylht at gmail dot com]

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

--- Comment #9 from Hongtao.liu  ---
(In reply to Hongtao.liu from comment #7)
> (In reply to Uroš Bizjak from comment #5)
> > (In reply to Hongtao.liu from comment #2)
> > 
> > > Need to add define_insn for movp2qi/movp2hi?
> > 
> > Yes, this is needed to cover some corner cases. Please see attachment 49114 
> > [details]
> > [details].
> > 
> > However, the patch assumes that avx512vp2intersect implies mavx512dq,
> 
> Let me check this part.

Confirmed, avx512vp2intersect implies avx512dq.

Should bellow in the same patch with attachment 49114, or a separate patch?

---
diff --git a/gcc/common/config/i386/i386-common.c
b/gcc/common/config/i386/i386-common.c
index bb14305ad7b..5305145a8c9 100644
--- a/gcc/common/config/i386/i386-common.c
+++ b/gcc/common/config/i386/i386-common.c
@@ -906,8 +906,8 @@ ix86_handle_option (struct gcc_options *opts,
  opts->x_ix86_isa_flags2 |= OPTION_MASK_ISA2_AVX512VP2INTERSECT_SET;
  opts->x_ix86_isa_flags2_explicit |=
OPTION_MASK_ISA2_AVX512VP2INTERSECT_SET;
- opts->x_ix86_isa_flags |= OPTION_MASK_ISA_AVX512F_SET;
- opts->x_ix86_isa_flags_explicit |= OPTION_MASK_ISA_AVX512F_SET;
+ opts->x_ix86_isa_flags |= OPTION_MASK_ISA_AVX512DQ_SET;
+ opts->x_ix86_isa_flags_explicit |= OPTION_MASK_ISA_AVX512DQ_SET;
}
   else
{
---

[Bug target/96744] [11 Regression] FAIL: gcc.target/i386/avx512bitalgvl-vpopcntb-1.c execution test

[crazylht at gmail dot com]

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

--- Comment #10 from Hongtao.liu  ---
(In reply to Uroš Bizjak from comment #3)
> Created attachment 49112 [details]
> Retune mask <-> general moves cost
> 
> It looks to me that mask <-> general cost is too low, so the compiler now
> prefers these moves too much. Attached patch equalizes mask <-> general cost
> with xmm <-> general cost, and it seems to fix the problem.
> 
> Hongjiu, can you please retune the costs, using the attached patch as the
> start?

I'll spend some time to retune it.

[Bug fortran/96797] OpenACC fortran acc_get_cuda_stream

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu.org

--- Comment #1 from Tobias Burnus  ---
(In reply to Pavan from comment #0)
> We observed that, acc_get_cuda_stream is declared in openacc.h file(C
> implementaion uses this)
> But acc_get_cuda_stream is not declared in openacc.f90 file(fortran
> implementation uses openacc.mod)

If you look at section A.2 of either OpenACC 2.6 (supported by GCC)
https://www.openacc.org/sites/default/files/inline-files/OpenACC.2.6.final.pdf
or in 3.0 (latest version) you only find the C/C++ version:
https://www.openacc.org/sites/default/files/inline-images/Specification/OpenACC.3.0.pdf

I note that there is an attempt to add a Fortran C-binding interface to it at
https://sourceforge.net/projects/fortcuda/ (does not seem to be very active).

That would be also my proposal to you as quick solution: Simply create an
INTERFACE for them using BIND(C).

[Bug fortran/96811] Power: x**(negative integer) – use libgcc variant for power raised to negative value?

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2020-08-27
 Status|UNCONFIRMED |NEW

--- Comment #1 from Richard Biener  ---
The reasoning is that doing 1/x first we "multiply" its rounding error N times
while doing it last has it only once.

[Bug rtl-optimization/96812] New: gcc.dg/torture/pr90328.c FAILs with -fno-ivopts

[rguenth at gcc dot gnu.org]

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

Bug ID: 96812
   Summary: gcc.dg/torture/pr90328.c FAILs with -fno-ivopts
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

With -fno-ivopts and -O3 -funroll-loops the testcase fails execution because
the RTL unroller has exactly the same issue with respect to base/clique
duplication as we fixed on the GIMPLE side a while ago.

[Bug c++/96805] [10/11 Regression] ICE: Segmentation fault in instantiate_template / pop_nested_class()

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #4 from Martin Liška  ---
Reduced test-case:

$ cat qendian.ii
template  bool is_nothrow_constructible_v;
template  struct QArrayExceptionSafetyPrimitives {
  struct {
template  using iterator_move_value = decltype(0);
template 
void
move()
noexcept(is_nothrow_constructible_v>);
  };
};

[Bug bootstrap/96813] New: [11 Regression] Broken bootstrap-lto-lean profiled bootstrap since r11-2883-gbf19cbc9cea6161f3deb63040601090828c44c53

[marxin at gcc dot gnu.org]

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

Bug ID: 96813
   Summary: [11 Regression] Broken bootstrap-lto-lean profiled
bootstrap since
r11-2883-gbf19cbc9cea6161f3deb63040601090828c44c53
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: aldyh at gcc dot gnu.org, jamborm at gcc dot gnu.org
  Target Milestone: ---

The following fails:

$ ../configure --enable-languages=c,c++,lto --disable-multilib
--disable-libsanitizer --disable-werror --with-build-config=bootstrap-lto-lean
&& time make -j111 STAGE1_CFLAGS="-O2 -g" profiledbootstrap

with
...
mliska@kunlun:~/Programming/gcc/objdir/gcc>
/home/mliska/Programming/gcc/objdir/./prev-gcc/xg++
-B/home/mliska/Programming/gcc/objdir/./prev-gcc/
-B/usr/local/x86_64-pc-linux-gnu/bin/ -nostdinc++
-B/home/mliska/Programming/gcc/objdir/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs
-B/home/mliska/Programming/gcc/objdir/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs

-I/home/mliska/Programming/gcc/objdir/prev-x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu

-I/home/mliska/Programming/gcc/objdir/prev-x86_64-pc-linux-gnu/libstdc++-v3/include
 -I/home/mliska/Programming/gcc/libstdc++-v3/libsupc++
-L/home/mliska/Programming/gcc/objdir/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs
-L/home/mliska/Programming/gcc/objdir/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs
  -g -O2 -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W
-Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-error=format-diag
-Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long
-Wno-variadic-macros -Wno-overlength-strings -fno-common  -DHAVE_CONFIG_H
-flto=jobserver -DGENERATOR_FILE -fno-PIE -static-libstdc++ -static-libgcc 
-no-pie -o build/genchecksum \
> build/genchecksum.o .././libiberty/libiberty.a
lto-wrapper: warning: jobserver is not available: ‘MAKEFLAGS’ environment
variable is unset
lto1: fatal error: invalid jump function in LTO stream
compilation terminated.

[Bug target/96744] [11 Regression] FAIL: gcc.target/i386/avx512bitalgvl-vpopcntb-1.c execution test

[ubizjak at gmail dot com]

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

--- Comment #11 from Uroš Bizjak  ---
(In reply to Hongtao.liu from comment #9)

> > > However, the patch assumes that avx512vp2intersect implies mavx512dq,
> > 
> > Let me check this part.
> 
> Confirmed, avx512vp2intersect implies avx512dq.
> 
> Should bellow in the same patch with attachment 49114 [details], or a
> separate patch?

Please commit this patch first (the patch is pre-approved), followed by
attachment 49119 (which is also pre-approved as a separate patch) after they
pass standard bootstrap/regression test cycle.

[Bug c++/25814] Request for warning for parser ambiguity of function declarations and variable declarations with initializations

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #16 from David Malcolm  ---
(In reply to Marek Polacek from comment #15)
> David, presumably you're not working on this at the moment?
You're correct.  Sorry about that.  Switching back from ASSIGNED to NEW;
resetting assignee to default

[Bug target/94538] [9/10/11 Regression] ICE: in extract_constrain_insn_cached, at recog.c:2223 (insn does not satisfy its constraints) with -mcpu=cortex-m23 -mslow-flash-data

[cvs-commit at gcc dot gnu.org]

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

--- Comment #22 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Christophe Lyon
:

https://gcc.gnu.org/g:967a5f8e585a5d499870903849c0fa06c326547a

commit r9-8835-g967a5f8e585a5d499870903849c0fa06c326547a
Author: Christophe Lyon 
Date:   Wed Aug 19 09:02:21 2020 +

arm: Fix -mpure-code support/-mslow-flash-data for armv8-m.base [PR94538]

armv8-m.base (cortex-m23) has the movt instruction, so we need to
disable the define_split to generate a constant in this case,
otherwise we get incorrect insn constraints as described in PR94538.

We also need to fix the pure-code alternative for thumb1_movsi_insn
because the assembler complains with instructions like
movs r0, #:upper8_15:1234
(Internal error in md_apply_fix)
We now generate movs r0, 4 instead.

2020-08-24  Christophe Lyon  

PR target/94538
gcc/
* config/arm/thumb1.md: Disable set-constant splitter when
TARGET_HAVE_MOVT.
(thumb1_movsi_insn): Fix -mpure-code
alternative.

PR target/94538
gcc/testsuite/
* gcc.target/arm/pure-code/pr94538-1.c: New test.
* gcc.target/arm/pure-code/pr94538-2.c: New test.

(cherry picked from commit 259d072067997ab8f55afcf735c91b6740fd0425)

[Bug target/96789] x264: sub4x4_dct() improves when vectorization is disabled

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
testcase from https://github.com/mirror/x264/blob/master/common/dct.c

where FENC_STRIDE is 16 and FDEC_STRIDE 32

pixel is unsigned char, dctcoef is unsigned short

static inline void pixel_sub_wxh( dctcoef *diff, int i_size,
  pixel *pix1, int i_pix1, pixel *pix2, int
i_pix2 )
{
for( int y = 0; y < i_size; y++ )
{
for( int x = 0; x < i_size; x++ )
diff[x + y*i_size] = pix1[x] - pix2[x];
pix1 += i_pix1;
pix2 += i_pix2;
}
}

static void sub4x4_dct( dctcoef dct[16], pixel *pix1, pixel *pix2 )
{
dctcoef d[16];
dctcoef tmp[16];

pixel_sub_wxh( d, 4, pix1, FENC_STRIDE, pix2, FDEC_STRIDE );

for( int i = 0; i < 4; i++ )
{
int s03 = d[i*4+0] + d[i*4+3];
int s12 = d[i*4+1] + d[i*4+2];
int d03 = d[i*4+0] - d[i*4+3];
int d12 = d[i*4+1] - d[i*4+2];

tmp[0*4+i] =   s03 +   s12;
tmp[1*4+i] = 2*d03 +   d12;
tmp[2*4+i] =   s03 -   s12;
tmp[3*4+i] =   d03 - 2*d12;
}

for( int i = 0; i < 4; i++ )
{
int s03 = tmp[i*4+0] + tmp[i*4+3];
int s12 = tmp[i*4+1] + tmp[i*4+2];
int d03 = tmp[i*4+0] - tmp[i*4+3];
int d12 = tmp[i*4+1] - tmp[i*4+2];

dct[i*4+0] =   s03 +   s12;
dct[i*4+1] = 2*d03 +   d12;
dct[i*4+2] =   s03 -   s12;
dct[i*4+3] =   d03 - 2*d12;
}
}

one can see vectorization is complicated by the non-homogenous computes.

[Bug analyzer/96792] Analyzer assumes pointer is NULL, even though pointer was dereferenced earlier

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2020-08-27

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

[Bug target/94538] [9/10/11 Regression] ICE: in extract_constrain_insn_cached, at recog.c:2223 (insn does not satisfy its constraints) with -mcpu=cortex-m23 -mslow-flash-data

[cvs-commit at gcc dot gnu.org]

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

--- Comment #23 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Christophe Lyon
:

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

commit r10-8678-gf8bc014aa47a1b2056e89e50b0ce86ba64d93f3b
Author: Christophe Lyon 
Date:   Wed Aug 19 09:02:21 2020 +

arm: Fix -mpure-code support/-mslow-flash-data for armv8-m.base [PR94538]

armv8-m.base (cortex-m23) has the movt instruction, so we need to
disable the define_split to generate a constant in this case,
otherwise we get incorrect insn constraints as described in PR94538.

We also need to fix the pure-code alternative for thumb1_movsi_insn
because the assembler complains with instructions like
movs r0, #:upper8_15:1234
(Internal error in md_apply_fix)
We now generate movs r0, 4 instead.

2020-08-24  Christophe Lyon  

PR target/94538
gcc/
* config/arm/thumb1.md: Disable set-constant splitter when
TARGET_HAVE_MOVT.
(thumb1_movsi_insn): Fix -mpure-code
alternative.

PR target/94538
gcc/testsuite/
* gcc.target/arm/pure-code/pr94538-1.c: New test.
* gcc.target/arm/pure-code/pr94538-2.c: New test.

(cherry picked from commit 259d072067997ab8f55afcf735c91b6740fd0425)

[Bug target/94538] [9/10/11 Regression] ICE: in extract_constrain_insn_cached, at recog.c:2223 (insn does not satisfy its constraints) with -mcpu=cortex-m23 -mslow-flash-data

[clyon at gcc dot gnu.org]

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

Christophe Lyon  changed:

   What|Removed |Added

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

--- Comment #24 from Christophe Lyon  ---
Backported to gcc-9 and gcc-10, thus considered fixed.

Improvements tracked in the new PRs.

[Bug bootstrap/96813] [11 Regression] Broken bootstrap-lto-lean profiled bootstrap since r11-2883-gbf19cbc9cea6161f3deb63040601090828c44c53

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |11.0
Version|10.0|11.0

--- Comment #1 from Richard Biener  ---
Sounds like the irange stuff broke IPA-CP VRP?

[Bug bootstrap/96813] [11 Regression] Broken bootstrap-lto-lean profiled bootstrap since r11-2883-gbf19cbc9cea6161f3deb63040601090828c44c53

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2020-08-27

--- Comment #2 from Martin Liška  ---
(In reply to Richard Biener from comment #1)
> Sounds like the irange stuff broke IPA-CP VRP?

I guess so.

[Bug rtl-optimization/96796] [9/10/11 Regression] aarch64: ICE during RTL pass: reload

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

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

--- Comment #6 from rsandifo at gcc dot gnu.org  
---
(In reply to Alex Coplan from comment #5)
> Started with this change:
> https://gcc.gnu.org/git/?p=gcc.git;a=commit;
> h=8eaff6ef97836100801f7b40dc03f77fbebe03ac
Ah, yeah.  What the patch does looks good, but it seems to be
exposing a latent problem with subreg reloads.

The cycling starts with:


Changing pseudo 196 in operand 1 of insn 103 on equiv [r105:DI*0x8+r140:DI]
  Creating newreg=287, assigning class ALL_REGS to slow/invalid mem r287
  Creating newreg=288, assigning class ALL_REGS to slow/invalid mem r288
  103: r203:SI=r288:SI<<0x1+r196:DI#0
  REG_DEAD r196:DI
Inserting slow/invalid mem reload before:
  316: r287:DI=[r105:DI*0x8+r140:DI]
  317: r288:SI=r287:DI#0


where we now (IMO justifiably) have two reload moves, one for the
memory load and one for the subreg.  Next we have:


Changing pseudo 196 in operand 3 of insn 103 on equiv [r105:DI*0x8+r140:DI]
 Reuse r287 for reload [r105:DI*0x8+r140:DI], change to class
POINTER_AND_FP_REGS for r287
 Reuse r288 for reload r287:DI#0, change to class POINTER_AND_FP_REGS
for r288
1 Non pseudo reload: reject++
3 Non pseudo reload: reject++
  alt=0,overall=2,losers=0,rld_nregs=0
 Choosing alt 0 in insn 103:  (0) =r  (1) r  (2) n  (3) r {*add_lsl_si}
  Change to class GENERAL_REGS for r288


POINTER_AND_FP_REGS is the class that aarch64 prefers for the reload,
again IMO justifiably.  This then gets narrowed to GENERAL_REGS for
the main reload register (r288) because of the use in the *add_lsl_si
instruction.  But we're then left with a situation in which r287 has
class POINTER_AND_FP_REGS and is only used in moves.  In practice,
each move alternative will require either POINTER_REGS or FP_REGS,
but there's nothing to pin r287 down to a particular one, and we end
up oscillating between them.

More specifically, we reload insn 316 as follows:


 Choosing alt 7 in insn 316:  (0) r  (1) m {*movdi_aarch64}
  Creating newreg=289 from oldreg=287, assigning class GENERAL_REGS to r289
  316: r289:DI=[r105:DI*0x8+r140:DI]
Inserting insn reload after:
  318: r287:DI=r289:DI


Here we've effectively chosen to use GENERAL_REGS for the r287 reload,
but made the choice via a new reload register (r289).  Next we do:


 Choosing alt 13 in insn 318:  (0) w  (1) rZ {*movdi_aarch64}
  Creating newreg=290 from oldreg=287, assigning class FP_REGS to r290
  318: r290:DI=r289:DI
Inserting insn reload after:
  319: r287:DI=r290:DI


Here we've eschewed the r<-r alternative because of the risk of cycling,
so this time we've effectively chosen to use FP_REGS for r287 (instead
of GENERAL_REGS as above).  This choice too is made via a new reload
register (r290).  We manage to break a potential cycle here, but we've
still left r287 as POINTER_AND_FP_REGS.

Next we move on to the second of the original two reload instructions:


 Choosing alt 13 in insn 317:  (0) r  (1) w {*movsi_aarch64}
  Creating newreg=291, assigning class FP_REGS to r291
  317: r288:SI=r291:SI
Inserting insn reload before:
  320: r291:SI=r287:DI#0


Here too we've rejected r<-r because of potential cycling, and
so have effectively chosen to put r287 in FP_REGS.  The “problem”
is that this time we've reloaded the subreg input rather than the
register output, and so we have the same problem when reloading
the subreg the next time round.

IMO the handling of the first reload shows that it would be better
to restrict the class of r287 rather than generate a new reload
register r289.  Doing that might then require a reload in the uses
of r287, but that might happen anyway, since the new class would
still be a subset of the old class, and so any register chosen
for 

[Bug fortran/96728] Fatal Error: Reading module inquiry functions on assumed-rank

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

   Assignee|pault at gcc dot gnu.org   |unassigned at gcc dot 
gnu.org

--- Comment #3 from Paul Thomas  ---
(In reply to Dominique d'Humieres from comment #2)
> Another patch has been submitted at
> https://gcc.gnu.org/pipermail/fortran/2020-August/054907.html

Hi Jose did not assign himself to this PR and so I worked on this
independently. It is lucky that it was not a lot of work, otherwise I might
have been really peeved about the waste of time.

Unassigning myself.

Paul

[Bug fortran/96727] ICE with character length specified using specification function on assumed-rank array

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

   Assignee|pault at gcc dot gnu.org   |unassigned at gcc dot 
gnu.org

--- Comment #3 from Paul Thomas  ---
(In reply to Dominique d'Humieres from comment #2)
> Patches have been submitted at
> 
> https://gcc.gnu.org/pipermail/fortran/2020-August/054903.html
> and https://gcc.gnu.org/pipermail/fortran/2020-August/054904.html

Hi Jose did not assign himself to this PR and so I worked on this
independently. It is lucky that it was not a lot of work, otherwise I might
have been really peeved about the waste of time.

Unassigning myself.

Paul

[Bug fortran/96726] ICE with user defined specification function on assumed-rank array

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

   Assignee|pault at gcc dot gnu.org   |unassigned at gcc dot 
gnu.org

--- Comment #3 from Paul Thomas  ---
(In reply to Dominique d'Humieres from comment #2)
> Patches have been submitted at
> 
> https://gcc.gnu.org/pipermail/fortran/2020-August/054903.html
> and https://gcc.gnu.org/pipermail/fortran/2020-August/054904.html

Hi Jose did not assign himself to this PR and so I worked on this
independently. It is lucky that it was not a lot of work, otherwise I might
have been really peeved about the waste of time.

Unassigning myself.

Paul

[Bug fortran/96624] A segment fault occurred when using the reshape function result to assign a variable

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

 CC||pault at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |pault at gcc dot gnu.org

--- Comment #2 from Paul Thomas  ---
Steve's patch has been OK'd here. I will commit tonight.

https://gcc.gnu.org/pipermail/fortran/2020-August/054941.html

Paul

[Bug target/96814] New: [11 Regression] wrong code with -march=cascadelake

[zsojka at seznam dot cz]

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

Bug ID: 96814
   Summary: [11 Regression] wrong code with -march=cascadelake
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu

Created attachment 49138
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49138&action=edit
reduced testcase

Output:
$ x86_64-pc-linux-gnu-gcc -march=cascadelake testcase.c
$ sde64 -- ./a.out 
Aborted

$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r11-2899-20200827080734-g989bc4ca2f2-checking-yes-rtl-df-extra-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/11.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--with-cloog --with-ppl --with-isl --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu
--with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r11-2899-20200827080734-g989bc4ca2f2-checking-yes-rtl-df-extra-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.0.0 20200827 (experimental) (GCC)

[Bug tree-optimization/96522] [9/10/11 Regression] Incorrect with with -O -fno-tree-pta

[cvs-commit at gcc dot gnu.org]

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

--- Comment #5 from CVS Commits  ---
The master branch has been updated by Richard Biener :

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

commit r11-2906-geb68d9d828f94d28afa5900fbf3072bbcd64ba8a
Author: Richard Biener 
Date:   Thu Aug 27 11:48:15 2020 +0200

tree-optimization/96522 - transfer of flow-sensitive info in copy_ref_info

This removes the bogus tranfer of flow-sensitive info in copy_ref_info
plus fixes one oversight in FRE when flow-sensitive non-NULLness was added
to
points-to info.

2020-08-27  Richard Biener  

PR tree-optimization/96522
* tree-ssa-address.c (copy_ref_info): Reset flow-sensitive
info of the copied points-to.  Transfer bigger alignment
via the access type.
* tree-ssa-sccvn.c (eliminate_dom_walker::eliminate_stmt):
Reset all flow-sensitive info.

* gcc.dg/torture/pr96522.c: New testcase.

[Bug c++/96815] New: internal compiler error: in tsubst_pack_expansion, at cp/pt.c:12928

[c.de-claverie at pm dot me]

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

Bug ID: 96815
   Summary: internal compiler error: in tsubst_pack_expansion, at
cp/pt.c:12928
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: c.de-claverie at pm dot me
  Target Milestone: ---

http://coliru.stacked-crooked.com/a/ad29e1a2281d762e with v10.2.0

May be a duplicate of https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96355 ?

[Bug libstdc++/96816] New: bitset: debug mode: operator== ambiguous

[jeanmichael.celerier at gmail dot com]

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

Bug ID: 96816
   Summary: bitset: debug mode: operator== ambiguous
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jeanmichael.celerier at gmail dot com
  Target Milestone: ---

Hello,

Given the following code: 

```
#define _GLIBCXX_DEBUG 1
#include 

std::bitset<3> a, b;
bool test = (a == b);
```

clang gives the following error: 

```
$ clang++ -c foo.cpp -std=c++20 
In file included from foo.cpp:2:
In file included from
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../include/c++/10.2.0/bitset:1595:
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../include/c++/10.2.0/debug/bitset:356:26:
error: use of overloaded operator '==' is ambiguous (with operand types 'const
std::__debug::bitset<3>::_Base' (aka 'const bitset<3UL>') and 'const
bitset<3UL>' (aka 'const std::__debug::bitset<3>'))
  { return _M_base() == __rhs; }
   ~ ^  ~
foo.cpp:5:16: note: in instantiation of member function
'std::__debug::bitset<3>::operator==' requested here
bool test = (a == b);
   ^
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../include/c++/10.2.0/bitset:1306:7:
note: candidate function
  operator==(const bitset<_Nb>& __rhs) const _GLIBCXX_NOEXCEPT
  ^
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../include/c++/10.2.0/debug/bitset:355:7:
note: candidate function (with reversed parameter order)
  operator==(const bitset<_Nb>& __rhs) const _GLIBCXX_NOEXCEPT
  ^
1 error generated
```

g++ does not, but I guess this still warrants checking ?

[Bug libstdc++/96816] bitset: debug mode: operator== ambiguous

[jeanmichael.celerier at gmail dot com]

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

--- Comment #1 from Jean-Michaël Celerier  ---
gcc.godbolt.org link for easy repro: https://gcc.godbolt.org/z/WYbzfT

[Bug libstdc++/96816] bitset: debug mode: operator== ambiguous

[jeanmichael.celerier at gmail dot com]

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

--- Comment #2 from Jean-Michaël Celerier  ---
I'd wager this is a result of C++20 operator<=> changes and operator==
synthesis.

[Bug libstdc++/96817] New: __cxa_guard_acquire unsafe against dynamically loaded pthread

[yshuiv7 at gmail dot com]

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

Bug ID: 96817
   Summary: __cxa_guard_acquire unsafe against dynamically loaded
pthread
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: yshuiv7 at gmail dot com
  Target Milestone: ---

If pthread is loaded dynamically via dlopen() after libstdc++ is loaded,
__gthread_active_p() would return wrong result, cause guard acquire to be
thread unsafe.

An example of this problem:
https://gitlab.freedesktop.org/mesa/mesa/-/issues/3199

[Bug c++/96815] internal compiler error: in tsubst_pack_expansion, at cp/pt.c:12928

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code
   Last reconfirmed||2020-08-27
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #1 from Jonathan Wakely  ---
#include 
#include 
#include 
#include 

template
struct A { // evtHandler
using type = T;   
void doStuff(T thing) { std::cout << "nice T ! " << thing << std::endl; }
};

template
struct B { // module
std::tuple As;
B(args... _As) : As{std::make_tuple(_As...)}{};

template
void dispatch(K coolObject) {
// doStuff for As that match
std::apply([&](auto& ... a) {
([&]{if constexpr(std::is_same_v) {
a.doStuff(coolObject); }}(), ...);
}, As);

}
};

template
struct C { // controller
std::tuple Bs;
C(bees... _Bs) : Bs{_Bs...} {};

template
void fullDispatch(L veryCoolObject) {
// doStuff for all Bs that match
std::apply([&](auto& ... b) {
(b.dispatch(veryCoolObject), ...);
}, Bs);
}
};

int main() {
auto b1 = B{A{}, A{}, A{}};
auto b2 = B{A{}, A{}, A{}};
auto c = C{b1, b2};
c.fullDispatch(12.5);
}

ICEs with -std=gnu++17

96815.C: In instantiation of 'B::dispatch::
[with auto:22 = {A, A, A}]':
/home/jwakely/gcc/10/include/c++/10.2.1/type_traits:2506:26:   required by
substitution of 'template static
std::__result_of_success()((declval<_Args>)()...)),
std::__invoke_other> std::__result_of_other_impl::_S_test(int) [with _Fn =
B::dispatch::; _Args = {A&, A&,
A&}]'
/home/jwakely/gcc/10/include/c++/10.2.1/type_traits:2517:55:   required from
'struct std::__result_of_impl::dispatch::, A&, A&,
A&>'
/home/jwakely/gcc/10/include/c++/10.2.1/type_traits:2522:12:   required from
'struct std::__invoke_result::dispatch::,
A&, A&, A&>'
/home/jwakely/gcc/10/include/c++/10.2.1/type_traits:138:12:   required from
'struct
std::__and_::dispatch::, A&, A&, A&>, void, true, void>,
std::__call_is_nothrow::dispatch::, A&, A&, A&>,
B::dispatch::, A&, A&,
A&> >'
/home/jwakely/gcc/10/include/c++/10.2.1/type_traits:2979:12:   [ skipping 7
instantiation contexts, use -ftemplate-backtrace-limit=0 to disable ]
/home/jwakely/gcc/10/include/c++/10.2.1/type_traits:138:12:   recursively
required by substitution of 'template struct
std::__is_invocable_impl<_Result, _Ret, true, std::__void_t > [with _Result =
std::__invoke_result::fullDispatch::,
B, A, A >&, B, A, A >&>; _Ret =
void]'
/home/jwakely/gcc/10/include/c++/10.2.1/type_traits:138:12:   required from
'struct
std::__and_::fullDispatch::, B, A, A >&, B, A, A >&>,
void, true, void>,
std::__call_is_nothrow::fullDispatch::, B, A, A >&, B, A, A >&>,
C::fullDispatch::, B, A,
A >&, B, A, A >&> >'
/home/jwakely/gcc/10/include/c++/10.2.1/type_traits:2979:12:   required from
'struct
std::is_nothrow_invocable::fullDispatch::, B, A, A >&, B, A, A >&>'
/home/jwakely/gcc/10/include/c++/10.2.1/tuple:1707:31:   required from
'constexpr const bool std::__unpack_std_tuple struct std::is_nothrow_invocable,
C::fullDispatch::, std::tuple,
A, A >, B, A, A > >&>'
/home/jwakely/gcc/10/include/c++/10.2.1/tuple:1730:14:   required from
'constexpr decltype(auto) std::apply(_Fn&&, _Tuple&&) [with _Fn =
C::fullDispatch::; _Tuple =
std::tuple, A, A >, B, A, A >
>&]'
96815.C:35:19:   required from 'void C::fullDispatch(L) [with L = double;
bees = {B, A, A >, B, A, A >}]'
96815.C:48:24:   required from here
96815.C:20:30: internal compiler error: in tsubst_pack_expansion, at
cp/pt.c:12928
   20 | std::apply([&](auto& ... a) {
  |~~^
0x5c4e33 tsubst_pack_expansion(tree_node*, tree_node*, int, tree_node*)
/home/jwakely/src/gcc/gcc-10/gcc/cp/pt.c:12928
0x729a55 tsubst_decl
/home/jwakely/src/gcc/gcc-10/gcc/cp/pt.c:14243
0x73162b tsubst_pack_expansion(tree_node*, tree_node*, int, tree_node*)
/home/jwakely/src/gcc/gcc-10/gcc/cp/pt.c:12849
0x738f82 tsubst_fold_expr_pack
/home/jwakely/src/gcc/gcc-10/gcc/cp/pt.c:12462
0x738f82 tsubst_unary_right_fold
/home/jwakely/src/gcc/gcc-10/gcc/cp/pt.c:12578
0x738f82 tsubst_copy
/home/jwakely/src/gcc/gcc-10/gcc/cp/pt.c:16983
0x72cd68 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
/home/jwakely/src/gcc/gcc-10/gcc/cp/pt.c:20567
0x724f84 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
/home/jwakely/src/gcc/gcc-10/gcc/cp/pt.c:19160
0x724f84 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/jwakely/src/gcc/gcc-10/gcc/cp/pt.c:18773
0x72613c tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/jwakely/src/gcc/gcc-10/gcc/cp/pt.c:17840
0x72613c tsubst_expr(tree_node*, tree_node*, int, tre

[Bug libstdc++/96816] bitset: debug mode: operator== ambiguous

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #3 from Jonathan Wakely  ---
Already fixed.

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

[Bug libstdc++/96303] [10/11 Regression] Ambiguous overload for operator!= for std::__debug::bitset compiled with -std=c++20 and -pedantic.

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||jeanmichael.celerier@gmail.
   ||com

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

[Bug bootstrap/95582] [11 Regression] LTO lean + PGO bootstrap is broken in Ada

[marxin at gcc dot gnu.org]

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

--- Comment #11 from Martin Liška  ---
Is there any progress about this PR? It's still blocking Ada bootstrap.

[Bug libstdc++/96816] bitset: debug mode: operator== ambiguous

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
(In reply to Jean-Michaël Celerier from comment #0)
> g++ does not, but I guess this still warrants checking ?

N.B. GCC does give an error if you compile with -Wpedantic -std=c++20

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

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org
Summary|[11 Regression] wrong code  |[11 Regression] wrong code
   |with -march=cascadelake |with -march=cascadelake
   ||since
   ||r11-1445-g502d63b6d6141597
   Last reconfirmed||2020-08-27
 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED

--- Comment #1 from Martin Liška  ---
Started with my r11-1445-g502d63b6d6141597.
Thank you for the report.

[Bug c++/96355] [10/11 Regression] [concepts] internal compiler error: in tsubst_pack_expansion, at cp/pt.c:12928

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

  Known to work||10.1.0
Summary|[concepts] internal |[10/11 Regression]
   |compiler error: in  |[concepts] internal
   |tsubst_pack_expansion, at   |compiler error: in
   |cp/pt.c:12928   |tsubst_pack_expansion, at
   ||cp/pt.c:12928
   Last reconfirmed||2020-08-27
 Status|UNCONFIRMED |NEW
  Known to fail||10.2.0, 11.0
 Ever confirmed|0   |1
   Target Milestone|--- |10.3

--- Comment #2 from Jonathan Wakely  ---
Comment 0 compiles with GCC 9 and -std=c++2a -fconcepts

rejects-valid with GCC 10.1 and -std=c++2a

ice-on-valid-code with GCC 10.2.0, 10.2.1 and 11.0 with -std=c++2a

[Bug c++/96355] [10/11 Regression] [concepts] internal compiler error: in tsubst_pack_expansion, at cp/pt.c:12928

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
(In reply to Robert Douglas from comment #1)
> I've also hit this issue in upgrading from 9.1 to 10.2
> 
> I presume it run into the same issue, but if it helps, this more closely
> matches my use case:
> https://godbolt.org/z/zb1bP5

That code:

template
concept ParamsRemain = requires(Params)
{ requires sizeof...(Params) > 0; };

template
void foo()
{
static constexpr bool pr1 = ParamsRemain;
};

int main()
{
foo<>();
return 0;
}

compiles with GCC 9 and -std=c++2a -fconcepts

compiles with GCC 10.1 and -std=c++2a

ice-on-valid-code with GCC 10.2.0, 10.2.1 and 11.0 with -std=c++2a

[Bug libstdc++/96817] __cxa_guard_acquire unsafe against dynamically loaded pthread

[yshuiv7 at gmail dot com]

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

--- Comment #1 from Yuxuan Shui  ---
Example:

This program normally deadlocks when using linked pthread:

https://godbolt.org/z/Yrza4e

But it will throw recursive_init_error when using dlopen'd pthread:

https://godbolt.org/z/afMe5d

[Bug libstdc++/96817] __cxa_guard_acquire unsafe against dynamically loaded pthread

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
Dynamically loading libpthread breaks everything in libstdc++, it just isn't
supported.

[Bug libstdc++/96817] __cxa_guard_acquire unsafe against dynamically loaded pthread

[yshuiv7 at gmail dot com]

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

--- Comment #3 from Yuxuan Shui  ---
(In reply to Jonathan Wakely from comment #2)
> Dynamically loading libpthread breaks everything in libstdc++, it just isn't
> supported.

But it has real use cases, e.g. writing a C++ OpenGL program that doesn't use
thread itself.

This is such an easy hole for the end user to fall into. How would they know
that they have to link against pthread even though their program doesn't use
any threading?

[Bug fortran/94958] gcc/fortran/trans-array.c:9797: possible typo ?

[vehre at gcc dot gnu.org]

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

Andre Vehreschild  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

[Bug bootstrap/95582] [11 Regression] LTO lean + PGO bootstrap is broken in Ada

[rguenth at gcc dot gnu.org]

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

--- Comment #12 from Richard Biener  ---
(In reply to Martin Liška from comment #11)
> Is there any progress about this PR? It's still blocking Ada bootstrap.

Can you check the patch from comment#6?  I'm not 100% sure it's correct
but it can at most break Ada ... for Ada bool we'd not optimize it as
bool but as char or whatever size it has.  IIRC Ada has TYPE_MIN/MAX_VALUEs
that do not match the precision here but we might be happily add
true + true == 2 then.

As said, some Ada coverage would be nice.

I don't know enough about the mask_precision stuff to say whether a
different patch is better (drop the assert?  fail somewhere?).

Richard added the mask_precision field so maybe he can chime in?

[Bug libstdc++/96817] __cxa_guard_acquire unsafe against dynamically loaded pthread

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
it's been always that way - but yes, people repeatedly fall into this trap

[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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |11.0

[Bug rtl-optimization/96812] gcc.dg/torture/pr90328.c FAILs with -fno-ivopts

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-code
 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2020-08-27

[Bug libstdc++/96817] __cxa_guard_acquire unsafe against dynamically loaded pthread

[yshuiv7 at gmail dot com]

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

--- Comment #5 from Yuxuan Shui  ---
(In reply to Richard Biener from comment #4)
> it's been always that way - but yes, people repeatedly fall into this trap

If there anything libstdc++, or maybe the middle man (Mesa in my case) can do,
to improve the situation.

Maybe if there is an API Mesa can call to "refresh" libstdc++'s memory about
pthread?

[Bug libstdc++/96817] __cxa_guard_acquire unsafe against dynamically loaded pthread

[yshuiv7 at gmail dot com]

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

--- Comment #6 from Yuxuan Shui  ---
I meant to say "Is there anything ... can do, to improve the situation?"

[Bug libstdc++/96817] __cxa_guard_acquire unsafe against dynamically loaded pthread

[redi at gcc dot gnu.org]

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

--- Comment #7 from Jonathan Wakely  ---
It will work when Glibc defines all the pthread functions in libc.so and
libpthread.so becomes empty. There's not really any way to make it work until
then that wouldn't pessimize programs that are entirely single-threaded.

You can use LD_PRELOAD=libpthread.so to "fix" the program by ensuring the
pthread symbols are present early, before any __cxa_guard_acquire calls happen.

[Bug libstdc++/96817] __cxa_guard_acquire unsafe against dynamically loaded pthread

[redi at gcc dot gnu.org]

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

--- Comment #8 from Jonathan Wakely  ---
I'm also going to start using Glibc's __libc_single_threaded instead of
__gthread_active_p() for deciding whether to use atomics for reference counting
in shared_ptr and the old std::string.

Once reference counting no longer depends on whether we're linked to libpthread
it won't be so costly to just link libstdc++.so to libpthread.so
unconditionally, so that std::thread Just Works without needing to use -pthread
and __gthread_active_p() is always true.

[Bug bootstrap/95582] [11 Regression] LTO lean + PGO bootstrap is broken in Ada

[marxin at gcc dot gnu.org]

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

--- Comment #13 from Martin Liška  ---
(In reply to Richard Biener from comment #12)
> (In reply to Martin Liška from comment #11)
> > Is there any progress about this PR? It's still blocking Ada bootstrap.
> 
> Can you check the patch from comment#6?

Yes, it works. I've been using it for some time in out gcc11 package.

[Bug libstdc++/96817] __cxa_guard_acquire unsafe against dynamically loaded pthread

[yshuiv7 at gmail dot com]

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

--- Comment #9 from Yuxuan Shui  ---
(In reply to Jonathan Wakely from comment #7)
> It will work when Glibc defines all the pthread functions in libc.so and
> libpthread.so becomes empty.

Won't that mean libstdc++ will always use the thread-safe behavior? If that's
the goal, why don't we just remove the __gthread_active_p check?

[Bug target/96768] -mpure-code produces switch tables for thumb-1

[clyon at gcc dot gnu.org]

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

--- Comment #1 from Christophe Lyon  ---
This is related to comments 10,11,14,15 and 16 in the original PR94538.

In comment 14, Wilco suggested: "The best option is to do the same as
Cortex-M3: just switch off branch tables altogether and fall back to
compare+branch. That completely avoids loading data from flash and is always
smaller than emitting 32-bit tables."

[Bug target/96768] -mpure-code produces switch tables for thumb-1

[clyon at gcc dot gnu.org]

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

--- Comment #2 from Christophe Lyon  ---
Send patch proposal:
https://gcc.gnu.org/pipermail/gcc-patches/2020-August/552798.html

[Bug target/96768] -mpure-code produces switch tables for thumb-1

[clyon at gcc dot gnu.org]

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

Christophe Lyon  changed:

   What|Removed |Added

   Last reconfirmed||2020-08-27
 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED

[Bug libstdc++/96817] __cxa_guard_acquire unsafe against dynamically loaded pthread

[redi at gcc dot gnu.org]

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

--- Comment #10 from Jonathan Wakely  ---
Because it pessimizes single threaded programs. After we've made some other
changes that depend on a recent glibc, then we can avoid that pessimization.

[Bug fortran/96418] Test coarray_alloc_comp_4.f08 ICEs

[vehre at gcc dot gnu.org]

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

Andre Vehreschild  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--- Comment #4 from Andre Vehreschild  ---
Well, it's better not to try to ref a non-array as an array.

[Bug libstdc++/66146] call_once not C++11-compliant on ppc64le

[kisha-nik at mail dot ru]

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

Evgeny  changed:

   What|Removed |Added

 CC||kisha-nik at mail dot ru

--- Comment #31 from Evgeny  ---
(In reply to Jonathan Wakely from comment #27)
> Yes, we need to reimplement call_once to not use pthread_once at all, for
> any targets.
Is there any progress on this issue?

[Bug libstdc++/96817] __cxa_guard_acquire unsafe against dynamically loaded pthread

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2020-08-27
 Status|UNCONFIRMED |NEW

--- Comment #11 from Jonathan Wakely  ---
Something like this should work with the latest glibc:

--- a/libstdc++-v3/libsupc++/guard.cc
+++ b/libstdc++-v3/libsupc++/guard.cc
@@ -252,7 +252,22 @@ namespace __cxxabiv1
 # ifdef _GLIBCXX_USE_FUTEX
 // If __atomic_* and futex syscall are supported, don't use any global
 // mutex.
+#if __has_include()
+// Prefer to rely on __libc_single_threaded instead of __gthread_active_p
+if (__libc_single_threaded)
+  {
+   int *gi = (int *) (void *) g;
+   if (*gi == 0)
+ {
+   *gi = _GLIBCXX_GUARD_PENDING_BIT;
+   return 1;
+ }
+   else
+ throw_recursive_init_exception();
+  }
+#else
 if (__gthread_active_p ())
+#endif
   {
int *gi = (int *) (void *) g;
const int guard_bit = _GLIBCXX_GUARD_BIT;
@@ -390,7 +405,17 @@ namespace __cxxabiv1
 #ifdef _GLIBCXX_USE_FUTEX
 // If __atomic_* and futex syscall are supported, don't use any global
 // mutex.
+#if __has_include()
+// Prefer to rely on __libc_single_threaded instead of __gthread_active_p
+if (__libc_single_threaded)
+  {
+   int *gi = (int *) (void *) g;
+   *gi = _GLIBCXX_GUARD_BIT;
+   return;
+  }
+#else
 if (__gthread_active_p ())
+#endif
   {
int *gi = (int *) (void *) g;
const int guard_bit = _GLIBCXX_GUARD_BIT;

[Bug libstdc++/96817] __cxa_guard_acquire unsafe against dynamically loaded pthread

[redi at gcc dot gnu.org]

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

--- Comment #12 from Jonathan Wakely  ---
Oh plus this for the aborted init case:

@@ -351,7 +366,17 @@ namespace __cxxabiv1
 #ifdef _GLIBCXX_USE_FUTEX
 // If __atomic_* and futex syscall are supported, don't use any global
 // mutex.
+#if __has_include()
+// Prefer to rely on __libc_single_threaded instead of __gthread_active_p
+if (__libc_single_threaded)
+  {
+   int *gi = (int *) (void *) g;
+   *gi = 0;
+   return;
+  }
+#else
 if (__gthread_active_p ())
+#endif
   {
int *gi = (int *) (void *) g;
const int waiting_bit = _GLIBCXX_GUARD_WAITING_BIT;

[Bug fortran/95882] [9/10/11 Regression] ICE in gfc_get_derived_type, at fortran/trans-types.c:2729

[cvs-commit at gcc dot gnu.org]

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Mark Eggleston
:

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

commit r11-2907-gc336eda750d4e7a0827fedf995da955d6d88d5ca
Author: Mark Eggleston 
Date:   Fri Aug 21 06:39:30 2020 +0100

Fortran  : ICE for division by zero in declaration PR95882

A length expression containing a divide by zero in a character
declaration will result in an ICE if the constant is anymore
complicated that a contant divided by a constant.

The cause was that char_len_param_value can return MATCH_YES
even if a divide by zero was seen.  Prior to returning check
whether a divide by zero was seen and if so set it to MATCH_ERROR.

2020-08-27  Mark Eggleston  

gcc/fortran

PR fortran/95882
* decl.c (char_len_param_value): Check gfc_seen_div0 and
if it is set return MATCH_ERROR.

2020-08-27  Mark Eggleston  

gcc/testsuite/

PR fortran/95882
* gfortran.dg/pr95882_1.f90: New test.
* gfortran.dg/pr95882_2.f90: New test.
* gfortran.dg/pr95882_3.f90: New test.
* gfortran.dg/pr95882_4.f90: New test.
* gfortran.dg/pr95882_5.f90: New test.

[Bug c++/25814] Request for warning for parser ambiguity of function declarations and variable declarations with initializations

[mpolacek at gcc dot gnu.org]

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

--- Comment #17 from Marek Polacek  ---
(In reply to David Malcolm from comment #16)
> (In reply to Marek Polacek from comment #15)
> > David, presumably you're not working on this at the moment?
> You're correct.  Sorry about that.  Switching back from ASSIGNED to NEW;
> resetting assignee to default

No worries.  I'm interested in this but won't assign until I have at least a
WIP patch.

[Bug tree-optimization/96818] New: [11 Regression] ICE: in decompose, at wide-int.h:984 at -O

[zsojka at seznam dot cz]

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

Bug ID: 96818
   Summary: [11 Regression] ICE: in decompose, at wide-int.h:984
at -O
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu

Created attachment 49139
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49139&action=edit
reduced testcase

Compiler output:
$ x86_64-pc-linux-gnu-g++ -O testcase.C 
during GIMPLE pass: dom
testcase.C: In function 'void p()':
testcase.C:22:1: internal compiler error: in decompose, at wide-int.h:984
   22 | p ()
  | ^
0x8343ce wi::int_traits >
>::decompose(long*, unsigned int, generic_wide_int > const&)
/repo/gcc-trunk/gcc/wide-int.h:984
0x1508d8d wi::int_traits >
>::decompose(long*, unsigned int, generic_wide_int > const&)
/repo/gcc-trunk/gcc/wide-int.h:1931
0x1508d8d wide_int_ref_storage::wide_int_ref_storage > >(generic_wide_int > const&,
unsigned int)
/repo/gcc-trunk/gcc/wide-int.h:1034
0x1508d8d generic_wide_int
>::generic_wide_int >
>(generic_wide_int > const&, unsigned int)
/repo/gcc-trunk/gcc/wide-int.h:790
0x1508d8d bool wi::ltu_p >,
generic_wide_int >
>(generic_wide_int > const&,
generic_wide_int > const&)
/repo/gcc-trunk/gcc/wide-int.h:1935
0x15071d4 bool wi::lt_p >,
generic_wide_int >
>(generic_wide_int > const&,
generic_wide_int > const&, signop)
/repo/gcc-trunk/gcc/wide-int.h:1961
0x15071d4 irange::irange_intersect(irange const&)
/repo/gcc-trunk/gcc/value-range.cc:1701
0x1507441 irange::intersect(irange const*)
/repo/gcc-trunk/gcc/value-range.cc:1539
0x14c35e1 find_case_label_range(gswitch*, irange const*)
/repo/gcc-trunk/gcc/tree-vrp.c:3853
0x1424cd3 simplify_control_stmt_condition
/repo/gcc-trunk/gcc/tree-ssa-threadedge.c:554
0x1425a30 thread_through_normal_block
/repo/gcc-trunk/gcc/tree-ssa-threadedge.c:1101
0x142730c thread_through_normal_block
/repo/gcc-trunk/gcc/vec.h:1010
0x142730c thread_across_edge
/repo/gcc-trunk/gcc/tree-ssa-threadedge.c:1372
0x133f745 dom_opt_dom_walker::after_dom_children(basic_block_def*)
/repo/gcc-trunk/gcc/tree-ssa-dom.c:1504
0x1c498c7 dom_walker::walk(basic_block_def*)
/repo/gcc-trunk/gcc/domwalk.c:352
0x134162c execute
/repo/gcc-trunk/gcc/tree-ssa-dom.c:724
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

$ x86_64-pc-linux-gnu-g++ -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest/bin/x86_64-pc-linux-gnu-g++
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r11-2899-20200827080734-g989bc4ca2f2-checking-yes-rtl-df-extra-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/11.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--with-cloog --with-ppl --with-isl --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu
--with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r11-2899-20200827080734-g989bc4ca2f2-checking-yes-rtl-df-extra-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.0.0 20200827 (experimental) (GCC)

[Bug c++/96819] New: ICE when reading from libc++ 9

[gccbugbjorn at fahller dot se]

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

Bug ID: 96819
   Summary: ICE when reading  from libc++ 9
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gccbugbjorn at fahller dot se
  Target Milestone: ---

Created attachment 49140
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49140&action=edit
Preprocessed source of #include  from libc++9

This program causes an ICE when compiled with g++ (Compiler-Explorer-Build)
11.0.0 20200825 and use the include path for libc++ 9.0.0 using -std=c++17 or
-std=c++20. C++11 and C++14 compiles.

---
#include 
---

Attached are preprocessed sources for -std=c++20

[Bug c++/96819] ICE when reading from libc++ 9

[gccbugbjorn at fahller dot se]

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

--- Comment #1 from Björn Fahller  ---
Compilation error message is:

In file included from :1:

/opt/compiler-explorer/clang-9.0.0/include/c++/v1/tuple: In substitution of
'template template template using
_PreferTupleLikeConstructor = std::__1::_Or::type,
std::__1::tuple<_Tp> >::value>, std::__1::_Lazy >,
std::__1::_Not > > > [with _Tuple =
_Tuple; _Dummy = _Dummy; _Tp = {_Tp ...}]':

/opt/compiler-explorer/clang-9.0.0/include/c++/v1/tuple:590:51:   required from
here

/opt/compiler-explorer/clang-9.0.0/include/c++/v1/tuple:590:51: internal
compiler error: Segmentation fault

  590 | _PreferTupleLikeConstructor<_Tuple>

  |   ^

Please submit a full bug report,

with preprocessed source if appropriate.

See  for instructions.

Compiler returned: 1

[Bug tree-optimization/96820] New: ICE on x86_64-linux-gnu with `-m32` and from `-O0` to `-O3` (internal compiler error: in verify_sra_access_forest, at tree-sra.c:2358)

[cnsun at uwaterloo dot ca]

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

Bug ID: 96820
   Summary: ICE on x86_64-linux-gnu with `-m32` and from `-O0` to
`-O3` (internal compiler error: in
verify_sra_access_forest, at tree-sra.c:2358)
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: cnsun at uwaterloo dot ca
  Target Milestone: ---

$ gcc-trunk -m32 -O1 t.c
during GIMPLE pass: esra
t.c: In function ‘main’:
t.c:9:1: internal compiler error: in verify_sra_access_forest, at
tree-sra.c:2358
9 | }
  | ^
0x733fa0 verify_sra_access_forest(access*)
/tmp/tmp.fduh3vs4H1-gcc-builder/gcc/gcc/tree-sra.c:2358
0xf43062 verify_all_sra_access_forests()
/tmp/tmp.fduh3vs4H1-gcc-builder/gcc/gcc/tree-sra.c:2409
0xf47094 analyze_all_variable_accesses
/tmp/tmp.fduh3vs4H1-gcc-builder/gcc/gcc/tree-sra.c:3456
0xf475c1 perform_intra_sra
/tmp/tmp.fduh3vs4H1-gcc-builder/gcc/gcc/tree-sra.c:4533
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
$ 
$ cat t.c
struct a {
  int b;
};
int main() {
  struct a d[][6] = {4};
  struct a e;
  d[1955249013][1955249013] = e;
  return e.b;
}
$ 
$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/scratch/software/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/11.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /tmp/tmp.fduh3vs4H1-gcc-builder/gcc/configure
--enable-languages=c,c++,lto --enable-multiarch
--prefix=/scratch/software/gcc-trunk --disable-bootstrap
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.0.0 20200827 (experimental) [master revision
:1121fa585:3ae0cd94abc15e33dc06ca7a5f76f14b1d74129f] (GCC)

[Bug tree-optimization/96820] ICE on x86_64-linux-gnu with `-m32` and from `-O0` to `-O3` (internal compiler error: in verify_sra_access_forest, at tree-sra.c:2358)

[cnsun at uwaterloo dot ca]

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

--- Comment #1 from cnsun at uwaterloo dot ca  ---
Not sure if this is a dup to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96730

[Bug c++/96819] [11 Regression] ICE when reading from libc++ 9

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Last reconfirmed||2020-08-27
 Status|UNCONFIRMED |NEW
  Known to fail||11.0
  Known to work||10.2.0
 Ever confirmed|0   |1
Summary|ICE when reading |[11 Regression] ICE when
   |from libc++ 9   |reading  from libc++
   ||9
   Keywords||ice-on-valid-code

--- Comment #2 from Jonathan Wakely  ---
ICE started with r11-2748

[Bug c++/96819] [11 Regression] ICE when reading from libc++ 9

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #3 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #2)
> ICE started with r11-2748

c++: Rewrite members for all deduction guides. [PR96199]

After the last patch, it occurred to me that we could run into the
specialization issue with non-alias deduction guides as well, so this patch
extends the rewriting to C++17 mode.

Doing this revealed that we weren't properly pushing into class scope for
normalization.

gcc/cp/ChangeLog:

PR c++/96199
* pt.c (tsubst_aggr_type): Rewrite in C++17, too.
(maybe_dependent_member_ref): Likewise.
(build_deduction_guide): Re-substitute template parms.
* cp-tree.h (struct push_nested_class_guard): New.
* constraint.cc (get_normalized_constraints_from_decl): Use it.

gcc/testsuite/ChangeLog:

PR c++/96199
* g++.dg/cpp1z/class-deduction-spec1.C: New test.

[Bug c++/96819] [11 Regression] ICE when reading from libc++ 9

[ppalka at gcc dot gnu.org]

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

--- Comment #4 from Patrick Palka  ---
Looks like a dup of PR96805?

[Bug c++/96819] [11 Regression] ICE when reading from libc++ 9

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  ---
Created attachment 49141
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49141&action=edit
Another preprocessed source

Using the attached file I get some other errors before the ICE. The attached
one gives no errors before the ICE. Created on Fedora 32 with libc++-devel
installed and using the following options:

-std=c++17 -c -nostdinc -I /usr/include/c++/v1/ -I /usr/include -I
$GCC_TRUNK_PREFIX/lib/gcc/x86_64-pc-linux-gnu/11.0.0/include/ -save-temps

[Bug c++/96819] [11 Regression] ICE when reading from libc++ 9

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  ---
(In reply to Patrick Palka from comment #4)
> Looks like a dup of PR96805?

Seems to have started at the following commit though.

[Bug c++/96819] [11 Regression] ICE when reading from libc++ 9

[redi at gcc dot gnu.org]

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

--- Comment #7 from Jonathan Wakely  ---
In file included from /usr/include/c++/v1/__functional_base:18,
 from /usr/include/c++/v1/tuple:152,
 from 96819.C:1:
/usr/include/c++/v1/utility: In substitution of ‘template
template > static constexpr bool std::__1::pair<_T1,
_T2>::_CheckArgs::__enable_implicit_default() [with int& ... =
; _T1 = {}; _T2 = ]’:
/usr/include/c++/v1/utility:341:47:   required from here
/usr/include/c++/v1/utility:341:47: internal compiler error: Segmentation fault
  341 |   && !__enable_implicit_default<>();
  |   ^
0xfafeff crash_signal
/home/jwakely/src/gcc/gcc/gcc/toplev.c:327
0x7f9305da1a6f ???
   
/usr/src/debug/glibc-2.31-48-g64246fccaf/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0
0x892858 tree_class_check(tree_node*, tree_code_class, char const*, int, char
const*)
/home/jwakely/src/gcc/gcc/gcc/tree.h:3417
0x892858 pop_nested_class()
/home/jwakely/src/gcc/gcc/gcc/cp/class.c:8138
0xa1d8b4 instantiate_template_1
/home/jwakely/src/gcc/gcc/gcc/cp/pt.c:20836
0xa2286b instantiate_template(tree_node*, tree_node*, int)
/home/jwakely/src/gcc/gcc/gcc/cp/pt.c:20891
0xa2286b fn_type_unification(tree_node*, tree_node*, tree_node*, tree_node*
const*, unsigned int, tree_node*, unification_kind_t, int, conversion**, bool,
bool)
/home/jwakely/src/gcc/gcc/gcc/cp/pt.c:21346
0x87a480 add_template_candidate_real
/home/jwakely/src/gcc/gcc/gcc/cp/call.c:3417
0x87ae4c add_template_candidate
/home/jwakely/src/gcc/gcc/gcc/cp/call.c:3502
0x87ae4c add_candidates
/home/jwakely/src/gcc/gcc/gcc/cp/call.c:5883
0x87e523 add_candidates
/home/jwakely/src/gcc/gcc/gcc/cp/call.c:5798
0x87e523 build_new_method_call_1
/home/jwakely/src/gcc/gcc/gcc/cp/call.c:10274
0x87f7df build_new_method_call(tree_node*, tree_node*, vec**, tree_node*, int, tree_node**, int)
/home/jwakely/src/gcc/gcc/gcc/cp/call.c:10481
0xa42a61 finish_call_expr(tree_node*, vec**, bool,
bool, int)
/home/jwakely/src/gcc/gcc/gcc/cp/semantics.c:2624
0x9b6473 cp_parser_postfix_expression
/home/jwakely/src/gcc/gcc/gcc/cp/parser.c:7542
0x9bf5e7 cp_parser_unary_expression
/home/jwakely/src/gcc/gcc/gcc/cp/parser.c:8560
0x997f4b cp_parser_simple_cast_expression
/home/jwakely/src/gcc/gcc/gcc/cp/parser.c:29654
0x997f4b cp_parser_binary_expression
/home/jwakely/src/gcc/gcc/gcc/cp/parser.c:9706
0x5e cp_parser_assignment_expression
/home/jwakely/src/gcc/gcc/gcc/cp/parser.c:9946
0x999c82 cp_parser_expression
/home/jwakely/src/gcc/gcc/gcc/cp/parser.c:10114
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug c++/96819] [11 Regression] ICE when reading from libc++ 9

[redi at gcc dot gnu.org]

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

--- Comment #8 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #6)
> (In reply to Patrick Palka from comment #4)
> > Looks like a dup of PR96805?
> 
> Seems to have started at the following commit though.

And I don't see an ICE with GCC 10.2.1 20200821

[Bug c++/96819] [11 Regression] ICE when reading from libc++ 9

[ppalka at gcc dot gnu.org]

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

--- Comment #9 from Patrick Palka  ---
Is this with -std=c++20 or -std=c++17?  From what I can tell r11-2747 adds a
fragment of code that is run only for c++20, and then r11-2748 makes it run for
c++17 as well.  And only the first commit was backported to the 10 branch.

[Bug c++/96819] [11 Regression] ICE when reading from libc++ 9

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #10 from Jonathan Wakely  ---
Aha, yes. That was with -std=c++17 but if I use -std=c++20 it fails on gcc-10
as well as trunk. Thanks!

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

[Bug c++/96805] [10/11 Regression] ICE: Segmentation fault in instantiate_template / pop_nested_class()

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||gccbugbjorn at fahller dot se

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

[Bug c++/96819] [11 Regression] ICE when reading from libc++ 9

[redi at gcc dot gnu.org]

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

--- Comment #11 from Jonathan Wakely  ---
And bisecting with -std=c++20 instead of -std=c++20 confirms it was r11-2747.

[Bug fortran/95882] [9/10/11 Regression] ICE in gfc_get_derived_type, at fortran/trans-types.c:2729

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:8323d09e82345a1ca39f6630cdd22ccf4ef38a84

commit r10-8679-g8323d09e82345a1ca39f6630cdd22ccf4ef38a84
Author: Mark Eggleston 
Date:   Fri Aug 21 06:39:30 2020 +0100

Fortran  : ICE for division by zero in declaration PR95882

A length expression containing a divide by zero in a character
declaration will result in an ICE if the constant is anymore
complicated that a contant divided by a constant.

The cause was that char_len_param_value can return MATCH_YES
even if a divide by zero was seen.  Prior to returning check
whether a divide by zero was seen and if so set it to MATCH_ERROR.

2020-08-27  Mark Eggleston  

gcc/fortran

PR fortran/95882
* decl.c (char_len_param_value): Check gfc_seen_div0 and
if it is set return MATCH_ERROR.

2020-08-27  Mark Eggleston  

gcc/testsuite/

PR fortran/95882
* gfortran.dg/pr95882_1.f90: New test.
* gfortran.dg/pr95882_2.f90: New test.
* gfortran.dg/pr95882_3.f90: New test.
* gfortran.dg/pr95882_4.f90: New test.
* gfortran.dg/pr95882_5.f90: New test.

(cherry picked from commit c336eda750d4e7a0827fedf995da955d6d88d5ca)

[Bug target/96787] rs6000 mcpu=power10 miscompiles libiberty htab_delete() causing bootstrap failure

[cvs-commit at gcc dot gnu.org]

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

--- Comment #9 from CVS Commits  ---
The master branch has been updated by William Schmidt :

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

commit r11-2908-gabca87c57847cd04f5e05935ff9ae5121c1ecb1d
Author: Bill Schmidt 
Date:   Thu Aug 27 11:17:06 2020 -0500

rs6000: Support ELFv2 sibcall for indirect calls [PR96787]

Prior to P10, ELFv2 hasn't implemented nonlocal sibcalls.  Now that we do,
we need to be sure that r12 is set up prior to such a call.

2020-08-27  Bill Schmidt  

gcc/
PR target/96787
* config/rs6000/rs6000.c (rs6000_sibcall_aix): Support
indirect call for ELFv2.

gcc/testsuite/

PR target/96787
* gcc.target/powerpc/pr96787-1.c: New.
* gcc.target/powerpc/pr96787-2.c: New.

[Bug fortran/79097] coarray and pointer component

[vehre at gcc dot gnu.org]

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

Andre Vehreschild  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #2 from Andre Vehreschild  ---
Using gcc of trunk a recent opencoarray including pull reQuest
https://github.com/sourceryinstitute/OpenCoarrays/pull/714 this works for me.
Testing with valgrind reported no issues.

[Bug fortran/83700] [Meta-bug] Fortran Coarray issues

[vehre at gcc dot gnu.org]

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

Bug 79097 Summary: coarray and pointer component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79097

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WORKSFORME

[Bug target/96787] rs6000 mcpu=power10 miscompiles libiberty htab_delete() causing bootstrap failure

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

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

--- Comment #10 from Bill Schmidt  ---
Work is complete.

[Bug fortran/96811] Power: x**(negative integer) – use libgcc variant for power raised to negative value?

[kargl at gcc dot gnu.org]

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

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 Tobias Burnus from comment #0)
> Fabio Azevedo has some observations at
> https://gcc.gnu.org/pipermail/fortran/2020-August/054931.html
> 
> In particular:
> 
>   The only difference in behaviour I see is that when the exponent is
>   negative, libgcc2 calculates 1/(x**(-n)) while libgfortran calculates
>   (1/x)**(-n). The first version being more accurate.
> [...]
>   On the top of that x**n with x real for negative exponents appears to yield
>   results more compatible with 1/(x**(-n)) than (1/x)**(-n).
> 
> libgcc/libgcc2.c has:
> 
> NAME (TYPE x, int m)
> {
>   unsigned int n = m < 0 ? -m : m;
>   TYPE y = n % 2 ? x : 1;
>   while (n >>= 1)
> {
>   x = x * x;
>   if (n % 2)
> y = y * x;
> }
>   return m < 0 ? 1/y : y;  // <<< division done at the end.
> }
> 
> 
> While libgfortran/m4/pow.m4 has (for noninteger x):
> 

For real x, gfortran does not generate a call to libgfortran function.

% cat a.f90
function foo(x,n)
  real foo, x
  integer n
  foo = x**n
end

% cat a.f90.004.original
foo (real(kind=4) & restrict x, integer(kind=4) & restrict n)
{
  real(kind=4) __result_foo;

  {
real(kind=4) D.3806;

D.3806 = *x;
__result_foo = __builtin_powif (D.3806, *n);
  }
  return __result_foo;
}

For complex or integer x, gfortran does generate the call.
With the obvious change to a.f90,

% cat a.f90.004t.original
foo (complex(kind=4) & restrict x, integer(kind=4) & restrict n)
{
  complex(kind=4) __result_foo;

  {
complex(kind=4) D.3806;

D.3806 = *x;
__result_foo = _gfortran_pow_c4_i4 (D.3806, *n);
  }
  return __result_foo;
}

Richard's observation about rounding error is probably sufficient
reason to prefer libgcc2.c.

[Bug tree-optimization/96818] [11 Regression] ICE: in decompose, at wide-int.h:984 at -O since r11-2883

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 CC||aldyh at gcc dot gnu.org,
   ||amacleod at redhat dot com,
   ||jakub at gcc dot gnu.org
 Ever confirmed|0   |1
   Target Milestone|--- |11.0
   Last reconfirmed||2020-08-27
Summary|[11 Regression] ICE: in |[11 Regression] ICE: in
   |decompose, at   |decompose, at
   |wide-int.h:984 at -O|wide-int.h:984 at -O since
   ||r11-2883
   Priority|P3  |P1

--- Comment #1 from Jakub Jelinek  ---
Started with r11-2883-gbf19cbc9cea6161f3deb63040601090828c44c53

[Bug target/65146] alignment of _Atomic structure member is not correct

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:04df5e7de2f3dd652a9cddc1c9adfbdf45947ae6

commit r11-2909-g04df5e7de2f3dd652a9cddc1c9adfbdf45947ae6
Author: Jakub Jelinek 
Date:   Thu Aug 27 18:44:40 2020 +0200

ia32: Fix alignment of _Atomic fields [PR65146]

For _Atomic fields, lowering the alignment of long long or double etc.
fields on ia32 is undesirable, because then one really can't perform atomic
operations on those using cmpxchg8b.

The following patch stops lowering the alignment in fields for _Atomic
types (the x86_field_alignment change) and for -mpreferred-stack-boundary=2
also ensures we don't misalign _Atomic long long etc. automatic variables
(the ix86_{local,minimum}_alignment changes).
Not sure about iamcu_alignment change, I know next to nothing about IA MCU,
but unless it doesn't have cmpxchg8b instruction, it would surprise me if
we
don't want to do it as well.
clang apparently doesn't lower the field alignment for _Atomic.

2020-08-27  Jakub Jelinek  

PR target/65146
* config/i386/i386.c (iamcu_alignment): Don't decrease alignment
for TYPE_ATOMIC types.
(ix86_local_alignment): Likewise.
(ix86_minimum_alignment): Likewise.
(x86_field_alignment): Likewise, and emit a -Wpsabi diagnostic
for it.

* gcc.target/i386/pr65146.c: New test.

[Bug fortran/96811] Power: x**(negative integer) – use libgcc variant for power raised to negative value?

[burnus at gcc dot gnu.org]

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

--- Comment #3 from Tobias Burnus  ---
(In reply to kargl from comment #2)
> For real x, gfortran does not generate a call to libgfortran function.

It does – as mentioned in my email reply but not only for 'int' integers:

integer(16) :: n
real :: x, y
y = x**n
end

calls:
y = _gfortran_pow_r4_i16 (D.3904, n);

[Bug c++/96821] New: [concepts] Incorrect evaluation of concept with ill-formed expression

[dudkindaniilm2 at yandex dot ru]

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

Bug ID: 96821
   Summary: [concepts] Incorrect evaluation of concept with
ill-formed expression
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dudkindaniilm2 at yandex dot ru
  Target Milestone: ---

[Bug fortran/95882] [9/10/11 Regression] ICE in gfc_get_derived_type, at fortran/trans-types.c:2729

[cvs-commit at gcc dot gnu.org]

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

--- Comment #5 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Mark Eggleston
:

https://gcc.gnu.org/g:042c58a4b8ba48fdf26c9003154e9d3b83d4c568

commit r9-8836-g042c58a4b8ba48fdf26c9003154e9d3b83d4c568
Author: Mark Eggleston 
Date:   Fri Aug 21 06:39:30 2020 +0100

Fortran  : ICE for division by zero in declaration PR95882

A length expression containing a divide by zero in a character
declaration will result in an ICE if the constant is anymore
complicated that a contant divided by a constant.

The cause was that char_len_param_value can return MATCH_YES
even if a divide by zero was seen.  Prior to returning check
whether a divide by zero was seen and if so set it to MATCH_ERROR.

2020-08-27  Mark Eggleston  

gcc/fortran

PR fortran/95882
* decl.c (char_len_param_value): Check gfc_seen_div0 and
if it is set return MATCH_ERROR.

2020-08-27  Mark Eggleston  

gcc/testsuite/

PR fortran/95882
* gfortran.dg/pr95882_1.f90: New test.
* gfortran.dg/pr95882_2.f90: New test.
* gfortran.dg/pr95882_3.f90: New test.
* gfortran.dg/pr95882_4.f90: New test.
* gfortran.dg/pr95882_5.f90: New test.

(cherry picked from commit c336eda750d4e7a0827fedf995da955d6d88d5ca)

[Bug fortran/95882] [9/10/11 Regression] ICE in gfc_get_derived_type, at fortran/trans-types.c:2729

[markeggleston at gcc dot gnu.org]

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

markeggleston at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||markeggleston at gcc dot 
gnu.org
 Resolution|--- |FIXED

--- Comment #6 from markeggleston at gcc dot gnu.org ---
committed and backported.

[Bug c++/96821] [concepts] Incorrect evaluation of concept with ill-formed expression

[dudkindaniilm2 at yandex dot ru]

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

--- Comment #1 from Daniil Dudkin  ---
Considering the code below the correct output would be (without the
indentation): 
  Called with constant value
  Called with non-const value
But the actual output is:
  Called with constant value
  Called with constant value

The code:
#include 

struct WithConstant {
static constexpr auto value = true;
};

struct WithNotConstant {
static inline auto value = false;
};

template 
concept constant_expression = true;

template 
concept with_value_constant = constant_expression;

template 
void foo() {
std::puts("Called with constant value");
}

template 
void foo() {
std::puts("Called with non-const value");
}

int main() {
foo();
foo();
}


Compile and run logs:

$ g++-10 -v
Using built-in specs.
COLLECT_GCC=g++-10
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/10/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa:hsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
10-20200411-0ubuntu1' --with-bugurl=file:///usr/share/doc/gcc-10/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,m2 --prefix=/usr
--with-gcc-major-version-only --program-suffix=-10
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new
--enable-gnu-unique-object --disable-vtable-verify --enable-plugin
--enable-default-pie --with-system-zlib --enable-libphobos-checking=release
--with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch
--disable-werror --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none,amdgcn-amdhsa,hsa --without-cuda-driver
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 10.0.1 20200411 (experimental) [master revision
bb87d5cc77d:75961caccb7:f883c46b4877f637e0fa5025b4d6b5c9040ec566] (Ubuntu
10-20200411-0ubuntu1)

$ g++-10 bug.cpp -Wall -Wextra -std=c++20
$ ./a.out
Called with constant value
Called with constant value

The godbolt link: https://godbolt.org/z/e3zvfc

The problem is reproducible with gcc 10.1, gcc 10.2 and gcc trunk also

[Bug c/96596] ICE in match_builtin_function_types on a declaration of a built-in with invalid array argument

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||patch
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
Summary|[11 Regression] ICE: tree   |ICE in
   |check: expected class   |match_builtin_function_type
   |‘type’, have ‘exceptional’  |s on a declaration of a
   |(error_mark) in |built-in with invalid array
   |match_builtin_function_type |argument
   |s   |
 Status|NEW |ASSIGNED

--- Comment #3 from Martin Sebor  ---
Patch: https://gcc.gnu.org/pipermail/gcc-patches/2020-August/552817.html

[Bug tree-optimization/96822] New: [11 regression] Starting with r11-2833 ICE in decompose, at wide-int.h:984

[seurer at gcc dot gnu.org]

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

Bug ID: 96822
   Summary: [11 regression] Starting with r11-2833   ICE in
decompose, at wide-int.h:984
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

g:bf19cbc9cea6161f3deb63040601090828c44c53, r11-2883

Unfortunately this is in one of the SPEC 2006 test cases.

seurer@genoa:~/gcc/cpu2006/benchspec/CPU2006/456.hmmer/build/build_base_ppc64.$
/home/seurer/gcc/git/install/gcc-test/bin/gcc -c -o revcomp.o -DSPEC_CPU
-DNDEBUG   -m64 -O3 -mcpu=power8 -ffast-math -funroll-loops -fpeel-loops
-fvect-cost-model -mpopcntd -mrecip=rsqrt revcomp.c 

during GIMPLE pass: vrp
revcomp.c: In function 'revcomp':
revcomp.c:35:1: internal compiler error: in decompose, at wide-int.h:984
   35 | revcomp(char *comp, char *seq)
  | ^~~
0x10f4b30f wi::int_traits >
>::decompose(long*, unsigned int, generic_wide_int > const&)
/home/seurer/gcc/git/gcc-test/gcc/wide-int.h:984
0x10f4b30f wide_int_ref_storage::wide_int_ref_storage > >(generic_wide_int > const&,
unsigned int)
/home/seurer/gcc/git/gcc-test/gcc/wide-int.h:1034
0x10f4b30f generic_wide_int
>::generic_wide_int >
>(generic_wide_int > const&, unsigned int)
/home/seurer/gcc/git/gcc-test/gcc/wide-int.h:790
0x10f4b30f bool wi::lts_p
>, generic_wide_int >
>(generic_wide_int > const&,
generic_wide_int > const&)
/home/seurer/gcc/git/gcc-test/gcc/wide-int.h:1902
0x10f4b30f bool wi::lt_p >,
generic_wide_int >
>(generic_wide_int > const&,
generic_wide_int > const&, signop)
/home/seurer/gcc/git/gcc-test/gcc/wide-int.h:1959
0x10f4b30f irange::irange_intersect(irange const&)
/home/seurer/gcc/git/gcc-test/gcc/value-range.cc:1701
0x10f4b48f irange::intersect(irange const*)
/home/seurer/gcc/git/gcc-test/gcc/value-range.cc:1539
0x10ed3e17 find_case_label_range(gswitch*, irange const*)
/home/seurer/gcc/git/gcc-test/gcc/tree-vrp.c:3853
0x10ed43ef find_case_label_range(gswitch*, irange const*)
/home/seurer/gcc/git/gcc-test/gcc/tree-vrp.c:3814
0x10ee1b0f simplify_stmt_for_jump_threading
/home/seurer/gcc/git/gcc-test/gcc/tree-vrp.c:4184
0x10dee153 simplify_control_stmt_condition
/home/seurer/gcc/git/gcc-test/gcc/tree-ssa-threadedge.c:554
0x10def903 thread_through_normal_block
/home/seurer/gcc/git/gcc-test/gcc/tree-ssa-threadedge.c:1101
0x10df2593 thread_across_edge
/home/seurer/gcc/git/gcc-test/gcc/tree-ssa-threadedge.c:1372
0x10df2ed7 thread_outgoing_edges(basic_block_def*, gcond*, const_and_copies*,
avail_exprs_stack*, evrp_range_analyzer*, tree_node* (*)(gimple*, gimple*,
avail_exprs_stack*, basic_block_def*))
/home/seurer/gcc/git/gcc-test/gcc/tree-ssa-threadedge.c:1463
0x10ecbef7 vrp_dom_walker::after_dom_children(basic_block_def*)
/home/seurer/gcc/git/gcc-test/gcc/tree-vrp.c:4284
0x1178d383 dom_walker::walk(basic_block_def*)
/home/seurer/gcc/git/gcc-test/gcc/domwalk.c:352
0x10ee1eef identify_jump_threads
/home/seurer/gcc/git/gcc-test/gcc/tree-vrp.c:4339
0x10ee1eef execute_vrp
/home/seurer/gcc/git/gcc-test/gcc/tree-vrp.c:4478
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.