Tom Lane wrote:
>"Andrew Dunstan" <andrew@dunslane.net> writes:
>
>
>>Of course, the linux kernel is aimed at a limited set of compilers - as I
>>understand it basically gcc although it has been made to build with Intel
>>compilers
>>
icc once compiled the kernel. But they had to teach it quite a lots of
gccisms.
>> - which makes things somewhat easier for them. What is our target
>>set of compilers? What is our target version of C?
>>
>>
>
>"Pretty much anything that speaks ANSI C" is my usual feeling about
>that. As yet we have not heard of any non-gcc compilers in which this
>is a problem, although you have a point that some compiler somewhere may
>do this and not have a way to turn it off :-(
>
>
Intel's icc compiler supports strict alias analysis, but the default was
off.
>>Also note that uninhibited casting between types can still cause alignment
>>problems,
>>
>>
>
>We understand that issue, we solved it years ago.
>
>BTW, I haven't looked at the problem spots in detail. How many of them
>are due to the use of MemSet in conjunction with other access to a chunk
>of memory? ISTM that we need not worry about code motion around a
>MemSet call, since that would require the compiler to prove that the
>memset() path through the macro wouldn't be affected, which I doubt it
>would think.
>
>
gcc is quite good at propagating constants around. This is heavily used
in the linux-kernel: __builtin_constant(x), and then large switch
statements that are completely evaluated at compile time. There is a
good chance that gcc figures out that MemSet(,0,sizeof(double)) are two
writes to two integer values, and then decides that they can't alias
with reads/write to the double.
I'll search for a suitable gcc list and post the memset macro - that
might give a definitive answer.
--
Manfred