Re: [Patch, Fortran, committed] PR 78592: [7 Regression] ICE in gfc_find_specific_dtio_proc, at fortran/interface.c:4939

Le 17/12/2016 à 22:49, Janus Weil a écrit : Hi Mikael, I have just committed a completely obvious patch for this PR. All it does is rearrange some expressions to avoid an ICE (see attachment): I have made a late review of it, and I think it’s not as innocent as it seems. With it, if the first

Re: [Patch, Fortran, committed] PR 78592: [7 Regression] ICE in gfc_find_specific_dtio_proc, at fortran/interface.c:4939

2016-12-18 11:18 GMT+01:00 Mikael Morin : > Le 17/12/2016 à 22:49, Janus Weil a écrit : >> >> Hi Mikael, >> I have just committed a completely obvious patch for this PR. All it does is rearrange some expressions to avoid an ICE (see attachment): >>> I have made a late review of it, a

Re: [Patch, Fortran, committed] PR 78592: [7 Regression] ICE in gfc_find_specific_dtio_proc, at fortran/interface.c:4939

2016-12-18 11:25 GMT+01:00 Janus Weil : > 2016-12-18 11:18 GMT+01:00 Mikael Morin : >> Le 17/12/2016 à 22:49, Janus Weil a écrit : >>> >>> Hi Mikael, >>> > I have just committed a completely obvious patch for this PR. All it > does is rearrange some expressions to avoid an ICE (see attachme

[v3 PATCH] Make the perfect-forwarding constructor of a two-element tuple sfinae away when the first argument is an allocator_arg.

Andrzej Krzemienski pointed this out in a discussion related to any and tags. Our two-element tuple specialization doesn't make the perfect-forwarding constructor and the allocator constructor properly mutually exclusive; this patch fixes that. Tested on Linux-x64, ok for trunk, gcc-6 and gcc-5?

[gimplefe] reject invalid pass name in startwith

Hi Richard, The attached patch attempts to reject invalid pass-name in startwith and verified gimplefe tests pass with the patch (not sure if bootstrap is required?) Does it look OK ? Thanks, Prathamesh 2016-12-18 Prathamesh Kulkarni c/ * gimple-parser.c (c_parser_gimple_pass_list): Re

[Patch, Fortran, OOP] PR 78848: [7 Regression] ICE on writing CLASS variable with non-typebound DTIO procedure

Hi all, the attached patch fixes an ICE on a valid DTIO example, which is in fact a regression of one of my recent patches. See bugzilla for details. Regtests cleanly on x86_64-linux-gnu. Ok for trunk? Cheers, Janus 2016-12-18 Janus Weil PR fortran/78848 * trans-io.c (get_dtio_proc

Re: [gimplefe] reject invalid pass name in startwith

On Sun, Dec 18, 2016 at 05:41:23PM +0530, Prathamesh Kulkarni wrote: > --- a/gcc/c/gimple-parser.c > +++ b/gcc/c/gimple-parser.c > @@ -1046,6 +1046,17 @@ c_parser_gimple_pass_list (c_parser *parser) >if (! c_parser_require (parser, CPP_CLOSE_PAREN, "expected %<)%>")) > return NULL; > > +

Re: [Patch, Fortran, OOP] PR 78848: [7 Regression] ICE on writing CLASS variable with non-typebound DTIO procedure

Hi Janus, Thanks for taking on the cleaning up of the dtio for me. I am up to my eyeballs in things other than gfortran. This patch is OK for trunk since it fixes a regression. Looking at it, though, I realised that dynamic dispatch would be possible. If, as each derived type is being resolved,

Re: [gimplefe] reject invalid pass name in startwith

On 18 December 2016 at 18:02, Jakub Jelinek wrote: > On Sun, Dec 18, 2016 at 05:41:23PM +0530, Prathamesh Kulkarni wrote: >> --- a/gcc/c/gimple-parser.c >> +++ b/gcc/c/gimple-parser.c >> @@ -1046,6 +1046,17 @@ c_parser_gimple_pass_list (c_parser *parser) >>if (! c_parser_require (parser, CPP_C

[PATCH, ARM] correctly encode the CC reg data flow

Hi, this is related to PR77308, the follow-up patch will depend on this one. When trying the split the *arm_cmpdi_insn and *arm_cmpdi_unsigned before reload, a mis-compilation in libgcc function __gnu_satfractdasq was discovered, see [1] for more details. The reason seems to be that when the *ar

[PATCH, ARM] Further improve stack usage in sha512, part 2 (PR 77308)

Hi, this splits the *arm_negdi2, *arm_cmpdi_insn and *arm_cmpdi_unsigned also at split1 except for TARGET_NEON and TARGET_IWMMXT. In the new test case the stack is reduced to about 270 bytes, except for neon and iwmmxt, where this does not change anything. This patch depends on [1] and [2] befor

Re: [Patch, Fortran, OOP] PR 78848: [7 Regression] ICE on writing CLASS variable with non-typebound DTIO procedure

Hi Paul, > Thanks for taking on the cleaning up of the dtio for me. I am up to my > eyeballs in things other than gfortran. > > This patch is OK for trunk since it fixes a regression. thanks for the review. Committed as r243784. > Looking at it, though, I realised that dynamic dispatch would be

Re: [Patch, Fortran, OOP] PR 78848: [7 Regression] ICE on writing CLASS variable with non-typebound DTIO procedure

Dear Janus, > If (2a) is false and (2b) is true, the reference is to the procedure > identified by the appropriate specific > interface in the interface block. This reference shall not be to a > dummy procedure that is not present, > or to a disassociated procedure pointer. > I also reread this p

Re: Hurd port for gcc go PATCH 1-4(23)

Hello, Svante Signell, on Fri 25 Nov 2016 20:57:26 +0100, wrote: > Another more annoying gnumch/hurd/glibc bug is that the > built program go (go-6 in Debian) gets killed when executed from the > shell vi path, but not when issued directly: /usr/bin/go-6 works fine. >  go-6 > Segmentation fault (c

Re: Hurd port for gcc go PATCH 1-4(23)

Samuel Thibault, on Mon 19 Dec 2016 00:25:35 +0100, wrote: > as the attached patch does, which should really be applied or done > any other way. Or rather this patch, which makes it more like the test above. Matthias, I'm committing this to Debian's gcc-6, along the other go patches from Svante.

Re: [PING**2] [PATCH, ARM] Further improve stack usage on sha512 (PR 77308)

Ping... On 12/12/16 06:59, Bernd Edlinger wrote: > Ping... > > On 12/05/16 14:41, Bernd Edlinger wrote: >> Hi, >> >> this was the latest version of my patch: >> https://gcc.gnu.org/ml/gcc-patches/2016-11/msg02796.html >> >> >> Thanks >> Bernd.