The SINGLE_BIT_MASK_OPERAND() is overly restrictive, triggering for
bits above 31 only (to side-step any issues with the negative SImode
value 0x8000). This moves the special handling of this SImode
value (i.e. the check for -2147483648) to riscv.cc and relaxes the
SINGLE_BIT_MASK_OPERAND() te
On Tue, May 24, 2022 at 3:57 PM Philipp Tomsich
wrote:
>
> The SINGLE_BIT_MASK_OPERAND() is overly restrictive, triggering for
> bits above 31 only (to side-step any issues with the negative SImode
> value 0x8000). This moves the special handling of this SImode
> value (i.e. the check for -21
On 7/22/21 15:41, Christoph Muellner via Gcc-patches wrote:
This patch enables the overlap-by-pieces feature of the by-pieces
infrastructure for inlining builtins in case the target has set
riscv_slow_unaligned_access_p to false.
An example to demonstrate the effect for targets with fast unal
On Tue, 24 May 2022 17:55:24 PDT (-0700), Vineet Gupta wrote:
On 7/22/21 15:41, Christoph Muellner via Gcc-patches wrote:
This patch enables the overlap-by-pieces feature of the by-pieces
infrastructure for inlining builtins in case the target has set
riscv_slow_unaligned_access_p to false.
A
On 5/24/22 18:32, Palmer Dabbelt wrote:
Ping, IMO this needs to be (re)considered for trunk.
This goes really nicely with riscv_slow_unaligned_access_p==false, to
elide the unrolled tail copies for trailer word/sword/byte accesses.
@Kito, @Palmer ? Just from codegen pov this seems to be a no
On Tue, 24 May 2022 18:36:27 PDT (-0700), Vineet Gupta wrote:
On 5/24/22 18:32, Palmer Dabbelt wrote:
Ping, IMO this needs to be (re)considered for trunk.
This goes really nicely with riscv_slow_unaligned_access_p==false, to
elide the unrolled tail copies for trailer word/sword/byte accesses.
Hello,
two weeks ago I submitted the second version of the patch PR105387 for the bug
105387. Now I added a pointer-to-member exception test just to make sure that
it doesn't break in case RTTI is enabled. The test is disabled if RTTI is
disabled. I didn't receive any feedback so far regarding
On Mon, May 23, 2022 at 3:32 PM David Malcolm via Gcc-patches
wrote:
>
> With C++11 we can add "final" and "override" to the decls of vfuncs
> in derived classes, which documents to both human and automated readers
> of the code that a decl is intended to override a vfunc in a base class,
> and ca
Rigt now, mem_cost for separate mem alternative is 1 * frequency which
is pretty small and caused the unnecessary SSE spill in the PR, I've tried
to rework backend cost model, but RA still not happy with that(regress
somewhere else). I think the root cause of this is cost for separate 'm'
alternati
Here is the patch to fix just what is described in PR 105714.
libstdc++: [_Hashtable] Insert range of types convertible to
value_type PR 105714
Fix insertion of range of types convertible to value_type.
libstdc++-v3/ChangeLog:
PR libstdc++/105714
* include
On Wed, May 25, 2022 at 11:39 AM liuhongt via Gcc-patches
wrote:
>
> Rigt now, mem_cost for separate mem alternative is 1 * frequency which
> is pretty small and caused the unnecessary SSE spill in the PR, I've tried
> to rework backend cost model, but RA still not happy with that(regress
> somewh
Jiufu Guo via Gcc-patches writes:
Hi,
This patch is based on:
https://gcc.gnu.org/pipermail/gcc-patches/2022-May/594252.html.
Compare with previous patch, this patch refined the comment and
rename one function, and support case: "*p == 0xc001".
When checking eq/neq with a constant w
On May 24, 2022, Martin Liška wrote:
> Allways install limits.h and syslimits.h header files
> to include folder.
typo: s/Allways/Always/
I'm a little worried about this bit, too. limitx.h includes
"syslimits.h", mentioning it should be in the same directory. Perhaps
it could be left in inclu
101 - 113 of 113 matches
Mail list logo
