Hi, > It's similar to mine results. > GCC4 in C++ mode for sure uses more extensively strict aliasing > optimization. At least it was reporting more errors and warnings > for Harbour core code which was using casting ignoring aliasing > rules.
Maybe we should switch to C++ as default for mingw or gcc in general. mingw C++ build speed is about 15% slower, so that's the price. (maybe it's possible to achieve C++ optimization levels by some extra C compiler option? so g++ is not needed to reach the same effect) > BTW this ones are still reported: > > ../../../hb_btree.c: In function ‘ioOneBufferAlloc’: > ../../../hb_btree.c:275:3: warning: dereferencing type-punned pointer will > break strict-aliasing rules > > This seems to be also real bug which may cause GPF on some platforms but > I'm not familiar enough with this code to fix it myself. > > ../../../sddfb.c: In function ‘fbDisconnect’: > ../../../sddfb.c:181:4: warning: dereferencing type-punned pointer will break > strict-aliasing rules > ../../../sddfb.c: In function ‘fbOpen’: > ../../../sddfb.c:209:4: warning: dereferencing type-punned pointer will break > strict-aliasing rules > ../../../sddfb.c:219:4: warning: dereferencing type-punned pointer will break > strict-aliasing rules Strangely, these are not reported by mingw. > This is also danger casting though it should work if void * is large enough > to hold FB handlers. Anyhow it's potential problem so it should be fixed. Definitely. It's a long time problem with FB client interface that it uses ints for handles in 64-bit mode, but void pointers in 32-bit mode. Seems even current solution is not perfect to make them both work without warnings. See this in ibase.h: --- #if defined(_LP64) || defined(__LP64__) || defined(__arch64__) || defined(_WIN64) typedef unsigned int FB_API_HANDLE; #else typedef void* FB_API_HANDLE; #endif --- > BTW it would be good to check what GCC does when it detects such code or > even real problems (it can report also: "dereferencing pointer ... does > break strict-aliasing rules"). > Does it disable optimization or generates potentially wrong code. > > Can you compare C and C++ mode in MSVC too? With same methodology there is about 1% speed advantage for C++ mode. It seems consistent, but minor. The size different is also very minor, C++ being same or somewhat larger (by 0-0.1%, or +0-5KB in case of Harbour tools). Tested with MSVC 2008 (as part of Win SDK 7) BTW, mingw created noticeably larger executables, by about 1-6% (+20-100KB in case of Harbour tools). Brgds, Viktor _______________________________________________ Harbour mailing list (attachment size limit: 40KB) [email protected] http://lists.harbour-project.org/mailman/listinfo/harbour
