Gerald,
Could I get a hand on checking in this last addition?
-m 'Add a blurb to htdocs/gcc-5/changes.html to explain the
__has_cpp_attribute and
the equivalent __has_attribute macros.'
Thanks,
Ed
Sorry, I forgot to add gcc-patches.
Index: htdocs/gcc-5/changes.html
On 01/25/2015 05:04 PM, Gerald Pfeifer wrote:
Hi Ed,
On Friday 2015-01-02 13:59, Ed Smith-Rowland wrote:
I would like peoples opinion of adding another column to the tables
indicating C++ feature status for C++11 and C++14 that contains the
relevant SD-6 feature macro.
Sure, that makes sense
OK,
Here is a new try at PR c++/64626 - C++14 single quote should not always
be a digit separator.
I decided to look for multiple terminating single quotes.
The test cases have bee adjusted and debugged.
Built and tested on x86_64-linux.
Ed
libcpp/
2015-03-16 Edward Smith-Rowland
On 03/08/2015 02:52 PM, Jakub Jelinek wrote:
On Sun, Mar 08, 2015 at 02:33:03PM -0400, Ed Smith-Rowland wrote:
I just look to see if a lexed number in libcpp ends in a '.
If so, back up one character and let string processing handle it.
I get one warning and one error for each instance but I'd
Forget this last patch.
The syntax of my dg lines was wrong and I'm seeing errors I'm not sure I
like.
I need to look at this further.
I'm sorry for the noise.
I just look to see if a lexed number in libcpp ends in a '.
If so, back up one character and let string processing handle it.
I get one warning and one error for each instance but I'd rather not
error when it should pass.
Built and tests clean on x86_64-linux.
OK?
libcpp/
2015-03-09
This has been in me tree for a good while.
It is fairly simple and adds C++ experimental container erasure.
Builds and tests cleanly on x86_64-linux.
OK?
Index: include/Makefile.am
===
--- include/Makefile.am (revision 222573)
And make_array, which isn't in the working paper yet, so I'd prefer to
leave that part out for now.
D'oh! Sorry about that.. Removed.
The Doxygen @headername command tells users which header they are
supposed to include, rather than this one. Since there is no
erase_if header that's wrong.
On 05/01/2015 05:01 PM, Jonathan Wakely wrote:
On 01/05/15 16:37 +0300, Ville Voutilainen wrote:
Tested on Linux-x64.
Implement observer_ptr.
Thanks! Committed with some minor formatting changes.
I've also committed this to add feature-test macros and update the
docs. Tested
On 05/02/2015 05:42 AM, Jonathan Wakely wrote:
On 02/05/15 10:40 +0100, Jonathan Wakely wrote:
On 01/05/15 22:02 -0400, Ed Smith-Rowland wrote:
On 05/01/2015 05:01 PM, Jonathan Wakely wrote:
On 01/05/15 16:37 +0300, Ville Voutilainen wrote:
Tested on Linux-x64.
Implement observer_ptr
This extends' static assert to not require a message string.
I elected to make this work also for C++11 and C++14 and warn only with
-pedantic.
I think many people just write
static_assert(thing, );
.
I took the path of building an empty string in the parser in this case.
I wasn't sure if
On 04/30/2015 02:01 PM, Daniel Krügler wrote:
Shouldn't the one-liner forwarding function templates be declared as
inline? - Daniel
You are right.
This builds and tests clean on x86_64-linux.
OK?
2015-05-01 Edward Smith-Rowland 3dw...@verizon.net
Inline one-line erasure dispatch
On 05/07/2015 09:59 AM, Marek Polacek wrote:
On Wed, May 06, 2015 at 11:17:20PM -0400, Ed Smith-Rowland wrote:
In addition to a PR this is 1/2 of a C=+17 feature. (The other half - really
a separate thing - is attributes on namespaces).
Ah, nice, I wasn't aware. For the record, this is
http
In addition to a PR this is 1/2 of a C=+17 feature. (The other half -
really a separate thing - is attributes on namespaces).
I wonder if we should pedwarn for C++17?
Or it could be just an extension for C++17 - I guess that would match
with clang.
if (SCOPED_ENUM_P (newtag))
diff
On 05/02/2015 04:16 PM, Ed Smith-Rowland wrote:
This extends' static assert to not require a message string.
I elected to make this work also for C++11 and C++14 and warn only
with -pedantic.
I think many people just write
static_assert(thing, );
.
I took the path of building an empty
I accidentally added an extra column to the C++14 language stats by
duplicating a column for the SD-6 feature test macros.
This one-liner fixes it.
I'll need someone to apply this...
Sorry.
Ed
? class_key.txt
? help
? patch
? patch_cxx14
? patch_cxx14_2
? patch_cxx14_3
? patch_cxx1y
?
On 06/17/2015 03:22 PM, Jason Merrill wrote:
On 06/17/2015 01:53 PM, Ed Smith-Rowland wrote:
I tried the obvious: an error message with %qE and got 'false'.
constexpr values are evaluated early on.
Is there a possibility that late folding could help or is that
completely different?
Late
On 06/17/2015 10:23 AM, Jason Merrill wrote:
On 06/15/2015 07:14 PM, Ed Smith-Rowland wrote:
I wanted to fix it up as per your suggestion. If someone wants it now I
can retest and commit. Otherwise give me a bit more time.
Someone in LWG was asking about it, and I figured it wouldn't hurt
On 06/15/2015 12:05 PM, Jason Merrill wrote:
On 05/20/2015 11:28 AM, Jason Merrill wrote:
On 05/02/2015 04:16 PM, Ed Smith-Rowland wrote:
This extends' static assert to not require a message string.
I elected to make this work also for C++11 and C++14 and warn only with
-pedantic.
I think many
I apologize to all who got this earlier.
I forgot to send to the list.
This patch adds UTF-8 character literals to C++:
auto c = u8'c';
This is mostly a straight forward preprocessor exercise.
I only allow these characters in -std=c++1z and -std=gnu++1z.
I figure we can expand that easily
On 05/22/2015 06:19 PM, Mikhail Maltsev wrote:
On 22.05.2015 12:10, Marek Polacek wrote:
Thanks, applied. Here's the final version.
By the way, we have a feature test macro, __cpp_attributes=200809 which
can be used to determine, whether C++11 attribute syntax is supported by
the compiler.
I
Greetings,
Now that most systems have uchar.h for conversion between char16_t* and
char32_t* to multibyte (analogue of wchar.h and cwchar) i think we
should check off this last little crumb of C++11.
I submitted this a while back but Jonathan suggested improvements and it
took me a hot
Jason,
My reading of
1.5 Feature-testing recommendations (Informative)
/2 ... The recommended macro name is __cpp_experimental_ followed by the
string in the “Macro
name suffix” column in Table 1. ...
Says change __cpp_concepts to __cpp_experimental_concepts
Cool beans on getting this in.
On 08/13/2015 10:51 AM, Jonathan Wakely wrote:
On 13/08/15 10:37 -0400, Ed Smith-Rowland wrote:
Greetings,
Now that most systems have uchar.h for conversion between char16_t*
and char32_t* to multibyte (analogue of wchar.h and cwchar) i think
we should check off this last little crumb of C
OK.
This tested clean because it didn't install the headers.
So Jonathan. I am going to throw in the sponge on the configury.
Could you have a look and carry this over the finish line?
Ed
On 10/24/2015 11:38 PM, Jonathan Wakely wrote:
On 8 May 2015 at 15:05, Ed Smith-Rowland <3dw...@verizon.net> wrote:
On 05/07/2015 12:06 PM, Jonathan Wakely wrote:
Hi Ed,
The C++ committee is considering the
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4437.pdf
proposal to
On 11/13/2015 10:32 AM, Jonathan Wakely wrote:
On 25 October 2015 at 20:48, Jonathan Wakely <jwakely@gmail.com> wrote:
On 25 October 2015 at 17:46, Ed Smith-Rowland <3dw...@verizon.net> wrote:
On 10/24/2015 11:38 PM, Jonathan Wakely wrote:
On 8 May 2015 at 15:05, Ed Smith-
On 11/16/2015 07:28 PM, Florian Goth wrote:
Hi all,
just a quick note that I'm still around...
Any particular pointers how I can help in improving the implementation?
Cheers,
Florian.
Gesendet: Samstag, 14. November 2015 um 21:40 Uhr
Von: "Ed Smith-Rowland" <3dw...@verizon.net&g
I think we should change the language in the c++0x_warning.h:
Index: include/bits/c++0x_warning.h
===
--- include/bits/c++0x_warning.h(revision 231922)
+++ include/bits/c++0x_warning.h(working copy)
@@ -29,9 +29,9 @@
branch is for development of TR29124 Special math Functions,
> for the C++ runtime library
> See href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3060.pdf;>
> . It is maintained by Ed Smith-Rowland
> mailto:3dw...@verizon.net;>3dw...@verizon.net.
>
On 12/27/2015 11:30 AM, Jonathan Wakely wrote:
I think we should change the language in the c++0x_warning.h:
Agreed, OK for trunk and gcc-5-branch, thanks.
N.B. s/Ramove/Remove/ in the changelog.
Done,
Here are the patch and CL as applied to trunk and gcc-5.
Thanks,
Ed
Index:
On 03/10/2016 03:48 AM, Jakub Jelinek wrote:
On Thu, Mar 10, 2016 at 03:44:26AM -0500, Ed Smith-Rowland wrote:
Here is a small patch to allow the special maths functions that came in with
TR29124 into C++17 in Jacksonville.
I am leaving the TR29124 access with __STDCPP_WANT_MATH_SPEC_FUNCS__
Here is a small patch to allow the special maths functions that came in
with TR29124 into C++17 in Jacksonville.
I am leaving the TR29124 access with __STDCPP_WANT_MATH_SPEC_FUNCS__ for
C++ < 17.
I added the SD-6 feature macro:
#define __cpp_lib_math_special_functions 20163L
Passes testing on
On 03/10/2016 05:24 AM, Tobias Burnus wrote:
Ed Smith-Rowland wrote:
--- include/bits/specfun.h
(svn+ssh://e...@gcc.gnu.org/svn/gcc/trunk/libstdc++-v3/include) (working copy)
+++ svn+ssh://e...@gcc.gnu.org/svn/gcc/trunk/libstdc++-v3/include
(revision 234098)
@@ -1,6 +1,6
On 03/11/2016 10:55 AM, Jonathan Wakely wrote:
The change approved in Jacksonville was to only add the special
functions to and not
That's easy.
OK, since they changed that and the macro and made it nonconditional I
should also drop the old-style macros __WANT_MATH_CANNEVERREMEMBER__ and
I wanted to ship the TR29124 special math functions in libstdc++ with
some documentation.
More could be done but this covers the function definitions, argument
ranges, template parms, and arguments.
There is a little mainpage with some overview, history, biblio, and links.
2016-04-08 Edward
Since the default is C++14 it seems apropos to *not* treat that C++
version thusly in the warning in libstdc++.
Ed
OK for trunk? And maybe some 6 branch later?
2016-04-17 Edward Smith-Rowland <3dw...@verizon.net>
* include/bits/c++14_warning.h: Do not refer C++14 as experimental.
Here is an implementation of P0025
An algorithm to "clamp" a value between a pair of boundary values.
Testing is almost finished - looks good so far.
OK if testing passes?
I didn't see a feature test in any of the SD-6 papers or P0025.
2016-07-15 Edward Smith-Rowland <3dw...@verizon.net>
This patch defines
operator""zu(unsigned long long __n)
for size_t literals.
for (auto k = 0zul; k < v.size(); ++k)
...
Testing on x86-64-linux is finishing but I'm past these tests.
OK?
Ed
2016-07-21 Edward Smith-Rowland <3dw...@verizon.net>
Implement C++17 P0330
OK for trunk, thanks.
I didn't see a feature test in any of the SD-6 papers or P0025.
p0096r3 proposes __cpp_lib_clamp = 201603.
I added the feature macro and committed the attached as 238383.
Thanks,
Ed
2016-07-15 Edward Smith-Rowland <3dw...@verizon.net>
Implement C++17
I saw this during bootstrap. I've verified that the patch works (I was
working on similar).
Ed
I am still having problems doing a full build.
I get stuck on something that I think can't be a concepts problem in
gcc/config/i386/i386.c:
make[3]: Entering directory `/home/ed/obj_concepts/gcc'
/home/ed/obj_concepts/./prev-gcc/xg++
-B/home/ed/obj_concepts/./prev-gcc/
I'm not sure the warning is correct in any case...
In i386.h
struct stringop_algs
{
const enum stringop_alg unknown_size;
const struct stringop_strategy {
const int max;
const enum stringop_alg alg;
int noalign;
} size [MAX_STRINGOP_ALGS];
};
in i386.c
---
On 06/24/14, Andrew Sutton wrote:
Weird. Any chance you're doing a bootstrap build?
There was an earlier bootstrapping issue with this branch. We had
turned on -std=c++1y by default, and it was causing some conversion
errors with lvalue references to bitfields in libasan.
This doesn't
On 06/25/2014 10:03 AM, Andrew Sutton wrote:
I did a full 3-stage bootstrap which is the default these days.
I'll try --disable-bootstrap and see what happens.
I just did a full bootstrap build and got the same errors. The errors
are correct for C++11, which was enabled by default in this
So is C++14 a done deal with a __cplusplus date and all?
I've been waiting for some news or a trip report from Rapperswil and
have seen nothing on isocpp.
I've been thinking of adding a thing or two to C++1z like clang has -
The Disabling trigraph expansion by default looks easy.
Ed
On 06/26/2014 11:28 PM, Jason Merrill wrote:
On 06/26/2014 09:38 PM, Ed Smith-Rowland wrote:
So is C++14 a done deal with a __cplusplus date and all?
The C++14 draft was finalized at the February meeting in Issaquah; the
ratification process isn't quite done, but I haven't heard any reason
On 06/27/2014 05:39 PM, paolo.carlini at oracle dot com wrote:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60249
--- Comment #5 from Paolo Carlini paolo.carlini at oracle dot com ---
Patch looks *great*. If it works, please send it to mailing list ASAP.
I think I finally got these weird
).
Built and tested clean on x86_64-linux.
OK?
I would also like to apply this to 4.9.
Ed Smith-Rowland
cp/
2014-06-28 Edward Smith-Rowland 3dw...@verizon.net
PR c++/58781
PR c++/60249
PR c++/59867
* parser.c (cp_parser_userdef_string_literal()): Take a tree
Support operator (...) per CWG 1473.
I'll be AFK over the holiday.
Bootstrapped and tested on x86_64-linux.
OK?
I'm less sure if this is appropriate for 4.9.
Index: cp/parser.c
===
--- cp/parser.c (revision 212248)
+++
This patch addresses an old issue of warning about macro touching string
literal even if the code is skipped:
#define BAZ baz
#if 0
barBAZ
#endif
Just skip the warning Wliteral-suffix if the preprocessor is skipping.
Built and tested on x86_64-linux.
OK?
And for 4.9?
Thanks,
Ed Smith
The title says it all.
I've been bootstrapping and testing with this on x86_64-linux for a month.
OK?
Ed
2014-07-10 Edward Smith-Rowland 3dw...@verizon.net
Add the logistic_distribution as an extension.
* include/ext/random: Add the logistic_distribution.
*
Here are some C++ versioning changes reflecting C++14 status and adding
c++1z. It is a followup to Jason's patch on 2014-06-26 adding std=c++1z,
etc.
This will allow us to start making C++1z changes to the preprocessor
(n3981 remove trigraphs).
In fact, I made trigraphs opt-in for both
Here is a preprocessor patch to make error messages show C++11 and other
relevant C++ language instead of C99.
Built and tested on x86_64-linux.
OK?
libcpp/
2014-07-09 Edward Smith-Rowland 3dw...@verizon.net
PR CPP/61389
* macro.c (_cpp_arguments_ok, parse_params,
Index: gcc/testsuite/g++.dg/cpp1y/digit-sep-neg.C
===
--- gcc/testsuite/g++.dg/cpp1y/digit-sep-neg.C(revision 212440)
+++ gcc/testsuite/g++.dg/cpp1y/digit-sep-neg.C(working copy)
@@ -7,7 +7,7 @@
i = 1048''576; // {
On 07/10/2014 06:16 AM, Paolo Carlini wrote:
.. I have another comment: are we sure the usual strategy:
templatetypename _UniformRandomNumberGenerator
result_type
operator()(_UniformRandomNumberGenerator __urng)
{ return this-operator()(__urng, this-_M_param); }
doesn't make
On 07/11/2014 11:42 AM, Paolo Carlini wrote:
Hi,
On 07/11/2014 05:38 PM, Ed Smith-Rowland wrote:
OK?
Ok, thanks, but please adjust the dates you have on the testcases to
the date of the actual commit (I suppose today or tomorrow)
Thanks again!
Paolo.
As committed.
Thanks all for looking
PING!
Support operator (...) per CWG 1473.
This brings full string parsing to literal operator declarations including
string chunk concatenation and appropriate errors.
Bootstrapped and tested on x86_64-linux.
OK?
I'm less sure if this is appropriate for 4.9 even when it opens.
cp/
Greetings,
This old bug involved C++98 accepting hex floats without complaint.
I also split the error messages between C and C++ like in the recent PR
61389 patch.
Bootstrapped and tested clean on x86_64-linux.
OK?
libcpp/
2014-07-12 Edward Smith-Rowland 3dw...@verizon.net
PR
are these dummy implementations intended?
Yes. There is no state. The only parameter is the dimensionality
which is a template parameter.
We do often serialize underlying helper distributions, in your case the
normal distribution _M_n.
While the normal distribution mean and stddev are
On 07/13/2014 10:11 AM, Ulrich Drepper wrote:
On Sun, Jul 13, 2014 at 9:55 AM, Ed Smith-Rowland 3dw...@verizon.net wrote:
So I would just serialize _M_n here.
It has fixed parameters. This would mean unnecessary work. When you
try to use the parameter of the sphere distribution the normal
On 07/14/2014 04:14 AM, Paolo Carlini wrote:
Hi,
On 07/14/2014 09:58 AM, Andreas Schwab wrote:
FAIL: ext/random/arcsine_distribution/cons/default.cc (test for
excess errors)
Excess errors:
/daten/aranym/gcc/gcc-20140714/libstdc++-v3/include/ext/random.tcc:1587:22:
error: '_M_n' was not
Braden,
I've played with this and it seems to work nicely.
Only one comment: Could you put the test cases in the C++14 subdirectory?
g++.dg/template/cpp1y/var-templ1.C
^
We should CC Jason on all this.
Also, do you have your FSF paperwork in place?
Thanks,
Ed
On 07/22/2014 01:56 AM, Ville Voutilainen wrote:
+/* Parse a type-parameter-key.
+
+ type-parameter-key:
+ class
+ typedef
+
+ Returns the kind of type-parameter-key specified, or none_type to indicate
+ error. */
+
Typo above, should be typename, not typedef.
Thanks!
New
Braden,
Great work on this. In addition to helping with constraints there is at
least one new library feature that depends on constexpr variable templates.
For my two cents it would be good to get just the constexpr variable
templates, aka n3651, in now as a first stage - it's quite usable.
On 07/23/2014 06:05 AM, Jason Merrill wrote:
On 07/22/2014 01:53 PM, Ed Smith-Rowland wrote:
+if (cxx_dialect cxx1z)
+ {
+/* Look for the `class' keyword. */
+cp_parser_require_keyword (parser, RID_CLASS, RT_CLASS);
+ }
+else
+ {
+/* Look
On 07/24/2014 11:32 AM, Jason Merrill wrote:
On 07/23/2014 10:31 PM, Ed Smith-Rowland wrote:
+pedwarn (token-location, OPT_Wpedantic,
+ ISO C++ forbids typename key in template template
parameter);
This should mention -std=c++1z.
+ if (tag_type == none_type
On 03/08/2014 01:33 PM, Jonathan Wakely wrote:
On 8 March 2014 16:29, Ed Smith-Rowland wrote:
On 03/08/2014 11:27 AM, Ed Smith-Rowland wrote:
The title says it all. This was just an oversight in the original patch.
This could wait until stage 1 obviously. I just wanted to post
How difficult would it be to make partial specializations work:
// Write n*pi once for every possible type
templatetypename Tp, std::size_t N
constexpr Tp npi = N * Tp(3.1415926535897932385L);
// Partial specialization for int type.
templatestd::size_t N
constexpr double npiint, N = N *
On 07/16/2014 12:18 PM, Mike Stump wrote:
On Jul 16, 2014, at 7:51 AM, Ed Smith-Rowland 3dw...@verizon.net wrote:
Deprecate c++1y. Chane language to reflect greater confidence in C++14
Chane - Change. I looked at your patch, all seems fine. I like the
documentation edits you did
On 07/26/2014 03:04 AM, Braden Obrzut wrote:
Ed, I looked into partial specializations and it looks like, while not
trivial, it would be easy enough for me to do them. However, it is
not required for concepts (which can not be specialized), so should I
fix them for this patch or as a separate
On 07/16/2014 12:18 PM, Mike Stump wrote:
On Jul 16, 2014, at 7:51 AM, Ed Smith-Rowland 3dw...@verizon.net wrote:
Deprecate c++1y. Chane language to reflect greater confidence in C++14
Chane - Change. I looked at your patch, all seems fine. I like the
documentation edits you did
in _Adaptor.
Someday, it might be beneficial to discuss an _IntegralAdaptor and a
corresponding __generate_canonical for use in our discreet distributions
but I want to close this bug with this patch.
Built and tested on x86_64-linux.
OK?
2014-07-29 Ed Smith-Rowland 3dw...@verizon.net
On 07/29/2014 04:29 AM, Jonathan Wakely wrote:
On 29/07/14 04:11 -0400, Ed Smith-Rowland wrote:
As discussed in the audit trail both _Adaptor and generate_canonical
are both meant to use floating point values. Both are here given
static_asserts to that effect.
This would have prevented
On 11/10/2014 12:10 PM, Jason Merrill wrote:
On 11/10/2014 10:55 AM, Ed Smith-Rowland wrote:
Would a 4.9 version be accepted?
Sure.
What do you think about defining the macros for unsupported features
to 0 rather than leaving them undefined? The document doesn't seem to
specify.
Jason
There were segfaults on preprocess-only involving __has_attribute.
-MM and -E both bombed with __has_attribute.
Several codebases use __has_attribute this (because of clang).
This problem would have been found with the SD-6 macro
__has_cpp_attribute as well so just taking out the extra macro
On 09/25/2014 01:40 PM, Jason Merrill wrote:
On 09/01/2014 09:41 PM, Ed Smith-Rowland wrote:
+ cpp_define (pfile, __cpp_attribute_deprecated=201309);
Don't we support attribute deprecated in C++11?
Jason
We support [[gnu::deprecated]] in C++11 bit not [[deprecated]] until C++14.
Ed
On 09/25/2014 12:57 PM, Jason Merrill wrote:
On 09/01/2014 09:34 PM, Ed Smith-Rowland wrote:
(open_file_failed()): Not an error to not find a header file for
__has_include__.
Hmm, looks like this means that __has_include__ will silently return
false if a header exists
On 09/25/2014 12:57 PM, Jason Merrill wrote:
On 09/01/2014 09:34 PM, Ed Smith-Rowland wrote:
(open_file_failed()): Not an error to not find a header file for
__has_include__.
Hmm, looks like this means that __has_include__ will silently return
false if a header exists
On 10/01/14, Jonathan Wakely wrote:
On 02/09/14 10:24 +0100, Jonathan Wakely wrote:
On 01/09/14 21:46 -0400, Ed Smith-Rowland wrote:
Index: include/bits/stl_function.h
===
--- include/bits/stl_function.h (revision 214680
On 10/01/2014 11:28 AM, Jonathan Wakely wrote:
On 02/09/14 10:24 +0100, Jonathan Wakely wrote:
On 01/09/14 21:46 -0400, Ed Smith-Rowland wrote:
Index: include/bits/stl_function.h
===
--- include/bits/stl_function.h(revision
On 10/02/2014 02:51 AM, Ed Smith-Rowland wrote:
On 10/01/2014 11:28 AM, Jonathan Wakely wrote:
On 02/09/14 10:24 +0100, Jonathan Wakely wrote:
On 01/09/14 21:46 -0400, Ed Smith-Rowland wrote:
Index: include/bits/stl_function.h
On 10/02/2014 06:14 AM, Jonathan Wakely wrote:
On 02/10/14 11:12 +0100, Jonathan Wakely wrote:
Note Ed's recent changes. Committed to CVS.
And fix a markup error that I expected xmllint to catch :-(
Thank you! I tried to do this and couldn't for permissions. I'm
probably not doing it right.
Built and tested clean on x86_64-linux.
OK?
Ed
2014-10-03 Edward Smith-Rowland 3dw...@verizon.net
* include/std/type_traits: Add is_final type trait for C++14.
* testsuite/util/testsuite_tr1.h: Add
* testsuite/20_util/is_final/requirements/
going on the branch too).
- Original Message -
From: Jason Merrill ja...@redhat.com
To: Ed Smith-Rowland 3dw...@verizon.net, Jonathan Wakely
jwak...@redhat.com
Cc: gcc-patches@gcc.gnu.org, thiago macieira thiago.macie...@intel.com
Sent: Thursday, 2 October, 2014 4:40:03 PM
Subject: Re
Greetings,
There was some feeling that not allowing [[deprecated]] for C++ was a
little extreme.
This patch builds and tests clean on x86_64-linux. OK?
Ed
gcc/c-family:
2014-10-06 Edward Smith-Rowland 3dw...@verizon.net
* c-family/c-cppbuiltin.c: Move
On 10/02/2014 10:24 AM, Jonathan Wakely wrote:
On 02/10/14 10:09 -0400, Ed Smith-Rowland wrote:
On 10/02/2014 06:14 AM, Jonathan Wakely wrote:
On 02/10/14 11:12 +0100, Jonathan Wakely wrote:
Note Ed's recent changes. Committed to CVS.
And fix a markup error that I expected xmllint to catch
On 10/09/2014 05:54 PM, Mike Stump wrote:
On Oct 9, 2014, at 11:56 AM, Uros Bizjak ubiz...@gmail.com wrote:
2014-10-09 Uros Bizjak ubiz...@gmail.com
* g++.dg/cpp1y/feat-cxx14.C: Variable templates not in yet.
(dg-do): Use c++1y target.
Tested on x86_64. OK for branch?
So, I need Ed
On 04/15/2014 03:06 PM, Jonathan Wakely wrote:
On 29/03/14 14:54 -0400, Ed Smith-Rowland wrote:
All,
In string_view I botched the noexcept specification of operations
like find and friends with CharT* arguments.
I'm a little surprised the inconsistency between string_view
This patch is really a libcpp patch. But UDLs are like that ;-)
Add string user-defined literals and char user-defined literals to the
list of things to look out for while escaping strings in macro args.
I'm not sure how to test this really. we want to write out *.ii files
and verify that
On 05/13/2014 01:29 PM, Joseph S. Myers wrote:
On Mon, 12 May 2014, Ed Smith-Rowland wrote:
This patch is really a libcpp patch. But UDLs are like that ;-)
Add string user-defined literals and char user-defined literals to the list of
things to look out for while escaping strings in macro
Make the machinery in bits/parse_number.h unsigned long long.
I had actually noticed this a while back but we were in stage 4. Then I
forgot.. :-/
Built and tested on x84_64-linux.
OK?
2014-05-14 Ed Smith-Rowland 3dw...@verizon.net
libstdc++/61166 overflow when parse number
On 05/14/2014 09:59 AM, Daniel Krügler wrote:
2014-05-14 15:38 GMT+02:00 Ed Smith-Rowland 3dw...@verizon.net:
Make the machinery in bits/parse_number.h unsigned long long.
I had actually noticed this a while back but we were in stage 4. Then I
forgot.. :-/
Built and tested on x84_64-linux.
OK
On 05/15/2014 03:03 PM, Jonathan Wakely wrote:
Here's a finished patch to simplify bits/parse_numbers.h
Tested x86_64-linux. Ed, any objection to this version?
This looks great, thanks!
Having done that should we actually stop using it as suggested in the
bug trail? ;-)
A group within the C++ standards committee was charged with the
responibility of coming up with a way for users to test a C++ compiler
and runtime for the availability of new features. These features are
intended to aid users in a time of intense C++ evolution. These
features are not really
This is the c-family part: Setting the language feature macos and
defining the __has_include macro.
c-family:
2014-05-31 Ed Smith-Rowland 3dw...@verizon.net
Implement SD-6: SG10 Feature Test Recommendations
* c-cppbuiltin.c (c_cpp_builtins()): Define language feature
Here is the libcpp portion.
2014-05-31 Ed Smith-Rowland 3dw...@verizon.net
Implement SD-6: SG10 Feature Test Recommendations
* directives.c: Support __has_include__ builtin.
* expr.c (parse_has_include): New function to parse __has_include__
builtin
This is the libstdc++ and libstdc++ testsuite part.
2014-05-31 Ed Smith-Rowland 3dw...@verizon.net
Implement SD-6: SG10 Feature Test Recommendations
* include/bits/basic_string.h: Add __cpp_lib feature test macro.
* include/bits/stl_algobase.h: Ditto.
* include
On 06/02/2014 10:31 AM, Jason Merrill wrote:
On 05/31/2014 02:30 AM, Marc Glisse wrote:
Also, I am pretty sure that gcc doesn't support the latest constexpr, we
shouldn't define those macros lightly.
That's correct. We should leave __cpp_constexpr at 200704 for now.
Right... That was a
On 05/20/2014 04:44 PM, Jason Merrill wrote:
On 05/13/2014 08:59 PM, Ed Smith-Rowland wrote:
+ escape_it = escape_it || cpp_userdef_string_p (token-type)
+|| cpp_userdef_char_p (token-type);
Let's add the new cases to the previous statement instead of a new
one. OK
1 - 100 of 330 matches
Mail list logo
