On Thu, Jul 6, 2023 at 8:53 PM Thomas Schwinge wrote:
>
> Hi!
>
> On 2014-09-01T21:56:28-0400, tsaund...@mozilla.com wrote:
> > [...] this part [...]
>
> ... became commit b086d5308de0d25444243f482f2f3d1dfd3a9a62
> (Subversion r214834), which added GGC support to &#
Hi!
On 2014-09-01T21:56:28-0400, tsaund...@mozilla.com wrote:
> [...] this part [...]
... became commit b086d5308de0d25444243f482f2f3d1dfd3a9a62
(Subversion r214834), which added GGC support to 'hash_map', 'hash_set',
and converted to those a number of 'htab&#x
Hi,
This patch refactors the ImportVisitor to cache the generated result
decl in a hash_map. Originally, these were cached in the front-end AST
node field `isym'. However, this field is soon to be removed.
Bootstrapped and regression tested on x86_64-linux-gnu/m32/mx32, and
committ
On Tue, Dec 7, 2021 at 12:10 PM Matthias Kretz wrote:
>
> On Tuesday, 7 December 2021 08:43:56 CET Richard Biener wrote:
> > On Mon, Dec 6, 2021 at 11:47 AM Matthias Kretz wrote:
> > > While reading the hash_map code I noticed this inconsistency. Bootstrapped
> > &g
On Tuesday, 7 December 2021 08:43:56 CET Richard Biener wrote:
> On Mon, Dec 6, 2021 at 11:47 AM Matthias Kretz wrote:
> > While reading the hash_map code I noticed this inconsistency. Bootstrapped
> > and regtested on x86_64. OK for trunk?
>
> I've inspected two users
s Kretz wrote:
> > >
> > > >
> > > >
> > > > While reading the hash_map code I noticed this inconsistency.
> > > > Bootstrapped and regtested on x86_64. OK for trunk?
> > >
> > >
> > >
> > > I've insp
On Tuesday, 7 December 2021 08:47:56 CET Richard Biener wrote:
> On Tue, Dec 7, 2021 at 8:43 AM Richard Biener
> wrote:
>
> >
> >
> > On Mon, Dec 6, 2021 at 11:47 AM Matthias Kretz wrote:
> >
> > >
> > >
> > > While reading the hash_m
On Tue, Dec 7, 2021 at 8:43 AM Richard Biener
wrote:
>
> On Mon, Dec 6, 2021 at 11:47 AM Matthias Kretz wrote:
> >
> > While reading the hash_map code I noticed this inconsistency. Bootstrapped
> > and
> > regtested on x86_64. OK for trunk?
>
> I've insp
On Mon, Dec 6, 2021 at 11:47 AM Matthias Kretz wrote:
>
> While reading the hash_map code I noticed this inconsistency. Bootstrapped and
> regtested on x86_64. OK for trunk?
I've inspected two users of said overload and they return true. Did you look
at the rest? I assume that
While reading the hash_map code I noticed this inconsistency. Bootstrapped and
regtested on x86_64. OK for trunk?
The hash_map::traverse overload taking a non-const Value pointer breaks
if the callback returns false. The other overload should behave the
same.
Signed-off-by: Matthias Kretz
> Hi,
>
> PR 103449 revealed that when I was storing result of one hash_map
> lookup into another entry in the hash_map, I was still accessing the
> entry in the table, which meanwhile could get reallocated, making the
> accesses invalid-after-free.
>
> Fixed with t
Hi,
PR 103449 revealed that when I was storing result of one hash_map
lookup into another entry in the hash_map, I was still accessing the
entry in the table, which meanwhile could get reallocated, making the
accesses invalid-after-free.
Fixed with the following, which also simplifies the return
M, Thomas Schwinge wrote:
>>>> So I'm trying to do some C++... ;-)
>>>>
>>>> Given:
>>>>
>>>> /* A map from SSA names or var decls to record fields. */
>>>> typedef hash_map field_map_t;
>>>>
>&
On 8/16/21 6:44 AM, Thomas Schwinge wrote:
> > >> [...], to document the current behavior, I propose to
> > >> "Add more self-tests for 'hash_map' with Value type with non-trivial
> > >> constructor/destructor", see attached. OK to push to m
ior, I propose to
>> >> "Add more self-tests for 'hash_map' with Value type with non-trivial
>> >> constructor/destructor", see attached. OK to push to master branch?
>> >> (Also cherry-pick into release branches, eventually?)
>> >
On Tue, Aug 17, 2021 at 8:40 AM Thomas Schwinge wrote:
>
> Hi!
>
> On 2021-08-16T14:10:00-0600, Martin Sebor wrote:
> > On 8/16/21 6:44 AM, Thomas Schwinge wrote:
> >> [...], to document the current behavior, I propose to
> >> "Add more self-tests for &#
Hi!
On 2021-08-16T14:10:00-0600, Martin Sebor wrote:
> On 8/16/21 6:44 AM, Thomas Schwinge wrote:
>> [...], to document the current behavior, I propose to
>> "Add more self-tests for 'hash_map' with Value type with non-trivial
>> constructor/destructor&q
On 8/16/21 6:44 AM, Thomas Schwinge wrote:
Hi!
On 2021-08-12T17:15:44-0600, Martin Sebor via Gcc wrote:
On 8/6/21 10:57 AM, Thomas Schwinge wrote:
So I'm trying to do some C++... ;-)
Given:
/* A map from SSA names or var decls to record fields. */
typedef hash_map field_
Hi!
On 2021-08-12T17:15:44-0600, Martin Sebor via Gcc wrote:
> On 8/6/21 10:57 AM, Thomas Schwinge wrote:
>> So I'm trying to do some C++... ;-)
>>
>> Given:
>>
>> /* A map from SSA names or var decls to record fields. */
>> typedef
On 9/3/20 4:20 AM, Jakub Jelinek wrote:
Hi!
The recent libstdc++ changes caused lots of libstdc++-v3 tests FAILs
on i686-linux, all of them in the same spot during constexpr evaluation
of a recursive _S_gcd call.
The problem is yet another hash_map that used the default hasing of
tree keys
Hi!
The recent libstdc++ changes caused lots of libstdc++-v3 tests FAILs
on i686-linux, all of them in the same spot during constexpr evaluation
of a recursive _S_gcd call.
The problem is yet another hash_map that used the default hasing of
tree keys through pointer hashing which is preserved
On Sat, 14 Mar 2020, Jakub Jelinek wrote:
> Hi!
>
> On the following testcase, if there is ASLR, the compiler generates
> different code each time (out of 1000 invocations 994 unique assembler
> contents). The problem is that undistribute_bitref_for_vector uses
> a ha
Hi!
On the following testcase, if there is ASLR, the compiler generates
different code each time (out of 1000 invocations 994 unique assembler
contents). The problem is that undistribute_bitref_for_vector uses
a hash_map from a tree (SSA_NAME) to a vector and such a hash_map is
by default doing
_step_for_index (congruence_class
> *cls,
> 3136unsigned int index)
> 3137 {
> 3138hash_map split_map;
> 3139
> 3140for (unsigned int i = 0; i < cls->members.length (); i++)
> 3141 {
> 314
if a class CLS used as INDEXth splits any congruence classes.
3132 Bitmap stack BMSTACK is used for bitmap allocation. */
3133
3134 void
3135 sem_item_optimizer::do_congruence_step_for_index (congruence_class *cls,
3136uns
m_item_optimizer::build_graph): Pass m_references
> to ::add_reference.
> (sem_item_optimizer::verify_classes): Remove usage of dead
> vectors.
> (sem_item_optimizer::traverse_congruence_split): Return true
> when a class is split.
> (sem_item_optimiz
to ::add_reference.
(sem_item_optimizer::verify_classes): Remove usage of dead
vectors.
(sem_item_optimizer::traverse_congruence_split): Return true
when a class is split.
(sem_item_optimizer::do_congruence_step_for_index): Use
hash_map for look up of (sem_i
On 2017.11.14 at 13:32 +0100, Richard Biener wrote:
> On Fri, Sep 15, 2017 at 11:45 PM, Jason Merrill wrote:
> > The hash_map interface is a lot more convenient than that of
> > hash_table for cases where it makes sense, but there hasn't been a way
> > to get the ggc_ca
On Fri, Sep 15, 2017 at 11:45 PM, Jason Merrill wrote:
> The hash_map interface is a lot more convenient than that of
> hash_table for cases where it makes sense, but there hasn't been a way
> to get the ggc_cache_remove behavior with a hash_map. In other words,
> not marking el
Ping.
On Fri, Sep 15, 2017 at 5:45 PM, Jason Merrill wrote:
> The hash_map interface is a lot more convenient than that of
> hash_table for cases where it makes sense, but there hasn't been a way
> to get the ggc_cache_remove behavior with a hash_map. In other words,
> not
The hash_map interface is a lot more convenient than that of
hash_table for cases where it makes sense, but there hasn't been a way
to get the ggc_cache_remove behavior with a hash_map. In other words,
not marking elements during the initial ggc marking phase, but maybe
marking them durin
The C++ delayed folding work wants to be able to clear out a hash_map,
and it's trivial to refer to the empty() function from the hash_table.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 760ba6617d6b7867692aba8c7494e8f08d6109aa
Author: Jason Merrill
Date: Fri Nov 13 09:38:32
Richard Sandiford writes:
> Richard Sandiford writes:
>> Rainer Orth writes:
>>> Richard Sandiford writes:
>>>
>>>> Rainer Orth writes:
>>>>> Jeff Law writes:
>>>>>
>>>>>> On 06/23/2015 08:57 AM, Richard S
Richard Sandiford writes:
> Rainer Orth writes:
>> Richard Sandiford writes:
>>
>>> Rainer Orth writes:
>>>> Jeff Law writes:
>>>>
>>>>> On 06/23/2015 08:57 AM, Richard Sandiford wrote:
>>>>>> At this point all
Rainer Orth writes:
> Richard Sandiford writes:
>
>> Rainer Orth writes:
>>> Jeff Law writes:
>>>
>>>> On 06/23/2015 08:57 AM, Richard Sandiford wrote:
>>>>> At this point all hash_map traits know what kind of key they're
>>&g
On 06/26/2015 04:37 PM, Rainer Orth wrote:
> /vol/gcc/src/hg/trunk/local/gcc/hash-map.h:173:8: note: template bool (* f)(tree_node*&, tree_node* const&, Arg)> void hash_map::traverse(Arg)
> const [with Arg = Arg; bool (* f)(typename Traits::key_type&, const Value&,
>
Richard Sandiford writes:
> Rainer Orth writes:
>> Jeff Law writes:
>>
>>> On 06/23/2015 08:57 AM, Richard Sandiford wrote:
>>>> At this point all hash_map traits know what kind of key they're
>>>> dealing with, so we can make that a traits
Rainer Orth writes:
> Jeff Law writes:
>
>> On 06/23/2015 08:57 AM, Richard Sandiford wrote:
>>> At this point all hash_map traits know what kind of key they're
>>> dealing with, so we can make that a traits typedef, like it is for
>>> hash_table trait
Jeff Law writes:
> On 06/23/2015 08:57 AM, Richard Sandiford wrote:
>> At this point all hash_map traits know what kind of key they're
>> dealing with, so we can make that a traits typedef, like it is for
>> hash_table traits. Then, if we make the default hash traits
On 06/23/2015 08:57 AM, Richard Sandiford wrote:
At this point all hash_map traits know what kind of key they're
dealing with, so we can make that a traits typedef, like it is for
hash_table traits. Then, if we make the default hash traits for
T be T, we can use hash_table-style traits a
On 06/23/2015 08:42 AM, Richard Sandiford wrote:
This patch defines a class that converts hash_table-style traits into
hash_map traits. It can be used as the default traits for all hash_maps
that don't specify their own traits (i.e. this patch does work on its own).
By the end of the s
At this point all hash_map traits know what kind of key they're
dealing with, so we can make that a traits typedef, like it is for
hash_table traits. Then, if we make the default hash traits for
T be T, we can use hash_table-style traits as the first template
parameter to hash_map, withou
This patch defines a class that converts hash_table-style traits into
hash_map traits. It can be used as the default traits for all hash_maps
that don't specify their own traits (i.e. this patch does work on its own).
By the end of the series this class replaces default_hashmap_traits.
Following on from: https://gcc.gnu.org/ml/gcc-patches/2015-06/msg01066.html
this series unifies the key hashing traits for hash_maps in all but one case
(which needs to use the values rather than keys to represent deleted and
empty entries).
It also consolidates the various tree, integer and strin
l compiler error: in relocate_ptrs, at ggc-common.c:435
--Alan
tsaund...@mozilla.com wrote:
From: Trevor Saunders
Hi,
There are still some issues to make this work really nicely, but this part is
probably good enough its worth reviewing.
For one thing you can't use ggc hash_map or set in fro
issues to make this work really nicely, but this part
>> > is
>> > probably good enough its worth reviewing.
>> >
>> > For one thing you can't use ggc hash_map or set in front ends with some
>> > types
>> > or gengtype will decide to p
d enough its worth reviewing.
> >
> > For one thing you can't use ggc hash_map or set in front ends with some
> > types
> > or gengtype will decide to put the overloads of the marking routines it
> > provides in a front end file instead of the one it choose b
On Tue, Sep 2, 2014 at 3:56 AM, wrote:
> From: Trevor Saunders
>
> Hi,
>
> There are still some issues to make this work really nicely, but this part is
> probably good enough its worth reviewing.
>
> For one thing you can't use ggc hash_map or set in front ends
/gcc.gnu.org/bugs.html> for instructions.
>
> FAIL: ./array-1.H -g (internal compiler error)
> FAIL: ./array-1.H -g (test for excess errors)
> Excess errors:
> ./array-1.H:4:2: internal compiler error: in relocate_ptrs, at
> ggc-common.c:435
>
> --Alan
>
> t
rror: in relocate_ptrs, at ggc-common.c:435
--Alan
tsaund...@mozilla.com wrote:
From: Trevor Saunders
Hi,
There are still some issues to make this work really nicely, but this part is
probably good enough its worth reviewing.
For one thing you can't use ggc hash_map or set in front ends
d enough its worth reviewing.
> >
> > For one thing you can't use ggc hash_map or set in front ends with some
> > types
> > or gengtype will decide to put the overloads of the marking routines it
> > provides in a front end file instead of the one it choose b
On Tue, Sep 2, 2014 at 3:56 AM, wrote:
> From: Trevor Saunders
>
> Hi,
>
> There are still some issues to make this work really nicely, but this part is
> probably good enough its worth reviewing.
>
> For one thing you can't use ggc hash_map or set in front ends
From: Trevor Saunders
Hi,
There are still some issues to make this work really nicely, but this part is
probably good enough its worth reviewing.
For one thing you can't use ggc hash_map or set in front ends with some types
or gengtype will decide to put the overloads of the marking rou
lto-streamer-out.c, lto-streamer.h, tree-affine.c, tree-affine.h,
> tree-predcom.c, tree-scalar-evolution.c, tree-ssa-loop-im.c,
> tree-ssa-loop-niter.c, tree-ssa.c, value-prof.c: Use hash_map instead
> of pointer_map.
>
> gcc/cp/
>
> *
-niter.c, tree-ssa.c, value-prof.c: Use hash_map instead
of pointer_map.
gcc/cp/
* cp-tree.h, pt.c: Use hash_map instead of pointer_map.
gcc/lto/
* lto-partition.c, lto.c: Use hash_map instead of pointer_map.
---
gcc/alias.c | 5 +--
gcc/cfgexpand.c
g 1, 2014 at 12:34 PM, wrote:
>>>>> From: Trevor Saunders
>>>>>
>>>>> Hi,
>>>>>
>>>>> This patch replaces a bunch of usage of pointer_map with hash_map. It
>>>>> also
>>>>> adds an overload to hash_m
r Saunders
> > > >
> > > > Hi,
> > > >
> > > > This patch replaces a bunch of usage of pointer_map with hash_map. It
> > > > also
> > > > adds an overload to hash_map::traverse that allows modifying the value,
> > > > and
On Sat, 2014-08-02 at 07:34 -0400, Trevor Saunders wrote:
> On Fri, Aug 01, 2014 at 12:52:08PM +0200, Richard Biener wrote:
> > On Fri, Aug 1, 2014 at 12:34 PM, wrote:
> > > From: Trevor Saunders
> > >
> > > Hi,
> > >
> > > This patch repla
On Fri, Aug 01, 2014 at 12:52:08PM +0200, Richard Biener wrote:
> On Fri, Aug 1, 2014 at 12:34 PM, wrote:
> > From: Trevor Saunders
> >
> > Hi,
> >
> > This patch replaces a bunch of usage of pointer_map with hash_map. It also
> > adds an overload to h
On Fri, Aug 1, 2014 at 12:34 PM, wrote:
> From: Trevor Saunders
>
> Hi,
>
> This patch replaces a bunch of usage of pointer_map with hash_map. It also
> adds an overload to hash_map::traverse that allows modifying the value, and a
> remove method.
>
> bootstrapped +
From: Trevor Saunders
Hi,
This patch replaces a bunch of usage of pointer_map with hash_map. It also
adds an overload to hash_map::traverse that allows modifying the value, and a
remove method.
bootstrapped + regtested on x86_64-unknown-linux-gnu, ok?
Trev
c-family/
* cilk.c: Use
On Tue, Jul 8, 2014 at 5:01 AM, wrote:
> From: Trevor Saunders
>
> Hi,
>
> just $subject
> bootstrapped + regtested on x86_64-unknown-linux-gnu, ok?
Ok.
Thanks,
Richard.
> Trev
>
> gcc/
>
> * graphite-htab.h: Use hash_map instead of hash_table.
>
From: Trevor Saunders
Hi,
just $subject
bootstrapped + regtested on x86_64-unknown-linux-gnu, ok?
Trev
gcc/
* graphite-htab.h: Use hash_map instead of hash_table.
* graphite-clast-to-gimple.c: Adjust.
* passes.c: Use hash_map instead of hash_table.
* sese.c
On 06/24/2014 09:31 PM, Richard Biener wrote:
On June 24, 2014 9:16:34 PM CEST, Trevor Saunders wrote:
On Tue, Jun 24, 2014 at 08:23:49PM +0200, Jan Hubicka wrote:
On 06/20/2014 12:52 PM, tsaund...@mozilla.com wrote:
From: Trevor Saunders
Hi,
This patch adds a hash_map class so we can
On June 24, 2014 9:16:34 PM CEST, Trevor Saunders wrote:
>On Tue, Jun 24, 2014 at 08:23:49PM +0200, Jan Hubicka wrote:
>> >
>> > On 06/20/2014 12:52 PM, tsaund...@mozilla.com wrote:
>> > >From: Trevor Saunders
>> > >
>> > >Hi,
>> &
On Tue, Jun 24, 2014 at 08:23:49PM +0200, Jan Hubicka wrote:
> >
> > On 06/20/2014 12:52 PM, tsaund...@mozilla.com wrote:
> > >From: Trevor Saunders
> > >
> > >Hi,
> > >
> > >This patch adds a hash_map class so we can consolidate the boi
>
> On 06/20/2014 12:52 PM, tsaund...@mozilla.com wrote:
> >From: Trevor Saunders
> >
> >Hi,
> >
> >This patch adds a hash_map class so we can consolidate the boiler plate
> >around
> >using hash_table as a map, it also allows us to get rid o
s
> >>>
> >>>Hi,
> >>>
> >>>This patch adds a hash_map class so we can consolidate the boiler plate
> >>>around
> >>>using hash_table as a map, it also allows us to get rid of pointer_map
> >>>which I
> >&g
On 06/24/2014 02:40 PM, Trevor Saunders wrote:
On Tue, Jun 24, 2014 at 02:29:53PM +0200, Martin Liška wrote:
On 06/20/2014 12:52 PM, tsaund...@mozilla.com wrote:
From: Trevor Saunders
Hi,
This patch adds a hash_map class so we can consolidate the boiler plate around
using hash_table as a
On Tue, Jun 24, 2014 at 02:29:53PM +0200, Martin Liška wrote:
>
> On 06/20/2014 12:52 PM, tsaund...@mozilla.com wrote:
> >From: Trevor Saunders
> >
> >Hi,
> >
> >This patch adds a hash_map class so we can consolidate the boiler plate
> >around
> >
On 06/20/2014 12:52 PM, tsaund...@mozilla.com wrote:
From: Trevor Saunders
Hi,
This patch adds a hash_map class so we can consolidate the boiler plate around
using hash_table as a map, it also allows us to get rid of pointer_map which I
do in this patch by converting its users to hash_map
On Fri, Jun 20, 2014 at 12:52 PM, wrote:
> From: Trevor Saunders
>
> Hi,
>
> This patch adds a hash_map class so we can consolidate the boiler plate around
> using hash_table as a map, it also allows us to get rid of pointer_map which I
> do in this patch by converting
From: Trevor Saunders
Hi,
This patch adds a hash_map class so we can consolidate the boiler plate around
using hash_table as a map, it also allows us to get rid of pointer_map which I
do in this patch by converting its users to hash_map.
bootstrapped + regtested without regression on x86_64
73 matches
Mail list logo
