On Tue, 7 May 2024 at 14:42, Matthias Kretz wrote:
>
> Tested on x86_64-linux-gnu and aarch64-linux-gnu and with Clang 18 on x86_64-
> linux-gnu.
>
> OK for trunk and backport(s)?
OK for all.
>
> -- 8<
>
> Signed-off-by: Matthias Kretz
>
> libst
On Mon, 2 Sept 2024 at 10:02, Andreas Schwab wrote:
>
> PR libstdc++/116513
> * libsupc++/compare (_S_fp_bits) [__fmt == _M68k_80bit]: Shift
> padding out of exponent word.
OK for trunk.
The code is present since GCC 12.1 so it's your call as target
maintainer which branch
On Sat, 31 Aug 2024 at 05:51, Alexandre Oliva wrote:
>
>
> 30_threads/future/members/poll.cc has calibration code that, on
> systems with very low clock resolution, may spuriously fail to run.
> Even when it does run, low resolution and reasonable
> timeouts limit severely the viability of increas
On Thu, 1 Aug 2024 at 11:44, Alexandre Oliva wrote:
>
> When we get to test_pr91486_wait_until(), we're about 10s past the
> float_steady_clock epoch. This is enough for the 1s delta for the
> timeout to come out slightly lower when the futex-less wait_until
> converts the deadline from float_ste
On Mon, 2 Sept 2024, 14:15 Kyrylo Tkachov, wrote:
> Hi Evgeny,
>
> > On 2 Sep 2024, at 15:03, Evgeny Karpov
> wrote:
> >
> > External email: Use caution opening links or attachments
> >
> >
> > The patch resolves compilation issues for the C++ language. Previous
> > patch series contributed to C
On Mon, 2 Sept 2024, 14:15 Kyrylo Tkachov, wrote:
> Hi Evgeny,
>
> > On 2 Sep 2024, at 15:03, Evgeny Karpov
> wrote:
> >
> > External email: Use caution opening links or attachments
> >
> >
> > The patch resolves compilation issues for the C++ language. Previous
> > patch series contributed to C
Tested x86_64-linux. Pushed to trunk.
-- >8 --
We don't need to use std::aligned_storage in std::any. We just need a
POD type of the right size. The void* union member already ensures the
alignment will be correct. Avoiding std::aligned_storage means we don't
need to suppress a -Wdeprecated-decla
Tested x86_64-linux. Pushed to trunk.
-- >8 --
LWG 3736 added a partial specialization of this variable template for
two std::move_iterator types. This is needed for the case where the
types satisfy std::sentinel_for and are subtractable, but do not model
the semantics requirements of std::sized_
Tested x86_64-linux. Pushed to trunk.
-- >8 --
The recent change to use auto_win_file_handle for
std::filesystem::hard_link_count caused a regression. The
std::error_code argument should be cleared if no error occurs, but this
no longer happens. Add a call to ec.clear() in fs::hard_link_count to
Tested x86_64-linux. Pushed to gcc-14.
-- >8 --
For the backport, rejecting array types is only done in strict modes.
libstdc++-v3/ChangeLog:
PR libstdc++/116381
* include/std/variant (variant): Fix conditions for
static_assert to match the spec.
* testsuite/20_u
On Thu, 5 Sept 2024 at 22:00, Jason Merrill wrote:
>
> Tested x86_64-pc-linux-gnu, OK for trunk?
OK, thanks.
>
> -- 8< --
>
> In addition to marking it as flag_enum, we want to avoid warnings about
> not having a case for the implementation detail enumerators
> _S_ios_openmode_*. And also for _
On Fri, 6 Sept 2024 at 02:47, Jason Merrill wrote:
>
> On 8/28/24 6:22 AM, Jason Merrill wrote:
> > On 8/28/24 6:09 AM, Jonathan Wakely wrote:
> >> On Wed, 28 Aug 2024 at 10:58, Jason Merrill wrote:
> >>>
> >>> On 8/28/24 5:55 AM, Jonathan Wakely wrot
On 05/09/24 21:44 -0400, Jason Merrill wrote:
On 9/4/24 11:02 AM, Marek Polacek wrote:
+handle_flag_enum_attribute (tree *node, tree ARG_UNUSED(name), tree args,
+ int ARG_UNUSED (flags), bool *no_add_attrs)
+{
+ if (args)
+warning (OPT_Wattributes, "%qE attribute
Tested x86_64-linux. Pushed to trunk. This should be backported too.
I noticed while testing this that all the from_stream overloads for
time_point specializations use time_point_cast to convert to the correct
result type. That's wrong, but I'll fix that separately, as it affects
more than just GP
This proposed patch means that span is not an associated type of
span::iterator, which means that we won't try to complete T when
doing ADL in the constraints for const_iterator. This makes it more
reliable to use std::span.
See https://github.com/llvm/llvm-project/issues/107215 for more info on
t
On Fri, 6 Sept 2024 at 20:17, Jason Merrill wrote:
>
> On 9/6/24 8:56 AM, Jonathan Wakely wrote:
> > On 05/09/24 21:44 -0400, Jason Merrill wrote:
> >> On 9/4/24 11:02 AM, Marek Polacek wrote:
> >>>> +handle_flag_enum_attribute (tree *node, tre
On Tue, 10 Sept 2024 at 05:10, Jason Merrill wrote:
>
> Tested x86_64-pc-linux-gnu, OK for trunk?
I'm going to have to do some digging ... I _think_ there's some
obscure reason for this. Maybe a weird bootstrap situation. Or maybe I
made that up as rationale for a scripting error.
>
> -- 8< --
>
Tested x86_64-linux. Pushed to trunk.
-- >8 --
Since r15-3532-g7cebc6384a0ad6 18_support/new_nothrow.cc fails in C++98 mode
because G++
diagnoses missing exception specifications for the user-defined
(de)allocation functions. Add throw(std::bad_alloc) and throw() for
C++98 mode.
Similarly, 26_n
Tested x86_64-linux. Pushed to trunk. Backports to follow.
-- >8 --
The changes to implement LWG 2579 (r10-327-gdb33efde17932f) made
std::string::assign use the propagate_on_container_copy_assignment
(POCCA) trait, for consistency with operator=(const basic_string&).
However, this also unintentio
Tested x86_64-linux. Pushed to trunk. Backport to follow.
-- >8 --
The undefined std::ios_base_library_init() symbol that is referenced by
is only supposed to be used for targets where symbol
versioning is supported.
The mingw-w64 target defaults to --enable-symvers=gnu due to using GNU
ld but
On Tue, 10 Sept 2024 at 11:12, Jonathan Wakely wrote:
>
> On Tue, 10 Sept 2024 at 05:10, Jason Merrill wrote:
> >
> > Tested x86_64-pc-linux-gnu, OK for trunk?
>
> I'm going to have to do some digging ... I _think_ there's some
> obscure reason for this. Maybe
Tested x86_64-linux. OK for trunk?
-- >8 --
The standard says that std::launder is ill-formed for function pointers
and cv void pointers, so there's no reason for __builtin_launder to
accept them. This change allows implementations of std::launder to defer
to the built-in for error checking, alth
Tested x86_64-linux.
Both GCC and Clang support the __is_function built-in, so we should get
the static_assert here. For a compiler that doesn't support it, we rely
on __builtin_launder to diagnose function pointers. That's true for
Clang, and PATCH 1/2 makes it true for G++.
We might want to con
On Thu, 12 Sept 2024 at 19:38, Patrick Palka wrote:
>
> On Thu, 12 Sep 2024, Jonathan Wakely wrote:
>
> > Tested x86_64-linux. OK for trunk?
> >
> > -- >8 --
> >
> > The standard says that std::launder is ill-formed for function pointers
> >
Tested x86_64-linux. Pushed to trunk.
-- >8 --
I added this __is_bool alias template in r15-2309-g6d86486292acbe but
it isn't actually used so can be removed.
libstdc++-v3/ChangeLog:
* include/std/optional (__is_bool): Remove.
---
libstdc++-v3/include/std/optional | 2 --
1 file change
On Thu, 12 Sept 2024 at 16:02, Jason Merrill wrote:
>
> On 9/12/24 4:49 AM, Jonathan Wakely wrote:
> > Tested x86_64-linux. OK for trunk?
> >
> > -- >8 --
> >
> > The standard says that std::launder is ill-formed for function pointers
> > a
This restores support for most of with -ffreestanding. In case
there are users who want a minimal freestanding implementation that only
provides what the standard guarantees, there's a new macro that disables
again. This can be used to write more portable freestanding
code that doesn't rely on b
You might notice that this removes handling of EINVAL from the call to
sem_timedwait. That error can only happen with a negative ts_nsec value,
which can only happen for a timestamp before the epoch. We should handle
that properly, not just for the case where ts_nsec happens to be
negative. I opene
This adds some comments to explain what this rather subtle code is
doing. It also replaces string::copy with using char_traits::copy
directly, because the bounds checks and length adjustments that
string::copy does are redundant here - we already ensure the lengths are
correct.
Tested x86_64-linux
I'll wait for Linaro CI to confirm this works, and then push.
I didn't see the regression because I only tested on x86_64.
-- >8 --
This aarch64-*-* test needs an update for the diagnostic I changed in
r15-3614-g9fe57e4879de93.
gcc/testsuite/ChangeLog:
* g++.dg/ext/sve-sizeless-1.C: Ad
On Fri, 30 Aug 2024 at 11:52, Giuseppe D'Angelo wrote:
>
> Hello,
>
> This patch completes the fix for PR108846, extending it to range-based
> copy/move algorithms, and also fixes a faulty static_assert in them
> (PR116471).
> It's a minor improvement over the patch I've attached to PR116471 (I've
On Sat, 3 Aug 2024 at 00:10, Jonathan Wakely wrote:
>
> On Fri, 2 Aug 2024 at 23:49, Giuseppe D'Angelo
> wrote:
> >
> > Hello,
> >
> > as usual thank you for the review. V2 is attached.
> >
> > On 02/08/2024 14:38, Jonathan Wakely wrote:
> &g
On Fri, 13 Sept 2024 at 11:00, Giuseppe D'Angelo wrote:
>
> Hello,
>
> Thank you for the review!
>
> Il 13/09/24 10:49, Jonathan Wakely ha scritto:
> >
> > But I can make these minor changes locally and push it if you want -
> > there's no need for a
On Fri, 13 Sept 2024 at 11:26, Jonathan Wakely wrote:
>
> On Sat, 3 Aug 2024 at 00:10, Jonathan Wakely wrote:
> >
> > On Fri, 2 Aug 2024 at 23:49, Giuseppe D'Angelo
> > wrote:
> > >
> > > Hello,
> > >
> > > as usual thank yo
On Sat, 14 Sept 2024 at 10:39, Arsen Arsenović wrote:
>
> Jonathan Wakely writes:
>
> > This restores support for most of with -ffreestanding. In case
> > there are users who want a minimal freestanding implementation that only
> > provides what the standard guarantee
On Fri, 13 Sept 2024 at 18:14, Patrick Palka wrote:
>
> On Fri, 13 Sep 2024, Jonathan Wakely wrote:
>
> > On Sat, 3 Aug 2024 at 00:10, Jonathan Wakely wrote:
> > >
> > > On Fri, 2 Aug 2024 at 23:49, Giuseppe D'Angelo
> > > wrote:
> > > >
On Sun, 15 Sept 2024 at 15:53, Jonathan Wakely wrote:
>
> On Fri, 13 Sept 2024 at 18:14, Patrick Palka wrote:
> >
> > On Fri, 13 Sep 2024, Jonathan Wakely wrote:
> >
> > > On Sat, 3 Aug 2024 at 00:10, Jonathan Wakely wrote:
> > > >
> >
On Fri, 13 Sept 2024 at 18:36, Patrick Palka wrote:
>
> On Fri, 13 Sep 2024, Patrick Palka wrote:
> >
> > Ah, we very recently implemented P2609R3 which has the following note
> > about projected_value_t: https://wg21.link/p2609r3#proposal
> >
> > Do we want to honor this note here and define proj
I posted this for review in January. I've pushed it now. I think the
patch is unchanged, but I improved the commit message.
Tested x86_64-linux. Pushed to trunk.
-- >8 --
This is a step towards implementing the C++23 change P2408R5, "Ranges
iterators as inputs to non-Ranges algorithms". C++20 ra
Tested x86_64-linux. Pushed to trunk.
-- >8 --
LWG 436 confirmed that const-qualified types are valid arguments for
Facet template parameters, but volatile-qualified types are not. Add an
assertion to locale::combine to check for valid types.
libstdc++-v3/ChangeLog:
* include/bits/loca
On Sat, 14 Sept 2024 at 15:16, Jonathan Wakely wrote:
>
> On Sat, 14 Sept 2024 at 10:39, Arsen Arsenović wrote:
> >
> > Jonathan Wakely writes:
> >
> > > This restores support for most of with -ffreestanding. In case
> > > there are users who want
The v2 patch extends the change to std::basic_stacktrace::iterator.
Tested x86_64-linux. Pushed to trunk.
-- >8 --
Because std::span can be useful, it makes sense to define
std::span::iterator such that Incomplete is not an
associated class, and so the compiler won't attempt to complete it when
Tested x86_64-linux.
-- >8 --
PR 116529 shows that std::unique_ptr is currently unusable
because the constructor taking std::auto_ptr (which is a non-standard
extension since C++17) tries to form the invalid type X&* during
overload resolution. We can use the `pointer` type in the constructor
con
As mentioned in the Q&A session in Prague, I've been using these files
for years in my local GCC tree to help with formatting libstdc++ files.
I'll come up with similar files for the top-level and elsewhere in the
GCC tree. As Jakub mentioned, we certainly don't want to trim trailing
whitespace fro
On Mon, 16 Sept 2024 at 10:19, Jonathan Wakely wrote:
>
> As mentioned in the Q&A session in Prague, I've been using these files
> for years in my local GCC tree to help with formatting libstdc++ files.
> I'll come up with similar files for the top-level and elsewhere i
On 23 August 2013 10:15, Tim Shen wrote:
> These two patches are not logically relative, but the next patch is
> based on this one.
>
> This patch of the regex scanner(or lexer) supports all styles
> specified by N3376. It shall build an abstract layer of regex token
> sequence, so that, ideally,
On 23 August 2013 10:17, Tim Shen wrote:
> Inspired by this mail: http://gcc.gnu.org/ml/libstdc++/2013-08/msg00131.html
This is OK too, thanks for the quick fix to the locale issue!
On 23 August 2013 15:53, Tim Shen wrote:
> On Fri, Aug 23, 2013 at 10:26 PM, Paolo Carlini
> wrote:
>> Great. But please but the names of the functions you are changing between
>> round brackets. You have tons of examples everywhere.
>
> ...like this?
Yes, that makes it clear what part of the fil
On 23 August 2013 16:48, Tim Shen wrote:
> By the way, do we seariously need to keep ChangeLog in files? Is it
> more like a tradition than a solution? After all, we have SVN or Git
> now. I remember a mail metioned this but cannot find it >.<
It's not a tradition, they are required, see
http://ww
On 10 September 2013 16:49, Kai Tietz wrote:
>
> PR/54314
> * config/abi/pre/gnu-versioned-namespace.ver: Add thunk _ZTv0_n12_NS* like
> in gnu,ver.
OK with s/gnu,ver/gnu.ver/ in the ChangeLog. Thanks.
On 15 September 2013 10:12, Marc Glisse wrote:
>
> PR libstdc++/58338
> * include/bits/stl_vector.h
> (_Vector_impl::_Vector_impl(_Tp_alloc_type const&),
> _Vector_impl::_Vector_impl(_Tp_alloc_type&&),
> _Vector_impl::_M_swap_data,
> _Vector_base::_Ve
On 18 September 2013 16:51, Marc Glisse wrote:
> Hello,
>
> some more containers...
>
> In debug array, we already have throw in noexcept functions, but if I
> understand correctly it is only because of syntax limitations for constexpr
> functions and aborts before throwing, although the use of
> _
On 18 September 2013 17:27, Marc Glisse wrote:
> On Wed, 18 Sep 2013, Paolo Carlini wrote:
>>
>> On 09/18/2013 05:51 PM, Marc Glisse wrote:
>>>
>>> In debug array, we already have throw in noexcept functions, but if I
>>> understand correctly it is only because of syntax limitations for
>>> conste
On 18 September 2013 17:00, Paolo Carlini wrote:
> Hi,
>
>
> On 09/18/2013 05:51 PM, Marc Glisse wrote:
>>
>> Hello,
>>
>> some more containers...
Great, thanks for working your way through all these!
>> In debug array, we already have throw in noexcept functions, but if I
>> understand correctly
On 24 September 2013 23:37, Marc Glisse wrote:
> Hello,
>
> this was only minimally tested since trunk is broken at the moment. There
> don't seem to be specific tests for the existing functors, so a couple tests
> for the new specializations seem good enough.
>
I've had this sitting in my tree wa
On 25 September 2013 06:41, Marc Glisse wrote:
> On Wed, 25 Sep 2013, Jonathan Wakely wrote:
>
>> I've had this sitting in my tree waiting to do something with,
>
>
> I did ask last week if someone had done it already...
Sorry :-\
>
>> I'm about to go to
On 19 January 2013 23:43, Jonathan Wakely wrote:
> PR libstdc++/55861
> * include/std/future (_State_base::_S_check(const shared_ptr&)):
> Fix return type.
> (__basic_future::_M_get_result()): Const qualify.
> (shared_futur
On 26 September 2013 22:28, Tim Shen wrote:
> Just follow the standard :)
>
> Booted and tested under -m32, -m64.
The ChangeLog entry says "stanard", with that fixed this is OK to
commit, thanks!
On 27 September 2013 03:15, Tim Shen wrote:
> POSIX ERE says that escaping an ordinary char, say R"\n" is not
> permitted, because 'n' is not a special char. However, they also say
> that : "Implementations are permitted to extend the language to allow
> these. Conforming applications cannot use su
On 27 September 2013 05:17, Ed Smith-Rowland wrote:
>
> The complex user-defined literals finally passed (n3779) with the resolution
> to DR1473 allowing the suffix id to touch the quotes (Can't find it but I
> put it in not too long ago).
I think it's been approved by the LWG and looks like it wi
On 27 September 2013 13:32, Paolo Carlini wrote:
> On 9/27/13 4:34 AM, Jonathan Wakely wrote:
>>
>> On 27 September 2013 03:15, Tim Shen wrote:
>>>
>>> POSIX ERE says that escaping an ordinary char, say R"\n" is not
>>> permitted, because '
after it's been on trunk without problems for a while.
commit 55531e9c74a5f2b4699250b6b302d49f7dc8c5ae
Author: Jonathan Wakely
Date: Wed Aug 7 01:38:39 2013 +0100
PR libstdc++/57465
* include/std/functional
(_Function_base::_Base_manager::_M_not_empty_function): Fi
On 2 October 2013 11:41, Paolo Carlini wrote:
>
> Minimally, I would talk about "improved support": the evolution from
> -std=c++0x to -std=c++11 meant that we aren't in experimental mode anymore.
>From speaking to Jason he's pretty adamant it's still experimental for now :-)
My understanding was
On 2 October 2013 13:28, Marc Glisse wrote:
> Hello,
>
> I don't understand why those 2 files differ by more than 1 extra argument,
> so I am changing that.
>
> Bootstrap and testsuite on x86_64.
>
> 2013-10-03 Marc Glisse
>
> * libsupc++/del_op.cc (operator delete): Don't test for 0 bef
On 2 October 2013 15:52, Tim Shen wrote:
> I feel little bit uncomfortable with "new ISO C++ standard, C++11",
> since C++14 is already there, so I removed it.
Good idea.
> Please check the words, since English is not my first language >.<
The english is fine, please wait a few hours in case any
On 2 October 2013 15:26, Tim Shen wrote:
> _BracketMatcher<>::_M_add_equivalence_class is misimplemented so I try
> `git blame regex_compiler.h`...that's me!
>
> Booted and tested under -m32, -m64.
This is OK to commit, thanks
This removes all the code for non-GCC compilers in
Tested x86_64, "make check check-parallel", committed to trunk.
PR libstdc++/34106
* include/parallel/compatibility.h: Remove non-GCC code.
commit 9c3f1fdec9fc7be67cf2c0d45d1b791f167c0aec
Author: Jonathan Wakely
Date:
PR libstdc++/54577
* doc/xml/manual/status_cxx2011.xml: N2350 changes are missing from
sequence containers.
* doc/html/*: Regenerate.
Committed to trunk.
commit 56e855e46beb016fcf4f9f293abbb774a9285a46
Author: Jonathan Wakely
Date: Sun Sep 30 12:35:19 2012 +0100
.
Tested x86_64-linux, committed to trunk.
commit 293275915de97fc9a627d27a4b8d3143f398486e
Author: Jonathan Wakely
Date: Sun Sep 30 15:53:11 2012 +0100
* include/ext/ropeimpl.h (__uninitialized_fill_n_a): Fix using
declaration.
* testsuite/ext/rope/5.cc: New.
diff --git a
-linux.
Are the libgcc parts OK for trunk?
commit 37d75fef68222e92c4b58870dcfeeb3679e3c718
Author: Jonathan Wakely
Date: Sun Sep 30 19:00:51 2012 +0100
libgcc:
PR other/53889
* gthr.h (__gthread_recursive_mutex_destroy): Document new required
function
On 1 October 2012 20:22, Ian Lance Taylor wrote:
> On Sun, Sep 30, 2012 at 11:41 AM, Jonathan Wakely
> wrote:
>> There is no __gthread_recursive_mutex_destroy function in the gthreads API.
>>
>> Trying to use __gthread_mutex_destroy fails to compile on platforms
>>
On 2 October 2012 07:02, Ian Lance Taylor wrote:
>
> The libgcc part of this is OK.
Thanks, I've committed it and closed the PR.
* config/i386/gthr-win32.h (__gthread_recursive_mutex_destroy):
Fix variable name.
commit 6bd7f9deb11c064e5c22acd8cbd0db163edd09d7
Author: Jonathan Wakely
Date: Fri Oct 5 08:33:24 2012 +0100
PR other/53889
* config/i386/gthr-win32.h (__gthread_recursive_mutex_destroy
Resending as plain text so the list doesn't reject it ...
On Oct 7, 2012 12:00 AM, "NightStrike" wrote:
>
> On Sat, Oct 6, 2012 at 7:30 AM, Manuel López-Ibáñez
> wrote:
> > Hi,
> >
> > GCC now requires ISL and a very new CLOOG but download_prerequisites
> > does not download those. Also, there i
On 7 October 2012 21:31, Manuel López-Ibáñez wrote:
> On 7 October 2012 22:13, Jonathan Wakely wrote:
>>
>> On Oct 7, 2012 12:00 AM, "NightStrike" wrote:
>>>
>>> On Sat, Oct 6, 2012 at 7:30 AM, Manuel López-Ibáñez
>>> wrote:
>>> &g
On 8 October 2012 20:45, Mark Kettenis wrote:
> Jonathan,
>
> Any further thoughts about this? I've attached a diff that combines
> my origional diff with the change to use the "newlib" locale model on
> OpenBSD since they probably should be committed together.
Hi,
Sorry for the delay, I realise
2012-10-09 Jonathan Wakely
PR libstdc++/54754
* include/parallel/compatibility.h: Use atomic built-ins when they are
lock-free.
Tested x86_64-linux, i386-linux, powerpc64-linux. There are some
time-outs when running the 'check-parallel' testsuite on ppc64 wh
On 9 October 2012 01:39, Jack Howarth wrote:
>The --enable-libstdcxx-time=yes configure option fails to validate the
> presence of a usable nanosleep() call on darwin due to its use of pre-2008
> POSIX timers. As both nanosleep() and sched_yield() have always been available
> on darwin, the att
On 9 October 2012 14:11, Jack Howarth wrote:
> On Tue, Oct 09, 2012 at 09:21:25AM +0100, Jonathan Wakely wrote:
>> I don't like the sched_yield macro being set there because it's
>> detected correctly by configure anyway, but I'm not going to labour
>> t
On 9 October 2012 20:48, Mark Kettenis wrote:
>
> I think it is. The newlib ctype classification is identical to the
> traditional BSD scheme that OpenBSD uses.
OK, I'll commit your patch tomorrow, thanks.
read.o]: [59] | 0| 418|FUNC |WEAK |0
> |12 |_ZNSt12system_errorC1ESt10error_codeRKSs
>
> A reghunt revealed that this was introduced by
>
> 2012-08-12 Jonathan Wakely
>
> PR libstdc++/52681
> * src/c++11/thread.cc (thread::_M_start_thr
rs in the future wondering why
> configure says no but their TU says yes.
>
> At least a comment in the configure bits admitting defeat, people.
Committed to trunk like so.
commit 1616a77cdcdf619b1621265f33165cf6c74a3eed
Author: Jonathan Wakely
Date: Thu Oct 11 00:06:14 2012 +0100
On 9 October 2012 22:03, Jonathan Wakely wrote:
> On 9 October 2012 20:48, Mark Kettenis wrote:
>>
>> I think it is. The newlib ctype classification is identical to the
>> traditional BSD scheme that OpenBSD uses.
>
> OK, I'll commit your patch tomorrow, thanks.
i
On 11 October 2012 00:09, Jonathan Wakely wrote:
> On 9 October 2012 18:49, Benjamin De Kosnik wrote:
>>
>>> I don't like the sched_yield macro being set there because it's
>>> detected correctly by configure anyway, but I'm not going to labour
>>&g
On 11 October 2012 17:05, Jack Howarth wrote:
>
> Jonathan,
> The committed patch results in the expected this_thread::yield() and
> this_thread::sleep_for()
> support. I did run into a regression at -m32/-m64 on darwin10 (but not
> darwin11/12).
>
> WARNING: program timed out.
> FAIL: 30_thr
http://gcc.gnu.org/onlinedocs/cpp/Search-Path.html claims the search
path for C++ headers starts with /usr/include/g++-v3 which hasn't been
true for many years.
2012-10-18 Jonathan Wakely
* doc/cpp.texi (Search Path): Fix outdated C++ path.
Tested with "make doc html"
* g++.dg/warn/Wreturn-local-addr.C: New.
Tested x86_64-linux, OK for trunk?
commit 77abe727e837e052680be8020fa2990cce4d1e9a
Author: Jonathan Wakely
Date: Wed Oct 17 19:32:10 2012 +0100
gcc/c-family:
PR c++/54930
* c.opt (Wreturn_local_addr): Define new option.
gc
: New.
* testsuite/23_containers/forward_list/allocator/noexcept.cc: New.
* testsuite/23_containers/forward_list/allocator/swap.cc: New.
Tested x86_64-linux, committed to trunk.
commit 2c5b344ef08b72cbf9e21f9859f85e54f3e87f26
Author: Jonathan Wakely
Date: Mon Mar 12 22:43:34 2012
of std::pair objects.
* testsuite/20_util/scoped_allocator/2.cc: New.
Tested x86_64-linux, committed to trunk.
commit 2a969ae20431833dbb4a2dfdf0be03b5d4b716c9
Author: Jonathan Wakely
Date: Fri Oct 19 16:58:53 2012 +0100
* include/std/scoped_allocator (__outermost_a
The table's a bit out of date
* doc/xml/manual/status_cxx2011.xml: Update.
Committed to trunk.
diff --git a/libstdc++-v3/doc/xml/manual/status_cxx2011.xml
b/libstdc++-v3/doc/xml/manual/status_cxx2011.xml
index 226eef9..6b1ad51 100644
--- a/libstdc++-v3/doc/xml/manual/status_cxx2011.xml
+
On 19 October 2012 21:28, Hans-Peter Nilsson wrote:
> Looks like _U is one of those identifiers that should be
> avoided: Grep yields:
> src/newlib/libc/include/ctype.h:#define _U 01
Argh! my bad, sorry - fix on the way ...
On 20 October 2012 02:35, Jonathan Wakely wrote:
> On 19 October 2012 21:28, Hans-Peter Nilsson wrote:
>> Looks like _U is one of those identifiers that should be
>> avoided: Grep yields:
>> src/newlib/libc/include/ctype.h:#define _U 01
>
> Argh! my bad, sorry
On 21 October 2012 20:34, Gerald Pfeifer wrote:
> On Thu, 18 Oct 2012, Jonathan Wakely wrote:
>> http://gcc.gnu.org/onlinedocs/cpp/Search-Path.html claims the search
>> path for C++ headers starts with /usr/include/g++-v3 which hasn't been
>> true for many years.
>>
alised the
'darwin' option was also undocumented, so I committed the attached
patch to the trunk.
I haven't regenerated the HTML pages, I plan to do that soon after a
few more doc updates.
commit 7e0b461312a4304d8f84602732aa19cb718af32c
Author: Jonathan Wakely
Date: Mon Oct 22
On 22 October 2012 20:59, François Dumont wrote:
> Attached patch applied.
>
> 2012-10-22 François Dumont
>
>
> * include/bits/unordered_set.h (unordered_set<>): Prefer
> aggregation to inheritance with _Hashtable.
> (unordered_multiset<>): Likewise.
> * include/debug/unordered_s
This seems to fix it, is it correct? (Untested as I'm still waiting
for a bootstrap to finish)
diff --git a/gcc/lra-constraints.c b/gcc/lra-constraints.c
index 4b35726..827fd4d 100644
--- a/gcc/lra-constraints.c
+++ b/gcc/lra-constraints.c
@@ -1216,11 +1216,13 @@ check_and_process_move (bool *cha
class.
(Tr1UnorderedSetPrinter): Likewise.
Tested x86_64-linux and committed to trunk.
commit a554179e10f867f983ca1915455ceb23a9edad3d
Author: Jonathan Wakely
Date: Sun Oct 28 13:16:31 2012 +
PR libstdc++/55041
* python/libstdcxx/v6/printers.py (Tr1UnorderedMapPrinter): Update
On 28 October 2012 22:21, Gerald Pfeifer wrote:
> On Sun, 21 Oct 2012, Jonathan Wakely wrote:
>>> I was going to say "Ack", since it's a doc patch, but somehow my
>>> own tests on various platforms (FreeBSD, GNU/Linux,...) did not
>>> confirm /usr/incl
On 29 October 2012 00:08, Jonathan Wakely wrote:
> Yes, libdir/gcc/target/version/../../../../include/c++/version would
> be more accurate, because libdir is not necessarily /usr
>
> I'll come up with something better ...
I've committed thi
Committed as obvious.
1301 - 1400 of 10092 matches
Mail list logo
