Re: [PATCH] [PR c++/84943] allow folding of array indexing indirect_ref

[Jason Merrill]

On Sat, Mar 31, 2018 at 2:24 AM, Alexandre Oliva  wrote:
> On Mar 30, 2018, Jason Merrill  wrote:
>
>> I don't think we need this; if arg is overloaded, we take the
>> type_unknown_p early exit, so the code lower down is always dealing
>> with a single function.
>
> Aah, that's why it seemed to me that we had already resolved overloads
> when we got there.
>
> As a bonus, I added the tf_conv test before another mark_used call I'd
> missed in the previous patch.

What if we check tf_conv in mark_used itself rather than at all the call sites?

Jason

Re: [PATCH] [PR c++/84979] improve auto handling in explicit tmpl args for concepts

[Jason Merrill]

On Sat, Mar 31, 2018 at 4:23 AM, Alexandre Oliva  wrote:
> On Mar 30, 2018, Jason Merrill  wrote:
>
>> True, it looks like sometimes we build a TEMPLATE_ID_EXPR with an
>> IDENTIFIER_NODE.  Looking at tsubst_copy_and_build, I see that we
>> don't call finish_id_expression when substituting such a
>> TEMPLATE_ID_EXPR.  So maybe lookup_template_function and
>> lookup_template_variable are the right places for this test.
>
> Nevermind the earlier email about multiple errors.  I realized that we
> save the preparsed template_id right after the tests in
> cp_parser_template_id, and if only I don't stop the rejected template
> from being saved, we avoid the duplicate errors, as in the patch below.
>
> A slight variant of this passed regstrap on i686- and x86_64-linux-gnu.
> Ok to install, though it does not catch such cases as:
>
> template 
> void foo(T t) {
>   typename T::template C u = t;
>   T::template C (t);
>   T::template C::f (t, u);
> }
>
> ?

We should be able to distinguish those cases based on tag_type.

Jason

Re: [PATCH, rs6000] Fix PR80546: FAIL: gcc.target/powerpc/bool3-p[78].c scan-assembler-not

[Peter Bergner]

On 3/30/18 6:15 PM, Segher Boessenkool wrote:
> But okay (with the fixes), and okay for 7.  Thanks!

Ok, committed now to trunk and GCC 7 with your suggestions.  Thanks!

Peter

Re: [PATCH. rs6000] Fix PR84912: ICE using -m32 on __builtin_divde*, patch #2

[Peter Bergner]

On 3/28/18 7:21 PM, Segher Boessenkool wrote:
> On Wed, Mar 28, 2018 at 07:13:36PM -0500, Peter Bergner wrote:
>> Do we care enough to fix these on the release branches?  If so, I
>> can backport them easily, since they're not that involved.
>> I'll leave it up to you to decide.
> 
> If it's easy, yes please.  After the usual wait.

Yes it was easy.  Committed now to GCC 7 and GCC 6.  Thanks.

Peter

[committed] fix a couple of typos in manual

[Martin Sebor]

I committed r259020 to fix a couple of typos in the documentation
of the -Wrestrict option.  The diff is below for reference.

Martin

Index: gcc/doc/invoke.texi
===
--- gcc/doc/invoke.texi (revision 259019)
+++ gcc/doc/invoke.texi (working copy)
@@ -6825,13 +6825,16 @@ the call writes the terminating NUL into @code{a[4
 the call is diagnosed.

 @smallexample
-struct foo
+void foo (void)
 @{
   char a[] = "abcd1234";
   strcpy (a, a + 4);
-@};
+  
+@}
 @end smallexample
-The @option{-Wrestrict} is included in @option{-Wall}.
+The @option{-Wrestrict} option detects some instances of simple overlap
+even without optimization but works best at @option{-O2}.  It is included
+in @option{-Wall}.

 @item -Wnested-externs @r{(C and Objective-C only)}
 @opindex Wnested-externs
Index: gcc/ChangeLog
===
--- gcc/ChangeLog   (revision 259019)
+++ gcc/ChangeLog   (working copy)
@@ -1,3 +1,7 @@
+2018-04-02  Martin Sebor  
+
+   * doc/invoke.texi (-Wrestrict): Fix typos.
+
 2018-04-02  Jim Wilson  

* config/riscv/riscv.h (SHIFT_COUNT_TRUNCATED): Set to zero.

Re: [PATCH, PR84660] Fix combine bug with SHIFT_COUNT_TRUNCATED.

[Jim Wilson]

On Fri, Mar 23, 2018 at 5:33 AM, Richard Biener
 wrote:
> I'm leaving the "simple" combiner patch to review by others
> but for RISC-V you could simply #define SHIFT_COUNT_TRUNCATED to zero
> to fix the issue.  Then add patterns if it turns out to be required
> to avoid regressions.  For example x86 has

I checked in a patch to do this.  It took me quite a few iterations to
work out how to do it without regressions, but it looks OK in the end.
6 additional patterns and changing the shift count mode to QImode in
all existing shift patterns and I get effectively the same code as
before with SHIFT_COUNT_TRUNCATED turned off.  With DImode shift
counts, I ran into problems with unnecessary sign/zero extensions from
SImode for shift counts.  With SImode shift counts, I ran into
problems with unnecessary truncations from DImode.  Using QImode shift
counts avoided both of those problems.

That leaves the other targets still using SHIFT_COUNT_TRUNCATED as
potentially broken.  I count 16 of them.  Though this particular
testcase might not be triggerable on most of them, since it requires
shift patterns for two different modes, and most 32-bit targets
probably only have one mode that shift is supported for.

Jim

[PATCH] RISC-V: Fix for combine bug with shift and AND operations.

[Jim Wilson]

This is a fix for PR 84660 which is a combine bug with SHIFT_COUNT_TRUNCATED.
It seems that use of SHIFT_COUNT_TRUNCATED is discouraged now, so rather than
fix combine this fixes the RISC-V backend to stop using SHIFT_COUNT_TRUNCATED.
This required adding 6 new patterns, and changing the existing patterns to use
QImode shift counts instead of SImode/SImode shift counts.  This also adds
the original testcase, and 6 minimal testcases which each test one of the new
patterns.

This was tested with riscv{32,64}-{linux,elf} builds and make checks.  There
are no regressions.  It was tested with a linux kernel and buildroot build and
boot on qemu.  It was tested by looking at libstdc++ code with and without the
patch, and trying to get the exact same code, though in the end I had to settle
for the same instructions with slightly different register allocation and
slightly different order in a few cases.

Committed.

Jim

PR rtl-optimization/84660
gcc/
* config/riscv/riscv.h (SHIFT_COUNT_TRUNCATED): Set to zero.
* config/riscv/riscv.md (si3): Use QImode shift count.
(di3, si3_extend): Likewise.
(si3_mask, si3_mask_1): New.
(di3_mask, di3_mask_1): New.
(si3_extend_mask, si3_extend_mask_1): New.
(lshrsi3_zero_extend_1): Use VOIDmode shift count.
* config/riscv/sync.md (atomic_test_and_set): Emit QImode shift count.
gcc/testsuite/
* gcc.target/riscv/pr84660.c: New.
* gcc.target/riscv/shift-and-1.c: New.
* gcc.target/riscv/shift-and-2.c: New.
---
 gcc/config/riscv/riscv.h |   4 +-
 gcc/config/riscv/riscv.md| 136 ++-
 gcc/config/riscv/sync.md |   5 +-
 gcc/testsuite/gcc.target/riscv/pr84660.c |  17 
 gcc/testsuite/gcc.target/riscv/shift-and-1.c |  10 ++
 gcc/testsuite/gcc.target/riscv/shift-and-2.c |  41 
 6 files changed, 206 insertions(+), 7 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/riscv/pr84660.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/shift-and-1.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/shift-and-2.c

diff --git a/gcc/config/riscv/riscv.h b/gcc/config/riscv/riscv.h
index ebd80c0a5f2..62279ff2cde 100644
--- a/gcc/config/riscv/riscv.h
+++ b/gcc/config/riscv/riscv.h
@@ -636,7 +636,9 @@ typedef struct {
and maybe make use of that.  */
 #define SLOW_BYTE_ACCESS 1
 
-#define SHIFT_COUNT_TRUNCATED 1
+/* Using SHIFT_COUNT_TRUNCATED is discouraged, so we handle this with patterns
+   in the md file instead.  */
+#define SHIFT_COUNT_TRUNCATED 0
 
 /* Specify the machine mode that pointers have.
After generation of rtl, the compiler makes no further distinction
diff --git a/gcc/config/riscv/riscv.md b/gcc/config/riscv/riscv.md
index bffe78dd837..9d222731a06 100644
--- a/gcc/config/riscv/riscv.md
+++ b/gcc/config/riscv/riscv.md
@@ -1483,11 +1483,16 @@
 ;;
 ;;  
 
+;; Use a QImode shift count, to avoid generating sign or zero extend
+;; instructions for shift counts, and to avoid dropping subregs.
+;; expand_shift_1 can do this automatically when SHIFT_COUNT_TRUNCATED is
+;; defined, but use of that is discouraged.
+
 (define_insn "si3"
   [(set (match_operand:SI 0 "register_operand" "= r")
(any_shift:SI
(match_operand:SI 1 "register_operand" "  r")
-   (match_operand:SI 2 "arith_operand"" rI")))]
+   (match_operand:QI 2 "arith_operand"" rI")))]
   ""
 {
   if (GET_CODE (operands[2]) == CONST_INT)
@@ -1499,11 +1504,50 @@
   [(set_attr "type" "shift")
(set_attr "mode" "SI")])
 
+(define_insn_and_split "si3_mask"
+  [(set (match_operand:SI 0 "register_operand" "= r")
+   (any_shift:SI
+   (match_operand:SI 1 "register_operand" "  r")
+   (subreg:QI
+(and:SI
+ (match_operand:SI 2 "register_operand"  "r")
+ (match_operand 3 "const_int_operand")) 0)))]
+  "(INTVAL (operands[3]) & (GET_MODE_BITSIZE (SImode)-1))
+   == GET_MODE_BITSIZE (SImode)-1"
+  "#"
+  "&& 1"
+  [(set (match_dup 0)
+   (any_shift:SI (match_dup 1)
+ (match_dup 2)))]
+  "operands[2] = gen_lowpart (QImode, operands[2]);"
+  [(set_attr "type" "shift")
+   (set_attr "mode" "SI")])
+
+(define_insn_and_split "si3_mask_1"
+  [(set (match_operand:SI 0 "register_operand" "= r")
+   (any_shift:SI
+   (match_operand:SI 1 "register_operand" "  r")
+   (subreg:QI
+(and:DI
+ (match_operand:DI 2 "register_operand"  "r")
+ (match_operand 3 "const_int_operand")) 0)))]
+  "TARGET_64BIT
+   && (INTVAL (operands[3]) & (GET_MODE_BITSIZE (SImode)-1))
+   == GET_MODE_BITSIZE (SImode)-1"
+  "#"
+  "&& 1"
+  [(set (match_dup 0)
+   (any_shift:SI (match_dup 1)
+ (match_dup 2)))]
+  "operands[2] = gen_lowpart (QImode, operands[2]);"
+  [(set_attr "type" "shift")
+   (set_attr "mode" "SI")])
+
 

Re: [documentation patch] add detail to const and pure attributes

[Martin Sebor]

On 04/02/2018 12:09 AM, Sandra Loosemore wrote:

On 03/27/2018 03:21 PM, Pedro Alves wrote:

On 03/27/2018 09:19 PM, Martin Sebor wrote:

On 03/27/2018 01:38 PM, Pedro Alves wrote:

On 03/27/2018 07:18 PM, Martin Sebor wrote:

+Because a @code{pure} function can have no side-effects it does not


FWIW, I'd suggest rephrasing as:

  Because a @code{pure} function cannot have side effects

because "can have no side-effects" can be read as
"is allowed to have no side effects", which gave me pause
when I read it the first time, and is the opposite of
what you mean.


That is what I meant: that const and pure functions are not allowed
to have any side-effects.  If they did, they could be unexpectedly
eliminated (i.e., the behavior is undefined when such a function
does have a side-effect).


I know, but that's not what I read the first time (and found it
odd so I had to re-read).  You can either assume that I'm the
only one that will misunderstand it on first read, or you can
swap a couple words and be sure no one will misunderstand it.

Up to you.


I'm chiming in a little late here, but I agree with Pedro that "can have
no side-effects" is confusing.  I'd say "cannot have side effects" or
"must have no side effects" instead.


There's nothing confusing about it.  It's an established phrase
with millions of uses and only one meaning.  According to Google
Books Ngram Viewer it's also more pervasive than either of
the two suggested alternatives:

  http://goo.gl/FgXgwi


Also note that non-hyphenated "side effects" seems to be preferred usage
as a noun phrase (at least it's the only form listed by m-w.com).


I'm all for using the preferred form.  I've made the change here
and submitted a separate patch to remove the hyphen from the rest
of the occurrences.

Attached is a changed patch that uses "cannot have side effects"
instead of "can have no side effects."

Martin
gcc/ChangeLog:

	* doc/extend.texi (Common Function Attributes): Clarify.
	(const attribute): Likewise.
	(pure attribute): Likewise.

Index: gcc/doc/extend.texi
===
--- gcc/doc/extend.texi	(revision 259017)
+++ gcc/doc/extend.texi	(working copy)
@@ -2275,8 +2275,11 @@ on a declaration, followed by an attribute specifi
 parentheses.  You can specify multiple attributes in a declaration by
 separating them by commas within the double parentheses or by
 immediately following an attribute declaration with another attribute
-declaration.  @xref{Attribute Syntax}, for the exact rules on
-attribute syntax and placement.
+declaration.  @xref{Attribute Syntax}, for the exact rules on attribute
+syntax and placement.  Compatible attribute specifications on distinct
+declarations of the same function are merged.  An attribute specification
+that is not compatible with attributes already applied to a declaration
+of the same function is ignored with a warning.
 
 GCC also supports attributes on
 variable declarations (@pxref{Variable Attributes}),
@@ -2499,7 +2502,7 @@ themselves to optimization such as common subexpre
 The @code{const} attribute imposes greater restrictions on a function's
 definition than the similar @code{pure} attribute below because it prohibits
 the function from reading global variables.  Consequently, the presence of
-the attribute on a function declarations allows GCC to emit more efficient
+the attribute on a function declaration allows GCC to emit more efficient
 code for some calls to the function.  Decorating the same function with
 both the @code{const} and the @code{pure} attribute is diagnosed.
 
@@ -2507,8 +2510,9 @@ both the @code{const} and the @code{pure} attribut
 Note that a function that has pointer arguments and examines the data
 pointed to must @emph{not} be declared @code{const}.  Likewise, a
 function that calls a non-@code{const} function usually must not be
-@code{const}.  It does not make sense for a @code{const} function to
-return @code{void}.
+@code{const}.  Because a @code{const} function cannot have any side
+effects it does not make sense for such a function to return @code{void}.
+Declaring such functions is diagnosed.
 
 @item constructor
 @itemx destructor
@@ -3218,6 +3222,9 @@ The @code{pure} attribute imposes similar but loos
 a function's defintion than the @code{const} attribute: it allows the
 function to read global variables.  Decorating the same function with
 both the @code{pure} and the @code{const} attribute is diagnosed.
+Because a @code{pure} function cannot have any side effects it does not
+make sense for such a function to return @code{void}.  Declaring such
+functions is diagnosed.
 
 @item returns_nonnull
 @cindex @code{returns_nonnull} function attribute

Re: [PATCH] [PR c++/85039] no type definitions in builtin offsetof

[Jason Merrill]

On Sat, Mar 31, 2018 at 7:12 AM, Alexandre Oliva  wrote:
> On Mar 30, 2018, Jason Merrill  wrote:
>
>> On Fri, Mar 30, 2018 at 3:55 AM, Alexandre Oliva  wrote:
>>> Types defined within a __builtin_offsetof argument don't always get
>>> properly recorded as members of their context types
>
>>> I suppose this means I should look for another solution that doesn't
>>> involve rejecting these definitions, eh?
>
>> Hmm, I'm afraid so
>
> Ok, but...  tricky...
>
> If I were to make the anonymous types members of the enclosing class,
> their members would be promoted to members of the enclosing class, which
> doesn't sound like the right thing to do.

Agreed.  The C definition talks in terms of a variable declaration

static  t;

so treating the type as an anonymous aggregate member of the class
would be wrong; it can be a type member, but not an anonymous
aggregate.

> But I wonder, should they even be regarded as members of the enclosing
> class, when they do not appear inside the body of the class.  Perhaps
> their context should be something else, say the innermost enclosing
> namespace, the global namespace, some anonymous namespace introduced for
> the offsetof...

> One thing that's not clear to me is whether types defined in offsetof
> can be referenced outside their own definition.  In C, that would be
> natural, since the struct namespace is flat, but in C++, structs belong
> to a context, and it's not obvious to me that offsetof should inject
> names in an enclosing context, or in a separate invisible namespace.  I
> lean towards the latter, but then I tried:
>
> template  class foo { };
> int j = __builtin_offsetof(struct a { int i; static foo x = foo(); }, 
> i);
>
> and found (through debug info) that foo is mangled as if struct a was
> defined in the global namespace.  And, indeed, a is recorded in the
> global namespace:
>
> a b;
>
> which was slightly surprising to me.
>
> But it seems to be consistent: when the offsetof expression is within a
> function, the type will be defined within the function; when it is used
> in the initializer of a data member, the context is the class containing
> the data member, even if the initializer is outside the class body, but
> the type is defined in the global namespace:
>
> struct a {
>   static int const z, i = __builtin_offsetof(struct b { int j; }, j);
>   b c;
> };
> int const a::z = __builtin_offsetof(struct d { int k; }, k);
> d e;
> b f; // b is not defined
> a::b g; // ok
>
> So, the problem with anon types defined in offsetof appears to be the
> inconsistency between the scope in which d is introduced, namely the
> global namespace because that's the current scope, and the DECL_CONTEXT,
> copied to TYPE_CONTEXT, that is taken as class a because we're parsing
> the initializer for a::z.  Since they disagree, we don't find the type
> defined in the context named as enclosing it.
>
> Since d is visible, I suppose the most conservative solution would be to
> name the global namespace as the context for type d, rather than
> defining it as a member of a.  Right?

The global namespace would be a rather arbitrary choice; it seems to
me that using the current scope is a natural interpretation.

About d in the example, I'm not sure how you mean the global namespace
is the current scope; we should be pushed into a when parsing the
initializer for a::z.

But I would think we should reject the definition of d because a is
already complete, so it's too late to add members to it.

> Now, I really don't want to think of offsetof appearing in default
> arguments or array lengths in function prototypes or even in template
> parameters.  Types are not supposed to be defined in such contexts,
> but...  should offsetof make an exception?  Currently, we reject them,
> which is quite a relief, because otherwise it might appear in
> expressions in templates and that would be really really hairy ;-)

No, offsetof should not make an exception.

>> Incidentally, it would be nice to replace all the
>> type_definition_forbidden stuff with defining-type-specifier as per DR
>> 2141... (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50169)
>
> *nod*
>
> Is this in scope for GCC 8?  It's not marked as a regression, but I
> guess I could try and tackle it if it's intended to make it anyway,
> given that I've got some context on this issue.  LMK about the plans,
> and whether you envision any pitfalls.

No, sorry, that's a relatively low priority cleanup.

Jason

[doc patch] remove hyphen from side-effect

[Martin Sebor]

Attached is a patch to remove the hyphen from uses of side-effect
in the manual as per the comment in:

  https://gcc.gnu.org/ml/gcc-patches/2018-04/msg00021.html

Although both forms are common, "side effect" (without the hyphen)
is more prevalent in current English and I think it's better to be
consistent than to have to rehash this question each time someone
happens to copy the less common form from existing text.

https://english.stackexchange.com/questions/889/when-should-compound-words-be-written-as-one-word-with-hyphens-or-with-spaces

Martin
gcc/ChangeLog:

	* doc/cppopts.texi: Use "side effect" instead of side-effect.
	* doc/extend.texi: Same.
	* doc/generic.texi: Same.
	* doc/implement-c.texi: Same.
	* doc/invoke.texi: Same.
	* doc/md.texi: Same.
	* doc/rtl.texi: Same.
	* doc/tm.texi: Same.
	* doc/tm.texi.in: Same.
	* doc/tree-ssa.texi: Same.

Index: gcc/doc/cppopts.texi
===
--- gcc/doc/cppopts.texi	(revision 259017)
+++ gcc/doc/cppopts.texi	(working copy)
@@ -200,7 +200,7 @@ If @option{-MD} is used in conjunction with @optio
 is understood to specify a target object file.
 
 Since @option{-E} is not implied, @option{-MD} can be used to generate
-a dependency output file as a side-effect of the compilation process.
+a dependency output file as a side effect of the compilation process.
 
 @item -MMD
 @opindex MMD
@@ -403,7 +403,7 @@ Do not discard comments, including during macro ex
 like @option{-C}, except that comments contained within macros are
 also passed through to the output file where the macro is expanded.
 
-In addition to the side-effects of the @option{-C} option, the
+In addition to the side effects of the @option{-C} option, the
 @option{-CC} option causes all C++-style comments inside a macro
 to be converted to C-style comments.  This is to prevent later use
 of that macro from inadvertently commenting out the remainder of
Index: gcc/doc/extend.texi
===
--- gcc/doc/extend.texi	(revision 259017)
+++ gcc/doc/extend.texi	(working copy)
@@ -2050,7 +2050,7 @@ int widths[] = @{ [0 ... 9] = 1, [10 ... 99] = 2,
 @end smallexample
 
 @noindent
-If the value in it has side-effects, the side-effects happen only once,
+If the value in it has side effects, the side effects happen only once,
 not for each initialized field by the range initializer.
 
 @noindent
@@ -2147,7 +2147,7 @@ struct point ptarray[10] = @{ [2].y = yv2, [2].x =
 @noindent
 If the same field is initialized multiple times, it has the value from
 the last initialization.  If any such overridden initialization has
-side-effect, it is unspecified whether the side-effect happens or not.
+side effect, it is unspecified whether the side effect happens or not.
 Currently, GCC discards them and issues a warning.
 
 @node Case Ranges
@@ -3024,7 +3024,7 @@ This function attribute prevents a function from b
 inlining.
 @c Don't enumerate the optimizations by name here; we try to be
 @c future-compatible with this mechanism.
-If the function does not have side-effects, there are optimizations
+If the function does not have side effects, there are optimizations
 other than inlining that cause function calls to be optimized away,
 although the function call is live.  To keep such calls from being
 optimized away, put
@@ -3034,7 +3034,7 @@ asm ("");
 
 @noindent
 (@pxref{Extended Asm}) in the called function, to serve as a special
-side-effect.
+side effect.
 
 @item noipa
 @cindex @code{noipa} function attribute
@@ -10658,7 +10658,7 @@ The built-in functions promote the first two opera
 and perform addition on those promoted operands. The result is then
 cast to the type of the third argument.  If the cast result is equal to the infinite
 precision result, the built-in functions return false, otherwise they return true.
-The value of the third argument is ignored, just the side-effects in the third argument
+The value of the third argument is ignored, just the side effects in the third argument
 are evaluated, and no integral argument promotions are performed on the last argument.
 If the third argument is a bit-field, the type used for the result cast has the
 precision and signedness of the given bit-field, rather than precision and signedness
@@ -10754,7 +10754,7 @@ a limited extent, they can be used without optimiz
 is a built-in construct that returns a constant number of bytes from
 @var{ptr} to the end of the object @var{ptr} pointer points to
 (if known at compile time).  @code{__builtin_object_size} never evaluates
-its arguments for side-effects.  If there are any side-effects in them, it
+its arguments for side effects.  If there are any side effects in them, it
 returns @code{(size_t) -1} for @var{type} 0 or 1 and @code{(size_t) 0}
 for @var{type} 2 or 3.  If there are multiple objects @var{ptr} can
 point to and all of them are known at compile time, the returned number
@@ -11773,7 +11773,7 @@ 

C++ PATCH for c++/64095, unnamed generic lambda parameter pack

[Jason Merrill]

In this testcase, we have (auto...), a function parameter pack without
a declarator.  Because there is no declarator, we were never hitting
the code for turning the auto type into a template parameter pack, so
the ... ended up being parsed as a C-style trailing ellipsis.

Tested x86_64-pc-linux-gnu, applying to trunk.
commit 476a47b844613603961cb1e7aedcbcc8601297b5
Author: Jason Merrill 
Date:   Mon Apr 2 07:45:02 2018 -0400

PR c++/64095 - auto... parameter pack.

* parser.c (cp_parser_parameter_declaration): Handle turning autos
into packs here.
(cp_parser_parameter_declaration_list): Not here.

diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index e946d0b7229..d526a4eb365 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -21320,9 +21320,6 @@ cp_parser_parameter_declaration_list (cp_parser* parser, bool *is_error)
   cp_parameter_declarator *parameter;
   tree decl = error_mark_node;
   bool parenthesized_p = false;
-  int template_parm_idx = (function_being_declared_is_template_p (parser)?
-			   TREE_VEC_LENGTH (INNERMOST_TEMPLATE_PARMS
-		(current_template_parms)) : 0);
 
   /* Parse the parameter.  */
   parameter
@@ -21336,22 +21333,6 @@ cp_parser_parameter_declaration_list (cp_parser* parser, bool *is_error)
 
   if (parameter)
 	{
-	  /* If a function parameter pack was specified and an implicit template
-	 parameter was introduced during cp_parser_parameter_declaration,
-	 change any implicit parameters introduced into packs.  */
-	  if (parser->implicit_template_parms
-	  && parameter->declarator
-	  && parameter->declarator->parameter_pack_p)
-	{
-	  int latest_template_parm_idx = TREE_VEC_LENGTH
-		(INNERMOST_TEMPLATE_PARMS (current_template_parms));
-
-	  if (latest_template_parm_idx != template_parm_idx)
-		parameter->decl_specifiers.type = convert_generic_types_to_packs
-		  (parameter->decl_specifiers.type,
-		   template_parm_idx, latest_template_parm_idx);
-	}
-
 	  decl = grokdeclarator (parameter->declarator,
  >decl_specifiers,
  PARM,
@@ -21511,6 +21492,10 @@ cp_parser_parameter_declaration (cp_parser *parser,
   parser->type_definition_forbidden_message
 = G_("types may not be defined in parameter types");
 
+  int template_parm_idx = (function_being_declared_is_template_p (parser) ?
+			   TREE_VEC_LENGTH (INNERMOST_TEMPLATE_PARMS
+	(current_template_parms)) : 0);
+
   /* Parse the declaration-specifiers.  */
   cp_token *decl_spec_token_start = cp_lexer_peek_token (parser->lexer);
   cp_parser_decl_specifier_seq (parser,
@@ -21600,6 +21585,23 @@ cp_parser_parameter_declaration (cp_parser *parser,
  parameter pack expansion expression. Otherwise, leave the ellipsis
  for a C-style variadic function. */
   token = cp_lexer_peek_token (parser->lexer);
+
+  /* If a function parameter pack was specified and an implicit template
+ parameter was introduced during cp_parser_parameter_declaration,
+ change any implicit parameters introduced into packs.  */
+  if (parser->implicit_template_parms
+  && (token->type == CPP_ELLIPSIS
+	  || (declarator && declarator->parameter_pack_p)))
+{
+  int latest_template_parm_idx = TREE_VEC_LENGTH
+	(INNERMOST_TEMPLATE_PARMS (current_template_parms));
+
+  if (latest_template_parm_idx != template_parm_idx)
+	decl_specifiers.type = convert_generic_types_to_packs
+	  (decl_specifiers.type,
+	   template_parm_idx, latest_template_parm_idx);
+}
+
   if (cp_lexer_next_token_is (parser->lexer, CPP_ELLIPSIS))
 {
   tree type = decl_specifiers.type;
diff --git a/gcc/testsuite/g++.dg/cpp1y/lambda-generic-variadic16.C b/gcc/testsuite/g++.dg/cpp1y/lambda-generic-variadic16.C
new file mode 100644
index 000..a9292253453
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp1y/lambda-generic-variadic16.C
@@ -0,0 +1,8 @@
+// PR c++/64095
+// { dg-do compile { target c++14 } }
+
+void f()
+{
+  [](auto...){}();
+  [](auto&&...){}();
+}
diff --git a/gcc/testsuite/g++.dg/cpp1y/lambda-mangle-1.C b/gcc/testsuite/g++.dg/cpp1y/lambda-mangle-1.C
index ca0910be503..8f135358465 100644
--- a/gcc/testsuite/g++.dg/cpp1y/lambda-mangle-1.C
+++ b/gcc/testsuite/g++.dg/cpp1y/lambda-mangle-1.C
@@ -85,4 +85,4 @@ void Baz ()
 // { dg-final { scan-assembler "_Z3eatIZ3FoovEUlPT_PT0_E4_Z3FoovEUlS1_S3_E5_EvRS0_RS2_:" } }
 // { dg-final { scan-assembler "_Z3eatIPiZ3BarIsEvvEUlPsPfS3_E_EvRT_RT0_:" } }
 // { dg-final { scan-assembler "_Z3eatIPiZ3BarIsEvvEUlPsPT_PT0_E0_EvRS3_RS5_:" } }
-// { dg-final { scan-assembler "_Z3eatIPiZ3BarIsEvvEUlPsPT_zE1_EvRS3_RT0_:" } }
+// { dg-final { scan-assembler "_Z3eatIPiZ3BarIsEvvEUlPsDpPT_E1_EvRT_RT0_:" } }

Re: [patch, fortran] Fix PR 85102, take 2

[Thomas König]

Hi Steve,


   else
 gfc_free_expr (n);

Don't you need the above changes to avoid leaking memory?


Correct.

OK with those changes?

Regards

Thomas

[cpp,doc] PATCH for Re: CPP documentation minor typo

[Gerald Pfeifer]

On Tue, 20 Feb 2018, Bogdan Harjoc wrote:
> __VA_OPT__ was documented after 7.3.0 and the eprintf example for it
> ends with two backslashes instead of one:
> 
> https://gcc.gnu.org/onlinedocs/cpp/Variadic-Macros.html

Thank you for reporting this, Bogdan.

I just fixed this per the patch below.

Gerald

2018-04-02  Gerald Pfeifer  

* doc/cpp.texi (Variadic Macros): Fix line continuation in an
example.

Index: doc/cpp.texi
===
--- doc/cpp.texi(revision 259011)
+++ doc/cpp.texi(working copy)
@@ -1710,7 +1710,7 @@
 not have any tokens, the @code{@w{__VA_OPT__}} expands to nothing:
 
 @smallexample
-#define eprintf(format, @dots{}) \\
+#define eprintf(format, @dots{}) \
   fprintf (stderr, format __VA_OPT__(,) __VA_ARGS__)
 @end smallexample
 

Re: [PATCH, rs6000, committed] Fix PR81143

[Peter Bergner]

On 2/8/18 2:44 PM, Peter Bergner wrote:
> I have committed the following obvious testsuite patch to fix PR81143.
> The "bug" is that __ORDER_LITTLE_ENDIAN__ is always defined for both
> little and big endian compiles.  I checked and this is the only use
> of this in the gcc.target/powerpc/ directory.
> 
> Peter
> 
>   PR target/81143
>   * gcc.target/powerpc/pr79799-2.c: Use __LITTLE_ENDIAN__.
> 
> Index: gcc/testsuite/gcc.target/powerpc/pr79799-2.c
> ===
> --- gcc/testsuite/gcc.target/powerpc/pr79799-2.c  (revision 257503)
> +++ gcc/testsuite/gcc.target/powerpc/pr79799-2.c  (revision 257504)
> @@ -8,7 +8,7 @@
>  /* Optimize x = vec_insert (vec_extract (v2, N), v1, M) for SFmode if N is 
> the default
> scalar position.  */
> 
> -#if __ORDER_LITTLE_ENDIAN__
> +#if __LITTLE_ENDIAN__
>  #define ELE 2
>  #else
>  #define ELE 1

I seem to have missed backporting this to GCC 7, where the same bug exists, so
I just committed the fix there too.

Peter

[wwwdocs] Consistently spell the noun "front end"

[Gerald Pfeifer]

I noticed this on one recent page, and looking into it then ended
up fixing a dozen more, historical and current.

Committed.

Gerald

Index: htdocs/frontends.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/frontends.html,v
retrieving revision 1.40
diff -u -r1.40 frontends.html
--- htdocs/frontends.html   28 Dec 2016 00:55:24 -  1.40
+++ htdocs/frontends.html   2 Apr 2018 15:16:30 -
@@ -40,8 +40,8 @@
 http://www.nongnu.org/gm2/;>GNU Modula-2 implements
 the PIM2, PIM3, PIM4 and ISO dialects of the language.  The compiler
 is fully operational with the GCC 4.1.2 back end (on GNU/Linux x86
-systems).  Work is in progress to move the frontend to the GCC trunk.
-The frontend is mostly written in Modula-2, but includes a bootstrap
+systems).  Work is in progress to move the front end to the GCC trunk.
+The front end is mostly written in Modula-2, but includes a bootstrap
 procedure via a heavily modified version of p2c.
 
 Modula-3 (for links see [2017-02-02]
  Support for the https://riscv.org;>RISC-V ISA was added, 
contributed by Palmer Dabbelt and Andrew Waterman.
 
-BRIG/HSAIL (Heterogeneous Systems Architecture Intermediate 
Language) frontend added
+BRIG/HSAIL (Heterogeneous Systems Architecture Intermediate 
Language) front end added
  [2017-02-01]
  http://www.hsafoundation.com/;> Heterogeneous Systems
  Architecture 1.0 BRIG (HSAIL)
- frontend was added to GCC,
+ front end was added to GCC,
  enabling HSAIL finalization for gcc-supported
  targets. The code was developed by
  http://parmance.com;>Parmance with sponsorship from
Index: htdocs/news.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/news.html,v
retrieving revision 1.159
diff -u -r1.159 news.html
--- htdocs/news.html18 Nov 2017 01:08:36 -  1.159
+++ htdocs/news.html2 Apr 2018 15:16:31 -
@@ -417,7 +417,7 @@
 December 2, 2010
 GCC 4.6 will support
   the https://golang.org/;>Go programming language.  The
-  new frontend was contributed by Ian Lance Taylor at Google.
+  new front end was contributed by Ian Lance Taylor at Google.
 
 November 16, 2010
 GCC 4.6 will include the
@@ -655,7 +655,7 @@
   Broadband Engine Architecture (BEA).
 
 January 1, 2007
-2006 has been a very productive year for the new Fortran frontend,
+2006 has been a very productive year for the new Fortran front end,
   with https://gcc.gnu.org/ml/gcc/2007-01/msg00059.html;>lots
   of improvements and fixes.
 
Index: htdocs/svn.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/svn.html,v
retrieving revision 1.218
diff -u -r1.218 svn.html
--- htdocs/svn.html 27 Jul 2017 09:17:28 -  1.218
+++ htdocs/svn.html 2 Apr 2018 15:16:32 -
@@ -547,7 +547,7 @@
   be marked with the tag [4_4-plugins] in the Subject line.
 
   gccgo
-  This branch is for the Go frontend to gcc.  For more information
+  This branch is for the Go front end to gcc.  For more information
 about the Go programming language,
 see https://golang.org/;>https://golang.org.  The
 branch is maintained by Ian Lance Taylor.  Patches should be
Index: htdocs/bugs/index.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/bugs/index.html,v
retrieving revision 1.121
diff -u -r1.121 index.html
--- htdocs/bugs/index.html  1 Dec 2017 01:18:03 -   1.121
+++ htdocs/bugs/index.html  2 Apr 2018 15:16:32 -
@@ -684,7 +684,7 @@
 Non-conforming legacy code that worked with older versions of GCC may be
 rejected by more recent compilers.  There is no command-line switch to ensure
 compatibility in general, because trying to parse standard-conforming and
-old-style code at the same time would render the C++ frontend unmaintainable.
+old-style code at the same time would render the C++ front end unmaintainable.
 However, some non-conforming constructs are allowed when the command-line
 option -fpermissive is used.
 
Index: htdocs/egcs-1.1/c++features.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/egcs-1.1/c++features.html,v
retrieving revision 1.5
diff -u -r1.5 c++features.html
--- htdocs/egcs-1.1/c++features.html11 Feb 2002 09:47:47 -  1.5
+++ htdocs/egcs-1.1/c++features.html2 Apr 2018 15:16:33 -
@@ -31,7 +31,7 @@
 * protected virtual inheritance is now supported.
 
 * Loops are optimized better; we now move the test to the end in most
-  cases, like the C frontend does.
+  cases, like the C front end does.
 
 * For class D derived from B which has a member 'int i', D::i is now of
   type 'int B::*' instead of 'int D::*'.
Index: htdocs/gcc-2.95/c++features.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-2.95/c++features.html,v
retrieving 

New Danish PO file for 'gcc' (version 8.1-b20180128)

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'gcc' has been submitted
by the Danish team of translators.  The file is available at:

http://translationproject.org/latest/gcc/da.po

(This file, 'gcc-8.1-b20180128.da.po', has just now been sent to you in
a separate email.)

All other PO files for your package are available in:

http://translationproject.org/latest/gcc/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

http://translationproject.org/domain/gcc.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

The Translation Project robot, in the
name of your translation coordinator.

New template for 'gcc' made available

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.  (If you have
any questions, send them to .)

A new POT file for textual domain 'gcc' has been made available
to the language teams for translation.  It is archived as:

http://translationproject.org/POT-files/gcc-8-b20180401.pot

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

Below is the URL which has been provided to the translators of your
package.  Please inform the translation coordinator, at the address
at the bottom, if this information is not current:

https://gcc.gnu.org/pub/gcc/snapshots/8-20180401/gcc-8-20180401.tar.xz

Translated PO files will later be automatically e-mailed to you.

Thank you for all your work,

The Translation Project robot, in the
name of your translation coordinator.

Re: [PATCH, rtl] Fix PR84878: Segmentation fault in add_cross_iteration_register_deps

[Alexander Monakov]

On Tue, 27 Mar 2018, Richard Biener wrote:
> > > so this is kind-of global regs being live across all BBs?  This sounds
> > > a bit stupid to me, but well ... IMHO those refs should be at
> > > specific insns like calls.
> > > 
> > > So maybe, with a big fat comment, it is OK to ignore artificial
> > > refs in this loop...
> > 
> > Yeah, I'd like someone else's opinion too, as I know even less about
> > real artificial uses (as opposed to my incorrect mention in my first
> > post). :-)
> 
> If they only appear in the exit/entry block ignoring them should be safe.
> 
> But who knows...

Roman and I discussed a related problem a few weeks ago, so here's my 2c.
As I don't have any special DF knowledge, this is merely my understanding.

(apropos i: SMS uses sched-deps for intra-loop deps, and then separately uses
DF for cross-iteration deps, which means that it should be ready for surprises
when the two scanners are not 100% in sync)

(apropos ii: given the flexibility of RTL, it would have been really nice
if there were no implicit cc0-like uses that need to be special-cased in DF,
sched-deps and other scanners)

In this case I believe it's fine to skip processing of r_use when the associated
BB is not the loop BB (i.e. 'if (DF_REF_BB (r_use->ref) != g->bb)' as Richard
suggested), but I'm concerned that skipping it when the artificial's use BB
corresponds to loop BB goes from ICE to wrong-code. It should be detected
earlier, in sms_schedule (see the comment starting with "Don't handle BBs with
calls or barriers").

Alexander

Re: [patch, fortran] Fix PR 85102, take 2

[Steve Kargl]

On Mon, Apr 02, 2018 at 02:05:29PM +0200, Thomas König wrote:
> +  if (as->type == AS_EXPLICIT)
> + {
> +   for (int i = 0; i < as->rank; i++)
> + {
> +   gfc_expr *e, *n;
> +   e = as->lower[i];
> +   if (e->expr_type != EXPR_CONSTANT)
> + {
> +   n = gfc_copy_expr (e);
> +   gfc_simplify_expr (n, 1);
> +   if (n->expr_type == EXPR_CONSTANT)
> + gfc_replace_expr (e, n);
  else
gfc_free_expr (n);
> + }
> +   e = as->upper[i];
> +   if (e->expr_type != EXPR_CONSTANT)
> + {
> +   n = gfc_copy_expr (e);
> +   gfc_simplify_expr (n, 1);
> +   if (n->expr_type == EXPR_CONSTANT)
> + gfc_replace_expr (e, n);
  else
gfc_free_expr (n);

> + }
> + }
> + }

Don't you need the above changes to avoid leaking memory?

-- 
Steve

PING^5: [PATCH] i386: Insert ENDBR before the profiling counter call

[H.J. Lu]

On Mon, Mar 26, 2018 at 4:09 AM, H.J. Lu  wrote:
> On Fri, Jan 26, 2018 at 6:23 AM, H.J. Lu  wrote:
>> On Sun, Jan 7, 2018 at 7:11 PM, H.J. Lu  wrote:
>>> On Tue, Oct 24, 2017 at 10:58 AM, H.J. Lu  wrote:
 On Tue, Oct 24, 2017 at 10:40 AM, Andi Kleen  wrote:
> "H.J. Lu"  writes:
>> --- /dev/null
>> +++ b/gcc/testsuite/gcc.target/i386/pr82699-4.c
>> @@ -0,0 +1,11 @@
>> +/* { dg-do compile { target { *-*-linux* && { ! ia32 } } } } */
>> +/* { dg-options "-O2 -fpic -fcf-protection -mcet -pg -mfentry 
>> -fasynchronous-unwind-tables" } */
>> +/* { dg-final { scan-assembler-times {\t\.cfi_startproc\n\tendbr} 1 }
>> } */
>
> Would add test cases for -mnop-mcount and -mrecord-mcount too
>

 Here is the updated patch to add a testcase for -mnop-mcount 
 -mrecord-mcount.
 No other changes otherwise.

>>>
>>> PING:
>>>
>>> https://gcc.gnu.org/ml/gcc-patches/2017-10/msg01741.html
>>>
>>>
>>
>> PING.
>
> PING.
>

PING.

-- 
H.J.

PING^: [GCC 6] PATCH: Backport -mindirect-branch= patches

[H.J. Lu]

On Mon, Mar 26, 2018 at 4:04 AM, H.J. Lu  wrote:
> On Mon, Mar 19, 2018 at 10:04 AM, H.J. Lu  wrote:
>>>
>>> Here are GCC 6 patches to backport all -mindirect-branch= patches.
>>> OK for GCC 6.
>>>
>>
>
> PING:
>
> https://gcc.gnu.org/ml/gcc-patches/2018-03/msg00884.html
>

PING.


-- 
H.J.

[patch, fortran] Fix PR 85102, take 2

[Thomas König]

Hello world,

here is the second version of the fix for PR 85102. This
is a much more general approach, which actually uses simplification
(while avoiding some "interesting" regressions when resolving, or
simplifying, too soon...)

Thanks to Dominique for the hint about the problem with my first patch.

Regression-tested. OK for trunk?

Regards

Thomas

2018-04-02  Thomas Koenig  

PR fortran/85102
* decl.c (variable_decl): If upper or lower bounds simplify
to a constant, use that.

2018-04-02  Thomas Koenig  

PR fortran/85102
* gfortran.dg/array_simplify_2.f90: New test.
! { dg-do  run }
! PR 85102 - this used to ICE
! Original test case by Gerhard Steinmetz
program p
   integer, parameter :: a((1+2)) = 1
   integer, parameter :: b((1+1)+1) = 1
   integer, parameter :: c = dot_product(a, a)
   integer, parameter :: d = dot_product(b,b)
   if (c /= 3) stop 1
   if (d /= 3) stop 2
 end program p
Index: decl.c
===
--- decl.c	(revision 258845)
+++ decl.c	(working copy)
@@ -2424,6 +2424,29 @@ variable_decl (int elem)
 	  goto cleanup;
 	}
 	}
+  if (as->type == AS_EXPLICIT)
+	{
+	  for (int i = 0; i < as->rank; i++)
+	{
+	  gfc_expr *e, *n;
+	  e = as->lower[i];
+	  if (e->expr_type != EXPR_CONSTANT)
+		{
+		  n = gfc_copy_expr (e);
+		  gfc_simplify_expr (n, 1);
+		  if (n->expr_type == EXPR_CONSTANT)
+		gfc_replace_expr (e, n);
+		}
+	  e = as->upper[i];
+	  if (e->expr_type != EXPR_CONSTANT)
+		{
+		  n = gfc_copy_expr (e);
+		  gfc_simplify_expr (n, 1);
+		  if (n->expr_type == EXPR_CONSTANT)
+		gfc_replace_expr (e, n);
+		}
+	}
+	}
 }
 
   char_len = NULL;

PING^4 [PATCH] i386: Avoid PLT when shadow stack is enabled directly

[H.J. Lu]

On Mon, Mar 26, 2018 at 4:06 AM, H.J. Lu  wrote:
> On Sat, Mar 17, 2018 at 5:55 AM, H.J. Lu  wrote:
>> On Fri, Dec 8, 2017 at 5:02 AM, H.J. Lu  wrote:
>>> On Tue, Oct 24, 2017 at 5:31 AM, H.J. Lu  wrote:
 PLT should be avoided with shadow stack in 32-bit mode if more than 2
 parameters are passed in registers since only 2 parameters can be passed
 in registers for external function calls via PLT with shadow stack
 enabled.

 OK for trunk if there is no regressions?
>>>
>>> Here is the updated patch.
>>>
>>> PING.
>>>
>>
>> https://gcc.gnu.org/ml/gcc-patches/2017-12/msg00485.html
>>
>> PING.
>>
>
> PING.
>

PING.


-- 
H.J.

Re: [PATCH] Use dlsym to check if libdl is needed for plugin

[H.J. Lu]

On Wed, Oct 18, 2017 at 5:25 PM, H.J. Lu  wrote:
> config/plugins.m4 has
>
>  if test "$plugins" = "yes"; then
> AC_SEARCH_LIBS([dlopen], [dl])
>   fi
>
> Plugin uses dlsym, but libasan.so only intercepts dlopen, not dlsym:
>
> [hjl@gnu-tools-1 binutils-text]$ nm -D /lib64/libasan.so.4| grep " dl"
> 00038580 W dlclose
>  U dl_iterate_phdr
> 0004dc50 W dlopen
>  U dlsym
>  U dlvsym
> [hjl@gnu-tools-1 binutils-text]$
>
> Testing dlopen for libdl leads to false negative when -fsanitize=address
> is used.  It results in link failure:
>
> ../bfd/.libs/libbfd.a(plugin.o): undefined reference to symbol 
> 'dlsym@@GLIBC_2.16'
>
> dlsym should be used to check if libdl is needed for plugin.
>
> OK for master?
>
> H.J.
> ---
> bfd/
>
> PR gas/22318
> * configure: Regenerated.
>
> binutils/
>
> PR gas/22318
> * configure: Regenerated.
>
> config/
>
> * plugins.m4 (AC_PLUGINS): Use dlsym to check if libdl is needed.
>
> gas/
>
> PR gas/22318
> * configure: Regenerated.
>
> gprof/
>
> PR gas/22318
> * configure: Regenerated.
>
> ld/
>
> PR gas/22318
> * configure: Regenerated.


> diff --git a/config/plugins.m4 b/config/plugins.m4
> index 513c690e1b..c6acebc1ca 100644
> --- a/config/plugins.m4
> +++ b/config/plugins.m4
> @@ -16,6 +16,6 @@ AC_DEFUN([AC_PLUGINS],
>  [plugins=$maybe_plugins]
>)
>if test "$plugins" = "yes"; then
> -AC_SEARCH_LIBS([dlopen], [dl])
> +AC_SEARCH_LIBS([dlsym], [dl])
>fi
>  ])

If there are no objections, I will check into binutils master branch this week.



-- 
H.J.

Re: [documentation patch] add detail to const and pure attributes

[Sandra Loosemore]

On 03/27/2018 03:21 PM, Pedro Alves wrote:

On 03/27/2018 09:19 PM, Martin Sebor wrote:

On 03/27/2018 01:38 PM, Pedro Alves wrote:

On 03/27/2018 07:18 PM, Martin Sebor wrote:

+Because a @code{pure} function can have no side-effects it does not


FWIW, I'd suggest rephrasing as:

  Because a @code{pure} function cannot have side effects

because "can have no side-effects" can be read as
"is allowed to have no side effects", which gave me pause
when I read it the first time, and is the opposite of
what you mean.


That is what I meant: that const and pure functions are not allowed
to have any side-effects.  If they did, they could be unexpectedly
eliminated (i.e., the behavior is undefined when such a function
does have a side-effect).


I know, but that's not what I read the first time (and found it
odd so I had to re-read).  You can either assume that I'm the
only one that will misunderstand it on first read, or you can
swap a couple words and be sure no one will misunderstand it.

Up to you.


I'm chiming in a little late here, but I agree with Pedro that "can have 
no side-effects" is confusing.  I'd say "cannot have side effects" or 
"must have no side effects" instead.


Also note that non-hyphenated "side effects" seems to be preferred usage
as a noun phrase (at least it's the only form listed by m-w.com).

-Sandra