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: ObjC++: fix testcase failures on Darwin


On Nov 29, 2010, at 1:19 PM, IainS wrote:
>> So, let's talk about this some more...  I'm hoping that there is a more tactical solution.  I'm expecting that we could put in a call to objc_non_volatilized_type in a spot or two and be done with it.
> 
> Is there any way we can shift the code-gen to the lang-specific-gimpifier?

Unknown to me.  With a clean separation between semantic analysis and codegen, the change needs to happen just before code-gen.  I'd need middle/gimple type of people to help design a nice solution.  The best approach would not to constrain the solution space, but rather say, imagine if C where defined so that int i; in the presence of setjmp/longjmp were required to work.  How would you design it?  They could then come up with a nice design, and then we'd just implement it.

> (I fear we will need yet another code-gen for m64 NeXT exceptions).

Nope, that already works.  They use eh bits, and under eh, int i; just works.  It is only because setjmp doesn't require int i work, that problems arise.

> Ideally, we'd have only one parse pathway [on the basis that the language is common and we're only changing runtime]
> and switch the code-gen on runtime...

Yes.

> too big a change I guess?

Can't render that judgment without code.


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