On 1 October 2014 08:09, Maxim Ostapenko <m.ostape...@partner.samsung.com> wrote: > Hi, > > some time ago, Andrew wrote a patch that fixes PR58867 > (http://patchwork.ozlabs.org/patch/286866/), but for some reasons it > wasn't committed to trunk. > > This is resurrected Andrew's patch, extended to support Tsan testsuite. > > Tested on x86_64-pc-linux-gnu, ok to commit? > > -Maxim
Hi, This patch results in wide spread failures in our bare metal test runs. I have not dug into the issue in detail but it appears that the issue is related to the attempted use of set_ld_library_path_env_vars and restore_ld_library_path_env_vars to save and restore nested contexts. Consider ubsan/ubsan.exp: load_lib gcc-dg.exp ... dg-init ubsan_init ... ubsan_finish The gcc-dg.exp library load calls set_ld_library_path_env_vars the first time an initializes GCC_EXEC_PREFIX. The ubsan_init call makes a further call to set_ld_library_path_env_vars which has no effect. The ubsan_finish invokes restore_ld_library_path_env_vars, restoring the environments as it was prior to the call to dg-init. Any further test execution has now lost the original initialization of GCC_EXEC_PREFIX by gcc-dg.exp It seems to me that either this patch assumes that the set/restore_ld_library_path_env foo is capable of maintaining a stack of saved contexts... which it is not. Prior to this patch ubsan_finish did not attempt to call restore_ld_library_path_env_vars hence the gcc-dg.exp environment remained in place for subsequent test executions. Cheers /Marcus