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

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

[Uros Bizjak]

Hello Scott!

>I do know this: Many, many scientific and mathematical programmers find
>GCC frustrating and annoying, and most of those folk know far more about
>numbers than I do. I wish more of these people would feel comfortable
>posting to the GCC list, rather than sending private e-mails to my
>inbox.
>
At this point, I wonder what is wrong with Bugzilla, that those 
programmers don't fill a proper bug report. If there is a problem with 
GCC, that is so annoying to somebody, I think that at least developers 
could be informed about it via their standard channels of communication. 
If there is a specific problem, at least it can be analysed properly and 
perhaps some actions could be taken to fix it. If the problem is indeed 
_that_ big (usually, it is not!), then a workaround could be suggested - 
and this bug, together with a workaround is documented in bugzilla for 
others, until the problem is properly solved (usually with a testcase). 
I guess that these persons don't know that bugreports are extremmely 
important for the development of gcc. The users themself are actaully a 
QA department of open source development;)

There is no problem that Bugzilla is un-intuitive, it is far from that. 
The users don't fill bugreports because they are afraid of filling an 
invalid report or a duplicate. I can't speak for gcc bugmasters, but it 
looks to me that dupes and invalid reports are not that big problem.

Is perhaps some kind of anonymous account needed (as in Slashdot's case) 
to encourage these users to fill bugreports? Their knowledge of specific 
problems could help gcc to became better, so it indeed is a win-win 
situation.

>However, the atmosphere of GCC development is... well, let's just
>say that my investment in asbestos underware has not been wasted. ;)
>
I would call it an atmosphere of brainstorming. Different opinions and 
different point of views. The only problem is, that words can be 
different if people sit 3000 km/miles/whatever apart ;)

Uros.

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

[Scott Robert Ladd]

Uros Bizjak wrote:
> At this point, I wonder what is wrong with Bugzilla, that those 
> programmers don't fill a proper bug report.

In my experience, people don't file Bugzilla reports because it feels
impersonal and unresponsive. The form is not very user-friendly (as in
friendly to users of GCC, not its developers.)

I have some thoughts on GCC customer support that would likely help both
developers and users, but I need to get my ducks in a row before I start
them quacking.

> I guess that these persons don't know that bugreports are extremmely
>  important for the development of gcc. The users themself are
> actaully a QA department of open source development;)

Asking users to do QA makes for poor relationships and quality, whether
we're talking about proprietary or free software. Ask anyone who
purchased a game like Dungeon Lords... ;)

Now, you can argue that people's expectations are unrealistic, and I
will agree with you, but we all know that the ideal situation is
only rarely reflected in reality.

>> However, the atmosphere of GCC development is... well, let's just 
>> say that my investment in asbestos underware has not been wasted. 
>> ;)
>> 
> I would call it an atmosphere of brainstorming. Different opinions 
> and different point of views. The only problem is, that words can be
>  different if people sit 3000 km/miles/whatever apart ;)

Brainstorming there may be, but certain folk in the GCC community simply
like being annoying, perhaps to feed their own sense of self-importance.
It is quite possible to disagree with someone without be disagreeable,
as exemplified by Evandro Menezes recently.

..Scott

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

[Daniel Berlin]

On Sat, 2005-05-28 at 13:09 -0400, Scott Robert Ladd wrote:
> Uros Bizjak wrote:
> > At this point, I wonder what is wrong with Bugzilla, that those 
> > programmers don't fill a proper bug report.
> 
> In my experience, people don't file Bugzilla reports because it feels
> impersonal and unresponsive. The form is not very user-friendly (as in
> friendly to users of GCC, not its developers.)

I have a hard time believing this, considering they'd see the same form
reporting bugs anywhere else, too, and thus, are probably used to it.

They could also send random emails to gcc-bugs.

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

[William Beebe]

On 5/28/05, Scott Robert Ladd <scott.ladd@coyotegulch.com> wrote:

> Brainstorming there may be, but certain folk in the GCC community simply
> like being annoying, perhaps to feed their own sense of self-importance.
> It is quite possible to disagree with someone without be disagreeable,
> as exemplified by Evandro Menezes recently.
> 
> ..Scott

It's called polite constructive criticism. Unfortunately, the lack of
civility when offering important judgement isn't limited to this
newsgroup. For example, whenever I feel the temperature rising a bit
too high, I just wonder over to the lkml and lurk awhile until I
realize once more what wonderfully sainted individuals the gcc
developers are.

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

[Scott Robert Ladd]

William Beebe wrote:
> For example, whenever I feel the temperature rising a bit
> too high, I just wonder over to the lkml and lurk awhile until I
> realize once more what wonderfully sainted individuals the gcc
> developers are.

With the departure of Larry McVoy and BitKeeper, LKML is going to be
rather tame, I think. ;)

Probably wishful thinking, though. ;)

..Scott

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

[Kai Henningsen]

scott.ladd@coyotegulch.com (Scott Robert Ladd)  wrote on 28.05.05 in <4298A5B0.1020304@coyotegulch.com>:

> Uros Bizjak wrote:
> > At this point, I wonder what is wrong with Bugzilla, that those
> > programmers don't fill a proper bug report.
>
> In my experience, people don't file Bugzilla reports because it feels
> impersonal and unresponsive. The form is not very user-friendly (as in
> friendly to users of GCC, not its developers.)

This is pretty much incomprehensible to me (NOT a gcc developer, but a gcc  
user - that is, a programmer).

"Feels impersonal"? And this is supposed to be a *problem* with a bug  
reporting system?!

We're not talking about a trouble ticket system for a matchmaking agency  
here, are we? I certainly don't expect technology in general to feel  
personal. And in fact I thought the problem with the mailing lists *was*  
that they got too personal.

Unresponsive? I thought the whole point was to avoid responses (in the  
mailing list)?

Sorry, but this really does not make any sense to me.

As for the user friendlyness of the forms, well, all I can say is that  
they're certainly not optimal, but they're at least in the upper 30% of  
forms in general one encounters on the web - and that includes non- 
technical stuff. In fact, forms for non-technical stuff are usually  
especially bad - presumably because the authors have less understanding of  
the technology involved.

MfG Kai

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

[William Beebe]

On 29 May 2005 11:37:00 +0200, Kai Henningsen <kaih@khms.westfalen.de> wrote:
> scott.ladd@coyotegulch.com (Scott Robert Ladd)  wrote on 28.05.05 in 
> > In my experience, people don't file Bugzilla reports because it feels
> > impersonal and unresponsive. The form is not very user-friendly (as in
> > friendly to users of GCC, not its developers.)
> 
> This is pretty much incomprehensible to me (NOT a gcc developer, but a gcc
> user - that is, a programmer).
> 
> "Feels impersonal"? And this is supposed to be a *problem* with a bug
> reporting system?!
> 
> We're not talking about a trouble ticket system for a matchmaking agency
> here, are we? I certainly don't expect technology in general to feel
> personal. And in fact I thought the problem with the mailing lists *was*
> that they got too personal.
> 
> Unresponsive? I thought the whole point was to avoid responses (in the
> mailing list)?
> 
> Sorry, but this really does not make any sense to me.
> 
> As for the user friendlyness of the forms, well, all I can say is that
> they're certainly not optimal, but they're at least in the upper 30% of
> forms in general one encounters on the web - and that includes non-
> technical stuff. In fact, forms for non-technical stuff are usually
> especially bad - presumably because the authors have less understanding of
> the technology involved.
> 
> MfG Kai

OK, then let me explain it to you. The problem with the GCC Bugzilla
reporting system is that it's a system that only other developers can
tolerate, let alone love. The entire GCC website (of which GCC
Bugzilla is a part) could be the poster child for why developers
should never be allowed to design user interfaces, especially web user
interfaces. I'm sure I'll get flamed for wanting style over substance
or about the proliferation of eye candy, but the GCC web site and it's
attendent support pages can only be charitably described as eye trash.
Yes, you can find the bug link if you read the main page long enough
and move down the page slowly enough, or if, like me, you fire up
Firefox's find and use that to go quickly to the bug link. But that's
beside the point. At the very least the design of the GCC web site
makes the whole project look like someone who has just discovered the
web and decided to build a few pages. And please don't harp on making
it standards compliant and viewable by every browser in existance.
There are plenty of well-designed and excellent sites that follow
those same rules. You just need to be willing to put in the effort to
look a little more professional and polished. And just to stir the pot
further, a web site is an important marketing tool. It's the first
thing that a lot of people will see when they go looking for help. If
you want to have more people participate, then make the tools more
inviting.

Re: What is wrong with Bugzilla?

[Russ Allbery]

William Beebe <wbeebe@gmail.com> writes:

> OK, then let me explain it to you. The problem with the GCC Bugzilla
> reporting system is that it's a system that only other developers can
> tolerate, let alone love.

Setting aside for the moment that GCC is a software package *targetted* at
developers, and hence the above is not necessarily a serious problem, I
agree that the Bugzilla interface isn't exactly my favorite UI.  However,
I haven't figured out a better one either, so I don't have a firm platform
on which to stand and complain.

Bug reporting interfaces appear to be a hard problem.

> The entire GCC website (of which GCC Bugzilla is a part) could be the
> poster child for why developers should never be allowed to design user
> interfaces, especially web user interfaces.

Well, unless you have some user interface designers lined up and
volunteering to help, this isn't really the most useful thing to say.  GCC
is a volunteer project; it uses the labor that it has available.

> You just need to be willing to put in the effort to look a little more
> professional and polished.

The people maintaining the GCC web site put a great deal of effort into
it.  If there is a problem, lack of effort isn't the cause of it.

You seem to be arguing that the people maintaining the web site have the
wrong skill set to do a good job at it.  Personally, the site looks great
to me, but then I'm a developer, so... :)  However, this is all just noise
on a mailing list in the absence of someone with different ideas who is
willing to do the work, just as with any other part of GCC.

If you feel there is a better way to do the web site, propose patches,
volunteer to help maintain it, and demonstrate why it's better.  Just like
with the rest of GCC.  If you don't have time to do that, you could try to
convince someone else to do it, or you could pay someone to do it.  Just
like with the rest of GCC.  In the absence of such a contribution, you
(and the web site) are at the mercy of the people who *are* willing to put
the effort into it.

Personally, I think they're doing a great job.  But maybe I just have a
tin eye for web site design too -- it's certainly possible.  I'm not
prejudging your argument that the web site could be better, just saying
that saying so on the mailing list isn't going to do anything towards
changing it.

-- 
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>

Re: What is wrong with Bugzilla?

[William Beebe]

On 5/29/05, Russ Allbery <rra@stanford.edu> wrote:

> Setting aside for the moment that GCC is a software package *targetted* at
> developers, and hence the above is not necessarily a serious problem, I
> agree that the Bugzilla interface isn't exactly my favorite UI.  However,
> I haven't figured out a better one either, so I don't have a firm platform
> on which to stand and complain.
> 
> Bug reporting interfaces appear to be a hard problem.

Then I would like you to review and contrast GCC Bugzilla
(http://gcc.gnu.org/bugzilla) with at least two others: Mozilla's
(https://bugzilla.mozilla.org) and Redhat's
(https://bugzilla.redhat.com/bugzilla/index.cgi). Mozilla's is a bit
more organized than GCC's (but not much) and it is organized as a
two-column page with a resonably lucid, short and sweet explaination
on the right. It shares the same ant picture with GCC's, which makes
me wonder if that image isn't part of some core page that comes with
the Bugzilla package.

The best of the two is the Redhat page. Instead of lots of controls on
the page, it has one to start with (search for a bug), with the more
detailed (and powerful) options located at the top of the page as menu
items. It's also good in that it has both expository information on
the page as well as news that someone looking for bugs might want to
read. The only problem with the Redhat page is that its news section
is somewhat dated. And yes, I know that Redhat is a 'real' company and
that the designer(s) are probably paid. It would be interesting to ask
if Redhat could provide some gcc site support.

And if bugzilla is not working out, or if you want some ideas on how
to build better interfaces, there seem to be plenty of open bug
tracking packages on Sourceforge. A quick search for bugzilla produces
a nice long list, and at random I picked phpBugTracker
(http://phpbt.sourceforge.net).

> Well, unless you have some user interface designers lined up and
> volunteering to help, this isn't really the most useful thing to say.  GCC
> is a volunteer project; it uses the labor that it has available.

And I understand and appreciate that. But when the UI heavy hitters
aren't beating your doors down you either have to appeal to them in
the coummunity or else go and do what I do; look at what's out there
and (re)use design elements. I know that there's got to be somebody
out there doing good volunteer UI work. For example, I look at the
Savannah project (http://savannah.gnu.org) which is at the least
reasonably organized and easy to read. Then there's Fedora
(http://fedora.redhat.com) and Gentoo (http://www.gentoo.org). I'm
sure there're others.

As I mentioned before, have you thought to ask for help from Redhat?
If everybody looks to gcc as an important core tool, then perhaps
those power users could help with the site. I would say to go and talk
to Apple, that paragon of UI design, but I have no idea how Apple
would react or if it would be a complete waste of time and energy.

> > You just need to be willing to put in the effort to look a little more
> > professional and polished.
> 
> The people maintaining the GCC web site put a great deal of effort into
> it.  If there is a problem, lack of effort isn't the cause of it.

Maintenence is not design. And when that maintenence is the last thing
you do after everything else, it shows. What triggered this diatribe
was the apparent hard-core attitude that the GCC bugzilla (warts and
all) was the way it was and it was going to stay that way, so live
with it. You can't have that kind of an attitude with the site or the
tool.

You've pointed out the lack of bandwidth to improve it, and I am
sympathetic (believe me, I really am). However, if someone makes a
comment on the look and feel of the site then you should make the
diplomatic equivalent to the comment "do you have a patch" when
someone makes a comment about some "questionable" issue with the
compiler.

> You seem to be arguing that the people maintaining the web site have the
> wrong skill set to do a good job at it.  Personally, the site looks great
> to me, but then I'm a developer, so... :)  However, this is all just noise
> on a mailing list in the absence of someone with different ideas who is
> willing to do the work, just as with any other part of GCC.

The people do have the wrong skill set. And let me be the first to
tell you that when it comes to truly creative design, I suck. I would
certainly be willing to help someone who doesn't suck.

> If you feel there is a better way to do the web site, propose patches,
> volunteer to help maintain it, and demonstrate why it's better.  Just like
> with the rest of GCC.  If you don't have time to do that, you could try to
> convince someone else to do it, or you could pay someone to do it.  Just
> like with the rest of GCC.  In the absence of such a contribution, you
> (and the web site) are at the mercy of the people who *are* willing to put
> the effort into it.

OK. Let's see where we go with that thought.

> Personally, I think they're doing a great job.  But maybe I just have a
> tin eye for web site design too -- it's certainly possible.  I'm not
> prejudging your argument that the web site could be better, just saying
> that saying so on the mailing list isn't going to do anything towards
> changing it.

I think we all suffer from Tin Eye Site Design - TESD. But if we don't
bring this issue up here, then where should it be brought up?

Re: What is wrong with Bugzilla?

[Russ Allbery]

William Beebe <wbeebe@gmail.com> writes:

> Then I would like you to review and contrast GCC Bugzilla
> (http://gcc.gnu.org/bugzilla) with at least two others: Mozilla's
> (https://bugzilla.mozilla.org) and Redhat's
> (https://bugzilla.redhat.com/bugzilla/index.cgi). Mozilla's is a bit
> more organized than GCC's (but not much) and it is organized as a
> two-column page with a resonably lucid, short and sweet explaination on
> the right. It shares the same ant picture with GCC's, which makes me
> wonder if that image isn't part of some core page that comes with the
> Bugzilla package.

> The best of the two is the Redhat page.  Instead of lots of controls on
> the page, it has one to start with (search for a bug), with the more
> detailed (and powerful) options located at the top of the page as menu
> items. It's also good in that it has both expository information on the
> page as well as news that someone looking for bugs might want to read.

The Red Hat page is prettier, and I guess the GCC page could use some more
orientation information, but they all feel roughly equal to me.  (I
actually prefer seeing clear links in the text of the page to the menu
thing that Red Hat is doing.)  But as previously mentioned, I'm not really
the person you want reviewing this, most likely.

> And if bugzilla is not working out, or if you want some ideas on how to
> build better interfaces, there seem to be plenty of open bug tracking
> packages on Sourceforge. A quick search for bugzilla produces a nice
> long list, and at random I picked phpBugTracker
> (http://phpbt.sourceforge.net).

Well, the amount of work required to change bug tracking systems or build
a new interface on top of Bugzilla is significant; if you're not planning
on doing that work or paying someone to do it, it's fairly unlikely there
will be any resources to do it.  So far as I know, Bugzilla is working out
fairly well from the perspective of the people working on GCC, which while
not the whole story is at least as important as the bug reporting
interface.

> And I understand and appreciate that. But when the UI heavy hitters
> aren't beating your doors down you either have to appeal to them in
> the coummunity or else go and do what I do; look at what's out there
> and (re)use design elements.

Well, I don't *have* to do anything.  GCC works great for what I want.
But I think I understand what you're saying.

GCC is using Bugzilla because someone not only got fed up with GNATS but
volunteered to do all the work required to make the switch and keep things
running afterwards.

> As I mentioned before, have you thought to ask for help from Redhat?  If
> everybody looks to gcc as an important core tool, then perhaps those
> power users could help with the site. I would say to go and talk to
> Apple, that paragon of UI design, but I have no idea how Apple would
> react or if it would be a complete waste of time and energy.

There are Red Hat and Apple folks on this list.  Maybe you can convince
them to take such an idea to their companies.  I have no idea.  Whatever
is done, it's very important that it be maintainable five years down the
road.  That's where single efforts often fail.

> You've pointed out the lack of bandwidth to improve it, and I am
> sympathetic (believe me, I really am). However, if someone makes a
> comment on the look and feel of the site then you should make the
> diplomatic equivalent to the comment "do you have a patch" when someone
> makes a comment about some "questionable" issue with the compiler.

I would generally agree, and that's basically what I'm trying to do here.
However, it's also useful to point out to someone with a specific
complaint how hard fixing that complaint might be.  For example, if the
report is "I want to link GCC as a library into my new IDE," people aren't
going to just say "do you have a patch" without explaining why that's
going to be hard to do.  :)

> I think we all suffer from Tin Eye Site Design - TESD. But if we don't
> bring this issue up here, then where should it be brought up?

I'm not saying this is the wrong place to bring it up.  It's the only
place to bring it up, so far as I know.  I just think it's one of those
things that can't really be discussed well in negatives.  I really
appreciated your links above to the other sites that you think are better
laid-out; that's positive and presenting a particular improvement that can
then be discussed.  In general, though, I think it's going to take someone
mocking something up and saying "here, I think this is better, what do
other people think?"

-- 
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>

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

[Kai Henningsen]

wbeebe@gmail.com (William Beebe)  wrote on 29.05.05 in <e0716e9f05052910475b5fc0fc@mail.gmail.com>:

> On 29 May 2005 11:37:00 +0200, Kai Henningsen <kaih@khms.westfalen.de>
> > wrote: scott.ladd@coyotegulch.com (Scott Robert Ladd)  wrote on 28.05.05
> > > in In my experience, people don't file Bugzilla reports because it feels
> > > impersonal and unresponsive. The form is not very user-friendly (as in
> > > friendly to users of GCC, not its developers.)
> >
> > This is pretty much incomprehensible to me (NOT a gcc developer, but a gcc
> > user - that is, a programmer).

[...]

> OK, then let me explain it to you. The problem with the GCC Bugzilla
> reporting system is that it's a system that only other developers can
> tolerate, let alone love.

But then, users of GCC typically *are* developers themselves, no?

>The entire GCC website (of which GCC
> Bugzilla is a part) could be the poster child for why developers
> should never be allowed to design user interfaces, especially web user
> interfaces. I'm sure I'll get flamed for wanting style over substance
> or about the proliferation of eye candy, but the GCC web site and it's

... which I think are poster childs why non-technical people *usually*  
ought not to be allowed to design web sites.

> attendent support pages can only be charitably described as eye trash.
> Yes, you can find the bug link if you read the main page long enough
> and move down the page slowly enough, or if, like me, you fire up
> Firefox's find and use that to go quickly to the bug link. But that's
> beside the point. At the very least the design of the GCC web site
> makes the whole project look like someone who has just discovered the
> web and decided to build a few pages. And please don't harp on making

To me, it looks *very* professional.

> it standards compliant and viewable by every browser in existance.
> There are plenty of well-designed and excellent sites that follow
> those same rules. You just need to be willing to put in the effort to
> look a little more professional and polished. And just to stir the pot

<shrug> that effort has pretty obviously been put in.

> further, a web site is an important marketing tool. It's the first
> thing that a lot of people will see when they go looking for help. If
> you want to have more people participate, then make the tools more
> inviting.

I think you're pretty much off by 180 degrees.

MfG Kai

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

[chris jefferson]

Kai Henningsen wrote:

>>The entire GCC website (of which GCC
>>Bugzilla is a part) could be the poster child for why developers
>>should never be allowed to design user interfaces, especially web user
>>interfaces. I'm sure I'll get flamed for wanting style over substance
>>or about the proliferation of eye candy, but the GCC web site and it's
>>    
>>
>
>... which I think are poster childs why non-technical people *usually*  
>ought not to be allowed to design web sites.
>
>  
>
>>attendent support pages can only be charitably described as eye trash.
>>Yes, you can find the bug link if you read the main page long enough
>>and move down the page slowly enough, or if, like me, you fire up
>>Firefox's find and use that to go quickly to the bug link. But that's
>>beside the point. At the very least the design of the GCC web site
>>makes the whole project look like someone who has just discovered the
>>web and decided to build a few pages. And please don't harp on making
>>    
>>
>
>To me, it looks *very* professional.
>
>  
>
I'm sorry, but I felt I couldn't leave this comment alone. The main GCC 
page is badly designed. The logo looks very amateurish, and also try 
exploring the page without actual knowledge. I just tried this. I 
suspect most people on their first visit are here because they want a 
copy of gcc, and it's perhaps reasonable to assume at this point they 
don't know a huge amount, and perhaps don't want to compile from source 
(if they had a copy of gcc, they wouldn't be here :). Yes, I know and 
you know it's not gcc's job to provide that, but I'd look for a copy of 
gcc by typing "gcc" into google, and gcc.gnu.org is where you get to first)

Lets try to get a copy of gcc. Firstly I see something in the top-left 
marked "releases". I click on it. It doesn't mention 4.0, and despite 
reasonable attempts I see no sign of code. Next I see a mention of 4.0.0 
in the main body. After wandering around that link for quite a while I 
find a link to the mirrors page, which is full of source.

Next try documentation, installation. Talks about compiling again. 
Finally, at download, binaries I find what I want. Seeing as I suspect 
that is the link most people want when they first visit, it should 
perhaps be a little more obvious, and in the main body near the top?

Chris

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

[Gary Funck]

> 
> Next try documentation, installation. Talks about compiling again. 
> Finally, at download, binaries I find what I want. Seeing as I suspect 
> that is the link most people want when they first visit, it should 
> perhaps be a little more obvious, and in the main body near the top?

Your scenario makes a lot of sense.  However, it should be possible to
verify actual usage patterns by investigating web site logs, to see which
pages are visited and (perhaps) in what order.  Based upon this information,
the pages can be re-organized to place first, and most prominent, the pages
that are generally visited first.

Sub-question: which version would the maintainers recommend that a user
looking for a stable release try first (3.3, 3.4, or 4.0)?

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

[Paul Brook]

> Lets try to get a copy of gcc. Firstly I see something in the top-left
> marked "releases". I click on it. It doesn't mention 4.0, 

Fair point. This needs fixing.

> and despite reasonable attempts I see no sign of code. 

Huh? The first paragraph on that page is
"Source code for GCC releases may be downloaded from our <mirror sites>"

The following paragraph clearly states that this is source code, and link to 
the page with binaries on. It even says "Important:".

Furthermore the title of that section is "Download"

I don't see how you could possibly have missed this.

Paul

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

[Daniel Berlin]

> > MfG Kai
> 
> OK, then let me explain it to you. The problem with the GCC Bugzilla
> reporting system is that it's a system that only other developers can
> tolerate, let alone love. 

You probably feel this way about all Bugzilla's then, since they are all
the same except for the really large ones.
Right?
However, if there is some you'd rather see us emulate, please let me
know what it is.
> The entire GCC website (of which GCC
> Bugzilla is a part) could be the poster child for why developers
> should never be allowed to design user interfaces, especially web user
> interfaces. 

You've forgotten that as a non-ui expert, I set my goals low when
dealing with bugzilla forms, because I knew i wasn't a UI expert

The main design goal of gcc bugzilla's forms were

1. Not be as horrible as GNATSweb to enter bugs
2. Not be as horrible as GNATSweb to search for bugs
3. Not be as horrible as GNATSweb to generate reports

In these respects, it's a rousing success! :)

Our forms match bugzilla's default forms except where for where we
replaced or changed a small number of fields.

As such, they don't have the customization that
KDE/GNOME/RedHat/whoever's bugzilla forms you like (if you like any
Bugzilla's at all).

There are currently some UI hackathons going on in Bugzilla world to
make the forms nicer to look at and use, but Bugzilla is not my primary
job.

As such, I keep up to date in what's going on in bugzilla world, keep
our code merged with the latest bugzilla cvs (This can be seen on
http://www.dberlin.org/bugzilla-cvs. We haven't had a stellar reason to
upgrade to the 2.20 series yet, so i haven't bothered).  
When developers or users tell me they need/want things, i do those
things, assuming their is some consensus (or it's non-controversial).

So the main reason the forms suck is because nobody has ever told me
what to do to make them not suck!

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

[Vincent Lefevre]

On 2005-05-28 17:17:32 +0200, Uros Bizjak wrote:
> At this point, I wonder what is wrong with Bugzilla, that those 
> programmers don't fill a proper bug report. If there is a problem with 
> GCC, that is so annoying to somebody, I think that at least developers 
> could be informed about it via their standard channels of communication.

Perhaps because GCC developers think that GCC isn't buggy when the
processor doesn't do the job for them? (I'm thinking of bug 323.)

-- 
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / SPACES project at LORIA

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

[Giovanni Bajo]

Vincent Lefevre <vincent+gcc@vinc17.org> wrote:

>> At this point, I wonder what is wrong with Bugzilla, that those
>> programmers don't fill a proper bug report. If there is a problem
>> with GCC, that is so annoying to somebody, I think that at least
>> developers could be informed about it via their standard channels of
>> communication.
>
> Perhaps because GCC developers think that GCC isn't buggy when the
> processor doesn't do the job for them? (I'm thinking of bug 323.)


You are mistaken, we think GCC isn't buggy about 323 because the C/C++
standards do not tell us to do better than this. If you have higher
expectations about floating point and C/C++, you should file a bugreport
against the C/C++ standards.

Really, we can't make everybody happy. The best we can do is to adhere the
international well-known ISO/ANSI standards.

Giovanni Bajo

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

[Michael Veksler]

"Giovanni Bajo wrote on 29/05/2005 13:54:39:

> Vincent Lefevre <vincent+gcc@vinc17.org> wrote:
>
> > Perhaps because GCC developers think that GCC isn't buggy when the
> > processor doesn't do the job for them? (I'm thinking of bug 323.)
>
>
> You are mistaken, we think GCC isn't buggy about 323 because the C/C++
> standards do not tell us to do better than this. If you have higher
> expectations about floating point and C/C++, you should file a bugreport
> against the C/C++ standards.
>

If more than 50 people report it, independently,  as a bug then it sure is
a bug.
You might argue whether technically it is a bug, but from user's
perspective
it is a bug (and you have over 50 duplicates as an evidence). As such it
has
to be dealt with more positively.

I also think that it is also a bug from the technical angle. As far as I
know,
there is an IEEE standard that dictates things like rounding. I don't have
it
in front of me now, but as I remember it refers mostly to CPU's floating
point unit. So if the CPU does not meet the standard, GCC can say that
it is a bug in the CPU.

The standpoint that it's a bug in the CPU is unproductive. It would help
the users if GCC were trying to hide IEEE nonconformance as much
as possible. Things such as
 assert( a / b == a / b);
should not fail according to IEEE (as far as I remember). Even if
it were not stated by IEEE to be wrong, GCC should consider it wrong,
at least from the rule of least surprise.

An even more surprising example can be created:
   #include <assert.h>
   volatile float x=3;
   int main()
   {
     float a = 1/x;
     x = a;
     assert(a == x); // -O2 will fail on gcc-3.4.3 and gcc-4.0.0
   }

I think that you can't deny it is a bug. Copying a variable of the
same type should not change its value (regardless of  what ==
generally means in FP context).

> Really, we can't make everybody happy. The best we can do is to adhere
the
> international well-known ISO/ANSI standards.
>
And what about the IEEE ? What about the above example, does it adhere
to ISO/ANSI ?
This FP issue is quite subjective and everyone seems to have a different
opinion. Some people even claim that -ffast-math should be default.
There is no "right" solution here, only *a set* of useful solutions.
As such (50 duplicates means it's useful!), bug 323 should have been
dealt with years ago.

I know that before bug 323 is handled, I will not file FP bug reports,
because I'll assume that it will be probably marked as a duplicate
of 323 anyway. Luckily, I am able to avoid FP most of the time
(at the cost of uglifying and slowing down parts of my code).
I don't know how many people are like me, but I guess that I am
not alone.

    Michael

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

[Vincent Lefevre]

On 2005-05-29 18:19:19 +0300, Michael Veksler wrote:
> If more than 50 people report it, independently, as a bug then it
> sure is a bug. You might argue whether technically it is a bug, but
> from user's perspective it is a bug (and you have over 50 duplicates
> as an evidence). As such it has to be dealt with more positively.

Concerning the extended precision, there are two problems.

First there is a bug in GCC concerning casts and assignments
(see ISO/IEC 9899: 5.1.2.3#13, 6.3.1.5#2 and 6.3.1.8#2).

But even this were fixed, many users would still complain.
That's why I think that the Linux kernel should set the CPU
in double-precision mode, like some other OS's (MS Windows,
*BSD) -- but this is off-topic here. I've written a web page
about that:

  http://www.vinc17.org/research/extended.en.html

> I also think that it is also a bug from the technical angle. As far
> as I know, there is an IEEE standard that dictates things like
> rounding. I don't have it in front of me now, but as I remember it
> refers mostly to CPU's floating point unit. So if the CPU does not
> meet the standard, GCC can say that it is a bug in the CPU.

The IEEE-754 standard allows extended precision, even though the
C type is double precision. The term used by the IEEE-754 standard
is "destination", but doesn't specify what the "destination" is.
It may be a floating-point register.

> The standpoint that it's a bug in the CPU is unproductive. It would
> help the users if GCC were trying to hide IEEE nonconformance as
> much as possible. Things such as

I agree that GCC should try to hide IEEE non-conformance (but
x86 CPUs are conforming IEEE-754 implementations, modulo some
particular bugs).

>  assert( a / b == a / b);
> should not fail according to IEEE (as far as I remember).

According to IEEE, it may fail, for various reasons. In particular
because the IEEE-754 standard does not have language bindings.

Also note that a CPU may have two floating-point units, one
conventional in extended precision and one in double precision
(e.g. SSE2), and they could be used in parallel (this was an
example by Fred J. Tydeman on the stds-754 list).

But if you do,

  double x = a / b;
  double y = a / b;
  double z = a / b;

at least two of x, y, z should be equal if the processor supports
the IEEE-754 standard, even with any extended precision internally.

> An even more surprising example can be created:
>    #include <assert.h>
>    volatile float x=3;
>    int main()
>    {
>      float a = 1/x;
>      x = a;
>      assert(a == x); // -O2 will fail on gcc-3.4.3 and gcc-4.0.0
>    }

Yes, this is the bug in GCC I was talking about (the one concerning
the assignments).

> I think that you can't deny it is a bug. Copying a variable of the
> same type should not change its value (regardless of what ==
> generally means in FP context).

Yes.

-- 
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / SPACES project at LORIA

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

[Daniel Berlin]

On Sun, 2005-05-29 at 18:19 +0300, Michael Veksler wrote:
> 
> 
> 
> 
> 
> "Giovanni Bajo wrote on 29/05/2005 13:54:39:
> 
> > Vincent Lefevre <vincent+gcc@vinc17.org> wrote:
> >
> > > Perhaps because GCC developers think that GCC isn't buggy when the
> > > processor doesn't do the job for them? (I'm thinking of bug 323.)
> >
> >
> > You are mistaken, we think GCC isn't buggy about 323 because the C/C++
> > standards do not tell us to do better than this. If you have higher
> > expectations about floating point and C/C++, you should file a bugreport
> > against the C/C++ standards.
> >
> 
> If more than 50 people report it, independently,  as a bug then it sure is
> a bug.

Which is why it's still open!
Whoops, you forgot that part didn't you :)

The problem with 323 isn't that we don't think it's really a bug, it's
that nobody has any plans to implement a fix for it other than "use SSE
math or a different arch".

--Dan

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

[Vincent Lefevre]

On 2005-05-29 23:59:39 -0400, Daniel Berlin wrote:
> On Sun, 2005-05-29 at 18:19 +0300, Michael Veksler wrote:
> > If more than 50 people report it, independently, as a bug then it
> > sure is a bug.
> 
> Which is why it's still open!

It isn't (it was marked as INVALID).

> The problem with 323 isn't that we don't think it's really a bug,

In this case, it shouldn't have been marked as INVALID.

-- 
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / SPACES project at LORIA

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

[Toon Moene]

Vincent Lefevre wrote:

> On 2005-05-29 18:19:19 +0300, Michael Veksler wrote:
> 
>>If more than 50 people report it, independently, as a bug then it
>>sure is a bug. You might argue whether technically it is a bug, but
>>from user's perspective it is a bug (and you have over 50 duplicates
>>as an evidence). As such it has to be dealt with more positively.

> Concerning the extended precision, there are two problems.
> 
> First there is a bug in GCC concerning casts and assignments
> (see ISO/IEC 9899: 5.1.2.3#13, 6.3.1.5#2 and 6.3.1.8#2).
> 
> But even this were fixed, many users would still complain.
> That's why I think that the Linux kernel should set the CPU
> in double-precision mode, like some other OS's (MS Windows,
> *BSD) -- but this is off-topic here.

It's not off-topic.  In fact, Jim Wilson argued this point here:

http://gcc.gnu.org/ml/gcc/2003-08/msg01282.html

"The best pragmatic solution is probably to set the rounding control to 
64-bits, but then we lose access to long double which some people need, 
and we still have excess precision problems for float."

Hope this helps,

-- 
Toon Moene - e-mail: toon@moene.indiv.nluug.nl - phone: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
A maintainer of GNU Fortran 95: http://gcc.gnu.org/fortran/
News on GNU Fortran 95: http://gfortran.org/

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

[Robert Dewar]

Toon Moene wrote:

>> But even this were fixed, many users would still complain.
>> That's why I think that the Linux kernel should set the CPU
>> in double-precision mode, like some other OS's (MS Windows,
>> *BSD) -- but this is off-topic here.
> 
> It's not off-topic.  In fact, Jim Wilson argued this point here:
> 
> http://gcc.gnu.org/ml/gcc/2003-08/msg01282.html

There are good arguments on either side of this issue. If you set
double precision mode, then you get more predictable precision
(though range is still unpredictable), at the expense of not being
able to make use of extended precision (there are many algorithms
which can take very effective advantage of extended precision (e.g.
you can use log/exp to compute x**y if you have extended precision
but not otherwise).

Given that there are good arguments on both sides for what the
default should be, I see no good argument for changing the
default, which will cause even more confusion, since programs
that work now will suddenly stop working.

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

[Laurent GUERBY]

On Mon, 2005-05-30 at 23:10 -0400, Robert Dewar wrote:
> Toon Moene wrote:
> 
> >> But even this were fixed, many users would still complain.
> >> That's why I think that the Linux kernel should set the CPU
> >> in double-precision mode, like some other OS's (MS Windows,
> >> *BSD) -- but this is off-topic here.
> > 
> > It's not off-topic.  In fact, Jim Wilson argued this point here:
> > 
> > http://gcc.gnu.org/ml/gcc/2003-08/msg01282.html
> 
> There are good arguments on either side of this issue. If you set
> double precision mode, then you get more predictable precision
> (though range is still unpredictable), at the expense of not being
> able to make use of extended precision (there are many algorithms
> which can take very effective advantage of extended precision (e.g.
> you can use log/exp to compute x**y if you have extended precision
> but not otherwise).

Such algorithm usually require a very detailed control of what's going
on at the machine level, given current high level programming languages
that means using assembler. Also, I don't remember but I believe
user code is able to change the default when needed, so knowlegeable
users should still be able to do what's necessary (set and restore the
state), albeit may be with a loss of processing performance.

I also assume it's nearly impossible to get FP algorithms (eg: relying
on FP equality) working with the currently (broken) compilers that
operate in extended precision, but it's much easier when
FPU mode is set to round to 64 bits.

> Given that there are good arguments on both sides for what the
> default should be, I see no good argument for changing the
> default, which will cause even more confusion, since programs
> that work now will suddenly stop working.

Or that many programs that currently work on many OS
will start to work the same under Linux instead of
giving strange (and may be wrong) results.

Laurent

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

[Robert Dewar]

Laurent GUERBY wrote:

> Such algorithm usually require a very detailed control of what's going
> on at the machine level, given current high level programming languages
> that means using assembler.

No, that's not true, you might want to look at some of Jim Demmel's
work in this area.


> Or that many programs that currently work on many OS
> will start to work the same under Linux instead of
> giving strange (and may be wrong) results.

But many programs that work fine on the x86 now will start
breaking.
> 
> Laurent

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

[Vincent Lefevre]

On 2005-06-06 19:23:06 -0400, Robert Dewar wrote:
> Laurent GUERBY wrote:
> 
> >Such algorithm usually require a very detailed control of what's
> >going on at the machine level, given current high level programming
> >languages that means using assembler.
> 
> No, that's not true, you might want to look at some of Jim Demmel's
> work in this area.

Do you have a reference (URL...)?

> >Or that many programs that currently work on many OS
> >will start to work the same under Linux instead of
> >giving strange (and may be wrong) results.
> 
> But many programs that work fine on the x86 now will start breaking.
                                          ^^^

Linux/x86 only! And probably not many programs, and only programs
specific to x86. Their authors could still change the rounding
precision at the beginning of their programs if need be.

-- 
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / SPACES project at LORIA

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

[Vincent Lefevre]

On 2005-05-30 22:18:14 +0200, Toon Moene wrote:
> Vincent Lefevre wrote:
[...]
> >First there is a bug in GCC concerning casts and assignments
> >(see ISO/IEC 9899: 5.1.2.3#13, 6.3.1.5#2 and 6.3.1.8#2).
> >
> >But even this were fixed, many users would still complain.
> >That's why I think that the Linux kernel should set the CPU
> >in double-precision mode, like some other OS's (MS Windows,
> >*BSD) -- but this is off-topic here.
> 
> It's not off-topic.  In fact, Jim Wilson argued this point here:
> 
> http://gcc.gnu.org/ml/gcc/2003-08/msg01282.html
> 
> "The best pragmatic solution is probably to set the rounding control
> to 64-bits,

[double precision -- 64-bits isn't correct since it's the sign +
53-bit mantissa + extended exponent range internally]

Will gcc do that?

This isn't up to the user himself to do that.

> but then we lose access to long double which some people need, 
> and we still have excess precision problems for float."

But as I said on my page, this isn't much a problem since users
who really need *extended* precision can still set the rounding
precision to extended precision; this isn't portable, but extended
precision isn't portable anyway.

-- 
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / SPACES project at LORIA

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

[Andreas Schwab]

Vincent Lefevre <vincent+gcc@vinc17.org> writes:

> But as I said on my page, this isn't much a problem since users
> who really need *extended* precision can still set the rounding
> precision to extended precision; this isn't portable, but extended
> precision isn't portable anyway.

What about LDBL_* from <float.h>?

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

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

[Vincent Lefevre]

On 2005-05-31 14:27:01 +0200, Andreas Schwab wrote:
> Vincent Lefevre <vincent+gcc@vinc17.org> writes:
> > But as I said on my page, this isn't much a problem since users
> > who really need *extended* precision can still set the rounding
> > precision to extended precision; this isn't portable, but extended
> > precision isn't portable anyway.
> 
> What about LDBL_* from <float.h>?

What do you mean here?

-- 
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / SPACES project at LORIA

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

[Andreas Schwab]

Vincent Lefevre <vincent+gcc@vinc17.org> writes:

> On 2005-05-31 14:27:01 +0200, Andreas Schwab wrote:
>> Vincent Lefevre <vincent+gcc@vinc17.org> writes:
>> > But as I said on my page, this isn't much a problem since users
>> > who really need *extended* precision can still set the rounding
>> > precision to extended precision; this isn't portable, but extended
>> > precision isn't portable anyway.
>> 
>> What about LDBL_* from <float.h>?
>
> What do you mean here?

They give you access to long double in a portable manner, but if you
change the rounding mode then the constants are no longer accurate.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

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

[Vincent Lefevre]

On 2005-05-31 15:33:48 +0200, Andreas Schwab wrote:
> Vincent Lefevre <vincent+gcc@vinc17.org> writes:
> > On 2005-05-31 14:27:01 +0200, Andreas Schwab wrote:
> >> Vincent Lefevre <vincent+gcc@vinc17.org> writes:
> >> > But as I said on my page, this isn't much a problem since users
> >> > who really need *extended* precision can still set the rounding
> >> > precision to extended precision; this isn't portable, but extended
> >> > precision isn't portable anyway.
> >> 
> >> What about LDBL_* from <float.h>?
> >
> > What do you mean here?
> 
> They give you access to long double in a portable manner,

No, this is not portable, since if extended precision is necessary to
get correct results for some application, the same application run on
PowerPC, where there is no extended precision, would give incorrect
results.

> but if you change the rounding mode then the constants are no longer
> accurate.

The implementation could provide another way to get the necessary
information; perhaps nextafterl()...

-- 
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / SPACES project at LORIA

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

[Andreas Schwab]

Vincent Lefevre <vincent+gcc@vinc17.org> writes:

> On 2005-05-31 15:33:48 +0200, Andreas Schwab wrote:
>> Vincent Lefevre <vincent+gcc@vinc17.org> writes:
>> > On 2005-05-31 14:27:01 +0200, Andreas Schwab wrote:
>> >> Vincent Lefevre <vincent+gcc@vinc17.org> writes:
>> >> > But as I said on my page, this isn't much a problem since users
>> >> > who really need *extended* precision can still set the rounding
>> >> > precision to extended precision; this isn't portable, but extended
>> >> > precision isn't portable anyway.
>> >> 
>> >> What about LDBL_* from <float.h>?
>> >
>> > What do you mean here?
>> 
>> They give you access to long double in a portable manner,
>
> No, this is not portable,

Sure they are, since they are required since C89.

> since if extended precision is necessary to get correct results for some
> application, the same application run on PowerPC, where there is no
> extended precision, would give incorrect results.

You can use <float.h> to find that out.  That's what portability is about.

>> but if you change the rounding mode then the constants are no longer
>> accurate.
>
> The implementation could provide another way to get the necessary
> information; perhaps nextafterl()...

But you still have to take care of (1.0 + LDBL_EPSILON) != 1.0, or the
other required identities in <float.h>.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

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

[Scott Robert Ladd]

Andreas Schwab wrote:
>> No, this is not portable,
> 
> Sure they are, since they are required since C89.
> 
> You can use <float.h> to find that out.  That's what portability is
> about.

"Portability" means different things to different people. There's a
difference between source code portability and "result" portability.

If you follow Standard C, you are guaranteed source code portability, in
the program compiles and produce the "same" results with any Standard C
compiler.

When we start talking about floating-point code, however, we enter the
realm of "result" portability, in that different platforms (or different
compiler swicthes) return slightly different numbers from the same
source code.

An example of this is the use of long double, the implementation of
which differs from platform to platform. On Intel-inspired processors, a
long double is 80 bits long with a 64-bit mantissa, corresponding to the
x87 registers. On other systems, long double may be the same as double,
having 64 bits and a 53-bit mantissa. Calculations with 80-bit long
doubles will differ from the same computations performed using 64-bit
long doubles.

C does not enforce identical results on all platforms; Java does (or at
least tries to).

It's an easy problem to get tripped by, as I recently experienced on
this forum.

..Scott

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

[Andreas Schwab]

Scott Robert Ladd <scott.ladd@coyotegulch.com> writes:

> Andreas Schwab wrote:
>>> No, this is not portable,
>> 
>> Sure they are, since they are required since C89.
>> 
>> You can use <float.h> to find that out.  That's what portability is
>> about.
>
> "Portability" means different things to different people. There's a
> difference between source code portability and "result" portability.

But making round to double the default makes it only worse in this case,
since there is no portable way to change the rounding precision.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

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

[Vincent Lefevre]

On 2005-05-31 17:10:58 +0200, Andreas Schwab wrote:
> Scott Robert Ladd <scott.ladd@coyotegulch.com> writes:
> > "Portability" means different things to different people. There's a
> > difference between source code portability and "result" portability.
> 
> But making round to double the default makes it only worse in this case,
> since there is no portable way to change the rounding precision.

No, if the goal is to be portable with various platforms, you need
to round to double by default, since single precision (almost no
longer used for FP computations) and double precision are the only
standard precisions in IEEE 754.

-- 
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / SPACES project at LORIA

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

[Jakub Jelinek]

On Tue, May 31, 2005 at 07:20:49PM +0200, Vincent Lefevre wrote:
> On 2005-05-31 17:10:58 +0200, Andreas Schwab wrote:
> > Scott Robert Ladd <scott.ladd@coyotegulch.com> writes:
> > > "Portability" means different things to different people. There's a
> > > difference between source code portability and "result" portability.
> > 
> > But making round to double the default makes it only worse in this case,
> > since there is no portable way to change the rounding precision.
> 
> No, if the goal is to be portable with various platforms, you need
> to round to double by default, since single precision (almost no
> longer used for FP computations) and double precision are the only
> standard precisions in IEEE 754.

IEEE 754 is not mandated by the ISO C{90,99} standards and there are indeed
platforms where float and double are not using IEEE 754 single resp. double
precision formats.

	Jakub

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

[Vincent Lefevre]

On 2005-05-31 19:30:48 +0200, Jakub Jelinek wrote:
> IEEE 754 is not mandated by the ISO C{90,99} standards and there are indeed
> platforms where float and double are not using IEEE 754 single resp. double
> precision formats.

But without IEEE-754 support, the ISO C99 standard is just a big joke
concerning floating point: almost nothing is guaranteed. And yes,
I know that there are platforms without IEEE-754 support, where a
multiplication by 1.0 may yield an overflow...

-- 
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / SPACES project at LORIA

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

[Vincent Lefevre]

On 2005-05-31 10:30:52 -0400, Scott Robert Ladd wrote:
> If you follow Standard C, you are guaranteed source code portability, in
> the program compiles and produce the "same" results with any Standard C
> compiler.
> 
> When we start talking about floating-point code, however, we enter the
> realm of "result" portability, in that different platforms (or different
> compiler swicthes) return slightly different numbers from the same
> source code.

This is not much different from integer arithmetic. Standard types
such as int may have different sizes on different platforms.

-- 
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / SPACES project at LORIA

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

[Vincent Lefevre]

On 2005-05-31 16:07:53 +0200, Andreas Schwab wrote:
> Vincent Lefevre <vincent+gcc@vinc17.org> writes:
> 
> > On 2005-05-31 15:33:48 +0200, Andreas Schwab wrote:
> >> Vincent Lefevre <vincent+gcc@vinc17.org> writes:
> >> > On 2005-05-31 14:27:01 +0200, Andreas Schwab wrote:
> >> >> Vincent Lefevre <vincent+gcc@vinc17.org> writes:
> >> >> > But as I said on my page, this isn't much a problem since users
> >> >> > who really need *extended* precision can still set the rounding
> >> >> > precision to extended precision; this isn't portable, but extended
> >> >> > precision isn't portable anyway.
> >> >> 
> >> >> What about LDBL_* from <float.h>?
> >> >
> >> > What do you mean here?
> >> 
> >> They give you access to long double in a portable manner,
> >
> > No, this is not portable,
> 
> Sure they are, since they are required since C89.

The "long double" type is required, but it is not required to be
extended precision.

> > since if extended precision is necessary to get correct results
> > for some application, the same application run on PowerPC, where
> > there is no extended precision, would give incorrect results.
> 
> You can use <float.h> to find that out. That's what portability is
> about.

No, this is not sufficient.

> >> but if you change the rounding mode then the constants are no longer
> >> accurate.
> >
> > The implementation could provide another way to get the necessary
> > information; perhaps nextafterl()...
> 
> But you still have to take care of (1.0 + LDBL_EPSILON) != 1.0, or the
> other required identities in <float.h>.

Once you change the rounding precision, this is no longer required,
since you are already working with an extension.

-- 
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / SPACES project at LORIA

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

[Andreas Schwab]

Vincent Lefevre <vincent+gcc@vinc17.org> writes:

> The "long double" type is required, but it is not required to be
> extended precision.

But it can be.

> Once you change the rounding precision, this is no longer required,
> since you are already working with an extension.

The use of long double is not an extension.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

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

[Vincent Lefevre]

On 2005-05-31 21:16:19 +0200, Andreas Schwab wrote:
> Vincent Lefevre <vincent+gcc@vinc17.org> writes:
> > The "long double" type is required, but it is not required to be
> > extended precision.
> 
> But it can be.

So what?

> > Once you change the rounding precision, this is no longer required,
> > since you are already working with an extension.
> 
> The use of long double is not an extension.

Changing the rounding precision is. The C standard defines how you
can change the rounding direction, but not the rounding precision.

-- 
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / SPACES project at LORIA

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

[Vincent Lefevre]

On 2005-06-01 00:58:25 +0200, Andreas Schwab wrote:
> You are mistaken.

No, I don't see any problem.

> #include <assert.h>
> #include <float.h>
> 
> long double one = 1.0;
> long double one_plus_eps;
> 
> int
> main (void)
> {
>   long double one_plus_eps;
> 
>   one_plus_eps = one + LDBL_EPSILON;
>   assert (one != one_plus_eps);
>   return 0;
> }

I don't know how the standard should be interpreted (see below), but
if your program fails, this means that either your program is buggy
or the C implemention is buggy.

The standard says for LDBL_EPSILON: "the difference between 1 and the
least value greater than 1 that is representable in the given floating
point type, b^(1-p)".

One may decide that p = 64. The processor will round to double
precision, but that's OK since the C standard doesn't require
correct rounding (the accuracy is implementation-defined, as
said in #4). Your program will fail because it is not portable:
you made some assumptions about the accuracy.

One may decide that p = 53. I think this is better. Your program
will work (unless LDBL_EPSILON has a value assuming that p = 64,
but this would mean that your C implementation is buggy).

-- 
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / SPACES project at LORIA

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

[Andreas Schwab]

Vincent Lefevre <vincent+gcc@vinc17.org> writes:

> On 2005-06-01 00:58:25 +0200, Andreas Schwab wrote:
>> #include <assert.h>
>> #include <float.h>
>> 
>> long double one = 1.0;
>> long double one_plus_eps;
>> 
>> int
>> main (void)
>> {
>>   long double one_plus_eps;
>> 
>>   one_plus_eps = one + LDBL_EPSILON;
>>   assert (one != one_plus_eps);
>>   return 0;
>> }
>
> I don't know how the standard should be interpreted (see below), but
> if your program fails, this means that either your program is buggy
> or the C implemention is buggy.

This works fine with a non-broken implementation which claims IEC 60559
compliance.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

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

[Mike Stump]

On Tuesday, May 31, 2005, at 06:43  AM, Vincent Lefevre wrote:
> No, this is not portable, since if extended precision is necessary to
> get correct results for some application, the same application run on
> PowerPC, where there is no extended precision

?  News to me!  Ok, who removed it?  Speak up now, or we're going to 
send the firing squad.

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

[Dave Korn]

----Original Message----
>From: Mike Stump
>Sent: 31 May 2005 17:57

> On Tuesday, May 31, 2005, at 06:43  AM, Vincent Lefevre wrote:
>> No, this is not portable, since if extended precision is necessary to
>> get correct results for some application, the same application run on
>> PowerPC, where there is no extended precision
> 
> ?  News to me!  Ok, who removed it?  

  It fell off and dropped down the back of the sofa!  There's always lots of
bits down there!

> Speak up now, or we're going to send the firing squad.

  Just don't let them use x87 intrinsics to calculate the line of fire, or
we'd all better run!


    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....

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

[Marcin Dalecki]

On 2005-05-31, at 19:14, Dave Korn wrote:
>
>> Speak up now, or we're going to send the firing squad.
>>
>
>   Just don't let them use x87 intrinsics to calculate the line of  
> fire, or
> we'd all better run!

Some remarkable time ago I was exposed to a 12 bit "RISC" CPU with  
two banks
of 4k ferrite core memory... We where able to hit with the precision  
of about
half a meter, yes just meters not km, from a distance of 45km!
No no there where no laser guided "funnies" involved just pure boring  
ari.

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

[Vincent Lefevre]

On 2005-05-31 09:56:31 -0700, Mike Stump wrote:
> On Tuesday, May 31, 2005, at 06:43  AM, Vincent Lefevre wrote:
> >No, this is not portable, since if extended precision is necessary to
> >get correct results for some application, the same application run on
> >PowerPC, where there is no extended precision
> 
> ?  News to me!  Ok, who removed it?  Speak up now, or we're going to 
> send the firing squad.

Well, there is no extended precision with GCC under Linux/PPC.
And according to

http://developer.apple.com/documentation/mac/PPCNumerics/PPCNumerics-14.html

(found with Google), the PowerPC doesn't have hardware support
for extended precision.

-- 
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / SPACES project at LORIA

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

[Mike Stump]

On May 31, 2005, at 10:25 AM, Vincent Lefevre wrote:
> Well, there is no extended precision with GCC under Linux/PPC.

Hum, I do wonder about even that; why do:

2004-02-07  Alan Modra  <amodra@bigpond.net.au>

         * config/rs6000/t-linux64 (LIB2FUNCS_EXTRA): Add darwin- 
ldouble.c.

powerpc64-*-linux*)
         tm_file="${tm_file} dbxelf.h elfos.h svr4.h freebsd-spec.h  
rs6000/sysv4.h"
         test x$with_cpu != x || cpu_is_64bit=yes
         test x$cpu_is_64bit != xyes || tm_file="${tm_file} rs6000/ 
default64.h"
         tm_file="rs6000/biarch64.h ${tm_file} rs6000/linux64.h"
         extra_options="${extra_options} rs6000/sysv4.opt rs6000/ 
linux64.opt"
         tmake_file="rs6000/t-fprules ${tmake_file} rs6000/t-ppccomm  
rs6000/t-linux64"

t-linux64:

LIB2FUNCS_EXTRA = tramp.S $(srcdir)/config/rs6000/ppc64-fp.c \
         $(srcdir)/config/rs6000/darwin-ldouble.c

darwin-ldouble.c:
/* 128-bit long double support routines for Darwin.

then?  Certainly, the intent was to push it closer to working.  I  
don't see why someone could not finish off the compiler bits fairly  
quickly, if they wanted to.

> And according to
> http://developer.apple.com/documentation/mac/PPCNumerics/ 
> PPCNumerics-14.html
> (found with Google), the PowerPC doesn't have hardware support
> for extended precision.

I don't see the relevance, not to the question of can long double be  
used under linux, nor even can long double be used under OSX, nor  
long double on ppc.

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

[Vincent Lefevre]

On 2005-05-31 11:39:39 -0700, Mike Stump wrote:
> On May 31, 2005, at 10:25 AM, Vincent Lefevre wrote:
> >Well, there is no extended precision with GCC under Linux/PPC.
> 
> Hum, I do wonder about even that; why do:
> 
> 2004-02-07  Alan Modra  <amodra@bigpond.net.au>
> 
>         * config/rs6000/t-linux64 (LIB2FUNCS_EXTRA): Add darwin- 
> ldouble.c.
> 
> powerpc64-*-linux*)

Hmm... this is powerpc64. Under the 32-bit version, there's no
extended precision.

> >And according to
> >http://developer.apple.com/documentation/mac/PPCNumerics/ 
> >PPCNumerics-14.html
> >(found with Google), the PowerPC doesn't have hardware support
> >for extended precision.
> 
> I don't see the relevance, not to the question of can long double be  
> used under linux, nor even can long double be used under OSX, nor  
> long double on ppc.

This just explains why there's no extended precision on Linux/ppc.
You can use long double, but if you want to be portable enough,
your program must not require extended precision.

-- 
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / SPACES project at LORIA

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

[Alan Modra]

On Tue, May 31, 2005 at 09:53:05PM +0200, Vincent Lefevre wrote:
> On 2005-05-31 11:39:39 -0700, Mike Stump wrote:
> > On May 31, 2005, at 10:25 AM, Vincent Lefevre wrote:
> > >Well, there is no extended precision with GCC under Linux/PPC.
> > 
> > Hum, I do wonder about even that; why do:
> > 
> > 2004-02-07  Alan Modra  <amodra@bigpond.net.au>
> > 
> >         * config/rs6000/t-linux64 (LIB2FUNCS_EXTRA): Add darwin- 
> > ldouble.c.
> > 
> > powerpc64-*-linux*)
> 
> Hmm... this is powerpc64.

Yes.  powerpc64-linux uses IBM extended precision long doubles.

> Under the 32-bit version, there's no extended precision.

No.  powerpc-linux has 128-bit IEEE soft-float long double.

$ cat > fadd.c <<\EOF
long double fadd (long double a, long double b) { return a + b; }
EOF
$ gcc -m32 -mlong-double-128 -c fadd.c
$ nm fadd.o
00000000 T fadd
         U _q_add

Now all you need is a library that supplies _q_add and similar.  Let's
see, glibc is a likely place..

./sysdeps/powerpc/soft-fp/Makefile:powerpc-quad-routines := q_add q_cmp q_cmpe q_div q_dtoq q_feq q_fge \
./sysdeps/powerpc/soft-fp/Versions:    _q_add; _q_cmp; _q_cmpe; _q_div; _q_dtoq; _q_feq; _q_fge; _q_fgt;
./sysdeps/powerpc/soft-fp/q_add.c:long double _q_add(const long double a, const long double b)

Then of course, you need to convince glibc to build them for you.

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

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

[Vincent Lefevre]

On 2005-06-01 15:29:37 +0930, Alan Modra wrote:
> On Tue, May 31, 2005 at 09:53:05PM +0200, Vincent Lefevre wrote:
> > Under the 32-bit version, there's no extended precision.
> 
> No.  powerpc-linux has 128-bit IEEE soft-float long double.
> 
> $ cat > fadd.c <<\EOF
> long double fadd (long double a, long double b) { return a + b; }
> EOF
> $ gcc -m32 -mlong-double-128 -c fadd.c

But that's not the default and you'll have problems when linking with
existing libraries on the machine, that use a 64-bit long double...

-- 
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / SPACES project at LORIA

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

[Mike Stump]

On Wednesday, June 1, 2005, at 12:21  AM, Vincent Lefevre wrote:
> But that's not the default and you'll have problems when linking with
> existing libraries on the machine, that use a 64-bit long double...

Fine, we'll make it the default and recompile all your libraries for 
you...  give me a second while I hack into your machine....

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

[Daniel Berlin]

On Wed, 2005-06-01 at 10:26 -0700, Mike Stump wrote:
> On Wednesday, June 1, 2005, at 12:21  AM, Vincent Lefevre wrote:
> > But that's not the default and you'll have problems when linking with
> > existing libraries on the machine, that use a 64-bit long double...
> 
> Fine, we'll make it the default and recompile all your libraries for 
> you...  give me a second while I hack into your machine....
> 

Mike says sarcastically, as if this isn't what tiger did :)

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

[Mike Stump]

On Wednesday, June 1, 2005, at 11:01  AM, Daniel Berlin wrote:
> Mike says sarcastically, as if this isn't what tiger did :)

Someday, get me drunk and ask me how hard abi compatibility is.  :-(  I 
hate how we did it, and I hate that it was necessary.  I hate that 
bools on darwin are 4 bytes, because _Bool is 4 bytes, and once set, is 
set in stone.

Maybe in the future we'll have so much CPU and disk space and RAM that 
we can dispense with hard, inflexible abis...  I''m gonna go off and 
hold my breath now...


Oh, and we already bought into a fixed libstdc++.dylib, so there's lots 
more fun and magic awaiting us.

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

[Joseph S. Myers]

On Sun, 29 May 2005, Giovanni Bajo wrote:

> You are mistaken, we think GCC isn't buggy about 323 because the C/C++
> standards do not tell us to do better than this. If you have higher
> expectations about floating point and C/C++, you should file a bugreport
> against the C/C++ standards.

This is ignoring that there are specific requirements in the C99 standard 
regarding the handling of excess precision which we do not implement, even 
with -ffloat-store, which are genuine bugs.  Assignment, casts and 
function call and return must discard excess precision, but we do not 
discard excess precision on a cast of an expression to its own type.  
Furthermore, the definition of FLT_EVAL_METHOD for i386

#define TARGET_FLT_EVAL_METHOD \
  (TARGET_MIX_SSE_I387 ? -1 : TARGET_SSE_MATH ? 0 : 2)

is wrong when it is 2 because the way the i386 back end pretends to have 
float and double (not just long double) 387 operations means that 
precision may get randomly reduced if an intermediate value is spilled (so 
-1, not 2, is correct).  It is also incorrect because it is an assertion 
about both arithmetic and evaluation of constants and we do not emulate 
excess precision when evaluating constants and doing arithmetic on them.

Many of the issues reported in 323 or duplicates may be problems of user 
expectations or problems that -ffloat-store fixes, but there are still 
these subsets which are genuine bugs.

-- 
Joseph S. Myers               http://www.srcf.ucam.org/~jsm28/gcc/
    jsm@polyomino.org.uk (personal mail)
    joseph@codesourcery.com (CodeSourcery mail)
    jsm28@gcc.gnu.org (Bugzilla assignments and CCs)

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

[Haren Visavadia]

--- "Joseph S. Myers" wrote:

> On Sun, 29 May 2005, Giovanni Bajo wrote:
> 
> > You are mistaken, we think GCC isn't buggy about
> 323 because the C/C++
> > standards do not tell us to do better than this.
> If you have higher
> > expectations about floating point and C/C++, you
> should file a bugreport
> > against the C/C++ standards.
> 
> This is ignoring that there are specific
> requirements in the C99 standard 
> regarding the handling of excess precision which we
> do not implement, even 
> with -ffloat-store, which are genuine bugs. 
> Assignment, casts and 
> function call and return must discard excess
> precision, but we do not 
> discard excess precision on a cast of an expression
> to its own type.  
> Furthermore, the definition of FLT_EVAL_METHOD for
> i386
> 
> #define TARGET_FLT_EVAL_METHOD \
>   (TARGET_MIX_SSE_I387 ? -1 : TARGET_SSE_MATH ? 0 :
> 2)
> 
> is wrong when it is 2 because the way the i386 back
> end pretends to have 
> float and double (not just long double) 387
> operations means that 
> precision may get randomly reduced if an
> intermediate value is spilled (so 
> -1, not 2, is correct).  It is also incorrect
> because it is an assertion 
> about both arithmetic and evaluation of constants
> and we do not emulate 
> excess precision when evaluating constants and doing
> arithmetic on them.
> 

This makes it *bad* compiler claiming it implements a
standard when does not.

Giovanni Bajo stop telling lies about what GCC
implements.








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

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

[Daniel Berlin]

On Sun, 2005-05-29 at 00:52 +0200, Vincent Lefevre wrote:
> On 2005-05-28 17:17:32 +0200, Uros Bizjak wrote:
> > At this point, I wonder what is wrong with Bugzilla, that those 
> > programmers don't fill a proper bug report. If there is a problem with 
> > GCC, that is so annoying to somebody, I think that at least developers 
> > could be informed about it via their standard channels of communication.
> 
> Perhaps because GCC developers think that GCC isn't buggy when the
> processor doesn't do the job for them? (I'm thinking of bug 323.)
> 

I don't believe people feel it's not buggy, it's just that nobody has
plans to fix this.  This is in line with the defaults of other
compilers, as well.

Let's take a duplicate of 323, 21809


Compiling the code there with icc gives us:

dberlin@linux:~> icc icca.c
icca.c(7): warning #1572: floating-point equality and inequality
comparisons are unreliable
    assert(a == x);
    ^

./dberlin@linux:~> ./a.out
a.out: icca.c:7: main: Assertion `a == x' failed.
Aborted

In order to get icc to not generate an executable that will abort, you
have to pass special flags (the same way we have -ffloat-store, except I
believe their -mp flag will just disable any optimization that could get
in the way of this working).

One of these flag options is to tell it to use processor specific
instructions, which auto turns on the equivalent of -mfpmath=sse.

Maybe if the compiler from the people who made the processor didn't do
what we did, we'd be more concerned.  Maybe not.  But it certainly
doesn't slant in favor of the vocal (what appears to be) minority to
change the way we default, etc, when everyone else seems to have come to
the same decision independently.

--Dan

PS i found this humorous for some reason:

      call      __intel_proc_init                             #4.1
        flds      _2il0floatpacket.1                            #5.17
        fdivs     x                                             #5.17
        fsts      x                                             #6.3
        fcomps    x                                             #7.3
        fnstsw    %ax                                           #7.3
        sahf                                                    #7.3
        jne       ..B1.3        # Prob 42%                      #7.3
                                # LOE ebx esi edi
..B1.2:                         # Preds ..B1.1
        xorl      %eax, %eax                                    #8.1
        movl      %ebp, %esp                                    #8.1
        popl      %ebp                                          #8.1
        ret                                                     #8.1
                                # LOE
..B1.3:                         # Preds ..B1.1
        push      $__STRING.2                                   #7.3
        push      $7                                            #7.3
        push      $__STRING.1                                   #7.3
        push      $__STRING.0                                   #7.3
        call      __assert_fail                                 #7.3
                                # LOE
..B1.6:                         # Preds ..B1.3


Apparently they estimate the probability of a == x succeeding at 42% for
some reason (This is true at all opts levels, with and without SSE
math). Why this isn't 50%, who knows.

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

[Vincent Lefevre]

On 2005-05-30 00:31:44 -0400, Daniel Berlin wrote:
[http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21809]
> Compiling the code there with icc gives us:
> 
> dberlin@linux:~> icc icca.c
> icca.c(7): warning #1572: floating-point equality and inequality
> comparisons are unreliable
>     assert(a == x);
>     ^

icc is not a good example concerning the warnings. I've been told
that it issues too many annoying warnings, not just related to FP.

> ./dberlin@linux:~> ./a.out
> a.out: icca.c:7: main: Assertion `a == x' failed.
> Aborted

Here, according to the C standard (even if IEEE-754 isn't supported),
the code shouldn't fail.

-- 
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / SPACES project at LORIA

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

[Haren Visavadia]

--- Daniel Berlin wrote:
> 
> Let's take a duplicate of 323, 21809
> 
> 
> Compiling the code there with icc gives us:
> 
> dberlin@linux:~> icc icca.c
> icca.c(7): warning #1572: floating-point equality
> and inequality
> comparisons are unreliable
>     assert(a == x);
>     ^
> 
> ./dberlin@linux:~> ./a.out
> a.out: icca.c:7: main: Assertion `a == x' failed.
> Aborted
> 
> In order to get icc to not generate an executable
> that will abort, you
> have to pass special flags (the same way we have
> -ffloat-store, except I
> believe their -mp flag will just disable any
> optimization that could get
> in the way of this working).
> 
> One of these flag options is to tell it to use
> processor specific
> instructions, which auto turns on the equivalent of
> -mfpmath=sse.
> 

Here is another case for you try out:

test.c:
#include <assert.h>
#include <stdio.h>

volatile float x = 3;

int main()
{
	float a = 1 / x;
	x = a;
	assert(a == x);
	printf("a has value of %g \n",a);
	printf("x has value of %g  \n",x);
	assert((int)a == 0);
	assert((int)x == 0);
	return 0;
}


Compile this gcc {-O0,-O1,-O2,-O3,-Os}

You will notice it will always works  (despite not
using  -ffloat-store) and not cause an assertion
failure at all.

























		
___________________________________________________________ 
How much free photo storage do you get? Store your holiday 
snaps for FREE with Yahoo! Photos http://uk.photos.yahoo.com

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

[Robert Dewar]

Haren Visavadia wrote:

> test.c:
> #include <assert.h>
> #include <stdio.h>
> 
> volatile float x = 3;
> 
> int main()
> {
> 	float a = 1 / x;
> 	x = a;
> 	assert(a == x);
> 	printf("a has value of %g \n",a);
> 	printf("x has value of %g  \n",x);
> 	assert((int)a == 0);
> 	assert((int)x == 0);
> 	return 0;
> }
> 
> 
> Compile this gcc {-O0,-O1,-O2,-O3,-Os}
> 
> You will notice it will always works  (despite not
> using  -ffloat-store) and not cause an assertion
> failure at all.

And so? Why would you expect this particular example
to give an assertion error. I would not expect an
assert error here. In unoptimized mode, you certainly
do not expect it, and in optimized mode, I would
expect the register tracker to know that a and x are
in the same register at the point of assertion (and
perhaps even eliminate the comparison entirely).

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

[Haren Visavadia]

--- Robert Dewar wrote:
> And so? Why would you expect this particular example
> to give an assertion error. I would not expect an
> assert error here. In unoptimized mode, you
> certainly
> do not expect it, and in optimized mode, I would
> expect the register tracker to know that a and x are
> in the same register at the point of assertion (and
> perhaps even eliminate the comparison entirely).
> 

The previous posted case only adds few new lines of
insignificant line of code from:


test-case.c:
#include <assert,h>
volatile float x = 3;
int main()
{
float a = 1 / x;
x = a;
assert(a == x);
}


to

test.c:
#include <assert.h>
#include <stdio.h>

volatile float x = 3;

int main()
{
	float a = 1 / x;
	x = a;
	assert(a == x);
	printf("a has value of %g \n",a);
	printf("x has value of %g  \n",x);
	assert((int)a == 0);
	assert((int)x == 0);
	return 0;
}


I would expect the seem behaviour for both cases.

test-case.c cause an assertion failure with
{-O1,-O2,-O3} but test.c does not all.

The first few lines of both case are pretty simalar.














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

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

[Robert Dewar]

Haren Visavadia wrote:
> --- Robert Dewar wrote:

> I would expect the seem behaviour for both cases.

why? You have some inaccurate model of computation,
which in the absence of switches, is not guaranteed.
Floating-point semantics are indeed tricky.
> 
> test-case.c cause an assertion failure with
> {-O1,-O2,-O3} but test.c does not all.
> 
> The first few lines of both case are pretty simalar.

pretty similar does not mean guaranteed identical
behavior.

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

[Haren Visavadia]

--- Robert Dewar wrote:
> Haren Visavadia wrote:
> > --- Robert Dewar wrote:
> 
> > I would expect the seem behaviour for both cases.
> 
> why? You have some inaccurate model of computation,
> which in the absence of switches, is not guaranteed.
> Floating-point semantics are indeed tricky.

Why are extra switches added onto the test.c and not
test-case.c?






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

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

[Robert Dewar]

Haren Visavadia wrote:
> --- Robert Dewar wrote:
> 
>>Haren Visavadia wrote:
>>
>>>--- Robert Dewar wrote:
>>
>>>I would expect the seem behaviour for both cases.
>>
>>why? You have some inaccurate model of computation,
>>which in the absence of switches, is not guaranteed.
>>Floating-point semantics are indeed tricky.
> 
> 
> Why are extra switches added onto the test.c and not
> test-case.c?

I assume you mean why is an extra switch needed in
one case and not the other? Well the answer is that
the optimization that causes extra precision for
one of the operands applies in one case and not the
other. It is often tricky to know exactly what the
effects of optimization are.

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

[Vincent Lefevre]

On 2005-05-30 16:12:07 -0400, Robert Dewar wrote:
> Haren Visavadia wrote:
> >--- Robert Dewar wrote:
> 
> >I would expect the seem behaviour for both cases.
> 
> why? You have some inaccurate model of computation,
> which in the absence of switches, is not guaranteed.
> Floating-point semantics are indeed tricky.

According to 5.1.2.3#13, 6.3.1.5#2 and 6.3.1.8#2, the assert should
not fail (unless the division yields a NaN, but that would be a very
bad implementation anyway).

-- 
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / SPACES project at LORIA

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

[Andrew Haley]

Vincent Lefevre writes:
 > On 2005-05-30 16:12:07 -0400, Robert Dewar wrote:
 > > Haren Visavadia wrote:
 > > >--- Robert Dewar wrote:
 > > 
 > > >I would expect the seem behaviour for both cases.
 > > 
 > > why? You have some inaccurate model of computation,
 > > which in the absence of switches, is not guaranteed.
 > > Floating-point semantics are indeed tricky.
 > 
 > According to 5.1.2.3#13, 6.3.1.5#2 and 6.3.1.8#2, the assert should
 > not fail (unless the division yields a NaN, but that would be a very
 > bad implementation anyway).

I have read the sections you mention, and I cannot see how they imply
what you write.  Can you explain, please?

Andrew.
  

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

[Vincent Lefevre]

On 2005-05-31 13:16:55 +0100, Andrew Haley wrote:
> Vincent Lefevre writes:
>  > According to 5.1.2.3#13, 6.3.1.5#2 and 6.3.1.8#2, the assert should
>  > not fail (unless the division yields a NaN, but that would be a very
>  > bad implementation anyway).
> 
> I have read the sections you mention, and I cannot see how they imply
> what you write.  Can you explain, please?

Consider the example:

#include <assert,h>
volatile float x = 3;
int main()
{
  float a = 1 / x;
  x = a;
  assert(a == x);
}

Concerning the line "float a = 1 / x;", 1 / x may be computed in
any extended precision, but when assigned to a, the result must
be converted to float (precision and range). Then concerning the
line "x = a;", since the type is the same, the value is unchanged.
And in the assert, a and x should have exactly the same value, so
that the comparison should return 1 (i.e., true).

-- 
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / SPACES project at LORIA

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

[Vincent Lefevre]

On 2005-05-31 13:16:55 +0100, Andrew Haley wrote:
> Vincent Lefevre writes:
>  > According to 5.1.2.3#13, 6.3.1.5#2 and 6.3.1.8#2, the assert should
>  > not fail (unless the division yields a NaN, but that would be a very
>  > bad implementation anyway).
> 
> I have read the sections you mention, and I cannot see how they imply
> what you write.  Can you explain, please?

Well, concerning the first reference, it should be 5.1.2.3#12.
Concerning 6.3.1.8#2, see the footnote (52).

-- 
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / SPACES project at LORIA

Re: What is wrong with Bugzilla?

[Gerald Pfeifer]

On Mon, 30 May 2005, Daniel Berlin wrote:
> Apparently they estimate the probability of a == x succeeding at 42%
> for some reason (This is true at all opts levels, with and without SSE 
> math). Why this isn't 50%, who knows.

Might be related to the Hitchhiker's Guide to the Galaxy? <g>

Gerald

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

[Ross Smith]

On Sunday, 29 May 2005 03:17, Uros Bizjak wrote:
>
> There is no problem that Bugzilla is un-intuitive, it is far from
> that. The users don't fill bugreports because they are afraid of
> filling an invalid report or a duplicate.

I strongly suspect you're mistaken about the reason.

> Is perhaps some kind of anonymous account needed (as in Slashdot's
> case) to encourage these users to fill bugreports?

I think this is probably the real showstopper. I'll admit I haven't 
exactly made a scientific survey here, but I suspect a lot of people 
give up when they see the login form.

Whenever I see something like "we need a valid email address" on a 
corporate web site, I always take it for granted that it's because they 
want to spam me. If I really need the information behind the login 
wall, I set up a throwaway address or use www.bugmenot.com. Of course 
I'm not accusing the FSF of being spammers, but you can't expect the 
casual user of GCC who isn't aware of its background to know that.

I'd bet that this is the real reason so few people file bug reports. As 
soon as they see the demand for an email address, alarm bells start 
going off in their minds, and they go away.

(If the email request was on the bug report form itself instead of a 
login, and was _optional_, probably more people would be willing to 
fill it in.)

-- 
Ross Smith ........ r-smith@ihug.co.nz ........ Auckland, New Zealand
  "Plausible rockets are rare. Plausible space travel is rare. Most
  SF authors could not calculate a mass ratio if you put them in a
  sunken pit filled with ravenous sliderules." -- James Nicoll

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

[Joe Buck]

On Sun, May 29, 2005 at 04:37:18PM +1200, Ross Smith wrote:
> Whenever I see something like "we need a valid email address" on a 
> corporate web site, I always take it for granted that it's because they 
> want to spam me.

In this case, the GCC developers really do intend to use your email
address to send you mail.  These might include requests for more
information on the bug if it is needed, as well as messages that indicate
when the bug is fixed.

It also helps assure that the bug filer is a real person.  If Bugzilla
provided an anonymous way to file Bugzilla reports, we'd probably have
spammers filling the bug database with ads for penis enlargement.

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

[R Hill]

Joe Buck wrote:

> It also helps assure that the bug filer is a real person.  If Bugzilla
> provided an anonymous way to file Bugzilla reports, we'd probably have
> spammers filling the bug database with ads for penis enlargement.

RESOLVED: WORKSFORME


--de.

Re: What is wrong with Bugzilla?

[Zack Weinberg]

R Hill <dirtyepic.sk@gmail.com> writes:
> Joe Buck wrote:
>> [The request to create a login] also helps assure that the bug
>> filer is a real person.  If Bugzilla provided an anonymous way to
>> file Bugzilla reports, we'd probably have spammers filling the bug
>> database with ads for penis enlargement.
>
> RESOLVED: WORKSFORME

I laughed, but Joe is right.  The Debian bug database, which creates
new bug reports for every message sent to its submit@ address, has had
to institute aggressive automated spam filtering, and its bugmasters
still spend plenty of time weeding spam out of the database.

However, Ross is also right; it is one more hoop to jump through to
submit a bug report, and privacy concerns aside, some people may just
get annoyed and give up at that point.

A possible happy medium might be to merge the two forms for people who
aren't already logged in:-

 --- 
 Bugzilla does not know who you are.  We need a valid email address
 for you so that we can contact you to discuss your bug report.

 If you already have an account, enter your email address and password
 below.  If you don't, enter your email address and leave the password
 field blank; Bugzilla will email you a password.

 Email address: |----------|
 Password:      |----------|
 ---
 [existing tell-us-about-the-bug form here]

Could probably be improved further; I just made that up off the top of
my head.

zw

RE: What is wrong with Bugzilla?

[Gary Funck]

As an occasional user of the Bugzilla database, I don't find it terrible to use, though
it would be nice if there were an abbreviated interface that looked for the sorts of
queries that users issue the most.  These often-occurring queries might be best determined
by saving a month's worth of queries and ferreting out the types of queries that occur
most often.  I also didn't find the requirement that I register my e-mail address to
be particular surprising or burdomesome.

As an aside, I often stumble into the middle of a Redhat discussion list thread via
Google that seems to relate to a problem that I've encountered.  Redhat for some reason
requires https access, and in IE6, my browser of non-choice, I have to click OK to view
the page.  Now, _that_ is annoying.

What may be confusing to users: where do I report my problem? If I'm a Redhat user,
do I log my potential GCC problem to their support site, or to the GCC site?  To further
confuse matters, for most users, the vendors often modify a given version of GCC to
include specific patches and build options of their choice.  This of course argues
for logging bugs with the vendor.  One wonders whether the vendors are timely in reporting
legit bugs back to the GCC Bugzilla database, but one hopes so.

If we for the moment assume that users of pre-packaged distributions report their bugs
back to the vendor, then the GCC mailing lists and bug lists are left for those brave
souls who are using GCC source code distributions directly.  (perhaps the GCC maintainers
can comment on whether this theory in fact holds).  Matters are further complicated by
the fact that there are now several viable GCC releases to choose from: 3.3.x, 3.4.x,
4.0.x, CVS head, and so on.  There's even the occasional bug filed against one of the
many branches.  When we consider the multitude of choices, it is amazing that there
is any forward progress. <g>

As a casual reader of the GCC lists, I do have one observation: the volume on the
GCC bug list is very, very high.  Often the bug traffic there relates to regressions
and bugs that are found on the CVS head or recent development releases.  As a user
of the older releases (3.3, 3.4), I'd much prefer it if there were too separate bug
reporting lists: one for the more stable released versions, and a separate list for
the "latest".  I'd also like it if there was a web page for each stable release that
showed the results of a canned Bugzilla query which lists open bugs and/or recently
closed bugs agaisnt the stable releases (not sure how this would be organized).

As far as the tenor of the GCC mailing list goes, it is true that responses to "dumb
questions" are often terse, but they're generally helpful.  I think this is to be
expected, when interacting with busy developers who have to balance many priorities
and pressing deadlines.  I've been particularly disappointed by queries to related
lists like the glibc list, which of course is an equally important component of a
useful C compilation system.  I would vote affirmatively to somehow more closely
linking GCC releases with specific GLIBC distributions, and have some sort of tighter
coordination between the two.  However, after delving into GLIBC on a particular
platform, I can see where handling the many varieties of GLIBC builds is a big
problem, and appears to be one that presently the vendors mainly deal with.

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

[Daniel Berlin]

On Sun, 2005-05-29 at 16:37 +1200, Ross Smith wrote:
> On Sunday, 29 May 2005 03:17, Uros Bizjak wrote:
> >
> > There is no problem that Bugzilla is un-intuitive, it is far from
> > that. The users don't fill bugreports because they are afraid of
> > filling an invalid report or a duplicate.
> 
> I strongly suspect you're mistaken about the reason.
> 
> > Is perhaps some kind of anonymous account needed (as in Slashdot's
> > case) to encourage these users to fill bugreports?
> 
> I think this is probably the real showstopper. I'll admit I haven't 
> exactly made a scientific survey here, but I suspect a lot of people 
> give up when they see the login form.
> 

> I'd bet that this is the real reason so few people file bug reports. As 
> soon as they see the demand for an email address, alarm bells start 
> going off in their minds, and they go away.

I've looked at the stats for those who click the "file new bug" (which
goes to the login screen if you aren't entered) and those who submit the
bug form, and they aren't way off from each other.

This is probably because the reason we require a valid email address on
bug reports is because we want to communicate with the person who filed
the bug report.

This is the same as every other bug reporting system i'm aware of that
wants high quality reports.

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

[R Hill]

Daniel Berlin wrote:
> On Sun, 2005-05-29 at 16:37 +1200, Ross Smith wrote:
>>On Sunday, 29 May 2005 03:17, Uros Bizjak wrote:
>>
>>>Is perhaps some kind of anonymous account needed (as in Slashdot's
>>>case) to encourage these users to fill bugreports?
>>
>>I think this is probably the real showstopper. I'll admit I haven't 
>>exactly made a scientific survey here, but I suspect a lot of people 
>>give up when they see the login form.
> 
>>I'd bet that this is the real reason so few people file bug reports. As 
>>soon as they see the demand for an email address, alarm bells start 
>>going off in their minds, and they go away.
> 
> I've looked at the stats for those who click the "file new bug" (which
> goes to the login screen if you aren't entered) and those who submit the
> bug form, and they aren't way off from each other.
> 
> This is probably because the reason we require a valid email address on
> bug reports is because we want to communicate with the person who filed
> the bug report.
> 
> This is the same as every other bug reporting system i'm aware of that
> wants high quality reports.

I just wanted to speak up and say that the idea of alarm bells going off 
when people see a request for an email address from bugzilla is probably 
one of the sillier things I've read this week.  Anyone lucid enough to 
be reporting a bug to an open source project like GCC realizes (i hope) 
in some form how the whole internet-thing works.  If you request 
support, obviously people need a way to get in touch with you.  If 
you're looking at GCC and thinking "email-spammers@!@#$" then you may 
have more bugs than you thought. ;)

There are throwaway-email services like http://www.jetable.org and free 
email services available from many sources for the very wary.  Maybe a 
mention of that would help.

--de.

Re: What is wrong with Bugzilla?

[Russ Allbery]

R Hill <dirtyepic.sk@gmail.com> writes:

> I just wanted to speak up and say that the idea of alarm bells going off
> when people see a request for an email address from bugzilla is probably
> one of the sillier things I've read this week.  Anyone lucid enough to
> be reporting a bug to an open source project like GCC realizes (i hope)
> in some form how the whole internet-thing works.  If you request
> support, obviously people need a way to get in touch with you.  If
> you're looking at GCC and thinking "email-spammers@!@#$" then you may
> have more bugs than you thought. ;)

It's not the request for the e-mail address.  It's that it's phrased as a
login screen and a button to create an account.  I know that I definitely
pause and consider before I create an account at a web site.  There are
many on-line newspapers that I refuse to read articles from, for example,
because I don't want to create an account.  That creates a piece of
authorization out there that I have to record a password for and that I'm
to some degree responsible for.

I think this is mostly just a matter of phrasing and presentation, though,
not a fundamental problem.  (Another difficulty is that presenting a login
screen and inviting people to create an account also implies that if you
weren't already invited to create an account, someone might be upset if
you just make one.  It has a very "members only" sort of feel to it.)

-- 
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>

Re: What is wrong with Bugzilla?

[R Hill]

Russ Allbery wrote:

> It's not the request for the e-mail address.  It's that it's phrased as a
> login screen and a button to create an account.  I know that I definitely
> pause and consider before I create an account at a web site.  There are
> many on-line newspapers that I refuse to read articles from, for example,
> because I don't want to create an account.  That creates a piece of
> authorization out there that I have to record a password for and that I'm
> to some degree responsible for.
> 
> I think this is mostly just a matter of phrasing and presentation, though,
> not a fundamental problem.  (Another difficulty is that presenting a login
> screen and inviting people to create an account also implies that if you
> weren't already invited to create an account, someone might be upset if
> you just make one.  It has a very "members only" sort of feel to it.)

Ah okay, I completely misinterpreted what you meant by "alarm bells". 
Sorry.  I do agree with you, and I know there are a few sites that I 
ignore due to their no-account-no-view policy too.

to bring in what Zack said earlier:

> However, Ross is also right; it is one more hoop to jump through to
> submit a bug report, and privacy concerns aside, some people may just
> get annoyed and give up at that point.
> 
> A possible happy medium might be to merge the two forms for people who
> aren't already logged in:-
> 
>  --- 
>  Bugzilla does not know who you are.  We need a valid email address
>  for you so that we can contact you to discuss your bug report.
> 
>  If you already have an account, enter your email address and password
>  below.  If you don't, enter your email address and leave the password
>  field blank; Bugzilla will email you a password.

IMHO, KDE's bugzilla[1] hits this right on the head.  They're also the 
only project I know who's bugzilla doesn't feel like every other 
bugzilla out there, just with a different themepack.

[1] https://bugs.kde.org/

RE: What is wrong with Bugzilla?

[Dave Korn]

----Original Message----
>From: Russ Allbery
>Sent: 31 May 2005 04:51


> It's not the request for the e-mail address.  It's that it's phrased as a
> login screen and a button to create an account.  I know that I definitely
> pause and consider before I create an account at a web site.  There are
> many on-line newspapers that I refuse to read articles from, for example,
> because I don't want to create an account.  That creates a piece of
> authorization out there that I have to record a password for and that I'm
> to some degree responsible for.


  Whenever I come across one of those interfaces, I test it to see if it'll
let me create an account called 'guest' with password 'guest'.  (I believe
in keeping the old net.traditions alive!)  If it wants an email address, I
use 'guest@example.org'. 


    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....

RE: What is wrong with Bugzilla?

[Daniel Berlin]

On Tue, 2005-05-31 at 17:52 +0100, Dave Korn wrote:
> ----Original Message----
> >From: Russ Allbery
> >Sent: 31 May 2005 04:51
> 
> 
> > It's not the request for the e-mail address.  It's that it's phrased as a
> > login screen and a button to create an account.  I know that I definitely
> > pause and consider before I create an account at a web site.  There are
> > many on-line newspapers that I refuse to read articles from, for example,
> > because I don't want to create an account.  That creates a piece of
> > authorization out there that I have to record a password for and that I'm
> > to some degree responsible for.
> 
> 
>   Whenever I come across one of those interfaces, I test it to see if it'll
> let me create an account called 'guest' with password 'guest'.  (I believe
> in keeping the old net.traditions alive!)  If it wants an email address, I
> use 'guest@example.org'. 


And then if we need more info for your bug report, and can't reach you,
we'll simply close it.

RE: What is wrong with Bugzilla?

[Dave Korn]

----Original Message----
>From: Daniel Berlin
>Sent: 31 May 2005 18:00

> On Tue, 2005-05-31 at 17:52 +0100, Dave Korn wrote:

>> ----Original Message----
>>> From: Russ Allbery
>>> Sent: 31 May 2005 04:51

>>> There are many on-line newspapers that I refuse to read articles from,
>>> for example, because I don't want to create an account.  That creates a
>>> piece of authorization out there that I have to record a password for
>>> and that I'm to some degree responsible for.

>>   Whenever I come across one of those interfaces, I test it to see if
>> it'll let me create an account called 'guest' with password 'guest'.  (I
>> believe in keeping the old net.traditions alive!)  If it wants an email
>> address, I use 'guest@example.org'.

> And then if we need more info for your bug report, and can't reach you,
> we'll simply close it.

  Oh, really?  

  At precisely *which* on-line newspaper site do you expect to find me
entering gcc bug reports?









       :-P~~~~

  Heh, I admit that was a bit O-T; I wasn't recommending that solution for a
situation where you actually _want_ to get in touch with someone, but just
for the general 'I can't read the article on this newspaper's site without
registering' case.

  For bugzilla I use my real email address, because of course if I report a
bug I want to hear back about it.

  I had an even stupider version of this whole debate a little while ago on
IIRC the binutils mailing list, where someone refused to enter a bug report
into bugzilla because it was going to set a cookie and they thought that it
was somehow sinister.  I'm all in favour of people being informed, and
closely guarding their privacy rights, but ranting and raving because you
think a cookie is some kind of evil demon that will magically spy on you is
the sign of a paranoid conspiracy loon, not a keen eye for privacy
violations.

    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....

RE: What is wrong with Bugzilla?

[Daniel Berlin]

On Tue, 2005-05-31 at 18:12 +0100, Dave Korn wrote:
> ----Original Message----
> >From: Daniel Berlin
> >Sent: 31 May 2005 18:00
> 
> > On Tue, 2005-05-31 at 17:52 +0100, Dave Korn wrote:
> 
> >> ----Original Message----
> >>> From: Russ Allbery
> >>> Sent: 31 May 2005 04:51
> 
> >>> There are many on-line newspapers that I refuse to read articles from,
> >>> for example, because I don't want to create an account.  That creates a
> >>> piece of authorization out there that I have to record a password for
> >>> and that I'm to some degree responsible for.
> 
> >>   Whenever I come across one of those interfaces, I test it to see if
> >> it'll let me create an account called 'guest' with password 'guest'.  (I
> >> believe in keeping the old net.traditions alive!)  If it wants an email
> >> address, I use 'guest@example.org'.
> 
> > And then if we need more info for your bug report, and can't reach you,
> > we'll simply close it.
> 
>   Oh, really?  


>   At precisely *which* on-line newspaper site do you expect to find me
> entering gcc bug reports?
I thought you were generalizing "those interfaces" to include bugzilla,
which was the original topic of discussion :)

>   I had an even stupider version of this whole debate a little while ago on
> IIRC the binutils mailing list, where someone refused to enter a bug report
> into bugzilla because it was going to set a cookie and they thought that it
> was somehow sinister. 

It's completely sinister.
We store all your info in there including YOUR QUERY SORT ORDER!

:)

RE: What is wrong with Bugzilla?

[Dave Korn]

----Original Message----
>From: Daniel Berlin
>Sent: 31 May 2005 18:22

> On Tue, 2005-05-31 at 18:12 +0100, Dave Korn wrote:

> 
>>   I had an even stupider version of this whole debate a little while ago
>> on IIRC the binutils mailing list, where someone refused to enter a bug
>> report into bugzilla because it was going to set a cookie and they
>> thought that it was somehow sinister.
> 
> It's completely sinister.
> We store all your info in there including YOUR QUERY SORT ORDER!
> 
> :)



  HAH!  That's just what they WANT you to think!!!1!!!!



    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....

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

[Hugh Sasse]

On Sun, 29 May 2005, Ross Smith wrote:

> On Sunday, 29 May 2005 03:17, Uros Bizjak wrote:
>>
>> There is no problem that Bugzilla is un-intuitive, it is far from
>> that. The users don't fill bugreports because they are afraid of
>> filling an invalid report or a duplicate.
>
> I strongly suspect you're mistaken about the reason.

Well, the site is pretty stern about searching first :-)  Which is
fair enough for the usual internet-culture (RTFM, STFW) reasons.
>
>> Is perhaps some kind of anonymous account needed (as in Slashdot's
>> case) to encourage these users to fill bugreports?
>
> I think this is probably the real showstopper. [...]
>
> Whenever I see something like "we need a valid email address" on a
> corporate web site, I always take it for granted that it's because they
> want to spam me. [...]

I don't think this is entirely the problem, however.  That recaction
is reasonable nowadays, but I think there are textual improvements
that could help.

It's an oft-quoted idea in teaching that you tell people what you
are going to tell them, then you tell them it, then you tell them
what you have told them.  I think the bugzilla site could be
improved by explaining the process a bit more:

  * How will your email address be used?
  * Who will actually see it?  Does it get shrouded, at all?
  * Will the system send you alerts of changes?
  * Do you have any control over the kinds of alerts you get?
  * Is there a person/group/list you can talk to about our
    bugzilla culture if the information here is insufficient?

Then there might be information such as

  * What will affect the time it takes to fix your bug?
  * Is there a normal lifecycle for bug reports, so you know how
    far your bug has progessed?
  * Any terminology you should be aware of (such as PR)?

If this information is available I think it could be made more
obvious, so that you pass through/close by it when reaching the page
where you make the account.


There has been an assertion that GCC is for developers, and the
sites reflect this.  Well, I'd like to challange that.  Many
packages (and I think among them are, or were,  Exim, Python, Perl
and Ruby) are designed to work best when built with GCC, and if you
have problems you are often advised to try with (the latest?) GCC.  Given
that many OS vendors don't supply a compiler now, it maybe that many
people experiencing problems are not familiar with GCC develpment,
and may not consider themselves familiar with modern C.  They may be
finding bugs (or only perceived bugs) when using GCC to get
somewhere else.  Obviously friendliness for developers is important,
but I don't helieve it covers everyone.

So, to conclude, I don't think there is much wrong with Bugzilla,
but that it could benefit from managing people's expectations of it, 
by supplying such information up front.

         Hope this helps
         Hugh

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

[Haren Visavadia]

--- Uros Bizjak  wrote:
> At this point, I wonder what is wrong with Bugzilla,
> that those 
> programmers don't fill a proper bug report. If there
> is a problem with 
> GCC, that is so annoying to somebody, I think that
> at least developers 
> could be informed about it via their standard
> channels of communication. 
> If there is a specific problem, at least it can be
> analysed properly and 
> perhaps some actions could be taken to fix it. If
> the problem is indeed 
> _that_ big (usually, it is not!), then a workaround
> could be suggested - 
> and this bug, together with a workaround is
> documented in bugzilla for 
> others, until the problem is properly solved
> (usually with a testcase). 
> I guess that these persons don't know that
> bugreports are extremmely 
> important for the development of gcc. The users
> themself are actaully a 
> QA department of open source development;)
> 
> There is no problem that Bugzilla is un-intuitive,
> it is far from that. 
> The users don't fill bugreports because they are
> afraid of filling an 
> invalid report or a duplicate. I can't speak for gcc
> bugmasters, but it 
> looks to me that dupes and invalid reports are not
> that big problem.
t if people sit 3000 km/miles/whatever apart
> ;)
> 

You can search Bugzilla as well, so you do not fill in
duplicate bug report.

As long as the bug report can be easily reproduced, it
will probably not get made invalid.





 



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

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

[Michael Veksler]

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

[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&)'

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

[Giovanni Bajo]

Michael Veksler <VEKSLER@il.ibm.com> wrote:

> Unfortunately, this is not 100% correct. Recently I have filed several
> duplicates, *after* searching Bugzilla.

That is not a problem. Bugmasters are there exactly for that. We realize that
finding duplicates can be very hard (in fact, sometimes duplicates are
acknowledged as such only after a fix appears), so that is our work. We just
ask users for some *basic* duplicate checking, and I think most users do that
before filing bugreports. So it's ok.


> 3. Nontrivial search of GCC Bugzilla are, sometimes,
>    extremely slow (over a minute).

3 could be worked on (Daniel?)


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

Maybe. But I don't think people don't file bugreports because of this. In every
software company I have been working on there has always been some debates
about bugreports ("it's your code's fault" -- "no, it's yours"), I expect GCC
users to know/expect this. Anyway, we are speaking of a really minority of the
bug reports we get. Most of the bugreports filed *are* related to GCC, and
among those that are not, most are *obviously* so (in that, people realize
immediately it's not GCC's fault).

> [2] GCC could implement a better error message.

This is a bug, too. You can file a PR in Bugzilla explictly asking for a more
informative error message.

Giovanni Bajo

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

[Michael Veksler]

Giovanni Bajo wrote on 29/05/2005 13:50:59:

> Michael Veksler <VEKSLER@il.ibm.com> wrote:
> > [2] GCC could implement a better error message.
>
> This is a bug, too. You can file a PR in Bugzilla explictly asking for a
more
> informative error message.
>

PR 21808

  Michael

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

[Daniel Berlin]

On Sun, 2005-05-29 at 12:50 +0200, Giovanni Bajo wrote:
> Michael Veksler <VEKSLER@il.ibm.com> wrote:
> 
> > Unfortunately, this is not 100% correct. Recently I have filed several
> > duplicates, *after* searching Bugzilla.
> 
> That is not a problem. Bugmasters are there exactly for that. We realize that
> finding duplicates can be very hard (in fact, sometimes duplicates are
> acknowledged as such only after a fix appears), so that is our work. We just
> ask users for some *basic* duplicate checking, and I think most users do that
> before filing bugreports. So it's ok.
> 
> 
> > 3. Nontrivial search of GCC Bugzilla are, sometimes,
> >    extremely slow (over a minute).
> 
> 3 could be worked on (Daniel?)

Send me the URL's for the buglists and i'll look at the queries (The url
for the buglist contains the query).

A lot of this is mysql's query engine being stupid, and is hopefully
fixed in 4.x or 5.x (sourceware is still on 3.x).

I'm happy to optimize the searchs as best i can (by adding lame extra
indexes if necessary :P)

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

[Michael Veksler]

Daniel Berlin <dberlin@dberlin.org> wrote on 30/05/2005 06:41:54:

> On Sun, 2005-05-29 at 12:50 +0200, Giovanni Bajo wrote:
> > Michael Veksler <VEKSLER@il.ibm.com> wrote:
> >
> > > 3. Nontrivial search of GCC Bugzilla are, sometimes,
> > >    extremely slow (over a minute).
> >
> > 3 could be worked on (Daniel?)
>
> Send me the URL's for the buglists and i'll look at the queries (The url
> for the buglist contains the query).
>
> A lot of this is mysql's query engine being stupid, and is hopefully
> fixed in 4.x or 5.x (sourceware is still on 3.x).
>
> I'm happy to optimize the searchs as best i can (by adding lame extra
> indexes if necessary :P)

It is difficult to reproduce because behavior changes over time.
2 hours ago I was getting time-out even for:
  http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21808

Now, it takes about 2 seconds.

Here is a synthetic test query that take only 15 seconds ATM:

http://gcc.gnu.org/bugzilla/buglist.cgi?query_format=&short_desc_type=allwordssubstr&short_desc=&known_to_fail_type=allwordssubstr&known_to_work_type=allwordssubstr&long_desc_type=allwordssubstr&long_desc=float-store+ICE&bug_file_loc_type=allwordssubstr&bug_file_loc=&gcchost_type=allwordssubstr&gcchost=&gcctarget_type=allwordssubstr&gcctarget=&gccbuild_type=allwordssubstr&gccbuild=&keywords_type=allwords&keywords=&bug_status=RESOLVED&bug_status=CLOSED&emailassigned_to1=1&emailreporter1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Bug+Number&field0-0-0=noop&type0-0-0=noop&value0-0-0=

A more sensible query takes 8 seconds:
http://gcc.gnu.org/bugzilla/buglist.cgi?query_format=&short_desc_type=allwordssubstr&short_desc=&known_to_fail_type=allwordssubstr&known_to_work_type=allwordssubstr&long_desc_type=allwordssubstr&long_desc=float-store+ICE&bug_file_loc_type=allwordssubstr&bug_file_loc=&gcchost_type=allwordssubstr&gcchost=&gcctarget_type=allwordssubstr&gcctarget=&gccbuild_type=allwordssubstr&gccbuild=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=SUSPENDED&bug_status=WAITING&bug_status=REOPENED&bug_status=VERIFIED&emailassigned_to1=1&emailreporter1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Bug+Number&field0-0-0=noop&type0-0-0=noop&value0-0-0=

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

[Daniel Berlin]

On Mon, 2005-05-30 at 07:59 +0300, Michael Veksler wrote:
> 
> 
> 
> 
> 
> Daniel Berlin <dberlin@dberlin.org> wrote on 30/05/2005 06:41:54:
> 
> > On Sun, 2005-05-29 at 12:50 +0200, Giovanni Bajo wrote:
> > > Michael Veksler <VEKSLER@il.ibm.com> wrote:
> > >
> > > > 3. Nontrivial search of GCC Bugzilla are, sometimes,
> > > >    extremely slow (over a minute).
> > >
> > > 3 could be worked on (Daniel?)
> >
> > Send me the URL's for the buglists and i'll look at the queries (The url
> > for the buglist contains the query).
> >
> > A lot of this is mysql's query engine being stupid, and is hopefully
> > fixed in 4.x or 5.x (sourceware is still on 3.x).
> >
> > I'm happy to optimize the searchs as best i can (by adding lame extra
> > indexes if necessary :P)
> 
> It is difficult to reproduce because behavior changes over time.
> 2 hours ago I was getting time-out even for:
>   http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21808

This may be server load in that case (new hardware is in the process of
being acquired).

> 
> Now, it takes about 2 seconds.
> 
> Here is a synthetic test query that take only 15 seconds ATM:
> 
> http://gcc.gnu.org/bugzilla/buglist.cgi?query_format=&short_desc_type=allwordssubstr&short_desc=&known_to_fail_type=allwordssubstr&known_to_work_type=allwordssubstr&long_desc_type=allwordssubstr&long_desc=float-store+ICE&bug_file_loc_type=allwordssubstr&bug_file_loc=&gcchost_type=allwordssubstr&gcchost=&gcctarget_type=allwordssubstr&gcctarget=&gccbuild_type=allwordssubstr&gccbuild=&keywords_type=allwords&keywords=&bug_status=RESOLVED&bug_status=CLOSED&emailassigned_to1=1&emailreporter1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Bug+Number&field0-0-0=noop&type0-0-0=noop&value0-0-0=

Comment searches don't currently take advantage of the fulltext index on
the comments, and mysql isn't particulary good at them.
I'm looking into it.

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

[Daniel Berlin]

On Mon, 2005-05-30 at 07:59 +0300, Michael Veksler wrote:
> 
> 
> 
> 
> 
> Daniel Berlin <dberlin@dberlin.org> wrote on 30/05/2005 06:41:54:
> 
> > On Sun, 2005-05-29 at 12:50 +0200, Giovanni Bajo wrote:
> > > Michael Veksler <VEKSLER@il.ibm.com> wrote:
> > >
> > > > 3. Nontrivial search of GCC Bugzilla are, sometimes,
> > > >    extremely slow (over a minute).
> > >
> > > 3 could be worked on (Daniel?)
> >
> > Send me the URL's for the buglists and i'll look at the queries (The url
> > for the buglist contains the query).
> >
> > A lot of this is mysql's query engine being stupid, and is hopefully
> > fixed in 4.x or 5.x (sourceware is still on 3.x).
> >
> > I'm happy to optimize the searchs as best i can (by adding lame extra
> > indexes if necessary :P)
> 
> It is difficult to reproduce because behavior changes over time.
> 2 hours ago I was getting time-out even for:
>   http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21808
> 
> Now, it takes about 2 seconds.
> 
> Here is a synthetic test query that take only 15 seconds ATM:
> 
> http://gcc.gnu.org/bugzilla/buglist.cgi?query_format=&short_desc_type=allwordssubstr&short_desc=&known_to_fail_type=allwordssubstr&known_to_work_type=allwordssubstr&long_desc_type=allwordssubstr&long_desc=float-store+ICE&bug_file_loc_type=allwordssubstr&bug_file_loc=&gcchost_type=allwordssubstr&gcchost=&gcctarget_type=allwordssubstr&gcctarget=&gccbuild_type=allwordssubstr&gccbuild=&keywords_type=allwords&keywords=&bug_status=RESOLVED&bug_status=CLOSED&emailassigned_to1=1&emailreporter1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Bug+Number&field0-0-0=noop&type0-0-0=noop&value0-0-0=

I should also note 2 things
1. that new hardware will help both these queries (mysql requires a
filesort for this one, and thus it will be heavily affected by i/o load,
which is usually pretty high on sourceware :( )


I'm still looking into what can be done in the meanwhile, of course.


2. Nobody in this thread has ever emailed me, or gcc@, before now,
complaining about bugzilla UI/speed/etc

You guys really should learn to complain more if you want things fixed.

:)

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

[Haren Visavadia]

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

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

[Joe Buck]

On Sun, May 29, 2005 at 01:22:55PM +0300, Michael Veksler wrote:
> 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.

That's OK.  It's better to have duplicates than to have a bug go
unreported; the duplicates even serve the purpose of sending the
message that this is an important bug (if the same bug can be
encountered in very different ways).

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

[Vincent Lefevre]

On 2005-05-29 13:22:55 +0300, Michael Veksler wrote:
> Two examples come in mind:
> 1. Non conformance of x86 to the standard FP due to
>    its extra precision.

Wrong. The IEEE-754 standard allows extended precision.

>    This includes different results between -O2 and -O0 even with
>    -fsave-temps.

Getting different results is not the problem (and indeed, some bug
reports are invalid, but *some* of them only).

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

As I've said above, this is not a wrong precision; this is allowed
by the IEEE-754 standard. So, this is definitely not a hardware
bug. Perhaps just a bad design.

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

Where? Has there been a bug report about that?

If you think of FLT_EVAL_METHOD, it is set to 2. It may be wrong
(as said later in this thread), but it certainly does not mean
that the default precision is the IEEE-754 double precision.

-- 
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / SPACES project at LORIA

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

[Daniel Berlin]

On Sun, 2005-05-29 at 13:22 +0300, Michael Veksler wrote:
> 
> 
> 
> 
> 
> 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).
> 
> >

Please send me the urls' to the buglists that are taking a long time to
generate (I don't care if they are a billion character long urls, i know
what to do with them :P)

I should be able to determine what will be necessary to make them go
faster.
--Dan