Re PR 43512 and Re: PING#2 Re: PING *objc, NeXT runtime, testsuite changes*

[IainS]

On 24 Mar 2010, at 22:57, Janis Johnson wrote:

>> I can do that.

In view of the temporary extra fails [43512] showing on linux I've  
gone as quickly as possible ...
... (although, I'm not sure whether I regard the fails as real  
regressions - or simply that the tests were not being carried out  
correctly before)

Part 2 resolves those - and does the main bulk of the solution to  
PR35165.

I'm attaching a formatted changelog ... it's lengthly and repetitive.   
I hope it's correctly stylistically.

Essentially, as a reprise:

on all targets gnu-runtime is tested
on darwin gnu and NeXT runtimes are tested -this is now done in two  
loops in objc.dg and obj-c++.dg with the runtime mentioned  
specifically rather than relying on defaults...

The ABI differences in post Darwin9 systems are wrapped up in a series  
of new headers in a common directory shared between ObjC and ObjC++.
This includes an updated version of next-mapping.h (moved from objc/ 
execute/next_mapping and updated).

---

A medium-term goal should be to migrate all the small sections of  
code  that cater for those differences into next-mapping.h.
However, that is too long a job for now - and would get in the way of  
solving the basic problem: vix: we can't see the wood for the trees -  
because of the cruft of ABI-related error messages.

I am attaching a tar file with the new files - and pointing out that  
objc/execute/next_mapping.h should be deleted -- these kind of changes  
are a little more difficult to embed in a diff.

===

There's more that could be done to reduce the spurious messages for  
ObjC++ - but it's getting to be a large patch anyway.

IMO any errors that remain (certainly at m32) should be considered  
genuine 'bugs' and not incidental fall-out from Darwin's ObjC ABI  
change.

The changes show no regressions on the platforms I have access to  
[darwin, pc-linux] .. in fact, I've tried hard to make them darwin- 
local...

===

There is one piece of weirditude that causes a test to pass on linux  
only if the -fnext-runtime is left in the test. [objc.dg/encode-1.m].
This is because the -fgnu-runtime flag causes the compiler to find the  
requisite headers - but the -fnext-runtime flag causes it to generate  
the correct code.
I think this is probably a completely anomalous historical test  
situation - there is no reason for a linux compiler to generate mach-o  
compliant code...

However, if I "correct" it - it will cause a 'regression' on Linux....  
so it needs looking at later;
I've preserved the status-quo to minimize things people need to  
consider.

hope this OK now..
Iain

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: 157723-PR35165-changelog.txt
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20100325/eff46cf5/attachment.txt>
-------------- next part --------------



-------------- next part --------------
A non-text attachment was scrubbed...
Name: 157723-objc-c++-shared.tar
Type: application/x-tar
Size: 40960 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20100325/eff46cf5/attachment.tar>
-------------- next part --------------


-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: 157723-objc-pr35165-part2-diff.txt
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20100325/eff46cf5/attachment-0001.txt>
-------------- next part --------------