Re: [PATCH 2] fix broken strict aliasing
On Wed, Feb 24, 2010 at 07:33:39PM +0100, Marc Lehmann wrote: On Wed, Feb 24, 2010 at 05:39:41PM +0100, com...@gmx.ch com...@gmx.ch wrote: (the iso c documents ae not that hard to read, though, imho, with the exception of structure member aliasing). Therefore I'd be glad to get more information on the topic. Thanks for the offer. Well, it's not fundamentally complicated. [...] Note: I haven't proofread this well, so it might be fuzzy, hard to understand or even wrong in some places, feel free to ask for clarifications or additions. It was pretty enlightning for me, many thanks. I think you should consider making this part of the FAQ (or at least pointing to this mail from the FAQ), this could avoid similar misunderstanding in the future. Regards, -- Gabriel Kerneis ___ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
Re: [PATCH 2] fix broken strict aliasing
On Thu, Feb 25, 2010 at 9:20 AM, Gabriel Kerneis kern...@pps.jussieu.fr wrote: On Wed, Feb 24, 2010 at 07:33:39PM +0100, Marc Lehmann wrote: Well, it's not fundamentally complicated. It was pretty enlightning for me, many thanks. Same here, actually one of the most interesting threads ever on this list. Many thanks Marc! Regards /Joachim ___ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
Re: [PATCH 2] fix broken strict aliasing
Hi, Marc Lehmann wrote: 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). I've had the same discussion before, but just pulled my claim as Marc was involved in gcc development, and I did not feel I could make a point. I've had the same problems, -Wall -Werror, as I consider the compiler my friend and if he wants to tell me something it usually pays of when I'm listening to him. But, I totally understand if Marc says it is not a libev bug, and rejects to add casts to proper code - to fix compiler misbehavior. Therefore I'd be glad to get more information on the topic. Thanks for the offer. Markus ___ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
Re: [PATCH 2] fix broken strict aliasing
On Wed, Feb 24, 2010 at 05:39:41PM +0100, com...@gmx.ch com...@gmx.ch wrote:
(the iso c documents ae not that hard to read, though, imho, with the
exception of structure member aliasing).
Therefore I'd be glad to get more information on the topic.
Thanks for the offer.
Well, it's not fundamentally complicated.
1. ALIASING
Aliasing (in this context) means to access the same storage area by different
aliases. For example, here:
int i;
int *p = i;
Now i and *p are alises for the same storage location. Now take this
example, which uses different types:
int a = 4;
long *b = (void *)a;
a = 5;
assert (*b == 5);
If long and int have the same size representation (typically yes on
32 bit archs), then this should intuitively work - a has the same bit
representation as *b, so a and *b are _aliases_ for each other, and cpus
will not have issues with implementing this, the assert should not fail.
2. ALIASING AND C
The problem is, C says that a compiler can assume that int variables
never are aliases for long variables *by definition*, as different types
never alias each other. That means gcc can assume that *b is NEVER a, or
b is never pointing to a, simply because C says it can do so. Or in other
words, for gcc, a and *b are two different variables.
There are exceptions - for example, char variables *may* alias with any
other type.
Now, when you access the same storage area via different types, you have a
potential aliasing issue - YOU might WANT the expressions to be aliases
for the same variable, but if none of them is of type char, then the compiler
might overrule you and say no, I just don't see why I should assume it is
the same storage area.
In the latter case you have an aliasing bug - YOU assume the
expressions/variables/storage spaces/pointer targets are aliases, gcc
disagrees and will not notice that writes to one alias will modify the
other.
In the above example:
a = 5;
assert (*b == 5);
WE might assume that a and *b are aliases, but gcc will assume that they
are not, so gcc will not see that *b is actually 5 as *b has never been
written to, according to the C standard.
That for example means that the only way to portably implement memcpy
would by by using a char-to-char copy, as other data types do not alias
with each other, but using char to access any object is safe, as it is
indeed aliasing with any other type.
3. LIBEV-BASED EXAMPLE
Here is a more practical example: take ev_watcher and ev_io structs in
libev. Both have an int active member at the same location:
struct ev_watcher { int active; };
struct ev_io { int active; };
// union with both omitted
Now, *some* readings of the C standard say (and I would personally support
these, although they are often not helpful), that accessing (ev_watcher
*)-active NEVER accesses the active member of ev_io, as the types are
different, so one active member is never an alias for the other.
Gcc follows this reading, as it is allows for important (IMHO)
optimisations.
That means that this code:
struct ev_io io;
struct ev_watcher *w = (ev_watcher *)io;
io.active = 0;
assert (w-active == 0);
might fail (and code like this sometimes happens to fail with current gcc
versions), because gcc assumes that w-active is not the same storage area
as io.active, i..e they do not refer to the same variable.
This is why libev always uses the ev_watcher * cast, i.e. it never
accesses active via ev_io or other types, only ever through ev_watcher
*, so libev does not rely on aliasing at all (in theory, it does
however still make a lot of unportable assumptions w.r.t. the C standard
internally).
Or in other words, libev puts a struct ev_watcher at the same storage
address as ev_io. It doesn't use the overlapping data members of the ev_io
watcher. They could in fact be missing, as long as ev_io contains enough
padding at that place - the ev_watcher occupies the head of the memory
area, ev_io the tail.
4. THE GCC WARNING AND LIBEV
The warning gcc emits still applies - it tells you that accessing the
active member via e.g. ev_io might not work.
Note that the gcc warning does not claim that such an access actually
happens anywhere, just that *if* there was one, then you might fall for an
aliasing issue.
As for libev, there might be any number of ways to avoid this warning
most of which will increase maintainance overhead, generate a lot of work
and might cause issues with other systems, as they are big changes. Maybe
there is a magic way to express this that avoids the gcc warning in all
cases (maybe an extra (void *)) will do the trick, but it is by far
simplest and safest to keep the code in a working state until a better
solution is found and well understood.
I think aliasing issues are not really common in practise UNLESS you
really designed the software to take advantage of aliasing. You are
unlikely to a) understand the warning and b) write code that has buggy
aliasing assumptions, so in my book,
Re: [PATCH 2] fix broken strict aliasing
On Sat, Feb 20, 2010 at 16:01, Marc Lehmann schm...@schmorp.de wrote: On Fri, Feb 19, 2010 at 07:14:28PM +0100, Alejandro Mery am...@geeks.cl wrote: ok, simple test case. (yes, it's only warnings, but they distract a LOT) Really, this has nothing to do with libev - you found a buggy warning in your compiler, report this against your compiler, or switch it off. What's so difficult about it? Libev cannot and will not care about the many versions of compilers that generate bogus warnings, just as thousands of other software packages will not - this is an issue in your compiler, or your flags. Hello Marc, what compiler are you using? because gcc produces these warnings with every version since libev got born. Regards, Alejandro Mery ___ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
Re: [PATCH 2] fix broken strict aliasing
On Mon, Feb 22, 2010 at 10:56:24AM +0100, Alejandro Mery am...@geeks.cl wrote: what compiler are you using? because gcc produces these warnings with every version since libev got born. gcc, and this is not true. -- 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
Re: [PATCH 2] fix broken strict aliasing
On Mon, Feb 22, 2010 at 16:11, Marc Lehmann schm...@schmorp.de wrote: On Mon, Feb 22, 2010 at 10:56:24AM +0100, Alejandro Mery am...@geeks.cl wrote: what compiler are you using? because gcc produces these warnings with every version since libev got born. gcc, and this is not true. so my sample code compiled for -O2 or higher or -Os doesn't dump the warning fest with your gcc version? I don't claim libev is buggy or that gcc is buggy, i simply say that the way that macro-magic is implemented confuses the compiler. it doesn't allow it to optimize correctly and who knows if it can trigger gcc-bugs, and also fills the compilation logs of our programs with tons of noise that doesn't allow libev users to see clearly real warnings/errors that do need to get fixed. so maybe those macros could be rewritten in a way that doesn't confuse the compilers and fill the compile log of noise just for the sake of the mental sanity of libev users? :) ___ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
Re: [PATCH 2] fix broken strict aliasing
On Mon, Feb 22, 2010 at 04:33:38PM +0100, Alejandro Mery am...@geeks.cl wrote: gcc, and this is not true. so my sample code compiled for -O2 or higher or -Os doesn't dump the warning fest with your gcc version? Not with those options at least. Keep in mind that these warnings apply to YOUR CODE, not to libev code. they are easy enough to avoid IN YOUR CODE with YOUR PARTICULAR WARNING SET and will not happen with the default set of any known compiler. Forcing YOUR particular set of warnings on other people's code is rather childish (and I think very unfriendly), especially as the warning is KNOWN TO BE BOGUS. Also you have been asked to review old discussions AND the existing documentation - you showed no evidence of doing either. Why can't you be bothered to be constructive and do those things? That is the minimum you can do. the way that macro-magic is implemented confuses the compiler. it I don't see why, it uses the correct casts for everything, afaics. Nobody produced any valid evidence to the contrary (as opposed to a lot of bullshit about standard C). doesn't allow it to optimize correctly and who knows if it can trigger gcc-bugs, And maybe it kills all first-born children, too. It would be nice if you could really stop making up all this fud. and also fills the compilation logs of our programs with tons of noise that doesn't allow libev users to see clearly real warnings/errors that do need to get fixed. This has been discussed in the past, and also in the documentation. See above. Why are you so antisocial and can't do that? Your issues are not new, and neither are the solutions. so maybe those macros could be rewritten in a way that doesn't Nobody found a way yet - the ways described certainly confuses the compiler even more, otherwise it would still issue the warning, no? See also how it might kill first-born children, above. confuse the compilers and fill the compile log of noise just for the sake of the mental sanity of libev users? :) I don't see how it confuses things. If anything, the warning itself is confusing - maybe you don't understand what it means, maybe it is bogus - in any case, it is obviously not a helpful warning, right? Apart from FUD (see first borns, above), this discussion has resulted in nothing new, it's just the same tiresome it could be bad, but I have no clue thing as before. Doing as told and RTFM'ing might have helped, but you chose not to. Libev doesn't require type aliasing beyond what standard C offers, and no evidence to the contrary is known. The programming techniques used in libev are hardly weird either, it's pretty common. In any case, please read the warning section of the documentation. (REALLY DO IT THIS TIME! Thats the minimum you need to do!) and please describe what you found unclear, confusing, or a bug. Otherwise, please take your unfounded allegations elsewhere. Your it could be bad bullshit is really damaging - come up with facts (or evidence), or shut up. If your code produces warnings that you can avoid with a cast, THEN DO THAT CAST. Forcing your specific set of bogus warnings on other people code IS childish and really IS NOT productive. In no case is a cast in those macros required. -- 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
Re: [PATCH 2] fix broken strict aliasing
On Sat, Feb 20, 2010 at 09:41:35AM -0600, Brandon Black blbl...@gmail.com wrote: I've seen this strict-aliasing issues with libev + gcc 4.4 as well. I You say to have seen strict aliasing issues, but none have been reported so far. Care to actually come up with the issues you have or think to have? There are currently no known strict aliasing issues. Making them up out of the air doesn't really count. All this is so far is a major time waster for everybody. Facts please... -- 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
Re: [PATCH 2] fix broken strict aliasing
On Sat, Feb 20, 2010 at 06:20:26PM +0100, Zsbán Ambrus amb...@math.bme.hu wrote: elements that way. The compiler warns about that because the C standard doesn't guarantee that the rest of the elements of the struct doesn't change how the first elements are laid out in the struct, but To the contrary, the C standard guarantees just that, and gcc follows it. Seearch for common initial sequence. Think about it, if the C standard didn't make that guarantee, unions would be mostly useless. Don't make so certain statements about the C standard if you don't really know it - you are doing a disservice to anybody else who might be stupid enough to blindly believe you. (Sorry to be so explicit, but I get really annoyed when people argue with made-up arguments like yours - check your facts, this is easy enough to google). that isn't likely to happen on any real system (which has abi rules so different compilers can interoperate). In theory, one could avoid It cannot happen on any system, real or theoretic, as long as it implements C. Incidentally, what bothers me more than these aliasing warnings is that there's both a structure called struct ev_loop and a function called ev_loop in the same header. Apparently C++ does allow this -- C allows it as well of course. I am not swure what others you, but the struct tag namespace and the function identifier namespace are distinct in both languages, and have been that way forever. Of course, if standard C (or C++) bothers you, maybe you could interest yourself with the perl interface, which has simpler scoping rules, albeit Perl has never been standardised. -- 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
Re: [PATCH 2] fix broken strict aliasing
On 02/20/2010 04:06 PM, Marc Lehmann wrote: Making things up doesn't make them true - do you really think this will help your credibility? This and other compiler bugs have been discussed in the past and are even discussed to some extent in the documentation. Why you think you need to bring this up in this way, without presenting any new evidence and by blatant attempts at bullshitting escapes me. I had been burnt quite severely one time with openssl and powerpc, thus I'm a bit touchy about such issues, I'll doublecheck what the actual macros are doing. You surely have a better knowledge than me about where those macros are located and what they do, please check them as well. lu -- Luca Barbato Gentoo/linux http://dev.gentoo.org/~lu_zero ___ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
Re: [PATCH 2] fix broken strict aliasing
On Fri, Feb 19, 2010 at 07:14:28PM +0100, Alejandro Mery am...@geeks.cl wrote: ok, simple test case. (yes, it's only warnings, but they distract a LOT) Really, this has nothing to do with libev - you found a buggy warning in your compiler, report this against your compiler, or switch it off. What's so difficult about it? Libev cannot and will not care about the many versions of compilers that generate bogus warnings, just as thousands of other software packages will not - this is an issue in your compiler, or your flags. -- 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
Re: [PATCH 2] fix broken strict aliasing
On Sat, Feb 20, 2010 at 9:41 AM, Brandon Black blbl...@gmail.com wrote: 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. The newer versions of gcc are very aggressive about aliasing assumptions for optimization, and my hunch is that this is a real issue with newer gcc's that really care about strict aliasing, but it's just a hunch at this point. I plan at some point in the next few days to dig into this in detail and sort it out for sure one way or the other. I meant to add (but forgot): if anyone is really worried this could cause a bug in your code in the short term, you can simply use -fno-strict-aliasing when compiling libev, which will prevent the compiler from making any bad aliasing assumptions about libev code. ___ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
Re: [PATCH 2] fix broken strict aliasing
I did look at those strict aliasing warnings a while back. It seemed to me that they're not bugs. They're caused by the header declaring structures (specifically ev_* and ev_watcher) that start with some common elements, casting a pointer to one to a pointer top the other, and accessing the common elements that way. The compiler warns about that because the C standard doesn't guarantee that the rest of the elements of the struct doesn't change how the first elements are laid out in the struct, but that isn't likely to happen on any real system (which has abi rules so different compilers can interoperate). In theory, one could avoid these warnings by having the larger structures have the smaller structures as their first member, not just sharing their first members, but that might make the code uglier and is not worth imo. (The strange thing is that in some places the ev.h header actually has code to silence these same warnings, such as in the ev_init macro.) The warnings are a bit annoying because they appear in user code that expand macros from the ev.h header, and with gcc they were not specific enough for me to easily tell that these are indeed caused by the header doing these casts, not something in my code. Incidentally, what bothers me more than these aliasing warnings is that there's both a structure called struct ev_loop and a function called ev_loop in the same header. Apparently C++ does allow this -- I don't quite understand the rules, but then I don't understand the rules that allow the double meaning of std::clog either. Ambrus ___ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
Re: [PATCH 2] fix broken strict aliasing
On 19/02/10 18:22, Marc Lehmann wrote: On Thu, Feb 18, 2010 at 09:12:45PM +0600, Denis F. Latypoffde...@gostats.ru wrote: Just found yet another potentially broken strict aliasing rules in ev.c same here, this is at best a nop and at worst a dangerous patch. it has no effect on any aliasing issues you might have seen (obviously, as the types are still the same). what's the danger? why do you insist in refusing this? at best they reduce tons of warnings without affecting the code. what's wrong with the warnings? they add tons of noise that doesn't allow us to see clearly other warnings that can be interesting. Regards, Alejandro Mery smime.p7s Description: S/MIME Cryptographic Signature ___ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
Re: [PATCH 2] fix broken strict aliasing
On Fri, Feb 19, 2010 at 06:26:49PM +0100, Alejandro Mery am...@geeks.cl wrote: what's the danger? why do you insist in refusing this? a compiler might well find an aliasing issue with the existing code, but unlikely with the patch. at best they reduce tons of warnings without affecting the code. if you get tons of warnings then your compiler or config is broken, and this is certainly the exception. what's wrong with the warnings? good question, I don't get any warnings, and libev doesn't generate them. so you need to identify where the warnings originate (e..g in your compiler) and then ask this question to those people who actually control the code that generates such bogus warnings. they add tons of noise that doesn't allow us to see clearly other warnings that can be interesting. exactly... but this really is out of the scope for libev, as libev doesn't generate those warnings. -- 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
Re: [PATCH 2] fix broken strict aliasing
Hi again,
On 19/02/10 18:39, Marc Lehmann wrote:
On Fri, Feb 19, 2010 at 06:26:49PM +0100, Alejandro Meryam...@geeks.cl wrote:
what's the danger? why do you insist in refusing this?
a compiler might well find an aliasing issue with the existing code, but
unlikely with the patch.
at best they reduce tons of warnings without affecting the code.
if you get tons of warnings then your compiler or config is broken, and this
is certainly the exception.
what's wrong with the warnings?
good question, I don't get any warnings, and libev doesn't generate them.
so you need to identify where the warnings originate (e..g in your
compiler) and then ask this question to those people who actually control
the code that generates such bogus warnings.
they add tons of noise that doesn't
allow us to see clearly other warnings that can be interesting.
exactly...
but this really is out of the scope for libev, as libev doesn't generate
those warnings.
ok, simple test case. (yes, it's only warnings, but they distract
a LOT)
$ grep -n ^ test.c
1:#include ev.h
2:#include stdio.h
3:
4:static void stdin_cb(struct ev_loop *loop, ev_io *w, int revents)
5:{
6: puts(stdin ready\n);
7: ev_io_stop(loop, w);
8: ev_unloop(loop, EVUNLOOP_ALL);
9:}
10:
11:int main(void)
12:{
13: struct ev_loop *loop = ev_default_loop(0);
14: ev_io stdin_watcher;
15:
16: ev_io_init(stdin_watcher, stdin_cb, 0, EV_READ);
17: ev_io_start(loop, stdin_watcher);
18:
19: ev_loop(loop, 0);
20:
21: return 0;
22:}
$ gcc -W -Wall -O2 -o test -lev test.c
test.c: In function ‘stdin_cb’:
test.c:4: warning: unused parameter ‘revents’
test.c: In function ‘main’:
test.c:16: warning: dereferencing type-punned pointer will break
strict-aliasing rules
test.c:16: warning: dereferencing type-punned pointer will break
strict-aliasing rules
test.c:16: warning: dereferencing type-punned pointer will break
strict-aliasing rules
test.c:16: warning: dereferencing pointer ‘stdin_watcher.22’ does
break strict-aliasing rules
test.c:16: warning: dereferencing pointer ‘stdin_watcher.22’ does
break strict-aliasing rules
test.c:16: warning: dereferencing pointer ‘stdin_watcher.22’ does
break strict-aliasing rules
test.c:16: warning: dereferencing pointer ‘stdin_watcher.22’ does
break strict-aliasing rules
test.c:16: warning: dereferencing pointer ‘stdin_watcher.22’ does
break strict-aliasing rules
test.c:16: note: initialized from here
$ gcc --version
gcc (Ubuntu 4.4.1-4ubuntu9) 4.4.1
Regards,
Alejandro Mery
smime.p7s
Description: S/MIME Cryptographic Signature
___
libev mailing list
libev@lists.schmorp.de
http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
Re: [PATCH 2] fix broken strict aliasing
On 02/19/2010 06:39 PM, Marc Lehmann wrote: what's wrong with the warnings? good question, I don't get any warnings, and libev doesn't generate them. so you need to identify where the warnings originate (e..g in your compiler) and then ask this question to those people who actually control the code that generates such bogus warnings. Are you _sure_ those are bogus? If you are using x86 with an ancient gcc you may not see them nor experience issues, any recent gcc on any recent arch will scream this way and with a reason... lu -- Luca Barbato Gentoo/linux http://dev.gentoo.org/~lu_zero ___ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
