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?
>
> 2019-09-0
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 t
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 the
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."; explanation
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 a
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)
> @@ -0,0
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 tha
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 on
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 VSX
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...
> Th
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 a
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
becau
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.
> >
> > W
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 fro
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 targ
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 aroun
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 it
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 expr
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 B
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 a
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.
>
> default_elf_s
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 stil
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 mak
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 ha
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 wh
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 x86_64-pc-l
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.
Signe
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
> cores
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 r
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:
>> https://gcc.gnu.org/ml/gcc-patches/2019-08/msg00031.
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 foll
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.
https://gcc.gnu.o
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
* config/arm/a
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 (mulsi3_co
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 to
> 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, {x86-64,powerp
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)
> >
> > con
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 e
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?
What
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 t
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 0
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, lots
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 Edling
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
> > TYPE_ALIG
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 av
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 similar
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 Leoshkevi
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,/* cost
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 clean
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 (expan
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 li
> 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): Lik
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 Shao
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 Cortex-
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, registe
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 t
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 e
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 just
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.
> (mem_re
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,
91 matches
Mail list logo
