This moves a recursion limit installed for PR80887 from
vn_lookup_simplify_result to gimple_resimplify* where it also applies
to a testcase I'm running into with modified VN without ever
calling vn_lookup_simplify_result. Basically with VN we are
not presenting the match.pd patterns with simpli
The following fixes fold_binary_op_with_conditional_arg to not move
a possibly trapping operation into the conditional arms because
this breaks later re-gimplification and also because we lose
information this way (like dividend is nonzero on the unconditional path).
Bootstrapped and tested on x
On Thu, 12 Jul 2018, Jakub Jelinek wrote:
> Hi!
>
> The following testcase is a similar issue to PR84503 and the fix is similar,
> because coalesce_immediate_stores temporarily sorts the stores on ascending
> bitpos and if stores are merged, the merged store is emitted in the location
> of the la
On 07/11/2018 01:33 PM, Richard Sandiford wrote:
Aldy Hernandez writes:
On 07/11/2018 08:52 AM, Richard Biener wrote:
On Wed, Jul 11, 2018 at 8:48 AM Aldy Hernandez wrote:
Hmmm, I think we can do better, and since this hasn't been reviewed yet,
I don't think anyone will mind the adjustment
Aldy Hernandez writes:
> On 07/11/2018 01:33 PM, Richard Sandiford wrote:
>> Aldy Hernandez writes:
>>> On 07/11/2018 08:52 AM, Richard Biener wrote:
On Wed, Jul 11, 2018 at 8:48 AM Aldy Hernandez wrote:
>
> Hmmm, I think we can do better, and since this hasn't been reviewed yet,
>>
On 07/12/2018 04:29 AM, Richard Sandiford wrote:
Aldy Hernandez writes:
On 07/11/2018 01:33 PM, Richard Sandiford wrote:
Aldy Hernandez writes:
On 07/11/2018 08:52 AM, Richard Biener wrote:
On Wed, Jul 11, 2018 at 8:48 AM Aldy Hernandez wrote:
Hmmm, I think we can do better, and since
Hi,
It can be useful to print the number of tests in each category, eg:
Tests that now work, but didn't before (65 tests):
instead of
Tests that now work, but didn't before:
This small patch does that.
OK?
Thanks,
Christophe
contrib/ChangeLog:
2018-07-12 Christophe Lyon
* compare_
On Wed, 11 Jul 2018, Martin Sebor wrote:
> The attached change set adjusts the attribute exclusion code
> to detect and reject incompatible attributes before attribute
> handlers are called to have a chance to make changes despite
> the exclusions. The handlers are not run when a conflict is
> fo
Hi,
the below resolves the bug report and its duplicates by implementing -
in a rather straightforward way, I believe - the resolution of DR 136,
which also made into C++17. Note that in the patch I used permerror
instead of a plain error for consistency with the other check
(check_redeclarat
Hi Jackson
On 11/07/18 17:48, Jackson Woodruff wrote:
Hi Sudi,
Thanks for the review.
On 07/10/2018 10:56 AM, Sudakshina wrote:
Hi Jackson
- if (!MEM_P (mem_1) || aarch64_mem_pair_operand (mem_1, mode))
+ if (!MEM_P (mem[1]) || aarch64_mem_pair_operand (mem[1], mode))
mem_1 == mem[1]?
Hi Jackson
On 11/07/18 17:48, Jackson Woodruff wrote:
Hi Sudi,
On 07/10/2018 02:29 PM, Sudakshina Das wrote:
Hi Jackson
On Tuesday 10 July 2018 09:37 AM, Jackson Woodruff wrote:
Hi all,
This patch resolves PR86014. It does so by noticing that the last
load may clobber the address registe
On Thu, 12 Jul 2018, Richard Biener wrote:
>
> This moves a recursion limit installed for PR80887 from
> vn_lookup_simplify_result to gimple_resimplify* where it also applies
> to a testcase I'm running into with modified VN without ever
> calling vn_lookup_simplify_result. Basically with VN we
Looks good to me FWIW (not a maintainer), just a minor formatting thing:
Matthew Malcomson writes:
> diff --git a/gcc/config/aarch64/aarch64-simd.md
> b/gcc/config/aarch64/aarch64-simd.md
> index
> aac5fa146ed8dde4507a0eb4ad6a07ce78d2f0cd..67b29cbe2cad91e031ee23be656ec61a403f2cf9
> 100644
> --
On 07/11/2018 05:40 PM, Robin Dapp wrote:
Hi,
the following patch increases the default function alignment to 16
bytes. This helps get rid of some unwanted performance effects.
I'm unsure whether or when it's necessary to implement
OVERRIDE_OPTIONS_AFTER_CHANGE.
Hi.
Yes, it's how that shoul
After my PR86413 fix to always annotate existing lexical block DIEs with
range attributes debuginfo grows significantly in case we previously
had "stale" lexical block DIEs without any variables.
The following fixes this by eliding those comletely and not emitting
a lexical block DIE for blocks
On 11/07/18 17:48, Jackson Woodruff wrote:
> Hi Sudi,
>
> Thanks for the review.
>
>
> On 07/10/2018 10:56 AM, Sudakshina wrote:
>> Hi Jackson
>>
>>
>> - if (!MEM_P (mem_1) || aarch64_mem_pair_operand (mem_1, mode))
>> + if (!MEM_P (mem[1]) || aarch64_mem_pair_operand (mem[1], mode))
>>
>> mem
On Thu, Jul 12, 2018 at 12:29:20PM +0200, Richard Biener wrote:
> After my PR86413 fix to always annotate existing lexical block DIEs with
> range attributes debuginfo grows significantly in case we previously
> had "stale" lexical block DIEs without any variables.
>
> The following fixes this by
Hi Matthew
On 12/07/18 11:18, Richard Sandiford wrote:
Looks good to me FWIW (not a maintainer), just a minor formatting thing:
Matthew Malcomson writes:
diff --git a/gcc/config/aarch64/aarch64-simd.md
b/gcc/config/aarch64/aarch64-simd.md
index
aac5fa146ed8dde4507a0eb4ad6a07ce78d2f0cd..67b2
Hi,
this is another field that I believe needs no streaming. I however think we
are pretty
much done with low hanging fruit.
lto-bootstrapped/regtested x86_64-linux, OK?
Honza
* lto-streamer-out.c (DFS::DFS_write_tree_body): Do not stream
DECL_FCONTEXT
(hash_tree): Do n
On Thu, 12 Jul 2018, Jakub Jelinek wrote:
> On Thu, Jul 12, 2018 at 12:29:20PM +0200, Richard Biener wrote:
> > After my PR86413 fix to always annotate existing lexical block DIEs with
> > range attributes debuginfo grows significantly in case we previously
> > had "stale" lexical block DIEs witho
On Thu, 12 Jul 2018, Jan Hubicka wrote:
> Hi,
> this is another field that I believe needs no streaming. I however think we
> are pretty
> much done with low hanging fruit.
>
> lto-bootstrapped/regtested x86_64-linux, OK?
OK.
Thanks,
Richard.
> Honza
>
> * lto-streamer-out.c (DFS::DFS
On Thu, Jul 12, 2018 at 01:01:14PM +0200, Richard Biener wrote:
> No, I don't think so. OK, I'll remove the loop over
> BLOCK_NON_LOCALIZED_VAR and keep the original check for it.
>
> I also simplified stuff by hoisting the TREE_USED and friends checks.
>
> Bootstrap & regtest running on x86_64
Hi Janus,
> after the dust of the heated discussion around this PR has settled a
> bit, here is another attempt to implement at least some basic warnings
> about compiler-dependent behavior concerning the short-circuiting of
> logical expressions. …
IMO your patch is missing the only point I agre
= x.u;
instead. As the testcase is sufficiently different from PR85698
testcase, I've committed this one too to trunk.
2018-07-12 Jakub Jelinek
* gcc.dg/torture/20180712-1.c: New test.
--- gcc/testsuite/gcc.dg/torture/20180712-1.c.jj2018-07-12
13:14:46.513068757 +02
Hi,
> Please skip '+ && !opts->x_optimize_size)'. I'm attaching patch
> that will
> set opts->x_flag_align_functions to 0 for -Os. It's part of another batch
> alignment patches I'm preparing.
done in the attached version and added some tests (which do not all fail
without the patch as we ca
On Wed, Jul 04, 2018 at 09:41:17AM +0200, Richard Biener wrote:
>
> The following removes adding -lieee to the link command when -mieee-fp
> is specified for GNU targets as suggested by Joseph in the PR. It doesn't
> touch m32r so the fix may be incomplete depending on the C library used.
>
> I'
Richard Biener writes:
> On Thu, May 24, 2018 at 2:08 PM Richard Sandiford <
> richard.sandif...@linaro.org> wrote:
>
>> This patch adds conditional equivalents of the IFN_FMA built-in functions.
>> Most of it is just a mechanical extension of the binary stuff.
>
>> Tested on aarch64-linux-gnu (wi
Hi,
this patch adds dump file for WPA streaming process. It uses the new
dump file code for parittions.
Bootstrapped/regtsted x86_64-linux, will commit it shortly.
Honza
* lto.c (do_stream_out): Add PART parameter; open dump file.
(stream_out): Add PART parameter; pass it to do_s
Hi Dominique,
thanks for the comments.
>> after the dust of the heated discussion around this PR has settled a
>> bit, here is another attempt to implement at least some basic warnings
>> about compiler-dependent behavior concerning the short-circuiting of
>> logical expressions. …
>
> IMO your p
Hi,
I've had this in my patch stack after discovering the gas issue where we
weren't warning on cases that were unpredictable according to the
architecture.
I would like to backport this fix to earlier GCC branches too. I did a
few attempts but I haven't been able to trigger the unpredictable be
> Le 12 juil. 2018 à 16:12, Janus Weil a écrit :
>
> Hi Dominique,
>
> thanks for the comments.
>
>>> after the dust of the heated discussion around this PR has settled a
>>> bit, here is another attempt to implement at least some basic warnings
>>> about compiler-dependent behavior concerni
ping.
On Fri, Jul 6, 2018 at 4:38 PM Kito Cheng wrote:
>
> Hi all:
>
> This patch implemented TARGET_MERGE_DECL_ATTRIBUTES hook to check the
> interrupter is all compatible, tested with rv32ima and rv64ima elf
> toolchain.
>
> gcc/ChangeLog
> 2018-07-06 Kito Cheng
>
> * config/riscv/ris
2018-07-12 16:35 GMT+02:00 Dominique d'Humières :
>
after the dust of the heated discussion around this PR has settled a
bit, here is another attempt to implement at least some basic warnings
about compiler-dependent behavior concerning the short-circuiting of
logical expression
On 12/07/18 15:22, Ramana Radhakrishnan wrote:
> Hi,
>
>
> I've had this in my patch stack after discovering the gas issue where we
> weren't warning on cases that were unpredictable according to the
> architecture.
>
> I would like to backport this fix to earlier GCC branches too. I did a
> few
On 07/08/2018 12:35 AM, Eric Botcazou wrote:
I haven't tried looking at the failures yet, and might not spend much
more time on this. Two of them are debug related, and debug support
is a work in progress. I need to finish the native riscv64-linux
support before we can do anything useful there,
On 11/07/18 17:48, Jackson Woodruff wrote:
> Hi Sudi,
>
> On 07/10/2018 02:29 PM, Sudakshina Das wrote:
>> Hi Jackson
>>
>>
>> On Tuesday 10 July 2018 09:37 AM, Jackson Woodruff wrote:
>>> Hi all,
>>>
>>> This patch resolves PR86014. It does so by noticing that the last
>>> load may clobber the a
Status
==
The GCC 8 branch is open for regression and documentation fixes. We
intend to release GCC 8.2 soon starting with a release candidate
mid to end of next week. This gives you some time to go over your
assigned regression bug reports and consider backports.
There is currently one P
On 07/12/2018 02:41 AM, Christophe Lyon wrote:
> Hi,
>
> It can be useful to print the number of tests in each category, eg:
> Tests that now work, but didn't before (65 tests):
> instead of
> Tests that now work, but didn't before:
>
> This small patch does that.
>
> OK?
>
> Thanks,
>
> Chris
On 07/11/2018 06:20 PM, Paul Koning wrote:
> This patch removes the obsolete documentation for
> decrement_and_branch_until_zero. It also adds detail to the description for
> doloop_end. In particular, it describes the required form of the conditional
> branch part of the pattern.
>
> Ok for
y fails on x86
trunk (gcc version 9.0.0 20180712 (experimental) (GCC))
on -O1 and above.
Thanks
Sudi
diff --git a/gcc/config/aarch64/aarch64.h b/gcc/config/aarch64/aarch64.h
index f284e74..9792d28 100644
--- a/gcc/config/aarch64/aarch64.h
+++ b/gcc/config/aarch64/aarch64.h
@@ -473,7 +473,
On 07/11/2018 04:03 PM, Qing Zhao wrote:
> Hi, This is the 3rd version of the patch for the last part of PR78809.
>
> the major change in this version is to address the following concerns raised
> by Martin:
>
>> One of the basic design principles that I myself have
>> accidentally violated in
On 07/11/2018 07:11 AM, Richard Biener wrote:
>
> The following fixes PR86452 by using scope_die_for which correctly
> deals with -g1 in not creating (new) DIEs for namespaces. With
> a larger LTO testcase we run into this with a namespace DIE not
> readily available but I'm not sure the issue is
> On Jul 12, 2018, at 12:55 PM, Jeff Law wrote:
>
> On 07/11/2018 06:20 PM, Paul Koning wrote:
>> This patch removes the obsolete documentation for
>> decrement_and_branch_until_zero. It also adds detail to the description for
>> doloop_end. In particular, it describes the required form of
On 07/06/2018 06:08 AM, Christophe Lyon wrote:
> Hi Jeff,
>
> On Fri, 6 Jul 2018 at 05:44, Jeff Law wrote:
>>
>> As noted in BZ 86010 we can be more aggressive when trimming tails of
>> mem* or str* calls in gimple DSE since trimming a tail doesn't affect
>> alignment and residuals are usually ha
Hi Jeff,
Thanks for the review!
The 07/11/2018 18:30, Jeff Law wrote:
> On 07/11/2018 05:20 AM, Tamar Christina wrote:
> > Hi All,
> >
> > This patch implements the use of the stack clash mitigation for aarch64.
> > In Aarch64 we expect both the probing interval and the guard size to be 64KB
> >
On 07/12/2018 11:17 AM, Paul Koning wrote:
>
>
>> On Jul 12, 2018, at 12:55 PM, Jeff Law wrote:
>>
>> On 07/11/2018 06:20 PM, Paul Koning wrote:
>>> This patch removes the obsolete documentation for
>>> decrement_and_branch_until_zero. It also adds detail to the
>>> description for doloop_end.
Hi Jeff,
The 07/11/2018 20:21, Jeff Law wrote:
> On 07/11/2018 05:22 AM, Tamar Christina wrote:
> > Hi All,
> >
> > This patch defines a configure option to allow the setting of the default
> > guard size via configure flags when building the target.
> >
> > The new flag is:
> >
> > * --with-s
Hi!
On Tue, Jul 10, 2018 at 12:10:51PM -0500, Will Schmidt wrote:
> Add support for Gimple folding for unaligned vector loads and stores.
This is fine if the experts agree. Thanks! And thanks to the reviewers,
too.
One detail:
> * config/rs6000/rs6000.c (rs6000_builtin_valid_without_lhs
> On Jul 12, 2018, at 1:42 PM, Jeff Law wrote:
>
> On 07/12/2018 11:17 AM, Paul Koning wrote:
>>
>>
>>> On Jul 12, 2018, at 12:55 PM, Jeff Law wrote:
>>>
>>> On 07/11/2018 06:20 PM, Paul Koning wrote:
This patch removes the obsolete documentation for
decrement_and_branch_until_ze
This fixes a typo in the output of a ".set" directive.
Committed.
paul
ChangeLog:
2018-07-12 Paul Koning
* config/pdp11/pdp11.c (pdp11_output_def): Fix typo in .set
directive.
Index: config/pdp11/pdp11.c
==
Hi!
As the following testcases show, diagnosing non-mappable type already in
c*_decl_attributes is too early, the type might not be finalized and
completed at that point for some variables yet.
This patch defers it until *finish_decl. Bootstrapped/regtested on
x86_64-linux and i686-linux, commit
Hi all,
here is a minor update of the patch, which cures some problems with
implicitly pure functions in the previous version.
Most implicitly pure functions were actually detected correctly, but
implicitly pure functions that called other implicitly pure functions
were not detected properly, and
Hi Janus,
The cleaner approach would certainly be to avoid short-circuiting of
impure functions altogether. If we can all agree that this is a good
idea,
This is a fine example of logical short-circuiting - the condition you
mention is false, therefore the rest need not be evaluated :-)
r259399, which added PROCESSOR_SKYLAKE, disabled many x86 optimizations
which are enabled by PROCESSOR_HASWELL. As the result, -mtune=skylake
generates slower codes on Skylake than before. The same also applies
to Cannonlake and Icelak tuning.
This patch changes -mtune={skylake|cannonlake|icelak
On Thu, Jul 12, 2018 at 7:53 AM, Kito Cheng wrote:
> ping.
> On Fri, Jul 6, 2018 at 4:38 PM Kito Cheng wrote:
>>
>> Hi all:
>>
>> This patch implemented TARGET_MERGE_DECL_ATTRIBUTES hook to check the
>> interrupter is all compatible, tested with rv32ima and rv64ima elf
>> toolchain.
>>
>> gcc/Cha
2018-07-12 21:53 GMT+02:00 Thomas Koenig :
> Hi Janus,
>
>> The cleaner approach would certainly be to avoid short-circuiting of
>> impure functions altogether. If we can all agree that this is a good
>> idea,
>
>
> This is a fine example of logical short-circuiting - the condition you
> mention is
Ping: https://gcc.gnu.org/ml/gcc-patches/2018-07/msg00197.html
On 07/04/18 12:53, Bernd Edlinger wrote:
> Hi,
>
> currently _Pragma("GCC diagnostic ...") does not properly
> work in macro expansions.
>
> Consider the following code:
>
> #define B _Pragma("GCC diagnostic push") \
> _Prag
This eliminates one Ada testsuite failure, by adding riscv*-*-* for the list
of targets that expect this warning. This was pre-approved by Eric Botcazou.
Tested with a riscv64-linux native Ada testsuite run. There was one less
failure with this patch.
Committed.
Jim
gcc/testsuite/
A somewhat old "issue report" pointed me to the code generated for a 4-fold
manually unrolled version of the following loop:
> while (++len != len_limit) /* this is loop */
> if (pb[len] != cur[len])
> break
On Thu, 2018-07-12 at 07:17 +0100, Richard Sandiford wrote:
>
> So it only calls targetm.hard_regno_call_part_clobbered if such a
> call is known to exist somewhere between the two references to
> regno (although we don't have the calls themselves to hand).
>
> Thanks,
> Richard
Having the speci
On Fri, 29 Jun 2018, Kyrill Tkachov wrote:
> This patch adds support for the Arm Cortex-A76 processor in changes.html
> for GCC 9. It enables the AArch64 section of the page and adds the news
> blob there. It also adds an entry to the already-existing arm entry.
Thank you, Kyrill.
Should I als
On Thu, Jul 12, 2018 at 8:56 AM, Pierre-Marie de Rodat
wrote:
> I don’t have much more to say than debug11.adb’s comment ;-)
>
>> This testcase checks that in the DWARF description of the variant type
>> below, the C discriminant is properly described as unsigned, hence the
>> 0x5a
>> ('Z') and 0x
On 07/13/2018 01:57 AM, Jim Wilson wrote:
I poked at this a little and noticed a difference between the x86_64
support and the RISC-V support. The RISC-V C language port has char
as unsigned by default. The x86_64 port has char signed by default.
If I add a -fsigned-char option, then the testca
On Fri, Jul 13, 2018 at 12:05 AM Kelvin Nilsen wrote:
>
> A somewhat old "issue report" pointed me to the code generated for a 4-fold
> manually unrolled version of the following loop:
>
> > while (++len != len_limit) /* this is loop */
> > if (
On Thu, Jul 12, 2018 at 9:57 PM, H.J. Lu wrote:
> r259399, which added PROCESSOR_SKYLAKE, disabled many x86 optimizations
> which are enabled by PROCESSOR_HASWELL. As the result, -mtune=skylake
> generates slower codes on Skylake than before. The same also applies
> to Cannonlake and Icelak tun
65 matches
Mail list logo
