[Bug tree-optimization/96187] GCC at -O2 generates branch for code that should be branch-free

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Host|x86_64  |
 Status|UNCONFIRMED |NEW
 Target|x86_64  |x86_64-*-*
   Keywords||missed-optimization
 Ever confirmed|0   |1
   Last reconfirmed||2020-07-14

--- Comment #1 from Richard Biener  ---
Confirmed.  The issue seems to be PRE removing the RTL if-conversion
opportunity by eliding the final bitwise OR on the path with a literal zero:

   _2 = MEM[(const uint8_t *)b_10(D) + 1B];
   if (_2 != 0)
-goto ; [50.00%]
-  else
 goto ; [50.00%]
+  else
+goto ; [50.00%]

-   [local count: 536870913]:
+   [local count: 536870912]:
+  _19 = iftmp.3_7 | 4;

[local count: 1073741824]:
-  # iftmp.4_8 = PHI <4(4), 0(5)>
-  _3 = iftmp.3_7 | iftmp.4_8;
-  _4 = _3 * 4;
+  # iftmp.4_8 = PHI <4(5), 0(4)>
+  # prephitmp_20 = PHI <_19(5), iftmp.3_7(4)>
+  _4 = prephitmp_20 * 4;
   _5 = 4837447714461450240 >> _4;
   _6 = (int) _5;
   len_11 = _6 & 15;


in the get_length4 case this pattern doesn't occur since the branch has
been removed by early folding and/or gimplification already.

[Bug target/96186] [11 regressoion] ICE: Unrecognizable insn since r11-1970-fab263ab0fc10ea08409b80afa7e8569438b8d28

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |11.0

--- Comment #1 from Richard Biener  ---
There's a duplicate bug IIRC.

[Bug c++/96185] Enhancement: Please add a builtin to count bindings in [dcl.struct.bind]

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

Version|unknown |11.0
   Severity|normal  |enhancement

[Bug middle-end/96192] New: tree-inline.c(copy_decl_for_dup_finish) should preserve decl alignment in copy

[skpgkp2 at gmail dot com]

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

Bug ID: 96192
   Summary: tree-inline.c(copy_decl_for_dup_finish) should
preserve decl alignment in copy
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: skpgkp2 at gmail dot com
CC: hjl.tools at gmail dot com
  Target Milestone: ---
Target: x86_64-*-* i?86-*-*

tree-inline.c function copy_decl_for_dup_finish should preserve local decl
alignment in copy.

This issue appears when local decl alignment get lowered by target hook, but
during the inline, copy may get different alignment than original decl.

This blocks PR95237.

Test case:

$ cat foo.c
int a;

long long 
b (void)
{
}

void
c (void)
{
  if (b())
a = 1;
}

$gcc -m32 -mpreferred-stack-boundary=2 -Os -c foo.c
during GIMPLE pass: adjust_alignment
foo.c: In function ??c??:
foo.c:12:1: internal compiler error: in execute, at adjust-alignment.c:74
   12 | c (void)
  | ^
0x20bc351 execute
/local/skpandey/gccwork/gccwork/pr95237_1/gcc/adjust-alignment.c:74
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug target/96191] New: aarch64 stack_protect_test canary leak

[wilson at gcc dot gnu.org]

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

Bug ID: 96191
   Summary: aarch64 stack_protect_test canary leak
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wilson at gcc dot gnu.org
  Target Milestone: ---

Given a simple testcase
extern int sub (int);

int
main (void)
{
  sub (10);
  return 0;
}
commpiling with -O -S -fstack-protector-all -mstack-protector-guard=global
in the epilogue for the canary check I see
ldr x1, [sp, 40]
ldr x0, [x19, #:lo12:__stack_chk_guard]
eor x0, x1, x0
cbnzx0, .L4
Both x0 and x1 have the stack protector canary loaded into them, and the eor
clobbers x0, but x1 is left alone.  This means the value of the canary is
leaking from the epilogue.  The canary value is never supposed to survive in a
register outside the stack protector patterns.

A powerpc64-linux toolchain build with the same testcase and options generates
lwz 9,28(1)
lwz 10,0(31)
xor. 9,9,10
li 10,0
bne- 0,.L4
and note that it clears the second register after the xor to prevent the canary
leak.  The aarch64 stack_protect_test pattern should do the same thing.

[Bug c++/59978] C++11 Non-Type-Template-Parameter Pack Expansion not working according to standard

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #2 from Marek Polacek  ---
Right, thanks, fixed in r224162.  That came without a test so I'll add this
one.

[Bug c++/59978] C++11 Non-Type-Template-Parameter Pack Expansion not working according to standard

[richard-gccbugzilla at metafoo dot co.uk]

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

Richard Smith  changed:

   What|Removed |Added

 CC||richard-gccbugzilla@metafoo
   ||.co.uk

--- Comment #1 from Richard Smith  ---
This appears to have been fixed in GCC 5.2 onwards.

[Bug driver/96190] New: --enable-default-pie on sparc uses crtbeginS.o (correct) and crtend.o (incorrect)

[slyfox at inbox dot ru]

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

Bug ID: 96190
   Summary: --enable-default-pie on sparc uses crtbeginS.o
(correct) and crtend.o (incorrect)
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: driver
  Assignee: unassigned at gcc dot gnu.org
  Reporter: slyfox at inbox dot ru
  Target Milestone: ---

The side-effect of the crtbeginS.o/crtend.o mismatch are:
- R_SPARC_NONE relocations in final executables: https://sourceware.org/PR26236
- TEXTRELs in binaries

Simple reproducer:

$ echo 'int main(){}' | sparc-unknown-linux-gnu-gcc -x c - -o a
/usr/libexec/gcc/sparc-unknown-linux-gnu/ld: warning: creating a DT_TEXTREL in
object
$ echo 'int main(){}' | sparc-unknown-linux-gnu-gcc -x c - -o a -no-pie
$ echo 'int main(){}' | sparc-unknown-linux-gnu-gcc -x c - -o a -pie

gcc is built as:

"""
Using built-in specs.
COLLECT_GCC=/usr/bin/sparc-unknown-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/sparc-unknown-linux-gnu/10.1.0/lto-wrapper
Target: sparc-unknown-linux-gnu
Configured with:
/tmp/portage-tmpdir/portage/cross-sparc-unknown-linux-gnu/gcc-10.1.0-r2/work/gcc-10.1.0/configure
--host=x86_64-pc-linux-gnu --target=sparc-unknown-linux-gnu
--build=x86_64-pc-linux-gnu --prefix=/usr
--bindir=/usr/x86_64-pc-linux-gnu/sparc-unknown-linux-gnu/gcc-bin/10.1.0
--includedir=/usr/lib/gcc/sparc-unknown-linux-gnu/10.1.0/include
--datadir=/usr/share/gcc-data/sparc-unknown-linux-gnu/10.1.0
--mandir=/usr/share/gcc-data/sparc-unknown-linux-gnu/10.1.0/man
--infodir=/usr/share/gcc-data/sparc-unknown-linux-gnu/10.1.0/info
--with-gxx-include-dir=/usr/lib/gcc/sparc-unknown-linux-gnu/10.1.0/include/g++-v10
--with-python-dir=/share/gcc-data/sparc-unknown-linux-gnu/10.1.0/python
--enable-languages=c,c++,fortran --enable-obsolete --enable-secureplt
--disable-werror --with-system-zlib --enable-nls --without-included-gettext
--enable-checking=release --with-bugurl=https://bugs.gentoo.org/
--with-pkgversion='Gentoo 10.1.0-r2 p3' --disable-esp --enable-libstdcxx-time
--enable-poison-system-directories --with-sysroot=/usr/sparc-unknown-linux-gnu
--disable-bootstrap --enable-__cxa_atexit --enable-clocale=gnu
--disable-multilib --disable-fixed-point --enable-targets=all --enable-libgomp
--disable-libmudflap --disable-libssp --disable-libada --disable-systemtap
--enable-vtable-verify --without-zstd --enable-lto --without-isl
--enable-default-pie --enable-default-ssp
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.1.0 (Gentoo 10.1.0-r2 p3)
"""

I think the bug here is in SPEC files where crtendS.o is only pulled by
explicit options:

  gcc/config/sparc/linux.h:  "%{shared|pie:crtendS.o%s;:crtend.o%s} crtn.o%s\
  gcc/config/sparc/linux64.h:  "%{shared|pie:crtendS.o%s;:crtend.o%s} crtn.o%s\

AFAIu it should be something similar to generic case:

  gcc/config/gnu-user.h: shared|static-pie|" PIE_SPEC ":crtendS.o%s; \

Does it sound about right? Should other targets follow as well? Specifically:

gcc/config/alpha/linux.h:   crti.o%s
%{static:crtbeginT.o%s;shared|pie:crtbeginS.o%s;:crtbegin.o%s}"
gcc/config/alpha/linux.h:   crti.o%s
%{static:crtbeginT.o%s;shared|pie:crtbeginS.o%s;:crtbegin.o%s}"
gcc/config/alpha/linux.h:   %{shared|pie:crtendS.o%s;:crtend.o%s} crtn.o%s"

gcc/config/bfin/linux.h:   crti.o%s %{shared|pie:crtbeginS.o%s;:crtbegin.o%s}"

gcc/config/c6x/uclinux-elf.h:  "%{!shared:crt1%O%s} crti%O%s
%{shared|pie:crtbeginS.o%s;:crtbegin.o%s}"

gcc/config/csky/csky-linux-elf.h:  crti.o%s
%{static:crtbeginT.o%s;shared|pie:crtbeginS.o%s;:crtbegin.o%s}"
gcc/config/csky/csky-linux-elf.h:  "%{shared|pie:crtendS.o%s;:crtend.o%s}
crtn.o%s"

gcc/config/frv/linux.h:   crti.o%s
%{static:crtbeginT.o%s;shared|pie:crtbeginS.o%s;:crtbegin.o%s}"
gcc/config/frv/linux.h:  "%{shared|pie:crtendS.o%s;:crtend.o%s} crtn.o%s"

gcc/config/ia64/linux.h:   crti.o%s %{shared|pie:crtbeginS.o%s;:crtbegin.o%s}"
gcc/config/ia64/linux.h:   crti.o%s %{shared|pie:crtbeginS.o%s;:crtbegin.o%s}"
gcc/config/ia64/linux.h:   %{shared|pie:crtendS.o%s;:crtend.o%s} crtn.o%s"

gcc/config/m32r/linux.h:   crti.o%s
%{static:crtbeginT.o%s;shared|pie:crtbeginS.o%s;:crtbegin.o%s}"
gcc/config/m32r/linux.h:  "%{shared|pie:crtendS.o%s;:crtend.o%s} crtn.o%s"

gcc/config/sparc/linux.h:  "%{shared|pie:crtendS.o%s;:crtend.o%s} crtn.o%s\
gcc/config/sparc/linux64.h:  "%{shared|pie:crtendS.o%s;:crtend.o%s} crtn.o%s\

[Bug driver/81658] gcc configured with --enable-default-pie on SPARC produces buggy executable from working .o files

[slyfox at inbox dot ru]

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

Sergei Trofimovich  changed:

   What|Removed |Added

 CC||slyfox at inbox dot ru

--- Comment #1 from Sergei Trofimovich  ---
I think it was a https://sourceware.org/PR22638

[Bug target/95952] [8 Regression] gcc-8 bootstrap failure on powerpc64-linux

[willschm at gcc dot gnu.org]

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

--- Comment #14 from Will Schmidt  ---
(In reply to Will Schmidt from comment #13)
> Created attachment 48871 [details]
> proposed patch
> 
> Attached patch appears sufficient to resolve the issue on the 970 based box
> I have access to.

Mikael, would be appreciated if you could give that a run-through to confirm it
fixes the problem on your system.
thanks,

[Bug target/95952] [8 Regression] gcc-8 bootstrap failure on powerpc64-linux

[willschm at gcc dot gnu.org]

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

--- Comment #13 from Will Schmidt  ---
Created attachment 48871
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48871&action=edit
proposed patch

Attached patch appears sufficient to resolve the issue on the 970 based box I
have access to.

[Bug libgcc/96173] double to _Decimal64 or _Decimal128 conversion with BID generates 3 MB of code

[joseph at codesourcery dot com]

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

--- Comment #5 from joseph at codesourcery dot com  ---
I expect there's a speed/space trade-off here.  You can use large tables 
for the conversions with less computation, or small tables with more 
computation (and the BID implementation in libgcc uses large tables).

The DPD implementation avoids the whole question of how to convert 
efficiently between decimal and binary FP by doing such conversions via 
strings (which may end up using large tables or less efficient algorithms 
in the libc code used for binary FP / string conversions; if you know the 
source and target formats in advance, there's more scope for statically 
determined bounds on how much internal precision is needed to get 
correctly rounded results for all inputs of the given floating-point 
format).

[Bug fortran/86268] [9.0] Error on correct code with PDTs

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

[Bug fortran/85942] ICE with PDTs

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

[Bug fortran/86148] parameterized type compile time error

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

[Bug fortran/91022] A suspicious code in fortran/decl.c

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

[Bug fortran/69654] ICE in gfc_trans_structure_assign

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

[Bug fortran/64120] [F03] Wrong handling of allocatable character string

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

[Bug libfortran/92836] segfault with inquire()

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

[Bug fortran/92959] ICE in gfc_conv_associated, at fortran/trans-intrinsic.c:8634

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

[Bug fortran/88632] [F08] function contained in module invisible to submodule unless declared public

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

[Bug fortran/94324] [10/11 regression] gfortran.dg/default_format_1.f90 etc. FAIL on 32-bit Solaris/x86

[dominiq at lps dot ens.fr]

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

--- Comment #5 from Dominique d'Humieres  ---
> > --- Comment #3 from Dominique d'Humieres  ---
> > Is it a fortran bug or a bug in a Solaris lib?
>
> The latter, I suspect (or rather: the Studio compiler used to build
> them).  However, I'd like to keep the PR open until that's confirmed.
> Didn't have time to investigate yet.

Shouldn't the component moved to target?

[Bug fortran/94324] [10/11 regression] gfortran.dg/default_format_1.f90 etc. FAIL on 32-bit Solaris/x86

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #3 from Dominique d'Humieres  ---
> Is it a fortran bug or a bug in a Solaris lib?

The latter, I suspect (or rather: the Studio compiler used to build
them).  However, I'd like to keep the PR open until that's confirmed.
Didn't have time to investigate yet.

[Bug fortran/94324] [10/11 regression] gfortran.dg/default_format_1.f90 etc. FAIL on 32-bit Solaris/x86

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Last reconfirmed||2020-07-13
 Ever confirmed|0   |1
 Status|UNCONFIRMED |WAITING

--- Comment #3 from Dominique d'Humieres  ---
Is it a fortran bug or a bug in a Solaris lib?

[Bug fortran/37336] [F03] Finish derived-type finalization

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

[Bug fortran/92976] [8 Regression][OOP] ICE in trans_associate_var, at fortran/trans-stmt.c:1963

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

[Bug fortran/88247] [8/9/10/11 Regression] ICE in get_array_ctor_var_strlen, at fortran/trans-array.c:2068

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

[Bug fortran/94246] [9 Regression] valgrind error for ./gfortran.dg/bessel_5.f90 since r9-1566-g87c789f1c0b2df41

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

[Bug fortran/93794] [8/9/10/11 Regression] ICE in gfc_conv_component_ref, at fortran/trans-expr.c:2497

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

[Bug fortran/93833] [8/9/10/11 Regression] ICE in trans_array_constructor, at fortran/trans-array.c:2566

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

[Bug target/96189] Failure to use eflags from cmpxchg on x86

[gabravier at gmail dot com]

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

--- Comment #1 from Gabriel Ravier  ---
PS : The extraneous movzx is already reported at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96176

[Bug fortran/93701] ICE on associate of wrongly accessed array

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

[Bug fortran/31593] Invariant DO loop variables and subroutines

[dominiq at lps dot ens.fr]

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

--- Comment #47 from Dominique d'Humieres  ---
The assignee is Tobias Schlüter, but the PR is not marked as assigned.
Is Tobias still interested? If no, the PR should be unassigned.

[Bug target/96189] New: Failure to use eflags from cmpxchg on x86

[gabravier at gmail dot com]

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

Bug ID: 96189
   Summary: Failure to use eflags from cmpxchg on x86
   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: ---

bool f(unsigned char* addr, unsigned char old_val, unsigned char new_val)
{
auto old_val_cpy = old_val;
__atomic_compare_exchange_n(addr, &old_val, new_val, 0, 0, 0);
return old_val == old_val_cpy;
}

With -O3, LLVM outputs this :

f(unsigned char*, unsigned char, unsigned char): # @f(unsigned char*, unsigned
char, unsigned char)
  mov eax, esi
  lock cmpxchg byte ptr [rdi], dl
  sete al
  ret

GCC outputs this :

f(unsigned char*, unsigned char, unsigned char):
  mov eax, esi
  movzx edx, dl
  lock cmpxchg BYTE PTR [rdi], dl
  cmp al, sil
  sete al
  ret

GCC could use the EFLAGS generated from cmpxchg, but it does not.

[Bug fortran/93736] Add .f18 and .F18 file suffixes

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

[Bug target/94891] aarch64: there is no way to strip PAC from a return address in c code

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r10-8485-geb41624df3bfee5dd4183738f57e1cf54a2a32eb
Author: Szabolcs Nagy 
Date:   Thu Jun 4 13:42:16 2020 +0100

aarch64: fix __builtin_eh_return with pac-ret [PR94891]

Currently __builtin_eh_return takes a signed return address, which can
cause ABI and API issues: 1) pointer representation problems if the
address is passed around before eh return, 2) the source code needs
pac-ret specific changes and needs to know if pac-ret is used in the
current frame, 3) signed address may not be representible as void *
(with ilp32 abi).

Using address signing to protect eh return is ineffective because the
instruction sequence in the unwinder that starts from the address
signing and ends with a ret can be used as a return to anywhere gadget.
Using indirect branch istead of ret with bti j landing pads at the
target can reduce the potential of such gadget, which also implies
that __builtin_eh_return should not take a signed address.

This is a big hammer fix to the ABI and API issues: it turns pac-ret
off for the caller completely (not just on the eh return path).  To
harden the caller against ROP attacks, it should use indirect branch
instead of ret, this is not attempted so the patch remains small and
backportable.

2020-07-13  Szabolcs Nagy  

gcc/ChangeLog:

PR target/94891
* config/aarch64/aarch64.c
(aarch64_return_address_signing_enabled):
Disable return address signing if __builtin_eh_return is used.

gcc/testsuite/ChangeLog:

PR target/94891
* gcc.target/aarch64/return_address_sign_1.c: Update test.
* gcc.target/aarch64/return_address_sign_b_1.c: Likewise.

(cherry picked from commit 2bc95be3bb8c8138e2e87c1c11c84bfede989d61)

[Bug libgcc/96001] aarch64: bti is missing from lse.S when built with branch protection

[cvs-commit at gcc dot gnu.org]

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

--- Comment #2 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Szabolcs Nagy :

https://gcc.gnu.org/g:8475641c2160262a33c553eee158f075c990fab7

commit r10-8482-g8475641c2160262a33c553eee158f075c990fab7
Author: Szabolcs Nagy 
Date:   Thu Jul 2 17:11:56 2020 +0100

aarch64: Fix BTI support in libgcc [PR96001]

lse.S did not have the GNU property note markup and the BTI c
instructions that are necessary when it is built with branch
protection.

The notes are only added when libgcc is built with branch
protection, because old linkers mishandle the note (merge
them incorrectly or emit warnings), the BTI instructions
are added unconditionally.

Note: BTI c is only necessary at function entry if the function
may be called indirectly, currently lse functions are not called
indirectly, but BTI is added for ABI reasons e.g. to allow
linkers later to emit stub code with indirect jump.

2020-07-09  Szabolcs Nagy  

libgcc/ChangeLog:

PR target/96001
* config/aarch64/lse.S: Add BTI marking and related definitions,
and add BTI c to function entries.

(cherry picked from commit f0f62fa0320762119446893c67cb52934bc5a05e)

[Bug target/94891] aarch64: there is no way to strip PAC from a return address in c code

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r10-8484-ge14149f66edebe16c48aeddb4c1f1abd00874eed
Author: Szabolcs Nagy 
Date:   Tue Jun 2 16:44:41 2020 +0100

aarch64: fix return address access with pac [PR94891][PR94791]

This is a big hammer fix for __builtin_return_address (PR target/94891)
returning signed addresses (sometimes, depending on wether lr happens
to be signed or not at the time of call which depends on optimizations),
and similarly -pg may pass signed return address to _mcount
(PR target/94791).

At the time of return address expansion we don't know if it's signed or
not so it is done unconditionally.

2020-07-13  Szabolcs Nagy  

gcc/ChangeLog:

PR target/94891
PR target/94791
* config/aarch64/aarch64-protos.h (aarch64_return_addr_rtx):
Declare.
* config/aarch64/aarch64.c (aarch64_return_addr_rtx): New.
(aarch64_return_addr): Use aarch64_return_addr_rtx.
* config/aarch64/aarch64.h (PROFILE_HOOK): Likewise.

(cherry picked from commit 463a54e5d4956143f81c1f23b91cbd2d93855741)

[Bug target/94891] aarch64: there is no way to strip PAC from a return address in c code

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r10-8486-gc24e8063ef5f4a462bedb1f8f71409c8116b26b0
Author: Szabolcs Nagy 
Date:   Thu Jun 4 09:33:35 2020 +0100

libgcc: fix the handling of return address mangling [PR94891]

Mangling, currently only used on AArch64 for return address signing,
is an internal representation that should not be exposed via

  __builtin_return_address return value,
  __builtin_eh_return handler argument,
  _Unwind_DebugHook handler argument.

Note that a mangled address might not even fit into a void *, e.g.
with AArch64 ilp32 ABI the return address is stored as 64bit, so
the mangled return address cannot be accessed via _Unwind_GetPtr.

This patch changes the unwinder hooks as follows:

MD_POST_EXTRACT_ROOT_ADDR is removed: root address comes from
__builtin_return_address which is not mangled.

MD_POST_EXTRACT_FRAME_ADDR is renamed to MD_DEMANGLE_RETURN_ADDR,
it now operates on _Unwind_Word instead of void *, so the hook
should work when return address signing is enabled on AArch64 ilp32.
(But for that __builtin_aarch64_autia1716 should be fixed to operate
on 64bit input instead of a void *.)

MD_POST_FROB_EH_HANDLER_ADDR is removed: it is the responsibility of
__builtin_eh_return to do the mangling if necessary.

2020-07-13  Szabolcs Nagy  

libgcc/ChangeLog:

PR target/94891
* config/aarch64/aarch64-unwind.h (MD_POST_EXTRACT_ROOT_ADDR):
Remove.
(MD_POST_FROB_EH_HANDLER_ADDR): Remove.
(MD_POST_EXTRACT_FRAME_ADDR): Rename to ...
(MD_DEMANGLE_RETURN_ADDR): This.
(aarch64_post_extract_frame_addr): Rename to ...
(aarch64_demangle_return_addr): This.
(aarch64_post_frob_eh_handler_addr): Remove.
* unwind-dw2.c (uw_update_context): Demangle return address.
(uw_frob_return_addr): Remove.

(cherry picked from commit b097c7a27fb0796b2653a1d003cbf6b7a69d8961)

[Bug target/94791] aarch64: -pg profiling is broken with pac-ret

[cvs-commit at gcc dot gnu.org]

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

--- Comment #2 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Szabolcs Nagy :

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

commit r10-8484-ge14149f66edebe16c48aeddb4c1f1abd00874eed
Author: Szabolcs Nagy 
Date:   Tue Jun 2 16:44:41 2020 +0100

aarch64: fix return address access with pac [PR94891][PR94791]

This is a big hammer fix for __builtin_return_address (PR target/94891)
returning signed addresses (sometimes, depending on wether lr happens
to be signed or not at the time of call which depends on optimizations),
and similarly -pg may pass signed return address to _mcount
(PR target/94791).

At the time of return address expansion we don't know if it's signed or
not so it is done unconditionally.

2020-07-13  Szabolcs Nagy  

gcc/ChangeLog:

PR target/94891
PR target/94791
* config/aarch64/aarch64-protos.h (aarch64_return_addr_rtx):
Declare.
* config/aarch64/aarch64.c (aarch64_return_addr_rtx): New.
(aarch64_return_addr): Use aarch64_return_addr_rtx.
* config/aarch64/aarch64.h (PROFILE_HOOK): Likewise.

(cherry picked from commit 463a54e5d4956143f81c1f23b91cbd2d93855741)

[Bug target/94891] aarch64: there is no way to strip PAC from a return address in c code

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r10-8487-g7e5bb3ce7c784844b1e14b754b58dee08ed5bac8
Author: Szabolcs Nagy 
Date:   Thu May 28 10:28:30 2020 +0100

doc: Clarify __builtin_return_address [PR94891]

The expected semantics and valid usage of __builtin_return_address is
not clear since it exposes implementation internals that are normally
not meaningful to portable c code.

This documentation change tries to clarify the semantics in case the
return address is stored in a mangled form. This affects AArch64 when
pointer authentication is used for the return address signing (i.e.
-mbranch-protection=pac-ret).

2020-07-13  Szabolcs Nagy  

gcc/ChangeLog:

PR target/94891
* doc/extend.texi: Update the text for  __builtin_return_address.

(cherry picked from commit 6a391e06f953c3390b14020d8cacb6d55f81b2b9)

[Bug fortran/96158] Debug symbols not emitted for module common variables

[amelvill at umich dot edu]

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

--- Comment #11 from AJM  ---
Thanks for all your suggestions, they're very helpful!

>'-falign-commons'
> By default, 'gfortran' enforces **proper** alignment of all variables
> in a 'COMMON' block by padding them as needed...

I am not sure what "proper" means in this context, proper for which language,
which architecture? All of them? What's "proper" for AMD64 isn't proper for
i386, and what's proper for Fortran might not be proper for C, right? What
about byte endianness?

> My guess would be that a common block
> is simply considered to be a chunk of memory under
> DWARF5.
> It provides a base address and one needs to
> know how to compute offsets into that chunk (including
> dealing with any padding).

My tests seem to show that this is the case so far too. It seems a bit weird to
me because GCC is able to handle things like individual int "extern" variables
in C, which would seem to have a very similar issue (memory stored in a
different object file, in an ad-hoc manner with no prescribed structure or
packing as an interface).

The only thing that I can think of that's different is the fact that gfortran
generates a .mod file, which I'm guessing (?) is some kind of binary interface
definition (like a precompiled header?); I'm really not sure what it does, but
there is no .mod file generated for "othermodule", only for somemodule (which
matches the file name).

At one point I was just wondering if all I needed to do was generate a .mod
file for othermodule somehow (the common 'module'), but I noticed that the
symbols were stored directly in the .o file, and I started to wonder if the
.mod file served any purpose at all.

>  the Fortran processor (in this case gfortran)
> and its companion C processor (gcc) have the same conventions regarding
> layout of variables etc.

I was hoping this was the case, thanks for confirming that.

> Maybe, if you show the code above to whoever's in charge, that might
> cause that person to reconsider :-)

We've discussed it at great length, these sorts of things have to happen in
stages I think. 

I have informed them of the risks and downsides of not doing this now (I have
been detailed and clear in my findings, including possible portability /
reliability problems and UB problems, additional time spent doing maintenance,
and now also debugging issues). They have decided to accept the risks and
inefficiencies.

Given the circumstances a rewrite is not on the table; the decision is final
and my job now is to support them as best I can. It's hard to allocate limited
resources, there is no lack of work here. That's about all I can say on that I
guess. This is not the first time I have entered a job with a codebase that had
UB, in fact, I would say I have never NOT had a problem with UB at any place
I've ever worked. Personally, I work hard not to introduce more, fix it when I
can, and try and help coders avoid adding more.

[Bug target/95151] [9/10/11 Regression] Add cmpmemM pattern for -minline-all-stringops

[hjl.tools at gmail dot com]

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

Bug 95443 Summary: cmpstrnqi patterns update string length
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95443

   What|Removed |Added

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

[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

--- Comment #7 from Marek Polacek  ---
// PR c++/96179

template struct vector
{
  void push_back(T) { }
};

struct dummy{
int a;
};

void Modify_Dummy(dummy &d){
d.a=1;
}

template  void Templated_Function(){
vector A;
A.push_back(Modify_Dummy(dummy{0}));
}

int main(){
Templated_Function();
}

[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

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

[Bug c++/96179] [10/11 Regression] g++-10.1 silently doesn't push_back the return of a void function

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|ASSIGNED|RESOLVED

--- Comment #2 from Marek Polacek  ---
This is also fixed by the patch for PR 95789.  But another test is useful.

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

[Bug target/95443] cmpstrnqi patterns update string length

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

   Target Milestone|--- |11.0
 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

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

[Bug target/95443] cmpstrnqi patterns update string length

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r11-2068-g9cba898481368ce16c6a2d30ef781a82dce27c55
Author: H.J. Lu 
Date:   Mon Jul 13 10:33:47 2020 -0700

x86: Pass a copy of the string length to cmpstrnqi

cmpstrnsi expander may pass the actual string length directly to cmpstrnqi
patterns.  For cmpstrnsi, one of the strings must be a constant and
expand_builtin_strncmp rewrites the length argument to be the minimum of
the const string length and the actual string length.  But it is not the
case for cmpmemsi.  Pass a copy of the string length to cmpstrnqi patterns
to avoid changing the actual string length by cmpstrnqi patterns.

gcc/

PR target/95443
* config/i386/i386.md (cmpstrnsi): Pass a copy of the string
length to cmpstrnqi patterns.

gcc/testsuite/

PR target/95443
* gcc.target/i386/pr95443-1.c: New test.
* gcc.target/i386/pr95443-2.c: Likewise.

[Bug c++/96169] Don't provide internal lambda names in diagnostics?

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #1 from Marek Polacek  ---
Confirmed.  I think Nathan tweaked the lambda names recently.

[Bug middle-end/95270] OpenACC 'enter data attach' looks up target memory object displaced by pointer size

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:2974e1eee053496e1d43f7f2e62f5feac2aa0315

commit r10-8475-g2974e1eee053496e1d43f7f2e62f5feac2aa0315
Author: Julian Brown 
Date:   Tue Jun 9 06:21:34 2020 -0700

openacc: Set bias to zero for explicit attach/detach clauses in C and C++

This is a fix for the pointer (or array) size inadvertently being used
for the bias with attach and detach mapping kinds, for both C and C++.

2020-07-09  Julian Brown  
Thomas Schwinge  

gcc/c/
PR middle-end/95270
* c-typeck.c (c_finish_omp_clauses): Set OMP_CLAUSE_SIZE (bias) to
zero
for standalone attach/detach clauses.

gcc/cp/
PR middle-end/95270
* semantics.c (finish_omp_clauses): Likewise.

include/
PR middle-end/95270
* gomp-constants.h (gomp_map_kind): Expand comment for
attach/detach
mapping kinds.

gcc/testsuite/
PR middle-end/95270
* c-c++-common/goacc/mdc-1.c: Update expected dump output for zero
bias.

libgomp/
PR middle-end/95270
* testsuite/libgomp.oacc-c-c++-common/pr95270-1.c: New test.
* testsuite/libgomp.oacc-c-c++-common/pr95270-2.c: New test.

(cherry picked from commit 0d00fe404c162ad0cf922ca8455aa23a74042b63)

[Bug c++/96188] -Wstringop-overflow false positive on std::vector::push_back with -O3

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=94335
Summary|-Wstringop-overflow false   |-Wstringop-overflow false
   |positive|positive on
   ||std::vector::push_back with
   ||-O3

--- Comment #2 from Martin Sebor  ---
pr94335 talks about some of the issues/challenges with pointers in this
context.  (The problem discussed in pr95353 has a similar test case as this one
but it's due to an already fixed bug in the warning.)

[Bug c++/95288] Poor error message with function-scope enum definition

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

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

[Bug c++/95288] Poor error message with function-scope enum definition

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r11-2067-g6a9a3434c7396ea14c8f9c291694faea382c36dc
Author: Marek Polacek 
Date:   Mon Jul 13 13:05:06 2020 -0400

c++: Add test [PR95288]

Somewhat improved by r11-2064, though we still generate junk that seems
redundant.  But at least it says
error: expected â}â before â.â token

PR c++/95288
* g++.dg/diagnostic/enum2.C: New test.

[Bug fortran/96158] Debug symbols not emitted for module common variables

[tkoenig at gcc dot gnu.org]

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

--- Comment #10 from Thomas Koenig  ---
(In reply to AJM from comment #8)

> If you really need to know, on the C side there is a struct with fields that
> match the order and size of the variables in the common statement / module
> declaration. I am almost certain that this is not the "right way" to do
> this,

That is correct, there is a _much_ better way to do it: C interoperability.
That is standard, and gfortran will even generate your C prototypes
for you :-)

For example:

$ cat a.f90
module foo
  use iso_c_binding
  type, bind(c) :: bar
 character(c_char) :: x(4)
 integer(kind=c_int) :: y
  end type bar
  type (bar), bind(C) :: myvar
end module foo

$ gfortran -fc-prototypes -c a.f90
#include 
#ifdef __cplusplus
#include 
#define __GFORTRAN_FLOAT_COMPLEX std::complex
#define __GFORTRAN_DOUBLE_COMPLEX std::complex
#define __GFORTRAN_LONG_DOUBLE_COMPLEX std::complex
extern "C" {
#else
#define __GFORTRAN_FLOAT_COMPLEX float _Complex
#define __GFORTRAN_DOUBLE_COMPLEX double _Complex
#define __GFORTRAN_LONG_DOUBLE_COMPLEX long double _Complex
#endif

typedef struct bar {
char x[4];
int y;
} bar;
extern bar myvar;

#ifdef __cplusplus
}
#endif



> and that there is some UB there in struct packing and compiler
> decisions on the size of the variables (neither the C side nor the fortran
> side has packing pragmas, and worse, the C side uses compiler defined
> integer types like "int").

All of that is not an issue with C interoperability, because these
things just work - the Fortran processor (in this case gfortran)
and its companion C processor (gcc) have the same conventions regarding
layout of variables etc.

> Without a doubt this is not an ideal setup, a
> rewrite is probably in order to ensure portability. We don't have the time
> resources for that rewrite right now, though (and that's not my call,
> either).

Maybe, if you show the code above to whoever's in charge, that might
cause that person to reconsider :-)

[Bug target/87949] PowerPC saves CR registers across calls

[bergner at gcc dot gnu.org]

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

--- Comment #13 from Peter Bergner  ---
(In reply to Segher Boessenkool from comment #12)
> Wow, this works!  Mine :-)

Hi Segher, did you ever commit anything to help here?  Ie, can we mark this as
fixed or is it still an open issue?

[Bug c++/95288] Poor error message with function-scope enum definition

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #2 from Marek Polacek  ---
Somewhat improved by r11-2064, though we still generate junk that seem
redundant.  But at least it says
error: expected ‘}’ before ‘.’ token

[Bug c++/96188] -Wstringop-overflow false positive

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic,
   ||missed-optimization
   Last reconfirmed||2020-07-13
 CC||msebor at gcc dot gnu.org
 Blocks||88443
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #1 from Martin Sebor  ---
In bug reports please include the information requested here:
https://gcc.gnu.org/bugs/#need (specifically the compiler outptut).  Links to
external sites are not a substitute since the need not reproduce the same
problem in the future.

This form of the warning first started paying attention to dynamically
allocated memory in GCC 10.  On master, the output is as follows:

pr96188.C: In function ‘void F()’:
pr96188.C:9:18: warning: unused variable ‘fx’ [-Wunused-variable]
9 |   for (const int fx : {0}) {
  |  ^~
cc1plus: warning: writing 16 bytes into a region of size 0
[-Wstringop-overflow=]
In file included from
/build/gcc-master/x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu/bits/c++allocator.h:33,
 from
/build/gcc-master/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/allocator.h:46,
 from
/build/gcc-master/x86_64-pc-linux-gnu/libstdc++-v3/include/string:41,
 from pr96188.C:2:
/build/gcc-master/x86_64-pc-linux-gnu/libstdc++-v3/include/ext/new_allocator.h:115:41:
note: at offset 112 to an object with size 0 allocated by ‘operator new’ here
  115 |  return static_cast<_Tp*>(::operator new(__n * sizeof(_Tp)));
  |   ~~^~~

The -Wstringop-overflow warning is based on the MEM store in the abbreviated IL
below (seen in the output of the -fdump-tree-strlen option):

   [local count: 268435456]:
  _87 = operator new (96);  ;; P

  
  __cur_167 = _87 + 32; ;; P + 32

  
  __cur_172 = __cur_167 + 32;   ;; P + 64

  
  __cur_97 = __cur_172 + 32;;; P + 96

  
  MEM <__int128 unsigned> [(char * {ref-all})__cur_97 + 16B] = _119;   ;; P +
96 + 16 == P + 112

The size of the allocation is 96 (it's missing from the warning due to a known
limitation) but the offset is 112.  The warning is doing what it's designed to
do, but it's possible that bb 52 isn't reachable and GCC can't tell.  There's
one jump to bb 52, from bb 51 based on this condition:

  _84 = _87 + 96;
  if (_84 != __cur_97)
goto ; [82.57%]

so that would seem to confirm the theory.  GCC only does limited pointer value
analysis and has no support for pointer value ranges, which is why I suspect it
can't figure out that the inequality in bb 51 implies that bb 52 isn't
reachable.  There are a number of reports of this warning for code that
manipulates arrays and pointers this way.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88443
[Bug 88443] [meta-bug] bogus/missing -Wstringop-overflow warnings

[Bug ipa/96130] [10/11 Regression] ICE in analyze_function_body at gcc/ipa-fnsummary.c:2769 since r10-3199-g351e7c3b5fbd45bd

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Assignee|fxue at gcc dot gnu.org|jakub at gcc dot gnu.org
 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #11 from Jakub Jelinek  ---
Fixed for 10.2 and 11.1.

[Bug ipa/96130] [10/11 Regression] ICE in analyze_function_body at gcc/ipa-fnsummary.c:2769 since r10-3199-g351e7c3b5fbd45bd

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r10-8472-g0d03c0ee5213703ec6d9ffa632fa5298d83adaaa
Author: Jakub Jelinek 
Date:   Mon Jul 13 18:25:53 2020 +0200

ipa-fnsummary: Fix ICE with switch predicates [PR96130]

The following testcase ICEs since r10-3199.
There is a switch with default label, where the controlling expression has
range just 0..7 and there are case labels for all those 8 values, but
nothing has yet optimized away the default.
Since r10-3199, set_switch_stmt_execution_predicate sets the switch to
default label's edge's predicate to a false predicate and then
compute_bb_predicates propagates the predicates through the cfg, but false
predicates aren't really added.  The caller of compute_bb_predicates
in one place handles NULL bb->aux as false predicate:
  if (fbi.info)
{
  if (bb->aux)
bb_predicate = *(predicate *) bb->aux;
  else
bb_predicate = false;
}
  else
bb_predicate = true;
but then in two further spots that the patch below is changing
it assumes bb->aux must be non-NULL.  Those two spots are guarded by a
condition that is only true if fbi.info is non-NULL, so I think the right
fix is to treat NULL aux as false predicate in those spots too.

2020-07-13  Jakub Jelinek  

PR ipa/96130
* ipa-fnsummary.c (analyze_function_body): Treat NULL bb->aux
as false predicate.

* gcc.dg/torture/pr96130.c: New test.

(cherry picked from commit 776e48e0931db69f158f40e5cb8e15463d879a42)

[Bug fortran/96158] Debug symbols not emitted for module common variables

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #9 from Steve Kargl  ---
On Mon, Jul 13, 2020 at 03:44:13PM +, amelvill at umich dot edu wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96158
> 
> --- Comment #8 from AJM  ---
> > > >> I won't comment on the questionable programming idiom of placing
> > > >> a common block in a module, which kind of defeats the niceties of
> > > >> a module.
> > > > If somebody wants to transition your code from using common blocks to
> > > > modules, that is a good way to proceed.   When all the direct usage
> > > > of the common block have been removed, you can then remove the
> > > > COMMON statement from the module.
> > > 
> > > This is the case, more or less. I didn't write the code that did this.
> > > 
> > > I would be quite happy to see the common blocks get moved to a module,
> > > but to make things a bit more dangerous on that side, these variables
> > > are bound to a C variable.
> > Do you mean the variable is declared with BIND(C)?
> > If so, you should be getting an error.
> 
> The bind statement would look like this, directly under the "common" 
> statement,
> inside somemodule.f90:
> 
> module somemodule
> 
> integer*8moduleVar !then many more variables
> 
> common /othermodule/  moduleVar !then many more variables
> bind(C, name="othermodule") :: /othermodule/
> 
> end module
> 
> The program, with the bind statement added, compiles without errors. 

Ah, I misunderstood what you wrote.  I thought you meant
you had instances of something like

integer*8, bind(c) :: modulevar
common /othermodule/  moduleVar

in the module.  That's invalid, and gfortran must issue an error
as it is a numbered constraint.  I'll need to go look at the
Fortran standard about bind(c) and named common blocks.

> If you really need to know, on the C side there is a struct with fields that
> match the order and size of the variables in the common statement / module
> declaration. I am almost certain that this is not the "right way" to do this,
> and that there is some UB there in struct packing and compiler decisions on 
> the
> size of the variables (neither the C side nor the fortran side has packing
> pragmas, and worse, the C side uses compiler defined integer types like 
> "int").
> Without a doubt this is not an ideal setup, a rewrite is probably in order to
> ensure portability. We don't have the time resources for that rewrite right
> now, though (and that's not my call, either).

Oh. That does look error prone.  The correct way, if you're 
working on improvements to the code, would be to use a derived
type on the Fortran side that matches a struct on the C side.
I would need check on whether you need to use a SEQUENCEd derived
type, and what other restrictions apply (e.g., no allocatable
components etc).

> While I was making a minimal example I originally thought bind was the root
> cause, but I eliminated it as the source of the problem (I found that I could
> reproduce the issue with only common). I removed it to try and make the most
> minimal example possible. 

Does the -fno-align-common option help you.  The manual says

'-falign-commons'
 By default, 'gfortran' enforces proper alignment of all variables
 in a 'COMMON' block by padding them as needed.  On certain
 platforms this is mandatory, on others it increases performance.
 If a 'COMMON' block is not declared with consistent data types
 everywhere, this padding can cause trouble, and
 '-fno-align-commons' can be used to disable automatic alignment.
 The same form of this option should be used for all files that
 share a 'COMMON' block.  To avoid potential alignment issues in
 'COMMON' blocks, it is recommended to order objects from largest to
 smallest.

Trying to match a named common block with memory alignment requirements
with a C struct (which may have different alignment requirements) seems
to the path to very hard to find bugs.

> > A quick scan of the DWARF5 standard does not show
> > a DW_TAG that applies to a variable declared in 
> > a module.
> 
> Referring to the github repo quickly
> https://github.com/amelvill-umich/Fortran_GDB_Common#with-that-line-commented-out
> , with the common statement commented out,
> 
> $ nm somemodule.o
>  B __somemodule_MOD_modulevar
> 

Interesting.  My guess would be that a common block
is simply considered to be a chunk of memory under
DWARF5.  It provides a base address and one needs to
know how to compute offsets into that chunk (including
dealing with any padding).

[Bug ipa/96130] [10/11 Regression] ICE in analyze_function_body at gcc/ipa-fnsummary.c:2769 since r10-3199-g351e7c3b5fbd45bd

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:776e48e0931db69f158f40e5cb8e15463d879a42

commit r11-2066-g776e48e0931db69f158f40e5cb8e15463d879a42
Author: Jakub Jelinek 
Date:   Mon Jul 13 18:25:53 2020 +0200

ipa-fnsummary: Fix ICE with switch predicates [PR96130]

The following testcase ICEs since r10-3199.
There is a switch with default label, where the controlling expression has
range just 0..7 and there are case labels for all those 8 values, but
nothing has yet optimized away the default.
Since r10-3199, set_switch_stmt_execution_predicate sets the switch to
default label's edge's predicate to a false predicate and then
compute_bb_predicates propagates the predicates through the cfg, but false
predicates aren't really added.  The caller of compute_bb_predicates
in one place handles NULL bb->aux as false predicate:
  if (fbi.info)
{
  if (bb->aux)
bb_predicate = *(predicate *) bb->aux;
  else
bb_predicate = false;
}
  else
bb_predicate = true;
but then in two further spots that the patch below is changing
it assumes bb->aux must be non-NULL.  Those two spots are guarded by a
condition that is only true if fbi.info is non-NULL, so I think the right
fix is to treat NULL aux as false predicate in those spots too.

2020-07-13  Jakub Jelinek  

PR ipa/96130
* ipa-fnsummary.c (analyze_function_body): Treat NULL bb->aux
as false predicate.

* gcc.dg/torture/pr96130.c: New test.

[Bug target/92488] GCC generates calls to __dpd_trunctdsd2 with -mhard-dfp

[bergner at gcc dot gnu.org]

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

Peter Bergner  changed:

   What|Removed |Added

 Status|NEW |WAITING

--- Comment #1 from Peter Bergner  ---
So if I look at what we generate for:

_Decimal64
truncd128 (_Decimal128 d)
{
  return d;
}

and:

_Decimal32
truncd64(_Decimal64 d)
{
  return d;
}

We basically just get a drdpq for the first function and a drsp for the second
function.  Ie, they don't change the rounding mode at all.  If I modify your
test case slightly to insert an intermediate cast to _Decimal64 like so:

_Decimal32
truncd128 (_Decimal128 d)
{
  return (_Decimal64)d;
}

...then we get:

drdpq 12,2
fmr 1,12
drsp 1,1
blr

So is changing the rounding mode really required here when we go from
_Decimal128 directly to _Decimal32?  If so, do the other casts also need to be
inserting rounding mode changes too?  If not, why not?

[Bug c++/96188] New: -Wstringop-overflow false positive

[derek.mauro at gmail dot com]

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

Bug ID: 96188
   Summary: -Wstringop-overflow false positive
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: derek.mauro at gmail dot com
  Target Milestone: ---

This is strange issue that started appearing in gcc 10.1. It also seems to
require -O3 and -std=gnu++11 (gnu++14 etc appear unaffected).

Godbolt demo: https://godbolt.org/z/W8MWbz

Test case copy/pasted below.

Use -Werror -Wstringop-overflow -std=gnu++11 -O3

#include 
#include 

bool b;

void F() {
  static bool b2 = b;
  for (const int fx : {0}) {
struct Expectation {
  std::string out;
};

std::vector expect = {
{std::string()},
{std::string()},
{std::string()},
};
if (b2) {
  expect.push_back({std::string()});
}

  }
}

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

[jerryfromearth at gmail dot com]

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

--- Comment #10 from Jiarui Hong  ---
Please note that there seems to be two issues here that affect different
versions of gcc:

(From the comment of g...@pkh.me)
https://godbolt.org/z/xc59TM
This fails in 9.3.0 but works in 10.1.0.

(From the comment of Martin Sebor)
https://godbolt.org/z/9Kh1Tn
This fails in both 9.3.0 and 10.1.0.

Maybe the difference is caused by some other feature/bugfix that is present in
10.1.0 but not in 9.3.0.
Anyway, I just want to highlight this and hope it can help with getting a
proper fix for this bug.
Thanks.

[Bug target/94393] Powerpc suboptimal 64-bit constant comparison

[bergner at gcc dot gnu.org]

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

--- Comment #5 from Peter Bergner  ---
(In reply to Alan Modra from comment #3)
> There are two parts to fixing this PR.
> 1) We can do better in the sequences generated for some constants.
> 2) rs6000_rtx_costs needs to be accurate, so that expensive constants are
> put in memory and stay there with optimisation.
> 
> Having looked at part 2 a little, I'd say fixes for that are definitely not
> stage 4 material.

Alan, I think you pushed some changes to help with 1) above, correct?
Is there more to do for 1)?

As for 2), we're in stage1 now.  Do you have ideas about what must be done
there?  Do we still want to do something for 2)?

[Bug fortran/96158] Debug symbols not emitted for module common variables

[amelvill at umich dot edu]

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

--- Comment #8 from AJM  ---
> > >> I won't comment on the questionable programming idiom of placing
> > >> a common block in a module, which kind of defeats the niceties of
> > >> a module.
> > > If somebody wants to transition your code from using common blocks to
> > > modules, that is a good way to proceed.   When all the direct usage
> > > of the common block have been removed, you can then remove the
> > > COMMON statement from the module.
> > 
> > This is the case, more or less. I didn't write the code that did this.
> > 
> > I would be quite happy to see the common blocks get moved to a module,
> > but to make things a bit more dangerous on that side, these variables
> > are bound to a C variable.
> Do you mean the variable is declared with BIND(C)?
> If so, you should be getting an error.

The bind statement would look like this, directly under the "common" statement,
inside somemodule.f90:

module somemodule

integer*8moduleVar !then many more variables

common /othermodule/  moduleVar !then many more variables
bind(C, name="othermodule") :: /othermodule/

end module

The program, with the bind statement added, compiles without errors. 

If you really need to know, on the C side there is a struct with fields that
match the order and size of the variables in the common statement / module
declaration. I am almost certain that this is not the "right way" to do this,
and that there is some UB there in struct packing and compiler decisions on the
size of the variables (neither the C side nor the fortran side has packing
pragmas, and worse, the C side uses compiler defined integer types like "int").
Without a doubt this is not an ideal setup, a rewrite is probably in order to
ensure portability. We don't have the time resources for that rewrite right
now, though (and that's not my call, either).

While I was making a minimal example I originally thought bind was the root
cause, but I eliminated it as the source of the problem (I found that I could
reproduce the issue with only common). I removed it to try and make the most
minimal example possible. 

This C side explanation is, in my opinion, not relevant at all to the bug at
hand and is our team's responsibility, not gfortran's. It's just to give you
context as to what I'm working with here and why "just make a module" is not
really an option, I would consider the C interfacing very precarious and I
personally only have the expertise to make it portable from the C side, not the
Fortran side (though I'm trying to get up to speed on the latter). 

Though, if anyone has any suggestions for documentation I can read about how to
avoid problems between g++ and gfortan that might come about from moving this
to a module I would appreciate it. I'm hoping that eventually I can come up
with a path towards making this a module that would exactly replicate the
original's intended behavior in a standards compliant way without breaking
anything. That path is not clear, at the moment.

> A quick scan of the DWARF5 standard does not show
> a DW_TAG that applies to a variable declared in 
> a module.

Referring to the github repo quickly
https://github.com/amelvill-umich/Fortran_GDB_Common#with-that-line-commented-out
, with the common statement commented out,

$ nm somemodule.o
 B __somemodule_MOD_modulevar

$ gdb main
GNU gdb (Ubuntu 9.1-0ubuntu1) 9.1
Copyright (C) 2020 Free Software Foundation, Inc.
(...)
Reading symbols from main...
(gdb) b 9
Breakpoint 1 at 0x1238: file main.f90, line 9.
(gdb) r
Starting program: /home/me/a_dev/fortran_gdb_common/main 
moduleVar=123

Breakpoint 1, myprogram () at main.f90:9
9   end program
(gdb) call moduleVar
$1 = 123

It seems like gfortran emits symbols of the form ___MOD_
if the common statement is omitted, could the compiler emit something like this
for common statements? Like ___MOD_?

In my test program's case, could it emit __othermodule_MOD_moduleVar? Would
there be issues with name collisions if there actually was a module named
othermodule (in addition to common)?

To be fair, I have not read the DWARF spec in depth, and "this is undefined
behavior" is a fair answer.

[Bug fortran/45337] gfortran accepts pointer initialization of DT dummy arguments w/ INTENT(OUT)

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r11-2065-gbae66e0f04323ba9d5daf60fcb997de925100e3e
Author: Mark Eggleston 
Date:   Wed Jun 10 07:22:50 2020 +0100

Fortran  : accepts pointer initialization of DT dummy args PR45337

Initialisation of a variable results in an implicit save attribute
being added to the variable.  The save attribute is not allowed for
variables with the dummy attribute set.  Initialisation should be
rejected for dummy variables.

2020-07-13  Mark Eggleston  

gcc/fortran/

PR fortran/45337
* resolve.c (resolve_fl_variable): Remove type and intent
checks from the check for dummy.

2020-07-13  Mark Eggleston  

gcc/testsuite/

PR fortran/45337
* gfortran.dg/pr45337_1.f90: New test.
* gfortran.dg/pr45337_2.f90: New test.

[Bug c++/96063] [10 Regression] mismatched-tags warnings in stdlib headers

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

  Known to fail|11.0|
 Resolution|--- |FIXED
Summary|[10/11 Regression]  |[10 Regression]
   |mismatched-tags warnings in |mismatched-tags warnings in
   |stdlib headers  |stdlib headers
 Status|ASSIGNED|RESOLVED

--- Comment #19 from Martin Sebor  ---
I backported the front end fix in r10-8471.

[Bug c++/96063] [10/11 Regression] mismatched-tags warnings in stdlib headers

[cvs-commit at gcc dot gnu.org]

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

--- Comment #18 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Martin Sebor
:

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

commit r10-8471-g5e4c9ebbab7bec3b5994f85aebce13bf37cf46e9
Author: Martin Sebor 
Date:   Mon Jul 13 09:32:40 2020 -0600

Avoid printing informational notes when -Wmismatched-tags is suppressed in
system headers (PR c++/96063)

Related:
PR c++/96063 - mismatched-tags warnings in stdlib headers

gcc/cp/ChangeLog:

PR c++/96063
* parser.c (class_decl_loc_t::diag_mismatched_tags): Print notes
only
if warning_at returns nonzero.

gcc/testsuite/ChangeLog:

PR c++/96063
* g++.dg/warn/Wmismatched-tags-7.C: New test.
* g++.dg/warn/Wmismatched-tags-8.C: New test.

[Bug c++/96077] GCC accepts ill-legal local enum definition

[mpolacek at gcc dot gnu.org]

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

--- Comment #9 from Marek Polacek  ---
Fixed for GCC 10.2 and 11.

[Bug c++/96077] GCC accepts ill-legal local enum definition

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:30529e2faa482bc749c65a490763dbc2ccaf63ac

commit r10-8470-g30529e2faa482bc749c65a490763dbc2ccaf63ac
Author: Marek Polacek 
Date:   Thu Jul 9 20:44:05 2020 -0400

c++: Fix tentative parsing of enum-specifier [PR96077]

Here's an interesting issue: in this code a ) is missing:

  enum { E = (2 } e;

but we compile the code anyway, and E is set to 0 in build_enumerator,
which is sneaky.

The problem is that cp_parser_enum_specifier parses tentatively, because
when we see the enum keyword, we don't know yet if we'll find an
enum-specifier, opaque-enum-declaration, or elaborated-enum-specifier.

In this test when we call cp_parser_enumerator_list we're still parsing
tentatively, and as a consequence, parens.require_close (parser) in
cp_parser_primary_expression doesn't report any errors.  But we only go
on to parse the enumerator-list after we've seen a {, at which point we
might as well commit -- we know we're dealing with an enum-specifier.

gcc/cp/ChangeLog:

PR c++/96077
* parser.c (cp_parser_enum_specifier): Commit to tentative parse
after we've seen an opening brace.

gcc/testsuite/ChangeLog:

PR c++/96077
* g++.dg/parse/enum14.C: New test.

(cherry picked from commit 4fd124a23664c712f1bb1a7e91fa23fe83d72c0b)

[Bug c++/96077] GCC accepts ill-legal local enum definition

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #10 from Marek Polacek  ---
.

[Bug c++/96077] GCC accepts ill-legal local enum definition

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r11-2064-g4fd124a23664c712f1bb1a7e91fa23fe83d72c0b
Author: Marek Polacek 
Date:   Thu Jul 9 20:44:05 2020 -0400

c++: Fix tentative parsing of enum-specifier [PR96077]

Here's an interesting issue: in this code a ) is missing:

  enum { E = (2 } e;

but we compile the code anyway, and E is set to 0 in build_enumerator,
which is sneaky.

The problem is that cp_parser_enum_specifier parses tentatively, because
when we see the enum keyword, we don't know yet if we'll find an
enum-specifier, opaque-enum-declaration, or elaborated-enum-specifier.

In this test when we call cp_parser_enumerator_list we're still parsing
tentatively, and as a consequence, parens.require_close (parser) in
cp_parser_primary_expression doesn't report any errors.  But we only go
on to parse the enumerator-list after we've seen a {, at which point we
might as well commit -- we know we're dealing with an enum-specifier.

gcc/cp/ChangeLog:

PR c++/96077
* parser.c (cp_parser_enum_specifier): Commit to tentative parse
after we've seen an opening brace.

gcc/testsuite/ChangeLog:

PR c++/96077
* g++.dg/parse/enum14.C: New test.

[Bug tree-optimization/96187] New: GCC at -O2 generates branch for code that should be branch-free

[philip.zander at googlemail dot com]

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

Bug ID: 96187
   Summary: GCC at -O2 generates branch for code that should be
branch-free
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: philip.zander at googlemail dot com
  Target Milestone: ---

Created attachment 48870
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48870&action=edit
Test case

The attached code contains two related functions, get_length2() and
get_length4(). For get_length4(), GCC generates branch-free instructions as
expected, but for get_length2() it introduces a branch, which is unfortunate
because the code was specifically written to avoid branches. The target is
x86_64.

You can compare the output here: https://godbolt.org/z/bhEzhY

This happens only at -O2, not at -O1 or -O3. It seems to have started with GCC
7, as GCC 6.* is the last version on Compiler Explorer that generates
branch-free code for both functions.

PS: I hope "tree-optimization" is the right component, I'm not a compiler
expert. If the problem lies elsewhere, please edit my report.

[Bug debug/78288] Compile time hog (with var-tracking) for libsanitizer/asan/asan_interceptors.cc

[rguenth at gcc dot gnu.org]

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

--- Comment #8 from Richard Biener  ---
files with growth:

obj/gcc/calls.c.325t.statistics:320 4958  | 5571
obj/gcc/prefix.c.325t.statistics:320 115  | 118

yes, that's all of them.

[Bug fortran/96158] Debug symbols not emitted for module common variables

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #7 from Steve Kargl  ---
On Mon, Jul 13, 2020 at 01:42:29PM +, amelvill at umich dot edu wrote:
> 
> As far as workarounds go, if it came to that I'd rather just make a dummy
> "debug" function that stored these common variables as a local variable.
> 

That would be the path of least trouble, is what my
subroutine boo is.

A quick scan of the DWARF5 standard does not show
a DW_TAG that applies to a variable declared in 
a module.

[Bug tree-optimization/96163] another ice in pass slp

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/96163] another ice in pass slp

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r11-2062-gc4facd483de2d5b6b4d20e6ad74c85b9f1eba41a
Author: Richard Biener 
Date:   Mon Jul 13 12:41:35 2020 +0200

tree-optimization/96163 - fix placement issue with SLP and vectors

This avoids placing stmts beyond the vectorizer region begin which
confuses vect_stmt_dominates_stmt_p.

2020-07-13  Richard Biener  

PR tree-optimization/96163
* tree-vect-slp.c (vect_schedule_slp_instance): Put new stmts
at least after region begin.

* g++.dg/vect/pr96163.cc: New testcase.

[Bug debug/78288] Compile time hog (with var-tracking) for libsanitizer/asan/asan_interceptors.cc

[rguenth at gcc dot gnu.org]

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

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

OK, I have another patch that reduces the overall number of visited blocks
in stage3 gcc/*.o by about 10%.  There are a few outliers that I need to
understand (because it should never(?) cause more blocks to be iterated).
Famous last words...

[Bug target/96186] New: [11 regressoion] ICE: Unrecognizable insn since r11-1970-fab263ab0fc10ea08409b80afa7e8569438b8d28

[wwwhhhyyy333 at gmail dot com]

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

Bug ID: 96186
   Summary: [11 regressoion] ICE: Unrecognizable insn since
r11-1970-fab263ab0fc10ea08409b80afa7e8569438b8d28
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wwwhhhyyy333 at gmail dot com
  Target Milestone: ---

A testcase extracted from 510.parest_r

#include 

double square(double d[3], double rad)
{
  double res[3];

  for (int i = 0; i < 3; i++)
{
  res[i] = d[i] * d[i];
  res[i] *= rad/sqrt(res[i]);
}

  return res[0];
}

Compile with -march=skylake-avx512 -funroll-loops -Ofast

sqrt.c: In function ‘square’:
sqrt.c:14:1: error: unrecognizable insn:
   14 | }
  | ^
(insn 12 11 13 2 (set (reg:V2DF 93)
(unspec:V2DF [
(reg:V2DF 84 [ vect_powmult_5.8 ])
] UNSPEC_RSQRT)) "sqrt.c":10:21 -1
 (nil))
during RTL pass: vregs
sqrt.c:14:1: internal compiler error: in extract_insn, at recog.c:2294
0x6e11f9 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/export/users2/hongyuw1/gcc/gcc/./gcc/rtl-error.c:108
0x6e1215 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/export/users2/hongyuw1/gcc/gcc/./gcc/rtl-error.c:116
0x6df72f extract_insn(rtx_insn*)
/export/users2/hongyuw1/gcc/gcc/./gcc/recog.c:2294
0xafd213 instantiate_virtual_regs_in_insn
/export/users2/hongyuw1/gcc/gcc/./gcc/function.c:1607
0xafd213 instantiate_virtual_regs
/export/users2/hongyuw1/gcc/gcc/./gcc/function.c:1977
0xafd213 execute
/export/users2/hongyuw1/gcc/gcc/./gcc/function.c:2026
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug fortran/96158] Debug symbols not emitted for module common variables

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #6 from Steve Kargl  ---
On Mon, Jul 13, 2020 at 12:23:58PM +, amelvill at umich dot edu wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96158
> 
> --- Comment #4 from AJM  ---
> >> I won't comment on the questionable programming idiom of placing
> >> a common block in a module, which kind of defeats the niceties of
> >> a module.
> > If somebody wants to transition your code from using common blocks to
> > modules, that is a good way to proceed.   When all the direct usage
> > of the common block have been removed, you can then remove the
> > COMMON statement from the module.
> 
> This is the case, more or less. I didn't write the code that did this.
> 
> I would be quite happy to see the common blocks get moved to a module,
> but to make things a bit more dangerous on that side, these variables
> are bound to a C variable.

Do you mean the variable is declared with BIND(C)?
If so, you should be getting an error.

[Bug fortran/95981] ICE in gfc_find_array_ref(): No ref found

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:3f069011019c9df670969ea283fd4d139f34a925

commit r11-2061-g3f069011019c9df670969ea283fd4d139f34a925
Author: Mark Eggleston 
Date:   Tue Jun 30 10:15:05 2020 +0100

Fortran  :  ICE in gfc_find_array_ref(): No ref found PR95981

When looking for an array reference allow NULL references.  If
no array reference is found dim_rank_check should return false.

2020-07-13  Steven G. Kargl  

gcc/fortran/

PR fortran/95981
* check.c (dim_rank_check): Allow NULL references in call to
gfc_find_array_ref and return false if no reference is found.

2020-07-13  Mark Eggleston  

gcc/testsuite/

PR fortran/95981
* gfortran.dg/pr95981.f90: New test.

[Bug fortran/96158] Symbols not emitted for module common variables

[amelvill at umich dot edu]

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

--- Comment #5 from AJM  ---
Also, in case it wasn't clear,

> Breakpoint 2, boo () at a.f90:9
> 9  write(*, '(A, I3)') "moduleVar=", n
> (gdb) p n
> $2 = 123
> (gdb) p moduleVar
> No symbol "moduleVar" in current context.
> (gdb) p (integer*8)othermodule_
> $3 = 123

I did find this as a workaround (it's in the repo README.md 
https://github.com/amelvill-umich/Fortran_GDB_Common , if you haven't seen it),
but this is not ideal, because there are hundreds of common statement variables
in the module in question, of varying size and type. They're all reduced to a
single othermodule_ variable.

I hypothetically could find the address of each variable, offset, and cast,
you're right, I could also hypothetically make some kind of memory map type
that I could cast that variable to, but then that would be a giant amount of
duplicated code and an extra thing to keep in sync whenever something is added.

As far as workarounds go, if it came to that I'd rather just make a dummy
"debug" function that stored these common variables as a local variable.

[Bug c++/96170] Enhancement: allow requires-clause checking of statement expression substitution success or failure

[wjwray at gmail dot com]

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

--- Comment #2 from Will Wray  ---
A much better idea, submitted here as bug 96185
and simultaneously submitted to Clang and MSVC -
a portable builtin to count bindings in [dcl.struct.bind]

[Bug c++/96185] Enhancement: Please add a builtin to count bindings in [dcl.struct.bind]

[wjwray at gmail dot com]

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

--- Comment #1 from Will Wray  ---
Clang ticket https://bugs.llvm.org/show_bug.cgi?id=46704

MSVC ticket
https://developercommunity.visualstudio.com/idea/203/enhancement-please-add-a-builtin-to-count-bindings.html#

[Bug c++/96185] New: Enhancement: Please add a builtin to count bindings in [dcl.struct.bind]

[wjwray at gmail dot com]

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

Bug ID: 96185
   Summary: Enhancement: Please add a builtin to count bindings in
[dcl.struct.bind]
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wjwray at gmail dot com
  Target Milestone: ---

(Submitting simultaneous requests for each of GCC, Clang and MSVC.
 Coordination between vendors will be beneficial for portability.)

Please add a builtin to count the bindings in [dcl.struct.bind].

A structured-bindable object has one of three types T:
  Case 1: array type
  Case 2: tuple access protocol; tuple_size, tuple_element, get
  Case 3: else, class types with restricted member data location & access

P2141 "Aggregates are named tuples" proposes automatic tuple-like protocol
for Case 3 types, in particular a generalisation of std::tuple_size.

This request is for a builtin exposing the field count of a Case 3 type
(so can be used to implement P2141's generalized std::tuple_size).

Counting bindings is key; it immediately opens up binding-based reflection.

Specification points (to be discussed & agreed between implementors)

Naming suggestions: __builtin_tuple_size, __builtin_binding_count ?
What value type? What value for an unsupported, non-bindable type?
Should the builtin work for Case 1 array and/or Case 2 tuple-like T?

E.g. given a statement SB :auto&& [b1,... bN] = std::declval();
decomposing a T into N bindings:

- If SB is well formed then the builtin evaluates to integer constant N
- Else If T is an empty class type then evaluate to 0
- Else evaluate to -1 ?? size_t(-1) ?? false ??

The empty class type exception is a convenience (c.f. std::is_empty)
and future-proofing in case variadic bindings allow the empty pack case.

What about access - should the builtin be sensitive to scope?
(I think not.)(c.f. P0969 DR allowing binding to accessible members.)

Please discuss with other implementors and agree on a portable builtin.
Thanks for your consideration.

[Bug c++/96063] [10/11 Regression] mismatched-tags warnings in stdlib headers

[ian.s.mcinerney at ieee dot org]

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

--- Comment #17 from Ian McInerney  ---
I think that r11-1899 is the more important one to backport, since that will
also allow for warnings that are generated by headers inside "-isystem" include
directories to not have the notes printed without the warning.

[Bug c++/96179] [10/11 Regression] g++-10.1 silently doesn't push_back the return of a void function

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

[Bug target/94891] aarch64: there is no way to strip PAC from a return address in c code

[cvs-commit at gcc dot gnu.org]

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Szabolcs Nagy :

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

commit r11-2059-g6a391e06f953c3390b14020d8cacb6d55f81b2b9
Author: Szabolcs Nagy 
Date:   Thu May 28 10:28:30 2020 +0100

doc: Clarify __builtin_return_address [PR94891]

The expected semantics and valid usage of __builtin_return_address is
not clear since it exposes implementation internals that are normally
not meaningful to portable c code.

This documentation change tries to clarify the semantics in case the
return address is stored in a mangled form. This affects AArch64 when
pointer authentication is used for the return address signing (i.e.
-mbranch-protection=pac-ret).

2020-07-13  Szabolcs Nagy  

gcc/ChangeLog:

PR target/94891
* doc/extend.texi: Update the text for  __builtin_return_address.

[Bug target/94791] aarch64: -pg profiling is broken with pac-ret

[cvs-commit at gcc dot gnu.org]

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

--- Comment #1 from CVS Commits  ---
The master branch has been updated by Szabolcs Nagy :

https://gcc.gnu.org/g:463a54e5d4956143f81c1f23b91cbd2d93855741

commit r11-2056-g463a54e5d4956143f81c1f23b91cbd2d93855741
Author: Szabolcs Nagy 
Date:   Tue Jun 2 16:44:41 2020 +0100

aarch64: fix return address access with pac [PR94891][PR94791]

This is a big hammer fix for __builtin_return_address (PR target/94891)
returning signed addresses (sometimes, depending on wether lr happens
to be signed or not at the time of call which depends on optimizations),
and similarly -pg may pass signed return address to _mcount
(PR target/94791).

At the time of return address expansion we don't know if it's signed or
not so it is done unconditionally.

2020-07-13  Szabolcs Nagy  

gcc/ChangeLog:

PR target/94891
PR target/94791
* config/aarch64/aarch64-protos.h (aarch64_return_addr_rtx):
Declare.
* config/aarch64/aarch64.c (aarch64_return_addr_rtx): New.
(aarch64_return_addr): Use aarch64_return_addr_rtx.
* config/aarch64/aarch64.h (PROFILE_HOOK): Likewise.

[Bug target/94891] aarch64: there is no way to strip PAC from a return address in c code

[cvs-commit at gcc dot gnu.org]

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Szabolcs Nagy :

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

commit r11-2057-g2bc95be3bb8c8138e2e87c1c11c84bfede989d61
Author: Szabolcs Nagy 
Date:   Thu Jun 4 13:42:16 2020 +0100

aarch64: fix __builtin_eh_return with pac-ret [PR94891]

Currently __builtin_eh_return takes a signed return address, which can
cause ABI and API issues: 1) pointer representation problems if the
address is passed around before eh return, 2) the source code needs
pac-ret specific changes and needs to know if pac-ret is used in the
current frame, 3) signed address may not be representible as void *
(with ilp32 abi).

Using address signing to protect eh return is ineffective because the
instruction sequence in the unwinder that starts from the address
signing and ends with a ret can be used as a return to anywhere gadget.
Using indirect branch istead of ret with bti j landing pads at the
target can reduce the potential of such gadget, which also implies
that __builtin_eh_return should not take a signed address.

This is a big hammer fix to the ABI and API issues: it turns pac-ret
off for the caller completely (not just on the eh return path).  To
harden the caller against ROP attacks, it should use indirect branch
instead of ret, this is not attempted so the patch remains small and
backportable.

2020-07-13  Szabolcs Nagy  

gcc/ChangeLog:

PR target/94891
* config/aarch64/aarch64.c
(aarch64_return_address_signing_enabled):
Disable return address signing if __builtin_eh_return is used.

gcc/testsuite/ChangeLog:

PR target/94891
* gcc.target/aarch64/return_address_sign_1.c: Update test.
* gcc.target/aarch64/return_address_sign_b_1.c: Likewise.

[Bug target/94891] aarch64: there is no way to strip PAC from a return address in c code

[cvs-commit at gcc dot gnu.org]

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Szabolcs Nagy :

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

commit r11-2058-gb097c7a27fb0796b2653a1d003cbf6b7a69d8961
Author: Szabolcs Nagy 
Date:   Thu Jun 4 09:33:35 2020 +0100

libgcc: fix the handling of return address mangling [PR94891]

Mangling, currently only used on AArch64 for return address signing,
is an internal representation that should not be exposed via

  __builtin_return_address return value,
  __builtin_eh_return handler argument,
  _Unwind_DebugHook handler argument.

Note that a mangled address might not even fit into a void *, e.g.
with AArch64 ilp32 ABI the return address is stored as 64bit, so
the mangled return address cannot be accessed via _Unwind_GetPtr.

This patch changes the unwinder hooks as follows:

MD_POST_EXTRACT_ROOT_ADDR is removed: root address comes from
__builtin_return_address which is not mangled.

MD_POST_EXTRACT_FRAME_ADDR is renamed to MD_DEMANGLE_RETURN_ADDR,
it now operates on _Unwind_Word instead of void *, so the hook
should work when return address signing is enabled on AArch64 ilp32.
(But for that __builtin_aarch64_autia1716 should be fixed to operate
on 64bit input instead of a void *.)

MD_POST_FROB_EH_HANDLER_ADDR is removed: it is the responsibility of
__builtin_eh_return to do the mangling if necessary.

2020-07-13  Szabolcs Nagy  

libgcc/ChangeLog:

PR target/94891
* config/aarch64/aarch64-unwind.h (MD_POST_EXTRACT_ROOT_ADDR):
Remove.
(MD_POST_FROB_EH_HANDLER_ADDR): Remove.
(MD_POST_EXTRACT_FRAME_ADDR): Rename to ...
(MD_DEMANGLE_RETURN_ADDR): This.
(aarch64_post_extract_frame_addr): Rename to ...
(aarch64_demangle_return_addr): This.
(aarch64_post_frob_eh_handler_addr): Remove.
* unwind-dw2.c (uw_update_context): Demangle return address.
(uw_frob_return_addr): Remove.

[Bug target/94891] aarch64: there is no way to strip PAC from a return address in c code

[cvs-commit at gcc dot gnu.org]

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

--- Comment #1 from CVS Commits  ---
The master branch has been updated by Szabolcs Nagy :

https://gcc.gnu.org/g:463a54e5d4956143f81c1f23b91cbd2d93855741

commit r11-2056-g463a54e5d4956143f81c1f23b91cbd2d93855741
Author: Szabolcs Nagy 
Date:   Tue Jun 2 16:44:41 2020 +0100

aarch64: fix return address access with pac [PR94891][PR94791]

This is a big hammer fix for __builtin_return_address (PR target/94891)
returning signed addresses (sometimes, depending on wether lr happens
to be signed or not at the time of call which depends on optimizations),
and similarly -pg may pass signed return address to _mcount
(PR target/94791).

At the time of return address expansion we don't know if it's signed or
not so it is done unconditionally.

2020-07-13  Szabolcs Nagy  

gcc/ChangeLog:

PR target/94891
PR target/94791
* config/aarch64/aarch64-protos.h (aarch64_return_addr_rtx):
Declare.
* config/aarch64/aarch64.c (aarch64_return_addr_rtx): New.
(aarch64_return_addr): Use aarch64_return_addr_rtx.
* config/aarch64/aarch64.h (PROFILE_HOOK): Likewise.

[Bug middle-end/95114] [9/10/11 Regression] ICE in obj_type_ref_class for structural-equality types

[cvs-commit at gcc dot gnu.org]

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Richard Sandiford :

https://gcc.gnu.org/g:5834e96a08fd8b86a42428f38a95903d2f1de202

commit r11-2055-g5834e96a08fd8b86a42428f38a95903d2f1de202
Author: Richard Sandiford 
Date:   Mon Jul 13 13:47:39 2020 +0100

ipa-devirt: Fix crash in obj_type_ref_class [PR95114]

The testcase has failed since r9-5035, because obj_type_ref_class
tries to look up an ODR type when no ODR type information is
available.  (The information was available earlier in the
compilation, but was freed during pass_ipa_free_lang_data.)
We then crash dereferencing the null get_odr_type result.

The test passes with -O2.  However, it fails again if -fdump-tree-all
is used, since obj_type_ref_class is called indirectly from the
dump routines.

Other code creates ODR type entries on the fly by passing âtrueâ
as the insert parameter.  But obj_type_ref_class can't do that
unconditionally, since it should have no side-effects when used
from the dumping code.

Following a suggestion from Honza, this patch adds parameters
to say whether the routines are being called from dump routines
and uses those to derive the insert parameter.

gcc/
PR middle-end/95114
* tree.h (virtual_method_call_p): Add a default-false parameter
that indicates whether the function is being called from dump
routines.
(obj_type_ref_class): Likewise.
* tree.c (virtual_method_call_p): Likewise.
* ipa-devirt.c (obj_type_ref_class): Likewise.  Lazily add ODR
type information for the type when the parameter is false.
* tree-pretty-print.c (dump_generic_node): Update calls to
virtual_method_call_p and obj_type_ref_class accordingly.

gcc/testsuite/
PR middle-end/95114
* g++.target/aarch64/pr95114.C: New test.

[Bug c++/96184] New: GCC treats "use of local variable with automatic storage from containing function" differently in versions

[haoxintu at gmail dot com]

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

Bug ID: 96184
   Summary: GCC treats "use of local variable with automatic
storage from containing function" differently in
versions
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: haoxintu at gmail dot com
  Target Milestone: ---

Hi, all.

This code, GCC-trunk and other versions (etc., GCC-10) treat it differently.

$cat test.cc
int main(){
int a  = 10;
int const b = 10;
auto p = [ ] () noexcept ( b ? 0 : a = b) { return 0;};
return 0;
}

$g++-trunk -std=c++14 test.cc
//nothing

$g++-10 -std=c++14 test.cc
test.cc: In function ‘int main()’:
test.cc:4:40: error: use of local variable with automatic storage from
containing function
4 | auto p = [ ] () noexcept ( b ? 0 : a = b) { return 0;};
  |^
test.cc:2:9: note: ‘int a’ declared here
2 | int a  = 10;
  | ^

I am wondering is this a enhancement of GCC-trunk? 

I also test this in other GCC versions. Weirdly, only GCC-9 or GCC-10 rejects
it while other versions from 6.1 to 8.3 (also trunk) accepts it.

I don't know how GCC deals with this case and this also makes me confused.

Thanks,
Haoxin

[Bug c++/96182] GCC accepts constexpr function with no return-statement

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
So we could do something like:
--- gcc/cp/decl.c.jj2020-07-09 11:27:51.088908783 +0200
+++ gcc/cp/decl.c   2020-07-13 14:34:59.887259561 +0200
@@ -17164,7 +17164,9 @@ finish_function (bool inline_p)
   BLOCK_SUPERCONTEXT (DECL_INITIAL (fndecl)) = fndecl;

   /* Complain if there's just no return statement.  */
-  if (warn_return_type
+  if ((warn_return_type
+   || (cxx_dialect >= cxx14
+  && DECL_DECLARED_CONSTEXPR_P (fndecl)))
   && !VOID_TYPE_P (TREE_TYPE (fntype))
   && !dependent_type_p (TREE_TYPE (fntype))
   && !current_function_returns_value && !current_function_returns_null
@@ -17196,8 +17198,12 @@ finish_function (bool inline_p)
global_dc->option_state))
add_return_star_this_fixit (&richloc, fndecl);
}
-  if (warning_at (&richloc, OPT_Wreturn_type,
- "no return statement in function returning non-void"))
+  if (cxx_dialect >= cxx14 && DECL_DECLARED_CONSTEXPR_P (fndecl))
+   error_at (&richloc, "no return statement in % function "
+   "returning non-void");
+  else if (warning_at (&richloc, OPT_Wreturn_type,
+  "no return statement in function returning "
+  "non-void"))
TREE_NO_WARNING (fndecl) = 1;
 }

and look for what breaks.

[Bug c++/96182] GCC accepts constexpr function with no return-statement

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Keywords|accepts-invalid |diagnostic
   Last reconfirmed||2020-07-13
   Severity|normal  |enhancement

--- Comment #5 from Jonathan Wakely  ---
[decl.constexpr] p6 in the C++ standard says:

"if no argument values exist such that an invocation of the function or
constructor could be an evaluated subexpression of a core constant expression
[...] the program is ill-formed, no diagnostic required."

So the foo() function is ill-formed, but implementations are not required to
diagnose it unless the function is actually evaluated.

So this is not accepts-invalid, but I'll confirm it as a request for a
diagnostic enhancement.

[Bug c++/96183] New: GCC accepts "convert '' from 'void' to 'int'" at compile time

[haoxintu at gmail dot com]

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

Bug ID: 96183
   Summary: GCC accepts "convert '' from 'void'
to 'int'" at compile time
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Keywords: accepts-invalid
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: haoxintu at gmail dot com
  Target Milestone: ---

Hi,all.

This code, test.cc, is an invalid code but GCC accepts it.

$cat test.cc
void 
foo (
auto, 
int var = throw )
{}

$g++ test.cc
test.cc:3:5: warning: use of ‘auto’ in parameter declaration only available
with ‘-fconcepts-ts’
3 | auto,
  | ^~~~

When I add -fconcepts-ts, GCC accepts this without any diagnostic message.

While in clang

$clang++ -c test.cc
test.cc:3:5: error: 'auto' not allowed in function prototype
auto, 
^~~~
test.cc:4:9: error: cannot initialize a parameter of type 'int' with an rvalue
of type 'void'
int var = throw )
^ ~
test.cc:4:9: note: passing argument to parameter 'var' here
2 errors generated.

The first error is ok because GCC emits an warning. I know when call foo() will
trigger the runtime error. But should GCC emit the error message like the
second error in clang at compile time? Or is this a intentional way when GCC
dealing with "auto" in function prototype?

Every GCC versions from 6.1 to trunk behave the same.


Thanks,
Haoxin

[Bug fortran/96158] Symbols not emitted for module common variables

[amelvill at umich dot edu]

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

--- Comment #4 from AJM  ---
>> I won't comment on the questionable programming idiom of placing
>> a common block in a module, which kind of defeats the niceties of
>> a module.
> If somebody wants to transition your code from using common blocks to
> modules, that is a good way to proceed.   When all the direct usage
> of the common block have been removed, you can then remove the
> COMMON statement from the module.

This is the case, more or less. I didn't write the code that did this.

I would be quite happy to see the common blocks get moved to a module, but to
make things a bit more dangerous on that side, these variables are bound to a C
variable.

If I could find a way to move the common statements to a module that was
guaranteed to have no issues whatsoever (UB, data alignment, etc., including on
the C side), I would be happy to do it. 

However, I haven't found enough information on this to feel confident about it
(there's significant gaps in the documentation I've found), so it seems
irresponsible to risk introducing bugs for the sake of getting GDB working.

[Bug c++/96182] GCC accepts constexpr function with no return-statement

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Or another possible wording would be that a constexpr function which is not a
valid constant expression for all possible parameter values is invalid.
I believe such wording is there for templates and instead of parameter values
all template arguments.