Re: What is wrong with Bugzilla? [Was: Re: GCC and Floating-Point]

[Haren Visavadia <themis_hv@yahoo.co.uk>]

--- Michael Veksler wrote:
> 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).

Sometimes it is difficult.

Exposing different visibility behaviors of the bug,
being filling in can save another person filing yet
another duplicate as they can maybe find it in their
search. 

Having different visibility behaviour of the bug being
put in Bugzilla is good IMHO.

> 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?

That's a problem with some of these GCC bugmasters (no
names mentioned) for classify them as not gcc bugs. I
have also been hit by similar problem but it got
fixed.

The toolchain packages are not always in sync. Getting
prerequisite for a toolchain is not that simple at
all.

Some of these problems can limit the usability of GCC,
ie toolchain problem preventing GCC to bootstrap or to
cause other errors.

> 
> 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 gcc@gcc.gnu.org.
>    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.

Yes, bugs in GDB are much 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&)'

Agreed, better error messages are definitely good idea
to make compiler useful. File that in as feature
enhancement PR (Severity set to enhancement).
























	
	
		
___________________________________________________________ 
Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail http://uk.messenger.yahoo.com