On Tue, Feb 23, 2010 at 12:03:52PM -0600, Brandon Black <blbl...@gmail.com>
wrote:
> Fine. This is the statement I think we are at odds about, in my first
> email in this thread:
No, you are just add odds with yourself :) Or maqybe you are too blind to
read what you wrote yourself (happens to me all the time...)
> I did not say, "I have seen aliasing errors in the libev code". I
Neither did I...
you: "I've seen this strict-aliasing issues with libev + gcc 4.4 as well."
you: "I wasn't asserting that there was an aliasing issue in libev."
me: "you asserted a "strict-aliasing issue", which to me sounds a lot like
an aliasing issue..."
Yeah, I was wrong - you said issues, I said issue. Doesn't really change
anything.
Why do you suddenly want to spin this into "errors", as if that made any
difference even?
All I asked you is to either a) stay true to your words or b)
retract/clarify your statement.
> compiler, although perhaps that was not explicitly clear), and then
We have to go by what you write, not by what you mean. I understand that it
is sometimes hard to express things precisely, but if I ask you to clarify,
it is really childish to react so stubbornly - either explain or retract, is
it that problematic?
> > 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
Interesting, I wasn't aware of such issues, but of course there are many
people out there who make bold easily-falsified statements.
> 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
While that is nice of you, it has zero relevance to libev, as libev
doesn't alias those members at all (that's the whole point of the casts,
obviously...).
It would be far more interesting to check whether any casts are missing,
causing gcc to not warn, but to actually alias, resulting in code
misoptimisations...
> it does or doesn't cause gcc optimization bugs, which may or may not
assuming aliasing where gcc doesn't does cause code not to behave as
intended. these are not optimisation bugs, but bugs in the code.
afaics, if you remove the casts, gcc will actually "misoptimise" ev.c,
as this results in aliasing and gcc will happily ignore writes when
inlining...
> be related to gcc's authors either not adhering to the standard, or
> being "more strict" about aliasing than the standard strictly
> requires.
gcc is documented to be less strict than C, btw.
> I'm taking you at your word that libev's pointer-aliasing doesn't
Yeah, and you beating your wife is probably not a problem for the economy
either.
As the very first I would like to see evidence for any aliasing in
libev. I have no clue what you are talking about, and so far, your statement
above is just more fud spreading...
Really, if you don't know, why can't you for god's sake ASK instead of
making up bullshit claims such as libev doing any pointer aliasing (or
relying on any (obviously legal) aliasing in fact, e.g. by using memcpy).
This continued assaults, intended or not, are really annoying.
You are making up bullshit faster than I can set it right!
I seriosuly suggets changing your strategy - don't make stupid statements you
have no clue about, ASK and I will answer.
So far, all my time in this discussion is sucked up by just clarifying
all the weird statements people do, without having the slightets clue
apparently.
If sth. is unclear, I can reply both by wearing my libev maintainer hat as
well as wearing my gcc maintainer hat.
It is hard for me to help you if you don't have any questions and just
make fullmouthed but wrong claims.
> 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.
If you rely on aliasing, then it's not similar, but maybe you again mean
something else?
> 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).
Yes, obviously it is much much harder to diagnose aliasing issues than to
take advantage of guaranteed non-aliasing...
> 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.
First you need to describe the issue you have. The only good description so
far was your example program, which doesn't have any aliasing at all.
If you are unclear on what aliasing itself means, I can write a short
paragraph to explain...
(the iso c documents ae not that hard to read, though, imho, with the
exception of structure member aliasing).
--
The choice of a Deliantra, the free code+content MORPG
-----==- _GNU_ http://www.deliantra.net
----==-- _ generation
---==---(_)__ __ ____ __ Marc Lehmann
--==---/ / _ \/ // /\ \/ / schm...@schmorp.de
-=====/_/_//_/\_,_/ /_/\_\
_______________________________________________
libev mailing list
libev@lists.schmorp.de
http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
