[SH] PR 52483 - Fix volatile mem loads
Hi,
the attached patch fixes volatile mem loads on SH so that they won't
result in redundant sign extensions and also utilize the available
addressing modes.
Tested on rev 200116 with
make -k check RUNTESTFLAGS=--target_board=sh-sim
\{-m2/-ml,-m2/-mb,-m2a/-mb,-m4/-ml,-m4/-mb,-m4a/-ml,-m4a/-mb}
and no new failures.
OK?
Cheers,
Oleg
gcc/ChangeLog:
PR target/52483
* config/sh/predicates.md (general_extend_operand): Invoke
general_movsrc_operand for memory operands.
(general_movsrc_operand): Allow reg+reg addressing, do not
invoke use general_operand for memory operands.
testsuite/ChangeLog:
PR target/52483
* gcc.target/sh/pr52483-1.c: New.
* gcc.target/sh/pr52483-2.c: New.
* gcc.target/sh/pr52483-3.c: New.
* gcc.target/sh/pr52483-4.c: New.
* gcc.target/sh/pr52483-5.c: New.
Index: gcc/testsuite/gcc.target/sh/pr52483-2.c
===
--- gcc/testsuite/gcc.target/sh/pr52483-2.c (revision 0)
+++ gcc/testsuite/gcc.target/sh/pr52483-2.c (revision 0)
@@ -0,0 +1,59 @@
+/* Check that loads from volatile mems utilize displacement addressing
+ modes and do not result in redundant sign extensions. */
+/* { dg-do compile { target sh*-*-* } } */
+/* { dg-options -O1 } */
+/* { dg-skip-if { sh*-*-* } { -m5*} { } } */
+/* { dg-final { scan-assembler-times @\\(5, 2 } } */
+/* { dg-final { scan-assembler-times @\\(10, 2 } } */
+/* { dg-final { scan-assembler-times @\\(20, 2 } } */
+/* { dg-final { scan-assembler-times @\\(40, 2 } } */
+/* { dg-final { scan-assembler-times @\\(44, 2 } } */
+/* { dg-final { scan-assembler-not exts } } */
+
+int
+test_00 (volatile char* x)
+{
+ return x[5];
+}
+
+int
+test_01 (volatile short* x)
+{
+ return x[5];
+}
+
+int
+test_02 (volatile int* x)
+{
+ return x[5];
+}
+
+long long
+test_03 (volatile long long* x)
+{
+ return x[5];
+}
+
+unsigned int
+test_04 (volatile unsigned char* x)
+{
+ return x[5];
+}
+
+unsigned int
+test_05 (volatile unsigned short* x)
+{
+ return x[5];
+}
+
+unsigned int
+test_06 (volatile unsigned int* x)
+{
+ return x[5];
+}
+
+unsigned long long
+test_07 (volatile unsigned long long* x)
+{
+ return x[5];
+}
Index: gcc/testsuite/gcc.target/sh/pr52483-3.c
===
--- gcc/testsuite/gcc.target/sh/pr52483-3.c (revision 0)
+++ gcc/testsuite/gcc.target/sh/pr52483-3.c (revision 0)
@@ -0,0 +1,25 @@
+/* Check that loads from volatile mems utilize indexed addressing
+ modes and do not result in redundant sign extensions. */
+/* { dg-do compile { target sh*-*-* } } */
+/* { dg-options -O1 } */
+/* { dg-skip-if { sh*-*-* } { -m5*} { } } */
+/* { dg-final { scan-assembler-times @\\(r0, 3 } } */
+/* { dg-final { scan-assembler-not exts } } */
+
+int
+test_00 (volatile char* x, unsigned int y)
+{
+ return x[y];
+}
+
+int
+test_01 (volatile short* x, unsigned int y)
+{
+ return x[y];
+}
+
+int
+test_02 (volatile int* x, unsigned int y)
+{
+ return x[y];
+}
Index: gcc/testsuite/gcc.target/sh/pr52483-4.c
===
--- gcc/testsuite/gcc.target/sh/pr52483-4.c (revision 0)
+++ gcc/testsuite/gcc.target/sh/pr52483-4.c (revision 0)
@@ -0,0 +1,12 @@
+/* Check that loads from volatile floating point mems utilize indexed
+ addressing modes. */
+/* { dg-do compile { target sh*-*-* } } */
+/* { dg-options -O1 } */
+/* { dg-skip-if { sh*-*-* } { -m1 -m2 -m3 -m4al *nofpu -m4-340* -m4-400* -m4-500* -m5* } { } } */
+/* { dg-final { scan-assembler-times @\\(r0, 1 } } */
+
+float
+test_00 (volatile float* x, unsigned int y)
+{
+ return x[y];
+}
Index: gcc/testsuite/gcc.target/sh/pr52483-1.c
===
--- gcc/testsuite/gcc.target/sh/pr52483-1.c (revision 0)
+++ gcc/testsuite/gcc.target/sh/pr52483-1.c (revision 0)
@@ -0,0 +1,30 @@
+/* Check that loads from volatile mems don't result in redundant sign
+ extensions. */
+/* { dg-do compile { target sh*-*-* } } */
+/* { dg-options -O1 } */
+/* { dg-skip-if { sh*-*-* } { -m5*} { } } */
+/* { dg-final { scan-assembler-not exts } } */
+
+int
+test_00 (volatile char* x)
+{
+ return *x;
+}
+
+int
+test_01 (volatile short* x)
+{
+ return *x;
+}
+
+int
+test_02 (volatile unsigned char* x)
+{
+ return *x == 0x80;
+}
+
+int
+test_03 (volatile unsigned short* x)
+{
+ return *x == 0xFF80;
+}
Index: gcc/testsuite/gcc.target/sh/pr52483-5.c
===
--- gcc/testsuite/gcc.target/sh/pr52483-5.c (revision 0)
+++ gcc/testsuite/gcc.target/sh/pr52483-5.c (revision 0)
@@ -0,0 +1,28 @@
+/* Check that loads from volatile mems utilize post-increment addressing
+ modes and do not result in redundant sign extensions. */
+/* { dg-do compile { target sh*-*-* } } */
+/* { dg-options -O1 } */
+/* { dg-skip-if { sh*-*-* } { -m5*} { } } */
+/* { dg-final {
Re: PATCH to add include cstdlib from system.h
On Thu, 2013-06-20 at 15:21 -0400, Jason Merrill wrote: Since we poison malloc and friends in system.h, any C++ code that includes a standard library header such as algorithm, which in turn includes cstdlib, will get poisoning errors due to lines like #undef malloc using ::malloc; The solution is to include cstdlib before poisoning those identifiers. Oleg posted a variant of this patch last year, which included cstdlib instead of stdlib.h; my patch includes both to avoid issues with other library implementations in which cstdlib might not declare functions in the global namespace. Tested x86_64-pc-linux-gnu, applying to trunk. Cool, thanks! I've committed the attached patch as rev 200328, which removes the cstdlib workaround in the SH backend. Cheers, Oleg gcc/ChangeLog: * config/sh/sh.c: Remove cstdlib workaround. Index: gcc/config/sh/sh.c === --- gcc/config/sh/sh.c (revision 200327) +++ gcc/config/sh/sh.c (working copy) @@ -19,12 +19,6 @@ along with GCC; see the file COPYING3. If not see http://www.gnu.org/licenses/. */ -/* FIXME: This is a temporary hack, so that we can include algorithm - below. algorithm will try to include cstdlib which will reference - malloc co, which are poisoned by system.h. The proper solution is - to include cstdlib in system.h instead of stdlib.h. */ -#include cstdlib - #include config.h #include system.h #include coretypes.h
Re: [PATCH GCC]Fix PR57540, try to choose scaled_offset address mode when expanding array reference
On Wed, 2013-06-19 at 22:42 +0800, Bin.Cheng wrote: On Tue, Jun 18, 2013 at 10:02 PM, Oleg Endo oleg.e...@t-online.de wrote: No, I haven't disabled ivopt. But -fno-ivopts is specified in PR50749. With current implementation, auto-inc-dec iterates instructions backward, tries to find memory access and increment/decrement pairs. It will miss opportunities if instructions are interfered with each other. Sorry for the confusion. I used -fno.ivopts in the original examples in the PR to emphasize one of the auto-inc-dec problems. If ivopts is not disabled there will be no auto-inc addressing modes at all. I've added a comment in the PR clarifying this. Cheers, Oleg
Re: [c++-concepts]: Requires expression
| + // Concept extensions
| + case RID_REQUIRES:
| +return cp_parser_requires_expression (parser);
| +
I think you meant here nested requirements, not extensions as in
GNU extensions or vendor lock-ins. We should continue with nested
requirements then.
This denotes a primary expression, not a nested requirement. I was
trying to subset the requirement like the Objective-C++ expressions
comment just below it.
I changed the comment to just C++ concepts. We may get other primary
expressions related to concepts, although I don't have any planned.
| +static inline tree
| +cp_parser_requires_clause (cp_parser *parser)
| +{
| + // Parse the constant expression.
| + tree expr =
| +cp_parser_binary_expression (parser, false, false, PREC_NOT_OPERATOR,
NULL);
| + if (!require_potential_rvalue_constant_expression (expr))
| +return error_mark_node;
| + return expr;
The grammar says constant-expression. You should use
cp_parser_constant_expression.
When we started talking about requirements, we didn't want the full
breadth of an expression, so I limited it to a logical-or-expression
that is also a constant expression. Commas, assignments, and
conditions at the top-level seemed counter-intuitive.
Do we want to allow any constant expression, or should we just change
the docs to logical-or-expression that is also a constant expression?
Andrew
Re: [c++-concepts]: Requires expression
Andrew Sutton andrew.n.sut...@gmail.com writes:
| | + // Concept extensions
| | + case RID_REQUIRES:
| | +return cp_parser_requires_expression (parser);
| | +
|
| I think you meant here nested requirements, not extensions as in
| GNU extensions or vendor lock-ins. We should continue with nested
| requirements then.
|
| This denotes a primary expression, not a nested requirement. I was
| trying to subset the requirement like the Objective-C++ expressions
| comment just below it.
|
| I changed the comment to just C++ concepts. We may get other primary
| expressions related to concepts, although I don't have any planned.
OK.
| | +static inline tree
| | +cp_parser_requires_clause (cp_parser *parser)
| | +{
| | + // Parse the constant expression.
| | + tree expr =
| | +cp_parser_binary_expression (parser, false, false,
PREC_NOT_OPERATOR, NULL);
| | + if (!require_potential_rvalue_constant_expression (expr))
| | +return error_mark_node;
| | + return expr;
|
| The grammar says constant-expression. You should use
| cp_parser_constant_expression.
|
| When we started talking about requirements, we didn't want the full
| breadth of an expression, so I limited it to a logical-or-expression
| that is also a constant expression. Commas, assignments, and
| conditions at the top-level seemed counter-intuitive.
I guess what I was saying earlier was that the comment preceding the
function said constant-expression, and we want the code to match that.
I am not sure it is less counter-intuitive to allow non-toplevel comma
constant expression but disallow toplevel ones; they will all end up
being logical literal terms anyway. We shouldn't worry about
assignments, for we are enforcing the semantics constraints of constant
expressions.
| Do we want to allow any constant expression, or should we just change
| the docs to logical-or-expression that is also a constant expression?
Yes; and change the comments to say the grammar term is
logical-or-expression, with additional semantics constraint that they
must be constant expressions.
-- Gaby
Re: [c++-concepts]: Requires expression
Like this?
// Parse a requires clause.
//
//requires-clause:
// 'requires' logical-or-expression
//
// The required logical-or-expression must be a constant expression.
static tree
cp_parser_requires_clause (cp_parser *parser)
{
// Parse the constant expression.
tree expr =
cp_parser_binary_expression (parser, false, false, PREC_NOT_OPERATOR, NULL);
if (!require_potential_rvalue_constant_expression (expr))
return error_mark_node;
return expr;
}
Okay to commit?
On Sat, Jun 22, 2013 at 9:41 AM, Gabriel Dos Reis g...@axiomatics.org wrote:
Andrew Sutton andrew.n.sut...@gmail.com writes:
| | + // Concept extensions
| | + case RID_REQUIRES:
| | +return cp_parser_requires_expression (parser);
| | +
|
| I think you meant here nested requirements, not extensions as in
| GNU extensions or vendor lock-ins. We should continue with nested
| requirements then.
|
| This denotes a primary expression, not a nested requirement. I was
| trying to subset the requirement like the Objective-C++ expressions
| comment just below it.
|
| I changed the comment to just C++ concepts. We may get other primary
| expressions related to concepts, although I don't have any planned.
OK.
| | +static inline tree
| | +cp_parser_requires_clause (cp_parser *parser)
| | +{
| | + // Parse the constant expression.
| | + tree expr =
| | +cp_parser_binary_expression (parser, false, false,
PREC_NOT_OPERATOR, NULL);
| | + if (!require_potential_rvalue_constant_expression (expr))
| | +return error_mark_node;
| | + return expr;
|
| The grammar says constant-expression. You should use
| cp_parser_constant_expression.
|
| When we started talking about requirements, we didn't want the full
| breadth of an expression, so I limited it to a logical-or-expression
| that is also a constant expression. Commas, assignments, and
| conditions at the top-level seemed counter-intuitive.
I guess what I was saying earlier was that the comment preceding the
function said constant-expression, and we want the code to match that.
I am not sure it is less counter-intuitive to allow non-toplevel comma
constant expression but disallow toplevel ones; they will all end up
being logical literal terms anyway. We shouldn't worry about
assignments, for we are enforcing the semantics constraints of constant
expressions.
| Do we want to allow any constant expression, or should we just change
| the docs to logical-or-expression that is also a constant expression?
Yes; and change the comments to say the grammar term is
logical-or-expression, with additional semantics constraint that they
must be constant expressions.
-- Gaby
--
Andrew Sutton
andrew.n.sut...@gmail.com
[c++-concepts]: constraint association
I changed the implementation to associate constraints with template decls (actually lang_decl_min) rather than template_info. The handling of constrained non-template member functions changes a little. When a class template is instantiated the instantiated requirements are associated directly with the synthesized function declaration since there is no template to attach them to. These are checked in add_function_candidate. This does not include support partial template specialization or friend templates yet. I did update part of the implementation for inherited constructors, but its probably incomplete. I think I may also need to propagate constraints from constrained non-template constructors as well. Changelog: 2013-06-22 Andrew Sutton andrew.n.sut...@gmail.com * gcc/cp/cp-tree.h (tree_template_info). Remove constraint from template info. (check_template_info): Removed (unused). (TI_CONSTRAINT): Removed (no longer needed) along with related macros. (DECL_CONSTRAONTS): New. (build_template_inof): Removed overload taking constraints. (get_constraints): Removed (no longer needed). * gcc/cp/class.c (are_constrained_member_overlaods): Allow constrained member function templates to be differentiated as overloads. * gcc/cp/decl.c (decls_match): Only compare constraints on declarations. (grokfndecl): Don't pass constraints to build_template_info. * gcc/cp/tree.c (bind_template_template_parm): Don't pass constraints to build_template_info. * gcc/cp/pt.c (build_template_info): Removed overload taking constraints. (check_explicit_specialization): Don't build new constraints for template info. (build_template_decl): Pass constraints. Update docs. (process_partial_specialization): Stub out support for constrained partial specialiations. (push_template_decl_real): Build template decls with current template reqs. Don't pass constraints to build_template_info. (add_inherited_template_parms): Build new constraints from inherited template constructors. (redeclare_class_template): Update to new constraint interface. (is_compatible_template_arg): Update to new constraint interface. (lookup_template_class_1): Don't build new constraints or pass them to build_template_info. (instantiate_class_template_1): Update to new constraints interface. (tsubst_decl): Don't build new constraints or pass them to build_template_info. For function templates, explicitly instantiate new constraints for member functions of class templates. * gcc/cp/semantics.c: Associate constraints with template template parms directly, not through template info. * gcc/cp/constraint.cc (get_constraints): Remove (no longer needed) along with related functions. (check_constraints): Update to use new constraints interface. (equivalently_constrained): Update to use new constraints interface. (more_constrained): Update to use new constraints interface. * gcc/cp/parser.cpp (cp_parser_late_parsing_for_member): Update to use new constraints interface. * gcc/cp/call.c (add_function_candidate): Update to use new constraints interface. Andrew template-decl.patch Description: Binary data
Re: [c++-concepts]: Requires expression
Andrew Sutton andrew.n.sut...@gmail.com writes:
| Like this?
|
| // Parse a requires clause.
| //
| //requires-clause:
| // 'requires' logical-or-expression
| //
| // The required logical-or-expression must be a constant expression.
| static tree
| cp_parser_requires_clause (cp_parser *parser)
| {
| // Parse the constant expression.
| tree expr =
| cp_parser_binary_expression (parser, false, false, PREC_NOT_OPERATOR,
NULL);
| if (!require_potential_rvalue_constant_expression (expr))
| return error_mark_node;
| return expr;
| }
Perfect!
| Okay to commit?
Yes. Thanks,
-- Gaby
Re: [PATCH] Cilk Plus Array Notation for C++
Hmm, seems like I should have sent this yesterday even though I hadn't
made it through the whole patch. But I suppose it doesn't hurt to fix
it after checkin.
On 06/20/2013 07:39 PM, Iyer, Balaji V wrote:
diff --git a/gcc/c-family/ChangeLog b/gcc/c-family/ChangeLog
old mode 100644
new mode 100755
index a0f195b..fb70520
Binary files a/gcc/c-family/ChangeLog and b/gcc/c-family/ChangeLog differ
Why are you marking lots of files as executable?
In the future please filter out ChangeLogs entirely from diffs. I use
filterdiff -x '*/ChangeLog' | sed -e '/^diff.*ChangeLog/{N;d}'
for my own patches.
+ if (flag_enable_cilkplus
+ (contains_array_notation_expr (expr)
+ || contains_array_notation_expr (fn)))
Looking at fn here doesn't make sense; it's only used for diagnostics.
+ /* If we are using array notations, we fix them up at a later stage
+ and we will do these checks then. */
+ ;
And please don't mess with the overload resolution code directly to
handle this case differently.
This seems to be a general problem with the patch; you are
special-casing array notation all through the compiler rather than
making it work with the existing mechanisms.
In this case, an ARRAY_NOTATION_REF should have a type that participates
normally with conversions.
+ /* If the function call is builtin array notation function then no need
+to do any type conversion. */
And here, instead of changing build_over_call, you can use the existing
magic_varargs_p mechanism.
+/* This function parses Cilk Plus array notations. The starting index is
+ passed in INIT_INDEX and the array name is passed in ARRAY_VALUE. If the
+ INIT_INDEX is NULL, then we have special case were the entire array is
where
+ accessed (e.g. A[:]). The return value of this function is a tree node
+ called VALUE_TREE of type ARRAY_NOTATION_REF. If some error occurred it
Drop called VALUE_TREE; the function comment shouldn't talk about
local variables.
+ cp_token *token = NULL;
+ tree start_index = NULL_TREE, length_index = NULL_TREE, stride = NULL_TREE;
+ tree value_tree, type, array_type, array_type_domain;
+ double_int x;
+ bool saved_colon_corrects_to_scope_p = parser-colon_corrects_to_scope_p;
Now that the compiler is built as C++, variables should be defined at
the point of first use, rather than at the top of the function.
+ if (TREE_CODE (array_type) == RECORD_TYPE
+ || TREE_CODE (array_type) == POINTER_TYPE)
+ {
+ error_at (loc, start-index and length fields necessary for
+ using array notations in pointers or records);
I think this should handle all non-array types, rather than just
pointers and classes.
Let's say notation rather than notations in all diagnostics.
+ error_at (loc, array notations cannot be used with
+function pointer arrays);
I don't see this restriction in any of the documentation. What's the
rationale?
+ error_at (loc, start-index and length fields necessary for
+ using array notations in dimensionless arrays);
Let's say ...with array of unknown bound
+ start_index = fold_build1 (CONVERT_EXPR, ptrdiff_type_node,
+start_index);
Use cp_fold_convert rather than fold_build1.
+ x = TREE_INT_CST (TYPE_MAXVAL (array_type_domain));
+ x.low++;
+ length_index = double_int_to_tree (integer_type_node, x);
This assumes a constant length array. Use size_binop instead.
+ stride = build_int_cst (integer_type_node, 1);
+ stride = fold_build1 (CONVERT_EXPR, ptrdiff_type_node, stride);
Build the constant in ptrdiff_type_node rather than build it in
integer_type_node and then convert.
+ /* Disable correcting single colon correcting to scope. */
+ parser-colon_corrects_to_scope_p = false;
+ stride = cp_parser_expression (parser, false, NULL);
+ parser-colon_corrects_to_scope_p =
+ saved_colon_corrects_to_scope_p;
Why do you do this for the stride? We've already seen both
array-notation colons at this point.
+ /* We fold all 3 of the values to make things easier when we transform
+ them later. */
Why is this better than folding at transformation time?
+/* If we are here, then we have something like this:
+ ARRAY[:]
+*/
The */ should go at the end of the last line in all comments.
- if (for_offsetof)
-index = cp_parser_constant_expression (parser, false, NULL);
...
else
{
- if (cp_lexer_next_token_is (parser-lexer, CPP_OPEN_BRACE))
...
+ if (for_offsetof)
+ index = cp_parser_constant_expression (parser, false, NULL);
+ else
Please try to avoid re-indenting code when possible, to make history
annotation simpler.
Actually, to reduce
Re: [PATCH 2/2] Fix HLE example in manual
Andi Kleen a...@firstfloor.org writes: ... /* Free lock with lock elision */ -__atomic_clear(lockvar, __ATOMIC_RELEASE|__ATOMIC_HLE_RELEASE); +__atomic_store(lockvar, 0, __ATOMIC_RELEASE|__ATOMIC_HLE_RELEASE); Sorry I realized it should be actually __atomic_store_n, not __atomic_store. I will fix that as an obvious change, unless someone objects. -Andi -- a...@linux.intel.com -- Speaking for myself only
Re: [c++-concepts]: constraint association
On Sat, Jun 22, 2013 at 10:57 AM, Andrew Sutton andrew.n.sut...@gmail.com wrote: I changed the implementation to associate constraints with template decls (actually lang_decl_min) rather than template_info. Hmm, why move it to lang_decl_min? Now, every C++ declaration will have a constraint, instead of just temploids? -- Gaby
Re: [c++-concepts]: constraint association
I the long term, I think we'll end up having constraints attached to declarations wherever we constrain auto (PARM_DECL, VAR_DECL, etc). Although now that I'm looking, it seems that lang_decl_parm does not inherit lang_min. Hmm... Mostly, though, I'm not sure where I could put it where both TEMPLATE_DECL and FUNCTION_DECL would have constraints. On Sat, Jun 22, 2013 at 11:41 AM, Gabriel Dos Reis g...@integrable-solutions.net wrote: On Sat, Jun 22, 2013 at 10:57 AM, Andrew Sutton andrew.n.sut...@gmail.com wrote: I changed the implementation to associate constraints with template decls (actually lang_decl_min) rather than template_info. Hmm, why move it to lang_decl_min? Now, every C++ declaration will have a constraint, instead of just temploids? -- Gaby -- Andrew Sutton andrew.n.sut...@gmail.com
Re: [c++-concepts]: constraint association
Andrew Sutton andrew.n.sut...@gmail.com writes: | I the long term, I think we'll end up having constraints attached to | declarations wherever we constrain auto (PARM_DECL, VAR_DECL, etc). | Although now that I'm looking, it seems that lang_decl_parm does not | inherit lang_min. Hmm... | | Mostly, though, I'm not sure where I could put it where both | TEMPLATE_DECL and FUNCTION_DECL would have constraints. I think we want constraints for: * FUNCTION_DECL * TEMPLATE_DECL * TYPE_DECL * TEMPLATE_PARM_DECL Internally, we want to always store the canonical form of a decl, not the source-level form -- the current g++ AST isn't prepared for that (I wish it was, but it isn't.) This allows for simple comparison and other semantics processing. When we have void sort(Range r); and Range is a unary concept, this make 'sort' a TEMPLATE_DECL. I am not sure we actually want to make the PARM_DECL 'r' to have a constraint. Rather, we want the internal representation to store the canonical form: templatetypename __T1 requires Range__T1 void sort(__T1 r); so that the PARM_DECL 'r' never gets a constraint -- it is its type that is constrained. This way, duplicate_decls for example won't need extensive surgery to remain unconfused. -- Gaby
Re: [c++-concepts]: constraint association
On Sat, Jun 22, 2013 at 12:11 PM, Gabriel Dos Reis g...@axiomatics.org wrote: Andrew Sutton andrew.n.sut...@gmail.com writes: | I the long term, I think we'll end up having constraints attached to | declarations wherever we constrain auto (PARM_DECL, VAR_DECL, etc). | Although now that I'm looking, it seems that lang_decl_parm does not | inherit lang_min. Hmm... | | Mostly, though, I'm not sure where I could put it where both | TEMPLATE_DECL and FUNCTION_DECL would have constraints. I think we want constraints for: * FUNCTION_DECL * TEMPLATE_DECL * TYPE_DECL * TEMPLATE_PARM_DECL Well, thinking more about it, I believe we want it only for * TEMPLATE_DECL * TEMPLATE_PARM_DECL. The FUNCTION_DECL and the TYPE_DECL gets their constraints from the abstract instantiation of the associated TEMPLATE_DECL. The comment for PARM_DECL extends to VAR_DECL -- only temploids get constraints and non-temploid vars declared 'auto' at the source level have types that are TEMPLATE_TYPE_PARM, hence should get their constraints properly set. -- Gaby
Re: [c++-concepts]: constraint association
Internally, we want to always store the canonical form of a decl, not the source-level form -- the current g++ AST isn't prepared for that (I wish it was, but it isn't.) This allows for simple comparison and other semantics processing. Agreed. But without some source-level annotations in the tree, I don't think I can generate the diagnostics that programmer's might otherwise expect. I'd have to emit the internal representation. I think we want constraints for: * FUNCTION_DECL * TEMPLATE_DECL * TYPE_DECL * TEMPLATE_PARM_DECL Well, thinking more about it, I believe we want it only for * TEMPLATE_DECL * TEMPLATE_PARM_DECL. The FUNCTION_DECL and the TYPE_DECL gets their constraints from the abstract instantiation of the associated TEMPLATE_DECL. If those constraints are cached, I don't see any other place to put them except in the template info. On the other hand, it seems like the only place we actually need to worry about is with non-template member functions. I think I can just grab the requirements and arguments and check them without caching them in the template_info. I'll have to experiment. We still don't have nodes specific to TEMPLTAE_DECL or TEMPLATE_PARM_DECL though. It seems like lang_decl_min is the only place to put this where it will be avilable to both.
[Patch, Fortran] Coarrays: Don't (free)/alloc LHS coarray components on assignment
With coarrays, allocation/deallocation of coarrays requires a
synchronization with all other images. Thus, the standard restricts
changing the allocation status to: ALLOCATE and DEALLOCATE statements
plus end-of-scope deallocation.
In particular, with intrinsic assignment the allocation status does not
change. Hence, there is no realloc on assignment. But also (this patch!)
no deallocation/allocation of allocatable components during intrinsic
assignment of derived types. [This implies that the LHS componet has to
have the same allocation status, shape, type-parameters and actual type
as the RHS.]
The patch additionally checks whether end-of-scope deallocation of
coarrays properly calls the deregister function (it did/does).
Build and regtested on x86-64-gnu-linux.
OK for the trunk?
Tobias
2013-06-22 Tobias Burnus bur...@net-b.de
* trans-array.h (gfc_deallocate_alloc_comp_no_caf): New
prototype.
* trans-array.c (enum): Add DEALLOCATE_ALLOC_COMP_NO_CAF.
(structure_alloc_comps): Handle it.
(gfc_deallocate_alloc_comp_no_caf): New function.
(gfc_alloc_allocatable_for_assignment): Call it.
* trans-expr.c (gfc_trans_scalar_assign,
gfc_trans_arrayfunc_assign, gfc_trans_assignment_1): Ditto.
2013-06-22 Tobias Burnus bur...@net-b.de
* gfortran.dg/coarray_lib_realloc_1.f90: New.
diff --git a/gcc/fortran/trans-array.c b/gcc/fortran/trans-array.c
index 96162e5..076a6df 100644
--- a/gcc/fortran/trans-array.c
+++ b/gcc/fortran/trans-array.c
@@ -7414,8 +7414,8 @@ gfc_copy_allocatable_data (tree dest, tree src, tree type, int rank)
deallocate, nullify or copy allocatable components. This is the work horse
function for the functions named in this enum. */
-enum {DEALLOCATE_ALLOC_COMP = 1, NULLIFY_ALLOC_COMP, COPY_ALLOC_COMP,
- COPY_ONLY_ALLOC_COMP};
+enum {DEALLOCATE_ALLOC_COMP = 1, DEALLOCATE_ALLOC_COMP_NO_CAF,
+ NULLIFY_ALLOC_COMP, COPY_ALLOC_COMP, COPY_ONLY_ALLOC_COMP};
static tree
structure_alloc_comps (gfc_symbol * der_type, tree decl,
@@ -7546,6 +7546,7 @@ structure_alloc_comps (gfc_symbol * der_type, tree decl,
switch (purpose)
{
case DEALLOCATE_ALLOC_COMP:
+ case DEALLOCATE_ALLOC_COMP_NO_CAF:
/* gfc_deallocate_scalar_with_status calls gfc_deallocate_alloc_comp
(i.e. this function) so generate all the calls and suppress the
@@ -7553,15 +7554,17 @@ structure_alloc_comps (gfc_symbol * der_type, tree decl,
called_dealloc_with_status = false;
gfc_init_block (tmpblock);
- if (c-attr.allocatable (c-attr.dimension || c-attr.codimension)
- !c-attr.proc_pointer)
+ if (c-attr.allocatable !c-attr.proc_pointer
+ (c-attr.dimension
+ || (c-attr.codimension
+ purpose != DEALLOCATE_ALLOC_COMP_NO_CAF)))
{
comp = fold_build3_loc (input_location, COMPONENT_REF, ctype,
decl, cdecl, NULL_TREE);
tmp = gfc_trans_dealloc_allocated (comp, c-attr.codimension, NULL);
gfc_add_expr_to_block (tmpblock, tmp);
}
- else if (c-attr.allocatable)
+ else if (c-attr.allocatable !c-attr.codimension)
{
/* Allocatable scalar components. */
comp = fold_build3_loc (input_location, COMPONENT_REF, ctype,
@@ -7577,7 +7580,9 @@ structure_alloc_comps (gfc_symbol * der_type, tree decl,
build_int_cst (TREE_TYPE (comp), 0));
gfc_add_expr_to_block (tmpblock, tmp);
}
- else if (c-ts.type == BT_CLASS CLASS_DATA (c)-attr.allocatable)
+ else if (c-ts.type == BT_CLASS CLASS_DATA (c)-attr.allocatable
+ (!CLASS_DATA (c)-attr.codimension
+ || purpose != DEALLOCATE_ALLOC_COMP_NO_CAF))
{
/* Allocatable CLASS components. */
comp = fold_build3_loc (input_location, COMPONENT_REF, ctype,
@@ -7713,10 +7718,17 @@ structure_alloc_comps (gfc_symbol * der_type, tree decl,
gfc_init_block (tmpblock);
- ftn_tree = builtin_decl_explicit (BUILT_IN_MALLOC);
- tmp = build_call_expr_loc (input_location, ftn_tree, 1, size);
- gfc_add_modify (tmpblock, dst_data,
- fold_convert (TREE_TYPE (dst_data), tmp));
+ /* Coarray component have to have the same allocation status and
+ shape/type-parameter/effective-type on the LHS and RHS of an
+ intrinsic assignment. Hence, we did not deallocated them - and
+ do not allocate them here. */
+ if (!CLASS_DATA (c)-attr.codimension)
+ {
+ ftn_tree = builtin_decl_explicit (BUILT_IN_MALLOC);
+ tmp = build_call_expr_loc (input_location, ftn_tree, 1, size);
+ gfc_add_modify (tmpblock, dst_data,
+ fold_convert (TREE_TYPE (dst_data), tmp));
+ }
tmp = gfc_copy_class_to_class (comp, dcmp, nelems);
gfc_add_expr_to_block (tmpblock, tmp);
@@ -7741,7 +7753,10 @@ structure_alloc_comps (gfc_symbol * der_type, tree decl,
!cmp_has_alloc_comps)
{
rank = c-as ? c-as-rank : 0;
- tmp = gfc_duplicate_allocatable (dcmp, comp, ctype, rank);
+ if (c-attr.codimension)
+ tmp =
Re: [c++-concepts]: constraint association
Andrew Sutton andrew.n.sut...@gmail.com writes: | Internally, we want to always store the canonical form of a decl, not the | source-level form -- the current g++ AST isn't prepared for that (I wish | it was, but it isn't.) This allows for simple comparison and other | semantics processing. | | Agreed. But without some source-level annotations in the tree, I don't | think I can generate the diagnostics that programmer's might otherwise | expect. I'd have to emit the internal representation. Do you have examples where we don't do or we can't do the obvious thing in terms of diagnostics? The source-level information has to sit above the current AST representation; not mixed with it -- it doesn't expect and isn't prepared for redundancy. | I think we want constraints for: | |* FUNCTION_DECL |* TEMPLATE_DECL |* TYPE_DECL |* TEMPLATE_PARM_DECL | | Well, thinking more about it, I believe we want it only for | * TEMPLATE_DECL | * TEMPLATE_PARM_DECL. | | The FUNCTION_DECL and the TYPE_DECL gets their constraints | from the abstract instantiation of the associated TEMPLATE_DECL. | | If those constraints are cached, I don't see any other place to put | them except in the template info. Exactly. | On the other hand, it seems like the only place we actually need to | worry about is with non-template member functions. Member function of templates are temploids, so no worry there either. (Internally, they act and are represented like templates.) | I think I can just grab the requirements and arguments and check them | without caching them in the template_info. I think we need to remember them for duplicate_decls or other routines that either check or use ODR-derived properties. | I'll have to experiment. | | We still don't have nodes specific to TEMPLTAE_DECL or | TEMPLATE_PARM_DECL though. A tree with TREE_CODE equal to TEMPLATE_DECL or TEMPLATE_PARM_DECL is just that. What we do is to use all unused- tree slots. Or are you suggesting we have exhausted all available pre-defined slots on such nodes? | It seems like lang_decl_min is the only | place to put this where it will be avilable to both. We have to try hard to avoid growing lang_decl_min. -- Gaby
Re: [Patch, Fortran] Print floating-point exception status after STOP/ERROR STOP
On Fri, 21 Jun 2013, Eric Botcazou wrote: The patch silently changes libgfortran/config/fpu-sysv.h as well, breaking Solaris in the process: In file included from /nile.build/botcazou/gcc- head/src/libgfortran/runtime/fpu.c:29:0: ./fpu-target.h: In function 'get_fpu_except_flags': ./fpu-target.h:88:3: error: unknown type name 'fp_except_t' fp_except_t set_excepts; ^ make[2]: *** [fpu.lo] Error 1 make[2]: Leaving directory `/nfs/nile/nile.build/botcazou/gcc-head/sparc-sun- solaris2.10/sparc-sun-solaris2.10/libgfortran' : Fixed thusly, applied as obvious. 2013-06-21 Eric Botcazou ebotca...@adacore.com * config/fpu-sysv.h (get_fpu_except_flags): Fix typo. Except that now FreeBSD 10.x is broken. :-( In file included from /scratch2/tmp/gerald/gcc-HEAD/libgfortran/runtime/fpu.c:29:0: ./fpu-target.h: In function 'get_fpu_except_flags': ./fpu-target.h:88:3: error: unknown type name 'fp_except' fp_except set_excepts; ^ gmake[3]: *** [fpu.lo] Error 1 Excerpt from the man page on such a system: fp_except_t fpgetmask(void); fp_except_t fpsetmask(fp_except_t mask); fp_except_t fpgetsticky(void); fp_except_t fpresetsticky(fp_except_t sticky); My autoconf foo does not seem to be strong enough for libgfortran, but I assume checking for both types and then using #ifdef HAVE_FP_EXCEPT_T ...#elif HAVE_FP_EXCEPT...#endif ought to work? Gerald
Re: [Patch, Fortran] Print floating-point exception status after STOP/ERROR STOP
Except that now FreeBSD 10.x is broken. :-( Death to the guy whose thought that adding/removing _t was a good idea... In file included from /scratch2/tmp/gerald/gcc-HEAD/libgfortran/runtime/fpu.c:29:0: ./fpu-target.h: In function 'get_fpu_except_flags': ./fpu-target.h:88:3: error: unknown type name 'fp_except' fp_except set_excepts; ^ gmake[3]: *** [fpu.lo] Error 1 Excerpt from the man page on such a system: fp_except_t fpgetmask(void); fp_except_t fpsetmask(fp_except_t mask); fp_except_t fpgetsticky(void); fp_except_t fpresetsticky(fp_except_t sticky); My autoconf foo does not seem to be strong enough for libgfortran, but I assume checking for both types and then using #ifdef HAVE_FP_EXCEPT_T ...#elif HAVE_FP_EXCEPT...#endif ought to work? Yes, I think that we just need to patch the LIBGFOR_CHECK_FPSETMASK check in acinclude.m4 so as to also test the return type of the function. -- Eric Botcazou
Re: [c++-concepts]: constraint association
| Agreed. But without some source-level annotations in the tree, I don't | think I can generate the diagnostics that programmer's might otherwise | expect. I'd have to emit the internal representation. Do you have examples where we don't do or we can't do the obvious thing in terms of diagnostics? I think we'll have this problem anywhere we want to pretty-print a template parameter that's declared using the concept shorthand. I'll have a better feeling for the issue once I start working the shorthand in. | If those constraints are cached, I don't see any other place to put | them except in the template info. Exactly. Previous discussion seemed to indicate that saving constraints with template decls was preferable. | On the other hand, it seems like the only place we actually need to | worry about is with non-template member functions. Member function of templates are temploids, so no worry there either. (Internally, they act and are represented like templates.) There's a difference between when those declarations are instantiated and when their constraints really need to be evaluated. Because temploids are instantiated with a class definition (prior to use), we (may) need to carry some information with those instances. The committed version in the branch carries those constraints in template_info for the temploid. The submitted patch carries the instantiated constraints with the member declaration. The most recent version on my work computer doesn't carry any constraints with temploids -- it instantiates the requirements directly from the template/args in the declarations' template_info. | I think I can just grab the requirements and arguments and check them | without caching them in the template_info. I think we need to remember them for duplicate_decls or other routines that either check or use ODR-derived properties. This doesn't seem to be a problem. IIRC, the instantiated declarations are differentiated by their template constraints, not their instantiated constraints. Differentiating by instantiated constraints may not be viable, anyways. Especially, if the instantiation folds them to only true or false. | We still don't have nodes specific to TEMPLTAE_DECL or | TEMPLATE_PARM_DECL though. A tree with TREE_CODE equal to TEMPLATE_DECL or TEMPLATE_PARM_DECL is just that. What we do is to use all unused- tree slots. Or are you suggesting we have exhausted all available pre-defined slots on such nodes? Unknown. I'll have to look. But, I don't think we have a single TEMPLATE_PARM_DECL node. Template parameters are either TYPE_DECLs or PARM_DECLs. I think auto declarations, get VAR_DECLs, but I haven't looked closely at that design. I'd have to look to see if there are any free tree slots all of those decl nodes to minimize. Andrew
[sso] Merge from trunk @200329
Only 3 minor (self-inflicted) conflicts, but the attached patchlet is needed
after the latest LTO changes.
Bootstrapped/regtested on x86_64-suse-linux, applied on the branch.
2013-06-22 Eric Botcazou ebotca...@adacore.com
* lto-streamer-out.c (hash_tree): Deal with TYPE_REVERSE_STORAGE_ORDER.
lto/
* lto.c (compare_tree_sccs_1): Likewise.
--
Eric Botcazou--- /home/eric/svn/gcc/gcc/lto-streamer-out.c 2013-06-19 09:28:43.643284602 +0200
+++ /home/eric/svn/sso/gcc/lto-streamer-out.c 2013-06-22 16:44:02.124648377 +0200
@@ -707,7 +707,9 @@ hash_tree (struct streamer_tree_cache_d
if (code != TREE_BINFO)
v = iterative_hash_host_wide_int (TREE_PRIVATE (t), v);
if (TYPE_P (t))
-v = iterative_hash_host_wide_int (TYPE_SATURATING (t)
+v = iterative_hash_host_wide_int ((AGGREGATE_TYPE_P (t)
+ ? TYPE_REVERSE_STORAGE_ORDER (t)
+ : TYPE_SATURATING (t))
| (TYPE_ADDR_SPACE (t) 1), v);
else if (code == SSA_NAME)
v = iterative_hash_host_wide_int (SSA_NAME_IS_DEFAULT_DEF (t), v);
--- /home/eric/svn/gcc/gcc/lto/lto.c 2013-06-22 08:40:34.458244488 +0200
+++ /home/eric/svn/sso/gcc/lto/lto.c 2013-06-22 20:36:48.312324302 +0200
@@ -1799,7 +1799,10 @@ compare_tree_sccs_1 (tree t1, tree t2, t
compare_values (TREE_DEPRECATED);
if (TYPE_P (t1))
{
- compare_values (TYPE_SATURATING);
+ if (AGGREGATE_TYPE_P (t1))
+ compare_values (TYPE_REVERSE_STORAGE_ORDER);
+ else
+ compare_values (TYPE_SATURATING);
compare_values (TYPE_ADDR_SPACE);
}
else if (code == SSA_NAME)
[v3] libstdc++/57674
Hi,
tested x86_64-linux, committed mainline and 4_8-branch.
Thanks,
Paolo.
///
2013-06-22 Paolo Carlini paolo.carl...@oracle.com
PR libstdc++/57674
* include/bits/random.h (binomial_distribution::_M_waiting):
Add double parameter.
* include/bits/random.tcc (binomial_distribution::operator()
(_UniformRandomNumberGenerator, const param_type)): Pass
__param._M_q to _M_waiting.
(_M_waiting): Adjust.
* testsuite/26_numerics/random/binomial_distribution/
operators/values.cc: Add tests.
Index: include/bits/random.h
===
--- include/bits/random.h (revision 200317)
+++ include/bits/random.h (working copy)
@@ -3978,7 +3978,8 @@
templatetypename _UniformRandomNumberGenerator
result_type
- _M_waiting(_UniformRandomNumberGenerator __urng, _IntType __t);
+ _M_waiting(_UniformRandomNumberGenerator __urng,
+ _IntType __t, double __q);
param_type _M_param;
Index: include/bits/random.tcc
===
--- include/bits/random.tcc (revision 200317)
+++ include/bits/random.tcc (working copy)
@@ -1648,7 +1648,8 @@
templatetypename _UniformRandomNumberGenerator
typename binomial_distribution_IntType::result_type
binomial_distribution_IntType::
- _M_waiting(_UniformRandomNumberGenerator __urng, _IntType __t)
+ _M_waiting(_UniformRandomNumberGenerator __urng,
+_IntType __t, double __q)
{
_IntType __x = 0;
double __sum = 0.0;
@@ -1663,7 +1664,7 @@
__sum += __e / (__t - __x);
__x += 1;
}
- while (__sum = _M_param._M_q);
+ while (__sum = __q);
return __x - 1;
}
@@ -1784,12 +1785,13 @@
__x += __np + __naf;
- const _IntType __z = _M_waiting(__urng, __t - _IntType(__x));
+ const _IntType __z = _M_waiting(__urng, __t - _IntType(__x),
+ __param._M_q);
__ret = _IntType(__x) + __z;
}
else
#endif
- __ret = _M_waiting(__urng, __t);
+ __ret = _M_waiting(__urng, __t, __param._M_q);
if (__p12 != __p)
__ret = __t - __ret;
Index: testsuite/26_numerics/random/binomial_distribution/operators/values.cc
===
--- testsuite/26_numerics/random/binomial_distribution/operators/values.cc
(revision 200317)
+++ testsuite/26_numerics/random/binomial_distribution/operators/values.cc
(working copy)
@@ -43,6 +43,17 @@
std::binomial_distribution bd3(10, 0.75);
auto bbd3 = std::bind(bd3, eng);
testDiscreteDist(bbd3, [](int n) { return binomial_pdf(n, 10, 0.75); } );
+
+ // libstdc++/57674
+ std::binomial_distribution bd4(1, 0.8);
+ const std::binomial_distribution::param_type pm4(1, 0.3);
+ auto bbd4 = std::bind(bd4, eng, pm4);
+ testDiscreteDist(bbd4, [](int n) { return binomial_pdf(n, 1, 0.3); } );
+
+ std::binomial_distribution bd5(100, 0.3);
+ const std::binomial_distribution::param_type pm5(100, 0.8);
+ auto bbd5 = std::bind(bd5, eng, pm5);
+ testDiscreteDist(bbd5, [](int n) { return binomial_pdf(n, 100, 0.8); } );
}
int main()
Re: [c++-concepts]: constraint association
* We have to avoid increasing memory consumption for regular C++ codes that do not use concepts lite. This is an important criteria. We have only one front-end that is invoked in C++03, C++11, C++14, and C++17 modes. Almost all existing codes are C++03, C++11, and even C++14 only and don't use concepts lite. | | Agreed. But without some source-level annotations in the tree, I don't | | think I can generate the diagnostics that programmer's might otherwise | | expect. I'd have to emit the internal representation. | | Do you have examples where we don't do or we can't do the obvious thing | in terms of diagnostics? | | I think we'll have this problem anywhere we want to pretty-print a | template parameter that's declared using the concept shorthand. I'll | have a better feeling for the issue once I start working the shorthand | in. Maybe it will help if we have concrete situations to work from. | | If those constraints are cached, I don't see any other place to put | | them except in the template info. | | Exactly. | | Previous discussion seemed to indicate that saving constraints with | template decls was preferable. Yes; exactly. | | On the other hand, it seems like the only place we actually need to | | worry about is with non-template member functions. | | Member function of templates are temploids, so no worry there either. | (Internally, they act and are represented like templates.) | | There's a difference between when those declarations are instantiated | and when their constraints really need to be evaluated. Because | temploids are instantiated with a class definition (prior to use), we | (may) need to carry some information with those instances. Yes, member *declarations* are almost always instantiated as part of the class instantiation. | The committed version in the branch carries those constraints in | template_info for the temploid. Yes; I think that is good. | The submitted patch carries the | instantiated constraints with the member declaration. The most recent | version on my work computer doesn't carry any constraints with | temploids -- it instantiates the requirements directly from the | template/args in the declarations' template_info. | | | I think I can just grab the requirements and arguments and check them | | without caching them in the template_info. | | I think we need to remember them for duplicate_decls or other routines | that either check or use ODR-derived properties. | | This doesn't seem to be a problem. IIRC, the instantiated declarations | are differentiated by their template constraints, not their | instantiated constraints. | | Differentiating by instantiated constraints may not be viable, | anyways. Especially, if the instantiation folds them to only true or | false. Hmm, I am lost here. Could you clarify with examples? | | We still don't have nodes specific to TEMPLTAE_DECL or | | TEMPLATE_PARM_DECL though. | | A tree with TREE_CODE equal to TEMPLATE_DECL or TEMPLATE_PARM_DECL is | just that. What we do is to use all unused- tree slots. Or are you | suggesting we have exhausted all available pre-defined slots on such nodes? | | Unknown. I'll have to look. | | But, I don't think we have a single TEMPLATE_PARM_DECL node. | Template parameters are either TYPE_DECLs or PARM_DECLs. I think auto | declarations, get VAR_DECLs, but I haven't looked closely at that | design. I'd have to look to see if there are any free tree slots all | of those decl nodes to minimize. the type specifier 'auto' is represented by a fresh TEMPLATE_TYPE_PARM, therefore has a TEMPLATE_TYPE_DECL. -- Gaby
[c++-concepts] Merge from trunk
Andrew -- At revision 200343. With the merge of Cilk changes to trunk, it was necessary to synchronize so that c++-concepts branch doesn't get too out of sync. There were a few conflicts in cp/Make-lang.in and cp/cp-tree.h that I think I resolved properly. Let me know if anything else was lost (I think not.) -- Gaby
Re: [Patch, Fortran] Print floating-point exception status after STOP/ERROR STOP
Eric Botcazou wrote: My autoconf foo does not seem to be strong enough for libgfortran, but I assume checking for both types and then using #ifdef HAVE_FP_EXCEPT_T ...#elif HAVE_FP_EXCEPT...#endif ought to work? Yes, I think that we just need to patch the LIBGFOR_CHECK_FPSETMASK check in acinclude.m4 so as to also test the return type of the function. Eric: I have a Solaris question. In acinclude.m4, one has: #if HAVE_FLOATINGPOINT_H # include floatingpoint.h #endif /* HAVE_FLOATINGPOINT_H */ Should one also include that file? Currently, only ieeefp.h is included via libgfortran.h. Gerald and Eric: Would the following work for you? (Sorry, no config.h.in/configure patch; I haven't build in maintainer's mode, yet.) --- Cut -- diff --git a/libgfortran/config/fpu-sysv.h b/libgfortran/config/fpu-sysv.h index 1502b37..db95e9d 100644 --- a/libgfortran/config/fpu-sysv.h +++ b/libgfortran/config/fpu-sysv.h @@ -87,3 +87,9 @@ get_fpu_except_flags (void) int result; +#if HAVE_FP_EXCEPT fp_except set_excepts; +#elif HAVE_FP_EXCEPT_T + fp_except_t set_excepts; +#else + choke me +#endif diff --git a/libgfortran/configure.ac b/libgfortran/configure.ac index ba14f1f..a2add6d 100644 --- a/libgfortran/configure.ac +++ b/libgfortran/configure.ac @@ -500,2 +500,3 @@ fi LIBGFOR_CHECK_FPSETMASK +AC_CHECK_TYPES([fp_except fp_except_t], [], [], [[#include ieeefp.h]]) --- Cut -- Tobias
Re: [c++-concepts]
On Mon, Jun 3, 2013 at 6:15 PM, Jason Merrill ja...@redhat.com wrote: On 06/01/2013 10:57 AM, Gabriel Dos Reis wrote: Well, we don't want to check cxx0x one place and cxx11 others. But we still do. Testing a patch. -- Gaby
Re: C++ PATCH to build a TEMPLATE_DECL for a partial specialization
On Thu, Jun 20, 2013 at 1:41 PM, Jason Merrill ja...@redhat.com wrote: It has always seemed odd that we didn't build a TEMPLATE_DECL for a partial specialization, and with the ongoing concepts work it has become more important to have one so that we can attach any requirements to it. Note that there is still no way to get from the type of a partial specialization to its template other than by way of the primary template's list of partial specializations. The second patch adds some missing _CHECK uses. Tested x86_64-pc-linux-gnu, applying to trunk. Thanks! -- Gaby
Re: [c++-concepts]: constraint association
| Previous discussion seemed to indicate that saving constraints with
| template decls was preferable.
Yes; exactly.
| The committed version in the branch carries those constraints in
| template_info for the temploid.
Yes; I think that is good.
So we should associate constraints with both TEMPLATE_DECLs and TEMPLATE_INFOs?
Storing constraints with TEMPLATE_INFO could require more memory since
each instantiation generates a new one. It doesn't look like that
structure has any free trees anyways, so we'd have to add a field
(which is what we've done now).
Concepts lite shouldn't need to track instantiated constraints,
anyway. Constraints are either satisfied or they aren't.
| I think we need to remember them for duplicate_decls or other routines
| that either check or use ODR-derived properties.
|
| This doesn't seem to be a problem. IIRC, the instantiated declarations
| are differentiated by their template constraints, not their
| instantiated constraints.
|
| Differentiating by instantiated constraints may not be viable,
| anyways. Especially, if the instantiation folds them to only true or
| false.
Hmm, I am lost here. Could you clarify with examples?
templatetypename T
struct S {
void f() requires Input_iteratorT { }
void f() requires Bidirectional_iteratorT { }
};
Probably an unlikely example, but anyways...
The class ST has two declarations of f, ST::f() requires
Input_iteratorT and ST::f() requires Bidirectional_iteratorT.
When you instantiate S, say Sint*, we instantiate the nested
declarations. They are made distinct on the basis of the dependent
constrains. If you try to distinguish them on the basis of their
instantiated constraints you could have:
template
struct Sint* {
void f() requires true;
void f() requires true; // Oops. Not desirable.
};
Andrew
Re: [c++-concepts]: constraint association
| But, I don't think we have a single TEMPLATE_PARM_DECL node. Template | parameters are either TYPE_DECLs or PARM_DECLs. I think auto | declarations, get VAR_DECLs, but I haven't looked closely at that | design. I'd have to look to see if there are any free tree slots all | of those decl nodes to minimize. The individual constraint for a template parameter should probably go with the TEMPLATE_PARM_INDEX which is the uniform representation of template parameters. But, the real cumulative constraints go with the TEMPLATE_DECLs. With Jason's patch that creates TEMPLATE_DECLs for partial instantiations, I believe we have all the bases covered. -- Gaby
Re: [c++-concepts]: constraint association
| But, I don't think we have a single TEMPLATE_PARM_DECL node. Template | parameters are either TYPE_DECLs or PARM_DECLs. I think auto | declarations, get VAR_DECLs, but I haven't looked closely at that | design. I'd have to look to see if there are any free tree slots all | of those decl nodes to minimize. The individual constraint for a template parameter should probably go with the TEMPLATE_PARM_INDEX which is the uniform representation of template parameters. But, the real cumulative constraints go with the TEMPLATE_DECLs. With Jason's patch that creates TEMPLATE_DECLs for partial instantiations, I believe we have all the bases covered. I have to look through the template parameter creation code, but that sounds about right. Andrew
Re: [c++-concepts]: constraint association
Andrew Sutton andrew.n.sut...@gmail.com writes:
| | Previous discussion seemed to indicate that saving constraints with
| | template decls was preferable.
|
| Yes; exactly.
|
| | The committed version in the branch carries those constraints in
| | template_info for the temploid.
|
| Yes; I think that is good.
|
| So we should associate constraints with both TEMPLATE_DECLs and
TEMPLATE_INFOs?
|
| Storing constraints with TEMPLATE_INFO could require more memory since
| each instantiation generates a new one. It doesn't look like that
| structure has any free trees anyways, so we'd have to add a field
| (which is what we've done now).
We don't want to unnecessarily duplicate the information...
The constraints have to go with TEMPLATE_DECLs directly or in the
TEMPLATE_INFO. But, we don't want a distributed fat.
| Concepts lite shouldn't need to track instantiated constraints,
| anyway. Constraints are either satisfied or they aren't.
Exactly right. For partial ordering, we use the original form to decide
most specialized -- mirroring what we do for non-constrained templates.
And when we do that we use the constraints from the source-level decls.
| | I think we need to remember them for duplicate_decls or other routines
| | that either check or use ODR-derived properties.
| |
| | This doesn't seem to be a problem. IIRC, the instantiated declarations
| | are differentiated by their template constraints, not their
| | instantiated constraints.
| |
| | Differentiating by instantiated constraints may not be viable,
| | anyways. Especially, if the instantiation folds them to only true or
| | false.
|
| Hmm, I am lost here. Could you clarify with examples?
|
| templatetypename T
| struct S {
| void f() requires Input_iteratorT { }
| void f() requires Bidirectional_iteratorT { }
| };
|
| Probably an unlikely example, but anyways...
Ah, I think last time we discussed this, it was something like
templatetypename T
struct vector {
void push_back(T) requires MovableOnlyT;
void push_back(const T) requires CopyConstructibleT;
};
but they are already distinguished by the parameter lists so that is not
an issue.
The cases were you can't distinguish the instantiated decls based on their
types correspond to perfect (partial) specializations; we should use the
existing model for those in this specific case. That means going back
to the abstract form (the associated temploids) and
| The class ST has two declarations of f, ST::f() requires
| Input_iteratorT and ST::f() requires Bidirectional_iteratorT.
| When you instantiate S, say Sint*, we instantiate the nested
| declarations. They are made distinct on the basis of the dependent
| constrains. If you try to distinguish them on the basis of their
| instantiated constraints you could have:
|
| template
| struct Sint* {
| void f() requires true;
| void f() requires true; // Oops. Not desirable.
| };
They look like partial specializations of member templates
(which they morally are); we should treat them as such. You have
similar situation if you put them at non-class scope.
-- Gaby
Re: [c++-concepts]: constraint association
Andrew Sutton andrew.n.sut...@gmail.com writes: | | But, I don't think we have a single TEMPLATE_PARM_DECL node. Template | | parameters are either TYPE_DECLs or PARM_DECLs. I think auto | | declarations, get VAR_DECLs, but I haven't looked closely at that | | design. I'd have to look to see if there are any free tree slots all | | of those decl nodes to minimize. | | The individual constraint for a template parameter should probably go | with the TEMPLATE_PARM_INDEX which is the uniform representation of | template parameters. But, the real cumulative constraints go with the | TEMPLATE_DECLs. With Jason's patch that creates TEMPLATE_DECLs for | partial instantiations, I believe we have all the bases covered. | | I have to look through the template parameter creation code, but that | sounds about right. build_template_parm-- the real (low-level) constructor process_template_parm -- higher-level interface to the parsing make_auto_1 -- for type of variables declared with 'auto'. -- Gaby
Re: [SH] PR 52483 - Fix volatile mem loads
Oleg Endo oleg.e...@t-online.de wrote:
the attached patch fixes volatile mem loads on SH so that they won't
result in redundant sign extensions and also utilize the available
addressing modes.
Tested on rev 200116 with
make -k check RUNTESTFLAGS=--target_board=sh-sim
\{-m2/-ml,-m2/-mb,-m2a/-mb,-m4/-ml,-m4/-mb,-m4a/-ml,-m4a/-mb}
and no new failures.
OK?
OK.
Regards,
kaz
C++ PATCH: Change reference to cxx0x to cxx11
Jason Merrill ja...@redhat.com writes:
| On 06/01/2013 10:57 AM, Gabriel Dos Reis wrote:
| Well, we don't want to check cxx0x one place and cxx11 others.
|
| But we still do.
Fixed with this.
-- Gaby
2013-06-22 Gabriel Dos Reis g...@integrable-solutions.net
* c-common.c (c_common_nodes_and_builtins): Use cxx11 in lieu of cxx0x.
* c-cppbuiltin.c (c_cpp_builtins): Likewise.
* c-opts.c (c_common_post_options): Likewise.
cp/
2013-06-22 Gabriel Dos Reis g...@integrable-solutions.net
* call.c (null_ptr_cst_p): Use cxx11 in lieu of cxx0x.
* class.c (add_implicitly_declared_members): Likewise.
(check_field_decl): Likewise.
(finalize_literal_type_property): Likewise.
(check_bases_and_members): Likewise.
* decl.c (poplevel): Likewise.
(case_conversion): Likewise.
(check_initializer): Likewise.
(grokfndecl): Likewise.
(check_static_variable_definition): Likewise.
(compute_array_index_type): Likewise.
(grokdeclarator): Likewise.
(build_enumerator): Likewise.
* friend.c (make_friend_class): Likewise.
* lex.c (init_reswords): Likewise.
* method.c (synthesized_method_walk): Likewise.
(implicitly_declare_fn): Likewise.
* parser.c (cp_parser_diagnose_invalid_type_name): Likewise.
(cp_parser_constant_expression): Likewise.
(cp_parser_for_init_statement): Likewise.
(cp_parser_block_declaration): Likewise.
(cp_parser_type_name): Likewise.
(cp_parser_enum_specifier): Likewise.
(cp_parser_enumerator_list): Likewise.
(cp_parser_member_declaration): Likewise.
(cp_nth_tokens_can_be_std_attribute_p): Likewise.
(cp_parser_template_declaration_after_export): Likewise.
* pt.c (convert_nontype_argument_function): Likewise.
(convert_nontype_argument): Likewise.
(convert_template_argument): Likewise.
(tsubst_copy_and_build): Likewise.
(build_non_dependent_expr): Likewise.
* semantics.c (non_const_var_error): Likewise.
(potential_constant_expression_1): Likewise.
* tree.c (lvalue_kind): Likewise.
(build_vec_init_expr): Likewise.
(cast_valid_in_integral_constant_expression_p): Likewise.
* typeck.c (build_x_conditional_expr): Likewise.
* typeck2.c (check_narrowing): Likewise.
Index: c-family/c-common.c
===
--- c-family/c-common.c (revision 200347)
+++ c-family/c-common.c (working copy)
@@ -5454,7 +5454,7 @@
{
char16_type_node = make_unsigned_type (char16_type_size);
- if (cxx_dialect = cxx0x)
+ if (cxx_dialect = cxx11)
record_builtin_type (RID_CHAR16, char16_t, char16_type_node);
}
@@ -5470,7 +5470,7 @@
{
char32_type_node = make_unsigned_type (char32_type_size);
- if (cxx_dialect = cxx0x)
+ if (cxx_dialect = cxx11)
record_builtin_type (RID_CHAR32, char32_t, char32_type_node);
}
Index: c-family/c-cppbuiltin.c
===
--- c-family/c-cppbuiltin.c (revision 200347)
+++ c-family/c-cppbuiltin.c (working copy)
@@ -713,7 +713,7 @@
cpp_define (pfile, __DEPRECATED);
if (flag_rtti)
cpp_define (pfile, __GXX_RTTI);
- if (cxx_dialect = cxx0x)
+ if (cxx_dialect = cxx11)
cpp_define (pfile, __GXX_EXPERIMENTAL_CXX0X__);
}
/* Note that we define this for C as well, so that we know if
Index: c-family/c-opts.c
===
--- c-family/c-opts.c (revision 200347)
+++ c-family/c-opts.c (working copy)
@@ -889,7 +889,7 @@
if (warn_implicit_function_declaration == -1)
warn_implicit_function_declaration = flag_isoc99;
- if (cxx_dialect = cxx0x)
+ if (cxx_dialect = cxx11)
{
/* If we're allowing C++0x constructs, don't warn about C++98
identifiers which are keywords in C++0x. */
Index: cp/call.c
===
--- cp/call.c (revision 200347)
+++ cp/call.c (working copy)
@@ -554,7 +554,7 @@
if (CP_INTEGRAL_TYPE_P (TREE_TYPE (t)))
{
/* Core issue 903 says only literal 0 is a null pointer constant. */
- if (cxx_dialect cxx0x)
+ if (cxx_dialect cxx11)
t = maybe_constant_value (fold_non_dependent_expr_sfinae (t, tf_none));
STRIP_NOPS (t);
if (integer_zerop (t) !TREE_OVERFLOW (t))
Index: cp/class.c
===
--- cp/class.c (revision 200347)
+++ cp/class.c (working copy)
@@ -2971,7 +2971,7 @@
{
bool move_ok = false;
- if (cxx_dialect = cxx0x !CLASSTYPE_DESTRUCTORS (t)
+ if (cxx_dialect = cxx11 !CLASSTYPE_DESTRUCTORS (t)
!TYPE_HAS_COPY_CTOR (t) !TYPE_HAS_COPY_ASSIGN (t)
