Hi Harald,
If you will excuse the British cultural reference, that's a Norwegian Blue
alright! Good spot.
OK for mainline.
Thanks
Paul
On Sat, 25 Mar 2023 at 19:13, Harald Anlauf via Fortran
wrote:
> Dear all,
>
> I've committed the attached patch from the PR that removes
> a dead code snip
This patch gets std::is_void to dispatch to new built-in trait __is_void.
libstdc++-v3/ChangeLog:
* include/std/type_traits (is_void): Use __is_void built-in trait.
Signed-off-by: Ken Matsui
---
libstdc++-v3/include/std/type_traits | 7 +++
1 file changed, 7 insertions(+)
diff --g
This patch implements built-in trait for std::is_void.
gcc/cp/ChangeLog:
* cp-trait.def: Define __is_void.
* constraint.cc (diagnose_trait_expr): Handle CPTK_IS_VOID.
* semantics.cc (trait_expr_value): Likewise.
(finish_trait_expr): Likewise.
gcc/testsuite/ChangeL
This patch implements built-in trait for std::is_function.
gcc/cp/ChangeLog:
* cp-trait.def: Define __is_function.
* constraint.cc (diagnose_trait_expr): Handle CPTK_IS_FUNCTION.
* semantics.cc (trait_expr_value): Likewise.
(finish_trait_expr): Likewise.
gcc/tests
This patch gets std::is_object to dispatch to new built-in traits,
__is_function, __is_reference, and __is_void.
libstdc++-v3/ChangeLog:
* include/std/type_traits (is_object): Use new built-in traits,
__is_function, __is_reference, and __is_void.
Signed-off-by: Ken Matsui
---
l
This patch gets std::is_function to dispatch to new built-in trait
__is_function.
libstdc++-v3/ChangeLog:
* include/std/type_traits (is_function): Use __is_function built-in
trait.
Signed-off-by: Ken Matsui
---
libstdc++-v3/include/std/type_traits | 7 +++
1 file changed, 7
This patch uses std::is_void in helper_function.h instead of __is_void defined
in cpp_type_traits.h to avoid conflicts with the __is_void built-in trait to
be implemented.
libstdc++-v3/ChangeLog:
* include/debug/helper_function.h (_DiffTraits): Use std::void
instead of __is_void d
This patch renames __is_void defined in pr46567.C to is_void to
avoid conflicts with the __is_void built-in trait to be implemented.
gcc/testsuite/ChangeLog:
* g++.dg/tm/pr46567.C (__is_void): Rename to ...
(is_void): ... this.
Signed-off-by: Ken Matsui
---
gcc/testsuit
This patch implements built-in trait for std::is_reference.
gcc/cp/ChangeLog:
* cp-trait.def: Define __is_reference.
* constraint.cc (diagnose_trait_expr): Handle CPTK_IS_REFERENCE.
* semantics.cc (trait_expr_value): Likewise.
(finish_trait_expr): Likewise.
gcc/te
This patch removes unused __is_void defined in cpp_type_traits.h
libstdc++-v3/ChangeLog:
* include/bits/cpp_type_traits.h (__is_void): Remove unused __is_void.
Signed-off-by: Ken Matsui
---
libstdc++-v3/include/bits/cpp_type_traits.h | 15 ---
1 file changed, 15 deletions(-
This patch gets std::is_reference to dispatch to new built-in trait
__is_reference.
libstdc++-v3/ChangeLog:
* include/std/type_traits (is_reference): Use __is_reference built-in
trait.
Signed-off-by: Ken Matsui
---
libstdc++-v3/include/std/type_traits | 7 +++
1 file change
Hi,
This patch series gets std::is_object to dispatch to built-in traits and
implements the following built-in traits, on which std::object depends.
* __is_reference
* __is_function
* __is_void
std::is_object was depending on them with disjunction and negation.
__not_<__
On 3/23/23 20:28, Palmer Dabbelt wrote:
On Thu, 23 Mar 2023 16:18:20 PDT (-0700), jeffreya...@gmail.com wrote:
OK. We don't have a hard need there, but it'll make life easier so I'm
happy to just treat it like a real shipping branch if you guys are going
to as well.
I'd planned to use i
On Mar 25, 2023, at 1:33 AM, Alexandre Oliva wrote:
>
> Explicitly enable altivec if it's supported. vect_int tests for
> powerpc_altivec_ok, but without the explicit option, if altivec is not
> enabled by default, we end up expecting vectorization that doesn't
> occur.
>
> Regstrapped on ppc64
Dear all,
I've committed the attached patch from the PR that removes
a dead code snippet, see discussion.
Regtested originally by Tobias, and reconfirmed on
x86_64-pc-linux-gnu.
Pushed as r13-6862-gb5fce899dbbd72 .
Thanks,
Harald
From b5fce899dbbd7246d003209b2fe3b04f8738 Mon Sep 17 00:00:0
On 3/24/23 08:11, pan2.li--- via Gcc-patches wrote:
From: Pan Li
Fix the bug of the incorrect code generation for the
below code sample.
typedef unsigned short __attribute__((__vector_size__ (32))) V;
typedef unsigned short u16;
void
foo (V m, u16 *ret)
{
V v = 6 > ((V) { 2049, 8 } & m)
On 3/23/23 20:45, juzhe.zh...@rivai.ai wrote:
Sounds like you are looking at redundant extension problem in RISC-V port.
This is the issue I want to fix but I don't find the time to do that.
My first impression is that we need to fix redundant extension in "ree"
PASS.
I am not sure.
It's ac
On 3/24/23 15:34, Peter Bergner wrote:
On 3/23/23 6:12 PM, Jeff Law via Gcc-patches wrote:
Is there a reason why REE cannot see that our (reg:QI 4) is a param register
and thus due to our ABI, already correctly sign/zero extended?
I don't think REE has ever considered exploiting ABI constra
This series of patches is mainly used to support the control flow
integrity protection of the linux kernel [1], which is similar to
-fsanitize=kcfi in clang 16.0 [2,3].
Any suggestion please let me know :).
Thanks, Dan.
[1]
https://lore.kernel.org/all/20220908215504.3686827-1-samitolva...@googl
The KCFI sanitizer enabled with -fsanitize=kcfi implements a forward
edge control flow integrity scheme for indirect calls, similar to
-fsanitize=kcfi [1] in llvm.
At compile time, it appends a uniform type identifier before the
first instruction of each function and inserts check code before
each
Based on Sami's patch[1], this patch makes the corresponding kernel
configuration of CFI available when compiling the kernel with the gcc[2].
The code after enabling cfi (with -fsanitize=kcfi,
-fpatchable-function-entry=3,1) is as follows:
int (*p)(void);
int func (int)
{
p();
}
__kcfi_f
In the AArch64 platform, typeid can be directly inserted in front
of the function header (offset is patch_area_entry + 4), it should
be assumed that patch_area_entry is the same for all functions.
For all functions that will not be called indirectly, insert the
reserved RESERVED_CFI_TYPEID (0x0) a
32-bit sanitize_code can no longer accommodate new options,
extending it to 64-bit.
Signed-off-by: Dan Li
gcc/ChangeLog:
PR c/102768
* asan.h (sanitize_flags_p): Promote to uint64_t.
* common.opt: Likewise.
* dwarf2asm.cc (dw2_output_indirect_constant_1): Likewis
From: yes
Fix the bug of the incorrect code generation for the
below code sample.
typedef unsigned short __attribute__((__vector_size__ (32))) V;
typedef unsigned short u16;
void
foo (V m, u16 *ret)
{
V v = 6 > ((V) { 2049, 8 } & m);
*ret = v[0]; // + a + b + c + d;
}
Before this patch.
ad
Hi!
On the following testcase we emit notes in
maybe_inform_about_fndecl_for_bogus_argument_init
despite no warning/error being printed before it.
This is for the extended floating point type conversions where pedwarn
is used, and complained is used there for 2 different purposes,
one is whether a
Hi!
In the following testcase, we predict baz to have cold
entry regardless of the user supplied attribute (as it call
unconditionally a cold function), but still issue
a -Wsuggest-attribute=cold warning despite it having that attribute
already.
The following patch avoids that.
Bootstrapped/regt
Explicitly enable altivec if it's supported. vect_int tests for
powerpc_altivec_ok, but without the explicit option, if altivec is not
enabled by default, we end up expecting vectorization that doesn't
occur.
Regstrapped on ppc64-linux-gnu. Also tested with ppc64-vxworks7r2
(gcc-12). Ok to in
Ping https://gcc.gnu.org/pipermail/gcc-patches/2022-February/590958.html
From: Haochen Gui
This patch corrects the match pattern in pr56605.c. The former pattern
is wrong and test case fails with GCC11. It should match following
insn on each subtarget after mode promotion is disabled. The patc
When long double is 64-bit wide, as on vxworks, the rs6000 backend
defines neither the __ibm128 type nor the __SIZEOF_IBM128__ macro, but
pr99708.c expected both to be always defined. Adjust the test to
match the implementation.
Regstrapped on ppc64-linux-gnu. Also tested with ppc64-vxworks7r2
The first loop in main gets stores "vectorized" on powerpc into
full-word stores, even without any vector instruction support, so the
test's expectation of no loop vectorization is not met.
Regstrapped on ppc64-linux-gnu. Also tested with ppc64-vxworks7r2
(gcc-12). Ok to install?
for gcc/te
30 matches
Mail list logo