[Bug target/89784] Missing AVX512 intrinsics

[crazylht at gmail dot com]

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

Hongtao.liu  changed:

   What|Removed |Added

  Attachment #46007|0   |1
is obsolete||

--- Comment #7 from Hongtao.liu  ---
Created attachment 46008
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46008&action=edit
add cover tests for intrinsics v2.

Add runtime tests for them.

Cover tests ok. bootstrap ok.
didn't run regression tests for x86_64/i386

[Bug middle-end/89790] [9 Regression] ICE segfault in operand_equal_p() at fold-const.c:3000 with -Wduplicated-cond since r269838

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-03-22
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
   Target Milestone|--- |9.0
 Ever confirmed|0   |1

--- Comment #2 from Richard Biener  ---
Will get to this next week.

[Bug c++/89793] Implicit conversion to std::string is ambiguous on GCC 8.2 but not GCC 7.3

[harald at gigawatt dot nl]

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

Harald van Dijk  changed:

   What|Removed |Added

 CC||harald at gigawatt dot nl

--- Comment #1 from Harald van Dijk  ---
Your StringType provides a conversion operator to HTTPResponse, which
indirectly has std::allocator as a private base class. Overload
resolution happens before access checks, so the fact that it is a private base
class does not prevent the construction of std::string from being ambiguous:
the conversion to HTTPResponse could be used followed by the construction of a
new std::string using the HTTPResponse as the allocator.

This appears to work the same way in GCC 8 as it does in GCC 7, although it is
possible that for whatever reason, the GCC 7 version ends up not including
std::allocator as a base class.

[Bug c++/60702] thread_local initialization

[iains at gcc dot gnu.org]

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

Iain Sandoe  changed:

   What|Removed |Added

 CC||iains at gcc dot gnu.org

--- Comment #11 from Iain Sandoe  ---
(In reply to Jakub Jelinek from comment #10)
> Created attachment 45976 [details]
> gcc9-pr60702.patch
> 
> Untested fix.

For emulated TLS on x86_64-Darwin16, this progresses 
thread_local12c.C 
thread_local12d.C
thread_local12i.C
thread_local12j.C
thread_local12l.C

which fail without the patch and pass with it,

thread_local11.C 
fails for every instance of _ZTH*
(passes for _ZTW* 2 gimple)

[Bug target/89784] Missing AVX512 intrinsics

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  ---
Author: jakub
Date: Fri Mar 22 10:08:40 2019
New Revision: 269868

URL: https://gcc.gnu.org/viewcvs?rev=269868&root=gcc&view=rev
Log:
PR target/89784
* config/i386/i386.c (enum ix86_builtins): Remove
IX86_BUILTIN_VFMSUBSD3_MASK3 and IX86_BUILTIN_VFMSUBSS3_MASK3.
* config/i386/i386-builtin.def (__builtin_ia32_vfmaddsd3_mask,
__builtin_ia32_vfmaddsd3_mask3, __builtin_ia32_vfmaddsd3_maskz,
__builtin_ia32_vfmsubsd3_mask3, __builtin_ia32_vfmaddss3_mask,
__builtin_ia32_vfmaddss3_mask3, __builtin_ia32_vfmaddss3_maskz,
__builtin_ia32_vfmsubss3_mask3): New builtins.
* config/i386/sse.md (avx512f_vmfmadd__mask,
avx512f_vmfmadd__mask3,
avx512f_vmfmadd__maskz_1,
*avx512f_vmfmsub__mask,
avx512f_vmfmsub__mask3,
*avx512f_vmfmasub__maskz_1,
*avx512f_vmfnmadd__mask,
*avx512f_vmfnmadd__mask3,
*avx512f_vmfnmadd__maskz_1,
*avx512f_vmfnmsub__mask,
*avx512f_vmfnmsub__mask3,
*avx512f_vmfnmasub__maskz_1): New define_insns.
(avx512f_vmfmadd__maskz): New define_expand.
* config/i386/avx512fintrin.h (_mm_mask_fmadd_sd, _mm_mask_fmadd_ss,
_mm_mask3_fmadd_sd, _mm_mask3_fmadd_ss, _mm_maskz_fmadd_sd,
_mm_maskz_fmadd_ss, _mm_mask_fmsub_sd, _mm_mask_fmsub_ss,
_mm_mask3_fmsub_sd, _mm_mask3_fmsub_ss, _mm_maskz_fmsub_sd,
_mm_maskz_fmsub_ss, _mm_mask_fnmadd_sd, _mm_mask_fnmadd_ss,
_mm_mask3_fnmadd_sd, _mm_mask3_fnmadd_ss, _mm_maskz_fnmadd_sd,
_mm_maskz_fnmadd_ss, _mm_mask_fnmsub_sd, _mm_mask_fnmsub_ss,
_mm_mask3_fnmsub_sd, _mm_mask3_fnmsub_ss, _mm_maskz_fnmsub_sd,
_mm_maskz_fnmsub_ss, _mm_mask_fmadd_round_sd, _mm_mask_fmadd_round_ss,
_mm_mask3_fmadd_round_sd, _mm_mask3_fmadd_round_ss,
_mm_maskz_fmadd_round_sd, _mm_maskz_fmadd_round_ss,
_mm_mask_fmsub_round_sd, _mm_mask_fmsub_round_ss,
_mm_mask3_fmsub_round_sd, _mm_mask3_fmsub_round_ss,
_mm_maskz_fmsub_round_sd, _mm_maskz_fmsub_round_ss,
_mm_mask_fnmadd_round_sd, _mm_mask_fnmadd_round_ss,
_mm_mask3_fnmadd_round_sd, _mm_mask3_fnmadd_round_ss,
_mm_maskz_fnmadd_round_sd, _mm_maskz_fnmadd_round_ss,
_mm_mask_fnmsub_round_sd, _mm_mask_fnmsub_round_ss,
_mm_mask3_fnmsub_round_sd, _mm_mask3_fnmsub_round_ss,
_mm_maskz_fnmsub_round_sd, _mm_maskz_fnmsub_round_ss): New intrinsics.

* gcc.target/i386/sse-13.c (__builtin_ia32_vfmaddsd3_mask,
__builtin_ia32_vfmaddsd3_mask3, __builtin_ia32_vfmaddsd3_maskz,
__builtin_ia32_vfmsubsd3_mask3, __builtin_ia32_vfmaddss3_mask,
__builtin_ia32_vfmaddss3_mask3, __builtin_ia32_vfmaddss3_maskz,
__builtin_ia32_vfmsubss3_mask3): Define.
* gcc.target/i386/sse-23.c (__builtin_ia32_vfmaddsd3_mask,
__builtin_ia32_vfmaddsd3_mask3, __builtin_ia32_vfmaddsd3_maskz,
__builtin_ia32_vfmsubsd3_mask3, __builtin_ia32_vfmaddss3_mask,
__builtin_ia32_vfmaddss3_mask3, __builtin_ia32_vfmaddss3_maskz,
__builtin_ia32_vfmsubss3_mask3): Define.
* gcc.target/i386/avx-1.c (__builtin_ia32_vfmaddsd3_mask,
__builtin_ia32_vfmaddsd3_mask3, __builtin_ia32_vfmaddsd3_maskz,
__builtin_ia32_vfmsubsd3_mask3, __builtin_ia32_vfmaddss3_mask,
__builtin_ia32_vfmaddss3_mask3, __builtin_ia32_vfmaddss3_maskz,
__builtin_ia32_vfmsubss3_mask3): Define.
* gcc.target/i386/sse-14.c: Add tests for
_mm_mask{,3,z}_f{,n}m{add,sub}_round_s{s,d} builtins.
* gcc.target/i386/sse-22.c: Likewise.

2019-03-22  Hongtao Liu  

* gcc.target/i386/avx512f-vfmaddXXXsd-1.c (avx512f_test): Add tests
for _mm_mask{,3,z}_*.
* gcc.target/i386/avx512f-vfmaddXXXss-1.c (avx512f_test): Likewise.
* gcc.target/i386/avx512f-vfmsubXXXsd-1.c (avx512f_test): Likewise.
* gcc.target/i386/avx512f-vfmsubXXXss-1.c (avx512f_test): Likewise.
* gcc.target/i386/avx512f-vfnmaddXXXsd-1.c (avx512f_test): Likewise.
* gcc.target/i386/avx512f-vfnmaddXXXss-1.c (avx512f_test): Likewise.
* gcc.target/i386/avx512f-vfnmsubXXXsd-1.c (avx512f_test): Likewise.
* gcc.target/i386/avx512f-vfnmsubXXXss-1.c (avx512f_test): Likewise.
* gcc.target/i386/avx512f-vfmaddXXXsd-2.c: New test.
* gcc.target/i386/avx512f-vfmaddXXXss-2.c: New test.
* gcc.target/i386/avx512f-vfmsubXXXsd-2.c: New test.
* gcc.target/i386/avx512f-vfmsubXXXss-2.c: New test.
* gcc.target/i386/avx512f-vfnmaddXXXsd-2.c: New test.
* gcc.target/i386/avx512f-vfnmaddXXXss-2.c: New test.
* gcc.target/i386/avx512f-vfnmsubXXXsd-2.c: New test.
* gcc.target/i386/avx512f-vfnmsubXXXss-2.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/i386/avx512f-vfmaddXXXsd-2.c
trunk/gcc/testsuite/gcc.target/i386/avx512f-vfmaddXXXss-2.c
trunk/gcc

[Bug c++/89793] Implicit conversion to std::string is ambiguous on GCC 8.2 but not GCC 7.3

[duyang.seu at gmail dot com]

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

--- Comment #2 from du yang  ---
Created attachment 46009
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46009&action=edit
GCC 7.3.1 source file dump

GCC version:
gcc version 7.3.1 20180303 (Red Hat 7.3.1-5) (GCC) 

System Type:
CentOS Linux release 7.5.1804 (Core) 

GCC Configured options:
Configured with: ../configure --enable-bootstrap
--enable-languages=c,c++,fortran,lto --prefix=/opt/rh/devtoolset-7/root/usr
--mandir=/opt/rh/devtoolset-7/root/usr/share/man
--infodir=/opt/rh/devtoolset-7/root/usr/share/info
--with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared
--enable-threads=posix --enable-checking=release --enable-multilib
--with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions
--enable-gnu-unique-object --enable-linker-build-id
--with-gcc-major-version-only --enable-plugin --with-linker-hash-style=gnu
--enable-initfini-array --with-default-libstdcxx-abi=gcc4-compatible
--with-isl=/builddir/build/BUILD/gcc-7.3.1-20180303/obj-x86_64-redhat-linux/isl-install
--enable-libmpx --enable-gnu-indirect-function --with-tune=generic
--with-arch_32=i686 --build=x86_64-redhat-linux

Comments:
Please see attached for a GCC 7.3.1 source file dump and help confirm your
assumptions.

[Bug c++/80559] Duplicate "template argument x is invalid" diagnostics

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

   Keywords|error-recovery, |diagnostic
   |ice-on-invalid-code |
   Target Milestone|7.5 |---
Summary|[7/8/9 Regression]  |Duplicate "template
   |Segmentation fault on   |argument x is invalid"
   |invalid initializer list|diagnostics
   |template arguments  |

[Bug c++/89512] [7/8/9 Regression] ICE in get_expr_operands, at tree-ssa-operands.c:882

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

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

[Bug c++/89512] [7/8 Regression] ICE in get_expr_operands, at tree-ssa-operands.c:882

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[7/8/9 Regression] ICE in   |[7/8 Regression] ICE in
   |get_expr_operands, at   |get_expr_operands, at
   |tree-ssa-operands.c:882 |tree-ssa-operands.c:882

--- Comment #5 from Jakub Jelinek  ---
Yes.

[Bug c++/89781] Misleading error messages when initializing a static data member in-class

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
Why do you think so?  Inline variables in C++17 are only variables with
explicit inline keyword or constexpr static data members.  So it is correct
this is rejected.

Are you suggesting the diagnostics should say something like either 'constexpr'
needed ... or static data member needs to be 'inline' ?

[Bug target/88918] [meta-bug] x86 intrinsic issues

[jakub at gcc dot gnu.org]

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

Bug 89784 Summary: Missing AVX512 intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89784

   What|Removed |Added

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

[Bug target/89784] Missing AVX512 intrinsics

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #9 from Jakub Jelinek  ---
Implemented on the trunk.  Thanks for the testcase coverage work.

[Bug tree-optimization/89789] [9 Regression] Compile time hog during RPO VN

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-03-22
 CC||jakub at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org
   Target Milestone|--- |9.0
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Started with r263875.

[Bug c++/89781] Misleading error messages when initializing a static data member in-class

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
Yeah I guess the diagnostics could be improved for C++17 and up to say that
using 'inline' would make it valid.

[Bug rtl-optimization/89794] New: wrong code with -Og -fno-forward-propagate

[zsojka at seznam dot cz]

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

Bug ID: 89794
   Summary: wrong code with -Og -fno-forward-propagate
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: armv7a-hardfloat-linux-gnueabi

Created attachment 46010
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46010&action=edit
reduced testcase

Output:
$ armv7a-hardfloat-linux-gnueabi-gcc -Og -fno-forward-propagate testcase.c
-static
$ ./a.out 
qemu: uncaught target signal 11 (Segmentation fault) - core dumped
Segmentation fault

The instruction:
...
@ testcase.c:12:   __builtin_memset (&i, c, 2);
movwr1, #:lower16:c @ tmp132,
movtr1, #:upper16:c @ tmp132,
ldr ip, [r1]@ c.2_7, c
uxtbr3, ip  @ c.2_7, c.2_7
add r3, r3, r3, lsl #8  @ tmp140, c.2_7, c.2_7,
strhr3, [sp]@ movhi @ tmp140, MEM[(void *)&i]

overwrites return address


$ armv7a-hardfloat-linux-gnueabi-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-armv7a-hardfloat/bin/armv7a-hardfloat-linux-gnueabi-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-269795-checking-yes-rtl-df-extra-armv7a-hardfloat/bin/../libexec/gcc/armv7a-hardfloat-linux-gnueabi/9.0.1/lto-wrapper
Target: armv7a-hardfloat-linux-gnueabi
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--with-cloog --with-ppl --with-isl --with-float=hard --with-fpu=vfpv4
--with-arch=armv7-a --with-sysroot=/usr/armv7a-hardfloat-linux-gnueabi
--build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu
--target=armv7a-hardfloat-linux-gnueabi
--with-ld=/usr/bin/armv7a-hardfloat-linux-gnueabi-ld
--with-as=/usr/bin/armv7a-hardfloat-linux-gnueabi-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-269795-checking-yes-rtl-df-extra-armv7a-hardfloat
Thread model: posix
gcc version 9.0.1 20190319 (experimental) (GCC)

[Bug rtl-optimization/89795] New: wrong code with -O2 -fno-dce -fno-forward-propagate -fno-sched-pressure

[zsojka at seznam dot cz]

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

Bug ID: 89795
   Summary: wrong code with -O2 -fno-dce -fno-forward-propagate
-fno-sched-pressure
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: armv7a-hardfloat-linux-gnueabi

Created attachment 46011
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46011&action=edit
reduced testcase

Compiler output:
$ armv7a-hardfloat-linux-gnueabi-gcc -O2 -fno-dce -fno-forward-propagate
-fno-sched-pressure testcase.c -static
$ ./a.out 
qemu: uncaught target signal 6 (Aborted) - core dumped
Aborted

Correct value is 0xf7, invalid value is 0xfff7 (sign extended).

$ armv7a-hardfloat-linux-gnueabi-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-armv7a-hardfloat/bin/armv7a-hardfloat-linux-gnueabi-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-269795-checking-yes-rtl-df-extra-armv7a-hardfloat/bin/../libexec/gcc/armv7a-hardfloat-linux-gnueabi/9.0.1/lto-wrapper
Target: armv7a-hardfloat-linux-gnueabi
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--with-cloog --with-ppl --with-isl --with-float=hard --with-fpu=vfpv4
--with-arch=armv7-a --with-sysroot=/usr/armv7a-hardfloat-linux-gnueabi
--build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu
--target=armv7a-hardfloat-linux-gnueabi
--with-ld=/usr/bin/armv7a-hardfloat-linux-gnueabi-ld
--with-as=/usr/bin/armv7a-hardfloat-linux-gnueabi-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-269795-checking-yes-rtl-df-extra-armv7a-hardfloat
Thread model: posix
gcc version 9.0.1 20190319 (experimental) (GCC)

[Bug target/89093] [9 Regression] C++ exception handling clobbers d8 VFP register

[jakub at gcc dot gnu.org]

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

--- Comment #31 from Jakub Jelinek  ---
(In reply to Ramana Radhakrishnan from comment #30)
> (In reply to Jakub Jelinek from comment #29)
> > Ramana, any progress on this?
> 
> I'm still trying to get the various spec files and the t-multilib bits
> sorted and half-term has intervened here in the UK.

Any further progress?  This is a wrong-code P1, so really has to be fixed for
GCC9.

[Bug c++/89780] -Wpessimizing-move is too agressive with templates and recommends pessimization

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-03-22
 CC||mpolacek at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org
 Ever confirmed|0   |1

[Bug c++/89793] Implicit conversion to std::string is ambiguous on GCC 8.2 but not GCC 7.3

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
I haven't analysed whether it's valid yet, but it started to fail with r258755

PR c++/81311 - wrong C++17 overload resolution.

* call.c (build_user_type_conversion_1): Remove C++17 code.
(conv_binds_ref_to_prvalue): New.
(build_over_call): Handle C++17 copy elision.
(build_special_member_call): Only do C++17 copy elision here if the
argument is already the right type.

[Bug c++/89793] Implicit conversion to std::string is ambiguous on GCC 8.2 but not GCC 7.3

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
(In reply to Harald van Dijk from comment #1)
> Your StringType provides a conversion operator to HTTPResponse, which
> indirectly has std::allocator as a private base class. Overload
> resolution happens before access checks, so the fact that it is a private
> base class does not prevent the construction of std::string from being
> ambiguous: the conversion to HTTPResponse could be used followed by the
> construction of a new std::string using the HTTPResponse as the allocator.

Right, the code is equivalent to this:

#include 

struct NotString : std::allocator { };

struct String {
  operator std::string() const;
  operator NotString() const;
};

struct Message {
  template
Message(T&& t) : s{t} { }
  std::string s;
};

int main()
{
  String s;
  Message m(s);
}


> This appears to work the same way in GCC 8 as it does in GCC 7, although it
> is possible that for whatever reason, the GCC 7 version ends up not
> including std::allocator as a base class.

There was a change in overload resolution between GCC 7 and 8.

[Bug c++/89793] Implicit conversion to std::string is ambiguous on GCC 8.2 but not GCC 7.3

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  ---
Minimal testcase:

struct allocator { };

struct string {
  string(const string&);
  string(const allocator&);
};

struct NotString : allocator { };

struct String {
  operator string() const;
  operator NotString() const;
};

struct Message {
  template
Message(T&& t) : s{t} { }
  string s;
};

int main()
{
  String s;
  Message m(s);
}

This is rejected by GCC 8:

s.cc: In instantiation of ‘Message::Message(T&&) [with T = String&]’:
s.cc:24:14:   required from here
s.cc:17:25: error: call of overloaded ‘string()’ is ambiguous
 Message(T&& t) : s{t} { }
 ^
s.cc:5:3: note: candidate: ‘string::string(const allocator&)’
   string(const allocator&);
   ^~
s.cc:4:3: note: candidate: ‘string::string(const string&)’
   string(const string&);
   ^~

EDG also rejects it:

"s.cc", line 17: error: more than one instance of constructor "string::string"
  matches the argument list:
function "string::string(const string &)"
function "string::string(const allocator &)"
argument types are: (String)
  Message(T&& t) : s{t} { }
^
  detected during instantiation of "Message::Message(T &&) [with
T=String &]" at line 24


It's accepted by Clang.

[Bug c++/89793] Implicit conversion to std::string is ambiguous on GCC 8.2 but not GCC 7.3

[harald at gigawatt dot nl]

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

--- Comment #6 from Harald van Dijk  ---
(In reply to Jonathan Wakely from comment #4)
> (In reply to Harald van Dijk from comment #1)
> > This appears to work the same way in GCC 8 as it does in GCC 7, although it
> > is possible that for whatever reason, the GCC 7 version ends up not
> > including std::allocator as a base class.
> 
> There was a change in overload resolution between GCC 7 and 8.

Ah, sorry, I just realised I was testing a smaller version without -std=c++17
on GCC 7. Yeah, I see the difference between GCC 7 and GCC 8 as well.

[Bug libstdc++/78830] std::prev accepts ForwardIterator-s

[piotrwn1 at gmail dot com]

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

Piotr Nycz  changed:

   What|Removed |Added

 CC||piotrwn1 at gmail dot com

--- Comment #5 from Piotr Nycz  ---
Still not "enhanced" (gcc9). 
CLANG with its std-lib correctly (IMO) does not compile it.

I understand this is UB - but implementation might suggest it is checked that
iterator is biderectional (at least ) but this check has no effect.

```

  template
inline _BidirectionalIterator
prev(_BidirectionalIterator __x, typename
 iterator_traits<_BidirectionalIterator>::difference_type __n = 1) 
{
  // concept requirements
  __glibcxx_function_requires(_BidirectionalIteratorConcept<
  _BidirectionalIterator>)
  std::advance(__x, -__n);
  return __x;
}

``` 

it is very troublesome to realize that there is something wrong here - when you
have UB="very long time consuming loop (LONG_MAX iteration probably)"

Is there anything that can be done to increase importance of this enhancement?

[Bug c++/89793] Implicit conversion to std::string is ambiguous on GCC 8.2 but not GCC 7.3

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #7 from Jonathan Wakely  ---
Jason, I'm not sure if this is a regression in gcc-8 or a bug in gcc-7 that was
fixed.

It looks like both conversion sequences (String -> string -> const string& and
String -> NotString -> const allocator&) have Conversion rank, although the
lack of a derived-to-base conversion in the first one would naively seem to
make it better.

[Bug libstdc++/78830] std::prev accepts ForwardIterator-s

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  ---
(In reply to Piotr Nycz from comment #5)
> CLANG with its std-lib correctly (IMO) does not compile it.

As explained above, GCC is already correct here.

> I understand this is UB - but implementation might suggest it is checked
> that iterator is biderectional (at least ) but this check has no effect.

It does if you compile with -D_GLIBCXX_CONCEPT_CHECKS


> Is there anything that can be done to increase importance of this
> enhancement?

Write a patch?

https://gcc.gnu.org/contribute.html

[Bug c++/89785] Incorrect "not a constant expression" error with switch statement that returns

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-03-22
 Ever confirmed|0   |1

--- Comment #6 from Jakub Jelinek  ---
The bug is then in potential_constant_expression_1:
case SWITCH_STMT:
  if (!RECUR (SWITCH_STMT_COND (t), rval))
return false;
  /* FIXME we don't check SWITCH_STMT_BODY currently, because even
 unreachable labels would be checked.  */
  return true;

This is not conservatively correct as the testcases show.
The question is how much effort we do want to spend on that.

The simplest might be to add *jump_target = integer_zero_node; before the
return true; above, that will just assume any switch can return and not check
both the switch body (which isn't checked even now) nor anything after the
switch.

Another option, slightly more involved, is say cp_walk_tree on
SWITCH_STMT_BODY, looking for any RETURN_EXPRs or CONTINUE_STMTs (the latter
only when not nested inside of a FOR_STMT, DO_STMT, WHILE_STMT and
RANGE_FOR_STMT) and if we find a RETURN_EXPR, set jump_target to that, if we
don't, but find a CONTINUE_STMT not nested in further looping constructs, set
*jump_target to that CONTINUE_STMT, otherwise keep it unchanged.  To me this
looks like the best approach for now.

Another option is try to do something for the case when SWITCH_STMT_COND is
constant, but already for that we'd need to greatly extend the simplified:
  if (*jump_target)
/* If we are jumping, ignore everything.  This is simpler than the
   cxx_eval_constant_expression handling because we only need to be
   conservatively correct, and we don't necessarily have a constant value
   available, so we don't bother with switch tracking.  */
return true;
so that we do walk statements that can embed other statements like
cxx_eval_constant_expression does and all of that stuff, with label_matches
etc.

And if the above is done, we could have some also some mode in which for
non-constant SWITCH_STMT_COND we could say set *jump_target to the SWITCH_STMT
itself and treat it as a walk which walks the switch body, if it finds some
CASE_LABEL_EXPR, it will change it to some other mode which will start
processing all the expressions; if we detect something that is not a potential
constant expression, we would at the level of whole stmts switch back to that
*jump_target = SWITCH_STMT mode and keep looking for another CASE_LABEL_EXPR
and that way, if for any of the switch condition values there would be a
potential constant expression, we'd succeed, otherwise fail, and even set
jump_target properly based on that.  But this would be quite a lot of work.

Jason, any preferences here?

[Bug libstdc++/78830] std::prev accepts ForwardIterator-s

[redi at gcc dot gnu.org]

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

--- Comment #7 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #6)
> (In reply to Piotr Nycz from comment #5)
> > CLANG with its std-lib correctly (IMO) does not compile it.
> 
> As explained above, GCC is already correct here.
> 
> > I understand this is UB - but implementation might suggest it is checked
> > that iterator is biderectional (at least ) but this check has no effect.
> 
> It does if you compile with -D_GLIBCXX_CONCEPT_CHECKS

If you enable concept checks it will fail to compile:

In file included from /usr/include/c++/8/bits/concept_check.h:56,
 from /usr/include/c++/8/bits/move.h:34,
 from /usr/include/c++/8/bits/stl_iterator.h:65,
 from /usr/include/c++/8/bits/forward_list.h:37,
 from /usr/include/c++/8/forward_list:38,
 from prev.cc:1:
/usr/include/c++/8/bits/boost_concept_check.h: In instantiation of ‘void
__gnu_cxx::_BidirectionalIteratorConcept<_Tp>::__constraints() [with _Tp =
std::_Fwd_list_iterator]’:
/usr/include/c++/8/bits/boost_concept_check.h:62:39:   required from ‘void
__gnu_cxx::__function_requires() [with _Concept =
__gnu_cxx::_BidirectionalIteratorConcept >]’
/usr/include/c++/8/bits/stl_iterator_base_funcs.h:228:7:   required from
‘_BidirectionalIterator std::prev(_BidirectionalIterator, typename
std::iterator_traits<_Iter>::difference_type) [with _BidirectionalIterator =
std::_Fwd_list_iterator; typename
std::iterator_traits<_Iter>::difference_type = long int]’
prev.cc:7:35:   required from here
/usr/include/c++/8/bits/boost_concept_check.h:506:7: error: no match for
‘operator--’ (operand type is ‘std::_Fwd_list_iterator’)
   --__i;// require predecrement operator
   ^
/usr/include/c++/8/bits/boost_concept_check.h:507:10: error: no
‘operator--(int)’ declared for postfix ‘--’ [-fpermissive]
   __i--;// require postdecrement operator
   ~~~^~
/usr/include/c++/8/bits/boost_concept_check.h: In instantiation of ‘void
__gnu_cxx::_ConvertibleConcept<_From, _To>::__constraints() [with _From =
std::forward_iterator_tag; _To = std::bidirectional_iterator_tag]’:
/usr/include/c++/8/bits/boost_concept_check.h:62:39:   required from ‘void
__gnu_cxx::__function_requires() [with _Concept =
__gnu_cxx::_ConvertibleConcept]’
/usr/include/c++/8/bits/boost_concept_check.h:505:43:   required from ‘void
__gnu_cxx::_BidirectionalIteratorConcept<_Tp>::__constraints() [with _Tp =
std::_Fwd_list_iterator]’
/usr/include/c++/8/bits/boost_concept_check.h:62:39:   required from ‘void
__gnu_cxx::__function_requires() [with _Concept =
__gnu_cxx::_BidirectionalIteratorConcept >]’
/usr/include/c++/8/bits/stl_iterator_base_funcs.h:228:7:   required from
‘_BidirectionalIterator std::prev(_BidirectionalIterator, typename
std::iterator_traits<_Iter>::difference_type) [with _BidirectionalIterator =
std::_Fwd_list_iterator; typename
std::iterator_traits<_Iter>::difference_type = long int]’
prev.cc:7:35:   required from here
/usr/include/c++/8/bits/boost_concept_check.h:223:27: error: conversion from
‘std::forward_iterator_tag’ to non-scalar type
‘std::bidirectional_iterator_tag’ requested
   _To __y _IsUnused = __x;
   ^~~

But I don't recommend using those concepts checks for C++11 or later, because
some of the checks are outdated and only enforce the C++98 requirements, so
they're wrong for the current standard.

If you compile with -D_GLIBCXX_ASSERTIONS (or -D_GLIBCXX_DEBUG which also
enables the former) then it will fail at runtime when trying to advance a
non-bidirectional iterator by a negative number:

/usr/include/c++/8/bits/stl_iterator_base_funcs.h:151: constexpr void
std::__advance(_InputIterator&, _Distance, std::input_iterator_tag) [with
_InputIterator = std::_Fwd_list_iterator; _Distance = long int]: Assertion
'__n >= 0' failed.
Aborted (core dumped)

So we actually already provide two ways to prevent this UB.

[Bug ada/89583] GNAT.Sockets.Bind_Socket fails with IPv4 address

[pmderodat at gcc dot gnu.org]

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

--- Comment #1 from pmderodat at gcc dot gnu.org ---
Author: pmderodat
Date: Fri Mar 22 13:59:02 2019
New Revision: 269873

URL: https://gcc.gnu.org/viewcvs?rev=269873&root=gcc&view=rev
Log:
[Ada] GNAT.Sockets: fix recent regressions

The support for IPv6 that was added since last release triggered
regressions on various platforms. The size of structures passed to low
level routines was not correct anymore: it should depend on the address
family, now.

2019-03-22  Dmitriy Anisimkov  

gcc/ada/

PR ada/89583
* libgnat/g-socket.adb (Bind_Socket, Connect_Socket,
Send_Socket): Fix the computation of structure lengths passed to
low level routines.
(Is_IPv6_Address): Fix the number of expected colons.

2019-03-22  Simon Wright  

gcc/testsuite/

PR ada/89583
* gnat.dg/socket2.adb: New.

Added:
trunk/gcc/testsuite/gnat.dg/socket2.adb
Modified:
trunk/gcc/ada/ChangeLog
trunk/gcc/ada/libgnat/g-socket.adb
trunk/gcc/testsuite/ChangeLog

[Bug c++/87481] [7/8/9 Regression] Endless loop with optimisation in C++17

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek  ---
Author: jakub
Date: Fri Mar 22 14:40:59 2019
New Revision: 269874

URL: https://gcc.gnu.org/viewcvs?rev=269874&root=gcc&view=rev
Log:
PR c++/87481
* doc/invoke.texi (-fconstexpr-ops-limit=): Document.

* c.opt (-fconstexpr-ops-limit=): New option.

* constexpr.c (struct constexpr_ctx): Add constexpr_ops_count member.
(cxx_eval_constant_expression): When not skipping, not constant class
or location wrapper, increment *ctx->constexpr_ops_count and if it is
above constexpr_loop_nest_limit, diagnose failure.
(cxx_eval_outermost_constant_expr): Add constexpr_ops_count and
initialize ctx.constexpr_ops_count to its address.
(is_sub_constant_expr): Likewise.

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

Added:
trunk/gcc/testsuite/g++.dg/cpp1y/constexpr-87481.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c.opt
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/constexpr.c
trunk/gcc/doc/invoke.texi
trunk/gcc/testsuite/ChangeLog

[Bug c++/60702] thread_local initialization

[jakub at gcc dot gnu.org]

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

--- Comment #12 from Jakub Jelinek  ---
Author: jakub
Date: Fri Mar 22 14:42:57 2019
New Revision: 269875

URL: https://gcc.gnu.org/viewcvs?rev=269875&root=gcc&view=rev
Log:
PR c++/60702
* cp-tree.h (get_tls_wrapper_fn): Remove declaration.
(maybe_get_tls_wrapper_call): Declare.
* decl2.c (get_tls_wrapper_fn): Make static.
(maybe_get_tls_wrapper_call): New function.
* typeck.c (build_class_member_access_expr): Handle accesses to TLS
variables.
* semantics.c (finish_qualified_id_expr): Likewise.
(finish_id_expression_1): Use maybe_get_tls_wrapper_call.
* pt.c (tsubst_copy_and_build): Likewise.

* g++.dg/tls/thread_local11.C: New test.
* g++.dg/tls/thread_local11.h: New test.
* g++.dg/tls/thread_local12a.C: New test.
* g++.dg/tls/thread_local12b.C: New test.
* g++.dg/tls/thread_local12c.C: New test.
* g++.dg/tls/thread_local12d.C: New test.
* g++.dg/tls/thread_local12e.C: New test.
* g++.dg/tls/thread_local12f.C: New test.
* g++.dg/tls/thread_local12g.C: New test.
* g++.dg/tls/thread_local12h.C: New test.
* g++.dg/tls/thread_local12i.C: New test.
* g++.dg/tls/thread_local12j.C: New test.
* g++.dg/tls/thread_local12k.C: New test.
* g++.dg/tls/thread_local12l.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/tls/thread_local11.C
trunk/gcc/testsuite/g++.dg/tls/thread_local11.h
trunk/gcc/testsuite/g++.dg/tls/thread_local12a.C
trunk/gcc/testsuite/g++.dg/tls/thread_local12b.C
trunk/gcc/testsuite/g++.dg/tls/thread_local12c.C
trunk/gcc/testsuite/g++.dg/tls/thread_local12d.C
trunk/gcc/testsuite/g++.dg/tls/thread_local12e.C
trunk/gcc/testsuite/g++.dg/tls/thread_local12f.C
trunk/gcc/testsuite/g++.dg/tls/thread_local12g.C
trunk/gcc/testsuite/g++.dg/tls/thread_local12h.C
trunk/gcc/testsuite/g++.dg/tls/thread_local12i.C
trunk/gcc/testsuite/g++.dg/tls/thread_local12j.C
trunk/gcc/testsuite/g++.dg/tls/thread_local12k.C
trunk/gcc/testsuite/g++.dg/tls/thread_local12l.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/decl2.c
trunk/gcc/cp/pt.c
trunk/gcc/cp/semantics.c
trunk/gcc/cp/typeck.c
trunk/gcc/testsuite/ChangeLog

[Bug libstdc++/78830] std::prev accepts ForwardIterator-s

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID
   Target Milestone|--- |10.0

--- Comment #8 from Jonathan Wakely  ---
I don't think it's conforming to reject this at compile-time, because
std::prev(it, -1) is equivalent to std::advance(it, 1) which is valid for
forward iterators. So libc++ has a bug, it is not allowed to reject forward
iterators unconditionally (only when it can prove the argument to prev is
greater than zero).

The best we can do is check for negative values at runtime and abort, which we
already do.

One day I hope to be able to enhance those assertions to warn at compile-time
if the compiler can tell the assertion will fail, but that is not currently
possible.

[Bug c++/89785] Incorrect "not a constant expression" error with switch statement that returns

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #7 from Marek Polacek  ---
(I'd be interested in implementing one of the above, but would also like to
hear from Jason first.)

[Bug libstdc++/78830] std::prev accepts ForwardIterator-s

[redi at gcc dot gnu.org]

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

--- Comment #9 from Jonathan Wakely  ---
P.S. in C++2a std::ranges::prev does make it ill-formed to pass arguments that
don't satisfy the BidirectionalIterator concept. But std::prev doesn't.

[Bug c++/60702] thread_local initialization

[jakub at gcc dot gnu.org]

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

--- Comment #13 from Jakub Jelinek  ---
(In reply to Iain Sandoe from comment #11)
> (In reply to Jakub Jelinek from comment #10)
> > Created attachment 45976 [details]
> > gcc9-pr60702.patch
> > 
> > Untested fix.
> 
> For emulated TLS on x86_64-Darwin16, this progresses 
> thread_local12c.C 
> thread_local12d.C
> thread_local12i.C
> thread_local12j.C
> thread_local12l.C
> 
> which fail without the patch and pass with it,
> 
> thread_local11.C 
> fails for every instance of _ZTH*
> (passes for _ZTW* 2 gimple)

Doesn't thread_local-wrap3.C FAIL then as well?
If yes, then perhaps:
--- gcc/testsuite/g++.dg/tls/thread_local11.C.jj2019-03-22
15:42:02.506993141 +0100
+++ gcc/testsuite/g++.dg/tls/thread_local11.C   2019-03-22 15:56:11.077364204
+0100
@@ -15,18 +15,18 @@
 // { dg-final { scan-tree-dump-times "_ZTWN1T2u6E" 2 "gimple" } }
 // { dg-final { scan-tree-dump-times "_ZTWN1T2u7E" 2 "gimple" } }
 // { dg-final { scan-tree-dump-times "_ZTWN1T2u8E" 2 "gimple" } }
-// { dg-final { scan-tree-dump-times "_ZTH2s1" 1 "gimple" } }
-// { dg-final { scan-tree-dump-times "_ZTH2s2" 1 "gimple" } }
-// { dg-final { scan-tree-dump-times "_ZTH2s3" 1 "gimple" } }
-// { dg-final { scan-tree-dump-times "_ZTH2s4" 1 "gimple" } }
-// { dg-final { scan-tree-dump-times "_ZTHN1T2u1E" 1 "gimple" } }
-// { dg-final { scan-tree-dump-times "_ZTHN1T2u2E" 1 "gimple" } }
-// { dg-final { scan-tree-dump-times "_ZTHN1T2u3E" 1 "gimple" } }
-// { dg-final { scan-tree-dump-times "_ZTHN1T2u4E" 1 "gimple" } }
-// { dg-final { scan-tree-dump-times "_ZTHN1T2u5E" 1 "gimple" } }
-// { dg-final { scan-tree-dump-times "_ZTHN1T2u6E" 1 "gimple" } }
-// { dg-final { scan-tree-dump-times "_ZTHN1T2u7E" 1 "gimple" } }
-// { dg-final { scan-tree-dump-times "_ZTHN1T2u8E" 1 "gimple" } }
+// { dg-final { scan-tree-dump-times "_ZTH2s1" 1 "gimple" { target tls_native
} } }
+// { dg-final { scan-tree-dump-times "_ZTH2s2" 1 "gimple" { target tls_native
} } }
+// { dg-final { scan-tree-dump-times "_ZTH2s3" 1 "gimple" { target tls_native
} } }
+// { dg-final { scan-tree-dump-times "_ZTH2s4" 1 "gimple" { target tls_native
} } }
+// { dg-final { scan-tree-dump-times "_ZTHN1T2u1E" 1 "gimple" { target
tls_native } } }
+// { dg-final { scan-tree-dump-times "_ZTHN1T2u2E" 1 "gimple" { target
tls_native } } }
+// { dg-final { scan-tree-dump-times "_ZTHN1T2u3E" 1 "gimple" { target
tls_native } } }
+// { dg-final { scan-tree-dump-times "_ZTHN1T2u4E" 1 "gimple" { target
tls_native } } }
+// { dg-final { scan-tree-dump-times "_ZTHN1T2u5E" 1 "gimple" { target
tls_native } } }
+// { dg-final { scan-tree-dump-times "_ZTHN1T2u6E" 1 "gimple" { target
tls_native } } }
+// { dg-final { scan-tree-dump-times "_ZTHN1T2u7E" 1 "gimple" { target
tls_native } } }
+// { dg-final { scan-tree-dump-times "_ZTHN1T2u8E" 1 "gimple" { target
tls_native } } }

 #include "thread_local11.h"

If that test doesn't fail, then perhaps instead:
--- gcc/testsuite/g++.dg/tls/thread_local11.C.jj2019-03-22
15:42:02.506993141 +0100
+++ gcc/testsuite/g++.dg/tls/thread_local11.C   2019-03-22 16:00:08.863486555
+0100
@@ -1,6 +1,7 @@
 // PR c++/60702
 // { dg-do compile { target c++11 } }
 // { dg-add-options tls }
+// { dg-require-alias "" }
 // { dg-require-effective-target tls_runtime }
 // { dg-additional-options "-fdump-tree-gimple" }
 // { dg-final { scan-tree-dump-times "_ZTW2s1" 2 "gimple" } }

(sadly there is no effective target alias).

[Bug c++/80472] cannot use push/pop with #pragma GCC diagnostic warning "-Wsystem-headers"

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
Another place where I'd like to selectively enable warnings is for this code
(from PR 78830):

#include 
#include 

int main()
{
std::forward_list il = {1, 2, 3, 4, 5, 6, 7}; 
auto iter = std::prev(il.end());
}


With -Wall -O1 -Wsystem-headers GCC detects the undefined behaviour:

In file included from
/home/jwakely/gcc/9/include/c++/9.0.1/bits/stl_algobase.h:66,
 from
/home/jwakely/gcc/9/include/c++/9.0.1/bits/forward_list.h:38,
 from /home/jwakely/gcc/9/include/c++/9.0.1/forward_list:38,
 from prev.cc:1:
/home/jwakely/gcc/9/include/c++/9.0.1/bits/stl_iterator_base_funcs.h:153:7:
warning: iteration 9223372036854775807 invokes undefined behavior
[-Waggressive-loop-optimizations]
  153 |   while (__n--)
  |   ^
/home/jwakely/gcc/9/include/c++/9.0.1/bits/stl_iterator_base_funcs.h:153:7:
note: within this loop

but that very useful warning is suppressed by default. This bug prevents me
from locally enabling -Wsystem-headers around the relevant functions in
.

[Bug c++/43167] Warnings should not be disabled when instantiating templates defined in system headers

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Last reconfirmed|2017-01-24 00:00:00 |2019-3-22
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=80472

--- Comment #16 from Jonathan Wakely  ---
Bug 80472 comment 4 is another case where GCC detects undefined behaviour
caused by user-provided values, but the warning is suppressed because it's
inside a template defined in a system header:

In file included from
/home/jwakely/gcc/9/include/c++/9.0.1/bits/stl_algobase.h:66,
 from
/home/jwakely/gcc/9/include/c++/9.0.1/bits/forward_list.h:38,
 from /home/jwakely/gcc/9/include/c++/9.0.1/forward_list:38,
 from prev.cc:1:
/home/jwakely/gcc/9/include/c++/9.0.1/bits/stl_iterator_base_funcs.h:153:7:
warning: iteration 9223372036854775807 invokes undefined behavior
[-Waggressive-loop-optimizations]
  153 |   while (__n--)
  |   ^
/home/jwakely/gcc/9/include/c++/9.0.1/bits/stl_iterator_base_funcs.h:153:7:
note: within this loop

[Bug libstdc++/78830] std::prev accepts ForwardIterator-s

[akrzemi1 at gmail dot com]

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

--- Comment #10 from Andrzej Krzemienski  ---
For `std::prev()` it is UB, but by my reading of UB
(http://eel.is/c++draft/intro.defs#defns.undefined) it is legal for the
implementation to respond with "terminating a translation" "with the issuance
of a diagnostic message", given that the UB in question can be detected
statically.

[Bug c++/43167] Warnings should not be disabled when instantiating templates defined in system headers

[redi at gcc dot gnu.org]

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

--- Comment #17 from Jonathan Wakely  ---
And Bug 87614 is a simpler form of Ian's original example in comment 0:

#include 

int main() {
std::vector a;
a.emplace_back(7);
}

With -Wsystem-header -Wconversion:

[...]
87614.cc:5:25:   required from here
/home/jwakely/gcc/9/include/c++/9.0.1/ext/new_allocator.h:147:4: warning:
conversion from 'int' to 'short unsigned int' may change value [-Wconversion]
  147 |  { ::new((void *)__p) _Up(std::forward<_Args>(__args)...); }
  |^

This error comes from the user's code, the fact the actual conversion happens
deep inside libstdc++ rather than at the call site is only because the function
templates preserves the original type all the way down. But the error is in the
user's code, not in the libstdc++ code which is just doing what it was told to
by the user.

The better GCC gets at detecting such problems and warning about them, the
bigger a problem it becomes that using templates from the C++ standard library
suppresses all GCC's useful warnings.

[Bug c++/43167] Warnings should not be disabled when instantiating templates defined in system headers

[redi at gcc dot gnu.org]

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

--- Comment #18 from Jonathan Wakely  ---
From Matthias Kretz on IRC:

GCC needs to make a difference between warnings that apply when reading the
system headers and warnings that only manifest on a template instantiation or
constprop

[Bug libstdc++/78830] std::prev accepts ForwardIterator-s

[redi at gcc dot gnu.org]

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

--- Comment #11 from Jonathan Wakely  ---
As I already said:

(In reply to Jonathan Wakely from comment #8)
> One day I hope to be able to enhance those assertions to warn at
> compile-time if the compiler can tell the assertion will fail, but that is
> not currently possible.

[Bug libstdc++/78830] std::prev accepts ForwardIterator-s

[redi at gcc dot gnu.org]

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

--- Comment #12 from Jonathan Wakely  ---
Finally, with -Waggressive-loop-optimizations -Wsystem-headers -O1 it does
terminate translation:

/usr/include/c++/8/bits/stl_iterator_base_funcs.h: In function ‘int main()’:
/usr/include/c++/8/bits/stl_iterator_base_funcs.h:152:7: error: iteration
9223372036854775807 invokes undefined behavior
[-Werror=aggressive-loop-optimizations]
   while (__n--)
   ^
/usr/include/c++/8/bits/stl_iterator_base_funcs.h:152:7: note: within this loop

It's not currently possible to make this work automatically, without
-Wsystem-headers.

[Bug c++/89796] New: Incorrect warning generated with OpenMP atomic capture

[perard at cg dot uni-saarland.de]

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

Bug ID: 89796
   Summary: Incorrect warning generated with OpenMP atomic capture
   Product: gcc
   Version: 8.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: perard at cg dot uni-saarland.de
  Target Milestone: ---

Created attachment 46012
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46012&action=edit
Sample code that reproduces the issue

Hello,

I get the warning "warning: value computed is not used [-Wunused-value]" when
compiling the attached code snippet with:

g++ test.cpp -fopenmp -Wall -o test

This warning is incorrect, as the value referred to by the warning is in fact
used. Moreover, the warning does not show up when OpenMP is disabled (by
omitting -fopenmp from the command line).

[Bug c++/87481] [7/8 Regression] Endless loop with optimisation in C++17

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[7/8/9 Regression] Endless  |[7/8 Regression] Endless
   |loop with optimisation in   |loop with optimisation in
   |C++17   |C++17

--- Comment #10 from Jakub Jelinek  ---
Fixed on the trunk so far.

[Bug target/89093] [9 Regression] C++ exception handling clobbers d8 VFP register

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

  Attachment #45552|0   |1
is obsolete||
  Attachment #45580|0   |1
is obsolete||

--- Comment #32 from Ramana Radhakrishnan  ---
Created attachment 46013
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46013&action=edit
updated patch.

Having discussed this with Richard further , instead of adding -mfpu=none , we
would prefer a mgeneral-regs-only option which keeps the 2 separate. 

I'm sorry about the time it has taken to get back but this is what I have right
now. The hunk in eh_personality.cc isn't very pleasing for me but that's
because of the warning in the ABI code which triggers on the build for a hard
float build because we do have inline functions consuming floating point. 


Either I drop the warning or I keep the hunk in eh_personality.cc - any
preferences / thoughts ?

[Bug rtl-optimization/89676] [7/8/9 Regression] Redundant moves for long long shift on 32bit x86

[vmakarov at gcc dot gnu.org]

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

--- Comment #8 from Vladimir Makarov  ---
Author: vmakarov
Date: Fri Mar 22 16:59:21 2019
New Revision: 269878

URL: https://gcc.gnu.org/viewcvs?rev=269878&root=gcc&view=rev
Log:
2019-03-22  Vladimir Makarov  

PR rtl-optimization/89676
* lra-constraints.c (curr_insn_transform): Do match reload for
early clobbers even if the match was successful.

2019-03-22  Vladimir Makarov  

PR rtl-optimization/89676
* gcc.target/i386/pr89676.c: New.


Added:
trunk/gcc/testsuite/gcc.target/i386/pr89676.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/lra-constraints.c
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/89797] New: ICE on a vector_size (1LU << 33) int variable

[msebor at gcc dot gnu.org]

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

Bug ID: 89797
   Summary: ICE on a vector_size (1LU << 33) int variable
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

The following most likely invalid test case causes an ICE.  See also bug 69973
for a similar ICE.

$ cat z.c && gcc -S -Wall -Wextra z.c
#define N (1LU << 33)

__attribute__ ((vector_size (N))) int v;
z.c:3:1: internal compiler error: in tree_to_shwi, at tree.c:7267
3 | __attribute__ ((vector_size (N))) int v;
  | ^
0x15ba089 tree_to_shwi(tree_node const*)
/src/gcc/svn/gcc/tree.c:7267
0x1170c66 default_vector_alignment(tree_node const*)
/src/gcc/svn/gcc/targhooks.c:1254
0x1163396 layout_type(tree_node*)
/src/gcc/svn/gcc/stor-layout.c:2396
0x15c4adb make_vector_type
/src/gcc/svn/gcc/tree.c:10135
0x15cba94 build_vector_type(tree_node*, poly_int<1u, long>)
/src/gcc/svn/gcc/tree.c:11055
0x97f342 handle_vector_size_attribute
/src/gcc/svn/gcc/c-family/c-attribs.c:3545
0x7f2bc1 decl_attributes(tree_node**, tree_node*, int, tree_node*)
/src/gcc/svn/gcc/attribs.c:718
0x80da64 c_decl_attributes
/src/gcc/svn/gcc/c/c-decl.c:4817
0x80e006 start_decl(c_declarator*, c_declspecs*, bool, tree_node*)
/src/gcc/svn/gcc/c/c-decl.c:4956
0x8862ac c_parser_declaration_or_fndef
/src/gcc/svn/gcc/c/c-parser.c:2154
0x884f1a c_parser_external_declaration
/src/gcc/svn/gcc/c/c-parser.c:1653
0x884a1b c_parser_translation_unit
/src/gcc/svn/gcc/c/c-parser.c:1534
0x8beced c_parse_file()
/src/gcc/svn/gcc/c/c-parser.c:19854
0x94ea72 c_common_parse_file()
/src/gcc/svn/gcc/c-family/c-opts.c:1156
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug middle-end/89797] ICE on a vector_size (1LU << 33) int variable

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code
  Known to fail||4.1.3, 4.3.5, 4.4.7, 4.8.5,
   ||4.9.4, 5.4.0, 6.4.0, 7.3.0,
   ||8.3.0, 9.0

--- Comment #1 from Martin Sebor  ---
The ICE goes as far back as GCC 4.

[Bug c/89798] New: excessive vector_size silently accepted and truncated

[msebor at gcc dot gnu.org]

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

Bug ID: 89798
   Summary: excessive vector_size silently accepted and truncated
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

In the following test case the declaration of v0 is accepted and its size
matches the size specified by the vector_size attribute.  The declaration of v1
is also accepted but its size does not match that specified by the same
attribute.  See also pr89797 for a similar test case that triggers an ICE.

GCC should validate the attribute argument against its internal maximum and
reject excessive arguments with a descriptive error.

$ cat z.c && gcc -S -Wall -Wextra z.c
#define N0   (1LU << 30)

__attribute__ ((vector_size (N0))) char v0;
_Static_assert (N0 == sizeof v0);   // passes


#define N1   (1LU << 34)

__attribute__ ((vector_size (N1))) char v1;
_Static_assert (N1 == sizeof v1);   // fails
z.c:10:1: error: static assertion failed
   10 | _Static_assert (N1 == sizeof v1);   // fails
  | ^~

[Bug c/89798] excessive vector_size silently accepted and truncated

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||accepts-invalid
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=89797

--- Comment #1 from Martin Sebor  ---
ICC 19 issues the following errors:

z.c(3): error: vector size is too large
  __attribute__ ((vector_size (N0))) char v0;
  ^
z.c(9): error: vector size is too large
  __attribute__ ((vector_size (N1))) char v1;
  ^
compilation aborted for  (code 2)

[Bug target/89093] [9 Regression] C++ exception handling clobbers d8 VFP register

[bernd.edlinger at hotmail dot de]

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

--- Comment #33 from Bernd Edlinger  ---
(In reply to Ramana Radhakrishnan from comment #32)
> 
> Either I drop the warning or I keep the hunk in eh_personality.cc - any
> preferences / thoughts ?

It would feel safer, if only the functions that need it
had a target attribute like:

_Unwind_Reason_Code
#ifdef __ARM_EABI_UNWINDER__
__attribute__((target("general-regs-only")))
PERSONALITY_FUNCTION (_Unwind_State state,
  struct _Unwind_Exception* ue_header,
  struct _Unwind_Context* context)

[Bug rtl-optimization/87761] [9 regression][MIPS] New FAIL: gcc.target/mips/fix-r4000-10.c -O1 start with r265398

[law at gcc dot gnu.org]

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

--- Comment #17 from Jeffrey A. Law  ---
Author: law
Date: Fri Mar 22 18:14:56 2019
New Revision: 269880

URL: https://gcc.gnu.org/viewcvs?rev=269880&root=gcc&view=rev
Log:
PR rtl-optimization/87761
* config/mips/mips-protos.h (mips_split_move): Add new argument.
(mips_emit_move_or_split): Pass NULL for INSN into mips_split_move.
(mips_split_move): Accept new INSN argument.  Try to forward SRC
into the next instruction.
(mips_split_move_insn): Pass INSN through to mips_split_move.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/mips/mips-protos.h
trunk/gcc/config/mips/mips.c

[Bug c++/89781] Misleading error messages when initializing a static data member in-class

[redbeard0531 at gmail dot com]

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

--- Comment #3 from Mathias Stearn  ---
Yeah, my point wasn't that this code should be accepted, it was that the error
messages should be improved. Ideally there would even be fixits suggesting
adding constexpr where it would be valid, otherwise suggesting inline.

Sorry if that wasn't clear.

[Bug middle-end/89797] ICE on a vector_size (1LU << 33) int variable

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
Related to PR 69973 (which was fixed).

[Bug c++/60702] thread_local initialization

[iains at gcc dot gnu.org]

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

--- Comment #14 from Iain Sandoe  ---
(In reply to Jakub Jelinek from comment #13)
> (In reply to Iain Sandoe from comment #11)
> > (In reply to Jakub Jelinek from comment #10)
> > > Created attachment 45976 [details]
> > > gcc9-pr60702.patch
> > > 
> > > Untested fix.
> > 
> > For emulated TLS on x86_64-Darwin16, this progresses 
> > thread_local12c.C 
> > thread_local12d.C
> > thread_local12i.C
> > thread_local12j.C
> > thread_local12l.C
> > 
> > which fail without the patch and pass with it,
> > 
> > thread_local11.C 
> > fails for every instance of _ZTH*
> > (passes for _ZTW* 2 gimple)
> 
> Doesn't thread_local-wrap3.C FAIL then as well?

No, because it already 
// { dg-require-alias "" }
so it's unsupported.


> --- gcc/testsuite/g++.dg/tls/thread_local11.C.jj  2019-03-22
> 15:42:02.506993141 +0100
> +++ gcc/testsuite/g++.dg/tls/thread_local11.C 2019-03-22 15:56:11.077364204
> +0100
> @@ -15,18 +15,18 @@
>  // { dg-final { scan-tree-dump-times "_ZTWN1T2u6E" 2 "gimple" } }
>  // { dg-final { scan-tree-dump-times "_ZTWN1T2u7E" 2 "gimple" } }
>  // { dg-final { scan-tree-dump-times "_ZTWN1T2u8E" 2 "gimple" } }
> -// { dg-final { scan-tree-dump-times "_ZTH2s1" 1 "gimple" } }
> -// { dg-final { scan-tree-dump-times "_ZTH2s2" 1 "gimple" } }
> -// { dg-final { scan-tree-dump-times "_ZTH2s3" 1 "gimple" } }
> -// { dg-final { scan-tree-dump-times "_ZTH2s4" 1 "gimple" } }
> -// { dg-final { scan-tree-dump-times "_ZTHN1T2u1E" 1 "gimple" } }
> -// { dg-final { scan-tree-dump-times "_ZTHN1T2u2E" 1 "gimple" } }
> -// { dg-final { scan-tree-dump-times "_ZTHN1T2u3E" 1 "gimple" } }
> -// { dg-final { scan-tree-dump-times "_ZTHN1T2u4E" 1 "gimple" } }
> -// { dg-final { scan-tree-dump-times "_ZTHN1T2u5E" 1 "gimple" } }
> -// { dg-final { scan-tree-dump-times "_ZTHN1T2u6E" 1 "gimple" } }
> -// { dg-final { scan-tree-dump-times "_ZTHN1T2u7E" 1 "gimple" } }
> -// { dg-final { scan-tree-dump-times "_ZTHN1T2u8E" 1 "gimple" } }
> +// { dg-final { scan-tree-dump-times "_ZTH2s1" 1 "gimple" { target
> tls_native } } }
> +// { dg-final { scan-tree-dump-times "_ZTH2s2" 1 "gimple" { target
> tls_native } } }
> +// { dg-final { scan-tree-dump-times "_ZTH2s3" 1 "gimple" { target
> tls_native } } }
> +// { dg-final { scan-tree-dump-times "_ZTH2s4" 1 "gimple" { target
> tls_native } } }
> +// { dg-final { scan-tree-dump-times "_ZTHN1T2u1E" 1 "gimple" { target
> tls_native } } }
> +// { dg-final { scan-tree-dump-times "_ZTHN1T2u2E" 1 "gimple" { target
> tls_native } } }
> +// { dg-final { scan-tree-dump-times "_ZTHN1T2u3E" 1 "gimple" { target
> tls_native } } }
> +// { dg-final { scan-tree-dump-times "_ZTHN1T2u4E" 1 "gimple" { target
> tls_native } } }
> +// { dg-final { scan-tree-dump-times "_ZTHN1T2u5E" 1 "gimple" { target
> tls_native } } }
> +// { dg-final { scan-tree-dump-times "_ZTHN1T2u6E" 1 "gimple" { target
> tls_native } } }
> +// { dg-final { scan-tree-dump-times "_ZTHN1T2u7E" 1 "gimple" { target
> tls_native } } }
> +// { dg-final { scan-tree-dump-times "_ZTHN1T2u8E" 1 "gimple" { target
> tls_native } } }
>  
>  #include "thread_local11.h"

^^ works for me, results below.

I guess we could do something more clever to detect that the __tls_init calls
are present for !tls_native.  c.f. PR84497 where we don't generate the call
(not had a chance to analyse that yet).

===

Running /src/gcc-trunk/gcc/testsuite/g++.dg/tls/tls.exp ...

=== g++ Summary for unix/-m64 ===

# of expected passes307
# of expected failures  2
# of unsupported tests  55
Running target unix/-m32

Running /src/gcc-trunk/gcc/testsuite/g++.dg/tls/tls.exp ...

=== g++ Summary for unix/-m32 ===

# of expected passes307
# of expected failures  2
# of unsupported tests  55

=== g++ Summary ===

# of expected passes614
# of expected failures  4
# of unsupported tests  110
/scratch/10-12-sie/gcc-trunk-unpatched/gcc/testsuite/g++/../../xg++  version
9.0.1 20190322 (experimental) [trunk revision 269875] (GCC)

[Bug c++/43167] Warnings should not be disabled when instantiating templates defined in system headers

[lopezibanez at gmail dot com]

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

--- Comment #19 from Manuel López-Ibáñez  ---
I think the solution is to have more locations. If the diagnostic code knew
where the user value came from then it will know to not suppress the
diagnostic. I wonder what happens if you used something that actually has a
location, like an expression, for the first test case using emplace().



On Fri, 22 Mar 2019, 15:33 redi at gcc dot gnu.org, <
gcc-bugzi...@gcc.gnu.org> wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43167
>
> --- Comment #18 from Jonathan Wakely  ---
> From Matthias Kretz on IRC:
>
> GCC needs to make a difference between warnings that apply when reading the
> system headers and warnings that only manifest on a template instantiation
> or
> constprop
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.

[Bug c++/80472] cannot use push/pop with #pragma GCC diagnostic warning "-Wsystem-headers"

[lopezibanez at gmail dot com]

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

--- Comment #5 from Manuel López-Ibáñez  ---
This warning will be incomprehensible to users because the warning never
mentions any code that the user can modify. What should the user do
according to the warning?

[Bug c++/85013] [7/8/9 Regression] :1:41: internal compiler error: in wide_int_to_tree_1, at tree.c:1567 0x4097e2b wide_int_to_tree_1

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |paolo.carlini at oracle 
dot com

--- Comment #2 from Paolo Carlini  ---
Mine.

[Bug c++/84661] [7/8/9 Regression] internal compiler error: Segmentation fault (strip_array_types())

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |paolo.carlini at oracle 
dot com

--- Comment #5 from Paolo Carlini  ---
Mine.

[Bug c++/80472] cannot use push/pop with #pragma GCC diagnostic warning "-Wsystem-headers"

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  ---
Is it better to silently generate code with undefined behaviour, or issue a
flawed warning about that undefined behaviour?

If the warning doesn't show the template instantiation context that's a
separate issue.

[Bug c++/80472] cannot use push/pop with #pragma GCC diagnostic warning "-Wsystem-headers"

[redi at gcc dot gnu.org]

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

--- Comment #7 from Jonathan Wakely  ---
A comment added to the code would make the caret diagnostic self-explanatory:

--- a/libstdc++-v3/include/bits/stl_iterator_base_funcs.h
+++ b/libstdc++-v3/include/bits/stl_iterator_base_funcs.h
@@ -149,7 +149,7 @@ _GLIBCXX_END_NAMESPACE_CONTAINER
   // concept requirements
   __glibcxx_function_requires(_InputIteratorConcept<_InputIterator>)
   __glibcxx_assert(__n >= 0);
-  while (__n--)
+  while (__n--) // if n is negative this has undefined behaviour
++__i;
 }

That would make the diagnostic look like:

/home/jwakely/gcc/9/include/c++/9.0.1/bits/stl_iterator_base_funcs.h:152:7:
warning: iteration 9223372036854775807 invokes undefined behavior
[-Waggressive-loop-optimizations]
  152 |   while (__n--) // if n is negative this has undefined behaviour
  | 


It's still a bug that there's no "In instantiation of ... required from ...
required from here" context shown though.

[Bug fortran/86277] Presence of optional arguments not recognized for zero length arrays

[anlauf at gmx dot de]

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

--- Comment #3 from Harald Anlauf  ---
(In reply to Harald Anlauf from comment #2)
> Actually, the problem is not related to zero length arrays, but to the
> constructor [integer::].  I think this is related to several other PRs.

Looking at the dump-tree parts related to the lines

>   integer, parameter :: m(0) = 42
>   call i(m)
>   call i([integer::])
>   call i([integer::m])

shows that only the first call variant has a sane version of the
actual argument, while the other two have two(!) strange array
descriptors with a NULL data pointer, e.g.:

  struct array01_integer(kind=4) atmp.8;
  struct array01_integer(kind=4) atmp.10;

typedef integer(kind=4) [0];
  atmp.8.dtype = {.elem_len=4, .rank=1, .type=1};
  atmp.8.dim[0].stride = 1;
  atmp.8.dim[0].lbound = 0;
  atmp.8.dim[0].ubound = -1;
  atmp.8.data = 0B;
  atmp.8.offset = 0;
typedef integer(kind=4) [0];
  atmp.10.dtype = {.elem_len=4, .rank=1, .type=1};
  atmp.10.dim[0].stride = 1;
  atmp.10.dim[0].lbound = 0;
  atmp.10.dim[0].ubound = -1;
  atmp.10.data = 0B;
  atmp.10.offset = 0;

A bookkeeping issue?

[Bug c++/80472] cannot use push/pop with #pragma GCC diagnostic warning "-Wsystem-headers"

[lopezibanez at gmail dot com]

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

--- Comment #8 from Manuel López-Ibáñez  ---
There is no negative n__ in user code.

On Fri, 22 Mar 2019, 21:21 redi at gcc dot gnu.org, <
gcc-bugzi...@gcc.gnu.org> wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80472
>
> --- Comment #7 from Jonathan Wakely  ---
> A comment added to the code would make the caret diagnostic
> self-explanatory:
>
> --- a/libstdc++-v3/include/bits/stl_iterator_base_funcs.h
> +++ b/libstdc++-v3/include/bits/stl_iterator_base_funcs.h
> @@ -149,7 +149,7 @@ _GLIBCXX_END_NAMESPACE_CONTAINER
>// concept requirements
>__glibcxx_function_requires(_InputIteratorConcept<_InputIterator>)
>__glibcxx_assert(__n >= 0);
> -  while (__n--)
> +  while (__n--) // if n is negative this has undefined behaviour
> ++__i;
>  }
>
> That would make the diagnostic look like:
>
> /home/jwakely/gcc/9/include/c++/9.0.1/bits/stl_iterator_base_funcs.h:152:7:
> warning: iteration 9223372036854775807 invokes undefined behavior
> [-Waggressive-loop-optimizations]
>   152 |   while (__n--) // if n is negative this has undefined
> behaviour
>   |
>
>
> It's still a bug that there's no "In instantiation of ... required from ...
> required from here" context shown though.
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.

[Bug c/89798] excessive vector_size silently accepted and truncated

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-03-22
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
 Ever confirmed|0   |1

[Bug middle-end/89797] ICE on a vector_size (1LU << 33) int variable

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-03-22
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
 Ever confirmed|0   |1

[Bug c++/80472] cannot use push/pop with #pragma GCC diagnostic warning "-Wsystem-headers"

[redi at gcc dot gnu.org]

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

--- Comment #9 from Jonathan Wakely  ---
There is though. std::prev(it, n) is specified as std::advance(it, -n). Calling
prev means advancing a negative amount.

But I'm not sure what your point is. Currently there's no warning by default
even though the compiler has detected UB. Are you saying it is better to not
warn at all, and just have silent UB?

If you want the warning to be improved, please open a separate bug report. This
one is about the inability to enable warnings in system headers, not the
quality of individual warnings.

[Bug c++/80472] cannot use push/pop with #pragma GCC diagnostic warning "-Wsystem-headers"

[redi at gcc dot gnu.org]

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

--- Comment #10 from Jonathan Wakely  ---
(In reply to Manuel López-Ibáñez from comment #8)
> There is no negative n__ in user code.

If you want to be pedantic, there's no __n at all in user code. Because it's a
function parameter of std::advance. But clearly if the compiler says "undefined
behaviour detected at this line" and the line has a comment saying "undefined
if n is negative" then the user can figure out that the function got called
with negative n.

Is that perfect? No. Is it better than printing nothing when UB is detected? To
me the answer is obviously yes, so it seems like you're just objecting to
making improvements.

[Bug fortran/84868] [7/8/9 Regression] ICE in gfc_conv_descriptor_offset, at fortran/trans-array.c:208

[anlauf at gmx dot de]

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

Harald Anlauf  changed:

   What|Removed |Added

 CC||anlauf at gmx dot de

--- Comment #5 from Harald Anlauf  ---
There is a variant that is wrongly rejected:

module m
  implicit none
contains
  function f(n) result(z)
character, save  :: c(3) = ['x', 'y', 'z']
integer,  intent(in) :: n
character(len_trim(c(n))) :: z
z = c(n)
  end
end
program p
  use m
  print *, f(2)
end

pr84868b.f90:7:23:

 character(len_trim(c(n))) :: z
   1
Error: Variable 'c' cannot appear in the expression at (1)

With the following patch len_trim is accepted in a specification expression:

Index: expr.c
===
--- expr.c  (revision 269880)
+++ expr.c  (working copy)
@@ -3402,10 +3402,13 @@
   return false;
 }

-  if (!gfc_simplify_expr (e, 0))
-return false;
+  if (gfc_simplify_expr (e, 0))
+return true;

-  return check_restricted (e);
+  if (check_restricted (e))
+return true;
+
+  return false;
 }

But then we hit the following issue at link time:

pr84868b.f90:(.text+0x12c): undefined reference to `___MOD_c'

[Bug c++/80472] cannot use push/pop with #pragma GCC diagnostic warning "-Wsystem-headers"

[lopezibanez at gmail dot com]

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

--- Comment #11 from Manuel López-Ibáñez  ---
I'm not being pedantic for the sake of being pedantic. It is trivial to fix
the #pragma as I explained above. However, that won't give the user any
idea about which user code is triggering the warning. For that, we need to
have at the point of warning a token that comes from user code or we need
to propagate a user location to the tokens that made up this particular
instantation of the template, so that the diagnostic code can windup the
location stack and find the user code that triggered the warning.


On Fri, 22 Mar 2019, 22:18 redi at gcc dot gnu.org, <
gcc-bugzi...@gcc.gnu.org> wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80472
>
> --- Comment #10 from Jonathan Wakely  ---
> (In reply to Manuel López-Ibáñez from comment #8)
> > There is no negative n__ in user code.
>
> If you want to be pedantic, there's no __n at all in user code. Because
> it's a
> function parameter of std::advance. But clearly if the compiler says
> "undefined
> behaviour detected at this line" and the line has a comment saying
> "undefined
> if n is negative" then the user can figure out that the function got called
> with negative n.
>
> Is that perfect? No. Is it better than printing nothing when UB is
> detected? To
> me the answer is obviously yes, so it seems like you're just objecting to
> making improvements.
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.

[Bug fortran/84868] [7/8/9 Regression] ICE in gfc_conv_descriptor_offset, at fortran/trans-array.c:208

[anlauf at gmx dot de]

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

--- Comment #6 from Harald Anlauf  ---
(In reply to Harald Anlauf from comment #5)
> With the following patch len_trim is accepted in a specification expression:

Just forget that.

[Bug target/89795] wrong code with -O2 -fno-dce -fno-forward-propagate -fno-sched-pressure

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
Most likely related to PR 89434.

[Bug target/89794] wrong code with -Og -fno-forward-propagate

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|rtl-optimization|target

--- Comment #1 from Andrew Pinski  ---
Most likely related to PR 89434.

[Bug c++/80472] cannot use push/pop with #pragma GCC diagnostic warning "-Wsystem-headers"

[redi at gcc dot gnu.org]

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

--- Comment #12 from Jonathan Wakely  ---
And as I've already said, the quality of the particular
-Waggressive-loop-optimizations warning is a separate issue, and should be
dealt with in a separate PR.

PR 58876 (mentioned in comment 0 as the reason for creating this bug) shows a
proper instantiation trace when -Wsystem-headers is used:

In file included from /home/jwakely/gcc/9/include/c++/9.0.1/memory:80,
 from up.cc:1:
/home/jwakely/gcc/9/include/c++/9.0.1/bits/unique_ptr.h: In instantiation of
'void std::default_delete<_Tp>::operator()(_Tp*) const [with _Tp = A]':
/home/jwakely/gcc/9/include/c++/9.0.1/bits/unique_ptr.h:289:17:   required from
'std::unique_ptr<_Tp, _Dp>::~unique_ptr() [with _Tp = A; _Dp =
std::default_delete]'
up.cc:12:30:   required from here
/home/jwakely/gcc/9/include/c++/9.0.1/bits/unique_ptr.h:81:2: warning: deleting
object of abstract class type 'A' which has non-virtual destructor will cause
undefined behavior [-Wdelete-non-virtual-dtor]
   81 |  delete __ptr;
  |  ^~

That shows the up.cc:12 location from the user code that triggers the warning.

But I can't make libstdc++ show that warning because of this bug with the
diagnostic pragmas.

Improving the warning in comment 4 is irrelevant to this bug.

[Bug c++/43167] Warnings should not be disabled when instantiating templates defined in system headers

[redi at gcc dot gnu.org]

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

--- Comment #20 from Jonathan Wakely  ---
(In reply to Manuel López-Ibáñez from comment #19)
> I wonder what happens if you used something that actually has a
> location, like an expression, for the first test case using emplace().

It doesn't make any difference.

[Bug c/89799] New: no warning declaring an misaligned array of overaligned structs

[msebor at gcc dot gnu.org]

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

Bug ID: 89799
   Summary: no warning declaring an misaligned array of
overaligned structs
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

Attribute warn_if_not_aligned is documented like so:

This attribute specifies a threshold for the structure field, measured in
bytes. If the structure field is aligned below the threshold, a warning will be
issued.

The test case below shows that the attributed does not have the documented
effect when an object of a type of a struct with an overaligned member is
defined with a less restrictive alignment.

$ cat z.c && gcc -O2 -S -Wall -Wextra -fdump-tree-optimized=/dev/stdout  z.c
#define ALIGN(N) __attribute__ ((aligned (N), warn_if_not_aligned (N)))

struct ALIGN (64) S { ALIGN (64) char a[64]; };

struct S __attribute__ ((aligned (8))) s;   // unaligned, missing warning

int f (void) { return __alignof__ (s); }


typedef struct S __attribute__ ((aligned (8))) A[1];   // unaligned, missing
warning

A a;   // unaligned, missing warning

int g (void) { return __alignof__ (a); }
int h (void) { return __alignof__ (a[0]); }

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

f ()
{
   [local count: 1073741824]:
  return 8;

}



;; Function g (g, funcdef_no=4, decl_uid=1914, cgraph_uid=2, symbol_order=3)

g ()
{
   [local count: 1073741824]:
  return 8;

}



;; Function h (h, funcdef_no=2, decl_uid=1917, cgraph_uid=3, symbol_order=4)

h ()
{
   [local count: 1073741824]:
  return 64;

}

[Bug tree-optimization/89800] New: -Waggressive-loop-optimization warning doesn't have useful location

[redi at gcc dot gnu.org]

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

Bug ID: 89800
   Summary: -Waggressive-loop-optimization warning doesn't have
useful location
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

Given:

template
T foo(T t, int n)
{
  while (n--)
++t;
  return t;
}

int bar(int n) { return foo(1, n); }

int main()
{
  return bar(-1);
}

GCC prints:

loop.cc: In function 'int main()':
loop.cc:4:3: warning: iteration 2147483647 invokes undefined behavior
[-Waggressive-loop-optimizations]
4 |   while (n--)
  |   ^
loop.cc:4:3: note: within this loop

This isn't very helpful, because the loop isn't in the function 'int main()' as
shown, it's in foo, and there's no indication of how foo was called from main
(there could be several different places in main that indirectly end up calling
foo).

I would expect to see something more like:


loop.cc:4:3: warning: iteration 2147483647 invokes undefined behavior
[-Waggressive-loop-optimizations]
4 |   while (n--)
  |   ^
loop.cc:4:3: note: within this loop
loop.cc:2:1 In instantiation of 'foo(T, int) [with T = int]':
loop.cc:9:25  required from 'int bar(int)':
loop.cc:13:10: required from here


A more realistic example is:

#include 
#include 
#include 

template
typename T::value_type
back(const T& t)
{
  return *std::prev(t.end());
}

int main()
{
  std::array a = { {1, 2} };
  std::forward_list l = {1, 2, 3};
  return back(a) - back(l);
}

With -Wall -Wsystem-headers -O1 this prints:

In file included from
/home/jwakely/gcc/9/include/c++/9.0.1/bits/stl_algobase.h:66,
 from
/home/jwakely/gcc/9/include/c++/9.0.1/bits/char_traits.h:39,
 from /home/jwakely/gcc/9/include/c++/9.0.1/string:40,
 from /home/jwakely/gcc/9/include/c++/9.0.1/stdexcept:39,
 from /home/jwakely/gcc/9/include/c++/9.0.1/array:39,
 from prev.cc:1:
/home/jwakely/gcc/9/include/c++/9.0.1/bits/stl_iterator_base_funcs.h: In
function 'int main()':
/home/jwakely/gcc/9/include/c++/9.0.1/bits/stl_iterator_base_funcs.h:153:7:
warning: iteration 9223372036854775806 invokes undefined behavior
[-Waggressive-loop-optimizations]
  153 |   while (__n--)
  |   ^
/home/jwakely/gcc/9/include/c++/9.0.1/bits/stl_iterator_base_funcs.h:153:7:
note: within this loop

The only location info is the "In file included from" which only shows the
header include stack and the lines of the #include directives, not the call
stack that reached std::__advance where the UB is detected.

The headers suggest that it maybe came from the  header, but the back(a)
call is fine, the problem is the back(l) call. (The reason is shows the array
header is  that that's the route by which the 
header gets included, but is not the call stack for the undefined call).

To be useful the warning needs to show the template instantiation context,
something like:

void std::__advance<_InputIterator, _Distance>(_InputIterator&, _Distance,
input_iterator_tag) [with _InputIterator =
std::forward_list::const_iterator, _Distance = int]

void std::advance<_InputIterator, _Distance>(_InputIterator&, _Distance) [with
_InputIterator = std::forward_list::const_iterator, _Distance = int]

void std::prev<_BidirectionalIterator>(_BidirectionalIterator&, ...) [with
_BidirectionalIterator = std::forward_list::const_iterator]

T::value_type back(const T&) [with T = std::forward_list]

prev.cc:16:20 required from here
 return back(a) - back(l);
  ^^^

This allows the user to see how the undefined behaviour happened.

(As an aside, should it say "results in undefined behavior" or "has undefined
behavior" not "invokes undefined behavior"? You don't invoke UB, it's not a
function.)

[Bug c++/80472] cannot use push/pop with #pragma GCC diagnostic warning "-Wsystem-headers"

[redi at gcc dot gnu.org]

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

--- Comment #13 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #12)
> Improving the warning in comment 4 is irrelevant to this bug.

I've created Bug 89800 for improving that warning, please move that discussion
there.

[Bug debug/89801] New: gcc generates wrong debug information at -O2

[qrzhang at gatech dot edu]

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

Bug ID: 89801
   Summary: gcc generates wrong debug information at -O2
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: qrzhang at gatech dot edu
  Target Milestone: ---

It affects gcc-6 to gcc-trunk. gcc-5 works fine.

Bisect points to r222305.


$ gcc-trunk -v
gcc version 9.0.1 20190322 (experimental) [trunk revision 269869] (GCC)

$ gdb -v
GNU gdb (Ubuntu 7.11.1-0ubuntu1~16.5) 7.11.1


# Correct ouutput #
$ gcc-trunk  -g abc.c outer.c
$ gdb -x cmds -batch a.out
Breakpoint 1 at 0x400486: file abc.c, line 9.

Breakpoint 1, d () at abc.c:9
9 c = 3;
$1 = 1


# Incorrect output at O2 #
$ gcc-trunk  -g abc.c outer.c -O2
$ gdb -x cmds -batch a.out
Breakpoint 1 at 0x400380: file abc.c, line 9.

Breakpoint 1, main () at abc.c:18
18for (; i < 5; i++)
$1 = 0





$ cat abc.c
long a, b;
static int c, f;
static long d() {
  int *e = &c;
  int i = 0;
  for (; i < 1; i++)
;
  *e ^= b;
  c = 3;
  for (; 0;)
optimize_me_not();
  ;
}
int main() {
  int i;
  d();
  i = 0;
  for (; i < 5; i++)
for (; f; f++)
  ;
  a = c;
}


$ cat outer.c
void optimize_me_not() {}

$ cat cmds
b 9
r
p i
kill
q

[Bug rtl-optimization/85528] ICE in code_motion_process_successors, at sel-sched.c:6403

[asolokha at gmx dot com]

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

Arseny Solokha  changed:

   What|Removed |Added

 Target|powerpc-*-linux-gnu*,   |powerpc-*-linux-gnu*,
   |powerpcspe-*-linux-gnu* |powerpcspe-*-linux-gnu*,
   ||x86_64-unknown-linux-gnu

--- Comment #3 from Arseny Solokha  ---
The following testcase fails for x86_64 w/ the current trunk:

int oh;
__int128 ii, pa;
unsigned __int128 kn;

void
vz (void)
{
  while (oh < 1)
{
  if (oh <= kn)
{
  __int128 *iu;

  if (oh == 0)
{
  ii |= pa;
  if (ii != 0)
while (kn != 0)
  ++kn;
}

  iu = &pa;
  kn *= 3;
  pa += kn;
}

  ++oh;
}
}

% x86_64-unknown-linux-gnu-gcc-9.0.0-alpha20190317 -O2 -fselective-scheduling2
-fvar-tracking-assignments -fno-tree-ter -w -c kchunwgx.c
during RTL pass: sched2
kchunwgx.c: In function 'vz':
kchunwgx.c:29:1: internal compiler error: in code_motion_process_successors, at
sel-sched.c:6399
   29 | }
  | ^
0x6806f9 code_motion_process_successors
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190317/work/gcc-9-20190317/gcc/sel-sched.c:6399
0x6806f9 code_motion_path_driver
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190317/work/gcc-9-20190317/gcc/sel-sched.c:6621
0xd3013b code_motion_process_successors
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190317/work/gcc-9-20190317/gcc/sel-sched.c:6355
0xd3013b code_motion_path_driver
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190317/work/gcc-9-20190317/gcc/sel-sched.c:6621
0xd32f39 move_op
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190317/work/gcc-9-20190317/gcc/sel-sched.c:6713
0xd32f39 move_exprs_to_boundary
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190317/work/gcc-9-20190317/gcc/sel-sched.c:5236
0xd32f39 schedule_expr_on_boundary
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190317/work/gcc-9-20190317/gcc/sel-sched.c:5449
0xd34627 fill_insns
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190317/work/gcc-9-20190317/gcc/sel-sched.c:5591
0xd34627 schedule_on_fences
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190317/work/gcc-9-20190317/gcc/sel-sched.c:7364
0xd34627 sel_sched_region_2
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190317/work/gcc-9-20190317/gcc/sel-sched.c:7502
0xd36538 sel_sched_region_1
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190317/work/gcc-9-20190317/gcc/sel-sched.c:7544
0xd38056 sel_sched_region(int)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190317/work/gcc-9-20190317/gcc/sel-sched.c:7645
0xd38056 sel_sched_region(int)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190317/work/gcc-9-20190317/gcc/sel-sched.c:7630
0xd38beb run_selective_scheduling()
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190317/work/gcc-9-20190317/gcc/sel-sched.c:7731
0xd172a5 rest_of_handle_sched2
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190317/work/gcc-9-20190317/gcc/sched-rgn.c:3731
0xd172a5 execute
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190317/work/gcc-9-20190317/gcc/sched-rgn.c:3875

[Bug tree-optimization/89802] New: [9 Regresssion] ICE: verify_gimple failed (error: dead STMT in EH table)

[asolokha at gmx dot com]

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

Bug ID: 89802
   Summary: [9 Regresssion] ICE: verify_gimple failed (error: dead
STMT in EH table)
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: ice-checking, ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

g++-9.0.0-alpha20190317 snapshot (r269746) ICEs when compiling the following
testcase w/ -mfma -O2 (-O3, -Os) -fnon-call-exceptions:

struct ef {
  ef (double xy) : m6 (xy)
  {
  }

  ~ef ()
  {
  }

  double m6;
};

ef
operator- (ef &db, ef oa)
{
  return db.m6 - oa.m6;
}

ef
vu (ef &db)
{
  return db - ef (db.m6 * 1.1);
}

% x86_64-unknown-linux-gnu-g++-9.0.0-alpha20190317 -mfma -O2
-fnon-call-exceptions -c xct1znkp.cc
xct1znkp.cc: In function 'ef vu(ef&)':
xct1znkp.cc:20:1: error: dead STMT in EH table
   20 | vu (ef &db)
  | ^~
_6 = .FMA (_7, 1.100088817841970012523233890533447265625e+0, _3);
during GIMPLE pass: widening_mul
xct1znkp.cc:20:1: internal compiler error: verify_gimple failed
0xfe2271 verify_gimple_in_cfg(function*, bool)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190317/work/gcc-9-20190317/gcc/tree-cfg.c:5386
0xeb7dff execute_function_todo
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190317/work/gcc-9-20190317/gcc/passes.c:1977
0xeb8d3e execute_todo
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190317/work/gcc-9-20190317/gcc/passes.c:2031