On Fri, Jun 21, 2019 at 3:52 PM Martin Sebor wrote:
>
> Most of the rest seem justified to me and worth cleaning up. Let
> me know if you agree and if you'd like my help with it.
Thanks. I sent https://golang.org/cl/183437 and
https://golang.org/cl/183497 to take care of these.
Ian
On 6/21/19 8:05 PM, Martin Sebor wrote:
The solution we implemented in GCC 9 to get the mangling of
non-type template arguments of class types containing array
members consistent regardless of the form of their
initialization introduced a couple of bugs. One of these
is the subject of this
On 6/22/19 5:57 PM, Marek Polacek wrote:
Now that DEFAULT_ARG is used for more things than just default arguments,
let's rename it and its related entities to something more appropriate.
Bootstrapped/regtested on x86_64-linux, ok for trunk?
OK, thanks.
Jason
On 6/13/19 5:03 PM, Marek Polacek wrote:
Case values are converted constant expressions, so narrowing conversion is not
permitted. This patch adds detecting narrowing to case_conversion; it's a
handy spot because we have both the value and the (adjusted) type of the
condition.
Is there a
On Sat, 22 Jun 2019, Richard Biener wrote:
On June 22, 2019 6:10:15 PM GMT+02:00, Marc Glisse wrote:
Hello,
as discussed in the PR, this seems like a simple enough approach to
handle
FENV functionality safely, while keeping it possible to implement
optimizations in the future.
Some key
Now that DEFAULT_ARG is used for more things than just default arguments,
let's rename it and its related entities to something more appropriate.
Bootstrapped/regtested on x86_64-linux, ok for trunk?
2019-06-22 Marek Polacek
* call.c (convert_default_arg): Use DEFERRED_PARSE instead
The two tests use decimal floating point and therefore fail where that isn’t
available.
Fixed for Darwin by adding the relevant dg-requires lines
(I didn’t try to alter the cases for AIX, but maybe the skip lines could be
removed now).
tested on powerpc-darwin9, applied to mainline,
thanks
Iain
This test was failing because of a pedantic warning that is unrelated to the
purpose of the test. Fixed by suppressing that warning.
tested on powerpc-darwin9, applied to mainline.
thanks
Iain
2019-06-22 Iain Sandoe
* gcc.target/powerpc/darwin-bool-1.c: Suppress the pedantic
On Sat, Jun 22, 2019 at 11:49:25AM -0700, Jerry DeLisle wrote:
> On 6/22/19 11:32 AM, Steve Kargl wrote:
> > On Sat, Jun 22, 2019 at 11:23:48AM -0700, Jerry DeLisle wrote:
> >>
> >> 2019-06-22 Jerry DeLisle
> >>
> >>PR fortran/89782
> >>* io.c (gfc_resolve_dt): Check that internal units
On 6/22/19 11:32 AM, Steve Kargl wrote:
On Sat, Jun 22, 2019 at 11:23:48AM -0700, Jerry DeLisle wrote:
2019-06-22 Jerry DeLisle
PR fortran/89782
* io.c (gfc_resolve_dt): Check that internal units are not
character PARAMETER.
This part of the patch is missing.
On Sat, Jun 22, 2019 at 11:23:48AM -0700, Jerry DeLisle wrote:
>
> 2019-06-22 Jerry DeLisle
>
> PR fortran/89782
> * io.c (gfc_resolve_dt): Check that internal units are not
> character PARAMETER.
This part of the patch is missing.
>
> *
Hi all,
The front-end is not consistently checking for errors with character parameters
as internal units. The reason is we never actually checked for this before. In
some cases an error message is triggered from other unrelated causes or
sometimes no error is given at all.
This is fixed by
On June 22, 2019 6:10:15 PM GMT+02:00, Marc Glisse wrote:
>Hello,
>
>as discussed in the PR, this seems like a simple enough approach to
>handle
>FENV functionality safely, while keeping it possible to implement
>optimizations in the future.
>
>Some key missing things:
>- handle C, not just C++
I suspect Wilco forgot commit this hunk which fixes the avr port after
the recent setjmp/longjmp changes. Tested on the avr-elf port which
builds again.
Committed to the trunk.
Jeff
commit 72f5e18d923404533b58a997735f8c09c6d12bb3
Author: law
Date: Sat Jun 22 16:31:50 2019 +
My fix for c++/60223 (ICE with T{} in non-deduced context) fixed these three
tests also. Yay!
Tested on x86_64-linux, applying to trunk.
2019-06-22 Marek Polacek
PR c++/65707
PR c++/89480
PR c++/58836
* g++.dg/cpp0x/nondeduced5.C: New test.
*
Hello,
as discussed in the PR, this seems like a simple enough approach to handle
FENV functionality safely, while keeping it possible to implement
optimizations in the future.
Some key missing things:
- handle C, not just C++ (I don't care, but some people probably do)
- handle vectors (for
Now that the parsing of noexcept-specifiers is properly delayed, this test
gives the error it should.
Tested x86_64-linux, applying ot trunk.
2019-06-22 Marek Polacek
PR c++/66256
* g++.dg/cpp0x/noexcept54.C: New test.
diff --git gcc/testsuite/g++.dg/cpp0x/noexcept54.C
>
> Ah, no, of course not. I guess the early out here should be a
> "ignore this match" instead.
Here is updated patch with a testcase I have re-tested on x86_64-linux
and comitted. There are still few divergences left, I will debug them
now.
Again the testcase has extra wrapper in struct d
On Fri, Jun 21, 2019 at 8:38 PM H.J. Lu wrote:
> > > > > > > > > >> > > +/* Register pair. */
> > > > > > > > > >> > > +VECTOR_MODES_WITH_PREFIX (P, INT, 2); /* P2QI */
> > > > > > > > > >> > > +VECTOR_MODES_WITH_PREFIX (P, INT, 4); /* P2HI P4QI */
> > > > > > > > > >> > >
> > > > > > > > > >>
19 matches
Mail list logo
