This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH][LTO,ARM] Fix vector TYPE_MODE in streaming-out
- From: Bernd Schmidt <bschmidt at redhat dot com>
- To: Christian Bruel <christian dot bruel at st dot com>, gcc-patches at gcc dot gnu dot org
- Date: Tue, 15 Dec 2015 17:14:12 +0100
- Subject: Re: [PATCH][LTO,ARM] Fix vector TYPE_MODE in streaming-out
- Authentication-results: sourceware.org; auth=none
- References: <56702D44 dot 1010103 at st dot com>
On 12/15/2015 04:09 PM, Christian Bruel wrote:
in "normal" mode, the TYPE_MODE for vector_type __simd64_int8_t is set
to V8QImode by arm_vector_mode_supported_p during the builtins type
initializations, thanks to TARGET_NEON set bu the global flag.
Now, in LTO mode the streamer writes the information for this
vector_type as a scalar DImode, causing ICEs during arm_expand_builtin.
The root cause of this is that the streamer-out uses TYPE_MODE in a
context where the target_flags are not known return false for TARGET_NEON.
The streamer-in then will then read the wrong mode that propagates to
the back-end.
static void
pack_ts_type_common_value_fields (struct bitpack_d *bp, tree expr)
{
- bp_pack_machine_mode (bp, TYPE_MODE (expr));
+ bp_pack_machine_mode (bp, expr->type_common.mode);
This looks sensible given that tree-streamer-in uses SET_TYPE_MODE,
which just writes expr->type_common.mode.
Make a new macro TYPE_MODE_RAW for this and I think the patch is ok
(although there's precedent for direct access in vector_type_mode, but I
think that's just bad).
Bernd