Re: Question about genassym, locore.s and 0-sizedarrays(showstopper for an icc compiled kernel)
Alexander Leidinger wrote: Dan Nelson [EMAIL PROTECTED] wrote: If you're talking FreeBSD 5, you should be able to simply subsitute a C99 flexible array member (basically replace [0] with []) and get the same effect. 0-length arrays are a gcc extension: http://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html Under FreeBSD 4.x, you can't use them because gcc 2.95 only supports the gcc extension. Intel has added support for a lot of gcc extensions recently; they may be willing to add this to the list. Please read my mail again, icc already supports my_array[0], but the resulting array in the binary has size '1'. The actual showstopper is the output of genassym.sh. To me it seems it's just a genassym.sh issue, but I don't really know what's going on in the kernel, so I ask here. The ICC is wrong. If they are supporting a GNU extension, they must do it the same way GNU does it, to actually be supporting it. The main issue here is that any reader of the object file, not just genassym.sh, will be unable to differentiate [0] vs. [1]. What does ICC do for []? Is it '1' also, or is it '0', like it's supposed to be? I, for one, would not be unhappy to see the GCC-ism fade into history. -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Question about genassym, locore.s and 0-sizedarrays(showstopper for an icc compiled kernel)
Dan Nelson wrote: I guess the correct question to be asking is does the ELF format allow 0-length symbols? It does, according to my reading of it. They may have an issue with dead code removal or element aliasing. The way to find out would be to see what they emit for []... 0 lenth, or 1? If not, then gcc is generating invalid objects, and genassym will have to be rewritten to not use them (maybe add one to the array size, and have genassym.sh subtract it). If it does, then genassym.c (sys/assym.h actually) is legal code. If Intel doesn't want to change icc, we can still work around it, but there may be other code that will break on icc just like assym.h. For example, an actual array of length 1 would mean you were screwed, since treating 1 as if it were 0 would treat that as zero, as well, and get the wrong answer. The real answer is that the code should probably use an array length of one, and then use the address of the array length 1 element, rather than the address of the object plus the size of the object, when it's trying to use the zero length array trick to glue data with the correct object alignment (according to the array type) onto the end of a structure, which is where most of this type of code comes from. Unfortunately, the genassym.sh is a special case; for it to work out if you changed the nature of the trick, the script would need to grow special knowledge of the symbols in question. That is probably going to be the answer in any case, if Intel is unwilling/unable to adopt the GCC-ism. Anecdote on unable: At one point in time SEF had to deal with a compiler issue with the Microsoft C compiler used by SCO; it took code like this: char *hw = Hello World!\n + 6; and generated a data segment missing the Hello . When the code later did this: printf( %s, hw - 6); It got the wrong answer. The problem was the MS compiler was unable to gerate a pseudo-symbol for the start of the data, and so had no way of taking the origina string, and allocating storage, with a static symbol offset +6 into the string. If Intel ICC makes an optimization based on pruning of actually zero-length element, or not aligning them to their type boundary, etc., it would take deep compiler voodoo to correct this. Hopefully, they do the right thing for []. -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Question about genassym, locore.s and 0-sizedarrays(showstopper for an icc compiled kernel)
On Fri, 5 Sep 2003, I wrote: ... If some values are unrepresentable then they need to be represtended using other values. E.g., add 1 to avoid 0, or multiply by the alignment size if some element of the tool chanin instsists on rounding up things chain insists for alignment like a broken aout version used to do. 16-bit values would need 17 bits to represent after adding 1. Better, add 0x1 to avoid 0. awk has no support for parsing hex numbers so subtracting the bias of 1 would take a lot more code, but ignoring leading hexdigits requires no changes in genassym.sh -- it already ignores everything except the last 4 hexdigits. Bruce ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Question about genassym, locore.s and 0-sizedarrays(showstopper for an icc compiled kernel)
On Fri, 05 Sep 2003 02:06:56 -0700
Terry Lambert [EMAIL PROTECTED] wrote:
Now try:
struct foo {
char c;
int i;
long array[];
};
struct foo foo;m
struct foo fee[1];
struct foo fie[3];
struct foo foe[0];
struct foo fum[1];
on both compilers. If they end up the same, then Intel needs to
change to using the 0. If they end up different, then they are
broken relative to the C99 standard and zero length arrays a final
elements in structures.
% icc -c terry.c
terry.c(8): warning #1229: type containing an unknown-size array may alias another
element
struct foo fee[1];
^
terry.c(9): warning #1229: type containing an unknown-size array may alias another
element
struct foo fie[3];
^
terry.c(10): warning #1229: type containing an unknown-size array may alias another
element
struct foo foe[0];
^
terry.c(11): warning #1229: type containing an unknown-size array may alias another
element
struct foo fum[1];
^
icc:
0008 C fee
0018 C fie
0008 C foe
0008 C foo
0008 C fum
gcc:
0008 C fee
0018 C fie
C foe
0008 C foo
0008 C fum
Bye,
Alexander.
--
Where do you think you're going today?
http://www.Leidinger.net Alexander @ Leidinger.net
GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
