On Tue, Feb 23, 2010 at 8:25 AM, Marc Lehmann <schm...@schmorp.de> wrote:
> On Mon, Feb 22, 2010 at 02:05:58PM -0600, Brandon Black <blbl...@gmail.com>
> wrote:
>> > Can we settle this please, or _finally_ bring some evidence?
>>
>> You're arguing with the wrong person. I didn't submit the patch, and
>> I have never once asserted that there was a problem with the libev
>> code with regards to aliasing.
>
> Except that you explicitly wrote that and reinforced it later. You have
> weird says of writing what you apperently didn't assert. Maybe use quote
> characters around assertions that you didn't mean to come from you?
>
> I know you didn't submit the patch, but I still know what you wrote. Maybe
> it was a simple mistake you did, but fact is that you did assert that
> there is an issue with libev and strict aliasing, and so far, you haven't
> taken back that statement.
>
> So please be bold enough to stand by your words or clarify them. Saying A
> and then claiming you didn't assert A does not do it in my eyes.
Fine. This is the statement I think we are at odds about, in my first
email in this thread:
"I've seen this strict-aliasing issues with libev + gcc 4.4 as well. I
haven't bothered to report it yet simply because I haven't had the
time to sort out exactly what's going on, and whether it's a real
issue that needs to be fixed, or as you've said, just an annoying
bogus warning."
I did not say, "I have seen aliasing errors in the libev code". I
said I had seen strict-aliasing issues with libev + gcc 4.4 ("issues"
here meaning I'm seeing warnings with this code compiled with this
compiler, although perhaps that was not explicitly clear), and then
noted that I have not yet determined for myself whether the warnings
are bogus.
>> I just find these warnings confusing,
>
> Then don't enable them - libev doesn't enable them, and with every
> released version of gcc you explicitly have to ask for them.
Because of all of the FUD and misinformation surrounding gcc aliasing
warnings in general (not just here on this mailing list), they are
something I wanted to verify. I'm still not entirely clear, in the
general case, when aliasing through pointers to technically-unrelated
types (two different structs which just happen to have a common set of
initial members, in this case) is allowed by the C standard, and when
it does or doesn't cause gcc optimization bugs, which may or may not
be related to gcc's authors either not adhering to the standard, or
being "more strict" about aliasing than the standard strictly
requires.
I'm taking you at your word that libev's pointer-aliasing doesn't
cause bugs when compiled with gcc (probably the most common compiler
for libev), partly because you're a smart guy, and partly because the
technique in question is in wide use elsewhere. I even use similar
techniques in my own code, although subtle differences make mine not
emit the warnings. From what I gather around the internet, whether or
not any given version gcc issues aliasing warnings for any given chunk
of code may be completely orthogonal to whether there is a gcc
aliasing-related optimization bug anyways, though (much less
orthogonal to complying with the C standards).
But I still would like to know, for my own sake, what the rules are on
this issue. My own google searching on this topic has turned up a lot
of confusing and contradictory information.
-- Brandon
_______________________________________________
libev mailing list
libev@lists.schmorp.de
http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
