http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53779
--- Comment #1 from Andreas Schwab <sch...@linux-m68k.org> 2012-06-26 14:55:34 UTC --- Try running it under valgrind. Your patch is apparently causing a memory corruption, and the SIGABRT handler tries to call back into malloc/free, which cannot work. Most likely target_cost_data is freed twice. --- Comment #2 from David Edelsohn <dje at gcc dot gnu.org> 2012-06-26 14:56:32 UTC --- Alan and my patch was to libjava and did not change anything in the common support for atomics. Unless the build is using libjava at that point, there is no way for the libjava locks.h patch to affect this. This may be due to some indirect change in the process memory layout after Steven's change. But the real problem appears to libc free() crashing in a call from var-tracking. libc raises a signal, GCC catching it and tries to print a pretty error and cleanup before exiting. The cleanup calls free() again and hangs. Is there some memory problem in var-tracking or an underlying data structure that was exposed by Steven's change? Some weird page crossing or some dangling pointer that accidentally pointed to valid memory before the process layout changed?
