[Bug c/70730] Inconsistent column number in "error: attempt to take address of bit-field structure member"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70730 --- Comment #3 from Manuel López-Ibáñez --- (In reply to Eric Gallager from comment #2) > (In reply to Manuel López-Ibáñez from comment #1) > > If not, this then depends on PR43486 > > (that's now fixed, btw... so maybe that's had an impact on this?) Still using error() instead of error_at(), so probably not: https://github.com/gcc-mirror/gcc/blob/c6c2a1d79eb333a00124bf67820a7f405d0d8641/gcc/c-family/c-common.cc#L6930
[Bug c/28492] -Wmissing-format-attribute points to vsnprintf() or related functions instead of the function that needs the attribute added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28492 Manuel López-Ibáñez changed: What|Removed |Added Last reconfirmed|2012-04-17 00:00:00 |2024-1-9 --- Comment #6 from Manuel López-Ibáñez --- The option is called now -Wsuggest-attribute=format See also https://gcc.gnu.org/pipermail/gcc/2024-January/243120.html for a real-world case.
[Bug other/44209] [meta-bug] Some warnings are not linked to diagnostics options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44209 --- Comment #9 from Manuel López-Ibáñez --- For the sake of other potential readers: Patches should be submitted to gcc-patc...@gcc.gnu.org and reviewers do not review patches in bugzilla. Nevertheless, it is a good idea to add the link to the mailing list archive here in bugzilla so the patch is not forgotten. For more details, please read: https://gcc.gnu.org/wiki/GettingStarted#Basics:_Contributing_to_GCC_in_10_easy_steps How to submit and ping patches: https://gcc.gnu.org/contribute.html#patches See other suggestions on how to interact with the GCC community here: https://gcc.gnu.org/wiki/Community
[Bug c/111654] Introduce clang's invalid-noreturn warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111654 --- Comment #4 from Manuel López-Ibáñez --- (In reply to Julian Waters from comment #2) > (In reply to Manuel López-Ibáñez from comment #1) > Yeah, I did try submitting it to gcc-patches, but it simply went ignored for > forever, so I decided to submit the patch through the bug system instead, > like others have done. I implemented it as numeric values to avoid inventing > new names for -Woption and because it was easier to implement for a gcc > beginner like myself, so worded warnings are likely to take me longer to > implement Apologies, I was not aware of that. I think it is a good idea to add the link to the mailing list here in bugzilla so it is not lost in the mailing list archive. Unfortunately, gcc does not have any patch tracking system so it is up to submitters to ping patches (the submitter is the one interested in seeing the patch committed). See for example: https://gcc.gnu.org/pipermail/gcc-patches/2023-August/627958.html It may take 4 to 10 pings to get the patch reviewed. It helps sometimes to describe the area the patch touches in the subject. In your case, I would write "[C family]". It helps reviewers if you mention how the patch was tested and also if the patch is attached as plain-text (not as application/*): https://gcc.gnu.org/contribute.html#patches See other suggestions on how to interact with the GCC community here: https://gcc.gnu.org/wiki/Community
[Bug c/111654] Introduce clang's invalid-noreturn warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111654 Manuel López-Ibáñez changed: What|Removed |Added CC||manu at gcc dot gnu.org --- Comment #1 from Manuel López-Ibáñez --- (In reply to Julian Waters from comment #0) > Created attachment 56022 [details] > Patch to add invalid-noreturn to gcc Patches should be submitted to gcc-patc...@gcc.gnu.org For more details, please read: https://gcc.gnu.org/wiki/GettingStarted#Basics:_Contributing_to_GCC_in_10_easy_steps Except for clang compatibility, I believe the consensus is that numerical levels are not user-friendly. I think it would be better to have: -Wnoreturn-implicit-return -Wnoreturn-explicit-return -Winvalid-noreturn enables / disables both.
[Bug c/39589] make -Wmissing-field-initializers=2 work with "designated initializers" ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39589 Manuel López-Ibáñez changed: What|Removed |Added Keywords||patch --- Comment #15 from Manuel López-Ibáñez --- (In reply to Peter Frost from comment #14) > FYI, this is the first time I've worked on the GCC codebase, so I have no > idea if this follow best practices etc. But it seems to work if anyone > wanted to try it out In a nutshell: 1. You need to add some tests that show everything works as expected. 2. You need to run the testsuite 3. You need to submit the patch to gcc-patches. More details: https://gcc.gnu.org/wiki/GettingStarted#Basics:_Contributing_to_GCC_in_10_easy_steps
[Bug c/109123] Bogus warning: pointer used after 'realloc' -Wuse-after-free with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109123 --- Comment #8 from Manuel López-Ibáñez --- (In reply to Richard Biener from comment #7) > Warning for "escapes" (the store is an escape point) is also sensible I > think. Would it be possible to make this distinction at the point of warning? > Warning for other uses is really only sensible before any code motion pass > took place. Can you move the warning pass before the first code motion pass? Or split it in two warning passes: warning for any uses (before code motion) and warn for escapes and deref (after code motion)? > Unfortunately the testsuite is full of cases expected to be diagnosed but > are no longer with any change to the operation. It is better to miss some warnings rather than warn too much because otherwise users will use any means available to silence them (often -Wno-use-after-free) and the useful warnings will be lost. For comprehensive code analysis, users should look at the static analyzer.
[Bug c/109123] Bogus warning: pointer used after 'realloc' -Wuse-after-free with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109123 --- Comment #6 from Manuel López-Ibáñez --- (In reply to Manuel López-Ibáñez from comment #5) > Is this code motion valid? Is there any point in the middle-end that checks > the validity of the pointer beyond a free/realloc? > > If there is a point where such check happens, perhaps it would be a good > place to apply no_warning attribute to the pointer. Answering to myself: It seems the dispute is over the meaning of "use". According to the middle-end and for the purposes of realloc/free, "use" means dereference, while for the warning "use" is any read of the value. By only warning for dereferences, the warning may miss some obvious cases like: tmp = realloc(v->_begin, sizeof(double) * n); v->_end = v->_begin + old_size; v->_begin = tmp; However, given that the assumption of the middle-end has worked for decades, and it will be not possible to fix it, warning only for dereferences (or moving warning for value-uses to a level not enabled by -Wall) would seem more user-friendly.
[Bug c/109123] Bogus warning: pointer used after 'realloc' -Wuse-after-free with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109123 --- Comment #5 from Manuel López-Ibáñez --- > GCC has sunk part of the old_size computation (not the loads but the > subtraction) to after the realloc but before the use of old_size. Is this code motion valid? Is there any point in the middle-end that checks the validity of the pointer beyond a free/realloc? If there is a point where such check happens, perhaps it would be a good place to apply no_warning attribute to the pointer.
[Bug c/109123] Bogus warning: pointer used after 'realloc' -Wuse-after-free with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109123 --- Comment #4 from Manuel López-Ibáñez --- This case is a bit different from other Wuse-after-free false positives: * there is no path through which the warning is true * the warning says "is used" not "may be used" * there is no easy workaround that I can see. Wuninitialized warnings are easy to silence but what should one do here?
[Bug c/109123] Bogus warning: pointer used after 'realloc' -Wuse-after-free with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109123 --- Comment #2 from Manuel López-Ibáñez --- This is probably the same underlying issue as PR 106119 and PR 104215, but unlike those, this testcase is heavily reduced without any header files (and it could be reduced further I believe).
[Bug c/109123] Bogus warning: pointer used after 'realloc' -Wuse-after-free with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109123 Manuel López-Ibáñez changed: What|Removed |Added Summary|Bogus warning: pointer used |Bogus warning: pointer used |after 'realloc' |after 'realloc' |-Wuse-after-free|-Wuse-after-free with -O2 Keywords||diagnostic Blocks||104075 --- Comment #1 from Manuel López-Ibáñez --- Also fails in trunk (gcc 13). Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104075 [Bug 104075] bogus/missing -Wuse-after-free
[Bug c/109123] New: Bogus warning: pointer used after 'realloc' -Wuse-after-free
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109123
Bug ID: 109123
Summary: Bogus warning: pointer used after 'realloc'
-Wuse-after-free
Product: gcc
Version: 12.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: manu at gcc dot gnu.org
Target Milestone: ---
```c
typedef long unsigned int size_t;
extern void *realloc (void *__ptr, size_t __size)
__attribute__ ((__nothrow__ , __leaf__)) __attribute__
((__warn_unused_result__)) __attribute__ ((__alloc_size__ (2)));
struct vector_objective;
typedef struct vector_objective vector_objective;
struct vector_objective { double *_begin; double *_end; double *_capacity; };
static inline size_t vector_objective_size(const vector_objective * v) {
return v->_end - v->_begin;
}
static inline size_t vector_objective_capacity(const vector_objective * v) {
return v->_capacity - v->_begin;
}
static inline void vector_objective_reserve(vector_objective * v, size_t n) {
size_t old_capacity = vector_objective_capacity(v);
size_t old_size = vector_objective_size(v);
if (n > old_capacity) {
v->_begin = realloc(v->_begin, sizeof(double) * n);
v->_end = v->_begin + old_size;
v->_capacity = v->_begin + n;
}
}
static inline void vector_objective_push_back(vector_objective * v, double x) {
if (v->_end == v->_capacity)
vector_objective_reserve (v, (vector_objective_capacity (v) == 0) ? 8 :
2 * vector_objective_capacity (v));
*(v->_end) = x;
v->_end++;
}
typedef struct {
vector_objective xy;
} eaf_polygon_t;
int
rectangle_add(eaf_polygon_t * regions, double lx)
{
vector_objective_push_back(>xy, lx);
return 0;
}
```
With -Wall -c -O2 produces:
In function 'vector_objective_size',
inlined from 'vector_objective_reserve' at :15:23,
inlined from 'vector_objective_push_back' at :24:9,
inlined from 'rectangle_add' at :38:5:
:8:20: warning: pointer used after 'realloc' [-Wuse-after-free]
8 | return v->_end - v->_begin;
|^
In function 'vector_objective_reserve',
inlined from 'vector_objective_push_back' at :24:9,
inlined from 'rectangle_add' at :38:5:
:17:21: note: call to 'realloc' here
17 | v->_begin = realloc(v->_begin, sizeof(double) * n);
|
But the use occurs before not after the realloc.
[Bug c/63357] Warn for P && P and P || P (same expression used multiple times in a condition)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63357 --- Comment #9 from Manuel López-Ibáñez --- (In reply to David Binderman from comment #8) > This could probably be extended to other operators. Please open a new PR mentioning this one.
[Bug c/47781] warnings from custom printf format specifiers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47781 --- Comment #30 from Manuel López-Ibáñez --- (In reply to jos...@codesourcery.com from comment #29) > As I said before, the issue is still how to define something general > enough to be useful but that doesn't expose too much of the details of > GCC's internal data structures for format checking. Indeed, the first step does not even require looking at GCC code or an implementation, but coming up with a design that is flexible enough to be useful.
[Bug c/47781] warnings from custom printf format specifiers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47781 --- Comment #28 from Manuel López-Ibáñez --- (In reply to Jan Wielemaker from comment #27) > It is really a pity this can't be resolved :( We have quite a few > extensions in the SWI-Prolog source code, mostly for debug messages that > deal with internal data structures. It makes writing debug messages a lot > easier. This can be resolved. It only needs someone(s) interested enough to implement it or pay someone else to implement it. There are a lot of suggestions in this page on how to proceed. Personally, I think the best would be to start with a simple design for an attribute rather than a pragma and implement it as a plugin to faster development and testing. Then submit it for comments. The simplest design that will get you faster feedback would be something the replaces some of the current GCC-specific printf formats, like %E, %T, %q, etc. (I don't remember where these are documented and implemented right now) It just needs people with time and patience to do it.
[Bug other/42540] c++ error message [vtable undefined] is unhelpful
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42540 --- Comment #24 from Manuel López-Ibáñez --- For completeness, this is what LLD says: ld.lld: error: undefined symbol: vtable for A >>> referenced by example.cpp:7 >>> /tmp/example-5d8b98.o:(A::A()) >>> the vtable symbol may be undefined because the class is missing its key >>> function (see https://lld.llvm.org/missingkeyfunction) which seems better.
[Bug other/42540] c++ error message [vtable undefined] is unhelpful
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42540 Manuel López-Ibáñez changed: What|Removed |Added Assignee|jyasskin at gmail dot com |unassigned at gcc dot gnu.org Status|ASSIGNED|NEW Last reconfirmed|2010-07-13 22:58:26 |2022-8-25 Keywords||patch URL||http://gcc.gnu.org/ml/gcc-p ||atches/2010-08/msg00367.htm ||l --- Comment #23 from Manuel López-Ibáñez --- Unassigned so that someone else can take it they wish to.
[Bug c/50486] No warning at signed -> unsigned casting
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50486 --- Comment #3 from Manuel López-Ibáñez --- Clang warns: :16:18: warning: implicit conversion changes signedness: 'int' to 'enum e' [-Wsign-conversion] return a(-1); ~ ^~ Not sure why gcc doesn't but it should.
[Bug c++/53431] C++ preprocessor ignores #pragma GCC diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53431 --- Comment #46 from Manuel López-Ibáñez --- (In reply to Lewis Hyatt from comment #44) > I hope this looks workable, happy to adjust the patch as needed. If you don't get much attention to the patch, it may be worth pinging it. But before that, I would also suggest submitting all the cleanups separately as their own, easy-to-review patch. For example, the bits about cp_token_is_module_directive.
[Bug fortran/56659] Segfault due to missing libcpp error handler for "gfortran -cpp"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56659 --- Comment #9 from Manuel López-Ibáñez --- (In reply to Tobias Burnus from comment #8) > f951: Warning: Include directory ‘foo/bar/’: Permission denied > : Error: foo/bar: Permission denied > > (The shows up when entering a file but the file is not yet there. > Not ideal, > but not that quick to fix. Once the file is read, that's replaced by the > file name and line number. Still, the issue should be fixed > eventually.) Hi Tobias, Are you sure the Error is produced *after* entering the file (by entering I mean pushing the file into the include stack and thus updating the line-map). If so, then the line-maps are not correctly named and the diagnostic wants to print some filename but the line-map or the include stack says that the name of the file is . But it could also be that the Error is produced *before* entering the file. Then, the bug is that something else has pushed the context into the line-map stack. This should be command-line context and produce: f951: Error: foo/bar: Permission denied or: : Error: foo/bar: Permission denied In either case, this points to some mess in the line-map stack.
[Bug fortran/102484] New: Refactor duplicated cb_cpp_diagnostic_cpp_option
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102484 Bug ID: 102484 Summary: Refactor duplicated cb_cpp_diagnostic_cpp_option Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: manu at gcc dot gnu.org Target Milestone: --- This function: https://github.com/gcc-mirror/gcc/blob/8bafc9640f353ff11c0535a03096fb4db9a5bb95/gcc/fortran/cpp.c#L1062 is a duplicate of: https://github.com/gcc-mirror/gcc/blob/16e2427f50c208dfe07d07f18009969502c25dc8/gcc/c-family/c-common.c#L6293 The function should be common to the whole compiler and it could be generated static inline by: https://github.com/gcc-mirror/gcc/blob/8bafc9640f353ff11c0535a03096fb4db9a5bb95/gcc/opth-gen.awk#L556 so that it is available by including options.h. Or even better, generate only a declaration above, generate the body from optc-gen.awk and move cpp_reason_option_codes inside the function rather than being yet another global. Note that this will also remove the need to include cpplib.h in options.h, which is a nice cleanup.
[Bug fortran/62226] Encode CPP options in lang.opt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62226 --- Comment #2 from Manuel López-Ibáñez --- (In reply to Tobias Burnus from comment #1) > I am not sure whether the original issue still exists. > > Fortran now uses a lot of the common machinery and also seems to handle > CPP() well. > > Thus, is this now fixed/superseded by the recent and not so recent > developments or is something still needed? If Fortran will always use a subset of the CPP options used by the C FE and defined by c-family/c.opt, then I guess it may not be needed. But be aware that this code: https://github.com/gcc-mirror/gcc/blob/8bafc9640f353ff11c0535a03096fb4db9a5bb95/gcc/fortran/cpp.c#L1062 only works because this file: https://github.com/gcc-mirror/gcc/blob/master/gcc/c-family/c.opt#L390 encodes the CppReason and it is not possible without the patch in this PR to have a CPP option that only works for Fortran only encoded in fortran/lang.opt I haven't tested whether diagnostics from CPP show the appropriate option in Fortran and behave correctly with #pragma GCC diagnostics. Another minor thing: You added recently another copy of: https://github.com/gcc-mirror/gcc/blob/16e2427f50c208dfe07d07f18009969502c25dc8/gcc/c-family/c-common.c#L6293 I may have added that function there, but it should be added in common code. In fact, it could be actually generated as "static inline" together with the table of codes: https://github.com/gcc-mirror/gcc/blob/master/gcc/opth-gen.awk so that it is available by including opts.h (in fact, that function is the only user of cpp_reason_option_codes, so the table could be inside the function rather than being yet another global).
[Bug fortran/58334] preprocessor behavior diffs under line continuation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58334 Manuel López-Ibáñez changed: What|Removed |Added CC||manu at gcc dot gnu.org --- Comment #5 from Manuel López-Ibáñez --- Some useful links copied from the duplicated report: https://gcc.gnu.org/ml/gcc/2014-11/msg00357.html See also the comments in https://gcc.gnu.org/ml/gcc/2014-12/msg3.html and follow-ups.
[Bug c++/67499] c++ template/overload diagnostic compression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67499
--- Comment #11 from Manuel López-Ibáñez ---
And Clang output:
:5:13: error: invalid operands to binary expression ('std::ostream'
(aka 'basic_ostream') and 'foo')
std::cout << bar;
~ ^ ~~~
/opt/compiler-explorer/gcc-snapshot/lib/gcc/x86_64-linux-gnu/12.0.0/../../../../include/c++/12.0.0/system_error:279:5:
note: candidate function template not viable: no known conversion from 'foo' to
'const std::error_code' for 2nd argument
operator<<(basic_ostream<_CharT, _Traits>& __os, const error_code& __e)
^
/opt/compiler-explorer/gcc-snapshot/lib/gcc/x86_64-linux-gnu/12.0.0/../../../../include/c++/12.0.0/ostream:505:5:
note: candidate function template not viable: no known conversion from 'foo' to
'char' for 2nd argument
operator<<(basic_ostream<_CharT, _Traits>& __out, char __c)
^
/opt/compiler-explorer/gcc-snapshot/lib/gcc/x86_64-linux-gnu/12.0.0/../../../../include/c++/12.0.0/ostream:511:5:
note: candidate function template not viable: no known conversion from 'foo' to
'char' for 2nd argument
operator<<(basic_ostream& __out, char __c)
^
/opt/compiler-explorer/gcc-snapshot/lib/gcc/x86_64-linux-gnu/12.0.0/../../../../include/c++/12.0.0/ostream:517:5:
note: candidate function template not viable: no known conversion from 'foo' to
'signed char' for 2nd argument
operator<<(basic_ostream& __out, signed char __c)
^
/opt/compiler-explorer/gcc-snapshot/lib/gcc/x86_64-linux-gnu/12.0.0/../../../../include/c++/12.0.0/ostream:522:5:
note: candidate function template not viable: no known conversion from 'foo' to
'unsigned char' for 2nd argument
operator<<(basic_ostream& __out, unsigned char __c)
^
/opt/compiler-explorer/gcc-snapshot/lib/gcc/x86_64-linux-gnu/12.0.0/../../../../include/c++/12.0.0/ostream:600:5:
note: candidate function template not viable: no known conversion from 'foo' to
'const char *' for 2nd argument
operator<<(basic_ostream& __out, const char* __s)
^
/opt/compiler-explorer/gcc-snapshot/lib/gcc/x86_64-linux-gnu/12.0.0/../../../../include/c++/12.0.0/ostream:613:5:
note: candidate function template not viable: no known conversion from 'foo' to
'const signed char *' for 2nd argument
operator<<(basic_ostream& __out, const signed char* __s)
^
/opt/compiler-explorer/gcc-snapshot/lib/gcc/x86_64-linux-gnu/12.0.0/../../../../include/c++/12.0.0/ostream:618:5:
note: candidate function template not viable: no known conversion from 'foo' to
'const unsigned char *' for 2nd argument
operator<<(basic_ostream& __out, const unsigned char* __s)
^
/opt/compiler-explorer/gcc-snapshot/lib/gcc/x86_64-linux-gnu/12.0.0/../../../../include/c++/12.0.0/bits/ostream.tcc:302:5:
note: candidate function template not viable: no known conversion from 'foo' to
'const char *' for 2nd argument
operator<<(basic_ostream<_CharT, _Traits>& __out, const char* __s)
^
/opt/compiler-explorer/gcc-snapshot/lib/gcc/x86_64-linux-gnu/12.0.0/../../../../include/c++/12.0.0/ostream:500:5:
note: candidate template ignored: deduced conflicting types for parameter
'_CharT' ('char' vs. 'foo')
operator<<(basic_ostream<_CharT, _Traits>& __out, _CharT __c)
^
/opt/compiler-explorer/gcc-snapshot/lib/gcc/x86_64-linux-gnu/12.0.0/../../../../include/c++/12.0.0/bits/basic_string.h:3591:5:
note: candidate template ignored: could not match
'basic_string'
against 'foo'
operator<<(basic_ostream<_CharT, _Traits>& __os,
^
/opt/compiler-explorer/gcc-snapshot/lib/gcc/x86_64-linux-gnu/12.0.0/../../../../include/c++/12.0.0/ostream:583:5:
note: candidate template ignored: could not match 'const _CharT *' against
'foo'
operator<<(basic_ostream<_CharT, _Traits>& __out, const _CharT* __s)
^
/opt/compiler-explorer/gcc-snapshot/lib/gcc/x86_64-linux-gnu/12.0.0/../../../../include/c++/12.0.0/type_traits:2230:46:
note: candidate template ignored: disabled by 'enable_if' [with _Ostream =
std::basic_ostream &, _Tp = foo]
using __enable_if_t = typename enable_if<_Cond, _Tp>::type;
^
/opt/compiler-explorer/gcc-snapshot/lib/gcc/x86_64-linux-gnu/12.0.0/../../../../include/c++/12.0.0/ostream:108:7:
note: candidate function not viable: no known conversion from 'foo' to
'std::basic_ostream::__ostream_type
&(*)(std::basic_ostream::__ostream_type &)' (aka 'basic_ostream> &(*)(basic_ostream> &)')
for 1st argument
operator<<(__ostream_type& (*__pf)(__ostream_type&))
^
/opt/compiler-explorer/gcc-snapshot/lib/gcc/x86_64-linux-gnu/12.0.0/../../../../include/c++/12.0.0/ostream:117:7:
note: candidate function not viable: no known conversion from 'foo' to
'std::basic_ostream::__ios_type &(*)(std::basic_ostream::__ios_type
&)' (aka 'basic_ios> &(*)(basic_ios> &)') for 1st argument
operator<<(__ios_type& (*__pf)(__ios_type&))
^
/opt/compiler-explorer/gcc-snapshot/lib/gcc/x86_64-linux-gnu/12.0.0/../../../../include/c++/12.0.0/ostream:127:7:
note: candidate function not viable:
[Bug c++/67499] c++ template/overload diagnostic compression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67499
--- Comment #10 from Manuel López-Ibáñez ---
This is the current GCC output:
```
: In function 'int main()':
:5:13: error: no match for 'operator<<' (operand types are
'std::ostream' {aka 'std::basic_ostream'} and 'foo')
5 | std::cout << bar;
| ~ ^~ ~~~
|| |
|| foo
|std::ostream {aka std::basic_ostream}
In file included from
/opt/compiler-explorer/gcc-trunk-20210823/include/c++/12.0.0/iostream:39,
from :1:
/opt/compiler-explorer/gcc-trunk-20210823/include/c++/12.0.0/ostream:108:7:
note: candidate: 'std::basic_ostream<_CharT, _Traits>::__ostream_type&
std::basic_ostream<_CharT, _Traits>::operator<<(std::basic_ostream<_CharT,
_Traits>::__ostream_type& (*)(std::basic_ostream<_CharT,
_Traits>::__ostream_type&)) [with _CharT = char; _Traits =
std::char_traits; std::basic_ostream<_CharT, _Traits>::__ostream_type =
std::basic_ostream]'
108 | operator<<(__ostream_type& (*__pf)(__ostream_type&))
| ^~~~
/opt/compiler-explorer/gcc-trunk-20210823/include/c++/12.0.0/ostream:108:36:
note: no known conversion for argument 1 from 'foo' to
'std::basic_ostream::__ostream_type&
(*)(std::basic_ostream::__ostream_type&)' {aka 'std::basic_ostream&
(*)(std::basic_ostream&)'}
108 | operator<<(__ostream_type& (*__pf)(__ostream_type&))
| ~~^~
/opt/compiler-explorer/gcc-trunk-20210823/include/c++/12.0.0/ostream:117:7:
note: candidate: 'std::basic_ostream<_CharT, _Traits>::__ostream_type&
std::basic_ostream<_CharT, _Traits>::operator<<(std::basic_ostream<_CharT,
_Traits>::__ios_type& (*)(std::basic_ostream<_CharT, _Traits>::__ios_type&))
[with _CharT = char; _Traits = std::char_traits;
std::basic_ostream<_CharT, _Traits>::__ostream_type = std::basic_ostream;
std::basic_ostream<_CharT, _Traits>::__ios_type = std::basic_ios]'
117 | operator<<(__ios_type& (*__pf)(__ios_type&))
| ^~~~
/opt/compiler-explorer/gcc-trunk-20210823/include/c++/12.0.0/ostream:117:32:
note: no known conversion for argument 1 from 'foo' to
'std::basic_ostream::__ios_type&
(*)(std::basic_ostream::__ios_type&)' {aka 'std::basic_ios&
(*)(std::basic_ios&)'}
117 | operator<<(__ios_type& (*__pf)(__ios_type&))
| ~~^~
/opt/compiler-explorer/gcc-trunk-20210823/include/c++/12.0.0/ostream:127:7:
note: candidate: 'std::basic_ostream<_CharT, _Traits>::__ostream_type&
std::basic_ostream<_CharT, _Traits>::operator<<(std::ios_base&
(*)(std::ios_base&)) [with _CharT = char; _Traits = std::char_traits;
std::basic_ostream<_CharT, _Traits>::__ostream_type =
std::basic_ostream]'
127 | operator<<(ios_base& (*__pf) (ios_base&))
| ^~~~
/opt/compiler-explorer/gcc-trunk-20210823/include/c++/12.0.0/ostream:127:30:
note: no known conversion for argument 1 from 'foo' to 'std::ios_base&
(*)(std::ios_base&)'
127 | operator<<(ios_base& (*__pf) (ios_base&))
| ^
/opt/compiler-explorer/gcc-trunk-20210823/include/c++/12.0.0/ostream:166:7:
note: candidate: 'std::basic_ostream<_CharT, _Traits>::__ostream_type&
std::basic_ostream<_CharT, _Traits>::operator<<(long int) [with _CharT = char;
_Traits = std::char_traits; std::basic_ostream<_CharT,
_Traits>::__ostream_type = std::basic_ostream]'
166 | operator<<(long __n)
| ^~~~
/opt/compiler-explorer/gcc-trunk-20210823/include/c++/12.0.0/ostream:166:23:
note: no known conversion for argument 1 from 'foo' to 'long int'
166 | operator<<(long __n)
| ~^~~
/opt/compiler-explorer/gcc-trunk-20210823/include/c++/12.0.0/ostream:170:7:
note: candidate: 'std::basic_ostream<_CharT, _Traits>::__ostream_type&
std::basic_ostream<_CharT, _Traits>::operator<<(long unsigned int) [with _CharT
= char; _Traits = std::char_traits; std::basic_ostream<_CharT,
_Traits>::__ostream_type = std::basic_ostream]'
170 | operator<<(unsigned long __n)
| ^~~~
/opt/compiler-explorer/gcc-trunk-20210823/include/c++/12.0.0/ostream:170:32:
note: no known conversion for argument 1 from 'foo' to 'long unsigned int'
170 | operator<<(unsigned long __n)
| ~~^~~
/opt/compiler-explorer/gcc-trunk-20210823/include/c++/12.0.0/ostream:174:7:
note: candidate: 'std::basic_ostream<_CharT, _Traits>::__ostream_type&
std::basic_ostream<_CharT, _Traits>::operator<<(bool) [with _CharT = char;
_Traits = std::char_traits; std::basic_ostream<_CharT,
_Traits>::__ostream_type = std::basic_ostream]'
174 | operator<<(bool __n)
| ^~~~
/opt/compiler-explorer/gcc-trunk-20210823/include/c++/12.0.0/ostream:174:23:
note: no known conversion for argument 1 from 'foo' to 'bool'
174 | operator<<(bool __n)
| ~^~~
In file included from
[Bug driver/69471] "-march=native" unintentionally breaks further -march/-mtune flags
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69471 --- Comment #18 from Manuel López-Ibáñez --- (In reply to wavexx from comment #17) > I wish this would be given a nudge, considering the patch. This has been > pushed to new releases since 2016 :( I see several patches have been committed already. Is there any patch pending? What are the remaining issues?
[Bug c++/18635] [DR 504] use of uninitialised reference accepted (without -Wuninitialized) in C++ front end
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=18635 Manuel López-Ibáñez changed: What|Removed |Added URL||http://www.open-std.org/jtc ||1/sc22/wg21/docs/papers/201 ||1/n3293.html#504 --- Comment #19 from Manuel López-Ibáñez --- (In reply to Martin Sebor from comment #18) > What is this a request for? What GCC should do depends on the DR which is still open. Until the DR is resolved one way or another, this PR should stay suspended.
[Bug middle-end/63943] wrong location for -Wmaybe-uninitialized in inlined function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63943 --- Comment #4 from Manuel López-Ibáñez --- (In reply to Martin Sebor from comment #3) > As for using %K, I mostly agree. I actually have %G in my tree, but my goal > is to get rid of both and replace them with a new warning function like so: > https://gcc.gnu.org/pipermail/gcc-patches/2021-January/563862.html > and replace calls to warning() and warning_at() in the middle end with those > to the new function. This makes it possible to control warnings at any > point in the lining stack and resolves bug like pr98871. That is great. It may be worth CCing David Malcolm, since he is the diagnostics maintainer. A couple of comments: * #include "tree.h" in diagnostic.c is not great. Ideally, diagnostic.c should be independent of trees so that other front-ends can use it without having to use tree. We went through a lot of work to make the core diagnostics independent of any FE or Middle-end and only depend on line-map and options handling. The original plan is to move it to its own library/module, but I guess there has been little progress in the modular GCC. * There is a tree-diagnostic.c. Everything that depends on tree.h should be moved there. (again, if there was a modular GCC, this would be obvious but alas...) * Although it is more work, I think Richard and other middle-end reviewers would be more motivated to accept this if it removed completely percent_K_format. That is, rather than add yet-another-way, completely replaces the old %K with something better. * I don't contribute to GCC anymore, but rather than doing: diag_inlining_context dic (exp); warning (dic, opt, "%qD specified size %E may exceed maximum object size %E", func, bndrng[0], maxobjsize); I'd prefer: warning_at_inlined_context(exp, opt, "%qD specified size %E may exceed maximum object size %E", func, bndrng[0], maxobjsize); This way, I don't need to know about class diag_inlining_context nor about another variable (dic). I just need to know about an alternative warning function and the magic is hidden from me. This function can live in tree-diagnostic.c which contains the tree-specific functions for diagnostics.
[Bug middle-end/61112] Simple example triggers false-positive -Wmaybe-uninitialized warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61112
--- Comment #9 from Manuel López-Ibáñez ---
(In reply to Martin Sebor from comment #8)
> I've added both the passing test case from comment #0 and the still failing
> test case from comment #5 to the test suite and xfailed the latter (thus
> reconfirming for GCC 11). Without any further analysis, the comment #5 test
> case also looks similar to pr99756.
I think the '||' is a red-herring or insufficient to explain the PR. The
following also warns:
int p;
void foo (int x, int y, int z, int a)
{
int w;
if (x)
w = z;
if (y)
w = 10;
if (a)
w = 67;
if (x)
p = w;
}
[Bug middle-end/60488] missing uninitialized warning (address taken, VOP)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60488 --- Comment #9 from Manuel López-Ibáñez --- (In reply to Martin Sebor from comment #8) > You're right, the test cases aren't equivalent, or meant to be. What I want > to highlight is that in the test case in comment #6, in g() and other > similar ones like it the warning is most likely going to be a false > positive, while in h(), not warning most likely a false negative. Both of > these "problems" are due to the same underlying assumption: that a variable > whose address escapes may be modified by a subsequent call to an unknown > function. Sure, but that assumption is not the problem in this PR, since assuming one thing or the other only matters for distinguishing between "is" and "may be", but a warning should have been given and it is not given.
[Bug middle-end/57832] compiling sha-256 code (xz 5.0.5) generates false warnings when using -march=native on Atom CPU
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57832
--- Comment #7 from Manuel López-Ibáñez ---
(In reply to Martin Sebor from comment #6)
> In the reduced test cases (in comment #3 and comment #4) d is a global
> variable so it's value is zero. c is assigned in the first iteration of the
> loop (when e is zero) and used in subsequent iterations when it has a
> defined value, so the warning .seems like a clear false postive to me. (I
> didn't look at the big test case.)
Oh, yes! Sorry, my comment didn't make sense. Even simpler:
int a, d;
void f (void)
{
int c;
for (int e = 0; e < 64; e += 6)
{
if (e == 0)
c = d;
else
a += c;
}
}
[Bug middle-end/57832] compiling sha-256 code (xz 5.0.5) generates false warnings when using -march=native on Atom CPU
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57832 --- Comment #5 from Manuel López-Ibáñez --- Either there is no bug or the reduction is incorrect because the warning in the testcase is correct since d is uninitialized. Maybe the bug is that it warns about 'c' and not about 'd', but probably at the time of warning 'd' is long gone.
[Bug middle-end/60488] missing uninitialized warning (address taken, VOP)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60488
--- Comment #7 from Manuel López-Ibáñez ---
(In reply to Martin Sebor from comment #6)
> The problem is that when the address of a variable escapes, because GCC
> doesn't track when, when the function from which it escapes calls another
> that might access the escaped variable, the warning (as a result of relying
> on the conservative assumptions the optimizers must make) assumes the called
> function initializes the variable. Another example of this is function h()
> below.
I don't think these are equivalent testcases. It is OK to assume that the
invisible function initializes the variable. The problem arises when there is a
path that never calls the function but GCC does not see that.
The key here is the logical operator splits the possible paths in two. In one
of the paths, b (comment #5) is never initialized, no matter what you assume
about f(). It also happens with a simple if():
int f (int*);
int g(void);
int foo (void)
{
int b;
if (g()) {
f();
}
return b;
}
However, a similar construct without works:
int g(void);
int foo (void)
{
int b;
if (g()) {
b = g();
}
return b;
}
If you look at the VOPs, there is a chain that goes from the VUSE of b to the
VDEF<(D)> through at least one PHI node.
The "return 0" is problematic because CPP (PR18501) will trigger and mess up
things even more. But the above testcases avoid PR18501 and still show this
bug.
[Bug middle-end/95848] missing -Wuninitialized passing structs by value (VOPS)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95848 --- Comment #3 from Manuel López-Ibáñez --- Martin, it is not clear from the dumps what is the difference between the two cases. Also, this warning triggers even with -O0, so it must come pretty earlier even before we have VOPS. What is the difference at the level of GIMPLE?
