[PATCH] Named address support for GCC 4.5

Joseph S. Myers joseph@codesourcery.com
Wed Dec 3 00:50:00 GMT 2008


On Tue, 2 Dec 2008, Michael Meissner wrote:

> This is tested in the test suite:
> 
> extern __ea void f1 ();	 /* { dg-error "'__ea' specified for function 'f1'" } */

But that is a qualifier on the return type, not on the function itself.

"The return type of a function shall be void or an object type other than 
array type." (C99 6.9.1#3) so a qualifier (whether address space or 
otherwise) is not permitted on a void return type in a function 
definition, and is useless but permitted on non-void return types and on 
return types in declarations that are not definitions.  Unless there's 
some special named address space rule, an address-space qualifier on a 
non-void return type is OK, as is one on a void return type in a 
non-definition.

> > >  	    if (pedantic && TREE_CODE (type) == FUNCTION_TYPE
> > > -		&& type_quals)
> > > +		&& CLEAR_QUAL_ADDR_SPACE (type_quals))
> > >  	      pedwarn (input_location, OPT_pedantic,
> > >  		       "ISO C forbids qualified function types");
> > 
> > In this and subsequent places with this diagnostic or the "ISO C forbids 
> > const or volatile function types" one, however, such a prohibition applies 
> > to address space qualifiers as well, so their use should be diagnosed.
> 
> Because an error is given previously, I didn't see the point of adding a
> warning for this case.

But qualifiers on function types themselves, as opposed to on function 
return types, are disallowed, and the several places with one of these 
diagnostics are where this is checked (and each such case needs a 
testcase).  Yes, there should be an error for this - but the previous code 
isn't such an error.

> > > @@ -8274,6 +8319,17 @@ build_binary_op (location_t location, en
> > >  		  && TREE_CODE (tt1) == FUNCTION_TYPE)
> > >  		pedwarn (location, OPT_pedantic, "ISO C forbids "
> > >  			 "comparison of %<void *%> with function pointer");
> > > +
> > > +	      /* If this operand is a pointer into another address
> > > +		 space, make the result of the comparison such a
> > > +		 pointer also.  */
> > > +	      if (POINTER_TYPE_P (type0)
> > > +		  && (as = TYPE_ADDR_SPACE (TREE_TYPE (type0))))
> > > +		{
> > > +		  int qual = ENCODE_QUAL_ADDR_SPACE (as);
> > > +		  result_type = build_pointer_type
> > > +		    (build_qualified_type (void_type_node, qual));
> > > +		}
> > >  	    }
> > >  	  else if (VOID_TYPE_P (tt1))
> > >  	    {
> > > @@ -8281,6 +8337,17 @@ build_binary_op (location_t location, en
> > >  		  && TREE_CODE (tt0) == FUNCTION_TYPE)
> > >  		pedwarn (location, OPT_pedantic, "ISO C forbids "
> > >  			 "comparison of %<void *%> with function pointer");
> > > +
> > > +	      /* If this operand is a pointer into another address
> > > +		 space, make the result of the comparison such a
> > > +		 pointer also.  */
> > > +	      if (POINTER_TYPE_P (type1)
> > > +		  && (as = TYPE_ADDR_SPACE (TREE_TYPE (type1))))
> > > +		{
> > > +		  int qual = ENCODE_QUAL_ADDR_SPACE (as);
> > > +		  result_type = build_pointer_type
> > > +		    (build_qualified_type (void_type_node, qual));
> > > +		}
> > 
> > I don't see the checks that the address spaces overlap, as noted in my 
> > previous message.
> 
> I assume such checks would occur in the backend target hooks
> TARGET_ADDR_SPACE_CAN_CONVERT_P and TARGET_ADDR_SPACE_NOP_CONVERT_P would be
> the place to put such checks.

As you don't seem to be calling them from build_binary_op, I don't see how 
that helps.

Comparisons need to check the address spaces overlap.  Pointer subtraction 
needs to check they overlap.  I don't think the "void *" blocks you're 
changing have anything to do with this.  The check is needed both if the 
target types are non-void (possibly with qualifiers such as const and 
volatile), and if one is void (again possibly with such qualifiers) - in 
all the if branches.

> > I don't see any changes to the handling of conditional expressions, as 
> > noted in my previous message.
> 
> I assumed the checks in common_pointer_type would catch the case of conditional
> expressions as well as subtracting two different pointers.

common_pointer_type's interface is that it's only called when it will 
return a common type; it's not meant to cause diagnostics.  The patch 
doesn't seem to add such diagnostics either, or to change 
comp_target_types to reject the problem cases.  Furthermore, the issue 
applies to all cases where both operands are pointers (even I think where 
one is a null pointer constant - which will have to point into the generic 
address space), not just the one where they are pointers to possibly 
differently qualified versions of compatible types.

-- 
Joseph S. Myers
joseph@codesourcery.com



More information about the Gcc-patches mailing list