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
"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 Lab
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-for
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
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
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
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 m
[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.
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.
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 ass
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,
> 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 ackno
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 lo
> 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 reall
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
actu
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
> 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
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",
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
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 lo
"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.
21 matches
Mail list logo
