Building mysql 5.0.67 with gcc 4.2 and 4.3.2 produce okay results. Building on 4.3.3 20081210 (prerelease) and 4.4.0 20081212 (experimental) [trunk revision 142725] causes problems. Compiling with -O1 (instead of the default -O2) fixes the issue. At least one of the failures was reduced to sql/log_event.cc. Attaching log_event.cc and -O2 log_event.o from 4.3.2 and 4.4.0 20081212, and -O1 from 4.4.0 20081212 for now, until I can further isolate the problem.
Created attachment 16919 [details] mysql source file
Created attachment 16920 [details] obj file from -O2 gcc 4.3.2
Created attachment 16921 [details] obj file from -O2 gcc 4.4.0 20081212 (experimental) [trunk revision 142725]
Created attachment 16922 [details] obj file from -O2 gcc 4.4.0 20081212 (experimental) [trunk revision 142725]
Created attachment 16923 [details] obj file from -O2 gcc 4.3.2
Created attachment 16924 [details] obj file from -O1 gcc 4.4.0 20081212 (experimental) [trunk revision 142725]
Created attachment 16925 [details] 4.4.0 -E output of log_event.cc (bzip2) $ /usr/lib/gcc-snapshot/bin/g++ -DMYSQL_SERVER -DDEFAULT_MYSQL_HOME="\"/usr\"" -DDATADIR="\"/var/lib/mysql\"" -DSHAREDIR="\"/usr/share/mysql\"" -DHAVE_CONFIG_H -I. -I. -I../include -I../innobase/include -I../innobase/include -I../ndb/include -I../ndb/include -I../ndb/include/ndbapi -I../ndb/include/mgmapi -I../include -I../include -I../regex -I. -DDBUG_OFF -DBIG_JOINS=1 -felide-constructors -fno-rtti -O1 -fno-implicit-templates -fno-exceptions -fno-rtti -MT log_event.o -MD -MP -MF ".deps/log_event.Tpo" -E log_event.cc > /tmp/log_event.cc-E
Does compiling with -O2 -fno-strict-aliasing fix the issue. I thought I saw some aliasing violations in the source dealing with accessing a "char *" as a "Log_event::Byte*" (aka "unsigned char *"). Now what is only defined is the accessing anything by a char/unsigned char/signed char, accessing pointers via a different type is undefined. The function which I saw the issue is in copy_str_and_move where there are going to be accesses in those two types.
Yes! Adding "-fno-strict-aliasing" to a normal (-O2) build seems to have fixed the problems so far. The full test suite takes a while, but the early failures are not present any more. I will report more once it finishes. Thank you for the hint! Is this a regression in gcc, or is this something upstreams need to add to their builds when doing the char/pointer manipulations you described?
(In reply to comment #9) > Is this a regression in gcc, or is this something upstreams need to add to > their builds when doing the char/pointer manipulations you described? Most likely a bug in the mysql sources. Does compiling with -W -Wall produce any warnings (when compiling with just -O2)?
I do get a warning from the trunk though: log_event.cc: In member function 'virtual bool Query_log_event::write(IO_CACHE*)': log_event.cc:1124: warning: dereferencing pointer 'start.519' does break strict-aliasing rules log_event.cc:1217: note: initialized from here Which is exactly what I mentioned except it is a different place I was thinking of: write_str_with_code_and_len((char **)(&start), catalog, catalog_len, 6); Yes this is now becomes an obvious aliasing issue as you are a "unsigned char *" as a "char *" which violates C/C++ aliasing rules. Please report this bug to mysql.