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
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
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
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
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])
>
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/
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") \
>
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
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.
>>
>>
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
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 :-)
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,
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,
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
> 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
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
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:
> >
> > *
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
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/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
> 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
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
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
(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,9 @@ extern unsigned
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
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,
>
>
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
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
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
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
>
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
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
>
> *
> 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
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
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
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
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
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.
>
>
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
;
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 +0200
+++ gcc
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
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
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
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
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
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
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
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))
>>
>>
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
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 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
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
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,
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
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
>
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
*
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
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/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
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
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
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
Jeff Law writes:
> On 07/11/2018 02:07 PM, Steve Ellcey wrote:
>> I have a reload/register allocation question and possible patch. While
>> working on the Aarch64 SIMD ABI[1] I ran into a problem where GCC was
>> saving and restoring registers that it did not need to. I tracked it
>> down to
Hi,
this is a heads-up that configuring with --enable-maintainer-mode
currently breaks bootstrap; see
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86450
for details.
Running configure with --enable-maintainer-mode --disable-werror
allows bootstrap to proceed until the underlying issue is
65 matches
Mail list logo
