[Bug fortran/86863] [OOP][F2008] type-bound module procedure name not recognized

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-08-06
 CC||janus at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from janus at gcc dot gnu.org ---
(In reply to Damian Rouson from comment #0)
> With gfortran 7.3.0 and 6.4.0, the code below causes an ICE.
>
> [..]
> 
>  call object%foobar
>   1
> Error: ‘foobar’ at (1) should be a SUBROUTINE

I can confirm this error with version 6 to trunk, but I don't see the ICE.

[Bug c++/57891] No diagnostic of narrowing conversion in non-type template argument

[mpolacek at gcc dot gnu.org]

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

--- Comment #10 from Marek Polacek  ---
Right, we're still hashing this out on the mailing list.  But I expect it to be
fixed soon.

There are similar cases not handled by my current patch, but I'll work on those
next.

[Bug c++/86871] ICE: gimple check: expected gimple_assign(error_mark), have gimple_call(trunc_mod_expr) in gimple_assign_lhs, at gimple.h:2462

[slyfox at inbox dot ru]

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

--- Comment #1 from Sergei Trofimovich  ---
Managed to get rid of templates. Looks like use of uninitialized 'i' is somehow
the culprit:

int *f;
struct g {
  g() {
f = new int;
aj = f;
  }
  int [](int h) { return *(aj + h); }
  int *aj;
};
void j() {
  g b;
  g c;
  for (int i; i; i++) {
int d = 0;
for (int e = -1; e <= 1; e++) {
  int a = i + e;
  if (a)
d = b[a];
}
c[i] = d;
  }
}

[Bug libstdc++/86861] 18_support/new_aligned.cc FAILs

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #3 from Jonathan Wakely  ---
> Great, thanks for testing it. Is it fixed for 64-bit as well as 32-bit? I was
> concerned that "the size of a word" might actually be imprecise and should be
> sizeof(void*) not sizeof(int).

It is.  In fact, I found the following comment in the OpenSolaris
sources of memalign.c, still in Illumos:

https://github.com/illumos/illumos-gate/blob/master/usr/src/lib/libc/port/gen/memalign.c#L35

#define _misaligned(p)  ((unsigned)(p) & 3)
/* 4-byte "word" alignment is considered ok in LP64 */

[Bug c/86873] New: "gcc -lmcheck" aborts on free when using posix_memalign

[ben at tawesoft dot co.uk]

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

Bug ID: 86873
   Summary: "gcc -lmcheck" aborts on free when using
posix_memalign
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ben at tawesoft dot co.uk
  Target Milestone: ---

Created attachment 44513
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44513=edit
Minimal example (.i version)

Simple C programs using `posix_memalign()` and `free()`, compiled with `gcc
-lmcheck`, cause the resulting binary to raise a runtime error such as
`munmap_chunk(): invalid pointer`.

For example,

#include 
#include 

int main()
{
void *p = 0;
int ret = posix_memalign(, sizeof(void*), 0);
printf("ret was %d, pointer is %p\n", ret, p);
free(p);
return 0;
}


The full example including headers is attached.

Note that "POSIX requires that memory obtained from posix_memalign() can be 
freed using free".

Output (my system):

$ gcc test.c -lmcheck -ggdb
$ ./a.out
ret was 0, pointer is 0xcb6090
*** Error in `./a.out': munmap_chunk(): invalid pointer: 0x00cb6060
***
Aborted

Output (NVIDIA developer):

$ gcc test.c -lmcheck -ggdb
$ ./a.out
ret was 0, pointer is 0x558c32d102e0
munmap_chunk(): invalid pointer
Aborted (core dumped)

Expected output:

$ gcc test.c -lmcheck -ggdb
$ ./a.out
ret was 0, pointer is 0x

This was initially discovered due to posix_memalign's use in the Nvidia
graphics driver -- discussion here, three people report same symptoms:
https://devtalk.nvidia.com/default/topic/1037171/linux/memory-error-in-glx-programs-when-linked-with-gcc-lmcheck/

For me, here is the GCC version that raises this. I am aware this is an old
version of GCC as provided by what is currently Debian odstable (Jessie), but
others have reported the same results.

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.9/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian
4.9.2-10+deb8u1' --with-bugurl=file:///usr/share/doc/gcc-4.9/README.Bugs
--enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.9 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.9 --libdir=/usr/lib --enable-nls
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-vtable-verify
--enable-plugin --with-system-zlib --disable-browser-plugin
--enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.9-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --with-arch-32=i586 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 4.9.2 (Debian 4.9.2-10+deb8u1) 

Obviously, I am using an old version of GCC but I hope this bug report may be
of use to anyone using a search engine to lookup a problem with this possible
lmcheck false positive.

[Bug libstdc++/86861] 18_support/new_aligned.cc FAILs

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #1 from Jonathan Wakely  ---
> (In reply to Rainer Orth from comment #0)
>> Thew new 18_support/new_aligned.cc test FAILs on Solaris 10 (sparc and x86),
>> which lacks aligned_alloc in libc:
>
> Ah good, I thought that testcase might shake out some more Solaris bugs :-)
>
> Which implementation in libsupc++/new_opa.cc gets used? Is posix_memalign
> available? Or memalign?

It's memalign indeed.  posix_memalign and aligned_alloc were introduced
at different points in the Solaris 11 release series.

> I'm guessing it uses memalign, and Solaris memalign has an additional
> requirement that posix_memalign has, but GNU memalign doesn't:
>
>   The value of alignment must be a power of two and must be greater than or
>   equal to the size of a word.

Indeed: this goes back as far as Solaris 2.5.1 and still exists in 11.5.

> So maybe this will fix it:
[...]
It did indeed: bootstrapped on i386-pc-solaris2.10 where

-FAIL: 18_support/new_aligned.cc execution test
-FAIL: 20_util/memory_resource/2.cc execution test

are now gone and i386-pc-solaris2.11 (unchanged).

Thanks.
Rainer

[Bug c/86873] "gcc -lmcheck" aborts on free when using posix_memalign

[ben at tawesoft dot co.uk]

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

--- Comment #3 from ben at tawesoft dot co.uk ---
Thanks for directing me to the appropriate channel

Here is the link to the matching glibc bug report those anyone following this

https://sourceware.org/bugzilla/show_bug.cgi?id=23489

[Bug bootstrap/86872] New: [9 Regression] LTO bootstrap failed with profiledbootstrap

[hjl.tools at gmail dot com]

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

Bug ID: 86872
   Summary: [9 Regression] LTO bootstrap failed with
profiledbootstrap
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
  Target Milestone: ---

On x86-64, r263300 gave

In function ‘gimple_simplify_32’:
lto1: internal compiler error: in linemap_check_ordinary, at
libcpp/include/line-map.h:587
0x5e2991 ???
../../src-trunk/libcpp/include/line-map.h:587
0x93aeae ???
../../src-trunk/libcpp/line-map.c:754
0x1d653e2 ???
../../src-trunk/gcc/lto-streamer-in.c:194
0x1d6661f ???
../../src-trunk/gcc/lto-streamer-in.c:304
0xbc5f88 ???
../../src-trunk/gcc/gimple-streamer-in.c:111
0x91d3c7 lto_read_body_or_constructor(lto_file_decl_data*, symtab_node*, char
const*, lto_section_type) [clone .isra.95] [clone .constprop.697]
../../src-trunk/gcc/lto-streamer-in.c:1092
0x22631cd ???
../../src-trunk/gcc/lto-streamer-in.c:1343
0x226e950 ???
../../src-trunk/gcc/cgraphunit.c:2086
0x227fa1b ???
../../src-trunk/gcc/cgraphunit.c:2254
0x23a9564 ???
../../src-trunk/gcc/lto/lto.c:3426
0x1ab4a59 ???
../../src-trunk/gcc/toplev.c:455
0x1ab7d67 ???
../../src-trunk/gcc/toplev.c:2161
0x904cca ???
../../src-trunk/gcc/main.c:39
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

when GCC is configured with

--with-build-config=bootstrap-lto --disable-werror

and built with profiledbootstrap. r263286 is OK.

[Bug c/86873] "gcc -lmcheck" aborts on free when using posix_memalign

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #1)
> libmcheck is from glibc, please report it to them.

https://sourceware.org/bugzilla/

[Bug c/86873] "gcc -lmcheck" aborts on free when using posix_memalign

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |MOVED

--- Comment #1 from Andrew Pinski  ---
libmcheck is from glibc, please report it to them.

[Bug c++/57891] No diagnostic of narrowing conversion in non-type template argument

[tadeus.prastowo at unitn dot it]

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

--- Comment #9 from Tadeus Prastowo  ---
This problem still exists in the trunk (cf. https://godbolt.org/g/bRf18i). 
Clang correctly keeps rejecting it (cf. https://godbolt.org/g/egcNtV).  Both
use the following MWE:

template
struct X {
  static constexpr unsigned data {a};
};

int main() {
  return X<-1>::data;
}

[Bug c++/86871] New: ICE: gimple check: expected gimple_assign(error_mark), have gimple_call(trunc_mod_expr) in gimple_assign_lhs, at gimple.h:2462

[slyfox at inbox dot ru]

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

Bug ID: 86871
   Summary: ICE: gimple check: expected gimple_assign(error_mark),
have gimple_call(trunc_mod_expr) in gimple_assign_lhs,
at gimple.h:2462
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: slyfox at inbox dot ru
  Target Milestone: ---

Created attachment 44511
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44511=edit
a.cc

Original bug report where g++ crashes when compiling opencv-3.4.1:
https://bugs.gentoo.org/657060

Also reproducible on gcc-master:

$ ./gcc/xg++ -B ./gcc -c /tmp/a.cc -O2 -march=bdver4 -ftree-vectorize
during GIMPLE pass: vect
/tmp/a.cc: In function 'void fn1()':
/tmp/a.cc:34:6: internal compiler error: gimple check: expected
gimple_assign(error_mark), have gimple_call(trunc_mod_expr) in
gimple_assign_lhs, at gimple.h:2462
 void fn1() {
  ^~~
0x7f822fff979a __libc_start_main
../csu/libc-start.c:308
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

$ ./gcc/xg++ -v
Using built-in specs.
COLLECT_GCC=./gcc/xg++
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --enable-languages=c,c++ --disable-bootstrap
--with-multilib-list=m64
--prefix=/home/slyfox/dev/git/gcc-x86_64/../gcc-native-quick-installed
--disable-nls CFLAGS='-O0  ' CXXFLAGS='-O0  '
--with-sysroot=/usr/x86_64-HEAD-linux-gnu
Thread model: posix
gcc version 9.0.0 20180806 (experimental) (GCC)

[Bug c++/86871] ICE: gimple check: expected gimple_assign(error_mark), have gimple_call(trunc_mod_expr) in gimple_assign_lhs, at gimple.h:2462

[slyfox at inbox dot ru]

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

Sergei Trofimovich  changed:

   What|Removed |Added

  Attachment #44511|0   |1
is obsolete||

--- Comment #2 from Sergei Trofimovich  ---
Created attachment 44512
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44512=edit
a.cc

[Bug libstdc++/86874] New: std::swap on std::variant fails to compile

[aaron at bestateless dot com]

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

Bug ID: 86874
   Summary: std::swap on std::variant fails to compile
   Product: gcc
   Version: 8.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: aaron at bestateless dot com
  Target Milestone: ---

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

Example:

#include 

int main(int, char**) {
std::variant v1, v2;
std::swap(v1, v2);
}

Expected: Compiles successfully. (Worked for me on g++ 7.3).

Actual:

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

$ g++-8 -std=c++17 test.cpp -save-temps
In file included from test.cpp:1:
/usr/include/c++/8/variant: In instantiation of 'void
std::variant<_Types>::swap(std::variant<_Types>&) [with _Types =
{std::monostate}]':
/usr/include/c++/8/variant:1010:7:   required from
'std::enable_if_t<((is_move_constructible_v<_Types> && ...) &&
(is_swappable_v<_Types> && ...))> std::swap(std::variant<_Types ...>&,
std::variant<_Types ...>&) [with _Types = {std::monostate};
std::enable_if_t<((is_move_constructible_v<_Types> && ...) &&
(is_swappable_v<_Types> && ...))> = void]'
test.cpp:5:21:   required from here
/usr/include/c++/8/variant:1265:12: error: 'class std::variant'
has no member named '_M_destructive_move'
  this->_M_destructive_move(std::move(__rhs));
  ~~^~~
/usr/include/c++/8/variant:1270:12: error: 'class std::variant'
has no member named '_M_destructive_move'
  __rhs._M_destructive_move(std::move(*this));
  ~~^~~
/usr/include/c++/8/variant:1276:12: error: 'class std::variant'
has no member named '_M_destructive_move'
  __rhs._M_destructive_move(std::move(*this));
  ~~^~~
/usr/include/c++/8/variant:1277:12: error: 'class std::variant'
has no member named '_M_destructive_move'
  this->_M_destructive_move(std::move(__tmp));
  ~~^~~
```

[Bug target/71727] -O3 -mstrict-align produces code which assumes unaligned vector accesses work

[sje at gcc dot gnu.org]

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

Steve Ellcey  changed:

   What|Removed |Added

 CC||sje at gcc dot gnu.org

--- Comment #6 from Steve Ellcey  ---
Is there any reason this defect cannot be closed out?

[Bug libstdc++/86861] 18_support/new_aligned.cc FAILs

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
   Target Milestone|9.0 |8.3

--- Comment #5 from Jonathan Wakely  ---
Perfect, thanks.

[Bug c++/85747] suboptimal code without constexpr

[zamazan4ik at tut dot by]

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

Alexander Zaitsev  changed:

   What|Removed |Added

 CC||zamazan4ik at tut dot by

--- Comment #8 from Alexander Zaitsev  ---
(In reply to Marc Glisse from comment #5)
> (In reply to Antony Polukhin from comment #4)
> > Does providing some kind of -Oon-the-fly switch solves the issue with JIT
> > compile times while still allows more optimizations for the traditional non
> > JIT  -O2 builds?
> 
> Not sure what you mean by -Oon-the-fly. If you want to JIT compile the code,
> you more or less need to embed a compiler in the executable...
> 
> The closest I can think of is -fprofile-values. It is possible to collect
> the values of constants during a training run and use them during a second
> compilation. But then knowing more constants in one compilation than the
> other may change the code in ways that the PGO framework will not like.

As I understand Anthony meant here some compiler option which allows to
compiler some "aggresive" mode for detecting code which can be calculated at
compile-time as much as possible, even if it will increase significantly
compilation time. Of course this flag must be disabled by default even with -O3

[Bug libstdc++/86861] 18_support/new_aligned.cc FAILs

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
Great, thanks for testing it. Is it fixed for 64-bit as well as 32-bit? I was
concerned that "the size of a word" might actually be imprecise and should be
sizeof(void*) not sizeof(int).

I'll commit a slightly improved patch tomorrow.

[Bug target/86807] spu port needs updating for CVE-2017-5753

[danglin at gcc dot gnu.org]

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

--- Comment #3 from John David Anglin  ---
Author: danglin
Date: Mon Aug  6 21:47:54 2018
New Revision: 263344

URL: https://gcc.gnu.org/viewcvs?rev=263344=gcc=rev
Log:
PR target/86807
* config/pa/pa.c (TARGET_HAVE_SPECULATION_SAFE_VALUE):
Define to speculation_safe_value_not_needed.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/pa/pa.c

[Bug bootstrap/86872] [9 Regression] LTO bootstrap failed with profiledbootstrap

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-08-07
 CC||dmalcolm at redhat dot com
   Target Milestone|--- |9.0
 Ever confirmed|0   |1

--- Comment #1 from H.J. Lu  ---
This is caused by r263298.

[Bug fortran/52473] CSHIFT slow - inline it?

[juergen.reuter at desy dot de]

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

--- Comment #18 from Jürgen Reuter  ---
The example by posted on May 20, 2017 on c.l.f. improved by Stefano Zaghi below
shows a factor of 10-20 improvement now in gfortran 9.0.0 including the work by
Thomas Koenig.
$ ./a.out
 Elapsed CPU time =   0.337644997 
 Elapsed CPU time =   0.292241003 
 Elapsed CPU time =   0.265654006

Here is the code:

program testme

  use, intrinsic :: iso_fortran_env

  implicit none

  integer(int32), parameter :: n = 200
  real(real32) :: a(n,n,n), b(n,n,n)
  integer(int32) :: j, k
  real(real64) :: t1, t2

  call random_number(a)

  do k = 1, 3
 call cpu_time ( t1 )
 do j = 1, 100
b = cshift(a, shift=1, DIM=k)
 end do
 call cpu_time ( t2 )
 write ( *, * ) 'Elapsed CPU time = ', t2-t1
  end do
end program testme

[Bug jit/66811] RFE: have jit dumps be compileable as C code

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

[Bug jit/66594] jitted code should use -mtune=native

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--- Comment #8 from Eric Gallager  ---
(In reply to Eric Gallager from comment #7)
> Confirming as an enhancement

...actually making that ASSIGNED (instead of NEW) due to that fitting.

[Bug target/52551] i686-interix3: winnt.c:400:8: error: ‘flag_writable_rel_rdata’ undeclared

[egallager at gcc dot gnu.org]

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

--- Comment #2 from Eric Gallager  ---
Is interix even still a thing or did it get deprecated or something?

[Bug other/25914] strsignal.c:558: warning: comparison between signed and unsigned

[egallager at gcc dot gnu.org]

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

--- Comment #8 from Eric Gallager  ---
(In reply to dave.anglin from comment #7)
> On 2018-05-07 4:05 PM, egallager at gcc dot gnu.org wrote:
> > Did this proposal ever happen?
> Yes:
> http://pubs.opengroup.org/onlinepubs/9699919799/functions/psignal.html

OK, so... time to change the libiberty one then? Or is it too late?

[Bug c++/86875] New: internal compiler error: in tsubst_copy, at cp/pt.c:15478

[ldalessandro at gmail dot com]

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

Bug ID: 86875
   Summary: internal compiler error: in tsubst_copy, at
cp/pt.c:15478
   Product: gcc
   Version: 8.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ldalessandro at gmail dot com
  Target Milestone: ---

ICE in 8.2 (Debian gcc package) when capturing `const` variable in y_combinator
recursive lambda. This code works fine in 7.x. Capturing by reference or copy
makes no difference. Removing `const` suppresses the ICE.

Attached reduced test.ii test case. 

 * g++ -std=c++14 -c -o test.o test.ii

 * Linux ** 4.16.0-2-amd64 #1 SMP Debian 4.16.16-2 (2018-06-22) x86_64
GNU/Linux

 * gcc version 8.2.0 (Debian 8.2.0-1) 

 * Configured with: ../src/configure -v --with-pkgversion='Debian 8.2.0-1'
--with-bugurl=file:///usr/share/doc/gcc-8/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr
--with-gcc-major-version-only --program-suffix=-8
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie
--with-system-zlib --with-target-system-zlib --enable-objc-gc=auto
--enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none --without-cuda-driver
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu

-
# Terminal session with details #
-

$ uname -a
Linux ** 4.16.0-2-amd64 #1 SMP Debian 4.16.16-2 (2018-06-22) x86_64
GNU/Linux

$ gcc --version
gcc (Debian 8.2.0-1) 8.2.0
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ cat test.cpp 
#include 

// Adapted from
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0200r0.html.
template
class y_combinator_result {
  Fun fun_;
 public:
  template
  explicit y_combinator_result(T &): fun_(std::forward(fun)) {}

  template
  decltype(auto) operator()(Args &&...args) {
return fun_(std::ref(*this), std::forward(args)...);
  }
};

template
decltype(auto) y_combinator(Fun &) {
  return y_combinator_result>(std::forward(fun));
}

int main() {
  const unsigned w = 1; // non-const works fine
  auto foo = y_combinator([=](auto foo) -> void {
  auto i = 0 + w;
  foo();
});
  foo();
  return 0;
}

$ g++ -v -std=c++14 -save-temps   -c -o test.o test.cpp
Using built-in specs.
COLLECT_GCC=g++
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 8.2.0-1'
--with-bugurl=file:///usr/share/doc/gcc-8/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr
--with-gcc-major-version-only --program-suffix=-8
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie
--with-system-zlib --with-target-system-zlib --enable-objc-gc=auto
--enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none --without-cuda-driver
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 8.2.0 (Debian 8.2.0-1) 
COLLECT_GCC_OPTIONS='-v' '-std=c++14' '-save-temps' '-c' '-o' 'test.o'
'-shared-libgcc' '-mtune=generic' '-march=x86-64'
 /usr/lib/gcc/x86_64-linux-gnu/8/cc1plus -E -quiet -v -imultiarch
x86_64-linux-gnu -D_GNU_SOURCE test.cpp -mtune=generic -march=x86-64 -std=c++14
-fpch-preprocess -o test.ii
ignoring duplicate directory "/usr/include/x86_64-linux-gnu/c++/8"
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory "/usr/local/include"
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-linux-gnu/8/../../../../x86_64-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /opt/intel/compilers_and_libraries_2018.1.163/linux/mkl/include
 /usr/include/c++/8
 

[Bug middle-end/86718] [9 Regression] ICE during RTL pass: expand

[zhonghao at pku dot org.cn]

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

--- Comment #2 from zhonghao at pku dot org.cn ---
My gcc:
gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-pc-linux-gnu/9.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc9.0/configure --enable-languages=c,c++
--disable-multilib
Thread model: posix
gcc version 9.0.0 20180715 (experimental) (GCC)

[Bug middle-end/54664] expand_gimple_cond warning for predictably small BRANCH_COST

[egallager at gcc dot gnu.org]

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

--- Comment #3 from Eric Gallager  ---
(In reply to Eric Gallager from comment #2)
> (In reply to Hans-Peter Nilsson from comment #1)
> > Also seen for 4.9.1 and 4.10.0 i.e. trunk r212879.
> 
> 4.10.0 became 5.0

...and regardless of which way it's numbered, that branch is closed now
anyways.

[Bug c++/86875] internal compiler error: in tsubst_copy, at cp/pt.c:15478

[ldalessandro at gmail dot com]

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

--- Comment #1 from Luke Dalessandro  ---
Created attachment 44515
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44515=edit
Preprocessed source

[Bug libstdc++/86861] 18_support/new_aligned.cc FAILs

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-08-06
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
(In reply to Rainer Orth from comment #0)
> Thew new 18_support/new_aligned.cc test FAILs on Solaris 10 (sparc and x86),
> which lacks aligned_alloc in libc:

Ah good, I thought that testcase might shake out some more Solaris bugs :-)

Which implementation in libsupc++/new_opa.cc gets used? Is posix_memalign
available? Or memalign?

I'm guessing it uses memalign, and Solaris memalign has an additional
requirement that posix_memalign has, but GNU memalign doesn't:

  The value of alignment must be a power of two and must be greater than or
  equal to the size of a word.

So maybe this will fix it:

--- a/libstdc++-v3/libsupc++/new_opa.cc
+++ b/libstdc++-v3/libsupc++/new_opa.cc
@@ -53,7 +53,14 @@ aligned_alloc (std::size_t al, std::size_t sz)
 #else
 extern "C" void *memalign(std::size_t boundary, std::size_t size);
 #endif
-#define aligned_alloc memalign
+static inline void*
+aligned_alloc (std::size_t al, std::size_t sz)
+{
+  // Solaris requires that sz is greater than or equal to sizeof(int)
+  if (al < sizeof(int))
+al = sizeof(int);
+  return memalign (al, sz);
+}
 #else
 #include 
 // The C library doesn't provide any aligned allocation functions, define one.

[Bug target/86866] MMX intrinsics / x87 registers aliasing

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|c   |target

--- Comment #1 from Andrew Pinski  ---
I think you forgot to the flush as required.  The mmx programming model
requires the user to do it.

[Bug target/86866] MMX intrinsics / x87 registers aliasing

[konovalov.alv at ya dot ru]

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

--- Comment #2 from Aleksey Konovalov  ---
(In reply to Andrew Pinski from comment #1)
> I think you forgot to the flush as required.  The mmx programming model
> requires the user to do it.

You are right. Calling _m_empty() solves problem
Thank you

[Bug c++/59480] Missing error diagnostic: friend declaration specifying a default argument must be a definition

[paolo.carlini at oracle dot com]

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

--- Comment #20 from Paolo Carlini  ---
That's good to know, thanks!

[Bug c/86866] New: MMX intrinsics / x87 registers aliasing

[konovalov.alv at ya dot ru]

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

Bug ID: 86866
   Summary: MMX intrinsics / x87 registers aliasing
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: konovalov.alv at ya dot ru
  Target Milestone: ---

Each 64-bit MMX register corresponds to the mantissa part of an 80-bit x87
register. But the GCC considers the MMX and X87 registers independent.


For example:

#include 
#include 

int main()
{
   float x = 3.14;
   __m64 y = _mm_or_si64(_m_from_int(1), _m_from_int(2));
   (void)y;
   printf("%f\n", x);
}


If I build this code using 387 floating-point coprocessor, program prints wrong
result:

bash-4.2$ gcc -mfpmath=387 -O0 -g3 test2.c -o test
bash-4.2$ ./test 
-nan

[Bug target/86866] MMX intrinsics / x87 registers aliasing

[konovalov.alv at ya dot ru]

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

Aleksey Konovalov  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #3 from Aleksey Konovalov  ---
Calling _m_empty () solved the problem

[Bug tree-optimization/56456] [meta-bug] bogus/missing -Warray-bounds

[egallager at gcc dot gnu.org]

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

Bug 52504 Summary: (unreachable) out of bounds access in 
thread_prologue_and_epilogue_insns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52504

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |INVALID

[Bug bootstrap/44756] [meta-bug] --enable-werror-always issues

[egallager at gcc dot gnu.org]

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

Bug 52504 Summary: (unreachable) out of bounds access in 
thread_prologue_and_epilogue_insns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52504

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |INVALID

[Bug middle-end/52504] (unreachable) out of bounds access in thread_prologue_and_epilogue_insns

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |INVALID

--- Comment #2 from Eric Gallager  ---
(In reply to Martin Sebor from comment #1)
> It's been a few years since this report was opened.  Can you please check
> with a recent version of GCC whether the warning still occurs?  If it does,
> can in addition reduce it to a small test case and include it in your
> comment?

No response to this since having been put in WAITING; closing.

[Bug target/86772] [meta-bug] tracking port status for CVE-2017-5753

[uweigand at gcc dot gnu.org]

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

Bug 86807 Summary: spu port needs updating for CVE-2017-5753
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86807

   What|Removed |Added

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

[Bug target/86807] spu port needs updating for CVE-2017-5753

[uweigand at gcc dot gnu.org]

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

Ulrich Weigand  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |uweigand at gcc dot 
gnu.org

--- Comment #2 from Ulrich Weigand  ---
Fixed.

[Bug web/86867] New bugzilla comment tag to mark comments as obsolete or irrelevant

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #5 from Jonathan Wakely  ---
Oh good! Closing this then.

[Bug target/86868] New: cc1: warning: stack probing requires '-maccumulate-outgoing-args' for correctness

[hjl.tools at gmail dot com]

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

Bug ID: 86868
   Summary: cc1: warning: stack probing requires
'-maccumulate-outgoing-args' for correctness
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: ubizjak at gmail dot com
  Target Milestone: ---
Target: i386,x86-64

[hjl@gnu-cfl-1 gcc]$ cat /tmp/x.i
extern void foo (void);

void
bar (void)
{
  foo ();
}
[hjl@gnu-cfl-1 gcc]$ ./xgcc -B./ -mno-accumulate-outgoing-args -S /tmp/x.i
[hjl@gnu-cfl-1 gcc]$ ./xgcc -B./ -mno-accumulate-outgoing-args -S /tmp/x.i
-mstack-arg-probe
cc1: warning: stack probing requires ‘-maccumulate-outgoing-args’ for
correctness
[hjl@gnu-cfl-1 gcc]$ 

But there is

#define ACCUMULATE_OUTGOING_ARGS \
  ((TARGET_ACCUMULATE_OUTGOING_ARGS \
&& optimize_function_for_speed_p (cfun)) \
   || (cfun->machine->func_type != TYPE_NORMAL \
   && crtl->stack_realign_needed) \
   || TARGET_STACK_PROBE \
   || TARGET_64BIT_MS_ABI \
   || (TARGET_MACHO && crtl->profile))

-mno-accumulate-outgoing-args is a best effort option.  GCC generates the
same code when

  /* If stack probes are required, the space used for large function
 arguments on the stack must also be probed, so enable
 -maccumulate-outgoing-args so this happens in the prologue.  */
  if (TARGET_STACK_PROBE_P (opts->x_target_flags)
  && !(opts->x_target_flags & MASK_ACCUMULATE_OUTGOING_ARGS))
{
  if (opts_set->x_target_flags & MASK_ACCUMULATE_OUTGOING_ARGS)
warning (0,
 main_args_p
 ? G_("stack probing requires %<-maccumulate-outgoing-args%> "
  "for correctness")
 : G_("stack probing requires "
  "% for "
  "correctness"));
  opts->x_target_flags |= MASK_ACCUMULATE_OUTGOING_ARGS;
}

is removed.

[Bug testsuite/86153] [8/9 regression] test case g++.dg/pr83239.C fails starting with r261585

[seurer at gcc dot gnu.org]

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

--- Comment #11 from seurer at gcc dot gnu.org ---
this run
> FAIL: g++.dg/pr83239.C  -std=gnu++98 (test for excess errors)
< FAIL: g++.dg/pr83239.C  -std=gnu++11  scan-tree-dump-not optimized
"_ZNSt6vectorIiSaIiEE17_M_default_appendEm"
< FAIL: g++.dg/pr83239.C  -std=gnu++14  scan-tree-dump-not optimized
"_ZNSt6vectorIiSaIiEE17_M_default_appendEm"

the patch fixed the original failures but now there's a new one

spawn -ignore SIGHUP
/home/seurer/gcc/build/gcc-trunk/gcc/testsuite/g++3/../../xg++
-B/home/seurer/gcc/build/gcc-trunk/gcc/testsuite/g++3/../../
/home/seurer/gcc/gcc-trunk/gcc/testsuite/g++.dg/pr83239.C
-fno-diagnostics-show-caret -fdiagnostics-color=never -nostdinc++
-I/home/seurer/gcc/build/gcc-trunk/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/powerpc64le-unknown-linux-gnu
-I/home/seurer/gcc/build/gcc-trunk/powerpc64le-unknown-linux-gnu/libstdc++-v3/include
-I/home/seurer/gcc/gcc-trunk/libstdc++-v3/libsupc++
-I/home/seurer/gcc/gcc-trunk/libstdc++-v3/include/backward
-I/home/seurer/gcc/gcc-trunk/libstdc++-v3/testsuite/util -fmessage-length=0
-std=gnu++98 -O3 -finline-limit=500 -Wall -fdump-tree-optimized -S -o pr83239.s
In function 'void test_loop() [with T = int]':
cc1plus: warning: 'void* __builtin_memset(void*, int, long unsigned int)'
specified size 18446744073709551608 exceeds maximum object size
9223372036854775807 [-Wstringop-overflow=]
In function 'void test_if(std::vector&, int) [with T = long int]':
cc1plus: warning: 'void* __builtin_memset(void*, int, long unsigned int)'
specified size 18446744073709551600 exceeds maximum object size
9223372036854775807 [-Wstringop-overflow=]
FAIL: g++.dg/pr83239.C  -std=gnu++98 (test for excess errors)
Excess errors:
cc1plus: warning: 'void* __builtin_memset(void*, int, long unsigned int)'
specified size 18446744073709551608 exceeds maximum object size
9223372036854775807 [-Wstringop-overflow=]
cc1plus: warning: 'void* __builtin_memset(void*, int, long unsigned int)'
specified size 18446744073709551600 exceeds maximum object size
9223372036854775807 [-Wstringop-overflow=]

PASS: g++.dg/pr83239.C  -std=gnu++98  scan-tree-dump-not optimized
"_ZNSt6vectorIiSaIiEE17_M_default_appendEm"
PASS: g++.dg/pr83239.C  -std=gnu++98  scan-tree-dump-not optimized
"_ZNSt6vectorIPvSaIS0_EE17_M_default_appendEm"

[Bug lto/48200] Implement function attribute for symbol versioning (.symver)

[zackw at panix dot com]

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

Zack Weinberg  changed:

   What|Removed |Added

 CC||zackw at panix dot com

--- Comment #26 from Zack Weinberg  ---
/subscribe

I've tripped over this problem myself in the context of the new
password-hashing library, libxcrypt (see
https://github.com/besser82/libxcrypt/issues/24 )  Our symbol-versioning
techniques are lifted from glibc (see
https://github.com/besser82/libxcrypt/blob/aae4c1baea534d2e4c9dfe2faf42ee0c5f7a6f22/crypt-port.h#L122
).  Function attributes seem like a good replacement to me, although I'd ask
that people think about how a library author might write macros that will
seamlessly fall back to the older technique.

[Bug web/86867] New bugzilla comment tag to mark comments as obsolete or irrelevant

[segher at gcc dot gnu.org]

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

--- Comment #3 from Segher Boessenkool  ---
I meant *test* comment.  Doh.

[Bug web/86867] New bugzilla comment tag to mark comments as obsolete or irrelevant

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 CC||segher at gcc dot gnu.org

--- Comment #2 from Segher Boessenkool  ---
This is a text comment.

[Bug web/86867] New bugzilla comment tag to mark comments as obsolete or irrelevant

[segher at gcc dot gnu.org]

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

--- Comment #6 from Segher Boessenkool  ---
So "obsolete" works, and "offtopic" doesn't.

[Bug web/86867] New: New bugzilla comment tag to mark comments as obsolete or irrelevant

[redi at gcc dot gnu.org]

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

Bug ID: 86867
   Summary: New bugzilla comment tag to mark comments as obsolete
or irrelevant
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: web
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

Marking a comment with the "spam" tag causes it to be hidden by default (and
locks the comment author's account).

It might be useful to have the hiding behaviour (but not locking the account)
for other reasons. Sometimes a comment is no longer relevant and could be
marked obsolete (like attachments can be). More commonly, a comment is simply
added to the wrong bug (often followed by a "sorry, please ignore" comment).

We could either have separate "obsolete" and "offtopic" tags, or maybe just
"hidden" which can serve both purposes.

Ideally any comment author would be able to tag their own comments, but it
would also be OK if only @gcc.gnu.org accounts can add the tags.

[Bug web/86867] New bugzilla comment tag to mark comments as obsolete or irrelevant

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
I haven't CC'd Frédéric yet, let's decide if we really want this or not first.

[Bug target/86807] spu port needs updating for CVE-2017-5753

[uweigand at gcc dot gnu.org]

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

--- Comment #1 from Ulrich Weigand  ---
Author: uweigand
Date: Mon Aug  6 14:40:56 2018
New Revision: 263335

URL: https://gcc.gnu.org/viewcvs?rev=263335=gcc=rev
Log:
[spu, commit] Define TARGET_HAVE_SPECULATION_SAFE_VALUE

The SPU processor is not affected by speculation, so this macro can
safely be defined as speculation_safe_value_not_needed.

gcc/ChangeLog:

PR target/86807
* config/spu/spu.c (TARGET_HAVE_SPECULATION_SAFE_VALUE):
Define to speculation_safe_value_not_needed.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/spu/spu.c

[Bug web/86867] New bugzilla comment tag to mark comments as obsolete or irrelevant

[segher at gcc dot gnu.org]

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

--- Comment #4 from Segher Boessenkool  ---
I tagged #c2 as obsolete, and it is hidden, so this already works.  Yay!

[Bug c++/86091] [fold expression] Slow compile time and high memory usage compared to initializer_list folds

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Resolution|FIXED   |WORKSFORME

--- Comment #3 from Jonathan Wakely  ---
(In reply to Vasili Burdo from comment #0)
> I tried multiple GCC versions starting from 5.3 to 8.0.0 on Ubuntu and
> Windows (MINGW) all of them have the same problem.

How did you test it with 5.3 when it doesn't even support fold expressions?

I can't reproduce the slowness with any version of GCC at all.

tmp$ time ~/gcc/6.1.0/bin/g++  -std=gnu++1z -Wall -Wextra 86091.cc -DBUG

real0m0.284s
user0m0.234s
sys 0m0.048s
tmp$ time ~/gcc/6.1.0/bin/g++  -std=gnu++1z -Wall -Wextra 86091.cc 

real0m0.267s
user0m0.235s
sys 0m0.028s
tmp$ time ~/gcc/6.2.0/bin/g++  -std=gnu++1z -Wall -Wextra 86091.cc -DBUG

real0m1.231s
user0m0.271s
sys 0m0.081s
tmp$ time ~/gcc/6.2.0/bin/g++  -std=gnu++1z -Wall -Wextra 86091.cc 

real0m0.298s
user0m0.225s
sys 0m0.037s
tmp$ time ~/gcc/6.3.0/bin/g++  -std=gnu++1z -Wall -Wextra 86091.cc -DBUG

real0m1.260s
user0m0.287s
sys 0m0.075s
tmp$ time ~/gcc/6.3.0/bin/g++  -std=gnu++1z -Wall -Wextra 86091.cc 

real0m0.317s
user0m0.230s
sys 0m0.034s
tmp$ time ~/gcc/6.4.0/bin/g++  -std=gnu++1z -Wall -Wextra 86091.cc -DBUG

real0m0.280s
user0m0.239s
sys 0m0.038s
tmp$ time ~/gcc/6.4.0/bin/g++  -std=gnu++1z -Wall -Wextra 86091.cc 

real0m0.264s
user0m0.226s
sys 0m0.035s
tmp$ time ~/gcc/7.1.0/bin/g++  -std=gnu++1z -Wall -Wextra 86091.cc -DBUG

real0m0.313s
user0m0.254s
sys 0m0.056s
tmp$ time ~/gcc/7.1.0/bin/g++  -std=gnu++1z -Wall -Wextra 86091.cc 

real0m0.304s
user0m0.266s
sys 0m0.036s
tmp$ time ~/gcc/7.2.0/bin/g++  -std=gnu++1z -Wall -Wextra 86091.cc -DBUG

real0m0.299s
user0m0.247s
sys 0m0.050s
tmp$ time ~/gcc/7.2.0/bin/g++  -std=gnu++1z -Wall -Wextra 86091.cc 

real0m0.281s
user0m0.245s
sys 0m0.034s
tmp$ time ~/gcc/7.3.0/bin/g++  -std=gnu++1z -Wall -Wextra 86091.cc -DBUG

real0m0.574s
user0m0.534s
sys 0m0.036s
tmp$ time ~/gcc/7.3.0/bin/g++  -std=gnu++1z -Wall -Wextra 86091.cc 

real0m0.632s
user0m0.592s
sys 0m0.037s
tmp$ time ~/gcc/8.1.0/bin/g++  -std=gnu++1z -Wall -Wextra 86091.cc -DBUG

real0m0.334s
user0m0.305s
sys 0m0.027s
tmp$ time ~/gcc/8.1.0/bin/g++  -std=gnu++1z -Wall -Wextra 86091.cc 

real0m0.652s
user0m0.610s
sys 0m0.040s
tmp$ time ~/gcc/8.2.0/bin/g++  -std=gnu++1z -Wall -Wextra 86091.cc -DBUG

real0m0.169s
user0m0.140s
sys 0m0.026s
tmp$ time ~/gcc/8.2.0/bin/g++  -std=gnu++1z -Wall -Wextra 86091.cc 

real0m0.296s
user0m0.249s
sys 0m0.043s

[Bug fortran/25829] [F03] Asynchronous IO support

[clyon at gcc dot gnu.org]

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

--- Comment #48 from Christophe Lyon  ---
I've reproduced the problem on armeb with the patch posted at:
https://gcc.gnu.org/ml/gcc-patches/2018-08/msg00208.html

The code generated for the testcase is the same with and without your patch, so
I guess the different behavior is caused by different runtime libraries.

I've compiled the testscase with -static, and the results are attached: .exe
files are the ELF binaries, .trace files are execution traces from QEMU, .dump
files are the output of objdump -d on the ELF binaries.
".ko" are the ones that fail, ".ok" are the ones that succeed.

[Bug tree-optimization/86865] New: [9 Regression] Wrong code w/ -O2 -floop-parallelize-all -fstack-reuse=none -fwrapv -fno-tree-ch -fno-tree-dce -fno-tree-dominator-opts -fno-tree-loop-ivcanon

[asolokha at gmx dot com]

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

Bug ID: 86865
   Summary: [9 Regression] Wrong code w/ -O2
-floop-parallelize-all -fstack-reuse=none -fwrapv
-fno-tree-ch -fno-tree-dce -fno-tree-dominator-opts
-fno-tree-loop-ivcanon
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

gcc-9.0.0-alpha20180729 snapshot (r263055) generates wrong code when compiling
the following snippet w/ -O2 -floop-parallelize-all -fstack-reuse=none -fwrapv
-fno-tree-ch -fno-tree-dce -fno-tree-dominator-opts -fno-tree-loop-ivcanon:

int xy, tb;

void
bt (void)
{
  for (xy = 0; xy >= 0; --xy)
{
  int yt[8] = { 0 };
  int pz[2] = { 0 };
  int sa[32] = { 0 };
  int us;

  for (us = 0; us < 8; ++us)
yt[us] = 0;

  (void) yt;
  (void) pz;
  (void) sa;
}

  tb = 1;
}

int
main (void)
{
  bt ();
  if (xy != -1)
__builtin_abort ();

  return 0;
}

% gcc-9.0.0-alpha20180729 -O2 jdoeqjdo.c -o good && ./good
% echo $?
0

% gcc-9.0.0-alpha20180729 -O2 -floop-parallelize-all -fstack-reuse=none -fwrapv
-fno-tree-ch -fno-tree-dce -fno-tree-dominator-opts -fno-tree-loop-ivcanon
jdoeqjdo.c -o bad && ./bad
zsh: abort (core dumped)  ./bad

[Bug target/86662] [7/8/9 Regression] msp430-elf segfault with -flto and -mlarge

[jozefl at gcc dot gnu.org]

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

--- Comment #3 from jozefl at gcc dot gnu.org ---
Author: jozefl
Date: Mon Aug  6 10:29:17 2018
New Revision: 263332

URL: https://gcc.gnu.org/viewcvs?rev=263332=gcc=rev
Log:
PR target/86662

* gcc/tree.c (build_common_tree_nodes): Initialize integer_types array
with all enabled __intN types.

* gcc/testsuite/gcc.target/msp430/pr86662.c: New test.


Added:
trunk/gcc/testsuite/gcc.target/msp430/pr86662.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree.c

[Bug middle-end/86864] [9 Regression] ICE in commit_one_edge_insertion, at cfgrtl.c:2025 since r261795

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org

--- Comment #2 from Martin Liška  ---
It's strange because the CFG looks fine in optimized dump:

g (int b, int c, int d)
{
  long int a.0_1;

   [local count: 1073741825]:
  if (b_5(D) > 0)
goto ; [50.00%]
  else
goto ; [50.00%]

   [local count: 1073741825]:
  switch (b_5(D))  [75.00%], case 29:  [25.00%], case 32:
 [25.00%], case 40:  [25.00%], case 42:  [25.00%], case 48:
 [25.00%]>

   [count: 0]:
:
  __builtin_unreachable ();

   [local count: 1073312327]:
  # c_2 = PHI <1(2), 2(3)>
:
  if (d_6(D) != 0)
goto ; [33.00%]
  else
goto ; [67.00%]

   [local count: 719119259]:
  a.0_1 = a;
  if (a.0_1 != 0)
goto ; [50.00%]
  else
goto ; [50.00%]

   [local count: 713752697]:
  f ();

   [local count: 1073312326]:
  if (c_2 == 1)
goto ; [20.24%]
  else
goto ; [79.76%]

   [local count: 217238415]:
  f (); [tail call]

   [local count: 1073312326]:
  return;

I'm adding Jakub and Richi, they are more familiar with GIMPLE representation.

[Bug fortran/25829] [F03] Asynchronous IO support

[clyon at gcc dot gnu.org]

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

--- Comment #49 from Christophe Lyon  ---
Created attachment 44507
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44507=edit
objdump of OK ELF file

[Bug libstdc++/86860] Reject valid overloads of subclass ostream operator<

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
(In reply to Michael Veksler from comment #0)
> The above function does not seem to be part of the standard, and it seems

It's (3) at https://en.cppreference.com/w/cpp/io/basic_ostream/operator_ltlt2

The constraint is to implement https://wg21.link/lwg2534

> that the other compilers can work without it.

They need to provide some equivalent of it to be conforming. Apparently they
either don't provide it, or fail to constrain it as per 2534, because they fail
this:

#include 

struct X { };
std::ostream& operator<<(std::ostream& o, const X&) = delete;

template
struct is_streamable_to_rvalue
: std::false_type { };

template
struct is_streamable_to_rvalue() << std::declval())>>
: std::true_type { };

static_assert(!is_streamable_to_rvalue::value);


For other edge cases that the current enable_if constraint addresses, see PR
80675 and PR 80940.

I don't think this testcase is valid.

[Bug fortran/25829] [F03] Asynchronous IO support

[clyon at gcc dot gnu.org]

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

--- Comment #53 from Christophe Lyon  ---
Sorry, .exe files are too large even after xz compression, I'm not allowed to
attach them.

[Bug tree-optimization/86637] [9 Regression] ICE: tree check: expected block, have in inlining_chain_to_json, at optinfo-emit-json.cc:293

[asolokha at gmx dot com]

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

--- Comment #2 from Arseny Solokha  ---
Created attachment 44506
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44506=edit
Testcase #2

Another testcase for this PR w/ different backtrace. W/ this testcase
optrecord_json_writer::inlining_chain_to_json() is called from the parloops
pass.

% powerpc-e300c3-linux-gnu-gcc-9.0.0-alpha20180729 -Os -floop-parallelize-all
-fsave-optimization-record -ftree-parallelize-loops=2 -ftree-slp-vectorize -c
dsaczzfr.c
during GIMPLE pass: parloops
dsaczzfr.c: In function 'im':
dsaczzfr.c:88:1: internal compiler error: tree check: expected block, have
 in inlining_chain_to_json, at optinfo-emit-json.cc:295
 im (uint8_t kt)
 ^~
0x55bf58 tree_check_failed(tree_node const*, char const*, int, char const*,
...)
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20180729/work/gcc-9-20180729/gcc/tree.c:9351
0xb0eb63 tree_check(tree_node*, char const*, int, char const*, tree_code)
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20180729/work/gcc-9-20180729/gcc/tree.h:3114
0xb0eb63 optrecord_json_writer::inlining_chain_to_json(unsigned int)
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20180729/work/gcc-9-20180729/gcc/optinfo-emit-json.cc:295
0xb0f795 optrecord_json_writer::optinfo_to_json(optinfo const*)
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20180729/work/gcc-9-20180729/gcc/optinfo-emit-json.cc:435
0xb0f9b8 optrecord_json_writer::add_record(optinfo const*)
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20180729/work/gcc-9-20180729/gcc/optinfo-emit-json.cc:154
0x7aaca1 dump_context::begin_scope(char const*, dump_location_t const&)
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20180729/work/gcc-9-20180729/gcc/dumpfile.c:785
0xee3e2a auto_dump_scope::auto_dump_scope(char const*, dump_location_t)
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20180729/work/gcc-9-20180729/gcc/dumpfile.h:513
0xee3e2a vect_analyze_loop_form_1(loop*, gcond**, tree_node**, tree_node**,
tree_node**, gcond**)
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20180729/work/gcc-9-20180729/gcc/tree-vect-loop.c:1167
0xee4914 vect_analyze_loop_form(loop*, vec_info_shared*)
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20180729/work/gcc-9-20180729/gcc/tree-vect-loop.c:1359
0xd01954 gather_scalar_reductions
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20180729/work/gcc-9-20180729/gcc/tree-parloops.c:2601
0xd0741a try_create_reduction_list
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20180729/work/gcc-9-20180729/gcc/tree-parloops.c:2785
0xd0741a parallelize_loops
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20180729/work/gcc-9-20180729/gcc/tree-parloops.c:3392
0xd091d1 execute
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20180729/work/gcc-9-20180729/gcc/tree-parloops.c:3503

(as of 263055)

The ICE w/ this exact backtrace is not powerpc-specific. It also happens on
x86_64, but relevant testcases seem to be resistant to reduction.

[Bug target/80080] S390: Isses with emitted cs-instructions for __atomic builtins.

[stli at linux dot ibm.com]

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

--- Comment #11 from stli at linux dot ibm.com  ---
Hi,
I've retested the samples with gcc 7, 8 and head from 2018-07-20, but there are
still issues:
The examples foo1 and foo2 are okay.

The issue in example foo3 is still present (see description of the bug-report):

00a0 :
  a0:   a7 18 00 05 lhi %r1,5
  a4:   c4 2d 00 00 00 00   lrl %r2,a4 
a6: R_390_PC32DBL   foo3_mem+0x2

  aa:   c0 30 00 00 00 00   larl%r3,aa 
ac: R_390_PC32DBL   foo3_mem+0x2
  b0:   ba 21 30 00 cs  %r2,%r1,0(%r3)
  b4:   a7 74 ff fb jne aa 

The address of the global variable is still reloaded within the loop. If the
value was not swapped with cs, the jne can jump directly to the cs instruction
instead of the larl-instruction.

  b8:   b9 14 00 22 lgfr%r2,%r2
  bc:   07 fe   br  %r14
  be:   07 07   nopr%r7

I've found a further issue which is observable with the following two examples.
See the questions in the disassembly:

void foo4(int *mem)
{
  int oldval = 0;
  if (!__atomic_compare_exchange_n (mem, (void *) , 1,
1, __ATOMIC_ACQUIRE, __ATOMIC_RELAXED))
{
  bar (mem);
}
  /*
 :
   0:   e3 10 20 00 00 12   lt  %r1,0(%r2)
   6:   a7 74 00 06 jne 12 

Why do we need to jump to 0x12 first instead of directly jumping to 0x18?

   a:   a7 38 00 01 lhi %r3,1
   e:   ba 13 20 00 cs  %r1,%r3,0(%r2)
  12:   a7 74 00 03 jne 18 
  16:   07 fe   br  %r14
  18:   c0 f4 00 00 00 00   jg  18 
1a: R_390_PC32DBL   bar+0x2
  1e:   07 07   nopr%r7
  */
}


void foo5(int *mem)
{
  int oldval = 0;
  __atomic_compare_exchange_n (mem, (void *) , 1,
   1, __ATOMIC_ACQUIRE, __ATOMIC_RELAXED);
  if (oldval != 0)
bar (mem);
  /*
0040 :
  40:   e3 10 20 00 00 12   lt  %r1,0(%r2)
  46:   a7 74 00 06 jne 52 

This is similar to foo4, but the variable oldval is compared against zero
instead of using the return value of __atomic_compare_exchange_n.
Can't we jump directly to 0x5a instead of 0x52?

  4a:   a7 38 00 01 lhi %r3,1
  4e:   ba 13 20 00 cs  %r1,%r3,0(%r2)
  52:   12 11   ltr %r1,%r1
  54:   a7 74 00 03 jne 5a 
  58:   07 fe   br  %r14
  5a:   c0 f4 00 00 00 00   jg  5a 
5c: R_390_PC32DBL   bar+0x2
   */
}

[Bug fortran/25829] [F03] Asynchronous IO support

[clyon at gcc dot gnu.org]

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

--- Comment #51 from Christophe Lyon  ---
Created attachment 44509
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44509=edit
execution trace of OK ELF file

[Bug fortran/25829] [F03] Asynchronous IO support

[clyon at gcc dot gnu.org]

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

--- Comment #50 from Christophe Lyon  ---
Created attachment 44508
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44508=edit
objdump of KO ELF file

[Bug c++/86767] [6/7/8 Regression] continue statements in constexpr functions causes unbounded looping

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

Summary|[6/7/8/9 Regression]|[6/7/8 Regression] continue
   |continue statements in  |statements in constexpr
   |constexpr functions causes  |functions causes unbounded
   |unbounded looping   |looping

--- Comment #5 from Marek Polacek  ---
Fixed on trunk so far.

[Bug c++/86767] [6/7/8/9 Regression] continue statements in constexpr functions causes unbounded looping

[mpolacek at gcc dot gnu.org]

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

--- Comment #4 from Marek Polacek  ---
Author: mpolacek
Date: Mon Aug  6 16:46:13 2018
New Revision: 263340

URL: https://gcc.gnu.org/viewcvs?rev=263340=gcc=rev
Log:
PR c++/86767
* constexpr.c (cxx_eval_statement_list): Handle continue.

* g++.dg/cpp1y/constexpr-86767.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp1y/constexpr-86767.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/constexpr.c
trunk/gcc/testsuite/ChangeLog

[Bug other/86857] configure sprintf with target-specific details

[joseph at codesourcery dot com]

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

--- Comment #2 from joseph at codesourcery dot com  ---
A configure test can only test what sprintf does for the host, not for the 
target, so this would always need to be a target hook.

Even with a hook, it would not surprise me if e.g. results on MinGW depend 
on __USE_MINGW_ANSI_STDIO, so you can't assume there is always a constant 
answer for these questions.

[Bug c++/86870] New: Declaration disambiguation is too greedy

[blitzrakete at gmail dot com]

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

Bug ID: 86870
   Summary: Declaration disambiguation is too greedy
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: blitzrakete at gmail dot com
  Target Milestone: ---

struct X {
  void operator=(int);
} x;

int main() {
  1 + 1, X(x) = 4; // ok
  X(x) = 4, 1 + 1; // gcc fails
}

gcc cannot compile the second statement, because it thinks it is a declaration,
even though it is not. EDG compiles this just fine (clang and MSVC do not).

[Bug c++/86763] [7/8 Regression] Wrong code comparing member of copy of a 237 byte object with nontrivial default constructor on x86-64 arch

[curlypaul924 at gmail dot com]

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

--- Comment #12 from Paul Brannan  ---
(In reply to Richard Biener from comment #9)
> The following seems to work, will test.
> 
> Index: gcc/cp/class.c
> ===
> --- gcc/cp/class.c  (revision 263209)
> +++ gcc/cp/class.c  (working copy)
> @@ -6243,6 +6243,7 @@ layout_class_type (tree t, tree *virtual
>   bitsize_int (BITS_PER_UNIT)));
>SET_TYPE_ALIGN (base_t, rli->record_align);
>TYPE_USER_ALIGN (base_t) = TYPE_USER_ALIGN (t);
> +  TYPE_TYPELESS_STORAGE (base_t) = TYPE_TYPELESS_STORAGE (t);
>  
>/* Copy the non-static data members of T. This will include its
>  direct non-virtual bases & vtable.  */

This patch fixes the failure in my original (non-reduced test case).

[Bug target/86869] New: ICE when taking address of array member of __memx struct pointer

[saaadhu at gcc dot gnu.org]

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

Bug ID: 86869
   Summary: ICE when taking address of array member of __memx
struct pointer
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: saaadhu at gcc dot gnu.org
  Target Milestone: ---

The following code
struct S {
  char y[2];
};

void foo(const __memx  struct S *s) {
  const char (*p)[2] = >y;
}

causes an ICE when compiled with the below flags on avr-gcc 9.0.0 20180805
(reproducible on 5.4 as well) causes an ICE

$ avr-gcc -O0 -mmcu=avr51 test.c
during RTL pass: expand
In function 'foo':
6 : internal compiler error: in convert_memory_address_addr_space_1, at
explow.c:300
const char (*p)[2] = >y;
^
0x5bd7ca convert_memory_address_addr_space_1(scalar_int_mode, rtx_def*,
unsigned char, bool, bool)
../../gcc-src/gcc/explow.c:300
0x939605 convert_memory_address_addr_space_1(scalar_int_mode, rtx_def*,
unsigned char, bool, bool)
../../gcc-src/gcc/explow.c:401
0x939605 convert_memory_address_addr_space(scalar_int_mode, rtx_def*, unsigned
char)
../../gcc-src/gcc/explow.c:402
0x94fdd9 expand_expr_addr_expr
../../gcc-src/gcc/expr.c:8028
0x94fdd9 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../gcc-src/gcc/expr.c:11142
0x95b727 store_expr(tree_node*, rtx_def*, int, bool, bool)
../../gcc-src/gcc/expr.c:5614
0x95c8c0 expand_assignment(tree_node*, tree_node*, bool)
../../gcc-src/gcc/expr.c:5398
0x849837 expand_gimple_stmt_1
../../gcc-src/gcc/cfgexpand.c:3636
0x84a728 expand_gimple_stmt
../../gcc-src/gcc/cfgexpand.c:3734
0x84b0ff expand_gimple_basic_block
../../gcc-src/gcc/cfgexpand.c:5769
0x84fec7 execute
../../gcc-src/gcc/cfgexpand.c:6372
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
Compiler exited with result code 1

[Bug middle-end/86864] [9 Regression] ICE in commit_one_edge_insertion, at cfgrtl.c:2025 since r261795

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-08-06
  Known to work||8.2.0
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org
   Target Milestone|--- |9.0
 Ever confirmed|0   |1
  Known to fail||9.0

--- Comment #1 from Martin Liška  ---
Confirmed, mine.

[Bug fortran/25829] [F03] Asynchronous IO support

[clyon at gcc dot gnu.org]

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

--- Comment #52 from Christophe Lyon  ---
Created attachment 44510
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44510=edit
execution trace of KO ELF file

[Bug libstdc++/86860] Reject valid overloads of subclass ostream operator<

[mickey.veksler at gmail dot com]

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

--- Comment #2 from Michael Veksler  ---
Sounds reasonable. Thanks.

[Bug c++/86849] g++ applies guaranteed copy elision to delegating construction, resulting in miscompiles

[richard-gccbugzilla at metafoo dot co.uk]

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

--- Comment #1 from Richard Smith  ---
Interestingly, GCC does appear to suppress guaranteed copy elision if the class
has virtual base classes.


Perhaps GCC's approach to this problem is to assume that a function returning a
T by value cannot touch the tail padding of the T object if T is POD for the
purpose of layout, and so the tail padding cannot be modified in the case where
it's reusable by the enclosing object? (So we only have a problem in the case
where a complete-object constructor and a base-subobject constructor would do
different things, namely when the class has virtual base classes.)

The trouble with that approach is that other compilers do store to the tail
padding of T in a function returning T by value:

https://godbolt.org/g/MM7Wvb

... and indeed the standard requires this behavior:

http://eel.is/c++draft/dcl.init#6.2

"To zero-initialize an object or reference of type T means [...] if T is a
(possibly cv-qualified) non-union class type, its padding bits (6.7) are
initialized to zero bits [...]"

(so arguably that's another bug in GCC's behavior: it should zero-initialize
A's tail padding in the new example, but does not).

[Bug c++/86849] g++ applies guaranteed copy elision to delegating construction, resulting in miscompiles

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #2 from Marek Polacek  ---
(In reply to Richard Smith from comment #1)
> Interestingly, GCC does appear to suppress guaranteed copy elision if the
> class has virtual base classes.
> 
> 
> Perhaps GCC's approach to this problem is to assume that a function
> returning a T by value cannot touch the tail padding of the T object if T is
> POD for the purpose of layout, and so the tail padding cannot be modified in
> the case where it's reusable by the enclosing object? (So we only have a
> problem in the case where a complete-object constructor and a base-subobject
> constructor would do different things, namely when the class has virtual
> base classes.)
> 
> The trouble with that approach is that other compilers do store to the tail
> padding of T in a function returning T by value:
> 
> https://godbolt.org/g/MM7Wvb
> 
> ... and indeed the standard requires this behavior:
> 
> http://eel.is/c++draft/dcl.init#6.2
> 
> "To zero-initialize an object or reference of type T means [...] if T is a
> (possibly cv-qualified) non-union class type, its padding bits (6.7) are
> initialized to zero bits [...]"
> 
> (so arguably that's another bug in GCC's behavior: it should zero-initialize
> A's tail padding in the new example, but does not).

I wonder if that's PR85548.