https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92765
--- Comment #23 from Richard Biener ---
(In reply to Martin Sebor from comment #22)
> I've been going through the test cases here. IIUC, the one in comment #10
> is a separate issue and should get its own bug. (Arguably, so is the one in
> comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92765
--- Comment #22 from Martin Sebor ---
I've been going through the test cases here. IIUC, the one in comment #10 is a
separate issue and should get its own bug. (Arguably, so is the one in comment
#7.)
It's unfortunate that GIMPLE doesn't prese
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92765
--- Comment #21 from Jakub Jelinek ---
There is no consensus on the #c0 testcase, but there are several other
testcases in this PR that are IMO unquestionably valid (or can be easily turned
into).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92765
--- Comment #20 from Martin Liška ---
@Martin, Jakub: What's the status of the PR? Is there a consensus that it'a a
wrong-code issue?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92765
--- Comment #19 from Jeffrey A. Law ---
Note that while the code in this BZ may or may not be valid, there is certainly
code in the wild which is incorrectly compiled as a result of Qing's patch
which uses TYPE_SIZE. In particular the flatbuffer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92765
--- Comment #18 from Jakub Jelinek ---
Also, note that union doesn't have to be visible on the access path, e.g.
union U { struct S { char a[2]; char b[2]; char c[2]; } s; struct T { char
d[6]; } t; } u;
__attribute__((noipa)) void
bar (char *p)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92765
--- Comment #17 from Jakub Jelinek ---
We explicitly document supporting type punning through unions as an extension,
so it is valid in C++ too. And, what union member is active at which point
really doesn't matter for the testcases, e.g. in #c6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92765
--- Comment #16 from Martin Sebor ---
The warning doesn't affect code generation. It's issued independent of it.
We'll have to agree to disagree about the validity of the test case in comment
#0, but I do agree that at least some of your test c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92765
--- Comment #15 from Jakub Jelinek ---
As for __builtin_*_eq, we could have some analysis that looks at accesses from
the same base, and e.g. if there is struct S { char name[16]; int whatever; }
and
we see strcmp (p->name, ...) and p->whatever s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92765
Jakub Jelinek changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92765
--- Comment #13 from Jakub Jelinek ---
(In reply to Martin Sebor from comment #12)
> The __builtin_strcmp(ptr->header.magic, "x") call in comment #0 is undefined
> because the two-element array ptr->header.magic is not a nul-terminated
> string.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92765
--- Comment #12 from Martin Sebor ---
The __builtin_strcmp(ptr->header.magic, "x") call in comment #0 is undefined
because the two-element array ptr->header.magic is not a nul-terminated string.
The warning was designed to point that out.
Remov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92765
--- Comment #11 from Jakub Jelinek ---
Untested patch to fix all these wrong-code issues would be something like:
--- gcc/tree-ssa-strlen.c.jj2019-11-28 09:35:32.443298424 +0100
+++ gcc/tree-ssa-strlen.c 2019-12-03 17:02:32.131658020 +0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92765
--- Comment #10 from Jakub Jelinek ---
Testcase showing wrong-code with the __builtin_strcmp_eq stuff (assuming the
testcase is considered valid):
/* { dg-do run { target mmap } } */
/* { dg-options "-O2" } */
#include
#include
#ifndef MAP_ANO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92765
--- Comment #9 from Jakub Jelinek ---
(In reply to Jeffrey A. Law from comment #8)
> Perhaps related to:
>
> https://gcc.gnu.org/ml/gcc-patches/2019-10/msg01874.html
Yes, that is pretty much the same thing. One thing is whether it is safe or
u
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92765
Jeffrey A. Law changed:
What|Removed |Added
CC||law at redhat dot com
--- Comment #8 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92765
--- Comment #7 from Jakub Jelinek ---
Now, determine_min_objsize has been introduced for the strcmp_eq optimization
and maybe doing something conservative for the strcmp -> ~[0, 0] or [0, 0]
optimization there like get_base_address on the ADDR_EX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92765
--- Comment #6 from Jakub Jelinek ---
(In reply to Andrew Pinski from comment #3)
> But isn't the case magic could be considered a variable length field since
> it is st the end of the struct?
At end of struct or not doesn't really matter.
Consi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92765
--- Comment #5 from Jakub Jelinek ---
Note, determine_min_objsize calls compute_builtin_object_size with 2 rather
than 3, which means it is in this regard conservative and uses whole object
size rather than just subobject, we've been there in the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92765
--- Comment #4 from Richard Biener ---
(In reply to Jakub Jelinek from comment #2)
> I'd say the bug is in determine_min_objsize, which makes assumption that are
> simply not valid in GIMPLE after optimizations.
> Before fre3 we have:
> _2 = &p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92765
--- Comment #3 from Andrew Pinski ---
But isn't the case magic could be considered a variable length field since it
is st the end of the struct?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92765
--- Comment #2 from Jakub Jelinek ---
I'd say the bug is in determine_min_objsize, which makes assumption that are
simply not valid in GIMPLE after optimizations.
Before fre3 we have:
_2 = &ptr.0_1->header.magic;
_3 = __builtin_strcmp (_2, "x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92765
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92765
Martin Liška changed:
What|Removed |Added
Priority|P3 |P1
Status|UNCONFIRMED
24 matches
Mail list logo
