Build a function call with variable number of arguments
Hi all, Could someone give me a pointer to doc or code about building a function decl and function call expr that take a variable number of arguments (like printf)? Thanks, FX
Re: Build a function call with variable number of arguments
"François-Xavier Coudert" <[EMAIL PROTECTED]> writes: > Could someone give me a pointer to doc or code about building a > function decl and function call expr that take a variable number of > arguments (like printf)? See c-common.c:def_fn_type for the decl. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Bootstrap broken on i386-pc-mingw32
Hi Zack, hi all, A bootstrap of GCC mainline, rev. 123324, fails because of: gcc -c -g -fkeep-inline-functions -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wmissing-format-attribute -fno-common -DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild -I../../trunk/gcc -I../../trunk/gcc/build -I../../trunk/gcc/../include -I../../trunk/gcc/../libcpp/include -I/home/coudert/local/include -I../../trunk/gcc/../libdecnumber -I../../trunk/gcc/../libdecnumber/dpd -I../libdecnumber-o build/rtl.o ../../trunk/gcc/rtl.c In file included from ../../trunk/gcc/ggc.h:40, from ../../trunk/gcc/rtl.c:35: ./gtype-desc.h:64: error: expected identifier before ',' token Line 64 of gtype-desc.h is the line with "gt_ggc_e_10stmt_gr,," in the following: gt_ggc_e_18gnat_binding_level, gt_ggc_e_9elab_info, gt_ggc_e_10stmt_gr,, gt_ggc_e_20ssa_operand_memory_d, gt_ggc_e_6subvar, The ",," is clearly wrong; there's another one later in this same file: gt_ggc_e_13convert_optab, gt_ggc_e_5optab, gt_ggc_e,,, gt_ggc_e_10real_value, gt_ggc_e_10VEC_rtx_gc, I'm CCing Zack, as there was a change in that code recently (last time I did a mingw32 build was on 2007-03-22, ie before that patch, and the bootstrap was successful). I'm willing to help and provide any generated files that may help to track this one down. PS: I've launched a cross build to see if I can reproduce it there, which would of course make it easier for tracking down. FX
Re: Bootstrap broken on i386-pc-mingw32
I'm CCing Zack Away on vacation until March 31st, said the automated reply. PS: I've launched a cross build to see if I can reproduce it there, which would of course make it easier for tracking down. Works OK on the cross. So, it's probably a host problem in gengtype. It appears to exist on HPUX as well, as Steve noted. FX
Re: core changes for mep port
In http://gcc.gnu.org/ml/gcc/2007-03/msg01007.html, Steven Bosscher wrote: > All of this feels (to me anyway) like adding a lot of code to the > middle end to support MEP specific arch features. I understand it is > in the mission statement that more ports is a goal for GCC, but I > wonder if this set of changes is worth the maintenance burden... The ARC also has an optional SIMD coprocessor, for which it would be useful to be able to specify that specific oprtations should be done on the coprocessor. Moreover, our current register class preferencing and mode tying heuristics are somewhat weak, and next-to-useless in the first scheduling pass; if we'll have specific modes for computations on the coprocessor, I think it will be easier for the compiler to automatically make sure that computations that feed into or depend on other computations on the coprocessor are also done on the coprocessor. This could even help more traditional processors. I remember for SHmedia, the floating point registers can hold integer values, but when you tell the compiler the facts straight as in cost of moves between various register classes, you'll end up with lots of moves of integer values between integer and floating point registers. You actually have to fiddle the cost to pretend that movsi_media alternatives involving only floating point registers are more costly than they actually are to avoid this pessimization. I suppose a similar scenario might be true for integer operations in floating point registers on x86 with MMX and its successors. Using separate modes for integer computations in floating point registers on these processors could help gcc to model the cost of transferring values between integer and floating point units. It also can make TRULY_NOOP_CONVERSION more relevant, as the answer is often different between integer and floating point registers.
Re: Bootstrap broken on i386-pc-mingw32
On 3/29/07, François-Xavier Coudert <[EMAIL PROTECTED]> wrote:
Works OK on the cross. So, it's probably a host problem in gengtype.
It appears to exist on HPUX as well, as Steve noted.
Yeah, it appears I was overly optimistic in hoping vsnprintf() would
do what C99 says it does. I do not have access to any system that
shows the problem, but I've attached a patch that should fix it (it
just reverts the oprintf() changes, which were not really necessary, I
was just trying to be more efficient).
zw
==
--- gengtype.c (revision 123293)
+++ gengtype.c (local)
@@ -1475,24 +1475,26 @@ create_file (const char *name, const cha
return f;
}
-/* Print, like fprintf, to O. */
+/* Print, like fprintf, to O.
+ N.B. You might think this could be implemented more efficiently
+ with vsnprintf(). Unfortunately, there are C libraries that
+ provide that function but without the C99 semantics for its return
+ value, making it impossible to know how much space is required. */
void
oprintf (outf_p o, const char *format, ...)
{
+ char *s;
size_t slength;
+ va_list ap;
- /* Try first with the assumption that there is enough space. */
- {
-va_list ap;
-va_start (ap, format);
-slength = vsnprintf (o->buf + o->bufused, o->buflength - o->bufused,
- format, ap);
-va_end (ap);
- }
+ va_start (ap, format);
+ slength = vasprintf (&s, format, ap);
+ if (s == NULL || (int)slength < 0)
+fatal ("out of memory");
+ va_end (ap);
- if (o->bufused + slength >= o->buflength)
+ if (o->bufused + slength > o->buflength)
{
- /* There wasn't enough space. */
size_t new_len = o->buflength;
if (new_len == 0)
new_len = 1024;
@@ -1501,21 +1503,10 @@ oprintf (outf_p o, const char *format, .
} while (o->bufused + slength >= new_len);
o->buf = XRESIZEVEC (char, o->buf, new_len);
o->buflength = new_len;
-
- /* We now know that there is enough space. */
- {
- size_t slen2;
- va_list ap;
- va_start (ap, format);
- slen2 = vsnprintf (o->buf + o->bufused, o->buflength - o->bufused,
- format, ap);
- va_end (ap);
-
- gcc_assert (slen2 == slength);
- gcc_assert (o->bufused + slen2 < o->buflength);
- }
}
+ memcpy (o->buf + o->bufused, s, slength);
o->bufused += slength;
+ free (s);
}
/* Open the global header file and the language-specific header files. */
Re: Bootstrap broken on i386-pc-mingw32
Yeah, it appears I was overly optimistic in hoping vsnprintf() would do what C99 says it does. I do not have access to any system that shows the problem, but I've attached a patch that should fix it (it just reverts the oprintf() changes, which were not really necessary, I was just trying to be more efficient). Thanks, that fixes it for me on i386-pc-mingw32. FX
Re: Bootstrap broken on i386-pc-mingw32
[resend] On 3/29/07, François-Xavier Coudert <[EMAIL PROTECTED]> wrote: > I've attached a patch that should fix it (it > just reverts the oprintf() changes, which were not really necessary, I > was just trying to be more efficient). Thanks, that fixes it for me on i386-pc-mingw32. committed. zw
Re: GCC 4.2.0 Status Report (2007-03-22)
Mark Mitchell wrote on 03/22/07 22:10: > Diego, Roger, Jason, would you please let me know if you can work on the > issues above? I'm going to try to test Jim's patch for PR 31273 tonight. I'm looking at 29585 today.
Re: Splay Tree
I had sent in the paperwork in october 2005. [EMAIL PROTECTED] Brian N. Makin I can certainly send another if necessary. --- Richard Guenther <[EMAIL PROTECTED]> wrote: > On 11/3/06, Ian Blanes <[EMAIL PROTECTED]> wrote: > > > > The original author of this patch said he sent his > copyright assignment. I > > only did minor modification to his work so I don't > I think I should send > > it too. > > > http://gcc.gnu.org/ml/gcc-patches/2005-10/msg00833.html > > There doesn't seem to be an assignment on file for > him. > > Richard. > Sucker-punch spam with award-winning protection. Try the free Yahoo! Mail Beta. http://advision.webevents.yahoo.com/mailbeta/features_spam.html
Re: Instrumenting for a different profiling algorithm
Ian Lance Taylor wrote: It's really a lot easier to do this as a source code modification than as a compiler change. Unless you already have a lot of experience with the compiler, I think you'd be lucky or very good to get it done in two weeks. I have already done it as source code modification, once. It has its limitations which may be overcome in the compiler (e.g. using a specialized ABI to call the profiler functions). For the prologue changes look at FUNCTION_PROFILER and friends in the internal documentation. There is currently no support for profiling support in the epilogue. It could be added along the same lines as FUNCTION_PROFILER. Thanks for the pointer. I have now read this documentation, but I am not sure it suits my needs: * No support for an epilogue. Isn't there some support for finalize through other means? My epilogue should be called even when exceptions are thrown. * I need a static variable per function (not a counter but a pointer to a struct or a struct) I hope that the proposed fprintf(f,"LP%d", labelno) is sufficient. * I need something more portable than assembler code. I'd like to define the profiler in C or even in a *portable* lower level language. * The documentation repeatedly mentions 'mcount', is it just an example for the most common profiling function, or is it a must? I would like to define something different, which does a completely different stuff. If I were you I wouldn't bother with __FUNCTION__ and would just deal with PC addresses. Use a post-processing pass to convert those back into function names, using, e.g., addr2line That's not a perfect solution. * I am not sure if there is a portable way to extract PC from stack. For now I can do this for Linux/x86 but its not perfect (also, how can this be done? With -fomit-frame-pointer and with -fno-omit-frame-pointer?) * Inline functions won't be profiled (I'd like to be able to selectively profile some of the inline functions using __attribute__((profile)) or some such). * There are many great features that are more difficult to implement if the PC is used instead of a string. Thanks Michael -- Michael Veksler http:///tx.technion.ac.il/~mveksler
Re: Splay Tree
> Brian Makin writes: Brian> I had sent in the paperwork in october 2005. Brian> [EMAIL PROTECTED] Brian> Brian N. Makin Brian> I can certainly send another if necessary. Did you send in a request for an assignment or did you fill out an assignment yourself? Did you receive an acknowledgement of the assignment? David
A sibcall is also a leaf?!?
Hi Gcc gang,
Are my eyes playing tricks on me? While compiling this code:
/tmp/warn $ cat leaf.c
extern void external_func (void);
void __attribute__ ((__isr__)) foo4 (void)
{
external_func ();
return ;
}
the compiler sets current_function_is_leaf. Huh? It doesn't look very leaf-y
to me!
Thing is, I've got this "isr" attribute, which tells us things like "oops,
better save the caller-save (volatile/call_used) regs because we just entered
via an interrupt and someone was probably using them". However, I don't want
to save them unnecessarily, so I only save the call_used regs if they are
marked in regs_ever_live, /or/ if the current function is non-leaf (meaning
whatever callee it calls may clobber them).
This logic works fine - except when gcc tells me that this sibcall function
is a leaf, despite the fact that it calls out to another function that
probably clobbers the call_used regs.
The immediate solution to my situation is that I'm going to deny isr
functions in FUNCTION_OK_FOR_SIBCALL (which is the right thing to do for many
reasons), but I'm still a little bemused: is the compiler /supposed/ to
believe that a sibcall function can be a leaf?
cheers,
DaveK
--
Can't think of a witty .sigline today
Re: A sibcall is also a leaf?!?
> This logic works fine - except when gcc tells me that this sibcall > function is a leaf, despite the fact that it calls out to another function > that probably clobbers the call_used regs. A leaf function is one that doesn't make any function calls. Technically speaking, a sibcall isn't really a function call, it's "returning" to somewhere other than the caller. For most purposes it's as if foo4's caller made the function call, not foo4. As you say, the correct solution is to disallow sibcalls on isr routines. Paul
tuples: data structure separation from trees
Hi guys!
I've been having sporadic conversations with both Diego and Rth regarding
tuples, and I wanted to sum up, and get others' opinions.
After doing the GIMPLE_MODIFY_STMT work, I've come to the conlusion that
to continue overloading trees will be more work in the long run than doing the
actual separation between tuples and trees. This business of "this is
a tree, but not really", includes far too much special casing. It seems it's
best to bite the bullet now and separate the data structures in one sweep.
Here are a few points that have been brought up, in no particular order.
* Statements should be something like:
typedef struct gimple_statement_d { ... } *gimple_stmt;
...to emphasize the fact that these are statements, not expressions, decls,
or the like.
* By extension, we will also need:
typedef struct gimple_expression_d { ... } * gimple_expr;
For example, PLUS_EXPR, etc. These will have location, btw.
Something like:
gimple_stmt
|
=
/ \
/ \
/ \
gimple_expr gimple_expr
| |
tree+
|/ \
decl / \
/ \
/ \
gimple_exprgimple_expr
| |
treetree
* Unfortunately, we're going to have to duplicate a lot of the functionality
we currently have for trees. For example, since STATEMENT_LISTs are used
before gimplification, we'll have to come up with the equivalent thing
for tuples (say, GIMPLE_STATMENT_LISTS).
* Currently we convert trees in place into gimple. This will have to
change, now that we have a different data structure to convert into.
I came up with a lot of stupid designs to make the gimplifier work,
in place, with tuples, none of which I'll bore y'all with.
Instead, Diego has saved my risible approaches, by suggesting we create
the gimple structures as we go, much like we create RTL in expand. This
means we won't have an iterative approach that leaves partially
gimplified structures, like we now have.
So... we should have an emit queue, much like we have an emit queue with
RTL. Each gimplifier function must emit individual gimple_stmts there,
so instead of calling buildN(), we call helpers that can emit the
associated gimple_stmts.
Yes, this means serious gimplify.c overhaul. And for some reason I've been
volunteered to do it. ;-)
Thoughts, ideas, 5k-line patches doing all the work?
Aldy
Re: tuples: data structure separation from trees
On Thu, Mar 29, 2007 at 04:16:35PM -0400, Aldy Hernandez wrote:
> * By extension, we will also need:
>
> typedef struct gimple_expression_d { ... } * gimple_expr;
>
> For example, PLUS_EXPR, etc. These will have location, btw.
> Something like:
>
> gimple_stmt
>|
>=
> / \
> / \
>/ \
> gimple_expr gimple_expr
> | |
> tree+
>|/ \
> decl / \
> / \
> / \
> gimple_exprgimple_expr
>| |
>treetree
If we really want to save space, this will not be true. We need
to pack as much as possible down into one structure.
GIMPLE_COPY_STMT (a = b)
subcode: enum tree_code MODIFY_EXPR
op0: tree DEST
op1: tree SRC
GIMPLE_EXPR_STMT (a = b + c)
subcode: enum tree_code PLUS_EXPR
op0: tree A
op1: tree B
op2: tree C
GIMPLE_CALL_STMT (a = f(b1, ..., bn))
count: HWIn
op0: tree a or nll
op1: tree f
op2: tree b1
...
op2+n: tree bn
Code CALL_EXPR_RETURN_SLOT_OPT, CALL_FROM_THUNK_P,
and CALL_EXPR_TAILCALL into subcode as bits?
etc, etc.
I think something like
struct gimple_statment_base
{
enum gimple_stmt_code code : 8;
unsigned int subcode : 24;
source_locus locus;
tree block;
};
struct gimple_statement_fixed_length
{
struct gimple_statment_base base;
tree GTY ((length (...))) operands[1];
};
struct gimple_statment_variable_length
{
struct gimple_statment_base base;
unsigned HOST_WIDE_INT length;
tree GTY ((length ("(%h.length)"))) operands[1];
};
might be sufficient. The two variable length things I can think
of are CALL_EXPR and SWITCH_EXPR. Call will have 2 mandatory
operands (return and function address), switch will also have two
mandatory operands (index and default label). I don't know if
it's easier to hide those in the first two slots of operands or
to make them separate structures.
Of course, there's all this VL_EXP_FOO stuff in tree.h to deal with
the changed layout of calls; you might be able to re-use that in
some way.
I only suspect it'll turn out to be useful to single out GIMPLE_COPY_STMT
instead of just using GIMPLE_EXPR_STMT+MODIFY_EXPR. Even though
we don't actually save any memory, it might result in not having
to load SUBCODE for the common case of recognizing straight copies.
> * Unfortunately, we're going to have to duplicate a lot of the functionality
> we currently have for trees. For example, since STATEMENT_LISTs are used
> before gimplification, we'll have to come up with the equivalent thing
> for tuples (say, GIMPLE_STATMENT_LISTS).
Sort of. I think you'd want to merge tree_statement_list_node
into gimple_statement_d, to avoid the extra indirection to get
to the statement.
r~
Re: classes visualizer
> What application/tool can show inheritance tree of C++ classes, or > list all classes from a source code, which g++ can compile without > errors or warnings ? This question is not relevant on this mailing list. This list is used for discussions about GCC development. Next time, please try the gcc-help mailing list. Even then, this is not a question about g++, really. Have you tried typing "source code browsers" into a search engine? Cheers, Ben
Re: tuples: data structure separation from trees
Aldy Hernandez <[EMAIL PROTECTED]> writes:
> After doing the GIMPLE_MODIFY_STMT work, I've come to the conlusion that
> to continue overloading trees will be more work in the long run than doing the
> actual separation between tuples and trees. This business of "this is
> a tree, but not really", includes far too much special casing. It seems it's
> best to bite the bullet now and separate the data structures in one sweep.
Yes.
> * By extension, we will also need:
>
> typedef struct gimple_expression_d { ... } * gimple_expr;
>
> For example, PLUS_EXPR, etc. These will have location, btw.
Why will expressions have location? It seems to me preferable to save
the memory. After a few optimization passes many of the expressions
have no location anyhow.
> Something like:
>
> gimple_stmt
>|
>=
> / \
> / \
>/ \
> gimple_expr gimple_expr
> | |
> tree+
>|/ \
> decl / \
> / \
> / \
> gimple_exprgimple_expr
>| |
>treetree
As RTH said, we need to pack operands together as much as possible and
avoid pointers as much as possible.
And as long as you are thinking about this, I think it would be very
desirable to not use pointers at all. That could reduce LTO output
serialization to some memory rearrangement plus an mmap call. LTO
serialization input would be pure mmap. For example, perhaps instead
of pointers, always store an offset into an array, and then garbage
collect array entries.
There are a number of other compilers with successful IR
implementations, and some of them are open source, such as LLVM or
Open64. Since you are essentially proposing a new IR, I would
encourage you to take a little time to see if you can learn anything
from their IR implementations.
Sure, we can't get there immediately. And your suggestion may be a
good incremental step. But I'd like to see a little more about the
final destination.
Thanks for looking at this!
Ian
Re: tuples: data structure separation from trees
On 29 Mar 2007 18:24:56 -0700, Ian Lance Taylor <[EMAIL PROTECTED]> wrote: Why will expressions have location? It seems to me preferable to save the memory. After a few optimization passes many of the expressions have no location anyhow. And I know from past experiences, that this is really a bug that they don't produce expressions with locations. I remember Daniel Berlin was talking about how SRA does the correct thing with respect of locations and other passes should really follow that. We can see how out of SSA can produce cases where PHIs would create expressions without locations but that is a bug (I cannot find the PR right now but Daniel J. filed it). Thanks, Andrew Pinski
Re: tuples: data structure separation from trees
On Thu, Mar 29, 2007 at 06:40:30PM -0700, Andrew Pinski wrote: > On 29 Mar 2007 18:24:56 -0700, Ian Lance Taylor <[EMAIL PROTECTED]> wrote: > >Why will expressions have location? It seems to me preferable to save > >the memory. After a few optimization passes many of the expressions > >have no location anyhow. > And I know from past experiences, that this is really a bug that they > don't produce expressions with locations. I remember Daniel Berlin > was talking about how SRA does the correct thing with respect of > locations and other passes should really follow that. We can see how > out of SSA can produce cases where PHIs would create expressions > without locations but that is a bug (I cannot find the PR right now > but Daniel J. filed it). http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26475 But I'm not convinced that adding locations on more things is a workable solution to the problem. I wish someone had sufficient incentive to sit down and design a proper solution to our degenerating debug info. -- Daniel Jacobowitz CodeSourcery
Re: tuples: data structure separation from trees
"Andrew Pinski" <[EMAIL PROTECTED]> writes: > On 29 Mar 2007 18:24:56 -0700, Ian Lance Taylor <[EMAIL PROTECTED]> wrote: > > Why will expressions have location? It seems to me preferable to save > > the memory. After a few optimization passes many of the expressions > > have no location anyhow. > > And I know from past experiences, that this is really a bug that they > don't produce expressions with locations. I remember Daniel Berlin > was talking about how SRA does the correct thing with respect of > locations and other passes should really follow that. We can see how > out of SSA can produce cases where PHIs would create expressions > without locations but that is a bug (I cannot find the PR right now > but Daniel J. filed it). Provided we keep locations on statements, specifically including GIMPLE_MODIFY_EXPR, does it really help us to keep locations on expressions within statements in optimized code? What could the debugger do with that information, in principle, that would be helpful? Ian
