[PATCHes] Misc aliasing fixes for building DLL with gcc-4.5.0
Mon Aug 10 15:22:00 GMT 2009
On Mon, Aug 10, 2009 at 05:28:16AM +0100, Dave Korn wrote:
>Christopher Faylor wrote:
>> On Mon, Aug 10, 2009 at 04:11:49AM +0100, Dave Korn wrote:
>>> * fhandler_tty.cc (process_input): Add dummy return to silence warning.
>>> (process_ioctl): Likewise.
>> Shouldn't these be defined with __attribute__ ((noreturn))?
> They probably should also, but (I forgot to mention) I tried it and it didn't
>solve the warning.
>>> * fork.cc (cygfork): New name with friendable C++ linkage for ...
>>> (fork): ... un-friendable extern "C" function becomes stub calling it.
>>> (class frok): Declare cygfork() friend, not fork(), avoiding PR41020.
>> Ugh. I don't like this. fork is slow enough and complicated enough
>> without adding this kind of workaround. If this is a problem with
>> declaring an 'extern "C"' friend function then it should be fixable by
>> just making fork() a C++ function but exporting it as a "C" function
>> in cygwin.din.
> My turn to say "ugh"! The wrapper function would translate down to a single
>'jmp' if -fno-omit-frame-pointer was in effect, but as things stand it's a bit
>ugly. So maybe we should let both of these rest for a while and see how things
>pan out upstream.
Yes, sometimes we do ugly things in Cygwin to avoid slowdowns, even if
it is to avoid a simple "jmp".
>> Also, referring to a bug without explaining what the problem either in
>> the source code or the ChangeLog is a guaranteed way to cause confusion
>> tomorrow after a memory cache refresh.
> You mean the PR notation? Hopefully GCC's bugzilla will still be there
>tomorrow! Anyway, with a bit of luck we won't end up needing this one at all.
Whether it is there tomorrow or not, we don't want to expect someone who
reads source code to know where to go to look for a gcc bugzilla entry.
More information about the Cygwin-patches