The patch below eliminates almost all cases of build_function_type in
the Fortran FE. (The last case uses TYPE_ARG_TYPES directly and will
need to be dealt with separately.) This is accomplished by introducing
two new functions, build_{,varargs_}function_type_array, which do what
you think, and t
On Tue, May 03, 2011 at 07:06:58PM +, Joseph S. Myers wrote:
> In my view we should require front ends to take responsibility for
> variable-size types, and get rid of this language-independent function
> (copying such parts as are needed into the front ends that need them). C
> for example
On Tue, May 03, 2011 at 07:27:24PM +, Joseph S. Myers wrote:
> On Tue, 3 May 2011, Nathan Froyd wrote:
> > The raft of changes/improvements enabled by this change would be most
> > welcome. *_SIZE becoming double_ints or HOST_WIDE_INT instead of trees
> > is the first thi
As $SUBJECT suggests; the patch makes the Ada FE use iterators instead.
Tested on x86_64-unknown-linux-gnu. OK to commit?
-Nathan
* gcc-interface/decl.c (intrin_arglists_compatible_p): Use iterators
instead of accessing TYPE_ARG_TYPES directly.
* gcc-interface/utils.c (h
On Wed, May 04, 2011 at 08:30:40AM -0400, Richard Kenner wrote:
> > There are pros and cons about early optimization, actually.
> > Generating extremely optimized IL very early can actually tie up
> > subsequent passes. For instance, loop unrolling and vectorization.
> > There are others in the li
On Wed, May 04, 2011 at 11:22:02AM +0200, Tobias Burnus wrote:
> On 05/03/2011 09:06 PM, Nathan Froyd wrote:
>> Testing in progress on x86_64-unknown-linux-gnu. OK to commit if
>> testing successful?
>
> The Fortran part is OK. Thanks for the janitorial work.
Thanks for the
As $SUBJECT suggests. The patch is somewhat larger than it needs to be
due to reindenting c-common.c:check_main_parameter_types.
Tested on x86_64-unknown-linux. OK to commit?
-Nathan
gcc/c-family/
* c-common.c (check_main_parameter_types): Reindent. Don't use
TYPE_ARG_TYPES di
As promised in http://gcc.gnu.org/ml/gcc-patches/2011-05/msg00211.html .
Tested by building f951. Committed as r173386.
-Nathan
gcc/fortran/
* trans.h (gfc_chainon_list): Delete.
* trans.c (gfc_chainon_list): Delete.
Index: gcc/fortran/ChangeLog
On Wed, May 04, 2011 at 10:44:14AM -0700, Mike Stump wrote:
> On May 3, 2011, at 10:27 PM, Michael Witten wrote:
> > To what do we owe this tradition other than laziness?
>
> By flat out rejecting style fixing patches, you preserve the
> annotations made by vc-blame (svn blame). That's the only r
The last remaining uses of build_function_type in the ObjC/C++ frontends
comes from this pattern:
tree method_param_types =
get_arg_type_list (method_prototype, METHOD_REF, super_flag);
tree ftype = build_function_type (ret_type, method_param_types);
To eliminate this, I made the followin
The patch below introduces simple accessors for getting at the class or
the type of the `this' parameter. It hides a couple of TYPE_ARG_TYPES
usages and makes the code slightly more obvious, I think.
Tested on x86_64-unknown-linux-gnu. OK to commit?
-Nathan
gcc/cp/
* cp-tree.h (type_of
Following on:
http://gcc.gnu.org/ml/gcc-patches/2011-03/msg00563.html
and the review received in:
http://gcc.gnu.org/ml/gcc-patches/2011-04/msg00651.html
I present the patch below. We have a new function,
cp_tree_operand_length, and the code has been retrofitted to use it in
various places.
T
As $SUBJECT suggests. Eradicating build_function_type from the C FE
entirely will take a bit more work.
The lto change is included because def_fn_type there is clearly a copy
of the C version; I am going to assume that given other approvals of
copy-paste code, this one is obvious.
Tested on x86_
As $SUBJECT suggests. Rather pleasant how easy this was.
Tested on x86_64-unknown-linux-gnu. OK to commit?
-Nathan
gcc/ada/
* gcc-interface/utils.c (def_fn_type): Don't call build_function_type;
call build_function_type_vec or build_varargs_function_type_vec
instead.
As $SUBJECT suggests. Nothing much to see here.
Tested on x86_64-unknown-linux-gnu. OK to commit?
-Nathan
gcc/java/
* expr.c (build_jni_stub): Don't call build_function_type; call
build_function_type_vec instead.
* typeck.c (parse_signature_string): Likewise.
diff --gi
tree_type is a fairly big structure, and several of its fields are
overloaded. This means we waste some space, depending on the type, and
it's also somewhat confusing as to who uses what.
The patch below implements the first step towards "tuplifying types":
those pieces which all types use have b
On Tue, May 10, 2011 at 02:28:06PM -0300, Diego Novillo wrote:
> On Tue, May 10, 2011 at 13:15, Nathan Froyd wrote:
> > Other types can of course be shrunk, but the memory savings from doing
> > so will be negligible
>
> Have you done any measurements on the potential savin
On Fri, Mar 11, 2011 at 02:19:14PM +0100, Richard Guenther wrote:
> On Fri, Mar 11, 2011 at 5:23 AM, Nathan Froyd
> wrote:
> > Move CASE_CHAIN into a local operand for CASE_LABEL_EXPR. Nothing to
> > see here.
>
> I wonder if there isn't a better way to do t
On 03/10/2011 11:23 PM, Nathan Froyd wrote:
After all that, we can finally make tree_exp inherit from typed_tree.
Quite anticlimatic.
Ping. http://gcc.gnu.org/ml/gcc-patches/2011-03/msg00559.html
-Nathan
The comment for pointer_map_traverse says:
/* Pass each pointer in PMAP to the function in FN, together with the pointer
to the value and the fixed parameter DATA. If FN returns false, the
iteration stops. */
However, the code in tree-cfg:edge_to_cases_cleanup does:
static bool
edge_to
On 05/13/2011 10:52 AM, William J. Schmidt wrote:
> This patch addresses PR46728, which notes that pow and powi need to be
> lowered in tree phases to restore lost FMA opportunities and expose
> vectorization opportunities.
>
> +struct gimple_opt_pass pass_lower_pow =
> +{
> + {
> + GIMPLE_PASS,
>
On 05/13/2011 11:26 AM, Richard Guenther wrote:
> On Fri, May 13, 2011 at 5:01 PM, Nathan Froyd
> wrote:
>> On 05/13/2011 10:52 AM, William J. Schmidt wrote:
>>> This patch addresses PR46728, which notes that pow and powi need to be
>>> lowered in tree phases to
On 05/15/2011 08:49 PM, Gabriel Dos Reis wrote:
> On Sun, May 15, 2011 at 7:13 PM, Nicola Pero
> wrote:
>> This patch adds a new GTY option, "atomic", which is similar to the
>> identical option you have with Boehm GC
>> and which can be used with pointers to inform the GC/PCH machinery that they
On 05/10/2011 04:18 PM, Nathan Froyd wrote:
> On 03/10/2011 11:23 PM, Nathan Froyd wrote:
>> After all that, we can finally make tree_exp inherit from typed_tree.
>> Quite anticlimatic.
>
> Ping. http://gcc.gnu.org/ml/gcc-patches/2011-03/msg00559.html
Ping^2.
-Nathan
On 05/18/2011 01:45 PM, Jason Merrill wrote:
>> Thanks for the background; I will keep the principle in mind. IMHO, in
>> a case like this where we're logically printing one diagnostic (one
>> error and then some number of explanatory notes) keeping all the logic
>> for the diagnostic centralized
This patch removes one of the two remaining uses of TYPE_ARG_TYPES in
the ObjC/C++ frontends. (The other one should be addressed in a
different manner.) Given the constraints of the function_args_iterator
interface, I thought rewriting the logic of the loop would make things
slightly clearer.
Te
As $SUBJECT suggests. It may be worth noting that we now do more work
after this patch (stdarg_p and prototype_p both traverse TYPE_ARG_TYPES
under the hood); one day those will be simple boolean tests.
Tested on x86_64-unknown-linux-gnu with go. OK to commit?
-Nathan
gcc/
* godump.c (
f comments, I plan to check this in in 24 hours.
-Nathan
gcc/
2011-03-04 Paul Wörgerer
* gimplify.c (gimplify_function_tree): Fix building calls
to __builtin_return_address.
gcc/testsuite/
2011-03-04 Paul Wörgerer
Nathan Froyd
* gcc.dg/20001117-1.c: Abo
On Fri, Mar 04, 2011 at 10:00:15AM -0500, Nathan Froyd wrote:
> Paul Wörgerer noticed that -finstrument-functions does do what it says
> on the tin
That's Paul *Wögerer*, fixed in the ChangeLog entries as well; sorry about
that!
-Nathan
On Wed, Feb 23, 2011 at 11:14:08AM -0800, Nathan Froyd wrote:
> The patch below fixes PR 47786, a bit of DECL_CHAIN fallout. The patch
> is trivial, even obvious, since it replaces the custom loop with
> list_length.
>
> The only problem is adding a testcase. I can't add the
atches
were not developed in this order; the checking bits were introduced
first, then any bootstrap or testsuite failures were fixed up, then the
patches were committed in the proper order.
Nathan Froyd (18):
add typed_tree structure
enforce TREE_CHAIN and TREE_TYPE accesses
remove TREE_CHAIN f
The first step in removing TREE_CHAIN (and even TREE_TYPE) from a select
few nodes is to create separate substructures for trees-with-type and
trees-with-chain. Since trees-with-type but no chain are expected to be
more common that vice versa, make the hierarchy reflect that. Modify a
few macros
*_CST nodes don't need TREE_CHAIN. Make them include typed_tree instead,
mark them as such in initialize_tree_contains_struct, and don't print out
their TREE_CHAIN.
-Nathan
gcc/
* tree.h (struct tree_int_cst, struct real_value): Include typed_tree
instead of tree_common.
A straightforward conversion.
-Nathan
gcc/
* tree.h (struct tree_constructor): Include typed_tree instead of
tree_common.
* tree.c (initialize_tree_contains_struct): Mark TS_CONSTRUCTOR as
TS_TYPED instead of TS_COMMON.
diff --git a/gcc/tree.c b/gcc/tree.c
index 0
This conversion is straightforward. The tricky part is converting
FREE_SSANAMES into a VEC to eliminate the only use of TREE_CHAIN on
SSA_NAMEs.
-Nathan
gcc/
* tree-flow.h (struct gimple_df): Make free_ssanames a VEC.
* tree-ssanames.c (fini_ssanames): VEC_free it.
(make_
This patch begins a subseries of patches aimed at removing TREE_CHAIN
from expression trees. tree-cfg.c uses TREE_CHAIN for some analysis
steps on CASE_LABEL_EXPRs. I looked at this for a while, thinking it'd
be easy to use VECs instead, but AFAICS, it wasn't. I went for the next
best thing, hid
C++'s FOR_STMT and RANGE_FOR_STMT store the scope in which they occur in
the TREE_CHAIN field of tree_exp. If we're going to remove TREE_CHAIN,
that won't work very well. This patch introduces an extra tree operand
to both tree kinds, accessor macros for those operands, and tweaks the
code to use
Just like the previous patches, except with SWITCH_STMT.
-Nathan
gcc/cp/
* cp-tree.def (SWITCH_STMT): Add an extra operand.
* cp-objcp-common.c (cp_common_init_ts): Mark it as TS_TYPED.
* cp-tree.h (SWITCH_STMT_SCOPE): Define.
* semantics.c (begin_switch__stmt): Pa
If we're going to add another TREE_OPERAND to CASE_LABEL_EXPR, then we'd
have to update a number of calls to buildN or similar to know about the
new operand. But that's not a good idea; the new operand is a strictly
private thing and FEs in particular shouldn't have to know anything
about it. Ins
After all that, we can finally make tree_exp inherit from typed_tree.
Quite anticlimatic.
-Nathan
gcc/
* tree.h (struct tree_exp): Inherit from struct typed_tree.
* tree.c (initialize_tree_contains_struct): Mark TS_EXP as TS_TYPED
instead of TS_COMMON.
diff --git a/gcc/tr
Now that we've done the requisite surgery on the C++ FE, we can
eliminate TREE_CHAIN and TREE_TYPE from IDENTIFIER_NODEs. Doing so
turns up a couple different places that need to be tweaked.
The bit I'm not quite sure about is free_lang_data_in_decl and
find_decls_types_r. Previously, due to C++
STATEMENT_LISTs use TREE_CHAIN for approximately nothing, so let's try
to shrink them. This patch involves quite a bit of refactoring in the C
and C++ FEs, as they used TREE_CHAIN to hold a stack of STATEMENT_LISTs
being built. Most of the noise comes from unifying the checking macro
name between
IDENTIFIER_NODE is next up for a shrinking. To do that, though, we have
to do some surgery on the C++ FE, as it uses TREE_TYPE (!) of such nodes
to store local data. Fortunately, we can move that information into
lang_identifier; unfortunately, that means we need to introduce a number
of conditio
Just like the previous *FOR_STMT conversions, except with IF_STMTs.
-Nathan
gcc/cp/
* cp-tree.def (IF_STMT): Add an extra operand.
* cp-objcp-common.c (cp_common_init_ts): Mark it as TS_TYPED.
* cp-tree.h (IF_SCOPE): Define.
* semantics.c (begin_if_stmt): Pass scop
Now that we have a structure where not every node might include
TREE_CHAIN or TREE_TYPE, we need to make sure that when we call said
accessors that the argument is properly typed. This requires a number
of changes:
- It's not enough for FEs to assume that FE-specific DECLs are the only
tree tha
EXPR_PACK_EXPANSION nodes store things in TREE_CHAIN, for symmetry with
TYPE_PACK_EXPANSIONs. In the interest of expendiency towards slimming
tree_exp, this patch moves EXPR_PACK_EXPANSION's use of TREE_CHAIN into
a local TREE_OPERAND. I suppose the conditional would be needed in any
event later
BLOCKs have a TREE_CHAIN and a TREE_TYPE; TREE_TYPE is useless for
blocks, but we can't remove TREE_TYPE without also removing TREE_CHAIN.
This patch lays the groundwork to do just that. It changes places that
use chainon on BLOCKs to use block_chainon, which works identically to
chainon except it
Now that we've encapsulated all uses of BLOCK_CHAINON properly, we can
make BLOCKs inherit from tree_base and redirect BLOCK_CHAINON to use a
tree_block-private field instead of tree_common's chain. Doing so saves
the never-used TREE_TYPE field.
-Nathan
gcc/
* tree.c (initialize_tree_co
Move CASE_CHAIN into a local operand for CASE_LABEL_EXPR. Nothing to
see here.
-Nathan
gcc/
* tree.def (CASE_LABEL_EXPR): Add an operand.
* tree.h (CASE_CHAIN): Use TREE_OPERAND instead of TREE_CHAIN.
diff --git a/gcc/tree.def b/gcc/tree.def
index eb94ad2..9c6606d 100644
--- a/g
On Fri, Mar 11, 2011 at 01:01:37AM -0500, Jason Merrill wrote:
> On 03/10/2011 11:23 PM, Nathan Froyd wrote:
>> The new checks in add_stmt are
>> required to make sure that cur_stmt_list can always point at something
>> when calling append_to_statement_list_force.
>
> Wh
On Fri, Mar 11, 2011 at 02:15:20PM +0100, Richard Guenther wrote:
> On Fri, Mar 11, 2011 at 5:23 AM, Nathan Froyd
> wrote:
> > BLOCKs have a TREE_CHAIN and a TREE_TYPE; TREE_TYPE is useless for
> > blocks, but we can't remove TREE_TYPE without also removing TREE_CHAIN.
On Fri, Mar 11, 2011 at 02:25:38PM +0100, Richard Guenther wrote:
> On Fri, Mar 11, 2011 at 5:23 AM, Nathan Froyd
> wrote:
> > This patch series does something similar to what:
> >
> > http://gcc.gnu.org/ml/gcc-patches/2010-11/msg02491.html
> >
> > did, onl
On Fri, Mar 11, 2011 at 08:40:24AM -0500, Jason Merrill wrote:
> On 03/10/2011 11:23 PM, Nathan Froyd wrote:
>> I'm not overly fond of the conditionals (especially in error_operand_p)
>> but I don't think it's reasonable to make IDENTIFIER_NODE bigger and
>> pen
On Fri, Mar 11, 2011 at 06:04:45AM -0800, Nathan Froyd wrote:
> On Fri, Mar 11, 2011 at 08:40:24AM -0500, Jason Merrill wrote:
> > On 03/10/2011 11:23 PM, Nathan Froyd wrote:
> > The C++ FE expects that we can check the TREE_TYPE of anything that
> > appears as an
On Fri, Mar 11, 2011 at 12:18:15AM -0800, Mike Stump wrote:
> On Mar 10, 2011, at 8:23 PM, Nathan Froyd wrote:
> > This patch series does something similar to what
>
> I am curious what the speed differences are.
A non-rigorous, C-only, release-checking bootstrap (which showed m
On Fri, Mar 11, 2011 at 10:03:43AM -0500, Jason Merrill wrote:
> On 03/11/2011 09:19 AM, Nathan Froyd wrote:
>>> I'm confused. Isn't this what the switching on IDENTIFIER_NODE in a
>>> number of places is doing? (And any future places that g++/libstdc++
>>&g
On Fri, Mar 11, 2011 at 02:12:06PM +0100, Richard Guenther wrote:
> On Fri, Mar 11, 2011 at 5:23 AM, Nathan Froyd
> wrote:
> > Now that we've done the requisite surgery on the C++ FE, we can
> > eliminate TREE_CHAIN and TREE_TYPE from IDENTIFIER_NODEs. Doing so
> >
On Sat, Mar 12, 2011 at 01:08:23PM +0100, Eric Botcazou wrote:
> > gcc/ada/
> > * gcc-interface/ada-tree.h (union lang_tree_node): Check for
> > TS_COMMON before calling TREE_CHAIN.
> > * gcc-interface/misc.c (gnat_init_ts): New function.
> > (LANG_HOOKS_INIT_TS): Define.
>
> I pre
pointers.
The patch series has been bootstrapped and tested on
x86_64-unknown-linux-gnu, though that was several months ago. If the
patches are approved, I will re-bootstrap and test prior to committing.
Nathan Froyd (2):
refactor emit_*_{after,before}_noloc using common functions
refactor emit_
This patch deals with the *_noloc family of functions. emit_pattern
seemed like a good prefix, even though AIUI these functions can receive
toplevel rtxes.
* emit-rtl.c (emit_pattern_before_noloc): New function.
(emit_insn_before_noloc, emit_jump_insn_before_noloc): Call it.
This patch builds on the previous one to refactor the close cousins of
the *_noloc family. I attempted to separate these out into separate
patches, one dealing with *_setloc and the other dealing with the
remainder, but I did not trust myself to do it correctly even with
magit's help.
* e
There are several places in libgcc where the expression
'sizeof (Wtype) * BITS_PER_UNIT' is used. We have a perfectly good
expression, W_TYPE_SIZE, for this; the patch below replaces the sizeof
expression with W_TYPE_SIZE.
Tested on x86_64-unknown-linux-gnu. I think this counts as obvious, so
I
The knowledge that building a CALL_EXPR requires three additional
arguments is scattered about tree.c; the patch below centralizes that
knowledge in a common function, build_call_1. This function can also
take care of setting up the non-argument fields of CALL_EXPRs.
Tested on x86_64-unknown-linu
On Sun, Nov 21, 2010 at 09:52:43PM -0500, Nathan Froyd wrote:
> The patch below finishes off the hookization process for FUNCTION_ARG
> and related macros. It converts the internals documentation to document
> the new hooks, poisons the macros, and shuffles the target hook suppor
On Tue, Mar 22, 2011 at 02:28:30PM -0700, Richard Henderson wrote:
> On 03/21/2011 08:18 PM, Nathan Froyd wrote:
> > +/* Insert PATTERN before BEFORE, setting its INSN_LOCATION to LOC.
> > + MAKE_RAW indicates how to turn PATTERN into a real insn. INSNP
> > + indicates if
On Tue, Mar 22, 2011 at 05:06:39PM -0700, Richard Henderson wrote:
> On 03/22/2011 04:13 PM, Nathan Froyd wrote:
> > rtx
> > emit_call_insn_before_setloc (rtx pattern, rtx before, int loc)
> > {
> > ...
> > if (pattern == NULL_RTX)
> > return la
On Wed, Mar 23, 2011 at 11:36:26AM -0700, Richard Henderson wrote:
> On 03/23/2011 05:09 AM, Nathan Froyd wrote:
> > Did you mean loc == UNKNOWN_LOCATION? Also, it looks like that's
> > conflating INSN_LOCATORs and location_ts; it seems like it'd be better
> > to ke
On Wed, Mar 23, 2011 at 01:55:34PM -0700, Richard Henderson wrote:
> I can't see how emitting a NULL_RTX should be a Good Thing, ever,
> and thus I don't see why we should be doing special things to
> handle it.
Ah, I thought the same thing and gcc_assert'ed emitting a NULL_RTX. I
didn't get ver
As $SUBJECT suggests. The patch looks much bigger than it actually is
due to re-indentation.
Tested on x86_64-unknown-linux-gnu. OK to commit?
-Nathan
* function.c (instantiate_virtual_regs): Use FOR_EACH_BB and
FOR_BB_INSNS_SAFE to iterate through insns. Re-indent.
*
The Fortran-specific bits of these patches:
[PATCH 02/18] enforce TREE_CHAIN and TREE_TYPE accesses
http://gcc.gnu.org/ml/gcc-patches/2011-03/msg00565.html
[PATCH 07/18] generalize build_case_label to the rest of the compiler
http://gcc.gnu.org/ml/gcc-patches/2011-03/msg00557.html
[PAT
The C++-specific bits of these patches:
[PATCH 02/18] enforce TREE_CHAIN and TREE_TYPE accesses
http://gcc.gnu.org/ml/gcc-patches/2011-03/msg00557.html
[PATCH 07/18] generalize build_case_label to the rest of the compiler
http://gcc.gnu.org/ml/gcc-patches/2011-03/msg00557.html
[PATCH 0
tree.c can gather optionally statistics--counts and total bytes
allocated--when tree nodes are created. Due to an oversight, however,
this accounting is not performed when nodes are copied. The patch below
corrects this oversight and moves things around so the accounting is
done in (almost) only
I've applied the obvious patch below to fix PR bootstrap/48282.
-Nathan
PR bootstrap/4828
Revert:
2011-03-24 Nathan Froyd
* function.c (instantiate_virtual_regs): Use FOR_EACH_BB and
FOR_BB_INSNS_SAFE to iterate through insns. Re-i
The patch below just moves the pattern:
x = EXPR_LOCATION (t)
if (x == UNKNOWN_LOCATION)
x = loc
into its own function.
Tested on x86_64-unknown-linux-gnu. OK to commit?
* fold-const.c (expr_location_or): New function.
(fold_truth_not_expr): Call it.
diff --git a/gcc/f
On Thu, Mar 31, 2011 at 01:39:05PM +0200, Ira Rosen wrote:
> This patch changes NEON's default vector size from 64 to 128 bits.
No comments about the patch itself, but this change should be noted in
changes.html.
-Nathan
This patch does as $SUBJECT suggests. It doesn't macroize all the call insns,
as iterators don't support substituting CONST_INTs, but it does clean up
quite a bit.
Tested on powerpc64-unknown-linux-gnu. OK to commit?
-Nathan
* config/rs6000/rs6000.md (*call_local32): Rename to...
On Fri, Apr 01, 2011 at 07:39:13PM +0200, Kai Tietz wrote:
> this patch sets for c++ methods, which are not stdarg ones, the
> default calling-convention to thiscall for ms_abi 32-bit, as vendor
> specific compiler does.
I think it might be worthwhile to pull this pattern:
> @@ -5500,7 +5524,8 @@
Nobody touches CONST_DECL's DECL_RTL, so there's no reason to for
CONST_DECL to inherit from tree_decl_with_rtl. This patch adjusts the
inheritance structure accordingly.
Bootstrapped on x86_64-unknown-linux-gnu; tests in progress. OK to
commit once those complete?
-Nathan
* tree.h (st
The patch below converts gcse.c:canon_modify_mem_list to hold VECs
instead of EXPR_LIST rtxes. I am ambivalent about the use of VECs in
canon_modify_mem_list; they will waste some memory compared to the
linked list scheme present before, though I'm not sure how much. It
would depend on the averag
This patch does just what $SUBJECT suggests: pushes down the DECL_RTL
field into LABEL_DECL. In this way, LABEL_DECL can inherit from
tree_decl_common instead of tree_decl_with_rtl.
I realize this looks like pure code shuffling; the reason for doing this
is that I want to split tree_decl_common i
On Mon, Apr 04, 2011 at 05:42:42PM +0200, Steven Bosscher wrote:
> Nice cleanup. I can't approve it but it looks alright to me. I suppose
> you're planning something similar for modify_mem_list?
That's the plan, along with numerous other users of {INSN,EXPR}_LIST.
-Nathan
On Mon, Apr 04, 2011 at 05:52:00PM +0200, Steven Bosscher wrote:
> Have you looked into maybe putting the CODE_LABEL for a LABEL_DECL in
> an on-the-side structure (hash table, whatever)? It looks like it is
> only used during expansion of SWITCH statements.
I haven't, though it'd be easy enough o
This patch does just what $SUBJECT suggests. Benefits:
- Smaller data structures in combine;
- Freeing LOG_LINKS becomes much easier (don't have to transfer
everything to the INSN_LIST free list);
Potential downsides:
- Less sharing of INSN_LIST nodes might mean more cache thrashing.
Bootstr
On Mon, Apr 04, 2011 at 09:01:20PM +0200, Steven Bosscher wrote:
> On Mon, Apr 4, 2011 at 8:49 PM, Nathan Froyd wrote:
> > This patch does just what $SUBJECT suggests. Benefits:
> >
> > - Smaller data structures in combine;
> > - Freeing LOG_LINKS becomes much eas
The type_generic and sentinel attribute handlers for c-family, LTO, and
Ada grovel through TYPE_ARG_TYPES; this patch changes them to use the
standard functions prototype_p and stdarg_p instead. Less
TYPE_ARG_TYPES usage is a good thing.
The prototype_p check in the type_generic handlers is gross
I was looking at debug_flush_symbol_queue and thought "gosh, it's
inefficient if we're calling this all the time, but it only does work
when we want DBX_DEBUGGING_INFO." So I looked around and saw that
debug_flush_symbol_queue and friends are only called from dbxout.c. So
this patch moves them th
On Mon, Apr 04, 2011 at 12:01:09PM -0600, Jeff Law wrote:
> > + canon_modify_mem_list = GCNEWVEC (VEC(modify_pair,heap) *,
> > + last_basic_block);
> nit; You're missing some whitespace here (after the VEC).
This doesn't seem to be a hard-and-fast policy; all of the
On Thu, Mar 24, 2011 at 06:15:18AM -0700, Nathan Froyd wrote:
> The C++-specific bits of these patches:
>
> [PATCH 02/18] enforce TREE_CHAIN and TREE_TYPE accesses
> http://gcc.gnu.org/ml/gcc-patches/2011-03/msg00557.html
>
> [PATCH 07/18] generalize build_case_label
On Tue, Apr 05, 2011 at 01:22:39PM +0100, Richard Earnshaw wrote:
> On Tue, 2011-04-05 at 04:44 -0700, Nathan Froyd wrote:
> > > nit; You're missing some whitespace here (after the VEC).
> >
> > This doesn't seem to be a hard-and-fast policy; all of the VEC code
When the real16/float128 bits were added to the Fortran FE, some uses of
build_function_type snuck in. This patch changes them to use
build_function_type_list.
The patch also corrects a small bug: the types for frexp and scalbn had
their argument types in the wrong order.
Tested on x86_64-unknow
As promised, this patch turns modify_mem_list into an array of VECs,
similar to the changes done to canon_modify_mem_list. Since I'm in the
area, I took the liberty of tweaking the VEC declarations related to
canon_modify_mem_list to have spaces before parens, as folks seem to
think that's the rig
On Mon, Apr 04, 2011 at 02:49:54PM -0400, Nathan Froyd wrote:
> This patch does just what $SUBJECT suggests.
v2, now with obstacks!
Tested on x86_64-unknown-linux-gnu. OK to commit?
-Nathan
* combine.c: Include obstack.h
(struct insn_link): Define.
(uid_log_li
On Tue, Apr 05, 2011 at 04:42:27PM +0200, Steven Bosscher wrote:
> On Tue, Apr 5, 2011 at 3:59 PM, Nathan Froyd wrote:
> > v2, now with obstacks!
>
> @findex LOG_LINKS
> @item LOG_LINKS (@var{i})
> A list (chain of @code{insn_list} expressions) giving information about
&
On Tue, Apr 05, 2011 at 05:55:33PM +0200, Michael Matz wrote:
> I have a preference in having just one DECL_RTL field for conceptual
> reasons:
>
> Most DECLs are actually objects (there are some prominent exceptions, but
> those always would be better described with something like NAMED_ENTITY,
Several places in the compiler could be usefully modified to use use_reg
instead of hand-building EXPR_LISTs. This patch makes such changes.
Since this patch implements equivalent functionality with an existing
function call, I believe it counts as obvious.
Tested by building cc1 for appropriate
On Tue, Apr 05, 2011 at 09:59:43AM -0400, Nathan Froyd wrote:
> On Mon, Apr 04, 2011 at 02:49:54PM -0400, Nathan Froyd wrote:
> > This patch does just what $SUBJECT suggests.
>
> v2, now with obstacks!
This broke compilation on AUTO_INC_DEC targets. Currently putting
together a
On Tue, Apr 05, 2011 at 11:22:56AM -0700, Nathan Froyd wrote:
> On Tue, Apr 05, 2011 at 09:59:43AM -0400, Nathan Froyd wrote:
> > On Mon, Apr 04, 2011 at 02:49:54PM -0400, Nathan Froyd wrote:
> > > This patch does just what $SUBJECT suggests.
> >
> > v2, now
On Tue, Apr 05, 2011 at 12:29:45PM -0700, H.J. Lu wrote:
> On Tue, Apr 5, 2011 at 11:28 AM, Nathan Froyd
> wrote:
> >> This broke compilation on AUTO_INC_DEC targets. Currently putting
> >> together a fix and testing via cross to powerpc-eabispe.
> >
> >
On Tue, Apr 05, 2011 at 07:18:16PM +, Joseph S. Myers wrote:
> On Tue, 5 Apr 2011, Nathan Froyd wrote:
> > Certainly vec.h never uses spaces; I thought this was simply The Way
> > Things Were.
>
> I also had the impression that for certain special macros such as V
On Tue, Apr 05, 2011 at 04:19:39PM +0200, Jakub Jelinek wrote:
> + for (i = 0; i < VEC_length (deferred_locations, deferred_locations_list);
> i++)
> +{
> + add_location_or_const_value_attribute (
> + VEC_index (deferred_locations, deferred_locations_list, i)->die,
> + VEC_index
101 - 200 of 204 matches
Mail list logo
