Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #122589 > unrolled thread

Inlining of auto generated move constructor/assignment failed

Back to article view | Back to comp.lang.c++

Contents

  Inlining of auto generated move constructor/assignment failed Marcel Mueller <news.5.maazl@spamgourmet.org> - 2025-08-19 22:33 +0200
    Re: Inlining of auto generated move constructor/assignment failed Andrey Tarasevich <noone@noone.net> - 2025-08-20 22:58 -0700
      Re: Inlining of auto generated move constructor/assignment failed [solved] Marcel Mueller <news.5.maazl@spamgourmet.org> - 2025-08-23 10:41 +0200
        Re: Inlining of auto generated move constructor/assignment failed boltar@caprica.universe - 2025-08-23 09:14 +0000
          Re: Inlining of auto generated move constructor/assignment failed David Brown <david.brown@hesbynett.no> - 2025-08-23 16:15 +0200
            Re: Inlining of auto generated move constructor/assignment failed boltar@caprica.universe - 2025-08-23 14:26 +0000
              Re: Inlining of auto generated move constructor/assignment failed David Brown <david.brown@hesbynett.no> - 2025-08-24 14:45 +0200
                Re: Inlining of auto generated move constructor/assignment failed "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-08-24 12:56 -0700
                  Re: Inlining of auto generated move constructor/assignment failed "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-08-24 13:10 -0700
                  Re: Inlining of auto generated move constructor/assignment failed David Brown <david.brown@hesbynett.no> - 2025-08-25 08:19 +0200
                    Re: Inlining of auto generated move constructor/assignment failed "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-08-27 16:34 -0700
                Re: Inlining of auto generated move constructor/assignment failed boltar@caprica.universe - 2025-08-24 20:42 +0000
                  Re: Inlining of auto generated move constructor/assignment failed Ike Naar <ike@sdf.org> - 2025-08-25 06:52 +0000
                  Re: Inlining of auto generated move constructor/assignment failed scott@slp53.sl.home (Scott Lurndal) - 2025-08-25 14:27 +0000
                  Re: Inlining of auto generated move constructor/assignment failed David Brown <david.brown@hesbynett.no> - 2025-08-25 16:36 +0200
                    Re: Inlining of auto generated move constructor/assignment failed boltar@battlestar-galactica.com - 2025-08-25 20:01 +0000
                      Re: Inlining of auto generated move constructor/assignment failed David Brown <david.brown@hesbynett.no> - 2025-08-26 09:06 +0200
                        Re: Inlining of auto generated move constructor/assignment failed boltar@battlestar-galactica.com - 2025-08-26 18:30 +0000
                          Re: Inlining of auto generated move constructor/assignment failed David Brown <david.brown@hesbynett.no> - 2025-08-26 22:49 +0200
                            Re: Inlining of auto generated move constructor/assignment failed boltar@battlestar-galactica.com - 2025-08-27 15:39 +0000

#122589 — Inlining of auto generated move constructor/assignment failed

With newer gcc versions I often get warnings that inlining failed for 
auto-generated functions. Is this a bug or is the use of auto-generated 
functions not recommended for slightly larger structures?

Example: with

struct Recording
{	Guid id = Guid::empty;
	xStringD0 artist;
	xStringD0 title;
	double duration = 0.;
	float score = 0.;
	unsigned release_count = 0;
	std::unique_ptr<const Release[]> releases;
};

I get warnings like

warning: inlining failed in call to ‘Recording& 
Recording::operator=(Recording&&) noexcept’: --param 
max-inline-insns-single limit reached [-Winline]

- Guid is in fact char[16],
- xStringD0 is a (smart) pointer to a string with move assignment 
(noexcept, not constexpr because std::swap isn't),
- unique_ptr should be also just a pointer with move semantics.

OK, there are 3 members of non-POD type, any maybe inlining is not 
adequate. But shouldn't the compiler just take the best implementation?
Or are default generated functions necessarily forced to be inline?
In the latter case: how do I avoid to implement this functions 
explicitly. It is too easy to forget a new member in such implementations.

(C++14, gcc 13.3)


Marcel

[toc] | [next] | [standalone]

#122610

On Tue 8/19/2025 1:33 PM, Marcel Mueller wrote:
> 
> OK, there are 3 members of non-POD type, any maybe inlining is not 
> adequate. But shouldn't the compiler just take the best implementation?
> Or are default generated functions necessarily forced to be inline?

It might be a simple consequence of a lazy implementation.

The standard says that an implicitly declared copy/move assignment 
operator is an _inline_ public member of its class. So, it is quite 
possible that GCC just marks such functions internally as "inline". And 
later it issues a diagnostic when it fails to actually substitute some 
call, just like it would for any other inline function.

Obviously, this diagnostic would be more appropriate for situations when 
inlining was explicitly requested (or hinted at) by the user. But it is 
quite possible that at that point GCC simply can't tell inlining 
requested by the user from inlining of implicitly declared special 
member functions.

-- 
Best regards,
Andrey

[toc] | [prev] | [next] | [standalone]

#122613 — Re: Inlining of auto generated move constructor/assignment failed [solved]

Am 21.08.25 um 07:58 schrieb Andrey Tarasevich:
> On Tue 8/19/2025 1:33 PM, Marcel Mueller wrote:
>>
>> OK, there are 3 members of non-POD type, any maybe inlining is not 
>> adequate. But shouldn't the compiler just take the best implementation?
>> Or are default generated functions necessarily forced to be inline?
> 
> It might be a simple consequence of a lazy implementation.

It turned out that this kind of warning of gcc is normally turned off 
and not even activated by -Wextra. But some guy managed to explicitly 
enable this warning in a dark corner of the custom automake macros of 
the project. -.-


Marcel

[toc] | [prev] | [next] | [standalone]

#122614

On Sat, 23 Aug 2025 10:41:12 +0200
Marcel Mueller <news.5.maazl@spamgourmet.org> gabbled:
>Am 21.08.25 um 07:58 schrieb Andrey Tarasevich:
>> On Tue 8/19/2025 1:33 PM, Marcel Mueller wrote:
>>>
>>> OK, there are 3 members of non-POD type, any maybe inlining is not 
>>> adequate. But shouldn't the compiler just take the best implementation?
>>> Or are default generated functions necessarily forced to be inline?
>> 
>> It might be a simple consequence of a lazy implementation.
>
>It turned out that this kind of warning of gcc is normally turned off 
>and not even activated by -Wextra. But some guy managed to explicitly 
>enable this warning in a dark corner of the custom automake macros of 
>the project. -.-

As an aside, the inconsistency of gcc cmd line options wrt warnings and between
versions really pisses me off. It shouldn't even need -Wextra (or -pedantic) if
I've already given it -Wall because all funnily enough means all, it doesn't 
mean all except some random ones - which seem to change between versions - it 
won't show unless you give extra options.

Until recently I was compiling all my straight C code on gcc v4 because it
gave quite useful warnings that later versions wouldn't show no matter what
options you gave them. 

[toc] | [prev] | [next] | [standalone]

#122615

On 23/08/2025 11:14, boltar@caprica.universe wrote:
> On Sat, 23 Aug 2025 10:41:12 +0200
> Marcel Mueller <news.5.maazl@spamgourmet.org> gabbled:
>> Am 21.08.25 um 07:58 schrieb Andrey Tarasevich:
>>> On Tue 8/19/2025 1:33 PM, Marcel Mueller wrote:
>>>>
>>>> OK, there are 3 members of non-POD type, any maybe inlining is not 
>>>> adequate. But shouldn't the compiler just take the best implementation?
>>>> Or are default generated functions necessarily forced to be inline?
>>>
>>> It might be a simple consequence of a lazy implementation.
>>
>> It turned out that this kind of warning of gcc is normally turned off 
>> and not even activated by -Wextra. But some guy managed to explicitly 
>> enable this warning in a dark corner of the custom automake macros of 
>> the project. -.-
> 
> As an aside, the inconsistency of gcc cmd line options wrt warnings and 
> between
> versions really pisses me off. It shouldn't even need -Wextra (or - 
> pedantic) if
> I've already given it -Wall because all funnily enough means all, it 
> doesn't mean all except some random ones - which seem to change between 
> versions - it won't show unless you give extra options.
> 
> Until recently I was compiling all my straight C code on gcc v4 because it
> gave quite useful warnings that later versions wouldn't show no matter what
> options you gave them.

I think you have misunderstood several things here.

gcc is an old project - it has been around for something like four 
decades, and changed enormously since its early days.  Perhaps "-Wall" 
meant "all warnings" when it was first introduced, but these days there 
are hundreds of warning flags in gcc, and /nobody/ wants them all 
enabled.  "-Wall" has, for a very long time, meant "warnings that are 
suitable for a wide range of programs".  Warnings that are triggered by 
common code constructs - whether the code is right or wrong - are rarely 
added to the set of "-Wall" warnings because they could mess up build 
scripts for existing code (especially if the build has "-Werror" to turn 
warnings into errors).

"-Wextra" adds some more warnings that many people find useful.  Many of 
these are more controversial - for example, some people like to be 
warned about missing names for parameters, others think such a warning 
is counter-productive.

Some warnings are enabled by default (such as "-Wimplicit-int"), others 
are only enabled by explicit flags (such as "-Wdouble-promotion").

"-pedantic" (or "-Wpedantic") is a special case - it asks gcc to be as 
close to a specified C or C++ standard as it can.


Usually new versions of gcc add new warnings, but occasionally warning 
flags are removed.  One that I missed when it was removed was a warning 
about dead code elimination.  But it was removed for good reason.  In 
earlier compiler versions, dead code elimination was a relatively simple 
matter in one optimisation pass, and the warning could be implemented 
easily enough and give accurate information.  In later versions, dead 
code elimination could occur in multiple places and in complex ways 
(such as in combination with code duplication or re-arrangements), 
making it increasingly hard to maintain and increasingly inaccurate.  In 
addition, as gcc's optimisations got better, there were more and more 
circumstances in which code could be eliminated as "dead" - it was not 
giving people useful information, so it was removed.


The decisions about what flags are included in "-Wall" and/or "-Wextra", 
and when flags are added or removed in gcc, are not random or 
inconsistent.  They are made carefully, and most of the discussions are 
publicly available in the mailing lists and bug tracker comments.  When 
flags are added to -Wall, large swaths of code (biased, reasonably 
enough, towards open source code for *nix) are tested to see if there 
are conflicts with existing makefiles and other build scripts. 
Decisions are made by weighing up the inconvenience of breaking existing 
builds or giving false positives and the benefits of making it easier 
for developers to find problems with their code.


None of this is particularly special to gcc.  If you have used any other 
compiler over a range of versions, you will likely have seen warnings 
and other options come and go (I know I have).  gcc has more warnings 
than most compilers, but clang has even more.  It also has a compiler 
option "-Weverything" that really does enable all warnings.  It is only 
ever used for testing, or for fun, because no real-world program will 
pass without triggering some false positive.

[toc] | [prev] | [next] | [standalone]

#122618

On Sat, 23 Aug 2025 16:15:03 +0200
David Brown <david.brown@hesbynett.no> gabbled:
>meant "all warnings" when it was first introduced, but these days there 
>are hundreds of warning flags in gcc, and /nobody/ wants them all 
>enabled.

Presumably "nobody" is defined in a similar way as "all". It almost no one
but some people will. I'm one of them.

>suitable for a wide range of programs".  Warnings that are triggered by 
>common code constructs - whether the code is right or wrong - are rarely 
>added to the set of "-Wall" warnings because they could mess up build 
>scripts for existing code (especially if the build has "-Werror" to turn 
>warnings into errors).

And why is that a bad idea? Perhaps some hidden bugs have been found. If
you don't want that behaviour then don't upgrade the compiler.

>and other options come and go (I know I have).  gcc has more warnings 
>than most compilers, but clang has even more.  It also has a compiler 
>option "-Weverything" that really does enable all warnings.  It is only 

Didn't know about Weverything, just tried it and its actually found a minor bug
in a program I'm working on atm. 

[toc] | [prev] | [next] | [standalone]

#122641

On 23/08/2025 16:26, boltar@caprica.universe wrote:
> On Sat, 23 Aug 2025 16:15:03 +0200
> David Brown <david.brown@hesbynett.no> gabbled:
>> meant "all warnings" when it was first introduced, but these days 
>> there are hundreds of warning flags in gcc, and /nobody/ wants them 
>> all enabled.
> 
> Presumably "nobody" is defined in a similar way as "all". It almost no one
> but some people will. I'm one of them.

I very much doubt that you are.

Do you want a warning when you write "float x, y; x = y + 2.5;" ?  Do 
you want a warning when you write "char x; x = x + 1;" ?  Do you want a 
warning for "printf(s);" instead of "printf("%s", s);" ?  Do you want a 
warning for all "switch" statements which don't have a "default" case? 
Do you want a warning on "int * p = 0;" ?  Do you want to warn about 
constructs that are not present in C or C++ standards other than the one 
you have chosen?

There are lots of warnings in gcc, and there are more in every new 
version.  Many are good, general warnings that can be helpful to a wide 
range of people - these will typically be added to "-Wall" or "-Wextra". 
  Many are more obscure, and will be useful only to a small number of 
people in niche circumstances.

Of course you are free to enable as many warnings as you like when you 
use gcc.  But before the gcc developers would bother implementing a 
"-Wabsolutely-everything" flag, they'd have to be persuaded that it 
would actually be useful to developers, worth the effort of implementing 
it, and worth the cost of the consequences of it (such a flag would 
limit the possibilities for flags that are not simply on/off).  I have 
seen discussions on the gcc mailing lists about a clang-style 
"-Weverything" flag for gcc, and read about why it is considered 
something of a joke flag in clang and only really of use when testing 
the compiler.

Good use of static warnings is very helpful in software development. 
But /good/ use does not mean /blind/ use.  The flags that are 
appropriate will depend on the code, the programmer, the project.  For 
most of my own code, I start with "-Wall -Wextra", then turn off a few 
warnings that I find inappropriate, and enable a fair number of extra 
warnings.  The selection is tuned with thought, consideration and 
testing to give the best automatic checking I can get with minimal risk 
of false positives - then I can treat warnings as errors that must be 
handled in some way, and not just ignored.  A "give me everything" flag 
that floods the output with false positives is only marginally better 
than no warnings at all.

> 
>> suitable for a wide range of programs".  Warnings that are triggered 
>> by common code constructs - whether the code is right or wrong - are 
>> rarely added to the set of "-Wall" warnings because they could mess up 
>> build scripts for existing code (especially if the build has "-Werror" 
>> to turn warnings into errors).
> 
> And why is that a bad idea? Perhaps some hidden bugs have been found. If
> you don't want that behaviour then don't upgrade the compiler.
> 

People do not always have tight control of which compiler is used for 
the code they write.  (Some people do - /I/ do - but most do not.)

Warnings generated by toolchains are not synonymous with bugs in the 
code.  They are an indication that there /might/ be a problem in the 
code, or the code might be written in a way that /could/ be considered 
higher risk for bugs during development or maintenance.  If a warning is 
triggered on "while (x = foo()) ...", it might have found a bug, or it 
might have been perfectly correct code doing exactly what the programmer 
intended.

It can certainly be a good idea to run old code through newer and more 
advanced static error checkers, to help find old latent issues.  But it 
needs to be done with care and effort by people who can see if you are 
actually dealing with a problem in the code or simply a different style 
of writing the code.  This takes time and money - and it is not 
necessarily an efficient use of those resources.

>> and other options come and go (I know I have).  gcc has more warnings 
>> than most compilers, but clang has even more.  It also has a compiler 
>> option "-Weverything" that really does enable all warnings.  It is only 
> 
> Didn't know about Weverything, just tried it and its actually found a 
> minor bug
> in a program I'm working on atm.

Then you might want to look at the available warning options in whatever 
compiler(s) you use, and start enabling them in your build system.

[toc] | [prev] | [next] | [standalone]

#122642

On 8/24/2025 5:45 AM, David Brown wrote:
> On 23/08/2025 16:26, boltar@caprica.universe wrote:
>> On Sat, 23 Aug 2025 16:15:03 +0200
>> David Brown <david.brown@hesbynett.no> gabbled:
>>> meant "all warnings" when it was first introduced, but these days 
>>> there are hundreds of warning flags in gcc, and /nobody/ wants them 
>>> all enabled.
>>
>> Presumably "nobody" is defined in a similar way as "all". It almost no 
>> one
>> but some people will. I'm one of them.
> 
> I very much doubt that you are.
> 
> Do you want a warning when you write "float x, y; x = y + 2.5;" ?  Do 
[...]

x = y + 2.5

Actually, sometimes I want a warning wrt 2.5 vs 2.5f...

[toc] | [prev] | [next] | [standalone]

#122644

On 8/24/2025 12:56 PM, Chris M. Thomasson wrote:
> On 8/24/2025 5:45 AM, David Brown wrote:
>> On 23/08/2025 16:26, boltar@caprica.universe wrote:
>>> On Sat, 23 Aug 2025 16:15:03 +0200
>>> David Brown <david.brown@hesbynett.no> gabbled:
>>>> meant "all warnings" when it was first introduced, but these days 
>>>> there are hundreds of warning flags in gcc, and /nobody/ wants them 
>>>> all enabled.
>>>
>>> Presumably "nobody" is defined in a similar way as "all". It almost 
>>> no one
>>> but some people will. I'm one of them.
>>
>> I very much doubt that you are.
>>
>> Do you want a warning when you write "float x, y; x = y + 2.5;" ?  Do 
> [...]
> 
> x = y + 2.5
> 
> Actually, sometimes I want a warning wrt 2.5 vs 2.5f...
> 

Let me clarify:

float x = 0;
float y = 0;

x = y + 2.5;

I sometimes want a warning on the 2.5 instead of 2.5f. Even the 0 vs 0.f

[toc] | [prev] | [next] | [standalone]

#122648

On 24/08/2025 21:56, Chris M. Thomasson wrote:
> On 8/24/2025 5:45 AM, David Brown wrote:
>> On 23/08/2025 16:26, boltar@caprica.universe wrote:
>>> On Sat, 23 Aug 2025 16:15:03 +0200
>>> David Brown <david.brown@hesbynett.no> gabbled:
>>>> meant "all warnings" when it was first introduced, but these days 
>>>> there are hundreds of warning flags in gcc, and /nobody/ wants them 
>>>> all enabled.
>>>
>>> Presumably "nobody" is defined in a similar way as "all". It almost 
>>> no one
>>> but some people will. I'm one of them.
>>
>> I very much doubt that you are.
>>
>> Do you want a warning when you write "float x, y; x = y + 2.5;" ?  Do 
> [...]
> 
> x = y + 2.5
> 
> Actually, sometimes I want a warning wrt 2.5 vs 2.5f...
> 

Exactly - /sometimes/ people want that kind of warning, which is why gcc 
has it.  It is typically useful for targets where there is hardware 
support for single-precision floating point, but not for 
double-precision floating point.  It can also be helpful where there 
might be significant differences in performance, perhaps due to 
vectorisation.

But most people are not at all interested in such a warning, and prefer 
not to clutter their code with "f" suffixes.

All these unusual warnings are useful to /some/ people - but it is very 
unlikely that any one person will want /all/ of these warnings enabled 
at the same time, for the same code.

[toc] | [prev] | [next] | [standalone]

#122673

On 8/24/2025 11:19 PM, David Brown wrote:
> On 24/08/2025 21:56, Chris M. Thomasson wrote:
>> On 8/24/2025 5:45 AM, David Brown wrote:
>>> On 23/08/2025 16:26, boltar@caprica.universe wrote:
>>>> On Sat, 23 Aug 2025 16:15:03 +0200
>>>> David Brown <david.brown@hesbynett.no> gabbled:
>>>>> meant "all warnings" when it was first introduced, but these days 
>>>>> there are hundreds of warning flags in gcc, and /nobody/ wants them 
>>>>> all enabled.
>>>>
>>>> Presumably "nobody" is defined in a similar way as "all". It almost 
>>>> no one
>>>> but some people will. I'm one of them.
>>>
>>> I very much doubt that you are.
>>>
>>> Do you want a warning when you write "float x, y; x = y + 2.5;" ?  Do 
>> [...]
>>
>> x = y + 2.5
>>
>> Actually, sometimes I want a warning wrt 2.5 vs 2.5f...
>>
> 
> Exactly - /sometimes/ people want that kind of warning, which is why gcc 
> has it.  It is typically useful for targets where there is hardware 
> support for single-precision floating point, but not for double- 
> precision floating point.  It can also be helpful where there might be 
> significant differences in performance, perhaps due to vectorisation.
> 
> But most people are not at all interested in such a warning, and prefer 
> not to clutter their code with "f" suffixes.
> 
> All these unusual warnings are useful to /some/ people - but it is very 
> unlikely that any one person will want /all/ of these warnings enabled 
> at the same time, for the same code.
> 

Exactly. Nice. Thanks David. :^)

[toc] | [prev] | [next] | [standalone]

#122645

On Sun, 24 Aug 2025 14:45:12 +0200
David Brown <david.brown@hesbynett.no> gabbled:
>On 23/08/2025 16:26, boltar@caprica.universe wrote:
>> On Sat, 23 Aug 2025 16:15:03 +0200
>> David Brown <david.brown@hesbynett.no> gabbled:
>>> meant "all warnings" when it was first introduced, but these days 
>>> there are hundreds of warning flags in gcc, and /nobody/ wants them 
>>> all enabled.
>> 
>> Presumably "nobody" is defined in a similar way as "all". It almost no one
>> but some people will. I'm one of them.
>
>I very much doubt that you are.
>
>Do you want a warning when you write "float x, y; x = y + 2.5;" ?  Do 
>you want a warning when you write "char x; x = x + 1;" ?  Do you want a 

Do I want a warning about using uninitialised variables? Umm, let me think...
.. yes please!

>warning for "printf(s);" instead of "printf("%s", s);" ?  Do you want a 

Why would that produce a warning?

>warning for all "switch" statements which don't have a "default" case? 

Happens already.

>Do you want a warning on "int * p = 0;" ?  Do you want to warn about 
>constructs that are not present in C or C++ standards other than the one 
>you have chosen?

Yes, otherwise I wouldn't have specified a particular version.

>Of course you are free to enable as many warnings as you like when you 
>use gcc.  But before the gcc developers would bother implementing a 
>"-Wabsolutely-everything" flag, they'd have to be persuaded that it 
>would actually be useful to developers, worth the effort of implementing 
>it, and worth the cost of the consequences of it (such a flag would 
>limit the possibilities for flags that are not simply on/off).  I have 
>seen discussions on the gcc mailing lists about a clang-style 
>"-Weverything" flag for gcc, and read about why it is considered 
>something of a joke flag in clang and only really of use when testing 
>the compiler.

"all" should mean all, not almost all, or the ones considered useful.
There was nothing stopping them using a different flag, eg -Wstandard
or something like that for the kind of warnings considered useful.

>handled in some way, and not just ignored.  A "give me everything" flag 
>that floods the output with false positives is only marginally better 
>than no warnings at all.

Gcc standard warnings have nothing on the gibberish the C++ compiler spits out
when there's a template error. Why the compiler writers think 3 pages of 
unintelligable crap is a useful tool in order to find what usually turns out
to be a simple typo i have no idea. Clang is far better , though still far
from perfect.

>> Didn't know about Weverything, just tried it and its actually found a 
>> minor bug
>> in a program I'm working on atm.
>
>Then you might want to look at the available warning options in whatever 
>compiler(s) you use, and start enabling them in your build system.

Life is too short to google all possible warning flags and figure out which
ones I need.

[toc] | [prev] | [next] | [standalone]

#122649

On 2025-08-24, boltar@caprica.universe <boltar@caprica.universe> wrote:
> On Sun, 24 Aug 2025 14:45:12 +0200
> David Brown <david.brown@hesbynett.no> gabbled:
>
>>warning for "printf(s);" instead of "printf("%s", s);" ?  Do you want a 
>
> Why would that produce a warning?

'printf(s);' can lead to surprises when s contains '%'.

[toc] | [prev] | [next] | [standalone]

#122651

boltar@caprica.universe writes:
>On Sun, 24 Aug 2025 14:45:12 +0200

>
>>warning for "printf(s);" instead of "printf("%s", s);" ?  Do you want a 
>
>Why would that produce a warning?

if "s" has a format specifier (e.g. '%s'), it can cause an
SIGBUS/SIGSEGV (or be used as a vector for malware).

[toc] | [prev] | [next] | [standalone]

#122654

On 24/08/2025 22:42, boltar@caprica.universe wrote:
> On Sun, 24 Aug 2025 14:45:12 +0200
> David Brown <david.brown@hesbynett.no> gabbled:
>> On 23/08/2025 16:26, boltar@caprica.universe wrote:
>>> On Sat, 23 Aug 2025 16:15:03 +0200
>>> David Brown <david.brown@hesbynett.no> gabbled:
>>>> meant "all warnings" when it was first introduced, but these days 
>>>> there are hundreds of warning flags in gcc, and /nobody/ wants them 
>>>> all enabled.
>>>
>>> Presumably "nobody" is defined in a similar way as "all". It almost 
>>> no one
>>> but some people will. I'm one of them.
>>
>> I very much doubt that you are.
>>
>> Do you want a warning when you write "float x, y; x = y + 2.5;" ?  Do 
>> you want a warning when you write "char x; x = x + 1;" ?  Do you want a 
> 
> Do I want a warning about using uninitialised variables? Umm, let me 
> think...
> .. yes please!

Yes, of course - those are obvious (but I should have been clear about 
that).  I meant warnings on promotion of single-precision float to 
double-precision (in "x = y + 2.5;") and warnings about converting "int" 
to "char" in "x = x + 1;".

These are both useful in some types of programming, but not in most 
programming.

> 
>> warning for "printf(s);" instead of "printf("%s", s);" ?  Do you want a 
> 
> Why would that produce a warning?

You get that if you have "-Wformat-security" enabled.  Some programs get 
strings from an external source (such as files of messages in different 
languages).  If these are used as the first parameter of a printf() 
without careful sanitisation, they could be an attack surface by causing 
stack corruption.

Some people (such as myself) want warnings on double precision 
promotion, typically because they are using small limited 
microcontrollers.  Others want extra security on printf, typically 
because they read the format strings from external sources.  Very few 
people will want both.

> 
>> warning for all "switch" statements which don't have a "default" case? 
> 
> Happens already.

No it doesn't, unless you enable it specifically (on gcc anyway - I 
can't answer for clang or other tools).  "-Wswitch-default" is not 
enabled by "-Wall", "-Wextra", or by default.

> 
>> Do you want a warning on "int * p = 0;" ?  Do you want to warn about 
>> constructs that are not present in C or C++ standards other than the 
>> one you have chosen?
> 
> Yes, otherwise I wouldn't have specified a particular version.

The warning on "int * p = 0;" occurs if you have 
"-Wzero-as-null-pointer-constant" enabled.  Most C and C++ programmers 
are quite happy to use the literal 0 as a null pointer constant, but 
some consider it risky and want a warning, forcing the use of NULL or 
nullptr.

As for warnings about incompatibilities across standards versions, I 
think you have completely missed the point.

If I want to write code in C11, I write "-std=c11", and I write my code 
in C11.  I have picked that standard because I want to use features that 
are in C11 but not in C99 or earlier versions.  I am not interested in 
whether or not my code can also be compiled with C99 or C90.  I /might/ 
be interested in known compatibility issues with C17 or C23.  Similarly 
for C++ standards.  I suspect the same applies to you.

So I do not want warning flags telling me about using features that are 
not available in different standards, or that my use of "auto" in C23 or 
C++11 is incompatible with its use in earlier standards.  I do not want 
warnings that my C code is not compatible with C++ - if I had wanted C++ 
compatibility, I would have written C code.

Of course some people /do/ want to write code that is compatible across 
a range of standards, so the various "-Wxxx-compat" flags in gcc are 
helpful to them.  It is highly unlikely, however, that they will want 
all these flags on at the same time.

> 
>> Of course you are free to enable as many warnings as you like when you 
>> use gcc.  But before the gcc developers would bother implementing a 
>> "-Wabsolutely-everything" flag, they'd have to be persuaded that it 
>> would actually be useful to developers, worth the effort of 
>> implementing it, and worth the cost of the consequences of it (such a 
>> flag would limit the possibilities for flags that are not simply 
>> on/off).  I have seen discussions on the gcc mailing lists about a 
>> clang-style "-Weverything" flag for gcc, and read about why it is 
>> considered something of a joke flag in clang and only really of use 
>> when testing the compiler.
> 
> "all" should mean all, not almost all, or the ones considered useful.
> There was nothing stopping them using a different flag, eg -Wstandard
> or something like that for the kind of warnings considered useful.
> 

Then "-Wall" would be useless.

And yes, there /are/ things stopping gcc developers from changing flag 
names without very good reason - it is effort on their part that could 
be better spent on useful things, and it is effort on the part of all 
their users that would then have to change their build scripts and flags 
to match the pointless changes.

I have explained to you why "-Wall" has the name it does, and what it 
means.  I have explained why it does /not/ mean "all warnings", and why 
enabling "all warnings" would be of no serious use to anyone.  If you 
want to stay upset about this and continue to be annoyed about the name 
of the flag, that's your choice - but at least you should no longer be 
doing so from a position of ignorance.  And if you want to file a bug 
about it in the gcc development bug tracker, or write a patch for gcc to 
get the flag names you want, you are free to do so.


>> handled in some way, and not just ignored.  A "give me everything" 
>> flag that floods the output with false positives is only marginally 
>> better than no warnings at all.
> 
> Gcc standard warnings have nothing on the gibberish the C++ compiler 
> spits out
> when there's a template error. Why the compiler writers think 3 pages of 
> unintelligable crap is a useful tool in order to find what usually turns 
> out
> to be a simple typo i have no idea. Clang is far better , though still far
> from perfect.
> 

That is a red herring, completely irrelevant to the argument you have 
been trying to make.

But it is also an issue that every C++ compiler has had trouble with 
since the dawn of C++ templates.

And like many C++ compilers, gcc has been getting steadily better at 
this, with later versions give better (or at least, less bad) error 
messages than earlier versions.  Some compiler options can help tune 
behaviour to suit the user.  You can also combine gcc's newer parseable 
error formats with some IDE's to get a clearer picture.  And you can use 
concepts (C++23) to significantly improve template error handling.

>>> Didn't know about Weverything, just tried it and its actually found a 
>>> minor bug
>>> in a program I'm working on atm.
>>
>> Then you might want to look at the available warning options in 
>> whatever compiler(s) you use, and start enabling them in your build 
>> system.
> 
> Life is too short to google all possible warning flags and figure out which
> ones I need.
> 

But it is long enough to rant about how the warning flags don't suit 
your needs?  Okay...

[toc] | [prev] | [next] | [standalone]

#122666

On Mon, 25 Aug 2025 16:36:01 +0200
David Brown <david.brown@hesbynett.no> wrote:
>On 24/08/2025 22:42, boltar@caprica.universe wrote:
>> "all" should mean all, not almost all, or the ones considered useful.
>> There was nothing stopping them using a different flag, eg -Wstandard
>> or something like that for the kind of warnings considered useful.
>> 
>
>Then "-Wall" would be useless.
>
>And yes, there /are/ things stopping gcc developers from changing flag 
>names without very good reason - it is effort on their part that could 
>be better spent on useful things, and it is effort on the part of all 
>their users that would then have to change their build scripts and flags 
>to match the pointless changes.

-Wall should have continued to mean all as compiler versions progressed.
Other warning options could have been introduced to keep the output similar
to earlier compiler versions or alternatively a flag to compile as an older
version.

>> Gcc standard warnings have nothing on the gibberish the C++ compiler 
>> spits out
>> when there's a template error. Why the compiler writers think 3 pages of 
>> unintelligable crap is a useful tool in order to find what usually turns 
>> out
>> to be a simple typo i have no idea. Clang is far better , though still far
>> from perfect.
>> 
>
>That is a red herring, completely irrelevant to the argument you have 
>been trying to make.

No, you're making a Big Deal out of lots of warnings when a standard
error dump from gcc can be pages long and utterly useless.

>But it is also an issue that every C++ compiler has had trouble with 
>since the dawn of C++ templates.

A syntax error is a syntax error. Templates should make no difference.

>> Life is too short to google all possible warning flags and figure out which
>> ones I need.
>> 
>
>But it is long enough to rant about how the warning flags don't suit 
>your needs?  Okay...

Using that logic I shouldn't post on this group at all until i've read
the latest C++ specification from start to finish.

[toc] | [prev] | [next] | [standalone]

#122668

On 25/08/2025 22:01, boltar@battlestar-galactica.com wrote:
> On Mon, 25 Aug 2025 16:36:01 +0200
> David Brown <david.brown@hesbynett.no> wrote:
>> On 24/08/2025 22:42, boltar@caprica.universe wrote:
>>> "all" should mean all, not almost all, or the ones considered useful.
>>> There was nothing stopping them using a different flag, eg -Wstandard
>>> or something like that for the kind of warnings considered useful.
>>>
>>
>> Then "-Wall" would be useless.
>>
>> And yes, there /are/ things stopping gcc developers from changing flag 
>> names without very good reason - it is effort on their part that could 
>> be better spent on useful things, and it is effort on the part of all 
>> their users that would then have to change their build scripts and 
>> flags to match the pointless changes.
> 
> -Wall should have continued to mean all as compiler versions progressed.
> Other warning options could have been introduced to keep the output similar
> to earlier compiler versions or alternatively a flag to compile as an older
> version.
> 

Certainly the gcc developers could have taken other paths here.  They 
could have said "You know that old "-Wall" flag you all find useful? 
Well, now we are going to make it useless, and you'll have to start 
using other flags instead if you want a practical selection of 
warnings."  That would have kept the name "all" meaning "all".  I'm 
happy that they made a different decision, but of course no choice of 
flags, names, or collections of warnings is going to please everyone.

>>> Gcc standard warnings have nothing on the gibberish the C++ compiler 
>>> spits out
>>> when there's a template error. Why the compiler writers think 3 pages 
>>> of unintelligable crap is a useful tool in order to find what usually 
>>> turns out
>>> to be a simple typo i have no idea. Clang is far better , though 
>>> still far
>>> from perfect.
>>>
>>
>> That is a red herring, completely irrelevant to the argument you have 
>> been trying to make.
> 
> No, you're making a Big Deal out of lots of warnings when a standard
> error dump from gcc can be pages long and utterly useless.
> 

/I/ am not the one making a big deal out of anything.  /You/ are getting 
your knickers in a twist because "-Wall" doesn't mean enable absolutely 
all warning flags the compiler supports.  I am happy enough with the 
warning flags gcc has (they are not perfect, but good enough for most of 
my needs - within the limits of compiler static error detection 
technology).  I am happy enough with the template error messages - they 
are sometimes hard to read, but have improved over the years, and I have 
so far managed to figure out the problems in my code.

>> But it is also an issue that every C++ compiler has had trouble with 
>> since the dawn of C++ templates.
> 
> A syntax error is a syntax error. Templates should make no difference.
> 

And a tautology is a tautology.  The things leading to warnings or 
errors with templates are often something other than syntax errors - 
that's why it is difficult (for compilers or humans) to figure out where 
the mistake actually occurs, which is why error messages are so long and 
complicated.  There are many other ways in C and C++ where a tiny 
mistake in one place can lead to piles of warnings and errors elsewhere 
- it's part of the fun of coding, and is far from a solved problem.

>>> Life is too short to google all possible warning flags and figure out 
>>> which
>>> ones I need.
>>>
>>
>> But it is long enough to rant about how the warning flags don't suit 
>> your needs?  Okay...
> 
> Using that logic I shouldn't post on this group at all until i've read
> the latest C++ specification from start to finish.
> 

Warning flags for a particular compiler are not part of the C++ standards.

But if you are going to get worked up about warnings in a particular 
compiler, I think it makes sense to at least read a bit of the relevant 
compiler manual page.

[toc] | [prev] | [next] | [standalone]

#122669

On Tue, 26 Aug 2025 09:06:23 +0200
David Brown <david.brown@hesbynett.no> wrote:
>On 25/08/2025 22:01, boltar@battlestar-galactica.com wrote:
>> -Wall should have continued to mean all as compiler versions progressed.
>> Other warning options could have been introduced to keep the output similar
>> to earlier compiler versions or alternatively a flag to compile as an older
>> version.
>> 
>
>Certainly the gcc developers could have taken other paths here.  They 
>could have said "You know that old "-Wall" flag you all find useful? 
>Well, now we are going to make it useless, and you'll have to start 
>using other flags instead if you want a practical selection of 
>warnings."  That would have kept the name "all" meaning "all".  I'm 

"You know that old -Wall flag that used to show all the warnings? Well now its 
not going to any more, good eh? You won't know which ones we've left out and 
they might change with each release, but here's a new bunch of -W flags which 
will also change meaning in the future. Have fun with your build!"

>> No, you're making a Big Deal out of lots of warnings when a standard
>> error dump from gcc can be pages long and utterly useless.
>> 
>
>/I/ am not the one making a big deal out of anything.  /You/ are getting 
>your knickers in a twist because "-Wall" doesn't mean enable absolutely 

I originally posted a single short paragraph on the subject. You're the
one responding with pages defending gcc. Are you on the dev team or 
something?

tl;dr

[toc] | [prev] | [next] | [standalone]

#122670

On 26/08/2025 20:30, boltar@battlestar-galactica.com wrote:
> On Tue, 26 Aug 2025 09:06:23 +0200
> David Brown <david.brown@hesbynett.no> wrote:
>> On 25/08/2025 22:01, boltar@battlestar-galactica.com wrote:
>>> -Wall should have continued to mean all as compiler versions progressed.
>>> Other warning options could have been introduced to keep the output 
>>> similar
>>> to earlier compiler versions or alternatively a flag to compile as an 
>>> older
>>> version.
>>>
>>
>> Certainly the gcc developers could have taken other paths here.  They 
>> could have said "You know that old "-Wall" flag you all find useful? 
>> Well, now we are going to make it useless, and you'll have to start 
>> using other flags instead if you want a practical selection of 
>> warnings."  That would have kept the name "all" meaning "all".  I'm 
> 
> "You know that old -Wall flag that used to show all the warnings? Well 
> now its not going to any more, good eh? You won't know which ones we've 
> left out and they might change with each release, but here's a new bunch 
> of -W flags which will also change meaning in the future. Have fun with 
> your build!"
> 

You can read what I wrote, explaining things to you.

Or you can read the relevant page in the gcc manual - it is not 
difficult to understand.

Or you can remain stubbornly and wilfully ignorant and make a fool of 
yourself crying about something that is only a problem in your own mind.

>>> No, you're making a Big Deal out of lots of warnings when a standard
>>> error dump from gcc can be pages long and utterly useless.
>>>
>>
>> /I/ am not the one making a big deal out of anything.  /You/ are 
>> getting your knickers in a twist because "-Wall" doesn't mean enable 
>> absolutely 
> 
> I originally posted a single short paragraph on the subject. You're the
> one responding with pages defending gcc. Are you on the dev team or 
> something?
> 

My apologies for being helpful and informative.  I'll try not to let it 
happen again.

[toc] | [prev] | [next] | [standalone]

#122672

On Tue, 26 Aug 2025 22:49:39 +0200
David Brown <david.brown@hesbynett.no> wrote:
>Or you can read the relevant page in the gcc manual - it is not 
>difficult to understand.

Right, because everyone reads the compiler manual before they start on a
project. Just the list of warning flags alone take up almost a page and
thats with 2 or 3 on each line.

>Or you can remain stubbornly and wilfully ignorant and make a fool of 
>yourself crying about something that is only a problem in your own mind.

Those straw men of yours deserve a pay rise.

>> I originally posted a single short paragraph on the subject. You're the
>> one responding with pages defending gcc. Are you on the dev team or 
>> something?
>> 
>
>My apologies for being helpful and informative.  I'll try not to let it 
>happen again.

You're never ever just "being helpful and informative". You always throw in
a nice dose of patronisation and subtle ad hominems as the icing on the cake.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.c++

csiph-web