Hi all,
just pinging this thread in case it got lost in the shuffle.
Best,
Nina
On Fri, 30 Aug 2024 at 13:49, Nina Dinka Ranns
wrote:
> We currently do not expect comdat group of the guarded function to
> be set at the time of generating pre and post check function.
> However, in th
We currently do not expect comdat group of the guarded function to
be set at the time of generating pre and post check function.
However, in the case of an explicit instantiation, the guarded
function has been added to a comdat group before generating contract
check functions, which causes the obse
On Tue, 16 Jul 2024 at 15:55, Jason Merrill wrote:
> On 7/16/24 5:03 AM, Nina Dinka Ranns wrote:
> > Hello,
> >
> > We currently only initialise terminate_fn if exceptions are enabled.
> > However, contract handling requires terminate_fn when building the
> > c
It would help if I attached the patch
Apologies,
Nina
On Tue, 16 Jul 2024 at 10:03, Nina Dinka Ranns
wrote:
> Hello,
>
> We currently only initialise terminate_fn if exceptions are enabled.
> However, contract handling requires terminate_fn when building the
> contract as a c
Hello,
We currently only initialise terminate_fn if exceptions are enabled.
However, contract handling requires terminate_fn when building the
contract as a contract failure may result in std::terminate call
regardless of whether the exceptions are enabled. Added possible
initialisation of termina
On Tue, 9 Jul 2024 at 22:50, Jason Merrill wrote:
> On 7/9/24 6:41 AM, Nina Dinka Ranns wrote:
> > On Mon, 8 Jul 2024 at 16:01, Jason Merrill > <mailto:ja...@redhat.com>> wrote:
> >
> > On 7/8/24 7:47 AM, Nina Dinka Ranns wrote:
> > > HI Jason
Hi Jason,
On Mon, 8 Jul 2024 at 16:01, Jason Merrill wrote:
> On 7/8/24 7:47 AM, Nina Dinka Ranns wrote:
> > HI Jason,
> >
> > On Fri, 5 Jul 2024 at 17:31, Jason Merrill wrote:
> >>
> >> On 7/5/24 10:25 AM, Nina Dinka Ranns wrote:
> >>>
HI Jason,
On Fri, 5 Jul 2024 at 17:31, Jason Merrill wrote:
>
> On 7/5/24 10:25 AM, Nina Dinka Ranns wrote:
> > Certain places in contract parsing currently do not check for errors.
> > This results in contracts
> > with embedded errors which eventually confuse gimplif
Certain places in contract parsing currently do not check for errors.
This results in contracts
with embedded errors which eventually confuse gimplify. Checks for
errors added in
grok_contract() and cp_parser_contract_attribute_spec() to exit early
if an error is encountered.
Tested on x86_64-pc-l
On Wed, 5 Jun 2019 at 19:19, Jason Merrill wrote:
> On 6/5/19 1:29 PM, Nina Dinka Ranns wrote:
> > Ack. Amended change log is below. Changes are :
> > * changed C++ -> c++
> > * fixed the name of added test
> >
> > There are no changes in the diff,
Ack. Amended change log is below. Changes are :
* changed C++ -> c++
* fixed the name of added test
There are no changes in the diff, but I attached it to this e-mail for
reference.
Thanks,
Nina
2019-06-04 Nina Dinka Ranns
gcc/cp
PR c++/63149
* pt.c (listify_autos): Use non
yes, I forgot to attach the latest patch. :)
On Wed, 5 Jun 2019 at 10:24, Nina Dinka Ranns wrote:
>
> Hi both,
> Addressing all comments in this e-mail, as some are duplicate.
>
> On Tue, 4 Jun 2019 at 20:45, Paolo Carlini wrote:
> >
> > Hi,
> >
> > On
Hi both,
Addressing all comments in this e-mail, as some are duplicate.
On Tue, 4 Jun 2019 at 20:45, Paolo Carlini wrote:
>
> Hi,
>
> On 04/06/19 21:26, Nina Dinka Ranns wrote:
>
> Good point, dg-do compile is sufficient to demonstrate the issue.
>
> I agree.
>
&g
Good point, dg-do compile is sufficient to demonstrate the issue.
Amended, new patch attached.
Thanks,
Nina
On Tue, 4 Jun 2019 at 17:53, Paolo Carlini wrote:
>
> Hi,
>
> On 04/06/19 18:36, Nina Dinka Ranns wrote:
> > +// Test for PR63149
> > +// { dg-do run { target c+
Tested on Linux x86_64
2019-06-04 Nina Dinka Ranns
gcc/cp
PR c++/63149
* pt.c (listify_autos): use non cv qualified auto_node in
std::initializer_list
testsuite/
PR c++/63149
* g++.dg/cpp0x/initlist-deduce.C: New
Index: gcc/cp/pt.c
Tested on Linux x86_64
basic_string spurious use of a default constructible allocator - LWG2788
2019-05-27 Nina Dinka Ranns
basic_string spurious use of a default constructible allocator - LWG2788
* bits/basic_string.tcc:
(_M_replace_dispatch()): string temporary now
That was fast :)
I’ll check the changelog for future reference.
Thanks,
Nina
On Tue, 14 May 2019 at 16:50, Jonathan Wakely wrote:
> On 14/05/19 15:43 +0100, Nina Dinka Ranns wrote:
> >Tested on Linux x86_64
> >nonesuch is insufficiently useless (lwg2996)
> >
> >2
Tested on Linux x86_64
nonesuch is insufficiently useless (lwg2996)
2019-05-14 Nina Dinka Ranns
nonesuch is insufficiently useless (lwg2996)
* include/std/type_traits
struct __nonesuch: added private base class to make __nonesuch
not an aggregate and removed deleted
Tested on Linux x86_64
Inconsistency wrt Allocators in basic_string assignment vs.
basic_string::assign (LWG2579)
2019-05-09 Nina Dinka Ranns
Inconsistency wrt Allocators in basic_string assignment vs.
basic_string::assign (LWG2579)
* include/bits/basic_string.h
On Tue, 7 May 2019 at 12:22, Jonathan Wakely wrote:
>
> I can remove that #if and test and commit the result for you though,
> no need for another revision of the patch.
Thanks ! :)
Best,
Nina
ic_string&&) as it's still technically
always resulting in an allocator from the first parameter.
2019-05-01 Nina Dinka Ranns
Make stateful allocator propagation more consistent
foroperator+(basic_string) (P1165R1)
* include/bits/basic_string.h:
(operator+(b
Tested on Linux x86_64
Make stateful allocator propagation more consistent for
operator+(basic_string) (P1165R1)
2019-05-01 Nina Dinka Ranns
Make stateful allocator propagation more consistent for
operator+(basic_string) (P1165R1)
* include/bits/basic_string.tcc
noted, thanks :)
Best,
Nina
On Sun, 28 Apr 2019 at 22:46, Jonathan Wakely wrote:
>
> On 28/04/19 22:44 +0100, Jonathan Wakely wrote:
> >On 29/04/19 00:18 +0300, Ville Voutilainen wrote:
> >>On Wed, 24 Apr 2019 at 14:53, Jonathan Wakely wrote:
> >>>
> >>
On Tue, 23 Apr 2019 at 21:28, Jonathan Wakely wrote:
>
> On 23/04/19 18:43 +0100, Nina Dinka Ranns wrote:
> >On Thu, 18 Apr 2019 at 21:35, Jonathan Wakely wrote:
> >>
> >> On 16/04/19 17:59 +0100, Nina Dinka Ranns wrote:
> >> >On Tue, 16
On Thu, 18 Apr 2019 at 21:35, Jonathan Wakely wrote:
>
> On 16/04/19 17:59 +0100, Nina Dinka Ranns wrote:
> >On Tue, 16 Apr 2019 at 15:18, Jonathan Wakely wrote:
> >>
> >> On 16/04/19 14:08 +0100, Nina Dinka Ranns wrote:
> >> >Tested on Linux-PPC64
&g
On Tue, 16 Apr 2019 at 15:18, Jonathan Wakely wrote:
>
> On 16/04/19 14:08 +0100, Nina Dinka Ranns wrote:
> >Tested on Linux-PPC64
> >Adding noexcept-specification on tuple constructors (LWG 2899)
>
> Thanks, Nina!
>
> This looks great, although as I think Ville has
Tested on Linux-PPC64
Adding noexcept-specification on tuple constructors (LWG 2899)
2019-04-13 Nina Dinka Ranns
Adding noexcept-specification on tuple constructors (LWG 2899)
* libstdc++-v3/include/std/tuple:
(tuple()): Add noexcept-specification.
(tuple(const
Comments addressed. Please find the new diff attached to this e-mail.
Changelog after review comments :
2017-02-18 Dinka Ranns
C++17 GB50 resolution
* include/std/chrono:
(duration::operator++()): Add _GLIBCXX17_CONSTEXPR.
(duration::operator++(int)): Likewise
Tested on Linux-x64
Implementation of resolution for C++17 GB50
2017-02-12 Dinka Ranns
C++17 GB50 resolution
* libstdc++-v3/include/std/chrono:
(duration::operator++()): Add constexpr.
(duration::operator++(int)): Likewise
(duration::operator
29 matches
Mail list logo
