RFC: Formalization of the Intel assembly syntax (PR53929)

2024-01-17 Thread LIU Hao via Gcc
Hello, There hasn't been an solution to https://gcc.gnu.org/PR53929 since almost a dozen years ago, mostly due to compatibility with MASM. I was told that the ambiguity of Intel syntax should be classified as its own limitation and disrecommendation. Notwithstanding, I am proposing a permanen

Re: [Tree][Static Analyzer] Tree representing types and svalues type

2024-01-17 Thread David Malcolm via Gcc
On Wed, 2024-01-17 at 17:52 -0500, David Malcolm wrote: > On Tue, 2024-01-16 at 15:44 +0100, Pierrick Philippe wrote: > > Hi David, hi all, > > Hi Pierrick. > > > > > I was playing along with APIs from the Static Analyzer and > > encountered a > > segfault in gcc/tree.cc:5068 (i.e. in function b

Re: GCC GSoC 2024: Call for project ideas and mentors

2024-01-17 Thread David Malcolm via Gcc
On Mon, 2024-01-15 at 18:48 +0100, Martin Jambor wrote: > Hello, > > another year has passed, Google has announced there will be again > Google > Summer of Code (GsoC) in 2024 and the deadline for organizations to > apply is already approaching (February 6th).  I'd like to volunteer > to > be the

Re: [Tree][Static Analyzer] Tree representing types and svalues type

2024-01-17 Thread David Malcolm via Gcc
On Tue, 2024-01-16 at 15:44 +0100, Pierrick Philippe wrote: > Hi David, hi all, Hi Pierrick. > > I was playing along with APIs from the Static Analyzer and > encountered a > segfault in gcc/tree.cc:5068 (i.e. in function build2 and failure is > due > to a > gcc_assert call), after a call to > an

Re: [PATCH] libstdc++: hashtable: No need to update before begin node in _M_remove_bucket_begin

2024-01-17 Thread Jonathan Wakely via Gcc
On Wed, 17 Jan 2024, 08:14 Huanghui Nie via Gcc, wrote: > Thanks. Done. > And don't CC the main gcc@ list, that's not for patch discussion. And if you CC the right list, you don't need to CC the individual maintainers. Anyway, it's on the right list now so we'll review it there, thanks. > 20

Re: [PATCH] libstdc++: hashtable: No need to update before begin node in _M_remove_bucket_begin

2024-01-17 Thread Huanghui Nie via Gcc
Thanks. Done. 2024年1月17日(水) 12:39 Sam James : > > Huanghui Nie writes: > > > Hi. > > Please CC the libstdc++ LM for libstdc++ patches, per > > https://gcc.gnu.org/onlinedocs/libstdc++/manual/appendix_contributing.html#list.patches > . > > > [...] > >

[PATCH] libstdc++: hashtable: No need to update before begin node in _M_remove_bucket_begin

2024-01-17 Thread Huanghui Nie via Gcc
Hi. When I implemented a hash table with reference to the C++ STL, I found that when the hash table in the C++ STL deletes elements, if the first element deleted is the begin element, the before begin node is repeatedly assigned. This creates unnecessary performance overhead. First, let’s see th