Re: [RFC][PR87528][PR86677] Disable builtin popcount detection when back-end does not define it

Hi Richard and Jeff, Thanks for your comments. On Fri, 26 Oct 2018 at 19:40, Richard Biener wrote: > > On Fri, Oct 26, 2018 at 4:55 AM Jeff Law wrote: > > > > On 10/25/18 4:33 PM, Kugan Vivekanandarajah wrote: > > > Hi, > > > > > > PR87528 showed a case where libgcc generated popcount is

Re: [PATCH v3 3/3] or1k: gcc: initial support for openrisc

Hi! On Mon, Oct 29, 2018 at 06:47:23AM +0900, Stafford Horne wrote: > On Sat, Oct 27, 2018 at 09:57:30PM -0500, Segher Boessenkool wrote: > > > +/* Helper for defining INITIAL_ELIMINATION_OFFSET. > > > + We allow the following eliminiations: > > > + FP -> HARD_FP or SP > > > + AP ->

Re: [PATCH v3 3/3] or1k: gcc: initial support for openrisc

On 10/28/18 2:57 AM, Segher Boessenkool wrote: >> +(define_insn "xorsi3" >> + [(set (match_operand:SI 0 "register_operand" "=r,r") >> + (xor:SI >> + (match_operand:SI 1 "register_operand" "%r,r") >> + (match_operand:SI 2 "reg_or_s16_operand" " r,I")))] >> + "" >> + "@ >> +

Re: [PATCH v3 3/3] or1k: gcc: initial support for openrisc

Hi Segher, Thank you for the review and thank you for all the help up until now. On Sat, Oct 27, 2018 at 09:57:30PM -0500, Segher Boessenkool wrote: > Hi Stafford, > > Some minor comments. I didn't read the atomics much, but I did look at > everything else, and it looks fine :-) > > On Sat,

Re: Fix dg-prune-output regex for versioned namespace

On 10/25/18 1:16 PM, Jonathan Wakely wrote: On 24/10/18 21:30 +0200, François Dumont wrote: Some tests dg-prune-output regex need to be adapted to pass when versioned namespace is activated. I preferred to add the version namespace in the regex rather than removing namespace qualification.

Re: [PATCH] asm inline

On Sun, Oct 28, 2018 at 01:32:09PM -0400, Eric Gallager wrote: > Since this is touching c_parser_asm_statement() it seems relevant to > bug 55681; could you check to see how it interacts with some of the > cases listed in that bug? > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55681 I wasn't

C++ PATCH to Implement P0846R0, ADL and function templates

This patch implements P0846R0: ADL and Function Templates that are not Visible whereby a name for which a normal lookup produces either no result or finds one or more functions and that is followed by a "<" would be treated as

Re: Is the D frontend good to go? (was Re: [PATCH 02/14] Add D frontend (GDC) implementation.)

On Fri, 26 Oct 2018 at 11:02, Richard Biener wrote: > > On Thu, Oct 25, 2018 at 4:13 PM Iain Buclaw wrote: > > > > On Thu, 25 Oct 2018 at 15:06, David Malcolm wrote: > > > > > > On Tue, 2018-10-23 at 19:21 +0200, Iain Buclaw wrote: > > > > On Tue, 23 Oct 2018 at 15:48, Richard Sandiford > > > >

Re: [PATCH] asm inline

On 10/12/18, Segher Boessenkool wrote: > The Linux kernel people want a feature that makes GCC pretend some > inline assembler code is tiny (while it would think it is huge), so > that such code will be inlined essentially always instead of > essentially never. > > This patch lets you say "asm

[patch, doc, fortran] Document FINDLOC

Hi, here is the promised documentation for FINDLOC. Tested with "make dvi" and "make pdf". OK for trunk? Regards Thomas 2018-10-28 Thomas Koenig PR fortran/54613 * gfortran.texi (File format of unformatted sequential files): Replace random comma with

Re: [Patch, fortran] PR40196 - [F03] [F08] Type parameter inquiry (str%len, a%kind) and Complex parts (z%re, z%im)

Hi Paul, inq would be easier to understand and unambiguous imho. Why? inquiry_type seems fine to me. I think Bernhard means the name of the member, i. I think it makes sense to leave as it is - gfc_ref is a struct that occurs a lot in complicated expressions, and the other members are one

Re: [patch, fortran] Implement FINDLOC

Hi Paul, The patch is ready to go. Please correct the following tiny nits: I have corrected those. s/Check that en expression/Check that an expression/ s/Set this if resolution has already happened and it could be harmful/Set this if resolution has already happened. It could be harmful/

Re: [Patch, fortran] PR40196 - [F03] [F08] Type parameter inquiry (str%len, a%kind) and Complex parts (z%re, z%im)

Hi Bernhard, Thanks for going through the patch: snip > missing space before open parenthesis Corrected. snip > inq would be easier to understand and unambiguous imho. Why? inquiry_type seems fine to me. snip > Is the switch really worth it? I'd have used a plain chain

Re: [Patch, fortran] PR40196 - [F03] [F08] Type parameter inquiry (str%len, a%kind) and Complex parts (z%re, z%im)

On Sat, 27 Oct 2018 20:03:47 +0100 Paul Richard Thomas wrote: A few nits. > + /* Pull an inquiry result out of an expression. */ > + > + static bool > + find_inquiry_ref (gfc_expr *p, gfc_expr **newp) > + { > + gfc_ref *ref; > + gfc_ref *inquiry = NULL; > + gfc_expr *tmp; > + > + tmp

Re: [patch, fortran] Implement FINDLOC

Hi Thomas, The patch is ready to go. Please correct the following tiny nits: s/Check that en expression/Check that an expression/ s/Set this if resolution has already happened and it could be harmful/Set this if resolution has already happened. It could be harmful/ An even tinier, probably