Hello!
> dropping the builtin as early as possible seems like it can only help us
> optimize the code. Jakub
> suggested in the PR that he liked this approach better than using
> __builtin_shuffle in the header.
> There is already some coverage in the testsuite (as I noticed when I tried to
> r
On Mon, 20 May 2019, Christophe Lyon wrote:
> On Fri, 17 May 2019 at 11:24, Richard Biener wrote:
> >
> >
> > Bootstrap / testing in progress on x86_64-unknown-linux-gnu.
> >
> > Richard.
> >
> > 2019-05-17 Richard Biener
> >
> > c/
> > * gimple-parser.c (c_parser_gimple_statem
On 5/19/19 10:06 PM, Marek Polacek wrote:
> On Sun, May 19, 2019 at 01:00:45PM -0700, Andrew Pinski wrote:
>> On Sun, May 19, 2019 at 12:54 PM Segher Boessenkool
>> wrote:
>>>
>>> On Sun, May 19, 2019 at 03:21:01PM -0400, Marek Polacek wrote:
On Sun, May 19, 2019 at 03:11:08AM -0500, Segher B
Hello!
> I have confirmed that the IDT Winchip 2 does not expressly set %ecx
> after a call to cpuid() with %eax = 1, and this causes incorrect
> reporting of cpu capabilities. The %ecx register should return 0x0
> (and likely %ebx should too) on this hardware. This patch proposes a
> fix.
>
> The
On Sat, May 18, 2019 at 2:56 PM Marc Glisse wrote:
>
> On Wed, 15 May 2019, Richard Biener wrote:
>
> > As you write the heuristic you could as well remove the malloc result
> > points-to set from the others after points-to analysis is finished?
>
> Looking at the vector testcase:
>
> #include
>
On Sat, May 18, 2019 at 4:00 PM Marc Glisse wrote:
>
> (@Feng Xue, it is better to include testcases in your patches)
>
> >> I'm not a big fan of this patch. I'd rather be looking at either
> >> improving our analysis
>
> Better analysis cannot hurt.
>
> >> or adding attributes to the loops to he
On Sun, May 19, 2019 at 6:16 PM Marc Glisse wrote:
>
> Hello,
>
> 2 pieces:
>
> - the first one handles the case where the denominator is negative. It
> doesn't happen often with exact_div, so I don't handle it everywhere, but
> this one looked trivial
>
> - handle the case where a pointer differe
On Sun, May 19, 2019 at 6:22 PM Marc Glisse wrote:
>
> Hello,
>
> I noticed this one with BIT_NOT_EXPR a while ago. C++ testcase because I
> haven't looked at gimplefe yet...
OK. I wonder if there's any issue with -ftrapv and negate/abs of
INT_MIN containing
vectors (we don't implement -ftrapv o
On Sun, May 19, 2019 at 6:23 PM Marc Glisse wrote:
>
> Hello,
>
> this patch lets the test match q_10, which can happen if you modify gcc a
> bit... It seems better to me to improve the test now, but if you think it
> is better that I wait until I have a gcc patch that actually requires it,
> that
On Mon, 20 May 2019, Richard Biener wrote:
On Sun, May 19, 2019 at 6:16 PM Marc Glisse wrote:
Hello,
2 pieces:
- the first one handles the case where the denominator is negative. It
doesn't happen often with exact_div, so I don't handle it everywhere, but
this one looked trivial
- handle t
On Sun, May 19, 2019 at 8:50 PM Eric S. Raymond wrote:
>
> First, my apologies for not responding five days ago. Joseph's mail
> issued as I was transitioning to a new machine and the day before I
> spent some hours in the ER of my local hospital, and I missed it in
> the confusion.
>
> In case yo
>>
>> IIUC that was slightly different: "This option tells the loop optimizer to
>> assume that loop indices do not overflow, and that loops with nontrivial
>> exit condition are not infinite."
>>
>> The assumption on indices looks unsafe indeed if it applied to unsigned
>> indices in non-empty l
Hi Martin,
> On 5/14/19 5:07 PM, Martin Sebor wrote:
>> On 5/14/19 8:55 AM, Martin Liška wrote:
>>> On 5/13/19 3:07 PM, Jakub Jelinek wrote:
On Mon, May 13, 2019 at 12:14:37PM +0200, Martin Liška wrote:
> On 5/10/19 11:21 AM, Jakub Jelinek wrote:
>> On Fri, May 10, 2019 at 11:04:12AM
On Fri, 17 May 2019, Richard Biener wrote:
>
> This moves things from fold-const.c to match.pd.
So there's an issue that was appearantly side-stepped in the GENERIC
folding by not re-folding the result.
/* Generate a canonical form of the selector. */
if (sel.encoding () != bui
On Mon, May 20, 2019 at 10:16:26AM +0200, Richard Biener wrote:
> There's not many details there but I always thought that the
> "interesting" parts of the GCC history (official branches and trunk)
> do _not_ contain merge commits so the GCC history forms a tree
> rather than a DAG. (I'm not sure
Hi Iain,
> Hi Dominique,
>
>> On 19 May 2019, at 15:10, Dominique d'Humières wrote:
>>
>> AFAICT the syntax for dg-require-ifunc seems to be
>>
>> /* { dg-require-ifunc "" } */
>>
>> with two sets of exceptions:
>>
>> (1) gcc.target/i386/pr90500-*.c
>>
>> which explains
>>
>> FAIL: gcc.targ
On Mon, May 20, 2019 at 11:00 AM Jakub Jelinek wrote:
>
> On Mon, May 20, 2019 at 10:16:26AM +0200, Richard Biener wrote:
> > There's not many details there but I always thought that the
> > "interesting" parts of the GCC history (official branches and trunk)
> > do _not_ contain merge commits so
Hi.
This is a missing piece of the libc_has_fast_function hook.
I'm going to install that as obvious as it breaks current trunk
for all except x86 target.
Martin
gcc/ChangeLog:
2019-05-20 Martin Liska
* targhooks.c (default_libc_has_fast_function): New function.
* targhooks.
On Mon, 20 May 2019 at 09:16, Richard Biener wrote:
>
> On Mon, 20 May 2019, Christophe Lyon wrote:
>
> > On Fri, 17 May 2019 at 11:24, Richard Biener wrote:
> > >
> > >
> > > Bootstrap / testing in progress on x86_64-unknown-linux-gnu.
> > >
> > > Richard.
> > >
> > > 2019-05-17 Richard Biener
On Mon, May 20, 2019 at 7:57 AM Christophe Lyon
wrote:
>
> Hi,
>
> After Martin's commit r271338, we now emit quotes around reserved
> names, and some tests started to fail on aarch64 and arm.
>
> This should fix them, OK?
Looks obvious to me.
R
>
> Christophe
On Mon, 20 May 2019, Christophe Lyon wrote:
> On Mon, 20 May 2019 at 09:16, Richard Biener wrote:
> >
> > On Mon, 20 May 2019, Christophe Lyon wrote:
> >
> > > On Fri, 17 May 2019 at 11:24, Richard Biener wrote:
> > > >
> > > >
> > > > Bootstrap / testing in progress on x86_64-unknown-linux-gnu.
On Mon, May 20, 2019 at 10:16 AM Marc Glisse wrote:
>
> On Mon, 20 May 2019, Richard Biener wrote:
>
> > On Sun, May 19, 2019 at 6:16 PM Marc Glisse wrote:
> >>
> >> Hello,
> >>
> >> 2 pieces:
> >>
> >> - the first one handles the case where the denominator is negative. It
> >> doesn't happen oft
On 04/02/2019 07:33 PM, Padraig Brady wrote:
> On 03/07/2019 03:43 AM, Jonathan Wakely wrote:
>> OK, that makes me feel better about it. It's presumably much easier to
>> upgrade to 5.2 from 5.0 or 5.1 than it would be from 4.x.
>>
How complicated is the fix to prevent the crashes? Would it
On Mon, May 20, 2019 at 10:27 AM Feng Xue OS
wrote:
>
>
> >>
> >> IIUC that was slightly different: "This option tells the loop optimizer to
> >> assume that loop indices do not overflow, and that loops with nontrivial
> >> exit condition are not infinite."
> >>
> >> The assumption on indices look
Richard Biener writes:
> On Fri, 17 May 2019, Richard Biener wrote:
>
>>
>> This moves things from fold-const.c to match.pd.
>
> So there's an issue that was appearantly side-stepped in the GENERIC
> folding by not re-folding the result.
>
> /* Generate a canonical form of the selector.
Hi Jakub, all,
> On 14 May 2019, at 23:57, Jakub Jelinek wrote:
>
> On Tue, May 14, 2019 at 01:08:27PM -0600, Jeff Law wrote:
>>> In https://gcc.gnu.org/ml/gcc-patches/2019-05/msg00484.html I've posted a
>>> patch that would set it earlier (or it could be set during gimplification
>>> and propag
On Thu, 16 May 2019, li...@linux.ibm.com wrote:
> From: Kewen Lin
>
> Hi,
>
> Previous version link:
> https://gcc.gnu.org/ml/gcc-patches/2019-05/msg00654.html
>
> Comparing with the previous version, I moved the generic
> parts of rs6000 target hook to IVOPTs. But I still kept
> the target h
On Fri, 17 May 2019, Jakub Jelinek wrote:
> Hi!
>
> When simdlen clause is specified on simd loop, it specifies the preferred
> vectorization factor. It is a preference, so if there is no possibility of
> satisfying it, we can do something else, but still, we shouldn't ignore it
> as we've been
Hi,
at the moment the alias stats outputs mostly 0 for res_may_alias_p
(which is supposed to be main entry point to the alias oracle).
I think this is because of code refactoring where we added more variants
of this function and we want to do stats around the main worker.
Bootstrapped/regtested x8
On Mon, 20 May 2019, Jan Hubicka wrote:
> Hi,
> at the moment the alias stats outputs mostly 0 for res_may_alias_p
> (which is supposed to be main entry point to the alias oracle).
> I think this is because of code refactoring where we added more variants
> of this function and we want to do stats
On Sun, 19 May 2019, Jan Hubicka wrote:
> > On Fri, 17 May 2019, Jan Hubicka wrote:
> >
> > > Hi,
> > > this patch cuts walks in aliasing_component_refs_p if the type we look for
> > > can not fit into a given type by comparing their sizes. Similar logic
> > > already exists in indirect_ref_may_a
On Fri, May 17, 2019 at 6:42 PM Vladislav Ivanishin wrote:
>
> Richard Biener writes:
>
> > On Tue, May 14, 2019 at 3:58 PM Vladislav Ivanishin wrote:
> >>
> >> Hi!
> >>
> >> The split_critical_edges() function has multiple uses and it seems, a
> >> portion of its code was added to work only whe
On 20/05/19 09:17 +, Pádraig Brady wrote:
On 04/02/2019 07:33 PM, Padraig Brady wrote:
On 03/07/2019 03:43 AM, Jonathan Wakely wrote:
OK, that makes me feel better about it. It's presumably much easier to
upgrade to 5.2 from 5.0 or 5.1 than it would be from 4.x.
How complicated is the f
On Fri, May 17, 2019 at 10:12 AM Vladislav Ivanishin wrote:
>
> Hi!
>
> Without the patch, two of the newly added tests fail with bogus warnings:
>
> - gcc.dg/uninit-28-gimple.c (Definition guarded with NE_EXPR, use with
> BIT_AND_EXPR. This is an FP my previous patch [1] knowingly
> overlook
On 19/05/19 17:44 -0400, Marek Polacek wrote:
CWG 2094 partially reverts CWG 496, which means that volatile-qualified scalars
are, once again, trivially copyable; [basic.types] now says "Scalar types,
trivially copyable class types, arrays of such types, and cv-qualified
versions of these types a
>> Now finiteness assertion is only used in a very late CD-DCE, which is
>> located after all loop optimizations are done. And we can even place it as
>> late as just before RTL-expansion. This might be safe enough to let hidden
>> infinite loops exposed.
> Is that so? The early pipeline conta
Hi.
The patch is about fallout of -Wformat-diag for ppc64le target where
I added quoting of various warnings and errors.
Patch can bootstrap on ppc64le-linux-gnu and survives regression tests.
Ready to be installed?
Thanks,
Martin
gcc/ChangeLog:
2019-05-16 Martin Liska
* config/rs6
On Mon, May 20, 2019 at 11:48:45AM +0200, Martin Liška wrote:
> --- a/gcc/config/rs6000/driver-rs6000.c
> +++ b/gcc/config/rs6000/driver-rs6000.c
> @@ -266,7 +266,7 @@ elf_platform (void)
> fatal_error (
> input_location,
> "Unsupported cpu name returned from kernel for
Let me try to answer a bit here...
On Mon, May 20, 2019 at 11:28:26AM +0200, Richard Biener wrote:
> On Thu, 16 May 2019, li...@linux.ibm.com wrote:
> > +/* Predict whether the given loop in gimple will be transformed in the RTL
> > + doloop_optimize pass. This is for rs6000 target specific. *
On Mon, 20 May 2019, Richard Sandiford wrote:
> Richard Biener writes:
> > On Fri, 17 May 2019, Richard Biener wrote:
> >
> >>
> >> This moves things from fold-const.c to match.pd.
> >
> > So there's an issue that was appearantly side-stepped in the GENERIC
> > folding by not re-folding the resu
On 5/20/19 12:06 PM, Jakub Jelinek wrote:
> On Mon, May 20, 2019 at 11:48:45AM +0200, Martin Liška wrote:
>> --- a/gcc/config/rs6000/driver-rs6000.c
>> +++ b/gcc/config/rs6000/driver-rs6000.c
>> @@ -266,7 +266,7 @@ elf_platform (void)
>>fatal_error (
>> input_location,
>>
An array of an unknown bound is an incomplete type, so no object of such
a type can be constructed. This means __is_constructible should always
be false for an array of unknown bound.
This patch also changes the std::is_default_constructible trait to use
std::is_constructible, which now gives the
On 5/20/19 10:43 AM, Rainer Orth wrote:
> Hi Martin,
>
>> On 5/14/19 5:07 PM, Martin Sebor wrote:
>>> On 5/14/19 8:55 AM, Martin Liška wrote:
On 5/13/19 3:07 PM, Jakub Jelinek wrote:
> On Mon, May 13, 2019 at 12:14:37PM +0200, Martin Liška wrote:
>> On 5/10/19 11:21 AM, Jakub Jelinek
On 5/20/19 11:05 AM, Martin Liška wrote:
> Hi.
>
> This is a missing piece of the libc_has_fast_function hook.
> I'm going to install that as obvious as it breaks current trunk
> for all except x86 target.
>
> Martin
>
> gcc/ChangeLog:
>
> 2019-05-20 Martin Liska
>
> * targhooks.c (de
Hi!
On Mon, May 20, 2019 at 11:48:45AM +0200, Martin Liška wrote:
> * config/rs6000/driver-rs6000.c (elf_platform): Do not use
> an extra newline.
> * config/rs6000/rs6000-c.c (SYNTAX_ERROR): Wrap pragma in %<%>.
Please say this is in rs6000_pragma_longcall. You might want to m
On 5/20/19 12:52 PM, Segher Boessenkool wrote:
> Hi!
>
> On Mon, May 20, 2019 at 11:48:45AM +0200, Martin Liška wrote:
>> * config/rs6000/driver-rs6000.c (elf_platform): Do not use
>> an extra newline.
>> * config/rs6000/rs6000-c.c (SYNTAX_ERROR): Wrap pragma in %<%>.
>
> Please sa
Hi Martin,
>> as usual, the new effective-target keyworks needs documenting in
>> sourcebuild.texi.
>
> It's not a target keywords, but it's a new hook. I've briefly read the file
> and I can't find any other hooks mentioned in the file.
I'm not talking about the hook, but about the glibc effecti
On 20/05/19 10:44 +0100, Jonathan Wakely wrote:
On 20/05/19 09:17 +, Pádraig Brady wrote:
On 04/02/2019 07:33 PM, Padraig Brady wrote:
On 03/07/2019 03:43 AM, Jonathan Wakely wrote:
OK, that makes me feel better about it. It's presumably much easier to
upgrade to 5.2 from 5.0 or 5.1 than
On 5/20/19 6:43 AM, Jonathan Wakely wrote:
An array of an unknown bound is an incomplete type, so no object of such
a type can be constructed. This means __is_constructible should always
be false for an array of unknown bound.
This patch also changes the std::is_default_constructible trait to us
Inspired by one of Iain's patches for PR target/82920, this patch
rejects -mx32 on Solaris/x86, too: x32 won't be implemented on Solaris
and the failure if one tries to use it isn't very helpful otherwise:
$ gcc -mx32 -o hello hello.c
In file included from
/vol/gcc-9/lib/gcc/i386-pc-solaris2.11/9
On 20/05/19 07:29 -0400, Nathan Sidwell wrote:
On 5/20/19 6:43 AM, Jonathan Wakely wrote:
An array of an unknown bound is an incomplete type, so no object of such
a type can be constructed. This means __is_constructible should always
be false for an array of unknown bound.
This patch also chang
This patch completes a fix Eric already applied on the SPARC side some
time ago, namely the erroreous use of a `:' after %e in specs.
Bootstrapped without regressions on sparc-sun-solaris2.11 and
i386-pc-solaris2.11, installed on mainline.
Rainer
--
--
On Sun, 19 May 2019, Richard Sandiford wrote:
> Richard Biener writes:
> > This adds, incrementally ontop of moving VEC_PERM_EXPR folding
> > to match.pd (but not incremental patch - sorry...), folding
> > of single-element insert permutations to BIT_INSERT_EXPR.
> >
> > Things are quite awkward
On Mon, May 20, 2019 at 11:48 AM Feng Xue OS
wrote:
>
> >> Now finiteness assertion is only used in a very late CD-DCE, which is
> >> located after all loop optimizations are done. And we can even place it as
> >> late as just before RTL-expansion. This might be safe enough to let hidden
> >> i
As noticed by Marc.
Bootstrapped / tested on x86_64-unknown-linux-gnu, applied.
Richard.
2019-05-20 Richard Biener
* tree-ssa-structalias.c (find_func_aliases): POINTER_MINUS_EXPR
doesn't produce pointers.
{TRUNC,CEIL,FLOOR,ROUND,EXACT}_{DIV,MOD}_EXPR points to what
Hi,
As discussed in the PR, the new cdce3.c test fails on
arm-linux-gnueabi, and passes on arm-linux-gnueabihf.
On arm-linux-gnueabi, the generated code is:
.arm
.fpu softvfp
.type foo, %function
foo:
b sqrtf
on arm-liunx-gnueabihf, it is:
.arm
Hi Jonathan,
> * include/bits/random.h (seed_seq::param): Fix non-reserved name.
> * include/experimental/type_traits (is_detected_exact)
> (is_detected_exact_v): Likewise.
> * include/pstl/execution_defs.h (is_execution_policy)
> (is_execution_policy_v, __enable_if_e
Alejandro Martinez Vicente writes:
> Hi Richards,
>
> This is the new version of the patch, addressing your comments.
You forgot the changelog :-)
The patch LGTM otherwise. Richard, any objections?
>
> Alejandro
>
>> -Original Message-
>> From: Richard Sandiford
>> Sent: 08 May 2019 1
On 20/05/19 14:11 +0200, Rainer Orth wrote:
Hi Jonathan,
* include/bits/random.h (seed_seq::param): Fix non-reserved name.
* include/experimental/type_traits (is_detected_exact)
(is_detected_exact_v): Likewise.
* include/pstl/execution_defs.h (is_execution_policy
Darwin doesn't emit a .file directive by default
and one of the scan-asm hits for ELF targets comes from
this directive. Adjust for Darwin and explain.
Tested on x86_64-darwin16, x86_64-linux-gnu
Applied to mainline.
Iain
2019-05-20 Iain Sandoe
PR testsuite/58321
* gcc.target/
A patch from the modules branch. I realized we don't need namespace
field to hold using directives. Each binding level already has such a
field, and we can easily go from namespace decl to its binding level.
This patch removes the usings field, and adjusts the accesses in
name-lookup. As an
On Mon, May 20, 2019 at 2:19 PM Richard Sandiford
wrote:
>
> Alejandro Martinez Vicente writes:
> > Hi Richards,
> >
> > This is the new version of the patch, addressing your comments.
>
> You forgot the changelog :-)
>
> The patch LGTM otherwise. Richard, any objections?
Nope.
Richard.
> >
>
On Mon, 20 May 2019, Richard Biener wrote:
On Sat, May 18, 2019 at 4:00 PM Marc Glisse wrote:
(@Feng Xue, it is better to include testcases in your patches)
I'm not a big fan of this patch. I'd rather be looking at either
improving our analysis
Better analysis cannot hurt.
or adding at
On Mon, May 20, 2019 at 3:04 PM Marc Glisse wrote:
>
> On Mon, 20 May 2019, Richard Biener wrote:
>
> > On Sat, May 18, 2019 at 4:00 PM Marc Glisse wrote:
> >>
> >> (@Feng Xue, it is better to include testcases in your patches)
> >>
> I'm not a big fan of this patch. I'd rather be looking a
On Mon, 20 May 2019, Richard Biener wrote:
On Sun, May 19, 2019 at 6:22 PM Marc Glisse wrote:
Hello,
I noticed this one with BIT_NOT_EXPR a while ago. C++ testcase because I
haven't looked at gimplefe yet...
OK. I wonder if there's any issue with -ftrapv and negate/abs of
INT_MIN containi
Hi Jonathan,
> On 20/05/19 14:11 +0200, Rainer Orth wrote:
>>Hi Jonathan,
>>
>>> * include/bits/random.h (seed_seq::param): Fix non-reserved name.
>>> * include/experimental/type_traits (is_detected_exact)
>>> (is_detected_exact_v): Likewise.
>>> * include/pstl/execution_defs.h (is
This patch commonizes local- and namespace-scope using directive
finishing. While a small cleanup, it matches a more significant
using-decl patch I have next.
applying to trunk.
nathan
--
Nathan Sidwell
2019-05-20 Nathan Sidwell
gcc/cp/
* name-lookup.c (finish_namespace_using_directive)
* Andrew Pinski:
> On Sun, May 19, 2019 at 12:54 PM Segher Boessenkool
> wrote:
>> Git can bisect automatically just fine, there is no upside to doing things
>> manually. In git there are various handy ways of referring to commits; you
>> can say master@{3 days ago} for example, or zut@{31}
>> I specialized a CD-DCE pass, named CD-DCE2, and only in this pass, loop
>> removal based on assumed finteness is performed. Please check the patch.
> Oh, but why not generally do this?
It is nature that real finiteness of loop should override assumed one. As you
said, CD-DCE could be invocat
On Mon, May 20, 2019 at 4:00 PM Feng Xue OS wrote:
>
> >> I specialized a CD-DCE pass, named CD-DCE2, and only in this pass, loop
> >> removal based on assumed finteness is performed. Please check the patch.
>
>
> > Oh, but why not generally do this?
>
> It is nature that real finiteness of loop
On 17/05/2019 15:15, Jonathan Wakely wrote:
> * include/bits/random.h (seed_seq::param): Fix non-reserved name.
> * include/experimental/type_traits (is_detected_exact)
> (is_detected_exact_v): Likewise.
> * include/pstl/execution_defs.h (is_execution_policy)
> (is_execution_pol
On Mon, May 20, 2019 at 03:56:35PM +0200, Florian Weimer wrote:
> If GCC policy is to reject merge commits, a command similar to
> “git log --pretty=oneline | wc -l” gives something that is very
> much like a Subversion revision number, in the sense that it matches
> the commit ordering and that th
Hi,
noticed a while ago this nit. Patchlet tested multiple times since, any
objections?
Thanks, Paolo.
2019-05-20 Paolo Carlini
* cp-tree.h: Remove remnants of CONV_NONCONVERTING.
Index: cp-tree.h
==
Uros,
On Mon, May 20, 2019 at 3:29 AM Uros Bizjak wrote:
> The CPUID documentation from Intel Architectures Developer's manual is
> crystal clear on the implementation:
>
> --quote--
> CPUID—CPU Identification
>
> Returns processor identification and feature
> information to the EAX, EBX, ECX, an
On Mon, May 20, 2019 at 03:56:35PM +0200, Florian Weimer wrote:
> * Andrew Pinski:
>
> > On Sun, May 19, 2019 at 12:54 PM Segher Boessenkool
> > wrote:
>
> >> Git can bisect automatically just fine, there is no upside to doing things
> >> manually. In git there are various handy ways of referri
On Mai 20 2019, Florian Weimer wrote:
> If GCC policy is to reject merge commits, a command similar to
> “git log --pretty=oneline | wc -l” gives something that is very
git rev-list HEAD | wc -l
Andreas.
--
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4
On Mon, May 20, 2019 at 04:26:45PM +0200, Andreas Schwab wrote:
> On Mai 20 2019, Florian Weimer wrote:
>
> > If GCC policy is to reject merge commits, a command similar to
> > “git log --pretty=oneline | wc -l” gives something that is very
>
> git rev-list HEAD | wc -l
That is still in the 1.3
On Mai 20 2019, Jakub Jelinek wrote:
> On Mon, May 20, 2019 at 04:26:45PM +0200, Andreas Schwab wrote:
>> On Mai 20 2019, Florian Weimer wrote:
>>
>> > If GCC policy is to reject merge commits, a command similar to
>> > “git log --pretty=oneline | wc -l” gives something that is very
>>
>> git
On 20/05/19 14:11 +, Szabolcs Nagy wrote:
On 17/05/2019 15:15, Jonathan Wakely wrote:
* include/bits/random.h (seed_seq::param): Fix non-reserved name.
* include/experimental/type_traits (is_detected_exact)
(is_detected_exact_v): Likewise.
* include/pstl/execution_defs.h (is_
On 5/20/19 4:24 AM, Segher Boessenkool wrote:
> Let me try to answer a bit here...
>
> On Mon, May 20, 2019 at 11:28:26AM +0200, Richard Biener wrote:
>> On Thu, 16 May 2019, li...@linux.ibm.com wrote:
>>> +/* Predict whether the given loop in gimple will be transformed in the RTL
>>> + doloop_o
On 5/20/19 6:00 AM, Christophe Lyon wrote:
> Hi,
>
> As discussed in the PR, the new cdce3.c test fails on
> arm-linux-gnueabi, and passes on arm-linux-gnueabihf.
>
> On arm-linux-gnueabi, the generated code is:
> .arm
> .fpu softvfp
> .type foo, %function
> foo:
>
Hi,
On Mon, 20 May 2019, Richard Biener wrote:
> > The C++ standard says that do{}while(1) is __builtin_unreachable(), we
> > don't have to preserve it. There is no mention of anything like a
> > "nontrivial exit condition". Other languages may have a different
> > opinion though, so it would
On 5/20/19 12:56 AM, Christophe Lyon wrote:
Hi,
After Martin's commit r271338, we now emit quotes around reserved
names, and some tests started to fail on aarch64 and arm.
This should fix them, OK?
Thanks! There will probably be a few more like this on other
targets. Jeff has been running a
> I don't see how it is safe in a late pass when it is not safe in an
> earlier one. Optimization is imperfect - we could fail to remove
> an "obvious" never taken exit and still have a loop that appears to be
> finite according to our definition.
Yes. it is. This is somewhat similar to strict-a
On Mon, May 20, 2019 at 09:48:57AM -0400, Nathan Sidwell wrote:
> + if (attribs != error_mark_node)
> +for (tree a = attribs; a; a = TREE_CHAIN (a))
> + {
> + tree name = get_attribute_name (a);
> + if (current_binding_level->kind == sk_namespace
> + && is_attribute_p ("st
On Mon, May 20, 2019 at 04:29:10PM +0200, Jakub Jelinek wrote:
> On Mon, May 20, 2019 at 04:26:45PM +0200, Andreas Schwab wrote:
> > On Mai 20 2019, Florian Weimer wrote:
> >
> > > If GCC policy is to reject merge commits, a command similar to
> > > “git log --pretty=oneline | wc -l” gives someth
Ping.
https://gcc.gnu.org/ml/gcc-patches/2019-05/msg00594.html
Thanks,
Kyrill
On 5/13/19 12:18 PM, Kyrill Tkachov wrote:
Hi Richard,
On 5/9/19 9:06 AM, Richard Sandiford wrote:
Kyrill Tkachov writes:
+;; Helper expander for aarch64_abd_3 to save the callers
+;; the hassle of constructing
On Sun, May 19, 2019 at 12:10 PM tedheadster wrote:
>
> I have confirmed that the IDT Winchip 2 does not expressly set %ecx
> after a call to cpuid() with %eax = 1, and this causes incorrect
> reporting of cpu capabilities. The %ecx register should return 0x0
> (and likely %ebx should too) on this
===
--- ChangeLog (revision 271424)
+++ ChangeLog (working copy)
@@ -1,3 +1,7 @@
+2019-05-20 Vladislav Ivanishin
+
+ * MAINTAINERS (Write After Approval): Add myself.
+
2019-05-19 Peter Bergner
* MAINTAINERS:
On Mon, May 20, 2019 at 4:24 PM tedheadster wrote:
>
> Uros,
>
> On Mon, May 20, 2019 at 3:29 AM Uros Bizjak wrote:
> > The CPUID documentation from Intel Architectures Developer's manual is
> > crystal clear on the implementation:
> >
> > --quote--
> > CPUID—CPU Identification
> >
> > Returns pr
This patch fixes a naked inform call that can be seen with -w.
While at it, I added missing quotes; I'm surprisesd this wasn't fixed by the
recent patch Martin submitted.
Bootstrapped/regtested on x86_64-linux, ok for trunk?
2019-05-20 Marek Polacek
* name-lookup.c (finish_using_dir
On 5/10/19 7:10 PM, Marek Polacek wrote:
When we have
template
struct S { };
then in
S s;
"int()" is resolved to a type-id, as per [temp.arg]/2, causing this program to
fail to compile. This can be rather confusing so I think we want to improve the
diagnostic a bit.
Bootstrapped/r
On 20/05/2019 15:38, Jonathan Wakely wrote:
> On 20/05/19 14:11 +, Szabolcs Nagy wrote:
>> On 17/05/2019 15:15, Jonathan Wakely wrote:
>>> * include/bits/random.h (seed_seq::param): Fix non-reserved name.
>>> * include/experimental/type_traits (is_detected_exact)
>>> (is_detected_ex
On 20/05/19 16:05 +, Szabolcs Nagy wrote:
On 20/05/2019 15:38, Jonathan Wakely wrote:
On 20/05/19 14:11 +, Szabolcs Nagy wrote:
On 17/05/2019 15:15, Jonathan Wakely wrote:
* include/bits/random.h (seed_seq::param): Fix non-reserved name.
* include/experimental/type_traits (is_d
On Mon, May 20, 2019 at 11:52 AM Uros Bizjak wrote:
> How about the attached patch that enables zeroing only for 32bit
> processors, and only for cpuid leaf 1? Usually, __get_cpuid is used
> with a constant leaf argument, so we benefit from constant propagation
> into inline function. Also, accor
This test fails in C++2a since r271338, because the types in the "aka" differ:
in C++17 and below we print:
{aka 'const char [3]'}
while in C++2a:
{aka 'const char8_t [3]'}
We can make the regexp accept both.
Tested on x86_64-linux, ok for trunk?
2019-05-20 Marek Polacek
* g++.dg
On Mon, May 20, 2019 at 12:18:18PM -0400, Marek Polacek wrote:
> This test fails in C++2a since r271338, because the types in the "aka" differ:
> in C++17 and below we print:
> {aka 'const char [3]'}
> while in C++2a:
> {aka 'const char8_t [3]'}
>
> We can make the regexp accept both.
...beca
On Mon, May 20, 2019 at 08:43:59AM -0600, Jeff Law wrote:
> > I think we should have two hooks: one is called with the struct loop as
> > parameter; and the other is called for every statement in the loop, if
> > the hook isn't null anyway. Or perhaps we do not need that second one.
> I'd wait to
On 5/20/19 10:55 AM, Marek Polacek wrote:
On Mon, May 20, 2019 at 09:48:57AM -0400, Nathan Sidwell wrote:
+ if (attribs != error_mark_node)
+for (tree a = attribs; a; a = TREE_CHAIN (a))
+ {
+ tree name = get_attribute_name (a);
+ if (current_binding_level->kind == sk_names
On 5/20/19 8:50 AM, Martin Sebor wrote:
> On 5/20/19 12:56 AM, Christophe Lyon wrote:
>> Hi,
>>
>> After Martin's commit r271338, we now emit quotes around reserved
>> names, and some tests started to fail on aarch64 and arm.
>>
>> This should fix them, OK?
>
> Thanks! There will probably be a fe
1 - 100 of 166 matches
Mail list logo
