[Patch, Fortran] Test for implied sequence in structures in common blocks

Hi, I'd like to contribute this small test. I have legacy code which uses STRUCTURE statements in common blocks, and was happy to find Fritz's DEC support assumes ordering in STRUCTUREs, as the Oracle compiler does. Jim MacArthur -- 2016-09-13 Jim MacArthur * g

Re: [PATCH, PR69043, fortran] Trying to include a directory causes an infinite loop

On 24/12/15 16:38, Jim MacArthur wrote: Botstrapped and tested for regressions on x86_64-pc-linux-gnu. There is a test case for the bug included. I missed out the test case when creating the first patch. This one should have it. PR fortran/69043 * scanner.c (load_file): Abort and show

[PATCH, PR69043, fortran] Trying to include a directory causes an infinite loop

#x27;ve only been able to check it on a Linux system so far. Botstrapped and tested for regressions on x86_64-pc-linux-gnu. There is a test case for the bug included. My office is about to close for the Christmas holiday, so I apologise if I don't respond to questions promptly. 2015-12-

Re: [PATCH, fortran] Revival of AUTOMATIC patch

On Thu, Sep 24, 2015 at 10:58:41PM +0200, FX wrote: > > I think I appreciate what you are trying to do here. I don't intend to > > sound > > negative here, but if the keyword AUTOMATIC does nothing > > The testcase given is not an example of useful AUTOMATIC. I think it is > meant to be used to

[PATCH, fortran] Revival of AUTOMATIC patch

test cases pass. Mark Doffman's original emails were in January and February 2014 in case you want to review them. I am in the process of arranging copyright assignment. In the meantime, does this look remotely OK? 2015-09-23 Jim MacArthur * decl.c (match_attr_s

[PATCH][AARCH64][libgcc] Remove t-softfp-sfdf and t-softfp-excl from aarch64 configuration

In response to a comment from http://gcc.gnu.org/ml/gcc-patches/2012-05/msg01721.html, this patch removes t-softfp-sfdf and t-softfp-excl from the aarch64 entries in libgcc/config.host. Every setting in these files is overridden by t-softfp. Addition to libgcc/ChangeLog: 2012-06-01 Jim

[AARCH64][libgcc] Add __aarch64_sync_cache_range as lib2func

applied after the patch I suggested for t-aarch64: http://gcc.gnu.org/ml/gcc-patches/2012-05/msg01884.html. Additions to libgcc/ChangeLog: 2012-05-31 Jim MacArthur * config.host (aarch64*-*-elf): Add t-aarch64. (aarch64*-*-linux*): Add t-aarch64, remove t-linux. * config

[PATCH][AARCH64] Remove t-aarch64 from libgcc

Jim MacArthur * config/aarch64/t-aarch64: Delete. * config.host (aarch64*-*-elf): Remove reference to t-aarch64. diff --git a/libgcc/config.host b/libgcc/config.host index ccd0fa1..56beddd 100644 --- a/libgcc/config.host +++ b/libgcc/config.host @@ -291,7 +291,6 @@ case ${host

Re: [patch] More thorough checking in reg_fits_class_p

On 02/05/12 14:55, Richard Sandiford wrote: Richard Earnshaw writes: On 02/05/12 14:00, Richard Sandiford wrote: Jim MacArthur writes: New Changelog text: 2012-05-02 Jim MacArthur * recog.c (reg_fits_class_p): Check both regno and regno + offset are hard registers. Thanks. I still think

Re: [patch] More thorough checking in reg_fits_class_p

On 30/04/12 16:19, Richard Sandiford wrote: Richard Earnshaw writes: On 30/04/12 15:39, Richard Sandiford wrote: Richard Earnshaw writes: On 30/04/12 15:07, Richard Sandiford wrote: Richard Earnshaw writes: On 26/04/12 14:20, Jim MacArthur wrote: The current code in reg_fits_class_p

[patch] More thorough checking in reg_fits_class_p

ith an x86 bootstrap which shows no errors, and with our own AArch64 back end. Ok for trunk? gcc/Changelog entry: 2012-04-26 Jim MacArthur * recog.c (reg_fits_class_p): Check every register between regno and regno+offset is in the hard register set. diff --git a/gcc/recog.c b/g