"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.
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
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
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",
> 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
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
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
> 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 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
> 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
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,
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
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.
[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.
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
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
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
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
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
"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 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
21 matches
Mail list logo
