[Bug target/86547] s390x: Maximum number of LRA assignment passes is achieved (30) when compiling a small inline assembler snippet

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||law at redhat dot com
 Resolution|--- |FIXED

--- Comment #9 from Jeffrey A. Law  ---
Fixed on the trunk.

[Bug target/86547] s390x: Maximum number of LRA assignment passes is achieved (30) when compiling a small inline assembler snippet

[law at gcc dot gnu.org]

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

--- Comment #8 from Jeffrey A. Law  ---
Author: law
Date: Wed Aug 15 04:09:45 2018
New Revision: 263548

URL: https://gcc.gnu.org/viewcvs?rev=263548=gcc=rev
Log:
PR target/86547
* lra-lives.c (remove_some_program_points_and_update_live_ranges):
Check whether lra_live_max_point is 0 before dividing.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/lra-lives.c

[Bug target/65604] MIPS -fno-delayed-branch generates incorrect code with -mcheck-zero-division

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

--- Comment #8 from Eric Gallager  ---
(In reply to Eric Gallager from comment #7)
> 
> WAITING on an answer...

No reply so I'm assuming that this was fixed.

[Bug c++/69089] C++11: alignas(0) causes an error

[egallager at gcc dot gnu.org]

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

--- Comment #6 from Eric Gallager  ---
(In reply to Dominik Vogt from comment #5)
> No, up to now you're the only one who commented on it.  I keep pinging it
> once in a while.

Please keep pinging it!

[Bug c++/67012] decltype(auto) with trailing return type

[redbeard0531 at gmail dot com]

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

Mathias Stearn  changed:

   What|Removed |Added

 CC||redbeard0531 at gmail dot com

--- Comment #1 from Mathias Stearn  ---
Still repros with latest trunk builds, even with -pedantic:
https://godbolt.org/g/vMDcwg

[Bug target/86777] Bfin port needs updating for CVE-2017-5753

[jiez at gcc dot gnu.org]

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

--- Comment #1 from Jie Zhang  ---
(In reply to Richard Earnshaw from comment #0)
> The bfin port needs updating for this CVE.  See the linked meta bug for
> details of possible actions required.

For Blackfin, the speculative load only happens when the load instruction is
the next instruction after conditional jump instruction. For example,

conditional jump
load

The above load will be speculatively executed. But

conditional jump
add
load

this load will not.

Is there a way to control speculation barrier being only inserted for the first
case, but not for the second case? Thanks.

Jie

[Bug libstdc++/86954] redundant nothrow in call of ::operator delete

[frankhb1989 at gmail dot com]

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

--- Comment #4 from frankhb1989 at gmail dot com ---
Well, actually I'm not sure if the original implementation has done the right
thing, as I don't find that the standard has requirement to specify that the
replaced definitions must acknowledge the fact nothrow_t overloads should only
be called on the specified condition (... and if so, whether it worth an LWG
issue).

But that still seems suspicious to me, because symmetry of call between
nothrow_t placement ::operator new and ::operator delete does not exist in the
language indeed, so that seems like an unintentional use unless it is
documented elsewhere. On the other hand, the change here towards to a simpler
and undoubtedly conformant way.

BTW, I do know the feature is deprecated in C++17 and removed in C++2a. I read
the paper of deprecation. It is plausible to be removed from the standard, but
not a must - not with a very strong reason. However, I am sure I do need that
feature so I have to reinvent my wheels... as done internally by various
standard library implementations. (More specifically, I need
std::_Temporary_buffer in libstdc++ and MSVC's current 
implementation, or at least something equivalent to
std::__return_temporary_buffer in libc++, but surely I can't rely on them
directly.) At least a raw call of allocation function does not always express
the intended call site requirements clearly like std::get_temporary_buffer, so
users who want to make it clear have to afford the extra layer of an
abstraction. Arguably, the removal will bloat work for anyone wants that and
discourage clearer expression of intentions.

[Bug target/86731] [8/9 Regression] Miscompiles vec_sl at -O3 with -fwrapv on ppc64el

[willschm at gcc dot gnu.org]

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

--- Comment #2 from Will Schmidt  ---
Thanks for the bug report.
The patch  (attached) has also been posted to gcc-patches for review.

Thanks,

[Bug target/86731] [8/9 Regression] Miscompiles vec_sl at -O3 with -fwrapv on ppc64el

[willschm at gcc dot gnu.org]

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

--- Comment #1 from Will Schmidt  ---
Created attachment 44542
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44542=edit
preliminary patch to resolve the problem

preliminary/rfc patch.

[Bug c/28848] argument mismatch for late-prototyped function should be warning, not error

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||msebor at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #1 from Martin Sebor  ---
The test was removed in r125974 but it compiles without an error or warning
now.

[Bug other/29842] [meta-bug] outstanding patches / issues from STMicroelectronics

[msebor at gcc dot gnu.org]

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

Bug 28848 Summary: argument mismatch for late-prototyped function should be 
warning, not error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28848

   What|Removed |Added

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

[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

--- Comment #4 from H.J. Lu  ---
line-map.c has

 linemap_assert (reason != LC_ENTER_MACRO);
  line_map_ordinary *map
= linemap_check_ordinary (new_linemap (set, start_location));
  map->reason = reason;

We get here with reason != LC_ENTER_MACRO and create linemap with
start_location >= LINE_MAP_MAX_LOCATION.

[Bug fortran/86945] BUG with optimisation of select case statement in gfortran v8.x

[anlauf at gmx dot de]

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

--- Comment #3 from Harald Anlauf  ---
Self contained alternative testcase:

program test
  implicit none
  integer, volatile :: id,ierr
  id = 1
  print*,'id=',id
  call foo1 ()
  print*,'ierr1, OK = ',ierr, ierr == 0
  call foo2 ()
  print*,'ierr2, OK = ',ierr, ierr == 0
contains
  subroutine foo1 ()
select case(id)
case(-HUGE(0):-1)
   ierr = id
case default
   ierr = 0
end select
  end subroutine foo1
  subroutine foo2 ()
select case(id)
!   case(-HUGE(0)-1:-1)
case(  :-1)
   ierr = id
case default
   ierr = 0
end select
  end subroutine foo2
end program test

With -O0:

 id=   1
 ierr1, OK =0 T
 ierr2, OK =0 T

With -Og, -O1 and higher:

 id=   1
 ierr1, OK =0 T
 ierr2, OK =1 F

[Bug c++/84840] [6/7/8 Regression] ICE (in poplevel_class) for `auto` in alias declaration

[v.reshetnikov at gmail dot com]

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

Vladimir Reshetnikov  changed:

   What|Removed |Added

 Status|RESOLVED|VERIFIED

--- Comment #3 from Vladimir Reshetnikov  ---
Verified.

[Bug c++/84798] [6/7 Regression] ICE (Segmentation fault) if `auto` appears in a template argument

[v.reshetnikov at gmail dot com]

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

Vladimir Reshetnikov  changed:

   What|Removed |Added

 Status|RESOLVED|VERIFIED

--- Comment #11 from Vladimir Reshetnikov  ---
Verified.

[Bug c++/84839] [6/7 Regression] ICE (Segmentation fault) when `decltype` is used with parameter pack

[v.reshetnikov at gmail dot com]

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

Vladimir Reshetnikov  changed:

   What|Removed |Added

 Status|RESOLVED|VERIFIED

--- Comment #5 from Vladimir Reshetnikov  ---
Verified.

[Bug c++/86728] [7/8/9 Regression] unexpected error: conversion from ', ...)>' to non-scalar type 'std::function' requested

[v.reshetnikov at gmail dot com]

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

Vladimir Reshetnikov  changed:

   What|Removed |Added

 Status|RESOLVED|VERIFIED

--- Comment #7 from Vladimir Reshetnikov  ---
Verified in 9.0.0 20180813 (experimental).

[Bug c++/86915] Segmentation fault for an array of auto in template parameter

[v.reshetnikov at gmail dot com]

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

Vladimir Reshetnikov  changed:

   What|Removed |Added

 Status|RESOLVED|VERIFIED

--- Comment #4 from Vladimir Reshetnikov  ---
Verified.

[Bug c++/86958] ICE in finish_member_declaration when an alias template is used

[v.reshetnikov at gmail dot com]

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

Vladimir Reshetnikov  changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

--- Comment #6 from Vladimir Reshetnikov  ---
I filed a corrected version as Bug 86961.

[Bug c++/86961] New: ICE in finish_member_declaration when an alias template is used

[v.reshetnikov at gmail dot com]

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

Bug ID: 86961
   Summary: ICE in finish_member_declaration when an alias
template is used
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: v.reshetnikov at gmail dot com
  Target Milestone: ---

/** BEGIN SOURCE **/
template
struct Outer {
template
struct Inner;

template
using Alias = Inner;
};

template<>
template
struct Outer::Inner { 
static constexpr auto value = sizeof(T);
};

static_assert(Outer::Inner::value == sizeof(bool)); // OK
static_assert(Outer::Alias::value == sizeof(bool)); // error

/*** END SOURCE ***/

The first static_assert compiles OK, but the second results in an ICE:

/** BEGIN OUTPUT **/
: In instantiation of 'struct Outer::Inner':
:17:39:   required from here
:13:27: internal compiler error: in finish_member_declaration, at
cp/semantics.c:3085
13 | static constexpr auto value = sizeof(T);
   |   ^
Compiler returned: 1

/*** END OUTPUT ***/

This issue was found with build 9.0.0 20180813 (experimental), but appears to
exist in earlier versions as well.

For comparison, Clang compiles this code successfully.

[Bug fortran/86945] BUG with optimisation of select case statement in gfortran v8.x

[anlauf at gmx dot de]

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

--- Comment #2 from Harald Anlauf  ---
Changing the line:

case(:-1)

to

case(-HUGE(0):-1)

makes the bug disappear; changing it to

case(-HUGE(0)-1:-1)

makes it reappear.

[Bug fortran/86945] BUG with optimisation of select case statement in gfortran v8.x

[anlauf at gmx dot de]

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

Harald Anlauf  changed:

   What|Removed |Added

 CC||anlauf at gmx dot de

--- Comment #1 from Harald Anlauf  ---
The bug also occurs with -Og.  Maybe it's not a frontend problem.

[Bug c++/86958] ICE in finish_member_declaration when an alias template is used

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #5 from Marek Polacek  ---
OK, closing then.

[Bug c++/86960] [Regression] internal compiler error: in coerce_template_parms

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #1 from Marek Polacek  ---
Confirmed.

commit e5a3303f90fcbcba4d8cd9cdcc0a2c7f45958b25
Author: jason 
Date:   Wed Feb 26 17:08:20 2014 +

PR c++/54440
* pt.c (get_template_parm_index): New.
(fixed_parameter_pack_p_1, fixed_parameter_pack_p): New.
(process_template_parm): Allow bare packs in template template
parm template parms.
(coerce_template_parameter_pack): Handle fixed template template
parm packs and fixed packs not at the end of the parm list.
(coerce_template_parms): Handle template parm packs not at the end
of the parm list.
(gen_elem_of_pack_expansion_instantiation): Handle a decl
expansion.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@208178
138bc75d-0d04-0410-961f-82ee72b054a4

[Bug target/84908] retpoline weirdness: 7.3.0-1 and 4.8.5-16: with -fPIC: R_X86_64_PC32 against undefined symbol `__x86_indirect_thunk_rax'

[luto at kernel dot org]

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

--- Comment #13 from Andy Lutomirski  ---
I find this whole discussion very confusing.  The problem has nothing to do
with relocations AFAICT.  The problem is that gcc is (as requested) generating
retpolines, and it's set up to do it by calling __x86_indirect_thunk_*, and
those helpers don't exist in the vDSO.

I also think that static inlines have anything to do with it.  Nor so I see why
any function attributes make any sense.

The trivial fix is:

diff --git a/arch/x86/entry/vdso/Makefile b/arch/x86/entry/vdso/Makefile
index 261802b1cc50..8140176b8b41 100644
--- a/arch/x86/entry/vdso/Makefile
+++ b/arch/x86/entry/vdso/Makefile
@@ -74,7 +74,7 @@ CFL := $(PROFILING) -mcmodel=small -fPIC -O2
-fasynchronous-unwind-tables -m64 \
-fno-omit-frame-pointer -foptimize-sibling-calls \
-DDISABLE_BRANCH_PROFILING -DBUILD_VDSO

-$(vobjs): KBUILD_CFLAGS := $(filter-out
$(GCC_PLUGINS_CFLAGS),$(KBUILD_CFLAGS)) $(CFL)
+$(vobjs): KBUILD_CFLAGS := $(filter-out $(GCC_PLUGINS_CFLAGS)
$(RETPOLINE_CFLAGS),$(KBUILD_CFLAGS)) $(CFL)

 #
 # vDSO code runs in userspace and -pg doesn't help with profiling anyway.
@@ -138,6 +138,7 @@ KBUILD_CFLAGS_32 := $(filter-out
-mcmodel=kernel,$(KBUILD_CFLAGS_32))
 KBUILD_CFLAGS_32 := $(filter-out -fno-pic,$(KBUILD_CFLAGS_32))
 KBUILD_CFLAGS_32 := $(filter-out -mfentry,$(KBUILD_CFLAGS_32))
 KBUILD_CFLAGS_32 := $(filter-out $(GCC_PLUGINS_CFLAGS),$(KBUILD_CFLAGS_32))
+KBUILD_CFLAGS_32 := $(filter-out $(RETPOLINE_CFLAGS),$(KBUILD_CFLAGS_32))
 KBUILD_CFLAGS_32 += -m32 -msoft-float -mregparm=0 -fpic
 KBUILD_CFLAGS_32 += $(call cc-option, -fno-stack-protector)
 KBUILD_CFLAGS_32 += $(call cc-option, -foptimize-sibling-calls)

but it might be better to use the internal thunk mechanism.

You said that Andi Kleen had a comment.  Can you point me to it?

[Bug c++/86958] ICE in finish_member_declaration when an alias template is used

[v.reshetnikov at gmail dot com]

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

--- Comment #4 from Vladimir Reshetnikov  ---
Apparently, I somehow pasted a wrong code into this bug report. If you wish,
you can close this one, and I will file proper one(s).

[Bug c++/86960] New: [Regression] internal compiler error: in coerce_template_parms

[v.reshetnikov at gmail dot com]

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

Bug ID: 86960
   Summary: [Regression] internal compiler error: in
coerce_template_parms
   Product: gcc
   Version: 8.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: v.reshetnikov at gmail dot com
  Target Milestone: ---

/** BEGIN SOURCE **/
template
struct Outer {
template
struct Inner;
};

template<>
template
struct Outer::Inner { 
static constexpr bool value = x;
};

static_assert(Outer::Inner::value); /* internal compiler error: in
coerce_template_parms, at cp/pt.c:8533 */

/*** END SOURCE ***/

Fails in GCC 8.1 and 8.2, compiles successfully with 7.3.

Might be related to Bug 86918, Bug 86920, Bug 86956, Bug 86958.

[Bug c++/65043] Expected narrowing conversion during list initialization of bool from double

[mpolacek at gcc dot gnu.org]

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

--- Comment #3 from Marek Polacek  ---
Testing a patch now.

[Bug c++/86918] internal compiler error: unexpected expression 'v' of kind template_parm_index

[v.reshetnikov at gmail dot com]

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

--- Comment #4 from Vladimir Reshetnikov  ---
I could not find a wording in the Standard that disallows this kind of
specialization (although certainly I might have overlooked it). A similar code
where the template parameter list is changed in a specialization compiles
successfully with GCC:

template
struct Outer {
template
struct Inner;
};

template<>
template
struct Outer::Inner { 
static constexpr auto value = sizeof...(x);
};

static_assert(Outer::Inner<>::value == 0); // OK

[Bug target/84908] retpoline weirdness: 7.3.0-1 and 4.8.5-16: with -fPIC: R_X86_64_PC32 against undefined symbol `__x86_indirect_thunk_rax'

[jason.vas.dias at gmail dot com]

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

--- Comment #12 from Jason Vas Dias  ---
RE: Comment #11 :
>   notrace int _RETPOLINE_FUNC_ATTR_ 
>   __vdso_clock_gettime(clockid_t clock, struct timespec *ts)
should of course be
   notrace _RETPOLINE_FUNC_ATTR_ 
   int __vdso_clock_gettime(clockid_t clock, struct timespec *ts)
- sorry, I was typing from memory, not pasting.

[Bug libstdc++/86954] redundant nothrow in call of ::operator delete

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #3 from Jonathan Wakely  ---
On the other hand, with PR 68210 fixed the change is harmless. So fixed on
trunk.

Not suitable for backports though.

[Bug libstdc++/86954] redundant nothrow in call of ::operator delete

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
Author: redi
Date: Tue Aug 14 20:19:20 2018
New Revision: 263542

URL: https://gcc.gnu.org/viewcvs?rev=263542=gcc=rev
Log:
PR libstdc++/86954 use non-placement operator delete

As explained in the PR, there's no reason to call the nothrow delete,
we can just use the normal one.

PR libstdc++/86954
* include/bits/stl_tempbuf.h (return_temporary_buffer): Use
non-placement delete.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/stl_tempbuf.h

[Bug libstdc++/86954] redundant nothrow in call of ::operator delete

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
Arguably this was good defensive programming for C++03. The program could have
replaced operator new(size_t) and operator delete(void*) but not replaced
operator new(size_t, const nothrow_t&) and operator delete(void*, const
nothrow_t&). That would be undefined (C++03 [lib.new.delete.single] p7) but by
using the nothrow version of operator delete the library avoids mixing the
default version of new with a replaced version of delete. LWG 206 changed the
behaviour for C++11, so that combining the nothrow new and normal delete does
the right thing, but GCC has only met that requirement since yesterday.

I'm not sure it's worth changing anything here now. get_temporary_buffer was
deprecated and removed from C++2a anyway.

[Bug c++/86959] New: Use of a variadic alias template unexpectedly breaks compilation

[v.reshetnikov at gmail dot com]

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

Bug ID: 86959
   Summary: Use of a variadic alias template unexpectedly breaks
compilation
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: v.reshetnikov at gmail dot com
  Target Milestone: ---

/*** BEGIN SOURCE ***/
template
struct Outer {
template
struct Inner;

template
using Alias = Inner;
};

template<>
template
struct Outer::Inner { 
static constexpr auto value = sizeof...(T);
};

static_assert(Outer::Inner::value == 1); // OK
static_assert(Outer::Alias::value == 1); // error

/ END SOURCE /

The first static_assert compiles OK, but the second results in unexpected
errors:

/*** BEGIN OUTPUT ***/
: In instantiation of 'struct Outer::Inner':
:17:39:   required from here
:12:27: error: template argument 1 is invalid
12 | struct Outer::Inner {
   |   ^
:12:27: error: template argument 1 is invalid
:13:27: error: template argument 1 is invalid
13 | static constexpr auto value = sizeof...(T);
   |   ^
:13:27: error: template argument 1 is invalid
:17:41: error: 'value' is not a member of 'Outer::Alias'
{aka 'Outer::Inner'}
17 | static_assert(Outer::Alias::value == 1); // error
   | ^
Compiler returned: 1

/ END OUTPUT /

The issue was discovered with build 9.0.0 20180813 (experimental), but appears
to exist in earlier versions as well.

For comparison, Clang compiles this code successfully.

Might be related to Bug 86956 and Bug 86958.

[Bug c++/86958] ICE in finish_member_declaration when an alias template is used

[mpolacek at gcc dot gnu.org]

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

--- Comment #3 from Marek Polacek  ---
note:   expected a constant of type ‘bool’, got ‘bool’
Though this is clearly bogus.

[Bug c++/86958] ICE in finish_member_declaration when an alias template is used

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #2 from Marek Polacek  ---
I don't see the ICE:

$ ./cc1plus -quiet 86958.C 
86958.C:16:38: error: type/value mismatch at argument 1 in template parameter
list for ‘template template > struct Outer<
 >::Inner’
16 | static_assert(Outer::Inner::value == sizeof(bool)); // OK
   |  ^
86958.C:16:38: note:   expected a constant of type ‘bool’, got ‘bool’
86958.C:17:38: error: type/value mismatch at argument 1 in template parameter
list for ‘template template using Alias = Outer<
 >::Inner’
17 | static_assert(Outer::Alias::value == sizeof(bool)); // error
   |  ^
86958.C:17:38: note:   expected a constant of type ‘bool’, got ‘bool’

[Bug c++/86958] ICE in finish_member_declaration when an alias template is used

[v.reshetnikov at gmail dot com]

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

--- Comment #1 from Vladimir Reshetnikov  ---
Sorry, there is a missing closing parenthesis in my code. The last line should
look like this:

static_assert(Outer::Alias::value == sizeof(bool)); // error

[Bug c++/65043] Expected narrowing conversion during list initialization of bool from double

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek  ---
Simplified:

struct X
{
  X(bool) { }
};

int main() 
{
  X x{1.2};
}

[Bug c++/86958] New: ICE in finish_member_declaration when an alias template is used

[v.reshetnikov at gmail dot com]

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

Bug ID: 86958
   Summary: ICE in finish_member_declaration when an alias
template is used
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: v.reshetnikov at gmail dot com
  Target Milestone: ---

/** BEGIN SOURCE **/
template
struct Outer {
template
struct Inner;

template
using Alias = Inner;
};

template<>
template
struct Outer::Inner { 
static constexpr bool value = v;
};

static_assert(Outer::Inner::value == sizeof(bool)); // OK
static_assert(Outer::Alias::value == sizeof(bool); // error

/*** END SOURCE ***/

The first static_assert compiles OK, but the second results in an ICE:

/** BEGIN OUTPUT **/
: In instantiation of 'struct Outer::Inner':
:17:39:   required from here
:13:27: internal compiler error: in finish_member_declaration, at
cp/semantics.c:3085
13 | static constexpr auto value = sizeof(T);
   |   ^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
Compiler returned: 1

/*** END OUTPUT ***/

This issue was found with build 9.0.0 20180813 (experimental), but appears to
exist in earlier versions as well.

For comparison, Clang compiles this code successfully.

[Bug c++/78244] Narrowing conversion is accepted in a function template, but it should be rejected

[mpolacek at gcc dot gnu.org]

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

--- Comment #5 from Marek Polacek  ---
And with class templates:

template
struct S {
  static const int i{1.1};
};

[Bug c++/78244] Narrowing conversion is accepted in a function template, but it should be rejected

[mpolacek at gcc dot gnu.org]

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

--- Comment #4 from Marek Polacek  ---
Another simple test:

template
decltype(int{1.1}) v;

[Bug tree-optimization/86650] -Warray-bounds missing inlining context

[msebor at gcc dot gnu.org]

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

--- Comment #5 from Martin Sebor  ---
Another small enhancement committed in r263541.  The inlining context is not
yet included so leaving this open until it's done.

[Bug tree-optimization/86650] -Warray-bounds missing inlining context

[msebor at gcc dot gnu.org]

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

--- Comment #4 from Martin Sebor  ---
Author: msebor
Date: Tue Aug 14 19:11:20 2018
New Revision: 263541

URL: https://gcc.gnu.org/viewcvs?rev=263541=gcc=rev
Log:
PR tree-optimization/86650 - -Warray-bounds missing inlining context

gcc/ChangeLog:

PR tree-optimization/86650
* tree-vrp.c (vrp_prop::check_array_ref): Print an inform message.
(vrp_prop::check_mem_ref): Same.

gcc/testsuite/ChangeLog:

PR tree-optimization/86650
* gcc.dg/Warray-bounds-34.c: New test.


Added:
trunk/gcc/testsuite/gcc.dg/Warray-bounds-34.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vrp.c

[Bug middle-end/86957] New: gcc should warn about missing profiles for a compilation unit or a new function with -fprofile-use

[ibhagatgnu at gmail dot com]

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

Bug ID: 86957
   Summary: gcc should warn about missing profiles for a
compilation unit or a new function with -fprofile-use
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ibhagatgnu at gmail dot com
CC: mliska at suse dot cz
  Target Milestone: ---

When using -fprofile-use in the FDO build, gcc currently does not warn about
about the following two cases. 

Both the cases are related to a missing profiles.

Discussed here on mailing list https://gcc.gnu.org/ml/gcc/2018-08/msg00048.html

CASE 1 : Missing profile for a new function
---
If a new function foo() is added to the file, gcc only warns about those
existing functions whose source locations have been impacted by foo() by
issuing the following :

"warning : source locations for function 'XXX' have changed, the profile data
may be out of date [-Werror=coverage-mismatch]"

Proposal to add a warning for the new function foo() along the lines of - 
"warning : profile for function ‘XXX’ not found in profile data
[-Wmissing-profile]"

Note that, the corner case of foo() being added to the end of the file is
exclusively covered by the proposed -Wmissing-profile

CASE 2 : Missing profile for a compilation unit
---
This is the case when, e.g., a new source file is added to the project after
profile generation phase. Also, the case when somehow .gcda files are wiped out
in a make clean etc.

It is worth informing the user that profile generation is due. Proposal to add
a warning per file along the lines of -

"warning : profile count data file not found, regenerating profiles may help
[-Wmissing-profile]"

To contrast, -Wcoverage-mismatch covers the cases when profiles are STALE.
-Wmissing-profile is intended to cover the cases when there is NO profile.

I propose to keep the behaviour of -Wmissing-profile to be consistent with
-Wcoverage-mismatch in that :
1. Both should be on by default and treated as errors by default in
-fprofile-use FDO build
2. A user must use -Wno-error to just see them as warnings (with
-fprofile-use).

[Bug fortran/86116] [6/7/8/9 Regression] Ambiguous generic interface not recognised

[janus at gcc dot gnu.org]

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

--- Comment #4 from janus at gcc dot gnu.org ---
Author: janus
Date: Tue Aug 14 19:09:33 2018
New Revision: 263540

URL: https://gcc.gnu.org/viewcvs?rev=263540=gcc=rev
Log:
2018-08-14  Janus Weil  

PR fortran/86116
* interface.c (compare_type): Remove a CLASS/TYPE check.
(compare_type_characteristics): New function that behaves like the old
'compare_type'.
(gfc_check_dummy_characteristics, gfc_check_result_characteristics):
Call 'compare_type_characteristics' instead of 'compare_type'.

2018-08-14  Janus Weil  

PR fortran/86116
* gfortran.dg/generic_34.f90: New test case.

Added:
trunk/gcc/testsuite/gfortran.dg/generic_34.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/interface.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/86956] New: Use of an alias template unexpectedly breaks compilation

[v.reshetnikov at gmail dot com]

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

Bug ID: 86956
   Summary: Use of an alias template unexpectedly breaks
compilation
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: v.reshetnikov at gmail dot com
  Target Milestone: ---

/** BEGIN SOURCE **/
template
struct Outer {
template
struct Inner;

template
using Alias = Inner;
};

template<>
template
struct Outer::Inner { 
static constexpr bool value = v;
};

static_assert(Outer::Inner::value); // OK
static_assert(Outer::Alias::value); // error
/*** END SOURCE ***/

The first static_assert compiles OK, but the second results in unexpected
errors:

/** BEGIN OUTPUT **/
: In instantiation of 'struct Outer::Inner':
:17:39:   required from here
:12:27: error: type/value mismatch at argument 1 in template parameter
list for 'template > struct Outer::Inner< >'
12 | struct Outer::Inner {
   |   ^
:12:27: note:   expected a constant of type 'bool', got 'void'
:12:27: error: type/value mismatch at argument 1 in template parameter
list for 'Outer::Inner< >::Inner'
:12:27: note:   expected a constant of type 'bool', got 'void'
:13:27: error: type/value mismatch at argument 1 in template parameter
list for 'template > struct Outer::Inner< >'
13 | static constexpr bool value = v;
   |   ^
:13:27: note:   expected a constant of type 'bool', got 'void'
:13:27: error: type/value mismatch at argument 1 in template parameter
list for 'value'
:13:27: note:   expected a constant of type 'bool', got 'void'
:17:41: error: 'value' is not a member of 'Outer::Alias'
{aka 'Outer::Inner'}
17 | static_assert(Outer::Alias::value); // error
   | ^
Compiler returned: 1
/*** END OUTPUT ***/

The part "expected a constant of type 'bool', got 'void'" looks inexplicable;
"Inner< >" is also difficult to decipher. The issue is discovered
with build 9.0.0 20180813 (experimental), but appears to exist in earlier
versions as well.

For comparison, Clang compiles this code successfully.

[Bug tree-optimization/86914] [8/9 Regression] -O2 generates wrong code with strlen() of pointers within one-element arrays of structures

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #4 from Martin Sebor  ---
Patch: https://gcc.gnu.org/ml/gcc-patches/2018-08/msg00823.html

[Bug c++/78244] Narrowing conversion is accepted in a function template, but it should be rejected

[mpolacek at gcc dot gnu.org]

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

--- Comment #3 from Marek Polacek  ---
Enhanced testcase (so that I don't lose it):

template 
auto f1(T) -> decltype(int{2.0}, void()) { }

template 
auto f2(T) -> decltype(int{2.0}) { return 1; }

template 
auto f3(T) -> decltype(void(), int{2.0}) { return 1; }

int
main ()
{
  f1 (0);
  f2 (0);
  f3 (0);
}

[Bug c++/86953] [6/7/8/9 Regression] compiler crashes with constexpr operator== and specific struct (cxx_eval_bit_field_ref, at cp/constexpr.c:2704)

[mpolacek at gcc dot gnu.org]

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

--- Comment #4 from Marek Polacek  ---
Started with r230365 -- Merge C++ delayed folding branch..

[Bug c++/86953] [6/7/8/9 Regression] compiler crashes with constexpr operator== and specific struct (cxx_eval_bit_field_ref, at cp/constexpr.c:2704)

[mpolacek at gcc dot gnu.org]

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

--- Comment #3 from Marek Polacek  ---
struct B {
  double x;
  bool isfreex;
  bool isfreey;

  constexpr bool operator==(const B& other) const noexcept
  {
return (x == other.x) && (isfreex == other.isfreex) && (isfreey ==
other.isfreey);
  }

  constexpr bool operator!=(const B& other) const noexcept { return !(*this ==
other); }
};

int
main ()
{
  bool b = B{} == B{};
}

[Bug target/86731] [8/9 Regression] Miscompiles vec_sl at -O3 with -fwrapv on ppc64el

[willschm at gcc dot gnu.org]

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

Will Schmidt  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-08-14
   Assignee|unassigned at gcc dot gnu.org  |willschm at gcc dot 
gnu.org
 Ever confirmed|0   |1

[Bug tree-optimization/86955] strlen of a known string in member array plus offset not folded

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Blocks||83819

--- Comment #1 from Martin Sebor  ---
The reason is that the strlen pass sees the following:

  _1 = _4(D)->a;
  __builtin_memcpy (_1, "123", 4);
  _2 = [(void *)p_4(D) + 2B];
  _3 = __builtin_strlen (_2);

and it doesn't understand that [(void *)p_4(D) + 2B] actually refers to
p_4(D)->a.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83819
[Bug 83819] [meta-bug] missing strlen optimizations

[Bug tree-optimization/86955] New: strlen of a known string in member array plus offset not folded

[msebor at gcc dot gnu.org]

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

Bug ID: 86955
   Summary: strlen of a known string in member array plus offset
not folded
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

GCC is able to fold three out of the four strlen calls in the test case below,
even though folding all four should be possible.

$ cat f.c && gcc -O2 -S -Wall -Wextra -fdump-tree-optimized=/dev/stdout f.c
char a[8];

struct A { char i, a[8]; };

void f0 (void)
{
  __builtin_strcpy (a, "123");

  if (__builtin_strlen (a) != 3)   // folded
__builtin_abort ();
}

void f1 (void)
{
  __builtin_strcpy (a, "123");

  if (__builtin_strlen (a + 1) != 2)   // folded
__builtin_abort ();
}

void f2 (struct A* p)
{
  __builtin_strcpy (p->a, "123");

  if (__builtin_strlen (p->a) != 3)   // folded
__builtin_abort ();
}

void f3 (struct A* p)
{
  __builtin_strcpy (p->a, "123");

  if (__builtin_strlen (p->a + 1) != 2)   // not folded
__builtin_abort ();
}


;; Function f0 (f0, funcdef_no=0, decl_uid=1910, cgraph_uid=1, symbol_order=1)

f0 ()
{
   [local count: 1073741825]:
  __builtin_memcpy (, "123", 4); [tail call]
  return;

}



;; Function f1 (f1, funcdef_no=1, decl_uid=1913, cgraph_uid=2, symbol_order=2)

f1 ()
{
   [local count: 1073741825]:
  __builtin_memcpy (, "123", 4); [tail call]
  return;

}



;; Function f2 (f2, funcdef_no=2, decl_uid=1916, cgraph_uid=3, symbol_order=3)

f2 (struct A * p)
{
  char[8] * _1;

   [local count: 1073741825]:
  _1 = _3(D)->a;
  __builtin_memcpy (_1, "123", 4); [tail call]
  return;

}



;; Function f3 (f3, funcdef_no=3, decl_uid=1919, cgraph_uid=4, symbol_order=4)

f3 (struct A * p)
{
  char[8] * _1;
  const char * _2;
  long unsigned int _3;

   [local count: 1073741825]:
  _1 = _4(D)->a;
  __builtin_memcpy (_1, "123", 4);
  _2 = [(void *)p_4(D) + 2B];
  _3 = __builtin_strlen (_2);
  if (_3 != 2)
goto ; [0.00%]
  else
goto ; [99.96%]

   [count: 0]:
  __builtin_abort ();

   [local count: 1073312327]:
  return;

}

[Bug hsa/86948] Internal compiler error compiling brig.dg/test/gimple/mulhi.hsail

[amonakov at gcc dot gnu.org]

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

--- Comment #4 from Alexander Monakov  ---
Created attachment 44541
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44541=edit
generic expansion for mult-highpart

This patch implements fallback via widening multiply; works for the gimple
testcase.

If this is accepted, BRIG FE should be able to drop workarounds and always use
MULT_HIGHPART_EXPR when it needs to; if not, BRIG FE should be changed to
assume that MULT_HIGHPART_EXPR is never available.

[Bug libstdc++/86590] Codegen is poor when passing std::string by value with _GLIBCXX_EXTERN_TEMPLATE undefined

[redi at gcc dot gnu.org]

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

--- Comment #29 from Jonathan Wakely  ---
The seemingly-redundant 'else' keywords in the patch are needed because of PR
86678.

[Bug libstdc++/86590] Codegen is poor when passing std::string by value with _GLIBCXX_EXTERN_TEMPLATE undefined

[redi at gcc dot gnu.org]

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

--- Comment #28 from Jonathan Wakely  ---
Created attachment 44540
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44540=edit
Use __builtin_is_constant_evaluated()

I tried to replace the __builtin_constant_p and __constant_string conditions
with Jakub's new __builtin_is_constant_evaluated (see patch) but it made no
difference.

[Bug libstdc++/86954] New: redundant nothrow in call of ::operator delete

[frankhb1989 at gmail dot com]

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

Bug ID: 86954
   Summary: redundant nothrow in call of ::operator delete
   Product: gcc
   Version: 8.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: frankhb1989 at gmail dot com
  Target Milestone: ---

In the current implementation std::return_temporary_buffer, ::operator delete
is called with std::nothrow as 2nd argument. (It seems here is the only
occurrence of such ::operator delete call in libstdc++). This seems
unintentional. Normally the std::nothrow argument should not exist here.

This should make no difference to intentional behavior when the allocation and
deallocation functions are not replaced due to the default behavior. However,
since the nothrow_t overloads are called by implementation on exceptions during
the call of operator new, and the overloads can be replaceable as per
[new.delete.single], this may lead to surprise result with reasonable use, e.g.
when user expect to have different log messages in different replaced overloads
of ::operator delete.

[Bug c++/86953] [6/7/8/9 Regression] compiler crashes with constexpr operator== and specific struct (cxx_eval_bit_field_ref, at cp/constexpr.c:2704)

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-08-14
 CC||mpolacek at gcc dot gnu.org
Summary|compiler crashes with   |[6/7/8/9 Regression]
   |constexpr operator== and|compiler crashes with
   |specific struct |constexpr operator== and
   |(cxx_eval_bit_field_ref, at |specific struct
   |cp/constexpr.c:2704)|(cxx_eval_bit_field_ref, at
   ||cp/constexpr.c:2704)
 Ever confirmed|0   |1

--- Comment #2 from Marek Polacek  ---
Confirmed.  G++ 5 compiles it fine.

[Bug c++/86953] compiler crashes with constexpr operator== and specific struct (cxx_eval_bit_field_ref, at cp/constexpr.c:2704)

[remi.ducceschi at gmail dot com]

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

--- Comment #1 from Rémi DUCCESCHI  ---
Created attachment 44539
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44539=edit
Small test case

[Bug c++/86953] New: compiler crashes with constexpr operator== and specific struct (cxx_eval_bit_field_ref, at cp/constexpr.c:2704)

[remi.ducceschi at gmail dot com]

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

Bug ID: 86953
   Summary: compiler crashes with constexpr operator== and
specific struct (cxx_eval_bit_field_ref, at
cp/constexpr.c:2704)
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: remi.ducceschi at gmail dot com
  Target Milestone: ---

Created attachment 44538
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44538=edit
preprocessed file of a small test case for the constexpr crash

Hello,

I've created a small test case that produces a compiler crash. You can find
attached the preprocessed file (main.ii) made by running the following command,
with `G++ 7.3.1 20180303 (Red Hat 7.3.1-5)` on a CentOS 7 (with the
devtoolset-7 installed), but it seems to exist on the last version too (see
https://wandbox.org/permlink/zGZWdHIrRNJKfh5Z):

g++ -O3 -Wall -Wextra -o main -save-temps -v main.cpp

I give at the end of the mail the output of the command.

You can find a run on the last G++ version (9) here:
https://wandbox.org/permlink/zGZWdHIrRNJKfh5Z 

---
Here is the code:

#include 
struct Bugged {
double x; bool isfreex; bool isfreey;
constexpr bool operator==(const Bugged& other) const noexcept {
return (x == other.x) && (isfreex == other.isfreex) && (isfreey ==
other.isfreey);
}
};
int main () {
std::cout << std::boolalpha << (Bugged{} == Bugged{}) << std::endl;
return 0;
}
---

The bug only appears if I enable optimization (-02 or -O3), I guess constexpr
optimization is not done otherwise.

The problem occurs on the operator==(). The compiler crashes because it can't
compute the result of the constexpr. Note that if I change the struct so it
doesn't hold booleans, but double instead, or if I remove any of the
parentheses term in the operator== function, it doesn't crash.

Note that this code compiles on MSVC 2017 and on clang 6 (though it doesn't
mean anything).

I search for a similar bug report but didn't find anything, sorry if this is a
duplicate.

---
Below the output of the command:

Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/opt/rh/devtoolset-7/root/usr/libexec/gcc/x86_64-redhat-linux/7/lto-wrapper
Target: x86_64-redhat-linux
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
Thread model: posix
gcc version 7.3.1 20180303 (Red Hat 7.3.1-5) (GCC) 
COLLECT_GCC_OPTIONS='-O3' '-Wall' '-Wextra' '-o' 'main' '-save-temps' '-v'
'-shared-libgcc' '-mtune=generic' '-march=x86-64'
 /opt/rh/devtoolset-7/root/usr/libexec/gcc/x86_64-redhat-linux/7/cc1plus -E
-quiet -v -D_GNU_SOURCE main.cpp -mtune=generic -march=x86-64 -Wall -Wextra -O3
-fpch-preprocess -o main.ii
ignoring nonexistent directory
"/opt/rh/devtoolset-7/root/usr/lib/gcc/x86_64-redhat-linux/7/include-fixed"
ignoring nonexistent directory
"/opt/rh/devtoolset-7/root/usr/lib/gcc/x86_64-redhat-linux/7/../../../../x86_64-redhat-linux/include"
#include "..." search starts here:
#include <...> search starts here:

/opt/rh/devtoolset-7/root/usr/lib/gcc/x86_64-redhat-linux/7/../../../../include/c++/7

/opt/rh/devtoolset-7/root/usr/lib/gcc/x86_64-redhat-linux/7/../../../../include/c++/7/x86_64-redhat-linux

/opt/rh/devtoolset-7/root/usr/lib/gcc/x86_64-redhat-linux/7/../../../../include/c++/7/backward
 /opt/rh/devtoolset-7/root/usr/lib/gcc/x86_64-redhat-linux/7/include
 /usr/local/include
 /opt/rh/devtoolset-7/root/usr/include
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-O3' '-Wall' '-Wextra' '-o' 'main' '-save-temps' '-v'
'-shared-libgcc' '-mtune=generic' '-march=x86-64'
 /opt/rh/devtoolset-7/root/usr/libexec/gcc/x86_64-redhat-linux/7/cc1plus
-fpreprocessed main.ii -quiet -dumpbase main.cpp -mtune=generic -march=x86-64
-auxbase main -O3 -Wall -Wextra -version -o main.s
GNU C++14 (GCC) version 7.3.1 20180303 (Red Hat 7.3.1-5) (x86_64-redhat-linux)
compiled by GNU C version 7.3.1 20180303 (Red Hat 7.3.1-5), GMP version
6.0.0, MPFR version 3.1.1, MPC version 1.0.1, isl version isl-0.16.1-GMP

[Bug c++/86678] constexpr evaluation incorrectly diagnoses unevaluated call to non-constexpr function

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Last reconfirmed|2018-07-26 00:00:00 |2018-8-14

--- Comment #4 from Jonathan Wakely  ---
constexpr bool always_true() { return true; }
int f() { return 1; }
constexpr int g() {
  if (always_true())
return 0;
  return f();
}

ce.cc: In function 'constexpr int g()':
ce.cc:6:11: error: call to non-'constexpr' function 'int f()'
6 |   return f();
  |  ~^~

This makes it awkward to use the new __builtin_is_constant_evaluated().

[Bug target/84908] retpoline weirdness: 7.3.0-1 and 4.8.5-16: with -fPIC: R_X86_64_PC32 against undefined symbol `__x86_indirect_thunk_rax'

[jason.vas.dias at gmail dot com]

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

--- Comment #11 from Jason Vas Dias  ---
In reply to Comment #9 :
Thanks Andy -

I think it is because when the retpoline flags are enabled ,
the 'static inline' function calls in vclock_gettime.c
have default function attributes which differ from those that 
__vdso_clock_gettime
( the function containing the switch ) gets, 
so GCC finds it must instantiate a
callable version of the normally static inline function calls 
this function makes, and
generates relocations for them which are not getting
copied into the VDSO for some reason.
Rather than making more radical changes to the VDSO assembly
code to handle these types of relocations, I think it is better
to avoid them being generated by either:
 A) compiling vclock_gettime.c without 
'-mindirect-branch=thunk-extern -mindirect-branch-register -DRETPOLINE'
(rejected by Andi Kleen)
 B) Specifying ALL entry points that __vdso_clock_gettime calls
to have attributes that do not require relocation for GCC
to handle if the above flags are in effect:



#ifdef RETPOLINE
+#  define  _NO_THUNK_RELOCS_()(indirect_branch("keep"),\
+   function_return("keep"))
+#  define  _RETPOLINE_FUNC_ATTR_   __attribute__(_NO_THUNK_RELOCS_())
+#  define  _RETPOLINE_INLINE_  inline
+#else
+#  define  _RETPOLINE_FUNC_ATTR_
+#  define  _RETPOLINE_INLINE_  __always_inline
+#endif

So then one declares any function called by __vdso_clock_gettime() like:

   notrace static _RETPOLINE_FUNC_ATTR_ _RETPOLINE_INLINE_
   int do_monotonic_raw( int clock, struct timespec *ts ) { ... }

and then must declare 

   notrace int _RETPOLINE_FUNC_ATTR_ 
   __vdso_clock_gettime(clockid_t clock, struct timespec *ts)
   {... do_monotonic_raw(ts); ...}

to avoid the relocations being generated. 
I did submit a patch to vclock_gettime.c
to do this - should I re-submit it?

Or one could fix the code which produces the resulting vdso
to include the generated (unecessary and redundant) relocations,
or generate the relocation functions in assembler somehow, but
I don't think this is the way the VDSO should go. There is no
reason to make functions in the VDSO have function attributes
 indirect_branch("thunk-extern,register") - they always WILL
generate relocations if more that 5 such calls are made in same
switch,  with all current versions of GCC, it seems. 
Every function that directly invokes these functions (in glibc),
must also have these function attributes, which are entirely
unnecessary and inefficient compared to the indirect_branch("keep")
style; and those relocations then must be in the VDSO for callers
to invoke.

[Bug target/84908] retpoline weirdness: 7.3.0-1 and 4.8.5-16: with -fPIC: R_X86_64_PC32 against undefined symbol `__x86_indirect_thunk_rax'

[hjl.tools at gmail dot com]

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

--- Comment #10 from H.J. Lu  ---
(In reply to Andy Lutomirski from comment #9)
> I haven't fully dug into this, but I do one one immediate question: why is
> GCC generating a jump table for a five-entry switch statement if retpolines
> are on?  This has got to be a *huge* performance loss.  The retpoline
> sequence is very, very slow, and branches aren't that slow.  A five-entry
> switch is only three branches deep.

I opened:

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

[Bug target/86952] New: Avoid jump table for switch statement with -mindirect-branch=thunk

[hjl.tools at gmail dot com]

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

Bug ID: 86952
   Summary: Avoid jump table for switch statement with
-mindirect-branch=thunk
   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: wei3.xiao at intel dot com
Blocks: 84072
  Target Milestone: ---
Target: i386,x86-64

Why is GCC generating a jump table for a five-entry switch statement if
retpolines are on?  This has got to be a *huge* performance loss.  The
retpoline sequence is very, very slow, and branches aren't that slow.
A five-entry switch is only three branches deep.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84072
[Bug 84072] [meta-bug] -mindirect-branch=thunk issues

[Bug tree-optimization/86724] Compilation error with new isl 0.20 (missing includes)

[doko at gcc dot gnu.org]

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

--- Comment #8 from Matthias Klose  ---
Author: doko
Date: Tue Aug 14 15:15:39 2018
New Revision: 263539

URL: https://gcc.gnu.org/viewcvs?rev=263539=gcc=rev
Log:
2018-08-14  Matthias Klose  

Backport from mainline
2018-08-01  Richard Biener  

PR bootstrap/86724
* graphite.h: Include isl/id.h and isl/space.h to allow build
with ISL 0.20.

Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/graphite.h

[Bug hsa/86948] Internal compiler error compiling brig.dg/test/gimple/mulhi.hsail

[amonakov at gcc dot gnu.org]

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

--- Comment #3 from Alexander Monakov  ---
Created attachment 44537
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44537=edit
expose mult-highpart via GIMPLE FE

Attaching a patch that allows creating MULT_HIGHPART_EXPR via GIMPLE FE, which
allows testing with

__GIMPLE
unsigned f(unsigned x, unsigned y)
{
  unsigned r;
  r = x h* y;
  return r;
}

(though the patch is not too sophisticated, it accepts "h*")

[Bug libstdc++/86590] Codegen is poor when passing std::string by value with _GLIBCXX_EXTERN_TEMPLATE undefined

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|--- |9.0

[Bug target/86951] arm speculation barrier incompatible with ARMv6 or earlier

[rearnsha at gcc dot gnu.org]

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

Richard Earnshaw  changed:

   What|Removed |Added

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

[Bug target/86951] New: arm speculation barrier incompatible with ARMv6 or earlier

[rearnsha at gcc dot gnu.org]

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

Bug ID: 86951
   Summary: arm speculation barrier incompatible with ARMv6 or
earlier
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: assemble-failure
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rearnsha at gcc dot gnu.org
Blocks: 86772
  Target Milestone: ---
Target: arm

The speculation_barrier_insn pattern uses DSB and ISB, but these instructions
were only added in ARMv7.  Another approach is needed for older versions of the
architecture.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86772
[Bug 86772] [meta-bug] tracking port status for CVE-2017-5753

[Bug target/84908] retpoline weirdness: 7.3.0-1 and 4.8.5-16: with -fPIC: R_X86_64_PC32 against undefined symbol `__x86_indirect_thunk_rax'

[luto at kernel dot org]

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

Andy Lutomirski  changed:

   What|Removed |Added

 CC||luto at kernel dot org

--- Comment #9 from Andy Lutomirski  ---
I haven't fully dug into this, but I do one one immediate question: why is GCC
generating a jump table for a five-entry switch statement if retpolines are on?
 This has got to be a *huge* performance loss.  The retpoline sequence is very,
very slow, and branches aren't that slow.  A five-entry switch is only three
branches deep.

[Bug target/86599] Problems building libgfortran from 7.2.0 on HP-UX 11.31/PA

[bugzilla-gcc at thewrittenword dot com]

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

--- Comment #20 from The Written Word  
---
Created attachment 44536
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44536=edit
stdlib.h long_double patch for HP-UX 11.31/PA

Tested against 7.3.0 and 8.2.0.

[Bug libstdc++/79433] __has_include() is true but #include gives #error when -std=old

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #28 from Jonathan Wakely  ---
This is fixed for gcc 7.3 and I don't plan to backport it to gcc-6-branch.

[Bug libstdc++/79323] FAIL: 20_util/duration/literals/range.cc (test for excess errors)

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #3 from Jonathan Wakely  ---
.

[Bug c++/86623] constexpr evaluation fails to give an error for modifying a const object

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

[Bug c++/86950] internal compiler error: unexpected expression ‘void()’ of kind cast_expr

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |INVALID

--- Comment #2 from Marek Polacek  ---
Closing because I am an idiot.

[Bug hsa/86948] Internal compiler error compiling brig.dg/test/gimple/mulhi.hsail

[amonakov at gcc dot gnu.org]

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

--- Comment #2 from Alexander Monakov  ---
Thanks for the heads-up. At present, BRIG frontend cannot rely on
MULT_HIGHPART, as the pattern is optional and, as this bug shows, generic
expansion is not implemented. BRIG frontend is already somewhat aware of the
issue, as the comment in brig-basic-inst-handler.cc indicates:

554   /* MULT_HIGHPART_EXPR works only on target dependent vector sizes and
555  even the scalars do not seem to work at least for char elements.
556
557  Let's fall back to scalarization and promotion [...]

So a quick-fix would be to never try to use MULT_HIGHPART_EXPR from BRIG FE.

However, I think it would be nice to extend expand_mult_highpart to handle
this, at least to avoid regressing here. I'll look into that. I'll also try to
expose MULT_HIGHPART_EXPR via the GIMPLE FE so it can be tested in a more
straightforward manner.

[Bug c++/86950] internal compiler error: unexpected expression ‘void()’ of kind cast_expr

[mpolacek at gcc dot gnu.org]

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

--- Comment #1 from Marek Polacek  ---
Fixed testcase:

template 
auto f(T) -> decltype(void(), 1) { return 1; }

int
main ()
{
  f(0);
}

[Bug c++/86950] internal compiler error: unexpected expression ‘void()’ of kind cast_expr

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-08-14
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org
 Ever confirmed|0   |1

[Bug c++/86950] New: internal compiler error: unexpected expression ‘void()’ of kind cast_expr

[mpolacek at gcc dot gnu.org]

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

Bug ID: 86950
   Summary: internal compiler error: unexpected expression
‘void()’ of kind cast_expr
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
  Target Milestone: ---

template 
auto f(T) -> decltype(void(), 1) { }

int
main ()
{
  f(0);
}

0x8d1e01 cxx_eval_constant_expression
/home/mpolacek/src/gcc/gcc/cp/constexpr.c:4861
0x8cf490 cxx_eval_constant_expression
/home/mpolacek/src/gcc/gcc/cp/constexpr.c:4485
0x8d451e cxx_eval_outermost_constant_expr
/home/mpolacek/src/gcc/gcc/cp/constexpr.c:4970
0x8d7368 maybe_constant_value(tree_node*, tree_node*)
/home/mpolacek/src/gcc/gcc/cp/constexpr.c:5197
0xa6b7b9 check_narrowing(tree_node*, tree_node*, int, bool)
/home/mpolacek/src/gcc/gcc/cp/typeck2.c:909
0xa2b0c2 finish_decltype_type(tree_node*, bool, int)
/home/mpolacek/src/gcc/gcc/cp/semantics.c:8917
0x9ab936 cp_parser_decltype
/home/mpolacek/src/gcc/gcc/cp/parser.c:14296
0x9adcdf cp_parser_simple_type_specifier
/home/mpolacek/src/gcc/gcc/cp/parser.c:17197
0x9a7d95 cp_parser_type_specifier
/home/mpolacek/src/gcc/gcc/cp/parser.c:16982
0x9a8b62 cp_parser_type_specifier_seq
/home/mpolacek/src/gcc/gcc/cp/parser.c:21253
0x9a8d81 cp_parser_type_id_1
/home/mpolacek/src/gcc/gcc/cp/parser.c:21099
0x9a4977 cp_parser_trailing_type_id
/home/mpolacek/src/gcc/gcc/cp/parser.c:21192
0x9a4977 cp_parser_late_return_type_opt
/home/mpolacek/src/gcc/gcc/cp/parser.c:21017
0x9a4977 cp_parser_direct_declarator
/home/mpolacek/src/gcc/gcc/cp/parser.c:20189
0x9a4977 cp_parser_declarator
/home/mpolacek/src/gcc/gcc/cp/parser.c:20019
0x9b2891 cp_parser_init_declarator
/home/mpolacek/src/gcc/gcc/cp/parser.c:19535
0x9b960a cp_parser_single_declaration
/home/mpolacek/src/gcc/gcc/cp/parser.c:27432
0x9b974c cp_parser_template_declaration_after_parameters
/home/mpolacek/src/gcc/gcc/cp/parser.c:27034
0x9b9fee cp_parser_explicit_template_declaration
/home/mpolacek/src/gcc/gcc/cp/parser.c:27271
0x9b9fee cp_parser_template_declaration_after_export
/home/mpolacek/src/gcc/gcc/cp/parser.c:27290
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug libstdc++/86846] [9 Regression] ld: (Warning) Unsatisfied symbol "__atomic_exchange_8" in libstdc++.sl

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #11 from Jonathan Wakely  ---
Should be fixed now.

[Bug libstdc++/86846] [9 Regression] ld: (Warning) Unsatisfied symbol "__atomic_exchange_8" in libstdc++.sl

[redi at gcc dot gnu.org]

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

--- Comment #10 from Jonathan Wakely  ---
Author: redi
Date: Tue Aug 14 13:13:37 2018
New Revision: 263536

URL: https://gcc.gnu.org/viewcvs?rev=263536=gcc=rev
Log:
PR libstdc++/86846 Alternative to pointer-width atomics

Define a class using std::mutex for when std::atomic
cannot be used to implement the default memory resource.

When std::mutex constructor is not constexpr the constant_init trick
won't work, so just define a global and use init_priority for it. The
compiler warns about using reserved priority, so put the definition in a
header file using #pragma GCC system_header to suppress the warning.

PR libstdc++/86846
* src/c++17/default_resource.h: New file, defining default_res.
* src/c++17/memory_resource.cc [ATOMIC_POINTER_LOCK_FREE != 2]
(atomic_mem_res): Define alternative for atomic
using a mutex instead of atomics.

Added:
trunk/libstdc++-v3/src/c++17/default_resource.h
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/src/c++17/memory_resource.cc

[Bug c++/86946] ice: canonical types differ for identical types

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #1 from Marek Polacek  ---
Confirmed.  Must be very old.

[Bug hsa/86948] Internal compiler error compiling brig.dg/test/gimple/mulhi.hsail

[jamborm at gcc dot gnu.org]

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

Martin Jambor  changed:

   What|Removed |Added

 CC||amonakov at gcc dot gnu.org

--- Comment #1 from Martin Jambor  ---
The first bad revision is r263467:

38bbb539599302461fa06df5ea847e2ddd337409 is the first bad commit
commit 38bbb539599302461fa06df5ea847e2ddd337409
Author: amonakov 
Date:   Fri Aug 10 10:13:37 2018 +

i386: do not use SImode mul-highpart on 64-bit (PR 82418)

PR target/82418
* config/i386/i386.md (mul3_highpart): Use DWIH mode
iterator
instead of SWI48.

testsuite/
* gcc.target/i386/pr82418.c: New test.

[Bug libstdc++/85343] Overload __throw_ios_failure to allow passing errno

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #3 from Jonathan Wakely  ---
Fixed on trunk.

[Bug libstdc++/85343] Overload __throw_ios_failure to allow passing errno

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
Author: redi
Date: Tue Aug 14 12:09:57 2018
New Revision: 263535

URL: https://gcc.gnu.org/viewcvs?rev=263535=gcc=rev
Log:
PR libstdc++/85343 overload __throw_ios_failure to take errno

[ios::failure] p2: "When throwing ios_base::failure exceptions,
implementations should provide values of ec that identify the specific
reason for the failure."

This adds a new overload of __throw_ios_failure that can be passed
errno, to store error_code(errno, system_category()) in the exception
object.

PR libstdc++/85343
* acinclude.m4 (libtool_VERSION): Bump version.
* config/abi/pre/gnu.ver (GLIBCXX_3.4.26): Add new symbol version.
Export new symbol.
* configure: Regenerate.
* doc/xml/manual/abi.xml: Document new versions.
* include/bits/fstream.tcc (basic_filebuf::underflow)
(basic_filebuf::xsgetn): Pass errno to __throw_ios_failure.
* include/bits/functexcept.h (__throw_ios_failure(const char*, int)):
Declare new overload.
* src/c++11/cxx11-ios_failure.cc (__ios_failure): Add new constructor
and static member function.
(__throw_ios_failure(const char*, int)): Define.
* src/c++98/ios_failure.cc [!_GLIBCXX_USE_DUAL_ABI]
(__throw_ios_failure(const char*, int)): Define.
* testsuite/util/testsuite_abi.cc: Update known and latest versions.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/config/abi/pre/gnu.ver
trunk/libstdc++-v3/doc/xml/manual/abi.xml
trunk/libstdc++-v3/include/bits/fstream.tcc
trunk/libstdc++-v3/include/bits/functexcept.h
trunk/libstdc++-v3/src/c++11/cxx11-ios_failure.cc
trunk/libstdc++-v3/src/c++98/ios_failure.cc

[Bug c++/86949] gcc generate an error because delete operator is private when it isn't needed

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||rejects-valid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-08-14
 Ever confirmed|0   |1

[Bug c++/86949] New: gcc generate an error because delete operator is private when it isn't needed

[tyker at outlook dot com]

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

Bug ID: 86949
   Summary: gcc generate an error because delete operator is
private when it isn't needed
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tyker at outlook dot com
  Target Milestone: ---

in this code:

#include 

struct X {
X() noexcept { }
private:
static void operator delete(void*);
};

int main() { 
X* x = new(std::nothrow) X{}; 
}

the delete operator is private but it isn't needed because the contructor and
the allocator can't throw. but gcc generate an error complaining that the
delete operator is private.

all other majors complier complie this code without errors except gcc:
https://godbolt.org/#z:OYLghAFBqd5QCxAYwPYBMCmBRdBLAF1QCcAaPECAKxAEZSAbAQwDtRkBSAJgCFufSAZ1QBXYskwgA5NwDMeFsgYisAag6yAwi0wB3Ddg4AGAILGTggsRHICqgBrqA7H1Or3DiAEpVLVJgAPCQAHOw4XZwARcw9VYOI8ADcmAkkYj0sUvGRVRNQ8dFVUYMxiFJJVLAZMVIg8goAqLw1XMydo2VbzBTsAWyYFb2cedTcPewbVAPVZSN89CEt0EBA/AgRiVF0fe3C%2BdpbRtsipL0ZpAFYpUhZpI2vUaU1%2BflVhMQl1Lllaa4I705nADWIFkXAAdAA2IwXGGyIwADgRABYuABOIzI85SZHXW5Se6kR5Sa6CEBGUj/AmnUhwWAwRAoVC9YJ4apkCgQNAstmlEDABFcUgAMzZqWIZIgACMAaQpQomMQAJ7SX6kbm9TAsAgAeRYDBV1NIWH6bGqsvwxEwtiSmDJRsC1pEqVV1x6mAYsqseF6rrOzDYKBevEYeClZMgZ2KBDwqBY9tJonEklo/sueNlxICCMhAFpIcjVMBkDkEeCuKoILhCBU5PRVJpmaz2V8fj5nrx%2BH8AV5gSAuLRwcjUZDZE40VxkU5ZBdaLRZNjcaRfci0eCnJCMRcfrQnE5BWj6PjCcTSeTKT3aQyIEhuc3SuRKHfecQUAxaGiAPoFkVi0qSmUjXlFhFUNNUNS1XV9UNQkTVYYBzSNS1rRjRI7VlR1kGdSQpDVd1PSNb1fVwmkA3YYMBAYMMI28IlQljeNpETD4UzTKQrhuTNpGzPMC1UABZABlAA1TRVA/VQuCMXdVAAJQAFQAdUrasiGIVt60bHkWzkLh2wo7tqV7UgEEwJgsFfWiCKXX1YXLeE0WRSEkS4AcnCPLiSSEc8qXuYyQVkWR12%2BSELgLWgkWRGcnAubFZAzI1TwvIyr3gOlGWfdlHy5JsXxAbJkAi38GHFADZWA0DXXVZlNW1PUDQtTBTQQnDYLwK0bTQ%2B1CUw7Cqvwr0EmI35/XgoNOxDKjw3gKN6LjBMhCTCQ6DYjjjwebic3zQsCvEssjHBIwVPwNSNNIBtcp075ZH0iaeEMvy%2B0C9c0QuWdBSMJwuAPehrOuFc10ii4uFCi4kUPJzOMSpjvIpXyaXSm8mW0h9OUyvklHg6EKVFEr/0oQDCQq5UqoguroMa5rELajrUPQh0AidF0SPIbUPUGn0/UYMbODu0NpsjOiY3mmH3mTFbsTWzyeO21RMbYVRIUOw7jprdS63OrT73V75kVuvheAewETLMizKDYmyQDsucLinWRhznRFtyxdaiVFnyeyeoLIXc9FMQnL7p0hSE4oSk8Yfh4yCK4MONq8yOzjQiUGJAZEgA%3D%3D

note that in this code:

#include 

struct X {
X() noexcept { }
static void operator delete(void*) = delete;
};

int main() { 
X* x = new(std::nothrow) X{}; 
}

where the operator delete isn't needed and explicitly deleted gcc compiles
correctly.

[Bug libstdc++/86846] [9 Regression] ld: (Warning) Unsatisfied symbol "__atomic_exchange_8" in libstdc++.sl

[redi at gcc dot gnu.org]

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

--- Comment #9 from Jonathan Wakely  ---
OK, thanks. The second patch might not be needed for hppa64-hp-hpux11.11 but
would be for targets without pointer-width atomics and without
PTHREAD_MUTEX_INITIALIZER, so I'll commit that version.

[Bug libstdc++/86846] [9 Regression] ld: (Warning) Unsatisfied symbol "__atomic_exchange_8" in libstdc++.sl

[dave.anglin at bell dot net]

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

--- Comment #8 from dave.anglin at bell dot net ---
On 2018-08-11 8:04 PM, redi at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86846
>
> --- Comment #5 from Jonathan Wakely  ---
> This should do it:
The testsuite isn't quite finished but it's clear this fixes the bug on 
hppa64-hp-hpux11.11.
Don't know about second patch.
>
> --- a/libstdc++-v3/src/c++17/memory_resource.cc
> +++ b/libstdc++-v3/src/c++17/memory_resource.cc
> @@ -25,6 +25,7 @@
>   #include 
>   #include 
>   #include 
> +#include 
>
>   namespace std _GLIBCXX_VISIBILITY(default)
>   {
> @@ -81,7 +82,31 @@ namespace pmr
>
>   constant_init newdel_res{};
>   constant_init null_res{};
> +#if ATOMIC_POINTER_LOCK_FREE == 2
>   constant_init> default_res{_res.obj};
> +#else
> +struct locking_atomic
> +{
> +  constexpr locking_atomic(memory_resource* r) : val(r) { }
> +  mutex mx;
> +  memory_resource* val;
> +
> +  memory_resource* load()
> +  {
> +   lock_guard lock(mx);
> +   return val;
> +  }
> +
> +  memory_resource* exchange(memory_resource* r)
> +  {
> +   lock_guard lock(mx);
> +   auto prev = val;
> +   val = r;
> +   return prev;
> +  }
> +};
> +constant_init default_res{_res.obj};
> +#endif
> } // namespace
>
> memory_resource*
>

Thanks,
Dave

[Bug hsa/86948] New: Internal compiler error compiling brig.dg/test/gimple/mulhi.hsail

[jamborm at gcc dot gnu.org]

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

Bug ID: 86948
   Summary: Internal compiler error compiling
brig.dg/test/gimple/mulhi.hsail
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: hsa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jamborm at gcc dot gnu.org
CC: jamborm at gcc dot gnu.org, marxin at gcc dot gnu.org
  Target Milestone: ---

Created attachment 44535
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44535=edit
BRIG input

At some point in the last two weeks, brig.dg/test/gimple/mulhi.hsail started
failing with and ICE.  Command-line reproducer (with the attached input) is:

$ ~/gcc/small/inst/bin/gccbrig mulhi.hsail.brig -S
during RTL pass: expand
In function ‘_Kernel’:
brig1: internal compiler error: in expand_expr_real_2, at expr.c:8918
0x868d36 expand_expr_real_2(separate_ops*, rtx_def*, machine_mode,
expand_modifier)
/home/mjambor/gcc/small/src/gcc/expr.c:8918
0x702e6a expand_gimple_stmt_1
/home/mjambor/gcc/small/src/gcc/cfgexpand.c:3673
0x703131 expand_gimple_stmt
/home/mjambor/gcc/small/src/gcc/cfgexpand.c:3734
0x7059f3 expand_gimple_basic_block
/home/mjambor/gcc/small/src/gcc/cfgexpand.c:5770
0x708e57 execute
/home/mjambor/gcc/small/src/gcc/cfgexpand.c:6373
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug tree-optimization/86944] ICE in vectorizable_store, at tree-vect-stmts.c:6878 on aarch64

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 CC||ktkachov at gcc dot gnu.org
  Component|target  |tree-optimization
 Ever confirmed|0   |1

--- Comment #1 from ktkachov at gcc dot gnu.org ---
Confirmed on the branches from GCC 7 onwards.
Doesn't look like a target bug to me though. Looks like the vectoriser doesn't
deal with some alignment info properly (to my uneducated eye).

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

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

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

--- Comment #10 from rsandifo at gcc dot gnu.org  
---
Fixed on trunk and GCC 8 branch.  Thanks for the bug report.

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

[rsandifo at gcc dot gnu.org]

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

--- Comment #9 from rsandifo at gcc dot gnu.org  
---
Author: rsandifo
Date: Tue Aug 14 09:24:45 2018
New Revision: 263528

URL: https://gcc.gnu.org/viewcvs?rev=263528=gcc=rev
Log:
Fix invalid assumption in vect_transform_stmt (PR 86871)

The handling of outer-loop uses of inner-loop definitions assumed
that anything that wasn't a PHI would be a gassign.  It's also
possible for it to be a gcall.

2018-08-14  Richard Sandiford  

gcc/
Backport from mainline
2018-08-09  Richard Sandiford  

PR tree-optimization/86871
* tree-vect-stmts.c (vect_transform_stmt): Use gimple_get_lhs
instead of gimple_assign_lhs.

gcc/testsuite/
Backport from mainline
2018-08-09  Richard Sandiford  

PR tree-optimization/86871
* gcc.dg/vect/pr86871.c: New test.

Added:
branches/gcc-8-branch/gcc/testsuite/gcc.dg/vect/pr86871.c
Modified:
branches/gcc-8-branch/gcc/ChangeLog
branches/gcc-8-branch/gcc/testsuite/ChangeLog
branches/gcc-8-branch/gcc/tree-vect-stmts.c

[Bug libstdc++/70472] is_copy_constructible>>::value is true

[simonrbrand at gmail dot com]

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

Simon Brand  changed:

   What|Removed |Added

 CC||simonrbrand at gmail dot com

--- Comment #13 from Simon Brand  ---
Is there any decent workaround for this for pre-GCC8 users? My current approach
is to add specializations to my own trait whenever a user of my library needs
support for types with this issue. I can happily use intrinsics if some would
make this easier.

[Bug c++/86921] do not remove input in bash

[yamirenk at ya dot ru]

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

--- Comment #8 from Yakov  ---
(In reply to Andreas Schwab from comment #7)
> This has nothing to do with gcc, it is a property of the terminal emulation.

ok. all my terminals have this problem)=
thanks for help

[Bug c++/86921] do not remove input in bash

[sch...@linux-m68k.org]

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

Andreas Schwab  changed:

   What|Removed |Added

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

--- Comment #7 from Andreas Schwab  ---
This has nothing to do with gcc, it is a property of the terminal emulation.

[Bug c++/86921] do not remove input in bash

[yamirenk at ya dot ru]

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

--- Comment #6 from Yakov  ---
(In reply to Jonathan Wakely from comment #5)
> (In reply to Yakov from comment #4)
> > I am sorry. I think, I did mistake in my question. I did not press Enter.
> 
> You said "when the second line begins. symbols, entered in first line"
> 
> If that doesn't mean you pressed Enter, you need to tell us what you did. We
> can't guess.
> 
> See https://gcc.gnu.org/bugs/

ok. bash:
$./test
aa(here is the end of the first line)
aa(then I press Backspace many times)
I see:
$./test
aa(this symbols I can not remove)

[Bug c++/86942] A trailing-return-type is allowed when the return type is not 'auto' for using declarations

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||accepts-invalid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-08-14
 Ever confirmed|0   |1

[Bug c/86947] New: Erroneous code generated with O2 and O3 for PPC

[vinay.kumar at blackfigtech dot com]

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

Bug ID: 86947
   Summary: Erroneous code generated with O2 and O3 for PPC
   Product: gcc
   Version: 8.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vinay.kumar at blackfigtech dot com
  Target Milestone: ---

Created attachment 44534
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44534=edit
Testcase to reproduce the bug.

$powerpc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/data/home/toolchain/ppc/prefix/bin/powerpc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/data/home/toolchain/ppc/prefix/bin/../libexec/gcc/powerpc-linux-gnu/8.1.0/lto-wrapper
Target: powerpc-linux-gnu
Configured with: /data/home/toolchain/ppc/build/../src/gcc-8.1.0/configure
--target=powerpc-linux-gnu --prefix=/data/home/toolchain/ppc/build/../prefix
--disable-nls --enable-languages=c,c++ --enable-targets=all --disable-multilib
--disable-libsanitizer --enable-threads --enable-tls --enable-__cxa_atexit
--enable-secureplt --with-gmp=/data/home/toolchain/gmp-mpfr-mpc/prefix
--with-mpfr=/data/home/toolchain/gmp-mpfr-mpc/prefix
--with-mpc=/data/home/toolchain/gmp-mpfr-mpc/prefix
--prefix=/data/home/toolchain/ppc/build/../prefix
Thread model: posix
gcc version 8.1.0 (GCC)

The testcase was compiled using following command and options:-
$powerpc-linux-gnu-gcc -m64 -O2 test.c -S

Please note the following chunk of code in the assembly file:-
There is a comparison of the registers R7 and R31.
However, the register R31 is not being initialized and optimized away 
and generating wrong code.

.L4:
addis 9,2,.LC2@toc@ha
ld 9,.LC2@toc@l(9)
lfd 12,0(9)nd 
fcmpu 7,12,31
bng 7,.L20
stfd 31,112(1)


We have investigated this issue and observed that its not observed with
O1 and Os optimization levels. Its only been the issue with O2 & O3.
The generated code was correct on disabling the optimization flags
"fno-tree-pre" and "fno-gcse" for O2 flags. It was also investigated on 
the earlier GCC source code and observed that issue is present atleast
until gcc-4.3.3 sources.

Thanks,
Vinay Kumar

[Bug c++/86921] do not remove input in bash

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  ---
(In reply to Yakov from comment #4)
> I am sorry. I think, I did mistake in my question. I did not press Enter.

You said "when the second line begins. symbols, entered in first line"

If that doesn't mean you pressed Enter, you need to tell us what you did. We
can't guess.

See https://gcc.gnu.org/bugs/