I've committed this relatively trivial patch to fix up some of the
kernels loop annotation tests on the OG10 branch to match changes in the
dump formatting.
-Sandra
commit 6d670e648e76fe44589a42ee458098ff84d24af1
Author: Sandra Loosemore
Date: Sat Aug 22 22:43:57 2020 -0700
Fix patterns
This is another small tweak to the kernels loop annotator. Like the
subject line says, it allows the annotator to consider loops that have
calls to builtins (C/C++) or intrinsics (Fortran). I've committed this
to the OG10 branch since there is no one to review these patches right
now, and it
On 8/20/20 6:33 PM, Segher Boessenkool wrote:
Hi!
On Tue, Aug 18, 2020 at 02:31:41AM -0400, Michael Meissner wrote:
In order to do this, the pass that converts the load address and load/store
must occur late in the compilation cycle.
That does not follow afaics.
Let me see if I can help exp
Hi Dave,
I actually think using plus_xor_ior operator is useful. It means that if
combine,
inlining or some other RTL simplification generates these variants, these forms
will still be recognized by the backend. It's more typing, but the compiler
produces
better code.
Here's what I have so fa
On 2020-08-22 12:01 p.m., Roger Sayle wrote:
> I suspect that the issue with the 64-bit patterns is that the second variant
> of
> pa.md's define_insn "shrpdi4" is unlikely ever to match as (minus:DI
> (const_int 64) x)
> is never "canonical" when x is itself a CONST_INT. Splitting this
> define_
Hi, Josh
On 08/21, Josh Triplett wrote:
> On Thu, Aug 20, 2020 at 07:00:13PM -0300, Giuliano Belinassi wrote:
> > This patch series add a new flag "-fparallel-jobs=" to control if the
> > compiler should try to compile the current file in parallel.
> [...]
> > Bootstrapped and Regtested on Linux x
On Sat, Aug 22, 2020 at 10:11 AM Uros Bizjak wrote:
>
> On Sat, Aug 22, 2020 at 6:27 PM H.J. Lu wrote:
> >
> > On Fri, Aug 21, 2020 at 9:45 AM H.J. Lu wrote:
> > >
> > > On Fri, Aug 21, 2020 at 9:35 AM H.J. Lu wrote:
> > > >
> > > > On Fri, Aug 21, 2020 at 9:29 AM Hongtao Liu wrote:
> > > > >
On Sat, Aug 22, 2020 at 6:27 PM H.J. Lu wrote:
>
> On Fri, Aug 21, 2020 at 9:45 AM H.J. Lu wrote:
> >
> > On Fri, Aug 21, 2020 at 9:35 AM H.J. Lu wrote:
> > >
> > > On Fri, Aug 21, 2020 at 9:29 AM Hongtao Liu wrote:
> > > >
> > > > On Fri, Aug 21, 2020 at 11:50 PM Uros Bizjak wrote:
> > > > >
On Fri, Aug 21, 2020 at 9:45 AM H.J. Lu wrote:
>
> On Fri, Aug 21, 2020 at 9:35 AM H.J. Lu wrote:
> >
> > On Fri, Aug 21, 2020 at 9:29 AM Hongtao Liu wrote:
> > >
> > > On Fri, Aug 21, 2020 at 11:50 PM Uros Bizjak wrote:
> > > >
> > > > On Fri, Aug 21, 2020 at 5:41 PM Hongtao Liu wrote:
> > >
Hi Dave,
Many thanks for your help.
I suspect that the issue with the 64-bit patterns is that the second variant
of
pa.md's define_insn "shrpdi4" is unlikely ever to match as (minus:DI
(const_int 64) x)
is never "canonical" when x is itself a CONST_INT. Splitting this
define_insn
into two (or
PR analyzer/94851 reports various false "NULL dereference" diagnostics.
The first case (comment #1) affects GCC 10.2 but no longer affects
trunk; I believe it was fixed by the state rewrite of
r11-2694-g808f4dfeb3a95f50f15e71148e5c1067f90a126d.
The patch adds a regression test for this case.
The
I have followup patches that add new conditions to store::eval_alias.
Rather than duplicate all conditions for symmetry, split it up and
call it on both (A, B) and (B, A).
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to master as c199723d7ed0032db095abc75b82a9710eaa5e56.
region_model::push_frame was binding arguments for both the default SSA
name for each parameter, and the underlying parameter.
Simplify the generated states by only binding the default SSA name if
it exists, or the parameter if there is no default SSA name.
Successfully bootstrapped & regrtested
On Sat, 22 Aug 2020, Jonathan Wakely via Gcc-patches wrote:
On Sat, 22 Aug 2020 at 13:13, Jonathan Wakely wrote:
On Sat, 22 Aug 2020 at 10:52, Marc Glisse wrote:
is there a particular reason to handle only __int128 this way, and not all
the non-standard integer types? It looks like it would
On Sat, 15 Aug 2020, Roger Sayle wrote:
Here's version #2 of the patch to recognize bswap32 and bswap64
incorporating your suggestions and feedback. The test cases now confirm
the transformation is applied when int is 32 bits and long is 64 bits,
and should pass otherwise; the patterns now re
On Fri, Aug 21, 2020 at 12:04 AM Palmer Dabbelt wrote:
>
> On Wed, 19 Aug 2020 02:25:37 PDT (-0700), gcc-patches@gcc.gnu.org wrote:
> > Hi Andrew:
> >
> > I am not sure the reason why some targets pick different numbers.
> > It seems it's not only target dependent but also OS dependent[1].
> >
> >
On Fri, 21 Aug 2020, Roger Sayle wrote:
This simple patch to match.pd optimizes away bit permutation
operations, specifically bswap and rotate, in calls to popcount and
parity.
Good idea.
Although this patch has been developed and tested on LP64,
it relies on there being no truncations or ex
Hi Roger,
Started a test of your latest version.
It appears we miss 64-bit patterns similar to these:
(define_insn ""
[(set (match_operand:SI 0 "register_operand" "=r")
(match_operator:SI 5 "plus_xor_ior_operator"
[(ashift:SI (match_operand:SI 1 "register_operand" "r")
On Sat, 22 Aug 2020 at 13:13, Jonathan Wakely wrote:
>
> On Sat, 22 Aug 2020 at 10:52, Marc Glisse wrote:
> > is there a particular reason to handle only __int128 this way, and not all
> > the non-standard integer types? It looks like it would be a bit simpler to
> > avoid a special case.
>
> I ha
On Sat, 22 Aug 2020 at 13:18, JeanHeyd Meneide wrote:
>
> On Sat, Aug 22, 2020 at 8:14 AM Jonathan Wakely via Gcc-patches
> wrote:
> > I really wish WG14 would just fix the intmax_t mess so we can make
> > them integral types unconditionally.
>
> We're trying, but we're struggling to reach a good
On Sat, Aug 22, 2020 at 8:14 AM Jonathan Wakely via Gcc-patches
wrote:
> I really wish WG14 would just fix the intmax_t mess so we can make
> them integral types unconditionally.
We're trying, but we're struggling to reach a good consensus. Almost
nobody's fully agreeing on one /particular/ solut
On Sat, 22 Aug 2020 at 10:52, Marc Glisse wrote:
> is there a particular reason to handle only __int128 this way, and not all
> the non-standard integer types? It looks like it would be a bit simpler to
> avoid a special case.
I have no objection to doing it for all of them, it just wasn't
necessa
Hi Jose,
Proposed patch to PR96727 - ICE with character length specified using
specification function on assumed-rank array.
Patch tested only on x86_64-pc-linux-gnu.
Add missing default error message for the assumed-rank array case.
Looks good with an adjusted ChangeLog/git commit message.
Hi Jose,
Proposed patch to PR96726 - ICE with user defined specification function
on assumed-rank array.
OK, you'll need a to work on the ChangeLog format to commit this
(like I wrote in my previous mail).
Thanks for the patch!
Regards
Thomas
On Wed, 19 Aug 2020, Jonathan Wakely via Gcc-patches wrote:
Because __int128 can be used as the difference type for iota_view, we
need to ensure that it meets the requirements of an integer-class type.
The requirements in [iterator.concept.winc] p10 include numeric_limits
being specialized and g
Hi Dave,
It's great to hear from you. It's been a long while.
Sorry, doh! yes, there's a mistake in my patch (that I introduced when I
renumbered
the operands in the shd's define_expand to be the more logical 0, 1, 2, 3,
then 4).
Sorry for the inconvenience [due to my lack of familiarity with P
David Malcolm writes:
> On Wed, 2020-08-19 at 09:24 +0200, Andrea Corallo wrote:
>> Hi all,
>>
>> just a small patch updating some comments that apparently went out of
>> sync a while ago adding gcc_jit_context_new_rvalue_from_long.
>
>> Okay for trunk?
>
> Yes
>
> Thanks for fixing these
> Dave
27 matches
Mail list logo
