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 element’s formal is not properly set, the rest of the generic linked list is ignored. Here is a variant of the testcase committed. It shows no error if the module procedure line is commented, and two errors if it’s uncommented, one error saying that the write of z2 should use DTIO. The latter error should not appear. thanks for the comment, and sorry that I didn't notice this problem. The attached patch should fix it. What do you think about it? Yes, it looks good. Btw, with trunk r243776 I get an ICE on your test case, when the module procedure is commented out. You don't see this? My trunk is from the 8 december (r243465), and I don’t see it. So it should be a quite recent regression. Mikael
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, and I think it’s not as innocent as it >>> seems. >>> With it, if the first element’s formal is not properly set, the rest of >>> the >>> generic linked list is ignored. >>> >>> Here is a variant of the testcase committed. >>> It shows no error if the module procedure line is commented, and two >>> errors >>> if it’s uncommented, one error saying that the write of z2 should use >>> DTIO. >>> The latter error should not appear. >> >> >> thanks for the comment, and sorry that I didn't notice this problem. >> >> The attached patch should fix it. What do you think about it? >> > Yes, it looks good. Ok, will commit this to trunk together with your test case. >> Btw, with trunk r243776 I get an ICE on your test case, when the >> module procedure is commented out. You don't see this? >> > My trunk is from the 8 december (r243465), and I don’t see it. > So it should be a quite recent regression. That confirms my suspicion that it was introduced by r243609. Thanks again for finding both of these problems ;) Cheers, Janus
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 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 element’s formal is not properly set, the rest of the generic linked list is ignored. Here is a variant of the testcase committed. It shows no error if the module procedure line is commented, and two errors if it’s uncommented, one error saying that the write of z2 should use DTIO. The latter error should not appear. >>> >>> >>> thanks for the comment, and sorry that I didn't notice this problem. >>> >>> The attached patch should fix it. What do you think about it? >>> >> Yes, it looks good. > > Ok, will commit this to trunk together with your test case. Committed as r243783 after successful regtest: https://gcc.gnu.org/viewcvs?rev=243783&root=gcc&view=rev Cheers, Janus
[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?
2016-12-18 Ville Voutilainen
Make the perfect-forwarding constructor of a two-element tuple
sfinae away when the first argument is an allocator_arg.
* include/std/tuple (tuple(_U1&&, _U2&&)): Constrain.
* testsuite/20_util/tuple/cons/allocator_with_any.cc: New.
* testsuite/20_util/tuple/element_access/get_neg.cc: Adjust.
diff --git a/libstdc++-v3/include/std/tuple b/libstdc++-v3/include/std/tuple
index 13e0bf8..9dbdd8d 100644
--- a/libstdc++-v3/include/std/tuple
+++ b/libstdc++-v3/include/std/tuple
@@ -951,7 +951,9 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
enable_if<_TMC::template
_MoveConstructibleTuple<_U1, _U2>()
&& _TMC::template
-_ImplicitlyMoveConvertibleTuple<_U1, _U2>(),
+_ImplicitlyMoveConvertibleTuple<_U1, _U2>()
+ && !is_same::type,
+ allocator_arg_t>::value,
bool>::type = true>
constexpr tuple(_U1&& __a1, _U2&& __a2)
: _Inherited(std::forward<_U1>(__a1), std::forward<_U2>(__a2)) { }
@@ -960,7 +962,9 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
enable_if<_TMC::template
_MoveConstructibleTuple<_U1, _U2>()
&& !_TMC::template
-_ImplicitlyMoveConvertibleTuple<_U1, _U2>(),
+_ImplicitlyMoveConvertibleTuple<_U1, _U2>()
+ && !is_same::type,
+ allocator_arg_t>::value,
bool>::type = false>
explicit constexpr tuple(_U1&& __a1, _U2&& __a2)
: _Inherited(std::forward<_U1>(__a1), std::forward<_U2>(__a2)) { }
diff --git a/libstdc++-v3/testsuite/20_util/tuple/cons/allocator_with_any.cc
b/libstdc++-v3/testsuite/20_util/tuple/cons/allocator_with_any.cc
new file mode 100644
index 000..9f86c93
--- /dev/null
+++ b/libstdc++-v3/testsuite/20_util/tuple/cons/allocator_with_any.cc
@@ -0,0 +1,42 @@
+// { dg-do run { target c++14 } }
+
+// Copyright (C) 2016 Free Software Foundation, Inc.
+//
+// This file is part of the GNU ISO C++ Library. This library 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.
+
+// This library 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.
+
+// You should have received a copy of the GNU General Public License along
+// with this library; see the file COPYING3. If not see
+//
[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): Reject invalid pass
name.
testsuite/
* gcc.dg/gimplefe-19.c: New test-case.
diff --git a/gcc/c/gimple-parser.c b/gcc/c/gimple-parser.c
index ddecaec..ec1dbb3 100644
--- 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;
+ if (pass)
+{
+ char *full_passname = (char *) xmalloc (strlen ("tree-") + strlen (pass)
+ 1);
+ strcpy (full_passname, "tree-");
+ strcat (full_passname, pass);
+ opt_pass *p = g->get_passes ()->get_pass_by_name (full_passname);
+ if (!p || p->type != GIMPLE_PASS)
+ error_at (c_parser_peek_token (parser)->location,
+ "%s is not a valid GIMPLE pass\n", pass);
+ free (full_passname);
+}
return pass;
}
diff --git a/gcc/testsuite/gcc.dg/gimplefe-19.c
b/gcc/testsuite/gcc.dg/gimplefe-19.c
new file mode 100644
index 000..bb5be33
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/gimplefe-19.c
@@ -0,0 +1,7 @@
+/* { dg-do compile } */
+/* { dg-options "-O -fgimple" } */
+
+void __GIMPLE (startwith ("combine")) foo () /* { dg-error "not a valid
GIMPLE pass" } */
+{
+ return;
+}
[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): Generate non-typebound DTIO call for class
variables, if no typebound DTIO procedure is available.
2016-12-18 Janus Weil
PR fortran/78848
* gfortran.dg/dtio_22.f90: New test.
Index: gcc/fortran/trans-io.c
===
--- gcc/fortran/trans-io.c (revision 243776)
+++ gcc/fortran/trans-io.c (working copy)
@@ -2180,9 +2180,31 @@ get_dtio_proc (gfc_typespec * ts, gfc_code * code,
formatted = true;
}
- if (ts->type == BT_DERIVED)
+ if (ts->type == BT_CLASS)
+derived = ts->u.derived->components->ts.u.derived;
+ else
+derived = ts->u.derived;
+
+ gfc_symtree *tb_io_st = gfc_find_typebound_dtio_proc (derived,
+ last_dt == WRITE, formatted);
+ if (ts->type == BT_CLASS && tb_io_st)
{
- derived = ts->u.derived;
+ // polymorphic DTIO call (based on the dynamic type)
+ gfc_se se;
+ gfc_expr *expr = gfc_find_and_cut_at_last_class_ref (code->expr1);
+ gfc_add_vptr_component (expr);
+ gfc_add_component_ref (expr,
+tb_io_st->n.tb->u.generic->specific_st->name);
+ *dtio_sub = tb_io_st->n.tb->u.generic->specific->u.specific->n.sym;
+ gfc_init_se (&se, NULL);
+ se.want_pointer = 1;
+ gfc_conv_expr (&se, expr);
+ gfc_free_expr (expr);
+ return se.expr;
+}
+ else
+{
+ // non-polymorphic DTIO call (based on the declared type)
*dtio_sub = gfc_find_specific_dtio_proc (derived, last_dt == WRITE,
formatted);
@@ -2189,32 +2211,8 @@ get_dtio_proc (gfc_typespec * ts, gfc_code * code,
if (*dtio_sub)
return gfc_build_addr_expr (NULL, gfc_get_symbol_decl (*dtio_sub));
}
- else if (ts->type == BT_CLASS)
-{
- gfc_symtree *tb_io_st;
- derived = ts->u.derived->components->ts.u.derived;
- tb_io_st = gfc_find_typebound_dtio_proc (derived,
- last_dt == WRITE, formatted);
- if (tb_io_st)
- {
- gfc_se se;
- gfc_expr *expr = gfc_find_and_cut_at_last_class_ref (code->expr1);
- gfc_add_vptr_component (expr);
- gfc_add_component_ref (expr,
-tb_io_st->n.tb->u.generic->specific_st->name);
- *dtio_sub = tb_io_st->n.tb->u.generic->specific->u.specific->n.sym;
- gfc_init_se (&se, NULL);
- se.want_pointer = 1;
- gfc_conv_expr (&se, expr);
- gfc_free_expr (expr);
- return se.expr;
- }
-}
-
-
return NULL_TREE;
-
}
/* Generate the call for a scalar transfer node. */
! { dg-do run }
!
! PR 78848: [OOP] ICE on writing CLASS variable with non-typebound DTIO procedure
!
! Contributed by Mikael Morin
module m
type :: t
integer :: i = 123
end type
interface write(formatted)
procedure wf
end interface
contains
subroutine wf(this, unit, b, c, iostat, iomsg)
class(t), intent(in) :: this
integer, intent(in) :: unit
character, intent(in) :: b
integer, intent(in) :: c(:)
integer, intent(out) :: iostat
character, intent(inout) :: iomsg
write (unit, "(i3)", IOSTAT=iostat, IOMSG=iomsg) this%i
end subroutine
end
program p
use m
character(3) :: buffer
class(t), allocatable :: z
allocate(z)
write(buffer,"(DT)") z
if (buffer /= "123") call abort()
end
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;
>
> + if (pass)
> +{
> + char *full_passname = (char *) xmalloc (strlen ("tree-") + strlen
> (pass) + 1);
> + strcpy (full_passname, "tree-");
> + strcat (full_passname, pass);
Use
char *full_passname = concat ("tree-", pass, NULL);
instead?
Jakub
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, specific DTIO procedures are found in generic interfaces, they could be added to the derived type's vtable. This is possibly an unnecessary embellishment but it could be done. Please commit this fix for now, however. Thanks Paul On 18 December 2016 at 13:12, Janus Weil wrote: > 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): Generate non-typebound DTIO call for class > variables, if no typebound DTIO procedure is available. > > 2016-12-18 Janus Weil > > PR fortran/78848 > * gfortran.dg/dtio_22.f90: New test. -- If you're walking down the right path and you're willing to keep walking, eventually you'll make progress. Barack Obama
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_CLOSE_PAREN, "expected %<)%>"))
>> return NULL;
>>
>> + if (pass)
>> +{
>> + char *full_passname = (char *) xmalloc (strlen ("tree-") + strlen
>> (pass) + 1);
>> + strcpy (full_passname, "tree-");
>> + strcat (full_passname, pass);
>
> Use
> char *full_passname = concat ("tree-", pass, NULL);
> instead?
Thanks! Modified the patch to use concat().
Regards,
Prathamesh
>
> Jakub
2016-12-18 Prathamesh Kulkarni
c/
* gimple-parser.c (c_parser_gimple_pass_list): Reject invalid pass
name.
testsuite/
* gcc.dg/gimplefe-19.c: New test-case.
diff --git a/gcc/c/gimple-parser.c b/gcc/c/gimple-parser.c
index ddecaec..68d2d74 100644
--- a/gcc/c/gimple-parser.c
+++ b/gcc/c/gimple-parser.c
@@ -1046,6 +1046,15 @@ c_parser_gimple_pass_list (c_parser *parser)
if (! c_parser_require (parser, CPP_CLOSE_PAREN, "expected %<)%>"))
return NULL;
+ if (pass)
+{
+ char *full_passname = concat ("tree-", pass, NULL);
+ opt_pass *p = g->get_passes ()->get_pass_by_name (full_passname);
+ if (!p || p->type != GIMPLE_PASS)
+ error_at (c_parser_peek_token (parser)->location,
+ "%s is not a valid GIMPLE pass\n", pass);
+ free (full_passname);
+}
return pass;
}
diff --git a/gcc/testsuite/gcc.dg/gimplefe-19.c
b/gcc/testsuite/gcc.dg/gimplefe-19.c
new file mode 100644
index 000..bb5be33
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/gimplefe-19.c
@@ -0,0 +1,7 @@
+/* { dg-do compile } */
+/* { dg-options "-O -fgimple" } */
+
+void __GIMPLE (startwith ("combine")) foo () /* { dg-error "not a valid
GIMPLE pass" } */
+{
+ return;
+}
[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 *arm_cmpdi_insn is directly
followed by a *arm_cmpdi_unsigned instruction, both are split
up into this:
[(set (reg:CC CC_REGNUM)
(compare:CC (match_dup 0) (match_dup 1)))
(parallel [(set (reg:CC CC_REGNUM)
(compare:CC (match_dup 3) (match_dup 4)))
(set (match_dup 2)
(minus:SI (match_dup 5)
(ltu:SI (reg:CC_C CC_REGNUM) (const_int
0])]
[(set (reg:CC CC_REGNUM)
(compare:CC (match_dup 2) (match_dup 3)))
(cond_exec (eq:SI (reg:CC CC_REGNUM) (const_int 0))
(set (reg:CC CC_REGNUM)
(compare:CC (match_dup 0) (match_dup 1]
The problem is that the reg:CC from the *subsi3_carryin_compare
is not mentioning that the reg:CC is also dependent on the reg:CC
from before. Therefore the *arm_cmpsi_insn appears to be
redundant and thus got removed, because the data values are identical.
I think that applies to a number of similar pattern where data
flow is happening through the CC reg.
So this is a kind of correctness issue, and should be fixed
independently from the optimization issue PR77308.
Therefore I think the patterns need to specify the true
value that will be in the CC reg, in order for cse to
know what the instructions are really doing.
Bootstrapped and reg-tested on arm-linux-gnueabihf.
Is it OK for trunk?
Thanks
Bernd.
[1] https://gcc.gnu.org/ml/gcc-patches/2016-12/msg00680.html
2016-12-10 Bernd Edlinger
PR target/77308
* config/arm/arm.md (adddi3_compareV, *addsi3_compareV_upper,
adddi3_compareC, *addsi3_compareC_upper, subdi3_compare1,
subsi3_carryin_compare, subsi3_carryin_compare_const,
negdi2_compare, *negsi2_carryin_compare,
*arm_cmpdi_insn): Fix the CC reg dataflow.
Index: gcc/config/arm/arm.md
===
--- gcc/config/arm/arm.md (revision 243515)
+++ gcc/config/arm/arm.md (working copy)
@@ -669,17 +669,15 @@
(set (match_dup 0) (plus:SI (match_dup 1) (match_dup 2)))])
(parallel [(set (reg:CC_V CC_REGNUM)
(ne:CC_V
- (plus:DI (plus:DI
- (sign_extend:DI (match_dup 4))
- (sign_extend:DI (match_dup 5)))
- (ltu:DI (reg:CC_C CC_REGNUM) (const_int 0)))
- (plus:DI (sign_extend:DI
- (plus:SI (match_dup 4) (match_dup 5)))
- (ltu:DI (reg:CC_C CC_REGNUM) (const_int 0)
- (set (match_dup 3) (plus:SI (plus:SI
- (match_dup 4) (match_dup 5))
- (ltu:SI (reg:CC_C CC_REGNUM)
- (const_int 0])]
+ (plus:DI (plus:DI (sign_extend:DI (match_dup 4))
+ (sign_extend:DI (match_dup 5)))
+ (ltu:DI (reg:CC_C CC_REGNUM) (const_int 0)))
+ (sign_extend:DI
+ (plus:SI (plus:SI (match_dup 4) (match_dup 5))
+ (ltu:SI (reg:CC_C CC_REGNUM) (const_int 0))
+ (set (match_dup 3) (plus:SI (plus:SI (match_dup 4) (match_dup 5))
+ (ltu:SI (reg:CC_C CC_REGNUM)
+ (const_int 0])]
"
{
operands[3] = gen_highpart (SImode, operands[0]);
@@ -713,13 +711,13 @@
[(set (reg:CC_V CC_REGNUM)
(ne:CC_V
(plus:DI
- (plus:DI
- (sign_extend:DI (match_operand:SI 1 "register_operand" "r"))
- (sign_extend:DI (match_operand:SI 2 "register_operand" "r")))
- (ltu:DI (reg:CC_C CC_REGNUM) (const_int 0)))
- (plus:DI (sign_extend:DI
- (plus:SI (match_dup 1) (match_dup 2)))
- (ltu:DI (reg:CC_C CC_REGNUM) (const_int 0)
+ (plus:DI
+ (sign_extend:DI (match_operand:SI 1 "register_operand" "r"))
+ (sign_extend:DI (match_operand:SI 2 "register_operand" "r")))
+ (ltu:DI (reg:CC_C CC_REGNUM) (const_int 0)))
+ (sign_extend:DI (plus:SI (plus:SI (match_dup 1) (match_dup 2))
+ (ltu:SI (reg:CC_C CC_REGNUM)
+ (const_int 0))
(set (match_operand:SI 0 "register_operand" "=r")
(plus:SI
(plus:SI (match_dup 1) (match_dup 2))
@@ -748,17 +746,15 @@
(set (match_dup 0) (plus:SI (match_dup 1) (match_dup 2)))])
(parallel [(set (reg:CC_C CC_REGNUM)
(ne:CC_C
- (plus:DI (plus:DI
- (zero_extend:DI (match_dup 4))
- (zero_extend:DI (match_dup 5)))
- (ltu:DI (reg:CC_C CC_REGNUM) (const_int 0)))
- (plus:DI (zero_extend:DI
- (plus:SI (match_dup 4) (match_dup 5)))
- (ltu:DI (reg:CC_C CC_REGNUM) (const_int 0)
- (set (match_dup 3) (plus:SI
- (plus:SI (match_dup 4) (match_dup 5))
- (ltu:SI (reg:CC_C CC_REGNUM)
- (const_int 0])]
+ (plus:DI (plus:DI (zero_extend:DI (match_dup 4))
+ (zero_extend:DI (match_dup 5)))
+ (ltu:DI (reg:CC_C CC_REGNUM) (const_int 0)))
+ (zero_extend:DI
+ (plus:SI (plus:SI (match_dup 4) (matc
[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] before it can be applied.
Bootstrapped and reg-tested on arm-linux-gnueabihf.
Is it OK for trunk?
Thanks
Bernd.
[1] https://gcc.gnu.org/ml/gcc-patches/2016-11/msg02796.html
[2] https://gcc.gnu.org/ml/gcc-patches/2016-12/msg01562.html
2016-12-18 Bernd Edlinger
PR target/77308
* config/arm/arm.md (*arm_negdi2, *arm_cmpdi_insn,
*arm_cmpdi_unsigned): Split early except for TARGET_NEON and
TARGET_IWMMXT.
testsuite:
2016-12-18 Bernd Edlinger
PR target/77308
* gcc.target/arm/pr77308-2.c: New test.
Index: gcc/config/arm/arm.md
===
--- gcc/config/arm/arm.md (revision 243782)
+++ gcc/config/arm/arm.md (working copy)
@@ -4689,7 +4689,7 @@
"TARGET_32BIT"
"#" ; rsbs %Q0, %Q1, #0; rsc %R0, %R1, #0 (ARM)
; negs %Q0, %Q1; sbc %R0, %R1, %R1, lsl #1 (Thumb-2)
- "&& reload_completed"
+ "&& ((!TARGET_NEON && !TARGET_IWMMXT) || reload_completed)"
[(parallel [(set (reg:CC CC_REGNUM)
(compare:CC (const_int 0) (match_dup 1)))
(set (match_dup 0) (minus:SI (const_int 0) (match_dup 1)))])
@@ -7359,7 +7359,7 @@
(clobber (match_scratch:SI 2 "=r"))]
"TARGET_32BIT"
"#" ; "cmp\\t%Q0, %Q1\;sbcs\\t%2, %R0, %R1"
- "&& reload_completed"
+ "&& ((!TARGET_NEON && !TARGET_IWMMXT) || reload_completed)"
[(set (reg:CC CC_REGNUM)
(compare:CC (match_dup 0) (match_dup 1)))
(parallel [(set (reg:CC CC_REGNUM)
@@ -7383,7 +7383,10 @@
operands[5] = gen_rtx_MINUS (SImode, operands[3], operands[4]);
}
operands[1] = gen_lowpart (SImode, operands[1]);
-operands[2] = gen_lowpart (SImode, operands[2]);
+if (can_create_pseudo_p ())
+ operands[2] = gen_reg_rtx (SImode);
+else
+ operands[2] = gen_lowpart (SImode, operands[2]);
}
[(set_attr "conds" "set")
(set_attr "length" "8")
@@ -7397,7 +7400,7 @@
"TARGET_32BIT"
"#" ; "cmp\\t%R0, %R1\;it eq\;cmpeq\\t%Q0, %Q1"
- "&& reload_completed"
+ "&& ((!TARGET_NEON && !TARGET_IWMMXT) || reload_completed)"
[(set (reg:CC CC_REGNUM)
(compare:CC (match_dup 2) (match_dup 3)))
(cond_exec (eq:SI (reg:CC CC_REGNUM) (const_int 0))
Index: gcc/testsuite/gcc.target/arm/pr77308-2.c
===
--- gcc/testsuite/gcc.target/arm/pr77308-2.c (revision 0)
+++ gcc/testsuite/gcc.target/arm/pr77308-2.c (working copy)
@@ -0,0 +1,169 @@
+/* { dg-do compile } */
+/* { dg-options "-Os -Wstack-usage=2500" } */
+
+/* This is a modified algorithm with 64bit cmp and neg at the Sigma-blocks.
+ It improves the test coverage of cmpdi and negdi2 patterns.
+ Unlike the original test case these insns can reach the reload pass,
+ which may result in large stack usage. */
+
+#define SHA_LONG64 unsigned long long
+#define U64(C) C##ULL
+
+#define SHA_LBLOCK 16
+#define SHA512_CBLOCK (SHA_LBLOCK*8)
+
+typedef struct SHA512state_st {
+SHA_LONG64 h[8];
+SHA_LONG64 Nl, Nh;
+union {
+SHA_LONG64 d[SHA_LBLOCK];
+unsigned char p[SHA512_CBLOCK];
+} u;
+unsigned int num, md_len;
+} SHA512_CTX;
+
+static const SHA_LONG64 K512[80] = {
+U64(0x428a2f98d728ae22), U64(0x7137449123ef65cd),
+U64(0xb5c0fbcfec4d3b2f), U64(0xe9b5dba58189dbbc),
+U64(0x3956c25bf348b538), U64(0x59f111f1b605d019),
+U64(0x923f82a4af194f9b), U64(0xab1c5ed5da6d8118),
+U64(0xd807aa98a3030242), U64(0x12835b0145706fbe),
+U64(0x243185be4ee4b28c), U64(0x550c7dc3d5ffb4e2),
+U64(0x72be5d74f27b896f), U64(0x80deb1fe3b1696b1),
+U64(0x9bdc06a725c71235), U64(0xc19bf174cf692694),
+U64(0xe49b69c19ef14ad2), U64(0xefbe4786384f25e3),
+U64(0x0fc19dc68b8cd5b5), U64(0x240ca1cc77ac9c65),
+U64(0x2de92c6f592b0275), U64(0x4a7484aa6ea6e483),
+U64(0x5cb0a9dcbd41fbd4), U64(0x76f988da831153b5),
+U64(0x983e5152ee66dfab), U64(0xa831c66d2db43210),
+U64(0xb00327c898fb213f), U64(0xbf597fc7beef0ee4),
+U64(0xc6e00bf33da88fc2), U64(0xd5a79147930aa725),
+U64(0x06ca6351e003826f), U64(0x142929670a0e6e70),
+U64(0x27b70a8546d22ffc), U64(0x2e1b21385c26c926),
+U64(0x4d2c6dfc5ac42aed), U64(0x53380d139d95b3df),
+U64(0x650a73548baf63de), U64(0x766a0abb3c77b2a8),
+U64(0x81c2c92e47edaee6), U64(0x92722c851482353b),
+U64(0xa2bfe8a14cf10364), U64(0xa81a664bbc423001),
+U64(0xc24b8b70d0f89791), U64(0xc76c51a30654be30),
+U64(0xd192e819d6ef5218), U64(0xd69906245565a910),
+U64(0xf40e35855771202a), U64(0x106aa07032bbd1b8),
+U64(0x19a4c116b8d2d0c8), U64(0x1e376c085141ab53),
+U64(0x2748774cdf8eeb99), U64(0x34b0bcb5e19b48a8),
+U64(0x391c0cb3c5c95a63), U64(0x4ed8aa4ae3418acb),
+U64(0x5b9cca4f7763e373), U64(0x682e6ff3d6b2b8a3),
+
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 > possible. If, as each derived type is being resolved, specific DTIO > procedures are found in generic interfaces, they could be added to the > derived type's vtable. This is possibly an unnecessary embellishment > but it could be done. Please commit this fix for now, however. Yes, I agree that technically it would be possible to do this. However, I doubt that the standard requires us to do it. I just had a look in chapter 9.5.3.7.3 of the F03 standard, which says: (2) A suitable user-defined derived-type input/output procedure is available; that is, either (a) the declared type of the effective item has a suitable generic type-bound procedure, or (b) a suitable generic interface is accessible. If (2a) is true, the procedure referenced is determined as for explicit type-bound procedure references (12.4); that is, the binding with the appropriate specific interface is located in the declared type of the effective item, and the corresponding binding in the dynamic type of the effective item is selected. 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. --- To me this sound like a typebound DTIO procedure should indeed behave differently than a non-typebound one, thus I think what you're proposing is not necessary. Do you agree? Cheers, Janus > On 18 December 2016 at 13:12, Janus Weil wrote: >> 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): Generate non-typebound DTIO call for class >> variables, if no typebound DTIO procedure is available. >> >> 2016-12-18 Janus Weil >> >> PR fortran/78848 >> * gfortran.dg/dtio_22.f90: New test. > > > > -- > If you're walking down the right path and you're willing to keep > walking, eventually you'll make progress. > > Barack Obama
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 part of the standard and thought that it was rather ambiguous. What determines "appropriate specific interface"? That's why I asked the question. > > To me this sound like a typebound DTIO procedure should indeed behave > differently than a non-typebound one, thus I think what you're > proposing is not necessary. Do you agree? I think that in the circumstances, it is not. Ciao Paul > > Cheers, > Janus > > > > >> On 18 December 2016 at 13:12, Janus Weil wrote: >>> 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): Generate non-typebound DTIO call for class >>> variables, if no typebound DTIO procedure is available. >>> >>> 2016-12-18 Janus Weil >>> >>> PR fortran/78848 >>> * gfortran.dg/dtio_22.f90: New test. >> >> >> >> -- >> If you're walking down the right path and you're willing to keep >> walking, eventually you'll make progress. >> >> Barack Obama -- If you're walking down the right path and you're willing to keep walking, eventually you'll make progress. Barack Obama
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 (core dumped) I've had a quick look by adding printfs in go-main.c and further to see up to where it goes before crashing. It crashes in src/libgo/runtime/go-caller.c in function __go_get_backtrace_state, inside the stat() call in: if (__builtin_strchr (filename, '/') == NULL) filename = NULL; if (stat (filename, &s) < 0 || s.st_size < 1024) filename = NULL; filename of course doesn't start with '/' (it's argv[0]), and thus NULL is passed to stat(). It happens that by luck on Linux this just returns an EFAULT error, but that's sheer luck :) This should probably be turned into e.g.: if (!filename || stat (filename, &s) < 0 || s.st_size < 1024) filename = NULL; as the attached patch does, which should really be applied or done any other way. Then calling go-6 brings this: fatal error: libbacktrace could not find executable to open That's inside src/libbacktrace/fileline.c, the fileline_initialize function, which tries the above filename (and thus fails), then getexecname() (which is not implemented), then /proc/self/exe, which is not implemented, then /proc/curproc/file which is even less implemented. So here it'd be "just" a matter of implementing /proc/self/exe. Samuel Index: runtime/go-caller.c === --- runtime/go-caller.c (révision 235086) +++ runtime/go-caller.c (copie de travail) @@ -93,7 +93,7 @@ argv[0] (http://gcc.gnu.org/PR61895). It would be nice to have a better check for whether this file is the real executable. */ - if (stat (filename, &s) < 0 || s.st_size < 1024) + if (!filename || stat (filename, &s) < 0 || s.st_size < 1024) filename = NULL; back_state = backtrace_create_state (filename, 1, error_callback, NULL);
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. Samuel Index: gcc/src/libgo/runtime/go-caller.c === --- gcc/src/libgo/runtime/go-caller.c (révision 235086) +++ gcc/src/libgo/runtime/go-caller.c (copie de travail) @@ -93,7 +93,7 @@ argv[0] (http://gcc.gnu.org/PR61895). It would be nice to have a better check for whether this file is the real executable. */ - if (stat (filename, &s) < 0 || s.st_size < 1024) + if (filename != NULL && (stat (filename, &s) < 0 || s.st_size < 1024)) filename = NULL; back_state = backtrace_create_state (filename, 1, error_callback, NULL);
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.
