[Patch, fortran] PR82275 - gfortran rejects valid & accepts invalid reference to dimension-remapped type SELECT TYPE selector
This patch is verging on 'obvious' since there was no attempt being
made to detect dimensions where the array reference of the selector is
an element. In fact, I made an attempt when the bug was first reported
to do this, Not realizing that the elements were coming through as
DIMEN_UNKNOWN, the attempt failed. This is now catered for.
Bootstrapped and regtested on FC27/x86_64. OK for all active branches?
Paul
2018-05-19 Paul Thomas
PR fortran/82275
* match.c (gfc_match_type_spec): Go through the array ref and
decrement 'rank' for every dimension that is an element.
2018-05-19 Paul Thomas
PR fortran/82923
* gfortran.dg/select_type_42.f90: New test.
Index: gcc/fortran/match.c
===
*** gcc/fortran/match.c (revision 260317)
--- gcc/fortran/match.c (working copy)
*** gfc_match_type_spec (gfc_typespec *ts)
*** 2118,2124
or list item in a type-list of an OpenMP reduction clause. Need to
differentiate REAL([KIND]=scalar-int-initialization-expr) from
REAL(A,[KIND]) and REAL(KIND,A). Logically, when this code was
! written the use of LOGICAL as a type-spec or intrinsic subprogram
was overlooked. */
m = gfc_match (" %n", name);
--- 2118,2124
or list item in a type-list of an OpenMP reduction clause. Need to
differentiate REAL([KIND]=scalar-int-initialization-expr) from
REAL(A,[KIND]) and REAL(KIND,A). Logically, when this code was
! written the use of LOGICAL as a type-spec or intrinsic subprogram
was overlooked. */
m = gfc_match (" %n", name);
*** copy_ts_from_selector_to_associate (gfc_
*** 5935,5940
--- 5935,5941
{
gfc_ref *ref;
gfc_symbol *assoc_sym;
+ int rank = 0;
assoc_sym = associate->symtree->n.sym;
*** copy_ts_from_selector_to_associate (gfc_
*** 5971,5984
selector->rank = ref->u.ar.dimen;
else
selector->rank = 0;
}
! if (selector->rank)
{
! assoc_sym->attr.dimension = 1;
! assoc_sym->as = gfc_get_array_spec ();
! assoc_sym->as->rank = selector->rank;
! assoc_sym->as->type = AS_DEFERRED;
}
else
assoc_sym->as = NULL;
--- 5972,5999
selector->rank = ref->u.ar.dimen;
else
selector->rank = 0;
+
+ rank = selector->rank;
}
! if (rank)
{
! for (int i = 0; i < ref->u.ar.dimen + ref->u.ar.codimen; i++)
! if (ref->u.ar.dimen_type[i] == DIMEN_ELEMENT
! || (ref->u.ar.dimen_type[i] == DIMEN_UNKNOWN
! && ref->u.ar.end[i] == NULL
! && ref->u.ar.stride[i] == NULL))
! rank--;
!
! if (rank)
! {
! assoc_sym->attr.dimension = 1;
! assoc_sym->as = gfc_get_array_spec ();
! assoc_sym->as->rank = rank;
! assoc_sym->as->type = AS_DEFERRED;
! }
! else
! assoc_sym->as = NULL;
}
else
assoc_sym->as = NULL;
Index: gcc/testsuite/gfortran.dg/select_type_42.f90
===
*** gcc/testsuite/gfortran.dg/select_type_42.f90 (nonexistent)
--- gcc/testsuite/gfortran.dg/select_type_42.f90 (working copy)
***
*** 0
--- 1,26
+ ! { dg-do run }
+ !
+ ! Tests the fix for PR82275.
+ ! Associating a name with a reduced-dimension section of a
+ ! multidimensional array precluded subsequent use of the name
+ ! with the appropriately reduced dimensionality and instead
+ ! required use of the (invalid) full set of original dimensions.
+ !
+ ! Contributed by Damian Rouson
+ !
+ type component
+integer :: i
+ end type
+ type container
+ class(component), allocatable :: component_array(:,:)
+ end type
+ type(container) bag
+ type(component) section_copy
+ allocate(bag%component_array, source = reshape ([component(10), component (100)], [1,2]))
+ select type(associate_name=>bag%component_array(1,:))
+ type is (component)
+ section_copy = associate_name(2) ! gfortran rejected valid
+ ! section_copy = associate_name(1,1)! gfortran accepted invalid
+ end select
+ if (section_copy%i .ne. 100) stop 1
+ end
Re: [Patch, fortran] PR82923 - Automatic allocation of deferred length character using function result
The patch works as expected and fixes also PRs 66694 and 82617. Thanks, Dominique
Re: [PATCH 1/2][Aarch64] Improve FP to int conversions
Michael Collison writes:
> This patch improves additional cases of FP to integer conversions.
>
> Example 1:
>
> unsigned long
> f7 (double x)
> {
> return (unsigned) y;
> }
>
>
> At -O2
>
> Trunk generates:
>
> f7:
> fcvtzu w0, d0
> uxtwx0, w0
> ret
>
> With the patch we can merge the zero-extend and reduce the sequence to one
> instruction at -O2
>
> f7:
> fcvtzu x0, d0
> ret
Thanks for doing this, patch looks good to me FWIW. I think the
patch actually uses "fcvtzu w0, d0", which unlike "fcvtzu x0, d0"
preserves the rtl semantics exactly.
> +/* { dg-final { scan-assembler "fcvtzu\\tw\[0-9\]+, d\[0-9\]+" } } */
> +/* { dg-final { scan-assembler "fcvtzu\\tw\[0-9\]+, s\[0-9\]+" } } */
Just wanted to plug curly-brace quoting, which avoids the extra backslashes:
/* { dg-final { scan-assembler {fcvtzu\tw[0-9]+, d[0-9]+} } } */
/* { dg-final { scan-assembler {fcvtzu\tw[0-9]+, s[0-9]+} } } */
Either's fine though -- don't respin for that. :-)
Richard
Re: [Patch, fortran] PR82923 - Automatic allocation of deferred length character using function result
Thanks! I will take this as an OK to commit. Regards Paul On 19 May 2018 at 10:18, Dominique d'Humières wrote: > The patch works as expected and fixes also PRs 66694 and 82617. > > Thanks, > > Dominique > -- "If you can't explain it simply, you don't understand it well enough" - Albert Einstein
O3 bootstraps fail on x86-64
O3 bootstraps have started to fail to build since about Thursday. Due to an internal compiler error when building asan.c in function asan_emit_stack_protectìon tree-ssa--sccan.c:3396 Graham
[wwwdocs] Buildstat update for 5.x
Going through the archives I found two results missing from the buildstat page. -tgc Testresults for 5.3.0: arm-unknown-linux-gnueabihf Testresults for 5.4.0: powerpc-apple-darwin9 Index: buildstat.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-5/buildstat.html,v retrieving revision 1.10 diff -u -r1.10 buildstat.html --- buildstat.html 5 Feb 2017 11:12:46 - 1.10 +++ buildstat.html 18 May 2018 20:01:32 - @@ -49,6 +49,14 @@ +arm-unknown-linux-gnueabihf + +Test results: +https://gcc.gnu.org/ml/gcc-testresults/2017-01/msg02598.html";>5.3.0 + + + + hppa-unknown-linux-gnu Test results: @@ -166,6 +174,14 @@ +powerpc-apple-darwin9 + +Test results: +https://gcc.gnu.org/ml/gcc-testresults/2017-01/msg02969.html";>5.4.0 + + + + powerpc-unknown-linux-gnu Test results:
[wwwdocs] Buildstat update for 6.x
Latest results for 6.x Note I reformatted two of the existing entries to match the rest of the file. -tgc Testresults for 6.2.0: i686-pc-linux-gnu x86_64-pc-linux-gnu (3) x86_64-w64-mingw32 Testresults for 6.3.0: powerpc-apple-darwin9 x86_64-pc-linux-gnu (3) x86_64-w64-mingw32 Testresults for 6.4.0: x86_64-w64-mingw32 Index: buildstat.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-6/buildstat.html,v retrieving revision 1.6 diff -u -r1.6 buildstat.html --- buildstat.html 5 Feb 2017 11:12:47 - 1.6 +++ buildstat.html 18 May 2018 17:01:04 - @@ -50,6 +50,7 @@ i686-pc-linux-gnu Test results: +https://gcc.gnu.org/ml/gcc-testresults/2016-08/msg02576.html";>6.2.0, https://gcc.gnu.org/ml/gcc-testresults/2016-05/msg01943.html";>6.1.0 @@ -58,7 +59,9 @@ powerpc64le-unknown-linux-gnu Test results: -https://gcc.gnu.org/ml/gcc-testresults/2016-04/msg02903.html";>6.1.0, https://gcc.gnu.org/ml/gcc-testresults/2016-08/msg02608.html";>6.2.0, https://gcc.gnu.org/ml/gcc-testresults/2017-01/msg00368.html";>6.3.0 +https://gcc.gnu.org/ml/gcc-testresults/2017-01/msg00368.html";>6.3.0, +https://gcc.gnu.org/ml/gcc-testresults/2016-08/msg02608.html";>6.2.0, +https://gcc.gnu.org/ml/gcc-testresults/2016-04/msg02903.html";>6.1.0 @@ -66,7 +69,17 @@ powerpc64-unknown-linux-gnu Test results: -https://gcc.gnu.org/ml/gcc-testresults/2016-04/msg02913.html";>6.1.0, https://gcc.gnu.org/ml/gcc-testresults/2016-08/msg02609.html";>6.2.0, https://gcc.gnu.org/ml/gcc-testresults/2017-01/msg00369.html";>6.3.0 +https://gcc.gnu.org/ml/gcc-testresults/2017-01/msg00369.html";>6.3.0, +https://gcc.gnu.org/ml/gcc-testresults/2016-08/msg02609.html";>6.2.0, +https://gcc.gnu.org/ml/gcc-testresults/2016-04/msg02913.html";>6.1.0 + + + + +powerpc-apple-darwin9 + +Test results: +https://gcc.gnu.org/ml/gcc-testresults/2017-01/msg02970.html";>6.3.0 @@ -122,6 +135,12 @@ x86_64-pc-linux-gnu Test results: +https://gcc.gnu.org/ml/gcc-testresults/2017-02/msg00319.html";>6.3.0, +https://gcc.gnu.org/ml/gcc-testresults/2017-01/msg00618.html";>6.3.0, +https://gcc.gnu.org/ml/gcc-testresults/2016-12/msg02604.html";>6.3.0, +https://gcc.gnu.org/ml/gcc-testresults/2016-08/msg03292.html";>6.2.0, +https://gcc.gnu.org/ml/gcc-testresults/2016-08/msg02892.html";>6.2.0, +https://gcc.gnu.org/ml/gcc-testresults/2016-08/msg02446.html";>6.2.0, https://gcc.gnu.org/ml/gcc-testresults/2016-04/msg02751.html";>6.1.0 @@ -130,6 +149,9 @@ x86_64-w64-mingw32 Test results: +https://gcc.gnu.org/ml/gcc-testresults/2017-07/msg01182.html";>6.4.0, +https://gcc.gnu.org/ml/gcc-testresults/2016-12/msg02327.html";>6.3.0, +https://gcc.gnu.org/ml/gcc-testresults/2016-08/msg02545.html";>6.2.0, https://gcc.gnu.org/ml/gcc-testresults/2016-05/msg00106.html";>6.1.0
Re: [PATCH 2/2][Aarch64] Improve FP to int conversions
Michael Collison writes:
> This patch improves additional cases of FP to integer conversions with
> -ffast-math enabled.
>
> Example 1:
>
> double
> f5 (int x)
> {
> return (double)(float) x;
> }
>
>
> At -O2 with -ffast-math
>
> Trunk generates:
>
> f5:
> scvtf s0, w0
> fcvtd0, s0
> ret
>
>
> With the patch we can merge the conversion to float and float-extend and
> reduce the sequence to one instruction at -O2 and -ffast-math
>
> f5:
> scvtf d0, w0
> ret
>
> Example 2
>
> int
> f6 (double x)
> {
> return (int)(float) x;
> }
>
>
> At -O2 (even with -ffast-math) trunk generates
>
> f6:
> fcvts0, d0
> fcvtzs w0, s0
> ret
>
> We can merge the float_truncate into the fix at the rtl level
>
> With -ffast-math enabled and -O2 we can now generate:
>
> f6:
> fcvtzs w0, d0
> ret
>
> Bootstrapped and regression tested on aarch64-linux-gnu. Okay for trunk?
I don't think these folds belong in target-specific code, since if they're
valid, they're valid for all targets. The code that handles sequences
of two conversions in gimple is the match.pd rule starting:
/* Handle cases of two conversions in a row. */
(for ocvt (convert float fix_trunc)
(for icvt (convert float)
(simplify
(ocvt (icvt@1 @0))
In particular, one of the conditions has:
/* Two conversions in a row are not needed unless:
- some conversion is floating-point (overstrict for now), or
... */
which seems to leave things open for more floating-point folds to be added.
Are there any targets for which converting to float then double is
cheaper then converting directly to double? If so, then those
targets might need a hook to turn the fold off. But if no modern
targets are known to be like that then it seems better to do the
fold whenever the FP settings make it valid.
Thanks,
Richard
[wwwdocs] Buildstat update for 7.x
Latest results for 7.x -tgc Testresults for 7.1.0: hppa2.0w-hp-hpux11.00 hppa64-hp-hpux11.00 i386-pc-solaris2.12 i686-pc-linux-gnu sparc-sun-solaris2.11 sparc-sun-solaris2.12 x86_64-apple-darwin11.4.2 x86_64-apple-darwin16.6.0 x86_64-pc-linux-gnu x86_64-w64-mingw32 Testresults for 7.2.0: i686-pc-linux-gnu sparc64-unknown-linux-gnu x86_64-pc-linux-gnu x86_64-w64-mingw32 Testresults for 7.3.0: x86_64-w64-mingw32 Index: buildstat.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-7/buildstat.html,v retrieving revision 1.2 diff -u -r1.2 buildstat.html --- buildstat.html 19 May 2017 22:00:28 - 1.2 +++ buildstat.html 18 May 2018 16:27:18 - @@ -23,6 +23,39 @@ +hppa2.0w-hp-hpux11.00 + +Test results: +https://gcc.gnu.org/ml/gcc-testresults/2017-05/msg01313.html";>7.1.0 + + + + +hppa64-hp-hpux11.00 + +Test results: +https://gcc.gnu.org/ml/gcc-testresults/2017-05/msg02656.html";>7.1.0 + + + + +i386-pc-solaris2.12 + +Test results: +https://gcc.gnu.org/ml/gcc-testresults/2017-05/msg00251.html";>7.1.0 + + + + +i686-pc-linux-gnu + +Test results: +https://gcc.gnu.org/ml/gcc-testresults/2017-08/msg01339.html";>7.2.0, +https://gcc.gnu.org/ml/gcc-testresults/2017-05/msg00434.html";>7.1.0 + + + + powerpc64le-unknown-linux-gnu Test results: @@ -38,6 +71,65 @@ + +sparc64-unknown-linux-gnu + +Test results: +https://gcc.gnu.org/ml/gcc-testresults/2017-08/msg01372.html";>7.2.0 + + + + +sparc-sun-solaris2.11 + +Test results: +https://gcc.gnu.org/ml/gcc-testresults/2017-05/msg00252.html";>7.1.0 + + + + +sparc-sun-solaris2.12 + +Test results: +https://gcc.gnu.org/ml/gcc-testresults/2017-05/msg00250.html";>7.1.0 + + + + +x86_64-apple-darwin11.4.2 + +Test results: +https://gcc.gnu.org/ml/gcc-testresults/2017-05/msg00413.html";>7.1.0 + + + + +x86_64-apple-darwin16.6.0 + +Test results: +https://gcc.gnu.org/ml/gcc-testresults/2017-05/msg00334.html";>7.1.0 + + + + +x86_64-pc-linux-gnu + +Test results: +https://gcc.gnu.org/ml/gcc-testresults/2017-08/msg01337.html";>7.2.0, +https://gcc.gnu.org/ml/gcc-testresults/2017-05/msg00253.html";>7.1.0 + + + + +x86_64-w64-mingw32 + +Test results: +https://gcc.gnu.org/ml/gcc-testresults/2018-02/msg00308.html";>7.3.0, +https://gcc.gnu.org/ml/gcc-testresults/2017-08/msg01364.html";>7.2.0, +https://gcc.gnu.org/ml/gcc-testresults/2017-05/msg00410.html";>7.1.0 + + +
Re: [patch AArch64] Do not perform a vector splat for vector initialisation if it is not useful
"Richard Earnshaw (lists)" writes: > On 16/05/18 09:37, Kyrill Tkachov wrote: >> >> On 15/05/18 10:58, Richard Biener wrote: >>> On Tue, May 15, 2018 at 10:20 AM Kyrill Tkachov >>> >>> wrote: >>> Hi all, This is a respin of James's patch from: >>> https://gcc.gnu.org/ml/gcc-patches/2017-12/msg00614.html The original patch was approved and committed but was later reverted >>> because of failures on big-endian. This tweaked version fixes the big-endian failures in >>> aarch64_expand_vector_init by picking the right element of VALS to move into the low part of the vector register >>> depending on endianness. The rest of the patch stays the same. I'm looking for approval on the aarch64 parts, as they >>> are the ones that have changed since the last approved version of the patch. --- In the testcase in this patch we create an SLP vector with only two elements. Our current vector initialisation code will first duplicate the first element to both lanes, then overwrite the top lane with a new value. This duplication can be clunky and wasteful. Better would be to simply use the fact that we will always be overwriting the remaining bits, and simply move the first element to the corrcet place (implicitly zeroing all other bits). This reduces the code generation for this case, and can allow more efficient addressing modes, and other second order benefits for AArch64 code which has been vectorized to V2DI mode. Note that the change is generic enough to catch the case for any vector mode, but is expected to be most useful for 2x64-bit vectorization. Unfortunately, on its own, this would cause failures in gcc.target/aarch64/load_v2vec_lanes_1.c and gcc.target/aarch64/store_v2vec_lanes.c , which expect to see many more vec_merge and vec_duplicate for their simplifications to apply. To fix this, add a special case to the AArch64 code if we are loading from two memory addresses, and use the load_pair_lanes patterns directly. We also need a new pattern in simplify-rtx.c:simplify_ternary_operation , to catch: (vec_merge:OUTER (vec_duplicate:OUTER x:INNER) (subreg:OUTER y:INNER 0) (const_int N)) And simplify it to: (vec_concat:OUTER x:INNER y:INNER) or (vec_concat y x) This is similar to the existing patterns which are tested in this function, without requiring the second operand to also be a vec_duplicate. Bootstrapped and tested on aarch64-none-linux-gnu and tested on aarch64-none-elf. Note that this requires https://gcc.gnu.org/ml/gcc-patches/2017-12/msg00614.html if we don't want to ICE creating broken vector zero extends. Are the non-AArch64 parts OK? >>> Is (vec_merge (subreg ..) (vec_duplicate)) canonicalized to the form >>> you handle? I see the (vec_merge (vec_duplicate...) (vec_concat)) case >>> also doesn't handle the swapped operand case. >>> >>> Otherwise the middle-end parts looks ok. >> >> I don't see any explicit canonicalisation code for it. >> I've updated the simplify-rtx part to handle the swapped operand case. >> Is the attached patch better in this regard? I couldn't think of a clean >> way to avoid >> duplicating some logic (beyond creating a new function away from the >> callsite). >> >> Thanks, >> Kyrill >> >>> Thanks, >>> Richard. >>> Thanks, James --- 2018-05-15 James Greenhalgh Kyrylo Tkachov * config/aarch64/aarch64.c (aarch64_expand_vector_init): Modify code generation for cases where splatting a value is not useful. * simplify-rtx.c (simplify_ternary_operation): Simplify vec_merge across a vec_duplicate and a paradoxical subreg >>> forming a vector mode to a vec_concat. 2018-05-15 James Greenhalgh * gcc.target/aarch64/vect-slp-dup.c: New. >> > > I'm surprised we don't seem to have a function in the compiler that > performs this check: > > + && rtx_equal_p (XEXP (x1, 0), > + plus_constant (Pmode, > + XEXP (x0, 0), > + GET_MODE_SIZE (inner_mode > > Without generating dead RTL (plus_constant will rarely be able to return > a subexpression of the original pattern). I would have thought this > sort of test was not that uncommon. FWIW, I think the way to write it without generating dead RTL is: rtx_equal_p (strip_offset (XEXP (x0, 0), &x0_offset), strip_offset (XEXP (x1, 0), &x1_offset)) && known_eq (x1_offset, x0_offset + GET_MODE_SIZE (inner_mode)) But yeah, a helper would be nice at some point. > However, I don't think that needs t
Re: O3 bootstraps fail on x86-64
Disabling asan the build works Original message From: graham stott via gcc-patches Date: 19/05/2018 10:30 (GMT+00:00) To: gcc-patches Subject: O3 bootstraps fail on x86-64 O3 bootstraps have started to fail to build since about Thursday. Due to an internal compiler error when building asan.c in function asan_emit_stack_protectìon tree-ssa--sccan.c:3396 Graham
[Patch, fortran] PR80657 - [7/8/9 Regression] Loop in character function declaration
I intend to commit this as 'obvious' once the patches for PR82923 and
82275 are out of the way.
Paul
2018-05-19 Paul Thomas
PR fortran/80657
* resolve.c (flag_fn_result_spec): Use the 'sym' argument to
test for self refs to the function result in the character len
expression. If a self reference is found, emit an error and
return true.
(resolve_fntype): Use the function symbol in the calls to the
above.
2018-05-19 Paul Thomas
PR fortran/80657
* gfortran.dg/char_result_18.f90: New test.
Index: gcc/fortran/resolve.c
===
*** gcc/fortran/resolve.c (revision 260389)
--- gcc/fortran/resolve.c (working copy)
*** resolve_equivalence (gfc_equiv *eq)
*** 16217,16223
static bool
flag_fn_result_spec (gfc_expr *expr,
! gfc_symbol *sym ATTRIBUTE_UNUSED,
int *f ATTRIBUTE_UNUSED)
{
gfc_namespace *ns;
--- 16217,16223
static bool
flag_fn_result_spec (gfc_expr *expr,
! gfc_symbol *sym,
int *f ATTRIBUTE_UNUSED)
{
gfc_namespace *ns;
*** flag_fn_result_spec (gfc_expr *expr,
*** 16230,16235
--- 16230,16242
if (!ns->parent)
break;
+ if (sym == s)
+ {
+ gfc_error ("Self reference in character length expression "
+ "for %qs at %L", sym->name, &expr->where);
+ return true;
+ }
+
if (!s->fn_result_spec
&& s->attr.flavor == FL_PARAMETER)
{
*** resolve_fntype (gfc_namespace *ns)
*** 16312,16318
}
if (sym->ts.type == BT_CHARACTER)
! gfc_traverse_expr (sym->ts.u.cl->length, NULL, flag_fn_result_spec, 0);
}
--- 16319,16325
}
if (sym->ts.type == BT_CHARACTER)
! gfc_traverse_expr (sym->ts.u.cl->length, sym, flag_fn_result_spec, 0);
}
Index: gcc/testsuite/gfortran.dg/char_result_18.f90
===
*** gcc/testsuite/gfortran.dg/char_result_18.f90 (nonexistent)
--- gcc/testsuite/gfortran.dg/char_result_18.f90 (working copy)
***
*** 0
--- 1,10
+ ! { dg-do compile }
+ !
+ ! Tests the fix for PR80657.
+ !
+ ! Contributed by Vittorio Zecca
+ !
+ function f(x)
+ implicit character(len(f)) (x) ! { dg-error "Self reference in character length" }
+ character(len(x)) f
+ end
RFA (symtab): PATCH to symtab_node::nonzero_address DECL_COMDAT handling for c++/80485
A comment earlier in in nonzero_address says, "Important case of WEAK
we want to do well are comdats. Those are handled by later check for
definition." But in this case we aren't handling this comdat function
well, we return false because it is DECL_WEAK and DECL_EXTERNAL
(because we aren't at EOF yet) and so we fail to fold the comparison.
This patch fixes the testcase by checking DECL_COMDAT directly.
Tested x86_64-pc-linux-gnu. OK for trunk?
commit a1a0c12db660aa94a625771a9f2fa9db30a552fe
Author: Jason Merrill
Date: Fri May 18 20:20:05 2018 -0400
PR c++/80485 - inline function non-zero address.
* symtab.c (nonzero_address): Check DECL_COMDAT.
diff --git a/gcc/symtab.c b/gcc/symtab.c
index c1533083573..faf0ccf3e61 100644
--- a/gcc/symtab.c
+++ b/gcc/symtab.c
@@ -1952,11 +1952,11 @@ symtab_node::nonzero_address ()
return true;
}
- /* If target is defined and not extern, we know it will be output and thus
- it will bind to non-NULL.
- Play safe for flag_delete_null_pointer_checks where weak definition maye
+ /* If target is defined and either comdat or not extern, we know it will be
+ output and thus it will bind to non-NULL.
+ Play safe for flag_delete_null_pointer_checks where weak definition may
be re-defined by NULL. */
- if (definition && !DECL_EXTERNAL (decl)
+ if (definition && (!DECL_EXTERNAL (decl) || DECL_COMDAT (decl))
&& (flag_delete_null_pointer_checks || !DECL_WEAK (decl)))
{
if (!DECL_WEAK (decl))
diff --git a/gcc/testsuite/g++.dg/expr/pmf-3.C b/gcc/testsuite/g++.dg/expr/pmf-3.C
new file mode 100644
index 000..fac42fc23a5
--- /dev/null
+++ b/gcc/testsuite/g++.dg/expr/pmf-3.C
@@ -0,0 +1,15 @@
+// PR c++/80485
+// { dg-do compile { target c++11 } }
+
+struct dummy {
+ void nonnull() {};
+ void nonnull2();
+};
+
+typedef void (dummy::*safe_bool)();
+
+constexpr safe_bool a = &dummy::nonnull;
+constexpr safe_bool b = &dummy::nonnull2;
+
+static_assert( static_cast( a ), "" );
+static_assert( static_cast( b ), "" );
[wwwdocs] Buildstat update for 5.5
Here's an update covering gcc 5.5.0. -tgc Testresults for 5.5.0: hppa2.0w-hp-hpux11.11 hppa64-hp-hpux11.11 powerpc64le-unknown-linux-gnu x86_64-unknown-freebsd12.0 x86_64-w64-mingw32 --- /home/tgc/projects/gcc/wwwdocs/htdocs/gcc-5/buildstat.html 2018-05-18 22:01:00.361974882 +0200 +++ buildstat.html 2018-05-19 15:15:39.183383794 +0200 @@ -83,6 +83,14 @@ +hppa2.0w-hp-hpux11.11 + +Test results: +https://gcc.gnu.org/ml/gcc-testresults/2017-10/msg02116.html";>5.5.0 + + + + hppa64-hp-hpux11.00 Test results: @@ -91,6 +99,14 @@ +hppa64-hp-hpux11.11 + +Test results: +https://gcc.gnu.org/ml/gcc-testresults/2017-10/msg02529.html";>5.5.0 + + + + i386-pc-solaris2.11 Test results: @@ -168,6 +184,7 @@ powerpc64le-unknown-linux-gnu Test results: +https://gcc.gnu.org/ml/gcc-testresults/2017-10/msg02085.html";>5.5.0, https://gcc.gnu.org/ml/gcc-testresults/2016-06/msg00322.html";>5.4.0, https://gcc.gnu.org/ml/gcc-testresults/2015-12/msg02804.html";>5.3.0 @@ -255,6 +272,14 @@ +x86_64-unknown-freebsd12.0 + +Test results: +https://gcc.gnu.org/ml/gcc-testresults/2017-11/msg00119.html";>5.5.0 + + + + x86_64-unknown-linux-gnu Test results: @@ -273,6 +298,7 @@ x86_64-w64-mingw32 Test results: +https://gcc.gnu.org/ml/gcc-testresults/2017-10/msg01084.html";>5.5.0, https://gcc.gnu.org/ml/gcc-testresults/2015-07/msg01714.html";>5.2.0, https://gcc.gnu.org/ml/gcc-testresults/2015-04/msg03077.html";>5.1.0
Re: [C++ Patch] PR 84588 ("[8 Regression] internal compiler error: Segmentation fault (contains_struct_check())") (Take 2)
On Fri, May 18, 2018 at 8:27 PM, Paolo Carlini wrote:
> On 19/05/2018 01:40, Jason Merrill wrote:
>> On Fri, May 18, 2018 at 1:40 PM, Paolo Carlini
>> wrote:
>>>
>>> Hi again,
>>>
>>> I'm playing with a wild, wild idea: would it make sense to try *first* an
>>> expression? Because, a quickly hacked draft appears to handle very
>>> elegantly
>>> all the possible cases of "junk" after the declarator, eg:
>>>
>>> void foo()
>>> {
>>> if (void bar()JUNK);
>>> }
>>>
>>> and the parenthesized case, etc, etc. Before trying to seriously work on
>>> that I wanted to ask...
>>
>> We'd need to try parsing as a declaration whether or not parsing as an
>> expression works, since any ambiguous cases are treated as
>> declarations [stmt.ambig].
>
> Yeah, that complicates the implementation of my idea. However, I'm thinking
> that at least *in the specific case of cp_parse_condition* from the
> computational complexity point of view probably we wouldn't regress much,
> because declarations are rare anyway, thus in most of the cases we end up
> doing both anyway. If we do expressions first and we save the result, then I
> believe when we can handle the declarator as something which cannot be a
> function or an array even if we don't see the initializer much more easily,
> we easily have a better diagnostic for things like
>
> if (int x);
>
> (another case we currently handle pretty badly, we don't talk about the
> missing initializer at all!), we cope elegantly with any junk following the
> wrong function/array declaration, etc. See that attached, if you are
> curious, which essentially passes the testsuite modulo a nit (*) which
> doesn't have anything to do with [stmt.ambig] per se (which of course is
> *not* correctly implemented in the wip).
>
> Can you give me your opinion about the more detailed idea, in particular
> whether we already have good infrastructure to implement [stmt.ambig] in
> this context, thus to keep the first parsing as an expression around,
> possibly returning to it if the parsing as a declaration fails??
I would expect it to cause different diagnostic issues, from
complaining about something not being a proper declaration when it's
really an expression. I also wonder about warning problems (either
missed or bogus) due to trying these in a different order.
How about doing cp_parser_commit_to_tentative_parse if we see
something that must be a declaration? cp_parser_simple_declaration
has
/* If we have seen at least one decl-specifier, and the next token
is not a parenthesis, then we must be looking at a declaration.
(After "int (" we might be looking at a functional cast.) */
if (decl_specifiers.any_specifiers_p
&& cp_lexer_next_token_is_not (parser->lexer, CPP_OPEN_PAREN)
&& cp_lexer_next_token_is_not (parser->lexer, CPP_OPEN_BRACE)
&& !cp_parser_error_occurred (parser))
cp_parser_commit_to_tentative_parse (parser);
That seems useful here, as well. Maybe factored into a separate function.
Jason
[PATCH, i386]: Merge SSE conversion patterns using SWI48 attribute
No functional changes.
2018-05-19 Uros Bizjak
* config/i386/i386.md (rex64namesuffix): New mode attribute.
* config/i386/sse.md (sse_cvtsi2ss):
Merge insn pattern from sse_cvtsi2ss and
sse_cvtsi2ssq using SWI48 mode iterator.
(sse_cvtss2si): Merge insn pattern
from sse_cvtss2si and sse_cvtss2siq
using SWI48 mode iterator.
(sse_cvtss2si_2): Merge insn pattern from
sse_cvtss2si_2 and sse_cvtss2siq_2 using SWI48 mode iterator.
(sse_cvttss2si): Merge insn
pattern from sse_cvttss2si
and sse_cvttss2siq using SWI48 mode iterator.
(avx512f_vcvtss2usi): Merge insn pattern
from avx512f_vcvtss2usi and avx512f_vcvtss2usiq
using SWI48 mode iterator.
(avx512f_vcvttss2usi): Merge
insn pattern from avx512f_vcvttss2usi and
avx512f_vcvttss2usiq using SWI48 mode iterator.
(avx512f_vcvtsd2usi): Merge insn pattern
from avx512f_vcvtsd2usi and avx512f_vcvtsd2usiq
using SWI48 mode iterator.
(avx512f_vcvttsd2usi): Merge
insn pattern from avx512f_vcvttsd2usi and
avx512f_vcvttsd2usiq using SWI48 mode iterator.
(sse2_cvtsd2si): Merge insn pattern from
sse2_cvtsd2si and sse2_cvtsd2siq using
SWI48 mode iterator.
(sse2_cvtsd2si_2): Merge insn pattern from
sse2_cvtsd2si_2 and sse2_cvtsd2siq_2 using SWI48 mode iterator.
(sse_cvttsd2si): Merge insn
pattern from sse_cvttsd2si
and sse_cvttsd2siq using SWI48 mode iterator.
Bootstrapped and regression tested on x86_64-linux-gnu {,-m32}.
Committed to mainline SVN.
Uros.
Index: config/i386/i386.md
===
--- config/i386/i386.md (revision 260389)
+++ config/i386/i386.md (working copy)
@@ -1212,6 +1212,7 @@
;; Instruction suffix for REX 64bit operators.
(define_mode_attr rex64suffix [(SI "") (DI "{q}")])
+(define_mode_attr rex64namesuffix [(SI "") (DI "q")])
;; This mode iterator allows :P to be used for patterns that operate on
;; pointer-sized quantities. Exactly one of the two alternatives will match.
Index: config/i386/sse.md
===
--- config/i386/sse.md (revision 260389)
+++ config/i386/sse.md (working copy)
@@ -4360,18 +4360,18 @@
(set_attr "prefix_rep" "0")
(set_attr "mode" "SF")])
-(define_insn "sse_cvtsi2ss"
+(define_insn "sse_cvtsi2ss"
[(set (match_operand:V4SF 0 "register_operand" "=x,x,v")
(vec_merge:V4SF
(vec_duplicate:V4SF
- (float:SF (match_operand:SI 2 ""
"r,m,")))
+ (float:SF (match_operand:SWI48 2 ""
"r,m,")))
(match_operand:V4SF 1 "register_operand" "0,0,v")
(const_int 1)))]
"TARGET_SSE"
"@
- cvtsi2ss\t{%2, %0|%0, %2}
- cvtsi2ss\t{%2, %0|%0, %2}
- vcvtsi2ss\t{%2, %1, %0|%0, %1, %2}"
+ cvtsi2ss\t{%2, %0|%0, %2}
+ cvtsi2ss\t{%2, %0|%0, %2}
+ vcvtsi2ss\t{%2, %1, %0|%0, %1, %2}"
[(set_attr "isa" "noavx,noavx,avx")
(set_attr "type" "sseicvt")
(set_attr "athlon_decode" "vector,double,*")
@@ -4379,54 +4379,43 @@
(set_attr "bdver1_decode" "double,direct,*")
(set_attr "btver2_decode" "double,double,double")
(set_attr "znver1_decode" "double,double,double")
+ (set (attr "length_vex")
+ (if_then_else
+ (and (match_test "mode == DImode")
+ (eq_attr "alternative" "2"))
+ (const_string "4")
+ (const_string "*")))
+ (set (attr "prefix_rex")
+ (if_then_else
+ (and (match_test "mode == DImode")
+ (eq_attr "alternative" "0,1"))
+ (const_string "1")
+ (const_string "*")))
(set_attr "prefix" "orig,orig,maybe_evex")
(set_attr "mode" "SF")])
-(define_insn "sse_cvtsi2ssq"
- [(set (match_operand:V4SF 0 "register_operand" "=x,x,v")
- (vec_merge:V4SF
- (vec_duplicate:V4SF
- (float:SF (match_operand:DI 2 ""
"r,m,")))
- (match_operand:V4SF 1 "register_operand" "0,0,v")
- (const_int 1)))]
- "TARGET_SSE && TARGET_64BIT"
- "@
- cvtsi2ssq\t{%2, %0|%0, %2}
- cvtsi2ssq\t{%2, %0|%0, %2}
- vcvtsi2ssq\t{%2, %1, %0|%0, %1, %2}"
- [(set_attr "isa" "noavx,noavx,avx")
- (set_attr "type" "sseicvt")
- (set_attr "athlon_decode" "vector,double,*")
- (set_attr "amdfam10_decode" "vector,double,*")
- (set_attr "bdver1_decode" "double,direct,*")
- (set_attr "btver2_decode" "double,double,double")
- (set_attr "length_vex" "*,*,4")
- (set_attr "prefix_rex" "1,1,*")
- (set_attr "prefix" "orig,orig,maybe_evex")
- (set_attr "mode" "SF")])
-
-(define_insn "sse_cvtss2si"
- [(set (match_operand:SI 0 "register_operand" "=r,r")
- (unspec:SI
+(define_insn "sse_cvtss2si"
+ [(set (match_operand:SWI48 0 "register_operand" "=r,r")
+ (unspec:SWI48
[(vec_select:SF
(match_operand:V4SF 1 ""
"v,")
(parallel [(const_int 0)]))]
UNSPEC_FIX_NOTRUNC))]
"TARGET_SSE"
- "%vcvtss2si\t{%1, %0|%0, %k1}"
+ "%vcvtss2si\t{%1, %0|%0, %k1}"
[(set_attr
[Patch, fortran] PR 49636 - [F03] ASSOCIATE construct confused with slightly complicated case
This patch is a straightforward recycling of existing code to replace
an incomplete copy elsewhere.
Bootstraps and regtests on FC27/x86_64 - OK for trunk down to 7-branch?
Paul
2018-05-19 Paul Thomas
PR fortran/49636
* trans-array.c (gfc_get_array_span): Renamed from
'get_array_span'.
(gfc_conv_expr_descriptor): Change references to above.
* trans-array.h : Add prototype for 'gfc_get_array_span'.
* trans-stmt.c (trans_associate_var): If the associate name is
a subref array pointer, use gfc_get_array_span for the span.
2018-05-19 Paul Thomas
PR fortran/49636
* gfortran.dg/associate_38.f90: New test.
Index: gcc/fortran/trans-array.c
===
*** gcc/fortran/trans-array.c (revision 260392)
--- gcc/fortran/trans-array.c (working copy)
*** is_pointer_array (tree expr)
*** 817,824
/* Return the span of an array. */
! static tree
! get_array_span (tree desc, gfc_expr *expr)
{
tree tmp;
--- 817,824
/* Return the span of an array. */
! tree
! gfc_get_array_span (tree desc, gfc_expr *expr)
{
tree tmp;
*** gfc_conv_expr_descriptor (gfc_se *se, gf
*** 7061,7067
subref_array_target, expr);
/* and set the span field. */
! tmp = get_array_span (desc, expr);
gfc_conv_descriptor_span_set (&se->pre, se->expr, tmp);
}
else if (se->want_pointer)
--- 7061,7067
subref_array_target, expr);
/* and set the span field. */
! tmp = gfc_get_array_span (desc, expr);
gfc_conv_descriptor_span_set (&se->pre, se->expr, tmp);
}
else if (se->want_pointer)
*** gfc_conv_expr_descriptor (gfc_se *se, gf
*** 7334,7340
parmtype = TREE_TYPE (parm);
/* and set the span field. */
! tmp = get_array_span (desc, expr);
gfc_conv_descriptor_span_set (&loop.pre, parm, tmp);
}
else
--- 7334,7340
parmtype = TREE_TYPE (parm);
/* and set the span field. */
! tmp = gfc_get_array_span (desc, expr);
gfc_conv_descriptor_span_set (&loop.pre, parm, tmp);
}
else
Index: gcc/fortran/trans-array.h
===
*** gcc/fortran/trans-array.h (revision 260391)
--- gcc/fortran/trans-array.h (working copy)
*** void gfc_conv_tmp_array_ref (gfc_se * se
*** 136,141
--- 136,143
/* Translate a reference to an array temporary. */
void gfc_conv_tmp_ref (gfc_se *);
+ /* Obtain the span of an array. */
+ tree gfc_get_array_span (tree, gfc_expr *);
/* Evaluate an array expression. */
void gfc_conv_expr_descriptor (gfc_se *, gfc_expr *);
/* Convert an array for passing as an actual function parameter. */
Index: gcc/fortran/trans-stmt.c
===
*** gcc/fortran/trans-stmt.c (revision 260391)
--- gcc/fortran/trans-stmt.c (working copy)
*** trans_associate_var (gfc_symbol *sym, gf
*** 1735,1745
if (sym->attr.subref_array_pointer)
{
gcc_assert (e->expr_type == EXPR_VARIABLE);
! tmp = e->symtree->n.sym->ts.type == BT_CLASS
! ? gfc_class_data_get (e->symtree->n.sym->backend_decl)
! : e->symtree->n.sym->backend_decl;
! tmp = gfc_get_element_type (TREE_TYPE (tmp));
! tmp = fold_convert (gfc_array_index_type, size_in_bytes (tmp));
gfc_conv_descriptor_span_set (&se.pre, desc, tmp);
}
--- 1735,1742
if (sym->attr.subref_array_pointer)
{
gcc_assert (e->expr_type == EXPR_VARIABLE);
! tmp = gfc_get_array_span (se.expr, e);
!
gfc_conv_descriptor_span_set (&se.pre, desc, tmp);
}
Index: gcc/testsuite/gfortran.dg/associate_38.f90
===
*** gcc/testsuite/gfortran.dg/associate_38.f90 (nonexistent)
--- gcc/testsuite/gfortran.dg/associate_38.f90 (working copy)
***
*** 0
--- 1,22
+ ! { dg-do run }
+ !
+ ! Test the fix for PR49636 in which the 'span' of 'ty1' was not used
+ ! in the descriptor of 'i'.
+ !
+ ! Contributed by Fred Krogh
+ !
+ program test
+ type ty1
+ integer :: k
+ integer :: i
+ end type ty1
+ type ty2
+ type(ty1) :: j(3)
+ end type ty2
+
+ type(ty2) t2
+ t2%j(1:3)%i = [ 1, 3, 5 ]
+ associate (i=>t2%j%i)
+ if (any (t2%j(1:3)%i .ne. i(1:3))) stop 1
+ end associate
+ end program test
Re: [Patch, fortran] PR82275 - gfortran rejects valid & accepts invalid reference to dimension-remapped type SELECT TYPE selector
On Sat, May 19, 2018 at 09:34:13AM +0100, Paul Richard Thomas wrote: > This patch is verging on 'obvious' since there was no attempt being > made to detect dimensions where the array reference of the selector is > an element. In fact, I made an attempt when the bug was first reported > to do this, Not realizing that the elements were coming through as > DIMEN_UNKNOWN, the attempt failed. This is now catered for. > > Bootstrapped and regtested on FC27/x86_64. OK for all active branches? > OK. -- Steve
Re: [Patch, fortran] PR 49636 - [F03] ASSOCIATE construct confused with slightly complicated case
On Sat, May 19, 2018 at 04:42:35PM +0100, Paul Richard Thomas wrote: > This patch is a straightforward recycling of existing code to replace > an incomplete copy elsewhere. > > Bootstraps and regtests on FC27/x86_64 - OK for trunk down to 7-branch? > OK. -- Steve
Re: Rb_tree constructor optimization
On Fri, May 18, 2018 at 6:45 PM, Jonathan Wakely wrote: > On 17/05/18 16:10 +0100, Jonathan Wakely wrote: >> >> On 15/05/18 07:30 +0200, François Dumont wrote: >>> >>> Here it is again even more simplified. Should I backport the Debug mode >>> fix to 8 branch ? >> >> >> Yes, please do backport the include/debug/* changes. >> >> >>> * include/bits/stl_tree.h >>> (_Rb_tree_impl(_Rb_tree_impl&&, _Node_allocator&&)): New. >>> (_Rb_tree(_Rb_tree&&, _Node_allocator&&, true_type)): New, use >>> latter. >>> (_Rb_tree(_Rb_tree&&, _Node_allocator&&, false_type)): New. >>> (_Rb_tree(_Rb_tree&&, _Node_allocator&&)): Adapt, use latters. >>> * include/debug/map.h >>> (map(map&&, const_allocator_type&)): Add noexcept qualitication. >>> * include/debug/multimap.h >>> (multimap(multimap&&, const_allocator_type&)): Add noexcept >>> qualification. >>> * include/debug/set.h >>> (set(set&&, const_allocator_type&)): Add noexcept qualitication. >>> * include/debug/multiset.h >>> (multiset(multiset&&, const_allocator_type&)): Add noexcept >>> qualification. >>> * testsuite/23_containers/map/cons/noexcept_default_construct.cc: >>> Add checks. >>> * testsuite/23_containers/map/cons/noexcept_move_construct.cc: >>> Add checks. >>> * >>> testsuite/23_containers/multimap/cons/noexcept_default_construct.cc: >>> Add checks. >>> * testsuite/23_containers/multimap/cons/noexcept_move_construct.cc: >>> Add checks. >>> * >>> testsuite/23_containers/multiset/cons/noexcept_default_construct.cc: >>> Add checks. >>> * testsuite/23_containers/multiset/cons/noexcept_move_construct.cc: >>> Add checks. >>> * testsuite/23_containers/set/cons/noexcept_default_construct.cc: >>> Add checks. >>> * testsuite/23_containers/set/cons/noexcept_move_construct.cc: >>> Add checks. >>> >>> Ok to commit ? >> >> >> Yes, OK for trunk - thanks. >> >> > > I'm seeing lots of new testsuite failures after this commit, see > https://gcc.gnu.org/ml/gcc-testresults/2018-05/msg02025.html > > I opened: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85845 -- H.J.
