Re: GCC 10.5 Released

2023-07-07 Thread Richard Stallman via Gcc
[[[ To any NSA and FBI agents reading my email: please consider]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] Congratulations on the new release. May it be as boring as we hope. -- Dr Ri

Re: Makeinfo generates wrong link

2022-10-10 Thread Richard Stallman via Gcc
Some macros are predefined on each kind of machine (@pxref{System specific Predefined Macros, System specific Predefined Macros, System-specific Predefined Macros, cpp, The C Preprocessor}). This allows you to provide code specially tuned for a particular machine. -- Dr Richard Stallman (

Re: Makeinfo generates wrong link

2022-10-04 Thread Richard Stallman via Gcc
gt; correct: the reference should point to the (cpp) manual instead of the > (gcc) manual. What is the full, formal tit;e of the CPP manual? Texinfo cross-references need to specify that, as well as the short name for Info. -- Dr Richard Stallman (https://stallman.org) Chief GNUisance of t

Re: Makeinfo generates wrong link

2022-10-03 Thread Richard Stallman via Gcc
n "System specific". I will make that change. Thanks. -- Dr Richard Stallman (https://stallman.org) Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org)

Re: clang vs free software

2014-01-24 Thread Richard Stallman
shed free source code, but under Apple's rules and Apple's DRM, the binary can't be free. -- Dr Richard Stallman President, Free Software Foundation 51 Franklin St Boston MA 02110 USA www.fsf.org www.gnu.org Skype: No way! That's nonfree (freedom-denying) software. Use Ekiga or an ordinary phone call.

Re: clang and FSF's strategy

2014-01-23 Thread Richard Stallman
petitors which consist of our code plus something else that is off limits to us. -- Dr Richard Stallman President, Free Software Foundation 51 Franklin St Boston MA 02110 USA www.fsf.org www.gnu.org Skype: No way! That's nonfree (freedom-denying) software. Use Ekiga or an ordinary phone call.

Re: Preventing warnings

2007-01-20 Thread Richard Stallman
Nevertheless, I (and others seem to agree) would like to name that particular warning, so it can be enabled/disabled. Also, there is a similar warning for unsigned >= 0 and unsigned < 0 in -Wextra. There are bug reports about the inconsistency (http://gcc.gnu.org/PR23587). So,

Good book on C? http://publications.gbdirect.co.uk/c_book/

2007-01-19 Thread Richard Stallman
http://publications.gbdirect.co.uk/c_book/ is reportedly a free book on C -- but it is C89, more or less. If it is well written, we could look for people to update it to modern C. But if it isn't well written and clear, it probably isn't worth the trouble. If a few of you who are familiar with o

Re: Preventing warnings

2007-01-19 Thread Richard Stallman
No. This is an undocumented, unnamed, unconditional warning. We are working on fixing those for GCC 4.3 :-) Could you explain what that means? What exactly is the problem that you are talking about fixing? What change is planned?

Re: Preventing warnings

2007-01-18 Thread Richard Stallman
I think this warning is starting to happen for valid code because of 64-bit machines. You can avoid it by using unsigned types. I think that something like this will do the trick: #define FIXNUM_OVERFLOW_P(i)\ ((unsigned long long)(i) > M

Preventing warnings (correction)

2007-01-17 Thread Richard Stallman
My suggestion is that (EMACS_INT)(int)(i) > MOST_POSITIVE_FIXNUM would avoid the warning. But we would not put the casts in the macro FIXNUM_OVERFLOW_P itself, since that would negate the purpose of the macro. Instead we would put the cast in the argument, when the argument is an `int' anyway

Preventing warnings

2007-01-16 Thread Richard Stallman
In Emacs we have a macro that tends to produce the warning comparison is always false due to limited range of data type when compiling for 64-bit machines. EMACS_INT is 64 bits in that case. Here is the macro: #define FIXNUM_OVERFLOW_P(i) \ ((EMACS_INT)(i) > MOST_POSITIVE_FIXNUM \ || (

Re: Merging calls to `abort'

2005-03-17 Thread Richard Stallman
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

Re: Merging calls to `abort'

2005-03-16 Thread Richard Stallman
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

Re: Merging calls to `abort'

2005-03-16 Thread Richard Stallman
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

Re: Merging calls to `abort'

2005-03-16 Thread Richard Stallman
> 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

Re: Merging calls to `abort'

2005-03-16 Thread Richard Stallman
> 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

Re: Merging calls to `abort'

2005-03-15 Thread Richard Stallman
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

Re: Merging calls to `abort'

2005-03-14 Thread Richard Stallman
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

Re: Merging calls to `abort'

2005-03-14 Thread Richard Stallman
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

Re: Merging calls to `abort'

2005-03-14 Thread Richard Stallman
'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 --

Re: Merging calls to `abort'

2005-03-13 Thread Richard Stallman
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

Merging calls to `abort'

2005-03-11 Thread Richard Stallman
Currently, I believe, GCC combines various calls to abort in a single function, because it knows that none of them returns. If the goal is simply to make the compiled code as small as possible, this is the way to do it. But that is not the best goal when compiling free software. Merging the vari