This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug target/63764] [5 Regression] ICE: in verify_ssa, at tree-ssa.c:939
- From: "joseph at codesourcery dot com" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Tue, 18 Nov 2014 15:34:10 +0000
- Subject: [Bug target/63764] [5 Regression] ICE: in verify_ssa, at tree-ssa.c:939
- Auto-submitted: auto-generated
- References: <bug-63764-4 at http dot gcc dot gnu dot org/bugzilla/>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63764
--- Comment #7 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
On Tue, 18 Nov 2014, jakub at gcc dot gnu.org wrote:
> does. The difference is when
> handling the (type) saijplus16 cast in build_c_cast.
> In the ppc case and fn3 case, the type is the same, so we end up with
> NON_LVALUE_EXPR of saijplus16. In the fn2 case with V typedef, the type is
> different (saijplus16 has V type, the cast uses its main variant), so we end up
> with VIEW_CONVERT_EXPR of saijplus16 instead. The VCE gets folded away, while
> NON_LVALUE_EXPR remains. But in all cases the casts aren't valid lvalue.
> Note, C++ ICEs on all the testcases.
> IMHO either we need to reject it (but how to find out in the case of
> build_c_cast that it originally was non-lvalue?), or we need to skip the
> NON_LVALUE_EXPRs when marking the var as addressable and taking address of it.
What folds away the VIEW_CONVERT_EXPR, when? c-typeck.c:lvalue_p does not
consider VIEW_CONVERT_EXPRs to be lvalues, and lvalue checks are meant to
happen before any folding that could change a non-lvalue to an lvalue.
Maybe build_array_ref needs to ensure that references to elements of
non-lvalue vectors don't become lvalues? (This would be different to
non-lvalue arrays arising from non-lvalue structs and unions, where the
result of an array reference *is* an lvalue but modifying it, or accessing
it after the next sequence point, has undefined behavior.)