This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] AmigaOS 4 port contribution [target core]


"Joseph S. Myers" <jsm@polyomino.org.uk> writes:

> But you haven't added any documentation for the new target macro (and it
> now needs to be considered what sort of target macro/function interface
> for modifying function calls is wanted).

Yes, I was under the impression that the documentation for the
semantics of the attribute was to be the basis for this consideration,
so that's why I started there.


> I don't see any testcases for the attributes either in this patch.

The testcases in the initial mail still apply.


> > +If the expression that denotes the called function is a struct or union
> > +member expression as defined in (6.5.2.3), and has a type that includes
> 
> So not, for example, such an expression parenthesised, nor such an 
> expression with the function pointer dereferenced explicitly with *?  If 
> that's what you do mean, then testcases that indeed such calls have no 
> implicit argument should be included....

Parentheses are allowed, so something like "possibly enclosed in any
number of parenthesized expressions" should be added before the comma
(suggestions for better formulations?).

I'll make a testcase which tests that no implicit argument is passed
for explicitly dereferenced function pointers.


> > +denotes the called function if that is an lvalue, and in other case the
> > +address of a temporary variable holding the value of that operand.
> 
> Temporary of what lifetime?  Address this question for both C and C++.  
> Note that in C the structure values that aren't lvalues (arising from
> function return, conditional operator, comma operator, value of
> assignment, and used to access arrays in such structures) only live until
> the next sequence point, making them entirely unsuitable for this case
> because of the sequence point before the call, so you need a temporary of
> some specified longer lifetime.

Seems better to restrict the functionality to lvalues in that case.


  // Marcus





Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]