https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85315
--- Comment #16 from Andrew Macleod ---
(In reply to Jakub Jelinek from comment #13)
> (In reply to Andrew Macleod from comment #12)
> > Maybe I'm a little dense.
> >
> > if we are presuming that
> > &x + (a + b)
> > implies a + b == 0, the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85315
--- Comment #15 from rguenther at suse dot de ---
On November 18, 2020 3:55:44 PM GMT+01:00, amacleod at redhat dot com
wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85315
>
>--- Comment #12 from Andrew Macleod ---
>Maybe I'm a little de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85315
--- Comment #14 from Martin Sebor ---
Andrew, we discussed the same idea for built-in functions at Couldron. For
instance, in:
void f (const char *s, int n)
{
char a[8];
memcpy (a, s, n); // n must be in [0, 8]
if (n < 0 ||
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85315
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85315
--- Comment #12 from Andrew Macleod ---
Maybe I'm a little dense.
if we are presuming that
&x + (a + b)
implies a + b == 0, then we also should assume that
&x + a implies a == 0
and if we can make those assumptions, then
&x + 1 is garb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85315
--- Comment #11 from Richard Biener ---
(In reply to Andrew Macleod from comment #10)
> OK, so whats the deal here. I can't really follow what the final request, or
> action is.
>
> Is there a conclusion on what needs to be done? if anything?
S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85315
Andrew Macleod changed:
What|Removed |Added
CC||amacleod at redhat dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85315
--- Comment #9 from Martin Sebor ---
(In reply to rguent...@suse.de from comment #8)
> > I asked Peter about that yesterday. The access to *p in your example is
> > still
> > meant to be undefined even under the proposed provenance rules. Here
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85315
--- Comment #8 from rguenther at suse dot de ---
On Wed, 11 Apr 2018, msebor at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85315
>
> --- Comment #7 from Martin Sebor ---
> I asked Peter about that yesterday. The acc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85315
--- Comment #7 from Martin Sebor ---
I asked Peter about that yesterday. The access to *p in your example is still
meant to be undefined even under the proposed provenance rules. Here's his
response: http://www.open-std.org/jtc1/sc22/wg14/15051
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85315
--- Comment #6 from rguenther at suse dot de ---
On Tue, 10 Apr 2018, msebor at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85315
>
> --- Comment #5 from Martin Sebor ---
> (In reply to rguent...@suse.de from comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85315
--- Comment #5 from Martin Sebor ---
(In reply to rguent...@suse.de from comment #4)
...
> If you eventually expect a true result then please no - this should be
> undefined.
The second test case in comment #4 is currently well-defined in C17 (b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85315
--- Comment #4 from rguenther at suse dot de ---
On April 10, 2018 4:50:49 PM GMT+02:00, "msebor at gcc dot gnu.org"
wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85315
>
>Martin Sebor changed:
>
> What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85315
Martin Sebor changed:
What|Removed |Added
CC||msebor at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85315
--- Comment #2 from Jakub Jelinek ---
Note for
int x;
...
*(&x + (a + b))
if x is common we need to take -funconstrained-commons into account, similarly
for vars that end with flexible array members or similar arrays.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85315
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
16 matches
Mail list logo
