On Thu, Mar 28, 2019 at 01:08:55PM -0500, Segher Boessenkool wrote:
> > TARGET_IRA_CHANGE_PSEUDO_ALLOCNO_CLASS is needed for rs6000 in order
> > to fix the 20% cactus_adm spec regression when using GEN_OR_VSX_REGS
> > as an allocno class. It is similar to the aarch64 version but without
> > any se
Hi All,
LTO bootstrap for ARM fails with the commit
commit 67c18bce7054934528ff5930cca283b4ac967dca
* combine.c (record_dead_and_set_regs_1): Record the source unmodified
for a paradoxical SUBREG on a WORD_REGISTER_OPERATIONS target.
It fails with an internal compiler error: in operator+=, at
pr
> On 28 Mar 2019, at 18:08, Segher Boessenkool
> wrote:
>
>> diff --git a/gcc/config/rs6000/darwin.h b/gcc/config/rs6000/darwin.h
>> index 9fb36e41e7d..20c59f89c8f 100644
>> --- a/gcc/config/rs6000/darwin.h
>> +++ b/gcc/config/rs6000/darwin.h
>> @@ -346,7 +346,8 @@ extern int darwin_emit_bran
On 3/28/19 5:07 PM, Marc Glisse wrote:
> On Thu, 28 Mar 2019, Vineet Gupta wrote:
>
>> simple test such as below was failing.
>>
>> | void main(int argc, char *argv[])
>> | {
>> |size_t total_time = 115424; // expected 115.424
>> |double secs = (double)total_time/(doub
On Thu, 28 Mar 2019, Vineet Gupta wrote:
simple test such as below was failing.
| void main(int argc, char *argv[])
| {
|size_t total_time = 115424; // expected 115.424
|double secs = (double)total_time/(double)1000;
|printf("%s %d %lf\n", "secs", total_time, s
On 3/28/19 11:45 AM, Jason Merrill wrote:
On 3/27/19 6:56 PM, Martin Sebor wrote:
On 3/27/19 3:11 PM, Martin Sebor wrote:
On 3/27/19 4:44 AM, Jonathan Wakely wrote:
On 21/03/19 15:03 -0400, Jason Merrill wrote:
On 3/20/19 6:06 PM, Marek Polacek wrote:
On Wed, Mar 20, 2019 at 10:58:32PM +0100
simple test such as below was failing.
| void main(int argc, char *argv[])
| {
|size_t total_time = 115424; // expected 115.424
|double secs = (double)total_time/(double)1000;
|printf("%s %d %lf\n", "secs", total_time, secs); // prints 113.504
|printf("%d\n",
Hi!
The following testcase ICEs, because remap_type remaps all VLA types, even
those that shouldn't be and e.g. the Fortran FE then asserts
TYPE_MAIN_VARIANT equality, which is not true because of that spurious
remapping.
During normal inlining and most of other remap_type uses, id->copy_decl is
On 3/26/19 4:40 AM, Richard Biener wrote:
On Mon, 18 Mar 2019, Richard Biener wrote:
On Fri, 15 Mar 2019, Jason Merrill wrote:
On 3/15/19 9:33 AM, Richard Biener wrote:
The following is an attempt to fix PR71598 where C (and C++?) have
an implementation-defined compatible integer type for e
On 3/28/19 2:59 PM, Marek Polacek wrote:
On Thu, Mar 21, 2019 at 04:00:41PM -0400, Jason Merrill wrote:
On 3/19/19 11:45 AM, Marek Polacek wrote:
On Thu, Mar 14, 2019 at 04:22:41PM -0400, Jason Merrill wrote:
On 3/7/19 4:52 PM, Marek Polacek wrote:
This was one of those PRs where the more you
On 3/20/19 4:12 PM, Marek Polacek wrote:
The fix for 77656 caused us to call convert_nontype_argument even for
value-dependent arguments, to perform the conversion in order to avoid
a bogus warning.
In this case, the argument is Pod{N}. The call to build_converted_constant_expr
in convert_nonty
On 3/28/19 11:49 AM, Roman Zhuykov wrote:
Ping
A week ago I decided it is so minor that I can report here with a
patch without creating bugzilla PR.
Technically it is a "9 regression" in new functionality added back in summer.
Patch was succesfully bootstrapped and regtested on x86_64.
Ok for
Attached patch corrects RMW operation with LEA peephole pattern. The
mode of the LEA is either SImode (for QImode, HImode or SImode
operation) or DImode.
2019-03-28 Uroš Bizjak
PR target/89865
* config/i386/i386.md (RMW operation with LEA peephole):
Use LEAMODE mode attribute inste
Hi Xiong,
Sorry this took so long.
On Mon, Mar 04, 2019 at 07:15:31PM -0600, luo...@linux.ibm.com wrote:
> This is a backport of r250477, r25, r257253 and r258137 from trunk to
> gcc-7-branch to support built-in functions:
> vec_extract_fp_from_shorth, vec_extract_fp_from_shortl,
> vec_extrac
On Tue, Mar 26, 2019 at 8:05 PM Uros Bizjak wrote:
>
> Attached patch fixes a corner case in STV pass where the shift operand
> register equals shift count register. The specialization for shift
> insns marked register as processed, but didn't process shift input
> operand, leaving an unprocessed
On Thu, Mar 21, 2019 at 04:00:41PM -0400, Jason Merrill wrote:
> On 3/19/19 11:45 AM, Marek Polacek wrote:
> > On Thu, Mar 14, 2019 at 04:22:41PM -0400, Jason Merrill wrote:
> > > On 3/7/19 4:52 PM, Marek Polacek wrote:
> > > > This was one of those PRs where the more you poke, the more ICEs turn
On 3/27/19 5:45 PM, Marek Polacek wrote:
Here we have a non-dependent constructor in a template:
{ VIEW_CONVERT_EXPR(j) }
In digest_init we call massage_init_elt, which calls digest_init_r on the
element. We convert the element, but we're in a template, so
perform_implicit_conversion added
On Thu, Mar 28, 2019 at 02:02:47PM -0400, Jason Merrill wrote:
> On 3/27/19 3:08 PM, Marek Polacek wrote:
> > I noticed that this test doesn't compile because
> > build_converted_constant_expr
> > failed to consider explicit conversion functions. That's wrong: while Core
> > Issue 1981 specifies
On Thu, Mar 28, 2019 at 09:15:54PM +1030, Alan Modra wrote:
> On Thu, Mar 28, 2019 at 12:10:06AM +1030, Alan Modra wrote:
> > Also, using a register move cost of 2 for for power9 direct moves
> > gives these fails, even with the .md file tweaks:
> > +FAIL: gcc.target/powerpc/vec-set-char.c scan-ass
Hi!
On Thu, Mar 28, 2019 at 12:10:06AM +1030, Alan Modra wrote:
> This patch makes a number of corrections to rs6000_register_move_cost,
> adds a new register union class, GEN_OR_VSX_REGS, and adjusts insn
> alternative to suit.
Cool beans.
[ snip various great explanations, thanks! ]
> TARGET_
On Thu, Mar 28, 2019 at 01:30:46PM -0400, Jason Merrill wrote:
> On 3/26/19 11:06 AM, Marek Polacek wrote:
> > On Tue, Mar 26, 2019 at 12:34:03PM +0100, Andreas Schwab wrote:
> > > I don't see any of the warnings in the tests on ia64.
> > >
> > > FAIL: g++.dg/cpp1z/aggr-base8.C -std=c++17 (test
On 3/27/19 3:08 PM, Marek Polacek wrote:
I noticed that this test doesn't compile because build_converted_constant_expr
failed to consider explicit conversion functions. That's wrong: while Core
Issue 1981 specifies that explicit conversion functions are not considered for
contextual conversions
> On Mar 28, 2019, at 11:30 AM, Qing Zhao wrote:
>
> Thanks.
>
> I updated ipa-inline.c as you suggested, and tested the gcc with all
> live-patching-*.c testing cases, all were fine.
> bootstrapped on aarch64, and now the regression testing is running.
the regression test passed without any
Ping
A week ago I decided it is so minor that I can report here with a
patch without creating bugzilla PR.
Technically it is a "9 regression" in new functionality added back in summer.
Patch was succesfully bootstrapped and regtested on x86_64.
Ok for trunk?
чт, 21 мар. 2019 г. в 18:53, Roman Z
On 3/27/19 6:56 PM, Martin Sebor wrote:
On 3/27/19 3:11 PM, Martin Sebor wrote:
On 3/27/19 4:44 AM, Jonathan Wakely wrote:
On 21/03/19 15:03 -0400, Jason Merrill wrote:
On 3/20/19 6:06 PM, Marek Polacek wrote:
On Wed, Mar 20, 2019 at 10:58:32PM +0100, Jakub Jelinek wrote:
On Wed, Mar 20, 201
On 3/26/19 11:06 AM, Marek Polacek wrote:
On Tue, Mar 26, 2019 at 12:34:03PM +0100, Andreas Schwab wrote:
I don't see any of the warnings in the tests on ia64.
FAIL: g++.dg/cpp1z/aggr-base8.C -std=c++17 (test for warnings, line 33)
FAIL: g++.dg/cpp1z/aggr-base8.C -std=c++17 (test for warnin
Thanks.
I updated ipa-inline.c as you suggested, and tested the gcc with all
live-patching-*.c testing cases, all were fine.
bootstrapped on aarch64, and now the regression testing is running.
the new patch is as following:
Okay for trunk?
thanks.
Qing
gcc/ChangeLog:
2019-03-28 qing zhao
On 3/26/19 6:28 PM, Jakub Jelinek wrote:
Hi!
As the testcase shows, the SWITCH_STMT handling in
potential_constant_expression_1
is quite conservative, it doesn't recurse on the body of the switch stmt,
because at least for the case where the switch condition isn't some easily
determinable const
On Thu, 2019-03-28 at 15:14 +0100, Jakub Jelinek wrote:
> On Thu, Mar 28, 2019 at 11:02:52AM -0400, David Malcolm wrote:
> > optrecord_json_writer::optinfo_to_json can in theory be called from
> > any
> > optimization pass, but currently uses get_fnname_from_decl, which
> > is RTL-specific, which c
This is an update from last years attempt to tame down vectorization
when it runs in to ABI inefficiencies at function return. I've
updated the patch to look for multi-reg returns instead of
!vector ones (due to word_mode vectorization) and handle a bit
more returns, esp. the common pattern of
On 3/27/19 4:24 PM, Jakub Jelinek wrote:
> On Wed, Mar 27, 2019 at 04:32:15PM +0100, Jakub Jelinek wrote:
>> On Wed, Mar 27, 2019 at 09:24:46AM -0600, Jeff Law wrote:
2) another thing I've noticed today, we queue up the debug insn changes,
but if we iterate the second time for any bb, we
On Thu, Mar 28, 2019 at 11:02:52AM -0400, David Malcolm wrote:
> optrecord_json_writer::optinfo_to_json can in theory be called from any
> optimization pass, but currently uses get_fnname_from_decl, which
> is RTL-specific, which can lead to an ICE (PR middle-end/89725).
The ICE is a separate prob
optrecord_json_writer::optinfo_to_json can in theory be called from any
optimization pass, but currently uses get_fnname_from_decl, which
is RTL-specific, which can lead to an ICE (PR middle-end/89725).
In that PR, Jakub suggested using either DECL_ASSEMBLER_NAME or the
"printable name" (via curre
On Thu, Mar 28, 2019 at 09:55:46AM +0100, Richard Biener wrote:
> On Wed, Mar 27, 2019 at 4:26 PM Jeff Law wrote:
> >
> > On 3/27/19 8:36 AM, Jakub Jelinek wrote:
> > > On Sun, Mar 24, 2019 at 09:20:07AM -0600, Jeff Law wrote:
> > >> However, I'm increasingly of the opinion that MIPS targets need
On 28/03/19 15:21 +0200, Ville Voutilainen wrote:
On Thu, 28 Mar 2019 at 15:07, Ville Voutilainen
wrote:
This shaves off some unnecessary codegen. In the assignment
operators and swap, we are already visiting the rhs, so we shouldn't
visit it again to get to its guts, we already have them in-h
On Thu, Mar 28, 2019 at 2:28 PM Jonathan Wakely wrote:
>
> The declaration of create_nested_ptr_option in the header has the 'from'
> and 'to' parameters in the opposite order from the definition in
> gengtype.c:
>
> /* Return an options structure for a "nested_ptr" option. */
> options_p
>
The declaration of create_nested_ptr_option in the header has the 'from'
and 'to' parameters in the opposite order from the definition in
gengtype.c:
/* Return an options structure for a "nested_ptr" option. */
options_p
create_nested_ptr_option (options_p next, type_p t,
On Thu, 28 Mar 2019 at 15:07, Ville Voutilainen
wrote:
>
> This shaves off some unnecessary codegen. In the assignment
> operators and swap, we are already visiting the rhs, so we shouldn't
> visit it again to get to its guts, we already have them in-hand.
>
> 2019-03-28 Ville Voutilainen
>
>
On 3/28/19 1:53 PM, Richard Biener wrote:
> On Wed, Mar 27, 2019 at 10:52 AM marxin wrote:
>>
>
> Hmm, I don't think we want this - it looks too much like a hack to me.
>
> I guess for an easier way to figure out the min/max ranges (do we
> handle anti-ranges?) would be to specify a function nam
On Thu, Mar 28, 2019 at 2:05 PM Martin Liška wrote:
>
> On 3/28/19 1:51 PM, Richard Biener wrote:
> > On Wed, Mar 27, 2019 at 10:52 AM marxin wrote:
> >>
> >>
> >> gcc/ChangeLog:
> >>
> >> 2019-03-27 Martin Liska
> >>
> >> * dbgcnt.c (dbg_cnt_process_single_pair): Fix GNU coding style.
This shaves off some unnecessary codegen. In the assignment
operators and swap, we are already visiting the rhs, so we shouldn't
visit it again to get to its guts, we already have them in-hand.
2019-03-28 Ville Voutilainen
Don't revisit a variant we are already visiting.
* include/std/
On 3/28/19 1:51 PM, Richard Biener wrote:
> On Wed, Mar 27, 2019 at 10:52 AM marxin wrote:
>>
>>
>> gcc/ChangeLog:
>>
>> 2019-03-27 Martin Liska
>>
>> * dbgcnt.c (dbg_cnt_process_single_pair): Fix GNU coding style.
>> (dbg_cnt_process_opt): Parse first tokens aas
>
> as
Better
On Tue, Mar 26, 2019 at 5:25 PM Qing Zhao wrote:
>
> Hi, Richard,
>
> thanks for the suggestion.
>
> I tried it yesterday, but it did not work.
>
> the reason is:
>
> inside “can_inline_edge_by_limits_p”, the “allowance for always_inline” is
> guarded by the following condition:
>
> else if “cal
On Wed, Mar 27, 2019 at 10:52 AM marxin wrote:
>
Hmm, I don't think we want this - it looks too much like a hack to me.
I guess for an easier way to figure out the min/max ranges (do we
handle anti-ranges?) would be to specify a function name the
debug counter would be enabled for. That might a
On Wed, Mar 27, 2019 at 10:52 AM marxin wrote:
>
>
> gcc/ChangeLog:
>
> 2019-03-27 Martin Liska
>
> * dbgcnt.c (dbg_cnt_process_single_pair): Fix GNU coding style.
> (dbg_cnt_process_opt): Parse first tokens aas
as
so what was the issue you fixed?
> dbg_cnt_process_si
On Wed, Mar 27, 2019 at 10:52 AM marxin wrote:
>
Hmm, I guess I can see how this is useful, thus OK.
Richard.
> gcc/ChangeLog:
>
> 2019-03-27 Martin Liska
>
> * dbgcnt.c (print_limit_reach): New function.
> (dbg_cnt): Use it.
> ---
> gcc/dbgcnt.c | 26 ---
On Thu, Mar 28, 2019 at 12:10:06AM +1030, Alan Modra wrote:
> Also, using a register move cost of 2 for for power9 direct moves
> gives these fails, even with the .md file tweaks:
> +FAIL: gcc.target/powerpc/vec-set-char.c scan-assembler-not mtvsrwz
> +FAIL: gcc.target/powerpc/vec-set-char.c scan-a
On Wed, 27 Mar 2019, Jakub Jelinek wrote:
> Hi!
>
> This cleans up something I found ugly already several times.
> NONDEBUG_INSN_P(X) used to be defined as
> ((GET_CODE (X) == INSN || GET_CODE (X) == DEBUG_INSN
> || GET_CODE (X) == JUMP_INSN || GET_CODE (X) == CALL_INSN)
> && GET_CODE (X) != D
On Wed, Mar 27, 2019 at 4:26 PM Jeff Law wrote:
>
> On 3/27/19 8:36 AM, Jakub Jelinek wrote:
> > On Sun, Mar 24, 2019 at 09:20:07AM -0600, Jeff Law wrote:
> >> However, I'm increasingly of the opinion that MIPS targets need to drop
> >> off the priority platform list. Given the trajectory I see f
Hi.
Backporting one documentation fix.
Martin
>From 7bcca48f559a3fefaf37b177b3c72e78d73d73ba Mon Sep 17 00:00:00 2001
From: marxin
Date: Thu, 28 Mar 2019 09:51:06 +0100
Subject: [PATCH] Backport r265786
gcc/ChangeLog:
2018-11-05 Martin Liska
PR web/87829
* doc/invoke.texi: Remove options
Hi.
I'm backporting a documentation fix.
Martin
>From 1055e2c2787be337c33787608473a7a4bcbe82b8 Mon Sep 17 00:00:00 2001
From: marxin
Date: Thu, 28 Mar 2019 09:47:27 +0100
Subject: [PATCH] Backport r265786
gcc/ChangeLog:
2018-11-05 Martin Liska
PR web/87829
* doc/invoke.texi: Remove optio
On Wed, Mar 27, 2019 at 11:02 AM Martin Liška wrote:
>
> Hi.
>
> The revision should be reverted as prev-* is the location
> where stagetrain stores all *.gcda files.
>
> I've tested that with PGO on x86_64-linux-gnu.
>
> Ready for trunk?
OK.
> Thanks,
> Martin
>
> ChangeLog:
>
> 2019-03-27 Mar
On Thu, Mar 28, 2019 at 7:47 AM Hongtao Liu wrote:
>
> Hi Uros:
> would you help to review this patch?
This is AVX512F patch, you will need the approval from the maintainer
first. I have no plans to maintain AVX512 beyond rubber-stamping OK
dead obvious regression from a reputable contributors.
53 matches
Mail list logo
