I use gcc 4.1.2 under solaris and linux and compile code using next commands: Linux: gcc -pipe -Wall -Wextra -Winvalid-pch -ansi -pedantic -Wundef -Wc++-compat -Wfloat-equal -Wredundant-decls -Waggregate-return -Wbad-function-cast -Wmissing-declarations -Wmissing-prototypes -Wstrict-prototypes -Wcast-align -Wshadow -Wsign-compare -Wnested-externs -Wcast-qual -Wpointer-arith -Wdeclaration-after-statement -Werror -O2 -finline-functions -Wdisabled-optimization -DNDEBUG test.c -o mtest_l Solaris: gcc -pipe -Wall -Wextra -Winvalid-pch -ansi -pedantic -Wundef -Wc++-compat -Wfloat-equal -Wredundant-decls -Waggregate-return -Wbad-function-cast -Wstrict-prototypes -Wcast-align -Wshadow -Wsign-compare -Wnested-externs -Wcast-qual -Wpointer-arith -Wdeclaration-after-statement -Werror -O2 -finline-functions -Wdisabled-optimization -DNDEBUG -g -o mtest test.c Segmentation fault happens when I try to run test program (see test.c attached).
Created attachment 14182 [details] test programm This example is compiled incorrectly by gcc 4.1.2 with -O2 flag. But all works fine if we change line 93 in this example on next: XML_Remove(currNode_sp);
Created attachment 14183 [details] Correct and incorrect assembler dumps. From incorrect dump we can see where segmentation fault heppens: 0x0804839e <testFunction+30>: mov DWORD PTR [ecx+4],0x0 0x080483a5 <testFunction+37>: mov DWORD PTR [eax+4],edx 0x080483a8 <testFunction+40>: mov edx,DWORD PTR [ecx+4] 0x080483ab <testFunction+43>: mov ecx,ebx 0x080483ad <testFunction+45>: mov DWORD PTR [edx],eax Instruction 0x080483ad tries to dereferencing pointer in edx, but in edx zero was put by 0x080483a8.
From the look at the source, it looks like you are violating C/C++ aliasing rules. Try with -fno-strict-aliasing.
There is no core dump with -fno-strict-aliasing. But, our code is used by others who can not set this option. Should code compiled without -fno-strict-aliasing produce core dump? In my opinion, the best way is produce only compiliation warnings in this case. Should we rewrite our code if it is not possible to set -fno-strict-aliasing option, or it is gcc issue that fixed in other versions?
This code is certainly undefined and violates all sorts of type correctness rules. In essence you write code that violates the language standards -- using -fno-strict-aliasing is only a workaround and you should fix your code. You may want to try to rewrite your code so that you don't need all those type casts. It isn't particularly hard to write a doubly-linked list without any type casts at all. W.
That code looks very similar to the doubly linked lists that AmigaOS exec.library uses. Just remove the XL and XLM prefixes from the names and it's the same. That code indeed plays nasty type casting tricks to reuse a NULL pointer in the list head, so as to save four bytes of memory. I guess aliasing violations were not a major concern when that code was written back in about 1985 or so. :-) Maybe the AROS project has revised code which survives alias analysis.