https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63645
--- Comment #1 from M Welinder ---
Created attachment 33810
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33810&action=edit
Preprocessed version of the program
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63645
--- Comment #2 from Andrew Pinski ---
I think this code violates C/C++ aliasing rules.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63645
--- Comment #3 from M Welinder ---
Why do you think so?
I think it is covered by this:
6.5 Expressions
[...]
[#7] An object shall have its stored value accessed only by
an lvalue expression that has one of the following types:63
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63645
Markus Trippelsdorf changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63645
M Welinder changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|INVALID
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63645
--- Comment #6 from Andrew Pinski ---
This:
expr->oper == GNM_EXPR_OP_FUNCALL &&
expr->func.argc == 1
is being combined into:
D.2319_2 = BIT_FIELD_REF <*expr_1, 64, 0>;
D.2320_3 = D.2319_2 & 18446744069414584575;
D.2320_3 == 4294967
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63645
Markus Trippelsdorf changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63645
--- Comment #8 from M Welinder ---
> That is a different issue. You access expr->func.argc and expr->func.func
> in your if expression. And of course they are uninitialised.
No, I don't. You see, C has this feature for the && operator that i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63645
--- Comment #9 from Mikael Pettersson ---
Can you tweak the testcase into something that throws an actual runtime error
(by faulting or returning 1 from main or doing exit(1)) instead of relying on
valgrind (which I don't trust) to spot a/the pro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63645
--- Comment #10 from Mikael Pettersson ---
I now think the test case is invalid. There is special provision in the
standard for accessing "the wrong member" of a union, but the member has to be
a struct type which shares a prefix with the curren
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63645
M Welinder changed:
What|Removed |Added
Attachment #33809|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63645
--- Comment #12 from Markus Trippelsdorf ---
1) Your malloc is too small. It has to be sizeof (biggest member).
So you're invoking undefined behavior.
2) In the if statement, where you probe the different members, you
also invoke undefined behav
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63645
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63645
--- Comment #14 from M Welinder ---
> 1) Your malloc is too small. It has to be sizeof (biggest member).
> So you're invoking undefined behavior.
Can you produce a specific authoritative reference for that statement?
I.e., a reference to the sta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63645
--- Comment #15 from M Welinder ---
FYI, I filed a related bug for valgrind covering the problem with the
conditional jump being detected as undefined:
https://bugs.kde.org/show_bug.cgi?id=340392
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63645
--- Comment #16 from Markus Trippelsdorf ---
(In reply to M Welinder from comment #14)
> > 2) In the if statement, where you probe the different members, you
> > also invoke undefined behavior.
>
> Absolutely not! I went other that in painful d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63645
--- Comment #17 from M Welinder ---
You keep saying "undefined behaviour", but you keep avoiding
substantiating that claim.
Where, in the C99 standard, is the clause that makes things undefined?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63645
--- Comment #18 from M Welinder ---
The example at strict-aliasing in the gcc man page covers a different
situation: you don't get to access a double via an int.
I get it.
But the standard says that in certain circumstances you really do get
to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63645
--- Comment #19 from joseph at codesourcery dot com ---
Given
GnmExprBinary res;
GnmExpr const *expr = (GnmExpr *)&res;
the C standard does not define where the result of the conversion points;
all that's defined is that if converted direc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63645
--- Comment #20 from Jakub Jelinek ---
(In reply to jos...@codesourcery.com from comment #19)
> Given
>
> GnmExprBinary res;
> GnmExpr const *expr = (GnmExpr *)&res;
Let's consider if in #c11 you change:
GnmExprBinary *res = malloc (sizeo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63645
--- Comment #21 from Andreas Schwab ---
This is only valid if the object is of the union type (union _GnmExpr)
(ยง6.5.2.3#6: "if the union object currently contains one of these structures").
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63645
--- Comment #22 from M Welinder ---
>Given
>
> GnmExprBinary res;
> GnmExpr const *expr = (GnmExpr *)&res;
>
>the C standard does not define where the result of the conversion points;
How do you read C99's Section 6.5 #7, then?
Doesn't that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63645
--- Comment #23 from joseph at codesourcery dot com ---
On Mon, 27 Oct 2014, jakub at gcc dot gnu.org wrote:
> Let's consider if in #c11 you change:
> GnmExprBinary *res = malloc (sizeof (GnmExprBinary));
> res->oper = op;
> return (GnmExp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63645
--- Comment #24 from joseph at codesourcery dot com ---
On Mon, 27 Oct 2014, terra at gnome dot org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63645
>
> --- Comment #22 from M Welinder ---
> >Given
> >
> > GnmExprBinary res;
> > G
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63645
--- Comment #25 from Mikael Pettersson ---
So, is there a way to under-allocate a union (just allocate enough for the
member you want) and access it via the union pointer that is valid C?
25 matches
Mail list logo
