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!

Re: [PATCH] Extend std::copy/std::copy_n char* overload to deque iterator

[François Dumont via Gcc-patches]

Now fully tested, ok to commit ?


On 07/05/20 9:12 am, François Dumont wrote:
    This patch purpose is to make sure that existing 
std::copy/std::copy_n overloads for char* will also be used for 
std::deque iterators when dealing with istreambuf_iterator. It 
also make sure that it still works when _GLIBCXX_DEBUG is activated.


    * include/bits/stl_algo.h (__copy_n_a): Move ...
    * include/bits/stl_algobase.h (__copy_n_a): ...here. Add __strict
    parameter.
    (__niter_base(const _Safe_iterator<_Ite, _Seq,
    random_access_iterator_tag>&)): New declaration.
    (__copy_move_a2(istreambuf_iterator<>, istreambuf_iterator<>,
    _Deque_iterator<>)): New declaration.
    (__copy_n_a(istreambuf_iterator<>, _Size, _Deque_iterator<>, bool)):
    New declaration.
    * include/bits/deque.tcc
    (__copy_move_a2(istreambuf_iterator<>, istreambuf_iterator<>,
    _Deque_iterator<>)): Add definition.
    (__copy_n_a(istreambuf_iterator<>, _Size, _Deque_iterator<>, bool)):
    Add definition.
    * include/bits/streambuf_iterator.h
    (__copy_n_a(istreambuf_iterator<>, _Size, _CharT*, bool)): Adapt
    definition.
    * include/debug/safe_iterator.tcc (__niter_base): Add definition.
    * testsuite/25_algorithms/copy/streambuf_iterators/char/4.cc 
(test03):

    New.
    * testsuite/25_algorithms/copy/streambuf_iterators/char/debug/
    deque_neg.cc: New.
    * testsuite/25_algorithms/copy_n/debug/istreambuf_ite_deque_neg.cc:
    New.
    * testsuite/25_algorithms/copy_n/istreambuf_iterator/2.cc: New.
    * testsuite/25_algorithms/copy_n/istreambuf_iterator/deque.cc: New.

Already tested for a while on Linux x64 normal and debug modes but I 
am currently rebuilding everything and will commit only once all 
succeeded again.


Ok ?

François

[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.

Re: dejagnu version update?

[Jacob Bachmeyer via Gcc]

Rob Savoye wrote:

On 5/14/20 10:08 AM, David Edelsohn wrote:
  

Have you approached the Linux Foundation Core Infrastructure
Initiative for funding for both DejaGNU maintenance (patch backlog)
and refactoring DejaGNU in Python efforts?



  Not that team, the folks I talked to thought I was crazy for wanting
to refactor it. :-) That's been the usual answer from anyone. I even
talked about this at GNU Tools Cauldron once. Seriously though, it'd be
great to analyze the current code base, write an actual design document,
clean internal APIs, and build something we can use for another 30
years.
This is very close to the volunteer work I have been doing on DejaGNU:  
just documenting the existing API would be a major step forwards, with 
follow-up plans to slowly move DejaGNU to more modern Tcl.  Using modern 
Tcl features, like namespaces (introduced in Tcl 8.0) and slave 
interpreters (introduced in Tcl 7.6) would enable significant clean up 
and possibly even simultaneous support for multiple testsuite API 
versions, allowing even backwards-incompatible changes by preserving 
support for the old API and requiring the new API to be requested.



 I'd start by writing a solid expect module for Python, and then
embedding Tcl in Python as a comparability layer. I understand it'd be a
huge project, which is why I haven't done this as a volunteer.
  

Amusingly, I believe both of those may already be in CPAN for Perl 5.  :-)

-- Jacob

[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.)

Re: dejagnu version update?

[Rob Savoye]

On 5/14/20 5:34 PM, Maciej W. Rozycki wrote:

> And then current development appears ongoing, ferociously indeed, with the 
> last check in literally today (barring my time zone), as indicated here: 
> .

  It's obvious I haven't been paying attention, so much for my
retirement... :-)  That's awesome actually, and it does look active.

>  Other than that what would be the technical advantage from rewriting 
> DejaGnu in Python (/me asking as a Python ignoramus)?

  The main thought was more towards an actual design and clean APIs, and
assuming Tcl/Expect was unmaintained, needed to use something that'll be
around for a few more decades. Assuming Tcl/Expect are maintained
forever, that's a bit of a moot point. Everybody has always complained
about using Tcl in DejaGnu. Python is just much more commonly used in
the current century.

  Right now working through patches is probably more important. :-)
There's zero patches on the DejaGnu savannah site, so I'd ask anybody to
submit them so I don't have to dig them out of email archives.

- rob -

[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: dejagnu version update?

[Maciej W. Rozycki via Gcc]

On Thu, 14 May 2020, Rob Savoye wrote:

>   Personally, I tried to find funding to refactor DejaGnu in Python,
> since Tcl is unmaintained too, but nobody was interested.

 Thank you for your contribution to DejaGnu over the years and for your 
input on this occasion.

 However it does not appear to me to be right that Tcl is not maintained, 
as a stable 8.6.10 release has been made as recently as half a year ago. 
And then current development appears ongoing, ferociously indeed, with the 
last check in literally today (barring my time zone), as indicated here: 
.

 Other than that what would be the technical advantage from rewriting 
DejaGnu in Python (/me asking as a Python ignoramus)?

  Maciej

Re: [PATCH] Skip jit tests for targets that don't support -lgccjit

[H.J. Lu via Gcc-patches]

On Thu, May 14, 2020 at 1:42 PM Jeff Law  wrote:
>
> On Fri, 2020-05-08 at 12:12 -0700, H.J. Lu via Gcc-patches wrote:
> > Since libgccjit.so is linked into jit tests, skip jit tests for targets
> > that don't support -lgccjit.
> >
> > OK for master?
> >
> > H.J.
> > ---
> >   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.
> I believe the new dejagnu tests needs to be documented in sourcebuild.texi.
>
> OK with the sourcebuild.texi changes included.
>

This is the patch I am checking in.

Thanks.

-- 
H.J.
From 0162e4ffaa40a1a879abf5e59671b80790df17eb Mon Sep 17 00:00:00 2001
From: "H.J. Lu" 
Date: Fri, 8 May 2020 12:09:11 -0700
Subject: [PATCH] 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.
---
 gcc/doc/sourcebuild.texi  |  3 +++
 gcc/testsuite/jit.dg/jit.exp  |  5 +
 gcc/testsuite/lib/target-supports.exp | 15 +++
 3 files changed, 23 insertions(+)

diff --git a/gcc/doc/sourcebuild.texi b/gcc/doc/sourcebuild.texi
index 240d6e4b08e..0f70e4baca9 100644
--- a/gcc/doc/sourcebuild.texi
+++ b/gcc/doc/sourcebuild.texi
@@ -2494,6 +2494,9 @@ Target uses comdat groups.
 @item indirect_calls
 Target supports indirect calls, i.e. calls where the target is not
 constant.
+
+@item lgccjit
+Target supports -lgccjit, i.e. libgccjit.so can be linked into jit tests.
 @end table
 
 @subsubsection Local to tests in @code{gcc.target/i386}
diff --git a/gcc/testsuite/jit.dg/jit.exp b/gcc/testsuite/jit.dg/jit.exp
index 13e8ab4dbfe..2f54681713b 100644
--- a/gcc/testsuite/jit.dg/jit.exp
+++ b/gcc/testsuite/jit.dg/jit.exp
@@ -38,6 +38,11 @@ load_lib gcc.exp
 load_lib g++.exp
 load_lib dejagnu.exp
 
+# Skip these tests for targets that don't support -lgccjit
+if { ![check_effective_target_lgccjit] } {
+return
+}
+
 # Look for lines of the form:
 #   definitely lost: 11,316 bytes in 235 blocks
 #   indirectly lost: 352 bytes in 4 blocks
diff --git a/gcc/testsuite/lib/target-supports.exp b/gcc/testsuite/lib/target-supports.exp
index 88f4a9cd812..3e91a81dd5a 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -10234,3 +10234,18 @@ proc check_effective_target_indirect_calls { } {
   }
   return 1
 }
+
+# Return 1 if we can use the -lgccjit option, 0 otherwise.
+
+proc check_effective_target_lgccjit { } {
+  if { [info procs jit_target_compile] == "" } then {
+global GCC_UNDER_TEST
+if ![info exists GCC_UNDER_TEST] {
+  set GCC_UNDER_TEST "[find_gcc]"
+}
+proc jit_target_compile { source dest type options } [info body gcc_target_compile]
+  }
+  return [check_no_compiler_messages lgccjit executable {
+ int main() { return 0; }
+  } "-lgccjit"]
+}
-- 
2.26.2

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

[PATCH] x86: Add -mavoid-libcall for -mgeneral-regs-only

[H.J. Lu via Gcc-patches]

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.

Tested on Linux/x86 and Linux/x86-64.  OK for master?

Thanks.

H.J.
---
gcc/

PR target/95134
* config/i386/i386-expand.c (alg_usable_p): Return false for
libcall with -mavoid-libcall.
(decide_alg): Avoid libcall and rep_prefix_1_byte instead of
libcall with -mavoid-libcall.
* config/i386/i386.opt: Add -mavoid-libcall.
* doc/invoke.texi: Document -mavoid-libcall.

gcc/testsuite/

PR target/95134
* gcc.target/i386/pr95134-1.c: New test.
* gcc.target/i386/pr95134-2.c: Likewise.
* gcc.target/i386/pr95134-3.c: Likewise.
* gcc.target/i386/pr95134-4.c: Likewise.
---
 gcc/config/i386/i386-expand.c | 15 ++-
 gcc/config/i386/i386.opt  |  6 +-
 gcc/doc/invoke.texi   | 10 +-
 gcc/testsuite/gcc.target/i386/pr95134-1.c | 18 ++
 gcc/testsuite/gcc.target/i386/pr95134-2.c | 18 ++
 gcc/testsuite/gcc.target/i386/pr95134-3.c | 18 ++
 gcc/testsuite/gcc.target/i386/pr95134-4.c | 11 +++
 7 files changed, 89 insertions(+), 7 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/i386/pr95134-1.c
 create mode 100644 gcc/testsuite/gcc.target/i386/pr95134-2.c
 create mode 100644 gcc/testsuite/gcc.target/i386/pr95134-3.c
 create mode 100644 gcc/testsuite/gcc.target/i386/pr95134-4.c

diff --git a/gcc/config/i386/i386-expand.c b/gcc/config/i386/i386-expand.c
index 26531585c5f..b38463bf88c 100644
--- a/gcc/config/i386/i386-expand.c
+++ b/gcc/config/i386/i386-expand.c
@@ -6816,7 +6816,7 @@ alg_usable_p (enum stringop_alg alg, bool memset, bool 
have_as)
  || (memset ? fixed_regs[AX_REG] : fixed_regs[SI_REG]))
return false;
 }
-  return true;
+  return !flag_avoid_libcall || alg != libcall;
 }
 
 /* Given COUNT and EXPECTED_SIZE, decide on codegen of string operation.  */
@@ -6889,7 +6889,7 @@ decide_alg (HOST_WIDE_INT count, HOST_WIDE_INT 
expected_size,
  setup.  */
   else if (expected_size != -1 && expected_size < 4)
 return loop_1_byte;
-  else if (expected_size != -1)
+  else if (expected_size != -1 && !flag_avoid_libcall)
 {
   enum stringop_alg alg = libcall;
   bool alg_noalign = false;
@@ -6934,6 +6934,9 @@ decide_alg (HOST_WIDE_INT count, HOST_WIDE_INT 
expected_size,
}
}
 }
+
+  enum stringop_alg alg;
+
   /* When asked to inline the call anyway, try to pick meaningful choice.
  We look for maximal size of block that is faster to copy by hand and
  take blocks of at most of that size guessing that average size will
@@ -6945,7 +6948,6 @@ decide_alg (HOST_WIDE_INT count, HOST_WIDE_INT 
expected_size,
   && (algs->unknown_size == libcall
  || !alg_usable_p (algs->unknown_size, memset, have_as)))
 {
-  enum stringop_alg alg;
   HOST_WIDE_INT new_expected_size = (max > 0 ? max : 4096) / 2;
 
   /* If there aren't any usable algorithms or if recursing already,
@@ -6967,8 +6969,11 @@ decide_alg (HOST_WIDE_INT count, HOST_WIDE_INT 
expected_size,
gcc_assert (alg != libcall);
   return alg;
 }
-  return (alg_usable_p (algs->unknown_size, memset, have_as)
- ? algs->unknown_size : libcall);
+  alg = (alg_usable_p (algs->unknown_size, memset, have_as)
+? algs->unknown_size : libcall);
+  if (flag_avoid_libcall && alg == libcall)
+alg = rep_prefix_1_byte;
+  return alg;
 }
 
 /* Decide on alignment.  We know that the operand is already aligned to ALIGN
diff --git a/gcc/config/i386/i386.opt b/gcc/config/i386/i386.opt
index c9f7195d423..23b401bd424 100644
--- a/gcc/config/i386/i386.opt
+++ b/gcc/config/i386/i386.opt
@@ -1114,4 +1114,8 @@ Support SERIALIZE built-in functions and code generation.
 
 mtsxldtrk
 Target Report Mask(ISA2_TSXLDTRK) Var(ix86_isa_flags2) Save
-Support TSXLDTRK built-in functions and code generation.
\ No newline at end of file
+Support TSXLDTRK built-in functions and code generation.
+
+mavoid-libcall
+Target Report Var(flag_avoid_libcall) Init(0)
+Avoid generation of libcall.
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 850aeac033d..0d2d70419d5 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -1364,7 +1364,7 @@ See RS/6000 and PowerPC Options.
 -mstack-protector-guard-reg=@var{reg} @gol
 -mstack-protector-guard-offset=@var{offset} 

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

gcc-8-20200514 is now available

[GCC Administrator via Gcc]

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

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

You'll find:

 gcc-8-20200514.tar.xzComplete GCC

  SHA256=93597d10dd9799b299e25a61f1a4858df5a4d29b02e6b367e9bda44b4045d62d
  SHA1=39a51ce7ba167ea30054bca0efa8257cc4154edc

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

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

[Bug 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.

Re: [PATCH RFC] bootstrap: Update requirement to C++11.

[Jakub Jelinek via Gcc-patches]

On Thu, May 14, 2020 at 05:05:59PM -0400, Jason Merrill via Gcc-patches wrote:
> +Versions of GCC prior to 11 also allow bootstrapping with an ISO C++98
> +compiler, versions of GCC prior to 4.8 also allow bootstrapping with a
> +ISO C89 compiler, and versions of GCC prior to 3.4 also allow
> +bootstrapping with a traditional (K) C compiler.
>  
>  To build all languages in a cross-compiler or other configuration where
>  3-stage bootstrap is not performed, you need to start with an existing
> -GCC binary (version 3.4 or later) because source code for language
> +GCC binary (version 4.8 or later) because source code for language
>  frontends other than C might use GCC extensions.
>  
>  Note that to bootstrap GCC with versions of GCC earlier than 3.4, you

Probably this paragraph needs adjustments too.

Jakub

[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.

[PATCH RFC] bootstrap: Update requirement to C++11.

[Jason Merrill via Gcc-patches]

There seemed to be general agreement last November that we would move to
allowing C++11 features to be used in GCC 11; this patch implements that
direction.  Are changes needed anywhere else?

ChangeLog
2020-05-14  Jason Merrill  

* configure.ac: Update bootstrap dialect to -std=gnu++11.

gcc/ChangeLog
2020-05-14  Jason Merrill  

* doc/install.texi (Prerequisites): Update boostrap compiler
requirement to C++11/GCC 4.8.
---
 gcc/doc/install.texi | 14 --
 configure.ac |  6 +++---
 ChangeLog|  4 
 configure|  6 +++---
 4 files changed, 18 insertions(+), 12 deletions(-)

diff --git a/gcc/doc/install.texi b/gcc/doc/install.texi
index 876b04f9c45..f47e3c76f73 100644
--- a/gcc/doc/install.texi
+++ b/gcc/doc/install.texi
@@ -238,15 +238,17 @@ described below.
 
 @heading Tools/packages necessary for building GCC
 @table @asis
-@item ISO C++98 compiler
-Necessary to bootstrap GCC, although versions of GCC prior
-to 4.8 also allow bootstrapping with a ISO C89 compiler and versions
-of GCC prior to 3.4 also allow bootstrapping with a traditional
-(K) C compiler.
+@item ISO C++11 compiler
+Necessary to bootstrap GCC.
+
+Versions of GCC prior to 11 also allow bootstrapping with an ISO C++98
+compiler, versions of GCC prior to 4.8 also allow bootstrapping with a
+ISO C89 compiler, and versions of GCC prior to 3.4 also allow
+bootstrapping with a traditional (K) C compiler.
 
 To build all languages in a cross-compiler or other configuration where
 3-stage bootstrap is not performed, you need to start with an existing
-GCC binary (version 3.4 or later) because source code for language
+GCC binary (version 4.8 or later) because source code for language
 frontends other than C might use GCC extensions.
 
 Note that to bootstrap GCC with versions of GCC earlier than 3.4, you
diff --git a/configure.ac b/configure.ac
index c78d9cbea62..63d92b73061 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1462,10 +1462,10 @@ case "$have_compiler:$host:$target:$enable_bootstrap" in
 ;;
 esac
 
-# When bootstrapping with GCC, build stage 1 in C++98 mode to ensure that a
-# C++98 compiler can still start the bootstrap.
+# When bootstrapping with GCC, build stage 1 in C++11 mode to ensure that a
+# C++11 compiler can still start the bootstrap.
 if test "$enable_bootstrap:$GXX" = "yes:yes"; then
-  CXX="$CXX -std=gnu++98"
+  CXX="$CXX -std=gnu++11"
 fi
 
 # Used for setting $lt_cv_objdir
diff --git a/ChangeLog b/ChangeLog
index a7fcf77b9b2..1d281855a3e 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,7 @@
+2020-05-14  Jason Merrill  
+
+   * configure.ac: Update bootstrap dialect to -std=gnu++11.
+
 2020-04-29  Thomas Schwinge  
 
PR target/92713
diff --git a/configure b/configure
index 4cc938ebb7d..9b39035bbcc 100755
--- a/configure
+++ b/configure
@@ -5523,10 +5523,10 @@ $as_echo "$as_me: WARNING: trying to bootstrap a cross 
compiler" >&2;}
 ;;
 esac
 
-# When bootstrapping with GCC, build stage 1 in C++98 mode to ensure that a
-# C++98 compiler can still start the bootstrap.
+# When bootstrapping with GCC, build stage 1 in C++11 mode to ensure that a
+# C++11 compiler can still start the bootstrap.
 if test "$enable_bootstrap:$GXX" = "yes:yes"; then
-  CXX="$CXX -std=gnu++98"
+  CXX="$CXX -std=gnu++11"
 fi
 
 # Used for setting $lt_cv_objdir

base-commit: 4e1592f8e1d6366699e05c0824fc3dc39ca7314b
-- 
2.18.1

[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.

Re: [PATCH] c++: Enable coroutines with -std=c++20.

[Iain Sandoe]

Jason Merrill via Gcc-patches  wrote:


Now that GCC 10 is out it seems time.  People can still choose to disable
coroutines with -fno-coroutines.


There’s one pass that has to run for all functions, the remainder of the work
is gated on the function being a coroutine.

If there’s a hit found from that one pass, we can think about solutions.
[The issue is that any (non-coro) function could, potentially, contain a
__builtin_coro_x, so there’s no way to gate the scan to lower those
once -fcoroutines is on].


This also switches the coroutines testsuite to run in C++20 mode.


I’m not sure if there’s benefit to doing some testing with C++17 (or even 14)
the idea was not to bake anything in that precluded coros working for 14+
However, the suite does take time, so it would probably be the wrong thing to
make it run for all three.


 The
change to coro.h is needed for co-await-11-forwarding.C; we could
alternatively #include  just in that file.


let’s see if there’s a significant hit on the test-time we can always move it
if so.


Iain, does this make sense to you?


yes, we just ran out of time before 10.1.

thanks for doing this, it was kinda on my list but lower than bug-fixing ;)
Iain



gcc/c-family/ChangeLog
2020-05-14  Jason Merrill  

* c-opts.c (set_std_cxx20): Set flag_coroutines.

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

* g++.dg/coroutines/coro.h: Always #include .
* g++.dg/coroutines/coroutines.exp (DEFAULT_COROFLAGS): Use
-std=c++20.
---
gcc/testsuite/g++.dg/coroutines/coro.h | 10 ++
gcc/c-family/c-opts.c  |  7 ---
gcc/testsuite/g++.dg/coroutines/coroutines.exp |  2 +-
3 files changed, 7 insertions(+), 12 deletions(-)

diff --git a/gcc/testsuite/g++.dg/coroutines/coro.h  
b/gcc/testsuite/g++.dg/coroutines/coro.h

index fccfe418616..02d26602727 100644
--- a/gcc/testsuite/g++.dg/coroutines/coro.h
+++ b/gcc/testsuite/g++.dg/coroutines/coro.h
@@ -2,20 +2,12 @@

#include 

-#  if __clang__
-#include 
-#  endif
-
namespace coro = std;

#elif __has_include()

#include 

-#  if __clang__
-#include 
-#  endif
-
namespace coro = std::experimental;

#else
@@ -143,6 +135,8 @@ extern "C" int printf (const char *, ...);

#include  /* for abort () */

+#include  /* for std::forward */
+
#ifndef OUTPUT
#  define PRINT(X)
#  define PRINTF (void)
diff --git a/gcc/c-family/c-opts.c b/gcc/c-family/c-opts.c
index bd617d3df18..7695e88c130 100644
--- a/gcc/c-family/c-opts.c
+++ b/gcc/c-family/c-opts.c
@@ -1722,7 +1722,7 @@ set_std_cxx17 (int iso)
  lang_hooks.name = "GNU C++17";
}

-/* Set the C++ 202a draft standard (without GNU extensions if ISO).  */
+/* Set the C++ 2020 standard (without GNU extensions if ISO).  */
static void
set_std_cxx20 (int iso)
{
@@ -1734,9 +1734,10 @@ set_std_cxx20 (int iso)
  flag_isoc94 = 1;
  flag_isoc99 = 1;
  flag_isoc11 = 1;
-  /* C++20 includes concepts. */
+  /* C++20 includes coroutines. */
+  flag_coroutines = true;
  cxx_dialect = cxx20;
-  lang_hooks.name = "GNU C++17"; /* Pretend C++17 until  
standardization.  */

+  lang_hooks.name = "GNU C++20";
}

/* Args to -d specify what to dump.  Silently ignore
diff --git a/gcc/testsuite/g++.dg/coroutines/coroutines.exp  
b/gcc/testsuite/g++.dg/coroutines/coroutines.exp

index e7fd4dac461..1bef98ae54d 100644
--- a/gcc/testsuite/g++.dg/coroutines/coroutines.exp
+++ b/gcc/testsuite/g++.dg/coroutines/coroutines.exp
@@ -29,7 +29,7 @@ if ![info exists DEFAULT_CXXFLAGS] then {
}

set DEFAULT_COROFLAGS $DEFAULT_CXXFLAGS
-lappend DEFAULT_COROFLAGS "-std=c++17" "-fcoroutines"
+lappend DEFAULT_COROFLAGS "-std=c++20"

dg-init


base-commit: 4e1592f8e1d6366699e05c0824fc3dc39ca7314b
--
2.18.1

[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

Re: [PATCH] Skip jit tests for targets that don't support -lgccjit

[Jeff Law via Gcc-patches]

On Fri, 2020-05-08 at 12:12 -0700, H.J. Lu via Gcc-patches wrote:
> Since libgccjit.so is linked into jit tests, skip jit tests for targets
> that don't support -lgccjit.
> 
> OK for master?
> 
> H.J.
> ---
>   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.
I believe the new dejagnu tests needs to be documented in sourcebuild.texi.

OK with the sourcebuild.texi changes included.

jeff

[PATCH] c++: Enable coroutines with -std=c++20.

[Jason Merrill via Gcc-patches]

Now that GCC 10 is out it seems time.  People can still choose to disable
coroutines with -fno-coroutines.

This also switches the coroutines testsuite to run in C++20 mode.  The
change to coro.h is needed for co-await-11-forwarding.C; we could
alternatively #include  just in that file.

Iain, does this make sense to you?

gcc/c-family/ChangeLog
2020-05-14  Jason Merrill  

* c-opts.c (set_std_cxx20): Set flag_coroutines.

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

* g++.dg/coroutines/coro.h: Always #include .
* g++.dg/coroutines/coroutines.exp (DEFAULT_COROFLAGS): Use
-std=c++20.
---
 gcc/testsuite/g++.dg/coroutines/coro.h | 10 ++
 gcc/c-family/c-opts.c  |  7 ---
 gcc/testsuite/g++.dg/coroutines/coroutines.exp |  2 +-
 3 files changed, 7 insertions(+), 12 deletions(-)

diff --git a/gcc/testsuite/g++.dg/coroutines/coro.h 
b/gcc/testsuite/g++.dg/coroutines/coro.h
index fccfe418616..02d26602727 100644
--- a/gcc/testsuite/g++.dg/coroutines/coro.h
+++ b/gcc/testsuite/g++.dg/coroutines/coro.h
@@ -2,20 +2,12 @@
 
 #include 
 
-#  if __clang__
-#include 
-#  endif
-
 namespace coro = std;
 
 #elif __has_include()
 
 #include 
 
-#  if __clang__
-#include 
-#  endif
-
 namespace coro = std::experimental;
 
 #else
@@ -143,6 +135,8 @@ extern "C" int printf (const char *, ...);
 
 #include  /* for abort () */
 
+#include  /* for std::forward */
+
 #ifndef OUTPUT
 #  define PRINT(X)
 #  define PRINTF (void)
diff --git a/gcc/c-family/c-opts.c b/gcc/c-family/c-opts.c
index bd617d3df18..7695e88c130 100644
--- a/gcc/c-family/c-opts.c
+++ b/gcc/c-family/c-opts.c
@@ -1722,7 +1722,7 @@ set_std_cxx17 (int iso)
   lang_hooks.name = "GNU C++17";
 }
 
-/* Set the C++ 202a draft standard (without GNU extensions if ISO).  */
+/* Set the C++ 2020 standard (without GNU extensions if ISO).  */
 static void
 set_std_cxx20 (int iso)
 {
@@ -1734,9 +1734,10 @@ set_std_cxx20 (int iso)
   flag_isoc94 = 1;
   flag_isoc99 = 1;
   flag_isoc11 = 1;
-  /* C++20 includes concepts. */
+  /* C++20 includes coroutines. */
+  flag_coroutines = true;
   cxx_dialect = cxx20;
-  lang_hooks.name = "GNU C++17"; /* Pretend C++17 until standardization.  */
+  lang_hooks.name = "GNU C++20";
 }
 
 /* Args to -d specify what to dump.  Silently ignore
diff --git a/gcc/testsuite/g++.dg/coroutines/coroutines.exp 
b/gcc/testsuite/g++.dg/coroutines/coroutines.exp
index e7fd4dac461..1bef98ae54d 100644
--- a/gcc/testsuite/g++.dg/coroutines/coroutines.exp
+++ b/gcc/testsuite/g++.dg/coroutines/coroutines.exp
@@ -29,7 +29,7 @@ if ![info exists DEFAULT_CXXFLAGS] then {
 }
 
 set DEFAULT_COROFLAGS $DEFAULT_CXXFLAGS
-lappend DEFAULT_COROFLAGS "-std=c++17" "-fcoroutines"
+lappend DEFAULT_COROFLAGS "-std=c++20"
 
 dg-init
 

base-commit: 4e1592f8e1d6366699e05c0824fc3dc39ca7314b
-- 
2.18.1

[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.

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

[Jason Merrill via Gcc-patches]

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.

Tested x86_64-pc-linux-gnu, applying to trunk.

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

PR c++/93901
* pt.c (maybe_instantiate_noexcept): Change clone handling.
---
 gcc/cp/pt.c | 55 ++---
 1 file changed, 27 insertions(+), 28 deletions(-)

diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 61e6fa7484d..2a0b18f5517 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -25174,7 +25174,7 @@ always_instantiate_p (tree decl)
 bool
 maybe_instantiate_noexcept (tree fn, tsubst_flags_t complain)
 {
-  tree fntype, spec, noex, clone;
+  tree fntype, spec, noex;
 
   /* Don't instantiate a noexcept-specification from template context.  */
   if (processing_template_decl
@@ -25193,8 +25193,16 @@ maybe_instantiate_noexcept (tree fn, tsubst_flags_t 
complain)
   return !DECL_MAYBE_DELETED (fn);
 }
 
-  if (DECL_CLONED_FUNCTION_P (fn))
-fn = DECL_CLONED_FUNCTION (fn);
+  fntype = TREE_TYPE (fn);
+  spec = TYPE_RAISES_EXCEPTIONS (fntype);
+
+  if (!spec || !TREE_PURPOSE (spec))
+return true;
+
+  noex = TREE_PURPOSE (spec);
+  if (TREE_CODE (noex) != DEFERRED_NOEXCEPT
+  && TREE_CODE (noex) != DEFERRED_PARSE)
+return true;
 
   tree orig_fn = NULL_TREE;
   /* For a member friend template we can get a TEMPLATE_DECL.  Let's use
@@ -25206,15 +25214,14 @@ maybe_instantiate_noexcept (tree fn, tsubst_flags_t 
complain)
   fn = DECL_TEMPLATE_RESULT (fn);
 }
 
-  fntype = TREE_TYPE (fn);
-  spec = TYPE_RAISES_EXCEPTIONS (fntype);
-
-  if (!spec || !TREE_PURPOSE (spec))
-return true;
-
-  noex = TREE_PURPOSE (spec);
-
-  if (TREE_CODE (noex) == DEFERRED_NOEXCEPT)
+  if (DECL_CLONED_FUNCTION_P (fn))
+{
+  tree prime = DECL_CLONED_FUNCTION (fn);
+  if (!maybe_instantiate_noexcept (prime, complain))
+   return false;
+  spec = TYPE_RAISES_EXCEPTIONS (TREE_TYPE (prime));
+}
+  else if (TREE_CODE (noex) == DEFERRED_NOEXCEPT)
 {
   static hash_set* fns = new hash_set;
   bool added = false;
@@ -25284,27 +25291,19 @@ maybe_instantiate_noexcept (tree fn, tsubst_flags_t 
complain)
 
   if (added)
fns->remove (fn);
-
-  if (spec == error_mark_node)
-   {
- /* This failed with a hard error, so let's go with false.  */
- gcc_assert (seen_error ());
- spec = noexcept_false_spec;
-   }
-
-  TREE_TYPE (fn) = build_exception_variant (fntype, spec);
-  if (orig_fn)
-   TREE_TYPE (orig_fn) = TREE_TYPE (fn);
 }
 
-  FOR_EACH_CLONE (clone, fn)
+  if (spec == error_mark_node)
 {
-  if (TREE_TYPE (clone) == fntype)
-   TREE_TYPE (clone) = TREE_TYPE (fn);
-  else
-   TREE_TYPE (clone) = build_exception_variant (TREE_TYPE (clone), spec);
+  /* This failed with a hard error, so let's go with false.  */
+  gcc_assert (seen_error ());
+  spec = noexcept_false_spec;
 }
 
+  TREE_TYPE (fn) = build_exception_variant (fntype, spec);
+  if (orig_fn)
+TREE_TYPE (orig_fn) = TREE_TYPE (fn);
+
   return true;
 }
 

base-commit: 3a36428b5fbc825e2d3455f5770b5d6e71c63413
-- 
2.18.1

[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

Re: libgo patch committed: Build syscall test with -static

[Ian Lance Taylor via Gcc-patches]

On Thu, May 14, 2020 at 12:43 PM Rainer Orth
 wrote:
>
> > This libgo patch builds the syscall test with -static.  This avoids
> > problems finding libgo.so when running the test as root, which invokes
> > the test as a child process in various limited environments.  This
> > fixes GCC PR 95061.  Bootstrapped and ran Go tests on
> > x86_64-pc-linux-gnu.  Committed to mainline.
>
> this patch broke the syscall test on Solaris:
>
> ld: fatal: library -lpthread: not found
> ld: fatal: library -lm: not found
> ld: fatal: library -lc: not found
> ld: fatal: library -lc: not found
> collect2: error: ld returned 1 exit status
> FAIL: syscall
>
> There are no static versions of system libraries.

Sorry about that.  The issue only arises on GNU/Linux, so committed
this patch after testing to at least fix the problem on Solaris.

Ian
49f993428fa6bc5921a473d4476db81698147519
diff --git a/gcc/go/gofrontend/MERGE b/gcc/go/gofrontend/MERGE
index b63bb3bd547..4776f78e5fa 100644
--- a/gcc/go/gofrontend/MERGE
+++ b/gcc/go/gofrontend/MERGE
@@ -1,4 +1,4 @@
-93b3d88515db85e203d54f382200b84b56b0ae4c
+cae8d4c388d4cc701c7f8fc221c9f6431760d93a
 
 The first line of this file holds the git revision number of the last
 merge done from the gofrontend repository.
diff --git a/libgo/Makefile.am b/libgo/Makefile.am
index eff0e00e787..0bbe54cfe1b 100644
--- a/libgo/Makefile.am
+++ b/libgo/Makefile.am
@@ -967,9 +967,11 @@ endif
 # Also use -fno-inline to get better results from the memory profiler.
 runtime_pprof_check_GOCFLAGS = -static-libgo -fno-inline
 
+if LIBGO_IS_LINUX
 # Use -static for the syscall tests, because otherwise when
 # running as root the re-execs ignore LD_LIBRARY_PATH.
 syscall_check_GOCFLAGS = -static
+endif
 
 extra_go_files_runtime_internal_sys = version.go
 runtime/internal/sys.lo.dep: $(extra_go_files_runtime_internal_sys)

[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.

[PATCH] c++: decltype of invalid non-dependent expr [PR57943]

[Patrick Palka via Gcc-patches]

We sometimes fail to reject a invalid non-dependent operand to decltype
when inside a template, because finish_decltype_type resolves the
decltype to the TREE_TYPE of the operand before we ever instantiate and
fully process the operand.  Fix this by adding a call to
instantiate_non_dependent_expr_sfinae in finish_decltype_type.

Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK to
commit?

gcc/cp/ChangeLog:

PR c++/57943
* semantics.c (finish_decltype_type): Call
instantiate_non_dependent_expr_sfinae on the decltype's operand.

gcc/testsuite/ChangeLog:

PR c++/57943
* g++.dg/cpp0x/decltype76.C: New test.
---
 gcc/cp/semantics.c  | 8 
 gcc/testsuite/g++.dg/cpp0x/decltype76.C | 7 +++
 2 files changed, 15 insertions(+)
 create mode 100644 gcc/testsuite/g++.dg/cpp0x/decltype76.C

diff --git a/gcc/cp/semantics.c b/gcc/cp/semantics.c
index d90816eabc9..64587c791c6 100644
--- a/gcc/cp/semantics.c
+++ b/gcc/cp/semantics.c
@@ -9746,6 +9746,14 @@ finish_decltype_type (tree expr, bool 
id_expression_or_member_access_p,
 
   return type;
 }
+  else if (processing_template_decl)
+{
+  ++cp_unevaluated_operand;
+  expr = instantiate_non_dependent_expr_sfinae (expr, complain);
+  --cp_unevaluated_operand;
+  if (expr == error_mark_node)
+   return error_mark_node;
+}
 
   /* The type denoted by decltype(e) is defined as follows:  */
 
diff --git a/gcc/testsuite/g++.dg/cpp0x/decltype76.C 
b/gcc/testsuite/g++.dg/cpp0x/decltype76.C
new file mode 100644
index 000..239fe6d2a8f
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/decltype76.C
@@ -0,0 +1,7 @@
+// PR c+/57943
+// { dg-do compile { target c++11 } }
+
+struct a { };
+
+template  // { dg-error "" }
+void f() { }
-- 
2.26.2.626.g172e8ff696

[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)

[committed] amdgcn: fix vcc clobber in vector load/store

[Andrew Stubbs]

This fixes a wrong-code error that could occur when a vector reload was 
inserted between a vector compare and conditional branch.


The problem was that expanding the vector base address to the vector of 
addresses needed by the ISA would clobber the VCC register. This fine 
before LRA, but not good after.


The fix clobbers CC_SAVE_REG instead, which is never long-lived.

Andrew
amdgcn: fix vcc clobber in vector load/store

This switches the code that expands scalar addresses to vectors of addresses
from using VCC to using CC_SAVE_REG, for the lo-part to hi-part carry values.
These were fine in code expanded in earlier passes, but addresses expanded
late, such as for stack spills or reloads, could clobber live VCC values,
causing execution failures.

This is the first target-specific testcase for GCN, so the new .exp file is
included.

2020-05-14  Andrew Stubbs  

	gcc/
	* config/gcn/gcn-valu.md (add3_zext_dup): Change to a
	define_expand, and rename the original to ...
	(add3_vcc_zext_dup): ... this, and add a custom VCC operand.
	(add3_zext_dup_exec): Likewise, with ...
	(add3_vcc_zext_dup_exec): ... this.
	(add3_zext_dup2): Likewise, with ...
	(add3_zext_dup_exec): ... this.
	(add3_zext_dup2_exec): Likewise, with ...
	(add3_zext_dup2): ... this.
	* config/gcn/gcn.c (gcn_expand_scalar_to_vector_address): Switch
	addv64di3_zext* calls to use addv64di3_vcc_zext*.

	gcc/testsuite/
	* testsuite/gcc.target/gcn/gcn.exp: New file.
	* testsuite/gcc.target/gcn/vcc-clobber.c: New file.

diff --git a/gcc/config/gcn/gcn-valu.md b/gcc/config/gcn/gcn-valu.md
index d3badb4059c..a43d6b6c6f3 100644
--- a/gcc/config/gcn/gcn-valu.md
+++ b/gcc/config/gcn/gcn-valu.md
@@ -1379,135 +1379,206 @@
   [(set_attr "type" "vmult")
(set_attr "length" "8")])
 
-(define_insn_and_split "add3_zext_dup"
-  [(set (match_operand:V_DI 0 "register_operand""= v,  v")
+(define_insn_and_split "add3_vcc_zext_dup"
+  [(set (match_operand:V_DI 0 "register_operand""=   v,   v")
 	(plus:V_DI
 	  (zero_extend:V_DI
 	(vec_duplicate:
-	  (match_operand:SI 1 "gcn_alu_operand" "BSv,ASv")))
-	  (match_operand:V_DI 2 "gcn_alu_operand"   "vDA,vDb")))
-   (clobber (reg:DI VCC_REG))]
+	  (match_operand:SI 1 "gcn_alu_operand" "  BSv, ASv")))
+	  (match_operand:V_DI 2 "gcn_alu_operand"   "  vDA, vDb")))
+   (set (match_operand:DI 3 "register_operand"	"=SgcV,SgcV")
+	(ltu:DI (plus:V_DI 
+		  (zero_extend:V_DI (vec_duplicate: (match_dup 1)))
+		  (match_dup 2))
+		(match_dup 1)))]
   ""
   "#"
   "gcn_can_split_p  (mode, operands[0])
&& gcn_can_split_p (mode, operands[2])"
   [(const_int 0)]
   {
-rtx vcc = gen_rtx_REG (DImode, VCC_REG);
 emit_insn (gen_add3_vcc_dup
 		(gcn_operand_part (mode, operands[0], 0),
 		 gcn_operand_part (DImode, operands[1], 0),
 		 gcn_operand_part (mode, operands[2], 0),
-		 vcc));
+		 operands[3]));
 emit_insn (gen_addc3
 		(gcn_operand_part (mode, operands[0], 1),
 		 gcn_operand_part (mode, operands[2], 1),
-		 const0_rtx, vcc, vcc));
+		 const0_rtx, operands[3], operands[3]));
 DONE;
   }
   [(set_attr "type" "vmult")
(set_attr "length" "8")])
 
-(define_insn_and_split "add3_zext_dup_exec"
-  [(set (match_operand:V_DI 0 "register_operand"		 "= v,  v")
+(define_expand "add3_zext_dup"
+  [(match_operand:V_DI 0 "register_operand")
+   (match_operand:SI 1 "gcn_alu_operand")
+   (match_operand:V_DI 2 "gcn_alu_operand")]
+  ""
+  {
+rtx vcc = gen_rtx_REG (DImode, VCC_REG);
+emit_insn (gen_add3_vcc_zext_dup (operands[0], operands[1],
+	operands[2], vcc));
+DONE;
+  })
+
+(define_insn_and_split "add3_vcc_zext_dup_exec"
+  [(set (match_operand:V_DI 0 "register_operand"		"=   v,   v")
 	(vec_merge:V_DI
 	  (plus:V_DI
 	(zero_extend:V_DI
 	  (vec_duplicate:
-		(match_operand:SI 1 "gcn_alu_operand"		 "ASv,BSv")))
-	(match_operand:V_DI 2 "gcn_alu_operand"		 "vDb,vDA"))
-	  (match_operand:V_DI 3 "gcn_register_or_unspec_operand" " U0, U0")
-	  (match_operand:DI 4 "gcn_exec_reg_operand"		 "  e,  e")))
-   (clobber (reg:DI VCC_REG))]
+		(match_operand:SI 1 "gcn_alu_operand"		"  ASv, BSv")))
+	(match_operand:V_DI 2 "gcn_alu_operand"		"  vDb, vDA"))
+	  (match_operand:V_DI 4 "gcn_register_or_unspec_operand" "  U0,  U0")
+	  (match_operand:DI 5 "gcn_exec_reg_operand"		"e,   e")))
+   (set (match_operand:DI 3 "register_operand"			"=SgcV,SgcV")
+	(and:DI
+	  (ltu:DI (plus:V_DI 
+		(zero_extend:V_DI (vec_duplicate: (match_dup 1)))
+		(match_dup 2))
+		  (match_dup 1))
+	  (match_dup 5)))]
   ""
   "#"
   "gcn_can_split_p  (mode, operands[0])
&& gcn_can_split_p (mode, operands[2])
-   && gcn_can_split_p (mode, operands[3])"
+   && gcn_can_split_p (mode, operands[4])"
   [(const_int 0)]
   {
-rtx vcc = gen_rtx_REG (DImode, VCC_REG);
 emit_insn (gen_add3_vcc_dup_exec
 		(gcn_operand_part (mode, operands[0], 0),
 		 gcn_operand_part (DImode, operands[1], 0),
 		 gcn_operand_part (mode, operands[2], 0),
-		 vcc,
-		 gcn_operand_part (mode, 

[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

Re: libgo patch committed: Build syscall test with -static

[Rainer Orth]

Hi Ian,

> This libgo patch builds the syscall test with -static.  This avoids
> problems finding libgo.so when running the test as root, which invokes
> the test as a child process in various limited environments.  This
> fixes GCC PR 95061.  Bootstrapped and ran Go tests on
> x86_64-pc-linux-gnu.  Committed to mainline.

this patch broke the syscall test on Solaris:

ld: fatal: library -lpthread: not found
ld: fatal: library -lm: not found
ld: fatal: library -lc: not found
ld: fatal: library -lc: not found
collect2: error: ld returned 1 exit status
FAIL: syscall

There are no static versions of system libraries.

Rainer

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University

[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;

Re: [C++] template arg comparison

[Arseny Solokha]

Hi,


> When fixing up the template specialization hasher I was confused by the
> control flow through template_args_equal.  This reorders the category
> checking, so it is clearer as to what kind of node can reach which point.
>
> nathan
>
> 2020-05-13  Nathan Sidwell  
>
>   * pt.c (template_args_equal): Reorder category checking for
>   clarity.
>
> diff --git i/gcc/cp/pt.c w/gcc/cp/pt.c
> index a732ced2d8d..a36f603761c 100644
> --- i/gcc/cp/pt.c
> +++ w/gcc/cp/pt.c
> @@ -9092,22 +9084,22 @@ template_args_equal (tree ot, tree nt, bool 
> partial_order /* = false */)
>if (class_nttp_const_wrapper_p (ot))
>  ot = TREE_OPERAND (ot, 0);
>
> -  if (TREE_CODE (nt) == TREE_VEC)
> +  if (TREE_CODE (nt) == TREE_VEC || TREE_CODE (nt) == TREE_VEC)

Shouldn't there be

  if (TREE_CODE (ot) == TREE_VEC || TREE_CODE (nt) == TREE_VEC)

?


>  /* For member templates */
> -return TREE_CODE (ot) == TREE_VEC && comp_template_args (ot, nt);
> -  else if (PACK_EXPANSION_P (ot))
> -return (PACK_EXPANSION_P (nt)
> +return TREE_CODE (ot) == TREE_CODE (nt) && comp_template_args (ot, nt);
> +  else if (PACK_EXPANSION_P (ot) || PACK_EXPANSION_P (nt))
> +return (PACK_EXPANSION_P (ot) && PACK_EXPANSION_P (nt)
>   && template_args_equal (PACK_EXPANSION_PATTERN (ot),
>   PACK_EXPANSION_PATTERN (nt))
>   && template_args_equal (PACK_EXPANSION_EXTRA_ARGS (ot),
>   PACK_EXPANSION_EXTRA_ARGS (nt)));
>else if (ARGUMENT_PACK_P (ot) || ARGUMENT_PACK_P (nt))
>  return cp_tree_equal (ot, nt);
> -  else if (ot && TREE_CODE (ot) == ARGUMENT_PACK_SELECT)
> +  else if (TREE_CODE (ot) == ARGUMENT_PACK_SELECT)
>  gcc_unreachable ();
> -  else if (TYPE_P (nt))
> +  else if (TYPE_P (nt) || TYPE_P (nt))

And here:

  else if (TYPE_P (ot) || TYPE_P (nt))

?

Thanks,

Arseny.


>  {
> -  if (!TYPE_P (ot))
> +  if (!(TYPE_P (nt) && TYPE_P (ot)))
>   return false;
>/* Don't treat an alias template specialization with dependent
>arguments as equivalent to its underlying type when used as a
> @@ -9125,8 +9117,6 @@ template_args_equal (tree ot, tree nt, bool 
> partial_order /* = false */)
>else
>   return same_type_p (ot, nt);
>  }
> -  else if (TREE_CODE (ot) == TREE_VEC || TYPE_P (ot))
> -return 0;
>else
>  {
>/* Try to treat a template non-type argument that has been converted
> @@ -9136,6 +9126,7 @@ template_args_equal (tree ot, tree nt, bool 
> partial_order /* = false */)
>|| code1 == NON_LVALUE_EXPR;
>  code1 = TREE_CODE (ot))
>   ot = TREE_OPERAND (ot, 0);
> +
>for (enum tree_code code2 = TREE_CODE (nt);
>  CONVERT_EXPR_CODE_P (code2)
>|| code2 == NON_LVALUE_EXPR;

[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.

Re: Ping: [PATCH] libiberty: Update D symbol demangling for latest ABI spec.

[Iain Buclaw via Gcc-patches]

On 14/05/2020 16:36, Jeff Law wrote:
> On Sun, 2020-05-10 at 11:10 +0200, Iain Buclaw via Gcc-patches wrote:
>> Ping
>>
>> On 03/05/2020 09:37, Iain Buclaw via Gcc-patches wrote:
>>> Ping.
>>>
>>> There is a new mangle string "Nm" in the abi to denote the @live attribute,
>>> however will add support in a follow up patch.
>>>
>>>
>>> On 15 April 2020 12:04:29 CEST, Iain Buclaw via Gcc-patches <
>>> gcc-patches@gcc.gnu.org> wrote:
 Ping.

 On 04/04/2020 13:33, Iain Buclaw wrote:
> Hi,
>
> Some small improvements and clarifications have been done in the D ABI
> specification to remove all ambiguities found in the current grammar,
> this implementation now more closely resembles the spec, whilst
> maintaining compatibility with the old ABI.
>
> Three new rules have been added to the ABI.
>
> 1. Back references using 'Q', analogous to C++ substitutions, compresses
>repeated identifiers, types, and template symbol and value parameters.
>
> 2. Template aliases to externally mangled symbols are prefixed with 'X'.
>This includes any symbol that isn't extern(D), or has its name
>overriden with pragma(mangle).  This fixes an ambiguity where it was
>not clear whether 'V' was an encoded calling convention, or the next
>template value parameter.
>
> 3. Alias parameters, templates, and tuple symbols no longer encode the
>symbol length of its subpart.  Tuples are now terminated with 'Z'.
>This fixes another ambiguity where the first character of the mangled
>name can be a digit as well, so the demangler had to figure out where
>to split the two adjacent numbers by trying out each combination.
>
> This patch was originally written by Rainer Schuetze, with clean-ups and
> backwards compatibility added by myself.
>
> Bootstrapped and regression tested on x86_linux-gnu, OK for mainline?
>
> Regards
> Iain.
>
> ---
>
> libiberty/ChangeLog:
>
> 2019-04-04  Rainer Schuetze  
> Iain Buclaw  
>
>   * d-demangle.c (enum dlang_symbol_kinds): Remove enum.
>   (struct dlang_info): New struct
>   (dlang_decode_backref): New function.
>   (dlang_backref): New function.
>   (dlang_symbol_backref): New function.
>   (dlang_type_backref): New function.
>   (dlang_symbol_name_p): New function.
>   (dlang_function_type_noreturn): New function.
>   (dlang_function_type): Add 'info' parameter.  Decode function
> type
>   with dlang_function_type_noreturn.
>   (dlang_function_args): Add 'info' parameter.
>   (dlang_type): Add 'info' parameter.  Handle back referenced
> types.
>   (dlang_identifier): Replace 'kind' parameter with 'info'.  Handle
> back
>   referenced symbols.  Split off decoding of plain identifiers
> to...
>   (dlang_lname): ...here.
>   (dlang_parse_mangle): Replace 'kind' parameter with
> 'info'.  Decode
>   function type and return with dlang_type.
>   (dlang_parse_qualified): Replace 'kind' parameter with 'info',
> add
>   'suffix_modifier' parameter.  Decode function type with
>   dlang_function_type_noreturn.
>   (dlang_parse_tuple): Add 'info' parameter.
>   (dlang_template_symbol_param): New function.
>   (dlang_template_args): Add 'info' parameter.  Decode symbol
> parameter
>   with dlang_template_symbol_param.  Handle back referenced values,
> and
>   externally mangled parameters.
>   (dlang_parse_template): Add 'info' parameter.
>   (dlang_demangle_init_info): New function.
>   (dlang_demangle): Initialize and pass 'info' parameter.
>   * testsuite/d-demangle-expected: Add new tests.
> OK.  I think this would fall under your "D" maintainership status.  

Thanks.  I'm not so sure about that though, despite yes this only touches the
"D" support files in libiberty.

The next two patches I have lined up will be additions of a few lines (support
for @live and variadic parameter attributes), so I feel more inclined to commit
them as obvious without review, unlike this change which is more substantial.

Iain.

[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

Re: dejagnu version update?

[Tom Tromey]

> "Rob" == Rob Savoye  writes:

Rob>   Not that team, the folks I talked to thought I was crazy for wanting
Rob> to refactor it. :-)

I don't think refactoring dejagnu is crazy, but I think it's pretty hard
to imagine rewriting the gdb test suite in Python.  It's 260 KLOC.

Tom

[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.

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

[Uros Bizjak via Gcc-patches]

gcc/ChangeLog:

2020-05-14  Uroš Bizjak  

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

testsuite/ChangeLog:

2020-05-14  Uroš Bizjak  

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

Bootstrapped and regression tested on x86_64-linux-gnu {,-m32}.

Uros.
diff --git a/gcc/config/i386/sse.md b/gcc/config/i386/sse.md
index dc0ecbc182e..28d2c434caf 100644
--- a/gcc/config/i386/sse.md
+++ b/gcc/config/i386/sse.md
@@ -6504,6 +6504,25 @@
(set_attr "prefix" "maybe_vex")
(set_attr "mode" "V4SF")])
 
+(define_insn "truncv2dfv2sf2"
+  [(set (match_operand:V2SF 0 "register_operand" "=v")
+   (float_truncate:V2SF
+ (match_operand:V2DF 1 "vector_operand" "vBm")))]
+  "TARGET_MMX_WITH_SSE"
+{
+  if (TARGET_AVX)
+return "vcvtpd2ps{x}\t{%1, %0|%0, %1}";
+  else
+return "cvtpd2ps\t{%1, %0|%0, %1}";
+}
+  [(set_attr "type" "ssecvt")
+   (set_attr "amdfam10_decode" "double")
+   (set_attr "athlon_decode" "vector")
+   (set_attr "bdver1_decode" "double")
+   (set_attr "prefix_data16" "1")
+   (set_attr "prefix" "maybe_vex")
+   (set_attr "mode" "V4SF")])
+
 (define_insn "*sse2_cvtpd2ps_mask"
   [(set (match_operand:V4SF 0 "register_operand" "=v")
(vec_concat:V4SF
@@ -6664,6 +6683,20 @@
(set_attr "prefix" "maybe_vex")
(set_attr "mode" "V2DF")])
 
+(define_insn "extendv2sfv2df2"
+  [(set (match_operand:V2DF 0 "register_operand" "=v")
+   (float_extend:V2DF
+ (match_operand:V2SF 1 "register_operand" "v")))]
+  "TARGET_MMX_WITH_SSE"
+  "%vcvtps2pd\t{%1, %0|%0, %1}"
+  [(set_attr "type" "ssecvt")
+   (set_attr "amdfam10_decode" "direct")
+   (set_attr "athlon_decode" "double")
+   (set_attr "bdver1_decode" "double")
+   (set_attr "prefix_data16" "0")
+   (set_attr "prefix" "maybe_vex")
+   (set_attr "mode" "V2DF")])
+
 (define_expand "vec_unpacks_hi_v4sf"
   [(set (match_dup 2)
(vec_select:V4SF
diff --git a/gcc/testsuite/gcc.target/i386/pr95046-7.c 
b/gcc/testsuite/gcc.target/i386/pr95046-7.c
new file mode 100644
index 000..b3702a5d761
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/pr95046-7.c
@@ -0,0 +1,25 @@
+/* PR target/95046 */
+/* { dg-do compile { target { ! ia32 } } } */
+/* { dg-options "-O3 -msse2" } */
+
+
+float f[2];
+double d[2];
+
+void
+test_float_truncate (void)
+{
+  for (int i = 0; i < 2; i++)
+f[i] = d[i];
+}
+
+/* { dg-final { scan-assembler "\tv?cvtpd2psx?" } } */
+
+void
+test_float_extend (void)
+{
+  for (int i = 0; i < 2; i++)
+d[i] = f[i];
+}
+
+/* { dg-final { scan-assembler "\tv?cvtps2pd" } } */

[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.

Re: Ping: [PATCH] wwwdocs: Add D front-end section for GCC 10 changes

[Iain Buclaw via Gcc-patches]

On 14/05/2020 17:04, Gerald Pfeifer wrote:
> On Thu, 14 May 2020, Jeff Law wrote:
>>> OK to commit?
>> OK.  In fact, this seems like you shouldn't need reviews -- you're just 
>> updating the docs for D.
> 
> Agreed, though always happy to help and provide review and feedback
> - sometimes just a bit slow as in this case.  But, indeed, you can
> self approve, Iain.
> 
> 
> Here is some specific feedback on the patch:
>  
> +  Aliases can now be created directly from any __trait that
> +  return symbols or tuples.  Previously, an AliasSeq was
> 
> "returns" ?
> 

The "s" should instead be on:

"__traits that return symbols or tuples."

I don't *think* "returns" is necessary, there's already a plethora of plurals.
To be sure though, I put it through a grammar checker, and it flags up "returns"
as an error of subject-verb agreement in the sentence.

> +  It is now possible to detect the language ABI specified for a struct,
> +  class, or interface using __traits(getLinkage, ...)
> 
> Full stop.
> 
> +  Support for core.math.toPrec intrinsics have been added.
> 
> "has been"
> 
> +  These intrinsics guarantee the rounding to specific floating-point
> +  precisions at required points in the code.
> 
> Is this about required points (by the standard) or specified (by the 
> user/programmer)?
> 

By user/programmer, so I've changed it to "specified".

> +  Optional parentheses in asm operands are now deprecated 
> and
> +  will be removed in a future release.
> 
> Maybe omit "now" of which there's a number in the vicinity already?
> 
> +  Added --enable-libphobos-checking configure option to
> 
> "Added a..."?
> 
> +  Added --with-libphobos-druntime-only configure option to
> 
> Same here?
> 
> +  allow specifying whether to build only the core D runtime library, or
> +  both the core and standard libraries into libphobos.
> 
> This reads a bit complicated.  Maybe "option to indicate whether to 
> build..." ?
> 
> 
> Please consider those items and questions and share the patch as you'll
> install it - no need for review or anything. :)
> 


Installed.

diff --git a/htdocs/gcc-10/changes.html b/htdocs/gcc-10/changes.html
index 8eaa3326..b9fae2c6 100644
--- a/htdocs/gcc-10/changes.html
+++ b/htdocs/gcc-10/changes.html
@@ -497,6 +497,41 @@ int get_naïve_pi() {
   
 
 
+D
+
+  Support for static foreach has been implemented.
+  Aliases can now be created directly from any __traits that
+  return symbols or tuples.  Previously, an AliasSeq was
+  necessary in order to alias their return.
+  
+  It is now possible to detect the language ABI specified for a struct,
+  class, or interface using __traits(getLinkage, ...).
+  Support for core.math.toPrec intrinsics has been added.
+  These intrinsics guarantee the rounding to specific floating-point
+  precisions at specified points in the code.
+  
+  Support for pragma(inline) has been implemented.  Previously
+  the pragma was recognized, but had no effect on the compilation.
+  
+  Optional parentheses in asm operands are deprecated and will
+  be removed in a future release.
+  
+  All content imported files are now included in the make dependency list
+  when compiling with -M.
+  
+  Compiler recognized attributes provided by the gcc.attribute
+  module will now take effect when applied to function prototypes as well
+  as when applied to full function declarations.
+  
+  Added a --enable-libphobos-checking configure option to
+  control whether run-time checks are compiled into the D runtime library.
+  
+  Added a --with-libphobos-druntime-only configure option to
+  indicate whether to build only the core D runtime library, or both the
+  core and standard libraries into libphobos.
+  
+
+
 Fortran
 
   use_device_addr of version 5.0 of the

[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.

Re: [PATCH] avoid -Warray-bounds when indexing into array members of union (PR 94940)

[Jeff Law via Gcc-patches]

On Fri, 2020-05-08 at 15:46 -0600, Martin Sebor via Gcc-patches wrote:
> The improved detection of accesses to interior zero-length arrays
> fails to consider the case when the array is a member of a union.
> Such accesses are documented as supported so warning for them is
> not expected.  The attached patch adjusts the component_ref_size
> function to return the size of the enclosing union instead of
> the member array.
> 
> The VRP bit of the patch remove a couple of redundant tests and
> unreachable blocks from the check_mem_ref function.  The change
> is not directly related to the fix except that I noticed them
> while working on it and it seems safe either to include in this
> patch or commit on its own.
> 
> Tested on x86_64-linux.
> 
> PR middle-end/94940 - spurious -Warray-bounds for a zero length array member 
> of
> union
> 
> gcc/testsuite/ChangeLog:
> 
>   PR middle-end/94940
>   * gcc.dg/Warray-bounds-61.c: New test.
> 
> gcc/ChangeLog:
> 
>   PR middle-end/94940
>   * tree-vrp.c (vrp_prop::check_mem_ref): Remove unreachable code.
>   * tree.c (component_ref_size): Correct the handling or array members
>   of unions.
>   Drop a pointless test.
>   Rename a local variable.
OK
jeff

[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.

Re: [PATCH resend] rs6000, pr 94833: fix vec_first_match_index for nulls

[Segher Boessenkool]

Hi!

On Wed, May 13, 2020 at 10:14:24AM -0700, Carl Love wrote:
> The following patch fixes PR94833, vec_first_match_index does not
> function as described in its description.
> 
> The builtin does not handle vector elements which are zero correctly. 
> The following patch fixes the issue and adds additional test cases to
> verify the vec_first_match_index builtin and related builtins work
> correctly with elements that are zero.

> 2020-04-30  Carl Love  
> 
>   PR target/94833
>   * config/rs6000/vsx.md (define_expand): Fix instruction generation for
>   first_match_index_.
>   * testsuite/gcc.target/powerpc/builtins-8-p9-runnable.c (main): Add
>   additional test cases with zero vector elements.

Okay for trunk and all backports needed after a while.  Thanks!


Segher

Re: [PATCH] Optimize store_expr from STRING_CST [PR95052]

[Jakub Jelinek via Gcc-patches]

On Thu, May 14, 2020 at 10:10:55AM -0600, Jeff Law wrote:
> On Tue, 2020-05-12 at 10:12 +0200, Jakub Jelinek wrote:
> > Hi!
> > 
> > In the following testcase, store_expr of e.g. 97 bytes long string literal
> > into 1MB long array is implemented by copying the 97 bytes from .rodata
> > section, followed by clearing the remaining bytes.  But, as the STRING_CST
> > has type char[1024*1024], we actually allocate whole 1MB in .rodata section
> > for it, even when we only use the first 97 bytes from that.
> > 
> > The following patch tweaks it so that if we are going to initialize only the
> > small part from it, we don't emit all the zeros that we never use after it.
> > 
> > Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
> > 
> > 2020-05-12  Jakub Jelinek  
> > 
> > PR middle-end/95052
> > * expr.c (store_expr): If expr_size is constant and significantly
> > larger than TREE_STRING_LENGTH, set temp to just the
> > TREE_STRING_LENGTH portion of the STRING_CST.
> > 
> > * gcc.target/i386/pr95052.c: New test.
> OK.  Initially I had a number of concerns, but this only affects the .rodata
> that's used to initialize the real object.  The .rodata bits have no other
> purpose and aren't otherwise accessable.

I wasn't sure if it wouldn't be safer to add some bool flag set to true by
the new code and then add gcc_assert in all the other paths, like following
incremental patch.  I believe none of the asserts can trigger right now,
but the code is still adjusting what it plans to use as source before actually
only copying fewer bytes from it, so if somebody changes it later...

Thoughts on that?

--- gcc/expr.c.jj   2020-05-14 18:43:46.324145031 +0200
+++ gcc/expr.c  2020-05-14 18:47:19.003950500 +0200
@@ -5583,6 +5583,7 @@ store_expr (tree exp, rtx target, int ca
   rtx temp;
   rtx alt_rtl = NULL_RTX;
   location_t loc = curr_insn_location ();
+  bool shortened_string_cst = false;
 
   if (VOID_TYPE_P (TREE_TYPE (exp)))
 {
@@ -5771,6 +5772,7 @@ store_expr (tree exp, rtx target, int ca
= build_index_type (size_int (TREE_STRING_LENGTH (exp) - 1));
  TREE_TYPE (rexp) = build_array_type (TREE_TYPE (TREE_TYPE (exp)),
   index);
+ shortened_string_cst = true;
}
}
   temp = expand_expr_real (rexp, tmp_target, GET_MODE (target),
@@ -5787,6 +5789,7 @@ store_expr (tree exp, rtx target, int ca
   && TREE_CODE (exp) != ERROR_MARK
   && GET_MODE (target) != TYPE_MODE (TREE_TYPE (exp)))
 {
+  gcc_assert (!shortened_string_cst);
   if (GET_MODE_CLASS (GET_MODE (target))
  != GET_MODE_CLASS (TYPE_MODE (TREE_TYPE (exp)))
  && known_eq (GET_MODE_BITSIZE (GET_MODE (target)),
@@ -5839,6 +5842,7 @@ store_expr (tree exp, rtx target, int ca
 {
   if (GET_MODE (temp) != GET_MODE (target) && GET_MODE (temp) != VOIDmode)
{
+ gcc_assert (!shortened_string_cst);
  if (GET_MODE (target) == BLKmode)
{
  /* Handle calls that return BLKmode values in registers.  */
@@ -5924,6 +5928,8 @@ store_expr (tree exp, rtx target, int ca
emit_label (label);
}
}
+  else if (shortened_string_cst)
+   gcc_unreachable ();
   /* Handle calls that return values in multiple non-contiguous locations.
 The Irix 6 ABI has examples of this.  */
   else if (GET_CODE (target) == PARALLEL)
@@ -5953,6 +5959,8 @@ store_expr (tree exp, rtx target, int ca
emit_move_insn (target, temp);
}
 }
+  else
+gcc_assert (!shortened_string_cst);
 
   return NULL_RTX;
 }


Jakub

[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.

Re: dejagnu version update?

[Rob Savoye]

On 5/14/20 10:08 AM, David Edelsohn wrote:

> Have you approached the Linux Foundation Core Infrastructure
> Initiative for funding for both DejaGNU maintenance (patch backlog)
> and refactoring DejaGNU in Python efforts?

  Not that team, the folks I talked to thought I was crazy for wanting
to refactor it. :-) That's been the usual answer from anyone. I even
talked about this at GNU Tools Cauldron once. Seriously though, it'd be
great to analyze the current code base, write an actual design document,
clean internal APIs, and build something we can use for another 30
years. I'd start by writing a solid expect module for Python, and then
embedding Tcl in Python as a comparability layer. I understand it'd be a
huge project, which is why I haven't done this as a volunteer.

  I think there has been a bit of a leave it alone so it stays stable
attitude... Bugs in the test framework effect our ability to work on the
toolchain efficiently, but other than the handful of people here, nobody
cares. Forgetting the refactoring daydream, testing patches and doing
releases still needs to be done, so I think we need a long-term solution
and fresh energy.

- rob -
---
https://www.senecass.com

Re: ChangeLog files - server and client scripts

[Joseph Myers]

On Thu, 14 May 2020, Martin Liška wrote:

> On 5/13/20 7:53 PM, Joseph Myers wrote:
> > On Wed, 13 May 2020, Martin Liška wrote:
> > 
> > > I'm sending the gcc-changelog relates scripts which should be added to
> > > contrib
> > > folder. The patch contains:
> > > - git_check_commit.py - checking script that verifies git message format
> > 
> > We need a documentation patch to contribute.html or gitwrite.html that
> > describes the exact commit message format being used.
> 
> Sure, I'm sending patch for that.

Thanks.  There are references to author timestamps there.  The date in a 
ChangeLog entry should always be a commit timestamp, not an author one, so 
author timestamps present either in commit messages or in the git commit 
metadata should be ignored, with only the committer timestamps from the 
git commit metadata being used when generating ChangeLog files.

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

Re: ChangeLog files - server and client scripts

[Joseph Myers]

On Thu, 14 May 2020, Martin Liška wrote:

> On 5/13/20 7:53 PM, Joseph Myers wrote:
> > On Wed, 13 May 2020, Martin Liška wrote:
> > 
> > > I'm sending the gcc-changelog relates scripts which should be added to
> > > contrib
> > > folder. The patch contains:
> > > - git_check_commit.py - checking script that verifies git message format
> > 
> > We need a documentation patch to contribute.html or gitwrite.html that
> > describes the exact commit message format being used.
> 
> Sure, I'm sending patch for that.

Thanks.  There are references to author timestamps there.  The date in a 
ChangeLog entry should always be a commit timestamp, not an author one, so 
author timestamps present either in commit messages or in the git commit 
metadata should be ignored, with only the committer timestamps from the 
git commit metadata being used when generating ChangeLog files.

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

[patch, libfortran, committed]

[Thomas Koenig via Gcc-patches]

Hi,

I just committed as obvious a patch which fixed a hang on close
with -pthread after a previous error on close with an invalid
STATUS.  The solution was obvious: Return early if an error
occurred.

I also managed to make some double ChangeLog entries (fixed with the
next commit after), but hey - git doing strange and unforseen stuff
is par for the course.  My life has gotten a lot easier since I stopped
worrying about that kind of stuff.

I will also backport to the other affected branches.

Regards

Thomas

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.
diff --git a/libgfortran/io/close.c b/libgfortran/io/close.c
index 8aaa00393e7..17e064ba4e8 100644
--- a/libgfortran/io/close.c
+++ b/libgfortran/io/close.c
@@ -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)
diff --git a/libgomp/testsuite/libgomp.fortran/close_errors_1.f90 b/libgomp/testsuite/libgomp.fortran/close_errors_1.f90
new file mode 100644
index 000..6edb7da4116
--- /dev/null
+++ b/libgomp/testsuite/libgomp.fortran/close_errors_1.f90
@@ -0,0 +1,19 @@
+! { dg-do run }
+! PR 95115 - this used to hang with -pthread.  Original test case by
+! Bill Long.
+
+program test
+  character(len=16) my_status
+  character(len=1000) :: iomsg
+  open (unit=10, file='test.dat')
+  print *,42
+  write (10, *) 'weird'
+  rewind (10)
+  read (10, *) my_status
+  close (10)
+  open (unit=10, file='test.dat')
+  close (unit=10, status=my_status, iostat=ios, iomsg=iomsg)
+  if (ios == 0) stop 1
+  if (iomsg /= "Bad STATUS parameter in CLOSE statement") stop 2
+  close (10, status='delete')
+end program test

[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.

[C++] simplify tsubst_template_decl

[Nathan Sidwell]

the final (for now) templatet simplification is this one.  The control 
flow through tsubst_template_decl was also confusing.  This flattens the 
conditionals and reorders things to make it simpler.


pushed to trunk.

nathan
--
Nathan Sidwell
2020-05-14  Nathan Sidwell  

	* pt.c (tsubst_template_decl): Reorder and commonize some control
	paths.

diff --git i/gcc/cp/pt.c w/gcc/cp/pt.c
index 4517147c8aa..5ca659e9f28 100644
--- i/gcc/cp/pt.c
+++ w/gcc/cp/pt.c
@@ -14031,52 +14031,50 @@ tsubst_template_decl (tree t, tree args, tsubst_flags_t complain,
 = tsubst_template_parms (DECL_TEMPLATE_PARMS (t), args,
 			 complain);
 
-  if (TREE_CODE (decl) == TYPE_DECL
-  && !TYPE_DECL_ALIAS_P (decl))
+  bool class_p = false;
+  tree inner = decl;
+  ++processing_template_decl;
+  if (TREE_CODE (inner) == FUNCTION_DECL)
+inner = tsubst_function_decl (inner, args, complain, lambda_fntype);
+  else
 {
-  tree new_type;
-  ++processing_template_decl;
-  new_type = tsubst (TREE_TYPE (t), args, complain, in_decl);
-  --processing_template_decl;
-  if (new_type == error_mark_node)
-	return error_mark_node;
+  if (TREE_CODE (inner) == TYPE_DECL && !TYPE_DECL_ALIAS_P (inner))
+	{
+	  class_p = true;
+	  inner = TREE_TYPE (inner);
+	}
+  inner = tsubst (inner, args, complain, in_decl);
+}
+  --processing_template_decl;
+  if (inner == error_mark_node)
+return error_mark_node;
 
-  TREE_TYPE (r) = new_type;
+  if (class_p)
+{
   /* For a partial specialization, we need to keep pointing to
 	 the primary template.  */
   if (!DECL_TEMPLATE_SPECIALIZATION (t))
-	CLASSTYPE_TI_TEMPLATE (new_type) = r;
-  DECL_TEMPLATE_RESULT (r) = TYPE_MAIN_DECL (new_type);
-  DECL_TI_ARGS (r) = CLASSTYPE_TI_ARGS (new_type);
-  DECL_CONTEXT (r) = TYPE_CONTEXT (new_type);
+	CLASSTYPE_TI_TEMPLATE (inner) = r;
+
+  DECL_TI_ARGS (r) = CLASSTYPE_TI_ARGS (inner);
+  inner = TYPE_MAIN_DECL (inner);
+}
+  else if (lambda_fntype)
+{
+  tree args = template_parms_to_args (DECL_TEMPLATE_PARMS (r));
+  DECL_TEMPLATE_INFO (inner) = build_template_info (r, args);
 }
   else
 {
-  tree new_decl;
-  ++processing_template_decl;
-  if (TREE_CODE (decl) == FUNCTION_DECL)
-	new_decl = tsubst_function_decl (decl, args, complain, lambda_fntype);
-  else
-	new_decl = tsubst (decl, args, complain, in_decl);
-  --processing_template_decl;
-  if (new_decl == error_mark_node)
-	return error_mark_node;
-
-  DECL_TEMPLATE_RESULT (r) = new_decl;
-  TREE_TYPE (r) = TREE_TYPE (new_decl);
-  DECL_CONTEXT (r) = DECL_CONTEXT (new_decl);
-  if (lambda_fntype)
-	{
-	  tree args = template_parms_to_args (DECL_TEMPLATE_PARMS (r));
-	  DECL_TEMPLATE_INFO (new_decl) = build_template_info (r, args);
-	}
-  else
-	{
-	  DECL_TI_TEMPLATE (new_decl) = r;
-	  DECL_TI_ARGS (r) = DECL_TI_ARGS (new_decl);
-	}
+  if (TREE_CODE (decl) != TYPE_DECL || !TYPE_DECL_ALIAS_P (decl))
+	DECL_TI_TEMPLATE (inner) = r;
+  DECL_TI_ARGS (r) = DECL_TI_ARGS (inner);
 }
 
+  DECL_TEMPLATE_RESULT (r) = inner;
+  TREE_TYPE (r) = TREE_TYPE (inner);
+  DECL_CONTEXT (r) = DECL_CONTEXT (inner);
+
   DECL_TEMPLATE_INSTANTIATIONS (r) = NULL_TREE;
   DECL_TEMPLATE_SPECIALIZATIONS (r) = NULL_TREE;
 

[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)

Re: [PATCH] Optimize store_expr from STRING_CST [PR95052]

[Jeff Law via Gcc-patches]

On Tue, 2020-05-12 at 10:12 +0200, Jakub Jelinek wrote:
> Hi!
> 
> In the following testcase, store_expr of e.g. 97 bytes long string literal
> into 1MB long array is implemented by copying the 97 bytes from .rodata
> section, followed by clearing the remaining bytes.  But, as the STRING_CST
> has type char[1024*1024], we actually allocate whole 1MB in .rodata section
> for it, even when we only use the first 97 bytes from that.
> 
> The following patch tweaks it so that if we are going to initialize only the
> small part from it, we don't emit all the zeros that we never use after it.
> 
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
> 
> 2020-05-12  Jakub Jelinek  
> 
>   PR middle-end/95052
>   * expr.c (store_expr): If expr_size is constant and significantly
>   larger than TREE_STRING_LENGTH, set temp to just the
>   TREE_STRING_LENGTH portion of the STRING_CST.
> 
>   * gcc.target/i386/pr95052.c: New test.
OK.  Initially I had a number of concerns, but this only affects the .rodata
that's used to initialize the real object.  The .rodata bits have no other
purpose and aren't otherwise accessable.

jeff
> 

Re: dejagnu version update?

[David Edelsohn via Gcc]

On Thu, May 14, 2020 at 12:00 PM Rob Savoye  wrote:
>
> On 5/14/20 8:08 AM, Rainer Orth wrote:
>
> >> stops responding for whatever reason.  I have come up with a solution
> >> (that I'd be happy to upstream, except that DejaGNU maintenance seems to
> >> have been dead for like a year now), which I have also confirmed to be
> >> required with current DejaGNU Git master so it must be a different one,
> >> and I would like to know how it might be related to the bug you mention.
>
>   I feel I need to bring up the issue that DejaGnu is 30 years old, and
> it's two maintainers are either trying to pay bills, or trying to
> retire, or both... This problem will effect more projects in the future,
> not just DejaGnu. I'd love to see if anyone would like to become a
> co-maintainer, who preferably will be actively working for a few decades
> still. I think most people on these lists make their income from working
> on the toolchain, but some of us are still volunteers... and getting
> older every day...
>
>   There is a patch backlog neither of us have even looked at, sorry. I'm
> willing to put some time into this, but I think you all realize the time
> involved to adequately test this. I'm not sure I have enough disk space. :-)
>
>   Personally, I tried to find funding to refactor DejaGnu in Python,
> since Tcl is unmaintained too, but nobody was interested.

I greatly appreciate all of the work that you have invested in the
infrastructure and your continued assistance.

Have you approached the Linux Foundation Core Infrastructure
Initiative for funding for both DejaGNU maintenance (patch backlog)
and refactoring DejaGNU in Python efforts?

Thanks, David

[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

Re: [PATCH 2/2] arm: Add support for interrupt routines to reg_needs_saving_p

[Ramana Radhakrishnan via Gcc-patches]

>  static bool reg_needs_saving_p (unsigned reg)
>  {
>unsigned long func_type = arm_current_func_type ();

Ah ok , you needed it here.

Ramana