[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);
}
[Bug c++/96521] New: Suggest signal.h missing include
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96521
Bug ID: 96521
Summary: Suggest signal.h missing include
Product: gcc
Version: 10.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jg at jguk dot org
Target Milestone: ---
Hello
Could g++ suggest signal.h?
int main()
{
raise(SIGSEGV);
}
#1 with x86-64 gcc (trunk)
: In function 'int main()':
:3:11: error: 'SIGSEGV' was not declared in this scope
3 | raise(SIGSEGV);
| ^~~
:3:5: error: 'raise' was not declared in this scope
3 | raise(SIGSEGV);
| ^
Compiler returned: 1
[Bug c++/96412] New: format suggestion issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96412
Bug ID: 96412
Summary: format suggestion issue
Product: gcc
Version: 10.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jg at jguk dot org
Target Milestone: ---
Running on godbolt trunk
The suggestion is '%ld' in green type colour in the terminal, but should it
actually be '%zu' ?
-Wformat-signedness -Wall
#include
int main()
{
size_t i = 0;
printf("%ld\n", i);
}
#1 with x86-64 gcc (trunk)
: In function 'int main()':
:5:11: warning: format '%ld' expects argument of type 'long int', but
argument 2 has type 'size_t' {aka 'long unsigned int'} [-Wformat=]
5 | printf("%ld\n", i);
| ~~^ ~
| | |
| | size_t {aka long unsigned int}
| long int
| %ld
Compiler returned: 0
[Bug c++/96214] gcc warn unreached else {}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96214 --- Comment #5 from Jonny Grant --- I saw this similar one too:- https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#Warning-Options -Wduplicated-cond Warn about duplicated conditions in an if-else-if chain. For instance, warn for the following code:
[Bug c++/96214] gcc warn unreached else {}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96214
--- Comment #4 from Jonny Grant ---
I realised there could be many else {} that can't be executed, added one more
to the example.
int main(void)
{
const int i = 1;
if(1 == i)
{
return 1;
}
else if(1 != i)
{
return 2;
}
else if(2 != i)
{
return 2;
}
else
{
return 3;
}
}
[Bug c++/96214] gcc warn unreached else {}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96214 --- Comment #2 from Jonny Grant --- Thank you. Saw there is -Wdangling-else already as well
[Bug c++/96214] New: gcc warn unreached else {}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96214
Bug ID: 96214
Summary: gcc warn unreached else {}
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: ---
First posted here
https://gcc.gnu.org/pipermail/gcc-help/2020-July/139136.html
Can g++ warn where code will not get to the 'return 3;' below?
This isn't real code, this is just an example. Upon code reviews, I do come
across something like this, so a warning would be handy.
My example
int main(void)
{
const int i = 1;
if(1 == i)
{
return 1;
}
else if(1 != i)
{
return 2;
}
else
{
return 3;
}
}
Quoting Martin Sebor
-Wduplicated-branches detects a related problem. It's implemented
entirely in the front end and quite simplistic. It just looks at
the chain of expressions controlling the if statements and compares
them for equality. I think it could be enhanced with not too much
effort to detect a subset of this problem as well by considering
the operator as well as its operands.
Here's the function that does the checking and issues the warning:
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/c-family/c-warn.c#l2491
Martin
[Bug c++/85958] Make const qualifier error clear
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85958
--- Comment #12 from Jonny Grant ---
Another example const.cpp attached.
The message doesn't mention it's the const qualifier.
Expected:
:6:21: error: passing 'const
std::vector >' as 'this' argument discards
const qualifier [-fpermissive]
6 | vec.push_back("");
| ^
Output:
#1 with x86-64 gcc (trunk)
: In function 'void f(const
std::vector >&)':
:6:21: error: passing 'const
std::vector >' as 'this' argument discards
qualifiers [-fpermissive]
6 | vec.push_back("");
| ^
In file included from
/opt/compiler-explorer/gcc-trunk-20200506/include/c++/11.0.0/vector:67,
from :2:
/opt/compiler-explorer/gcc-trunk-20200506/include/c++/11.0.0/bits/stl_vector.h:1203:7:
note: in call to 'void std::vector<_Tp, _Alloc>::push_back(std::vector<_Tp,
_Alloc>::value_type&&) [with _Tp = std::__cxx11::basic_string; _Alloc =
std::allocator >; std::vector<_Tp,
_Alloc>::value_type = std::__cxx11::basic_string]'
1203 | push_back(value_type&& __x)
| ^
Compiler returned: 1
[Bug c++/85958] Make const qualifier error clear
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85958 --- Comment #11 from Jonny Grant --- Created attachment 48463 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48463=edit argument discards qualifiers Another example "argument discards qualifiers"
[Bug c++/92660] overflow warning message enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92660 --- Comment #1 from Jonny Grant --- Improved suggestion with the sign indicated: const int n = 411; :1:15: warning: overflow in conversion from 'long int' (signed 64bit) to 'int' (signed 32bit) changes value from '411' to '-1838561849' [-Woverflow] 1 | const int n = 411; | ^~~ Another example: const unsigned int n = 411; Improved suggestion with the sign indicated: :1:24: warning: unsigned conversion from 'long int' (signed 64bit) to 'unsigned int' (unsigned 32bit) changes value from '411' to '2456405447' [-Woverflow] 1 | const unsigned int n = 411; |^~~
[Bug c++/92675] sign-conversion C++ unsigned int j = -1;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92675 --- Comment #6 from Jonny Grant --- Is the clearest way to write this as follows? unsigned int j = (unsigned int)-1; Likewise for the template example: U max = (U)-1; // good
[Bug c++/92675] sign-conversion C++ unsigned int j = -1;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92675 --- Comment #5 from Jonny Grant --- I tried godbolt trunk again for C++ today with -Wsign-conversion and it does give a warning. I can only think I made a mistake while checking - unless a patch has just gone in?
[Bug c++/92659] Suggestions for bitshift
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92659 --- Comment #10 from Jonny Grant --- (In reply to Jonathan Wakely from comment #8) > Because 5147483647 doesn't fit in an int, so it picks a larger type, because > that's what the standard requires. 1 does fit in an int, so the compiler > picks int, because that's what the standard requires. Fair enough. Let's close this PR if no support for this suggestion.
[Bug c++/92675] sign-conversion C++ unsigned int j = -1;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92675 --- Comment #2 from Jonny Grant --- (In reply to Jonathan Wakely from comment #1) > That's an idiomatic way to get the largest unsigned value, it would be a > shame if it warned. Personally I would use UINT_MAX from limits.h, feels more idiomatic.
[Bug c++/92659] Suggestions for bitshift
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92659 --- Comment #7 from Jonny Grant --- (In reply to David Brown from comment #4) > (In reply to Jonny Grant from comment #2) > > (In reply to Xi Ruoyao from comment #1) > > > Is it appropriate? > > > > > > Though on both 32-bit and 64-bit x86 "1ul" is good for a size_t, but I > > > believe there is some platform where "1ull" is necessary. > > > > > > Maybe I'm wrong. But if I'm correct, suggesting "1ul" is encouraging bad > > > code. I'll use "(size_t) 1 << 32" for this. > > > > UL means Unsigned Long, so if that type is also 64bit like size_t, then it > > is fine. > > > > > > I would rather use the real type, if the compiler is too stupid to start > > with a type big enough... the same code with 5147483647 works fine, because > > the compiler starts with the number as a 'long int' which is already 64bit, > > no suffix required. > > > > I recommend you learn the details of how C works before declaring the > compiler "stupid". This sort of thing is not up to the compiler. When you > write "1 << 32", the "1" is of type "int". The compiler is not allowed to > choose a different type - the best it can do is give you a warning. And the > compiler already /does/ give a warning - a perfectly good warning. It is > not the compiler's job to teach you how to program in C. Hi David, Compiler manages it okay with this example below. Therefore the compiler appears to be allowed to choose 'long int' for the number being shifted in this test case. #include size_t i = 5147483647 << 2;
[Bug c++/92659] Suggestions for bitshift
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92659
--- Comment #2 from Jonny Grant ---
(In reply to Xi Ruoyao from comment #1)
> Is it appropriate?
>
> Though on both 32-bit and 64-bit x86 "1ul" is good for a size_t, but I
> believe there is some platform where "1ull" is necessary.
>
> Maybe I'm wrong. But if I'm correct, suggesting "1ul" is encouraging bad
> code. I'll use "(size_t) 1 << 32" for this.
UL means Unsigned Long, so if that type is also 64bit like size_t, then it is
fine.
I would rather use the real type, if the compiler is too stupid to start with a
type big enough... the same code with 5147483647 works fine, because the
compiler starts with the number as a 'long int' which is already 64bit, no
suffix required.
#include
int f()
{
size_t i = 1;
i = i << 32;
return i;
}
[Bug c++/92675] New: sign-conversion C++ unsigned int j = -1;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92675 Bug ID: 92675 Summary: sign-conversion C++ unsigned int j = -1; Product: gcc Version: 10.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 G++ also give a nice error for -Wsign-conversion ? unsigned int j = -1; GCC does already for C code, as does Clang C++ #1 with x86-64 gcc (trunk) :1:18: warning: unsigned conversion from 'int' to 'unsigned int' changes value from '-1' to '4294967295' [-Wsign-conversion] 1 | unsigned int j = -1; | ^~ Clang gives a nice error with C++: #1 with x86-64 clang (trunk) :1:18: warning: implicit conversion changes signedness: 'int' to 'unsigned int' [-Wsign-conversion] unsigned int j = -1; ~ ^~ 1 warning generated. Compiler returned: 0 Compiler returned: 1
[Bug c++/92642] Enhance shift-count-overflow output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92642
--- Comment #4 from Jonny Grant ---
This test case for similar does have a nice warning.
Interestingly, G++ does not indicate that 5147483647 is already 34 bits long:
100110010110101011101
which is more than an 'int' (32bit) which as Jonathan has highlighted, to be
the way numbers are treated in C/C++ when they do not have UL suffix.
#include
int main()
{
size_t i = 5147483647 << 32;
printf("%zu\n", i);
}
#1 with x86-64 gcc (trunk)
: In function 'int main()':
:5:23: warning: result of '(5147483647 << 32)' requires 66 bits to
represent, but 'long int' only has 64 bits [-Wshift-overflow=]
5 | size_t i = 5147483647 << 32;
|~~~^
[Bug c++/92660] New: overflow warning message enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92660 Bug ID: 92660 Summary: overflow warning message enhancement Product: gcc Version: 10.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 GCC, for both C and C++ output the bitsize on the overflow warning ? const int n = 411; #1 with x86-64 gcc (trunk) :1:15: warning: overflow in conversion from 'long int' to 'int' changes value from '411' to '-1838561849' [-Woverflow] 1 | const int n = 411; | ^~~ Suggestion: :1:15: warning: overflow in conversion from 'long int' (64bit) to 'int' (32bit) changes value from '411' to '-1838561849' [-Woverflow] 1 | const int n = 411; | ^~~
[Bug c++/92659] New: Suggestions for bitshift
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92659 Bug ID: 92659 Summary: Suggestions for bitshift Product: gcc Version: 10.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 GCC suggest for C/C++ the code change? #include size_t i = 1 << 32; #1 with x86-64 gcc (trunk) :2:14: warning: left shift count >= width of type [-Wshift-count-overflow] 2 | size_t i = 1 << 32; |~~^ Compiler returned: 0 It could output: :2:14: warning: left shift count >= width of type [-Wshift-count-overflow] 2 | size_t i = 1 << 32; |~~^ | size_t i = 1 << 32; | ~~^ |1UL << 32;
[Bug c++/92642] Enhance shift-count-overflow output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92642 --- Comment #2 from Jonny Grant --- (In reply to Jonathan Wakely from comment #1) > (A) seems pointless in this case, it's right there in the caret diagnostic. > > The type size_t is irrelevant. > > IMO a better testcase would be: > > const int n = 41; > auto x = 1 << n; Sounds good. That 'n' might be passed in from somewhere, so worth including the number in the output if it is visible (compiler is aware of the value if it is const right?)
[Bug c++/92642] New: Enhance shift-count-overflow output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92642 Bug ID: 92642 Summary: Enhance shift-count-overflow output Product: gcc Version: 10.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 g++ enhance this warning ? Suggestion: A) Include the number of bits being shifted B) Include the type of the value being shifted. C) Include the size in bits of the type in (B). #1 with x86-64 gcc (trunk) :2:15: warning: left shift count >= width of type [-Wshift-count-overflow] 2 | size_t big = 1<<41; | ~^~~~ Compiler returned: 0 Suggestion: #1 with x86-64 gcc (trunk) :2:15: warning: left shift count '41' >= width of type 'int' (32bit) [-Wshift-count-overflow] 2 | size_t big = 1<<41; | ~^~~~ Compiler returned: 0 Code: #include size_t big = 1<<41;
[Bug c++/85861] g++ -Wconversion misses int to size_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85861
--- Comment #14 from Jonny Grant ---
It would be useful to see the size in bits of each conversion, could that be
added?
Currently it shows:
$ g++-8 -Wall -Wextra -Wsign-conversion -o size_t size_t.cpp
size_t.cpp: In function ‘int main()’:
size_t.cpp:14:19: warning: conversion to ‘size_t’ {aka ‘long unsigned int’}
from ‘int’ may change the sign of the result [-Wsign-conversion]
size_t big2 = smaller;
^~~
size_t.cpp:19:18: warning: conversion to ‘size_t’ {aka ‘long unsigned int’}
from ‘int’ may change the sign of the result [-Wsign-conversion]
size_t in2 = in;
^~
It would be useful as:
size_t.cpp: In function ‘int main()’:
size_t.cpp:14:19: warning: conversion to 64bit ‘size_t’ {aka ‘long unsigned
int’} from 32bit ‘int’ may change the sign of the result [-Wsign-conversion]
size_t big2 = smaller;
^~~
The warning is only about the loss of signed, not about the width in fields of
the conversion at present.
[Bug c++/85861] g++ -Wconversion misses int to size_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85861
--- Comment #13 from Jonny Grant ---
(In reply to Jonathan Wakely from comment #11)
> My guess is that we don't want to warn about conversions that are
> well-defined and the original value can be obtained by a round-trip.
> Converting a size_t to an int is lossy, i.e. converting back to size_t may
> not give the original value. But converting an int to size_t and back to an
> int is value preserving.
Do you mean because size_t is 64bit typically, and int is only 32bit?
I tested this on my 64bit Ubuntu
It converts a size_t 9,223,372,036,854,775,807 to an int
and ends up with 18,446,744,073,709,551,615
Which I was surprised about, as I thought int was 4 bytes. I had expected
4,294,967,295
printf("size_t: %zu\n", sizeof(size_t));
printf("int: %zu\n", sizeof(int));
size_t big = 9223372036854775807;
int smaller = big;
size_t big2 = smaller;
printf("smaller: %d, big2: %zu\n", smaller, big2);
> So I can see why it makes sense to have different warnings for lossy and
> non-lossy conversions.
That sounds good, all lossy would be useful to have a loss of precision
warning.
[Bug c++/92158] Missed -Wsign-conversion in C++ when -1 enum converted to unsigned int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92158
--- Comment #10 from Jonny Grant ---
C++ 'enum class' gives a nice error for conversion to unsigned.
Example:
enum class E { a = 1 } ;
unsigned i = E::a;
I've asked this before, will just write again so it is on a ticket. I
understand C++ allows implicit conversion of enum's, it would be good to
generate a warning with the following example in C++. So I could make the
conversion explicit
enum E { a = 1 } ;
unsigned i = a;
[Bug c++/92158] Enum warning when -1 enum converted to unsigned int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92158 --- Comment #7 from Jonny Grant --- > Would it be better if I re-file this ticket as implement -Wsign-conversion > for C++ ? I mean expand -Wsign-conversion for C++ to detect the enum conversion that the same option does for C code.
[Bug c++/92158] Enum warning when -1 enum converted to unsigned int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92158
--- Comment #6 from Jonny Grant ---
Many thanks for your reply. Would you rather I close this and create a new
ticket with just your test case so it is clearer on bugzilla?
Just to note, gcc trunk shows a warning in C - but oddly g++ does not for C++
-Wsign-conversion
enum E { a = -1 } ;
unsigned i = a;
Would it be better if I re-file this ticket as implement -Wsign-conversion for
C++ ?
[Bug c++/92159] -Wenum-conversion for C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92159
--- Comment #4 from Jonny Grant ---
My apologies, I tested with the correct test case and it already does not
compile in C++ as desired, so no -Wenum-conversion required.
#include
typedef enum {brandon, jon, mitch} name_t;
typedef enum {fred, dog, cat} name2_t;
name2_t name = brandon;
name_t hik = 3;
int hal_entry(void)
{
if (hik < name)
return(0);
return 1;
}
int main ()
{
printf ("%d\n", hal_entry());
return 0;
}
[Bug c++/92158] Enum warning when -1 enum converted to unsigned int or int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92158
--- Comment #4 from Jonny Grant ---
Hello
Implicit conversion can introduce bugs. I would like to detect implicit enum
conversions to other types in C and C++. How about just adding the C++ warnings
first to match clang in example below?
The following example does produce warnings in C++ with Clang trunk, but not C.
Likewise with MSVC, C++ warning, but no C warning.
G++ only warns on line (19), clang has the additional line (15) and line (17)
warnings.
Could G++ also add the additions warnings?
-O2 -Wall -Wextra -Wconversion -Werror
#include
typedef enum
{
a = -1
} a_t;
a_t f()
{
return a;
}
int main()
{
unsigned int b = f();
a_t test = b;
printf("%u %u", test, b);
return b;
}
#1 with x86-64 clang (trunk)
:15:22: error: implicit conversion changes signedness: 'a_t' to
'unsigned int' [-Werror,-Wsign-conversion]
unsigned int b = f();
~ ^~~
:17:9: error: cannot initialize a variable of type 'a_t' with an lvalue
of type 'unsigned int'
a_t test = b;
^ ~
:19:12: error: implicit conversion changes signedness: 'unsigned int'
to 'int' [-Werror,-Wsign-conversion]
return b;
~~ ^
3 errors generated.
Compiler returned: 1
#1 with x64 msvc v19.22
example.cpp
(18): error C2440: 'initializing': cannot convert from 'unsigned int'
to 'a_t'
(18): note: Conversion to enumeration type requires an explicit cast
(static_cast, C-style cast or function-style cast)
Compiler returned: 2
x86-64 gcc (trunk) - 484ms
#1 with x86-64 gcc (trunk)
: In function 'int main()':
:17:16: error: invalid conversion from 'unsigned int' to 'a_t'
[-fpermissive]
17 | a_t test = b;
|^
||
|unsigned int
Compiler returned: 1
[Bug preprocessor/90476] prepossessor should error if #line 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90476 --- Comment #9 from Jonny Grant --- Maybe it could say warning: line number out of range 1 - 2147483647
[Bug preprocessor/90476] prepossessor should error if #line 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90476 --- Comment #7 from Jonny Grant --- Could someone confirm this please.
[Bug c/78736] enum warnings in GCC (request for -Wenum-conversion to be added)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78736
--- Comment #19 from Jonny Grant ---
(In reply to Eric Gallager from comment #18)
> (In reply to Jonny Grant from comment #17)
> > Hello Joseph
> >
> > This was the test case I created. There isn't any warning output when 'a_t'
> > is converted to 'int'. Or even if it was converted to an 'unsigned int'
> >
> > https://gcc.gnu.org/ml/gcc-help/2019-07/msg00014.html
> >
> >
> > //-O2 -Wall -Wextra -Wconversion -Werror
> >
> > #include
> > typedef enum
> > {
> > a = -1
> > } a_t;
> >
> > a_t f()
> > {
> > return a;
> > }
> >
> > int main()
> > {
> > int b = f();
> > return b;
> > }
>
> While it's true that g++ prints no warnings for that testcase, I think
> that's material for a separate bug. The original bug here was just to add
> -Wenum-conversion for the C front-end, which has now been done, so I'm
> closing this. Feel free to open new bugs for any missed cases.
ok, I added
Bug 92159 to add -Wenum-conversion for C++
Bug 92158 my enum test case for C and C++
[Bug c++/92159] New: -Wenum-conversion for C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92159
Bug ID: 92159
Summary: -Wenum-conversion for C++
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: ---
Bug 60591 added -Wenum-conversion for C
Could this be added for C++ too?
#1 with x86-64 gcc (trunk)
cc1plus: error: command-line option '-Wenum-conversion' is valid for C/ObjC but
not for C++ [-Werror]
cc1plus: all warnings being treated as errors
Compiler returned: 1
Test case
enum xpto
{
A = 0,
B = 1,
X = 512
};
extern void print (unsigned int);
unsigned char bar (enum xpto a)
{
return a;
}
[Bug c++/92158] New: Enum warning when -1 enum converted to unsigned int or int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92158
Bug ID: 92158
Summary: Enum warning when -1 enum converted to unsigned int or
int
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: ---
Could warnings for this be added for C and C++?
I tested on godbolt trunk today 19 Oct 2019.
There isn't any warning output when 'a_t' is converted to 'int'. Or even if it
was converted to an 'unsigned int'
https://gcc.gnu.org/ml/gcc-help/2019-07/msg00014.html
//-O2 -Wall -Wextra -Wconversion -Werror
#include
typedef enum
{
a = -1
} a_t;
a_t f()
{
return a;
}
int main()
{
int b = f();
return b;
}
