On Wed, Nov 02, 2016 at 12:39:08PM +0530, Prathamesh Kulkarni wrote:
> On 1 November 2016 at 23:41, Uros Bizjak <ubiz...@gmail.com> wrote:
> > On Tue, Nov 1, 2016 at 5:05 PM, Jakub Jelinek <ja...@redhat.com> wrote:
> >> On Tue, Nov 01, 2016 at 10:05:22AM +0100, Uros Bizjak wrote:
> >>> ... simplify some conditions and add i?86-*-* target where missing.
> >>>
> >>> 2016-11-01 Uros Bizjak <ubiz...@gmail.com>
> >>>
> >>> * lib/target-supports.exp: Normalize order of i?86 and x86_64 targets.
> >>> Whitespace fixes.
> >> ...
> >>> (check_effective_target_divmod): Add i?86-*-* target.
> >>
> >> This part likely broke
> >> +FAIL: gcc.dg/divmod-1.c scan-tree-dump-times widening_mul "DIVMOD" 7
> >> +FAIL: gcc.dg/divmod-2.c scan-tree-dump-times widening_mul "DIVMOD" 7
> >> +FAIL: gcc.dg/divmod-3.c scan-tree-dump-times widening_mul "DIVMOD" 7
> >> +FAIL: gcc.dg/divmod-4.c scan-tree-dump-times widening_mul "DIVMOD" 7
> >> +FAIL: gcc.dg/divmod-6.c scan-tree-dump-times widening_mul "DIVMOD" 7
> >> on i686-linux (i.e. 32-bit).
> >
> > No, this is expected (these tests already fail with x86_64 -m32
> > multilib). These will be fixed by [1].
> Oops, sorry for the breakage.
> The tests are meant to check if the divmod transform triggered, which
> is done by scanning
> DIVMOD in the widening_mul dump.
>
> Apparently I only checked for the triplet "x86_64-*-*" in
> check_effective_target_divmod()
> and it returned 1, which probably caused the divmod DImode tests to
> fail with -m32.
>
> In general, could I check in check_effective_target_*(), what options
> are passed ?
On some targets, yes. E.g. on i?86-*-*/x86_64-*-*, one can additionally
test lp64 or ia32 or negation thereof - there are -m32, -mx32 and -m64
modes, -m64 satisfies lp64, -m32 ia32.
Though the predicate seems to be misnamed and not properly documented
if it is about properties of DImode divmod rather than other modes
(SImode, HImode, QImode, TImode, ...).
Jakub
