[Bug other/92631] New: Warnings partly caused by system headers are broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92631
Bug ID: 92631
Summary: Warnings partly caused by system headers are broken
Product: gcc
Version: 9.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: mwoehlke.floss at gmail dot com
Target Milestone: ---
While trying to fix warnings in a code base, we noticed that some are very
strange:
foo.cpp: warning: by ‘virtual ...’ [-Werror=overloaded-virtual]
bar.cpp: warning: but ‘...’ does not throw; perhaps it should be declared
‘noexcept’ [-Wnoexcept]
The commonality is that all of these are the second part of a multi-part
warning. The first part of the warning IS NOT SHOWN. Further testing proved
that the problem isn't on our end (misreading the log or some such); gcc NEVER
printed the first part of the warning. Additionally, the file reference for the
missing first part would be in a "system" header.
Needless to say, this makes for some *very* confusing warnings.
Attempting to compile the following example will reproduce the issue:
==> foo.cpp <==
#pragma GCC diagnostic error "-Woverloaded-virtual"
#include "foo.h"
struct bar : foo
{
void frob(int) override;
}
==> foo.h <==
#pragma GCC system_header
struct foo
{
virtual void frob(int);
virtual void frob(long);
};
(Compile with 'g++ foo.cpp'.)
Adding -Wsystem-headers "reveals" the missing first part of the
warnings/errors.
(Apologies if this is a duplicate and I have overlooked a similar report.)
[Bug c++/52718] -Wzero-as-null-pointer-constant: misleading location for 0 as default argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52718
--- Comment #16 from mwoehlke.floss at gmail dot com 2012-11-01 22:03:46 UTC ---
On 2012-11-01 16:52, paolo.carlini at oracle dot com wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52718
> --- Comment #15 from Paolo Carlini
> 2012-11-01 20:52:15 UTC ---
>
> This is what I meant when I said that the issue is different, and is much more
>
> general than -Wzero-as-null-pointer-constant. Consider, eg, with -Woverflow:
>
> #pragma GCC system_header
>
> class Foo
> {
> public:
>Foo(signed char);
> };
>
> class Bar
> {
> public:
>Bar(Foo = 1);
> };
Would you prefer I open a new bug report?
[Bug other/87371] New: Spurious -Wreturn-type warning with "pathological" for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87371
Bug ID: 87371
Summary: Spurious -Wreturn-type warning with "pathological" for
Product: gcc
Version: 8.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: mwoehlke.floss at gmail dot com
Target Milestone: ---
Consider the following code:
int foo()
{
for (int y = 0; !y;)
for (/*decl*/; !y; ++y)
return 1;
}
This generates a -Wreturn-type warning, despite that the inner loop body will
*always* execute. Moreover, with optimization enabled, the compiler does (as
expected) successfully remove the loops entirely.
(This is a simplified version of a pre-C++17 `with` statement. The purpose of
this code, which is usually a macro, is to look like the opening statement of a
block, where `/*decl*/` — omitted in this example — is in scope only until the
end of the block. FWIW, the C++17 form, `if (/*decl*/; true)` does not exhibit
the problem.)
Live example: https://godbolt.org/g/5xM6C3. Possibly related to #67629 and/or
#85914.
[Bug c/67629] bogus -Wreturn-type in a function with tautological if-else
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67629 --- Comment #8 from Matthew Woehlke --- Given what -Wreturn-type is trying to accomplish, I wonder if a "delayed issuance" strategy would be in order? IOW, have the front end "trigger" the warning, as now, but stuff it in a queue or such, continue on with optimization, then go back and check the queue to see if the warning still looks legitimate, and only *then* emit it. Where this gets sticky is that at -O0, we still may not know that the warning is spurious. We might, ideally, want to perform optimization anyway on a function with a "pending" -Wreturn-type warning, but throw out the result.
[Bug c/7652] -Wswitch-break : Warn if a switch case falls through
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=7652 --- Comment #37 from Matthew Woehlke --- > Essentially, this warning and the "intentional fallthrough" attribute exist for both clang and MSVC and will be enabled there; but GCC still doesn't have this feature. [[fallthrough]] was approved for C++17. While the standard does not normatively *require* a diagnostic, it's certainly expected that one be issued. It's a shame that gcc is behind the curve here.
[Bug c/7652] -Wswitch-break : Warn if a switch case falls through
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=7652 --- Comment #39 from Matthew Woehlke --- (In reply to Jonathan Wakely from comment #38) > (In reply to Matthew Woehlke from comment #37) > > [[fallthrough]] was approved for C++17 [...] It's a shame that gcc is behind > > the curve here. > > It was approved less than a week ago. So? People have been asking for it for at least *13+ years* (this report was opened in August 2002). Compared to clang which has had this feature for some years already, gcc is lagging. I'm also not sure how to react to "less than a week ago". The *wording* was approved last week. The *feature* was approved (by EWG¹, which is the approval that matters most for something like this) at Kona, a few months back. If you're claiming you can't implement without wording, that's one thing. If you didn't see it coming, then you didn't do your homework. (¹ ...about as strongly as you ever see out of EWG, at that: SF=15, F=5, N=0, A=0, SA=0) > It will get implemented. I do hope so, but given that a) it hasn't been implemented in over a decade of people asking for it, and b) isn't actually required for conformance, I'm not holding my breath.
