Haren Visavadia wrote on 29/05/2005 10:51:00:
>
> You can search Bugzilla as well, so you do not fill in
> duplicate bug report.
Unfortunately, this is not 100% correct. Recently I have filed several
duplicates, *after* searching Bugzilla.
1. There are too many ways to phrase a title, and too many
times I search for wrong words.
2. The same bug may have several different user
visible behaviors. You will end up with at least one
duplicate per user visible behavior.
At work, I maintain a bug database for my project and I
sometimes need to fire-up a debugger to find out that
a reported bug is a well known one.
Many times only a trained developer (in the project) can assert
that a PR is indeed a duplicate of another one.
3. Nontrivial search of GCC Bugzilla are, sometimes,
extremely slow (over a minute). This inhibits multiple
searches. I usually give up after the first one, and don't
bother with a different type of query (which could have
revealed a similar PR).
>
> As long as the bug report can be easily reproduced, it
> will probably not get made invalid.
>
Mostly true, but not always. Bugs will be normally marked
invalid when the bug is in other parts of the toolchnain, or
in the processor. This happens even when it is possible to
implement a work-around in gcc.
Two examples come in mind:
1. Non conformance of x86 to the standard FP due to
its extra precision. This includes different results
between -O2 and -O0 even with -fsave-temps.
Several PR about this issue were marked invalid in
the past.
This is a bug in two places:
i. x86 FP which implements wrong precision.
ii. glibc that claims in its headers that it sets to set
default precision to 64 bits, when in practice it
sets it to 80 bits.
Nevertheless, gcc can implement a work-around. The
PRs may have stayed open with a low priority, putting
the issue on a list of projects that someone may want
to pick up.
2. GDB crashes on AIX because a bug in either gcc, gdb,
or the native /bin/as. Every one of these tools points
fingers to the other direction. I tend to believe the bug
is in GDB
http://sources.redhat.com/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gdb&pr=1170
yet, the work-around in gcc is only 2 lines.
If GCC and GDB were one project instead of two, it is
possible that the work-around approach would be implemented.
But because GDB is a different project, and the fix is nontrivial [1]
it will probably be never fixed (unless AIX moves to dwarf).
Technically speaking, these are not GCC bugs. However, from
user's POV they *are* GCC bugs. This mismatch between user
and developer perceptions is not very healthy and may inhibit
other PRs. Maybe developers should be more open to "fixing"
things that are not purely GCC bugs?
Another thing that intimidates users is the complexity of
C and C++. Things that may look like bugs are not really
bugs:
1. Undefined (unspecified?) behavior due to aliasing rules.
2. Two stage name lookup in templates is confusing.
Because of that I will not report a bug related to templates,
before mailing a query to [EMAIL PROTECTED]
It is not only a "fault" of ISO C++, but also of gcc [2].
[1] The fix could be trivial, but I could not find it. Despite having no
time to learn neither GCC nor GDB source I was able to
1. Follow the bug from GDB crash back to GCC.
2. Find how to trivially "fix" it in GCC.
3. Yet I was unable to find how to fix GDB.
This leads me to believe that fixing GDB is more difficult.
[2] GCC could implement a better error message. An example
for a good report is:
$ cat t.cpp
int f() {
for (int i=0 ; i < 10 ; ++i)
{}
return i;
}
$ g++ t.cpp
t.cpp: In function 'int f()':
t.cpp:4: error: name lookup of 'i' changed for new ISO 'for' scoping
t.cpp:2: error: using obsolete binding at 'i'
A similar thing could be done for (probably nontrivial task)
$ cat t2.cpp
template <class T> struct A { T t; };
// Swap the follwing 2 functions to get valid C++
template <class T> void foo(const A<T>& data)
{ foo((int)data.t); }
void foo(int data);
Instead of today's uninformative error:
t2.cpp: In function `void foo(const A<T>&)':
t2.cpp:3: error: no matching function for call to `foo(int&)'
