gcc 3.4.3? -O2 is generally pretty safe. Your version of gcc sounds pretty old. I assume this isn't an issue with newer versions of gcc? ________________________________________ From: owner-bird-users@atrey.karlin.mff.cuni.cz [owner-bird-users@atrey.karlin.mff.cuni.cz] on behalf of Maksim Tamarsky [mtamarsky@nsg.net.ru] Sent: Thursday, January 10, 2013 9:47 AM To: bird-users@trubka.network.cz Subject: Re: BUG: /lib/lists.c.. Don`t use -O2 . Use -O1 I found that my trouble exists when compiling with -O2 option. In that case inline functions rem_node and add_head will merged into function (/nest/iface.c ifa_recalc_primary) and then will badly optimized by compiler, because the implicit use of pointers to the same data. If we call external function(like printf) between rem_node and add_head trouble gone away in any case. Now i use -O1. This works for 1.3.2 and 13.8. My compiler is: $ powerpc-nsg-linux-gcc -dumpversion 3.4.3 $ powerpc-nsg-linux-gcc -dumpmachine powerpc-nsg-linux -- RU: Тамарский Максим Александрович Инженер-программист ООО Эн-Эс-Джи г.Москва, Кирпичная 39/41 оф.1302 Почтовый адрес: 105187 Россия, Москва ул.Вольная, д.35, оф.NSG Тел./факс: +7 495 727-19-59 Web-сайт: http://www.nsg.ru EN: Maksim Tamarsky Software Engineer NSG Ltd. 35 Volnaya Street, 105187 Moscow, Russia +7 495 727-19-59 http://www.nsg.ru

On Thu, Jan 10, 2013 at 06:47:42PM +0400, Maksim Tamarsky wrote:

I found that my trouble exists when compiling with -O2 option. In that case inline functions rem_node and add_head will merged into function (/nest/iface.c ifa_recalc_primary) and then will badly optimized by compiler, because the implicit use of pointers to the same data. If we call external function(like printf) between rem_node and add_head trouble gone away in any case.

Now i use -O1. This works for 1.3.2 and 13.8.

Hello I thought that it might be something like that, but if i remember and understand correctly C language rules for pointer aliasing, then the code is OK, because although the memory is accessed through pointers to structures of two different types, the content is same (node ptr), so compiler cannot expect non-aliasing. So i would suppose it is a compiler bug, so workaround with -O1 is probably a good solution. There are probably some other potential pointer aliasing problems in BIRD (at least the ones that newer versions of GCC complainted) that should be addressed, but i think this one is OK. MJ, any comment on this list code and pointer aliasing? -- Elen sila lumenn' omentielvo Ondrej 'SanTiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."

Hello, On 01/10/2013 03:47 PM, Maksim Tamarsky wrote:

I found that my trouble exists when compiling with -O2 option. In that case inline functions rem_node and add_head will merged into function (/nest/iface.c ifa_recalc_primary) and then will badly optimized by compiler, because the implicit use of pointers to the same data. If we call external function(like printf) between rem_node and add_head trouble gone away in any case. Do you wanna say that adding a printf between rem_node and add_head makes bird run fine? I analysed the code generated for ARM with -O2 (see thread "bird6 1.3.7 hangs on start on a Raspberry Pi") and I cannot see anything wrong with the assembler code.

On the other hand, casting a pointer to the head member of a struct list to a node * is definitely broken. (This is done in add_head().) I'm pretty sure this code's behavior is undefined and so should be fixed. And I consider this to be more likely the cause of the bad behaviour that you, Fritz and Eric are seeing. Martin Mares already suggested an alternative implementation for doubly-linked lists. Another alternative is include/linux/lists.h from the Linux kernel. I guess an upside of the latter is that it is known to be working on several architectures. (But note I didn't even look at Martin's suggestion and so cannot really say how well it is tested.) Best regards Uwe