On Fri, Nov 17, 2017 at 8:50 AM, Jason Merrill wrote:
> On Thu, Nov 16, 2017 at 11:21 AM, Nathan Froyd wrote:
>> diff --git a/gcc/cp/init.c b/gcc/cp/init.c
>> index c76460d..53d6133 100644
>> --- a/gcc/cp/init.c
>> +++ b/gcc/cp/init.c
>> @@ -4038,6 +4038,15 @
Default-initialization of scalar arrays in C++ member initialization
lists produced rather slow code, laboriously setting each element of the
array to zero. It would be much faster to block-initialize the array,
and that's what this patch does.
The patch works for me, but I'm not sure if it's the
From: Nathan Froyd
Including in C++11 mode (typically done for
std::{min,max,swap}) includes , for
std::uniform_int_distribution. On x86 platforms, manages to
drag in through x86's opt_random.h header, and
has gotten rather large recently with the addition of AVX
intrinsics. The compa
- Original Message -
> /aux/hubicka/firefox/netwerk/sctp/datachannel/DataChannel.h:64:0: warning:
> field ‘mSpa’ (of type ‘struct BufferedMsg’) violates one definition rule
> [-Wodr]
Can we reword this warning? The "of type 'struct BufferedMsg'" could be easily
taken to mean that the typ
- Original Message -
> On 07/26/2013 08:42 PM, Nathan Froyd wrote:
> > Sure, I can do that. For maximum effectiveness, it'd be good to have it
> > check the specializations for atomic<>, too. Is there something in the
> > libstdc++ testsuite for iteratin
-- Original Message -
>
>
> Hi,
>
> Nathan Froyd ha scritto:
> >Compiling the test program:
> >
> >#include
> >
> >enum x { a, b };
> >
> >std::atomic v;
> >
> >bool test_strong()
> >{
> > x expected = a;
>
Compiling the test program:
#include
enum x { a, b };
std::atomic v;
bool test_strong()
{
x expected = a;
return v.compare_exchange_strong(expected, b, std::memory_order_acq_rel);
}
bool test_weak()
{
x expected = a;
return v.compare_exchange_weak(expected, b, std::memory_order_acq_re
- Original Message -
> Btw, as for Richards idea of conditionally placing the length field
> in
> rtx_def looks like overkill to me. These days we'd merely want to
> optimize for 64bit hosts, thus unconditionally adding a 32 bit
> field to rtx_def looks ok to me (you can wrap that inside a
- Original Message -
> I see all these patches with mixed feeling - it puts breaks on all
> developers
> because they need to learn the new interface which does not bring any
> immediate benefit. So I think _your_ development time would be
> better
> spent by fixing open bugs or by tacklin
- Original Message -
> Nathan, again thanks. There are a few minor tweaks compared to your
> version:
Thanks for fixing this up!
> - Keeping old layout of "mmix_reg_or_8bit_operand". That looked like
> a spurious change and I prefer the ior construct to the
> if_then_else.
ISTR wit
As $SUBJECT suggests.
I haven't tested this. It's possible my dejagnu installation is too old
and/or I have forgotten many subtleties for testing embedded targets,
but I could not make m32c-sim work and I didn't want to spend an
enormous amount of time making it work.
Nonetheless, I have compare
On Wed, Aug 08, 2012 at 10:52:28AM -0700, Mike Stump wrote:
> As we move to C++, I'd love for port maintainers to be able to get together
> and hoist _up_ code from the port so other ports can use it and thus, have
> more sharing. We make heavily stylized uses, which could be wrapped into a
> p
As $SUBJECT says. There's not too much interesting here. I did a
fairly literal-minded conversion, so it's possible there's smarter ways
to do some things.
Compiled with cross to mmix-knuth-mmixware and spot-checked by comparing
libgcc object files. I have no idea how to set up a simulator
envi
mep uses {constraints,predicates}.md and #if 0'd out the old macro versions.
In the interest of not keeping dead code around, I'd like to delete these.
I think this falls under the obvious rule, so I'll commit this in a couple of
days after waiting to hear from DJ.
Tested by building mep-elf.
-Na
On Thu, Aug 02, 2012 at 05:20:24PM +0200, Marc Glisse wrote:
> On Thu, 2 Aug 2012, Nathan Froyd wrote:
> >>PR tree-optimization/53805
> >>* fold-const.c (invert_tree_comparison): Do invert ORDERED_EXPR and
> >>UNORDERED_EXPR for floating point.
> >
On Thu, Aug 02, 2012 at 02:48:08PM +0200, Marc Glisse wrote:
> I am redoing the bootstrap+regtest, then I'll commit if I don't hear
> protests about the testcase.
>
> gcc/ChangeLog
> 2012-06-15 Marc Glisse
>
> PR tree-optimization/53805
> * fold-const.c (invert_tree_comparison): Do
Now that we can freely change the representation of the cost fields in
struct target_expmed, the patch below does so, by only requiring arrays
to hold enough storage for integer modes and/or vector integer modes,
as appropriate.
default_target_expmed shrinks from ~200KB to ~85KB on
x86_64-unknown-
Subject says it all, really. Two targets with redundant definitions, and
two targets with trivial definitions. Time to remove this.
Tested on x86_64-unknown-linux-gnu. Crosses to {alpha,vax}-linux-gnu built
as well. OK to commit?
-Nathan
* defaults.h (GO_IF_MODE_DEPENDENT_ADDRESS): D
As suggested by rth here:
http://gcc.gnu.org/ml/gcc-patches/2012-07/msg01281.html
this patch converts all the #define accessors in expmed.h to use inline
functions instead.
By itself, doing that conversion is not very exciting. Followup patches
might:
* Move setters into expmed.c;
* Reduce spa
On Fri, Jul 13, 2012 at 10:36:35AM -0700, Mike Stump wrote:
> I just checked all in tree gcc targets, and none claim OImode support.
./s390/s390-modes.def:23:INT_MODE (OI, 32);
./spu/spu-modes.def:29:INT_MODE (OI, 32);
./ia64/ia64-modes.def:68:INT_MODE (OI, 32);
./i386/i386-modes.def:88:INT_MODE (
On Tue, Jun 05, 2012 at 02:35:30PM +0200, Richard Guenther wrote:
> Index: gcc/tree-vect-data-refs.c
> ! gimple stmt = gsi_stmt (gsi);
> ! if (!find_data_references_in_stmt (NULL, stmt,
> ! &BB_VINFO_DATAREFS (bb_vinfo)))
> ! {
> !
- Original Message -
> > BTW, do you have the numbers of CSiBE with this?
>
> Only for "-m4-single -ml -O2 -mpretend-cmove" so far.
> Not so spectacular :T
> I'll also do a comparison of more variants to see if something went
> really bad. It's a bit difficult to isolate the degradations
- Original Message -
> else if (is_gimple_call (def_stmt))
> {
> + int flags = gimple_call_flags (def_stmt);
> +
> + /* Don't optimize away calls that have side-effects. */
> + if ((flags & (ECF_CONST|ECF_PURE)) == 0
> + || (flags & ECF_LOOPING_CONST_OR_PURE))
This patch does this computat
On 10/19/2011 3:27 PM, Ramana Radhakrishnan wrote:
Index: gcc/config/arm/arm.c
- live_regs_mask |= extra_mask<< (size / UNITS_PER_WORD);
+ live_regs_mask |= extra_mask<< ((size + 3) / UNITS_PER_WORD);
IIUC, wouldn't ((size + UNITS_PER_WORD - 1) / UNITS_PER_WORD) be clearer?
-Nathan
On 9/23/2011 6:03 PM, Sriraman Tallam wrote:
This patch adds a new linker plugin to re-order functions.
This is great stuff. We were experimenting with using the coverage
files to generate an ordering for --section-ordering-file, but this
might be even better, will have to experiment with it
On 9/21/2011 5:49 AM, Georg-Johann Lay wrote:
As proposed in PR45099, avr-gcc will now just print a warning instead of an
error when a fixed register is needed to pass a parameter to a function.
Where's the proposal in the PR? I see a problem report that was
addressed four months ago by addin
On 7/9/2011 8:02 AM, Tobias Burnus wrote:
Tobias Burnus wrote:
This patch adds a run-time error function to mpi.c, which gives a
proper error message including the image number. Additionally, it
allows to clean up the error handling, avoiding the duplicated
declaration of strings.
+static void
I've done a lot of g++-only testsuite runs lately and I noticed that it
didn't parallelize all that well. The patch below adds a couple more
.exp files to the parallel infrastructure. dg-torture.exp is the big
one; it takes about as much time as old-deja.exp.
Other valid candidates are lto.exp a
build_function_call uses an outdated interface (a TREE_LIST containing
the arguments passed to the function) and is only used by the ObjC/C++
FEs. The patch below deletes it and introduces a new
build_function_call_nary interface modeled after
cp_build_function_call_nary.
The C/C++ changes are mi
nemoking...@gmail.com
Thomas Fitzsimmons fitz...@redhat.com
Brian Ford f...@vss.fsi.com
John Freeman jfreema...@gmail.com
-Nathan Froyd
On 05/26/2011 10:24 PM, Lawrence Crowl wrote:
> Index: gcc/cp/cp-objcp-common.c
> ===
> --- gcc/cp/cp-objcp-common.c (revision 174301)
> +++ gcc/cp/cp-objcp-common.c (working copy)
> @@ -99,6 +99,8 @@ cp_tree_size (enum tree_code cod
On Thu, May 26, 2011 at 09:39:30AM -0400, Jason Merrill wrote:
> On 05/25/2011 10:21 PM, Nathan Froyd wrote:
> >An alternative solution would be to initialize cur_stmt_list somewhere with
> >an
> >actual 1-element VEC;
>
> Or just push NULL onto the stack and let
On Thu, Mar 10, 2011 at 11:23:26PM -0500, Nathan Froyd wrote:
> 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 s
On 05/26/2011 09:39 AM, Jason Merrill wrote:
> On 05/25/2011 10:21 PM, Nathan Froyd wrote:
>> An alternative solution would be to initialize cur_stmt_list somewhere with
>> an
>> actual 1-element VEC;
>
> Or just push NULL onto the stack and let append_to_statemen
On 05/25/2011 10:18 AM, Jason Merrill wrote:
> On 05/25/2011 10:00 AM, Nathan Froyd wrote:
>> Jason commented on the TS_STATEMENT_LIST patch, but
>> the discussion didn't come to a resolution.
>
> Right, from your last mail I thought that you were investigating my que
On Wed, May 25, 2011 at 03:22:07PM -0400, Nathan Froyd wrote:
> The patch just requires some shuffling of logic to catch issues now;
> below is a version that works for me on the trunk.
>
> This new checking does require modifying g++.dg/cpp0x/range-for5.C.
>
> Tested wit
On 05/25/2011 03:45 PM, Jason Merrill wrote:
> While looking at this, I also noticed that print_node expects everything to
> have TREE_TYPE, which is no longer correct.
Technically, I think this is not true; everything inherits from tree_common;
or at least tree_typed. (I had the bit of print_nod
x86_64-unknown-linux-gnu; tests in progress
for libstdc++. OK to commit?
-Nathan
gcc/cp/
2011-xx-xx Janis Johnson
Nathan Froyd
PR c++/2288
PR c++/18770
* name-lookup.h (enum scope_kind): Add sk_cond.
* name-lookup.c (pushdecl_maybe_friend): Get scope of shadowed loca
On 05/25/2011 02:06 PM, Tom Tromey wrote:
>>>>>> "Nathan" == Nathan Froyd writes:
>
> Nathan> (C, Java, middle-end)
> Nathan> [PATCH 18/18] make TS_BLOCK a substructure of TS_BASE
> Nathan> http://gcc.gnu.org/ml/gcc-patches/2011-03/msg00
These patches:
(C, C++, middle-end)
[PATCH 14/18] move TS_STATEMENT_LIST to be a substructure of TS_TYPED
http://gcc.gnu.org/ml/gcc-patches/2011-03/msg00560.html
(C, Java, middle-end)
[PATCH 18/18] make TS_BLOCK a substructure of TS_BASE
http://gcc.gnu.org/ml/gcc-patches/2011-03/msg00
`0On Mon, May 23, 2011 at 04:58:06PM +0200, Richard Guenther wrote:
> On Mon, May 23, 2011 at 4:18 PM, Nathan Froyd
> wrote:
> > On 05/17/2011 11:31 AM, Nathan Froyd wrote:
> >> On 05/10/2011 04:18 PM, Nathan Froyd wrote:
> >>> On 03/10/2011 11:23 PM, Nathan F
On 05/23/2011 04:23 PM, Richard Guenther wrote:
>> So I don't buy Richie's argument. Otherwise, someone would propose a
>> patch to remove the hundreds of debug_ declarations in public header
>> files (i.e. those visible to plugins), and if he did, I hope such a
>> naughty patch won't be accepted.
On 05/22/2011 02:24 PM, Tom de Vries wrote:
> Now that struct tree_type does not exist anymore, 'sizeof (struct tree_type)'
> generates an error in the following assert in fold_checksum_tree:
> ...
> gcc_assert ((sizeof (struct tree_exp) + 5 * sizeof (tree)
> <= sizeof (struct tree_f
On 05/17/2011 11:31 AM, Nathan Froyd wrote:
> 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.
On 05/23/2011 10:05 AM, Richard Guenther wrote:
> On Mon, May 23, 2011 at 3:53 PM, Nathan Froyd
> wrote:
>> +/* Return the Nth argument type from FNTYPE. */
>> +
>> +tree
>> +nth_arg_type (const_tree fntype, int n)
>> +{
>> + function_arg
Various places in the compiler grab TYPE_ARG_TYPES and grovel through it
when what they're really trying to do is index into the list of argument
types. The patch below introduces nth_arg_type for such situatiosn and
changes a hodgepodge of places to use it. You could, of course, use
function_arg
The calling interface for check_function_arguments requires the caller
to extract TYPE_ATTRIBUTES and TYPE_ARG_TYPES prior to calling it. This
is somewhat silly, as well as being incompatible with an eventual
removal of TYPE_ARG_TYPES. The patch below changes things to pass the
FUNCTION_TYPE itse
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 (
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
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
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/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/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/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,
>
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 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
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 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
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
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
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. 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_
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
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
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
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
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
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
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
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
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 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
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
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 Mon, May 02, 2011 at 05:23:48PM +0200, Georg-Johann Lay wrote:
> PR45099 is an extension that gives an error when a fixed register is
> needed to pass a parameter to a function.
>
> Because the program will show malfunction when such code is generated,
> anyway, I think an error is more appropr
On Mon, May 02, 2011 at 04:46:23PM +0200, Richard Guenther wrote:
> >> *** typedef void (lto_free_section_data_f) (
> >> *** 346,355
> >> struct lto_streamer_cache_d
> >> {
> >> /* The mapping between tree nodes and slots into the nodes array. */
> >> ! htab_t node_map;
> >
On Fri, Apr 29, 2011 at 10:59:31AM -0400, Diego Novillo wrote:
> * g++.dg/warn/Wreal-conversion-1.C: New.
> * gcc.dg/Wreal-conversion-1.c: New.
Could a single copy of the test be placed in c-c++-common, instead?
-Nathan
As $SUBJECT suggests. It is write-only; I'm not sure what it was ever
used for.
Tested on x86_64-unknonw-linux-gnu. OK to commit?
-Nathan
gcc/cp/
* cp-tree.h (TREE_NEGATED_INT): Delete.
* semantics.c (finish_unary_op_expr): Don't try to set it.
diff --git a/gcc/cp/cp-tree.h b/
As $SUBJECT suggests. Just like the nonlocal_goto_handler_labels, the
real benefit is a proper container instead of an EXPR_LIST.
in_expr_list_p is unused after this patch; I will delete it as obvious
in a followon patch if this patch is approved.
Tested on x86_64-unknown-linux-gnu. OK to commi
As $SUBJECT suggests. The memory savings from this conversion is
negligible; the real benefit, IMHO, is use of a proper container instead
of EXPR_LIST.
remove_node_from_expr_list is unused after this patch; I will delete it
as an obvious followon patch if this patch is approved.
Tested on x86_64
On Thu, Apr 28, 2011 at 03:50:45PM -0400, Diego Novillo wrote:
> Committed to google/main. Jason, Silvius, what do you think would be
> the best approach to merge this into trunk?
When this code does get merged to trunk, can the testcases abort() on
failure rather than returning 1? This is frien
On Wed, Apr 27, 2011 at 04:23:42PM -0700, Xinliang David Li wrote:
> This can happen when the module does not have function bodies.
>
> - VEC_free (cgraph_node_ptr, heap, cgraph_node_map);
> - cgraph_node_map = NULL;
> + if (cgraph_node_map)
> +VEC_free (cgraph_node_ptr, heap, cgraph_node_
On Wed, Apr 20, 2011 at 10:08:21AM -0700, Nathan Froyd wrote:
> This patch changes most of the uses of build_function_type in the Ada to
> use build_function_type_list. There are a handful of
> build_function_type calls left; replacing those will have to wait until
> we get a build_fu
On Fri, Apr 22, 2011 at 12:59:21AM -0400, Jason Merrill wrote:
> On 04/21/2011 10:55 PM, Nathan Froyd wrote:
>> On Thu, Apr 21, 2011 at 10:49:05PM -0400, Jason Merrill wrote:
>>> Hunh. How does that work? They fill in CASE_LABEL later? Can that be
>>>
On Fri, Apr 22, 2011 at 02:58:31PM -0400, Michael Meissner wrote:
> On Thu, Apr 21, 2011 at 11:04:47AM -0400, Nathan Froyd wrote:
> > - centralizes some infrastructure for defining builtin function types
> > for frontends by providing a common function that
> > DEF_FUNCTIO
On Thu, Apr 21, 2011 at 05:36:42PM +0200, Richard Guenther wrote:
> On Thu, Apr 21, 2011 at 5:04 PM, Nathan Froyd
> wrote:
> > This patch does two things:
> >
> > - centralizes some infrastructure for defining builtin function types
> > for frontends by pr
On Fri, Apr 22, 2011 at 11:12:01AM +0200, Richard Guenther wrote:
> On Fri, Apr 22, 2011 at 8:13 AM, Mike Stump wrote:
> > Unsurprising... It will never fail during testsuite run, and won't
> > always fail during a bootstrap.
> >
> >> I can't think what the comment would be talking about with poi
On Thu, Apr 21, 2011 at 10:49:05PM -0400, Jason Merrill wrote:
> On 04/21/2011 08:50 PM, Nathan Froyd wrote:
>> On Fri, Apr 08, 2011 at 01:50:24PM -0400, Jason Merrill wrote:
>>> As jsm and richi said, using input_location like this is a regression.
>>> Can we use DECL_
On Fri, Apr 08, 2011 at 01:50:24PM -0400, Jason Merrill wrote:
> On 03/24/2011 09:15 AM, Nathan Froyd wrote:
>> + tree t = make_node (CASE_LABEL_EXPR);
>> +
>> + TREE_TYPE (t) = void_type_node;
>> + SET_EXPR_LOCATION (t, input_location);
>
> As jsm and richi sai
On Thu, Apr 21, 2011 at 05:54:28PM +0200, Michael Matz wrote:
> > > In particular, FIELD_DECLs have a size, but they have no RTL associated
> > > with them. And LABEL_DECLs have RTL, but no size.
>
> Blaeh. So far about nice clean ideas :) One hacky idea: change my
> proposal to this:
>
> de
This patch does two things:
- centralizes some infrastructure for defining builtin function types
for frontends by providing a common function that
DEF_FUNCTION_TYPE_FOO macros can call; and
- in order to do that well, it also introduces
build{,_varargs}_function_type_array for cases when
On Wed, Apr 20, 2011 at 02:09:49PM -0700, Steve Ellcey wrote:
> I am not sure what the patch would look like then. You removed the
> assignment to decl, so what are you putting in ia64_builtins? Can you
> send the full correct patch.
Sure. Updated patch below, which probably looks somewhat more
As $SUBJECT suggests. The only tricky bit is the initialization of
`args' to NULL_TREEs so that we can safely pass all of the relevant args
to build_function_type_list, regardless of whether the function type in
question has that many args.
Tested with cross to sh-elf. OK to commit?
-Nathan
As $SUBJECT suggests. For safety's sake, we initialize all the
arguments to NULL before passing them to build_function_type_list. This
is not necessary currently, as we always completely fill in the args
array, but it might save some future coder from quite some grief...
Tested with cross to xst
As $SUBJECT suggests. The only tricky bit is initializing all the args
to NULL_TREE so that we can safely pass all the args to
build_function_type_list.
Tested with cross to spu-elf; I couldn't build all of libgcc, but that
appears to be a pre-existing problem. OK to commit?
-Nathan
*
On Wed, Apr 20, 2011 at 03:29:19PM -0400, Nathan Froyd wrote:
> As $SUBJECT suggests. Tested with cross to ia64-linux-gnu. OK to
> commit?
>
> - ftype = build_function_type (float128_type, void_list_node);
> - decl = add_builtin_function ("__
As $SUBJECT suggests. There's one remaining use of build_function_type,
but replace that will have to wait until we have a better
FUNCTION_TYPE-building interface.
Tested with cross to arm-eabi. OK to commit?
-Nathan
* config/arm/arm.c (arm_init_iwmmxt_builtins): Call
build_fun
As $SUBJECT suggests. Tested with cross to hppa-linux-gnu. OK to
commit?
-Nathan
* config/pa/pa.c (pa_init_builtins): Call build_function_type_list
instead of build_function_type.
diff --git a/gcc/config/pa/pa.c b/gcc/config/pa/pa.c
index e05cf19..aeb8061 100644
--- a/gcc/confi
As $SUBJECT suggests. Tested with cross to avr-elf. OK to commit?
-Nathan
* config/avr/avr.c (avr_init_builtins): Call
build_function_type_list instead of build_function_type.
diff --git a/gcc/config/avr/avr.c b/gcc/config/avr/avr.c
index 500a5b2..6dbf8b4 100644
--- a/gcc/confi
As $SUBJECT suggests. Tested with cross to picochip-elf. OK to commit?
-Nathan
* config/picochip/picochip.c (picochip_init_builtins): Call
build_function_type_list instead of build_function_type.
Delete `endlink' variable.
diff --git a/gcc/config/picochip/picochip.c b/g
1 - 100 of 204 matches
Mail list logo
