Re: movmem pattern and missed alignment

> 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

Re: movmem pattern and missed alignment

> 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

[PATCH, pdp11] libgcc: remove -mfloat32

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

Re: movmem pattern and missed alignment

> 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 ex

[PATCH, pdp11] Fix LRA failure

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

movmem pattern and missed alignment

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) {

[PATCH, pdp11] remove -mfloat32, -mfloat64

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): Re

Re: blkmov and alignment

> 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. >&

blkmov and alignment

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

[PATCH, pdp11] Enable LRA for pdp11

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

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

> 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 >>>

Re: [PATCH 04/25] SPECIAL_REGNO_P

> 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 rea

Re: [PATCH 04/25] SPECIAL_REGNO_P

> 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?

Re: [PATCH 04/25] SPECIAL_REGNO_P

> 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

Trampolines and descriptors

. 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, Rich

Re: gcc books, gcc debug (errata)

> 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

Re: Even numbered register pairs restriction on some instructions

> 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

Re: Even numbered register pairs restriction on some instructions

> 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

Re: Even numbered register pairs restriction on some instructions

> On Aug 31, 2018, at 11:41 AM, Matthew Malcomson > wrote: > > Hi there, > > I'm looking into whether it's possible to require even numbered registers on > modes that need more than one hard-register to represent them. But only in > some cases. > > The problem is the one mentioned

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

> 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 >>>

Re: Trying to convert to LRA, running into an ICE (infinite reload loop)

> On Aug 20, 2018, at 7:17 AM, Segher Boessenkool > wrote: > > On Tue, Aug 14, 2018 at 03:32:01PM -0400, Paul Koning wrote: >> I'm trying to convert the pdp11 target to use LRA. >> >> A lot of it "just works". But one of the test suite files fa

Re: Trying to convert to LRA, running into an ICE (infinite reload loop)

> On Aug 20, 2018, at 7:17 AM, Segher Boessenkool > wrote: > > On Tue, Aug 14, 2018 at 03:32:01PM -0400, Paul Koning wrote: >> I'm trying to convert the pdp11 target to use LRA. >> >> A lot of it "just works". But one of the test suite files fa

Re: Trying to convert to LRA, running into an ICE (infinite reload loop)

> On Aug 15, 2018, at 1:01 AM, Jeff Law wrote: > > On 08/14/2018 01:32 PM, Paul Koning wrote: >> I'm trying to convert the pdp11 target to use LRA. >> >> A lot of it "just works". But one of the test suite files fails in a way >> that I can't f

Trying to convert to LRA, running into an ICE (infinite reload loop)

I'm trying to convert the pdp11 target to use LRA. A lot of it "just works". But one of the test suite files fails in a way that I can't figure out at all. I'm hoping for some help or hints to track down the cause and come up with a fix. The failing program is

Re: [PATCH] Add sinh(tanh(x)) and cosh(tanh(x)) rules

tch code and comments are still correct. > > On Wed, Aug 8, 2018 at 10:58 AM, Paul Koning wrote: >> Now I'm puzzled. >> >> I don't see how an infinite would show up in the original expression. I >> don't know hyperbolic functions, so I just constructed a small test p

Re: [PATCH] Add sinh(tanh(x)) and cosh(tanh(x)) rules

ano Augusto Faulin Belinassi > wrote: > > That is a good question because I didn't know that such targets > exists. Any suggestion? > > > On Tue, Aug 7, 2018 at 5:29 PM, Paul Koning wrote: >> >> >>> On Aug 7, 2018, at 4:00 PM, Giuliano Augusto F

Re: [PATCH] Add sinh(tanh(x)) and cosh(tanh(x)) rules

> On Aug 7, 2018, at 4:00 PM, Giuliano Augusto Faulin Belinassi > wrote: > > Related with bug 86829, but for hyperbolic trigonometric functions. > This patch adds substitution rules to both sinh(tanh(x)) -> x / sqrt(1 > - x*x) and cosh(tanh(x)) -> 1 / sqrt(1 - x*x). Notice that the both >

Re: [PATCH] Use getentropy() for seeding PRNG

> On Aug 3, 2018, at 9:19 AM, Janne Blomqvist wrote: > > The getentropy function, found on Linux, OpenBSD, and recently also > FreeBSD, can be used to get random bytes to initialize the PRNG. It > is similar to the traditional way of reading from /dev/urandom, but > being a system call

Re: [patch] improve internals documentation for nested function descriptors

> On Jul 27, 2018, at 4:39 PM, Sandra Loosemore wrote: > > Apropos of the discussion about improving the docs for > TARGET_CUSTOM_FUNCTION_DESCRIPTORS in the context of the C-SKY port > submission, > > https://gcc.gnu.org/ml/gcc-patches/2018-07/msg01454.html > > here is the patch I've

Re: [PATCH 09/11] pdp11 - example of a port not needing a speculation barrier

> On Jul 27, 2018, at 5:37 AM, Richard Earnshaw > wrote: > > > This patch is intended as an example of all that is needed if the > target system doesn't support CPUs that have speculative execution. > I've chosen the pdp11 port on the basis that it's old enough that this > is likely to be

Re: [PATCH 1/7] Add __builtin_speculation_safe_value

> On Jul 26, 2018, at 7:34 PM, Joseph Myers wrote: > > On Wed, 25 Jul 2018, Richard Earnshaw (lists) wrote: > Port maintainers DO need to decide what to do about speculation, even if it is explicitly that no mitigation is needed. >>> >>> Agreed. But I didn't yet see a request for

Re: [2/5] C-SKY port: Backend implementation

> On Jul 25, 2018, at 12:50 AM, Jeff Law wrote: > ... >>> It did. See TARGET_CUSTOM_FUNCTION_DESCRIPTORS and the (relatively few) >>> ports that define it. >> >> Hmmm, I completely failed to make that connection from the docs -- the >> whole description of that hook is pretty

Re: That light at the end of the tunnel?

> On Jul 23, 2018, at 12:21 PM, Jeff Law wrote: > >> > Hell, I'd live with doing a "reasonable effort" for the vast majority of > our branches. Other than the trunk, active release branches and a few > active development branches I don't think we really care about 'em. > > jeff There are

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

> On Jul 23, 2018, at 10:21 AM, Joseph Myers wrote: > > On Tue, 17 Jul 2018, Paul Koning wrote: > >> That reveals some things but nothing jumps out at me. However... pdp11 >> is an a.out target, not an ELF target. Would that explain the problem? >> If yes

Re: [RFC] Adding Python as a possible language and it's usage

> On Jul 20, 2018, at 12:37 PM, Segher Boessenkool > wrote: > > On Fri, Jul 20, 2018 at 11:49:05AM +0200, Martin Liška wrote: >> Fully agree with that. Coming up with a new scripts written in python2 really >> makes no sense. > > Then python cannot be a build requirement for GCC, since some

Re: Detecting superfluous "else"

> On Jul 19, 2018, at 4:49 AM, U.Mutlu wrote: > > Hi, > it makes me 'crazy' when I see such if-else constructs: > if (x) >return 7; > else >return 4; > > (Of course in this case one better would use the shorthand "return x ? 7 : > 4;", but that's not the issue here) > > The

Re: [RFC] Adding Python as a possible language and it's usage

> On Jul 18, 2018, at 1:22 PM, Boris Kolpackov wrote: > > Paul Koning writes: > >>> On Jul 18, 2018, at 11:13 AM, Boris Kolpackov >>> wrote: >>> >>> I wonder what will be the expected way to obtain a suitable version of >>> Python

Re: [RFC] Adding Python as a possible language and it's usage

> On Jul 18, 2018, at 11:13 AM, Boris Kolpackov wrote: > > On Tue, 2018-07-17 at 14:49 +0200, Martin Liška wrote: > >> My question is simple: can we starting using a scripting language like >> Python and replace usage of the AWK scripts? > > I wonder what will be the expected way to obtain

Re: [RFC] Adding Python as a possible language and it's usage

> On Jul 17, 2018, at 8:23 PM, David Malcolm wrote: > >>> Hi. >>> >>> I've recently touched AWK option generate machinery and it's quite >>> unpleasant to make any adjustments. My question is simple: can we >>> starting using a scripting language like Python and replace usage >>> of >>> the

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

> On Jul 17, 2018, at 9:38 AM, Richard Biener > wrote: > >> ... >> lldb? eh ... ;) Yes, gdb is hard to make work on Mac OS. >> anyhow, this is >> >> namespace std >> { >> >> # 56 >> "/Users/pkoning/Documents/svn/buildpdp/pdp11-aout/libstdc++-v3/include/type_traits" >> 3 >> template >>

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

> On Jul 13, 2018, at 3:12 PM, U.Mutlu wrote: > > Paul Koning wrote on 07/13/2018 08:56 PM: >> >> >>> On Jul 13, 2018, at 2:52 PM, U.Mutlu wrote: >>> >>> Paul Koning wrote on 07/13/2018 08:27 PM: >>>> I'm trying to see if I can

[PATCH, committed] Fix rtl check error in pdp11

When building with checking enabled, there were check failures in pdp11_rtx_costs. This patch fixes two errors. Committed. paul ChangeLog: 2018-07-14 Paul Koning * config/pdp11/pdp11.c (pdp11_rtx_costs): Bugfixes. Index: config/pdp11/pdp11.c

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

> On Jul 13, 2018, at 2:52 PM, U.Mutlu wrote: > > Paul Koning wrote on 07/13/2018 08:27 PM: >> I'm trying to see if I can build the pdp11 target for languages other than >> just C, and the answer is for the most part yes. But I' running into an ICE >> I can't f

ICE building a libsupc++ file, pdp11 target

I'm trying to see if I can build the pdp11 target for languages other than just C, and the answer is for the most part yes. But I' running into an ICE I can't figure out. It's way before the back end comes into the picture as far as I can see, and there's nothing particularly strange looking

Re: How does a target make Fortran work?

> On Jul 13, 2018, at 9:36 AM, Janus Weil wrote: > > Hi Paul, > > Fortran problems are best discussed on fort...@gcc.gnu.org > <mailto:fort...@gcc.gnu.org> (in CC) ... > > 2018-07-12 21:22 GMT+02:00 Paul Koning <mailto:paulkon...@comcast.net>>:

[PATCH, committed] Fix typo in pdp11 target

This fixes a typo in the output of a ".set" directive. Committed. paul ChangeLog: 2018-07-12 Paul Koning * config/pdp11/pdp11.c (pdp11_output_def): Fix typo in .set directive. Index: config/pdp

How does a target make Fortran work?

I tried to rebuild for target pdp11 with fortran enabled (in the past I've just enabled C). It builds fine but the resulting compiler crashes at startup: Paul-Konings-MacBook-Pro:gcc pkoning$ ./xgcc -B. -O2 -S ../../hello.f f951: internal compiler error: gfc_validate_kind(): Got bad kind

Re: [PATCH] doc: update looping constructs

> On Jul 12, 2018, at 1:42 PM, Jeff Law wrote: > > On 07/12/2018 11:17 AM, Paul Koning wrote: >> >> >>> On Jul 12, 2018, at 12:55 PM, Jeff Law wrote: >>> >>> On 07/11/2018 06:20 PM, Paul Koning wrote: &g

Re: [PATCH] doc: update looping constructs

> On Jul 12, 2018, at 12:55 PM, Jeff Law wrote: > > On 07/11/2018 06:20 PM, Paul Koning wrote: >> This patch removes the obsolete documentation for >> decrement_and_branch_until_zero. It also adds detail to the description for >> doloop_end. In particular, it

[PATCH] doc: update looping constructs

This patch removes the obsolete documentation for decrement_and_branch_until_zero. It also adds detail to the description for doloop_end. In particular, it describes the required form of the conditional branch part of the pattern. Ok for trunk? paul ChangeLog: 2018-07-11 Paul

Re: ChangeLog's: do we have to?

> On Jul 10, 2018, at 2:18 PM, NightStrike wrote: > > On Fri, Jul 6, 2018 at 1:17 AM, Siddhesh Poyarekar > wrote: >> ... >> >> We had discussed making addition of ChangeLog entries into the commit >> message mandatory but the issue there is that commit logs cannot be (or more >> precisely,

[PATCH] doc: add missing "mode" type attribute

butes. Ok for trunk? paul ChangeLog: 2018-07-10 Paul Koning * doc/extend.texi (Common Variable Attributes): Move "mode" into alphabetical order. (Common Type Attributes): Add "mode&

[PATCH, committed] Improve code generation for pdp11 target

This patch improves the generated code for the pdp11 target. Committed. paul ChangeLog: 2018-07-09 Paul Koning * config/pdp11/pdp11.c (pdp11_addr_cost): New function. (pdp11_insn_cost): New function. (pdp11_md_asm_adjust): New function

[PATCH, doc] Small clarification on define_subst

In doing CCmode work I was confused how define_subst handles cases where the same argument appears more than once. The attached clarifies this. Ok for trunk? paul ChangeLog: 2018-07-08 Paul Koning * doc/md.texi (define_subst): Document how multiple occurrences

Re: [PATCH] doc clarification: DONE and FAIL in define_split and define_peephole2

> On Jul 6, 2018, at 12:20 PM, Richard Sandiford > wrote: > > Double empty line. > > OK otherwise, thanks. (Think this counts as a gen* patch.) > > Richard Thanks. Committed as shown below. paul ChangeLog: 2018-07-06 Paul Koning * d

Re: [PATCH] doc clarification: DONE and FAIL in define_split and define_peephole2

+particular inputs it was given, and the input insns are left unchanged. > > If it FAILs, GCC will try to apply later define_peehole2s instead. > (This is in contrast to define_split, so it's a bit inconsistent. > Would be easy to make define_split behave the same way if there was a >

Re: Inefficient code

> On Jul 6, 2018, at 6:18 AM, Bernd Edlinger wrote: > > You can get much better code if you make xrci a bit field. > so the entire bit filed region can be accessed word-wise: > > > #include > > struct Xrb > { >uint16_t xrlen; /* Length of I/O buffer in bytes */ >

Re: Inefficient code

> On Jul 5, 2018, at 9:01 PM, Paul Koning wrote: > > > >> On Jul 5, 2018, at 6:47 PM, Eric Botcazou wrote: >> >>> So back to the previous one: anything I can do about a 24 bit field getting >>> split into three movqi rather than a movqi plus a mov

Re: Inefficient code

> On Jul 5, 2018, at 6:47 PM, Eric Botcazou wrote: > >> So back to the previous one: anything I can do about a 24 bit field getting >> split into three movqi rather than a movqi plus a movhi? That happens >> during RTL expand, I believe. > > Yes, this one doesn't look as hopeless as the

[PATCH] doc clarification: DONE and FAIL in define_split and define_peephole2

ribe those cases. Ok for trunk? paul ChangeLog: 2018-07-05 Paul Koning * doc/md.texi (define_split): Document DONE and FAIL. Describe interaction with usual "#" output template in define_insn_and_split. (define_peephole2): Document DONE a

Re: Inefficient code

> On Jul 5, 2018, at 4:44 PM, Eric Botcazou wrote: > > ... > The GIMPLE pass responsible for the optimization simply punts for the "funny- > endian ordering" of the PDP11. More generally, you shouldn't expect anything > sparkling for such a peculiar architecture as the PDP11. Ok. Yet

Re: decrement_and_branch_until_zero pattern

> On Jun 8, 2018, at 6:16 PM, Jim Wilson wrote: > > On Fri, Jun 8, 2018 at 1:12 PM, Paul Koning wrote: >> Thanks. I saw those sections and interpreted them as support for signal >> processor style fast hardware loops. If they can be adapted for dbra type >>

Re: Inefficient code

> On Jul 5, 2018, at 12:01 PM, Segher Boessenkool > wrote: > > On Thu, Jul 05, 2018 at 08:45:30AM -0400, Paul Koning wrote: >> I have a struct that looks like this: >> >> struct Xrb >> { >>uint16_t xrlen; /* Length of

Re: ChangeLog's: do we have to?

> On Jul 5, 2018, at 10:44 AM, Florian Weimer wrote: > > * Richard Kenner: > >>> GCC ChangeLogs don't record the purpose of the change. They say what >>> changed, >>> but not why. >> >> That depends on how you define "purpose". Let's take a random entry, >> from a 1999 change of mine: >>

Re: ChangeLog's: do we have to?

> On Jul 5, 2018, at 10:43 AM, Florian Weimer wrote: > > * Aldy Hernandez: > >> Can someone refresh my memory here, what are the remaining arguments for >> requiring ChangeLog entries? > > ChangeLog entries are part of the review, commit messages are not, so > you end up with surprises

Inefficient code

I have a struct that looks like this: struct Xrb { uint16_t xrlen; /* Length of I/O buffer in bytes */ uint16_t xrbc; /* Byte count for transfer */ void * xrloc; /* Pointer to I/O buffer */ uint8_t xrci; /* Channel number times

[PATCH, committed] Add -mgnu-asm to pdp11 target, change -mdec-asm

. paul ChangeLog: 2018-07-01 Paul Koning * common/config/pdp11/pdp11-common.c (pdp11_handle_option): Handle -munit-asm, -mgnu-asm, -mdec-asm. * config/pdp11/pdp11-protos.h (pdp11_gen_int_label): New. (pdp11_output_labelref): New

[PATCH, committed] Fix insn length in pdp11 shift patterns

This patch corrects the setting of the "length" attributes in the pdp11 target for certain shift cases. Committed. paul ChangeLog: 2018-06-28 Paul Koning * config/pdp11/pdp11-protos.h (pdp11_shift_length): New function. * config/pdp11/pdp11.c (pdp11_sh

[PATCH, committed] Convert pdp11 back end to CCmode

with a machine that has two condition code registers. Committed. paul ChangeLog: 2018-06-27 Paul Koning * common/config/pdp11/pdp11-common.c (pdp11_handle_option): Handle mutually exclusive options. * config/pdp11/constraints.md (h): New constraint. (O

[PATCH, committed] fix pdp11 target test failures

This patch fixes a number of test suite failures caused by data too large for the address space or alignment larger than supported by this target. paul testsuite/ChangeLog: 2018-06-22 Paul Koning * gcc.c-torture/execute/builtins/lib/chk.c: Use smaller alignment

ICE in a testcase, not sure about solution

I'm running into an ICE in the GIMPLE phase, for gcc.c-torture/compile/386.c, on pdp11 -mint32. That's an oddball where int is 32 bits (due to the flag) but Pmode is 16 bits (HImode). The ICE message is: ../../gcc/gcc/testsuite/gcc.c-torture/compile/386.c: In function ‘main’:

Re: divmod pattern question

> On Jun 20, 2018, at 1:16 AM, Jeff Law wrote: > > On 06/19/2018 12:55 PM, Paul Koning wrote: >> Gentlepeople, >> >> I have a two-operand divide instruction that takes a double length dividend >> in a register pair, and produces the quotient in the

divmod pattern question

Gentlepeople, I have a two-operand divide instruction that takes a double length dividend in a register pair, and produces the quotient in the first register and remainder in the second. How do I write a divmod pattern for that? The quotient is easy enough, I write a match_operand for that

Re: [PATCH] Come up with Deprecated option flag.

> On Jun 8, 2018, at 7:09 AM, Martin Liška wrote: > > Hi. > > First follow-up MPX removal patch comes up with Deprecated option flag. > That prints warning for options that have no effect: Should this be mentioned in the internals manual (section 8.2)? paul

Re: in/out operands and auto-inc-dec

> On Jun 11, 2018, at 3:04 PM, Jeff Law wrote: > > On 06/04/2018 09:02 AM, Paul Koning wrote: >> >> ... >> >> By "multiple memory operands" do you mean both source and dest in >> memory? > Yes and no :-) I suspect no real thought was giv

Re: decrement_and_branch_until_zero pattern

> On Jun 8, 2018, at 2:29 PM, Jim Wilson wrote: > > On 06/08/2018 06:21 AM, Paul Koning wrote: >> Interesting. The ChangeLog doesn't give any background. I suppose I should >> plan to approximate the effect of this pattern with a define-peephole2 ? > >

Re: decrement_and_branch_until_zero pattern

> On Jun 8, 2018, at 6:59 AM, Andreas Schwab wrote: > > On Jun 07 2018, Paul Koning wrote: > >> None of these seem to use that loop optimization, with -O2 or -Os. Did I >> miss some magic switch to turn on something else that isn't on by default? >> Or is

decrement_and_branch_until_zero pattern

I'm a bit puzzled by the decrement_and_branch_until_zero looping pattern. The manual described it as a named pattern, through from the description it isn't clear that it's referenced by name. I see those only in m68k and pa. There are similar looking but anonymous patterns in pdp11 and vax,

Re: [PATCH] Avoid optimizing memory references with side effects in compare-elim.c

> On Jun 7, 2018, at 11:37 AM, Eric Botcazou wrote: > >> Here is a corrected version. Ok with this change? >> >> paul >> >> gcc/ChangeLog: >> >> 2018-06-06 Paul Koning >> >> * compare-elim.c (try_merge_compare): D

Re: [PATCH] Avoid optimizing memory references with side effects in compare-elim.c

> On Jun 6, 2018, at 11:53 AM, Eric Botcazou wrote: > >> That simplifies the patch, which now looks like this. Ok for trunk? >> >> paul >> >> gcc/ChangeLog: >> >> 2018-06-05 Paul Koning >> >> * compare-elim.c

Re: [PATCH] Avoid optimizing memory references with side effects in compare-elim.c

> On Jun 5, 2018, at 3:54 PM, Richard Sandiford > wrote: > > Paul Koning writes: >> This fixes an ICE if post-reload compare elimination is done and the >> target supports post_inc and similar modes, as pdp11 does. The ICE is >> caused by a generated PARALLEL

[PATCH] Avoid optimizing memory references with side effects in compare-elim.c

generate a similar RTL suitable for a matching constraint with the side effect omitted; I may try for that later on if that is still supported by the constraint machinery.) Tested against my in-progress CCmode pdp11 target. Ok to commit? paul gcc/ChangeLog: 2018-06-05 Paul Koning

[PATCH] Avoid optimizing memory references with side effects in compare-elim.c

constraint with the side effect omitted; I may try for that later on if that is still supported by the constraint machinery.) Tested against my in-progress CCmode pdp11 target. Ok to commit? paul gcc/ChangeLog: 2018-06-05 Paul Koning * compare-elim.c (addr_side_effect_check): New

Re: in/out operands and auto-inc-dec

> On Jun 4, 2018, at 10:09 AM, Jeff Law wrote: > > On 06/04/2018 08:06 AM, Paul Koning wrote: >> >> >>> On Jun 4, 2018, at 9:51 AM, Jeff Law wrote: >>> >>> On 06/04/2018 07:31 AM, Paul Koning wrote: >>>> The internals

Re: in/out operands and auto-inc-dec

> On Jun 4, 2018, at 9:51 AM, Jeff Law wrote: > > On 06/04/2018 07:31 AM, Paul Koning wrote: >> The internals manual in its description of the "matching constraint" says >> that it works for cases where the in and out operands are somewhat >> diffe

in/out operands and auto-inc-dec

The internals manual in its description of the "matching constraint" says that it works for cases where the in and out operands are somewhat different, such as *p++ vs. *p. Obviously that is meant to cover post_inc side effects. The curious thing is that auto-inc-dec.c specifically avoids

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

> On Jun 1, 2018, at 5:04 PM, Joseph Myers wrote: > > On Tue, 29 May 2018, Paul Koning wrote: > >> +unsigned short udivmodhi4(unsigned short, unsigned short, int); > > libgcc should not have any such non-static functions in the user > namespace; they should a

Re: Doing pdp11 cc0->CC conversion, running into ICE related to compare-elim

> On Jun 1, 2018, at 2:40 PM, Jakub Jelinek wrote: > > On Fri, Jun 01, 2018 at 02:35:41PM -0400, Paul Koning wrote: >> during RTL pass: dse2 >> dump file: unwind-dw2-fde.c.288r.dse2 >> ../../../../gcc/libgcc/unwind-dw2-fde.c: In function ‘get_cie_encoding’: >&

Doing pdp11 cc0->CC conversion, running into ICE related to compare-elim

Gentlepeople, I'm using Eric Botcazou's recipe #2 for the CCmode version of pdp11 -- where most instructions step on the condition codes so the CC references are inserted post-reload. As part of that, the compare-elim pass gets rid of compares that are redundant given that the instruction

Re: Adding a libgcc file

> On May 31, 2018, at 12:35 PM, Joseph Myers wrote: > > On Tue, 29 May 2018, Paul Koning wrote: > >> Question about proper target maintainer procedures... >> >> The pdp11 target needs udivhi3 in libgcc. There's udivsi3, and it's >> really

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

> On May 29, 2018, at 4:17 PM, Jakub Jelinek wrote: > > On Tue, May 29, 2018 at 03:01:20PM -0400, Paul Koning wrote: >> +short udivmodhi4 (); > > We do want real prototypes, not K declarations. Fixed. I had copied that from the SImode file. > >> Adde

[PATCH] add udivhi3, umodhi3 functions to libgcc

Paul Koning * udivhi3.c: New file. * udivmodhi4.c: New file. * config/pdp11/t-pdp11 (LIB2ADD): Add the above files. Index: config/pdp11/t-pdp11 === --- config/pdp11/t-pdp11(revision 260806) +++ config

Adding a libgcc file

Question about proper target maintainer procedures... The pdp11 target needs udivhi3 in libgcc. There's udivsi3, and it's really easy to tweak those files for HImode. And that works. Should I add the HI files to the libgcc directory, or under config/pdp11? There's nothing target specific

Re: not computable at load time

> On May 29, 2018, at 5:49 AM, Richard Biener > wrote: > ... > It might be a "regression" with the POINTER_MINUS_EXPR introduction. > You can debug this with gdb when you break on 'pointer_diff'. For me > on x86_64 this builds a POINTER_DIFF_EXPR: (char *) - > of ptrdiff_t. That a

Re: not computable at load time

> On May 28, 2018, at 12:03 PM, Richard Biener > wrote: > > On May 28, 2018 12:45:04 PM GMT+02:00, Andreas Schwab wrote: >> On Mai 28 2018, Richard Biener wrote: >> >>> It means there's no relocation that can express the result of 's.f - >> ' >>> and the frontend doesn't consider this a

[PATCH, committed] fix ICE in test suite on pdp11

This cures an ICE caused by a wrong pattern that produces invalid register references. gcc/ChangeLog 2018-05-27 Paul Koning <n...@arrl.net> * config/pdp11/pdp11.md (truncsihi2): Remove. Index: config/pdp11/pd

Re: virtual-stack-vars reference not resolved in vregs

> On May 25, 2018, at 2:11 AM, Eric Botcazou wrote: > >> Is this something the back end is responsible for getting right, for example >> via the machine description file? If so, any hints where to start? > > The SUBREG of MEM is invalid at this stage. Thanks. That

[PATCH, committed] fix a number of pdp11 target test failures

Sorry, it's been a while, previous message was incomplete. This fixes a number of test failures due to test cases that are too large for pdp11 and should be skipped. Also one test case that asks for alignment larger than what pdp11 supports. paul 2018-05-25 Paul Koning &l

[PATCH, committed] fix a number of pdp11 target test failures

This fixes a number of test failures due to test cases that are too large for pdp11 and should be skipped. Also one test case that asks for alignment larger than what pdp11 supports. paul 2018-05-25 Paul Koning <n...@arrl.net> * gcc.c-torture/compile/20151204.c

not computable at load time

One of my testsuite failures for the pdp11 back end is gcc.c-torture/compile/930326-1.c which is: struct { char a, b, f[3]; } s; long i = s.f- It fails with "error: initializer element is not computable at load time". I don't understand why because it seems to be a perfectly reasonable

<    1   2   3   4   5   >