https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86259
--- Comment #35 from Bernd Edlinger ---
at least gcc 9 has been fixed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86259
Jakub Jelinek changed:
What|Removed |Added
Target Milestone|8.3 |8.4
--- Comment #34 from Jakub Jelinek
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86259
--- Comment #33 from Martin Sebor ---
The following patch relaxes the optimization and handles the test suite
fallout:
https://gcc.gnu.org/ml/gcc-patches/2018-10/msg00129.html
It just needs to be rebased on top of the current trunk and some
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86259
Richard Biener changed:
What|Removed |Added
Status|REOPENED|ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86259
Jakub Jelinek changed:
What|Removed |Added
Target Milestone|8.2 |8.3
--- Comment #31 from Jakub Jelinek
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86259
--- Comment #30 from Martin Sebor ---
(In reply to Bernd Edlinger from comment #28)
>
> Can someone explain why the example in comment #21 works when
> pointer arithmentic instead of integer arithmetic is used?
Because the optimization (making
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86259
--- Comment #29 from Martin Sebor ---
(In reply to rguent...@suse.de from comment #25)
>
> Istr the proposal suggests a -fno-provenance option. How would we handle
> these cases with that?
The proposal is still being discussed and it's not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86259
--- Comment #28 from Bernd Edlinger ---
(In reply to Davin McCall from comment #27)
> Again, there was no pointer arithmetic (other than the line containing
> 'strlen', but that particular case the pointer has the address of the union
> object,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86259
--- Comment #27 from Davin McCall ---
(In reply to Martin Sebor from comment #24)
> The code in example #21 has the same bug:
> [...]
... due to provenance, you are claiming, if I understand correctly. But I don't
see anything in the current
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86259
Bernd Edlinger changed:
What|Removed |Added
CC||bernd.edlinger at hotmail dot
de
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86259
--- Comment #25 from rguenther at suse dot de ---
On July 14, 2018 2:26:06 AM GMT+02:00, "msebor at gcc dot gnu.org"
wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86259
>
>--- Comment #24 from Martin Sebor ---
>The code in example #21
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86259
--- Comment #24 from Martin Sebor ---
The code in example #21 has the same bug:
union U u;
u.s = (struct S){0, 0, 0};
char *bp = u.s.b; // <<< bp points to u.s.b
uintptr_t sp_ip = (uintptr_t)bp - offsetof(struct S,b); //
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86259
--- Comment #23 from Davin McCall ---
(In reply to Martin Sebor from comment #22)
> The test cases in this report are variations on this theme. [...]
Ok, except that the one I posted in comment #21 specifically copies the string
into a union
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86259
--- Comment #22 from Martin Sebor ---
In areas where the authors of the proposal find the standard open to
interpretation and when they feel it doesn't contradict the surveyed
implementation practice they tend to suggest to tighten the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86259
--- Comment #21 from Davin McCall ---
Looking at this further, the proposal actually states, for the address-of
operator:
> When the operand designates an object, the result has the single provenance
> of the outermost object containing that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86259
--- Comment #20 from Davin McCall ---
(In reply to Davin McCall from comment #19)
> [...] If the result of offsetof has no provenance even the long form won't
> work.
"no provenance" meaning "empty provenance", and of course this is not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86259
Davin McCall changed:
What|Removed |Added
CC||davmac at davmac dot org
--- Comment #19
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86259
--- Comment #18 from Martin Sebor ---
> Similarly for (char *) conversions as performed by str* calls,
> 6.3.2.3/7 applies which says "When a pointer to _an object_ is
> converted to a pointer to a character type, the result points
> to the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86259
--- Comment #17 from Martin Sebor ---
> Let's give the struct a name and introduce some casts
>
> typedef struct { int a; int b; } S;
> S s, s2;
> memcpy ((S*), (S*), sizeof(s));
>
> The standard makes it valid to convert to S* and makes it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86259
--- Comment #16 from rguenther at suse dot de ---
On Mon, 25 Jun 2018, glisse at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86259
>
> --- Comment #15 from Marc Glisse ---
> (In reply to Martin Sebor from comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86259
--- Comment #15 from Marc Glisse ---
(In reply to Martin Sebor from comment #14)
> > You say that
> >
> > struct { int a; int b; } s, s2;
> > memcpy (, , sizeof (s));
> >
> > is invalid, aka not copying the whole structure since you pass in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86259
--- Comment #14 from Martin Sebor ---
> You say that
>
> struct { int a; int b; } s, s2;
> memcpy (, , sizeof (s));
>
> is invalid, aka not copying the whole structure since you pass in a
> pointer to s2.a rather than s2?
Yes. It's invalid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86259
--- Comment #13 from joseph at codesourcery dot com ---
Well, C90 TC1 adds (to the informative Annex listing undefined behavior)
the case of array subscripts being out of range even if they wouldn't be
simply based on the top-level object,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86259
--- Comment #12 from Richard Biener ---
Btw, GCC still claims to support C89, so please cite appropriate C89 wording.
To GCC internals while a direct access like
a.b.c[i].d
has to remain inside bounds the variant via a pointer
p = [i].d;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86259
Richard Biener changed:
What|Removed |Added
Status|RESOLVED|REOPENED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86259
--- Comment #10 from Martin Sebor ---
(to complete the sentence from comment #9)
There is a separate question of whether strings (as in arguments to string
functions like strlen) extend to arbitrary sequences of bytes regardless of the
object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86259
--- Comment #9 from Martin Sebor ---
There is an ongoing effort to clarify the provenance of pointers in C. A
recent proposal for such clarification is N2219:
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2219.htm
I don't see anything in the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86259
Martin Sebor changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86259
Richard Biener changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86259
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
Status|UNCONFIRMED
30 matches
Mail list logo
