ObjC patch: fix CLASS_HAS_EXCEPTION_ATTR

IainS developer@sandoe-acoustics.co.uk
Wed Feb 23 11:02:00 GMT 2011


Hi Nicola,

On 23 Feb 2011, at 01:52, Mike Stump wrote:

> On Feb 22, 2011, at 3:22 PM, Nicola Pero wrote:
>> This patch fixes one of the pending FIXMEs with the big ObjC patch  
>> committed
>> a few days ago, which is

thanks for looking at this - a solution that is local to ObjC is much  
better.

>> I also added a basic testcase for "attribute((objc_exception))".   
>> It only checks that
>> the attribute is accepted correctly; it would be good to have a  
>> testcase checking metadata
>> generation for Apple 64-bit (I did check that the flag gets  
>> detected correctly during
>> metadata generation by just hacking some code into the compiler; it  
>> would be nice to have a
>> complete standard test for the Apple 64-bit that checks the actual  
>> output).
>
> You can test the metadata by using scan and just having a snippet  
> that you know is correct.
>
> An example from the testsuite:
>
> 	/* { dg-final { scan-assembler ".globl _a.*.data.*.space\[\t  
> \]1" } } */
>
> . matches \n as well, and the thing to match is the entire .s file  
> produced.  If you want to control it, you'd want [^\n] for all but  
> newline.  You'd want to start from the symbol (something unique) and  
> then just match the output you expect.  If the label is uncontrolled  
> (L435), don't do that, but if it is something like  
> L_METADATA_CLASS_T, then it should be safe until we alter the name  
> and have to update the testcase.
>
>> Ok to commit ?
>
> Ok.  I'll pre-approve adding scan to the testcase, if you want, you  
> don't have to.

when there is next some time, I was planning to:

(a) move all the meta-data tests to the torture section (since they  
verify code-gen)
(b) this seems a weak area of testing for the GNU runtime, so add to/ 
strengthen testing there.
(c) perhaps segregate these particular tests by runtime (these should  
be the only tests that require that).

whilst it is possible to cater for (c) by putting target conditionals  
on the scan-assembler lines, they do start to get unwieldy (see the  
few examples dealing with NeXT m32/m64/ppc/i386) - and I don't believe  
that DejaGnu will allow us to break lines.  In this instance - it  
might be clearer to find a different solution for dealing with  
multiple runtimes.

cheers
Iain



More information about the Gcc-patches mailing list