New Swedish PO file for 'gcc' (version 11.1-b20210207)
Hello, gentle maintainer. This is a message from the Translation Project robot. A revised PO file for textual domain 'gcc' has been submitted by the Swedish team of translators. The file is available at: https://translationproject.org/latest/gcc/sv.po (This file, 'gcc-11.1-b20210207.sv.po', has just now been sent to you in a separate email.) All other PO files for your package are available in: https://translationproject.org/latest/gcc/ Please consider including all of these in your next release, whether official or a pretest. Whenever you have a new distribution with a new version number ready, containing a newer POT file, please send the URL of that distribution tarball to the address below. The tarball may be just a pretest or a snapshot, it does not even have to compile. It is just used by the translators when they need some extra translation context. The following HTML page has been updated: https://translationproject.org/domain/gcc.html If any question arises, please contact the translation coordinator. Thank you for all your work, The Translation Project robot, in the name of your translation coordinator.
[commit] typos: Fix various typos - mainly misspelled reference* [PR99304]
Hi!
The PR is about a typo in handle_malloc_attribute diagnostic message,
but grepping around I found many other cases and while fixing those I've
noticed a couple of other typos.
Bootstrapped/regtested on x86_64-linux and i686-linux, committed to trunk.
2021-02-28 Jakub Jelinek
PR c/99304
* ipa.c (symbol_table::remove_unreachable_nodes): Fix a comment
typo - referneced -> referenced.
* tree.c (component_ref_size): Fix comment typo -
refernce -> reference.
* tree-ssa-alias.c (access_path_may_continue_p): Fix comment typo -
traling -> trailing.
(aliasing_component_refs_p): Fix comment typos -
refernce -> reference and refernece -> reference and
traling -> trailing.
(nonoverlapping_refs_since_match_p): Fix comment typo -
referneces -> references.
* doc/invoke.texi (--param modref-max-bases): Fix a typo -
referneces -> references.
c-family/
* c-attribs.c (handle_malloc_attribute): Fix a typo in inform
message - refernced -> referenced. Remove superfluous space before
closing ) of function calls.
lto/
* lto-symtab.c (lto_symtab_prevailing_virtual_decl): Fix comment
typos - refernced -> referenced and
devirtualizaiton -> devirtualization.
--- gcc/ipa.c.jj2021-01-04 10:25:38.423238467 +0100
+++ gcc/ipa.c 2021-02-27 15:38:27.974496481 +0100
@@ -285,7 +285,7 @@ walk_polymorphic_call_targets (hash_set<
- C++ virtual tables keyed to other unit are represented as DECL_EXTERNAL
variables with DECL_INITIAL set. We finalize these and keep reachable
ones around for constant folding purposes. After inlining we however
- stop walking their references to let everything static referneced by them
+ stop walking their references to let everything static referenced by them
to be removed when it is otherwise unreachable.
We maintain queue of both reachable symbols (i.e. defined symbols that needs
--- gcc/tree.c.jj 2021-02-08 19:07:33.130166682 +0100
+++ gcc/tree.c 2021-02-27 15:38:52.847220200 +0100
@@ -13857,7 +13857,7 @@ component_ref_size (tree ref, special_ar
*sam = special_array_member::trail_1;
}
- /* For a refernce to a zero- or one-element array member of a union
+ /* For a reference to a zero- or one-element array member of a union
use the size of the union instead of the size of the member. */
if (TREE_CODE (argtype) == UNION_TYPE)
memsize = TYPE_SIZE_UNIT (argtype);
--- gcc/tree-ssa-alias.c.jj 2021-01-04 10:25:38.527237289 +0100
+++ gcc/tree-ssa-alias.c2021-02-27 15:47:35.671415937 +0100
@@ -,7 +,7 @@ aliasing_component_refs_walk (tree ref1,
REF1_ALIAS_SET is the alias set of REF1.
BASE_TYPE2 is type of base2. END_STRUCT_REF2 is non-NULL if there is
- a traling array access in the TBAA part of access path2.
+ a trailing array access in the TBAA part of access path2.
BASE2_ALIAS_SET is the alias set of base2. */
bool
@@ -1183,8 +1183,8 @@ aliasing_component_refs_p (tree ref1,
trailing array.
We generally discard the segment after end_of_tbaa_ref however
- we need to be careful in case it contains zero sized or traling array.
- These may happen after refernce to union and in this case we need to
+ we need to be careful in case it contains zero sized or trailing array.
+ These may happen after reference to union and in this case we need to
not disambiguate type puning scenarios.
We set:
@@ -1195,7 +1195,7 @@ aliasing_component_refs_p (tree ref1,
end_struct_ref1 to point the trailing reference (if it exists
in range baseend_of_tbaa_ref
- end_struct_past_end1 is true if this traling refernece occurs in
+ end_struct_past_end1 is true if this trailing reference occurs in
end_of_tbaa_ref...actual_ref. */
base1 = ref1;
while (handled_component_p (base1))
@@ -1674,7 +1674,7 @@ nonoverlapping_refs_since_match_p (tree
seen_unmatched_ref_p = true;
/* We can not maintain the invariant that bases are either
same or completely disjoint. However we can still recover
-from type based alias analysis if we reach referneces to
+from type based alias analysis if we reach references to
same sizes. We do not attempt to match array sizes, so
just finish array walking and look for component refs. */
if (ntbaa1 < 0 || ntbaa2 < 0)
--- gcc/c-family/c-attribs.c.jj 2021-02-19 12:14:10.941114111 +0100
+++ gcc/c-family/c-attribs.c2021-02-27 15:40:48.909931006 +0100
@@ -3343,7 +3343,7 @@ handle_malloc_attribute (tree *node, tre
error ("%qE attribute argument 1 must take a pointer "
"type as its first argument", name);
inform (DEC
[committed] fortran: Replace double space in diagnostic with a single one [PR99300]
Hi!
The diagnostic had " " in it instead of just " ".
Bootstrapped/regtested on x86_64-linux and i686-linux, committed to trunk as
obvious.
2021-02-28 Jakub Jelinek
PR fortran/99300
* frontend-passes.c (doloop_code): Replace double space in diagnostics
with a single space.
--- gcc/fortran/frontend-passes.c.jj2021-01-16 22:52:33.617413820 +0100
+++ gcc/fortran/frontend-passes.c 2021-02-27 17:57:21.956841765 +0100
@@ -2648,7 +2648,7 @@ doloop_code (gfc_code **c, int *walk_sub
{
if (f->sym->attr.intent == INTENT_OUT)
gfc_error_now ("Variable %qs at %L set to undefined "
- "value inside loop beginning at %L as "
+ "value inside loop beginning at %L as "
"INTENT(OUT) argument to subroutine %qs",
do_sym->name, &a->expr->where,
&(doloop_list[i].c->loc),
Jakub
[committed] fortran: Fix up wording of 3 OpenMP diagnostic messages [PR99303]dbI
Hi!
As reported in the PR, some diagnostic messages need wording improvements.
Bootstrapped/regtested on x86_64-linux and i686-linux, committed to trunk.
2021-02-28 Jakub Jelinek
PR fortran/99303
* openmp.c (gfc_omp_requires_add_clause): Fix up diagnostic message
wordings.
(resolve_omp_clauses): Likewise.
--- gcc/fortran/openmp.c.jj 2021-02-18 09:11:25.358114314 +0100
+++ gcc/fortran/openmp.c2021-02-27 19:37:36.976876441 +0100
@@ -3788,11 +3788,11 @@ gfc_omp_requires_add_clause (gfc_omp_req
if (clause & OMP_REQ_ATOMIC_MEM_ORDER_MASK)
gfc_error ("!$OMP REQUIRES clause % "
"specified via module %qs use at %L but same clause is "
- "not set at for the program unit", clause_name, module_name,
- loc);
+ "not specified for the program unit", clause_name,
+ module_name, loc);
else
gfc_error ("!$OMP REQUIRES clause %qs specified via module %qs use at "
- "%L but same clause is not set at for the program unit",
+ "%L but same clause is not specified for the program unit",
clause_name, module_name, loc);
return false;
}
@@ -5411,7 +5411,7 @@ resolve_omp_clauses (gfc_code *code, gfc
if (has_inscan && has_notinscan && is_reduction)
{
gfc_error ("% and non-% % "
- "clauses on the same construct %L",
+ "clauses on the same construct at %L",
&n->where);
break;
}
Jakub
[r11-7430 Regression] FAIL: g++.dg/ext/attr-lambda3.C -std=c++2a (test for excess errors) on Linux/x86_64
On Linux/x86_64,
5d9d6c1cd8d9f0e057b4a7a849bc765e2109137c is the first bad commit
commit 5d9d6c1cd8d9f0e057b4a7a849bc765e2109137c
Author: Jason Merrill
Date: Fri Feb 26 05:45:02 2021 -0500
c++: Allow GNU attributes before lambda -> [PR90333]
caused
FAIL: g++.dg/ext/attr-lambda3.C -std=c++14 (test for excess errors)
FAIL: g++.dg/ext/attr-lambda3.C -std=c++17 (test for excess errors)
FAIL: g++.dg/ext/attr-lambda3.C -std=c++2a (test for excess errors)
with GCC configured with
../../gcc/configure
--prefix=/local/skpandey/gccwork/toolwork/gcc-bisect-master/master/r11-7430/usr
--enable-clocale=gnu --with-system-zlib --with-demangler-in-ld
--with-fpmath=sse --enable-languages=c,c++,fortran --enable-cet --without-isl
--enable-libmpx x86_64-linux --disable-bootstrap
To reproduce:
$ cd {build_dir}/gcc && make check
RUNTESTFLAGS="dg.exp=g++.dg/ext/attr-lambda3.C --target_board='unix{-m32}'"
$ cd {build_dir}/gcc && make check
RUNTESTFLAGS="dg.exp=g++.dg/ext/attr-lambda3.C --target_board='unix{-m32\
-march=cascadelake}'"
$ cd {build_dir}/gcc && make check
RUNTESTFLAGS="dg.exp=g++.dg/ext/attr-lambda3.C --target_board='unix{-m64}'"
$ cd {build_dir}/gcc && make check
RUNTESTFLAGS="dg.exp=g++.dg/ext/attr-lambda3.C --target_board='unix{-m64\
-march=cascadelake}'"
(Please do not reply to this email, for question about this report, contact me
at skpgkp2 at gmail dot com)
[PATCH] Add missing changes to Makefile.tpl
On Sat, Feb 27, 2021 at 11:01 PM Mike Frysinger wrote: > > On 19 Dec 2020 10:10, H.J. Lu via Gdb-patches wrote: > > --- a/Makefile.in > > +++ b/Makefile.in > > > > +PGO_BUILD_TRAINING_FLAGS_TO_PASS = \ > > + PGO_BUILD_TRAINING=yes \ > > + CFLAGS_FOR_TARGET="$(PGO_BUILD_TRAINING_CFLAGS)" \ > > + CXXFLAGS_FOR_TARGET="$(PGO_BUILD_TRAINING_CXXFLAGS)" > > + > > +# Ignore "make check" errors in PGO training runs. > > +PGO_BUILD_TRAINING_MFLAGS = -i > > these lines are in Makefile.in but not Makefile.tpl. so regenerating > the file causes them to be removed. can you take a look please ? > I checked in this patch as an obvious change. Thanks. -- H.J. From 1dbde357be3ce2641595b10436822e699abe32a0 Mon Sep 17 00:00:00 2001 From: "H.J. Lu" Date: Sun, 28 Feb 2021 04:39:38 -0800 Subject: [PATCH] Add missing changes to Makefile.tpl Update Makefile.tpl to add missing changes in commit af019bfde9b13d628202fe58054ec7ff08d92a0f Author: H.J. Lu Date: Sat Jan 9 06:51:15 2021 -0800 Support the PGO build for binutils+gdb "autogen Makefile.def" showed no changes in Makefile.in. PR binutils/26766 * Makefile.tpl (PGO_BUILD_TRAINING_FLAGS_TO_PASS): Add PGO_BUILD_TRAINING=yes. (PGO_BUILD_TRAINING_MFLAGS): New. (all): Pass $(PGO_BUILD_TRAINING_MFLAGS) to the PGO build. --- ChangeLog| 8 Makefile.tpl | 5 + 2 files changed, 13 insertions(+) diff --git a/ChangeLog b/ChangeLog index e9a5611c5e7..4cd48fa1dad 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,11 @@ +2021-02-28 H.J. Lu + + PR binutils/26766 + * Makefile.tpl (PGO_BUILD_TRAINING_FLAGS_TO_PASS): Add + PGO_BUILD_TRAINING=yes. + (PGO_BUILD_TRAINING_MFLAGS): New. + (all): Pass $(PGO_BUILD_TRAINING_MFLAGS) to the PGO build. + 2021-02-09 Alan Modra * configure.ac: Delete arm*-*-symbianelf* entry. diff --git a/Makefile.tpl b/Makefile.tpl index 38f0b021f43..84fee3dd0f7 100644 --- a/Makefile.tpl +++ b/Makefile.tpl @@ -440,9 +440,13 @@ PGO_BUILD_TRAINING_CFLAGS:= \ PGO_BUILD_TRAINING_CXXFLAGS:= \ $(filter-out -specs=%,$(PGO_BUILD_TRAINING_CXXFLAGS)) PGO_BUILD_TRAINING_FLAGS_TO_PASS = \ + PGO_BUILD_TRAINING=yes \ CFLAGS_FOR_TARGET="$(PGO_BUILD_TRAINING_CFLAGS)" \ CXXFLAGS_FOR_TARGET="$(PGO_BUILD_TRAINING_CXXFLAGS)" +# Ignore "make check" errors in PGO training runs. +PGO_BUILD_TRAINING_MFLAGS = -i + # Additional PGO and LTO compiler options to use profiling data for the # PGO build. PGO_BUILD_USE_FLAGS_TO_PASS = \ @@ -784,6 +788,7 @@ all: $(PGO_BUILD_GEN_FLAGS_TO_PASS) all-host all-target \ @if pgo-build && $(MAKE) $(RECURSE_FLAGS_TO_PASS) \ + $(PGO_BUILD_TRAINING_MFLAGS) \ $(PGO_BUILD_TRAINING_FLAGS_TO_PASS) \ $(PGO_BUILD_TRAINING) \ && $(MAKE) $(RECURSE_FLAGS_TO_PASS) clean \ -- 2.29.2
Re: [PATCH] coroutines : Remove throwing_cleanup marks from the ramp [PR95822].
Jason Merrill wrote:
On 2/26/21 4:36 PM, Iain Sandoe wrote:
Jason Merrill wrote:
On 2/24/21 3:06 PM, Iain Sandoe wrote:
So (a) the 'throwing_cleanup' is no longer correct for the ramp and
(b) we do not need to transfer it to the actor which only contains
void returns.
OK, but I wonder if there are other things that should also be reset.
That would be believable but, absent problem reports, have you any advice
on how/what to audit?
Looking at language_function, I guess it would make sense to clear
returns_abnormally and infinite_loop{,s}, maybe bindings.
thanks, I’ll take a look.
Since you're completely replacing the function body, almost none of the
information we previously recorded about it in cfun is accurate.
Yes, and maybe no longer accurate about the body when transferred to the
actor function [like the throwing_cleanup] (but it’s worth considering the
other cases anyway).
But it may be harmless.
I’d be inclined to null stuff out if it’s definitively unneeded - so will
check some more.
thanks
Iain
Re: [PATCH 4/5] barrier: use int instead of unsigned char for the phase state
On Fri, 26 Feb 2021, Thiago Macieira via Gcc-patches wrote:
> ints can be used in futexes. chars can't.
Shouldn't that be an atomic type instead of a bare int then?
> ---
> libstdc++-v3/include/std/barrier | 21 -
> 1 file changed, 12 insertions(+), 9 deletions(-)
>
> diff --git a/libstdc++-v3/include/std/barrier
> b/libstdc++-v3/include/std/barrier
> index e09212dfcb9..ae058bd3dc3 100644
> --- a/libstdc++-v3/include/std/barrier
> +++ b/libstdc++-v3/include/std/barrier
> @@ -70,7 +70,7 @@ It looks different from literature pseudocode for two main
> reasons:
>
> */
>
> - enum class __barrier_phase_t : unsigned char { };
> + enum class __barrier_phase_t : int { };
brgds, H-P
[pushed] testsuite, coroutines : Mark final awaiters and co_await operators noexcept.
Hi,
Fixing up some non-conforming testcases.
This is part of the requirement of [dcl.fct.def.coroutine]/15.
In addition to promise final_suspend() calls, the following cases must
also be noexcept as per discussion in PR95616.
- finalSuspendObj.operator co_await()
- finalSuspendAwaiter.await_ready()
- finalSuspendAwaiter.await_suspend()
- finalSuspendAwaiter.await_resume()
- finalSuspedObj destructor
- finalSuspendAwaiter destructor
Fixed for missing cases in the testsuite as a prerequisite to fixing
PR95616.
tested on x86_64-darwin, x86_64-linux-gnu
pushed to master,
thanks
Iain
gcc/testsuite/ChangeLog:
* g++.dg/coroutines/pr94879-folly-1.C: Make final suspend
expression components noexcept.
* g++.dg/coroutines/pr94883-folly-2.C: Likewise.
* g++.dg/coroutines/pr95345.C: Likewise.
---
gcc/testsuite/g++.dg/coroutines/pr94879-folly-1.C | 8
gcc/testsuite/g++.dg/coroutines/pr94883-folly-2.C | 6 +++---
gcc/testsuite/g++.dg/coroutines/pr95345.C | 6 +++---
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/gcc/testsuite/g++.dg/coroutines/pr94879-folly-1.C
b/gcc/testsuite/g++.dg/coroutines/pr94879-folly-1.C
index e815ca70735..11bcce04b7d 100644
--- a/gcc/testsuite/g++.dg/coroutines/pr94879-folly-1.C
+++ b/gcc/testsuite/g++.dg/coroutines/pr94879-folly-1.C
@@ -18,14 +18,14 @@ class i {
namespace ac {
template class ad {
public:
- bool await_ready();
- void await_resume();
- void await_suspend(std::coroutine_handle<>);
+ bool await_ready() noexcept;
+ void await_resume() noexcept;
+ void await_suspend(std::coroutine_handle<>) noexcept;
i ae;
};
} // namespace ac
-template ac::ad operator co_await(ab);
+template ac::ad operator co_await(ab) noexcept;
class j {
class l {};
diff --git a/gcc/testsuite/g++.dg/coroutines/pr94883-folly-2.C
b/gcc/testsuite/g++.dg/coroutines/pr94883-folly-2.C
index c5fa65931e0..ce06cfddb0a 100644
--- a/gcc/testsuite/g++.dg/coroutines/pr94883-folly-2.C
+++ b/gcc/testsuite/g++.dg/coroutines/pr94883-folly-2.C
@@ -16,9 +16,9 @@ int f;
class h {
class j {
public:
-bool await_ready();
-void await_suspend(std::coroutine_handle<>);
-void await_resume();
+bool await_ready() noexcept;
+void await_suspend(std::coroutine_handle<>) noexcept;
+void await_resume() noexcept;
};
public:
diff --git a/gcc/testsuite/g++.dg/coroutines/pr95345.C
b/gcc/testsuite/g++.dg/coroutines/pr95345.C
index 8eae611b8d3..57b95cbebb2 100644
--- a/gcc/testsuite/g++.dg/coroutines/pr95345.C
+++ b/gcc/testsuite/g++.dg/coroutines/pr95345.C
@@ -9,9 +9,9 @@ using namespace std::experimental;
struct dummy_coro
{
using promise_type = dummy_coro;
- bool await_ready() { return false; }
- void await_suspend(std::coroutine_handle<>) { }
- void await_resume() { }
+ bool await_ready() noexcept { return false; }
+ void await_suspend(std::coroutine_handle<>) noexcept { }
+ void await_resume() noexcept { }
dummy_coro get_return_object() { return {}; }
dummy_coro initial_suspend() { return {}; }
dummy_coro final_suspend() noexcept { return {}; }
--
2.24.1
Re: [PATCH 3/4] c++: Delay normalizing nested requirements until satisfaction
On Fri, 12 Feb 2021, Jason Merrill wrote:
> On 2/10/21 9:41 AM, Patrick Palka wrote:
> > On Tue, 9 Feb 2021, Jason Merrill wrote:
> >
> > > On 2/8/21 2:03 PM, Patrick Palka wrote:
> > > > This sets up the functionality for controlling the initial set of
> > > > template parameters to pass to normalization when dealing with a
> > > > constraint-expression that is not associated with some constrained
> > > > declaration, for instance when normalizing a nested requirement of a
> > > > requires expression, or the constraints on a placeholder type.
> > > >
> > > > The main new ingredient here is the data member norm_info::initial_parms
> > > > which can be set by callers of the normalization routines to communicate
> > > > the in-scope template parameters for the supplied constraint-expression,
> > > > rather than always falling back to using current_template_parms.
> > > >
> > > > This patch then uses this functionality in our handling of nested
> > > > requirements so that we can delay normalizing them until needed for
> > > > satisfaction. We currently immediately normalize nested requirements at
> > > > parse time, where we have the necessary template context, and cache the
> > > > normal form in their TREE_TYPE node. With this patch, we now delay
> > > > normalization until needed (as with other constraint expressions), and
> > > > instead store the current value of current_template_parms in their
> > > > TREE_TYPE node (which we use to restore the template context at
> > > > normalization time).
> > > >
> > > > In the subsequent patch, this functionality will also be used to
> > > > normalize placeholder type constraints during auto deduction.
> > > >
> > > > gcc/cp/ChangeLog:
> > > >
> > > > * constraint.cc (build_parameter_mapping): Rely on the caller to
> > > > determine the in-scope template parameters.
> > > > (norm_info::norm_info): Delegate the one-parameter constructor
> > > > to the two-parameter constructor. In the two-parameter
> > > > constructor, fold in the definition of make_context, set
> > > > initial_parms appropriately, and don't set the now-removed
> > > > orig_decl member.
> > > > (norm_info::make_context): Remove, now that its only use is
> > > > inlined into the caller.
> > > > (norm_info::update_context): Adjust call to
> > > > build_parameter_mapping to pass in the relevant set of in-scope
> > > > template parameters.
> > > > (norm_info::ctx_parms): Define this member function.
> > > > (norm_info::context): Initialize to NULL_TREE.
> > > > (norm_info::orig_decl): Remove this data member.
> > > > (norm_info::initial_parms): Define this data member.
> > > > (normalize_atom): Adjust call to build_parameter_mapping to pass
> > > > in the relevant set of in-scope template parameters. Use
> > > > info.initial_parms instead of info.orig_decl.
> > > > (normalize_constraint_expression): Define an overload that takes
> > > > a norm_info object. Cache the result of normalization. Define
> > > > the other overload in terms of this one, and handle a NESTED_REQ
> > > > argument by setting info.initial_parms appropriately.
> > > > (tsubst_nested_requirement): Go through
> > > > satisfy_constraint_expression so that we normalize on demand.
> > > > (finish_nested_requirement): Set the TREE_TYPE of the NESTED_REQ
> > > > to current_template_parms.
> > > > (diagnose_nested_requirements): Go through
> > > > satisfy_constraint_expression, as with
> > > > tsubst_nested_requirement.
> > > > ---
> > > >gcc/cp/constraint.cc | 140
> > > > +++
> > > >gcc/cp/cp-tree.h | 4 +-
> > > >2 files changed, 78 insertions(+), 66 deletions(-)
> > > >
> > > > diff --git a/gcc/cp/constraint.cc b/gcc/cp/constraint.cc
> > > > index 39c97986082..56134f8b2bf 100644
> > > > --- a/gcc/cp/constraint.cc
> > > > +++ b/gcc/cp/constraint.cc
> > > > @@ -133,7 +133,7 @@ struct sat_info : subst_info
> > > > bool diagnose_unsatisfaction;
> > > >};
> > > >-static tree satisfy_constraint (tree, tree, sat_info);
> > > > +static tree satisfy_constraint_expression (tree, tree, sat_info);
> > > > /* True if T is known to be some type other than bool. Note that
> > > > this
> > > > is false for dependent types and errors. */
> > > > @@ -594,26 +594,12 @@ map_arguments (tree parms, tree args)
> > > > return parms;
> > > >}
> > > >-/* Build the parameter mapping for EXPR using ARGS. */
> > > > +/* Build the parameter mapping for EXPR using ARGS, where CTX_PARMS
> > > > + are the template parameters in scope for EXPR. */
> > > > static tree
> > > > -build_parameter_mapping (tree expr, tree args, tree decl)
> > > > +build_parameter_mapping (tree expr, tree args, tree ctx_parms)
> > > >{
> > > > -
Re: [x86] Fix PR target/99264
On Fri, Feb 26, 2021 at 5:14 PM Eric Botcazou wrote: > > Hi, > > this wrong-code PR for the C++ compiler on x86-64/Windows is a regression > in GCC 9 and later, but the underlying issue has probably been there since > SEH was implemented and is exposed by this comment in config/i386/winnt.c: > > /* SEH records saves relative to the "current" stack pointer, whether > or not there's a frame pointer in place. This tracks the current > stack pointer offset from the CFA. */ > HOST_WIDE_INT sp_offset; > > That's not what the (current) Microsoft documentation says; instead it says: > > /* SEH records offsets relative to the lowest address of the fixed stack > allocation. If there is no frame pointer, these offsets are from the > stack pointer; if there is a frame pointer, these offsets are from the > value of the stack pointer when the frame pointer was established, i.e. > the frame pointer minus the offset in the .seh_setframe directive. > > That's why the implementation is correct only under the condition that the > frame pointer be established *after* the fixed stack allocation; as a matter > of fact, that's clearly the model underpinning SEH, but is the opposite of > what is done e.g. on Linux. > > However the issue is mostly papered over in practice because: > > 1. SEH forces use_fast_prologue_epilogue to false, which in turns forces > save_regs_using_mov to false, so the general regs are always pushed when they > need to be saved, which eliminates the offset computation for them. > > 2. As soon as a frame is larger than 240 bytes, the frame pointer is fixed > arbitrarily to 128 bytes above the stack pointer, which of course requires > that it be established after the fixed stack allocation. > > So you need a very small frame clobbering one of the call-saved XMM registers > in order to generate wrong SEH unwind info. > > The attached fix makes sure that the frame pointer is always established after > the fixed stack allocation by pointing it at or below the lowest used register > save area, i.e. the SSE save area, and removing the special early saves in the > prologue; the end result is a uniform prologue sequence for SEH whatever the > frame size. And it avoids a weird discrepancy between cases where the number > of saved general regs is even and cases where it is odd. > > Tested on x86_64-w64-mingw32, OK for mainline, 10 and 9 branches? > > > 2021-02-26 Eric Botcazou > > PR target/99264 > * config/i386/i386.c (ix86_compute_frame_layout): For a SEH target, > point the hard frame pointer to the SSE register save area instead > of the general register save area. Perform only minimal adjustment > for small frames if it is initially not correctly aligned. > (ix86_expand_prologue): Remove early saves for a SEH target. > * config/i386/winnt.c (struct seh_frame_state): Document constraint. > > > 2021-02-26 Eric Botcazou > > * g++.dg/eh/seh-xmm-unwind.C: New test. LGTM. Thanks, Uros. > -- > Eric Botcazou
Re: [PATCH 4/4] c++: dependent constraint on placeholder 'auto' [PR96443]
On Fri, 12 Feb 2021, Jason Merrill wrote: > On 2/11/21 5:14 PM, Patrick Palka wrote: > > On Thu, 11 Feb 2021, Jason Merrill wrote: > > > > > On 2/8/21 2:03 PM, Patrick Palka wrote: > > > > This fixes the way we check satisfaction of constraints on placeholder > > > > types in various contexts, and in particular when the constraint is > > > > dependent. > > > > > > > > Firstly, when evaluating the return type requirement of a compound > > > > requirement, we currently substitute the outer template arguments into > > > > the constraint before checking satisfaction. But we should instead be > > > > passing in the complete set of template arguments to satisfaction and > > > > not do a prior separate substitution. Our current approach leads to us > > > > incorrectly rejecting the testcase concepts-return-req2.C below. > > > > > > > > Secondly, when checking the constraints on a placeholder variable or > > > > return type, we don't substitute the template arguments of the enclosing > > > > context at all. This leads to bogus errors during satisfaction when the > > > > constraint is dependent as in the testcase concepts-placeholder3.C > > > > below. > > > > > > > > In order to fix these two issues, we need to be able to properly > > > > normalize the constraints on a placeholder 'auto', which in turn > > > > requires us to know the template parameters that were in-scope where an > > > > 'auto' was introduced. This information currently doesn't seem to be > > > > easily available when we need it, so this patch adds an auxiliary hash > > > > table that keeps track of the value of current_template_parms when each > > > > constrained 'auto' was formed. > > > > > > > > This patch also removes some seemingly wrong handling of placeholder > > > > type arguments from tsubst_parameter_mapping. The code doesn't trigger > > > > with the example used in the comments, because type_uses_auto doesn't > > > > look inside non-deduced contexts such as the operand of decltype. And > > > > the call to do_auto_deduction seems confused because if 'arg' is a type, > > > > then so is 'parm', and therefore 'init' too is a type, but > > > > do_auto_deduction expects it to be an expression. Before this patch, > > > > this code was dead (as far as our testsuite can tell), but now it breaks > > > > other parts of this patch, so let's remove it. > > > > > > > > gcc/cp/ChangeLog: > > > > > > > > PR c++/96443 > > > > * constraint.cc (type_deducible_p): Don't substitute into the > > > > constraints, and instead just pass 'args' to do_auto_deduction > > > > as the outer template arguments. > > > > (tsubst_parameter_mapping): Remove confused code for handling > > > > placeholder type arguments. > > > > (normalize_placeholder_type_constraint): Define. > > > > (satisfy_constraint_expression): Use it to handle placeholder > > > > 'auto' types. > > > > * cp-tree.h (get_constrained_auto_context): Declare. > > > > * pt.c (constrained_auto_context_map): Define. > > > > (get_placeholder_type_constraint_context): Define. > > > > (set_placeholder_type_constraints): Define. > > > > (copy_placeholder_type_constraints): Define. > > > > (tsubst) : Use > > > > copy_placeholder_type_constraints. > > > > (make_constrained_placeholder_type): Use > > > > set_placeholder_type_constraints. > > > > (do_auto_deduction): Clarify comments about the outer_targs > > > > parameter. Rework satisfaction of a placeholder type constraint > > > > to pass in the complete set of template arguments directly to > > > > constraints_satisfied_p. > > > > (splice_late_return_type): Use > > > > copy_placeholder_type_constraints. > > > > > > > > gcc/testsuite/ChangeLog: > > > > > > > > PR c++/96443 > > > > * g++.dg/cpp2a/concepts-placeholder3.C: New test. > > > > * g++.dg/cpp2a/concepts-return-req2.C: New test. > > > > * g++.dg/concepts-ts1.C: Add dg-bogus directive to the call to > > > > f15 that we expect to accept. > > > > --- > > > >gcc/cp/constraint.cc | 106 > > > > -- > > > >gcc/cp/cp-tree.h | 1 + > > > >gcc/cp/pt.c | 101 +++-- > > > >.../g++.dg/cpp2a/concepts-placeholder3.C | 19 > > > >.../g++.dg/cpp2a/concepts-return-req2.C | 13 +++ > > > >gcc/testsuite/g++.dg/cpp2a/concepts-ts1.C | 2 +- > > > >6 files changed, 146 insertions(+), 96 deletions(-) > > > >create mode 100644 gcc/testsuite/g++.dg/cpp2a/concepts-placeholder3.C > > > >create mode 100644 gcc/testsuite/g++.dg/cpp2a/concepts-return-req2.C > > > > > > > > diff --git a/gcc/cp/constraint.cc b/gcc/cp/constraint.cc > > > > index 56134f8b2bf..53588047d44 100644 > > > > --- a/gcc/cp/constraint.cc > > > > +++ b/gcc/cp/c
[PATCH 5/6] c++: Clean up normalization / satisfaction routines
This patch mostly performs some straightforward refactoring:
- Renamed satisfy_constraint to satisfy_normalized_constraints
- Renamed the three-parameter version of satisfy_constraint_expression
to satisfy_nondeclaration_constraints
- Removed normalize_(non)?template_requirements
- Removed satisfy_associated_constraints (and made its callers
check for dependent template args sooner, before normalization)
- Removed the tsubst_flags_t parameter of evaluate_concept_check
- Combined the two versions of constraint_satisfaction_value
- Combined the two versions of constraint_satisfied_p
Additionally, this patch removes the handling of bare
constraint-expressions from satisfy_nondeclaration_constraints, and
hence constraints_satisfied_p and constraint_satisfaction_value now only
take things that carry their own template information needed for
normalization. In practice, this only means it's no longer possible to
evaluate bare REQUIRES_EXPRs via the satisfaction routines, and so this
patch adjusts the affected callers to instead use tsubst_requires_expr.
For convenience, the function diagnose_constraints continues to accept
REQUIRES_EXPRs, but it now handles them by calling diagnose_require_expr
directly.
(That we used to evaluate REQUIRES_EXPR via satisfaction might even be a
correctness issue: since we cache satisfaction in special ways that don't
apply to regular evaluation, going through satisfaction could in theory
cause us to reuse a cached value for a REQUIRES_EXPR when we shouldn't
have.)
gcc/cp/ChangeLog:
* constexpr.c (cxx_eval_call_expression): Adjust call to
evaluate_concept_check.
(cxx_eval_constant_expression) : Use
tsubst_requires_expr instead of satisfy_constraint_expression.
: Adjust call to evaluate_concept_check.
* constraint.cc (struct sat_info): Adjust comment about which
satisfaction entrypoints use noisy-unsat.
(normalize_template_requirements): Remove (and adjust callers
appropriately).
(normalize_nontemplate_requirements): Likewise.
(tsubst_nested_requirement): Use constraint_satisfaction_value
instead of satisfy_constraint_expression, which'll do the
noisy replaying of ill-formed quiet satisfaction for us.
(decl_satisfied_cache): Adjust comment.
(satisfy_constraint): Rename to ...
(satisfy_normalized_constraints): ... this.
(satisfy_associated_constraints): Remove (and make its
callers check for dependent arguments).
(satisfy_constraint_expression): Rename to ...
(satisfy_nondeclaration_constraints): ... this. Assert that
'args' is empty when 't' is a concept-id. Removing handling
bare constraint-expressions. Adjust comment accordingly.
(satisfy_declaration_constraints): Assert in the two-parameter
version that 't' is not a TEMPLATE_DECL. Adjust following
removal of normalize_(non)?template_requirements and
satisfy_asociated_constraints.
(constraint_satisfaction_value): Combine the two- and
three-parameter versions in the natural way.
(constraints_satisfied_p): Combine the one- and two-parameter
versions in the natural way. Improve documentation.
(evaluate_concept_check): Remove 'complain' parameter. Use
constraint_satisfaction_value instead of
satisfy_constraint_expression.
(diagnose_nested_requirement): Adjust following renaming of
satisfy_constraint_expression.
(diagnose_constraints): Handle REQUIRES_EXPR by going through
diagnose_requires_expr directly instead of treating it as a
constraint-expression. Improve documentation.
* cp-gimplify.c (cp_genericize_r) : Adjust call
to evaluate_concept_check.
: Use tsubst_requires_expr instead of
constraints_satisfied_p.
: Adjust call to evaluate_concept_check.
* cp-tree.h (evaluate_concept_check): Remove tsubst_flag_t
parameter.
(satisfy_constraint_expression): Remove declaration.
(constraints_satisfied_p): Remove one-parameter declaration.
Add a default argument to the two-parameter declaration.
* cvt.c (convert_to_void): Adjust call to
evaluate_concept_check.
---
gcc/cp/constexpr.c | 6 +-
gcc/cp/constraint.cc | 210 ---
gcc/cp/cp-gimplify.c | 7 +-
gcc/cp/cp-tree.h | 6 +-
gcc/cp/cvt.c | 2 +-
5 files changed, 85 insertions(+), 146 deletions(-)
diff --git a/gcc/cp/constexpr.c b/gcc/cp/constexpr.c
index cd0a68e9fd6..f940e3e5985 100644
--- a/gcc/cp/constexpr.c
+++ b/gcc/cp/constexpr.c
@@ -2257,7 +2257,7 @@ cxx_eval_call_expression (const constexpr_ctx *ctx, tree
t,
{
/* Handle concept checks separately. */
if (concept_check_p (t))
-return evaluate_concept_check (t, tf_warning_or_error);
+return evaluate_concept_check (t);
location_t
[PATCH 6/6] c++: Consolidate REQUIRES_EXPR evaluation/diagnostic routines
This folds the diagnose_requires_expr routines into the corresponding tsubst_requires_expr ones. This is achieved by making the latter routines take a sat_info instead of a subst_info, and assigning the appropriate meanings to the flags sat_info::noisy and sat_info::diagnose_unsatisfaction_p during tsubst_requires_expr: info.noisy() controls whether to diagnose invalid types and expressions inside the requires-expression, and info.diagnose_unsatisfaction_p() controls whether to diagnose why the requires-expression evaluates to false. gcc/cp/ChangeLog: * constraint.cc (struct sat_info): Document the different meanings of noisy() and diagnose_unsatisfaction_p() during satisfaction and requires-expression evaluation. (tsubst_valid_expression_requirement): Take a sat_info instead of a subst_info. Perform the substitution quietly first. Fold in error-replaying code from diagnose_valid_expression. (tsubst_simple_requirement): Take a sat_info instead of a subst_info. (tsubst_type_requirement_1): New. Fold in error-replaying code from diagnose_valid_type. (tsubst_type_requirement): Use the above. Take a sat_info instead of a subst_info. (tsubst_compound_requirement): Likewise. Fold in error-replaying code from diagnose_compound_requirement. (tsubst_nested_requirement): Take a sat_info instead of a subst_info. Fold in error-replaying code from diagnose_nested_requirement. (tsubst_requirement): Take a sat_info instead of a subst_info. (tsubst_requires_expr): Split into two versions, one that takes a sat_info argument and another that takes a complain and in_decl argument. Remove outdated documentation. Document the effects of the sat_info argument. (diagnose_trait_expr): Make static. Take a template argument vector instead of a parameter mapping. (diagnose_valid_expression): Remove. (diagnose_valid_type): Remove. (diagnose_simple_requirement): Remove. (diagnose_compound_requirement): Remove. (diagnose_type_requirement): Remove. (diagnose_nested_requirement): Remove. (diagnose_requirement): Remove. (diagnose_requires_expr): Remove. (diagnose_atomic_constraint): Take a sat_info instead of a subst_info. Adjust call to diagnose_trait_expr. Call tsubst_requires_expr instead of diagnose_requires_expr. (diagnose_constraints): Call tsubst_requires_expr instead of diagnose_requires_expr. gcc/testsuite/ChangeLog: * g++.dg/concepts/diagnostic1.C: Adjust expected diagnostics now that we diagnose only the first failed requirement of a requires-expression. --- gcc/cp/constraint.cc| 416 +--- gcc/testsuite/g++.dg/concepts/diagnostic1.C | 2 +- 2 files changed, 179 insertions(+), 239 deletions(-) diff --git a/gcc/cp/constraint.cc b/gcc/cp/constraint.cc index cf319b34da0..31f32c25dfe 100644 --- a/gcc/cp/constraint.cc +++ b/gcc/cp/constraint.cc @@ -100,17 +100,30 @@ struct subst_info /* Provides additional context for satisfaction. - The flag noisy() controls whether to diagnose ill-formed satisfaction, - such as the satisfaction value of an atom being non-bool or non-constant. - - The flag diagnose_unsatisfaction_p() controls whether to explain why - a constraint is not satisfied. - - The entrypoints to satisfaction for which we set noisy+unsat are - diagnose_constraints and diagnose_nested_requirement. The entrypoint for - which we set noisy-unsat is the replay inside constraint_satisfaction_value. - From constraints_satisfied_p, we enter satisfaction quietly (both flags - cleared). */ + During satisfaction: +- The flag noisy() controls whether to diagnose ill-formed satisfaction, + such as the satisfaction value of an atom being non-bool or non-constant. +- The flag diagnose_unsatisfaction_p() controls whether to explain why + a constraint is not satisfied. +- We enter satisfaction with noisy+unsat from diagnose_constraints. +- We enter satisfaction with noisy-unsat from the replay inside + constraint_satisfaction_value. +- We enter satisfaction quietly (both flags cleared) from + constraints_satisfied_p. + + During evaluation of a requires-expression: +- The flag noisy() controls whether to diagnose ill-formed types and + expressions inside its requirements. +- The flag diagnose_unsatisfaction_p() controls whether to explain why + the requires-expression evaluates to false. +- We enter tsubst_requires_expr with noisy+unsat from diagnose_constraints + and from diagnose_atomic_constraint. +- We enter tsubst_requires_expr with noisy-unsat from + cp_parser_requires_expression when processing a requires-expression that + appears outside a template. +
Re: [PATCH 1/5] std::latch: reduce internal implementation from ptrdiff_t to int
On Fri, 26 Feb 2021, Thiago Macieira via Gcc-patches wrote: > On Friday, 26 February 2021 11:31:00 PST Andreas Schwab wrote: > > On Feb 26 2021, Thiago Macieira wrote: > > > On Friday, 26 February 2021 10:14:42 PST Andreas Schwab wrote: > > >> On Feb 26 2021, Thiago Macieira via Gcc-patches wrote: > > >> > -alignas(__alignof__(ptrdiff_t)) ptrdiff_t _M_a; > > >> > +alignas(__alignof__(int)) int _M_a; > > >> > > >> Futexes must be aligned to 4 bytes. > > > > > > Agreed, but doesn't this accomplish that? > > > > No. It uses whatever alignment the type already has, and is an > > elaborate no-op. > > I thought so too when I read the original line. But I expected it was written > like that for a reason, especially since the same pattern appears in other > places. > > I can change to "alignas(4)" (which is a GCC extension, I believe). Is that > the correct solution? IMNSHO make use of the corresponding atomic type. Then there'd be no need for separate what's-the-right-align-curse games. brgds, H-P
Re: [PATCH 1/4] unroll: Add middle-end unroll factor estimation
on 2021/1/27 下午5:43, Kewen.Lin via Gcc-patches wrote: > on 2021/1/26 下午6:53, Richard Biener wrote: >> On Tue, 26 Jan 2021, Kewen.Lin wrote: >> >>> Hi Segher/Richard B./Richard S., >>> >>> Many thanks for your all helps and comments on this! >>> >>> on 2021/1/25 下午3:56, Richard Biener wrote: On Fri, 22 Jan 2021, Segher Boessenkool wrote: > On Fri, Jan 22, 2021 at 02:47:06PM +0100, Richard Biener wrote: >> On Thu, 21 Jan 2021, Segher Boessenkool wrote: >>> What is holding up this patch still? Ke Wen has pinged it every month >>> since May, and there has still not been a review. > > Richard Sandiford wrote: >> FAOD (since I'm on cc:), I don't feel qualified to review this. >> Tree-level loop stuff isn't really my area. > > And Richard Biener wrote: >> I don't like it, it feels wrong but I don't have a good suggestion >> that had positive feedback. Since a reviewer / approver is indirectly >> responsible for at least the design I do not want to ack this patch. >> Bin made forward progress on the other parts of the series but clearly >> there's somebody missing with the appropriate privileges who feels >> positive about the patch and its general direction. >> >> Sorry to be of no help here. > > How unfortunate :-( > > So, first off, this will then have to work for next stage 1 to make any > progress. Rats. > > But what could have been done differently that would have helped? Of > course Ke Wen could have written a better patch (aka one that is more > acceptable); either of you could have made your current replies earlier, > so that it is clear help needs to be sought elsewhere; and I could have > pushed people earlier, too. No one really did anything wrong, I'm not > seeking who to blame, I'm just trying to find out how to prevent > deadlocks like this in the future (where one party waits for replies > that will never come). > > Is it just that we have a big gaping hole in reviewers with experience > in such loop optimisations? May be. But what I think is the biggest problem is that we do not have a good way to achieve what the patch tries (if you review the communications you'll see many ideas tossed around) first and foremost because IV selection is happening early on GIMPLE and unrolling happens late on RTL. Both need a quite accurate estimate of costs but unrolling has an ever harder time than IV selection where we've got along with throwing dummy RTL at costing functions. >>> >>> Yeah, exactly. >>> IMHO the patch is the wrong "start" to try fixing the issue and my fear is that wiring this kind of "features" into the current (fundamentally broken) state will make it much harder to rework that state without introducing regressions on said features (I'm there with trying to turn the vectorizer upside down - for three years now, struggling to not regress any of the "features" we've accumulated for various targets where most of them feel a "bolted-on" rather than well-designed ;/). >>> >>> OK, understandable. >>> I think IV selection and unrolling (and scheduling FWIW) need to move closer together. I do not have a good idea how that can work out though but I very much believe that this "most wanted" GIMPLE unroller will not be a good way of progressing here. Maybe taking the bullet and moving IV selection back to RTL is the answer. >>> >>> I haven't looked into loop-iv.c, but IVOPTS in gimple can leverage >>> SCEV analysis for iv detection, if moving it to RTL, it could be >>> very heavier to detect the full set there? >>> For a "short term" solution I still think that trying to perform unrolling and IV selection (for the D-form case you're targeting) at the same time is a better design, even if it means complicating the IV selection pass (and yeah, it'll still be at GIMPLE and w/o any good idea about scheduling). There are currently 20+ GIMPLE optimization passes and 10+ RTL optimization passes between IV selection and unrolling, the idea that you can have transform decision and transform apply this far apart looks scary. >>> >>> I have some questions in mind for this part, for "perform unrolling >>> and IV selection at the same time", it can be interpreted to two >>> different implementation ways to me: >>> >>> 1) Run one gimple unrolling pass just before IVOPTS, probably using >>>the same gate for IVOPTS. The unrolling factor is computed by >>>the same method as that of RTL unrolling. But this sounds very >>>like "most wanted gimple unrolling" which is what we want to avoid. >>> >>>The positive aspect here is what IVOPTS faces is already one unrolled >>>loop, it can see the whole picture and get the optimal IV set. The >>>downside/question is how we position thes
