[wwwdocs] Always set the language to English
...not just for "standard" pages, those that used to be XHTML and are now HTML 5. On the way remove traces of XHTML around that, which were still fine, but not necessary. Committed. Gerald Index: style.mhtml === RCS file: /cvs/gcc/wwwdocs/htdocs/style.mhtml,v retrieving revision 1.157 diff -u -r1.157 style.mhtml --- style.mhtml 29 Sep 2018 17:28:15 - 1.157 +++ style.mhtml 30 Sep 2018 07:26:21 - @@ -10,19 +10,17 @@ > -;;; Redefine the tag so that we can put XHTML attributes inside. +;;; Redefine the tag. - - + - http://www.w3.org/1999/xhtml"; xml:lang="en" lang="en"> + %body - > -> + ;;; Redefine the tag so that we can add default headers.
Re: [Patch, fortran] PRs 70752 and 72709 - more deferred character length bugs
Hi Dominique, It's the patch for pr70752 that causes the trouble, which I had guessed from the point in trans.c where the ICE occurs. I am onto it. Thanks again Paul On Wed, 26 Sep 2018 at 16:52, Dominique d'Humières wrote: > > > Is se->string_length guaranteed to be of type gfc_array_index_type_here? > > If so, why? And if not, maybe a fold_convert is in order? > > I don’t know if this related, but if I build gfortran with the patches for > PRs 70752 and 72709, 70149, and 65677 with --enable-checking=yes, compiling > the test in pr82617 gives an ICE: > > pr82617.f90:68:0: > > 68 | items(i_item) = str(i0:i1-1) >| > internal compiler error: tree check: expected tree that contains 'decl > minimal' structure, have 'indirect_ref' in get_array_span, at > fortran/trans.c:301 > > Cheers, > > Dominique > -- "If you can't explain it simply, you don't understand it well enough" - Albert Einstein
Re: [PATCH] x86: Add pmovzx/pmovsx patterns with SI/DI operands
On Sat, 29 Sep 2018, H.J. Lu wrote: Add pmovzx/pmovsx patterns with SI and DI operands for pmovzx/pmovsx instructions which only read the low 4 or 8 bytes from the source. Hello, I am wondering a few things (these are questions, I am not asking for changes): Should we change the builtin and make it take a shorter argument, so it is visible to gimple optimizers that the high part is unused? But then would that shorter type be v8qi (we don't really have that type) or di (risks trying to use general regs?)? +(define_insn "*sse4_1_v8qiv8hi2" + [(set (match_operand:V8HI 0 "register_operand" "=Yr,*x,v") + (any_extend:V8HI + (vec_select:V8QI + (subreg:V16QI + (vec_concat:V2DI + (match_operand:DI 1 "nonimmediate_operand" "Yrm,*xm,vm") + (const_int 0)) 0) + (parallel [(const_int 0) (const_int 1) + (const_int 2) (const_int 3) + (const_int 4) (const_int 5) + (const_int 6) (const_int 7)]] There is code in simplify-rtx.c that handles (vec_select (vec_concat x y) z) when vec_select only picks from x. We could extend it to handle an intermediate subreg/cast, which would yield something like: (any_extend:V8HI (subreg:V8QI (match_operand:DI))) or maybe even (any_extend:V8HI (match_operand:V8QI)) Would this be likely to work? Is it desirable? -- Marc Glisse
[libstdc++,doc] Update link to Microsoft Component Model Object Technologies
The original link was simply broken, no redirect or anything, but I'm relatively confident this is a good replacement. Committed. Gerald 2018-09-30 Gerald Pfeifer * doc/xml/manual/policy_data_structures_biblio.xml: Update link to Microsoft Component Model Object Technologies. Index: doc/xml/manual/policy_data_structures_biblio.xml === --- doc/xml/manual/policy_data_structures_biblio.xml(revision 264721) +++ doc/xml/manual/policy_data_structures_biblio.xml(working copy) @@ -1062,7 +1062,7 @@ http://www.w3.org/1999/xlink"; - xlink:href="https://www.microsoft.com/com/";> + xlink:href="https://docs.microsoft.com/en-us/windows/desktop/com/the-component-object-model";> COM: Component Model Object Technologies
Re: [PATCH] libgo: Don't assume sys.GoarchAmd64 == 64-bit pointer
On Sat, Sep 29, 2018 at 9:01 PM Ian Lance Taylor wrote: > > "H.J. Lu" writes: > > > On x86-64, sys.GoarchAmd64 == 1 for -mx32. But -mx32 has 32-bit > > pointer, not 64-bit. There is > > > > // _64bit = 1 on 64-bit systems, 0 on 32-bit systems > > _64bit = 1 << (^uintptr(0) >> 63) / 2 > > > > We should check both _64bit and sys.GoarchAmd64. > > Thanks, but I think the correct fix is to set GOARCH to amd64p32 when > using x32. I'm trying that to see if it will work out. > My understanding is amd64p32 == NaCl. But x32 != NaCl. -- H.J.
Re: [Patch, fortran] PRs 70752 and 72709 - more deferred character length bugs
Dear Dominique and Janne,
Putting the problem right turned out to be trivial. In the part of the
patch in gfc_conv_array_ref, what was being passed as 'decl' , in the
failing test from PR82617 was indeed an indirect reference. Applying
one dollop of indirection fixed it. The original testcase from PR82617
has been added to make sure that this does not break again. I also,
did the fold_convert, as recommended by Janne.
Committed as revision 264724 after regtesting.
Paul
2018-09-30 Paul Thomas
PR fortran/70752
PR fortran/72709
* trans-array.c (gfc_conv_scalarized_array_ref): If this is a
deferred type and the info->descriptor is present, use the
info->descriptor
(gfc_conv_array_ref): Is the se expr is a descriptor type, pass
it as 'decl' rather than the symbol backend_decl.
(gfc_array_allocate): If the se string_length is a component
reference, fix it and use it for the expression string length
if the latter is not a variable type. If it is a variable do
an assignment. Make use of component ref string lengths to set
the descriptor 'span'.
(gfc_conv_expr_descriptor): For pointer assignment, do not set
the span field if gfc_get_array_span returns zero.
* trans.c (get_array_span): If the upper bound a character type
is zero, use the descriptor span if available.
2018-09-30 Paul Thomas
PR fortran/70752
PR fortran/72709
* gfortran.dg/deferred_character_25.f90 : New test.
* gfortran.dg/deferred_character_26.f90 : New test.
* gfortran.dg/deferred_character_27.f90 : New test to verify
that PR82617 remains fixed.
On Sun, 30 Sep 2018 at 09:02, Paul Richard Thomas
wrote:
>
> Hi Dominique,
>
> It's the patch for pr70752 that causes the trouble, which I had
> guessed from the point in trans.c where the ICE occurs. I am onto it.
>
> Thanks again
>
> Paul
>
> On Wed, 26 Sep 2018 at 16:52, Dominique d'Humières wrote:
> >
> > > Is se->string_length guaranteed to be of type gfc_array_index_type_here?
> > > If so, why? And if not, maybe a fold_convert is in order?
> >
> > I don’t know if this related, but if I build gfortran with the patches for
> > PRs 70752 and 72709, 70149, and 65677 with --enable-checking=yes, compiling
> > the test in pr82617 gives an ICE:
> >
> > pr82617.f90:68:0:
> >
> > 68 | items(i_item) = str(i0:i1-1)
> >|
> > internal compiler error: tree check: expected tree that contains 'decl
> > minimal' structure, have 'indirect_ref' in get_array_span, at
> > fortran/trans.c:301
> >
> > Cheers,
> >
> > Dominique
> >
>
>
> --
> "If you can't explain it simply, you don't understand it well enough"
> - Albert Einstein
--
"If you can't explain it simply, you don't understand it well enough"
- Albert Einstein
Index: gcc/fortran/trans-array.c
===
*** gcc/fortran/trans-array.c (revision 264720)
--- gcc/fortran/trans-array.c (working copy)
*** gfc_conv_scalarized_array_ref (gfc_se *
*** 3423,3429
/* A pointer array component can be detected from its field decl. Fix
the descriptor, mark the resulting variable decl and pass it to
gfc_build_array_ref. */
! if (is_pointer_array (info->descriptor))
{
if (TREE_CODE (info->descriptor) == COMPONENT_REF)
decl = info->descriptor;
--- 3423,3431
/* A pointer array component can be detected from its field decl. Fix
the descriptor, mark the resulting variable decl and pass it to
gfc_build_array_ref. */
! if (is_pointer_array (info->descriptor)
! || (expr && expr->ts.deferred && info->descriptor
! && GFC_DESCRIPTOR_TYPE_P (TREE_TYPE (info->descriptor
{
if (TREE_CODE (info->descriptor) == COMPONENT_REF)
decl = info->descriptor;
*** gfc_conv_array_ref (gfc_se * se, gfc_arr
*** 3676,3682
else if (expr->ts.deferred
|| (sym->ts.type == BT_CHARACTER
&& sym->attr.select_type_temporary))
! decl = sym->backend_decl;
else if (sym->ts.type == BT_CLASS)
decl = NULL_TREE;
--- 3678,3693
else if (expr->ts.deferred
|| (sym->ts.type == BT_CHARACTER
&& sym->attr.select_type_temporary))
! {
! if (GFC_DESCRIPTOR_TYPE_P (TREE_TYPE (se->expr)))
! {
! decl = se->expr;
! if (TREE_CODE (decl) == INDIRECT_REF)
! decl = TREE_OPERAND (decl, 0);
! }
! else
! decl = sym->backend_decl;
! }
else if (sym->ts.type == BT_CLASS)
decl = NULL_TREE;
*** gfc_array_allocate (gfc_se * se, gfc_exp
*** 5761,5766
--- 5772,5790
overflow = integer_zero_node;
+ if (expr->ts.type == BT_CHARACTER
+ && TREE_CODE (se->string_length) == COMPONENT_REF
+ && expr->ts.u.cl->backend_decl != se->string_length)
+ {
+ if (VAR_P (expr->ts.u.cl->backend_decl))
+ gfc_add_modify (&se->pre, expr->ts.u.cl->backend_decl,
+ fold_convert (TREE_TYPE (expr->ts.u.cl->backend_d
[Patch, fortran] PR87359 [9 regression] pointer being freed was not allocated
After testing by Dominique and Juergen. Committed as revision 264725.
Thanks to Dominique and juergen for doing all the hard work!
Cheers
Paul
2018-09-30 Paul Thomas
PR fortran/87359
* trans-array.c (gfc_is_reallocatable_lhs): Correct the problem
introduced by r264358, which prevented components of associate
names from being reallocated on assignment.
2018-09-30 Paul Thomas
PR fortran/87359
* gfortran.dg/associate_40.f90 : New test.
Index: gcc/fortran/trans-array.c
===
*** gcc/fortran/trans-array.c (revision 264724)
--- gcc/fortran/trans-array.c (working copy)
*** gfc_is_reallocatable_lhs (gfc_expr *expr
*** 9574,9584
sym = expr->symtree->n.sym;
! if (sym->attr.associate_var)
return false;
/* An allocatable class variable with no reference. */
if (sym->ts.type == BT_CLASS
&& CLASS_DATA (sym)->attr.allocatable
&& expr->ref && expr->ref->type == REF_COMPONENT
&& strcmp (expr->ref->u.c.component->name, "_data") == 0
--- 9574,9585
sym = expr->symtree->n.sym;
! if (sym->attr.associate_var && !expr->ref)
return false;
/* An allocatable class variable with no reference. */
if (sym->ts.type == BT_CLASS
+ && !sym->attr.associate_var
&& CLASS_DATA (sym)->attr.allocatable
&& expr->ref && expr->ref->type == REF_COMPONENT
&& strcmp (expr->ref->u.c.component->name, "_data") == 0
*** gfc_is_reallocatable_lhs (gfc_expr *expr
*** 9587,9595
/* An allocatable variable. */
if (sym->attr.allocatable
! && expr->ref
! && expr->ref->type == REF_ARRAY
! && expr->ref->u.ar.type == AR_FULL)
return true;
/* All that can be left are allocatable components. */
--- 9588,9597
/* An allocatable variable. */
if (sym->attr.allocatable
! && !sym->attr.associate_var
! && expr->ref
! && expr->ref->type == REF_ARRAY
! && expr->ref->u.ar.type == AR_FULL)
return true;
/* All that can be left are allocatable components. */
Index: gcc/testsuite/gfortran.dg/associate_40.f90
===
*** gcc/testsuite/gfortran.dg/associate_40.f90 (nonexistent)
--- gcc/testsuite/gfortran.dg/associate_40.f90 (working copy)
***
*** 0
--- 1,96
+ ! { dg-do compile }
+ ! { dg-options "-fdump-tree-original" }
+ !
+ ! Test the fix for the second part of PR87359 in which the reallocation on
+ ! assignment for components of associate names was disallowed by r264358.
+ ! -fcheck-all exposed the mismatch in array shapes. The deallocations at
+ ! the end of the main program are there to make sure that valgrind does
+ ! not report an memory leaks.
+ !
+ ! Contributed by Juergen Reuter
+ !
+ module phs_fks
+ implicit none
+ private
+ public :: phs_identifier_t
+ public :: phs_fks_t
+ type :: phs_identifier_t
+ integer, dimension(:), allocatable :: contributors
+ contains
+ procedure :: init => phs_identifier_init
+ end type phs_identifier_t
+
+ type :: phs_fks_t
+ type(phs_identifier_t), dimension(:), allocatable :: phs_identifiers
+ end type phs_fks_t
+ contains
+
+ subroutine phs_identifier_init &
+ (phs_id, contributors)
+ class(phs_identifier_t), intent(out) :: phs_id
+ integer, intent(in), dimension(:) :: contributors
+ allocate (phs_id%contributors (size (contributors)))
+ phs_id%contributors = contributors
+end subroutine phs_identifier_init
+
+ end module phs_fks
+
+ !
+
+ module instances
+ use phs_fks
+ implicit none
+ private
+ public :: process_instance_t
+
+ type :: nlo_event_deps_t
+ type(phs_identifier_t), dimension(:), allocatable :: phs_identifiers
+ end type nlo_event_deps_t
+
+ type :: process_instance_t
+ type(phs_fks_t), pointer :: phs => null ()
+ type(nlo_event_deps_t) :: event_deps
+contains
+ procedure :: init => process_instance_init
+ procedure :: setup_real_event_kinematics => pi_setup_real_event_kinematics
+ end type process_instance_t
+
+ contains
+
+ subroutine process_instance_init (instance)
+ class(process_instance_t), intent(out), target :: instance
+ integer :: i
+ integer :: i_born, i_real
+ allocate (instance%phs)
+ end subroutine process_instance_init
+
+ subroutine pi_setup_real_event_kinematics (process_instance)
+ class(process_instance_t), intent(inout) :: process_instance
+ integer :: i_real, i
+ associate (event_deps => process_instance%event_deps)
+i_real = 2
+associate (phs => process_instance%phs)
+ allocate (phs%phs_identifiers (3))
+ call phs%phs_identifiers(1)%init ([1])
+ call phs%phs_identifiers(2)%init ([1,2])
+ call phs%phs_identifiers(3)%init ([1,2,3])
+ process_instance%event_deps%phs_identifie
[libstdc++,doc] adjust link to www.oracle.com
I applied the patch below. Given a number of fixes in libstdc++/doc I've applied recently, can one of you please regenerate the HTML pages in the next days? Thanks, Gerald 2018-09-30 Gerald Pfeifer * doc/xml/manual/messages.xml: Switch link to www.oracle.com to https. Index: doc/xml/manual/messages.xml === --- doc/xml/manual/messages.xml (revision 264721) +++ doc/xml/manual/messages.xml (working copy) @@ -541,7 +541,7 @@ void test01() http://www.w3.org/1999/xlink"; - xlink:href="http://www.oracle.com/technetwork/java/api/index.html";> + xlink:href="https://www.oracle.com/technetwork/java/api/index.html";> API Specifications, Java Platform
Re: [PATCH] x86: Add pmovzx/pmovsx patterns with SI/DI operands
On Sun, Sep 30, 2018 at 1:53 AM Marc Glisse wrote: > > On Sat, 29 Sep 2018, H.J. Lu wrote: > > > Add pmovzx/pmovsx patterns with SI and DI operands for pmovzx/pmovsx > > instructions which only read the low 4 or 8 bytes from the source. > > Hello, > > I am wondering a few things (these are questions, I am not asking for > changes): > > Should we change the builtin and make it take a shorter argument, so it is > visible to gimple optimizers that the high part is unused? But then would > that shorter type be v8qi (we don't really have that type) or di (risks > trying to use general regs?)? I think this may lead to other issues you pointed out. > > +(define_insn "*sse4_1_v8qiv8hi2" > > + [(set (match_operand:V8HI 0 "register_operand" "=Yr,*x,v") > > + (any_extend:V8HI > > + (vec_select:V8QI > > + (subreg:V16QI > > + (vec_concat:V2DI > > + (match_operand:DI 1 "nonimmediate_operand" "Yrm,*xm,vm") > > + (const_int 0)) 0) > > + (parallel [(const_int 0) (const_int 1) > > +(const_int 2) (const_int 3) > > +(const_int 4) (const_int 5) > > +(const_int 6) (const_int 7)]] > > There is code in simplify-rtx.c that handles (vec_select (vec_concat x > y) z) when vec_select only picks from x. We could extend it to handle an > intermediate subreg/cast, which would yield something like: > (any_extend:V8HI (subreg:V8QI (match_operand:DI))) > or maybe even > (any_extend:V8HI (match_operand:V8QI)) > Would this be likely to work? Is it desirable? > We need vector instructions with source memory or XMM operand in SI/DImode only for these patterns. Exposed it to simplify-rtx.c may lead to unexpected results. But we don't know for sure unless we try. -- H.J.
Re: Fold more boolean expressions
Now that it has got enough reviews and there's
been no comments for a week, I believe
now it's time for us to install it on trunk.
The patch is the same as previous, but rebased
on current trunk.
Could you please push it for me? If there's anything
I can do to help, just tell me.
2018-09-30 MCC CS
gcc/
PR tree-optimization/87261
* match.pd: Add boolean optimizations,
fix whitespace.
2018-09-30 MCC CS
gcc/testsuite/
PR tree-optimization/87261
* gcc.dg/pr87261.c: New test.
Index: gcc/match.pd
===
--- gcc/match.pd(revision 264725)
+++ gcc/match.pd(working copy)
@@ -92,7 +92,7 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
IFN_FMA IFN_FMS IFN_FNMA IFN_FNMS)
(define_operator_list COND_TERNARY
IFN_COND_FMA IFN_COND_FMS IFN_COND_FNMA IFN_COND_FNMS)
-
+
/* As opposed to convert?, this still creates a single pattern, so
it is not a suitable replacement for convert? in all cases. */
(match (nop_convert @0)
@@ -106,7 +106,7 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
&& tree_nop_conversion_p (TREE_TYPE (type), TREE_TYPE (TREE_TYPE
(@0))
/* This one has to be last, or it shadows the others. */
(match (nop_convert @0)
- @0)
+ @0)
/* Transform likes of (char) ABS_EXPR <(int) x> into (char) ABSU_EXPR
ABSU_EXPR returns unsigned absolute value of the operand and the operand
@@ -285,7 +285,7 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
And not for _Fract types where we can't build 1. */
(if (!integer_zerop (@0) && !ALL_FRACT_MODE_P (TYPE_MODE (type)))
{ build_one_cst (type); }))
- /* X / abs (X) is X < 0 ? -1 : 1. */
+ /* X / abs (X) is X < 0 ? -1 : 1. */
(simplify
(div:C @0 (abs @0))
(if (INTEGRAL_TYPE_P (type)
@@ -929,6 +929,31 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
(bitop:c @0 (bit_not (bitop:cs @0 @1)))
(bitop @0 (bit_not @1
+/* (~x & y) | ~(x | y) -> ~x */
+(simplify
+ (bit_ior:c (bit_and:c (bit_not@2 @0) @1) (bit_not (bit_ior:c @0 @1)))
+ @2)
+
+/* (x | y) ^ (x | ~y) -> ~x */
+(simplify
+ (bit_xor:c (bit_ior:c @0 @1) (bit_ior:c @0 (bit_not @1)))
+ (bit_not @0))
+
+/* (x & y) | ~(x | y) -> ~(x ^ y) */
+(simplify
+ (bit_ior:c (bit_and:cs @0 @1) (bit_not:s (bit_ior:s @0 @1)))
+ (bit_not (bit_xor @0 @1)))
+
+/* (~x | y) ^ (x ^ y) -> x | ~y */
+(simplify
+ (bit_xor:c (bit_ior:cs (bit_not @0) @1) (bit_xor:s @0 @1))
+ (bit_ior @0 (bit_not @1)))
+
+/* (x ^ y) | ~(x | y) -> ~(x & y) */
+(simplify
+ (bit_ior:c (bit_xor:cs @0 @1) (bit_not:s (bit_ior:s @0 @1)))
+ (bit_not (bit_and @0 @1)))
+
/* (x | y) & ~x -> y & ~x */
/* (x & y) | ~x -> y | ~x */
(for bitop (bit_and bit_ior)
@@ -1139,7 +1164,7 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
(if (tree_nop_conversion_p (type, TREE_TYPE (@0))
&& tree_nop_conversion_p (type, TREE_TYPE (@1)))
(mult (convert @0) (convert (negate @1)
-
+
/* -(A + B) -> (-B) - A. */
(simplify
(negate (plus:c @0 negate_expr_p@1))
@@ -3099,7 +3124,7 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
(if (tree_int_cst_sgn (@1) < 0)
(scmp @0 @2)
(cmp @0 @2))
-
+
/* Simplify comparison of something with itself. For IEEE
floating-point, we can only do some of these simplifications. */
(for cmp (eq ge le)
@@ -3170,11 +3195,11 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
}
tree newtype
= (TYPE_PRECISION (TREE_TYPE (@0)) > TYPE_PRECISION (type1)
- ? TREE_TYPE (@0) : type1);
+ ? TREE_TYPE (@0) : type1);
}
(if (TYPE_PRECISION (TREE_TYPE (@2)) > TYPE_PRECISION (newtype))
(cmp (convert:newtype @0) (convert:newtype @1))
-
+
(simplify
(cmp @0 REAL_CST@1)
/* IEEE doesn't distinguish +0 and -0 in comparisons. */
@@ -3422,7 +3447,7 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
(FTYPE) N == CST -> 0
(FTYPE) N != CST -> 1. */
(if (cmp == EQ_EXPR || cmp == NE_EXPR)
-{ constant_boolean_node (cmp == NE_EXPR, type); })
+{ constant_boolean_node (cmp == NE_EXPR, type); })
/* Otherwise replace with sensible integer constant. */
(with
{
@@ -3666,7 +3691,7 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
(simplify
(cmp (bit_and@2 @0 integer_pow2p@1) @1)
(icmp @2 { build_zero_cst (TREE_TYPE (@0)); })))
-
+
/* If we have (A & C) != 0 ? D : 0 where C and D are powers of 2,
convert this into a shift followed by ANDing with D. */
(simplify
@@ -3886,7 +3911,7 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
(if (cmp == LE_EXPR)
(ge (convert:st @0) { build_zero_cst (st); })
(lt (convert:st @0) { build_zero_cst (st); }))
-
+
(for cmp (unordered ordered unlt unle ungt unge uneq ltgt)
/* If the second operand is NaN, the result is constant. */
(simplify
@@ -4540,7 +4565,7 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
(if (wi::to_wide (@1) == -1)
(rdiv { build_real (type, dconst1); } @0
-/* Narrowing of arithmetic and logical operations.
+/* Narrowing of arithmetic a
Re: [Patch, fortran] PR65677 - Incomplete assignment on deferred-length character variable
Hi Paul, First your patch has been committed with wrong entry: 65667 instead of 65677. Second, I suspect it is responsible of the following ICE: % gfc pr72755.f90 -fno-range-check pr72755.f90:1485:0: 1485 | this%buffer = transfer( c(start:iend), this%buffer ) | internal compiler error: in gfc_dep_resolver, at fortran/dependency.c:2257 and % gfc pr64125_db.f90 pr64125_db.f90:20:0: 20 | left%chars = transfer( right, left%chars ) | internal compiler error: in gfc_dep_resolver, at fortran/dependency.c:2257 for module test type t_string private character(len=:), allocatable :: chars end type t_string contains pure subroutine string_assign_from_array( left, right ) ! The target string type(t_string), intent(out) :: left ! The source string character, dimension(:), intent(in) :: right ! Copy memory allocate( character(len=size(right)) :: left%chars ) left%chars = transfer( right, left%chars ) end subroutine string_assign_from_array end module test Cheers, Dominique
[wwwdocs] Push lang="en" into individual pages instead of redefining the tag (via MetaHTML)
This is a follow-up on the initial simplification I worked on this morning, cf. https://gcc.gnu.org/ml/gcc-patches/2018-09/msg01782.html . With this we no longer set the lang attribute to "en" via our global style/MetaHTML pre-processing, but push lang="en" down into the tags of all individual pages. This avoids redefining to begin with. Which in turn also means less to do for David's script (hopefully). Committed. Gerald Index: style.mhtml === RCS file: /cvs/gcc/wwwdocs/htdocs/style.mhtml,v retrieving revision 1.158 diff -u -r1.158 style.mhtml --- style.mhtml 30 Sep 2018 07:29:40 - 1.158 +++ style.mhtml 30 Sep 2018 14:35:52 - @@ -10,18 +10,6 @@ > -;;; Redefine the tag. - - - - - - %body - - - - - ;;; Redefine the tag so that we can add default headers. Index: about.html === RCS file: /cvs/gcc/wwwdocs/htdocs/about.html,v retrieving revision 1.32 diff -u -r1.32 about.html --- about.html 3 Sep 2018 10:08:07 - 1.32 +++ about.html 30 Sep 2018 14:20:38 - @@ -1,5 +1,5 @@ - + GCC: About Index: backends.html === RCS file: /cvs/gcc/wwwdocs/htdocs/backends.html,v retrieving revision 1.80 diff -u -r1.80 backends.html --- backends.html 1 Sep 2018 23:41:59 - 1.80 +++ backends.html 30 Sep 2018 14:20:38 - @@ -1,5 +1,5 @@ - + Status of Supported Architectures from Maintainers' Point of View Index: badspammer.html === RCS file: /cvs/gcc/wwwdocs/htdocs/badspammer.html,v retrieving revision 1.9 diff -u -r1.9 badspammer.html --- badspammer.html 1 Sep 2018 23:41:59 - 1.9 +++ badspammer.html 30 Sep 2018 14:20:39 - @@ -1,5 +1,5 @@ - + GCC Index: branch-closing.html === RCS file: /cvs/gcc/wwwdocs/htdocs/branch-closing.html,v retrieving revision 1.3 diff -u -r1.3 branch-closing.html --- branch-closing.html 1 Sep 2018 23:41:59 - 1.3 +++ branch-closing.html 30 Sep 2018 14:20:39 - @@ -1,5 +1,5 @@ - + Closing a GCC Release Branch Index: branching.html === RCS file: /cvs/gcc/wwwdocs/htdocs/branching.html,v retrieving revision 1.36 diff -u -r1.36 branching.html --- branching.html 1 Sep 2018 23:41:59 - 1.36 +++ branching.html 30 Sep 2018 14:20:39 - @@ -1,5 +1,5 @@ - + Branching for a GCC Release Index: buildstat.html === RCS file: /cvs/gcc/wwwdocs/htdocs/buildstat.html,v retrieving revision 1.29 diff -u -r1.29 buildstat.html --- buildstat.html 1 Sep 2018 23:41:59 - 1.29 +++ buildstat.html 30 Sep 2018 14:20:39 - @@ -1,5 +1,5 @@ - + Build status for GCC Index: c99status.html === RCS file: /cvs/gcc/wwwdocs/htdocs/c99status.html,v retrieving revision 1.67 diff -u -r1.67 c99status.html --- c99status.html 11 Sep 2018 19:32:09 - 1.67 +++ c99status.html 30 Sep 2018 14:20:39 - @@ -1,5 +1,5 @@ - + Status of C99 features in GCC Index: codingconventions.html === RCS file: /cvs/gcc/wwwdocs/htdocs/codingconventions.html,v retrieving revision 1.84 diff -u -r1.84 codingconventions.html --- codingconventions.html 2 Sep 2018 20:26:14 - 1.84 +++ codingconventions.html 30 Sep 2018 14:20:39 - @@ -1,5 +1,5 @@ - + GCC Coding Conventions Index: codingrationale.html === RCS file: /cvs/gcc/wwwdocs/htdocs/codingrationale.html,v retrieving revision 1.6 diff -u -r1.6 codingrationale.html --- codingrationale.html1 Sep 2018 23:42:00 - 1.6 +++ codingrationale.html30 Sep 2018 14:20:40 - @@ -1,5 +1,5 @@ - + GCC Coding Conventions Rationale and Discussion Index: contribute.html === RCS file: /cvs/gcc/wwwdocs/htdocs/contribute.html,v retrieving revision 1.91 diff -u -r1.91 contribute.html --- contribute.html 3 Sep 2018 10:08:08 - 1.91 +++ contribute.html 30 Sep 2018 14:20:40 - @@ -1,5 +1,5 @@ - + - + Extending and Contributing to GCC Index: develop.html === RCS file: /cvs/gcc/wwwdocs/htdocs/develop.html,v retrieving revision 1.186 diff -u -r1.186 develop.html --- develop.html1 Sep 2018 23:42:00 - 1.186 +++ develop.html30 Sep 2018 14:20:40 - @@ -1,5 +1,5 @@ - + GCC Development Plan https://gcc.gnu.org/gcc.css"; /> Index: extensions.ht
Re: [PATCH][AArch64] Support zero-extended move to FP register
On 9/28/18 12:56 PM, Wilco Dijkstra wrote: > We've seen too many instances where not keeping a well defined boundary > between int and fp/simd leads to bad code, so not defining all possible legal > combinations is intended. I'll check whether 32-bit w->r and w->w > zero-extension > could ever trigger. As a guess, I would expect them to happen after some sort of vector reduction operation. r~
[PATCH] Add option to control warnings added through attribure "warning"
Hello,
I prepared patch that give more precise control over __attribute__((warning)). Currently when you
use "warning" attribute with "-Werror" option warning become error and there is
no way to ignore this error.
With suggested changes it will be possible to use "-Werror
-Wno-error=warning-attribute" to compile code with warning attributes. This
particular case added as new testcase.
I tested suggested changes in two cases: with gcc-trunk compiled on GuixSD with
GCC 5.5 on amd64 machine and as patch to gcc 6.2.0 inside of Yocto 2.2
environment on Ubuntu 14.04 on amd64 machine.
Regards,
Nikolai
gcc/Changelog
2018-09-29 Nikolai Merinov
* gcc/common.opt: Add -Wwarning-attribute.
* gcc/doc/invoke.texi: Add documentation for -Wno-warning-attribute.
* gcc/testsuite/gcc.dg/Wno-warning-attribute.c: New test.
* gcc/expr.c (expand_expr_real_1): Add new attribute to warning_at
call to allow user configure behavior of "warning" attribute
Index: gcc/common.opt
===
--- gcc/common.opt (revision 264725)
+++ gcc/common.opt (working copy)
@@ -571,6 +571,10 @@ Wcpp
Common Var(warn_cpp) Init(1) Warning
Warn when a #warning directive is encountered.
+Wwarning-attribute
+Common Var(warn_warning_attribute) Init(1) Warning
+Warn about uses of __attribute__((warning)) declarations.
+
Wdeprecated-declarations
Common Var(warn_deprecated_decl) Init(1) Warning
Warn about uses of __attribute__((deprecated)) declarations.
Index: gcc/doc/invoke.texi
===
--- gcc/doc/invoke.texi (revision 264725)
+++ gcc/doc/invoke.texi (working copy)
@@ -291,6 +291,7 @@ Objective-C and Objective-C++ Dialects}.
-Wclobbered -Wcomment -Wconditionally-supported @gol
-Wconversion -Wcoverage-mismatch -Wno-cpp -Wdangling-else -Wdate-time @gol
-Wdelete-incomplete @gol
+-Wno-warning-attribute @gol
-Wno-deprecated -Wno-deprecated-declarations -Wno-designated-init @gol
-Wdisabled-optimization @gol
-Wno-discarded-qualifiers -Wno-discarded-array-qualifiers @gol
@@ -6940,6 +6941,15 @@ confused with the digit 0, and so is not the defau
useful as a local coding convention if the programming environment
cannot be fixed to display these characters distinctly.
+@item -Wno-warning-attribute
+@opindex Wno-warning-attribute
+@opindex Wwarning-attribute
+Do not warn about usage of functions (@pxref{Function Attributes})
+declared with @code{warning} attribute. By default, this warning is
+enabled. @option{-Wno-warning-attribute} can be used to disable the
+warning or @option{-Wno-error=warning-attribute} can be used to
+disable the error when compiled with @option{-Werror} flag.
+
@item -Wno-deprecated
@opindex Wno-deprecated
@opindex Wdeprecated
Index: gcc/expr.c
===
--- gcc/expr.c (revision 264725)
+++ gcc/expr.c (working copy)
@@ -10930,7 +10930,8 @@ expand_expr_real_1 (tree exp, rtx target, machine_
DECL_ATTRIBUTES (fndecl))) != NULL)
{
const char *ident = lang_hooks.decl_printable_name (fndecl, 1);
- warning_at (tree_nonartificial_location (exp), 0,
+ warning_at (tree_nonartificial_location (exp),
+ OPT_Wwarning_attribute,
"%Kcall to %qs declared with attribute warning: %s",
exp, identifier_to_locale (ident),
TREE_STRING_POINTER (TREE_VALUE (TREE_VALUE (attr;
Index: gcc/testsuite/gcc.dg/Wno-warning-attribute.c
===
--- gcc/testsuite/gcc.dg/Wno-warning-attribute.c (revision 0)
+++ gcc/testsuite/gcc.dg/Wno-warning-attribute.c (working copy)
@@ -0,0 +1,8 @@
+/* { dg-do compile } */
+/* { dg-options "-Werror -Wno-error=warning-attribute" } */
+
+int f1(void) __attribute__ ((warning("Please avoid f1")));
+int func1(void)
+{
+ return f1(); /* { dg-warning "'f1' declared with attribute warning: Please avoid f1" } */
+}
Re: [PATCH 0/2][IRA,LRA] Fix PR86939, IRA incorrectly creates an interference between a pseudo register and a hard register
On 9/28/18 4:34 PM, Vladimir Makarov wrote: > I remember I experimented with value numbering and using it in building > conflicts (that time it was global.c) but it did not improve the code as > I expected and made RA much slower. Yes, value numbering is not cheap to compute for catching special cases like this that probably don't happen too often. Handling copies is fairly cheap and easy though. > We had some PRs with old RA code generation in case of using undefined values. > I don't remember what problems were exactly but I remember Ken Zadeck worked > on this too. That is why I probably chose the current scheme of conflict > building. > > May be I was wrong because you testing shows that it is not a problem anymore. Maybe it was due to code relying on undefined behavior? Anyway, it'll be good to let PATCH 1 bake on trunk for a little while before we commit PATCH 2 to catch any (if they exist) problems related to that change. > The 1st patch is ok for me. You can commit it to the trunk. Ok, PATCH 1 is now committed, thanks! > I'll review the second patch on the next week. Sounds great as it gives any problems caused or exposed by PATCH 1 time to be reported. Thanks again! Peter
[PATCH, i386]: Optimize detection of a couple of patterns
There is no need to dynamically construct clobbers of (f)emms insn.
Also, use faster detection of vzeroall pattern.
2018-09-30 Uros Bizjak
* config/i386/mmx.md (EMMS): New int iterator.
(emms): New int attribute.
(mmx_): Macroize insn from *mmx_emms and *mmx_femms using
EMMS int iterator. Explicitly declare clobbers.
(mmx_emms): Remove expander.
(mmx_femms): Ditto.
* config/i386/predicates.md (emms_operation): Remove predicate.
(vzeroall_pattern): New predicate.
(vzeroupper_pattern): Rename from vzeroupper_operation.
* config/i386/i386.c (ix86_avx_u128_mode_after): Use
vzeroupper_pattern and vzeroall_pattern predicates.
Bootstrapped and regression tested on x86_64-linux-gnu {,-m32}.
Committed to mainline SVN.
Uros.
Index: config/i386/i386.c
===
--- config/i386/i386.c (revision 264695)
+++ config/i386/i386.c (working copy)
@@ -18944,8 +18944,8 @@ ix86_avx_u128_mode_after (int mode, rtx_insn *insn
{
rtx pat = PATTERN (insn);
- if (vzeroupper_operation (pat, VOIDmode)
- || vzeroall_operation (pat, VOIDmode))
+ if (vzeroupper_pattern (pat, VOIDmode)
+ || vzeroall_pattern (pat, VOIDmode))
return AVX_U128_CLEAN;
/* We know that state is clean after CALL insn if there are no
Index: config/i386/mmx.md
===
--- config/i386/mmx.md (revision 264693)
+++ config/i386/mmx.md (working copy)
@@ -1570,68 +1570,34 @@
(set_attr "znver1_decode" "vector")
(set_attr "mode" "DI")])
-(define_expand "mmx_emms"
- [(match_par_dup 0 [(const_int 0)])]
- "TARGET_MMX"
-{
- int regno;
+(define_int_iterator EMMS
+ [(UNSPECV_EMMS "TARGET_MMX")
+ (UNSPECV_FEMMS "TARGET_3DNOW")])
- operands[0] = gen_rtx_PARALLEL (VOIDmode, rtvec_alloc (17));
+(define_int_attr emms
+ [(UNSPECV_EMMS "emms")
+ (UNSPECV_FEMMS "femms")])
- XVECEXP (operands[0], 0, 0)
-= gen_rtx_UNSPEC_VOLATILE (VOIDmode, gen_rtvec (1, const0_rtx),
- UNSPECV_EMMS);
-
- for (regno = 0; regno < 8; regno++)
-{
- XVECEXP (operands[0], 0, regno + 1)
- = gen_rtx_CLOBBER (VOIDmode,
- gen_rtx_REG (XFmode, FIRST_STACK_REG + regno));
-
- XVECEXP (operands[0], 0, regno + 9)
- = gen_rtx_CLOBBER (VOIDmode,
- gen_rtx_REG (DImode, FIRST_MMX_REG + regno));
-}
-})
-
-(define_insn "*mmx_emms"
- [(match_parallel 0 "emms_operation"
-[(unspec_volatile [(const_int 0)] UNSPECV_EMMS)])]
- "TARGET_MMX"
- "emms"
+(define_insn "mmx_"
+ [(unspec_volatile [(const_int 0)] EMMS)
+ (clobber (reg:XF ST0_REG))
+ (clobber (reg:XF ST1_REG))
+ (clobber (reg:XF ST2_REG))
+ (clobber (reg:XF ST3_REG))
+ (clobber (reg:XF ST4_REG))
+ (clobber (reg:XF ST5_REG))
+ (clobber (reg:XF ST6_REG))
+ (clobber (reg:XF ST7_REG))
+ (clobber (reg:DI MM0_REG))
+ (clobber (reg:DI MM1_REG))
+ (clobber (reg:DI MM2_REG))
+ (clobber (reg:DI MM3_REG))
+ (clobber (reg:DI MM4_REG))
+ (clobber (reg:DI MM5_REG))
+ (clobber (reg:DI MM6_REG))
+ (clobber (reg:DI MM7_REG))]
+ ""
+ ""
[(set_attr "type" "mmx")
(set_attr "modrm" "0")
(set_attr "memory" "none")])
-
-(define_expand "mmx_femms"
- [(match_par_dup 0 [(const_int 0)])]
- "TARGET_3DNOW"
-{
- int regno;
-
- operands[0] = gen_rtx_PARALLEL (VOIDmode, rtvec_alloc (17));
-
- XVECEXP (operands[0], 0, 0)
-= gen_rtx_UNSPEC_VOLATILE (VOIDmode, gen_rtvec (1, const0_rtx),
- UNSPECV_FEMMS);
-
- for (regno = 0; regno < 8; regno++)
-{
- XVECEXP (operands[0], 0, regno + 1)
- = gen_rtx_CLOBBER (VOIDmode,
- gen_rtx_REG (XFmode, FIRST_STACK_REG + regno));
-
- XVECEXP (operands[0], 0, regno + 9)
- = gen_rtx_CLOBBER (VOIDmode,
- gen_rtx_REG (DImode, FIRST_MMX_REG + regno));
-}
-})
-
-(define_insn "*mmx_femms"
- [(match_parallel 0 "emms_operation"
-[(unspec_volatile [(const_int 0)] UNSPECV_FEMMS)])]
- "TARGET_3DNOW"
- "femms"
- [(set_attr "type" "mmx")
- (set_attr "modrm" "0")
- (set_attr "memory" "none")])
Index: config/i386/predicates.md
===
--- config/i386/predicates.md (revision 264695)
+++ config/i386/predicates.md (working copy)
@@ -1406,36 +1406,6 @@
(and (match_code "mem")
(match_test "MEM_ALIGN (op) < GET_MODE_BITSIZE (mode)")))
-;; Return true if OP is a emms operation, known to be a PARALLEL.
-(define_predicate "emms_operation"
- (match_code "parallel")
-{
- unsigned i;
-
- if (XVECLEN (op, 0) != 17)
-return false;
-
- for (i = 0; i < 8; i++)
-{
- rtx elt = XVECEXP (op, 0, i+1);
-
- if (GET_CODE (elt) != CLOBBER
- || GET_CODE (SET_DEST (elt)) != REG
- || GET_MODE (SET_DEST (elt)) != XFmode
- || REGNO (SET_DEST (elt)) != FIRST_STACK_REG + i)
-retur
Re: [PATCH 0/2][IRA,LRA] Fix PR86939, IRA incorrectly creates an interference between a pseudo register and a hard register
On Sun, Sep 30, 2018 at 1:21 PM Peter Bergner wrote: > > On 9/28/18 4:34 PM, Vladimir Makarov wrote: > > I remember I experimented with value numbering and using it in building > > conflicts (that time it was global.c) but it did not improve the code as > > I expected and made RA much slower. > > Yes, value numbering is not cheap to compute for catching special cases > like this that probably don't happen too often. Handling copies is fairly > cheap and easy though. > > > > We had some PRs with old RA code generation in case of using undefined > > values. > > I don't remember what problems were exactly but I remember Ken Zadeck worked > > on this too. That is why I probably chose the current scheme of conflict > > building. > > > > May be I was wrong because you testing shows that it is not a problem > > anymore. > > Maybe it was due to code relying on undefined behavior? Anyway, it'll be good > to let PATCH 1 bake on trunk for a little while before we commit PATCH 2 to > catch any (if they exist) problems related to that change. > > > > The 1st patch is ok for me. You can commit it to the trunk. > > Ok, PATCH 1 is now committed, thanks! > > > > I'll review the second patch on the next week. > > Sounds great as it gives any problems caused or exposed by PATCH 1 time to > be reported. Thanks again! This caused: FAIL: gcc.target/i386/pr63527.c scan-assembler-not movl[ \t]%[^,]+, %ebx FAIL: gcc.target/i386/pr63534.c scan-assembler-not movl[ \t]%[^,]+, %ebx FAIL: gcc.target/i386/pr64317.c scan-assembler addl[ \\t]+[$]_GLOBAL_OFFSET_TABLE_, %ebx FAIL: gcc.target/i386/pr64317.c scan-assembler movl[ \\t]+c@GOTOFF[(]%ebx[)] for Linux/i686. -- H.J.
Re: [PATCH 0/2][IRA,LRA] Fix PR86939, IRA incorrectly creates an interference between a pseudo register and a hard register
On 9/30/18 7:57 PM, H.J. Lu wrote: > This caused: > > FAIL: gcc.target/i386/pr63527.c scan-assembler-not movl[ \t]%[^,]+, %ebx > FAIL: gcc.target/i386/pr63534.c scan-assembler-not movl[ \t]%[^,]+, %ebx > FAIL: gcc.target/i386/pr64317.c scan-assembler addl[ > \\t]+[$]_GLOBAL_OFFSET_TABLE_, %ebx > FAIL: gcc.target/i386/pr64317.c scan-assembler movl[ \\t]+c@GOTOFF[(]%ebx[)] Can you check whether the new generated code is at least as good as the old generated code? I'm assuming the code we generate now isn't wrong, just different and maybe we just need to change what we expect to see. Peter
