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
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
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
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
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
> >
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.
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.
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"},
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
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
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
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
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
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
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
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
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
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
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++
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
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
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
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,
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. ***
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
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
++
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
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
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
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
: 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
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
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
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
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);
>
: 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
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/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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88944
Jonny Grant changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
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));
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
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
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
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
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
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
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
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
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
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++
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.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90039
--- Comment #1 from Jonny Grant ---
Hello. Could someone confirm please?
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
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
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
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;
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101052
--- Comment #5 from Jonny Grant ---
Amazing 1-day turnaround, thank you Jonathan!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101052
--- Comment #1 from Jonny Grant ---
Code link:
https://godbolt.org/z/vYTc87db1
++
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
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
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
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) -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98819
--- Comment #6 from Jonny Grant ---
Godbolt %u example
https://godbolt.org/z/sc7K6T
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
>
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
++
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
++
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
: 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("
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
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)
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
++
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
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]
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"
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
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
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?
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
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
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
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
++
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
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
++
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
: 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 | siz
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
++
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
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()’:
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
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++
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.
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
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
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90476
--- Comment #7 from Jonny Grant ---
Could someone confirm this please.
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
++
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
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
1 - 100 of 320 matches
Mail list logo
