[Bug c++/104111] [DR2589] Concept evaluation depends on context where it was first checked

[webrown.cpp at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104111

--- Comment #10 from W E Brown  ---
(In reply to Eric Estievenart from comment #9)

Sorry, but I find neither "weirdness" nor "spooky"-ness in the comment #9 code
as shown.  Rather, I believe it to be simply an example of a program that the
C++ standard would describe as "ill-formed, no diagnostic required."

A common, yet incorrect expectation that template instantiation somehow mirrors
function call semantics seems to me to lie at the heart of the
misunderstanding.  Hypothetically, if the above program were to be well-formed,
the compiler would need to instantiate the member template twice *with
identical template arguments* in order to obtain the expected two different
outcomes.  However, I recall no specification, in the C++ standard, that
requires such (relatively expensive!) duplication of compiler effort:  once a
template has been instantiated, the compiler seems fully entitled, say, to
cache the result of that instantiation and reuse that outcome as may be needed
during the remainder of that TU's compilation.

Put another way, defining the same function in two different ways (one
instantiation as deleted, one not) seems to be a form of ODR violation.

Perhaps the OP is also a manifestation of a similar misunderstanding; I've not
checked.  If so, I would respectfully recommend this PR be closed as invalid.

[Bug c++/108205] New: ICE following "unused parameter" in precondition

[webrown.cpp at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108205

Bug ID: 108205
   Summary: ICE following "unused parameter" in precondition
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: webrown.cpp at gmail dot com
  Target Milestone: ---

Using (Homebrew GCC HEAD-37c2d99) 13.0.0 20221213 (experimental)
and compiling via:
  g++-HEAD -std=c++23 -fmodules-ts -fcontracts -pedantic-errors \
-O0 -Wall -Wextra -Werror -Wpedantic \
-fno-builtin -fconcepts-diagnostics-depth=2
on an x86 MacBook Pro.

This code compiles:

[[nodiscard]] constexpr int
  quotient( double x, double y ) noexcept
{
  [[assume (y != 0.0)]];
  return int(x / y);
}

The same code also compiles as a module:

export module test;
export [[nodiscard]] constexpr int
  quotient( double x, double y ) noexcept
{
  [[assume (y != 0.0)]];
  return int(x / y);
}

But reformulating the assumption as a precondition causes issues.
First, this code is diagnosed with "unused parameter 'x'", which
seems misleading:

[[nodiscard]] constexpr int
  quotient( double x, double y ) noexcept
  [[ pre: y != 0.0 ]]
{
  return int(x / y);
}

Second, when the above is compiled as a module, the compiler 
additionally segfaults:

export module test;
export [[nodiscard]] constexpr int
  quotient( double x, double y ) noexcept
  [[ pre: y != 0.0 ]]
{
  return int(x / y);
}

[Bug libstdc++/107778] handle_contract_violation should reflect _GLIBCXX_VERBOSE

[webrown.cpp at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107778

--- Comment #10 from W E Brown  ---
> On Dec 22, 2022, at 6:51 PM, cvs-commit at gcc dot gnu.org 
>  wrote:
> 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107778
> 
> --- Comment #9 from CVS Commits  ---
> The master branch has been updated by Jason Merrill :
> 
> https://gcc.gnu.org/g:8ec5fcb6fc79e5bcca23c3fecbaf09d4566cb1d5
> 
> commit r13-4861-g8ec5fcb6fc79e5bcca23c3fecbaf09d4566cb1d5
> Author: Arsen ArsenoviÄ 
> Date:   Thu Dec 22 12:03:06 2022 +0100
> 
>libstdc++: Improve output of default contract violation handler [PR107792]
> 
>Make the output more readable. Don't output anything unless verbose
>termination is enabled at configure-time.
> 
>The testsuite change was almost entirely mechanical.  Save for two files
>which had very short matches, these changes were produced by two seds and a
>Perl script, for the more involved cases.  The latter will be added in a
>subsequent commit.  The former are as follows:
> 
>sed -E -i "/dg-output/s/default std::handle_contract_violation called:
> \
>(\S+) (\S+) (\S+(<[A-Za-z0-9, ]*)?>?)\
>/contract violation in function \3 at \1:\2: /" *.C
>sed -i '/dg-output/s/  */ /g'
> 
>Whichever files remained failing after the above changes were checked-out,
>re-ran, with output extracted, and ran through dg-out-generator.pl.
> 
>Co-Authored-By: Jonathan Wakely 
> 
>libstdc++-v3/ChangeLog:
> 
>PR libstdc++/107792
>PR libstdc++/107778
>* src/experimental/contract.cc (handle_contract_violation): Make
>output more readable.
> 
>gcc/testsuite/ChangeLog:
> 
>* g++.dg/contracts/contracts-access1.C: Convert to new default
>violation handler.
>* g++.dg/contracts/contracts-assume2.C: Ditto.
>* g++.dg/contracts/contracts-config1.C: Ditto.
>* g++.dg/contracts/contracts-constexpr1.C: Ditto.
>* g++.dg/contracts/contracts-ctor-dtor1.C: Ditto.
>* g++.dg/contracts/contracts-deduced2.C: Ditto.
>* g++.dg/contracts/contracts-friend1.C: Ditto.
>* g++.dg/contracts/contracts-multiline1.C: Ditto.
>* g++.dg/contracts/contracts-post3.C: Ditto.
>* g++.dg/contracts/contracts-pre10.C: Ditto.
>* g++.dg/contracts/contracts-pre2.C: Ditto.
>* g++.dg/contracts/contracts-pre2a2.C: Ditto.
>* g++.dg/contracts/contracts-pre3.C: Ditto.
>* g++.dg/contracts/contracts-pre4.C: Ditto.
>* g++.dg/contracts/contracts-pre5.C: Ditto.
>* g++.dg/contracts/contracts-pre7.C: Ditto.
>* g++.dg/contracts/contracts-pre9.C: Ditto.
>* g++.dg/contracts/contracts-redecl3.C: Ditto.
>* g++.dg/contracts/contracts-redecl4.C: Ditto.
>* g++.dg/contracts/contracts-redecl6.C: Ditto.
>* g++.dg/contracts/contracts-redecl7.C: Ditto.
>* g++.dg/contracts/contracts-tmpl-spec1.C: Ditto.
>* g++.dg/contracts/contracts-tmpl-spec2.C: Ditto.
>* g++.dg/contracts/contracts-tmpl-spec3.C: Ditto.
>* g++.dg/contracts/contracts10.C: Ditto.
>* g++.dg/contracts/contracts14.C: Ditto.
>* g++.dg/contracts/contracts15.C: Ditto.
>* g++.dg/contracts/contracts16.C: Ditto.
>* g++.dg/contracts/contracts17.C: Ditto.
>* g++.dg/contracts/contracts19.C: Ditto.
>* g++.dg/contracts/contracts25.C: Ditto.
>* g++.dg/contracts/contracts3.C: Ditto.
>* g++.dg/contracts/contracts35.C: Ditto.
>* g++.dg/contracts/contracts5.C: Ditto.
>* g++.dg/contracts/contracts7.C: Ditto.
>* g++.dg/contracts/contracts9.C: Ditto.
> 
> -- 
> You are receiving this mail because:
> You are on the CC list for the bug.

[Bug c++/108052] New: forward-declared constexpr variable template unusable in constexpr context

[webrown.cpp at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108052

Bug ID: 108052
   Summary: forward-declared constexpr variable template unusable
in constexpr context
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: webrown.cpp at gmail dot com
  Target Milestone: ---

Similar to bug 59123, the following code compiles with no complaint:

  extern const double e;  // a fwd-declaration
  constexpr double e = 2.71;  // its corresponding def'n
  static_assert( e == 2.71 ); // verification

But the following analogous, templatized, code...:

  template< class T > extern const T pi; // a fwd-declaration
  template< class T > constexpr T pi = 3.14; // its corresponding def'n
  static_assert( pi == 3.14 );   // verification

... produces the following unexpected diagnostics:
  error: non-constant condition for static assertion
  error: the value of 'pi' is not usable in a constant expression
  note: 'pi' was not declared 'constexpr'

...when compiling with gcc version 13.0.0 20221122 and any of:
  -std=c++17, -std=c++20, or -std=c++23.

However, further experimentation reveals that the following int variation of
the above static_assert does compile (although an expected float-conversion
warning is produced if enabled):

  template< class T > extern const T pi; // a fwd-declaration

Finally, bug 92576 and bug 68012 seem tangentially related.
  template< class T > constexpr T pi = 3.14; // its corresponding def'n
  static_assert( pi == 3 ); // verification

A knowledgeable CWG colleague conjectures that the double-vs-int difference may
be "somehow related to the special rule for 'const integral types' vs.
'constexpr any type'."

Finally, bug 68012, bug 84255, and bug 92576 seem tangentially related,
although these do not involve any extern declaration.

[Bug c++/103049] [C++23] P0849R8 - auto(x): decay-copy in the language

[webrown.cpp at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103049

--- Comment #2 from W E Brown  ---
(In reply to Marek Polacek from comment #1)
> Patch on review.

In the proposed patch, I respectfully recommend a slight rewording of the new
pedwarn messages in gcc/cp/semantics.c and gcc/cp/typeck2.c:

  either s/only available with/available only with/
  or s/only available with/unavailable without/
  or s/only available with/requires/

would emphasize the required flag rather than focus on the feature's
availability.  (FWIW, of the above suggestions, the last ["requires"] seems to
me the most direct and simplest to understand.)

Thank you.

[Bug c++/101181] New: ICE when using an alias template

[webrown.cpp at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101181

Bug ID: 101181
   Summary: ICE when using an alias template
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: webrown.cpp at gmail dot com
  Target Milestone: ---

The following program produces "Segmentation fault: 11 signal terminated
program cc1plus" when compiled with flags

-std=c++23 -fmodules-ts -pedantic-errors -O0 -c

using gcc trunk version

(Homebrew GCC HEAD-da13e4e_1) 12.0.0 20210623 (experimental)


template< class T
, bool = requires { typename T::pointer; }
>
struct p { using type = void; };

template< class T >
struct p { using type = T::pointer; };

template< class T > using P = typename p::type;


Without the final alias template, all seems well.

[Bug c++/100687] New: [modules, concepts] imported concept gives different result

[webrown.cpp at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100687

Bug ID: 100687
   Summary: [modules, concepts] imported concept gives different
result
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: webrown.cpp at gmail dot com
  Target Milestone: ---

Using recent trunk [g++-HEAD (Homebrew GCC HEAD-5380e3c) 12.0.0 20210513],
compiling with significant flags -std=c++23 -fmodules-ts -c.

I have two source files, as follows:

//
export module bug_a;

template< class T >
inline constexpr bool probe = false;
//
template< class R, class C >
inline constexpr bool probe = true;

export
template< class T >
concept mbr_ptr = probe;

struct S { int f( ); };
using mf_t = decltype( ::f );

static_assert( mbr_ptr< mf_t > );
//

This bug_a module compiles successfully.  In particular, the static_assert
passes.

//
export module bug_b;

import bug_a;

struct S { int f( ); };
using mf_t = decltype( ::f );

static_assert( mbr_ptr< mf_t > );
//

This bug_b module does not compile.  The diagnostics are reproduced below,
including the somewhat mysterious lone apostrophe:

bug_b.cc:8:16: error: static assertion failed
8 | static_assert( mbr_ptr< mf_t > );
  |^~~
bug_b.cc:8:16: note: constraints not satisfied
'
bug_a.cc:12: confused by earlier errors, bailing out

Please note that the static_assert and supporting declarations in module bug_a
are identical to those in module bug_a, yet one compiles while the other does
not.

Thus we seem to have two problems:  (1) the lone apostrophe amongst the
diagnostics, and (2) the inconsistent evaluation of identical expressions.

Finally, please note that if I use a class template (instead of the variable
template) in module bug_a, both modules' static_asserts now compile without
complaint:

//
template< class T >
struct probe { static constexpr bool value = false; };
//
template< class R, class C >
struct probe { static constexpr bool value = true; };

export
template< class T >
concept
  mbr_ptr = probe::value;
//

[Bug c++/100335] Using statement of a ref-qualified method from base class: method not callable on derived object

[webrown.cpp at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100335

--- Comment #4 from W E Brown  ---
I won't comment on any compiler's behavior, but do want to thank you for
reminding me of [namespace.udecl]/14:

"When a using-declarator brings declarations from a base class into a derived
class, member functions ... in the derived class override and/or hide member
functions .. with the same name, parameter-type-list ..., and ref-qualifier (if
any), in a base class"

Upon reflection, I believe that [namespace.udecl]/14 does not apply to the
original example because the ref-qualifier on Derived::method (i.e., none) is
not "the same" as the ref-qualifier on either Base::method.  Thus, there's no
overriding and/or hiding to be done there.

However, I believe that [namespace.udecl]/14 *does* apply to the example in
Comment 3, where Base::method and Derived::method do have "the same"
ref-qualifier (i.e., none).  There, Derived::method ought to hide Base::method
as [over.load]/2.3 seems be inapplicable.

In brief, I believe Comment 3's example ought compile due to
[namespace.udecl]/14, but the original example ought not compile due to
[over.load]/2.3.

[Bug c++/100335] Using statement of a ref-qualified method from base class: method not callable on derived object

[webrown.cpp at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100335

W E Brown  changed:

   What|Removed |Added

 CC||webrown.cpp at gmail dot com

--- Comment #1 from W E Brown  ---
According to C++20 [over.load]/2.3:

"Member function declarations ... cannot be overloaded if any of them, but not
all, have a ref-qualifier"

Therefore, the above example's Base class compiles because each of its
overloaded member functions has a ref-qualifier.  However, Derived::method is
not ref-qualified, so treating it as an overload of those Base functions would
violate the above-cited passage.

Accordingly, unless I've overlooked some exception to this rule, I respectfully
suggest this issue be closed as invalid.

[Bug c++/99686] ICE when using both concepts and full specialization

[webrown.cpp at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99686

--- Comment #4 from W E Brown  ---
(In reply to Steven Sun from comment #3)
>  I would expect the complete specialization is full
> specialization for both primary templates.

No, any given explicit or partial specialization can be a specialization of
only one primary template.  (Suppose that two overloaded primary templates had
different signatures.  How then, in general, could both be specialized by any
single explicit or partial specialization?)

> ... 
> In conclusion, this makes sences but I didn't see that coming. Anyway, I
> think a possible improvement is make ICE to an error of "ambigous full
> specialization". Or even better, a change in C++23 standard.

Given two or more very similar primary templates, C++ already specifies an
algorithm (known as "partial* ordering") to determine which one is being
specialized by a given explicit or partial specialization.  Therefore, unless
you can find some issue with that algorithm, I see no reason to propose any
language change in this area; partial ordering has been part of C++ for several
decades.

(However, I speculate that your test cases may have exposed a bug in GCC's
implementation of partial ordering, possibly just a failure to diagnose an
ambiguous situation.  I'm sure the GCC internals experts will provide proper
diagnosis and remediation in due course.)


* The algorithn is termed "partial" because there are cases that can't be
decided and therefore result in an ill-formed program.  If you'd like some
further details on this topic, I can recommend my video 
https://www.youtube.com/watch?v=nfIX8yWlByY.

[Bug c++/99686] ICE when using both concepts and full specialization

[webrown.cpp at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99686

W E Brown  changed:

   What|Removed |Added

 CC||webrown.cpp at gmail dot com

--- Comment #2 from W E Brown  ---
Since C++ has no partial specializations of function templates, the test case
in Comment 1 is somewhat mischaracterized there.

Instead, what we have in that test case are, first, two distinct primary
templates that happen to share a common name within a single scope, and hence
overload that name.  Note that these primary templates are distinguishable
because one is more constrained (via its requires-clause) than the other (which
is unconstrained):  whenever these primary templates produce equally viable
candidates during overload resolution, C++ specifies that the more constrained
declaration should be selected.

Finally, the test case defines a complete specialization, but which of the
overloaded primary templates is being specialized?  That's the real question
for the compiler to determine in its role of language lawyer.  Note that if one
of the two primary templates were removed from the test case, the compiler's
decision would become near-trivial to make, as there would remain only a single
candidate.  If, instead, the explicit specialization were removed from the test
case, such a compiler determination would be no longer needed at all.

[Bug c++/98735] New: ICE with -std=c++20 -fmodules-ts -fsanitize=undefined

[webrown.cpp at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98735

Bug ID: 98735
   Summary: ICE with -std=c++20 -fmodules-ts -fsanitize=undefined
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: webrown.cpp at gmail dot com
  Target Milestone: ---

Using gcc version 11.0.0 20210116 (experimental) (Homebrew GCC HEAD-2c356f2_2)
and compiling with flags:
   -std=c++20 -fmodules-ts -fsanitize=undefined
produces:
  internal compiler error: in tree_node, at cp/module.cc:9125
pointing at the module keyword (line 1) in the following innocuous program:

  export module X;

  export
inline constexpr bool f( ) noexcept
{ return true; }

Removing -fsanitize=undefined permits successful compilation.

[Bug c++/95999] New: ICE in tree check: expected integer_cst, have var_decl in get_len, at tree.h:5951

[webrown.cpp at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95999

Bug ID: 95999
   Summary: ICE in tree check: expected integer_cst, have var_decl
in get_len, at tree.h:5951
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Keywords: error-recovery, ice-on-invalid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: haoxintu at gmail dot com
CC: webrown.cpp at gmail dot com
  Target Milestone: ---
CC: webrown.cpp at gmail dot com

This code, bug.cc, reduced by C-Reduce, makes GCC-trunk ICE.

$cat bug.cc
int a;
enum struct b;
template  enum struct b { e };


$g++ bug.cc
bug.cc:3:42: error: the value of ‘a’ is not usable in a constant expression
3 | template ’ before ‘d’
bug.cc:3:46: error: expected unqualified-id before ‘}’ token
3 | template  enum struct b { e };
  | ^
0x7c2dcf tree_check_failed(tree_node const*, char const*, int, char const*,
...)
../../gcc/tree.c:9685
0x61582f tree_check(tree_node const*, char const*, int, char const*, tree_code)
../../gcc/tree.h:3557
0x61582f wi::extended_tree<192>::get_len() const
../../gcc/tree.h:5951
0x61582f wi::int_traits >
>::decompose(long*, unsigned int, generic_wide_int >
const&)
../../gcc/wide-int.h:985
0x61582f wide_int_ref_storage::wide_int_ref_storage >
>(generic_wide_int > const&, unsigned int)
../../gcc/wide-int.h:1034
0x61582f generic_wide_int
>::generic_wide_int >
>(generic_wide_int > const&, unsigned int)
../../gcc/wide-int.h:790
0x61582f wi::binary_traits >, int,
wi::int_traits > >::precision_type,
wi::int_traits::precision_type>::result_type
wi::add >,
int>(generic_wide_int > const&, int const&, signop,
wi::overflow_type*)
../../gcc/wide-int.h:2467
0x61582f build_enumerator(tree_node*, tree_node*, tree_node*, tree_node*,
unsigned int)
../../gcc/cp/decl.c:15857
0x9a2447 cp_parser_enumerator_definition
../../gcc/cp/parser.c:19545
0x9a2447 cp_parser_enumerator_list
../../gcc/cp/parser.c:19474
0x9a2447 cp_parser_enum_specifier
../../gcc/cp/parser.c:19405
0x9a2447 cp_parser_type_specifier
../../gcc/cp/parser.c:17734
0x9a2a02 cp_parser_decl_specifier_seq
../../gcc/cp/parser.c:14410
0x9c8f35 cp_parser_single_declaration
../../gcc/cp/parser.c:29459
0x9ca0f0 cp_parser_explicit_specialization
../../gcc/cp/parser.c:17654
0x9ccac9 cp_parser_declaration
../../gcc/cp/parser.c:13430
0x9cd06a cp_parser_translation_unit
../../gcc/cp/parser.c:4761
0x9cd06a c_parse_file()
../../gcc/cp/parser.c:44043
0xae4dbb c_common_parse_file()
../../gcc/c-family/c-opts.c:1190
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

$g++ --version
g++ (GCC) 11.0.0 20200626 (experimental)
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[Bug c++/95963] [11 Regression] ICE: Segmentation fault (in contains_struct_check)

[webrown.cpp at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95963

W E Brown  changed:

   What|Removed |Added

 CC||webrown.cpp at gmail dot com

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Jakub Jelinek :

https://gcc.gnu.org/g:8dc933c12f489626339b3ba1a8e2dc23eb4de98e

commit r11-1728-g8dc933c12f489626339b3ba1a8e2dc23eb4de98e
Author: Jakub Jelinek 
Date:   Tue Jun 30 11:42:54 2020 +0200

c-family: Avoid ICEs on calls to internal functions [PR95963]

The following testcase ICEs since recent Martin's -Wnonnull changes,
we see a CALL_EXPR and ICE because CALL_EXPR_FN is NULL, which is
valid for internal function calls.  Internal function calls don't have a
function type, and will never have format_arg attribute on them nor will
serve as the i18n routines -Wformat cares about.

2020-06-30  Jakub Jelinek  

PR c++/95963
* c-common.c (check_function_arguments_recurse): Don't crash on
calls to internal functions.

* g++.dg/cpp1z/launder9.C: New test.

[Bug c++/95993] New: the error of multi-array init in gcc 10.1

[webrown.cpp at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95993

Bug ID: 95993
   Summary: the error of multi-array init in gcc 10.1
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chengcongxiu at huawei dot com
CC: webrown.cpp at gmail dot com
  Target Milestone: ---
CC: webrown.cpp at gmail dot com

the main2.cpp as follow:

#include 
using namespace std;
void FuncA(int arg1, int arg2)
{
  int i = 0, j = 0;
  unsigned char noConst = 2;
  const unsigned char index1 = 16;
  const unsigned char index2 = noConst;
  unsigned char temp3[index1][index2] = { 0 };
  for(i = 0; i < index1; i++) {
for(j = 0; j < index2; j++) {
  printf("%d\t", temp3[i][j]);
}
printf("\n");
  }
}
int main()
{
  FuncA(0, 0);
  return 0;
}

./arm64be/bin/aarch64_be-linux-gnu-g++ main2.cpp -static -o app

./app0   
the result is:

0   0
0   83
65  24
0   0
0   0
0   1
28  0
0   0
0   64
0   128
3   232
0   0
0   64
0   128
3   248

everyone know what's wrong? is the internal error of gcc?

[Bug libstdc++/95989] New: Segmentation fault compiling with static libraries and using jthread::request_stop

[webrown.cpp at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95989

Bug ID: 95989
   Summary: Segmentation fault compiling with static libraries and
using jthread::request_stop
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: antal.buss at ualberta dot ca
CC: webrown.cpp at gmail dot com
  Target Milestone: ---
CC: webrown.cpp at gmail dot com

A simple program creating a jthread and later calling request_stop on the
created thread produces a segmentation fault when the program is compiled
against the static libraries but works fine using dynamic libraries.

--- Comment #1 from Antal Buss  ---
Created attachment 48811
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48811=edit
Preprocessed file

--- Comment #2 from Antal Buss  ---
Created attachment 48812
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48812=edit
Compiler output

--- Comment #3 from Richard Biener  ---
*** Bug 95990 has been marked as a duplicate of this bug. ***

--- Comment #4 from Richard Biener  ---
*** Bug 95991 has been marked as a duplicate of this bug. ***

[Bug libstdc++/95992] New: chrono adding duration to time_point reports signed integer overflow with -fsanitize=undefined

[webrown.cpp at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95992

Bug ID: 95992
   Summary: chrono adding duration to time_point reports signed
integer overflow with -fsanitize=undefined
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redboltz at gmail dot com
CC: webrown.cpp at gmail dot com
  Target Milestone: ---
CC: webrown.cpp at gmail dot com

When I add a duration to std::chrono::time_point,
then signed integer overflow is reported on runtime.

The compile option I set is -fsanitize=undefined -std=gnu++2a

I call test() three times but the error is reported only the first call.
I think that it is weird.


Code:

#include 
#include 

using duration_t = std::chrono::system_clock::duration;

void test() {
std::chrono::time_point tp;

auto ns = std::chrono::nanoseconds(145224192L);
auto s  = std::chrono::seconds(-9223372037LL);
tp += std::chrono::duration_cast(ns);
std::cout << "before add sec" << std::endl;
tp += std::chrono::duration_cast(s);
std::cout << "after  add sec" << std::endl;
}

int main() {
std::cout << "<<< 1 >>>" << std::endl;
test();
std::cout << "<<< 2 >>>" << std::endl;
test();
std::cout << "<<< 3 >>>" << std::endl;
test();
}


Output:

<<< 1 >>>
before add sec
/opt/wandbox/gcc-10.1.0/include/c++/10.1.0/chrono:197:38: runtime error: signed
integer overflow: -9223372037 * 10 cannot be represented in type 'long
int'
/opt/wandbox/gcc-10.1.0/include/c++/10.1.0/chrono:474:8: runtime error: signed
integer overflow: 9223372036709551616 + 145224192 cannot be represented in type
'long int'
after  add sec
<<< 2 >>>
before add sec
after  add sec
<<< 3 >>>
before add sec
after  add sec


Runable Demo:

g++ 10.1.0
https://wandbox.org/permlink/uQja7r4XZYyGIMjI

clang++ 10.0.0 (libc++)
https://wandbox.org/permlink/aDskiG7oaKj2R2dW


Error reported case:
 * g++ 10.1.0 with libstdc++ 10.1.0 
 * clang++ 10.0.0 with libstdc++ 10.1.0
No error case:
 * clang++ 10.0.0 with libc++ 10.0.0

Environment:

Linux 5.7.4-arch1-1 #1 SMP PREEMPT Thu, 18 Jun 2020 16:01:07 + x86_64
GNU/Linux

[Bug c++/92426] ICE on spaceship declaration plus other P1185R2 interaction issue

[webrown.cpp at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92426

--- Comment #2 from W E Brown  ---
Please note that the submitted test program seems not to meet the #include
requirement as articulated in N4835 clause [expr.spaceship] p10:

"10 The five comparison category types (17.11.2) (the types
std::strong_ordering, std::strong_equality, std::weak_ordering,
std::weak_equality, and std::partial_ordering) are not predefined; if the
header  (17.11.1) is not included prior to a use of such a class type
– even an implicit use in which the type is not named (e.g., via the auto
specifier (9.2.8.5) in a defaulted three-way comparison (11.11.3) or use of the
built-in operator) – the program is ill-formed."

[Bug other/87343] New: Incomplete documentation for built-in type traits

[webrown.cpp at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87343

Bug ID: 87343
   Summary: Incomplete documentation for built-in type traits
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: webrown.cpp at gmail dot com
  Target Milestone: ---

The manual page https://gcc.gnu.org/onlinedocs/gcc/Type-Traits.html seems to be
missing descriptions of several built-in type traits in current (trunk) use for
implementing the C++  header.

The missing entries seem to include __is_final, __is_trivially_copyable,
__is_assignable, __is_trivially_constructible, __is_trivially_assignable,
__is_aggregate, and __is_constructible.

Also, while the __is_same trait is documented in section 7.10 (Concepts), its
description seems perhaps to belong better among the other built-ins in 7.9
(Type Traits).  I believe that this trait's placement in 7.10 is simply a
historical artifact, and that no harm would accrue from relocating it to 7.9.

(Bug 48748 is similar in nature, but has long since been addressed.)

[Bug libstdc++/87193] symbols in have inconsistent types

[webrown.cpp at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87193

--- Comment #3 from W E Brown  ---
Sorry; hadn't seen or recalled the note cited by comment 1.

Agreed with comment 2 that this need not be a priority.  My (admittedly
hostile) experimental code caught it, so I thought to note it for the record.

Thanks for confirming.

[Bug libstdc++/87193] New: symbols in have inconsistent types

[webrown.cpp at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87193

Bug ID: 87193
   Summary: symbols in  have inconsistent types
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: webrown.cpp at gmail dot com
  Target Milestone: ---

In the new  header, most symbols are given a value of type int, rather
than a value of type long as mandated by [support.limits.general] Table 35 of
N4762.

For example, we find these consecutive macro def'ns:

#define __cpp_lib_is_final 201402L
#define __cpp_lib_make_reverse_iterator 201402

in which the values are to be identical, yet have distinct types.


Code such as:

#include 
static_assert( std::is_same_v );
static_assert( std::is_same_v
);

will detect the difference.

[Bug c++/86642] Spurious return type warning with enable_if

[webrown.cpp at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86642

W E Brown  changed:

   What|Removed |Added

 CC||webrown.cpp at gmail dot com

--- Comment #1 from W E Brown  ---
I believe this issue is based on a minor misunderstanding.

As written, the return type is never a void type.  However, a small adjustment
in the return type gives what seems to be the intended effect:

  std::enable_if_t  // assumes C++14 or later
or
  typename std::enable_if::type  // any C++ dialect

Either will work to invoke the enable_if metafunction and produce a SFINAE
effect.  However, as written, the metafunction is not invoked and so does not
activate SFINAE. 

However, as written, the code says that func will return an object of this
metafunction's type; since the function does not do so, the warning seems
correct.  I respectfully recommend this issue be closed as INVALID.

[Bug c++/85958] Make const qualifier error clear

[webrown.cpp at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85958

--- Comment #8 from W E Brown  ---
C++ seems very clear that the semantics of parameter passage are those of
initialization.  For example, according to [expr.call]/7 in N4741:

"When a function is called, each parameter shall be initialized with its
corresponding argument" [cross-references omitted].

(1) We might therefore consider to rephrase the diagnostic so as to be
consistent with the Standard's nomenclature.  For example:

"can't initialize parameter of type 'int&' with argument of type 'const int'"

Or, flipping the phrasing:

"argument of type 'const int' can't initialize parameter of type 'int&'"

(I prefer the latter, actually, because the caret indicates the argument.
YMMV.)

(2) For the same reason, the note accompanying the diagnostic might at the same
time be more accurately rephrased as "initializing parameter 1 of ..." instead
of the current "initializing argument 1 of ...".

(3) Finally, there seems to be a fair amount of redundancy in the note,
mentioning the called function both with and without its parameter's name. 
Perhaps just one of these might suffice?

Just some thoughts for your consideration.

[Bug c++/85689] if constexpr compiles false branch

[webrown.cpp at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85689

W E Brown  changed:

   What|Removed |Added

 CC||webrown.cpp at gmail dot com

--- Comment #1 from W E Brown  ---
I believe the test program demonstrates that g++ is behaving correctly in
processing static_assert in the context of a constexpr if.

The demonstrated behavior is part of the design of the constexpr if facility as
proposed for and adopted into C++17.  Please see wg21.link/p0292, which in
section "Not proposed" exhibits an example very similar to the submitted test
program, pronouncing it "ill-formed".

I respectfully recommend this issue be closed as INVALID, as it seems to be
based on a misunderstanding.

[Bug libstdc++/85439] mt19937_64 producing unexpected result only in certain configuration

[webrown.cpp at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85439

--- Comment #5 from W E Brown  ---
(In reply to Marc "Foddex" Oude Kotte from comment #4)
> The reason I was expecting the same result everywhere is because of this
> statement on cppreference.com:
> 
> 
> "Notes
> The 1th consecutive invocation of a default-contructed std::mt19937 is
> required to produce the value 4123659995.
> 
> The 1th consecutive invocation of a default-contructed std::mt19937_64
> is required to produce the value 9981545732273789042"
> 
> 
> Source:
> http://en.cppreference.com/w/cpp/numeric/random/mersenne_twister_engine
> 
> Obviously I'm not testing the 1th consecutive invocation but the 1st,
> but I still expected things to be similar (and they are, in 7/8 test cases).

The cited text is correct, but the attached program doesn't test it.

In particular, the attached program tests nothing about calling any Mersenne
twister object; rather, it looks at the results of calling
uniform_int_distribution objects.  As specified in C++, distribution objects
are not required to produce identical results across platforms, even if given
identical inputs.  Any expectation to the contrary is not supported by the C++
standard.

ISTM that testing the behavior of std::mt19937 and std::mt19937_64 -- or of any
engine, for that matter -- ought not involve any distribution object at all. 
Instead, such a test program should IMO be looking at the result(s) of directly
invoking the engine.

Comment #2 was exactly right.  I recommend this report be closed as invalid.

[Bug c++/80144] Concept introduced with "template" is not diagnosed

[webrown.cpp at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80144

--- Comment #2 from W E Brown  ---
> Confirmed, although I'm not sure which of those 2 options is correct...

Per N4687, [temp.concept]/4:
  A concept shall not have associated constraints (17.4.2).

Since Second's declaration does specify Never as an associated constraint,
Second's declaration appears to be in error.  Any such declarations ought
likely be diagnosed accordingly.

[Bug c++/81901] New: false-positive -Warray-bounds

[webrown.cpp at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81901

Bug ID: 81901
   Summary: false-positive -Warray-bounds
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vermaelen.wouter at gmail dot com
CC: webrown.cpp at gmail dot com
  Target Milestone: ---
CC: webrown.cpp at gmail dot com

When switching from gcc-6 to gcc-7 my application triggers some new compiler
warnings (with -Wall). I believe these warnings are false-positives. But I
don't see an easy way to work around them. I also tested with a gcc-8 snapshot
(2017/08/19) and the problem persists.

I managed to reduce my program to the following:

int a[8];

extern void f2();

void f() {
for (int i = 0x3F; i >= 0x10; --i) {
switch (i & 0xF0) {
case 0x00:
if ((i & 0x0F) < 8) a[i] = 0;
break;
case 0x10:
f2();
}
}
}

Compile with
g++ -O2 -Wall test.cpp

warning: array subscript is above array bounds [-Warray-bounds]

[Bug libstdc++/81263] Work around CWG issue 1558 (guarantee SFINAE when using `void_t`)

[webrown.cpp at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81263

W E Brown  changed:

   What|Removed |Added

 CC||webrown.cpp at gmail dot com

--- Comment #1 from W E Brown  ---
I have not confirmed the report but, as the originator of the void_t technique,
I do have a few comments:

a)  The cited CWG issue was resolved several years ago, and is in DR status. 
That means the exhibited code is expected to work.  If it doesn't, I consider
it a compiler issue, not a library issue.

b) Therefore, once the compiler is fixed (if necessary), ISTM there should be
no reason to use the cited alternative definition of void_t, which I first
discovered and disseminated as a temporary workaround only.  See my WG21 paper
N3911 and/or part 2 of my metaprogramming talk at CppCon 2014.

c)  FWIW, while it should work as exhibited in the report, the code does not
quite conform to the design of the detection idiom.  I prefer to write such a
2nd template parameter as a type parameter of the form
   class = void_t.

[Bug c++/81259] New: Class template deduction cannot work on Constructor without parameters in some cases

[webrown.cpp at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81259

Bug ID: 81259
   Summary: Class template deduction cannot work on Constructor
without parameters in some cases
   Product: gcc
   Version: 7.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kmp53 at sina dot com
CC: webrown.cpp at gmail dot com
  Target Milestone: ---
CC: webrown.cpp at gmail dot com

template
class C {
public:
  void fn(){}
};
int main(int argc,char*argv[]){
  C c;//OK
  C{}.fn();//OK
  C().fn();//cannot deduce template arguments for 'C' from ()
}

[Bug libstdc++/80796] New: std::make_xxx_searcher / std::search(iter, iter, searcher) is missing

[webrown.cpp at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80796

Bug ID: 80796
   Summary: std::make_xxx_searcher / std::search(iter, iter,
searcher) is missing
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: d25fe0be at outlook dot com
CC: webrown.cpp at gmail dot com
  Target Milestone: ---
CC: webrown.cpp at gmail dot com

I hesitate to submit this as a PR since they might simply have not been
implemented yet, as they're not listed in libstdc++/manual/status.html
explicitly.

The searchers are present, as stated in the status page.

The std::make_xxx_searcher / std::search is listed in P0220R1, the same paper
as the searchers ('Library Fundamentals V1 TS Components: Searchers').

FWIW, std::experimental::make_xxx_searcher / std::experimental::search (N3905)
are present, only the corresponding ones in std:: are missing,

[Bug c++/80649] New: value-initialization rather than default-initialization at some optimization levels

[webrown.cpp at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80649

Bug ID: 80649
   Summary: value-initialization rather than
default-initialization at some optimization levels
   Product: gcc
   Version: 6.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: john.duncan at oracle dot com
CC: webrown.cpp at gmail dot com
  Target Milestone: ---
CC: webrown.cpp at gmail dot com

This problem concerns a placement-new statement within a loop:

new (ptr.p) TestRecord;

In this case "new TestRecord" without any parentheses or braces should perform
default-initialization. My experience with gcc 6.3 shows default-initialization
at some -O levels, but apparent value-initialization at other levels. In the
example submitted here in the bug report, the problem appears at -O1 but not at
-O2. In the actual large codebase where I first observed the problem, it was
seen at -O2 but not at -O1.

[Bug libstdc++/78996] uses macro as name

[webrown.cpp at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78996

--- Comment #1 from W E Brown  ---
Created attachment 40465
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40465=edit
Preprocessed source

[Bug libstdc++/78996] New: uses macro as name

[webrown.cpp at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78996

Bug ID: 78996
   Summary:  uses macro as name
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: webrown.cpp at gmail dot com
  Target Milestone: ---

Upon upgrading to g++-mp-7 (MacPorts gcc7 7-20170101_0) 7.0.0 20170101
(experimental) and compiling with significant options -std=c++1z -fconcepts, I
find a previously-unseen conflict.

At line 607, header  employs the identifier __unused as the name of a
template parameter pack.

Unfortunately, before #including , my test program has already
#included , which on my system contains the line:

  #define __unused  __attribute__((unused))

This seems the source of the conflict that now produces diagnostics from the
unchanged test program that last month compiled cleanly.

Preprocessed source is attached.  Thank you.

[Bug c++/78955] New: [c++ concepts] Concept requirements on functions cancels the private section method check in the following code

[webrown.cpp at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78955

Bug ID: 78955
   Summary: [c++ concepts] Concept requirements on functions
cancels the private section method check in the
following code
   Product: gcc
   Version: c++-concepts
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sergstrukovlink at gmail dot com
CC: webrown.cpp at gmail dot com
  Target Milestone: ---
CC: webrown.cpp at gmail dot com

See the attached code example.

Checked on https://gcc.godbolt.org with gcc-6.2.0 , gcc-6.3.0 anf gcc-7.0.0.

Options: -std=c++1z -fconcepts .

[Bug c++/78473] New: Enhancement request: __builtin_div_overflow

[webrown.cpp at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78473

Bug ID: 78473
   Summary: Enhancement request:  __builtin_div_overflow
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: webrown.cpp at gmail dot com
  Target Milestone: ---

https://gcc.gnu.org/onlinedocs/gcc/Integer-Overflow-Builtins.html documents gcc
intrinsic functions to perform integer arithmetic with overflow checking. 
Addition, subtraction, and multiplication are supported, but division is not.

However, division can overflow, for any of at least three different reasons:

(1) For a signed 2s-complement integer type T, consider dividing the most
negative value by T(-1); the result can't be represented in T.

(2) There are also cases involving mixed types such that the quotient can't be
represented in the smaller type or in a too-small third type.

(3) There's also the always-delightful division by zero opportunity.

I am therefore writing to request that division be supported as a future
enhancement to current functionality.  Both the __builtin_*div_overflow and
__builtin_div_overflow_p forms would be useful, IMO.

It also seems useful to support a remainder operation in some manner, either as
a separate set of functions or perhaps via extra arguments to the division
functions.

Thanks very much.

[Bug c++/62181] [C/C++] Expected new warning: "adding 'char' to a string does not append to the string" [-Wstring-plus-int]

[webrown.cpp at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62181

Eric Gallager  changed:

   What|Removed |Added

 CC||egall at gwmail dot gwu.edu

W E Brown  changed:

   What|Removed |Added

 CC||webrown.cpp at gmail dot com

--- Comment #3 from Eric Gallager  ---
I think a better fixit would be to suggest using strcat or strncat or strlcat
or something, since that actually appends to the string like the programmer
probably intended to do. Abusing array indexing like that just looks wrong.

[Bug c++/70539] New: ICE on invalid code on x86_64-linux-gnu in cxx_incomplete_type_diagnostic, at cp/typeck2.c:569

[webrown.cpp at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70539

Bug ID: 70539
   Summary: ICE on invalid code on x86_64-linux-gnu in
cxx_incomplete_type_diagnostic, at cp/typeck2.c:569
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
CC: webrown.cpp at gmail dot com
  Target Milestone: ---
CC: webrown.cpp at gmail dot com

The following code causes an ICE when compiled with the current GCC trunk on
x86_64-linux-gnu in both 32-bit and 64-bit modes. 

It is a regression from 5.3.x. 


$ g++-trunk -v
Using built-in specs.
COLLECT_GCC=g++-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/6.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/usr/local/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 6.0.0 20160404 (experimental) [trunk revision 234712] (GCC) 
$ 
$ g++-5.3 -c small.cpp
small.cpp: In function ‘void foo()’:
small.cpp:4:8: error: ‘f’ does not name a type
   auto f = [&] { return f; };
^
$ 
$ g++-trunk -c small.cpp
small.cpp: In lambda function:
small.cpp:4:25: error: use of ‘f’ before deduction of ‘auto’
   auto f = [&] { return f; };
 ^
small.cpp:4:25: error: use of ‘foo()::<lambda()>::’ before deduction
of ‘auto’
small.cpp:4:28: internal compiler error: in cxx_incomplete_type_diagnostic, at
cp/typeck2.c:569
   auto f = [&] { return f; };
^
0x6ce8e3 cxx_incomplete_type_diagnostic(tree_node const*, tree_node const*,
diagnostic_t)
../../gcc-source-trunk/gcc/cp/typeck2.c:569
0x765f99 complete_type_or_maybe_complain(tree_node*, tree_node*, int)
../../gcc-source-trunk/gcc/cp/typeck.c:150
0x7c37fc apply_deduced_return_type(tree_node*, tree_node*)
../../gcc-source-trunk/gcc/cp/semantics.c:9226
0x7342a2 cp_parser_lambda_body
../../gcc-source-trunk/gcc/cp/parser.c:10256
0x7342a2 cp_parser_lambda_expression
../../gcc-source-trunk/gcc/cp/parser.c:9756
0x734c9c cp_parser_primary_expression
../../gcc-source-trunk/gcc/cp/parser.c:4933
0x736d26 cp_parser_postfix_expression
../../gcc-source-trunk/gcc/cp/parser.c:6690
0x73fe6c cp_parser_unary_expression
../../gcc-source-trunk/gcc/cp/parser.c:7988
0x7406c7 cp_parser_cast_expression
../../gcc-source-trunk/gcc/cp/parser.c:8665
0x740cc5 cp_parser_binary_expression
../../gcc-source-trunk/gcc/cp/parser.c:8767
0x7415b0 cp_parser_assignment_expression
../../gcc-source-trunk/gcc/cp/parser.c:9055
0x7419ea cp_parser_constant_expression
../../gcc-source-trunk/gcc/cp/parser.c:9323
0x742174 cp_parser_initializer_clause
../../gcc-source-trunk/gcc/cp/parser.c:20793
0x74391b cp_parser_initializer
../../gcc-source-trunk/gcc/cp/parser.c:20734
0x752bce cp_parser_init_declarator
../../gcc-source-trunk/gcc/cp/parser.c:18604
0x7532b0 cp_parser_simple_declaration
../../gcc-source-trunk/gcc/cp/parser.c:12379
0x7535c1 cp_parser_block_declaration
../../gcc-source-trunk/gcc/cp/parser.c:12248
0x754018 cp_parser_declaration_statement
../../gcc-source-trunk/gcc/cp/parser.c:11860
0x7326db cp_parser_statement
../../gcc-source-trunk/gcc/cp/parser.c:10528
0x732ffc cp_parser_statement_seq_opt
../../gcc-source-trunk/gcc/cp/parser.c:10806
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
$ 


--


void
foo ()
{
  auto f = [&] { return f; };
}

[Bug c++/69009] [5/6 Regression] ICE in instantiate_decl, at cp/pt.c:21511

[webrown.cpp at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69009

--- Comment #5 from W E Brown  ---
I have encountered this issue several more times since my original report, and
am writing to report a pattern I recently noticed among cases that ICE vs
similar cases that compile correctly.  (I'm now using MacPorts gcc6
6-20160110_0.)

The following two representative code samples are similar in structure. 
However, the first (is_floating_point_v<>) does compile for me, while the
second (is_pointer_v<>) gives the reported ICE "in instantiate_decl, at
cp/pt.c:21511":

  template< typename T >
  constexpr bool
is_unqual_floating_point_v = false;
  //
  template< >
  constexpr bool
is_unqual_floating_point_v = true;
  //
  template< >
  constexpr bool
is_unqual_floating_point_v = true;
  //
  template< >
  constexpr bool
is_unqual_floating_point_v<_ldbl> = true;

  template< typename T >
  constexpr bool
is_floating_point_v = is_unqual_floating_point_v< ::_tt::remove_cv_t >;

  // --

  template< typename T >
  constexpr bool
is_unqual_pointer_v = false;
  //
  template< typename U >
  constexpr bool
is_unqual_pointer_v = true;

  template< typename T >
  constexpr bool
is_pointer_v = is_unqual_pointer_v< ::_tt::remove_cv_t >;
   ^

Note that in one case, the is_unqual*<> helper employs complete specialization,
while the helper in the other case uses partial specialization.

I have found this observation to be a reliable discriminator between cases that
compile for me and those that ICE as reported; I hope it may be useful in
analyzing and resolving the issue.

[Bug libstdc++/53901] [C++11] [DR 2165] std::atomic fails for type without no-throw default constructor

[webrown.cpp at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53901

W E Brown  changed:

   What|Removed |Added

 CC||webrown.cpp at gmail dot com

--- Comment #4 from W E Brown  ---
LWG2165 (http://cplusplus.github.io/LWG/lwg-defects.html#2165) was resolved via
CWG1778 (http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1778).

[Bug libstdc++/51960] [DR 2127] Missing move-assignment operator in raw_storage_iterator

[webrown.cpp at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51960

W E Brown  changed:

   What|Removed |Added

 CC||webrown.cpp at gmail dot com

--- Comment #4 from W E Brown  ---
LWG2127 now has DR status: 
http://cplusplus.github.io/LWG/lwg-defects.html#2127

[Bug c++/950] [DR 203] Template problem: decay of pointer-to-member-of-derived to p-o-m-o-base

[webrown.cpp at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=950

W E Brown  changed:

   What|Removed |Added

 CC||webrown.cpp at gmail dot com

--- Comment #16 from W E Brown  ---
(In reply to Jason Merrill from comment #15)
> Actually, this is issue 203, so I'll suspend it instead of closing.
> 
> http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#203

Issue 203 has been resolved:

http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_closed.html#203

[Bug c++/12255] exception-specification ignored on pointer to function

[webrown.cpp at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12255

W E Brown  changed:

   What|Removed |Added

 CC||webrown.cpp at gmail dot com

--- Comment #7 from W E Brown  ---
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#92 was "Adopted at
the October, 2015 meeting as P0012R1."

[Bug c++/69009] New: ICE in instantiate_decl, at cp/pt.c:21511

[webrown.cpp at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69009

Bug ID: 69009
   Summary: ICE in instantiate_decl, at cp/pt.c:21511
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: webrown.cpp at gmail dot com
  Target Milestone: ---

Created attachment 37101
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37101=edit
Preprocessed source

Using g++-mp-6 (MacPorts gcc6 6-20151220_0) 6.0.0 20151220 (experimental)

compiling via
  g++-mp-6 -x c++ -std=c++1z -O3  (plus lots of -W flags)

Preprocessed source attached.

The problem manifested after revising my implementation of tuple_size and
tuple_size_v as outlined below:

template< class T >
constexpr auto
  tuple_size_v = 0;

...
// several tuple_size_v specializations later:

template< class T >
using
  tuple_size = integral_constant<size_t, tuple_size_v>;

[Bug c++/68164] Destructor side effect unexpectedly elided

[webrown.cpp at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68164

W E Brown  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #4 from W E Brown  ---
(In reply to Casey Carter from comment #3)
...
> The access to bp[i].data in the for loop inside the catch clause is the
> access to which I was referring.
...

Sorry, that hadn't been clear to me from the original response; I'd thought it
was discussing use of the this pointer.

I'm told that the original test program was earlier today adapted to avoid the
reported behavior.  I haven't yet tried the revised version, but am closing
this report.

[Bug c++/68164] Destructor side effect unexpectedly elided

[webrown.cpp at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68164

--- Comment #2 from W E Brown  ---
(In reply to Casey Carter from comment #1)
> [basic.life]/5 says:
> 
> Before the lifetime of an object has started ... or, after the lifetime of
> an object has ended and before the storage which the object occupied is
> reused or released, any pointer that refers to the storage location where
> the object will be or was located may be used but only in limited ways. ...
> Indirection through such a pointer is permitted but the resulting lvalue may
> only be used in limited ways, as described below. The program has undefined
> behavior if:
> 
> (5.1) — ...
> 
> (5.2) — the pointer is used to access a non-static data member or call a
> non-static member function of the object, or
> 
> ...
> 
> This looks like straight-forward violation of 5.2 resulting in UB.

By this reasoning, no c'tor or d'tor would be allowed, in its body, to access
any of its non-static data members or call any of its non-static member
functions.  There must be more to it, and indeed IMO there is.

According to the second sentence of [class.cdtor]/3:

"To ... access the value of ... a direct non-static member of an object obj,
the construction of obj shall have started and its destruction shall not have
completed, otherwise ... accessing the member value ... results in undefined
behavior."

Moreover, according to the first sentence of the next paragraph
([class.cdtor]/4), "Member functions, including virtual functions, can be
called during construction or destruction" [cross-references elided].

I conclude that the access in the test program's d'tor does not qualify as
undefined behavior and is therefore permissible.

Accordingly, I recommend further analysis of the original report.

[Bug c++/68164] New: Destructor side effect unexpectedly elided

[webrown.cpp at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68164

Bug ID: 68164
   Summary: Destructor side effect unexpectedly elided
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: webrown.cpp at gmail dot com
  Target Milestone: ---

Created attachment 36625
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36625=edit
Test program

Compiler version:  g++-mp-6 (MacPorts gcc6 6-20151025_0) 6.0.0 20151025
(experimental).

Compiling via:  g++-mp-6 -Og -std=c++1z

The enclosed test program improperly asserts because (it seems) that the
assignment in the body of B's destructor is elided.

The program does not assert, however, if I insert a debugging output statement
(marked #1) following the assignment.

Comment #1 out to see the unexpected failed assertion.  Repositioning #1 to
precede the assignment also results in a failed assertion.

[Bug c++/67324] New: Failures in Assignable concept's requires-expression

[webrown.cpp at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67324

Bug ID: 67324
   Summary: Failures in Assignable concept's requires-expression
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: webrown.cpp at gmail dot com
  Target Milestone: ---

Created attachment 36243
  -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=36243action=edit
Test for Assignable concept

Using g++-mp-6 (MacPorts gcc6 6-20150816_0) 6.0.0 20150816 (experimental), I
have been experimenting with the Assignable concept as defined in a very recent
draft of the Ranges proposal.  I am experiencing several kinds of failures,
demonstrable via the attached self-contained program.  I compile with options
-Og -std=c++1z plus a host of warning-enabling options.

Please note, in the Assignable concept definition, lines annotated #1 and #2. 
Line #1 corresponds to the draft's definition; line #2 is a variant formulation
of that definition.  There are no compilation diagnostics except as follows:

When line #1 is uncommented, all the affirmatively-phrased static_asserts fail.
 When line #2 is uncommented instead, only the last static_assert (involving
struct F) fires.

I believe none of these asserts should fail in either case.

When I remove the entire requires expression and replace it with a
corresponding expression using the detection idiom (per N4502), none of the
static_asserts fail.

I have consulted with both Eric Niebler and Andrew Sutton re these
observations; they agree this is unexpected behavior.  Eric commented that the
placeholder constraint in #1 is only partially implemented in gcc.  Andrew
commented, I wonder if there's not a deeper bug. I plugged something similar
into origin and it broke completely unrelated test cases.

At the moment, this is a complete show-stopper for me.

[Bug c++/67238] New: [C++11][C++14]cc1plus crash for nested decltype expression in parameter pack in trailing return type when '-g' enabled

[webrown.cpp at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67238

Bug ID: 67238
   Summary: [C++11][C++14]cc1plus crash for nested decltype
expression in parameter pack in trailing return type
when '-g' enabled
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: frankhb1989 at gmail dot com
CC: webrown.cpp at gmail dot com
  Target Milestone: ---
CC: webrown.cpp at gmail dot com

g++ -v
...
gcc version 5.2.0 (Rev3, Built by MSYS2 project)

Case:
//a.cc
templateclass F, class... A
void
g(F, A...)
{}

templateclass... A
auto
h(A... a) - decltype(g(0, gdecltype(a)(a)...))
{
return g([]{}, a...); // Crash if any error here.
}

int
main()
{
h();
}

g++ a.cc -std=c++11 -g1

The frontend crashes, and no diagnostics shown for this particular case on my
machine. Otherwise there may be segfault. Same for -std=c++14, but '-g0' seems
to be OK.

BTW, it seems that nested decltype expression in trailing return types are
often buggy playing with lambdas. Should there be any other reports?

[Bug c++/67070] [concepts] Concept with negation and disjunction not checked correctly

[webrown.cpp at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67070

--- Comment #4 from W E Brown webrown.cpp at gmail dot com ---
(In reply to Andrew Sutton from comment #2)
snip
 If we had a rule that allowed the evaluation of a concept in any
 context, then we could avoid doing this. It would also guarantee the
 ability to write;
 
static_assert(CT);
 
 This is probably a good issue to raise against the TS, and we should
 discuss it in Kona.

For the record, I'd proposed exactly this in section 4 (Concept evaluation
anywhere) of my WG21 paper N4434; it was briefly discussed in Lenexa, but
ultimately deemed premature.  I'd be pleased to see the issue reconsidered.

-- WEB

[Bug c++/66743] New: ICE on formerly working code

[webrown.cpp at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66743

Bug ID: 66743
   Summary: ICE on formerly working code
   Product: gcc
   Version: c++-concepts
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: webrown.cpp at gmail dot com
  Target Milestone: ---

This appears to be a recently introduced regression.  Although I'm using the
concepts branch, no concepts features are used to reproduce the problem.


Reduced test case:

template class T 
struct
  type_is { using type = T; };

template class T 
  using underlying_type = type_is__underlying_type(T);

int
  main( )
{
  return 0;
}


Compiler version:
concepts-g++ (GCC) 6.0.0 20150702 (experimental)


Command line (numerous -W options elided):
concepts-g++ -Og -std=c++1z ... filename


Diagnostic:

internal compiler error: tree check: expected record_type or union_type or
qual_union_type, have underlying_type in for_each_template_parm_r, at
cp/pt.c:8726

[Bug c++/66743] ICE on formerly working code

[webrown.cpp at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66743

--- Comment #1 from W E Brown webrown.cpp at gmail dot com ---
Further reduced test case:

template class T 
  using u_t = __underlying_type(T);

int  main( )  { }

[Bug libstdc++/41759] [C++0x] random static_assert phrasing should be positive

[webrown.cpp at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41759

--- Comment #6 from W E Brown webrown.cpp at gmail dot com ---
I hadn't realized this was still open :)

FWIW, my paper N3846
(http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3846.pdf) summarizes
on p. 3 my recommended guidelines for programmers to follow in crafting
diagnostic messages for users as follows:

• Provide explicit indication that something has gone wrong:
  – Users are lost when they make mistakes with no feedback.
  – Be specific in describing the exact problem;
avoid vague generalities or generic messages (e.g., syntax error).

• Use human-readable (i.e., comprehensible) language:
  – Avoid abbr’s and codes (e.g., type 2 error).
  – Use polite and grammatically correct phrasing.
  – Neither blame users nor imply they are stupid or doing something wrong 
(e.g., illegal command).
  – Be affirmative.

• Above all, be helpful; provide constructive advice:
  – Tell users how to address the problem.
  – Use error messages as an educational resource to impart a small amount 
of knowledge to users.

[To give due credit, I many years ago paraphrased, rearranged, and reformatted
these based in significant part on Jakob Nielsen's article “Error Message
Guidelines.” (Nielsen Norman Group, 2001-06-24. http://www.
nngroup.com/articles/error-message-guidelines/).]

[Bug c++/65553] New: ICE on valid variadic template

[webrown.cpp at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65553

Bug ID: 65553
   Summary: ICE on valid variadic template
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: webrown.cpp at gmail dot com

Created attachment 35134
  -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35134action=edit
program producing ICE

When compiling enclosed program via
  g++-mp-5 (MacPorts gcc5 5-20150308_0) 5.0.0 20150308 (experimental)
via command line
  g++-mp-5 -std=c++14 junk.cpp
the following messages obtain:

junk.cpp:10:38: internal compiler error: tree check: accessed elt 2 of tree_vec
with 1 elts in check_instantiated_args, at cp/pt.c:15822
 template typename... Args, bool B = F2Args... 
  ^
junk.cpp:10:38: internal compiler error: Abort trap: 6
g++-mp-5: internal compiler error: Abort trap: 6 (program cc1plus)

Thanks to Andrew Sutton for reducing the test case.

[Bug c++/65553] ICE on valid variadic template

[webrown.cpp at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65553

W E Brown webrown.cpp at gmail dot com changed:

   What|Removed |Added

 CC||andrew.n.sutton at gmail dot 
com

--- Comment #3 from W E Brown webrown.cpp at gmail dot com ---
Hmm.  Looks like this was fairly recently fixed.  After I updated from version
  g++-mp-5 (MacPorts gcc5 5-20150308_0) 5.0.0 20150308 (experimental)

to version
  g++-mp-5 (MacPorts gcc5 5-20150322_0) 5.0.0 20150322 (experimental)

the attachment now compiles successfully.

Thank you.

[Bug c++/59204] New: Incorrect metaprogram evaluation in SFINAE context

[webrown.cpp at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59204

Bug ID: 59204
   Summary: Incorrect metaprogram evaluation in SFINAE context
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: webrown.cpp at gmail dot com

Created attachment 31255
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31255action=edit
Demonstrating SFINAE failure to fail

Command:  g++-mp-4.9 -O3 -std=gnu++1y bug2.cc
Version: g++-mp-4.9 (MacPorts gcc49 4.9-20131110_0) 4.9.0 20131110
(experimental)

Attached program fails to compile because the 2nd static_assert incorrectly
leads to a diagnostic.

Used in a SFINAE context, it seems that the type expression
  void_ttypename T::type
always yields the type void.  This seems too aggressive an outcome; when T has
no T::type member, the expression should instead be treated as invalid, hence
its context rejected due to SFINAE.

[Bug c++/57682] New: Uniform initialization syntax rejected in function-try-block

[webrown.cpp at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57682

Bug ID: 57682
   Summary: Uniform initialization syntax rejected in
function-try-block
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: webrown.cpp at gmail dot com

Created attachment 30342
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30342action=edit
Source file demonstrating issue

Compiling via:
  g++-mp-4.9 -std=gnu++1y -c bug.cc 

Using version:
  g++-mp-4.9 (MacPorts gcc49 4.9-20130616_0) 4.9.0 20130616 (experimental)

Using paren's to initialize a data member will compile successfully, but using
braces in their place produces a diagnostic.  Define/undefine the OOPS macro in
the attachment to reproduce failure/success.

[Bug c++/56041] New: Constexpr conversion function definition not found in template argument context

[webrown.cpp at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56041



 Bug #: 56041

   Summary: Constexpr conversion function definition not found in

template argument context

Classification: Unclassified

   Product: gcc

   Version: 4.7.2

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: c++

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: webrown@gmail.com





Created attachment 29215

  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29215

C++11 metaprogramming experiment



Enclosed code fails to compile, but should.



Tested with:

  g++-mp-4.7 (MacPorts gcc47 4.7.2_2) 4.7.2

  g++-mp-4.8 (MacPorts gcc48 4.8-20130113_0) 4.8.0 20130113 (experimental)



Compiled via:

  g++-mp-4.7 -O3 -std=c++0x main.cc

  g++-mp-4.8 -O3 -std=c++0x main.cc



Use of expression true_type{} as template argument corresponding to bool

template parameter produces diagnostic:

  'constexpr integral_constantT, v::operator T() const [with T = bool; T v =

true]' used before its definition



[The syntax variant true_type() [note parentheses instead of braces as shown

above] is correctly diagnosed, applying 14.3/2.  This variant, as well as a

C++03-style variant, are present but commented out in the attachment; I left

them for possible additional experimentation.]



Using braces should force interpretation as an expression, not a type.  That

expression should result in a default-constructed temporary object of the named

type; that type, defined earlier in the source, has a conversion operator

defined inline.  However, the compiler claims that the operator's definition is

not yet defined at the point of (implicit) use.