[Bug tree-optimization/105616] Using regex_replace throws "maybe-uninitialized" warnings with -fsanitize=address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105616 Jonny Grant changed: What|Removed |Added CC||jg at jguk dot org --- Comment #5 from Jonny Grant --- The godbolt link shows the issue on the trunk. I see this in 13.2.0 myself.
[Bug tree-optimization/109590] array-bounds does not warn about address 0x0 dereference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109590 --- Comment #5 from Jonny Grant --- (In reply to Xi Ruoyao from comment #4) > (In reply to Jonny Grant from comment #2) > > (In reply to Andrew Pinski from comment #1) > > > There is -Wnull-dereference for this ... > > > > I agree. I set that -Wnull-dereference in usual projects (it doesn't seem to > > get enabled by -Wall -Wextra) > > > > I just expected -Warray-bounds to get the 0x0 address too > > There is no reason to expect this. There is no array at 0x0 address. The > warning for *p in your case is already complained as false warning in > another PR (I cannot remember the number, but I'm sure there is such a PR). I get what you are saying, it's a pointer, not a zero-length array that -Warray-bounds is designed to detect. I tried these two, just for completeness. n[0] no warning, n[1] gives warning https://godbolt.org/z/q4fbTofqM https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html This is another C example, with a struct, like the manual describes, but no warning -O2 -Wall -Warray-bounds=2 -std=c2x https://godbolt.org/z/W1G3Wrnoh #include typedef struct foo { char buf[0]; } foo_t; int main() { foo_t * n = NULL; return n->buf[1]; } https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html I did wonder what 'this_length' refers to in that example
[Bug tree-optimization/109590] array-bounds does not warn about address 0x0 dereference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109590 --- Comment #2 from Jonny Grant --- (In reply to Andrew Pinski from comment #1) > There is -Wnull-dereference for this ... I agree. I set that -Wnull-dereference in usual projects (it doesn't seem to get enabled by -Wall -Wextra) I just expected -Warray-bounds to get the 0x0 address too
[Bug c++/109590] New: array-bounds does not warn about address 0x0 dereference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109590 Bug ID: 109590 Summary: array-bounds does not warn about address 0x0 dereference Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: jg at jguk dot org Target Milestone: --- Could -Warray-bounds give a warning when a buffer is at address 0x0 like it does when buffers are at addresses under 0x1000 ? example below. int main() { const char * n = nullptr; const char * p = reinterpret_cast(0x100); return *n + *p; } https://godbolt.org/z/n6ffhfEn9 : In function 'int main()': :7:17: warning: array subscript 0 is outside array bounds of 'const char [0]' [-Warray-bounds=] 7 | return *n + *p; | ^~ cc1plus: note: source object is likely at address zero Compiler returned: 0 I know the --param=min-pagesize default is 0x1000 so I had expected the warning to occur on 0x0 as well as 0x100 in this example
[Bug c++/109356] Enhancement idea to provide clearer missing brace line number
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109356 --- Comment #8 from Jonny Grant --- (In reply to Xi Ruoyao from comment #7) > (In reply to Jonny Grant from comment #6) > > Tried a few other compilers on godbolt. > > > > ICC gets the warning on line 6 > > https://godbolt.org/z/fYb9c8f61 > > > > nvc++ gives the warning on line 6 > > https://godbolt.org/z/xvh67odzY > > > > MSVC and Clang don't. > > This is just blind luck. All of these compilers attempt to "fix" the syntax > error by adding "}" at line 8 (not line 6!) and produce further warnings. > It's just ICC and nvc++ report "excess elements in initializer" at the > beginning of the initializer, while the other compilers report it at the end. > > Strictly speaking all of them are false warnings as there is no excess > elements in the initializer (according to the programmer's mind). But the > only thing the parser can do is guessing the programmer wanted a "}" at line > 8. ok, thank you for your further replies
[Bug c++/109356] Enhancement idea to provide clearer missing brace line number
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109356 --- Comment #6 from Jonny Grant --- Tried a few other compilers on godbolt. ICC gets the warning on line 6 https://godbolt.org/z/fYb9c8f61 nvc++ gives the warning on line 6 https://godbolt.org/z/xvh67odzY MSVC and Clang don't.
[Bug c++/109356] Enhancement idea to provide clearer missing brace line number
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109356 --- Comment #5 from Jonny Grant --- I see it is more complicated than I imagined. Thank you for looking into it.
[Bug c++/109356] Enhancement idea to provide clearer missing brace line number
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109356 --- Comment #3 from Jonny Grant --- A different example where GCC does a good job of indicating the line number of a missing comma problem. https://godbolt.org/z/asGhE3W17 :6:5: error: expected '}' before '{' token 6 | {"G", "H"}, | ^ :2:1: note: to match this '{' 2 | { | ^ :6:5: error: expected ',' or ';' before '{' token 6 | {"G", "H"}, | ^
[Bug analyzer/109266] Wanalyzer-null-dereference does not warn when struct is at null
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109266 --- Comment #5 from Jonny Grant --- (In reply to David Malcolm from comment #3) > (In reply to Jonny Grant from comment #2) > > Thank you for your reply David. Your analyzer is very good already. > > > > I played around a bit, a base of nullptr doesn't give a warning. But > > changing to 0x10 does give array-bounds warning. > > cc1plus: note: source object is likely at address zero > > :13:13: warning: array subscript 0 is outside array bounds of 'a_t > > [0]' [-Warray-bounds=] > > > > https://godbolt.org/z/PhhT48xxP > > FWIW, note that [-Warray-bounds=] is separate from -fanalyzer. > > > > > Found Andrew Pinski comment says 4096 is not accessible: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106699#c1 > > Aha - thanks for the link! I think that's the thing that I was > half-remembering (well, its dup, PR 99578), and that it was, in fact, in GCC. > > Looks like I should extend -Wanalyzer-null-dereference to warn about > accesses to constant addresses, but have it respect --param=min-pagesize= > (see r11-9731-g91f7d7e1bb6827bf8e0b7ba7eb949953a5b1bd18). This would have > to wait for GCC 14 at this point in the release cycle. > > > > > I wondered if you know how to turn on that "cc1plus: note: source object is > > likely at address zero? It seems different from normal warnings. > > Grepping the sources shows it's from gcc/pointer-query.cc: > access_ref::inform_access; I think it's one of the middle-end warnings that > triggers that, but I'm not sure exactly which (the analyzer doesn't use that > at the moment). Many thanks for your investigation and reply. > > It would be fantastic if there was a way for me to specify on the gcc > > command line an address range I didn't want read and/or writable. That would > > be great to get build warnings from those addresses if the compiler could > > see them being accessed. > > Is this always for stuff near the 0 address, or are there other use cases? > (embedded?) Are you able to post an example here of what the input might > look like? For me, I was mainly thinking issues due to reading near the 0x0 address (which is valid containing some stuff like the interrupt vector of function pointers etc). The best example would be the struct at NULL I put on godbolt. However, it is true that reading from other addresses that aren't HW mapped IO, RAM or Flash etc would also lead to faults, so if there was a way to specify the valid address ranges that would be great. I recall another compiler I used did let me specify valid ranges. Jonathan Wakely mentioned __attribute__((access(read_only, 1))); elsewhere it could imply the pointer was non-null (I couldn't get any build warnings through use of that attribute though in GCC 12). I don't know if the Analyzer could use that attribute too. > > > > At the moment, I always need to use the JTAG debugger to set some hw > > breakpoints on read from various addresses to catch those accesses (as they > > are mapped to the interrupt vector from 0x0). On Windows I've had various > > crashes where the access was address 0x10 so felt like that was probably a > > struct offset too > > > > I don't know very much about gcc internals. I did wonder if the analyzer can > > see the base address of the struct being passed as 0x0 in the RTL file? > > I tried -fdump-rtl-all but couldn't see the 0x0 address, or when I changed > > to 0x10 either > > The analyzer works on the gimple-ssa representation, which is before it > become RTL. If you want to see the gory details, have a look in: > https://gcc.gnu.org/onlinedocs/gccint/Analyzer-Internals.html > in the gcc internal docs, and: > https://gcc-newbies-guide.readthedocs.io/en/latest/inside-cc1.html > in the guide for new gcc contributors I wrote. Thank thanks for the links. I modified the above example to have a base of 0x100 and noticed it in the SSA file MEM[(struct a_t *)256B].c[0] = 98; In the resulting ASM output, it was 8 bytes offset from the base. 0x108 Would be great if Analyzer could report on these in a future release.
[Bug c++/109356] Enhancement idea to provide clearer missing brace line number
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109356 --- Comment #2 from Jonny Grant --- (In reply to Xi Ruoyao from comment #1) > I believe attempting to doing so would result exponential time complexity. Ah ok, I didn't realise it would be complex. I don't know enough about the internals, I was just thinking it could use the [2] to know that it had got 2 elements, and that } closing brace was needed before the comma. ie. :5:10: error: expected '}' before ',' token 5 | {"E", "F", | ^ Or I thought it could just count the number of braces, and when it got to the 3rd open brace { ie. :6:2: error: expected '}' before '{' token 5 | {"E", "F", | ^
[Bug web/109355] Add a text warning to old gcc online manual stating it is out of date
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109355 --- Comment #4 from Jonny Grant --- (In reply to Andrew Pinski from comment #2) > Oh and the manual is not exactly out of date for that version of gcc. So the > text you have would be wrong. Sorry, you're completely right. A script could search for and insert after: Warning: This GCC manual is not the https://gcc.gnu.org/onlinedocs/gcc-latest-stable-redirect;>latest GCC release
[Bug c++/109356] New: Enhancement idea to provide clearer missing brace line number
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109356 Bug ID: 109356 Summary: Enhancement idea to provide clearer missing brace line number Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: jg at jguk dot org Target Milestone: --- Sometimes due to human error there is a missing brace. Enhancement idea to provide the missing brace line number. Is that possible? Godbolt trunk gcc does show there is an error, but doesn't pick out line 5. Would be great if it could https://godbolt.org/z/nE13h1r13 :8:2: error: expected '}' before ';' token 8 | }; | ^ :2:1: note: to match this '{' 2 | { | ^ :8:2: error: too many initializers for 'const char* [2]' 8 | }; | ^ static const char * list[][2] = { {"A", "B"}, {"C", "D"}, {"E", "F", {"G", "H"}, {"I", "J"} }; int main() { }
[Bug web/109355] New: Add a text warning to old gcc online manual stating it is out of date
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109355 Bug ID: 109355 Summary: Add a text warning to old gcc online manual stating it is out of date Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: web Assignee: unassigned at gcc dot gnu.org Reporter: jg at jguk dot org Target Milestone: --- Could old GCC documentation release HTML web pages have a text warning at the top making it clear the documentation is out of date? ie: "Warning: This GCC manual is not the latest online documentation " eg searching for "gcc function attributes error" gives me: https://gcc.gnu.org/onlinedocs/gcc-4.7.2/gcc/Function-Attributes.html I noticed popular search engines often suggest out of date GCC docs, eg this one from 2012. So I manually browse to https://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html Which is fine, I just find it myself, but it would be nice if there was a reminder at the top of each page, in case someone doesn't check the URL.
[Bug analyzer/109266] Wanalyzer-null-dereference does not warn when struct is at null
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109266 --- Comment #2 from Jonny Grant --- Thank you for your reply David. Your analyzer is very good already. I played around a bit, a base of nullptr doesn't give a warning. But changing to 0x10 does give array-bounds warning. cc1plus: note: source object is likely at address zero :13:13: warning: array subscript 0 is outside array bounds of 'a_t [0]' [-Warray-bounds=] https://godbolt.org/z/PhhT48xxP Found Andrew Pinski comment says 4096 is not accessible: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106699#c1 I wondered if you know how to turn on that "cc1plus: note: source object is likely at address zero? It seems different from normal warnings. It would be fantastic if there was a way for me to specify on the gcc command line an address range I didn't want read and/or writable. That would be great to get build warnings from those addresses if the compiler could see them being accessed. At the moment, I always need to use the JTAG debugger to set some hw breakpoints on read from various addresses to catch those accesses (as they are mapped to the interrupt vector from 0x0). On Windows I've had various crashes where the access was address 0x10 so felt like that was probably a struct offset too I don't know very much about gcc internals. I did wonder if the analyzer can see the base address of the struct being passed as 0x0 in the RTL file? I tried -fdump-rtl-all but couldn't see the 0x0 address, or when I changed to 0x10 either
[Bug analyzer/109266] New: Wanalyzer-null-dereference does not warn when struct is at null
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109266 Bug ID: 109266 Summary: Wanalyzer-null-dereference does not warn when struct is at null Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: analyzer Assignee: dmalcolm at gcc dot gnu.org Reporter: jg at jguk dot org Target Milestone: --- Couldn't find an existing report for this. Hope the very useful Analyzer can be enhanced to handle nullptr for structs. Which means that when reading members of the struct they might be at 0x4 etc, not directly 0x0 Analyzer does detect if the first 'int' in this struct at address nullptr is read. If the code reads the bytes after in the struct, it doesn't identify that 0x4 address is also inaccessible. Only way to ensure to get a warning is to copy the struct to a local variable (before reading those bytes at offset 0x4 from the copy). Try it live: https://godbolt.org/z/9a611jvfM -fanalyzer -Wall -O2 typedef struct a { int b; char c[3]; } a_t; void f(a_t * s) { //s->b = 0; s->c[0] = 'b'; } int main() { a_t * s = nullptr; f(s); }
[Bug libstdc++/108886] Add basic_string throw logic_error when assigned a nullptr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108886 --- Comment #4 from Jonny Grant --- (In reply to Jonathan Wakely from comment #3) > (In reply to Jonny Grant from comment #2) > > I was taught to validate parameters at University. Personally I always > > follow defensive programming approaches to avoid crashes. > > So stop passing null to these functions then :-) Feels like we have a different opinion. I know you know more about C++ than me. Defensive programming is carefulness in libraries too; particularly interfaces. The C++ standard group have a paper "P2698R0 Unconditional termination is a serious problem" you may have seen. What I see is that the nullptr keyword is part of the language, and is used in many places to indicate an object is not available. For me, a function that requires a valid pointer, should check for the nullptr constant. The crash is the code that de-references the nullptr because it requires a valid pointer. Of course I would like all code to check for nullptr before passing to std::string, and I would do those checks myself as well :-) A nullptr is different from passing a use-after-free pointer. Wrapping std::string is the workaround, as it doesn't always throw logic_error for the nullptr constant. It would just use up time when the STL implementation could handle it, as need to check every method on std::string in the codebase to check for nullptr, because it doesn't throw logic_error say for assign or other operators. > > So I would check > > parameters on all interface methods and operators. I would rely on the > > compiler to remove any unnecessary duplicate sanity checks. > > That doesn't necessarily work when the member functions are separately > compiled, as with most std::string member functions. Ok, that's a shame. If it showed up in some performance measurements it could be adjusted. > > > What would be the point of _GLIBCXX_DEBUG_PEDASSERT when there's already a > > > debug assertion there? Compiling with _GLIBCXX_DEBUG will already abort. > > > > I don't see a debug assertion for _GLIBCXX_DEBUG_PEDASSERT could you point > > out the file and line number to me please. > > You already quoted it in your comment 0 above, it's right there in > assign(const _CharT*)! > > basic_string& > assign(const _CharT* __s) > { > __glibcxx_requires_string(__s); Ok I see. Thank you for that example __glibcxx_requires_string is a macro that compiles down to _GLIBCXX_DEBUG_PEDASSERT. I wonder why it wasn't written in capitals as __GLIBCXX_REQUIRES_STRING_ASSERT? Anyway, it is good there are asserts that report nullptr issues at runtime. > > Just compiled with -D_GLIBCXX_DEBUG but I don't get any abort, just the same > > SEGV > > https://godbolt.org/z/rjYG8Yrnh > > If you want a PEDASSERT to fire you need to actually request pedantic > assertions. > > https://godbolt.org/z/874x18G1G > > /opt/compiler-explorer/gcc-trunk-20230227/include/c++/13.0.1/bits/ > basic_string.h:1645: constexpr std::__cxx11::basic_string<_CharT, _Traits, > _Alloc>& std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::assign(const > _CharT*) [with _CharT = char; _Traits = std::char_traits; _Alloc = > std::allocator]: Assertion '__s != nullptr' failed. > > I'm not persuaded to change anything here. The performance of string > assignments is very important and adding an extra branch and throwing an > exception isn't free. It sounds like you know the implementation really well. Personally on embedded systems I don't find the cost of checking for NULL an issue. The 'throw' should not impact performance, as it is within the if() and code shouldn't often throw, still better than SEGV! Maybe you have some performance comparison statistics showing that a NULL check really impacts performance? STL string heap allocations and actual memory read/write are the biggest performance impact on performance in my experience on embedded. I doubt all uses of std::string are performance intensive. For performance critical code identified by a profiler I just re-write that function in C. Usually graphics code. There is what might be a performance issue, I don't know if anyone has measured, _M_construct() appears to copy copies byte by byte in basic_string.tcc:177 rather than using an optimized memcpy(). I've not measured this myself.
[Bug ipa/108871] attribute nonnull does not spot nullptr O2 and above when function inlined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108871 --- Comment #8 from Jonny Grant --- Another test case. https://godbolt.org/z/qss7jj51x I noticed when not using -fanalyzer gcc still warns about __builtin_puts being passed NULL. However gcc doesn't warn about my own function with attribute nullptr. Maybe I'm missing something. With puts() it gives a nice warning In function 'void f2(const char*)', inlined from 'void f1(const char*)' at :22:7, inlined from 'int main()' at :28:7: :11:19: warning: argument 1 null where non-null expected [-Wnonnull] 11 | __builtin_puts(str); | ~~^ // -std=c++23 -O1 -Wnonnull -Wall // Test case that shows a difference in behavour, // __builtin_puts generates a warning but not f1() // Note, not using -fanalyzer // Change this to 1 to see nonnull warning #define USE_PUTS 0 void f2(const char * str) { #if USE_PUTS __builtin_puts(str); #else char a = *str; __builtin_printf("%c", a); #endif } void f1(const char * const str) __attribute__ ((nonnull)); void f1(const char * const str) { f2(str); } int main() { const char * a = nullptr; f1(a); }
[Bug libstdc++/108886] Add basic_string throw logic_error when assigned a nullptr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108886 --- Comment #2 from Jonny Grant --- (In reply to Jonathan Wakely from comment #1) > Why are you suggesting adding a check in two places when the first one just > calls the second one? Feels clearer in the callstack if operator= throws when nullptr is passed. Likewise if assign() is called with nullptr it looks clearer if the throw is from there. Of course it may be enough just to put it in assign() if that is your preference. I was taught to validate parameters at University. Personally I always follow defensive programming approaches to avoid crashes. So I would check parameters on all interface methods and operators. I would rely on the compiler to remove any unnecessary duplicate sanity checks. > What would be the point of _GLIBCXX_DEBUG_PEDASSERT when there's already a > debug assertion there? Compiling with _GLIBCXX_DEBUG will already abort. I don't see a debug assertion for _GLIBCXX_DEBUG_PEDASSERT could you point out the file and line number to me please. Just compiled with -D_GLIBCXX_DEBUG but I don't get any abort, just the same SEGV https://godbolt.org/z/rjYG8Yrnh > > I don't see the point of adding anything to char_traits at all. It's a very > low-level interface and you probably shouldn't be (and aren't) using it > directly anyway. Sounds reasonable, it's true I'm not using char_traits.
[Bug analyzer/108879] -Wanalyzer-malloc-leak false positive stl string in try catch block
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108879 --- Comment #2 from Jonny Grant --- (In reply to David Malcolm from comment #1) > Yeah, I haven't implemented exceptions yet, so even the simplest cases are > likely to fail :-/ > > I plan to spent a chunk of my GCC *14* cycles working on C++ support (in the > hope of "eating my own dogfood" for GCC 14), but in the meantime, I'm afraid > it's not going to be helpful to file any more bugs about -fanalyzer on C++. > > I've added a caveat about that to the GCC 13 release notes: > https://gcc.gnu.org/git/?p=gcc-wwwdocs.git;a=commitdiff; > h=98c77c7cd4fc3f1bb1e77e260640cbbe5fd45b46 > > and to the manpage/docs: > https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff; > h=a90316c6ceddfbb47b3c2161baf446ccb87df5ff Many thanks for you reply. Looking forward to trying out in future GCC releases! thank you for working on such useful features.
[Bug c++/108893] attribute access read_only
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108893 --- Comment #11 from Jonny Grant --- As you say, in your quote from the manual, the access attribute read_only doesn't mean there will be any access at all. However, it doesn't seem to generate any warnings itself, maybe it is only for the optimizer to utilize this knowledge. Quoting the manual: "The read_only access mode specifies that the pointer to which it applies is used to read the referenced object but not write to it. Unless the argument specifying the size of the access denoted by size-index is zero, the referenced object must be initialized." I tried size-index of 0, and 1, but it doesn't make any difference. Updated example: https://godbolt.org/z/Ms3zWThjT So if I need such nullptr warnings where it is passed and the optimizer can see it, I should use -Wnonnull and attribute nonnull on those functions. Perhaps via a macro, so only in a special build run occasionally to check for such issues.
[Bug c++/108893] attribute access read_only
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108893 --- Comment #10 from Jonny Grant --- (In reply to Andrew Pinski from comment #9) > (In reply to Jonny Grant from comment #8) > > So the caveat is this issue (2). I can't use attribute nonnull due to these > > optimizations that cannot be disabled. > > But you declare that argument cannot be null. So why keep around a check for > it being null. The nonnull attribute is basically saying there is a > requirement for it being nonnull no matter what. It basically says if a null > is passed undefined behavior happens. My concern would be when building a library, the nullptr checks might be removed by the optimizer, and then when linked a nullptr could slip through if they called functions indirectly (ie. not via a header with the same attribute nonnull) I would rather avoid undefined behavior nullptr dereference SEGV, as safety critical software. For instance such functions could check parameters and return -1 if a nullptr is present. So application can handle it, log an issue etc So, I'm adding -fno-delete-null-pointer-checks to my builds as I didn't realise that was on already in -O3.
[Bug c++/108893] attribute access read_only
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108893 --- Comment #8 from Jonny Grant --- (In reply to Andrew Pinski from comment #7) > access attribute says if it is access, then it will be that. It does not say > it MUST be accessed. That is what nonnull is for. > > >I didn't want to use __attribute__((nonnull)) because the optimizer may use > >that knowledge to remove nullptr checks. > > It only uses it afterwards or inside the function. > It cannot use nonnull attribute to optimize before the access has happened. Thank you for your reply. https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html The manual does state: quote 1: "The compiler may also perform optimizations based on the knowledge that certain function arguments cannot be null. These optimizations can be disabled by the -fno-delete-null-pointer-checks option. See Optimize Options." quote 2: "The compiler may also perform optimizations based on the knowledge that nonnul parameters cannot be null. This can currently not be disabled other than by removing the nonnull attribute." So the caveat is this issue (2). I can't use attribute nonnull due to these optimizations that cannot be disabled. BTW, there is a "nonnul" typo there, if you have a moment and commit access to change (the patches I sent to gcc-patches for documentation didn't get any replies) Thank you again for your reply.
[Bug c++/108893] attribute access read_only
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108893 --- Comment #5 from Jonny Grant --- Here is an example, no warnings during compilation. https://godbolt.org/z/h8E7r3Wf8 #include // Try get a build warning for nullptr dereference __attribute__ ((access (read_only, 1, 2))) void f(char * s, size_t size); void f(char * s, size_t size) { *s = 'a'; } int main() { char * s = nullptr; f(s, 1); }
[Bug ipa/108871] attribute nonnull does not spot nullptr O2 and above when function inlined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108871 --- Comment #7 from Jonny Grant --- (In reply to Jakub Jelinek from comment #6) > (In reply to Jonathan Wakely from comment #5) > > (In reply to Andrew Pinski from comment #3) > > > *** Bug 108893 has been marked as a duplicate of this bug. *** > > > > N.B. this one is about __attribute__((access(read_only, 1))) not nonnull. > > The docs already seem to imply that it requires a non-null pointer: > > > > The read_only access mode specifies that the pointer to which it applies > > is used to > > read the referenced object but not write to it. Unless the argument > > specifying the > > size of the access denoted by size-index is zero, the referenced object > > must be > > initialized. > > > > If a non-zero size implies an initialized object, then it also implies a > > non-null pointer (since a null pointer doesn't point to an initialized > > object). > > > > I don't know if we want this PR to be specific to the nonnull attribute, or > > if it makes sense to use it for access(read_only) too. > > On the other side, looking at glibc sources, access attributes there are > used on many functions together with nonnull attributes for the same > arguments and in many cases in places where there are not nonnull > attributes. So, making access attribute imply non-null might not be > desirable in real-world unless it is already implied. > So it might be just that it is badly documented. Hi Jakub, Did you manage to get gcc to give a build warning from those __attr_access read_only lines in glibc? I haven't found a way to activate any build warnings. attribute nonnull seems to be used by optimizer to remove any NULL checks it finds.
[Bug ipa/108871] attribute nonnull does not spot nullptr O2 and above when function inlined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108871 --- Comment #4 from Jonny Grant --- (In reply to Andrew Pinski from comment #3) > *** Bug 108893 has been marked as a duplicate of this bug. *** Hello Andrew May I check, I thought attribute access read_only was different from attribute nonnull? https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html "Note that the access attribute merely specifies how an object referenced by the pointer argument can be accessed; it does not imply that an access will happen. Also, the access attribute does not imply the attribute nonnull; it may be appropriate to add both attributes at the declaration of a function that unconditionally manipulates a buffer via a pointer argument. See the nonnull attribute for more information and caveats." Seems to be stating, nonnull is not the same as access read_only. Or am I missing something? I had understood __attribute__((access(read_only, 1))); would be enough on a -O3 -Wall build to generate a warning that a nullptr had been passed (even if it was not actually dereferenced) Here is an example that actually does derefernence, and runtime SEGV, but it the access read_only itself doesn't give any build warning. Just an example, I'm only hoping to get build warnings when optimizer sees that nullptr got through g++ -std=c++23 -O3 -Wall https://godbolt.org/z/KbzcjEjYj void f(const char * const str) __attribute__((access(read_only,1))); void f(const char * const str) { if(*str == 'a') { __builtin_puts("a1"); } else { __builtin_puts("a2"); } } int main() { const char * a = nullptr; f(a); }
[Bug c++/108893] attribute access read_only
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108893 --- Comment #4 from Jonny Grant --- My apologies, I had understood attribute access read_only was different from the attribute nonnull. So I filed a different report for this. I didn't want to use __attribute__((nonnull)) because the optimizer may use that knowledge to remove nullptr checks. access read_only I hoped would just warn about the dereference. Unfortunately I pasted the wrong example link in the report.
[Bug c++/108893] New: attribute access read_only
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108893 Bug ID: 108893 Summary: attribute access read_only Product: gcc Version: 12.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: jg at jguk dot org Target Milestone: --- could attribute access read_only give a build warning about this nullptr dereference? This example compiles, and then gives SEGV when run. Following on from gcc-help mailing list discussion I tried this out https://gcc.gnu.org/pipermail/gcc-help/2023-February/142280.html void f(const char * const str) __attribute__((access(read_only, 1))); void f(const char * const str) { __builtin_puts(str); } int main() { const char * a = nullptr; f(a); } https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html Tested on trunk in C++ https://godbolt.org/z/rc8G6bePq
[Bug libstdc++/108886] New: Add basic_string throw logic_error when assigned a nullptr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108886 Bug ID: 108886 Summary: Add basic_string throw logic_error when assigned a nullptr Product: gcc Version: 12.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: jg at jguk dot org Target Milestone: --- Checked this on godbolt trunk today. https://godbolt.org/z/6xxEc85c9 basic_string.h will throw a logic_error at runtime if a nullptr gets through to the basic_string() constructor. But assignment doesn't throw a logic_error, it gives SEGV. Could I suggest two improvements please: 1) Add throw logic_error to basic_string.h:815 if pointer is nullptr. _GLIBCXX20_CONSTEXPR basic_string& operator=(const _CharT* __s) { return this->assign(__s); } 2) Add throw logic_error to basic_string:1647 _GLIBCXX20_CONSTEXPR basic_string& assign(const _CharT* __s) { __glibcxx_requires_string(__s); return _M_replace(size_type(0), this->size(), __s, traits_type::length(__s)); } This is what basic_string.h has for normal construction std::__throw_logic_error(__N("basic_string: " "construction from null is not valid")); The basic_string assignment = uses char_traits to check the length using __builtin_strlen and then SEGV. I believe it is the actual __builtin_strlen that does the nullptr dereference. GDB output Core was generated by `./str2'. Program terminated with signal SIGSEGV, Segmentation fault. #0 __strlen_sse2 () at ../sysdeps/x86_64/multiarch/strlen-sse2.S:142 142 ../sysdeps/x86_64/multiarch/strlen-sse2.S: No such file or directory. (gdb) bt #0 __strlen_sse2 () at ../sysdeps/x86_64/multiarch/strlen-sse2.S:142 #1 0x55ca94a8327e in std::char_traits::length (__s=0x0) at /usr/include/c++/12/bits/char_traits.h:395 #2 std::__cxx11::basic_string, std::allocator >::assign (__s=0x0, this=0x7fff26f1e370) at /usr/include/c++/12/bits/basic_string.h:1647 #3 std::__cxx11::basic_string, std::allocator >::operator= (__s=0x0, this=0x7fff26f1e370) at /usr/include/c++/12/bits/basic_string.h:815 #4 make_string (str=str@entry=0x0, out_string="") at str2.cpp:8 #5 0x55ca94a832d9 in main () at str2.cpp:15 Therefore I propose 1) Add throw logic_error to basic_string.h:815 if pointer is nullptr. _GLIBCXX20_CONSTEXPR basic_string& operator=(const _CharT* __s) { return this->assign(__s); } 2) Add throw logic_error to basic_string:1647 _GLIBCXX20_CONSTEXPR basic_string& assign(const _CharT* __s) { __glibcxx_requires_string(__s); return _M_replace(size_type(0), this->size(), __s, traits_type::length(__s)); } 3) I don't think char_traits allows exceptions, so I can't suggest a logic_error Is there anything else that could be added here? Maybe just a _GLIBCXX_DEBUG_PEDASSERT ? strlen() doesn't have a way to even set errno and return -1 This is what char_traits.h has /usr/include/c++/12/bits/char_traits.h:395:25: runtime error: null pointer passed as argument 1, which is declared to never be null AddressSanitizer:DEADLYSIGNAL /usr/include/c++/12/bits/char_traits.h static _GLIBCXX17_CONSTEXPR size_t length(const char_type* __s) { #if __cplusplus >= 201703L if (std::__is_constant_evaluated()) return __gnu_cxx::char_traits::length(__s); #endif return __builtin_strlen(__s); } Example: #include #include void make_string(const char * const str, std::string & out_string) { out_string = str; } int main() { const char * a = NULL; std::string str; make_string(a, str); printf("%s\n", str.c_str()); }
[Bug analyzer/108879] New: -Wanalyzer-malloc-leak false positive stl string in try catch block
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108879 Bug ID: 108879 Summary: -Wanalyzer-malloc-leak false positive stl string in try catch block Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: analyzer Assignee: dmalcolm at gcc dot gnu.org Reporter: jg at jguk dot org Target Milestone: --- Tested just now on gcc (trunk). Source code below and the output. https://godbolt.org/z/Ms6fezGvT : In function 'void make_string(const char*, std::string&)': :11:27: warning: leak of '.std::__cxx11::basic_string::_M_dataplus.std::__cxx11::basic_string::_Alloc_hider::_M_p' [CWE-401] [-Wanalyzer-malloc-leak] 11 | out_string = std::string(str); | ^~~ 'void make_string(const char*, std::string&)': events 1-2 | |7 | void make_string(const char * const str, std::string & out_string) | | ^~~ | | | | | (1) entry to 'make_string' |.. | 11 | out_string = std::string(str); | | ~~~ | | | | | (2) calling 'std::__cxx11::basic_string::basic_string<>' from 'make_string' // -fanalyzer -std=c++23 -O1 -Wall -Wno-analyzer-use-of-uninitialized-value #include #include void make_string(const char * const str, std::string & out_string) { try { out_string = std::string(str); } catch (std::exception& ex) { printf("exception %s\n", ex.what()); fflush(stdout); } } int main() { std::string str; make_string(NULL, str); }
[Bug c++/108871] attribute nonnull does not spot nullptr O2 and above when function inlined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108871 --- Comment #1 from Jonny Grant --- gcc-help mailing list discussion https://gcc.gnu.org/pipermail/gcc-help/2023-February/142279.html
[Bug c++/108871] New: attribute nonnull does not spot nullptr O2 and above when function inlined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108871 Bug ID: 108871 Summary: attribute nonnull does not spot nullptr O2 and above when function inlined Product: gcc Version: 12.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: jg at jguk dot org Target Milestone: --- With Optimizations level 1 it still works. https://godbolt.org/z/6axdfchr8 -fanalyzer -std=c++23 -O3 -Wnonnull -Wall -Wno-analyzer-use-of-uninitialized-value #include std::string make_std_string(const char * const str) __attribute__ ((nonnull)); std::string make_std_string(const char * const str) { return std::string(str); } int main() { const char * a = NULL; std::string result = make_std_string(a); __builtin_puts(result.c_str()); }
[Bug analyzer/107106] Incorrect use of uninitialized value warning on C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107106 Jonny Grant changed: What|Removed |Added CC||jg at jguk dot org --- Comment #2 from Jonny Grant --- I saw this and checked on latest trunk, just sharing as another test case. If I have -Wno-analyzer-use-of-uninitialized-value it keeps this one quiet :7:12: warning: use of uninitialized value '' [CWE-457] [-Wanalyzer-use-of-uninitialized-value] 7 | return str; #include std::string make_str(const char * str) { return str; }
[Bug tree-optimization/105651] [12 Regression] bogus "may overlap" memcpy warning with std::string and operator+ at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105651 Jonny Grant changed: What|Removed |Added CC||jg at jguk dot org --- Comment #24 from Jonny Grant --- Hi, Glad it is fixed in trunk. I saw this fail in 12.2 - test case below. #include typedef struct a_bc { std::string a; std::string b; } a_t; void f() { a_t c; c.a = " sdfsdf fsdfsdf fdfsfdsdf "; // seems to need this long string to reproduce, down to 8 bytes it didn't c.b = "E"; }
[Bug c++/108646] nonnull attribute does not detect variables that are NULL being passed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108646 --- Comment #5 from Jonny Grant --- (In reply to Jonathan Wakely from comment #4) > (In reply to Jonny Grant from comment #3) > > Is it worth -Wnonnull emitting a warning message that it needs optimization > > to get the needed data flow analysis? > > No, there are dozens of warnings that work poorly, or not at all, unless > optimization is enabled. It's in the manual. > > "The effectiveness of some warnings depends on optimizations also being > enabled. For example -Wsuggest-final-types is more effective with link-time > optimization and some instances of other warnings may not be issued at all > unless optimization is enabled. While optimization in general improves the > efficacy of control and data flow sensitive warnings, in some cases it may > also cause false positives." Ok I see. Thank you for clarifying.
[Bug c++/108646] nonnull attribute does not detect variables that are NULL being passed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108646 --- Comment #3 from Jonny Grant --- (In reply to Jonathan Wakely from comment #2) > It already does detect it: > > n.c: In function ‘test’: > n.c:6:2: warning: argument 1 null where non-null expected [-Wnonnull] > 6 | mem2(dest); > | ^~ > n.c:2:8: note: in a call to function ‘mem2’ declared ‘nonnull’ > 2 | void * mem2(void *dest) __attribute__((nonnull)); > |^~~~ > > You need to enable optimization, otherwise there is no data flow analysis. > > Without optimization, it detects it with -fanalyzer > > n.c: In function ‘void test()’: > n.c:6:6: warning: use of NULL ‘dest’ where non-null expected [CWE-476] > [-Wanalyzer-null-argument] > 6 | mem2(dest); > | ^~ > ‘void test()’: events 1-2 > | > |5 | char *dest = NULL; > | |^~~~ > | || > | |(1) ‘dest’ is NULL > |6 | mem2(dest); > | | ~~ > | | | > | | (2) argument 1 (‘dest’) NULL where non-null expected > | > n.c:2:8: note: argument 1 of ‘void* mem2(void*)’ must be non-null > 2 | void * mem2(void *dest) __attribute__((nonnull)); > |^~~~ > > > And it's also detected at runtime using -fsanitize=undefined: > > n.c:6:6: runtime error: null pointer passed as argument 1, which is declared > to never be null That's great it works with optimization, I should remember to always do that.(In reply to Jonathan Wakely from comment #2) > It already does detect it: > > n.c: In function ‘test’: > n.c:6:2: warning: argument 1 null where non-null expected [-Wnonnull] > 6 | mem2(dest); > | ^~ > n.c:2:8: note: in a call to function ‘mem2’ declared ‘nonnull’ > 2 | void * mem2(void *dest) __attribute__((nonnull)); > |^~~~ > > You need to enable optimization, otherwise there is no data flow analysis. > > Without optimization, it detects it with -fanalyzer > > n.c: In function ‘void test()’: > n.c:6:6: warning: use of NULL ‘dest’ where non-null expected [CWE-476] > [-Wanalyzer-null-argument] > 6 | mem2(dest); > | ^~ > ‘void test()’: events 1-2 > | > |5 | char *dest = NULL; > | |^~~~ > | || > | |(1) ‘dest’ is NULL > |6 | mem2(dest); > | | ~~ > | | | > | | (2) argument 1 (‘dest’) NULL where non-null expected > | > n.c:2:8: note: argument 1 of ‘void* mem2(void*)’ must be non-null > 2 | void * mem2(void *dest) __attribute__((nonnull)); > |^~~~ > > > And it's also detected at runtime using -fsanitize=undefined: > > n.c:6:6: runtime error: null pointer passed as argument 1, which is declared > to never be null That's great. I should have remembered to add -O2 Is it worth -Wnonnull emitting a warning message that it needs optimization to get the needed data flow analysis?
[Bug c++/108646] New: nonnull attribute does not detect variables that are NULL being passed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108646 Bug ID: 108646 Summary: nonnull attribute does not detect variables that are NULL being passed Product: gcc Version: 12.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: jg at jguk dot org Target Milestone: --- If we pass NULL directly, there is a good warning (pasted below from today on Godblot.org latest gcc trunk) However, there is no error if passing a variable set to NULL. Could gcc detect this situation? #include void * mem2(void *dest) __attribute__((nonnull)); void test(void) { char *dest = NULL; mem2(dest); } This is the warning when NULL is passed directly: : In function 'void test()': :6:6: warning: argument 1 null where non-null expected [-Wnonnull] 6 | mem2(NULL); | ^~ :2:8: note: in a call to function 'void* mem2(void*)' declared 'nonnull' 2 | void * mem2(void *dest) __attribute__((nonnull)); |^~~~ Compiler returned: 0
[Bug web/88860] Clarify gcc online manual 6.38 Attribute Syntax
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88860 --- Comment #9 from Jonny Grant --- (In reply to Jonathan Wakely from comment #8) > Has it been reviewed and approved? I can't do that for patches outside the > libstdc++-v3 dir. I've not yet received a reply to it on gcc-patches list. https://gcc.gnu.org/pipermail/gcc-patches/2022-December/609132.html
[Bug web/88860] Clarify gcc online manual 6.38 Attribute Syntax
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88860 --- Comment #7 from Jonny Grant --- (In reply to Jonathan Wakely from comment #6) > (In reply to Jonny Grant from comment #5) > > Re the patches, I recall I did email them, but pasted here too as another > > developer was doing that. I'll have a good read of that contribution guide. > > If you've emailed them to the list then it's better to link to the mails in > the list archive, not duplicate them here. > > > What did you think of the "infelicities" patch? > > It loses a little of the nuance, i.e. that the limitations are unfortunate. > But I think it's an improvement. Ok thank you. May I ask if you could commit the patch please?
[Bug web/88860] Clarify gcc online manual 6.38 Attribute Syntax
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88860 --- Comment #5 from Jonny Grant --- (In reply to Jonathan Wakely from comment #4) > (In reply to Jonny Grant from comment #1) > > --- a/gcc/doc/extend.texi > > +++ b/gcc/doc/extend.texi > > @@ -9353,6 +9353,13 @@ __attribute__((noreturn)) void d0 (void), > > the @code{noreturn} attribute applies to all the functions > > declared; the @code{format} attribute only applies to @code{d1}. > > > > +@noindent > > +The following __attribute__ causes gcc to check run printf argument checks > > "check run printf argument checks" > > > > on argument '3' which is 'const char * string format' (when visible at > > compile time), against argument '4' the '...' variadic ellipsis. In the > > example below, arguments '1' and '2' are not checked. > > + > > +@smallexample > > +void string_format(const char * prefix, size_t line, const char * const > > format, ...) __attribute__ ((format (printf,3,4))); > > +@end smallexample > > > This argument seems to be documenting the effects of the printf attribute, > not attribute syntax. Why would it belong on this page? You're right, I found this page with an example that is fine https://gcc.gnu.org/onlinedocs/gcc-12.2.0/gcc/Common-Function-Attributes.html#Common-Function-Attributes Re the patches, I recall I did email them, but pasted here too as another developer was doing that. I'll have a good read of that contribution guide. What did you think of the "infelicities" patch? Thanks
[Bug c/88944] Suggested alternative C stdbool.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88944 Jonny Grant changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Jonny Grant --- gcc (Ubuntu 12.2.0-3ubuntu1) 12.2.0 Saw it is suggested and works.
[Bug c++/96412] format suggestion issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96412 --- Comment #2 from Jonny Grant --- Just posted this on bug 90205 but maybe more appropriate here gcc (Ubuntu 12.2.0-3ubuntu1) 12.2.0 Another example, but suggesting the same %ld from a sizeof printf("sizeof time_t %zu\n", sizeof(time_t)); broken.c:35:35: warning: format ‘%ld’ expects argument of type ‘long int’, but argument 2 has type ‘long unsigned int’ [-Wformat=] 35 | printf("sizeof unsigned int %ld\n", sizeof(unsigned int)); | ~~^ | | | | | long unsigned int | long int | %ld
[Bug c++/90205] Wformat-signedness detects %d and suggests %d fixit hint
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90205 --- Comment #11 from Jonny Grant --- That last comment was using gcc (Ubuntu 12.2.0-3ubuntu1) 12.2.0
[Bug c++/90205] Wformat-signedness detects %d and suggests %d fixit hint
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90205 --- Comment #10 from Jonny Grant --- printf("sizeof time_t %ld\n", sizeof(time_t)); Another example, but suggesting the same %ld from a sizeof broken.c:34:29: error: format ‘%ld’ expects argument of type ‘long int’, but argument 2 has type ‘long unsigned int’ [-Werror=format=] 34 | printf("sizeof time_t %ld\n", sizeof(time_t)); | ~~^ ~~ | | | | | long unsigned int | long int | %ld Probably %zu is the appropriate format to be suggested?
[Bug web/88860] Clarify gcc online manual 6.38 Attribute Syntax
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88860 --- Comment #2 from Jonny Grant --- 2022-12-26 Jonathan Grant * gcc/doc/extend.texi: Bugzilla 88860 - Clarify online manual infelicities >From 8b142ad8973dc67289e197e30966490a944e4819 Mon Sep 17 00:00:00 2001 From: Jonathan Grant Date: Mon, 26 Dec 2022 20:58:29 + Subject: [PATCH] Bugzilla 88860 - Clarify gcc online manual infelicities Signed-off-by: Jonathan Grant --- gcc/doc/extend.texi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi index adba057c190..88fc625050b 100644 --- a/gcc/doc/extend.texi +++ b/gcc/doc/extend.texi @@ -9190,7 +9190,7 @@ have to optimize it to just @code{return 42 + 42;}. This section describes the syntax with which @code{__attribute__} may be used, and the constructs to which attribute specifiers bind, for the C language. Some details may vary for C++ and Objective-C@. Because of -infelicities in the grammar for attributes, some forms described here +limitations in the grammar for attributes, some forms described here may not be successfully parsed in all cases. There are some problems with the semantics of attributes in C++. For -- 2.37.2
[Bug sanitizer/88997] Implicit constructors created with line numbers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88997 --- Comment #3 from Jonny Grant --- (In reply to Jonny Grant from comment #2) > 2022-12-26 Jonathan Grant > * gcc/doc/extend.texi: Bugzilla 88860 - Clarify online manual > infelicities > > > >From 8b142ad8973dc67289e197e30966490a944e4819 Mon Sep 17 00:00:00 2001 > From: Jonathan Grant > Date: Mon, 26 Dec 2022 20:58:29 + > Subject: [PATCH] Bugzilla 88860 - Clarify gcc online manual infelicities Darn, wrong ticket.
[Bug sanitizer/88997] Implicit constructors created with line numbers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88997 --- Comment #2 from Jonny Grant --- 2022-12-26 Jonathan Grant * gcc/doc/extend.texi: Bugzilla 88860 - Clarify online manual infelicities >From 8b142ad8973dc67289e197e30966490a944e4819 Mon Sep 17 00:00:00 2001 From: Jonathan Grant Date: Mon, 26 Dec 2022 20:58:29 + Subject: [PATCH] Bugzilla 88860 - Clarify gcc online manual infelicities Signed-off-by: Jonathan Grant --- gcc/doc/extend.texi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi index adba057c190..88fc625050b 100644 --- a/gcc/doc/extend.texi +++ b/gcc/doc/extend.texi @@ -9190,7 +9190,7 @@ have to optimize it to just @code{return 42 + 42;}. This section describes the syntax with which @code{__attribute__} may be used, and the constructs to which attribute specifiers bind, for the C language. Some details may vary for C++ and Objective-C@. Because of -infelicities in the grammar for attributes, some forms described here +limitations in the grammar for attributes, some forms described here may not be successfully parsed in all cases. There are some problems with the semantics of attributes in C++. For -- 2.37.2
[Bug web/88860] Clarify gcc online manual 6.38 Attribute Syntax
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88860 --- Comment #1 from Jonny Grant --- 2022-12-26 Jonathan Grant * gcc/doc/extend.texi: Bugzilla 88860 - Add attribute format printf example >From 1668dc58206428ee92ff142bafb5f545dba029ae Mon Sep 17 00:00:00 2001 From: Jonathan Grant Date: Mon, 26 Dec 2022 21:02:35 + Subject: [PATCH] Bugzilla 88860 - Clarify gcc online manual attribute format printf example Signed-off-by: Jonathan Grant --- gcc/doc/extend.texi | 7 +++ 1 file changed, 7 insertions(+) diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi index 88fc625050b..9b200c6f3a0 100644 --- a/gcc/doc/extend.texi +++ b/gcc/doc/extend.texi @@ -9353,6 +9353,13 @@ __attribute__((noreturn)) void d0 (void), the @code{noreturn} attribute applies to all the functions declared; the @code{format} attribute only applies to @code{d1}. +@noindent +The following __attribute__ causes gcc to check run printf argument checks on argument '3' which is 'const char * string format' (when visible at compile time), against argument '4' the '...' variadic ellipsis. In the example below, arguments '1' and '2' are not checked. + +@smallexample +void string_format(const char * prefix, size_t line, const char * const format, ...) __attribute__ ((format (printf,3,4))); +@end smallexample + An attribute specifier list may appear immediately before the comma, @code{=} or semicolon terminating the declaration of an identifier other than a function definition. Such attribute specifiers apply -- 2.37.2
[Bug sanitizer/81649] Instrumentation Options page grammar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81649 --- Comment #2 from Jonny Grant --- (In reply to Jakub Jelinek from comment #1) > That doesn't look correct to me, as it is the option that ensures that the > executables are linked against such a library, after all, it is the only > purpose of the option. Maybe we should just replace the " and t" with ". T". That sounds good. I made a patch with your change and will email to gcc-patches. If you could review please.
[Bug c/108224] Suggest stdlib.h header for rand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108224 --- Comment #5 from Jonny Grant --- (In reply to Sam James from comment #4) > (In reply to Jonny Grant from comment #3) > > Great! I just saw it is the same for random(), srandom(), initstate(), > > setstate() > > > > Is there an easy way to add them all based on the C API to save opening > > separate tickets? > > > > I added those : > > Could you send the patch to gcc-patches (the mailing list)? Thanks. Sure, just sent :-)
[Bug c/108224] Suggest stdlib.h header for rand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108224 --- Comment #3 from Jonny Grant --- Great! I just saw it is the same for random(), srandom(), initstate(), setstate() Is there an easy way to add them all based on the C API to save opening separate tickets? I added those : >From 6ff344979af46dbcd739dd9068d6d595547e4c27 Mon Sep 17 00:00:00 2001 From: Jonathan Grant Date: Sun, 25 Dec 2022 22:38:44 + Subject: [PATCH] add srandom random initstate setstate --- gcc/c-family/known-headers.cc | 4 1 file changed, 4 insertions(+) diff --git a/gcc/c-family/known-headers.cc b/gcc/c-family/known-headers.cc index 9c256173b82..ade9fa2dcc0 100644 --- a/gcc/c-family/known-headers.cc +++ b/gcc/c-family/known-headers.cc @@ -171,6 +171,10 @@ get_stdlib_header_for_name (const char *name, enum stdlib lib) {"getenv", {"", ""} }, {"malloc", {"", ""} }, {"realloc", {"", ""} }, +{"random", {"", ""} }, +{"srandom", {"", ""} }, +{"initstate", {"", ""} }, +{"setstate", {"", ""} }, /* and . */ {"memchr", {"", ""} }, -- 2.37.2
[Bug c/108224] New: Suggest stdlib.h header for rand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108224 Bug ID: 108224 Summary: Suggest stdlib.h header for rand Product: gcc Version: 12.2.0 Status: UNCONFIRMED Keywords: diagnostic Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: jg at jguk dot org Target Milestone: --- Would be great if the suggestions could suggest for rand() Same in C and C++
[Bug sanitizer/89868] -fsanitize=address inhibits core dumps
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89868 --- Comment #12 from Jonny Grant --- (In reply to Jakub Jelinek from comment #11) > The shadow maps are 1/8 of the address space, so I think that is 16TB. Ah ok, that explains it. Thank you.
[Bug demangler/90039] libiberty demangling _GLOBAL__sub_I__Z11print_tracev
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90039 --- Comment #1 from Jonny Grant --- Hello. Could someone confirm please?
[Bug sanitizer/89868] -fsanitize=address inhibits core dumps
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89868 --- Comment #9 from Jonny Grant --- (In reply to Andrew Pinski from comment #8) > Not a bug as mentioned, the core file just becomes too big for the limits > (either hard or soft limits). $ ulimit -c unlimited /dev/sda5 709G 479G 195G 72% / Would the core file be larger than 195 Gigabytes ?
[Bug driver/81371] Too many C++ templates output in build error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81371 --- Comment #7 from Jonny Grant --- It would be nice to have a way to print the original std::string name, but depends if it is really worth all the trouble to have an the non expanded template name as alternative... It would make error messages clearer. That way, the symbol could stay the same, but the linker could show the alternative..
[Bug preprocessor/84864] Issues with large line numbers >= 2^31
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84864 --- Comment #9 from Jonny Grant --- I'm sure you all know more than me. But I understood #line 0was not allowed. Therefore, it can simply be unsigned, and 0 used to indicate an error, instead of negative values. #line 0 is not currently an error, but probably should right? file line numbers start at 1. If it was changed to a uint64, at least this issue wouldn't occur for a long time. BTW, could this message clarify what the supported range is? Probably 2147483648 ? Output of x86-64 gcc (trunk) (Compiler #1) :1:7: warning: line number out of range 1 | #line 88 | ^~ Compiler returned: 0
[Bug c++/64228] compile error not accurate expected ; before string constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64228 --- Comment #2 from Jonny Grant --- (In reply to Andrew Pinski from comment #1) > The trunk show: > : In function 'int main()': > :7:30: error: expected ';' before string constant > 7 | std::cout << "oops " << i " number" << endl; > | ^~ > | ; > > Error recovery is always hard even saying << might be wrong when you want +. Hi Andrew You're right. The suggestion might not be what was desired. The caret location is enough to help programmer fix the build error.
[Bug c++/101052] Suggest stdlib.h when exit(1) is called
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101052 --- Comment #5 from Jonny Grant --- Amazing 1-day turnaround, thank you Jonathan!
[Bug c++/101052] Suggest stdlib.h when exit(1) is called
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101052 --- Comment #1 from Jonny Grant --- Code link: https://godbolt.org/z/vYTc87db1
[Bug c++/101052] New: Suggest stdlib.h when exit(1) is called
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101052 Bug ID: 101052 Summary: Suggest stdlib.h when exit(1) is called Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: jg at jguk dot org Target Milestone: --- >From godbolt GCC trunk 13 June 2021 Could #include be suggested please. -Wall -O2 123 # For more information see the output window x86-64 gcc (trunk) - 322ms #1 with x86-64 gcc (trunk) : In function 'void f(int*)': :8:9: error: 'exit' was not declared in this scope 8 | exit(1); | ^~~~ Compiler returned: 1 //#include #include void f(int * g) { if(NULL == g) { exit(1); } }
[Bug middle-end/88175] GCC should not warn within implicit copy-constructor (or should report the implicit function in a special way)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88175 --- Comment #20 from Jonny Grant --- (In reply to Jonathan Wakely from comment #19) > Why is that needed? It says the location is something like: > > In member function ‘info& info::operator=(const info&)’, > > or: > > In copy constructor ‘info::info(const info&)’, > > If that isn't explicitly defined in the class, then obviously it's being > defined implicitly by the compiler. That property of C++ should not surprise > anybody. You're point is valid. Highlighting it is implicitly generated is purely an informative diagnostic. I've been on C++ teams where certain software engineers weren't aware of implicitly generated constructors.
[Bug middle-end/88175] GCC should not warn within implicit copy-constructor (or should report the implicit function in a special way)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88175 --- Comment #18 from Jonny Grant --- Hello Martin It looks better. May I ask, if the "implicitly generated copy assignment" and "copy constructor" could be mentioned in the warning that they were implicitly generated? Thank you, Jonny
[Bug c/98819] Wall Wformat-signedness suggests %u for %u
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98819 --- Comment #7 from Jonny Grant --- https://godbolt.org/z/bhnbsb Another example where %ld suggests to replace with %ld #include int main() { size_t i = 0; std::printf("%ld", i); } -Wall -Wformat-signedness x86-64 gcc (trunk) - 600ms (19538B) #1 with x86-64 gcc (trunk) : In function 'int main()': :6:20: warning: format '%ld' expects argument of type 'long int', but argument 2 has type 'size_t' {aka 'long unsigned int'} [-Wformat=] 6 | std::printf("%ld", i); | ~~^ ~ || | || size_t {aka long unsigned int} |long int | %ld Compiler returned: 0
[Bug c/98819] Wall Wformat-signedness suggests %u for %u
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98819 --- Comment #6 from Jonny Grant --- Godbolt %u example https://godbolt.org/z/sc7K6T
[Bug c/98819] Wall Wformat-signedness suggests %u for %u
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98819 --- Comment #5 from Jonny Grant --- (In reply to David Malcolm from comment #4) > In comment #0, the bottom-most "%u" is a fix-it hint, giving the nonsensical > suggestion to the user that they replace the "%u" with itself. Clearly we > shouldn't issue such a fix-it hint. > > I'm not able to reproduce the warning with the given reproducer. What flags > are you using? Do you have a URL for your godbolt example? Hello David, Martin Godbot was with: -Wall -Wformat-signedness https://godbolt.org/z/bn3oeh
[Bug c++/98819] Wall Wformat-signedness suggests %u for %u
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98819 --- Comment #2 from Jonny Grant --- (In reply to Andrew Pinski from comment #1) > I think you misunderstood the diagnostic. It is saying unsigned int is for > %u. The type you have is int. Ah, is that "%u" not the suggestion? Change it to %f and it gives the clear "%d" suggestion I expected for my int #1 with x86-64 gcc (trunk) : In function 'int main()': :6:19: warning: format '%f' expects argument of type 'double', but argument 2 has type 'int' [-Wformat=] 6 | std::printf("%f", CURRENT_YEAR); | ~^ | | | double | %d Compiler returned: 0
[Bug c++/98819] New: -Wall -Wformat-signedness suggests %u for %u
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98819 Bug ID: 98819 Summary: -Wall -Wformat-signedness suggests %u for %u Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: jg at jguk dot org Target Milestone: --- Reproduced in latest Godbolt trunk %u is suggested for %u #1 with x86-64 gcc (trunk) : In function 'int main()': :6:19: warning: format '%u' expects argument of type 'unsigned int', but argument 2 has type 'int' [-Wformat=] 6 | std::printf("%u", CURRENT_YEAR); | ~^ | | | unsigned int | %u Compiler returned: 0 #include #define CURRENT_YEAR 2021 int main() { std::printf("%u", CURRENT_YEAR); }