RE: [PATCH] Fix various x86 avx512{bitalg,vpopcntdq,vbmi2} issues (PR target/83488)

2017-12-25 Thread Koval, Julia
Thank you very much for fixing those issues. Note, __builtin_ia32_vpshufbitqmb{128,256,512}_mask are implemented > incorrectly, can somebody from Intel handle that? The inlines in the > intrinsic header look correct, but the builtins aren't and what's even worse > is that the define_insns are wro

Re: [patch, lingfortran] Bug 83560 - list-directed formatting of INTEGER is missing plus on output

2017-12-25 Thread Thomas Koenig
Hi Jerry, OK for trunk? OK. Thanks for the patch. And: Merry Christmas to everybody! Thomas

Re: [patch, lingfortran] Bug 83560 - list-directed formatting of INTEGER is missing plus on output

2017-12-25 Thread Dominique d'Humières
Dear Jerry, The lines +a=12.3456 and +open(unit=10,sign='plus') in gfortran.dg/integer_plus.f90 could probably be removed. >From comment 2 in the PR (and the attached test), it seems that the reporter >is expecting sign=‘plus’ to apply also to namelists, which is not the case >with this pat

[PATCH] sel-sched: fix zero-usefulness case in sel_rank_for_schedule (PR 83513)

2017-12-25 Thread Alexander Monakov
Hello, we need the following follow-up fix for priority comparison in sel_rank_for_schedule as demonstrated by PR 83513. Checked on x86_64 by running a bootstrap and also checking for no regressions in make -k check-gcc RUNTESTFLAGS="--target_board=unix/-fselective-scheduling/-fschedule-insns"

[PATCH] PR Fortran/83548 -- a LOGICAL fix

2017-12-25 Thread Steve Kargl
The attach patch fixes a problem when a LOGICAL subprogram appears as the first element in an array constructor, which is interpreted as a LOGICAL type-spec, which fails because the argument is of type LOGICAL instead of INTEGER. Regression tested on i686-*-freebsd and x86_64-*-freebsd. OK to com

Re: [patch, lingfortran] Bug 83560 - list-directed formatting of INTEGER is missing plus on output

2017-12-25 Thread Jerry DeLisle
On 12/25/2017 05:10 AM, Dominique d'Humières wrote: > Dear Jerry, > > The lines > > +a=12.3456 > > and > > +open(unit=10,sign='plus') > > in gfortran.dg/integer_plus.f90 could probably be removed. > Yes, left over from some other testing I was doing > From comment 2 in the PR (and the attach

[v3 PATCH] Make optional conditionally trivially_{copy,move}_{constructible,assignable}

2017-12-25 Thread Ville Voutilainen
In the midst of the holiday season, the king and ruler of all elves, otherwise known as The Elf, was told by little elves that users are complaining how stlstl and libc++ make optional's copy and move operations conditionally trivial, but libstdc++ doesn't. This made The Elf fairly angry, and he sp

Re: [PATCH] PR Fortran/83548 -- a LOGICAL fix

2017-12-25 Thread Bernhard Reutner-Fischer
On 25 December 2017 20:45:40 CET, Steve Kargl wrote: >The attach patch fixes a problem when a LOGICAL subprogram >appears as the first element in an array constructor, which >is interpreted as a LOGICAL type-spec, which fails because >the argument is of type LOGICAL instead of INTEGER. > >Regress

Re: [PATCH] PR Fortran/83548 -- a LOGICAL fix

2017-12-25 Thread Steve Kargl
On Mon, Dec 25, 2017 at 11:12:49PM +0100, Bernhard Reutner-Fischer wrote: > On 25 December 2017 20:45:40 CET, Steve Kargl > wrote: > >The attach patch fixes a problem when a LOGICAL subprogram > >appears as the first element in an array constructor, which > >is interpreted as a LOGICAL type-spec,

Re: [PATCH] Add LVAL argument to c_fully_fold* and propagate it through (PR c/66618, PR c/69960)

2017-12-25 Thread Tom de Vries
On 11/09/2017 11:54 AM, Jakub Jelinek wrote: On Wed, Nov 08, 2017 at 06:57:55PM +0100, Jakub Jelinek wrote: On Wed, Nov 08, 2017 at 06:51:34PM +0100, Marek Polacek wrote: Ok, so like this if it passes bootstrap/regtest? Changes from the last patch: 1) false instead of lval for COMPOUND_EXPR an