On Mar 20, 2018, Jason Merrill wrote:
> On Tue, Mar 20, 2018 at 6:07 PM, Alexandre Oliva wrote:
>> On Mar 20, 2018, Jason Merrill wrote:
>>> that doesn't mean it's wrong to peek.
>> Huh? We're referencing members of an unrelated template that AFAIK
>> needs not even be defined at that point,
On Mar 20, 2018, Jason Merrill wrote:
>> + if (id == error_mark_node)
>> +return error_mark_node;
> Why wait until here to return? There are error returns immediately
> above and below your first hunk.
QOI. Returning immediately, we then get other errors. We could consume
tokens till th
On Tue, Mar 20, 2018 at 7:37 PM, David Malcolm wrote:
> PR c++/84894 reports that the fix-it hints suggesting accessor calls for
> private fields doesn't work with -g for -O1 and above.
>
> The issue is that field_accessor_p requires DECL_SAVED_TREE (fn) to be
> a RETURN_EXPR, but the former is a
On Tue, Mar 20, 2018 at 7:37 PM, David Malcolm wrote:
> PR c++/84892 reports that we fail to offer fix-it hints about accessor
> member functions when complaining about accesses to private fields
> through const pointers and references.
>
> It turns out that field_accessor_p was incorrectly checki
On Tue, Mar 20, 2018 at 6:51 PM, Alexandre Oliva wrote:
> On Mar 20, 2018, Jason Merrill wrote:
>
>> On Tue, Mar 20, 2018 at 4:15 PM, Alexandre Oliva wrote:
>>> Should we aim at rejecting the declaration of U?
>
>> Yes.
>
> Like this?
>
> [PR c++/71251] check tmpl parms in template using decl
>
On Tue, Mar 20, 2018 at 6:07 PM, Alexandre Oliva wrote:
> On Mar 20, 2018, Jason Merrill wrote:
>
>> On Fri, Mar 16, 2018 at 5:38 PM, Alexandre Oliva wrote:
>>> resolve_typename_type may peek into template types that might still be
>>> specialized. In some cases, e.g. g++.dg/template/friend48.C
The following patch fixes an assign of a valid pointer to
to pointer, but what should have been assigned is NULL;
2018-03-20 Steven G. Kargl
PR fortran/85001
* interface.c (symbol_rank): Remove bogus null pointer check that
crept in when translating a ternary operator i
On Wed, 2018-03-21 at 00:39 +0100, Rainer Orth wrote:
> Hi Malcolm,
>
> > > I've now tested the patch (together with the one from PR
> > > jit/84288
> > > for
> > > several remaining issues). I've needed another snippet for
> > > Solaris/SPARC which links libkstat into xgcc and needs it in
> > >
Hi Malcolm,
>> I've now tested the patch (together with the one from PR jit/84288
>> for
>> several remaining issues). I've needed another snippet for
>> Solaris/SPARC which links libkstat into xgcc and needs it in
>> libgccjit.so, too. Bootstrapped without regressions on
>> i386-pc-solaris2.11
PR c++/84894 reports that the fix-it hints suggesting accessor calls for
private fields doesn't work with -g for -O1 and above.
The issue is that field_accessor_p requires DECL_SAVED_TREE (fn) to be
a RETURN_EXPR, but the former is a STATEMENT_LIST, created in
start_preparsed_function here:
15060
PR c++/84892 reports that we fail to offer fix-it hints about accessor
member functions when complaining about accesses to private fields
through const pointers and references.
It turns out that field_accessor_p was incorrectly checking for "this"
being a "const *T", rather than being a "const T*"
On Mar 20, 2018, Jason Merrill wrote:
> On Tue, Mar 20, 2018 at 4:15 PM, Alexandre Oliva wrote:
>> Should we aim at rejecting the declaration of U?
> Yes.
Like this?
[PR c++/71251] check tmpl parms in template using decl
Check that template using decls have the correct number of parm lists.
On 03/20/2018 02:46 PM, Jakub Jelinek wrote:
> Hi!
>
> On the following testcase, simplify_unary_operation is called on
> VEC_DUPLICATE from (vec_duplicate:V4SF something:SF) to V8SFmode,
> and simplify_unary_operation_1 tries an optimization usable for most
> unary operations, in particular it at
On 03/12/2018 08:56 PM, David H. Gutteridge wrote:
> 2018-03-12 David H. Gutteridge
>
> PR target/84838
> * Minor grammar fixes for x86 options.
>
THanks. Installed.
jeff
On 02/28/2018 02:30 AM, Christophe Lyon wrote:
> Hi,
>
> We happen to build GCC with '~' in the src and build dirs, leading to
> single quotes around the configure path in config.status. For example:
> [...]
> S["TOPLEVEL_CONFIGURE_ARGUMENTS"]="'/home/christophe.lyon/src/Linaro/abe/abe-contrib-sum
This fixes a wrong-code issue on RISC-V, but in theory could be a problem for
any SHIFT_COUNT_TRUNCATED target.
The testcase computes 46 or 47 (0x2e or 0x2f), then ANDs the value with 0xf,
and then SHIFTs the value. On a SHIFT_COUNT_TRUNCATED target, the AND can get
optimized away because for a 3
On Mar 20, 2018, Jason Merrill wrote:
> On Fri, Mar 16, 2018 at 5:38 PM, Alexandre Oliva wrote:
>> resolve_typename_type may peek into template types that might still be
>> specialized. In some cases, e.g. g++.dg/template/friend48.C or
>> g++.dg/template/decl2.C, that is exactly the right thing
On Tue, Mar 20, 2018 at 5:57 PM, Alexandre Oliva wrote:
> On Mar 20, 2018, Jason Merrill wrote:
>
>>> While debugging this, I first tried another patch, that avoids the same
>>> ICEs. I thought this one was a more complete solution, and it renders
>>> the other unnecessary, but I still though it
On Tue, Mar 20, 2018 at 5:56 PM, Alexandre Oliva wrote:
> On Mar 20, 2018, Jason Merrill wrote:
>
>> On Sat, Mar 10, 2018 at 6:57 AM, Alexandre Oliva wrote:
>>> A parenthesized initializer is only accepted when new()ing an array in
>>> permissive mode. We were not careful, however, to convert t
Trunk doesn't build for msp430 due to an ICE whilst building libstdc++.
The following patch proposed a while ago fixes the issue, but hasn't been
applied: https://gcc.gnu.org/ml/gcc-patches/2017-08/msg01433.html
I don't have write access, so if the patch is acceptable I would appreciate
if someo
On Tue, Mar 20, 2018 at 5:55 PM, Alexandre Oliva wrote:
> On Mar 20, 2018, Jason Merrill wrote:
>
>> On Sat, Mar 17, 2018 at 8:11 AM, Alexandre Oliva wrote:
>>> - sorry
>>> - ("cannot initialize multi-dimensional array with
>>> initializer");
>
>> This shouldn't even be a
On Tue, Mar 20, 2018 at 5:04 PM, Jakub Jelinek wrote:
> Hi!
>
> While in C, x = 10 or ++x or --x aren't lvalues and so we reject such
> expressions in inline asm output operands (and inputs that only allow
> memory, not registers), in C++ they apparently are lvalues; for output
> operands we ICE i
On Mar 20, 2018, Jason Merrill wrote:
>> While debugging this, I first tried another patch, that avoids the same
>> ICEs. I thought this one was a more complete solution, and it renders
>> the other unnecessary, but I still though it might be useful to disable
>> auto->implicit_parm while parsin
On Mar 20, 2018, Jason Merrill wrote:
> On Sat, Mar 10, 2018 at 6:57 AM, Alexandre Oliva wrote:
>> A parenthesized initializer is only accepted when new()ing an array in
>> permissive mode. We were not careful, however, to convert the
>> TREE_LIST initializer to the array element type in this e
On Mar 20, 2018, Jason Merrill wrote:
> On Sat, Mar 17, 2018 at 8:11 AM, Alexandre Oliva wrote:
>> - sorry
>> - ("cannot initialize multi-dimensional array with initializer");
> This shouldn't even be a sorry anymore
> Let's make it a hard error here.
Like this?
[PR c+
OK.
On Mon, Mar 19, 2018 at 10:06 PM, Martin Sebor wrote:
> The -Wclass-memaccess warning makes an exception for ctors and
> dtors of non-trivial classes with no bases to avoid triggering
> for uses of raw memory functions with this as the destination.
> All other members as well as non-members t
Jeff Law writes:
> On 03/20/2018 01:36 PM, Martin Liška wrote:
>> Hi.
>>
>> This is a work-around to not iterate all members of array that can be huge.
>> As MPX will be removed in GCC 9.x, I hope it's acceptable. I don't want
>> to come
>> up with a new param for it.
>>
>> Survives tests&bootst
On 20 March 2018 at 21:02, François Dumont wrote:
> On 20/03/2018 19:20, Jonathan Wakely wrote:
>>
>> On 17 March 2018 at 09:01, Jonathan Wakely wrote:
>>>
>>> Native configuration is x86_64-pc-linux-gnu
>>>
>>> === libstdc++ tests ===
>>>
>>>
>>> Running target unix/-std=gnu++11/-
Hi!
While in C, x = 10 or ++x or --x aren't lvalues and so we reject such
expressions in inline asm output operands (and inputs that only allow
memory, not registers), in C++ they apparently are lvalues; for output
operands we ICE in the gimplifier on this, because in the generic code
MODIFY_EXPR
On 03/14/2018 12:29 AM, Paul Hua wrote:
> Hi:
>
> The vect-strided-shift-1.c test fails on MIPS target.
>
> FAIL: gcc.dg/vect/vect-strided-shift-1.c -mpaired-single
> scan-tree-dump-times vect "vectorized 1 loops in function" 1 (found 0
> times)
> FAIL: gcc.dg/vect/vect-strided-shift-1.c -flto -
On 20/03/2018 19:20, Jonathan Wakely wrote:
On 17 March 2018 at 09:01, Jonathan Wakely wrote:
Native configuration is x86_64-pc-linux-gnu
=== libstdc++ tests ===
Running target unix/-std=gnu++11/-D_GLIBCXX_ASSERTIONS
=== libstdc++ Summary for
unix/-std=gnu+
On 03/14/2018 11:23 AM, Martin Liška wrote:
> Hi.
>
> This is a new test-case isolated from libreoffice.
>
> Patch can bootstrap on ppc64le-redhat-linux and survives regression tests.
> I'm going to install it.
>
> Martin
>
> gcc/testsuite/ChangeLog:
>
> 2018-03-14 Martin Liska
>
> P
On Mon, Mar 19, 2018 at 3:50 PM, Jakub Jelinek wrote:
> +int a(__attribute__((b((int)__builtin_inf() * 1ULL / auto;
This seems like another situation like 84610 and 84642 that Alex sent
a patch for, of 'auto' in an attribute wrongly being treated as an
implicit template parameter. As I sugge
On 03/20/2018 06:08 AM, Tom de Vries wrote:
> On 02/20/2018 06:33 PM, Steve Ellcey wrote:
>> +@deftypefn {Built-in Function} Pmode __builtin_extend_pointer (void * x)
>> +On targets where the user visible pointer size is different than the
>> size
>> +of an actual hardware address this function ret
On 03/20/2018 01:40 PM, Martin Liška wrote:
> Hi.
>
> I'm sending removal of a stupid mistake where I installed a patch that
> contained
> a debugging 'return' statement. Fixed that and added condition to
> inspect only
> functions with SSA.
>
> Patch can bootstrap on ppc64le-redhat-linux and sur
Hi!
On the following testcase, simplify_unary_operation is called on
VEC_DUPLICATE from (vec_duplicate:V4SF something:SF) to V8SFmode,
and simplify_unary_operation_1 tries an optimization usable for most
unary operations, in particular it attempts to do
(vec_duplicate:V8SF (unary:SF something:SF))
On 03/15/2018 01:20 PM, Jakub Jelinek wrote:
> Hi!
>
> The following testcase ICEs on s390x-linux, because we have 2 registers
> saved in prologue, but only one of them modified in one path and then
> both restored there; cprop_hardreg propagates the saving register into the
> REG_CFA_RESTORE insn
Hi!
Boolean !x is often expanded as ^ 1, but store merging it actually merges
as ^ 255 (for 8-bit bool), which is incorrect.
The following patch fixes it to do that ^ 1 instead.
Bootstrapped/regtested on x86_64-linux and i686-linux and checked on the
testcase with -> powerpc64-linux cross, ok fo
On Tue, Mar 20, 2018 at 4:15 PM, Alexandre Oliva wrote:
> On Mar 20, 2018, Jason Merrill wrote:
>
>> On Sat, Mar 17, 2018 at 8:13 AM, Alexandre Oliva wrote:
>>> As we go through each of the template parameters, substituting it with
>>> corresponding template arguments, an incorrect argument list
OK.
On Tue, Mar 20, 2018 at 3:50 PM, Marek Polacek wrote:
> This extends my previous fix for c++/84927 in that it also updates
> the ctor's flags when we replace an element.
>
> Bootstrapped/regtested on x86_64-linux, ok for trunk?
>
> 2018-03-20 Marek Polacek
>
> PR c++/71638, ICE wit
On Tue, Mar 20, 2018 at 08:01:57AM -0500, Segher Boessenkool wrote:
> Hi! Some comments...
>
> On Wed, Mar 14, 2018 at 06:54:08PM -0400, Michael Meissner wrote:
> > The first patch in the series moves most of the reg_addr structure from
> > rs6000.c to rs6000-protos.h, so that in the next patch,
On Fri, Mar 16, 2018 at 5:38 PM, Alexandre Oliva wrote:
> resolve_typename_type may peek into template types that might still be
> specialized. In some cases, e.g. g++.dg/template/friend48.C or
> g++.dg/template/decl2.C, that is exactly the right thing to do. In
> others, like the newly-added te
On Tue, Mar 20, 2018 at 08:30:57AM -0500, Segher Boessenkool wrote:
> On Thu, Mar 15, 2018 at 01:04:30PM -0400, Michael Meissner wrote:
> > This is patch #2 of my series for improving the PowerPC internal memory
> > support. It assumes patch #1 has been applied.
> >
> > This patch moves the rs600
Hi Tom,
> On 03/19/2018 10:11 AM, Richard Biener wrote:
>> On Fri, 16 Mar 2018, Tom de Vries wrote:
>>
>>> On 03/16/2018 12:55 PM, Richard Biener wrote:
On Fri, 16 Mar 2018, Tom de Vries wrote:
> On 02/27/2018 01:42 PM, Richard Biener wrote:
>> Index: gcc/testsuite/gcc.dg/tree-ss
On Mar 20, 2018, Jason Merrill wrote:
> On Sat, Mar 17, 2018 at 8:13 AM, Alexandre Oliva wrote:
>> As we go through each of the template parameters, substituting it with
>> corresponding template arguments, an incorrect argument list might
>> cause us to index argument vectors past their length
On 03/20/2018 07:18 PM, Bin Cheng wrote:
Hi,
As noted in PR84969, fuse_memset_builtins breaks dependence between different
memsets.
Specifically, it reorders different builtin memset partitions though it doesn't
merge
them in the end. This simple patch fixes this wrong code issue by checking i
This extends my previous fix for c++/84927 in that it also updates
the ctor's flags when we replace an element.
Bootstrapped/regtested on x86_64-linux, ok for trunk?
2018-03-20 Marek Polacek
PR c++/71638, ICE with NSDMI and reference.
* constexpr.c (cxx_eval_bare_aggregate): U
On 3/16/18 5:51 PM, Segher Boessenkool wrote:
> But fctiw is an ISA 1.xx instruction already (and fctid is as well,
> but explicitly undefined for 32-bit implementations until some 2.xx,
> I forgot which, 2.02 I think?)
>
> Requiring power8 for it is weird and surprising. power8-vector doubly so.
On Sat, Mar 10, 2018 at 6:57 AM, Alexandre Oliva wrote:
> If we get a parse error during an attempted fully implicit function
> template parse, and need to skip to the end of the statement or block,
> we may discard the function parms scope rather than the enclosing
> injected implicit template pa
On Tue, 2018-03-20 at 09:38 +0100, Rainer Orth wrote:
> Hi David,
>
> > Release managers:
> >
> > I'd like to apply FX's patch here:
> > https://gcc.gnu.org/ml/gcc-patches/2018-02/msg00881/patch
> > to trunk, to fix the build of jit on OS X, and to make it easier to
> > fix
> > it on Solaris.
>
Hi.
I'm sending removal of a stupid mistake where I installed a patch that contained
a debugging 'return' statement. Fixed that and added condition to inspect only
functions with SSA.
Patch can bootstrap on ppc64le-redhat-linux and survives regression tests.
Thanks,
Martin
gcc/ChangeLog:
2018
On 03/20/2018 01:36 PM, Martin Liška wrote:
> Hi.
>
> This is a work-around to not iterate all members of array that can be huge.
> As MPX will be removed in GCC 9.x, I hope it's acceptable. I don't want
> to come
> up with a new param for it.
>
> Survives tests&bootstrap on x86_64-linux-gnu.
>
Hi.
This is a work-around to not iterate all members of array that can be huge.
As MPX will be removed in GCC 9.x, I hope it's acceptable. I don't want to come
up with a new param for it.
Survives tests&bootstrap on x86_64-linux-gnu.
Martin
gcc/ChangeLog:
2018-03-20 Martin Liska
P
On 19/03/18 12:11, James Greenhalgh wrote:
On Wed, Mar 14, 2018 at 05:40:49PM +, Sudi Das wrote:
Hi
This patch is another partial fix for PR 84521. This is adding a
definition to one of the target hooks used in the SJLJ implemetation so
that AArch64 defines the hard_frame_pointer_rtx as the
On 03/20/2018 12:37 PM, Nathan Sidwell wrote:
This patch deprecates 2 sets of extensions
1) 'T v (init) __attribute__ ((ignored))'
That attribute placement has had no effect since the new parser (2002, I
think gcc 3.3). Now we're more noisy about it.
2) anonymous struct or union members cou
Codethink has several more changes that improve gfortran's ability to
handle legacy codebases, particularly those which rely on DEC
extensions. Most are strictly compiler side issues. However, one
touches on the runtime.
Specifically, as an extension, DEC Fortran allows omitting the width in
f
This patch deprecates 2 sets of extensions
1) 'T v (init) __attribute__ ((ignored))'
That attribute placement has had no effect since the new parser (2002, I
think gcc 3.3). Now we're more noisy about it.
2) anonymous struct or union members could be things other than public
non-static data
I've applied this patch to openacc-gcc-7-branch which backports Tom's
fix for the nvptx bar.sync placement bug in PR84952. This patch also
reverts some changes I introduced in git revision 7445a4d40.
Tom's patch didn't apply cleanly because of the recent I renamed
nvptx_wsync to nvptx_cta_sync so
On Sat, Mar 10, 2018 at 6:57 AM, Alexandre Oliva wrote:
> We ICEd when attempting to convert a default arg for an auto parm, the
> default arg amounting to a call to an undeclared function, in a
> declaration of a pointer to function variable.
This seems to have been fixed by my patch for 84798,
Hi,
As noted in PR84969, fuse_memset_builtins breaks dependence between different
memsets.
Specifically, it reorders different builtin memset partitions though it doesn't
merge
them in the end. This simple patch fixes this wrong code issue by checking if
any two
builtin memsets set the same rhs
On Tue, Mar 20, 2018 at 5:56 PM, Richard Biener
wrote:
> On March 20, 2018 6:11:53 PM GMT+01:00, "Bin.Cheng"
> wrote:
>>On Mon, Mar 19, 2018 at 5:08 PM, Aldy Hernandez
>>wrote:
>>> Hi Richard.
>>>
>>> As discussed in the PR, the problem here is that we have two
>>different
>>> iterations of an
On Sat, Mar 10, 2018 at 6:57 AM, Alexandre Oliva wrote:
> A parenthesized initializer is only accepted when new()ing an array in
> permissive mode. We were not careful, however, to convert the
> TREE_LIST initializer to the array element type in this extension.
> This patch fixes it: after turnin
On Tue, Mar 20, 2018 at 11:55 AM, Jason Merrill wrote:
> On Tue, Mar 20, 2018 at 9:32 AM, Marek Polacek wrote:
>> We started crashing on this test with r258592 which added
>> cp_get_callee_fndecl
>> in in cp_genericize_r.
>>
>> This ICE apparently depends on whether we perform NRVO or not. If
On March 20, 2018 6:11:53 PM GMT+01:00, "Bin.Cheng"
wrote:
>On Mon, Mar 19, 2018 at 5:08 PM, Aldy Hernandez
>wrote:
>> Hi Richard.
>>
>> As discussed in the PR, the problem here is that we have two
>different
>> iterations of an IV live outside of a loop. This inhibits us from
>using
>> autoinc
On 3/14/18 4:27 PM, Kelvin Nilsen wrote:
> @@ -14452,6 +14452,7 @@ altivec_expand_lv_builtin (enum insn_code icode, t
> LVXL and LVE*X expand to use UNSPECs to hide their special behavior,
> so the raw address is fine. */
>if (icode == CODE_FOR_altivec_lvx_v2df_2op
> + || icod
On 3/20/18 11:42 AM, Segher Boessenkool wrote:
> On Mon, Mar 19, 2018 at 09:12:08PM -0500, Peter Bergner wrote:
>> Looking at mu build dirs insn-modes.h, I don't see HAVE_V8HFmode being
>> defined on either my LE or BE builds. What am I missing?
>
> Nothing, I just was confused (we always define
Hi,
On Tue, 20 Mar 2018, Andreas Krebbel wrote:
> On 03/13/2018 04:53 PM, Michael Matz wrote:
> > Hi,
> >
> > On Tue, 13 Mar 2018, Andreas Krebbel wrote:
> >
> >> Leaving history aside don't you agree that it would have been more
> >> sensible to require a -m option only if you want to build f
Hi all,
This PR shows that we get the load/store_lanes logic wrong for arm big-endian.
It is tricky to get right. Aarch64 does it by adding the appropriate
lane-swapping
operations during expansion.
I'd like to do the same on arm eventually, but we'd need to port and validate
the VTBL-generati
On Mon, Mar 19, 2018 at 5:08 PM, Aldy Hernandez wrote:
> Hi Richard.
>
> As discussed in the PR, the problem here is that we have two different
> iterations of an IV live outside of a loop. This inhibits us from using
> autoinc/dec addressing on ARM, and causes extra lea's on x86.
>
> An abbrevia
On Sat, Mar 17, 2018 at 8:13 AM, Alexandre Oliva wrote:
> As we go through each of the template parameters, substituting it with
> corresponding template arguments, an incorrect argument list might
> cause us to index argument vectors past their length (or fail in the
> preceding tree checks). Av
On Sat, Mar 17, 2018 at 8:11 AM, Alexandre Oliva wrote:
> We shouldn't substitute templates into short-circuited-out concepts
> constraints, but we do, and to add insult to injury, we issue a
> sorry() error when a concept that shouldn't even have been substituted
> attempts to perform a multi-dim
On Tue, Mar 20, 2018 at 10:37 AM, Nathan Sidwell wrote:
> Jason, in parser.c
> /* The old parser allows attributes to appear after a parenthesized
> initializer. Mark Mitchell proposed removing this functionality
> on the GCC mailing lists on 2002-08-13. This parser accepts the
>
On Mon, Mar 19, 2018 at 09:12:08PM -0500, Peter Bergner wrote:
> On 3/12/18 1:55 PM, Segher Boessenkool wrote:
> >> #ifdef HAVE_V8HFmode
> >> - else if (mode == V8HFmode)
> >> - stvx = TARGET_64BIT
> >> -? gen_altivec_stvx_v8hf_1op (src_exp, memory_address)
> >> -: gen_altivec_stvx_v
On 03/13/2018 04:53 PM, Michael Matz wrote:
> Hi,
>
> On Tue, 13 Mar 2018, Andreas Krebbel wrote:
>
>> Leaving history aside don't you agree that it would have been more
>> sensible to require a -m option only if you want to build for an ABI
>> different from what is currently mandated by the p
On Tue, Mar 20, 2018 at 9:55 AM, Nathan Sidwell wrote:
> This fixes the 84962 ICE, which is where we name a member function of an
> anon-struct in the width specifier of a bitfield. The problem is that when
> permissive we allow some of this strangeness. Prior to my lookup changes, we
> only adde
On Fri, Mar 16, 2018 at 07:01:18PM -0400, Michael Meissner wrote:
> In patch #4, I mentioned that the spec 2006 benchmark 'tonto' generated
> different with the patches applied. I tracked it down, and it was due to the
> call I inserted in rs6000_debug_reg_print to update the conditional register
Hi Mike,
On Fri, Mar 16, 2018 at 12:50:45PM -0400, Michael Meissner wrote:
> --- gcc/config/rs6000/rs6000-output.c (revision 258576)
> +++ gcc/config/rs6000/rs6000-output.c (working copy)
> @@ -162,7 +162,13 @@ rs6000_output_move_64bit (rtx operands[]
>
>/* Moves to SPRs. */
>el
On Tue, Mar 20, 2018 at 9:32 AM, Marek Polacek wrote:
> We started crashing on this test with r258592 which added cp_get_callee_fndecl
> in in cp_genericize_r.
>
> This ICE apparently depends on whether we perform NRVO or not. If the size of
> S is <=16B we pass it in registers and it compiles f
This is another case of lookups escaping into template bodies, without
being marked. In this case an initializer list.
in the non-template case, we try and recycle these lookup nodes
immediately. But for templates we have to mark lookups, so we don't try
and mutate them via the binding. Whe
On 03/20/2018 04:28 PM, Gerald Pfeifer wrote:
> On Tue, 20 Mar 2018, Martin Liška wrote:
>> There's patch for couple of documentation issues reported in the PR.
>
> Looks good to me, thanks!
>
> Just, should there be an "a" in "use jump table"?
Looks good. And 'an indirect jump.' ?
Martin
>
>
Hi Andrew --
I just do a visual check. The script can help.
On 03/20/2018 07:13 AM, Andrew Sadek wrote:
Many Thanks Michael for the updates .. I was actually looking for something
similar for my test case .. I m currently revising the Gnu code conventions
on the patches then will send them aga
On Tue, 20 Mar 2018, Martin Liška wrote:
> There's patch for couple of documentation issues reported in the PR.
Looks good to me, thanks!
Just, should there be an "a" in "use jump table"?
Geralddiff --git a/gcc/calls.c b/gcc/calls.c
index 4dcfef77a5a..9eb0467311b 100644
--- a/gcc/calls.c
+++ b/g
Richard Biener writes:
> On Mon, Mar 19, 2018 at 10:27 PM, Richard Sandiford
> wrote:
>> Richard Biener writes:
>>> On Sat, Mar 17, 2018 at 11:45 AM, Richard Sandiford
>>> wrote:
Index: gcc/tree-data-ref.c
===
--- gc
On Tue, Mar 20, 2018 at 7:48 AM, Jan Hubicka wrote:
>> On Tue, Feb 27, 2018 at 11:39 AM, H.J. Lu wrote:
>> > For x86 targets, when -fno-plt is used, external functions are called
>> > via GOT slot, in 64-bit mode:
>> >
>> > [bnd] call/jmp *foo@GOTPCREL(%rip)
>> >
>> > and in 32-bit mode:
> On Tue, Feb 27, 2018 at 11:39 AM, H.J. Lu wrote:
> > For x86 targets, when -fno-plt is used, external functions are called
> > via GOT slot, in 64-bit mode:
> >
> > [bnd] call/jmp *foo@GOTPCREL(%rip)
> >
> > and in 32-bit mode:
> >
> > [bnd] call/jmp *foo@GOT[(%reg)]
> >
> > With
Jason, in parser.c
/* The old parser allows attributes to appear after a parenthesized
initializer. Mark Mitchell proposed removing this functionality
on the GCC mailing lists on 2002-08-13. This parser accepts the
attributes -- but ignores them. */
if (cp_parser_allow_gnu_ex
On Tue, Mar 20, 2018 at 01:42:04PM +0100, Richard Biener wrote:
> 2018-03-20 Richard Biener
>
> * testsuite/libgomp.graphite/force-parallel-4.c: XFAIL one
> parallelizable loop.
>
> Index: libgomp/testsuite/libgomp.graphite/force-parallel-4.c
> =
Hi.
There's patch for couple of documentation issues reported in the PR.
Ready for trunk?
Thanks,
Martin
gcc/ChangeLog:
2018-03-20 Martin Liska
PR other/84819
* calls.c (initialize_argument_information): Fix trailing space.
* common.opt: Fix typo and provide better e
Many Thanks Michael for the updates .. I was actually looking for something
similar for my test case .. I m currently revising the Gnu code conventions
on the patches then will send them again.
I m actually running the 'check_GNU_Style' in contrib folder,, is this the
correct way ? Is it enough ?
> On 03/13/2018 01:13 PM, Martin Liška wrote:
> > Hi.
> >
> > This is a fix for situation where we use -fno-guess-branch-probability and
> > fnsplit happens.
> >
> > Patch can bootstrap on ppc64le-redhat-linux and survives regression tests.
> >
> > Ready for trunk?
> > Thanks,
> > Martin
> >
>
This fixes the 84962 ICE, which is where we name a member function of an
anon-struct in the width specifier of a bitfield. The problem is that
when permissive we allow some of this strangeness. Prior to my lookup
changes, we only added TYPE_FIELDS and we still do that. Trouble is
that now con
On Mon, Mar 19, 2018 at 10:27 PM, Richard Sandiford
wrote:
> Richard Biener writes:
>> On Sat, Mar 17, 2018 at 11:45 AM, Richard Sandiford
>> wrote:
>>> Index: gcc/tree-data-ref.c
>>> ===
>>> --- gcc/tree-data-ref.c 2018-02-14 13:14
The way i originally made the code was going through ix86_rtx_costs
and factoring out/simplifying logic that translates directly to trees.
With NOP_EXPR I probably only tought of subgregs and other free stuff
which truly_noop_* probably simulates quite well.
ix86_rtx_costs understand how to zero
Hi,
On Tue, 20 Mar 2018, Jakub Jelinek wrote:
> It is very common that input is one of the above cases, during x86_64-linux
> and i686-linux bootstraps+regtests I got:
> 13201x CONST_INT, 1959x MEM, 114x SUBREG, 110x SYMBOL_REF,
> 2x PLUS (the new testcase only)
> and most of those were actually
On Mon, Mar 19, 2018 at 6:08 PM, Aldy Hernandez wrote:
> Hi Richard.
>
> As discussed in the PR, the problem here is that we have two different
> iterations of an IV live outside of a loop. This inhibits us from using
> autoinc/dec addressing on ARM, and causes extra lea's on x86.
>
> An abbrevia
On Tue, Mar 20, 2018 at 11:41:01AM +0100, Richard Biener wrote:
> If the precision matches the mode maybe. But I thought we try to
> avoid using %al (HImode) or %ax (QImode) operands in the end?
Yes, but we try to do that only on the level of the emitted assembly,
sometimes we simply emit a QImod
We started crashing on this test with r258592 which added cp_get_callee_fndecl
in in cp_genericize_r.
This ICE apparently depends on whether we perform NRVO or not. If the size of
S is <=16B we pass it in registers and it compiles fine. But if the size of S
is >16B, then we pass in memory, and
On Thu, Mar 15, 2018 at 01:04:30PM -0400, Michael Meissner wrote:
> This is patch #2 of my series for improving the PowerPC internal memory
> support. It assumes patch #1 has been applied.
>
> This patch moves the rs6000_move_128bit function from rs6000.c to a new file,
> rs6000-output.c.
>
> Th
On Tue, Mar 20, 2018 at 9:08 AM, Martin Liška wrote:
> Hi.
>
> The CHKP test-case ICEs for me and as CHKP will be removed in next stage1,
> I would like to remove the test-case. Will it be possible?
OK.
> Martin
>
> gcc/testsuite/ChangeLog:
>
> 2018-03-19 Martin Liska
>
> * gcc.dg/lto
> On Mon, 19 Mar 2018, Jan Hubicka wrote:
>
> > Hi,
> > this patch adds some documentation for what is new in IPA and x86.
> > For lto we should mention early-debug. Richard, perhaps you can suggest
> > wording?
>
> I have committed the following (will happily edit if necessary).
Great thanks a
1 - 100 of 132 matches
Mail list logo
