This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug c++/11376] [3.3/3.4 regression] mozilla-1.4 miscompiled


PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11376



------- Additional Comments From bangerth at dealii dot org  2003-07-08 19:35 -------
I would like to posit one additional comment here that I hope you don't
take personal: When you say

> Finding these types of violations is extremely time consuming and
> it is hard to convince a non-impacted developer that his/her code is
> incorrect [...]
> Unfortunately, without some form of warning about when the
> optimization is used it is next to impossible to find and fix all
> of the occurrences.

I would like to disagree. You have certainly noticed that even those of
us who are well-trained in these questions tip-toed around the code and
dared not say whether it is legal or not until it was really down to
about one page. Rather than putting the blame on gcc, I would like to
put it on the original authors of the code. They chose a wicked code
design involving evil constructs such as casting to void** and using
reinterpret_cast. It is certainly not only my personal view that this
obfuscated the code to a degree that none of us could easily see what
was going on. It is not up to me to judge how this might affect the
mozilla developers community. However, I think there are more pressing
things to do in gcc than to invent ways to track the course pointers take
just to catch problems like this one. After all, it is not only time
consuming to track down such bugs, but also to implement tracking them
inside the compiler. 

Putting it somewhat bluntly (please take this with a grain of salt):
If you choose to shoot yourself in the foot, gcc shouldn't interfere.

W.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]