Re: [PATCH, LRA]: Revert the revert of removal of usless move insns.
On 11/21/18 2:33 PM, Uros Bizjak wrote:
Hello!
Before the recent patch to post-reload mode switching, vzeroupper
insertion depended on the existence of the return copy instructions
pair in functions that return a value. The first instruction in the
pair represents a move to a function return hard register, and the
second was a USE of the function return hard register. Sometimes a nop
move was generated (e.g. %eax->%eax) for the first instruction of the
return copy instructions pair and the patch [1] teached LRA to remove
these useless instructions on the fly.
The removal caused optimize mode switching to trigger the assert,
since the first instruction of a return pair was not found. The
relevant part of the patch was later reverted. With the recent
optimize mode switching patch, this is no longer necessary for
vzeroupper insertion pass, so attached patch reverts the revert.
2018-11-21 Uros Bizjak
Revert the revert:
2013-10-26 Vladimir Makarov
Revert:
2013-10-25 Vladimir Makarov
* lra-spills.c (lra_final_code_change): Remove useless move insns.
Patch was bootstrapped and regression tested on x86_64-linux-gnu {,-m32}.
OK for mainline?
Sure, Uros. I support the patch. But I think it would be wise to
postpone its committing after releasing GCC-9. Simply it is hard to
predict the patch effect to other targets and I would avoid any risk at
this stage.
[1] https://gcc.gnu.org/ml/gcc-patches/2013-10/msg02208.html
Uros.
New German PO file for 'gcc' (version 9.1-b20190414)
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 German team of translators. The file is available at: https://translationproject.org/latest/gcc/de.po (This file, 'gcc-9.1-b20190414.de.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.
[PATCH] PR fortran/90166 -- check F2018:C1547
The attached patch fixes PR fortran/91066. The original
code was feeding a nonsense string of tokens to the
assembler causing it to toss its cookies. It turns out
that gfortran was not enforcing the constraint C1547
from Fortran 2018. The attached patch now performs
that check. Regression tested on x86_64-*-freebsd.
OK to commit?
2019-04-19 Steven G. Kargl
PR fortran/90166
* decl.c (in_module_or_interface): New function to check that the
current state is in a module, submodule, or interface.
(gfc_match_prefix): Use it.
PR fortran/90166
* gfortran.dg/submodule_22.f08: Add additional dg-error comments.
--
Steve
Index: gcc/fortran/decl.c
===
--- gcc/fortran/decl.c (revision 270181)
+++ gcc/fortran/decl.c (working copy)
@@ -6070,7 +6070,29 @@ cleanup:
return m;
}
+static bool
+in_module_or_interface(void)
+{
+ if (gfc_current_state () == COMP_MODULE
+ || gfc_current_state () == COMP_SUBMODULE
+ || gfc_current_state () == COMP_INTERFACE)
+return true;
+ if (gfc_state_stack->state == COMP_CONTAINS
+ || gfc_state_stack->state == COMP_FUNCTION
+ || gfc_state_stack->state == COMP_SUBROUTINE)
+{
+ gfc_state_data *p;
+ for (p = gfc_state_stack->previous; p ; p = p->previous)
+ {
+ if (p->state == COMP_MODULE || p->state == COMP_SUBMODULE
+ || p->state == COMP_INTERFACE)
+ return true;
+ }
+}
+return false;
+}
+
/* Match a prefix associated with a function or subroutine
declaration. If the typespec pointer is nonnull, then a typespec
can be matched. Note that if nothing matches, MATCH_YES is
@@ -6102,6 +6124,13 @@ gfc_match_prefix (gfc_typespec *ts)
{
if (!gfc_notify_std (GFC_STD_F2008, "MODULE prefix at %C"))
goto error;
+
+ if (!in_module_or_interface ())
+ {
+ gfc_error ("MODULE prefix at %C found outside of a module, "
+ "submodule, or INTERFACE");
+ goto error;
+ }
current_attr.module_procedure = 1;
found_prefix = true;
Index: gcc/testsuite/gfortran.dg/submodule_22.f08
===
--- gcc/testsuite/gfortran.dg/submodule_22.f08 (revision 270181)
+++ gcc/testsuite/gfortran.dg/submodule_22.f08 (working copy)
@@ -40,8 +40,10 @@ end
submodule (mtop:submod:subsubmod) subsubsubmod ! { dg-error "Syntax error in SUBMODULE statement" }
contains
- module subroutine sub3
-r = 2.0
-s = 2.0
- end subroutine sub3
+ module subroutine sub3 ! { dg-error "found outside of a module" }
+r = 2.0 ! { dg-error "Unexpected assignment" }
+s = 2.0 ! { dg-error "Unexpected assignment" }
+ end subroutine sub3 ! { dg-error "Expecting END PROGRAM statement" }
end
+
+found outside of a module
Re: [PATCH 3/3] Fix condition for std::variant to be copy constructible
On 17/04/19 17:12 +0100, Jonathan Wakely wrote: The standard says the std::variant copy constructor is defined as deleted unless all alternative types are copy constructible, but we were making it also depend on move constructible. It turns out that was changed by https://wg21.link/lwg2904 and we're missing the rest of that resolution too. Patch coming soon ...
Re: [PATCH] Delegate PSTL configuration to pstl/pstl_config.h
On 18/04/19 17:02 -0700, Thomas Rodgers wrote: * include/bits/c++config: Remove explicit PSTL configuration macros and use definitions from . OK for trunk, thanks.
Re: [PATCH] Cleanup algorithm implementations
On 19/04/19 11:59 -0700, Thomas Rodgers wrote: * include/pstl/glue_algorithm_impl.h (stable_sort): Forward execution policy. (mismatch): Forward execution policy. (equal): Qualify call to std::equal(). (partial_sort): Forward execution policy. (inplace_merge): Forward execution policy. OK for trunk, thanks.
Re: [PATCH] Cleanup algorithm implementations
On Fri, 19 Apr 2019 at 22:00, Thomas Rodgers wrote: > > * include/pstl/glue_algorithm_impl.h (stable_sort): Forward > execution policy. > (mismatch): Forward execution policy. > (equal): Qualify call to std::equal(). > (partial_sort): Forward execution policy. > (inplace_merge): Forward execution policy. +1, looks good to me.
New German PO file for 'gcc' (version 9.1-b20190414)
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 German team of translators. The file is available at: https://translationproject.org/latest/gcc/de.po (This file, 'gcc-9.1-b20190414.de.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.
Re: [PATCH, LRA]: Revert the revert of removal of usless move insns.
On Wed, Nov 21, 2018 at 1:45 PM Vladimir Makarov wrote:
>
>
>
> On 11/21/2018 02:33 PM, Uros Bizjak wrote:
> > Hello!
> >
> > Before the recent patch to post-reload mode switching, vzeroupper
> > insertion depended on the existence of the return copy instructions
> > pair in functions that return a value. The first instruction in the
> > pair represents a move to a function return hard register, and the
> > second was a USE of the function return hard register. Sometimes a nop
> > move was generated (e.g. %eax->%eax) for the first instruction of the
> > return copy instructions pair and the patch [1] teached LRA to remove
> > these useless instructions on the fly.
> >
> > The removal caused optimize mode switching to trigger the assert,
> > since the first instruction of a return pair was not found. The
> > relevant part of the patch was later reverted. With the recent
> > optimize mode switching patch, this is no longer necessary for
> > vzeroupper insertion pass, so attached patch reverts the revert.
> >
> > 2018-11-21 Uros Bizjak
> >
> > Revert the revert:
> > 2013-10-26 Vladimir Makarov
> >
> > Revert:
> > 2013-10-25 Vladimir Makarov
> >
> > * lra-spills.c (lra_final_code_change): Remove useless move insns.
> >
> > Patch was bootstrapped and regression tested on x86_64-linux-gnu {,-m32}.
> >
> > OK for mainline?
> Sure. Thank you, Uros.
> > [1] https://gcc.gnu.org/ml/gcc-patches/2013-10/msg02208.html
> >
> > Uros.
>
This caused:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90178
--
H.J.
[PATCH] Cleanup algorithm implementations
* include/pstl/glue_algorithm_impl.h (stable_sort): Forward
execution policy.
(mismatch): Forward execution policy.
(equal): Qualify call to std::equal().
(partial_sort): Forward execution policy.
(inplace_merge): Forward execution policy.
>From ce0ae4e065692da6d0dcdb0f7ba5d2f3db4d3ec7 Mon Sep 17 00:00:00 2001
From: Thomas Rodgers
Date: Fri, 19 Apr 2019 11:16:44 -0700
Subject: [PATCH] Cleanup algorithm implementations
* include/pstl/glue_algorithm_impl.h (stable_sort): Forward
execution policy.
(mismatch): Forward execution policy.
(equal): Qualify call to std::equal().
(partial_sort): Forward execution policy.
(inplace_merge): Forward execution policy.
---
libstdc++-v3/include/pstl/glue_algorithm_impl.h | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/libstdc++-v3/include/pstl/glue_algorithm_impl.h b/libstdc++-v3/include/pstl/glue_algorithm_impl.h
index db5ef2b76f5..1c4a3511a48 100644
--- a/libstdc++-v3/include/pstl/glue_algorithm_impl.h
+++ b/libstdc++-v3/include/pstl/glue_algorithm_impl.h
@@ -674,7 +674,7 @@ __pstl::__internal::__enable_if_execution_policy<_ExecutionPolicy, void>
stable_sort(_ExecutionPolicy&& __exec, _RandomAccessIterator __first, _RandomAccessIterator __last)
{
typedef typename std::iterator_traits<_RandomAccessIterator>::value_type _InputType;
-std::stable_sort(__exec, __first, __last, std::less<_InputType>());
+std::stable_sort(std::forward<_ExecutionPolicy>(__exec), __first, __last, std::less<_InputType>());
}
// [mismatch]
@@ -696,8 +696,8 @@ __pstl::__internal::__enable_if_execution_policy<_ExecutionPolicy, std::pair<_Fo
mismatch(_ExecutionPolicy&& __exec, _ForwardIterator1 __first1, _ForwardIterator1 __last1, _ForwardIterator2 __first2,
_BinaryPredicate __pred)
{
-return std::mismatch(__exec, __first1, __last1, __first2, std::next(__first2, std::distance(__first1, __last1)),
- __pred);
+return std::mismatch(std::forward<_ExecutionPolicy>(__exec), __first1, __last1, __first2,
+ std::next(__first2, std::distance(__first1, __last1)), __pred);
}
template
@@ -757,8 +757,8 @@ __pstl::__internal::__enable_if_execution_policy<_ExecutionPolicy, bool>
equal(_ExecutionPolicy&& __exec, _ForwardIterator1 __first1, _ForwardIterator1 __last1, _ForwardIterator2 __first2,
_ForwardIterator2 __last2)
{
-return equal(std::forward<_ExecutionPolicy>(__exec), __first1, __last1, __first2, __last2,
- __pstl::__internal::__pstl_equal());
+return std::equal(std::forward<_ExecutionPolicy>(__exec), __first1, __last1, __first2, __last2,
+ __pstl::__internal::__pstl_equal());
}
// [alg.move]
@@ -798,7 +798,7 @@ partial_sort(_ExecutionPolicy&& __exec, _RandomAccessIterator __first, _RandomAc
_RandomAccessIterator __last)
{
typedef typename iterator_traits<_RandomAccessIterator>::value_type _InputType;
-std::partial_sort(__exec, __first, __middle, __last, std::less<_InputType>());
+std::partial_sort(std::forward<_ExecutionPolicy>(__exec), __first, __middle, __last, std::less<_InputType>());
}
// [partial.sort.copy]
@@ -908,7 +908,7 @@ inplace_merge(_ExecutionPolicy&& __exec, _BidirectionalIterator __first, _Bidire
_BidirectionalIterator __last)
{
typedef typename std::iterator_traits<_BidirectionalIterator>::value_type _InputType;
-std::inplace_merge(__exec, __first, __middle, __last, std::less<_InputType>());
+std::inplace_merge(std::forward<_ExecutionPolicy>(__exec), __first, __middle, __last, std::less<_InputType>());
}
// [includes]
--
2.20.1
Re: [PATCH] PR translation/90118 Missing space between words
On 4/19/19 3:38 AM, Jakub Jelinek wrote:
On Fri, Apr 19, 2019 at 11:28:41AM +0200, Christophe Lyon wrote:
--- a/contrib/check-internal-format-escaping.py
+++ b/contrib/check-internal-format-escaping.py
@@ -58,6 +58,10 @@ for i, l in enumerate(lines):
print('%s: %s' % (origin, text))
if re.search("[^%]'", p):
print('%s: %s' % (origin, text))
+# %< should not be preceded by a non-punctuation
+# %character.
+if re.search("[a-zA-Z0-9]%<", p):
+print('%s: %s' % (origin, text))
j += 1
I'm not convinced we want this in check-internal-format-escaping.py
exactly because it is too fragile.
I have a patch that adds a -Wformat-diag warning that can detect
some of these kinds of problems. For cases where the missing space
is intentional it relies on a pair of adjacent directives, as in
"%s%<%>foo" or "%s%s" with the "foo" being an argument.
Instead, we want what David Malcolm has proposed, for GCC 10 some
-Wformat-something (non-default) style warning or even a warning for
all string literals when there is
"str"
" str2"
or
"str"
"str2"
-Wformat-diag doesn't handle this because it runs as part of -Wformat
Basically require if there is a line break between two concatenated string
literals that there is a single space, either at the end of one chunk or
at the beginning of the other one.
...so that would still be a useful feature.
Martin
Re: [Patch, fortran] PR57284 - [OOP] ICE with find_array_spec for polymorphic arrays
On Fri, Apr 19, 2019 at 06:19:00PM +0100, Paul Richard Thomas wrote: > The part of this patch in resolve.c had essentially already been > sorted out by Tobias Burnus in comment #2 of the PR. I suspect that he > must have been put off the trail by the segfault that occurred when > this was implemented. In the end, the reason for the segfault is quite > straight forward and comes about because the temporary declarations > representing class actual arguments cause gfc_conv_component_ref to > barf, when porcessing the _data component. However, they are amenable > to gfc_class_data_get and so this is used in the fix. > > Bootstrapped and regtested on FC29/x86_64 - OK for trunk? > Looks good to me. Where are we in the release cycle? Do you need release manager approval to apply the patch? -- Steve
[Patch, fortran] PR57284 - [OOP] ICE with find_array_spec for polymorphic arrays
The part of this patch in resolve.c had essentially already been
sorted out by Tobias Burnus in comment #2 of the PR. I suspect that he
must have been put off the trail by the segfault that occurred when
this was implemented. In the end, the reason for the segfault is quite
straight forward and comes about because the temporary declarations
representing class actual arguments cause gfc_conv_component_ref to
barf, when porcessing the _data component. However, they are amenable
to gfc_class_data_get and so this is used in the fix.
Bootstrapped and regtested on FC29/x86_64 - OK for trunk?
Paul
2019-04-19 Paul Thomas
PR fortran/57284
* resolve.c (find_array_spec): If this is a class expression
and the symbol and component array specs are the same, this is
not an error.
*trans-intrinsic.c (gfc_conv_intrinsic_size): If a class symbol
argument, has no namespace, it has come from the interface
mapping and the _data component must be accessed directly.
2019-04-19 Paul Thomas
PR fortran/57284
* gfortran.dg/class_70.f03
Index: gcc/fortran/resolve.c
===
*** gcc/fortran/resolve.c (revision 270352)
--- gcc/fortran/resolve.c (working copy)
*** find_array_spec (gfc_expr *e)
*** 4712,4720
gfc_array_spec *as;
gfc_component *c;
gfc_ref *ref;
if (e->symtree->n.sym->ts.type == BT_CLASS)
! as = CLASS_DATA (e->symtree->n.sym)->as;
else
as = e->symtree->n.sym->as;
--- 4712,4724
gfc_array_spec *as;
gfc_component *c;
gfc_ref *ref;
+ bool class_as = false;
if (e->symtree->n.sym->ts.type == BT_CLASS)
! {
! as = CLASS_DATA (e->symtree->n.sym)->as;
! class_as = true;
! }
else
as = e->symtree->n.sym->as;
*** find_array_spec (gfc_expr *e)
*** 4733,4739
c = ref->u.c.component;
if (c->attr.dimension)
{
! if (as != NULL)
gfc_internal_error ("find_array_spec(): unused as(1)");
as = c->as;
}
--- 4737,4743
c = ref->u.c.component;
if (c->attr.dimension)
{
! if (as != NULL && !(class_as && as == c->as))
gfc_internal_error ("find_array_spec(): unused as(1)");
as = c->as;
}
Index: gcc/fortran/trans-intrinsic.c
===
*** gcc/fortran/trans-intrinsic.c (revision 270352)
--- gcc/fortran/trans-intrinsic.c (working copy)
*** gfc_conv_intrinsic_size (gfc_se * se, gf
*** 7446,7451
--- 7446,7453
tree fncall0;
tree fncall1;
gfc_se argse;
+ gfc_expr *e;
+ gfc_symbol *sym = NULL;
gfc_init_se (, NULL);
actual = expr->value.function.actual;
*** gfc_conv_intrinsic_size (gfc_se * se, gf
*** 7453,7464
if (actual->expr->ts.type == BT_CLASS)
gfc_add_class_array_ref (actual->expr);
argse.data_not_needed = 1;
! if (gfc_is_class_array_function (actual->expr))
{
/* For functions that return a class array conv_expr_descriptor is not
able to get the descriptor right. Therefore this special case. */
! gfc_conv_expr_reference (, actual->expr);
argse.expr = gfc_build_addr_expr (NULL_TREE,
gfc_class_data_get (argse.expr));
}
--- 7455,7485
if (actual->expr->ts.type == BT_CLASS)
gfc_add_class_array_ref (actual->expr);
+ e = actual->expr;
+
+ /* These are emerging from the interface mapping, when a class valued
+ function appears as the rhs in a realloc on assign statement, where
+ the size of the result is that of one of the actual arguments. */
+ if (e->expr_type == EXPR_VARIABLE
+ && e->symtree->n.sym->ns == NULL /* This is distinctive! */
+ && e->symtree->n.sym->ts.type == BT_CLASS
+ && e->ref && e->ref->type == REF_COMPONENT
+ && strcmp (e->ref->u.c.component->name, "_data") == 0)
+ sym = e->symtree->n.sym;
+
argse.data_not_needed = 1;
! if (gfc_is_class_array_function (e))
{
/* For functions that return a class array conv_expr_descriptor is not
able to get the descriptor right. Therefore this special case. */
! gfc_conv_expr_reference (, e);
! argse.expr = gfc_build_addr_expr (NULL_TREE,
! gfc_class_data_get (argse.expr));
! }
! else if (sym && sym->backend_decl)
! {
! gcc_assert (GFC_CLASS_TYPE_P (TREE_TYPE (sym->backend_decl)));
! argse.expr = sym->backend_decl;
argse.expr = gfc_build_addr_expr (NULL_TREE,
gfc_class_data_get (argse.expr));
}
Index: gcc/testsuite/gfortran.dg/class_70.f03
===
*** gcc/testsuite/gfortran.dg/class_70.f03 (nonexistent)
--- gcc/testsuite/gfortran.dg/class_70.f03 (working copy)
***
*** 0
--- 1,38
+ ! { dg-do run }
+ !
+ ! Test the fix for PR57284 - [OOP] ICE with find_array_spec for polymorphic
+ ! arrays.
Re: [PATCH] tree-call-cdce: If !HONOR_NANS do not make code with NaNs (PR88055)
On Fri, Apr 19, 2019 at 10:15:31AM -0600, Jeff Law wrote:
> On 4/18/19 3:23 PM, Segher Boessenkool wrote:
> > If we don't HONOR_NANS we should not try to use any unordered
> > comparison results. Best case those will just be optimized away;
> > realistically, they ICE. For example, the rs6000 backend has some
> > code that specifically checks we never do this.
> >
> > This patch fixes it. Bootstrapped and tested on powerpc64-linux
> > {-m32,-m64}. Is this okay for trunk?
> >
> > 2019-04-18 Segher Boessenkool
> >
> > PR tree-optimization/88055
> > * tree-call-cdce.c (comparison_code_if_no_nans): New function.
> > (gen_one_condition): Use it if !HONOR_NANS.
> ISTM that this should have been marked as a regression since presumably
> at some point we didn't try to eliminate the call and thus wouldn't have
> generated the problematic code and ICE'd.
Yes, I just still don't know how to mark things as regressions. It's a
GCC 9 regression.
> Thus, OK for gcc-9.
Thanks!
Segher
Re: [PATCH] tree-call-cdce: If !HONOR_NANS do not make code with NaNs (PR88055)
On 4/18/19 3:23 PM, Segher Boessenkool wrote:
> If we don't HONOR_NANS we should not try to use any unordered
> comparison results. Best case those will just be optimized away;
> realistically, they ICE. For example, the rs6000 backend has some
> code that specifically checks we never do this.
>
> This patch fixes it. Bootstrapped and tested on powerpc64-linux
> {-m32,-m64}. Is this okay for trunk?
>
>
> Segher
>
>
> 2019-04-18 Segher Boessenkool
>
> PR tree-optimization/88055
> * tree-call-cdce.c (comparison_code_if_no_nans): New function.
> (gen_one_condition): Use it if !HONOR_NANS.
ISTM that this should have been marked as a regression since presumably
at some point we didn't try to eliminate the call and thus wouldn't have
generated the problematic code and ICE'd.
Thus, OK for gcc-9.
jeff
libgo patch committed: Define SockaddrDataLink on AIX
This patch by Clément Chigot defines SockaddrDatalink on AIX. It is
required for the golang.org/x/net repo. Bootstrapped on
x86_64-pc-linux-gnu. Committed to mainline.
Ian
Index: gcc/go/gofrontend/MERGE
===
--- gcc/go/gofrontend/MERGE (revision 270434)
+++ gcc/go/gofrontend/MERGE (working copy)
@@ -1,4 +1,4 @@
-ecbd6562aff604b9559f63d714e922a0c9c2a77f
+1d2b98a4af0188f3f1d4a3eaae928e1db8383a63
The first line of this file holds the git revision number of the last
merge done from the gofrontend repository.
Index: libgo/go/syscall/socket_aix.go
===
--- libgo/go/syscall/socket_aix.go (revision 270373)
+++ libgo/go/syscall/socket_aix.go (working copy)
@@ -11,6 +11,7 @@ import "unsafe"
const SizeofSockaddrInet4 = 16
const SizeofSockaddrInet6 = 28
const SizeofSockaddrUnix = 1025
+const SizeofSockaddrDatalink = 128
type RawSockaddrInet4 struct {
Lenuint8
@@ -87,3 +88,26 @@ func GetsockoptIPv6MTUInfo(fd, level, op
err := getsockopt(fd, level, opt, unsafe.Pointer(), )
return , err
}
+
+type SockaddrDatalink struct {
+ Lenuint8
+ Family uint8
+ Index uint16
+ Type uint8
+ Nlen uint8
+ Alen uint8
+ Slen uint8
+ Data [120]uint8
+ rawRawSockaddrDatalink
+}
+
+type RawSockaddrDatalink struct {
+ Lenuint8
+ Family uint8
+ Index uint16
+ Type uint8
+ Nlen uint8
+ Alen uint8
+ Slen uint8
+ Data [120]uint8
+}
Re: [PATCH] Fix PR90131, wrong-debug
On 4/19/19 3:26 AM, Jakub Jelinek wrote: > On Thu, Apr 18, 2019 at 11:20:32AM +0200, Richard Biener wrote: >> >> This fixes another case similar to the fixed PR89892, mergephi >> via remove_forwarder_block_with_phi caused out-of-date debug >> binds to become live and thus needs similar treatment as >> remove_forwarder_block. Previously it didn't even bother >> to move debug stmts because the destination always has >> multiple predecessors. Now we have to move and reset them. >> >> Fixed by factoring out a worker from remove_forwarder_block and >> using that from remove_forwarder_block_with_phi as well. >> >> Bootstrap & regtest running on x86_64-unknown-linux-gnu. > > This regressed quite a few guality tests on both x86_64 and i686: > +FAIL: gcc.dg/guality/pr54519-1.c -O3 -g -DPREVENT_OPTIMIZATION line 20 x > == 36 > +FAIL: gcc.dg/guality/pr54519-1.c -O3 -g -DPREVENT_OPTIMIZATION line 20 y > == 25 > +FAIL: gcc.dg/guality/pr54519-1.c -O3 -g -DPREVENT_OPTIMIZATION line 20 z > == 6 > +FAIL: gcc.dg/guality/pr54519-1.c -O3 -g -DPREVENT_OPTIMIZATION line 23 x > == 98 > +FAIL: gcc.dg/guality/pr54519-1.c -O3 -g -DPREVENT_OPTIMIZATION line 23 y > == 117 > +FAIL: gcc.dg/guality/pr54519-1.c -O3 -g -DPREVENT_OPTIMIZATION line 23 z > == 8 > +FAIL: gcc.dg/guality/pr54519-2.c -O2 -flto -fuse-linker-plugin > -fno-fat-lto-objects -DPREVENT_OPTIMIZATION line 17 x == 6 > +FAIL: gcc.dg/guality/pr54519-2.c -O3 -g -DPREVENT_OPTIMIZATION line 17 x > == 6 > +FAIL: gcc.dg/guality/pr54519-2.c -O3 -g -DPREVENT_OPTIMIZATION line 17 y > == 25 > +FAIL: gcc.dg/guality/pr54519-3.c -O2 -DPREVENT_OPTIMIZATION line 20 x == > 36 > +FAIL: gcc.dg/guality/pr54519-3.c -O2 -DPREVENT_OPTIMIZATION line 20 y == > 25 > +FAIL: gcc.dg/guality/pr54519-3.c -O2 -DPREVENT_OPTIMIZATION line 20 z == > 6 > +FAIL: gcc.dg/guality/pr54519-3.c -O2 -DPREVENT_OPTIMIZATION line 23 x == > 98 > +FAIL: gcc.dg/guality/pr54519-3.c -O2 -DPREVENT_OPTIMIZATION line 23 y == > 117 > +FAIL: gcc.dg/guality/pr54519-3.c -O2 -DPREVENT_OPTIMIZATION line 23 z == > 8 > +FAIL: gcc.dg/guality/pr54519-3.c -O2 -flto -fno-use-linker-plugin > -flto-partition=none -DPREVENT_OPTIMIZATION line 20 x == 36 > +FAIL: gcc.dg/guality/pr54519-3.c -O2 -flto -fno-use-linker-plugin > -flto-partition=none -DPREVENT_OPTIMIZATION line 23 x == 98 > +FAIL: gcc.dg/guality/pr54519-3.c -O2 -flto -fuse-linker-plugin > -fno-fat-lto-objects -DPREVENT_OPTIMIZATION line 20 x == 36 > +FAIL: gcc.dg/guality/pr54519-3.c -O2 -flto -fuse-linker-plugin > -fno-fat-lto-objects -DPREVENT_OPTIMIZATION line 23 x == 98 > +FAIL: gcc.dg/guality/pr54519-3.c -O3 -g -DPREVENT_OPTIMIZATION line 20 x > == 36 > +FAIL: gcc.dg/guality/pr54519-3.c -O3 -g -DPREVENT_OPTIMIZATION line 20 y > == 25 > +FAIL: gcc.dg/guality/pr54519-3.c -O3 -g -DPREVENT_OPTIMIZATION line 20 z > == 6 > +FAIL: gcc.dg/guality/pr54519-3.c -O3 -g -DPREVENT_OPTIMIZATION line 23 x > == 98 > +FAIL: gcc.dg/guality/pr54519-3.c -O3 -g -DPREVENT_OPTIMIZATION line 23 y > == 117 > +FAIL: gcc.dg/guality/pr54519-3.c -O3 -g -DPREVENT_OPTIMIZATION line 23 z > == 8 > +FAIL: gcc.dg/guality/pr54519-3.c -Os -DPREVENT_OPTIMIZATION line 20 x == > 36 > +FAIL: gcc.dg/guality/pr54519-3.c -Os -DPREVENT_OPTIMIZATION line 20 y == > 25 > +FAIL: gcc.dg/guality/pr54519-3.c -Os -DPREVENT_OPTIMIZATION line 20 z == > 6 > +FAIL: gcc.dg/guality/pr54519-3.c -Os -DPREVENT_OPTIMIZATION line 23 x == > 98 > +FAIL: gcc.dg/guality/pr54519-3.c -Os -DPREVENT_OPTIMIZATION line 23 y == > 117 > +FAIL: gcc.dg/guality/pr54519-3.c -Os -DPREVENT_OPTIMIZATION line 23 z == > 8 > +FAIL: gcc.dg/guality/pr54519-4.c -O2 -DPREVENT_OPTIMIZATION line 17 x == > 6 > +FAIL: gcc.dg/guality/pr54519-4.c -O2 -DPREVENT_OPTIMIZATION line 17 y == > 25 > +FAIL: gcc.dg/guality/pr54519-4.c -O2 -flto -fno-use-linker-plugin > -flto-partition=none -DPREVENT_OPTIMIZATION line 17 x == 6 > +FAIL: gcc.dg/guality/pr54519-4.c -O2 -flto -fuse-linker-plugin > -fno-fat-lto-objects -DPREVENT_OPTIMIZATION line 17 x == 6 > +FAIL: gcc.dg/guality/pr54519-4.c -O3 -g -DPREVENT_OPTIMIZATION line 17 x > == 6 > +FAIL: gcc.dg/guality/pr54519-4.c -O3 -g -DPREVENT_OPTIMIZATION line 17 y > == 25 > +FAIL: gcc.dg/guality/pr54519-4.c -Os -DPREVENT_OPTIMIZATION line 17 x == > 6 > +FAIL: gcc.dg/guality/pr54519-4.c -Os -DPREVENT_OPTIMIZATION line 17 y == > 25 > +FAIL: gcc.dg/guality/pr54519-5.c -O2 -flto -fuse-linker-plugin > -fno-fat-lto-objects -DPREVENT_OPTIMIZATION line 17 x == 6 > +FAIL: gcc.dg/guality/pr54519-5.c -O3 -g -DPREVENT_OPTIMIZATION line 17 x > == 6 > +FAIL: gcc.dg/guality/pr54519-5.c -O3 -g -DPREVENT_OPTIMIZATION line 17 y > == 25 > +FAIL: gcc.dg/guality/pr54519-6.c -Os -DPREVENT_OPTIMIZATION line 11 x == > 2 > +FAIL: gcc.dg/guality/pr54519-6.c -Os -DPREVENT_OPTIMIZATION line 11 y == > 0 > +FAIL: gcc.dg/guality/pr68860-1.c -O2
Fwd:
Gcc https://www.mdmgames.com/dreamweddingdemo/trk.aspx?t=outbound=http://tiny.cc/jxwe5y -- Forwarded message - From: crcha...@yahoo.co.uk Date: Friday, April 19, 2019 04:23:36 PM Subject: To: http://www.bing.com/search?q==DDKYZRVTSTV=GRHBQVUGHPRRFER
Re: [PATCH] PR translation/90118 Missing space between words
On Fri, 19 Apr 2019 at 11:57, Richard Sandiford
wrote:
>
> Christophe Lyon writes:
> > On Fri, 19 Apr 2019 at 11:23, Richard Sandiford
> > wrote:
> >>
> >> Christophe Lyon writes:
> >> > On Thu, 18 Apr 2019 at 18:25, Richard Sandiford
> >> > wrote:
> >> >>
> >> >> Christophe Lyon writes:
> >> >> > Hi,
> >> >> >
> >> >> > This patch adds the missing space before '%<' in
> >> >> > config/aarch64/aarch64.c and gcc/cp/call.c. It also updates the
> >> >> > check-internal-format-escaping.py checker to warn about such cases.
> >> >> >
> >> >> > OK?
> >> >> >
> >> >> > Christophe
> >> >> >
> >> >> > diff --git a/contrib/check-internal-format-escaping.py
> >> >> > b/contrib/check-internal-format-escaping.py
> >> >> > index aac4f9e..9c62586 100755
> >> >> > --- a/contrib/check-internal-format-escaping.py
> >> >> > +++ b/contrib/check-internal-format-escaping.py
> >> >> > @@ -58,6 +58,10 @@ for i, l in enumerate(lines):
> >> >> > print('%s: %s' % (origin, text))
> >> >> > if re.search("[^%]'", p):
> >> >> > print('%s: %s' % (origin, text))
> >> >> > +# %< should not be preceded by a non-punctuation
> >> >> > +# %character.
> >> >> > +if re.search("[a-zA-Z0-9]%<", p):
> >> >> > +print('%s: %s' % (origin, text))
> >> >> > j += 1
> >> >> >
> >> >> > origin = None
> >> >> > diff --git a/gcc/config/aarch64/aarch64.c
> >> >> > b/gcc/config/aarch64/aarch64.c
> >> >> > index 9be7548..b66071f 100644
> >> >> > --- a/gcc/config/aarch64/aarch64.c
> >> >> > +++ b/gcc/config/aarch64/aarch64.c
> >> >> > @@ -11483,7 +11483,7 @@ aarch64_override_options_internal (struct
> >> >> > gcc_options *opts)
> >> >> >if (aarch64_stack_protector_guard == SSP_GLOBAL
> >> >> >&& opts->x_aarch64_stack_protector_guard_offset_str)
> >> >> > {
> >> >> > - error ("incompatible options
> >> >> > %<-mstack-protector-guard=global%> and"
> >> >> > + error ("incompatible options
> >> >> > %<-mstack-protector-guard=global%> and "
> >> >> >"%<-mstack-protector-guard-offset=%s%>",
> >> >> >aarch64_stack_protector_guard_offset_str);
> >> >> > }
> >> >> > diff --git a/gcc/cp/call.c b/gcc/cp/call.c
> >> >> > index 9582345..8f3d019 100644
> >> >> > --- a/gcc/cp/call.c
> >> >> > +++ b/gcc/cp/call.c
> >> >> > @@ -3614,16 +3614,16 @@ print_z_candidate (location_t loc, const char
> >> >> > *msgstr,
> >> >> > {
> >> >> >cloc = loc;
> >> >> >if (candidate->num_convs == 3)
> >> >> > - inform (cloc, "%s%<%D(%T, %T, %T)%> ", msg, fn,
> >> >> > + inform (cloc, "%s %<%D(%T, %T, %T)%> ", msg, fn,
> >> >> > candidate->convs[0]->type,
> >> >> > candidate->convs[1]->type,
> >> >> > candidate->convs[2]->type);
> >> >> >else if (candidate->num_convs == 2)
> >> >> > - inform (cloc, "%s%<%D(%T, %T)%> ", msg, fn,
> >> >> > + inform (cloc, "%s %<%D(%T, %T)%> ", msg, fn,
> >> >> > candidate->convs[0]->type,
> >> >> > candidate->convs[1]->type);
> >> >> >else
> >> >> > - inform (cloc, "%s%<%D(%T)%> ", msg, fn,
> >> >> > + inform (cloc, "%s %<%D(%T)%> ", msg, fn,
> >> >> > candidate->convs[0]->type);
> >> >> > }
> >> >> >else if (TYPE_P (fn))
> >> >>
> >> >> I don't think this is right, since msg already has a space where
> >> >> necessary:
> >> >>
> >> >> const char *msg = (msgstr == NULL
> >> >> ? ""
> >> >> : ACONCAT ((msgstr, " ", NULL)));
> >> >>
> >> >> Adding something like "(^| )[^% ]*" to the start of the regexp might
> >> >> avoid that, at the risk of letting through real problems.
> >> >>
> >> >
> >> > Yes, that would miss the problem in aarch64.c.
> >>
> >> Are you sure? It works for me.
> >>
> > It didn't work for me, with that change the line didn't report any error.
>
> Hmm, OK. With:
>
> if re.search("(^| )[^% ]*[a-zA-Z0-9]%<", p):
> print('%s: %s' % (origin, text))
>
> and a tree without your aarch64.c fix, I get:
>
> #: config/aarch64/aarch64.c:11486: incompatible options
> %<-mstack-protector-guard=global%> and%<-mstack-"
>
> but no warning about the cp/call.c stuff.
>
This works for me too. I don't know what I got wrong in my previous check.
So... what should I do? Apply you patch, or revert mine according to
Jakub's comments?
Improving the checker now would help fixing these annoying things
without waiting for gcc-10
Christophe
> Thanks,
> Richard
Re: [PATCH] Fix tree-outof-ssa.c ICE with vector types (PR middle-end/90139)
On April 19, 2019 10:52:50 AM GMT+02:00, Jakub Jelinek wrote:
>Hi!
>
>We use SSA_NAMEs even for vector types which have BLKmode, e.g. neither
>x86
>nor sparc targets have V1SFmode and thus such VECTOR_TYPEs have
>BLKmode.
>In some cases outof ssa subpass calls get_temp_reg, but that will
>gen_reg_rtx (BLKmode) in that case, which is something that doesn't
>really
>work. The following patch fixes it by using a stack slot for the
>BLKmode
>SSA_NAMEs instead.
>
>Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
OK.
Richard.
>2019-04-19 Jakub Jelinek
>
> PR middle-end/90139
> * tree-outof-ssa.c (get_temp_reg): If reg_mode is BLKmode, return
> assign_temp instead of gen_reg_rtx.
>
> * gcc.c-torture/compile/pr90139.c: New test.
>
>--- gcc/tree-outof-ssa.c.jj2019-03-19 07:46:45.136798336 +0100
>+++ gcc/tree-outof-ssa.c 2019-04-18 15:40:33.801698542 +0200
>@@ -653,6 +653,8 @@ get_temp_reg (tree name)
> tree type = TREE_TYPE (name);
> int unsignedp;
> machine_mode reg_mode = promote_ssa_mode (name, );
>+ if (reg_mode == BLKmode)
>+return assign_temp (type, 0, 0);
> rtx x = gen_reg_rtx (reg_mode);
> if (POINTER_TYPE_P (type))
> mark_reg_pointer (x, TYPE_ALIGN (TREE_TYPE (type)));
>--- gcc/testsuite/gcc.c-torture/compile/pr90139.c.jj 2019-04-18
>15:39:16.121974160 +0200
>+++ gcc/testsuite/gcc.c-torture/compile/pr90139.c 2019-04-18
>15:37:08.947062569 +0200
>@@ -0,0 +1,20 @@
>+/* PR middle-end/90139 */
>+
>+typedef float __attribute__((vector_size (sizeof (float V;
>+void bar (int, V *);
>+int l;
>+
>+void
>+foo (void)
>+{
>+ V n, b, o;
>+ while (1)
>+switch (l)
>+ {
>+ case 0:
>+ o = n;
>+ n = b;
>+ b = o;
>+ bar (1, );
>+ }
>+}
>
> Jakub
Re: [PATCH] PR translation/90118 Missing space between words
Christophe Lyon writes:
> On Fri, 19 Apr 2019 at 11:23, Richard Sandiford
> wrote:
>>
>> Christophe Lyon writes:
>> > On Thu, 18 Apr 2019 at 18:25, Richard Sandiford
>> > wrote:
>> >>
>> >> Christophe Lyon writes:
>> >> > Hi,
>> >> >
>> >> > This patch adds the missing space before '%<' in
>> >> > config/aarch64/aarch64.c and gcc/cp/call.c. It also updates the
>> >> > check-internal-format-escaping.py checker to warn about such cases.
>> >> >
>> >> > OK?
>> >> >
>> >> > Christophe
>> >> >
>> >> > diff --git a/contrib/check-internal-format-escaping.py
>> >> > b/contrib/check-internal-format-escaping.py
>> >> > index aac4f9e..9c62586 100755
>> >> > --- a/contrib/check-internal-format-escaping.py
>> >> > +++ b/contrib/check-internal-format-escaping.py
>> >> > @@ -58,6 +58,10 @@ for i, l in enumerate(lines):
>> >> > print('%s: %s' % (origin, text))
>> >> > if re.search("[^%]'", p):
>> >> > print('%s: %s' % (origin, text))
>> >> > +# %< should not be preceded by a non-punctuation
>> >> > +# %character.
>> >> > +if re.search("[a-zA-Z0-9]%<", p):
>> >> > +print('%s: %s' % (origin, text))
>> >> > j += 1
>> >> >
>> >> > origin = None
>> >> > diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
>> >> > index 9be7548..b66071f 100644
>> >> > --- a/gcc/config/aarch64/aarch64.c
>> >> > +++ b/gcc/config/aarch64/aarch64.c
>> >> > @@ -11483,7 +11483,7 @@ aarch64_override_options_internal (struct
>> >> > gcc_options *opts)
>> >> >if (aarch64_stack_protector_guard == SSP_GLOBAL
>> >> >&& opts->x_aarch64_stack_protector_guard_offset_str)
>> >> > {
>> >> > - error ("incompatible options %<-mstack-protector-guard=global%>
>> >> > and"
>> >> > + error ("incompatible options %<-mstack-protector-guard=global%>
>> >> > and "
>> >> >"%<-mstack-protector-guard-offset=%s%>",
>> >> >aarch64_stack_protector_guard_offset_str);
>> >> > }
>> >> > diff --git a/gcc/cp/call.c b/gcc/cp/call.c
>> >> > index 9582345..8f3d019 100644
>> >> > --- a/gcc/cp/call.c
>> >> > +++ b/gcc/cp/call.c
>> >> > @@ -3614,16 +3614,16 @@ print_z_candidate (location_t loc, const char
>> >> > *msgstr,
>> >> > {
>> >> >cloc = loc;
>> >> >if (candidate->num_convs == 3)
>> >> > - inform (cloc, "%s%<%D(%T, %T, %T)%> ", msg, fn,
>> >> > + inform (cloc, "%s %<%D(%T, %T, %T)%> ", msg, fn,
>> >> > candidate->convs[0]->type,
>> >> > candidate->convs[1]->type,
>> >> > candidate->convs[2]->type);
>> >> >else if (candidate->num_convs == 2)
>> >> > - inform (cloc, "%s%<%D(%T, %T)%> ", msg, fn,
>> >> > + inform (cloc, "%s %<%D(%T, %T)%> ", msg, fn,
>> >> > candidate->convs[0]->type,
>> >> > candidate->convs[1]->type);
>> >> >else
>> >> > - inform (cloc, "%s%<%D(%T)%> ", msg, fn,
>> >> > + inform (cloc, "%s %<%D(%T)%> ", msg, fn,
>> >> > candidate->convs[0]->type);
>> >> > }
>> >> >else if (TYPE_P (fn))
>> >>
>> >> I don't think this is right, since msg already has a space where
>> >> necessary:
>> >>
>> >> const char *msg = (msgstr == NULL
>> >> ? ""
>> >> : ACONCAT ((msgstr, " ", NULL)));
>> >>
>> >> Adding something like "(^| )[^% ]*" to the start of the regexp might
>> >> avoid that, at the risk of letting through real problems.
>> >>
>> >
>> > Yes, that would miss the problem in aarch64.c.
>>
>> Are you sure? It works for me.
>>
> It didn't work for me, with that change the line didn't report any error.
Hmm, OK. With:
if re.search("(^| )[^% ]*[a-zA-Z0-9]%<", p):
print('%s: %s' % (origin, text))
and a tree without your aarch64.c fix, I get:
#: config/aarch64/aarch64.c:11486: incompatible options
%<-mstack-protector-guard=global%> and%<-mstack-"
but no warning about the cp/call.c stuff.
Thanks,
Richard
Re: [C++ PATCH] Fix process_template_parm error-recovery (PR c++/90138)
OK.
On Fri, Apr 19, 2019 at 1:43 AM Jakub Jelinek wrote:
>
> Hi!
>
> On the following testcase, there is a type template argument, for which
> we create a decl (decl == parm in that case) and pushdecl it. But, if
> the pushdecl detects a redeclaration in that scope, duplicate_decls will
> ggc_free the decl passed to it and we then add that ggc_freed tree into the
> template parameter TREE_LIST.
>
> The following patch fixes that by using the result value from pushdecl.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
>
> 2019-04-19 Jakub Jelinek
>
> PR c++/90138
> * pt.c (process_template_parm): Set decl to pushdecl result. If
> !is_non_type, also set parm to that.
>
> * g++.dg/template/pr90138.C: New test.
>
> --- gcc/cp/pt.c.jj 2019-04-18 12:16:47.0 +0200
> +++ gcc/cp/pt.c 2019-04-18 14:12:36.765494173 +0200
> @@ -4433,7 +4433,9 @@ process_template_parm (tree list, locati
> process_template_parm could fail. */
>tree reqs = finish_shorthand_constraint (parm, constr);
>
> - pushdecl (decl);
> + decl = pushdecl (decl);
> + if (!is_non_type)
> +parm = decl;
>
>/* Build the parameter node linking the parameter declaration,
> its default argument (if any), and its constraints (if any). */
> --- gcc/testsuite/g++.dg/template/pr90138.C.jj 2019-04-18 14:58:06.035564846
> +0200
> +++ gcc/testsuite/g++.dg/template/pr90138.C 2019-04-18 14:57:27.056206214
> +0200
> @@ -0,0 +1,5 @@
> +// PR c++/90138
> +
> +template <, typename T, typename typename, typename T> // { dg-error
> "expected" }
> +struct S; // { dg-error "no default" }
> +// { dg-error "two or more" "" { target *-*-* } .-2 }
>
> Jakub
Re: [C/C++ PATCH] Fix promoted switch condition out of range diagnostics (PR c/89888, take 2)
On Fri, Apr 19, 2019 at 1:39 AM Jakub Jelinek wrote: > > On Thu, Apr 18, 2019 at 10:41:55PM -0700, Jason Merrill wrote: > > > + node = splay_tree_predecessor (cases, (splay_tree_key) min_value); > > ... > > > + if (CASE_HIGH ((tree) node->value) > > > + && tree_int_cst_compare (CASE_HIGH ((tree) node->value), > > > + min_value) >= 0) > > ... > > > + node = splay_tree_predecessor (cases, > > > +(splay_tree_key) min_value); > > > > > + node = splay_tree_lookup (cases, (splay_tree_key) max_value); > > > + if (node == NULL) > > > + node = splay_tree_predecessor (cases, (splay_tree_key) max_value); > > > + /* Handle a single node that might partially overlap the range. */ > > > + if (node > > > + && node->key > > > + && CASE_HIGH ((tree) node->value) > > > + && tree_int_cst_compare (CASE_HIGH ((tree) node->value), > > > + max_value) > 0) > > ... > > > + while ((node = splay_tree_successor (cases, > > > + (splay_tree_key) max_value)) > > > > Hmm, why are the code sections for dealing with the lower bound and > > upper bound asymmetrical? That is, why not start the upper bound > > consideration with splay_tree_successor? > > Because of the case 1 ... 4: GNU extension. Without that it would be > mostly symmetrical (well, there still would be a difference, because we put > the default: before all other cases, so we still need to test > node->key != 0 for the splay_tree_predecessor case but don't have to test > that for splay_tree_successor. But with the GNU extension, we still use > the low bound of the range as the key, which makes it asymmetrical. > > splay_tree_predecessor (cases, (splay_tree_key) min_value) > if it is not default: can be either the overlapping case (first part of the > range outside of range, then part of the range in range of the corresponding > type) or non-overlapping case. There is at most one overlapping case there > and all further predecessors are necessarily outside of range. > > On the other side, > splay_tree_successor (cases, (splay_tree_key) max_value) > is never default: and is always completely outside of range (and its > successors are as well). If we want to find the (single) overlapping case > that > overlaps the max_value, then it could be either > splay_tree_lookup (cases, (splay_tree_key) max_value) > or > splay_tree_predecessor (cases, (splay_tree_key) max_value) > (the first one if there is e.g. a range case max_value ... max_value + N: > and the second one if there is e.g. a range case max_value - M ... max_value > + N: where both M and N are positive integers). > > Of course, the overlapping case could be also > case min_value - M ... max_value + N: > in which case both the earlier and later code will find the same node and > each will complain about one boundary of that node and adjust that boundary. Aha, thanks. The patch is OK. Jason
Re: [PATCH] PR translation/90118 Missing space between words
On Fri, Apr 19, 2019 at 11:28:41AM +0200, Christophe Lyon wrote:
> > >> > --- a/contrib/check-internal-format-escaping.py
> > >> > +++ b/contrib/check-internal-format-escaping.py
> > >> > @@ -58,6 +58,10 @@ for i, l in enumerate(lines):
> > >> > print('%s: %s' % (origin, text))
> > >> > if re.search("[^%]'", p):
> > >> > print('%s: %s' % (origin, text))
> > >> > +# %< should not be preceded by a non-punctuation
> > >> > +# %character.
> > >> > +if re.search("[a-zA-Z0-9]%<", p):
> > >> > +print('%s: %s' % (origin, text))
> > >> > j += 1
I'm not convinced we want this in check-internal-format-escaping.py
exactly because it is too fragile.
Instead, we want what David Malcolm has proposed, for GCC 10 some
-Wformat-something (non-default) style warning or even a warning for
all string literals when there is
"str "
" str2"
or
"str"
"str2"
Basically require if there is a line break between two concatenated string
literals that there is a single space, either at the end of one chunk or
at the beginning of the other one.
Jakub
Re: [PATCH] PR translation/90118 Missing space between words
On Fri, 19 Apr 2019 at 11:23, Richard Sandiford
wrote:
>
> Christophe Lyon writes:
> > On Thu, 18 Apr 2019 at 18:25, Richard Sandiford
> > wrote:
> >>
> >> Christophe Lyon writes:
> >> > Hi,
> >> >
> >> > This patch adds the missing space before '%<' in
> >> > config/aarch64/aarch64.c and gcc/cp/call.c. It also updates the
> >> > check-internal-format-escaping.py checker to warn about such cases.
> >> >
> >> > OK?
> >> >
> >> > Christophe
> >> >
> >> > diff --git a/contrib/check-internal-format-escaping.py
> >> > b/contrib/check-internal-format-escaping.py
> >> > index aac4f9e..9c62586 100755
> >> > --- a/contrib/check-internal-format-escaping.py
> >> > +++ b/contrib/check-internal-format-escaping.py
> >> > @@ -58,6 +58,10 @@ for i, l in enumerate(lines):
> >> > print('%s: %s' % (origin, text))
> >> > if re.search("[^%]'", p):
> >> > print('%s: %s' % (origin, text))
> >> > +# %< should not be preceded by a non-punctuation
> >> > +# %character.
> >> > +if re.search("[a-zA-Z0-9]%<", p):
> >> > +print('%s: %s' % (origin, text))
> >> > j += 1
> >> >
> >> > origin = None
> >> > diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
> >> > index 9be7548..b66071f 100644
> >> > --- a/gcc/config/aarch64/aarch64.c
> >> > +++ b/gcc/config/aarch64/aarch64.c
> >> > @@ -11483,7 +11483,7 @@ aarch64_override_options_internal (struct
> >> > gcc_options *opts)
> >> >if (aarch64_stack_protector_guard == SSP_GLOBAL
> >> >&& opts->x_aarch64_stack_protector_guard_offset_str)
> >> > {
> >> > - error ("incompatible options %<-mstack-protector-guard=global%>
> >> > and"
> >> > + error ("incompatible options %<-mstack-protector-guard=global%>
> >> > and "
> >> >"%<-mstack-protector-guard-offset=%s%>",
> >> >aarch64_stack_protector_guard_offset_str);
> >> > }
> >> > diff --git a/gcc/cp/call.c b/gcc/cp/call.c
> >> > index 9582345..8f3d019 100644
> >> > --- a/gcc/cp/call.c
> >> > +++ b/gcc/cp/call.c
> >> > @@ -3614,16 +3614,16 @@ print_z_candidate (location_t loc, const char
> >> > *msgstr,
> >> > {
> >> >cloc = loc;
> >> >if (candidate->num_convs == 3)
> >> > - inform (cloc, "%s%<%D(%T, %T, %T)%> ", msg, fn,
> >> > + inform (cloc, "%s %<%D(%T, %T, %T)%> ", msg, fn,
> >> > candidate->convs[0]->type,
> >> > candidate->convs[1]->type,
> >> > candidate->convs[2]->type);
> >> >else if (candidate->num_convs == 2)
> >> > - inform (cloc, "%s%<%D(%T, %T)%> ", msg, fn,
> >> > + inform (cloc, "%s %<%D(%T, %T)%> ", msg, fn,
> >> > candidate->convs[0]->type,
> >> > candidate->convs[1]->type);
> >> >else
> >> > - inform (cloc, "%s%<%D(%T)%> ", msg, fn,
> >> > + inform (cloc, "%s %<%D(%T)%> ", msg, fn,
> >> > candidate->convs[0]->type);
> >> > }
> >> >else if (TYPE_P (fn))
> >>
> >> I don't think this is right, since msg already has a space where necessary:
> >>
> >> const char *msg = (msgstr == NULL
> >> ? ""
> >> : ACONCAT ((msgstr, " ", NULL)));
> >>
> >> Adding something like "(^| )[^% ]*" to the start of the regexp might
> >> avoid that, at the risk of letting through real problems.
> >>
> >
> > Yes, that would miss the problem in aarch64.c.
>
> Are you sure? It works for me.
>
It didn't work for me, with that change the line didn't report any error.
> The idea is to treat any immediately-adjoining non-whitespace sequence as
> punctuation rather than a word if it includes a % character.
>
> >> The aarch64.c change is definitely OK though, thanks for the catch.
> >>
> >
> > I'll committ the aarch64.c and check-internal-format-escaping.py parts.
>
> I wasn't sure whether we wanted to avoid false positives, so that anyone
> running the script doesn't need to repeat the same thought process.
>
> Thanks,
> Richard
Re: [PATCH] Fix PR90131, wrong-debug
On Thu, Apr 18, 2019 at 11:20:32AM +0200, Richard Biener wrote: > > This fixes another case similar to the fixed PR89892, mergephi > via remove_forwarder_block_with_phi caused out-of-date debug > binds to become live and thus needs similar treatment as > remove_forwarder_block. Previously it didn't even bother > to move debug stmts because the destination always has > multiple predecessors. Now we have to move and reset them. > > Fixed by factoring out a worker from remove_forwarder_block and > using that from remove_forwarder_block_with_phi as well. > > Bootstrap & regtest running on x86_64-unknown-linux-gnu. This regressed quite a few guality tests on both x86_64 and i686: +FAIL: gcc.dg/guality/pr54519-1.c -O3 -g -DPREVENT_OPTIMIZATION line 20 x == 36 +FAIL: gcc.dg/guality/pr54519-1.c -O3 -g -DPREVENT_OPTIMIZATION line 20 y == 25 +FAIL: gcc.dg/guality/pr54519-1.c -O3 -g -DPREVENT_OPTIMIZATION line 20 z == 6 +FAIL: gcc.dg/guality/pr54519-1.c -O3 -g -DPREVENT_OPTIMIZATION line 23 x == 98 +FAIL: gcc.dg/guality/pr54519-1.c -O3 -g -DPREVENT_OPTIMIZATION line 23 y == 117 +FAIL: gcc.dg/guality/pr54519-1.c -O3 -g -DPREVENT_OPTIMIZATION line 23 z == 8 +FAIL: gcc.dg/guality/pr54519-2.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects -DPREVENT_OPTIMIZATION line 17 x == 6 +FAIL: gcc.dg/guality/pr54519-2.c -O3 -g -DPREVENT_OPTIMIZATION line 17 x == 6 +FAIL: gcc.dg/guality/pr54519-2.c -O3 -g -DPREVENT_OPTIMIZATION line 17 y == 25 +FAIL: gcc.dg/guality/pr54519-3.c -O2 -DPREVENT_OPTIMIZATION line 20 x == 36 +FAIL: gcc.dg/guality/pr54519-3.c -O2 -DPREVENT_OPTIMIZATION line 20 y == 25 +FAIL: gcc.dg/guality/pr54519-3.c -O2 -DPREVENT_OPTIMIZATION line 20 z == 6 +FAIL: gcc.dg/guality/pr54519-3.c -O2 -DPREVENT_OPTIMIZATION line 23 x == 98 +FAIL: gcc.dg/guality/pr54519-3.c -O2 -DPREVENT_OPTIMIZATION line 23 y == 117 +FAIL: gcc.dg/guality/pr54519-3.c -O2 -DPREVENT_OPTIMIZATION line 23 z == 8 +FAIL: gcc.dg/guality/pr54519-3.c -O2 -flto -fno-use-linker-plugin -flto-partition=none -DPREVENT_OPTIMIZATION line 20 x == 36 +FAIL: gcc.dg/guality/pr54519-3.c -O2 -flto -fno-use-linker-plugin -flto-partition=none -DPREVENT_OPTIMIZATION line 23 x == 98 +FAIL: gcc.dg/guality/pr54519-3.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects -DPREVENT_OPTIMIZATION line 20 x == 36 +FAIL: gcc.dg/guality/pr54519-3.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects -DPREVENT_OPTIMIZATION line 23 x == 98 +FAIL: gcc.dg/guality/pr54519-3.c -O3 -g -DPREVENT_OPTIMIZATION line 20 x == 36 +FAIL: gcc.dg/guality/pr54519-3.c -O3 -g -DPREVENT_OPTIMIZATION line 20 y == 25 +FAIL: gcc.dg/guality/pr54519-3.c -O3 -g -DPREVENT_OPTIMIZATION line 20 z == 6 +FAIL: gcc.dg/guality/pr54519-3.c -O3 -g -DPREVENT_OPTIMIZATION line 23 x == 98 +FAIL: gcc.dg/guality/pr54519-3.c -O3 -g -DPREVENT_OPTIMIZATION line 23 y == 117 +FAIL: gcc.dg/guality/pr54519-3.c -O3 -g -DPREVENT_OPTIMIZATION line 23 z == 8 +FAIL: gcc.dg/guality/pr54519-3.c -Os -DPREVENT_OPTIMIZATION line 20 x == 36 +FAIL: gcc.dg/guality/pr54519-3.c -Os -DPREVENT_OPTIMIZATION line 20 y == 25 +FAIL: gcc.dg/guality/pr54519-3.c -Os -DPREVENT_OPTIMIZATION line 20 z == 6 +FAIL: gcc.dg/guality/pr54519-3.c -Os -DPREVENT_OPTIMIZATION line 23 x == 98 +FAIL: gcc.dg/guality/pr54519-3.c -Os -DPREVENT_OPTIMIZATION line 23 y == 117 +FAIL: gcc.dg/guality/pr54519-3.c -Os -DPREVENT_OPTIMIZATION line 23 z == 8 +FAIL: gcc.dg/guality/pr54519-4.c -O2 -DPREVENT_OPTIMIZATION line 17 x == 6 +FAIL: gcc.dg/guality/pr54519-4.c -O2 -DPREVENT_OPTIMIZATION line 17 y == 25 +FAIL: gcc.dg/guality/pr54519-4.c -O2 -flto -fno-use-linker-plugin -flto-partition=none -DPREVENT_OPTIMIZATION line 17 x == 6 +FAIL: gcc.dg/guality/pr54519-4.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects -DPREVENT_OPTIMIZATION line 17 x == 6 +FAIL: gcc.dg/guality/pr54519-4.c -O3 -g -DPREVENT_OPTIMIZATION line 17 x == 6 +FAIL: gcc.dg/guality/pr54519-4.c -O3 -g -DPREVENT_OPTIMIZATION line 17 y == 25 +FAIL: gcc.dg/guality/pr54519-4.c -Os -DPREVENT_OPTIMIZATION line 17 x == 6 +FAIL: gcc.dg/guality/pr54519-4.c -Os -DPREVENT_OPTIMIZATION line 17 y == 25 +FAIL: gcc.dg/guality/pr54519-5.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects -DPREVENT_OPTIMIZATION line 17 x == 6 +FAIL: gcc.dg/guality/pr54519-5.c -O3 -g -DPREVENT_OPTIMIZATION line 17 x == 6 +FAIL: gcc.dg/guality/pr54519-5.c -O3 -g -DPREVENT_OPTIMIZATION line 17 y == 25 +FAIL: gcc.dg/guality/pr54519-6.c -Os -DPREVENT_OPTIMIZATION line 11 x == 2 +FAIL: gcc.dg/guality/pr54519-6.c -Os -DPREVENT_OPTIMIZATION line 11 y == 0 +FAIL: gcc.dg/guality/pr68860-1.c -O2 -DPREVENT_OPTIMIZATION line 14 arg1 == 1 +FAIL: gcc.dg/guality/pr68860-1.c -O2 -DPREVENT_OPTIMIZATION line 14 arg2 == 2 +FAIL: gcc.dg/guality/pr68860-1.c -O2 -DPREVENT_OPTIMIZATION line 14 arg3 == 3 +FAIL: gcc.dg/guality/pr68860-1.c -O2
Re: [PATCH] PR translation/90118 Missing space between words
Christophe Lyon writes:
> On Thu, 18 Apr 2019 at 18:25, Richard Sandiford
> wrote:
>>
>> Christophe Lyon writes:
>> > Hi,
>> >
>> > This patch adds the missing space before '%<' in
>> > config/aarch64/aarch64.c and gcc/cp/call.c. It also updates the
>> > check-internal-format-escaping.py checker to warn about such cases.
>> >
>> > OK?
>> >
>> > Christophe
>> >
>> > diff --git a/contrib/check-internal-format-escaping.py
>> > b/contrib/check-internal-format-escaping.py
>> > index aac4f9e..9c62586 100755
>> > --- a/contrib/check-internal-format-escaping.py
>> > +++ b/contrib/check-internal-format-escaping.py
>> > @@ -58,6 +58,10 @@ for i, l in enumerate(lines):
>> > print('%s: %s' % (origin, text))
>> > if re.search("[^%]'", p):
>> > print('%s: %s' % (origin, text))
>> > +# %< should not be preceded by a non-punctuation
>> > +# %character.
>> > +if re.search("[a-zA-Z0-9]%<", p):
>> > +print('%s: %s' % (origin, text))
>> > j += 1
>> >
>> > origin = None
>> > diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
>> > index 9be7548..b66071f 100644
>> > --- a/gcc/config/aarch64/aarch64.c
>> > +++ b/gcc/config/aarch64/aarch64.c
>> > @@ -11483,7 +11483,7 @@ aarch64_override_options_internal (struct
>> > gcc_options *opts)
>> >if (aarch64_stack_protector_guard == SSP_GLOBAL
>> >&& opts->x_aarch64_stack_protector_guard_offset_str)
>> > {
>> > - error ("incompatible options %<-mstack-protector-guard=global%> and"
>> > + error ("incompatible options %<-mstack-protector-guard=global%> and
>> > "
>> >"%<-mstack-protector-guard-offset=%s%>",
>> >aarch64_stack_protector_guard_offset_str);
>> > }
>> > diff --git a/gcc/cp/call.c b/gcc/cp/call.c
>> > index 9582345..8f3d019 100644
>> > --- a/gcc/cp/call.c
>> > +++ b/gcc/cp/call.c
>> > @@ -3614,16 +3614,16 @@ print_z_candidate (location_t loc, const char
>> > *msgstr,
>> > {
>> >cloc = loc;
>> >if (candidate->num_convs == 3)
>> > - inform (cloc, "%s%<%D(%T, %T, %T)%> ", msg, fn,
>> > + inform (cloc, "%s %<%D(%T, %T, %T)%> ", msg, fn,
>> > candidate->convs[0]->type,
>> > candidate->convs[1]->type,
>> > candidate->convs[2]->type);
>> >else if (candidate->num_convs == 2)
>> > - inform (cloc, "%s%<%D(%T, %T)%> ", msg, fn,
>> > + inform (cloc, "%s %<%D(%T, %T)%> ", msg, fn,
>> > candidate->convs[0]->type,
>> > candidate->convs[1]->type);
>> >else
>> > - inform (cloc, "%s%<%D(%T)%> ", msg, fn,
>> > + inform (cloc, "%s %<%D(%T)%> ", msg, fn,
>> > candidate->convs[0]->type);
>> > }
>> >else if (TYPE_P (fn))
>>
>> I don't think this is right, since msg already has a space where necessary:
>>
>> const char *msg = (msgstr == NULL
>> ? ""
>> : ACONCAT ((msgstr, " ", NULL)));
>>
>> Adding something like "(^| )[^% ]*" to the start of the regexp might
>> avoid that, at the risk of letting through real problems.
>>
>
> Yes, that would miss the problem in aarch64.c.
Are you sure? It works for me.
The idea is to treat any immediately-adjoining non-whitespace sequence as
punctuation rather than a word if it includes a % character.
>> The aarch64.c change is definitely OK though, thanks for the catch.
>>
>
> I'll committ the aarch64.c and check-internal-format-escaping.py parts.
I wasn't sure whether we wanted to avoid false positives, so that anyone
running the script doesn't need to repeat the same thought process.
Thanks,
Richard
Re: [PATCH] PR translation/90118 Missing space between words
On Thu, 18 Apr 2019 at 18:25, Richard Sandiford
wrote:
>
> Christophe Lyon writes:
> > Hi,
> >
> > This patch adds the missing space before '%<' in
> > config/aarch64/aarch64.c and gcc/cp/call.c. It also updates the
> > check-internal-format-escaping.py checker to warn about such cases.
> >
> > OK?
> >
> > Christophe
> >
> > diff --git a/contrib/check-internal-format-escaping.py
> > b/contrib/check-internal-format-escaping.py
> > index aac4f9e..9c62586 100755
> > --- a/contrib/check-internal-format-escaping.py
> > +++ b/contrib/check-internal-format-escaping.py
> > @@ -58,6 +58,10 @@ for i, l in enumerate(lines):
> > print('%s: %s' % (origin, text))
> > if re.search("[^%]'", p):
> > print('%s: %s' % (origin, text))
> > +# %< should not be preceded by a non-punctuation
> > +# %character.
> > +if re.search("[a-zA-Z0-9]%<", p):
> > +print('%s: %s' % (origin, text))
> > j += 1
> >
> > origin = None
> > diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
> > index 9be7548..b66071f 100644
> > --- a/gcc/config/aarch64/aarch64.c
> > +++ b/gcc/config/aarch64/aarch64.c
> > @@ -11483,7 +11483,7 @@ aarch64_override_options_internal (struct
> > gcc_options *opts)
> >if (aarch64_stack_protector_guard == SSP_GLOBAL
> >&& opts->x_aarch64_stack_protector_guard_offset_str)
> > {
> > - error ("incompatible options %<-mstack-protector-guard=global%> and"
> > + error ("incompatible options %<-mstack-protector-guard=global%> and "
> >"%<-mstack-protector-guard-offset=%s%>",
> >aarch64_stack_protector_guard_offset_str);
> > }
> > diff --git a/gcc/cp/call.c b/gcc/cp/call.c
> > index 9582345..8f3d019 100644
> > --- a/gcc/cp/call.c
> > +++ b/gcc/cp/call.c
> > @@ -3614,16 +3614,16 @@ print_z_candidate (location_t loc, const char
> > *msgstr,
> > {
> >cloc = loc;
> >if (candidate->num_convs == 3)
> > - inform (cloc, "%s%<%D(%T, %T, %T)%> ", msg, fn,
> > + inform (cloc, "%s %<%D(%T, %T, %T)%> ", msg, fn,
> > candidate->convs[0]->type,
> > candidate->convs[1]->type,
> > candidate->convs[2]->type);
> >else if (candidate->num_convs == 2)
> > - inform (cloc, "%s%<%D(%T, %T)%> ", msg, fn,
> > + inform (cloc, "%s %<%D(%T, %T)%> ", msg, fn,
> > candidate->convs[0]->type,
> > candidate->convs[1]->type);
> >else
> > - inform (cloc, "%s%<%D(%T)%> ", msg, fn,
> > + inform (cloc, "%s %<%D(%T)%> ", msg, fn,
> > candidate->convs[0]->type);
> > }
> >else if (TYPE_P (fn))
>
> I don't think this is right, since msg already has a space where necessary:
>
> const char *msg = (msgstr == NULL
> ? ""
> : ACONCAT ((msgstr, " ", NULL)));
>
> Adding something like "(^| )[^% ]*" to the start of the regexp might
> avoid that, at the risk of letting through real problems.
>
Yes, that would miss the problem in aarch64.c.
> The aarch64.c change is definitely OK though, thanks for the catch.
>
I'll committ the aarch64.c and check-internal-format-escaping.py parts.
Thanks,
Christophe
> Richard
[PATCH] Fix tree-outof-ssa.c ICE with vector types (PR middle-end/90139)
Hi!
We use SSA_NAMEs even for vector types which have BLKmode, e.g. neither x86
nor sparc targets have V1SFmode and thus such VECTOR_TYPEs have BLKmode.
In some cases outof ssa subpass calls get_temp_reg, but that will
gen_reg_rtx (BLKmode) in that case, which is something that doesn't really
work. The following patch fixes it by using a stack slot for the BLKmode
SSA_NAMEs instead.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2019-04-19 Jakub Jelinek
PR middle-end/90139
* tree-outof-ssa.c (get_temp_reg): If reg_mode is BLKmode, return
assign_temp instead of gen_reg_rtx.
* gcc.c-torture/compile/pr90139.c: New test.
--- gcc/tree-outof-ssa.c.jj 2019-03-19 07:46:45.136798336 +0100
+++ gcc/tree-outof-ssa.c2019-04-18 15:40:33.801698542 +0200
@@ -653,6 +653,8 @@ get_temp_reg (tree name)
tree type = TREE_TYPE (name);
int unsignedp;
machine_mode reg_mode = promote_ssa_mode (name, );
+ if (reg_mode == BLKmode)
+return assign_temp (type, 0, 0);
rtx x = gen_reg_rtx (reg_mode);
if (POINTER_TYPE_P (type))
mark_reg_pointer (x, TYPE_ALIGN (TREE_TYPE (type)));
--- gcc/testsuite/gcc.c-torture/compile/pr90139.c.jj2019-04-18
15:39:16.121974160 +0200
+++ gcc/testsuite/gcc.c-torture/compile/pr90139.c 2019-04-18
15:37:08.947062569 +0200
@@ -0,0 +1,20 @@
+/* PR middle-end/90139 */
+
+typedef float __attribute__((vector_size (sizeof (float V;
+void bar (int, V *);
+int l;
+
+void
+foo (void)
+{
+ V n, b, o;
+ while (1)
+switch (l)
+ {
+ case 0:
+ o = n;
+ n = b;
+ b = o;
+ bar (1, );
+ }
+}
Jakub
[C++ PATCH] Fix process_template_parm error-recovery (PR c++/90138)
Hi!
On the following testcase, there is a type template argument, for which
we create a decl (decl == parm in that case) and pushdecl it. But, if
the pushdecl detects a redeclaration in that scope, duplicate_decls will
ggc_free the decl passed to it and we then add that ggc_freed tree into the
template parameter TREE_LIST.
The following patch fixes that by using the result value from pushdecl.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2019-04-19 Jakub Jelinek
PR c++/90138
* pt.c (process_template_parm): Set decl to pushdecl result. If
!is_non_type, also set parm to that.
* g++.dg/template/pr90138.C: New test.
--- gcc/cp/pt.c.jj 2019-04-18 12:16:47.0 +0200
+++ gcc/cp/pt.c 2019-04-18 14:12:36.765494173 +0200
@@ -4433,7 +4433,9 @@ process_template_parm (tree list, locati
process_template_parm could fail. */
tree reqs = finish_shorthand_constraint (parm, constr);
- pushdecl (decl);
+ decl = pushdecl (decl);
+ if (!is_non_type)
+parm = decl;
/* Build the parameter node linking the parameter declaration,
its default argument (if any), and its constraints (if any). */
--- gcc/testsuite/g++.dg/template/pr90138.C.jj 2019-04-18 14:58:06.035564846
+0200
+++ gcc/testsuite/g++.dg/template/pr90138.C 2019-04-18 14:57:27.056206214
+0200
@@ -0,0 +1,5 @@
+// PR c++/90138
+
+template <, typename T, typename typename, typename T> // { dg-error
"expected" }
+struct S; // { dg-error "no default" }
+// { dg-error "two or more" "" { target *-*-* } .-2 }
Jakub
Re: [C/C++ PATCH] Fix promoted switch condition out of range diagnostics (PR c/89888, take 2)
On Thu, Apr 18, 2019 at 10:41:55PM -0700, Jason Merrill wrote: > > + node = splay_tree_predecessor (cases, (splay_tree_key) min_value); > ... > > + if (CASE_HIGH ((tree) node->value) > > + && tree_int_cst_compare (CASE_HIGH ((tree) node->value), > > + min_value) >= 0) > ... > > + node = splay_tree_predecessor (cases, > > +(splay_tree_key) min_value); > > > + node = splay_tree_lookup (cases, (splay_tree_key) max_value); > > + if (node == NULL) > > + node = splay_tree_predecessor (cases, (splay_tree_key) max_value); > > + /* Handle a single node that might partially overlap the range. */ > > + if (node > > + && node->key > > + && CASE_HIGH ((tree) node->value) > > + && tree_int_cst_compare (CASE_HIGH ((tree) node->value), > > + max_value) > 0) > ... > > + while ((node = splay_tree_successor (cases, > > + (splay_tree_key) max_value)) > > Hmm, why are the code sections for dealing with the lower bound and > upper bound asymmetrical? That is, why not start the upper bound > consideration with splay_tree_successor? Because of the case 1 ... 4: GNU extension. Without that it would be mostly symmetrical (well, there still would be a difference, because we put the default: before all other cases, so we still need to test node->key != 0 for the splay_tree_predecessor case but don't have to test that for splay_tree_successor. But with the GNU extension, we still use the low bound of the range as the key, which makes it asymmetrical. splay_tree_predecessor (cases, (splay_tree_key) min_value) if it is not default: can be either the overlapping case (first part of the range outside of range, then part of the range in range of the corresponding type) or non-overlapping case. There is at most one overlapping case there and all further predecessors are necessarily outside of range. On the other side, splay_tree_successor (cases, (splay_tree_key) max_value) is never default: and is always completely outside of range (and its successors are as well). If we want to find the (single) overlapping case that overlaps the max_value, then it could be either splay_tree_lookup (cases, (splay_tree_key) max_value) or splay_tree_predecessor (cases, (splay_tree_key) max_value) (the first one if there is e.g. a range case max_value ... max_value + N: and the second one if there is e.g. a range case max_value - M ... max_value + N: where both M and N are positive integers). Of course, the overlapping case could be also case min_value - M ... max_value + N: in which case both the earlier and later code will find the same node and each will complain about one boundary of that node and adjust that boundary. Jakub
