Re: g++ extension for Concepts TS

[Nathan Ridge]

cc Andrew Sutton

From: gcc-ow...@gcc.gnu.org  on behalf of Christopher Di 
Bella 
Sent: April 2, 2017 8:57 AM
To: gcc Mailing List
Subject: g++ extension for Concepts TS

Hey all,

I've been working on a concept extension that permits type aliases
inside the requires-seq.
The grammar addition is fairly simple.

```
requirement-seq
   requirement
   alias-declaration
   requirement-seq requirement
```

Semantically, this change forces a requirement-body to open a new
scope to house the alias.

I've managed to get it working for variable concepts, but not function concepts.

It looks like type aliases for some concepts are tricking the compiler
into thinking that there are multiple statements.
For example:

```cpp
template 
concept bool Foo =
requires(T a) {
   using type = T;
   using value_type = typename std::vector::value_type;
   {a + a} -> value_type;
   {a - a} -> type;
   {a + a} -> typename std::vector::value_type;
   {a - a} -> T;
};
```
works, but

```cpp
template 
concept bool Foo() {
requires(T a) {
   using type = T;
   using value_type = typename std::vector::value_type;
   {a + a} -> value_type;
   {a - a} -> type;
   {a + a} -> typename std::vector::value_type;
   {a - a} -> T;
};
}
```
fails with

```
test.cpp: In function 'concept bool Foo()':
test.cpp:4:14: error: definition of concept 'concept bool Foo()' has
multiple statements
 concept bool Foo() {
  ^~~
test.cpp: In function 'int main()':
test.cpp:17:10: error: deduced initializer does not satisfy
placeholder constraints
  Foo i = 0;
  ^
test.cpp:17:10: note: in the expansion of concept '(Foo)()'
template concept bool Foo() [with T = int]
```

After some inspection, I've deduced that the issue is flagged in
constraint.cc:2527, where a DECL_EXPR is identified, instead of a
RETURN_EXPR.
I'm wondering if it's trivially possible to ignore these declarations?
E.g. a loop that somewhat resembles:

```cpp
while (body != TREE_NULL && TREE_CODE(STATEMENT_LIST_HEAD(body)) ==
DECL_EXPR && is also an alias declaration)
   body = STATEMENT_LIST_TAIL(body);
if (body != TREE_NULL)
  error...
// else cleared of all charges
```

Cheers,

Chris

RE: Named parameters

[Nathan Ridge]

Note that a proposal for named arguments was recently presented to the C++ 
standards committee [1], and they did not seem receptive to it [2].

The proposal was for a different syntax (name : value), but the objections were 
not related to the syntax.

Regards,
Nate

[1] http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4172.htm
[2] 
http://theres-waldo.ca/2014/11/23/trip-report-c-standards-meeting-in-urbana-champaign-november-2014/
 (see list of rejected proposals in section Evolution Working Group)
  

RE: [boost] lots of warning with gcc-4.8.1 + boost-1.54.0

[Nathan Ridge]

 On 3 July 2013 02:41, Nathan Ridge wrote:
 Lots of warnings like this:

 ./boost/bind/arg.hpp:37:22: warning: typedef ‘T_must_be_placeholder’ locally
 defined but not used [-Wunused-local-typedefs]

 when building 1.54.0 with gcc-4.8.1 (fedora f19)

 This warning is new in GCC 4.8, and I have been seeing a ton of them
 not just in boost, but in every codebase I've built.

 It was new in GCC 4.7, http://gcc.gnu.org/gcc-4.7/changes.html

I stand corrected. (What's new in 4.8 is it being included in -Wall,
which is why I never noticed it in 4.7).

 It affects Boost more than most code because of the prevalent use of
 concept checks and static assertions which are usually implemented
 using typedefs but only conditionally compiled.

I've seen spews of that warning for other large projects, such as
clang or wxWidgets, not just boost.

Would GCC consider removing it from -Wall?

 CC'ing the gcc folks.

 That's not very helpful because posting to the Boost list is
 subscription only (you'll have two copies of this mail, because the
 first one I sent from an address subscribed to the GCC list but not
 this one.)

My apologies.

Regards,
Nate  

PR 50025 (uniform initialization of class member of reference type)

[Nathan Ridge]

Hi,

I'm just wondering, is there any chance of fixing PR 50025 [1] soon?
It concerns uniform initialization of a class member of reference
type.

I have been using GCC to do C++11 development for a while now, and
this one bug has been a bit of an eyesore IMO, that has been
keeping the uniform out of uniform initialization.

I think a lot of people would be happy to see thix fixed!

Thanks,
Nate

[1] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50025   
  

RE: [boost] lots of warning with gcc-4.8.1 + boost-1.54.0

[Nathan Ridge]

 Lots of warnings like this:

 ./boost/bind/arg.hpp:37:22: warning: typedef ‘T_must_be_placeholder’ locally
 defined but not used [-Wunused-local-typedefs]

 when building 1.54.0 with gcc-4.8.1 (fedora f19)

This warning is new in GCC 4.8, and I have been seeing a ton of them
not just in boost, but in every codebase I've built.

IMO gcc should not have this warning turned on by default.

CC'ing the gcc folks.

Regards,
Nate  

RE: std::count leaked outside namespace std?

[Nathan Ridge]

 Here's a simple program:

 #include algorithm
 #include vector

 int main()
 {
 std::vectorint vec;
 count(vec.begin(), vec.end(), 0); // shouldn't this be std::count ?
 }

 The above compiles successfully, but I think it shouldn't. I expect a
 message like error: `count` not declared in scope because I meant to
 say std::count. Isn't this a bug, or am I missing something?

It is not a bug. std::count is being found by argument-dependent lookup [1].

Regards,
Nate

[1] http://en.wikipedia.org/wiki/Argument-dependent_name_lookup 
  

RE: Could we start accepting rich-text postings on the gcc lists?

[Nathan Ridge]

  Similarly for text-only vs. rich text. You may argue that there's no
  compatibility issue, but I disagree. As was pointed out upthread, when
  people use rich text, they often start to use colors or other mechanisms
  to express themselves, which can now be dependent on the rendering agent
  used to read the email. Requiring people to express themselves using only
  words seems to me to encourage the sorts of discipline that we require in
  contributors.

 We disagree on this point, then. While rich-text can be abused, it is
 not my experience that people do abuse it to the point of making their
 postings illegible. The markings you see commonly used are monospace
 font alterations, bolding and lists. I have noticed no correlation
 between the ability to use a markup language and quality of
 contributions.

I am regular reader of several mailing lists, some of which (such as this 
one) require plain text, and some (like cdt-dev) which allow rich text.

My experience has been that the formatting of messages on plain-text
lists is consistent across the board, while on rich-text lists you get a
mess by mixing together different formatting conventions. A prominent
example is the formatting convention used for quoting the message you're
replying to. Plain-text lists always use one convention: greater-than
signs () before each line of the quote, one for each level of quoting.
On rich-text lists, some messages use greater-than signs, some use a 
vertical line to the left of the text, some use a different color, etc.
The result is a mess that's difficult to follow.

I think rich-text works well when everyone uses the same mail client.
For example, at a company I used to work, for everyone used Microsoft
Outlook as their mail client, and emails were sent in rich text. There
was no readability problem there because everyone used the same 
formatting conventions.

However, requiring that everyone that posts to a public mailing list
use the same mail client is even more restrictive than requiring that
they use plain text. The only other way to ensure consistency of
formatting conventions is to use the lowest common denominator between
mail clients, which is plain text.

Regards,
Nate
  

C++11 no longer experimental

[Nathan Ridge]

Hello,

Now that the C++11 standard has been officially voted in, there is nothing
 experimental about it any more.

Would it be possible to remove the warning about GCC's C++11 support
being experimental from http://gcc.gnu.org/projects/cxx0x.html, and
to modify the __GXX_EXPERIMENTAL_CXX0X__ macro to be just
__GXX_CXX0X__ (or even better, __GXX_CXX11__)?

Thanks,
Nate
  

new C++11 features in GCC 4.7

[Nathan Ridge]

Hi,

I'm wondering, are there are other new C++11 features planned
for GCC 4.7 besides Extended friend declarations and Explicit 
virtual overrides (which are marked as already implemented at
http://gcc.gnu.org/projects/cxx0x.html)?

Thanks,
Nate
  

Re: Tracing C++ template instantiations‏

[Nathan Ridge]

 On 06/09/2011 03:48 PM, Jonathan Wakely wrote:

 When I'm working on complicated template code and debugging a mixture
 of bugs in my templates and ICEs in g++ caused by my buggy templates I
 sometimes wish I could see a dump of all the templates that the
 compiler is instantiating, so I can see at which point in a
 deeply-nested instantiation things don't happen the way I expected
 them to. With variadic templates in particular it's sometimes hard to
 visualize what's happening to your code.
 
 Someone else asked for this the other day on gcc-help
 (http://gcc.gnu.org/ml/gcc-help/2011-06/msg00193.html) so I thought
 I'd take a look at implementing it. It turns out that or class
 templates all that's needed is something like:
 verbatim (instantiating class template %qT, type)
 in instantiate_class_template_1 in gcc/cp/pt.c
 Presumably it wouldn't be much harder to do the same for function templates.
 
 Is there something that does this already that I've missed? If I were
 to add a switch like -ftrace-template-instantiation to control this,
 is there any chance of getting it accepted?
 
 It might be useful if the trace said something like:
 attempting to instantiate foobar...
 attempting to instantiate foobar::bazint ...
 successfully instantiated foobar::bazint
 failed to instantiate foobar
 with nesting to see which instantiations depend on others and to see
 which pass/fail, but I've already found it useful just to see a list
 of instantiations, in order to verify whether some refactoring reduces
 the number of instantiations.
 
 Would anyone else find this useful, or should I just keep it in my own
 source tree for my own use?

+1 for this feature. I would find it very useful too!

Regards,
Nate. 

gcc interprets C++0x initialization construct as function declaration

[Nathan Ridge]

Hello,

For the following code:

struct S
{
int a;
float b;
};
struct T
{
T(S s) {}
};
int main()
{
T t(S{1, 0.1}); // ERROR HERE
}

gcc 4.6 trunk gives the following errors (with the --std=c++0x option):

decl.cpp: In function 'int main()':
decl.cpp:14:10: error: expected ')' before '{' token
decl.cpp:14:10: error: a function-definition is not allowed here before '{' 
token
decl.cpp:14:18: error: expected primary-expression before ')' token
decl.cpp:14:18: error: expected ';' before ')' token

It seems gcc is interpreting the statement as a function declaration.

Is this the desired behaviour?

Regards,
Nate. 

internal compiler error in gcc trunk when using std::map

[Nathan Ridge]

Hello,
 
I've just build the gcc trunk and tried to compile some code that compiled fine 
with gcc 4.5.
It gave an internal compiler error.
I've reduced it to the following minimal test case:
 
#include string
#include map
int main()
{
std::mapstd::string, int m;
std::pairstd::string, int p;
m.insert(p);
return 0;
}
 
Here's the command used to compile:
 
g++-4.6 --std=c++0x test.cpp
 
Here's the output:
 
In file included from 
/usr/local/lib/gcc/i686-pc-linux-gnu/4.6.0/../../../../include/c++/4.6.0/bits/stl_algobase.h:65:0,
 from 
/usr/local/lib/gcc/i686-pc-linux-gnu/4.6.0/../../../../include/c++/4.6.0/bits/char_traits.h:41,
 from 
/usr/local/lib/gcc/i686-pc-linux-gnu/4.6.0/../../../../include/c++/4.6.0/string:42,
 from ice.cpp:1:
/usr/local/lib/gcc/i686-pc-linux-gnu/4.6.0/../../../../include/c++/4.6.0/bits/stl_pair.h:
 In constructor âconstexpr std::pair_T1, _T2::pair(const std::pair_U1, 
_U2) [with _U1 = std::basic_stringchar, _U2 = int, _T1 = const 
std::basic_stringchar, _T2 = int]â:
/usr/local/lib/gcc/i686-pc-linux-gnu/4.6.0/../../../../include/c++/4.6.0/type_traits:780:68:
   instantiated from âconst bool 
std::__is_convertible_helperstd::pairstd::basic_stringchar, int, 
std::pairconst std::basic_stringchar, int, false::__valueâ
/usr/local/lib/gcc/i686-pc-linux-gnu/4.6.0/../../../../include/c++/4.6.0/type_traits:787:12:
   instantiated from âstd::is_convertiblestd::pairstd::basic_stringchar, 
int, std::pairconst std::basic_stringchar, int â
test.cpp:8:15:   instantiated from here
/usr/local/lib/gcc/i686-pc-linux-gnu/4.6.0/../../../../include/c++/4.6.0/bits/stl_pair.h:107:43:
 internal compiler error: in build_data_member_initialization, at 
cp/semantics.c:5502
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
 
And here's the output of g++-4.6 -v:
 
Using built-in specs.
COLLECT_GCC=g++-4.6
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/i686-pc-linux-gnu/4.6.0/lto-wrapper
Target: i686-pc-linux-gnu
Configured with: ../src/configure --program-suffix=-4.6 --enable-languages=c,c++
Thread model: posix
gcc version 4.6.0 20101209 (experimental) (GCC)
 
Thanks,
Nate.
  

g++ segfault when using C++0x feature‏

[Nathan Ridge]

Hello,

The attached minimal code (test.cpp) causes g++ to 
segfault. It uses the C++0x features variadic templates and initializer 
lists.

The command used to compile it is:

g++ -std=c++0x test.cpp

The output is:

test.cpp: In function ‘void f(const Args ...) [with Args = ]’:
test.cpp:21:   instantiated from here
test.cpp:16: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See file:///usr/share/doc/gcc-4.4/README.Bugs for instructions.

The output of g++ -v is:

Using built-in specs.
Target: i486-linux-gnu
Configured
 with: ../src/configure -v --with-pkgversion='Ubuntu 4.4.1-4ubuntu9' 
--with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs 
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr 
--enable-shared --enable-multiarch --enable-linker-build-id 
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext 
--enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.4 
--program-suffix=-4.4 --enable-nls --enable-clocale=gnu 
--enable-libstdcxx-debug --enable-objc-gc --enable-targets=all 
--disable-werror --with-arch-32=i486 --with-tune=generic 
--enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu 
--target=i486-linux-gnu
Thread model: posix
gcc version 4.4.1 (Ubuntu 4.4.1-4ubuntu9) 

I also attached the preprocessed source file, as requested (test.ii when 
compiling using -save-temps).

Please let me know if you need any more information.

Regards,
Nate. #include initializer_list

template typename T
class my_vector
{
public:
my_vector(std::initializer_listT l);

template typename InputIterator
my_vector(InputIterator first, InputIterator last); 
};

template typename... Args
void f(const Args... args)
{
my_vectorint commands{args...};
}

int main(int argc, const char** argv)
{
f();
}


test.ii
Description: Binary data

missing return statement

[Nathan Ridge]

Hello,
 
So many times I write code like this:
 
SomeType function()
{
SomeType result;
// do something with result
return result;
}
 
except I often forget the return result statement.
 
Why does gcc not give an error about this?
If I compile with -Wall, it will give a WARNING saying
control reaches end of non-void function.
 
However, shouldn't it be an ERROR to return nothing
from a function that's supposed to return something?
Does this not result in undefined behaviour? Why goes gcc allow it?
 
Thanks,
Nate.
_
Share photos with friends on Windows Live Messenger
http://go.microsoft.com/?linkid=9650734

RE: missing return statement

[Nathan Ridge]

 On Thu, Mar 12, 2009 at 4:56 PM, Robert Dewar wrote:
 Nathan Ridge wrote:

 Why does gcc not give an error about this?
 If I compile with -Wall, it will give a WARNING saying
 control reaches end of non-void function.
 However, shouldn't it be an ERROR to return nothing
 from a function that's supposed to return something?
 Does this not result in undefined behaviour? Why goes gcc allow it?

 Because the standard does not make this an error, you can't tell
 if anyone needs a result, perhaps function is always called in
 a void environment.

 A warning is all you can get, always pay attention to warnings!

 The standard does make it an error, in that if such a function
 (meaning a function that unconditionally falls off the end, when
 declared to return a value) is called _at all_ then undefined behavior
 results. More general cases can't be established at compile time, of
 course.

 To be conservative, a compiler would issue the error only at the call
 site, with possibly a warning (as gcc does) for the definition.

 -- James

I get no error when I compile the following code, even though a call to the 
function does take place:
 
class A {};
A function()
{
A result;
}
int main()
{
function();
return 0;
}

Regards,
Nate.
_
Share photos with friends on Windows Live Messenger
http://go.microsoft.com/?linkid=9650734