Re: pb_ds gp_hash_table resize strategy
On Fri, 21 Jun 2024, 02:28 CH HC via Gcc, wrote: > Hi there, > In libstdc++/ext/pb_ds , I noticed that the (automatic) resize function > for gp_hash_table does copy-and-destruct operations on old key-value pair > (from the line resize_no_store_hash_fn_imps.hpp:58). Meanwhile, > cc_hash_table simply moves the old pair as expected. > So for gp_hash_table, this strategy makes it impossible to have > non-copyable values, e.g. __gnu_pbds::gp_hash_table std::unique_ptr>. And there exists potential bugs for scenarios like, > keeping a gp_hash_table> and saving some iterators of > those lists elsewhere for quick access to specific elements in lists. > There could be some workarounds like using std::shared_ptr as value > type, but not so perfect. > I wonder if this is caused by some implementation difficulty or just a > small bug? > Yours, > chhc > Hi, this question would be more appropriate on the libstd...@gcc.gnu.org making list. I've Cc'd that list. Please take the gcc list out of any future replies, thanks. The pb_ds code was written pre-C++11 and not updated for move semantics. All that code is completely unmaintained and my preference would be to remove it completely.
SARIF support in GCC: wiki page and BZ keyword
I've create a wiki page to track our support for GCC: https://gcc.gnu.org/wiki/SARIF and a keyword "SARIF" in our bugzilla instance for bugs relating to it (see links on the above page). Dave
Re: Setting insn mnemonic partly automagically
Am 17.06.24 um 21:13 schrieb Stefan Schulze Frielinghaus via Gcc: Hi all, I'm trying to add an alternative to an existing insn foobar: (define_insn "foobar" [(set (match_operand ...) (match_operand ...))] "" "@ foo bar #") Since the asm output depends on the operands in a non-trivial way which isn't easily solved via iterators, I went for a general C function and came up with: (define_insn "foobar" [(set (match_operand ...) (match_operand ...))] "" "@ foo * return foobar_helper (operands[0], operands[1]); bar #" [(set_attr_alternative "mnemonic" [(const_string "foo") (const_string "specialcase") (const_string "bar") (const_string "unknown")])]) If there exist a lot of alternatives, then setting the mnemonic attribute like this feels repetitive and is error prone. Furthermore, if there exists no other insn with an output template containing foo/bar, then I would have to declare foo/bar via (define_attr "mnemonic" "...,foo,bar,..." (const_string "unknown")) which again is repetitive. Thus, I'm wondering if there exists a more elegant way to achieve this? Ultimately, I would like to set the mnemonic attribute only manually for the alternative which is implemented via C code and let the mnemonic attribute for the remaining alternatives be set automagically. Not sure whether this is supported? If all fails, I have another idea how to solve this by utilizing PRINT_OPERAND. However, now I'm curious whether my current attempt is feasible or not. Cheers, Stefan It's a bit unclear to me what you are trying to do, as you are not only adding an insn alternative, but also are adding insn attribute "mnemonic", which the original insn did not have. Also, it's unclear how PRINT_OPERAND would help with setting the attribute. Johann
gcc-13-20240621 is now available
Snapshot gcc-13-20240621 is now available on https://gcc.gnu.org/pub/gcc/snapshots/13-20240621/ and on various mirrors, see https://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 13 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch releases/gcc-13 revision c335e34ff89ec9aec1ba874dc5cece9c2303c906 You'll find: gcc-13-20240621.tar.xz Complete GCC SHA256=7b5637c3da9db0efaa9b74bcf57d6395d98ed3c991eabe97c32e8f994048fdcf SHA1=f6d9541d0f3632e4e1aa9b0f8679b4ac73f72c48 Diffs from 13-20240614 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-13 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: SARIF support in GCC: wiki page and BZ keyword
On Fri, Jun 21, 2024 at 12:12 PM David Malcolm via Gcc wrote: > > I've create a wiki page to track our support for GCC: > https://gcc.gnu.org/wiki/SARIF > > and a keyword "SARIF" in our bugzilla instance for bugs relating to it > (see links on the above page). > Hi, thanks for creating these. Since "SARIF" is a keyword, what component should bugs using it generally go under? Thanks, Eric > Dave >
