[Bug tree-optimization/44736] Overeager -O1 optimization results in incorrect code generation
--- Comment #4 from opensource3141 at gmail dot com 2010-07-01 16:52 --- (In reply to comment #3) > We are going to ask developers to use -fno-builtin-malloc for now. I also > think this is a glibc bug which should mark the hook variables volatile. I tested using the volatile keyword inside the glibc header malloc.h, and that also serves as a workaround. However, I believe the meaning of volatile is something a bit different, and using the qualifier would prevent GCC from optimizing accesses to the hook variables independent of calls to malloc. The fundamental issue seems to be that there is a mismatch between how malloc behaves and how GCC thinks it behaves. It sounds like the best way to resolve that mismatch is to use -fno-builtin-malloc, the main drawback being that the developer has to be consciously aware of this when building the code. Otherwise, there will be a nasty surprise. > So, can you file a bug in the glibc bugzilla as well? I have filed a bug there and referenced this one: http://sources.redhat.com/bugzilla/show_bug.cgi?id=11781 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44736
[Bug tree-optimization/44736] Overeager -O1 optimization results in incorrect code generation
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-07-01 08:20 --- (In reply to comment #2) > Thanks for the lightening fast response. I wouldn't have known to look there, > especially since older GCC versions did not have this problem. > > Is it because 4.5.0 has better optimizations such that the code surrounding > this malloc is now optimized away in this situation? > > Finally, is this issue going to be resolved within GCC, or is the permanent > fix > going to be to ask developers to use -fno-builtin-malloc? We are going to ask developers to use -fno-builtin-malloc for now. I also think this is a glibc bug which should mark the hook variables volatile. So, can you file a bug in the glibc bugzilla as well? > Thanks again. > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44736
[Bug tree-optimization/44736] Overeager -O1 optimization results in incorrect code generation
--- Comment #2 from opensource3141 at gmail dot com 2010-07-01 00:32 --- Thanks for the lightening fast response. I wouldn't have known to look there, especially since older GCC versions did not have this problem. Is it because 4.5.0 has better optimizations such that the code surrounding this malloc is now optimized away in this situation? Finally, is this issue going to be resolved within GCC, or is the permanent fix going to be to ask developers to use -fno-builtin-malloc? Thanks again. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44736
[Bug tree-optimization/44736] Overeager -O1 optimization results in incorrect code generation
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-06-30 23:42 --- Stupid glibc extensions. __malloc_hook and __free_hook are not part of standard C90/C99. -fno-builtin-malloc will disable this optimization. Basically malloc cannot touch global memory as far as the compiler knows so it optimizes out the extra stores. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|critical|normal Component|c |tree-optimization http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44736
