Re: [PATCH] implement -Wformat-diag, v2
On Fri, Jun 21, 2019 at 3:52 PM Martin Sebor wrote: > > Most of the rest seem justified to me and worth cleaning up. Let > me know if you agree and if you'd like my help with it. Thanks. I sent https://golang.org/cl/183437 and https://golang.org/cl/183497 to take care of these. Ian
Re: [PATCH] don't trim empty string initializers for pointers (PR 90947)
On 6/21/19 8:05 PM, Martin Sebor wrote:
The solution we implemented in GCC 9 to get the mangling of
non-type template arguments of class types containing array
members consistent regardless of the form of their
initialization introduced a couple of bugs. One of these
is the subject of this patch. The bug results in stripping
trailing initializers for array elements that involve the empty
string such as in here:
void f (void)
{
const char* a[1][1] = { "" };
if (!a[0][0])
__builtin_abort ();
}
The problem is caused by relying on initializer_zerop() that
returns true for the empty string regardless of whether it's
used to initialize an array or a pointer (the function doesn't
know what the initializer is being used for).
Why doesn't the existing POINTER_TYPE_P check handle this? It's clearly
intended to.
Jason
Re: C++ PATCH to rename DEFAULT_ARG to DEFERRED_PARSE
On 6/22/19 5:57 PM, Marek Polacek wrote: Now that DEFAULT_ARG is used for more things than just default arguments, let's rename it and its related entities to something more appropriate. Bootstrapped/regtested on x86_64-linux, ok for trunk? OK, thanks. Jason
Re: C++ PATCH to detect narrowing in case values (PR c++/90805)
On 6/13/19 5:03 PM, Marek Polacek wrote: Case values are converted constant expressions, so narrowing conversion is not permitted. This patch adds detecting narrowing to case_conversion; it's a handy spot because we have both the value and the (adjusted) type of the condition. Is there a reason not to use build_converted_constant_expr? Jason
Re: Start implementing -frounding-math
On Sat, 22 Jun 2019, Richard Biener wrote: On June 22, 2019 6:10:15 PM GMT+02:00, Marc Glisse wrote: Hello, as discussed in the PR, this seems like a simple enough approach to handle FENV functionality safely, while keeping it possible to implement optimizations in the future. Some key missing things: - handle C, not just C++ (I don't care, but some people probably do) As you tackle C++, what does the standard say to constexpr contexts and FENV? That is, what's the FP environment at compiler - time (I suppose FENV modifying functions are not constexpr declared). The C++ standard doesn't care much about fenv: [Note: This document does not require an implementation to support the FENV_ACCESS pragma; it is implementation-defined (15.8) whether the pragma is supported. As a consequence, it is implementation- defined whether these functions can be used to test floating-point status flags, set floating-point control modes, or run under non-default mode settings. If the pragma is used to enable control over the floating-point environment, this document does not specify the effect on floating-point evaluation in constant expressions. — end note] We should care about the C standard, and do whatever makes sense for C++ without expecting the C++ standard to tell us exactly what that is. We can check what visual studio and intel do, but we don't have to follow them. -frounding-math is supposed to be equivalent to "#pragma stdc fenv_access on" covering the whole program. For constant expressions, I see a difference between constexpr double third = 1. / 3.; which really needs to be done at compile time, and const double third = 1. / 3.; which will try to evaluate the rhs as constexpr, but where the program is still valid if that fails. The second one clearly should refuse to be evaluated at compile time if we are specifying a dynamic rounding direction. For the first one, I am not sure. I guess you should only write that in "fenv_access off" regions and I wouldn't mind a compile error. Note that C2x adds a pragma fenv_round that specifies a rounding direction for a region of code, which seems relevant for constant expressions. That pragma looks hard, but maybe some pieces would be nice to add. - handle vectors (for complex, I don't know what it means) Then flag_trapping_math should also enable this path, meaning that we should stop making it the default, or performance will suffer. Do we need N variants of the functions to really encode FP options into the IL and thus allow inlining of say different signed-zero flag functions? Not sure what you are suggesting. I am essentially creating a new tree_code (well, an internal function) for an addition-like function that actually reads/writes memory, so it should be orthogonal to inlining, and only the front-end should care about -frounding-math. I didn't think about the interaction with signed-zero. Ah, you mean IFN_FENV_ADD_WITH_ROUNDING_AND_SIGNED_ZEROS, etc? The ones I am starting from are supposed to be safe-for-everything. As refinement, I was thinking in 2 directions: * add a third constant argument, where we can specify extra info * add a variant for the case where the function is pure (because I expect that's easier on the compiler than "pure if (arg3 & 8) != 0") I am not sure more variants are needed. Also, while rounding clearly applies to an operation, signed-zero kind of seems to apply to a variable, and in an operation, I don't really know if it means that I can pretend that an argument of -0. is +0. (I can return +inf for 1/-0.) or if it means I can return 0. when the operation should return -0.. Probably both... If we have just -fsigned-zeros but no rounding or trapping, the penalty of using an IFN would be bad. But indeed inlining functions with different -f(no-)signed-zeros forces to use -fsigned-zeros for the whole merged function if we don't encode it in the operations. Hmm I didn't look at the patch but I suppose you rely on RTL to not do code motion across FENV modifications and not fold Constants? No, I rely on asm volatile to prevent that, as in your recent hack, except that the asm only appears near expansion. I am trying to start from something safe and refine with optimizations, no subtlety. That is, don't we really need unspec_volatile variant patterns for the Operations? Yes. One future optimization (that I listed in the PR) is to let targets expand those IFN as they like (without the asm barriers), using some unspec_volatile. I hope we can get there, although just letting targets replace "=g" with whatever in the asm would already get most of the benefits. I just thought of one issue for vector intrinsics, say _mm_add_pd, where the fenv_access status that should matter is that of the caller, not the one in emmintrin.h. But since I don't have the pragma or vectors, that can wait. -- Marc Glisse
C++ PATCH to rename DEFAULT_ARG to DEFERRED_PARSE
Now that DEFAULT_ARG is used for more things than just default arguments,
let's rename it and its related entities to something more appropriate.
Bootstrapped/regtested on x86_64-linux, ok for trunk?
2019-06-22 Marek Polacek
* call.c (convert_default_arg): Use DEFERRED_PARSE instead of
DEFAULT_ARG.
* cp-objcp-common.c (cp_tree_size): Likewise. Use tree_deferred_parse
instead of tree_default_arg.
* cp-tree.def: Rename DEFAULT_ARG to DEFERRED_PARSE.
* cp-tree.h: Rename DEFARG_TOKENS to DEFPARSE_TOKENS. Rename
DEFARG_INSTANTIATIONS to DEFPARSE_INSTANTIATIONS. Rename
tree_default_arg to tree_deferred_parse.
(UNPARSED_NOEXCEPT_SPEC_P): Use DEFERRED_PARSE instead of DEFAULT_ARG.
(cp_tree_node_structure_enum): Rename TS_CP_DEFAULT_ARG to
TS_CP_DEFERRED_PARSE.
(lang_tree_node): Rename tree_default_arg to tree_deferred_parse.
Rename default_arg to deferred_parse. Use TS_CP_DEFERRED_PARSE instead
of TS_CP_DEFAULT_ARG.
(defarg_location): Remove declaration.
(defparse_location): Add declaration.
* decl.c (grokfndecl): Use DEFERRED_PARSE instead of DEFAULT_ARG.
Call defparse_location instead of defarg_location.
(check_default_argument): Use DEFERRED_PARSE instead of DEFAULT_ARG.
(cp_tree_node_structure): Likewise. Use TS_CP_DEFERRED_PARSE instead
of TS_CP_DEFAULT_ARG.
* decl2.c (grokfield): Use DEFERRED_PARSE instead of DEFAULT_ARG.
* error.c (dump_expr): Likewise.
(location_of): Likewise.
* init.c (get_nsdmi): Likewise.
* parser.c (cp_parser_save_noexcept): Likewise. Use DEFPARSE_TOKENS
instead of DEFARG_TOKENS.
(cp_parser_late_noexcept_specifier): Likewise.
(cp_parser_late_parse_one_default_arg): Use DEFPARSE_TOKENS instead
of DEFARG_TOKENS.
(cp_parser_late_parsing_default_args): Use DEFERRED_PARSE instead of
DEFAULT_ARG. Use DEFPARSE_INSTANTIATIONS instead of
DEFARG_INSTANTIATIONS.
(cp_parser_cache_defarg): Use DEFERRED_PARSE instead of DEFAULT_ARG.
Use DEFPARSE_TOKENS instead of DEFARG_TOKENS. Use
DEFPARSE_INSTANTIATIONS instead of DEFARG_INSTANTIATIONS.
(defparse_location): Renamed from defarg_location.
* pt.c (tsubst_default_argument): Use DEFERRED_PARSE instead of
DEFAULT_ARG.
(tsubst_arg_types): Likewise.
(dependent_type_p_r): Likewise.
* tree.c (cp_tree_equal): Likewise.
(cp_walk_subtrees): Likewise.
* typeck.c (convert_arguments): Likewise.
diff --git gcc/cp/call.c gcc/cp/call.c
index 8367ef7b557..e4923f4ccbf 100644
--- gcc/cp/call.c
+++ gcc/cp/call.c
@@ -7674,7 +7674,7 @@ convert_default_arg (tree type, tree arg, tree fn, int
parmnum,
/* If the ARG is an unparsed default argument expression, the
conversion cannot be performed. */
- if (TREE_CODE (arg) == DEFAULT_ARG)
+ if (TREE_CODE (arg) == DEFERRED_PARSE)
{
if (complain & tf_error)
error ("call to %qD uses the default argument for parameter %P, which "
diff --git gcc/cp/cp-objcp-common.c gcc/cp/cp-objcp-common.c
index a8f7db0854a..21d162e5d0c 100644
--- gcc/cp/cp-objcp-common.c
+++ gcc/cp/cp-objcp-common.c
@@ -67,7 +67,7 @@ cp_tree_size (enum tree_code code)
case PTRMEM_CST: return sizeof (ptrmem_cst);
case BASELINK: return sizeof (tree_baselink);
case TEMPLATE_PARM_INDEX: return sizeof (template_parm_index);
-case DEFAULT_ARG: return sizeof (tree_default_arg);
+case DEFERRED_PARSE: return sizeof (tree_deferred_parse);
case DEFERRED_NOEXCEPT:return sizeof (tree_deferred_noexcept);
case OVERLOAD: return sizeof (tree_overload);
case STATIC_ASSERT: return sizeof (tree_static_assert);
diff --git gcc/cp/cp-tree.def gcc/cp/cp-tree.def
index 475c584fd4c..4db1d316124 100644
--- gcc/cp/cp-tree.def
+++ gcc/cp/cp-tree.def
@@ -207,11 +207,11 @@ DEFTREECODE (USING_DECL, "using_decl", tcc_declaration, 0)
/* A using directive. The operand is USING_STMT_NAMESPACE. */
DEFTREECODE (USING_STMT, "using_stmt", tcc_statement, 1)
-/* An un-parsed default argument. Holds a vector of input tokens and
+/* An un-parsed operand. Holds a vector of input tokens and
a vector of places where the argument was instantiated before
- parsing had occurred. This is also used for delayed NSDMIs and
- noexcept-specifier parsing. */
-DEFTREECODE (DEFAULT_ARG, "default_arg", tcc_exceptional, 0)
+ parsing had occurred. This is used for default arguments, delayed
+ NSDMIs, and noexcept-specifier parsing. */
+DEFTREECODE (DEFERRED_PARSE, "deferred_parse", tcc_exceptional, 0)
/* An uninstantiated/unevaluated noexcept-specification. For the
uninstantiated case, DEFERRED_NOEXCEPT_PATTERN is the pattern from the
diff --git gcc/cp/cp-tree.h gcc/cp/cp-tree.h
index
[Darwin, PPC, testsuite, committed] Add requires for DFP to two tests.
The two tests use decimal floating point and therefore fail where that isn’t
available.
Fixed for Darwin by adding the relevant dg-requires lines
(I didn’t try to alter the cases for AIX, but maybe the skip lines could be
removed now).
tested on powerpc-darwin9, applied to mainline,
thanks
Iain
2019-06-22 Iain Sandoe
* gcc.target/powerpc/pr64205.c: Require effective target dfp.
* gcc.target/powerpc/pr79909.c: Likewise.
diff --git a/gcc/testsuite/gcc.target/powerpc/pr64205.c
b/gcc/testsuite/gcc.target/powerpc/pr64205.c
index 3882e3f..c726fb7 100644
--- a/gcc/testsuite/gcc.target/powerpc/pr64205.c
+++ b/gcc/testsuite/gcc.target/powerpc/pr64205.c
@@ -1,4 +1,5 @@
/* { dg-do compile { target { powerpc*-*-* && ilp32 } } } */
+/* { dg-require-effective-target dfp } */
/* { dg-skip-if "" { powerpc*-*-aix* } } */
/* { dg-options "-O2 -mdejagnu-cpu=G5 -maltivec" } */
diff --git a/gcc/testsuite/gcc.target/powerpc/pr79909.c
b/gcc/testsuite/gcc.target/powerpc/pr79909.c
index d9fb7c3..d886c32 100644
--- a/gcc/testsuite/gcc.target/powerpc/pr79909.c
+++ b/gcc/testsuite/gcc.target/powerpc/pr79909.c
@@ -1,6 +1,7 @@
/* PR rtl-optimization/79909 */
/* { dg-do compile } */
/* { dg-options "-O2 -mxl-compat" } */
+/* { dg-require-effective-target dfp } */
/* { dg-skip-if "DFP" { powerpc*-*-aix* } } */
typedef float T __attribute__ ((mode (TD)));
[Darwin, PPC, testsuite, committed] Fix darwin-bool-1.c.
This test was failing because of a pedantic warning that is unrelated to the
purpose of the test. Fixed by suppressing that warning.
tested on powerpc-darwin9, applied to mainline.
thanks
Iain
2019-06-22 Iain Sandoe
* gcc.target/powerpc/darwin-bool-1.c: Suppress the pedantic
warning about _Bool.
diff --git a/gcc/testsuite/gcc.target/powerpc/darwin-bool-1.c
b/gcc/testsuite/gcc.target/powerpc/darwin-bool-1.c
index 2f147d0..f444edf 100644
--- a/gcc/testsuite/gcc.target/powerpc/darwin-bool-1.c
+++ b/gcc/testsuite/gcc.target/powerpc/darwin-bool-1.c
@@ -1,6 +1,8 @@
/* Check that sizeof(bool) is 4 if we don't use special options. */
/* Matt Austern */
/* { dg-do run { target { powerpc*-*-darwin* && ilp32 } } } */
+/* We do need to suppress the ISO C doesn't support _Bool message tho. */
+/* { dg-options "-Wno-pedantic" } */
int dummy1[sizeof(_Bool) - 3];
int dummy2[5 - sizeof(_Bool)];
Re: [PATCH, fortran] PR89782 READ/WRITE of a character array when it is a parameter
On Sat, Jun 22, 2019 at 11:49:25AM -0700, Jerry DeLisle wrote:
> On 6/22/19 11:32 AM, Steve Kargl wrote:
> > On Sat, Jun 22, 2019 at 11:23:48AM -0700, Jerry DeLisle wrote:
> >>
> >> 2019-06-22 Jerry DeLisle
> >>
> >>PR fortran/89782
> >>* io.c (gfc_resolve_dt): Check that internal units are not
> >>character PARAMETER.
> >
> > This part of the patch is missing.
> >
> >>
> >>* gfortran.dg/io_constraints.f90: New test.
> >>
> >
> > this part looks fine, but depends on the missing part.
> >
>
> Sorry about that, I missed the HEAD in "git diff HEAD".
>
> Jerry
>
> diff --git a/gcc/fortran/io.c b/gcc/fortran/io.c
> index 425c2b86899..cd21c6bcf82 100644
> --- a/gcc/fortran/io.c
> +++ b/gcc/fortran/io.c
> @@ -3328,6 +3328,14 @@ gfc_resolve_dt (gfc_dt *dt, locus *loc)
> return false;
> }
>
> + if (e->symtree && e->symtree->n.sym->attr.flavor == FL_PARAMETER
> + && e->ts.type == BT_CHARACTER)
> +{
> + gfc_error ("UNIT specification at %L must "
> + "not be a character PARAMETER", >where);
> + return false;
> +}
> +
> if (gfc_resolve_expr (e)
> && (e->ts.type != BT_INTEGER
> && (e->ts.type != BT_CHARACTER || e->expr_type != EXPR_VARIABLE)))
Looks good. Thanks for the patch.
--
Steve
Re: [PATCH, fortran] PR89782 READ/WRITE of a character array when it is a parameter
On 6/22/19 11:32 AM, Steve Kargl wrote:
On Sat, Jun 22, 2019 at 11:23:48AM -0700, Jerry DeLisle wrote:
2019-06-22 Jerry DeLisle
PR fortran/89782
* io.c (gfc_resolve_dt): Check that internal units are not
character PARAMETER.
This part of the patch is missing.
* gfortran.dg/io_constraints.f90: New test.
this part looks fine, but depends on the missing part.
Sorry about that, I missed the HEAD in "git diff HEAD".
Jerry
diff --git a/gcc/fortran/io.c b/gcc/fortran/io.c
index 425c2b86899..cd21c6bcf82 100644
--- a/gcc/fortran/io.c
+++ b/gcc/fortran/io.c
@@ -3328,6 +3328,14 @@ gfc_resolve_dt (gfc_dt *dt, locus *loc)
return false;
}
+ if (e->symtree && e->symtree->n.sym->attr.flavor == FL_PARAMETER
+ && e->ts.type == BT_CHARACTER)
+{
+ gfc_error ("UNIT specification at %L must "
+ "not be a character PARAMETER", >where);
+ return false;
+}
+
if (gfc_resolve_expr (e)
&& (e->ts.type != BT_INTEGER
&& (e->ts.type != BT_CHARACTER || e->expr_type != EXPR_VARIABLE)))
Re: [PATCH, fortran] PR89782 READ/WRITE of a character array when it is a parameter
On Sat, Jun 22, 2019 at 11:23:48AM -0700, Jerry DeLisle wrote: > > 2019-06-22 Jerry DeLisle > > PR fortran/89782 > * io.c (gfc_resolve_dt): Check that internal units are not > character PARAMETER. This part of the patch is missing. > > * gfortran.dg/io_constraints.f90: New test. > this part looks fine, but depends on the missing part. -- Steve 20170425 https://www.youtube.com/watch?v=VWUpyCsUKR4 20161221 https://www.youtube.com/watch?v=IbCHE-hONow
[PATCH, fortran] PR89782 READ/WRITE of a character array when it is a parameter
Hi all,
The front-end is not consistently checking for errors with character parameters
as internal units. The reason is we never actually checked for this before. In
some cases an error message is triggered from other unrelated causes or
sometimes no error is given at all.
This is fixed by the attached patch that adds the check in gfc_resolve_dt. I had
to place the check before the unit expression is resolved because somewhere in
gfc_resolve_expr the attribute information does not trigger for at least one
test case (lost?).
All cases I found are included in the test case. Regression tested on
x86_64-pc-linux-gnu.
OK for trunk?
Regards,
Jerry
2019-06-22 Jerry DeLisle
PR fortran/89782
* io.c (gfc_resolve_dt): Check that internal units are not
character PARAMETER.
* gfortran.dg/io_constraints.f90: New test.
! { dg-do compile }
program pr89782
character(len=*),parameter :: VALUES(*)=[character(len=10) :: 'NaN','NAN','nan','Inf','INF','inf','Infinity']
character(len=*),parameter :: VALUE='NaN'
real(4) :: var
do i=1,size(VALUES)
read(VALUES(i),*) float ! { dg-error "character PARAMETER" }
write(VALUES(i),*)float ! { dg-error "character PARAMETER" }
enddo
read(var,*)float! { dg-error "INTEGER expression or a CHARACTER" }
read(VALUE,*)float ! { dg-error "character PARAMETER" }
write(VALUE,*)float ! { dg-error "character PARAMETER" }
end program pr89782
Re: Start implementing -frounding-math
On June 22, 2019 6:10:15 PM GMT+02:00, Marc Glisse wrote: >Hello, > >as discussed in the PR, this seems like a simple enough approach to >handle >FENV functionality safely, while keeping it possible to implement >optimizations in the future. > >Some key missing things: >- handle C, not just C++ (I don't care, but some people probably do) As you tackle C++, what does the standard say to constexpr contexts and FENV? That is, what's the FP environment at compiler - time (I suppose FENV modifying functions are not constexpr declared). >- handle vectors (for complex, I don't know what it means) > >Then flag_trapping_math should also enable this path, meaning that we >should stop making it the default, or performance will suffer. Do we need N variants of the functions to really encode FP options into the IL and thus allow inlining of say different signed-zero flag functions? I didn't look at the patch but I suppose you rely on RTL to not do code motion across FENV modifications and not fold Constants? That is, don't we really need unspec_volatile variant patterns for the Operations? Thanks for working on this. Richard. >Nice to have: >- parse the fenv_access pragma and make it set flag_rounding_math or >similar. >- sqrt > >All the optimizations can come later (I count having different >functions >for flag_rounding_math and flag_trapping_math as one such >optimization). > > >I put the lowering in its own pass, because it needs to run at -O0 and >there aren't that many passes at -O0 where I could put it. It would >probably be better to handle this directly during expansion, but with >my >knowledge of the compiler it was easier to lower it before. > >This patch passes bootstrap+regtest on x86_64. I expect it may break a >few >testcases on some targets (arm?) that check that we optimize some >things >even with -frounding-math, but as far as I am concerned those do not >count >as regressions because -frounding-math was never really implemented, so >I >would encourage target maintainers to xfail those for now. > >I'd like to handle this incrementally, rather than wait for a >mega-patch >that does everything, if that's ok. For instance, I didn't handle >vectors >in this first patch because the interaction with vector lowering was >not >completely obvious. Plus it may help get others to implement some parts >of >it ;-) > >2019-06-24 Marc Glisse > > PR middle-end/34678 >gcc/cp/ > * typeck.c (cp_build_binary_op): Generate internal functions for float > operations with -frounding-math. > >gcc/ > * Makefile.in: Handle new file gimple-lower-fenv.cc. > * gimple-lower-fenv.cc: New file. >* internal-fn.c (expand_FENV_PLUS, expand_FENV_MINUS, expand_FENV_MULT, > expand_FENV_DIV): New functions. >* internal-fn.def (FENV_PLUS, FENV_MINUS, FENV_MULT, FENV_DIV): New > internal functions. > * passes.def (pass_lower_fenv): New pass. > * tree-pass.h (make_pass_lower_fenv): Declare new function.
[committed] Fix avr port
I suspect Wilco forgot commit this hunk which fixes the avr port after the recent setjmp/longjmp changes. Tested on the avr-elf port which builds again. Committed to the trunk. Jeff commit 72f5e18d923404533b58a997735f8c09c6d12bb3 Author: law Date: Sat Jun 22 16:31:50 2019 + * config/avr/avr.c (TARGET_BUILTIN_SETJMP_FRAME_VALUE): Remove. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@272590 138bc75d-0d04-0410-961f-82ee72b054a4 diff --git a/gcc/ChangeLog b/gcc/ChangeLog index 03e17488324..d2dd391b39c 100644 --- a/gcc/ChangeLog +++ b/gcc/ChangeLog @@ -1,3 +1,7 @@ +2019-06-22 Jeff Law + + * config/avr/avr.c (TARGET_BUILTIN_SETJMP_FRAME_VALUE): Remove. + 2019-06-22 Jan Hubicka * tree-ssa-alias.c (nonoverlapping_component_refs_p): Do not diff --git a/gcc/config/avr/avr.c b/gcc/config/avr/avr.c index f3896f79cd1..873a9da6140 100644 --- a/gcc/config/avr/avr.c +++ b/gcc/config/avr/avr.c @@ -14656,9 +14656,6 @@ avr_fold_builtin (tree fndecl, int n_args ATTRIBUTE_UNUSED, tree *arg, #undef TARGET_STRICT_ARGUMENT_NAMING #define TARGET_STRICT_ARGUMENT_NAMING hook_bool_CUMULATIVE_ARGS_true -#undef TARGET_BUILTIN_SETJMP_FRAME_VALUE -#define TARGET_BUILTIN_SETJMP_FRAME_VALUE avr_builtin_setjmp_frame_value - #undef TARGET_CONDITIONAL_REGISTER_USAGE #define TARGET_CONDITIONAL_REGISTER_USAGE avr_conditional_register_usage
C++ PATCH to add tests for c++/65707, c++/89480, c++/58836
My fix for c++/60223 (ICE with T{} in non-deduced context) fixed these three
tests also. Yay!
Tested on x86_64-linux, applying to trunk.
2019-06-22 Marek Polacek
PR c++/65707
PR c++/89480
PR c++/58836
* g++.dg/cpp0x/nondeduced5.C: New test.
* g++.dg/cpp0x/nondeduced6.C: New test.
* g++.dg/cpp0x/nondeduced7.C: New test.
diff --git gcc/testsuite/g++.dg/cpp0x/nondeduced5.C
gcc/testsuite/g++.dg/cpp0x/nondeduced5.C
new file mode 100644
index 000..dd890ec4b69
--- /dev/null
+++ gcc/testsuite/g++.dg/cpp0x/nondeduced5.C
@@ -0,0 +1,12 @@
+// PR c++/65707
+// { dg-do compile { target c++11 } }
+
+template struct b {
+ typedef int c;
+ constexpr operator c() { return a; }
+};
+template struct d;
+template struct e : b {};
+template > struct f;
+template struct f{}>> {};
+template struct f;
diff --git gcc/testsuite/g++.dg/cpp0x/nondeduced6.C
gcc/testsuite/g++.dg/cpp0x/nondeduced6.C
new file mode 100644
index 000..9f68e304f03
--- /dev/null
+++ gcc/testsuite/g++.dg/cpp0x/nondeduced6.C
@@ -0,0 +1,24 @@
+// PR c++/89480
+// { dg-do compile { target c++11 } }
+
+template
+struct TSelect {};
+
+enum What {
+The
+};
+
+template
+struct AnotherOneSelector {
+static constexpr Foo Id = Foo::The;
+};
+
+template
+struct THelper;
+
+template
+struct THelper::Id}>> {};
+
+int main() {
+THelper> t;
+}
diff --git gcc/testsuite/g++.dg/cpp0x/nondeduced7.C
gcc/testsuite/g++.dg/cpp0x/nondeduced7.C
new file mode 100644
index 000..a8aa073c57e
--- /dev/null
+++ gcc/testsuite/g++.dg/cpp0x/nondeduced7.C
@@ -0,0 +1,6 @@
+// PR c++/58836
+// { dg-do compile { target c++11 } }
+
+template struct A;
+template struct A {}; // { dg-error "partial
specialization" }
+A a;
Start implementing -frounding-math
Hello,
as discussed in the PR, this seems like a simple enough approach to handle
FENV functionality safely, while keeping it possible to implement
optimizations in the future.
Some key missing things:
- handle C, not just C++ (I don't care, but some people probably do)
- handle vectors (for complex, I don't know what it means)
Then flag_trapping_math should also enable this path, meaning that we
should stop making it the default, or performance will suffer.
Nice to have:
- parse the fenv_access pragma and make it set flag_rounding_math or similar.
- sqrt
All the optimizations can come later (I count having different functions
for flag_rounding_math and flag_trapping_math as one such optimization).
I put the lowering in its own pass, because it needs to run at -O0 and
there aren't that many passes at -O0 where I could put it. It would
probably be better to handle this directly during expansion, but with my
knowledge of the compiler it was easier to lower it before.
This patch passes bootstrap+regtest on x86_64. I expect it may break a few
testcases on some targets (arm?) that check that we optimize some things
even with -frounding-math, but as far as I am concerned those do not count
as regressions because -frounding-math was never really implemented, so I
would encourage target maintainers to xfail those for now.
I'd like to handle this incrementally, rather than wait for a mega-patch
that does everything, if that's ok. For instance, I didn't handle vectors
in this first patch because the interaction with vector lowering was not
completely obvious. Plus it may help get others to implement some parts of
it ;-)
2019-06-24 Marc Glisse
PR middle-end/34678
gcc/cp/
* typeck.c (cp_build_binary_op): Generate internal functions for float
operations with -frounding-math.
gcc/
* Makefile.in: Handle new file gimple-lower-fenv.cc.
* gimple-lower-fenv.cc: New file.
* internal-fn.c (expand_FENV_PLUS, expand_FENV_MINUS, expand_FENV_MULT,
expand_FENV_DIV): New functions.
* internal-fn.def (FENV_PLUS, FENV_MINUS, FENV_MULT, FENV_DIV): New
internal functions.
* passes.def (pass_lower_fenv): New pass.
* tree-pass.h (make_pass_lower_fenv): Declare new function.
--
Marc GlisseIndex: gcc/Makefile.in
===
--- gcc/Makefile.in (revision 272586)
+++ gcc/Makefile.in (working copy)
@@ -1315,20 +1315,21 @@ OBJS = \
gimple.o \
gimple-builder.o \
gimple-expr.o \
gimple-iterator.o \
gimple-fold.o \
gimple-laddress.o \
gimple-loop-interchange.o \
gimple-loop-jam.o \
gimple-loop-versioning.o \
gimple-low.o \
+ gimple-lower-fenv.o \
gimple-pretty-print.o \
gimple-ssa-backprop.o \
gimple-ssa-evrp.o \
gimple-ssa-evrp-analyze.o \
gimple-ssa-isolate-paths.o \
gimple-ssa-nonnull-compare.o \
gimple-ssa-split-paths.o \
gimple-ssa-store-merging.o \
gimple-ssa-strength-reduction.o \
gimple-ssa-sprintf.o \
Index: gcc/cp/typeck.c
===
--- gcc/cp/typeck.c (revision 272586)
+++ gcc/cp/typeck.c (working copy)
@@ -5544,20 +5544,47 @@ cp_build_binary_op (const op_location_t
if (TREE_TYPE (cop0) != orig_type)
cop0 = cp_convert (orig_type, op0, complain);
if (TREE_TYPE (cop1) != orig_type)
cop1 = cp_convert (orig_type, op1, complain);
instrument_expr = ubsan_instrument_division (location, cop0, cop1);
}
else if (doing_shift && sanitize_flags_p (SANITIZE_SHIFT))
instrument_expr = ubsan_instrument_shift (location, code, op0, op1);
}
+ // FIXME: vectors (and complex?) as well
+ if (flag_rounding_math && SCALAR_FLOAT_TYPE_P (build_type))
+{
+ bool do_fenv_subst = true;
+ internal_fn ifn;
+ switch (resultcode)
+ {
+ case PLUS_EXPR:
+ ifn = IFN_FENV_PLUS;
+ break;
+ case MINUS_EXPR:
+ ifn = IFN_FENV_MINUS;
+ break;
+ case MULT_EXPR:
+ ifn = IFN_FENV_MULT;
+ break;
+ case RDIV_EXPR:
+ ifn = IFN_FENV_DIV;
+ break;
+ default:
+ do_fenv_subst = false;
+ }
+ if (do_fenv_subst)
+ return build_call_expr_internal_loc (location, ifn, build_type,
+ 2, op0, op1);
+}
+
result = build2_loc (location, resultcode, build_type, op0, op1);
if (final_type != 0)
result = cp_convert (final_type, result, complain);
if (instrument_expr != NULL)
result = build2 (COMPOUND_EXPR, TREE_TYPE (result),
instrument_expr, result);
if (!processing_template_decl)
{
Index: gcc/gimple-lower-fenv.cc
===
--- gcc/gimple-lower-fenv.cc (nonexistent)
+++ gcc/gimple-lower-fenv.cc (working copy)
@@ -0,0 +1,144 @@
+/* Lower correctly rounded operations.
+ Copyright (C) 2019 Free Software Foundation, Inc.
+
+This file is part of GCC.
+
+GCC is free software; you can redistribute it and/or modify it
+under the terms of the
C++ PATCH to add test for c++/66256
Now that the parsing of noexcept-specifiers is properly delayed, this test
gives the error it should.
Tested x86_64-linux, applying ot trunk.
2019-06-22 Marek Polacek
PR c++/66256
* g++.dg/cpp0x/noexcept54.C: New test.
diff --git gcc/testsuite/g++.dg/cpp0x/noexcept54.C
gcc/testsuite/g++.dg/cpp0x/noexcept54.C
new file mode 100644
index 000..20d844b8e89
--- /dev/null
+++ gcc/testsuite/g++.dg/cpp0x/noexcept54.C
@@ -0,0 +1,10 @@
+// PR c++/66256 - noexcept-specifier is a complete-class context.
+// { dg-do compile { target c++11 } }
+
+void swap(int&, int&);
+
+int& get();
+
+struct pair {
+ void swap(pair&) noexcept(noexcept(swap(get(), get( { } // { dg-error
"no matching function for call" }
+};
Re: Remove nonoverlapping_component_refs_of_decl_p
>
> Ah, no, of course not. I guess the early out here should be a
> "ignore this match" instead.
Here is updated patch with a testcase I have re-tested on x86_64-linux
and comitted. There are still few divergences left, I will debug them
now.
Again the testcase has extra wrapper in struct d to prevent oracle
giving up earlier via overlaping_range_refs.
Honza
* tree-ssa-alias.c (nonoverlapping_component_refs_p): Do not
give up on bitfields; continue searching for different refs
appearing later.
* gcc.dg/tree-ssa/alias-access-path-6.c: New testcase.
Index: tree-ssa-alias.c
===
--- tree-ssa-alias.c(revision 272510)
+++ tree-ssa-alias.c(working copy)
@@ -1350,19 +1350,16 @@ nonoverlapping_component_refs_p (const_t
same. */
if (DECL_BIT_FIELD_REPRESENTATIVE (fieldx) == fieldy
|| DECL_BIT_FIELD_REPRESENTATIVE (fieldy) == fieldx)
- {
- ++alias_stats.nonoverlapping_component_refs_p_may_alias;
- return false;
- }
+ ;
/* Different fields of the same record type cannot overlap.
??? Bitfields can overlap at RTL level so punt on them. */
- if (DECL_BIT_FIELD (fieldx) && DECL_BIT_FIELD (fieldy))
+ else if (DECL_BIT_FIELD (fieldx) && DECL_BIT_FIELD (fieldy))
+ ;
+ else
{
- ++alias_stats.nonoverlapping_component_refs_p_may_alias;
- return false;
+ ++alias_stats.nonoverlapping_component_refs_p_no_alias;
+ return true;
}
- ++alias_stats.nonoverlapping_component_refs_p_no_alias;
- return true;
}
}
if (TYPE_UID (typex) < TYPE_UID (typey))
Index: testsuite/gcc.dg/tree-ssa/alias-access-path-6.c
===
--- testsuite/gcc.dg/tree-ssa/alias-access-path-6.c (nonexistent)
+++ testsuite/gcc.dg/tree-ssa/alias-access-path-6.c (working copy)
@@ -0,0 +1,29 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -fdump-tree-optimized" } */
+
+/* This tests that nonoveralpping_component_refs does not give up
+ on field delcs and continues looking to find mismatch between
+ a1 and a2. */
+struct a {
+ int a:3;
+ int b:3;
+};
+struct b {struct a a1,a2;};
+struct c {struct b b[10];} *cptr;
+struct d {struct c c;} *dptr;
+int
+test(int i,int j)
+{
+ cptr->b[i].a1.a=0;
+ dptr->c.b[j].a2.b=1;
+ return cptr->b[i].a1.a;
+}
+int
+test2(int i,int j)
+{
+ cptr->b[i].a1.a=1;
+ dptr->c.b[j].a1.a=0;
+ return cptr->b[i].a1.a;
+}
+/* { dg-final { scan-tree-dump-times "return 0" 1 "optimized"} } */
+/* { dg-final { scan-tree-dump-not "return 1" "optimized"} } */
Re: [PATCH] Enable GCC support for AVX512_VP2INTERSECT.
On Fri, Jun 21, 2019 at 8:38 PM H.J. Lu wrote:
> > > > > > > > > >> > > +/* Register pair. */
> > > > > > > > > >> > > +VECTOR_MODES_WITH_PREFIX (P, INT, 2); /* P2QI */
> > > > > > > > > >> > > +VECTOR_MODES_WITH_PREFIX (P, INT, 4); /* P2HI P4QI */
> > > > > > > > > >> > >
> > > > > > > > > >> > > I think
> > > > > > > > > >> > >
> > > > > > > > > >> > > INT_MODE (P2QI, 16);
> > > > > > > > > >> > > INT_MODE (P2HI, 32);
> > > > Why P2QI need 16 bytes but not 2 bytes?
> > > > Same question with P2HI.
> > >
> > > Because we made a mistake. It should be 2 and 4, since these arguments
> > Then it will run into internal comiler error when building libgcc.
> > I'm still invertigating it.
> > > are bytes, not bits.
>
> I don't think we can have 2 integer modes with the same number of bytes since
> it breaks things like
>
> scalar_int_mode wider_mode = GET_MODE_WIDER_MODE (mode).require ();
>
> We can get
>
> (gdb) p mode
> $2 = {m_mode = E_SImode}
> (gdb) p wider_mode
> $3 = {m_mode = E_P2HImode}
> (gdb)
>
> Neither middle-end nor backend support it.
Ouch... It looks we hit the limitation of the middle end (which should
at least warn/error out if two modes of the same width are declared).
OTOH, we can't solve this problem by using two HI/QImode registers,
since a consecutive register pair has to be allocated It is also not
possible to overload existing SI/HImode mode with different
requirements w.r.t register pair allocation (e.g. sometimes the whole
register is allocated, and sometimes a register pair is allocated).
I think we have to invent something like SPECIAL_INT_MODE, which would
avoid mode promotion functionality (basically, it should not be listed
in mode_wider and similar arrays). This would prevent mode promotion
issues, while it would still allow to have mode, having the same width
as existing mode, but with special properties.
I'm adding Jeff and Jakub to the discussion about SPECIAL_INT_MODE.
Uros.
