Off list, Mike S. pointed out that the Objective C
front-end uses the lang-specific extensions to
GCC's tree node, and it shares logic with the C
and C++ front ends. Therefore, the lang-specific
extensions might offer an alternative approach
for storing UPC's layout qualifier. The current plan,
h
On 07/02/11 15:21:32, Joseph S. Myers wrote:
[...]
> In general configure options aren't really a good idea in many cases:
>
> * If something is always best on a particular architecture, maybe you want
> a target hook (not macro) rather than a configure option, with the target
> hook being set a
On Fri, 1 Jul 2011, Gary Funck wrote:
> The reason that so many #ifdef's and #defines remain is that
> I wasn't sure about the best method of parameterizing those values to
> avoid the use of conditional compilation. For example, should
> a small struct be defined that has fields for the configur
On 07/01/11 16:39:55, Mike Stump wrote:
> You can use that to allocate additional data for the frontend's exclusive
> use.
> See the C++ frontend, it uses language specific data. :-)
Heh. It sounds like this language-specific hook works well for language
front-ends that aren't sharing the logi
On 07/02/11 00:06:07, Jakub Jelinek wrote:
> Yes, look at DECL_VALUE_EXPR/SET_DECL_VALUE_EXPR/DECL_HAS_VALUE_EXPR_P
> or DECL_DEBUG_EXPR/SET_DECL_DEBUG_EXPR/DEBUG_EXPR_IS_FROM.
OK, thanks. The UPC front end will be changed use a similar method to
encode UPC's block size.
On 07/01/11 19:28:34, Joseph S. Myers wrote:
> On Fri, 1 Jul 2011, Gary Funck wrote:
> GF: * Most of the #ifdef conditionals have been removed. Some target macros
> GF: have been defined and documented in tm.texi. We still have some questions
>
> [...]
> I looked at the first of the documented ma
On Jul 1, 2011, at 2:34 PM, Gary Funck wrote:
> Is there some way to use the language specific information hook?
>
>struct GTY(()) tree_type_with_lang_specific {
> struct tree_type_common common;
> /* Points to a structure whose details depend on the language in use. */
> struc
On Fri, Jul 01, 2011 at 02:34:41PM -0700, Gary Funck wrote:
> Is there precedent for this technique being used in other GCC front-ends?
Yes, look at DECL_VALUE_EXPR/SET_DECL_VALUE_EXPR/DECL_HAS_VALUE_EXPR_P
or DECL_DEBUG_EXPR/SET_DECL_DEBUG_EXPR/DEBUG_EXPR_IS_FROM.
Jakub
On 07/01/11 22:42:55, Jakub Jelinek wrote:
> On Fri, Jul 01, 2011 at 11:31:45AM -0700, Gary Funck wrote:
> > @@ -2405,6 +2469,9 @@ struct GTY(()) tree_type_common {
> >alias_set_type alias_set;
> >tree pointer_to;
> >tree reference_to;
> > + /* UPC: for block-distributed arrays */
> >
On Fri, Jul 01, 2011 at 11:31:45AM -0700, Gary Funck wrote:
> @@ -2405,6 +2469,9 @@ struct GTY(()) tree_type_common {
>alias_set_type alias_set;
>tree pointer_to;
>tree reference_to;
> + /* UPC: for block-distributed arrays */
> + tree block_factor;
>
I think this is undesirable. U
On 07/01/11 19:28:34, Joseph S. Myers wrote:
> On Fri, 1 Jul 2011, Gary Funck wrote:
> GF: * Most of the #ifdef conditionals have been removed. Some target macros
> GF: have been defined and documented in tm.texi. We still have some questions
>
> For each target macro, what is the justification
On Fri, 1 Jul 2011, Gary Funck wrote:
> * Most of the #ifdef conditionals have been removed. Some target macros
> have been defined and documented in tm.texi. We still have some questions
For each target macro, what is the justification requiring it to be a
macro rather than a hook documented
12 matches
Mail list logo
