On Wed, Sep 4, 2019 at 12:50 AM Uros Bizjak wrote:
>
> On Tue, Sep 3, 2019 at 1:33 PM Richard Biener
> wrote:
>
> > > > Note:
> > > > Removing limit of cost would introduce lots of regressions in SPEC2017
> > > > as follow
> > > >
> > > > 531.deepsjeng_r -7.18%
On Tue, Sep 03, 2019 at 08:52:54PM -0400, Marek Polacek wrote:
> As I recently threatened, it's time we let -fdeduce-init-list go.
> This patch removes the implementation while keeping the option for
> backward compatibility.
>
> Bootstrapped/regtested on x86_64-linux, ok for trunk?
>
>
As I recently threatened, it's time we let -fdeduce-init-list go.
This patch removes the implementation while keeping the option for
backward compatibility.
Bootstrapped/regtested on x86_64-linux, ok for trunk?
2019-09-03 Marek Polacek
* c.opt (fdeduce-init-list): Ignored.
*
If the Go frontend sees a dot-import of a package, it should only add
an imported variable to the package bindings if the variable is in the
package being imported. This patch fixes that. A test case for this
is the 1.13 os package, in which ErrClosed and friends are defined
both locally and in
On Tue, Sep 03, 2019 at 07:20:13PM -0400, Michael Meissner wrote:
> On Tue, Sep 03, 2019 at 05:56:03PM -0500, Segher Boessenkool wrote:
> > Hi!
> >
> > On Mon, Aug 26, 2019 at 05:43:41PM -0400, Michael Meissner wrote:
> > > /* This file implements a RTL pass that looks for pc-relative loads of
Hi!
On Mon, Aug 26, 2019 at 05:50:38PM -0400, Michael Meissner wrote:
> * gcc/testsuite/gcc.target/powerpc/prefix-large.h: New set of
> tests to test prefixed addressing on 'future' system with large
> numeric offsets.
In the changelog just say "New." or "New test.";
On Tue, Sep 03, 2019 at 05:56:03PM -0500, Segher Boessenkool wrote:
> Hi!
>
> On Mon, Aug 26, 2019 at 05:43:41PM -0400, Michael Meissner wrote:
> > /* This file implements a RTL pass that looks for pc-relative loads of the
> >address of an external variable using the PCREL_GOT relocation and
On Mon, Aug 26, 2019 at 05:48:08PM -0400, Michael Meissner wrote:
> This patch contains the miscellaneous tests for GCC to test some features of
> --- gcc/testsuite/gcc.target/powerpc/paddi-1.c(revision 274879)
> +++ gcc/testsuite/gcc.target/powerpc/paddi-1.c(working copy)
> @@
Hi!
On Mon, Aug 26, 2019 at 05:43:41PM -0400, Michael Meissner wrote:
> /* This file implements a RTL pass that looks for pc-relative loads of the
>address of an external variable using the PCREL_GOT relocation and a single
>load/store that uses that GOT pointer.
Does this work better
On Tue, Sep 03, 2019 at 05:06:52PM -0400, Michael Meissner wrote:
> On Fri, Aug 30, 2019 at 01:32:57PM -0500, Segher Boessenkool wrote:
> > On Mon, Aug 26, 2019 at 05:07:25PM -0400, Michael Meissner wrote:
> > > +/* By default enable support for pc-relative and numeric prefixed
> > > addressing
Hi!
On Tue, Sep 03, 2019 at 05:01:46PM -0400, Michael Meissner wrote:
> On Thu, Aug 29, 2019 at 12:02:05PM -0500, Segher Boessenkool wrote:
> > On Tue, Aug 20, 2019 at 02:00:31PM -0400, Michael Meissner wrote:
> > > The test for TARGET_VADDUQM
> > > matches a test earlier in the function where
On 8/26/19 3:00 AM, Richard Biener wrote:
> On Fri, Aug 23, 2019 at 9:19 PM Jeff Law wrote:
>>
>> On 8/22/19 4:46 AM, Richard Biener wrote:
> Also you seem to use this info to constrain optimization when you
> might remember that types of addresses do not carry such information...
>
On 9/3/19 3:00 PM, Jozef Lawrynowicz wrote:
> On Tue, 3 Sep 2019 13:37:57 -0600
> Jeff Law wrote:
>
>> On 8/30/19 4:09 AM, Jozef Lawrynowicz wrote:
>>> The attached patch adds a new target hook "TARGET_HANDLE_GENERIC_ATTRIBUTE"
>>> which enables a back end to perform additional processing of an
First constinit bug report (yay?). The problem is that while I made sure
that constinit variable templates work as they should, I clearly neglected
ordinary static variables declared constinit in function templates.
This was an ICE in cp_finish_decl when setting TINFO_VAR_DECLARED_CONSTINIT
On Fri, Aug 30, 2019 at 01:32:57PM -0500, Segher Boessenkool wrote:
> On Mon, Aug 26, 2019 at 05:07:25PM -0400, Michael Meissner wrote:
> > +/* By default enable support for pc-relative and numeric prefixed
> > addressing on
> > + the 'future' system, unless it is overriden at build time. */
>
On Thu, Aug 29, 2019 at 12:02:05PM -0500, Segher Boessenkool wrote:
> Hi!
>
> On Tue, Aug 20, 2019 at 02:00:31PM -0400, Michael Meissner wrote:
> > I
> > noticed on power5 that the V1TImode mode is allowed in Altivec registers,
> > even
> > though power5 doesn't have Altivec registers.
> >
> >
On Tue, 3 Sep 2019 13:37:57 -0600
Jeff Law wrote:
> On 8/30/19 4:09 AM, Jozef Lawrynowicz wrote:
> > The attached patch adds a new target hook "TARGET_HANDLE_GENERIC_ATTRIBUTE"
> > which enables a back end to perform additional processing of an attribute
> > that
> > is normally handled by a
Hi,
due to the introduction of unaligned_loaddi and unaligned_storedi,
two test cases show some regression as PR 91614 points out.
I would like to change the test expectations if these two test cases,
since they seem to be bogus.
That is the test case already failed for arm_prefer_ldrd_strd
On 7/29/19 9:50 AM, Jakub Jelinek wrote:
> On Tue, Jul 23, 2019 at 04:26:24AM +, JiangNing OS wrote:
>> --- a/gcc/ChangeLog
>> +++ b/gcc/ChangeLog
>> @@ -1,3 +1,9 @@
>> +2019-07-22 Jiangning Liu
>> +
>> +PR middle-end/91195
>> +* tree-ssa-phiopt.c (cond_store_replacement): Work
On 7/24/19 12:07 PM, Martin Sebor wrote:
> On 7/24/19 11:12 AM, Jeff Law wrote:
>> On 7/24/19 10:09 AM, Martin Sebor wrote:
>>> On 7/24/19 9:25 AM, Jeff Law wrote:
On 7/23/19 10:20 AM, Martin Sebor wrote:
> On 7/22/19 10:26 PM, JiangNing OS wrote:
>> This patch is to fix PR91195. Is
On 8/26/19 1:06 AM, kamlesh kumar wrote:
> 2019-08-26 Kamlesh Kumar
>
> * gcc/match.pd: Added simplification
> pattern.
> * gcc.dg/tree-ssa/pr91504.c: New test.
Thanks. I've installed this on the trunk.
jeff
This patch is a refinement of a path first submitted to this list on Nov. 10,
2018, with a revision submitted this list on Dec. 13, 2018. At the time of the
last submission, it was deemed too close to the close of GCC 9, so was not
considered at that time.
This new pass scans existing rtl
On 8/28/19 9:16 AM, Eduard-Mihai Burtescu wrote:
> Could you, or someone else, commit this for me (as I have no commit access)?
I've added this to the trunk.
Thanks,
jeff
>
> Thanks.
>
> On Mon, Aug 26, 2019, at 11:04 PM, Ian Lance Taylor wrote:
>> On Wed, Aug 14, 2019 at 10:24 AM Eduard-Mihai
On 8/28/19 3:12 PM, Martin Sebor wrote:
> On 8/22/19 3:31 PM, Jeff Law wrote:
>> On 8/20/19 8:10 PM, Martin Sebor wrote:
>>> Jeff,
>>>
>>> Please let me know if you agree/disagree and what I need to
>>> do to advance this work:
>>>
>>> https://gcc.gnu.org/ml/gcc-patches/2019-08/msg00643.html
>>
The attached patch has been tested on x86_64-*-freebsd.
I plan to commit this patch tomorrow if there are no objections.
A BOZ literal constant cannot appear in an output IO list. By
default, the patch will generate an error. The -fallow-invalid-boz
option can be used to degrade the error into
On 8/28/19 8:55 PM, Prathamesh Kulkarni wrote:
> Hi,
> This is a rebased patch on trunk for PR78736. The last time, it got
> stuck, because of warning issues with libgfortran, for which I filed
> PR91593. The patch relegates the warning to Wextra instead, which only
> triggers (non-fatal) warnings
Hi!
On Mon, Aug 26, 2019 at 05:20:12PM -0400, Michael Meissner wrote:
> @@ -3249,9 +3249,10 @@ (define_insn "vsx_vslo_"
> ;; Variable V2DI/V2DF extract
> (define_insn_and_split "vsx_extract__var"
>[(set (match_operand: 0 "gpc_reg_operand" "=v,wa,r")
> - (unspec: [(match_operand:VSX_D 1
On 8/30/19 4:14 AM, Jozef Lawrynowicz wrote:
> With the "noinit" attribute now handled generically, direct assignment of
> data with the "noinit" attribute to the ".noinit" attribute can be removed
> from
> the msp430 back end, and default_elf_select_section can be used instead.
>
>
On 8/30/19 4:11 AM, Jozef Lawrynowicz wrote:
> The attached patch removes hard-coded warnings from msp430 attribute handlers,
> and replaces them with exclusion rules specified in the attribute_spec table.
>
> Where msp430 attributes conflict with generic attributes, hard-coded warnings
> are
On 8/30/19 4:09 AM, Jozef Lawrynowicz wrote:
> The attached patch adds a new target hook "TARGET_HANDLE_GENERIC_ATTRIBUTE"
> which enables a back end to perform additional processing of an attribute that
> is normally handled by a front end.
>
> So far only the "section" and "noinit" attribute
On Tue, 3 Sep 2019, Ian Lance Taylor wrote:
> > * c-cppbuiltin.c (builtin_define_with_hex_fp_value): Always expand
> > when using -fgo-dump-spec.
>
> Ping Joseph Myers as C frontend maintainer.
This patch is OK.
--
Joseph S. Myers
jos...@codesourcery.com
On 9/3/19 2:16 AM, Mihailo Stojanovic wrote:
> From: Mihailo Stojanovic
>
> Hi everybody,
>
> This fixes the MSA implementation on big-endian targets which is
> essentially broken for things like SUBREG handling and calling
> convention for vector types. It borrows heavily from [1] as Aarch64
On 8/29/19 9:20 AM, Elen Kalda wrote:
> Hi all,
>
> Advice and help needed!
>
> This patch makes changes to the the complex division in GCC. The algorithm
> used is same as in https://gcc.gnu.org/ml/gcc-patches/2019-08/msg01629.html -
> same problems, same improvement in robustness, same loss
On 9/3/19 12:46 PM, Bernd Edlinger wrote:
> On 9/3/19 8:40 PM, Jeff Law wrote:
>> On 9/1/19 4:36 AM, Bernd Edlinger wrote:
>>> 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
On 9/3/19 8:40 PM, Jeff Law wrote:
> On 9/1/19 4:36 AM, Bernd Edlinger wrote:
>> 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.
>>
>>
On 8/30/19 3:40 AM, Jose E. Marchesi wrote:
>
> > This patch adds a port for the Linux kernel eBPF architecture to GCC.
> >
> > ChangeLog:
> >
> > * configure.ac: Support for bpf-*-* targets.
> > * configure: Regenerate.
> >
> > contrib/ChangeLog:
> >
>
On 9/1/19 4:36 AM, Bernd Edlinger wrote:
> 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
From: Shahab Vahedi
This change makes sure that if the driver is invoked with
"-mcode-density" flag, then the assembler will receive it
too.
gcc/
2019-09-03 Sahahb Vahedi
* config/arc/arc.h (ASM_SPEC): pass -mcode-density
* gcc.target/arc/code-density-flag.c: New test.
Hi Maxim,
> > Autoprefetching heuristic is enabled only for cores that support it, and
> isn't active for by default.
>
> It's enabled on most cores, including the default (generic). So we do have to
> be
> careful that this doesn't regress any other benchmarks or do worse on modern
>
On Tue, Sep 3, 2019 at 1:33 PM Richard Biener
wrote:
> > > Note:
> > > Removing limit of cost would introduce lots of regressions in SPEC2017 as
> > > follow
> > >
> > > 531.deepsjeng_r -7.18%
> > > 548.exchange_r -6.70%
> > > 557.xz_r -6.74%
> > > 508.namd_r
On 8/29/19 1: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
On 8/30/19 2:55 AM, Martin Liška wrote:
> PING^1
>
> On 8/13/19 9:49 AM, Martin Liska wrote:
>> Hi.
>>
>> I'm sending format independent changes to mklog that should
>> improve the script. It addresses couple of improvement
>> mentioned here:
>>
On Tue, Sep 3, 2019 at 9:08 AM Jakub Jelinek wrote:
>
> Hi!
>
> As mentioned in the PR, adjust_address in certain cases forces the address
> into a register. This doesn't work if there is a matching MEM, where we
> need rtx_equal_p before the splitting as well as after the splitting.
>
> The
On 03/09/2019 15:01, Kyrill Tkachov wrote:
Sorry for responding to this so late. I'm testing a rebased version of
Richard's OOL atomic patches [1] and am hitting an ICE building the
-mabi=ilp32 libgfortran multilib for aarch64-none-elf:
I thought Andreas already fixed ILP32.
Cleanup 64-bit multiplies. Combine the expanders using iterators.
Merge the signed/unsigned multiplies as well as the pre-Armv6 and Armv6
variants. Split DImode operands early into parallel sets inside the
MULL/MLAL instructions - this improves register allocation and avoids
subreg issues due to
Cleanup the various highpart multiply patterns using iterators.
As a result the signed and unsigned variants and the pre-Armv6
multiply operand constraints are all handled in a single pattern
and simple expander.
Bootstrap OK on armhf, regress passes.
ChangeLog:
2019-09-03 Wilco Dijkstra
Cleanup the 32-bit multiply patterns. Merge the pre-Armv6 with the Armv6
patterns, remove useless alternatives and order the accumulator operands
to prefer MLA Ra, Rb, Rc, Ra whenever feasible.
Bootstrap OK on armhf, regress passes.
ChangeLog:
2019-09-03 Wilco Dijkstra
*
Remove various MULS/MLAS patterns which are enabled when optimizing for
size. However the codesize gain from these patterns is so minimal that
there is no point in keeping them.
Bootstrap OK on armhf, regress passes.
ChangeLog:
2019-09-03 Wilco Dijkstra
* config/arm/arm.md
On 9/3/19 9:23 AM, Richard Biener wrote:
> On Mon, 2 Sep 2019, Barnaby Wilks wrote:
>
>> Hello,
>>
>> This patch introduces an optimization for narrowing binary and builtin
>> math operations to the smallest type when unsafe math optimizations are
>> enabled (typically -Ofast or -ffast-math).
On 9/3/19 8:01 AM, Kyrill Tkachov wrote:
> Hi all,
>
> On 9/5/18 12:48 PM, a...@codesourcery.com wrote:
>>
>> At present, pointers passed to builtin functions, including atomic
>> operators,
>> are stripped of their address space properties. This doesn't seem to be
>> deliberate, it just omits
> On 3 Sep 2019, at 15:52, Jeff Law wrote:
>
> On 9/1/19 12:43 PM, Iain Sandoe wrote:
>> 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.
>>
>>
On 9/1/19 12:43 PM, Iain Sandoe wrote:
> 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,
On Tue, Aug 20, 2019 at 4:36 PM Ian Lance Taylor wrote:
>
> On Mon, Aug 12, 2019 at 8:21 PM Xiangdong JI wrote:
> >
> > The .go files generated during building gccgo seem to have a few constants
> > with weird values, for example:
> >
> > // sysinfo.go (on x86-64, latest gcc-9 trunk)
> >
> >
Richard Biener writes:
> On Mon, 2 Sep 2019, Barnaby Wilks wrote:
>
>> Hello,
>>
>> This patch introduces an optimization for narrowing binary and builtin
>> math operations to the smallest type when unsafe math optimizations are
>> enabled (typically -Ofast or -ffast-math).
>>
>> Consider the
On 9/2/19 2:16 PM, Ulrich Weigand wrote:
> Hello,
>
> as announced here: https://gcc.gnu.org/ml/gcc/2019-04/msg00023.html
> we have declared the spu-elf target obsolete in GCC 9 with the goal
> of removing support in GCC 10. Nobody has stepped up to take over
> maintainership of the target.
>
>
On 2019/8/14 1:16 AM, Joseph Myers wrote:
On Thu, 4 Jul 2019, Chung-Lin Tang wrote:
Bringing back this issue, as this is still bothering our OpenACC toolchains.
If the main variance in format was the 2007 ' ' to '.' change for non-release
binutils builds, then is the attached patch okay?
Hi all,
On 9/5/18 12:48 PM, a...@codesourcery.com wrote:
At present, pointers passed to builtin functions, including atomic
operators,
are stripped of their address space properties. This doesn't seem to be
deliberate, it just omits to copy them.
Not only that, but it forces pointer sizes
Richard Biener writes:
> On Mon, 2 Sep 2019, Richard Sandiford wrote:
>
>> Richard Biener writes:
>> > This disables postreload GCSE the same way we disable GCSE/cprop.
>> > On the PR36262 testcase this removes
>> >
>> > load CSE after reload : 129.00 ( 72%) 0.08 ( 5%) 130.50 (
On 9/3/19 7:13 AM, Richard Biener wrote:
> On Tue, 3 Sep 2019, Richard Biener wrote:
>
>> On Tue, 3 Sep 2019, Bernd Edlinger wrote:
>>
>>> On 9/3/19 1:12 PM, Richard Biener wrote:
On Tue, 3 Sep 2019, Bernd Edlinger wrote:
> On 9/3/19 9:05 AM, Jakub Jelinek wrote:
>> On Tue, Sep
On 30/08/19 19:42 -0400, JeanHeyd Meneide wrote:
Ahem -- we were supposed to use the 20 version of the constexpr macro,
not the base one.
I will note that, for some reason, the default constructor was already
constexpr, so we don't change that one!
Thanks!
I've done a thorough review now,
On Tue, 3 Sep 2019, Richard Biener wrote:
> On Tue, 3 Sep 2019, Bernd Edlinger wrote:
>
> > On 9/3/19 1:12 PM, Richard Biener wrote:
> > > On Tue, 3 Sep 2019, Bernd Edlinger wrote:
> > >
> > >> On 9/3/19 9:05 AM, Jakub Jelinek wrote:
> > >>> On Tue, Sep 03, 2019 at 07:02:53AM +, Bernd
On Tue, 3 Sep 2019, Bernd Edlinger wrote:
> On 9/3/19 1:12 PM, Richard Biener wrote:
> > On Tue, 3 Sep 2019, Bernd Edlinger wrote:
> >
> >> On 9/3/19 9:05 AM, Jakub Jelinek wrote:
> >>> On Tue, Sep 03, 2019 at 07:02:53AM +, Bernd Edlinger wrote:
> 2019-09-03 Bernd Edlinger
>
>
Richard Biener wrote:
> On Tue, Sep 3, 2019 at 1:56 PM Ulrich Weigand wrote:
> > combined with the fact that get_object_alignment_2 actually itself
> > uses type alignment if we have an actual memory object:
> > /* When EXP is an actual memory reference then we can use
> >
On 9/3/19 1:12 PM, Richard Biener wrote:
> On Tue, 3 Sep 2019, Bernd Edlinger wrote:
>
>> On 9/3/19 9:05 AM, Jakub Jelinek wrote:
>>> On Tue, Sep 03, 2019 at 07:02:53AM +, Bernd Edlinger wrote:
2019-09-03 Bernd Edlinger
PR middle-end/91603
PR middle-end/91612
On Tue, Sep 3, 2019 at 1:56 PM Ulrich Weigand wrote:
>
> Richard Biener wrote:
> > On Mon, Sep 2, 2019 at 10:35 PM Ulrich Weigand wrote:
> > > Now one question might be, why does get_pointer_alignment not take
> > > type alignment into account by itself? This appears to be deliberate
> > > to
Richard Biener wrote:
> On Mon, Sep 2, 2019 at 10:35 PM Ulrich Weigand wrote:
> > Now one question might be, why does get_pointer_alignment not take
> > type alignment into account by itself? This appears to be deliberate
> > to avoid considering numeric pointer values to be aligned when they
>
On Mon, 2 Sep 2019, Richard Sandiford wrote:
> Richard Biener writes:
> > This disables postreload GCSE the same way we disable GCSE/cprop.
> > On the PR36262 testcase this removes
> >
> > load CSE after reload : 129.00 ( 72%) 0.08 ( 5%) 130.50 (
> > 72%) 6 kB ( 0%)
> >
On Tue, Sep 3, 2019 at 1:24 PM Richard Biener
wrote:
>
> On Tue, Sep 3, 2019 at 9:57 AM Hongtao Liu wrote:
> >
> > On Mon, Sep 2, 2019 at 4:41 PM Uros Bizjak wrote:
> > >
> > > On Mon, Sep 2, 2019 at 10:13 AM Hongtao Liu wrote:
> > > >
> > > > > which is not the case with core_cost (and
On Tue, Sep 3, 2019 at 12:34 PM Ilya Leoshkevich wrote:
>
> > Am 03.09.2019 um 12:07 schrieb Richard Biener :
> >
> > On Mon, Sep 2, 2019 at 6:28 PM Ilya Leoshkevich wrote:
> >>
> >>> Am 02.09.2019 um 12:37 schrieb Richard Biener
> >>> :
> >>>
> >>> On Fri, Aug 30, 2019 at 5:25 PM Ilya
On Tue, Sep 3, 2019 at 9:57 AM Hongtao Liu wrote:
>
> On Mon, Sep 2, 2019 at 4:41 PM Uros Bizjak wrote:
> >
> > On Mon, Sep 2, 2019 at 10:13 AM Hongtao Liu wrote:
> > >
> > > > which is not the case with core_cost (and similar with skylake_cost):
> > > >
> > > > 2, 2, 4,/*
Hi Shaokun,
On 9/3/19 9:35 AM, Shaokun Zhang wrote:
The DCache clean & ICache invalidation requirements for instructions
to be data coherence are discoverable through new fields in CTR_EL0.
Let's support the two bits if they are enabled, the CPU core will
not execute the unnecessary DCache
On Tue, 3 Sep 2019, Bernd Edlinger wrote:
> On 9/3/19 9:05 AM, Jakub Jelinek wrote:
> > On Tue, Sep 03, 2019 at 07:02:53AM +, Bernd Edlinger wrote:
> >> 2019-09-03 Bernd Edlinger
> >>
> >>PR middle-end/91603
> >>PR middle-end/91612
> >>PR middle-end/91613
> >>* expr.c
On Mon, Sep 2, 2019 at 10:35 PM Ulrich Weigand wrote:
>
> Hello,
>
> on s390x the 128-bit integer type is only aligned to 8 bytes by default,
> but when lock-free atomic operations can only be performed on objects
> aligned to 16 bytes. However, we've noticed that GCC sometimes falls
> back to
> Am 03.09.2019 um 12:07 schrieb Richard Biener :
>
> On Mon, Sep 2, 2019 at 6:28 PM Ilya Leoshkevich wrote:
>>
>>> Am 02.09.2019 um 12:37 schrieb Richard Biener :
>>>
>>> On Fri, Aug 30, 2019 at 5:25 PM Ilya Leoshkevich wrote:
> Am 30.08.2019 um 16:40 schrieb Ilya Leoshkevich :
I am testing the following.
Richard.
2019-09-03 Richard Biener
* tree-ssa-sccvn.h (vn_nary_op_lookup): Remove.
(vn_nary_op_insert): Likewise.
* tree-ssa-sccvn.c (init_vn_nary_op_from_op): Remove.
(vn_nary_op_lookup): Likewise.
(vn_nary_op_insert):
On Mon, Sep 2, 2019 at 6:28 PM Ilya Leoshkevich wrote:
>
> > Am 02.09.2019 um 12:37 schrieb Richard Biener :
> >
> > On Fri, Aug 30, 2019 at 5:25 PM Ilya Leoshkevich wrote:
> >>
> >>> Am 30.08.2019 um 16:40 schrieb Ilya Leoshkevich :
> >>>
> Am 30.08.2019 um 09:12 schrieb Richard Biener
>
Christophe Lyon writes:
> @@ -3485,6 +3485,14 @@ arm_option_override (void)
>if (flag_pic && TARGET_VXWORKS_RTP)
> arm_pic_register = 9;
>
> + /* If in FDPIC mode then force arm_pic_register to be r9. */
> + if (TARGET_FDPIC)
> +{
> + arm_pic_register = FDPIC_REGNUM;
> +
The DCache clean & ICache invalidation requirements for instructions
to be data coherence are discoverable through new fields in CTR_EL0.
Let's support the two bits if they are enabled, the CPU core will
not execute the unnecessary DCache clean or Icache Invalidation
instructions.
2019-09-03
Hi James,
On 9/2/19 6:30 PM, James Greenhalgh wrote:
On Thu, Aug 22, 2019 at 12:03:33PM +0100, Kyrill Tkachov wrote:
Hi Dennis,
On 8/21/19 10:27 AM, Dennis Zhang wrote:
Hi all,
This patch adds '-mcpu' options for following CPUs:
Cortex-A77, Cortex-A76AE, Cortex-A65, Cortex-A65AE, and
On Mon, 2 Sep 2019, Barnaby Wilks wrote:
> Hello,
>
> This patch introduces an optimization for narrowing binary and builtin
> math operations to the smallest type when unsafe math optimizations are
> enabled (typically -Ofast or -ffast-math).
>
> Consider the example:
>
>float f (float x)
From: Mihailo Stojanovic
Hi everybody,
This fixes the MSA implementation on big-endian targets which is
essentially broken for things like SUBREG handling and calling
convention for vector types. It borrows heavily from [1] as Aarch64 has
the same problem with SVE vectors.
Conceptually,
On Tue, 3 Sep 2019 at 08:10, Bernd Edlinger wrote:
>
> Hi,
>
>
> I've noticed that testing libphobos fails for multi-lib configs:
>
> $ make check-target-libphobos RUNTESTFLAGS="--target_board=unix\{-m32,\}"
>
> fails for every 32bit execution, because the host libgcc_s.so is used which
> is not
On Mon, Sep 2, 2019 at 4:41 PM Uros Bizjak wrote:
>
> On Mon, Sep 2, 2019 at 10:13 AM Hongtao Liu wrote:
> >
> > > which is not the case with core_cost (and similar with skylake_cost):
> > >
> > > 2, 2, 4,/* cost of moving XMM,YMM,ZMM register */
> > > {6, 6, 6, 6, 12},
On Tue, 3 Sep 2019, Jakub Jelinek wrote:
> Hi!
>
> As discussed in the PR, this optimization introduced in r161707
> is invalid, even when neither of the vrs include NULL, the result
> can still be NULL. While for usual uses (where the second argument
> is INTEGER_CST with all bits set except a
Hi Kyrill,
On 2019/9/2 22:31, Kyrill Tkachov wrote:
> Hi Shaokun
>
> On 8/31/19 8:12 AM, Shaokun Zhang wrote:
>> The DCache clean & ICache invalidation requirements for instructions
>> to be data coherence are discoverable through new fields in CTR_EL0.
>> Let's support the two bits if they are
Hi Kyrill,
On 2019/9/2 22:24, Kyrill Tkachov wrote:
> Hi Shaokun,
>
> On 8/31/19 8:12 AM, Shaokun Zhang wrote:
>> The DCache clean & ICache invalidation requirements for instructions
>> to be data coherence are discoverable through new fields in CTR_EL0.
>> Let's support the two bits if they are
Hi!
As discussed in the PR, this optimization introduced in r161707
is invalid, even when neither of the vrs include NULL, the result
can still be NULL. While for usual uses (where the second argument
is INTEGER_CST with all bits set except a few last ones and first argument
is a pointer to real
On 9/3/19 9:05 AM, Jakub Jelinek wrote:
> On Tue, Sep 03, 2019 at 07:02:53AM +, Bernd Edlinger wrote:
>> 2019-09-03 Bernd Edlinger
>>
>> PR middle-end/91603
>> PR middle-end/91612
>> PR middle-end/91613
>> * expr.c (expand_expr_real_1): decl_p_1): Refactor into...
>>
Hi!
As mentioned in the PR, adjust_address in certain cases forces the address
into a register. This doesn't work if there is a matching MEM, where we
need rtx_equal_p before the splitting as well as after the splitting.
The following patch fixes that by checking for the matching MEM (looks
On Tue, Sep 03, 2019 at 07:02:53AM +, Bernd Edlinger wrote:
> 2019-09-03 Bernd Edlinger
>
> PR middle-end/91603
> PR middle-end/91612
> PR middle-end/91613
> * expr.c (expand_expr_real_1): decl_p_1): Refactor into...
> (non_mem_decl_p): ...this.
>
Hi,
this fixes two bugs, one is also a wrong-code bug that turned into an ICE due
to the middle-end sanitation (PR 91603/91612). The other is just an assertion
due to expand_expr_real_1 setting byte-aligned mem_attributes of a SSA_NAME
referring to a CONSTANT_P which is actually 16-byte aligned,
On Fri, 2 Aug 2019, Marc Glisse wrote:
Ping
On Tue, 16 Jul 2019, Marc Glisse wrote:
Adding a C++ maintainer in Cc:
https://gcc.gnu.org/ml/gcc-patches/2019-07/msg00808.html
On Wed, 10 Jul 2019, Marc Glisse wrote:
Hello,
this avoids folding __builtin_constant_p to 0 early when we are not
Hi,
I've noticed that testing libphobos fails for multi-lib configs:
$ make check-target-libphobos RUNTESTFLAGS="--target_board=unix\{-m32,\}"
fails for every 32bit execution, because the host libgcc_s.so is used which
is not the correct version:
spawn [open ...]
./test_aa.exe:
93 matches
Mail list logo
