This is the mail archive of the 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: Keeping unreachable code

On Monday 04 February 2002 00:18, you wrote:
> <<It can if it thinks it is 'dead' code and it does since no jumps targets
> the code. The address of the exception handler is kept in a table so the
> runtime library can find it.
> It cannot throw away a fucntion that could potentially be called from
> some other file, that's obvious, and that's what you disagreed with.
> <<It is not a whole C function it throws is part of the code I
> have modified it to emit for __try/__except blocks.
> Then it is not a function, and has nothing to do with what I said. Of
> course it will throw away code of the kind you describe. In fact I think
> you are persuing a lost cause here. Optimization will kill you in general
> (we have found that in the move from GCC 2.8.1 to GCC 3 for GNAT, it was
> impossible to keep the old GNAT zero cost exception mechanism working,
> because of optimziations -- not only throwing away code, but more
> importantly, moving code around in ways that are inconsistent with the
> model -- I bet you will run into the same problem.
> Why are you doing this at all?

I am doing this because I'm developing a open source Windows NT clone (see using GCC/MinGW. MS Visual C++ compiler supports Structured 
Exception Handling (SEH), which is exception handling at the OS and compiler 
level, but GCC does not.
SEH can be used to make robust drivers and is required for some 
types of Windows NT drivers. MinGW will benefit from SEH support in GCC too 
since Windows applications can use it too.


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