[Bug tree-optimization/95760] New: ivopts with loop variables

[hailey.chiu at sifive dot com]

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

Bug ID: 95760
   Summary: ivopts with loop variables
   Product: gcc
   Version: tree-ssa
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hailey.chiu at sifive dot com
  Target Milestone: ---

C Source:

int **matrix;
int n;
void foo()
{
static int row;
static int col;
static int sum = 0;

for( row = 0 ; row < n ; row++ )
{
for( col = 0 ; col < n ; col++ )
{
sum += matrix[row][col];
}
}
}

Compiling:
$./RISCV-GCC-10.1/bin/riscv64-unknown-elf-gcc foo.c -Os -S -o foo.s
-march=rv32imac -mabi=ilp32

Asm:

foo:
...skip load/store variables...
.L5:
sllia7,a1,2 #row*4 
add a7,t3,a7#matrix + (row*4) 
li  a0,0
.L3:
bgt a5,a0,.L4
addia1,a1,1 #row++
mv  a0,a5
li  a7,1
j   .L2
.L4:
lw  t1,0(a7)
sllit4,a0,2 #col*4
addia0,a0,1 #col++
add t1,t1,t4#*matrix + (col*4)
lw  t1,0(t1)
add a6,a6,t1
li  t1,1
j   .L3

The calculation of matrix offset is not increasing by 4 after each iteration. I
also check that with RISCV-GCC-8.3, it can be emitted code like "add a7, a7, 4"
after each iteration. GCC-10.1 takes two instructions to do this, while GCC-8.3
takes one. I think it might affect code size / performance slightly. 

I am also wondering if "col" can be optimized to the add by 4 operation,
because gcc-8.3 doesn't optimize it too. 

Thanks.

[Bug libstdc++/95759] New: Sized deallocation function can not be matched

[hujiangping at cn dot fujitsu.com]

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

Bug ID: 95759
   Summary: Sized deallocation function can not be matched
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hujiangping at cn dot fujitsu.com
  Target Milestone: ---

Accroding to https://gcc.gnu.org/projects/cxx-status.html#cxx14, sized
dealloction function which is one of C++14 language features should have been
implemented from GCC 5. But, I cann't get the following replaced one matched.

---
#include 
#include 
#include 

void* operator new[](std::size_t sz){
printf("new called\n");
void* m = malloc(sz);
assert(m);
return m;
}

void operator delete[](void*p)noexcept {
printf("usual deallocation called\n");
return free(p);
}

void operator delete[](void*p, std::size_t size)noexcept {
printf("sized deallocation called\n");
return free(p);
}

void test() {
delete[] new int[3];
}

int main() {
test();
}
---

The gcc version and command used are as follow:
---
$ /home/extra_mnt/build_gcc/bin_gcc-master/bin/g++ --version
g++ (GCC) 11.0.0 20200519 (experimental)
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.

$ /home/extra_mnt/build_gcc/bin_gcc-master/bin/g++ --std=c++14 tmp.cpp &&
./a.out
new called
usual deallocation called
---

I guess if the sized deallocation funtion may not replaceable, or there is a
mis-matched bug?

[Bug analyzer/95758] New: -Wanalyzer-use-after-free false positive when compiling glibc regex.c

[eggert at cs dot ucla.edu]

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

Bug ID: 95758
   Summary: -Wanalyzer-use-after-free false positive when
compiling glibc regex.c
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: eggert at cs dot ucla.edu
  Target Milestone: ---

Created attachment 48755
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48755&action=edit
compressed .i file illustrating the -Wanalyzer-use-after-free false positive

When using GCC 10.1.0 -fanalyzer to compile Glibc/Gnulib regex.c I found
several -fanalyzer false positives. Most seem to come from GCC bugs already
reported (Bug#93695, Bug#94458, Bug#94851) but one might be new. To reproduce
the problem on x86-64, uncompress the attached file t4b.i.gz and the compile
t4b.i with the command:

gcc -S -fanalyzer -Wno-analyzer-double-free -Wno-analyzer-malloc-leak
-Wno-analyzer-null-dereference t4b.i

This should be a clean compile, but the output is the following, which is a
false alarm:

t4b.i: In function 'free_charset':
t4b.i:11582:13: warning: use after 'free' of 'cset' [CWE-416]
[-Wanalyzer-use-after-free]
11582 |   free (cset->mbchars);
  | ^
  'rpl_regfree': events 1-4
|
| 7610 | rpl_regfree (regex_t *preg)
|  | ^~~
|  | |
|  | (1) entry to 'rpl_regfree'
|..
| 7613 |   if (__builtin_expect ((dfa !=
|  |  ~
|  |  |
|  |  (2) following 'true' branch...
|..
| 7618 |   free_dfa_content (dfa);
|  |   ~~
|  |   |
|  |   (3) ...to here
|  |   (4) calling 'free_dfa_content' from 'rpl_regfree'
|
+--> 'free_dfa_content': events 5-10
   |
   | 7566 | free_dfa_content (re_dfa_t *dfa)
   |  | ^~~~
   |  | |
   |  | (5) entry to 'free_dfa_content'
   |..
   | 7569 |   if (dfa->nodes)
   |  |  ~
   |  |  |
   |  |  (6) following 'true' branch...
   | 7570 | for (i = 0; i < dfa->nodes_len; ++i)
   |  | ~~~  ~
   |  | |  |
   |  | |  (7) ...to here
   |  | (8) following 'true' branch...
   | 7571 |   free_token (dfa->nodes + i);
   |  |   ~~~
   |  |   |  |
   |  |   |  (9) ...to here
   |  |   (10) calling 'free_token' from 'free_dfa_content'
   |
   +--> 'free_token': events 11-15
  |
  |11648 | free_token (re_token_t *node)
  |  | ^~
  |  | |
  |  | (11) entry to 'free_token'
  |11649 | {
  |11650 |   if (node->type == COMPLEX_BRACKET &&
node->duplicated == 0)
  |  | 
~~~
  |  |  |  |   
   |
  |  |  |  |   
   (13) ...to here
  |  |  |  (14) following
'true' branch...
  |  |  (12) following 'true' branch...
  |11651 | free_charset (node->opr.mbcset);
  |  | ~~~
  |  | |
  |  | (15) ...to here
  |
   <--+
   |
 'free_dfa_content': events 16-19
   |
   | 7570 | for (i = 0; i < dfa->nodes_len; ++i)
   |  | ~~~
   |  | |
   |  | (17) following 'true' branch...
   | 7571 |   free_token (dfa->nodes + i);
   |  |   ^~~
   |  |   |  |
   |  |   |  (18) ...to here
   |  |   (16) returning to 'free_dfa_content' from
'free_token'
   |  |   (19) calling 'free_token' from 'free_dfa_content'
   |
   +--> 'free_token': events 20-24
  |
  |11648 | free_token (re_token_t *node)
  |  | ^~
  |  | |
  |  | (20) entry to 'free_token'
  |11649 | {
  |11650 |   if (node->type == COMPLEX_BRACKET &&
node->duplicated == 0)
  |  | 
~~~
  |  |  |  |   
   |
   

[Bug target/95683] RISC-V: internal compiler error: in riscv_gpr_save_operation_p, at config/riscv/riscv.c:5219

[kito at gcc dot gnu.org]

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

Kito Cheng  changed:

   What|Removed |Added

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

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

[Bug bootstrap/95712] configure-target-libgcc fails on s390x target because xgcc is not being built

[egorenar at linux dot ibm.com]

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

--- Comment #23 from Alexander Egorenkov  ---
I would gladly if i understood the real problem. Sorry i'm not very familiar
with config.guess & config.sub. Could you please elaborate what the problem is
and how it should be fixed ? Thanks

[Bug middle-end/95757] New: [11 regression] missing warning in gcc.dg/Wstringop-overflow-25.c since r11-1517

[seurer at linux dot vnet.ibm.com]

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

Bug ID: 95757
   Summary: [11 regression] missing warning in
gcc.dg/Wstringop-overflow-25.c since r11-1517
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at linux dot vnet.ibm.com
  Target Milestone: ---

g:5acc654e380797bbf402bc3a0a67f9a6ac4c2a83, r11-1517

spawn -ignore SIGHUP /home/seurer/gcc/git/build/gcc-test/gcc/xgcc
-B/home/seurer/gcc/git/build/gcc-test/gcc/
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/Wstringop-overflow-25.c
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never -fdiagnostics-urls=never -O2 -Wall -Wno-array-bounds
-ftrack-macro-expansion=0 -S -o Wstringop-overflow-25.s
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/Wstringop-overflow-25.c: In
function 'test_strcpy_alloca':
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/Wstringop-overflow-25.c:46:3:
warning: '__builtin_memcpy' writing 2 bytes into a region of size between 0 and
1 [-Wstringop-overflow=]
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/Wstringop-overflow-25.c:46:3:
note: at offset 0 to an object with size at most 1 allocated by 'alloca' here
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/Wstringop-overflow-25.c:50:3:
warning: '__builtin_memcpy' writing 3 bytes into a region of size between 1 and
2 [-Wstringop-overflow=]
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/Wstringop-overflow-25.c:50:3:
note: at offset 0 to an object with size between 1 and 2 allocated by 'alloca'
here
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/Wstringop-overflow-25.c:54:3:
warning: '__builtin_memcpy' writing 4 bytes into a region of size between 2 and
3 [-Wstringop-overflow=]
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/Wstringop-overflow-25.c:54:3:
note: at offset 0 to an object with size between 2 and 3 allocated by 'alloca'
here
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/Wstringop-overflow-25.c:55:3:
warning: '__builtin_memcpy' writing 10 bytes into a region of size between 2
and 3 [-Wstringop-overflow=]
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/Wstringop-overflow-25.c:55:3:
note: at offset 0 to an object with size between 2 and 3 allocated by 'alloca'
here
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/Wstringop-overflow-25.c: In
function 'test_strcpy_calloc':
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/Wstringop-overflow-25.c:96:3:
warning: '__builtin_memcpy' writing 3 bytes into a region of size between 1 and
2 [-Wstringop-overflow=]
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/Wstringop-overflow-25.c:96:3:
note: at offset 0 to an object with size between 1 and 2 allocated by 'calloc'
here
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/Wstringop-overflow-25.c:99:3:
warning: '__builtin_memcpy' writing 4 bytes into a region of size between 2 and
3 [-Wstringop-overflow=]
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/Wstringop-overflow-25.c:99:3:
note: at offset 0 to an object with size between 2 and 3 allocated by 'calloc'
here
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/Wstringop-overflow-25.c:103:3:
warning: '__builtin_memcpy' writing 3 bytes into a region of size between 1 and
2 [-Wstringop-overflow=]
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/Wstringop-overflow-25.c:103:3:
note: at offset 0 to an object with size between 1 and 2 allocated by 'calloc'
here
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/Wstringop-overflow-25.c:106:3:
warning: '__builtin_memcpy' writing 4 bytes into a region of size between 2 and
3 [-Wstringop-overflow=]
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/Wstringop-overflow-25.c:106:3:
note: at offset 0 to an object with size between 2 and 3 allocated by 'calloc'
here
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/Wstringop-overflow-25.c:112:3:
warning: '__builtin_memcpy' writing 5 bytes into a region of size between 2 and
4 [-Wstringop-overflow=]
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/Wstringop-overflow-25.c:112:3:
note: at offset 0 to an object with size between 2 and 4 allocated by 'calloc'
here
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/Wstringop-overflow-25.c:118:3:
warning: '__builtin_memcpy' writing 7 bytes into a region of size between 4 and
6 [-Wstringop-overflow=]
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/Wstringop-overflow-25.c:118:3:
note: at offset 0 to an object with size between 4 and 6 allocated by 'calloc'
here
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/Wstringop-overflow-25.c:124:3:
warning: '__builtin_memcpy' writing 5 bytes into a region of size between 2 and
4 [-Wstringop-overflow=]
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/Wstringop-overflow-25.c:124:3:
note: at offset 0 to an object with size between 2 and 4 allocated by 'c

[Bug analyzer/94458] -Wanalyzer-malloc-leak false positive when returning a heap-allocated struct by value holding a heap-allocated pointer

[eggert at cs dot ucla.edu]

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

eggert at cs dot ucla.edu changed:

   What|Removed |Added

 CC||eggert at cs dot ucla.edu

--- Comment #2 from eggert at cs dot ucla.edu ---
I ran into what appear to be several instances of this bug when compiling GNU
coreutils. My instances didn't necessarily involve two allocations; one
sufficed. Here is a stripped-down version of the first instance:

void *malloc (unsigned long);

struct hash_table;
void *hash_insert (struct hash_table *, const void *);

struct di_ent
{
  unsigned long dev;
  struct hash_table *ino_set;
};
struct di_set
{
  struct hash_table *dev_map;
  struct di_ent *probe;
};

void
map_device (struct di_set *dis, unsigned long dev)
{
  struct di_ent *probe = dis->probe;
  if (probe)
{
  if (probe->dev == dev)
return;
}
  else
{
  probe = malloc (sizeof *probe);
  if (!probe)
return;
  dis->probe = probe;
}
  probe->dev = dev;
  struct di_ent *ent = hash_insert (dis->dev_map, probe);
  if (ent == probe)
dis->probe = 0;
}



in the file t3.i, and here is the incorrect output when I compiled with 'gcc
-fanalyzer -S t3.i':

In function 'map_device':
t3.i:36:16: warning: leak of 'probe' [CWE-401] [-Wanalyzer-malloc-leak]
   36 | dis->probe = 0;
  | ~~~^~~
  'map_device': events 1-9
|
|   21 |   if (probe)
|  |  ^
|  |  |
|  |  (1) following 'false' branch (when 'probe' is NULL)...
|..
|   28 |   probe = malloc (sizeof *probe);
|  |   ~~
|  |   |
|  |   (2) ...to here
|  |   (3) allocated here
|   29 |   if (!probe)
|  |  ~
|  |  |
|  |  (4) assuming 'probe' is non-NULL
|  |  (5) following 'false' branch (when 'probe' is
non-NULL)...
|   30 |  return;
|   31 |   dis->probe = probe;
|  |   ~~
|  |  |
|  |  (6) ...to here
|..
|   35 |   if (ent == probe)
|  |  ~
|  |  |
|  |  (7) following 'true' branch (when 'ent == probe')...
|   36 | dis->probe = 0;
|  | ~~
|  ||
|  |(8) ...to here
|  |(9) 'probe' leaks here; was allocated at (3)
|

[Bug target/95756] New: Failure to optimize memory operations with _Complex

[gabravier at gmail dot com]

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

Bug ID: 95756
   Summary: Failure to optimize memory operations with _Complex
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gabravier at gmail dot com
  Target Milestone: ---

float _Complex f()
{
return {0, 0};
}

With -O3, LLVM outputs this :

f(): # @f()
  xorps xmm0, xmm0
  ret

GCC outputs this :

f():
  mov DWORD PTR [rsp-8], 0x
  mov DWORD PTR [rsp-4], 0x
  movq xmm0, QWORD PTR [rsp-8]
  ret

[Bug c/95755] New: GCC 10.1.0 reports bogus sizes in -Werror=format-truncation= error

[jonathan.leffler at gmail dot com]

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

Bug ID: 95755
   Summary: GCC 10.1.0 reports bogus sizes in
-Werror=format-truncation= error
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jonathan.leffler at gmail dot com
  Target Milestone: ---

Created attachment 48754
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48754&action=edit
Preprocessed source (also in body of bug report)

GCC 10.1.0 on an RHEL 7 machine gives an incorrect warning about truncated
output via snprintf, claiming a size that is much bigger than is justified.

Compilation error induced by -Werror shows:

gcc-10.1.0-bug-v2.c: In function ‘mz_format’:
gcc-10.1.0-bug-v2.c:60:48: error: ‘%s’ directive output may be truncated
writing up to 4551 bytes into a region of size 513 [-Werror=format-truncation=]
   60 | snprintf(rcb->mz_url, sizeof(rcb->mz_url), "%s/name/%s/abc1234",
  |^~~~
gcc-10.1.0-bug-v2.c:60:5: note: ‘snprintf’ output between 15 and 8837 bytes
into a destination of size 513
   60 | snprintf(rcb->mz_url, sizeof(rcb->mz_url), "%s/name/%s/abc1234",
  | ^~~~
   61 |  rcred->variant.variant02.az_field11,
  |  
   62 |   rcred->variant.variant02.common01);
  |   ~~
cc1: all warnings being treated as errors

The mz_url member is 513 bytes (that's correct); the format string has 15 bytes
apart from the two %s directives (including the null byte); the field
az_field11 is 129 bytes; the field common01 is 161 bytes; the maximum total
length should be much less than 513 bytes (15 + 128 + 160 = 303), therefore,
and not 8837 bytes, and should not suffer truncation and hence the warning
(error) is bogus.

Version and options:

Using built-in specs.
COLLECT_GCC=gcc
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-10.1.0/configure --prefix=/usr/gcc/v10.1.0
CC=/usr/gcc/v9.3.0/bin/gcc CXX=/usr/gcc/v9.3.0/bin/g++
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.1.0 (GCC) 
COLLECT_GCC_OPTIONS='-O3' '-Wall' '-Werror' '-c' '-v' '-save-temps'
'-mtune=generic' '-march=x86-64'
 /work1/gcc/v10.1.0/bin/../libexec/gcc/x86_64-pc-linux-gnu/10.1.0/cc1 -E -quiet
-v -iprefix /work1/gcc/v10.1.0/bin/../lib/gcc/x86_64-pc-linux-gnu/10.1.0/
gcc-10.1.0-bug-v2.c -mtune=generic -march=x86-64 -Wall -Werror -O3
-fpch-preprocess -o gcc-10.1.0-bug-v2.i
ignoring nonexistent directory
"/work1/gcc/v10.1.0/bin/../lib/gcc/x86_64-pc-linux-gnu/10.1.0/../../../../x86_64-pc-linux-gnu/include"
ignoring duplicate directory
"/work1/gcc/v10.1.0/bin/../lib/gcc/../../lib/gcc/x86_64-pc-linux-gnu/10.1.0/include"
ignoring duplicate directory
"/work1/gcc/v10.1.0/bin/../lib/gcc/../../lib/gcc/x86_64-pc-linux-gnu/10.1.0/include-fixed"
ignoring nonexistent directory
"/work1/gcc/v10.1.0/bin/../lib/gcc/../../lib/gcc/x86_64-pc-linux-gnu/10.1.0/../../../../x86_64-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /work1/gcc/v10.1.0/bin/../lib/gcc/x86_64-pc-linux-gnu/10.1.0/include
 /work1/gcc/v10.1.0/bin/../lib/gcc/x86_64-pc-linux-gnu/10.1.0/include-fixed
 /usr/local/include
 /work1/gcc/v10.1.0/bin/../lib/gcc/../../include
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-O3' '-Wall' '-Werror' '-c' '-v' '-save-temps'
'-mtune=generic' '-march=x86-64'
 /work1/gcc/v10.1.0/bin/../libexec/gcc/x86_64-pc-linux-gnu/10.1.0/cc1
-fpreprocessed gcc-10.1.0-bug-v2.i -quiet -dumpbase gcc-10.1.0-bug-v2.c
-mtune=generic -march=x86-64 -auxbase gcc-10.1.0-bug-v2 -O3 -Wall -Werror
-version -o gcc-10.1.0-bug-v2.s
GNU C17 (GCC) version 10.1.0 (x86_64-pc-linux-gnu)
compiled by GNU C version 10.1.0, GMP version 6.2.0, MPFR version
4.0.2, MPC version 1.1.0, isl version isl-0.18-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C17 (GCC) version 10.1.0 (x86_64-pc-linux-gnu)
compiled by GNU C version 10.1.0, GMP version 6.2.0, MPFR version
4.0.2, MPC version 1.1.0, isl version isl-0.18-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 86d44affd1f923d461a5269e6fdf7b02

Preprocessed output:

# 1 "gcc-10.1.0-bug-v2.c"
# 1 ""
# 1 ""
# 31 ""
# 1 "/usr/include/stdc-predef.h" 1 3 4
# 32 "" 2
# 1 "gcc-10.1.0-bug-v2.c"



# 1 "/work1/gcc/v10.1.0/lib/gcc/x86_64-pc-linux-gnu/10.1.0/include/stddef.h" 1
3 4
# 143 "/work1/gcc/v10.1.0/lib/gcc/x86_64-pc-linux-gnu/10.1.0/include/stddef.h"
3 4

# 143 "/work1/gcc/v10.1.0/lib/gcc/x86_64-pc-linux-gnu/10.1.0/include/stddef.h"
3 4
typedef long int ptrdiff_t;
# 209 "/work1/gcc/v10.1.0/lib/gcc/x86_64-pc-linux-gnu/10.1.0/include/stddef.h"
3

[Bug target/95754] New: Failure to optimize __builtin_ia32_cmpb512_mask with anded first operand, 0 second operand and neq operation

[gabravier at gmail dot com]

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

Bug ID: 95754
   Summary: Failure to optimize __builtin_ia32_cmpb512_mask with
anded first operand, 0 second operand and neq
operation
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gabravier at gmail dot com
  Target Milestone: ---

typedef char v64i8 __attribute__((vector_size(64)));

int64_t f(v64i8 a, v64i8 b)
{
return __builtin_ia32_cmpb512_mask((a & b), (v64i8){0}, 4, -1);
}

This can be optimized to _mm512_test_epi8_mask(a, b). This transformation is
done by LLVM, but not by GCC.

[Bug c++/95568] No CTAD with list initialization within requires-clause

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #4 from Marek Polacek  ---
A patch I've been playing with

--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -28767,7 +28767,11 @@ do_class_deduction (tree ptype, tree tmpl, tree init,
 }

   if (tree guide = maybe_aggr_guide (tmpl, init, args))
-cands = lookup_add (guide, cands);
+{
+  if (dependent_type_p (TREE_TYPE (guide)))
+   return ptype;
+  cands = lookup_add (guide, cands);
+}

   tree call = error_mark_node;

[Bug target/95750] [x86] Use dummy atomic insn instead of mfence in __atomic_thread_fence(seq_cst)

[andysem at mail dot ru]

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

--- Comment #6 from andysem at mail dot ru ---
Also, I think (%%rsp) can be rather far from the top of the stack if the stack
frame is large. This may mean it's less likely to be in data cache. Having a
dummy variable ensures that it is close to the top.

[Bug target/95750] [x86] Use dummy atomic insn instead of mfence in __atomic_thread_fence(seq_cst)

[andysem at mail dot ru]

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

--- Comment #5 from andysem at mail dot ru ---
> Please also read [1] why we avoid -4(%%esp).

I believe, memcheck would complain because the value at -4(%%rsp) would be
uninitialized. This is unfortunate. The workaround could be to initialize it
prior to the atomic operation. This would avoid data dependencies with the
surrounding code.

[Bug c++/95568] No CTAD with list initialization within requires-clause

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #3 from Marek Polacek  ---
So far my guess is that this doesn't work because in a template
finish_decltype_type will create a DECLTYPE_TYPE in the deduction guide, so
we'll have

template X(decltype (X::x))-> X

deduction guide.  type_unification_real then tries to deduce T from a P/A pair
decltype (X::x) and 0.  But:

The non-deduced contexts are:
-- The expression of a decltype-specifier.

and

If a template parameter is used only in non-deduced contexts and is not
explicitly specified, template argument deduction fails.

[Bug fortran/95587] ICE in gfc_target_encode_expr, at fortran/target-memory.c:362

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #3 from anlauf at gcc dot gnu.org ---
Regtests cleanly.  Submitted for review:

https://gcc.gnu.org/pipermail/fortran/2020-June/054554.html

[Bug c/95753] New: ICE when building the Linux Kernel for ARM64 (internal compiler error: ‘global_options’ are modified in local context)

[luis.machado at linaro dot org]

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

Bug ID: 95753
   Summary: ICE when building the Linux Kernel for ARM64 (internal
compiler error: ‘global_options’ are modified in local
context)
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: luis.machado at linaro dot org
  Target Milestone: ---

Created attachment 48753
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48753&action=edit
preprocessed reproduction file

While attempting to build a branch of the Linux Kernel for arm64 (repo is
git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux, branch mte-v4) with
a master GCC, I ran into the following ICE:

---

/kernel/bpf/core.c:1368:1: internal compiler error: ‘global_options’ are
modified in local context

0xc053ab cl_optimization_compare(gcc_options*, gcc_options*)
/gcc-master/gcc/options-save.c:9786
0x78122f handle_optimize_attribute
../../../repos/gcc/gcc/c-family/c-attribs.c:4475
0x6663c7 decl_attributes(tree_node**, tree_node*, int, tree_node*)
../../../repos/gcc/gcc/attribs.c:714
0x688beb start_function(c_declspecs*, c_declarator*, tree_node*)
../../../repos/gcc/gcc/c/c-decl.c:9177
0x6f8543 c_parser_declaration_or_fndef
../../../repos/gcc/gcc/c/c-parser.c:2434
0x7037ff c_parser_external_declaration
../../../repos/gcc/gcc/c/c-parser.c:1773
0x704417 c_parser_translation_unit
../../../repos/gcc/gcc/c/c-parser.c:1646
0x704417 c_parse_file()
../../../repos/gcc/gcc/c/c-parser.c:21822
0x7647e7 c_common_parse_file()
../../../repos/gcc/gcc/c-family/c-opts.c:1190
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

---

The compiler was built with the default configure for aarch64-linux-gnu and I
enabled only the C and C++ languages.

Attached is the preprocessed file, and here's the command line that will
trigger the ICE.

---

gcc -nostdinc -mlittle-endian -DKASAN_SHADOW_SCALE_SHIFT=3 -Wall -Wundef
-Werror=strict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common
-fshort-wchar -fno-PIE -Werror=implicit-function-declaration
-Werror=implicit-int -Wno-format-security -std=gnu89 -mgeneral-regs-only
-DCONFIG_CC_HAS_K_CONSTRAINT=1 -fno-asynchronous-unwind-tables -Wno-psabi
-mabi=lp64 -mbranch-protection=none -DKASAN_SHADOW_SCALE_SHIFT=3
-fno-delete-null-pointer-checks -Wno-frame-address -Wno-format-truncation
-Wno-format-overflow -Wno-address-of-packed-member -O2
-fno-allow-store-data-races -Wframe-larger-than=2048 -fstack-protector-strong
-Wno-unused-but-set-variable -Wimplicit-fallthrough -Wno-unused-const-variable
-fno-omit-frame-pointer -fno-optimize-sibling-calls
-fno-var-tracking-assignments -g -Wdeclaration-after-statement -Wvla
-Wno-pointer-sign -Wno-stringop-truncation -fno-strict-overflow
-fno-merge-all-constants -fmerge-constants -fno-stack-check -c core.i

---

Please let me know if you need more information.

[Bug target/95750] [x86] Use dummy atomic insn instead of mfence in __atomic_thread_fence(seq_cst)

[ubizjak at gmail dot com]

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

--- Comment #4 from Uroš Bizjak  ---
(In reply to Uroš Bizjak from comment #3)
> How about the following patch:

Surely, mfence_nosse needs to be enabled also for
TARGET_USE_XCHG_FOR_ATOMIC_STORE.

> This will generate "lock orl $0, (%rsp)" instead of mfence.

Please also read [1] why we avoid -4(%%esp).

[1] https://gcc.gnu.org/pipermail/gcc-patches/2017-February/469630.html

[Bug target/95750] [x86] Use dummy atomic insn instead of mfence in __atomic_thread_fence(seq_cst)

[ubizjak at gmail dot com]

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

--- Comment #3 from Uroš Bizjak  ---
How about the following patch:

--cut here--
diff --git a/gcc/config/i386/sync.md b/gcc/config/i386/sync.md
index 9ab5456b227..7d9442d45b7 100644
--- a/gcc/config/i386/sync.md
+++ b/gcc/config/i386/sync.md
@@ -117,10 +117,11 @@
   rtx (*mfence_insn)(rtx);
   rtx mem;

-  if (TARGET_64BIT || TARGET_SSE2)
-   mfence_insn = gen_mfence_sse2;
-  else
+  if (!(TARGET_64BIT || TARGET_SSE2)
+ || TARGET_USE_XCHG_FOR_ATOMIC_STORE)
mfence_insn = gen_mfence_nosse;
+  else
+   mfence_insn = gen_mfence_sse2;

   mem = gen_rtx_MEM (BLKmode, gen_rtx_SCRATCH (Pmode));
   MEM_VOLATILE_P (mem) = 1;
--cut here--

This will generate "lock orl $0, (%rsp)" instead of mfence.

[Bug fortran/95587] ICE in gfc_target_encode_expr, at fortran/target-memory.c:362

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 CC||anlauf at gcc dot gnu.org
   Priority|P3  |P4

--- Comment #2 from anlauf at gcc dot gnu.org ---
The ICE is fixed by this patch:

diff --git a/gcc/fortran/match.c b/gcc/fortran/match.c
index 82d2b5087e5..8063fcad295 100644
--- a/gcc/fortran/match.c
+++ b/gcc/fortran/match.c
@@ -5700,6 +5700,11 @@ gfc_match_equivalence (void)

  if (!gfc_add_in_equivalence (&sym->attr, sym->name, NULL))
goto cleanup;
+ if (sym->ts.type == BT_CLASS
+ && CLASS_DATA (sym)
+ && !gfc_add_in_equivalence (&CLASS_DATA (sym)->attr,
+ sym->name, NULL))
+   goto cleanup;

  if (sym->attr.in_common)
{

Haven't tested this thoroughly yet.

[Bug middle-end/92814] missing -Wstringop-overflow writing into a dynamically allocated flexible array member

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
 Resolution|--- |FIXED
 Status|NEW |RESOLVED
   Target Milestone|--- |11.0
  Known to fail||10.1.0

--- Comment #2 from Martin Sebor  ---
Fixed in r11-1517.

[Bug c++/69698] [meta-bug] flexible array members

[msebor at gcc dot gnu.org]

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

Bug 92814 Summary: missing -Wstringop-overflow writing into a dynamically 
allocated flexible array member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92814

   What|Removed |Added

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

[Bug tree-optimization/88443] [meta-bug] bogus/missing -Wstringop-overflow warnings

[msebor at gcc dot gnu.org]

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

Bug 92814 Summary: missing -Wstringop-overflow writing into a dynamically 
allocated flexible array member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92814

   What|Removed |Added

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

[Bug tree-optimization/95752] New: Failure to optimize complicated usage of __builtin_ctz with conditionals properly

[gabravier at gmail dot com]

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

Bug ID: 95752
   Summary: Failure to optimize complicated usage of __builtin_ctz
with conditionals properly
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gabravier at gmail dot com
  Target Milestone: ---

unsigned long f(uint64_t value)
{
unsigned int result;

if ((value & 0x) == 0)
{
result = __builtin_ctz(value >> 32) + 32;
}
else
{
if ((unsigned int)value != 0)
result = __builtin_ctz((unsigned int)value);
}

return result;
}

With -O3 -mbmi, LLVM outputs this :

f(unsigned long):
  mov rax, rdi
  shr rax, 32
  tzcnt ecx, eax
  or ecx, 32
  tzcnt eax, edi
  cmovb eax, ecx
  ret

GCC outputs this :

f(unsigned long):
  test edi, edi
  jne .L2

  shr rdi, 32
  xor eax, eax
  tzcnt eax, edi
  add eax, 32
  mov eax, eax
  ret

.L2:
  xor edx, edx
  mov eax, 0
  tzcnt edx, edi
  test edi, edi
  cmovne eax, edx
  mov eax, eax
  ret

This may be related to how GCC handles undefined behaviour in relation to
`__builtin_ctz` and uninitialized variables, but this still seems like it could
be heavily optimized. At least, it could emit something like this if the
`cmovcc` is not the best behaviour here :

f(unsigned long):
  test edi, edi
  jne .L2

  shr rdi, 32
  tzcnt eax, edi
  add eax, 32
  ret

.L1:
  tzcnt eax, edi
  ret

Using this code :

unsigned long f(uint64_t value)
{
unsigned int result;

if ((value & 0x) == 0)
{
result = __builtin_ctz(value >> 32) + 32;
}
else
{
if ((unsigned int)value != 0)
result = __builtin_ctz((unsigned int)value);
else
__builtin_unreachable();
}

return result;
}

(i.e. adding __builtin_unreachable where an undefined value is created)
generates better code :

f(unsigned long):
  xor eax, eax
  tzcnt eax, edi
  test edi, edi
  jne .L3
  shr rdi, 32
  tzcnt edi, edi
  lea eax, [rdi+32]
.L3:
  mov eax, eax
  ret

This looks like something tree-ssa optimizers could do (inserting
__builtin_unreachable when invoking UB through usage of undefined values) since
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94861 indicates that GCC doesn't
do this even for the simplest cases (and, looking at tree dumps, tree-ssa
doesn't look like it makes any assumptions on the initial value of variables).

[Bug c++/95726] ICE with aarch64 __Float32x4_t as template argument

[jason at gcc dot gnu.org]

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

--- Comment #6 from Jason Merrill  ---
(In reply to rsand...@gcc.gnu.org from comment #4)
> (In reply to Jakub Jelinek from comment #3)
> > But if they mangle differently, then structural_comptypes shouldn't treat
> > them as same types.

Definitely.

> That certainly avoids the ICE, and makes GCC's behaviour consistent
> with Clang for things like:
> 
>   typedef float vecf __attribute__((vector_size(16)));
>   vecf x;
>   float32x4_t &y = x;
> 
> Previously we accepted this, with the struct_comptypes change
> we reject it (like Clang does).  But that might break existing
> code, so I'm not sure it would be backportable.

If necessary we could add a conversion between the pointer-to-vector types.

> I guess the question then is: what does TYPE_STRUCTURAL_EQUALITY_P
> mean for VECTOR_TYPEs in the context of structural_comptypes?

The same thing it means for any other type: setting TYPE_CANONICAL properly is
too hard, so use structural_comptypes.

> And (if this is a different question) what case is that function's
> VECTOR_TYPE handling for?  I.e. when do we want to return true for
> a pair of VECTOR_TYPEs whose TYPE_MAIN_VARIANTs are different?

We want to return true if they should be considered the same type.

Generally, TYPE_MAIN_VARIANT isn't sufficient for checking type identity, as it
only looks through variants of the outermost type:  If I have

typedef int myint;
typedef myint* myintptr;

taking TYPE_MAIN_VARIANT of myintptr gives myint*, not int*.  That's why
TYPE_CANONICAL was introduced, so we didn't need to do structural comparison
whenever we wanted to compare types.

[Bug target/95751] New: [aarch64] Consider using ldapr for __atomic_load_n(acquire) on ARMv8.3-RCPC

[andysem at mail dot ru]

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

Bug ID: 95751
   Summary: [aarch64] Consider using ldapr for
__atomic_load_n(acquire) on ARMv8.3-RCPC
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: andysem at mail dot ru
  Target Milestone: ---

ARMv8.3-RCPC extension adds new ldapr[b/h] instructions for Load-AcquirePC
semantics that better matches C++ memory order semantics.

In particular, the core ldar instructions will wait until the previous stlr,
even on another address, completes on the same thread. The newer ldapr does not
wait for the previous stlr to complete, unless it is performed on the same
address.

Consider using these new instructions in __atomic_load_n(consume/acquire) when
-march=armv8.3 or higher is specified. Note that __atomic_load_n(relaxed) and
__atomic_load_n(seq_cst) should stay unchanged.

[Bug c++/95568] No CTAD with list initialization within requires-clause

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #2 from Marek Polacek  ---
The problem seems to be not that we're in a require-clause but that we're in a
template, the following is also rejected:

template struct X { T x; };
template void g () { X{0}; }

[Bug target/95750] [x86] Use dummy atomic insn instead of mfence in __atomic_thread_fence(seq_cst)

[andysem at mail dot ru]

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

--- Comment #2 from andysem at mail dot ru ---
gcc 10.1 only optimizes __atomic_store_n(seq_cst) to xchg, but not the fence.

Also, consider applying the same optimization to __sync_synchronize().

[Bug target/95750] [x86] Use dummy atomic insn instead of mfence in __atomic_thread_fence(seq_cst)

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Depends on||91719

--- Comment #1 from Andrew Pinski  ---
PR 91719 says this was fixed in GCC 10.1.0


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91719
[Bug 91719] gcc compiles seq_cst store on x86-64 differently from clang/icc

[Bug target/95750] New: [x86] Use dummy atomic insn instead of mfence in __atomic_thread_fence(seq_cst)

[andysem at mail dot ru]

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

Bug ID: 95750
   Summary: [x86] Use dummy atomic insn instead of mfence in
__atomic_thread_fence(seq_cst)
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: andysem at mail dot ru
  Target Milestone: ---

Currently, __atomic_thread_fence(seq_cst) on x86 and x86-64 generates mfence
instruction. A dummy atomic instruction (a lock-prefixed instruction or xchg
with a memory operand) would provide the same sequential consistency guarantees
while being more efficient on most current CPUs. The mfence instruction
additionally orders non-temporal stores, which is not relevant for atomic
operations and are not ordered by seq_cst atomic operations anyway.

Regarding performance, some data is available in Agner Fog's instruction
tables:

https://www.agner.org/optimize/

Also, there is this article:

https://shipilev.net/blog/2014/on-the-fence-with-dependencies/

TL;DR: There is benefit on every CPU except Atom; on Atom there is no
difference.

Regarding the dummy instruction and target memory location, here are some
considerations:

- The lock-prefixed instruction should preferably not alter flags or registers
and should require minimum number of registers.
- The memory location should not be shared with other threads.
- The memory location should likely be in cache.
- The memory location should not alias existing data on the stack, so that we
don't introduce a false data dependency on previous or subsequent instructions.

Based on the above, a good candidate is "lock not" on a dummy variable on the
top of the stack. Note that the variable would be accessible through esp/rsp,
it is likely to be in hot memory and is likely thread-private.

I've implemented this optimization in Boost.Atomic, and a similar optimization
is done in MSVC:

https://github.com/microsoft/STL/pull/740

[Bug middle-end/95746] ice during GIMPLE pass: reassoc

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
 Ever confirmed|0   |1
 CC||marxin at gcc dot gnu.org
   Last reconfirmed||2020-06-18

--- Comment #2 from Martin Liška  ---
Should be fixed on master, can you please re-check?

[Bug tree-optimization/95745] [11 regression] O3-pr85794.c fails since r11-1445-g502d63b6d6141597bb18fd23c87736a1b384cf8f

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|ASSIGNED|WAITING

--- Comment #2 from Martin Liška  ---
Should be fixed on master, can you please re-check?

[Bug libstdc++/95749] std::filesystem::file_size returns wrong size for large files on Windows

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2020-06-18
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
 Ever confirmed|0   |1
  Component|c++ |libstdc++

[Bug tree-optimization/95745] [11 regression] O3-pr85794.c fails since r11-1445-g502d63b6d6141597bb18fd23c87736a1b384cf8f

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Last reconfirmed||2020-06-18
 Status|UNCONFIRMED |ASSIGNED
 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Mine. Can you please add the author of a problematic commit to CC next time?

[Bug bootstrap/95712] configure-target-libgcc fails on s390x target because xgcc is not being built

[pinskia at gcc dot gnu.org]

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

--- Comment #22 from Andrew Pinski  ---
(In reply to Alexander Egorenkov from comment #21)
> Could you please point me to the bug report it was moved to ? Thanks

Can you file it?  Well they don't have a bug database, just an email list:
Report bugs and patches to .

[Bug c++/95749] New: std::filesystem::file_size returns wrong size for large files on Windows

[reiter.christoph at gmail dot com]

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

Bug ID: 95749
   Summary: std::filesystem::file_size returns wrong size for
large files on Windows
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: reiter.christoph at gmail dot com
  Target Milestone: ---

Downstream report: https://github.com/msys2/MINGW-packages/issues/6585



#include 
#include 
#include 
#include 
#include 

int main(int argc, char** argv)
{

uint64_t std_filesystem_file_size;
uint64_t std_fstream_file_size;
std::filesystem::path sourceFile = std::filesystem::current_path() /
"example_3GiB.bin";

std::ofstream ofs(sourceFile);
ofs << "this is some text in the new file\n";
ofs.close();

std::filesystem::resize_file(sourceFile,3221225472);
std_filesystem_file_size = std::filesystem::file_size(sourceFile);

std::ifstream in(sourceFile.string(), std::ifstream::ate |
std::ifstream::binary);
std_fstream_file_size = in.tellg();

std::cout << "3 GiB file:" << std::endl;
std::cout << "std_filesystem_file_size: " << std_filesystem_file_size <<
std::endl;
std::cout << "std_fstream_file_size: " << std_fstream_file_size <<
std::endl;
return 0;
}



$ g++ -std=c++17 a.cpp
$ ./a.exe
3 GiB file:
std_filesystem_file_size: 18446744072635809792
std_fstream_file_size: 3221225472



The first value is wrong. My uneducated guess would be that
https://github.com/gcc-mirror/gcc/blob/41d6b10e96a1de98e90a7c0378437c3255814b16/libstdc%2B%2B-v3/src/filesystem/ops-common.h#L66
should use _wstat64() instead of _wstat and stat_type should be _stat64 instead
of _stat, otherwise things are limited to 32bit.

See
https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/stat-functions?view=vs-2019
for details.

[Bug c++/95639] wrong error location

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #3 from Marek Polacek  ---
Not that trivial because it breaks -fdiagnostics-generate-patch.

[Bug middle-end/92814] missing -Wstringop-overflow writing into a dynamically allocated flexible array member

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:5acc654e380797bbf402bc3a0a67f9a6ac4c2a83

commit r11-1517-g5acc654e380797bbf402bc3a0a67f9a6ac4c2a83
Author: Martin Sebor 
Date:   Thu Jun 18 12:00:36 2020 -0600

Avoid warning for memset writing over multiple members.

Resolves:
PR middle-end/95667 - unintended warning for memset writing across multiple
members
PR middle-end/92814 - missing -Wstringop-overflow writing into a
dynamically allocated flexible array member

gcc/ChangeLog:

PR middle-end/95667
PR middle-end/92814
* builtins.c (compute_objsize): Remove call to
compute_builtin_object_size and instead compute conservative sizes
directly here.

gcc/testsuite/ChangeLog:

PR middle-end/95667
PR middle-end/92814
* gcc.dg/Wstringop-overflow-25.c: Remove xfails.
* gcc.dg/Wstringop-overflow-39.c: New test.

[Bug middle-end/95667] [11 Regression] unintended warning for memset writing across multiple members

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:5acc654e380797bbf402bc3a0a67f9a6ac4c2a83

commit r11-1517-g5acc654e380797bbf402bc3a0a67f9a6ac4c2a83
Author: Martin Sebor 
Date:   Thu Jun 18 12:00:36 2020 -0600

Avoid warning for memset writing over multiple members.

Resolves:
PR middle-end/95667 - unintended warning for memset writing across multiple
members
PR middle-end/92814 - missing -Wstringop-overflow writing into a
dynamically allocated flexible array member

gcc/ChangeLog:

PR middle-end/95667
PR middle-end/92814
* builtins.c (compute_objsize): Remove call to
compute_builtin_object_size and instead compute conservative sizes
directly here.

gcc/testsuite/ChangeLog:

PR middle-end/95667
PR middle-end/92814
* gcc.dg/Wstringop-overflow-25.c: Remove xfails.
* gcc.dg/Wstringop-overflow-39.c: New test.

[Bug target/95748] New: Long long function parameter should be aligned to 32 bit on x86.

[skpgkp2 at gmail dot com]

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

Bug ID: 95748
   Summary: Long long function parameter should be aligned to 32
bit on x86.
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: skpgkp2 at gmail dot com
CC: hjl.tools at gmail dot com
  Target Milestone: ---

Long long function parameter should be aligned to 32 bit on x86 target.

$ cat paramtest.c
void foo(int x, long long p)
{
if (__alignof__(p) != 4 )
  __builtin_abort();
}
int bar()
{
foo(4,5);
return 0;
}
int main()
{
return(bar());
}

$ gcc -m32 paramtest.c
$ ./a.out
Aborted (core dumped)

[Bug bootstrap/95712] configure-target-libgcc fails on s390x target because xgcc is not being built

[egorenar at linux dot ibm.com]

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

--- Comment #21 from Alexander Egorenkov  ---
Could you please point me to the bug report it was moved to ? Thanks

[Bug tree-optimization/95747] New: [OpenMP/Builtin] nontemporal store support

[jed at 59A2 dot org]

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

Bug ID: 95747
   Summary: [OpenMP/Builtin] nontemporal store support
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jed at 59A2 dot org
  Target Milestone: ---

My understanding is that GCC currently has no analog of Clang's
__builtin_nontemporal_store
(https://clang.llvm.org/docs/LanguageExtensions.html#non-temporal-load-store-builtins)
and I don't see a ticket to add support for OpenMP-5's pragma omp simd
nontemporal. This leaves developers stuck with needing intrinsics to generate
vmovntpd and related instructions. Proper use of nontemporal stores can make
circa 50% performance improvement in bandwidth-limited workloads.

[Bug bootstrap/95712] configure-target-libgcc fails on s390x target because xgcc is not being built

[egorenar at linux dot ibm.com]

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

--- Comment #20 from Alexander Egorenkov  ---
(In reply to Andrew Pinski from comment #19)
> This is a config.sub issue where the vendor is always rest/set to ibm. Not
> directly a gcc issue.  Gcc does not maintain config.sub.

Ok, sorry, thank you :)

[Bug bootstrap/95712] configure-target-libgcc fails on s390x target because xgcc is not being built

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |MOVED
 Status|UNCONFIRMED |RESOLVED

--- Comment #19 from Andrew Pinski  ---
This is a config.sub issue where the vendor is always rest/set to ibm. Not
directly a gcc issue.  Gcc does not maintain config.sub.

[Bug c++/95726] ICE with aarch64 __Float32x4_t as template argument

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Dunno, perhaps for backporting it could be done in template_args_equal instead?
Like I said, it would probably need to handle also POINTER/REFERENCE/ARRAY_TYPE
whose ultimate element type is VECTOR_TYPE possibly affected by this.
Dunno about aggregates, I'd hope we set TYPE_CANONICAL for most of them and
therefore shouldn't care about this.
If comptypes returns false for these, can one still implicitly convert them to
the other vector types?
Does 32-bit ARM have similar types too?
Anyway, your questions are more for Jason...

[Bug middle-end/95746] ice during GIMPLE pass: reassoc

[dcb314 at hotmail dot com]

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

--- Comment #1 from David Binderman  ---
The bug doesn't seem to occur on raspberry pi 4, with config string
arm-linux-gnueabihf.

[Bug c++/95746] New: ice during GIMPLE pass: reassoc

[dcb314 at hotmail dot com]

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

Bug ID: 95746
   Summary: ice during GIMPLE pass: reassoc
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

For C++ testsuite case ./g++.dg/other/vector-compare.C
on flag -O3 -march=native, recent gcc trunk does this:

$ /home/pi/gcc/results/bin/g++ -c -O3 -march=native
./g++.dg/other/vector-compare.C
during GIMPLE pass: reassoc
./g++.dg/other/vector-compare.C: In function 'long long int f(v4f*, const
v4f*)':
./g++.dg/other/vector-compare.C:21:1: internal compiler error: Segmentation
fault
   21 | f (v4f *x, v4f const *y)
  | ^
0x8db2e3 crash_signal
../../trunk.git/gcc/toplev.c:328
0x76c3511f ???
../sysdeps/unix/sysv/linux/arm/sigrestorer.S:64
0x5f0513 gsi_replace_with_seq(gimple_stmt_iterator*, gimple*, bool)
../../trunk.git/gcc/gimple-iterator.c:474
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

native is Raspberry PI 3+, so armv7l-unknown-linux-gnueabihf

[Bug libstdc++/71096] std::get did not work for nested derived classes from std::tuple if one element is empty

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
 Status|NEW |ASSIGNED
   Target Milestone|--- |11.0

[Bug c/95722] libatomic crashes on __atomic_load of const object

[joseph at codesourcery dot com]

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

--- Comment #3 from joseph at codesourcery dot com  ---
See bugs 70490 and 84563 regarding atomic_load of const.

The atomic_load generic function takes a pointer-to-const-atomic argument 
just like any other library function that takes an argument it does not 
modify.  It's certainly valid to do an atomic load through such a pointer 
in a case where the original object was not defined as const but a pointer 
to const was passed to the function doing the load.

The question is whether it is or should be valid in the case where the 
object was defined as const.  If it is, that would constrain code 
sequences used in any case where the compiler cannot see that the object 
definitely isn't in read-only memory, including for other operations that 
might only be valid for writable memory but need to interact correctly 
with atomic_load.

[Bug c++/95726] ICE with aarch64 __Float32x4_t as template argument

[rsandifo at gcc dot gnu.org]

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

--- Comment #4 from rsandifo at gcc dot gnu.org  
---
(In reply to Jakub Jelinek from comment #3)
> But if they mangle differently, then structural_comptypes shouldn't treat
> them as same types.
That certainly avoids the ICE, and makes GCC's behaviour consistent
with Clang for things like:

  typedef float vecf __attribute__((vector_size(16)));
  vecf x;
  float32x4_t &y = x;

Previously we accepted this, with the struct_comptypes change
we reject it (like Clang does).  But that might break existing
code, so I'm not sure it would be backportable.

I guess the question then is: what does TYPE_STRUCTURAL_EQUALITY_P
mean for VECTOR_TYPEs in the context of structural_comptypes?
And (if this is a different question) what case is that function's
VECTOR_TYPE handling for?  I.e. when do we want to return true for
a pair of VECTOR_TYPEs whose TYPE_MAIN_VARIANTs are different?

[Bug target/95347] rs6000 mcpu=future generating stfs instead of pstfs for pc-relative references

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:6e81b0cf4ff75f65edfd2d83bfa2933f35ae66af

commit r10-8325-g6e81b0cf4ff75f65edfd2d83bfa2933f35ae66af
Author: Aaron Sawdey 
Date:   Wed Jun 17 15:35:55 2020 -0500

identify lfs prefixed case PR95347

The same problem also arises for plfs where prefixed_load_p()
doesn't recognize it so we get just lfs in the asm output
with an @pcrel address.

Backport from master
2020-06-03  Aaron Sawdey  

PR target/95347
* config/rs6000/rs6000.c (is_stfs_insn): Rename to
is_lfs_stfs_insn and make it recognize lfs as well.
(prefixed_store_p): Use is_lfs_stfs_insn().
(prefixed_load_p): Use is_lfs_stfs_insn() to recognize lfs.

[Bug target/95347] rs6000 mcpu=future generating stfs instead of pstfs for pc-relative references

[cvs-commit at gcc dot gnu.org]

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

--- Comment #5 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Aaron Sawdey
:

https://gcc.gnu.org/g:541e8c4dac11fce933a7f9fa7d865abf8d6496f7

commit r10-8324-g541e8c4dac11fce933a7f9fa7d865abf8d6496f7
Author: Aaron Sawdey 
Date:   Wed Jun 17 15:32:53 2020 -0500

Correctly identify stfs if prefixed

Because reg_to_non_prefixed() only looks at the register being used, it
doesn't get the right answer for stfs, which leads to us not seeing
that it has a PCREL symbol ref.  This patch works around this by
introducing a helper function that inspects the insn to see if it is in
fact a stfs. Then if we use NON_PREFIXED_DEFAULT, address_to_insn_form()
can see that it has the PCREL symbol ref.

Backport from master
2020-06-02  Aaron Sawdey  

PR target/95347
* config/rs6000/rs6000.c (prefixed_store_p): Add special case
for stfs.
(is_stfs_insn): New helper function.

[Bug c++/95735] ICE on invalid non-type template argument

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #5 from Marek Polacek  ---
Fixed.

[Bug c++/95735] ICE on invalid non-type template argument

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:5421fae8b17c7401f3a4ac5b9f414a47f7bda379

commit r11-1516-g5421fae8b17c7401f3a4ac5b9f414a47f7bda379
Author: Marek Polacek 
Date:   Thu Jun 18 09:38:42 2020 -0400

c++: ICE in requires-expressions with invalid args [PR95735]

This ICE-on-invalid goes back to GCC 6.  In finish_template_variable,
if coerce_innermost_template_parms returns error_mark_node, we pass
it down to constraints_satisfied_p and that error_mark_node flows
down to various satisfy_* functions and then to various tsubst_*
functions, where we crash.  diagnose_constraints also doesn't cope
with error arglist, so I think we should just return as in the
patch below.

gcc/cp/ChangeLog:

PR c++/95735
* pt.c (finish_template_variable): Return if
coerce_innermost_template_parms return error_mark_node.

gcc/testsuite/ChangeLog:

PR c++/95735
* g++.dg/cpp2a/concepts-err2.C: New test.

[Bug c++/95736] coroutine method improperly copies awaitable

[lewissbaker.opensource at gmail dot com]

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

Lewis Baker  changed:

   What|Removed |Added

 CC||lewissbaker.opensource@gmai
   ||l.com

--- Comment #1 from Lewis Baker  ---
I've also investigated this a bit more and have annotated the assembly of the
code being generated by GCC in this example (slightly modified).

https://godbolt.org/z/_HJNHC

Immediately before the 'co_await foo' expression the compiler generates
a copy of the this->foo member into the coroutine frame. But it does
this doing the equivalent of a memcpy() rather than calling the
copy-constructor.

The compiler should not be making this copy of the operand to 'co_await'
and should instead be passing the address of the 'this->foo' member to the
as the implicit object parameter in the call to
await_ready/await_suspend/await_resume.

[Bug middle-end/95667] [11 Regression] unintended warning for memset writing across multiple members

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #2 from Martin Sebor  ---
Patch: https://gcc.gnu.org/pipermail/gcc-patches/2020-June/548511.html

[Bug c++/95735] ICE on invalid non-type template argument

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org
   Keywords||patch

--- Comment #3 from Marek Polacek  ---
Posted.

[Bug c++/95744] Duplicate error message in a simple decltype specifier

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-06-18
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Confirmed.

[Bug tree-optimization/95745] New: [11 regression] O3-pr85794.c fails since r11-1445-g502d63b6d6141597bb18fd23c87736a1b384cf8f

[clyon at gcc dot gnu.org]

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

Bug ID: 95745
   Summary: [11 regression] O3-pr85794.c fails since
r11-1445-g502d63b6d6141597bb18fd23c87736a1b384cf8f
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: clyon at gcc dot gnu.org
  Target Milestone: ---

Hi,

Since r11-1445-g502d63b6d6141597bb18fd23c87736a1b384cf8f I have noticed that 
O3-pr85794.c fails on arm:
FAIL: gcc.dg/vect/O3-pr85794.c (internal compiler error)
FAIL: gcc.dg/vect/O3-pr85794.c (test for excess errors)
Excess errors:
during RTL pass: expand
/gcc/testsuite/gcc.dg/vect/O3-pr85794.c:7:1: internal compiler error: in
do_store_flag, at expr.c:12247
0x8fe346 do_store_flag
/gcc/expr.c:12247
0x8ff3c1 expand_expr_real_2(separate_ops*, rtx_def*, machine_mode,
expand_modifier)
/gcc/expr.c:9610
0x7bd97a expand_gimple_stmt_1
/gcc/cfgexpand.c:3787
0x7bd97a expand_gimple_stmt
/gcc/cfgexpand.c:3847
0x7bfadd expand_gimple_basic_block
/gcc/cfgexpand.c:5888
0x7c1c50 execute
/gcc/cfgexpand.c:6572


Many other ICEs appeared between r11-1409 and r11-1457 which are probably
caused by the same commit:
gcc.dg/vect/O3-pr85794.c (internal compiler error)
gcc.dg/vect/bb-slp-43.c (internal compiler error)
gcc.dg/vect/bb-slp-43.c -flto -ffat-lto-objects (internal compiler error)
gcc.dg/vect/bb-slp-cond-1.c (internal compiler error)
gcc.dg/vect/bb-slp-cond-1.c -flto -ffat-lto-objects (internal compiler
error)
gcc.dg/vect/bb-slp-pattern-2.c (internal compiler error)
gcc.dg/vect/bb-slp-pattern-2.c -flto -ffat-lto-objects (internal compiler
error)
gcc.dg/vect/bb-slp-pr92596.c (internal compiler error)
gcc.dg/vect/bb-slp-pr92596.c -flto -ffat-lto-objects (internal compiler
error)
gcc.dg/vect/pr18308.c (internal compiler error)
gcc.dg/vect/pr18308.c -flto -ffat-lto-objects (internal compiler error)
gcc.dg/vect/pr24059.c (internal compiler error)
gcc.dg/vect/pr24059.c -flto -ffat-lto-objects (internal compiler error)
gcc.dg/vect/pr51000.c (internal compiler error)
gcc.dg/vect/pr51000.c -flto -ffat-lto-objects (internal compiler error)
gcc.dg/vect/pr51581-3.c (internal compiler error)
gcc.dg/vect/pr51581-3.c -flto -ffat-lto-objects (internal compiler error)
gcc.dg/vect/pr51581-4.c (internal compiler error)
gcc.dg/vect/pr51581-4.c -flto -ffat-lto-objects (internal compiler error)
gcc.dg/vect/pr56625.c (internal compiler error)
gcc.dg/vect/pr56625.c -flto -ffat-lto-objects (internal compiler error)
gcc.dg/vect/pr59519-2.c (internal compiler error)
gcc.dg/vect/pr59519-2.c -flto -ffat-lto-objects (internal compiler error)
gcc.dg/vect/pr59591-1.c (internal compiler error)
gcc.dg/vect/pr59591-1.c -flto -ffat-lto-objects (internal compiler error)
gcc.dg/vect/pr62075.c (internal compiler error)
gcc.dg/vect/pr62075.c -flto -ffat-lto-objects (internal compiler error)
gcc.dg/vect/pr63605.c (internal compiler error)
gcc.dg/vect/pr63605.c -flto -ffat-lto-objects (internal compiler error)
gcc.dg/vect/pr65947-1.c (internal compiler error)
gcc.dg/vect/pr65947-1.c -flto -ffat-lto-objects (internal compiler error)
gcc.dg/vect/pr65947-12.c (internal compiler error)
gcc.dg/vect/pr65947-12.c -flto -ffat-lto-objects (internal compiler error)
gcc.dg/vect/pr65947-13.c (internal compiler error)
gcc.dg/vect/pr65947-13.c -flto -ffat-lto-objects (internal compiler error)
gcc.dg/vect/pr65947-14.c (internal compiler error)
gcc.dg/vect/pr65947-14.c -flto -ffat-lto-objects (internal compiler error)
gcc.dg/vect/pr65947-2.c (internal compiler error)
gcc.dg/vect/pr65947-2.c -flto -ffat-lto-objects (internal compiler error)
gcc.dg/vect/pr65947-3.c (internal compiler error)
gcc.dg/vect/pr65947-3.c -flto -ffat-lto-objects (internal compiler error)
gcc.dg/vect/pr65947-4.c (internal compiler error)
gcc.dg/vect/pr65947-4.c -flto -ffat-lto-objects (internal compiler error)
gcc.dg/vect/pr65947-6.c (internal compiler error)
gcc.dg/vect/pr65947-6.c -flto -ffat-lto-objects (internal compiler error)
gcc.dg/vect/pr68305.c (internal compiler error)
gcc.dg/vect/pr68305.c -flto -ffat-lto-objects (internal compiler error)
gcc.dg/vect/pr69820.c (internal compiler error)
gcc.dg/vect/pr69820.c -flto -ffat-lto-objects (internal compiler error)
gcc.dg/vect/pr71259.c -flto -ffat-lto-objects (internal compiler error)
gcc.dg/vect/pr72866.c (internal compiler error)
gcc.dg/vect/pr72866.c -flto -ffat-lto-objects (internal compiler error)
gcc.dg/vect/pr80631-1.c (internal compiler error)
gcc.dg/vect/pr80631-1.c -flto -ffat-lto-objects (internal compiler error)
gcc.dg/vect/pr80631-2.c (internal compiler error)
gcc.dg/vect/pr806

[Bug rtl-optimization/87600] Fix for PRs 86939 and 87479 causes build issues for several targets

[segher at gcc dot gnu.org]

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

--- Comment #9 from Segher Boessenkool  ---
(In reply to Alexandre Oliva from comment #8)
> I've noticed regressions caused by make_more_copies, in scenarios that used
> subreg s for the low part of promoted incoming parms.  With hard regs, the
> substitution into a subreg became a reg, but with a pseudo, it remains a
> subreg, which prevents further combines in some cases, as in e.g.
> gcc_target/powerpc/20050603-3.c on ppc64.

That happens because of the zero_extract problems.  The only thing
make_more_copies has to do with this is that this change exposes this
problem on this testcase.

> I thought one way to go about it could be to scan for subregs of pseudos
> copied from hard regs before introducing the additional copies, and
> introduce the intermediate pseudo with the widest subreg mode if there
> aren't uses of the full pseudo.

Usually we want the *smallest* possible mode for pseudos.  This is
important to get good optimisation.

[Bug c++/95744] New: Duplicate error message in a simple decltype specifier

[haoxintu at gmail dot com]

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

Bug ID: 95744
   Summary: Duplicate error message in a simple decltype specifier
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: haoxintu at gmail dot com
CC: mpolacek at gcc dot gnu.org, redi at gcc dot gnu.org
  Target Milestone: ---

The test.cc includes a very simple valid decltype specifier with an undeclared
variable(I am definitely sure), but GCC emits two duplicated error messages on
it.

$cat test.cc
decltype(var) i = 100;

$g++-trunk -c -w test.cc
test.cc:1:10: error: ‘var’ was not declared in this scope
1 | decltype(var) i = 100;
  |  ^~~
test.cc:1:10: error: ‘var’ was not declared in this scope

While in clang

$clang++ -c -w test.cc
test.cc:1:10: error: use of undeclared identifier 'var'
decltype(var) i = 100;
 ^
1 error generated.


My GCC version is

$g++-trunk --version
g++ (GCC) 11.0.0 20200605 (experimental)
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.

[Bug testsuite/95706] New test case gfortran.dg/pr95690.f90 fails

[clyon at gcc dot gnu.org]

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

Christophe Lyon  changed:

   What|Removed |Added

 CC||clyon at gcc dot gnu.org

--- Comment #4 from Christophe Lyon  ---
Seen on arm and aarch64 too.

[Bug target/95734] [11 regression] lots of ICEs after r11-1445

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #3 from Martin Liška  ---
Fixed.

[Bug fortran/95743] New: [9/10 Regression] bogus recursive call to nonrecursive procedure with -fcheck=recursion

[antoine.lemo...@bordeaux-inp.fr]

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

Bug ID: 95743
   Summary: [9/10 Regression] bogus recursive call to nonrecursive
procedure with -fcheck=recursion
   Product: gcc
   Version: 9.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: antoine.lemo...@bordeaux-inp.fr
  Target Milestone: ---

I was able to reproduce the closed bug #80361 with gfortran 9.3.0 and 10.1.0
using the following code:

program test_recursive_call 
   implicit none

   type t_tree_node
  type(t_tree_node), dimension(:), allocatable :: child
   end type

   type t_tree
  type(t_tree_node), allocatable :: root
   end type

   type(t_tree), allocatable :: tree

   allocate(tree)
   allocate(tree%root)
   allocate(tree%root%child(1))
   ! If the line below is removed, the code works fine. 
   allocate(tree%root%child(1)%child(1))
   deallocate(tree)
end program

Command line to compile the code:
gfortran -g -fcheck=recursion -o tree tree.f90

I obtain the following runtime error:

At line 1 of file tree.f90
Fortran runtime error: Recursive call to nonrecursive procedure
'__deallocate_test_recursive_call_T_tree_node'

Error termination. Backtrace:
#0  0x5623824511fb in __deallocate_test_recursive_call_T_tree_node
at /home//fortran/test_gcc_ice2/tree.f90:1
#1  0x562382451302 in __deallocate_test_recursive_call_T_tree_node
at /home//fortran/test_gcc_ice2/tree.f90:1
#2  0x562382451b95 in test_recursive_call
at /home//fortran/test_gcc_ice2/tree.f90:18
#3  0x562382452230 in main
at /home//fortran/test_gcc_ice2/tree.f90:19

It works fine without -fcheck=recursion.

[Bug c++/95741] Optimization skips destructor and calls terminate directly

[mpoulhies at kalray dot eu]

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

--- Comment #3 from Marc POULHIÈS  ---
 Yes you are right, sorry. Mistake caused by previous change in the title...

[Bug tree-optimization/67282] Wrong code with -floop-nest-optimize

[mpoulhies at kalray dot eu]

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

Marc POULHIÈS  changed:

   What|Removed |Added

 CC||mpoulhies at kalray dot eu

--- Comment #4 from Marc POULHIÈS  ---
Yes you're right sorry, mistake from a previous change !

[Bug c++/95741] Optimization skips destructor and calls set_terminate directly

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
I assume the bug summary is a typo, and you meant to say "Optimization skips
destructor and calls terminate directly", right?

[Bug c++/95735] ICE on invalid non-type template argument

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #2 from Marek Polacek  ---
The second test ICEs with gcc 6 too.

Patch:
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -10154,6 +10154,8 @@ finish_template_variable (tree var, tsubst_flags_t
complain)
   arglist = coerce_innermost_template_parms (parms, arglist, templ, complain,
 /*req_all*/true,
 /*use_default*/true);
+  if (arglist == error_mark_node)
+return error_mark_node;

   if (flag_concepts && !constraints_satisfied_p (templ, arglist))
 {

[Bug c++/95741] Optimization skips destructor and calls set_terminate directly

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2020-06-18

--- Comment #1 from Jonathan Wakely  ---
[except.terminate] allows std::terminate to be called without stack unwinding
in some cases, but I don't think that applies here. The standard specifically
says "An implementation is not permitted to finish stack unwinding prematurely
based on a determination that the unwind process will eventually cause a call
to std::terminate()." That seems to be what's happening here.

[Bug c++/95742] Bad error message in parsing a function with "decltype()"

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
(In reply to Haoxin Tu from comment #0)
> This code test.cc, I think it's not a garbage input for GCC,

That's debatable.

> I guess GCC might can not recognize the function definition correctly?

That's not a valid function definition though, that's why GCC doesn't recognize
it.

[Bug target/95730] GCN offloading ICEs after commit fe7ebef7fe4f9acb79658ed9db0749b07efc3105 "Add support for __builtin_bswap128"

[ams at gcc dot gnu.org]

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

--- Comment #3 from Andrew Stubbs  ---
The GCN port does not define a scalar_mode_supported, and I think the default
definition is allowing TImode (as long long int). As I said, the SLP
fake-vector load/store use it fine as a substitute for V4SI or V2DI.

Probably this is a bug we should fix. I've been planning to implement
additional vector sizes, so I can fold this fix into that work and not regress
anything in SLP (hopefully).

[Bug c++/95742] Bad error message in parsing a function with "decltype()"

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Priority|P3  |P5
 Status|UNCONFIRMED |NEW
 CC||mpolacek at gcc dot gnu.org
   Last reconfirmed||2020-06-18

--- Comment #1 from Marek Polacek  ---
I suppose in this case there's some room for improvement, but very low prio.

[Bug c++/95742] New: Bad error message in parsing a function with "decltype()"

[haoxintu at gmail dot com]

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

Bug ID: 95742
   Summary: Bad error message in parsing a function with
"decltype()"
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: haoxintu at gmail dot com
CC: redi at gcc dot gnu.org
  Target Milestone: ---

This code test.cc, I think it's not a garbage input for GCC, but it parses
badly and emits some confusing error messages.

$cat test.cc

int foo( decltype(),int) { } 

$g++-trunk -c -w test.cc
test.cc:1:19: error: expected primary-expression before ‘)’ token
1 | int foo( decltype(),int)  { }
  |   ^
test.cc:1:10: error: expected primary-expression before ‘decltype’
1 | int foo( decltype(),int)  { }
  |  ^~
test.cc:1:21: error: expected primary-expression before ‘int’
1 | int foo( decltype(),int)  { }
  | ^~~
test.cc:1:24: error: expression list treated as compound expression in
initializer [-fpermissive]
1 | int foo( decltype(),int)  { }
  |^

While in Clang
$clang++ -c -w test.cc
test.cc:1:19: error: expected expression
int foo( decltype(),int)  { } 
  ^
1 error generated.


When I change the code into test1.cc, GCC get following results:

$cat test1.cc
void foo( decltype(),int) { } 

$g++-trunk -c -w test1.cc
test1.cc:1:6: error: variable or field ‘foo’ declared void
1 | void foo( decltype(),int)  { }
  |  ^~~
test1.cc:1:20: error: expected primary-expression before ‘)’ token
1 | void foo( decltype(),int)  { }
  |^
test1.cc:1:11: error: expected primary-expression before ‘decltype’
1 | void foo( decltype(),int)  { }
  |   ^~
test1.cc:1:22: error: expected primary-expression before ‘int’
1 | void foo( decltype(),int)  { }

This time GCC emits "error: variable or field ‘foo’ declared void"?

Also in Clang

$clang++ -c -w test1.cc
test1.cc:1:20: error: expected expression
void foo( decltype(),int)  { } 
   ^
1 error generated.

I guess GCC might can not recognize the function definition correctly?

[Bug c++/95726] ICE with aarch64 __Float32x4_t as template argument

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

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

[Bug middle-end/95739] [11 Regression] Unordered comparison and VEC_COND_EXPR

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |11.0

[Bug middle-end/95739] [11 Regression] Unordered comparison and VEC_COND_EXPR

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r11-1510-geccc3d432669ba272229d49f015cb986df21eb0a
Author: Richard Biener 
Date:   Thu Jun 18 14:45:03 2020 +0200

middle-end/95739 - fix vector condition IFN expansion

This fixes the omission of moving the expansion result to the
target.

2020-06-18  Richard Biener  

PR middle-end/95739
* internal-fn.c (expand_vect_cond_optab_fn): Move the result
to the target if necessary.
(expand_vect_cond_mask_optab_fn): Likewise.

[Bug middle-end/95739] [11 Regression] Unordered comparison and VEC_COND_EXPR

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #4 from Richard Biener  ---
Fixed.

[Bug target/95734] [11 regression] lots of ICEs after r11-1445

[dje at gcc dot gnu.org]

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

David Edelsohn  changed:

   What|Removed |Added

 CC||dje at gcc dot gnu.org
   Host|powerpc64*-linux-gnu|powerpc*-*-8
 Target|powerpc64*-linux-gnu|powerpc*-*-*
  Build|powerpc64*-linux-gnu|powerpc*-*-*

--- Comment #2 from David Edelsohn  ---
Same on AIX.

[Bug c++/95728] [11 Regression] tree check: expected tree_list, have error_mark in tsubst_copy_and_build, at cp/pt.c:19594

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #4 from Marek Polacek  ---
Fixed.

[Bug bootstrap/95712] configure-target-libgcc fails on s390x target because xgcc is not being built

[egorenar at linux dot ibm.com]

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

Alexander Egorenkov  changed:

   What|Removed |Added

 Resolution|INVALID |---
 Status|RESOLVED|UNCONFIRMED

--- Comment #18 from Alexander Egorenkov  ---
I reopened the problem because i reproduced this w/o buildroot and
--host,--target and --build configure options.

[Bug c++/95728] [11 Regression] tree check: expected tree_list, have error_mark in tsubst_copy_and_build, at cp/pt.c:19594

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:81caacc273399c91ae3182021ad87bc2ba786039

commit r11-1507-g81caacc273399c91ae3182021ad87bc2ba786039
Author: Marek Polacek 
Date:   Wed Jun 17 19:23:10 2020 -0400

c++: Fix tsubst ICE with invalid static_cast [PR95728]

Since r11-423 tsubst_copy_and_build/TREE_LIST uses tsubst_tree_list
instead of open coding it.  While the latter could return an error
node wrapped in a TREE_LIST, the former can return a naked error node.

That broke in tsubst_copy_and_build/NEW_EXPR:
  tree placement = RECUR (TREE_OPERAND (t, 0));
  // placement is now error_mark_node, so...
  for (; placement != NULL_TREE; placement = TREE_CHAIN (placement))
  // ... this crashes

If we just return, we avoid the ICE and improve the diagnostic a bit.

gcc/cp/ChangeLog:

PR c++/95728
* pt.c (tsubst_copy_and_build) : Return
error_mark_node
if placement is erroneous.

gcc/testsuite/ChangeLog:

PR c++/95728
* g++.dg/template/cast6.C: New test.

[Bug c++/95741] New: Optimization removes call to set_terminate in destructor

[mpoulhies at kalray dot eu]

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

Bug ID: 95741
   Summary: Optimization  removes call to set_terminate in
destructor
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpoulhies at kalray dot eu
  Target Milestone: ---

The following code has different executions in O0 and O3.
It looks like GCC is able to optimize the `throw s` in `test()` by calling
`terminate()` directly as it knows the destructor will raise an exception:

```
terminate called after throwing an instance of 'int'
Aborted
```

But without optimization, the destructor will be executed and the
`set_terminate` function will hook `my_term` and the program will return 0.

I'm not sure if this is a valid optimization and the original code is wrong, or
if the code is valid.

I've tried with various GCC version from 7.5 to 10.1.0.

#include 
#include 

int test ( void );

void my_term ( void )
{
  // only way to exit SUCCESS
  _exit(0);
}

int main(void)
{
  test ();

  // unreachable
  return 1;
}


struct S1 {
public:
  ~S1 (  ) noexcept (false)
  {
// moving this outside of ~S1 (eg. in main()) makes the program behave
// consistently for O0~O3
std::set_terminate(&my_term);

// this should trigger the terminate() as we are throwing in a dtor called
// during exception handling ?
throw 1;
  };
};


int test(void)
{
  try
{
  int s = 0;
  S1  ss;

  // this should trigger the dtor for ss
  throw s;

  // unreachable
  return -1;
}
  catch ( ... ) {
// unreachable
return -1;
  }
}

[Bug c++/95724] bogue error : "expected '{' before ')' token"

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Biener  ---
(In reply to Jonathan Wakely from comment #6)
> (In reply to Richard Biener from comment #4)
> > Note the testcase does not ICE so ice-on-invalid is wrong.  It's really
> > a diagnostic only.  If we want sth extra to distinguish error diagnostics
> > from warning diagnostics then we should add one (can't come up with a good
> > name right now)
> 
> It's like a weaker form of error-recovery but for cases that don't ICE.

error-recovery is fine then I guess since it doens't imply ICEing.  We
use the combo of ice-on-invalid-code, error-recovery for that.  But indeed
the description says 'use only for ice-on-invalid-code' ...

> cascading-errors maybe.

[Bug target/95740] Failure to avoid using the stack when interpreting a float as an integer when it is modified afterwards

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2020-06-18
   Keywords||ra

--- Comment #1 from Richard Biener  ---
;; return _1;

(insn 6 5 7 (parallel [
(set (reg:SI 86)
(plus:SI (subreg:SI (reg/v:SF 85 [ p ]) 0)
(const_int 1 [0x1])))
(clobber (reg:CC 17 flags))
]) "t.c":5:5 -1
 (nil))

(insn 7 6 8 (set (reg:SI 84 [  ])
(reg:SI 86)) "t.c":6:12 -1
 (nil))


Initial RTL couldn't be better...  but then LRA chooses to spill rather
than try a direct xmm->grp move.  -mtune=intel didn't help here (for
generic we IIRC avoid such moves)

[Bug middle-end/95739] [11 Regression] Unordered comparison and VEC_COND_EXPR

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Component|tree-optimization   |middle-end
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Status|NEW |ASSIGNED

--- Comment #2 from Richard Biener  ---
Hmm, the vectorizer emits

  vect_cst__41 = { 0.0, 0.0 };
  vect_cst__42 = { -1.0e+0, -1.0e+0 };
...
  vect__1.7_37 = MEM  [(double *)vectp_s1.5_35];
  _1 = s1[i_23];
  vect__2.10_40 = MEM  [(double *)vectp_s2.8_38];
  _2 = s2[i_23];
  _43 = vect__1.7_37 u<= vect__2.10_40;
  vect_iftmp.11_44 = VEC_COND_EXPR <_43, vect_cst__41, vect_cst__42>;
  iftmp.0_5 = _1 u<= _2 ? 0.0 : -1.0e+0;

but this is __builtin__isgreaterequal (s1[i], s2[i]) ? 0:0 : -1.0; already
this way from if-conversion it seems.  Before we have

  if (_1 u<= _2)
goto ; [50.00%]
  else
goto ; [50.00%]

   [local count: 429496729]:
  goto ; [100.00%]

   [local count: 429496728]:

   [local count: 858993457]:
  # iftmp.0_5 = PHI <-1.0e+0(4), 0.0(10)>

And even .original:

s3[i] = s1[i] u<= s2[i] ? 0.0 : -1.0e+0;

but that's the inverted condition plus swapped which should be u>=!?

Seemingly this is generated from

 /* !A ? B : C -> A ? C : B.  */
 (simplify
  (cnd (logical_inverted_value truth_valued_p@0) @1 @2)
  (cnd @0 @2 @1)))

fed by !(s1[i] u<= s2[i]) ? -1. : 0.  Hmm, which looks OK.

later the backend via ix86_prepare_sse_fp_compare_args correctly (!?)
swaps operands of the compare to s2[i] u>= s1[i].

Now somewhere things go wrong and the __builtin_isgreater vanishes completely,
leaving us with uninitialized stack slots:

main:
.LFB0:
.cfi_startproc
subq$120, %rsp
.cfi_def_cfa_offset 128
movapd  .LC0(%rip), %xmm0
movaps  %xmm0, s1(%rip)
movapd  .LC1(%rip), %xmm0
movaps  %xmm0, s1+16(%rip)
movapd  .LC2(%rip), %xmm0
movaps  %xmm0, s2(%rip)
movaps  %xmm0, s2+16(%rip)
movsd   56(%rsp), %xmm0
movapd  48(%rsp), %xmm1
movapd  96(%rsp), %xmm2
movsd   %xmm0, 8(%rsp)
movsd   .LC4(%rip), %xmm0
ucomisd 8(%rsp), %xmm0
movaps  %xmm1, s3(%rip)
movaps  %xmm2, s3+16(%rip)

I guess the issue is

   31: r104:V2DF=unge(r103:V2DF,[r77:DI-0x60])
   32: r101:V2DF=~r104:V2DF&r102:V2DF
   33: r105:DI=`s3'
   34: r106:V2DF=[r77:DI-0x40]
   35: [r105:DI]=r106:V2DF

look at how we compute the result into r101 but then use [r77:D1-0x40]
as source for the store.  When I trace expand_vect_cond_optab_fn
I see 'target' is expanded to

(mem/c:V2DF (plus:DI (reg/f:DI 77 virtual-stack-vars)
(const_int -64 [0xffc0])) [1 vect_iftmp.11+0 S16 A128])

but we don't check whether ops[0].value matches target after expand_insn
and fail to move it there.

testing patch.

[Bug c++/95724] bogue error : "expected '{' before ')' token"

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  ---
(In reply to Richard Biener from comment #4)
> Note the testcase does not ICE so ice-on-invalid is wrong.  It's really
> a diagnostic only.  If we want sth extra to distinguish error diagnostics
> from warning diagnostics then we should add one (can't come up with a good
> name right now)

It's like a weaker form of error-recovery but for cases that don't ICE.

cascading-errors maybe.

[Bug c++/95659] Inconsistent error message in "default argument missing for parameter"

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
(In reply to Haoxin Tu from comment #0)
> $cat bug.cc
> int a;
> long  foo1 ( void  = a, double  param2 ,decltype (auto) param3 = a){ }
> long  foo2 ( void  = a, double  param2){ }
> 
> In gcc-trunk
> $g++-trunk -w -c -std=c++14 bug.cc 
> bug.cc:2:41: error: cannot declare a parameter with ‘decltype(auto)’
> 2 | long  foo1 ( void  = a, double  param2 ,decltype (auto) param3 = a){
> }
>   | ^~~
> bug.cc:2:14: error: invalid use of type ‘void’ in parameter declaration
> 2 | long  foo1 ( void  = a, double  param2 ,decltype (auto) param3 = a){
> }
>   |  ^

The first two errors are correct, the function declaration is complete garbage
and these errors correctly identify some of the problems.

Whether it *also* notices another error in this garbage doesn't really matter.
You need to fix this nonsense before the code can be compiled anyway.

The general rule of thumb is always to start by fixing the first errors,
because they might be causing the later ones. If you fix those two errors, then
G++ will  tell you about the next problem.

It's not really helpful to keep pointing out that if you randomly generate
complete garbage then GCC gets confused.

[Bug c++/95725] Confusing error diagnostic in an invalid template

[redi at gcc dot gnu.org]

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

--- Comment #10 from Jonathan Wakely  ---
(In reply to Haoxin Tu from comment #7)
> By the way, can you take a look at bug 95597 and bug 95659? I think GCC
> should accept the first case and shouldn't miss the error message in the
> second code. 
> Those cases are different from this report.

I've confirmed bug 95597, that's a real bug.

Bug 95659 is just more garbage.

[Bug c++/95597] bogus error: "expected nested-name-specifier "

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-06-18
 Ever confirmed|0   |1

[Bug c++/95725] Confusing error diagnostic in an invalid template

[redi at gcc dot gnu.org]

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

--- Comment #9 from Jonathan Wakely  ---
(In reply to Haoxin Tu from comment #6)
> Hi, there.
> 
> I hold the view that the compiler should have good fault tolerance, which
> means giving an input(even invalid), the compiler might emit appropriate
> error message diagnostics so that we can fix them into valid code according
> to the diagnostics. 

In an ideal world, yes. But this testcase is complete garbage. Nobody is going
to accidentally write that and be unable to see what's wrong with the code when
they get an error.

We could spend time giving perfect diagnostics for unrealistic garbage, or do
more useful things.

> I have tested in both GCC and Clang, the results show that GCC has lots of
> unrelated diagnostic messages than Clang. 

They're not unrelated, they're all directly related to the error in the code.

> In this report, GCC-trunk seems ok, but GCC-9 emits too many duplicated
> error messages. So I guess there might something not correct in FE.

So it's already fixed then.

> Finally, I am wondering if those cases are useful for the GCC community?

This particular case is not useful.

[Bug rtl-optimization/87600] Fix for PRs 86939 and 87479 causes build issues for several targets

[aoliva at gcc dot gnu.org]

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

Alexandre Oliva  changed:

   What|Removed |Added

 CC||aoliva at gcc dot gnu.org

--- Comment #8 from Alexandre Oliva  ---
I've noticed regressions caused by make_more_copies, in scenarios that used
subreg s for the low part of promoted incoming parms.  With hard regs, the
substitution into a subreg became a reg, but with a pseudo, it remains a
subreg, which prevents further combines in some cases, as in e.g.
gcc_target/powerpc/20050603-3.c on ppc64.

I thought one way to go about it could be to scan for subregs of pseudos copied
from hard regs before introducing the additional copies, and introduce the
intermediate pseudo with the widest subreg mode if there aren't uses of the
full pseudo.

[Bug target/94735] MVE vector load/store pair getting removed with -O2.

[sripar01 at gcc dot gnu.org]

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

SRINATH PARVATHANENI  changed:

   What|Removed |Added

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

--- Comment #3 from SRINATH PARVATHANENI  ---
Committed patch to trunk and gcc-10.

[Bug target/94959] Wrong code gen for MVE intrinsics vldrbq_s32 which fails with assembler `Error: lo register required`

[sripar01 at gcc dot gnu.org]

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

SRINATH PARVATHANENI  changed:

   What|Removed |Added

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

--- Comment #3 from SRINATH PARVATHANENI  ---
Committed patch to trunk and backported to GCC-10.

[Bug target/95740] New: Failure to avoid using the stack when interpreting a float as an integer when it is modified afterwards

[gabravier at gmail dot com]

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

Bug ID: 95740
   Summary: Failure to avoid using the stack when interpreting a
float as an integer when it is modified afterwards
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gabravier at gmail dot com
  Target Milestone: ---

int32_t f(float p)
{
int32_t tmp;
memcpy(&tmp, &p, sizeof(float));
++tmp;
return tmp;
}

With -O3, LLVM outputs this :

f(float):
  movd eax, xmm0
  add eax, 1
  ret

GCC outputs this :

f(float):
  movd DWORD PTR [rsp-4], xmm0
  mov eax, 1
  add eax, DWORD PTR [rsp-4]
  ret

[Bug target/95713] [10/11 Regression] ICE in emit_move_insn when converting int2 vector to short2 vector for -march=skylake-avx512 since r10-5031-g78307657cf9675bc

[cvs-commit at gcc dot gnu.org]

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

--- Comment #8 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Jakub Jelinek
:

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

commit r10-8323-g0c7d18d51a8e9abd085afd0b01743662fd0419fa
Author: Jakub Jelinek 
Date:   Thu Jun 18 12:08:06 2020 +0200

forwprop: simplify_vector_constructor follow-up fix [PR95713]

As the following testcase shows, the exception for the aarch64
vec_pack_trunc_di is not sufficient on x86, the halfvectype
"vectors" have SImode but the x86 vec_pack_trunc_si meant for
the bool bitmasks combines 2x SImode into DImode, while in the
testcase the halfvectype is 1x SImode "vector" with SImode and
result is 2x HImode "vector" with SImode.

Richard Sandiford's reply:
FWIW, since the aarch64 case was only found by inspection and might
not be useful, personally I'd prefer to drop that case after all.

2020-06-18  Jakub Jelinek  

PR target/95713
* tree-ssa-forwprop.c (simplify_vector_constructor): Don't allow
scalar mode halfvectype other than vector boolean for
VEC_PACK_TRUNC_EXPR.

* gcc.dg/pr95713.c: New test.

(cherry picked from commit 9a875db43cd4210843c480c8df26a1d6624d057d)

[Bug c/95699] __builtin_constant_p inconsistencies

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r11-1504-g2e0f4a18bc978c73624dd016e4cce229c2809c9c
Author: Jakub Jelinek 
Date:   Thu Jun 18 12:11:09 2020 +0200

phiopt: Improve minmax optimization [PR95699]

As discussed in the PR, the
x < 0x8000U to (int) x >= 0
optimization stands in the way of minmax_replacement optimization,
so for comparisons with most of the constants it works well, but when the
above mentioned optimization triggers, it is unable to do it.
The match.pd (cond (cmp (convert? x) c1) (op x c2) c3) -> (op (minmax x c1)
c2)
optimization is able to look through that and this patch
teaches minmax_replacement about it too.

2020-06-18  Jakub Jelinek  

PR tree-optimization/95699
* tree-ssa-phiopt.c (minmax_replacement): Treat (signed int)x < 0
as x > INT_MAX and (signed int)x >= 0 as x <= INT_MAX.  Move
variable
declarations to the statements that set them where possible.

* gcc.dg/tree-ssa/pr95699.c: New test.

[Bug target/95713] [10/11 Regression] ICE in emit_move_insn when converting int2 vector to short2 vector for -march=skylake-avx512 since r10-5031-g78307657cf9675bc

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:9a875db43cd4210843c480c8df26a1d6624d057d

commit r11-1503-g9a875db43cd4210843c480c8df26a1d6624d057d
Author: Jakub Jelinek 
Date:   Thu Jun 18 12:08:06 2020 +0200

forwprop: simplify_vector_constructor follow-up fix [PR95713]

As the following testcase shows, the exception for the aarch64
vec_pack_trunc_di is not sufficient on x86, the halfvectype
"vectors" have SImode but the x86 vec_pack_trunc_si meant for
the bool bitmasks combines 2x SImode into DImode, while in the
testcase the halfvectype is 1x SImode "vector" with SImode and
result is 2x HImode "vector" with SImode.

Richard Sandiford's reply:
FWIW, since the aarch64 case was only found by inspection and might
not be useful, personally I'd prefer to drop that case after all.

2020-06-18  Jakub Jelinek  

PR target/95713
* tree-ssa-forwprop.c (simplify_vector_constructor): Don't allow
scalar mode halfvectype other than vector boolean for
VEC_PACK_TRUNC_EXPR.

* gcc.dg/pr95713.c: New test.

[Bug tree-optimization/95739] New: [11 Regression] Unordered comparison and VEC_COND_EXPR

[marxin at gcc dot gnu.org]

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

Bug ID: 95739
   Summary: [11 Regression] Unordered comparison and VEC_COND_EXPR
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: rguenth at gcc dot gnu.org
  Target Milestone: ---

The following is a fallout of
r11-1445-g502d63b6d6141597bb18fd23c87736a1b384cf8f but it seems to me a latent
issue:

$ cat pr50310.c
double s1[4], s2[4], s3[64];

int
main ()
{
  s1[0] = __builtin_nan ("");
  s1[1] = 6.0;
  s1[2] = 6.0;
  s1[3] = 6.0;

  s2[0] = 5.0;
  s2[1] = 5.0;
  s2[2] = 5.0;
  s2[3] = 5.0;

  asm volatile ("" : : : "memory");
  for (int i = 0; i < 4; i++)
s3[i] = __builtin_isgreater (s1[i], s2[i]) ? -1.0 : 0.0;

  if (s3[1] != -1.0)
__builtin_abort ();
  return 0;
}

$ gcc pr50310.c -O3 -ffloat-store && ./a.out 
Aborted (core dumped)

The thing is that we newly generate:
--- good2020-06-18 12:08:56.901799621 +0200
+++ bad 2020-06-18 12:08:54.137825794 +0200
@@ -1,39 +1,43 @@

-;; Function main (main, funcdef_no=0, decl_uid=1937, cgraph_uid=1,
symbol_order=3) (executed once)
+;; Function main (main, funcdef_no=0, decl_uid=1933, cgraph_uid=1,
symbol_order=3) (executed once)

 main ()
 {
   vector(2) double vect_iftmp.11;
   vector(2) double vect__2.10;
   vector(2) double vect__1.7;
+  vector(2)  _4;
   double _14;
+  vector(2)  _43;

[local count: 214748371]:
   MEM  [(double *)&s1] = {  Nan, 6.0e+0 };
   MEM  [(double *)&s1 + 16B] = { 6.0e+0, 6.0e+0 };
   MEM  [(double *)&s2] = { 5.0e+0, 5.0e+0 };
   MEM  [(double *)&s2 + 16B] = { 5.0e+0, 5.0e+0 };
   __asm__ __volatile__("" :  :  : "memory");
   vect__1.7_5 = MEM  [(double *)&s1];
   vect__2.10_19 = MEM  [(double *)&s2];
-  vect_iftmp.11_4 = VEC_COND_EXPR ;
-  MEM  [(double *)&s3] = vect_iftmp.11_4;
+  _4 = vect__1.7_5 u<= vect__2.10_19;
+  vect_iftmp.11_33 = .VCOND (vect__1.7_5, vect__2.10_19, { 0.0, 0.0 }, {
-1.0e+0, -1.0e+0 }, 117);
+  MEM  [(double *)&s3] = vect_iftmp.11_33;
   vect__1.7_37 = MEM  [(double *)&s1 + 16B];
   vect__2.10_40 = MEM  [(double *)&s2 + 16B];
-  vect_iftmp.11_43 = VEC_COND_EXPR ;
-  MEM  [(double *)&s3 + 16B] = vect_iftmp.11_43;
-  _14 = BIT_FIELD_REF ;
+  _43 = vect__1.7_37 u<= vect__2.10_40;
+  vect_iftmp.11_44 = .VCOND (vect__1.7_37, vect__2.10_40, { 0.0, 0.0 }, {
-1.0e+0, -1.0e+0 }, 117);
+  MEM  [(double *)&s3 + 16B] = vect_iftmp.11_44;
+  _14 = BIT_FIELD_REF ;
   if (_14 != -1.0e+0)
 goto ; [0.00%]
   else
 goto ; [100.00%]

[count: 0]:
   __builtin_abort ();

[local count: 214748368]:
   return 0;

 }

Looking at the assembly the comparison is somehow gone:
diff -u good.s bad.s
--- good.s  2020-06-18 12:09:52.385274181 +0200
+++ bad.s   2020-06-18 12:09:54.013258763 +0200
@@ -19,31 +19,14 @@
movapd  .LC2(%rip), %xmm0
movaps  %xmm0, s2(%rip)
movaps  %xmm0, s2+16(%rip)
-   movapd  s2(%rip), %xmm3
-   movapd  s1(%rip), %xmm2
-   movapd  .LC3(%rip), %xmm1
-   movapd  s2+16(%rip), %xmm6
-   movaps  %xmm3, 48(%rsp)
-   movapd  48(%rsp), %xmm0
-   movapd  s1+16(%rip), %xmm5
-   movaps  %xmm2, 32(%rsp)
-   cmpnltpd32(%rsp), %xmm0
-   movaps  %xmm6, 80(%rsp)
-   movaps  %xmm5, 64(%rsp)
-   andnpd  %xmm1, %xmm0
-   movaps  %xmm0, 16(%rsp)
-   movapd  80(%rsp), %xmm0
-   movapd  16(%rsp), %xmm4
-   cmpnltpd64(%rsp), %xmm0
-   movaps  %xmm4, s3(%rip)
-   andnpd  %xmm1, %xmm0
-   movaps  %xmm0, 96(%rsp)
-   movsd   24(%rsp), %xmm0
-   movapd  96(%rsp), %xmm7
+   movsd   56(%rsp), %xmm0
+   movapd  48(%rsp), %xmm1
+   movapd  96(%rsp), %xmm2
movsd   %xmm0, 8(%rsp)
movsd   .LC4(%rip), %xmm0
ucomisd 8(%rsp), %xmm0
-   movaps  %xmm7, s3+16(%rip)
+   movaps  %xmm1, s3(%rip)
+   movaps  %xmm2, s3+16(%rip)
jp  .L4
comisd  8(%rsp), %xmm0
jne .L4
@@ -107,16 +90,10 @@
.long   1075052544
.long   0
.long   1075052544
-   .align 16
-.LC3:
-   .long   0
-   .long   -1074790400
-   .long   0
-   .long   -1074790400
.section.rodata.cst8,"aM",@progbits,8
.align 8
 .LC4:
.long   0
.long   -1074790400
-   .ident  "GCC: (SUSE Linux) 10.1.1 20200507 [revision
dd38686d9c810cecbaa80bb82ed91caaa58ad635]"
+   .ident  "GCC: (GNU) 11.0.0 20200618 (experimental)"
.section.note.GNU-stack,"",@progbits

[Bug tree-optimization/95739] [11 Regression] Unordered comparison and VEC_COND_EXPR

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2020-06-18

--- Comment #1 from Martin Liška  ---
@Richi: Do you have a hint what went wrong?

[Bug tree-optimization/95738] New: Failure to optimize comparison of float after sign xor to unsigned comparison

[gabravier at gmail dot com]

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

Bug ID: 95738
   Summary: Failure to optimize comparison of float after sign xor
to unsigned comparison
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gabravier at gmail dot com
  Target Milestone: ---

typedef int64_t v2i64 __attribute__((vector_size(16)));
typedef uint64_t v2u64 __attribute__((vector_size(16)));

v2i64 f(v2i64 a, v2i64 b)
{
auto sign = (v2i64){(int64_t)0x8000u,
(int64_t)0x8000u};
return (a ^ sign) > (b ^ sign);
}

This can be optimized to `(v2u64)a > (v2u64)b`. This transformation is done by
LLVM, but not by GCC.

[Bug bootstrap/95712] configure-target-libgcc fails on s390x target because xgcc is not being built

[egorenar at linux dot ibm.com]

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

--- Comment #17 from Alexander Egorenkov  ---
(In reply to Andrew Pinski from comment #13)
> (In reply to Andreas Schwab from comment #11)
> > > generated for aarch64-linux-gnu that I configured for and it has:
> > 
> > You have used --disable-bootstrap.
> 
> No I did not, --disable-bootstrap is the default for the case where we are
> doing cross.
> 
> OH I did not notice it was s390 to s390 cross building but buildroot is not
> handling that case correctly.  Rather it is thinking it is always building a
> cross even when build==host==target .
> 
> > --build=s390x-ibm-linux-gnu --host=s390x-buildroot-linux-gnu 
> > --target=s390x-buildroot-linux-gnu
> 
> That is broken.  This is not a cross compiler but rather a build of the
> native gcc and therefor is not the correct options.
> 
> So the problem is rather how buildroot is not doing the right configure
> options to gcc for building a cross build.  NOT A BUG.

But i did not use those configure options in my test.
And now i also removed option "--target=" in my test and it is still failing
with the same problem. I'm not talking about buildroot, i got rid of it. Please
see my test.

Thanks