https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80346
--- Comment #16 from Martin Sebor ---
Interestingly, GCC manages to eliminate the memset at -O1 (and thus avoid
warning) but not at -O2:
$ gcc -O1 -S -Wall -Wextra -Wpedantic -fdump-tree-optimized=/dev/stdout ../b.c
;; Function f (f, funcdef_no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80346
--- Comment #15 from Jeffrey A. Law ---
I was looking pretty hard for something the compiler could use to avoid the
problematical paths. That's always my first approach since doing so removes
the warning and generates better code.
I just couldn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80346
--- Comment #14 from Paolo Bonzini ---
And also treat it as undefined behavior and go straight to the else...
kidding, but not entirely!).
The main issue is that here we _are_ testing the overflow behavior of the
function, so we cannot pass sz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80346
--- Comment #13 from Jeffrey A. Law ---
Given an unknown object size and a byte count of -1 we ought to be warning
IMHO.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80346
--- Comment #12 from Paolo Bonzini ---
> So AFAICT, the warning for the first testcase is valid as well.
True, but isn't the maximum object size (2^63-1 aka PTRDIFF_MAX) as bogus as
2^64-1? We are using -1 which is a bit ugly but SIZE_MAX would
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80346
Jeffrey A. Law changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80346
--- Comment #10 from Martin Sebor ---
108 /* compute the table entries in rsdt */
109 tables_nr = (rsdt_table->length - sizeof(AcpiRsdtDescriptorRev1)) /
110 sizeof(uint32_t);
111 g_assert_cmpint(tables_nr, >, 0);
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80346
--- Comment #9 from Dr. David Alan Gilbert ---
(In reply to Paolo Bonzini from comment #8)
> g_assertion_message_cmpnum is not declared anymore as noreturn since glib
> 2.38.
> https://bugzilla.gnome.org/show_bug.cgi?id=692125 :-O
!!!? Oh in th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80346
--- Comment #8 from Paolo Bonzini ---
g_assertion_message_cmpnum is not declared anymore as noreturn since glib 2.38.
https://bugzilla.gnome.org/show_bug.cgi?id=692125 :-O
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80346
--- Comment #7 from Dr. David Alan Gilbert ---
(In reply to Martin Sebor from comment #6)
> The reduced test case from comment #4 doesn't trigger a warning because in
> it the value of n is unknown. The original test case does trigger it
> becau
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80346
--- Comment #6 from Martin Sebor ---
The reduced test case from comment #4 doesn't trigger a warning because in it
the value of n is unknown. The original test case does trigger it because in
it n's range is known. This is evident from the VRP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80346
--- Comment #5 from Jeffrey A. Law ---
My very quick analysis from the IRC chat yesterday was that the first testcase
has a path that should have been detected as unexecutable. I'd work from the
full testcase rather than the reduced one.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80346
Paolo Bonzini changed:
What|Removed |Added
CC||bonzini at gnu dot org
--- Comment #4 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80346
--- Comment #3 from Martin Sebor ---
The warning for attachment 41147 looks valid. It points to the
g_malloc0_n(__n, __s) call in the else statement in the following block. If
I'm reading it right, there, __s is non-zero, and __n is equal to SI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80346
--- Comment #2 from Dr. David Alan Gilbert ---
Created attachment 41147
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41147&action=edit
a different signed/size case
Here's another case (law said to attach it to the same bug), this is givi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80346
Martin Sebor changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
16 matches
Mail list logo
