viding some proper C++-esque wording, which I
> summarized to replace my original source code comment.
>
> >> > What happens if the dtor is deleted btw?
> >>
> >> If the destructor is deleted you have created an unusable type that
> >> cannot be stor
On Fri, 17 Sep 2021, 16:52 Thomas Schwinge, wrote:
> Hi!
>
> On 2021-09-17T15:03:18+0200, Richard Biener
> wrote:
> > On Fri, Sep 17, 2021 at 2:39 PM Jonathan Wakely
> wrote:
> >> On Fri, 17 Sept 2021 at 13:08, Richard Biener
> >> wrote:
> >> > On Fri, Sep 17, 2021 at 1:17 PM Thomas Schwinge <
ace my original source code comment.
>> > What happens if the dtor is deleted btw?
>>
>> If the destructor is deleted you have created an unusable type that
>> cannot be stored in containers. It can only be created using new, and
>> then never destroyed. If you play stu
On Fri, Sep 17, 2021 at 2:39 PM Jonathan Wakely wrote:
>
> On Fri, 17 Sept 2021 at 13:08, Richard Biener
> wrote:
> >
> > On Fri, Sep 17, 2021 at 1:17 PM Thomas Schwinge
> > wrote:
> > >
> > > Hi!
> > >
> > > On 2021-09-10T10:00:25+0200, I wrote:
> > > > On 2021-09-01T19:31:19-0600, Martin Sebo
On Fri, 17 Sept 2021 at 13:08, Richard Biener
wrote:
>
> On Fri, Sep 17, 2021 at 1:17 PM Thomas Schwinge
> wrote:
> >
> > Hi!
> >
> > On 2021-09-10T10:00:25+0200, I wrote:
> > > On 2021-09-01T19:31:19-0600, Martin Sebor via Gcc-patches
> > > wrote:
> > >> On 8/30/21 4:46 AM, Thomas Schwinge wr
case is novel in some way, chances
> >>>>>> are it might not work as intended in all circumstances.
> >>>>>>
> >>>>>> I've wrestled with hash_map a number of times. A use case that's
> >>>>>> close to y
hat's
>>>>>> close to yours (i.e., a non-trivial value type) is in cp/parser.c:
>>>>>> see class_to_loc_map_t.
>>>>>
>>>>> Indeed, at the time you sent this email, I already had started looking
>>>>> into that one! (T
; close to yours (i.e., a non-trivial value type) is in cp/parser.c:
>>>>> see class_to_loc_map_t.
>>>>
>>>> Indeed, at the time you sent this email, I already had started looking
>>>> into that one! (The Fortran test cases that I originally analy
s leak memory at present. :-| (See attached commit log for
details for one example.)
(Attached "Fix 'hash_table::expand' to destruct stale Value objects"
again.)
To that effect, to document the current behavior, I propose to
"Add more sel
inal problem, does address the current 'class2loc'
>> memory leak in 'cp/parser.c' (see commit log for one example), and
>> adjusts the new
>> 'gcc/hash-map-tests.c:test_map_of_type_with_ctor_and_dtor_expand' test
>> case such that number of constru
10 matches
Mail list logo
