On 12/12/23 12:50, Jason Merrill wrote:
On 12/12/23 10:24, Jason Merrill wrote:
On 12/12/23 06:15, Jakub Jelinek wrote:
On Tue, Dec 12, 2023 at 02:13:43PM +0300, Alexander Monakov wrote:
On Tue, 12 Dec 2023, Jakub Jelinek wrote:
On Mon, Dec 11, 2023 at 05:00:50PM -0500, Jason Merrill
On 12/12/23 10:24, Jason Merrill wrote:
On 12/12/23 06:15, Jakub Jelinek wrote:
On Tue, Dec 12, 2023 at 02:13:43PM +0300, Alexander Monakov wrote:
On Tue, 12 Dec 2023, Jakub Jelinek wrote:
On Mon, Dec 11, 2023 at 05:00:50PM -0500, Jason Merrill wrote:
In discussion of PR71093 it came up
On 12/12/23 06:15, Jakub Jelinek wrote:
On Tue, Dec 12, 2023 at 02:13:43PM +0300, Alexander Monakov wrote:
On Tue, 12 Dec 2023, Jakub Jelinek wrote:
On Mon, Dec 11, 2023 at 05:00:50PM -0500, Jason Merrill wrote:
In discussion of PR71093 it came up that more clobber_kind options would be
On Tue, Dec 12, 2023 at 02:13:43PM +0300, Alexander Monakov wrote:
>
>
> On Tue, 12 Dec 2023, Jakub Jelinek wrote:
>
> > On Mon, Dec 11, 2023 at 05:00:50PM -0500, Jason Merrill wrote:
> > > In discussion of PR71093 it came up that more clobber_kind options would
> > > be
> > > useful within
On Tue, 12 Dec 2023, Jakub Jelinek wrote:
> On Mon, Dec 11, 2023 at 05:00:50PM -0500, Jason Merrill wrote:
> > In discussion of PR71093 it came up that more clobber_kind options would be
> > useful within the C++ front-end.
> >
> > gcc/ChangeLog:
> >
> > * tree-core.h (enum
On Mon, Dec 11, 2023 at 05:00:50PM -0500, Jason Merrill wrote:
> In discussion of PR71093 it came up that more clobber_kind options would be
> useful within the C++ front-end.
>
> gcc/ChangeLog:
>
> * tree-core.h (enum clobber_kind): Rename CLOBBER_EOL to
> CLOBBER_STORAGE_END. Add
On Mon, Dec 11, 2023 at 05:00:50PM -0500, Jason Merrill wrote:
> On 12/11/23 14:21, Marek Polacek wrote:
> > On Mon, Dec 11, 2023 at 08:17:22PM +0100, Richard Biener wrote:
> > >
> > >
> > > > Am 11.12.2023 um 20:12 schrieb Jason Merrill :
> > > > Maybe something like this? Or shall we write
On 12/11/23 14:21, Marek Polacek wrote:
On Mon, Dec 11, 2023 at 08:17:22PM +0100, Richard Biener wrote:
Am 11.12.2023 um 20:12 schrieb Jason Merrill :
Maybe something like this? Or shall we write out the names like
CLOBBER_OBJECT_START, CLOBBER_STORAGE_END, etc?
Yeah, the abbreviations
On Mon, Dec 11, 2023 at 08:17:22PM +0100, Richard Biener wrote:
>
>
> > Am 11.12.2023 um 20:12 schrieb Jason Merrill :
> > Maybe something like this? Or shall we write out the names like
> > CLOBBER_OBJECT_START, CLOBBER_STORAGE_END, etc?
>
> Yeah, the abbreviations look a bit confusing so
> Am 11.12.2023 um 20:12 schrieb Jason Merrill :
>
> On 12/11/23 03:02, Richard Biener wrote:
>>> On Sun, 10 Dec 2023, Jason Merrill wrote:
>>> On 12/10/23 05:22, Richard Biener wrote:
> Am 09.12.2023 um 21:13 schrieb Jason Merrill :
>
> On 11/2/23 21:18, Nathaniel Shead wrote:
On 12/11/23 03:02, Richard Biener wrote:
On Sun, 10 Dec 2023, Jason Merrill wrote:
On 12/10/23 05:22, Richard Biener wrote:
Am 09.12.2023 um 21:13 schrieb Jason Merrill :
On 11/2/23 21:18, Nathaniel Shead wrote:
Bootstrapped and regtested on x86-64_pc_linux_gnu.
I'm not entirely sure if
On Sun, 10 Dec 2023, Jason Merrill wrote:
> On 12/10/23 05:22, Richard Biener wrote:
> >> Am 09.12.2023 um 21:13 schrieb Jason Merrill :
> >>
> >> On 11/2/23 21:18, Nathaniel Shead wrote:
> >>> Bootstrapped and regtested on x86-64_pc_linux_gnu.
> >>> I'm not entirely sure if the change I made to
On 12/10/23 05:22, Richard Biener wrote:
Am 09.12.2023 um 21:13 schrieb Jason Merrill :
On 11/2/23 21:18, Nathaniel Shead wrote:
Bootstrapped and regtested on x86-64_pc_linux_gnu.
I'm not entirely sure if the change I made to have destructors clobber with
CLOBBER_EOL instead of CLOBBER_UNDEF
> Am 10.12.2023 um 12:21 schrieb Alexander Monakov :
>
>
> On Sun, 10 Dec 2023, Richard Biener wrote:
>
>>> It seems wrong to me: CLOBBER_EOL is documented to mean that the storage is
>>> expiring at that point as well, which a (pseudo-)destructor does not imply;
>>> it's perfectly valid to
On Sun, 10 Dec 2023, Richard Biener wrote:
> > It seems wrong to me: CLOBBER_EOL is documented to mean that the storage is
> > expiring at that point as well, which a (pseudo-)destructor does not imply;
> > it's perfectly valid to destroy an object and then create another in the
> > same
> Am 09.12.2023 um 21:13 schrieb Jason Merrill :
>
> On 11/2/23 21:18, Nathaniel Shead wrote:
>> Bootstrapped and regtested on x86-64_pc_linux_gnu.
>> I'm not entirely sure if the change I made to have destructors clobber with
>> CLOBBER_EOL instead of CLOBBER_UNDEF is appropriate, but
On 11/2/23 21:18, Nathaniel Shead wrote:
Bootstrapped and regtested on x86-64_pc_linux_gnu.
I'm not entirely sure if the change I made to have destructors clobber with
CLOBBER_EOL instead of CLOBBER_UNDEF is appropriate, but nothing seemed to have
broken by doing this and I wasn't able to find
Ping for https://gcc.gnu.org/pipermail/gcc-patches/2023-November/635071.html.
On Fri, Nov 03, 2023 at 12:34:06PM +1100, Nathaniel Shead wrote:
> Oh, this also fixes PR102284 and its other linked PRs (apart from
> fields); I forgot to note that in the commit.
>
> On Fri, Nov 03, 2023 at
Oh, this also fixes PR102284 and its other linked PRs (apart from
fields); I forgot to note that in the commit.
On Fri, Nov 03, 2023 at 12:18:29PM +1100, Nathaniel Shead wrote:
> Bootstrapped and regtested on x86-64_pc_linux_gnu.
>
> I'm not entirely sure if the change I made to have destructors
Bootstrapped and regtested on x86-64_pc_linux_gnu.
I'm not entirely sure if the change I made to have destructors clobber with
CLOBBER_EOL instead of CLOBBER_UNDEF is appropriate, but nothing seemed to have
broken by doing this and I wasn't able to find anything else that really
depended on this
20 matches
Mail list logo
