[Bug c++/66159] bogus warning for alias-declaration using elaborated-type-specifier

[egallager at gcc dot gnu.org]

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

--- Comment #4 from Eric Gallager  ---
(In reply to Jonathan Wakely from comment #3)
> Patch for stage 1:
> 
> diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
> index 4fa546a086c..4dc4e751b28 100644
> --- a/gcc/cp/parser.c
> +++ b/gcc/cp/parser.c
> @@ -17818,9 +17818,11 @@ cp_parser_elaborated_type_specifier (cp_parser*
> parser,
>   caught elsewhere in parsing.  Those that are pointless arrive
>   here.  */
>  
> -  if (cp_lexer_next_token_is (parser->lexer, CPP_SEMICOLON)
> +  if (warn_redundant_decls
> + && cp_lexer_next_token_is (parser->lexer, CPP_SEMICOLON)
>&& !is_friend && !processing_explicit_instantiation)
> -warning (0, "declaration %qD does not declare anything", decl);
> +warning (OPT_Wredundant_decls,
> +"declaration %qD does not declare anything", decl);
>  
>   type = TREE_TYPE (decl);
> }
> diff --git a/gcc/testsuite/g++.dg/warn/forward-inner.C
> b/gcc/testsuite/g++.dg/warn/forward-inner.C
> index 5336d4ed946..f720a6cdae3 100644
> --- a/gcc/testsuite/g++.dg/warn/forward-inner.C
> +++ b/gcc/testsuite/g++.dg/warn/forward-inner.C
> @@ -1,5 +1,6 @@
>  // Check that the compiler warns about inner-style forward declarations in
>  // contexts where they're not actually illegal, but merely useless.
> +// { dg-options "-Wredundant-decls" }
>  
>  // Verify warnings for and within classes, and by extension, struct and
> union.
>  class C1;
> @@ -70,7 +71,7 @@ template class TC6::TC7;  // Valid explicit
> instantiation, no warning
>  
>  
>  // Verify that friend declarations, also easy to confuse with forward
> -// declrations, are similarly not warned about.
> +// declarations, are similarly not warned about.
>  class C8 {
>   public:
>class C9 { };
> @@ -79,3 +80,10 @@ class C10 {
>   public:
>friend class C8::C9; // Valid friend declaration, no warning
>  };
> +
> +#if __cplusplus >= 201103L
> +// Verify that alias-declarations using an elaborated-type-specifier and
> +// nested-name-specifier are not warned about (PR c++/66159).
> +struct C11;
> +using A1 = struct ::C11;
> +#endif
> diff --git a/gcc/testsuite/g++.dg/warn/pr36999.C
> b/gcc/testsuite/g++.dg/warn/pr36999.C
> index ce2286efcf4..6f69e192d02 100644
> --- a/gcc/testsuite/g++.dg/warn/pr36999.C
> +++ b/gcc/testsuite/g++.dg/warn/pr36999.C
> @@ -1,5 +1,6 @@
>  /* PR36999: Erroneous "does not declare anything" warnings.  */
>  /* { dg-do compile } */
> +/* { dg-options "-Wredundant-decls" } */
>  
>  class C1 {
>   public: class C2 { };

It's stage 1 now.

[Bug fortran/86021] New: ICE when initializing a character array

[john.harper at vuw dot ac.nz]

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

Bug ID: 86021
   Summary: ICE when initializing a character array
   Product: gcc
   Version: 7.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: john.harper at vuw dot ac.nz
  Target Milestone: ---

On compiling this program with gfortran 7.2.1 the error message below it
appears. Is it a duplicate of bug 68155?

cayley[~/Jfh] % cat gfbug8.f90
program testgf
  implicit none
  integer,parameter:: mp=selected_real_kind(14)
  real(mp):: x
  character(precision(x)+5)::labels(3)=['my series ','intrinsic ','difference']
  print *,labels
end program testgf
cayley[~/Jfh] % gfortran gfbug8.f90
gfbug8.f90:7:0:

 end program testgf

internal compiler error: in output_constructor_regular_field, at varasm.c:5031
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

cayley[~/Jfh] % gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/7.2.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib
--libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared
--enable-threads=posix --enable-libmpx --with-system-zlib --with-isl
--enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu
--disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object
--enable-linker-build-id --enable-lto --enable-plugin
--enable-install-libiberty --with-linker-hash-style=gnu
--enable-gnu-indirect-function --enable-multilib --disable-werror
--enable-checking=release --enable-default-pie --enable-default-ssp
Thread model: posix
gcc version 7.2.1 20180116 (GCC) 
cayley[~/Jfh] %

[Bug fortran/85840] Memory leak in write.c

[jvdelisle at gcc dot gnu.org]

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

--- Comment #15 from Jerry DeLisle  ---
Author: jvdelisle
Date: Fri Jun  1 02:14:53 2018
New Revision: 261054

URL: https://gcc.gnu.org/viewcvs?rev=261054=gcc=rev
Log:
2018-05-31  Jerry DeLisle  

Backport from trunk.
PR libgfortran/85840
* io/write.c (write_real, write_real_g0, write_complex): Use
separate local variables for the float string length.

Modified:
branches/gcc-8-branch/libgfortran/ChangeLog
branches/gcc-8-branch/libgfortran/io/write.c

[Bug c/85957] i686: Integers appear to be different, but compare as equal

[joseph at codesourcery dot com]

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

--- Comment #11 from joseph at codesourcery dot com  ---
On Mon, 28 May 2018, vincent-gcc at vinc17 dot net wrote:

> floating-point expression: Once a floating-point number has been converted 
> into
> an integer type, the value of this integer must be fixed.

Yes, I agree that any particular conversion to integer executed in the 
abstract machine must produce some definite integer value for each 
execution.

(Conversions of *out-of-range* floating-point values to integer are a 
trickier case; under Annex F they produce unspecified values.  I think 
semantics along the lines of N2221 are fine for unspecified values arising 
from reading an uninitialized object, but more questionable for values 
arising from a floating-point-to-integer conversion.)

[Bug go/85429] Several gotools tests FAIL with Solaris as

[ian at gcc dot gnu.org]

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

--- Comment #12 from ian at gcc dot gnu.org  ---
Author: ian
Date: Thu May 31 22:46:52 2018
New Revision: 261045

URL: https://gcc.gnu.org/viewcvs?rev=261045=gcc=rev
Log:
PR go/85429

Various backports from mainline:

libgo: update to Go 1.10.2 release

cmd/go: support more Solaris assembler syntaxes

Patch by Rainer Orth.

cmd/go: update to match recent changes to gc

In https://golang.org/cl/111097 the gc version of cmd/go was updated
to include some gofrontend-specific changes. The gofrontend code
already has different versions of those changes; this CL makes the
gofrontend match the upstream code.

cmd/go, cmd/vet: make vet work with gccgo

Backport https://golang.org/cl/113715 and https://golang.org/cl/113716:

cmd/go: don't pass -compiler flag to vet

Without this running go vet -compiler=gccgo causes vet to fail.
The vet tool does need to know the compiler, but it is passed in
vetConfig.Compiler.

cmd/go, cmd/vet, go/internal/gccgoimport: make vet work with gccgo

When using gccgo/GoLLVM, there is no package file for a standard
library package. Since it is impossible for the go tool to rebuild the
package, and since the package file exists only in the form of a .gox
file, this seems like the best choice. Unfortunately it was confusing
vet, which wanted to see a real file. This caused vet to report errors
about missing package files for standard library packages. The
gccgoimporter knows how to correctly handle this case. Fix this by

1) telling vet which packages are standard;
2) letting vet skip those packages;
3) letting the gccgoimporter handle this case.

As a separate required fix, gccgo/GoLLVM has no runtime/cgo package,
so don't try to depend on it (as it happens, this fixes golang/go#25324).

The result is that the cmd/go vet tests pass when using -compiler=gccgo.

crypto/x509: specify path to AIX certificate file

go/build, cmd/go: update to match recent changes to gc

Several recent changes to the gc version of cmd/go improve the
gofrontend support. These changes are partially copies of existing
gofrontend differences, and partially new code. This CL makes the
gofrontend match the upstream code.

The changes included here come from:
https://golang.org/cl/111575
https://golang.org/cl/111595
https://golang.org/cl/111635
https://golang.org/cl/111636

For the record, the following recent gc changes are based on code
already present in the gofrontend repo:
https://golang.org/cl/110915
https://golang.org/cl/111615

For the record, a gc change, partially based on earlier gofrontend
work, also with new gc code, was already copied to gofrontend repo in
CL 111099:

https://golang.org/cl/111097

This moves the generated list of standard library packages from
cmd/go/internal/load to go/build.

gotools/ChangeLog:

Backport from mainline:
2018-05-09  Ian Lance Taylor  
* Makefile.am (check-go-tool): Don't copy zstdpkglist.go.
* Makefile.in: Rebuild.

Added:
branches/gcc-8-branch/libgo/go/cmd/internal/objabi/funcid.go
branches/gcc-8-branch/libgo/go/go/build/gc.go
branches/gcc-8-branch/libgo/go/go/build/gccgo.go
branches/gcc-8-branch/libgo/go/go/internal/srcimporter/testdata/issue23092/
   
branches/gcc-8-branch/libgo/go/go/internal/srcimporter/testdata/issue23092/issue23092.go
branches/gcc-8-branch/libgo/go/go/internal/srcimporter/testdata/issue24392/
   
branches/gcc-8-branch/libgo/go/go/internal/srcimporter/testdata/issue24392/issue24392.go
branches/gcc-8-branch/libgo/go/net/http/pprof/pprof_test.go
branches/gcc-8-branch/libgo/misc/cgo/testplugin/src/issue24351/
branches/gcc-8-branch/libgo/misc/cgo/testplugin/src/issue24351/main.go
branches/gcc-8-branch/libgo/misc/cgo/testplugin/src/issue24351/plugin.go
Modified:
branches/gcc-8-branch/gotools/ChangeLog
branches/gcc-8-branch/gotools/Makefile.am
branches/gcc-8-branch/gotools/Makefile.in
branches/gcc-8-branch/libgo/MERGE
branches/gcc-8-branch/libgo/Makefile.am
branches/gcc-8-branch/libgo/Makefile.in
branches/gcc-8-branch/libgo/VERSION
branches/gcc-8-branch/libgo/go/archive/zip/reader.go
branches/gcc-8-branch/libgo/go/archive/zip/reader_test.go
branches/gcc-8-branch/libgo/go/cmd/go/alldocs.go
branches/gcc-8-branch/libgo/go/cmd/go/go_test.go
branches/gcc-8-branch/libgo/go/cmd/go/internal/cfg/cfg.go
branches/gcc-8-branch/libgo/go/cmd/go/internal/get/vcs.go
branches/gcc-8-branch/libgo/go/cmd/go/internal/get/vcs_test.go
branches/gcc-8-branch/libgo/go/cmd/go/internal/help/helpdoc.go
branches/gcc-8-branch/libgo/go/cmd/go/internal/load/pkg.go
branches/gcc-8-branch/libgo/go/cmd/go/internal/test/test.go

[Bug target/85984] [8/9 Regression] ICE in create_pseudo_cfg, at dwarf2cfi.c:2874

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #7 from Jakub Jelinek  ---
Fixed.

[Bug target/85950] Unsafe-math-optimizations regresses optimization using SSE4.1 roundss

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |8.2

--- Comment #9 from Uroš Bizjak  ---
Fixed for 8.2+.

[Bug target/85591] __builtin_cpu_is() is not detecting bdver2 with Model = 0x02

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |ubizjak at gmail dot com
   Target Milestone|--- |8.2

--- Comment #6 from Uroš Bizjak  ---
Fixed for 8.2+

[Bug target/85950] Unsafe-math-optimizations regresses optimization using SSE4.1 roundss

[uros at gcc dot gnu.org]

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

--- Comment #8 from uros at gcc dot gnu.org ---
Author: uros
Date: Thu May 31 22:09:39 2018
New Revision: 261043

URL: https://gcc.gnu.org/viewcvs?rev=261043=gcc=rev
Log:
PR target/85950
* config/i386/i386.md (l2):
Enable for TARGET_SSE4_1 and generate rounds{s,d} and cvtts{s,d}2si{,q}
sequence.
(sse4_1_round2): Use nonimmediate_operand
for operand 1 predicate.

testsuite/ChangeLog:

PR target/85950
* gcc.target/i386/pr85950.c: New test.


Added:
branches/gcc-8-branch/gcc/testsuite/gcc.target/i386/pr85950.c
Modified:
branches/gcc-8-branch/gcc/ChangeLog
branches/gcc-8-branch/gcc/config/i386/i386.md
branches/gcc-8-branch/gcc/testsuite/ChangeLog

[Bug target/85591] __builtin_cpu_is() is not detecting bdver2 with Model = 0x02

[uros at gcc dot gnu.org]

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

--- Comment #5 from uros at gcc dot gnu.org ---
Author: uros
Date: Thu May 31 22:04:22 2018
New Revision: 261042

URL: https://gcc.gnu.org/viewcvs?rev=261042=gcc=rev
Log:
PR target/85591
* config/i386/cpuinfo.c (get_amd_cpu): Return
AMDFAM15H_BDVER2 for AMDFAM15H model 0x2.


Modified:
branches/gcc-8-branch/libgcc/ChangeLog
branches/gcc-8-branch/libgcc/config/i386/cpuinfo.c

[Bug middle-end/78809] Inline strcmp with small constant strings

[qinzhao at gcc dot gnu.org]

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

qinzhao at gcc dot gnu.org changed:

   What|Removed |Added

 CC||qinzhao at gcc dot gnu.org

--- Comment #35 from qinzhao at gcc dot gnu.org ---
the second part of the implementation is checked into gcc9 today as:

https://gcc.gnu.org/viewcvs/gcc?limit_changes=0=revision=261039

[Bug tree-optimization/83819] [meta-bug] missing strlen optimizations

[qinzhao at gcc dot gnu.org]

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

Bug 83026 Summary: missing strlen optimization for strcmp of unequal strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83026

   What|Removed |Added

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

[Bug tree-optimization/83026] missing strlen optimization for strcmp of unequal strings

[qinzhao at gcc dot gnu.org]

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

qinzhao at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #6 from qinzhao at gcc dot gnu.org ---
the change is in trunk, I am closing this bug.

[Bug tree-optimization/83026] missing strlen optimization for strcmp of unequal strings

[qinzhao at gcc dot gnu.org]

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

qinzhao at gcc dot gnu.org changed:

   What|Removed |Added

 CC||qinzhao at gcc dot gnu.org

--- Comment #5 from qinzhao at gcc dot gnu.org ---
the patch has been put back into trunk as revision 261039:

https://gcc.gnu.org/viewcvs/gcc?limit_changes=0=revision=261039

[Bug target/86005] [RISCV] Invalid intermixing of __atomic_* libcalls and inline atomic instruction sequences

[wilson at tuliptree dot org]

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

--- Comment #6 from Jim Wilson  ---
On Thu, 2018-05-31 at 15:07 +, foom at fuhm dot net wrote:
> (But also, why doesn't it implement __atomic_add_fetch inline?)

If you don't have atomic instructions, then we call an out-of-line
function that uses locks.

If you have atomic instructions, and it is a 32/64-bit operation, then
we inline it.

If you have atomic instructions, and it is a 8/16-bit operation, then
we call a lock free out-of-line function that uses a sequence of
instructions to implement it using 32/64-bit atomic instructions.  And
as mentioned previously, I have an unfinished prototype patch to fix
this by emitting the sequence of instructions inline.

[Bug tree-optimization/86020] Performance regression in Eigen geometry.cpp test starting with r248334

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Target||powerpc64le-linux-gnu
 CC||hubicka at gcc dot gnu.org,
   ||pthaugen at gcc dot gnu.org,
   ||segher at gcc dot gnu.org
  Known to work||7.3.0
   Target Milestone|--- |8.2
  Known to fail||8.1.0

[Bug tree-optimization/86020] Performance regression in Eigen geometry.cpp test starting with r248334

[wschmidt at gcc dot gnu.org]

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

--- Comment #1 from Bill Schmidt  ---
Created attachment 44220
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44220=edit
Source file that shows the problem

[Bug tree-optimization/86020] New: Performance regression in Eigen geometry.cpp test starting with r248333

[wschmidt at gcc dot gnu.org]

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

Bug ID: 86020
   Summary: Performance regression in Eigen geometry.cpp test
starting with r248333
   Product: gcc
   Version: 8.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wschmidt at gcc dot gnu.org
  Target Milestone: ---

GCC 8.1 has regressed by about 30% compared with GCC 7.3 on one of the Eigen
test cases when measured on Power9 hardware (powerpc64le-linux-gnu).  Similar
performance loss is seen on Power8 hardware as well.  Pat Haugen did some
bisecting and found that this began with r248334.

2017-05-22  Jan Hubicka  

* ipa-inline.c (edge_badness): Use inlined_time instead of
inline_summaries->get.

The performance difference seems to be due to a change in inlining as a result
of the above patch.  The symptom is a marked increase in stack load/store
activity.

An example occurs in one of the hottest routines: 
_ZN5Eigen8internal20generic_product_implINS_5BlockIKNS_6MatrixIfLi4ELi4ELi0ELi4ELi4EEELi3ELi3ELb0EEENS3_IfLi3ELi8ELi0ELi3ELi8EEENS_10DenseShapeES8_Li3EE5addToINS2_IS7_Li3ELi8ELb1EvRT_RKS6_RKS7_

Below is the code with GCC 8.1.0 : 
0.15 :1000b274:   lfs f7,8(r9)
0.00 :1000b278:   li  r5,2
0.00 :1000b27c:   addir4,r1,464
0.06 :1000b280:   lfs f8,4(r9)
0.09 :1000b284:   lfs f9,0(r9)
0.00 :1000b288:   lfs f0,4(r31)
0.00 :1000b28c:   addir3,r1,648
2.61 :1000b290:   lfs f10,32(r10)
0.71 :1000b294:   lfs f11,16(r10)
0.46 :1000b298:   lfs f12,0(r10)
1.99 :1000b29c:   fmuls   f10,f10,f7
4.36 :1000b2a0:   fmadds  f11,f11,f8,f10
4.20 :1000b2a4:   fmadds  f12,f12,f9,f11
4.08 :1000b2a8:   fadds   f0,f0,f12
7.67 :1000b2ac:   stfsf0,4(r31)
0.00 :1000b2b0:   bl  10004838
0.00 :1000b2b4:   nop
0.06 :1000b2b8:   ld  r5,664(r1)
0.00 :1000b2bc:   ld  r10,680(r1)
0.00 :1000b2c0:   ld  r9,512(r1)
0.00 :1000b2c4:   addir4,r1,32
0.00 :1000b2c8:   ld  r6,688(r1)
0.06 :1000b2cc:   ld  r7,696(r1)
0.00 :1000b2d0:   ld  r8,712(r1)
0.03 :1000b2d4:   ld  r0,648(r1)
0.00 :1000b2d8:   addir3,r1,1104
0.00 :1000b2dc:   ld  r11,704(r1)
0.09 :1000b2e0:   std r28,144(r1)
0.00 :1000b2e4:   std r30,152(r1)
0.00 :1000b2e8:   std r26,160(r1)
0.18 :1000b2ec:   std r5,48(r1)
0.09 :1000b2f0:   std r10,64(r1)
0.03 :1000b2f4:   ld  r5,728(r1)
0.00 :1000b2f8:   ld  r10,720(r1)
0.06 :1000b2fc:   std r9,136(r1)
0.00 :1000b300:   add r9,r9,r29
0.09 :1000b304:   std r0,32(r1)
0.46 :1000b308:   std r6,600(r1)
0.06 :1000b30c:   std r6,72(r1)
0.18 :1000b310:   std r7,608(r1)

0.09 :1000b314:   std r7,80(r1)
0.12 :1000b318:   std r11,88(r1)
0.40 :1000b31c:   std r9,120(r1)
0.09 :1000b320:   std r8,624(r1)
0.06 :1000b324:   std r8,96(r1)
0.03 :1000b328:   std r10,632(r1)
0.06 :1000b32c:   std r10,104(r1)
0.06 :1000b330:   std r5,112(r1)
0.15 :1000b334:   bl  1000a248  
The additional instructions can be seen between addresses 1000b2b8 and
1000b330. 

Below is the code for GCC 7.3.0 : 
0.16 :1000ac88:   lfs f7,8(r9)
0.04 :1000ac8c:   ld  r10,488(r1)
0.08 :1000ac90:   addir4,r1,176
0.35 :1000ac94:   lfs f8,4(r9)
0.28 :1000ac98:   lfs f9,0(r9)
0.12 :1000ac9c:   lfs f0,0(r31)
0.00 :1000aca0:   ld  r9,496(r1)
0.00 :1000aca4:   addir3,r1,1160
3.39 :1000aca8:   lfs f10,32(r8)
0.87 :1000acac:   lfs f11,16(r8)
0.83 :1000acb0:   lfs f12,0(r8)
0.32 :1000acb4:   std r10,864(r1)
0.12 :1000acb8:   std r10,776(r1)
0.04 :1000acbc:   std r9,872(r1)
0.24 :1000acc0:   std r9,784(r1)
1.93 :1000acc4:   fmuls   f10,f10,f7
4.38 :1000acc8:   fmadds  f11,f11,f8,f10
5.48 :1000accc:   fmadds  f12,f12,f9,f11
5.99 :1000acd0:   fadds   f0,f0,f12
10.25 :1000acd4:   stfsf0,0(r31)
0.00 :1000acd8:   std r7,304(r1)
0.20 :1000acdc:   std r9,224(r1)
0.00 :1000ace0:   std r21,176(r1)
0.24 :1000ace4:   std r27,192(r1)
0.00 :1000ace8:   std r23,208(r1)
0.00 :1000acec:   std r24,232(r1)
0.04 :1000acf0:   std r26,240(r1)
0.00 :1000acf4:   std r30,248(r1)
0.12 :1000acf8:   std r26,256(r1)
0.79 :1000acfc:   std  

[Bug fortran/66193] ICE for initialisation of some non-zero-sized arrays

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #16 from kargl at gcc dot gnu.org ---
test_case_pr66193_1_real.f90 and test_case_pr66193_2.integer.f90
compile and execute on trunk.

test_case_pr66193_3_diverse.f90 and test case pr66193_3_diverse_new.f90
still fail, because of the zero-sized nested array.  Problems with
nested array constructors are tracked in a different PR.  I propose
that first 2 testcases be committed to the testsuite, the 2 failing
testcase be added to the other PR, and this PR be closed.

[Bug target/85984] [8/9 Regression] ICE in create_pseudo_cfg, at dwarf2cfi.c:2874

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Author: jakub
Date: Thu May 31 19:51:50 2018
New Revision: 261038

URL: https://gcc.gnu.org/viewcvs?rev=261038=gcc=rev
Log:
PR target/85984
* bb-reorder.c (pass_partition_blocks::gate): Return false for
functions with naked attribute.

* gcc.target/i386/pr85984.c: New test.

Added:
branches/gcc-8-branch/gcc/testsuite/gcc.target/i386/pr85984.c
Modified:
branches/gcc-8-branch/gcc/ChangeLog
branches/gcc-8-branch/gcc/bb-reorder.c
branches/gcc-8-branch/gcc/testsuite/ChangeLog

[Bug target/85984] [8/9 Regression] ICE in create_pseudo_cfg, at dwarf2cfi.c:2874

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Thu May 31 19:49:54 2018
New Revision: 261037

URL: https://gcc.gnu.org/viewcvs?rev=261037=gcc=rev
Log:
PR target/85984
* bb-reorder.c (pass_partition_blocks::gate): Return false for
functions with naked attribute.

* gcc.target/i386/pr85984.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/i386/pr85984.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/bb-reorder.c
trunk/gcc/testsuite/ChangeLog

[Bug target/85591] __builtin_cpu_is() is not detecting bdver2 with Model = 0x02

[uros at gcc dot gnu.org]

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

--- Comment #4 from uros at gcc dot gnu.org ---
Author: uros
Date: Thu May 31 19:45:54 2018
New Revision: 261036

URL: https://gcc.gnu.org/viewcvs?rev=261036=gcc=rev
Log:
PR target/85591
* config/i386/cpuinfo.c (get_amd_cpu): Return
AMDFAM15H_BDVER2 for AMDFAM15H model 0x2.


Modified:
trunk/libgcc/ChangeLog
trunk/libgcc/config/i386/cpuinfo.c

[Bug libstdc++/78870] Support std::filesystem on Windows

[redi at gcc dot gnu.org]

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

--- Comment #15 from Jonathan Wakely  ---
P.S. thanks to niXman for the patch that inspired the approach used.

[Bug libstdc++/78870] Support std::filesystem on Windows

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #14 from Jonathan Wakely  ---
The Filesystem library now builds and mostly works on MinGW (for both the TS
and C++17 versions).

The library is not enabled by default for mingw targets, so you need to build
GCC with --enable-libstdcxx-filesystem-ts

If people can test and confirm it works fine for both mingw and mingw-w64 then
we can enable it by default.

[Bug libstdc++/85670] `std::filesystem` does not compile on mingw-w64

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  ---
Fixed on trunk now. See PR 78870.

[Bug libstdc++/78870] Support std::filesystem on Windows

[redi at gcc dot gnu.org]

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

--- Comment #13 from Jonathan Wakely  ---
Author: redi
Date: Thu May 31 19:20:24 2018
New Revision: 261034

URL: https://gcc.gnu.org/viewcvs?rev=261034=gcc=rev
Log:
PR libstdc++/78870 support std::filesystem on Windows

PR libstdc++/78870 support std::filesystem on Windows
* config.h.in: Regenerate.
* configure: Regenerate.
* configure.ac: Check for link, readlink and symlink.
* include/bits/fs_path.h (path::operator/=(const path&)): Move
definition out of class body.
(path::is_absolute(), path::_M_append(path)): Likewise.
(operator<<(basic_ostream, const path&)): Use std::quoted directly.
(operator>>(basic_istream, path&)): Likewise.
(u8path): Reorder definitions and fix Windows implementation.
(path::is_absolute()): Define inline and fix for Windows.
[!_GLIBCXX_FILESYSTEM_IS_WINDOWS] (path::operator/=(const path&)):
Define POSIX version inline.
(path::_M_append(path)): Define inline.
* include/experimental/bits/fs_path.h (path::is_absolute()): Move
definition out of class body.
(operator<<(basic_ostream, const path&)): Fix type of delimiter and
escape characters.
(operator>>(basic_istream, path&)): Likewise.
(path::is_absolute()): Define inline and fix for Windows.
* src/filesystem/dir-common.h (__gnu_posix): New namespace.
(__gnu_posix::char_type, __gnu_posix::DIR, __gnu_posix::dirent)
(__gnu_posix::opendir, __gnu_posix::readdir, __gnu_posix::closedir):
Define as adaptors for Windows functions/types or as
using-declarations for POSIX functions/types.
(_Dir_base, get_file_type): Qualify names to use declarations from
__gnu_posix namespace.
(_Dir_base::is_dor_or_dotdot): New helper functions.
* src/filesystem/dir.cc (_Dir, recursive_directory_iterator): Qualify
names to use declarations from __gnu_posix namespace.
* src/filesystem/ops-common.h (__gnu_posix): New nested namespace.
(__gnu_posix::open, __gnu_posix::close, __gnu_posix::stat_type)
(__gnu_posix::stat, __gnu_posix::lstat, __gnu_posix::mode_t)
(__gnu_posix::chmod, __gnu_posix::mkdir, __gnu_posix::getcwd)
(__gnu_posix::chdir, __gnu_posix::utimbuf, __gnu_posix::utime)
(__gnu_posix::rename, __gnu_posix::truncate, __gnu_posix::char_type):
Define as adaptors for Windows functions/types or as
using-declarations for POSIX functions/types.
(stat_type, do_copy_file): Qualify names to use declarations from
__gnu_posix namespace.
(do_space): Declare new function.
(make_file_type): Only use S_ISLNK if defined.
* src/filesystem/ops.cc (char_ptr, filesystem::canonical): Use
path::value_type not char.
(filesystem::copy, create_dir, filesystem::create_directory): Qualify
names to use declarations from __gnu_posix namespace.
(filesystem::create_hard_link): Check HAVE_LINK autoconf macro and
add implementation for Windows.
(filesystem::create_symlink): Check HAVE_SYMLINK autoconf macro.
(filesystem::current_path(error_code&)): Use __gnu_posix::getcwd.
[!_PC_PATH_MAX]: Don't use pathconf.
[PATH_MAX]: Use if defined.
(filesystem::current_path(const path&, error_code&))
(filesystem::equivalent, do_stat, filesystem::hard_link_count)
(filesystem::last_write_time, filesystem::permissions): Use names
from __gnu_posix.
(filesystem::read_symlink): Check HAVE_READLINK autoconf macro.
(filesystem::remove) [_GLIBCXX_FILESYSTEM_IS_WINDOWS]: Add
implementation for Windows.
(filesystem::rename, filesystem::resize_file): Use names from
__gnu_posix.
(filesystem::space): Use do_space.
[_GLIBCXX_FILESYSTEM_IS_WINDOWS]: Get absolute path to directory.
(filesystem::status, filesystem::symlink_status): Use names from
__gnu_posix.
(filesystem::temp_directory_path): Add implementation for Windows.
* src/filesystem/path.cc (dot): Define constant.
(path::replace_extension): Use dot.
(path::_M_find_extension): Likewise. Use path::string_type not
std::string.
(path::_M_split_cmpts): Use dot.
(filesystem_error::_M_get_what): Use u8string() not native().
* src/filesystem/std-dir.cc (_Dir, recursive_directory_iterator):
Qualify names to use declarations from __gnu_posix namespace.
* src/filesystem/std-ops.cc (filesystem::absolute(const path&)): Use
correct error_code.
(filesystem::absolute(const path&, error_code&)): Add implementation
for Windows.
(char_ptr, filesystem::canonical): Use path::value_type not char.
(do_copy_file): Use names from __gnu_posix.
[_GLIBCXX_FILESYSTEM_IS_WINDOWS]: Do not use 

[Bug libstdc++/86015] Better handling of iterator distances

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-05-31
  Component|c++ |libstdc++
 Ever confirmed|0   |1
   Severity|normal  |enhancement

--- Comment #3 from Jonathan Wakely  ---
I think all those _Distance types comes from
iterator_traits::difference_type, and by my reading of the standard an
iterator's difference type is required to be a signed integer type.

But it seems harmless to make the suggested change, it won't affect any valid
code.

[Bug target/86019] Unref implementation using atomic_thread_fence generates worse code on x86-64 in gcc 8.1 than 7.3

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Target||x86_64
URL||missed-optimization
  Component|c++ |target

--- Comment #1 from Andrew Pinski  ---
I suspect memory_order_acquire is being treated as a compiler memory barrier
and that is causing an empty basic block (it is not truly empty).

[Bug c++/86019] New: Unref implementation using atomic_thread_fence generates worse code on x86-64 in gcc 8.1 than 7.3

[klempner at imsanet dot org]

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

Bug ID: 86019
   Summary: Unref implementation using atomic_thread_fence
generates worse code on x86-64 in gcc 8.1 than 7.3
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: klempner at imsanet dot org
  Target Milestone: ---

See https://godbolt.org/g/Tu80RI (specifically the godegen for do_unref3())

Simplified version: https://godbolt.org/g/Xbn6n6

This is the unref half of a refcount implementation:

#include 

std::atomic refcount;

bool do_unref() {
int old_count = refcount.fetch_sub(1, std::memory_order_release);
if (old_count == 1) {
std::atomic_thread_fence(std::memory_order_acquire);
}
return old_count == 1;
}

In particular, unref needs release semantics on every decrement, but only needs
acquire semantics on the last decrement.

std::atomic_thread_fence(std::memory_order_acquire) should be (approximately) a
no-op on x86.

gcc 7.3 generated the right code here:

do_unref():
lock subDWORD PTR refcount[rip], 1
seteal
ret

gcc 8.1 generates a branch choosing between duplicate codepaths based on
whether old_count == 1:

do_unref():
mov eax, -1
lock xadd   DWORD PTR refcount[rip], eax
cmp eax, 1
je  .L4
cmp eax, 1
seteal
ret
.L4:
cmp eax, 1
seteal
ret

It also appears to fail to optimize based on decrementing the constant value 1.

[Bug c++/86018] New: Incorrect unused warning for int passed by reference to lambda

[rconde01 at hotmail dot com]

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

Bug ID: 86018
   Summary: Incorrect unused warning for int passed by reference
to lambda
   Product: gcc
   Version: 8.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rconde01 at hotmail dot com
  Target Milestone: ---

https://godbolt.org/g/XLjyWM

When compiled with: -std=c++14 -Wall -Wextra

#include 

typedef void(*TheFP)(int & e);

class MyObject
{
public:
void DoSomething(TheFP)
{
}
};

void myFunc()
{
MyObject m;

m.DoSomething
(
[](auto i)
{
i = 5; 
}
);
}



gives:

In instantiation of 'myFunc():: [with auto:1 = int]':

19:18:   required by substitution of 'template
myFunc()operator decltype (((const
myFunc()::*)((const myFunc()::*
const)0))->operator()(static_cast())) (*)(auto:1)() const
[with auto:1 = int&]'

23:5:   required from here

19:17: warning: parameter 'i' set but not used [-Wunused-but-set-parameter]

 [](auto i)

~^


The workaround is to change it to:

void myFunc()
{
MyObject m;

m.DoSomething
(
[](auto & i)
{
i = 5; 
}
);
}

[Bug c++/86015] Better handling of iterator distances

[joshua.r.marshall.1991 at gmail dot com]

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

--- Comment #2 from Josh Marshall  ---
There are also lines close by which call std::distance() which need to be
similarly wrapped.

[Bug c/85931] -Wsizeof-pointer-memaccess for strncpy with size of source

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #3 from Martin Sebor  ---
Patch: https://gcc.gnu.org/ml/gcc-patches/2018-05/msg01698.html

[Bug tree-optimization/86017] multiple consecutive calls to bzero/memset not merged

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||missed-optimization
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=86010

--- Comment #1 from Martin Sebor  ---
See also bug 86010 for a related missed optimization (that one is a regression
while this bug does not appear to be).

[Bug tree-optimization/86017] New: multiple consecutive calls to bzero/memset not merged

[msebor at gcc dot gnu.org]

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

Bug ID: 86017
   Summary: multiple consecutive calls to bzero/memset not merged
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

Even though the two functions defined in the test case below are equivalent,
GCC emits considerably less efficient code the one with multiple calls to
memset than for the one with just a single call.  Clang emits the same
optimally efficient code for both.

$ cat b.c && gcc -O2 -S -Wall -Wextra -fdump-tree-optimized=/dev/stdout
-o/dev/stdout b.c
void f (void*);

void g (void)
{
  char a[8];
  __builtin_memset (a, 0, 8);

  f (a);
}

void h (void)
{
  char a[8];
  __builtin_memset (a, 0, 1);
  __builtin_memset (a + 1, 0, 1);
  __builtin_memset (a + 2, 0, 1);
  __builtin_memset (a + 3, 0, 1);
  __builtin_memset (a + 4, 0, 1);
  __builtin_memset (a + 5, 0, 1);
  __builtin_memset (a + 6, 0, 1);
  __builtin_memset (a + 7, 0, 1);

  f (a);
}

.file   "b.c"
.text

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

g ()
{
  char a[8];

   [local count: 1073741825]:
  __builtin_memset (, 0, 8);
  f ();
  a ={v} {CLOBBER};
  return;

}


.p2align 4,,15
.globl  g
.type   g, @function
g:
.LFB0:
.cfi_startproc
subq$24, %rsp
.cfi_def_cfa_offset 32
movq$0, 8(%rsp)
leaq8(%rsp), %rdi
callf
addq$24, %rsp
.cfi_def_cfa_offset 8
ret
.cfi_endproc
.LFE0:
.size   g, .-g

;; Function h (h, funcdef_no=1, decl_uid=1962, cgraph_uid=1, symbol_order=1)

h ()
{
  char a[8];

   [local count: 1073741825]:
  MEM[(void *)] = 0;
  __builtin_memset ([(void *) + 1B], 0, 1);
  __builtin_memset ([(void *) + 2B], 0, 1);
  __builtin_memset ([(void *) + 3B], 0, 1);
  __builtin_memset ([(void *) + 4B], 0, 1);
  __builtin_memset ([(void *) + 5B], 0, 1);
  __builtin_memset ([(void *) + 6B], 0, 1);
  __builtin_memset ([(void *) + 7B], 0, 1);
  f ();
  a ={v} {CLOBBER};
  return;

}


.p2align 4,,15
.globl  h
.type   h, @function
h:
.LFB1:
.cfi_startproc
subq$24, %rsp
.cfi_def_cfa_offset 32
leaq8(%rsp), %rdi
movb$0, 8(%rsp)
movb$0, 9(%rsp)
movb$0, 10(%rsp)
movb$0, 11(%rsp)
movb$0, 12(%rsp)
movb$0, 13(%rsp)
movb$0, 14(%rsp)
movb$0, 15(%rsp)
callf
addq$24, %rsp
.cfi_def_cfa_offset 8
ret
.cfi_endproc
.LFE1:
.size   h, .-h
.ident  "GCC: (GNU) 8.1.1 20180522"
.section.note.GNU-stack,"",@progbits

[Bug middle-end/82063] issues with arguments enabled by -Wall

[msebor at gcc dot gnu.org]

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

--- Comment #8 from Martin Sebor  ---
Author: msebor
Date: Thu May 31 17:04:43 2018
New Revision: 261030

URL: https://gcc.gnu.org/viewcvs?rev=261030=gcc=rev
Log:
PR c/82063 - issues with arguments enabled by -Wall

gcc/c-family/ChangeLog:

PR c/82063
* c.opt (-Wno-alloc-size-larger-than): New option.
* doc/invoke.texi (-Walloc-size-larger-than): Update.

gcc/ChangeLog:

PR c/82063
* calls.c (alloc_max_size): Correct a logic error/typo.
Treat excessive arguments as infinite.  Warn for invalid arguments.

gcc/testsuite/ChangeLog:

PR c/82063
* gcc.dg/Walloc-size-larger-than-1.c: New test.
* gcc.dg/Walloc-size-larger-than-10.c: New test.
* gcc.dg/Walloc-size-larger-than-11.c: New test.
* gcc.dg/Walloc-size-larger-than-12.c: New test.
* gcc.dg/Walloc-size-larger-than-13.c: New test.
* gcc.dg/Walloc-size-larger-than-14.c: New test.
* gcc.dg/Walloc-size-larger-than-15.c: New test.
* gcc.dg/Walloc-size-larger-than-16.c: New test.
* gcc.dg/Walloc-size-larger-than-17.c: New test.
* gcc.dg/Walloc-size-larger-than-2.c: New test.
* gcc.dg/Walloc-size-larger-than-3.c: New test.
* gcc.dg/Walloc-size-larger-than-4.c: New test.
* gcc.dg/Walloc-size-larger-than-5.c: New test.
* gcc.dg/Walloc-size-larger-than-6.c: New test.
* gcc.dg/Walloc-size-larger-than-7.c: New test.
* gcc.dg/Walloc-size-larger-than-8.c: New test.
* gcc.dg/Walloc-size-larger-than-9.c: New test.
* gcc.dg/Walloc-size-larger-than.c: New test.


Added:
trunk/gcc/testsuite/gcc.dg/Walloc-size-larger-than-1.c
trunk/gcc/testsuite/gcc.dg/Walloc-size-larger-than-10.c
trunk/gcc/testsuite/gcc.dg/Walloc-size-larger-than-11.c
trunk/gcc/testsuite/gcc.dg/Walloc-size-larger-than-12.c
trunk/gcc/testsuite/gcc.dg/Walloc-size-larger-than-13.c
trunk/gcc/testsuite/gcc.dg/Walloc-size-larger-than-14.c
trunk/gcc/testsuite/gcc.dg/Walloc-size-larger-than-15.c
trunk/gcc/testsuite/gcc.dg/Walloc-size-larger-than-16.c
trunk/gcc/testsuite/gcc.dg/Walloc-size-larger-than-17.c
trunk/gcc/testsuite/gcc.dg/Walloc-size-larger-than-2.c
trunk/gcc/testsuite/gcc.dg/Walloc-size-larger-than-3.c
trunk/gcc/testsuite/gcc.dg/Walloc-size-larger-than-4.c
trunk/gcc/testsuite/gcc.dg/Walloc-size-larger-than-5.c
trunk/gcc/testsuite/gcc.dg/Walloc-size-larger-than-6.c
trunk/gcc/testsuite/gcc.dg/Walloc-size-larger-than-7.c
trunk/gcc/testsuite/gcc.dg/Walloc-size-larger-than-8.c
trunk/gcc/testsuite/gcc.dg/Walloc-size-larger-than-9.c
trunk/gcc/testsuite/gcc.dg/Walloc-size-larger-than.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c.opt
trunk/gcc/calls.c
trunk/gcc/doc/invoke.texi
trunk/gcc/testsuite/ChangeLog

[Bug testsuite/86016] New: New tests for r260978 report excess errors

[seurer at gcc dot gnu.org]

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

Bug ID: 86016
   Summary: New tests for r260978 report excess errors
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

Some of the new tests are reporting excess errors like this:

# of expected passes14
# of unexpected failures7
FAIL: gcc.dg/noncompile/pr55976-1.c   -O0  (test for excess errors)
FAIL: gcc.dg/noncompile/pr55976-1.c   -O1  (test for excess errors)
FAIL: gcc.dg/noncompile/pr55976-1.c   -O2  (test for excess errors)
FAIL: gcc.dg/noncompile/pr55976-1.c   -O3 -g  (test for excess errors)
FAIL: gcc.dg/noncompile/pr55976-1.c   -Os  (test for excess errors)
FAIL: gcc.dg/noncompile/pr55976-1.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  (test for excess errors)
FAIL: gcc.dg/noncompile/pr55976-1.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  (test for excess errors)


spawn -ignore SIGHUP /home/seurer/gcc/build/gcc-test2/gcc/xgcc
-B/home/seurer/gcc/build/gcc-test2/gcc/
/home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/noncompile/pr55976-1.c
-fno-diagnostics-show-caret -fdiagnostics-color=never -O0 -Werror=return-type
-S -o pr55976-1.s
/home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/noncompile/pr55976-1.c: In
function 't':
/home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/noncompile/pr55976-1.c:7:20:
error: 'return' with a value, in function returning void [-Werror=return-type]
/home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/noncompile/pr55976-1.c:7:6:
note: declared here
/home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/noncompile/pr55976-1.c: In
function 'b':
/home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/noncompile/pr55976-1.c:8:12:
error: 'return' with no value, in function returning non-void
[-Werror=return-type]
/home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/noncompile/pr55976-1.c:8:5:
note: declared here
cc1: some warnings being treated as errors
compiler exited with status 1
PASS: gcc.dg/noncompile/pr55976-1.c   -O0  function returning void (test for
errors, line 7)
PASS: gcc.dg/noncompile/pr55976-1.c   -O0  function returning non-void (test
for errors, line 8)
FAIL: gcc.dg/noncompile/pr55976-1.c   -O0  (test for excess errors)
Excess errors:
cc1: some warnings being treated as errors

[Bug lto/68791] Segfault during link/compilation after update.

[dcb314 at hotmail dot com]

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

--- Comment #7 from David Binderman  ---
This bug seems to have been present since some revision before 260047.

[Bug c++/86015] Better handling of iterator distances

[joshua.r.marshall.1991 at gmail dot com]

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

--- Comment #1 from Josh Marshall  ---
It looks like wrappings would be applicable at the following lines:

296, 297, 2438, 2439, 2494, 2495

using
https://github.com/gcc-mirror/gcc/blob/master/libstdc%2B%2B-v3/include/bits/stl_algo.h
as reference.

[Bug lto/68791] Segfault during link/compilation after update.

[dcb314 at hotmail dot com]

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

--- Comment #6 from David Binderman  ---
Created attachment 44219
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44219=edit
x86_64 object module

[Bug lto/68791] Segfault during link/compilation after update.

[dcb314 at hotmail dot com]

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

David Binderman  changed:

   What|Removed |Added

 CC||dcb314 at hotmail dot com

--- Comment #5 from David Binderman  ---
For this command line:

~/gcc/results.260789.ubsan/bin/gcc -flto acct.o

I get this:

$ source /tmp/11
../../trunk/gcc/lto-streamer.h:1210:1: runtime error: member access within null
pointer of type 'struct lto_in_decl_state'
lto1: internal compiler error: Segmentation fault
0x25937cf crash_signal
../../trunk/gcc/toplev.c:325
0x1cf8601 lto_file_decl_data_get_var_decl
../../trunk/gcc/lto-streamer.h:1210
0x1cf8601 lto_input_tree_ref(lto_input_block*, data_in*, function*, LTO_tags)
../../trunk/gcc/lto-streamer-in.c:364
0x1cf916d lto_input_tree_1(lto_input_block*, data_in*, LTO_tags, unsigned int)
../../trunk/gcc/lto-streamer-in.c:1489

Object file acct.o attached.

[Bug target/85993] config/sh/sh.c:10878: suspicious if .. else chain

[olegendo at gcc dot gnu.org]

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

Oleg Endo  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-05-31
 Ever confirmed|0   |1

--- Comment #3 from Oleg Endo  ---
(In reply to David Binderman from comment #0)
> config/sh/sh.c:10878:12: warning: duplicated ‘if’ condition
> [-Wduplicated-cond]
> 
> Source code is
> 
>  else if (scratch0 != scratch1)
> {
>   emit_move_insn (scratch1, GEN_INT (vcall_offset));
>   emit_insn (gen_add2_insn (scratch0, scratch1));
>   offset_addr = scratch0;
> }
> 
> but earlier is code
> 
>  else if (scratch0 != scratch1)
> {
>   /* scratch0 != scratch1, and we have indexed loads.  Get better
>  schedule by loading the offset into r1 and using an indexed
>  load - then the load of r1 can issue before the load from
>  (this_rtx + delta) finishes.  */
>   emit_move_insn (scratch1, GEN_INT (vcall_offset));
>   offset_addr = gen_rtx_PLUS (Pmode, scratch0, scratch1);
> }
> 
> Interestingly, the two blocks of code in the ifs aren't the same.

The line 10864 used to be:

  else if (! TARGET_SH5 && scratch0 != scratch1)

and I chopped it off to be 

  else if (scratch0 != scratch1)

when removing support for SH5.  I haven't noticed that the 2nd else if block
became unreachable.  It can be removed.

[Bug target/85829] [8/9 Regression] PARTIAL_REG_DEPENDENCY and MOVX were disabled for Haswell and newer processors

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #8 from H.J. Lu  ---
Fixed for GCC 9 and GCC 8.2.

[Bug c++/86015] New: Better handling of iterator distances

[joshua.r.marshall.1991 at gmail dot com]

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

Bug ID: 86015
   Summary: Better handling of iterator distances
   Product: gcc
   Version: 7.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: joshua.r.marshall.1991 at gmail dot com
  Target Milestone: ---

I'm writing containers for containers to track usage and operations for
performance metrics.  I've found it impossible to allow implicit conversion
from integer types to a distance object without introducing conflicting
resolutions for all basic math operations.  It occasionally leads to errors
like the following:

/usr/bin/../lib/gcc/x86_64-linux-gnu/7.3.0/../../../../include/c++/7.3.0/bits/stl_algo.h:2495:17:
error: no viable conversion from 'int' to
  'distance_counter<__gnu_cxx::__normal_iterator > >, long>'
  _Distance __len22 = 0;

In this instance, I think the best way to handle this is to change

stl_algo.h:2495: _Distance __len22 = 0;

to 

stl_algo.h:2495: _Distance __len22 = _Distance(0);

Am I just doing something dumb, or is this reasonable?

[Bug target/85829] [8/9 Regression] PARTIAL_REG_DEPENDENCY and MOVX were disabled for Haswell and newer processors

[hjl at gcc dot gnu.org]

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

--- Comment #7 from hjl at gcc dot gnu.org  ---
Author: hjl
Date: Thu May 31 15:37:22 2018
New Revision: 261028

URL: https://gcc.gnu.org/viewcvs?rev=261028=gcc=rev
Log:
x86: Re-enable partial_reg_dependency and movx for Haswell

r254152 disabled partial_reg_dependency and movx for Haswell and newer
Intel processors.  r258972 restored them for skylake-avx512.  For Haswell,
movx improves performance.  But partial_reg_stall may be better than
partial_reg_dependency in theory.  We will investigate performance impact
of partial_reg_stall vs partial_reg_dependency on Haswell for GCC 9.  In
the meantime, this patch restores both partial_reg_dependency and mox for
Haswell in GCC 8.

On Haswell, improvements for EEMBC benchmarks with

-mtune-ctrl=movx,partial_reg_dependency -Ofast -march=haswell

vs

-Ofast -mtune=haswell

are

automotive
=
  aifftr01 (default) - goodperf: Runtime improvement of   2.6% (time).
  aiifft01 (default) - goodperf: Runtime improvement of   2.2% (time).

networking
=
  ip_pktcheckb1m (default) - goodperf: Runtime improvement of   3.8% (time).
  ip_pktcheckb2m (default) - goodperf: Runtime improvement of   5.2% (time).
  ip_pktcheckb4m (default) - goodperf: Runtime improvement of   4.4% (time).
  ip_pktcheckb512k (default) - goodperf: Runtime improvement of   4.2% (time).

telecom
=
  fft00data_1 (default) - goodperf: Runtime improvement of   8.4% (time).
  fft00data_2 (default) - goodperf: Runtime improvement of   8.6% (time).
  fft00data_3 (default) - goodperf: Runtime improvement of   9.0% (time).

PR target/85829
* config/i386/x86-tune.def: Re-enable partial_reg_dependency
and movx for Haswell.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/x86-tune.def

[Bug target/86005] [RISCV] Invalid intermixing of __atomic_* libcalls and inline atomic instruction sequences

[wilson at gcc dot gnu.org]

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

Jim Wilson  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-05-31
 Ever confirmed|0   |1

[Bug target/86005] [RISCV] Invalid intermixing of __atomic_* libcalls and inline atomic instruction sequences

[wilson at tuliptree dot org]

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

--- Comment #5 from Jim Wilson  ---
On Thu, 2018-05-31 at 05:40 +, asb at lowrisc dot org wrote:
> Actually I think this bug is wider in scope than I first thought. GCC
> will also
> intermix __atomic libcalls and inline instruction sequences with
> -march=rv32ia
> when values less than XLEN in size are accessed.

FYI I have a prototype patch to fix this.  I copied the subword atomic
support from the ppc port, and hacked it to work.  I haven't done the
fences yet, so it probably won't work if you have more than one thread,
but it works well enough to handle the gcc/g++ testsuites.  It also
needs some cleanup to remove more ppc specific stuff.  I don't know
when I will have time to finish it though.

[Bug target/86005] [RISCV] Invalid intermixing of __atomic_* libcalls and inline atomic instruction sequences

[foom at fuhm dot net]

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

James Y Knight  changed:

   What|Removed |Added

 CC||foom at fuhm dot net

--- Comment #4 from James Y Knight  ---
I think if RISCV wants to use out-of-line lock-free atomic helpers, it should
give those another function name (for example,
__sync_fetch_and_##OP##_##WIDTH), and provide them in libgcc.a, the same as the
other architectures which use such out-of-line helpers.

(But also, why doesn't it implement __atomic_add_fetch inline?)

Since lock-free helper functions can be linked into a process as many times as
you like without correctness issues, it's safe, and preferable, to provide them
in the static runtime lib.

That is quite unlike a potentially-locking __atomic_* function, which must
share the same lock across the whole process, and thus must have only one
implementation in a process, which is why they're provided separately by
libatomic.so.

It's not a good idea to conflate the two different things.

[Bug target/85829] [8/9 Regression] PARTIAL_REG_DEPENDENCY and MOVX were disabled for Haswell and newer processors

[hjl at gcc dot gnu.org]

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

--- Comment #5 from Sebastian Peryt  ---
I have made measurements on HSW comparing
-mtune-ctrl=movx,partial_reg_dependency -Ofast -march=haswell to -Ofast
-mtune=haswell and I see improvements on EEMBC benchmarks.

automotive
=
  aifftr01 (default) - goodperf: Runtime improvement of   2.6% (time).
  aiifft01 (default) - goodperf: Runtime improvement of   2.2% (time).

networking
=
  ip_pktcheckb1m (default) - goodperf: Runtime improvement of   3.8% (time).
  ip_pktcheckb2m (default) - goodperf: Runtime improvement of   5.2% (time).
  ip_pktcheckb4m (default) - goodperf: Runtime improvement of   4.4% (time).
  ip_pktcheckb512k (default) - goodperf: Runtime improvement of   4.2% (time).

telecom
=
  fft00data_1 (default) - goodperf: Runtime improvement of   8.4% (time).
  fft00data_2 (default) - goodperf: Runtime improvement of   8.6% (time).
  fft00data_3 (default) - goodperf: Runtime improvement of   9.0% (time).

--- Comment #6 from hjl at gcc dot gnu.org  ---
Author: hjl
Date: Thu May 31 15:02:36 2018
New Revision: 261026

URL: https://gcc.gnu.org/viewcvs?rev=261026=gcc=rev
Log:
x86: Re-enable partial_reg_dependency and movx for Haswell

r254152 disabled partial_reg_dependency and movx for Haswell and newer
Intel processors.  r258972 restored them for skylake-avx512.  For Haswell,
movx improves performance.  But partial_reg_stall may be better than
partial_reg_dependency in theory.  We will investigate performance impact
of partial_reg_stall vs partial_reg_dependency on Haswell for GCC 9.  In
the meantime, this patch restores both partial_reg_dependency and mox for
Haswell in GCC 8.

On Haswell, improvements for EEMBC benchmarks with

-mtune-ctrl=movx,partial_reg_dependency -Ofast -march=haswell

vs

-Ofast -mtune=haswell

are

automotive
=
  aifftr01 (default) - goodperf: Runtime improvement of   2.6% (time).
  aiifft01 (default) - goodperf: Runtime improvement of   2.2% (time).

networking
=
  ip_pktcheckb1m (default) - goodperf: Runtime improvement of   3.8% (time).
  ip_pktcheckb2m (default) - goodperf: Runtime improvement of   5.2% (time).
  ip_pktcheckb4m (default) - goodperf: Runtime improvement of   4.4% (time).
  ip_pktcheckb512k (default) - goodperf: Runtime improvement of   4.2% (time).

telecom
=
  fft00data_1 (default) - goodperf: Runtime improvement of   8.4% (time).
  fft00data_2 (default) - goodperf: Runtime improvement of   8.6% (time).
  fft00data_3 (default) - goodperf: Runtime improvement of   9.0% (time).

PR target/85829
* config/i386/x86-tune.def: Re-enable partial_reg_dependency
and movx for Haswell.

Modified:
branches/gcc-8-branch/gcc/ChangeLog
branches/gcc-8-branch/gcc/config/i386/x86-tune.def

[Bug c++/86000] ICE with requires statement in a non constexpr if

[gcc-bugs at oxyware dot com]

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

--- Comment #2 from Hubert Matthews  ---
template 
int f()
{
bool check = requires { 3 > 4; };
if (check) return 1;
else return 2;
}

compiles cleanly and gives the expected result.  This is essentially the same
code but with the check performed separately and stored in an intermediate
variable.

[Bug c++/86000] ICE with requires statement in a non constexpr if

[gcc-bugs at oxyware dot com]

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

--- Comment #1 from Hubert Matthews  ---
template 
int f()
{
bool check = requires { 3 > 4; };
if (check) return 1;
else return 2;
}

compiles cleanly and gives the expected result.  This is essentially the same
code but with the check performed separately and stored in an intermediate
variable.

[Bug lto/86004] [9 regression] Several lto test cases begin failing with r260963

[seurer at gcc dot gnu.org]

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

--- Comment #3 from seurer at gcc dot gnu.org ---
I tried a couple of different versions of binutils on one system where this was
occurring and it happens with binutils 2.26 but doesn't with 2.27 (and later).

[Bug lto/86004] [9 regression] Several lto test cases begin failing with r260963

[seurer at gcc dot gnu.org]

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

--- Comment #2 from seurer at gcc dot gnu.org ---
Sorry about that.  The actual complaints are about a missing plugin from the
loader.  I've never seen anything like that before.

gcc/testsuite/gfortran/gfortran.log:/usr/bin/ld: /tmp/ccxyE8Zx.lto.o: plugin
needed to handle lto object

seurer@genoa:~/gcc/build/gcc-trunk$ ld --version
GNU ld (GNU Binutils for Ubuntu) 2.26.1

I don't see this problem on a newer system that has binutils version 2.30 on it
so this is probably a problem with binutils.

[Bug libstdc++/85951] make_signed and make_unsigned are incorrect for wchar_t, char16_t, and char32_t

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
Fixed for trunk and 8.2 so far.

[Bug middle-end/85879] [6/7/8/9 Regression] ICE in expand_debug_locations, at cfgexpand.c:5405

[cesar at gcc dot gnu.org]

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

--- Comment #4 from cesar at gcc dot gnu.org ---
Author: cesar
Date: Thu May 31 14:10:10 2018
New Revision: 261025

URL: https://gcc.gnu.org/viewcvs?rev=261025=gcc=rev
Log:
Fix PR middle-end/85879

gcc/
* gimplify.c (gimplify_adjust_omp_clauses): Add 'remove = true'
when emitting error on private/firstprivate reductions.
* omp-low.c (lower_omp_target): Avoid reference-type processing
on pointers for firstprivate clause.

gcc/testsuite/
* gfortran.dg/goacc/pr77371-1.f90: New test.
* gfortran.dg/goacc/pr77371-2.f90: New test.
* gfortran.dg/goacc/pr85879.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/goacc/pr77371-1.f90
trunk/gcc/testsuite/gfortran.dg/goacc/pr77371-2.f90
trunk/gcc/testsuite/gfortran.dg/goacc/pr85879.f90
Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimplify.c
trunk/gcc/omp-low.c
trunk/gcc/testsuite/ChangeLog

[Bug libstdc++/85951] make_signed and make_unsigned are incorrect for wchar_t, char16_t, and char32_t

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
Author: redi
Date: Thu May 31 14:07:22 2018
New Revision: 261024

URL: https://gcc.gnu.org/viewcvs?rev=261024=gcc=rev
Log:
PR libstdc++/85951 for make_signed/make_unsigned for character types

Because the wide character types are neither signed integer types nor
unsigned integer types they need to be transformed to an integral type
of the correct size and the lowest rank (which is not necessarily the
underlying type). Reuse the helpers for enumeration types to select the
correct integer.

PR libstdc++/85951
* include/std/type_traits [_GLIBCXX_USE_C99_STDINT_TR1]: Do not define
uint_least16_t and uint_least32_t.
(__make_unsigned): Define unconditionally.
(__make_unsigned, __make_unsigned): Define.
(__make_signed, __make_signed)
(__make_signed)): Define unconditionally.
* testsuite/20_util/make_signed/requirements/typedefs-3.cc: Check
wchar_t, char16_t and char32_t are transformed correctly.
* testsuite/20_util/make_signed/requirements/typedefs_neg.cc: Adjust
dg-error lineno.
* testsuite/20_util/make_unsigned/requirements/typedefs-3.cc: Check
wchar_t, char16_t and char32_t are transformed correctly.
* testsuite/20_util/make_unsigned/requirements/typedefs_neg.cc: Adjust
dg-error lineno.

Modified:
branches/gcc-8-branch/libstdc++-v3/ChangeLog
branches/gcc-8-branch/libstdc++-v3/include/std/type_traits
   
branches/gcc-8-branch/libstdc++-v3/testsuite/20_util/make_signed/requirements/typedefs-3.cc
   
branches/gcc-8-branch/libstdc++-v3/testsuite/20_util/make_signed/requirements/typedefs_neg.cc
   
branches/gcc-8-branch/libstdc++-v3/testsuite/20_util/make_unsigned/requirements/typedefs-3.cc
   
branches/gcc-8-branch/libstdc++-v3/testsuite/20_util/make_unsigned/requirements/typedefs_neg.cc

[Bug libstdc++/85670] `std::filesystem` does not compile on mingw-w64

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  ---
All those issues will be fixed later today.

[Bug c++/85254] boost::is_final does not work for template types

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
I hoped this would fix it, but it didn't:

--- a/gcc/cp/semantics.c
+++ b/gcc/cp/semantics.c
@@ -9010,6 +9010,7 @@ trait_expr_value (cp_trait_kind kind, tree type1, tree
type2)
   return type_code1 == ENUMERAL_TYPE;

 case CPTK_IS_FINAL:
+  type1 = TYPE_MAIN_VARIANT (type1);
   return CLASS_TYPE_P (type1) && CLASSTYPE_FINAL (type1);

 case CPTK_IS_LITERAL_TYPE:

[Bug libstdc++/85670] `std::filesystem` does not compile on mingw-w64

[development at jordi dot vilar.cat]

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

Jordi Vilar  changed:

   What|Removed |Added

 CC||development at jordi dot 
vilar.cat

--- Comment #4 from Jordi Vilar  ---
No only operator != is referenced (line 237) before it is declared (line 550).
Also __is_encoded_char is instantiated (line 412) before it is specialized
(line 511) via the constructor (line 180). In both cases, it only happens if
the _GLIBCXX_FILESYSTEM_IS_WINDOWS is defined. And finally, both overloads of
u8path must be introduced in the reversed order.

I managed to compile just #include , but then it fails with
 as it is not able to open file streams with a path object (it looks
like it lacks a constructor with const wchar_t*)

[Bug fortran/85983] ICE in check_dtio_interface1, at fortran/interface.c:4748

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-05-31
 CC||jvdelisle at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Confirmed from 7.3.0 up to trunk (9.0).

[Bug fortran/85982] ICE in resolve_component, at fortran/resolve.c:13696

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code
   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-05-31
 CC||foreese at gcc dot gnu.org
   Target Milestone|--- |6.5
 Ever confirmed|0   |1

--- Comment #2 from Dominique d'Humieres  ---
Confirmed from 6.4.0 up to trunk (9.0).

[Bug libstdc++/86013] std::vector::shrink_to_fit() could sometimes use realloc()

[jan.kratochvil at redhat dot com]

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

--- Comment #2 from Jan Kratochvil  ---
You apparently know better all the pitfalls, I just got shocked that a
squeezing shrink_to_fit() does a copy.

[Bug fortran/86006] compile time error generic type bound procedure

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2018-05-31
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
I get the error with at least 4.8 up to trunk (9.0).

> From my understanding this should work.

Where do you expect the ambiguity between

Class(*), Intent(Out), Pointer :: TSOut

and

Integer*8, Intent(In) :: ISPos

to be resolved?

> It also compiles without error with other compilers (e.g. ifort)

Did you use any option enforcing the compliance to some Fortran standard?

[Bug libstdc++/85951] make_signed and make_unsigned are incorrect for wchar_t, char16_t, and char32_t

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
Author: redi
Date: Thu May 31 12:18:19 2018
New Revision: 261023

URL: https://gcc.gnu.org/viewcvs?rev=261023=gcc=rev
Log:
PR libstdc++/85951 for make_signed/make_unsigned for character types

Because the wide character types are neither signed integer types nor
unsigned integer types they need to be transformed to an integral type
of the correct size and the lowest rank (which is not necessarily the
underlying type). Reuse the helpers for enumeration types to select the
correct integer.

The refactoring of __make_unsigned_selector and __make_signed_selector
slightly reduces the number of template instantiations and so reduces
memory usage.

PR libstdc++/85951
* include/std/type_traits [_GLIBCXX_USE_C99_STDINT_TR1]: Do not define
uint_least16_t and uint_least32_t.
(__make_unsigned): Define unconditionally.
(__make_unsigned_selector<_Tp, true, false>): Remove intermediate
typedefs.
(__make_unsigned_selector_base): New type to provide helper templates.
(__make_unsigned_selector<_Tp, false, true>): Reimplement using
__make_unsigned_selector_base helpers.
(__make_unsigned, __make_unsigned): Define.
(__make_signed_selector<_Tp, true, false>): Remove intermediate
typedefs.
(__make_signed, __make_signed)
(__make_signed)): Define unconditionally.
* testsuite/20_util/make_signed/requirements/typedefs-3.cc: Check
wchar_t, char16_t and char32_t are transformed correctly.
* testsuite/20_util/make_signed/requirements/typedefs_neg.cc: Adjust
dg-error lineno.
* testsuite/20_util/make_unsigned/requirements/typedefs-3.cc: Check
wchar_t, char16_t and char32_t are transformed correctly.
* testsuite/20_util/make_unsigned/requirements/typedefs_neg.cc: Adjust
dg-error lineno.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/std/type_traits
trunk/libstdc++-v3/testsuite/20_util/make_signed/requirements/typedefs-3.cc
   
trunk/libstdc++-v3/testsuite/20_util/make_signed/requirements/typedefs_neg.cc
   
trunk/libstdc++-v3/testsuite/20_util/make_unsigned/requirements/typedefs-3.cc
   
trunk/libstdc++-v3/testsuite/20_util/make_unsigned/requirements/typedefs_neg.cc

[Bug pch/86007] precompiled header on bdver2 with -march=native triggers a "created and used with differing settings of '-mlwp'" warning, intermittently

[stefantalpalaru at yahoo dot com]

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

--- Comment #1 from Ștefan Talpalaru  ---
The patch that fixes #85591 doesn't fix this problem.

[Bug target/85591] __builtin_cpu_is() is not detecting bdver2 with Model = 0x02

[stefantalpalaru at yahoo dot com]

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

--- Comment #3 from Ștefan Talpalaru  ---
I applied the patch to gcc-8.1.0 and it fixes the problem on my CPU.

[Bug libstdc++/86013] std::vector::shrink_to_fit() could sometimes use realloc()

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
(In reply to Jan Kratochvil from comment #0)
> std::vector::shrink_to_fit() when reducing the size it still calls
> new()+copy.
> It could use realloc() when the objects are trivially copyable resulting in
> no copy during size reduction.

In general it can't. It's only valid to do that when we know that the allocator
obtained memory from malloc, which we can't know for the default new_allocator
(users could have replaced operator new to get memory from somewhere else). It
would be OK for malloc_allocator only.

The only reliable way to get realloc-like behaviour is by extending the
allocator API to cover it.

> Maybe it could even always call realloc() for size reduction of any type of
> objects and just assert the returned pointer did not change.

That suggestion terrifies me.

[Bug middle-end/82089] emit_cstore sign-extends BImode result for STORE_FLAG_VALUE == 1

[vries at gcc dot gnu.org]

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

--- Comment #6 from Tom de Vries  ---
(In reply to Andrew Stubbs from comment #5)
> Any reason not to get this committed?

No, this should get committed.

This should either:
- be fixed as part of upstreaming the gcn port, or
- we can trigger the problem on bfin using the afore-mentioned trigger patch,
  and test that in combination with the fix, and prove that there are no
  regressions compared a vanilla bfin build and test, and see it this level
  of testing is acceptable for a middle-end maintainer.

[Bug sanitizer/86012] [7/8/9 Regression] libsanitizer build failure on sparc64-linux-gnu

[doko at gcc dot gnu.org]

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

Matthias Klose  changed:

   What|Removed |Added

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

--- Comment #4 from Matthias Klose  ---
fixed.

[Bug target/86014] [AArch64] missed LDP optimization

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-05-31
 Ever confirmed|0   |1

--- Comment #1 from ktkachov at gcc dot gnu.org ---
Confirmed.

[Bug target/86014] New: [AArch64] missed LDP optimization

[clyon at gcc dot gnu.org]

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

Bug ID: 86014
   Summary: [AArch64] missed LDP optimization
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: clyon at gcc dot gnu.org
  Target Milestone: ---

After r260952 (Improve LDP/STP generation that requires a base register),

I noticed that the new test ldp_stp_10.c fails in ILP32 mode:
FAIL:gcc.target/aarch64/ldp_stp_10.c scan-assembler-times
ldp\tw[0-9]+, w[0-9]+,  2
FAIL:gcc.target/aarch64/ldp_stp_10.c scan-assembler-times
ldp\tx[0-9]+, x[0-9]+,  2

Kyrill thinks it's a missed-optimization:
This is because the register allocation is such that the last load in the
sequence clobbers the address register like so:
...
ldr w0, [x2, 1600]
ldr w1, [x2, 2108]
ldr w3, [x2, 1604]
ldr w2, [x2, 2112] //<<--- x2 is an address and a destination
...

The checks in aarch64_operands_adjust_ok_for_ldpstp bail out for this case.
I believe as long as w2 is loaded in the second/last LDP pair that this
optimisation generates
and the address is not a writeback address (as we are guaranteed in this
context) then it should
be safe to form the LDP pairs.

[Bug sanitizer/86012] [7/8/9 Regression] libsanitizer build failure on sparc64-linux-gnu

[doko at gcc dot gnu.org]

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

--- Comment #3 from Matthias Klose  ---
Author: doko
Date: Thu May 31 09:59:35 2018
New Revision: 260992

URL: https://gcc.gnu.org/viewcvs?rev=260992=gcc=rev
Log:
2018-05-31  Matthias Klose  

PR sanitizer/86012
* sanitizer_common/sanitizer_platform_limits_posix.cc: Define
SIZEOF_STRUCT_USTAT for 32bit sparc.

Modified:
branches/gcc-7-branch/libsanitizer/ChangeLog
   
branches/gcc-7-branch/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc

[Bug sanitizer/86012] [7/8/9 Regression] libsanitizer build failure on sparc64-linux-gnu

[doko at gcc dot gnu.org]

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

--- Comment #2 from Matthias Klose  ---
Author: doko
Date: Thu May 31 09:58:32 2018
New Revision: 260991

URL: https://gcc.gnu.org/viewcvs?rev=260991=gcc=rev
Log:
2018-05-31  Matthias Klose  

PR sanitizer/86012
* sanitizer_common/sanitizer_platform_limits_posix.cc: Define
SIZEOF_STRUCT_USTAT for 32bit sparc.

Modified:
branches/gcc-8-branch/libsanitizer/ChangeLog
   
branches/gcc-8-branch/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc

[Bug sanitizer/86012] [7/8/9 Regression] libsanitizer build failure on sparc64-linux-gnu

[doko at gcc dot gnu.org]

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

--- Comment #1 from Matthias Klose  ---
Author: doko
Date: Thu May 31 09:57:33 2018
New Revision: 260990

URL: https://gcc.gnu.org/viewcvs?rev=260990=gcc=rev
Log:
2018-05-31  Matthias Klose  

PR sanitizer/86012
* sanitizer_common/sanitizer_platform_limits_posix.cc: Define
SIZEOF_STRUCT_USTAT for 32bit sparc.

Modified:
trunk/libsanitizer/ChangeLog
trunk/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc

[Bug libstdc++/86013] New: std::vector::shrink_to_fit() could sometimes use realloc()

[jan.kratochvil at redhat dot com]

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

Bug ID: 86013
   Summary: std::vector::shrink_to_fit() could sometimes use
realloc()
   Product: gcc
   Version: 8.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jan.kratochvil at redhat dot com
  Target Milestone: ---

std::vector::shrink_to_fit() when reducing the size it still calls new()+copy.
It could use realloc() when the objects are trivially copyable resulting in no
copy during size reduction.

Maybe it could even always call realloc() for size reduction of any type of
objects and just assert the returned pointer did not change.

[Bug sanitizer/85835] libsanitizer includes unconditionally

[doko at gcc dot gnu.org]

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

Matthias Klose  changed:

   What|Removed |Added

 CC||doko at gcc dot gnu.org

--- Comment #8 from Matthias Klose  ---
see PR86012 for a build failure on sparc64.

[Bug target/86012] New: [7/8/9 Regression] libsanitizer build failure on sparc64-linux-gnu

[doko at gcc dot gnu.org]

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

Bug ID: 86012
   Summary: [7/8/9 Regression] libsanitizer build failure on
sparc64-linux-gnu
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: doko at gcc dot gnu.org
  Target Milestone: ---

The fix for PR85835 causes the build to fail on sparc64-linux-gnu in the 32bit
multilib.

../../../../../src/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc:262:2:
error: #error Unknown size of struct ustat
 #error Unknown size of struct ustat
  ^
../../../../../src/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc:264:30:
error: 'SIZEOF_STRUCT_USTAT' was not declared in this scope
   unsigned struct_ustat_sz = SIZEOF_STRUCT_USTAT;
  ^~~
make[10]: *** [Makefile:539: sanitizer_platform_limits_posix.lo] Error 1
make[10]: Leaving directory
'/<>/build/sparc64-linux-gnu/32/libsanitizer/sanitizer_common'
make[9]: *** [Makefile:472: all-recursive] Error 1

[Bug target/85591] __builtin_cpu_is() is not detecting bdver2 with Model = 0x02

[ubizjak at gmail dot com]

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

--- Comment #2 from Uroš Bizjak  ---
Created attachment 44218
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44218=edit
Proposed patch

Can someone please test the attached patch?

[Bug target/86005] [RISCV] Invalid intermixing of __atomic_* libcalls and inline atomic instruction sequences

[asb at lowrisc dot org]

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

--- Comment #3 from Alex Bradbury  ---
(In reply to Andrew Waterman from comment #2)
> I realize the documentation doesn't concur with me, but as long as gcc
> and libgcc agree on the lock-freeness of the routines, I don't see the
> harm. (wrt. rv32ia, at least.)

Yes, for RV32IA it might be allowable - assuming you're able for the compiler
to make the assumption that it knows that property of the __atomic_*
implementation and that assumption won't/can't be invalidated by linking in
another implementation which isn't lock-free.