Re: [google]: initialize language field for clone function struct
On Wed, May 4, 2011 at 7:14 PM, Eric Botcazou ebotca...@adacore.com wrote: Actually it turns out that it doesn't matter. If we arrive here with something that needs a SAVE_EXPR we have to be able to generate code for it somewhere, where there would be obviously the possibility to also generate code for a SAVE_EXPR. The transformations done in fold are optimizations that duplicate things, hence the need to protect them from multiple evaluations. If you cannot easily do so (e.g. at global level), you just don't do the optimizations. But, yes, there is something true. If you have variable sizes at the global level, they need to be evaluated once for all (unless self-referential, but this is another subject) so you need to do it somewhere. But you cannot do it with SAVE_EXPRs since they would end up being shared across functions. Sure, but that's a limitation of out SAVE_EXPR handling (given that it would be ok to expand the SAVE_EXPR multiple times - once per instantiation context). Richard. -- Eric Botcazou
Re: [google]: initialize language field for clone function struct
Sure, but that's a limitation of out SAVE_EXPR handling (given that it would be ok to expand the SAVE_EXPR multiple times - once per instantiation context). You need to expand the initializer exactly once and you need to make sure that this occurrence is invoked before all the others at run time. Not trivial. -- Eric Botcazou
Re: [google]: initialize language field for clone function struct
But where do you expand it without the SAVE_EXPR? The same restrictions apply there. So I suppose you expand it to a function in which case there is the context where the SAVE_EXPR can be expanded exactly once. You don't have SAVE_EXPRs so you're precisely controlling what you're doing. Once a SAVE_EXPR is generated, things are pretty much out of control for the front-end. But maybe I'm confused and simply lack an actual testcase that shows the issue ;) Remove the call to global_bindings_p from variable_size and run gnat.dg. -- Eric Botcazou
Re: [google]: initialize language field for clone function struct
Hm, ok. I was more looking at removing the calls from fold-const.c where it seems to protect things like folding x = +Inf to x == x, stuff unlikely to appear in type sizes. I can imagine the Ada FE wanting to do things with type sizes and variable_size's wrapping looks like merely an optimization to me (for re-using values in nested array types for example(?)). I indeed can try to remove some/the calls present in fold-const.c as part as my upcoming patch to tidy up the hook, but the one present in variable_size needs to stay for the time being. -- Eric Botcazou
Re: [google]: initialize language field for clone function struct
Well - the errors in variable_size aren't used by C any more (since 4.5), but I don't know whether any other languages use them. Apparently not, let's remove them. And pending sizes are used to a limited extent for C (to handle side effects in sizes of array parameters, as described in the comment /* ??? Insert the contents of the pending sizes list into the function to be evaluated. The only reason left to have this is void foo(int n, int array[n++]) because we throw away the array type in favor of a pointer type, and thus won't naturally see the SAVE_EXPR containing the increment. All other pending sizes would be handled by gimplify_parameters. */ ) although it would now be better to make use of the expr parameter to grokdeclarator to replace this residual use of the pending sizes global list. c-parser.c/c-decl.c are the only remaining users of pending sizes so it would indeed be desirable to change them so as to totally get rid of pending sizes. Actually, it will probably be possible the eliminate the function completely for C; there's no good reason to do more than calling save_expr directly. if (TREE_CONSTANT (size)) return size; Redundant, save_expr checks for constants. size = save_expr (size); The only necessary bit of c_variable_size once pending sizes are replaced by a better scheme. save = skip_simple_arithmetic (size); Premature optimization. if (cfun cfun-dont_save_pending_sizes_p) return size; if (!global_bindings_p ()) put_pending_size (save); No longer needed once pending sizes are replaced. return size; So this just becomes equivalent to save_expr. There is the CONTAINS_PLACEHOLDER_P check in the generic case but, yes, otherwise it's just a proxy for save_expr. -- Eric Botcazou
Re: [google]: initialize language field for clone function struct
On Tue, May 3, 2011 at 6:15 PM, Xinliang David Li davi...@google.com wrote: On Tue, May 3, 2011 at 3:55 AM, Jan Hubicka hubi...@ucw.cz wrote: Is this one ok? Hi, we did quite some work on removing a langhooks for LTO, where they become quite impossible So I would like to know what testcase causes the problem and why. In fold-const.c, there are many of calls to lang_hooks.decls.global_bindings_p, and the implementation of this in name-lookup.h will look at the the cfun-language Umm, I think most of them (if not all) are just bogus. If a FE doesn't want to fold some stuff when at global scope it should not call fold. But I'm not sure that is actually what it tries to do ... and the existing checks are far from consistently spread out in fold-const.c ... Richard.
Re: [google]: initialize language field for clone function struct
Umm, I think most of them (if not all) are just bogus. If a FE doesn't want to fold some stuff when at global scope it should not call fold. That isn't so easy because fold is invoked on sizes of types by stor-layout.c and these sizes can be variable (at least in Ada). So I think that the calls to the hook are still needed. But: 1) The -1 thing should go and the hook return boolean. The prerequisite is to tidy up variable_size, 2) I think that the GIMPLE hook can return 0 unconditionally. But I'm not sure that is actually what it tries to do ... and the existing checks are far from consistently spread out in fold-const.c ... It prevents save_expr from being called at global level, since you cannot create SAVE_EXPRs outside functions. Likewise in variable_size. -- Eric Botcazou
Re: [google]: initialize language field for clone function struct
On Wed, 4 May 2011, Eric Botcazou wrote: That isn't so easy because fold is invoked on sizes of types by stor-layout.c That's what we should phase out. The eventual aim should be for (a) folding on GIMPLE (gimple-fold etc. - working with SSA not combined trees) as an optimization and (b) folding done by front ends only when required for language semantics (e.g. constant expressions). If you want to optimize type sizes, look at where they are located in the GIMPLE IR, as a property of the IR rather than as a hook checking global state. -- Joseph S. Myers jos...@codesourcery.com
Re: [google]: initialize language field for clone function struct
That's what we should phase out. The eventual aim should be for (a) folding on GIMPLE (gimple-fold etc. - working with SSA not combined trees) as an optimization and (b) folding done by front ends only when required for language semantics (e.g. constant expressions). If you want to optimize type sizes, look at where they are located in the GIMPLE IR, as a property of the IR rather than as a hook checking global state. In Ada we simply don't want to emit raw type sizes in the GIMPLE IR, they are just too heavy to be manipulated up to there, even for moderately complex code. That's why we need them to be folded as soon as possible, and even factored out of the GENERIC IR into functions when they are self-referential. -- Eric Botcazou
Re: [google]: initialize language field for clone function struct
On Wed, May 4, 2011 at 12:00 PM, Eric Botcazou ebotca...@adacore.com wrote: Umm, I think most of them (if not all) are just bogus. If a FE doesn't want to fold some stuff when at global scope it should not call fold. That isn't so easy because fold is invoked on sizes of types by stor-layout.c and these sizes can be variable (at least in Ada). So I think that the calls to the hook are still needed. But: 1) The -1 thing should go and the hook return boolean. The prerequisite is to tidy up variable_size, 2) I think that the GIMPLE hook can return 0 unconditionally. But I'm not sure that is actually what it tries to do ... and the existing checks are far from consistently spread out in fold-const.c ... It prevents save_expr from being called at global level, since you cannot create SAVE_EXPRs outside functions. Likewise in variable_size. I see several places in fold-const.c that are not properly guarded then. But anyway, if it is supposed to protect SAVE_EXPRs then I'd have expected save_expr to contain that check and possibly return NULL if it can't save. And I'm not sure you can't do SAVE_EXPRs outside of functions - you could simply emit global temporaries. Richard. -- Eric Botcazou
Re: [google]: initialize language field for clone function struct
That's what we should phase out. The eventual aim should be for (a) folding on GIMPLE (gimple-fold etc. - working with SSA not combined trees) as an optimization and (b) folding done by front ends only when required for language semantics (e.g. constant expressions). Why? Isn't it always better to optimize as early as you can when it's easy? Why keep unfolded constants around at all?
Re: [google]: initialize language field for clone function struct
Hi, On Wed, 4 May 2011, Richard Guenther wrote: It prevents save_expr from being called at global level, since you cannot create SAVE_EXPRs outside functions. Likewise in variable_size. I see several places in fold-const.c that are not properly guarded then. But anyway, if it is supposed to protect SAVE_EXPRs then I'd have expected save_expr to contain that check and possibly return NULL if it can't save. And I'm not sure you can't do SAVE_EXPRs outside of functions - you could simply emit global temporaries. It's not the temporary, but the evaluation that poses problems in global context. (you could add a global ctor to it, ugh) Ciao, Michael.
Re: [google]: initialize language field for clone function struct
On Wed, May 4, 2011 at 1:56 PM, Michael Matz m...@suse.de wrote: Hi, On Wed, 4 May 2011, Richard Guenther wrote: It prevents save_expr from being called at global level, since you cannot create SAVE_EXPRs outside functions. Likewise in variable_size. I see several places in fold-const.c that are not properly guarded then. But anyway, if it is supposed to protect SAVE_EXPRs then I'd have expected save_expr to contain that check and possibly return NULL if it can't save. And I'm not sure you can't do SAVE_EXPRs outside of functions - you could simply emit global temporaries. It's not the temporary, but the evaluation that poses problems in global context. (you could add a global ctor to it, ugh) Well, a save-expr would only be created if evaluation is necessary anyway, so I don't see the issue really. Richard.
Re: [google]: initialize language field for clone function struct
On Wed, May 4, 2011 at 07:44, Richard Kenner ken...@vlsi1.ultra.nyu.edu wrote: That's what we should phase out. The eventual aim should be for (a) folding on GIMPLE (gimple-fold etc. - working with SSA not combined trees) as an optimization and (b) folding done by front ends only when required for language semantics (e.g. constant expressions). Why? Isn't it always better to optimize as early as you can when it's easy? Why keep unfolded constants around at all? 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 literature. Diego.
Re: [google]: initialize language field for clone function struct
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 literature. Sure, in the sorts of examples you mention where there's a level of globality to it. But I don't see it in the types of things that fold does. How could it ever be better to leave a - a in the tree instead of 0?
Re: [google]: initialize language field for clone function struct
On Wed, May 4, 2011 at 08:30, Richard Kenner ken...@vlsi1.ultra.nyu.edu 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 literature. Sure, in the sorts of examples you mention where there's a level of globality to it. But I don't see it in the types of things that fold does. How could it ever be better to leave a - a in the tree instead of 0? Yes, that's true. Diego.
Re: [google]: initialize language field for clone function struct
Hi, On Wed, 4 May 2011, 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 literature. Sure, in the sorts of examples you mention where there's a level of globality to it. But I don't see it in the types of things that fold does. How could it ever be better to leave a - a in the tree instead of 0? The former is not a constant expression in the C sense, hence folding it early disables required diagnostics; that's what Joseph means when he says that the frontends should fold only exactly those things that the language standard requires, implying not a general catch-all folder. After the frontend is ready with a construct we can do all kinds of foldings as early as we like. Ciao, Michael.
Re: [google]: initialize language field for clone function struct
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 literature. Sure, in the sorts of examples you mention where there's a level of globality to it. But I don't see it in the types of things that fold does. How could it ever be better to leave a - a in the tree instead of 0? If you ever want to do things beside compile the code--automated refactoring, renaming, pretty-printing, etc.--fidelity to the source is preferred. -Nathan
Re: [google]: initialize language field for clone function struct
On Wed, May 4, 2011 at 09:19, Nathan Froyd froy...@codesourcery.com wrote: 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 literature. Sure, in the sorts of examples you mention where there's a level of globality to it. But I don't see it in the types of things that fold does. How could it ever be better to leave a - a in the tree instead of 0? If you ever want to do things beside compile the code--automated refactoring, renaming, pretty-printing, etc.--fidelity to the source is preferred. I think we may be talking at different levels. It's my impression that Richard K. was referring to local transformations like a - a - 0 once we are in the middle end. I agree that doing that transformation close to the FE is undesirable, but once we are in the middle end that should be fine. Diego.
Re: [google]: initialize language field for clone function struct
I think we may be talking at different levels. It's my impression that Richard K. was referring to local transformations like a - a - 0 once we are in the middle end. I agree that doing that transformation close to the FE is undesirable, but once we are in the middle end that should be fine. That's exactly what I mean. If the FE cares about no folding taking place, it shouldn't fold. But once we're past the point that it's doing syntax and semantic checking, there's no optimization benefit in deferring the folding until we get to SSA, for example.
Re: [google]: initialize language field for clone function struct
And I'm not sure you can't do SAVE_EXPRs outside of functions - you could simply emit global temporaries. How do you initialize global temporaries with non-trivial initializers? -- Eric Botcazou
Re: [google]: initialize language field for clone function struct
On Wed, May 4, 2011 at 5:10 PM, Eric Botcazou ebotca...@adacore.com wrote: And I'm not sure you can't do SAVE_EXPRs outside of functions - you could simply emit global temporaries. How do you initialize global temporaries with non-trivial initializers? Actually it turns out that it doesn't matter. If we arrive here with something that needs a SAVE_EXPR we have to be able to generate code for it somewhere, where there would be obviously the possibility to also generate code for a SAVE_EXPR. No? Richard. -- Eric Botcazou
Re: [google]: initialize language field for clone function struct
Actually it turns out that it doesn't matter. If we arrive here with something that needs a SAVE_EXPR we have to be able to generate code for it somewhere, where there would be obviously the possibility to also generate code for a SAVE_EXPR. The transformations done in fold are optimizations that duplicate things, hence the need to protect them from multiple evaluations. If you cannot easily do so (e.g. at global level), you just don't do the optimizations. But, yes, there is something true. If you have variable sizes at the global level, they need to be evaluated once for all (unless self-referential, but this is another subject) so you need to do it somewhere. But you cannot do it with SAVE_EXPRs since they would end up being shared across functions. -- Eric Botcazou
Re: [google]: initialize language field for clone function struct
Joseph I don't know if Fortran, Java or Go use variable-size types at Joseph all. Java doesn't have variable-size types. AFAIK, gcj does not generate them internally for anything, either. Tom
Re: [google]: initialize language field for clone function struct
On Tue, May 3, 2011 at 3:55 AM, Jan Hubicka hubi...@ucw.cz wrote:
Is this one ok?
Hi,
we did quite some work on removing a langhooks for LTO, where they become
quite impossible
So I would like to know what testcase causes the problem and why.
In fold-const.c, there are many of calls to
lang_hooks.decls.global_bindings_p, and the implementation of this in
name-lookup.h will look at the the cfun-language
#define cp_function_chain (cfun-language)
#define current_binding_level \
(*(cfun cp_function_chain cp_function_chain-bindings \
? cp_function_chain-bindings \
int
global_bindings_p (void)
{
return global_scope_p (current_binding_level);
}
In gcc 4.4.3, current_binding_level is defined in a way that
cp_function_chain-bindings is not guarded, resulting in segfault for
clones. In trunk, this is guarded -- but not setting language field
for clone probably just hide the problem.
Thanks,
David
Honza
David
On Fri, Apr 29, 2011 at 4:38 PM, Xinliang David Li davi...@google.com
wrote:
During function cloning, the language field of the src func is not
copied. This can lead to null dereference when gcc calls into langhook
functions. Unfortunately, I lost track of the test case.
Ok for trunk ?
Thanks,
David
2011-04-29 Xinliang David Li davi...@google.com
* tree-inline.c (ininitialize_cfun): Initialize
language field for clone cfun.
Re: [google]: initialize language field for clone function struct
In fold-const.c, there are many of calls to
lang_hooks.decls.global_bindings_p, and the implementation of this in
name-lookup.h will look at the the cfun-language
#define cp_function_chain (cfun-language)
#define current_binding_level \
(*(cfun cp_function_chain cp_function_chain-bindings \
? cp_function_chain-bindings \
int
global_bindings_p (void)
{
return global_scope_p (current_binding_level);
}
In gcc 4.4.3, current_binding_level is defined in a way that
cp_function_chain-bindings is not guarded, resulting in segfault for
clones. In trunk, this is guarded -- but not setting language field
for clone probably just hide the problem.
Indeed, it seems to me that global_bindings_p should go, clearly the LTO does
not preserve its behaviour in any sane way.
I am however completely missing the point of this langhook and doc is not
exactly
informative either:
/* Returns nonzero if we are in the global binding level. Ada
returns -1 for an undocumented reason used in stor-layout.c. */
What is the purpose of this hook?
Honza
Re: [google]: initialize language field for clone function struct
I am however completely missing the point of this langhook and doc is not
exactly informative either:
/* Returns nonzero if we are in the global binding level. Ada
returns -1 for an undocumented reason used in stor-layout.c. */
What is the purpose of this hook?
I've seen things far more undocumented in GCC than this one ;-)
tree
variable_size (tree size)
{
[...]
/* If the language-processor is to take responsibility for variable-sized
items (e.g., languages which have elaboration procedures like Ada),
just return SIZE unchanged. */
if (lang_hooks.decls.global_bindings_p () 0)
return size;
[...]
if (lang_hooks.decls.global_bindings_p ())
{
if (TREE_CONSTANT (size))
error (type size can%'t be explicitly evaluated);
else
error (variable-size type declared outside of any function);
return size_one_node;
}
[...]
}
In Ada there are variable-sized types at global level so it isn't an error to
call variable_size when lang_hooks.decls.global_bindings_p returns non-zero.
--
Eric Botcazou
Re: [google]: initialize language field for clone function struct
On Tue, 3 May 2011, Eric Botcazou wrote:
I am however completely missing the point of this langhook and doc is not
exactly informative either:
/* Returns nonzero if we are in the global binding level. Ada
returns -1 for an undocumented reason used in stor-layout.c. */
What is the purpose of this hook?
I've seen things far more undocumented in GCC than this one ;-)
tree
variable_size (tree size)
{
[...]
/* If the language-processor is to take responsibility for variable-sized
items (e.g., languages which have elaboration procedures like Ada),
just return SIZE unchanged. */
if (lang_hooks.decls.global_bindings_p () 0)
return size;
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 uses its own version as the language-independent one isn't
right for C. Similarly, the pending_size code should be local to front
ends.
--
Joseph S. Myers
jos...@codesourcery.com
Re: [google]: initialize language field for clone function struct
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 uses its own version as the language-independent one isn't right for C. Similarly, the pending_size code should be local to front ends. 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; perhaps there are others. -Nathan
Re: [google]: initialize language field for clone function struct
On Tue, 3 May 2011, Nathan Froyd wrote: 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 uses its own version as the language-independent one isn't right for C. Similarly, the pending_size code should be local to front ends. 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; perhaps there are others. I don't see how you can do that; you'll still have variable-sized types and objects, it would just be entirely the front end's responsibility to ensure that the size expression is evaluated exactly once (whenever required by the language). At most, the size would either be a constant or an internal DECL created by the front end if you move that to the front end instead of using SAVE_EXPR. However, I think the fields storing type and decl sizes (and alignment) in *bits* are suspect. Values in bits are needed when dealing with bit-field layout, but I think types should otherwise be defined to be made up of whole bytes (bytes of BITS_PER_UNIT bits, at this level) with code dealing with bit-fields looking at TYPE_PRECISION as needed. -- Joseph S. Myers jos...@codesourcery.com
Re: [google]: initialize language field for clone function struct
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). I don't really see the point here. GCC supports variable-sized types in the middle-end (stor-layout.c, gimplifier) so why special-casing this function? C for example uses its own version as the language-independent one isn't right for C. The C version looks an almost exact duplicate of the generic one though. We should probably try to reconciliate the different versions. Similarly, the pending_size code should be local to front ends. Yes, I agree here. gigi already does the full management and doesn't use it. -- Eric Botcazou
Re: [google]: initialize language field for clone function struct
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; perhaps there are others. I don't see how you can do that; you'll still have variable-sized types and objects, it would just be entirely the front end's responsibility to ensure that the size expression is evaluated exactly once (whenever required by the language). Ah, you're right. I got carried away about thinking about FE-specific data structures for things. -Nathan
Re: [google]: initialize language field for clone function struct
On Tue, 3 May 2011, Eric Botcazou 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). I don't really see the point here. GCC supports variable-sized types in the middle-end (stor-layout.c, gimplifier) so why special-casing this function? In general errors from outside the front end, but relating to problems with the user's source code, are suspicious; the front end should detect invalid code, diagnose it and not pass it to the language-independent compiler. And the exact language semantics regarding where variable-size types are permitted and when the sizes should be evaluated are inherently front-end-specific and not easily represented in a generic function. convert.c is another place with errors that I think ought to go in the front ends; having some generic conversion logic is fine, but the front ends should deal with diagnosing invalid cases and convert.c should ICE if asked to do a conversion it doesn't know how to do. C for example uses its own version as the language-independent one isn't right for C. The C version looks an almost exact duplicate of the generic one though. We should probably try to reconciliate the different versions. C doesn't want the language-independent errors (see above); they don't reflect the right logic for C. It needs to override parts of the generic function when called from generic code, and so to replace it when called from the front end. C returns -1 from global_bindings_p, as does Ada. That the languages that probably care most about variable-size types find aspects of the generic function need overriding like that should be a good indication that it isn't really that generic - as I said above, semantics for variable sizes are very front-end-specific. -- Joseph S. Myers jos...@codesourcery.com
Re: [google]: initialize language field for clone function struct
C returns -1 from global_bindings_p, as does Ada. That the languages that probably care most about variable-size types find aspects of the generic function need overriding like that should be a good indication that it isn't really that generic - as I said above, semantics for variable sizes are very front-end-specific. I think that a large chunk of the non-generic code can be removed because it is either useless (the error) or obsolete (pending_size) in the 4.x series. After that, if you prefer to make this particular function FE-specific, fine with me, but they will all essentially look alike. -- Eric Botcazou
Re: [google]: initialize language field for clone function struct
On Tue, 3 May 2011, Eric Botcazou wrote: C returns -1 from global_bindings_p, as does Ada. That the languages that probably care most about variable-size types find aspects of the generic function need overriding like that should be a good indication that it isn't really that generic - as I said above, semantics for variable sizes are very front-end-specific. I think that a large chunk of the non-generic code can be removed because it is either useless (the error) or obsolete (pending_size) in the 4.x series. Well - the errors in variable_size aren't used by C any more (since 4.5), but I don't know whether any other languages use them. And pending sizes are used to a limited extent for C (to handle side effects in sizes of array parameters, as described in the comment /* ??? Insert the contents of the pending sizes list into the function to be evaluated. The only reason left to have this is void foo(int n, int array[n++]) because we throw away the array type in favor of a pointer type, and thus won't naturally see the SAVE_EXPR containing the increment. All other pending sizes would be handled by gimplify_parameters. */ ) although it would now be better to make use of the expr parameter to grokdeclarator to replace this residual use of the pending sizes global list. The most suspect case for using generic variable-size code would be C++, which has some limited, poorly-defined VLA support as a GNU extension. I don't know if Fortran, Java or Go use variable-size types at all. After that, if you prefer to make this particular function FE-specific, fine with me, but they will all essentially look alike. Actually, it will probably be possible the eliminate the function completely for C; there's no good reason to do more than calling save_expr directly. if (TREE_CONSTANT (size)) return size; Redundant, save_expr checks for constants. size = save_expr (size); The only necessary bit of c_variable_size once pending sizes are replaced by a better scheme. save = skip_simple_arithmetic (size); Premature optimization. if (cfun cfun-dont_save_pending_sizes_p) return size; if (!global_bindings_p ()) put_pending_size (save); No longer needed once pending sizes are replaced. return size; So this just becomes equivalent to save_expr. -- Joseph S. Myers jos...@codesourcery.com
Re: [google]: initialize language field for clone function struct
Is this one ok? David On Fri, Apr 29, 2011 at 4:38 PM, Xinliang David Li davi...@google.com wrote: During function cloning, the language field of the src func is not copied. This can lead to null dereference when gcc calls into langhook functions. Unfortunately, I lost track of the test case. Ok for trunk ? Thanks, David 2011-04-29 Xinliang David Li davi...@google.com * tree-inline.c (ininitialize_cfun): Initialize language field for clone cfun.
[google]: initialize language field for clone function struct
During function cloning, the language field of the src func is not copied. This can lead to null dereference when gcc calls into langhook functions. Unfortunately, I lost track of the test case. Ok for trunk ? Thanks, David 2011-04-29 Xinliang David Li davi...@google.com * tree-inline.c (ininitialize_cfun): Initialize language field for clone cfun. Index: tree-inline.c === --- tree-inline.c (revision 173176) +++ tree-inline.c (working copy) @@ -2087,6 +2087,7 @@ initialize_cfun (tree new_fndecl, tree c cfun-returns_struct = src_cfun-returns_struct; cfun-returns_pcc_struct = src_cfun-returns_pcc_struct; cfun-after_tree_profile = src_cfun-after_tree_profile; + cfun-language = src_cfun-language; init_empty_tree_cfg ();
