On Fri, Nov 17, 2017 at 8:50 AM, Jason Merrill <ja...@redhat.com> wrote:
> On Thu, Nov 16, 2017 at 11:21 AM, Nathan Froyd <froy...@mozilla.com> wrote:
>> diff --git a/gcc/cp/init.c b/gcc/cp/init.c
>> index c76460d..53d6133 100644
>> --- a/gcc/cp/init.c
>> +++
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
From: Nathan Froyd <froy...@gmail.com>
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
- 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 type of
Compiling the test program:
#include atomic
enum x { a, b };
std::atomicx 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,
Message -
Hi,
Nathan Froyd nfr...@mozilla.com ha scritto:
Compiling the test program:
#include atomic
enum x { a, b };
std::atomicx v;
bool test_strong()
{
x expected = a;
return v.compare_exchange_strong(expected, b,
std::memory_order_acq_rel);
}
bool test_weak
- 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 iterating template instantiations over a list
- 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 tackling
- 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 without
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
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
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 marc.gli...@inria.fr
PR tree-optimization/53805
* fold-const.c
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.
Minor protest about the ChangeLog: I think you
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.
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
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
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
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):
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 because
- 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 computation
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
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
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
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
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 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_statement_list_1 allocate
the VEC?
Did you
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 so saves
the never-used
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 append_to_statement_list_1
allocate
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 code)
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
On 05/25/2011 02:06 PM, Tom Tromey wrote:
Nathan == Nathan Froyd froy...@codesourcery.com 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/msg00564.html
The Java parts are ok.
I
believe [basic.scope.local]p4 says much the same thing.
Tested with g++ testsuite on x86_64-unknown-linux-gnu; tests in progress
for libstdc++. OK to commit?
-Nathan
gcc/cp/
2011-xx-xx Janis Johnson jani...@codesourcery.com
Nathan Froyd froy...@codesourcery.com
PR c++/2288
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_node
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 question
about add_stmt and your
`0On Mon, May 23, 2011 at 04:58:06PM +0200, Richard Guenther wrote:
On Mon, May 23, 2011 at 4:18 PM, Nathan Froyd froy...@codesourcery.com
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 Froyd wrote:
After all
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
On 05/23/2011 10:05 AM, Richard Guenther wrote:
On Mon, May 23, 2011 at 3:53 PM, Nathan Froyd froy...@codesourcery.com
wrote:
+/* Return the Nth argument type from FNTYPE. */
+
+tree
+nth_arg_type (const_tree fntype, int n)
+{
+ function_args_iterator iter;
+ tree t;
+ int i
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
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.
Such
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
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.
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
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 makes
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
nicola.p...@meta-innovation.com 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
On 05/13/2011 11:26 AM, Richard Guenther wrote:
On Fri, May 13, 2011 at 5:01 PM, Nathan Froyd froy...@codesourcery.com
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 restore lost FMA
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
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
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
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
On Fri, Mar 11, 2011 at 02:19:14PM +0100, Richard Guenther wrote:
On Fri, Mar 11, 2011 at 5:23 AM, Nathan Froyd froy...@codesourcery.com
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 this ... like always
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 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
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
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 review! We'll see
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
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
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
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
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 thing that comes to mind
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
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
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
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
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
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_function_type_{n
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
changed?
Yeah, tree-eh.c:lower_try_finally_switch
On Fri, Apr 22, 2011 at 11:12:01AM +0200, Richard Guenther wrote:
On Fri, Apr 22, 2011 at 8:13 AM, Mike Stump mikest...@comcast.net 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
On Thu, Apr 21, 2011 at 05:36:42PM +0200, Richard Guenther wrote:
On Thu, Apr 21, 2011 at 5:04 PM, Nathan Froyd froy...@codesourcery.com
wrote:
This patch does two things:
- centralizes some infrastructure for defining builtin function types
for frontends by providing a common function
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_FUNCTION_TYPE_FOO macros can call
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 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:
decl_common
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 said, using input_location like
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_SOURCE_LOCATION (label_decl) instead
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_function_type_{n,vec} interface.
Tested on x86_64-unknown-linux-gnu. OK to commit?
Just as $SUBJECT suggests. All the other uses of
build_function_type_list are tied up with get_arg_type_list and will
therefore have to wait for a better FUNCTION_TYPE builder.
Tested on x86_64-unknown-linux-gnu. IIUC the changes to
objc-next-runtime-abi-02.c would not be tested on that
As $SUBJECT suggests. Tested with cross to alpha-elf. OK to commit?
-Nathan
* config/alpha/alpha.c (alpha_init_builtins): Call
build_function_type_list instead of build_function_type.
diff --git a/gcc/config/alpha/alpha.c b/gcc/config/alpha/alpha.c
index 5e85e2b..237e9b3
As $SUBJECT suggests. Tested with cross to bfin-elf. OK to commit?
-Nathan
* config/bfin/bfin.c (bfin_init_builtins): Call
build_function_type_list instead of build_function_type.
diff --git a/gcc/config/bfin/bfin.c b/gcc/config/bfin/bfin.c
index 5d08437..03a833d 100644
---
As $SUBJECT suggests. Tested with cross to frv-elf. OK to commit?
-Nathan
* config/frv/frv.c (frv_init_builtins): Delete `endlink' variable.
Call builtin_function_type_list instead of builtin_function_type.
(UNARY, BINARY, TRINARY, QUAD): Likewise.
diff --git
As $SUBJECT suggests. There's still one use of build_function_type;
replacing that type will have to wait for an improved
FUNCTION_TYPE-building interface.
Tested on x86_64-unknown-linux-gnu. OK to commit?
-Nathan
* config/i386/i386.c (ix86_code_end): Call build_function_type_list
As $SUBJECT suggests. Tested with cross to ia64-linux-gnu. OK to
commit?
-Nathan
* config/ia64/ia64.c (ia64_init_builtins): Call
build_function_type_list instead of builtin_function_type.
diff --git a/gcc/config/ia64/ia64.c b/gcc/config/ia64/ia64.c
index 5f22b17..166ec43
As $SUBJECT suggests. Tested with cross to iq2000-elf. OK to commit?
-Nathan
* config/iq2000/i2000.c (iq2000_init_builtins): Call
build_function_type_list instead of build_function_type.
Delete `endlink' variable.
diff --git a/gcc/config/iq2000/iq2000.c
As $SUBJECT suggests. Tested with cross to mips-elf. OK to commit?
-Nathan
* config/mips/mips.c (mips16_build_function_stub): Call
build_function_type_list instead of build_function_type.
(mips16_build_call_stub): Likewise.
diff --git a/gcc/config/mips/mips.c
As $SUBJECT suggests. Tested with cross to s390-linux-gnu. OK to
commit?
-Nathan
* config/s390/s390.c (s390_init_builtins): Call
build_function_type_list instead of build_function_type.
diff --git a/gcc/config/s390/s390.c b/gcc/config/s390/s390.c
index caee077..adacfa3 100644
As $SUBJECT suggests. Tested with cross to xtensa-elf. OK to commit?
-Nathan
* config/xtensa/xtensa.c (xtensa_init_builtins): Call
build_function_type_list instead of build_function_type.
diff --git a/gcc/config/xtensa/xtensa.c b/gcc/config/xtensa/xtensa.c
index
As $SUBJECT suggests. The only tricky part is in builtin_function_type,
where we fill in unused args with NULL_TREE so that passing extra
arguments to build_function_type_list doesn't matter.
Tested with cross to powerpc-eabi. OK to commit?
-Nathan
* config/rs6000/rs6000.c
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
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
---
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
---
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
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 (__builtin_infq, ftype
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
*
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
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
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
1 - 100 of 152 matches
Mail list logo
