Re: [PATCH] Improve DF use of loop-invaraint (PR46590)
On Tue, 2 Apr 2019, Richard Sandiford wrote:
> Richard Sandiford writes:
> > Richard Biener writes:
> >> After the fix to RPO VN in loop header copying DF via RTL invariant
> >> motion takes 50% of the compile-time for the second testcase in
> >> PR46590. This is caused by the DF live problem iterating over
> >> all dirty blocks for the local problem which is all blocks of
> >> the function because while loop-invariant uses df_analyze_loop
> >> it always marks all blocks of the function as dirty via
> >> df_live_set_all_dirty. One of the possible fixes is to add
> >> a df_live_set_loop_dirty () function which causes the problem
> >> to only iterate over one loop blocks.
> >>
> >> It turns out the LIVE problem is always present so we cannot
> >> remove it which in turn means we have to mark blocks possibly
> >> not visited by invaraint motion as dirty (thus the new
> >> df_live_set_all_dirty at the end of move_loop_invariants).
> >>
> >> Anyhow - I'm not really into how DF should ideally work here
> >
> > Me neither, but as discussed on IRC, here's alternative that seems
> > to give a similar speed-up.
> >
> > - df_live is already present at -O2, so we only need to add it and
> > mark all blocks dirty for -O
> >
> > - df_process_deferred_rescans should be enough to force a rescan of
> > blocks affected by moving invariants, but calling it in find_defs
> > means that we don't do any rescans for the final loop
> >
> > Still testing, but posting for comments.
> >
> > Thanks,
> > Richard
> >
> >
> > 2019-04-01 Richard Sandiford
> >
> > gcc/
> > PR rtl-optimization/46950
> > * loop-invariant.c (find_defs): Move df_remove_problem and
> > df_process_deferred_rescans to move_invariants.
> > Move df_live_add_problem and df_live_set_all_dirty calls
> > to move_invariants.
> > (move_invariants): Likewise.
> > (move_loop_invariants): Likewise, making the df_live calls
> > conditional on -O. Remove the problem again if we added it
> > locally.
> >
> > Index: gcc/loop-invariant.c
> > ===
> > --- gcc/loop-invariant.c2019-03-08 18:15:33.704751739 +
> > +++ gcc/loop-invariant.c2019-04-01 14:09:13.553206345 +
> > @@ -681,11 +681,7 @@ find_defs (struct loop *loop)
> >loop->num);
> > }
> >
> > - df_remove_problem (df_chain);
> > - df_process_deferred_rescans ();
> >df_chain_add_problem (DF_UD_CHAIN);
> > - df_live_add_problem ();
> > - df_live_set_all_dirty ();
> >df_set_flags (DF_RD_PRUNE_DEAD_DEFS);
> >df_analyze_loop (loop);
> >check_invariant_table_size ();
> > @@ -1891,6 +1887,10 @@ move_invariants (struct loop *loop)
> > GENERAL_REGS, NO_REGS, GENERAL_REGS);
> > }
> > }
> > + /* Remove the DF_UD_CHAIN problem added in find_defs before rescanning,
> > + to save a bit of compile time. */
> > + df_remove_problem (df_chain);
> > + df_process_deferred_rescans ();
> > }
> >
> > /* Initializes invariant motion data. */
> > @@ -2254,6 +2254,11 @@ move_loop_invariants (void)
> > {
> >struct loop *loop;
> >
> > + if (optimize == 1)
> > +{
> > + df_live_add_problem ();
> > + df_live_set_all_dirty ();
> > +}
>
> Gah, this is a mess. The patch as posted regresses gcc.dg/pr65779.c,
> which is an -O2 -fcompare-debug test. This is because the DF_INSN_LUIDs
> are out-of-date on entry to the pass, and without the df_live_set_all_dirty,
> they stay out-of-date after a full df_analyze, even though the comment
> above luid suggests otherwise:
>
> /* The logical uid of the insn in the basic block. This is valid
> after any call to df_analyze but may rot after insns are added,
> deleted or moved. */
> int luid;
>
> This affects this condition in can_move_invariant_reg:
>
> /* Don't move if a use is not dominated by def in insn. */
> if (use_bb == bb && DF_INSN_LUID (insn) >= DF_INSN_LUID (use_insn))
> return false;
>
> After hacking up some extra testing, it seems that it's often the
> case that DF_INSN_LUID is out-of-date even after df_analyze.
> E.g. the LUIDs are not in-oder after sched1 and the df_analyze
> in early-remat.c doesn't fix them up. There are also cases in
> other passes.
>
> Yet it seems several passes (e.g. combine) do rely on valid LUIDs,
> without doing anything obvious to ensure that they're valid.
> So whether LUIDs are valid after the initial df_analyze seems
> to be a pass-specific property (whether it was meant to be or not).
>
> In gcc.dg/pr65779.c, the insn with an invalid LUID is a debug insn
> that's actually *generated* by df_analyze (in regcprop, as a side-effect
> of DF_LR_RUN_DCE). AFAIK, LUIDs for debug insns should be just as
> reliable as LUIDs for ordinary insns, but we're less likely to
> rescan the block and recompute the luids due to:
>
> if (!DEBUG_INSN_P (insn))
> df_set_bb_dirty (bb);
>
> in df_insn_resca
[PATCH] Add missing libsanitizer extra patch (r259664) (PR sanitizer/89941).
Hi.
The patch is about re-application of what we've already had
on top trunk libsanitizer. I'll then include the patch in
libsanitizer/LOCAL_PATCHES.
Ready for trunk?
Thanks,
Martin
libsanitizer/ChangeLog:
2019-04-03 Martin Liska
PR sanitizer/89941
* sanitizer_common/sanitizer_platform_limits_linux.cc (defined):
Reapply patch from r259664.
* sanitizer_common/sanitizer_platform_limits_posix.h (defined):
Likewise.
---
.../sanitizer_common/sanitizer_platform_limits_linux.cc| 7 +--
.../sanitizer_common/sanitizer_platform_limits_posix.h | 2 +-
2 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/libsanitizer/sanitizer_common/sanitizer_platform_limits_linux.cc b/libsanitizer/sanitizer_common/sanitizer_platform_limits_linux.cc
index 23a014823c4..3a906538129 100644
--- a/libsanitizer/sanitizer_common/sanitizer_platform_limits_linux.cc
+++ b/libsanitizer/sanitizer_common/sanitizer_platform_limits_linux.cc
@@ -25,9 +25,12 @@
// With old kernels (and even new kernels on powerpc) asm/stat.h uses types that
// are not defined anywhere in userspace headers. Fake them. This seems to work
-// fine with newer headers, too.
+// fine with newer headers, too. Beware that with , struct stat
+// takes the form of struct stat64 on 32-bit platforms if _FILE_OFFSET_BITS=64.
+// Also, for some platforms (e.g. mips) there are additional members in the
+// struct stat:s.
#include
-#if defined(__x86_64__) || defined(__mips__)
+#if defined(__x86_64__)
#include
#else
#define ino_t __kernel_ino_t
diff --git a/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h b/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h
index 91f38918f35..73af92af1e8 100644
--- a/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h
+++ b/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h
@@ -87,7 +87,7 @@ namespace __sanitizer {
#elif defined(__mips__)
const unsigned struct_kernel_stat_sz =
SANITIZER_ANDROID ? FIRST_32_SECOND_64(104, 128) :
- FIRST_32_SECOND_64(160, 216);
+ FIRST_32_SECOND_64(144, 216);
const unsigned struct_kernel_stat64_sz = 104;
#elif defined(__s390__) && !defined(__s390x__)
const unsigned struct_kernel_stat_sz = 64;
Re: [PATCH] Fix PR71598, aliasing between enums and compatible types
Hi! On Fri, 29 Mar 2019 at 20:02, Jeff Law wrote: > > On 3/29/19 9:09 AM, Jason Merrill wrote: > > On Fri, Mar 29, 2019 at 4:48 AM Richard Biener wrote: > >> > >> On Thu, 28 Mar 2019, Jason Merrill wrote: > >> > >>> On 3/26/19 4:40 AM, Richard Biener wrote: > On Mon, 18 Mar 2019, Richard Biener wrote: > > > On Fri, 15 Mar 2019, Jason Merrill wrote: > > > >> On 3/15/19 9:33 AM, Richard Biener wrote: > >>> > >>> The following is an attempt to fix PR71598 where C (and C++?) have > >>> an implementation-defined compatible integer type for each enum > >>> and the TBAA rules mandate that accesses using a compatible type > >>> are allowed. > >> > >> This does not apply to C++; an enum does not alias its underlying type. > > > > Thus the following different patch, introducing c_get_alias_set and > > only doing the special handling for C family frontends (I assume > > that at least ObjC is also affected). > > > > Bootstrap & regtest running on x86_64-unknown-linux-gnu, OK? > > Ping. Also consider the additional testcase below to be added. > > Richard. > > 2019-03-18 Richard Biener > > PR c/71598 > * gimple.c: Include langhooks.h. > (gimple_get_alias_set): Treat enumeral types as the underlying > integer type. > >>> > >>> Won't this affect all languages? > >> > >> It affects all languages during the LTO optimization phase, yes. > >> There's unfortunately no way around that at the moment. > > > > Ah, well. Looks good to me, then. > Likewise. And with Joseph largely offline right now, that's going to > have to be sufficient :-) > I've noticed minor new errors at link time on arm with the 2 new testcases. pr71598-1.c complains on arm-none-eabi because arm-none-eabi/bin/ld: warning: /ccu5w26t.o uses 32-bit enums yet the output is to use variable-size enums; use of enum values across objects may fail conversely, pr71598-2.c complains on arm-none-linux-gnueabi* because: arm-none-linux-gnueabi/bin/ld: warning: /ccl5OUKi.o uses variable-size enums yet the output is to use 32-bit enums; use of enum values across objects may fail In both cases this is because crt0.o is built with the opposite (default) short-enum option than the testcase, so the linker sees a mismatch between crt0.o and pr71598-X.o. Shall I add target-dependent dg-warning directives in the testcases, or is there a better way? Thanks, Christophe > jeff
Re: [PATCH] Fix PR71598, aliasing between enums and compatible types
On Wed, 3 Apr 2019, Christophe Lyon wrote: > Hi! > > On Fri, 29 Mar 2019 at 20:02, Jeff Law wrote: > > > > On 3/29/19 9:09 AM, Jason Merrill wrote: > > > On Fri, Mar 29, 2019 at 4:48 AM Richard Biener wrote: > > >> > > >> On Thu, 28 Mar 2019, Jason Merrill wrote: > > >> > > >>> On 3/26/19 4:40 AM, Richard Biener wrote: > > On Mon, 18 Mar 2019, Richard Biener wrote: > > > > > On Fri, 15 Mar 2019, Jason Merrill wrote: > > > > > >> On 3/15/19 9:33 AM, Richard Biener wrote: > > >>> > > >>> The following is an attempt to fix PR71598 where C (and C++?) have > > >>> an implementation-defined compatible integer type for each enum > > >>> and the TBAA rules mandate that accesses using a compatible type > > >>> are allowed. > > >> > > >> This does not apply to C++; an enum does not alias its underlying > > >> type. > > > > > > Thus the following different patch, introducing c_get_alias_set and > > > only doing the special handling for C family frontends (I assume > > > that at least ObjC is also affected). > > > > > > Bootstrap & regtest running on x86_64-unknown-linux-gnu, OK? > > > > Ping. Also consider the additional testcase below to be added. > > > > Richard. > > > > 2019-03-18 Richard Biener > > > > PR c/71598 > > * gimple.c: Include langhooks.h. > > (gimple_get_alias_set): Treat enumeral types as the underlying > > integer type. > > >>> > > >>> Won't this affect all languages? > > >> > > >> It affects all languages during the LTO optimization phase, yes. > > >> There's unfortunately no way around that at the moment. > > > > > > Ah, well. Looks good to me, then. > > Likewise. And with Joseph largely offline right now, that's going to > > have to be sufficient :-) > > > > > I've noticed minor new errors at link time on arm with the 2 new testcases. > pr71598-1.c complains on arm-none-eabi because > arm-none-eabi/bin/ld: warning: /ccu5w26t.o uses 32-bit enums yet the > output is to use variable-size enums; use of enum values across > objects may fail > > conversely, pr71598-2.c complains on arm-none-linux-gnueabi* because: > arm-none-linux-gnueabi/bin/ld: warning: /ccl5OUKi.o uses variable-size > enums yet the output is to use 32-bit enums; use of enum values across > objects may fail > > In both cases this is because crt0.o is built with the opposite > (default) short-enum option than the testcase, so the linker sees a > mismatch between crt0.o and pr71598-X.o. > > Shall I add target-dependent dg-warning directives in the testcases, > or is there a better way? Maybe dg-skip the test for target_short_enums which seems to exist? Can you try if that works and if so, commit the fix? Thanks, Richard.
Re: [PATCH] Updated patch for PR84101
On Mon, 1 Apr 2019, Richard Sandiford wrote:
> Richard Biener writes:
> > This is an update from last years attempt to tame down vectorization
> > when it runs in to ABI inefficiencies at function return. I've
> > updated the patch to look for multi-reg returns instead of
> > !vector ones (due to word_mode vectorization) and handle a bit
> > more returns, esp. the common pattern of
> >
> > ret = vector;
> > D.1234 = ret;
> > ret = {CLOBBER};
> > return D.1234;
> >
> > Bootstrapped and tested on x86_64-unknown-linux-gnu, OK?
> >
> > I know this isn't the ultimate solution but we keep getting
> > duplicates of the PR.
> >
> > Richard.
> >
> > 2019-03-28 Richard Biener
> >
> > PR tree-optimization/84101
> > * tree-vect-stmts.c: Include explow.h for hard_function_value,
> > regs.h for hard_regno_nregs.
> > (cfun_returns): New helper.
> > (vect_model_store_cost): When vectorizing a store to a decl
> > we return and the function ABI returns in a multi-reg location
> > account for the possible spilling that will happen.
> >
> > * gcc.target/i386/pr84101.c: New testcase.
> >
> > Index: gcc/tree-vect-stmts.c
> > ===
> > --- gcc/tree-vect-stmts.c (revision 269987)
> > +++ gcc/tree-vect-stmts.c (working copy)
> > @@ -43,6 +43,7 @@ along with GCC; see the file COPYING3.
> > #include "tree-cfg.h"
> > #include "tree-ssa-loop-manip.h"
> > #include "cfgloop.h"
> > +#include "explow.h"
> > #include "tree-ssa-loop.h"
> > #include "tree-scalar-evolution.h"
> > #include "tree-vectorizer.h"
> > @@ -52,6 +53,7 @@ along with GCC; see the file COPYING3.
> > #include "vec-perm-indices.h"
> > #include "tree-ssa-loop-niter.h"
> > #include "gimple-fold.h"
> > +#include "regs.h"
> >
> > /* For lang_hooks.types.type_for_mode. */
> > #include "langhooks.h"
> > @@ -948,6 +950,37 @@ vect_model_promotion_demotion_cost (stmt
> > "prologue_cost = %d .\n", inside_cost, prologue_cost);
> > }
> >
> > +/* Returns true if the current function returns DECL. */
> > +
> > +static bool
> > +cfun_returns (tree decl)
> > +{
> > + edge_iterator ei;
> > + edge e;
> > + FOR_EACH_EDGE (e, ei, EXIT_BLOCK_PTR_FOR_FN (cfun)->preds)
> > +{
> > + greturn *ret = safe_dyn_cast (last_stmt (e->src));
> > + if (!ret)
> > + continue;
> > + if (gimple_return_retval (ret) == decl)
> > + return true;
> > + /* We often end up with an aggregate copy to the result decl,
> > + handle that case as well. First skip intermediate clobbers
> > +though. */
> > + gimple *def = ret;
> > + do
> > + {
> > + def = SSA_NAME_DEF_STMT (gimple_vuse (def));
> > + }
> > + while (gimple_clobber_p (def));
> > + if (is_a (def)
> > + && gimple_assign_lhs (def) == gimple_return_retval (ret)
> > + && gimple_assign_rhs1 (def) == decl)
> > + return true;
> > +}
> > + return false;
> > +}
> > +
> > /* Function vect_model_store_cost
> >
> > Models cost for stores. In the case of grouped accesses, one access
> > @@ -1032,6 +1065,37 @@ vect_model_store_cost (stmt_vec_info stm
> >vec_to_scalar, stmt_info, 0, vect_body);
> > }
> >
> > + /* When vectorizing a store into the function result assign
> > + a penalty if the function returns in a multi-register location.
> > + In this case we assume we'll end up with having to spill the
> > + vector result and do piecewise loads. */
> > + tree base = get_base_address (STMT_VINFO_DATA_REF (stmt_info)->ref);
> > + if (base
> > + && (TREE_CODE (base) == RESULT_DECL
> > + || (DECL_P (base) && cfun_returns (base)))
> > + && !aggregate_value_p (base, cfun->decl))
> > +{
> > + rtx reg = hard_function_value (TREE_TYPE (base), cfun->decl, 0, 1);
> > + /* ??? Handle PARALLEL in some way. */
> > + if (REG_P (reg))
> > + {
> > + int nregs = hard_regno_nregs (REGNO (reg), GET_MODE (reg));
> > + /* Assume that a reg-reg move is possible and cheap,
> > +do not account for vector to gp register move cost. */
> > + if (nregs > 1)
>
> Looks OK to me FWIW, but maybe it would be worth having a check like:
>
> targetm.secondary_memory_needed (TYPE_MODE (vectype), ALL_REGS,
>REGNO_REG_CLASS (REGNO (reg)))
>
> as well as the above, so that we don't accidentally penalise values
> that are returned in multiple vector registers. Looks like the i386.c
> definition will return true in the cases that matter.
I wonder if what this hook returns makes sense if you feed it modes
with different sizes? Say for the testcase V2DImode and
the general regs class (DImode). No "direct" moves exist because the
result doesn't fit anyway so I wonder about the semantic of
secondary_memory_needed here. Wouldn't it be more appropriate to
specify the correct register class instead of ALL_REGS here a
[PATCH] Define std::hash specializations for C++17 PMR strings
These hash specializations should have been added when the pmr::string
and related typedefs were added.
* include/std/string (__hash_string_base): New class template defining
operator() for hashing strings.
(hash, hash, hash)
(hash, hash): Define for C++17.
* testsuite/21_strings/basic_string/hash/hash.cc: New test.
* testsuite/21_strings/basic_string/hash/hash_char8_t.cc: New test.
Tested powerpc64le-linux, committed to trunk.
commit ac005dda6dc17eb46729a64d59dc626c246ab944
Author: Jonathan Wakely
Date: Wed Apr 3 10:14:28 2019 +0100
Define std::hash specializations for C++17 PMR strings
These hash specializations should have been added when the pmr::string
and related typedefs were added.
* include/std/string (__hash_string_base): New class template defining
operator() for hashing strings.
(hash, hash, hash)
(hash, hash): Define for C++17.
* testsuite/21_strings/basic_string/hash/hash.cc: New test.
* testsuite/21_strings/basic_string/hash/hash_char8_t.cc: New test.
diff --git a/libstdc++-v3/include/std/string b/libstdc++-v3/include/std/string
index 100c6c84ef6..6ccc06f337a 100644
--- a/libstdc++-v3/include/std/string
+++ b/libstdc++-v3/include/std/string
@@ -74,6 +74,41 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
using wstring = basic_string;
#endif
} // namespace pmr
+
+ template
+struct __hash_string_base
+: public __hash_base
+{
+ size_t
+ operator()(const _Str& __s) const noexcept
+ { return hash>{}(__s); }
+};
+
+ template<>
+struct hash
+: public __hash_string_base
+{ };
+#ifdef _GLIBCXX_USE_CHAR8_T
+ template<>
+struct hash
+: public __hash_string_base
+{ };
+#endif
+ template<>
+struct hash
+: public __hash_string_base
+{ };
+ template<>
+struct hash
+: public __hash_string_base
+{ };
+#ifdef _GLIBCXX_USE_WCHAR_T
+ template<>
+struct hash
+: public __hash_string_base
+{ };
+#endif
+
_GLIBCXX_END_NAMESPACE_VERSION
} // namespace std
#endif // C++17
diff --git a/libstdc++-v3/testsuite/21_strings/basic_string/hash/hash.cc b/libstdc++-v3/testsuite/21_strings/basic_string/hash/hash.cc
new file mode 100644
index 000..9bdf9bd41ab
--- /dev/null
+++ b/libstdc++-v3/testsuite/21_strings/basic_string/hash/hash.cc
@@ -0,0 +1,57 @@
+// Copyright (C) 2019 Free Software Foundation, Inc.
+//
+// This file is part of the GNU ISO C++ Library. This library is free
+// software; you can redistribute it and/or modify it under the
+// terms of the GNU General Public License as published by the
+// Free Software Foundation; either version 3, or (at your option)
+// any later version.
+
+// This library is distributed in the hope that it will be useful,
+// but WITHOUT ANY WARRANTY; without even the implied warranty of
+// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+// GNU General Public License for more details.
+
+// You should have received a copy of the GNU General Public License along
+// with this library; see the file COPYING3. If not see
+//
[PATCH] PR libstdc++/85184 remove debug assertions from std::variant
The __glibcxx_assert macro should be used to check preconditions that
users must meet, not to check postconditions that the implementation
must meet. We have tests to verify std::variant meets its
postconditions, users shouldn't pay for those checks at runtime.
PR libstdc++/85184
* include/std/variant (_Copy_assign_base, _Move_assign_base, variant):
Remove assertions.
(variant::emplace<_Tp>): Remove result of emplace directly.
Tested powerpc64le-linux, committed to trunk.
commit b54865992e3553dbf5aa93726996da3d3d891806
Author: Jonathan Wakely
Date: Wed Apr 3 10:28:33 2019 +0100
PR libstdc++/85184 remove debug assertions from std::variant
The __glibcxx_assert macro should be used to check preconditions that
users must meet, not to check postconditions that the implementation
must meet. We have tests to verify std::variant meets its
postconditions, users shouldn't pay for those checks at runtime.
PR libstdc++/85184
* include/std/variant (_Copy_assign_base, _Move_assign_base,
variant):
Remove assertions.
(variant::emplace<_Tp>): Remove result of emplace directly.
diff --git a/libstdc++-v3/include/std/variant b/libstdc++-v3/include/std/variant
index a7cc2065073..a21ef3005cf 100644
--- a/libstdc++-v3/include/std/variant
+++ b/libstdc++-v3/include/std/variant
@@ -612,7 +612,6 @@ namespace __variant
this->_M_reset();
return {};
}, __variant_cast<_Types...>(__rhs));
- __glibcxx_assert(this->_M_index == __rhs._M_index);
return *this;
}
@@ -670,7 +669,6 @@ namespace __variant
this->_M_reset();
return {};
}, __variant_cast<_Types...>(__rhs));
- __glibcxx_assert(this->_M_index == __rhs._M_index);
return *this;
}
@@ -1245,7 +1243,7 @@ namespace __variant
noexcept(is_nothrow_constructible_v<__accepted_type<_Tp&&>, _Tp&&>)
: variant(in_place_index<__accepted_index<_Tp&&>>,
std::forward<_Tp>(__t))
- { __glibcxx_assert(holds_alternative<__accepted_type<_Tp&&>>(*this)); }
+ { }
template
@@ -1254,7 +1252,7 @@ namespace __variant
variant(in_place_type_t<_Tp>, _Args&&... __args)
: variant(in_place_index<__index_of<_Tp>>,
std::forward<_Args>(__args)...)
- { __glibcxx_assert(holds_alternative<_Tp>(*this)); }
+ { }
template
@@ -1265,7 +1263,7 @@ namespace __variant
_Args&&... __args)
: variant(in_place_index<__index_of<_Tp>>, __il,
std::forward<_Args>(__args)...)
- { __glibcxx_assert(holds_alternative<_Tp>(*this)); }
+ { }
template, _Args&&... __args)
: _Base(in_place_index<_Np>, std::forward<_Args>(__args)...),
_Default_ctor_enabler(_Enable_default_constructor_tag{})
- { __glibcxx_assert(index() == _Np); }
+ { }
template,
@@ -1284,7 +1282,7 @@ namespace __variant
_Args&&... __args)
: _Base(in_place_index<_Np>, __il, std::forward<_Args>(__args)...),
_Default_ctor_enabler(_Enable_default_constructor_tag{})
- { __glibcxx_assert(index() == _Np); }
+ { }
template
enable_if_t<__exactly_once<__accepted_type<_Tp&&>>
@@ -1300,7 +1298,6 @@ namespace __variant
std::get<__index>(*this) = std::forward<_Tp>(__rhs);
else
this->emplace<__index>(std::forward<_Tp>(__rhs));
- __glibcxx_assert(holds_alternative<__accepted_type<_Tp&&>>(*this));
return *this;
}
@@ -1309,10 +1306,8 @@ namespace __variant
_Tp&>
emplace(_Args&&... __args)
{
- auto& ret =
- this->emplace<__index_of<_Tp>>(std::forward<_Args>(__args)...);
- __glibcxx_assert(holds_alternative<_Tp>(*this));
- return ret;
+ constexpr size_t __index = __index_of<_Tp>;
+ return this->emplace<__index>(std::forward<_Args>(__args)...);
}
template
@@ -1321,11 +1316,8 @@ namespace __variant
_Tp&>
emplace(initializer_list<_Up> __il, _Args&&... __args)
{
- auto& ret =
- this->emplace<__index_of<_Tp>>(__il,
- std::forward<_Args>(__args)...);
- __glibcxx_assert(holds_alternative<_Tp>(*this));
- return ret;
+ constexpr size_t __index = __index_of<_Tp>;
+ return this->emplace<__index>(__il, std::forward<_Args>(__args)...);
}
template
@@ -1363,7 +1355,6 @@ namespace __variant
this->_M_index = variant_npos;
__throw_exception_again;
}
- __glibcxx_assert(index() == _Np);
return std::get<_Np>(*this);
}
@@ -1399,7 +1390,6 @@ namespace __variant
this->_M_index = variant_npos;
__throw_exception_again;
}
Re: [PATCH] [ARC] PR 88409: miscompilation due to missing cc clobber in longlong.h macros
Pushed, thank you for your contribution,
Claudiu
On Tue, Apr 2, 2019 at 9:27 PM Vineet Gupta wrote:
>
> simple test such as below was failing.
>
> | void main(int argc, char *argv[])
> | {
> |size_t total_time = 115424; // expected 115.424
> |double secs = (double)total_time/(double)1000;
> |printf("%s %d %lf\n", "secs", total_time, secs); // prints 113.504
> |printf("%d\n", (size_t)secs);
> | }
>
> The printf eventually called into glibc stdlib/divrem.c:__mpn_divrem()
> which uses the __arc__ specific inline asm macros from longlong.h which
> were causing miscompilation.
>
> include/
> 2019-03-28 Vineet Gupta
>
> PR 89877
>
> * longlong.h [__arc__] (add_ss): Add cc clobber
> (sub_ddmmss): Likewise.
>
> Signed-off-by: Vineet Gupta
> ---
> include/ChangeLog | 7 +++
> include/longlong.h | 6 --
> 2 files changed, 11 insertions(+), 2 deletions(-)
>
> diff --git a/include/ChangeLog b/include/ChangeLog
> index be08141deeb9..96d967d10a52 100644
> --- a/include/ChangeLog
> +++ b/include/ChangeLog
> @@ -1,3 +1,10 @@
> +2019-03-28 Vineet Gupta
> +
> + PR 89877
> +
> + * longlong.h [__arc__] (add_ss): Add cc clobber
> + (sub_ddmmss): Likewise.
> +
> 2019-02-11 Philippe Waroquiers
>
> * splay-tree.h (splay_tree_delete_key_fn): Update comment.
> diff --git a/include/longlong.h b/include/longlong.h
> index 3dd8dc3aa80c..1f0ce4204255 100644
> --- a/include/longlong.h
> +++ b/include/longlong.h
> @@ -199,7 +199,8 @@ extern UDItype __udiv_qrnnd (UDItype *, UDItype, UDItype,
> UDItype);
>: "%r" ((USItype) (ah)), \
> "rICal" ((USItype) (bh)), \
> "%r" ((USItype) (al)), \
> -"rICal" ((USItype) (bl)))
> +"rICal" ((USItype) (bl)) \
> + : "cc")
> #define sub_ddmmss(sh, sl, ah, al, bh, bl) \
>__asm__ ("sub.f %1, %4, %5\n\tsbc %0, %2, %3" \
>: "=r" ((USItype) (sh)), \
> @@ -207,7 +208,8 @@ extern UDItype __udiv_qrnnd (UDItype *, UDItype, UDItype,
> UDItype);
>: "r" ((USItype) (ah)), \
> "rICal" ((USItype) (bh)), \
> "r" ((USItype) (al)), \
> -"rICal" ((USItype) (bl)))
> +"rICal" ((USItype) (bl)) \
> + : "cc")
>
> #define __umulsidi3(u,v) ((UDItype)(USItype)u*(USItype)v)
> #ifdef __ARC_NORM__
> --
> 2.7.4
>
Re: [PATCH, GCC, DOCS, AArch64] Add missing documenation for mbranch-protection
Hi Sandra
On 02/04/2019 16:32, Sandra Loosemore wrote:
> On 4/2/19 6:45 AM, Sudakshina Das wrote:
>> Hi
>>
>> This patch add the missing documentation bits for -mbranch-protection in
>> both extend.texi and invoke.texi.
>>
>> Is this ok for trunk?
>>
>> diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
>> index
>> ef7adb6a9c0fe1abd769e237fd8d0ce4c614aef8..7e1c28182138aeba163e50f5b7ed60812c1dfe27
>>
>> 100644
>> --- a/gcc/doc/extend.texi
>> +++ b/gcc/doc/extend.texi
>> @@ -3925,7 +3925,15 @@ same as for the @option{-mcpu=} command-line
>> option.
>> @cindex @code{sign-return-address} function attribute, AArch64
>> Select the function scope on which return address signing will be
>> applied. The
>> behavior and permissible arguments are the same as for the
>> command-line option
>> -@option{-msign-return-address=}. The default value is @code{none}.
>> +@option{-msign-return-address=}. The default value is @code{none}.
>> This
>> +attribute is @code{deprecated}. The @code{branch-protection}
>> attribute should
>> +be used instead.
>
> s/@code{deprecated}/deprecated/
>
> The patch is OK with that tweak.
Thanks. I have made the change and committed as r270119.
Sudi
>
> -Sandra
Re: [PATCH] PR libstdc++/85184 remove debug assertions from std::variant
On Wed, 3 Apr 2019 at 12:48, Jonathan Wakely wrote: > > The __glibcxx_assert macro should be used to check preconditions that > users must meet, not to check postconditions that the implementation > must meet. We have tests to verify std::variant meets its > postconditions, users shouldn't pay for those checks at runtime. > > PR libstdc++/85184 > * include/std/variant (_Copy_assign_base, _Move_assign_base, variant): > Remove assertions. > (variant::emplace<_Tp>): Remove result of emplace directly. > > Tested powerpc64le-linux, committed to trunk. The latter changelog entry should say "Return resulf of emplace directly", not "Remove result...".
Re: [PATCH] PR libstdc++/85184 remove debug assertions from std::variant
On Wed, 3 Apr 2019 at 13:04, Ville Voutilainen wrote: > > On Wed, 3 Apr 2019 at 12:48, Jonathan Wakely wrote: > > > > The __glibcxx_assert macro should be used to check preconditions that > > users must meet, not to check postconditions that the implementation > > must meet. We have tests to verify std::variant meets its > > postconditions, users shouldn't pay for those checks at runtime. > > > > PR libstdc++/85184 > > * include/std/variant (_Copy_assign_base, _Move_assign_base, > > variant): > > Remove assertions. > > (variant::emplace<_Tp>): Remove result of emplace directly. > > > > Tested powerpc64le-linux, committed to trunk. > > The latter changelog entry should say "Return resulf of emplace > directly", not "Remove result...". And yeah, *result*, dunno how that f came into existence instead of a t. Read it with the right font so that a ligature hides it. :P
Re: [PATCH] PR libstdc++/85184 remove debug assertions from std::variant
On Wed, 3 Apr 2019 at 11:04, Ville Voutilainen wrote: > > On Wed, 3 Apr 2019 at 12:48, Jonathan Wakely wrote: > > > > The __glibcxx_assert macro should be used to check preconditions that > > users must meet, not to check postconditions that the implementation > > must meet. We have tests to verify std::variant meets its > > postconditions, users shouldn't pay for those checks at runtime. > > > > PR libstdc++/85184 > > * include/std/variant (_Copy_assign_base, _Move_assign_base, > > variant): > > Remove assertions. > > (variant::emplace<_Tp>): Remove result of emplace directly. > > > > Tested powerpc64le-linux, committed to trunk. > > The latter changelog entry should say "Return resulf of emplace > directly", not "Remove result...". Oops! I'll fix that, thanks.
Re: [PATCH] [ARC] Restore blink first when optimizing for speed.
Great, thanks!
Claudiu
On Wed, Apr 3, 2019 at 2:50 AM Andrew Burgess
wrote:
>
> * Claudiu Zissulescu [2019-03-25 11:56:49 +0100]:
>
> > Hi,
> >
> > When not optimizing for size, we can restore first blink, hence the return
> > instruction will be executed faster.
> >
> > OK to apply?
> > Claudiu
> >
> > gcc/
> > -xx-xx Claudiu Zissulescu
> >
> > * config/arc/arc.c (GMASK_LEN): Define.
> > (arc_restore_callee_saves): Restore first blink when
> > !optimize_size.
>
>
> This looks fine.
>
> Thanks,
> Andrew
>
> > ---
> > gcc/config/arc/arc.c | 37 +++--
> > 1 file changed, 35 insertions(+), 2 deletions(-)
> >
> > diff --git a/gcc/config/arc/arc.c b/gcc/config/arc/arc.c
> > index de2c8d5df9c..9a6920a709f 100644
> > --- a/gcc/config/arc/arc.c
> > +++ b/gcc/config/arc/arc.c
> > @@ -2545,6 +2545,9 @@ struct GTY (()) arc_frame_info
> >bool save_return_addr;
> > };
> >
> > +/* GMASK bit length -1. */
> > +#define GMASK_LEN 31
> > +
> > /* Defining data structures for per-function information. */
> >
> > typedef struct GTY (()) machine_function
> > @@ -3087,6 +3090,8 @@ arc_restore_callee_saves (unsigned int gmask,
> > {
> >rtx reg;
> >int frame_deallocated = 0;
> > + HOST_WIDE_INT offs = cfun->machine->frame_info.reg_size;
> > + bool early_blink_restore;
> >
> >/* Emit mov fp,sp. */
> >if (arc_frame_pointer_needed () && offset)
> > @@ -3112,9 +3117,21 @@ arc_restore_callee_saves (unsigned int gmask,
> >offset = 0;
> > }
> >
> > + /* When we do not optimize for size, restore first blink. */
> > + early_blink_restore = restore_blink && !optimize_size && offs;
> > + if (early_blink_restore)
> > +{
> > + rtx addr = plus_constant (Pmode, stack_pointer_rtx, offs);
> > + reg = gen_rtx_REG (Pmode, RETURN_ADDR_REGNUM);
> > + rtx insn = frame_move_inc (reg, gen_frame_mem (Pmode, addr),
> > + stack_pointer_rtx, NULL_RTX);
> > + add_reg_note (insn, REG_CFA_RESTORE, reg);
> > + restore_blink = false;
> > +}
> > +
> >/* N.B. FRAME_POINTER_MASK and RETURN_ADDR_MASK are cleared in gmask. */
> >if (gmask)
> > -for (int i = 0; i <= 31; i++)
> > +for (int i = 0; i <= GMASK_LEN; i++)
> >{
> > machine_mode restore_mode = SImode;
> >
> > @@ -3127,7 +3144,23 @@ arc_restore_callee_saves (unsigned int gmask,
> > continue;
> >
> > reg = gen_rtx_REG (restore_mode, i);
> > - frame_deallocated += frame_restore_reg (reg, 0);
> > + offs = 0;
> > + switch (restore_mode)
> > + {
> > + case E_DImode:
> > + if ((GMASK_LEN - __builtin_clz (gmask)) == (i + 1)
> > + && early_blink_restore)
> > + offs = 4;
> > + break;
> > + case E_SImode:
> > + if ((GMASK_LEN - __builtin_clz (gmask)) == i
> > + && early_blink_restore)
> > + offs = 4;
> > + break;
> > + default:
> > + offs = 0;
> > + }
> > + frame_deallocated += frame_restore_reg (reg, offs);
> > offset = 0;
> >
> > if (restore_mode == DImode)
> > --
> > 2.20.1
> >
[PATCH] Remove usage of apostrophes in error and warning messages (PR translation/89935).
Hi.
The patch addresses wrong usage of apostrophes in error and warning
messages. It's follow up of what I did couple of weeks ago.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed?
Thanks,
Martin
contrib/ChangeLog:
2019-04-03 Martin Liska
PR translation/89935
* check-internal-format-escaping.py: Properly detect wrong
apostrophes.
gcc/ChangeLog:
2019-04-03 Martin Liska
PR translation/89935
* collect-utils.c (collect_execute): Use %< and %>, or %qs in
order to wrap keywords or arguments.
* collect2.c (main): Likewise.
(scan_prog_file): Likewise.
(scan_libraries): Likewise.
* common/config/riscv/riscv-common.c
(riscv_subset_list::parsing_subset_version): Likewise.
(riscv_subset_list::parse_std_ext): Likewise.
* config/aarch64/aarch64.c (aarch64_override_options_internal):
Likewise.
* config/arm/arm.c (arm_option_override): Likewise.
* config/cris/cris.c (cris_print_operand): Likewise.
* config/darwin-c.c (darwin_pragma_options): Likewise.
(darwin_pragma_unused): Likewise.
(darwin_pragma_ms_struct): Likewise.
* config/ft32/ft32.c (ft32_print_operand): Likewise.
* config/i386/i386.c (print_reg): Likewise.
(ix86_print_operand): Likewise.
* config/i386/xm-djgpp.h: Likewise.
* config/iq2000/iq2000.c (iq2000_print_operand): Likewise.
* config/m32c/m32c.c (m32c_option_override): Likewise.
* config/msp430/msp430.c (msp430_option_override): Likewise.
* config/nds32/nds32.c (nds32_option_override): Likewise.
* config/nvptx/mkoffload.c (main): Likewise.
* config/rx/rx.c (rx_print_operand): Likewise.
(valid_psw_flag): Likewise.
* config/vms/vms-c.c (vms_pragma_member_alignment): Likewise.
(vms_pragma_nomember_alignment): Likewise.
(vms_pragma_extern_model): Likewise.
* lto-wrapper.c (compile_offload_image): Likewise.
* omp-offload.c (oacc_parse_default_dims): Likewise.
* symtab.c (symtab_node::verify_base): Likewise.
* tlink.c (recompile_files): Likewise.
(start_tweaking): Likewise.
* tree-profile.c (parse_profile_filter): Likewise.
gcc/objc/ChangeLog:
2019-04-03 Martin Liska
* objc-act.c (objc_add_property_declaration): Use %< and %>, or %qs in
order to wrap keywords or arguments.
(objc_add_synthesize_declaration_for_property): Likewise.
---
contrib/check-internal-format-escaping.py | 2 +-
gcc/collect-utils.c | 2 +-
gcc/collect2.c| 10 +-
gcc/common/config/riscv/riscv-common.c| 12 ++--
gcc/config/aarch64/aarch64.c | 4 ++--
gcc/config/arm/arm.c | 2 +-
gcc/config/cris/cris.c| 2 +-
gcc/config/darwin-c.c | 24 +++
gcc/config/ft32/ft32.c| 2 +-
gcc/config/i386/i386.c| 4 ++--
gcc/config/i386/xm-djgpp.h| 4 ++--
gcc/config/iq2000/iq2000.c| 2 +-
gcc/config/m32c/m32c.c| 2 +-
gcc/config/msp430/msp430.c| 18 -
gcc/config/nds32/nds32.c | 6 +++---
gcc/config/nvptx/mkoffload.c | 2 +-
gcc/config/rx/rx.c| 7 ---
gcc/config/vms/vms-c.c| 15 +++---
gcc/lto-wrapper.c | 4 ++--
gcc/objc/objc-act.c | 18 +++--
gcc/omp-offload.c | 2 +-
gcc/symtab.c | 2 +-
gcc/tlink.c | 4 ++--
gcc/tree-profile.c| 2 +-
24 files changed, 80 insertions(+), 72 deletions(-)
diff --git a/contrib/check-internal-format-escaping.py b/contrib/check-internal-format-escaping.py
index 5da56b59dd6..aac4f9edeee 100755
--- a/contrib/check-internal-format-escaping.py
+++ b/contrib/check-internal-format-escaping.py
@@ -56,7 +56,7 @@ for i, l in enumerate(lines):
print('%s: %s' % (origin, text))
elif p.startswith('__builtin_'):
print('%s: %s' % (origin, text))
-if re.search("[a-zA-Z]'[a-zA-Z]", p):
+if re.search("[^%]'", p):
print('%s: %s' % (origin, text))
j += 1
diff --git a/gcc/collect-utils.c b/gcc/collect-utils.c
index 1e034433b80..1b1b27c9251 100644
--- a/gcc/collect-utils.c
+++ b/gcc/collect-utils.c
@@ -176,7 +176,7 @@ collect_execute (const char *prog, char **argv, const char *outname,
since we might not end up needing something that we could not find. */
if (argv[0] == 0)
-fatal_error (input_location, "cannot find '%s'", prog);
+fatal_error (input_locat
Re: [PATCH, GCC, AARCH64] Add GNU note section with BTI and PAC.
Hi Richard
On 02/04/2019 10:25, Sudakshina Das wrote:
> Hi
>
> On 02/04/2019 03:27, H.J. Lu wrote:
>> On Tue, Apr 2, 2019 at 10:05 AM Richard Henderson
>> wrote:
>>>
>>> On 4/1/19 8:53 PM, Sudakshina Das wrote:
> This could stand to use a comment, a moment's thinking about the
> sizes, and to
> use the existing asm output functions.
>
> /* PT_NOTE header: namesz, descsz, type.
> namesz = 4 ("GNU\0")
> descsz = 12 (see below)
I was trying out these changes but the descsz of 12 gets rejected by
readelf. It hits the following
unsigned int size = is_32bit_elf ? 4 : 8;
printf (_(" Properties: "));
if (pnote->descsz < 8 || (pnote->descsz % size) != 0)
{
printf (_("\n"),
pnote->descsz);
return;
}
>>>
>>> Hmm, interesting. The docs say that padding is not to be included in
>>> descsz
>>> (gabi4.1, page 82). To my eye this is a bug in binutils, but perhaps
>>> we will
>>> have to live with it.
>>>
>>> Nick, thoughts?
>>
>> descsz is wrong. From:
>>
>> https://github.com/hjl-tools/linux-abi/wiki/Linux-Extensions-to-gABI
>>
>> n_desc The note descriptor. The first n_descsz bytes in n_desc is the
>> pro-
>> gram property array.
>>
>> The program property array
>> Each array element represents one program property with type, data
>> size and data.
>> In 64-bit objects, each element is an array of 8-byte integers in the
>> format of the
>> target processor. In 32-bit objects, each element is an array of
>> 4-byte integers in
>> the format of the target processor.
>
> Thanks @HJ for clarifying that. I should have been more careful in
> spotting the difference.
>
> @Richard I will update my patch according to your suggestions but
> keeping in mind decssz should be the size of the entire program property
> array so 16 in this case.
>
I have updated the patch as per your suggestions. The Changelog is still
valid from my original patch.
Thanks
Sudi
> Thanks
> Sudi
>>
>>
>
diff --git a/gcc/config/aarch64/aarch64-linux.h b/gcc/config/aarch64/aarch64-linux.h
index 9d0292d64f20939ccedd7ab56027aa1282826b23..5e8b34ded03c78493f868e38647bf57c2da5187c 100644
--- a/gcc/config/aarch64/aarch64-linux.h
+++ b/gcc/config/aarch64/aarch64-linux.h
@@ -83,7 +83,7 @@
#define GNU_USER_TARGET_D_CRITSEC_SIZE 48
-#define TARGET_ASM_FILE_END file_end_indicate_exec_stack
+#define TARGET_ASM_FILE_END aarch64_file_end_indicate_exec_stack
/* Uninitialized common symbols in non-PIE executables, even with
strong definitions in dependent shared libraries, will resolve
diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index b38505b0872688634b2d3f625ab8d313e89cfca0..f25f7da8f0224167db68e61a2ba88f0943316360 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -18744,6 +18744,56 @@ aarch64_stack_protect_guard (void)
return NULL_TREE;
}
+/* Implement TARGET_ASM_FILE_END for AArch64. This adds the AArch64 GNU NOTE
+ section at the end if needed. */
+#define GNU_PROPERTY_AARCH64_FEATURE_1_AND 0xc000
+#define GNU_PROPERTY_AARCH64_FEATURE_1_BTI (1U << 0)
+#define GNU_PROPERTY_AARCH64_FEATURE_1_PAC (1U << 1)
+void
+aarch64_file_end_indicate_exec_stack ()
+{
+ file_end_indicate_exec_stack ();
+
+ unsigned feature_1_and = 0;
+ if (aarch64_bti_enabled ())
+feature_1_and |= GNU_PROPERTY_AARCH64_FEATURE_1_BTI;
+
+ if (aarch64_ra_sign_scope != AARCH64_FUNCTION_NONE)
+feature_1_and |= GNU_PROPERTY_AARCH64_FEATURE_1_PAC;
+
+ if (feature_1_and)
+{
+ /* Generate .note.gnu.property section. */
+ switch_to_section (get_section (".note.gnu.property",
+ SECTION_NOTYPE, NULL));
+
+ /* PT_NOTE header: namesz, descsz, type.
+ namesz = 4 ("GNU\0")
+ descsz = 16 (Size of the program property array)
+ type = 5 (NT_GNU_PROPERTY_TYPE_0). */
+ assemble_align (POINTER_SIZE);
+ assemble_integer (GEN_INT (4), 4, 32, 1);
+ assemble_integer (GEN_INT (16), 4, 32, 1);
+ assemble_integer (GEN_INT (5), 4, 32, 1);
+
+ /* PT_NOTE name. */
+ assemble_string ("GNU", 4);
+
+ /* PT_NOTE contents for NT_GNU_PROPERTY_TYPE_0:
+ type = GNU_PROPERTY_AARCH64_FEATURE_1_AND
+ datasz = 4
+ data = feature_1_and. */
+ assemble_integer (GEN_INT (GNU_PROPERTY_AARCH64_FEATURE_1_AND), 4, 32, 1);
+ assemble_integer (GEN_INT (4), 4, 32, 1);
+ assemble_integer (GEN_INT (feature_1_and), 4, 32, 1);
+
+ /* Pad the size of the note to the required alignment. */
+ assemble_align (POINTER_SIZE);
+}
+}
+#undef GNU_PROPERTY_AARCH64_FEATURE_1_PAC
+#undef GNU_PROPERTY_AARCH64_FEATURE_1_BTI
+#undef GNU_PROPERTY_AARCH64_FEATURE_1_AND
/* Target-specific selftests. */
diff --git a/gcc/testsuite/gcc.target/aarch64/bti-1.c b/gcc/testsuite/gcc.target/aarch64/bti-1.c
index a8c60412e310a4f322372f334ae5314f426d310e..5a556b08ed15679b25676a11fe9c7a64641ee671
Re: [PATCH, GCC, AARCH64] Add GNU note section with BTI and PAC.
On 4/3/19 5:19 PM, Sudakshina Das wrote:
> + /* PT_NOTE header: namesz, descsz, type.
> + namesz = 4 ("GNU\0")
> + descsz = 16 (Size of the program property array)
> + type = 5 (NT_GNU_PROPERTY_TYPE_0). */
> + assemble_align (POINTER_SIZE);
> + assemble_integer (GEN_INT (4), 4, 32, 1);
> + assemble_integer (GEN_INT (16), 4, 32, 1);
So, it's 16 only if POINTER_SIZE == 64.
I think ROUND_UP (12, POINTER_BYTES) is what you want here.
r~
[PATCH][RFC] Fix PRs 88882, 89905, 89892 (and more?)
The following patch tries to plug the CFG cleanup forwarder block
removal hole for wrong-debug PRs. Currently when we cannot move
debug-stmts to the destination block (because that has multiple
predecessors and thus the debug stmt could possibly not be
valid on all paths into the block) we simply drop them on the
floor. That is of course wrong since earlier live (and wrong)
values might now be visible at this point.
My solution is to instead of dropping the debug binds still
move them to the destination but then reset them. This solves
the wrong-debug issue.
But it of course possibly degrades debug information for the
other paths into the destination block.
I'm less sure what would be the correct action for DEBUG_BEGIN
stmts (the patch contines to drop them on the floor, leaving
reset debug-binds possibly surrounded by wrong stmt context?).
Not sure what else debug stmt kinds we have and what the proper
action for those would be.
Somewhere I've written that debug-stmts living on edges would
also solve the issue on the GIMPLE (and RTL) side, not sure
if we can make sense of those in the end though. Having stmts
permanently on edges is also sth new on GIMPLE so I'm staying
away from that at this moment...
I've noted that for the specific case where there is
(before the next DEBUG_BEGIN_STMT? before the next real stmt?)
(debug-) definitions of the debug vars we reset in the destination
block then dropping the debug stmt might be better and avoids
the debug-info quality degadation. Any opinions on the boundary
(DEBUG_BEGIN_STMT, real stmt, basic-block, post-domination region)
we can look up to for such definition? I guess that at least
looking at all PHI nodes of the destination might be a good
idea because those defs happen before the "new" debug reset.
Jakub - I remember you posted debug-info quality summaries
(location counts / extents) previously, do you have a script
to extract those from ELF objects?
Meanwhile bootstrap & regtest is running on x86_64-unknown-linux-gnu.
Richard.
2019-04-03 Richard Biener
PR debug/89892
PR debug/89905
* tree-cfgcleanup.c (remove_forwarder_block): Always move
debug bind stmts but reset them if they are not valid at the
destination.
* gcc.dg/guality/pr89892.c: New testcase.
* gcc.dg/guality/pr89905.c: Likewise.
Index: gcc/tree-cfgcleanup.c
===
--- gcc/tree-cfgcleanup.c (revision 270114)
+++ gcc/tree-cfgcleanup.c (working copy)
@@ -564,15 +564,39 @@ remove_forwarder_block (basic_block bb)
gsi_next (&gsi);
}
- /* Move debug statements if the destination has a single predecessor. */
- if (can_move_debug_stmts && !gsi_end_p (gsi))
+ /* Move debug statements. Reset them if the destination does not
+ have a single predecessor. */
+ if (!gsi_end_p (gsi))
{
gsi_to = gsi_after_labels (dest);
do
{
gimple *debug = gsi_stmt (gsi);
gcc_assert (is_gimple_debug (debug));
- gsi_move_before (&gsi, &gsi_to);
+ /* Move debug binds anyway, but not anything else
+like begin-stmt markers unless they are always
+valid at the destination. */
+ if (can_move_debug_stmts
+ || gimple_debug_bind_p (debug))
+ {
+ gsi_move_before (&gsi, &gsi_to);
+ /* Reset debug-binds that are not always valid at the
+destination. Simply dropping them can cause earlier
+values to become live, generating wrong debug information.
+??? There are several things we could improve here. For
+one we might be able to move stmts to the predecessor.
+For anther, if the debug stmt is immediately followed
+by a (debug) definition in the destination (on a
+post-dominated path?) we can elide it without any bad
+effects. */
+ if (!can_move_debug_stmts)
+ {
+ gimple_debug_bind_reset_value (debug);
+ update_stmt (debug);
+ }
+ }
+ else
+ gsi_next (&gsi);
}
while (!gsi_end_p (gsi));
}
Index: gcc/testsuite/gcc.dg/guality/pr89892.c
===
--- gcc/testsuite/gcc.dg/guality/pr89892.c (nonexistent)
+++ gcc/testsuite/gcc.dg/guality/pr89892.c (working copy)
@@ -0,0 +1,34 @@
+/* { dg-do run } */
+/* { dg-options "-g" } */
+
+void __attribute__((noinline))
+optimize_me_not ()
+{
+ __asm__ volatile ("" : : : "memory");
+}
+volatile int a;
+static short b[3][9][1] = {5};
+int c;
+int main() {
+int i, d;
+i = 0;
+for (; i < 3; i++) {
+ c = 0;
+ for (; c < 9; c++) {
+ d = 0;
+ for (; d < 1; d++)
+ a = b[i][c][d];
+ }
+}
+i = c = 0;
+for (; c < 7
Re: [PATCH] Updated patch for PR84101
Richard Biener writes:
> On Mon, 1 Apr 2019, Richard Sandiford wrote:
>
>> Richard Biener writes:
>> > This is an update from last years attempt to tame down vectorization
>> > when it runs in to ABI inefficiencies at function return. I've
>> > updated the patch to look for multi-reg returns instead of
>> > !vector ones (due to word_mode vectorization) and handle a bit
>> > more returns, esp. the common pattern of
>> >
>> > ret = vector;
>> > D.1234 = ret;
>> > ret = {CLOBBER};
>> > return D.1234;
>> >
>> > Bootstrapped and tested on x86_64-unknown-linux-gnu, OK?
>> >
>> > I know this isn't the ultimate solution but we keep getting
>> > duplicates of the PR.
>> >
>> > Richard.
>> >
>> > 2019-03-28 Richard Biener
>> >
>> >PR tree-optimization/84101
>> >* tree-vect-stmts.c: Include explow.h for hard_function_value,
>> >regs.h for hard_regno_nregs.
>> >(cfun_returns): New helper.
>> >(vect_model_store_cost): When vectorizing a store to a decl
>> >we return and the function ABI returns in a multi-reg location
>> >account for the possible spilling that will happen.
>> >
>> >* gcc.target/i386/pr84101.c: New testcase.
>> >
>> > Index: gcc/tree-vect-stmts.c
>> > ===
>> > --- gcc/tree-vect-stmts.c (revision 269987)
>> > +++ gcc/tree-vect-stmts.c (working copy)
>> > @@ -43,6 +43,7 @@ along with GCC; see the file COPYING3.
>> > #include "tree-cfg.h"
>> > #include "tree-ssa-loop-manip.h"
>> > #include "cfgloop.h"
>> > +#include "explow.h"
>> > #include "tree-ssa-loop.h"
>> > #include "tree-scalar-evolution.h"
>> > #include "tree-vectorizer.h"
>> > @@ -52,6 +53,7 @@ along with GCC; see the file COPYING3.
>> > #include "vec-perm-indices.h"
>> > #include "tree-ssa-loop-niter.h"
>> > #include "gimple-fold.h"
>> > +#include "regs.h"
>> >
>> > /* For lang_hooks.types.type_for_mode. */
>> > #include "langhooks.h"
>> > @@ -948,6 +950,37 @@ vect_model_promotion_demotion_cost (stmt
>> > "prologue_cost = %d .\n", inside_cost,
>> > prologue_cost);
>> > }
>> >
>> > +/* Returns true if the current function returns DECL. */
>> > +
>> > +static bool
>> > +cfun_returns (tree decl)
>> > +{
>> > + edge_iterator ei;
>> > + edge e;
>> > + FOR_EACH_EDGE (e, ei, EXIT_BLOCK_PTR_FOR_FN (cfun)->preds)
>> > +{
>> > + greturn *ret = safe_dyn_cast (last_stmt (e->src));
>> > + if (!ret)
>> > + continue;
>> > + if (gimple_return_retval (ret) == decl)
>> > + return true;
>> > + /* We often end up with an aggregate copy to the result decl,
>> > + handle that case as well. First skip intermediate clobbers
>> > + though. */
>> > + gimple *def = ret;
>> > + do
>> > + {
>> > +def = SSA_NAME_DEF_STMT (gimple_vuse (def));
>> > + }
>> > + while (gimple_clobber_p (def));
>> > + if (is_a (def)
>> > +&& gimple_assign_lhs (def) == gimple_return_retval (ret)
>> > +&& gimple_assign_rhs1 (def) == decl)
>> > + return true;
>> > +}
>> > + return false;
>> > +}
>> > +
>> > /* Function vect_model_store_cost
>> >
>> > Models cost for stores. In the case of grouped accesses, one access
>> > @@ -1032,6 +1065,37 @@ vect_model_store_cost (stmt_vec_info stm
>> > vec_to_scalar, stmt_info, 0, vect_body);
>> > }
>> >
>> > + /* When vectorizing a store into the function result assign
>> > + a penalty if the function returns in a multi-register location.
>> > + In this case we assume we'll end up with having to spill the
>> > + vector result and do piecewise loads. */
>> > + tree base = get_base_address (STMT_VINFO_DATA_REF (stmt_info)->ref);
>> > + if (base
>> > + && (TREE_CODE (base) == RESULT_DECL
>> > +|| (DECL_P (base) && cfun_returns (base)))
>> > + && !aggregate_value_p (base, cfun->decl))
>> > +{
>> > + rtx reg = hard_function_value (TREE_TYPE (base), cfun->decl, 0, 1);
>> > + /* ??? Handle PARALLEL in some way. */
>> > + if (REG_P (reg))
>> > + {
>> > +int nregs = hard_regno_nregs (REGNO (reg), GET_MODE (reg));
>> > +/* Assume that a reg-reg move is possible and cheap,
>> > + do not account for vector to gp register move cost. */
>> > +if (nregs > 1)
>>
>> Looks OK to me FWIW, but maybe it would be worth having a check like:
>>
>> targetm.secondary_memory_needed (TYPE_MODE (vectype), ALL_REGS,
>> REGNO_REG_CLASS (REGNO (reg)))
>>
>> as well as the above, so that we don't accidentally penalise values
>> that are returned in multiple vector registers. Looks like the i386.c
>> definition will return true in the cases that matter.
>
> I wonder if what this hook returns makes sense if you feed it modes
> with different sizes? Say for the testcase V2DImode and
> the general regs class (DImode).
In this case I think it's between V2DImode and TImode. I went with
the vector mode becaus
Re: [PATCH] Updated patch for PR84101
On Wed, 3 Apr 2019, Richard Sandiford wrote:
> Richard Biener writes:
> > On Mon, 1 Apr 2019, Richard Sandiford wrote:
> >
> >> Richard Biener writes:
> >> > This is an update from last years attempt to tame down vectorization
> >> > when it runs in to ABI inefficiencies at function return. I've
> >> > updated the patch to look for multi-reg returns instead of
> >> > !vector ones (due to word_mode vectorization) and handle a bit
> >> > more returns, esp. the common pattern of
> >> >
> >> > ret = vector;
> >> > D.1234 = ret;
> >> > ret = {CLOBBER};
> >> > return D.1234;
> >> >
> >> > Bootstrapped and tested on x86_64-unknown-linux-gnu, OK?
> >> >
> >> > I know this isn't the ultimate solution but we keep getting
> >> > duplicates of the PR.
> >> >
> >> > Richard.
> >> >
> >> > 2019-03-28 Richard Biener
> >> >
> >> > PR tree-optimization/84101
> >> > * tree-vect-stmts.c: Include explow.h for hard_function_value,
> >> > regs.h for hard_regno_nregs.
> >> > (cfun_returns): New helper.
> >> > (vect_model_store_cost): When vectorizing a store to a decl
> >> > we return and the function ABI returns in a multi-reg location
> >> > account for the possible spilling that will happen.
> >> >
> >> > * gcc.target/i386/pr84101.c: New testcase.
> >> >
> >> > Index: gcc/tree-vect-stmts.c
> >> > ===
> >> > --- gcc/tree-vect-stmts.c(revision 269987)
> >> > +++ gcc/tree-vect-stmts.c(working copy)
> >> > @@ -43,6 +43,7 @@ along with GCC; see the file COPYING3.
> >> > #include "tree-cfg.h"
> >> > #include "tree-ssa-loop-manip.h"
> >> > #include "cfgloop.h"
> >> > +#include "explow.h"
> >> > #include "tree-ssa-loop.h"
> >> > #include "tree-scalar-evolution.h"
> >> > #include "tree-vectorizer.h"
> >> > @@ -52,6 +53,7 @@ along with GCC; see the file COPYING3.
> >> > #include "vec-perm-indices.h"
> >> > #include "tree-ssa-loop-niter.h"
> >> > #include "gimple-fold.h"
> >> > +#include "regs.h"
> >> >
> >> > /* For lang_hooks.types.type_for_mode. */
> >> > #include "langhooks.h"
> >> > @@ -948,6 +950,37 @@ vect_model_promotion_demotion_cost (stmt
> >> > "prologue_cost = %d .\n", inside_cost,
> >> > prologue_cost);
> >> > }
> >> >
> >> > +/* Returns true if the current function returns DECL. */
> >> > +
> >> > +static bool
> >> > +cfun_returns (tree decl)
> >> > +{
> >> > + edge_iterator ei;
> >> > + edge e;
> >> > + FOR_EACH_EDGE (e, ei, EXIT_BLOCK_PTR_FOR_FN (cfun)->preds)
> >> > +{
> >> > + greturn *ret = safe_dyn_cast (last_stmt (e->src));
> >> > + if (!ret)
> >> > +continue;
> >> > + if (gimple_return_retval (ret) == decl)
> >> > +return true;
> >> > + /* We often end up with an aggregate copy to the result decl,
> >> > + handle that case as well. First skip intermediate clobbers
> >> > + though. */
> >> > + gimple *def = ret;
> >> > + do
> >> > +{
> >> > + def = SSA_NAME_DEF_STMT (gimple_vuse (def));
> >> > +}
> >> > + while (gimple_clobber_p (def));
> >> > + if (is_a (def)
> >> > + && gimple_assign_lhs (def) == gimple_return_retval (ret)
> >> > + && gimple_assign_rhs1 (def) == decl)
> >> > +return true;
> >> > +}
> >> > + return false;
> >> > +}
> >> > +
> >> > /* Function vect_model_store_cost
> >> >
> >> > Models cost for stores. In the case of grouped accesses, one access
> >> > @@ -1032,6 +1065,37 @@ vect_model_store_cost (stmt_vec_info stm
> >> > vec_to_scalar, stmt_info, 0,
> >> > vect_body);
> >> > }
> >> >
> >> > + /* When vectorizing a store into the function result assign
> >> > + a penalty if the function returns in a multi-register location.
> >> > + In this case we assume we'll end up with having to spill the
> >> > + vector result and do piecewise loads. */
> >> > + tree base = get_base_address (STMT_VINFO_DATA_REF (stmt_info)->ref);
> >> > + if (base
> >> > + && (TREE_CODE (base) == RESULT_DECL
> >> > + || (DECL_P (base) && cfun_returns (base)))
> >> > + && !aggregate_value_p (base, cfun->decl))
> >> > +{
> >> > + rtx reg = hard_function_value (TREE_TYPE (base), cfun->decl, 0,
> >> > 1);
> >> > + /* ??? Handle PARALLEL in some way. */
> >> > + if (REG_P (reg))
> >> > +{
> >> > + int nregs = hard_regno_nregs (REGNO (reg), GET_MODE (reg));
> >> > + /* Assume that a reg-reg move is possible and cheap,
> >> > + do not account for vector to gp register move cost. */
> >> > + if (nregs > 1)
> >>
> >> Looks OK to me FWIW, but maybe it would be worth having a check like:
> >>
> >> targetm.secondary_memory_needed (TYPE_MODE (vectype), ALL_REGS,
> >> REGNO_REG_CLASS (REGNO (reg)))
> >>
> >> as well as the above, so that we don't accidentally penalise
Re: [PATCH] Updated patch for PR84101
Richard Biener writes: >> > So, may I go with the original patch? >> >> Still feels like we're counting spills on targets that shouldn't need them. >> But going back to: >> >>/* Assume that a reg-reg move is possible and cheap, >> do not account for vector to gp register move cost. */ >> >> I guess we could gloss over the "unnecessary" spill cost by saying that, >> even if the spill isn't needed, this is a conservative estimate of the >> vector to gp register move cost? > > Yes. What I really tried to ask is - am I going to need the > vectorized result piecewise in the end (but not being in control > of the chopping into pieces)? I wanted to pessimize that with > an estimate of the "chopping cost". I probably shouldn't have > talked about spilling but that's the usual straight-forward > solution of extracting sth from a larger register that works > everywhere. > > So I guess I'll update the comment and install as-is? Sounds good to me. Richard > > I still hope for a better solution either on the target or the > RTL optimization side (undoing the vectorization). > > Richard.
Re: [PATCH] Fix a missed case in predicate analysis of the late uninit pass
On Mon, Apr 1, 2019 at 5:36 PM Vladislav Ivanishin wrote: > > Hi! > > This is a fairly trivial change fixing a false negative in > -Wmaybe-uninitialized. I am pretty sure this is simply an overlooked > case (is_value_included_in() is not meant to deal with the case where > both compare codes are NE_EXPRs, neither does it need to, since their > handling is trivial). > > In a nutshell, what happens is values of v restricted by (v != 2) are > incorrectly considered a subset of values of v restricted by (v != 1). > As if "v != 2, therefore v != 1". > > This is by no means a gcc-9 regression; I'll ping the patch once stage4 > is over, if needed. > > This came up when I was experimenting with moving the uninit passes > around. On mainline, the late uninit pass runs very late, so reliably > triggering the affected path is a bit tricky. So I created a GIMPLE > test (it reproduces the behavior precisely, but might be fragile > w.r.t. future versions of the textual representation) and then with a > hint from Alexander managed to produce a simple C test. [By the way, > the first take was to insert an asm with a lot of newlines to prevent > the dom pass from rewriting the CFG due to high cost of duplicating > instructions. This didn't work out; I think the dom pass does not > respect sizes of inline asms. I plan to create a testcase and file a > bug later.] > > I ran regression testing on x86_64-pc-linux-gnu and saw no new > regressions modulo a handful of flaky UNRESOLVED tests under > gcc.dg/tree-prof. `BOOT_CFLAGS="-O -Wno-error=maybe-uninitialized > -Wmaybe-uninitialized" bootstrap` also succeeded producing no new > warnings. > > OK for stage1? Hum. While definitely two NE_EXPR do not work correctly I'd like to see a positive test since LT_EXPR doesn't work either? Specifically the code falls through to test is_value_included_in which seems to assume code1 == code2. To me it looks like is_value_includeds comment should be clarified to say /* Returns true if all values X satisfying X CMPC VAL satisfy X CMPC BOUNDARY. */ That is, "all values in the range" in the current comment is under-specified since VAL is just a single value. So I wonder what testcases regress if we remove the && code2 != NE_EXPR case? That way we see what the intention was. A patch should then change that to if ((code1 != code2) || !( && code2 == NE_EXPR)) return false; to explicitely spell out what case was meant here. Richard. > > -- > Vlad
Re: [PATCH 3/N] Fix GCC internal format in D front-end.
On 4/2/19 4:13 PM, Iain Buclaw wrote: > On Tue, 2 Apr 2019 at 12:51, Martin Liška wrote: >> >> On 3/11/19 3:00 PM, Martin Liška wrote: >>> On 3/11/19 2:38 PM, Jakub Jelinek wrote: I think for D you need to go through Iain Buclaw, I have no idea if exp->error even has the gcc internal format infrastructure. Can you split that part of the patch and post it independently? >>> >>> The patch addresses that. >>> >>> Martin >>> >> >> Iain, what do you think about the patch? >> > > Is this because it got picked up by exgettext? I've added > expressionsem.c to the EXCLUDES so I think this change is no longer > needed. Ok then. Thanks > > If required however, then the place to fix it would be in > expand_d_format, which deals with oddities with format strings in the > dmd front-end. >
Re: [RFC] D support for S/390
Hi Robin,
>> Are the values inside the tables the problem? Or just some of the
>> helper functions/templates that interact with them to generate the
>> static data?
>>
>> If the latter, then a rebuild of the files may not be necessary.
>
> I managed to get this to work without rebuilding the files. After
> checking more carefully, it turned out that simpleIndex already does the
> right thing and only a few simple changes were necessary.
>
> Continuing with the phobos test suite failures I managed to fix some
> more problems. I'm down to 32 failures now with the attached patch
> (single file this time). It doesn't even seem that much now, debugging
> the failures took me longer than what the diff reflects :)
>
> An imho nasty (since unexpected) one was the implicit pointer cast from
> size_t* to int* during a foreach delegate (see aApply.d:_aApplycd2). I
> did not check where exactly the cast happens but changing the int inside
> the foreach header to size_t fixed it.
>
> I also found some wrong POSIX defines and did not check all the others.
> A more thorough check might be necessary in the future.
>
> The tests I did not yet check/fix are shared libphobos, math and
> numeric-related as well as some regex and curl tests.
>
> Any chance we will get some or most of the diff in before GCC 9?
> (provided they do not break anything else of course) I'm going to be
> away for two weeks and will continue with the remaining failures afterwards.
I've applied the non-S/390 parts of the patch to move further along on
Solaris/SPARC (both 32 and 64-bit) since SPARC is another big-endian
target. I immediately ran into two issues with your patch:
/vol/gcc/src/hg/trunk/solaris/libphobos/src/std/xml.d:2216:19: error: cannot
implicitly convert expression (n) of type long to uint
2216 | s = s[n..$];
| ^
/vol/gcc/src/hg/trunk/solaris/libphobos/src/std/xml.d:2254:23: error: cannot
implicitly convert expression (n) of type long to uint
2254 | name = s[0 .. n];
| ^
/vol/gcc/src/hg/trunk/solaris/libphobos/src/std/xml.d:2255:15: error: cannot
implicitly convert expression (n) of type long to uint
2255 | s = s[n..$];
| ^
This will occur on any 32-bit target. The following patch (using
ssize_t instead) allowed the code to compile:
diff --git a/libphobos/src/std/xml.d b/libphobos/src/std/xml.d
--- a/libphobos/src/std/xml.d
+++ b/libphobos/src/std/xml.d
@@ -2192,6 +2192,8 @@ private
catch (Err e) { fail(e); }
}
+import core.sys.posix.sys.types : ssize_t;
+
void checkChars(ref string s) @safe pure // rule 2
{
// TO DO - Fix std.utf stride and decode functions, then use those
@@ -2201,7 +2203,7 @@ private
mixin Check!("Chars");
dchar c;
-long n = -1;
+ssize_t n = -1;
foreach (size_t i,dchar d; s)
{
if (!isChar(d))
@@ -2238,7 +2240,7 @@ private
mixin Check!("Name");
if (s.length == 0) fail();
-long n;
+ssize_t n;
// i must not be smaller than size_t because size_t is used internally
// in aApply.d and it will be cast e.g. to (int *) which fails on
// big-endian machines.
Another issue on 32-bit targets is
FAIL: gdc.dg/runnable.d -O0 (test for excess errors)
Excess errors:
/vol/gcc/src/hg/trunk/solaris/gcc/testsuite/gdc.dg/runnable.d:923:13: error:
function runnable.test186a (uint val) is not callable using argument types
(long)
Again, this will occur on any 32-bit target.
Besides, you're quite inconsistent with the use of tab vs. blank in your
patch. The D code uses only blanks as a rule, for example.
I've still got tons of execution failures with that augmented patch, but
those seem down to just a few root causes.
Rainer
--
-
Rainer Orth, Center for Biotechnology, Bielefeld University
[Committed] S/390: Reject long disp for vector load/store early
The vector memory instructions only support short displacements.
Reject invalid displacements early to prevent plenty of lay
instructions to be generated later which then cannot be merged
properly.
Committed to mainline after bootstrapping and regtesting on IBM z14.
gcc/ChangeLog:
2019-04-03 Andreas Krebbel
* config/s390/s390.c (s390_legitimate_address_p): Reject long
displacement addresses for vector mode operands.
---
gcc/config/s390/s390.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/gcc/config/s390/s390.c b/gcc/config/s390/s390.c
index bceaca3fbc8..e0b62b741f2 100644
--- a/gcc/config/s390/s390.c
+++ b/gcc/config/s390/s390.c
@@ -4677,6 +4677,17 @@ s390_legitimate_address_p (machine_mode mode, rtx addr,
bool strict)
if (!s390_decompose_address (addr, &ad))
return false;
+ /* The vector memory instructions only support short displacements.
+ Reject invalid displacements early to prevent plenty of lay
+ instructions to be generated later which then cannot be merged
+ properly. */
+ if (TARGET_VX
+ && VECTOR_MODE_P (mode)
+ && ad.disp != NULL_RTX
+ && CONST_INT_P (ad.disp)
+ && !SHORT_DISP_IN_RANGE (INTVAL (ad.disp)))
+return false;
+
if (strict)
{
if (ad.base && !REGNO_OK_FOR_BASE_P (REGNO (ad.base)))
--
2.17.1
Re: [PATCH] Fix PR71598, aliasing between enums and compatible types
On Wed, 3 Apr 2019 at 10:24, Richard Biener wrote:
>
> On Wed, 3 Apr 2019, Christophe Lyon wrote:
>
> > Hi!
> >
> > On Fri, 29 Mar 2019 at 20:02, Jeff Law wrote:
> > >
> > > On 3/29/19 9:09 AM, Jason Merrill wrote:
> > > > On Fri, Mar 29, 2019 at 4:48 AM Richard Biener
> > > > wrote:
> > > >>
> > > >> On Thu, 28 Mar 2019, Jason Merrill wrote:
> > > >>
> > > >>> On 3/26/19 4:40 AM, Richard Biener wrote:
> > > On Mon, 18 Mar 2019, Richard Biener wrote:
> > >
> > > > On Fri, 15 Mar 2019, Jason Merrill wrote:
> > > >
> > > >> On 3/15/19 9:33 AM, Richard Biener wrote:
> > > >>>
> > > >>> The following is an attempt to fix PR71598 where C (and C++?) have
> > > >>> an implementation-defined compatible integer type for each enum
> > > >>> and the TBAA rules mandate that accesses using a compatible type
> > > >>> are allowed.
> > > >>
> > > >> This does not apply to C++; an enum does not alias its underlying
> > > >> type.
> > > >
> > > > Thus the following different patch, introducing c_get_alias_set and
> > > > only doing the special handling for C family frontends (I assume
> > > > that at least ObjC is also affected).
> > > >
> > > > Bootstrap & regtest running on x86_64-unknown-linux-gnu, OK?
> > >
> > > Ping. Also consider the additional testcase below to be added.
> > >
> > > Richard.
> > >
> > > 2019-03-18 Richard Biener
> > >
> > > PR c/71598
> > > * gimple.c: Include langhooks.h.
> > > (gimple_get_alias_set): Treat enumeral types as the
> > > underlying
> > > integer type.
> > > >>>
> > > >>> Won't this affect all languages?
> > > >>
> > > >> It affects all languages during the LTO optimization phase, yes.
> > > >> There's unfortunately no way around that at the moment.
> > > >
> > > > Ah, well. Looks good to me, then.
> > > Likewise. And with Joseph largely offline right now, that's going to
> > > have to be sufficient :-)
> > >
> >
> >
> > I've noticed minor new errors at link time on arm with the 2 new testcases.
> > pr71598-1.c complains on arm-none-eabi because
> > arm-none-eabi/bin/ld: warning: /ccu5w26t.o uses 32-bit enums yet the
> > output is to use variable-size enums; use of enum values across
> > objects may fail
> >
> > conversely, pr71598-2.c complains on arm-none-linux-gnueabi* because:
> > arm-none-linux-gnueabi/bin/ld: warning: /ccl5OUKi.o uses variable-size
> > enums yet the output is to use 32-bit enums; use of enum values across
> > objects may fail
> >
> > In both cases this is because crt0.o is built with the opposite
> > (default) short-enum option than the testcase, so the linker sees a
> > mismatch between crt0.o and pr71598-X.o.
> >
> > Shall I add target-dependent dg-warning directives in the testcases,
> > or is there a better way?
>
> Maybe dg-skip the test for target_short_enums which seems to exist?
>
> Can you try if that works and if so, commit the fix?
>
Thanks, here is what I have committed as r270126.
(skip one test on short_enums targets, skip the other one on
non-short_enums targets)
Christophe
> Thanks,
> Richard.
2019-04-13 Christophe Lyon
PR c/71598
* gcc.dg/torture/pr71598-1.c: Skip if short_enums target.
* gcc.dg/torture/pr71598-2.c: Skip if not short_enums target.
Index: gcc/testsuite/gcc.dg/torture/pr71598-1.c
===
--- gcc/testsuite/gcc.dg/torture/pr71598-1.c(revision 270125)
+++ gcc/testsuite/gcc.dg/torture/pr71598-1.c(revision 270126)
@@ -1,4 +1,5 @@
/* { dg-do run } */
+/* { dg-skip-if "" { short_enums } } */
/* { dg-additional-options "-fno-short-enums" } */
enum e1 { c1 };
Index: gcc/testsuite/gcc.dg/torture/pr71598-2.c
===
--- gcc/testsuite/gcc.dg/torture/pr71598-2.c(revision 270125)
+++ gcc/testsuite/gcc.dg/torture/pr71598-2.c(revision 270126)
@@ -1,4 +1,5 @@
/* { dg-do run } */
+/* { dg-skip-if "" { ! short_enums } } */
/* { dg-additional-options "-fshort-enums" } */
enum e1 { c1 = -__INT_MAX__ };
Re: [PATCH, wwwdocs] Update on existence of free emulators for alpha, VAX
Let me include the maintainers for alpha and vax; from a web page perspective this is clearly fine, but I'm not expert enough on the technical aspects. (Richard, Matt, if/once you okay, I can apply the patch so you're off the hook.) Gerald On Sun, 31 Mar 2019, co...@sdf.org wrote: > As far as I can tell, alpha can be emulated by QEMU. > VAX has SIMH. (Perhaps I should mention it somewhere? :)) > > Index: backends.html > === > RCS file: /cvs/gcc/wwwdocs/htdocs/backends.html,v > retrieving revision 1.84 > diff -u -r1.84 backends.html > --- backends.html 18 Jan 2019 11:52:12 - 1.84 > +++ backends.html 31 Mar 2019 08:00:23 - > @@ -69,7 +69,7 @@ > Target | HMSLQNFICBD lqrcpbfmgiates > ---+--- > aarch64| Qq b gia s > -alpha | ?? Q Cq mgi e > +alpha | ? Q Cq mgi e > arc| B b gia > arm| b ia s > avr|L FIl cp g > @@ -116,7 +116,7 @@ > tilegx | S Q Cq gi e > tilepro| S F C gi e > v850 | g a s > -vax| M?I c b i e > +vax| M I c b i e > visium | B g t s > xtensa | C > >
[Patch fortran] PR 68567 - ICE on using wrong defined arrays (different cases/messages)
Hi Steve,
Do you agree with the following packaging of your patch for pr68567?
2019-04-03 Steven G. Kargl
PR fortran/68567
* expr.c (gfc_reduce_init_expr): Add extra check to avoid dereferencing
a null
pointer.
2019-04-03 Dominique d'Humieres
PR fortran/68567
* gfortran.dg/parameter_array_error_1.f90: New test.
--- ../_clean/gcc/fortran/expr.c2019-04-03 11:00:55.0 +0200
+++ gcc/fortran/expr.c 2019-04-02 20:55:20.0 +0200
@@ -3003,7 +3003,7 @@ gfc_reduce_init_expr (gfc_expr *expr)
t = gfc_check_init_expr (expr);
gfc_init_expr_flag = false;
- if (!t)
+ if (!t || !expr)
return false;
if (expr->expr_type == EXPR_ARRAY)
! { dg-do compile }
! PR68567
! Contributed by Gerhard Steinmetz
!
program p
integer, parameter :: a(:) = [2, 1] ! { dg-error "cannot be automatic or of
deferred shape" }
end
Tested on darwin for more than two years.
TIA
Dominique
Re: [PATCH] Fix PR71598, aliasing between enums and compatible types
On Wed, 3 Apr 2019 at 15:19, Christophe Lyon wrote: > > On Wed, 3 Apr 2019 at 10:24, Richard Biener wrote: > > > > On Wed, 3 Apr 2019, Christophe Lyon wrote: > > > > > Hi! > > > > > > On Fri, 29 Mar 2019 at 20:02, Jeff Law wrote: > > > > > > > > On 3/29/19 9:09 AM, Jason Merrill wrote: > > > > > On Fri, Mar 29, 2019 at 4:48 AM Richard Biener > > > > > wrote: > > > > >> > > > > >> On Thu, 28 Mar 2019, Jason Merrill wrote: > > > > >> > > > > >>> On 3/26/19 4:40 AM, Richard Biener wrote: > > > > On Mon, 18 Mar 2019, Richard Biener wrote: > > > > > > > > > On Fri, 15 Mar 2019, Jason Merrill wrote: > > > > > > > > > >> On 3/15/19 9:33 AM, Richard Biener wrote: > > > > >>> > > > > >>> The following is an attempt to fix PR71598 where C (and C++?) > > > > >>> have > > > > >>> an implementation-defined compatible integer type for each enum > > > > >>> and the TBAA rules mandate that accesses using a compatible type > > > > >>> are allowed. > > > > >> > > > > >> This does not apply to C++; an enum does not alias its > > > > >> underlying type. > > > > > > > > > > Thus the following different patch, introducing c_get_alias_set > > > > > and > > > > > only doing the special handling for C family frontends (I assume > > > > > that at least ObjC is also affected). > > > > > > > > > > Bootstrap & regtest running on x86_64-unknown-linux-gnu, OK? > > > > > > > > Ping. Also consider the additional testcase below to be added. > > > > > > > > Richard. > > > > > > > > 2019-03-18 Richard Biener > > > > > > > > PR c/71598 > > > > * gimple.c: Include langhooks.h. > > > > (gimple_get_alias_set): Treat enumeral types as the > > > > underlying > > > > integer type. > > > > >>> > > > > >>> Won't this affect all languages? > > > > >> > > > > >> It affects all languages during the LTO optimization phase, yes. > > > > >> There's unfortunately no way around that at the moment. > > > > > > > > > > Ah, well. Looks good to me, then. > > > > Likewise. And with Joseph largely offline right now, that's going to > > > > have to be sufficient :-) > > > > > > > > > > > > > I've noticed minor new errors at link time on arm with the 2 new > > > testcases. > > > pr71598-1.c complains on arm-none-eabi because > > > arm-none-eabi/bin/ld: warning: /ccu5w26t.o uses 32-bit enums yet the > > > output is to use variable-size enums; use of enum values across > > > objects may fail > > > > > > conversely, pr71598-2.c complains on arm-none-linux-gnueabi* because: > > > arm-none-linux-gnueabi/bin/ld: warning: /ccl5OUKi.o uses variable-size > > > enums yet the output is to use 32-bit enums; use of enum values across > > > objects may fail > > > > > > In both cases this is because crt0.o is built with the opposite > > > (default) short-enum option than the testcase, so the linker sees a > > > mismatch between crt0.o and pr71598-X.o. > > > > > > Shall I add target-dependent dg-warning directives in the testcases, > > > or is there a better way? > > > > Maybe dg-skip the test for target_short_enums which seems to exist? > > > > Can you try if that works and if so, commit the fix? > > > > Thanks, here is what I have committed as r270126. > (skip one test on short_enums targets, skip the other one on > non-short_enums targets) > However this has the drawback that pr71598-2.c is now skipped on aarch64 (and probably many other targets). > Christophe > > > Thanks, > > Richard.
[committed] [PR rtl-optimization/81025 ] Don't walk through barriers when looking for consecutive labels
Copying from BZ: The bug here is in reorg and its legacy of trying to compensate for the lack of a CFG. In particular it has a function skip_consecutive_labels. The idea (of course) is to have jumps target the last label if there's several in a row. The code looks something like this: for (insn = label; insn != 0 && !INSN_P (insn); insn = NEXT_INSN (insn)) if (LABEL_P (insn)) label = insn; The loop termination condition allows the code to look through notes and other random crud. Now imagine if we have (code_label 1) (barrier) (code_label 2) (more code) The BARRIER after a CODE_LABEL can occur due to __builtin_unreachable. If a jump targets code_label 1, it will be redirected to code_label 2. That's fine from a runtime standpoint, but runs afoul of the CFI bits. Why? Consider if the jump which targeted label 1 did not have a prologue (we're shrink wrapping) and "more code" section is a shrink wrapped epilogue. The original paths to code_label 2 will have one CFI state while the new paths to code_label 1 will have a different CFI state and we trip the check. Ultimately the fix here is quite simple. Don't allow looking through a BARRIER when skipping "consecutive" labels. While this has bootstrapped and regression tested on x86_64, that's not a particularly useful test. More importantly, it's bootstrapped mipsisa32r2-linux-gnu and also built and regression tested on mips64-linux-gnu/mips64el-linux-gnu and a variety of other targets, some of which have delay slots. sparc64 is testing, but I won't have results for many many hours. Installing on the trunk. The testcase is flaky enough that I didn't bother to include it. Jeff commit 7570fd592fccd12c67a294c65a4904c7e1c0a797 Author: law Date: Wed Apr 3 16:03:37 2019 + PR rtl-optimization/81025 * reorg.c (skip_consecutive_labels): Do not skip past a BARRIER. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@270129 138bc75d-0d04-0410-961f-82ee72b054a4 diff --git a/gcc/ChangeLog b/gcc/ChangeLog index 9149d9c9a9e..0d7c206de90 100644 --- a/gcc/ChangeLog +++ b/gcc/ChangeLog @@ -1,3 +1,8 @@ +2019-04-03 Jeff Law + + PR rtl-optimization/81025 + * reorg.c (skip_consecutive_labels): Do not skip past a BARRIER. + 2019-04-03 Richard Biener PR tree-optimization/84101 diff --git a/gcc/reorg.c b/gcc/reorg.c index 84128a4fe9e..81349382b81 100644 --- a/gcc/reorg.c +++ b/gcc/reorg.c @@ -137,7 +137,20 @@ skip_consecutive_labels (rtx label_or_return) rtx_insn *label = as_a (label_or_return); - for (insn = label; insn != 0 && !INSN_P (insn); insn = NEXT_INSN (insn)) + /* __builtin_unreachable can create a CODE_LABEL followed by a BARRIER. + + Since reaching the CODE_LABEL is undefined behavior, we can return + any code label and we're OK at runtime. + + However, if we return a CODE_LABEL which leads to a shrinked wrapped + epilogue, but the path does not have a prologue, then we will trip + a sanity check in the dwarf2 cfi code which wants to verify that + the CFIs are all the same on the traces leading to the epilogue. + + So we explicitly disallow looking through BARRIERS here. */ + for (insn = label; + insn != 0 && !INSN_P (insn) && !BARRIER_P (insn); + insn = NEXT_INSN (insn)) if (LABEL_P (insn)) label = insn;
[PATCH] PR libstdc++/87431 re-adjust never-valueless optimizations
Avoid creating arbitrarily large objects on the stack when creating
temporaries in order to provide the strong exception-safety guarantee.
Also implement Antony Polukhin's suggestion to whitelist specific types
that can be efficiently move-assigned, so that emplacing those types
never causes a variant to become valueless. The whitelisted types are:
all trivially copyable types no greater than 256 bytes in size,
std::shared_ptr, std::weak_ptr, std::unique_ptr, std::function, and
std::any. Additionally, std::basic_string, std::vector, and
__gnu_debug::vector are whitelisted if their allocator traits give them
a non-throwing move assignment operator. Specifically, this means
std::string is whitelisted, but std::pmr::string is not.
PR libstdc++/87431 (again)
* include/bits/basic_string.h (__variant::_Never_valueless_alt):
Define partial specialization for basic_string.
* include/bits/shared_ptr.h (_Never_valueless_alt): Likewise for
shared_ptr and weak_ptr.
* include/bits/std_function.h (_Never_valueless_alt): Likewise for
function.
* include/bits/stl_vector.h (_Never_valueless_alt): Likewise for
vector.
* include/bits/unique_ptr.h (_Never_valueless_alt): Likewise for
unique_ptr.
* include/debug/vector (_Never_valueless_alt): Likewise for debug
vector.
* include/std/any (_Never_valueless_alt): Define explicit
specialization for any.
* include/std/variant (_Never_valueless_alt): Define primary template.
(__never_valueless): Use _Never_valueless_alt instead of
is_trivially_copyable.
(variant::emplace(Args&&...)): Add special case for non-throwing
initializations to avoid try-catch overhead. Add special case for
scalars produced by potentially-throwing conversions. Use
_Never_valueless_alt instead of is_trivially_copyable for the
remaining strong exception-safety cases.
(variant::emplace(initializer_list, Args&&...)): Likewise.
* testsuite/20_util/variant/87431.cc: Run both test functions.
* testsuite/20_util/variant/exception_safety.cc: New test.
* testsuite/20_util/variant/run.cc: Use pmr::string instead of string,
so the variant becomes valueless.
I'd like to commit this to trunk this week. Does anybody see any
problems with this approach?
As the comment in says, the _Never_valueless_alt trait has
ABI impact, so we should define it for more types now, or not at all.
When we add new types to the library we should consider if they need a
specialization of _Never_valueless_alt.
Should we also whitelist some (all?) other containers, as they all
have conditionally noexcept move assignment operators, and those
assignments are efficient when noexcept (because they don't
reallocate). Are there other types in the library we should consider
it for?
std::optional is automatically whitelisted for trivially copyable
types, because if T is trivially copyable then optional should be
too. We could also whitelist other specializations though:
template
struct _Never_valueless_alt>
: _Never_valueless_alt
{ };
We could also do:
template
struct _Never_valueless_alt>
: __and_<_Never_valueless_alt, _Never_valueless_alt>
{ };
template
struct _Never_valueless_alt>
: __and_<_Never_valueless_alt...>
{ };
In case it isn't clear, under normal circumstances something like a
variant,int> won't ever become valueless anyway, because
initialization of those alternatives doesn't throw. But what can throw
is a conversion operator that is invoked to produce one of those
alternatives. The _Never_valueless_alt trait says that emplacing an
alternative of that type should do some extra work to ensure the
variant doesn't become valueless *ever*. And then a variant that only
has never-valueless alternatives is itself never-valueless, and so the
valueless_by_exception() member just returns false, and visitation is
more efficient as it doesn't need to deal with the valueless state.
commit c6f0754f08c6285fc3383aae25f573b448ce31de
Author: Jonathan Wakely
Date: Wed Apr 3 11:08:43 2019 +0100
PR libstdc++/87431 re-adjust never-valueless optimizations
Avoid creating arbitrarily large objects on the stack when creating
temporaries in order to provide the strong exception-safety guarantee.
Also implement Antony Polukhin's suggestion to whitelist specific types
that can be efficiently move-assigned, so that emplacing those types
never causes a variant to become valueless. The whitelisted types are:
all trivially copyable types no greater than 256 bytes in size,
std::shared_ptr, std::weak_ptr, std::unique_ptr, std::function, and
std::any. Additionally, std::basic_string, std::vector, and
__gnu_debug::vector are whitelisted if their allocator traits give them
a non-throwing move assignment operator. Specifically, this means
std::string is whitelisted, but std::pmr::strin
Re: [PATCH] [ARC] PR 88409: miscompilation due to missing cc clobber in longlong.h macros
On 4/3/19 2:53 AM, Claudiu Zissulescu wrote:
> Pushed, thank you for your contribution,
> Claudiu
Thx, can this be backported to gcc-8-stable please which is what glibc folks use
for testing !
-Vineet
>
> On Tue, Apr 2, 2019 at 9:27 PM Vineet Gupta
> wrote:
>> simple test such as below was failing.
>>
>> | void main(int argc, char *argv[])
>> | {
>> |size_t total_time = 115424; // expected 115.424
>> |double secs = (double)total_time/(double)1000;
>> |printf("%s %d %lf\n", "secs", total_time, secs); // prints 113.504
>> |printf("%d\n", (size_t)secs);
>> | }
>>
>> The printf eventually called into glibc stdlib/divrem.c:__mpn_divrem()
>> which uses the __arc__ specific inline asm macros from longlong.h which
>> were causing miscompilation.
>>
>> include/
>> 2019-03-28 Vineet Gupta
>>
>> PR 89877
>>
>> * longlong.h [__arc__] (add_ss): Add cc clobber
>> (sub_ddmmss): Likewise.
>>
>> Signed-off-by: Vineet Gupta
>> ---
>> include/ChangeLog | 7 +++
>> include/longlong.h | 6 --
>> 2 files changed, 11 insertions(+), 2 deletions(-)
>>
>> diff --git a/include/ChangeLog b/include/ChangeLog
>> index be08141deeb9..96d967d10a52 100644
>> --- a/include/ChangeLog
>> +++ b/include/ChangeLog
>> @@ -1,3 +1,10 @@
>> +2019-03-28 Vineet Gupta
>> +
>> + PR 89877
>> +
>> + * longlong.h [__arc__] (add_ss): Add cc clobber
>> + (sub_ddmmss): Likewise.
>> +
>> 2019-02-11 Philippe Waroquiers
>>
>> * splay-tree.h (splay_tree_delete_key_fn): Update comment.
>> diff --git a/include/longlong.h b/include/longlong.h
>> index 3dd8dc3aa80c..1f0ce4204255 100644
>> --- a/include/longlong.h
>> +++ b/include/longlong.h
>> @@ -199,7 +199,8 @@ extern UDItype __udiv_qrnnd (UDItype *, UDItype,
>> UDItype, UDItype);
>>: "%r" ((USItype) (ah)), \
>> "rICal" ((USItype) (bh)), \
>> "%r" ((USItype) (al)), \
>> -"rICal" ((USItype) (bl)))
>> +"rICal" ((USItype) (bl)) \
>> + : "cc")
>> #define sub_ddmmss(sh, sl, ah, al, bh, bl) \
>>__asm__ ("sub.f %1, %4, %5\n\tsbc %0, %2, %3" \
>>: "=r" ((USItype) (sh)), \
>> @@ -207,7 +208,8 @@ extern UDItype __udiv_qrnnd (UDItype *, UDItype,
>> UDItype, UDItype);
>>: "r" ((USItype) (ah)), \
>> "rICal" ((USItype) (bh)), \
>> "r" ((USItype) (al)), \
>> -"rICal" ((USItype) (bl)))
>> +"rICal" ((USItype) (bl)) \
>> + : "cc")
>>
>> #define __umulsidi3(u,v) ((UDItype)(USItype)u*(USItype)v)
>> #ifdef __ARC_NORM__
>> --
>> 2.7.4
>>
[PATCH] Fix typo in comment
* files.c (search_path_exhausted): Fix typo in comment.
Committed as obvious.
commit 0e105a283e738b74744fa806a19d5f4afe56732a
Author: Jonathan Wakely
Date: Wed Apr 3 18:55:08 2019 +0100
Fix typo in comment
* files.c (search_path_exhausted): Fix typo in comment.
diff --git a/libcpp/files.c b/libcpp/files.c
index 77dc1889471..b0ac22be6ba 100644
--- a/libcpp/files.c
+++ b/libcpp/files.c
@@ -455,7 +455,7 @@ find_file_in_dir (cpp_reader *pfile, _cpp_file *file, bool
*invalid_pch,
return false;
}
-/* Return tue iff the missing_header callback found the given HEADER. */
+/* Return true iff the missing_header callback found the given HEADER. */
static bool
search_path_exhausted (cpp_reader *pfile, const char *header, _cpp_file *file)
{
Re: Re : add tsv110 pipeline scheduling
On Tue, Apr 02, 2019 at 03:26:22PM +0100, wuyuan (E) wrote:
> Hi ,James:
> Has the submitted patch been merged into the trunk? Looking forward to your
> reply , thank you very much!
>
>
>
> Best Regards,
>
> wuyuan
Hi Wuyuan,
This patch is OK for trunk. Thank you for your many clarifications.
Will you need one of us to apply this to trunk on your behalf?
If you would like me to apply your patch, please provide the full ChangeLog
with author information, like so:
2019-04-03 James Greenhalgh
Second Author
Third Author
* config/aarch64/aarch64-cores.def (tsv1100): Change scheduling model.
* config/aarch64/aarch64.md : Add "tsv110.md"
* config/aarch64/tsv110.md: New file.
Thanks,
James
> -邮件原件-
> 发件人: wuyuan (E)
> 发送时间: 2019年3月15日 21:57
> 收件人: 'James Greenhalgh'
> 抄送: Kyrill Tkachov ; gcc-patches@gcc.gnu.org;
> Zhangyichao (AB) ; Zhanghaijian (A)
> ; nd ; wufeng (O)
> ; Yangfei (Felix)
> 主题: Re : add tsv110 pipeline scheduling
>
> Hi , James:
> Thank you very much for your meticulous review work. The explanation of
> the two questions as follows:
> The first problem is caused by my negligence and should be changed to "
> crypto_sha256_fast" .
> The second question I have verified with the hardware engineer. Only
> ALU2/ALU3 could support PSTATE register update so any instruction intends to
> update NZCV will be issued to ALU2/ALU3. MDU could provide a better
> pipeline efficiency for multi cycle ALU instruction so we issue 2 cycles ALU
> w/o PSTATE update to MDU unit. the current pipeline processing is ok ,
> except the pipeline " tsv110_alu2" should replace with " tsv110_alu2|
> tsv110_alu3".
>
>
>
>
> The detailed patches are as follows:
>
> * config/aarch64/aarch64-cores.def (tsv1100): Change scheduling model.
> * config/aarch64/aarch64.md : Add "tsv110.md"
> * config/aarch64/tsv110.md: New file.
>
>
> diff --git a/gcc/config/aarch64/aarch64-cores.def
> b/gcc/config/aarch64/aarch64-cores.def
> index ed56e5e..82d91d6
> --- a/gcc/config/aarch64/aarch64-cores.def
> +++ b/gcc/config/aarch64/aarch64-cores.def
> @@ -105,7 +105,7 @@ AARCH64_CORE("neoverse-n1", neoversen1, cortexa57, 8_2A,
> AARCH64_FL_FOR_ARCH8_ AARCH64_CORE("neoverse-e1", neoversee1, cortexa53,
> 8_2A, AARCH64_FL_FOR_ARCH8_2 | AARCH64_FL_F16 | AARCH64_FL_RCPC |
> AARCH64_FL_DOTPROD | AARCH64_FL_SSBS, cortexa53, 0x41, 0xd4a, -1)
>
> /* HiSilicon ('H') cores. */
> -AARCH64_CORE("tsv110", tsv110, cortexa57, 8_2A, AARCH64_FL_FOR_ARCH8_2 |
> AARCH64_FL_CRYPTO | AARCH64_FL_F16 | AARCH64_FL_AES | AARCH64_FL_SHA2,
> tsv110, 0x48, 0xd01, -1)
> +AARCH64_CORE("tsv110", tsv110, tsv110, 8_2A, AARCH64_FL_FOR_ARCH8_2 |
> AARCH64_FL_CRYPTO | AARCH64_FL_F16 | AARCH64_FL_AES | AARCH64_FL_SHA2,
> tsv110, 0x48, 0xd01, -1)
>
> /* ARMv8.4-A Architecture Processors. */
>
> diff --git a/gcc/config/aarch64/aarch64.md b/gcc/config/aarch64/aarch64.md
> index b7cd9fc..861f059 100644
> --- a/gcc/config/aarch64/aarch64.md
> +++ b/gcc/config/aarch64/aarch64.md
> @@ -361,6 +361,7 @@
> (include "thunderx.md")
> (include "../arm/xgene1.md")
> (include "thunderx2t99.md")
> +(include "tsv110.md")
>
> ;; ---
> ;; Jumps and other miscellaneous insns
> diff --git a/gcc/config/aarch64/tsv110.md b/gcc/config/aarch64/tsv110.md new
> file mode 100644 index 000..9d12839
> --- /dev/null
> +++ b/gcc/config/aarch64/tsv110.md
> @@ -0,0 +1,708 @@
> +;; tsv110 pipeline description
> +;; Copyright (C) 2018 Free Software Foundation, Inc.
> +;;
> +;; This file is part of GCC.
> +;;
> +;; GCC is free software; you can redistribute it and/or modify it ;;
> +under the terms of the GNU General Public License as published by ;;
> +the Free Software Foundation; either version 3, or (at your option) ;;
> +any later version.
> +;;
> +;; GCC is distributed in the hope that it will be useful, but ;;
> +WITHOUT ANY WARRANTY; without even the implied warranty of ;;
> +MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU ;;
> +General Public License for more details.
> +;;
> +;; You should have received a copy of the GNU General Public License ;;
> +along with GCC; see the file COPYING3. If not see ;;
> +
Re: [PATCH,AIX] disables -flto on Go tests for AIX
On Mon, Apr 1, 2019 at 12:49 AM CHIGOT, CLEMENT wrote:
>
> Description:
> * This patches disables go tests with -flto on AIX.
>
> Tests:
> * AIX 7.2: Configure/Build: SUCCESS
>
> Changelog:
> * lib/go-torture.exp: add check for lto option
Thanks. I moved the adjustment up into the block where
TORTURE_OPTIONS was not already set, and committed as follows.
Ian
2019-04-03 Clément Chigot
* lib/go-torture.exp: Only add lto to TORTURE_OPTIONS if it is
supported.
Index: lib/go-torture.exp
===
--- lib/go-torture.exp (revision 269805)
+++ lib/go-torture.exp (working copy)
@@ -34,10 +34,13 @@ if ![info exists TORTURE_OPTIONS] {
{ -O2 -fomit-frame-pointer -finline-functions -funroll-loops } \
{ -O2 -fbounds-check } \
{ -O3 -g } \
- { -Os } \
- { -flto }]
-}
+ { -Os }]
+if [check_effective_target_lto] {
+ set TORTURE_OPTIONS \
+ [concat $TORTURE_OPTIONS [list {-flto}]]
+}
+}
#
# go-torture-compile -- compile a go.go-torture testcase.
Re: [PATCH] Fix PR71598, aliasing between enums and compatible types
On Wed, Apr 3, 2019 at 6:19 AM Christophe Lyon wrote: > > Thanks, here is what I have committed as r270126. > (skip one test on short_enums targets, skip the other one on > non-short_enums targets) I noticed that your testsuite/ChangeLog entry is marked 2019-04-13, but it should perhaps be 2019-04-03. Ian
Re: [Patch fortran] PR 68567 - ICE on using wrong defined arrays (different cases/messages)
On Wed, Apr 03, 2019 at 05:01:42PM +0200, Dominique d'Humières wrote: > Hi Steve, > > Do you agree with the following packaging of your patch for pr68567? > I honestly don't remember why I did not submit the patch to the list. If it fixes the bug and regression tests cleanly, then I won't object to committing the patch. -- Steve
[PATCH] avoid an other ICE due to invalid built-in call (PR 89934)
PR 89934 reports yet another ICE due to a call to a library
built-in function with invalid arguments. The attached patch
does the bare minimum to avoid it. I will commit it to trunk
and to GCC 8 later this week if there are no objections.
Martin
PS There have been many of these reports (at least three in
the wrestrict pass alone, and quite a few elsewhere). Simply
avoiding the ICEs as this patch does and as all the others
before it have done as well does nothing to help solve
the underlying problem in user code: the invalid calls will
end up with undefined behavior if they are ever made at runtime.
For example, the one in this bug report will most likely cause
data corruption or buffer overflow without ever being detected
by _FORTIFY_SOURCE. That seems far worse than failing to compile
the code (either with an ICE or with some
other hard error).
For GCC 10 I think a more robust solution should be put in place
not just to prevent these invalid built-in calls from tripping
up the middle-end, but also to avoid the undefined behavior at
runtime. The calls could either be rejected with an error as
Clang does, or they could be replaced them with __builtin_trap
or perhaps __builtin_unreachable, depending on some command
line option.
PR middle-end/89934 - ICE on a call with fewer arguments to strncpy declared without prototype
gcc/ChangeLog:
PR middle-end/89934
* gimple-ssa-warn-restrict.c (builtin_access::builtin_access): Bail
out if the number of arguments is less than expected.
gcc/testsuite/ChangeLog:
PR middle-end/89934
* gcc.dg/Wrestrict-19.c: New test.
* gcc.dg/Wrestrict-5.c: Add comment. Remove unused code.
Index: gcc/gimple-ssa-warn-restrict.c
===
--- gcc/gimple-ssa-warn-restrict.c (revision 270061)
+++ gcc/gimple-ssa-warn-restrict.c (working copy)
@@ -730,6 +730,10 @@ builtin_access::builtin_access (gimple *call, buil
offset_int bounds[2] = { maxobjsize, maxobjsize };
if (dstref->strbounded_p)
{
+ unsigned nargs = gimple_call_num_args (call);
+ if (nargs <= sizeargno)
+ return;
+
tree size = gimple_call_arg (call, sizeargno);
tree range[2];
if (get_size_range (size, range, true))
Index: gcc/testsuite/gcc.dg/Wrestrict-19.c
===
--- gcc/testsuite/gcc.dg/Wrestrict-19.c (nonexistent)
+++ gcc/testsuite/gcc.dg/Wrestrict-19.c (working copy)
@@ -0,0 +1,33 @@
+/* PR middle-end/89934 - ICE on a call with fewer arguments to strncpy
+ declared without prototype
+ { dg-do compile }
+ { dg-options "-O2 -Wall" } */
+
+typedef __SIZE_TYPE__ size_t;
+
+char *strncpy ();
+
+char* f0 (char *s)
+{
+ return strncpy ();
+}
+
+char* f1 (char *s)
+{
+ return strncpy (s);
+}
+
+char* f2 (char *s)
+{
+ return strncpy (s, s + 1); /* ICE here. */
+}
+
+void f3 (char *s, size_t n, const char *t)
+{
+ strncpy (s, n, t);
+ strncpy (n, s, t);
+}
+
+/* { dg-prune-output "\\\[-Wbuiltin-declaration-mismatch]" }
+ { dg-prune-output "\\\[-Wint-conversion]" } */
+
Index: gcc/testsuite/gcc.dg/Wrestrict-5.c
===
--- gcc/testsuite/gcc.dg/Wrestrict-5.c (revision 270061)
+++ gcc/testsuite/gcc.dg/Wrestrict-5.c (working copy)
@@ -1,20 +1,11 @@
-/* Test to verify that valid calls to common restrict-qualified built-in
+/* PR tree-optimization/83655 - ICE on an invalid call to memcpy declared
+ with no prototype
+ Test to verify that valid calls to common restrict-qualified built-in
functions declared with no prototype are checked for overlap, and that
invalid calls are ignored.
{ dg-do compile }
- { dg-prune-output "conflicting types for built-in" }
{ dg-options "-O2 -Wrestrict" } */
-typedef __SIZE_TYPE__ size_t;
-
-#if __cplusplus
-extern "C" {
-
-#define NO_PROTO ...
-#else
-#define NO_PROTO /* empty */
-#endif
-
void* memcpy ();
char* strncpy ();
[C++ PATCH] PR c++/89331 - ICE with offsetof in incomplete class.
We were aborting when build_base_path returned an error because of the
derived class not being complete yet, which wasn't considered by the assert.
Fixed by checking for complete type first. The semantics.c change avoids
a duplicate error message.
Tested x86_64-pc-linux-gnu, applying to trunk.
* semantics.c (finish_offsetof): Handle error_mark_node.
* typeck.c (build_class_member_access_expr): Call
complete_type_or_maybe_complain before converting to base.
---
gcc/cp/semantics.c | 3 +++
gcc/cp/typeck.c | 8
gcc/testsuite/g++.dg/ext/builtin-offsetof4.C | 11 +++
gcc/testsuite/g++.dg/other/offsetof8.C | 2 +-
gcc/cp/ChangeLog | 5 +
5 files changed, 28 insertions(+), 1 deletion(-)
create mode 100644 gcc/testsuite/g++.dg/ext/builtin-offsetof4.C
diff --git a/gcc/cp/semantics.c b/gcc/cp/semantics.c
index a08a2a57f5f..408675b8099 100644
--- a/gcc/cp/semantics.c
+++ b/gcc/cp/semantics.c
@@ -4144,6 +4144,9 @@ finish_offsetof (tree object_ptr, tree expr, location_t
loc)
return expr;
}
+ if (expr == error_mark_node)
+return error_mark_node;
+
if (TREE_CODE (expr) == PSEUDO_DTOR_EXPR)
{
error ("cannot apply % to destructor %<~%T%>",
diff --git a/gcc/cp/typeck.c b/gcc/cp/typeck.c
index a00b0f48b69..56def144a3e 100644
--- a/gcc/cp/typeck.c
+++ b/gcc/cp/typeck.c
@@ -2474,6 +2474,14 @@ build_class_member_access_expr (cp_expr object, tree
member,
tree binfo;
base_kind kind;
+ /* We didn't complain above about a currently open class, but now we
+must: we don't know how to refer to a base member before layout is
+complete. But still don't complain in a template. */
+ if (!dependent_type_p (object_type)
+ && !complete_type_or_maybe_complain (object_type, object,
+ complain))
+ return error_mark_node;
+
binfo = lookup_base (access_path ? access_path : object_type,
member_scope, ba_unique, &kind, complain);
if (binfo == error_mark_node)
diff --git a/gcc/testsuite/g++.dg/ext/builtin-offsetof4.C
b/gcc/testsuite/g++.dg/ext/builtin-offsetof4.C
new file mode 100644
index 000..b30c31dbfa9
--- /dev/null
+++ b/gcc/testsuite/g++.dg/ext/builtin-offsetof4.C
@@ -0,0 +1,11 @@
+// PR c++/89331
+
+class A {
+public:
+char a;
+};
+
+class B : public A {
+public:
+static const unsigned b = __builtin_offsetof(B, a); // { dg-error
"incomplete" }
+};
diff --git a/gcc/testsuite/g++.dg/other/offsetof8.C
b/gcc/testsuite/g++.dg/other/offsetof8.C
index 211c5127026..daca70a6fe4 100644
--- a/gcc/testsuite/g++.dg/other/offsetof8.C
+++ b/gcc/testsuite/g++.dg/other/offsetof8.C
@@ -9,4 +9,4 @@ struct B: virtual A { };
int a[] = {
!&((B*)0)->i,// { dg-error "invalid access to non-static data member" }
__builtin_offsetof (B, i) // { dg-error "invalid access to non-static" }
-}; // { dg-message "offsetof within
non-standard-layout type" "" { target *-*-* } .-1 }
+};
diff --git a/gcc/cp/ChangeLog b/gcc/cp/ChangeLog
index bb719133a97..a224517b566 100644
--- a/gcc/cp/ChangeLog
+++ b/gcc/cp/ChangeLog
@@ -1,5 +1,10 @@
2019-04-03 Jason Merrill
+ PR c++/89331 - ICE with offsetof in incomplete class.
+ * semantics.c (finish_offsetof): Handle error_mark_node.
+ * typeck.c (build_class_member_access_expr): Call
+ complete_type_or_maybe_complain before converting to base.
+
PR c++/89917 - ICE with lambda in variadic mem-init.
* pt.c (make_pack_expansion): Change type_pack_expansion_p to false.
base-commit: 9939b2f79bd9b75b99080a17f3d6f1214d543477
--
2.20.1
[PATCH] PR c++/86586 - -fcompare-debug=-Wsign-compare.
This patch limits constexpr folding for -Wsign-compare to only cases that we
would warn for without considering constant values, avoiding the folding in
the testcase in question.
Tested x86_64-pc-linux-gnu, applying to trunk.
gcc/c-family/
* c-warn.c (warn_for_sign_compare): Call fold_for_warn.
gcc/cp/
* typeck.c (cp_build_binary_op): Don't fold for -Wsign-compare.
---
gcc/c-family/c-warn.c | 3 +++
gcc/cp/typeck.c | 9 +
gcc/testsuite/g++.target/i386/mv1.C | 2 +-
gcc/c-family/ChangeLog | 5 +
gcc/cp/ChangeLog| 3 +++
5 files changed, 13 insertions(+), 9 deletions(-)
diff --git a/gcc/c-family/c-warn.c b/gcc/c-family/c-warn.c
index d775ff80b45..4785887c1de 100644
--- a/gcc/c-family/c-warn.c
+++ b/gcc/c-family/c-warn.c
@@ -2073,6 +2073,9 @@ warn_for_sign_compare (location_t location,
else
sop = orig_op1, uop = orig_op0;
+ sop = fold_for_warn (sop);
+ uop = fold_for_warn (uop);
+
STRIP_TYPE_NOPS (sop);
STRIP_TYPE_NOPS (uop);
base_type = (TREE_CODE (result_type) == COMPLEX_TYPE
diff --git a/gcc/cp/typeck.c b/gcc/cp/typeck.c
index 56def144a3e..03b14024738 100644
--- a/gcc/cp/typeck.c
+++ b/gcc/cp/typeck.c
@@ -5486,14 +5486,7 @@ cp_build_binary_op (const op_location_t &location,
&& !enum_cast_to_int (orig_op0)
&& !enum_cast_to_int (orig_op1))
{
- tree oop0 = maybe_constant_value (orig_op0);
- tree oop1 = maybe_constant_value (orig_op1);
-
- if (TREE_CODE (oop0) != INTEGER_CST)
- oop0 = cp_fully_fold (orig_op0);
- if (TREE_CODE (oop1) != INTEGER_CST)
- oop1 = cp_fully_fold (orig_op1);
- warn_for_sign_compare (location, oop0, oop1, op0, op1,
+ warn_for_sign_compare (location, orig_op0, orig_op1, op0, op1,
result_type, resultcode);
}
}
diff --git a/gcc/testsuite/g++.target/i386/mv1.C
b/gcc/testsuite/g++.target/i386/mv1.C
index fc713477c1e..9e368506196 100644
--- a/gcc/testsuite/g++.target/i386/mv1.C
+++ b/gcc/testsuite/g++.target/i386/mv1.C
@@ -1,7 +1,7 @@
/* Test case to check if Multiversioning works. */
/* { dg-do run } */
/* { dg-require-ifunc "" } */
-/* { dg-options "-O2 -fPIC" } */
+/* { dg-options "-O2 -fPIC -fcompare-debug=-Wsign-compare" } */
#include
diff --git a/gcc/c-family/ChangeLog b/gcc/c-family/ChangeLog
index cf73a1cad1c..ae6b8a7094d 100644
--- a/gcc/c-family/ChangeLog
+++ b/gcc/c-family/ChangeLog
@@ -1,3 +1,8 @@
+2019-04-03 Jason Merrill
+
+ PR c++/86586 - -fcompare-debug=-Wsign-compare.
+ * c-warn.c (warn_for_sign_compare): Call fold_for_warn.
+
2019-04-01 Martin Sebor
PR c/89685
diff --git a/gcc/cp/ChangeLog b/gcc/cp/ChangeLog
index a224517b566..91d14311f18 100644
--- a/gcc/cp/ChangeLog
+++ b/gcc/cp/ChangeLog
@@ -1,5 +1,8 @@
2019-04-03 Jason Merrill
+ PR c++/86586 - -fcompare-debug=-Wsign-compare.
+ * typeck.c (cp_build_binary_op): Don't fold for -Wsign-compare.
+
PR c++/89331 - ICE with offsetof in incomplete class.
* semantics.c (finish_offsetof): Handle error_mark_node.
* typeck.c (build_class_member_access_expr): Call
base-commit: 4c246688d98b0acfd6bf8579026e3cc79eae1951
--
2.20.1
Re: [PATCH] PR libstdc++/87431 re-adjust never-valueless optimizations
Looks good. Covers most of the use cases.
Please consider adding filesystem::path, pair, tuple, string_view?,
error_code, list, deque (myabe all the other containers), optional, variant
itself (for cases when variant holds another variant).
It would be very useful for the _Never_valueless_alt to return true for
aggregates that hold only never valueles types. Not sure that there is a
compiler builtin for getting all the aggregates types, but it could be
implemented via metaprogramming.
When is the ABI freeze for the C++17 additions?
On Wed, Apr 3, 2019, 19:25 Jonathan Wakely wrote:
> Avoid creating arbitrarily large objects on the stack when creating
> temporaries in order to provide the strong exception-safety guarantee.
>
> Also implement Antony Polukhin's suggestion to whitelist specific types
> that can be efficiently move-assigned, so that emplacing those types
> never causes a variant to become valueless. The whitelisted types are:
> all trivially copyable types no greater than 256 bytes in size,
> std::shared_ptr, std::weak_ptr, std::unique_ptr, std::function, and
> std::any. Additionally, std::basic_string, std::vector, and
> __gnu_debug::vector are whitelisted if their allocator traits give them
> a non-throwing move assignment operator. Specifically, this means
> std::string is whitelisted, but std::pmr::string is not.
>
> PR libstdc++/87431 (again)
> * include/bits/basic_string.h (__variant::_Never_valueless_alt):
> Define partial specialization for basic_string.
> * include/bits/shared_ptr.h (_Never_valueless_alt): Likewise for
> shared_ptr and weak_ptr.
> * include/bits/std_function.h (_Never_valueless_alt): Likewise for
> function.
> * include/bits/stl_vector.h (_Never_valueless_alt): Likewise for
> vector.
> * include/bits/unique_ptr.h (_Never_valueless_alt): Likewise for
> unique_ptr.
> * include/debug/vector (_Never_valueless_alt): Likewise for debug
> vector.
> * include/std/any (_Never_valueless_alt): Define explicit
> specialization for any.
> * include/std/variant (_Never_valueless_alt): Define primary
> template.
> (__never_valueless): Use _Never_valueless_alt instead of
> is_trivially_copyable.
> (variant::emplace(Args&&...)): Add special case for non-throwing
> initializations to avoid try-catch overhead. Add special case for
> scalars produced by potentially-throwing conversions. Use
> _Never_valueless_alt instead of is_trivially_copyable for the
> remaining strong exception-safety cases.
> (variant::emplace(initializer_list, Args&&...)): Likewise.
> * testsuite/20_util/variant/87431.cc: Run both test functions.
> * testsuite/20_util/variant/exception_safety.cc: New test.
> * testsuite/20_util/variant/run.cc: Use pmr::string instead of
> string,
> so the variant becomes valueless.
>
> I'd like to commit this to trunk this week. Does anybody see any
> problems with this approach?
>
> As the comment in says, the _Never_valueless_alt trait has
> ABI impact, so we should define it for more types now, or not at all.
> When we add new types to the library we should consider if they need a
> specialization of _Never_valueless_alt.
>
> Should we also whitelist some (all?) other containers, as they all
> have conditionally noexcept move assignment operators, and those
> assignments are efficient when noexcept (because they don't
> reallocate). Are there other types in the library we should consider
> it for?
>
> std::optional is automatically whitelisted for trivially copyable
> types, because if T is trivially copyable then optional should be
> too. We could also whitelist other specializations though:
>
> template
> struct _Never_valueless_alt>
> : _Never_valueless_alt
> { };
>
> We could also do:
>
> template
> struct _Never_valueless_alt>
> : __and_<_Never_valueless_alt, _Never_valueless_alt>
> { };
>
> template
> struct _Never_valueless_alt>
> : __and_<_Never_valueless_alt...>
> { };
>
> In case it isn't clear, under normal circumstances something like a
> variant,int> won't ever become valueless anyway, because
> initialization of those alternatives doesn't throw. But what can throw
> is a conversion operator that is invoked to produce one of those
> alternatives. The _Never_valueless_alt trait says that emplacing an
> alternative of that type should do some extra work to ensure the
> variant doesn't become valueless *ever*. And then a variant that only
> has never-valueless alternatives is itself never-valueless, and so the
> valueless_by_exception() member just returns false, and visitation is
> more efficient as it doesn't need to deal with the valueless state.
>
>
Re: [PATCH] PR libstdc++/87431 re-adjust never-valueless optimizations
On Wed, 3 Apr 2019 at 23:32, Antony Polukhin wrote: > > Looks good. Covers most of the use cases. > > Please consider adding filesystem::path, pair, tuple, string_view?, > error_code, list, deque (myabe all the other containers), optional, variant > itself (for cases when variant holds another variant). > > It would be very useful for the _Never_valueless_alt to return true for > aggregates that hold only never valueles types. Not sure that there is a > compiler builtin for getting all the aggregates types, but it could be > implemented via metaprogramming. What metaprogram is capable of that? > When is the ABI freeze for the C++17 additions? This approach concerns me; it's a "get it right at the first chance and then never change it", which is.. ..awkward. But I don't know whether there's any way around that.
[committed] [Patch, fortran] PR 89375 fortran/expr.c:4723:5: warning: logical ‘or’ of equal expressions [-Wlogical-op]
Committed as obvious at revision r270115: 2019-04-03 Dominique d'Humieres PR fortran/89375 * expr.c (comp_pointer): Remove redundant condition. Dominique
Re: [Patch fortran] PR 68567 - ICE on using wrong defined arrays (different cases/messages)
Thanks for the quick answer. Committed as revision r270137. Dominique > Le 3 avr. 2019 à 21:15, Steve Kargl a > écrit : > > On Wed, Apr 03, 2019 at 05:01:42PM +0200, Dominique d'Humières wrote: >> Hi Steve, >> >> Do you agree with the following packaging of your patch for pr68567? >> > > I honestly don't remember why I did not submit the patch to the list. > If it fixes the bug and regression tests cleanly, then I won't object > to committing the patch. > > -- > Steve
[C++ PATCH] PR c++/81866 - ICE with member template and default targ.
This testcase manages to find a way to look up the partial instantiation of
B for the default argument of C before we've created the partial
instantiation of B as part of the normal instantiation of the members of A.
Which we can deal with, but we were getting confused because the partial
instantiation was stored with a RECORD_TYPE specialization rather than
TEMPLATE_DECL.
Tested x86_64-pc-linux-gnu, applying to trunk.
* pt.c (tsubst_template_decl): Handle getting a type from
retrieve_specialization.
---
gcc/cp/pt.c | 8 +++-
gcc/testsuite/g++.dg/template/memtmpl6.C | 13 +
gcc/cp/ChangeLog | 4
3 files changed, 24 insertions(+), 1 deletion(-)
create mode 100644 gcc/testsuite/g++.dg/template/memtmpl6.C
diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 2b92b608f5d..9cb29d22ca3 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -13266,7 +13266,13 @@ tsubst_template_decl (tree t, tree args,
tsubst_flags_t complain,
hash = hash_tmpl_and_args (t, full_args);
spec = retrieve_specialization (t, full_args, hash);
if (spec != NULL_TREE)
- return spec;
+ {
+ if (TYPE_P (spec))
+ /* Type partial instantiations are stored as the type by
+ lookup_template_class_1, not here as the template. */
+ spec = CLASSTYPE_TI_TEMPLATE (spec);
+ return spec;
+ }
}
/* Make a new template decl. It will be similar to the
diff --git a/gcc/testsuite/g++.dg/template/memtmpl6.C
b/gcc/testsuite/g++.dg/template/memtmpl6.C
new file mode 100644
index 000..9ce35abfc4e
--- /dev/null
+++ b/gcc/testsuite/g++.dg/template/memtmpl6.C
@@ -0,0 +1,13 @@
+// PR c++/81866
+
+template
+struct A {
+ template struct C;
+ template struct B;
+ template > struct C {};
+};
+
+int main() {
+ A::C<> ac;
+ return 0;
+}
diff --git a/gcc/cp/ChangeLog b/gcc/cp/ChangeLog
index 91d14311f18..888b431e099 100644
--- a/gcc/cp/ChangeLog
+++ b/gcc/cp/ChangeLog
@@ -1,5 +1,9 @@
2019-04-03 Jason Merrill
+ PR c++/81866 - ICE with member template and default targ.
+ * pt.c (tsubst_template_decl): Handle getting a type from
+ retrieve_specialization.
+
PR c++/86586 - -fcompare-debug=-Wsign-compare.
* typeck.c (cp_build_binary_op): Don't fold for -Wsign-compare.
base-commit: b3902d2e4fe4c7c1b04a92ae1e0a4959d7df1574
--
2.20.1
[PING] [PATCH V3] PR88497 - Extend reassoc for vector bit_field_ref
Hi, Gentle ping for this patch: https://gcc.gnu.org/ml/gcc-patches/2019-03/msg00966.html Thanks! on 2019/3/19 上午11:14, Kewen.Lin wrote: > Hi, > > Please refer to below link for previous threads. > https://gcc.gnu.org/ml/gcc-patches/2019-03/msg00348.html > > Comparing to patch v2, I've moved up the vector operation target > check upward together with vector type target check. Besides, I > ran bootstrap and regtest on powerpc64-linux-gnu (BE), updated > testcases' requirements and options for robustness. > > Is it OK for GCC10? > > > gcc/ChangeLog > > 2019-03-20 Kewen Lin > > PR target/88497 > * tree-ssa-reassoc.c (reassociate_bb): Swap the positions of > GIMPLE_BINARY_RHS check and gimple_visited_p check, call new > function undistribute_bitref_for_vector. > (undistribute_bitref_for_vector): New function. > (cleanup_vinfo_map): Likewise. > (unsigned_cmp): Likewise. > > gcc/testsuite/ChangeLog > > 2019-03-20 Kewen Lin > > * gcc.dg/tree-ssa/pr88497-1.c: New test. > * gcc.dg/tree-ssa/pr88497-2.c: Likewise. > * gcc.dg/tree-ssa/pr88497-3.c: Likewise. > * gcc.dg/tree-ssa/pr88497-4.c: Likewise. > * gcc.dg/tree-ssa/pr88497-5.c: Likewise. >
Re: [PATCH] PR libstdc++/87431 re-adjust never-valueless optimizations
On 03/04/19 23:32 +0300, Antony Polukhin wrote: Looks good. Covers most of the use cases. Please consider adding filesystem::path, pair, tuple, string_view?, string_view is trivially_copyable, and < 256 bytes, so works automatically. error_code, list, deque (myabe all the other containers), optional, variant itself (for cases when variant holds another variant). I hadn't thought about error_code and recursive variants, I'll check those can be made to work. filesystem::path had occurred to me, but I'm undecided. pair, tuple and optional I think can be done as shown in my email. It would be very useful for the _Never_valueless_alt to return true for aggregates that hold only never valueles types. Not sure that there is a compiler builtin for getting all the aggregates types, but it could be implemented via metaprogramming. Useful, but not essential. This is a Quality of Implementation issue, and the cases where an exception actually gets thrown and leaves the variant valueless are going to be rare anyway. The codegen benefits of being never-valueless are minor. So I don't think we need to go too wild doing this. When is the ABI freeze for the C++17 additions? The GCC 9 release, ideally.
Re: [PATCH] PR libstdc++/87431 re-adjust never-valueless optimizations
On 03/04/19 23:39 +0300, Ville Voutilainen wrote: On Wed, 3 Apr 2019 at 23:32, Antony Polukhin wrote: Looks good. Covers most of the use cases. Please consider adding filesystem::path, pair, tuple, string_view?, error_code, list, deque (myabe all the other containers), optional, variant itself (for cases when variant holds another variant). It would be very useful for the _Never_valueless_alt to return true for aggregates that hold only never valueles types. Not sure that there is a compiler builtin for getting all the aggregates types, but it could be implemented via metaprogramming. What metaprogram is capable of that? I think it would need a compiler builtin like __bases and __direct_bases, which we don't have (and couldn't use unless it was already implemented in every compiler that uses libstdc++). When is the ABI freeze for the C++17 additions? This approach concerns me; it's a "get it right at the first chance and then never change it", which is.. ..awkward. But I don't know whether there's any way around that. To some extent that's the case every time we declare something non-experimental. There are things I'd change about std::__cxx11::string if I was doing that again, but we're stuck with what we have. At least for these never-valueless variants it's just a QoI optimization, and if we don't make it work for every possible type it doesn't matter much.
Re : add tsv110 pipeline scheduling
Hi ,James:
Thank you for your review, Please attach the following author
information to the patch.
2019-04-04 wu yuan
* config/aarch64/aarch64-cores.def (tsv1100): Change scheduling model.
* config/aarch64/aarch64.md : Add "tsv110.md"
* config/aarch64/tsv110.md: New file.
Thanks,
wuyuan
-邮件原件-
发件人: James Greenhalgh [mailto:james.greenha...@arm.com]
发送时间: 2019年4月4日 1:58
收件人: wuyuan (E)
抄送: Kyrill Tkachov ; gcc-patches@gcc.gnu.org;
Zhangyichao (AB) ; Zhanghaijian (A)
; nd
主题: Re: Re : add tsv110 pipeline scheduling
On Tue, Apr 02, 2019 at 03:26:22PM +0100, wuyuan (E) wrote:
> Hi ,James:
> Has the submitted patch been merged into the trunk? Looking forward to your
> reply , thank you very much!
>
>
>
> Best Regards,
>
> wuyuan
Hi Wuyuan,
This patch is OK for trunk. Thank you for your many clarifications.
Will you need one of us to apply this to trunk on your behalf?
If you would like me to apply your patch, please provide the full ChangeLog
with author information, like so:
2019-04-03 James Greenhalgh
Second Author
Third Author
* config/aarch64/aarch64-cores.def (tsv1100): Change scheduling model.
* config/aarch64/aarch64.md : Add "tsv110.md"
* config/aarch64/tsv110.md: New file.
Thanks,
James
> -邮件原件-
> 发件人: wuyuan (E)
> 发送时间: 2019年3月15日 21:57
> 收件人: 'James Greenhalgh'
> 抄送: Kyrill Tkachov ;
> gcc-patches@gcc.gnu.org; Zhangyichao (AB)
> ; Zhanghaijian (A)
> ; nd ; wufeng (O)
> ; Yangfei (Felix)
> 主题: Re : add tsv110 pipeline scheduling
>
> Hi , James:
> Thank you very much for your meticulous review work. The explanation of
> the two questions as follows:
> The first problem is caused by my negligence and should be changed to "
> crypto_sha256_fast" .
> The second question I have verified with the hardware engineer. Only
> ALU2/ALU3 could support PSTATE register update so any instruction intends to
> update NZCV will be issued to ALU2/ALU3. MDU could provide a better
> pipeline efficiency for multi cycle ALU instruction so we issue 2 cycles ALU
> w/o PSTATE update to MDU unit. the current pipeline processing is ok ,
> except the pipeline " tsv110_alu2" should replace with " tsv110_alu2|
> tsv110_alu3".
>
>
>
>
> The detailed patches are as follows:
>
> * config/aarch64/aarch64-cores.def (tsv1100): Change scheduling model.
> * config/aarch64/aarch64.md : Add "tsv110.md"
> * config/aarch64/tsv110.md: New file.
>
>
> diff --git a/gcc/config/aarch64/aarch64-cores.def
> b/gcc/config/aarch64/aarch64-cores.def
> index ed56e5e..82d91d6
> --- a/gcc/config/aarch64/aarch64-cores.def
> +++ b/gcc/config/aarch64/aarch64-cores.def
> @@ -105,7 +105,7 @@ AARCH64_CORE("neoverse-n1", neoversen1,
> cortexa57, 8_2A, AARCH64_FL_FOR_ARCH8_ AARCH64_CORE("neoverse-e1",
> neoversee1, cortexa53, 8_2A, AARCH64_FL_FOR_ARCH8_2 | AARCH64_FL_F16
> | AARCH64_FL_RCPC | AARCH64_FL_DOTPROD | AARCH64_FL_SSBS, cortexa53,
> 0x41, 0xd4a, -1)
>
> /* HiSilicon ('H') cores. */
> -AARCH64_CORE("tsv110", tsv110, cortexa57, 8_2A, AARCH64_FL_FOR_ARCH8_2 |
> AARCH64_FL_CRYPTO | AARCH64_FL_F16 | AARCH64_FL_AES | AARCH64_FL_SHA2,
> tsv110, 0x48, 0xd01, -1)
> +AARCH64_CORE("tsv110", tsv110, tsv110, 8_2A, AARCH64_FL_FOR_ARCH8_2 |
> AARCH64_FL_CRYPTO | AARCH64_FL_F16 | AARCH64_FL_AES | AARCH64_FL_SHA2,
> tsv110, 0x48, 0xd01, -1)
>
> /* ARMv8.4-A Architecture Processors. */
>
> diff --git a/gcc/config/aarch64/aarch64.md
> b/gcc/config/aarch64/aarch64.md index b7cd9fc..861f059 100644
> --- a/gcc/config/aarch64/aarch64.md
> +++ b/gcc/config/aarch64/aarch64.md
> @@ -361,6 +361,7 @@
> (include "thunderx.md")
> (include "../arm/xgene1.md")
> (include "thunderx2t99.md")
> +(include "tsv110.md")
>
> ;;
> ---
> ;; Jumps and other miscellaneous insns diff --git
> a/gcc/config/aarch64/tsv110.md b/gcc/config/aarch64/tsv110.md new file
> mode 100644 index 000..9d12839
> --- /dev/null
> +++ b/gcc/config/aarch64/tsv110.md
> @@ -0,0 +1,708 @@
> +;; tsv110 pipeline description
> +;; Copyright (C) 2018 Free Software Foundation, Inc.
> +;;
> +;; This file is part of GCC.
> +;;
> +;; GCC is free software; you can redistribute it a
Re: [PATCH] handle strings as template arguments (PR 47488, 89833, 89876)
On 4/1/19 11:27 AM, Jason Merrill wrote:
On 3/31/19 10:17 PM, Martin Sebor wrote:
To fix PR 89833, a P1 regression, the attached patch tries to
handle string literals as C++ 2a non-type template arguments
by treating them the same as brace enclosed initializer lists
(where the latter are handled correctly). The solution makes
sure equivalent forms of array initializers such as for char[5]:
"\0\1\2"
"\0\1\2\0"
{ 0, 1, 2 }
{ 0, 1, 2, 0 }
{ 0, 1, 2, 0, 0 }
are treated as the same, both for overloading and mangling.
Ditto for the following equivalent forms:
""
"\0"
"\0\0\0\0"
{ }
{ 0 }
{ 0, 0, 0, 0, 0 }
and for these of struct { char a[5], b[5], c[5]; }:
{ {0,0,0,0,0}, {0,0,0,0}, {0,0,0} }
{ { 0 }, { } }
{ "" }
Since this is not handled correctly by the current code (see PR
89876 for a test case) the patch also fixes that.
I'm not at all confident the handling of classes with user-defined
constexpr ctors is 100% correct. (I use triviality to constrain
the solution for strings but that was more of an off-the-cuff guess
than a carefully considered decision).
You could use TYPE_HAS_TRIVIAL_DFLT since we don't care about the
triviality of other operations.
Done (I think).
I wouldn't worry about trying to omit user-defined constexpr ctors.
The g++.dg/abi/mangle71.C
test is all I've got in terms of verifying it works correctly.
I'm quite sure the C++ 2a testing could stand to be beefed up.
The patch passes x86_64-linux bootstrap and regression tests.
There are a few failures in check-c++-all tests that don't look
related to the changes (I see them with an unpatched GCC as well):
g++.dg/spellcheck-macro-ordering-2.C
g++.dg/cpp0x/auto52.C
g++.dg/cpp1y/auto-neg1.C
g++.dg/other/crash-9.C
You probably need to check zero_init_p to properly handle pointers to
data members, where a null value is integer -1; given
struct A { int i; };
constexpr A::* pm = &A::i;
int A::* pma[] = { pm, pm };
we don't want to discard the initializers because they look like zeros,
as then digest_init will add back -1s.
I added it but it wasn't doing the right thing. It mangled { } and
{ 0 } differently:
typedef int A::*pam_t;
struct B { pam_t a[2]; };
template struct Y { };
void f (Y) { } // _Z1f1YIXtl1BtlA2_M1AiLS2_0E
void f (Y) { } // _Z1f1YIXtl1BtlA2_M1AiLS2_0ELS2_0E
because the zeros didn't get removed. They need to be mangled the same,
don't they?
I've added three tests to exercise this (array51.C, nontype-class16.C,
and mangle72.C). They pass without the zero_init_p() calls but some
fail with it (depending on where it's added). Please check to see
that the tests really do exercise what they should.
If you think a zero_init_p() check really is needed I will need some
guidance where (a test case would be great).
+ unsigned n = TREE_STRING_LENGTH (value);
+ const char *str = TREE_STRING_POINTER (value);
+ /* Count the number of trailing nuls and subtract them from
+ STRSIZE because they don't need to be mangled. */
+ tree strsizenode = TYPE_SIZE_UNIT (TREE_TYPE (value));
+ unsigned strsize = tree_to_uhwi (strsizenode);
+ if (strsize > n)
+ strsize = n;
Why not just use TREE_STRING_LENGTH?
The length reflects the size of the string literal, including
any trailing nuls (like in "x\0y\0\0"). We only want to mangle
the leading part up to (but not including) the first trailing
nul.
Attached is a patch adjusted to use TYPE_HAS_TRIVIAL_DFLT in
decl.c and with the three additional tests.
Martin
PR c++/89833 - sorry, unimplemented: string literal in function template signature
gcc/cp/ChangeLog:
PR c++/89833
* decl.c (reshape_init_array_1): Strip trailing zero-initializers
from arrays of trivial type and known size.
* mangle.c (write_expression): Convert braced initializer lists
to STRING_CSTs.
(write_expression): Trim trailing zero-initializers from arrays
of trivial type.
(write_template_arg_literal): Mangle strings the same as braced
initializer lists.
gcc/testsuite/ChangeLog:
* gcc/testsuite/g++.dg/abi/mangle69.C: New test.
* gcc/testsuite/g++.dg/abi/mangle70.C: New test.
* gcc/testsuite/g++.dg/abi/mangle71.C: New test.
* gcc/testsuite/g++.dg/abi/mangle72.C: New test.
* gcc/testsuite/g++.dg/cpp0x/constexpr-array19.C: New test.
* gcc/testsuite/g++.dg/cpp2a/nontype-class15.C: New test.
* gcc/testsuite/g++.dg/cpp2a/nontype-class16.C: New test.
* gcc/testsuite/g++.dg/init/array51.C: New test.
diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
index c46a39665bd..400e1a274aa 100644
--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -5799,6 +5799,9 @@ reshape_init_array_1 (tree elt_type, tree max_index, reshape_iter *d,
max_index_cst = tree_to_uhwi (fold_convert (size_type_node, max_index));
}
+ /* Set to the index of the last element with a non-zero initializer.
+ Initializers for elements past this one can be dropped. */
+
PR 89864 - gcc fails to build/bootstrap with XCode 10.2
Fixinclude the header file that incorrectly uses the C-only
_Atomic keyword when compiled as C++. Apply the same work-around for two
GCC source files that transitively use this header file.
Index: fixincludes/inclhack.def
===
--- fixincludes/inclhack.def (revision 270127)
+++ fixincludes/inclhack.def (working copy)
@@ -1298,6 +1298,36 @@ fix = {
};
/*
+ * macOS 10.14.4 uses the C _Atomic keyword in C++ code.
+ */
+fix = {
+hackname = darwin_ucred__Atomic;
+mach = "*-*-darwin18.5.*";
+files = sys/ucred.h;
+select= "_Atomic";
+
+c_fix = wrap;
+
+c_fix_arg = <<- _EOArg_
+
+ #if defined(__cplusplus) && __cplusplus >= 201103L
+ # define _Atomic volatile
+ #endif
+
+ _EOArg_;
+
+c_fix_arg = <<- _EOArg_
+
+ #if defined(__cplusplus) && __cplusplus >= 201103L
+ # undef _Atomic
+ #endif
+
+ _EOArg_;
+
+test_text = "#include \n";
+};
+
+/*
* For the AAB_darwin7_9_long_double_funcs fix to be useful,
* you have to not use "" includes.
*/
Index: gcc/config/darwin-driver.c
===
--- gcc/config/darwin-driver.c (revision 270127)
+++ gcc/config/darwin-driver.c (working copy)
@@ -27,7 +27,15 @@ along with GCC; see the file COPYING3.
#include "diagnostic-core.h"
#ifndef CROSS_DIRECTORY_STRUCTURE
+#if defined(__cplusplus) && __cplusplus >= 201103L
+// This is safe because it applies only to struct ucred, which is
+// not actually used by gcc.
+#define _Atomic volatile
+#endif
#include
+#if defined(__cplusplus) && __cplusplus >= 201103L
+#undef _Atomic
+#endif
#include "xregex.h"
static char *
Index: libsanitizer/sanitizer_common/sanitizer_mac.cc
===
--- libsanitizer/sanitizer_common/sanitizer_mac.cc (revision 270127)
+++ libsanitizer/sanitizer_common/sanitizer_mac.cc (working copy)
@@ -67,7 +67,13 @@ extern "C" {
#include
#include
#include
+#if defined(__cplusplus) && __cplusplus >= 201103L
+# define _Atomic volatile
+#endif
#include
+#if defined(__cplusplus) && __cplusplus >= 201103L
+# undef _Atomic
+#endif
#include
#include
#include
--
Erik Schnetter
http://www.perimeterinstitute.ca/personal/eschnetter/
Re: [wwwdoc][Patch] Mention Loongson 3a1000 3a2000 3a3000 2k1000 support in gcc9
Hi, This is a updated version, Ok for commit? On Thu, Jan 17, 2019 at 10:05 AM Paul Hua wrote: > > Hi Gerald, > > Updated version, please review. > > Thanks. > > On Mon, Jan 14, 2019 at 7:46 AM Gerald Pfeifer wrote: > > > > Hi Paul, > > > > On Mon, 31 Dec 2018, Paul Hua wrote: > > > The attached patch mention Loongson 3a1000 3a2000 3a3000 2k1000 support > > > in gcc9. > > > > thanks for putting this together. Only a couple of editorial changes: > > > > Index: changes.html > > === > > + > > +The Loongson loongson-mmi and loongson-ext > > +extension has now been splited from loongson3a: > > > > "...extensions have been split..." > > > > + > > + loongson-mmi which contains > > + the Loongson MultiMedia extension Instructions operations. > > + loongson-ext which contains > > + the Loongson EXTension instructions. > > > > Here I'd omit omit the two instances of "which" > > > > +The Loongson EXTension R2 instructions is now supported. > > > > "is" -> "are" > > > > +Use -mxxx or -mno-xxx will enable or disable those extersions. > > > > Since it's only two options, how about listing both of them? > > > > "extersion" -> "extension" > > > > +for example: Using > > -mloongson-mmi/-mno-loongson-mmi > > +will enable/disable Loongson MultiMedia Instructions extensions. > > > > "...the Loongson MultiMedia Instructions extension." > > > > + which default enable loongson-mmi, > > loongson-ext. > > > > "which enables ... by default" (also in the following two items) > > > > > > Please look into those comments and then simply post the updated patch > > as you're committing it. > > > > Gerald Index: htdocs/gcc-9/changes.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-9/changes.html,v retrieving revision 1.57 diff -r1.57 changes.html 822,823c822,859 < < --- > MIPS > > > The Loongson loongson-mmi and loongson-ext > extensions have been split from loongson3a: > >loongson-mmi contains >the Loongson MMI (MultiMedia extensions Instructions). >loongson-ext contains >the Loongson EXT (EXTensions instructions). > > > The Loongson EXT2 (EXTensions R2 instructions) are now supported. > >loongson-ext2 which contains the Loongson EXT2 instructions. > > Use -m[no-]loongson-mmi -m[no-]loongson-ext -m[no-]loongson-ext2 > will enable or disable those extensions, > for example: Using -mloongson-mmi/-mno-loongson-mmi > will enable/disable the Loongson MultiMedia Instructions extensions. > > Support has been added for the following processors > (GCC identifiers in parentheses): > > Loongson 3A1000 (gs464) > which enables loongson-mmi, loongson-ext by default. > Loongson 3A2000/3A3000 (gs464e) > which enables loongson-mmi, loongson-ext, loongson-ext2 by default. > Loongson 2K1000 (gs264e) > which enables loongson-ext, loongson-ext2, msa by default. > > The GCC identifiers can be used > as arguments to the -mcpu or -mtune options, > for example: -mcpu=gs464 or > -mtune=gs464e or as arguments to the equivalent target > attributes and pragmas. > >
Re: [PATCH] PR libstdc++/87431 re-adjust never-valueless optimizations
On Wed, Apr 3, 2019, 23:39 Ville Voutilainen wrote: > On Wed, 3 Apr 2019 at 23:32, Antony Polukhin wrote: > > > > Looks good. Covers most of the use cases. > > > > Please consider adding filesystem::path, pair, tuple, string_view?, > error_code, list, deque (myabe all the other containers), optional, variant > itself (for cases when variant holds another variant). > > > > It would be very useful for the _Never_valueless_alt to return true for > aggregates that hold only never valueles types. Not sure that there is a > compiler builtin for getting all the aggregates types, but it could be > implemented via metaprogramming. > > What metaprogram is capable of that? > This one https://github.com/apolukhin/magic_get >
