On Tue, Mar 29, 2005 at 09:27:32AM -0800, Joe Buck wrote:
> Or are you just way behind in your reading?
Way behind.
I've read the discussion, I've seen nothing looking like my argument,
so I posted my reply.
RMS wrote:
> >GCC's primary purpose is to be the compiler for the GNU system. It is
> >used for many other purposes too, and it is good for GCC to serve more
> >purposes, but they're not as important for the GNU Project, even
> >though they are all important for some users.
On Tue, Mar 29, 2005
In article <[EMAIL PROTECTED]> you write:
>GCC's primary purpose is to be the compiler for the GNU system. It is
>used for many other purposes too, and it is good for GCC to serve more
>purposes, but they're not as important for the GNU Project, even
>though they are all important for some users.
When they see abort: core dumped, they just curse Emacs for losing their
work and switch to vi.
I am dubious of that speculation, because Emacs is very good at not
losing your work.
It's true
that they don't complain about it on the Emacs developer list, where you
participat
GCC's primary purpose is to be the compiler for the GNU system. It is
used for many other purposes too, and it is good for GCC to serve more
purposes, but they're not as important for the GNU Project, even
though they are all important for some users.
Meanwhile, assuming that -Os is not implied b
On Mar 16, 2005, at 11:23, Richard Stallman wrote:
But what are you saying to those users who don't like it that GNU
programs
abort silently when they discover bugs in themselves? Aren't you
saying
"tough" in a somewhat more polite way?
No, because nobody has complained about it. T
I wrote:
> But what are you saying to those users who don't like it that GNU programs
> abort silently when they discover bugs in themselves? Aren't you saying
> "tough" in a somewhat more polite way?
On Wed, Mar 16, 2005 at 11:23:55AM -0500, Richard Stallman wrote:
> No, because nobody has com
As I recall, in the old days you (RMS) used to do user polls on occasion.
Would you consider doing it in this case? That is, is it appropriate
for the GNU project to place naked aborts in its programs?
Conducting a poll does not mean asking users to vote on a design
decison or a desig
> Currently, I believe, GCC combines various calls to abort in a single
> function, because it knows that none of them returns.
afaics it is more generic. It merges them because it knows that it doesn't
make any difference.
Sometimes it is useful to make special exceptions to gene
> After some 20 years of developing popular free software, I have
> somewhat of an idea what users are likely to do.
Many of us have developed software for a similar period of time,
and yet feel differently.
We may have had different experiences working on different kinds of
progr
Richard Kenner <[EMAIL PROTECTED]> wrote:
> However, the idea that users could search for previous bug
> reports is new to me. That might be an additional reason for
> using fancy_abort.
>
> It's not just users, but first level tech-support. There, it can help
> in suggesting a workaroun
"Dave Korn" <[EMAIL PROTECTED]> writes:
> I very strongly feel that this optimisation should be placed under user
> control rather than just disabled, and that it should remain enabled by
> default at -Os; but I wouldn't go to the ropes over whether or not it's
> included in -Os as long as there'
On Mar 14, 2005, Eric Christopher <[EMAIL PROTECTED]> wrote:
>> > Now, I wouldn't object to hacking GCC to avoid cross-jumping calls to
>> > abort. It's just that I don't think that the common GNU use of abort
>> > serves the users.
>> Agreed. And as someone suggested, rather than treating abort
> What we might want to do is provide an option to disable all such
> optimizations.
>
We have had enough requests for -Odebug or something like that.
Probably could be just dce, ccp, and a couple of other optimizations...
-eric
Original Message
>From: Richard Stallman
>Sent: 15 March 2005 18:39
> Nonetheless, GCC may as well still stop cross-jumping abort calls.
> There's nothing to lose
There *is* something to lose: memory space. Lots of people use gcc to
develop for deeply embedded systems, where memory res
However, the idea that users could search for previous bug reports is
new to me. That might be an additional reason for using fancy_abort.
It's not just users, but first level tech-support. There, it can help
in suggesting a workaround to the user and knowing which file the abort
is in m
With or without cross-jumping, when the developer gets a
report from a user that "the program died with an abort", he or she has to
debug from scratch, only to find out in many cases that it's a known bug,
already fixed in CVS for the next release, information that would have
Hi,
On Fri, Mar 11, 2005 at 03:28:19PM -0500, Richard Stallman wrote:
> Currently, I believe, GCC combines various calls to abort in a single
> function, because it knows that none of them returns.
afaics it is more generic. It merges them because it knows that it doesn't
make any difference. Thi
On Tue, 2005-03-15 at 09:59, Clifford Wolf wrote:
> Hi,
>
> On Sun, Mar 13, 2005 at 03:01:00PM +0200, Kai Henningsen wrote:
> > Most of the rest of the error handling in this project is concerned with
> > the absence of the feature I loved in the IBM PL/I compilers under the
> > name "SNAP;" -
Hi,
On Sun, Mar 13, 2005 at 03:01:00PM +0200, Kai Henningsen wrote:
> Most of the rest of the error handling in this project is concerned with
> the absence of the feature I loved in the IBM PL/I compilers under the
> name "SNAP;" - putting out a stack backtrace (the usual idiom for abort()
On Mon, Mar 14, 2005 at 04:49:41PM -0800, Eric Christopher wrote:
>
> > > Now, I wouldn't object to hacking GCC to avoid cross-jumping calls to
> > > abort. It's just that I don't think that the common GNU use of abort
> > > serves the users.
> > Agreed. And as someone suggested, rather than tre
> > Now, I wouldn't object to hacking GCC to avoid cross-jumping calls to
> > abort. It's just that I don't think that the common GNU use of abort
> > serves the users.
> Agreed. And as someone suggested, rather than treating abort
> specially within GCC, I think we'd be better off with a functi
On Mon, 2005-03-14 at 16:17 -0800, Joe Buck wrote:
> On Mon, Mar 14, 2005 at 06:44:16PM -0500, Richard Stallman wrote:
> > After some 20 years of developing popular free software, I have
> > somewhat of an idea what users are likely to do.
>
> Many of us have developed software for a similar perio
Joe Buck wrote:
But it seems to me that the practice of using abort() as it is now used
in many GNU programs is a holdover from 20 years ago when the engineering
tradeoffs were different. We can afford to tell the user more.
In addition, crossjumping calls to abort does more than just save space;
On Mon, Mar 14, 2005 at 06:44:16PM -0500, Richard Stallman wrote:
> After some 20 years of developing popular free software, I have
> somewhat of an idea what users are likely to do.
Many of us have developed software for a similar period of time,
and yet feel differently.
> I don't use
> fancy_a
On Mon, Mar 14, 2005 at 06:44:09PM -0500, Richard Stallman wrote:
> 'abort: core dumped' is not a good user experience. If code is being
> shipped with naked aborts in it, that is where the problem lies.
>
> You're entitled to your opinion, but such a conclusion requires much
> stronger b
Most people don't do debugging. For some reason you appear to think
that every free software user is also a free software debuggers.
After some 20 years of developing popular free software, I have
somewhat of an idea what users are likely to do. I don't use
fancy_abort functions because
The __FILE__ strings will be combined, so you get a most one of it for
each object file.
You're right about that. So the increase in size due to fancy_abort
will be somewhat less than I previously said. However, it will still
be an increase in size, compared with using abort and not
cros
'abort: core dumped' is not a good user experience. If code is being
shipped with naked aborts in it, that is where the problem lies.
You're entitled to your opinion, but such a conclusion requires much
stronger basis than this.
If
cross jumping makes debugging harder, tough --
On Mar 14, 2005, at 10:30 AM, Joe Buck wrote:
Steven Bosscher <[EMAIL PROTECTED]> wrote:
system.h:#define abort() fancy_abort (__FILE__, __LINE__,
__FUNCTION__)
I agree that this is the best technical solution, even if cross-jumping
were not an issue.
This invokes undefined behavior in a pro
Distributions would have to triple the number of CDs shipped. Most
users don't know how to run a debugger. This means that there is no
debug information available until a developer tries to duplicate the
problem report. With or without cross-jumping, when the developer
gets a
Steven Bosscher <[EMAIL PROTECTED]> wrote:
system.h:#define abort() fancy_abort (__FILE__, __LINE__, __FUNCTION__)
I agree that this is the best technical solution, even if cross-jumping
were not an issue.
Also:
On Monday 14 March 2005 04:00, Richard Stallman wrote:
> > But you recommend a
Richard Stallman wrote:
Otherwise, we need to consider the merits of disabling an optimization
to make debugging easier.
Optimizing calls to `abort' doesn't offer much benefit, so I think in
this particular case it is worth disabling cross-jumping.
This is a difficult choice to make
On Mon, 2005-03-14 at 03:00, Richard Stallman wrote:
> This is a difficult choice to make, but at
> -O2, I'd prefer that we optimize, and suggest other debugging techniques
> intead of relying on the line numbers of abort calls.
>
> The sole purpose of optimization is to satisfy us
On Monday 14 March 2005 04:00, Richard Stallman wrote:
> Steven Bosscher <[EMAIL PROTECTED]> wrote:
>
> system.h:#define abort() fancy_abort (__FILE__, __LINE__, __FUNCTION__)
>
> where fancy_abort is a, well, fancy abort that prints some more
> information about what happened, and wher
Richard Stallman <[EMAIL PROTECTED]> writes:
> Steven Bosscher <[EMAIL PROTECTED]> wrote:
>
> system.h:#define abort() fancy_abort (__FILE__, __LINE__, __FUNCTION__)
>
> where fancy_abort is a, well, fancy abort that prints some more
> information about what happened, and where. IMVHO
On 2005-03-14, at 05:20, Gary Funck wrote:
Richard Stallman wrote (in part):
What's the point of cross-jumping? It saves a certain amount of
space; it has no other benefit. All else being equal, there's no
reason not to do it. But cross-jumping abort calls interferes with
debugging. That's a go
Richard Stallman wrote (in part):
> What's the point of cross-jumping? It saves a certain amount of
> space; it has no other benefit. All else being equal, there's no
> reason not to do it. But cross-jumping abort calls interferes with
> debugging. That's a good reason not to do it.
t's get ri
Otherwise, we need to consider the merits of disabling an optimization
to make debugging easier.
Optimizing calls to `abort' doesn't offer much benefit, so I think in
this particular case it is worth disabling cross-jumping.
This is a difficult choice to make, but at
-O2, I'd
[EMAIL PROTECTED] (Steven Bosscher) wrote on 13.03.05 in <[EMAIL PROTECTED]>:
> On Sunday 13 March 2005 02:07, James E Wilson wrote:
> > Richard Stallman wrote:
> > > Currently, I believe, GCC combines various calls to abort in a single
> > > function, because it knows that none of them returns.
On Sunday 13 March 2005 02:07, James E Wilson wrote:
> Richard Stallman wrote:
> > Currently, I believe, GCC combines various calls to abort in a single
> > function, because it knows that none of them returns.
>
> To give this request a little context, consider the attached example.
May I recomme
James E Wilson wrote:
To give this request a little context, consider the attached example.
This time actually attached.
--
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
int
sub (int i, int j)
{
if (i == 0)
abort ();
else if (j == 0)
abort ();
else
return i * j;
}
int
Richard Stallman wrote:
Currently, I believe, GCC combines various calls to abort in a single
function, because it knows that none of them returns.
To give this request a little context, consider the attached example.
If I compile this with -O2 -g, and run it under the debugger, it tells
me that
43 matches
Mail list logo
