Re: Baby X is bor nagain

On 29/06/2024 18:11, bart wrote:

On 29/06/2024 16:38, Tim Rentsch wrote:

bart <bc@freeuk.com> writes:
>

On 28/06/2024 11:26, Kaz Kylheku wrote:
>

On 2024-06-28, bart <bc@freeuk.com> wrote:
>

On 28/06/2024 04:23, Kaz Kylheku wrote:
>

On 2024-06-27, bart <bc@freeuk.com> wrote:
>

And for most of /my/ compiles, the code produced by gcc-O0 is
fast enough.  It also about the same speed as code produced by
one of my compilers.
>
So I tend to use it when I want the extra speed, or other
compilers don't work, or when a particular app only builds
with that compiler.
>
Otherwise the extra overheads are not worth the bother.

>
How good are your diagnostics compared to GCC -O2, plus -Wall
and -W?

>
Using products like tcc doesn't mean never using gcc.
(Especially on Linux where you will have it installed anyway.)
>
You can use the latter to do extra, periodic checks that the
simpler compiler may have missed, or to produce faster production
builds.
>
But gcc is not needed for routine compilation.

>
Catching common bugs in routine compilation is better than once
a month.
>
You could be wasting time debugging something where GCC would have
told you right away you have something uninitialized or whatever.

>
Let's take the C program below.  It has 4 things wrong with it,
marked with comments.
>
[...]

>
People are never going to take you seriously as long as
you keep offering what are obviously strawman arguments,
and especially ones where you know better but pretend
that you don't.

 You've perhaps missed my main point, which was that gcc 14 now reports hard errors BY DEFAULT for things which I have argued in the past should be hard errors by default.

I don't remember anyone disagreeing with you that some things would be better as hard errors by default.  People have been quite happy with the idea that code that breaks C syntax rules or constraint rules should be hard errors.  But they disagree with you on some of your hard errors - code that we all think is bad code and almost certainly an error, but which does not break the rules of standard C can be a warning by default, but should not be an error by default.
gcc, however, is restricted and limited by its past - the developers do not lightly make changes that will result in compilation failures of code that previously compiled fine and had been tested to run correctly.   Such changes - as made for gcc 14 - are only done after long discussion and long testing with existing code bases.
Many of us thing it would be better if gcc's warnings and errors were a lot stricter by default.  But we understand the reasons why gcc can't change these much, and we understand how to choose the checking levels with flags so that we can use gcc the way we want it.  Telling you "just use -Wall", or similar, is advice and help - it is not saying that we like a lax compiler by default.

 You've probably also missed my secondary point, which was asking WHY that change was made, since all that people had to do to get that behaviour was to jump through a number of hoops as I've always been told to do. Apparently that was not good enough!
 I've also learnt something interesting. Which is that whatever the current version of gcc does is always right, and I'm always wrong if I suggest it should be any different.
 

You are wrong when you continually misrepresent what others say.  When people tell you the facts - be it about C or gcc - it is not the same as saying we necessarily like those facts.

But if gcc suddenly starts doing what I'd advocated, then according to you I'm still wrong! So I can never win.
 

You can win when you stop intentionally misunderstanding, and start listening.