[Bug libstdc++/95832] std::vector specialization leading std::variant ctor treating it as int rather than bool

[fiesh at zefix dot tv]

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

--- Comment #1 from fiesh at zefix dot tv ---
https://en.cppreference.com/w/cpp/utility/variant/variant says that

"If T_i is (possibly cv-qualified) bool, F(T_i) is only considered if
std::decay_t (until C++20)std::remove_cvref_t (since C++20) is also bool"

which would mean 0 is the correct return value.  But I can't find anything like
this in

http://eel.is/c++draft/variant

[Bug libstdc++/95832] New: std::vector specialization leading std::variant ctor treating it as int rather than bool

[fiesh at zefix dot tv]

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

Bug ID: 95832
   Summary: std::vector specialization leading std::variant
ctor treating it as int rather than bool
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fiesh at zefix dot tv
  Target Milestone: ---

The following code returned 1 when compiled with gcc-9 but returns 0 with
gcc-10.  Since clang exhibits the exact same behavior depending on the
installed gcc version, I suppose it might be because of libstdc++.

It's worth noting that MSVC on godbolt also returns 0.

My primitive reading skills suggest to me that
http://eel.is/c++draft/variant#ctor-14 says it should be 1.  (Overload
resolution works correctly in that it prefers an f(bool) over an f(int) when
passed b.back().)

#include 
#include 

using T = std::variant;

int main()
{
std::vector b{false};
std::vector ts;
ts.emplace_back(b.back());
return ts.back().index();
}

[Bug target/95676] [armhf] g++ mis-compiles code at -O1 or above

[jamessan at jamessan dot com]

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

--- Comment #3 from James McCoy  ---
(In reply to Richard Earnshaw from comment #1)
> So what do you think is wrong with the code?  Sorry, I don't have time to
> try to second guess what's going on.
> 
> How did you configure the compiler?  What options did you use when building
> your code?

Given the additional information I supplied, is there anything else I can
provide to help?

[Bug c++/95831] New: Wrong line number in " -Wconversion" warning message

[haoxintu at gmail dot com]

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

Bug ID: 95831
   Summary: Wrong line number in " -Wconversion" warning message
   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
  Target Milestone: ---

This code, bug.cc, GCC might emit the wrong line number of the "-Wconversion"
warning.

$cat bug.cc
unsigned a = 0;
void foo (
short  param1 = a,
short  param2 = a,
char param3 = a)
{}

$g++ -Wconversion -c bug.cc
bug.cc:6:20: warning: conversion from 'unsigned int' to 'short int' may change
value [-Wconversion]
6 | char param3 = a)
  |^
bug.cc:6:20: warning: conversion from 'unsigned int' to 'short int' may change
value [-Wconversion]
bug.cc:6:20: warning: conversion from 'unsigned int' to 'char' may change value
[-Wconversion]
Compiler returned: 0

While in Clang:
$clang++ -Wconversion -c bug.cc
bug.cc:3:21: warning: implicit conversion loses integer precision: 'unsigned
int' to 'short' [-Wimplicit-int-conversion]
short  param1 = a,
  ~ ^
bug.cc:4:21: warning: implicit conversion loses integer precision: 'unsigned
int' to 'short' [-Wimplicit-int-conversion]
short  param2 = a,
  ~ ^
bug.cc:5:19: warning: implicit conversion loses integer precision: 'unsigned
int' to 'char' [-Wimplicit-int-conversion]
char param3 = a)
~ ^
3 warnings generated.

Reproduced in godblot: https://godbolt.org/z/AoGkVQ

Noted that I have tested it in almost all GCC versions, they all have this
issue. I guess maybe someone have reported this already, but I can't find one.

[Bug regression/95830] [11 regression][MIPS/MSA] internal compiler error: in do_store_flag, at expr.c:12247 start with gcc-11-1445-g502d63b6d61

[paul.hua.gm at gmail dot com]

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

Paul Hua  changed:

   What|Removed |Added

Summary|[10 regression][MIPS/MSA]   |[11 regression][MIPS/MSA]
   |internal compiler error: in |internal compiler error: in
   |do_store_flag, at   |do_store_flag, at
   |expr.c:12247 start with |expr.c:12247 start with
   |gcc-11-1445-g502d63b6d61|gcc-11-1445-g502d63b6d61
 CC||mliska at suse dot cz
 Target||mips
Version|10.0|11.0

--- Comment #1 from Paul Hua  ---
still fails on gcc-11-1580-gc154b8bc568.

[Bug regression/95830] New: [10 regression][MIPS/MSA] internal compiler error: in do_store_flag, at expr.c:12247 start with gcc-11-1445-g502d63b6d61

[paul.hua.gm at gmail dot com]

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

Bug ID: 95830
   Summary: [10 regression][MIPS/MSA] internal compiler error: in
do_store_flag, at expr.c:12247 start with
gcc-11-1445-g502d63b6d61
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: regression
  Assignee: unassigned at gcc dot gnu.org
  Reporter: paul.hua.gm at gmail dot com
  Target Milestone: ---

Since gcc-11-1445-g502d63b6d61 O3-pr45971 fails on mips.

$ cat O3-pr45971.i 

void
foo (int *x, int *y)
{
  int i;
  for (i = 0; i < 11; i++)
y[i] = (x[i] == 1) ? i + 1 : -(i + 1);
}

$ ./gcc/cc1 -fpreprocessed O3-pr45971.i -mel -quiet -dumpbase O3-pr45971.c
-dumpbase-ext .c -mmsa -march=mips64r2 -mabi=64 -mllsc -mips64r2 -mno-shared
-O2 -O3 -version -fdiagnostics-color=never -fno-diagnostics-show-caret
-fno-diagnostics-show-line-numbers -fdiagnostics-urls=never -ftree-vectorize
-fno-tree-loop-distribute-patterns -fvect-cost-model=unlimited -fno-common
-fdump-tree-vect-details -fno-ipa-cp-clone -o O3-pr45971.s


/home/xuchenghua/GCC/gcc_git_trunk/gcc/testsuite/gcc.dg/vect/O3-pr45971.c: In
function ‘foo’:
/home/xuchenghua/GCC/gcc_git_trunk/gcc/testsuite/gcc.dg/vect/O3-pr45971.c:5:1:
internal compiler error: in do_store_flag, at expr.c:12247
0x1204fed93 do_store_flag
../../../gcc_git_trunk/gcc/expr.c:12247
0x1204ff313 expand_expr_real_2(separate_ops*, rtx_def*, machine_mode,
expand_modifier)
../../../gcc_git_trunk/gcc/expr.c:9608
0x120379653 expand_gimple_stmt_1
../../../gcc_git_trunk/gcc/cfgexpand.c:3786
0x120379653 expand_gimple_stmt
../../../gcc_git_trunk/gcc/cfgexpand.c:3847
0x120380183 expand_gimple_basic_block
../../../gcc_git_trunk/gcc/cfgexpand.c:5888
0x120382dd3 execute
../../../gcc_git_trunk/gcc/cfgexpand.c:6572
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

there are many others fails start between gcc-11-1441-g48b6386f5d0 and
gcc-11-1470-gd11c9841d54. 

/gcc.dg/graphite/vect-pr43423.c:6:6: internal compiler error: in do_store_flag,
at expr.c:12247
/gcc.dg/graphite/vect-pr43423.c:6:6: internal compiler error: in do_store_flag,
at expr.c:12247
/gcc.dg/vect/pr46009.c:13:1: internal compiler error: in do_store_flag, at
expr.c:12247
/gcc.dg/vect/pr46009.c:13:1: internal compiler error: in do_store_flag, at
expr.c:12247
/gcc.dg/vect/pr62075.c:11:1: internal compiler error: in do_store_flag, at
expr.c:12247
/gcc.dg/vect/pr62075.c:11:1: internal compiler error: in do_store_flag, at
expr.c:12247
/gcc.dg/vect/pr69820.c:10:1: internal compiler error: in do_store_flag, at
expr.c:12247
/gcc.dg/vect/pr69820.c:10:1: internal compiler error: in do_store_flag, at
expr.c:12247
/gcc.dg/vect/pr86749.c:10:1: internal compiler error: in do_store_flag, at
expr.c:12247
/gcc.dg/vect/pr86749.c:10:1: internal compiler error: in do_store_flag, at
expr.c:12247
/gcc.dg/vect/pr94727.c:9:1: internal compiler error: in do_store_flag, at
expr.c:12247
/gcc.dg/vect/pr94727.c:9:1: internal compiler error: in do_store_flag, at
expr.c:12247
/gcc.dg/vect/vect-over-widen-13.c:19:1: internal compiler error: in
do_store_flag, at expr.c:12247
/gcc.dg/vect/vect-over-widen-13.c:19:1: internal compiler error: in
do_store_flag, at expr.c:12247
/gcc.dg/vect/vect-over-widen-15.c:20:1: internal compiler error: in
do_store_flag, at expr.c:12247
/gcc.dg/vect/vect-over-widen-15.c:20:1: internal compiler error: in
do_store_flag, at expr.c:12247
/gcc.dg/vect/vect-version-1.c:5:6: internal compiler error: in do_store_flag,
at expr.c:12247
/gcc.dg/vect/vect-version-1.c:5:6: internal compiler error: in do_store_flag,
at expr.c:12247
/gcc.dg/vect/vect-version-2.c:5:6: internal compiler error: in do_store_flag,
at expr.c:12247
/gcc.dg/vect/vect-version-2.c:5:6: internal compiler error: in do_store_flag,
at expr.c:12247
/gcc.dg/vect/pr68305.c:8:1: internal compiler error: in do_store_flag, at
expr.c:12247
/gcc.dg/vect/pr68305.c:8:1: internal compiler error: in do_store_flag, at
expr.c:12247
/gcc.dg/vect/pr68417.c:13:1: internal compiler error: in do_store_flag, at
expr.c:12247
/gcc.dg/vect/pr68417.c:13:1: internal compiler error: in do_store_flag, at
expr.c:12247
/gcc.dg/vect/pr79887.c:8:1: internal compiler error: in do_store_flag, at
expr.c:12247
/gcc.dg/vect/pr79887.c:8:1: internal compiler error: in do_store_flag, at
expr.c:12247
/gcc.dg/vect/vect-over-widen-13.c:19:1: internal compiler error: in
do_store_flag, at expr.c:12247
/gcc.dg/vect/vect-over-widen-13.c:19:1: internal compiler error: in
do_store_flag, at expr.c:12247
/gcc.dg/vect/vect-over-widen-15.c:20:1: internal compiler error: in
do_store_flag, at expr.c:12247
/gcc.dg/vect/vect-over-widen-15.c:20:1: internal compiler error: in
do_store_flag, at expr.c:12247

[Bug middle-end/95818] wrong "used uninitialized" warning

[msebor at gcc dot gnu.org]

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

--- Comment #8 from Martin Sebor  ---
No problem (and no inconvenience either).

[Bug rtl-optimization/89310] Poor code generation returning float field from a struct

[luoxhu at gcc dot gnu.org]

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

luoxhu at gcc dot gnu.org changed:

   What|Removed |Added

 CC||luoxhu at gcc dot gnu.org

--- Comment #3 from luoxhu at gcc dot gnu.org ---
rs6000.md:

(define_insn_and_split "movsf_from_si"
...
  "&& reload_completed
   && vsx_reg_sfsubreg_ok (operands[0], SFmode)
   && int_reg_operand_not_pseudo (operands[1], SImode)"
  [(const_int 0)
...
  /* Move SF value to upper 32-bits for xscvspdpn.  */
  emit_insn (gen_ashldi3 (op2, op1_di, GEN_INT (32)));
  emit_insn (gen_p8_mtvsrd_sf (op0, op2));
  emit_insn (gen_vsx_xscvspdpn_directmove (op0, op0));
  DONE


The split seems inevitable as reload_completed is true here, can this
lshrdi3+ashldi3 be optimized by peephole? 

r9 is DImode, is there any benefit of using mtvsrw[az] instead of mtvsrd?

Or could we replace the 3 instructions with better sequence?  Thanks.

[Bug fortran/92702] [F2008] (and hence [F2018]) Implement VALUE support for arrays + deferred-length parameters

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

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

--- Comment #2 from Yao Liu  ---
(In reply to Tobias Burnus from comment #1)
> The following restriction of F2003 is also gone:
> 
> C528   (R501) If the VALUE attribute is specified, the length type parameter
> values shall be omitted or specified by initialization expressions.
> 
> F2008 + F2018 permit them.
> 
> Implementation choice (for characters and arrays): One can pass those with
> known bounds as ARRAY_TYPE (i.e. by value) or one passes them as a pointer
> to an ARRAY_TYPE (i.e. by reference).
> 
> Currently, for character they are passed by value as (known string-length)
> ARRAY_TYPE.

F2008:
C557 An entity with the VALUE attribute shall be a dummy data object that is
not an assumed-size array or a coarray, and does not have a coarray ultimate
component.

I have a question: like "character(*)" or "demension(::)", it's a assumed-size
character or array, is this situation premitted in F2008？

(In reply to Tobias Burnus from comment #1)
> The following restriction of F2003 is also gone:
> 
> C528   (R501) If the VALUE attribute is specified, the length type parameter
> values shall be omitted or specified by initialization expressions.
> 
> F2008 + F2018 permit them.
> 
> Implementation choice (for characters and arrays): One can pass those with
> known bounds as ARRAY_TYPE (i.e. by value) or one passes them as a pointer
> to an ARRAY_TYPE (i.e. by reference).
> 
> Currently, for character they are passed by value as (known string-length)
> ARRAY_TYPE.

F2008:
C557 An entity with the VALUE attribute shall be a dummy data object that is
not an assumed-size array or a coarray, and does not have a coarray ultimate
component.

I have a question: like "character(*)" or "demension(::)", it's a assumed-size
character or array, is this situation premitted in F2008？

[Bug middle-end/95818] wrong "used uninitialized" warning

[ferruh.yigit at intel dot com]

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

--- Comment #7 from Ferruh YIGIT  ---
Thanks Martin, explanation and sample clarified the issue for me.
Sorry for the inconvenience caused.

[Bug middle-end/95818] wrong "used uninitialized" warning

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

  Component|c   |middle-end
 Resolution|--- |INVALID
 CC||msebor at gcc dot gnu.org
 Status|WAITING |RESOLVED

--- Comment #6 from Martin Sebor  ---
This instance of the warning looks familiar but I can't reproduce it with my
build of the kernel.  The code in the test case isn't valid (it triggers both
-Wstrict-aliasing and -Wuninitialized), and I don't think it's safe either. 
Only the leading 48 bits of the struct are initialized (by GCC; the program
initializes just 35 bits) but the access is to the full 64 bits.  Clearing the
whole struct by calling memset avoids the -Wuninitialized.

A small test case that reproduces both warnings is below.

$ cat z.c && gcc -O2 -S -Wall -fdump-tree-uninit=/dev/stdout z.c
struct S
{
  int a;
  short i: 1;
};

void f (long);

void g (void)
{
  struct S s;
  s.a = 0;
  s.i = 1;
  f (*(long*));
}
z.c: In function ‘g’:
z.c:14:7: warning: dereferencing type-punned pointer will break strict-aliasing
rules [-Wstrict-aliasing]
   14 |   f (*(long*));
  |   ^
z.c:14:3: warning: ‘s’ is used uninitialized [-Wuninitialized]
   14 |   f (*(long*));
  |   ^~
z.c:11:12: note: ‘s’ declared here
   11 |   struct S s;
  |^

;; Function g (g, funcdef_no=0, decl_uid=1937, cgraph_uid=1, symbol_order=0)

g ()
{
  struct S s;
  long int _1;

   [local count: 1073741824]:
  s.a = 0;
  s.i = -1;
  _1 = MEM[(long int *)];
  f (_1); [tail call]
  s ={v} {CLOBBER};
  return;

}

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

[msebor at gcc dot gnu.org]

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

Bug 95818 Summary: wrong "used uninitialized" warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95818

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |INVALID

[Bug c/95818] wrong "used uninitialized" warning

[ferruh.yigit at intel dot com]

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

--- Comment #5 from Ferruh YIGIT  ---
Got it, 'iavf_ethdev.i' attached.

I am able to reproduce with command [1] and got the output [2] using .i file.

[1]
/usr/local/gcc-latest/bin/gcc -m64 -pthread -march=native -O3 -Wall -Werror
-Wno-strict-aliasing -v -save-temps -o iavf_ethdev.o -x cpp-output
iavf_ethdev.i


[2]
Using built-in specs.
COLLECT_GCC=/usr/local/gcc-latest/bin/gcc
COLLECT_LTO_WRAPPER=/usr/local/gcc-latest/libexec/gcc/x86_64-pc-linux-gnu/11.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-latest/configure --prefix=/usr/local/gcc-latest :
(reconfigured) ../gcc-latest/configure --prefix=/usr/local/gcc-latest
--enable-languages=c,c++,fortran,lto,objc --no-create --no-recursion
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.0.0 20200621 (experimental) (GCC) 
COLLECT_GCC_OPTIONS='-m64' '-pthread' '-march=native' '-O3' '-Wall' '-Werror'
'-Wno-strict-aliasing' '-v' '-save-temps' '-o' 'iavf_ethdev.o' '-dumpdir'
'iavf_ethdev.o-'
 /usr/local/gcc-latest/libexec/gcc/x86_64-pc-linux-gnu/11.0.0/cc1
-fpreprocessed iavf_ethdev.i -march=skylake-avx512 -mmmx -mno-3dnow -msse
-msse2 -msse3 -mssse3 -mno-sse4a -mcx16 -msahf -mmovbe -maes -mno-sha -mpclmul
-mpopcnt -mabm -mno-lwp -mfma -mno-fma4 -mno-xop -mbmi -mno-sgx -mbmi2
-mno-pconfig -mno-wbnoinvd -mno-tbm -mavx -mavx2 -msse4.2 -msse4.1 -mlzcnt
-mrtm -mhle -mrdrnd -mf16c -mfsgsbase -mrdseed -mprfchw -madx -mfxsr -mxsave
-mxsaveopt -mavx512f -mno-avx512er -mavx512cd -mno-avx512pf -mno-prefetchwt1
-mclflushopt -mxsavec -mxsaves -mavx512dq -mavx512bw -mavx512vl -mno-avx512ifma
-mno-avx512vbmi -mno-avx5124fmaps -mno-avx5124vnniw -mclwb -mno-mwaitx
-mno-clzero -mpku -mno-rdpid -mno-gfni -mno-shstk -mno-avx512vbmi2
-mno-avx512vnni -mno-vaes -mno-vpclmulqdq -mno-avx512bitalg
-mno-avx512vpopcntdq -mno-movdiri -mno-movdir64b -mno-waitpkg -mno-cldemote
-mno-ptwrite -mno-avx512bf16 -mno-enqcmd -mno-avx512vp2intersect -mno-serialize
-mno-tsxldtrk --param l1-cache-size=32 --param l1-cache-line-size=64 --param
l2-cache-size=33792 -mtune=skylake-avx512 -quiet -dumpdir iavf_ethdev.o-
-dumpbase iavf_ethdev.i -dumpbase-ext .i -m64 -O3 -Wall -Werror
-Wno-strict-aliasing -version -o iavf_ethdev.o-iavf_ethdev.s
GNU C17 (GCC) version 11.0.0 20200621 (experimental) (x86_64-pc-linux-gnu)
compiled by GNU C version 11.0.0 20200621 (experimental), GMP version
6.1.2, MPFR version 3.1.6-p2, MPC version 1.1.0, isl version none
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU C17 (GCC) version 11.0.0 20200621 (experimental) (x86_64-pc-linux-gnu)
compiled by GNU C version 11.0.0 20200621 (experimental), GMP version
6.1.2, MPFR version 3.1.6-p2, MPC version 1.1.0, isl version none
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: 6a7f176d54144e44e3ed475e12ec1e06
.../net/iavf/iavf_ethdev.c: In function ‘iavf_dev_link_update’:
.../net/iavf/iavf_ethdev.c:641:6: error: ‘new_link’ is used uninitialized
[-Werror=uninitialized]
  641 |  if (rte_atomic64_cmpset((uint64_t *)>data->dev_link,
  |  ^
  642 | *(uint64_t *)>data->dev_link,
  | ~~
  643 | *(uint64_t *)_link) == 0)
  | ~~~
.../net/iavf/iavf_ethdev.c:596:22: note: ‘new_link’ declared here
  596 |  struct rte_eth_link new_link;
  |  ^~~~
cc1: all warnings being treated as errors

[Bug c/95818] wrong "used uninitialized" warning

[ferruh.yigit at intel dot com]

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

--- Comment #4 from Ferruh YIGIT  ---
Created attachment 48772
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48772=edit
preprocessed source

[Bug tree-optimization/95803] Failure to optimize strlen in certain situations properly, instead leading to weird code

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Blocks||83819
   Last reconfirmed||2020-06-22
 CC||msebor at gcc dot gnu.org
 Status|UNCONFIRMED |NEW

--- Comment #1 from Martin Sebor  ---
The first case is due to failing to handle POINTER_PLUS expressions in
maybe_set_strlen_range() in tree-ssa-strlen.c.  The second case is folded into
(i <= 3 ? i : 0) very early on by fold_builtin_strlen().

There is no consistency in how GCC responds to instances of undefined behavior.
 Some are folded away and replaced by constants, others are intentionally made
to expand into library calls.  The referenced meta-bug tracks a number of such
cases.

We've been talking for years now about implementing a policy where the decision
how to respond is left up to the user.  The three common responses that were
discussed at GNU Cauldron in Manchester are to:

1) fold/eliminate/replace it with a safer alternative
2) replace with __builtin_trap
3) replace with __builtin_unreachable

All three with a warning.  I've been working on improvements in this area and
with my WIP patches to the detection of past the end reads GCC prints:

pr95803.c: In function ‘f’:
pr95803.c:8:12: warning: ‘__builtin_strlen’ reading 1 or more bytes from a
region of size 0 [-Wstringop-overread]
8 | return __builtin_strlen(s) > 3;
  |^~~

I expect to submit the patch for review soon (maybe even this week).  I support
folding this and similar code to a no-op provided it still triggers a warning.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83819
[Bug 83819] [meta-bug] missing strlen optimizations

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

[wilson at gcc dot gnu.org]

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

--- Comment #2 from Jim Wilson  ---
I took another look, and it turns out that the should_duplicate_loop_header_p
for size/speed is not the only issue.  There is also an issue in
tree-ssa-loop-ivopts.c when computing iv costs.  With speed, the +4 iv is
computed as cheaper than the +1 iv.  With size, the +4 iv and +1 iv have the
exact same cost, and since the +1 iv was looked at first that one was chosen. 
If I hack adjust_setup_cost to use to always use the speed cost calculation,
and retain the should_duplicate_loop_header_p hack, then both the inner and
outer loops get the +4 iv with -Os.

Looking at gcc-8.3, I see that the outer loop has the +4 iv and the inner loop
as the +1 iv.  This looks similar to the result I get with the
adjust_setup_cost hack but not the should_duplicate_loop_header_p hack.  So I
think the regression is solely due to some change in the cost calculation.

There is a lot of code involved in cost calculations.  This could have even
been a riscv backend change.  I would suggest doing a bisect over the gcc git
tree if you want to see exactly where and how the cost calculation changed.

The -Os and -O2 optimization diverges in try_improve_iv_set where it does "if
(acost < best_cost)".  Maybe this could be improved to handle the case where
acost == best_cost, and use some other criteria to choose which one is better,
e.g. maybe a giv is better than a biv if they have the same cost.  I haven't
tried looking into this.

[Bug fortran/95829] Bogus error with additional blanks in type(*)

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4
 CC||kargl at gcc dot gnu.org
   Last reconfirmed||2020-06-22
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #1 from kargl at gcc dot gnu.org ---
Index: gcc/fortran/decl.c
===
--- gcc/fortran/decl.c  (revision 280157)
+++ gcc/fortran/decl.c  (working copy)
@@ -4069,7 +4069,7 @@ gfc_match_decl_type_spec (gfc_typespec *ts, int implic
   gfc_gobble_whitespace ();
   if (gfc_peek_ascii_char () == '*')
{
- if ((m = gfc_match ("*)")) != MATCH_YES)
+ if ((m = gfc_match ("* ) ")) != MATCH_YES)
return m;
  if (gfc_comp_struct (gfc_current_state ()))
{

[Bug fortran/95812] [10/11 Regression] ICE in gfc_dep_resolver since r10-2114

[tkoenig at gcc dot gnu.org]

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

--- Comment #2 from Thomas Koenig  ---
Fix looks simple enough:

diff --git a/gcc/fortran/dependency.c b/gcc/fortran/dependency.c
index f6c68409e68..7edd5d9010d 100644
--- a/gcc/fortran/dependency.c
+++ b/gcc/fortran/dependency.c
@@ -2031,10 +2031,12 @@ ref_same_as_full_array (gfc_ref *full_ref, gfc_ref
*ref)
 return false;
   if (full_ref->u.ar.type != AR_FULL)
 return false;
   if (ref->type != REF_ARRAY)
 return false;
+  if (ref->u.ar.type == AR_FULL)
+return true;
   if (ref->u.ar.type != AR_SECTION)
 return false;

   for (i = 0; i < ref->u.ar.dimen; i++)
 {

[Bug fortran/95827] ICE in gfc_get_string, at fortran/iresolve.c:70

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Priority|P3  |P4
 CC||anlauf at gcc dot gnu.org
 Ever confirmed|0   |1
   Last reconfirmed||2020-06-22
   Assignee|unassigned at gcc dot gnu.org  |anlauf at gcc dot 
gnu.org

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

diff --git a/gcc/fortran/iresolve.c b/gcc/fortran/iresolve.c
index aa9bb328a0f..73769615c20 100644
--- a/gcc/fortran/iresolve.c
+++ b/gcc/fortran/iresolve.c
@@ -47,8 +47,8 @@ along with GCC; see the file COPYING3.  If not see
 const char *
 gfc_get_string (const char *format, ...)
 {
-  /* Provide sufficient space to hold "_F.symbol.symbol_MOD_symbol".  */
-  char temp_name[4 + 2*GFC_MAX_SYMBOL_LEN + 5 + GFC_MAX_SYMBOL_LEN + 1];
+  /* Provide sufficient space for "_F.caf_token__symbol.symbol_MOD_symbol". 
*/
+  char temp_name[15 + 2*GFC_MAX_SYMBOL_LEN + 5 + GFC_MAX_SYMBOL_LEN + 1];
   const char *str;
   va_list ap;
   tree ident;

[Bug fortran/95826] ICE in gfc_match_decl_type_spec, at fortran/decl.c:4290

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2020-06-22
   Priority|P3  |P4
 CC||anlauf at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |anlauf at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from anlauf at gcc dot gnu.org ---
This is fixed by:

diff --git a/gcc/fortran/decl.c b/gcc/fortran/decl.c
index c8a98537e87..fd4e1dc2322 100644
--- a/gcc/fortran/decl.c
+++ b/gcc/fortran/decl.c
@@ -4095,7 +4095,7 @@ match
 gfc_match_decl_type_spec (gfc_typespec *ts, int implicit_flag)
 {
   /* Provide sufficient space to hold "pdtsymbol".  */
-  char name[GFC_MAX_SYMBOL_LEN + 1 + 3];
+  char *name = XALLOCAVEC (char, GFC_MAX_SYMBOL_LEN + 1);
   gfc_symbol *sym, *dt_sym;
   match m;
   char c;
@@ -4286,8 +4286,10 @@ gfc_match_decl_type_spec (gfc_typespec *ts, int
implicit_flag)
  gcc_assert (!sym->attr.pdt_template && sym->attr.pdt_type);
  ts->u.derived = sym;
  const char* lower = gfc_dt_lower_string (sym->name);
- size_t len = strnlen (lower, sizeof (name));
- gcc_assert (len < sizeof (name));
+ size_t len = strlen (lower);
+ /* Reallocate with sufficient size.  */
+ if (len > GFC_MAX_SYMBOL_LEN)
+   name = XALLOCAVEC (char, len + 1);
  memcpy (name, lower, len);
  name[len] = '\0';
}

[Bug d/95198] [D] extern(C) private final functions should use 'local' linker attribute

[ibuclaw at gdcproject dot org]

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

Iain Buclaw  changed:

   What|Removed |Added

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

--- Comment #4 from Iain Buclaw  ---
(In reply to Witold Baryluk from comment #3)
> > The main example to demonstrate the current behaviour is correct would be 
> > the following:
> 
> ```
> extern(C)
> private final int f() {
>   return 5;
> }
> 
> auto pubf()() {
>   return f();
> }
> ```
> 
> I see, I guess you are right. I don't know how would one go to fix this to
> work correctly with existing linkers and not break other code.
> 
> Thanks for clarifications.

To close this issue, I'll leave my thoughts on a similar topic that was touched
on the D ML (this time, regarding the linkage of inline functions).

I'm of the opinion that there is no concept of external (global) or internal
(local) linkage in D.  Rather there's language linkage and module linkage.

Language linkage as in `extern(C++)`, `extern(C)`, `extern(Objective-C)`...

Module linkage as in for a given declaration resolves to the same symbol across
all TUs that import its residing module, but otherwise not strictly visible
outside of that.

It might do well to familiarize yourself with C++2a modules as a primer.  But
even then, you'll have to unlearn a lot of things.

[Bug fortran/95829] New: Bogus error with additional blanks in type(*)

[gs...@t-online.de]

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

Bug ID: 95829
   Summary: Bogus error with additional blanks in type(*)
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Affects versions down to at least r5 :


$ cat z1.f90
subroutine s(x)
   type( * ) :: x
end


$ cat z2.f90
subroutine s (a, b, c, d, e, f, g)
   type(*) :: a
   type(* ) :: b
   type( *) :: c
   type( * ) :: d
   type(*  ) :: e
   type(  *) :: f
   type(  *  ) :: g
end


$ gfortran-11-20200621 -c z1.f90
z1.f90:2:4:

2 |type( * ) :: x
  |1
Error: Unclassifiable statement at (1)

[Bug fortran/95828] New: ICE in resolve_select_rank, at fortran/resolve.c:9774

[gs...@t-online.de]

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

Bug ID: 95828
   Summary: ICE in resolve_select_rank, at fortran/resolve.c:9774
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Happens between name length 58 (ok) and 59 (ICE) :


$ cat z1_58.f90
module m234567890123456789012345678901234567890123456789012345678
   type t234567890123456789012345678901234567890123456789012345678
   end type
contains
   subroutine s234567890123456789012345678901234567890123456789012345678 &
  (x234567890123456789012345678901234567890123456789012345678)
  type(t234567890123456789012345678901234567890123456789012345678) :: &
   x234567890123456789012345678901234567890123456789012345678(..)
  select rank (y234567890123456789012345678901234567890123456789012345678 &
=> x234567890123456789012345678901234567890123456789012345678)
  rank (2)
  rank (3)
  rank default
  end select
   end
end


$ cat z1_59.f90
module m2345678901234567890123456789012345678901234567890123456789
   type t2345678901234567890123456789012345678901234567890123456789
   end type
contains
   subroutine s2345678901234567890123456789012345678901234567890123456789 &
  (x2345678901234567890123456789012345678901234567890123456789)
  type(t2345678901234567890123456789012345678901234567890123456789) :: &
   x2345678901234567890123456789012345678901234567890123456789(..)
  select rank (y2345678901234567890123456789012345678901234567890123456789
&
=> x2345678901234567890123456789012345678901234567890123456789)
  rank (2)
  rank (3)
  rank default
  end select
   end
end


$ cat z1_63.f90
module m23456789012345678901234567890123456789012345678901234567890123
   type t23456789012345678901234567890123456789012345678901234567890123
   end type
contains
   subroutine s23456789012345678901234567890123456789012345678901234567890123 &
  (x23456789012345678901234567890123456789012345678901234567890123)
  type(t23456789012345678901234567890123456789012345678901234567890123) ::
&
   x23456789012345678901234567890123456789012345678901234567890123(..)
  select rank
(y23456789012345678901234567890123456789012345678901234567890123 &
=> x23456789012345678901234567890123456789012345678901234567890123)
  rank (2)
  rank (3)
  rank default
  end select
   end
end


$ gfortran-11-20200621 -c z1_58.f90
$
$ gfortran-11-20200621 -c z1_59.f90
f951: internal compiler error: Segmentation fault
0xbce57f crash_signal
../../gcc/toplev.c:328
0x6cb511 resolve_select_rank
../../gcc/fortran/resolve.c:9774
0x6cb511 gfc_resolve_code(gfc_code*, gfc_namespace*)
../../gcc/fortran/resolve.c:11973
0x6cc6f7 resolve_codes
../../gcc/fortran/resolve.c:17257
0x6cc62e resolve_codes
../../gcc/fortran/resolve.c:17240
0x6cc7be gfc_resolve(gfc_namespace*)
../../gcc/fortran/resolve.c:17292
0x6b46f2 gfc_parse_file()
../../gcc/fortran/parse.c:6448
0x70098f gfc_be_parse_file
../../gcc/fortran/f95-lang.c:212

[Bug fortran/95827] New: ICE in gfc_get_string, at fortran/iresolve.c:70

[gs...@t-online.de]

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

Bug ID: 95827
   Summary: ICE in gfc_get_string, at fortran/iresolve.c:70
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Happens between name length 59 (ok) and 60 (ICE) :


$ cat z1_59.f90
module m2345678901234567890123456789012345678901234567890123456789
   interface
  module subroutine
s2345678901234567890123456789012345678901234567890123456789
  end
   end interface
end
submodule(m2345678901234567890123456789012345678901234567890123456789) &
   n2345678901234567890123456789012345678901234567890123456789
   integer :: x2345678901234567890123456789012345678901234567890123456789[*]
end


$ cat z1_60.f90
module m23456789012345678901234567890123456789012345678901234567890
   interface
  module subroutine
s23456789012345678901234567890123456789012345678901234567890
  end
   end interface
end
submodule(m23456789012345678901234567890123456789012345678901234567890) &
   n23456789012345678901234567890123456789012345678901234567890
   integer :: x23456789012345678901234567890123456789012345678901234567890[*]
end


$ cat z1_63.f90
module m23456789012345678901234567890123456789012345678901234567890123
   interface
  module subroutine
s23456789012345678901234567890123456789012345678901234567890123
  end
   end interface
end
submodule(m23456789012345678901234567890123456789012345678901234567890123) &
   n23456789012345678901234567890123456789012345678901234567890123
   integer ::
x23456789012345678901234567890123456789012345678901234567890123[*]
end


$ gfortran-11-20200621 -c z1_59.f90 -fcoarray=lib
$
$ gfortran-11-20200621 -c z1_60.f90 -fcoarray=lib
f951: internal compiler error: identifier overflow: 200
0x695169 gfc_report_diagnostic
../../gcc/fortran/error.c:782
0x69688a gfc_internal_error(char const*, ...)
../../gcc/fortran/error.c:1402
0x6be1d7 gfc_get_string(char const*, ...)
../../gcc/fortran/iresolve.c:70
0x773c16 gfc_build_qualified_array
../../gcc/fortran/trans-decl.c:994
0x7761bc gfc_get_symbol_decl(gfc_symbol*)
../../gcc/fortran/trans-decl.c:1795
0x77a340 gfc_create_module_variable
../../gcc/fortran/trans-decl.c:5302
0x72ab12 do_traverse_symtree
../../gcc/fortran/symbol.c:4162
0x77ae1b gfc_generate_module_vars(gfc_namespace*)
../../gcc/fortran/trans-decl.c:5801
0x748fc1 gfc_generate_module_code(gfc_namespace*)
../../gcc/fortran/trans.c:2238
0x6f3831 translate_all_program_units
../../gcc/fortran/parse.c:6294
0x6f3831 gfc_parse_file()
../../gcc/fortran/parse.c:6546
0x74021f gfc_be_parse_file
../../gcc/fortran/f95-lang.c:212

[Bug fortran/95826] New: ICE in gfc_match_decl_type_spec, at fortran/decl.c:4290

[gs...@t-online.de]

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

Bug ID: 95826
   Summary: ICE in gfc_match_decl_type_spec, at
fortran/decl.c:4290
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Moving on, this happens between name length 60 (ok) and 61 (ICE) :


$ cat z1_60.f90
program p
   type t23456789012345678901234567890123456789012345678901234567890 &
   (a23456789012345678901234567890123456789012345678901234567890, &
b23456789012345678901234567890123456789012345678901234567890)
  integer, kind ::
a23456789012345678901234567890123456789012345678901234567890
  integer, len :: 
b23456789012345678901234567890123456789012345678901234567890
   end type
   integer, parameter ::
n23456789012345678901234567890123456789012345678901234567890 = 16
   type (t23456789012345678901234567890123456789012345678901234567890 &
  (n23456789012345678901234567890123456789012345678901234567890, :)), &
  allocatable ::
x23456789012345678901234567890123456789012345678901234567890
end


$ cat z1_61.f90
program p
   type t234567890123456789012345678901234567890123456789012345678901 &
   (a234567890123456789012345678901234567890123456789012345678901, &
b234567890123456789012345678901234567890123456789012345678901)
  integer, kind ::
a234567890123456789012345678901234567890123456789012345678901
  integer, len :: 
b234567890123456789012345678901234567890123456789012345678901
   end type
   integer, parameter ::
n234567890123456789012345678901234567890123456789012345678901 = 16
   type (t234567890123456789012345678901234567890123456789012345678901 &
  (n234567890123456789012345678901234567890123456789012345678901, :)), &
  allocatable ::
x234567890123456789012345678901234567890123456789012345678901
end


$ cat z1_63.f90
program p
   type t23456789012345678901234567890123456789012345678901234567890123 &
   (a23456789012345678901234567890123456789012345678901234567890123, &
b23456789012345678901234567890123456789012345678901234567890123)
  integer, kind ::
a23456789012345678901234567890123456789012345678901234567890123
  integer, len :: 
b23456789012345678901234567890123456789012345678901234567890123
   end type
   integer, parameter ::
n23456789012345678901234567890123456789012345678901234567890123 = 16
   type (t23456789012345678901234567890123456789012345678901234567890123 &
(n23456789012345678901234567890123456789012345678901234567890123, :)),
&
  allocatable ::
x23456789012345678901234567890123456789012345678901234567890123
end


$ gfortran-11-20200621 -c z1_60.f90
$
$ gfortran-11-20200621 -c z1_61.f90
f951: internal compiler error: in gfc_match_decl_type_spec, at
fortran/decl.c:4290
0x64849f gfc_match_decl_type_spec(gfc_typespec*, int)
../../gcc/fortran/decl.c:4290
0x6491dc gfc_match_data_decl()
../../gcc/fortran/decl.c:6124
0x6ad323 match_word
../../gcc/fortran/parse.c:65
0x6ad323 decode_statement
../../gcc/fortran/parse.c:376
0x6aed6a next_free
../../gcc/fortran/parse.c:1280
0x6aed6a next_statement
../../gcc/fortran/parse.c:1512
0x6b03bb parse_spec
../../gcc/fortran/parse.c:3923
0x6b318c parse_progunit
../../gcc/fortran/parse.c:5852
0x6b4869 gfc_parse_file()
../../gcc/fortran/parse.c:6393
0x70098f gfc_be_parse_file
../../gcc/fortran/f95-lang.c:212

[Bug c++/93976] Implement P2082R1, Fixing CTAD for aggregates

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

   Last reconfirmed||2020-06-22
   Assignee|unassigned at gcc dot gnu.org  |jason at gcc dot gnu.org
 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1

[Bug c++/95825] New: [7/8/9/10/11 Regression] boost::optional -Wuninitialized

[nok.raven at gmail dot com]

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

Bug ID: 95825
   Summary: [7/8/9/10/11 Regression] boost::optional
-Wuninitialized
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nok.raven at gmail dot com
  Target Milestone: ---

#include 

boost::optional get()
{
  return {};
}

boost::optional foo()
{
  return get();
}

// g++ -O3 -Wall -Wextra -fsanitize=address

: In function 'boost::optional foo()':
:5:11: warning:
'.boost::optional::.boost::optional_detail::tc_optional_base::m_storage'
is used uninitialized in this function [-Wuninitialized]
5 |   return {};
  |   ^

https://godbolt.org/z/PD_qan

Most likely related to bug 86465

[Bug c++/95789] [10/11 Regression] Const method is allowed to return non-const reference on template class

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #2 from Marek Polacek  ---
This actually started with r10-7096-gd417b4f5414d9076300ab41974a14424f722688c
so mine.

[Bug fortran/95707] ICE in finish_equivalences, at fortran/trans-common.c:1319

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r10-8341-g4dd2fd9c4350529947fffc6bf257b5e22379554b
Author: Harald Anlauf 
Date:   Sat Jun 20 16:15:16 2020 +0200

PR fortran/95707 - ICE in finish_equivalences, at
fortran/trans-common.c:1319

With submodules and equivalence declarations, name mangling may result in
long internal symbols overflowing internal buffers.  We now check that
we do not exceed the enlarged buffer sizes.

gcc/fortran/
PR fortran/95707
* gfortran.h (gfc_common_head): Enlarge buffer.
* trans-common.c (gfc_sym_mangled_common_id): Enlarge temporary
buffers, and add check on length on mangled name to prevent
overflow.

(cherry picked from commit 3345e74299687de6144b87c0632018cafd4ccf3b)

[Bug fortran/95689] [8/9/10/11 Regression] ICE in check_sym_interfaces, at fortran/interface.c:2015

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r10-8338-gece7b4d5f0cef0811ee1a0ebbf00ba41c5cf080c
Author: Harald Anlauf 
Date:   Sat Jun 20 16:09:45 2020 +0200

PR fortran/95689 - ICE in check_sym_interfaces, at fortran/interface.c:2015

With submodules, name mangling of interfaces may result in long internal
symbols overflowing an internal buffer.  We now check that we do not
exceed the enlarged buffer size.

gcc/fortran/
PR fortran/95689
* interface.c (check_sym_interfaces): Enlarge temporary buffer,
and add check on length on mangled name to prevent overflow.

(cherry picked from commit 62c0c0ea7bfb6f8f6b8d767b05120cafb6823da6)

[Bug fortran/95688] ICE in gfc_get_string, at fortran/iresolve.c:70

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:9056a5f1874eb85c74e439c4058b1e5c936b

commit r10-8340-g9056a5f1874eb85c74e439c4058b1e5c936b
Author: Harald Anlauf 
Date:   Sat Jun 20 16:14:00 2020 +0200

PR fortran/95688 - ICE in gfc_get_string, at fortran/iresolve.c:70

With submodules, name mangling of character pointer declarations produces
long
internal symbols that overflowed a static internal buffer.  Adjust the
buffer
size.

gcc/fortran/
PR fortran/95688
* iresolve.c (gfc_get_string): Enlarge static buffer size.

(cherry picked from commit cd6546ac0e8fb2f4ff2a4bb2db2363ca02bdb7ba)

[Bug fortran/95687] ICE in get_unique_hashed_string, at fortran/class.c:508

[cvs-commit at gcc dot gnu.org]

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

--- Comment #7 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Harald Anlauf
:

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

commit r10-8339-gf067cc55d382c256308f85575bca3e42fe215541
Author: Harald Anlauf 
Date:   Sat Jun 20 16:11:48 2020 +0200

PR fortran/95687 - ICE in get_unique_hashed_string, at fortran/class.c:508

With submodules and PDTs, name mangling of interfaces may result in long
internal symbols overflowing a previously static internal buffer.  We now
set the buffer size dynamically.

gcc/fortran/
PR fortran/95687
* class.c (get_unique_type_string): Return a string with dynamic
length.
(get_unique_hashed_string, gfc_hash_value): Use dynamic result
from get_unique_type_string instead of static buffer.

(cherry picked from commit ac932bfcd21e9523fa2b880ae8138aef79da7f54)

[Bug c/95818] wrong "used uninitialized" warning

[glisse at gcc dot gnu.org]

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

--- Comment #3 from Marc Glisse  ---
Richard said "complete", that is the whole .i file, not just one random
function. If we cannot reproduce the issue by copying your code and compiling
it, we can't do anything about your report.

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

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r10-8337-gc00ca04ba7e46d2d59e5a4f95ee7121cdc4ba224
Author: Harald Anlauf 
Date:   Sat Jun 20 16:05:13 2020 +0200

PR fortran/95587 - ICE in gfc_target_encode_expr, at
fortran/target-memory.c:362

EQUIVALENCE objects are subject to constraints listed in the Fortran 2018
standard, section 8.10.1.1.  These constraints are to be checked
also for CLASS variables.

gcc/fortran/
PR fortran/95587
* match.c (gfc_match_equivalence): Check constraints on
EQUIVALENCE objects also for CLASS variables.

(cherry picked from commit 5eb947601bdce59f2ff26694327ad173c51c2724)

[Bug bootstrap/95805] [11 regression] gcc/recog.h:301:30: error: too many arguments to function call, expected 1, have 2

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

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

--- Comment #2 from rsandifo at gcc dot gnu.org  
---
Fixed by g:20a2e6afa82c165bcd1a8749478e9402a25088a4.

[Bug c++/95824] New: [coroutines] compiler crash

[victor.burckel at gmail dot com]

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

Bug ID: 95824
   Summary: [coroutines] compiler crash
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: victor.burckel at gmail dot com
  Target Milestone: ---

The following code sample makes the gcc 10.1.0 compiler crash with segmentation
fault (compiled with -std=c++20 -fcoroutines). Gcc trunk generates an assertion
> internal compiler error: tree check: expected function_type or method_type, 
> have pointer_type in captures_temporary, at cp/coroutines.cc:2690

That's the smallest piece of code I was able to reproduce on gcc 10.1.0
(removing the virtual from the makeId method or removing the virtual
inheritance from the exception fixes the issue). 
On gcc trunk the exception and base classes are not necessary to generate the
assertion.

I initially got this issue when invoking a virtual method to get a feed a
parameter to a coroutine, with boost::archive::archive_exception included,
which virtually inherits from std::exception.

I managed to reproduce with godbolt
https://godbolt.org/z/tBmRxJ

#include 

struct task {
  struct promise_type {
auto initial_suspend() noexcept { return std::suspend_always{}; }
auto final_suspend() noexcept { return std::suspend_always{}; }
void return_void() {}
task get_return_object() { return task{}; }
void unhandled_exception() noexcept {}
  };

  ~task() noexcept {}

  bool await_ready() const noexcept { return false; }
  void await_suspend(std::coroutine_handle<>) noexcept {}
  void await_resume() noexcept {}
};

struct base
{
virtual ~base() = default;
};

class exception : public virtual base
{};

struct factory
{
virtual ~factory() = default;
virtual int makeId() const;
};

task g(int);

task f(factory& factory) {
co_await g(factory.makeId());
}

[Bug c++/95823] New: [coroutines] compiler internal error in captures_temporary,

[victor.burckel at gmail dot com]

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

Bug ID: 95823
   Summary: [coroutines] compiler internal error in
captures_temporary,
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: victor.burckel at gmail dot com
  Target Milestone: ---

I get a compiler internal error when passing a value to a coroutine that is
retrieved through two inderections within smart pointers (I don't get the error
with raw pointers, that's the smallest piece of code I was able to produce).
> internal compiler error: in captures_temporary, at cp/coroutines.cc:2717

It can be easily worked around by making a local variable containing the value.
Of course the code would crash in runtime as the pointers are not initialized,
but I get the same error when initializing them.

I managed to reproduce with godbolt (both gcc10.1 and gcc trunk give me the
assertion)
https://godbolt.org/z/XarC_M

#include 
#include 

struct task {
  struct promise_type {
auto initial_suspend() noexcept { return std::suspend_always{}; }
auto final_suspend() noexcept { return std::suspend_always{}; }
void return_void() {}
task get_return_object() { return task{}; }
void unhandled_exception() noexcept {}
  };

  ~task() noexcept {}

  bool await_ready() const noexcept { return false; }
  void await_suspend(std::coroutine_handle<>) noexcept {}
  void await_resume() noexcept {}
};

struct Id
{
std::unique_ptr value;
};

task g(int);

task f() {
std::unique_ptr id;
co_await g(*id->value);
}

[Bug c++/95819] ICE: Segmentation fault signal terminated program cc1plus

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE
 CC||mpolacek at gcc dot gnu.org

--- Comment #1 from Marek Polacek  ---
Found a dup.

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

[Bug c++/93788] Segfault caused by infinite loop in cc1plus

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||haoxintu at gmail dot com

--- Comment #1 from Marek Polacek  ---
*** Bug 95819 has been marked as a duplicate of this bug. ***

[Bug c++/95822] New: [coroutines] compiler internal error with local object with noexcept false destructor

[victor.burckel at gmail dot com]

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

Bug ID: 95822
   Summary: [coroutines] compiler internal error with local object
with noexcept false destructor
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: victor.burckel at gmail dot com
  Target Milestone: ---

It seems that when a coroutine contains a local object whose destructor is
marked as noexcept(false), gcc reaches an unexpected state and aborts.
When compiling the following code with gcc10.1.0 (-std=c++20 -fcoroutines), I
get a compiler internal error: 
> internal compiler error: in gimplify_var_or_parm_decl, at gimplify.c:2830

Making the destructor noexcept fixes the error. I  got the error when using
boost log within a couroutine. It uses a record_pump whose destructor is not
noexcept.

I managed to reproduce with godbolt (both gcc10.1 and gcc trunk give me the
assertion)
https://godbolt.org/z/6JtKsU

#include 

struct task {
  struct promise_type {
auto initial_suspend() noexcept { return std::suspend_always{}; }
auto final_suspend() noexcept { return std::suspend_always{}; }
void return_void() {}
task get_return_object() { return task{}; }
void unhandled_exception() noexcept {}
  };

  ~task() noexcept {}

  bool await_ready() const noexcept { return false; }
  void await_suspend(std::coroutine_handle<>) noexcept {}
  void await_resume() noexcept {}
};

struct Error {
  ~Error() noexcept(false) {}
};

task g();
task f() {
  Error error;
  co_await g();
}

[Bug tree-optimization/95821] Failure to optimize strchr to use memchr for string constant

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
For -Os that is an undesirable change because it makes the code larger.  But
otherwise yes, seems useful.

[Bug tree-optimization/95821] New: Failure to optimize strchr to use memchr for string constant

[gabravier at gmail dot com]

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

Bug ID: 95821
   Summary: Failure to optimize strchr to use memchr for string
constant
   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: ---

auto f(char c)
{
return strchr("123", c);
}

This can be optimized to `return memchr("123", c, 4)`. This transformation is
done by LLVM, but not by GCC.

[Bug sanitizer/95137] Sanitizers seem to be missing support for coroutines

[iains at gcc dot gnu.org]

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

--- Comment #30 from Iain Sandoe  ---
(In reply to Rafael Avila de Espindola from comment #29)
> Created attachment 48771 [details]
> Testcase without lambda coroutines
> 
> I modified the testcase to also build with clang and not depend on async
> lambdas. This still reproduces the problem with gcc with undefined behaviour
> sanitizer, but works with with clang and sanitizers and gcc with valgrind.

thanks, I think I have a fix for this locally - but not ready to post just yet.

[Bug sanitizer/95137] Sanitizers seem to be missing support for coroutines

[rafael at espindo dot la]

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

Rafael Avila de Espindola  changed:

   What|Removed |Added

  Attachment #48723|0   |1
is obsolete||

--- Comment #29 from Rafael Avila de Espindola  ---
Created attachment 48771
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48771=edit
Testcase without lambda coroutines

I modified the testcase to also build with clang and not depend on async
lambdas. This still reproduces the problem with gcc with undefined behaviour
sanitizer, but works with with clang and sanitizers and gcc with valgrind.

[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 #8 from rsandifo at gcc dot gnu.org  
---
Thanks for the pointers.  Putting the mangled name in a target-specific
attribute (like we do for SVE) seems to fix it.  It actually also keeps
the testcase in comment 4 “working”, which is unexpected (to me) and
seems a little dubious.  I guess it's good news for backporting though.

[Bug fortran/95614] ICE in build_field, at fortran/trans-common.c:301

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #4 from Steve Kargl  ---
On Mon, Jun 22, 2020 at 09:10:25AM +, drikosev at gmail dot com wrote:
> 
> --- Comment #3 from Ev Drikos  ---
> 
> Hello,
> 
> Perhaps, an additional check in file resolve.c might be necessary, or
> one would have to adjust one-two "common*.f" test cases.
> 
> Hope this helps,
> Ev. Drikos

Yes, indeed.  Some testcases may need to be updated to
account for the new error message or one may needs to
use the old testcase to adjust the conditional to not
trigger for the older testcase.  Also, note that I've
found invalid Fortran in testcases as I've fixed a 
bug.

When parsing a file, gfortran runs a series of matchers.
If a failure is detected in a matcher an error message
is queued, and then other matchers are run.  If no matcher
succeeds in matching a statement, the last queued error
message(s) is(are) emitted and gfortran will exit.  If a
matcher does match a statement, then the error queue is
cleared and the next statement is parsed.  Sometimes a
new patch will find invalid Fortran in the testsuite.

[Bug c++/95807] GCC accepts "void value not ignored as it ought to be" in function template

[redi at gcc dot gnu.org]

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

--- Comment #7 from Jonathan Wakely  ---
(In reply to Haoxin Tu from comment #6)
> My team nowadays are focusing on improving the quality of mature compilers.
> We just developed a tool to test them and then found those bugs. Our method
> might not perfect now and it only found some issues in FE, and we are
> designing a more effective approach to focus on the ME or BE parts (those
> parts might more important for GCC), it still needs some time for us. So I
> totally agree with that you said, and maybe later reports will be more
> useful for you.

OK, thanks for the background information.

[Bug tree-optimization/95761] [11 regression] ICE during GIMPLE pass: slp verify_ssa failed

[dimhen at gmail dot com]

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

--- Comment #6 from Dmitry G. Dyachenko  ---
r11-1582 PASS for me x_2.i and original (non-reduced) compilation

[Bug fortran/95708] [9/10/11 Regression] ICE in resolve_fl_procedure, at fortran/resolve.c:13002

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:647340c92a042e8e6f7d004637f07060dbde49c0

commit r11-1586-g647340c92a042e8e6f7d004637f07060dbde49c0
Author: Mark Eggleston 
Date:   Mon Jun 22 13:35:01 2020 +0100

Fortran  : ICE in resolve_fl_procedure PR95708

Now issues an error "Intrinsic procedure 'num_images' not
allowed in PROCEDURE" instead of an ICE.

2020-06-22  Steven G. Kargl  

gcc/fortran/

PR fortran/95708
* intrinsic.c (add_functions): Replace CLASS_INQUIRY with
CLASS_TRANSFORMATIONAL for intrinsic num_images.
(make_generic): Replace ACTUAL_NO with ACTUAL_YES for
intrinsic team_number.
* resolve.c (resolve_fl_procedure): Check pointer ts.u.derived
exists before using it.

2020-06-22  Mark Eggleston  

gcc/testsuite/

PR fortran/95708
* gfortran.dg/pr95708.f90: New test.

[Bug tree-optimization/95804] ice in generate_code_for_partition, at tree-loop-distribution.c:1323

[dcb314 at hotmail dot com]

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

--- Comment #3 from David Binderman  ---
(In reply to bin cheng from comment #2)
> Whew, this part IS can of worms.  Will investigate it.

Great. The testcase I provided came from a C source code generator
called ccg. 

Here is another C test case which produces the same compiler crash with -O3:

$ more bug625.c
int a, b, c, d, e, f;
void g() {
  short *h = d;
  char *i = 
  for (; e; e++) {
for (; f; f++) {
  b = 3;
  if ((c = 8) >= *i)
a = 5 ? *h : 0;
  h = g;
}
i = 
  }
}

[Bug c++/95820] ICE in splice_late_return_type, at cp/pt.c:29034

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

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

[Bug c++/95768] [11 Regression] -march=sandybridge -O2 -Wall crashes as 'during GIMPLE pass: uninit ... Segmentation fault'

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=95580

--- Comment #4 from Martin Sebor  ---
In fact, the same test case as for pr95580 triggers the C++ ICE as well:

$ gcc -O1 -S -Wall -fno-tree-dce -xc++
/src/gcc/trunk/gcc/testsuite/gcc.dg/pr95580.c
‘
during GIMPLE pass: uninit
In function ‘void foo(int)’:
Segmentation fault
8 | foo (int x)
  | ^~~
0x15c3040 crash_signal
/src/gcc/trunk/gcc/toplev.c:328
0x9559fc location_wrapper_p(tree_node const*)
/src/gcc/trunk/gcc/tree.h:4004
0x955a79 tree_strip_any_location_wrapper(tree_node*)
/src/gcc/trunk/gcc/tree.h:4016
0x1a04ede integer_onep(tree_node const*)
/src/gcc/trunk/gcc/tree.c:2573
0xa9878e dump_expr
/src/gcc/trunk/gcc/cp/error.c:2386
0xa9b4f4 expr_to_string(tree_node*)
/src/gcc/trunk/gcc/cp/error.c:3109
0xa9f1e7 cp_printer
/src/gcc/trunk/gcc/cp/error.c:4264
0x270616b pp_format(pretty_printer*, text_info*)
/src/gcc/trunk/gcc/pretty-print.c:1475
0x26df21d diagnostic_report_diagnostic(diagnostic_context*, diagnostic_info*)
/src/gcc/trunk/gcc/diagnostic.c:1159
0x26df841 diagnostic_impl
/src/gcc/trunk/gcc/diagnostic.c:1309
0x26e00bd warning_at(unsigned int, int, char const*, ...)
/src/gcc/trunk/gcc/diagnostic.c:1446
0x1915da3 maybe_warn_operand
/src/gcc/trunk/gcc/tree-ssa-uninit.c:431
0x1916782 warn_uninitialized_vars
/src/gcc/trunk/gcc/tree-ssa-uninit.c:640
0x191b3e7 execute
/src/gcc/trunk/gcc/tree-ssa-uninit.c:2936
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug c/95818] wrong "used uninitialized" warning

[ferruh.yigit at intel dot com]

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

--- Comment #2 from Ferruh YIGIT  ---
.i output [1] and .s output [2] below, please let me know if the request was
something else.

[1]
int
iavf_dev_link_update(struct rte_eth_dev *dev,
  __attribute__((__unused__)) int wait_to_complete)
{
 struct rte_eth_link new_link;
 struct iavf_info *vf = (&((struct iavf_adapter *)dev->data->dev_private)->vf);




 switch (vf->link_speed) {
 case 10:
  new_link.link_speed = 10;
  break;
 case 100:
  new_link.link_speed = 100;
  break;
 case 1000:
  new_link.link_speed = 1000;
  break;
 case 1:
  new_link.link_speed = 1;
  break;
 case 2:
  new_link.link_speed = 2;
  break;
 case 25000:
  new_link.link_speed = 25000;
  break;
 case 4:
  new_link.link_speed = 4;
  break;
 case 5:
  new_link.link_speed = 5;
  break;
 case 10:
  new_link.link_speed = 10;
  break;
 default:
  new_link.link_speed = 0;
  break;
 }

 new_link.link_duplex = 1;
 new_link.link_status = vf->link_up ? 1 :
  0;
 new_link.link_autoneg = !(dev->data->dev_conf.link_speeds &
(1 << 0));

 if (rte_atomic64_cmpset((uint64_t *)>data->dev_link,
*(uint64_t *)>data->dev_link,
*(uint64_t *)_link) == 0)
  return -1;

 return 0;
}



[2]
.globl  iavf_dev_link_update
.type   iavf_dev_link_update, @function iavf_dev_link_update:
.LFB6034:
.cfi_startproc
movq24(%rdi), %rcx
movq96(%rcx), %rsi
movl476(%rsi), %edx
cmpl$2, %edx
je  .L5
jbe .L28
cmpl$5, %edx
je  .L5
jbe .L29
cmpl$10, %edx
movl$0, %eax
cmovne  %rax, %rdx
.L5:
movl112(%rcx), %eax
movzbl  473(%rsi), %esi
notl%eax
andl$1, %eax
sall$2, %esi
leal1(%rax,%rax), %eax
orl %esi, %eax
andl$7, %eax
salq$32, %rax
orq %rax, %rdx
movq104(%rcx), %rax
#APP
# 33 "/root/development/dpdk-next-net/build/include/rte_atomic_64.h" 1
lock ; cmpxchgq %rdx, 104(%rcx);sete %al;
# 0 "" 2
#NO_APP
cmpb$1, %al
sbbl%eax, %eax
ret
.p2align 4,,10
.p2align 3
.L29:
cmpl$25000, %edx
je  .L5
cmpl$4, %edx
je  .L5
.L11:
xorl%edx, %edx
jmp .L5
.p2align 4,,10
.p2align 3
.L28:
cmpl$1000, %edx
je  .L5
jbe .L30
cmpl$1, %edx
movl$0, %eax
cmovne  %rax, %rdx
jmp .L5
.p2align 4,,10
.p2align 3
.L30:
cmpl$10, %edx
je  .L5
cmpl$100, %edx
je  .L5
jmp .L11
.cfi_endproc
.LFE6034:
.size   iavf_dev_link_update, .-iavf_dev_link_update
.p2align 4

[Bug c++/95820] ICE in splice_late_return_type, at cp/pt.c:29034

[haoxintu at gmail dot com]

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

--- Comment #1 from Haoxin Tu  ---
(In reply to Haoxin Tu from comment #0)

> $g++ -w -fpermissive small.cc

Here is a mistake, and it should be

$g++ -w -fpermissive bug.cc

[Bug c++/95768] [11 Regression] -march=sandybridge -O2 -Wall crashes as 'during GIMPLE pass: uninit ... Segmentation fault'

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
  Component|tree-optimization   |c++

--- Comment #3 from Martin Sebor  ---
This is the same case of the pretty printer not handling an expression as
pr95580, except this one is in the C++ front end (the code is duplicated almost
verbatim between the two).  tree-ssa-uninit.c calls:

  if (warning_at (location, OPT_Wuninitialized,
  "%G%qE is used uninitialized", stmt, rhs))

with this STMT and its RHS:

  b$4$g_7 = MEM  [(const struct m &)_6 + 4];

expr_to_string() in cp/error.c then does this with the RHS:

case MEM_REF:
  if (TREE_CODE (TREE_OPERAND (t, 0)) == ADDR_EXPR
  && integer_zerop (TREE_OPERAND (t, 1)))
dump_expr (pp, TREE_OPERAND (TREE_OPERAND (t, 0), 0), flags);
  else
{
  pp_cxx_star (pp);
  if (!integer_zerop (TREE_OPERAND (t, 1)))
{
  pp_cxx_left_paren (pp);
  if (!integer_onep (TYPE_SIZE_UNIT
 (TREE_TYPE (TREE_TYPE (TREE_OPERAND (t,
0))

but because the MEM_REF first operand is not a ADDR_EXPR the else branch trips
the ICE in integer_zerop() because because the RHS type is void* whose
TYPE_SIZE_UNIT is null that integer_zerop() is not prepared to handle.

[Bug c++/95820] New: ICE in splice_late_return_type, at cp/pt.c:29034

[haoxintu at gmail dot com]

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

Bug ID: 95820
   Summary: ICE in splice_late_return_type, at cp/pt.c:29034
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Keywords: ice-on-invalid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: haoxintu at gmail dot com
  Target Milestone: ---

This case bug.cc, reduced by C-Reduce, crashed GCC.

$cat bug.cc
constexpr (*a)()->bool,

$g++ -w -fpermissive small.cc
bug.cc:1:19: internal compiler error: in splice_late_return_type, at
cp/pt.c:29034
1 | constexpr (*a)()->bool,
  |   ^~~~
0x5cd1f6 splice_late_return_type(tree_node*, tree_node*)
../../gcc/cp/pt.c:29034
0x67db9a grokdeclarator(cp_declarator const*, cp_decl_specifier_seq*,
decl_context, int, tree_node**)
../../gcc/cp/decl.c:12154
0x684228 start_decl(cp_declarator const*, cp_decl_specifier_seq*, int,
tree_node*, tree_node*, tree_node**)
../../gcc/cp/decl.c:5231
0x70c8ce cp_parser_init_declarator
../../gcc/cp/parser.c:20817
0x6efcc2 cp_parser_simple_declaration
../../gcc/cp/parser.c:13785
0x7159c6 cp_parser_declaration
../../gcc/cp/parser.c:13484
0x7160b4 cp_parser_translation_unit
../../gcc/cp/parser.c:4761
0x7160b4 c_parse_file()
../../gcc/cp/parser.c:44034
0x7de74b c_common_parse_file()
../../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.

My GCC version is
$g++ --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 c++/95819] New: ICE: Segmentation fault signal terminated program cc1plus

[haoxintu at gmail dot com]

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

Bug ID: 95819
   Summary: ICE: Segmentation fault signal terminated program
cc1plus
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Keywords: ice-on-invalid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: haoxintu at gmail dot com
  Target Milestone: ---

This case bug.cc, reduced by C-Reduce, makes GCC crashed.

$cat bug.cc
wchar_t  a  =  [] (struct  {


$g++ bug.cc
bug.cc:1:33: error: types may not be defined in parameter types
1 |  wchar_t  a  =  [] (struct  {
  | ^
bug.cc:2: error: expected ‘}’ at end of input
bug.cc:1:33: note: to match this ‘{’
1 |  wchar_t  a  =  [] (struct  {
  | ^
bug.cc:2: error: expected ‘,’ or ‘...’ at end of input
bug.cc:1:34: error: expected ‘)’ at end of input
1 |  wchar_t  a  =  [] (struct  {
  |~ ^
  |  )
g++: internal compiler error: Segmentation fault signal terminated program
cc1plus
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

My GCC version
$g++ --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 c/95777] Allow specifying more than one target options at the same time in target and target_clones attribute

[yyc1992 at gmail dot com]

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

--- Comment #3 from Yichao Yu  ---
And for backward compatibility maybe
`target_clones("(sse4.1,arch=core2),default")` would work?

[Bug c++/95807] GCC accepts "void value not ignored as it ought to be" in function template

[haoxintu at gmail dot com]

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

--- Comment #6 from Haoxin Tu  ---
(In reply to Jonathan Wakely from comment #5)

> What practical impact does this have on any real world code?
> Why should we spend time on that, rather than the million other things we
> have to fix?

Hi, Jonathan,
This is the question I am always thinking about. GCC is a big software somehow,
and that's impossible to treat every part equally when it has issues. 


> Obviously in an ideal world GCC would be perfect, but the majority of your
> bug reports are asking for time to be spent on things that just don't matter.

My team nowadays are focusing on improving the quality of mature compilers. We
just developed a tool to test them and then found those bugs. Our method might
not perfect now and it only found some issues in FE, and we are designing a
more effective approach to focus on the ME or BE parts (those parts might more
important for GCC), it still needs some time for us. So I totally agree with
that you said, and maybe later reports will be more useful for you.

> If you really want it fixed, you can always do it yourself:
> https://gcc.gnu.org/contribute.html

This is a really constructive suggestion for me. I will try to do this at some
time.

Anyway, thanks for your kind and helpful response!

[Bug c++/95054] internal compiler error while overloading class constructor using variadic templates constraint by c++20 concepts

[breyer.marcel at web dot de]

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

Marcel Breyer  changed:

   What|Removed |Added

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

--- Comment #1 from Marcel Breyer  ---
This has been fixed on the current GCC trunk.

https://godbolt.org/z/Lnh9d-

[Bug c++/94260] Specific friend function inside c++20 concept-constrained class template triggers 'not usable in a constant expression' error

[ppalka at gcc dot gnu.org]

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

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #1 from Patrick Palka  ---
Thanks for the report.  I'm unable to reproduce this issue against GCC 10.1 or
current trunk.  Are you still able to reproduce?

[Bug c++/95262] Taking address of function pointer doesn't do full concept overload resolution

[ppalka at gcc dot gnu.org]

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

Patrick Palka  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2020-06-22
 CC||ppalka at gcc dot gnu.org
 Status|UNCONFIRMED |NEW

--- Comment #1 from Patrick Palka  ---
Confirmed.

[Bug target/95791] Unnecessary vzeroupper when only using zmm16 through zmm31

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #2 from H.J. Lu  ---
Fixed for GCC 11.

[Bug c/95777] Allow specifying more than one target options at the same time in target and target_clones attribute

[yyc1992 at gmail dot com]

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

--- Comment #2 from Yichao Yu  ---
I only tested this with `target_clones` and it seems that I misread the
document for `target`. So this is only an issue with `target_clones` attribute.
`target` support this just fine.

So to be more clear, using an example from the doc, it seems impossible to do
the equivalent of `target("sse4.1,arch=core2")` using `target_clones`. Doing
`target_clones("sse4.1,arch=core2")` will create two functions instead of one.
(of course in reality what I might actually want is to make `target_clones` do
`target("sse4.1,arch=core2")` and target("default")).

[Bug ipa/95775] Command line argument for target_clones?

[yyc1992 at gmail dot com]

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

--- Comment #2 from Yichao Yu  ---
> But it will blow up code-size considerably.
> So without some major work I don't think simply slapping target_clones on 
> each function is going to fly in practice.

I mean, it'll blow up not much more than the number of targets. I do agree this
is not something that the compiler should just do automatically and especially
not for big libraries and the user has to ask for it.

However, I don't believe code side consumes most memory on any modern desktop
or server systems and when using shared library different process won't even
consume much more memory anyway. It's for sure still the user's choice but OTOH
I think the compiler shouldn't have to make this choice for the user.

Additionally, there are some libraries, like math heavy ones, where virtually
every single functions could benefit from this. Those are the ones that I would
like to apply this option too. I'm also hoping, and I forgot to mention this in
the first post, that this can just work on gfortran as well...

> Eventually it should be possible to do sth like target_clones(auto) where 
> with a new option, the target (or the user) can define "default" targets to 
> clone for but the user still figures which are the important functions to 
> optimize

In julia I'm currently using a simple heuristic of detecting floating point
operation, vector operation and loops...

> [and GCC may, via IPA "spread" the cloned cgraph portion a bit].

and I do this in julia too.

[Bug c++/95807] GCC accepts "void value not ignored as it ought to be" in function template

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Severity|normal  |enhancement
   Last reconfirmed||2020-06-22

--- Comment #5 from Jonathan Wakely  ---
(In reply to Haoxin Tu from comment #4)
> As other major compilers reject this by default, I just suggest GCC should
> emit a appropriate diagnostic message (maybe a warning is fine).

What practical impact does this have on any real world code?

Why should we spend time on that, rather than the million other things we have
to fix?

Obviously in an ideal world GCC would be perfect, but the majority of your bug
reports are asking for time to be spent on things that just don't matter.

If you really want it fixed, you can always do it yourself:
https://gcc.gnu.org/contribute.html

[Bug target/95798] [10/11 Regression] Initialization code --- suboptimal

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Partially related, using the following -O2 -fno-ipa-icf:
void
foo (int x, int *p)
{
  p[x + 1] = 1;
}

void
bar (int x, int *p)
{
  p[x + 1UL] = 1;
}

void
baz (int x, int *p)
{
  unsigned long l = x;
  l++;
  p[l] = 1;
}

void
qux (int x, int *p)
{
  unsigned long l = x + 1;
  p[l] = 1;
}
we get the same 3 insn functions for the first 3 cases and 4 insn for the last
one.  I'm surprised that we treat foo and qux differently, as x + 1 has
undefined overflow, so (unsigned long) (x + 1) can be implemented with x + 1UL
and when used in address arithmetics it should be beneficial like that (so
shall e.g. expansion optimize it, or ivopts, or isel)?

[Bug c/95818] wrong "used uninitialized" warning

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Blocks||24639
   Last reconfirmed||2020-06-22
 Ever confirmed|0   |1
 Status|UNCONFIRMED |WAITING
   Keywords||diagnostic

--- Comment #1 from Richard Biener  ---
please provide complete preprocessed source


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639
[Bug 24639] [meta-bug] bug to track all Wuninitialized issues

[Bug c/95818] New: wrong "used uninitialized" warning

[ferruh.yigit at intel dot com]

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

Bug ID: 95818
   Summary: wrong "used uninitialized" warning
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ferruh.yigit at intel dot com
  Target Milestone: ---

gcc (GCC) 11.0.0 20200621 (experimental)

Sorry, I couldn't able to reproduce with test code, I will copy-paste the real
code that causes the warning hoping it helps.

Warning [1] and code that causes it [2], struct in question [3].

As you can see all the fields of the struct has been set before used, so not
sure why giving used uninitialized warning.



[1]
.../drivers/net/iavf/iavf_ethdev.c: In function ‘iavf_dev_link_update’:
.../drivers/net/iavf/iavf_ethdev.c:641:6: error: ‘new_link’ is used
uninitialized [-Werror=uninitialized]
  641 |  if (rte_atomic64_cmpset((uint64_t *)>data->dev_link,
  |  ^
  642 | *(uint64_t *)>data->dev_link,
  | ~~
  643 | *(uint64_t *)_link) == 0)
  | ~~~
.../drivers/net/iavf/iavf_ethdev.c:596:22: note: ‘new_link’ declared here
  596 |  struct rte_eth_link new_link;
  |  ^~~~
cc1: all warnings being treated as error



[2]
iavf_dev_link_update(struct rte_eth_dev *dev,
__rte_unused int wait_to_complete)
{
struct rte_eth_link new_link;
struct iavf_info *vf = IAVF_DEV_PRIVATE_TO_VF(dev->data->dev_private);

/* Only read status info stored in VF, and the info is updated
 *  when receive LINK_CHANGE evnet from PF by Virtchnnl.
 */
switch (vf->link_speed) {
case 10:
new_link.link_speed = ETH_SPEED_NUM_10M;
break;
case 100:
new_link.link_speed = ETH_SPEED_NUM_100M;
break;
case 1000:
new_link.link_speed = ETH_SPEED_NUM_1G;
break;
case 1:
new_link.link_speed = ETH_SPEED_NUM_10G;
break;
case 2:
new_link.link_speed = ETH_SPEED_NUM_20G;
break;
case 25000:
new_link.link_speed = ETH_SPEED_NUM_25G;
break;
case 4:
new_link.link_speed = ETH_SPEED_NUM_40G;
break;
case 5:
new_link.link_speed = ETH_SPEED_NUM_50G;
break;
case 10:
new_link.link_speed = ETH_SPEED_NUM_100G;
break;
default:
new_link.link_speed = ETH_SPEED_NUM_NONE;
break;
}

new_link.link_duplex = ETH_LINK_FULL_DUPLEX;
new_link.link_status = vf->link_up ? ETH_LINK_UP :
 ETH_LINK_DOWN;
new_link.link_autoneg = !(dev->data->dev_conf.link_speeds &
ETH_LINK_SPEED_FIXED);

if (rte_atomic64_cmpset((uint64_t *)>data->dev_link,
*(uint64_t *)>data->dev_link,
*(uint64_t *)_link) == 0)
return -1;

return 0;
}



[3]
struct rte_eth_link {
uint32_t link_speed;/**< ETH_SPEED_NUM_ */
uint16_t link_duplex  : 1;  /**< ETH_LINK_[HALF/FULL]_DUPLEX */
uint16_t link_autoneg : 1;  /**< ETH_LINK_[AUTONEG/FIXED] */
uint16_t link_status  : 1;  /**< ETH_LINK_[DOWN/UP] */
} __rte_aligned(8);  /**< aligned for atomic64 read/write */

[Bug target/95791] Unnecessary vzeroupper when only using zmm16 through zmm31

[cvs-commit at gcc dot gnu.org]

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

--- Comment #1 from CVS Commits  ---
The master branch has been updated by H.J. Lu :

https://gcc.gnu.org/g:9302421e71e85b4d3766a534ed9e1c4ae1e7a6ca

commit r11-1585-g9302421e71e85b4d3766a534ed9e1c4ae1e7a6ca
Author: H.J. Lu 
Date:   Sat Jun 20 16:02:42 2020 -0700

x86: Skip EXT_REX_SSE_REG_P for vzeroupper optimization

Skip EXT_REX_SSE_REG_P for vzeroupper optimization since upper 16 vector
registers don't trigger SSE <-> AVX transition penalty.

gcc/

PR target/95791
* config/i386/i386.c (ix86_dirflag_mode_needed): Skip
EXT_REX_SSE_REG_P.

gcc/testsuite/

PR target/95791
* gcc.target/i386/pr95791.c: New test.

[Bug fortran/95585] ICE in gfc_check_reshape, at fortran/check.c:4751

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r11-1584-gd9aed5f1ccffc019ddf980e349caa3d092755cb4
Author: Mark Eggleston 
Date:   Thu Jun 11 06:42:36 2020 +0100

Fortran  : ICE in gfc_check_reshape PR95585

Issue an error where an array is used before its definition
instead of an ICE.

2020-06-22  Steven G. Kargl  

gcc/fortran/

PR fortran/95585
* check.c (gfc_check_reshape): Add check for a value when
the symbol has an attribute flavor FL_PARAMETER.

2020-06-22  Mark Eggleston  

gcc/testsuite/

PR fortran/95585
* gfortran.dg/pr95585.f90: New test.

[Bug bootstrap/94998] [10 Regression] GCC 10 won't configure for host=x86, build!=host, linker=bfd due to CET

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #10 from H.J. Lu  ---
Fixed for GCC 11 and GCC 10.2.

[Bug bootstrap/94998] [10 Regression] GCC 10 won't configure for host=x86, build!=host, linker=bfd due to CET

[cvs-commit at gcc dot gnu.org]

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

--- Comment #9 from CVS Commits  ---
The releases/gcc-10 branch has been updated by H.J. Lu :

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

commit r10-8336-g2c7ae01349f779f1d4e66d8831052ee59f9c948b
Author: H.J. Lu 
Date:   Tue May 12 10:39:42 2020 -0700

Enable CET in cross compiler if possible

Don't perform CET run-time check for host when cross compiling.  Instead,
enable CET in cross compiler if possible so that it will run on both CET
and non-CET hosts.

config/

PR bootstrap/94998
* cet.m4 (GCC_CET_HOST_FLAGS): Enable CET in cross compiler if
possible.

libiberty/

PR bootstrap/94998
* configure: Regenerated.

lto-plugin/

PR bootstrap/94998
* configure: Regenerated.

(cherry picked from commit d17cdc17c90ce77cb90c569322c1f241d3530cec)

[Bug tree-optimization/95817] New: Failure to optimize shift with constant to compare

[gabravier at gmail dot com]

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

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

bool f(int a)
{
return (!(a >> 7));
}

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

[Bug tree-optimization/95792] Failure to optimize assignment of struct members to memset

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
store-merging could do this, just rewrite it into MEM[whatever] = {}; if it is
large and let the expansion deal with it.

[Bug fortran/42693] Missing gcc-internal-format on messages from gfc_arith_error

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r11-1583-gd57bf2315e024ada3393ad967e8f632121383c9c
Author: Mark Eggleston 
Date:   Wed Jun 10 11:41:56 2020 +0100

Fortran  : Missing gcc-internal-format PR42693

Messages in gfc_arith_error contain gcc internal format specifiers
which should be enclosed in G_() in order to be correctly translated.

2020-06-22  Mark Eggleston  

gcc/fortran/

PR fortran/42693
* arith.c (gfc_arith_error): Enclose strings in G_() instead
of _().

[Bug target/95798] [10/11 Regression] Initialization code --- suboptimal

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Perhaps the change should be guarded on single_use?

[Bug target/95798] [10/11 Regression] Initialization code --- suboptimal

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
Summary|Initialization code --- |[10/11 Regression]
   |suboptimal  |Initialization code ---
   ||suboptimal
   Last reconfirmed||2020-06-22
 CC||jakub at gcc dot gnu.org,
   ||rdapp at gcc dot gnu.org
   Target Milestone|--- |10.2
 Ever confirmed|0   |1

--- Comment #2 from Jakub Jelinek  ---
The 9 -> 10 regression started with
r10-2806-gdf7d46d925c7baca7bf9961aee900876d8aef225
since which the IL is much larger and the resulting code less efficient.
The testcase as written is just weird, it is an expensive check whether the
program is called with multiple of 128 arguments >= 1024 arguments (otherwise
it invokes UB).

Adjusted testcase that is more meaningful:
void bar (unsigned long long *, int);

void
foo (int y, unsigned long long z)
{
  unsigned long long x[1024];
  unsigned long long i = y % 127;
  __builtin_memset (x, -1, sizeof (x));
  x[i] = 0;
  x[i + 1] = 0;
  x[i + 2] = 0;
  x[i + 3] = 0;
  x[i + 4] = 0;
  x[i + 5] = 0;
  x[i + 6] = 0;
  x[i + 7] = 0;
  bar (x, y);
}

[Bug target/95816] New: Aarch64 jumps between Hot/Cold sections use possibly clobbered registers x16/x17

[matmal01 at gcc dot gnu.org]

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

Bug ID: 95816
   Summary: Aarch64 jumps between Hot/Cold sections use possibly
clobbered registers x16/x17
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: matmal01 at gcc dot gnu.org
  Target Milestone: ---
Target: AArch64

When splitting a function into two different sections (hot/cold).

The assembler produces a relocation on jumps between the two sections.

The linker is permitted to use a veneer to implement such a relocated jump.

The registers x16 and x17 are reserved for use in those veneers.

Hence the registers x16 and x17 should be treated as clobbered when jumping
between the hot/cold sections in a function.

This is not done.

We can use the testcase below to demonstrate this (modified from predict-22.c
in the testsuite).

-
$ aarch64-none-linux-gnu-gcc \  
>predict-22.c \
>-O2 -w -fPIC -freorder-blocks-and-partition \
>-c -o predict-22.o

-
volatile int v;
void bar (void) __attribute__((leaf, cold));
void baz (int *);
void alt (long long);

void
foo (int x, int y, int z)
{
  static int f __attribute__((section ("mysection")));
  register long long k asm ("x16");
  __asm__ ("mov\t%0, 10" : "=r" (k) : "0" (k));
  f = 1;
  if (__builtin_expect (x, 0))
  if (__builtin_expect (y, 0))
  if (__builtin_expect (z, 0))
{
  f = 2;
  k *= 13;
  bar ();
  v += 1;
  v *= 2;
  v /= 2;
  v -= 1;
  v += 1;
  v *= 2;
  v /= 2;
  v -= 1;
  v += 1;
  v *= 2;
  v /= 2;
  v -= 1;
  v += k;
  v *= 2;
  v /= 2;
  v -= 1;
  v += 1;
  v *= 2;
  v /= 2;
  v -= 1;
  v += 1;
  v *= 2;
  v /= 2;
  v -= 1;
  v += 1;
  v *= 2;
  v /= 2;
  v -= 1;
  v += 1;
  v *= 2;
  v /= 2;
  v -= 1;
  f = 3;
  __builtin_abort ();
}
  f = k;
  baz ();
}



This produces an object file which is dumped below.
The dump below demonstrates that there is a R_AARCH64_JUMP26 relocation on the
jump between the hot/cold sections, and that the value stored in x16 is used
after that jump.



$  aarch64-none-linux-gnu-objdump -dr predict-22.o  
predict-22.o: file format elf64-littleaarch64


Disassembly of section .text:

 :
   0:   713fcmp w1, #0x0
   4:   7a401844ccmpw2, #0x0, #0x4, ne  // ne = any
   8:   7a401804ccmpw0, #0x0, #0x4, ne  // ne = any
   c:   d2800150mov x16, #0xa   // #10
  10:   54a1b.ne24   // b.any
  14:   9001adrpx1, 0 
14: R_AARCH64_ADR_PREL_PG_HI21  .bss
  18:   9120add x0, x1, #0x0
18: R_AARCH64_ADD_ABS_LO12_NC   .bss
  1c:   b930str w16, [x1]
1c: R_AARCH64_LDST32_ABS_LO12_NC.bss
  20:   1400b   0 
20: R_AARCH64_JUMP26baz
  24:   a9bd7bfdstp x29, x30, [sp, #-48]!
  28:   910003fdmov x29, sp
  2c:   a90153f3stp x19, x20, [sp, #16]
  30:   f90013f5str x21, [sp, #32]
  34:   1400b   0# Here is the
relocation.
34: R_AARCH64_JUMP26.text.unlikely

Disassembly of section .text.unlikely:

 :
   0:   9015adrpx21, 0 
0: R_AARCH64_ADR_PREL_PG_HI21   .bss
   4:   52800053mov w19, #0x2   // #2
   8:   aa1003f4mov x20, x16# Here we try
and use the clobbered x16 register.
   c:   b90002b3str w19, [x21]
c: R_AARCH64_LDST32_ABS_LO12_NC .bss
  10:   9400bl  0 
10: R_AARCH64_CALL26bar
  14:   9000adrpx0, 4 
14: R_AARCH64_ADR_GOT_PAGE  v
  18:   d28001a3mov x3, #0xd// #13
  1c:   52800062mov w2, #0x3// #3
  20:   f940ldr x0, [x0]
20: R_AARCH64_LD64_GOT_LO12_NC  v

[Bug demangler/95815] New: Infinite recursive error about "demangle_args" "demangle_nested_args" in libiberty when running cxxfilt

[ossecurity at iscas dot ac.cn]

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

Bug ID: 95815
   Summary: Infinite recursive error about "demangle_args"
"demangle_nested_args" in libiberty when running
cxxfilt
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: demangler
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ossecurity at iscas dot ac.cn
  Target Milestone: ---

Created attachment 48770
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48770=edit
crash input of cxxfilt (cxxfilt < ./payload002040)

Hi, developers, we find an infinite recursive error of cxxfilt(Binutils-2.31
and earlier) when demangle malformed inputs(Generate by our modified version of
AFL). This bug seems to be fixed in 2.32 and it is not reported yet, is there
any patches for earlier version?


reproduce command: cxxfilt < payload002040

Compile:
obj-2.31$../binutils-2.31/configure --disable-shared --disable-gdb
--disable-libde
cnumber --disable-readline --disable-sim --disable-ld AR=llvm-ar
RANLIB=llvm-ranlib CC=clang


Any comments or suggestions are grateful.

Best regards,
Ke Yang 

==
Valgrind log(binutils-2.31):
obj-2.31/binutils$ valgrind -- ./cxxfilt < ./paload002040 
==24114== Memcheck, a memory error detector
==24114== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==24114== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==24114== Command: ./cxxfilt
==24114== 
__?__aTSY_]fS __t4__fm4d666T4]fS
__t4__fm4d6667666T4_Z���_

_%�'

��
77�

_( ( ( (void���FeFFF@FFK_(int255_t,  ( ( ( ( ( ( ( ( ( (
( ( ( ( ( ( ( ( ( ( ( ( ( ( ( (void)))@FFK_(int255_t, 
( ( ( ( ( ( ( ( (double,  ( ( ( ( ( (���_

_%�

==24114== Stack overflow in thread #1: can't grow stack to 0xffe801000
==24114== 
==24114== Process terminating with default action of signal 11 (SIGSEGV)
==24114==  Access not within mapped region at address 0xFFE801FF0
==24114== Stack overflow in thread #1: can't grow stack to 0xffe801000
==24114==at 0x497BBA: string_init (cplus-dem.c:4935)
==24114==by 0x497BBA: do_type (cplus-dem.c:3628)
==24114==  If you believe this happened as a result of a stack
==24114==  overflow in your program's main thread (unlikely but
==24114==  possible), you can try to increase the size of the
==24114==  main thread stack using the --main-stacksize= flag.
==24114==  The main thread stack size used in this run was 8388608.
==24114== Stack overflow in thread #1: can't grow stack to 0xffe801000
==24114== 
==24114== Process terminating with default action of signal 11 (SIGSEGV)
==24114==  Access not within mapped region at address 0xFFE801FD8
==24114== Stack overflow in thread #1: can't grow stack to 0xffe801000
==24114==at 0x4A28680: _vgnU_freeres (in
/usr/lib/valgrind/vgpreload_core-amd64-linux.so)
==24114==  If you believe this happened as a result of a stack
==24114==  overflow in your program's main thread (unlikely but
==24114==  possible), you can try to increase the size of the
==24114==  main thread stack using the --main-stacksize= flag.
==24114==  The main thread stack size used in this run was 8388608.
==24114== 
==24114== HEAP SUMMARY:
==24114== in use at exit: 1,091,324 bytes in 38,796 blocks
==24114==   total heap usage: 39,071 allocs, 275 frees, 1,103,917 bytes
allocated
==24114== 
==24114== LEAK SUMMARY:
==24114==definitely lost: 0 bytes in 0 blocks
==24114==indirectly lost: 0 bytes in 0 blocks
==24114==  possibly lost: 0 bytes in 0 blocks
==24114==still reachable: 1,091,324 bytes in 38,796 blocks
==24114== suppressed: 0 bytes in 0 blocks
==24114== Rerun with --leak-check=full to see details of leaked memory
==24114== 
==24114== For counts of detected and suppressed errors, rerun with: -v
==24114== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
Segmentation fault

GDB log:

Program received signal SIGSEGV, Segmentation fault.
0x7788ab9a in _int_malloc (av=av@entry=0x77bcdb20 , 
bytes=bytes@entry=32) at malloc.c:3319
3319malloc.c: No such file or directory.
(gdb) bt
#0  0x7788ab9a in _int_malloc (av=av@entry=0x77bcdb20 , 
bytes=bytes@entry=32) at malloc.c:3319
#1  0x7788d184 in __GI___libc_malloc (bytes=32) at malloc.c:2913
#2  0x004bda45 in xmalloc (size=32) at
../../binutils-2.31/libiberty/xmalloc.c:147
#3  0x004a58eb in string_need (s=, n=32)
at ../../binutils-2.31/libiberty/cplus-dem.c:4906
#4  string_append (p=, s=)
at ../../binutils-2.31/libiberty/cplus-dem.c:4961
#5  demangle_args (work=0x7fffdc30, mangled=0x7fffdbd0,
declp=0x7f7ff100)
at ../../binutils-2.31/libiberty/cplus-dem.c:4578
#6  0x00498711 in demangle_nested_args 

[Bug target/95814] New: Failure to optimize __builtin_ia32_rsqrtss properly

[gabravier at gmail dot com]

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

Bug ID: 95814
   Summary: Failure to optimize __builtin_ia32_rsqrtss properly
   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 float v4f32 __attribute__((vector_size(16)));

float f(float x)
{
return __builtin_ia32_rsqrtss((v4f32){x, 0, 0, 0})[0];
}

With -O3, LLVM outputs this :

f(float):
  rsqrtss xmm0, xmm0
  ret

GCC outputs this :

f(float):
  pxor xmm1, xmm1
  movss xmm1, xmm0
  movaps xmm0, xmm1
  rsqrtss xmm0, xmm1
  ret

[Bug tree-optimization/95770] [11 Regression] ice during GIMPLE pass: slp

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/95770] [11 Regression] ice during GIMPLE pass: slp

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r11-1582-gcf07eea8429c923b7eb884ffc1b267c80a0a839c
Author: Richard Biener 
Date:   Mon Jun 22 12:14:54 2020 +0200

tree-optimization/95770 - fix SLP vectorized stmt placement compute

This fixes the vectorized stmt placement compute for the case of
external defs.

2020-06-22  Richard Biener  

PR tree-optimization/95770
* tree-vect-slp.c (vect_schedule_slp_instance): Also consider
external defs.

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

[Bug c++/95807] GCC accepts "void value not ignored as it ought to be" in function template

[haoxintu at gmail dot com]

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

--- Comment #4 from Haoxin Tu  ---
(In reply to Jonathan Wakely from comment #3)
>  The ill-formed template is not diagnosed unless you instantiate it.
> That is allowed by the standard.

Thank you Jonathan, thanks for your response.

As other major compilers reject this by default, I just suggest GCC should emit
a appropriate diagnostic message (maybe a warning is fine).

Just a suggestion, please understand if it is inappropriate ~

[Bug middle-end/95810] Spurious UBSan warning when computing the opposite of the absolute value of INT_MIN

[jakub at gcc dot gnu.org]

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

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

Untested fix.

[Bug c++/95807] GCC accepts "void value not ignored as it ought to be" in function template

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
(In reply to Haoxin Tu from comment #2)
> (In reply to Andrew Pinski from comment #1)
> > I think it is rejected at instanition time.
> 
> Hi, Andrew. Shouldn't it be rejected at compiling time?

It could be, but that is not required by the C++ standard.

> Is this case similar with bug.cc?

Yes. The ill-formed template is not diagnosed unless you instantiate it. That
is allowed by the standard.

[Bug fortran/95812] [10/11 Regression] ICE in gfc_dep_resolver since r10-2114

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

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

--- Comment #1 from Thomas Koenig  ---
I'll take a look.

[Bug middle-end/95810] Spurious UBSan warning when computing the opposite of the absolute value of INT_MIN

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
   Last reconfirmed||2020-06-22
 CC||jakub at gcc dot gnu.org
 Status|UNCONFIRMED |ASSIGNED

[Bug c++/95813] New: Making static member function a coroutine may cause "defined but not used" warning for destroy(frame*) function

[gleb at scylladb dot com]

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

Bug ID: 95813
   Summary: Making static member function a coroutine may cause
"defined but not used" warning for destroy(frame*)
function
   Product: gcc
   Version: 10.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gleb at scylladb dot com
  Target Milestone: ---

Compiling the code below with -Wall emits:

warn.cc:37:5: warning: ^Xגvoid
xxx::_ZN3xxx4funcEv.destroy(xxx::func()::_ZN3xxx4funcEv.frame*)^Yג defined but
not used [-Wunused-function]

and if foo() is uncommented the code compiles fine.

If should be OK to have the static member function in a header without getting
the warning.

#include 
#include 
#include 
#include 

template 
class lazy {
T _v = 0;
public:
lazy() {}
bool await_ready() {return true;}
void await_suspend(auto x) noexcept {}
T await_resume() { return _v; }
};

namespace std {

template 
struct coroutine_traits, Args...> {
struct promise_type {
suspend_always initial_suspend() const { return {}; }
suspend_always final_suspend() const { return {}; }
void return_value(T val) {}
lazy get_return_object() {
return lazy();
}
void unhandled_exception() {
std::terminate();
}
};
};
}

struct xxx {
static lazy func() {
co_return 1;
}
};

#if 0
lazy foo() {
co_return co_await xxx::func();
}
#endif

[Bug fortran/95614] ICE in build_field, at fortran/trans-common.c:301

[drikosev at gmail dot com]

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

Ev Drikos  changed:

   What|Removed |Added

 CC||drikosev at gmail dot com

--- Comment #3 from Ev Drikos  ---

Hello,

Perhaps, an additional check in file resolve.c might be necessary, or
one would have to adjust one-two "common*.f" test cases.

Hope this helps,
Ev. Drikos

--

   if (gsym && gsym->type != GSYM_UNKNOWN && gsym->type != GSYM_COMMON)
+  gsym = gfc_find_gsymbol (gfc_gsym_root, csym->name);
+  if (gsym && gsym->type != GSYM_UNKNOWN)
+   gfc_error_now ("Global entity %qs at %L cannot appear in a "
+   "COMMON block at %L", gsym->name,
+   >where, >common_block->where);
+

[Bug tree-optimization/95804] ice in generate_code_for_partition, at tree-loop-distribution.c:1323

[amker at gcc dot gnu.org]

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

--- Comment #2 from bin cheng  ---
(In reply to Richard Biener from comment #1)
> Confirmed.  We seem to end up with a reduction partition not in the last
> position thus miss some required partition merging.
Sorry for the breakage.

Whew, this part IS can of worms.  Will investigate it.

[Bug bootstrap/94998] GCC 10 won't configure for host=x86, build!=host, linker=bfd due to CET

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

--- Comment #8 from Richard Biener  ---
HJ, can you please backport?

[Bug middle-end/95810] Spurious UBSan warning when computing the opposite of the absolute value of INT_MIN

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|tree-optimization   |middle-end

--- Comment #1 from Andrew Pinski  ---
It should have became uabs instead.

[Bug other/95811] configure fails when crossing to x86_64: checking for CET support...configure: error: cannot run test program while cross compiling

[slyfox at inbox dot ru]

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

Sergei Trofimovich  changed:

   What|Removed |Added

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

--- Comment #1 from Sergei Trofimovich  ---
Was probably fixed in
https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=d17cdc17c90ce77cb90c569322c1f241d3530cec

which added cross_compiling case. My apologies for the noise.

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

[Bug bootstrap/94998] GCC 10 won't configure for host=x86, build!=host, linker=bfd due to CET

[slyfox at inbox dot ru]

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

Sergei Trofimovich  changed:

   What|Removed |Added

 CC||slyfox at inbox dot ru

--- Comment #7 from Sergei Trofimovich  ---
*** Bug 95811 has been marked as a duplicate of this bug. ***

[Bug fortran/95812] [10/11 Regression] ICE in gfc_dep_resolver since r10-2114

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P4
   Keywords||ice-on-valid-code

[Bug bootstrap/95805] [11 regression] gcc/recog.h:301:30: error: too many arguments to function call, expected 1, have 2

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC|rsandifo at sources dot redhat.com |rsandifo at gcc dot 
gnu.org
   Keywords||build
   Target Milestone|--- |11.0
Version|unknown |11.0

[Bug tree-optimization/95804] ice in generate_code_for_partition, at tree-loop-distribution.c:1323

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

Version|unknown |11.0
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-06-22
   Keywords||needs-bisection
  Component|target  |tree-optimization
 CC||amker at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed.  We seem to end up with a reduction partition not in the last
position thus miss some required partition merging.

[Bug tree-optimization/95801] Optimiser does not exploit the fact that an integer divisor cannot be zero

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
Created attachment 48768
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48768=edit
prototype

Here is the WIP patch, work is suspended.  There may be a duplicate bug about
this.

[Bug tree-optimization/95801] Optimiser does not exploit the fact that an integer divisor cannot be zero

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
I have a patch exploiting this but it faces some correctness issues in the
propagators where some of them instantiate the assumptions before simplifying
the stmts themselves.