Reporting bugs: there is nothing to gain in frustrating reporters

Reporting bugs: there is nothing to gain in frustrating reporters

[Roberto Bagnara]

Stimulated by the discussion about fixing bugs and frustrated
potential developers, I thought it could be useful to briefly
share my recent experience of frustrated bug reporter with the
subscribers of this list.

Until the recent past, I have never given up investigating any
suspicious behavior of GCC and I have always tried hard to
come up with a testcase, check the standard documents and write
decent bug reports.  But this activity has recently been so
frustrating that I now see it as a loss of time.  In the past,
we had the list of open bug reports that was growing beyond
control;  to improve the situation now we have people sitting
on the bug database on a 24/7 basis, with an apparent anxiety
to close bug reports as quickly as possible.

The pattern I went through lately goes more or less as follows:

1) I submit a bug report;
2) someone looks at it superficially, too superficially, and
    posts a comment that tends to deny there is a problem;
3) I and/or someone else explain that the problem is indeed
    there, possibly citing the points of the standards that
    are being violated;
4) the person who said the bug was not (exactly) a bug does
    not even care to reply, but the superficial comments
    remain there, probably killing the bug report.

I wonder what is the rationale here.  Discouraging bug
reporters may be an effective way to avoid bug reports pile up,
but this is certainly not good for GCC.

Examples of the pattern I described above are in:

   http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21067
   http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21032
   http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19092
   http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12963

My advice to people filtering bug reports is: if you only had
time to look at the issue superficially, either do not post
any comment or be prepared to continue the discussion on more
serious grounds if the reporter or someone else comes back
by offering more insight and/or precise clauses of the
relevant standards.

All the best,

     Roberto

-- 
Prof. Roberto Bagnara
Computer Science Group
Department of Mathematics, University of Parma, Italy
http://www.cs.unipr.it/~bagnara/
mailto:bagnara@cs.unipr.it

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Giovanni Bajo]

Roberto Bagnara <bagnara@cs.unipr.it> wrote:

> 1) I submit a bug report;
> 2) someone looks at it superficially, too superficially, and
>     posts a comment that tends to deny there is a problem;
> 3) I and/or someone else explain that the problem is indeed
>     there, possibly citing the points of the standards that
>     are being violated;
> 4) the person who said the bug was not (exactly) a bug does
>     not even care to reply, but the superficial comments
>     remain there, probably killing the bug report.

While I agree that it can happen to make a too superficial comment on a bug
(I surely had done this in the past, and Andrew seems to do this very
often), I believe that this does not spoil or kill the bug report itself,
once it was agreed that there is indeed a bug.

Surely, it does annoy the reporter though, which is a serious problem.

> I wonder what is the rationale here.  Discouraging bug
> reporters may be an effective way to avoid bug reports pile up,
> but this is certainly not good for GCC.

I totally agree here. I believe Mark already asked us (bugmasters) to be
more polite in their work, and I believe that another official statement in
this direction would help.

> My advice to people filtering bug reports is: if you only had
> time to look at the issue superficially, either do not post
> any comment or be prepared to continue the discussion on more
> serious grounds if the reporter or someone else comes back
> by offering more insight and/or precise clauses of the
> relevant standards.

Agreed. But keep in mind that it is not necessary to reply: once the bug is
open and confirmed, the last comment "wins", in a way. If the bugmaster
wanted to close it, he would just do it, so an objection in a comment does
not make the bug invalid per se.
-- 
Giovanni Bajo

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Scott Robert Ladd]

Giovanni Bajo wrote:
> Agreed. But keep in mind that it is not necessary to reply: once the bug is
> open and confirmed, the last comment "wins", in a way. If the bugmaster
> wanted to close it, he would just do it, so an objection in a comment does
> not make the bug invalid per se.

But an objection from one of the bugmasters *is* enough to keep people
from presenting a patch. While the may not explicitly close the bug,
their negative reaction tends to suggest that they would not look
favorably on a patch.

..Scott

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Richard Guenther]

On 6/15/05, Scott Robert Ladd <scott.ladd@coyotegulch.com> wrote:
> Giovanni Bajo wrote:
> > Agreed. But keep in mind that it is not necessary to reply: once the bug is
> > open and confirmed, the last comment "wins", in a way. If the bugmaster
> > wanted to close it, he would just do it, so an objection in a comment does
> > not make the bug invalid per se.
> 
> But an objection from one of the bugmasters *is* enough to keep people
> from presenting a patch.

How do you come to this conclusion?  From my experience this
is untrue - bugs get fixed because either someone feels resposible,
it's too easy to do, or someone has personal interest in getting the
bug fixed.  Negative or positive comments do not change this.

Richard.

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Scott Robert Ladd]

Richard Guenther wrote:
> On 6/15/05, Scott Robert Ladd <scott.ladd@coyotegulch.com> wrote:
>>But an objection from one of the bugmasters *is* enough to keep people
>>from presenting a patch.
> 
> How do you come to this conclusion?  From my experience this
> is untrue - bugs get fixed because either someone feels resposible,
> it's too easy to do, or someone has personal interest in getting the
> bug fixed.  Negative or positive comments do not change this.

When a bugmaster posts a pejorative response, it strongly implies that
any effort in patch will be rejected or ignored.

I know for a fact that several people have been chased away from working
on GCC by the pithy attitudes of some GCC developers. Heaven knows why I
stick around and keep trying to help out; it must be a perverse stubborn
streak, akin to masochism. ;)

Why go through the effort of creating a patch when it is likely to be
rejected or ignored? I don't get paid to fix GCC bugs, and if a bug does
not affect my code personally, I have little incentive but the goodness
in my heart to fix bugs that affect other people's code.

Mark has a valid concern: Why aren't bugs being fixed? One answer is:
The GCC community is often less than welcoming, friendly, and helpful.

You may not like or believe the answer, but if you want more people to
help GCC for free, an attitude adjustment may be required on your part.
It's not as if there aren't many other challenging projects for people
to participate in.

..Scott

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Steven Bosscher]

On Wednesday 15 June 2005 18:13, Scott Robert Ladd wrote:
> Mark has a valid concern: Why aren't bugs being fixed?

Maybe the people who work a lot on GCC just don't hear enough about
those bug reports.  I for one will admit to not looking at bugzilla
often enough.  I like the Wiki regressions page a lot, because it is
a nice overview, categorized and everything, of bugs in GCC that we
may want to fix asap.  You could actually see this happening the last
time Mark sent a GCC 4.0.1 status report: he mentioned three bugs and
all three of them are fixed now, about one week later.  One of them
was literally a five minute job, but nobody pointed out this bug to
the people who are familiar with the code that the bug was in.

Or maybe the bugs are just not important enough to the people working
on GCC.  When some bug is a real problem, it usually gets fixed pretty
quickly AFAICT.

> One answer is:
> The GCC community is often less than welcoming, friendly, and helpful.

The GCC community is, as far as I can tell, quite welcoming and most
of the time very friendly and helpful to people who want to hack GCC
and get stuck somewhere after thinking up a good plan for fixing bugs,
reading the code and manuals before asking, and trying to do as much
as possible themselves.  People get less friendly and helpful when
someone only asks silly questions and lots of hand-holding is needed.
That is perfectly reasonable, most GCC hackers are trying to finish
actual work that they care about, and you can't force them to care
about your itches if they really just don't care.  Persisting upsets
people, and that is perfectly normal I think.

Gr.
Steven

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Gabriel Dos Reis]

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

| Richard Guenther wrote:
| > On 6/15/05, Scott Robert Ladd <scott.ladd@coyotegulch.com> wrote:
| >>But an objection from one of the bugmasters *is* enough to keep people
| >>from presenting a patch.
| > 
| > How do you come to this conclusion?  From my experience this
| > is untrue - bugs get fixed because either someone feels resposible,
| > it's too easy to do, or someone has personal interest in getting the
| > bug fixed.  Negative or positive comments do not change this.
| 
| When a bugmaster posts a pejorative response, it strongly implies that
| any effort in patch will be rejected or ignored.

That is not my experience.

-- Gaby

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Daniel Berlin]

On Wed, 2005-06-15 at 12:13 -0400, Scott Robert Ladd wrote:
> Richard Guenther wrote:
> > On 6/15/05, Scott Robert Ladd <scott.ladd@coyotegulch.com> wrote:
> >>But an objection from one of the bugmasters *is* enough to keep people
> >>from presenting a patch.
> > 
> > How do you come to this conclusion?  From my experience this
> > is untrue - bugs get fixed because either someone feels resposible,
> > it's too easy to do, or someone has personal interest in getting the
> > bug fixed.  Negative or positive comments do not change this.
> 
> When a bugmaster posts a pejorative response, it strongly implies that
> any effort in patch will be rejected or ignored.
> 
> I know for a fact that several people have been chased away from working
> on GCC by the pithy attitudes of some GCC developers. 

Maybe you should start naming names, so we can take stock of the
problem.
Otherwise, it just sounds like you are blowing smoke :)
I know it may seem "impolite", but apparently these people are being
impolite and having what you see as a significant affect on GCC.

Therefore, i believe the embarrassment or whatever is outweighed by the
need to change.



> Mark has a valid concern: Why aren't bugs being fixed? One answer is:
> The GCC community is often less than welcoming, friendly, and helpful.

Again, please point to specific examples.

How do you  expect things to adapt and change if you won't give us
examples?

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Vincent Lefevre]

On 2005-06-16 07:43:17 -0400, Daniel Berlin wrote:
> Again, please point to specific examples.

GCC developers don't want examples.

-- 
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: Reporting bugs: there is nothing to gain in frustrating reporters

[Daniel Berlin]

On Thu, 16 Jun 2005, Vincent Lefevre wrote:

> On 2005-06-16 07:43:17 -0400, Daniel Berlin wrote:
>> Again, please point to specific examples.
>
> GCC developers don't want examples.

I'm sorry to interrupt your trolling, but you'll note
1. I'm a GCC developer
2. I asked for specific examples

So you are quite clearly wrong, and being a troll.

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Daniel Berlin]

On Thu, 2005-06-16 at 14:03 +0200, Vincent Lefevre wrote:
> On 2005-06-16 07:43:17 -0400, Daniel Berlin wrote:
> > Again, please point to specific examples.
> 
> GCC developers don't want examples.
> 

I should also note that *you* seem to equate "disagreement with your
viewpoint" with "wrong", "obstinate", or "ignorant", which is not the
case.  Just because someone disagrees with your views on floating point
does not make them wrong, stupid, or people who don't want to listen.
It means they disagree with your viewpoint.

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Vincent Lefevre]

On 2005-06-16 08:12:24 -0400, Daniel Berlin wrote:
> I should also note that *you* seem to equate "disagreement with your
> viewpoint" with "wrong", "obstinate", or "ignorant", which is not the
> case.  Just because someone disagrees with your views on floating point
> does not make them wrong, stupid, or people who don't want to listen.
> It means they disagree with your viewpoint.

This is not my viewpoint, but what the C standard says.

-- 
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: Reporting bugs: there is nothing to gain in frustrating reporters

[Steven Bosscher]

On Thursday 16 June 2005 14:03, Vincent Lefevre wrote:
> On 2005-06-16 07:43:17 -0400, Daniel Berlin wrote:
> > Again, please point to specific examples.
>
> GCC developers don't want examples.

Perhaps not your examples, because your way of discussing so
far is not exactly a very constructive one.

Gr.
Steven

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Gabriel Dos Reis]

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

| On 2005-06-16 07:43:17 -0400, Daniel Berlin wrote:
| > Again, please point to specific examples.
| 
| GCC developers don't want examples.

Vincent -- 

   Yoir remark is inappropriate.  Obviously, Daniel is a GCC developer.
I guess you did not mean to be impolite to or annoy him?

-- Gaby

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Scott Robert Ladd]

Daniel Berlin wrote:
> Maybe you should start naming names, so we can take stock of the
> problem.

Because of Acovea and my reviews of GCC (there are two more coming, one
in a print magazine), a lot of people write me privately. This happens
with commercial compilers as well... and combining those e-mails with
conversations in IRC and other mailing lists, I have ample evidence that
many people feel that the GCC developer community is not very welcoming.

Why do people write me? I've been doing compiler reviews, and working on
compilers (other than GCC), for more than 15 years. Perhaps people just
think they know me, and are more comfortable talking to a "person" who
has publicly expressed concerns similar to thiers.

I am not the only voice in these threads, though. Several people have
expressed feelings herein that are similar to mine.

> How do you  expect things to adapt and change if you won't give us
> examples?

We've made productive suggestions. People have cited specific examples.
For example,

1) Bugmasters could be less perfunctory and pejorative in their
comments. Examples have been given.

2) A mentoring system could help bring along new GCC developers. I'm not
talking about hand-holding, I'm suggesting that having some place for
people to ask a few questions, one on one, to get over certain
conceptual humps.

3) To keep Steven's bloodpressure down, I suggest a new mailing list,
gcc-design, where engineers like myself can propose designs and concepts
without upsetting those who find such discussions annoying.

As it is, I now have enough information to proceed with a couple of
patches related to these dicussions. We'll see how it goes.

..Scott

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Andrew Pinski]

On Jun 16, 2005, at 10:13 AM, Scott Robert Ladd wrote:

> 1) Bugmasters could be less perfunctory and pejorative in their
> comments. Examples have been given.

But you don't see all the thank you emails I get too because they are
almost always in a private email.  And most of the time I don't close
a bug unless I am really really sure that the bug is invalid.  I usually
say "I think this is invalid".

There was a public thank you to me yesterday:
<http://gcc.gnu.org/ml/gcc-bugs/2005-06/msg02124.html>.

-- Pinski

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Gabriel Dos Reis]

Andrew Pinski <pinskia@physics.uc.edu> writes:

| On Jun 16, 2005, at 10:13 AM, Scott Robert Ladd wrote:
| 
| > 1) Bugmasters could be less perfunctory and pejorative in their
| > comments. Examples have been given.
| 
| But you don't see all the thank you emails I get too because they are
| almost always in a private email.  And most of the time I don't close
| a bug unless I am really really sure that the bug is invalid.  I usually
| say "I think this is invalid".

The issue is not whether a report is effectively an invalid bug.  The
issue is whether the reporter must be assumed an obscure ignorant
whose main ill wills are to fill up the GCC bug database, and as such
deserve a corresponding rudeness and must be fought.

-- Gaby

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Gabriel Dos Reis]

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

| 2) A mentoring system could help bring along new GCC developers. I'm not
| talking about hand-holding, I'm suggesting that having some place for
| people to ask a few questions, one on one, to get over certain
| conceptual humps.

Such a place does exist, as mentioned in several messages.

-- Gaby

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Scott Robert Ladd]

Gabriel Dos Reis wrote:
> Scott Robert Ladd <scott.ladd@coyotegulch.com> writes:
> 
> | 2) A mentoring system could help bring along new GCC developers. I'm not
> | talking about hand-holding, I'm suggesting that having some place for
> | people to ask a few questions, one on one, to get over certain
> | conceptual humps.
> 
> Such a place does exist, as mentioned in several messages.

The IRC channel? No one stated that it was for "newbie" questions. Given
that it wasn't very well documented on the web site, it appeared to be a
private channel for existing GCC developers.

..Scott

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Steven Bosscher]

On Thursday 16 June 2005 16:39, Scott Robert Ladd wrote:
> Gabriel Dos Reis wrote:
> > Scott Robert Ladd <scott.ladd@coyotegulch.com> writes:
> > | 2) A mentoring system could help bring along new GCC developers. I'm
> > | not talking about hand-holding, I'm suggesting that having some place
> > | for people to ask a few questions, one on one, to get over certain
> > | conceptual humps.
> >
> > Such a place does exist, as mentioned in several messages.
>
> The IRC channel? No one stated that it was for "newbie" questions. Given
> that it wasn't very well documented on the web site, it appeared to be a
> private channel for existing GCC developers.

Newbie GCC developers are also existing GCC developers.

Gr.
Steven

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Daniel Berlin]

On Thu, 2005-06-16 at 10:13 -0400, Scott Robert Ladd wrote:
> Daniel Berlin wrote:
> > Maybe you should start naming names, so we can take stock of the
> > problem.
> 
> Because of Acovea and my reviews of GCC (there are two more coming, one
> in a print magazine), a lot of people write me privately. This happens
> with commercial compilers as well... and combining those e-mails with
> conversations in IRC and other mailing lists, I have ample evidence that
> many people feel that the GCC developer community is not very welcoming.

Again, *please* provide examples other than "The bugmasters are mean".

> I am not the only voice in these threads, though. Several people have
> expressed feelings herein that are similar to mine.

I've seen two people trolling this thread claiming that because gcc
doesn't agree with their viewpoint, they are wrong and unfriendly.

> 
> > How do you  expect things to adapt and change if you won't give us
> > examples?
> 
> We've made productive suggestions. People have cited specific examples.
> For example,
> 
> 1) Bugmasters could be less perfunctory and pejorative in their
> comments. Examples have been given.

I thought we were talking about the gcc developer community, not only
the bug reporting system?
You keep saying "the mailing lists are not very welcoming".
I've not seen any examples of this.

> 3) To keep Steven's bloodpressure down, I suggest a new mailing list,
> gcc-design, where engineers like myself can propose designs and concepts
> without upsetting those who find such discussions annoying.

You are more than free to post designs on gcc@ if you want. However, you
seem to interpret what appears to be constructive criticism as "not very
friendly" at times.

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Scott Robert Ladd]

Daniel Berlin wrote:
> Again, *please* provide examples other than "The bugmasters are mean".

Don't invent quotes. I never said anyone was "mean." And other people
have provided explicitly links to germane bugs.

> You are more than free to post designs on gcc@ if you want. However, you
> seem to interpret what appears to be constructive criticism as "not very
> friendly" at times.

There's a difference between constructive criticism and condescension.

Be that as it may, I actually agree with Steven that this conversation
has reach the point of no return. You may have the last word.

..Scott

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Daniel Berlin]

On Thu, 2005-06-16 at 10:58 -0400, Scott Robert Ladd wrote:
> Daniel Berlin wrote:
> > Again, *please* provide examples other than "The bugmasters are mean".
> 
> Don't invent quotes. I never said anyone was "mean." And other people
> have provided explicitly links to germane bugs.

Again, i'm looking for more than just the bug database here.

> > You are more than free to post designs on gcc@ if you want. However, you
> > seem to interpret what appears to be constructive criticism as "not very
> > friendly" at times.
> 
> There's a difference between constructive criticism and condescension.

The only time i've seen  condescension used is when the person posting
is not willing to actually understand the issues in the work they are
doing, or repeatedly ignore attempts to guide them.
> 
> Be that as it may, I actually agree with Steven that this conversation
> has reach the point of no return. You may have the last word.

Scott, you have repeatedly claimed unfriendlyness in the gcc developer
community, pointing only to our bug database, and private emails you get
from other people.

When people criticize your designs on gcc@, you seem to take it
personally, and call them unfriendly.

Nothing i have seen in my professional life of a developer tells me that
what you have received is more than just the regular mix of constructive
criticism, mixed with useless replies that inveitably occur that have
nothing to do with anything.

If you consider that "unfriendly", then you really need to get out of
the development business, because you need a thicker skin.

> ..Scott

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Scott Robert Ladd]

Daniel Berlin wrote:
> If you consider that "unfriendly", then you really need to get out of
> the development business, because you need a thicker skin.

Oh, my skin's thick enough. And my skull, too. :) Perhaps there is
misinterpretation all around.

..Scott

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Andrew Pinski]

On Jun 16, 2005, at 10:58 AM, Scott Robert Ladd wrote:

> Daniel Berlin wrote:
>> Again, *please* provide examples other than "The bugmasters are mean".
>
> Don't invent quotes. I never said anyone was "mean." And other people
> have provided explicitly links to germane bugs.

Four out of how many?
The explantion for all of those four:
   http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21067
"
Note GCC does not know about the rounding mode, in fact the round mode 
is only changeable in C99
by the #pragma which GCC does not do right now and I thought that is a 
different PR already."

How could this be considered rude, I was just stating a fact.


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

"
Note neg just flips a bit so it is correct anyways and there is no loss 
of precession.

This also happens on ppc darwin, I don't know what to make of this.  A 
C person has to comment to say
something about this.
"

I said someone else has to comment on this, so I was saying I don't 
know for sure.

   http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19092
Huh, there was no negative thing in there at all from me or either 
Wolfgang.
Maybe "This should be low priority, since we only accept invalid code. 
"  but Wolfgang
found a rejects valid case in about an hour.

   http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12963
This is the only one which was closed, in fact I still think it should 
be a warning
unconditional.

As you can see that from above, only one really shows the case and it 
was corrected
and JSM gave a better way of doing it.

-- Hitler (just to stop this thread)

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Haren Visavadia]

--- Andrew Pinski wrote:
> Four out of how many?

This can not be measured (ie unpredictable), unless
you suggesting you are 100% deterministic on every new
bug presented to you.






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

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Roberto Bagnara]

Andrew Pinski wrote:
 >
 > On Jun 16, 2005, at 10:58 AM, Scott Robert Ladd wrote:
 >
 >> Daniel Berlin wrote:
 >>
 >>> Again, *please* provide examples other than "The bugmasters are mean".
 >>
 >>
 >> Don't invent quotes. I never said anyone was "mean." And other people
 >> have provided explicitly links to germane bugs.
 >
 >
 > Four out of how many?
 > The explantion for all of those four:
 >   http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21067
 > "
 > Note GCC does not know about the rounding mode, in fact the round mode
 > is only changeable in C99
 > by the #pragma which GCC does not do right now and I thought that is a
 > different PR already."
 >
 > How could this be considered rude, I was just stating a fact.

First, I would like to clarify I do not consider it rude.

But I do not consider it a good thing that, after this superficial comment
of yours, you did not even care to reply to my further arguments and question.
This is precisely the kind of behavior that frustrates me and, I guess,
frustrates most other bug reporters.

 >   http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21032
 >
 > "
 > Note neg just flips a bit so it is correct anyways and there is no loss
 > of precession.
 >
 > This also happens on ppc darwin, I don't know what to make of this.  A C
 > person has to comment to say
 > something about this.
 > "
 >
 > I said someone else has to comment on this, so I was saying I don't know
 > for sure.

You said something incorrect ("Note neg just flips a bit so it is correct
anyways and there is no loss of precession"), then again you failed to reply
to an explicit question and to further arguments I added.  You also failed
to reply when I pointed out, in another comment, that this was indeed
a regression from 3.3.  Then leaving the bug UNCONFIRMED for months...
OK, you did not have time to check the standard... perhaps it is the
word "bugmaster" that generates unreasonable expectations.

 >   http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19092
 > Huh, there was no negative thing in there at all from me or either
 > Wolfgang.
 > Maybe "This should be low priority, since we only accept invalid code.
 > "  but Wolfgang
 > found a rejects valid case in about an hour.

That link was included by mistake, in fact.  I apologize.

 >   http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12963
 > This is the only one which was closed, in fact I still think it should
 > be a warning
 > unconditional.

As I said above, perhaps it is the word "bugmaster" that should be changed.
It is hard to believe that a master can advocate an unconditional,
architecture-dependent warning that a user cannot switch off without
switching of _all_ the other warnings and that can only be avoided
by writing non-portable code.  This concerning the substance.
Concerning the form, you closed the bug without even caring, again,
to address the points I raised and the explicit questions I have asked.

To summarize, why should I, simple user, spend hours investigating a
suspicious behavior of GCC when you, bugmaster,  take the liberties
of giving superficial and/or wrong answers without even apologizing,
of not answering altogether, of not looking at the standard documents,
of not even reading carefully what me and others write?  It is not
a matter of rudeness, but rather a matter of technical and social
carelessness.  Why you seem to feel an obligation to intervene
on bug reports for which you appear to have neither the competences
nor a willingness to obtaining them by careful consideration of
the issues that are brought to your attention and of the standards?

Now please do not tell me that you are a volunteer: we all are
volunteers here and we are all contributing to Free Software in
one way or another.  Being a volunteer is not an excuse for not
paying attention to the technical and human aspects of our
volunteer work.

 > -- Hitler (just to stop this thread)

I don't believe that stopping the thread would solve the problem.
You probably want to say that continuing it would not solve it
either.  This is sad, if it means we have to live with it...
All the best,

     Roberto

-- 
Prof. Roberto Bagnara
Computer Science Group
Department of Mathematics, University of Parma, Italy
http://www.cs.unipr.it/~bagnara/
mailto:bagnara@cs.unipr.it

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Andrew Pinski]

On Jun 16, 2005, at 1:26 PM, Roberto Bagnara wrote:

> First, I would like to clarify I do not consider it rude.
>
> But I do not consider it a good thing that, after this superficial 
> comment
> of yours, you did not even care to reply to my further arguments and 
> question.
> This is precisely the kind of behavior that frustrates me and, I guess,
> frustrates most other bug reporters.

This is not a superficial comment, my whole point with that comment
is that GCC does not __currently__ implement any other rounding mode
than the default one which is not what you want but hey it is what GCC
currently does.

> You said something incorrect ("Note neg just flips a bit so it is 
> correct
> anyways and there is no loss of precession"), then again you failed to 
> reply
> to an explicit question and to further arguments I added.  You also 
> failed
> to reply when I pointed out, in another comment, that this was indeed
> a regression from 3.3.  Then leaving the bug UNCONFIRMED for months...
> OK, you did not have time to check the standard... perhaps it is the
> word "bugmaster" that generates unreasonable expectations.

That is because I said someone else needs to look into it (a C "lawyer"
person who is on the standards committee).  Also again GCC
__currently__ implements one rounding mode and this is current for that
rounding mode.  And actually neg does just a flip a bit according to the
standard.  Now rounding modes are weird and should be implemented in GCC
but __currently__ they are not have not been since day one before there
was a C standard.


For the last one, the warning is correct, yes and is actually useful for
most people.

-- Pinski

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Andrew Pinski]

> 
> 
> On Jun 16, 2005, at 1:26 PM, Roberto Bagnara wrote:
> 
> > First, I would like to clarify I do not consider it rude.
> >
> > But I do not consider it a good thing that, after this superficial 
> > comment
> > of yours, you did not even care to reply to my further arguments and 
> > question.
> > This is precisely the kind of behavior that frustrates me and, I guess,
> > frustrates most other bug reporters.

Oh, only just people who file floating point "bugs" because that is the hardest
to get right in any compiler.

-- Pinski

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Vincent Lefevre]

On 2005-06-16 13:37:23 -0400, Andrew Pinski wrote:
> This is not a superficial comment, my whole point with that comment
> is that GCC does not __currently__ implement any other rounding mode
> than the default one which is not what you want but hey it is what GCC
> currently does.

Based on this comment, shouldn't the bug have been marked as NEW or
SUSPENDED?

-- 
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: Reporting bugs: there is nothing to gain in frustrating reporters

[Mike Stump]

On Thursday, June 16, 2005, at 10:26  AM, Roberto Bagnara wrote:
> OK, you did not have time to check the standard... perhaps it is the
> word "bugmaster" that generates unreasonable expectations.

Think of them as BugMonkeys if it helps.  :-)

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[E. Weddington]

Scott Robert Ladd wrote:

>1) Bugmasters could be less perfunctory and pejorative in their
>comments. Examples have been given.
>
>  
>
<De-lurking>

Quoting ESR these days is perhaps not really in vogue, but I've always 
found this document to be extremely helpful:
<http://www.catb.org/~esr/faqs/smart-questions.html>

Specifically, this section:
<http://www.catb.org/~esr/faqs/smart-questions.html#keepcool>
which I think is very applicable both to bug comments as well as the gcc 
list and this thread in particular. ;-)

>2) A mentoring system could help bring along new GCC developers. I'm not
>talking about hand-holding, I'm suggesting that having some place for
>people to ask a few questions, one on one, to get over certain
>conceptual humps.
>  
>

Geez, I've seen this happen many a time on the gcc list. Jim Wilson, in 
particular, I've noticed does a tremendous job in helping new people out 
by pointing them in the right direction (IMHO). Why should something new 
be created?

Anyway, I'll go back to lurking now.

Eric

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Gabriel Dos Reis]

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

| Giovanni Bajo wrote:
| > Agreed. But keep in mind that it is not necessary to reply: once the bug is
| > open and confirmed, the last comment "wins", in a way. If the bugmaster
| > wanted to close it, he would just do it, so an objection in a comment does
| > not make the bug invalid per se.
| 
| But an objection from one of the bugmasters *is* enough to keep people
| from presenting a patch.

Well, I'm not sure.  If the report is closed, then you're right.
However, if the report is not closed, then I think it often happens
that people who will prepare a patch will look into the report, even
with the comments from a bugmaster.  I know I do it that way, and I
know other people more knowledgeable of GCC tham me do it that way too.
When I find a bugmaster's comment incorrect, I say it for the record.

I think you'd need to be more careful in your generalization.

-- Gaby

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Scott Robert Ladd]

Gabriel Dos Reis wrote:
> Scott Robert Ladd <scott.ladd@coyotegulch.com> writes:
> | But an objection from one of the bugmasters *is* enough to keep people
> | from presenting a patch.
> 
> Well, I'm not sure.  If the report is closed, then you're right.
> However, if the report is not closed, then I think it often happens
> that people who will prepare a patch will look into the report, even
> with the comments from a bugmaster.  I know I do it that way, and I
> know other people more knowledgeable of GCC tham me do it that way too.
> When I find a bugmaster's comment incorrect, I say it for the record.
> 
> I think you'd need to be more careful in your generalization.

More precisely, then:

An objection from one of the bugmasters *is* enough to keep some people
who are new to GCC from presenting a patch.

Ugh. An inelegant sentence, but perhaps more accurate.

..Scott

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Richard Guenther]

On 6/15/05, Scott Robert Ladd <scott.ladd@coyotegulch.com> wrote:
> Gabriel Dos Reis wrote:
> > Scott Robert Ladd <scott.ladd@coyotegulch.com> writes:
> > | But an objection from one of the bugmasters *is* enough to keep people
> > | from presenting a patch.
> >
> > Well, I'm not sure.  If the report is closed, then you're right.
> > However, if the report is not closed, then I think it often happens
> > that people who will prepare a patch will look into the report, even
> > with the comments from a bugmaster.  I know I do it that way, and I
> > know other people more knowledgeable of GCC tham me do it that way too.
> > When I find a bugmaster's comment incorrect, I say it for the record.
> >
> > I think you'd need to be more careful in your generalization.
> 
> More precisely, then:
> 
> An objection from one of the bugmasters *is* enough to keep some people
> who are new to GCC from presenting a patch.
> 
> Ugh. An inelegant sentence, but perhaps more accurate.

May I turn this into a suggestion:  don't be scared away by negative
comments of one of the bugmasters, instead continue working on a
patch; you are definitely encouraged to do so!  And if not the
bugmasters, other people affected by the bug will be grateful!

Thanks,
Richard.

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Scott Robert Ladd]

Richard Guenther wrote:
> May I turn this into a suggestion:  don't be scared away by negative
> comments of one of the bugmasters, instead continue working on a
> patch; you are definitely encouraged to do so!  And if not the
> bugmasters, other people affected by the bug will be grateful!

It's isn't so much a matter of being "scared away" as it is of deciding
where to allocate one's "free" resources.

I prefer to apply my energies to situations where there is a good chance
of success; a negative comment by a bugmaster makes it less likely that
my efforts on that bug will bear fruit. It's a cost-benefit analysis for me.

As for people being grateful -- well, that's why I'm here. Despite
certain people here who have low opinions of my abilities, there are
some folk who appreciate my work.

..Scott

RE: Reporting bugs: there is nothing to gain in frustrating reporters

[Dave Korn]

----Original Message----
>From: Scott Robert Ladd
>Sent: 15 June 2005 18:24

> a negative comment by a bugmaster makes it less likely that
> my efforts on that bug will bear fruit. 


  No, it doesn't.  You seem to be under the impression that bugmasters have
some kind of "power" or "authority" over what does and doesn't happen and
which patches will or will not be accepted.  I think this is a
misunderstanding; it doesn't matter what some bugmaster says or doesn't say,
all that matters is the verdict of the maintainer responsible for the area
of the compiler for which you propose a patch.


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

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Eric Botcazou]

>   No, it doesn't.  You seem to be under the impression that bugmasters have
> some kind of "power" or "authority" over what does and doesn't happen and
> which patches will or will not be accepted.  I think this is a
> misunderstanding; it doesn't matter what some bugmaster says or doesn't
> say, all that matters is the verdict of the maintainer responsible for the
> area of the compiler for which you propose a patch.

Do not underestimate the importance of Bugzilla (hence that of the 
bugmasters): for most users of GCC, it's the only interface to the GCC 
community.

-- 
Eric Botcazou

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Florian Weimer]

* Gabriel Dos Reis:

> Scott Robert Ladd <scott.ladd@coyotegulch.com> writes:
>
> | Giovanni Bajo wrote:
> | > Agreed. But keep in mind that it is not necessary to reply: once the bug is
> | > open and confirmed, the last comment "wins", in a way. If the bugmaster
> | > wanted to close it, he would just do it, so an objection in a comment does
> | > not make the bug invalid per se.
> | 
> | But an objection from one of the bugmasters *is* enough to keep people
> | from presenting a patch.
>
> Well, I'm not sure.  If the report is closed, then you're right.

Not necessarily, wrongly closed reports are reopened in my experience
(and not by the submitter 8-).

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Vincent Lefevre]

On 2005-06-15 21:22:38 +0200, Florian Weimer wrote:
> Not necessarily, wrongly closed reports are reopened in my experience

Not all of them, e.g. bug 323 (yes, again).

-- 
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: Reporting bugs: there is nothing to gain in frustrating reporters

[Andrew Pinski]

On Jun 15, 2005, at 6:14 PM, Vincent Lefevre wrote:

> On 2005-06-15 21:22:38 +0200, Florian Weimer wrote:
>> Not necessarily, wrongly closed reports are reopened in my experience
>
> Not all of them, e.g. bug 323 (yes, again).

But if you look how old it is, it is before really any bugmaster 
started.
Also a main developer, RTH, closed it and he has been working on GCC 
since
before 1999.

Thanks,
Andrew Pinski

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Vincent Lefevre]

On 2005-06-15 18:18:23 -0400, Andrew Pinski wrote:
> But if you look how old it is, it is before really any bugmaster
> started. Also a main developer, RTH, closed it and he has been
> working on GCC since before 1999.

I'm answering that since this is plainly wrong. Bug 21809 was
closed by yourself on 2005-05-29. This is not 1999!

-- 
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: Reporting bugs: there is nothing to gain in frustrating reporters

[Daniel Berlin]

On Thu, 2005-06-16 at 14:08 +0200, Vincent Lefevre wrote:
> On 2005-06-15 18:18:23 -0400, Andrew Pinski wrote:
> > But if you look how old it is, it is before really any bugmaster
> > started. Also a main developer, RTH, closed it and he has been
> > working on GCC since before 1999.
> 
> I'm answering that since this is plainly wrong. Bug 21809 was
> closed by yourself on 2005-05-29. This is not 1999!

You deny that Bug 21809 is the same bug as Bug 323, which was closed in
1999?


Again, this is a place where you disagree that this should be considered
a "bug", but refuse to believe that reasonable people can disagree on
it.

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Haren Visavadia]

--- Daniel Berlin wrote:
> Again, this is a place where you disagree that this
> should be considered
> a "bug", but refuse to believe that reasonable
> people can disagree on
> it.

Well, Vincent has given detailed explaination on his
views.

What do you mean by "reasonable" here?










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

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Daniel Berlin]

On Thu, 2005-06-16 at 13:35 +0100, Haren Visavadia wrote:
> --- Daniel Berlin wrote:
> > Again, this is a place where you disagree that this
> > should be considered
> > a "bug", but refuse to believe that reasonable
> > people can disagree on
> > it.
> 
> Well, Vincent has given detailed explaination on his
> views.
> 
> What do you mean by "reasonable" here?

I mean people who understand the issues involved.
Again, Vincent refuses to believe that anybody who "truly" understands
the issues involved could come to any other conclusion than his.
However, this simply is not true.

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Patrick McFarland]

[-- Attachment #1: Type: text/plain, Size: 623 bytes --]

On Thursday 16 June 2005 08:20 am, Daniel Berlin wrote:
> You deny that Bug 21809 is the same bug as Bug 323, which was closed in
> 1999?

No, clearly, its some form of time travel by aliens wanting to subvert GCC to 
their own evil purposes. Vincent is their leader.

I, for one, welcome our new Lefevrian overlords.

-- 
Patrick "Diablo-D3" McFarland || pmcfarland@downeast.net
"Computer games don't affect kids; I mean if Pac-Man affected us as kids, we'd 
all be running around in darkened rooms, munching magic pills and listening to
repetitive electronic music." -- Kristian Wilson, Nintendo, Inc, 1989

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Mark Hahn]

> > I'm answering that since this is plainly wrong. Bug 21809 was
> > closed by yourself on 2005-05-29. This is not 1999!
> 
> You deny that Bug 21809 is the same bug as Bug 323, which was closed in
> 1999?
> 
> Again, this is a place where you disagree that this should be considered
> a "bug", but refuse to believe that reasonable people can disagree on
> it.

the question then becomes whether GCC is helped or harmed by 
its current policy of unpredictable excess precision.

it's quite unfortunate that gcc responders feel so free to vent
their annoyance about this.  Pinski, for instance, is absurdly 
unhelpful in suggesting that the bug reporter just abandon x87.

again, the problem is well-understood: the lack of predictability of
when excess precision is retained by x87.  the problem is not EP or x87.

the only constructive comment in this thread so far has been that libm
might somehow rely on EP (ie can't use the _FPU_SET_CW workaround).
which code is this?  I'd guess it might be related to using series 
approximations, and the code could either set CW or accept 64b results.

regards, mark hahn.

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Andrew Pinski]

On Jun 16, 2005, at 10:11 AM, Mark Hahn wrote:

>>> I'm answering that since this is plainly wrong. Bug 21809 was
>>> closed by yourself on 2005-05-29. This is not 1999!
>>
>> You deny that Bug 21809 is the same bug as Bug 323, which was closed 
>> in
>> 1999?
>>
>> Again, this is a place where you disagree that this should be 
>> considered
>> a "bug", but refuse to believe that reasonable people can disagree on
>> it.
>
> the question then becomes whether GCC is helped or harmed by
> its current policy of unpredictable excess precision.
>
> it's quite unfortunate that gcc responders feel so free to vent
> their annoyance about this.  Pinski, for instance, is absurdly
> unhelpful in suggesting that the bug reporter just abandon x87.

Well abandoning x87 was a joke, I was trying to get the point across
that this is long standing "problem" with x87.  If you go and search
you will see this comes up every year since at least 1998 before
EGCS was officially GCC.

-- Pinski

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Vincent Lefevre]

On 2005-06-16 12:34:27 -0400, Andrew Pinski wrote:
> Well abandoning x87 was a joke, I was trying to get the point across
> that this is long standing "problem" with x87.  If you go and search
> you will see this comes up every year since at least 1998 before
> EGCS was officially GCC.

In the bug report, it didn't look at the joke. Anyway, one could also
say that floating-point arithmetic (not only binary one) is a long
standing problem. See for instance

  https://bugzilla.mozilla.org/show_bug.cgi?id=5856

and all the duplicates (and this one is really an invalid bug).

-- 
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: Reporting bugs: there is nothing to gain in frustrating reporters

[Vincent Lefevre]

On 2005-06-16 08:20:20 -0400, Daniel Berlin wrote:
> You deny that Bug 21809 is the same bug as Bug 323, which was closed
> in 1999?

Yes: Bug 323 as originally reported is really invalid. The C standard
doesn't guarantee that y and y2 should exactly be the same value.
However bug 21809 (like *some* other bugs duplicated to bug 323) shows
a bug in the compiler, since a variable must not have a precision (or
range) larger than the one specified by the type. A fix is *possible*:
just store the value to memory after a cast or an assignment. Of
course, this wouldn't necessarily be efficient, but there could be
options to allow the compiler to have a non-comforming behavior. Or
the user could get a processor that behaves differently.

Dynamical extended precision is allowed by IEEE-754 and a part of
the specifications of the x86 processors. So, you can't say that
such processors are buggy.

On 2005-06-16 10:11:39 -0400, Mark Hahn wrote:
> the question then becomes whether GCC is helped or harmed by 
> its current policy of unpredictable excess precision.

BTW, unpredictability, such as in bug 323, is not a bug (according
to the C standard). This may be seen as a bad behavior and changing
this behavior would be a great improvement, but I don't complain
about it here when saying "bug".

> the only constructive comment in this thread so far has been that libm
> might somehow rely on EP (ie can't use the _FPU_SET_CW workaround).
> which code is this?  I'd guess it might be related to using series 
> approximations, and the code could either set CW or accept 64b results.

Or the code could be changed: glibc has code that is guaranteed to
work in double precision (modulo some bugs), since it is used on
processors that have no 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: Reporting bugs: there is nothing to gain in frustrating reporters

[Robert Dewar]

Vincent Lefevre wrote:

> BTW, unpredictability, such as in bug 323, is not a bug (according
> to the C standard). This may be seen as a bad behavior and changing
> this behavior would be a great improvement, but I don't complain
> about it here when saying "bug".

Everyone would agree that per se unnecessary non-determinism is a
bad thing. However, most people would also agree that poor performance
is a bad thing.

All this stuff about allowing extra precision is actually about
allowing efficient code.

Lacking in this discussion is a good quantitative measurement
over a reasonable set of benchmarks as to what eliminating the
excess precision in all cases would cost.

Note that just setting the precision to 64-bits is not enough if
you agree with Vincent that 32-bit float variables have to be
normalized on every assignment.

Data would help. Almost everyone will agree with eliminating the
extra precision if it has only a 3% impact, almost everyone
will disagree if it doubles execution time (I suspect the asnwer
is in that range :-)

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Vincent Lefevre]

On 2005-06-16 12:12:26 -0400, Robert Dewar wrote:
> Everyone would agree that per se unnecessary non-determinism is a
> bad thing.

Yes, but not all people would agree on the meaning of "necessary"
(for performance? for security?).

> However, most people would also agree that poor performance
> is a bad thing.

Getting incorrect results is even worse. Anyway a bug isn't invalid
just because fixing it would make the code less efficient.

> All this stuff about allowing extra precision is actually about
> allowing efficient code.
> 
> Lacking in this discussion is a good quantitative measurement
> over a reasonable set of benchmarks as to what eliminating the
> excess precision in all cases would cost.

Why not compile benchmarks with options that allow to keep
extra precision?

Also fixing the bug would not necessarily make code less efficient.
2 solutions:
  * A diagnostic is sufficient.
  * Not declaring that the compiler is conforming to the C standard
    would also be sufficient.

Whether this should be done by default or not could be discussed
later (the behavior could be different depending on FP-related
standard pragmas or options like -std=c99).

> Note that just setting the precision to 64-bits is not enough if
> you agree with Vincent that 32-bit float variables have to be
> normalized on every assignment.

I agree. This would not fix the bug, but make it less visible.
This would thus be an improvement.

> Data would help. Almost everyone will agree with eliminating the
> extra precision if it has only a 3% impact, almost everyone
> will disagree if it doubles execution time (I suspect the asnwer
> is in that range :-)

What about having the choice?

Anyway, if the only reason is the performance, then the bug shouldn't
have been marked as INVALID (the SUSPENDED status is for such kind of
problems -- and SUSPENDED doesn't mean that the bug is resolved).

-- 
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: Reporting bugs: there is nothing to gain in frustrating reporters

[Robert Dewar]

Vincent Lefevre wrote:

> What about having the choice?

That's fine, provided there are really well defined semantic
rules for what the options do, these options need designing
by people who are experts in floating-point semantics.

> Anyway, if the only reason is the performance, then the bug shouldn't
> have been marked as INVALID (the SUSPENDED status is for such kind of
> problems -- and SUSPENDED doesn't mean that the bug is resolved).

As you well know, not everyone agrees this is a bug, and this does
not have to do with performance. Saying over and over again that you
think it is a bug does not make it so.

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Vincent Lefevre]

On 2005-06-16 17:54:03 -0400, Robert Dewar wrote:
> As you well know, not everyone agrees this is a bug, and this does
> not have to do with performance. Saying over and over again that you
> think it is a bug does not make it so.

I haven't seen any correct argument why it could not be a bug.
Saying that the x86 processor is buggy is just completely silly.
Only some gcc developers think so.

-- 
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: Reporting bugs: there is nothing to gain in frustrating reporters

[Patrick McFarland]

[-- Attachment #1: Type: text/plain, Size: 487 bytes --]

On Saturday 18 June 2005 02:52 am, Vincent Lefevre wrote:
> Saying that the x86 processor is buggy is just completely silly.
> Only some gcc developers think so.

Yeah, the smart ones.

-- 
Patrick "Diablo-D3" McFarland || pmcfarland@downeast.net
"Computer games don't affect kids; I mean if Pac-Man affected us as kids, we'd 
all be running around in darkened rooms, munching magic pills and listening to
repetitive electronic music." -- Kristian Wilson, Nintendo, Inc, 1989

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Mattias Karlsson]

On Sat, 18 Jun 2005, Vincent Lefevre wrote:

> On 2005-06-16 17:54:03 -0400, Robert Dewar wrote:
>> As you well know, not everyone agrees this is a bug, and this does
>> not have to do with performance. Saying over and over again that you
>> think it is a bug does not make it so.
>
> I haven't seen any correct argument why it could not be a bug.
> Saying that the x86 processor is buggy is just completely silly.
> Only some gcc developers think so.
>

Don't know about you, but I consider any processor that is unable to store 
a register to memory and then read back the same value to be buggy.

Sure, you can change rounding precision but according to my 2003 version 
of "IA-32 Intel(r) Architecture Software Developer's Manual - Volume 
1: Basic Architecture"
  a) That takes at least 4 instructions.
  b) Only affects some instructions, and then only the result.
  c) Only affects the significand and not the exponent.

Disclaimer: I haven't done any testing to verify that this is actually the 
case since I have no access to x86 hardware.

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Sylvain Pion]

On Sat, Jun 18, 2005 at 12:54:40PM +0200, Mattias Karlsson wrote:
> On Sat, 18 Jun 2005, Vincent Lefevre wrote:
> 
> >On 2005-06-16 17:54:03 -0400, Robert Dewar wrote:
> >>As you well know, not everyone agrees this is a bug, and this does
> >>not have to do with performance. Saying over and over again that you
> >>think it is a bug does not make it so.
> >
> >I haven't seen any correct argument why it could not be a bug.
> >Saying that the x86 processor is buggy is just completely silly.
> >Only some gcc developers think so.
> 
> Don't know about you, but I consider any processor that is unable to store 
> a register to memory and then read back the same value to be buggy.

That would indeed be a funny kind of processor, but x86 can store its
registers in memory exactly : simply store/reread them as long doubles.

> Sure, you can change rounding precision but according to my 2003 version 
> of "IA-32 Intel(r) Architecture Software Developer's Manual - Volume 
> 1: Basic Architecture"
>  a) That takes at least 4 instructions.
>  b) Only affects some instructions, and then only the result.
>  c) Only affects the significand and not the exponent.
> 
> Disclaimer: I haven't done any testing to verify that this is actually the 
> case since I have no access to x86 hardware.

-- 
Sylvain

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Robert Dewar]

Sylvain Pion wrote:

> That would indeed be a funny kind of processor, but x86 can store its
> registers in memory exactly : simply store/reread them as long doubles.

There was indeed a processor (I think by Honeywell) where the fpt accumulator
had extra precision bits that could not be stored in memory. The result was
that an interrupt could cause those bits to be randomly lost. Now *that* was
a fpt processor you could complain about :-)

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Robert Dewar]

Mattias Karlsson wrote:

> Don't know about you, but I consider any processor that is unable to 
> store a register to memory and then read back the same value to be buggy.

THe x86/x87 does not violate this requirement

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Mattias Karlsson]

On Sat, 18 Jun 2005, Robert Dewar wrote:

> Mattias Karlsson wrote:
>
>> Don't know about you, but I consider any processor that is unable to store 
>> a register to memory and then read back the same value to be buggy.
>
> THe x86/x87 does not violate this requirement

In my Obi-Wan-Point-Of-View it does. :-)


This entire debate comes from one thing: currently floating point has 
always type long double untill stored to memory, regardless of 
user-specified type. At -O1 this becomes more or less non-deterministic.

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Robert Dewar]

Mattias Karlsson wrote:
> On Sat, 18 Jun 2005, Robert Dewar wrote:
> 
>> Mattias Karlsson wrote:
>>
>>> Don't know about you, but I consider any processor that is unable to 
>>> store a register to memory and then read back the same value to be 
>>> buggy.
>>
>>
>> THe x86/x87 does not violate this requirement

> In my Obi-Wan-Point-Of-View it does. :-)

Well I think it is inapprorpiate to assign erroneous points of
view to Obi-Wan :-) Once again, on the x86/x87 the process IS "able
to store a register to memory and then read back the same value".
ANy claim to the contrary is ill-informed.

> This entire debate comes from one thing: currently floating point has 
> always type long double untill stored to memory, regardless of 
> user-specified type. At -O1 this becomes more or less non-deterministic.

Yes, right, but that is a different issue from being able to store
a register to memory and then read back the same value.

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Mattias Karlsson]

On Sat, 18 Jun 2005, Robert Dewar wrote:

> Mattias Karlsson wrote:
>> On Sat, 18 Jun 2005, Robert Dewar wrote:
>> 
>>> Mattias Karlsson wrote:
>>> 
>>>> Don't know about you, but I consider any processor that is unable to 
>>>> store a register to memory and then read back the same value to be buggy.
>>> 
>>> 
>>> THe x86/x87 does not violate this requirement
>
>> In my Obi-Wan-Point-Of-View it does. :-)
>
> Well I think it is inapprorpiate to assign erroneous points of
> view to Obi-Wan :-) Once again, on the x86/x87 the process IS "able
> to store a register to memory and then read back the same value".
> ANy claim to the contrary is ill-informed.
>
>> This entire debate comes from one thing: currently floating point has 
>> always type long double untill stored to memory, regardless of 
>> user-specified type. At -O1 this becomes more or less non-deterministic.
>
> Yes, right, but that is a different issue from being able to store
> a register to memory and then read back the same value.

I confess of being overly generic, and quite fuzzy about my point.


Anyway my point of view is that the solution to anyone needing strict IEEE 
semantics are:
1) Use -float-store
2) Use sse math
3) Learn to live without it.

Since the "gcc-is-buggy" solution of changing x87 rounding modes will:
1) Be a lot of work.
2) Cause a lot of regressions.

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Robert Dewar]

Mattias Karlsson wrote:

> Since the "gcc-is-buggy" solution of changing x87 rounding modes will:
> 1) Be a lot of work.
> 2) Cause a lot of regressions.

To this you can add

   3) generate less efficient code
   4) cause some algorithms that work now to fail

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Laurent GUERBY]

On Sat, 2005-06-18 at 16:45 -0400, Robert Dewar wrote:
> Mattias Karlsson wrote:
> 
> > Since the "gcc-is-buggy" solution of changing x87 rounding modes will:
> > 1) Be a lot of work.
> > 2) Cause a lot of regressions.
> 
> To this you can add
> 
>    3) generate less efficient code

Changing the default rounding of the processor will make code less
efficient?

Laurent

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Robert Dewar]

Laurent GUERBY wrote:
> On Sat, 2005-06-18 at 16:45 -0400, Robert Dewar wrote:
> 
>>Mattias Karlsson wrote:
>>
>>
>>>Since the "gcc-is-buggy" solution of changing x87 rounding modes will:
>>>1) Be a lot of work.
>>>2) Cause a lot of regressions.
>>
>>To this you can add
>>
>>   3) generate less efficient code
> 
> 
> Changing the default rounding of the processor will make code less
> efficient?
> 
> Laurent

Yes, if you have to change it backwards and forwards for float and
double ... and if you insist on getting the range right as well as
the precision, then you have to do extra stores. Changing the
rounding mode alone does not give what people call IEEE behavior.

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Laurent GUERBY]

On Sat, 2005-06-18 at 17:37 -0400, Robert Dewar wrote:
> > Changing the default rounding of the processor will make code less
> > efficient?

> Yes, if you have to change it backwards and forwards for float and
> double 

Quite rare. Only usage I've seen is for tabulation when you want
to save storage space but there it won't be an issue since you're
explicitely storing to memory.

> ... and if you insist on getting the range right as well as
> the precision, then you have to do extra stores. 

If you code run in extra range issue then you'll get "expected"
results on x86 and it will fail everywhere else, a nice
way to detect those issues indeed (and you won't face
this if you developped your code on non x86).

> Changing the rounding mode alone does not give what people call IEEE behavior.

I agree, but in 99.9% of the case it will do what people expect.
For the remaining 0.1% of the case, we're facing expert code and
experts can look into the magic manual and find the right 
flags/pragma/libraries/whatever :).

Anyway, default situation is unlikely to change, and x86_64 ABI
default to SSE2 plus it will soon be hard to find reasonably powerful
x86 only harware out there...

Laurent

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Robert Dewar]

Laurent GUERBY wrote:
> On Sat, 2005-06-18 at 17:37 -0400, Robert Dewar wrote:
> 
>>>Changing the default rounding of the processor will make code less
>>>efficient?
> 
> 
>>Yes, if you have to change it backwards and forwards for float and
>>double 
> 
> 
> Quite rare. Only usage I've seen is for tabulation when you want
> to save storage space but there it won't be an issue since you're
> explicitely storing to memory.
> 
> 
>>... and if you insist on getting the range right as well as
>>the precision, then you have to do extra stores. 
> 
> 
> If you code run in extra range issue then you'll get "expected"
> results on x86 and it will fail everywhere else, a nice
> way to detect those issues indeed (and you won't face
> this if you developped your code on non x86).

That's not right, your algorithm may expect infinities in certain
ranges, handle them right, and blow up if they are not generated,
and vice versa. IEEE = IEEE, not some approximation thereof.

>>Changing the rounding mode alone does not give what people call IEEE behavior.

> I agree, but in 99.9% of the case it will do what people expect.
> For the remaining 0.1% of the case, we're facing expert code and
> experts can look into the magic manual and find the right 
> flags/pragma/libraries/whatever :).

Right, but formal definition of what it means to be right
99.9% of the time is tricky. In practice, I would guess that
gcc is right for most people 99.9% of the time as it is.

> Anyway, default situation is unlikely to change, and x86_64 ABI
> default to SSE2 plus it will soon be hard to find reasonably powerful
> x86 only harware out there...

Right, though it is a tremendous advantage of the ia32 (and ia64)
architectures that they *do* have efficient implementations of
IEEE extended, which is rare on other processors.
> 
> Laurent
> 

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Vincent Lefevre]

On 2005-06-18 18:01:33 -0400, Robert Dewar wrote:
> Laurent GUERBY wrote:
> >If you code run in extra range issue then you'll get "expected"
> >results on x86 and it will fail everywhere else, a nice
> >way to detect those issues indeed (and you won't face
> >this if you developped your code on non x86).
> 
> That's not right, your algorithm may expect infinities in certain
> ranges, handle them right, and blow up if they are not generated,
> and vice versa. IEEE = IEEE, not some approximation thereof.

I don't understand your "IEEE = IEEE". To make things clearer:
IEEE 754 explicitly allows an extended exponent range. The ISO C
language doesn't. But this can be solved by stores, then there
wouldn't by any problem as far as the standards are concerned.

-- 
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: Reporting bugs: there is nothing to gain in frustrating reporters

[Gabriel Dos Reis]

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

| I don't understand your "IEEE = IEEE". To make things clearer:
| IEEE 754 explicitly allows an extended exponent range. The ISO C
| language doesn't. But this can be solved by stores, then there
| wouldn't by any problem as far as the standards are concerned.

Vincent --

  I recommend you google GCC's archive for past discussions on this
issue.  This is not the first time it is being discussed.  If I
remember correctly, core back-end people looked at it and concluded
that fixing it requires a *major* rewrite of the back-end, if at all
possible [1].  I read your paragraph above as suggesting that it would
be simple thing to fix.  It would be wonderful if that is true; would
you mind submitting a patch?

[1]:  http://gcc.gnu.org/ml/gcc/2003-08/msg01234.html
      http://gcc.gnu.org/ml/gcc/2003-08/msg01257.html

--- Gaby

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Vincent Lefevre]

On 2005-06-19 11:42:04 +0200, Gabriel Dos Reis wrote:
> Vincent Lefevre <vincent+gcc@vinc17.org> writes:
> 
> | I don't understand your "IEEE = IEEE". To make things clearer:
> | IEEE 754 explicitly allows an extended exponent range. The ISO C
> | language doesn't. But this can be solved by stores, then there
> | wouldn't by any problem as far as the standards are concerned.
> 
> Vincent --
> 
>   I recommend you google GCC's archive for past discussions on this
> issue.  This is not the first time it is being discussed.  If I
> remember correctly, core back-end people looked at it and concluded
> that fixing it requires a *major* rewrite of the back-end, if at all
> possible [1].

OK, I'm not saying that this is simple. I'm just saying that it *can*
be solved. Even if the fix is complex, it is not a reason to mark the
bug 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: Reporting bugs: there is nothing to gain in frustrating reporters

[Gabriel Dos Reis]

Robert Dewar <dewar@adacore.com> writes:

| Laurent GUERBY wrote:
| > On Sat, 2005-06-18 at 16:45 -0400, Robert Dewar wrote:
| >
| >>Mattias Karlsson wrote:
| >>
| >>
| >>>Since the "gcc-is-buggy" solution of changing x87 rounding modes will:
| >>>1) Be a lot of work.
| >>>2) Cause a lot of regressions.
| >>
| >>To this you can add
| >>
| >>   3) generate less efficient code
| > Changing the default rounding of the processor will make code less
| > efficient?
| > Laurent
| 
| Yes, if you have to change it backwards and forwards for float and
| double

I suspect the real question is which kind of codes and how they are
representative. 


-- Gaby

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Robert Dewar]

Gabriel Dos Reis wrote:

> I suspect the real question is which kind of codes and how they are
> representative. 

Absolutely, and my general rule is that optimizations are disappointing,
which has a corrolary that removing an optimization is not necessarily
disappointing in terms of performance :-) And we really don't have good
data on this issue.

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Vincent Lefevre]

On 2005-06-18 16:45:06 -0400, Robert Dewar wrote:
> Mattias Karlsson wrote:
> 
> >Since the "gcc-is-buggy" solution of changing x87 rounding modes will:
> >1) Be a lot of work.
> >2) Cause a lot of regressions.
> 
> To this you can add
> 
>   3) generate less efficient code

Not by changing the rounding precision. Anyway this is not the point
here (i.e. to consider where the bug comes from).

>   4) cause some algorithms that work now to fail

Only non-portable ones (those designed for extended precision only).
And portable algorithms that didn't work will work after the fix.

-- 
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: Reporting bugs: there is nothing to gain in frustrating reporters

[Vincent Lefevre]

On 2005-06-18 15:51:50 +0200, Mattias Karlsson wrote:
> Anyway my point of view is that the solution to anyone needing
> strict IEEE semantics are:

You are wrong. IEEE allows extended precision. We are talking about
*ISO C99* semantics.

> 1) Use -float-store

Note: -ffloat-store. This is not a solution as it doesn't affect casts
(I haven't checked, but it was said by several GCC developers).

> 2) Use sse math

Not available everywhere, and not the default everywhere even when it
is available.

> 3) Learn to live without it.

Learn to live with buggy compilers?

> Since the "gcc-is-buggy" solution of changing x87 rounding modes will:
> 1) Be a lot of work.
> 2) Cause a lot of regressions.

This remains to see. BTW, the Opteron uses SSE by default. Did you see
a lot of regressions?

Other solutions that would fix the bug (but not ultimate solutions):
1) Do not claim that gcc is a conforming ISO C implementation.
2) Output a diagnostic.

-- 
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: Reporting bugs: there is nothing to gain in frustrating reporters

[Mattias Karlsson]

On Sun, 19 Jun 2005, Vincent Lefevre wrote:

>> Since the "gcc-is-buggy" solution of changing x87 rounding modes will:
>> 1) Be a lot of work.
>> 2) Cause a lot of regressions.
>
> This remains to see. BTW, the Opteron uses SSE by default. Did you see
> a lot of regressions?

Opteron is not an issue, when I talked about regressions above I dont mean 
only "My code give a diffrent answer" regressions but also "My code that 
uses both float/doubles is bigger and slower"

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Vincent Lefevre]

On 2005-06-19 10:59:24 +0200, Mattias Karlsson wrote:
> On Sun, 19 Jun 2005, Vincent Lefevre wrote:
> 
> >>Since the "gcc-is-buggy" solution of changing x87 rounding modes will:
> >>1) Be a lot of work.
> >>2) Cause a lot of regressions.
> >
> >This remains to see. BTW, the Opteron uses SSE by default. Did you see
> >a lot of regressions?
> 
> Opteron is not an issue, when I talked about regressions above I
> dont mean only "My code give a diffrent answer" regressions but also
> "My code that uses both float/doubles is bigger and slower"

Not by the proposed solution "of changing x87 rounding modes".
Of course, this solution is not sufficient to completely fix the
bug (due to the exponent range), but it would solve most problems.
And concerning the solution with stores, then users would have to
learn to use compiler options. BTW, in this way, they could even
learn the existence of -ffast-math and have smaller and faster
programs! :)

-- 
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: Reporting bugs: there is nothing to gain in frustrating reporters

[Mattias Karlsson]

On Sun, 19 Jun 2005, Vincent Lefevre wrote:

>>>> Since the "gcc-is-buggy" solution of changing x87 rounding modes will:
>>>> 1) Be a lot of work.
>>>> 2) Cause a lot of regressions.
>>>
>>> This remains to see. BTW, the Opteron uses SSE by default. Did you see
>>> a lot of regressions?
>>
>> Opteron is not an issue, when I talked about regressions above I
>> dont mean only "My code give a diffrent answer" regressions but also
>> "My code that uses both float/doubles is bigger and slower"
>
> Not by the proposed solution "of changing x87 rounding modes".
> Of course, this solution is not sufficient to completely fix the
> bug (due to the exponent range), but it would solve most problems.
> And concerning the solution with stores, then users would have to
> learn to use compiler options. BTW, in this way, they could even
> learn the existence of -ffast-math and have smaller and faster
> programs! :)

True, more people should try -ffast-math since on x87 it can give them 
more precisison and not less, with the nasty non-deterministic loss of 
that extra precission.


On the other hand, sysadmins refuse to install gcc versions past 3.3 at my 
institution (gcc is the default and only compiler available to students 
on non-windows machines) since "It's not binary compatible, and then we 
need an costly OS update". True, ABI changed in 3.3 but reading PR's I see 
that it only affects 64-bit code, and 64-bit libraries are not available 
anyway.

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Gabriel Dos Reis]

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

| On 2005-06-19 10:59:24 +0200, Mattias Karlsson wrote:
| > On Sun, 19 Jun 2005, Vincent Lefevre wrote:
| > 
| > >>Since the "gcc-is-buggy" solution of changing x87 rounding modes will:
| > >>1) Be a lot of work.
| > >>2) Cause a lot of regressions.
| > >
| > >This remains to see. BTW, the Opteron uses SSE by default. Did you see
| > >a lot of regressions?
| > 
| > Opteron is not an issue, when I talked about regressions above I
| > dont mean only "My code give a diffrent answer" regressions but also
| > "My code that uses both float/doubles is bigger and slower"
| 
| Not by the proposed solution "of changing x87 rounding modes".
| Of course, this solution is not sufficient to completely fix the
| bug (due to the exponent range), but it would solve most problems.

since you seem OK with that solution, would you mind preparing a patch?
(discussions are not executables; someone needs to make things happen.) 

-- Gaby

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Vincent Lefevre]

On 2005-06-19 11:47:16 +0200, Gabriel Dos Reis wrote:
> since you seem OK with that solution, would you mind preparing a patch?
> (discussions are not executables; someone needs to make things happen.) 

This is complete non-sense. One doesn't prepare a patch for an invalid
bug.

-- 
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: Reporting bugs: there is nothing to gain in frustrating reporters

[Steven Bosscher]

On Jun 19, 2005 12:55 PM, Vincent Lefevre <vincent+gcc@vinc17.org> wrote:

> On 2005-06-19 11:47:16 +0200, Gabriel Dos Reis wrote:
> > since you seem OK with that solution, would you mind preparing a patch?
> > (discussions are not executables; someone needs to make things happen.) 
> 
> This is complete non-sense. One doesn't prepare a patch for an invalid
> bug.

What exactly do you want to _achieve_ with this thread?  Please, do tell,
because you've completely lost most of us by now, I'm sure.

I have re-closed PR323 now as SUSPENDED instead of INVALID because I find
the messages from Jim Wilson, that Gaby pointed us to, convincing enough
to admit that the problem is _also_ with gcc and not just with the x87
hardware. With a little serious effort on your part, you could have found
those messages as well.

But I'm fed up with the way you're participating in this discussion.  In
this mail I'm replying to, you say you don't want to prepare a patch for
a bug that is marked INVALID. But in your previous mail, and throughout
this discussion, you are arguing that the bug should not be marked INVALID
to begin with.

So by all means, pretty _please_, get your story consistent or quit arguing.
And frankly, I _do_ expect a patch from you, now that PR323 is no longer
marked invalid.  If you don't post a patch, that will be the ultimate proof
that you are just trolling here.

Gr.
Steven

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Vincent Lefevre]

On 2005-06-19 13:16:33 +0200, Steven Bosscher wrote:
> What exactly do you want to _achieve_ with this thread?  Please, do tell,
> because you've completely lost most of us by now, I'm sure.

Just that the problem should be considered as a bug, and not a bug
in the users' code (for some of them), nor a bug in x86 (a bad design
if you want).

> I have re-closed PR323 now as SUSPENDED instead of INVALID because I find

Thank you very much. Note that you're "re-closed" is incorrect because
a SUSPENDED bug is still open (but suspended); look at bugzilla's
documentation... This is important for the above reasons and also
because users will be able to see this bug when searching on bugzilla
(let's hope that this will reduce future duplicates).

> the messages from Jim Wilson, that Gaby pointed us to, convincing
> enough to admit that the problem is _also_ with gcc and not just
> with the x87 hardware. With a little serious effort on your part,
> you could have found those messages as well.

Well, there have been many useful comments in PR323 and duplicates,
but have always been ignored.

> But I'm fed up with the way you're participating in this discussion.  In
> this mail I'm replying to, you say you don't want to prepare a patch for
> a bug that is marked INVALID. But in your previous mail, and throughout
> this discussion, you are arguing that the bug should not be marked INVALID
> to begin with.

There's no contradiction. The bug shouldn't be marked as INVALID,
and there shouldn't be patches as long as it is marked as INVALID.
That's what I meant.

> So by all means, pretty _please_, get your story consistent or quit
> arguing. And frankly, I _do_ expect a patch from you, now that PR323
> is no longer marked invalid. If you don't post a patch, that will be
> the ultimate proof that you are just trolling here.

No, because as some other users said too, INVALID bugs make people
don't feel the need to write patches. Now, *if* I write a patch
(fixing the bug in some way), will it be accepted, even if people
don't like it? (If they don't like it, they could write a better
patch after all.)

-- 
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: Reporting bugs: there is nothing to gain in frustrating reporters

[Andrew Pinski]

> Thank you very much. Note that you're "re-closed" is incorrect because
> a SUSPENDED bug is still open (but suspended); look at bugzilla's
> documentation... This is important for the above reasons and also
> because users will be able to see this bug when searching on bugzilla
> (let's hope that this will reduce future duplicates).

Note this bug was not marked as invalid by some random bug master
but by RTH, one of the core GCC developers, and there was a reason
why it was because it is a bug which cannot fixed so easily.  Maybe
will not fix would be better but since at the time, we using gnats
which did not have "will not fix", it got marked as invalid instead.
Also note the description of this "bug" is on the non-bug part of
the bug reporting page and we still get dups.  In fact we get dups
of other real non-bugs dealing with C/C++ aliasing rule violation
so we will still get bugs for this one too.

Quote from bugs.html:

Problems with floating point numbers - the most often reported non-bug.


In a number of cases, GCC appears to perform floating point 
computations incorrectly. For example, the C++ program

#include <iostream>

int main()
{
   double a = 0.5;
   double b = 0.01;
   std::cout << (int)(a / b) << std::endl;
   return 0;
}



might print 50 on some systems and optimization levels, and 49 on 
others.


This is the result of rounding: The computer cannot represent all real 
numbers exactly, so it has to use approximations. When computing with 
approximation, the computer needs to round to the nearest representable 
number.


This is not a bug in the compiler, but an inherent limitation of the 
floating point types. Please study this paper for more information.

-- Pinski

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Gabriel Dos Reis]

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

| On 2005-06-19 13:16:33 +0200, Steven Bosscher wrote:
| > What exactly do you want to _achieve_ with this thread?  Please, do tell,
| > because you've completely lost most of us by now, I'm sure.
| 
| Just that the problem should be considered as a bug, and not a bug
| in the users' code (for some of them), nor a bug in x86 (a bad design
| if you want).
| 
| > I have re-closed PR323 now as SUSPENDED instead of INVALID because I find
| 
| Thank you very much. Note that you're "re-closed" is incorrect because
| a SUSPENDED bug is still open (but suspended); look at bugzilla's
| documentation... This is important for the above reasons and also
| because users will be able to see this bug when searching on bugzilla
| (let's hope that this will reduce future duplicates).

Vincent --
   
   You can make a difference by helping yourself, creating a bugzilla
account, adding comments and modifying PR status based on informed facts.

[...]

| There's no contradiction. The bug shouldn't be marked as INVALID,
| and there shouldn't be patches as long as it is marked as INVALID.
| That's what I meant.

Is that a GCC development policy or a new rule you would like people
to adopt?

-- Gaby

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Gabriel Dos Reis]

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

| On 2005-06-19 11:47:16 +0200, Gabriel Dos Reis wrote:
| > since you seem OK with that solution, would you mind preparing a patch?
| > (discussions are not executables; someone needs to make things happen.) 
| 
| This is complete non-sense. One doesn't prepare a patch for an invalid
| bug.

If you think it is an invalid bug, then it effectively is a complete
non-sense that you continue making noise on this list about it. 
FWIW, I would remind you that this is not news:fr.comp.lang.c.

-- Gaby

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Vincent Lefevre]

On 2005-06-19 15:47:58 +0200, Gabriel Dos Reis wrote:
> If you think it is an invalid bug, then it effectively is a complete
> non-sense that you continue making noise on this list about it. 

I've never said that I thought it was an invalid bug.

> FWIW, I would remind you that this is not news:fr.comp.lang.c.

I remind it you too.

-- 
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: Reporting bugs: there is nothing to gain in frustrating reporters

[Gabriel Dos Reis]

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

| On 2005-06-19 15:47:58 +0200, Gabriel Dos Reis wrote:
| > If you think it is an invalid bug, then it effectively is a complete
| > non-sense that you continue making noise on this list about it. 
| 
| I've never said that I thought it was an invalid bug.

Then, care to explain

   On 2005-06-19 11:47:16 +0200, Gabriel Dos Reis wrote:
   > since you seem OK with that solution, would you mind preparing a patch?
   > (discussions are not executables; someone needs to make things happen.) 

   This is complete non-sense. One doesn't prepare a patch for an invalid
   bug.

?

-- Gaby

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Michael Veksler]

gcc-owner@gcc.gnu.org wrote on 19/06/2005 18:33:55:

> Vincent Lefevre <vincent+gcc@vinc17.org> writes:
>
> | On 2005-06-19 15:47:58 +0200, Gabriel Dos Reis wrote:
> | > If you think it is an invalid bug, then it effectively is a complete
> | > non-sense that you continue making noise on this list about it.
> |
> | I've never said that I thought it was an invalid bug.
>
> Then, care to explain
>
>    On 2005-06-19 11:47:16 +0200, Gabriel Dos Reis wrote:
>    > since you seem OK with that solution, would you mind preparing a
patch?
>    > (discussions are not executables; someone needs to make things
happen.)
>
>    This is complete non-sense. One doesn't prepare a patch for an invalid
>    bug.
>
> ?
>
> -- Gaby

I think that what Vincent meant was:
"One doesn't prepare a patch for a PR marked as INVALID".

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Gabriel Dos Reis]

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

| gcc-owner@gcc.gnu.org wrote on 19/06/2005 18:33:55:
| 
| > Vincent Lefevre <vincent+gcc@vinc17.org> writes:
| >
| > | On 2005-06-19 15:47:58 +0200, Gabriel Dos Reis wrote:
| > | > If you think it is an invalid bug, then it effectively is a complete
| > | > non-sense that you continue making noise on this list about it.
| > |
| > | I've never said that I thought it was an invalid bug.
| >
| > Then, care to explain
| >
| >    On 2005-06-19 11:47:16 +0200, Gabriel Dos Reis wrote:
| >    > since you seem OK with that solution, would you mind preparing a
| patch?
| >    > (discussions are not executables; someone needs to make things
| happen.)
| >
| >    This is complete non-sense. One doesn't prepare a patch for an invalid
| >    bug.
| >
| > ?
| >
| > -- Gaby
| 
| I think that what Vincent meant was:
| "One doesn't prepare a patch for a PR marked as INVALID".

Then let me explain my previous message.  Either

  (1) Vincent thinks it is an invalid bug, then

         http://gcc.gnu.org/ml/gcc/2005-06/msg00818.html

  (2) or Vincent thinks it is NOT an invalid bug, then

         http://gcc.gnu.org/ml/gcc/2005-06/msg00803.html

Vincent can help himself changing the status of PRs, based on informed
facts. And in effect, that just happened to that very PR.  If the only
thing that was stopping him from producing a patch was the status of
the PR, then now that it changed I expect patch from him. 

-- Gaby

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Michael Veksler]

[Gaby wants Vincent to explain:]
Vincent Lefevre <vincent+gcc@vinc17.org> writes:
#  This is complete non-sense. One doesn't prepare a patch for an invalid
#  bug.

[Michael tries to interpret Vincent:]
| I think that what Vincent meant was:
| "One doesn't prepare a patch for a PR marked as INVALID".


Gabriel Dos Reis wrote on 19/06/2005 19:06:13:
> Then let me explain my previous message.  Either
>
>   (1) Vincent thinks it is an invalid bug, then
>
>          http://gcc.gnu.org/ml/gcc/2005-06/msg00818.html
>
>   (2) or Vincent thinks it is NOT an invalid bug, then
>
>          http://gcc.gnu.org/ml/gcc/2005-06/msg00803.html
>

I don't see a contradiction. All he is trying to say that it is
a valid bug marked as INVALID. His claims that a patch will
be ignored if the PR is marked as INVALID make sense to me.

> Vincent can help himself changing the status of PRs, based on informed
> facts. And in effect, that just happened to that very PR.  If the only
> thing that was stopping him from producing a patch was the status of
> the PR, then now that it changed I expect patch from him.
>
I tend to agree with Vincent's view by not with his tone.
More than one PR that I opened (or its duplicate) were closed,
reopened (by me or others), and then closed again without
a serious discussion.
For example, PR 21951. Unfortunately, Bugzilla hides the history of
close / reopen so you can't see where exactly the bug changed
status back to NEW.


It is frustrating to discuss a validity of a PR in the following manner:

  Reporter:     bug description X
  Bug master: not a bug.    INVALID.
  Reporter: a bug because Y.   REOPEN.
  Bug master: not a bug because Z.   INVALID.
  Reported: a bug, here is an example.   REOPEN.
Assuming Reporter is "lucky":
  Bug master: Well, is guess it is a bug. (Title changed).


Despite being descriptive and friendly, bug masters
frustrate me and other users by being too eager
to close the PR. I would suggest a policy change,
a PR should be closed (as duplicate or as INVALID)
only after discussion was exhausted.

Instead of:
  Reporter:     bug description X
  Bug master: not a bug.    INVALID.

Try to do:
  Reporter:     bug description X
  Bug master: I think it is not a bug, because.
  Reporter: a bug because Y.
  Bug master: I disagree, because Z.
[no reply within 2 days]
  Bug master: INVALID



     Michael

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Steven Bosscher]

On Jun 20, 2005 09:51 AM, Michael Veksler <VEKSLER@il.ibm.com> wrote:

> Despite being descriptive and friendly, bug masters
> frustrate me and other users by being too eager
> to close the PR. I would suggest a policy change,
> a PR should be closed (as duplicate or as INVALID)
> only after discussion was exhausted.

And you going to provide the extra man-power required to track bugs this
way, right? This means keeping an eye on many more bugs where a discussion
is still going on. Unless you have convincing proof that it happens often
that valid bugs are closed as INVALID, I think we should change nothing,

I have seen a discussion similar to your description of a bug discussion
only once, and in this case the bug master was right. It is equally
frustrating for gcc bugmasters that some user thinks it is OK to keep
re-opening a bug report because his/her opinion is The One Opinion. This
is something that happens a lot. "There is nothing to gain in frustrating
bugmasters" ;-)

Maybe every once in a while a bugmaster closes a bug report too quickly, but
at least the bugmasters get a useful job done.  If you compare the state of
our bug database now with the mess of a couple of years ago, we are much
better off now.

Gr.
Steven

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Michael Veksler]

Steven Bosscher <stevenb@suse.de> wrote on 20/06/2005 11:13:35:

> On Jun 20, 2005 09:51 AM, Michael Veksler <VEKSLER@il.ibm.com> wrote:
>
> > Despite being descriptive and friendly, bug masters
> > frustrate me and other users by being too eager
> > to close the PR. I would suggest a policy change,
> > a PR should be closed (as duplicate or as INVALID)
> > only after discussion was exhausted.
>
> And you going to provide the extra man-power required to track bugs this
> way, right? This means keeping an eye on many more bugs where a
discussion
> is still going on. Unless you have convincing proof that it happens often
> that valid bugs are closed as INVALID, I think we should change nothing,

You are probably right that it will take extra person-power (even
after automating part of the process).

>
> I have seen a discussion similar to your description of a bug discussion
> only once, and in this case the bug master was right. It is equally
> frustrating for gcc bugmasters that some user thinks it is OK to keep
> re-opening a bug report because his/her opinion is The One Opinion. This
> is something that happens a lot. "There is nothing to gain in frustrating
> bugmasters" ;-)
>

Look at PR 21951 for such a discussion that ended up NEW.
I also have users, and I am also get frustrated by repeated bogus
bug reports when the user is to blame. I have learnt that it is
simpler and more efficient to teach few coders to be tolerant
(and not easily frustrated), than to teach many users.

It is probably an axiom that at least one person is going to
be frustrated in a big enough community (GCC). The processes
of the community should minimize the amount, the cost
and the impact of such frustration. It is a fine balance to be
maintained.

> Maybe every once in a while a bugmaster closes a bug report too quickly,
but
> at least the bugmasters get a useful job done.  If you compare the state
of
> our bug database now with the mess of a couple of years ago, we are much
> better off now.
>

It is much better now than what it used to be, can it be even better?
Is it cost efficient? I really can't tell.


   Michael

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Gabriel Dos Reis]

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

| [Gaby wants Vincent to explain:]
| Vincent Lefevre <vincent+gcc@vinc17.org> writes:
| #  This is complete non-sense. One doesn't prepare a patch for an invalid
| #  bug.
| 
| [Michael tries to interpret Vincent:]
| | I think that what Vincent meant was:
| | "One doesn't prepare a patch for a PR marked as INVALID".
| 
| 
| Gabriel Dos Reis wrote on 19/06/2005 19:06:13:
| > Then let me explain my previous message.  Either
| >
| >   (1) Vincent thinks it is an invalid bug, then
| >
| >          http://gcc.gnu.org/ml/gcc/2005-06/msg00818.html
| >
| >   (2) or Vincent thinks it is NOT an invalid bug, then
| >
| >          http://gcc.gnu.org/ml/gcc/2005-06/msg00803.html
| >
| 
| I don't see a contradiction. All he is trying to say that it is
| a valid bug marked as INVALID. His claims that a patch will
| be ignored if the PR is marked as INVALID make sense to me.

But, that is not the claim he made.

-- Gaby

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Vincent Lefevre]

On 2005-06-19 17:33:55 +0200, Gabriel Dos Reis wrote:
> Then, care to explain
> 
>    On 2005-06-19 11:47:16 +0200, Gabriel Dos Reis wrote:
>    > since you seem OK with that solution, would you mind preparing a patch?
>    > (discussions are not executables; someone needs to make things happen.) 
> 
>    This is complete non-sense. One doesn't prepare a patch for an invalid
>    bug.
> 
> ?

By "an invalid bug", I meant "a bug marked as invalid" (I thought every
one would have understood with the context). Is that clear now?

Concerning about reopening it, I didn't feel the need since some other
users tried before (and gave good reasons), without any success (see
the last duplicates for instance).

-- 
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: Reporting bugs: there is nothing to gain in frustrating reporters

[Gabriel Dos Reis]

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

| Other solutions that would fix the bug (but not ultimate solutions):
| 1) Do not claim that gcc is a conforming ISO C implementation.

As far as I can see, there is no such claim.

-- Gaby

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Vincent Lefevre]

On 2005-06-19 11:12:49 +0200, Gabriel Dos Reis wrote:
> Vincent Lefevre <vincent+gcc@vinc17.org> writes:
> | Other solutions that would fix the bug (but not ultimate solutions):
> | 1) Do not claim that gcc is a conforming ISO C implementation.
> 
> As far as I can see, there is no such claim.

The standard says:

       __STDC__ The decimal constant  1,  intended  to  indicate  a
                conforming implementation.

       __STDC_VERSION__ The decimal constant 199901L.138)

In my program, I have:

#if __STDC__ == 1 && __STDC_VERSION__ >= 199901 && defined(__STDC_IEC_559__)
  printf ("__STDC_IEC_559__ defined:\n"
          "The implementation shall conform to the IEEE-754 standard.\n"
          "FLT_EVAL_METHOD is %d (see ISO/IEC 9899, 5.2.4.2.2#7).\n",
          (int) FLT_EVAL_METHOD);
#endif
[...]

and it outputs:

__STDC_IEC_559__ defined:
The implementation shall conform to the IEEE-754 standard.
FLT_EVAL_METHOD is 2 (see ISO/IEC 9899, 5.2.4.2.2#7).
The IEEE-754 result is 9007199254740994 with double precision.
The IEEE-754 result is 9007199254740996 with extended precision.
The obtained result is 9007199254740996.

BUG:
The implementation doesn't seem to convert values to the target type after
an assignment (see ISO/IEC 9899: 5.1.2.3#12, 6.3.1.5#2 and 6.3.1.8#2[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: Reporting bugs: there is nothing to gain in frustrating reporters

[Joseph S. Myers]

On Sun, 19 Jun 2005, Vincent Lefevre wrote:

> On 2005-06-19 11:12:49 +0200, Gabriel Dos Reis wrote:
> > Vincent Lefevre <vincent+gcc@vinc17.org> writes:
> > | Other solutions that would fix the bug (but not ultimate solutions):
> > | 1) Do not claim that gcc is a conforming ISO C implementation.
> > 
> > As far as I can see, there is no such claim.
> 
> The standard says:
> 
>        __STDC__ The decimal constant  1,  intended  to  indicate  a
>                 conforming implementation.
> 
>        __STDC_VERSION__ The decimal constant 199901L.138)

I would have hoped the documentation (trouble.texi, "Undefining 
@code{__STDC__} when @option{-ansi} is not used.") would have been clearly 
enough applicable here.  The standard only relates to conforming 
compilers, the definitions for compilers aiming towards conformance but 
not there yet (-std=c89, -ansi, -std=c99 etc.) and for compilers not 
aiming towards conformance are a pragmatic matter only.

As in standards.texi, GCC *aims towards* being usable as a conforming 
freestanding implementation, ....  The support is not feature-complete as 
regards C99 and not fully correct as regards either C90 or C99.  There is 
no claim to be free from bugs, or free from known bugs, as regards 
conformance, and I do not believe bug-free compilers (or popular compilers 
free from known bugs) exist.

-- 
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: Reporting bugs: there is nothing to gain in frustrating reporters

[Haren Visavadia]

--- Gabriel Dos Reis wrote:
> Vincent Lefevre writes:
> 
> | Other solutions that would fix the bug (but not
> ultimate solutions):
> | 1) Do not claim that gcc is a conforming ISO C
> implementation.
> 
> As far as I can see, there is no such claim.

It's implied when using -std=c99



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

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Vincent Lefevre]

On 2005-06-19 11:17:47 +0100, Haren Visavadia wrote:
> --- Gabriel Dos Reis wrote:
> > Vincent Lefevre writes:
> > 
> > | Other solutions that would fix the bug (but not
> > ultimate solutions):
> > | 1) Do not claim that gcc is a conforming ISO C
> > implementation.
> > 
> > As far as I can see, there is no such claim.
> 
> It's implied when using -std=c99

Yes, and if GCC developers think it is better to lie concerning the
C standard comformance, this could be acceptable when such an option
is given, but this should be clearly documented. According to the man
page, this just means that the source is to be seen as C99 (what "the
compiler accepts").

-- 
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: Reporting bugs: there is nothing to gain in frustrating reporters

[Gabriel Dos Reis]

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

| On 2005-06-19 11:17:47 +0100, Haren Visavadia wrote:
| > --- Gabriel Dos Reis wrote:
| > > Vincent Lefevre writes:
| > > 
| > > | Other solutions that would fix the bug (but not
| > > ultimate solutions):
| > > | 1) Do not claim that gcc is a conforming ISO C
| > > implementation.
| > > 
| > > As far as I can see, there is no such claim.
| > 
| > It's implied when using -std=c99
| 
| Yes, and if GCC developers think it is better to lie concerning the
| C standard comformance, this could be acceptable when such an option
| is given, but this should be clearly documented. According to the man
| page, this just means that the source is to be seen as C99 (what "the
| compiler accepts").

Now that you have equated GCC developers to liars, are you willing to
improve over the situation?

-- Gaby

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Andrew Pinski]

On Jun 19, 2005, at 9:54 AM, Gabriel Dos Reis wrote:

> Vincent Lefevre <vincent+gcc@vinc17.org> writes:
> | Yes, and if GCC developers think it is better to lie concerning the
> | C standard comformance, this could be acceptable when such an option
> | is given, but this should be clearly documented. According to the man
> | page, this just means that the source is to be seen as C99 (what "the
> | compiler accepts").
>
> Now that you have equated GCC developers to liars, are you willing to
> improve over the situation?

Also I think GCC is not the one who is defining it either.  It is glibc
who is defining that so complain to them instead.

-- Pinski

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Vincent Lefevre]

On 2005-06-19 09:57:33 -0400, Andrew Pinski wrote:
> Also I think GCC is not the one who is defining it either. It is
> glibc who is defining that so complain to them instead.

Thanks for the information (I'm a bit surprised because these are gcc
command-line options that are the first cause of these definitions).
Is there a way to know what gcc defines and what glibc defines?

-- 
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: Reporting bugs: there is nothing to gain in frustrating reporters

[Gabriel Dos Reis]

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

| On 2005-06-19 09:57:33 -0400, Andrew Pinski wrote:
| > Also I think GCC is not the one who is defining it either. It is
| > glibc who is defining that so complain to them instead.
| 
| Thanks for the information (I'm a bit surprised because these are gcc
| command-line options that are the first cause of these definitions).
| Is there a way to know what gcc defines and what glibc defines?

As a first approximation, you can start with the assumption that
anything having to do with the C standard library is expected to be
provided by the target system library.  GCC does some transformations
based on the standard semantics -- look for the so-called "built-ins"
in the documentation.  The options are sometime needed for the target
library to profide some functionalities, so that means that it is
close do impossible for GCC to know when a switch is selected by 
User L. but is not honored by the target library.

-- Gaby

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Marcin Dalecki]

On 2005-06-19, at 17:59, Vincent Lefevre wrote:

> On 2005-06-19 09:57:33 -0400, Andrew Pinski wrote:
>
>> Also I think GCC is not the one who is defining it either. It is
>> glibc who is defining that so complain to them instead.
>>
>
> Thanks for the information (I'm a bit surprised because these are gcc
> command-line options that are the first cause of these definitions).
> Is there a way to know what gcc defines and what glibc defines?

For GCC, sure, yes. GLIBC: certainly NO. To be more precise:
It's only possible in a time-span which exceeds the MTBF of an  
developer.

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Vincent Lefevre]

On 2005-06-19 15:54:20 +0200, Gabriel Dos Reis wrote:
> Vincent Lefevre <vincent+gcc@vinc17.org> writes:
> | Yes, and if GCC developers think it is better to lie concerning the
> | C standard comformance, this could be acceptable when such an option
> | is given, but this should be clearly documented. According to the man
> | page, this just means that the source is to be seen as C99 (what "the
> | compiler accepts").
> 
> Now that you have equated GCC developers to liars, are you willing to
> improve over the situation?

I haven't said that. Sorry if I wasn't clear enough. I meant that
the gcc implementation lies about C standard comformance, and
showed an example. Concerning the documentation, I'll put that
on my todo list (now that I know a little more about what gcc
does and when). You can see I've already posted comments on the
documentation:

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

But I'm not a GCC developer and doesn't know the GCC internals
(I can just see the effects). So, producing a correct documentation
could be a bit difficult for me.

-- 
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: Reporting bugs: there is nothing to gain in frustrating reporters

[Gabriel Dos Reis]

Haren Visavadia <themis_hv@yahoo.co.uk> writes:

| --- Gabriel Dos Reis wrote:
| > Vincent Lefevre writes:
| > 
| > | Other solutions that would fix the bug (but not
| > ultimate solutions):
| > | 1) Do not claim that gcc is a conforming ISO C
| > implementation.
| > 
| > As far as I can see, there is no such claim.
| 
| It's implied when using -std=c99

I see.  Patch to reword the documentation are welcome.

-- Gaby

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Toon Moene]

Vincent Lefevre wrote:

> Saying that the x86 processor is buggy is just completely silly.
> Only some gcc developers think so.

No, Kahan thinks so too (sorry, can't come up with a link just right 
now).  The original plan for x87 extended precision floating point was 
to have a small stack of 80-bit floats on the chip, and an interrupt to 
the OS if more registers were needed than the number extant on the chip. 
  The OS was then to provide the extra storage to "feign" the unlimited 
number of 80-bit "registers".

Unfortunately, somewhere in the design process of the 8087 things went 
wrong and the chip only handles 8 80-bit registers, not providing an 
interrupt (or any other support) to an OS to fake the "virtual" 80-bit 
registers.

Hence our problems.

-- 
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/
Looking for a job: Work from home or at a customer site; HPC, (GNU) 
Fortran & C

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Robert Dewar]

Toon Moene wrote:
> Vincent Lefevre wrote:

> Unfortunately, somewhere in the design process of the 8087 things went 
> wrong and the chip only handles 8 80-bit registers, not providing an 
> interrupt (or any other support) to an OS to fake the "virtual" 80-bit 
> registers.

This is nonsense. It is perfectly possible to extend the stack accurately
in memory. That is easily true on the 387, but was also true on the 8087
with just a little bit of fiddling (I know that some people thought this
was not possible, but they just did not look hard enough, the Alsys Ada
compiler for instance used a stack model for fpt, and dynamically extended
this stack in memory, so this is certainly possible).

> Hence our problems.

No, this has nothing whatever to do with our problems
> 

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Toon Moene]

Robert Dewar wrote:

> I wrote:

>> Unfortunately, somewhere in the design process of the 8087 things went 
>> wrong and the chip only handles 8 80-bit registers, not providing an 
>> interrupt (or any other support) to an OS to fake the "virtual" 80-bit 
>> registers.

> This is nonsense. It is perfectly possible to extend the stack accurately
> in memory. That is easily true on the 387, but was also true on the 8087
> with just a little bit of fiddling (I know that some people thought this
> was not possible, but they just did not look hard enough, the Alsys Ada
> compiler for instance used a stack model for fpt, and dynamically extended
> this stack in memory, so this is certainly possible).

Well, I haven't studied this to such a great detail because I (according 
to Kahan) belong to the group of people who "don't care about floating 
point accuracy because their code is so robust they can even run on 
Cray's", but doesn't this mean that we can solve it in the compiler by 
having its run time library provide this functionality ?

Given that most modern compilations on x86 hardware would use SSE, we 
could at least comfort the users who do want to use the extra bits of 
80-bit floating point land ...

It'll be the final nail in the coffing of PR/323 ...

-- 
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/
Looking for a job: Work from home or at a customer site; HPC, (GNU) 
Fortran & C

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Robert Dewar]

Toon Moene wrote:

> Well, I haven't studied this to such a great detail because I (according 
> to Kahan) belong to the group of people who "don't care about floating 
> point accuracy because their code is so robust they can even run on 
> Cray's", but doesn't this mean that we can solve it in the compiler by 
> having its run time library provide this functionality ?

you are actually in the group for which the extra precision etc is
designed :-) THe extra precision probably does not affect your code,
might even help it who knows, but attempts to "fix" this problem might
harm the performance of your code. The "might" is of course a very
important word here. It really seems like a better idea to use sse
if you don't care about 80-bit precision anyway.

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Vincent Lefevre]

On 2005-06-18 13:52:01 +0200, Toon Moene wrote:
> Vincent Lefevre wrote:
> 
> >Saying that the x86 processor is buggy is just completely silly.
> >Only some gcc developers think so.
> 
> No, Kahan thinks so too (sorry, can't come up with a link just right 
> now).

I'd be very interested in such a link. That would mean that he changed
his mind and it would contradict some points given in "How Java's FP
Hurt Everyone Everywhere". He even seems to like x87, see page 61 for
instance (though I disagree with him on the advantages of extended
precision, for portability reasons).

>  The original plan for x87 extended precision floating point was 
> to have a small stack of 80-bit floats on the chip, and an interrupt to 
> the OS if more registers were needed than the number extant on the chip. 
>  The OS was then to provide the extra storage to "feign" the unlimited 
> number of 80-bit "registers".
> 
> Unfortunately, somewhere in the design process of the 8087 things went 
> wrong and the chip only handles 8 80-bit registers, not providing an 
> interrupt (or any other support) to an OS to fake the "virtual" 80-bit 
> registers.
> 
> Hence our problems.

Why? Even when the 8-register limit isn't reached, there are problems.
And I recall the problem: the fact that an extended-precision value of
type double is not rounded to double-precision after an assignment or
a cast. I don't see the relation with the 8-register limit.

-- 
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: Reporting bugs: there is nothing to gain in frustrating reporters

[Steven Bosscher]

On Thursday 16 June 2005 00:14, Vincent Lefevre wrote:
> On 2005-06-15 21:22:38 +0200, Florian Weimer wrote:
> > Not necessarily, wrongly closed reports are reopened in my experience
>
> Not all of them, e.g. bug 323 (yes, again).

Please make this thread die, you've all made your points by now, don't
you think?!  Can we return to discussions about the development of GCC,
which is what this list is for?  Discussions at the meta-level are OK,
but this one is going round in circles.

Geez.  I've never seen such long nonsense threads before on gcc@.

Gr.
Steven

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Gabriel Dos Reis]

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

| On 2005-06-15 21:22:38 +0200, Florian Weimer wrote:
| > Not necessarily, wrongly closed reports are reopened in my experience
| 
| Not all of them, e.g. bug 323 (yes, again).

Vincent, please.

-- Gaby

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Sam Lauber]

> > > Agreed. But keep in mind that it is not necessary to reply: once the 
bug is
> > > open and confirmed, the last comment "wins", in a way. If the 
bugmaster
> > > wanted to close it, he would just do it, so an objection in a comment 
does
> > > not make the bug invalid per se.
> >
> > But an objection from one of the bugmasters *is* enough to keep people
> > from presenting a patch.
> 
> How do you come to this conclusion?  From my experience this
> is untrue - bugs get fixed because either someone feels resposible,
> it's too easy to do, or someone has personal interest in getting the
> bug fixed.  Negative or positive comments do not change this.
Once I submitted a bug to a project (not GCC) in November '04.  I didn't
recive a conformation mail until last month!

Samuel Lauber

-- 
_______________________________________________
Surf the Web in a faster, safer and easier way:
Download Opera 8 at http://www.opera.com

Powered by Outblaze

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Dan Kegel]

Scott Robert Ladd wrote:

> Mark has a valid concern: Why aren't bugs being fixed? One answer is:
> The GCC community is often less than welcoming, friendly, and helpful.
> 
> You may not like or believe the answer, but if you want more people to
> help GCC for free, an attitude adjustment may be required on your part.
> It's not as if there aren't many other challenging projects for people
> to participate in.

I'm a bug reporter, usually not a bug fixer, and I don't
get the feeling that the gcc developers are being rude.
The 27 issues I've reported have been dealt with professionally
and reasonably.  (A few have languished unfixed, but those
bugs aren't critical, and it hasn't bothered me too much.
And to be fair, I'm sitting on fixes sent me by the gcc
developers I've been too busy to verify, so really, I
wouldn't have a leg to stand on even if I wanted to complain!)
- Dan

-- 
Trying to get a job as a c++ developer?  See http://kegel.com/academy/getting-hired.html

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Scott Robert Ladd]

Mark Hahn wrote:
> LKML is no different, except that it is probably somewhat more prominent,
> and has developed some immunity/bouncers (kernel janitors, etc).

Linux as has a vast body of educational material, including "kernel
newbies".

..Scott

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Dan Kegel]

Scott Robert Ladd wrote:
> I have ample evidence that
> many people feel that the GCC developer community is not very welcoming.

I haven't found this to be the case.  Perhaps that's because
I try to control my urge to post frequently (oops, guess
I'm screwing up here!), and because I try hard to come
up with minimal test cases when I have problems to report.

> 1) Bugmasters could be less perfunctory and pejorative in their
> comments. Examples have been given.

Politeness is always a good idea.
However, if you poke a bear with a stick often enough,
he will growl.  If you tell a gcc developer over and over
he is wrong, for instance, I think it's understandable
for him to becom cross.

In any big project, there will always be developers who are sometimes
cross and impolite (e.g. certain library maintainers who shall
remain nameless) but do stellar work in general.
When you run into such a bear, it's best to just
grit your teeth, remain polite, and be thankful he's
contributing to the project.

> 2) A mentoring system could help bring along new GCC developers. I'm not
> talking about hand-holding, I'm suggesting that having some place for
> people to ask a few questions, one on one, to get over certain
> conceptual humps.

What about the IRC channel mentioned earlier, posted
prominently at the top of http://gcc.gnu.org/wiki ?
And then there's the GCC summit, if you're really serious.

> 3) To keep Steven's bloodpressure down, I suggest a new mailing list,
> gcc-design, where engineers like myself can propose designs and concepts
> without upsetting those who find such discussions annoying.

I think what gets peoples' blood pressure up is
endless discussion about how they ought to do their
business.
- Dan

-- 
Trying to get a job as a c++ developer?  See http://kegel.com/academy/getting-hired.html

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Scott Robert Ladd]

Dan Kegel wrote:
> And then there's the GCC summit, if you're really serious.

I'd certainly love to attend, but can't afford it with the medical bills
we've accumulated. Hospitalizing both the primary bread-winners has a
dramatic affect on finances. ;)

> I think what gets peoples' blood pressure up is
> endless discussion about how they ought to do their
> business.

Try publishing a compiler review, and listen to the kibitzers. :)

I've been writing for publication all my adult life; just because people
don't like what you write (software or prose) is no reason to be rude.
They might actually have valid points...

..Scott

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Daniel Berlin]

On Thu, 2005-06-16 at 10:51 -0400, Scott Robert Ladd wrote:
> Dan Kegel wrote:
> > And then there's the GCC summit, if you're really serious.
> 
> I'd certainly love to attend, but can't afford it with the medical bills
> we've accumulated. Hospitalizing both the primary bread-winners has a
> dramatic affect on finances. ;)
> 
> > I think what gets peoples' blood pressure up is
> > endless discussion about how they ought to do their
> > business.
> 
> Try publishing a compiler review, and listen to the kibitzers. :)
> 
I've actually done this before, back in the BeOS days , of gcc vs
Metrowerks.  Kibitzers raise the same issues that many trolls on our
mailing lists do too. Strange, isn't it?

> I've been writing for publication all my adult life; just because people
> don't like what you write (software or prose) is no reason to be rude.
> They might actually have valid points...
> 

And it might be possible that in the past 5 years, endless discussion
has been had on most of these points, and the person positing the
viewpoint is not in any way raising new reasoning or anything else, they
just want to throw their same 2 cents in again and again and again and
again and again and again and again (which i'm sure you'll say is us
"not listening to the user community", which is not the case).

We've also had people write to other mailing lists and say "plesae
mail-bomb the gcc list so they'll listen to us"

If your whole "community is unfriendly" is about discussion of floating
point issues, than i'll just go away, because yes, over the past 8
years, we've become very unfriendly about the small number of people who
contend again and again that we should do it different, claiming simply
that any viewpoint than theirs is *wrong* and *bad* instead of "a
tradeoff that has been chosen".  And they are *not* particularly polite
about it.



> ..Scott

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Scott Robert Ladd]

Darn me all the heck. I said I wasn't going to say anything more... bad
Scott, bad Scott!

> again and again and again and again (which i'm sure you'll say is us
> "not listening to the user community", which is not the case).

I hate to disappoint you, but those words won't grace this message. I
understand the frustration.

> We've also had people write to other mailing lists and say "plesae
> mail-bomb the gcc list so they'll listen to us"

And I have a homeless guy in Berkeley who takes great satisfaction in
raking anything I do over the coals in various Usenet groups. We all
have our crosses to bear...

> ...we've become very unfriendly about the small number of people who
> contend again and again that we should do it different, claiming simply
> that any viewpoint than theirs is *wrong* and *bad* instead of "a
> tradeoff that has been chosen".  And they are *not* particularly polite
> about it.

My silly goal is to try an accomodate all viewpoints; providing a
solution for bug 323 (for infamous example) could remove an irritant for
all sides. Wouldn't that be a Good Thing?

..Scott
(Who really will shut up now, until he presents some code.)

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Gabriel Dos Reis]

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

| > I think what gets peoples' blood pressure up is
| > endless discussion about how they ought to do their
| > business.
| 
| Try publishing a compiler review, and listen to the kibitzers. :)
| 
| I've been writing for publication all my adult life; just because people
| don't like what you write (software or prose) is no reason to be rude.
| They might actually have valid points...

Well, some of the GCC developers have been publishing in their adult
life too.  I guess, the real issue as far as GCC is concerned must be
somewhere else.  Reasonable people with fair technical backgrounds can
look at the same problems and come up with different conclusions. 

Sometimes, some people come to GCC developers with the assumptions
that they must be obscure ignorant and miles-of-code-writers-without-
thinking and as such are very willing to endlessly lecture them about
how ignorant they are and how they should do their jobs.  That can not
only irritate but also contribute to "blood pressure".  Furthermore,
it is also assumed that since people working on GCC earn part of their 
business on working on GCC, they de facto become slaves of the 
lecturer/manager-du-jour.  

That is not meant to excuse what you perceive to be rudeness, but to
point out that the communication channel works both ways.

-- Gaby

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Scott Robert Ladd]

Gabriel Dos Reis wrote:
> Sometimes, some people come to GCC developers with the assumptions
> that they must be obscure ignorant and miles-of-code-writers-without-
> thinking and as such are very willing to endlessly lecture them about
> how ignorant they are and how they should do their jobs.

I have never considered GCC developers to be ignorant, and perhaps what
I perceive as "rudeness" is in fact frsutration accumulated over many
years. If anything, this is one of the brightest developer groups.

> That is not meant to excuse what you perceive to be rudeness, but to
> point out that the communication channel works both ways.

A good point. I shall attempt to be a bit less sensitive and more
understanding, on the assumption that others will return the favor.

..Scott

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Robert Dewar]

> Well, I haven't studied this to such a great detail because I (according 
> to Kahan) belong to the group of people who "don't care about floating 
> point accuracy because their code is so robust they can even run on 
> Cray's", but doesn't this mean that we can solve it in the compiler by 
> having its run time library provide this functionality ?

You are mixing issues, the issue of extra precision on the x86 has nothing
whatever with whether or not such values can be stored in memory (they can),
and Kahan's inaccurate impression that there is a problem in extending the
stack, if indeed you are quoting him accurately, is not relevant.

> Given that most modern compilations on x86 hardware would use SSE, we 
> could at least comfort the users who do want to use the extra bits of 
> 80-bit floating point land ...

long double works just fine right now

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Robert Dewar]

By the way, we had one customer recently report an experiment of 
using -march=pentium4 -fpmath=sse on a big application and seeing
a 5% improvement in performance. This customer incidentally had
reported a bug under the title "intel x86 numeric nightmare",
which was another version of PR/323 in the Ada context, and the
use of -fpmath=sse was to fix this nightmare (the improved
performance was a pleasant side effect). Unfortunately we
don't have the figures for these two switches separated.

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Toon Moene]

Robert Dewar wrote:

>>Well, I haven't studied this to such a great detail because I (according 
>>to Kahan) belong to the group of people who "don't care about floating 
>>point accuracy because their code is so robust they can even run on 
>>Cray's", but doesn't this mean that we can solve it in the compiler by 
>>having its run time library provide this functionality ?

> You are mixing issues, the issue of extra precision on the x86 has nothing
> whatever with whether or not such values can be stored in memory (they can),
> and Kahan's inaccurate impression that there is a problem in extending the
> stack, if indeed you are quoting him accurately, is not relevant.

Hmmm, lets be careful here.  In my original reply I said "I do not have 
a link just right now", which means I might recall things incorrectly.

I have read accounts (in a distant past) that the original purpose of 
the x87 stack of 80-bit floating point values was to have a cache on the 
processor (initially 8 registers) and the rest supported by "the 
operating system".  That could of course well be the common run time 
library.

If your experience is that such a support (of an indefinite number of 
80-bit floating point registers) could easily be provided by the run 
time library of <language> compiler, that indicates to me that GCC could 
provide such support.

The new thing I learned from your mail is the above.  If GCC can support 
this, than we can properly solve PR/323.  This is independent of whether 
I recall the thing I read in the past correctly.

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/
Looking for a job: Work from home or at a customer site; HPC, (GNU) 
Fortran & C

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Robert Dewar]

Toon Moene wrote:

> The new thing I learned from your mail is the above.  If GCC can support 
> this, than we can properly solve PR/323.  This is independent of whether 
> I recall the thing I read in the past correctly.

Interesting, let me restudy PR/323 ...