https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104069
--- Comment #26 from Sergei Trofimovich ---
#c12 fixed elfutils case.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104069
--- Comment #25 from Mark Wielaard ---
Note that elfutils-0.187 builds fine for me on fedora x86_64 with either:
gcc (GCC) 12.2.1 20220819 (Red Hat 12.2.1-2)
So this might have been fixed since 12.2.0?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104069
vincent at systemli dot org changed:
What|Removed |Added
CC||vincent at systemli dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104069
Rolf Eike Beer changed:
What|Removed |Added
CC||e...@sf-mail.de
--- Comment #23 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104069
Martin Sebor changed:
What|Removed |Added
Assignee|msebor at gcc dot gnu.org |unassigned at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104069
--- Comment #21 from Jakub Jelinek ---
#c0 is fixed with the r12-6712-g2f714642e574c64e1c0e093cad3de6f8accb6ec7
change.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104069
--- Comment #20 from Martin Sebor ---
This warning, like all others, is meant to help find common bugs in ordinary
code. It shouldn't be expected to reflect implementation-defined behavior or
to be free of false positives. Tricky code that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104069
--- Comment #19 from Jakub Jelinek ---
Note, actually because of the glibc and AIX behavior, after the first realloc
returns NULL if size is 0, then ptr has been freed and so the code actually is
a use after free. For BSD it is not a use after
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104069
--- Comment #18 from Jakub Jelinek ---
(In reply to Martin Sebor from comment #14)
> Removing the test for !size from the first conditional avoids the warning.
> I don't fully understand what the code tries to do but the following avoids
> it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104069
--- Comment #17 from Martin Sebor ---
Having spent some time trying to understand the function I think the following
simplification should capture its intent. It compiles without warnings at all
levels:
void *xrealloc (void *ptr, size_t size)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104069
--- Comment #16 from Andrew Pinski ---
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2396.htm#dr_400
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104069
--- Comment #15 from Andrew Pinski ---
I think the new code in comment #14 is the only code which is well defined in
c17 really. Before c17 (dr400), realloc for sizes of 0 the return value was
unspecified which means it could return null or an
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104069
--- Comment #14 from Martin Sebor ---
Removing the test for !size from the first conditional avoids the warning. I
don't fully understand what the code tries to do but the following avoids it at
-O2 (only):
void *xrealloc (void *ptr, int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104069
--- Comment #13 from Martin Sebor ---
I confused things (including myself) yesterday, sorry.
Let me try again, with just the -O2 behavior for the test case in comment #2:
void *xrealloc (void *ptr, int size)
{
void *ret = __builtin_realloc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104069
--- Comment #12 from CVS Commits ---
The master branch has been updated by Martin Sebor :
https://gcc.gnu.org/g:2f714642e574c64e1c0e093cad3de6f8accb6ec7
commit r12-6712-g2f714642e574c64e1c0e093cad3de6f8accb6ec7
Author: Martin Sebor
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104069
--- Comment #11 from Andrew Macleod ---
(In reply to Jakub Jelinek from comment #10)
> It is not, because it emits a false positive on a fairly common code.
> Anyway, if bb3 jumps to bb4, then bb3 should have in the ranger assertion
> that in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104069
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104069
--- Comment #9 from Martin Sebor ---
My mistake, a PHI is an OR of its operands, not an AND. With that, the IL
doesn't rule out that the subsequent realloc() call isn't made with the
argument to a prior successful realloc(). So for the more
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104069
--- Comment #8 from Jakub Jelinek ---
ret_7 == 0 certainly doesn't imply ret_17 == 0, so it is correct ranger doesn't
know. ret_7 == 0 implies that either ret_17 == 0 if bb 2 jumped to bb 4, in
that case ret_19 isn't even defined, or ret_19 is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104069
Martin Sebor changed:
What|Removed |Added
Component|tree-optimization |middle-end
--- Comment #7 from Martin
20 matches
Mail list logo
