This patch is to fix a missing ifcvt opportunity in back-end. For the simple
case below,
if (...)
x = a; /* x is memory */
/* no else */
We can generate conditional move and remove the branch as below if the target
cost is acceptable.
r1 = x
r2 = a
cmp ...
csel r3, r1, r2, cond
x = r3
T
This patch by Cherry Zhang fixes the Go frontend to eliminate bound
checks in an append expression. The compiler generates two array
index expressions when lowering an append expression. Currently they
generate bound checks. Bound checks are not necessary in this case,
as we know the slice has,
On 3/14/19 7:01 PM, Jakub Jelinek wrote:
Hi!
On the following testcase, we have tree initializers that satisfy
initializer_constant_valid_p and do:
rtl = rtl_for_decl_init (init, type);
if (rtl)
return add_const_value_attribute (die, rtl);
add_const_value_attribute has a l
To copy type attributes from struct A, the copy attribute (new
in GCC 9) accepts a pointer argument such as (struct A*)0, but
it isn't prepared for anything much more complicated than that.
So for example when it's passed something like (struct A*)(0, 1)
as the test case in PR 89685 does (a P1 reg
From: Andrew Pinski
Hi,
On OcteonTX2, ld1r and ld1 (with a single lane) are split
into two different micro-ops unlike most other targets.
This adds three extra costs to the cost table:
ld1_dup: used for "ld1r {v0.4s}, [x0]"
merge_dup: used for "dup v0.4s, v0.4s[0]" and "ins v0.4s[0], v0.4s[0]"
Hi!
On the following testcase, we have tree initializers that satisfy
initializer_constant_valid_p and do:
rtl = rtl_for_decl_init (init, type);
if (rtl)
return add_const_value_attribute (die, rtl);
add_const_value_attribute has a list of rtl codes it expects in the
initializer
Hi!
As mentioned in the PR, r267272 added STRIP_ANY_LOCATION_WRAPPERS
at the start of operand_equal_p, but has not updated inchash::add_expr
which needs to follow what operand_equal_p does, so that if two trees
compare equal, they get the same hash value.
For location wrappers at the outermost lev
Double ping.
Steve Ellcey
sell...@marvell.com
On Tue, 2019-02-26 at 08:44 -0800, Steve Ellcey wrote:
> Ping.
>
> Steve Ellcey
> sell...@marvell.com
>
>
> On Mon, 2019-02-11 at 10:46 -0800, Steve Ellcey wrote:
> > On Thu, 2019-02-07 at 18:13 +, Wilco Dijkstra wrote
> > >
> > > Hi Steve,
>
On Thu, Mar 14, 2019 at 11:01:37PM +0100, Eric Botcazou wrote:
> > Not if the >> 3 shift is arithmetic shift.
>
> Sorry, I don't understand how this can work.
For some configurations, libasan defines SHADOW_OFFSET to
__asan_shadow_memory_dynamic_address (exported uptr symbol from libasan),
so SHA
> Not if the >> 3 shift is arithmetic shift.
Sorry, I don't understand how this can work.
--
Eric Botcazou
On Mar 12, 2019, Jakub Jelinek wrote:
> Note, for DWARF before v4, there is no DW_FORM_sec_offset and
> DW_FORM_data4 or DW_FORM_data8 depending on whether it is 32-bit or 64-bit
> DWARF is used instead.
Ah, yes, thanks. I made these fixes, changed some dashes to underlines
in "identifiers", an
Hi,
On 14/03/19 21:03, Jason Merrill wrote:
On 3/12/19 7:21 AM, Paolo Carlini wrote:
Hi,
this is just an error recovery ICE but maybe we can fix it in time
for 9.1.0, like c++/89488, which is somehow related. Indeed, the
problem is again a !DEFERRED_NOEXCEPT_SPEC_P gcc_assert triggering
whe
On 3/14/19 4:20 PM, Marek Polacek wrote:
On Thu, Mar 14, 2019 at 05:14:49PM -0300, Alexandre Oliva wrote:
P0732R2 / C++ 2a introduce class literals as template parameters. The
front-end uses VAR_DECLs constructed from such literals to bind the
template PARM_DECLs, but dwarf2out.c used to reject
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 up.
This patch fixes the ones I could find. The original problem was that
maybe_instantiate_noexcept got a TEMPLATE_DECL created for the member
friend template in do_friend. Its noexcep
On Thu, Mar 14, 2019 at 05:14:49PM -0300, Alexandre Oliva wrote:
> P0732R2 / C++ 2a introduce class literals as template parameters. The
> front-end uses VAR_DECLs constructed from such literals to bind the
> template PARM_DECLs, but dwarf2out.c used to reject such VAR_DECLs.
>
> Taking DECL_INIT
P0732R2 / C++ 2a introduce class literals as template parameters. The
front-end uses VAR_DECLs constructed from such literals to bind the
template PARM_DECLs, but dwarf2out.c used to reject such VAR_DECLs.
Taking DECL_INITIAL from such VAR_DECLs enables the generation of
DW_AT_const_value for the
On 3/12/19 7:21 AM, Paolo Carlini wrote:
Hi,
this is just an error recovery ICE but maybe we can fix it in time for
9.1.0, like c++/89488, which is somehow related. Indeed, the problem is
again a !DEFERRED_NOEXCEPT_SPEC_P gcc_assert triggering where, earlier,
process_subob_fn had maybe_instan
The concepts overhaul isn't ready yet, but we should at least support concept
definitions without bool; that has been the one thing that prevents people from
writing code that works in both TS and C++20 concepts.
Tested x86_64-pc-linux-gnu, applying to trunk.
* parser.c (cp_parser_decl_sp
On Fri, Mar 15, 2019 at 03:36:15AM +0800, H.J. Lu wrote:
> Like this?
Yes.
> gcc/
>
> PR target/89650
> * config/i386/i386.c (remove_partial_avx_dependency): Handle
> REG_EH_REGION note.
>
> gcc/testsuite/
>
> PR target/89650
> * g++.target/i386/pr89650.C: New tes
On 3/14/19, Jakub Jelinek wrote:
> On Thu, Mar 14, 2019 at 09:08:17PM +0800, H.J. Lu wrote:
>> --- a/gcc/config/i386/i386.c
>> +++ b/gcc/config/i386/i386.c
>> @@ -2819,6 +2819,8 @@ remove_partial_avx_dependency (void)
>>rtx set;
>>rtx v4sf_const0 = NULL_RTX;
>>
>> + auto_vec splitted_insn
Hi Nathan,
On 14/03/19 16:59, Nathan Sidwell wrote:
I see this is DR 36.
http://wiki.edg.com/pub/Wg21kona2019/CoreWorkingGroup/cwg_active.html#36
I still think we should drop this check, for one thing we don't apply
it consistently (eg, naming an unscoped enum value).
I see that for example
On Thu, Mar 14, 2019 at 03:10:59PM +0100, Richard Biener wrote:
> I've added a testcase.
>
> Bootstrapped and tested on x86_64-unknown-linux-gnu, OK for trunk
> or should it wait for GCC10?
I meant something like following where we'd clean it up everything right
away after we DCE some returns_twi
On Thu, Mar 14, 2019 at 10:08:55AM -0600, Martin Sebor wrote:
> What solution would you like to see for these (pointer vs integer)
> mismatches?
For GCC 9, I'd probably like most adding the similar pointer vs. non-pointer
test to the return value like there is for the arguments, unless there is
so
On 3/14/19 2:43 AM, Jakub Jelinek wrote:
On Thu, Mar 14, 2019 at 12:50:28AM +, Joseph Myers wrote:
The C FE sadly passes through some really bad prototypes of builtin
functions as "harmless":
/* Accept "harmless" mismatches in function types such
as missing qualifier
I see this is DR 36.
http://wiki.edg.com/pub/Wg21kona2019/CoreWorkingGroup/cwg_active.html#36
I still think we should drop this check, for one thing we don't apply it
consistently (eg, naming an unscoped enum value).
On 3/14/19 11:47 AM, Nathan Sidwell wrote:
Jason, Paolo,
This concerns:
nam
Jason, Paolo,
This concerns:
namespace N
{
int i;
}
void
f ()
{
using N::i;
using N::i; // { dg-error "declared" }
}
which is extracted from g++.dg/lookup/using53.C added fixing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=20420
The comment mentions C++11 7.3.3/10, which does giv
On Thu, 14 Mar 2019, Christophe Lyon wrote:
> On Thu, 14 Mar 2019 at 15:35, Jakub Jelinek wrote:
> >
> > On Thu, Mar 14, 2019 at 03:32:39PM +0100, Christophe Lyon wrote:
> > > > 2019-03-04 Richard Biener
> > > >
> > > > PR testsuite/89551
> > > > * gcc.dg/uninit-pred-8_b.c: For
On Thu, 14 Mar 2019 at 15:35, Jakub Jelinek wrote:
>
> On Thu, Mar 14, 2019 at 03:32:39PM +0100, Christophe Lyon wrote:
> > > 2019-03-04 Richard Biener
> > >
> > > PR testsuite/89551
> > > * gcc.dg/uninit-pred-8_b.c: Force logical-op-non-short-circuit
> > > the way that
On Thu, Mar 14, 2019 at 03:32:39PM +0100, Christophe Lyon wrote:
> > 2019-03-04 Richard Biener
> >
> > PR testsuite/89551
> > * gcc.dg/uninit-pred-8_b.c: Force logical-op-non-short-circuit
> > the way that makes the testcase PASS.
>
> Hi Richard,
>
> I think you forgot
On March 14, 2019 3:32:39 PM GMT+01:00, Christophe Lyon
wrote:
>On Mon, 4 Mar 2019 at 11:25, Richard Biener wrote:
>>
>>
>> The CFG cleanup change made us remove an extra forwarder which
>somehow
>> makes VRP jump threading go berzerk. Fortunately only on
>> logical-op-non-short-circuit=0 targe
On Mon, 4 Mar 2019 at 11:25, Richard Biener wrote:
>
>
> The CFG cleanup change made us remove an extra forwarder which somehow
> makes VRP jump threading go berzerk. Fortunately only on
> logical-op-non-short-circuit=0 targets so the easy way to fix the
> testcase is to force that our way.
>
> T
Hi.
This is removal of not supported option.
I'm going to install it as obvious.
Martin
gcc/ChangeLog:
2019-03-14 Martin Liska
PR other/89712
* doc/invoke.texi: Remove -fdump-class-hierarchy option.
---
gcc/doc/invoke.texi | 1 -
1 file changed, 1 deletion(-)
diff --git a
On Thu, 14 Mar 2019, Richard Biener wrote:
> On Thu, 14 Mar 2019, Jakub Jelinek wrote:
>
> > On Thu, Mar 14, 2019 at 11:23:03AM +0100, Richard Biener wrote:
> > > I am testing the following. There's IMHO also a missed optimization
> > > (for CFG-cleanup?) that when a block does not end up in a c
On 3/14/19 7:52 AM, Jakub Jelinek wrote:
> Hi!
>
> On the gcc.dg/vect/pr88598-3.c testcase, gen_vec_extract... is called with
> operands[1] that is already a subreg - (subreg:V4SF (reg:V4SI 201 [ _31 ]) 0)
> and wraps it in another SUBREG, which is invalid in RTL.
>
> In all the following 4 spots
gcc/lto/ChangeLog:
2019-03-14 Martin Liska
* lto-common.c: Update coding style.
* lto.c (materialize_cgraph): Likewise.
---
gcc/lto/lto-common.c | 214 ++-
gcc/lto/lto.c| 30 +++---
2 files changed, 128 insertions(+), 116 delet
gcc/ChangeLog:
2019-03-14 Hrishikesh Kulkarni
Martin Liska
* Makefile.in: Add lto-dump.texi.
* cgraph.h: Add new functions dump_visibility and
dump_type_name.
* doc/gcc.texi: Include lto-dump section.
* doc/lto-dump.texi: New file.
Hi.
The patch series is a remake of Hrishikesh's LTO dump tool that was
part of GSoC last year. I decided to split the patch into 3 parts, where
the first one is purely mechanical splitting code into a newly created
one. The second part introduces the new tool. And the last one is about
GNU coding
Hi!
On the gcc.dg/vect/pr88598-3.c testcase, gen_vec_extract... is called with
operands[1] that is already a subreg - (subreg:V4SF (reg:V4SI 201 [ _31 ]) 0)
and wraps it in another SUBREG, which is invalid in RTL.
In all the following 4 spots I've verified that the operand's mode is some
128-bit
On Thu, 14 Mar 2019, Martin Jambor wrote:
> Hi,
>
> PR 89546 is a nasty miscompilation bug that is in the compiler since
> r247604 (May 2017) but is surprisingly hard to trigger. Since that
> revision, SRA does not consider all aggregates that are assigned a value
> in a gimple assignment statem
Hi,
PR 89546 is a nasty miscompilation bug that is in the compiler since
r247604 (May 2017) but is surprisingly hard to trigger. Since that
revision, SRA does not consider all aggregates that are assigned a value
in a gimple assignment statement from another aggregate as automatically
containing
On Thu, Mar 14, 2019 at 12:29:37PM +0100, Richard Biener wrote:
> The following properly sets DECL_CONTEXT of the result decl we build,
> otherwise LTO happily merges those across different resolver decls
> ending up in IPA PTA ICEing on this invalidity.
>
> Bootstrap & regtest running on x86_64-u
On Thu, Mar 14, 2019 at 09:08:17PM +0800, H.J. Lu wrote:
> --- a/gcc/config/i386/i386.c
> +++ b/gcc/config/i386/i386.c
> @@ -2819,6 +2819,8 @@ remove_partial_avx_dependency (void)
>rtx set;
>rtx v4sf_const0 = NULL_RTX;
>
> + auto_vec splitted_insn;
Perhaps throwing_insns or flow_transfe
On 3/14/19, H.J. Lu wrote:
> On Thu, Mar 14, 2019 at 4:34 PM Jakub Jelinek wrote:
>>
>> On Thu, Mar 14, 2019 at 11:30:21AM +0800, H.J. Lu wrote:
>> > We need to split the basic block if we create new insns, which may
>> > throw exceptions, in the middle of the basic blocks.
>> >
>> > Tested on AV
Ping.
On Thu, Mar 07, 2019 at 04:52:55PM -0500, Marek Polacek wrote:
> This was one of those PRs where the more you poke, the more ICEs turn up.
> This patch fixes the ones I could find. The original problem was that
> maybe_instantiate_noexcept got a TEMPLATE_DECL created for the member
> friend
On Thu, Mar 14, 2019 at 11:45:53AM +, Jonathan Wakely wrote:
> The checksum file uses SHA512 not MD5SUM, so the instructions should
> be updated accordingly.
>
> SInce there's only one tarfile these days (not separate ones for
> gcc-base, gcc-g++, gcc-fortran, etc) it doesn't seem necessary to
On Wed, 13 Mar 2019, Jakub Jelinek wrote:
> Hi!
>
> create_dispatcher_calls iterates over ipa_ref *s referring the current node
> and wants to remove them all and create new ones. The problem is
> that if there are any ipa_ref objects where two or more of them are from the
> same cgraph node to
On Sat, Feb 23, 2019 at 01:28:22PM +, wuyuan (E) wrote:
> Hi ,James:
> Sorry for not responding to your email in time because of Chinese New Year’s
> holiday and urgent work. The three questions you mentioned last email are due
> to my misunderstanding of pipeline.
> the first question, These
> Below is one patch, more in the spirit of
> https://gcc.gnu.org/ml/gcc-patches/2016-04/msg00418.html
> where we refuse to add REG_EQUAL note in that case.
>
> Attached is another variant, which keeps it around just in case something
> would make use of it, but makes sure we don't fwprop into suc
The checksum file uses SHA512 not MD5SUM, so the instructions should
be updated accordingly.
SInce there's only one tarfile these days (not separate ones for
gcc-base, gcc-g++, gcc-fortran, etc) it doesn't seem necessary to
filter out the "OK" lines with grep, but I could add --quiet to the
comma
The following properly sets DECL_CONTEXT of the result decl we build,
otherwise LTO happily merges those across different resolver decls
ending up in IPA PTA ICEing on this invalidity.
Bootstrap & regtest running on x86_64-unknown-linux-gnu, will apply
as obvious.
Wonder if other targets copied
On Thu, 14 Mar 2019, Jakub Jelinek wrote:
> On Thu, Mar 14, 2019 at 11:23:03AM +0100, Richard Biener wrote:
> > I am testing the following. There's IMHO also a missed optimization
> > (for CFG-cleanup?) that when a block does not end up in a call
> > outgoing abnormal edges can be purged? In thi
> Le 13 mars 2019 à 13:39, Harald Anlauf a écrit :
>
> Hi Thomas,
>
> I am not so convinced that "plain english" messages are the way to go,
> even if they appear better readable at first sight, if conciseness is
> lost.
Well, "Syntax error" is concise, but not really helpful!
> The main r
On Thu, Mar 14, 2019 at 11:23:03AM +0100, Richard Biener wrote:
> I am testing the following. There's IMHO also a missed optimization
> (for CFG-cleanup?) that when a block does not end up in a call
> outgoing abnormal edges can be purged? In this case it is
> IPA inlining leaving us with this -
On Wed, 13 Mar 2019, Richard Biener wrote:
> On Wed, 13 Mar 2019, Bin.Cheng wrote:
>
> > On Wed, Mar 13, 2019 at 3:58 AM Richard Biener wrote:
> > >
> > >
> > > This makes an attempt at fixing the most annoying parts of the GIMPLE
> > > FE unit testing - the lack of proper CFG preservation and h
Hello!
> The following patch fixes
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85860
>
> The patch was successfully bootstrapped and tested on x86-64.
>
> Committed as rev. 269662 to trunk and as rev. 269663 to gcc-8-branch.
Index: testsuite/gcc.target/i386/pr85860.c
===
I am testing the following. There's IMHO also a missed optimization
(for CFG-cleanup?) that when a block does not end up in a call
outgoing abnormal edges can be purged? In this case it is
IPA inlining leaving us with this - the inliner calls
gimple_purge_dead_abnormal_call_edges on the return
On Thu, Mar 14, 2019 at 09:57:27AM +0100, Richard Biener wrote:
> I'd say make it work, thus your patch below is OK.
Ok, here is an updated patch with some self-tests coverage as well that I'll
bootstrap/regtest.
2019-03-14 Jason Merrill
Jakub Jelinek
* hash-table.h (rem
On Thu, 14 Mar 2019, Jakub Jelinek wrote:
> On Wed, Mar 13, 2019 at 10:08:09PM -0400, Jason Merrill wrote:
> > > The following testcase ICEs since my recent cxx_eval_loop_expr changes.
> > > The problem is that the Forget saved values of SAVE_EXPRs. inside of the
> > > loop can remove SAVE_EXPRs f
On Wed, 13 Mar 2019, Jakub Jelinek wrote:
> Hi!
>
> The C FE sadly passes through some really bad prototypes of builtin
> functions as "harmless":
> /* Accept "harmless" mismatches in function types such
> as missing qualifiers or pointer vs same size integer
>
On Thu, Mar 14, 2019 at 4:34 PM Jakub Jelinek wrote:
>
> On Thu, Mar 14, 2019 at 11:30:21AM +0800, H.J. Lu wrote:
> > We need to split the basic block if we create new insns, which may
> > throw exceptions, in the middle of the basic blocks.
> >
> > Tested on AVX2 and AVX512 machines with and with
On Thu, Mar 14, 2019 at 9:22 AM H.J. Lu wrote:
> > > We can't use the %X5 since %X5 is used on operands.
> >
> > So, please introduce some other modifier ("X" was not to be taken
> > literally, but *some* letter). Why are you overloading 'P'?
>
> Here is the updated patch with the 'M' modifier.
>
On Thu, Mar 14, 2019 at 12:50:28AM +, Joseph Myers wrote:
> > The C FE sadly passes through some really bad prototypes of builtin
> > functions as "harmless":
> > /* Accept "harmless" mismatches in function types such
> > as missing qualifiers or pointer vs same size inte
On Thu, Mar 14, 2019 at 11:30:21AM +0800, H.J. Lu wrote:
> We need to split the basic block if we create new insns, which may
> throw exceptions, in the middle of the basic blocks.
>
> Tested on AVX2 and AVX512 machines with and without
>
> --with-arch=native
>
> OK for trunk?
That looks much b
On Mon, Mar 4, 2019 at 10:09 PM Uros Bizjak wrote:
>
> On Mon, Mar 4, 2019 at 2:54 PM H.J. Lu wrote:
> >
> > On Sun, Mar 03, 2019 at 10:34:29PM +0100, Uros Bizjak wrote:
> > > On Sun, Mar 3, 2019 at 10:18 PM H.J. Lu wrote:
> > > >
> > > > On Sun, Mar 3, 2019 at 9:27 AM Uros Bizjak wrote:
> > >
On Wed, Mar 13, 2019 at 10:08:09PM -0400, Jason Merrill wrote:
> > The following testcase ICEs since my recent cxx_eval_loop_expr changes.
> > The problem is that the Forget saved values of SAVE_EXPRs. inside of the
> > loop can remove SAVE_EXPRs from new_ctx.values and if that is the last
> > iter
Hi Thomas!
On Wed, 13 Mar 2019 23:13:46 +0100, Thomas Koenig wrote:
> Am 13.03.19 um 18:50 schrieb Thomas Schwinge:
> >> There are many ways to deal with it without bumping MOD_VERSION in a
> >> backwards but not forwards compatible way, so that a newer compiler will be
> >> able to parse old *.m
66 matches
Mail list logo
