[Bug c++/98970] Use of uninitialized variable in loop is not reported

[redi at gcc dot gnu.org via Gcc-bugs]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #1 from Jonathan Wakely  ---
The manual says:

The effectiveness of some warnings depends on optimizations also being enabled.
For example -Wsuggest-final-types is more effective with link-time optimization
and -Wmaybe-uninitialized does not warn at all unless optimization is enabled.

[Bug rtl-optimization/98144] REE needs 6GB DF memory when compiling insn-extract.c with RTL checking enabled

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #14 from Richard Biener  ---
(In reply to Franz Sirl from comment #13)
> Some data for the inhouse testcase in Bug 80930 with ASAN+UBSAN:
> 
>  gcc-9@r9-8944:   OOM killed after 15min at ~85 GB
>  gcc-10@r10-9345: takes ~25min to compile, max mem ~6.5GB
> 
> Thanks for this nice improvement!

Great to hear.  You can also try if cherry-picking
g:a523add327c6cfdd68cf9b788ea808068d0f508c makes a difference.

[Bug target/98878] Incorrect multilib list for riscv*-rtems

[kito at gcc dot gnu.org via Gcc-bugs]

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

Kito Cheng  changed:

   What|Removed |Added

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

--- Comment #3 from Kito Cheng  ---
Fixed on trunk.

Re: [PATCH] PR target/98878 - Incorrect multilib list for riscv*-rtems

[Kito Cheng via Gcc-patches]

Thanks Jim, committed with your revision of comment :)

On Fri, Feb 5, 2021 at 11:28 AM Jim Wilson  wrote:
>
> On Thu, Feb 4, 2021 at 2:02 AM Kito Cheng  wrote:
>>
>> * gcc.c (print_multilib_info): Check all required argument is 
>> provided
>> by default arg.
>
>
> This looks OK to me, but...
>>
>>
>> -  /* If this directory requires any default arguments, we can skip
>> +  /* If this directory requires any default arguments, and any default
>> +arguments not appear in the ! argument list, then we can skip
>>  it.  We will already have printed a directory identical to
>>  this one which does not require that default argument.  */
>
>
> I would suggest "any default arguments not appear in the ! argument list" to 
> be instead "no default arguments appear in the ! argument list".  But there 
> are actually 3 conditions being tested, and the comment only mentions 2.  The 
> other condition is that a required argument must appear in the default 
> argument list.  That can be combined with the first condition by saying all 
> required arguments must be default arguments.  So maybe something like
>
> /* If all required arguments are default arguments, and no default
>arguments appear in the ! argument list, then we can skip it.
>
> Jim
>

[Bug target/98878] Incorrect multilib list for riscv*-rtems

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Kito Cheng :

https://gcc.gnu.org/g:072f20c555907cce38a424da47b6c1baa8330169

commit r11-7117-g072f20c555907cce38a424da47b6c1baa8330169
Author: Kito Cheng 
Date:   Thu Jan 28 18:29:53 2021 +0800

PR target/98878 - Incorrect multilib list for riscv*-rtems

 - Multi-lib only check the default argument is appeared in the multilib
   flag list, but we didn't check the case that the flag is required but
   default argument didn't provide.

 - For example riscv*-rtems has a multilib set:

 rv32imafd/ilp32d;@march=rv32imafd@mabi=ilp32d

   And when we set the default argument of arch to rv32imafdc and ABI to
   ilp32d, gcc will check the ilp32d is matched, but it didn't check
   rv32imafd is not provided by default arguments, so it should not
   reuse default library.

 - The side effcet of this patch is csky-elf target will increase the
   number of multilib from 54 to 59, but it's because genmultilib didn't
   know the default argument for multilib, so I think it could be
   improved in future.

gcc/ChangeLog:

* gcc.c (print_multilib_info): Check all required argument is
provided
by default arg.

[r11-7113 Regression] FAIL: gfortran.dg/goacc/derived-chartypes-2.f90 -O (test for excess errors) on Linux/x86_64

[sunil.k.pandey via Gcc-patches]

On Linux/x86_64,

b2d84e9f9cccbe4ee662f7002b83105629d09939 is the first bad commit
commit b2d84e9f9cccbe4ee662f7002b83105629d09939
Author: Julian Brown 
Date:   Thu Feb 4 10:13:22 2021 -0800

openacc: Tests for character types in derived-type mappings

caused

FAIL: gfortran.dg/goacc/derived-chartypes-1.f90   -O  (internal compiler error)
FAIL: gfortran.dg/goacc/derived-chartypes-1.f90   -O  (test for excess errors)
FAIL: gfortran.dg/goacc/derived-chartypes-2.f90   -O  (internal compiler error)
FAIL: gfortran.dg/goacc/derived-chartypes-2.f90   -O  (test for excess errors)

with GCC configured with

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

To reproduce:

$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="goacc.exp=gfortran.dg/goacc/derived-chartypes-1.f90 
--target_board='unix{-m32}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="goacc.exp=gfortran.dg/goacc/derived-chartypes-1.f90 
--target_board='unix{-m32\ -march=cascadelake}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="goacc.exp=gfortran.dg/goacc/derived-chartypes-1.f90 
--target_board='unix{-m64}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="goacc.exp=gfortran.dg/goacc/derived-chartypes-1.f90 
--target_board='unix{-m64\ -march=cascadelake}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="goacc.exp=gfortran.dg/goacc/derived-chartypes-2.f90 
--target_board='unix{-m32}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="goacc.exp=gfortran.dg/goacc/derived-chartypes-2.f90 
--target_board='unix{-m32\ -march=cascadelake}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="goacc.exp=gfortran.dg/goacc/derived-chartypes-2.f90 
--target_board='unix{-m64}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="goacc.exp=gfortran.dg/goacc/derived-chartypes-2.f90 
--target_board='unix{-m64\ -march=cascadelake}'"

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

[r11-7112 Regression] FAIL: libgomp.oacc-fortran/array-stride-dt-1.f90 -DACC_DEVICE_TYPE_host=1 -DACC_MEM_SHARED=1 -foffload=disable -Os (test for excess errors) on Linux/x86_64

[sunil.k.pandey via Gcc-patches]

On Linux/x86_64,

9a4d32f85ccebc0ee4b24e6d9d7a4f11c04d7146 is the first bad commit
commit 9a4d32f85ccebc0ee4b24e6d9d7a4f11c04d7146
Author: Julian Brown 
Date:   Tue Feb 2 03:44:34 2021 -0800

openacc: Allow strided arrays in update directives

caused

FAIL: gfortran.dg/goacc/array-with-dt-2.f90   -O  (internal compiler error)
FAIL: gfortran.dg/goacc/array-with-dt-2.f90   -O  (test for excess errors)
FAIL: libgomp.oacc-fortran/array-stride-dt-1.f90 -DACC_DEVICE_TYPE_host=1 
-DACC_MEM_SHARED=1 -foffload=disable  -O0  (internal compiler error)
FAIL: libgomp.oacc-fortran/array-stride-dt-1.f90 -DACC_DEVICE_TYPE_host=1 
-DACC_MEM_SHARED=1 -foffload=disable  -O0  (test for excess errors)
FAIL: libgomp.oacc-fortran/array-stride-dt-1.f90 -DACC_DEVICE_TYPE_host=1 
-DACC_MEM_SHARED=1 -foffload=disable  -O1  (internal compiler error)
FAIL: libgomp.oacc-fortran/array-stride-dt-1.f90 -DACC_DEVICE_TYPE_host=1 
-DACC_MEM_SHARED=1 -foffload=disable  -O1  (test for excess errors)
FAIL: libgomp.oacc-fortran/array-stride-dt-1.f90 -DACC_DEVICE_TYPE_host=1 
-DACC_MEM_SHARED=1 -foffload=disable  -O2  (internal compiler error)
FAIL: libgomp.oacc-fortran/array-stride-dt-1.f90 -DACC_DEVICE_TYPE_host=1 
-DACC_MEM_SHARED=1 -foffload=disable  -O2  (test for excess errors)
FAIL: libgomp.oacc-fortran/array-stride-dt-1.f90 -DACC_DEVICE_TYPE_host=1 
-DACC_MEM_SHARED=1 -foffload=disable  -O3 -fomit-frame-pointer -funroll-loops 
-fpeel-loops -ftracer -finline-functions  (internal compiler error)
FAIL: libgomp.oacc-fortran/array-stride-dt-1.f90 -DACC_DEVICE_TYPE_host=1 
-DACC_MEM_SHARED=1 -foffload=disable  -O3 -fomit-frame-pointer -funroll-loops 
-fpeel-loops -ftracer -finline-functions  (test for excess errors)
FAIL: libgomp.oacc-fortran/array-stride-dt-1.f90 -DACC_DEVICE_TYPE_host=1 
-DACC_MEM_SHARED=1 -foffload=disable  -O3 -g  (internal compiler error)
FAIL: libgomp.oacc-fortran/array-stride-dt-1.f90 -DACC_DEVICE_TYPE_host=1 
-DACC_MEM_SHARED=1 -foffload=disable  -O3 -g  (test for excess errors)
FAIL: libgomp.oacc-fortran/array-stride-dt-1.f90 -DACC_DEVICE_TYPE_host=1 
-DACC_MEM_SHARED=1 -foffload=disable  -Os  (internal compiler error)
FAIL: libgomp.oacc-fortran/array-stride-dt-1.f90 -DACC_DEVICE_TYPE_host=1 
-DACC_MEM_SHARED=1 -foffload=disable  -Os  (test for excess errors)

with GCC configured with

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

To reproduce:

$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="goacc.exp=gfortran.dg/goacc/array-with-dt-2.f90 
--target_board='unix{-m32}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="goacc.exp=gfortran.dg/goacc/array-with-dt-2.f90 
--target_board='unix{-m32\ -march=cascadelake}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="goacc.exp=gfortran.dg/goacc/array-with-dt-2.f90 
--target_board='unix{-m64}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="goacc.exp=gfortran.dg/goacc/array-with-dt-2.f90 
--target_board='unix{-m64\ -march=cascadelake}'"
$ cd {build_dir}/x86_64-linux/libgomp/testsuite && make check 
RUNTESTFLAGS="fortran.exp=libgomp.oacc-fortran/array-stride-dt-1.f90 
--target_board='unix{-m32}'"
$ cd {build_dir}/x86_64-linux/libgomp/testsuite && make check 
RUNTESTFLAGS="fortran.exp=libgomp.oacc-fortran/array-stride-dt-1.f90 
--target_board='unix{-m32\ -march=cascadelake}'"
$ cd {build_dir}/x86_64-linux/libgomp/testsuite && make check 
RUNTESTFLAGS="fortran.exp=libgomp.oacc-fortran/array-stride-dt-1.f90 
--target_board='unix{-m64}'"
$ cd {build_dir}/x86_64-linux/libgomp/testsuite && make check 
RUNTESTFLAGS="fortran.exp=libgomp.oacc-fortran/array-stride-dt-1.f90 
--target_board='unix{-m64\ -march=cascadelake}'"

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

Re: [PATCH] rs6000: Fix MMA API - Add support for compatibility built-ins

[Peter Bergner via Gcc-patches]

On 2/4/21 3:16 PM, Segher Boessenkool wrote:
> Hi!
> 
> On Thu, Feb 04, 2021 at 02:40:20PM -0600, Peter Bergner wrote:
>> The LLVM and GCC teams agreed to rename the __builtin_mma_assemble_pair and
>> __builtin_mma_disassemble_pair built-ins to __builtin_vsx_assemble_pair and
>> __builtin_vsx_disassemble_pair respectively.  It's too late to remove the
>> old names, so this patch adds support for creating compatibility built-ins
>> (ie, multiple built-in functions generate the same code) and then creates
>> compatibility built-ins using the new names.
> 
> This needs a documentation update.  You can just delete the old names
> there (i.e. rename everything there).

Good catch!  I had meant to do that and totally forgot! :-(


>> +#ifndef RS6000_BUILTIN_COMPAT
>> +  #undef BU_COMPAT
>> +  #define BU_COMPAT(ENUM, COMPAT_NAME)
> 
> Please do not do #undef unless necessary: it hides bugs (and that causes
> more bugs).

I thought it was needed, since rs6000-builtin.def is #included into
rs6000-call.c and rs6000.h multiple times.  The first 11 times, we must
make sure it expands to nothing/empty string and on the 12th time, it
expands to create the bdesc_compat array.  However, it looks like if you
redefine it to be the same value each time, then you do not need to
#undef it, so it looks like just the last usage when we create the
bdesc_compat array will we need to #undef it.  I'll give that a try
and see how it works out.



>>  BU_MMA_3 (ASSEMBLE_PAIR,"assemble_pair",MISC, mma_assemble_pair)
>> +BU_COMPAT (MMA_BUILTIN_ASSEMBLE_PAIR, "vsx_assemble_pair")
> 
> You should do those the other way around (the mma_ one is the
> compatibility one).  This matters, because if you disable the
> compatibility builtins the vsx_ one should still be there, but not the
> old name.  (It also makes more sense of course).

I actually did it that way initially, but decided to do it this was
just to make the patch smaller.  You are correct that it's "more"
correct to rename it though. 

Peter

[Bug c++/98972] New: internal compiler error: Segmentation fault signal terminated program cc1plus

[zhan3299 at purdue dot edu via Gcc-bugs]

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

Bug ID: 98972
   Summary: internal compiler error: Segmentation fault signal
terminated program cc1plus
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zhan3299 at purdue dot edu
  Target Milestone: ---

Hi, 

I have a crafted .cc program named crash1.cc. When I use both gcc-10 and g++-10
compile it, an internal compiler error occurs. I run it on Ubuntu 20.04 x64.

Details are attached.


--- crash1.cc starts 
constexpr const short f() { return 1.2345 * 0 / 01e9; try {  enum s {  }  a[] =
{ 0 };; __attribute__ ((noinline(2))); a || -1ULL; } catch (int x) { int a[] =
{ 0 }; struct s {  }; struct t: s {} ; try { (x %= 0); (x == 0); l:; } catch
(int x) { auto x = f();  struct s {}; struct l: s {} t; 0 - 0; 0 + 0; } [] (
union s {} ) {};f; (sizeof(x) == __builtin_popcount(x)); if (sizeof ((void)
sizeof(char[1 - 2 * x]))) { register const ; extern void; ; asm("" : "=a"(x),
"=d"(x) : "r" (x), "0" (x), "1" (x));  void; } else { for (unsigned int i =
f(); i < .1; i++) { for (unsigned int i = (x == 0); i < & i++) { ;
__builtin_inf(); __builtin_alloca(1); alignof(x); ;  class s {  } ; asm
volatile ("" :  :  : ); ; }; int a[] = {};; x; ;  class s {  } ; const ; x; ~-1
- 0; }; 0 << 0 >> 0;  s; __builtin_constant_p(2); ;;  struct s restrict ;
struct t: s {} ; }; }  class & {  } ;; } void T( int *x) { f(); }
--- crash1.cc ends ---


--- g++-10 version starts ---
root@c0d53067e55a:~/docker_share/gcc# g++-10 --version
g++-10 (Ubuntu 10.2.0-5ubuntu1~20.04) 10.2.0
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.

root@c0d53067e55a:~/docker_share/gcc# lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:Ubuntu 20.04.2 LTS
Release:20.04
Codename:   focal
--- g++-10 version ends ---


--- g++-10 crash log starts ---
root@c0d53067e55a:~/docker_share/gcc# g++-10 crash1.cc
crash1.cc: In function 'constexpr const short int f()':
crash1.cc:1:55: warning: 'try' in 'constexpr' function only available with
'-std=c++2a' or '-std=gnu++2a'
1 | constexpr const short f() { return 1.2345 * 0 / 01e9; try {  enum s { 
}  a[] = { 0 };; __attribute__ ((noinline(2))); a || -1ULL; } catch (int x) {
int a[] = { 0 }; struct s {  }; struct t: s {} ; try { (x %= 0); (x == 0); l:;
} catch (int x) { auto x = f();  struct s {}; struct l: s {} t; 0 - 0; 0 + 0; }
[] ( union s {} ) {};f; (sizeof(x) == __builtin_popcount(x)); if (sizeof
((void) sizeof(char[1 - 2 * x]))) { register const ; extern void; ; asm("" :
"=a"(x), "=d"(x) : "r" (x), "0" (x), "1" (x));  void; } else { for (unsigned
int i = f(); i < .1; i++) { for (unsigned int i = (x == 0); i < & i++) { ;
__builtin_inf(); __builtin_alloca(1); alignof(x); ;  class s {  } ; asm
volatile ("" :  :  : ); ; }; int a[] = {};; x; ;  class s {  } ; const ; x; ~-1
- 0; }; 0 << 0 >> 0;  s; __builtin_constant_p(2); ;;  struct s restrict ;
struct t: s {} ; }; }  class & {  } ;; } void T( int *x) { f(); }
  |   ^~~
crash1.cc:1:83: error: invalid conversion from 'int' to 'f()::s' [-fpermissive]
1 | constexpr const short f() { return 1.2345 * 0 / 01e9; try {  enum s { 
}  a[] = { 0 };; __attribute__ ((noinline(2))); a || -1ULL; } catch (int x) {
int a[] = { 0 }; struct s {  }; struct t: s {} ; try { (x %= 0); (x == 0); l:;
} catch (int x) { auto x = f();  struct s {}; struct l: s {} t; 0 - 0; 0 + 0; }
[] ( union s {} ) {};f; (sizeof(x) == __builtin_popcount(x)); if (sizeof
((void) sizeof(char[1 - 2 * x]))) { register const ; extern void; ; asm("" :
"=a"(x), "=d"(x) : "r" (x), "0" (x), "1" (x));  void; } else { for (unsigned
int i = f(); i < .1; i++) { for (unsigned int i = (x == 0); i < & i++) { ;
__builtin_inf(); __builtin_alloca(1); alignof(x); ;  class s {  } ; asm
volatile ("" :  :  : ); ; }; int a[] = {};; x; ;  class s {  } ; const ; x; ~-1
- 0; }; 0 << 0 >> 0;  s; __builtin_constant_p(2); ;;  struct s restrict ;
struct t: s {} ; }; }  class & {  } ;; } void T( int *x) { f(); }
  |
  ^
  |
  |
  |
  int
crash1.cc:1:89: warning: attributes at the beginning of statement are ignored
[-Wattributes]
1 | constexpr const short f() { return 1.2345 * 0 / 01e9; try {  enum s { 
}  a[] = { 0 };; __attribute__ ((noinline(2))); a || -1ULL; } catch (int x) {
int a[] = { 0 }; struct s {  }; struct t: s {} ; try { (x %= 0); (x == 0); l:;
} catch (int 

Re: [PATCH] PR target/98878 - Incorrect multilib list for riscv*-rtems

[Jim Wilson]

On Thu, Feb 4, 2021 at 2:02 AM Kito Cheng  wrote:

> * gcc.c (print_multilib_info): Check all required argument is
> provided
> by default arg.
>

This looks OK to me, but...

>
> -  /* If this directory requires any default arguments, we can skip
> +  /* If this directory requires any default arguments, and any default
> +arguments not appear in the ! argument list, then we can skip
>  it.  We will already have printed a directory identical to
>  this one which does not require that default argument.  */
>

I would suggest "any default arguments not appear in the ! argument list"
to be instead "no default arguments appear in the ! argument list".  But
there are actually 3 conditions being tested, and the comment only mentions
2.  The other condition is that a required argument must appear in the
default argument list.  That can be combined with the first condition by
saying all required arguments must be default arguments.  So maybe
something like

/* If all required arguments are default arguments, and no default
   arguments appear in the ! argument list, then we can skip it.

Jim

[Bug target/98537] [11 Regression] ICE in emit_move_insn since r11-5839

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

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

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

commit r11-7116-g8d0737d8f4b10bffe0411507ad2dc21ba7679883
Author: liuhongt 
Date:   Thu Jan 7 10:15:33 2021 +0800

Fix ICE: Don't generate integer mask comparision for 128/256-bits vector
when op_true/op_false are NULL or constm1_rtx/const0_rtx [PR98537]

avx512vl-pr92686-vpcmp-{1,2,intelasm-1}.c are used to guard code
generation of integer mask comparison, but for vector comparison to
vector dest, integer mask comparison is disliked, so delete these
useless tests.

gcc/ChangeLog:

PR target/98537
* config/i386/i386-expand.c (ix86_expand_sse_cmp): Don't
generate integer mask comparison for 128/256-bits vector when
op_true/op_false is NULL_RTX or CONSTM1_RTX/CONST0_RTX. Also
delete redundant !maskcmp condition.
(ix86_expand_int_vec_cmp): Ditto but no redundant deletion
here.
(ix86_expand_sse_movcc): Delete definition of maskcmp, add the
condition directly to if (maskcmp), add extra check for
cmpmode, it should be MODE_INT.
(ix86_expand_fp_vec_cmp): Pass NULL to ix86_expand_sse_cmp's
parameters op_true/op_false.
(ix86_use_mask_cmp_p): New.

gcc/testsuite/ChangeLog:

PR target/98537
* g++.target/i386/avx512bw-pr98537-1.C: New test.
* g++.target/i386/avx512vl-pr98537-1.C: New test.
* g++.target/i386/avx512vl-pr98537-2.C: New test.
* gcc.target/i386/avx512vl-pr88547-1.c: Adjust testcase,
integer mask comparison should not be generated.
* gcc.target/i386/avx512vl-pr92686-vpcmp-1.c: Remove.
* gcc.target/i386/avx512vl-pr92686-vpcmp-2.c: Ditto.
* gcc.target/i386/avx512vl-pr92686-vpcmp-intelasm-1.c: Ditto.

[Bug target/98172] Update -mtune=generic for the current Intel and AMD processors

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

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

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

commit r11-7115-gb80fefd626460fb8924248622ba59dd56246703e
Author: liuhongt 
Date:   Thu Jan 28 14:07:00 2021 +0800

Enable X86_TUNE_AVX256_UNALIGNED_{LOADï¼STORE}_OPTIMAL in generic tune.

gcc/ChangeLog:

PR target/98172
* config/i386/x86-tune.def
(X86_TUNE_AVX256_UNALIGNED_LOAD_OPTIMAL):
Remove m_GENERIC from ~list.
(X86_TUNE_AVX256_UNALIGNED_STORE_OPTIMAL): Ditto.

Re: [PATCH] [AVX512] Fix ICE: Convert integer mask to vector in ix86_expand_fp_vec_cmp/ix86_expand_int_vec_cmp [PR98537]

[Hongtao Liu via Gcc-patches]

On Thu, Feb 4, 2021 at 8:00 PM Jakub Jelinek  wrote:
>
> On Thu, Feb 04, 2021 at 01:31:52PM +0800, Hongtao Liu via Gcc-patches wrote:
> * gcc.target/i386/avx512vl-pr92686-vpcmp-1.c: This test is
> used to guard code generation of integer mask comparison, but
> for vector comparison to vector dest, integer mask comparison
> is disliked, so detele this useless test.
> * gcc.target/i386/avx512vl-pr92686-vpcmp-2.c: Ditto.
> * gcc.target/i386/avx512vl-pr92686-vpcmp-intelasm-1.c: Ditto.
>
> s/detele/delete/; but I'd say just write : Remove.
> for all 3 tests, the explanation should go into the commit message, not
> ChangeLog.
> +  /* When op_true is NULL, op_flase must be NULL, vice either.  */
>
> s/flase/false/
> s/vice either/or vice versa/
>
> +  gcc_assert (!op_true == !op_false);
> +
> +  /* When op_true/op_false is NULL or cmp_mode is not valid mask cmp mode,
> + vector dest is required.  */
> +  if (!op_true || !ix86_valid_mask_cmp_mode (cmp_mode))
> +return false;
> +
> +  /* Exclude those could be optimized in ix86_expand_sse_movcc.  */
>
> s/those/those that/
>
> Otherwise LGTM.
>
Ok for backport?
> Jakub
>


-- 
BR,
Hongtao

Re: [PATCH][X86] Enable X86_TUNE_AVX256_UNALIGNED_{LOAD, STORE}_OPTIMAL for generic tune [PR target/98172]

[Hongtao Liu via Gcc-patches]

On Thu, Feb 4, 2021 at 4:52 PM Richard Biener
 wrote:
>
> On Thu, Feb 4, 2021 at 7:45 AM Uros Bizjak  wrote:
> >
> > On Thu, Feb 4, 2021 at 5:28 AM Hongtao Liu  wrote:
> >
> > > > > >GCC11 will be the system GCC 2 years from now, and for the
> > > > > > processors then, they shouldn't even need to split a 256-bit vector
> > > > > > into 2 128-bits vectors.
> > > > > >.i.e. Test SPEC2017 with the below 2 options on Zen3/ICL show
> > > > > > option B is better than Option A.
> > > > > > Option A:
> > > > > > -march=x86-64 -mtune=generic -mavx2 -mfma -Ofast
> > > > > >
> > > > > > Option B:
> > > > > > Option A + 
> > > > > > -mtune-ctrl="256_unaligned_load_optimal,256_unaligned_store_optimal"
> > > > > >
> > > > > >   Bootstrapped and regtested on x86-64_iinux-gnu{-m32,}.
> > > > >
> > > > > Given the explicit list for unaligned loads it's a no-brainer to 
> > > > > change that
> > > > > for X86_TUNE_AVX256_UNALIGNED_LOAD_OPTIMAL.  Given both
> > > > > BDVER and ZNVER1 are listed for 
> > > > > X86_TUNE_AVX256_UNALIGNED_STORE_OPTIMAL
> > > > > we should try to benchmark the effect on ZNVER1 - Martin, do we still
> > > > > have a znver1 machine around?
> > > >
> > > > They are also turned on for Sandybridge.  I don't believe we should 
> > > > keep it
> > > > in GCC 11 to penalize today's CPUs as well as CPUs in 2024.
> > > >
> > > I agree with H.J, and I would also like to hear Uros' opinion.
> >
> > I don't have any benchmark data to form my opinion on, but I
> > definitely agree that the compiler should tune for the newer processor
> > where speed matters the most, and 10 years old processors are
> > irrelevant as far as speed is concerned.
> >
> > So, if it is expected that gcc-11 will be most used in 2-3 years from
> > now, it should by default target the architecture that will be most
> > used at that time. But I think that distribution maintainers should
> > decide here.
>
> I'm all for the change - the case it could regress is odd anyway as it needs
> AVX2 enabled and on CPUs with a 128bit data path those shouldn't be
> prefered mutlilibs (thinking of this new x86_64-v2/v3 stuff).
>
I'm going to check in the patch.
> Richard.
>
> > Uros.



-- 
BR,
Hongtao

[Bug c++/98717] [10 Regression] [c++20] variadic concept can't take empty pack

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

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

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

commit r10-9348-geb15f761bc741599504d532ef9c1c03a8de71820
Author: Jason Merrill 
Date:   Thu Feb 4 11:46:45 2021 -0500

c++: Empty args for variadic concept [PR98717]

Nice when fixing a bug is as easy as removing incorrect checks.

gcc/cp/ChangeLog:

PR c++/98717
* constraint.cc (build_concept_check_arguments): Remove assert.
(build_concept_check): Allow empty args.

gcc/testsuite/ChangeLog:

PR c++/98717
* g++.dg/cpp2a/concepts-variadic3.C: New test.

[Bug c/98965] assignment to a struct with an atomic member not atomic

[msebor at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #5 from Martin Sebor  ---
I was thinking of the latter, i.e., splitting the assignment into a series of
ordinary and atomic, the latter per member.  The union case would be diagnosed
(it too should be straightforward to detect).

But C++ rejects such mixed assignments, so the easiest solution would be to do
the same in C (or at least warn).

Re: [RFC] test builtin ratio for loop distribution

[Jim Wilson]

On Wed, Jan 27, 2021 at 4:40 AM Alexandre Oliva  wrote:

> This patch attempts to fix a libgcc codegen regression introduced in
> gcc-10, as -ftree-loop-distribute-patterns was enabled at -O2.
>
> RISC-V doesn't have any setmemM pattern, so the loops above end up
> "optimized" into memset calls, incurring not only the overhead of an
> explicit call, but also discarding the information the compiler has
> about the alignment of the destination, and that the length is a
> multiple of the word alignment.
>
> FYI we have a bug report for this for a coremark regression which sounds
like the same problem.
 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94092

Jim

[Bug target/98959] ICE in extract_constrain_insn, at recog.c:2670

[bergner at gcc dot gnu.org via Gcc-bugs]

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

Peter Bergner  changed:

   What|Removed |Added

 CC||meissner at gcc dot gnu.org,
   ||wschmidt at gcc dot gnu.org

--- Comment #13 from Peter Bergner  ---
Adding Bill and Mike for some input.

So the bad insn below is being generated by the after LRA splitter,
specifically the *vsx_le_perm_load_ splitter which calls
rs6000_emit_le_vsx_permute().  

Bill, Mike and Segher, I assume that vsx function is NOT expecting to see an
Altivec style and: address correct?  Adding some uses of the
altivec_indexed_or_indirect_operand () predicate to disable the splitters that
call rs6000_emit_le_vsx_permute() seems to fix the bug for me.  Does this look
like the correct fix?


diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
index ec068c58aa5..8db41a066b4 100644
--- a/gcc/config/rs6000/rs6000.c
+++ b/gcc/config/rs6000/rs6000.c
@@ -10059,6 +10059,11 @@ rs6000_const_vec (machine_mode mode)
 void
 rs6000_emit_le_vsx_permute (rtx dest, rtx source, machine_mode mode)
 {
+  if (MEM_P (dest))
+gcc_assert (!altivec_indexed_or_indirect_operand (dest, mode));
+  else if (MEM_P (source))
+gcc_assert (!altivec_indexed_or_indirect_operand (source, mode));
+
   /* Scalar permutations are easier to express in integer modes rather than
  floating-point modes, so cast them here.  We use V1TImode instead
  of TImode to ensure that the values don't go through GPRs.  */
diff --git a/gcc/config/rs6000/vsx.md b/gcc/config/rs6000/vsx.md
index 3e0518631df..610490cb3d9 100644
--- a/gcc/config/rs6000/vsx.md
+++ b/gcc/config/rs6000/vsx.md
@@ -991,7 +991,8 @@
   "@
#
#"
-  "!BYTES_BIG_ENDIAN && TARGET_VSX && !TARGET_P9_VECTOR"
+  "!BYTES_BIG_ENDIAN && TARGET_VSX && !TARGET_P9_VECTOR
+   && !altivec_indexed_or_indirect_operand (operands[1], mode)"
   [(const_int 0)]
 {
   rtx tmp = (can_create_pseudo_p ()
@@ -1008,7 +1009,8 @@
 (define_insn "*vsx_le_perm_store_"
   [(set (match_operand:VSX_LE_128 0 "memory_operand" "=Z,Q")
 (match_operand:VSX_LE_128 1 "vsx_register_operand" "+wa,r"))]
-  "!BYTES_BIG_ENDIAN && TARGET_VSX && !TARGET_P9_VECTOR"
+  "!BYTES_BIG_ENDIAN && TARGET_VSX && !TARGET_P9_VECTOR
+   & !altivec_indexed_or_indirect_operand (operands[0], mode)"
   "@
#
#"
@@ -1019,7 +1021,8 @@
 (define_split
   [(set (match_operand:VSX_LE_128 0 "memory_operand")
 (match_operand:VSX_LE_128 1 "vsx_register_operand"))]
-  "!BYTES_BIG_ENDIAN && TARGET_VSX && !reload_completed && !TARGET_P9_VECTOR"
+  "!BYTES_BIG_ENDIAN && TARGET_VSX && !reload_completed && !TARGET_P9_VECTOR
+   && !altivec_indexed_or_indirect_operand (operands[0], mode)"
   [(const_int 0)]
 {
   rtx tmp = (can_create_pseudo_p ()
@@ -1075,7 +1078,8 @@
 (define_split
   [(set (match_operand:VSX_LE_128 0 "memory_operand")
 (match_operand:VSX_LE_128 1 "vsx_register_operand"))]
-  "!BYTES_BIG_ENDIAN && TARGET_VSX && reload_completed && !TARGET_P9_VECTOR"
+  "!BYTES_BIG_ENDIAN && TARGET_VSX && reload_completed && !TARGET_P9_VECTOR
+   && !altivec_indexed_or_indirect_operand (operands[0], mode)"
   [(const_int 0)]
 {
   rs6000_emit_le_vsx_permute (operands[1], operands[1], mode);

Re: [PATCH] RISC-V: Fix -march option parsing when `p` extension exists.

[Jim Wilson]

On Thu, Jan 21, 2021 at 10:49 PM Kito Cheng  wrote:

> I think this patch is small enough to accept without FSF copyright
> assignment, and he is also on the way of the process, what do you
> think?
>

I see the copyright assignments on file at the FSF when I checked today.

Jim

[Bug analyzer/98575] [11 regression] gcc.dg/analyzer/pr94851-1.c fails after r11-6495

[dmalcolm at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #4 from David Malcolm  ---
The false leak bug appears to very similar to PR analyzer/97072.

Re: [PATCH 1/4] openacc: Remove dereference for non-pointer derived-type members

[Julian Brown]

On Thu, 4 Feb 2021 15:55:20 +0100
Tobias Burnus  wrote:

> Hi Julian,
> 
> LGTM. Thanks!
> 
>   * * *
> 
> Can you as follow-up also add a testcase which uses – instead of
> integer – 'character' (with len > 1, both kind=1 and kind=4) and
> check that it is handled correctly? In particular, that the right
> size is passed on. (Should be size-in-bytes = kind*len.) It probably
> just work, unless any OpenACC construct uses a different code path
> than the one covered by my OpenMP patches (esp.
> https://gcc.gnu.org/g:102502e32ea4e8a75d6b252ba319d09d735d9aa7 ).
> 
> ('character' (esp. kind=4 or len=: (¹)) and 'class' have the tendency
> to break. Not that allocatable/pointer/optional don't expose bugs.)

Thanks, I've committed the patch, and also the attached patch with some
additional character tests. All seems good, AFAICT.

Julian
>From b2d84e9f9cccbe4ee662f7002b83105629d09939 Mon Sep 17 00:00:00 2001
From: Julian Brown 
Date: Thu, 4 Feb 2021 10:13:22 -0800
Subject: [PATCH 4/4] openacc: Tests for character types in derived-type
 mappings

This patch adds some tests for character types that are components of
derived types used in OpenACC data-movement clauses.

gcc/testsuite/
	* gfortran.dg/goacc/derived-chartypes-1.f90: New test.
	* gfortran.dg/goacc/derived-chartypes-2.f90: Likewise.
	* gfortran.dg/goacc/derived-chartypes-3.f90: Likewise.
	* gfortran.dg/goacc/derived-chartypes-4.f90: Likewise.
---
 .../gfortran.dg/goacc/derived-chartypes-1.f90 | 129 ++
 .../gfortran.dg/goacc/derived-chartypes-2.f90 | 129 ++
 .../gfortran.dg/goacc/derived-chartypes-3.f90 |  38 ++
 .../gfortran.dg/goacc/derived-chartypes-4.f90 |  38 ++
 4 files changed, 334 insertions(+)
 create mode 100644 gcc/testsuite/gfortran.dg/goacc/derived-chartypes-1.f90
 create mode 100644 gcc/testsuite/gfortran.dg/goacc/derived-chartypes-2.f90
 create mode 100644 gcc/testsuite/gfortran.dg/goacc/derived-chartypes-3.f90
 create mode 100644 gcc/testsuite/gfortran.dg/goacc/derived-chartypes-4.f90

diff --git a/gcc/testsuite/gfortran.dg/goacc/derived-chartypes-1.f90 b/gcc/testsuite/gfortran.dg/goacc/derived-chartypes-1.f90
new file mode 100644
index 000..e4d360e1262
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/goacc/derived-chartypes-1.f90
@@ -0,0 +1,129 @@
+type :: type1
+  character(len=35) :: a
+end type type1
+
+type :: type2
+  character(len=35), pointer :: b
+end type type2
+
+type :: aux1
+  character(len=22) :: y
+end type aux1
+
+type, extends(aux1) :: aux
+  character(len=33) :: x
+end type aux
+
+type :: type3
+  class(aux), pointer :: c(:)
+end type type3
+
+type :: type4
+  integer, pointer :: d(:)
+end type type4
+
+type :: type5
+  type(aux1) :: e
+end type type5
+
+type :: type6
+  type(aux1), pointer :: f
+end type type6
+
+type :: type7
+  class(aux), pointer :: g
+end type type7
+
+type(type1) :: foo
+type(type2) :: bar
+type(type3) :: qux
+type(type4) :: quux
+type(type5) :: fred
+type(type6) :: jim
+type(type7) :: shiela
+
+type(type1), pointer :: pfoo
+type(type2), pointer :: pbar
+type(type3), pointer :: pqux
+type(type4), pointer :: pquux
+type(type5), pointer :: pfred
+type(type6), pointer :: pjim
+type(type7), pointer :: pshiela
+
+class(type1), pointer :: cfoo
+class(type2), pointer :: cbar
+class(type3), pointer :: cqux
+class(type4), pointer :: cquux
+class(type5), pointer :: cfred
+class(type6), pointer :: cjim
+class(type7), pointer :: cshiela
+
+class(type1), allocatable :: acfoo
+class(type2), allocatable :: acbar
+class(type3), allocatable :: acqux
+class(type4), allocatable :: acquux
+class(type5), allocatable :: acfred
+class(type6), allocatable :: acjim
+class(type7), allocatable :: acshiela
+
+!$acc enter data copyin(foo)
+!$acc enter data copyin(foo%a)
+!$acc enter data copyin(bar)
+!$acc enter data copyin(bar%b)
+!$acc enter data copyin(qux)
+!$acc enter data copyin(qux%c)
+!$acc enter data copyin(quux)
+!$acc enter data copyin(quux%d)
+!$acc enter data copyin(fred)
+!$acc enter data copyin(fred%e)
+!$acc enter data copyin(jim)
+!$acc enter data copyin(jim%f)
+!$acc enter data copyin(shiela)
+!$acc enter data copyin(shiela%g)
+
+!$acc enter data copyin(pfoo)
+!$acc enter data copyin(pfoo%a)
+!$acc enter data copyin(pbar)
+!$acc enter data copyin(pbar%b)
+!$acc enter data copyin(pqux)
+!$acc enter data copyin(pqux%c)
+!$acc enter data copyin(pquux)
+!$acc enter data copyin(pquux%d)
+!$acc enter data copyin(pfred)
+!$acc enter data copyin(pfred%e)
+!$acc enter data copyin(pjim)
+!$acc enter data copyin(pjim%f)
+!$acc enter data copyin(pshiela)
+!$acc enter data copyin(pshiela%g)
+
+!$acc enter data copyin(cfoo)
+!$acc enter data copyin(cfoo%a)
+!$acc enter data copyin(cbar)
+!$acc enter data copyin(cbar%b)
+!$acc enter data copyin(cqux)
+!$acc enter data copyin(cqux%c)
+!$acc enter data copyin(cquux)
+!$acc enter data copyin(cquux%d)
+!$acc enter data copyin(cfred)
+!$acc enter data copyin(cfred%e)
+!$acc enter data copyin(cjim)
+!$acc enter data copyin(cjim%f)

Re: [PATCH 4/4] openacc: Allow strided arrays in update directives

[Julian Brown]

On Thu, 4 Feb 2021 16:03:44 +0100
Tobias Burnus  wrote:

> LGTM.
> 
> However, I'd feel better if there were a testcase, which actually
> checks that it works correctly. (I think that means a
> libgomp/testsuite/ run test.)

Thanks! FYI, I've committed this version with an additional runtime
test.

Julian
>From 9a4d32f85ccebc0ee4b24e6d9d7a4f11c04d7146 Mon Sep 17 00:00:00 2001
From: Julian Brown 
Date: Tue, 2 Feb 2021 03:44:34 -0800
Subject: [PATCH 3/4] openacc: Allow strided arrays in update directives

OpenACC 3.0 ("2.14.4. Update Directive") states:

  Noncontiguous subarrays may appear. It is implementation-specific
  whether noncontiguous regions are updated by using one transfer for
  each contiguous subregion, or whether the non-contiguous data is
  packed, transferred once, and unpacked, or whether one or more larger
  subarrays (no larger than the smallest contiguous region that contains
  the specified subarray) are updated.

This patch relaxes some conditions in the Fortran front-end so that
strided accesses are permitted for update directives.

gcc/fortran/
	* openmp.c (resolve_omp_clauses): Omit OpenACC update in
	contiguity check and stride-specified error.

gcc/testsuite/
	* gfortran.dg/goacc/array-with-dt-2.f90: New test.

libgomp/
	* testsuite/libgomp.oacc-fortran/array-stride-dt-1.f90: New test.
---
 gcc/fortran/openmp.c  |  5 ++-
 .../gfortran.dg/goacc/array-with-dt-2.f90 | 10 +
 .../array-stride-dt-1.f90 | 44 +++
 3 files changed, 57 insertions(+), 2 deletions(-)
 create mode 100644 gcc/testsuite/gfortran.dg/goacc/array-with-dt-2.f90
 create mode 100644 libgomp/testsuite/libgomp.oacc-fortran/array-stride-dt-1.f90

diff --git a/gcc/fortran/openmp.c b/gcc/fortran/openmp.c
index aab17f0589f..797f6c86b62 100644
--- a/gcc/fortran/openmp.c
+++ b/gcc/fortran/openmp.c
@@ -5192,7 +5192,8 @@ resolve_omp_clauses (gfc_code *code, gfc_omp_clauses *omp_clauses,
 			   array isn't contiguous.  An expression such as
 			   arr(-n:n,-n:n) could be contiguous even if it looks
 			   like it may not be.  */
-			if (list != OMP_LIST_CACHE
+			if (code->op != EXEC_OACC_UPDATE
+			&& list != OMP_LIST_CACHE
 			&& list != OMP_LIST_DEPEND
 			&& !gfc_is_simply_contiguous (n->expr, false, true)
 			&& gfc_is_not_contiguous (n->expr))
@@ -5230,7 +5231,7 @@ resolve_omp_clauses (gfc_code *code, gfc_omp_clauses *omp_clauses,
 			int i;
 			gfc_array_ref *ar = _ref->u.ar;
 			for (i = 0; i < ar->dimen; i++)
-			  if (ar->stride[i])
+			  if (ar->stride[i] && code->op != EXEC_OACC_UPDATE)
 			{
 			  gfc_error ("Stride should not be specified for "
 	 "array section in %s clause at %L",
diff --git a/gcc/testsuite/gfortran.dg/goacc/array-with-dt-2.f90 b/gcc/testsuite/gfortran.dg/goacc/array-with-dt-2.f90
new file mode 100644
index 000..807580d75a9
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/goacc/array-with-dt-2.f90
@@ -0,0 +1,10 @@
+type t
+   integer, allocatable :: A(:,:)
+end type t
+
+type(t), allocatable :: b(:)
+
+!$acc update host(b(::2))
+!$acc update host(b(1)%A(::3,::4))
+end
+
diff --git a/libgomp/testsuite/libgomp.oacc-fortran/array-stride-dt-1.f90 b/libgomp/testsuite/libgomp.oacc-fortran/array-stride-dt-1.f90
new file mode 100644
index 000..f04d76d583a
--- /dev/null
+++ b/libgomp/testsuite/libgomp.oacc-fortran/array-stride-dt-1.f90
@@ -0,0 +1,44 @@
+! { dg-do run }
+
+type t
+   integer, allocatable :: A(:,:)
+end type t
+
+type(t), allocatable :: b(:)
+
+integer :: i
+
+allocate(b(1:20))
+do i=1,20
+  allocate(b(i)%A(1:20,1:20))
+end do
+
+do i=1,20
+  b(i)%A(:,:) = 0
+end do
+
+!$acc enter data copyin(b)
+do i=1,20
+  !$acc enter data copyin(b(i)%A)
+end do
+
+b(1)%A(:,:) = 5
+
+!$acc update device(b(::2))
+!$acc update device(b(1)%A(::3,::4))
+
+do i=1,20
+  !$acc exit data copyout(b(i)%A)
+end do
+!$acc exit data copyout(b)
+
+! This is necessarily conservative because the "update" is allowed to copy
+! e.g. the whole of the containing block for a discontinuous update.
+! Try to ensure that the update covers a sufficient portion of the array.
+
+if (any(b(1)%A(::3,::4) .ne. 5)) stop 1
+do i=2,20
+  if (any(b(i)%A(:,:) .ne. 0)) stop 2
+end do
+
+end
-- 
2.29.2

[Bug analyzer/98575] [11 regression] gcc.dg/analyzer/pr94851-1.c fails after r11-6495

[dmalcolm at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #3 from David Malcolm  ---
The pertinent glibc commit was:
https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=26c07172cde74617ca7214c93cdcfa75321e6b2b
("Remove getc and putc macros from the public stdio.h.", 2018-02-06).

It's listed in the NEWS as in "Version 2.28", so presumably the test failure
occurs with glibc < 2.28.

That said, it's merely a symptom of the bug identified in comment #2

[PATCH] c++: Fix ICE with invalid using enum [PR96462]

[Marek Polacek via Gcc-patches]

Here we ICE in finish_nonmember_using_decl -> lookup_using_decl ->
... -> find_namespace_slot because "name" is not an IDENTIFIER_NODE.
It is a BIT_NOT_EXPR because this broken test uses

  using E::~E; // SCOPE::NAME

A using-decl can't refer to a destructor, and lookup_using_decl already
checks that in the class member case.  But in C++17, we do the "enum
scope is the enclosing scope" block, and so scope gets set to ::, and
we go into the NAMESPACE_DECL block.  In C++20 we don't do it, we go
to the ENUMERAL_TYPE block.

I resorted to hoisting the check along with a diagnostic tweak: we
don't want to print "~E names destructor".

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

gcc/cp/ChangeLog:

PR c++/96462
* name-lookup.c (lookup_using_decl): Hoist the destructor check.

gcc/testsuite/ChangeLog:

PR c++/96462
* g++.dg/cpp2a/using-enum-8.C: New test.
---
 gcc/cp/name-lookup.c  | 15 ---
 gcc/testsuite/g++.dg/cpp2a/using-enum-8.C |  5 +
 2 files changed, 13 insertions(+), 7 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp2a/using-enum-8.C

diff --git a/gcc/cp/name-lookup.c b/gcc/cp/name-lookup.c
index 52e4a630e25..1f4a7ac1d0c 100644
--- a/gcc/cp/name-lookup.c
+++ b/gcc/cp/name-lookup.c
@@ -5700,6 +5700,14 @@ lookup_using_decl (tree scope, name_lookup )
scope = ctx;
 }
 
+  /* You cannot using-decl a destructor.  */
+  if (TREE_CODE (lookup.name) == BIT_NOT_EXPR)
+{
+  error ("%<%T%s%D%> names destructor", scope,
+&"::"[scope == global_namespace ? 2 : 0], lookup.name);
+  return NULL_TREE;
+}
+
   if (TREE_CODE (scope) == NAMESPACE_DECL)
 {
   /* Naming a namespace member.  */
@@ -5739,13 +5747,6 @@ lookup_using_decl (tree scope, name_lookup )
  return NULL_TREE;
}
 
-  /* You cannot using-decl a destructor.  */
-  if (TREE_CODE (lookup.name) == BIT_NOT_EXPR)
-   {
- error ("%<%T::%D%> names destructor", scope, lookup.name);
- return NULL_TREE;
-   }
-
   /* Using T::T declares inheriting ctors, even if T is a typedef.  */
   if (lookup.name == TYPE_IDENTIFIER (npscope)
  || constructor_name_p (lookup.name, npscope))
diff --git a/gcc/testsuite/g++.dg/cpp2a/using-enum-8.C 
b/gcc/testsuite/g++.dg/cpp2a/using-enum-8.C
new file mode 100644
index 000..9a743a98399
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp2a/using-enum-8.C
@@ -0,0 +1,5 @@
+// PR c++/96462
+// { dg-do compile { target c++11 } }
+
+enum E {};
+using E::~E; // { dg-error "names destructor" }

base-commit: ce5720447c69286599b96bae53ae854b1bbe41fa
-- 
2.29.2

Re: [PATCH v2] c++: Fix bogus -Wvolatile warning in C++20 [PR98947]

[Marek Polacek via Gcc-patches]

On Thu, Feb 04, 2021 at 03:47:54PM -0500, Jason Merrill via Gcc-patches wrote:
> On 2/4/21 1:11 PM, Marek Polacek wrote:
> > On Thu, Feb 04, 2021 at 10:59:21AM -0500, Jason Merrill wrote:
> > > On 2/3/21 7:03 PM, Marek Polacek wrote:
> > > > Since most of volatile is deprecated in C++20, we are required to warn
> > > > for compound assignments to volatile variables and so on.  But here we
> > > > have
> > > > 
> > > > volatile int x, y, z;
> > > > (b ? x : y) = 1;
> > > > 
> > > > and we shouldn't warn, because simple assignments like x = 24; should
> > > > not provoke the warning when they are a discarded-value expression.
> > > > 
> > > > We warn here because when ?: is used as an lvalue, we transform it in
> > > > cp_build_modify_expr/COND_EXPR from (a ? b : c) = rhs to
> > > > 
> > > > (a ? (b = rhs) : (c = rhs))
> > > > 
> > > > and build_conditional_expr then calls mark_lvalue_use for the new
> > > > artificial assignments
> > > 
> > > Hmm, that seems wrong; the ?: expression itself does not use lvalue 
> > > operands
> > > any more than ',' does.  I notice that removing those mark_lvalue_use 
> > > calls
> > > doesn't regress Wunused-var-10.c, which was added with them in r160289.
> > 
> > The mark_lvalue_use calls didn't strike me as wrong because [expr.cond]/7
> > says that lvalue-to-rvalue conversion is performed on the second and third
> > operands.
> 
> Only after we've decided (in /6) that the result is a prvalue.

Oh, I see.  :~

> > With those mark_lvalue_use calls removed, we'd not issue the
> > warning for
> > 
> >(b ? (x = 2) : y) = 1;
> >(b ? x : (y = 5)) = 1;
> 
> Why wouldn't we?  The assignment should call mark_lvalue_use for the LHS,
> which recursively applies it to the arms of the ?:.

Aha: we call mark_lvalue_use_*nonread* and the warning was guarded by
read_p.  I don't know why I did it, I see no regressions if I just
remove the check.  And then I get the expected results.

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

-- >8 --
Since most of volatile is deprecated in C++20, we are required to warn
for compound assignments to volatile variables and so on.  But here we
have

  volatile int x, y, z;
  (b ? x : y) = 1;

and we shouldn't warn, because simple assignments like x = 24; should
not provoke the warning when they are a discarded-value expression.

We warn here because when ?: is used as an lvalue, we transform it in
cp_build_modify_expr/COND_EXPR from (a ? b : c) = rhs to

  (a ? (b = rhs) : (c = rhs))

and build_conditional_expr then calls mark_lvalue_use for the new
artificial assignments, which then evokes the warning.  The calls
to mark_lvalue_use were added in r160289 to suppress warnings in
Wunused-var-10.c, but looks like they're no longer needed.

To warn on

(b ? (x = 2) : y) = 1;
(b ? x : (y = 5)) = 1;

I've tweaked a check in mark_use/MODIFY_EXPR.

I'd argue this is a regression because GCC 9 doesn't warn.

gcc/cp/ChangeLog:

PR c++/98947
* call.c (build_conditional_expr_1): Don't call mark_lvalue_use
on arg2/arg3.
* expr.c (mark_use) : Don't check read_p when
issuing the -Wvolatile warning.  Only set TREE_THIS_VOLATILE if
a warning was emitted.

gcc/testsuite/ChangeLog:

PR c++/98947
* g++.dg/cpp2a/volatile5.C: New test.
---
 gcc/cp/call.c  |  2 --
 gcc/cp/expr.c  | 14 +++---
 gcc/testsuite/g++.dg/cpp2a/volatile5.C | 15 +++
 3 files changed, 22 insertions(+), 9 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp2a/volatile5.C

diff --git a/gcc/cp/call.c b/gcc/cp/call.c
index c7e13f3a22b..4744c9768ec 100644
--- a/gcc/cp/call.c
+++ b/gcc/cp/call.c
@@ -5559,8 +5559,6 @@ build_conditional_expr_1 (const op_location_t ,
   && same_type_p (arg2_type, arg3_type))
 {
   result_type = arg2_type;
-  arg2 = mark_lvalue_use (arg2);
-  arg3 = mark_lvalue_use (arg3);
   goto valid_operands;
 }
 
diff --git a/gcc/cp/expr.c b/gcc/cp/expr.c
index 480e740f08c..d16d1896f2d 100644
--- a/gcc/cp/expr.c
+++ b/gcc/cp/expr.c
@@ -224,17 +224,17 @@ mark_use (tree expr, bool rvalue_p, bool read_p,
 a volatile-qualified type is deprecated unless the assignment
 is either a discarded-value expression or appears in an
 unevaluated context."  */
- if (read_p
- && !cp_unevaluated_operand
+ if (!cp_unevaluated_operand
  && (TREE_THIS_VOLATILE (lhs)
  || CP_TYPE_VOLATILE_P (TREE_TYPE (lhs)))
  && !TREE_THIS_VOLATILE (expr))
{
- warning_at (location_of (expr), OPT_Wvolatile,
- "using value of simple assignment with %-"
- "qualified left operand is deprecated");
- /* Make sure not to warn about this assignment again.  */
- TREE_THIS_VOLATILE (expr) = true;
+ if (warning_at 

[Bug analyzer/98575] [11 regression] gcc.dg/analyzer/pr94851-1.c fails after r11-6495

[dmalcolm at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #2 from David Malcolm  ---
This turns out to be due to differences in the inline implementation of getchar
in  which expose a latent bug in leak-detection.

On my x86_64 Fedora 32 box,
/usr/include/bits/stdio.h is from glibc-headers-2.31-2.fc32.x86_64 and has:

/* Read a character from stdin.  */
__STDIO_INLINE int
getchar (void)
{
  return getc (stdin);
}

On gcc135 in the GCC compile farm,
/usr/include/bits/stdio.h is from glibc-headers-2.17-307.el7.1.ppc64le and has:

/* Read a character from stdin.  */
__STDIO_INLINE int
getchar (void)
{
  return _IO_getc (stdin);
}

The analyzer's sm-file.cc "knows" about "getc" and thus the analyzer treats
getc as having no side-effects.
In contrast, it doesn't "know" about "_IO_getc" and thus treats it as
potentially clobbering curbp, which exposes a latent false-positive bug in leak
detection.

The reported leak seems like a bug where the analyzer doesn't seem to grok that
a pointer written through a clobbered global variable is still live if that
global variable hasn't been clobbered again.  A minimal reproducer for this is:

void **g;

extern void unknown_fn (void);

int test(void)
{
  void *p;
#ifdef CALL_UNKNOWN
  unknown_fn ();
#endif
  p = __builtin_malloc(1024);
  *g = p;
  return 0;
}

Without -DCALL_UNKNOWN:
  ./xgcc -B. -S t.c -fanalyzer
  (no output)

With -DCALL_UNKNOWN:
  ./xgcc -B. -S t.c -fanalyzer -DCALL_UNKNOWN
  t.c: In function ‘test’:
  t.c:13:10: warning: leak of ‘p’ [CWE-401] [-Wanalyzer-malloc-leak]
 13 |   return 0;
|  ^
‘test’: events 1-2
  |
  |   11 |   p = __builtin_malloc(1024);
  |  |   ^~
  |  |   |
  |  |   (1) allocated here
  |   12 |   *g = p;
  |   13 |   return 0;
  |  |  ~
  |  |  |
  |  |  (2) ‘p’ leaks here; was allocated at (1)
  |

Re: Comma Operator - Left to Right Associativity

[AJ D via Gcc]

Yes, there is only function argument which is the result of the comma
operator.

On Thu, Feb 4, 2021 at 2:46 PM AJ D  wrote:

> Nope, -std=c++17 didn’t help either.
>
> On Thu, Feb 4, 2021 at 1:33 PM David Brown 
> wrote:
>
>>
>>
>> On 04/02/2021 22:21, Andreas Schwab wrote:
>> > On Feb 04 2021, David Brown wrote:
>> >
>> >> For the built-in comma operator, you get guaranteed order of evaluation
>> >> (or more precisely, guaranteed order of visible side-effects).  But for
>> >> a user-defined comma operator, you do not - until C++17, which has
>> >> guaranteed evaluation ordering in some circumstances.
>> >
>> > But not the evaluation order of function arguments.  See
>> > 
>> Sequenced-before
>> > rules, rule 15.
>>
>> Correct.
>>
>> >
>> >> Try your test again with "-std=c++17" or "-std=g++17" - if the order is
>> >> still reversed, it's a gcc bug (AFAICS).
>> >
>> > I don't think so.
>> >
>>
>> Unless I am missing something, in the OP's program it is a user-defined
>> comma operator that is called.  There is only one argument to the
>> "test_comma_operator" function, the result of that user-defined comma
>> operator.  So rule 15 above does not apply - rule 16 applies.
>>
>> At least that is /my/ reading of the cppreference page and the OP's
>> program.
>>
>> David
>>
>>

Re: Comma Operator - Left to Right Associativity

[AJ D via Gcc]

Nope, -std=c++17 didn’t help either.

On Thu, Feb 4, 2021 at 1:33 PM David Brown  wrote:

>
>
> On 04/02/2021 22:21, Andreas Schwab wrote:
> > On Feb 04 2021, David Brown wrote:
> >
> >> For the built-in comma operator, you get guaranteed order of evaluation
> >> (or more precisely, guaranteed order of visible side-effects).  But for
> >> a user-defined comma operator, you do not - until C++17, which has
> >> guaranteed evaluation ordering in some circumstances.
> >
> > But not the evaluation order of function arguments.  See
> >  Sequenced-before
> > rules, rule 15.
>
> Correct.
>
> >
> >> Try your test again with "-std=c++17" or "-std=g++17" - if the order is
> >> still reversed, it's a gcc bug (AFAICS).
> >
> > I don't think so.
> >
>
> Unless I am missing something, in the OP's program it is a user-defined
> comma operator that is called.  There is only one argument to the
> "test_comma_operator" function, the result of that user-defined comma
> operator.  So rule 15 above does not apply - rule 16 applies.
>
> At least that is /my/ reading of the cppreference page and the OP's
> program.
>
> David
>
>

[Bug testsuite/98325] [11 regression] gcc.dg/pr25376.c fails after r11-5027

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

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

https://gcc.gnu.org/g:0b34dbc0a24864b1674bff7a92fa3cf0f1cbcea1

commit r11-7109-g0b34dbc0a24864b1674bff7a92fa3cf0f1cbcea1
Author: Jakub Jelinek 
Date:   Thu Feb 4 23:42:09 2021 +0100

testsuite: Fix up pr25376.c on powerpc64-linux and array-quals-1.c on
powerpc-linux [PR98325]

The following patch fixes the pr25376.c testcase on powerpc64-linux
and array-quals-1.c on powerpc-linux.
Previously it failed like:
FAIL: gcc.dg/array-quals-1.c scan-assembler-symbol-section symbol ^_?a1\$
(found a1) has section ^.(const|rodata|srodata)|[RO] (found .sdata)
FAIL: gcc.dg/array-quals-1.c scan-assembler-symbol-section symbol ^_?b1\$
(found b1) has section ^.(const|rodata|srodata)|[RO] (found .sdata)
FAIL: gcc.dg/array-quals-1.c scan-assembler-symbol-section symbol ^_?c1\$
(found c1) has section ^.(const|rodata|srodata)|[RO] (found .sdata)
FAIL: gcc.dg/array-quals-1.c scan-assembler-symbol-section symbol ^_?d1\$
(found d1) has section ^.(const|rodata|srodata)|[RO] (found .sdata)
FAIL: gcc.dg/array-quals-1.c scan-assembler-symbol-section symbol ^_?p\$
(found p) has section ^.(const|rodata|srodata)|[RW] (found .sdata)
FAIL: gcc.dg/array-quals-1.c scan-assembler-symbol-section symbol ^_?p1\$
(found p1) has section ^.(const|rodata|srodata)|[RW] (found .sdata)
FAIL: gcc.dg/array-quals-1.c scan-assembler-symbol-section symbol ^_?q\$
(found q) has section ^.(const|rodata|srodata)|[RW] (found .sdata)
FAIL: gcc.dg/array-quals-1.c scan-assembler-symbol-section symbol ^_?q1\$
(found q1) has section ^.(const|rodata|srodata)|[RW] (found .sdata)
FAIL: gcc.dg/array-quals-1.c scan-assembler-symbol-section symbol ^_?r\$
(found r) has section ^.(const|rodata|srodata)|[RW] (found .sdata)
FAIL: gcc.dg/array-quals-1.c scan-assembler-symbol-section symbol ^_?r1\$
(found r1) has section ^.(const|rodata|srodata)|[RW] (found .sdata)
FAIL: gcc.dg/array-quals-1.c scan-assembler-symbol-section symbol ^_?s\$
(found s) has section ^.(const|rodata|srodata)|[RW] (found .sdata)
FAIL: gcc.dg/array-quals-1.c scan-assembler-symbol-section symbol ^_?s1\$
(found s1) has section ^.(const|rodata|srodata)|[RW] (found .sdata)
FAIL: gcc.dg/array-quals-1.c scan-assembler-symbol-section symbol ^_?t\$
(found t) has section ^.(const|rodata|srodata)|[RW] (found .sdata)
FAIL: gcc.dg/array-quals-1.c scan-assembler-symbol-section symbol ^_?t1\$
(found t1) has section ^.(const|rodata|srodata)|[RW] (found .sdata)
FAIL: gcc.dg/pr25376.c scan-assembler-symbol-section symbol simple\$ (found
.L.simple) has section
^.?my_named_section|simple[DS]|^".opd" (found .opd)
FAIL: gcc.dg/pr25376.c scan-assembler-symbol-section symbol simple\$ (found
simple) has section
^.?my_named_section|simple[DS]|^".opd" (found .opd)

The problem with pr25376.c testcase are the ELFv1 function descriptors,
.sectionmy_named_section,"ax",@progbits
.align 2
.globl simple
.section".opd","aw"
.align 3
simple:
.quad   .L.simple,.TOC.@tocbase,0
.previous
.type   simple, @function
.L.simple:

so the simple symbol is found in the .opd section rather than in the
my_named_section the test attempts to verify for that symbol.
This patch deals it with two changes, the last two hunks in scanasm.exp
teach it about the behavior of .previous directive and the first hunk
for powerpc if symbol is in .opd section will try section in which the
.L.symbol label is instead.

The array-quals-1.c test fails because on powerpc-linux the symbols
are emitted into .sdata section rather than one of the expected ones.

2021-02-04  Jakub Jelinek  

PR testsuite/98325
* lib/scanasm.exp (dg-scan-symbol-section): For powerpc*-*-*
targets if
$section is .opd, look at .L.$symbol_name's section.
(parse_section_section_of_symbols): Handle .previous directive.
* gcc.dg/array-quals-1.c: Allow .sdata section.

gcc-8-20210204 is now available

[GCC Administrator via Gcc]

Snapshot gcc-8-20210204 is now available on
  https://gcc.gnu.org/pub/gcc/snapshots/8-20210204/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 8 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch releases/gcc-8 
revision 67620b038d9746e2ebf274548cd9de0d853ba909

You'll find:

 gcc-8-20210204.tar.xzComplete GCC

  SHA256=1eed7af357605081e70828007eb81aa9fcb7a5aae8401e94cac72e916955907d
  SHA1=52e266a9768ad94df5793e0e31b49b2b51e04a7c

Diffs from 8-20210128 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-8
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

[Bug d/98910] [11 regression] locale_t undefined on Solaris

[ibuclaw at gdcproject dot org via Gcc-bugs]

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

--- Comment #5 from Iain Buclaw  ---
(In reply to Rainer Orth from comment #2)
> Unfortunately, even with your patch Solaris bootstrap is still broken:
> 

Sorry, I've just been a bit slow getting the second part in.  The first part
was just what I originally pushed upstream before this PR was raised.  The
second part includes what you gave here.

Re: [RFC] test builtin ratio for loop distribution

[Alexandre Oliva]

On Feb  4, 2021, Richard Biener  wrote:

>> >  b) if expansion would use BY_PIECES then expand to an unrolled loop
>> 
>> Why would that be better than keeping the constant-length memset call,
>> that would be turned into an unrolled loop during expand?

> Well, because of the possibly lost ctz and alignment info.

Funny you should mention that.  I got started with the expand-time
expansion yesterday, and found out that we're not using the alignment
information that is available.  Though the pointer is known to point to
an aligned object, we are going for 8-bit alignment for some reason.

The strategy I used there was to first check whether by_pieces would
expand inline a constant length near the max known length, then loop
over the bits in the variable length, expand in each iteration a
constant-length store-by-pieces for the fixed length corresponding to
that bit, and a test comparing the variable length with the fixed length
guarding the expansion of the store-by-pieces.  We may get larger code
this way (no loops), but only O(log(len)) compares.

I've also fixed some bugs in the ldist expander, so now it bootstraps,
but with a few regressions in the testsuite, that I'm yet to look into.

>> Uhh, thanks, but...  you realize nearly all of the gimple-building code
>> is one and the same for the loop and for trailing count misalignment?

> Sorry, the code lacked comments and so I didn't actually try decipering
> the code you generate ;)

Oh, come on, it was planly obscure ;-D

Sorry for posting an early-draft before polishing it up.

> The original motivation was really that esp. for small trip count loops
> the target knows best how to implement them.  Now, that completely
> fails of course in case the target doesn't implement any of this or
> the generic code fails because we lost ctz and alignment info.

In our case, generic code fails because it won't handle variable-sized
clear-by-pieces.  But then, I found out, when it's fixed-size, it also
makes the code worse, because it seems to expand to byte stores even
when the store-to object is known to have wider alignment:

union u {
  long long i;
  char c[8];
} x[8];
int s(union u *p, int k) {
  for (int i = k ? 0 : 3; i < 8; i++) {
for (int j = 0; j < 8; j++) {
  p[i].c[j] = 0;
} // becomes a memset to an 8-byte-aligned 8-byte object, then 8 byte stores
  }
}

>> > I think the builtins with alignment and calloc-style element count
>> > will be useful on its own.
>> 
>> Oh, I see, you're suggesting actual separate builtin functions.  Uhh...
>> I'm not sure I want to go there.  I'd much rather recover the ctz of the
>> length, and use it in existing code.

> Yeah, but when we generate memcpy there might not be a way to
> store the ctz info until RTL expansion where the magic should really happen 
> ...

True.  It can be recovered without much difficulty in the cases I've
looked at, but it could be lost in others.

> So I'd say go for improving RTL expansion.

'k, thanks

-- 
Alexandre Oliva, happy hacker  https://FSFLA.org/blogs/lxo/
   Free Software Activist GNU Toolchain Engineer
Vim, Vi, Voltei pro Emacs -- GNUlius Caesar

[committed] d: Merge upstream dmd 46133f761, druntime 0fd4364c

[Iain Buclaw via Gcc-patches]

Hi,

This patch merges the D front-end implementation with upstream dmd
46133f761, and the D runtime library with upstream druntime 0fd4364c.

Backports built-in function handling from upstream, adding a new
intrinsic `byteswap(ushort)`.

Intrinsic modules have been updated accordingly in the runtime library,
and a few more platform-specific fixes have been downstreamed as well.

Bootstrapped and regression tested on x86_64-linux-gnu/-m32/-mx32, and
committed to mainline.

Regards,
Iain.

---
gcc/d/ChangeLog:

* dmd/MERGE: Merge upstream dmd 46133f761.
* d-builtins.cc (d_build_builtins_module): Set builtins as BUILTINgcc.
(maybe_set_builtin_1): Likewise.
* d-frontend.cc (eval_builtin): Adjust condition for early return.
* intrinsics.cc (maybe_set_intrinsic): Set intrinsics as BUILTINgcc.
(maybe_expand_intrinsic): Add case for INTRINSIC_BSWAP16.
* intrinsics.def (INTRINSIC_BT): Update signature.
(INTRINSIC_BT64): Likewise.
(INTRINSIC_BSWAP16): New intrinsic.
(INTRINSIC_VLOAD8): Update module.
(INTRINSIC_VLOAD16): Likewise.
(INTRINSIC_VLOAD32): Likewise.
(INTRINSIC_VLOAD64): Likewise.
(INTRINSIC_VSTORE8): Likewise.
(INTRINSIC_VSTORE16): Likewise.
(INTRINSIC_VSTORE32): Likewise.
(INTRINSIC_VSTORE64): Likewise.
(INTRINSIC_ADDS): Update signature.
(INTRINSIC_ADDSL): Likewise.
(INTRINSIC_ADDU): Likewise.
(INTRINSIC_ADDUL): Likewise.
(INTRINSIC_SUBS): Likewise.
(INTRINSIC_SUBSL): Likewise.
(INTRINSIC_SUBU): Likewise.
(INTRINSIC_SUBUL): Likewise.
(INTRINSIC_MULS): Likewise.
(INTRINSIC_MULSL): Likewise.
(INTRINSIC_MULU): Likewise.
(INTRINSIC_MULUI): Likewise.
(INTRINSIC_MULUL): Likewise.
(INTRINSIC_NEGS): Likewise.
(INTRINSIC_NEGSL): Likewise.


libphobos/ChangeLog:

PR d/98910
* libdruntime/MERGE: Merge upstream druntime 0fd4364c.
* libdruntime/Makefile.am (DRUNTIME_DSOURCES): Add core/volatile.d.
* libdruntime/Makefile.in: Regenerate.
* testsuite/libphobos.allocations/tls_gc_integration.d: Update test.

gcc/testsuite/ChangeLog:

* gdc.dg/intrinsics.d: Update test.
---
 gcc/d/d-builtins.cc   |4 +-
 gcc/d/d-frontend.cc   |2 +-
 gcc/d/dmd/MERGE   |2 +-
 gcc/d/dmd/declaration.h   |   40 +-
 gcc/d/dmd/dinterpret.c|2 +-
 gcc/d/dmd/idgen.c |   38 +
 gcc/d/dmd/root/ctfloat.h  |   18 +
 gcc/d/intrinsics.cc   |7 +-
 gcc/d/intrinsics.def  |   53 +-
 gcc/testsuite/gdc.dg/intrinsics.d |3 +
 libphobos/libdruntime/MERGE   |2 +-
 libphobos/libdruntime/Makefile.am |   31 +-
 libphobos/libdruntime/Makefile.in |   48 +-
 libphobos/libdruntime/core/bitop.d|  145 ++-
 libphobos/libdruntime/core/checkedint.d   |   48 +-
 libphobos/libdruntime/core/cpuid.d|   69 +-
 libphobos/libdruntime/core/internal/traits.d  |  152 ++-
 libphobos/libdruntime/core/simd.d | 1096 ++---
 libphobos/libdruntime/core/stdc/stdio.d   |2 +-
 libphobos/libdruntime/core/sys/posix/locale.d |   28 +
 libphobos/libdruntime/core/thread/osthread.d  |8 -
 libphobos/libdruntime/core/vararg.d   |  122 ++
 libphobos/libdruntime/core/volatile.d |   67 +
 libphobos/libdruntime/rt/lifetime.d   |  109 +-
 .../tls_gc_integration.d  |2 +-
 25 files changed, 1329 insertions(+), 769 deletions(-)
 create mode 100644 libphobos/libdruntime/core/volatile.d

diff --git a/gcc/d/d-builtins.cc b/gcc/d/d-builtins.cc
index 3f1533b592f..c45edc2fa3f 100644
--- a/gcc/d/d-builtins.cc
+++ b/gcc/d/d-builtins.cc
@@ -566,7 +566,7 @@ d_build_builtins_module (Module *m)
   STCextern, tf);
   DECL_LANG_SPECIFIC (decl) = build_lang_decl (func);
   func->csym = decl;
-  func->builtin = BUILTINyes;
+  func->builtin = BUILTINgcc;
 
   members->push (func);
 }
@@ -706,7 +706,7 @@ maybe_set_builtin_1 (Dsymbol *d)
  /* Found a match, tell the frontend this is a builtin.  */
  DECL_LANG_SPECIFIC (t) = build_lang_decl (fd);
  fd->csym = t;
- fd->builtin = BUILTINyes;
+ fd->builtin = BUILTINgcc;
  return;
}
 }
diff --git a/gcc/d/d-frontend.cc b/gcc/d/d-frontend.cc
index 32550ecfd64..84c70f8ee6a 100644
--- a/gcc/d/d-frontend.cc
+++ b/gcc/d/d-frontend.cc
@@ -158,7 +158,7 @@ isBuiltin (FuncDeclaration *fd)
 Expression *
 eval_builtin (Loc loc, FuncDeclaration *fd, Expressions *arguments)
 {
-  if (fd->builtin != BUILTINyes)
+  if (fd->builtin == BUILTINunimp)
 return NULL;
 
   tree decl = 

[Bug d/98910] [11 regression] locale_t undefined on Solaris

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

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

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

commit r11-7108-gc1d56e6a737418b7b48a53b355f588ea14f1b9a9
Author: Iain Buclaw 
Date:   Thu Feb 4 22:34:22 2021 +0100

d: Merge upstream dmd 46133f761, druntime 0fd4364c

D front-end changes:

 - Backported built-in function handling from upstream.

 - Added new intrinsic `byteswap(ushort)`.

Druntime changes:

 - Update intrinsic modules core.bitop, core.checkedint, core.simd,
   core.vararg, and core.volatile.

 - Backport platform-specific fixes for runtime modules core.cpuid,
   core.internal.traits, and rt.lifetime.

 - Backport openbsd fixes for core.stdc.stdio.

 - Backport solaris fixes for core.sys.posix.locale, and
   core.thread.osthread (PR98910).

gcc/d/ChangeLog:

* dmd/MERGE: Merge upstream dmd 46133f761.
* d-builtins.cc (d_build_builtins_module): Set builtins as
BUILTINgcc.
(maybe_set_builtin_1): Likewise.
* d-frontend.cc (eval_builtin): Adjust condition for early return.
* intrinsics.cc (maybe_set_intrinsic): Set intrinsics as
BUILTINgcc.
(maybe_expand_intrinsic): Add case for INTRINSIC_BSWAP16.
* intrinsics.def (INTRINSIC_BT): Update signature.
(INTRINSIC_BT64): Likewise.
(INTRINSIC_BSWAP16): New intrinsic.
(INTRINSIC_VLOAD8): Update module.
(INTRINSIC_VLOAD16): Likewise.
(INTRINSIC_VLOAD32): Likewise.
(INTRINSIC_VLOAD64): Likewise.
(INTRINSIC_VSTORE8): Likewise.
(INTRINSIC_VSTORE16): Likewise.
(INTRINSIC_VSTORE32): Likewise.
(INTRINSIC_VSTORE64): Likewise.
(INTRINSIC_ADDS): Update signature.
(INTRINSIC_ADDSL): Likewise.
(INTRINSIC_ADDU): Likewise.
(INTRINSIC_ADDUL): Likewise.
(INTRINSIC_SUBS): Likewise.
(INTRINSIC_SUBSL): Likewise.
(INTRINSIC_SUBU): Likewise.
(INTRINSIC_SUBUL): Likewise.
(INTRINSIC_MULS): Likewise.
(INTRINSIC_MULSL): Likewise.
(INTRINSIC_MULU): Likewise.
(INTRINSIC_MULUI): Likewise.
(INTRINSIC_MULUL): Likewise.
(INTRINSIC_NEGS): Likewise.
(INTRINSIC_NEGSL): Likewise.

libphobos/ChangeLog:

PR d/98910
* libdruntime/MERGE: Merge upstream druntime 0fd4364c.
* libdruntime/Makefile.am (DRUNTIME_DSOURCES): Add core/volatile.d.
* libdruntime/Makefile.in: Regenerate.
* testsuite/libphobos.allocations/tls_gc_integration.d: Update
test.

gcc/testsuite/ChangeLog:

* gdc.dg/intrinsics.d: Update test.

[Bug c/97882] [8/9/10/11 Regression] Segmentation Fault on improper redeclaration of function

[msebor at gcc dot gnu.org via Gcc-bugs]

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

Martin Sebor  changed:

   What|Removed |Added

 Resolution|--- |FIXED
  Known to fail||10.2.0, 7.3.0, 8.3.0, 9.2.0
 Status|ASSIGNED|RESOLVED
   Target Milestone|8.5 |11.0

--- Comment #7 from Martin Sebor  ---
Fixed.  Will not backport per comment 1.

[Bug c/97882] [8/9/10/11 Regression] Segmentation Fault on improper redeclaration of function

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #6 from CVS Commits  ---
The master branch has been updated by Martin Sebor :

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

commit r11-7107-gce5720447c69286599b96bae53ae854b1bbe41fa
Author: Martin Sebor 
Date:   Thu Feb 4 14:50:23 2021 -0700

PR c/97882 - Segmentation Fault on improper redeclaration of function

gcc/c/ChangeLog:

PR c/97882
* c-decl.c (locate_old_decl): Add type to diagnostic output.
(diagnose_mismatched_decls): Same.
(start_function): Introduce temporaries for better readability.
* c-typeck.c (comptypes_internal): Only consider complete enum
types in comparisons with integers.

gcc/testsuite/ChangeLog:

PR c/97882
* gcc.dg/decl-8.c: Adjust text of expected diagnostic.
* gcc.dg/label-decl-4.c: Same.
* gcc.dg/mismatch-decl-1.c: Same.
* gcc.dg/old-style-then-proto-1.c: Same.
* gcc.dg/parm-mismatch-1.c: Same.
* gcc.dg/pr35445.c: Same.
* gcc.dg/redecl-11.c: Same.
* gcc.dg/redecl-12.c: Same.
* gcc.dg/redecl-13.c: Same.
* gcc.dg/redecl-15.c: Same.
* gcc.dg/tls/thr-init-1.c: Same.
* objc.dg/id-1.m: Same.
* objc.dg/tls/diag-3.m: Same.
* gcc.dg/pr97882.c: New test.
* gcc.dg/qual-return-7.c: New test.
* gcc.dg/qual-return-8.c: New test.

[Bug lto/98971] New: LTO removes __patchable_function_entries

[gabriel at inconstante dot net.br via Gcc-bugs]

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

Bug ID: 98971
   Summary: LTO removes __patchable_function_entries
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gabriel at inconstante dot net.br
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

Building with -flto removes the effects of -fpatchable-function-entries, or at
least some of them.

For instance, building the following code:

$ cat libtesta.c
int
testa7(void)
{
  return 7;
}

with:

$ gcc libtesta.c -fPIC -fpatchable-function-entry=4,2 -flto -c -o libtesta.o
$ gcc libtesta.o -flto -shared -o libtesta.so

removes the nop padding usually generated with -fpatchable-function-entry, as
well as it removes the __patchable_function_entries section from the resulting
binaries. The intermediate libtesta.o already lacks both:

$ readelf --sections libtesta.o | grep __patchable
$ readelf --sections libtesta.so | grep __patchable
$ objdump -d libtesta.so | grep ":" -C3
10f0 :
10f0:   e9 7b ff ff ff  jmpq   1070 

10f5 :
10f5:   55  push   %rbp
10f6:   48 89 e5mov%rsp,%rbp
10f9:   b8 07 00 00 00  mov$0x7,%eax

Without -flto, I get what I expected:

$ readelf --sections libtesta.o | grep __patchable
  [ 4] __patchable_[...] PROGBITS   0050
$ readelf --sections libtesta.so | grep __patchable
  [19] __patchable_[...] PROGBITS 4020  3020
$ objdump -d libtesta.so | grep ":" -C3
10f5:   90  nop
10f6:   90  nop

10f7 :
10f7:   90  nop
10f8:   90  nop
10f9:   55  push   %rbp

Building with a single gcc command, such as:

$ gcc libtesta.c -fPIC -fpatchable-function-entry=4,2 -flto -shared -o
libtesta.so

also works as I expected, i.e.: the nops and the __patchable_function_entries
are kept.


Is this the intended behavior? Am I using it wrong? Or is this a bug?

Cheers

PS: Tested with the branch for gcc 10, with trunk, and with the compilers from
openSUSE and Debian.

Re: [PATCH] testsuite: Fix up pr25376.c on powerpc64-linux and array-quals-1.c on powerpc-linux [PR98325]

[David Edelsohn via Gcc-patches]

On Thu, Feb 4, 2021 at 4:26 PM Segher Boessenkool
 wrote:
>
> Hi!
>
> On Thu, Feb 04, 2021 at 09:26:47PM +0100, Jakub Jelinek wrote:
> > On Mon, Nov 16, 2020 at 06:14:52PM -0500, David Edelsohn via Gcc-patches 
> > wrote:
> > > Jenkins does function on AIX.  I will take an action item to create
> > > another LPAR on the AIX systems at OSUOSL for Jenkins and coordinate
> > > with you to connect it to the terrific Jenkins infrastructure for GCC
> > > that you have deployed.
> >
> > The following patch fixes the pr25376.c testcase on powerpc64-linux
> > and array-quals-1.c on powerpc-linux.
> > Previously it failed like:
> > FAIL: gcc.dg/array-quals-1.c scan-assembler-symbol-section symbol ^_?a1\$ 
> > (found a1) has section ^.(const|rodata|srodata)|[RO] (found 
> > .sdata)
> > FAIL: gcc.dg/array-quals-1.c scan-assembler-symbol-section symbol ^_?b1\$ 
> > (found b1) has section ^.(const|rodata|srodata)|[RO] (found 
> > .sdata)
> > FAIL: gcc.dg/array-quals-1.c scan-assembler-symbol-section symbol ^_?c1\$ 
> > (found c1) has section ^.(const|rodata|srodata)|[RO] (found 
> > .sdata)
> > FAIL: gcc.dg/array-quals-1.c scan-assembler-symbol-section symbol ^_?d1\$ 
> > (found d1) has section ^.(const|rodata|srodata)|[RO] (found 
> > .sdata)
> > FAIL: gcc.dg/array-quals-1.c scan-assembler-symbol-section symbol ^_?p\$ 
> > (found p) has section ^.(const|rodata|srodata)|[RW] (found 
> > .sdata)
> > FAIL: gcc.dg/array-quals-1.c scan-assembler-symbol-section symbol ^_?p1\$ 
> > (found p1) has section ^.(const|rodata|srodata)|[RW] (found 
> > .sdata)
> > FAIL: gcc.dg/array-quals-1.c scan-assembler-symbol-section symbol ^_?q\$ 
> > (found q) has section ^.(const|rodata|srodata)|[RW] (found 
> > .sdata)
> > FAIL: gcc.dg/array-quals-1.c scan-assembler-symbol-section symbol ^_?q1\$ 
> > (found q1) has section ^.(const|rodata|srodata)|[RW] (found 
> > .sdata)
> > FAIL: gcc.dg/array-quals-1.c scan-assembler-symbol-section symbol ^_?r\$ 
> > (found r) has section ^.(const|rodata|srodata)|[RW] (found 
> > .sdata)
> > FAIL: gcc.dg/array-quals-1.c scan-assembler-symbol-section symbol ^_?r1\$ 
> > (found r1) has section ^.(const|rodata|srodata)|[RW] (found 
> > .sdata)
> > FAIL: gcc.dg/array-quals-1.c scan-assembler-symbol-section symbol ^_?s\$ 
> > (found s) has section ^.(const|rodata|srodata)|[RW] (found 
> > .sdata)
> > FAIL: gcc.dg/array-quals-1.c scan-assembler-symbol-section symbol ^_?s1\$ 
> > (found s1) has section ^.(const|rodata|srodata)|[RW] (found 
> > .sdata)
> > FAIL: gcc.dg/array-quals-1.c scan-assembler-symbol-section symbol ^_?t\$ 
> > (found t) has section ^.(const|rodata|srodata)|[RW] (found 
> > .sdata)
> > FAIL: gcc.dg/array-quals-1.c scan-assembler-symbol-section symbol ^_?t1\$ 
> > (found t1) has section ^.(const|rodata|srodata)|[RW] (found 
> > .sdata)
> > FAIL: gcc.dg/pr25376.c scan-assembler-symbol-section symbol simple\$ (found 
> > .L.simple) has section 
> > ^.?my_named_section|simple[DS]|^".opd" (found .opd)
> > FAIL: gcc.dg/pr25376.c scan-assembler-symbol-section symbol simple\$ (found 
> > simple) has section 
> > ^.?my_named_section|simple[DS]|^".opd" (found .opd)
> >
> > The problem with pr25376.c testcase are the ELFv1 function descriptors,
> > .sectionmy_named_section,"ax",@progbits
> > .align 2
> > .globl simple
> > .section".opd","aw"
> > .align 3
> > simple:
> > .quad   .L.simple,.TOC.@tocbase,0
> > .previous
> > .type   simple, @function
> > .L.simple:
> >
> > so the simple symbol is found in the .opd section rather than in the
> > my_named_section the test attempts to verify for that symbol.
> > This patch deals it with two changes, the last two hunks in scanasm.exp
> > teach it about the behavior of .previous directive and the first hunk
> > for powerpc if symbol is in .opd section will try section in which the
> > .L.symbol label is instead.
> >
> > The array-quals-1.c test fails because on powerpc-linux the symbols
> > are emitted into .sdata section rather than one of the expected ones.
> >
> > Tested on powerpc64-linux (-m32/-m64) and x86_64-linux (-m32/-m64), ok for
> > trunk?
>
> The Tcl looks okay; whether it actually does the right thing, I do not
> know :-)
>
> > Whether this fixes also AIX, I have no idea.
>
> Yeah me neither.  So okay for trunk, if David thinks it is okay as well.
> Thanks!

We'll see if it starts to XPASS on AIX.

- David

Re: Comma Operator - Left to Right Associativity

[David Brown]

On 04/02/2021 22:21, Andreas Schwab wrote:
> On Feb 04 2021, David Brown wrote:
> 
>> For the built-in comma operator, you get guaranteed order of evaluation
>> (or more precisely, guaranteed order of visible side-effects).  But for
>> a user-defined comma operator, you do not - until C++17, which has
>> guaranteed evaluation ordering in some circumstances.
> 
> But not the evaluation order of function arguments.  See
>  Sequenced-before
> rules, rule 15.

Correct.

> 
>> Try your test again with "-std=c++17" or "-std=g++17" - if the order is
>> still reversed, it's a gcc bug (AFAICS).
> 
> I don't think so.
> 

Unless I am missing something, in the OP's program it is a user-defined
comma operator that is called.  There is only one argument to the
"test_comma_operator" function, the result of that user-defined comma
operator.  So rule 15 above does not apply - rule 16 applies.

At least that is /my/ reading of the cppreference page and the OP's program.

David

[PATCH] PR98096: inline-asm: Take inout operands into account for access to labels by names.

[Vladimir Makarov via Gcc-patches]

The following patch solves

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

The patch is for a new GCC extension -- asm goto with output reloads.

GCC splits inout operands (with constraint "+") into output and new 
matched input operands during gimplfication.  Addressing input or output 
operands by name or number is not a problem as the new input operands 
are added at the end of existing input operands.


However it became a problem for labels in asm goto with output reloads.  
Addressing labels should take into account the added matched input 
operands.  The patch solves the problem.


The patch was successfully bootstrapped and tested on x86-64.

Is it ok to commit into the trunk?



diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index 8daa1c67974..71b35252b84 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -10656,16 +10656,23 @@ should use @samp{+} constraint modifier meaning that the operand is
 input and output one.  With this modifier you will have the correct
 values on all possible paths from the @code{asm goto}.
 
-To reference a label in the assembler template,
-prefix it with @samp{%l} (lowercase @samp{L}) followed 
-by its (zero-based) position in @var{GotoLabels} plus the number of input 
-operands.  For example, if the @code{asm} has three inputs and references two 
-labels, refer to the first label as @samp{%l3} and the second as @samp{%l4}).
-
-Alternately, you can reference labels using the actual C label name enclosed
-in brackets.  For example, to reference a label named @code{carry}, you can
-use @samp{%l[carry]}.  The label must still be listed in the @var{GotoLabels}
-section when using this approach.
+To reference a label in the assembler template, prefix it with
+@samp{%l} (lowercase @samp{L}) followed by its (zero-based) position
+in @var{GotoLabels} plus the number of input and output operands.
+Output operand with constraint modifier @samp{+} is counted as two
+operands because it is considered as one output and one input operand.
+For example, if the @code{asm} has three inputs, one output operand
+with constraint modifier @samp{+} and one output operand with
+constraint modifier @samp{=} and references two labels, refer to the
+first label as @samp{%l6} and the second as @samp{%l7}).
+
+Alternately, you can reference labels using the actual C label name
+enclosed in brackets.  For example, to reference a label named
+@code{carry}, you can use @samp{%l[carry]}.  The label must still be
+listed in the @var{GotoLabels} section when using this approach.  It
+is better to use the named references for labels as in this case you
+can avoid counting input and output operands and special treatment of
+output operands with constraint modifier @samp{+}.
 
 Here is an example of @code{asm goto} for i386:
 
diff --git a/gcc/stmt.c b/gcc/stmt.c
index bd836d8f65f..f52ffaf8e75 100644
--- a/gcc/stmt.c
+++ b/gcc/stmt.c
@@ -611,7 +611,7 @@ static char *
 resolve_operand_name_1 (char *p, tree outputs, tree inputs, tree labels)
 {
   char *q;
-  int op;
+  int op, op_inout;
   tree t;
 
   /* Collect the operand name.  */
@@ -624,11 +624,14 @@ resolve_operand_name_1 (char *p, tree outputs, tree inputs, tree labels)
   *q = '\0';
 
   /* Resolve the name to a number.  */
-  for (op = 0, t = outputs; t ; t = TREE_CHAIN (t), op++)
+  for (op_inout = op = 0, t = outputs; t ; t = TREE_CHAIN (t), op++)
 {
   tree name = TREE_PURPOSE (TREE_PURPOSE (t));
   if (name && strcmp (TREE_STRING_POINTER (name), p) == 0)
 	goto found;
+  tree constraint = TREE_VALUE (TREE_PURPOSE (t));
+  if (constraint && strchr (TREE_STRING_POINTER (constraint), '+') != NULL)
+op_inout++;
 }
   for (t = inputs; t ; t = TREE_CHAIN (t), op++)
 {
@@ -636,6 +639,7 @@ resolve_operand_name_1 (char *p, tree outputs, tree inputs, tree labels)
   if (name && strcmp (TREE_STRING_POINTER (name), p) == 0)
 	goto found;
 }
+  op += op_inout;
   for (t = labels; t ; t = TREE_CHAIN (t), op++)
 {
   tree name = TREE_PURPOSE (t);
diff --git a/gcc/testsuite/gcc.c-torture/compile/pr98096.c b/gcc/testsuite/gcc.c-torture/compile/pr98096.c
new file mode 100644
index 000..95ad55c81aa
--- /dev/null
+++ b/gcc/testsuite/gcc.c-torture/compile/pr98096.c
@@ -0,0 +1,10 @@
+/* Test for correct naming of label operands in asm goto in case of presence of
+   input/output operands. */
+/* { dg-do compile } */
+int i, j;
+int f(void) {
+  asm goto ("# %0 %2" : "+r" (i) ::: jmp);
+  i += 2;
+  asm goto ("# %0 %1 %l[jmp]" : "+r" (i), "+r" (j) ::: jmp);
+ jmp: return i;
+}

Re: [PATCH] testsuite: Fix up pr25376.c on powerpc64-linux and array-quals-1.c on powerpc-linux [PR98325]

[Segher Boessenkool]

Hi!

On Thu, Feb 04, 2021 at 09:26:47PM +0100, Jakub Jelinek wrote:
> On Mon, Nov 16, 2020 at 06:14:52PM -0500, David Edelsohn via Gcc-patches 
> wrote:
> > Jenkins does function on AIX.  I will take an action item to create
> > another LPAR on the AIX systems at OSUOSL for Jenkins and coordinate
> > with you to connect it to the terrific Jenkins infrastructure for GCC
> > that you have deployed.
> 
> The following patch fixes the pr25376.c testcase on powerpc64-linux
> and array-quals-1.c on powerpc-linux.
> Previously it failed like:
> FAIL: gcc.dg/array-quals-1.c scan-assembler-symbol-section symbol ^_?a1\$ 
> (found a1) has section ^.(const|rodata|srodata)|[RO] (found 
> .sdata)
> FAIL: gcc.dg/array-quals-1.c scan-assembler-symbol-section symbol ^_?b1\$ 
> (found b1) has section ^.(const|rodata|srodata)|[RO] (found 
> .sdata)
> FAIL: gcc.dg/array-quals-1.c scan-assembler-symbol-section symbol ^_?c1\$ 
> (found c1) has section ^.(const|rodata|srodata)|[RO] (found 
> .sdata)
> FAIL: gcc.dg/array-quals-1.c scan-assembler-symbol-section symbol ^_?d1\$ 
> (found d1) has section ^.(const|rodata|srodata)|[RO] (found 
> .sdata)
> FAIL: gcc.dg/array-quals-1.c scan-assembler-symbol-section symbol ^_?p\$ 
> (found p) has section ^.(const|rodata|srodata)|[RW] (found .sdata)
> FAIL: gcc.dg/array-quals-1.c scan-assembler-symbol-section symbol ^_?p1\$ 
> (found p1) has section ^.(const|rodata|srodata)|[RW] (found 
> .sdata)
> FAIL: gcc.dg/array-quals-1.c scan-assembler-symbol-section symbol ^_?q\$ 
> (found q) has section ^.(const|rodata|srodata)|[RW] (found .sdata)
> FAIL: gcc.dg/array-quals-1.c scan-assembler-symbol-section symbol ^_?q1\$ 
> (found q1) has section ^.(const|rodata|srodata)|[RW] (found 
> .sdata)
> FAIL: gcc.dg/array-quals-1.c scan-assembler-symbol-section symbol ^_?r\$ 
> (found r) has section ^.(const|rodata|srodata)|[RW] (found .sdata)
> FAIL: gcc.dg/array-quals-1.c scan-assembler-symbol-section symbol ^_?r1\$ 
> (found r1) has section ^.(const|rodata|srodata)|[RW] (found 
> .sdata)
> FAIL: gcc.dg/array-quals-1.c scan-assembler-symbol-section symbol ^_?s\$ 
> (found s) has section ^.(const|rodata|srodata)|[RW] (found .sdata)
> FAIL: gcc.dg/array-quals-1.c scan-assembler-symbol-section symbol ^_?s1\$ 
> (found s1) has section ^.(const|rodata|srodata)|[RW] (found 
> .sdata)
> FAIL: gcc.dg/array-quals-1.c scan-assembler-symbol-section symbol ^_?t\$ 
> (found t) has section ^.(const|rodata|srodata)|[RW] (found .sdata)
> FAIL: gcc.dg/array-quals-1.c scan-assembler-symbol-section symbol ^_?t1\$ 
> (found t1) has section ^.(const|rodata|srodata)|[RW] (found 
> .sdata)
> FAIL: gcc.dg/pr25376.c scan-assembler-symbol-section symbol simple\$ (found 
> .L.simple) has section 
> ^.?my_named_section|simple[DS]|^".opd" (found .opd)
> FAIL: gcc.dg/pr25376.c scan-assembler-symbol-section symbol simple\$ (found 
> simple) has section 
> ^.?my_named_section|simple[DS]|^".opd" (found .opd)
> 
> The problem with pr25376.c testcase are the ELFv1 function descriptors,
> .sectionmy_named_section,"ax",@progbits
> .align 2
> .globl simple
> .section".opd","aw"
> .align 3
> simple:
> .quad   .L.simple,.TOC.@tocbase,0
> .previous
> .type   simple, @function
> .L.simple:
> 
> so the simple symbol is found in the .opd section rather than in the
> my_named_section the test attempts to verify for that symbol.
> This patch deals it with two changes, the last two hunks in scanasm.exp
> teach it about the behavior of .previous directive and the first hunk
> for powerpc if symbol is in .opd section will try section in which the
> .L.symbol label is instead.
> 
> The array-quals-1.c test fails because on powerpc-linux the symbols
> are emitted into .sdata section rather than one of the expected ones.
> 
> Tested on powerpc64-linux (-m32/-m64) and x86_64-linux (-m32/-m64), ok for
> trunk?

The Tcl looks okay; whether it actually does the right thing, I do not
know :-)

> Whether this fixes also AIX, I have no idea.

Yeah me neither.  So okay for trunk, if David thinks it is okay as well.
Thanks!


Segher

Re: Comma Operator - Left to Right Associativity

[Andreas Schwab]

On Feb 04 2021, David Brown wrote:

> For the built-in comma operator, you get guaranteed order of evaluation
> (or more precisely, guaranteed order of visible side-effects).  But for
> a user-defined comma operator, you do not - until C++17, which has
> guaranteed evaluation ordering in some circumstances.

But not the evaluation order of function arguments.  See
 Sequenced-before
rules, rule 15.

> Try your test again with "-std=c++17" or "-std=g++17" - if the order is
> still reversed, it's a gcc bug (AFAICS).

I don't think so.

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

[Bug d/98910] [11 regression] locale_t undefined on Solaris

[ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs]

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

--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
On top of the missing locale_t definition, the other issue I'd reported
is also still present:

/vol/gcc/src/hg/master/local/libphobos/libdruntime/core/thread/osthread.d:1468:12:
error: alias core.thread.osthread.idtype_t conflicts with alias
core.thread.osthread.idtype_t at
/vol/gcc/src/hg/master/local/libphobos/libdruntime/core/thread/osthread.d:162:12
 1468 | import core.sys.posix.sys.wait : idtype_t;
  |^

Re: [PATCH] rs6000: Fix MMA API - Add support for compatibility built-ins

[Segher Boessenkool]

Hi!

On Thu, Feb 04, 2021 at 02:40:20PM -0600, Peter Bergner wrote:
> The LLVM and GCC teams agreed to rename the __builtin_mma_assemble_pair and
> __builtin_mma_disassemble_pair built-ins to __builtin_vsx_assemble_pair and
> __builtin_vsx_disassemble_pair respectively.  It's too late to remove the
> old names, so this patch adds support for creating compatibility built-ins
> (ie, multiple built-in functions generate the same code) and then creates
> compatibility built-ins using the new names.

This needs a documentation update.  You can just delete the old names
there (i.e. rename everything there).

> This passed bootstrap and regtesting on powerpc64le-linux with no regressions.
> Ok for mainline?

Some comments:

> +#ifndef RS6000_BUILTIN_COMPAT
> +  #undef BU_COMPAT
> +  #define BU_COMPAT(ENUM, COMPAT_NAME)

Please do not do #undef unless necessary: it hides bugs (and that causes
more bugs).

>  BU_MMA_3 (ASSEMBLE_PAIR,"assemble_pair", MISC, mma_assemble_pair)
> +BU_COMPAT (MMA_BUILTIN_ASSEMBLE_PAIR, "vsx_assemble_pair")

You should do those the other way around (the mma_ one is the
compatibility one).  This matters, because if you disable the
compatibility builtins the vsx_ one should still be there, but not the
old name.  (It also makes more sense of course).

Okay for trunk with that fixed.  Also okay for gcc-10 after watching
a week or so for fallout.  Thanks!


Segher

Re: [PATCH] improve detection of incompatible redeclarations (PR 97882)

[Joseph Myers]

On Thu, 4 Feb 2021, Martin Sebor via Gcc-patches wrote:

> Okay, that's much simpler.  Thanks for nudging me in the right
> direction!  How's the attached patch? Retested on x86_64-linux.

OK, minus the addition of gcc/testsuite/c-c++-common/array-lit.s which 
looks like a mistake.

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

[Bug fortran/88735] Nested assignment triggers call of final method for right hand side

[drikosev at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Ev Drikos  ---
Created attachment 50129
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50129=edit
Test Case


IMHO, a simple workaround might be a deep copy in 'gfc_trans_scalar_assign' if
the LHS is finalizable (not pointer, artificial, or associate variable), just
in case it's also somewhere a dummy argument with the intent(out) attribute.

If this ok, the value b%x%i should be 124 after the assignment 'a=b' in #0

Hope this helps,
Ev. Drikos

[committed] [PR97701] LRA: Don't narrow class only for REG or MEM. A version modified for gcc 10 branch.

[Vladimir Makarov via Gcc-patches]

It seem that my recent patch for PR97701 for the trunk did not create 
new problems.  Therefore I am committing the following patch into 
gcc-10-branch.



commit 4918937f4c76b05eaa331f8d6f2571e2fddcc22b (HEAD -> releases/gcc-10)
Author: Vladimir N. Makarov 
Date:   Thu Feb 4 15:57:55 2021 -0500

[PR97701] LRA: Don't narrow class only for REG or MEM.  A version modified for gcc-10.

This is modified version of the patch committed for the trunk.  The
modification for gcc-10 includes lra-constraint.c code and the test.

gcc/ChangeLog:

PR target/97701
* lra-constraints.c (in_class_p): Don't narrow class only for REG
or MEM.

gcc/testsuite/ChangeLog:

PR target/97701
* gcc.target/aarch64/pr97701.c: New.

diff --git a/gcc/lra-constraints.c b/gcc/lra-constraints.c
index 088208b9c6e..bf04eb48ba6 100644
--- a/gcc/lra-constraints.c
+++ b/gcc/lra-constraints.c
@@ -244,6 +244,7 @@ in_class_p (rtx reg, enum reg_class cl, enum reg_class *new_class)
 {
   enum reg_class rclass, common_class;
   machine_mode reg_mode;
+  rtx src;
   int class_size, hard_regno, nregs, i, j;
   int regno = REGNO (reg);
 
@@ -259,6 +260,7 @@ in_class_p (rtx reg, enum reg_class cl, enum reg_class *new_class)
 }
   reg_mode = GET_MODE (reg);
   rclass = get_reg_class (regno);
+  src = curr_insn_set != NULL ? SET_SRC (curr_insn_set) : NULL;
   if (regno < new_regno_start
   /* Do not allow the constraints for reload instructions to
 	 influence the classes of new pseudos.  These reloads are
@@ -266,12 +268,10 @@ in_class_p (rtx reg, enum reg_class cl, enum reg_class *new_class)
 	 reload pseudos for one alternative may lead to situations
 	 where other reload pseudos are no longer allocatable.  */
   || (INSN_UID (curr_insn) >= new_insn_uid_start
-	  && curr_insn_set != NULL
-	  && ((OBJECT_P (SET_SRC (curr_insn_set))
-	   && ! CONSTANT_P (SET_SRC (curr_insn_set)))
-	  || (GET_CODE (SET_SRC (curr_insn_set)) == SUBREG
-		  && OBJECT_P (SUBREG_REG (SET_SRC (curr_insn_set)))
-		  && ! CONSTANT_P (SUBREG_REG (SET_SRC (curr_insn_set)))
+	  && src != NULL
+	  && ((REG_P (src) || MEM_P (src))
+	  || (GET_CODE (src) == SUBREG
+		  && (REG_P (SUBREG_REG (src)) || MEM_P (SUBREG_REG (src)))
 /* When we don't know what class will be used finally for reload
pseudos, we use ALL_REGS.  */
 return ((regno >= new_regno_start && rclass == ALL_REGS)
diff --git a/gcc/testsuite/gcc.target/aarch64/pr97701.c b/gcc/testsuite/gcc.target/aarch64/pr97701.c
new file mode 100644
index 000..ede3540c48d
--- /dev/null
+++ b/gcc/testsuite/gcc.target/aarch64/pr97701.c
@@ -0,0 +1,17 @@
+/* { dg-do compile } */
+/* { dg-options "-O3" } */
+
+extern char a[][12][18][17][17];
+extern short b[][12][18][17][17];
+extern int c[][2][8][7];
+short *d;
+void e(signed f, int g, char h, char i, char j) {
+  for (int k = 648; k; k += f)
+for (short l; l < j; l += 9)
+  for (long m = f + 6LL; m < (h ? h : i); m += 2)
+for (int n = 0; n < 16; n += 3LL) {
+  for (int o = g; o; o++)
+a[k][l][m][n][o] = b[k][l][m][n][o] = d[k] ? 2 : 0;
+  c[k][l][m][0] = 0;
+}
+}

Re: driver: error for nonexistent linker inputs [PR 98943]

[Joseph Myers]

On Thu, 4 Feb 2021, Nathan Sidwell wrote:

> We used   to check all unknown input files, even when passing them to a
> compiler.  But that caused problems.  However, not erroring out on
> non-existent would-be-linker inputs confuses configure machinery that
> probes the compiler to see if it accepts various inputs.  This
> restores the access check for things that are thought to be linker
> input files, when we're not linking.  (If we are linking, we presume
> the linker will error out on its own accord.)

OK.

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

[Bug middle-end/98465] [11 Regression] Bogus -Wstringop-overread with -std=gnu++20 -O2 and std::string::insert

[jakub at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #27 from Jakub Jelinek  ---
(In reply to Martin Sebor from comment #26)
> I tried the __builtin_object_size patch and while it avoids the warning in
> the reported test case it's not effective in others derived from it, such as:
> 
> #include 
> 
> const char constantString[] = {42, 53};
> 
> void f(std::string& s, int n)
> {
>   if (n < 2) n = 2;
>   s.insert(0, static_cast(constantString), n);
> }

That could be handled by doing:
__builtin_constant_p (__builtin_object_size (__s, 0) < (2 * __len2 - __len1) *
sizeof(_CharT))
&& __builtin_object_size (__s, 0) < (2 * __len2 - __len1) * sizeof(_CharT)
assuming VRP is able to determine the comparison is constant even when one of
the lengths are non-constant.

[Bug target/97701] [10 Regression] aarch64: ICE in extract_constrain_insn since r10-4447-g095f78c6

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #14 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Vladimir Makarov
:

https://gcc.gnu.org/g:2211aab8e3832356d066915dfb1e081ac94de7e9

commit r10-9346-g2211aab8e3832356d066915dfb1e081ac94de7e9
Author: Vladimir N. Makarov 
Date:   Thu Feb 4 15:57:55 2021 -0500

[PR97701] LRA: Don't narrow class only for REG or MEM.  A version modified
for gcc-10.

This is modified version of the patch committed for the trunk.  The
modification for gcc-10 includes lra-constraint.c code and the test.

gcc/ChangeLog:

PR target/97701
* lra-constraints.c (in_class_p): Don't narrow class only for REG
or MEM.

gcc/testsuite/ChangeLog:

PR target/97701
* gcc.target/aarch64/pr97701.c: New.

[Bug c++/96591] [8/9/10/11 Regression] ICE with -flto=auto and -O1: tree code ‘typename_type’ is not supported in LTO streams

[jason at gcc dot gnu.org via Gcc-bugs]

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

Jason Merrill  changed:

   What|Removed |Added

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

Re: Comma Operator - Left to Right Associativity

[David Brown]

On 04/02/2021 21:08, AJ D via Gcc wrote:
> Isn't comma operator suppose to honor left-to-right associativity?
> 
> When I try it on this test case, it exhibits right-to-left associativity.

You are not talking about associativity - you are talking about
evaluation order.  (The two things are often mixed up.)

For the built-in comma operator, you get guaranteed order of evaluation
(or more precisely, guaranteed order of visible side-effects).  But for
a user-defined comma operator, you do not - until C++17, which has
guaranteed evaluation ordering in some circumstances.

See  (it's
easier to read than the C++ standards).

Try your test again with "-std=c++17" or "-std=g++17" - if the order is
still reversed, it's a gcc bug (AFAICS).  But for standards prior to
C++17, the ordering is unspecified for user-defined comma operators.

This is not unlike the difference between the built-in logic operators
&& and ||, which are guaranteed short-circuiting, while user-defined
overloads are not.  And for arithmetic operators, you don't get integer
promotion, automatic conversion to a common type, etc.

Basically, the user-defined operators are just syntactic sugar for a
function call - they don't have the "magic" features of the real operators.

David

[Bug c/98965] assignment to a struct with an atomic member not atomic

[joseph at codesourcery dot com via Gcc-bugs]

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

--- Comment #4 from joseph at codesourcery dot com  ---
The difficulty with making such an assignment atomic is that atomic 
operations for different sizes of atomic access don't interoperate on the 
same memory; if the struct contains an _Atomic int, that's accessed 
atomically via appropriate int-sized atomic operations, while a larger 
structure may use locking for atomic access in libatomic, and if both 
mechanisms are used on the same memory the result doesn't properly follow 
the memory model.

So you'd need to split struct assignment up into assignment of members to 
access a member atomically.  But that couldn't work at all when you have a 
union with atomic members, because in the union case the compiler can't 
know which is the currently active member that would determine the size of 
the atomic access.

[Bug middle-end/98465] [11 Regression] Bogus -Wstringop-overread with -std=gnu++20 -O2 and std::string::insert

[msebor at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #26 from Martin Sebor  ---
I tried the __builtin_object_size patch and while it avoids the warning in the
reported test case it's not effective in others derived from it, such as:

#include 

const char constantString[] = {42, 53};

void f(std::string& s, int n)
{
  if (n < 2) n = 2;
  s.insert(0, static_cast(constantString), n);
}

Re: [PATCH] c++: Private parent access check for using decls [PR19377]

[Jason Merrill via Gcc-patches]

On 2/4/21 12:46 PM, Anthony Sharp wrote:

Yes, thanks; it would take a lot to make me request less comments.


Awesome.


The second lines of arguments are indented one space too far in both these 
calls.


Oops! I will fix that.


Well, I guess it could be using a declaration of the same name from another 
base.


  Yes I had been worrying about that.


But in that case you could end up with an overload set
containing both the decl we're complaining about and another of the same
name from another base, in which case the lookup result would include
both, and so the comparison would fail and we would fall through to the
private base assumption.


I think technically yes ... but also no since such code would not
compile anyways, plus oddly it seems to work anyway. For instance
(assuming I'm understanding correctly), if you do this (with the patch
applied):

class A
{
   protected:
   int i;
};

class A2
{
   protected:
   int i;
};

class B:public A, public A2
{
   private:
   using A::i, A2::i;
};

class C:public B
{
   void f()
   {
 A::i = 0;
   }
};

You get:

error: redeclaration of ‘using A::i’
using A::i;

note: previous declaration ‘using A2::i’
 using A2::i;

error: redeclaration of ‘using A2::i’
using A::i, A2::i;

previous declaration ‘using A::i’
using A::i, A2::i;

In member function ‘void C::f()’:
error: ‘int A::i’ is private within this context
A::i = 0;

note: declared private here
using A::i, A2::i;

Which seems to work (well ... more like fail to compile ... as
expected). Maybe you're imagining a different situation to me?


I'm imagining member functions, i.e. A::f() and A2::f(int).


You can even use void f() { i = 0; } and void f() { A2::i = 0; } and
you seem to get the same results either which way (although, to be
fair, if you do A2::i = 0, it suddenly doesn't complain about it being
private anymore [no idea why], it just complains about the
redeclaration , and once you fix the redeclaration, it THEN complains
about being private, so it's got a bit of a quirk - don't think that's
related to the patch though).


That sounds fine, one error can hide another.


But checking the name is a simple way to skip irrelevant usings.


That does sound like a better way of doing it. Would I just do
cp_tree_equal (DECL_NAME (blah1), DECL_NAME (blah2)) [assuming
DECL_NAME returns a tree], or perhaps DECL_NAME (blah1) == DECL_NAME
(blah2)?


== is enough, identifiers are unique.


Maybe also check that the using is TREE_PRIVATE?


Would that be necessary? Maybe if you wanted to sanity-check it I
suppose. We know for sure that PARENT_BINFO has private access to
DECL. If we find a using statement introducing DECL in PARENT_BINFO,
then surely the using statement must (by definition) have been
private? If it were not private, then the child class would have been
able to access it, and enforce_access wouldn't have thrown an error.
It doesn't seem to be the case that DECL could be private for any
other reason other than the using decl being private.


Agreed, but the using-declaration might not be introducing DECL.  This 
would be another way to skip irrelevant usings.



Let me know your thoughts and I will update the patch. Thanks for your help.

Anthony


On Thu, 4 Feb 2021 at 16:33, Jason Merrill  wrote:


On 2/4/21 11:24 AM, Jason Merrill wrote:

On 2/4/21 10:02 AM, Anthony Sharp via Gcc-patches wrote:

Hello,

New bugfix for PR19377
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19377). This is
basically an extension of what I did before for PR17314 except it also
fixes this other bug.

I hope I didn't over-comment in the code ... better to say too much
than too little! It's a niche bug so I thought it could do with a
little explanation.


Yes, thanks; it would take a lot to make me request less comments.


+  if (TREE_CODE (parent_field) == USING_DECL)
+   {
+ if (cp_tree_equal (decl,
+lookup_member (parent_binfo,
+   DECL_NAME (parent_field),
+   /*protect=*/0,
+   /*want_type=*/false,
+   tf_warning_or_error)))


Isn't it sufficient to check that the names match?


Well, I guess it could be using a declaration of the same name from
another base.  But in that case you could end up with an overload set
containing both the decl we're complaining about and another of the same
name from another base, in which case the lookup result would include
both, and so the comparison would fail and we would fall through to the
private base assumption.

But checking the name is a simple way to skip irrelevant usings.
Maybe also check that the using is TREE_PRIVATE?


   tree parent_binfo = get_parent_with_private_access (decl,
-
basetype_path);
+
basetype_path);

...

+ diag_location = get_class_access_diagnostic_decl
(parent_binfo,
+
diag_decl);


The second lines 

[Bug c/98969] [11 Regression] ICE: Segmentation fault (in print_mem_ref)

[jakub at gcc dot gnu.org via Gcc-bugs]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
This programming style is always wrong, please stop doing that.

Re: [pushed] c++: Empty args for variadic concept [PR98717]

[Marek Polacek via Gcc-patches]

On Thu, Feb 04, 2021 at 03:43:33PM -0500, Jason Merrill via Gcc-patches wrote:
> Nice when fixing a bug is as easy as removing incorrect checks.
> 
> gcc/cp/ChangeLog:
> 
>   PR c++/98717
>   * constraint.cc (build_concept_check_arguments): Remove assert.
>   (build_concept_check): Allow empty args.
> 
> gcc/testsuite/ChangeLog:
> 
>   PR c++/98717
>   * g++.dg/cpp2a/concepts-variadic3.C: New test.
> ---
>  gcc/cp/constraint.cc| 8 
>  gcc/testsuite/g++.dg/cpp2a/concepts-variadic3.C | 7 +++
>  2 files changed, 7 insertions(+), 8 deletions(-)
>  create mode 100644 gcc/testsuite/g++.dg/cpp2a/concepts-variadic3.C
> 
> diff --git a/gcc/cp/constraint.cc b/gcc/cp/constraint.cc
> index 9049d087859..31e0fb5079a 100644
> --- a/gcc/cp/constraint.cc
> +++ b/gcc/cp/constraint.cc
> @@ -1345,7 +1345,6 @@ build_concept_check_arguments (tree arg, tree rest)
>  }
>else
>  {
> -  gcc_assert (rest != NULL_TREE);
>args = rest;
>  }

Could even remove the braces now!  :)

Marek

[Bug c/98969] [11 Regression] ICE: Segmentation fault (in print_mem_ref)

[msebor at gcc dot gnu.org via Gcc-bugs]

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

Martin Sebor  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
   Target Milestone|--- |11.0
 Status|NEW |ASSIGNED
   Keywords|ice-on-invalid-code |ice-on-valid-code

--- Comment #2 from Martin Sebor  ---
The following avoids the ICE:

diff --git a/gcc/c-family/c-pretty-print.c b/gcc/c-family/c-pretty-print.c
index 2095d4badf7..da4a8b5defd 100644
--- a/gcc/c-family/c-pretty-print.c
+++ b/gcc/c-family/c-pretty-print.c
@@ -1989,7 +1989,9 @@ print_mem_ref (c_pretty_printer *pp, tree e)
 }

   tree access_type = TREE_TYPE (e);
-  tree arg_type = TREE_TYPE (TREE_TYPE (arg));
+  tree arg_type = TREE_TYPE (arg);
+  if (POINTER_TYPE_P (arg))
+arg_type = TREE_TYPE (arg_type);
   if (tree access_size = TYPE_SIZE_UNIT (access_type))
 if (byte_off != 0
&& TREE_CODE (access_size) == INTEGER_CST

and results in:

pr98969.c: In function ‘_round_2_cb’:
pr98969.c:14:14: warning: argument 1 null where non-null expected [-Wnonnull]
   14 |   bb->expr = strdup ((const char *) 0);
  |  ^~
pr98969.c:7:1: note: in a call to function ‘strdup’ declared ‘nonnull’
7 | strdup (const char *);
  | ^~
pr98969.c:15:1: warning: leak of ‘*(struct TYPE_14__ *)_round_2_cb_n_0.expr’
[CWE-401] [-Wanalyzer-malloc-leak]
   15 | }
  | ^
  ‘_round_2_cb’: events 1-2
|
|   14 |   bb->expr = strdup ((const char *) 0);
|  |  ^
|  |  |
|  |  (1) allocated here
|   15 | }
|  | ~ 
|  | |
|  | (2) ‘*(struct TYPE_14__ *)_round_2_cb_n_0.expr’ leaks here; was
allocated at (1)
|


The test case is undefined but syntactically valid thus ice-on-valid-code.

Re: [PATCH] c++: Fix ICE with structured binding initialized to incomplete array [PR97878]

[Jason Merrill via Gcc-patches]

On 2/4/21 12:47 PM, Jakub Jelinek wrote:

On Thu, Feb 04, 2021 at 11:03:10AM -0500, Jason Merrill wrote:

--- gcc/cp/decl.c.jj2021-01-28 16:13:04.0 +0100
+++ gcc/cp/decl.c   2021-02-03 15:57:16.980557836 +0100
@@ -6837,7 +6837,8 @@ check_initializer (tree decl, tree init,
   /* We will have already complained.  */
   return NULL_TREE;
-  if (TREE_CODE (type) == ARRAY_TYPE)
+  if (TREE_CODE (type) == ARRAY_TYPE
+  && (!DECL_DECOMPOSITION_P (decl) || DECL_DECOMP_BASE (decl)))


This needs a comment.  Or handle this inside check_array_initializer, where
we could give a more helpful diagnostic?


So like this?

2021-02-04  Jakub Jelinek  

PR c++/97878
* decl.c (check_array_initializer): For structured bindings, require
the array type to be complete.

* g++.dg/cpp1z/decomp54.C: New test.

--- gcc/cp/decl.c.jj2021-02-03 17:13:58.567872007 +0100
+++ gcc/cp/decl.c   2021-02-04 18:42:35.347374198 +0100
@@ -6768,6 +6768,19 @@ check_array_initializer (tree decl, tree
  {
tree element_type = TREE_TYPE (type);
  
+  /* Structured binding when initialized with an array type needs

+ to have complete type.  */
+  if (decl
+  && DECL_DECOMPOSITION_P (decl)
+  && !DECL_DECOMP_BASE (decl)
+  && !COMPLETE_TYPE_P (type))
+{
+  error_at (DECL_SOURCE_LOCATION (decl),
+   "structured binding has incomplete type");


Let's print the type.  OK with that change.


+  TREE_TYPE (decl) = error_mark_node;
+  return true;
+}
+
/* The array type itself need not be complete, because the
   initializer may tell us how many elements are in the array.
   But, the elements of the array must be complete.  */
--- gcc/testsuite/g++.dg/cpp1z/decomp54.C.jj2021-02-04 18:33:34.829393825 
+0100
+++ gcc/testsuite/g++.dg/cpp1z/decomp54.C   2021-02-04 18:33:34.829393825 
+0100
@@ -0,0 +1,17 @@
+// PR c++/97878
+// { dg-do compile { target c++11 } }
+// { dg-options "" }
+
+extern int a[];
+auto [b] { a };// { dg-error "has incomplete type" }
+   // { dg-warning "only available with" "" { target c++14_down } 
.-1 }
+auto [c] = a;  // { dg-error "has incomplete type" }
+   // { dg-warning "only available with" "" { target c++14_down } 
.-1 }
+extern int d[0];
+auto [e] { d };// { dg-error "too many initializers for" }
+   // { dg-error "1 name provided for structured binding" "" { 
target *-*-* } .-1 }
+   // { dg-message "decomposes into 0 elements" "" { target *-*-* 
} .-2 }
+   // { dg-warning "only available with" "" { target c++14_down } 
.-3 }
+auto [f] = d;  // { dg-error "1 name provided for structured binding" }
+   // { dg-message "decomposes into 0 elements" "" { target *-*-* 
} .-1 }
+   // { dg-warning "only available with" "" { target c++14_down } 
.-2 }


Jakub

Re: [PATCH] c++: Fix bogus -Wvolatile warning in C++20 [PR98947]

[Jason Merrill via Gcc-patches]

On 2/4/21 1:11 PM, Marek Polacek wrote:

On Thu, Feb 04, 2021 at 10:59:21AM -0500, Jason Merrill wrote:

On 2/3/21 7:03 PM, Marek Polacek wrote:

Since most of volatile is deprecated in C++20, we are required to warn
for compound assignments to volatile variables and so on.  But here we
have

volatile int x, y, z;
(b ? x : y) = 1;

and we shouldn't warn, because simple assignments like x = 24; should
not provoke the warning when they are a discarded-value expression.

We warn here because when ?: is used as an lvalue, we transform it in
cp_build_modify_expr/COND_EXPR from (a ? b : c) = rhs to

(a ? (b = rhs) : (c = rhs))

and build_conditional_expr then calls mark_lvalue_use for the new
artificial assignments


Hmm, that seems wrong; the ?: expression itself does not use lvalue operands
any more than ',' does.  I notice that removing those mark_lvalue_use calls
doesn't regress Wunused-var-10.c, which was added with them in r160289.


The mark_lvalue_use calls didn't strike me as wrong because [expr.cond]/7
says that lvalue-to-rvalue conversion is performed on the second and third
operands.


Only after we've decided (in /6) that the result is a prvalue.


With those mark_lvalue_use calls removed, we'd not issue the
warning for

   (b ? (x = 2) : y) = 1;
   (b ? x : (y = 5)) = 1;


Why wouldn't we?  The assignment should call mark_lvalue_use for the 
LHS, which recursively applies it to the arms of the ?:.


Jason

[Bug c++/98717] [10/11 Regression] [c++20] variadic concept can't take empty pack

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Jason Merrill :

https://gcc.gnu.org/g:4e7c24d97dd65083a770252ce942f43d408fe11d

commit r11-7106-g4e7c24d97dd65083a770252ce942f43d408fe11d
Author: Jason Merrill 
Date:   Thu Feb 4 11:46:45 2021 -0500

c++: Empty args for variadic concept [PR98717]

Nice when fixing a bug is as easy as removing incorrect checks.

gcc/cp/ChangeLog:

PR c++/98717
* constraint.cc (build_concept_check_arguments): Remove assert.
(build_concept_check): Allow empty args.

gcc/testsuite/ChangeLog:

PR c++/98717
* g++.dg/cpp2a/concepts-variadic3.C: New test.

[pushed] c++: Empty args for variadic concept [PR98717]

[Jason Merrill via Gcc-patches]

Nice when fixing a bug is as easy as removing incorrect checks.

gcc/cp/ChangeLog:

PR c++/98717
* constraint.cc (build_concept_check_arguments): Remove assert.
(build_concept_check): Allow empty args.

gcc/testsuite/ChangeLog:

PR c++/98717
* g++.dg/cpp2a/concepts-variadic3.C: New test.
---
 gcc/cp/constraint.cc| 8 
 gcc/testsuite/g++.dg/cpp2a/concepts-variadic3.C | 7 +++
 2 files changed, 7 insertions(+), 8 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp2a/concepts-variadic3.C

diff --git a/gcc/cp/constraint.cc b/gcc/cp/constraint.cc
index 9049d087859..31e0fb5079a 100644
--- a/gcc/cp/constraint.cc
+++ b/gcc/cp/constraint.cc
@@ -1345,7 +1345,6 @@ build_concept_check_arguments (tree arg, tree rest)
 }
   else
 {
-  gcc_assert (rest != NULL_TREE);
   args = rest;
 }
   return args;
@@ -1444,13 +1443,6 @@ build_concept_check (tree target, tree args, 
tsubst_flags_t complain)
 tree
 build_concept_check (tree decl, tree arg, tree rest, tsubst_flags_t complain)
 {
-  if (arg == NULL_TREE && rest == NULL_TREE)
-{
-  tree id = build_nt (TEMPLATE_ID_EXPR, decl, rest);
-  error ("invalid use concept %qE", id);
-  return error_mark_node;
-}
-
   tree args = build_concept_check_arguments (arg, rest);
 
   if (standard_concept_p (decl))
diff --git a/gcc/testsuite/g++.dg/cpp2a/concepts-variadic3.C 
b/gcc/testsuite/g++.dg/cpp2a/concepts-variadic3.C
new file mode 100644
index 000..6fa7113e734
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp2a/concepts-variadic3.C
@@ -0,0 +1,7 @@
+// PR c++/98717
+// { dg-do compile { target c++20 } }
+
+template
+concept True = true;
+
+static_assert(True<>);

base-commit: e6cc142ad99ab8d28581f4ce61056c9cce74dba3
-- 
2.27.0

[PATCH] rs6000: Fix MMA API - Add support for compatibility built-ins

[Peter Bergner via Gcc-patches]

The LLVM and GCC teams agreed to rename the __builtin_mma_assemble_pair and
__builtin_mma_disassemble_pair built-ins to __builtin_vsx_assemble_pair and
__builtin_vsx_disassemble_pair respectively.  It's too late to remove the
old names, so this patch adds support for creating compatibility built-ins
(ie, multiple built-in functions generate the same code) and then creates
compatibility built-ins using the new names.

This passed bootstrap and regtesting on powerpc64le-linux with no regressions.
Ok for mainline?

This will need backporting to GCC 10.  Ok there too once it's baked on
trunk for a little while?

Peter


gcc/
* gcc/config/rs6000/rs6000-builtin.def (BU_COMPAT): Add support macro
for defining compatibility built-ins.
(vsx_assemble_pair): Add compatibility built-in.
* gcc/config/rs6000/rs6000-call.c (struct builtin_compatibility): New.
(bdesc_compat): New.
(RS6000_BUILTIN_COMPAT): Define.
(rs6000_init_builtins): Register compatibility built-ins.
* gcc/testsuite/gcc.target/powerpc/mma-builtin-4.c: Add tests for
__builtin_vsx_assemble_pair and __builtin_vsx_disassemble_pair.
Update expected instruction counts.


diff --git a/gcc/config/rs6000/rs6000-builtin.def 
b/gcc/config/rs6000/rs6000-builtin.def
index 058a32abf4c..268f5d5b52b 100644
--- a/gcc/config/rs6000/rs6000-builtin.def
+++ b/gcc/config/rs6000/rs6000-builtin.def
@@ -43,6 +43,10 @@
ATTRbuiltin attribute information.
ICODE   Insn code of the function that implements the builtin.  */
 
+#ifndef RS6000_BUILTIN_COMPAT
+  #undef BU_COMPAT
+  #define BU_COMPAT(ENUM, COMPAT_NAME)
+
 #ifndef RS6000_BUILTIN_0
   #error "RS6000_BUILTIN_0 is not defined."
 #endif
@@ -87,6 +91,36 @@
   #error "RS6000_BUILTIN_X is not defined."
 #endif
 
+#else
+  /* Compatibility builtins.  These builtins are simply mapped into
+ their compatible builtin function identified by ENUM.  */
+  #undef BU_COMPAT
+  #define BU_COMPAT(ENUM, COMPAT_NAME) { ENUM, "__builtin_" COMPAT_NAME },
+
+  #undef RS6000_BUILTIN_0
+  #undef RS6000_BUILTIN_1
+  #undef RS6000_BUILTIN_2
+  #undef RS6000_BUILTIN_3
+  #undef RS6000_BUILTIN_4
+  #undef RS6000_BUILTIN_A
+  #undef RS6000_BUILTIN_D
+  #undef RS6000_BUILTIN_H
+  #undef RS6000_BUILTIN_M
+  #undef RS6000_BUILTIN_P
+  #undef RS6000_BUILTIN_X
+  #define RS6000_BUILTIN_0(ENUM, NAME, MASK, ATTR, ICODE)
+  #define RS6000_BUILTIN_1(ENUM, NAME, MASK, ATTR, ICODE)
+  #define RS6000_BUILTIN_2(ENUM, NAME, MASK, ATTR, ICODE)
+  #define RS6000_BUILTIN_3(ENUM, NAME, MASK, ATTR, ICODE)
+  #define RS6000_BUILTIN_4(ENUM, NAME, MASK, ATTR, ICODE)
+  #define RS6000_BUILTIN_A(ENUM, NAME, MASK, ATTR, ICODE)
+  #define RS6000_BUILTIN_D(ENUM, NAME, MASK, ATTR, ICODE)
+  #define RS6000_BUILTIN_H(ENUM, NAME, MASK, ATTR, ICODE)
+  #define RS6000_BUILTIN_M(ENUM, NAME, MASK, ATTR, ICODE)
+  #define RS6000_BUILTIN_P(ENUM, NAME, MASK, ATTR, ICODE)
+  #define RS6000_BUILTIN_X(ENUM, NAME, MASK, ATTR, ICODE)
+#endif
+
 #ifndef BU_AV_1
 /* Define convenience macros using token pasting to allow fitting everything in
one line.  */
@@ -3137,8 +3171,10 @@ BU_MMA_1 (XXSETACCZ, "xxsetaccz",MISC, 
mma_xxsetaccz)
 
 BU_MMA_2 (DISASSEMBLE_ACC, "disassemble_acc",  QUAD, mma_disassemble_acc)
 BU_MMA_2 (DISASSEMBLE_PAIR,"disassemble_pair", PAIR, mma_disassemble_pair)
+BU_COMPAT (MMA_BUILTIN_DISASSEMBLE_PAIR, "vsx_disassemble_pair")
 
 BU_MMA_3 (ASSEMBLE_PAIR,"assemble_pair",   MISC, mma_assemble_pair)
+BU_COMPAT (MMA_BUILTIN_ASSEMBLE_PAIR, "vsx_assemble_pair")
 BU_MMA_3 (XVBF16GER2,  "xvbf16ger2",   MISC, mma_xvbf16ger2)
 BU_MMA_3 (XVF16GER2,   "xvf16ger2",MISC, mma_xvf16ger2)
 BU_MMA_3 (XVF32GER,"xvf32ger", MISC, mma_xvf32ger)
diff --git a/gcc/config/rs6000/rs6000-call.c b/gcc/config/rs6000/rs6000-call.c
index ae0c761f0a4..240533dec55 100644
--- a/gcc/config/rs6000/rs6000-call.c
+++ b/gcc/config/rs6000/rs6000-call.c
@@ -89,6 +89,12 @@
 #define TARGET_NO_PROTOTYPE 0
 #endif
 
+struct builtin_compatibility
+{
+  const enum rs6000_builtins code;
+  const char *const name;
+};
+
 struct builtin_description
 {
   const HOST_WIDE_INT mask;
@@ -8839,6 +8845,13 @@ def_builtin (const char *name, tree type, enum 
rs6000_builtins code)
 (int)code, name, attr_string);
 }
 
+static const struct builtin_compatibility bdesc_compat[] =
+{
+#define RS6000_BUILTIN_COMPAT
+#include "rs6000-builtin.def"
+};
+#undef RS6000_BUILTIN_COMPAT
+
 /* Simple ternary operations: VECd = foo (VECa, VECb, VECc).  */
 
 #undef RS6000_BUILTIN_0
@@ -13445,6 +13458,18 @@ rs6000_init_builtins (void)
 #ifdef SUBTARGET_INIT_BUILTINS
   SUBTARGET_INIT_BUILTINS;
 #endif
+
+  /* Register the compatibility builtins after all of the normal
+ builtins have been defined.  */
+  const struct builtin_compatibility *d = bdesc_compat;
+  unsigned i;
+  for (i = 0; i < ARRAY_SIZE (bdesc_compat); i++, d++)
+{
+  tree decl = 

[Bug c/98969] [11 Regression] ICE: Segmentation fault (in print_mem_ref)

[msebor at gcc dot gnu.org via Gcc-bugs]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
 CC||msebor at gcc dot gnu.org
   Last reconfirmed||2021-02-04

--- Comment #1 from Martin Sebor  ---
Confirmed.  The ICE is in accessing arg_type in the snippet below when it's
null.

  tree arg_type = TREE_TYPE (TREE_TYPE (arg));
  ...
  /* True to include a cast to the accessed type.  */
  const bool access_cast
= ((op && op != TREE_OPERAND (arg, 0))
   || VOID_TYPE_P (arg_type)
   || !lang_hooks.types_compatible_p (access_type, arg_type));
  const bool has_off = byte_off != 0 || (op && op != TREE_OPERAND (arg, 0));

arg is set to the integer but the arg_type initalizer assumes it's a pointer:

 
unit-size 
align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7fffea810738 precision:64 min  max 
pointer_to_this >
visited var 
def_stmt GIMPLE_NOP
version:2>

[Bug c/97932] [8/9/10 Regression] Preprocessor, generated error dumps most of the source file, not just one line by r6-5941

[dmalcolm at gcc dot gnu.org via Gcc-bugs]

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

David Malcolm  changed:

   What|Removed |Added

Summary|[8/9/10/11 Regression]  |[8/9/10 Regression]
   |Preprocessor, generated |Preprocessor, generated
   |error dumps most of the |error dumps most of the
   |source file, not just one   |source file, not just one
   |line by r6-5941 |line by r6-5941

--- Comment #8 from David Malcolm  ---
Should be fixed on trunk by above commit.

[PATCH] testsuite: Fix up pr25376.c on powerpc64-linux and array-quals-1.c on powerpc-linux [PR98325]

[Jakub Jelinek via Gcc-patches]

Hi!

On Mon, Nov 16, 2020 at 06:14:52PM -0500, David Edelsohn via Gcc-patches wrote:
> Jenkins does function on AIX.  I will take an action item to create
> another LPAR on the AIX systems at OSUOSL for Jenkins and coordinate
> with you to connect it to the terrific Jenkins infrastructure for GCC
> that you have deployed.

The following patch fixes the pr25376.c testcase on powerpc64-linux
and array-quals-1.c on powerpc-linux.
Previously it failed like:
FAIL: gcc.dg/array-quals-1.c scan-assembler-symbol-section symbol ^_?a1\$ 
(found a1) has section ^.(const|rodata|srodata)|[RO] (found .sdata)
FAIL: gcc.dg/array-quals-1.c scan-assembler-symbol-section symbol ^_?b1\$ 
(found b1) has section ^.(const|rodata|srodata)|[RO] (found .sdata)
FAIL: gcc.dg/array-quals-1.c scan-assembler-symbol-section symbol ^_?c1\$ 
(found c1) has section ^.(const|rodata|srodata)|[RO] (found .sdata)
FAIL: gcc.dg/array-quals-1.c scan-assembler-symbol-section symbol ^_?d1\$ 
(found d1) has section ^.(const|rodata|srodata)|[RO] (found .sdata)
FAIL: gcc.dg/array-quals-1.c scan-assembler-symbol-section symbol ^_?p\$ (found 
p) has section ^.(const|rodata|srodata)|[RW] (found .sdata)
FAIL: gcc.dg/array-quals-1.c scan-assembler-symbol-section symbol ^_?p1\$ 
(found p1) has section ^.(const|rodata|srodata)|[RW] (found .sdata)
FAIL: gcc.dg/array-quals-1.c scan-assembler-symbol-section symbol ^_?q\$ (found 
q) has section ^.(const|rodata|srodata)|[RW] (found .sdata)
FAIL: gcc.dg/array-quals-1.c scan-assembler-symbol-section symbol ^_?q1\$ 
(found q1) has section ^.(const|rodata|srodata)|[RW] (found .sdata)
FAIL: gcc.dg/array-quals-1.c scan-assembler-symbol-section symbol ^_?r\$ (found 
r) has section ^.(const|rodata|srodata)|[RW] (found .sdata)
FAIL: gcc.dg/array-quals-1.c scan-assembler-symbol-section symbol ^_?r1\$ 
(found r1) has section ^.(const|rodata|srodata)|[RW] (found .sdata)
FAIL: gcc.dg/array-quals-1.c scan-assembler-symbol-section symbol ^_?s\$ (found 
s) has section ^.(const|rodata|srodata)|[RW] (found .sdata)
FAIL: gcc.dg/array-quals-1.c scan-assembler-symbol-section symbol ^_?s1\$ 
(found s1) has section ^.(const|rodata|srodata)|[RW] (found .sdata)
FAIL: gcc.dg/array-quals-1.c scan-assembler-symbol-section symbol ^_?t\$ (found 
t) has section ^.(const|rodata|srodata)|[RW] (found .sdata)
FAIL: gcc.dg/array-quals-1.c scan-assembler-symbol-section symbol ^_?t1\$ 
(found t1) has section ^.(const|rodata|srodata)|[RW] (found .sdata)
FAIL: gcc.dg/pr25376.c scan-assembler-symbol-section symbol simple\$ (found 
.L.simple) has section 
^.?my_named_section|simple[DS]|^".opd" (found .opd)
FAIL: gcc.dg/pr25376.c scan-assembler-symbol-section symbol simple\$ (found 
simple) has section 
^.?my_named_section|simple[DS]|^".opd" (found .opd)

The problem with pr25376.c testcase are the ELFv1 function descriptors,
.sectionmy_named_section,"ax",@progbits
.align 2
.globl simple
.section".opd","aw"
.align 3
simple:
.quad   .L.simple,.TOC.@tocbase,0
.previous
.type   simple, @function
.L.simple:

so the simple symbol is found in the .opd section rather than in the
my_named_section the test attempts to verify for that symbol.
This patch deals it with two changes, the last two hunks in scanasm.exp
teach it about the behavior of .previous directive and the first hunk
for powerpc if symbol is in .opd section will try section in which the
.L.symbol label is instead.

The array-quals-1.c test fails because on powerpc-linux the symbols
are emitted into .sdata section rather than one of the expected ones.

Tested on powerpc64-linux (-m32/-m64) and x86_64-linux (-m32/-m64), ok for
trunk?

Whether this fixes also AIX, I have no idea.

2021-02-04  Jakub Jelinek  

PR testsuite/98325
* lib/scanasm.exp (dg-scan-symbol-section): For powerpc*-*-* targets if
$section is .opd, look at .L.$symbol_name's section.
(parse_section_section_of_symbols): Handle .previous directive.
* gcc.dg/array-quals-1.c: Allow .sdata section.

--- a/gcc/testsuite/lib/scanasm.exp
+++ b/gcc/testsuite/lib/scanasm.exp
@@ -275,6 +275,9 @@ proc dg-scan-symbol-section { name testcase output_file 
orig_args } {
 foreach symbol_name [lsort [array names section_by_symbol]] {
 if { [regexp -- $symbol_pattern $symbol_name] } {
 set section $section_by_symbol($symbol_name)
+   if { [istarget powerpc*-*-*] && $section == ".opd" } {
+   set section $section_by_symbol(.L.$symbol_name)
+   }
 set description "$testcase $name symbol $printable_symbol_pattern 
(found $symbol_name) has section $printable_expected_section_pattern"
 if { $section == "" } {
 fail "$description (no section 

[committed] diagnostics: fix excessive range-printing involving macros [PR97932]

[David Malcolm via Gcc-patches]

PR c/97932 describes a bug in which diagnostic_show_locus prints most
of a source file.

The issue is that it prints a range in which the start and end locations
are part of the same macro map, but the start location is for a token in
the definition of the macro, whereas the end location is for a token in
an argument of the macro.

This patch extends compatible_locations_p to require that range-printing
of macro maps requires the location to either be both for the definition
of the macro, or both for the arguments of the macro (not one of each),
fixing the issue.

Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r11-7105-g65c1cb358999e9d1618834af341b31837ede839e.

gcc/ChangeLog:
PR c/97932
* diagnostic-show-locus.c (compatible_locations_p): Require
locations in the same macro map to be either both from the
macro definition, or both from the macro arguments.

gcc/testsuite/ChangeLog:
PR c/97932
* gcc.dg/pr97932.c: New test.
---
 gcc/diagnostic-show-locus.c|   9 +++
 gcc/testsuite/gcc.dg/pr97932.c | 125 +
 2 files changed, 134 insertions(+)
 create mode 100644 gcc/testsuite/gcc.dg/pr97932.c

diff --git a/gcc/diagnostic-show-locus.c b/gcc/diagnostic-show-locus.c
index 92a07c2f60a..458830aa2a9 100644
--- a/gcc/diagnostic-show-locus.c
+++ b/gcc/diagnostic-show-locus.c
@@ -905,6 +905,15 @@ compatible_locations_p (location_t loc_a, location_t loc_b)
   /* Are both within the same macro expansion?  */
   if (linemap_macro_expansion_map_p (map_a))
{
+ /* If so, then they're only compatible if either both are
+from the macro definition, or both from the macro arguments.  */
+ bool loc_a_from_defn
+   = linemap_location_from_macro_definition_p (line_table, loc_a);
+ bool loc_b_from_defn
+   = linemap_location_from_macro_definition_p (line_table, loc_b);
+ if (loc_a_from_defn != loc_b_from_defn)
+   return false;
+
  /* Expand each location towards the spelling location, and
 recurse.  */
  const line_map_macro *macro_map = linemap_check_macro (map_a);
diff --git a/gcc/testsuite/gcc.dg/pr97932.c b/gcc/testsuite/gcc.dg/pr97932.c
new file mode 100644
index 000..4a0b3041375
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr97932.c
@@ -0,0 +1,125 @@
+/* Verify that we don't emit ranges that span both
+   a macro definition location and a macro expansion location.  */
+
+/* { dg-options "-fdiagnostics-show-caret" } */
+
+/* Various cases involving the ranges of the LHS and RHS operands to "-".  */
+
+/* Case 1
+   start token is in macro definition ("&"),
+   end token is in macro invocation ("a" and "b").  */   
+
+#define M1(A, B)  -  /* { dg-error "invalid operands" } */
+
+/* Intervening
+   material
+   that
+   ought
+   not
+   to
+   be
+   printed.  */
+
+int test_1 (float a, int b)
+{
+  return M1(a, b); /* { dg-message "in expansion of macro 'M1'" } */
+}
+
+/* { dg-begin-multiline-output "" }
+ #define M1(A, B)  - 
+ ^
+   { dg-end-multiline-output "" } */
+/* { dg-begin-multiline-output "" }
+   return M1(a, b);
+  ^~
+   { dg-end-multiline-output "" } */
+
+/* Case 2:
+   start and end tokens are both in macro invocation ("&", and "a"/"b").  */   
+
+#define M2(A, B) A - B /* { dg-error "invalid operands" } */
+
+/* Intervening
+   material
+   that
+   ought
+   not
+   to
+   be
+   printed.  */
+
+int test_2 (float a, int b)
+{
+  return M2(, ); /* { dg-message "in expansion of macro 'M2'" } */
+}
+
+/* { dg-begin-multiline-output "" }
+ #define M2(A, B) A - B
+^
+   { dg-end-multiline-output "" } */
+/* { dg-begin-multiline-output "" }
+   return M2(, );
+  ^~
+   { dg-end-multiline-output "" } */
+
+/* Case 3:
+   start token is in macro invocation ("&"),
+   end token is in macro definition ("a").  */   
+
+#define M3(OP) OP a - OP b /* { dg-error "invalid operands" } */
+
+/* Intervening
+   material
+   that
+   ought
+   not
+   to
+   be
+   printed.  */
+
+int test_3 (float a, int b)
+{
+  return M3(&); /* { dg-message "in expansion of macro 'M3'" } */
+}
+
+/* { dg-begin-multiline-output "" }
+ #define M3(OP) OP a - OP b
+ ^
+   { dg-end-multiline-output "" } */
+/* { dg-begin-multiline-output "" }
+   return M3(&);
+  ^~
+   { dg-end-multiline-output "" } */
+
+
+/* Case 4:
+   start and end tokens are both in macro definition ("").  */   
+
+#define M4  -  /* { dg-error "invalid operands" } */
+
+/* Intervening
+   material
+   that
+   ought
+   not
+   to
+   be
+   printed.  */
+
+int test_4 (float a, int b)
+{
+  return M4; /* { dg-message "in expansion of macro 'M4'" } */
+}
+
+/* { dg-begin-multiline-output "" }
+ #define M4  - 
+~~ ^ ~~
+||
+|int *
+float *
+   { dg-end-multiline-output "" } */
+/* { 

[Bug c/97932] [8/9/10/11 Regression] Preprocessor, generated error dumps most of the source file, not just one line by r6-5941

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #7 from CVS Commits  ---
The master branch has been updated by David Malcolm :

https://gcc.gnu.org/g:65c1cb358999e9d1618834af341b31837ede839e

commit r11-7105-g65c1cb358999e9d1618834af341b31837ede839e
Author: David Malcolm 
Date:   Thu Feb 4 15:20:59 2021 -0500

diagnostics: fix excessive range-printing involving macros [PR97932]

PR c/97932 describes a bug in which diagnostic_show_locus prints most
of a source file.

The issue is that it prints a range in which the start and end locations
are part of the same macro map, but the start location is for a token in
the definition of the macro, whereas the end location is for a token in
an argument of the macro.

This patch extends compatible_locations_p to require that range-printing
of macro maps requires the location to either be both for the definition
of the macro, or both for the arguments of the macro (not one of each),
fixing the issue.

gcc/ChangeLog:
PR c/97932
* diagnostic-show-locus.c (compatible_locations_p): Require
locations in the same macro map to be either both from the
macro definition, or both from the macro arguments.

gcc/testsuite/ChangeLog:
PR c/97932
* gcc.dg/pr97932.c: New test.

Re: [PATCH] Add unordered containers heterogeneous lookup

[François Dumont via Gcc-patches]

    Considering that most of the code is already new code it doesn't 
look like a major tradeoff duplicate some more code.


    So here is a new proposal with only new code. However I left the 
new few XXX_tr methods accessible even in C++11 because I'll use them to 
propose a fix for PR 98066 when back in stage 1.


    libstdc++: Add unordered containers heterogeneous lookup

    Add unordered containers heterogeneous lookup member functions 
find, count, contains and
    equal_range in C++20. Those members are considered for overload 
resolution only if hash and
    equal functors used to instantiate the container have a nested 
is_transparent type.


    libstdc++-v3/ChangeLog:

    * include/bits/stl_tree.h
    (__has_is_transparent, __has_is_transparent_t): Move...
    * include/bits/stl_function.h: ...here.
    * include/bits/hashtable_policy.h 
(_Hash_code_base<>::_M_hash_code_tr): New..

    (_Hashtable_base<>::_M_equals_tr): New.
    * include/bits/hashtable.h (_Hashtable<>::_M_find_tr, 
_Hashtable<>::_M_count_tr,
    _Hashtable<>::_M_equal_range_tr): New member function 
templates to perform

    heterogeneous lookup.
    (_Hashtable<>::_M_find_before_node_tr): New.
    (_Hashtable<>::_M_find_node_tr): New.
    * include/bits/unordered_map.h (unordered_map::find<>, 
unordered_map::count<>,
    unordered_map::contains<>, unordered_map::equal_range<>): 
New member function

    templates to perform heterogeneous lookup.
    (unordered_multimap::find<>, unordered_multimap::count<>,
    unordered_multimap::contains<>, 
unordered_multimap::equal_range<>): Likewise.
    * include/bits/unordered_set.h (unordered_set::find<>, 
unordered_set::count<>,
    unordered_set::contains<>, unordered_set::equal_range<>): 
Likewise.

    (unordered_multiset::find<>, unordered_multiset::count<>,
    unordered_multiset::contains<>, 
unordered_multiset::equal_range<>): Likewise.

    * include/debug/unordered_map
    (unordered_map::find<>, unordered_map::equal_range<>): 
Likewise.
    (unordered_multimap::find<>, 
unordered_multimap::equal_range<>): Likewise.

    * include/debug/unordered_set
    (unordered_set::find<>, unordered_set::equal_range<>): 
Likewise.
    (unordered_multiset::find<>, 
unordered_multiset::equal_range<>): Likewise.
    * testsuite/23_containers/unordered_map/operations/1.cc: 
New test.
    * 
testsuite/23_containers/unordered_multimap/operations/1.cc: New test.
    * 
testsuite/23_containers/unordered_multiset/operations/1.cc: New test.
    * testsuite/23_containers/unordered_set/operations/1.cc: 
New test.


New test run under Linux x86_64.

Ok to commit if all tests pass ?

François

On 03/02/21 12:24 pm, Jonathan Wakely wrote:

On 03/02/21 11:23 +, Jonathan Wakely wrote:

On 25/01/21 19:21 +0100, François Dumont via Libstdc++ wrote:
I think I never got a clear answer that we'll wait for stage 1 to 
consider this patch so here is a ping.


My concern with this patch is that it alters the existing code used
for non-heterogeneous lookups in C++11/14/17. I think if we're going
to do thatk, it needs to wait for stage 1.

If the new C++20 code was added with new _M_find_before_node and


s/_M_find_before_node/_M_find_before_node_tr/


_M_find_node_tr members (duplicating the existing code) then it would
be safe to add now, because it wouldn't touch the stable C++11/14/17
code.




diff --git a/libstdc++-v3/include/bits/hashtable.h b/libstdc++-v3/include/bits/hashtable.h
index bc7ec926155..fa80675ad91 100644
--- a/libstdc++-v3/include/bits/hashtable.h
+++ b/libstdc++-v3/include/bits/hashtable.h
@@ -724,6 +724,38 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   std::pair
   equal_range(const key_type& __k) const;
 
+#if __cplusplus > 201702L
+  template,
+	   typename = __has_is_transparent_t<_Equal, _Kt>>
+	iterator
+	_M_find_tr(const _Kt& __k);
+
+  template,
+	   typename = __has_is_transparent_t<_Equal, _Kt>>
+	const_iterator
+	_M_find_tr(const _Kt& __k) const;
+
+  template,
+	   typename = __has_is_transparent_t<_Equal, _Kt>>
+	size_type
+	_M_count_tr(const _Kt& __k) const;
+
+  template,
+	   typename = __has_is_transparent_t<_Equal, _Kt>>
+	pair
+	_M_equal_range_tr(const _Kt& __k);
+
+  template,
+	   typename = __has_is_transparent_t<_Equal, _Kt>>
+	pair
+	_M_equal_range_tr(const _Kt& __k) const;
+#endif
+
 private:
   // Bucket index computation helpers.
   size_type
@@ -739,6 +771,10 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   __node_base_ptr
   _M_find_before_node(size_type, const key_type&, __hash_code) const;
 
+  template
+	__node_base_ptr
+	_M_find_before_node_tr(size_type, const _Kt&, __hash_code) const;
+
   __node_ptr
   _M_find_node(size_type __bkt, const key_type& __key,
 		   

[PATCH, rs6000, expand, hooks]: Fix PR98872, handle uninitialized opaque mode variables

[Peter Bergner via Gcc-patches]

Adding Richard since he's reviewed the generic opaque mode code in
the past and this patch contains some more eneric support.

GCC handles pseudos that are used uninitialized, by emitting a
(set (reg: ) CONST0_RTX(regmode)) before their uninitialized
pseudo usage.  Currently, CONST0_RTX(mode) is NULL for opaque modes,
which leads to an ICE.  The solution is to enhance init_emit_once() to
add initialization of CONST0_RTX for opaque modes using a target hook,
since CONST0_RTX probably are different for each opaque mode and each
target.  The default hook throws an error to force the target to think
hard about what their CONST0_RTX values should be for each mode.

This passed bootstrap and regtesting on x86_64-linux and powerpc64le-linux
with no regressions.  Ok for mainline?

Peter


gcc/
PR target/98872
* config/rs6000/mma.md (*movoo): Accept zero constraint.
(mma_xxsetaccz): Use CONST0_RTX.
* config/rs6000/predicates.md: Recognize OOmode CONST0_RTX.
* config/rs6000/rs6000.c (TARGET_OPAQUE_CONST0_RTX): Define.
(rs6000_split_multireg_move): Handle splitting an OOmode register
set to CONST0_RTX.
(rs6000_opaque_const0_rtx): New function.
* emit-rtl.c (init_emit_once): Initialize CONST0_RTX for opaque modes.
* hooks.c (hook_rtx_mode_unreachable): New function.
* hooks.h (hook_rtx_mode_unreachable): Declare
* target.def (opaque_const0_rtx): New target hook.
* doc/tm.texi.in: Document it.
* doc/tm.texi: Regenerate.

gcc/testsuite/
* gcc.target/powerpc/pr98872.c: New test.

diff --git a/gcc/config/rs6000/mma.md b/gcc/config/rs6000/mma.md
index 87569f1c31d..fab849a4f12 100644
--- a/gcc/config/rs6000/mma.md
+++ b/gcc/config/rs6000/mma.md
@@ -272,7 +272,7 @@
 
 (define_insn_and_split "*movoo"
   [(set (match_operand:OO 0 "nonimmediate_operand" "=wa,m,wa")
-   (match_operand:OO 1 "input_operand" "m,wa,wa"))]
+   (match_operand:OO 1 "input_operand" "m,wa,waO"))]
   "TARGET_MMA
&& (gpc_reg_operand (operands[0], OOmode)
|| gpc_reg_operand (operands[1], OOmode))"
@@ -473,9 +473,7 @@
(const_int 0))]
   "TARGET_MMA"
 {
-  rtx xo0 = gen_rtx_UNSPEC (XOmode, gen_rtvec (1, const0_rtx),
-   UNSPEC_MMA_XXSETACCZ);
-  emit_insn (gen_rtx_SET (operands[0], xo0));
+  emit_insn (gen_rtx_SET (operands[0], CONST0_RTX (XOmode)));
   DONE;
 })
 
diff --git a/gcc/config/rs6000/predicates.md b/gcc/config/rs6000/predicates.md
index 5d1952e59d3..30805ab0619 100644
--- a/gcc/config/rs6000/predicates.md
+++ b/gcc/config/rs6000/predicates.md
@@ -1081,6 +1081,10 @@
   && easy_vector_constant (op, mode))
 return 1;
 
+  /* For OOmode, zero is an easy constant.  */
+  if (mode == OOmode && op == CONST0_RTX (mode))
+return 1;
+
   /* For floating-point or multi-word mode, the only remaining valid type
  is a register.  */
   if (SCALAR_FLOAT_MODE_P (mode)
diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
index f5565a1a253..c726aa09d26 100644
--- a/gcc/config/rs6000/rs6000.c
+++ b/gcc/config/rs6000/rs6000.c
@@ -1752,6 +1752,10 @@ static const struct attribute_spec 
rs6000_attribute_table[] =
 
 #undef TARGET_INVALID_CONVERSION
 #define TARGET_INVALID_CONVERSION rs6000_invalid_conversion
+
+#undef TARGET_OPAQUE_CONST0_RTX
+#define TARGET_OPAQUE_CONST0_RTX rs6000_opaque_const0_rtx
+
 
 
 /* Processor table.  */
@@ -16624,6 +16628,19 @@ rs6000_split_multireg_move (rtx dst, rtx src)
  return;
}
 
+  /* Split the clearing of an OOmode register pair into clearing
+of its two constituent registers.  */
+  if (REG_P (dst) && mode == OOmode && src == CONST0_RTX (mode))
+   {
+ int regno = REGNO (dst);
+ gcc_assert (VSX_REGNO_P (regno));
+ emit_insn (gen_rtx_SET (gen_rtx_REG (reg_mode, regno),
+ CONST0_RTX (reg_mode)));
+ emit_insn (gen_rtx_SET (gen_rtx_REG (reg_mode, regno + 1),
+ CONST0_RTX (reg_mode)));
+ return;
+   }
+
   /* Register -> register moves can use common code.  */
 }
 
@@ -27477,6 +27494,25 @@ rs6000_output_addr_vec_elt (FILE *file, int value)
   fprintf (file, "\n");
 }
 
+/* Implement TARGET_OPAQUE_CONST0_RTX.  */
+
+rtx
+rs6000_opaque_const0_rtx (machine_mode mode)
+{
+  gcc_assert (OPAQUE_MODE_P (mode));
+
+  switch (mode)
+{
+case E_OOmode:
+  return const0_rtx;
+case E_XOmode:
+  return gen_rtx_UNSPEC (XOmode, gen_rtvec (1, const0_rtx),
+UNSPEC_MMA_XXSETACCZ);
+default:
+  gcc_unreachable ();
+}
+}
+
 struct gcc_target targetm = TARGET_INITIALIZER;
 
 #include "gt-rs6000.h"
diff --git a/gcc/emit-rtl.c b/gcc/emit-rtl.c
index b23284e5e56..4ac26491481 100644
--- a/gcc/emit-rtl.c
+++ b/gcc/emit-rtl.c
@@ -6408,6 +6408,11 @@ init_emit_once (void)
 if (GET_MODE_CLASS ((machine_mode) i) == MODE_CC)
   const_tiny_rtx[0][i] = 

Comma Operator - Left to Right Associativity

[AJ D via Gcc]

Isn't comma operator suppose to honor left-to-right associativity?

When I try it on this test case, it exhibits right-to-left associativity.

#include 



struct CBI;

struct EC;

struct CET;



struct CBI {

CBI& operator,(const CBI& rhs)

{ return *const_cast(); }

};



struct EC : CBI {

explicit EC(CET* cet) : cet_(cet)

{}



CET* cet_;

};



struct CET {

CBI& operator,(const CBI& rhs) const

{ return *const_cast(); }



operator EC&() const

{ return *new EC(const_cast(this)); }

};



static const CET&

hello() {

std::cout << "Hello " << std::endl;

return *new CET();

}



static const CET&

world() {

std::cout << "World " << std::endl;

return *new CET();

}



static void

test_comma_operator(CBI&) {



}



int main()

{

test_comma_operator ((

hello(),

world()

));

}



CLANG appears to do it right.


us01odcvde08782> clang++ -g test.cpp

us01odcvde08782> ./a.out

*Hello*

World

us01odcvde08782> g++ -g test.cpp

us01odcvde08782> ./a.out

World

*Hello*

us01odcvde08782>


I was using CentOS6.8 with gcc 6.2. However, trying other versions of GCC
didn't make any difference.


Is this a bug in GCC?

Re: [PATCH] improve detection of incompatible redeclarations (PR 97882)

[Martin Sebor via Gcc-patches]

On 2/4/21 9:48 AM, Martin Sebor wrote:

On 2/3/21 5:15 PM, Joseph Myers wrote:

On Wed, 3 Feb 2021, Martin Sebor via Gcc-patches wrote:


+/* Return true of T1 and T2 are matching types for the purposes of
+   redeclaring a variable or a function without a prototype (i.e.,
+   considering just its return type).  */


I think this comment is confusing (it suggests it's checking something
looser than the notion of compatibility checked by comptypes, but it's
actually checking something stricter).  But I also think it's wrong to do
anything restricted to the return type.

For example, I think the following should be rejected, as enum E and
unsigned int end up incompatible and quite likely ABI-incompatible.

enum E;
void f(enum E);
void f(unsigned int);
enum E { x = 1ULL << 63 };

Maybe the ICE is specific to the case of return types, but I think the
same rules about type compatibility should apply regardless of precisely
where the incomplete enum type appears.


Ah, it's even more wide-spread than I realized.



I'd expect the natural fix for this PR to involve making
comptypes_internal treat an incomplete enum as incompatible with an
integer type.  Only if that causes too many problems should we then look
at other approaches.



Let me look into it then.


Okay, that's much simpler.  Thanks for nudging me in the right
direction!  How's the attached patch? Retested on x86_64-linux.

Martin
PR c/97882 - Segmentation Fault on improper redeclaration of function

gcc/c/ChangeLog:

	PR c/97882
	* c-decl.c (locate_old_decl): Add type to diagnostic output.
	(diagnose_mismatched_decls): Same.
	(start_function): Introduce temporaries for better readability.
	* c-typeck.c (comptypes_internal): Only consider complete enum
	types in comparisons with integers.

gcc/testsuite/ChangeLog:

	PR c/97882
	* gcc.dg/decl-8.c: Adjust text of expected diagnostic.
	* gcc.dg/label-decl-4.c: Same.
	* gcc.dg/mismatch-decl-1.c: Same.
	* gcc.dg/old-style-then-proto-1.c: Same.
	* gcc.dg/parm-mismatch-1.c: Same.
	* gcc.dg/pr35445.c: Same.
	* gcc.dg/redecl-11.c: Same.
	* gcc.dg/redecl-12.c: Same.
	* gcc.dg/redecl-13.c: Same.
	* gcc.dg/redecl-15.c: Same.
	* gcc.dg/tls/thr-init-1.c: Same.
	* objc.dg/id-1.m: Same.
	* objc.dg/tls/diag-3.m: Same.
	* c-c++-common/array-lit.s: New test.
	* gcc.dg/pr97882.c: New test.
	* gcc.dg/qual-return-7.c: New test.
	* gcc.dg/qual-return-8.c: New test.

diff --git a/gcc/c/c-decl.c b/gcc/c/c-decl.c
index be95643fcf9..a5852a3bae7 100644
--- a/gcc/c/c-decl.c
+++ b/gcc/c/c-decl.c
@@ -1910,15 +1910,22 @@ validate_proto_after_old_defn (tree newdecl, tree newtype, tree oldtype)
 static void
 locate_old_decl (tree decl)
 {
-  if (TREE_CODE (decl) == FUNCTION_DECL && fndecl_built_in_p (decl)
+  if (TREE_CODE (decl) == FUNCTION_DECL
+  && fndecl_built_in_p (decl)
   && !C_DECL_DECLARED_BUILTIN (decl))
 ;
   else if (DECL_INITIAL (decl))
-inform (input_location, "previous definition of %q+D was here", decl);
+inform (input_location,
+	"previous definition of %q+D with type %qT",
+	decl, TREE_TYPE (decl));
   else if (C_DECL_IMPLICIT (decl))
-inform (input_location, "previous implicit declaration of %q+D was here", decl);
+inform (input_location,
+	"previous implicit declaration of %q+D with type %qT",
+	decl, TREE_TYPE (decl));
   else
-inform (input_location, "previous declaration of %q+D was here", decl);
+inform (input_location,
+	"previous declaration of %q+D with type %qT",
+	decl, TREE_TYPE (decl));
 }
 
 /* Subroutine of duplicate_decls.  Compare NEWDECL to OLDDECL.
@@ -2083,7 +2090,8 @@ diagnose_mismatched_decls (tree newdecl, tree olddecl,
 	   && C_DECL_IMPLICIT (olddecl) && !DECL_INITIAL (olddecl))
 	{
 	  pedwarned = pedwarn (input_location, 0,
-			   "conflicting types for %q+D", newdecl);
+			   "conflicting types for %q+D; have %qT",
+			   newdecl, newtype);
 	  /* Make sure we keep void as the return type.  */
 	  TREE_TYPE (olddecl) = *oldtypep = oldtype = newtype;
 	}
@@ -2119,7 +2127,7 @@ diagnose_mismatched_decls (tree newdecl, tree olddecl,
 		error ("conflicting type qualifiers for %q+D", newdecl);
 	}
 	  else
-	error ("conflicting types for %q+D", newdecl);
+	error ("conflicting types for %q+D; have %qT", newdecl, newtype);
 	  diagnose_arglist_conflict (newdecl, olddecl, newtype, oldtype);
 	  locate_old_decl (olddecl);
 	  return false;
@@ -9457,27 +9465,29 @@ start_function (struct c_declspecs *declspecs, struct c_declarator *declarator,
   current_function_prototype_locus = UNKNOWN_LOCATION;
   current_function_prototype_built_in = false;
   current_function_prototype_arg_types = NULL_TREE;
-  if (!prototype_p (TREE_TYPE (decl1)))
+  tree newtype = TREE_TYPE (decl1);
+  tree oldtype = old_decl ? TREE_TYPE (old_decl) : newtype;
+  if (!prototype_p (newtype))
 {
+  tree oldrt = TREE_TYPE (oldtype);
+  tree newrt = TREE_TYPE (newtype);
   if (old_decl != NULL_TREE
-	  && TREE_CODE (TREE_TYPE 

Re: [PATCH] PR target/98878 - Incorrect multilib list for riscv*-rtems

[Sebastian Huber]

On 04/02/2021 11:01, Kito Cheng wrote:


gcc/ChangeLog:

* gcc.c (print_multilib_info): Check all required argument is provided
by default arg.


Thanks, with this patch the riscv-rtems* target works again.

--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/

[Bug analyzer/98575] [11 regression] gcc.dg/analyzer/pr94851-1.c fails after r11-6495

[dmalcolm at gcc dot gnu.org via Gcc-bugs]

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

David Malcolm  changed:

   What|Removed |Added

   Last reconfirmed||2021-02-04
 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1

--- Comment #1 from David Malcolm  ---
Confirmed; I can reproduce it on gcc135 in the compile farm (todays' trunk,
with powerpc64le-unknown-linux-gnu)

[Bug target/98959] ICE in extract_constrain_insn, at recog.c:2670

[bergner at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #12 from Peter Bergner  ---
(In reply to Jakub Jelinek from comment #10)
> The important difference from my auto-host.h to your auto-host.h which
> causes this ICE is that you don't have HAVE_LD_LARGE_TOC defined.
> Manually commenting it out makes the ICE reproduceable.

Doing this on my native build allowed me to recreate the ICE too.  I'll have a
look.

[Bug d/98910] [11 regression] locale_t undefined on Solaris

[ro at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #2 from Rainer Orth  ---
Unfortunately, even with your patch Solaris bootstrap is still broken:

/vol/gcc/src/hg/master/local/libphobos/libdruntime/core/sys/posix/strings.d:23:15:
error: module core.sys.posix.locale import 'locale_t' not found
   23 | public import core.sys.posix.locale : locale_t;
  |   ^

I only now noticed that you only define the XPG6 subset of locale functions in
locale.d for Solaris.  That seems quite unfortunate, castrating functionality
for the benefit of older XPG6-only Solaris 11.3 while 11.4 supports locale_t
and
XPG7 perfectly fine.

I'm uncertain what's the best way to handle this: one could certainly test for
a locale_t definition via autoconf, record the result in gcc/config.d, and use
that instead of version (Solaris).

The same test would have to be used in strings.d to avoid leaving that broken
when locale_t isn't available.

[Bug target/98959] ICE in extract_constrain_insn, at recog.c:2670

[bergner at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #11 from Peter Bergner  ---
(In reply to Jakub Jelinek from comment #10)
> The important difference from my auto-host.h to your auto-host.h which
> causes this ICE is that you don't have HAVE_LD_LARGE_TOC defined.
> Manually commenting it out makes the ICE reproduceable.

So the important thing on recreating this is using a binutils that has been
configured a certain way?

[Bug c++/98970] New: Use of uninitialized variable in loop is not reported

[aa1ronham at gmail dot com via Gcc-bugs]

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

Bug ID: 98970
   Summary: Use of uninitialized variable in loop is not reported
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: aa1ronham at gmail dot com
  Target Milestone: ---

The following code:

```
int main() {
int x;
for (int i = 0; i < 10; i++) {
x++;
}
}
```

does not produce any warnings when compiled with 'g++ bad.cpp -Wall'

However, the increment 'x++' reads an uninitialized value of 'x', so a warning
should be reported.

[Bug c/60759] improve -Wlogical-op

[vincent-gcc at vinc17 dot net via Gcc-bugs]

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

Vincent Lefèvre  changed:

   What|Removed |Added

 CC||vincent-gcc at vinc17 dot net

--- Comment #5 from Vincent Lefèvre  ---
Clang's -Wconstant-logical-operand is useful: it found a bug in new MPFR code,
which had

  rnd_mode == MPFR_RNDN || MPFR_RNDF

instead of

  rnd_mode == MPFR_RNDN || rnd_mode == MPFR_RNDF

FYI, GCC's -Wlogical-op doesn't warn (20201002 snapshot).

[Bug target/98959] ICE in extract_constrain_insn, at recog.c:2670

[jakub at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #10 from Jakub Jelinek  ---
The important difference from my auto-host.h to your auto-host.h which causes
this ICE is that you don't have HAVE_LD_LARGE_TOC defined.
Manually commenting it out makes the ICE reproduceable.

[Bug rtl-optimization/98144] REE needs 6GB DF memory when compiling insn-extract.c with RTL checking enabled

[sirl at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #13 from Franz Sirl  ---
Some data for the inhouse testcase in Bug 80930 with ASAN+UBSAN:

 gcc-9@r9-8944:   OOM killed after 15min at ~85 GB
 gcc-10@r10-9345: takes ~25min to compile, max mem ~6.5GB

Thanks for this nice improvement!

Re: [PATCH] c++: Fix bogus -Wvolatile warning in C++20 [PR98947]

[Marek Polacek via Gcc-patches]

On Thu, Feb 04, 2021 at 10:59:21AM -0500, Jason Merrill wrote:
> On 2/3/21 7:03 PM, Marek Polacek wrote:
> > Since most of volatile is deprecated in C++20, we are required to warn
> > for compound assignments to volatile variables and so on.  But here we
> > have
> > 
> >volatile int x, y, z;
> >(b ? x : y) = 1;
> > 
> > and we shouldn't warn, because simple assignments like x = 24; should
> > not provoke the warning when they are a discarded-value expression.
> > 
> > We warn here because when ?: is used as an lvalue, we transform it in
> > cp_build_modify_expr/COND_EXPR from (a ? b : c) = rhs to
> > 
> >(a ? (b = rhs) : (c = rhs))
> > 
> > and build_conditional_expr then calls mark_lvalue_use for the new
> > artificial assignments
> 
> Hmm, that seems wrong; the ?: expression itself does not use lvalue operands
> any more than ',' does.  I notice that removing those mark_lvalue_use calls
> doesn't regress Wunused-var-10.c, which was added with them in r160289.

The mark_lvalue_use calls didn't strike me as wrong because [expr.cond]/7
says that lvalue-to-rvalue conversion is performed on the second and third
operands.  With those mark_lvalue_use calls removed, we'd not issue the
warning for

  (b ? (x = 2) : y) = 1;
  (b ? x : (y = 5)) = 1;

which I think we want (and clang++ warns here too).

> > --- a/gcc/cp/expr.c
> > +++ b/gcc/cp/expr.c
> > @@ -228,7 +228,8 @@ mark_use (tree expr, bool rvalue_p, bool read_p,
> >   && !cp_unevaluated_operand
> >   && (TREE_THIS_VOLATILE (lhs)
> >   || CP_TYPE_VOLATILE_P (TREE_TYPE (lhs)))
> > - && !TREE_THIS_VOLATILE (expr))
> > + && !TREE_THIS_VOLATILE (expr)
> > + && warn_volatile)
> 
> Or you could check the return value of the warning?

Works too.  Happy to change that.

Marek

Re: [PATCH] c++: Fix ICE with structured binding initialized to incomplete array [PR97878]

[Jakub Jelinek via Gcc-patches]

On Thu, Feb 04, 2021 at 11:03:10AM -0500, Jason Merrill wrote:
> > --- gcc/cp/decl.c.jj2021-01-28 16:13:04.0 +0100
> > +++ gcc/cp/decl.c   2021-02-03 15:57:16.980557836 +0100
> > @@ -6837,7 +6837,8 @@ check_initializer (tree decl, tree init,
> >   /* We will have already complained.  */
> >   return NULL_TREE;
> > -  if (TREE_CODE (type) == ARRAY_TYPE)
> > +  if (TREE_CODE (type) == ARRAY_TYPE
> > +  && (!DECL_DECOMPOSITION_P (decl) || DECL_DECOMP_BASE (decl)))
> 
> This needs a comment.  Or handle this inside check_array_initializer, where
> we could give a more helpful diagnostic?

So like this?

2021-02-04  Jakub Jelinek  

PR c++/97878
* decl.c (check_array_initializer): For structured bindings, require
the array type to be complete.

* g++.dg/cpp1z/decomp54.C: New test.

--- gcc/cp/decl.c.jj2021-02-03 17:13:58.567872007 +0100
+++ gcc/cp/decl.c   2021-02-04 18:42:35.347374198 +0100
@@ -6768,6 +6768,19 @@ check_array_initializer (tree decl, tree
 {
   tree element_type = TREE_TYPE (type);
 
+  /* Structured binding when initialized with an array type needs
+ to have complete type.  */
+  if (decl
+  && DECL_DECOMPOSITION_P (decl)
+  && !DECL_DECOMP_BASE (decl)
+  && !COMPLETE_TYPE_P (type))
+{
+  error_at (DECL_SOURCE_LOCATION (decl),
+   "structured binding has incomplete type");
+  TREE_TYPE (decl) = error_mark_node;
+  return true;
+}
+
   /* The array type itself need not be complete, because the
  initializer may tell us how many elements are in the array.
  But, the elements of the array must be complete.  */
--- gcc/testsuite/g++.dg/cpp1z/decomp54.C.jj2021-02-04 18:33:34.829393825 
+0100
+++ gcc/testsuite/g++.dg/cpp1z/decomp54.C   2021-02-04 18:33:34.829393825 
+0100
@@ -0,0 +1,17 @@
+// PR c++/97878
+// { dg-do compile { target c++11 } }
+// { dg-options "" }
+
+extern int a[];
+auto [b] { a };// { dg-error "has incomplete type" }
+   // { dg-warning "only available with" "" { target c++14_down } 
.-1 }
+auto [c] = a;  // { dg-error "has incomplete type" }
+   // { dg-warning "only available with" "" { target c++14_down } 
.-1 }
+extern int d[0];
+auto [e] { d };// { dg-error "too many initializers for" }
+   // { dg-error "1 name provided for structured binding" "" { 
target *-*-* } .-1 }
+   // { dg-message "decomposes into 0 elements" "" { target *-*-* 
} .-2 }
+   // { dg-warning "only available with" "" { target c++14_down } 
.-3 }
+auto [f] = d;  // { dg-error "1 name provided for structured binding" }
+   // { dg-message "decomposes into 0 elements" "" { target *-*-* 
} .-1 }
+   // { dg-warning "only available with" "" { target c++14_down } 
.-2 }


Jakub

Re: [PATCH] c++: Private parent access check for using decls [PR19377]

[Anthony Sharp via Gcc-patches]

> Yes, thanks; it would take a lot to make me request less comments.

Awesome.

> The second lines of arguments are indented one space too far in both these 
> calls.

Oops! I will fix that.

> Well, I guess it could be using a declaration of the same name from another 
> base.

 Yes I had been worrying about that.

> But in that case you could end up with an overload set
> containing both the decl we're complaining about and another of the same
> name from another base, in which case the lookup result would include
> both, and so the comparison would fail and we would fall through to the
> private base assumption.

I think technically yes ... but also no since such code would not
compile anyways, plus oddly it seems to work anyway. For instance
(assuming I'm understanding correctly), if you do this (with the patch
applied):

class A
{
  protected:
  int i;
};

class A2
{
  protected:
  int i;
};

class B:public A, public A2
{
  private:
  using A::i, A2::i;
};

class C:public B
{
  void f()
  {
A::i = 0;
  }
};

You get:

error: redeclaration of ‘using A::i’
   using A::i;

note: previous declaration ‘using A2::i’
using A2::i;

error: redeclaration of ‘using A2::i’
   using A::i, A2::i;

previous declaration ‘using A::i’
   using A::i, A2::i;

In member function ‘void C::f()’:
error: ‘int A::i’ is private within this context
   A::i = 0;

note: declared private here
   using A::i, A2::i;

Which seems to work (well ... more like fail to compile ... as
expected). Maybe you're imagining a different situation to me?

You can even use void f() { i = 0; } and void f() { A2::i = 0; } and
you seem to get the same results either which way (although, to be
fair, if you do A2::i = 0, it suddenly doesn't complain about it being
private anymore [no idea why], it just complains about the
redeclaration , and once you fix the redeclaration, it THEN complains
about being private, so it's got a bit of a quirk - don't think that's
related to the patch though).

> But checking the name is a simple way to skip irrelevant usings.

That does sound like a better way of doing it. Would I just do
cp_tree_equal (DECL_NAME (blah1), DECL_NAME (blah2)) [assuming
DECL_NAME returns a tree], or perhaps DECL_NAME (blah1) == DECL_NAME
(blah2)?

> Maybe also check that the using is TREE_PRIVATE?

Would that be necessary? Maybe if you wanted to sanity-check it I
suppose. We know for sure that PARENT_BINFO has private access to
DECL. If we find a using statement introducing DECL in PARENT_BINFO,
then surely the using statement must (by definition) have been
private? If it were not private, then the child class would have been
able to access it, and enforce_access wouldn't have thrown an error.
It doesn't seem to be the case that DECL could be private for any
other reason other than the using decl being private.

Let me know your thoughts and I will update the patch. Thanks for your help.

Anthony


On Thu, 4 Feb 2021 at 16:33, Jason Merrill  wrote:
>
> On 2/4/21 11:24 AM, Jason Merrill wrote:
> > On 2/4/21 10:02 AM, Anthony Sharp via Gcc-patches wrote:
> >> Hello,
> >>
> >> New bugfix for PR19377
> >> (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19377). This is
> >> basically an extension of what I did before for PR17314 except it also
> >> fixes this other bug.
> >>
> >> I hope I didn't over-comment in the code ... better to say too much
> >> than too little! It's a niche bug so I thought it could do with a
> >> little explanation.
> >
> > Yes, thanks; it would take a lot to make me request less comments.
> >
> >> +  if (TREE_CODE (parent_field) == USING_DECL)
> >> +   {
> >> + if (cp_tree_equal (decl,
> >> +lookup_member (parent_binfo,
> >> +   DECL_NAME (parent_field),
> >> +   /*protect=*/0,
> >> +   /*want_type=*/false,
> >> +   tf_warning_or_error)))
> >
> > Isn't it sufficient to check that the names match?
>
> Well, I guess it could be using a declaration of the same name from
> another base.  But in that case you could end up with an overload set
> containing both the decl we're complaining about and another of the same
> name from another base, in which case the lookup result would include
> both, and so the comparison would fail and we would fall through to the
> private base assumption.
>
> But checking the name is a simple way to skip irrelevant usings.
> Maybe also check that the using is TREE_PRIVATE?
>
> >>   tree parent_binfo = get_parent_with_private_access (decl,
> >> -
> >> basetype_path);
> >> +
> >> basetype_path);
> > ...
> >> + diag_location = get_class_access_diagnostic_decl
> >> (parent_binfo,
> >> +
> >> diag_decl);
> >
> > The second lines of arguments are indented one space too far in both
> > these calls.
> >
> > Jason
>

[Bug middle-end/26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)

[jamborm at gcc dot gnu.org via Gcc-bugs]

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

Bug 90234 Summary: 503.bwaves_r is 6% slower on Zen1/Zen2 CPUs at -Ofast with 
native march/mtune than with generic ones
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90234

   What|Removed |Added

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

[Bug target/90234] 503.bwaves_r is 6% slower on Zen1/Zen2 CPUs at -Ofast with native march/mtune than with generic ones

[jamborm at gcc dot gnu.org via Gcc-bugs]

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

Martin Jambor  changed:

   What|Removed |Added

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

--- Comment #3 from Martin Jambor  ---
I do not have data from Zen1 on this, but on Zen2 this is fixed on the current
trunk (and on Zen3 too, where GCC 10 also was slower with native than generic
tuning).

I don't seem to be able to force LNT to show me the respective graph, but my
guess would be that lim after loop interchange did it.  Anyway, fixed.

[Bug middle-end/26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)

[jamborm at gcc dot gnu.org via Gcc-bugs]

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

Bug 94375 Summary: 548.exchange2_r run time is 8-18% worse than GCC 9 at -Ofast 
-march=native
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94375

   What|Removed |Added

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

[Bug tree-optimization/53947] [meta-bug] vectorizer missed-optimizations

[jamborm at gcc dot gnu.org via Gcc-bugs]

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

Bug 94375 Summary: 548.exchange2_r run time is 8-18% worse than GCC 9 at -Ofast 
-march=native
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94375

   What|Removed |Added

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

[Bug tree-optimization/94375] 548.exchange2_r run time is 8-18% worse than GCC 9 at -Ofast -march=native

[jamborm at gcc dot gnu.org via Gcc-bugs]

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

Martin Jambor  changed:

   What|Removed |Added

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

--- Comment #7 from Martin Jambor  ---
Thu bug as specified here has been fixed by commits 31584824665, 91153e0af9a,
67ce9099bc9, 1e7fdc02cba, 7d2cb2755a1.

We can still do better on the benchmark if we fix PR 98782.

[Bug target/94373] 548.exchange2_r run time is 16-35% worse than GCC 9 at -O2 and generic march/mtune

[jamborm at gcc dot gnu.org via Gcc-bugs]

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

Martin Jambor  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=98782
Summary|548.exchange2_r run time is |548.exchange2_r run time is
   |7-12% worse than GCC 9 at   |16-35% worse than GCC 9 at
   |-O2 and generic march/mtune |-O2 and generic march/mtune
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2021-02-04

--- Comment #5 from Martin Jambor  ---
The regression is confirmed, it is now 35% on Cascadelake, 20% on Zen3
and 16% on Zen2 against GCC 9 (19%, 12% and 8% respectively against
GCC 10)

LNT sees it too:
  - on znver2 (though with LTO):
https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=278.407.0=298.407.0;
  - on znver1:
https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=303.407.0=31.407.0;
  - on a Kabylake:
https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=206.407.0=30.407.0;

I wonder whether the RA issue PR 98782 might be also related, although
it mostly focuses on -O3.

[Bug middle-end/98465] [11 Regression] Bogus -Wstringop-overread with -std=gnu++20 -O2 and std::string::insert

[jakub at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #25 from Jakub Jelinek  ---
(In reply to Jonathan Wakely from comment #22)
> I think it is rare for _M_disjunct to return false, most strings being
> appended/inserted are disjunct from the string itself.

If it is really rare, then moving it out of line might be beneficial.  It will
slow down the non-disjunct case, not only because of a (possibly PLT) call, but
also because when it isn't inlined, e.g. for constant __len1 and/or __len2 the
various comparisons can't be constant folded.  But it will make code smaller.

As a proof of concept, I've hacked up the preprocessed source:
--- pr98465.ii  2021-02-04 14:09:29.230049287 +0100
+++ pr98465-5.ii2021-02-04 18:08:19.784739149 +0100
@@ -26229,6 +26229,10 @@ namespace __cxx11 {
   basic_string&
   _M_append(const _CharT* __s, size_type __n);

+  [[gnu::noinline, gnu::cold]] void
+  _M_replace_cold(size_type __pos, size_type __len1, const _CharT* __s,
+   const size_type __len2);
+
 public:
 # 2285
"/opt/compiler-explorer/gcc-trunk-20210204/include/c++/11.0.0/bits/basic_string.h"
3
   size_type
@@ -28220,31 +28224,15 @@ namespace std __attribute__ ((__visibili
 }

   template
-basic_string<_CharT, _Traits, _Alloc>&
+void
 basic_string<_CharT, _Traits, _Alloc>::
-_M_replace(size_type __pos, size_type __len1, const _CharT* __s,
+_M_replace_cold(size_type __pos, size_type __len1, const _CharT* __s,
 const size_type __len2)
 {
-  _M_check_length(__len1, __len2, "basic_string::_M_replace");
+  pointer __p = this->_M_data() + __pos;

   const size_type __old_size = this->size();
-  const size_type __new_size = __old_size + __len2 - __len1;
-
-  if (__new_size <= this->capacity())
- {
-   pointer __p = this->_M_data() + __pos;
-
-   const size_type __how_much = __old_size - __pos - __len1;
-   if (_M_disjunct(__s))
- {
-   if (__how_much && __len1 != __len2)
-  this->_S_move(__p + __len2, __p + __len1, __how_much);
-   if (__len2)
-  this->_S_copy(__p, __s, __len2);
- }
-   else
- {
-
+  const size_type __how_much = __old_size - __pos - __len1;
if (__len2 && __len2 <= __len1)
   this->_S_move(__p, __s, __len2);
if (__how_much && __len1 != __len2)
@@ -28263,7 +28251,34 @@ namespace std __attribute__ ((__visibili
 __len2 - __nleft);
   }
   }
+  }
+
+  template
+basic_string<_CharT, _Traits, _Alloc>&
+basic_string<_CharT, _Traits, _Alloc>::
+_M_replace(size_type __pos, size_type __len1, const _CharT* __s,
+const size_type __len2)
+{
+  _M_check_length(__len1, __len2, "basic_string::_M_replace");
+
+  const size_type __old_size = this->size();
+  const size_type __new_size = __old_size + __len2 - __len1;
+
+  pointer __p = this->_M_data() + __pos;
+
+  const size_type __how_much = __old_size - __pos - __len1;
+
+  if (__new_size <= this->capacity())
+ {
+   if (_M_disjunct(__s))
+ {
+   if (__how_much && __len1 != __len2)
+  this->_S_move(__p + __len2, __p + __len1, __how_much);
+   if (__len2)
+  this->_S_copy(__p, __s, __len2);
  }
+   else
+   _M_replace_cold(__pos, __len1, __s, __len2);
  }
   else
  this->_M_mutate(__pos, __len1, __s, __len2);

Without this patch, _Z1fRNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE
has 614 bytes,
with the patch there is:
399 bytes of _Z1fRNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE + 31 of
_Z1fRNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE.cold (caller of
_M_replace_cold moved into cold section) and 317 bytes
_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE15_M_replace_coldEmmPKcm. 
But that one can be moved to libstdc++ and shared there.

[Bug target/98959] ICE in extract_constrain_insn, at recog.c:2670

[marxin at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #9 from Martin Liška  ---
> If that fixes it, are you really seeing the same ICE on current trunk?

Yes, I see it also on the current trunk.

[Bug c/98969] New: [11 Regression] ICE: Segmentation fault (in print_mem_ref)

[asolokha at gmx dot com via Gcc-bugs]

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

Bug ID: 98969
   Summary: [11 Regression] ICE: Segmentation fault (in
print_mem_ref)
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Keywords: ice-on-invalid-code
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

gcc-11.0.0-alpha20210131 snapshot (g:98342bdd2b7085c9e7e4c9fbb07c3917a0013515)
ICEs when compiling the following snippet by either C or C++ compiler w/
-fanalyzer:

struct TYPE_14__ {
  char *expr;
};

char *
strdup (const char *);

void
_round_2_cb (long int _round_2_cb_n_0)
{
  struct TYPE_14__ *bb = (struct TYPE_14__ *) _round_2_cb_n_0;

  bb->expr = strdup ((const char *) 0);
}

% gcc-11.0.0 -fanalyzer -c e6r6hdiy.c
during IPA pass: analyzer
e6r6hdiy.c:14:1: internal compiler error: Segmentation fault
   14 | }
  | ^
0xe0343f crash_signal
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20210131/work/gcc-11-20210131/gcc/toplev.c:327
0x8dac60 print_mem_ref
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20210131/work/gcc-11-20210131/gcc/c-family/c-pretty-print.c:2006
0x8d7ffc c_pretty_printer::postfix_expression(tree_node*)
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20210131/work/gcc-11-20210131/gcc/c-family/c-pretty-print.c:1696
0x83b34d c_tree_printer
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20210131/work/gcc-11-20210131/gcc/c/c-objc-common.c:317
0x83b34d c_tree_printer
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20210131/work/gcc-11-20210131/gcc/c/c-objc-common.c:254
0x1a01945 pp_format(pretty_printer*, text_info*)
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20210131/work/gcc-11-20210131/gcc/pretty-print.c:1475
0x11ab18b ana::evdesc::event_desc::formatted_print(char const*, ...) const
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20210131/work/gcc-11-20210131/gcc/analyzer/pending-diagnostic.cc:64
0x1998e16 ana::warning_event::get_desc(bool) const
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20210131/work/gcc-11-20210131/gcc/analyzer/checker-path.cc:885
0x1998692 ana::checker_event::prepare_for_emission(ana::checker_path*,
ana::pending_diagnostic*, diagnostic_event_id_t)
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20210131/work/gcc-11-20210131/gcc/analyzer/checker-path.cc:149
0x19a9159 ana::checker_path::prepare_for_emission(ana::pending_diagnostic*)
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20210131/work/gcc-11-20210131/gcc/analyzer/checker-path.h:559
0x19a9159 ana::diagnostic_manager::emit_saved_diagnostic(ana::exploded_graph
const&, ana::saved_diagnostic const&, ana::exploded_path const&, gimple const*,
int)
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20210131/work/gcc-11-20210131/gcc/analyzer/diagnostic-manager.cc:668
0x19ab831 ana::dedupe_winners::emit_best(ana::diagnostic_manager*,
ana::exploded_graph const&)
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20210131/work/gcc-11-20210131/gcc/analyzer/diagnostic-manager.cc:569
0x19a956a ana::diagnostic_manager::emit_saved_diagnostics(ana::exploded_graph
const&)
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20210131/work/gcc-11-20210131/gcc/analyzer/diagnostic-manager.cc:622
0x11a1602 ana::impl_run_checkers(ana::logger*)
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20210131/work/gcc-11-20210131/gcc/analyzer/engine.cc:4780
0x11a2426 ana::run_checkers()
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20210131/work/gcc-11-20210131/gcc/analyzer/engine.cc:4837
0x11940f8 execute
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20210131/work/gcc-11-20210131/gcc/analyzer/analyzer-pass.cc:87

[Bug target/98959] ICE in extract_constrain_insn, at recog.c:2670

[bergner at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #8 from Peter Bergner  ---
(In reply to Martin Liška from comment #2)
> I do not set any default CPU:

The default cpu on ppc64le is (should be!) POWER8.

That said, I cannot recreate the issue with a cross build using current trunk. 
I will say that the change you identified did cause some fallout that was fixed
with a later change (below) that looks related to the bad insn you are seeing. 
Maybe this is a bisec issue?  Does adding the later fix from the following
"fix" the ICE?

commit dd75498db79675a1a0b73c25e5f110969ee72d9d
Author: Peter Bergner 
AuthorDate: Thu Apr 16 23:26:41 2020 -0500
Commit: Peter Bergner 
CommitDate: Thu Apr 16 23:26:41 2020 -0500

rs6000: Fix ICE in decompose_normal_address. [PR93974]

Fix an ICE in decompose_normal_address(), which cannot handle Altivec AND:
addresses, by disallowing them via implementing the target hook
rs6000_cannot_substitute_mem_equiv_p.

gcc/
PR rtl-optimization/93974
* config/rs6000/rs6000.c (TARGET_CANNOT_SUBSTITUTE_MEM_EQUIV_P):
Define.
(rs6000_cannot_substitute_mem_equiv_p): New function.

gcc/testsuite/
PR rtl-optimization/93974
* g++.dg/pr93974.C: New test.

If that fixes it, are you really seeing the same ICE on current trunk?

[Bug middle-end/98465] [11 Regression] Bogus -Wstringop-overread with -std=gnu++20 -O2 and std::string::insert

[jakub at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #24 from Jakub Jelinek  ---
Ok, so for GCC 11, can we just help the optimizers a little bit and at the same
time get rid of the warning?
Like:
--- libstdc++-v3/include/bits/basic_string.tcc.jj   2021-01-04
10:26:02.930960956 +0100
+++ libstdc++-v3/include/bits/basic_string.tcc  2021-02-04 17:44:10.592843195
+0100
@@ -477,7 +477,20 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
{
  if (__s + __len2 <= __p + __len1)
this->_S_move(__p, __s, __len2);
+#if _GLIBCXX_HAS_BUILTIN(__builtin_object_size) && defined(__OPTIMIZE__)
+ /* Help the optimizers rule out impossible cases and
+get rid of false positive warnings at the same time.
+If we know the maximum size of the __s object and
+it is shorter than 2 * __len2 - __len1, then
+__s >= __p + __len1 case is impossible.  */
+ else if (!(__builtin_constant_p((2 * __len2 - __len1)
+ * sizeof(_CharT))
+&& __builtin_object_size(__s, 0)
+   < (2 * __len2 - __len1) * sizeof(_CharT))
+  && __s >= __p + __len1)
+#else
  else if (__s >= __p + __len1)
+#endif
this->_S_copy(__p, __s + __len2 - __len1, __len2);
  else
{
I don't get the warning anymore and function size on #c0 testcase shrunk with
-O2 -std=gnu++20 -Wall from 614 bytes to 568.
This code is handling the non-disjunct case, and when __s >= __p + __len1 and
__len1 < __len2, we need to copy from (__s + __len2 - __len1) __len2, i.e. have
access up to __s + 2 * __len2 - __len1 - 1.  If we know that is certainly out
of bounds, most likely it isn't the non-disjunct case at all, but even if it
would, this copying wouldn't be a valid option.

[Bug middle-end/97894] gcc/attr-fnspec.h: 8 * function could be const ?

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #2 from David Binderman  ---
I applied the obvious changes and gcc built fine.

git diff attached.

Re: [PATCH] improve detection of incompatible redeclarations (PR 97882)

[Martin Sebor via Gcc-patches]

On 2/3/21 5:15 PM, Joseph Myers wrote:

On Wed, 3 Feb 2021, Martin Sebor via Gcc-patches wrote:


+/* Return true of T1 and T2 are matching types for the purposes of
+   redeclaring a variable or a function without a prototype (i.e.,
+   considering just its return type).  */


I think this comment is confusing (it suggests it's checking something
looser than the notion of compatibility checked by comptypes, but it's
actually checking something stricter).  But I also think it's wrong to do
anything restricted to the return type.

For example, I think the following should be rejected, as enum E and
unsigned int end up incompatible and quite likely ABI-incompatible.

enum E;
void f(enum E);
void f(unsigned int);
enum E { x = 1ULL << 63 };

Maybe the ICE is specific to the case of return types, but I think the
same rules about type compatibility should apply regardless of precisely
where the incomplete enum type appears.


Ah, it's even more wide-spread than I realized.



I'd expect the natural fix for this PR to involve making
comptypes_internal treat an incomplete enum as incompatible with an
integer type.  Only if that causes too many problems should we then look
at other approaches.



Let me look into it then.

Martin

[Bug middle-end/97894] gcc/attr-fnspec.h: 8 * function could be const ?

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #1 from David Binderman  ---
Created attachment 50128
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50128=edit
git diff

[Bug middle-end/26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)

[jamborm at gcc dot gnu.org via Gcc-bugs]

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

Bug 94400 Summary: 531.deepsjeng_r is 7% slower at -O2 -march=znver2 than GCC 9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94400

   What|Removed |Added

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

[Bug target/94400] 531.deepsjeng_r is 7% slower at -O2 -march=znver2 than GCC 9

[jamborm at gcc dot gnu.org via Gcc-bugs]

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

Martin Jambor  changed:

   What|Removed |Added

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

--- Comment #2 from Martin Jambor  ---
The regression dropped to 1.9% according to my own measurements which also
match LNT (linked above).  It is peculiar to an unusual option combination,
specific to Zen2 (I cannot see it on Zen3 or CascadeLake) and so I think it is
unreasonable to expect that anybody will actually want to work on it.  And the
PR really is mostly fixed, so let me close it as such.