Re: bug in bit structure compilation

[Jonathan Wakely via Gcc-bugs]

I know you've realised the problem here now, but ...

This mailing list is for automated mails from our bugzilla database.
To report a bug please use bugzilla. Sending email directly to the
list will often be ignored, and will never create a bugzilla report.

See https://gcc.gnu.org/bugs/ for details.

Thanks!

[Bug rtl-optimization/37451] Extra addition for doloop in some cases

[luoxhu at gcc dot gnu.org]

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

luoxhu at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #12 from luoxhu at gcc dot gnu.org ---
Close this.

[Bug rtl-optimization/37451] Extra addition for doloop in some cases

[luoxhu at gcc dot gnu.org]

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

--- Comment #11 from luoxhu at gcc dot gnu.org ---
fixed on master.

[Bug rtl-optimization/37451] Extra addition for doloop in some cases

[cvs-commit at gcc dot gnu.org]

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

--- Comment #10 from CVS Commits  ---
The master branch has been updated by Xiong Hu Luo :

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

commit r11-407-g8a15faa730f99100f6f3ed12663563356ec5a2c0
Author: Xionghu Luo 
Date:   Thu May 14 21:03:24 2020 -0500

Fold (add -1; zero_ext; add +1) operations to zero_ext when not
overflow(PR37451, PR61837)

This "subtract/extend/add" existed for a long time and still annoying us
(PR37451, part of PR61837) when converting from 32bits to 64bits, as the
ctr
register is used as 64bits on powerpc64, Andraw Pinski had a patch but
caused some issue and reverted by Joseph S. Myers(PR37451, PR37782).

Andraw:
http://gcc.gnu.org/ml/gcc-patches/2008-09/msg01070.html
http://gcc.gnu.org/ml/gcc-patches/2008-10/msg01321.html
Joseph:
https://gcc.gnu.org/legacy-ml/gcc-patches/2011-11/msg02405.html

We still can do the simplification from "subtract/zero_ext/add" to
"zero_ext"
when loop iterations is known to be LT than MODE_MAX (only do simplify
when counter+0x1 NOT overflow).

Bootstrap and regression tested pass on Power8-LE.

gcc/ChangeLog

2020-05-15  Xiong Hu Luo  

PR rtl-optimization/37451, part of PR target/61837
* loop-doloop.c (doloop_simplify_count): New function.  Simplify
(add -1; zero_ext; add +1) to zero_ext when not wrapping.
(doloop_modify): Call doloop_simplify_count.

gcc/testsuite/ChangeLog

2020-05-15  Xiong Hu Luo  

PR rtl-optimization/37451, part of PR target/61837
* gcc.target/powerpc/doloop-2.c: New test.

[Bug target/61837] missed loop invariant expression optimization

[cvs-commit at gcc dot gnu.org]

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

--- Comment #11 from CVS Commits  ---
The master branch has been updated by Xiong Hu Luo :

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

commit r11-407-g8a15faa730f99100f6f3ed12663563356ec5a2c0
Author: Xionghu Luo 
Date:   Thu May 14 21:03:24 2020 -0500

Fold (add -1; zero_ext; add +1) operations to zero_ext when not
overflow(PR37451, PR61837)

This "subtract/extend/add" existed for a long time and still annoying us
(PR37451, part of PR61837) when converting from 32bits to 64bits, as the
ctr
register is used as 64bits on powerpc64, Andraw Pinski had a patch but
caused some issue and reverted by Joseph S. Myers(PR37451, PR37782).

Andraw:
http://gcc.gnu.org/ml/gcc-patches/2008-09/msg01070.html
http://gcc.gnu.org/ml/gcc-patches/2008-10/msg01321.html
Joseph:
https://gcc.gnu.org/legacy-ml/gcc-patches/2011-11/msg02405.html

We still can do the simplification from "subtract/zero_ext/add" to
"zero_ext"
when loop iterations is known to be LT than MODE_MAX (only do simplify
when counter+0x1 NOT overflow).

Bootstrap and regression tested pass on Power8-LE.

gcc/ChangeLog

2020-05-15  Xiong Hu Luo  

PR rtl-optimization/37451, part of PR target/61837
* loop-doloop.c (doloop_simplify_count): New function.  Simplify
(add -1; zero_ext; add +1) to zero_ext when not wrapping.
(doloop_modify): Call doloop_simplify_count.

gcc/testsuite/ChangeLog

2020-05-15  Xiong Hu Luo  

PR rtl-optimization/37451, part of PR target/61837
* gcc.target/powerpc/doloop-2.c: New test.

[Bug tree-optimization/88842] missing optimization CSE, reassociation

[luoxhu at gcc dot gnu.org]

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

luoxhu at gcc dot gnu.org changed:

   What|Removed |Added

 CC||luoxhu at gcc dot gnu.org

--- Comment #3 from luoxhu at gcc dot gnu.org ---
One more case of missed optimization CSE, reassoc:

void foo(unsigned int a, unsigned int b, unsigned int c, unsigned int d, int
*res1, int*res2, int *res3)
{
  *res1 = a + b + c + d;
  *res2 = b + c;
  *res3 = a + d;
}

cat foo.s
.file   "foo.c"
.machine power8
.abiversion 2
.section".text"
.align 2
.p2align 4,,15
.globl foo
.type   foo, @function
foo:
.LFB0:
.cfi_startproc
add 10,5,6
add 10,10,4
add 4,4,5
add 10,10,3
add 3,3,6
stw 10,0(7)
stw 4,0(8)
stw 3,0(9)
blr

[Bug c++/86142] hard error for bad delete-expression in SFINAE context

[ensadc at mailnesia dot com]

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

--- Comment #2 from ensadc at mailnesia dot com ---
I was misled by Clang. Seems like there's a Clang bug then.

[Bug c/95145] New: [10/11 Regression]internal compiler error: in analyze_functions, at cgraphunit.c:1380

[anbu1024.me at gmail dot com]

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

Bug ID: 95145
   Summary: [10/11 Regression]internal compiler error: in
analyze_functions, at cgraphunit.c:1380
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: anbu1024.me at gmail dot com
  Target Milestone: ---

$ cat test.c 

void foo ( ) 
{ 
extern __inline int bar ( ) { }

int baz ( ) { return bar ; } 
}


$ gcc-11 --version
gcc (GCC) 11.0.0 20200510 (experimental)
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


$ gcc-11 test.c 
test.c: In function ‘foo’:
test.c:4:22: error: nested function ‘bar’ declared ‘extern’
4 |  extern __inline int bar ( ) { }
  |  ^~~
test.c: In function ‘baz’:
test.c:6:23: warning: returning ‘int (*)()’ from a function with return type
‘int’ makes integer from pointer without a cast
[]8;;https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wint-conversion-Wint-conversion]8;;]
6 |  int baz ( ) { return bar ; }
  |   ^~~
At top level:
cc1: internal compiler error: in analyze_functions, at cgraphunit.c:1380
0x63a1df analyze_functions
../../gcc-11-20200510/gcc/cgraphunit.c:1380
0x966712 symbol_table::finalize_compilation_unit()
../../gcc-11-20200510/gcc/cgraphunit.c:2971
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.


$ gcc-10 --version
gcc (GCC) 10.0.1 20200419 (experimental)
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


$ gcc-10 test.c 
test.c: In function ‘foo’:
test.c:4:22: error: nested function ‘bar’ declared ‘extern’
4 |  extern __inline int bar ( ) { }
  |  ^~~
test.c: In function ‘baz’:
test.c:6:23: warning: returning ‘int (*)()’ from a function with return type
‘int’ makes integer from pointer without a cast
[]8;;https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wint-conversion-Wint-conversion]8;;]
6 |  int baz ( ) { return bar ; }
  |   ^~~
At top level:
cc1: internal compiler error: in analyze_functions, at cgraphunit.c:1380
0x639ab1 analyze_functions
../../gcc-10-20200419/gcc/cgraphunit.c:1380
0x963fc2 symbol_table::finalize_compilation_unit()
../../gcc-10-20200419/gcc/cgraphunit.c:2974
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/95082] LE implementations of vec_cnttz_lsbb and vec_cntlz_lsbb are wrong

[pc at us dot ibm.com]

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

Paul Clarke  changed:

   What|Removed |Added

 CC||pc at us dot ibm.com

--- Comment #2 from Paul Clarke  ---
This is a dup of bug 95070.
(I am unable to mark it as such.)

[Bug target/95144] Many AVX-512 functions take an int instead of unsigned int

[e...@coeus-group.com]

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

--- Comment #1 from Evan Nemerson  ---
Godbolt link with corrected flags for MSVC: https://godbolt.org/z/M9sgxe

Sorry about that.

[Bug jit/94778] All jit tests failed with multilib

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

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

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

[Bug jit/94778] All jit tests failed with multilib

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r11-405-gd2a359fe5d72e28433c92e64dcbdaa93eb39caf4
Author: H.J. Lu 
Date:   Thu May 14 16:34:52 2020 -0700

Skip jit tests for targets that don't support -lgccjit

Since libgccjit.so is linked into jit tests, skip jit tests for targets
that don't support -lgccjit.

gcc/

PR jit/94778
* doc/sourcebuild.texi: Document effective target lgccjit.

gcc/testsuite/

PR jit/94778
* jit.dg/jit.exp: Skip jit tests for targets that don't support
-lgccjit.
* lib/target-supports.exp (check_effective_target_lgccjit): New.

Re: bug in bit structure compilation

[Andrew Pinski via Gcc-bugs]

On Thu, May 14, 2020 at 4:19 PM Geoff Mulligan  wrote:
>
> Version:
> gcc -v
> Using built-in specs.
> COLLECT_GCC=gcc
> COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/7/lto-wrapper
> OFFLOAD_TARGET_NAMES=nvptx-none
> OFFLOAD_TARGET_DEFAULT=1
> Target: x86_64-linux-gnu
> Configured with: ../src/configure -v --with-pkgversion='Ubuntu
> 7.5.0-3ubuntu1~18.04'
> --with-bugurl=file:///usr/share/doc/gcc-7/README.Bugs
> --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++
> --prefix=/usr --with-gcc-major-version-only --program-suffix=-7
> --program-prefix=x86_64-linux-gnu- --enable-shared
> --enable-linker-build-id --libexecdir=/usr/lib
> --without-included-gettext --enable-threads=posix --libdir=/usr/lib
> --enable-nls --enable-bootstrap --enable-clocale=gnu
> --enable-libstdcxx-debug --enable-libstdcxx-time=yes
> --with-default-libstdcxx-abi=new --enable-gnu-unique-object
> --disable-vtable-verify --enable-libmpx --enable-plugin
> --enable-default-pie --with-system-zlib --with-target-system-zlib
> --enable-objc-gc=auto --enable-multiarch --disable-werror
> --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32
> --enable-multilib --with-tune=generic
> --enable-offload-targets=nvptx-none --without-cuda-driver
> --enable-checking=release --build=x86_64-linux-gnu
> --host=x86_64-linux-gnu --target=x86_64-linux-gnu
> Thread model: posix
> gcc version 7.5.0 (Ubuntu 7.5.0-3ubuntu1~18.04)
>
> Here is a simple program:
>
> #include 
>
> int main() {
>struct {
>  int a : 3;
>} foo;
>
>switch (foo.a) {
>case 3: break;
>case 4: break;
>}
>
>if (foo.a == 3) { }
>if (foo.a == 4) { }
> }
>
> When compiling the compiler complains:
> gcc -o a a.c
> a.c: In function ‘main’:
> a.c:10:3: warning: case label value exceeds maximum value for type
> case 4: break;
> ^~~~
>
> It would seem that 4 is within the bounds of 0 to 7.

But the range of foo.a is -4 ... 3  and not 0 ... 7.

>
> Geoff
>

[Bug target/95144] New: Many AVX-512 functions take an int instead of unsigned int

[e...@coeus-group.com]

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

Bug ID: 95144
   Summary: Many AVX-512 functions take an int instead of unsigned
int
   Product: gcc
   Version: 10.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: e...@coeus-group.com
  Target Milestone: ---

There are a bunch of functions in AVX-512F which, according to Intel's
documentation (https://software.intel.com/sites/landingpage/IntrinsicsGuide/),
take an unsigned integer as an argument but GCC's header has the type as a
signed integer.

This causes problems with -Wsign-conversion.  Here is an example which will
generate a warning with -Wsign-conversion (or https://godbolt.org/z/kTBTAD if
you prefer):

  #include 

  static __m256i foo (__m256i a, unsigned int imm8) {
return _mm256_srai_epi64(a, imm8);
  }

  __m256i bar(__m256i a) {
return foo(a, 7);
  }


AFAICT all the functions which take unsigned imm8 arguments have this problem
in clang.  Here is a quick list:

 * _mm256_mask_slli_epi16
 * _mm256_mask_slli_epi32
 * _mm256_mask_slli_epi64
 * _mm256_mask_srai_epi16
 * _mm256_mask_srai_epi32
 * _mm256_mask_srai_epi64
 * _mm256_mask_srli_epi32
 * _mm256_mask_srli_epi64
 * _mm256_maskz_slli_epi16
 * _mm256_maskz_slli_epi32
 * _mm256_maskz_slli_epi64
 * _mm256_maskz_srai_epi16
 * _mm256_maskz_srai_epi32
 * _mm256_maskz_srai_epi64
 * _mm256_maskz_srli_epi32
 * _mm256_maskz_srli_epi64
 * _mm256_srai_epi64
 * _mm512_mask_slli_epi16
 * _mm512_mask_slli_epi32
 * _mm512_mask_slli_epi64
 * _mm512_mask_srai_epi16
 * _mm512_mask_srai_epi32
 * _mm512_mask_srai_epi64
 * _mm512_mask_srli_epi16
 * _mm512_mask_srli_epi32
 * _mm512_mask_srli_epi64
 * _mm512_maskz_slli_epi16
 * _mm512_maskz_slli_epi32
 * _mm512_maskz_slli_epi64
 * _mm512_maskz_srai_epi16
 * _mm512_maskz_srai_epi32
 * _mm512_maskz_srai_epi64
 * _mm512_maskz_srli_epi32
 * _mm512_maskz_srli_epi64
 * _mm512_slli_epi16
 * _mm512_slli_epi32
 * _mm512_slli_epi64
 * _mm512_srai_epi16
 * _mm512_srai_epi32
 * _mm512_srai_epi64
 * _mm512_srli_epi16
 * _mm512_srli_epi32
 * _mm512_srli_epi64
 * _mm_mask_slli_epi16
 * _mm_mask_slli_epi32
 * _mm_mask_slli_epi64
 * _mm_mask_srai_epi16
 * _mm_mask_srai_epi32
 * _mm_mask_srai_epi64
 * _mm_mask_srli_epi32
 * _mm_mask_srli_epi64
 * _mm_maskz_slli_epi16
 * _mm_maskz_slli_epi32
 * _mm_maskz_slli_epi64
 * _mm_maskz_srai_epi16
 * _mm_maskz_srai_epi32
 * _mm_maskz_srai_epi64
 * _mm_maskz_srli_epi32
 * _mm_maskz_srli_epi64

It looks like clang has the same problem, though ICC and MSVC do not.  Here is
an almost identical bug report I filed against LLVM:
https://bugs.llvm.org/show_bug.cgi?id=45931

Re: bug in bit structure compilation

[Geoff Mulligan]

Obviously I'm an idiot.  signed vs unsigned.  Ugh.  But maybe the 
compiler should complain about the if test...


Geoff


On 5/14/20 4:45 PM, Geoff Mulligan wrote:

Version:
gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/7/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 
7.5.0-3ubuntu1~18.04' 
--with-bugurl=file:///usr/share/doc/gcc-7/README.Bugs 
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ 
--prefix=/usr --with-gcc-major-version-only --program-suffix=-7 
--program-prefix=x86_64-linux-gnu- --enable-shared 
--enable-linker-build-id --libexecdir=/usr/lib 
--without-included-gettext --enable-threads=posix --libdir=/usr/lib 
--enable-nls --enable-bootstrap --enable-clocale=gnu 
--enable-libstdcxx-debug --enable-libstdcxx-time=yes 
--with-default-libstdcxx-abi=new --enable-gnu-unique-object 
--disable-vtable-verify --enable-libmpx --enable-plugin 
--enable-default-pie --with-system-zlib --with-target-system-zlib 
--enable-objc-gc=auto --enable-multiarch --disable-werror 
--with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 
--enable-multilib --with-tune=generic 
--enable-offload-targets=nvptx-none --without-cuda-driver 
--enable-checking=release --build=x86_64-linux-gnu 
--host=x86_64-linux-gnu --target=x86_64-linux-gnu

Thread model: posix
gcc version 7.5.0 (Ubuntu 7.5.0-3ubuntu1~18.04)

Here is a simple program:

#include 

int main() {
  struct {
    int a : 3;
  } foo;

  switch (foo.a) {
  case 3: break;
  case 4: break;
  }

  if (foo.a == 3) { }
  if (foo.a == 4) { }
}

When compiling the compiler complains:
gcc -o a a.c
a.c: In function ‘main’:
a.c:10:3: warning: case label value exceeds maximum value for type
   case 4: break;
   ^~~~

It would seem that 4 is within the bounds of 0 to 7.

Geoff

bug in bit structure compilation

[Geoff Mulligan]

Version:
gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/7/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 
7.5.0-3ubuntu1~18.04' 
--with-bugurl=file:///usr/share/doc/gcc-7/README.Bugs 
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ 
--prefix=/usr --with-gcc-major-version-only --program-suffix=-7 
--program-prefix=x86_64-linux-gnu- --enable-shared 
--enable-linker-build-id --libexecdir=/usr/lib 
--without-included-gettext --enable-threads=posix --libdir=/usr/lib 
--enable-nls --enable-bootstrap --enable-clocale=gnu 
--enable-libstdcxx-debug --enable-libstdcxx-time=yes 
--with-default-libstdcxx-abi=new --enable-gnu-unique-object 
--disable-vtable-verify --enable-libmpx --enable-plugin 
--enable-default-pie --with-system-zlib --with-target-system-zlib 
--enable-objc-gc=auto --enable-multiarch --disable-werror 
--with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 
--enable-multilib --with-tune=generic 
--enable-offload-targets=nvptx-none --without-cuda-driver 
--enable-checking=release --build=x86_64-linux-gnu 
--host=x86_64-linux-gnu --target=x86_64-linux-gnu

Thread model: posix
gcc version 7.5.0 (Ubuntu 7.5.0-3ubuntu1~18.04)

Here is a simple program:

#include 

int main() {
  struct {
    int a : 3;
  } foo;

  switch (foo.a) {
  case 3: break;
  case 4: break;
  }

  if (foo.a == 3) { }
  if (foo.a == 4) { }
}

When compiling the compiler complains:
gcc -o a a.c
a.c: In function ‘main’:
a.c:10:3: warning: case label value exceeds maximum value for type
   case 4: break;
   ^~~~

It would seem that 4 is within the bounds of 0 to 7.

Geoff

[Bug c++/95143] SFINAE failure with static_cast

[redi at gcc dot gnu.org]

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

--- Comment #11 from Jonathan Wakely  ---
Possibly fixed as part of PR 94885.

[Bug c++/95143] SFINAE failure with static_cast

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

  Known to fail||10.1.0
   Keywords||needs-bisection,
   ||rejects-valid
 Status|WAITING |NEW
  Known to work||10.1.1, 11.0, 9.2.0

--- Comment #10 from Jonathan Wakely  ---
Thanks. Confirmed as a bug in 10.1 but it already seems to be fixed on the
gcc-10 branch after the release. I'll bisect it.

[Bug c++/95143] SFINAE failure with static_cast

[familiebaumanns at gmail dot com]

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

--- Comment #9 from Bernd Baumanns  ---
fails with this version:
g++-10.1 (GCC) 10.1.0
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[Bug c++/95143] SFINAE failure with static_cast

[familiebaumanns at gmail dot com]

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

--- Comment #8 from Bernd Baumanns  ---
fails with this version:
g++ (Compiler-Explorer-Build) 10.1.0
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Compiler returned: 0


And this:
g++-10 (Ubuntu 10-20200417-0ubuntu1) 10.0.1 20200417 (experimental) [master
revision a64468a3034:28feadc0609:b835645c7a51b7e99092abe61d677aa491836f95]
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[Bug fortran/95138] ICE on transfer to unlimited polymorphic

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

   Last reconfirmed||2020-5-14
 CC||anlauf at gcc dot gnu.org
   Keywords||ice-on-valid-code,
   ||wrong-code
   Priority|P3  |P4

--- Comment #1 from anlauf at gcc dot gnu.org ---
A small subset of the reproducer shows that invalid code is generated:

program transfer_p
  implicit none
  integer, parameter :: n = 3
  class(*), allocatable :: o(:)
  integer   :: v(n)
  integer   :: i

  v = [(i, i=1,n)]
  allocate(o, source=v)
  print *, "size (o) =", size (o)
  print *, transfer(o, v)
end

This compiles and gives:

 size (o) =   3
   1   2   3   0   0   0

while compiling with -fdefault-integer-8 gives the correct answer:

 size (o) =3
123

A look at the dump appears to give some hint where to look further.

[Bug c++/95143] SFINAE failure with static_cast

[familiebaumanns at gmail dot com]

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

--- Comment #7 from Bernd Baumanns  ---
I hope you have now all you need.

This bug is only triggered in C++20 mode and with inheritance.

[Bug c++/95143] SFINAE failure with static_cast

[familiebaumanns at gmail dot com]

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

--- Comment #6 from Bernd Baumanns  ---
simplified source (without include type_traits):

class false_type
{
public:
static constexpr bool value = false;
};

class true_type{
public:
static constexpr bool value = true;
};

template
T&& declval() noexcept;

template
struct is_static_castable : false_type
{};
template
struct is_static_castable(declval()))> :
true_type
{};

class Base
{};

struct A
{};

class B: public Base
{};

int main()
{
constexpr auto canCast = is_static_castable::value;
static_assert(!canCast);
constexpr auto canCast2 = is_static_castable::value;
static_assert(canCast2);
return 0;
}

[Bug c++/95143] SFINAE failure with static_cast

[familiebaumanns at gmail dot com]

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

--- Comment #5 from Bernd Baumanns  ---
Created attachment 48544
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48544=edit
source

[Bug c++/95143] SFINAE failure with static_cast

[familiebaumanns at gmail dot com]

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

--- Comment #4 from Bernd Baumanns  ---
Created attachment 48543
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48543=edit
g++-10 -v -save-temps -std=c++2a /mnt/j/test.cpp

[Bug c/95142] ICE when compiling certain logic with -Ofast and -mpretend-cmove when dealing with floats

[hayden at hkowsoftware dot com]

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

--- Comment #2 from Hayden Kowalchuk  ---
slightly further testing shows all affected versions only need these flags to
trigger

sh4-linux-gnu-gcc-* -O1 -ffast-math -mpretend-cmove -c ice_sh4.c

[Bug c++/93901] [10 Regression] noexcept specifier on ctor does not work with constexpr variable or expression since r10-4394

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r11-403-g4e1592f8e1d6366699e05c0824fc3dc39ca7314b
Author: Jason Merrill 
Date:   Thu May 14 11:15:27 2020 -0400

c++: Fix deferred noexcept on constructor [PR93901].

My change in r10-4394 to only update clones when we actually instantiate a
deferred noexcept-spec broke this because deferred parsing updates the
primary function but not the clones.  For GCC 10 I just reverted that
change; this patch adjusts maybe_instantiate_noexcept to update only the
clone passed as the argument.

gcc/cp/ChangeLog
2020-05-14  Jason Merrill  

PR c++/93901
* pt.c (maybe_instantiate_noexcept): Change clone handling.

[Bug c++/95143] SFINAE failure with static_cast

[familiebaumanns at gmail dot com]

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

--- Comment #3 from Bernd Baumanns  ---
Created attachment 48541
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48541=edit
ii file

[Bug target/95139] Messages using string concatenation can not be translated

[joseph at codesourcery dot com]

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

--- Comment #1 from joseph at codesourcery dot com  ---
Code using the GCC diagnostic functions should use %wd instead of 
HOST_WIDE_INT_PRINT, both for translation and because HOST_WIDE_INT_PRINT 
is a format for the host printf and may not be understood by the GCC 
pretty-printer code at all; the pretty-printer code is responsible for 
translating %wd to %lld / %I64d as needed.

[Bug go/95061] shared libgo library not found when running the testsuite

[cvs-commit at gcc dot gnu.org]

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

--- Comment #6 from CVS Commits  ---
The master branch has been updated by Ian Lance Taylor :

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

commit r11-402-g3a36428b5fbc825e2d3455f5770b5d6e71c63413
Author: Ian Lance Taylor 
Date:   Thu May 14 12:50:30 2020 -0700

libgo: only build syscall test with -static on GNU/Linux

For PR go/95061

Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/234019

[Bug c/95142] ICE when compiling certain logic with -Ofast and -mpretend-cmove when dealing with floats

[gabravier at gmail dot com]

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

Gabriel Ravier  changed:

   What|Removed |Added

 CC||gabravier at gmail dot com

--- Comment #1 from Gabriel Ravier  ---
I can reproduce this on Fedora 32 with `sh-linux-gnu-gcc` (which uses GCC 9.2)
: 

$ sh-linux-gnu-gcc -Ofast -m4 -mpretend-cmove -c ice_sh4.c 
ice_sh4.c: In function ‘call_create’:
ice_sh4.c:48:1: error: unrecognizable insn:
   48 | }
  | ^
(insn 26 25 27 2 (parallel [
(set (reg:SI 147 t)
(ge:SI (reg/v:SF 170 [ size_1 ])
(reg/v:SF 167 [ size_0 ])))
(clobber (reg:SI 155 fpscr1))
(use (reg:SI 154 fpscr0))
]) "ice_sh4.c":41:29 -1
 (nil))
during RTL pass: vregs
ice_sh4.c:48:1: internal compiler error: in extract_insn, at recog.c:2310
0x7f37befd0041 __libc_start_main
../csu/libc-start.c:308
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
The bug is not reproducible, so it is likely a hardware or OS problem.
$ sh-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/usr/bin/sh-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/sh-linux-gnu/9/lto-wrapper
Target: sh-linux-gnu
Configured with: ../gcc-9.2.1-20190827/configure --bindir=/usr/bin
--build=x86_64-redhat-linux-gnu --datadir=/usr/share --disable-decimal-float
--disable-dependency-tracking --disable-gold --disable-libgcj --disable-libgomp
--disable-libmpx --disable-libquadmath --disable-libssp
--disable-libunwind-exceptions --disable-shared --disable-silent-rules
--disable-sjlj-exceptions --disable-threads --with-ld=/usr/bin/sh-linux-gnu-ld
--enable-__cxa_atexit --enable-checking=release --enable-gnu-unique-object
--enable-initfini-array --enable-languages=c,c++ --enable-linker-build-id
--enable-lto --enable-nls --enable-obsolete --enable-plugin
--enable-targets=all --exec-prefix=/usr --host=x86_64-redhat-linux-gnu
--includedir=/usr/include --infodir=/usr/share/info --libexecdir=/usr/libexec
--localstatedir=/var --mandir=/usr/share/man --prefix=/usr
--program-prefix=sh-linux-gnu- --sbindir=/usr/sbin --sharedstatedir=/var/lib
--sysconfdir=/etc --target=sh-linux-gnu
--with-bugurl=http://bugzilla.redhat.com/bugzilla/
--with-gcc-major-version-only --with-isl --with-newlib
--with-plugin-ld=/usr/bin/sh-linux-gnu-ld
--with-sysroot=/usr/sh-linux-gnu/sys-root --with-system-libunwind
--with-system-zlib --without-headers
--with-multilib-list=m1,m2,m2e,m2a,m2a-single,m4,m4-single,m4-single-only,m4-nofpu
--with-linker-hash-style=gnu
Thread model: single
gcc version 9.2.1 20190827 (Red Hat Cross 9.2.1-3) (GCC) 


Reproducing it requires `-m4` here (doesn't work with nothing or another
architecture like `-m3`), so it is most likely a bug specific to SH4-specific
code.

[Bug middle-end/95140] [10/11 Regression] bogus -Wstringop-overflow for a loop unrolled past the end of a trailing array

[msebor at gcc dot gnu.org]

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

--- Comment #4 from Martin Sebor  ---
No.  GCC's manual recommends using either flexible array members or zero-length
arrays, and explicitly discourages abuses of arrays of length one (nothing is
said about any such exceptions for larger arrays):

  Although using one-element arrays this way is discouraged, GCC handles
accesses to trailing one-element array members analogously to zero-length
arrays.

Legacy code that misuses arrays of larger bounds either needs to be updated to
use the recommended solutions or it can suppress the warning using one of the
provided mechanisms.  Otherwise, undefined code will be increasingly diagnosed
(in line with the reporter's expectation).

[Bug tree-optimization/95133] [8/9/10/11 Regression] ICE in gimple_redirect_edge_and_branch_force, at tree-cfg.c:6075

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

Summary|[9/10/11 Regression] ICE in |[8/9/10/11 Regression] ICE
   |gimple_redirect_edge_and_br |in
   |anch_force, at  |gimple_redirect_edge_and_br
   |tree-cfg.c:6075 |anch_force, at
   ||tree-cfg.c:6075
 CC||rguenth at gcc dot gnu.org

--- Comment #3 from Martin Liška  ---
(In reply to James Greenhalgh from comment #2)
> Should reproduce further back if you force it on with -ftree-vectorize .
> 
> i.e.
> 
> gcc foo.c -ftree-vectorize -O3
> 
> Breaks somewhere between:
> 
> gcc version 7.0.0 20160615
> gcc version 7.0.0 20160907

You are right James, it started with r7-1820-g1174b21b388ba06e.

[Bug target/95134] Add a target option to avoid libcall

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Resolution|WONTFIX |---
 Status|RESOLVED|NEW
   Assignee|unassigned at gcc dot gnu.org  |hjl.tools at gmail dot 
com

--- Comment #5 from H.J. Lu  ---
Created attachment 48538
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48538=edit
A patch to add -mavoid-libcall

The -mgeneral-regs-only option generates code that uses only the
general-purpose registers.  It prevents the compiler from using vector
registers.  But GCC may still generate calls to memcpy, memmove, memset
and memcmp library functions.  In the GNU C library, these library
functions are implementated with vector registers, which makes the
-mgeneral-regs-only option less effective.  The new -mavoid-libcall
option expands memcpy, memmove and memset into REP MOVSB and REP STOSB
sequence.  This option can be further enhanced with a cmpmem pattern
to expand memcmp into REP CMPSB sequence in the future.

[Bug c++/95143] SFINAE failure with static_cast

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2020-05-14
 Status|UNCONFIRMED |WAITING

--- Comment #2 from Jonathan Wakely  ---
Please read https://gcc.gnu.org/bugs (as requested when creating a bug) and
provide the missing information.

[Bug c++/95143] SFINAE failure with static_cast

[familiebaumanns at gmail dot com]

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

Bernd Baumanns  changed:

   What|Removed |Added

URL||https://godbolt.org/z/yVjQf
   ||9

--- Comment #1 from Bernd Baumanns  ---
https://godbolt.org/z/FRznAh

[Bug c++/95143] New: SFINAE failure with static_cast

[familiebaumanns at gmail dot com]

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

Bug ID: 95143
   Summary: SFINAE failure with static_cast
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: familiebaumanns at gmail dot com
  Target Milestone: ---

Bug 90080 - [8 Regression] SFINAE failure with static_cast
Bug 87748 - [8 Regression] G++-8 treats SFINAE as error

This bug seems to be back in g++-10.1

See the following code: https://godbolt.org/z/yVjQf9

It works in g++-9 and in g++-11 / g++-trunk.

[Bug c/95142] New: ICE when compiling certain logic with -Ofast and -mpretend-cmove when dealing with floats

[hayden at hkowsoftware dot com]

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

Bug ID: 95142
   Summary: ICE when compiling certain logic with -Ofast and
-mpretend-cmove when dealing with floats
   Product: gcc
   Version: 9.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hayden at hkowsoftware dot com
  Target Milestone: ---

Created attachment 48537
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48537=edit
small self contained example showing the crash

this issue is exhibited by the included source in versions gcc 9.3 and 10.0.1
for the sh4 target.

It seems to be related to using cmove when dealing with access to a float using
an index from a pointer, included is a small ~60 line example demonstrating
this.

sh4-linux-gnu-gcc-9-Ofast -mpretend-cmove -c ice_sh4.c

ice_sh4.c: In function ‘call_create’:
ice_sh4.c:48:1: error: unrecognizable insn:
   48 | }
  | ^
(insn 26 25 27 2 (parallel [
(set (reg:SI 147 t)
(ge:SI (reg/v:SF 170 [ size_1 ])
(reg/v:SF 167 [ size_0 ])))
(clobber (reg:SI 155 fpscr1))
(use (reg:SI 154 fpscr0))
]) "ice_sh4.c":41:29 -1
 (nil))
during RTL pass: vregs
ice_sh4.c:48:1: internal compiler error: in extract_insn, at recog.c:2310



version info for gcc 9.3:
Using built-in specs.
COLLECT_GCC=sh4-linux-gnu-gcc-9
COLLECT_LTO_WRAPPER=/usr/lib/gcc-cross/sh4-linux-gnu/9/lto-wrapper
Target: sh4-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 9.3.0-8'
--with-bugurl=file:///usr/share/doc/gcc-9/README.Bugs
--enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++ --prefix=/usr
--with-gcc-major-version-only --program-suffix=-9 --enable-shared
--enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/
--enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-libsanitizer --disable-libquadmath --disable-libquadmath-support
--enable-plugin --with-system-zlib --disable-libphobos --enable-multiarch
--disable-werror --with-cpu=sh4 --with-multilib-list=m4,m4-nofpu
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=sh4-linux-gnu --program-prefix=sh4-linux-gnu-
--includedir=/usr/sh4-linux-gnu/include --with-build-config=bootstrap-lto-lean
--enable-link-mutex
Thread model: posix
gcc version 9.3.0 (Debian 9.3.0-8)


version info for gcc 10.0.1:
Using built-in specs.
COLLECT_GCC=sh4-linux-gnu-gcc-10
COLLECT_LTO_WRAPPER=/usr/lib/gcc-cross/sh4-linux-gnu/10/lto-wrapper
Target: sh4-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 10-20200418-1'
--with-bugurl=file:///usr/share/doc/gcc-10/README.Bugs
--enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++ --prefix=/usr
--with-gcc-major-version-only --program-suffix=-10 --enable-shared
--enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/
--enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-libsanitizer --disable-libquadmath --disable-libquadmath-support
--enable-plugin --with-system-zlib --disable-libphobos --enable-multiarch
--disable-werror --with-cpu=sh4 --with-multilib-list=m4,m4-nofpu
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=sh4-linux-gnu --program-prefix=sh4-linux-gnu-
--includedir=/usr/sh4-linux-gnu/include
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.0.1 20200418 (experimental) [master revision
27c171775ab:4c277008be0:c5bac7d127f288fd2f8a1f15c3f30da5903141c6] (Debian
10-20200418-1)

[Bug c/95141] New: Incorrect integer overflow warning message for bitand expression

[yadongh at vt dot edu]

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

Bug ID: 95141
   Summary: Incorrect integer overflow warning message for bitand
expression
   Product: gcc
   Version: 8.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: yadongh at vt dot edu
  Target Milestone: ---

C code:
#include 

uint64_t test(uint8_t IA1)
{
  return (uint8_t)(IA1 & 158) & 1UL;
}


Command:
gcc -c test.c


Warning message:
test.c: In function ‘test’:
test.c:5:31: warning: integer overflow in expression ‘(long unsigned int)IA1 &
158 & 1’ of type ‘long unsigned int’ results in ‘0’ [-Woverflow]
   return (uint8_t)(IA1 & 158) & 1UL;
  ~^


gcc -v output:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/8/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 8.3.0-6'
--with-bugurl=file:///usr/share/doc/gcc-8/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr
--with-gcc-
major-version-only --program-suffix=-8 --program-prefix=x86_64-linux-gnu-
--enable-shared --enable-linker-build-id --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --libdir=/usr/lib --enab
le-nls --enable-bootstrap --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new
--enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-pl
ugin --enable-default-pie --with-system-zlib --with-target-system-zlib
--enable-objc-gc=auto --enable-multiarch --disable-werror --with-arch-32=i686
--with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-mult
ilib --with-tune=generic --enable-offload-targets=nvptx-none
--without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 8.3.0 (Debian 8.3.0-6)

Note that I find this reproducible starting from GCC 7.1 to 10.1 (on GodBolt).


Platform:
Debian 10 Linux


Problem statement:
There are a lot of explicit/implicit integer type casts here, but in no way I
think integer overflow can happen. Note that essentially we are returning zero
here as 158 & 1 is just zero.
Some other interesting observations:
(uint8_t)(IA1 & 159) & 1UL;  --- No Warning
(uint8_t)(IA1 & 158U) & 1UL; --- No Warning
(uint8_t)(IA1 & 254) & 1UL;  --- Warning
(uint8_t)(IA1 & 2) & 1UL;--- No Warning

[Bug middle-end/95140] [10/11 Regression] bogus -Wstringop-overflow for a loop unrolled past the end of a trailing array

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
The warning should change, not the conservative assumption.  There is a lot of
code in the wild with such trailing arrays, not everything uses flexible array
members, [0] or [1] for that.

[Bug middle-end/95140] [10/11 Regression] bogus -Wstringop-overflow for a loop unrolled past the end of a trailing array

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #2 from Martin Sebor  ---
See also pr92110 for a report of redundant -Wstringop-overflow instances due to
loop unrolling.  A single warning should suffice (especially when it's a false
positive).

[Bug middle-end/95140] [10/11 Regression] bogus -Wstringop-overflow for a loop unrolled past the end of a trailing array

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Keywords||diagnostic,
   ||missed-optimization
URL||https://bugzilla.redhat.com
   ||/show_bug.cgi?id=1835906
  Known to fail||10.1.0, 11.0
 Ever confirmed|0   |1
   Last reconfirmed||2020-05-14

--- Comment #1 from Martin Sebor  ---
The missed-optimization keyword is for the unnecessary loop unrolling.

[Bug middle-end/95140] New: [10/11 Regression] bogus -Wstringop-overflow for a loop unrolled past the end of a trailing array

[msebor at gcc dot gnu.org]

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

Bug ID: 95140
   Summary: [10/11 Regression] bogus -Wstringop-overflow for a
loop unrolled past the end of a trailing array
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

As reported in https://bugzilla.redhat.com/show_bug.cgi?id=1835906, compiling
loops that copy a variable number of elements to a trailing character array
member results in many spurious instances of -Wstringop-overflow (below).

The reporter expects "No warnings about an overflow, and little or no code to
handle c > 8, as that would be undefined behaviour" and adds "It would be nice
if GCC still warned if a function like f was called with a value of c that was
a compile time constant > 8 however."

$ cat rhbz1835906.c && gcc -O3 -S -Wall -fdump-tree-strlen=/dev/stdout
rhbz1835906.c
struct A
{
  char v[8];
};

void f (struct A *p, char * s, int c)
{
  for (int i = 0; i < c; ++i)
p->v[i] = s[i];
}

;; Function f (f, funcdef_no=0, decl_uid=1934, cgraph_uid=1, symbol_order=0)

Created preheader block for loop 2
Created preheader block for loop 1
;; 4 loops found
;;
;; Loop 0
;;  header 0, latch 1
;;  depth 0, outer -1
;;  nodes: 0 1 2 3 4 28 5 30 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 27
23 29 24 25 26
;;
;; Loop 2
;;  header 23, latch 29
;;  depth 1, outer 0
;;  nodes: 23 29
;;
;; Loop 1
;;  header 5, latch 30
;;  depth 1, outer 0
;;  nodes: 5 30
;; 2 succs { 3 26 }
;; 3 succs { 14 4 }
;; 4 succs { 28 6 }
;; 28 succs { 5 }
;; 5 succs { 30 6 }
;; 30 succs { 5 }
;; 6 succs { 7 24 }
;; 7 succs { 8 24 }
;; 8 succs { 9 24 }
;; 9 succs { 10 24 }
;; 10 succs { 11 24 }
;; 11 succs { 12 24 }
;; 12 succs { 13 24 }
;; 13 succs { 24 }
;; 14 succs { 15 25 }
;; 15 succs { 16 25 }
;; 16 succs { 17 25 }
;; 17 succs { 18 25 }
;; 18 succs { 19 25 }
;; 19 succs { 20 25 }
;; 20 succs { 21 25 }
;; 21 succs { 22 25 }
;; 22 succs { 27 25 }
;; 27 succs { 23 }
;; 23 succs { 29 25 }
;; 29 succs { 23 }
;; 24 succs { 25 }
;; 25 succs { 26 }
;; 26 succs { 1 }
rhbz1835906.c: In function ‘f’:
rhbz1835906.c:9:13: warning: writing 1 byte into a region of size 0
[-Wstringop-overflow=]
9 | p->v[i] = s[i];
  | ^~
rhbz1835906.c:3:8: note: at offset [8, 2147483640] to object ‘v’ with size 8
declared here
3 |   char v[8];
  |^
rhbz1835906.c:9:13: warning: writing 1 byte into a region of size 0
[-Wstringop-overflow=]
9 | p->v[i] = s[i];
  | ^~
rhbz1835906.c:3:8: note: at offset [9, 2147483641] to object ‘v’ with size 8
declared here
3 |   char v[8];
  |^
rhbz1835906.c:9:13: warning: writing 1 byte into a region of size 0
[-Wstringop-overflow=]
9 | p->v[i] = s[i];
  | ^~
rhbz1835906.c:3:8: note: at offset [10, 2147483642] to object ‘v’ with size 8
declared here
3 |   char v[8];
  |^
rhbz1835906.c:9:13: warning: writing 1 byte into a region of size 0
[-Wstringop-overflow=]
9 | p->v[i] = s[i];
  | ^~
rhbz1835906.c:3:8: note: at offset [11, 2147483643] to object ‘v’ with size 8
declared here
3 |   char v[8];
  |^
rhbz1835906.c:9:13: warning: writing 1 byte into a region of size 0
[-Wstringop-overflow=]
9 | p->v[i] = s[i];
  | ^~
rhbz1835906.c:3:8: note: at offset [12, 2147483644] to object ‘v’ with size 8
declared here
3 |   char v[8];
  |^
rhbz1835906.c:9:13: warning: writing 1 byte into a region of size 0
[-Wstringop-overflow=]
9 | p->v[i] = s[i];
  | ^~
rhbz1835906.c:3:8: note: at offset [13, 2147483645] to object ‘v’ with size 8
declared here
3 |   char v[8];
  |^
rhbz1835906.c:9:13: warning: writing 1 byte into a region of size 0
[-Wstringop-overflow=]
9 | p->v[i] = s[i];
  | ^~
rhbz1835906.c:3:8: note: at offset [14, 2147483646] to object ‘v’ with size 8
declared here
3 |   char v[8];
  |^
rhbz1835906.c:9:13: warning: writing 1 byte into a region of size 0
[-Wstringop-overflow=]
9 | p->v[i] = s[i];
  | ^~
rhbz1835906.c:3:8: note: at offset 8 to object ‘v’ with size 8 declared here
3 |   char v[8];
  |^
f (struct A * p, char * s, int c)
{
  unsigned long ivtmp.24;
  sizetype ivtmp.15;
  vector(8) char * vectp_p.12;
  vector(8) char * vectp_p.11;
  vector(8) char vect__3.10;
  vector(8) char * vectp_s.9;
  vector(8) char * vectp_s.8;
  int tmp.7;
  unsigned int niters_vector_mult_vf.6;
  unsigned int bnd.5;
  unsigned int niters.4;
  int i;
  unsigned int _4;
  unsigned int _5;
  char _11;
  ssizetype _12;
  char * _13;
  _Bool _17;
  sizetype _19;
  _Bool _20;
  _Bool _21;
  char _26;
  sizetype _33;

[Bug fortran/95053] [11 regression] ICE in f951: gfc_divide()

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #27 from Steve Kargl  ---
On Thu, May 14, 2020 at 06:39:24PM +, tkoenig at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95053
> 
> --- Comment #26 from Thomas Koenig  ---
> (In reply to wschmidt from comment #24)
> 
> > I'm afraid I disagree.  A divide-by-zero that cannot ever be executed is 
> > not an error.
> 
> Well, there is PR90302.  We could insert some piece of code into the
> IL. A warning or an error could then be issued if the piece of code is still
> present after the final optimization.
> 
> It would make a nice project, and remove a few more false positives
> as well.
> 

gfortran supports a legacy extension of jumping into a if-block.

Prior to Harald's patch (which fixes at least 1 ICE), we have

% cat a.f90
program foo
   real x, y
   real, parameter :: c = 0
   x = 1
   y = 2
   goto 10
   if (c > 0) then
10x = (y / c) * c
   end if
   print *, x, y
end program foo
% gfcx -o z a.f90 && ./z
a.f90:8:2:

6 |goto 10
  |  2
7 |if (c > 0) then
8 | 10x = (y / c) * c
  |  1
Warning: Legacy Extension: Label at (1) is not in the same block as
the GOTO statement at (2)
  NaN   2.  

So, using 'if (c > 0)' to assume DCE occurs is invalid as the
code is reachable.  Perhaps, my original patch submitted at

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93499#c2

should have been committed with no attempt to aid a programmer
from making a potential mistake.

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

[iains at gcc dot gnu.org]

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

--- Comment #2 from Iain Sandoe  ---
Hi Rafael, 
nor me, the coros implementation is a set of AST transforms - so is supposed to
present the following code with valid trees - which would be analysed "as
normal".

[Bug c/95139] New: Messages using string concatenation can not be translated

[goeran at uddeborg dot se]

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

Bug ID: 95139
   Summary: Messages using string concatenation can not be
translated
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: goeran at uddeborg dot se
  Target Milestone: ---

In pru-pragma.c, in the function pru_pragma_ctable_entry, there are two error
messages created by concatenating string literals, where some of the literals
are preprocessor definitions.  This unfortunately fails when the messages are
to be extracted for translation.  Only the literals up to the first such
preprocessor symbol will be included in the message catalog, but that will
never be looked up.

  else if (i >= ARRAY_SIZE (pru_ctable))
error ("% index %" HOST_WIDE_INT_PRINT "d"
   " is not valid", i);
  else if (pru_ctable[i].valid && pru_ctable[i].base != base)
error ("redefinition of %", i);

Only "% index %" and "redefinition of %https://gcc.gnu.org/git?p=gcc.git;a=blob;f=gcc/config/pru/pru-pragma.c;h=5d6cc49b71494c0a224491be40247c50a5e2cd63;hb=HEAD#l60

[Bug fortran/95053] [11 regression] ICE in f951: gfc_divide()

[tkoenig at gcc dot gnu.org]

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

--- Comment #26 from Thomas Koenig  ---
(In reply to wschmidt from comment #24)

> I'm afraid I disagree.  A divide-by-zero that cannot ever be executed is 
> not an error.

Well, there is PR90302.  We could insert some piece of code into the
IL. A warning or an error could then be issued if the piece of code is still
present after the final optimization.

It would make a nice project, and remove a few more false positives
as well.

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

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||iains at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
Nothing I'd be aware of.

[Bug target/95134] Add a target option to avoid libcall

[pinskia at gcc dot gnu.org]

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

--- Comment #4 from Andrew Pinski  ---
https://gcc.gnu.org/onlinedocs/gcc-4.0.4/gcc/Standards.html#index-ffreestanding-58

[Bug fortran/95138] New: ICE on transfer to unlimited polymorphic

[jrfsousa at gmail dot com]

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

Bug ID: 95138
   Summary: ICE on transfer to unlimited polymorphic
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jrfsousa at gmail dot com
  Target Milestone: ---

Created attachment 48536
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48536=edit
Fortran code demonstrating problems.

Hi all!

ICE on 10 and 11, 9 compiles part of the code, so there is also some aspect of
regression here.

Using -Wsurprising gives surprising (to me...) diagnostics.

Not sure if all the code is kosher, most likely it is not...

using:

GNU Fortran (GCC) 11.0.0 20200513 (experimental)
GNU Fortran (GCC) 10.1.1 20200513
GNU Fortran (GCC) 9.3.1 20200513

Thank you very much.

Best regards,
José Rui

[Bug target/95134] Add a target option to avoid libcall

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |WONTFIX
 Status|REOPENED|RESOLVED

--- Comment #3 from Andrew Pinski  ---
(In reply to H.J. Lu from comment #2)
> Since -ffreestanding can generate libcall, we should add a target option to
> avoid libcall.

-minline-all-stringops
-mmemcpy-strategy=
-mmemset-strategy=

From
https://gcc.gnu.org/onlinedocs/gcc-10.1.0/gcc/Standards.html#index-ffreestanding
:
"Most of the compiler support routines used by GCC are present in libgcc, but
there are a few exceptions. GCC requires the freestanding environment provide
memcpy, memmove, memset and memcmp. Finally, if __builtin_trap is used, and the
target does not implement the trap pattern, then GCC emits a call to abort.

"

[Bug c++/95111] coroutines use-after-free with lambdas

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=78352
 Blocks||54367
 CC||egallager at gcc dot gnu.org

--- Comment #24 from Eric Gallager  ---
(In reply to Iain Sandoe from comment #6)
> 
> We (at least several of us) agree that this is a source of easy programming
> errors - and I expect there to be some revisiting in c++23.  That's a
> considerable challenge in the face of a mutable lambda - maybe (thinking
> aloud) needs something like Apple blocks, but with an automatic promotion of
> the closure to a heap object if it escapes the creating scope.

...(Apple blocks support is bug 78352, for reference)...


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54367
[Bug 54367] [meta-bug] lambda expressions

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

[rafael at espindo dot la]

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

Bug ID: 95137
   Summary: Sanitizers seem to be missing support for coroutines
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rafael at espindo dot la
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at 
gcc dot gnu.org
  Target Milestone: ---

In seastar (http://seastar.io/) we have experimental support for coroutines and
a simple test to check that it is working.

It currently passes with clang+asan and gcc+valgrind. Unfortunately it fails
with gcc + asan. It is not even that gcc's asan reports an error, it seems to
corrupt memory and the test hits a segmentation fault.

Sorry for the super generic bug report. I just wanted to check if it is a know
issue before I try to create a smallish testcase to add here.

[Bug inline-asm/95121] Wrong code generated: low-byte registers are silently used in place of their corresponding high-byte registers (ah, bh, ch, dh)

[craig.topper at gmail dot com]

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

Craig Topper  changed:

   What|Removed |Added

 CC||craig.topper at gmail dot com

--- Comment #6 from Craig Topper  ---
Could gcc at least emit an error?

[Bug target/95046] Vectorize V2SFmode operations

[cvs-commit at gcc dot gnu.org]

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

--- Comment #10 from CVS Commits  ---
The master branch has been updated by Uros Bizjak :

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

commit r11-400-g9056cd80351c65c3b9a3257644236f2007c46a3f
Author: Uros Bizjak 
Date:   Thu May 14 19:51:40 2020 +0200

i386: Add V2DFmode float trunc/extend functions [PR95046]

gcc/ChangeLog:

PR target/95046
* config/i386/sse.md (truncv2dfv2df2): New insn pattern.
(extendv2sfv2df2): Ditto.

testsuite/ChangeLog:

PR target/95046
* gcc.target/i386/pr95046-7.c: New test.

[Bug fortran/95053] [11 regression] ICE in f951: gfc_divide()

[wschmidt at gcc dot gnu.org]

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

--- Comment #25 from Bill Schmidt  ---
But I'm not going to worry about it further.

[Bug fortran/95053] [11 regression] ICE in f951: gfc_divide()

[wschmidt at linux dot ibm.com]

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

--- Comment #24 from wschmidt at linux dot ibm.com ---
On 5/14/20 12:08 PM, sgk at troutmask dot apl.washington.edu wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95053
>
> --- Comment #23 from Steve Kargl  ---
> On Thu, May 14, 2020 at 02:57:37PM +, wschmidt at gcc dot gnu.org wrote:
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95053
>>
>> Bill Schmidt  changed:
>>
>> What|Removed |Added
>> 
>>   CC||wschmidt at gcc dot gnu.org
>>
>> --- Comment #22 from Bill Schmidt  ---
>> Breaking legitimate code, even if "borderline," does not seem right to me.
>> Zero division is generally a runtime exception because of such cases.
>>
>> You write code for a general case, then later you discover "oh, well, we 
>> could
>> make this variable zero for our specific usage," and now the compiler throws 
>> a
>> fit?  Seems like this is warning-level stuff.
>>
> If Bill's reduction of the several thousand-line file to 10ish
> lines is an accurate reduction (and I have no reasons to doubt
> that it isn't), then no.  It is an programming error.  This is
> not the first time that gfortran has found a programming error
> in WRF.  Sure, in this case the 'if (cdleps > 0)' leads to dead
> code elimination, but DCE happens after gfortran has done some
> constant folding and common subexpression elimination in the
> front-end.
>
I'm afraid I disagree.  A divide-by-zero that cannot ever be executed is 
not an error.

[Bug c/95130] GCC ignoring attribute(format(gnu_printf)) on printf in mingw

[joseph at codesourcery dot com]

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

--- Comment #1 from joseph at codesourcery dot com  ---
See bug 92292.  The extra attribute isn't ignored, it simply means the 
function has multiple format attributes, which is valid, but should 
probably be special-cased for this case of built-in functions.

[Bug fortran/95053] [11 regression] ICE in f951: gfc_divide()

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #23 from Steve Kargl  ---
On Thu, May 14, 2020 at 02:57:37PM +, wschmidt at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95053
> 
> Bill Schmidt  changed:
> 
>What|Removed |Added
> 
>  CC||wschmidt at gcc dot gnu.org
> 
> --- Comment #22 from Bill Schmidt  ---
> Breaking legitimate code, even if "borderline," does not seem right to me.  
> Zero division is generally a runtime exception because of such cases.
> 
> You write code for a general case, then later you discover "oh, well, we could
> make this variable zero for our specific usage," and now the compiler throws a
> fit?  Seems like this is warning-level stuff.
> 

If Bill's reduction of the several thousand-line file to 10ish
lines is an accurate reduction (and I have no reasons to doubt
that it isn't), then no.  It is an programming error.  This is
not the first time that gfortran has found a programming error
in WRF.  Sure, in this case the 'if (cdleps > 0)' leads to dead
code elimination, but DCE happens after gfortran has done some
constant folding and common subexpression elimination in the
front-end.

[Bug c++/57943] [c++11] invalid decltype expression accepted in template default type

[ppalka at gcc dot gnu.org]

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

Patrick Palka  changed:

   What|Removed |Added

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

[Bug c++/78446] Ambiguous member lookup for operator() in a function call expression treated as hard error in SFINAE context

[ppalka at gcc dot gnu.org]

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

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #3 from Patrick Palka  ---
Fixed for GCC 11.

[Bug c++/78446] Ambiguous member lookup for operator() in a function call expression treated as hard error in SFINAE context

[cvs-commit at gcc dot gnu.org]

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Patrick Palka :

https://gcc.gnu.org/g:098cf31aa2631db6922d4de5661c1b0ce19af0aa

commit r11-399-g098cf31aa2631db6922d4de5661c1b0ce19af0aa
Author: Patrick Palka 
Date:   Thu May 14 12:56:18 2020 -0400

c++: Missing SFINAE with lookup_fnfields [PR78446]

Here we're failing to do SFINAE in build_op_call when looking up the
class's operator() via lookup_fnfields, which calls lookup_member always
with complain=tf_warning_or_error; from there we would complain
about an ambiguous lookup for operator().

This patch fixes this by adding a tsubst_flags_t parameter to
lookup_fnfields and adjusting all its callers appropriately.

gcc/cp/ChangeLog:

PR c++/78446
* call.c (build_op_call): Pass complain to lookup_fnfields.
(build_special_member_call): Likewise.
* class.c (type_requires_array_cookie): Pass tf_warning_or_error
to lookup_fnfields.
* cp-tree.h (lookup_fnfields): Add tsubst_flags_t parameter.
* except.c (build_throw): Pass tf_warning_or_error to
lookup_fnfields.
* init.c (build_new_1): Pass complain to lookup_fnfields.
* method.c (locate_fn_flags): Likewise.
* name-lookup.c (lookup_name_real_1): Pass tf_warning_or_error
to lookup_fnfields.
* pt.c (tsubst_baselink): Pass complain to lookup_fnfields.
* search.c (lookup_fnfields): New 'complain' parameter.  Pass it
to lookup_member.

gcc/testsuite/ChangeLog:

PR c++/78446
* g++.dg/template/sfinae31.C: New test.

[Bug fortran/95119] [9/10 Regression] CLOSE hangs when -fopenmp is specified in compilation

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

   Target Milestone|--- |9.4
Summary|CLOSE hangs when -fopenmp   |[9/10 Regression] CLOSE
   |is specified in compilation |hangs when -fopenmp is
   ||specified in compilation

--- Comment #7 from Thomas Koenig  ---
Still two revisions to fix.

[Bug fortran/95119] CLOSE hangs when -fopenmp is specified in compilation

[cvs-commit at gcc dot gnu.org]

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

--- Comment #6 from CVS Commits  ---
The master branch has been updated by Thomas Kथà¤nig :

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

commit r11-397-gcdc34b505796327b3eee9e97bc5f27ba71fd9e7a
Author: Thomas Koenig 
Date:   Thu May 14 18:30:27 2020 +0200

Add early return for invalid STATUS for close.

2020-05-14  Thomas Koenig  

PR libfortran/95119
* io/close.c (close_status): Add CLOSE_INVALID.
(st_close): Return early on invalid STATUS parameter.

2020-05-14  Thomas Koenig  

PR libfortran/95119
* testsuite/libgomp.fortran/close_errors_1.f90: New test.

[Bug target/95134] Add a target option to avoid libcall

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

Summary|-ffreestanding should avoid |Add a target option to
   |libcall |avoid libcall
 Status|RESOLVED|REOPENED
 Ever confirmed|0   |1
   Last reconfirmed||2020-05-14
 Resolution|WONTFIX |---

--- Comment #2 from H.J. Lu  ---
Since -ffreestanding can generate libcall, we should add a target option to
avoid libcall.

[Bug fortran/95119] CLOSE hangs when -fopenmp is specified in compilation

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--- Comment #5 from Thomas Koenig  ---
This looks simple enough.  Regression-testing as I write this.

@@ -31,7 +31,7 @@ see the files COPYING3 and COPYING.RUNTIME respectively.  If
not, see
 #endif

 typedef enum
-{ CLOSE_DELETE, CLOSE_KEEP, CLOSE_UNSPECIFIED }
+{ CLOSE_INVALID = - 1, CLOSE_DELETE, CLOSE_KEEP, CLOSE_UNSPECIFIED }
 close_status;

 static const st_option status_opt[] = {
@@ -61,6 +61,12 @@ st_close (st_parameter_close *clp)
 find_option (>common, clp->status, clp->status_len,
 status_opt, "Bad STATUS parameter in CLOSE statement");

+  if (status == CLOSE_INVALID)
+{
+  library_end ();
+  return;
+}
+
   u = find_unit (clp->common.unit);

   if (ASYNC_IO && u && u->au)

[Bug c/95133] [9/10/11 Regression] ICE in gimple_redirect_edge_and_branch_force, at tree-cfg.c:6075

[jgreenhalgh at gcc dot gnu.org]

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

--- Comment #2 from James Greenhalgh  ---
Should reproduce further back if you force it on with -ftree-vectorize .

i.e.

gcc foo.c -ftree-vectorize -O3

Breaks somewhere between:

gcc version 7.0.0 20160615
gcc version 7.0.0 20160907

[Bug target/94748] aarch64: many unnecessary bti j emitted

[nsz at gcc dot gnu.org]

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

nsz at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #4 from nsz at gcc dot gnu.org ---
fixed for gcc-10.1 and on the gcc-9 branch.

[Bug target/94697] aarch64: bti j at function start instead of bti c

[nsz at gcc dot gnu.org]

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

nsz at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #8 from nsz at gcc dot gnu.org ---
fixed for gcc-10.1 and on the gcc-9 branch.

[Bug target/94515] aarch64: broken unwind information for pac-ret

[nsz at gcc dot gnu.org]

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

nsz at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #5 from nsz at gcc dot gnu.org ---
fixed for gcc-10.1 and on gcc-9 and gcc-8 branches.

[Bug target/94514] aarch64: unwinding across mixed pac-ret and non-pac-ret frames is broken

[nsz at gcc dot gnu.org]

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

nsz at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #5 from nsz at gcc dot gnu.org ---
fixed for gcc-10.1 and on gcc-9 and gcc-8 branches.

[Bug target/94515] aarch64: broken unwind information for pac-ret

[nsz at gcc dot gnu.org]

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

Bug 94514 Summary: aarch64: unwinding across mixed pac-ret and non-pac-ret 
frames is broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94514

   What|Removed |Added

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

[Bug target/94515] aarch64: broken unwind information for pac-ret

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:62ab8b9114b0bdae508ed76fa9028e0040d35e6b

commit r8-10253-g62ab8b9114b0bdae508ed76fa9028e0040d35e6b
Author: Szabolcs Nagy 
Date:   Mon Apr 27 09:07:15 2020 +0100

aarch64: Fix .cfi_window_save with pac-ret [PR94515]

On aarch64 -mbranch-protection=pac-ret reuses the dwarf
opcode for window_save to mean "toggle the return address
mangle state", but in the dwarf2cfi internal logic the
state was not updated when an opcode was emitted, the
currently present update logic is only valid for the
original sparc use of window_save so a separate bool is
used on aarch64 to track the state.

This bug can cause the unwinder not to authenticate return
addresses that were signed (or vice versa) which means a
runtime crash on a pauth enabled system.

Currently only aarch64 pac-ret uses REG_CFA_TOGGLE_RA_MANGLE.

This should be backported to gcc-9 and gcc-8 branches.

Changed branch-protection=pac-ret to sign-return-address=all etc
in the tests for the backport and adjusted the dwarf2cfi.c
changes because the sparc change was missing.

gcc/ChangeLog:

Backport from mainline.
2020-04-27  Szabolcs Nagy  

PR target/94515
* dwarf2cfi.c (struct GTY): Add ra_mangled.
(cfi_row_equal_p): Check ra_mangled.
(dwarf2out_frame_debug_cfa_window_save): Remove the argument,
this only handles the sparc logic now.
(dwarf2out_frame_debug_cfa_toggle_ra_mangle): New function for
the aarch64 specific logic.
(dwarf2out_frame_debug): Update to use the new subroutines.
(change_cfi_row): Check ra_mangled.

gcc/testsuite/ChangeLog:

Backport from mainline.
2020-04-27  Szabolcs Nagy  

PR target/94515
* g++.target/aarch64/pr94515-1.C: New test.
* g++.target/aarch64/pr94515-2.C: New test.

[Bug target/94514] aarch64: unwinding across mixed pac-ret and non-pac-ret frames is broken

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r8-10252-gd523cd5109bc5ab42edf85385f6a1085e0d6028c
Author: Szabolcs Nagy 
Date:   Fri Apr 3 09:35:41 2020 +

aarch64, libgcc: Fix unwinding from pac-ret to normal frames [PR94514]

With -mbranch-protection=pac-ret the debug info toggles the
signedness state of the return address so the unwinder knows when
the return address needs pointer authentication.

The unwind context flags were not updated according to the dwarf
frame info.

This causes unwinding across frames that were built without pac-ret
to incorrectly authenticate the return address wich corrupts the
return address on a system where PAuth is enabled.

Note: This even affects systems where all code use pac-ret because
unwinding across a signal frame the return address is not signed.

Changed branch-protection=pac-ret to sign-return-address=all etc
in the tests for the backport.

gcc/testsuite/ChangeLog:

Backport from mainline.
2020-04-23  Szabolcs Nagy  

PR target/94514
* g++.target/aarch64/pr94514.C: Require lp64.
* gcc.target/aarch64/pr94514.c: Likewise.

Backport from mainline.
2020-04-21  Szabolcs Nagy  

PR target/94514
* g++.target/aarch64/pr94514.C: New test.
* gcc.target/aarch64/pr94514.c: New test.

libgcc/ChangeLog:

Backport from mainline.
2020-04-21  Szabolcs Nagy  

PR target/94514
* config/aarch64/aarch64-unwind.h (aarch64_frob_update_context):
Update context->flags accroding to the frame state.

[Bug middle-end/95136] missing -Wuninitialized on an array access with a variable offset

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1
 Blocks||24639
   Last reconfirmed||2020-05-14
   Keywords||diagnostic

--- Comment #1 from Martin Sebor  ---
I'm testing a fix.


Referenced Bugs:

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

[Bug c++/95135] Inconsistent CTAD behaviour with the "new" operator.

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||rejects-valid
 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #1 from Jonathan Wakely  ---
GCC 7 is no longer supported or maintained, and this bug has already been fixed
in r260901 and is a duplicate of PR c++/85883

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

[Bug c++/85883] class template argument deduction fails in new-expression

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||gccbugreport at yandex dot com

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

[Bug middle-end/95136] New: missing -Wuninitialized on an array access with a variable offset

[msebor at gcc dot gnu.org]

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

Bug ID: 95136
   Summary: missing -Wuninitialized on an array access with a
variable offset
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

GCC successfully reports uninitialized reads from arrays involving variable
indices but it fails to find the same bugs when besides the index the array
reference also includes an offset.  The test case below shows the difference.

In addition, the issued warning in these cases is missing essential detail such
as the name or location of the declaration of the variable.

$ cat x.c && gcc -O2 -S -Wall -fdump-tree-uninit=/dev/stdout x.c
int f (int i)
{ 
  int a[4];
  int *p = [i + 1];
  return *p; // -Wuninitialized
}

int g (int i)
{
  int a[4];
  int *p = [i] + 1;
  return *p; // missing warning
}

;; Function f (f, funcdef_no=0, decl_uid=1930, cgraph_uid=1, symbol_order=0)

x.c: In function ‘f’:
x.c:5:10: warning: ‘a[]’ is used uninitialized in this function
[-Wuninitialized]
5 |   return *p; // -Wuninitialized
  |  ^~
f (int i)
{
  int a[4];
  int _1;
  int _4;

   [local count: 1073741824]:
  _1 = i_2(D) + 1;
  _4 = MEM  [(int *)][_1];
  a ={v} {CLOBBER};
  return _4;

}



;; Function g (g, funcdef_no=1, decl_uid=1935, cgraph_uid=2, symbol_order=1)

g (int i)
{
  int a[4];
  int * _1;
  int _4;
  sizetype _6;
  sizetype _7;

   [local count: 1073741824]:
  _6 = (sizetype) i_2(D);
  _7 = _6 * 4;
  _1 =  + _7;
  _4 = MEM[(int *)_1 + 4B];
  a ={v} {CLOBBER};
  return _4;

}

[Bug c++/95132] Concept checked after auto return type deduction

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2020-05-14
 Status|UNCONFIRMED |WAITING

--- Comment #1 from Jonathan Wakely  ---
Please read https://gcc.gnu.org/bugs (as requested when creating a bug) and
provide the missing information.

[Bug target/94743] IRQ handler doesn't save scratch VFP registers

[clyon at gcc dot gnu.org]

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

--- Comment #19 from Christophe Lyon  ---
(In reply to Christophe Lyon from comment #8)
> Patch sent: https://gcc.gnu.org/pipermail/gcc-patches/2020-April/544872.html
> 
> This is a simple improvement, hopefully simple enough for stage 4, yet
> useful for the end-users.

I have just sent an updated version of this patch:
https://gcc.gnu.org/pipermail/gcc-patches/2020-May/545747.html

Maybe that would be sufficient to consider this PR fixed?

Indeed I fear we open a can of worms, as I've also realized that at least some
Cortex-M cores save part of the FP registers when taking an interruption, the
number depends on several parameters (eg secure/non-secure, ... see "Exception
entry in Cortex-M33 GUG for instance
https://static.docs.arm.com/100235/0002/arm_cortex_m33_dgug_100235_0002_00_en.pdf)

I haven't found such documentation for Cortex-A, so I'm not sure if they have
the same behaviour.

I have attached a WIP patch that demonstrates local saving of FP registers as
an attachment to https://gcc.gnu.org/pipermail/gcc-patches/2020-May/545754.html

[Bug target/94514] aarch64: unwinding across mixed pac-ret and non-pac-ret frames is broken

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:6173489dbfe5828b2c4082d7a450a766779f87c7

commit r9-8592-g6173489dbfe5828b2c4082d7a450a766779f87c7
Author: Szabolcs Nagy 
Date:   Fri Apr 3 09:35:41 2020 +

aarch64, libgcc: Fix unwinding from pac-ret to normal frames [PR94514]

With -mbranch-protection=pac-ret the debug info toggles the
signedness state of the return address so the unwinder knows when
the return address needs pointer authentication.

The unwind context flags were not updated according to the dwarf
frame info.

This causes unwinding across frames that were built without pac-ret
to incorrectly authenticate the return address wich corrupts the
return address on a system where PAuth is enabled.

Note: This even affects systems where all code use pac-ret because
unwinding across a signal frame the return address is not signed.

gcc/testsuite/ChangeLog:

Backport from mainline.
2020-04-23  Szabolcs Nagy  

PR target/94514
* g++.target/aarch64/pr94514.C: Require lp64.
* gcc.target/aarch64/pr94514.c: Likewise.

Backport from mainline.
2020-04-21  Szabolcs Nagy  

PR target/94514
* g++.target/aarch64/pr94514.C: New test.
* gcc.target/aarch64/pr94514.c: New test.

libgcc/ChangeLog:

Backport from mainline.
2020-04-21  Szabolcs Nagy  

PR target/94514
* config/aarch64/aarch64-unwind.h (aarch64_frob_update_context):
Update context->flags accroding to the frame state.

[Bug target/94515] aarch64: broken unwind information for pac-ret

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:95833c34424f340a7e465ee38b6a41369bc7c90b

commit r9-8593-g95833c34424f340a7e465ee38b6a41369bc7c90b
Author: Szabolcs Nagy 
Date:   Mon Apr 27 09:07:15 2020 +0100

aarch64: Fix .cfi_window_save with pac-ret [PR94515]

On aarch64 -mbranch-protection=pac-ret reuses the dwarf
opcode for window_save to mean "toggle the return address
mangle state", but in the dwarf2cfi internal logic the
state was not updated when an opcode was emitted, the
currently present update logic is only valid for the
original sparc use of window_save so a separate bool is
used on aarch64 to track the state.

This bug can cause the unwinder not to authenticate return
addresses that were signed (or vice versa) which means a
runtime crash on a pauth enabled system.

Currently only aarch64 pac-ret uses REG_CFA_TOGGLE_RA_MANGLE.

This should be backported to gcc-9 and gcc-8 branches.

gcc/ChangeLog:

Backport from mainline.
2020-04-27  Szabolcs Nagy  

PR target/94515
* dwarf2cfi.c (struct GTY): Add ra_mangled.
(cfi_row_equal_p): Check ra_mangled.
(dwarf2out_frame_debug_cfa_window_save): Remove the argument,
this only handles the sparc logic now.
(dwarf2out_frame_debug_cfa_toggle_ra_mangle): New function for
the aarch64 specific logic.
(dwarf2out_frame_debug): Update to use the new subroutines.
(change_cfi_row): Check ra_mangled.

gcc/testsuite/ChangeLog:

Backport from mainline.
2020-04-27  Szabolcs Nagy  

PR target/94515
* g++.target/aarch64/pr94515-1.C: New test.
* g++.target/aarch64/pr94515-2.C: New test.

[Bug target/94748] aarch64: many unnecessary bti j emitted

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r9-8595-g9a1b74d49e2e25b29675fac4322bb7ba6cec5894
Author: Szabolcs Nagy 
Date:   Fri Apr 24 17:36:02 2020 +0100

aarch64: don't emit bti j after NOTE_INSN_DELETED_LABEL [PR94748]

It was previously discussed that indirect branches cannot go to
NOTE_INSN_DELETED_LABEL so inserting a landing pad is unnecessary.
See https://gcc.gnu.org/pipermail/gcc-patches/2019-May/522625.html

Before the patch a bti j was inserted after the label in

  __attribute__((target("branch-protection=bti")))
  int foo (void)
  {
  label:
return 0;
  }

This is not necessary and weakens the security protection.

gcc/ChangeLog:

Backport from mainline.
2020-04-30  Szabolcs Nagy  

PR target/94748
* config/aarch64/aarch64-bti-insert.c (rest_of_insert_bti): Remove
the check for NOTE_INSN_DELETED_LABEL.

gcc/testsuite/ChangeLog:

Backport from mainline.
2020-04-30  Szabolcs Nagy  

PR target/94748
* gcc.target/aarch64/pr94748.c: New test.

[Bug target/94697] aarch64: bti j at function start instead of bti c

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r9-8594-gf6e42cdee5de2b3441afc88cc1166bdffe57
Author: Szabolcs Nagy 
Date:   Fri Apr 17 16:54:12 2020 +0100

aarch64: ensure bti c is emitted at function start [PR94697]

The bti pass currently first emits bti c at function start
if there is no paciasp (which also acts as indirect call
landing pad), then bti j is emitted at jump labels, however
if there is a label right before paciasp then the function
start can end up like

  foo:
  label:
bti j
paciasp
...

This patch is a minimal fix that just moves the bti c handling
after the bti j handling so we end up with

  foo:
bti c
  label:
bti j
paciasp
...

This could be improved by emitting bti jc in this case, or by
detecting that the label is not in fact an indirect jump target
and then this situation would be much less common.

Needs to be backported to gcc-9 branch.

Backported without the testcase because of missing infrastructure
for check-function-bodies.

gcc/ChangeLog:

Backport from mainline.
2020-04-23  Szabolcs Nagy  

PR target/94697
* config/aarch64/aarch64-bti-insert.c (rest_of_insert_bti): Swap
bti c and bti j handling.

[Bug fortran/95119] CLOSE hangs when -fopenmp is specified in compilation

[tkoenig at gcc dot gnu.org]

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

--- Comment #4 from Thomas Koenig  ---
So, in order for this to hang, two close statements
on the same unit are needed, the first one with an
error message.

Seems like the unit is not unlocked on the error return.

[Bug c++/95135] New: Inconsistent CTAD behaviour with the "new" operator.

[gccbugreport at yandex dot com]

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

Bug ID: 95135
   Summary: Inconsistent CTAD behaviour with the "new" operator.
   Product: gcc
   Version: 7.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gccbugreport at yandex dot com
  Target Milestone: ---

Created attachment 48535
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48535=edit
The preprocessed file.

This is my first bug report, I hope it includes all the necessary information.
In any case, this bug is very easy to replicate.
===
The code (main.cpp):

template
struct X {
X(T _t) {}
};

template
struct Y {
Y(T _t, U _u) {}
};

int main() {
X(1);
new X(1);

Y(1, 2);
new Y(1, 2); // This line causes the compilation error.

return 0;
}
===
Compiled with:

gcc -v -save-temps -std=c++17 main.cpp -lstdc++
===
Output:

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/7/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
7.5.0-3ubuntu1~18.04' --with-bugurl=file:///usr/share/doc/gcc-7/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr
--with-gcc-major-version-only --program-suffix=-7
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie
--with-system-zlib --with-target-system-zlib --enable-objc-gc=auto
--enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none --without-cuda-driver
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 7.5.0 (Ubuntu 7.5.0-3ubuntu1~18.04) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++1z' '-mtune=generic'
'-march=x86-64'
 /usr/lib/gcc/x86_64-linux-gnu/7/cc1plus -E -quiet -v -imultiarch
x86_64-linux-gnu -D_GNU_SOURCE main.cpp -mtune=generic -march=x86-64 -std=c++1z
-fpch-preprocess -fstack-protector-strong -Wformat -Wformat-security -o main.ii
ignoring duplicate directory "/usr/include/x86_64-linux-gnu/c++/7"
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-linux-gnu/7/../../../../x86_64-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/include/c++/7
 /usr/include/x86_64-linux-gnu/c++/7
 /usr/include/c++/7/backward
 /usr/lib/gcc/x86_64-linux-gnu/7/include
 /usr/local/include
 /usr/lib/gcc/x86_64-linux-gnu/7/include-fixed
 /usr/include/x86_64-linux-gnu
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++1z' '-mtune=generic'
'-march=x86-64'
 /usr/lib/gcc/x86_64-linux-gnu/7/cc1plus -fpreprocessed main.ii -quiet
-dumpbase main.cpp -mtune=generic -march=x86-64 -auxbase main -std=c++1z
-version -fstack-protector-strong -Wformat -Wformat-security -o main.s
GNU C++14 (Ubuntu 7.5.0-3ubuntu1~18.04) version 7.5.0 (x86_64-linux-gnu)
compiled by GNU C version 7.5.0, GMP version 6.1.2, MPFR version 4.0.1,
MPC version 1.1.0, isl version isl-0.19-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++14 (Ubuntu 7.5.0-3ubuntu1~18.04) version 7.5.0 (x86_64-linux-gnu)
compiled by GNU C version 7.5.0, GMP version 6.1.2, MPFR version 4.0.1,
MPC version 1.1.0, isl version isl-0.19-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 3eb3dc290cd5714c3e1c3ae751116f07
main.cpp: In function ‘int main()’:
main.cpp:16:15: error: class template argument deduction failed:
 new Y(1, 2); // This line causes the compilation error.
   ^
main.cpp:16:15: error: no matching function for call to ‘Y()’
main.cpp:8:5: note: candidate: template Y(T, U)-> Y
 Y(T _t, U _u) {}
 ^
main.cpp:8:5: note:   template argument deduction/substitution failed:
main.cpp:16:15: note:   candidate expects 2 arguments, 0 provided
 new Y(1, 2); // This line causes the compilation error.
===

[Bug target/95134] -ffreestanding should avoid libcall

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #1 from Andrew Pinski  ---
This is documented this way and has been true for years and documented for
years.

[Bug c/95133] [9/10/11 Regression] ICE in gimple_redirect_edge_and_branch_force, at tree-cfg.c:6075

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Last reconfirmed||2020-05-14
 CC||jgreenhalgh at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Confirmed, started with r8-2217-g0919ce3efe2a0d6a.

[Bug fortran/95053] [11 regression] ICE in f951: gfc_divide()

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

 CC||wschmidt at gcc dot gnu.org

--- Comment #22 from Bill Schmidt  ---
Breaking legitimate code, even if "borderline," does not seem right to me.  
Zero division is generally a runtime exception because of such cases.

You write code for a general case, then later you discover "oh, well, we could
make this variable zero for our specific usage," and now the compiler throws a
fit?  Seems like this is warning-level stuff.

[Bug target/95134] New: -ffreestanding should avoid libcall

[hjl.tools at gmail dot com]

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

Bug ID: 95134
   Summary: -ffreestanding should avoid libcall
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: ubizjak at gmail dot com
  Target Milestone: ---
Target: i386, x86-64

[hjl@gnu-cfl-2 freestand]$ cat x.i 
struct foo
{
  char array[257];
};

extern struct foo x;

void
func (struct foo i)
{
  x = i;
}
[hjl@gnu-cfl-2 freestand]$ make x.s
/export/build/gnu/tools-build/gcc-gitlab-debug/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/tools-build/gcc-gitlab-debug/build-x86_64-linux/gcc/ -O2 -W
-ffreestanding -mtune=pentium -m32 -S x.i
[hjl@gnu-cfl-2 freestand]$ cat x.s
.file   "x.i"
.text
.p2align 4
.globl  func
.type   func, @function
func:
.LFB0:
.cfi_startproc
subl$16, %esp
.cfi_def_cfa_offset 20
pushl   $257
.cfi_def_cfa_offset 24
leal24(%esp), %eax
pushl   %eax
.cfi_def_cfa_offset 28
pushl   $x
.cfi_def_cfa_offset 32
callmemcpy
addl$28, %esp
.cfi_def_cfa_offset 4
ret
.cfi_endproc
.LFE0:
.size   func, .-func
.ident  "GCC: (GNU) 11.0.0 20200514 (experimental)"
.section.note.GNU-stack,"",@progbits
[hjl@gnu-cfl-2 freestand]$ 

x86 backend should avoid libcall if flag_hosted is false.

[Bug c/95133] New: [9/10/11 Regression] ICE in gimple_redirect_edge_and_branch_force, at tree-cfg.c:6075

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

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

Bug ID: 95133
   Summary: [9/10/11 Regression] ICE in
gimple_redirect_edge_and_branch_force, at
tree-cfg.c:6075
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Started with r8, needs option -O3 :


$ cat z1.c
extern int a[16];
void f (int *ip, int x)
{
  int *xp = a;
  for (int i=0; i<8; ++i)
  {
base: if (x) return;
  }
  *xp++ = *ip;
  goto *(& + *ip);
}


$ gcc-11-20200510 -c z1.c -O2
$ gcc-11-20200510 -c z1.c -O3
during GIMPLE pass: split-paths
z1.c: In function 'f':
z1.c:2:6: internal compiler error: in gimple_redirect_edge_and_branch_force, at
tree-cfg.c:6075
2 | void f (int *ip, int x)
  |  ^
0xd2de58 gimple_redirect_edge_and_branch_force
../../gcc/tree-cfg.c:6075
0x7d32a3 redirect_edge_and_branch_force(edge_def*, basic_block_def*)
../../gcc/cfghooks.c:490
0x7d509a duplicate_block(basic_block_def*, edge_def*, basic_block_def*,
copy_bb_data*)
../../gcc/cfghooks.c:1109
0xcddf05 transform_duplicate(basic_block_def*, basic_block_def*)
../../gcc/tracer.c:245
0x1697ae0 split_paths
../../gcc/gimple-ssa-split-paths.c:463
0x1697ae0 execute_split_paths
../../gcc/gimple-ssa-split-paths.c:503
0x1697ae0 execute
../../gcc/gimple-ssa-split-paths.c:540

[Bug fortran/95107] ICE in hash_operand, at fold-const.c:3768

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

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

G. Steinmetz  changed:

   What|Removed |Added

Summary|[10/11 Regression] ICE in   |ICE in hash_operand, at
   |hash_operand, at|fold-const.c:3768
   |fold-const.c:3768   |

--- Comment #2 from G. Steinmetz  ---
> I see a Fortran FE ICE since at least 4.8.0:
Can confirm that with test versions too.

[Bug c++/95132] New: Concept checked after auto return type deduction

[bluescarni at gmail dot com]

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

Bug ID: 95132
   Summary: Concept checked after auto return type deduction
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bluescarni at gmail dot com
  Target Milestone: ---

It seems like in GCC's implementation of C++20 concepts, concept checking is
done after the instantiation of the body of a function with auto return type
deduction.

See the godbolt link, where the same snippet of code is being compiled with
GCC, clang and MSVC:

https://godbolt.org/z/CMzZyV

As you see, the first GCC error comes from the failure in the instantiation of
the body of function bar(), and only later GCC complains about the concept
check failure. The other two compilers don't produce any error from the
instantiation of bar().

This is problematic because it means that another concept that would check
whether or not bar() can be called with a specific argument type would fail
with a hard compile time error, instead of marking the concept as not
satisfied.

[Bug pch/95131] Instantiate templates at pch generation time

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

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

--- Comment #2 from Nathan Sidwell  ---
1) The future is sooner than you think :)

2) template instantiation cannot be done speculatively -- only when language
constructs require it.  Otherwise you can change the meaning of well-formed
code.

[Bug target/92658] x86 lacks vector extend / truncate

[rsandifo at gcc dot gnu.org]

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

--- Comment #12 from rsandifo at gcc dot gnu.org  
---
(In reply to rguent...@suse.de from comment #11)
> On Thu, 14 May 2020, ubizjak at gmail dot com wrote:
> 
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92658
> > 
> > --- Comment #10 from Uroš Bizjak  ---
> > The patch is ready to be pushed, it is waiting for a decision what to do 
> > with
> > failed cases.
> > 
> > Richi, should this patch move forward (eventually XFAILing failed cases), 
> > or do
> > you plan to look at the fails from the generic vectorizer POV?
> 
> I think we should go forward with the patch, either XFAILing the testcases
> or splitting out the testcase (and backend patterns that do not get
> exercised due to the issue).
> 
> I've already said in comment#8 that the issue here is optabs working
> with modes and not vector types, so it's a bit hard to use the
> same mechanism to deal with the currently failing cases.  One
> possible route would be to add V4QImode similar to how we now
> do V2SFmode with SSE but of course where do we stop ...
> 
> As said we can try to tackle this incrementally.  Maybe Richard also
> has input here?
Nothing to add really, but: yeah, the idea was that the target
would provide smaller vector modes if it can efficiently load,
store and (at least) add them.  I think it would be good to do
that for aarch64 Advanced SIMD at some point.

There are three points behind using vector modes for this:

1. It gives the target the flexibility to decide how best to
   implement the operation (All at one end, and if so, which end?
   Or spread out evenly across the vector?)  On aarch64, the
   choice would differ between SVE and Advanced SIMD.

2. It means that __attribute__((vector_size)) vectors benefit.

3. The smaller modes can be used in conjunction with
   autovectorize_vector_modes to give the loop vectoriser
   a choice between operating on packed or unpacked vectors.
   This is mostly useful for VECT_COMPARE_COSTS but can help
   with low-trip-count loops even without.

So yeah, defining V4QI sounds like the way to go if the
architecture can process it efficiently.  I get the "where
do we stop" concern, but .md mode iterators should help.

[Bug pch/95131] Instantiate templates at pch generation time

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||nathan at gcc dot gnu.org

--- Comment #1 from Richard Biener  ---
Modules are the future, not sure how this applies there.

[Bug bootstrap/95122] Cross-compile arm32 toolchain with hard float, but Error in gcc final

[sch...@linux-m68k.org]

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

Andreas Schwab  changed:

   What|Removed |Added

 Resolution|FIXED   |INVALID

[Bug bootstrap/95122] Cross-compile arm32 toolchain with hard float, but Error in gcc final

[chengcongxiu at huawei dot com]

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

chengcongxiu at huawei dot com  changed:

   What|Removed |Added

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

[Bug target/92658] x86 lacks vector extend / truncate

[rguenther at suse dot de]

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

--- Comment #11 from rguenther at suse dot de  ---
On Thu, 14 May 2020, ubizjak at gmail dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92658
> 
> --- Comment #10 from Uroš Bizjak  ---
> The patch is ready to be pushed, it is waiting for a decision what to do with
> failed cases.
> 
> Richi, should this patch move forward (eventually XFAILing failed cases), or 
> do
> you plan to look at the fails from the generic vectorizer POV?

I think we should go forward with the patch, either XFAILing the testcases
or splitting out the testcase (and backend patterns that do not get
exercised due to the issue).

I've already said in comment#8 that the issue here is optabs working
with modes and not vector types, so it's a bit hard to use the
same mechanism to deal with the currently failing cases.  One
possible route would be to add V4QImode similar to how we now
do V2SFmode with SSE but of course where do we stop ...

As said we can try to tackle this incrementally.  Maybe Richard also
has input here?

[Bug pch/95131] New: Instantiate templates at pch generation time

[trass3r at gmail dot com]

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

Bug ID: 95131
   Summary: Instantiate templates at pch generation time
   Product: gcc
   Version: 8.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: pch
  Assignee: unassigned at gcc dot gnu.org
  Reporter: trass3r at gmail dot com
  Target Milestone: ---

Judging by the limited information -ftime-report provides it looks like gcc
still spends quite some time on things that could have been done at pch
generation time already like template instantiations.

This was already noted in
https://gcc.gnu.org/wiki/Speedup_areas#Improvements_to_PCH
The page should be updated if this is not true anymore.

Clang has a similar problem that is currently being addressed:
https://llunak.blogspot.com/2019/11/clang-precompiled-headers-and-improving.html
https://reviews.llvm.org/D69585