Re: Fix ALL_REGS thinko in initialisation of function_used_regs

2019-10-03 Thread Paul Koning



> On Oct 3, 2019, at 9:12 AM, Richard Earnshaw (lists) 
>  wrote:
> 
> On 03/10/2019 10:48, Segher Boessenkool wrote:
>>> ...
>> But ALL_REGS should contain *all* registers.  The union of any two register
>> classes has to be contained in some register class, so every register class
>> has to be contained in ALL_REGS.
>> Segher
> 
> Why would anyone want a to form a union of one class with a class that can't 
> be used for allocation.  That's just silly.

Yes, if that's the only purpose of register classes.

If the documentation doesn't match what the real intent is, and some developers 
apparently use the intent while others use the documentation.  The result is 
bugs like the one we're talking about here.  

It may well make sense to say that ALL_REGS should be the set of all 
*allocatable* registers.  If that's what we want, the documentation should say 
so, and then the code has to understand that some registers (like CC_REG) may 
be outside ALL_REGS.  Similarly, NO_REGS is currently documented as "no 
registers" (empty set).  If it is intended that it might contain 
non-allocatable registers, again the documentation should say so.

paul



Re: [PATCH] regrename: Use PC instead of CC0 to hide operands

2019-10-01 Thread Paul Koning
On Oct 1, 2019, at 5:14 AM, Segher Boessenkool  
wrote:
> 
> The regrename pass temporarily changes some operand RTL to CC0 so that
> note_stores and scan_rtx don't see those operands.  CC0 is deprecated
> and we want to remove it, so we need to use something else here.
> PC fits the bill fine.

CC0 is, presumably, not part of GENERAL_REGS, but PC is, in some ports.  Does 
that cause a problem here? 

paul



Re: Problem exposed by recent ARM multiply changes

2019-09-26 Thread Paul Koning



> On Sep 26, 2019, at 12:01 PM, Jeff Law  wrote:
> 
> On 9/26/19 9:47 AM, Jakub Jelinek wrote:
>> On Thu, Sep 26, 2019 at 09:39:31AM -0600, Jeff Law wrote:
>>> Right.  My point is that the multiplication patterns are an exception as
>>> well.
>> 
>> Do you have some evidence for that? 
> It's in the manual.  And yes it potentially makes a huge mess due to the
> interactions with modeless CONST_INTs.

Do you mean things like "mulhisi3"?

That's a pattern for a multiplication whose output is longer than its inputs.  
But the RTL it builds has a regular mult insn with equal length operands (all 
SImode in this example), with sign_extend insns in the mult source operands.  
So I don't believe that contradicts what Jakub said.

paul



Re: Deprecating cc0 (and consequently cc0 targets)

2019-09-21 Thread Paul Koning



> On Sep 20, 2019, at 1:45 PM, Jeff Law  wrote:
> 
> On 9/20/19 11:22 AM, Richard Biener wrote:
>> ...
>> It seems to be that for the goal to keep a target alive a variant #2
>> conversion (according to the wiki) should be closely mirror CC0
>> behavior and thus should be easier to achieve and with less patterns
>> touched than the 'good' variant. Can you acknowledge that and would
>> such 'simple' conversions be OK?
> Unless the target has condition code preserving arithmetic a variant #2
> conversion is the only way to go.

Yes.

> Now if someone did a variant #2 without the optimization bits (ie,
> adding appropriate _set_flags pattern variants), I think that should be
> considered explicitly OK even though the code quality would potentially
> suffer.  Essentially it's a choice between dropping the port or keeping
> the port, but with slightly less optimization.  THe latter seems like a
> better choice to me.

True.  Then again, the added work of creating the pattern pairs is modest.  
With define_subst, much of the work can be automated.

For pdp11, I found this to be the case; the hard part was to learn what is 
needed, and for that the Wiki ends up a big help.  Also, pdp11 is harder than 
most because it has two CC registers (one for float ops, one for the rest).  I 
don't know all the others, but for example VAX only has one, and I'm pretty 
sure the same applies to m68k.

paul




Re: syncing the GCC vax port, atomic issue

2019-09-21 Thread Paul Koning



> On Sep 20, 2019, at 9:18 PM, co...@sdf.org wrote:
> 
> On Fri, Sep 20, 2019 at 10:07:59PM +, co...@sdf.org wrote:
>> Introducing the reversed jbb* patterns doesn't seem to help with the
>> original issue. It crashes building libatomic.
> 
> My loose understanding of what is going on:
> - GCC emits this atomic in expand.
> - When cleaning up, it looks for optimizations.
> - It decides this is a branch to another branch situation, so maybe
>  can be improved.
> - This fails to output an instruction for unrelated reasons.
> - Hit an assert.
> 
> I don't think that we should be trying to combine regular branch +
> atomic branch in very generic code.
> My guess is that, if it didn't crash now, it might emit a different kind
> of branch which loses the atomic qualities, and result in wrong code.

Or it might leave the atomic branch, in a place where it isn't really wanted.

I wonder if this could be avoided by representing the atomic branch by an 
UNSPEC rather than by a branch, since it isn't a "normal branch" that GCC knows 
about.

paul



Re: Proposal for the transition timetable for the move to GIT

2019-09-19 Thread Paul Koning



> On Sep 17, 2019, at 8:02 AM, Richard Earnshaw (lists) 
>  wrote:
> 
> ...
> So in summary my proposed timetable would be:
> 
> Monday 16th December 2019 - cut off date for picking which git conversion to 
> use
> 
> Tuesday 31st December 2019 - SVN repo becomes read-only at end of stage 3.
> 
> Thursday 2nd January 2020 - (ie read-only + 2 days) new git repo comes on 
> line for live commits.

That sounds ok but it feels incomplete; there are additional steps and dates 
needed leading up to the 16th December decision point.

I would suggest: 1 December 2019: final version of each proposed conversion 
tool is available, trial conversion repository of the full GCC SVN repository 
is posted for public examination.

That allows 2 weeks for the different tools and their output to get the 
scrutiny needed for the picking decision to be made.  2 weeks may be more than 
needed (or possibly, less), but in any case I think this piece needs to be 
called out.

paul



Re: [PATCH][ARM] Correctly set SLOW_BYTE_ACCESS

2019-09-11 Thread Paul Koning



> On Sep 11, 2019, at 11:48 AM, Wilco Dijkstra  wrote:
> 
> Contrary to all documentation, SLOW_BYTE_ACCESS simply means accessing
> bitfields by their declared type, which results in better codegeneration
> on practically any target.  So set it correctly to 1 on Arm.

If the documentation is indeed wrong, could you submit a patch to cure that 
documentation defect?

paul



Re: asking for __attribute__((aligned()) clarification

2019-08-21 Thread Paul Koning



> On Aug 21, 2019, at 10:57 AM, Alexander Monakov  wrote:
> 
> On Wed, 21 Aug 2019, Paul Koning wrote:
> 
>> I agree, but if the new approach generates a warning for code that was 
>> written
>> to the old rules, that would be unfortunate.
> 
> FWIW I don't know which GCC versions accepted 'packed' on a scalar type.

That wasn't what I meant; I was talking about the packed and aligned attributes 
on struct members.  I thought you were saying that ((packed,aligned(2))) is now 
a warning.  That doesn't appear to be the case, though; it's accepted without 
complaint as it always was.

paul



Re: asking for __attribute__((aligned()) clarification

2019-08-21 Thread Paul Koning



> On Aug 21, 2019, at 10:28 AM, Alexander Monakov  wrote:
> 
> On Tue, 20 Aug 2019, "Markus Fröschle" wrote:
> 
>> Thank you (and others) for your answers. Now I'm just as smart as before, 
>> however.
>> 
>> Is it a supported, documented, 'long term' feature we can rely on or not?
>> 
>> If yes, I would expect it to be properly documented. If not, never mind.
> 
> I think it's properly documented in gcc-9:
> 
>  https://gcc.gnu.org/onlinedocs/gcc-9.2.0/gcc/Common-Type-Attributes.html
> 
> (the "old" behavior where the compiler would neither honor reduced alignment
> nor issue a warning seems questionable, the new documentation promises a more
> sensible approach)

I agree, but if the new approach generates a warning for code that was written 
to the old rules, that would be unfortunate.

> In portable code one can also use memcpy to move unaligned data, the compiler
> should translate it like an unaligned load/store when size is a suitable
> constant:
> 
>  int val;
>  memcpy(, ptr, sizeof val);
> 
> (or __builtin_memcpy when -ffreestanding is in effect)

Yes.  But last I tried, optimizing that for > 1 alignment is problematic 
because that information often doesn't make it down to the target code even 
though it is documented to do so.

paul



Re: asking for __attribute__((aligned()) clarification

2019-08-19 Thread Paul Koning



> On Aug 19, 2019, at 10:08 AM, Alexander Monakov  wrote:
> 
> On Mon, 19 Aug 2019, Richard Earnshaw (lists) wrote:
> 
>> Correct, but note that you can only pack structs and unions, not basic types.
>> there is no way of under-aligning a basic type except by wrapping it in a
>> struct.
> 
> I don't think that's true. In GCC-9 the doc for 'aligned' attribute has been
> significantly revised, and now ends with
> 
>  When used as part of a typedef, the aligned attribute can both increase and
>  decrease alignment, and specifying the packed attribute generates a warning. 
> 
> (but I'm sure defacto behavior of accepting and honoring reduced alignment on
> a typedef'ed scalar type goes way earlier than gcc-9)

Interesting.  It certainly wasn't that way a decade ago.  And for the old code 
pattern to generate a warning seems like a bad incompatible change.  Honoring 
reducing alignments is one thing, complaining about packed is not good.

paul



Re: asking for __attribute__((aligned()) clarification

2019-08-19 Thread Paul Koning



> On Aug 19, 2019, at 8:46 AM, Markus Fröschle  wrote:
> 
> All,
> 
> this is my first post on these lists, so please bear with me.
> 
> My question is about gcc's __attribute__((aligned()). Please consider the 
> following code:
> 
> #include 
> 
> typedef uint32_t uuint32_t __attribute__((aligned(1)));
> 
> uint32_t getuuint32(uint8_t p[]) {
>return *(uuint32_t*)p;
> }
> 
> This is meant to prevent gcc to produce hard faults/address errors on 
> architectures that do not support unaligned access to shorts/ints (e.g some 
> ARMs, some m68k). On these architectures, gcc is supposed to replace the 32 
> bit access with a series of 8 or 16 bit accesses.
> 
> I originally came from gcc 4.6.4 (yes, pretty old) where this did not work 
> and gcc does not respect the aligned(1) attribute for its code generation 
> (i.e. it generates a 'normal' pointer dereference, consequently crashing when 
> the code executes). To be fair, it is my understanding that the gcc manuals 
> never promised this *would* work.

That has never been my understanding.  I've always read the manual to say that 
"aligned" only INCREASES the alignment.  The normal alignment is that specified 
by the ABI for the given data type (often, but not always, the size of the 
primitive type) -- or it is 1 for "packed".

So I use __attribute__ ((packed)) to request byte alignment, and, say, 
__attribute__ ((packed, aligned(2))) to specify alignment to 2 byte multiples.

paul




Re: Indirect memory addresses vs. lra

2019-08-09 Thread Paul Koning



> On Aug 9, 2019, at 10:16 AM, Segher Boessenkool  
> wrote:
> 
> Hi!
> 
> On Fri, Aug 09, 2019 at 10:14:39AM +0200, John Darrington wrote:
>> On Thu, Aug 08, 2019 at 01:57:41PM -0600, Jeff Law wrote:
>> 
>>  ...  However I wonder if this issue is
>> related to the other major outstanding problem I have, viz: the large 
>> number of test failures which report "Unable to find a register to
>> spill" - So far, nobody has been able to explain how to solve that
>> issue and even the people who appear to be more knowlegeable have
>> expressed suprise that it is even happening at all.
> 
> No one is surprised.  It is just the funny way that LRA says "whoops I
> am going in circles, there is no progress and there will never be, I'd
> better stop that".  Everyone doing new ports / new conversions to LRA
> sees that error all the time.
> 
> The error could be pretty much *anywhere* in your port.  You have to
> look at what LRA did, and why, and why that is wrong, and fix that.

I've run into this a number of times.  The difficulty is that, for someone who 
understands the back end and the documented rules but not the internals of LRA, 
it tends to be hard to figure out what the problem is.  And since the causes 
tend to be obscure and undocumented, I find myself having to relearn the 
analysis from time to time. 

It has been stated that LRA is more dependent on correct back end definitions 
than Reload is, but unfortunately the precise definition of "correct" can be 
less than obvious to a back end maintainer.

paul




Re: Indirect memory addresses vs. lra

2019-08-08 Thread Paul Koning



> On Aug 8, 2019, at 1:21 PM, Segher Boessenkool  
> wrote:
> 
> On Thu, Aug 08, 2019 at 12:43:52PM -0400, Paul Koning wrote:
>>> On Aug 8, 2019, at 12:25 PM, Vladimir Makarov  wrote:
>>> The old reload (reload[1].c) supports such addressing.  As modern 
>>> mainstream architectures have no this kind of addressing, it was not 
>>> implemented in LRA.
>> 
>> Is LRA only intended for "modern mainstream architectures"?
> 
> I sure hope not!  But it has only been *used* and *tested* much on such,
> so far. 

That's not entirely accurate.  At the prodding of people pushing for the 
removal of CC0 and reload, I've added LRA support to pdp11 in the V9 cycle.  
And it works pretty well, in the sense of passing the compile tests.  But I 
haven't yet examined the code quality vs. the old one in any detail.

paul



Re: Indirect memory addresses vs. lra

2019-08-08 Thread Paul Koning



> On Aug 8, 2019, at 1:21 PM, Segher Boessenkool  
> wrote:
> 
> On Thu, Aug 08, 2019 at 12:43:52PM -0400, Paul Koning wrote:
>>> On Aug 8, 2019, at 12:25 PM, Vladimir Makarov  wrote:
>>> The old reload (reload[1].c) supports such addressing.  As modern 
>>> mainstream architectures have no this kind of addressing, it was not 
>>> implemented in LRA.
>> 
>> Is LRA only intended for "modern mainstream architectures"?
> 
> I sure hope not!  But it has only been *used* and *tested* much on such,
> so far.  Things are designed to work well for modern archs.
> 
>> If yes, why is the old reload being deprecated?  You can't have it both 
>> ways.  Unless you want to obsolete all "not modern mainstream architectures" 
>> in GCC, it doesn't make sense to get rid of core functionality used by those 
>> architectures.
>> 
>> Indirect addressing is a key feature in size-optimized code.
> 
> That doesn't mean that LRA has to support it, btw, not necessarily; it
> may well be possible to do a good job of this in the later passes?
> Maybe postreload, maybe some peepholes, etc.?

Possibly.  But as Vladimir points out, indirect addressing affects register 
allocation (reducing register pressure).  In older architectures that implement 
indirect addressing, that is one of the key ways in which the feature reduces 
code size.  While I can see how peephole optimization can convert a address 
load plus a register indirect into a memory indirect instruction, does that 
help the register become available for other uses or is post-LRA too late for 
that?  My impression is that it is too late, since at this point we're dealing 
with hard registers and making one free via peephole helps no one else.

paul




Re: Indirect memory addresses vs. lra

2019-08-08 Thread Paul Koning



> On Aug 8, 2019, at 12:25 PM, Vladimir Makarov  wrote:
> 
> 
> On 2019-08-04 3:18 p.m., John Darrington wrote:
>> I'm trying to write a back-end for an architecture (s12z - the ISA you can
>> download from [1]).  This arch accepts indirect memory addresses.   That is 
>> to
>> say, those of the form (mem (mem (...)))  and although my 
>> TARGET_LEGITIMATE_ADDRESS
>> function returns true for such addresses, LRA insists on reloading them out 
>> of
>> existence.
>> ...
> The old reload (reload[1].c) supports such addressing.  As modern mainstream 
> architectures have no this kind of addressing, it was not implemented in LRA.

Is LRA only intended for "modern mainstream architectures"?

If yes, why is the old reload being deprecated?  You can't have it both ways.  
Unless you want to obsolete all "not modern mainstream architectures" in GCC, 
it doesn't make sense to get rid of core functionality used by those 
architectures.

Indirect addressing is a key feature in size-optimized code.

paul



Re: [PATCH 21/30] Changes to pdp11

2019-06-27 Thread Paul Koning



> On Jun 25, 2019, at 4:22 PM, acsaw...@linux.ibm.com wrote:
> 
> From: Aaron Sawdey 
> 
>   * config/pdp11/pdp11.md (movmemhi, movmemhi1,
>   movmemhi_nocc, UNSPEC_MOVMEM): Change movmem to cpymem.

Ok, thanks.

paul




Re: [Contrib PATCH] Add scripts to convert GCC repo from SVN to Git

2019-05-15 Thread Paul Koning



> On May 15, 2019, at 2:42 PM, Eric Gallager  wrote:
> 
>> ...
> 
> Wasn't Eric S. Raymond working on his own conversion of the GCC repo
> from SVN to Git? Whatever happened to his?

Yes, and from what I recall he found that doing it fully correctly is an 
extremely hard task.  It might be a good idea to ask him to comment.

paul



Re: syncing the GCC vax port

2019-03-31 Thread Paul Koning



> On Mar 30, 2019, at 5:03 AM, co...@sdf.org wrote:
> 
> hi folks,
> 
> i was interesting in tackling some problems gcc netbsd/vax has.
> it has some ICEs which are in reload phase. searching around, the answer
> to that is "switch to LRA first". Now, I don't quite know what that is
> yet, but I know I need to try to do it.

That's not quite the whole story.

The answer is (1) switch from CC0 to CCmode condition code handling, which 
enables (2) switch from Reload to LRA.

(1) requires actual work, not terribly hard but not entirely trivial.  (2) may 
take as little as switching the "use LRA" flag to "yes".

I did (1) as well as a tentative (2) for pdp11 last year.  It was reasonably 
straightforward thanks to a pile of help from Eric Botcazou and his gcc wiki 
articles on the subject.  You might find the pdp11 deltas for CCmode helpful as 
a source of ideas, since the two machines have a fair amount in common as far 
as condition codes goes.  At least for the integer ops (pdp11 has separate 
floating point conditions, vax doesn't).

paul



Re: [PATCH] correct maximum valid alignment in error message (PR 89812)

2019-03-25 Thread Paul Koning



> On Mar 25, 2019, at 12:07 PM, Jeff Law  wrote:
> 
>> ...
>> 1) Does GCC support building with compilers where int is not 32
>>bits wide, or where BITS_PER_UNIT is not 3? (I.e., either is
>>less or more?)
> We've certainly supported 16 bit ints in the past.  H8/300 would be an
> example.  It defaults to 16 bit ints.  But I don't think we've tested
> that in a very long time -- my tester is only testing with -mint32.

pdp11 is set up the same way (16 bit int is the default, -mint32 supported).  I 
run most of my pdp11 tests (including gcc testsuite runs) with the default 16 
bit ints.  I haven't seen issues related to int size handing in the GCC core.

paul



Re: [PATCH] correct maximum valid alignment in error message (PR 89812)

2019-03-25 Thread Paul Koning



> On Mar 24, 2019, at 8:21 PM, Martin Sebor  wrote:
> 
> ...
> PS I have a couple of questions related to the affected code:
> 1) Does GCC support building with compilers where int is not 32
>   bits wide, or where BITS_PER_UNIT is not 3? (I.e., either is
>   less or more?)

Yes.  pdp11 int can be 16 bits (or 32 bits, if you say -mint32). 

> 2) Is there a supported target that doesn't have __INT64_TYPE__?
>   (And if so, how do I find it in a test?  I couldn't find
>   anythhing in target-supports.exp).

Maybe one of the tiny targets.  pdp11 does support int64.

paul




Re: Annoying silly warning emitted by gcc?

2019-01-23 Thread Paul Koning



> On Jan 23, 2019, at 7:15 PM, Warren D Smith  wrote:
> 
> x = x^x;
> 
> The purpose of the above is to load "x" with zero.
> For very wide types, say 256 bits wide, explicitly loading 0
> is deprecated by Intel since taking too much memory.
> XORing x with itself always yields 0 and is allegedly
> a better thing to do.
> 
> But the problem is, gcc complains:
> variable 'x' is uninitialized when used here [-Wuninitialized]
> note: initialize the variable 'x' to silence this warning
> 
> Well, the thing is, it DOES NOT MATTER that x is not initialized,
> or initialized with wrong data.  No matter what was in x, it becomes 0.
> 
> So, how to get Gcc to shut up and quit whining about this?
> I do not want to actually load 0.

The way to tell gcc that you don't want to hear about x being uninitialized is 
to write the declaration as an initialization to itself:

int x = x;
/* then you can do what you wanted: */
x = x ^ x;

But it seems that GCC should be able to tell expressions that do not depend on 
x and suppress the complaint about uninitialized x if so.

But furthermore: the "too much memory" argument makes no sense.  You should 
write what you mean in the plainest terms, in other words: "x = 0".  It is then 
up to the optimizer to generate the best code for it.  If xor is the better 
code that's what should come out.  Does it already?  If so, Intel's advice is 
simply wrong, ignore it and write the simple code.  If the compiler actually 
generates a transfer from a (potentially big) zero, that might be a missed 
optimization bug.  In that case, Intel's advice may possibly be useful as a 
temporary workaround for this bug.  But only if the small savings is so 
important that obfuscating your source code is justified.

   paul



Re: [RFC] Update Stage 4 description

2019-01-09 Thread Paul Koning



> On Jan 9, 2019, at 3:42 AM, Tom de Vries  wrote:
> 
> [ To revisit https://gcc.gnu.org/ml/gcc-patches/2018-04/msg00385.html ]
> 
> The current formulation for the description of Stage 4 here (
> https://gcc.gnu.org/develop.html ) is:
> ...
> During this period, the only (non-documentation) changes that may be
> made are changes that fix regressions.
> 
> Other changes may not be done during this period.
> 
> Note that the same constraints apply to release branches.
> 
> This period lasts until stage 1 opens for the next release.
> ...
> 
> This updated formulation was proposed by Richi (with a request for
> review of wording):
> ...
> During this period, the only (non-documentation) changes that may
> be made are changes that fix regressions.
> 
> -Other changes may not be done during this period.
> +Other important bugs like wrong-code, rejects-valid or build issues may
> +be fixed as well.  All changes during this period should be done with
> +extra care on not introducing new regressions - fixing bugs at all cost
> +is not wanted.
...

Is there, or should there be, a distinction between primary and non-primary 
platforms?  While platform bugs typically require fixes in platform-specific 
code, I would think we would want to stay away from bugfixes in minor platforms 
during stage 4.  The wording seems to say that I could fix wrong-code bugs in 
pdp11 during stage 4; I have been assuming I should not do that.  Is this 
something that should be explicitly stated?

paul



Re: [RFC] Update Stage 4 description

2019-01-09 Thread Paul Koning



> On Jan 9, 2019, at 3:42 AM, Tom de Vries  wrote:
> 
> [ To revisit https://gcc.gnu.org/ml/gcc-patches/2018-04/msg00385.html ]
> 
> The current formulation for the description of Stage 4 here (
> https://gcc.gnu.org/develop.html ) is:
> ...
> During this period, the only (non-documentation) changes that may be
> made are changes that fix regressions.
> 
> Other changes may not be done during this period.
> 
> Note that the same constraints apply to release branches.
> 
> This period lasts until stage 1 opens for the next release.
> ...
> 
> This updated formulation was proposed by Richi (with a request for
> review of wording):
> ...
> During this period, the only (non-documentation) changes that may
> be made are changes that fix regressions.
> 
> -Other changes may not be done during this period.
> +Other important bugs like wrong-code, rejects-valid or build issues may
> +be fixed as well.  All changes during this period should be done with
> +extra care on not introducing new regressions - fixing bugs at all cost
> +is not wanted.
...

Is there, or should there be, a distinction between primary and non-primary 
platforms?  While platform bugs typically require fixes in platform-specific 
code, I would think we would want to stay away from bugfixes in minor platforms 
during stage 4.  The wording seems to say that I could fix wrong-code bugs in 
pdp11 during stage 4; I have been assuming I should not do that.  Is this 
something that should be explicitly stated?

paul



Re: [PATCH v4][C][ADA] use function descriptors instead of trampolines in C

2018-12-18 Thread Paul Koning



> On Dec 17, 2018, at 2:23 PM, Szabolcs Nagy  wrote:
> 
> On 17/12/2018 18:22, Uecker, Martin wrote:
>>> 
>>> ...
>> 
>> So a thread_local static variable for storing the static
>> chain?
> 
> something like that, but the more i think about it the
> harder it seems: the call site of the nested function
> may not be under control of the nested function writer,
> in particular the nested function may be called on a
> different thread, and extern library apis are unlikely
> to provide guarantees about this, so in general if a
> nested function escapes into an extern library then
> this cannot be relied on, which limits my original
> idea again to cases where there is no escape (which i
> think is not that useful).

I'm not sure I understand "escape" of a nested function pointer. 

Your description makes it sound like you're talking about a function being 
called by someone who has been given the pointer, from outside the scope of the 
function.  That sounds like an illegal operation, exactly as it would be if you 
attempted to reference an automatic variable via a pointer from outside the 
scope of that variable.

Did I misunderstand?

paul



Re: [ping] Change static chain to r11 on aarch64

2018-12-12 Thread Paul Koning



> On Dec 12, 2018, at 5:12 PM, Uecker, Martin 
>  wrote:
>> ...
>> I've not seen such an alternative implementation (-fno-trampolines is
>> ignored on all targets I tried),
> 
> It was implemented for Ada. But here is a patch to also
> activate it for C:
> 
> https://gcc.gnu.org/ml/gcc-patches/2018-12/msg00853.html
> 
> With this patch one can use nested functions in C without
> having an executable stack.

That's interesting, because the internals manual (section 18.11, "Support for 
nested functions") clearly implies that it's already supported so long as the 
target defines the necessary macros / target hooks.  Though admittedly the 
documentation is a bit muddled.

I've been wanting to use this, since executable stacks really need to be 
avoided on pdp11.

paul




Re: Bug in divmodhi4(), plus poor inperformant code

2018-12-05 Thread Paul Koning



> On Dec 5, 2018, at 11:23 AM, Segher Boessenkool  
> wrote:
> 
> On Wed, Dec 05, 2018 at 02:19:14AM +0100, Stefan Kanthak wrote:
>> "Paul Koning"  wrote:
>> 
>>> Yes, that's a rather nasty cut & paste error I made.
>> 
>> I suspected that.
>> Replacing
>>!(den & (1L<<31))
>> with
>>(signed short) den >= 0
>> avoids this type of error: there's no need for a constant here!
>> 
>> JFTR: of course the 1L should be just a 1, without suffix.
> 
> "int" can be 16 bits only, I think?  If you change to 15 you can remove
> the L, sure.

"int" on pdp11 is either 16 or 32 bits depending on switches, but "short int" 
is always 16.  I changed it to be 1U << 15 which seems more appropriate if int 
is 16 bits.

paul




Re: Bug in divmodhi4(), plus poor inperformant code

2018-12-05 Thread Paul Koning



> On Dec 4, 2018, at 8:19 PM, Stefan Kanthak  wrote:
> 
> "Paul Koning"  wrote:
> 
>> Yes, that's a rather nasty cut & paste error I made.
> 
> I suspected that.
> Replacing
>!(den & (1L<<31))
> with
>(signed short) den >= 0
> avoids this type of error: there's no need for a constant here!
> 
> JFTR: of course the 1L should be just a 1, without suffix.
> 
>> But if the 31 is changed to a 15, is the code correct?
>> I would think so.
> 
> Almost. It's the standard algorithm, and it's correct except
> for den == 0, where the current implementation returns 0 as
> quotient or the numerator as remainder, while my fix yields an
> endless loop (as could be expected for "undefined behaviour").

I submitted a patch that just changes that one line.  This file is a copy of 
udivmodsi4.c so I figured I'd aim for the same logic except for the word length 
changes, and the 31 instead of 15 was a missed edit for that.

The other changes could be left for later, or a handwritten assembly routine 
used instead as some other targets do.

Thanks!

paul



[PATCH, libgcc] Bug fix in udivmodhi4.c

2018-12-05 Thread Paul Koning
This fixes a cut & paste oversight in udivmodhi4 (which is currently used only 
by the pdp11 target) reported by Stefan Kanthak.

Committed as obvious.

paul

ChangeLog:

2018-12-05  Paul Koning  

* udivmodhi4.c (__udivmodhi4): Fix loop end check.

Index: libgcc/udivmodhi4.c
===
--- libgcc/udivmodhi4.c (revision 266823)
+++ libgcc/udivmodhi4.c (working copy)
@@ -27,7 +27,7 @@ __udivmodhi4(unsigned short num, unsigned short de
   unsigned short bit = 1;
   unsigned short res = 0;
 
-  while (den < num && bit && !(den & (1L<<31)))
+  while (den < num && bit && !(den & (1U<<15)))
 {
   den <<=1;
   bit <<=1;



Re: Bug in divmodhi4(), plus poor inperformant code

2018-12-04 Thread Paul Koning
Yes, that's a rather nasty cut & paste error I made.

But if the 31 is changed to a 15, is the code correct?  I would think so.  For 
optimization I'd think that an assembly language version would make more sense, 
and a few targets do that.

paul


> On Dec 4, 2018, at 5:51 PM, Stefan Kanthak  wrote:
> 
> Hi @ll,
> 
> libgcc's divmodhi4() function has an obvious bug; additionally
> it shows rather poor inperformant code: two of the three conditions
> tested in the first loop should clearly moved outside the loop!
> 
> divmodsi4() shows this inperformant code too!
> 
> regards
> Stefan Kanthak
> 
> --- divmodhi4.c ---
> 
> unsigned short
> __udivmodhi4(unsigned short num, unsigned short den, int modwanted)
> {
>  unsigned short bit = 1;
>  unsigned short res = 0;
> 
> #ifdef BUGFIX
>  if (den > num)
> return modwanted ? num : 0;
>  if (den == num)
> return modwanted ? 0 : 1;
>  while ((signed short) den >= 0)
> #else // original, buggy and inperformant code
>  while (den < num && bit && !(den & (1L<<31)))  // unsigned shorts are 16 bit!
> #endif
>{
>  den <<=1;
>  bit <<=1;
>}
>  while (bit)
>{
>  if (num >= den)
>{
>  num -= den;
>  res |= bit;
>}
>  bit >>=1;
>  den >>=1;
>}
>  if (modwanted) return num;
>  return res;
> }



Re: [PATCH] PR880088 Enable -Wtrampolines for no-exec-stack targets with -Wall.

2018-11-26 Thread Paul Koning



> On Nov 26, 2018, at 4:13 AM, Mark Wielaard  wrote:
> 
> With -Wtrampolines a warning is produced whenever gcc generates executable
> code on the stack at runtime to support taking a nested function address
> that is used to call the nested function indirectly when it needs to access
> any variables in its lexical scope.
> 
> As a result the stack has to be marked as executable even for targets which
> have a non-executable stack as default.
> 
> Define a new target macro TARGET_HAS_DEFAULT_NOEXEC_STACK for those targets
> that have a non-executable default stack based on when they call
> file_end_indicate_exec_stack.

The word "default" suggests this is a constant attribute of the platform.  Can 
it be variable?  Whether the stack is executable or not may depend on 
-m switches.

paul




[PATCH, pdp11] Fix 64 bit divide

2018-11-25 Thread Paul Koning
This fixes a number of testsuite failures in pdp11.

Committed.

paul

ChangeLog:

2018-11-25  Paul Koning  

* config/pdp11/pdp11.h (TARGET_HAS_NO_HW_DIVIDE): Define.

Index: config/pdp11/pdp11.h
===
--- config/pdp11/pdp11.h(revision 266438)
+++ config/pdp11/pdp11.h(working copy)
@@ -143,6 +143,11 @@ extern const struct real_format pdp11_d_format;
 /* Define this if move instructions will actually fail to work
when given unaligned data.  */
 #define STRICT_ALIGNMENT 1
+
+/* "HW_DIVIDE" actually means 64 by 32 bit divide.  While some PDP11
+   models have hardware divide, it is for 32 by 16 bits only, so we
+   call this platform "no hardware divide".  */
+#define TARGET_HAS_NO_HW_DIVIDE 1
 
 /* Standard register usage.  */
 



[PATCH, testsuite] Fix pdp11 test failures

2018-11-19 Thread Paul Koning
This corrects a number of pdp11 test suite failures.  The first set fail due to 
larger than supported alignment.  The next two look for .ascii directives in 
the assembly output which pdp11 does not use.  The last one needs adjustment 
because CSE loads subroutine addresses into registers in this test.

Committed.

paul

testsuite/ChangeLog:

2018-11-19  Paul Koning  

* gcc.c-torture/execute/align-3.c: Skip if pdp11.
* gcc.c-torture/execute/pr23467.c: Ditto.
* gcc.c-torture/execute/pr36093.c: Ditto.
* gcc.c-torture/execute/pr43783.c: Ditto.
* gcc.dg/const-elim-2.c: Xfail if pdp11.
* gcc.dg/torture/pr36400.c: Ditto.
* gcc.dg/tree-ssa/loop-1.c: Xfail for pdp11.  Add pdp11 to check
for jsr.

Index: gcc.c-torture/execute/align-3.c
===
--- gcc.c-torture/execute/align-3.c (revision 266295)
+++ gcc.c-torture/execute/align-3.c (working copy)
@@ -1,3 +1,5 @@
+/* { dg-skip-if "small alignment" { pdp11-*-* } } */
+
 void func(void) __attribute__((aligned(256)));
 
 void func(void) 
Index: gcc.c-torture/execute/pr23467.c
===
--- gcc.c-torture/execute/pr23467.c (revision 266295)
+++ gcc.c-torture/execute/pr23467.c (working copy)
@@ -1,3 +1,5 @@
+/* { dg-skip-if "small alignment" { pdp11-*-* } } */
+
 struct s1
 {
   int __attribute__ ((aligned (8))) a;
Index: gcc.c-torture/execute/pr36093.c
===
--- gcc.c-torture/execute/pr36093.c (revision 266295)
+++ gcc.c-torture/execute/pr36093.c (working copy)
@@ -1,3 +1,5 @@
+/* { dg-skip-if "small alignment" { pdp11-*-* } } */
+
 extern void abort (void);
 
 typedef struct Bar {
Index: gcc.c-torture/execute/pr43783.c
===
--- gcc.c-torture/execute/pr43783.c (revision 266295)
+++ gcc.c-torture/execute/pr43783.c (working copy)
@@ -1,3 +1,5 @@
+/* { dg-skip-if "small alignment" { pdp11-*-* } } */
+
 typedef __attribute__((aligned(16)))
 struct {
   unsigned long long w[3];
Index: gcc.dg/const-elim-2.c
===
--- gcc.dg/const-elim-2.c   (revision 266295)
+++ gcc.dg/const-elim-2.c   (working copy)
@@ -1,7 +1,7 @@
 /* The string constant in this test case should be emitted exactly once.  */
 /* { dg-do compile } */
 /* { dg-options "-O2" } */
-/* { dg-final { scan-assembler-times "hi there" 1 { xfail nvptx-*-* } } } */
+/* { dg-final { scan-assembler-times "hi there" 1 { xfail nvptx-*-* pdp11-*-* 
} } } */
 
 static inline int returns_23() { return 23; }
 
Index: gcc.dg/torture/pr36400.c
===
--- gcc.dg/torture/pr36400.c(revision 266295)
+++ gcc.dg/torture/pr36400.c(working copy)
@@ -14,4 +14,4 @@ void baz()
   barptr->some_string = "Everything OK";
 }
 
-/* { dg-final { scan-assembler "Everything OK" { xfail nvptx-*-* } } } */
+/* { dg-final { scan-assembler "Everything OK" { xfail nvptx-*-* pdp11-*-* } } 
} */
Index: gcc.dg/tree-ssa/loop-1.c
===
--- gcc.dg/tree-ssa/loop-1.c(revision 266295)
+++ gcc.dg/tree-ssa/loop-1.c(working copy)
@@ -46,7 +46,7 @@ int xxx(void)
 /* CRIS keeps the address in a register.  */
 /* m68k sometimes puts the address in a register, depending on CPU and PIC.  */
 
-/* { dg-final { scan-assembler-times "foo" 5 { xfail hppa*-*-* ia64*-*-* 
sh*-*-* cris-*-* crisv32-*-* fido-*-* m68k-*-* i?86-*-mingw* i?86-*-cygwin* 
x86_64-*-mingw* visium-*-* nvptx*-*-* } } } */
+/* { dg-final { scan-assembler-times "foo" 5 { xfail hppa*-*-* ia64*-*-* 
sh*-*-* cris-*-* crisv32-*-* fido-*-* m68k-*-* i?86-*-mingw* i?86-*-cygwin* 
x86_64-*-mingw* visium-*-* nvptx*-*-* pdp11*-*-* } } } */
 /* { dg-final { scan-assembler-times "foo,%r" 5 { target hppa*-*-* } } } */
 /* { dg-final { scan-assembler-times "= foo"  5 { target ia64*-*-* } } } */
 /* { dg-final { scan-assembler-times "call\[ \t\]*_foo" 5 { target 
i?86-*-mingw* i?86-*-cygwin* } } } */
@@ -53,6 +53,6 @@ int xxx(void)
 /* { dg-final { scan-assembler-times "call\[ \t\]*foo" 5 { target 
x86_64-*-mingw* } } } */
 /* { dg-final { scan-assembler-times "jsr|bsrf|blink\ttr?,r18"  5 { target 
sh*-*-* } } } */
 /* { dg-final { scan-assembler-times "Jsr \\\$r" 5 { target cris-*-* } } } */
-/* { dg-final { scan-assembler-times "\[jb\]sr" 5 { target fido-*-* m68k-*-* } 
} } */
+/* { dg-final { scan-assembler-times "\[jb\]sr" 5 { target fido-*-* m68k-*-* 
pdp11-*-* } } } */
 /* { dg-final { scan-assembler-times "bra *tr,r\[1-9\]*,r21" 5 { target 
visium-*-* } } } */
 /* { dg-final { scan-assembler-times "(?n)\[ \t\]call\[ \t\].*\[ \t\]foo," 5 { 
target nvptx*-*-* } } } */



Re: [PATCH, testsuite] indicate no "weak" support in pdp11

2018-11-19 Thread Paul Koning



> On Nov 19, 2018, at 5:20 PM, Jeff Law  wrote:
> 
> On 11/19/18 3:18 PM, Paul Koning wrote:
>> This patch changes check_weak_available to report that pdp11 does not 
>> support "weak".  A number of test case failures are caused by attempts to 
>> use weak support which is missing in the pdp11 flavor of a.out.
>> 
>> I'm not sure if this is covered by target maintainer authority so I figure 
>> it's best to ask for approval.
>> 
>> Ok for trunk?
>> 
>>  paul
>> 
>> testsuite/ChangeLog:
>> 
>> 2018-11-19  Paul Koning  
>> 
>>  * lib/target-supports.exp (check_weak_available): Return "no" for
>>  pdp11.
> Yes.  And FWIW this kind of change falls into what maintainers can make
> and self-approve.
> 
> jeff

Thanks for the clarification.  Committed.

paul



[PATCH, testsuite] indicate no "weak" support in pdp11

2018-11-19 Thread Paul Koning
This patch changes check_weak_available to report that pdp11 does not support 
"weak".  A number of test case failures are caused by attempts to use weak 
support which is missing in the pdp11 flavor of a.out.

I'm not sure if this is covered by target maintainer authority so I figure it's 
best to ask for approval.

Ok for trunk?

paul

testsuite/ChangeLog:

2018-11-19  Paul Koning  

* lib/target-supports.exp (check_weak_available): Return "no" for
pdp11.

Index: lib/target-supports.exp
===
--- lib/target-supports.exp (revision 266288)
+++ lib/target-supports.exp (working copy)
@@ -314,6 +314,12 @@ proc check_weak_available { } {
return 1
 }
 
+# pdp11 doesn't support it
+
+if { [istarget pdp11*-*-*] } {
+   return 0
+}
+
 # ELF and ECOFF support it. a.out does with gas/gld but may also with
 # other linkers, so we should try it
 



Re: [PATCH 1/7][MSP430][TESTSUITE] Tweak dg-directives for msp430-elf

2018-11-15 Thread Paul Koning



> On Nov 14, 2018, at 5:19 PM, Jozef Lawrynowicz  
> wrote:
> 
> On Wed, 14 Nov 2018 11:30:39 -0500
> Paul Koning  wrote:
> 
>>> On Nov 14, 2018, at 10:44 AM, Jozef Lawrynowicz 
>>> wrote:
>>> 
>>> Patch 1 tweaks dg directives in tests specifically for msp430. Many of
>>> these are extensions to existing target selectors in dg directives.
>>> 
>>> <0001-TESTSUITE-MSP430-Tweak-dg-directives-for-msp430-elf.patch>  
>> 
>> For pr41779.c, you have
>> 
>> +/* { dg-skip-if "int is smaller than float" { msp430-*-* } } */
>> 
>> I take it that means: sizeof(int) < sizeof(float).  That property also holds
>> for pdp11 and perhaps other targets.  Would it make sense to introduce a new
>> effective-target flag for that check instead?
>> 
>>  paul
>> 
> 
> Paul,
> 
> Yes you are correct the comment implies sizeof(int) < sizeof(float).
> 
> I believe this was the only test where this property affected the test
> results, so a new effective-target flag is probably only worth adding if it
> affects at least a couple of tests.
> On the other hand, I suppose there is no harm in adding another
> check-effective-target and it at least means we'll catch failures across more
> targets.
> 
> I'd be curious if the line I added the xfail to in c-c++-common/pr57371-2.c
> also fails for pdp11.
> 
> The conversion to float might be getting optimized out whenever
> sizeof(int) < sizeof(float).
> 
> Thanks,
> Jozef

Yes, that test on pr57371-2.c also fails on pdp11.

paul



Re: [PATCH 1/7][MSP430][TESTSUITE] Tweak dg-directives for msp430-elf

2018-11-14 Thread Paul Koning



> On Nov 14, 2018, at 1:00 PM, Jozef Lawrynowicz  
> wrote:
> 
> On 14/11/2018 16:54, Andreas Schwab wrote:
>> On Nov 14 2018, Jozef Lawrynowicz  wrote:
>> 
>>> diff --git a/gcc/testsuite/c-c++-common/torture/builtin-arith-overflow-10.c 
>>> b/gcc/testsuite/c-c++-common/torture/builtin-arith-overflow-10.c
>>> index 6b1c427..71d24ce 100644
>>> --- a/gcc/testsuite/c-c++-common/torture/builtin-arith-overflow-10.c
>>> +++ b/gcc/testsuite/c-c++-common/torture/builtin-arith-overflow-10.c
>>> @@ -1,6 +1,7 @@
>>>  /* Test __builtin_{add,sub}_overflow on {,un}signed long int.  */
>>>  /* { dg-do run } */
>>>  /* { dg-skip-if "" { ! run_expensive_tests }  { "*" } { "-O0" "-O2" } } */
>>> +/* { dg-timeout 120 { target msp430-*-* } } */
>> Are you sure you want to _decrease_ the timeout?  The default is 300
>> seconds.
>> 
>> Andreas.
>> 
> The timeout as set in the dejagnu configuration for msp430 
> ([dejagnu.git]/baseboards/msp430-sim.exp) is 30, which is rarely hit. There 
> are some tests which pass most of of the time but will occasionally timeout 
> so maybe the default timeout in dejagnu is worth increasing a little as well.

Would it make sense to use { dg-timeout-factor 4 ... } instead?  That would 
make it explicit that you're raising rather than lowering the timeout.

paul




Re: [PATCH 1/7][MSP430][TESTSUITE] Tweak dg-directives for msp430-elf

2018-11-14 Thread Paul Koning



> On Nov 14, 2018, at 10:44 AM, Jozef Lawrynowicz  
> wrote:
> 
> Patch 1 tweaks dg directives in tests specifically for msp430. Many of
> these are extensions to existing target selectors in dg directives.
> 
> <0001-TESTSUITE-MSP430-Tweak-dg-directives-for-msp430-elf.patch>

For pr41779.c, you have

+/* { dg-skip-if "int is smaller than float" { msp430-*-* } } */

I take it that means: sizeof(int) < sizeof(float).  That property also holds 
for pdp11 and perhaps other targets.  Would it make sense to introduce a new 
effective-target flag for that check instead?

paul



Ping: [PATCH, testsuite] ignore some "conflicting types for built-in" messages

2018-11-09 Thread Paul Koning
Ping.

I'd like to commit this.  The discussion seems to have ended up with the 
conclusion that this is a reasonable approach.

paul


> On Nov 1, 2018, at 3:13 PM, Paul Koning  wrote:
> 
> A number of test cases contain declarations like:
>  void *memcpy();
> which currently are silently accepted on most platforms but not on all; pdp11 
> (and possibly some others) generate a "conflicting types for built-in 
> function" warning.
> 
> It was suggested to prune those messages because the test cases where these 
> occur are not looking for the message but are testing some other issue, so 
> the message is not relevant.  The attached patch adds dg-prune-output 
> directives to do so.
> 
> Ok for trunk?
> 
>   paul
> 
> ChangeLog:
> 
> 2018-11-01  Paul Koning  
> 
>   * gcc.dg/Walloca-16.c: Ignore conflicting types for built-in
>   warnings.
>   * gcc.dg/Wrestrict-4.c: Ditto.
>   * gcc.dg/Wrestrict-5.c: Ditto.
>   * gcc.dg/pr83463.c: Ditto.
>   * gcc.dg/torture/pr55890-2.c: Ditto.
>   * gcc.dg/torture/pr55890-3.c: Ditto.
>   * gcc.dg/torture/pr71816.c: Ditto.
> 
> Index: gcc.dg/Walloca-16.c
> ===
> --- gcc.dg/Walloca-16.c   (revision 265727)
> +++ gcc.dg/Walloca-16.c   (working copy)
> @@ -1,5 +1,6 @@
> /* PR tree-optimization/84224 */
> /* { dg-do compile } */
> +/* { dg-prune-output "conflicting types for built-in" } */
> /* { dg-options "-O0 -Walloca" } */
> 
> void *alloca ();
> Index: gcc.dg/Wrestrict-4.c
> ===
> --- gcc.dg/Wrestrict-4.c  (revision 265727)
> +++ gcc.dg/Wrestrict-4.c  (working copy)
> @@ -3,6 +3,7 @@
>Test to verify that invalid calls to built-in functions declared
>without a prototype don't cause an ICE.
>{ dg-do compile }
> +   { dg-prune-output "conflicting types for built-in" }
>{ dg-options "-O2 -Warray-bounds -Wrestrict" } */
> 
> void* memcpy ();
> Index: gcc.dg/Wrestrict-5.c
> ===
> --- gcc.dg/Wrestrict-5.c  (revision 265727)
> +++ gcc.dg/Wrestrict-5.c  (working copy)
> @@ -2,6 +2,7 @@
>functions declared with no prototype are checked for overlap, and that
>invalid calls are ignored.
>   { dg-do compile }
> +  { dg-prune-output "conflicting types for built-in" }
>   { dg-options "-O2 -Wrestrict" }  */
> 
> typedef __SIZE_TYPE__ size_t;
> Index: gcc.dg/pr83463.c
> ===
> --- gcc.dg/pr83463.c  (revision 265727)
> +++ gcc.dg/pr83463.c  (working copy)
> @@ -1,5 +1,6 @@
> /* PR middle-end/83463 */
> /* { dg-do compile } */
> +/* { dg-prune-output "conflicting types for built-in" } */
> /* { dg-options "-O2 -Wrestrict -Wno-pointer-to-int-cast" } */
> 
> int *a;
> Index: gcc.dg/torture/pr55890-2.c
> ===
> --- gcc.dg/torture/pr55890-2.c(revision 265727)
> +++ gcc.dg/torture/pr55890-2.c(working copy)
> @@ -1,4 +1,5 @@
> /* { dg-do compile } */
> +/* { dg-prune-output "conflicting types for built-in" } */
> 
> extern void *memcpy();
> int main() { memcpy(); }
> Index: gcc.dg/torture/pr55890-3.c
> ===
> --- gcc.dg/torture/pr55890-3.c(revision 265727)
> +++ gcc.dg/torture/pr55890-3.c(working copy)
> @@ -1,4 +1,5 @@
> /* { dg-do compile } */
> +/* { dg-prune-output "conflicting types for built-in" } */
> 
> void *memmove ();
> 
> Index: gcc.dg/torture/pr71816.c
> ===
> --- gcc.dg/torture/pr71816.c  (revision 265727)
> +++ gcc.dg/torture/pr71816.c  (working copy)
> @@ -1,4 +1,5 @@
> /* { dg-do compile } */
> +/* { dg-prune-output "conflicting types for built-in" } */
> 
> void *ext2fs_resize_mem_p;
> struct ext2_icount_el {
> 



[PATCH, pdp11] Bugfixes from test suite

2018-11-08 Thread Paul Koning
This patch corrects a large number of test suite failures.  I'm now down to 
about 1100 failures out of over 60k total, from at least 4000 before.  

Committed.

paul

ChangeLog:

2018-11-08  Paul Koning  

* config/pdp11/constraints.md: Add "Z" series constraints for use
with pre-dec and post-inc addressing.
* config/pdp11/pdp11-protos.m (expand_block_move): Delete.
(pdp11_expand_operands): Add int argument (word count).
(pdp11_sp_frame_offset): Delete.
(pdp11_cmp_length): New function.
(pushpop_regeq): New function.
* config/pdp11/pdp11.c (TARGET_STACK_PROTECT_RUNTIME_ENABLED_P):
Add hook.
(pdp11_expand_prologue, pdp11_expand_epilogue): Rewrite for new
frame layout.
(pdp11_initial_elimination_offset): Ditto.
(pdp11_expand_operands): Add word count argument.  Bugfixes.
(output_move_multiple): Change how pointer adjustment is done.
(pdp11_gen_int_label): Correct format.
(output_ascii): Ditto.
(pdp11_asm_output_var): Add code for DEC assembler case.
(pdp11_asm_print_operand): Bugfix for CONST_DOUBLE holding integer
value.
(legitimate_const_double_p): Ditto.
(pdp11_register_move_cost): Adjust for new register classes.
(pdp11_regno_reg_class): Ditto.
(expand_block_move): Delete.
(pushpop_regeq): New function.
(pdp11_legitimate_address_p): Bugfix in check for constant
offset.
(pdp11_sp_frame_offset): Delete.
(pdp11_reg_save_size): New helper function for new frame layout.
(output_addr_const_pdp11): Remove CONST_DOUBLE case.
(pdp11_expand_shift): Bugfix in check for constant shift count.
(pdp11_shift_length): Ditto.
(pdp11_assemble_shift): Copy input to pdp11_expand_operands.
(pdp11_cmp_length): New function.
* config/pdp11/pdp11.h (TARGET_CPU_CPP_BUILTINS): Add macros for
some compile options.
(FIXED_REGISTERS): Remove HARD_FRAME_POINTER_REGNUM.
(CALL_USED_REGISTERS): Ditto.
(ELIMINABLE_REGS): Ditto.
(REGISTER_NAMES): Ditto.
(reg_class): Add classes NOTR0_REG through NOTSP_REG for use by Z
constraints.
(REG_CLASS_NAMES): Ditto.
(REG_CLASS_CONTENTS): Ditto.  Also remove
HARD_FRAME_POINTER_REGNUM.
(CPU_REG_CLASS): New macro.
(CLASS_MAX_NREGS): Adjust for new register classes.
(FUNCTION_PROFILER): Make no-op.
(may_call_alloca): Remove unused declaration.
(ASM_OUTPUT_ALIGN): Add workaround for PR87795.
(ASM_OUTPUT_SKIP): Fix format.
* config/pdp11/pdp11.md (unspecv): Add UNSPECV_MOVMEM.
(HARD_FRAME_POINTER_REGNUM): Remove.
(return): Delete.
(*rts): Rename.  Remove epilogue related checks.
(cmpsi, cmpdi): New insn.
(cbranch4): Change to apply to SI and DI modes as well.
(mov): Change constraints to enforce that push/pop
destination cannot use the same register as source.
(*mov): Ditto.
(movmemhi, movmemhi1, movmemhi_nocc): Change to expand block move
at assembly output rather than as RTL expander.
(zero_extendqihi2): Bugfix in check for same registers.
(adddi3_nocc): Bugfix in check for constant operand.
(addsi3_nocc): Ditto.
(subdi3_nocc): Ditto.
(subsi3_nocc): Ditto.
(negdi2_nocc): Copy input to pdp11_expand_operands.
(negsi2_nocc): Ditto.
(bswap2_nocc): Ditto.
* config/pdp11/pdp11.opt (mlra): Fix documentation.
* config/pdp11/t-pdp11: Use -Os.

Index: config/pdp11/constraints.md
===
--- config/pdp11/constraints.md (revision 265931)
+++ config/pdp11/constraints.md (working copy)
@@ -88,3 +88,32 @@
(match_test "memory_address_p (GET_MODE (op), XEXP (op, 0))
 && no_side_effect_operand (op, GET_MODE (op))")))
 
+;; What follows is a set of constraints used to prevent the generation
+;; of insns that have a register as source, and an auto-increment or
+;; auto-decrement memory reference as the destination where the register
+;; is the same as the source.  On the PDP11, such instructions are not
+;; implemented consistently across the models and often do something
+;; different from what the RTL intends.
+(define_register_constraint "Z0" "NOTR0_REG" "Register other than 0")
+(define_register_constraint "Z1" "NOTR1_REG" "Register other than 1")
+(define_register_constraint "Z2" "NOTR2_REG" "Register other than 2")
+(define_register_constraint "Z3" "NOTR3_REG" "Register other than 3")
+(define_register_constraint "Z4" "NOTR4_REG" "Register other than 4")
+(define_register_constraint &qu

Re: [PATCH, testsuite] add "inf" target attribute

2018-11-05 Thread Paul Koning



> On Nov 4, 2018, at 2:33 PM, Jeff Law  wrote:
> 
> On 11/1/18 1:30 PM, Paul Koning wrote:
>> A number of test cases fail on pdp11 because they use the "inf" float value 
>> which does not exist on that target (nor on VAX).  Rainer Orth and Joseph 
>> Myers suggested adding a new effective-target keyword to check for this, and 
>> require it for tests that have that dependency.
>> 
>> The attached patch implements this.  Ok for trunk?
>> 
>>  paul
>> 
>> ChangeLog:
>> 
>> 2018-11-01  Paul Koning  
>> 
>>  * doc/sourcebuild.texi (target attributes): Document new "inf"
>>  effective target keyword.
> OK with me.
> 
> jeff

Thanks.  Committed, with the doc change clarified to address Joseph's comment.

paul

Index: doc/sourcebuild.texi
===
--- doc/sourcebuild.texi(revision 265814)
+++ doc/sourcebuild.texi(revision 265815)
@@ -1393,8 +1393,11 @@ for any options added with @code{dg-add-options}.
 Target has runtime support for any options added with
 @code{dg-add-options} for any @code{_Float@var{n}} or
 @code{_Float@var{n}x} type.
+
+@item inf
+Target supports floating point infinite (@code{inf}) for type
+@code{double}.
 @end table
-
 @subsubsection Fortran-specific attributes
 
 @table @code



Re: PR83750: CSE erf/erfc pair

2018-11-05 Thread Paul Koning



> On Nov 5, 2018, at 1:48 PM, Michael Matz  wrote:
> 
> Hi,
> 
> On Mon, 5 Nov 2018, Jeff Law wrote:
> 
 Don't we have a flag specific to honoring nans?  Would that be better 
 to use than flag_unsafe_math_optimizations?  As Uli mentioned, 
 there's
>>> 
>>> That's only relevant for the comparison optimization, of course.
>>> 
>>> Converting erfc to 1-erf is dubious, since the whole point of erfc is 
>>> for cases where 1-erf is inaccurate.  (Conversion in the other 
>>> direction also needs flag_unsafe_math_optimizations.)
>>> 
>> Understood.  Thanks for clarifying.  It seems like 
>> unsafe-math-optimization is a better fit than the nan specific flag.
> 
> But still we should consider general usefullness, even with unsafe-math.  
> In this case we would remove a usage of a slow function that the user 
> specifically used to deal with inaccuracies with an equally slow function 
> (plus a little arithmetic that is shadows by the functions slowness) that 
> now exacly produces the inaccuracies the user wanted to avoid.  I.e. the 
> speed gain is zero.  The "canonicalization gain" referred to in the PR 
> might be real, but it comes at the cost of introducing definite 
> catastrophic cancellation.
> 
> IMHO that's not a sensible transformation to do, under any flags.

That seems right.  The same goes for log vs. logp1, and exp vs. expm1.

paul



Re: [PATCH, testsuite] ignore some "conflicting types for built-in" messages

2018-11-05 Thread Paul Koning



> On Nov 5, 2018, at 11:45 AM, Jeff Law  wrote:
> 
>>> ...
>> 
>> I can do that, but I'm wondering if some systems have different prototypes 
>> than the C standard calls for so I'd end up breaking those.I wouldn't worry 
>> about those.  I think the bigger question (thanks
> Martin) is whether or not any of those tests are checking for issues
> that arise specifically due to not having a full prototype available
> (and in those cases your fix is probably more appropriate).
> 
> Probably the only way to figure that out is to dig into the history of
> each one :(  Mighty unpleasant.
> 
> jeff

I took a quick look.  PR83655 is specifically about an issue due to a 
declaration with no prototype, but the others (55890, 71816, 83463, 83603, 
84244) are not so clear to me.  Still, what IS clear is that none of them are 
interested in messages that may or may not be generated as a result of these 
funny declarations.  In other words, pruning the messages still looks 
appropriate.

So where do I go from here?  Without the change I can deal with this by 
recognizing these cases as false failures when I do my test runs.

paul



Re: [PATCH, testsuite] ignore some "conflicting types for built-in" messages

2018-11-05 Thread Paul Koning



> On Nov 3, 2018, at 10:12 PM, Jeff Law  wrote:
> 
> On 11/1/18 1:13 PM, Paul Koning wrote:
>> A number of test cases contain declarations like:
>>  void *memcpy();
>> which currently are silently accepted on most platforms but not on all; 
>> pdp11 (and possibly some others) generate a "conflicting types for built-in 
>> function" warning.
>> 
>> It was suggested to prune those messages because the test cases where these 
>> occur are not looking for the message but are testing some other issue, so 
>> the message is not relevant.  The attached patch adds dg-prune-output 
>> directives to do so.
>> 
>> Ok for trunk?
>> 
>>  paul
>> 
>> ChangeLog:
>> 
>> 2018-11-01  Paul Koning  
>> 
>>  * gcc.dg/Walloca-16.c: Ignore conflicting types for built-in
>>  warnings.
>>  * gcc.dg/Wrestrict-4.c: Ditto.
>>  * gcc.dg/Wrestrict-5.c: Ditto.
>>  * gcc.dg/pr83463.c: Ditto.
>>  * gcc.dg/torture/pr55890-2.c: Ditto.
>>  * gcc.dg/torture/pr55890-3.c: Ditto.
>>  * gcc.dg/torture/pr71816.c: Ditto.
> ISTM it'd be better to just fix memcpy to have a correct prototype.
> 
> jeff

I can do that, but I'm wondering if some systems have different prototypes than 
the C standard calls for so I'd end up breaking those.

paul



Re: [PATCH, testsuite] test case fixes for pdp11

2018-11-02 Thread Paul Koning



> On Nov 2, 2018, at 3:19 PM, Rainer Orth  wrote:
> 
> Hi Paul,
> 
>> This patch fixes a number of test case failures on pdp11.  Some are too 
>> large for the address space, some have dependencies on the float format that 
>> don't match the DEC format, some add pdp11 to the targets that expect 
>> particular compiler messages.
> 
> unfortunately, even apart from the two bugs in your patch Andreas
> already fixed, there are more problems: with the patch one gets 20
> warnings
> 
> WARNING: compat.exp does not support dg-skip-if
> 
> in mail-report.log for gcc.dg/compat.  While the message is misleading
> and it took me a moment to understand what's wrong, you should have
> found this in your testing.  A good way something like this doesn't go
> unnoticed in a regtest is to run make mail-report.log in a vanilla and
> patched tree and compare the output.  Those WARNING and ERROR lines are
> prominent there for a reason ;-)

My apologies for these errors.  I will strive to learn from the feedback you 
and Andreas have given and do it better next time.

I wasn't ware of mail-report -- I have used contrib/test_summary in the past.  
What makes it more difficult in this case is that most of these test cases have 
not run in a long time (if ever) so the volume is quite large.  I'm getting it 
down to a more manageable number, though 1000 out of 60k is still much higher 
than it should be.

> While we give target maintainers quite a bit of leeway to apply
> testsuite patches affecting only their targets, this needs to be
> exercised with caution.  Best test the modified testsuite on a different
> target, too, to check that it doesn't break there.

I understand, I will do so in the future.

> Besides, a bit more detail on the failures you observe without your
> patch would have been helpful.  I noticed that some of the tests you
> change already have dg-skip-if directives for avr with a comment of
> "Program too big".  It's hard to tell if this is the same issue as your
> "limited code space".  If so, it would be advisable and much more
> expressive to introduce (yet another) effective-target keyword for this.

I could use "! ptr32plus".  I'm a bit hesitant to do so because I don't know 
what othe targets might match that.  msp430, based on the comment, and possibly 
others.  For tests that allocate megabyte buffers that's an obvious fit.  For 
tests that generate large blocks of code it isn't quite so obvious; the 
gcc.gd/long_branch.c test is too big for pdp11 but it might be ok for other 
"small" targets.

> The problem is that in the g??.dg/compat testsuites, dg keywords except
> for dg-options are only supposed to go into the *_main.c file.  The
> following patch fixes this.  Tested on i386-pc-solaris2.11 and
> sparc-sun-solaris2.11, installed on mainline.

Thank you.  How can I tell for a particular test case or test directory what 
the rules are for where "dg" directives go, or which ones are supported?  I 
know there is a fair amount of variability in this, but I don't yet understand 
what they all are.

paul




Re: LRA reload produces invalid insn

2018-11-02 Thread Paul Koning



> On Nov 2, 2018, at 9:34 AM, Peter Bergner  wrote:
> 
> On 11/1/18 10:37 PM, Vladimir Makarov wrote:
>> On 11/01/2018 08:25 PM, Paul Koning wrote:
>>> Is this an LRA bug, or is there something I need to do in the target to 
>>> prevent this happening?
>> It is hard to say whose code is responsible for this.  It might be a wrong 
>> machine-dependent code or a LRA bug.
>> 
>> Paul, could you send me full LRA dump file (.reload).  It might help me to 
>> say more specific reason for the bug.  LRA has iterated sub-passes and the 
>> full dump can say where LRA started to behave wrongly.
>> 
> 
> I'll note that when we ported the rs6000 (ie, ppc*) port over to LRA
> from reload, we hit many target problems.  It seems LRA is much less
> forgiving to bad constraints, predicates, etc. than reload was.
> I think that's actually a good thing.
> 
> Peter

Yes, I ran into that, and Segher (I think) helped me with a bad predicate case. 
 It doesn't help that the documentation isn't all that explicit about what the 
requirements are.  

paul



Re: LRA reload produces invalid insn

2018-11-02 Thread Paul Koning



> On Nov 1, 2018, at 8:49 PM, Peter Bergner  wrote:
> 
> On 11/1/18 7:25 PM, Paul Koning wrote:
>> I'm running the testsuite on the pdp11 target, and I get a failure when 
>> using LRA that works correctly with the old allocator.  The issue is that 
>> LRA is producing an insn that is invalid (it violates the constraints stated 
>> in the insn definition).
> [snip]
>> which is the correct sequence given the matching operand constraint in the 
>> define_insn.
>> 
>> Is this an LRA bug, or is there something I need to do in the target to 
>> prevent this happening?
> 
> What do you mean by "old allocator"?  Just an older revision?  Does it work 
> before my
> revision 264897 commit and broken after?  If so, could you try the following 
> to see
> whether that fixes things for you?
> 
>https://gcc.gnu.org/ml/gcc-patches/2018-10/msg01757.html
> 
> My commit above exposed some latent LRA bugs and my patch above tries
> to fix issues similar to what you're seeing.
> 
> Peter

That doesn't cure this particular problem; the ICE is still there with the same 
error message (identical failing insn) as before.

paul



LRA reload produces invalid insn

2018-11-01 Thread Paul Koning
I'm running the testsuite on the pdp11 target, and I get a failure when using 
LRA that works correctly with the old allocator.  The issue is that LRA is 
producing an insn that is invalid (it violates the constraints stated in the 
insn definition).

The insn in the IRA dump looks like this:

(insn 240 238 241 13 (set (reg/f:HI 155)
(plus:HI (reg/f:HI 5 r5)
(const_int -58 [0xffc6]))) 
"/Users/pkoning/Documents/svn/combined/gcc/testsuite/gcc.c-torture/execute/builtins/strcat-chk.c":68:7
 68 {addhi3}
 (expr_list:REG_EQUIV (plus:HI (reg/f:HI 5 r5)
(const_int -58 [0xffc6]))
(nil)))

(note that R5 is FRAME_POINTER_REGNUM.)

The reload dump from LRA shows this:

(insn 240 238 241 13 (set (reg/f:HI 5 r5 [155])
(plus:HI (reg/f:HI 6 sp)
(const_int 12 [0xc]))) 
"/Users/pkoning/Documents/svn/combined/gcc/testsuite/gcc.c-torture/execute/builtins/strcat-chk.c":68:7
 68 {addhi3}
 (expr_list:REG_EQUIV (plus:HI (reg/f:HI 5 r5)
(const_int -58 [0xffc6]))
(nil)))

But that's not valid because ADD is a two-operand instruction:

(define_insn_and_split "addhi3"
  [(set (match_operand:HI 0 "nonimmediate_operand" "=rR,rR,Q,Q")
(plus:HI (match_operand:HI 1 "general_operand" "%0,0,0,0")
 (match_operand:HI 2 "general_operand" "rRLM,Qi,rRLM,Qi")))]

The old allocator produces two insns for this:

(insn 443 238 240 13 (set (reg/f:HI 5 r5 [155])
(const_int 12 [0xc])) 
"/Users/pkoning/Documents/svn/combined/gcc/testsuite/gcc.c-torture/execute/builtins/strcat-chk.c":68:7
 25 {movhi}
 (nil))
(insn 240 443 241 13 (set (reg/f:HI 5 r5 [155])
(plus:HI (reg/f:HI 5 r5 [155])
(reg/f:HI 6 sp))) 
"/Users/pkoning/Documents/svn/combined/gcc/testsuite/gcc.c-torture/execute/builtins/strcat-chk.c":68:7
 68 {addhi3}
 (expr_list:REG_EQUIV (plus:HI (reg/f:HI 6 sp)
(const_int 12 [0xc]))
(nil)))

which is the correct sequence given the matching operand constraint in the 
define_insn.

Is this an LRA bug, or is there something I need to do in the target to prevent 
this happening?

paul



Re: [PATCH, testsuite] add "inf" target attribute

2018-11-01 Thread Paul Koning



> On Nov 1, 2018, at 4:52 PM, Joseph Myers  wrote:
> 
> On Thu, 1 Nov 2018, Paul Koning wrote:
> 
>> +@item inf
>> +Target supports floating point infinite (@code{inf}).
>> @end table
> 
> Do you mean supports infinity for type double?  (That's what the 
> implementation does.)  Supporting it for double is not the same as 
> supporting it for float (SPU supports it for double but not float, hence 
> various such tests, which require infinities or NaNs (or other IEEE 
> features SPU doesn't have) for float, being disabled for SPU).)

Yes, I do mean for double.  I suppose I should say that.

I noticed SPU avoids using __builtin_inff by conditional compile.  I thought of 
adding an "inff" flag also.  The reason I didn't is that my target does not 
need that, so I would end up with a new feature that would only be applied on 
targets I do not know.

paul




[PATCH, testsuite] add "inf" target attribute

2018-11-01 Thread Paul Koning
A number of test cases fail on pdp11 because they use the "inf" float value 
which does not exist on that target (nor on VAX).  Rainer Orth and Joseph Myers 
suggested adding a new effective-target keyword to check for this, and require 
it for tests that have that dependency.

The attached patch implements this.  Ok for trunk?

paul

ChangeLog:

2018-11-01  Paul Koning  

* doc/sourcebuild.texi (target attributes): Document new "inf"
effective target keyword.

Index: doc/sourcebuild.texi
===
--- doc/sourcebuild.texi(revision 265728)
+++ doc/sourcebuild.texi(working copy)
@@ -1393,8 +1393,10 @@ for any options added with @code{dg-add-options}.
 Target has runtime support for any options added with
 @code{dg-add-options} for any @code{_Float@var{n}} or
 @code{_Float@var{n}x} type.
+
+@item inf
+Target supports floating point infinite (@code{inf}).
 @end table
-
 @subsubsection Fortran-specific attributes
 
 @table @code


testsuite/ChangeLog:

2018-11-01  Paul Koning  

* lib/target-supports.exp: Add check for "inf" effective target
keyword.
* gcc.dg/builtins-44.c: Skip if no infinite support.
* gcc.dg/builtins-45.c: Ditto.
* gcc.dg/torture/builtin-complex-1.c: Ditto.
* gcc.dg/torture/builtin-cproj-1.c: Ditto.
* gcc.dg/torture/builtin-frexp-1.c: Ditto.
* gcc.dg/torture/builtin-ldexp-1.c: Ditto.
* gcc.dg/torture/builtin-logb-1.c: Ditto.
* gcc.dg/torture/builtin-math-2.c: Ditto.
* gcc.dg/torture/builtin-math-5.c: Ditto.
* gcc.dg/torture/builtin-math-7.c: Ditto.
* gcc.dg/torture/builtin-modf-1.c: Ditto.
* gcc.dg/torture/type-generic-1.c: Ditto.


Index: lib/target-supports.exp
===
--- lib/target-supports.exp (revision 265728)
+++ lib/target-supports.exp (working copy)
@@ -8933,3 +8933,10 @@ proc check_effective_target_cet { } {
}
 } "-O2" ]
 }
+
+# Return 1 if target supports floating point "infinite"
+proc check_effective_target_inf { } {
+return [check_no_compiler_messages supports_inf assembly {
+const double pinf = __builtin_inf ();
+}]
+}
Index: gcc.dg/builtins-44.c
===
--- gcc.dg/builtins-44.c(revision 265728)
+++ gcc.dg/builtins-44.c(working copy)
@@ -1,4 +1,5 @@
 /* { dg-do compile } */
+/* { dg-require-effective-target inf } */
 /* { dg-options "-O1 -fno-trapping-math -fno-finite-math-only 
-fdump-tree-optimized" } */
   
 extern void f(int);
Index: gcc.dg/builtins-45.c
===
--- gcc.dg/builtins-45.c(revision 265728)
+++ gcc.dg/builtins-45.c(working copy)
@@ -1,4 +1,5 @@
 /* { dg-do compile } */
+/* { dg-require-effective-target inf } */
 /* { dg-options "-O1 -fno-trapping-math -fno-finite-math-only 
-fdump-tree-optimized" } */
   
 extern void f(int);
Index: gcc.dg/torture/builtin-complex-1.c
===
--- gcc.dg/torture/builtin-complex-1.c  (revision 265728)
+++ gcc.dg/torture/builtin-complex-1.c  (working copy)
@@ -1,6 +1,7 @@
 /* Test __builtin_complex semantics.  */
 /* { dg-do run } */
 /* { dg-options "-std=c11 -pedantic-errors" } */
+/* { dg-require-effective-target inf } */
 /* { dg-add-options ieee } */
 
 extern void exit (int);
Index: gcc.dg/torture/builtin-cproj-1.c
===
--- gcc.dg/torture/builtin-cproj-1.c(revision 265728)
+++ gcc.dg/torture/builtin-cproj-1.c(working copy)
@@ -7,6 +7,7 @@
 
 /* { dg-do link } */
 /* { dg-skip-if "" { *-*-* } { "-O0" } { "" } } */
+/* { dg-require-effective-target inf } */
 /* { dg-add-options ieee } */
 
 /* All references to link_error should go away at compile-time.  The
Index: gcc.dg/torture/builtin-frexp-1.c
===
--- gcc.dg/torture/builtin-frexp-1.c(revision 265728)
+++ gcc.dg/torture/builtin-frexp-1.c(working copy)
@@ -9,6 +9,7 @@
 /* { dg-options "-fno-finite-math-only" { target sh*-*-* } } */
 /* In order to fold algebraic exprs below, targets with "composite"
floating point formats need -funsafe-math-optimizations.  */
+/* { dg-require-effective-target inf } */
 /* { dg-options "-funsafe-math-optimizations" { target powerpc*-*-* } } */
 
 extern void link_error(int);
Index: gcc.dg/torture/builtin-ldexp-1.c
===
--- gcc.dg/torture/builtin-ldexp-1.c(revision 265728)
+++ gcc.dg/torture/builtin-ldexp-1.c(working copy)
@@ -7,6 +7,7 @@
 
 /* { dg-do link } */
 /* 

[PATCH, testsuite] ignore some "conflicting types for built-in" messages

2018-11-01 Thread Paul Koning
A number of test cases contain declarations like:
  void *memcpy();
which currently are silently accepted on most platforms but not on all; pdp11 
(and possibly some others) generate a "conflicting types for built-in function" 
warning.

It was suggested to prune those messages because the test cases where these 
occur are not looking for the message but are testing some other issue, so the 
message is not relevant.  The attached patch adds dg-prune-output directives to 
do so.

Ok for trunk?

paul

ChangeLog:

2018-11-01  Paul Koning  

* gcc.dg/Walloca-16.c: Ignore conflicting types for built-in
warnings.
* gcc.dg/Wrestrict-4.c: Ditto.
* gcc.dg/Wrestrict-5.c: Ditto.
* gcc.dg/pr83463.c: Ditto.
* gcc.dg/torture/pr55890-2.c: Ditto.
* gcc.dg/torture/pr55890-3.c: Ditto.
* gcc.dg/torture/pr71816.c: Ditto.

Index: gcc.dg/Walloca-16.c
===
--- gcc.dg/Walloca-16.c (revision 265727)
+++ gcc.dg/Walloca-16.c (working copy)
@@ -1,5 +1,6 @@
 /* PR tree-optimization/84224 */
 /* { dg-do compile } */
+/* { dg-prune-output "conflicting types for built-in" } */
 /* { dg-options "-O0 -Walloca" } */
 
 void *alloca ();
Index: gcc.dg/Wrestrict-4.c
===
--- gcc.dg/Wrestrict-4.c(revision 265727)
+++ gcc.dg/Wrestrict-4.c(working copy)
@@ -3,6 +3,7 @@
Test to verify that invalid calls to built-in functions declared
without a prototype don't cause an ICE.
{ dg-do compile }
+   { dg-prune-output "conflicting types for built-in" }
{ dg-options "-O2 -Warray-bounds -Wrestrict" } */
 
 void* memcpy ();
Index: gcc.dg/Wrestrict-5.c
===
--- gcc.dg/Wrestrict-5.c(revision 265727)
+++ gcc.dg/Wrestrict-5.c(working copy)
@@ -2,6 +2,7 @@
functions declared with no prototype are checked for overlap, and that
invalid calls are ignored.
   { dg-do compile }
+  { dg-prune-output "conflicting types for built-in" }
   { dg-options "-O2 -Wrestrict" }  */
 
 typedef __SIZE_TYPE__ size_t;
Index: gcc.dg/pr83463.c
===
--- gcc.dg/pr83463.c(revision 265727)
+++ gcc.dg/pr83463.c(working copy)
@@ -1,5 +1,6 @@
 /* PR middle-end/83463 */
 /* { dg-do compile } */
+/* { dg-prune-output "conflicting types for built-in" } */
 /* { dg-options "-O2 -Wrestrict -Wno-pointer-to-int-cast" } */
 
 int *a;
Index: gcc.dg/torture/pr55890-2.c
===
--- gcc.dg/torture/pr55890-2.c  (revision 265727)
+++ gcc.dg/torture/pr55890-2.c  (working copy)
@@ -1,4 +1,5 @@
 /* { dg-do compile } */
+/* { dg-prune-output "conflicting types for built-in" } */
 
 extern void *memcpy();
 int main() { memcpy(); }
Index: gcc.dg/torture/pr55890-3.c
===
--- gcc.dg/torture/pr55890-3.c  (revision 265727)
+++ gcc.dg/torture/pr55890-3.c  (working copy)
@@ -1,4 +1,5 @@
 /* { dg-do compile } */
+/* { dg-prune-output "conflicting types for built-in" } */
 
 void *memmove ();
 
Index: gcc.dg/torture/pr71816.c
===
--- gcc.dg/torture/pr71816.c(revision 265727)
+++ gcc.dg/torture/pr71816.c(working copy)
@@ -1,4 +1,5 @@
 /* { dg-do compile } */
+/* { dg-prune-output "conflicting types for built-in" } */
 
 void *ext2fs_resize_mem_p;
 struct ext2_icount_el {



[PATCH, testsuite] test case fixes for pdp11

2018-11-01 Thread Paul Koning
This patch fixes a number of test case failures on pdp11.  Some are too large 
for the address space, some have dependencies on the float format that don't 
match the DEC format, some add pdp11 to the targets that expect particular 
compiler messages.

Committed.

paul

ChangeLog:

2018-11-01  Paul Koning  

* gcc.c-torture/execute/20010904-1.c: Align 2 if pdp11.
* gcc.c-torture/execute/20010904-2.c: Ditto.
* c-c++-common/builtin-arith-overflow-2.c: Skip if pdp11.
* gcc.dg/Walloc-size-larger-than-4.c: Ditto.
* gcc.dg/Walloc-size-larger-than-5.c: Ditto.
* gcc.dg/Walloc-size-larger-than-6.c: Ditto.
* gcc.dg/Walloc-size-larger-than-7.c: Ditto.
* gcc.dg/Walloca-14.c: Ditto.
* gcc.dg/Wlarger-than3.c: Ditto.
* gcc.dg/compat/pr83487-1_y.c: Ditto.
* gcc.dg/compat/struct-by-value-2_x.c: Ditto.
* gcc.dg/compat/struct-by-value-3_x.c: Ditto.
* gcc.dg/compat/struct-by-value-4_x.c: Ditto.
* gcc.dg/compat/struct-by-value-5b_x.c: Ditto.
* gcc.dg/compat/struct-by-value-6b_x.c: Ditto.
* gcc.dg/compat/struct-by-value-7b_x.c: Ditto.
* gcc.dg/compat/struct-by-value-8_x.c: Ditto.
* gcc.dg/compat/struct-by-value-9_x.c: Ditto.
* gcc.dg/compat/struct-by-value-10_x.c: Ditto.
* gcc.dg/compat/struct-by-value-11_x.c: Ditto.
* gcc.dg/compat/struct-by-value-12_x.c: Ditto.
* gcc.dg/compat/struct-by-value-13_x.c: Ditto.
* gcc.dg/compat/struct-by-value-14_x.c: Ditto.
* gcc.dg/compat/struct-by-value-15_x.c: Ditto.
* gcc.dg/compat/struct-by-value-16_x.c: Ditto.
* gcc.dg/compat/struct-by-value-17_x.c: Ditto.
* gcc.dg/compat/struct-by-value-18_x.c: Ditto.
* gcc.dg/compat/struct-by-value-22_x.c: Ditto.
* gcc.dg/compat/struct-return-2_x.c: Ditto.
* gcc.dg/falign-labels-1.c: Ditto.
* gcc.dg/long_branch.c: Ditto.
* gcc.dg/nextafter-1.c: Ditto.
* gcc.dg/pr35045.c: Ditto.
* gcc.dg/pr48616.c: Ditto.
* gcc.dg/pr84100.c: Ditto.
* gcc.dg/tree-ssa/builtin-sprintf-9.c: Ditto.
* gcc.dg/tree-ssa/builtin-sprintf-warn-10.c: Ditto.
* gcc.dg/tree-ssa/builtin-sprintf.c: Ditto.
* gcc.dg/Wattributes-10.c: Expect error if pdp11.
* gcc.dg/attr-alloc_size-11.c: Don't XFAIL if pdp11.
* gcc.dg/builtin-inf-1.c: Add pdp11 to warnings about INF.
* gcc.dg/builtins-1.c: Ditto.

Index: gcc.c-torture/execute/20010904-1.c
===
--- gcc.c-torture/execute/20010904-1.c  (revision 265727)
+++ gcc.c-torture/execute/20010904-1.c  (working copy)
@@ -1,4 +1,12 @@
-typedef struct x { int a; int b; } __attribute__((aligned(32))) X;
+/* If some target has a Max alignment less than 32, please create
+   a #ifdef around the alignment and add your alignment.  */
+#ifdef __pdp11__
+#define alignment 2
+#else
+#define alignment 32
+#endif
+
+typedef struct x { int a; int b; } __attribute__((aligned(alignment))) X;
 typedef struct y { X x[32]; int c; } Y;
 
 Y y[2];
Index: gcc.c-torture/execute/20010904-2.c
===
--- gcc.c-torture/execute/20010904-2.c  (revision 265727)
+++ gcc.c-torture/execute/20010904-2.c  (working copy)
@@ -1,4 +1,12 @@
-typedef struct x { int a; int b; } __attribute__((aligned(32))) X;
+/* If some target has a Max alignment less than 32, please create
+   a #ifdef around the alignment and add your alignment.  */
+#ifdef __pdp11__
+#define alignment 2
+#else
+#define alignment 32
+#endif
+
+typedef struct x { int a; int b; } __attribute__((aligned(aligned))) X;
 typedef struct y { X x; X y[31]; int c; } Y;
 
 Y y[2];
Index: c-c++-common/builtin-arith-overflow-2.c
===
--- c-c++-common/builtin-arith-overflow-2.c (revision 265727)
+++ c-c++-common/builtin-arith-overflow-2.c (working copy)
@@ -1,7 +1,7 @@
 /* PR c/68120 - can't easily deal with integer overflow at compile time */
 /* { dg-do run } */
 /* { dg-additional-options "-Wno-long-long" } */
-/* { dg-skip-if "Program too big" { "avr-*-*" } } */
+/* { dg-skip-if "Program too big" { "avr-*-* pdp11*-*-*" } } */
 
 #define SCHAR_MAX__SCHAR_MAX__
 #define SHRT_MAX __SHRT_MAX__
Index: gcc.dg/Walloc-size-larger-than-4.c
===
--- gcc.dg/Walloc-size-larger-than-4.c  (revision 265727)
+++ gcc.dg/Walloc-size-larger-than-4.c  (working copy)
@@ -1,5 +1,6 @@
 /* PR middle-end/82063 - issues with arguments enabled by -Wall
{ dg-do compile }
+   { dg-skip-if "small address space" { "pdp11-*-*" } }
{ dg-options "-O -Walloc-size-larger-than=1MiB -ftrack-macro-expansion=0" } 
*/
 
 void sink (void*);
Index: gcc.dg/Walloc-size-larger-than-5.c
=

[PATCH] libgcc build fix for pdp11

2018-11-01 Thread Paul Koning
This fixes some test suite failures due to a missing arithmetic support routine.

Committed.

paul

ChangeLog:

2018-11-01  Paul Koning  

* config/pdp11/t-pdp11 (LIB2ADD): Add divmod.c.
(HOST_LIBGCC2_CFLAGS): Change to optimize for size.

Index: config/pdp11/t-pdp11
===
--- config/pdp11/t-pdp11(revision 265725)
+++ config/pdp11/t-pdp11(working copy)
@@ -1,4 +1,5 @@
-LIB2ADD = $(srcdir)/udivmod.c \
+LIB2ADD = $(srcdir)/divmod.c \
+ $(srcdir)/udivmod.c \
  $(srcdir)/udivmodsi4.c \
  $(srcdir)/udivhi3.c \
  $(srcdir)/udivmodhi4.c \
@@ -7,4 +8,5 @@
  $(srcdir)/memmove.c \
  $(srcdir)/memset.c
 
-HOST_LIBGCC2_CFLAGS += -O2
+# Small machine, optimize for size
+HOST_LIBGCC2_CFLAGS += -Os



Re: dg-add-options ieee ?

2018-10-31 Thread Paul Koning



> On Oct 31, 2018, at 5:47 PM, Joseph Myers  wrote:
> 
> On Wed, 31 Oct 2018, Paul Koning wrote:
> 
>> So you mean, add a new keyword (say, "ieee") to dg-effective-target that 
>> means "run this test only on ieee targets"?
> 
> Note that different tests may need different IEEE features, though some 
> such cases are already handled specially anyway - so be clear on what 
> target properties such a keyword actually relates to.  (E.g. 
> fenv_exceptions already exists for tests needing floating-point 
> exceptions; tests that don't work on SPU because of the way its 
> single-precision format deviates from IEEE are skipped specifically for 
> spu-*-*; tests handling IBM long double specially as needed.)
> 
> -- 
> Joseph S. Myers
> jos...@codesourcery.com

I can add a general "ieee" test.  I've also found some test cases that depend 
on things like the width of exponent and mantissa, and are written to match 
what IEEE does.  They may well be valid for some other float formats, so saying 
they require IEEE might not be the best answer.  For example 
gcc.dg/tree-ssa/sprintf-warn-10.c which has checks like this:
  T1 ("%.*a", 0); /* { dg-warning "between 3 and 10 bytes" } */

Many of those numbers come out different on pdp11, partly because it's a 16 bit 
platform (so the upper bound is never > 32767) and partly because the float 
format has different field widths than IEEE.

Another case is tests that refer to infinite, which some float formats don't 
have.  Or "not a number"; pdp11 has some flavors of that but not all that IEEE 
has.  Should I try to add various other float features, like "infinite", "nan", 
"quiet-nan", "signaling-nan"?

Given Rainer's comment that dg-effective-target ieee and dg-add-options ieee 
should be separate, should I add dg-effective-target ieee to every test that 
currently says dg-add-options ieee?  Or leave that for others to do 
selectively?  It feels like it can be applied everywhere, but I may be missing 
something.

paul



Re: dg-add-options ieee ?

2018-10-31 Thread Paul Koning



> On Oct 31, 2018, at 4:11 PM, Rainer Orth  
> wrote:
> 
> Hi Paul,
> 
>> Ok, thanks.  So adding a dg-skip-if for my target is indeed correct.  Will 
>> do so.
> 
> please don't: since this is going to be common, please add a
> corresponding effective-target keyword instead, together with
> sourcebuild.texi documentation.  That's far more expressive than
> explicit target lists.
> 
> Thanks.
>Rainer

So you mean, add a new keyword (say, "ieee") to dg-effective-target that means 
"run this test only on ieee targets"?

Another approach might be to have dg-add-options ieee mean what it does today, 
but also have it skip the test for non-ieee capable targets.  Or is that 
undesirable because it muddles the meaning of the dg-add-options keyword?  I 
figure it would make sense because any test that has dg-add-options ieee by 
definition should be skipped by any target that can't do ieee at all.

paul




Re: Builtin mismatch warning

2018-10-31 Thread Paul Koning



> On Oct 31, 2018, at 4:21 PM, Martin Sebor  wrote:
> 
> On 10/31/2018 12:15 PM, Paul Koning wrote:
>> I noticed a curious inconsistency.
>> 
>> Some testcases (like gcc.dg/Wrestrict-4.c) have declarations like this:
>> 
>> void *alloca();
>> void* memcpy ();
>> 
>> Those don't generate warnings in a just built V9.0 gcc for x86.  And the 
>> testcase clearly doesn't expect warnings.
> 
> Wrestrict-4.c is about verifying there is no ICE.  It doesn't check
> for warnings (or expect them) only because GCC doesn't issue them,
> even though it should.  I submitted a patch to enable warnings for
> built-in declarations without a prototype back in June but it wasn't
> been approved:
> 
>  https://gcc.gnu.org/ml/gcc-patches/2018-06/msg01645.html
> 
> I'm still hoping to resuscitate it before the end of stage 1.
> 
>> But I do get a warning (warning: conflicting types for built-in function 
>> ‘memcpy’) when I compile that same code on GCC built for pdp11.  I don't 
>> know why changing the target should affect whether that message appears.
> 
> Apparently because the warning depends on whether arguments to
> such functions are affected by default promotions (determined
> by self_promoting_args_p()) and on pdp11 that isn't the case
> for size_t.  So on pdp11, the type of void* memcpy() isn't
> considered compatible with the type of the built-in function.
> 
> IMO, the warning should be issued regardless of compatibility.
> Function declarations without a prototype have been deprecated
> since C99, and are being considered for removal from C2X.  There
> is no reason for maintained software not to adopt the much safer
> declaration style in general, and certainly not for built-in
> functions.  Even if safety weren't reason enough, declaring
> built-ins with correct prototypes improves the quality of
> generated code: GCC will expand a call like memcpy(d, s, 32)
> inline when the the function is declared with a prototype but
> it declines to do so when it isn't declared with one, because
> the type of 32 doesn't match size_t.
> 
> Martin

Thanks.  So I'm wondering if I should add 
  { dg-warning "conflicting types" "" { "pdp11*-*-*" } }
for now, and then if your patch goes in that simply changes to apply to all 
targets.

paul



Re: dg-add-options ieee ?

2018-10-31 Thread Paul Koning



> On Oct 31, 2018, at 3:55 PM, Segher Boessenkool  
> wrote:
> 
> On Wed, Oct 31, 2018 at 02:20:38PM -0400, Paul Koning wrote:
>> I see some test cases that say dg-add-options ieee.  That apparently means: 
>> pretend we have IEEE float even when the target does not.
> 
> It means:
> 
> (from testsuite/lib/target-supports.exp)
> 
> ===
> # Add to FLAGS all the target-specific flags needed to enable
> # full IEEE compliance mode.
> 
> ...
> 
> i.e. add those options that make the floating point IEEE compliant.
> If your target cannot do that, it should skip the tests that need IEEE float
> (and if it can do it, but it is (possibly) not the default, code needs to
> be added here for your target).
> 
>> ...
> 
> On some targets IEEE float is not the default, but those targets can still
> do it if you pass certain options.
> 
> 
> Segher

Ok, thanks.  So adding a dg-skip-if for my target is indeed correct.  Will do 
so.

paul



dg-add-options ieee ?

2018-10-31 Thread Paul Koning
I see some test cases that say dg-add-options ieee.  That apparently means: 
pretend we have IEEE float even when the target does not.

What is the point of doing that?  On non-IEEE targets such test cases fail -- 
at least they do on pdp11.  Instead I'd expect a check that skips these tests 
if not IEEE.  There is a subdirectory for IEEE tests under gcc.c-torture, 
though not under gcc.dg.

I can just put a target specific dg-skip-if in these files, but I'm curious why 
dg-add-options was used.

paul



Builtin mismatch warning

2018-10-31 Thread Paul Koning
I noticed a curious inconsistency.

Some testcases (like gcc.dg/Wrestrict-4.c) have declarations like this:

void *alloca();
void* memcpy ();

Those don't generate warnings in a just built V9.0 gcc for x86.  And the 
testcase clearly doesn't expect warnings.

But I do get a warning (warning: conflicting types for built-in function 
‘memcpy’) when I compile that same code on GCC built for pdp11.  I don't know 
why changing the target should affect whether that message appears.

paul



Re: Ping: [PATCH, testsuite]: check for weak support

2018-10-30 Thread Paul Koning



> On Oct 30, 2018, at 10:17 AM, Jeff Law  wrote:
> 
> On 10/30/18 6:55 AM, Paul Koning wrote:
>> Ping.  Ok to commit?
>> 
>>  paul
>> 
>>> On Oct 25, 2018, at 2:57 PM, Paul Koning  wrote:
>>> 
>>> I ran into a failures due to no weak symbol support in my target.  This 
>>> patch cures that.  Is it right?  The test case uses "weakref" so I' not 
>>> 100% sure that checking for "weak" support is correct.  If not, I can put 
>>> in a skip-if check for the target (pdp11) instead.
>>> 
>>> paul
>>> 
>>> ChangeLog:
>>> 
>>> 2018-10-25  Paul Koning  
>>> 
>>> * gcc.dg/tree-ssa/attr-alias.c: Skip if no weak support.
> OK.  This would fall under the obvious rule IMHO.  There's a "weak"
> attribute so clearly the test needs to require weak support :-)
> 
> jeff

Thanks.  Committed.

paul



Ping: [PATCH, testsuite]: check for weak support

2018-10-30 Thread Paul Koning
Ping.  Ok to commit?

paul

> On Oct 25, 2018, at 2:57 PM, Paul Koning  wrote:
> 
> I ran into a failures due to no weak symbol support in my target.  This patch 
> cures that.  Is it right?  The test case uses "weakref" so I' not 100% sure 
> that checking for "weak" support is correct.  If not, I can put in a skip-if 
> check for the target (pdp11) instead.
> 
>   paul
> 
> ChangeLog:
> 
> 2018-10-25  Paul Koning  
> 
>   * gcc.dg/tree-ssa/attr-alias.c: Skip if no weak support.
> 
> Index: testsuite/gcc.dg/tree-ssa/attr-alias.c
> ===
> --- testsuite/gcc.dg/tree-ssa/attr-alias.c(revision 265404)
> +++ testsuite/gcc.dg/tree-ssa/attr-alias.c(working copy)
> @@ -1,5 +1,6 @@
> /* { dg-do compile } */
> /* { dg-require-alias "" } */
> +/* { dg-require-weak "" } */
> /* { dg-options "-O2 -fdump-tree-optimized -std=gnu89" } */
> void abort (void);
> __attribute__ ((weak))
> 



Re: "aligned" attribute with too-large argument

2018-10-29 Thread Paul Koning



> On Oct 29, 2018, at 4:08 PM, Martin Sebor  wrote:
> 
> On 10/29/2018 09:19 AM, Paul Koning wrote:
>> 
>> 
>>> On Oct 29, 2018, at 10:54 AM, Martin Sebor  wrote:
>>> 
>>> On 10/29/2018 07:45 AM, Paul Koning wrote:
>>>> I noticed an inconsistency in the handling of the aligned attribute.  When 
>>>> applied to variables, I get an error message if the alignment is too large 
>>>> for the platform.  But when applied to functions, there is no error check. 
>>>>  The same applies to label alignment (from the -falign-labels switch).
>>>> 
>>>> The result is an ICE in my target code because it is asked to output 
>>>> assembly language for an alignment not supported by the target.
>>>> 
>>>> Should these cases also produce error messages?  Or should the back end 
>>>> ignore attempts to align too much?
>>> 
>>> check_user_alignment() in c-attribs.c rejects excessive alignments
>>> the same for functions and variables:
>>> 
>>> else if (i >= HOST_BITS_PER_INT - LOG2_BITS_PER_UNIT)
>>>  {
>>>error ("requested alignment is too large");
>>>return -1;
>>>  }
>>> 
>>> so I don't immediately see where this inconsistency comes from
>>> Is there different/more restrictive handling for variables in
>>> the back end? (a test case would be great).
>> 
>> I forgot to attach it.  Here it is.
> 
> I don't see any errors with the test case on x86_64.  In GDB I see
> the alignment for ag is 524288 and MAX_OFILE_ALIGNMENT is 2147483648.
> What target do you see the error with?
> 
> Martin

There are two related issues.

One is that GCC says the max alignment for variables on x86 is 32768 
(MAX_OFILE_ALIGNMENT is 32768).  And it enforces that, for variables.  But a 
request to align a function to 65536 is permitted.  Since the assembler doesn't 
actually complain, no errors appear.

On pdp11, MAX_OFILE_ALIGNMENT is 2.  So in the test file I sent, the aligned(2) 
entries are legal and the others are not.  Since the target doesn't know how to 
generate assembly code for alignment greater than 2, the overly aligned 
function results in an ICE.  But the overly aligned variables generate error 
messages, as expected.

What I want is for function and label alignment to honor MAX_OFILE_ALIGNMENT.  
The only alternative is to silently ignore excessive function alignment in the 
target code.

paul



[PATCH, doc] Fix CONST_WIDE_INT_ELT

2018-10-29 Thread Paul Koning
The description of CONST_WIDE_INT_ELT gave the macro's name as 
CONST_WIDE_INT_NUNITS instead.

Committed as obvious.

paul

ChangeLog:

2018-10-29  Paul Koning  

* doc/rtl.texi (CONST_WIDE_INT_ELT): Give correct macro name.

Index: doc/rtl.texi
===
--- doc/rtl.texi(revision 265601)
+++ doc/rtl.texi(working copy)
@@ -1732,7 +1732,7 @@ Note that this generally is smaller than the numbe
 @code{HOST_WIDE_INT}s implied by the mode size.
 
 @findex CONST_WIDE_INT_ELT
-@item CONST_WIDE_INT_NUNITS (@var{code},@var{i})
+@item CONST_WIDE_INT_ELT (@var{code},@var{i})
 Returns the @code{i}th element of the array.   Element 0 is contains
 the low order bits of the constant.
 



Re: "aligned" attribute with too-large argument

2018-10-29 Thread Paul Koning



> On Oct 29, 2018, at 11:18 AM, Paul Koning  wrote:
> 
> ...
> 
>> That said, attribute problems aren't handled perfectly consistently
>> in GCC.  Some result in errors, others in warnings, and some are
>> silently ignored.  I've been tracking the problems I notice in
>> Bugzilla (those with "aligned" in their title are: 87524, 84185,
>> 82914, 81566, 69502, 65055, 61939).  In my view, silently ignoring
>> problems without as much as a warning is a bug.  But whether they
>> should result in warnings or errors can be debated on a case by
>> case basis.  For instance, it might be appropriate to give
>> an error when a negative alignment is specified but just a warning
>> when the specified alignment is less than the minimum for the symbol
>> for the target.  For the case you mention I think an argument could
>> be for either, but given the check_user_alignment handling I'd say
>> an error would seem to be in line with the current practice.
>> 
>> Martin
> 
> Ok, I'll enter a PR. 

Done.  https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87795

paul




Re: "aligned" attribute with too-large argument

2018-10-29 Thread Paul Koning


> On Oct 29, 2018, at 10:54 AM, Martin Sebor  wrote:
> 
> On 10/29/2018 07:45 AM, Paul Koning wrote:
>> I noticed an inconsistency in the handling of the aligned attribute.  When 
>> applied to variables, I get an error message if the alignment is too large 
>> for the platform.  But when applied to functions, there is no error check.  
>> The same applies to label alignment (from the -falign-labels switch).
>> 
>> The result is an ICE in my target code because it is asked to output 
>> assembly language for an alignment not supported by the target.
>> 
>> Should these cases also produce error messages?  Or should the back end 
>> ignore attempts to align too much?
> 
> check_user_alignment() in c-attribs.c rejects excessive alignments
> the same for functions and variables:
> 
> else if (i >= HOST_BITS_PER_INT - LOG2_BITS_PER_UNIT)
>   {
> error ("requested alignment is too large");
> return -1;
>   }
> 
> so I don't immediately see where this inconsistency comes from
> Is there different/more restrictive handling for variables in
> the back end? (a test case would be great).

I forgot to attach it.  Here it is.

paul



testalign.c
Description: Binary data




Re: "aligned" attribute with too-large argument

2018-10-29 Thread Paul Koning



> On Oct 29, 2018, at 10:54 AM, Martin Sebor  wrote:
> 
> On 10/29/2018 07:45 AM, Paul Koning wrote:
>> I noticed an inconsistency in the handling of the aligned attribute.  When 
>> applied to variables, I get an error message if the alignment is too large 
>> for the platform.  But when applied to functions, there is no error check.  
>> The same applies to label alignment (from the -falign-labels switch).
>> 
>> The result is an ICE in my target code because it is asked to output 
>> assembly language for an alignment not supported by the target.
>> 
>> Should these cases also produce error messages?  Or should the back end 
>> ignore attempts to align too much?
> 
> check_user_alignment() in c-attribs.c rejects excessive alignments
> the same for functions and variables:
> 
>  else if (i >= HOST_BITS_PER_INT - LOG2_BITS_PER_UNIT)
>{
>  error ("requested alignment is too large");
>  return -1;
>}

Yes, but that code merely verifies that the requested alignment can be 
represented on the host doing the compiling.

> so I don't immediately see where this inconsistency comes from
> Is there different/more restrictive handling for variables in
> the back end? (a test case would be great).

The error I get for variables comes from varasm.c, align_variable:

  if (align > MAX_OFILE_ALIGNMENT)
{
  error ("alignment of %q+D is greater than maximum object "
 "file alignment %d", decl,
 MAX_OFILE_ALIGNMENT/BITS_PER_UNIT);
  align = MAX_OFILE_ALIGNMENT;
}

There are some other references to MAX_OFILE_ALIGNMENT, but they all seem to be 
related to variables.  I would think that the same check should also be applied 
to other objects that are mentioned in the output file, specifically code 
(functions and labels).  

I'll attach a test case.  On Intel, the max alignment is 32768 so the 
declaration of variable "ag" fails on the above error check.  But if I comment 
out that line, the function alignment is silently accepted and generates the 
corresponding assembly file directive (".align 16").  And the assembler accepts 
that because apparently 64k alignment IS allowed...

> That said, attribute problems aren't handled perfectly consistently
> in GCC.  Some result in errors, others in warnings, and some are
> silently ignored.  I've been tracking the problems I notice in
> Bugzilla (those with "aligned" in their title are: 87524, 84185,
> 82914, 81566, 69502, 65055, 61939).  In my view, silently ignoring
> problems without as much as a warning is a bug.  But whether they
> should result in warnings or errors can be debated on a case by
> case basis.  For instance, it might be appropriate to give
> an error when a negative alignment is specified but just a warning
> when the specified alignment is less than the minimum for the symbol
> for the target.  For the case you mention I think an argument could
> be for either, but given the check_user_alignment handling I'd say
> an error would seem to be in line with the current practice.
> 
> Martin

Ok, I'll enter a PR. 

paul




"aligned" attribute with too-large argument

2018-10-29 Thread Paul Koning
I noticed an inconsistency in the handling of the aligned attribute.  When 
applied to variables, I get an error message if the alignment is too large for 
the platform.  But when applied to functions, there is no error check.  The 
same applies to label alignment (from the -falign-labels switch).

The result is an ICE in my target code because it is asked to output assembly 
language for an alignment not supported by the target.

Should these cases also produce error messages?  Or should the back end ignore 
attempts to align too much?

paul



INTVAL type

2018-10-28 Thread Paul Koning
I was reviewing some back end code that handles integer values of various 
sizes, and got confused reading about CONST_INT and CONST_DOUBLE.

It's pretty clear that CONST_DOUBLE is used for values bigger than 
HOST_WIDE_INT.  But the description of INTVAL is contradictory.  In some 
places, it states that its type is HOST_WIDE_INT; in others it says that it it 
"int".  For example, in section 17.6 of the internals manual:

Be careful when doing this, because the result of INTVAL is an integer on the 
host machine. If the host machine has more bits in an int than the target 
machine has in the mode in which the constant will be used, then some of the 
bits you get from INTVAL will be superfluous.

A related problem is that it isn't clearly stated what the properties of 
HOST_WIDE_INT are.  Judging by hwint.h, it is always specifically a 64 bit 
integer.  If that is intended to be the case, it would be good for that to be 
documented.  Alternatively, if the intent is that it is at least 64 bits but 
might be bigger, that should be stated.  As it stands, I have some code I need 
to repair because it picks apart integer constants from INTVAL in a way that's 
incorrect if a 64-bit value is passed.

paul



cmpsi2 library calls?

2018-10-25 Thread Paul Koning
In my target (pdp11) which has 16 bit words, I see some test suite failures 
because of unresolved references to __cmpsi2.  The strange thing is that most 
of the time 32 bit compares are expanded by GCC into a sequence of word 
compares and branches.

Why would GCC sometimes generate library calls for this?  Can I make it stop 
doing that by writing patterns (define_expand or define_insn) for cmpsi2?  That 
may be useful because I think I can generate better code, but still it's 
puzzling that the behavior is inconsistent.

paul



[PATCH, testsuite]: check for weak support

2018-10-25 Thread Paul Koning
I ran into a failures due to no weak symbol support in my target.  This patch 
cures that.  Is it right?  The test case uses "weakref" so I' not 100% sure 
that checking for "weak" support is correct.  If not, I can put in a skip-if 
check for the target (pdp11) instead.

paul

ChangeLog:

2018-10-25  Paul Koning  

* gcc.dg/tree-ssa/attr-alias.c: Skip if no weak support.

Index: testsuite/gcc.dg/tree-ssa/attr-alias.c
===
--- testsuite/gcc.dg/tree-ssa/attr-alias.c  (revision 265404)
+++ testsuite/gcc.dg/tree-ssa/attr-alias.c  (working copy)
@@ -1,5 +1,6 @@
 /* { dg-do compile } */
 /* { dg-require-alias "" } */
+/* { dg-require-weak "" } */
 /* { dg-options "-O2 -fdump-tree-optimized -std=gnu89" } */
 void abort (void);
 __attribute__ ((weak))



Re: Trying to debug a testsuite failure

2018-10-23 Thread Paul Koning



> On Oct 23, 2018, at 6:08 AM, Richard Biener  
> wrote:
> 
> On Tue, Oct 23, 2018 at 2:39 AM Paul Koning  wrote:
>> 
>> In running the gcc testsuite on pdp11, I get some failures like this:
>> 
>> collect2: fatal error: /Users/pkoning/Documents/svn/buildpdp/gcc/nm returned 
>> 1 exit status
>> compilation terminated.
>> compiler exited with status 1
>> FAIL: gcc.c-torture/execute/builtins/memcpy-chk.c compilation,  -O3 
>> -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions
>> 
>> While those tests flags are not terribly useful on a small memory platform 
>> like pdp11, I wouldn't expect a failure like that.  Some tests with those 
>> flags do pass.
>> 
>> The real issue is that collect2 is apparently failing for no visible reason 
>> and without any helpful explanation of what it's trying to do.  Any hints on 
>> how I might debug this?
> 
> Try with -Wl,-debug -Wl,-v but then it already tells you that nm
> failed somehow.  So possibly debug
> that via strace -f?
> 
> Richard.

Found the problem.  By default (without a suitable linker script) the linker 
does not report memory overflow.  The failing cases are all programs too large 
to fit in the 16 bit address space of the target.  

I changed the board file to specify a linker script with explicit memory 
bounds, and a torture options override that omits the -O3 variants.  Now I get 
sane results.

Thanks,

paul



Trying to debug a testsuite failure

2018-10-22 Thread Paul Koning
In running the gcc testsuite on pdp11, I get some failures like this:

collect2: fatal error: /Users/pkoning/Documents/svn/buildpdp/gcc/nm returned 1 
exit status
compilation terminated.
compiler exited with status 1
FAIL: gcc.c-torture/execute/builtins/memcpy-chk.c compilation,  -O3 
-fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions 

While those tests flags are not terribly useful on a small memory platform like 
pdp11, I wouldn't expect a failure like that.  Some tests with those flags do 
pass.

The real issue is that collect2 is apparently failing for no visible reason and 
without any helpful explanation of what it's trying to do.  Any hints on how I 
might debug this?

paul



[PATCH] correct max alignment check in symtab.c

2018-10-22 Thread Paul Koning
GCC was hitting an ICE on some pdp11 tests due to a typo in a max alignment 
check.

Committed as obvious.

paul

ChangeLog:

2018-10-22  Paul Koning  

* symtab.c (symtab_node::increase_alignment): Correct max
alignment check.

Index: symtab.c
===
--- symtab.c(revision 265403)
+++ symtab.c(working copy)
@@ -2205,7 +2205,7 @@ increase_alignment_1 (symtab_node *n, void *v)
 void
 symtab_node::increase_alignment (unsigned int align)
 {
-  gcc_assert (can_increase_alignment_p () && align < MAX_OFILE_ALIGNMENT);
+  gcc_assert (can_increase_alignment_p () && align <= MAX_OFILE_ALIGNMENT);
   ultimate_alias_target()->call_for_symbol_and_aliases (increase_alignment_1,
(void *)(size_t) align,
true);



Re: [PATCH] add udivhi3, umodhi3 functions to libgcc

2018-10-18 Thread Paul Koning



> On Oct 18, 2018, at 1:18 PM, Jeff Law  wrote:
> 
> On 10/17/18 5:48 PM, Paul Koning wrote:
>> This is a revision of a patch I proposed a while back, to add udivhi3 and 
>> umodhi3 functions to libgcc since some platforms (like pdp11) need it.  The 
>> code is adopted from that of udivsi3.
>> 
>> In earlier discussion it was pointed out that internal functions need to 
>> start with __.  The code I had copied does not do that, so I corrected mine 
>> and also changed the existing code to conform to the rules.
>> 
>> Ok for trunk?
>> 
>>  paul
>> 
>> ChangeLog:
>> 
>> 2018-10-17  Paul Koning  
>> 
>>  * udivmodsi4.c (__udivmodsi4): Rename to conform to coding
>>  standard.
>>  * udivmod.c: Update references to __udivmodsi4.
>>  * udivhi3.c: New file.
>>  * udivmodhi4.c: New file.
>>  * config/pdp11/t-pdp11 (LIB2ADD): Add the new files.
> I think you need to fix divmod.c as well since it calls udivmodsi4.  OK
> with that fixed.
> 
> Jeff

Thanks.  Committed as shown below.

paul

ChangeLog:

2018-10-18  Paul Koning  

* udivmodsi4.c (__udivmodsi4): Rename to conform to coding
standard.
* divmod.c: Update references to __udivmodsi4.
* udivmod.c: Ditto.
* udivhi3.c: New file.
* udivmodhi4.c: New file.
* config/pdp11/t-pdp11 (LIB2ADD): Add the new files.

Index: config/pdp11/t-pdp11
===
--- config/pdp11/t-pdp11(revision 265276)
+++ config/pdp11/t-pdp11(working copy)
@@ -1,5 +1,7 @@
 LIB2ADD = $(srcdir)/udivmod.c \
  $(srcdir)/udivmodsi4.c \
+ $(srcdir)/udivhi3.c \
+ $(srcdir)/udivmodhi4.c \
  $(srcdir)/memcmp.c \
  $(srcdir)/memcpy.c \
  $(srcdir)/memmove.c \
Index: divmod.c
===
--- divmod.c(revision 265276)
+++ divmod.c(working copy)
@@ -21,7 +21,8 @@ a copy of the GCC Runtime Library Exception along
 see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
 <http://www.gnu.org/licenses/>.  */
 
-long udivmodsi4 ();
+extern unsigned long __udivmodsi4(unsigned long num, unsigned long den,
+ int 
modwanted);
 
 long
 __divsi3 (long a, long b)
@@ -41,7 +42,7 @@ __divsi3 (long a, long b)
   neg = !neg;
 }
 
-  res = udivmodsi4 (a, b, 0);
+  res = __udivmodsi4 (a, b, 0);
 
   if (neg)
 res = -res;
@@ -64,7 +65,7 @@ __modsi3 (long a, long b)
   if (b < 0)
 b = -b;
 
-  res = udivmodsi4 (a, b, 1);
+  res = __udivmodsi4 (a, b, 1);
 
   if (neg)
 res = -res;
Index: udivhi3.c
===
--- udivhi3.c   (nonexistent)
+++ udivhi3.c   (working copy)
@@ -0,0 +1,38 @@
+/* Copyright (C) 2000-2018 Free Software Foundation, Inc.
+
+This file is part of GCC.
+
+GCC is free software; you can redistribute it and/or modify it under
+the terms of the GNU General Public License as published by the Free
+Software Foundation; either version 3, or (at your option) any later
+version.
+
+GCC is distributed in the hope that it will be useful, but WITHOUT ANY
+WARRANTY; without even the implied warranty of MERCHANTABILITY or
+FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
+for more details.
+
+Under Section 7 of GPL version 3, you are granted additional
+permissions described in the GCC Runtime Library Exception, version
+3.1, as published by the Free Software Foundation.
+
+You should have received a copy of the GNU General Public License and
+a copy of the GCC Runtime Library Exception along with this program;
+see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
+<http://www.gnu.org/licenses/>.  */
+
+extern unsigned short __udivmodhi4(unsigned short num, unsigned short den,
+  int 
modwanted);
+
+unsigned short
+__udivhi3 (unsigned short a, unsigned short b)
+{
+  return __udivmodhi4 (a, b, 0);
+}
+
+unsigned short
+__umodhi3 (unsigned short a, unsigned short b)
+{
+  return __udivmodhi4 (a, b, 1);
+}
+
Index: udivmod.c
===
--- udivmod.c   (revision 265276)
+++ udivmod.c   (working copy)
@@ -21,17 +21,18 @@ a copy of the GCC Runtime Library Exception along
 see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
 <http://www.gnu.org/licenses/>.  */
 
-long udivmodsi4 ();
+extern unsigned long __udivmodsi4(unsigned long num, unsigned long den,
+ int 
modwanted);
 
 long
 __udivsi3 (long a, long b)
 {
-  return udivmodsi4 (a,

Re: [PATCH] add udivhi3, umodhi3 functions to libgcc

2018-10-17 Thread Paul Koning
This is a revision of a patch I proposed a while back, to add udivhi3 and 
umodhi3 functions to libgcc since some platforms (like pdp11) need it.  The 
code is adopted from that of udivsi3.

In earlier discussion it was pointed out that internal functions need to start 
with __.  The code I had copied does not do that, so I corrected mine and also 
changed the existing code to conform to the rules.

Ok for trunk?

paul

ChangeLog:

2018-10-17  Paul Koning  

* udivmodsi4.c (__udivmodsi4): Rename to conform to coding
standard.
* udivmod.c: Update references to __udivmodsi4.
* udivhi3.c: New file.
* udivmodhi4.c: New file.
* config/pdp11/t-pdp11 (LIB2ADD): Add the new files.

Index: config/pdp11/t-pdp11
===
--- config/pdp11/t-pdp11(revision 265151)
+++ config/pdp11/t-pdp11(working copy)
@@ -1,5 +1,7 @@
 LIB2ADD = $(srcdir)/udivmod.c \
  $(srcdir)/udivmodsi4.c \
+ $(srcdir)/udivhi3.c \
+ $(srcdir)/udivmodhi4.c \
  $(srcdir)/memcmp.c \
  $(srcdir)/memcpy.c \
  $(srcdir)/memmove.c \
Index: udivhi3.c
===
--- udivhi3.c   (nonexistent)
+++ udivhi3.c   (working copy)
@@ -0,0 +1,38 @@
+/* Copyright (C) 2000-2018 Free Software Foundation, Inc.
+
+This file is part of GCC.
+
+GCC is free software; you can redistribute it and/or modify it under
+the terms of the GNU General Public License as published by the Free
+Software Foundation; either version 3, or (at your option) any later
+version.
+
+GCC is distributed in the hope that it will be useful, but WITHOUT ANY
+WARRANTY; without even the implied warranty of MERCHANTABILITY or
+FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
+for more details.
+
+Under Section 7 of GPL version 3, you are granted additional
+permissions described in the GCC Runtime Library Exception, version
+3.1, as published by the Free Software Foundation.
+
+You should have received a copy of the GNU General Public License and
+a copy of the GCC Runtime Library Exception along with this program;
+see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
+<http://www.gnu.org/licenses/>.  */
+
+extern unsigned short __udivmodhi4(unsigned short num, unsigned short den,
+  int 
modwanted);
+
+unsigned short
+__udivhi3 (unsigned short a, unsigned short b)
+{
+  return __udivmodhi4 (a, b, 0);
+}
+
+unsigned short
+__umodhi3 (unsigned short a, unsigned short b)
+{
+  return __udivmodhi4 (a, b, 1);
+}
+
Index: udivmod.c
===
--- udivmod.c   (revision 265151)
+++ udivmod.c   (working copy)
@@ -21,17 +21,18 @@ a copy of the GCC Runtime Library Exception along
 see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
 <http://www.gnu.org/licenses/>.  */
 
-long udivmodsi4 ();
+extern unsigned long __udivmodsi4(unsigned long num, unsigned long den,
+ int 
modwanted);
 
 long
 __udivsi3 (long a, long b)
 {
-  return udivmodsi4 (a, b, 0);
+  return __udivmodsi4 (a, b, 0);
 }
 
 long
 __umodsi3 (long a, long b)
 {
-  return udivmodsi4 (a, b, 1);
+  return __udivmodsi4 (a, b, 1);
 }
 
Index: udivmodhi4.c
===
--- udivmodhi4.c(nonexistent)
+++ udivmodhi4.c(working copy)
@@ -0,0 +1,47 @@
+/* Copyright (C) 2000-2018 Free Software Foundation, Inc.
+
+This file is part of GCC.
+
+GCC is free software; you can redistribute it and/or modify it under
+the terms of the GNU General Public License as published by the Free
+Software Foundation; either version 3, or (at your option) any later
+version.
+
+GCC is distributed in the hope that it will be useful, but WITHOUT ANY
+WARRANTY; without even the implied warranty of MERCHANTABILITY or
+FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
+for more details.
+
+Under Section 7 of GPL version 3, you are granted additional
+permissions described in the GCC Runtime Library Exception, version
+3.1, as published by the Free Software Foundation.
+
+You should have received a copy of the GNU General Public License and
+a copy of the GCC Runtime Library Exception along with this program;
+see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
+<http://www.gnu.org/licenses/>.  */
+
+unsigned short
+__udivmodhi4(unsigned short num, unsigned short den, int modwanted)
+{
+  unsigned short bit = 1;
+  unsigned short res = 0;
+
+  while (den < num && bit && !(den & (1L<<31)))
+{
+  den <<=1;
+  bit <<=1;
+}
+  while (bit)
+{
+  if (num >= den)
+   {
+ num -= den;
+ res |= bit;
+   }
+  

[PATCH, pdp11] fix problem with doloop_end

2018-10-12 Thread Paul Koning
For some newlib sources, pdp11 doloop_end was creating problems because it was 
handed a QImode operand when it only wants HImode.  This patch cures that, and 
also adds addqi3 and subqi3 patterns to help with that case.

Committed.

paul

ChangeLog:

2018-10-12  Paul Koning  

* config/pdp11/pdp11.md (doloop_end): New expander.
(doloop_end_insn): renamed from "doloop_end".
(addqi3): New pattern.
(subqi3): New pattern.
* config/pdp11/predicates.md (incdec_operand): New predicate.

Index: config/pdp11/predicates.md
===
--- config/pdp11/predicates.md  (revision 265131)
+++ config/pdp11/predicates.md  (revision 265132)
@@ -30,6 +30,14 @@
   (and (match_code "const_int")
(match_test "(unsigned) INTVAL (op) < 4")))
 
+;; Accept integer arguments +1 and -1, for which add and sub can be
+;; done as inc or dec instructions.  This matches the rule for the
+;; L and M constraints.
+(define_predicate "incdec_operand"
+  (and (match_code "const_int")
+   (ior (match_test "INTVAL (op) == -1")
+   (match_test "INTVAL (op) == 1"
+
 ;; Accept anything general_operand accepts, except that registers must
 ;; be FPU registers.
 (define_predicate "float_operand"
Index: config/pdp11/pdp11.md
===
--- config/pdp11/pdp11.md   (revision 265131)
+++ config/pdp11/pdp11.md   (revision 265132)
@@ -251,9 +251,28 @@
 
 ;; sob instruction
 ;;
-;; Do a define_expand because some alternatives clobber CC.
+;; This expander has to check for mode match because the doloop pass
+;; in gcc that invokes it does not do so, i.e., it may attempt to apply
+;; this pattern even if the count operand is QI or SI mode.
+(define_expand "doloop_end"
+  [(parallel [(set (pc)
+  (if_then_else
+   (ne (match_operand:HI 0 "nonimmediate_operand" "+r,!m")
+   (const_int 1))
+   (label_ref (match_operand 1 "" ""))
+   (pc)))
+ (set (match_dup 0)
+  (plus:HI (match_dup 0)
+(const_int -1)))])]
+  "TARGET_40_PLUS"
+  "{
+if (GET_MODE (operands[0]) != HImode)
+  FAIL;
+  }")
+
+;; Do a define_split because some alternatives clobber CC.
 ;; Some don't, but it isn't all that interesting to cover that case.
-(define_insn_and_split "doloop_end"
+(define_insn_and_split "doloop_end_insn"
   [(set (pc)
(if_then_else
 (ne (match_operand:HI 0 "nonimmediate_operand" "+r,!m")
@@ -1067,6 +1086,35 @@
 }"
   [(set_attr "length" "2,4,4,6")])
 
+(define_insn_and_split "addqi3"
+  [(set (match_operand:QI 0 "nonimmediate_operand" "=rR,Q")
+   (plus:QI (match_operand:QI 1 "general_operand" "%0,0")
+(match_operand:QI 2 "incdec_operand" "LM,LM")))]
+  ""
+  "#"
+  "reload_completed"
+  [(parallel [(set (match_dup 0)
+  (plus:QI (match_dup 1) (match_dup 2)))
+ (clobber (reg:CC CC_REGNUM))])]
+  ""
+  [(set_attr "length" "2,4")])
+
+;; Inc/dec sets V if overflow from the operation
+(define_insn "*addqi3"
+  [(set (match_operand:QI 0 "nonimmediate_operand" "=rR,Q")
+   (plus:QI (match_operand:QI 1 "general_operand" "%0,0")
+(match_operand:QI 2 "incdec_operand" "LM,LM")))
+   (clobber (reg:CC CC_REGNUM))]
+  "reload_completed"
+  "*
+{
+  if (INTVAL(operands[2]) == 1)
+return \"incb\t%0\";
+  else
+return \"decb\t%0\";
+}"
+  [(set_attr "length" "2,4")])
+
 

 ;;- subtract instructions
 ;; we don't have to care for constant second 
@@ -1226,6 +1274,35 @@
 }"
   [(set_attr "length" "2,4,4,6")])
 
+(define_insn_and_split "subqi3"
+  [(set (match_operand:QI 0 "nonimmediate_operand" "=rR,Q")
+   (plus:QI (match_operand:QI 1 "general_operand" "%0,0")
+(match_operand:QI 2 "incdec_operand" "LM,LM")))]
+  ""
+  "#"
+  "reload_completed"
+  [(parallel [(set (match_dup 0)
+  (plus:QI (match_dup 1) (match_dup 2)))
+ (clobber (reg:CC CC_REGNUM))])]
+  ""
+  [(set_attr "length" "2,4")])
+
+;; Inc/dec sets V if overflow from the operation
+(define_insn "*subqi3"
+  [(set (match_operand:QI 0 "nonimmediate_operand" "=rR,Q")
+   (plus:QI (match_operand:QI 1 "general_operand" "%0,0")
+(match_operand:QI 2 "incdec_operand" "LM,LM")))
+   (clobber (reg:CC CC_REGNUM))]
+  "reload_completed"
+  "*
+{
+  if (INTVAL(operands[2]) == -1)
+return \"incb\t%0\";
+  else
+return \"decb\t%0\";
+}"
+  [(set_attr "length" "2,4")])
+
 - and instructions
 ;; Bit-and on the pdp (like on the VAX) is done with a clear-bits insn.
 



Re: [PATCH, doc] describe mode checking for doloop_end pattern

2018-10-12 Thread Paul Koning



> On Oct 11, 2018, at 11:01 PM, Jeff Law  wrote:
> 
> On 10/11/18 3:09 PM, Paul Koning wrote:
>> Updated with an additional item I just debugged.
>> 
>> Since the code that uses the doloop_end pattern does not check the operand 
>> mode as given in the pattern, the pattern itself may need to do this, and 
>> that was not documented.  In addition, if the doloop_end pattern is a 
>> define_expand, there must be a define_insn (or define_insn_and_split) 
>> matching the generated pattern.  I had a define_split instead, and the 
>> result was an ICE in loop optimization (loop2_done pass).
>> 
>> This patch adds that information.  It also updates the example to reflect 
>> this.
>> 
>> Ok for trunk?
>> 
>>  paul
>> 
>> ChangeLog:
>> 
>> 2018-10-11  Paul Koning  
>> 
>>  * doc/md.texi (doloop_end): Document that the pattern code may
>>  need to check operand mode.
> OK.
> jeff

Thanks.  Committed.

paul



[PATCH, doc] describe mode checking for doloop_end pattern

2018-10-11 Thread Paul Koning
Updated with an additional item I just debugged.

Since the code that uses the doloop_end pattern does not check the operand mode 
as given in the pattern, the pattern itself may need to do this, and that was 
not documented.  In addition, if the doloop_end pattern is a define_expand, 
there must be a define_insn (or define_insn_and_split) matching the generated 
pattern.  I had a define_split instead, and the result was an ICE in loop 
optimization (loop2_done pass).

This patch adds that information.  It also updates the example to reflect this.

Ok for trunk?

paul

ChangeLog:

2018-10-11  Paul Koning  

* doc/md.texi (doloop_end): Document that the pattern code may
need to check operand mode.

Index: md.texi
===
--- md.texi (revision 265042)
+++ md.texi (working copy)
@@ -7619,7 +7619,23 @@ simplified) from the PDP-11 target:
 
 @smallexample
 @group
-(define_insn "doloop_end"
+(define_expand "doloop_end"
+  [(parallel [(set (pc)
+   (if_then_else
+(ne (match_operand:HI 0 "nonimmediate_operand" "+r,!m")
+(const_int 1))
+(label_ref (match_operand 1 "" ""))
+(pc)))
+  (set (match_dup 0)
+   (plus:HI (match_dup 0)
+ (const_int -1)))])]
+  ""
+  "@{
+if (GET_MODE (operands[0]) != HImode)
+  FAIL;
+  @}")
+
+(define_insn "doloop_end_insn"
   [(set (pc)
 (if_then_else
  (ne (match_operand:HI 0 "nonimmediate_operand" "+r,!m")
@@ -7662,10 +7678,23 @@ will be non-negative.
 Since the @code{doloop_end} insn is a jump insn that also has an output,
 the reload pass does not handle the output operand.  Therefore, the
 constraint must allow for that operand to be in memory rather than a
-register.  In the example shown above, that is handled by using a loop
-instruction sequence that can handle memory operands when the memory
-alternative appears.
+register.  In the example shown above, that is handled (in the
+@code{doloop_end_nocc} pattern) by using a loop instruction sequence
+that can handle memory operands when the memory alternative appears.
 
+GCC does not check the mode of the loop register operand when generating
+the @code{doloop_end} pattern.  If the pattern is only valid for some
+modes but not others, the pattern should be a @code{define_expand}
+pattern that checks the operand mode in the preparation code, and issues
+@code{FAIL} if an unsupported mode is found.  The example above does
+this, since the machine instruction to be used only exists for
+@code{HImode}.
+
+If the @code{doloop_end} pattern is a @code{define_expand}, there must
+also be a @code{define_insn} or @code{define_insn_and_split} matching
+the generated pattern.  Otherwise, the compiler will fail during loop
+optimization.
+
 @end ifset
 @ifset INTERNALS
 @node Insn Canonicalizations



[PATCH, doc] describe mode checking for doloop_end pattern

2018-10-11 Thread Paul Koning
Since the code that uses the doloop_end pattern does not check the operand mode 
as given in the pattern, the pattern itself may need to do this, and that was 
not documented.  This patch adds that information.  It also updates the example 
to reflect this.

Ok for trunk?

paul

ChangeLog:

2018-10-11  Paul Koning  

* doc/md.texi (doloop_end): Document that the pattern code may
need to check operand mode.

Index: doc/md.texi
===
--- doc/md.texi (revision 265042)
+++ doc/md.texi (working copy)
@@ -7619,7 +7619,23 @@ simplified) from the PDP-11 target:
 
 @smallexample
 @group
-(define_insn "doloop_end"
+(define_expand "doloop_end"
+  [(parallel [(set (pc)
+   (if_then_else
+(ne (match_operand:HI 0 "nonimmediate_operand" "+r,!m")
+(const_int 1))
+(label_ref (match_operand 1 "" ""))
+(pc)))
+  (set (match_dup 0)
+   (plus:HI (match_dup 0)
+ (const_int -1)))])]
+  "TARGET_40_PLUS"
+  "@{
+if (GET_MODE (operands[0]) != HImode)
+  FAIL;
+  @}")
+
+(define_insn "doloop_end_nocc"
   [(set (pc)
 (if_then_else
  (ne (match_operand:HI 0 "nonimmediate_operand" "+r,!m")
@@ -7628,17 +7644,28 @@ simplified) from the PDP-11 target:
  (pc)))
(set (match_dup 0)
 (plus:HI (match_dup 0)
-  (const_int -1)))]
-  ""
-  
+  (const_int -1)))
+   (clobber (reg:CC CC_REGNUM))]
+  "TARGET_40_PLUS && reload_completed"
+  "*
   @{
+rtx lb[1];
+   
 if (which_alternative == 0)
-  return "sob %0,%l1";
+   return \"sob\t%0,%l1\";
+   
+/* emulate sob */
+lb[0] = gen_label_rtx ();
+output_asm_insn (\"dec\t%0\", operands);
+output_asm_insn (\"beq\t%l0\", lb);
+output_asm_insn (\"jmp\t%l1\", operands);
+
+output_asm_label (lb[0]);
+fputs (\":\\n\", asm_out_file);
+   
+return \"\";
+  @}")
 
-/* emulate sob */
-output_asm_insn ("dec %0", operands);
-return "bne %l1";
-  @})
 @end group
 @end smallexample
 
@@ -7662,10 +7689,18 @@ will be non-negative.
 Since the @code{doloop_end} insn is a jump insn that also has an output,
 the reload pass does not handle the output operand.  Therefore, the
 constraint must allow for that operand to be in memory rather than a
-register.  In the example shown above, that is handled by using a loop
-instruction sequence that can handle memory operands when the memory
-alternative appears.
+register.  In the example shown above, that is handled (in the
+@code{doloop_end_nocc} pattern) by using a loop instruction sequence
+that can handle memory operands when the memory alternative appears.
 
+GCC does not check the mode of the loop register operand when generating
+the @code{doloop_end} pattern.  If the pattern is only valid for some
+modes but not others, the pattern should be a @code{define_expand}
+pattern that checks the operand mode in the preparation code, and issues
+@code{FAIL} if an unsupported mode is found.  The example above does
+this, since the machine instruction to be used only exists for
+@code{HImode}.
+
 @end ifset
 @ifset INTERNALS
 @node Insn Canonicalizations



Re: doloop insn generated incorrectly (wrong mode)

2018-10-11 Thread Paul Koning



> On Oct 11, 2018, at 3:11 AM, Segher Boessenkool  
> wrote:
> 
> Hi!
> 
> On Wed, Oct 10, 2018 at 08:55:12PM -0400, Paul Koning wrote:
> 
> [ snip ]
> 
>> ...
>> Why is this happening, and how can I fix it (short of removing the 
>> doloop_end pattern)?  I see a comment in loop-doloop.c about handling a FAIL 
>> of the pattern -- am I going to have to check that the wrong mode is being 
>> passed in and FAIL if so?
> 
> That is exactly what other targets do.  Maybe you can improve doloop so
> this isn't necessary anymore?  :-)

Maybe.  For now I'll take the expand and check approach.  And propose a doc 
patch to explain that this is needed, because it's an unusual situation. 

paul

doloop insn generated incorrectly (wrong mode)

2018-10-10 Thread Paul Koning
I have a doloop_end pattern in pdp11.md which looks like this:

(define_insn_and_split "doloop_end"
  [(set (pc)
(if_then_else
 (ne (match_operand:HI 0 "nonimmediate_operand" "+r,!m")
 (const_int 1))
 (label_ref (match_operand 1 "" ""))
 (pc)))
   (set (match_dup 0)
(plus:HI (match_dup 0)
 (const_int -1)))]
  "TARGET_40_PLUS"
  "#"
...

And the loop2 dump file shows this insn sequence:

(insn 1417 1415 1418 282 (set (reg:HI 565)
(plus:HI (subreg:HI (reg/v:QI 269 [ infcount ]) 0)
(const_int -1 [0x]))) 
"../../../../../combined/newlib/libc/stdio/vfscanf.c":1474:18 62 {addhi3}
 (nil))
(insn 1418 1417 1419 282 (set (reg/v:QI 292 [ infcount ])
(subreg:QI (reg:HI 565) 0)) 
"../../../../../combined/newlib/libc/stdio/vfscanf.c":1474:18 20 {movqi}
 (expr_list:REG_DEAD (reg:HI 565)
(nil)))
(jump_insn 1419 1418 1423 282 (set (pc)
(if_then_else (ne (reg/v:QI 269 [ infcount ])
(const_int 3 [0x3]))
(label_ref 1430)
(pc))) "../../../../../combined/newlib/libc/stdio/vfscanf.c":1474:9 
12 {cbranchqi4}
 (int_list:REG_BR_PROB 955630228 (nil))
 -> 1430)

which is turned into this (in loop2_doloop):

and ends up like this:

(jump_insn 2158 1447 2111 285 (parallel [
(set (pc)
(if_then_else (ne (reg:QI 647)
(const_int 1 [0x1]))
(label_ref 2111)
(pc)))
(set (reg:QI 647)
(plus:HI (reg:QI 647)
(const_int -1 [0x])))
]) "../../../../../combined/newlib/libc/stdio/vfscanf.c":1474:9 -1
 (int_list:REG_BR_PROB 955630228 (nil))
 -> 2111)

Note that this isn't permitted by the .md file -- the mode is wrong (QI not 
HI).  The result is an ICE in cfgrtl.c line 1275:

  /* If the substitution doesn't succeed, die.  This can happen
 if the back end emitted unrecognizable instructions or if
 target is exit block on some arches.  */
  if (!redirect_jump (as_a  (insn),
  block_label (new_bb), 0))
{
  gcc_assert (new_bb == EXIT_BLOCK_PTR_FOR_FN (cfun));
  return false;
}

It's not obvious to me how that relates to the wrong insn generated by the 
compiler, but clearly it can't be good to have something that won't match when 
it's time to generate the output code.  It seems to me that the doloop 
convertor should be checking the doloop_end pattern to make sure the mode 
matches, and not apply it unless it does.  

Why is this happening, and how can I fix it (short of removing the doloop_end 
pattern)?  I see a comment in loop-doloop.c about handling a FAIL of the 
pattern -- am I going to have to check that the wrong mode is being passed in 
and FAIL if so?

paul



Re: ICE building a libsupc++ file, pdp11 target

2018-10-09 Thread Paul Koning



> On Jul 17, 2018, at 9:36 AM, Richard Biener  
> wrote:
> 
> On Tue, Jul 17, 2018 at 3:08 PM Paul Koning  wrote:
>> 
>> 
>>> On Jul 17, 2018, at 5:46 AM, Richard Biener  
>>> wrote:
>>> 
>>>> ...
>>> 
>>> There is not enough information for anyone to help you without
>>> reproducing the issue which is maybe too much to ask for ;)
>>> 
>>> Can you debug_tree () the offending decl in gdb?
>> 
>> Yes, here it is.  I don't know anything about debugging in this area, so 
>> tools like debug_tree are good to learn about.  How would I interpret its 
>> output?
>> 
>> pkoning:gcc pkoning$ lldb ./cc1plus -- new_opa.ii -fno-implicit-templates 
>> -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi 
>> -fdiagnostics-show-location=once -frandom-seed=new_opa.lo -g -O2 -std=gnu++1z
>> (lldb) target create "./cc1plus"
>> Current executable set to './cc1plus' (x86_64).
>> ...
>> Process 10880 stopped
>> * thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
>>frame #0: 0x000100c21378 cc1plus`internal_error(gmsgid="in %s, at 
>> %s:%d") at diagnostic.c:1441 [opt]
>>   1438 internal_error (const char *gmsgid, ...)
>>   1439 {
>>   1440   va_list ap;
>> -> 1441   va_start (ap, gmsgid);
>>   1442   rich_location richloc (line_table, input_location);
>>   1443   diagnostic_impl (, -1, gmsgid, , DK_ICE);
>>   1444   va_end (ap);
>> Target 0: (cc1plus) stopped.
>> (lldb) frame sel 2
>> frame #2: 0x000100074b36 
>> cc1plus`import_export_decl(decl=0x00014269c750) at decl2.c:2877 [opt]
>>   2874   gcc_assert (VAR_OR_FUNCTION_DECL_P (decl));
>>   2875   /* Any code that creates entities with TREE_PUBLIC cleared should
>>   2876  also set DECL_INTERFACE_KNOWN.  */
>> -> 2877   gcc_assert (TREE_PUBLIC (decl));
>>   2878   if (TREE_CODE (decl) == FUNCTION_DECL)
>>   2879 gcc_assert (DECL_IMPLICIT_INSTANTIATION (decl)
>>   2880 || DECL_FRIEND_PSEUDO_TEMPLATE_INSTANTIATION (decl)
>> (lldb) call debug_tree(decl)
>> >type >size 
>>unit-size 
>>align:8 warn_if_not_align:0 symtab:150 alias-set -1 canonical-type 
>> 0x1426aa5e8 precision:1 min  max > 0x142502a08 1>>
>>readonly constant used static tree_1 tree_2 tree_3 unsigned nonlocal 
>> in_system_header read decl_1 QI 
>> /Users/pkoning/Documents/svn/buildpdp/pdp11-aout/libstdc++-v3/include/type_traits:59:28
>>  size  unit-size 
>>align:8 warn_if_not_align:0 context > integral_constant> initial 
>>template-info 0x1426a64e0 chain >
>> (lldb)
> 
> lldb? eh ... ;)
> 
> anyhow, this is
> 
> namespace std
> {
> 
> # 56 
> "/Users/pkoning/Documents/svn/buildpdp/pdp11-aout/libstdc++-v3/include/type_traits"
> 3
>  template
>struct integral_constant
>{
>  static constexpr _Tp value = __v;
> ^^^
> 
> which should have TREE_PUBLIC set.  My next step would be to watch how
> this flag changes (if it does...)
> 
> break at ggc-page.c:1442 (the return stmt of ggc_internal_alloc)
> conditional on result == 0x14269c750
> and then watch *>base.public_flag printing said flag when
> the watchpoint hits
> (because you're watching the whole integer containing the bitfield bit).
> 
> If that doesn't go anywhere try reducing the source file using creduce
> or by other means.
> 
> Maybe look at reset_decl_linkage () and visibility support in general.

I trimmed the file a bit.

Managed to find where public_flag is cleared.  It is in cp/expr.c 
maybe_commonize_var, line 5619, here:

  else
{
  /* While for initialized variables, we must use internal
 linkage -- which means that multiple copies will not
 be merged.  */
  TREE_PUBLIC (decl) = 0;
  DECL_COMMON (decl) = 0;

Could it be related to the fact that I have an a.out (rather than ELF) target?

paul



Building with old gcc

2018-10-09 Thread Paul Koning
I'm trying to build the current code on Linux with GCC 4.3.2 (stock compiler in 
Fedora 10 which is my old test system).  It fails like this:

In file included from 
/mnt/hgfs/pkoning/Documents/svn/gcc/gcc/tree-data-ref.h:27,
 from 
/mnt/hgfs/pkoning/Documents/svn/gcc/gcc/gimple-loop-interchange.cc:44:
/mnt/hgfs/pkoning/Documents/svn/gcc/gcc/opt-problem.h: In constructor 
‘opt_result::opt_result(bool, opt_problem*)’:
/mnt/hgfs/pkoning/Documents/svn/gcc/gcc/opt-problem.h:217: error: class 
‘opt_result’ does not have any field named ‘opt_wrapper’
/mnt/hgfs/pkoning/Documents/svn/gcc/gcc/opt-problem.h:217: error: no matching 
function for call to ‘opt_wrapper::opt_wrapper()’
/mnt/hgfs/pkoning/Documents/svn/gcc/gcc/opt-problem.h:160: note: candidates 
are: opt_wrapper::opt_wrapper(T, opt_problem*) [with T = bool]
/mnt/hgfs/pkoning/Documents/svn/gcc/gcc/opt-problem.h:147: note:
 opt_wrapper::opt_wrapper(const opt_wrapper&)
make[3]: *** [gimple-loop-interchange.o] Error 1

Is 9.0 supposed to build with a build compiler this old?  The documentation on 
the GCC web page says an ISO C++ compiler is required but it doesn't tell me 
whether the C++ compiler in GCC 4.3.2 is adequate.  Since many people will be 
installing GCC using an older version of GCC, it would be good for the 
documentation to state what the minimum version of GCC is.

paul



Re: movmem pattern and missed alignment

2018-10-08 Thread Paul Koning



> On Oct 8, 2018, at 5:43 PM, Eric Botcazou  wrote:
> 
>> That's correct, I was explaining from the middle-end perspective.  There
>> we are consciously more lenient as we have to support the real world and
>> other languages than C.  This is one of the cases.
> 
> This had worked as Paul expects until GCC 4.4 IIRC and this was perfectly OK 
> for every language on strict-alignment platforms.  This was changed only 
> because of SSE on x86.
> 
> -- 
> Eric Botcazou

So does that mean this should be a target-specific behavior, but it isn't at 
the moment?

paul



Re: movmem pattern and missed alignment

2018-10-08 Thread Paul Koning



> On Oct 8, 2018, at 1:29 PM, Andrew Haley  wrote:
> 
> On 10/08/2018 06:20 PM, Michael Matz wrote:
>> Only if you somewhere visibly add accesses to *i and *j.  Without them you 
>> only have the "accesses" via memcpy, and as Richi says, those don't imply 
>> any alignment requirements.  The i and j pointers might validly be char* 
>> pointers in disguise and hence be in fact only 1-aligned.  I.e. there's 
>> nothing in your small example program from which GCC can infer that those 
>> two global pointers are in fact 2-aligned.
> 
> So all you'd actually have to say is
> 
> void f1(void)
> {
>*i; *j;
>__builtin_memcpy (i, j, 32);
> }

No, that doesn't help.  Not even if I make it:

void f1(void)
{
k = *i + *j;
__builtin_memcpy (i, j, 4);
}

The first line does word aligned references to *i and *j, but the memcpy 
stubbornly remains a byte move.

paul



[PATCH, pdp11] libgcc: remove -mfloat32

2018-10-08 Thread Paul Koning
I missed a file that needed to be updated for the removal of -mfloat32.

Committed.

paul

ChangeLog:

2018-10-08  Paul Koning  

* config/pdp11/t-pdp11: Remove -mfloat32 switch.

Index: config/pdp11/t-pdp11
===
--- config/pdp11/t-pdp11(revision 264938)
+++ config/pdp11/t-pdp11(working copy)
@@ -5,4 +5,4 @@ LIB2ADD = $(srcdir)/udivmod.c \
  $(srcdir)/memmove.c \
  $(srcdir)/memset.c
 
-HOST_LIBGCC2_CFLAGS += -O2 -mfloat32
+HOST_LIBGCC2_CFLAGS += -O2



Re: movmem pattern and missed alignment

2018-10-08 Thread Paul Koning



> On Oct 8, 2018, at 11:09 AM, Richard Biener  
> wrote:
> 
> On Mon, Oct 8, 2018 at 3:57 PM Paul Koning  wrote:
>> 
>> I have a movmem pattern in my target that pays attention to the alignment 
>> argument.
>> 
>> GCC isn't passing in the expected alignment part of the time.  I have this 
>> test case:
>> 
>> extern int *i, *j;
>> extern int iv[40], jv[40];
>> 
>> void f1(void)
>> {
>>__builtin_memcpy (i, j, 32);
>> }
>> 
>> void f2(void)
>> {
>>__builtin_memcpy (iv, jv, 32);
>> }
>> 
>> When the movmem pattern is called for f1, alignment is 1.  In f2, it is 2 
>> (int is 2 bytes in pdp11) as expected.
>> 
>> The compiler clearly knows that int* points to aligned data, since it 
>> generates instructions that assume alignment (this is a strict-alignment 
>> target) when I dereference the pointer.  But somehow it gets it wrong for 
>> block move.
>> 
>> I also see this for the individual move operations that are generated for 
>> very short memcpy operations; if the count is 4, I get four move byte 
>> operations for f1, but two move word operations for f2.
>> 
>> This seems like a bug.  Am I missing something?
> 
> Yes, memcpy doesn't require anything bigger than byte alignment and
> GCC infers alignemnt
> only from actual memory references or from declarations (like iv /
> jv).  For i and j there
> are no dereferences and thus you get alignment of 1.
> 
> Richard.

Ok, but why is that not a bug?  The whole point of passing alignment to the 
movmem pattern is to let it generate code that takes advantage of the 
alignment.  So we get a missed optimization.

paul



[PATCH, pdp11] Fix LRA failure

2018-10-08 Thread Paul Koning
This patch fixes a failure handling block moves when the LRA register allocator 
is used. 

Committed.

paul

ChangeLog:

2018-10-08  Paul Koning  

* config/pdp11/pdp11-protos.h (output_block_move): Remove.
(expand_block_move): New function.
* config/pdp11/pdp11.c (output_block_move): Remove.
(expand_block_move): New function.
* config/pdp11/pdp11.h (MOVE_RATIO): New definition.
* config/pdp11/pdp11.md (movmemhi): Use expand_block_move.
(*movmemhi1): Remove.

Index: config/pdp11/pdp11-protos.h
===
--- config/pdp11/pdp11-protos.h (revision 264929)
+++ config/pdp11/pdp11-protos.h (revision 264930)
@@ -26,7 +26,7 @@ extern int legitimate_const_double_p (rtx);
 extern void notice_update_cc_on_set (rtx, rtx);
 extern void output_addr_const_pdp11 (FILE *, rtx);
 extern const char *output_move_multiple (rtx *);
-extern const char *output_block_move (rtx *);
+extern void expand_block_move (rtx *);
 extern const char *output_jump (rtx *, int, int);
 extern void print_operand_address (FILE *, rtx);
 typedef enum { no_action, dec_before, inc_after } pdp11_action;
Index: config/pdp11/pdp11.md
===
--- config/pdp11/pdp11.md   (revision 264929)
+++ config/pdp11/pdp11.md   (revision 264930)
@@ -570,48 +570,20 @@
   clrf\t%0"
   [(set_attr "length" "2,2,4,4,2")])
 
-;; maybe fiddle a bit with move_ratio, then 
-;; let constraints only accept a register ...
-
+;; Expand a block move.  We turn this into a move loop.
 (define_expand "movmemhi"
-  [(parallel [(set (match_operand:BLK 0 "general_operand" "=g,g")
-  (match_operand:BLK 1 "general_operand" "g,g"))
- (use (match_operand:HI 2 "general_operand" "n,mr"))
- (use (match_operand:HI 3 "immediate_operand" "i,i"))
- (clobber (match_scratch:HI 6 "=,X"))
- (clobber (match_dup 4))
- (clobber (match_dup 5))
- (clobber (match_dup 2))])]
+  [(match_operand:BLK 0 "general_operand" "=g")
+   (match_operand:BLK 1 "general_operand" "g")
+   (match_operand:HI 2 "immediate_operand" "i")
+   (match_operand:HI 3 "immediate_operand" "i")]
   ""
   "
 {
-  operands[0]
-= replace_equiv_address (operands[0],
-copy_to_mode_reg (Pmode, XEXP (operands[0], 0)));
-  operands[1]
-= replace_equiv_address (operands[1],
-copy_to_mode_reg (Pmode, XEXP (operands[1], 0)));
-
-  operands[4] = XEXP (operands[0], 0);
-  operands[5] = XEXP (operands[1], 0);
+  if (INTVAL (operands[2]) != 0)
+expand_block_move (operands);
+  DONE;
 }")
 
-
-(define_insn "*movmemhi1"
-  [(set (mem:BLK (match_operand:HI 0 "register_operand" "r,r"))
-   (mem:BLK (match_operand:HI 1 "register_operand" "r,r")))
-   (use (match_operand:HI 2 "general_operand" "n,r"))
-   (use (match_operand:HI 3 "immediate_operand" "i,i"))
-   (clobber (match_scratch:HI 4 "=,X"))
-   (clobber (match_dup 0))
-   (clobber (match_dup 1))
-   (clobber (match_dup 2))]
-  ""
-  "* return output_block_move (operands);"
-;;; just a guess
-  [(set_attr "length" "80")])
-   
-
 

 ;;- truncation instructions
 
Index: config/pdp11/pdp11.c
===
--- config/pdp11/pdp11.c(revision 264929)
+++ config/pdp11/pdp11.c(revision 264930)
@@ -45,6 +45,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "expr.h"
 #include "builtins.h"
 #include "dbxout.h"
+#include "explow.h"
 #include "expmed.h"
 
 /* This file should be included last.  */
@@ -1513,173 +1514,48 @@ no_side_effect_operand(rtx op, machine_mode mode A
 
 
 /*
- * output a block move:
+ * expand a block move:
  *
  * operands[0] ... to
  * operands[1]  ... from
  * operands[2]  ... length
  * operands[3]  ... alignment
- * operands[4]  ... scratch register
  */
 
- 
-const char *
-output_block_move(rtx *operands)
+void
+expand_block_move(rtx *operands)
 {
-static int count = 0;
-char buf[200];
-int unroll;
-int lastbyte = 0;
-
-/* Move of zero bytes is a NOP.  */
-if (operands[2] == const0_rtx)
-  return "";
-
-/* Look for moves by small constant byte counts, those we'll
-   expand to straight line code.  */
-if (CONSTANT_P (operands[2]))
-{
-   if (INTVAL (operands[2]) < 16
-   && (!optimize_size || INTVAL (operands[2]) < 5)
-   && INTVA

movmem pattern and missed alignment

2018-10-08 Thread Paul Koning
I have a movmem pattern in my target that pays attention to the alignment 
argument.

GCC isn't passing in the expected alignment part of the time.  I have this test 
case:

extern int *i, *j;
extern int iv[40], jv[40];

void f1(void)
{
__builtin_memcpy (i, j, 32);
}

void f2(void)
{
__builtin_memcpy (iv, jv, 32);
}

When the movmem pattern is called for f1, alignment is 1.  In f2, it is 2 (int 
is 2 bytes in pdp11) as expected.

The compiler clearly knows that int* points to aligned data, since it generates 
instructions that assume alignment (this is a strict-alignment target) when I 
dereference the pointer.  But somehow it gets it wrong for block move.

I also see this for the individual move operations that are generated for very 
short memcpy operations; if the count is 4, I get four move byte operations for 
f1, but two move word operations for f2.  

This seems like a bug.  Am I missing something?

paul



[PATCH, pdp11] remove -mfloat32, -mfloat64

2018-10-05 Thread Paul Koning
This patch removes switches that allow the size of "float" to be either the 
usual 4, or 8 -- which is also the size of "double".  That second choice 
creates problems for Fortran and violates the Fortran standard.  I don't see a 
reason for having the option; it certainly is not a familiar thing to do on 
this machine.

Committed.

paul

ChangeLog:

2018-10-05  Paul Koning  

* config/pdp11/pdp11.h (FLOAT_TYPE_SIZE): Always 32.
* config/pdp11/pdp11.opt (mfloat32): Remove.
(mfloat64): Remove.
* doc/invoke.texi (pdp11 -mfloat32): Remove:
(pdp11 -mfloat64): Remove.

Index: doc/invoke.texi
===
--- doc/invoke.texi (revision 264880)
+++ doc/invoke.texi (revision 264881)
@@ -1007,7 +1007,6 @@ Objective-C and Objective-C++ Dialects}.
 @emph{PDP-11 Options}
 @gccoptlist{-mfpu  -msoft-float  -mac0  -mno-ac0  -m40  -m45  -m10 @gol
 -mint32  -mno-int16 -mint16  -mno-int32 @gol
--mfloat32  -mno-float64 -mfloat64  -mno-float32 @gol
 -msplit -munix-asm  -mdec-asm -mgnu-asm -mlra}
 
 @emph{picoChip Options}
@@ -22722,18 +22721,6 @@ Use 16-bit @code{int}.  This is the default.
 @opindex mno-int16
 Use 32-bit @code{int}.
 
-@item -mfloat64
-@itemx -mno-float32
-@opindex mfloat64
-@opindex mno-float32
-Use 64-bit @code{float}.  This is the default.
-
-@item -mfloat32
-@itemx -mno-float64
-@opindex mfloat32
-@opindex mno-float64
-Use 32-bit @code{float}.
-
 @item -msplit
 @opindex msplit
 Target has split instruction and data space.  Implies -m45.
Index: config/pdp11/pdp11.opt
===
--- config/pdp11/pdp11.opt  (revision 264880)
+++ config/pdp11/pdp11.opt  (revision 264881)
@@ -42,14 +42,6 @@ mgnu-asm
 Target RejectNegative Report Mask(GNU_ASM) Negative(munix-asm)
 Use the GNU assembler syntax.
 
-mfloat32
-Target Report Mask(FLOAT32)
-Use 32 bit float.
-
-mfloat64
-Target Report InverseMask(FLOAT32, FLOAT64)
-Use 64 bit float.
-
 mfpu
 Target RejectNegative Report Mask(FPU)
 Use hardware floating point.
Index: config/pdp11/pdp11.h
===
--- config/pdp11/pdp11.h(revision 264880)
+++ config/pdp11/pdp11.h(revision 264881)
@@ -59,12 +59,14 @@ along with GCC; see the file COPYING3.  If not see
 #define LONG_TYPE_SIZE 32
 #define LONG_LONG_TYPE_SIZE64 
 
-/* if we set FLOAT_TYPE_SIZE to 32, we could have the benefit 
-   of saving core for huge arrays - the definitions are 
-   already in md - but floats can never reside in 
-   an FPU register - we keep the FPU in double float mode 
-   all the time !! */
-#define FLOAT_TYPE_SIZE(TARGET_FLOAT32 ? 32 : 64)
+/* In earlier versions, FLOAT_TYPE_SIZE was selectable as 32 or 64,
+   but that conflicts with Fortran language rules.  Since there is no
+   obvious reason why we should have that feature -- other targets
+   generally don't have float and double the same size -- I've removed
+   it.  Note that it continues to be true (for now) that arithmetic is
+   always done with 64-bit values, i.e., the FPU is always in "double"
+   mode.  */
+#define FLOAT_TYPE_SIZE32
 #define DOUBLE_TYPE_SIZE   64
 #define LONG_DOUBLE_TYPE_SIZE  64
 
@@ -200,12 +202,11 @@ extern const struct real_format pdp11_d_format;
 
 MUL_REGS are used for odd numbered regs, to use in 16-bit multiplication
  (even numbered do 32-bit multiply)
-LMUL_REGS long multiply registers (even numbered regs )
- (don't need them, all 32-bit regs are even numbered!)
 GENERAL_REGS is all cpu
 LOAD_FPU_REGS is the first four cpu regs, they are easier to load
 NO_LOAD_FPU_REGS is ac4 and ac5, currently - difficult to load them
 FPU_REGS is all fpu regs 
+CC_REGS is the condition codes (CPU and FPU)
 */
 
 enum reg_class



Re: blkmov and alignment

2018-10-05 Thread Paul Koning



> On Oct 5, 2018, at 12:21 PM, Richard Biener  
> wrote:
> 
> On October 5, 2018 4:17:53 PM GMT+02:00, Paul Koning  
> wrote:
>> The documentation says that argument 4 of the blkmov insn gives the
>> alignment, for example 4 if things are word-aligned.
>> 
>> It's documented that, say, the value 4 means source and destination are
>> multiples of 4.  What isn't clear is whether the length is also a
>> multiple of 4 in this case.  In other words, does "aligned" state the
>> alignment of source and destination and length, or only of the
>> addresses and the length may still be odd?
> 
> It only applies to the address alignment but you may want to check out the 
> expander. 

You mean emit_block_move_via_loop in expr.c?  That has a comment saying it 
would be nice to move units larger than QImode.  Yes, and that's just what I 
was looking to do.

I suppose I could write an expander that produces a different insn when the 
size is also the correct multiple, including the conversion from byte count to 
word count.  That seems like an obvious common optimization so having to do it 
in target code is a bit odd.

paul



blkmov and alignment

2018-10-05 Thread Paul Koning
The documentation says that argument 4 of the blkmov insn gives the alignment, 
for example 4 if things are word-aligned.

It's documented that, say, the value 4 means source and destination are 
multiples of 4.  What isn't clear is whether the length is also a multiple of 4 
in this case.  In other words, does "aligned" state the alignment of source and 
destination and length, or only of the addresses and the length may still be 
odd?

paul



[PATCH, pdp11] Enable LRA for pdp11

2018-10-03 Thread Paul Koning
This patch enables LRA register allocator support for pdp11.  For the moment, 
it is invoked via a switch (-mlra) as is done by a few other targets.  There 
are some code quality issues and test suite rejects to be looked at, but it's 
close enough for initial delivery.

Thanks to Segher for pointing out that LRA requires define_memory_constraint, 
while the old allocator is happy when memory operands use define_constraint. 

Committed.

paul

ChangeLog:

2018-10-03  Paul Koning  

Enable LRA register allocator for PDP11.
* config/pdp11/constraints.md (Q): Use define_memory_constraints.
(R): Likewise.
(D): Likewise.
* config/pdp11/pdp11.c (pdp11_lra_p): New function.
* config/pdp11/pdp11.opt (-mlra): New option.
* doc/invoke.texi (PDP-11 Options): Document -mlra.

Index: doc/invoke.texi
===
--- doc/invoke.texi (revision 264818)
+++ doc/invoke.texi (revision 264819)
@@ -1007,7 +1007,7 @@ Objective-C and Objective-C++ Dialects}.
 @gccoptlist{-mfpu  -msoft-float  -mac0  -mno-ac0  -m40  -m45  -m10 @gol
 -mint32  -mno-int16 -mint16  -mno-int32 @gol
 -mfloat32  -mno-float64 -mfloat64  -mno-float32 @gol
--msplit -munix-asm  -mdec-asm -mgnu-asm}
+-msplit -munix-asm  -mdec-asm -mgnu-asm -mlra}
 
 @emph{picoChip Options}
 @gccoptlist{-mae=@var{ae_type}  -mvliw-lookahead=@var{N} @gol
@@ -22721,6 +22721,11 @@ Use DEC assembler syntax.
 @item -mgnu-asm
 @opindex mgnu-asm
 Use GNU assembler syntax.  This is the default.
+
+@item -mlra
+@opindex mlra
+Use the new LRA register allocator.  By default, the old ``reload''
+allocator is used.
 @end table
 
 @node picoChip Options
Index: config/pdp11/constraints.md
===
--- config/pdp11/constraints.md (revision 264818)
+++ config/pdp11/constraints.md (revision 264819)
@@ -70,19 +70,19 @@
   (and (match_code "const_double")
(match_test "op == CONST0_RTX (GET_MODE (op))")))
 
-(define_constraint "Q"
+(define_memory_constraint "Q"
   "Memory reference that requires an additional word after the opcode"
   (and (match_code "mem")
(match_test "memory_address_p (GET_MODE (op), XEXP (op, 0))
 && !simple_memory_operand (op, GET_MODE (op))")))
 
-(define_constraint "R"
+(define_memory_constraint "R"
   "Memory reference that is encoded within the opcode"
   (and (match_code "mem")
(match_test "memory_address_p (GET_MODE (op), XEXP (op, 0))
 && simple_memory_operand (op, GET_MODE (op))")))
 
-(define_constraint "D"
+(define_memory_constraint "D"
   "Memory reference that is encoded within the opcode, and not push or pop"
   (and (match_code "mem")
(match_test "memory_address_p (GET_MODE (op), XEXP (op, 0))
Index: config/pdp11/pdp11.c
===
--- config/pdp11/pdp11.c(revision 264818)
+++ config/pdp11/pdp11.c(revision 264819)
@@ -230,7 +230,7 @@ static bool pdp11_scalar_mode_supported_p (scalar_
 #define TARGET_PREFERRED_OUTPUT_RELOAD_CLASS 
pdp11_preferred_output_reload_class
 
 #undef  TARGET_LRA_P
-#define TARGET_LRA_P hook_bool_void_false
+#define TARGET_LRA_P pdp11_lra_p
 
 #undef  TARGET_LEGITIMATE_ADDRESS_P
 #define TARGET_LEGITIMATE_ADDRESS_P pdp11_legitimate_address_p
@@ -991,6 +991,12 @@ pdp11_assemble_integer (rtx x, unsigned int size,
 }
 
 
+static bool
+pdp11_lra_p (void)
+{
+  return TARGET_LRA;
+}
+
 /* Register to register moves are cheap if both are general
registers.  */
 static int 
Index: config/pdp11/pdp11.opt
===
--- config/pdp11/pdp11.opt  (revision 264818)
+++ config/pdp11/pdp11.opt  (revision 264819)
@@ -73,3 +73,7 @@ Target has split I
 munix-asm
 Target RejectNegative Report Mask(UNIX_ASM) Negative(mdec-asm)
 Use UNIX assembler syntax.
+
+mlra
+Target Report Mask(LRA)
+Use LRA register allocator



Re: [PATCH] middle-end/81035: Mention that noreturn suppresses tail call optimization

2018-09-21 Thread Paul Koning



> On Sep 21, 2018, at 2:17 PM, Florian Weimer  wrote:
> 
> * Segher Boessenkool:
> 
>> On Fri, Sep 21, 2018 at 12:59:27PM +0200, Florian Weimer wrote:
>>> 2018-09-21  Florian Weimer  
>>> 
>>> PR middle-end/81035
>>> * doc/extend.texi (Common Function Attributes): Mention that
>>> noreturn suppresses tail call optimization.
>> 
>>> +In order to preserve backtraces, GCC will never turn calls to
>>> +@code{noreturn} functions into tail calls.
>> 
>> Should we document this?  Shouldn't we fix it, instead?
> 
> Fix how?  What is currently broken?
> 
> For things like assertion failures, we do not want to replace the
> current stack frame with that of __assert_fail, I think.

I agree.  Also, tailcalls are optimizations.  Speed optimizing noreturn calls 
is obviously not interesting.  Calls to noreturn functions are short, and 
turning them into a jump probably makes no difference in size, or if it does, 
not enough to matter.

paul



Re: [PATCH 04/25] SPECIAL_REGNO_P

2018-09-13 Thread Paul Koning



> On Sep 13, 2018, at 10:58 AM, Andrew Stubbs  wrote:
> 
> On 13/09/18 15:49, Paul Koning wrote:
>> It's ambiguous, because the last sentence of that paragraph says "addm3 is 
>> used if addptrm3 is not defined."
> 
> I didn't read that as ambiguous; I read it as addm3 is assumed to work fine 
> when addptr is not defined.
> 
>> I don't know of any change in this area.  All I know is that pdp11 has adds 
>> that clobber CC and it doesn't define addptrm3, relying on that last 
>> sentence.  I've tried LRA and for the most part it compiles successfully, I 
>> suppose I should verify the generated code based on the point you raised.  
>> If I really have to define addptr, I'm in trouble because  save/restore CC 
>> is not easy on pdp11.
> 
> The code was added because we had a number of testcases that failed at 
> runtime without it.
> 
> Admittedly, that was in a GCC 7 code-base, and I can't reproduce the failure 
> with one of those test cases now (with addptr deleted), but possibly that's 
> just noise.

Possibly relevant is that pdp11 is a "type 2" CC setting target, one where the 
machine description doesn't mention CC until after reload.  So if reload (LRA) 
is generating adds, the CC effect of that is invisible anyway until later 
passes that deal with the resulting clobbers and elimination, or not, of 
compares.

If that's what this is all about, some documentation clarification would help.  
Can someone confirm (or refute) my guess?

paul




Re: [PATCH 04/25] SPECIAL_REGNO_P

2018-09-13 Thread Paul Koning



> On Sep 13, 2018, at 10:39 AM, Andrew Stubbs  wrote:
> 
> On 13/09/18 15:16, Paul Koning wrote:
>> If you don't have machine operations that add without messing with
>> condition codes, wouldn't it make sense to omit the definition of the
>> add-pointer patterns?  GCC will build things out of normal
>> (CC-clobbering) adds if there are no add-pointer operations, which
>> may well be more efficient in most cases than explicitly
>> saving/restoring a CC that may in fact not matter right at that
>> spot.
> 
> I thought the whole point of addptr is that it *is* needed when add
> clobbers CC? As in, LRA spills are malformed without this.
> 
> Did something change? The internals manual still says "It only needs to
> be defined if addm3 sets the condition code."

It's ambiguous, because the last sentence of that paragraph says "addm3 is used 
if addptrm3 is not defined."  

I don't know of any change in this area.  All I know is that pdp11 has adds 
that clobber CC and it doesn't define addptrm3, relying on that last sentence.  
I've tried LRA and for the most part it compiles successfully, I suppose I 
should verify the generated code based on the point you raised.  If I really 
have to define addptr, I'm in trouble because  save/restore CC is not easy on 
pdp11.

paul



Re: [PATCH 04/25] SPECIAL_REGNO_P

2018-09-13 Thread Paul Koning



> On Sep 13, 2018, at 10:08 AM, Andrew Stubbs  wrote:
> 
> On 13/09/18 11:01, Andrew Stubbs wrote:
>> The assert is caused because the def-use chains indicate that SCC conflicts 
>> with itself. I suppose the question is why is it doing that, but it's 
>> probably do do with that being a special register that gets used in split2 
>> (particularly by the addptrdi3 pattern). Although, those patterns are 
>> careful to save SCC to one side and then restore it again after, so I'd have 
>> thought the DF analysis would work out?
> 
> I think I may have a theory on this one now
> 
> The addptrdi3 pattern must use two 32-bit adds with a carry in SCC, but 
> addptr patterns are not allowed to clobber SCC, so the splitter carefully 
> saves and restores the old value.

If you don't have machine operations that add without messing with condition 
codes, wouldn't it make sense to omit the definition of the add-pointer 
patterns?  GCC will build things out of normal (CC-clobbering) adds if there 
are no add-pointer operations, which may well be more efficient in most cases 
than explicitly saving/restoring a CC that may in fact not matter right at that 
spot.

paul



Trampolines and descriptors

2018-09-06 Thread Paul Koning
This came up in a discussion of an or1k patch, but it left me wondering so I'll 
raise the question again.

Are function descriptors meaningful outside Ada?  The internals manual seems to 
say yes, if enabled they will be used -- instead of trampolines -- also for C 
nested functions.

Is that correct?  It seems that this is worth using for any machine where it's 
desirable to avoid executing stack data.

paul

> On Aug 31, 2018, at 9:19 AM, Paul Koning  wrote:
> 
> 
> 
>> On Aug 30, 2018, at 9:02 PM, Jeff Law  wrote:
>> 
>> On 08/30/2018 10:58 AM, Richard Henderson wrote:
>>> On 08/28/2018 07:13 AM, Jeff Law wrote:
>>>> Please consider using function descriptors rather than trampolines.
>>>> This allows you to make the stack non-executable at all times which is
>>>> good from a security standpoint.  The downside is the indirect calling
>>>> mechanism has to change slightly to distinguish between a simple
>>>> indirect call and one through a function descriptor (usually by having a
>>>> low bit on to indicate the latter).  GIven this is an ABI change, now is
>>>> probably the last opportunity to make this change.
>>> 
>>> Correct me if I'm wrong here:
>>> 
>>> Define TARGET_CUSTOM_FUNCTION_DESCRIPTORS to an appropriate value -- easy 
>>> for a
>>> RISC target -- and that's it.
>>> 
>>> Further, it pretty much only gets used by the Ada front end.  One should not
>>> expect these to be used by the C front end nested functions.
>> I thought it was used more extensively than that...  Thanks for checking
>> into it though.
>> 
>> Jeff
> 
> My impression from reading the internals manual is that it's an alternative 
> to trampolines -- and in fact it appears to suggest it's a superior 
> alternative.  I've been planning to try turning it on for pdp11 where 
> executable stacks can be problematic.  (For that matter, they are on lots of 
> other machines -- which is why descriptors instead of trampolines sounds like 
> a good thing.)
> 
>   paul
> 



Re: gcc books, gcc debug (errata)

2018-09-04 Thread Paul Koning



> On Sep 4, 2018, at 12:40 PM, gérard Calliet  
> wrote:
> 
> (our build version is 4.7.3)
> 
> Hello,
> 
> I'm just a beginner in gcc. (I contributed to the rebuild of the gnat ada 
> compiler (version 3.4.7) on OpenVMS last year: 
> https://github.com/AdaLabs/gnat-vms).
> 
> As I do love books and encyclopedic learning attitude, I searched for a good 
> book about gcc.

My favorite resource is the GCC Internals manual, which is part of the GCC 
distribution.  Unlike the internals manuals from some other GNU projects, it's 
quite thorough.  Not everything is covered deep enough, but it certainly 
delivers a solid basis on many aspects of the system.

paul




Re: Even numbered register pairs restriction on some instructions

2018-09-03 Thread Paul Koning



> On Sep 3, 2018, at 1:25 PM, Matthew Malcomson  
> wrote:
> 
>>> 
>>> Thanks for the suggestions,
>>> I've had a look into these, and unfortunately it seems they have the same 
>>> problem I've been hitting before.
>>> 
>>> The use of the TARGET_HARD_REGNO_MODE_OK macro limits all uses of registers 
>>> in a given mode (so that we wouldn't be able to use register pairs 
>>> beginning with odd registers for other instructions), while using an 
>>> EVEN_REGS register class won't work in modes that span more than one hard 
>>> register (as all hard registers covered by a pseudo register must be in the 
>>> same class).
>> Is that so?  I don't remember that restriction, and certainly pdp11 does not 
>> do this.  Could that be why LRA is failing in some of my tests?  The "old" 
>> reload pass makes no objections.
>> 
>> Note though that there are two possible ways to look at this.
>> 
>> 1. Is there a register class such that all of the hard registers for a given 
>> mode are in that class?
>> 
>> 2. Is the value returned by REGNO_REG_CLASS the same for each of the hard 
>> registers of a register pair?
>> 
>> For pdp11, (1) is true (they are both members of GENERAL_REGS) while (2) is 
>> false (for the even register, GENERAL_REGS is returned, vs. MUL_REGS for the 
>> odd one).
>> 
>>  paul
>> 
> Apologies, I was unclear there.
> 
> When I said "all hard registers covered by a pseudo register must be in the 
> same class" I meant "in order for a register constraint to that class to be 
> satisfied".
> 
> i.e. if you were to use the "d" constraint in the SI operand of the 
> "mulhisi3" pattern, then that constraint would not allow any register pair to 
> be used since all register pairs use an odd register.
> 
> That is why "register classes cannot be used to enforce a requirement for a 
> register pair to start with an even-numbered register" as mentioned in 
> https://gcc.gnu.org/onlinedocs/gccint/Register-Classes.html 
>  .
> 
> Matthew

I see what you mean.  You want, say, SImode to be sometimes in an even/odd 
pair, and sometimes in any pair.  I'd like the same thing, in fact, or more 
generally still, I'd like SImode sometimes just to be a pair of HImode values 
that don't have to be both in registers at all, never mind in adjacent 
registers.  There doesn't seem to be a way to do that.  So pdp11, for example, 
always has SImode in even/odd pairs even though only MUL and DIV require that, 
no one else.

paul



Re: Even numbered register pairs restriction on some instructions

2018-09-03 Thread Paul Koning



> On Sep 3, 2018, at 12:10 PM, Matthew Malcomson  
> wrote:
> 
>> 
>> I think you can use pdp11 as an example, it does two things that are similar 
>> to what you're describing.
>> 
>> One is that it requires SImode to go into an even regno, and indicates that 
>> it uses two registers.  See TARGET_HARD_REGNO_MODE_OK and 
>> TARGET_HARD_REGNO_NREGS.
>> 
>> The other is that it has one instruction that wants an odd (!) register: 16 
>> bit multiply.  Multiply is weird: if you give it an even destination 
>> register it produces a 32 bit result in that register pair, with an odd 
>> register number it produces a 16 bit result.  So pdp11.md defines both 
>> "mulhi3" and "mulsihi3" insns.  The latter has an SImode output so that uses 
>> the even numbered register, as I already described.  The former uses a 
>> machine-specific constraint "d". That is defined in constraints.md to mean a 
>> register in class MUL_REGS.  pdp11.h defines that name and what registers it 
>> refers to, and pdp11.h does the reverse mapping (REGNO_REG_CLASS).
>> 
>> If you want even register numbers for some instructions but that's not tied 
>> to a specific type size (like SImode in my case), I think you'd want to use 
>> something analogous to the MUL_REGS thing I described.  Say, "EVEN_REGS".  
>> REGNO_REG_CLASS would report even regnum to be in EVEN_REGS, odd in 
>> GENERAL_REGS. The bitmaps for REG_CLASS_CONTENTS would show that EVEN_REGS 
>> contains only even numbered registers while GENERAL_REGS contains both odd 
>> and even.  And you'd defined a register constraint which matches EVEN_REGS.  
>> Then the instructions where you want them would use that constraint.
>> 
>>  paul
>> 
> 
>> Yes, it's possible.  You can look at TDmode (128-bit decimal floating point)
>> on powerpc64*-linux, which is only allowed in even-odd register pairs.
>> It's in *all* cases though, not some of the time.
>> 
>> Peter
>> 
> 
> Thanks for the suggestions,
> I've had a look into these, and unfortunately it seems they have the same 
> problem I've been hitting before.
> 
> The use of the TARGET_HARD_REGNO_MODE_OK macro limits all uses of registers 
> in a given mode (so that we wouldn't be able to use register pairs beginning 
> with odd registers for other instructions), while using an EVEN_REGS register 
> class won't work in modes that span more than one hard register (as all hard 
> registers covered by a pseudo register must be in the same class).

Is that so?  I don't remember that restriction, and certainly pdp11 does not do 
this.  Could that be why LRA is failing in some of my tests?  The "old" reload 
pass makes no objections.

Note though that there are two possible ways to look at this.

1. Is there a register class such that all of the hard registers for a given 
mode are in that class?

2. Is the value returned by REGNO_REG_CLASS the same for each of the hard 
registers of a register pair?

For pdp11, (1) is true (they are both members of GENERAL_REGS) while (2) is 
false (for the even register, GENERAL_REGS is returned, vs. MUL_REGS for the 
odd one).

paul



  1   2   3   4   >