There's no reason why we wouldn't check for dependent scopes when
parsing the target of an alias declaration, and indeed not doing so led
to the ICE here.
The rest of the patch improves the diagnostic for this testcase (and
some others).
Tested x86_64-pc-linux-gnu, applying to trunk. Also a
Ok. I expect this also submitted to trunk later.
David
On Fri, Feb 21, 2014 at 2:08 PM, Rong Xu wrote:
> Hi,
>
> For builtins without nothrow attributes, we currently split bb by adding
> fake edge to func_exit in instrumenting profile counters. While it's safe,
> The resulted control flow and
emit_associated_thunks expects DECL_INTERFACE_KNOWN to be set, but we
weren't setting it in this case (as opposed to the case where the
destructor is implicitly declared) because it has
DECL_TEMPLATE_INSTANTIATION set. Fixed by checking for
DECL_DEFAULTED_FN as well.
Tested x86_64-pc-linux-g
To avoid problems trying to resolve an invalid use of 'this' before
diagnosing it later, let's do the same thing we do in
tsubst_default_argument, namely clear current_class_{ptr,ref}.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit f1051ca23020746350bacff3c499b2a9d1ec0dff
Author: Jason M
On 02/21/2014 09:10 AM, Jason Merrill wrote:
While parsing the template parameter list for a lambda, we've already
pushed into the closure class but haven't created the op()
FUNCTION_DECL, so trying to capture 'this' by way of the 'this' pointer
of op() breaks. Avoid the ICE by not trying to cap
My earlier massage_init_elt patch neglected to call
fold_non_dependent_expr before maybe_constant_init.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit b77241e3be8b3eb4247d07e2f2967cbb585e08bc
Author: Jason Merrill
Date: Fri Feb 21 14:37:17 2014 -0500
PR c++/60186
* typeck2.c
Yet another place where we need to check for bare parameter packs.
Tested x86_64-pc-linux-gnu, applying to trunk and 4.8.
commit 4e02d1498063b3ffa31d3fe35682b0c94667360c
Author: Jason Merrill
Date: Fri Feb 21 14:03:36 2014 -0500
PR c++/60187
* parser.c (cp_parser_enum_specifier): Ca
An earlier patch of mine changed the compiler to retain erroneous
declarations to provide better error-recovery behavior. But that's
causing problems with nested typedefs, so let's not bother in that case.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 85cffc1cc3fe706d61a417cf6a1139f546
We already have the code to reassign instances to the appropriate
template when we see a specialization of a partial instantiation of a
member template, but it wasn't firing properly in this case, for two
reasons:
1) We were attaching the instances to the most general template and then
lookin
The following patch fixes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60298
The patch was successfully bootstrapped on x86/x86-64.
Committed as rev. 208023.
2014-02-21 Vladimir Makarov
PR target/60298
* lra-constraints.c (inherit_reload_reg): Use lra_emit_move
inste
From: tschwinge
gcc/c-family/
* c-pragma.c (oacc_pragmas): Add "data".
* c-pragma.h (enum pragma_kind): Add PRAGMA_OACC_DATA.
gcc/c/
* c-parser.c (OACC_DATA_CLAUSE_MASK): New macro definition.
(c_parser_oacc_data): New function.
(c_parser_om
From: tschwinge
gcc/
* omp-low.c (scan_sharing_clauses): Catch unexpected occurrences
of OMP_CLAUSE_TO, OMP_CLAUSE_FROM, OMP_CLAUSE_MAP.
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/branches/gomp-4_0-branch@208015
138bc75d-0d04-0410-961f-82ee72b054a4
---
gcc/ChangeLog.gomp
From: tschwinge
gcc/
* gimple.h (enum gf_mask): Add GF_OMP_TARGET_KIND_OACC_DATA.
(is_gimple_omp_oacc_specifically): Handle it.
* gimple-pretty-print.c (dump_gimple_omp_target): Likewise.
* gimplify.c (gimplify_omp_workshare, gimplify_expr): Likewise.
Hi!
On Tue, 14 Jan 2014 16:10:05 +0100, I wrote:
> --- gcc/gimplify.c
> +++ gcc/gimplify.c
> @@ -86,7 +92,11 @@ enum omp_region_type
>ORT_UNTIED_TASK = 5,
>ORT_TEAMS = 8,
>ORT_TARGET_DATA = 16,
> - ORT_TARGET = 32
> + ORT_TARGET = 32,
> +
> + /* Flags for ORT_TARGET. */
> + /* Def
Hi!
On Tue, 11 Feb 2014 17:51:15 +0100, I wrote:
> On Fri, 31 Jan 2014 15:16:07 +0400, Ilmir Usmanov
> wrote:
> > --- a/gcc/omp-low.c
> > +++ b/gcc/omp-low.c
> > @@ -1491,6 +1491,18 @@ fixup_child_record_type (omp_context *ctx)
> >TREE_TYPE (ctx->receiver_decl) = build_pointer_type (type);
>
On Thu, Feb 20, 2014 at 2:46 PM, Bill Schmidt
wrote:
> Hi,
>
> For compatibility with the XL compilers, we need to support -maltivec=be
> for vec_ld, vec_ldl, vec_st, and vec_stl. (A later patch will also
> handle vec_lde and vec_ste.)
>
> This is a much simpler patch than its size would indicate
Hello!
No additional testsuite failures.
2014-02-21 Uros Bizjak
* g++.dg/other/i386-2.C (dg-options): Add -mavx512pf.
* g++.dg/other/i386-3.C (dg-options): Ditto.
* gcc.target/i386/sse-12.c (dg-options): Add -msha.
* gcc.target/i386/sse-13.c (dg-options): Add -mavx512er, -mavx
On Fri, Feb 21, 2014 at 12:56 PM, Bill Schmidt
wrote:
> Hi,
>
> The little-endian implementation of vec_sums is incorrect. I had
> misread the specification and thought that the fields not containing the
> result value were undefined, but in fact they are defined to contain
> zero. My previous i
2014-02-21 19:41 GMT+04:00 Bernd Schmidt :
> The problem is that ptx does not have a linker, so we cannot exactly
> reproduce what happens on the host side. We have to process all host .o
> files in one single invocation of ptx lto1, and produce a single ptx
> assembly file, with a single function/
Hi,
The little-endian implementation of vec_sums is incorrect. I had
misread the specification and thought that the fields not containing the
result value were undefined, but in fact they are defined to contain
zero. My previous implementation used a vector splat to copy the field
from BE elemen
On Fri, Feb 21, 2014 at 4:25 PM, Ilya Tocar wrote:
>> > Latest version of AVX512 spec
>> > http://download-software.intel.com/sites/default/files/managed/50/1a/319433-018.pdf
>> > Has a few changes.
>> >
>> > 1)PREFETCHWT1 instruction now has separate CPUID bit PREFETCHWT1.
>> > We can either supp
> Hi,
>
> in propagate_constants_accross_call we expect a thunk to have at least
> one parameter and thus an ipa-prop parameter descriptor. However,
> when the callee comes from a CU that was compiled with -O0, there are
> no parameter descriptors and we fail an index checking assert.
>
> This p
On 2/21/2014, 2:22 AM, Andrey Belevantsev wrote:
Hello,
While fixing PR 58960 I forgot about single-block regions placing the
initialization of the new nr_regions_initial variable in the wrong
place. Thus for single block regions we ended up with nr_regions = 1 and
nr_regions_initial = 0 and eff
thanks for the fix!
David
On Fri, Feb 21, 2014 at 12:21 AM, Jakub Jelinek wrote:
> Hi!
>
> As discussed in the PR, on larger functions we can end up with
> over 3 million of compute_control_dep_chain nested calls from
> a single compute_control_dep_chain call, on that testcase all that
> effort
Hi,
When a shuffle of more than one input happens, on NEON we end up with a
'mixed-endian' format in the register list which TBL operates on. We don't make
this correction in RTL and therefore the shuffle operation gets it incorrect.
Here is a patch that fixes-up the index table in the select
Committed to branch dmalcolm/jit:
Add a new "gcc_jit_context_dump_to_file", which dumps a C-like
representation of the context's IR to a given path.
There is also a flag "update_locations", which, when true, will set up
gcc_jit_location information throughout the context, pointing at the dump
fil
On 02/21/2014 03:19 AM, Adam Butcher wrote:
A class template with an out-of-line generic function definition will
give the same issue I think:
template
void A::f(auto x) {} // should inject a new list
Right. template_class_depth should be useful here. This is basically
the same ques
On 02/21/2014 04:17 PM, Ilya Verbin wrote:
2014-02-20 22:27 GMT+04:00 Bernd Schmidt :
There were still a number of things in these patches that did not make sense
to me and which I've changed. Let me know if there was a good reason for the
way some of these things were originally done.
* Funct
> > Latest version of AVX512 spec
> > http://download-software.intel.com/sites/default/files/managed/50/1a/319433-018.pdf
> > Has a few changes.
> >
> > 1)PREFETCHWT1 instruction now has separate CPUID bit PREFETCHWT1.
> > We can either support new CPUID or disable PREFETCHWT1 from generating,
> >
2014-02-20 22:27 GMT+04:00 Bernd Schmidt :
> There were still a number of things in these patches that did not make sense
> to me and which I've changed. Let me know if there was a good reason for the
> way some of these things were originally done.
> * Functions and variables now go into differen
This patch benefits from the discussion of array deduction at last
week's C++ standardization committee meeting, where we clarified that we
should only try to deduce the array bound from an initializer-list if
the array bound is deducible, i.e. if it's a non-type template
parameter. We also sh
This are the patches as applied
Built and tested x86_64-linux.
2014-02-20 Ed Smith-Rowland <3dw...@verizon.net>
Rename shared_mutex to shared_timed_mutex per C++14 acceptance of N3891.
* include/std/shared_mutex: Rename shared_mutex to shared_timed_mutex.
* testsuite/3
On 19/02/14 10:18, Ian Bolton wrote:
> Hi,
>
> Patterns had previously been added to thumb2.md to support ORN, but only for
> SImode.
>
> This patch adds DImode support, to cover the full 64|64->64 operation and
> the various 32|64->64 operations (see AND:DI variants that use NOT).
>
> The patch
Hi,
in propagate_constants_accross_call we expect a thunk to have at least
one parameter and thus an ipa-prop parameter descriptor. However,
when the callee comes from a CU that was compiled with -O0, there are
no parameter descriptors and we fail an index checking assert.
This patch fixes it by
On Fri, 21 Feb 2014, Richard Biener wrote:
> On Fri, 21 Feb 2014, Richard Biener wrote:
>
> > On Fri, 21 Feb 2014, Richard Sandiford wrote:
> >
> > > In a thread a few years ago you talked about the possibility of going
> > > further and folding the attributes into the MEM itself, so avoiding
>
We need to propagate DECL_DELETED_FN to clones when we get a new
specialization.
Tested x86_64-pc-linux-gnu, applying to trunk and 4.8.
commit eaf1689e134ff4fb364c0045965b19879bff8f32
Author: Jason Merrill
Date: Fri Feb 21 08:47:01 2014 -0500
PR c++/60216
* pt.c (register_specializ
In coerce_template_parms, if we try to pack the remaining arguments into
an argument pack and that fails, we should immediately stop trying to
process more arguments.
Tested x86_64-pc-linux-gnu, applying to trunk and 4.8.
commit 1555baa24f537d0e724c53845e7ba2881df7a77f
Author: Jason Merrill
Da
We shouldn't treat a CONSTRUCTOR as an init-list if it already has a type.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 8e1493a7a31ffdb1e70977c325e7d2f2686b14a7
Author: Jason Merrill
Date: Fri Feb 21 00:52:20 2014 -0500
PR c++/60224
* decl.c (cp_complete_array_type, maybe_d
mangle_decl shouldn't try to make a forward-compatibility alias for a
TYPE_DECL, since they don't have symbols.
Tested x86_64-pc-linux-gnu, applying to trunk, 4.7, 4.8.
commit 8d40d9322f567ba5720ac807168232ae3c5ee0e4
Author: Jason Merrill
Date: Fri Feb 21 00:39:25 2014 -0500
PR c++/6024
While parsing the template parameter list for a lambda, we've already
pushed into the closure class but haven't created the op()
FUNCTION_DECL, so trying to capture 'this' by way of the 'this' pointer
of op() breaks. Avoid the ICE by not trying to capture 'this' when
parsing a parameter list.
Hi Philipp,
On 18/02/14 21:09, Philipp Tomsich wrote:
The default target should be "generic", as Cortex-A53 includes
optional ISA features (CRC and CRYPTO) that are not required for
architectural compliance. The key difference between generic (which
already uses the cortexa53 pipeline model for
A type-dependent expression can have NULL TREE_TYPE, and if we wrap it
in a NOP_EXPR also with NULL type, that confuses things. Let's not try
to do that.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 5564347b2b7b39d92f8f3b8307bc8ed8551e4d91
Author: Jason Merrill
Date: Thu Feb 20 23:
is_normal_capture_proxy got confused by the contortions we go through to
build up a capture proxy for a VLA capture, so it's easier to just check
for variably modified type.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 1fa864d218992c8a1b9b1fd4fae2205d5572205b
Author: Jason Merrill
Dat
My patch for 58606 was incomplete; there were other places that needed
to change to handle dereferencing reference non-type template parameters.
Tested x86_64-pc-linux-gnu, applying to trunk. I reverted the earlier
58606 patch on the 4.8 branch.
commit 7b1bb4515ae768ca44e192442d2578ea46c16f96
On Fri, 21 Feb 2014, Richard Biener wrote:
> On Fri, 21 Feb 2014, Richard Sandiford wrote:
>
> > Richard Biener writes:
> > > On Fri, 21 Feb 2014, Richard Biener wrote:
> > >
> > >> On Fri, 21 Feb 2014, Richard Biener wrote:
> > >>
> > >> > On Fri, 21 Feb 2014, Richard Biener wrote:
> > >> >
>
On Fri, 21 Feb 2014, Richard Sandiford wrote:
> Richard Biener writes:
> > On Fri, 21 Feb 2014, Richard Biener wrote:
> >
> >> On Fri, 21 Feb 2014, Richard Biener wrote:
> >>
> >> > On Fri, 21 Feb 2014, Richard Biener wrote:
> >> >
> >> > >
> >> > > This fixes the slowness of RTL expansion in
Sir,
I have a cross compiler and I know how to cross compile a file . But I
am doing all just for glib compilation that I do not know how to do. Anyone
to guide me. or generally just inform me how can I compile a complete
library using gcc.
--
View this message in context:
http://gcc.10653
On Fri, 21 Feb 2014, Richard Biener wrote:
> On Fri, 21 Feb 2014, Richard Biener wrote:
>
> > Last statistics: http://gcc.gnu.org/ml/gcc-patches/2011-08/msg01784.html
>
> With the patch below to get some statistics we see that one important
> piece of sharing not covered by above measurements is
Richard Biener writes:
> On Fri, 21 Feb 2014, Richard Biener wrote:
>
>> On Fri, 21 Feb 2014, Richard Biener wrote:
>>
>> > On Fri, 21 Feb 2014, Richard Biener wrote:
>> >
>> > >
>> > > This fixes the slowness of RTL expansion in PR60291 which is caused
>> > > by excessive collisions in mem-att
On 13/02/14 17:43, Richard Henderson wrote:
On 02/13/2014 03:17 AM, Alex Velenko wrote:
+/* Sets "rmode" field of "FPCR" control register to
+ "FPROUNDING_ZERO". */
Comment is wrong, or at least misleading.
+void __inline __attribute__ ((__always_inline__))
+set_rounding_mode (uint32_t mo
On Fri, 21 Feb 2014, Richard Biener wrote:
> On Fri, 21 Feb 2014, Richard Biener wrote:
>
> > On Fri, 21 Feb 2014, Richard Biener wrote:
> >
> > >
> > > This fixes the slowness of RTL expansion in PR60291 which is caused
> > > by excessive collisions in mem-attr sharing. The issue here is
> >
OK to trunk and 4.8?
-Original Message-
From: Joey Ye [mailto:joey...@arm.com]
Sent: 2014年2月21日 19:32
To: gcc-patches@gcc.gnu.org
Subject: [patch] [arm] Fix PR60169 - thumb1 far jump
Patch http://gcc.gnu.org/ml/gcc-patches/2012-12/msg01229.html introduced
this ICE:
1. thumb1 estimate if
Patch http://gcc.gnu.org/ml/gcc-patches/2012-12/msg01229.html introduced
this ICE:
1. thumb1 estimate if far_jump is used based on function insn size
2. During reload, after stack layout finalized, it does reload_as_needed. It
however increases insn size that changes estimation result of far_jump,
On Fri, 21 Feb 2014, Richard Biener wrote:
> On Fri, 21 Feb 2014, Richard Biener wrote:
>
> >
> > This fixes the slowness of RTL expansion in PR60291 which is caused
> > by excessive collisions in mem-attr sharing. The issue here is
> > that sharing attempts happens across functions and we have
Hi,
unless we have reasons to believe that the diagnostic quality could
regress in some circumstances, we can easily resolve this ICE on invalid
regression by always returning error_mark_node after error (thus outside
SFINAE too).
Tested x86_64-linux.
Thanks,
Paolo.
///
On Fri, 21 Feb 2014, Bin.Cheng wrote:
> On Thu, Feb 20, 2014 at 10:51 PM, Richard Biener wrote:
> >
> > The following fixes an ICE I got when building libjava with a local
> > patch. This causes us to substitute &MEM[&a, 5] into MEM[_3, 0]
> > to MEM[&MEM[&a, 5], 0] and then asking stmt_ends_bb_
On Fri, 21 Feb 2014, Richard Biener wrote:
>
> This improves compile-time of PR60291 at -O1 from 210s to 85s,
> getting remove unused locals out of the profile. There walking
> DECL_INITIAL of globals is quadratic when that is refered to from
> multiple functions. We've had the same issue with
On Fri, Feb 21, 2014 at 11:32:41AM +0100, Richard Biener wrote:
>
> This attempts to fix PR60276 - the fact that the vectorizer dependence
> analysis is run too early and that it invalidates assumptions it
> makes there later. The specific issue in question arises when
> the vectorizer needs to e
On Thu, Feb 20, 2014 at 10:51 PM, Richard Biener wrote:
>
> The following fixes an ICE I got when building libjava with a local
> patch. This causes us to substitute &MEM[&a, 5] into MEM[_3, 0]
> to MEM[&MEM[&a, 5], 0] and then asking stmt_ends_bb_p which doesn't
> expect such bogus MEM_REFs. Th
This attempts to fix PR60276 - the fact that the vectorizer dependence
analysis is run too early and that it invalidates assumptions it
makes there later. The specific issue in question arises when
the vectorizer needs to effectively unroll the loop and by
performing all vectorized loads first an
On Fri, 21 Feb 2014, Richard Biener wrote:
>
> This fixes the slowness of RTL expansion in PR60291 which is caused
> by excessive collisions in mem-attr sharing. The issue here is
> that sharing attempts happens across functions and we have a _lot_
> of functions in this testcase referencing the
This fixes the slowness of RTL expansion in PR60291 which is caused
by excessive collisions in mem-attr sharing. The issue here is
that sharing attempts happens across functions and we have a _lot_
of functions in this testcase referencing the same lexically
equivalent memory, for example MEM[(St
This improves compile-time of PR60291 at -O1 from 210s to 85s,
getting remove unused locals out of the profile. There walking
DECL_INITIAL of globals is quadratic when that is refered to from
multiple functions. We've had the same issue with
add_referenced_vars when that still existed.
Bootstra
Hi!
On Fri, 15 Nov 2013 14:44:45 -0700, Aldy Hernandez wrote:
> Attached is the final version of the patch I have committed to trunk.
> --- a/gcc/gimple-pretty-print.c
> +++ b/gcc/gimple-pretty-print.c
> @@ -1118,6 +1118,8 @@ dump_gimple_omp_for (pretty_printer *buffer, gimple gs,
> int spc, in
On Fri, 21 Feb 2014, Jakub Jelinek wrote:
> Hi!
>
> As discussed in the PR, on larger functions we can end up with
> over 3 million of compute_control_dep_chain nested calls from
> a single compute_control_dep_chain call, on that testcase all that
> effort just to get zero or at most one (useless
2014-02-21 8:25 GMT+01:00 Tobias Burnus :
> Hi Janus,
>
> Janus Weil wrote:
>>
>> What the patch does is to defer the building of the vtabs to a later
>> stage. Previously this was done only for some rare cases, now we do it
>> basically for all vtabs. This is necessary with finalization, since
>>
Hello,
Would anyone be able to (re-)approve this patch, please?
It should be really really straightforward, and only adds a DWARF
flag to Ada Compilation Units, so I should think that the risk
is near zero. I've tested the patch as usual regardless.
Parallel to that, we have also started working
Hi!
As discussed in the PR, on larger functions we can end up with
over 3 million of compute_control_dep_chain nested calls from
a single compute_control_dep_chain call, on that testcase all that
effort just to get zero or at most one (useless) control dep path.
The problem is that the function is
On 2014-02-20 16:18, Jason Merrill wrote:
On 02/19/2014 10:00 PM, Adam Butcher wrote:
+ if (current_template_parms)
+{
+ cp_binding_level *maybe_tmpl_scope =
current_binding_level->level_chain;
+ while (maybe_tmpl_scope && maybe_tmpl_scope->kind ==
sk_class)
+ maybe_tmpl_
Hi Guys,
I am applying the patch below to add modes to the POST_INC and PRE_DEC
patterns in the XStormy16 backend. The lack of the modes was leading
to some build problems.
Cheers
Nick
gcc/ChangeLog
2014-02-21 Nick Clifton
* config/stormy16/stormy16.md (pushdqi1): Add mode t
70 matches
Mail list logo
