> I have read through the patch and it looks OK to me but I cannot approve
> it, you have to ping Honza for that. Since you decided to use the value
> range info, it would be nice if you could also add a testcase where it
> plays a role.
It is somewhat hard to write a testcase to show role of ra
On 8/29/19 2:37 AM, Martin Liška wrote:
On 8/28/19 10:19 PM, Jason Merrill wrote:
On 8/28/19 12:29 PM, Martin Liška wrote:
The patch restores behavior before r265711 where we used
cxx_printable_name for __PRETTY_FUNCTION__.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
On 8/29/19 12:36 PM, Marek Polacek wrote:
We reject this test with errors like
nontype1.C:22:14: error: taking address of rvalue [-fpermissive]
22 | A{}> a2;
| ^~~
that happens because for converting "C{}" to int we generate
"C::operator int (&TARGET_EXPR )".
On Sat, Aug 31, 2019 at 3:57 PM Richard Biener
wrote:
>
> On August 31, 2019 2:51:51 AM GMT+02:00, Alan Modra wrote:
> >On Fri, Aug 30, 2019 at 09:42:06AM +0200, Uros Bizjak wrote:
> >> On Fri, Aug 30, 2019 at 9:22 AM Richard Biener
> >> wrote:
> >> >
> >> > On Thu, Aug 29, 2019 at 9:54 AM Uros
This test is failing everywhere on Darwin, which lacks the necessary alias
support.
I didn’t check to see if there was some way to re-write the test to avoid the
need for
such support.
tested on powerpc-darwin9, x86_64-darwin16, {x86-64,powerpc64}-linux-gnu,
applied to mainline as obvious,
thank
This was caused by my inquiry ref patch.
I will commit to both branches tomorrow night unless there is an objection.
Bootstraps and regtests on FC29/x86_64.
Paul
2019-09-02 Paul Thomas
PR fortran/91589
* primary.c (gfc_match_varspec): Return MATCH_NO on an apparent
component ref
On September 1, 2019 6:34:25 PM GMT+02:00, Jakub Jelinek
wrote:
>On Sat, Aug 31, 2019 at 08:25:49PM +0200, Richard Biener wrote:
>> So why not always return an unsigned type then by telling
>type_for_size?
>
>So like this (if it passes bootstrap/regtest)?
Yes.
Thanks,
Richard.
>2019-09-01
On Sat, Aug 31, 2019 at 08:25:49PM +0200, Richard Biener wrote:
> So why not always return an unsigned type then by telling type_for_size?
So like this (if it passes bootstrap/regtest)?
2019-09-01 Jakub Jelinek
PR go/91617
* fold-const.c (range_check_type): For enumeral and b
On Sun, Sep 01, 2019 at 02:30:12PM +0200, Richard Biener wrote:
> On September 1, 2019 1:55:14 PM GMT+02:00, Jakub Jelinek
> wrote:
> >On Sat, Aug 31, 2019 at 03:02:18PM +0200, Richard Biener wrote:
> >> Ok, but I wonder if we can stream the constraint strings in a simpler
> >way - surely the typ
been used yet.
(sparc_pic_register_p): Test reload_in_progress for consistency's sake.
2019-09-01 Eric Botcazou
* gcc.c-torture/execute/20190901-1.c: New test.
--
Eric Botcazou/* PR target/91472 */
/* Reported by John Paul Adrian Glaubitz */
typedef unsigned int gmp_uint
Hi Steve,
OK to commit.
Thanks
Paul
On Sat, 31 Aug 2019 at 21:16, Steve Kargl
wrote:
>
> The attached patch has been built and tested on i586-*-freebsd
> and x86_64-*-freebsd. OK to commit?
>
> The patch fixes an ICE during type conversion where an array
> constructor contains another array.
Hi Steve,
Thanks for the remarks and the OK. Committed as revision 275269.
Onward to PDTs!
Cheers
Paul
On Sat, 31 Aug 2019 at 18:46, Steve Kargl
wrote:
>
> On Sat, Aug 31, 2019 at 04:59:03PM +0100, Paul Richard Thomas wrote:
> >
> > Bootstraps and regtests on FC29/x86_64 - OK for trunk?
>
> W
microsoft.com redirects the existing link and changed the title of
the document; this adjust both.
Committed.
Jonathan(?), if you could regenerate the libstdc++ online docs, that
would be nice.
Gerald
2019-09-01 Gerald Pfeifer
* doc/xml/manual/policy_data_structures_biblio.xml (COM:
On September 1, 2019 1:55:14 PM GMT+02:00, Jakub Jelinek
wrote:
>On Sat, Aug 31, 2019 at 03:02:18PM +0200, Richard Biener wrote:
>> Ok, but I wonder if we can stream the constraint strings in a simpler
>way - surely the type doesn't really matter?
>> Why are they not identifier nodes?
>
>I guess
On Sat, Aug 31, 2019 at 03:02:18PM +0200, Richard Biener wrote:
> Ok, but I wonder if we can stream the constraint strings in a simpler way -
> surely the type doesn't really matter?
> Why are they not identifier nodes?
I guess they have type because they are parsed like any other string
literal
And now the Solaris libstdc++ baseline updates for the gcc-9 branch.
Tested on i386-pc-solaris2.1[01] and sparc-sun-solaris2.1[01]. Ok for
mainline?
Rainer
--
-
Rainer Orth, Center for Biotechnology, Bielefeld
Hi,
this fixes a mistake I made (and a few others as well):
using the wrong month in the ChangeLog.
Committed as obvious.
$ svn diff -r275264:275265
Index: ChangeLog
===
--- ChangeLog (revision 275264)
+++ ChangeLog (revision 27
Here's are the updates to the Solaris libstdc++ baselines on mainline.
Tested on i386-pc-solaris2.11 and sparc-sun-solaris2.11. Ok for mainline?
Rainer
--
-
Rainer Orth, Center for Biotechnology, Bielefeld Univ
Hi,
this fixes an oversight in r274986.
We need to avoid using movmisalign on DECL_P which are not in memory,
similar to the !mem_ref_refers_to_non_mem_p which unfortunately can't
handle DECL_P.
Bootstrapped and reg-tested on x86_64-pc-linux-gnu.
Is it OK for trunk?
Thanks
Bernd.
2019-09-01 B
On September 1, 2019 12:19:51 PM GMT+02:00, Jakub Jelinek
wrote:
>Hi!
>
>The following testcase ICEs, because for SSE4.1 only VEC_COND_EXPRs
>with
>EQ_EXPR/NE_EXPR are supported and vectorizer generates such
>VEC_COND_EXPR,
>but later on the condition is folded into a VECTOR_CST and the
>VEC_COND
Hi!
The following testcase ICEs, because for SSE4.1 only VEC_COND_EXPRs with
EQ_EXPR/NE_EXPR are supported and vectorizer generates such VEC_COND_EXPR,
but later on the condition is folded into a VECTOR_CST and the VEC_COND_EXPR
expansion code expands non-comparison conditions as LT_EXPR against z
21 matches
Mail list logo
