On Friday, 1 September 2023 at 09:43:43 UTC+1, David Brown wrote:
>
> Putting object files in the current directory is a useful default. It
> won't suit everyone, but it will suit some people. And since almost
> anyone who has an "everything in one directory" structure will be in
> that directory when they run their compiler (or make, or whatever), it
> would give the same effect as your compiler's default choice.
>
> I really don't understand what you have against it - other than your
> knee-jerk reaction of "gcc does it, therefore it must be terrible and I
> must invent absurd situations to justify myself".
>
It was the old way of doing things.
Noways most people prefer the "out of tree build". Basically your valuable,
human-generated, human-meaningful source files go in one directory,
the object files and various other intermediates automatically generated by
tools are sequestrated in another directory.
The new way is in my view a lot better, but it does make it a bit more difficult
to set up tools like "make".

On 31/08/2023 22:03, Bart wrote:
> On 31/08/2023 20:28, Kaz Kylheku wrote:

>> You don't want to be dropping binaries in the sae place where the
>> sources are located.
>>
>> *THAT* location may be read-only!
>
> The location that you invoke the compiler from may be read-only!

Yes - that is entirely true. That is why any choice of default here is
only going to suit some use-cases. That is why gcc's choice is not
perfect for everyone - just like /your/ choice is not perfect for everyone.

Can you still not understand what people are trying to tell you? Are
you so obsessed with screaming at everything that gcc and/or Linux does,
and screaming at everyone who uses them, that this has still not sunk in?

Defaults work in some cases, not others.

>
> I guess I'm an oddball. I routinely modify source files and write new
> EXEs in the same folder. What's the point of mucking about with a
> special folder just for the one EXE file?
>

You do realise that if you go to your source directory and use "gcc",
the default is to put the output files in that same directory, just like
if you use "bcc" ? So gcc's defaults work perfectly well for compiling
the way you want - all you need is to give a name for the exe file that
suits your preferences (it gets put in the directory you want).

On 01/09/2023 09:43, David Brown wrote:
> On 31/08/2023 21:26, Bart wrote:

> Putting object files in the current directory is a useful default.

'gcc -c' will do that if the input file is in the same current directory.

So if the current directory happens to be /abc, compiling hello.c will
produce /abc/hello.o from /abc/hello.c.

Everyone has been saying, do the build from inside the source directory.
They've also been saying don't put the object file in the source directory!

That means gcc breaks that rule by default. But look at this pattern:

Object file written to:

abc> gcc hello.c /abc/hello.o
abc> gcc /abc/hello.c /abc/hello.o
xyz> gcc /abc/hello.c /xyz/hello.o

This looks wrong.

> It
> won't suit everyone, but it will suit some people.  And since almost
> anyone who has an "everything in one directory" structure will be in
> that directory when they run their compiler (or make, or whatever), it
> would give the same effect as your compiler's default choice.
>
> I really don't understand what you have against it - other than your
> knee-jerk reaction of "gcc does it, therefore it must be terrible

Or "gcc does it, therefore it must be OK, and the model of how all
software must work"

If I give gcc 100 files to build, will it finish it in a few seconds, or
do I go and make a drink? Simply listing the same of each file will give
a useful indication of where it's up to and how until it's done.

Presumably, you can't see the point of those progress bars you see in GUIs?

> and I
> must invent absurd situations to justify myself".

I raised the issue because the OP did this:

cc64 -c -out:cclib/cclib.obj cclib/cclib.i

I assumed this was out of habit because other compilers required it, and
I double-checked mine.

Note that the current directory is not known in this posted fragment.
With bcc however, I KNOW that with:

bcc -c cclib/cclib.i

the .obj file will be cclib/cclib.obj, in the same directory, as that is
the clear intent. But with:

gcc -c cclib/cclib.i

I don't where the .o file will be; I will guess it is one directory
above. If the path was /cclib/cclib.i, then it could be anywhere in the
file system.

> I still don't see why a compiler should print out a line to say it is
> compiling the file you asked it to compile.  If I want that information,
> I have it in the command I typed in.

It is confirming the input file, output file, the extensions that will
be used, and the operations that can be done.

The output file is certainly not clear from what you typed:

gcc -shared -oprog prog.c

On Windows, this writes prog.exe, NOT prog.dll that you might expect.

The destination is not clear from what you typed:

root@DESKTOP-11:/mnt/c/c# gcc /abc/hello.c

The destination here is derived from the CWD, and will be
/mnt/c/c/hello.o. Not what you typed.

The operation being done is not clear from what you typed as that
depends on 'options' file:

gcc @options hello.c

The files being compiled are not always clear from what you typed:

gcc *.c
gcc @input

There could 1 file, or 1000 files. You're really not curious as to what
it's doing?

I've noticed that ./configure and makefile scripts are not usually
silent; quite the opposite! apt-get install likes to give a running
commentary too.

So verbosity is good when a tool is verbose. Verbosity is bad when a
tool usually says nothing. This sounds very much like defending or
excusing all the tools you use against ANY sort or criticism.

Summary:

gcc prog.c producing 0 bytes of output: Great
gcc prog.c -v producing 5000 bytes of output: Great
bcc prog producing 25 bytes of output: Terrible!

Have I summed up your view correctly?

On 01/09/2023 10:10, David Brown wrote:
> On 01/09/2023 00:18, Bart wrote:

>> And when there is a lot going on with gcc, you can get loads of
>> warnings and other crap scrolling up the screen. So, was there an
>> "error:" in there or not? I've no idea if it worked!
>
> Fix the problems in your source code (or choice of flags to the
> compiler) - if you are getting screenfuls of errors or warnings, it is
> irrelevant whether an output file was generated or not.

We are talking about compilers like gcc where you make up your own rules
as to show strictly you want your program treated:

gcc prog.c zero warnings, writes .exe
gcc @options prog.c 10000 warnings, but it still writes .exe
gcc @options prog.c 10000 warning and 1 error, no .exe

In the first two cases, the .exe runs fine. I've just asked it to be
more picky. It's telling the difference between the last two that is the
problem. The one error is buried in those warnings. There is no summary
at the end.

This is where you need to use half a dozen ways to figure out:

DID IT WORK?

DID IT NOT WORK?

Because the compiler, aften 30,000 lines of output, decides it would be
too verbose to print a one-line summary.

With bcc, in order to more easily detect a silent crash, I added a
confirmation message, but it is subtle (it was for my use).

bcc prog.c
Compiling prog.c to prog.exe

When it finished it adds a full-stop:

Compiling prog.c to prog.exe.

If there was an error, it will report the error and stop. There is only
the one error, and there are no warnings.

With lccwin32, if there are any errors or warnings, it will summarise as:

2 errors, 0 warnings

It's really not hard.

On 01/09/2023 13:01, Bart wrote:
> On 01/09/2023 10:10, David Brown wrote:
>> On 01/09/2023 00:18, Bart wrote:
>
>
>>> And when there is a lot going on with gcc, you can get loads of
>>> warnings and other crap scrolling up the screen. So, was there an
>>> "error:" in there or not? I've no idea if it worked!
>>
>> Fix the problems in your source code (or choice of flags to the
>> compiler) - if you are getting screenfuls of errors or warnings, it is
>> irrelevant whether an output file was generated or not.
>
> We are talking about compilers like gcc where you make up your own rules
> as to show strictly you want your program treated:
>
>  gcc prog.c              zero warnings, writes .exe
>  gcc @options prog.c     10000 warnings, but it still writes .exe
>  gcc @options prog.c     10000 warning and 1 error, no .exe
>
> In the first two cases, the .exe runs fine. I've just asked it to be
> more picky. It's telling the difference between the last two that is the
> problem. The one error is buried in those warnings. There is no summary
> at the end.
>
> This is where you need to use half a dozen ways to figure out:
>
>   DID IT WORK?
>
>   DID IT NOT WORK?

I think a more interesting question here is "Do you want it to work?"
And the answer, of course, is "No" - you don't want it to work, you
don't want to know how to get it to work, or how to find out what went
wrong. If you ever listened to advice, suggestions or help, or tried to
make things work rather than working so hard to get failures, you might
accidentally discover that gcc is usable after all. And that would be
just terrible for you.

You have such a strong emotional investment in the idea that you are
always right, all your opinions are the best, your languages and tools
are perfect, while all other languages and tools are utterly useless and
all other opinions are completely wrong, that contradictory evidence
would be devastating. It must be very difficult for you, being so fragile.

On 01/09/2023 11:17, Malcolm McLean wrote:
> On Friday, 1 September 2023 at 09:43:43 UTC+1, David Brown wrote:
>>
>> Putting object files in the current directory is a useful default. It
>> won't suit everyone, but it will suit some people. And since almost
>> anyone who has an "everything in one directory" structure will be in
>> that directory when they run their compiler (or make, or whatever), it
>> would give the same effect as your compiler's default choice.
>>
>> I really don't understand what you have against it - other than your
>> knee-jerk reaction of "gcc does it, therefore it must be terrible and I
>> must invent absurd situations to justify myself".
>>
> It was the old way of doing things.

It is also the current way of doing things for smaller projects. And
out of tree builds are not new.

People prefer different ways of arranging their builds, which is
absolutely fine.

> Noways most people prefer the "out of tree build".

Some do, some don't, and some do for some projects and not others.
Unless you have the statistics to prove it, please don't try to speak
for "most people".

I also usually prefer out-of-tree builds for bigger projects (but I find
in-tree builds convenient for small single-file programs). But "you and
I" does not mean "most people".

> Basically your valuable,
> human-generated, human-meaningful source files go in one directory,
> the object files and various other intermediates automatically generated by
> tools are sequestrated in another directory.

> The new way is in my view a lot better, but it does make it a bit more difficult
> to set up tools like "make".

It's not hard at all. You do have to consider it in the makefile, but I
would not classify it as "difficult".

On 01/09/2023 12:35, Bart wrote:
> On 01/09/2023 09:43, David Brown wrote:
>> On 31/08/2023 21:26, Bart wrote:
>
>> Putting object files in the current directory is a useful default.
>
> 'gcc -c' will do that if the input file is in the same current directory.
>
> So if the current directory happens to be /abc, compiling hello.c will
> produce /abc/hello.o from /abc/hello.c.
>
> Everyone has been saying, do the build from inside the source directory.
> They've also been saying don't put the object file in the source directory!

Really? Everyone?

Do you bother to read the posts here, or do you just cherry-pick a few
snippets that you can complain about?

I have said /many/ times that sometimes people what out-of-tree builds,
and sometimes they want in-tree builds, and that there are pros and cons
of each. Generally you are better with out-of-tree builds for big
projects, while it can be convenient with in-tree builds for small projects.

Will you please acknowledge that you have read that paragraph, and that
you understand it, so that we can go on?

>
> That means gcc breaks that rule by default. But look at this pattern:
>
>                               Object file written to:
>
>   abc> gcc hello.c            /abc/hello.o
>   abc> gcc /abc/hello.c       /abc/hello.o
>   xyz> gcc /abc/hello.c       /xyz/hello.o
>
> This looks wrong.

It only looks wrong because you make it look wrong. Every time, the
file is written to "./hello.o". Simple and consistent. And if that's
not what you want, then specify the output file that you /do/ want. (Or
write a wrapper. Or use make. Or do one of a dozen alternatives that
get you what you wanted, rather than bursting a blood vessel and blaming
the wrong people for your own wilful and self-created problems.)

>
>> It won't suit everyone, but it will suit some people.  And since
>> almost anyone who has an "everything in one directory" structure will
>> be in that directory when they run their compiler (or make, or
>> whatever), it would give the same effect as your compiler's default
>> choice.
>>
>> I really don't understand what you have against it - other than your
>> knee-jerk reaction of "gcc does it, therefore it must be terrible
>
> Or "gcc does it, therefore it must be OK, and the model of how all
> software must work"

No one has /ever/ said anything of the sort. You are tilting at
windmills again.

>
> If I give gcc 100 files to build, will it finish it in a few seconds, or
> do I go and make a drink? Simply listing the same of each file will give
> a useful indication of where it's up to and how until it's done.

I suggest you don't bother with gcc - just go and have that drink.
Maybe you'll feel better.

>
> Presumably, you can't see the point of those progress bars you see in GUIs?

Presumably you are making stuff up again.

I would suggest that the answer to your problem is that you should not
call gcc on 100 files - the normal practice is to use make (or something
similar) to call gcc a hundred times on one file at a time, taking
advantage of modern multi-core machines, skipping unnecessary re-builds,
and generally being more efficient. (And also printing out "Compiling
file.c" lines if you want.) But I'll keep quite, because I know you
don't want a useful suggestion that would hinder you in your god-given
right to be the pain in your own arse.

>
> Have I summed up your view correctly?
>

No, but that is only to be expected from you.

On 01/09/2023 12:01, Bart wrote:
> On 01/09/2023 10:10, David Brown wrote:
>> On 01/09/2023 00:18, Bart wrote:
>
>
>>> And when there is a lot going on with gcc, you can get loads of
>>> warnings and other crap scrolling up the screen. So, was there an
>>> "error:" in there or not? I've no idea if it worked!
>>
>> Fix the problems in your source code (or choice of flags to the
>> compiler) - if you are getting screenfuls of errors or warnings, it is
>> irrelevant whether an output file was generated or not.
>
> We are talking about compilers like gcc where you make up your own rules
> as to show strictly you want your program treated:
>
>  gcc prog.c              zero warnings, writes .exe
>  gcc @options prog.c     10000 warnings, but it still writes .exe
>  gcc @options prog.c     10000 warning and 1 error, no .exe

Don't worry about 10,000 warnings/errors; Fix the first one, and
recompile. Rinse/Repeat.

On Friday, 1 September 2023 at 11:36:09 UTC+1, Bart wrote:
>
> Everyone has been saying, do the build from inside the source directory.
> They've also been saying don't put the object file in the source directory!
>
You don't want human-generated, human-readable, and therefore quite
valuable files mixed with computer-generated intermediate files which
are worthless except as intermediates, and usually only on that platform.

But the normal answer is to create a "build" directory under the root of
the source directory which you wrote yourself, or downloaded. Then all
the compiler products and other cruft goes in there. You don't put anything
of much value in the "build" directory, and if something goes badly wrong,
often something to try is to delete it and start a clean rebuild.
>
> That means gcc breaks that rule by default. But look at this pattern:
>
> Object file written to:
>
> abc> gcc hello.c /abc/hello.o
> abc> gcc /abc/hello.c /abc/hello.o
> xyz> gcc /abc/hello.c /xyz/hello.o
>
> This looks wrong.
>
It's not too bad.

You download

whizzyproject
...................documents
...................source

you make a new directory, build, under whizzyproject

build> gcc ../source/*.c

will create a.out in the build directory.
>
> If I give gcc 100 files to build, will it finish it in a few seconds, or
> do I go and make a drink? Simply listing the same of each file will give
> a useful indication of where it's up to and how until it's done.
>
Who knows. But it's not really a useful indication because C source files
can vary wildly in length and complexity. The optimisation problem reduces
to the halting problem, after all.
However I agree that it;s nice to have a pacifier. Also, if the compiler crashes
out or hangs whilst compiling barts_special_file.c, then it helps that its last
message was "compiling barts_speciaL_file.c".

On 01/09/2023 13:08, Richard Harnden wrote:
> On 01/09/2023 12:01, Bart wrote:
>> On 01/09/2023 10:10, David Brown wrote:
>>> On 01/09/2023 00:18, Bart wrote:
>>
>>
>>>> And when there is a lot going on with gcc, you can get loads of
>>>> warnings and other crap scrolling up the screen. So, was there an
>>>> "error:" in there or not? I've no idea if it worked!
>>>
>>> Fix the problems in your source code (or choice of flags to the
>>> compiler) - if you are getting screenfuls of errors or warnings, it
>>> is irrelevant whether an output file was generated or not.
>>
>> We are talking about compilers like gcc where you make up your own
>> rules as to show strictly you want your program treated:
>>
>>   gcc prog.c              zero warnings, writes .exe
>>   gcc @options prog.c     10000 warnings, but it still writes .exe
>>   gcc @options prog.c     10000 warning and 1 error, no .exe
>
> Don't worry about 10,000 warnings/errors; Fix the first one, and
> recompile.  Rinse/Repeat.

You're joking, right? Maybe some of them I need to do something about,
but most of them are irrelevant:

cc.c:5363:5: warning: ISO C forbids initialization between function
pointer and 'void *' [-Wpedantic]
5363 | &cc_genasm$stropndx,
| ^

You can't turn a 64-bit void* pointer on x64 into a 64-bit function
pointer? **** off!

Or unused labels. Or unused parameters (in a suite of functions that
must share the same set).

How do I discover the important ones?

This is for generated code. The fact is, WHATEVER I do, somebody can
just ramp up the options further to make it show a diagnostic.

The simple solution is for me to stipulate the compile options, or for
me to control the process (by my backend invoking the compiler directly).

Apparently, you can do that with gcc: it's one positive, if bizarre,
aspect of it.

It's bizarre because *I*, as user, have to tell an actual C compiler how
to compile my code, what to treat seriously, and what to disregard.

In other words, I have to do half its job for it. Including finding out
whether it's has succeeded!

On 01/09/2023 12:39, David Brown wrote:
> On 01/09/2023 12:35, Bart wrote:

>>                                Object file written to:
>>
>>    abc> gcc hello.c            /abc/hello.o
>>    abc> gcc /abc/hello.c       /abc/hello.o
>>    xyz> gcc /abc/hello.c       /xyz/hello.o
>>
>> This looks wrong.
>
> It only looks wrong because you make it look wrong.  Every time, the
> file is written to "./hello.o".  Simple and consistent.

And dangerous, since "." is variable. And it can't be consistent since
that third line writes it to xyz not abc. With bcc (excuse use of /
rather than \):

abc> bcc hello.c /abc/hello.obj
abc> bcc /abc/hello.c /abc/hello.obj
xyz> bcc /abc/hello.c /abc/hello.obj

Position-independent compilation!

>> Or "gcc does it, therefore it must be OK, and the model of how all
>> software must work"
>
> No one has /ever/ said anything of the sort.  You are tilting at
> windmills again.
>
>>
>> If I give gcc 100 files to build, will it finish it in a few seconds,
>> or do I go and make a drink? Simply listing the same of each file will
>> give a useful indication of where it's up to and how until it's done.
>
> I suggest you don't bother with gcc - just go and have that drink. Maybe
> you'll feel better.
>
>>
>> Presumably, you can't see the point of those progress bars you see in
>> GUIs?
>
> Presumably you are making stuff up again.

And you're not answering the question. Progress bars obviously ARE
useful, but not for a compiler?

>> Have I summed up your view correctly?
>>
>
> No, but that is only to be expected from you.

Have I then summed up the capabilities of gcc correctly?

That it either it says nothing, or spouts pages of nonsense.

But then, you don't really care do you, as you mainly use such compilers
from inside a script, where its behaviour is carefully orchestrated.

So the actual problems others experience are no skin off your nose.

I'm glad that my own product is friendlier, helps with such problems,
and is amenable to being tweaked according to suggestions.

On 01/09/2023 14:39, Bart wrote:
> On 01/09/2023 13:08, Richard Harnden wrote:
>> On 01/09/2023 12:01, Bart wrote:
>>> On 01/09/2023 10:10, David Brown wrote:
>>>> On 01/09/2023 00:18, Bart wrote:
>>>
>>>
>>>>> And when there is a lot going on with gcc, you can get loads of
>>>>> warnings and other crap scrolling up the screen. So, was there an
>>>>> "error:" in there or not? I've no idea if it worked!
>>>>
>>>> Fix the problems in your source code (or choice of flags to the
>>>> compiler) - if you are getting screenfuls of errors or warnings, it
>>>> is irrelevant whether an output file was generated or not.
>>>
>>> We are talking about compilers like gcc where you make up your own
>>> rules as to show strictly you want your program treated:
>>>
>>>   gcc prog.c              zero warnings, writes .exe
>>>   gcc @options prog.c     10000 warnings, but it still writes .exe
>>>   gcc @options prog.c     10000 warning and 1 error, no .exe
>>
>> Don't worry about 10,000 warnings/errors; Fix the first one, and
>> recompile.  Rinse/Repeat.
>
> You're joking, right? Maybe some of them I need to do something about,
> but most of them are irrelevant:
>
> cc.c:5363:5: warning: ISO C forbids initialization between function
> pointer and 'void *' [-Wpedantic]
>  5363 |     &cc_genasm$stropndx,
>       |     ^
>
> You can't turn a 64-bit void* pointer on x64 into a 64-bit function
> pointer? **** off!
>
>
> Or unused labels. Or unused parameters (in a suite of functions that
> must share the same set).
>
> How do I discover the important ones?
>
> This is for generated code. The fact is, WHATEVER I do, somebody can
> just ramp up the options further to make it show a diagnostic.
>
> The simple solution is for me to stipulate the compile options, or for
> me to control the process (by my backend invoking the compiler directly).
>
> Apparently, you can do that with gcc: it's one positive, if bizarre,
> aspect of it.
>
> It's bizarre because *I*, as user, have to tell an actual C compiler how
> to compile my code, what to treat seriously, and what to disregard.
>
> In other words, I have to do half its job for it. Including finding out
> whether it's has succeeded!

If you ever decide you want to learn C, you can always ask here for help.

The same applies if you ever decide you want to learn how to use gcc
(though of course some people here will say it is off-topic).

All that will be asked of you, is that you ask politely and listen to
the answers, and do your best to understand. It's not actually very hard.

On 01/09/2023 13:39, Bart wrote:
> On 01/09/2023 13:08, Richard Harnden wrote:
>> On 01/09/2023 12:01, Bart wrote:
>>> On 01/09/2023 10:10, David Brown wrote:
>>>> On 01/09/2023 00:18, Bart wrote:
>>>
>>>
>>>>> And when there is a lot going on with gcc, you can get loads of
>>>>> warnings and other crap scrolling up the screen. So, was there an
>>>>> "error:" in there or not? I've no idea if it worked!
>>>>
>>>> Fix the problems in your source code (or choice of flags to the
>>>> compiler) - if you are getting screenfuls of errors or warnings, it
>>>> is irrelevant whether an output file was generated or not.
>>>
>>> We are talking about compilers like gcc where you make up your own
>>> rules as to show strictly you want your program treated:
>>>
>>>   gcc prog.c              zero warnings, writes .exe
>>>   gcc @options prog.c     10000 warnings, but it still writes .exe
>>>   gcc @options prog.c     10000 warning and 1 error, no .exe
>>
>> Don't worry about 10,000 warnings/errors; Fix the first one, and
>> recompile.  Rinse/Repeat.
>
> You're joking, right? Maybe some of them I need to do something about,
> but most of them are irrelevant:

No. 10,000 warnings is ridiculus.

>
> cc.c:5363:5: warning: ISO C forbids initialization between function
> pointer and 'void *' [-Wpedantic]
>  5363 |     &cc_genasm$stropndx,
>       |     ^
>
> You can't turn a 64-bit void* pointer on x64 into a 64-bit function
> pointer? **** off!

You could use actual function pointers that have the correct signature?
You don't really call every function thru one single void*?

>
>
> Or unused labels. Or unused parameters (in a suite of functions that
> must share the same set).

So, shut the warning up. Otherwise it's just noise.
Most people say:
(void) unused_var;

>
> How do I discover the important ones?

By fixing the unimportant ones.

>
> This is for generated code. The fact is, WHATEVER I do, somebody can
> just ramp up the options further to make it show a diagnostic.

Maybe fix the generator to produce correct code in the first place?

>
> The simple solution is for me to stipulate the compile options, or for
> me to control the process (by my backend invoking the compiler directly).
>
> Apparently, you can do that with gcc: it's one positive, if bizarre,
> aspect of it.
>
> It's bizarre because *I*, as user, have to tell an actual C compiler how
> to compile my code, what to treat seriously, and what to disregard.
>
> In other words, I have to do half its job for it. Including finding out
> whether it's has succeeded!

On 01/09/2023 15:09, Bart wrote:
> On 01/09/2023 12:39, David Brown wrote:
>> On 01/09/2023 12:35, Bart wrote:
>
>>>                                Object file written to:
>>>
>>>    abc> gcc hello.c            /abc/hello.o
>>>    abc> gcc /abc/hello.c       /abc/hello.o
>>>    xyz> gcc /abc/hello.c       /xyz/hello.o
>>>
>>> This looks wrong.
>>
>> It only looks wrong because you make it look wrong.  Every time, the
>> file is written to "./hello.o".  Simple and consistent.
>
> And dangerous, since "." is variable. And it can't be consistent since
> that third line writes it to xyz not abc. With bcc (excuse use of /
> rather than \):
>
>
>    abc> bcc hello.c            /abc/hello.obj
>    abc> bcc /abc/hello.c       /abc/hello.obj
>    xyz> bcc /abc/hello.c       /abc/hello.obj
>
> Position-independent compilation!
>
>>> Or "gcc does it, therefore it must be OK, and the model of how all
>>> software must work"
>>
>> No one has /ever/ said anything of the sort.  You are tilting at
>> windmills again.
>>
>>>
>>> If I give gcc 100 files to build, will it finish it in a few seconds,
>>> or do I go and make a drink? Simply listing the same of each file
>>> will give a useful indication of where it's up to and how until it's
>>> done.
>>
>> I suggest you don't bother with gcc - just go and have that drink.
>> Maybe you'll feel better.
>>
>>>
>>> Presumably, you can't see the point of those progress bars you see in
>>> GUIs?
>>
>> Presumably you are making stuff up again.
>
> And you're not answering the question. Progress bars obviously ARE
> useful, but not for a compiler?
>

I presumed your question was rhetorical. Were you really asking
something that stupid? (And that was a rhetorical question.)

>>> Have I summed up your view correctly?
>>>
>>
>> No, but that is only to be expected from you.
>
> Have I then summed up the capabilities of gcc correctly?

No.

>
> That it either it says nothing, or spouts pages of nonsense.

No.

>
> But then, you don't really care do you, as you mainly use such compilers
> from inside a script, where its behaviour is carefully orchestrated.

No.

>
> So the actual problems others experience are no skin off your nose.

No.

>
> I'm glad that my own product is friendlier, helps with such problems,
> and is amenable to being tweaked according to suggestions.
>

No.

Were there more inaccuracies you want to make up? Any time you want to
change from rant mode to listen mode, just let me know.

Bart <bc@freeuk.com> writes:

> On 01/09/2023 13:08, Richard Harnden wrote:
>> On 01/09/2023 12:01, Bart wrote:

>>> We are talking about compilers like gcc where you make up your own rules
>>> as to show strictly you want your program treated:
>>>
>>>   gcc prog.c              zero warnings, writes .exe
>>>   gcc @options prog.c     10000 warnings, but it still writes .exe
>>>   gcc @options prog.c     10000 warning and 1 error, no .exe

Which would you choose as the one and only behaviour?

>> Don't worry about 10,000 warnings/errors; Fix the first one, and
>> recompile.  Rinse/Repeat.
>
> You're joking, right? Maybe some of them I need to do something about, but
> most of them are irrelevant:
>
> cc.c:5363:5: warning: ISO C forbids initialization between function pointer
> and 'void *' [-Wpedantic]
> 5363 | &cc_genasm$stropndx,
> | ^
>
> You can't turn a 64-bit void* pointer on x64 into a 64-bit function
> pointer?

You asked for the program to be checked 'pedantically' and now you are
complaining about that. If you don't want to know if your code violates
any of C's rules, why ask?

> Or unused labels. Or unused parameters (in a suite of functions that must
> share the same set).
>
> How do I discover the important ones?

It's up to you. That's the whole point. When I was porting code to a
machine with distinct code and data address formats, I would have loved
a warning like the one above, but the C compiler was not that helpful.
Only you know if you want your code to be highly portable or not; gcc
can't possibly know.

> This is for generated code. The fact is, WHATEVER I do, somebody can just
> ramp up the options further to make it show a diagnostic.

Is that true? #pragma GCC diagnostic "-Wno-xxxx" lines are not
overruled by command line warning options, but there may be a way to
force these to be ignored.

Anyway, why do you mind? The person ramping up the options is probably
doing so for some reason, but even it's just for fun of it, it's on
them.

--
Ben.

On 01/09/2023 14:53, Ben Bacarisse wrote:
> Bart <bc@freeuk.com> writes:
>
>> On 01/09/2023 13:08, Richard Harnden wrote:
>>> On 01/09/2023 12:01, Bart wrote:
>
>>>> We are talking about compilers like gcc where you make up your own rules
>>>> as to show strictly you want your program treated:
>>>>
>>>>   gcc prog.c              zero warnings, writes .exe
>>>>   gcc @options prog.c     10000 warnings, but it still writes .exe
>>>>   gcc @options prog.c     10000 warning and 1 error, no .exe
>
> Which would you choose as the one and only behaviour?
>
>>> Don't worry about 10,000 warnings/errors; Fix the first one, and
>>> recompile.  Rinse/Repeat.
>>
>> You're joking, right? Maybe some of them I need to do something about, but
>> most of them are irrelevant:
>>
>> cc.c:5363:5: warning: ISO C forbids initialization between function pointer
>> and 'void *' [-Wpedantic]
>> 5363 | &cc_genasm$stropndx,
>> | ^
>>
>> You can't turn a 64-bit void* pointer on x64 into a 64-bit function
>> pointer?
>
> You asked for the program to be checked 'pedantically' and now you are
> complaining about that. If you don't want to know if your code violates
> any of C's rules, why ask?

This is what happened in 2014 when I first posted some generated C code
here. People would apply all sorts of advanced warning levels.

But was there an actual bug in my program or not? If there was, why
wasn't it caught with 'gcc prog.c' and why did it proceed to generate an
executable?

(The object/function pointer issue wasn't of great interest. In both the
source language and known targets the conversion (actually, a no-op) is
well-defined. Only some C compilers get uppity about it.

There might have reason to do so on some exotic architecture, but then,
you can get around it by a double-conversion via an intermediate
integer, then those reasons appear to go out the window.

My generated code can also contains lots of usused labels. I'm sure that
one is not dangerous. But if people are applying their own compile
options, they can also apply the ones to shut up those warnings.)

>> Or unused labels. Or unused parameters (in a suite of functions that must
>> share the same set).
>>
>> How do I discover the important ones?
>
> It's up to you. That's the whole point. When I was porting code to a
> machine with distinct code and data address formats, I would have loved
> a warning like the one above, but the C compiler was not that helpful.
> Only you know if you want your code to be highly portable or not; gcc
> can't possibly know.

Then it needs a -Wportable check.

>> This is for generated code. The fact is, WHATEVER I do, somebody can just
>> ramp up the options further to make it show a diagnostic.
>
> Is that true? #pragma GCC diagnostic "-Wno-xxxx" lines are not
> overruled by command line warning options, but there may be a way to
> force these to be ignored.

Those don't always work. At least this doesn't:

#pragma GCC diagnostic ignored "-Wbuiltin-declaration-mismatch"

It works on Windows gcc but not WSL gcc.

In any case I would now stipulate the essential options, leaving only
ones like -o and -O to the user.

> Anyway, why do you mind? The person ramping up the options is probably
> doing so for some reason, but even it's just for fun of it, it's on
> them.

It's an example of gcc hiding a potential needle in a haystack of
warnings and notes. Was there anything important in there like an actual
'error:' line?

On 01/09/2023 15:32, Richard Harnden wrote:
> On 01/09/2023 13:39, Bart wrote:
>> On 01/09/2023 13:08, Richard Harnden wrote:
>>> On 01/09/2023 12:01, Bart wrote:
>>>> On 01/09/2023 10:10, David Brown wrote:
>>>>> On 01/09/2023 00:18, Bart wrote:
>>>>
>>>>
>>>>>> And when there is a lot going on with gcc, you can get loads of
>>>>>> warnings and other crap scrolling up the screen. So, was there an
>>>>>> "error:" in there or not? I've no idea if it worked!
>>>>>
>>>>> Fix the problems in your source code (or choice of flags to the
>>>>> compiler) - if you are getting screenfuls of errors or warnings, it
>>>>> is irrelevant whether an output file was generated or not.
>>>>
>>>> We are talking about compilers like gcc where you make up your own
>>>> rules as to show strictly you want your program treated:
>>>>
>>>>   gcc prog.c              zero warnings, writes .exe
>>>>   gcc @options prog.c     10000 warnings, but it still writes .exe
>>>>   gcc @options prog.c     10000 warning and 1 error, no .exe
>>>
>>> Don't worry about 10,000 warnings/errors; Fix the first one, and
>>> recompile.  Rinse/Repeat.
>>
>> You're joking, right? Maybe some of them I need to do something about,
>> but most of them are irrelevant:
>
> No.  10,000 warnings is ridiculus.

Yes. It's because he does silly things (like using "void *" for
function pointers), and because he views warnings as all or nothing -
for Bart, it's either "gcc" or "gcc -Wall -Wextra", just as optimisation
is always either "-O0" or "-O3". Taking advice, reading manuals, or
knowing what he is doing are not his specialities.

>
>>
>> cc.c:5363:5: warning: ISO C forbids initialization between function
>> pointer and 'void *' [-Wpedantic]
>>   5363 |     &cc_genasm$stropndx,
>>        |     ^
>>
>> You can't turn a 64-bit void* pointer on x64 into a 64-bit function
>> pointer? **** off!
>
> You could use actual function pointers that have the correct signature?

He has been told countless times that, at the very least, "void*(void)"
would be hugely better.

> You don't really call every function thru one single void*?

Yes, he converts pretty much everything to "void*".

>
>>
>>
>> Or unused labels. Or unused parameters (in a suite of functions that
>> must share the same set).

In C23, unused parameters can be left unnamed - though apparently that
is an abomination in Bart's eyes.

>
> So, shut the warning up.  Otherwise it's just noise.
> Most people say:
> (void) unused_var;

Or use -Wno-unused-parameters -Wno-unused-labels, etc.

Or use #pragma GCC diagnostic ignored "-Wunused".

Or stop generating unused labels.

There are plenty of possibilities.

>
>>
>> How do I discover the important ones?
>
> By fixing the unimportant ones.
>
>>
>> This is for generated code. The fact is, WHATEVER I do, somebody can
>> just ramp up the options further to make it show a diagnostic.
>
> Maybe fix the generator to produce correct code in the first place?

And if the generator produces things like extra unused labels (it's not
uncommon), it could also generate pragmas to disable those warnings even
if the user had enabled them at the command line.

It would also make a great deal of sense to have pragmas for "-fwrapv"
and "-fno-strict-aliasing", since Bart's code generator requires these.

>
>>
>> The simple solution is for me to stipulate the compile options, or for
>> me to control the process (by my backend invoking the compiler directly).
>>
>> Apparently, you can do that with gcc: it's one positive, if bizarre,
>> aspect of it.
>>
>> It's bizarre because *I*, as user, have to tell an actual C compiler
>> how to compile my code, what to treat seriously, and what to disregard.
>>
>> In other words, I have to do half its job for it. Including finding
>> out whether it's has succeeded!
>

On 2023-09-01, Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote:
> On Friday, 1 September 2023 at 00:32:03 UTC+1, Kaz Kylheku wrote:
>>
>> Building other people's projects can suck. It sucks not just for
>> Bart but for the rest of us who don't mind the defaults and conventions.
>>
>> FOSS projects are written by volunteers. They don't owe you anything,
>> including a build system that works how you would like.
>>
>> It's sad that people do counterproductive things to their programs, like
>> vandalize their build systems with Autoconf, just because that's what
>> others have done and they read about it in some blog or tutorial.
>>
> Bart's basic complaint is right.

It is off topic and misdirected, though.

> It's too hard to build many projects, and

That's the fault of those projects, whose maintainers don't read this
newsgroup, and wouldn't change anything if they did.

So the complaining is completely useless.

It's like joining a cooking club, to complain about restaurant prices,
or the design of mixers and spatulas.

Probably a few regulars here work on some open source projects that
Bart might find hard to build.

Without a

- comphrehensive, realistic proposal;

- accompanied by a patch;

- that works on all supported platforms;

- and can be easily extended to new platforms;

- and is demonstrably better than the current system;

I wouldn't lift a finger. Fixing a build system is just risk that's
not even in the program. Breaking builds will make your program look
immature; possibly a deal breaker for a prospective user.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

On 2023-09-01, Bart <bc@freeuk.com> wrote:
> On 01/09/2023 09:43, David Brown wrote:
>> On 31/08/2023 21:26, Bart wrote:
>
>> Putting object files in the current directory is a useful default.
>
> 'gcc -c' will do that if the input file is in the same current directory.
>
> So if the current directory happens to be /abc, compiling hello.c will
> produce /abc/hello.o from /abc/hello.c.

You are right. I didn't even notice that or forgot about it all these
years. -c is only used in very trivial makefiles.

The built-in make recipe doesn't use it; it uses -o so that if you say,

obj/foo.o: src/foo.c

it works fine. According to the gcc man page, I would think that
-c turns src/foo.c into src/foo.o.

Quote

By default, the object file name for a source file is made by
replacing the suffix .c, .i, .s, etc., with .o.

That's literally saying src/foo.c becomes src/foo.o. If
src/foo.c becomes foo.o, then the way to describe it is:

By default, the object file name for a source file is made by
taking the base name of the source file, removing any directory path
components, and replacing the suffix .c, .i, .s, etc., with .o.

> Everyone has been saying, do the build from inside the source directory.

More generally, you do the build from a build directory. That is almost
tautological. If you're building there, it's a build directory.

It's okay for the build directory to be the source directory.

Many FOSS projects support both modes: you can build in the source
directory, or you can create a separate build directory and configure
from there and build from there.

(AutoConf projects are like this, ideally. Some maintainers don't test
building in a separate directory, and also do something clever which
breaks it. Downstream distro packagers then work around it somehow,
without submitting a fix upstream.)

> They've also been saying don't put the object file in the source directory!

David pointed out advantages in not doing that, even if the project is
being built from within its source tree (not in a separate
build directory). This is not some hard and fast rule, though.

> That means gcc breaks that rule by default. But look at this pattern:

> Object file written to:
>
> abc> gcc hello.c /abc/hello.o
> abc> gcc /abc/hello.c /abc/hello.o
> xyz> gcc /abc/hello.c /xyz/hello.o
>
> This looks wrong.

Yes; so people who write their own build script or use their own make
recipe for .c to .o instead of the built-in one, will soon discover that
it isn't doing what they want. They will stop relyin gon using -c
without -o, one way or another: fix their script, fix their custom build
recipe, or use the built-in one.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

On 2023-09-01, Bart <bc@freeuk.com> wrote:
> On 01/09/2023 10:10, David Brown wrote:
>> On 01/09/2023 00:18, Bart wrote:
>
>
>>> And when there is a lot going on with gcc, you can get loads of
>>> warnings and other crap scrolling up the screen. So, was there an
>>> "error:" in there or not? I've no idea if it worked!
>>
>> Fix the problems in your source code (or choice of flags to the
>> compiler) - if you are getting screenfuls of errors or warnings, it is
>> irrelevant whether an output file was generated or not.
>
> We are talking about compilers like gcc where you make up your own rules
> as to show strictly you want your program treated:
>
> gcc prog.c zero warnings, writes .exe
> gcc @options prog.c 10000 warnings, but it still writes .exe
> gcc @options prog.c 10000 warning and 1 error, no .exe

Firstly, gcc is a front end to multiple languages, including multiple
dialects to C. Some things which are fine in one dialect are errors
in another.

Everything you've ever done on any of your own compilers that was
not a pure refactoring or code cleanup change, everything,
always created a new dialect in which something worked that
previously did not work, and for which a test case could be written
which works with the changed compiler and fails with the previous
one before the change.

You can also tweak the diagnosis rules in GCC, so that something that is
a warning can be treated as a fatal error.

Users want this, and you will not pry it out of their hands.

What have you ever done in any of your compilers to support a user
whose code base uses your language, but from five years ago?

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

On 01/09/2023 14:32, Richard Harnden wrote:
> On 01/09/2023 13:39, Bart wrote:

>> You're joking, right? Maybe some of them I need to do something about,
>> but most of them are irrelevant:
>
> No.  10,000 warnings is ridiculus.
>
>>
>> cc.c:5363:5: warning: ISO C forbids initialization between function
>> pointer and 'void *' [-Wpedantic]
>>   5363 |     &cc_genasm$stropndx,
>>        |     ^
>>
>> You can't turn a 64-bit void* pointer on x64 into a 64-bit function
>> pointer? **** off!
>
> You could use actual function pointers that have the correct signature?
> You don't really call every function thru one single void*?

>
>>
>>
>> Or unused labels. Or unused parameters (in a suite of functions that
>> must share the same set).
>
> So, shut the warning up.  Otherwise it's just noise.
> Most people say:
> (void) unused_var;

I don't want to, and I shouldn't need to.

Here I'm using C as a portable assembler. In assembly, you don't need to
care about unused labels, unused parameters, or having a function
pointer in the same 64-bit register as an integer.

Generating C is supposed to make some things easier. It's not supposed
to make things harder!

If I compile my generated C with any of:

bcc prog
tcc prog.c
gcc prog.c -oprog

it works perfectly.

Unless there's actually something wrong with prog.c. In that case:

* Why doesn't gcc show any errors?
* Why not even warnings?
* Why is it generating an executable?

If the famous gcc thinks my program is OK, then that suits me fine.

If interpreting a 64-bit address as a function rather than object
pointer is such a no-no, then where's the hard error?

WHY is it letting such a serious infringement through?

Bart <bc@freeuk.com> writes:

> On 01/09/2023 14:53, Ben Bacarisse wrote:
>> Bart <bc@freeuk.com> writes:
>>
>>> On 01/09/2023 13:08, Richard Harnden wrote:
>>>> On 01/09/2023 12:01, Bart wrote:
>>
>>>>> We are talking about compilers like gcc where you make up your own rules
>>>>> as to show strictly you want your program treated:
>>>>>
>>>>>   gcc prog.c              zero warnings, writes .exe
>>>>>   gcc @options prog.c     10000 warnings, but it still writes .exe
>>>>>   gcc @options prog.c     10000 warning and 1 error, no .exe
>>
>> Which would you choose as the one and only behaviour?

No answer? I'll look at the rest of your post, if you decide to address
this point...

--
Ben.

On 01/09/2023 18:48, Kaz Kylheku wrote:
> On 2023-09-01, Bart <bc@freeuk.com> wrote:
>> On 01/09/2023 10:10, David Brown wrote:
>>> On 01/09/2023 00:18, Bart wrote:
>>
>>
>>>> And when there is a lot going on with gcc, you can get loads of
>>>> warnings and other crap scrolling up the screen. So, was there an
>>>> "error:" in there or not? I've no idea if it worked!
>>>
>>> Fix the problems in your source code (or choice of flags to the
>>> compiler) - if you are getting screenfuls of errors or warnings, it is
>>> irrelevant whether an output file was generated or not.
>>
>> We are talking about compilers like gcc where you make up your own rules
>> as to show strictly you want your program treated:
>>
>> gcc prog.c zero warnings, writes .exe
>> gcc @options prog.c 10000 warnings, but it still writes .exe
>> gcc @options prog.c 10000 warning and 1 error, no .exe
>
> Firstly, gcc is a front end to multiple languages, including multiple
> dialects to C. Some things which are fine in one dialect are errors
> in another.
>
> Everything you've ever done on any of your own compilers that was
> not a pure refactoring or code cleanup change, everything,
> always created a new dialect in which something worked that
> previously did not work, and for which a test case could be written
> which works with the changed compiler and fails with the previous
> one before the change.
>
> You can also tweak the diagnosis rules in GCC, so that something that is
> a warning can be treated as a fatal error.

> Users want this, and you will not pry it out of their hands.
>
> What have you ever done in any of your compilers to support a user
> whose code base uses your language, but from five years ago?
>

The first two examples above are for the exact same program.

For example, @options is '-Wall -Wextra -Wpedantic'; it is not defining
a new dialect.

While for errors, add -Werror, then you'll get a lot more than one!

Is my program correct? Apparently gcc can't tell me; *I* have to tell
*it*. You pretty much say that above.

OK, *I* say then that if 'gcc prog.c' works with no notes, warnings or
messages, then my program is fine.

On 2023-09-01, Bart <bc@freeuk.com> wrote:
> On 01/09/2023 13:08, Richard Harnden wrote:
>> On 01/09/2023 12:01, Bart wrote:
>>> On 01/09/2023 10:10, David Brown wrote:
>>>> On 01/09/2023 00:18, Bart wrote:
>>>
>>>
>>>>> And when there is a lot going on with gcc, you can get loads of
>>>>> warnings and other crap scrolling up the screen. So, was there an
>>>>> "error:" in there or not? I've no idea if it worked!
>>>>
>>>> Fix the problems in your source code (or choice of flags to the
>>>> compiler) - if you are getting screenfuls of errors or warnings, it
>>>> is irrelevant whether an output file was generated or not.
>>>
>>> We are talking about compilers like gcc where you make up your own
>>> rules as to show strictly you want your program treated:
>>>
>>>   gcc prog.c              zero warnings, writes .exe
>>>   gcc @options prog.c     10000 warnings, but it still writes .exe
>>>   gcc @options prog.c     10000 warning and 1 error, no .exe
>>
>> Don't worry about 10,000 warnings/errors; Fix the first one, and
>> recompile.  Rinse/Repeat.
>
> You're joking, right? Maybe some of them I need to do something about,
> but most of them are irrelevant:
>
> cc.c:5363:5: warning: ISO C forbids initialization between function
> pointer and 'void *' [-Wpedantic]
> 5363 | &cc_genasm$stropndx,
> | ^

The word "pedantic" is a slightly pejorative term. Someone in GCC,
perhaps Richard Stallman himself, introduced this diagnostic category in
order to capture certain overly nitpicky diagnostics required by ISO C.

Mainly these are in areas in which GNU C differs, providing a
nonconforming extension, like allowing a certain conversion. The
extension is only noncoforming because the required diagnostic is not
emitted; -Wpedantic makes it conforming.

-Wpedantic is used by those who are looking to write maximally portable
code that doesn't violate any ISO C constraint rule. Under -Wpedantic,
you will not accidentally use a GNU C extension.

If the code is relying on extensions like function pointer and
object conversions, it makes sense not to use -Wpedantic.

> You can't turn a 64-bit void* pointer on x64 into a 64-bit function
> pointer? **** off!

You obviously can, but ISO C requires a diagnostic. This is an extension
that makes sense on systems in which code and data are in the same
memory space, and the void * pointer is large enough to hold the
function pointer.

ISO C (a document you will likely only know about by word of mouth but
not actually read) lists this in its Annex as a common extension.

> Or unused labels. Or unused parameters (in a suite of functions that
> must share the same set).
>
> How do I discover the important ones?

By reading the GCC documentation, mainly.

One approach would be to use -Wall and perhaps -Wextra.

Then if you run into some bugs you can reactively check the compiler
documentation to answeer the question "could the compiler have
caught this issue?"

Or you can proactively do this: go "shopping" through the documentation
to get an idea of what kinds of diagnostics are available that look like
they might be useful for your project.

You can experiment with them to see whether they find something,
and what the false positive ratio is like.

> This is for generated code. The fact is, WHATEVER I do, somebody can
> just ramp up the options further to make it show a diagnostic.

If you trust your generated code, then disable warnings. Your
compiler front end should have done all the diagnosis, and the
C that is output is just being used as a "high level assembly language".

You, the compiler writer, should have done the groundwork to validate
that the way you're using the C language, with that specific compiler it
is intended for, yields the correct behavior which implements the intent
of your language.

You should dictate all code generation and diagnosis options.

Or else, you could write your compiler such that it outputs
strictly conforming ISO C, intended to be compiled by any compiler
with its highest or close-to-highest diagnostic levels.

Identify a target set of compilers and test with all of them,
working toward tweaking your generator to eliminate all warnings
(without generating code variants specific to any of the compilers).

That would mean that you don't get to convert function pointers
and void *.

Or you could target "almost strict ISO C, except that function pointers
are converted to and from void *".

> The simple solution is for me to stipulate the compile options, or for
> me to control the process (by my backend invoking the compiler directly).

That is wise.
>
> Apparently, you can do that with gcc: it's one positive, if bizarre,
> aspect of it.

What's bizarre about a tool having documented configuraton options which
it obeys?

> It's bizarre because *I*, as user, have to tell an actual C compiler how
> to compile my code, what to treat seriously, and what to disregard.

In the area of warnings, most warnings should be taken seriously.

But warnings are a an area of active development.

When GCC gets a new warning option, and people enable it, some
people find that it is triggered hundreds of times in their
code base.

So, they want that warning, but at the same time are inundated with
violations.

The configurability lets people choose.

E.g. a developer can be assigned to work (on a branch of the code)
to fix the hundreds of instances of the new warning. So GCC is
helpful to that workflow. The developer turns it on locally, gets
the diagnostics and goes about fixing them, making one or more
commits to the branch.

Then when his branch is merged to the product trunk, the warning
option can be turned on on the trunk.

Make sense?

Some projects turn all warnings into fatal errors. On such projects, the
shiny new diagnostic option cannot be turned on. It won't simply cause a
ream of nuisance messages in the build log, but fail the build.

> In other words, I have to do half its job for it. Including finding out
> whether it's has succeeded!

I don't think GCC ever terminates normally, with a failed termination
status, without emitting a diagnostic. (Maybe there is a special mode
for that?)

You must be running into a case where GCC is crashing (without having
emitted any diagnostic), and you're running it from a command
interpreter or other program which neglects to report that the child
program has abended.

Here is a dime, get a better command interpreter?

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

Kaz Kylheku <864-117-4973@kylheku.com> writes:
>On 2023-09-01, Bart <bc@freeuk.com> wrote:
>> On 01/09/2023 09:43, David Brown wrote:
>>> On 31/08/2023 21:26, Bart wrote:

>David pointed out advantages in not doing that, even if the project is
>being built from within its source tree (not in a separate
>build directory). This is not some hard and fast rule, though.
>
>> That means gcc breaks that rule by default. But look at this pattern:
>
>> Object file written to:
>>
>> abc> gcc hello.c /abc/hello.o
>> abc> gcc /abc/hello.c /abc/hello.o
>> xyz> gcc /abc/hello.c /xyz/hello.o
>>
>> This looks wrong.
>
>Yes; so people who write their own build script or use their own make
>recipe for .c to .o instead of the built-in one, will soon discover that
>it isn't doing what they want. They will stop relyin gon using -c
>without -o, one way or another: fix their script, fix their custom build
>recipe, or use the built-in one.

As a note, early C compilers did not support mixing -o and -c. That
capability came later.