> On Aug 2, 2017, at 6:43 PM, Segher Boessenkool <seg...@kernel.crashing.org>
> wrote:
>
> Hi Bill,
>
> On Wed, Aug 02, 2017 at 10:29:20AM -0500, Bill Schmidt wrote:
>> I don't anticipate backporting any of this.
>
> Good :-)
>
>> @@ -6802,7 +6802,7 @@ altivec_resolve_overloaded_builtin (location_t loc
>> if (unsupported_builtin)
>> {
>> const char *name = rs6000_overloaded_builtin_name (fcode);
>> - error ("Builtin function %s not supported in this compiler
>> configuration",
>> + error ("builtin function %s not supported in this compiler
>> configuration",
>> name);
>
> As Martin says, %qs for this and similar (see the documentation before
> pp_format in pretty-print.c). Can be a separate patch of course, this
> one is big enough already.
>
>> Index: gcc/config/rs6000/rs6000.c
>> ===================================================================
>> --- gcc/config/rs6000/rs6000.c (revision 250791)
>> +++ gcc/config/rs6000/rs6000.c (working copy)
>> @@ -4132,7 +4132,7 @@ rs6000_option_override_internal (bool global_init_
>> || rs6000_cpu == PROCESSOR_PPCE5500)
>> {
>> if (TARGET_ALTIVEC)
>> - error ("AltiVec not supported in this target");
>> + error ("altivec not supported in this target");
>> }
>>
>> /* If we are optimizing big endian systems for space, use the load/store
>
> Let's either keep AltiVec or say -maltivec. We only have this warning
> because we allow -maltivec with CPUs that do not support it; and this
> warning is only for some of the FSL CPUs. It isn't very consistent.
Back to AltiVec it goes! Thanks.
>
>> @@ -4250,7 +4250,7 @@ rs6000_option_override_internal (bool global_init_
>> rs6000_isa_flags |= (ISA_3_0_MASKS_SERVER & ~ignore_masks);
>> }
>> else
>> - error ("Power9 target option is incompatible with -mcpu=<xxx> for "
>> + error ("power9 target option is incompatible with -mcpu=<xxx> for "
>> "<xxx> less than power9");
>> }
>> else if ((ISA_3_0_MASKS_SERVER & rs6000_isa_flags_explicit)
>
> See also PR79477. Since many of these options are going away it is
> probably not worth spending too much time on this, not until stage 3
> or so anyway.
Yeah, let's address that later in the year after Mike finishes his cleanups.
>
>> @@ -11226,7 +11226,7 @@ rs6000_return_in_memory (const_tree type, const_tr
>> static bool warned_for_return_big_vectors = false;
>> if (!warned_for_return_big_vectors)
>> {
>> - warning (OPT_Wpsabi, "GCC vector returned by reference: "
>> + warning (OPT_Wpsabi, "gcc vector returned by reference: "
>> "non-standard ABI extension with no compatibility
>> guarantee");
>> warned_for_return_big_vectors = true;
>> }
>
> Maybe the warning should just say "big vector"? Or "generic vector"?
>
> (Vectors that fit in one VR, or in GPRs in 8 bytes or less, do not have
> the problem this warns for. Kind of hard to express tersely and
> precisely though).
I looked in the GCC manual and couldn't find a better way of expressing
this than just "GCC vector," so I will return it to the way it was. "GCC
vector extension vector" is accurate but hardly trips lightly off the
tongue...
>
> Approved for trunk with whichever of the suggested changes you think
> are good. Thanks,
Thanks much!
Bill
>
>
> Segher
>
