On Fri, Oct 2, 2020 at 6:21 AM H.J. Lu wrote:
>
> On Wed, Sep 16, 2020 at 10:07 PM H.J. Lu wrote:
> >
> > On Wed, Aug 19, 2020 at 6:09 AM H.J. Lu wrote:
> > >
> > > On Tue, May 19, 2020 at 5:14 AM H.J. Lu wrote:
> > > >
> > > > On Tue, May 19, 2020 at 1:48 AM Uros Bizjak wrote:
> > > > >
> > >
On Fri, 16 Oct 2020 at 13:02, Jonathan Wakely wrote:
>
> On 16/10/20 10:26 +0300, Ville Voutilainen via Libstdc++ wrote:
> >Tested on Linux-PPC64. I haven't tested this with clang yet,
> >Jonathan, can you help with that? The previous implementation
> >indeed made an if-constexpr branch invalid fo
On Sat, 17 Oct 2020 at 20:30, Stephan Bergmann wrote:
> Clang (with -std=c++17/20) now complains about
>
> > include/c++/11.0.0/variant:1032:10: error: no matching constructor for
> > initialization of 'std::__nonesuch'
> > return __nonesuch{};
> >^
On 08/10/2020 16:27, Jonathan Wakely via Gcc-patches wrote:
On 05/10/20 22:35 +0300, Ville Voutilainen via Libstdc++ wrote:
On Mon, 5 Oct 2020 at 01:15, Ville Voutilainen
wrote:
The patch is borked, doesn't pass tests, fixing...
Unborked, ok for trunk if full testsuite passes?
Assuming it
Early *ping*.
> Gesendet: Sonntag, 11. Oktober 2020 um 21:09 Uhr
> Von: "Harald Anlauf"
> An: "fortran" , "gcc-patches"
> Betreff: [PATCH] PR libfortran/97063 - Wrong result for vector (step size is
> negative) * matrix
>
> PR libfortran/97063 - Wrong result for vector (step size is negative) *
I eventually would like to propose the following resolution.
For multi-key containers I kept the same resolution build the node first
and compute has code from the node key.
For unique-key ones I change behavior when I can't find out hash functor
argument type. I am rather using the iterator
On Fri, Oct 16, 2020 at 11:29 AM H.J. Lu wrote:
>
> On Fri, Oct 16, 2020 at 11:17 AM Jakub Jelinek wrote:
> >
> > On Fri, Oct 16, 2020 at 10:58:34AM -0700, H.J. Lu wrote:
> > > Don't set HAVE_AS_GDWARF_5_DEBUG_FLAG nor HAVE_AS_WORKING_DWARF_4_FLAG
> > > if there is an extra assembly input file in
On October 16, 2020 8:46:39 PM GMT+02:00, Martin Jambor wrote:
>Hi,
>
>in PR 97456, IPA-SRA triggers a bug in tree-complex.c where it
>converts:
>
>
> a$_M_value_21 = COMPLEX_EXPR ;
>
>(where ISRA.18 is IPA-SRA created PARM_DECL with DECL_IGNORED_P set,
>which is why it only happens with IPA-SR