On May 19, 2020, Alexandre Oliva wrote:
> - fix a build problem when targeting platforms with an executable suffix
aux and dump revamp: fix target exec suffix handling
HAVE_TARGET_EXECUTABLE_SUFFIX is defined only in gcc.c, and in a way
that requires testing whether it's defined, rather than fo
On May 19, 2020, Alexandre Oliva wrote:
> - fix spurious outputs.exp test failures on targets that do not support
> -gsplit-dwarf
cope with -gsplit-dwarf errors
From: Alexandre Oliva
On targets that did not support -gsplit-dwarf, we'd get tons of
spurious failures. This patch tests for sup
On Tue, May 19, 2020 at 10:48 AM Richard Biener wrote:
>
> On Tue, 19 May 2020, Uros Bizjak wrote:
>
> > Hello!
> >
> > Attached patch adds missing vector zero/sign_extend expanders to allow
> > vectorization of operations between different vector sizes.
> >
> > The patch regresses (progresses?):
On 5/19/20 10:23 AM, Jakub Jelinek wrote:
On Tue, May 19, 2020 at 10:11:28AM +0200, Martin Liška wrote:
I find this format more helpful for the reasons below so unless your
script can be tweaked to do something similar I'd like to be able to
continue to use mine going forward with the new infras
On 5/19/20 10:11 AM, Martin Liška wrote:
Can you please share how do you do it? It would be easy to add it.
I added the feature via --fill-up-bug-titles option. It uses common
request and beatifulsoup packages.
Martin
>From 5450c99b54131d1942ece3ffb6bbe415b1c85151 Mon Sep 17 00:00:00 2001
From
I've refreshed the patch, approved back on Jan 22 for gcc-11, in
refs/users/aoliva/heads/aux-dump-revamp, and committed 3 other related
patches on top of it, that I hope to get approved for folding and joint
installation:
- fix a build problem when targeting platforms with an executable suffix
-
On Sun, May 17, 2020 at 7:06 PM H.J. Lu wrote:
>
> Duplicate the cmpstrn pattern for cmpmem. The only difference is that
> the length argument of cmpmem is guaranteed to be less than or equal to
> lengths of 2 memory areas. Since "repz cmpsb" can be much slower than
> memcmp function implemented
On Tue, 19 May 2020, Uros Bizjak wrote:
> Hello!
>
> Attached patch adds missing vector zero/sign_extend expanders to allow
> vectorization of operations between different vector sizes.
>
> The patch regresses (progresses?):
>
> FAIL: gcc.target/i386/pr92645-4.c scan-tree-dump-times optimized
>
Hi Thomas,
Thomas Schwinge writes:
> I can't formally approve testsuite patches, but did a review anyway:
Thanks for the review!
> On 2020-05-15T12:31:54+0200, Frederik Harwath
> wrote:
>> The dump
>> scanning procedures are changed to make the test unresolved
>> if globbing matches more th
Hi!
This patch adds very basic allocator support (omp_{init,destroy}_allocator,
omp_{alloc,free}, omp_[sg]et_default_allocator).
The plan is to use memkind (likely dlopened) for high bandwidth memory, but
that part isn't implemented yet, probably mlock for pinned memory and see
what other options
On Tue, May 19, 2020 at 10:11:28AM +0200, Martin Liška wrote:
> > I find this format more helpful for the reasons below so unless your
> > script can be tweaked to do something similar I'd like to be able to
> > continue to use mine going forward with the new infrastructure.
>
> Let's extend the c
On 5/15/20 5:06 PM, Martin Sebor wrote:
On 5/15/20 2:59 AM, Martin Liška wrote:
Hi.
Since we moved to git world and we're in the preparation for ChangeLog messages
being in git commit messages, I think it's the right time to also simplify mklog
script.
I'm sending a new version (which should e
Am 18.05.20 um 09:35 schrieb Mark Eggleston:
> Please find attached a patch for PR39695 (this time it is attached).
>
> Commit message:
>
> Fortran : ProcPtr function results: 'ppr@' in error message PR39695
>
> The value 'ppr@' is set in the name of result symbol, the actual
> name of the symbol
Messed up the e-mail addressed, gcc-patches now added.
Also, I note that I missed the PR fortran/50392 which should be inserted
at the start of the change log entries.
On 19/05/2020 08:49, Mark Eggleston wrote:
Please find attached patch for PR50392.
This patch was extracted from the comment
Hello!
Attached patch adds missing vector zero/sign_extend expanders to allow
vectorization of operations between different vector sizes.
The patch regresses (progresses?):
FAIL: gcc.target/i386/pr92645-4.c scan-tree-dump-times optimized
"vec_unpack_lo" 3
but eyeballing the asm code before/afte
On Mon, 18 May 2020, Richard Sandiford wrote:
> Richard Biener writes:
> > Hi,
> >
> > I'm trying to enforce SLP_TREE_VECTYPE being set (correctly) on
> > external and invariant SLP nodes to avoid (re-)computing that
> > in other places.
>
> Nice.
>
> > The responsible entity for specifying the
On Mon, May 18, 2020 at 8:21 PM Aldy Hernandez via Gcc-patches
wrote:
>
> As a follow-up to the patch moving array bounds checking into its own
> class, this moves the class into its own files. As I've mentioned
> previously, having it in tree-vrp just pollutes the file with unrelated
> stuff.
>
On Mon, May 18, 2020 at 8:13 PM Aldy Hernandez via Gcc-patches
wrote:
>
> We already moved the value_range class into its own class in the last
> release. I think it's time to move the value_range_equiv stuff into its
> own class, as it's a distraction from the VRP code.
>
> I've moved it to valu
101 - 118 of 118 matches
Mail list logo
