On Tue, Aug 04, 2015 at 09:58:37AM +0100, Kyrill Tkachov wrote:
>
> On 04/08/15 09:53, James Greenhalgh wrote:
> > On Mon, Aug 03, 2015 at 04:20:13PM +0100, Kyrill Tkachov wrote:
> >> Ok, I've removed usages of 'ret' in favor of returning when appropriate.
> >> In this last one I left the ret (but cleaned up the control flow a bit)
> >> because if the processing fails we need to clean up a bit of state before
> >> returning.
> > This is OK with the changes below fixed, or commented on as justification.
> >
> >> diff --git a/gcc/config/aarch64/aarch64-protos.h
> >> b/gcc/config/aarch64/aarch64-protos.h
> >> index fc1cec7..3a5482d 100644
> >> --- a/gcc/config/aarch64/aarch64-protos.h
> >> +++ b/gcc/config/aarch64/aarch64-protos.h
> >> @@ -376,6 +378,8 @@ extern bool aarch64_madd_needs_nop (rtx_insn *);
> >> extern void aarch64_final_prescan_insn (rtx_insn *);
> >> extern bool
> >> aarch64_expand_vec_perm_const (rtx target, rtx op0, rtx op1, rtx sel);
> >> +bool aarch64_handle_option (struct gcc_options *, struct gcc_options *,
> >> + const struct cl_decoded_option *, location_t);
> > Please try to keep this file in alphabetical order, first by return type,
> > then by function name.
>
> Ok, will do.
>
> >
> >> void aarch64_atomic_assign_expand_fenv (tree *, tree *, tree *);
> >> int aarch64_ccmp_mode_to_code (enum machine_mode mode);
> >>
> >> diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
> >> index d0d62e7..7a369fd 100644
> >> --- a/gcc/config/aarch64/aarch64.c
> >> +++ b/gcc/config/aarch64/aarch64.c
> >> +static bool
> >> +aarch64_handle_attr_arch (const char *str, const char *pragma_or_attr)
> >> +{
> >> + const struct processor *tmp_arch = NULL;
> >> + enum aarch64_parse_opt_result parse_res
> >> + = aarch64_parse_arch (str, &tmp_arch, &aarch64_isa_flags);
> >> +
> >> + if (parse_res == AARCH64_PARSE_OK)
> >> + {
> >> + gcc_assert (tmp_arch);
> >> + selected_arch = tmp_arch;
> >> + explicit_arch = selected_arch->arch;
> >> + return true;
> >> + }
> > Why not pull this in to the switch case below?
>
> I chose to keep the success case separate from error handling and reporting
> as it made it
> easier to find it (and it is the more interesting case in these functions). I
> can add a comment
> to that effect there if you'd like.
I thought that might be it. It looks unusual to me, but I don't have
strong feelings against it, so I'm happy for you to leave it as is if
that is your preference.
Thanks,
James
