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/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 01/22/2016 05:39 AM, Jonathan Wakely wrote:
On 21/01/16 19:07 -0500, Ed Smith-Rowland wrote:
On 01/21/2016 07:29 AM, Jonathan Wakely wrote:
On 20/01/16 20:30 -0500, Ed Smith-Rowland wrote:
Now that libstdc++ installs a proper math.h we can piggyback on
that to put in the last bit
On 01/21/2016 07:29 AM, Jonathan Wakely wrote:
On 20/01/16 20:30 -0500, Ed Smith-Rowland wrote:
Now that libstdc++ installs a proper math.h we can piggyback on that
to put in the last bit of TR29124.
This patch adds the math special functions to c_compatibility/math.h
in the global namespace
Now that libstdc++ installs a proper math.h we can piggyback on that to
put in the last bit of TR29124.
This patch adds the math special functions to c_compatibility/math.h in
the global namespace.
I remove the XFAILs from the compile_2.cc tests.
This converts 21 XFAILs into 21 PASSes.
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:
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 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
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 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 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
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.
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 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
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
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
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 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 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 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
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.
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
?
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
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
On 12/30/2014 10:44 AM, Jason Merrill wrote:
On 12/27/2014 07:56 PM, 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.
Jason
Greetings,
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.
Ed
Index: htdocs/projects/cxx0x.html
===
RCS file:
I tried this patch a year ago and, as pointed out by NightStrike, got
lost in the shuffle.
The idea is that default arguments in literal operators would lead to
ambiguities and might not act like the uthor intends.
The earlier patch errors out. This time I just warn. I'm not sure what
we
And now with a patch...
I tried this patch a year ago and, as pointed out by NightStrike, got
lost in the shuffle.
The idea is that default arguments in literal operators would lead to
ambiguities and might not act like the uthor intends.
The earlier patch errors out. This time I just
On 12/17/2014 05:43 PM, Jakub Jelinek wrote:
On Wed, Dec 17, 2014 at 04:14:00PM -0500, Jason Merrill wrote:
On 12/05/2014 03:28 PM, Jakub Jelinek wrote:
3) there is no __has_attribute__ middle-end secondary macro,
when it is a built-in macro, it works fine in #ifdef too
I'm not sure what
Since we have C++14 sized deallocation we should enable the SD-6 feature
test macro.
For this feature test I'm not using language version but testing
flag_sized_deallocation in case C++14 turns the feature off or C++11
turns the feature on (as my reading and testing indicate that it can).
Since we have C++14 sized deallocation it seems we should enable the SD-6
feature test appropriately.
My reading of the announcement and code along with some experimentation
indicates that this feature is allowed in C++11 with -fsized-deallocation.
The feature test macro is thus set whenever
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 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
On 11/09/2014 11:45 PM, Jason Merrill wrote:
On 11/09/2014 08:33 PM, Ed Smith-Rowland wrote:
+ //cpp_hashnode *node = 0;
+ //node = token-val.node.node;
+ //if (node)
+ // pfile-mi_ind_cmacro = node;
Remove this commented-out code?
The patch is OK.
Jason
Here is the committed
I would like to put this patch out before Stage 1 ends even if there is
bikeshed renaming of macros in the next couple weeks as the C++
committee wraps up after their meeting.
The main part of this patch is a __has_cpp_attribute macro.
#if __has_cpp_attribute(foobar)
#else
#endif
In C++ we
On 11/06/2014 02:23 AM, Marc Glisse wrote:
On Wed, 5 Nov 2014, Ed Smith-Rowland wrote:
On 11/05/2014 04:25 PM, Marc Glisse wrote:
On Wed, 5 Nov 2014, Ed Smith-Rowland wrote:
Like the uniform_on_sphere_distribution which is used inside, the
2-dimensional case uses rejection
Could you point
This distribution has come in handy for me.
It relies on uniform_on_sphere_distribution and like it, min and max
have no real meaning.
Unlike uniform_on_sphere_distribution which really is a random
multidimensional unit vector users often want to pick the radius of the
distribution.
Unit
On 11/05/2014 04:25 PM, Marc Glisse wrote:
On Wed, 5 Nov 2014, Ed Smith-Rowland wrote:
Like the uniform_on_sphere_distribution which is used inside, the
2-dimensional case uses rejection
Could you point out where in the code you are special-casing dimension
2? Somehow I can't see
Subject says it all really.
Build and tested clean on x86_64-linux.
OK?
Ed
testsuite/
2014-11-02 Edward Smith-Rowland 3dw...@verizon.net
* g++.dg/cpp1y/feat-cxx11.C: Commentary and rearrangement of tests.
* g++.dg/cpp1y/feat-cxx11-neg.C: Add aggregate NSDMI test.
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 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
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
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
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/
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 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 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 x86_64-linux.
Part 5 - __has_cpp_attribute and supporting machinery is proving more
interesting than I thought.
But the rest should be put in.
Thank you,
Ed Smith-Rowland
On 09/15/2014 05:17 AM, Paolo Carlini wrote:
Hi again,
On 08/26/2014 10:54 AM, Paolo Carlini wrote:
Hi,
On 08/26/2014 10:52 AM, Jonathan Wakely wrote:
That seems like a good idea, but I'm not convinced there's any benefit
in Ed's changes to do:
-#if __cplusplus 201103L
+#if __cplusplus =
-linux.
Part 5 - __has_cpp_attribute and supporting machinery is proving more
interesting than I thought.
But the rest should be put in.
Thank you,
Ed Smith-Rowland
We've had __has_final built-in for a good while.
the std library component is_final was added to C++14 - which is now good.
I noticed while looking at the latest SD-6 draft.
So here is a simple patch that builds and passes clean on x86_64-linux.
OK?
2014-09-14 Edward Smith-Rowland
Greetings,
I am finally getting back to my SD-6 C++ features test work.
This adds front end and preprocessor tests for the language feature tests and
__has_include.
I am still working on the fifth and last in this series to add
__had_cpp_attribute but these first four patches add a very
Greetings,
I am finally getting back to my SD-6 C++ features test work.
This first part adds a __has_include__ built-in that will return true if
a header exists.
I also added __has_include_next__ as an extension. Clang has this
extension.
Both these built-ins will be wrapped in function
Greetings,
I am finally getting back to my SD-6 C++ features test work.
This second part adds a __has_include function-like macro that will
return true if a header exists. I also added a __has_include_next
function-like macro as an extension. Clang has this extension.
These macros just wrap
Greetings,
I am finally getting back to my SD-6 C++ features test work.
This adds feature macros to various libstdc++ components.
The new version of SD-6 cleans up the shared_mutex noise.
Some libraries that were moved to different tSen are still given macros as they
are in the SD-6 draft.
The Fourth installment, testing and other oddments will be sent tomorrow.
The implementation of __has_cpp_attribute is underway and will come in a
few days as a Fifth installment (modulo bugs this should be all).
I have it working in C++.
I feel though that it would be welcome as it is in
On 08/27/2014 03:40 PM, Jason Merrill wrote:
OK.
Jason
Is this OK for 4.9 also?
It builds and tests clean on x86_64-linux.
Attached slightly modified patch.
Ed
libcpp/
2014-08-28 Edward Smith-Rowland 3dw...@verizon.net
PR cpp/23827 - standard C++ should not have hex float
On 08/28/2014 09:47 AM, Jason Merrill wrote:
On 08/28/2014 09:41 AM, Marc Glisse wrote:
In my opinion it is not appropriate for a backport, no. If someone was
using hex floats with -std=c++98 with 4.9.1, it should still work with
4.9.2, I only expect to have to fix such things when moving to
This old one says the C++98 ANSI doesn't have hex float literals and
should error gracefully.
Fixed by changing a language feature flag as suggested by the audit
trail and by adding an error message.
Built and tested on x86_64-linux.
OK?
libcpp/
2014-08-27 Edward Smith-Rowland
On 08/26/2014 04:59 AM, Paolo Carlini wrote:
Hi,
On 08/26/2014 10:56 AM, Rainer Orth wrote:
bits/c++config...
Which won't help users seeing them in the headers. Maybe the issue
could be avoided by chosing names that make it clear that they are
g++/libstdc++ specific, not generic?
Sure,
On 08/22/2014 04:36 PM, Jason Merrill wrote:
OK, thanks.
Jason
Committed 214400.
Attached patch is the one committed.
Thanks.
libcpp/
2014-08-23 Edward Smith-Rowland 3dw...@verizon.net
* include/cpplib.h (enum c_lang): Add CLK_GNUCXX1Z, CLK_CXX1Z;
Rename CLK_GNUCXX1Y,
with
#if __cplusplus 201402L
...
#endif
Built and tested clean on x86_64-linux.
OK?
2014-08-23 Ed Smith-Rowland 3dw...@verizon.net
* libsupc++/new: Use the C++14 value of __cplusplus as appropriate.
* include/bits/parse_numbers.h: Ditto.
* include/bits/stl_function.h: Ditto
I get build fail:
../../gcc_concepts/gcc/cp/call.c:8793:8: error: unused variable ‘m1’
[-Werror=unused-variable]
tree m1 = get_temploid (cand1);
^
../../gcc_concepts/gcc/cp/call.c:8794:8: error: unused variable ‘m2’
[-Werror=unused-variable]
tree m2 = get_temploid (cand2);
On 08/09/2014 11:33 AM, Marc Glisse wrote:
On Sat, 9 Aug 2014, Ulrich Drepper wrote:
If you are going to specialize for dim 2, I imagine you won't be
computing
normal distributions, you will only generate a point uniformy in a
square
and reject it if it is not in the ball? (interestingly
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 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
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/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
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/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,
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/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
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
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
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
101 - 200 of 330 matches
Mail list logo
