Re: [Patch, Fortran, OOP] PR 58175: Incorrect warning message on scalar finalizer
I have just committed as obvious a minor addition here: https://gcc.gnu.org/viewcvs?rev=243218&root=gcc&view=rev It deals with an extended test case that was only reported after the initial fix. Cheers, Janus 2016-11-29 15:16 GMT+01:00 Janus Weil : > Committed as r242960. > > > > 2016-11-28 14:36 GMT+01:00 Janus Weil : >> Hi all, >> >> the attached patch was posted on bugzilla by Tobias three years ago, >> but left unattended since then. It is simple, works well (fixing a >> bogus warning) and regtests cleanly on x86_64-linux-gnu. >> >> If no one objects, I will commit this to trunk by tomorrow. >> >> Cheers, >> Janus >> >> >> >> 2016-11-28 Tobias Burnus >> >> PR fortran/58175 >> * resolve.c (gfc_resolve_finalizers): Properly detect scalar finalizers. >> >> 2016-11-28 Janus Weil >> >> PR fortran/58175 >> * gfortran.dg/finalize_30.f90: New test case. Index: gcc/fortran/resolve.c === --- gcc/fortran/resolve.c (revision 243217) +++ gcc/fortran/resolve.c (working copy) @@ -12517,7 +12517,7 @@ error: /* Warn if we haven't seen a scalar finalizer procedure (but we know there were nodes in the list, must have been for arrays. It is surely a good idea to have a scalar version there if there's something to finalize. */ - if (warn_surprising && result && !seen_scalar) + if (warn_surprising && derived->f2k_derived->finalizers && !seen_scalar) gfc_warning (OPT_Wsurprising, "Only array FINAL procedures declared for derived type %qs" " defined at %L, suggest also scalar one", Index: gcc/testsuite/gfortran.dg/finalize_30.f90 === --- gcc/testsuite/gfortran.dg/finalize_30.f90 (revision 243217) +++ gcc/testsuite/gfortran.dg/finalize_30.f90 (working copy) @@ -10,6 +10,8 @@ module ct contains final :: aD end type + type, extends(a) :: a1 + end type contains subroutine aD(self) type(a), intent(inout) :: self
Re: PR78634: ifcvt/i386 cost updates
On Fri, Dec 2, 2016 at 8:58 PM, James Greenhalgh wrote: > On Fri, Dec 02, 2016 at 05:00:05PM +0100, Bernd Schmidt wrote: >> With the i386 backend no longer double-counting the cost of a SET, >> the default implementation default_max_noce_ifcvt_seq_cost now >> provides too high a bound for if conversion, allowing very costly >> substitutions. >> >> The following patch fixes this by making an i386 variant of the >> hook, but first - James, do you recall how you arrived at the >> COSTS_N_INSNS(3) magic number? What happens on arm if you lower that >> in the default hook? > > Hi Bernd, > > Given the magic numbers in BRANCH_COST already, 3 was chosen to give a > resonable chance of allowing if-conversion of blocks containing multiple > sets. iWe need to do this because for AArch64 and x86 the conditional > move pattern will expand to two further patterns, each of which will get > a cost (before my cost model patches you would simply count the total > number of expansions you would make, so the multiplication by three is > to compensate) > > I wouldn't say there was much scientific to choosing between 2 and 3 > beyond looking at cases which worked on x86_64 and AArch64 before I > modified the cost model, and again after, and trying to maintain the > number of such cases which were if-converted. > > Setting this to 2 in the generic hook and forcing AArch64 to run with > a custom hook would be just as correct as this patch (though arguably > yours is the better Stage 3 patch as it has more limited scope). Based on the above explanation, the patch is OK. Thanks, Uros.
[PATCH] Added noexcept on constructors
---
libstdc++-v3/ChangeLog | 3 +++
libstdc++-v3/src/c++11/shared_ptr.cc | 4 ++--
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/libstdc++-v3/ChangeLog b/libstdc++-v3/ChangeLog
index 08d9229..18924c4 100644
--- a/libstdc++-v3/ChangeLog
+++ b/libstdc++-v3/ChangeLog
@@ -1,3 +1,6 @@
+2016-12-03 Aditya Kumar
+ * src/c++11/shared_ptr.cc: Added noexcept on constructors.
+
2016-12-01 David Edelsohn
* testsuite/26_numerics/headers/cmath/hypot.cc: XFAIL on AIX.
diff --git a/libstdc++-v3/src/c++11/shared_ptr.cc
b/libstdc++-v3/src/c++11/shared_ptr.cc
index 9028040..b4addd0 100644
--- a/libstdc++-v3/src/c++11/shared_ptr.cc
+++ b/libstdc++-v3/src/c++11/shared_ptr.cc
@@ -56,7 +56,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
{ return _Hash_impl::hash(addr) & __gnu_internal::mask; }
}
- _Sp_locker::_Sp_locker(const void* p)
+ _Sp_locker::_Sp_locker(const void* p) noexcept
{
if (__gthread_active_p())
{
@@ -67,7 +67,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
_M_key1 = _M_key2 = __gnu_internal::invalid;
}
- _Sp_locker::_Sp_locker(const void* p1, const void* p2)
+ _Sp_locker::_Sp_locker(const void* p1, const void* p2) noexcept
{
if (__gthread_active_p())
{
--
2.5.0
Re: [PATCH, Fortran, v2] Fix deallocation of nested derived typed components
Hi Dominique,
thanks for immediately finding the issues. Please find an updated and extended
patch. This time trunk w/o this patch ICEs on compiling the _4-testcase and
accesses freed memory for the _3-testcase. Furthermore are now components of
derived-typed coarrays deregistered correctly instead of being freed as trunk
did.
I also have addressed the ICEs with proc_pointer components.
Bootstraps and regtests ok on x86_64-linux/F23. Ok for trunk?
Regards,
Andre
On Sat, 3 Dec 2016 02:17:30 +0100
Dominique d'Humières wrote:
> Dear Andre,
>
> After having applied the patch to my working tree, compiling the tests in
> pr61952 or pr64381 gives the ICE
>
>END SUBROUTINE sm_multiply
>
> internal compiler error: in gfc_get_element_type, at
> fortran/trans-types.c:1185
>
> Also the name coarray_alloc_comp_3.f08 does not seem right as there is no
> carry involved. Note that the test compiles and executes with at least a
> clean trunk and 6.2.0.
>
> Cheers,
>
> Dominique
>
--
Andre Vehreschild * Email: vehre ad gmx dot de
gcc/fortran/ChangeLog:
2016-12-03 Andre Vehreschild
* trans-array.c (structure_alloc_comps): Restructure deallocation of
(nested) allocatable components. Insert dealloc of sub-component into
the block guarded by the if != NULL for the component.
* trans.c (gfc_deallocate_with_status): Allow deallocation of scalar
and arrays as well as coarrays.
(gfc_deallocate_scalar_with_status): Get the data member for coarrays
only when freeing an array with descriptor. And set correct caf_mode
when freeing components of coarrays.
* trans.h: Change prototype of gfc_deallocate_with_status to allow
adding statements into the block guarded by the if (pointer != 0) and
supply a coarray handle.
gcc/testsuite/ChangeLog:
2016-12-03 Andre Vehreschild
* gfortran.dg/coarray_alloc_comp_3.f08: New test.
* gfortran.dg/coarray_alloc_comp_4.f08: New test.
* gfortran.dg/finalize_18.f90: Add count for additional guard against
accessing null-pointer.
diff --git a/gcc/fortran/trans-array.c b/gcc/fortran/trans-array.c
index ac90a4b..1d48c63 100644
--- a/gcc/fortran/trans-array.c
+++ b/gcc/fortran/trans-array.c
@@ -8157,8 +8157,11 @@ structure_alloc_comps (gfc_symbol * der_type, tree decl,
tree null_cond = NULL_TREE;
tree add_when_allocated;
tree dealloc_fndecl;
- bool called_dealloc_with_status;
+ tree caf_token;
gfc_symbol *vtab;
+ int caf_dereg_mode;
+ symbol_attribute *attr;
+ bool deallocate_called;
gfc_init_block (&fnblock);
@@ -8265,7 +8268,8 @@ structure_alloc_comps (gfc_symbol * der_type, tree decl,
bool cmp_has_alloc_comps = (c->ts.type == BT_DERIVED
|| c->ts.type == BT_CLASS)
&& c->ts.u.derived->attr.alloc_comp;
- bool same_type = c->ts.type == BT_DERIVED && der_type == c->ts.u.derived;
+ bool same_type = (c->ts.type == BT_DERIVED && der_type == c->ts.u.derived)
+ || (c->ts.type == BT_CLASS && der_type == CLASS_DATA (c)->ts.u.derived);
cdecl = c->backend_decl;
ctype = TREE_TYPE (cdecl);
@@ -8274,112 +8278,118 @@ structure_alloc_comps (gfc_symbol * der_type, tree decl,
{
case DEALLOCATE_ALLOC_COMP:
- /* gfc_deallocate_scalar_with_status calls gfc_deallocate_alloc_comp
- (i.e. this function) so generate all the calls and suppress the
- recursion from here, if necessary. */
- called_dealloc_with_status = false;
gfc_init_block (&tmpblock);
+ comp = fold_build3_loc (input_location, COMPONENT_REF, ctype,
+ decl, cdecl, NULL_TREE);
+
+ /* Shortcut to get the attributes of the component. */
+ if (c->ts.type == BT_CLASS)
+ attr = &CLASS_DATA (c)->attr;
+ else
+ attr = &c->attr;
+
if ((c->ts.type == BT_DERIVED && !c->attr.pointer)
- || (c->ts.type == BT_CLASS && !CLASS_DATA (c)->attr.class_pointer))
- {
- comp = fold_build3_loc (input_location, COMPONENT_REF, ctype,
- decl, cdecl, NULL_TREE);
+ || (c->ts.type == BT_CLASS && !CLASS_DATA (c)->attr.class_pointer))
+ /* Call the finalizer, which will free the memory and nullify the
+ pointer of an array. */
+ deallocate_called = gfc_add_comp_finalizer_call (&tmpblock, comp, c,
+ caf_enabled (caf_mode))
+ && attr->dimension;
+ else
+ deallocate_called = false;
- /* The finalizer frees allocatable components. */
- called_dealloc_with_status
- = gfc_add_comp_finalizer_call (&tmpblock, comp, c,
- purpose == DEALLOCATE_ALLOC_COMP
- && caf_enabled (caf_mode));
+ /* Add the _class ref for classes. */
+ if (c->ts.type == BT_CLASS && attr->allocatable)
+ comp = gfc_class_data_get (comp);
+
+ add_when_allocated = NULL_TREE;
+ if (cmp_has_alloc_comps
+ && !c->attr.pointer && !c->attr.proc_pointer
+ && !same_type
+ && !deallocate_called)
+ {
+ /* Add checked deallocation of
Re: [PATCH] Added noexcept on constructors
On 3 December 2016 at 13:31, Aditya K wrote:
> ---
> libstdc++-v3/ChangeLog | 3 +++
> libstdc++-v3/src/c++11/shared_ptr.cc | 4 ++--
> 2 files changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/libstdc++-v3/ChangeLog b/libstdc++-v3/ChangeLog
> index 08d9229..18924c4 100644
> --- a/libstdc++-v3/ChangeLog
> +++ b/libstdc++-v3/ChangeLog
> @@ -1,3 +1,6 @@
> +2016-12-03 Aditya Kumar
> + * src/c++11/shared_ptr.cc: Added noexcept on constructors.
> +
> 2016-12-01 David Edelsohn
Please separate the ChangeLogs from patches - Changelog needs to be
temporally linear, and doesn't merge well.
For reference, see the ChangeLog part of https://gcc.gnu.org/contribute.html
> diff --git a/libstdc++-v3/src/c++11/shared_ptr.cc
> b/libstdc++-v3/src/c++11/shared_ptr.cc
> index 9028040..b4addd0 100644
> --- a/libstdc++-v3/src/c++11/shared_ptr.cc
> +++ b/libstdc++-v3/src/c++11/shared_ptr.cc
> @@ -56,7 +56,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
> { return _Hash_impl::hash(addr) & __gnu_internal::mask; }
>}
>
> - _Sp_locker::_Sp_locker(const void* p)
> + _Sp_locker::_Sp_locker(const void* p) noexcept
>{
> if (__gthread_active_p())
>{
> @@ -67,7 +67,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>_M_key1 = _M_key2 = __gnu_internal::invalid;
>}
>
> - _Sp_locker::_Sp_locker(const void* p1, const void* p2)
> + _Sp_locker::_Sp_locker(const void* p1, const void* p2) noexcept
>{
> if (__gthread_active_p())
>{
It would be helpful to mention rationale for patches, and add tests to
verify correct functionality. However, in this
case it's fairly obvious that the noexcept-spec of the class
definition declarations of these constructors disagree with the
definitions.
Re: [PATCH] Added noexcept on constructors
On 3 December 2016 at 14:20, Ville Voutilainen wrote: > On 3 December 2016 at 13:31, Aditya K wrote: >> --- >> libstdc++-v3/ChangeLog | 3 +++ >> libstdc++-v3/src/c++11/shared_ptr.cc | 4 ++-- >> 2 files changed, 5 insertions(+), 2 deletions(-) >> >> diff --git a/libstdc++-v3/ChangeLog b/libstdc++-v3/ChangeLog >> index 08d9229..18924c4 100644 >> --- a/libstdc++-v3/ChangeLog >> +++ b/libstdc++-v3/ChangeLog >> @@ -1,3 +1,6 @@ >> +2016-12-03 Aditya Kumar >> + * src/c++11/shared_ptr.cc: Added noexcept on constructors. >> + >> 2016-12-01 David Edelsohn > > > Please separate the ChangeLogs from patches - Changelog needs to be > temporally linear, and doesn't merge well. > For reference, see the ChangeLog part of https://gcc.gnu.org/contribute.html I also failed to mention that a proper ChangeLog entry contains the context of the change, for example 2016-12-01 Ville Voutilainen Implement LWG 2766, Swapping non-swappable types and LWG 2749, swappable traits for variants. * include/bits/move.h (swap(_Tp&, _Tp&)): Constrain with __is_tuple_like. Note the parenthesized mention of swap.
New French PO file for 'gcc' (version 6.2.0)
Hello, gentle maintainer. This is a message from the Translation Project robot. A revised PO file for textual domain 'gcc' has been submitted by the French team of translators. The file is available at: http://translationproject.org/latest/gcc/fr.po (This file, 'gcc-6.2.0.fr.po', has just now been sent to you in a separate email.) All other PO files for your package are available in: http://translationproject.org/latest/gcc/ Please consider including all of these in your next release, whether official or a pretest. Whenever you have a new distribution with a new version number ready, containing a newer POT file, please send the URL of that distribution tarball to the address below. The tarball may be just a pretest or a snapshot, it does not even have to compile. It is just used by the translators when they need some extra translation context. The following HTML page has been updated: http://translationproject.org/domain/gcc.html If any question arises, please contact the translation coordinator. Thank you for all your work, The Translation Project robot, in the name of your translation coordinator.
[committed] Update baseline symbols on hppa-linux
The attached change update the baseline symbols for libstdc++ on hppa-linux-gnu. Committed to trunk. Dave -- John David Anglin dave.ang...@bell.net 2016-12-03 John David Anglin * config/abi/post/hppa-linux-gnu/baseline_symbols.txt: Regenerate. Index: config/abi/post/hppa-linux-gnu/baseline_symbols.txt === --- config/abi/post/hppa-linux-gnu/baseline_symbols.txt (revision 243215) +++ config/abi/post/hppa-linux-gnu/baseline_symbols.txt (working copy) @@ -1,3 +1,72 @@ +FUNC:_ZGTtNKSt11logic_error4whatEv@@GLIBCXX_3.4.22 +FUNC:_ZGTtNKSt13bad_exception4whatEv@@CXXABI_1.3.10 +FUNC:_ZGTtNKSt13bad_exceptionD1Ev@@CXXABI_1.3.10 +FUNC:_ZGTtNKSt13runtime_error4whatEv@@GLIBCXX_3.4.22 +FUNC:_ZGTtNKSt9exception4whatEv@@CXXABI_1.3.10 +FUNC:_ZGTtNKSt9exceptionD1Ev@@CXXABI_1.3.10 +FUNC:_ZGTtNSt11logic_errorC1EPKc@@GLIBCXX_3.4.22 +FUNC:_ZGTtNSt11logic_errorC1ERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE@@GLIBCXX_3.4.22 +FUNC:_ZGTtNSt11logic_errorC2EPKc@@GLIBCXX_3.4.22 +FUNC:_ZGTtNSt11logic_errorC2ERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE@@GLIBCXX_3.4.22 +FUNC:_ZGTtNSt11logic_errorD0Ev@@GLIBCXX_3.4.22 +FUNC:_ZGTtNSt11logic_errorD1Ev@@GLIBCXX_3.4.22 +FUNC:_ZGTtNSt11logic_errorD2Ev@@GLIBCXX_3.4.22 +FUNC:_ZGTtNSt11range_errorC1EPKc@@GLIBCXX_3.4.22 +FUNC:_ZGTtNSt11range_errorC1ERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE@@GLIBCXX_3.4.22 +FUNC:_ZGTtNSt11range_errorC2EPKc@@GLIBCXX_3.4.22 +FUNC:_ZGTtNSt11range_errorC2ERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE@@GLIBCXX_3.4.22 +FUNC:_ZGTtNSt11range_errorD0Ev@@GLIBCXX_3.4.22 +FUNC:_ZGTtNSt11range_errorD1Ev@@GLIBCXX_3.4.22 +FUNC:_ZGTtNSt11range_errorD2Ev@@GLIBCXX_3.4.22 +FUNC:_ZGTtNSt12domain_errorC1EPKc@@GLIBCXX_3.4.22 +FUNC:_ZGTtNSt12domain_errorC1ERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE@@GLIBCXX_3.4.22 +FUNC:_ZGTtNSt12domain_errorC2EPKc@@GLIBCXX_3.4.22 +FUNC:_ZGTtNSt12domain_errorC2ERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE@@GLIBCXX_3.4.22 +FUNC:_ZGTtNSt12domain_errorD0Ev@@GLIBCXX_3.4.22 +FUNC:_ZGTtNSt12domain_errorD1Ev@@GLIBCXX_3.4.22 +FUNC:_ZGTtNSt12domain_errorD2Ev@@GLIBCXX_3.4.22 +FUNC:_ZGTtNSt12length_errorC1EPKc@@GLIBCXX_3.4.22 +FUNC:_ZGTtNSt12length_errorC1ERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE@@GLIBCXX_3.4.22 +FUNC:_ZGTtNSt12length_errorC2EPKc@@GLIBCXX_3.4.22 +FUNC:_ZGTtNSt12length_errorC2ERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE@@GLIBCXX_3.4.22 +FUNC:_ZGTtNSt12length_errorD0Ev@@GLIBCXX_3.4.22 +FUNC:_ZGTtNSt12length_errorD1Ev@@GLIBCXX_3.4.22 +FUNC:_ZGTtNSt12length_errorD2Ev@@GLIBCXX_3.4.22 +FUNC:_ZGTtNSt12out_of_rangeC1EPKc@@GLIBCXX_3.4.22 +FUNC:_ZGTtNSt12out_of_rangeC1ERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE@@GLIBCXX_3.4.22 +FUNC:_ZGTtNSt12out_of_rangeC2EPKc@@GLIBCXX_3.4.22 +FUNC:_ZGTtNSt12out_of_rangeC2ERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE@@GLIBCXX_3.4.22 +FUNC:_ZGTtNSt12out_of_rangeD0Ev@@GLIBCXX_3.4.22 +FUNC:_ZGTtNSt12out_of_rangeD1Ev@@GLIBCXX_3.4.22 +FUNC:_ZGTtNSt12out_of_rangeD2Ev@@GLIBCXX_3.4.22 +FUNC:_ZGTtNSt13runtime_errorC1EPKc@@GLIBCXX_3.4.22 +FUNC:_ZGTtNSt13runtime_errorC1ERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE@@GLIBCXX_3.4.22 +FUNC:_ZGTtNSt13runtime_errorC2EPKc@@GLIBCXX_3.4.22 +FUNC:_ZGTtNSt13runtime_errorC2ERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE@@GLIBCXX_3.4.22 +FUNC:_ZGTtNSt13runtime_errorD0Ev@@GLIBCXX_3.4.22 +FUNC:_ZGTtNSt13runtime_errorD1Ev@@GLIBCXX_3.4.22 +FUNC:_ZGTtNSt13runtime_errorD2Ev@@GLIBCXX_3.4.22 +FUNC:_ZGTtNSt14overflow_errorC1EPKc@@GLIBCXX_3.4.22 +FUNC:_ZGTtNSt14overflow_errorC1ERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE@@GLIBCXX_3.4.22 +FUNC:_ZGTtNSt14overflow_errorC2EPKc@@GLIBCXX_3.4.22 +FUNC:_ZGTtNSt14overflow_errorC2ERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE@@GLIBCXX_3.4.22 +FUNC:_ZGTtNSt14overflow_errorD0Ev@@GLIBCXX_3.4.22 +FUNC:_ZGTtNSt14overflow_errorD1Ev@@GLIBCXX_3.4.22 +FUNC:_ZGTtNSt14overflow_errorD2Ev@@GLIBCXX_3.4.22 +FUNC:_ZGTtNSt15underflow_errorC1EPKc@@GLIBCXX_3.4.22 +FUNC:_ZGTtNSt15underflow_errorC1ERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE@@GLIBCXX_3.4.22 +FUNC:_ZGTtNSt15underflow_errorC2EPKc@@GLIBCXX_3.4.22 +FUNC:_ZGTtNSt15underflow_errorC2ERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE@@GLIBCXX_3.4.22 +FUNC:_ZGTtNSt15underflow_errorD0Ev@@GLIBCXX_3.4.22 +FUNC:_ZGTtNSt15underflow_errorD1Ev@@GLIBCXX_3.4.22 +FUNC:_ZGTtNSt15underflow_errorD2Ev@@GLIBCXX_3.4.22 +FUNC:_ZGTtNSt16invalid_argumentC1EPKc@@GLIBCXX_3.4.22 +FUNC:_ZGTtNSt16invalid_argumentC1ERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE@@GLIBCXX_3.4.22 +FUNC:_ZGTtNSt16invalid_argumentC2EPKc@@GLIBCXX_3.4.22 +FUNC:_ZGTtNSt16invalid_argumentC2ERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE@@GLIBCXX_3.4.22 +FUNC:_ZGTtNSt16invalid_argumentD0Ev@@GLIBCXX_3.4.22 +FUNC:_ZGTtNSt16invalid_argumentD1Ev@@GLIBCXX_3.4.22 +FUNC:_ZGTtNSt16invalid_argumentD2Ev@@GLIBCXX_3.4.22 FUNC:_
Re: [PATCH v3] Do not simplify "(and (reg) (const bit))" to if_then_else.
On Dez 01 2016, Dominik Vogt wrote: > gcc/ChangeLog > > * combine.c (combine_simplify_rtx): Suppress replacement of > "(and (reg) (const_int bit))" with "if_then_else". That causes a regression on ia64. FAIL: gcc.target/ia64/builtin-popcount-2.c scan-assembler-not popcnt Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: [PATCH] PR fortran/78618 -- RANK() should not ICE
On Dez 01 2016, Steve Kargl wrote: > PR fortran/78618 > * gfortran.dg/char_conversion.f90: New test. That test still crashes the compiler on m68k: /daten/aranym/gcc/gcc-20161203/gcc/testsuite/gfortran.dg/char_conversion.f90:8:30: Error: Character '\u0100' in string at (1) cannot be converted into character kind 1 f951: internal compiler error: Segmentation fault 0xb40a7f crash_signal ../../gcc/toplev.c:333 0x58dd52 gfc_is_constant_expr(gfc_expr*) ../../gcc/fortran/expr.c:899 0x5feb90 resolve_fl_procedure ../../gcc/fortran/resolve.c:12013 0x5feb90 resolve_symbol ../../gcc/fortran/resolve.c:14721 0x616e73 do_traverse_symtree ../../gcc/fortran/symbol.c:3994 0x6007d4 resolve_types ../../gcc/fortran/resolve.c:15948 0x5fc3e4 gfc_resolve ../../gcc/fortran/resolve.c:16061 0x5e70b2 resolve_all_program_units ../../gcc/fortran/parse.c:5977 0x5e70b2 gfc_parse_file() ../../gcc/fortran/parse.c:6224 0x629da2 gfc_be_parse_file ../../gcc/fortran/f95-lang.c:202 Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: [Patch, Fortran, OOP] PR 42188: F03:C612. The leftmost part-name shall be the name of a data object
On Fri, Dec 02, 2016 at 04:24:20PM +0100, Janus Weil wrote: > > another simple fix for a rather old PR. This one adds a new check, in > order to provide better error messages than just "Unclassifiable > statement". > > Regtests cleanly on x86_64-linux-gnu. Ok for trunk? > OK. -- Steve
Re: [Patch, Fortran, OOP] PR 43207: [OOP] invalid (pointer) assignment to and from abstract non-polymorphic expressions
On Fri, Dec 02, 2016 at 02:37:24PM +0100, Janus Weil wrote: > > the attached patch fixes the PR in the subject line by introducing a > new check to reject invalid code. It's a slight update of an old patch > that I posted in the PR quite some time ago, using somewhat tighter > checking to avoid side effects on the testsuite. > > Regtests cleanly on x86_64-linux-gnu. Ok for trunk? > OK -- Steve
Re: [PATCH, Fortran, cosmetics] Use convenience functions and constants
On Tue, Nov 22, 2016 at 06:56:16PM +0100, Andre Vehreschild wrote: > > during more hacking on the allocatable components in derived type coarrays, I > encountered the improvable code fragments in the patch attached. > > Bootstraps and regtests ok on x86_64-linux/F23. Ok for trunk? > OK with a suitable ChangeLog entry. -- Steve
Re: [PATCH] PR fortran/78618 -- RANK() should not ICE
On Sat, Dec 03, 2016 at 05:58:02PM +0100, Andreas Schwab wrote: > On Dez 01 2016, Steve Kargl wrote: > > > PR fortran/78618 > > * gfortran.dg/char_conversion.f90: New test. > > That test still crashes the compiler on m68k: > > 0xb40a7f crash_signal > ../../gcc/toplev.c:333 > 0x58dd52 gfc_is_constant_expr(gfc_expr*) > ../../gcc/fortran/expr.c:899 > 0x5feb90 resolve_fl_procedure > ../../gcc/fortran/resolve.c:12013 Yes, we know. I've reopen the PR; see audit trail. It seems to be a used-after-freed issue, but I've been unable to track down the issue. -- Steve
Re: [PATCH, Fortran, cosmetics] Use convenience functions and constants
Hi Steve, Er, thanks for the review and sorry, but I fear I already committed the changes as part of r243021. These improvables occurred to me while hacking at: [PATCH, Fortran, accaf, v1] Add caf-API-calls to asynchronously handle allocatable components in derived type coarrays. https://gcc.gnu.org/ml/fortran/2016-11/msg00267.html so they sled in with committing those changes and got a suitable Changelog-entry while at it. Thanks again for the review though. - Andre On Sat, 3 Dec 2016 09:05:23 -0800 Steve Kargl wrote: > On Tue, Nov 22, 2016 at 06:56:16PM +0100, Andre Vehreschild wrote: > > > > during more hacking on the allocatable components in derived type coarrays, > > I encountered the improvable code fragments in the patch attached. > > > > Bootstraps and regtests ok on x86_64-linux/F23. Ok for trunk? > > > > OK with a suitable ChangeLog entry. > -- Andre Vehreschild * Email: vehre ad gmx dot de
[SPARC] Disable U constraint with LRA
As diagnosed by DaveM, there is a bad interaction between the U constraint used by the SPARC port to represent "aligned" double-word registers in 32-bit mode and LRA; more precisely, LRA doesn't play as nice as reload with it because it's not declared with define_register_constraint. Fixed by disabling the relevant alternatives in the few patterns using the constraint and replacing it with a simple r constraint. This yields a clean C testsuite in 32-bit mode. The generated code seems to be slightly better than with reload, except for one issue: LRA doesn't seem to take into account the REG_ALLOC_ORDER specified by the architecture for picking reload registers, which means that it doesn't use leaf registers in leaf functions, which in turn blocks the leaf function optimization on SPARC. We cannot switch SPARC to LRA until after this is fixed, I'm going to open an enhancement PR. Tested on SPARC/Solaris, applied on the mainline. 2016-12-03 Eric Botcazou David S. Miller * config/sparc/constraints.md (U): Adjust comment. * config/sparc/sparc.md (lra): New attribute. (enabled): For base instructions, if the lra attribute is set, return 1 if it is in keeping with TARGET_LRA. (*movdi_insn_sp32): Add lra attribute for alternatives mentioning U constraint and duplicate them with U replaced by r. (*movdf_insn_sp32): Likewise. (*mov_insn_sp32): Likewise. (*movtf_insn_sp32): Remove alternatives mentioning U constraint. -- Eric BotcazouIndex: config/sparc/constraints.md === --- config/sparc/constraints.md (revision 243172) +++ config/sparc/constraints.md (working copy) @@ -166,10 +166,10 @@ (define_memory_constraint "T" ;; example, we have a non-offsetable MEM. Reload will notice this ;; case and reload the address into a single hard register. ;; -;; The real downfall of this awkward register constraint is that it does -;; not evaluate to a true register class like a bonafide use of -;; define_register_constraint would. This currently means that we cannot -;; use LRA on Sparc, since the constraint processing of LRA really depends +;; The real downfall of this awkward register constraint is that it +;; does not evaluate to a true register class like a bonafide use of +;; define_register_constraint would. This means that we cannot use +;; it with LRA, since the constraint processing of LRA really depends ;; upon whether an extra constraint is for registers or not. It uses ;; reg_class_for_constraint, and checks it against NO_REGS. (define_constraint "U" Index: config/sparc/sparc.md === --- config/sparc/sparc.md (revision 243172) +++ config/sparc/sparc.md (working copy) @@ -254,8 +254,14 @@ (define_attr "isa" "v7,v8,v9,sparclet" (define_attr "cpu_feature" "none,fpu,fpunotv9,v9,vis,vis3,vis4" (const_string "none")) +(define_attr "lra" "none,disabled,enabled" + (const_string "none")) + (define_attr "enabled" "" - (cond [(eq_attr "cpu_feature" "none") (const_int 1) + (cond [(eq_attr "cpu_feature" "none") + (cond [(eq_attr "lra" "disabled") (symbol_ref "!TARGET_LRA") + (eq_attr "lra" "enabled") (symbol_ref "TARGET_LRA")] + (const_int 1)) (eq_attr "cpu_feature" "fpu") (symbol_ref "TARGET_FPU") (eq_attr "cpu_feature" "fpunotv9") (symbol_ref "TARGET_FPU && !TARGET_V9") (eq_attr "cpu_feature" "v9") (symbol_ref "TARGET_V9") @@ -1701,9 +1707,9 @@ (define_expand "movdi" (define_insn "*movdi_insn_sp32" [(set (match_operand:DI 0 "nonimmediate_operand" - "=T,o,T,U,o,r,r,r,?T,?*f,?*f,?o,?*e,?*e, r,?*f,?*e,?W,b,b") + "=T,o,T,T,U,r,o,r,r,r,?T,?*f,?*f,?o,?*e,?*e, r,?*f,?*e,?W,b,b") (match_operand:DI 1 "input_operand" - " J,J,U,T,r,o,i,r,*f, T, o,*f, *e, *e,?*f, r, W,*e,J,P"))] + " J,J,U,r,T,T,r,o,i,r,*f, T, o,*f, *e, *e,?*f, r, W,*e,J,P"))] "TARGET_ARCH32 && (register_operand (operands[0], DImode) || register_or_zero_operand (operands[1], DImode))" @@ -1711,6 +1717,8 @@ (define_insn "*movdi_insn_sp32" stx\t%%g0, %0 # std\t%1, %0 + std\t%1, %0 + ldd\t%1, %0 ldd\t%1, %0 # # @@ -1728,11 +1736,12 @@ (define_insn "*movdi_insn_sp32" std\t%1, %0 fzero\t%0 fone\t%0" - [(set_attr "type" "store,store,store,load,*,*,*,*,fpstore,fpload,*,*,fpmove,*,*,*,fpload,fpstore,visl,visl") - (set_attr "length" "*,2,*,*,2,2,2,2,*,*,2,2,*,2,2,2,*,*,*,*") - (set_attr "fptype" "*,*,*,*,*,*,*,*,*,*,*,*,double,*,*,*,*,*,double,double") - (set_attr "cpu_feature" "v9,*,*,*,*,*,*,*,fpu,fpu,fpu,fpu,v9,fpunotv9,vis3,vis3,fpu,fpu,vis,vis") - (set_attr "v3pipe" "*,*,*,*,*,*,*,*,*,*,*,*,*,*,*,*,*,*,true,true")]) + [(set_attr "type" "store,store,store,store,load,load,*,*,*,*,fpstore,fpload,*,*,fpmove,*,*,*,fpload,fpstore,visl,visl") + (set_attr "length" "*,2,*,*,*,*,2,2,2,2,
Re: [PATCH, Fortran, v2] Fix deallocation of nested derived typed components
> I also have addressed the ICEs with proc_pointer components. Confirmed, the patch LGTM. Thanks, Dominique
Use gen_lowpart_SUBREG consistently in emit_spill_move
The second branch of the alternative in emit_spill_move correctly uses
gen_lowpart_SUBREG to build a lowpart SUBREG, whereas the first branch uses
gen_rtx_SUBREG (..., ..., 0), which of course badly breaks on big-endian.
Tested on x86_64/Linux and SPARC/Solaris, applied on the mainline as obvious.
2016-12-03 Eric Botcazou
* lra-constraints.c (emit_spill_move): Use gen_lowpart_SUBREG in all
cases to build a lowpart SUBREG.
--
Eric BotcazouIndex: lra-constraints.c
===
--- lra-constraints.c (revision 243172)
+++ lra-constraints.c (working copy)
@@ -1109,9 +1109,9 @@ emit_spill_move (bool to_p, rtx mem_pseu
dependent macro HARD_REGNO_CALLER_SAVE_MODE. */
if (! MEM_P (val))
{
- val = gen_rtx_SUBREG (GET_MODE (mem_pseudo),
-GET_CODE (val) == SUBREG ? SUBREG_REG (val) : val,
-0);
+ val = gen_lowpart_SUBREG (GET_MODE (mem_pseudo),
+GET_CODE (val) == SUBREG
+? SUBREG_REG (val) : val);
LRA_SUBREG_P (val) = 1;
}
else
Re: [PATCH, Fortran, cosmetics] Use convenience functions and constants
On Sat, Dec 03, 2016 at 06:25:19PM +0100, Andre Vehreschild wrote: > > Er, thanks for the review and sorry, but I fear I already committed > the changes as part of r243021. These improvables occurred to me > while hacking at: > > [PATCH, Fortran, accaf, v1] Add caf-API-calls to asynchronously handle > allocatable components in derived type coarrays. > https://gcc.gnu.org/ml/fortran/2016-11/msg00267.html > > so they sled in with committing those changes and got a suitable > Changelog-entry > while at it. > > Thanks again for the review though. > No problem. I started at the bottom of my mail queue looking for unreviewed patches. I did not see one for your patch, so read through it and found no issues. -- Steve
Re: [Patch, Fortran, OOP] PR 42188: F03:C612. The leftmost part-name shall be the name of a data object
2016-12-03 18:01 GMT+01:00 Steve Kargl : > On Fri, Dec 02, 2016 at 04:24:20PM +0100, Janus Weil wrote: >> >> another simple fix for a rather old PR. This one adds a new check, in >> order to provide better error messages than just "Unclassifiable >> statement". >> >> Regtests cleanly on x86_64-linux-gnu. Ok for trunk? >> > > OK. Thanks, Steve. Committed to trunk as r243223. Cheers, Janus
Re: [Patch, Fortran, OOP] PR 43207: [OOP] invalid (pointer) assignment to and from abstract non-polymorphic expressions
2016-12-03 18:03 GMT+01:00 Steve Kargl : > On Fri, Dec 02, 2016 at 02:37:24PM +0100, Janus Weil wrote: >> >> the attached patch fixes the PR in the subject line by introducing a >> new check to reject invalid code. It's a slight update of an old patch >> that I posted in the PR quite some time ago, using somewhat tighter >> checking to avoid side effects on the testsuite. >> >> Regtests cleanly on x86_64-linux-gnu. Ok for trunk? >> > > OK Thanks, committed as r243224. Cheers, Janus
Re: [PATCH, Fortran, v2] Fix deallocation of nested derived typed components
Hi all,
@Dominique: Thanks for checking. And also for pointing out that the initial
version of the patch ICEd on some already closed PRs. The objective of those
PRs does not seem to be covered by the current testsuite. I therefore
additionally propose to add attached testcase. Ok for trunk?
Of course with appropriate Changelog-entry.
Regards,
Andre
On Sat, 3 Dec 2016 18:34:56 +0100
Dominique d'Humières wrote:
> > I also have addressed the ICEs with proc_pointer components.
>
> Confirmed, the patch LGTM.
>
> Thanks,
>
> Dominique
>
>
--
Andre Vehreschild * Email: vehre ad gmx dot de
diff --git a/gcc/testsuite/gfortran.dg/proc_ptr_comp_47.f90 b/gcc/testsuite/gfortran.dg/proc_ptr_comp_47.f90
new file mode 100644
index 000..1d52100
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/proc_ptr_comp_47.f90
@@ -0,0 +1,40 @@
+! { dg-do run }
+
+MODULE distribution_types
+ ABSTRACT INTERFACE
+ FUNCTION dist_map_blk_to_proc_func ( row, col, nrow_tot, ncol_tot, proc_grid ) RESULT( reslt )
+ INTEGER, INTENT( IN ) :: row, col, nrow_tot, ncol_tot
+ INTEGER, DIMENSION( : ), INTENT( IN ) :: proc_grid
+ INTEGER, DIMENSION( : ), ALLOCATABLE :: reslt
+ END FUNCTION dist_map_blk_to_proc_func
+ END INTERFACE
+ TYPE, PUBLIC :: dist_type
+ INTEGER, DIMENSION( : ), ALLOCATABLE :: task_coords
+ PROCEDURE( dist_map_blk_to_proc_func ), NOPASS, POINTER :: map_blk_to_proc => NULL( )
+ END TYPE dist_type
+END MODULE distribution_types
+
+MODULE sparse_matrix_types
+ USE distribution_types, ONLY : dist_type
+ TYPE, PUBLIC :: sm_type
+ TYPE( dist_type ) :: dist
+ END TYPE sm_type
+END MODULE sparse_matrix_types
+
+PROGRAM comp_proc_ptr_test
+ USE sparse_matrix_types, ONLY : sm_type
+
+ call sm_multiply_a ()
+CONTAINS
+ SUBROUTINE sm_multiply_a ( )
+INTEGER :: n_push_tot, istat
+TYPE( sm_type ), DIMENSION( : ), ALLOCATABLE :: matrices_a, matrices_b
+n_push_tot =2
+ALLOCATE( matrices_a( n_push_tot + 1 ), matrices_b( n_push_tot + 1), STAT=istat )
+if (istat /= 0) call abort()
+if (.not. allocated(matrices_a)) call abort()
+if (.not. allocated(matrices_b)) call abort()
+if (associated(matrices_a(1)%dist%map_blk_to_proc)) call abort()
+ END SUBROUTINE sm_multiply_a
+END PROGRAM comp_proc_ptr_test
+
[PATCH] libiberty: Don't update and remove did_subs field from demangler structs.
The d_info field did_subs was used for estimating the string output size. It was no longer used when the malloc-less callback interface was introduced in 2007 (svn r121305). But the field was still updated. When backtracking was introduced in 2013 (svn r205292) did_subs was also added to the d_info_checkpoint struct. But except for updating the field it was still not used. Since it is never used just stop updating the field and remove it from the two structs. libiberty/ChangeLog: * cp-demangle.h (struct d_info): Remove did_subs field. * cp-demangle.c (struct d_info_checkpoint): Likewise. (d_template_param): Don't update did_subs. (d_substitution): Likewise. (d_checkpoint): Don't assign did_subs. (d_backtrack): Likewise. (cplus_demangle_init_info): Don't initialize did_subs. --- libiberty/cp-demangle.c | 8 libiberty/cp-demangle.h | 4 2 files changed, 12 deletions(-) diff --git a/libiberty/cp-demangle.c b/libiberty/cp-demangle.c index 45663fe..c628dd6 100644 --- a/libiberty/cp-demangle.c +++ b/libiberty/cp-demangle.c @@ -317,7 +317,6 @@ struct d_info_checkpoint const char *n; int next_comp; int next_sub; - int did_subs; int expansion; }; @@ -3062,8 +3061,6 @@ d_template_param (struct d_info *di) if (param < 0) return NULL; - ++di->did_subs; - return d_make_template_param (di, param); } @@ -3815,8 +3812,6 @@ d_substitution (struct d_info *di, int prefix) if (id >= (unsigned int) di->next_sub) return NULL; - ++di->did_subs; - return di->subs[id]; } else @@ -3881,7 +3876,6 @@ d_checkpoint (struct d_info *di, struct d_info_checkpoint *checkpoint) checkpoint->n = di->n; checkpoint->next_comp = di->next_comp; checkpoint->next_sub = di->next_sub; - checkpoint->did_subs = di->did_subs; checkpoint->expansion = di->expansion; } @@ -3891,7 +3885,6 @@ d_backtrack (struct d_info *di, struct d_info_checkpoint *checkpoint) di->n = checkpoint->n; di->next_comp = checkpoint->next_comp; di->next_sub = checkpoint->next_sub; - di->did_subs = checkpoint->did_subs; di->expansion = checkpoint->expansion; } @@ -6106,7 +6099,6 @@ cplus_demangle_init_info (const char *mangled, int options, size_t len, chars in the mangled string. */ di->num_subs = len; di->next_sub = 0; - di->did_subs = 0; di->last_name = NULL; diff --git a/libiberty/cp-demangle.h b/libiberty/cp-demangle.h index 197883e..f197f99 100644 --- a/libiberty/cp-demangle.h +++ b/libiberty/cp-demangle.h @@ -112,10 +112,6 @@ struct d_info int next_sub; /* The number of available entries in the subs array. */ int num_subs; - /* The number of substitutions which we actually made from the subs - array, plus the number of template parameter references we - saw. */ - int did_subs; /* The last name we saw, for constructors and destructors. */ struct demangle_component *last_name; /* A running total of the length of large expansions from the -- 1.8.3.1
Re: [PATCH, Fortran, v2] Fix deallocation of nested derived typed components
Hi Andre, I fear the patch is causing another set of failures with -fopenmp: FAIL: libgomp.fortran/allocatable11.f90 -O0 (internal compiler error) … FAIL: libgomp.fortran/allocatable8.f90 -g -flto (test for excess errors) of the kind collect2: error: ld returned 1 exit status [Book15] f90/bug% gfc /opt/gcc/work/libgomp/testsuite/libgomp.fortran/allocatable2.f90 -fopenmp /opt/gcc/work/libgomp/testsuite/libgomp.fortran/allocatable2.f90:46:0: if (l.or.allocated (a)) call abort Error: incorrect sharing of tree nodes a.data a.data = 0B; /opt/gcc/work/libgomp/testsuite/libgomp.fortran/allocatable2.f90:46:0: internal compiler error: verify_gimple failed Dominique > Le 3 déc. 2016 à 19:51, Andre Vehreschild a écrit : > > Hi all, > > @Dominique: Thanks for checking. And also for pointing out that the initial > version of the patch ICEd on some already closed PRs. The objective of those > PRs does not seem to be covered by the current testsuite. I therefore > additionally propose to add attached testcase. Ok for trunk? > > Of course with appropriate Changelog-entry. > > Regards, > Andre
Re: [PATCH v3] Do not simplify "(and (reg) (const bit))" to if_then_else.
[ I did not see this patch before, sorry. ]
This causes the second half of PR78638.
On Thu, Dec 01, 2016 at 04:30:08PM +0100, Dominik Vogt wrote:
> --- a/gcc/combine.c
> +++ b/gcc/combine.c
> @@ -5600,6 +5600,18 @@ combine_simplify_rtx (rtx x, machine_mode op0_mode,
> int in_dest,
>&& OBJECT_P (SUBREG_REG (XEXP (x, 0)))
> {
>rtx cond, true_rtx, false_rtx;
> + unsigned HOST_WIDE_INT nz;
> +
> + /* If the operation is an AND wrapped in a SIGN_EXTEND or ZERO_EXTEND
> with
> + either operand being just a constant single bit value, do nothing since
> + IF_THEN_ELSE is likely to increase the expression's complexity. */
> + if (HWI_COMPUTABLE_MODE_P (mode)
> + && pow2p_hwi (nz = nonzero_bits (x, mode))
> + && ! ((code == SIGN_EXTEND || code == ZERO_EXTEND)
> + && GET_CODE (XEXP (x, 0)) == AND
> + && CONST_INT_P (XEXP (XEXP (x, 0), 0))
> + && UINTVAL (XEXP (XEXP (x, 0), 0)) == nz))
> + return x;
The code does not match the comment: the "!" should not be there. How
did it fix anything on s390 *with* that "!"? That does not make much
sense.
Segher
