[Bug libstdc++/81091] libstdc++ not built with large file support

[bandinfinite at gmail dot com]

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

Jc Yang  changed:

   What|Removed |Added

 CC||bandinfinite at gmail dot com

--- Comment #1 from Jc Yang  ---
This bug also affects std::filesystem when the capacity of modern storage
devices are progressing in a fast pace.
Without 64bit _FILE_OFFSET_BITS, and consider that there's no trends among the
hardware vendors to migrate to a block size larger than 4096 in the foreseeable
future, not even the fixed in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85632 can tell the user of a 32bit
system the correct size of a partition that is as large as 20TB.
I think we need this as the ultimate fix and should force it no matter whether
it is a 64bit build or not.

[Bug rtl-optimization/85645] New: ICE in maybe_record_trace_start, at dwarf2cfi.c:2348

[asolokha at gmx dot com]

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

Bug ID: 85645
   Summary: ICE in maybe_record_trace_start, at dwarf2cfi.c:2348
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: ice-checking, ice-on-invalid-code
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---
Target: powerpc-*-linux-gnu*

Created attachment 44064
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44064=edit
Testcase

gcc-9.0.0-alpha20180429 snapshot (r259749) ICEs when compiling the attached
snippet w/ -mcpu=powerpc -O1 -funroll-loops -fno-dce -fno-tree-dominator-opts
-fno-tree-fre:

% powerpc-e300c3-linux-gnu-gcc-9.0.0-alpha20180429 -mcpu=powerpc -O1
-funroll-loops -fno-dce -fno-tree-dominator-opts -fno-tree-fre -w -c p4tfcqzb.c
during RTL pass: dwarf2
p4tfcqzb.c: In function 'g7':
p4tfcqzb.c:55:1: internal compiler error: in maybe_record_trace_start, at
dwarf2cfi.c:2348
 }
 ^
0x7ce5bc maybe_record_trace_start
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20180429/work/gcc-9-20180429/gcc/dwarf2cfi.c:2348
0x7d0d16 scan_trace
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20180429/work/gcc-9-20180429/gcc/dwarf2cfi.c:2541
0x7d1487 create_cfi_notes
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20180429/work/gcc-9-20180429/gcc/dwarf2cfi.c:2694
0x7d1487 execute_dwarf2_frame
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20180429/work/gcc-9-20180429/gcc/dwarf2cfi.c:3057
0x7d1487 execute
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20180429/work/gcc-9-20180429/gcc/dwarf2cfi.c:3545

In p4tfcqzb.c.312r.dwarf2 we have:

Inconsistent CFI state!
SHOULD have:
.cfi_def_cfa 1, 96
DO have:
.cfi_def_cfa 1, 96
.cfi_register 27, 25

[Bug c/85644] New: -fstack-protector generates invalid read to %fs:0x0 on mac

[shyou...@ruby-lang.org]

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

Bug ID: 85644
   Summary: -fstack-protector generates invalid read to %fs:0x0 on
mac
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: shyou...@ruby-lang.org
  Target Milestone: ---

When -fstack-protector is passed, gcc introduces problematic %fs:0x0 reference
in a function prelude.

% echo 'int main(void) { char c[8]; }' | gcc-trunk -v -fstack-protector -xc -
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/Users/urabe.shyouhei/target/libexec/gcc/x86_64-apple-darwin15.6.0/9.0.0/lto-wrapper
Target: x86_64-apple-darwin15.6.0
Configured with:
/Users/urabe.shyouhei/data/src/github.com/gcc-mirror/gcc/configure
--prefix=/Users/urabe.shyouhei/target --program-suffix=-trunk
--enable-languages=c --disable-bootstrap
--cache-file=/Users/urabe.shyouhei/data/build/gcc/config.cache
Thread model: posix
gcc version 9.0.0 20180503 (experimental) (GCC)
COLLECT_GCC_OPTIONS='-v' '-fstack-protector' '-mmacosx-version-min=10.11.0'
'-asm_macosx_version_min=10.11' '-mtune=core2'
 /Users/urabe.shyouhei/target/libexec/gcc/x86_64-apple-darwin15.6.0/9.0.0/cc1
-quiet -v -D__DYNAMIC__ - -fPIC -quiet -dumpbase - -mmacosx-version-min=10.11.0
-mtune=core2 -auxbase - -version -fstack-protector -o
/var/folders/50/9ss08lxs5ml7kvz614tr3_wmm17741/T//ccO4in0z.s
GNU C17 (GCC) version 9.0.0 20180503 (experimental) (x86_64-apple-darwin15.6.0)
compiled by GNU C version 6.4.0, GMP version 6.1.2, MPFR version 4.0.1,
MPC version 1.1.0, isl version isl-0.19-GMP

GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
ignoring nonexistent directory
"/Users/urabe.shyouhei/target/lib/gcc/x86_64-apple-darwin15.6.0/9.0.0/../../../../x86_64-apple-darwin15.6.0/include"
#include "..." search starts here:
#include <...> search starts here:
 /Users/urabe.shyouhei/target/lib/gcc/x86_64-apple-darwin15.6.0/9.0.0/include
 /usr/local/include
 /Users/urabe.shyouhei/target/include

/Users/urabe.shyouhei/target/lib/gcc/x86_64-apple-darwin15.6.0/9.0.0/include-fixed
 /usr/include
 /System/Library/Frameworks
 /Library/Frameworks
End of search list.
GNU C17 (GCC) version 9.0.0 20180503 (experimental) (x86_64-apple-darwin15.6.0)
compiled by GNU C version 6.4.0, GMP version 6.1.2, MPFR version 4.0.1,
MPC version 1.1.0, isl version isl-0.19-GMP

GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: 48d8373f46962ba1e7a1ba1886f038d5
COLLECT_GCC_OPTIONS='-v' '-fstack-protector' '-mmacosx-version-min=10.11.0' 
'-mtune=core2'
 as -arch x86_64 -v -force_cpusubtype_ALL -mmacosx-version-min=10.11 -o
/var/folders/50/9ss08lxs5ml7kvz614tr3_wmm17741/T//cc2AB2b1.o
/var/folders/50/9ss08lxs5ml7kvz614tr3_wmm17741/T//ccO4in0z.s
Apple LLVM version 8.0.0 (clang-800.0.42.1)
Target: x86_64-apple-darwin15.6.0
Thread model: posix
InstalledDir:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

"/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang"
-cc1as -triple x86_64-apple-macosx10.11.0 -filetype obj -main-file-name
ccO4in0z.s -target-cpu core2 -fdebug-compilation-dir
/Users/urabe.shyouhei/data/build/ruby@gcc-8/trunk@O0 -dwarf-debug-producer
Apple LLVM version 8.0.0 (clang-800.0.42.1) -dwarf-version=2 -mrelocation-model
pic -o /var/folders/50/9ss08lxs5ml7kvz614tr3_wmm17741/T//cc2AB2b1.o
/var/folders/50/9ss08lxs5ml7kvz614tr3_wmm17741/T//ccO4in0z.s
COMPILER_PATH=/Users/urabe.shyouhei/target/libexec/gcc/x86_64-apple-darwin15.6.0/9.0.0/:/Users/urabe.shyouhei/target/libexec/gcc/x86_64-apple-darwin15.6.0/9.0.0/:/Users/urabe.shyouhei/target/libexec/gcc/x86_64-apple-darwin15.6.0/:/Users/urabe.shyouhei/target/lib/gcc/x86_64-apple-darwin15.6.0/9.0.0/:/Users/urabe.shyouhei/target/lib/gcc/x86_64-apple-darwin15.6.0/
LIBRARY_PATH=/Users/urabe.shyouhei/target/lib/gcc/x86_64-apple-darwin15.6.0/9.0.0/:/Users/urabe.shyouhei/target/lib/gcc/x86_64-apple-darwin15.6.0/9.0.0/../../../
COLLECT_GCC_OPTIONS='-v' '-fstack-protector' '-mmacosx-version-min=10.11.0' 
'-mtune=core2'

/Users/urabe.shyouhei/target/libexec/gcc/x86_64-apple-darwin15.6.0/9.0.0/collect2
-dynamic -arch x86_64 -macosx_version_min 10.11.0 -weak_reference_mismatches
non-weak -o a.out
-L/Users/urabe.shyouhei/target/lib/gcc/x86_64-apple-darwin15.6.0/9.0.0
-L/Users/urabe.shyouhei/target/lib/gcc/x86_64-apple-darwin15.6.0/9.0.0/../../..
/var/folders/50/9ss08lxs5ml7kvz614tr3_wmm17741/T//cc2AB2b1.o -no_compact_unwind
-lSystem -lgcc_ext.10.5 -lgcc -lSystem -v
collect2 version 9.0.0 20180503 (experimental)
/usr/bin/ld -dynamic -arch x86_64 -macosx_version_min 10.11.0
-weak_reference_mismatches non-weak -o a.out
-L/Users/urabe.shyouhei/target/lib/gcc/x86_64-apple-darwin15.6.0/9.0.0
-L/Users/

[Bug middle-end/85643] New: attribute nonstring fails to squash -Wstringop-truncation warning

[amodra at gmail dot com]

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

Bug ID: 85643
   Summary: attribute nonstring fails to squash
-Wstringop-truncation warning
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: amodra at gmail dot com
  Target Milestone: ---

Created attachment 44063
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44063=edit
testcase

The attached testcase taken from binutils sources fails at -O2 -Wall -Werror
with

strncpy.i: In function ‘f3’:
strncpy.i:24:3: error: ‘__builtin_strncpy’ specified bound 60 equals
destination size [-Werror=stringop-truncation]
   __builtin_strncpy (data + 20, name, 60);
   ^~~
strncpy.i: In function ‘f4’:
strncpy.i:33:3: error: ‘__builtin_strncpy’ specified bound 60 equals
destination size [-Werror=stringop-truncation]
   __builtin_strncpy (p, name, 60);
   ^~~
cc1: all warnings being treated as errors

[Bug other/78063] libbacktrace fails to handle cross CU DW_AT_abstract_origin

[romain.geissler at amadeus dot com]

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

Romain Geissler  changed:

   What|Removed |Added

 CC||romain.geissler at amadeus dot 
com

--- Comment #2 from Romain Geissler  ---
Hi,

As written in previous comments, this now breaks both libbacktrace tests + all
sanitizer tests using backtrace when using gcc >= 8 and an LTO bootstrapped
compiler.

Shall we XFAIL temporarily these tests in case of LTO bootstrap (if that is
even possible) ?

Here is a list of tests which are failing for me:

test1: [0]: missing file name or function name
FAIL: backtrace_full alloc stress
FAIL: edtest
test1: [0]: missing file name or function name
test1: [0]: missing file name or function name
test1: [0]: missing file name or function name
test1: [0]: missing file name or function name
test1: [0]: missing file name or function name
test1: [0]: missing file name or function name
test1: [0]: missing file name or function name
test1: [0]: missing file name or function name
test1: [0]: missing file name or function name
test1: [0]: missing file name or function name
FAIL: threaded backtrace_full noinline
FAIL: ttest

Cheers,
Romain

[Bug fortran/85641] [7/8 Regression] ICE with string concatenate

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #2 from Steve Kargl  ---
On Thu, May 03, 2018 at 11:12:26PM +, kargl at gcc dot gnu.org wrote:
> 
> #31 0x008ad88d in gfc_code_walker (c=0x2ca231808, 
> codefn=codefn@entry=0x8a90d0  void*)>, 
> exprfn=exprfn@entry=0x8a6eb0  void*)>, data=data@entry=0x0) at ../../gcc/gcc/fortran/frontend-passes.c:4593
> 

gfortran seems to be stuck in an infinite loop and slowly
swallowing memory.

(gdb) c
Continuing.

Breakpoint 1, gfc_code_walker (c=0x203dc5008, 
codefn=codefn@entry=0x8a90d0 , 
exprfn=exprfn@entry=0x8a6eb0 , data=data@entry=0x0) at ../../gcc/gcc/fortran/frontend-passes.c:4566
4566  for (; *c; c = &(*c)->next)
(gdb) c
Continuing.

Breakpoint 2, realloc_string_callback (c=0x203dc5008, 
walk_subtrees=0x7fffd14c, data=0x0)
at ../../gcc/gcc/fortran/frontend-passes.c:248
248   if (co->op != EXEC_ASSIGN)


(gdb) list
4561
4562int
4563gfc_code_walker (gfc_code **c, walk_code_fn_t codefn, walk_expr_fn_t
exprfn,
4564 void *data)
4565{
4566  for (; *c; c = &(*c)->next)
4567{
4568  int walk_subtrees = 1;
4569  int result = codefn (c, _subtrees, data);
4570  if (result)

:-(

[Bug c++/85600] [9 Regression] CPU2006 471.omnetpp fails starting with r259771

[jason at gcc dot gnu.org]

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

--- Comment #9 from Jason Merrill  ---
Author: jason
Date: Thu May  3 23:35:20 2018
New Revision: 259913

URL: https://gcc.gnu.org/viewcvs?rev=259913=gcc=rev
Log:
PR c++/85600 - virtual delete failure.

* init.c (build_delete): Always save_expr when deleting.

Added:
trunk/gcc/testsuite/g++.dg/expr/delete2.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/init.c

[Bug c++/85600] [9 Regression] CPU2006 471.omnetpp fails starting with r259771

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #8 from Jason Merrill  ---
Fixed.

[Bug c++/83476] Template argument deduction fails with reference template parameter

[gufideg at gmail dot com]

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

Guillaume Racicot  changed:

   What|Removed |Added

   Keywords||rejects-valid
Version|7.3.1   |8.1.0
Summary|Template argument deduction |Template argument deduction
   |fails with reference auto   |fails with reference
   |template parameter  |template parameter

--- Comment #1 from Guillaume Racicot  ---
Still happen with GCC 8.1. It also happen with normal reference template
parameter.

Here's a simplified test case:

template struct foo {};

template
void deduce(foo) {}

extern int bar;
int bar;

int main() {
deduce(foo{});
}


This example compiles in MSVC and Clang. https://godbolt.org/g/kxKkb5

[Bug fortran/85641] [7/8 Regression] ICE with string concatenate

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-05-03
 CC||kargl at gcc dot gnu.org,
   ||tkoenig at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from kargl at gcc dot gnu.org ---
This seems to be a problem in the gfc_code_walker() chain.
Note, even if I use -fno-frontend-optimize, I still hit the
problem.  If try

gfcx -o z a.f90 -fno-frontend-optimize

and watch for an explosion in memory usage in top I see

last pid:   489;  load averages:  0.13,  0.22,  0.18up 16+00:00:59 
16:07:16
68 processes:  1 running, 64 sleeping, 3 stopped
CPU:  0.5% user,  0.1% nice,  0.2% system,  0.0% interrupt, 99.1% idle
Mem: 3977M Active, 12G Inact, 695M Laundry, 2153M Wired, 830M Buf, 12G Free
Swap: 16G Total, 84M Used, 16G Free

  PID USERNAMETHR PRI NICE   SIZERES STATE   C   TIMEWCPU COMMAND
  484 sgk   1  400  3280M  3271M STOP1   0:04   0.00% f951
  487 sgk   1  400   340M   316M select  2   0:03   0.00% gdb81

suspending the compilation with ^Z and attaching gdb81 to PID 484 gives

#0  memset () at /usr/src/lib/libc/amd64/string/memset.S:51
#1  0x00020307ae09 in tcache_alloc_small (arena=, size=0, 
tsd=, tcache=, binind=, 
zero=, slow_path=)
at /usr/src/contrib/jemalloc/include/jemalloc/internal/tcache_inlines.h:117
#2  arena_malloc (tsdn=, size=, zero=255, 
tcache=, slow_path=false, arena=, 
ind=)
at
/usr/src/contrib/jemalloc/include/jemalloc/internal/arena_inlines_b.h:101
#3  iallocztm (size=, zero=255, tcache=, 
is_internal=false, slow_path=false, tsdn=, 
ind=, arena=)
at
/usr/src/contrib/jemalloc/include/jemalloc/internal/jemalloc_internal_inlines_c.h:33
#4  imalloc_no_sample (tsd=, size=, usize=3072, 
sopts=, dopts=, ind=)
at jemalloc_jemalloc.c:1654
#5  imalloc_body (tsd=, sopts=, 
dopts=) at jemalloc_jemalloc.c:1850
#6  imalloc (sopts=, dopts=)
at jemalloc_jemalloc.c:1950
#7  __calloc (num=, num@entry=1, size=, 
size@entry=2680) at jemalloc_jemalloc.c:2064
#8  0x0160ca11 in xcalloc (nelem=nelem@entry=1, 
elsize=elsize@entry=2680) at ../../gcc/libiberty/xmalloc.c:162
#9  0x0080b57d in gfc_get_namespace (parent=parent@entry=0x203caf000, 
parent_types=parent_types@entry=1) at ../../gcc/gcc/fortran/symbol.c:2824
#10 0x007d1c93 in gfc_build_block_ns(gfc_namespace*) ()
at ../../gcc/gcc/fortran/parse.c:4429
#11 0x008a884f in insert_block ()
at ../../gcc/gcc/fortran/frontend-passes.c:673
#12 0x008a8cca in insert_block ()
at ../../gcc/gcc/fortran/frontend-passes.c:644
#13 create_var(gfc_expr*, char const*) ()
at ../../gcc/gcc/fortran/frontend-passes.c:728
#14 0x008a9190 in realloc_string_callback (c=0x2ca244808, 
walk_subtrees=, data=)
at ../../gcc/gcc/fortran/frontend-passes.c:291
#15 0x008ad2ca in gfc_code_walker (c=0x2ca244808, 
codefn=codefn@entry=0x8a90d0 , 
exprfn=exprfn@entry=0x8a6eb0 , data=data@entry=0x0) at ../../gcc/gcc/fortran/frontend-passes.c:4569
#16 0x008ad88d in gfc_code_walker (c=0x2ca243c08, 
codefn=codefn@entry=0x8a90d0 , 
exprfn=exprfn@entry=0x8a6eb0 , data=data@entry=0x0) at ../../gcc/gcc/fortran/frontend-passes.c:4593
#17 0x008ad88d in gfc_code_walker (c=0x2ca243008, 
codefn=codefn@entry=0x8a90d0 , 
exprfn=exprfn@entry=0x8a6eb0 , data=data@entry=0x0) at ../../gcc/gcc/fortran/frontend-passes.c:4593
#18 0x008ad88d in gfc_code_walker (c=0x2ca242408, 
codefn=codefn@entry=0x8a90d0 , 
exprfn=exprfn@entry=0x8a6eb0 , data=data@entry=0x0) at ../../gcc/gcc/fortran/frontend-passes.c:4593

[Bug tree-optimization/61502] == comparison on "one-past" pointer gives wrong result

[foom at fuhm dot net]

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

James Y Knight  changed:

   What|Removed |Added

 CC||foom at fuhm dot net

--- Comment #24 from James Y Knight  ---
FWIW, clang did consider this a bug and fixed it in
https://bugs.llvm.org/show_bug.cgi?id=21327.

[Bug libstdc++/82644] Non-standard hypergeometric special functions defined in strict modes

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  ---
Author: redi
Date: Thu May  3 22:58:43 2018
New Revision: 259912

URL: https://gcc.gnu.org/viewcvs?rev=259912=gcc=rev
Log:
PR libstdc++/82644 define TR1 hypergeometric functions in strict modes

Following a recent change for PR 82644 the non-standard hypergeomtric
functions are not defined by  when __STRICT_ANSI__ is defined
(e.g. for -std=c++17, or -std=c++14 -D__STDCPP_WANT_MATH_SPEC_FUNCS__).
That caused errors in  because the using-declarations for
tr1::hyperg et al are invalid in strict modes.

The solution is to define the TR1 hypergeometric functions inline in
 if __STRICT_ANSI__ is defined.

PR libstdc++/82644
* include/tr1/cmath [__STRICT_ANSI__] (hypergf, hypergl, hyperg): Use
inline definitions instead of using-declarations.
[__STRICT_ANSI__] (conf_hypergf, conf_hypergl, conf_hyperg): Likewise.
* testsuite/tr1/5_numerical_facilities/special_functions/
07_conf_hyperg/compile_cxx17.cc: New.
* testsuite/tr1/5_numerical_facilities/special_functions/
17_hyperg/compile_cxx17.cc: New.

Added:
   
trunk/libstdc++-v3/testsuite/tr1/5_numerical_facilities/special_functions/07_conf_hyperg/compile_cxx17.cc
   
trunk/libstdc++-v3/testsuite/tr1/5_numerical_facilities/special_functions/17_hyperg/compile_cxx17.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/tr1/cmath

[Bug c++/85642] New: Wrong implicit exception-specification with std::optional

[duarte at scylladb dot com]

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

Bug ID: 85642
   Summary: Wrong implicit exception-specification with
std::optional
   Product: gcc
   Version: 8.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: duarte at scylladb dot com
  Target Milestone: ---

Apologies if this has already been reported, but I couldn't find a matching
report.

Consider the following program:

#include 

struct Y {
int i;
Y() noexcept = default;
Y(Y&&) noexcept = default;
};

class X final {
std::optional _permit;
X() noexcept = default;
public:
static X make() {
return X();
}
};

int main() {
X::make();
return 1;
}

It fails with the following error message on GCC 8.0.1 and GCC 8.1:

: In static member function 'static X X::make()':
:14:18: error: use of deleted function 'constexpr X::X()'

 return X();
  ^
:11:5: note: 'constexpr X::X() noexcept' is implicitly deleted because
its exception-specification does not match the implicit exception-specification
''
 X() noexcept = default;
 ^
Compiler returned: 1

It compiles fine on GCC 7.3, which I believe is the correct result. 

Godbolt: https://godbolt.org/g/Y2hCHZ

[Bug fortran/85641] New: [7/8 Regression] ICE with string concatenate

[antony at cosmologist dot info]

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

Bug ID: 85641
   Summary: [7/8 Regression] ICE with string concatenate
   Product: gcc
   Version: 7.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: antony at cosmologist dot info
  Target Milestone: ---

This worked for a long time in gcc 7, I think it broke in gcc 7.3 (not exactly
sure which minor version). It is also broken in gcc 8 and latest master:

gfortran -c test.f90

where test.f90 is 

program tester
character(LEN=:), allocatable :: fields
integer j
character(LEN=4), parameter :: CMB_CL_Fields = 'TEBP'

fields = ''
j=1
fields = fields // CMB_CL_Fields(j:j)

end program tester

[Bug target/55307] libgcc's __cpu_indicator_init does not check for avx correctly

[hjl.tools at gmail dot com]

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

--- Comment #6 from H.J. Lu  ---
Dup.

[Bug target/85100] __builtin_cpu_supports avx does not verify OS supports it

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 CC||luto at kernel dot org

--- Comment #13 from H.J. Lu  ---
*** Bug 55307 has been marked as a duplicate of this bug. ***

[Bug target/55307] libgcc's __cpu_indicator_init does not check for avx correctly

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #7 from H.J. Lu  ---
Dup.

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

[Bug middle-end/85637] Unneeded store of member variables in inner loop

[petschy at gmail dot com]

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

--- Comment #2 from petschy at gmail dot com ---
Thanks. For non-char types, one can use __restrict on ptrs, but for chars it
doesn't work, unfortunately (strict aliasing rules). Is there a way to tell the
compiler that a char ptr doesn't alias anything in the function? The current
behaviour pessimizes any code that does byte I/O with classes, if I understand
the rules correcly: 

- for const char* it assumes that members might be read through the ptr, so it
stores them back after an update

- for char* it assumes that after a write, any members in registers must be
re-loaded as the write might have changed them.

[Bug c++/85640] New: Code size regression vs 7.3.1

[petschy at gmail dot com]

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

Bug ID: 85640
   Summary: Code size regression vs 7.3.1
   Product: gcc
   Version: 8.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: petschy at gmail dot com
  Target Milestone: ---

Created attachment 44062
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44062=edit
source

Attached the source of a simple Adler32 checksum class. The Update() fn is 32
bytes longer compared to the code generated with 7.3.1.

Dump of assembler code for function Adler32::Update(void const*, unsigned int):
7.3.1 0x00400500 <+0>: test   %edx,%edx
7.3.1 0x00400502 <+2>: je 0x400578 
7.3.1 0x00400504 <+4>: mov(%rdi),%ecx
7.3.1 0x00400506 <+6>: mov0x4(%rdi),%r8d
7.3.1 0x0040050a <+10>:mov$0x80078071,%r10d
7.3.1 0x00400510 <+16>:xor%r9d,%r9d
7.3.1 0x00400513 <+19>:cmp$0x15af,%edx
7.3.1 0x00400519 <+25>:jbe0x400527 
7.3.1 0x0040051b <+27>:lea-0x15b0(%rdx),%r9d
7.3.1 0x00400522 <+34>:mov$0x15b0,%edx
7.3.1 0x00400527 <+39>:lea-0x1(%rdx),%eax
7.3.1 0x0040052a <+42>:lea0x1(%rsi,%rax,1),%rdx
7.3.1 0x0040052f <+47>:nop
7.3.1 0x00400530 <+48>:add$0x1,%rsi
7.3.1 0x00400534 <+52>:movzbl -0x1(%rsi),%eax
7.3.1 0x00400538 <+56>:add%eax,%ecx
7.3.1 0x0040053a <+58>:add%ecx,%r8d
7.3.1 0x0040053d <+61>:cmp%rdx,%rsi
7.3.1 0x00400540 <+64>:mov%ecx,(%rdi)
7.3.1 0x00400542 <+66>:mov%r8d,0x4(%rdi)
7.3.1 0x00400546 <+70>:jne0x400530 
7.3.1 0x00400548 <+72>:mov%ecx,%eax
7.3.1 0x0040054a <+74>:mul%r10d
7.3.1 0x0040054d <+77>:mov%r8d,%eax
7.3.1 0x00400550 <+80>:shr$0xf,%edx
7.3.1 0x00400553 <+83>:imul   $0xfff1,%edx,%edx
7.3.1 0x00400559 <+89>:sub%edx,%ecx
7.3.1 0x0040055b <+91>:mul%r10d
7.3.1 0x0040055e <+94>:mov%ecx,(%rdi)
7.3.1 0x00400560 <+96>:shr$0xf,%edx
7.3.1 0x00400563 <+99>:imul   $0xfff1,%edx,%edx
7.3.1 0x00400569 <+105>:   sub%edx,%r8d
7.3.1 0x0040056c <+108>:   test   %r9d,%r9d
7.3.1 0x0040056f <+111>:   mov%r9d,%edx
7.3.1 0x00400572 <+114>:   mov%r8d,0x4(%rdi)
7.3.1 0x00400576 <+118>:   jne0x400510 
7.3.1 0x00400578 <+120>:   repz retq 

Dump of assembler code for function Adler32::Update(void const*, unsigned int):
8.1.1 0x00400500 <+0>: test   %edx,%edx
8.1.1 0x00400502 <+2>: je 0x400598 
8.1.1 0x00400508 <+8>: mov(%rdi),%ecx
8.1.1 0x0040050a <+10>:mov0x4(%rdi),%r8d
8.1.1 0x0040050e <+14>:push   %rbx
8.1.1 0x0040050f <+15>:mov$0x80078071,%ebx
8.1.1 0x00400514 <+20>:nopl   0x0(%rax)
8.1.1 0x00400518 <+24>:xor%r11d,%r11d
8.1.1 0x0040051b <+27>:cmp$0x15af,%edx
8.1.1 0x00400521 <+33>:jbe0x40052f 
8.1.1 0x00400523 <+35>:lea-0x15b0(%rdx),%r11d
8.1.1 0x0040052a <+42>:mov$0x15b0,%edx
8.1.1 0x0040052f <+47>:mov%edx,%r10d
8.1.1 0x00400532 <+50>:mov%rsi,%rax
8.1.1 0x00400535 <+53>:add%rsi,%r10
8.1.1 0x00400538 <+56>:nopl   0x0(%rax,%rax,1)
8.1.1 0x00400540 <+64>:add$0x1,%rax
8.1.1 0x00400544 <+68>:movzbl -0x1(%rax),%r9d
8.1.1 0x00400549 <+73>:add%r9d,%ecx
8.1.1 0x0040054c <+76>:add%ecx,%r8d
8.1.1 0x0040054f <+79>:mov%ecx,(%rdi)
8.1.1 0x00400551 <+81>:mov%r8d,0x4(%rdi)
8.1.1 0x00400555 <+85>:cmp%r10,%rax
8.1.1 0x00400558 <+88>:jne0x400540 
8.1.1 0x0040055a <+90>:lea-0x1(%rdx),%eax
8.1.1 0x0040055d <+93>:lea0x1(%rsi,%rax,1),%rsi
8.1.1 0x00400562 <+98>:mov%ecx,%eax
8.1.1 0x00400564 <+100>:   mul%ebx
8.1.1 0x00400566 <+102>:   mov%r8d,%eax
8.1.1 0x00400569 <+105>:   shr$0xf,%edx
8.1.1 0x0040056c <+108>:   imul   $0xfff1,%edx,%edx
8.1.1 0x00400572 <+114>:   sub%edx,%ecx
8.1.1 0x00400574 <+116>:   mul%ebx
8.1.1 0x00400576 <+118>:   mov%ecx,(%rdi)
8.1.1 0x00400578 <+120>:   shr$0xf,%edx

[Bug libgomp/85639] New: ICE in compiling new test cases added in r259850

[seurer at gcc dot gnu.org]

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

Bug ID: 85639
   Summary: ICE in compiling new test cases added in r259850
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgomp
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
  Target Milestone: ---

> FAIL: c-c++-common/goacc/builtin-goacc-parlevel-id-size.c  -std=c++11 
> (internal compiler error)
> FAIL: c-c++-common/goacc/builtin-goacc-parlevel-id-size.c  -std=c++11 (test 
> for excess errors)
> FAIL: c-c++-common/goacc/builtin-goacc-parlevel-id-size.c  -std=c++14 
> (internal compiler error)
> FAIL: c-c++-common/goacc/builtin-goacc-parlevel-id-size.c  -std=c++14 (test 
> for excess errors)
> FAIL: c-c++-common/goacc/builtin-goacc-parlevel-id-size.c  -std=c++98 
> (internal compiler error)
> FAIL: c-c++-common/goacc/builtin-goacc-parlevel-id-size.c  -std=c++98 (test 
> for excess errors)
> FAIL: c-c++-common/goacc/builtin-goacc-parlevel-id-size.c (internal compiler 
> error)
> FAIL: c-c++-common/goacc/builtin-goacc-parlevel-id-size.c (test for excess 
> errors)
> FAIL: libgomp.oacc-c++/../libgomp.oacc-c-c++-common/loop-auto-1.c 
> -DACC_DEVICE_TYPE_host=1 -DACC_MEM_SHARED=1  -O2  (internal compiler error)
> FAIL: libgomp.oacc-c++/../libgomp.oacc-c-c++-common/loop-auto-1.c 
> -DACC_DEVICE_TYPE_host=1 -DACC_MEM_SHARED=1  -O2  (test for excess errors)
> FAIL: libgomp.oacc-c/../libgomp.oacc-c-c++-common/loop-auto-1.c 
> -DACC_DEVICE_TYPE_host=1 -DACC_MEM_SHARED=1  -O2  (internal compiler error)
> FAIL: libgomp.oacc-c/../libgomp.oacc-c-c++-common/loop-auto-1.c 
> -DACC_DEVICE_TYPE_host=1 -DACC_MEM_SHARED=1  -O2  (test for excess errors)


Executing on host: /home/seurer/gcc/build/gcc-trunk/gcc/xgcc
-B/home/seurer/gcc/build/gcc-trunk/gcc/
/home/seurer/gcc/gcc-trunk/libgomp/testsuite/libgomp.oacc-c/../libgomp.oacc-c-c++-common/loop-auto-1.c
 -B/home/seurer/gcc/build/gcc-trunk/powerpc64-unknown-linux-gnu/./libgomp/
-B/home/seurer/gcc/build/gcc-trunk/powerpc64-unknown-linux-gnu/./libgomp/.libs
-I/home/seurer/gcc/build/gcc-trunk/powerpc64-unknown-linux-gnu/./libgomp
-I/home/seurer/gcc/gcc-trunk/libgomp/testsuite/../../include
-I/home/seurer/gcc/gcc-trunk/libgomp/testsuite/.. -fmessage-length=0
-fno-diagnostics-show-caret -Wno-hsa -fdiagnostics-color=never -fopenacc
-DACC_DEVICE_TYPE_host=1 -DACC_MEM_SHARED=1  -O2  -fopenacc-dim=32  
-L/home/seurer/gcc/build/gcc-trunk/powerpc64-unknown-linux-gnu/./libgomp/.libs
-lm   -o ./loop-auto-1.exe(timeout = 300)
spawn -ignore SIGHUP /home/seurer/gcc/build/gcc-trunk/gcc/xgcc
-B/home/seurer/gcc/build/gcc-trunk/gcc/
/home/seurer/gcc/gcc-trunk/libgomp/testsuite/libgomp.oacc-c/../libgomp.oacc-c-c++-common/loop-auto-1.c
-B/home/seurer/gcc/build/gcc-trunk/powerpc64-unknown-linux-gnu/./libgomp/
-B/home/seurer/gcc/build/gcc-trunk/powerpc64-unknown-linux-gnu/./libgomp/.libs
-I/home/seurer/gcc/build/gcc-trunk/powerpc64-unknown-linux-gnu/./libgomp
-I/home/seurer/gcc/gcc-trunk/libgomp/testsuite/../../include
-I/home/seurer/gcc/gcc-trunk/libgomp/testsuite/.. -fmessage-length=0
-fno-diagnostics-show-caret -Wno-hsa -fdiagnostics-color=never -fopenacc
-DACC_DEVICE_TYPE_host=1 -DACC_MEM_SHARED=1 -O2 -fopenacc-dim=32
-L/home/seurer/gcc/build/gcc-trunk/powerpc64-unknown-linux-gnu/./libgomp/.libs
-lm -o ./loop-auto-1.exe
during RTL pass: expand
/home/seurer/gcc/gcc-trunk/libgomp/testsuite/libgomp.oacc-c/../libgomp.oacc-c-c++-common/loop-auto-1.c:
In function 'place':
/home/seurer/gcc/gcc-trunk/libgomp/testsuite/libgomp.oacc-c/../libgomp.oacc-c-c++-common/loop-auto-1.c:80:7:
internal compiler error: Segmentation fault
0x109992cb crash_signal
/home/seurer/gcc/gcc-trunk/gcc/toplev.c:325
0x10561c54 emit_move_insn(rtx_def*, rtx_def*)
/home/seurer/gcc/gcc-trunk/gcc/expr.c:3719
0x103990eb expand_builtin_goacc_parlevel_id_size
/home/seurer/gcc/gcc-trunk/gcc/builtins.c:6687
0x103b745f expand_builtin(tree_node*, rtx_def*, rtx_def*, machine_mode, int)
/home/seurer/gcc/gcc-trunk/gcc/builtins.c:7830
0x1055cb6b expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
/home/seurer/gcc/gcc-trunk/gcc/expr.c:11008
0x105741e3 expand_expr
/home/seurer/gcc/gcc-trunk/gcc/expr.h:280
0x105741e3 expand_expr_real_2(separate_ops*, rtx_def*, machine_mode,
expand_modifier)
/home/seurer/gcc/gcc-trunk/gcc/expr.c:8482
0x1055bb03 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
/home/seurer/gcc/gcc-trunk/gcc/expr.c:11295
0x1056b173 expand_expr
/home/seurer/gcc/gcc-trunk/gcc/expr.h:280
0x1056b173 store_expr_with_bounds(tree_node*, rtx_def*, int, bool, bool,
tree_node*)
/home/seurer/gcc/gcc-trunk/gcc/expr.c:5546
0x1056d29f expand_assignment(tree_node*, tree_node*, bool)

[Bug c++/80947] [6/7 Regression] Different visibility for the lambda and its capture list members with -fvisibility=hidden

[duarte at scylladb dot com]

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

--- Comment #17 from Duarte  ---
It also fails on GCC 8.1. This is the reproducer:

template
void foo() {
struct inner {
inner() {
([this] { });
}
};
}

int main() { foo(); }

It fails when compiled with -fvisibility=hidden, but succeeds with
-fvisibility=default.

It also compiles fine without the template.

[Bug c++/85600] [9 Regression] CPU2006 471.omnetpp fails starting with r259771

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug libstdc++/85632] std::filesystem::space or std::experimental::filesystem::space does not return correct information

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |6.5
  Known to fail||6.4.0, 7.3.0, 8.1.0

--- Comment #5 from Jonathan Wakely  ---
Fixed on all active branches, thanks for the report.

[Bug libstdc++/85632] std::filesystem::space or std::experimental::filesystem::space does not return correct information

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
Author: redi
Date: Thu May  3 20:39:31 2018
New Revision: 259911

URL: https://gcc.gnu.org/viewcvs?rev=259911=gcc=rev
Log:
PR libstdc++/85632 fix wraparound in filesystem::space

On 32-bit targets any values over 4GB would wrap and produce the wrong
result.

PR libstdc++/85632 use uintmax_t for arithmetic
* src/filesystem/ops.cc (experimental::filesystem::space): Perform
arithmetic in result type.
* testsuite/experimental/filesystem/operations/space.cc: New.

Added:
   
branches/gcc-6-branch/libstdc++-v3/testsuite/experimental/filesystem/operations/space.cc
Modified:
branches/gcc-6-branch/libstdc++-v3/ChangeLog
branches/gcc-6-branch/libstdc++-v3/src/filesystem/ops.cc

[Bug target/55307] libgcc's __cpu_indicator_init does not check for avx correctly

[njs at pobox dot com]

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

Nathaniel J. Smith  changed:

   What|Removed |Added

 CC||njs at pobox dot com

--- Comment #5 from Nathaniel J. Smith  ---
This was fixed in #85100.

[Bug libstdc++/84769] variant::get(): unscoped call to get

[duarte at scylladb dot com]

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

--- Comment #13 from Duarte  ---
Awesome, thank you!

[Bug ada/85638] gcc 8.1.0 fails to build ada language for target i686-w64-mingw32

[xantares09 at hotmail dot com]

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

--- Comment #2 from xantares09 at hotmail dot com ---
Created attachment 44061
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44061=edit
./src/gcc-build-i686-w64-mingw32/gcc/ada/rts/a-calend.adb

[Bug ada/85638] gcc 8.1.0 fails to build ada language for target i686-w64-mingw32

[xantares09 at hotmail dot com]

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

--- Comment #1 from xantares09 at hotmail dot com ---
Created attachment 44060
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44060=edit
??

[Bug ada/85638] New: gcc 8.1.0 fails to build ada language for target i686-w64-mingw32

[xantares09 at hotmail dot com]

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

Bug ID: 85638
   Summary: gcc 8.1.0 fails to build ada language for target
i686-w64-mingw32
   Product: gcc
   Version: 8.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: xantares09 at hotmail dot com
  Target Milestone: ---

Created attachment 44059
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44059=edit
error log

Summary
===
Archlinux, x86_64, trying to compile mingw-w64-gcc 8.1.0:

+===GNAT BUG DETECTED==+
| 8.1.0 (i686-w64-mingw32) GCC error:  |
| in find_rarely_executed_basic_blocks_and_crossing_edges, at  |
| bb-reorder.c:1673|
| Error detected around a-calend.adb:801:11|

See error.log for more details
Build goes through if I disable ada.
Binutils is 2.30, mingw crt/winpthreads 5.0.3, installed mingw-w64-gcc is 7.3.0

Compilation options
===
configure --prefix=/usr --libexecdir=/usr/lib \
--target=i686-w64-mingw32 \
--enable-languages=c,lto,c++,objc,obj-c++,fortran,ada \
--enable-shared --enable-static \
--enable-threads=posix --enable-fully-dynamic-string
--enable-libstdcxx-time=yes \
--with-system-zlib --enable-cloog-backend=isl \
--enable-lto --disable-dw2-exceptions --enable-libgomp \
--disable-multilib --enable-checking=release

[Bug libstdc++/84769] variant::get(): unscoped call to get

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

--- Comment #12 from Jonathan Wakely  ---
Fixed on all branches, thanks again.

[Bug libstdc++/84769] variant::get(): unscoped call to get

[redi at gcc dot gnu.org]

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

--- Comment #11 from Jonathan Wakely  ---
Author: redi
Date: Thu May  3 20:16:34 2018
New Revision: 259910

URL: https://gcc.gnu.org/viewcvs?rev=259910=gcc=rev
Log:
PR libstdc++/84769 qualify call to std::get<0>

PR libstdc++/84769
* include/std/variant (visit): Qualify std::get call.

Modified:
branches/gcc-7-branch/libstdc++-v3/ChangeLog
branches/gcc-7-branch/libstdc++-v3/include/std/variant

[Bug libstdc++/85632] std::filesystem::space or std::experimental::filesystem::space does not return correct information

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
Author: redi
Date: Thu May  3 20:16:29 2018
New Revision: 259909

URL: https://gcc.gnu.org/viewcvs?rev=259909=gcc=rev
Log:
PR libstdc++/85632 fix wraparound in filesystem::space

On 32-bit targets any values over 4GB would wrap and produce the wrong
result.

PR libstdc++/85632 use uintmax_t for arithmetic
* src/filesystem/ops.cc (experimental::filesystem::space): Perform
arithmetic in result type.
* testsuite/experimental/filesystem/operations/space.cc: New.

Added:
   
branches/gcc-7-branch/libstdc++-v3/testsuite/experimental/filesystem/operations/space.cc
Modified:
branches/gcc-7-branch/libstdc++-v3/ChangeLog
branches/gcc-7-branch/libstdc++-v3/src/filesystem/ops.cc

[Bug middle-end/85637] Unneeded store of member variables in inner loop

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
This is most likely because unsigned char is considered as aliasing any type. 
That means the write to this->m_s1 and this->m_s2 can be read via *buf

[Bug c++/85637] New: Unneeded store of member variables in inner loop

[petschy at gmail dot com]

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

Bug ID: 85637
   Summary: Unneeded store of member variables in inner loop
   Product: gcc
   Version: 7.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: petschy at gmail dot com
  Target Milestone: ---

Created attachment 44058
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44058=edit
source

Attached a simple Adler32 checksum class. When updating with an array of bytes,
the inner loop just accumulates the two sums, then the modulo is done in the
outer loop. This way the cost of the two modulos is amortized.

At the start the two member variables are loaded into registers, however, they
are stored back to memory in each inner loop iteration. Then, also at the end
after the modulo, but before the end of the outer loop. There is only one exit
from the function.

Why not store the registers back just once right before the ret?

Dump of assembler code for function Adler32::Update(void const*, unsigned int):
   0x00400500 <+0>: test   %edx,%edx
   0x00400502 <+2>: je 0x400578 
   0x00400504 <+4>: mov(%rdi),%ecx  ; ecx is m_s1
   0x00400506 <+6>: mov0x4(%rdi),%r8d   ; r8d is m_s2
   0x0040050a <+10>:mov$0x80078071,%r10d
   0x00400510 <+16>:xor%r9d,%r9d
   0x00400513 <+19>:cmp$0x15af,%edx
   0x00400519 <+25>:jbe0x400527 
   0x0040051b <+27>:lea-0x15b0(%rdx),%r9d
   0x00400522 <+34>:mov$0x15b0,%edx
   0x00400527 <+39>:lea-0x1(%rdx),%eax
   0x0040052a <+42>:lea0x1(%rsi,%rax,1),%rdx
   0x0040052f <+47>:nop
   0x00400530 <+48>:add$0x1,%rsi
   0x00400534 <+52>:movzbl -0x1(%rsi),%eax
   0x00400538 <+56>:add%eax,%ecx; m_s1 += *buf
   0x0040053a <+58>:add%ecx,%r8d; m_s2 += m_s1
   0x0040053d <+61>:cmp%rdx,%rsi
   0x00400540 <+64>:mov%ecx,(%rdi)  ; !!! unneeded store
   0x00400542 <+66>:mov%r8d,0x4(%rdi)   ; !!! ditto
   0x00400546 <+70>:jne0x400530 
   0x00400548 <+72>:mov%ecx,%eax
   0x0040054a <+74>:mul%r10d
   0x0040054d <+77>:mov%r8d,%eax
   0x00400550 <+80>:shr$0xf,%edx
   0x00400553 <+83>:imul   $0xfff1,%edx,%edx
   0x00400559 <+89>:sub%edx,%ecx
   0x0040055b <+91>:mul%r10d
   0x0040055e <+94>:mov%ecx,(%rdi)  ; !!! this could be
done after the jne at +118
   0x00400560 <+96>:shr$0xf,%edx
   0x00400563 <+99>:imul   $0xfff1,%edx,%edx
   0x00400569 <+105>:   sub%edx,%r8d
   0x0040056c <+108>:   test   %r9d,%r9d
   0x0040056f <+111>:   mov%r9d,%edx
   0x00400572 <+114>:   mov%r8d,0x4(%rdi)   ; !!! ditto
   0x00400576 <+118>:   jne0x400510 
   0x00400578 <+120>:   repz retq 

The above code is generated w/ 7.3.1, 6.3.1 generates the exact same code. 

8.0.1  and 8.1.1 generates somewhat different code, longer by 32 bytes, but the
placing of the stores are the same. The size difference is odd, but I'll open
another bug for that.

Platform: AMD64 (FX-8150), Debian 9.4

$ g++-6.3.1 -v
Using built-in specs.
COLLECT_GCC=g++-6.3.1
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-pc-linux-gnu/6.3.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure --enable-languages=c,c++ --disable-multilib
--program-suffix=-6.3.1 --disable-bootstrap --enable-checking=release
CFLAGS='-O2 -march=native' CXXFLAGS='-O2 -march=native'
Thread model: posix
gcc version 6.3.1 20170120 (GCC)

$ g++-7.3.1 -v
Using built-in specs.
COLLECT_GCC=g++-7.3.1
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-pc-linux-gnu/7.3.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure --enable-languages=c,c++ --disable-multilib
--program-suffix=-7.3.1 --disable-bootstrap CFLAGS='-O2 -march=native
-mtune=native' CXXFLAGS='-O2 -march=native -mtune=native'
Thread model: posix
gcc version 7.3.1 20180429 (GCC)

$ g++-8.0.1 -v
Using built-in specs.
COLLECT_GCC=g++-8.0.1
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-pc-linux-gnu/8.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure --enable-languages=c,c++ --disable-multilib
--program-suffix=-8.0.1 --disable-bootstrap CFLAGS='-O2 -march=native'
CXXFLAGS='-O2 -march=native'
Thread model: posix
gcc version 8.0.1 20180214 (experimental) (GCC)

$ g++-8.1.1 -v
Using built-in specs.

[Bug libstdc++/84769] variant::get(): unscoped call to get

[redi at gcc dot gnu.org]

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

--- Comment #10 from Jonathan Wakely  ---
Author: redi
Date: Thu May  3 19:53:46 2018
New Revision: 259907

URL: https://gcc.gnu.org/viewcvs?rev=259907=gcc=rev
Log:
PR libstdc++/84769 qualify call to std::get<0>

PR libstdc++/84769
* include/std/variant (visit): Qualify std::get call.

Modified:
branches/gcc-8-branch/libstdc++-v3/ChangeLog
branches/gcc-8-branch/libstdc++-v3/include/std/variant

[Bug libstdc++/85632] std::filesystem::space or std::experimental::filesystem::space does not return correct information

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
Author: redi
Date: Thu May  3 19:53:42 2018
New Revision: 259906

URL: https://gcc.gnu.org/viewcvs?rev=259906=gcc=rev
Log:
PR libstdc++/85632 fix wraparound in filesystem::space

On 32-bit targets any values over 4GB would wrap and produce the wrong
result.

PR libstdc++/85632 use uintmax_t for arithmetic
* src/filesystem/ops.cc (experimental::filesystem::space): Perform
arithmetic in result type.
* src/filesystem/std-ops.cc (filesystem::space): Likewise.
* testsuite/27_io/filesystem/operations/space.cc: Check total capacity
is greater than free space.
* testsuite/experimental/filesystem/operations/space.cc: New.

Added:
   
branches/gcc-8-branch/libstdc++-v3/testsuite/experimental/filesystem/operations/space.cc
  - copied, changed from r259898,
branches/gcc-8-branch/libstdc++-v3/testsuite/27_io/filesystem/operations/space.cc
Modified:
branches/gcc-8-branch/libstdc++-v3/ChangeLog
branches/gcc-8-branch/libstdc++-v3/src/filesystem/ops.cc
branches/gcc-8-branch/libstdc++-v3/src/filesystem/std-ops.cc
   
branches/gcc-8-branch/libstdc++-v3/testsuite/27_io/filesystem/operations/space.cc

[Bug tree-optimization/85636] New: Tree if-conversion inserts bogus loads

[rsandifo at gcc dot gnu.org]

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

Bug ID: 85636
   Summary: Tree if-conversion inserts bogus loads
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rsandifo at gcc dot gnu.org
  Target Milestone: ---

Compiling this at -O3 on aarch64-linux-gnu:

void f (int *a, int *b, int *c, int x, int y)
{
  for (int i = 0; i < 100; ++i)
{
  int v = c[i];
  a[i] = (v == 20 ? x : y);
  b[i] = (v != 20 ? x : y);
}
}

gives the following basic block after if-conversion:

  _1 = (long unsigned int) i_31;
  _2 = _1 * 4;
  _3 = c_11(D) + _2;
  v_12 = *_3;
  _21 = a_15(D) + _2;
  _ifc__41 = *_21;
  _ifc__42 = x_13(D);
  _ifc__43 = v_12 == 20 ? _ifc__42 : _ifc__41;
  *_21 = _ifc__43;
  _ifc__44 = *_21;
  _ifc__45 = y_14(D);
  _ifc__46 = v_12 == 20 ? _ifc__44 : _ifc__45;
  *_21 = _ifc__46;
  iftmp.1_8 = v_12 != 20 ? x_13(D) : y_14(D);
  _5 = b_17(D) + _2;
  *_5 = iftmp.1_8;

Note the two extra loads from a[i] (_21), which didn't occur in the original
source.  The handling of b[i] is fine.

[Bug target/85530] [X86] _mm512_mullox_epi64 and _mm512_mask_mullox_epi64 not implemented

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #3 from Jakub Jelinek  ---
Implemented for GCC9+.

[Bug target/85530] [X86] _mm512_mullox_epi64 and _mm512_mask_mullox_epi64 not implemented

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
Author: jakub
Date: Thu May  3 18:59:39 2018
New Revision: 259903

URL: https://gcc.gnu.org/viewcvs?rev=259903=gcc=rev
Log:
PR target/85530
* config/i386/avx512fintrin.h (_mm512_mullox_epi64,
_mm512_mask_mullox_epi64): New intrinsics.

* gcc.target/i386/avx512f-vpmullq-1.c: New test.
* gcc.target/i386/avx512f-vpmullq-2.c: New test.
* gcc.target/i386/avx512dq-vpmullq-3.c: New test.
* gcc.target/i386/avx512dq-vpmullq-4.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/i386/avx512dq-vpmullq-3.c
trunk/gcc/testsuite/gcc.target/i386/avx512dq-vpmullq-4.c
trunk/gcc/testsuite/gcc.target/i386/avx512f-vpmullq-1.c
trunk/gcc/testsuite/gcc.target/i386/avx512f-vpmullq-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/avx512fintrin.h
trunk/gcc/testsuite/ChangeLog

[Bug libstdc++/85632] std::filesystem::space or std::experimental::filesystem::space does not return correct information

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
Author: redi
Date: Thu May  3 18:58:00 2018
New Revision: 259901

URL: https://gcc.gnu.org/viewcvs?rev=259901=gcc=rev
Log:
PR libstdc++/85632 fix wraparound in filesystem::space

On 32-bit targets any values over 4GB would wrap and produce the wrong
result.

PR libstdc++/85632 use uintmax_t for arithmetic
* src/filesystem/ops.cc (experimental::filesystem::space): Perform
arithmetic in result type.
* src/filesystem/std-ops.cc (filesystem::space): Likewise.
* testsuite/27_io/filesystem/operations/space.cc: Check total capacity
is greater than free space.
* testsuite/experimental/filesystem/operations/space.cc: New.

Added:
trunk/libstdc++-v3/testsuite/experimental/filesystem/operations/space.cc
  - copied, changed from r259900,
trunk/libstdc++-v3/testsuite/27_io/filesystem/operations/space.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/src/filesystem/ops.cc
trunk/libstdc++-v3/src/filesystem/std-ops.cc
trunk/libstdc++-v3/testsuite/27_io/filesystem/operations/space.cc

[Bug libstdc++/84769] variant::get(): unscoped call to get

[redi at gcc dot gnu.org]

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

--- Comment #9 from Jonathan Wakely  ---
Author: redi
Date: Thu May  3 18:58:04 2018
New Revision: 259902

URL: https://gcc.gnu.org/viewcvs?rev=259902=gcc=rev
Log:
PR libstdc++/84769 qualify call to std::get<0>

PR libstdc++/84769
* include/std/variant (visit): Qualify std::get call.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/std/variant

[Bug libstdc++/84769] variant::get(): unscoped call to get

[duarte at scylladb dot com]

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

--- Comment #8 from Duarte  ---
I tried to go ahead and send a patch for this (should be on the gcc-patches and
libstdc++ lists).

[Bug libstdc++/84769] variant::get(): unscoped call to get

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

--- Comment #7 from Jonathan Wakely  ---
Thanks, I thought I'd searched for any others. Apparently not.

[Bug ada/85635] gcc8+: typo in link.c renders gnat unbuildable on non-windows, non hpux

[gnugcc at marino dot st]

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

--- Comment #2 from John Marino  ---
I would think every condition after (e.g. __APPLE__, __linux__, _AIX) would
fail as well.  Wouldn't cpp abort on QNX before the __APPLE__ condition is
evaluated?

[Bug ada/85635] gcc8+: typo in link.c renders gnat unbuildable on non-windows, non hpux

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
To be precise, only {Free,Net,Open}BSD, QNX and DragonFly ada is broken.

[Bug c++/85634] [8/9 Regression] ICE in tsubst_copy, at cp/pt.c:15483

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-05-03
   Target Milestone|--- |8.2
Summary|8.1 ICE in tsubst_copy, at  |[8/9 Regression] ICE in
   |cp/pt.c:15483   |tsubst_copy, at
   ||cp/pt.c:15483
 Ever confirmed|0   |1

--- Comment #5 from Marek Polacek  ---
Thanks.  Confirmed, started with r248250.

[Bug ada/85635] New: gcc8+: typo in link.c renders gnat unbuildable on non-windows, non hpux

[gnugcc at marino dot st]

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

Bug ID: 85635
   Summary: gcc8+: typo in link.c renders gnat unbuildable on
non-windows, non hpux
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gnugcc at marino dot st
  Target Milestone: ---

There was a bug introduced at trunk@254573 on (2017-11-09 Pascal Obry
)

Specifically, a macro condition was modified improperly, resulting in a broken
build on gcc release 8.1 and trunk.

The following (obvious) patch needs to be applied to fix it:

--- gcc/ada/link.c.orig 2018-05-03 17:24:27 UTC
+++ gcc/ada/link.c
@@ -104,7 +104,7 @@ unsigned char __gnat_separate_run_path_o
 const char *__gnat_default_libgcc_subdir = "lib";

 #elif defined (__FreeBSD__) || defined (__DragonFly__) \
-   || defined (__NetBSD__) || defined (__OpenBSD__)
+   || defined (__NetBSD__) || defined (__OpenBSD__) \
|| defined (__QNX__)
 const char *__gnat_object_file_option = "-Wl,@";
 const char *__gnat_run_path_option = "-Wl,-rpath,";

[Bug c++/82899] *this in constructors could not alias with reference input parameters of the same type

[antoshkka at gmail dot com]

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

--- Comment #8 from Antony Polukhin  ---
(In reply to Richard Biener from comment #4)
> (In reply to Antony Polukhin from comment #2)
> > Looks like [class.ctor] paragraph 14 covers this case:
> > 
> > "During the construction of an object, if the value of the object or any of
> > its subobjects is accessed through
> > a glvalue that is not obtained, directly or indirectly, from the
> > constructor’s this pointer, the value of the
> > object or subobject thus obtained is unspecified."
> 
> Yeah, sounds like covering this case.  Thus we can make 'this' restrict in
> constructors (and possibly assignment operators if self-assignment is
> forbidden).

Self assignment is tricky and is OK to alias in most cases. It could be
restricted at some point after the `this != ` check (as proposed in Bug
82918). 

I'd rather start by "restricting this" for copy and move constructors, leaving
assignment as is.

[Bug c++/85634] 8.1 ICE in tsubst_copy, at cp/pt.c:15483

[andrew at ishiboo dot com]

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

--- Comment #4 from Andrew Paprocki  ---
(In reply to Marek Polacek from comment #1)
> Please submit a full bug report, with preprocessed source if appropriate.

I had to attach the .ii and .s file tgz'd due to the file size limit of the
bugtracker.

[Bug c++/85634] 8.1 ICE in tsubst_copy, at cp/pt.c:15483

[andrew at ishiboo dot com]

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

--- Comment #3 from Andrew Paprocki  ---
Compiler info:

$ g++-8 -v
Reading specs from /dev/shm/refroot/opt/bb/lib/gcc-8.1/bin/../lib/gcc/specs
COLLECT_GCC=/dev/shm/refroot/opt/bb/bin/g++-8
COLLECT_LTO_WRAPPER=/dev/shm/refroot/opt/bb/lib/gcc-8.1/bin/../libexec/gcc/x86_64-unknown-linux-gnu/8.1.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --enable-languages=c,c++,fortran,go
--build=x86_64-unknown-linux-gnu --prefix=/opt/bb/lib/gcc-8.1
--with-ar=/opt/rh/devtoolset-4/root/usr/bin/ar
--with-ld=/opt/rh/devtoolset-4/root/usr/bin/ld
--with-nm=/opt/rh/devtoolset-4/root/usr/bin/nm
--with-objcopy=/opt/rh/devtoolset-4/root/usr/bin/objcopy
--with-objdump=/opt/rh/devtoolset-4/root/usr/bin/objdump
--with-ranlib=/opt/rh/devtoolset-4/root/usr/bin/ranlib
--with-readelf=/opt/rh/devtoolset-4/root/usr/bin/readelf
--with-gmp-include=/opt/bb/include --with-gmp-lib=/opt/bb/lib64
--with-mpfr-include=/opt/bb/include --with-mpfr-lib=/opt/bb/lib64
--with-mpc-include=/opt/bb/include --with-mpc-lib=/opt/bb/lib64
--with-libiconv-prefix=/tmp/gcc-8.1-8.1.0-0/build/iconv
--with-stage1-ldflags='-Wl,--enable-new-dtags  -Wl,-R/opt/bb/lib64'
--with-boot-ldflags='-Wl,--enable-new-dtags  -Wl,-R/opt/bb/lib64'
--enable-plugin --enable-vtable-verify --disable-bootstrap
Thread model: posix
gcc version 8.1.0

Host info:

RHEL6 

$ uname -a
Linux nylxdev1 2.6.32-642.6.2.el6.x86_64 #1 SMP Mon Oct 24 10:22:33 EDT 2016
x86_64 x86_64 x86_64 GNU/Linux

[Bug c++/85634] 8.1 ICE in tsubst_copy, at cp/pt.c:15483

[andrew at ishiboo dot com]

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

--- Comment #2 from Andrew Paprocki  ---
Created attachment 44057
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44057=edit
-save-temps output

[Bug libstdc++/84769] variant::get(): unscoped call to get

[duarte at scylladb dot com]

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

--- Comment #6 from Duarte  ---
I think that calls to get<0> should be scoped, for example in visit().

[Bug c++/80947] [6/7 Regression] Different visibility for the lambda and its capture list members with -fvisibility=hidden

[duarte at scylladb dot com]

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

Duarte  changed:

   What|Removed |Added

 CC||duarte at scylladb dot com

--- Comment #16 from Duarte  ---
This is happening again in g++ (GCC) 8.0.1 20180324 (Red Hat 8.0.1-0.20).

[Bug middle-end/85633] reorders function ignoring fpu exception state

[jtaylor.debian at googlemail dot com]

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

--- Comment #4 from Julian Taylor  ---
Oh that is unfortunate.
I guess one has to inject the dependency in the fpu checking function as an
argument then.

[Bug c++/85634] 8.1 ICE in tsubst_copy, at cp/pt.c:15483

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #1 from Marek Polacek  ---
Please submit a full bug report, with preprocessed source if appropriate.

[Bug c++/85634] New: 8.1 ICE in tsubst_copy, at cp/pt.c:15483

[andrew at ishiboo dot com]

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

Bug ID: 85634
   Summary: 8.1 ICE in tsubst_copy, at cp/pt.c:15483
   Product: gcc
   Version: 8.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: andrew at ishiboo dot com
  Target Milestone: ---

Easily reproducible on a RHEL6 Linux box using the just released GCC 8.1.0
compiler built from source.

1) Clone https://github.com/bloomberg/bde
2) cd bde/groups/bsl/bslstl
3) Compile bslstl_queue.t.cpp

The full compiler command line and output is:

g++-8 \
-Wall -Wno-unused-variable \
-DBDE_BUILD_TARGET_EXC \
-DBDE_BUILD_TARGET_MT \
-DBDE_BUILD_TARGET_OPT \
-fexceptions \
-O2 \
-fno-gcse \
-fno-strict-aliasing \
-DNDEBUG \
-D_POSIX_PTHREAD_SEMANTICS \
-D_REENTRANT \
-D_FILE_OFFSET_BITS=64 \
-DBDE_NO_CPP_STDLIB \
-D_RWSTD_COMPILE_INSTANTIATE=1 \
-I. \
-I../bslalg \
-I../bsltf \
-I../bslma \
-I../bslh \
-I../bslmf \
-I../bslscm \
-I../bsls \
-c \
-o /dev/null \
bslstl_queue.t.cpp

Output:

bslstl_queue.t.cpp: In instantiation of 'static void TestDriver::testCase6() [with VALUE = signed char; CONTAINER =
bsl::deque >]':
bslstl_queue.t.cpp:6618:9:   required from here
bslstl_queue.t.cpp:5114:21: internal compiler error: in tsubst_copy, at
cp/pt.c:15483
 operatorPtr operatorEq = operator==;
 ^~
0x6fe553 tsubst_copy
../../gcc/cp/pt.c:15483
0x6f75dc tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/cp/pt.c:18975
0x6fc177 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/cp/pt.c:17412
0x6fd5e5 tsubst_init
../../gcc/cp/pt.c:15274
0x6fce7e tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/cp/pt.c:16726
0x6fbb04 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/cp/pt.c:16599
0x6fc0b5 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/cp/pt.c:16896
0x6fbb04 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/cp/pt.c:16599
0x6fc0b5 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/cp/pt.c:16896
0x6fa6ad instantiate_decl(tree_node*, bool, bool)
../../gcc/cp/pt.c:23977
0x715b1b instantiate_pending_templates(int)
../../gcc/cp/pt.c:24093
0x673430 c_parse_final_cleanups()
../../gcc/cp/decl2.c:4725
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.

[Bug target/85628] Make better use of BFI (BFXIL)

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
>This should just be a matter of adding the necessary patterns in aarch64.md.

I was doing for MIPS and it was rejected because combine or something before
combine should be generating zero_extract on the set side.

[Bug middle-end/85633] reorders function ignoring fpu exception state

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski  ---
See PR 38960 for why I said this is not a regression.

[Bug c++/67650] undef reference with -fdevirtualize

[vincent.lextrait at gmail dot com]

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

--- Comment #30 from Vincent  ---
Am using OSX, but I do not believe it makes a big difference. Thanks, Jonathan,
let me know if I can help in any way.

(In reply to Jonathan Wakely from comment #29)
> (In reply to Vincent from comment #27)
> > Sorry for the silly check, are you sure you are trying with -O3 or
> > -fdevirtualize -O2? 
> 
> I've tried both. I'm using x86_64-pc-linux-gnu though.
> 
> 
> > You can try this with 8.1:
> > 
> > void *v;
> > 
> > template 
> > struct LK: public BLKC
> > {
> >   void rb(){((T*)v)->ax();}
> >   static T* st;
> > };
> > 
> > As a replacement to the call to null, and the missing definition problem is
> > reported.
> 
> OK now I can reproduce it with trunk.
> 
> (In reply to Vincent from comment #28)
> > Other silly check, did you try with my code or your reduced code ?
> 
> Yours.
> 
> Here's the reduced form that gives a link-error with trunk:
> 
> #include 
> 
> template 
> struct RE
> {
>   virtual void rp()=0;
>   void ax(){rp();}
> };
> 
> struct EN : RE
> {
>   EN(::std::string = ""){}
>   void rp(){}
> };
> 
> template 
> struct AN : RE
> {
>   void rp(){}
> };
> 
> template 
> struct LK
> {
>   T* p = nullptr;
>   virtual void rb(){p->ax();}
> };
> 
> template 
> struct LR
> {
>   virtual ~LR(){}
>   struct LLC { virtual ~LLC(){} };
>   LK l;
> };
> 
> constexpr char ET[]="";
> struct I : EN
> {
>   LR _e;
> };
> 
> int main(){new I();}
> 
> 
> $ ~/gcc/8.1.0/bin/g++ -Wall -O1 -fdevirtualize main.cc 
> main.cc:19:8: warning: ‘void AN::rp() [with OC = LR<(& ET)>::LLC]’ used
> but never defined
>void rp(){}
> ^~
> /tmp/cc4IHAPf.o: In function `LK::LLC> >::rb()':
> main.cc:(.text+0x37): undefined reference to `AN::LLC>::rp()'
> collect2: error: ld returned 1 exit status

[Bug middle-end/85633] reorders function ignoring fpu exception state

[jtaylor.debian at googlemail dot com]

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

--- Comment #2 from Julian Taylor  ---
changing the fpu state does not count as a side effect?
This doesn't seem plausible, this type of code is one the reasons the fpu
exception state exists.
There is a lot of code written with this in mind which worked for decades and
now not anymore. I think that classifies as a regression.

[Bug middle-end/85633] reorders function ignoring fpu exception state

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|c   |middle-end
Summary|[8 Regression] reorders |reorders function ignoring
   |function ignoring fpu   |fpu exception state
   |exception state |

--- Comment #1 from Andrew Pinski  ---
There is no tie between FPU operations and function calls.  This is not a
regression as it was just done by accident between GCC 8.

[Bug c/85633] New: [8 Regression] reorders function ignoring fpu exception state

[jtaylor.debian at googlemail dot com]

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

Bug ID: 85633
   Summary: [8 Regression] reorders function ignoring fpu
exception state
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jtaylor.debian at googlemail dot com
  Target Milestone: ---

gcc-8 seems to ignore the global fpu exception state when reordering functions.
In this example it reorders the fpu_invalid_set_function which is _not_ marked
as const before the last _mm_min_ps call which can set the fpu invalid
exception.

#include 
int fpu_invalid_set(void);
float reduce(__m128 a);

float fun(float *a)
{
__m128 c1 = _mm_set_ps1(1000);
__m128 c2 = _mm_set_ps1(1000);
for (int i=0; i < 64; i+=8) {
__m128 x1 = _mm_loadu_ps([i]);
__m128 x2 = _mm_loadu_ps([i+4]);
c1 = _mm_min_ps(c1, x1);
c2 = _mm_min_ps(c2, x2);
}
c1 = _mm_min_ps(c1, c2);
if (fpu_invalid_set()) {
return 1;
}
else {
return reduce(c1);
}
}

gcc -O2 -c fun.c
objdump -d fun.o
 :
   0:   48 83 ec 28 sub$0x28,%rsp
   4:   0f 28 0d 00 00 00 00movaps 0x0(%rip),%xmm1# b 
   b:   48 8d 87 00 01 00 00lea0x100(%rdi),%rax
  12:   0f 28 c1movaps %xmm1,%xmm0
  15:   0f 1f 00nopl   (%rax)
  18:   0f 10 17movups (%rdi),%xmm2
  1b:   0f 10 5f 10 movups 0x10(%rdi),%xmm3
  1f:   48 83 c7 20 add$0x20,%rdi
  23:   0f 5d c2minps  %xmm2,%xmm0
  26:   0f 5d cbminps  %xmm3,%xmm1
  29:   48 39 f8cmp%rdi,%rax
  2c:   75 ea   jne18 
  2e:   0f 29 44 24 10  movaps %xmm0,0x10(%rsp)
  33:   0f 29 0c 24 movaps %xmm1,(%rsp)
  37:   e8 00 00 00 00  callq  3c   call to early
  3c:   0f 28 0c 24 movaps (%rsp),%xmm1
  40:   0f 28 44 24 10  movaps 0x10(%rsp),%xmm0
  45:   85 c0   test   %eax,%eax
  47:   74 17   je 60 
  49:   f3 0f 10 05 00 00 00movss  0x0(%rip),%xmm0# 51 
  50:   00 
  51:   48 83 c4 28 add$0x28,%rsp
  55:   c3  retq   
  56:   66 2e 0f 1f 84 00 00nopw   %cs:0x0(%rax,%rax,1)
  5d:   00 00 00 
  60:   0f 5d c1minps  %xmm1,%xmm0 <<< min at wrong
place
  63:   48 83 c4 28 add$0x28,%rsp
  67:   e9 00 00 00 00  jmpq   6c 


gcc 7 and earlier execute the minps instruction before calling the function
that checks the fpu state.

[Bug libstdc++/85632] std::filesystem::space or std::experimental::filesystem::space does not return correct information

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-05-03
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug libstdc++/82644] Non-standard hypergeometric special functions defined in strict modes

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  ---
Bah, now we have failures for TR1 with -std=c++17 or -std=c++2a:


$ ~/gcc/8/bin/g++ -std=c++17 -include tr1/cmath -x c++ /dev/null 
In file included from :
/home/jwakely/gcc/8/include/c++/8.0.1/tr1/cmath:1163:20: error:
‘__gnu_cxx::conf_hypergf’ has not been declared
   using __gnu_cxx::conf_hypergf;
^~~~
/home/jwakely/gcc/8/include/c++/8.0.1/tr1/cmath:1164:20: error:
‘__gnu_cxx::conf_hypergl’ has not been declared
   using __gnu_cxx::conf_hypergl;
^~~~
/home/jwakely/gcc/8/include/c++/8.0.1/tr1/cmath:1165:20: error:
‘__gnu_cxx::conf_hyperg’ has not been declared
   using __gnu_cxx::conf_hyperg;
^~~
/home/jwakely/gcc/8/include/c++/8.0.1/tr1/cmath:1203:20: error:
‘__gnu_cxx::hypergf’ has not been declared
   using __gnu_cxx::hypergf;
^~~
/home/jwakely/gcc/8/include/c++/8.0.1/tr1/cmath:1204:20: error:
‘__gnu_cxx::hypergl’ has not been declared
   using __gnu_cxx::hypergl;
^~~
/home/jwakely/gcc/8/include/c++/8.0.1/tr1/cmath:1205:20: error:
‘__gnu_cxx::hyperg’ has not been declared
   using __gnu_cxx::hyperg;
^~

[Bug libstdc++/85632] New: std::filesystem::space or std::experimental::filesystem::space does not return correct information

[bandinfinite at gmail dot com]

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

Bug ID: 85632
   Summary: std::filesystem::space or
std::experimental::filesystem::space does not return
correct information
   Product: gcc
   Version: 7.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bandinfinite at gmail dot com
  Target Milestone: ---

I'm typing this report on my phone so forgive me for not perfect formatting.
The bug is simple, filesystem::space() probably won't return correct info for
most modern  storage device that contain a big enough partition (anything more
than 4GB   counts). The cause of this bug is simply that the author forgot
static_cast(data retrieved by statvfs) before the calculation. So
the fix is also trivial and can definitely backport to all version  contain
experimental::filesystem.
The latest 8.1 release shares this bug, confirmed with the git mirror hours
ago.

[Bug fortran/85631] [8/9 Regression] Runtime error message array bound mismatch with nonzero optimization

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
  Known to work||7.3.0
   Keywords||wrong-code
   Last reconfirmed||2018-05-03
 CC||tkoenig at gcc dot gnu.org
 Ever confirmed|0   |1
Summary|Runtime error message array |[8/9 Regression] Runtime
   |bound mismatch with nonzero |error message array bound
   |optimization|mismatch with nonzero
   ||optimization
   Target Milestone|--- |8.2
  Known to fail||8.1.0, 9.0

--- Comment #1 from Dominique d'Humieres  ---
Confirmed on 8 and trunk (9.0), likely r248553. Usual workaround: compile with
-fno-frontend-optimize.

[Bug libstdc++/84087] string::assign problem with two arguments

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords|deferred|
 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |9.0

--- Comment #7 from Jonathan Wakely  ---
This is fixed on trunk now. I'll probably backport it to the release branches.

[Bug fortran/85631] New: Runtime error message array bound mismatch with nonzero optimization

[zeccav at gmail dot com]

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

Bug ID: 85631
   Summary: Runtime error message array bound mismatch with
nonzero optimization
   Product: gcc
   Version: 8.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zeccav at gmail dot com
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu

! Runtime error message on good Fortran
! gfortran -O -g -fcheck=bounds
! must be compiled and run
!At line 20 of file pcp2k.f
!Fortran runtime error: Array bound mismatch for dimension 1 of array
'__var_1_mma' (0/2)

!Error termination. Backtrace:
!#0  0x1496530ec2de in ???
!#1  0x1496530ece89 in ???
!#2  0x1496530ed26b in ???
!#3  0x40082d in MAIN__
!   at /home/vitti/test/pcp2k.f:8
!#4  0x40086e in main
!   at /home/vitti/test/pcp2k.f:9
  integer, parameter :: N=2
  real, dimension(:,:), pointer :: block_1, block_2
  allocate(block_1(N,N),block_2(N,N))
  block_1=0
  block_2=0
  block_1 = MATMUL(TRANSPOSE(block_1), block_2)
  end

[Bug libstdc++/84087] string::assign problem with two arguments

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  ---
Author: redi
Date: Thu May  3 15:01:20 2018
New Revision: 259895

URL: https://gcc.gnu.org/viewcvs?rev=259895=gcc=rev
Log:
PR libstdc++/84087 add default arguments to basic_string members (LWG 2268)

This change was a DR against C++11 and so should have been implemented
years ago.

PR libstdc++/84087 LWG DR 2268 basic_string default arguments
* include/bits/basic_string.h [_GLIBCXX_USE_CXX11_ABI=1]
(append(const basic_string&, size_type, size_type)
(assign(const basic_string&, size_type, size_type)
(insert(size_type, const basic_string&, size_type, size_type)
(replace(size_type,size_type,const basic_string&,size_type,size_type)
(compare(size_type,size_type,constbasic_string&,size_type,size_type)):
Add default arguments (LWG 2268).
[_GLIBCXX_USE_CXX11_ABI=0]
(append(const basic_string&, size_type, size_type)
(assign(const basic_string&, size_type, size_type)
(insert(size_type, const basic_string&, size_type, size_type)
(replace(size_type,size_type,const basic_string&,size_type,size_type)
(compare(size_type,size_type,constbasic_string&,size_type,size_type)):
Likewise.
* testsuite/21_strings/basic_string/dr2268.cc: New test.

Added:
trunk/libstdc++-v3/testsuite/21_strings/basic_string/dr2268.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/basic_string.h

[Bug bootstrap/85630] New: GCC 8.1.0: Filesystem pollution during build: .cache dir in $HOME

[kdevel at vogtner dot de]

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

Bug ID: 85630
   Summary: GCC 8.1.0: Filesystem pollution during build: .cache
dir in $HOME
   Product: gcc
   Version: 8.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kdevel at vogtner dot de
  Target Milestone: ---

After a make bootstrap and make test (which failed, Bug 85629) a directory
named ".cache" is left over in $HOME. It contains a sub-directory "go-build":

$ ls
00  09  12  1b  24  2d  36  3f  48  51  5a  63  6c  75  7e  87  90  99  a2  ab 
b4  bd  c6  cf  d8  e1  ea  f3  fc
01  0a  13  1c  25  2e  37  40  49  52  5b  64  6d  76  7f  88  91  9a  a3  ac 
b5  be  c7  d0  d9  e2  eb  f4  fd
02  0b  14  1d  26  2f  38  41  4a  53  5c  65  6e  77  80  89  92  9b  a4  ad 
b6  bf  c8  d1  da  e3  ec  f5  fe
03  0c  15  1e  27  30  39  42  4b  54  5d  66  6f  78  81  8a  93  9c  a5  ae 
b7  c0  c9  d2  db  e4  ed  f6  ff
04  0d  16  1f  28  31  3a  43  4c  55  5e  67  70  79  82  8b  94  9d  a6  af 
b8  c1  ca  d3  dc  e5  ee  f7  log.txt
05  0e  17  20  29  32  3b  44  4d  56  5f  68  71  7a  83  8c  95  9e  a7  b0 
b9  c2  cb  d4  dd  e6  ef  f8  README
06  0f  18  21  2a  33  3c  45  4e  57  60  69  72  7b  84  8d  96  9f  a8  b1 
ba  c3  cc  d5  de  e7  f0  f9  trim.txt
07  10  19  22  2b  34  3d  46  4f  58  61  6a  73  7c  85  8e  97  a0  a9  b2 
bb  c4  cd  d6  df  e8  f1  fa
08  11  1a  23  2c  35  3e  47  50  59  62  6b  74  7d  86  8f  98  a1  aa  b3 
bc  c5  ce  d7  e0  e9  f2  fb

$ cat README 
This directory holds cached build artifacts from the Go build system.
Run "go clean -cache" if the directory is getting too large.
See golang.org to learn more about Go.

These files shall be placed in the build-directory and not in $HOME.

[Bug bootstrap/85629] New: GCC 8.1.0: FTBFS: make check fails in Go part

[kdevel at vogtner dot de]

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

Bug ID: 85629
   Summary: GCC 8.1.0: FTBFS: make check fails in Go part
   Product: gcc
   Version: 8.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kdevel at vogtner dot de
  Target Milestone: ---

Centos 6.9 final, X86_64, expect installed, dejagnu not installed

$ grep ^FAIL build.log.2018-05-02T20\:49\:37

FAIL: go test cmd/go
FAIL: go test runtime
FAIL: TestBreakpoint
FAIL: TestCatchPanic
FAIL: TestCgoCallbackGC
FAIL: TestCgoCCodeSIGPROF
FAIL: TestCgoCheckBytes
FAIL: TestCgoCrashHandler
FAIL: TestCgoExecSignalMask
FAIL: TestCgoExternalThreadPanic
FAIL: TestCgoExternalThreadSignal
FAIL: TestCgoExternalThreadSIGPROF
FAIL: TestCgoLockOSThreadExit
FAIL: TestCgoNumGoroutine
FAIL: TestCgoPanicDeadlock
FAIL: TestCgoSignalDeadlock
FAIL: TestCgoTraceback
FAIL: TestCgoTracebackSigpanic
FAIL: TestCrashDumpsAllThreads
FAIL: TestCrashHandler
FAIL: TestEnsureDropM
FAIL: TestGccgoCrashTraceback
FAIL: TestGccgoCrashTracebackNodebug
FAIL: TestGCFairness
FAIL: TestGCFairness2
FAIL: TestGoexitCrash
FAIL: TestGoexitDeadlock
FAIL: TestGoexitInPanic
FAIL: TestGoNil
FAIL: TestInitDeadlock
FAIL: TestLargeStringConcat
FAIL: TestLockedDeadlock
FAIL: TestLockedDeadlock2
FAIL: TestLockOSThreadExit
FAIL: TestMainGoroutineID
FAIL: TestNetpollDeadlock
FAIL: TestNoHelperGoroutines
FAIL: TestNumGoroutine
FAIL: TestPanicAfterGoexit
FAIL: TestPanicDeadlockGosched
FAIL: TestPanicDeadlockSyscall
FAIL: TestPanicLoop
FAIL: TestPanicRace
FAIL: TestPanicTraceback
FAIL: TestRecoveredPanicAfterGoexit
FAIL: TestRecursivePanic
FAIL: TestSignalDuringExec
FAIL: TestSignalExitStatus
FAIL: TestSignalIgnoreSIGTRAP
FAIL: TestSigStackSwapping
FAIL: TestSimpleDeadlock
FAIL: TestThreadExhaustion
FAIL: go test misc/cgo/test
FAIL: go test misc/cgo/testcarchive
FAIL: go test cmd/vet

[Bug target/85628] New: Make better use of BFI (BFXIL)

[ktkachov at gcc dot gnu.org]

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

Bug ID: 85628
   Summary: Make better use of BFI (BFXIL)
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ktkachov at gcc dot gnu.org
  Target Milestone: ---
Target: aarch64

The testcase:
unsigned long long combine(unsigned long long a, unsigned long long b) {
return (a & 0xll) | (b & 0xll);
}

void read2(unsigned long long a, unsigned long long b, unsigned long long *c,
unsigned long long *d) {
*c = combine(a, b); *d = combine(b, a);
}

on aarch64 with -O2 currently generates:
combine:
bfi x0, x1, 0, 32
ret

read2:
and x5, x1, 4294967295
and x4, x0, -4294967296
orr x4, x4, x5
and x1, x1, -4294967296
and x0, x0, 4294967295
str x4, [x2]
orr x0, x0, x1
str x0, [x3]
ret

With LLVM it does a better job:
combine:// @combine
bfxil   x0, x1, #0, #32
ret

read2:  // @read2
mov x8, x0
bfxil   x8, x1, #0, #32
bfxil   x1, x0, #0, #32
str x8, [x2]
str x1, [x3]
ret

This should just be a matter of adding the necessary patterns in aarch64.md.
Combine already tries to match:

(set (reg:DI 105)
(ior:DI (and:DI (reg/v:DI 97 [ b ])
(const_int -4294967296 [0x]))
(and:DI (reg/v:DI 96 [ a ])
(const_int 4294967295 [0x]

[Bug middle-end/60646] Investigate improved complex division algorithms

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 CC||ktkachov at gcc dot gnu.org

--- Comment #7 from ktkachov at gcc dot gnu.org ---
Regarding performance, the paper from the description indicates the "Improved"
algorithm is the highest performing one and is more resistant to overflows and
underflows. Am I reading that right?

[Bug target/85593] GCC on ARM allocates R3 for local variable when calling naked function with O2 optimizations enabled

[austinpmorton at gmail dot com]

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

--- Comment #4 from Austin Morton  ---
In my particular case I was able to work around the issue by removing the naked
attribute and using extended assembly with a clobbers list.

The resulting code is nearly identical (allowing GCC to generate the correct
pro/epilog instead of hand writing it), and gcc correctly allocates R4 instead
of R3.

This still feels like a bug in GCC.  In the example I gave, if you compiled the
naked function in a separate C file and linked them it would generate the
correct code.  The issue is that GCC is able to "see" the naked function and is
performing optimizations that it shouldn't as a result.

I believe that GCC should treat naked functions as opaque as far as
optimizations are concerned.
At the very least, there should be a note about this kind of issue included in
the documentation of the naked attribute.

[Bug libstdc++/84535] std::thread constructor missing constraint on first argument

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
Author: redi
Date: Thu May  3 14:08:36 2018
New Revision: 259893

URL: https://gcc.gnu.org/viewcvs?rev=259893=gcc=rev
Log:
PR libstdc++/84535 constrain std::thread constructor

The standard requires that the std::thread constructor is constrained so
it can't be called with a first argument of type std::thread. The
current implementation only meets that requirement if the constructor is
called with one argument, by using deleted overloads. This uses an
enable_if constraint to enforce the requirement for any number of
arguments.

Also add a static assertion to give a more readable error for invalid
arguments that cannot be invoked. Also simplify _Invoker to reduce the
error cascade for ill-formed instantiations with non-invocable
arguments.

PR libstdc++/84535
* include/std/thread (thread::__not_same): New SFINAE helper.
(thread::thread(_Callable&&, _Args&&...)): Add SFINAE constraint that
first argument is not a std::thread. Add static assertion to check
INVOKE expression is valid.
(thread::thread(thread&), thread::thread(const thread&&)): Remove.
(thread::_Invoke::_M_invoke, thread::_Invoke::operator()): Use
__invoke_result for return types and remove exception specifications.
* testsuite/30_threads/thread/cons/84535.cc: New.

Added:
trunk/libstdc++-v3/testsuite/30_threads/thread/cons/84535.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/std/thread

[Bug c++/67650] undef reference with -fdevirtualize

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||link-failure

--- Comment #29 from Jonathan Wakely  ---
(In reply to Vincent from comment #27)
> Sorry for the silly check, are you sure you are trying with -O3 or
> -fdevirtualize -O2? 

I've tried both. I'm using x86_64-pc-linux-gnu though.


> You can try this with 8.1:
> 
> void *v;
> 
> template 
> struct LK: public BLKC
> {
>   void rb(){((T*)v)->ax();}
>   static T* st;
> };
> 
> As a replacement to the call to null, and the missing definition problem is
> reported.

OK now I can reproduce it with trunk.

(In reply to Vincent from comment #28)
> Other silly check, did you try with my code or your reduced code ?

Yours.

Here's the reduced form that gives a link-error with trunk:

#include 

template 
struct RE
{
  virtual void rp()=0;
  void ax(){rp();}
};

struct EN : RE
{
  EN(::std::string = ""){}
  void rp(){}
};

template 
struct AN : RE
{
  void rp(){}
};

template 
struct LK
{
  T* p = nullptr;
  virtual void rb(){p->ax();}
};

template 
struct LR
{
  virtual ~LR(){}
  struct LLC { virtual ~LLC(){} };
  LK l;
};

constexpr char ET[]="";
struct I : EN
{
  LR _e;
};

int main(){new I();}


$ ~/gcc/8.1.0/bin/g++ -Wall -O1 -fdevirtualize main.cc 
main.cc:19:8: warning: ‘void AN::rp() [with OC = LR<(& ET)>::LLC]’ used but
never defined
   void rp(){}
^~
/tmp/cc4IHAPf.o: In function `LK::LLC> >::rb()':
main.cc:(.text+0x37): undefined reference to `AN::LLC>::rp()'
collect2: error: ld returned 1 exit status

[Bug fortran/85599] invalid optimization: function not always evaluated in logical expression

[dominiq at lps dot ens.fr]

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

--- Comment #11 from Dominique d'Humieres  ---
> Am I mistaken to read this as being handled by the middle-end?
> If yes, the situation is discussed in pr57160 comment 1.

I meant "If no"!-(

[Bug testsuite/85106] Add scan-ltrans-tree-dump and scan-wpa-ipa-dump

[vries at gcc dot gnu.org]

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

--- Comment #13 from Tom de Vries  ---
Author: vries
Date: Thu May  3 13:47:14 2018
New Revision: 259892

URL: https://gcc.gnu.org/viewcvs?rev=259892=gcc=rev
Log:
[testsuite] Add scan-offload-tree-dump

2018-05-03  Tom de Vries  

PR testsuite/85106
* lib/scanoffloadtree.exp: New file.

* testsuite/lib/libgomp-dg.exp (libgomp-dg-test): Add save-temps to
extra_tool_flags if it contains an -foffload=-fdump-* flag.
* testsuite/lib/libgomp.exp: Include scanoffloadtree.exp.
* testsuite/libgomp.oacc-c/vec.c: Use scan-offload-tree-dump.

* doc/sourcebuild.texi (Commands for use in dg-final, Scan optimization
dump files): Add offload-tree.

Added:
trunk/gcc/testsuite/lib/scanoffloadtree.exp
Modified:
trunk/gcc/ChangeLog
trunk/gcc/doc/sourcebuild.texi
trunk/gcc/testsuite/ChangeLog
trunk/libgomp/ChangeLog
trunk/libgomp/testsuite/lib/libgomp-dg.exp
trunk/libgomp/testsuite/lib/libgomp.exp
trunk/libgomp/testsuite/libgomp.oacc-c/vec.c

[Bug fortran/85599] invalid optimization: function not always evaluated in logical expression

[dominiq at lps dot ens.fr]

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

--- Comment #10 from Dominique d'Humieres  ---
Dumping the original tree of the test in comment 0 gives

...
lazy ()
{
  static logical(kind=4) check (void);
  logical(kind=4) flag;

  flag = 0;
  flag = check () && flag;
  flag = flag && check ();
}
...

Am I mistaken to read this as being handled by the middle-end? If yes, the
situation is discussed in pr57160 comment 1.

> *
> 7.1.4 Evaluation of operations
> 2 The evaluation of a function reference shall neither affect nor be affected
> by the evaluation of any other entity within the statement.
> *

Does it means that 'check' has to be evaluated in

if (flag) flag = check ()

even if flag==.false. ?

[Bug tree-optimization/70291] muldc3 code generation could be smarter

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
  Known to work||9.0
 Resolution|--- |FIXED
   Target Milestone|--- |9.0

--- Comment #4 from ktkachov at gcc dot gnu.org ---
Implemented for GCC 9.

[Bug c++/67650] undef reference with -fdevirtualize

[vincent.lextrait at gmail dot com]

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

--- Comment #28 from Vincent  ---
Other silly check, did you try with my code or your reduced code ?

(In reply to Jonathan Wakely from comment #26)
> (In reply to Vincent from comment #25)
> > Oh, it used to be the case. I think that must be due to some additional
> > artefact of more recent compilers. I'll try to find another way to show it.
> 
> I tried 5.1.0 and 5.2.0 and several other previous releases, they all link
> the program successfully, with just this warning:
> 
> main.cpp:53:8: warning: 'I' has a field 'I::_e' whose type uses the
> anonymous namespace

[Bug tree-optimization/85615] [8 Regression] ICE at -O2 and above on valid code on x86_64-linux-gnu: in dfs_enumerate_from, at cfganal.c:1197

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||9.0
Summary|[8/9 Regression] ICE at -O2 |[8 Regression] ICE at -O2
   |and above on valid code on  |and above on valid code on
   |x86_64-linux-gnu: in|x86_64-linux-gnu: in
   |dfs_enumerate_from, at  |dfs_enumerate_from, at
   |cfganal.c:1197  |cfganal.c:1197

--- Comment #7 from Richard Biener  ---
Fixed on trunk sofar.

[Bug tree-optimization/85615] [8/9 Regression] ICE at -O2 and above on valid code on x86_64-linux-gnu: in dfs_enumerate_from, at cfganal.c:1197

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener  ---
Author: rguenth
Date: Thu May  3 13:20:02 2018
New Revision: 259891

URL: https://gcc.gnu.org/viewcvs?rev=259891=gcc=rev
Log:
2018-05-03  Richard Biener  

PR tree-optimization/85615
* tree-ssa-threadupdate.c (thread_block_1): Only allow exits
to loops not nested in BBs loop father to avoid creating multi-entry
loops.

* gcc.dg/torture/pr85615.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr85615.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-threadupdate.c

[Bug c++/67650] undef reference with -fdevirtualize

[vincent.lextrait at gmail dot com]

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

--- Comment #27 from Vincent  ---
Sorry for the silly check, are you sure you are trying with -O3 or
-fdevirtualize -O2? 

You can try this with 8.1:

void *v;

template 
struct LK: public BLKC
{
  void rb(){((T*)v)->ax();}
  static T* st;
};

As a replacement to the call to null, and the missing definition problem is
reported.

(In reply to Jonathan Wakely from comment #26)
> (In reply to Vincent from comment #25)
> > Oh, it used to be the case. I think that must be due to some additional
> > artefact of more recent compilers. I'll try to find another way to show it.
> 
> I tried 5.1.0 and 5.2.0 and several other previous releases, they all link
> the program successfully, with just this warning:
> 
> main.cpp:53:8: warning: 'I' has a field 'I::_e' whose type uses the
> anonymous namespace

[Bug c++/67650] undef reference with -fdevirtualize

[redi at gcc dot gnu.org]

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

--- Comment #26 from Jonathan Wakely  ---
(In reply to Vincent from comment #25)
> Oh, it used to be the case. I think that must be due to some additional
> artefact of more recent compilers. I'll try to find another way to show it.

I tried 5.1.0 and 5.2.0 and several other previous releases, they all link the
program successfully, with just this warning:

main.cpp:53:8: warning: 'I' has a field 'I::_e' whose type uses the anonymous
namespace

[Bug libstdc++/84535] std::thread constructor missing constraint on first argument

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #2 from Jonathan Wakely  ---
Fixed for GCC 9

[Bug c++/67650] undef reference with -fdevirtualize

[vincent.lextrait at gmail dot com]

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

--- Comment #25 from Vincent  ---
Oh, it used to be the case. I think that must be due to some additional
artefact of more recent compilers. I'll try to find another way to show it.

(In reply to Jonathan Wakely from comment #24)
> (In reply to Vincent from comment #22)
> > See comment #6.
> 
> I already saw it, and I already tried that change. The problem disappears if
> you make that change. 
> 
> (In reply to Vincent from comment #23)
> > See comment #10. The error is sensitive to unrelated changes. There is some
> > (front-end?) corruption somewhere.
> 
> I'm not convinced by that either.

[Bug fortran/65086] Segfault: Invalid copy-out of temporary as argument is in read-only memory

[juergen.reuter at desy dot de]

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

Jürgen Reuter  changed:

   What|Removed |Added

 CC||juergen.reuter at desy dot de

--- Comment #2 from Jürgen Reuter  ---
I rechecked this. Same situation still with gfortran 9.0. Also ran nagfor.
nagfor behaves the same way as gfortran does, so the seg fault is only gone if
the intent(in) in sub4 is added.

[Bug c++/67650] undef reference with -fdevirtualize

[redi at gcc dot gnu.org]

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

--- Comment #24 from Jonathan Wakely  ---
(In reply to Vincent from comment #22)
> See comment #6.

I already saw it, and I already tried that change. The problem disappears if
you make that change. 

(In reply to Vincent from comment #23)
> See comment #10. The error is sensitive to unrelated changes. There is some
> (front-end?) corruption somewhere.

I'm not convinced by that either.

[Bug tree-optimization/70291] muldc3 code generation could be smarter

[ktkachov at gcc dot gnu.org]

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

--- Comment #3 from ktkachov at gcc dot gnu.org ---
Author: ktkachov
Date: Thu May  3 12:59:43 2018
New Revision: 259889

URL: https://gcc.gnu.org/viewcvs?rev=259889=gcc=rev
Log:
[tree-complex.c] PR tree-optimization/70291: Inline floating-point complex
multiplication more aggressively

We can improve the performance of complex floating-point multiplications by
inlining the expansion a bit more aggressively.
We can inline complex x = a * b as:
x = (ar*br - ai*bi) + i(ar*bi + br*ai);
if (isunordered (__real__ x, __imag__ x))
  x = __muldc3 (a, b); //Or __mulsc3 for single-precision

That way the common case where no NaNs are produced we can avoid the libgcc
call and fall back to the
NaN handling stuff in libgcc if either components of the expansion are NaN.

The implementation is done in expand_complex_multiplication in tree-complex.c
and the above expansion
will be done when optimising for -O1 and greater and when not optimising for
size.
At -O0 and -Os the single call to libgcc will be emitted.

For the code:
__complex double
foo (__complex double a, __complex double b)
{
  return a * b;
}

We will now emit at -O2 for aarch64:
foo:
fmuld16, d1, d3
fmuld6, d1, d2
fnmsub  d5, d0, d2, d16
fmadd   d4, d0, d3, d6
fcmpd5, d4
bvs .L8
fmovd1, d4
fmovd0, d5
ret
.L8:
stp x29, x30, [sp, -16]!
mov x29, sp
bl  __muldc3
ldp x29, x30, [sp], 16
ret

Instead of just a branch to __muldc3.

PR tree-optimization/70291
* tree-complex.c (expand_complex_libcall): Add type, inplace_p
arguments.  Change return type to tree.  Emit libcall as a new
statement rather than replacing existing one when inplace_p is true.
(expand_complex_multiplication_components): New function.
(expand_complex_multiplication): Expand floating-point complex
multiplication using the above.
(expand_complex_division): Rename inner_type parameter to type.
Update expand_complex_libcall call-site.
(expand_complex_operations_1): Update expand_complex_multiplication
and expand_complex_division call-sites.

* gcc.dg/complex-6.c: New test.
* gcc.dg/complex-7.c: Likewise.

Added:
trunk/gcc/testsuite/gcc.dg/complex-6.c
trunk/gcc/testsuite/gcc.dg/complex-7.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-complex.c

[Bug lto/48200] linking shared library with LTO results in different exported symbols

[ryxi at stu dot xidian.edu.cn]

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

--- Comment #18 from Xi Ruoyao  ---
(In reply to Xi Ruoyao from comment #17)

> I prefer
> 
> int pci_fill_info(struct pci_dev *, int)
> __attribute__((symver_alias("@LIBPCI_3.0", "pci_fill_info_v31")));

But then what should we do for

int pci_fill_info(struct pci_dev *, int)
__attribute__((symver_alias("@LIBPCI_3.0", "pci_fill_info_v31")));

int pci_fill_info(struct pci_dev *, int)
__attribute__((symver_alias("@LIBPCI_3.1", "pci_fill_info_v32")));

[Bug target/81084] [8 Regression] powerpcspe port full of confusing configury / command-line options not related to SPE

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #53 from John Paul Adrian Glaubitz  ---
(In reply to Andrew Jenner from comment #52)
> (In reply to John Paul Adrian Glaubitz from comment #51)
> > Absolutely. Where should I test the patch? Natively on powerpcspe? On
> > x86_64? Or anything else? We have a wide range of architectures available
> > for testing.
> 
> The patch only changes the powerpcspe backend - there's no need to test it
> against any other targets.

Ok. I will try a native build then.

[Bug target/81084] [8 Regression] powerpcspe port full of confusing configury / command-line options not related to SPE

[andrewjenner at gcc dot gnu.org]

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

--- Comment #52 from Andrew Jenner  ---
(In reply to John Paul Adrian Glaubitz from comment #51)
> Absolutely. Where should I test the patch? Natively on powerpcspe? On
> x86_64? Or anything else? We have a wide range of architectures available
> for testing.

The patch only changes the powerpcspe backend - there's no need to test it
against any other targets.

[Bug c++/67650] undef reference with -fdevirtualize

[vincent.lextrait at gmail dot com]

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

--- Comment #23 from Vincent  ---
See comment #10. The error is sensitive to unrelated changes. There is some
(front-end?) corruption somewhere.

(In reply to Jonathan Wakely from comment #21)
> Comment 19 shows a bogus warning triggered by -fdevirtualize but I'm not
> convinced the original report of a link-error bug is valid.

[Bug c++/67650] undef reference with -fdevirtualize

[vincent.lextrait at gmail dot com]

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

--- Comment #22 from Vincent  ---
See comment #6.

(In reply to Jonathan Wakely from comment #20)
> (In reply to Vincent from comment #5)
> > The problem is static time, not dynamic time.
> > This artefact is just a result of source code reduction. In  my code there
> > is no "0", and the problem exists.
> 
> Are you sure about that? Using your original testcase I can only reproduce
> the link error when it has ((T*)0)->ax()

[Bug target/81084] [8 Regression] powerpcspe port full of confusing configury / command-line options not related to SPE

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #51 from John Paul Adrian Glaubitz  ---
(In reply to Andrew Jenner from comment #50),
> 
> Thanks for the offer of help. I already have hardware, but I need to get my
> test scripts in order.

Ok, great!

> I'm attaching my current patch. If you could get some
> test results with and without this patch to make sure it doesn't break
> anything, that would be a tremendous help.

Absolutely. Where should I test the patch? Natively on powerpcspe? On x86_64?
Or anything else? We have a wide range of architectures available for testing.

> Unfortunately I've been
> side-tracked onto other projects and haven't been able to give this the
> attention it deserves, but I hope to get back to it in the next couple of
> weeks. Thanks again!

No worries. Your efforts are highly appreciated and I'm happy to help whereever
I can.

[Bug target/81084] [8 Regression] powerpcspe port full of confusing configury / command-line options not related to SPE

[andrewjenner at gcc dot gnu.org]

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

Andrew Jenner  changed:

   What|Removed |Added

  Attachment #43312|0   |1
is obsolete||

--- Comment #50 from Andrew Jenner  ---
Created attachment 44056
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44056=edit
Patch in progress as of 2018/05/03

Hi John,

Thanks for the offer of help. I already have hardware, but I need to get my
test scripts in order. I'm attaching my current patch. If you could get some
test results with and without this patch to make sure it doesn't break
anything, that would be a tremendous help. Unfortunately I've been side-tracked
onto other projects and haven't been able to give this the attention it
deserves, but I hope to get back to it in the next couple of weeks. Thanks
again!

[Bug c++/85600] [9 Regression] CPU2006 471.omnetpp fails starting with r259771

[sudi at gcc dot gnu.org]

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

sudi at gcc dot gnu.org changed:

   What|Removed |Added

 CC||sudi at gcc dot gnu.org

--- Comment #7 from sudi at gcc dot gnu.org ---
Also failing on aarch64 targets.

[Bug libstdc++/84949] -ffast-math bugged with respect to NaNs

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
std::numeric_limits defines:

  static _GLIBCXX_USE_CONSTEXPR bool has_infinity = __FLT_HAS_INFINITY__;
  static _GLIBCXX_USE_CONSTEXPR bool has_quiet_NaN = __FLT_HAS_QUIET_NAN__;
  static _GLIBCXX_USE_CONSTEXPR bool has_signaling_NaN = has_quiet_NaN;
  static _GLIBCXX_USE_CONSTEXPR float_denorm_style has_denorm
= bool(__FLT_HAS_DENORM__) ? denorm_present : denorm_absent;
  //...
  static _GLIBCXX_USE_CONSTEXPR bool is_iec559
= has_infinity && has_quiet_NaN && has_denorm == denorm_present;

And that seems to be the right thing to do. If the compiler tells us the type
has infinities and NaNs then we expose that through std::numeric_limits.

I don't think we want the C++ library to be inconsistent with the compiler
here. So maybe any change should be in the compiler not libstdc++.

[Bug tree-optimization/85588] [6/7/8/9 Regression] -fwrapv miscompilation

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
Or rather

Index: gcc/fold-const.c
===
--- gcc/fold-const.c(revision 259879)
+++ gcc/fold-const.c(working copy)
@@ -474,12 +474,15 @@ negate_expr_p (tree t)
 case EXACT_DIV_EXPR:
   if (TYPE_UNSIGNED (type))
break;
-  if (negate_expr_p (TREE_OPERAND (t, 0)))
+  /* In general we can't negate A in A / B, because if A is INT_MIN and
+ B is not 1 we change the sign of the result.  */
+  if (TREE_CODE (TREE_OPERAND (t, 0)) == INTEGER_CST
+ && negate_expr_p (TREE_OPERAND (t, 0)))
return true;
   /* In general we can't negate B in A / B, because if A is INT_MIN and
 B is 1, we may turn this into INT_MIN / -1 which is undefined