On 9/4/16 09:01, Al Viro wrote: > On Sun, Sep 04, 2016 at 06:36:56AM +0800, Chen Gang wrote: > >> And for all: shall I provide the proof for another archs? >> >> For me, Boolean gives additional chance to compiler to improve the code. > > Whereas for compiler it gives nothing. Not in those cases. > >> If the compiler can not improve the code, it can treat it as int simply. >> So theoretically, at least, Boolean should not be worse than int. > > Except for pointless code churn and pandering to irrational beliefs, that > is... > Please, RTFISO9899 and learn the semantics of _Bool; it's not that > complicated. > Start with 6.2.5[2,6] and 6.3.1.2, then look through 6.8.4 and 6.8.5 to > figure out the semantics of conditions in if/while/for. Note also 6.5.8, > 6.5.9, 6.5.13 and 6.5.14 and observe that type of (x > 5 && y < 1) is *NOT* > _Bool; it's int. > > If you can show any improvement or loss in code generation in this case > (static inline int converted to static inline bool), I would really like to > see the details. As in .config/file/function/gcc version/target architecture. > Optimizer bugs happens, but they should be reported when found, and I would > expect _Bool handling to be _less_ exercised than that of normal logical > expressions, so loss is probably more likely. And yes, it also should be > reported. >
Sorry for replying late, and excuse me, I did not read the details more. During these days I have no enough time on it (working, buying house, and catching a cold, but lucky enough that my father's health is OK). I shall try to read the details and analyze it within next weekend (I guess I can not finish within this week end, sorry again for I really have no time during these days). But all together, for me, I guess our discussion can not 'prevent' that bool return value instead of int return value for pure bool function in our kernel. :-) Thanks. -- Chen Gang (陈刚) Managing Natural Environments is the Duty of Human Beings.
