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 Jo
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 expect
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
Prio
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 nullptr
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 w
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 searc
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
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
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
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
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
n
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 null
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++ s
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 optim
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 disable
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 __attri
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, si
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
nonnull
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
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++
Assig
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
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
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
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: n
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 Jo
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 J
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 analysi
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);
> |
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: norma
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://
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 d0
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));
br
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 ‘lon
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
Da
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 8b142ad8973dc67289e197e30966490a
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
Da
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
D
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 t
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 ad
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 6ff344979af4
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
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 messages
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 e
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
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++
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 ‘inf
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) - 60
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
> shouldn'
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
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++
67 matches
Mail list logo
