[PATCH v2] [testsuite] add linkonly to dg-additional-sources [PR115295]
e/g++.dg/vect/simd-clone-3.cc
@@ -1,7 +1,7 @@
// { dg-require-effective-target vect_simd_clones }
// { dg-additional-options "-fopenmp-simd -fno-inline" }
// { dg-additional-options "-mavx" { target avx_runtime } }
-// { dg-additional-sources "simd-clone-2.cc" }
+// { dg-additional-sources "simd-clone-2.cc" linkonly }
#include "simd-clone-2.h"
diff --git a/gcc/testsuite/g++.dg/vect/simd-clone-5.cc
b/gcc/testsuite/g++.dg/vect/simd-clone-5.cc
index 07ec8a8079efc..aca64a03c3aa9 100644
--- a/gcc/testsuite/g++.dg/vect/simd-clone-5.cc
+++ b/gcc/testsuite/g++.dg/vect/simd-clone-5.cc
@@ -1,7 +1,7 @@
// { dg-require-effective-target vect_simd_clones }
// { dg-additional-options "-fopenmp-simd -fno-inline" }
// { dg-additional-options "-mavx" { target avx_runtime } }
-// { dg-additional-sources "simd-clone-4.cc" }
+// { dg-additional-sources "simd-clone-4.cc" linkonly }
#include "simd-clone-4.h"
diff --git a/gcc/testsuite/gcc.dg/vect/vect-simd-clone-10.c
b/gcc/testsuite/gcc.dg/vect/vect-simd-clone-10.c
index 009c849b7e7ea..06fbdef1da9c6 100644
--- a/gcc/testsuite/gcc.dg/vect/vect-simd-clone-10.c
+++ b/gcc/testsuite/gcc.dg/vect/vect-simd-clone-10.c
@@ -1,9 +1,7 @@
-/* Since this uses dg-additional-sources, need to specify `dg-do run` instead
of the default. */
-/* { dg-do run } */
/* { dg-require-effective-target vect_simd_clones } */
/* { dg-additional-options "-fopenmp-simd" } */
/* { dg-additional-options "-mavx" { target avx_runtime } } */
-/* { dg-additional-sources vect-simd-clone-10a.c } */
+/* { dg-additional-sources vect-simd-clone-10a.c linkonly } */
#include "tree-vect.h"
diff --git a/gcc/testsuite/gcc.dg/vect/vect-simd-clone-12.c
b/gcc/testsuite/gcc.dg/vect/vect-simd-clone-12.c
index 4699a3f3c8001..f640c8bc9dd8b 100644
--- a/gcc/testsuite/gcc.dg/vect/vect-simd-clone-12.c
+++ b/gcc/testsuite/gcc.dg/vect/vect-simd-clone-12.c
@@ -1,9 +1,7 @@
-/* Since this uses dg-additional-sources, need to specify `dg-do run` instead
of the default. */
-/* { dg-do run } */
/* { dg-require-effective-target vect_simd_clones } */
/* { dg-additional-options "-fopenmp-simd" } */
/* { dg-additional-options "-mavx" { target avx_runtime } } */
-/* { dg-additional-sources vect-simd-clone-12a.c } */
+/* { dg-additional-sources vect-simd-clone-12a.c linkonly } */
#include "vect-simd-clone-10.c"
diff --git a/gcc/testsuite/lib/gcc-defs.exp b/gcc/testsuite/lib/gcc-defs.exp
index cdca4c254d6ec..c6ec490f0092e 100644
--- a/gcc/testsuite/lib/gcc-defs.exp
+++ b/gcc/testsuite/lib/gcc-defs.exp
@@ -303,18 +303,26 @@ proc dg-additional-options { args } {
# main source file.
set additional_sources ""
+set additional_sources_omit_on_compile ""
set additional_sources_used ""
proc dg-additional-sources { args } {
global additional_sources
+global additional_sources_omit_on_compile
if { [llength $args] > 3 } {
error "[lindex $args 0]: too many arguments"
return
}
-if { [llength $args] >= 3 } {
- switch [dg-process-target [lindex $args 2]] {
+set target [lindex $args 2]
+if { [llength $args] >= 3 && [lindex $target 0] == "linkonly" } {
+ append additional_sources_omit_on_compile " [lindex $args 1]"
+ set target [lreplace $target 0 1]
+}
+
+if { [llength $args] >= 3 && $target != ""} {
+ switch [dg-process-target $target] {
"S" { append additional_sources " [lindex $args 1]" }
"N" { }
"F" { error "[lindex $args 0]: `xfail' not allowed here" }
@@ -407,16 +415,29 @@ proc dg-additional-files-options { options source dest
type } {
gcc_adjust_linker_flags
global additional_sources
+global additional_sources_omit_on_compile
global additional_sources_used
global additional_files
set to_download [list]
-if { $additional_sources == "" } then {
-} elseif { $type != "executable" && $dest != "" } then {
+if { $additional_sources_omit_on_compile != "" \
+&& $additional_sources != "" \
+&& $type != "executable" && $dest != "" } then {
+ set linkonly ""
foreach s $additional_sources {
- unsupported "$s: additional-source will not be used to build $dest"
+ foreach s2 $additional_sources_omit_on_compile {
+ if { $s == $s2 } {
+ unsupported "$s: additional-source will not be used to
build $dest"
+ set s ""
+ break
+ }
+ }
+ if { $s != "" } {
+ appe
[FYI] map packed field type to unpacked for debug info
We create a distinct type for each field in a packed record with a
gnu_size, but there is no distinct debug information for them. Use
the same unpacked type for debug information.
Regstrapped on x86_64-linux-gnu. Pre-approved by Eric. I'm checking it
in.
for gcc/ada/ChangeLog
* gcc-interface/decl.cc (gnat_to_gnu_field): Use unpacked type
as the debug type for packed fields.
for gcc/testsuite/ChangeLog
* gnat.dg/bias1.adb: Count occurrences of -7.*DW_AT_GNU_bias.
---
gcc/ada/gcc-interface/decl.cc |4
gcc/testsuite/gnat.dg/bias1.adb |3 ++-
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/gcc/ada/gcc-interface/decl.cc b/gcc/ada/gcc-interface/decl.cc
index 8b72c96c4396a..e97ff64a4805c 100644
--- a/gcc/ada/gcc-interface/decl.cc
+++ b/gcc/ada/gcc-interface/decl.cc
@@ -7786,6 +7786,7 @@ gnat_to_gnu_field (Entity_Id gnat_field, tree
gnu_record_type, int packed,
/* If a size is specified, adjust the field's type to it. */
if (gnu_size)
{
+ tree debug_field_type = gnu_field_type;
tree orig_field_type;
/* If the field's type is justified modular, we would need to remove
@@ -7844,6 +7845,9 @@ gnat_to_gnu_field (Entity_Id gnat_field, tree
gnu_record_type, int packed,
&& !DECL_P (TYPE_NAME (gnu_field_type)))
create_type_decl (TYPE_NAME (gnu_field_type), gnu_field_type, true,
debug_info_p, gnat_field);
+
+ if (debug_info_p && gnu_field_type != debug_field_type)
+ SET_TYPE_DEBUG_TYPE (gnu_field_type, debug_field_type);
}
/* Otherwise (or if there was an error), don't specify a position. */
diff --git a/gcc/testsuite/gnat.dg/bias1.adb b/gcc/testsuite/gnat.dg/bias1.adb
index 016a159b692da..d9a00a1aa4588 100644
--- a/gcc/testsuite/gnat.dg/bias1.adb
+++ b/gcc/testsuite/gnat.dg/bias1.adb
@@ -1,6 +1,7 @@
-- { dg-do compile }
-- { dg-options "-cargs -g -dA -gnatws -fgnat-encodings=gdb -margs" }
-- { dg-final { scan-assembler "DW_AT_GNU_bias" } }
+-- { dg-final { scan-assembler-times "-7.*DW_AT_GNU_bias" 1 } }
procedure Bias1 is
type Small is range -7 .. -4;
@@ -31,4 +32,4 @@ procedure Bias1 is
begin
null;
-end Bias1;
\ No newline at end of file
+end Bias1;
--
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
Free Software Activist GNU Toolchain Engineer
More tolerance and less prejudice are key for inclusion and diversity
Excluding neuro-others for not behaving ""normal"" is *not* inclusive
[PATCH] [testsuite] add linkonly to dg-additional-sources [PR115295]
ch s $additional_sources {
- unsupported "$s: additional-source will not be used to build $dest"
+ foreach s2 $additional_sources_omit_on_compile {
+ if { $s == $s2 } {
+ unsupported "$s: additional-source will not be used to
build $dest"
+ set s ""
+ break
+ }
+ }
+ if { $s != "" } {
+ append linkonly " $s"
+ }
}
- set additional_sources_used ""
- set additional_sources ""
+ set additional_sources "$linkonly"
+}
+if { $additional_sources == "" } then {
} else {
if [is_remote host] {
lappend options "additional_flags=$additional_sources"
--
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
Free Software Activist GNU Toolchain Engineer
More tolerance and less prejudice are key for inclusion and diversity
Excluding neuro-others for not behaving ""normal"" is *not* inclusive
[PATCH] [libstdc++] [testsuite] require cmath for c++23 cmath tests
Some c++23 tests fail on targets that don't satisfy dg-require-cmath,
because referenced math functions don't get declared in std. Add the
missing requirement.
Regstrapping on x86_64-linux-gnu. Already successfully tested with
gcc-13 on aarch64-rtems, where it avoids the errors that come up because
math.h doesn't meet the cmath requirements there. Ok to install?
for libstdc++-v3/ChangeLog
* testsuite/26_numerics/headers/cmath/constexpr_std_c++23.cc:
Require cmath.
* testsuite/26_numerics/headers/cmath/functions_std_c++23.cc:
Likewise.
* testsuite/26_numerics/headers/cmath/nextafter_std_c++23.cc:
Likewise.
---
.../headers/cmath/constexpr_std_c++23.cc |1 +
.../headers/cmath/functions_std_c++23.cc |1 +
.../26_numerics/headers/cmath/nextafter_c++23.cc |1 +
3 files changed, 3 insertions(+)
diff --git
a/libstdc++-v3/testsuite/26_numerics/headers/cmath/constexpr_std_c++23.cc
b/libstdc++-v3/testsuite/26_numerics/headers/cmath/constexpr_std_c++23.cc
index 0e3d112fe2e80..3c2377fd6987b 100644
--- a/libstdc++-v3/testsuite/26_numerics/headers/cmath/constexpr_std_c++23.cc
+++ b/libstdc++-v3/testsuite/26_numerics/headers/cmath/constexpr_std_c++23.cc
@@ -16,6 +16,7 @@
// <http://www.gnu.org/licenses/>.
// { dg-do link { target c++23 } }
+// { dg-require-cmath "" }
#include
#include
diff --git
a/libstdc++-v3/testsuite/26_numerics/headers/cmath/functions_std_c++23.cc
b/libstdc++-v3/testsuite/26_numerics/headers/cmath/functions_std_c++23.cc
index 000cebf364aaa..ea68ac5da7551 100644
--- a/libstdc++-v3/testsuite/26_numerics/headers/cmath/functions_std_c++23.cc
+++ b/libstdc++-v3/testsuite/26_numerics/headers/cmath/functions_std_c++23.cc
@@ -16,6 +16,7 @@
// <http://www.gnu.org/licenses/>.
// { dg-do link { target c++23 } }
+// { dg-require-cmath "" }
#include
#include
diff --git
a/libstdc++-v3/testsuite/26_numerics/headers/cmath/nextafter_c++23.cc
b/libstdc++-v3/testsuite/26_numerics/headers/cmath/nextafter_c++23.cc
index 7d7e10bd8aea3..91767d22cc3f2 100644
--- a/libstdc++-v3/testsuite/26_numerics/headers/cmath/nextafter_c++23.cc
+++ b/libstdc++-v3/testsuite/26_numerics/headers/cmath/nextafter_c++23.cc
@@ -16,6 +16,7 @@
// <http://www.gnu.org/licenses/>.
// { dg-do run { target c++23 } }
+// { dg-require-cmath "" }
#include
#include
--
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
Free Software Activist GNU Toolchain Engineer
More tolerance and less prejudice are key for inclusion and diversity
Excluding neuro-others for not behaving ""normal"" is *not* inclusive
[PATCH] [libstdc++] [testsuite] xfail double-prec from_chars for float128_t
Tests involving float128_t were xfailed or otherwise worked around for
vxworks on aarch64. The same issue came up on rtems. This patch
adjusts them similarly.
Regstrapping on x86_64-linux-gnu. Also tested with gcc-13 on
aarch64-rtems6. Ok to install?
(I'd have expected the fast_float limitation to come up with aarch64-elf
and any other aarch64 targets, but since I haven't observed it there,
I'm avoiding aarch64-*-*.)
for libstdc++-v3/ChangeLog
* testsuite/20_util/from_chars/8.cc: Skip float128_t testing
on aarch64-rtems*.
* testsuite/20_util/to_chars/float128_c++23.cc: Xfail run on
aarch64-rtems*.
---
libstdc++-v3/testsuite/20_util/from_chars/8.cc |2 +-
.../testsuite/20_util/to_chars/float128_c++23.cc |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/libstdc++-v3/testsuite/20_util/from_chars/8.cc
b/libstdc++-v3/testsuite/20_util/from_chars/8.cc
index a6343422c5a91..bacad89943b5f 100644
--- a/libstdc++-v3/testsuite/20_util/from_chars/8.cc
+++ b/libstdc++-v3/testsuite/20_util/from_chars/8.cc
@@ -17,7 +17,7 @@
// { dg-do run { target c++23 } }
// { dg-add-options ieee }
-// { dg-additional-options "-DSKIP_LONG_DOUBLE" { target aarch64-*-vxworks* } }
+// { dg-additional-options "-DSKIP_LONG_DOUBLE" { target aarch64-*-vxworks*
aarch64-*-rtems* } }
#include
#include
diff --git a/libstdc++-v3/testsuite/20_util/to_chars/float128_c++23.cc
b/libstdc++-v3/testsuite/20_util/to_chars/float128_c++23.cc
index ca00761ee7c98..6cb9cadcd2041 100644
--- a/libstdc++-v3/testsuite/20_util/to_chars/float128_c++23.cc
+++ b/libstdc++-v3/testsuite/20_util/to_chars/float128_c++23.cc
@@ -19,7 +19,7 @@
// { dg-require-effective-target ieee_floats }
// { dg-require-effective-target size32plus }
// { dg-add-options ieee }
-// { dg-xfail-run-if "from_chars limited to double-precision" {
aarch64-*-vxworks* } }
+// { dg-xfail-run-if "from_chars limited to double-precision" {
aarch64-*-vxworks* aarch64-*-rtems* } }
#include
#include
--
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
Free Software Activist GNU Toolchain Engineer
More tolerance and less prejudice are key for inclusion and diversity
Excluding neuro-others for not behaving ""normal"" is *not* inclusive
Re: [PATCH v3 #1/2] enable adjustment of return_pc debug attrs
On May 28, 2024, Jason Merrill wrote: > On 5/25/24 08:12, Alexandre Oliva wrote: >> On Apr 27, 2023, Alexandre Oliva wrote: >>> On Apr 14, 2023, Alexandre Oliva wrote: >>>> On Mar 23, 2023, Alexandre Oliva wrote: >>>>> This patch introduces infrastructure for targets to add an offset to >>>>> the label issued after the call_insn to set the call_return_pc >>>>> attribute. This will be used on rs6000, that sometimes issues another >>>>> instruction after the call proper as part of a call insn. >> >>>> Ping? >>>> https://gcc.gnu.org/pipermail/gcc-patches/2023-March/614452.html >> Ping? >> Refreshed, retested on ppc64le-linux-gnu. Ok to install? > I wonder about adding this information to REG_CALL_ARG_LOCATION, but > doing it this way also seems reasonable. I'm interested in Jakub's > input, but the patch is OK in a week if he doesn't get to it. Thanks, I'm putting it in, but I also look forward to Jakub's feedback. As for REG_CALL_ARG_LOCATION, I suppose that would be a decent place to hold it for the new hook to get at it, but since it can usually be computed directly, possibly with help of an attribute, adding extra rtl to call insns is probably unnecessary and undesirable. >> for gcc/ChangeLog >> * target.def (call_offset_return_label): New hook. >> * gcc/doc/tm.texi.in (TARGET_CALL_OFFSET_RETURN_LABEL): Add >> placeholder. >> * gcc/doc/tm.texi: Rebuild. >> * dwarf2out.cc (struct call_arg_loc_node): Record call_insn >> instad of call_arg_loc_note. >> (add_AT_lbl_id): Add optional offset argument. >> (gen_call_site_die): Compute and pass on a return pc offset. >> (gen_subprogram_die): Move call_arg_loc_note computation... >> (dwarf2out_var_location): ... from here. Set call_insn. -- Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/ Free Software Activist GNU Toolchain Engineer More tolerance and less prejudice are key for inclusion and diversity Excluding neuro-others for not behaving ""normal"" is *not* inclusive
[PATCH] [testsuite] [arm] test board cflags in multilib.exp
multilib.exp tests for multilib-altering flags in a board's
multilib_flags and skips the test, but if such flags appear in the
board's cflags, with the same distorting effects on tested multilibs,
we fail to skip the test.
Extend the skipping logic to board's cflags as well.
Regstrapping on x86_64-linux-gnu. Already tested on arm-eabi (gcc-13
and trunk). Ok to install?
for gcc/testsuite/ChangeLog
* gcc.target/arm/multilib.exp: Skip based on board cflags too.
---
gcc/testsuite/gcc.target/arm/multilib.exp |8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/gcc/testsuite/gcc.target/arm/multilib.exp
b/gcc/testsuite/gcc.target/arm/multilib.exp
index 4442d5d754bd6..12c93bc89d222 100644
--- a/gcc/testsuite/gcc.target/arm/multilib.exp
+++ b/gcc/testsuite/gcc.target/arm/multilib.exp
@@ -18,13 +18,15 @@ load_lib gcc-dg.exp
dg-init
-if { [board_info [target_info name] exists multilib_flags]
- && [regexp {(-marm|-mthumb|-march=.*|-mcpu=.*|-mfpu=.*|-mfloat=abi=.*)\y}
[board_info [target_info name] multilib_flags]] } {
+foreach flagsvar {multilib_flags cflags} {
+ if { [board_info [target_info name] exists $flagsvar]
+ && [regexp {(-marm|-mthumb|-march=.*|-mcpu=.*|-mfpu=.*|-mfloat=abi=.*)\y}
[board_info [target_info name] $flagsvar]] } {
# Multilib flags override anything we can apply to a test, so
# skip if any of the above options are set there.
-verbose "skipping multilib tests due to multilib_flags setting" 1
+verbose "skipping multilib tests due to $flagsvar setting" 1
return
+ }
}
# We don't want to run this test multiple times in a parallel make check.
--
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
Free Software Activist GNU Toolchain Engineer
More tolerance and less prejudice are key for inclusion and diversity
Excluding neuro-others for not behaving ""normal"" is *not* inclusive
[PATCH] [libstdc++] drop workaround for clang<=7 (was: [libstdc++] add _GLIBCXX_CLANG to workaround predefined __clang__)
On May 31, 2024, Alexandre Oliva wrote: >> I think we could drop this kluge entirely, clang 7 is old now, we >> generally only support the most recent 3 or 4 clang versions. > Fine with me, but I'd do that in a separate later patch, so that this > goes in, and if it gets backported, it will cover this change, rather > than miss it. Though, as you say, it doesn't matter much either way. In response to a request in the review of the patch that introduced _GLIBCXX_CLANG, this patch removes from std/variant an obsolete workaround for clang 7-. Regstrapping on x86_64-linux-gnu. Ok to install? for libstdc++-v3/ChangeLog * include/std/variant: Drop obsolete workaround. --- libstdc++-v3/include/std/variant |5 - 1 file changed, 5 deletions(-) diff --git a/libstdc++-v3/include/std/variant b/libstdc++-v3/include/std/variant index 51aaa62085170..13ea1dd384965 100644 --- a/libstdc++-v3/include/std/variant +++ b/libstdc++-v3/include/std/variant @@ -1758,11 +1758,6 @@ namespace __detail::__variant }, __rhs); } -#if defined(_GLIBCXX_CLANG) && __clang_major__ <= 7 -public: - using _Base::_M_u; // See https://bugs.llvm.org/show_bug.cgi?id=31852 -#endif - private: template friend constexpr decltype(auto) -- Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/ Free Software Activist GNU Toolchain Engineer More tolerance and less prejudice are key for inclusion and diversity Excluding neuro-others for not behaving ""normal"" is *not* inclusive
[FYI] [PATCH v3] [libstdc++] add _GLIBCXX_CLANG to workaround predefined __clang__
e<_Fp&, range_reference_t<_Ws>...>
@@ -5387,7 +5387,7 @@ namespace views::__adaptor
template
class adjacent_view<_Vp, _Nm>::_Iterator
{
-#ifdef __clang__ // LLVM-61763 workaround
+#ifdef _GLIBCXX_CLANG // LLVM-61763 workaround
public:
#endif
using _Base = __detail::__maybe_const_t<_Const, _Vp>;
@@ -5430,7 +5430,7 @@ namespace views::__adaptor
friend class adjacent_view;
-#ifndef __clang__ // LLVM-61763 workaround
+#ifndef _GLIBCXX_CLANG // LLVM-61763 workaround
template
requires view<_Wp> && (_Mm > 0) && is_object_v<_Fp>
&& regular_invocable<__detail::__unarize<_Fp&, _Mm>,
range_reference_t<_Wp>>
diff --git a/libstdc++-v3/include/std/variant b/libstdc++-v3/include/std/variant
index 371cbb90f54a6..51aaa62085170 100644
--- a/libstdc++-v3/include/std/variant
+++ b/libstdc++-v3/include/std/variant
@@ -1758,7 +1758,7 @@ namespace __detail::__variant
}, __rhs);
}
-#if defined(__clang__) && __clang_major__ <= 7
+#if defined(_GLIBCXX_CLANG) && __clang_major__ <= 7
public:
using _Base::_M_u; // See https://bugs.llvm.org/show_bug.cgi?id=31852
#endif
--
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
Free Software Activist GNU Toolchain Engineer
More tolerance and less prejudice are key for inclusion and diversity
Excluding neuro-others for not behaving ""normal"" is *not* inclusive
[PATCH v2] [libstdc++] add _GLIBCXX_CLANG to workaround predefined __clang__
On May 31, 2024, Alexandre Oliva wrote: >> So either don't change this line at all, or just do a simple >> s/__clang__/_GLIBCXX_CLANG/ > If c++config can be counted on, I'd be happy to do that, but I couldn't > tell that it could. Here's what I've retested on x86_64-linux-gnu and, slightly adjusted for gcc-13, on arm-vx7r2. Ok to install? [libstdc++] add _GLIBCXX_CLANG to workaround predefined __clang__ A proprietary embedded operating system that uses clang as its primary compiler ships headers that require __clang__ to be defined. Defining that macro causes libstdc++ to adopt workarounds that work for clang but that break for GCC. So, introduce a _GLIBCXX_CLANG macro, and a convention to test for it rather than for __clang__, so that a GCC variant that adds -D__clang__ to satisfy system headers can also -D_GLIBCXX_CLANG=0 to avoid workarounds that are not meant for GCC. I've left fast_float and ryu files alone, their tests for __clang__ don't seem to be harmful for GCC, they don't include bits/c++config, and patching such third-party files would just make trouble for updating them without visible benefit. pstl_config.h, though also imported, required adjustment. for libstdc++-v3/ChangeLog * include/bits/c++config (_GLIBCXX_CLANG): Define or undefine. * include/bits/locale_facets_nonio.tcc: Test for it. * include/bits/stl_bvector.h: Likewise. * include/c_compatibility/stdatomic.h: Likewise. * include/experimental/bits/simd.h: Likewise. * include/experimental/bits/simd_builtin.h: Likewise. * include/experimental/bits/simd_detail.h: Likewise. * include/experimental/bits/simd_x86.h: Likewise. * include/experimental/simd: Likewise. * include/std/complex: Likewise. * include/std/ranges: Likewise. * include/std/variant: Likewise. * include/pstl/pstl_config.h: Likewise. --- libstdc++-v3/include/bits/c++config| 13 - libstdc++-v3/include/bits/locale_facets_nonio.tcc |2 +- libstdc++-v3/include/bits/stl_bvector.h|2 +- libstdc++-v3/include/c_compatibility/stdatomic.h |2 +- libstdc++-v3/include/experimental/bits/simd.h | 14 +++--- .../include/experimental/bits/simd_builtin.h |4 ++-- .../include/experimental/bits/simd_detail.h|8 libstdc++-v3/include/experimental/bits/simd_x86.h | 12 ++-- libstdc++-v3/include/experimental/simd |2 +- libstdc++-v3/include/pstl/pstl_config.h|4 ++-- libstdc++-v3/include/std/complex |4 ++-- libstdc++-v3/include/std/ranges|8 libstdc++-v3/include/std/variant |2 +- 13 files changed, 44 insertions(+), 33 deletions(-) diff --git a/libstdc++-v3/include/bits/c++config b/libstdc++-v3/include/bits/c++config index b57e3f338e92a..6dca2d9467aa5 100644 --- a/libstdc++-v3/include/bits/c++config +++ b/libstdc++-v3/include/bits/c++config @@ -481,9 +481,20 @@ _GLIBCXX_END_NAMESPACE_VERSION // Define if compatibility should be provided for -mlong-double-64. #undef _GLIBCXX_LONG_DOUBLE_COMPAT +// Use an alternate macro to test for clang, so as to provide an easy +// workaround for systems (such as vxworks) whose headers require +// __clang__ to be defined, even when compiling with GCC. +#if !defined _GLIBCXX_CLANG && defined __clang__ +# define _GLIBCXX_CLANG __clang__ +// Turn -D_GLIBCXX_CLANG=0 into -U_GLIBCXX_CLANG, so that +// _GLIBCXX_CLANG can be tested as defined, just like __clang__. +#elif !_GLIBCXX_CLANG +# undef _GLIBCXX_CLANG +#endif + // Define if compatibility should be provided for alternative 128-bit long // double formats. Not possible for Clang until __ibm128 is supported. -#ifndef __clang__ +#ifndef _GLIBCXX_CLANG #undef _GLIBCXX_LONG_DOUBLE_ALT128_COMPAT #endif diff --git a/libstdc++-v3/include/bits/locale_facets_nonio.tcc b/libstdc++-v3/include/bits/locale_facets_nonio.tcc index 8f67be5a6147b..72136f42f0866 100644 --- a/libstdc++-v3/include/bits/locale_facets_nonio.tcc +++ b/libstdc++-v3/include/bits/locale_facets_nonio.tcc @@ -1465,7 +1465,7 @@ _GLIBCXX_END_NAMESPACE_LDBL_OR_CXX11 ctype<_CharT> const& __ctype = use_facet >(__loc); __err = ios_base::goodbit; bool __use_state = false; -#if __GNUC__ >= 5 && !defined(__clang__) +#if __GNUC__ >= 5 && !defined(_GLIBCXX_CLANG) #pragma GCC diagnostic push #pragma GCC diagnostic ignored "-Wpmf-conversions" // Nasty hack. The C++ standard mandates that get invokes the do_get diff --git a/libstdc++-v3/include/bits/stl_bvector.h b/libstdc++-v3/include/bits/stl_bvector.h index d567e26f4e430..52153cadf8f70 100644 --- a/libstdc++-v3/include/bits/stl_bvector.h +++ b/libstdc++-v3/include/bits/stl_bvector.h @@ -185,7 +185,7 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER void _M_assume
Re: [PATCH] [libstdc++] add _GLIBCXX_CLANG to workaround predefined __clang__
On May 31, 2024, Matthias Kretz wrote: > So __clang__ is turning into the next __GNUC__ ;) Yeah :-( > So passing -D__clang__=17 -D_GLIBCXX_CLANG=1 is possible? Should it be? I thought setting them independently could give us some testing flexibility, thought it's not for the faint of heart ;-) -- Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/ Free Software Activist GNU Toolchain Engineer More tolerance and less prejudice are key for inclusion and diversity Excluding neuro-others for not behaving ""normal"" is *not* inclusive
Re: [PATCH] [libstdc++] add _GLIBCXX_CLANG to workaround predefined __clang__
On May 31, 2024, Jonathan Wakely wrote: > On 31/05/24 11:07 -0300, Alexandre Oliva wrote: >> --- a/libstdc++-v3/include/pstl/pstl_config.h [...] >> -#if defined(__clang__) >> +#if defined(__GLIBCXX__) ? defined(_GLIBCXX_CLANG) : defined(__clang__) > This file is also imported from upstream, like Ryu and fast_float. Oh, yeah, I should have mentioned this one in the proposed commit message. The problem here was that it wasn't clear c++config would always be included, so I figured I'd better be conservative. > I don't think having a "spurious" definition of _PSTL_CLANG_VERSION > here actually matters. Yeah, no, it's the other macros guarded by __clang__ that I'm concerned about, and since the version macro could replace it, I went for it. > So either don't change this line at all, or just do a simple > s/__clang__/_GLIBCXX_CLANG/ If c++config can be counted on, I'd be happy to do that, but I couldn't tell that it could. > Does the vxworks toolchain need to support the PSTL headers? Maybe we can do without them. I really don't know. Olivier? > If not, we could just ignore this file, so the local changes don't > need to be re-applied when we import a new version of the header from > upstream. That sounds desirable indeed. This change is supposed to spare us (AdaCore) from precisely this sort of trouble, so it wouldn't be fair if it made this very kind of trouble for our upstream. >> --- a/libstdc++-v3/include/std/ranges >> -#ifdef __clang__ // LLVM-61763 workaround >> +#ifdef _GLIBCXX_CLANG // LLVM-61763 workaround > This one doesn't matter, since making these members public for a "fake > clang" doesn't really hurt anything. For consistency maybe it makes > sense to use _GLIBCXX_CLANG anyway. Yeah, uniformity would be good to simplify checking for no new appearances of __clang__, and to set the example to avoid accidental additions thereof. >> --- a/libstdc++-v3/include/std/variant >> -#if defined(__clang__) && __clang_major__ <= 7 >> +#if defined(_GLIBCXX_CLANG) && __clang_major__ <= 7 > I think we could drop this kluge entirely, clang 7 is old now, we > generally only support the most recent 3 or 4 clang versions. Fine with me, but I'd do that in a separate later patch, so that this goes in, and if it gets backported, it will cover this change, rather than miss it. Though, as you say, it doesn't matter much either way. -- Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/ Free Software Activist GNU Toolchain Engineer More tolerance and less prejudice are key for inclusion and diversity Excluding neuro-others for not behaving ""normal"" is *not* inclusive
[PATCH] [libstdc++] add _GLIBCXX_CLANG to workaround predefined __clang__
dex b1e827c9a7241..3f335b95a0864 100644
--- a/libstdc++-v3/include/std/ranges
+++ b/libstdc++-v3/include/std/ranges
@@ -4687,7 +4687,7 @@ namespace views::__adaptor
class zip_view<_Vs...>::_Iterator
: public __detail::__zip_view_iter_cat<_Const, _Vs...>
{
-#ifdef __clang__ // LLVM-61763 workaround
+#ifdef _GLIBCXX_CLANG // LLVM-61763 workaround
public:
#endif
tuple>...> _M_current;
@@ -4710,7 +4710,7 @@ namespace views::__adaptor
return input_iterator_tag{};
}
-#ifndef __clang__ // LLVM-61763 workaround
+#ifndef _GLIBCXX_CLANG // LLVM-61763 workaround
template
requires (view<_Ws> && ...) && (sizeof...(_Ws) > 0) && is_object_v<_Fp>
&& regular_invocable<_Fp&, range_reference_t<_Ws>...>
@@ -5387,7 +5387,7 @@ namespace views::__adaptor
template
class adjacent_view<_Vp, _Nm>::_Iterator
{
-#ifdef __clang__ // LLVM-61763 workaround
+#ifdef _GLIBCXX_CLANG // LLVM-61763 workaround
public:
#endif
using _Base = __detail::__maybe_const_t<_Const, _Vp>;
@@ -5430,7 +5430,7 @@ namespace views::__adaptor
friend class adjacent_view;
-#ifndef __clang__ // LLVM-61763 workaround
+#ifndef _GLIBCXX_CLANG // LLVM-61763 workaround
template
requires view<_Wp> && (_Mm > 0) && is_object_v<_Fp>
&& regular_invocable<__detail::__unarize<_Fp&, _Mm>,
range_reference_t<_Wp>>
diff --git a/libstdc++-v3/include/std/variant b/libstdc++-v3/include/std/variant
index 371cbb90f54a6..51aaa62085170 100644
--- a/libstdc++-v3/include/std/variant
+++ b/libstdc++-v3/include/std/variant
@@ -1758,7 +1758,7 @@ namespace __detail::__variant
}, __rhs);
}
-#if defined(__clang__) && __clang_major__ <= 7
+#if defined(_GLIBCXX_CLANG) && __clang_major__ <= 7
public:
using _Base::_M_u; // See https://bugs.llvm.org/show_bug.cgi?id=31852
#endif
--
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
Free Software Activist GNU Toolchain Engineer
More tolerance and less prejudice are key for inclusion and diversity
Excluding neuro-others for not behaving ""normal"" is *not* inclusive
Re: [PATCH v3 #2/2] [rs6000] adjust return_pc debug attrs
Sorry, I misnumbered this patch as #1/2 when first posting v3.
On May 28, 2024, Segher Boessenkool wrote:
> Please don't (incorrectly!) line-wrap changelogs. Lines are 80
> characters wide, not 60 or 72 or whatever. 80. Indents are tabs that
> take 8 columns.
ACK. When was it bumped up to 80, BTW? It wasn't always like that, was
it? I've noticed that something seems to change my line width settings
in Emacs, but I must have missed that memo.
>> +/* Return the offset to be added to the label output after CALL_INSN
>> + to compute the address to be placed in DW_AT_call_return_pc. */
>> +
>> +static int
>> +rs6000_call_offset_return_label (rtx_insn *call_insn)
>> +{
>> + /* All rs6000 CALL_INSN output patterns start with a b or bl, always
> This isn't true. There is a crlogical insn before the bcl for sysv for
> example.
Hmm, if that's so, this function will have to look at the insn and
recognize those cases and use a different way to compute the offset.
However, I don't see any relevant uses of bcl in output patterns for
insns containing a call rtx. There are other uses in profiling and pic
loading and whatnot, but those don't get mentioned in the call graph in
debug info, and so they don't get this target hook called on them.
>> +we compute the offset
>> + back to the address of the call opcode proper, then add the
>> + constant 4 bytes, to get the address after that opcode. */
>> + return 4 - get_attr_length (call_insn);
> Please explain this magic, too -- in code preferably (so with a ? :
> maybe, but don't try to "optimise" that expression, let the compiler
> do that, it is much better at it anyway :-) )
There's neither optimization nor magic, it's literally what's written in
the comment quoted above: starting from the label at the end of the call
insn (that's what the caller offsets from, as in the documentation in
the actual #1/2), subtract the length (to get to the address of the call
opcode), and add 4 (to get past the call opcode). Ok, I've reordered
the two addends for an IMHO more readable expression, but that was all.
> Is that correct for all ABIs we support?
Back when I wrote this patchset, I went through all call opcodes I could
find in the md and .c files within rs6000/, and I was satisfied that it
covered what we had then, but I won't pretend to know all about all of
the ppc ABIs. I may have missed disguised call insns, too. I was
hoping some ppc maintainer, more familiar with the port than I am, would
catch any trouble on review and let me know about pitfalls and surprises
to watch out for.
> Even if so, it needs a lot more documentation than this.
I can write more documentation, but I'm at a loss as to what you're
hoping for. If you set clearer expectations, I'll be glad to oblige.
Thanks,
--
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
Free Software Activist GNU Toolchain Engineer
More tolerance and less prejudice are key for inclusion and diversity
Excluding neuro-others for not behaving ""normal"" is *not* inclusive
Re: [PATCH] [libstdc++-v3] [rtems] enable filesystem support
On May 30, 2024, Jonathan Wakely wrote: > Typo here, "rtemps"? Ugh, thanks, fixed. > OK with that fixed (and configure regenerated). I also untabified the new lines, to match the surrounding context. Here's what I installed: [libstdc++-v3] [rtems] enable filesystem support mkdir, chdir and chmod functions are defined in librtemscpu, that doesn't get linked in during libstdc++-v3 configure, but applications use -qrtems for linking, which brings those symbols in, so it makes sense to mark them as available so that the C++ filesystem APIs are enabled. for libstdc++-v3/ChangeLog * configure.ac [*-*-rtems*]: Set chdir, chmod and mkdir as available. * configure: Rebuilt. --- libstdc++-v3/configure|7 +++ libstdc++-v3/configure.ac |7 +++ 2 files changed, 14 insertions(+) diff --git a/libstdc++-v3/configure b/libstdc++-v3/configure index 5179cc507f129..5645e991af7ab 100755 --- a/libstdc++-v3/configure +++ b/libstdc++-v3/configure @@ -28610,6 +28610,13 @@ _ACEOF $as_echo "#define HAVE_USLEEP 1" >>confdefs.h + +# These functions are defined in librtemscpu. We don't use +# -qrtems during configure, so we don't link that in, and fail +# to find them. +glibcxx_cv_chdir=yes +glibcxx_cv_chmod=yes +glibcxx_cv_mkdir=yes ;; esac elif test "x$with_headers" != "xno"; then diff --git a/libstdc++-v3/configure.ac b/libstdc++-v3/configure.ac index 37396bd6ebbe6..ccb24a82be799 100644 --- a/libstdc++-v3/configure.ac +++ b/libstdc++-v3/configure.ac @@ -400,6 +400,13 @@ dnl # rather than hardcoding that information. AC_DEFINE(HAVE_SYMLINK) AC_DEFINE(HAVE_TRUNCATE) AC_DEFINE(HAVE_USLEEP) + +# These functions are defined in librtemscpu. We don't use +# -qrtems during configure, so we don't link that in, and fail +# to find them. +glibcxx_cv_chdir=yes +glibcxx_cv_chmod=yes +glibcxx_cv_mkdir=yes ;; esac elif test "x$with_headers" != "xno"; then -- Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/ Free Software Activist GNU Toolchain Engineer More tolerance and less prejudice are key for inclusion and diversity Excluding neuro-others for not behaving ""normal"" is *not* inclusive
[PATCH] [libstdc++-v3] [rtems] enable filesystem support
mkdir, chdir and chmod functions are defined in librtemscpu, that doesn't get linked in during libstdc++-v3 configure, but applications use -qrtems for linking, which brings those symbols in, so it makes sense to mark them as available so that the C++ filesystem APIs are enabled. Regstrapped on x86_64-linux-gnu, also tested on aarch64-rtems6 with gcc-13. Ok to install? for libstdc++-v3/ChangeLog * configure.ac [*-*-rtems*]: Set chdir, chmod and mkdir as available. * configure: Rebuilt. --- libstdc++-v3/configure|7 +++ libstdc++-v3/configure.ac |7 +++ 2 files changed, 14 insertions(+) diff --git a/libstdc++-v3/configure b/libstdc++-v3/configure index 5179cc507f129..a7d1c015906c2 100755 --- a/libstdc++-v3/configure +++ b/libstdc++-v3/configure @@ -28610,6 +28610,13 @@ _ACEOF $as_echo "#define HAVE_USLEEP 1" >>confdefs.h + + # These functions are defined in librtempscpu. We don't use + # -qrtems during configure, so we don't link that in, and fail + # to find them. + glibcxx_cv_chdir=yes + glibcxx_cv_chmod=yes + glibcxx_cv_mkdir=yes ;; esac elif test "x$with_headers" != "xno"; then diff --git a/libstdc++-v3/configure.ac b/libstdc++-v3/configure.ac index 37396bd6ebbe6..0725c81bc9fa4 100644 --- a/libstdc++-v3/configure.ac +++ b/libstdc++-v3/configure.ac @@ -400,6 +400,13 @@ dnl # rather than hardcoding that information. AC_DEFINE(HAVE_SYMLINK) AC_DEFINE(HAVE_TRUNCATE) AC_DEFINE(HAVE_USLEEP) + + # These functions are defined in librtempscpu. We don't use + # -qrtems during configure, so we don't link that in, and fail + # to find them. + glibcxx_cv_chdir=yes + glibcxx_cv_chmod=yes + glibcxx_cv_mkdir=yes ;; esac elif test "x$with_headers" != "xno"; then -- Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/ Free Software Activist GNU Toolchain Engineer More tolerance and less prejudice are key for inclusion and diversity Excluding neuro-others for not behaving ""normal"" is *not* inclusive
Re: [PATCH v2] [testsuite] [powerpc] adjust -m32 counts for fold-vec-extract*
stxvw4x, lwa/lwz
/* { dg-final { scan-assembler-times {\mli\M} 6 } } */
-/* { dg-final { scan-assembler-times {\maddi\M|\madd\M} 9 { target lp64 } } }
*/
-/* { dg-final { scan-assembler-times {\maddi\M|\madd\M} 12 { target ilp32 } }
} */
+/* { dg-final { scan-assembler-times {\maddi?\M} 9 } } */
/* { dg-final { scan-assembler-times {\mstxvw4x\M|\mstvx\M|\mstxv\M} 6 } } */
/* { dg-final { scan-assembler-times {\mrldic\M|\mrlwinm\M} 3 } } */
/* { dg-final { scan-assembler-times {\mlwz\M|\mlwa\M|\mlwzx\M|\mlwax\M} 6 } }
*/
diff --git a/gcc/testsuite/gcc.target/powerpc/fold-vec-extract-int.p8.c
b/gcc/testsuite/gcc.target/powerpc/fold-vec-extract-int.p8.c
index 67fa89d9e02e6..81d95e456bf01 100644
--- a/gcc/testsuite/gcc.target/powerpc/fold-vec-extract-int.p8.c
+++ b/gcc/testsuite/gcc.target/powerpc/fold-vec-extract-int.p8.c
@@ -28,9 +28,8 @@
/* { dg-final { scan-assembler-times {\mli\M} 6 { target ilp32 } } } */
/* { dg-final { scan-assembler-times {\mrlwinm\M} 3 { target ilp32 } } } */
/* { dg-final { scan-assembler-times {\mstxvw4x\M} 6 { target ilp32 } } } */
-/* { dg-final { scan-assembler-times {\madd\M} 3 { target ilp32 } } } */
/* { dg-final { scan-assembler-times {\mlwz\M} 6 { target ilp32 } } } */
-/* { dg-final { scan-assembler-times {\maddi\M} 9 { target ilp32 } } } */
+/* { dg-final { scan-assembler-times {\maddi?\M} 9 { target ilp32 } } } */
diff --git a/gcc/testsuite/gcc.target/powerpc/fold-vec-extract-short.p7.c
b/gcc/testsuite/gcc.target/powerpc/fold-vec-extract-short.p7.c
index 5f3b11fc5c10e..d8ed54703c9ea 100644
--- a/gcc/testsuite/gcc.target/powerpc/fold-vec-extract-short.p7.c
+++ b/gcc/testsuite/gcc.target/powerpc/fold-vec-extract-short.p7.c
@@ -10,8 +10,7 @@
// P7 (be) constants:li, addi, stxvw4x, lha/lhz
/* { dg-final { scan-assembler-times {\mli\M} 6 } } */
-/* { dg-final { scan-assembler-times {\maddi\M|\madd\M} 9 { target lp64 } } }
*/
-/* { dg-final { scan-assembler-times {\maddi\M|\madd\M} 12 { target ilp32 } }
} */
+/* { dg-final { scan-assembler-times {\maddi?\M} 9 } } */
/* { dg-final { scan-assembler-times {\mrldic\M|\mrlwinm\M} 3 } } */
/* { dg-final { scan-assembler-times {\mstxvw4x\M|\mstvx\M} 6 } } */
/* { dg-final { scan-assembler-times "lhz|lha|lhzx|lhax" 6 } } */
diff --git a/gcc/testsuite/gcc.target/powerpc/fold-vec-extract-short.p8.c
b/gcc/testsuite/gcc.target/powerpc/fold-vec-extract-short.p8.c
index 0db99933871ff..af741c1a7ab83 100644
--- a/gcc/testsuite/gcc.target/powerpc/fold-vec-extract-short.p8.c
+++ b/gcc/testsuite/gcc.target/powerpc/fold-vec-extract-short.p8.c
@@ -30,9 +30,8 @@
/* { dg-final { scan-assembler-times {\mli\M} 6 { target ilp32 } } } */
/* { dg-final { scan-assembler-times "stxvw4x" 6 { target ilp32 } } } */
/* add and rlwinm instructions only on the variable tests. */
-/* { dg-final { scan-assembler-times {\madd\M} 3 { target ilp32 } } } */
/* { dg-final { scan-assembler-times "rlwinm" 3 { target ilp32 } } } */
-/* { dg-final { scan-assembler-times {\maddi\M} 9 { target ilp32 } } } */
+/* { dg-final { scan-assembler-times {\maddi?\M} 9 { target ilp32 } } } */
/* { dg-final { scan-assembler-times {\mlha\M|\mlhz\M} 6 { target ilp32 } } }
*/
--
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
Free Software Activist GNU Toolchain Engineer
More tolerance and less prejudice are key for inclusion and diversity
Excluding neuro-others for not behaving ""normal"" is *not* inclusive
Re: [PATCH v3 #1/2] [rs6000] adjust return_pc debug attrs
On May 27, 2024, "Kewen.Lin" wrote: > I wonder if it's possible to have a test case for this? gcc.dg/guality/pr54519-[34].c at -O[1g] are fixed by this patch on ppc64le-linux-gnu. Are these the sort of test case you're interested in, or are you looking for something that tests the offsets in debug info, rather than the end-to-end debugging feature? -- Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/ Free Software Activist GNU Toolchain Engineer More tolerance and less prejudice are key for inclusion and diversity Excluding neuro-others for not behaving ""normal"" is *not* inclusive
Re: [PATCH v2] add explicit ABI and align options to pr88233.c
On May 26, 2024, "Kewen.Lin" wrote: > Hi, > on 2024/4/22 17:38, Alexandre Oliva wrote: >> Ping? >> https://gcc.gnu.org/pipermail/gcc-patches/2021-March/566530.html >> (modified version follows) > Segher originated this test case, I was expecting he can chime in this. :) Me too ;-) >> We've observed failures of this test on powerpc configurations that >> default to different calling conventions and alignment requirements. > It seems that it was using the original "BE" and "LE" guards to shadow > ABIs, could you share some more on how you found this failure? It seems > that your test environment with -mstrict-align turned on by default? And > also having a ABI which passing small struct return value in register? Exactly, AdaCore's ppc64-vx7r2 are configured so as to enable -mstrict-align and -freg-struct-return by default. But since these settings may change depending on the target variant, I figured it would be useful to record what the assumptions are that the test makes. That one of these settings changed depending on endianness and affected codegen was, to me, further evidence that this would be useful, so, with the explicit settings, I could restore the original test's expectations. -- Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/ Free Software Activist GNU Toolchain Engineer More tolerance and less prejudice are key for inclusion and diversity Excluding neuro-others for not behaving ""normal"" is *not* inclusive
[PATCH v3 #1/2] [rs6000] adjust return_pc debug attrs
On Apr 27, 2023, Alexandre Oliva wrote:
> On Apr 14, 2023, Alexandre Oliva wrote:
>> On Mar 23, 2023, Alexandre Oliva wrote:
>>> This patch introduces infrastructure for targets to add an offset to
>>> the label issued after the call_insn to set the call_return_pc
>>> attribute. This will be used on rs6000, that sometimes issues another
>>> instruction after the call proper as part of a call insn.
>> Ping?
>> https://gcc.gnu.org/pipermail/gcc-patches/2023-March/614453.html
> Ping?
Ping?
Refreshed, retested on ppc64le-linux-gnu. Ok to install?
Some of the rs6000 call patterns, on some ABIs, issue multiple opcodes
out of a single call insn, but the call (bl) or jump (b) is not always
the last opcode in the sequence.
This does not seem to be a problem for exception handling tables, but
the return_pc attribute in the call graph output in dwarf2+ debug
information, that takes the address of a label output right after the
call, does not match the value of the link register even for non-tail
calls. E.g., with ABI_AIX or ABI_ELFv2, such code as:
foo ();
outputs:
bl foo
nop
LVL#:
[...]
.8byte .LVL# # DW_AT_call_return_pc
but debug info consumers may rely on the return_pc address, and draw
incorrect conclusions from its off-by-4 value.
This patch uses the infrastructure for targets to add an offset to the
label issued after the call_insn to set the call_return_pc attribute,
on rs6000, to account for opcodes issued after actual call opcode as
part of call insns output patterns.
for gcc/ChangeLog
* config/rs6000/rs6000.cc (TARGET_CALL_OFFSET_RETURN_LABEL):
Override.
(rs6000_call_offset_return_label): New.
---
gcc/config/rs6000/rs6000.cc | 18 ++
1 file changed, 18 insertions(+)
diff --git a/gcc/config/rs6000/rs6000.cc b/gcc/config/rs6000/rs6000.cc
index e4dc629ddcc9a..77e6b94a539da 100644
--- a/gcc/config/rs6000/rs6000.cc
+++ b/gcc/config/rs6000/rs6000.cc
@@ -1779,6 +1779,8 @@ static const scoped_attribute_specs *const
rs6000_attribute_table[] =
#undef TARGET_OVERLAP_OP_BY_PIECES_P
#define TARGET_OVERLAP_OP_BY_PIECES_P hook_bool_void_true
+#undef TARGET_CALL_OFFSET_RETURN_LABEL
+#define TARGET_CALL_OFFSET_RETURN_LABEL rs6000_call_offset_return_label
/* Processor table. */
@@ -14822,6 +14824,22 @@ rs6000_assemble_integer (rtx x, unsigned int size, int
aligned_p)
return default_assemble_integer (x, size, aligned_p);
}
+/* Return the offset to be added to the label output after CALL_INSN
+ to compute the address to be placed in DW_AT_call_return_pc. */
+
+static int
+rs6000_call_offset_return_label (rtx_insn *call_insn)
+{
+ /* All rs6000 CALL_INSN output patterns start with a b or bl, always
+ a 4-byte instruction, but some output patterns issue other
+ opcodes afterwards. The return label is issued after the entire
+ call insn, including any such post-call opcodes. Instead of
+ figuring out which cases need adjustments, we compute the offset
+ back to the address of the call opcode proper, then add the
+ constant 4 bytes, to get the address after that opcode. */
+ return 4 - get_attr_length (call_insn);
+}
+
/* Return a template string for assembly to emit when making an
external call. FUNOP is the call mem argument operand number. */
--
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
Free Software Activist GNU Toolchain Engineer
More tolerance and less prejudice are key for inclusion and diversity
Excluding neuro-others for not behaving ""normal"" is *not* inclusive
[PATCH v3 #1/2] enable adjustment of return_pc debug attrs
On Apr 27, 2023, Alexandre Oliva wrote:
> On Apr 14, 2023, Alexandre Oliva wrote:
>> On Mar 23, 2023, Alexandre Oliva wrote:
>>> This patch introduces infrastructure for targets to add an offset to
>>> the label issued after the call_insn to set the call_return_pc
>>> attribute. This will be used on rs6000, that sometimes issues another
>>> instruction after the call proper as part of a call insn.
>> Ping?
>> https://gcc.gnu.org/pipermail/gcc-patches/2023-March/614452.html
Ping?
Refreshed, retested on ppc64le-linux-gnu. Ok to install?
This patch introduces infrastructure for targets to add an offset to
the label issued after the call_insn to set the call_return_pc
attribute. This will be used on rs6000, that sometimes issues another
instruction after the call proper as part of a call insn.
for gcc/ChangeLog
* target.def (call_offset_return_label): New hook.
* gcc/doc/tm.texi.in (TARGET_CALL_OFFSET_RETURN_LABEL): Add
placeholder.
* gcc/doc/tm.texi: Rebuild.
* dwarf2out.cc (struct call_arg_loc_node): Record call_insn
instad of call_arg_loc_note.
(add_AT_lbl_id): Add optional offset argument.
(gen_call_site_die): Compute and pass on a return pc offset.
(gen_subprogram_die): Move call_arg_loc_note computation...
(dwarf2out_var_location): ... from here. Set call_insn.
---
gcc/doc/tm.texi|7 +++
gcc/doc/tm.texi.in |2 ++
gcc/dwarf2out.cc | 26 +-
gcc/target.def |9 +
4 files changed, 35 insertions(+), 9 deletions(-)
diff --git a/gcc/doc/tm.texi b/gcc/doc/tm.texi
index cd50078227d98..8a7aa70d605ba 100644
--- a/gcc/doc/tm.texi
+++ b/gcc/doc/tm.texi
@@ -5557,6 +5557,13 @@ except the last are treated as named.
You need not define this hook if it always returns @code{false}.
@end deftypefn
+@deftypefn {Target Hook} int TARGET_CALL_OFFSET_RETURN_LABEL (rtx_insn
*@var{call_insn})
+While generating call-site debug info for a CALL insn, or a SEQUENCE
+insn starting with a CALL, this target hook is invoked to compute the
+offset to be added to the debug label emitted after the call to obtain
+the return address that should be recorded as the return PC.
+@end deftypefn
+
@deftypefn {Target Hook} void TARGET_START_CALL_ARGS (cumulative_args_t
@var{complete_args})
This target hook is invoked while generating RTL for a function call,
after the argument values have been computed, and after stack arguments
diff --git a/gcc/doc/tm.texi.in b/gcc/doc/tm.texi.in
index 058bd56487a9a..9e0830758aeea 100644
--- a/gcc/doc/tm.texi.in
+++ b/gcc/doc/tm.texi.in
@@ -3887,6 +3887,8 @@ These machine description macros help implement varargs:
@hook TARGET_STRICT_ARGUMENT_NAMING
+@hook TARGET_CALL_OFFSET_RETURN_LABEL
+
@hook TARGET_START_CALL_ARGS
@hook TARGET_CALL_ARGS
diff --git a/gcc/dwarf2out.cc b/gcc/dwarf2out.cc
index 5b064ffd78ad1..1092880738df4 100644
--- a/gcc/dwarf2out.cc
+++ b/gcc/dwarf2out.cc
@@ -3593,7 +3593,7 @@ typedef struct var_loc_list_def var_loc_list;
/* Call argument location list. */
struct GTY ((chain_next ("%h.next"))) call_arg_loc_node {
- rtx GTY (()) call_arg_loc_note;
+ rtx_insn * GTY (()) call_insn;
const char * GTY (()) label;
tree GTY (()) block;
bool tail_call_p;
@@ -3777,7 +3777,8 @@ static void remove_addr_table_entry (addr_table_entry *);
static void add_AT_addr (dw_die_ref, enum dwarf_attribute, rtx, bool);
static inline rtx AT_addr (dw_attr_node *);
static void add_AT_symview (dw_die_ref, enum dwarf_attribute, const char *);
-static void add_AT_lbl_id (dw_die_ref, enum dwarf_attribute, const char *);
+static void add_AT_lbl_id (dw_die_ref, enum dwarf_attribute, const char *,
+ int = 0);
static void add_AT_lineptr (dw_die_ref, enum dwarf_attribute, const char *);
static void add_AT_macptr (dw_die_ref, enum dwarf_attribute, const char *);
static void add_AT_range_list (dw_die_ref, enum dwarf_attribute,
@@ -5353,14 +5354,17 @@ add_AT_symview (dw_die_ref die, enum dwarf_attribute
attr_kind,
static inline void
add_AT_lbl_id (dw_die_ref die, enum dwarf_attribute attr_kind,
- const char *lbl_id)
+ const char *lbl_id, int offset)
{
dw_attr_node attr;
attr.dw_attr = attr_kind;
attr.dw_attr_val.val_class = dw_val_class_lbl_id;
attr.dw_attr_val.val_entry = NULL;
- attr.dw_attr_val.v.val_lbl_id = xstrdup (lbl_id);
+ if (!offset)
+attr.dw_attr_val.v.val_lbl_id = xstrdup (lbl_id);
+ else
+attr.dw_attr_val.v.val_lbl_id = xasprintf ("%s%+i", lbl_id, offset);
if (dwarf_split_debug_info)
attr.dw_attr_val.val_entry
= add_addr_table_entry (attr.dw_attr_val.v.val_lbl_id,
@@ -23515,7 +23519,9 @@ gen_call_site_die (tree decl, dw_die_ref subr_die,
if (stmt_die == NULL)
stmt_die = subr_die;
die = new_die (dwarf_TAG (DW_TAG_call_site), stmt_die, NULL
Re: [PATCH] [tree-prof] skip if errors were seen [PR113681]
On Apr 16, 2024, Alexandre Oliva wrote: > for gcc/ChangeLog > PR tree-optimization/113681 > * tree-profiling.cc (pass_ipa_tree_profile::gate): Skip if > seen_errors. > for gcc/testsuite/ChangeLog > PR tree-optimization/113681 > * c-c++-common/strub-pr113681.c: New. Ping? https://gcc.gnu.org/pipermail/gcc-patches/2024-April/649546.html -- Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/ Free Software Activist GNU Toolchain Engineer More tolerance and less prejudice are key for inclusion and diversity Excluding neuro-others for not behaving ""normal"" is *not* inclusive
Re: [PATCH v2] [testsuite] [arm] add effective target and options for pacbti tests
On Apr 19, 2024, Alexandre Oliva wrote: > for gcc/testsuite/ChangeLog > * gcc.target/arm/bti-1.c: Require arch, use its opts, drop skip. > * gcc.target/arm/bti-2.c: Likewise. > * gcc.target/arm/acle/pacbti-m-predef-11.c: Likewise. > * gcc.target/arm/acle/pacbti-m-predef-12.c: Likewise. > * gcc.target/arm/acle/pacbti-m-predef-7.c: Likewise. > * g++.target/arm/pac-1.C: Likewise. Drop +mve. Ping? https://gcc.gnu.org/pipermail/gcc-patches/2024-April/649732.html -- Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/ Free Software Activist GNU Toolchain Engineer More tolerance and less prejudice are key for inclusion and diversity Excluding neuro-others for not behaving ""normal"" is *not* inclusive
Re: [PATCH v2] [testsuite] [powerpc] adjust -m32 counts for fold-vec-extract*
On Apr 22, 2024, Alexandre Oliva wrote: > for gcc/testsuite/ChangeLog > PR testsuite/101169 > * gcc.target/powerpc/fold-vec-extract-double.p7.c: Adjust addi > counts for ilp32. > * gcc.target/powerpc/fold-vec-extract-float.p7.c: Likewise. > * gcc.target/powerpc/fold-vec-extract-float.p8.c: Likewise. > * gcc.target/powerpc/fold-vec-extract-int.p7.c: Likewise. > * gcc.target/powerpc/fold-vec-extract-int.p8.c: Likewise. > * gcc.target/powerpc/fold-vec-extract-short.p7.c: Likewise. > * gcc.target/powerpc/fold-vec-extract-short.p8.c: Likewise. Ping? https://gcc.gnu.org/pipermail/gcc-patches/2024-April/649830.html -- Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/ Free Software Activist GNU Toolchain Engineer More tolerance and less prejudice are key for inclusion and diversity Excluding neuro-others for not behaving ""normal"" is *not* inclusive
Re: [PATCH v2] add explicit ABI and align options to pr88233.c
On Apr 22, 2024, Alexandre Oliva wrote: > for gcc/testsuite/ChangeLog > * gcc.target/powerpc/pr88233.c: Make some alignment strictness > and calling conventions assumptions explicit. Restore uniform > codegen expectations Ping? https://gcc.gnu.org/pipermail/gcc-patches/2024-April/649823.html -- Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/ Free Software Activist GNU Toolchain Engineer More tolerance and less prejudice are key for inclusion and diversity Excluding neuro-others for not behaving ""normal"" is *not* inclusive
Re: [PATCH v8] Introduce attribute sym_alias
On Dec 5, 2023, Alexandre Oliva wrote:
> Here's an improved version that fixes some cases of making static local
> names visible through sym_alias, detection of symbol name clashes when
> sym_alias is registered before a clashing definition ("sym name"
> attributes are now introduced to enable sym_alias-created declarations
> to be identified), and aliases to typeinfo sym_alias names, with tests
> adjusted and extended to match.
> I've retained comments for the desired create_alias calls that didn't
> work, instead of create_same_body_alias for functions, and for the
> create_extra_name_alias calls I used to issue for variables, mainly to
> draw attention to the fact that some of these calls, found undesirable
> in earlier iterations, are still there, hoping that we can keep them
> this way rather than work out some other way to introduce this feature.
> Regstrapped on x86_64-linux-gnu, also tested on arm-eabi. Ok to
> install?
Ping?
Refreshed (minor conflict resolution) for GCC 15, retested.
Introduce attribute sym_alias
This patch introduces an attribute to add extra asm names (aliases)
for a decl when its definition is output. The main goal is to ease
interfacing C++ with Ada, as C++ mangled names have to be named, and
in some cases (e.g. when using stdint.h typedefs in function
arguments) the symbol names may vary across platforms.
The attribute is usable in C and C++, presumably in all C-family
languages. It can be attached to global variables and functions, and
also to local static variables. In C++, it can also be attached to
class types, namespace-scoped variables and functions, static data
members, member functions, explicit instantiations and specializations
of template functions, members and classes.
When applied to constructors or destructor, additional sym aliases
with _Base and _Del suffixes are defined for variants other than
complete-object ones. This changes the assumption that clones always
carry the same attributes as their abstract declarations, so there is
now a function to adjust them.
C++ also had a bug in which attributes from local extern declarations
failed to be propagated to a preexisting corresponding
namespace-scoped decl. I've fixed that, and adjusted acc tests that
distinguished between C and C++ in this regard.
Applying the attribute to class types is only valid in C++, and the
effect is to attach the alias to the RTTI object associated with the
class type.
for gcc/ChangeLog
* attribs.cc: Include cgraph.h.
(decl_attributes): Allow late introduction of sym_alias in
types.
(create_sym_alias_decl, create_sym_alias_decls): New.
* attribs.h: Declare them.
(FOR_EACH_SYM_ALIAS): New macro.
* cgraph.cc (cgraph_node::create): Create sym_alias decls.
* varpool.cc (varpool_node::get_create): Create sym_alias
decls.
* cgraph.h (symtab_node::remap_sym_alias_target): New.
* symtab.cc (symtab_node::remap_sym_alias_target): Define.
(symbol_table::insert_to_assembler_name_hash): Check for
symbol name clashes.
(symtab_node::noninterposable_alias): Drop sym_alias
attributes.
* cgraphunit.cc (cgraph_node::analyze): Create alias_target
node if needed.
(analyze_functions): Fixup visibility of implicit alias only
after its node is analyzed.
* doc/extend.texi (sym_alias): Document for variables,
functions and types.
for gcc/ada/ChangeLog
* doc/gnat_rm/interfacing_to_other_languages.rst: Mention
attribute sym_alias to give RTTI symbols mnemonic names.
* doc/gnat_ugn/the_gnat_compilation_model.rst: Mention
aliases. Fix incorrect ref to C1 ctor variant.
for gcc/c-family/ChangeLog
* c-ada-spec.cc (pp_asm_name): Use first sym_alias if
available.
* c-attribs.cc (handle_sym_alias_attribute): New.
(c_common_attribute_table): Add sym_alias.
(handle_copy_attribute): Do not copy sym_alias attribute.
for gcc/c/ChangeLog
* c-decl.cc (duplicate_decls): Remap sym_alias target.
(finish_decl): Create varpool_node for local static
variables.
for gcc/cp/ChangeLog
* class.cc (adjust_clone_attributes): New.
(copy_fndecl_with_name, build_clone): Call it.
* cp-tree.h (adjust_clone_attributes): Declare.
(update_sym_alias_interface): Declare.
(update_tinfo_sym_alias): Declare.
* decl.cc (duplicate_decls): Remap sym_alias target.
Adjust clone attributes.
(grokfndecl): Tentatively create sym_alias decls after
adding attributes in e.g. a template member function explicit
instantiation.
* decl2.cc (cplus_decl_attributes): Update tinfo sym_alias.
(copy_interface, update_sym_alias_interface): New.
(determine_visibility): Update sym_alias interface.
(tentative_decl_li
Re: [PATCH] adjust vectorization expectations for ppc costmodel 76b
On May 23, 2024, Alexandre Oliva wrote: > On Apr 29, 2024, "Kewen.Lin" wrote: >> I think you can still push the patch as the testing just exposes >> another issue. > ACK, thanks, I've just confirmed that the problem I reported on > ppc64el-linux-gnu didn't come up when testing on ppc64-vx7r2 with a > non-power8 emulated cpu, so I'm going to install it. I see I hadn't posted the latest version of the patch, with the updated attribution and commit message. Here it is. I'm checking it in. testsuite: adjust iteration count for ppc costmodel 76b From: Alexandre Oliva For some hardware which doesn't support unaligned vector memory access, test case costmodel-vect-76b.c expects to see cost modeling would make the decision that it's not profitable for peeling, according to the commit history, test case comments and the way to check. For now, the existing loop bound 14 works well for Power7, but it does not for some targets on which the cost of operation vec_perm can be different from Power7, such as: Power6, it's 3 vs. 1. This difference further causes the difference (10 vs. 12) on the minimum iteration for profitability and cause the failure. To keep the original test point, this patch is to tweak the loop bound to ensure it's not profitable to be vectorized for !vect_no_align with peeling. Co-Authored-By: Kewen Lin for gcc/testsuite/ChangeLog * gcc.dg/vect/costmodel/ppc/costmodel-vect-76b.c (N): Tweak. --- .../gcc.dg/vect/costmodel/ppc/costmodel-vect-76b.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/gcc/testsuite/gcc.dg/vect/costmodel/ppc/costmodel-vect-76b.c b/gcc/testsuite/gcc.dg/vect/costmodel/ppc/costmodel-vect-76b.c index cbbfbb24658f8..e48b0ab759e75 100644 --- a/gcc/testsuite/gcc.dg/vect/costmodel/ppc/costmodel-vect-76b.c +++ b/gcc/testsuite/gcc.dg/vect/costmodel/ppc/costmodel-vect-76b.c @@ -6,7 +6,7 @@ /* On Power7 without misalign vector support, this case is to check it's not profitable to perform vectorization by peeling to align the store. */ -#define N 14 +#define N 13 #define OFF 4 /* Check handling of accesses for which the "initial condition" - -- Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/ Free Software Activist GNU Toolchain Engineer More tolerance and less prejudice are key for inclusion and diversity Excluding neuro-others for not behaving ""normal"" is *not* inclusive
[PATCH] [testsuite] conditionalize dg-additional-sources on target and type
On Apr 30, 2024, Christophe Lyon wrote:
> On Tue, 30 Apr 2024 at 01:31, Alexandre Oliva wrote:
>> >> for gcc/testsuite/ChangeLog
>> >>
>> >> * lib/target-supports.exp (check_vect_support_and_set_flags):
>> >> Decay to link rather than compile.
>>
>> Alas, linking may fail because of an incompatible libc, as reported by
>> Linaro with a link to their issue GNU-1206 (I'm not posting the link to
>> the fully-Javascrippled Jira web page; it shows nothing useful, and I
>> can't post feedback there) and to
>> https://ci.linaro.org/job/tcwg_gnu_embed_check_gcc--master-thumb_m7_hard_eabi-build/10/artifact/artifacts/00-sumfiles/
>> (where I could get useful information)
>>
>> I'm reverting the patch, and I'll see about some alternate approach
> Indeed, that's another instance of the tricky multilibs configuration issues.
> - we run the tests with
> qemu/-mthumb/-march=armv7e-m+fp.dp/-mtune=cortex-m7/-mfloat-abi=hard/-mfpu=auto
> which matches the GCC configuration flags,
> but the vect.exp tests add -mfpu=neon -mfloat-abi=softfp -march=armv7-a
> and link fails because the toolchain does not support softfp libs
Hello, Christophe, thanks for the info.
I came up with an entirely different approach:
g++.dg/vect/pr95401.cc has dg-additional-sources, and that fails when
check_vect_support_and_set_flags finds vector support lacking for
execution tests: tests decay to compile tests, and additional sources
are rejected by the compiler when compiling to a named output file.
At first I considered using some effective target to conditionalize
the additional sources. There was no support for target-specific
additional sources, so I added that.
But then, I found that adding an effective target to check whether the
test involves linking would just make for busy work in this case, and
so I went ahead and adjusted the handling of additional sources to
refrain from adding them on compile tests, reporting them as
unsupported.
That solves the problem without using the newly-added machinery for
per-target additional sources, but I figured since I'd implemented it
I might as well contribute it, since there might be other uses for it.
Regstrapped on x86_64-linux-gnu. Also tested on ppc64-vx7r2 with
gcc-13. Ok to install?
for gcc/ChangeLog
* doc/sourcebuild.texi (dg-additional-sources): Document
newly-added support for target selectors, and implicit discard
on non-linking tests that name the compiler output explicitly.
for gcc/testsuite/ChangeLog
* lib/gcc-defs.exp (dg-additional-sources): Support target
selectors. Make it cumulative.
(dg-additional-files-options): Take dest and type. Note
unsupported additional sources when not linking and naming the
compiler output. Adjust source dirname prepending to cope
with leading blanks.
* lib/g++.exp (g++_target_compile): Pass dest and type on to
dg-additional-files-options.
* lib/gcc.exp (gcc_target_compile): Likewise.
* lib/gdc.exp (gdb_target_compile): Likewise.
* lib/gfortran.exp (gfortran_target_compile): Likewise.
* lib/go.exp (go_target_compile): Likewise.
* lib/obj-c++.exp (obj-c++_target_compile): Likewise.
* lib/objc.exp (objc_target_compile): Likewise.
* lib/rust.exp (rust_target_compile): Likewise.
* lib/profopt.exp (profopt-execute): Likewise-ish.
---
gcc/doc/sourcebuild.texi |8 +++-
gcc/testsuite/lib/g++.exp |2 +-
gcc/testsuite/lib/gcc-defs.exp | 35 ++-
gcc/testsuite/lib/gcc.exp |2 +-
gcc/testsuite/lib/gdc.exp |2 +-
gcc/testsuite/lib/gfortran.exp |2 +-
gcc/testsuite/lib/go.exp |2 +-
gcc/testsuite/lib/obj-c++.exp |2 +-
gcc/testsuite/lib/objc.exp |2 +-
gcc/testsuite/lib/profopt.exp |2 +-
gcc/testsuite/lib/rust.exp |2 +-
11 files changed, 46 insertions(+), 15 deletions(-)
diff --git a/gcc/doc/sourcebuild.texi b/gcc/doc/sourcebuild.texi
index 8e4e59ac44c74..e997dbec3334b 100644
--- a/gcc/doc/sourcebuild.texi
+++ b/gcc/doc/sourcebuild.texi
@@ -1320,9 +1320,15 @@ to @var{var_value} before execution of the program
created by the test.
Specify additional files, other than source files, that must be copied
to the system where the compiler runs.
-@item @{ dg-additional-sources "@var{filelist}" @}
+@item @{ dg-additional-sources "@var{filelist}" [@{ target @var{selector} @}]
@}
Specify additional source files to appear in the compile line
following the main test file.
+If the directive includes the optional @samp{@{ @var{selector} @}}
+then the additional sources are only added if the target system
+matches the @var{selector}.
+Additional sources are generally used only in @samp{link} and @samp{run}
+tests; they are reported as unsupported
Re: [PATCH] adjust vectorization expectations for ppc costmodel 76b
On Apr 29, 2024, "Kewen.Lin" wrote: > I think you can still push the patch as the testing just exposes > another issue. ACK, thanks, I've just confirmed that the problem I reported on ppc64el-linux-gnu didn't come up when testing on ppc64-vx7r2 with a non-power8 emulated cpu, so I'm going to install it. -- Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/ Free Software Activist GNU Toolchain Engineer More tolerance and less prejudice are key for inclusion and diversity Excluding neuro-others for not behaving ""normal"" is *not* inclusive
[PATCH v2] [testsuite] xfail pr79004 on longdouble64; drop long_double_64bit (was: ppc: testsuite: pr79004 needs -mlong-double-128)
sprintf (buffer, "%lg", b);
- return strcmp (buffer, "3") != 0;
- }
-} [add_options_for_ppc_long_double_override_64bit ""]]
-}
-
-# Return the appropriate options to specify that long double uses the IEEE
-# 64-bit format on PowerPC.
-
-proc add_options_for_long_double_64bit { flags } {
-if { [istarget powerpc*-*-*] } {
- return "$flags -mlong-double-64"
-}
-return "$flags"
-}
-
# Return 1 if the target supports executing VSX instructions, 0
# otherwise. Cache the result.
--
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
Free Software Activist GNU Toolchain Engineer
More tolerance and less prejudice are key for inclusion and diversity
Excluding neuro-others for not behaving ""normal"" is *not* inclusive
[PATCH] [testsuite] cope with rtems implicit -ftls-model=local-exec
ons "-ftls-model=global-dynamic" { target *-*-rtems* }
} */
typedef float v8si __attribute__ ((vector_size (32)));
diff --git a/gcc/testsuite/gcc.target/aarch64/sve/tls_preserve_3.c
b/gcc/testsuite/gcc.target/aarch64/sve/tls_preserve_3.c
index a19908f29b6a1..6e1a82698bde2 100644
--- a/gcc/testsuite/gcc.target/aarch64/sve/tls_preserve_3.c
+++ b/gcc/testsuite/gcc.target/aarch64/sve/tls_preserve_3.c
@@ -2,6 +2,7 @@
/* { dg-options "-O3 -fpic -msve-vector-bits=512 -fno-schedule-insns" } */
/* { dg-require-effective-target fpic } */
/* { dg-require-effective-target tls_native } */
+/* { dg-additional-options "-ftls-model=global-dynamic" { target *-*-rtems* }
} */
typedef float v16si __attribute__ ((vector_size (64)));
--
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
Free Software Activist GNU Toolchain Engineer
More tolerance and less prejudice are key for inclusion and diversity
Excluding neuro-others for not behaving ""normal"" is *not* inclusive
Re: [PATCH] make -freg-struct-return visibly a negative alias of -fpcc-struct-return
On Apr 30, 2024, Richard Biener wrote: > OK. Thanks, I'm back (from LibrePlanet), and I've just installed it in the trunk. >> for gcc/ChangeLog >> >> * common.opt (freg-struct-return): Make it explicitly >> fpcc-struct-return's NegativeAlias. Copy Optimization... >> (freg-struct-return): ... here. -- Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/ Free Software Activist GNU Toolchain Engineer More tolerance and less prejudice are key for inclusion and diversity Excluding neuro-others for not behaving ""normal"" is *not* inclusive
Re: [PATCH] decay vect tests from run to link for pr95401
On Apr 22, 2024, Richard Biener wrote: >> Regstrapped on x86_64-linux-gnu and ppc64el-linux-gnu. Also tested with >> gcc-13 on ppc64-vx7r2 and ppc-vx7r2. Ok to install? > That makes sense. OK >> for gcc/testsuite/ChangeLog >> >> * lib/target-supports.exp (check_vect_support_and_set_flags): >> Decay to link rather than compile. Alas, linking may fail because of an incompatible libc, as reported by Linaro with a link to their issue GNU-1206 (I'm not posting the link to the fully-Javascrippled Jira web page; it shows nothing useful, and I can't post feedback there) and to https://ci.linaro.org/job/tcwg_gnu_embed_check_gcc--master-thumb_m7_hard_eabi-build/10/artifact/artifacts/00-sumfiles/ (where I could get useful information) I'm reverting the patch, and I'll see about some alternate approach that can accommodate this scenario after I return from LibrePlanet. -- Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/ Free Software Activist GNU Toolchain Engineer More tolerance and less prejudice are key for inclusion and diversity Excluding neuro-others for not behaving ""normal"" is *not* inclusive
Re: [PATCH] ppc: testsuite: pr79004 needs -mlong-double-128
On Apr 29, 2024, "Kewen.Lin" wrote: > Thanks for catching this and sorry > that I didn't check it before suggesting it, I think we can aggressively > drop this effective target instead to avoid any possible confusion. The 128-bit ones, unfortunately, follow the same pattern but are probably used. IMHO we should transition all 3 to an '_ok' suffix, but... > How about the generic one "longdouble64"? I did a grep and found it has one > use, I'd expect it can work here. :) ... since this and longdouble128 exist, maybe we can fix it and leave them all alone, despite the interface oddity. -- Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/ Free Software Activist GNU Toolchain Engineer More tolerance and less prejudice are key for inclusion and diversity Excluding neuro-others for not behaving ""normal"" is *not* inclusive
Re: [PATCH] ppc: testsuite: pr79004 needs -mlong-double-128
On Apr 28, 2024, "Kewen.Lin" wrote:
> OK, from this perspective IMHO it seems more clear to adopt xfail
> with effective target long_double_64bit?
That's effective target is quite broken, alas. I doubt it's used
anywhere: it calls an undefined proc, and its memcmp call seems to have
the size cut from the 128-bit functions. (a patchlet that
fixes these most glaring issues is below)
Furthermore, it doesn't really work. Since it adds -mlong-double-64 for
the effective target test, it overrides the default, so it sort of
always passes, even on a 128-bit long double target. But since the test
itself doesn't add that option, any xfails on long_double_64bit would be
flagged as XPASS.
There's no effective target test for 64-bit long double that doesn't
override the default, so we'd have to add one. Alas, the natural name
for it is the one that's taken with overriding behavior, and the current
option-overriding tests, that need to be used along with the
corresponding add-options in testcases, might benefit from a renaming to
make them fit the already-established (?) naming standards. Yuck.
diff --git a/gcc/testsuite/lib/target-supports.exp
b/gcc/testsuite/lib/target-supports.exp
index 182d80129de9b..603da25c97d67 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -2961,12 +2961,12 @@ proc check_effective_target_long_double_64bit { } {
/* eliminate removing volatile cast warning. */
a2 = a;
b2 = b;
- if (memcmp (, , 16) != 0)
+ if (memcmp (, , 8) != 0)
return 1;
sprintf (buffer, "%lg", b);
return strcmp (buffer, "3") != 0;
}
-} [add_options_for_ppc_long_double_override_64bit ""]]
+} [add_options_for_long_double_64bit ""]]
}
# Return the appropriate options to specify that long double uses the IEEE
--
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
Free Software Activist GNU Toolchain Engineer
More tolerance and less prejudice are key for inclusion and diversity
Excluding neuro-others for not behaving ""normal"" is *not* inclusive
Re: [PATCH] ppc: testsuite: pr79004 needs -mlong-double-128
On Apr 28, 2024, "Kewen.Lin" wrote: > OK, from this perspective IMHO it seems more clear to adopt xfail > with effective target long_double_64bit? *nod*, yeah, that makes sense. I'm going to travel this week, to speak at FSF's LibrePlanet conference, so I'll look into massaging the patch into that when I get back, if you haven't rendered it obsolete by then ;-) Thanks, -- Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/ Free Software Activist GNU Toolchain Engineer More tolerance and less prejudice are key for inclusion and diversity Excluding neuro-others for not behaving ""normal"" is *not* inclusive
Re: [PATCH] adjust vectorization expectations for ppc costmodel 76b
On Apr 28, 2024, "Kewen.Lin" wrote: > Nit: Maybe add a prefix "testsuite: ". ACK >> >> From: Kewen Lin > Thanks, you can just drop this. :) I've turned it into Co-Authored-By, since you insist. But unfortunately with the patch it still fails when testing for -mcpu=power7 on ppc64le-linux-gnu: it does vectorize the loop with 13 iterations. We need 16 iterations, as in an earlier version of this test, for it to pass for -mcpu=power7, but then it doesn't pass for -mcpu=power6. It looks like we're going to have to adjust the expectations. -- Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/ Free Software Activist GNU Toolchain Engineer More tolerance and less prejudice are key for inclusion and diversity Excluding neuro-others for not behaving ""normal"" is *not* inclusive
[PATCH] make -freg-struct-return visibly a negative alias of -fpcc-struct-return
The fact that both options accept negative forms suggests that maybe they aren't negative forms of each other. They are, but that isn't clear even by examining common.opt. Use NegativeAlias to make it abundantly clear. The 'Optimization' keyword next to freg-struct-return was the only thing that caused flag_pcc_struct_return to be a per-function flag, and ipa-inline relied on that. After making it an alias, the Optimization keyword was no longer operational. I'm not sure it was sensible or desirable for flag_pcc_struct_return to be a per-function setting, but this patch does not intend to change behavior. Regstrapped on x86_64-linux-gnu and ppc64le-linux-gnu. Ok to install? for gcc/ChangeLog * common.opt (freg-struct-return): Make it explicitly fpcc-struct-return's NegativeAlias. Copy Optimization... (freg-struct-return): ... here. --- gcc/common.opt |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/gcc/common.opt b/gcc/common.opt index ad3488447752b..12d93c76a1e63 100644 --- a/gcc/common.opt +++ b/gcc/common.opt @@ -2406,7 +2406,7 @@ Common RejectNegative Joined UInteger Optimization -fpack-struct= Set initial maximum structure member alignment. fpcc-struct-return -Common Var(flag_pcc_struct_return,1) Init(DEFAULT_PCC_STRUCT_RETURN) +Common Var(flag_pcc_struct_return,1) Init(DEFAULT_PCC_STRUCT_RETURN) Optimization Return small aggregates in memory, not registers. fpeel-loops @@ -2596,7 +2596,7 @@ Common Var(flag_record_gcc_switches) Record gcc command line switches in the object file. freg-struct-return -Common Var(flag_pcc_struct_return,0) Optimization +Common NegativeAlias Alias(fpcc_struct_return) Optimization Return small aggregates in registers. fregmove -- Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/ Free Software Activist GNU Toolchain Engineer More tolerance and less prejudice are key for inclusion and diversity Excluding neuro-others for not behaving ""normal"" is *not* inclusive
Re: [PATCH] ppc: testsuite: pr79004 needs -mlong-double-128
On Apr 23, 2024, "Kewen.Lin" wrote:
> This patch seemed to miss to CC gcc-patches list. :)
Oops, sorry, thanks for catching that.
Here it is. FTR, you've already responded suggesting an apparent
preference for addressing PR105359, but since I meant to contribute it,
I'm reposting is to gcc-patches, now with a reference to the PR.
ppc: testsuite: pr79004 needs -mlong-double-128
Some of the asm opcodes expected by pr79004 depend on
-mlong-double-128 to be output. E.g., without this flag, the
conditions of patterns @extenddf2 and extendsf2 do not
hold, and so GCC resorts to libcalls instead of even trying
rs6000_expand_float128_convert.
Perhaps the conditions are too strict, and they could enable the use
of conversion insns involving __ieee128/_Float128 even with 64-bit
long doubles. Alas, for now, we need this flag for the test to pass
on target variants that use 64-bit long doubles.
for gcc/testsuite/ChangeLog
* gcc.target/powerpr/pr79004.c: Add -mlong-double-128.
---
gcc/testsuite/gcc.target/powerpc/pr79004.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/testsuite/gcc.target/powerpc/pr79004.c
b/gcc/testsuite/gcc.target/powerpc/pr79004.c
index e411702dc98a9..061a0e83fe2ad 100644
--- a/gcc/testsuite/gcc.target/powerpc/pr79004.c
+++ b/gcc/testsuite/gcc.target/powerpc/pr79004.c
@@ -1,6 +1,6 @@
/* { dg-do compile { target { powerpc*-*-* && lp64 } } } */
/* { dg-require-effective-target powerpc_p9vector_ok } */
-/* { dg-options "-mdejagnu-cpu=power9 -O2 -mfloat128" } */
+/* { dg-options "-mdejagnu-cpu=power9 -O2 -mfloat128 -mlong-double-128" } */
/* { dg-prune-output ".-mfloat128. option may not be fully supported" } */
#include
--
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
Free Software Activist GNU Toolchain Engineer
More tolerance and less prejudice are key for inclusion and diversity
Excluding neuro-others for not behaving ""normal"" is *not* inclusive
Re: [PATCH] adjust vectorization expectations for ppc costmodel 76b
On Apr 24, 2024, "Kewen.Lin" wrote: > For !has_arch_pwr7 case, it still adopts peeling but as the comment (one line > above) > shows the original intention of this case is to expect not profitable for > peeling > so it's not expected to be handled here, can we just tweak the loop bound > instead, > such as: > -#define N 14 > +#define N 13 > #define OFF 4 > ?, it can make this loop not profitable to be vectorized for !vect_no_align > with > peeling (both pwr7 and pwr6) and keep consistent. Like this? I didn't feel I could claim authorship of this one-liner just because I turned it into a patch and tested it, so I took the liberty of turning your own words above into the commit message. So far, tested on ppc64le-linux-gnu (ppc9). Testing with vxworks targets now. Would you like to tweak the commit message to your liking? Otherwise, is this ok to install? Thanks, adjust iteration count for ppc costmodel 76b From: Kewen Lin The original intention of this case is to expect not profitable for peeling. Tweak the loop bound to make this loop not profitable to be vectorized for !vect_no_align with peeling (both pwr7 and pwr6) and keep consistent. for gcc/testsuite/ChangeLog * gcc.dg/vect/costmodel/ppc/costmodel-vect-76b.c (N): Tweak. --- .../gcc.dg/vect/costmodel/ppc/costmodel-vect-76b.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/gcc/testsuite/gcc.dg/vect/costmodel/ppc/costmodel-vect-76b.c b/gcc/testsuite/gcc.dg/vect/costmodel/ppc/costmodel-vect-76b.c index cbbfbb24658f8..e48b0ab759e75 100644 --- a/gcc/testsuite/gcc.dg/vect/costmodel/ppc/costmodel-vect-76b.c +++ b/gcc/testsuite/gcc.dg/vect/costmodel/ppc/costmodel-vect-76b.c @@ -6,7 +6,7 @@ /* On Power7 without misalign vector support, this case is to check it's not profitable to perform vectorization by peeling to align the store. */ -#define N 14 +#define N 13 #define OFF 4 /* Check handling of accesses for which the "initial condition" - -- Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/ Free Software Activist GNU Toolchain Engineer More tolerance and less prejudice are key for inclusion and diversity Excluding neuro-others for not behaving ""normal"" is *not* inclusive
Re: enable sqrt insns for cdce3.c
On Apr 23, 2024, Hans-Peter Nilsson wrote: > (We could also fix the predicate description to actually say > "for all floating-point modes" and/or split the predicate into > mode-specific variants, etc. ;-) Yeah, I suppose that could make sense. > MMIX has sqrtdf2 but not sqrtsf2, and the latter is what's used > in cdce3.c. I see, thanks for the info. -- Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/ Free Software Activist GNU Toolchain Engineer More tolerance and less prejudice are key for inclusion and diversity Excluding neuro-others for not behaving ""normal"" is *not* inclusive
Re: [PATCH v2] [testsuite] require sqrt_insn effective target where needed
erpc/pr46728-14.c
@@ -1,6 +1,6 @@
/* { dg-do run } */
-/* { dg-skip-if "-mpowerpc-gpopt not supported" { powerpc*-*-darwin* } } */
/* { dg-options "-O2 -ffast-math -fno-inline -fno-unroll-loops -lm
-mpowerpc-gpopt" } */
+/* { dg-require-effective-target sqrt_insn } */
#include
--
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
Free Software Activist GNU Toolchain Engineer
More tolerance and less prejudice are key for inclusion and diversity
Excluding neuro-others for not behaving ""normal"" is *not* inclusive
Re: [PATCH v2] xfail fetestexcept test - ppc always uses fcmpu
On Apr 23, 2024, "Kewen.Lin" wrote:
>> --- a/gcc/testsuite/gcc.dg/torture/pr91323.c
>> +++ b/gcc/testsuite/gcc.dg/torture/pr91323.c
>> @@ -1,4 +1,5 @@
>> -/* { dg-do run } */
>> +/* { dg-do run { xfail powerpc*-*-* } } */
>> +/* The ppc xfail is because of PR target/58684. */
> OK, though the proposed comment is slightly different from what's in
> the related commit r8-6445-g86145a19abf39f. :) Thanks!
Oh, thanks for the pointer, that was easy to fix. Here's what I'm
pushing momentarily...
xfail fetestexcept test - ppc always uses fcmpu
gcc.dg/torture/pr91323.c tests that a compare with NaNf doesn't set an
exception using builtin compare intrinsics, and that it does when
using regular compare operators.
That doesn't seem to be expected to work on powerpc targets. It fails
on GNU/Linux, it's marked to be skipped on AIX, and a similar test,
gcc.dg/torture/pr93133.c, has the execution test xfailed for all of
powerpc*-*-*.
In this test, the functions that use intrinsics for the compare end up
with the same code as the one that uses compare operators, using
fcmpu, a floating compare that, unlike fcmpo, does not set the invalid
operand exception for quiet NaN. I couldn't find any evidence that
the rs6000 backend ever outputs fcmpo. Therefore, I'm adding the same
execution xfail marker to this test.
for gcc/testsuite/ChangeLog
PR target/58684
* gcc.dg/torture/pr91323.c: Expect execution fail on
powerpc*-*-*.
---
gcc/testsuite/gcc.dg/torture/pr91323.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/gcc/testsuite/gcc.dg/torture/pr91323.c
b/gcc/testsuite/gcc.dg/torture/pr91323.c
index 1411fcaa3966c..4574342e728db 100644
--- a/gcc/testsuite/gcc.dg/torture/pr91323.c
+++ b/gcc/testsuite/gcc.dg/torture/pr91323.c
@@ -1,4 +1,5 @@
-/* { dg-do run } */
+/* { dg-do run { xfail powerpc*-*-* } } */
+/* remove the xfail for powerpc when pr58684 is fixed */
/* { dg-add-options ieee } */
/* { dg-require-effective-target fenv_exceptions } */
/* { dg-skip-if "fenv" { powerpc-ibm-aix* } } */
--
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
Free Software Activist GNU Toolchain Engineer
More tolerance and less prejudice are key for inclusion and diversity
Excluding neuro-others for not behaving ""normal"" is *not* inclusive
Re: [PATCH] ppc: testsuite: vec-mul requires vsx runtime
On Apr 23, 2024, "Kewen.Lin" wrote:
>> -/* { dg-do run } */
>> +/* { dg-do compile { target { ! vsx_hw } } } */
>> +/* { dg-do run { target vsx_hw } } */
>> /* { dg-require-effective-target powerpc_vsx_ok } */
> Nit: It's useless to check powerpc_vsx_ok for vsx_hw, so powerpc_vsx_ok check
> can be moved to be with ! vsx_hw.
> OK with this nit tweaked, thanks!
Thanks, here's what I'm pushing momentarily...
ppc: testsuite: vec-mul requires vsx runtime
vec-mul is an execution test, but it only requires a powerpc_vsx_ok
effective target, which is enough only for compile tests. In order to
check for runtime and execution environment support, we need to
require vsx_hw. Make that a condition for execution, but still
perform a compile test if the condition is not satisfied.
for gcc/testsuite/ChangeLog
* gcc.target/powerpc/vec-mul.c: Run on target vsx_hw, just
compile otherwise.
---
gcc/testsuite/gcc.target/powerpc/vec-mul.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/gcc/testsuite/gcc.target/powerpc/vec-mul.c
b/gcc/testsuite/gcc.target/powerpc/vec-mul.c
index bfcaf80719d1d..aa0ef7aa45acc 100644
--- a/gcc/testsuite/gcc.target/powerpc/vec-mul.c
+++ b/gcc/testsuite/gcc.target/powerpc/vec-mul.c
@@ -1,5 +1,5 @@
-/* { dg-do run } */
-/* { dg-require-effective-target powerpc_vsx_ok } */
+/* { dg-do compile { target { { ! vsx_hw } && powerpc_vsx_ok } } } */
+/* { dg-do run { target vsx_hw } } */
/* { dg-options "-mvsx -O3" } */
/* Test that the vec_mul builtin works as expected. */
--
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
Free Software Activist GNU Toolchain Engineer
More tolerance and less prejudice are key for inclusion and diversity
Excluding neuro-others for not behaving ""normal"" is *not* inclusive
[PATCH v2] [testsuite] [powerpc] adjust -m32 counts for fold-vec-extract*
Ping?-ish
https://gcc.gnu.org/pipermail/gcc-patches/2023-May/619678.html
It's that time of the year again. The good news is that this is the
last patch in my ppc*-vxworks7* set ;-)
On May 25, 2023, Segher Boessenkool wrote:
> On Thu, May 25, 2023 at 10:55:37AM -0300, Alexandre Oliva wrote:
>> I've actually identified the corresponding change to the
>> lp64 tests, compared the effects of the codegen changes, and concluded
>> the tests needed this changing for ilp32 to keep on testing for the same
>> thing after code changes brought about by changes that AFAICT had been
>> well understood when making the lp64 adjustments.
>> /* -m32 target has an 'add' in place of one of the 'addi'. */
>> -/* { dg-final { scan-assembler-times {\maddi\M|\madd\M} 2 { target lp64 } }
>> } */
>> -/* { dg-final { scan-assembler-times {\maddi\M|\madd\M} 3 { target ilp32 }
>> } } */
>> +/* { dg-final { scan-assembler-times {\maddi\M|\madd\M} 2 } } */
> Just {\madd} or more conservative {\maddi?\M} then?
I've made these changes in the v2 below.
Codegen changes caused add instruction count mismatches on
ppc-*-linux-gnu and other 32-bit ppc targets. At some point the
expected counts were adjusted for lp64, but ilp32 differences
remained, and published test results confirm it.
Regstrapped on x86_64-linux-gnu and ppc64el-linux-gnu. Also tested with
gcc-13 on ppc64-vx7r2 and ppc-vx7r2. Ok to install?
for gcc/testsuite/ChangeLog
PR testsuite/101169
* gcc.target/powerpc/fold-vec-extract-double.p7.c: Adjust addi
counts for ilp32.
* gcc.target/powerpc/fold-vec-extract-float.p7.c: Likewise.
* gcc.target/powerpc/fold-vec-extract-float.p8.c: Likewise.
* gcc.target/powerpc/fold-vec-extract-int.p7.c: Likewise.
* gcc.target/powerpc/fold-vec-extract-int.p8.c: Likewise.
* gcc.target/powerpc/fold-vec-extract-short.p7.c: Likewise.
* gcc.target/powerpc/fold-vec-extract-short.p8.c: Likewise.
---
.../powerpc/fold-vec-extract-double.p7.c |5 ++---
.../gcc.target/powerpc/fold-vec-extract-float.p7.c |5 ++---
.../gcc.target/powerpc/fold-vec-extract-float.p8.c |2 +-
.../gcc.target/powerpc/fold-vec-extract-int.p7.c |3 +--
.../gcc.target/powerpc/fold-vec-extract-int.p8.c |2 +-
.../gcc.target/powerpc/fold-vec-extract-short.p7.c |3 +--
.../gcc.target/powerpc/fold-vec-extract-short.p8.c |2 +-
7 files changed, 9 insertions(+), 13 deletions(-)
diff --git a/gcc/testsuite/gcc.target/powerpc/fold-vec-extract-double.p7.c
b/gcc/testsuite/gcc.target/powerpc/fold-vec-extract-double.p7.c
index 3cae644b90b71..e69d9253e2d28 100644
--- a/gcc/testsuite/gcc.target/powerpc/fold-vec-extract-double.p7.c
+++ b/gcc/testsuite/gcc.target/powerpc/fold-vec-extract-double.p7.c
@@ -13,12 +13,11 @@
/* { dg-final { scan-assembler-times {\mxxpermdi\M} 1 } } */
/* { dg-final { scan-assembler-times {\mli\M} 1 } } */
/* -m32 target has an 'add' in place of one of the 'addi'. */
-/* { dg-final { scan-assembler-times {\maddi\M|\madd\M} 2 { target lp64 } } }
*/
-/* { dg-final { scan-assembler-times {\maddi\M|\madd\M} 3 { target ilp32 } } }
*/
+/* { dg-final { scan-assembler-times {\maddi?\M} 2 } } */
/* -m32 target has a rlwinm in place of a rldic . */
/* { dg-final { scan-assembler-times {\mrldic\M|\mrlwinm\M} 1 } } */
/* { dg-final { scan-assembler-times {\mstxvd2x\M} 1 } } */
-/* { dg-final { scan-assembler-times {\mlfdx\M|\mlfd\M} 1 } } */
+/* { dg-final { scan-assembler-times {\mlfdx?\M} 1 } } */
#include
diff --git a/gcc/testsuite/gcc.target/powerpc/fold-vec-extract-float.p7.c
b/gcc/testsuite/gcc.target/powerpc/fold-vec-extract-float.p7.c
index 59a4979457dcb..9ff197a704906 100644
--- a/gcc/testsuite/gcc.target/powerpc/fold-vec-extract-float.p7.c
+++ b/gcc/testsuite/gcc.target/powerpc/fold-vec-extract-float.p7.c
@@ -12,13 +12,12 @@
/* { dg-final { scan-assembler-times {\mxscvspdp\M} 1 } } */
/* { dg-final { scan-assembler-times {\mli\M} 1 } } */
/* -m32 as an add in place of an addi. */
-/* { dg-final { scan-assembler-times {\maddi\M|\madd\M} 2 { target lp64 } } }
*/
-/* { dg-final { scan-assembler-times {\maddi\M|\madd\M} 3 { target ilp32 } } }
*/
+/* { dg-final { scan-assembler-times {\maddi?\M} 2 } } */
/* { dg-final { scan-assembler-times {\mstxvd2x\M|\mstvx\M|\mstxv\M} 1 } } */
/* -m32 uses rlwinm in place of rldic */
/* { dg-final { scan-assembler-times {\mrldic\M|\mrlwinm\M} 1 } } */
/* -m32 has lfs in place of lfsx */
-/* { dg-final { scan-assembler-times {\mlfsx\M|\mlfs\M} 1 } } */
+/* { dg-final { scan-assembler-times {\mlfsx?\M} 1 } } */
#include
diff --git a/gcc/testsuite/gcc.target/powerpc/fold-vec-extract-float.p8.c
b/gcc/testsuite/gcc.target/powerpc/fold-vec-extract-float.p8.c
index ce4e43c1fb462..cd80c5e1b19c6 100644
--- a/gcc/testsuite/gcc.target/powerpc/fold-vec-extract-float.p8.c
+++ b/gcc/testsuite/gcc.target/powerpc/fold-vec-ex
[PATCH] decay vect tests from run to link for pr95401
Ping?-ish for the full version of the RFC posted at
https://gcc.gnu.org/pipermail/gcc-patches/2021-March/566588.html
On Mar 11, 2021, Richard Biener wrote:
> On Thu, Mar 11, 2021 at 9:03 AM Alexandre Oliva wrote:
>> So I'm leaning towards this proposed change, just extended to other
>> platforms that also decay from run to compile rather than link, and thus
>> run into this problem in g++.dg/vect/pr95401.cc. Would this be
>> acceptable?
> I think that's OK. It's probably difficult to make the test UNSUPPORTED
> when dg-additional-sources is discovered with a dg-do compile test?
Thanks, here's a completed version.
When vect.exp finds our configuration disables altivec by default, it
disables the execution of vectorization tests, assuming the test
hardware doesn't support it.
Tests become just compile tests, but compile tests won't work
correctly when additional sources are named, e.g. pr95401.cc, because
GCC refuses to compile multiple files into the same asm output.
With this patch, the default for when execution is not possible
becomes link.
Regstrapped on x86_64-linux-gnu and ppc64el-linux-gnu. Also tested with
gcc-13 on ppc64-vx7r2 and ppc-vx7r2. Ok to install?
for gcc/testsuite/ChangeLog
* lib/target-supports.exp (check_vect_support_and_set_flags):
Decay to link rather than compile.
---
gcc/testsuite/lib/target-supports.exp | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/gcc/testsuite/lib/target-supports.exp
b/gcc/testsuite/lib/target-supports.exp
index 3a5713d98691f..54a55585371b0 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -11625,7 +11625,7 @@ proc check_vect_support_and_set_flags { } {
if [check_750cl_hw_available] {
set dg-do-what-default run
} else {
-set dg-do-what-default compile
+set dg-do-what-default link
}
} elseif [istarget powerpc*-*-*] {
# Skip targets not supporting -maltivec.
@@ -11655,14 +11655,14 @@ proc check_vect_support_and_set_flags { } {
# some other cpu type specified above.
set DEFAULT_VECTCFLAGS [linsert $DEFAULT_VECTCFLAGS 0
"-mcpu=970"]
}
-set dg-do-what-default compile
+set dg-do-what-default link
}
} elseif { [istarget i?86-*-*] || [istarget x86_64-*-*] } {
lappend DEFAULT_VECTCFLAGS "-msse2"
if { [check_effective_target_sse2_runtime] } {
set dg-do-what-default run
} else {
-set dg-do-what-default compile
+set dg-do-what-default link
}
} elseif { [istarget mips*-*-*]
&& [check_effective_target_nomips16] } {
@@ -11681,7 +11681,7 @@ proc check_vect_support_and_set_flags { } {
if [check_effective_target_ultrasparc_hw] {
set dg-do-what-default run
} else {
-set dg-do-what-default compile
+set dg-do-what-default link
}
} elseif [istarget alpha*-*-*] {
# Alpha's vectorization capabilities are extremely limited.
@@ -11694,7 +11694,7 @@ proc check_vect_support_and_set_flags { } {
if [check_alpha_max_hw_available] {
set dg-do-what-default run
} else {
-set dg-do-what-default compile
+set dg-do-what-default link
}
} elseif [istarget ia64-*-*] {
set dg-do-what-default run
@@ -11707,7 +11707,7 @@ proc check_vect_support_and_set_flags { } {
if [is-effective-target arm_neon_hw] {
set dg-do-what-default run
} else {
-set dg-do-what-default compile
+set dg-do-what-default link
}
} elseif [istarget aarch64*-*-*] {
set dg-do-what-default run
@@ -11731,7 +11731,7 @@ proc check_vect_support_and_set_flags { } {
set dg-do-what-default run
} else {
lappend DEFAULT_VECTCFLAGS "-march=z14" "-mzarch"
-set dg-do-what-default compile
+set dg-do-what-default link
}
} elseif [istarget amdgcn-*-*] {
set dg-do-what-default run
@@ -11742,7 +11742,7 @@ proc check_vect_support_and_set_flags { } {
foreach item [add_options_for_riscv_v ""] {
lappend DEFAULT_VECTCFLAGS $item
}
- set dg-do-what-default compile
+ set dg-do-what-default link
}
} elseif [istarget loongarch*-*-*] {
# Set the default vectorization option to "-mlsx" due to the problem
@@ -11751,7 +11751,7 @@ proc check_vect_support_and_set_flags { } {
if [check_effective_target_loongarch_sx_hw] {
set dg-do-what-default run
} else {
- set dg-do-what-default compile
+ set dg-do-what-default link
}
} else {
return 0
[PATCH v2] xfail fetestexcept test - ppc always uses fcmpu
On Mar 10, 2021, Joseph Myers wrote:
> On Wed, 10 Mar 2021, Alexandre Oliva wrote:
>> operand exception for quiet NaN. I couldn't find any evidence that
>> the rs6000 backend ever outputs fcmpo. Therefore, I'm adding the same
>> execution xfail marker to this test.
> In my view, such an XFAIL (for a GCC bug as opposed to an environmental
> issue) should have a comment pointing to a corresponding open bug in GCC
> Bugzilla. In this case, that's bug 58684.
Thanks for the suggestion, yeah, that makes sense. Fixed in v2 below.
https://gcc.gnu.org/pipermail/gcc-patches/2021-March/566523.html
Ping?-ish
gcc.dg/torture/pr91323.c tests that a compare with NaNf doesn't set an
exception using builtin compare intrinsics, and that it does when
using regular compare operators.
That doesn't seem to be expected to work on powerpc targets. It fails
on GNU/Linux, it's marked to be skipped on AIX, and a similar test,
gcc.dg/torture/pr93133.c, has the execution test xfailed for all of
powerpc*-*-*.
In this test, the functions that use intrinsics for the compare end up
with the same code as the one that uses compare operators, using
fcmpu, a floating compare that, unlike fcmpo, does not set the invalid
operand exception for quiet NaN. I couldn't find any evidence that
the rs6000 backend ever outputs fcmpo. Therefore, I'm adding the same
execution xfail marker to this test.
Regstrapped on x86_64-linux-gnu and ppc64el-linux-gnu. Also tested with
gcc-13 on ppc64-vx7r2 and ppc-vx7r2. Ok to install?
for gcc/testsuite/ChangeLog
PR target/58684
* gcc.dg/torture/pr91323.c: Expect execution fail on
powerpc*-*-*.
---
gcc/testsuite/gcc.dg/torture/pr91323.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/gcc/testsuite/gcc.dg/torture/pr91323.c
b/gcc/testsuite/gcc.dg/torture/pr91323.c
index 1411fcaa3966c..f188faa3ccf47 100644
--- a/gcc/testsuite/gcc.dg/torture/pr91323.c
+++ b/gcc/testsuite/gcc.dg/torture/pr91323.c
@@ -1,4 +1,5 @@
-/* { dg-do run } */
+/* { dg-do run { xfail powerpc*-*-* } } */
+/* The ppc xfail is because of PR target/58684. */
/* { dg-add-options ieee } */
/* { dg-require-effective-target fenv_exceptions } */
/* { dg-skip-if "fenv" { powerpc-ibm-aix* } } */
--
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
Free Software Activist GNU Toolchain Engineer
More tolerance and less prejudice are key for inclusion and diversity
Excluding neuro-others for not behaving ""normal"" is *not* inclusive
[PATCH v2] [testsuite] require sqrt_insn effective target where needed
This patch takes feedback received for 3 earlier patches, and adopts a
simpler approach to skip the still-failing tests, that I believe to be
in line with ppc maintainers' expressed preferences.
https://gcc.gnu.org/pipermail/gcc-patches/2021-February/565939.html
https://gcc.gnu.org/pipermail/gcc-patches/2021-March/566617.html
https://gcc.gnu.org/pipermail/gcc-patches/2021-March/566521.html
Ping?-ish :-)
Some tests fail on ppc and ppc64 when testing a compiler [with options
for] for a CPU [emulator] that doesn't support the sqrt insn.
The gcc.dg/cdce3.c is one in which the expected shrink-wrap
optimization only takes place when the target CPU supports a sqrt
insn.
The gcc.target/powerpc/pr46728-1[0-4].c tests use -mpowerpc-gpopt and
call sqrt(), which involves the sqrt insn that the target CPU under
test may not support.
Require a sqrt_insn effective target for all the affected tests.
Regstrapped on x86_64-linux-gnu and ppc64el-linux-gnu. Also testing
with gcc-13 on ppc64-vx7r2 and ppc-vx7r2. Ok to install?
for gcc/testsuite/ChangeLog
* gcc.dg/cdce3.c: Require sqrt_insn effective target.
* gcc.target/powerpc/pr46728-10.c: Likewise.
* gcc.target/powerpc/pr46728-11.c: Likewise.
* gcc.target/powerpc/pr46728-13.c: Likewise.
* gcc.target/powerpc/pr46728-14.c: Likewise.
---
gcc/testsuite/gcc.dg/cdce3.c |3 ++-
gcc/testsuite/gcc.target/powerpc/pr46728-10.c |1 +
gcc/testsuite/gcc.target/powerpc/pr46728-11.c |1 +
gcc/testsuite/gcc.target/powerpc/pr46728-13.c |1 +
gcc/testsuite/gcc.target/powerpc/pr46728-14.c |1 +
5 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/gcc/testsuite/gcc.dg/cdce3.c b/gcc/testsuite/gcc.dg/cdce3.c
index 601ddf055fd71..f759a95972e8b 100644
--- a/gcc/testsuite/gcc.dg/cdce3.c
+++ b/gcc/testsuite/gcc.dg/cdce3.c
@@ -1,7 +1,8 @@
/* { dg-do compile } */
/* { dg-require-effective-target hard_float } */
+/* { dg-require-effective-target sqrt_insn } */
/* { dg-options "-O2 -fmath-errno -fdump-tree-cdce-details
-fdump-tree-optimized" } */
-/* { dg-final { scan-tree-dump "cdce3.c:11: \[^\n\r]* function call is
shrink-wrapped into error conditions\." "cdce" } } */
+/* { dg-final { scan-tree-dump "cdce3.c:12: \[^\n\r]* function call is
shrink-wrapped into error conditions\." "cdce" } } */
/* { dg-final { scan-tree-dump "sqrtf \\(\[^\n\r]*\\); \\\[tail call\\\]"
"optimized" } } */
/* { dg-skip-if "doesn't have a sqrtf insn" { mmix-*-* } } */
diff --git a/gcc/testsuite/gcc.target/powerpc/pr46728-10.c
b/gcc/testsuite/gcc.target/powerpc/pr46728-10.c
index 3be4728d333a4..7e9bb638106c2 100644
--- a/gcc/testsuite/gcc.target/powerpc/pr46728-10.c
+++ b/gcc/testsuite/gcc.target/powerpc/pr46728-10.c
@@ -1,6 +1,7 @@
/* { dg-do run } */
/* { dg-skip-if "-mpowerpc-gpopt not supported" { powerpc*-*-darwin* } } */
/* { dg-options "-O2 -ffast-math -fno-inline -fno-unroll-loops -lm
-mpowerpc-gpopt" } */
+/* { dg-require-effective-target sqrt_insn } */
#include
diff --git a/gcc/testsuite/gcc.target/powerpc/pr46728-11.c
b/gcc/testsuite/gcc.target/powerpc/pr46728-11.c
index 43b6728a4b812..5bfa25925675a 100644
--- a/gcc/testsuite/gcc.target/powerpc/pr46728-11.c
+++ b/gcc/testsuite/gcc.target/powerpc/pr46728-11.c
@@ -1,6 +1,7 @@
/* { dg-do run } */
/* { dg-skip-if "-mpowerpc-gpopt not supported" { powerpc*-*-darwin* } } */
/* { dg-options "-O2 -ffast-math -fno-inline -fno-unroll-loops -lm
-mpowerpc-gpopt" } */
+/* { dg-require-effective-target sqrt_insn } */
#include
diff --git a/gcc/testsuite/gcc.target/powerpc/pr46728-13.c
b/gcc/testsuite/gcc.target/powerpc/pr46728-13.c
index b9fd63973b728..b66d0209a5e54 100644
--- a/gcc/testsuite/gcc.target/powerpc/pr46728-13.c
+++ b/gcc/testsuite/gcc.target/powerpc/pr46728-13.c
@@ -1,6 +1,7 @@
/* { dg-do run } */
/* { dg-skip-if "-mpowerpc-gpopt not supported" { powerpc*-*-darwin* } } */
/* { dg-options "-O2 -ffast-math -fno-inline -fno-unroll-loops -lm
-mpowerpc-gpopt" } */
+/* { dg-require-effective-target sqrt_insn } */
#include
diff --git a/gcc/testsuite/gcc.target/powerpc/pr46728-14.c
b/gcc/testsuite/gcc.target/powerpc/pr46728-14.c
index 5a13bdb6c..71a1a70c4e7a2 100644
--- a/gcc/testsuite/gcc.target/powerpc/pr46728-14.c
+++ b/gcc/testsuite/gcc.target/powerpc/pr46728-14.c
@@ -1,6 +1,7 @@
/* { dg-do run } */
/* { dg-skip-if "-mpowerpc-gpopt not supported" { powerpc*-*-darwin* } } */
/* { dg-options "-O2 -ffast-math -fno-inline -fno-unroll-loops -lm
-mpowerpc-gpopt" } */
+/* { dg-require-effective-target sqrt_insn } */
#include
--
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
Free Software Activist GNU Toolchain Engineer
More tolerance and less prejudice are key for inclusion and diversity
Excluding neuro-others for not behaving ""normal"" is *not* inclusive
Re: enable sqrt insns for cdce3.c
[Revamped version of this patch, combined with others, to follow]
On Mar 10, 2021, Hans-Peter Nilsson wrote:
> On Wed, 10 Mar 2021, Alexandre Oliva wrote:
>>
>> The test expects shrink-wrapping of the fsqrt call, but that will only
>> occur when there is a usable sqrt insn.
>>
>> Arrange for dejagnu to add the options that enable the sqrt insn, if
>> one is available, and to skip the test otherwise.
>>
>>
>> H-P, this *should* obviate the mmix-specific dg-skip-if.
> Unfortunately it doesn't.
>> Would it be
>> easy for you to confirm that this is the case and, if so, drop it?
> About as easy as for anyone (this is a compile-test), but no
> problem. Unfortunately I get, with your patch applied and the
> dg-skip-if removed:
> FAIL: gcc.dg/cdce3.c scan-tree-dump cdce "cdce3.c:12: [^\n\r]*
> function call is shrink-wrapped into error conditions."
Is mmix a sqrt_insn effective target? proc
check_effective_target_sqrt_insn in
gcc/testsuite/lib/target-supports.exp suggests it shouldn't pass, so I'm
surprised it would still try to run the test despite the added
/* { dg-require-effective-target sqrt_insn } */ directive.
> The dump files and assembly file show no obvious clues to me as
> to what is supposed to happen; attached.
cdce3 is supposed to shrink-wrap the sqrtf(x) call into something like
(x >= 0 ? .SQRT(x) : sqrtf(x)), where .SQRT stands for a square root
instruction.
Since we don't know why it still runs for you, I'm keeping the mmix
explicit skip in the new version of the patch.
Thanks,
--
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
Free Software Activist GNU Toolchain Engineer
More tolerance and less prejudice are key for inclusion and diversity
Excluding neuro-others for not behaving ""normal"" is *not* inclusive
[PATCH v2] add explicit ABI and align options to pr88233.c
Ping?
https://gcc.gnu.org/pipermail/gcc-patches/2021-March/566530.html
(modified version follows)
We've observed failures of this test on powerpc configurations that
default to different calling conventions and alignment requirements.
Both settings are needed for the original expectations to be met.
The test was later modified to have different expectations for big and
little endian code generation. This patch restores the original
codegen expectations, that, with the explicit options, don't vary any
more.
Regstrapped on x86_64-linux-gnu and ppc64el-linux-gnu. Also tested with
gcc-13 on ppc64-vx7r2 and ppc-vx7r2. Ok to install?
for gcc/testsuite/ChangeLog
* gcc.target/powerpc/pr88233.c: Make some alignment strictness
and calling conventions assumptions explicit. Restore uniform
codegen expectations
---
gcc/testsuite/gcc.target/powerpc/pr88233.c |7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/gcc/testsuite/gcc.target/powerpc/pr88233.c
b/gcc/testsuite/gcc.target/powerpc/pr88233.c
index 27c73717a3f79..46a3ebfa28775 100644
--- a/gcc/testsuite/gcc.target/powerpc/pr88233.c
+++ b/gcc/testsuite/gcc.target/powerpc/pr88233.c
@@ -1,5 +1,5 @@
/* { dg-require-effective-target lp64 } */
-/* { dg-options "-O2 -mdejagnu-cpu=power8" } */
+/* { dg-options "-O2 -mdejagnu-cpu=power8 -mno-strict-align
-fpcc-struct-return" } */
typedef struct { double a[2]; } A;
A
@@ -9,6 +9,5 @@ foo (const A *a)
}
/* { dg-final { scan-assembler-not {\mmtvsr} } } */
-/* { dg-final { scan-assembler-times {\mlxvd2x\M} 1 { target { be } } } } */
-/* { dg-final { scan-assembler-times {\mstxvd2x\M} 1 { target { be } } } } */
-/* { dg-final { scan-assembler-times {\mlfd\M} 2 { target { le } } } } */
+/* { dg-final { scan-assembler-times {\mlxvd2x\M} 1 } } */
+/* { dg-final { scan-assembler-times {\mstxvd2x\M} 1 } } */
--
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
Free Software Activist GNU Toolchain Engineer
More tolerance and less prejudice are key for inclusion and diversity
Excluding neuro-others for not behaving ""normal"" is *not* inclusive
[PATCH] ppc: testsuite: vec-mul requires vsx runtime
Ping?
https://gcc.gnu.org/pipermail/gcc-patches/2022-May/593947.html
vec-mul is an execution test, but it only requires a powerpc_vsx_ok
effective target, which is enough only for compile tests. In order to
To check for runtime and execution environment support, we need to
require vsx_hw. Make that a condition for execution, but still
perform a compile test if the condition is not satisfied.
Regstrapped on x86_64-linux-gnu and ppc64el-linux-gnu. Also tested with
gcc-13 on ppc64-vx7r2 and ppc-vx7r2. Ok to install?
for gcc/testsuite/ChangeLog
* gcc.target/powerpc/vec-mul.c: Run on target vsx_hw, just
compile otherwise.
---
gcc/testsuite/gcc.target/powerpc/vec-mul.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/gcc/testsuite/gcc.target/powerpc/vec-mul.c
b/gcc/testsuite/gcc.target/powerpc/vec-mul.c
index bfcaf80719d1d..11da86159723f 100644
--- a/gcc/testsuite/gcc.target/powerpc/vec-mul.c
+++ b/gcc/testsuite/gcc.target/powerpc/vec-mul.c
@@ -1,4 +1,5 @@
-/* { dg-do run } */
+/* { dg-do compile { target { ! vsx_hw } } } */
+/* { dg-do run { target vsx_hw } } */
/* { dg-require-effective-target powerpc_vsx_ok } */
/* { dg-options "-mvsx -O3" } */
--
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
Free Software Activist GNU Toolchain Engineer
More tolerance and less prejudice are key for inclusion and diversity
Excluding neuro-others for not behaving ""normal"" is *not* inclusive
[PATCH] Request check for hw support in ppc run tests with -maltivec/-mvsx
From: Olivier Hainque
Regstrapped on x86_64-linux-gnu and ppc64el-linux-gnu. Also tested with
gcc-13 on ppc64-vx7r2 and ppc-vx7r2. Ok to install?
for gcc/testsuite/ChangeLog
* gcc.target/powerpc/swaps-p8-20.c: Change powerpc_altivec_ok
require-effective-target test into vmx_hw.
* gcc.target/powerpc/vsx-vector-5.c: Change powerpc_vsx_ok
require-effective-target test into vsx_hw.
---
gcc/testsuite/gcc.target/powerpc/swaps-p8-20.c |2 +-
gcc/testsuite/gcc.target/powerpc/vsx-vector-5.c |5 +
2 files changed, 2 insertions(+), 5 deletions(-)
diff --git a/gcc/testsuite/gcc.target/powerpc/swaps-p8-20.c
b/gcc/testsuite/gcc.target/powerpc/swaps-p8-20.c
index 564e8acb1f421..755519bfe847d 100644
--- a/gcc/testsuite/gcc.target/powerpc/swaps-p8-20.c
+++ b/gcc/testsuite/gcc.target/powerpc/swaps-p8-20.c
@@ -1,5 +1,5 @@
/* { dg-do run } */
-/* { dg-require-effective-target powerpc_altivec_ok } */
+/* { dg-require-effective-target vmx_hw } */
/* { dg-options "-O2 -mdejagnu-cpu=power8 -maltivec" } */
/* The expansion for vector character multiply introduces a vperm operation.
diff --git a/gcc/testsuite/gcc.target/powerpc/vsx-vector-5.c
b/gcc/testsuite/gcc.target/powerpc/vsx-vector-5.c
index dcc88b1f3a4c6..37a324b6f897d 100644
--- a/gcc/testsuite/gcc.target/powerpc/vsx-vector-5.c
+++ b/gcc/testsuite/gcc.target/powerpc/vsx-vector-5.c
@@ -1,11 +1,8 @@
/* { dg-do run { target lp64 } } */
/* { dg-skip-if "" { powerpc*-*-darwin* } } */
-/* { dg-require-effective-target powerpc_vsx_ok } */
+/* { dg-require-effective-target vsx_hw } */
/* { dg-options "-mvsx -O2" } */
-/* This will run, and someday we should add the support to test whether we are
- running on VSX hardware. */
-
#include
#include
--
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
Free Software Activist GNU Toolchain Engineer
More tolerance and less prejudice are key for inclusion and diversity
Excluding neuro-others for not behaving ""normal"" is *not* inclusive
[PATCH] adjust vectorization expectations for ppc costmodel 76b
Ping?
https://gcc.gnu.org/pipermail/gcc-patches/2021-March/566525.html
This test expects vectorization at power8+ because strict alignment is
not required for vectors. For power7, vectorization is not to take
place because it's not deemed profitable: 12 iterations would be
required to make it so.
But for power6 and below, the test's 10 iterations are enough to make
vectorization profitable, but the test doesn't expect this. Assuming
the decision is indeed appropriate, I'm adjusting the expectations.
for gcc/testsuite/ChangeLog
* gcc.dg/vect/costmodel/ppc/costmodel-vect-76b.c: Adjust
expectations for cpus below power7.
---
.../gcc.dg/vect/costmodel/ppc/costmodel-vect-76b.c |9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/gcc/testsuite/gcc.dg/vect/costmodel/ppc/costmodel-vect-76b.c
b/gcc/testsuite/gcc.dg/vect/costmodel/ppc/costmodel-vect-76b.c
index cbbfbb24658f8..0dab2c08acdb4 100644
--- a/gcc/testsuite/gcc.dg/vect/costmodel/ppc/costmodel-vect-76b.c
+++ b/gcc/testsuite/gcc.dg/vect/costmodel/ppc/costmodel-vect-76b.c
@@ -46,9 +46,10 @@ int main (void)
return 0;
}
-/* Peeling to align the store is used. Overhead of peeling is too high. */
-/* { dg-final { scan-tree-dump-times "vectorized 1 loops" 0 "vect" { target {
vector_alignment_reachable && {! vect_no_align} } } } } */
-/* { dg-final { scan-tree-dump-times "vectorization not profitable" 1 "vect" {
target { vector_alignment_reachable && {! vect_hw_misalign} } } } } */
+/* Peeling to align the store is used. Overhead of peeling is too high
+ for power7, but acceptable for earlier architectures. */
+/* { dg-final { scan-tree-dump-times "vectorized 1 loops" 0 "vect" { target {
has_arch_pwr7 && { vector_alignment_reachable && {! vect_no_align} } } } } } */
+/* { dg-final { scan-tree-dump-times "vectorization not profitable" 1 "vect" {
target { has_arch_pwr7 && { vector_alignment_reachable && {! vect_hw_misalign}
} } } } } */
/* Versioning to align the store is used. Overhead of versioning is not too
high. */
-/* { dg-final { scan-tree-dump-times "vectorized 1 loops" 1 "vect" { target {
vect_no_align || {! vector_alignment_reachable} } } } } */
+/* { dg-final { scan-tree-dump-times "vectorized 1 loops" 1 "vect" { target {
vect_no_align || { {! vector_alignment_reachable} || {! has_arch_pwr7 } } } } }
} */
--
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
Free Software Activist GNU Toolchain Engineer
More tolerance and less prejudice are key for inclusion and diversity
Excluding neuro-others for not behaving ""normal"" is *not* inclusive
[PATCH] disable ldist for test, to restore vectorizing-candidate loop
Ping?
https://gcc.gnu.org/pipermail/gcc-patches/2021-March/566524.html
The loop we're supposed to try to vectorize in
gcc.dg/vect/costmodel/ppc/costmodel-vect-31a.c is turned into a memset
before the vectorizer runs.
Various other tests in this set have already run into this, and the
solution has been to disable this loop distribution transformation,
enabled at -O2, so that the vectorizer gets a chance to transform the
loop and, in this testcase, fail to do so.
Regstrapped on x86_64-linux-gnu and ppc64el-linux-gnu. Also tested with
gcc-13 on ppc64-vx7r2 and ppc-vx7r2. Ok to install?
for gcc/testsuite/ChangeLog
* gcc.dg/vect/costmodel/ppc/costmodel-vect-31a.c: Disable
ldist.
---
.../gcc.dg/vect/costmodel/ppc/costmodel-vect-31a.c |1 +
1 file changed, 1 insertion(+)
diff --git a/gcc/testsuite/gcc.dg/vect/costmodel/ppc/costmodel-vect-31a.c
b/gcc/testsuite/gcc.dg/vect/costmodel/ppc/costmodel-vect-31a.c
index 454a714a30916..90b5d5a7f400b 100644
--- a/gcc/testsuite/gcc.dg/vect/costmodel/ppc/costmodel-vect-31a.c
+++ b/gcc/testsuite/gcc.dg/vect/costmodel/ppc/costmodel-vect-31a.c
@@ -1,4 +1,5 @@
/* { dg-require-effective-target vect_int } */
+/* { dg-additional-options "-fno-tree-loop-distribute-patterns" } */
#include
#include "../../tree-vect.h"
--
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
Free Software Activist GNU Toolchain Engineer
More tolerance and less prejudice are key for inclusion and diversity
Excluding neuro-others for not behaving ""normal"" is *not* inclusive
[PATCH] [testsuite] [ppc64] expect error on vxworks too
These ppc lp64 tests check for errors or warnings on -mno-powerpc64.
On powerpc64-*-vxworks* we get the same errors as on most other
covered platforms, but the tests did not mark them as expected for
this target. On powerpc-*-vxworks*, the tests are skipped because
lp64 is not satisfied, so I'm naming powerpc*-*-vxworks* rather than
something more specific.
Regstrapped on x86_64-linux-gnu and ppc64el-linux-gnu. Also tested with
gcc-13 on ppc64-vx7r2 and ppc-vx7r2. Ok to install?
for gcc/testsuite/ChangeLog
* gcc.target/powerpc/pr106680-1.c: Error on vxworks too.
* gcc.target/powerpc/pr106680-2.c: Likewise.
* gcc.target/powerpc/pr106680-3.c: Likewise.
---
gcc/testsuite/gcc.target/powerpc/pr106680-1.c |2 +-
gcc/testsuite/gcc.target/powerpc/pr106680-2.c |2 +-
gcc/testsuite/gcc.target/powerpc/pr106680-3.c |2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/gcc/testsuite/gcc.target/powerpc/pr106680-1.c
b/gcc/testsuite/gcc.target/powerpc/pr106680-1.c
index d624d43230a7a..aadaa614cfeba 100644
--- a/gcc/testsuite/gcc.target/powerpc/pr106680-1.c
+++ b/gcc/testsuite/gcc.target/powerpc/pr106680-1.c
@@ -8,6 +8,6 @@ int foo ()
return 1;
}
-/* { dg-error "'-m64' requires a PowerPC64 cpu" "PR106680" { target
powerpc*-*-linux* powerpc*-*-freebsd* powerpc-*-rtems* } 0 } */
+/* { dg-error "'-m64' requires a PowerPC64 cpu" "PR106680" { target
powerpc*-*-linux* powerpc*-*-freebsd* powerpc-*-rtems* powerpc*-*-vxworks* } 0
} */
/* { dg-warning "'-m64' requires PowerPC64 architecture, enabling" "PR106680"
{ target powerpc*-*-darwin* } 0 } */
/* { dg-warning "'-maix64' requires PowerPC64 architecture remain enabled"
"PR106680" { target powerpc*-*-aix* } 0 } */
diff --git a/gcc/testsuite/gcc.target/powerpc/pr106680-2.c
b/gcc/testsuite/gcc.target/powerpc/pr106680-2.c
index a9ed73726ef0c..f0758e303350a 100644
--- a/gcc/testsuite/gcc.target/powerpc/pr106680-2.c
+++ b/gcc/testsuite/gcc.target/powerpc/pr106680-2.c
@@ -9,6 +9,6 @@ int foo ()
return 1;
}
-/* { dg-error "'-m64' requires a PowerPC64 cpu" "PR106680" { target
powerpc*-*-linux* powerpc*-*-freebsd* powerpc-*-rtems* } 0 } */
+/* { dg-error "'-m64' requires a PowerPC64 cpu" "PR106680" { target
powerpc*-*-linux* powerpc*-*-freebsd* powerpc-*-rtems* powerpc*-*-vxworks* } 0
} */
/* { dg-warning "'-m64' requires PowerPC64 architecture, enabling" "PR106680"
{ target powerpc*-*-darwin* } 0 } */
/* { dg-warning "'-maix64' requires PowerPC64 architecture remain enabled"
"PR106680" { target powerpc*-*-aix* } 0 } */
diff --git a/gcc/testsuite/gcc.target/powerpc/pr106680-3.c
b/gcc/testsuite/gcc.target/powerpc/pr106680-3.c
index b642d5c7a008d..bca012e2cf663 100644
--- a/gcc/testsuite/gcc.target/powerpc/pr106680-3.c
+++ b/gcc/testsuite/gcc.target/powerpc/pr106680-3.c
@@ -8,6 +8,6 @@ int foo ()
return 1;
}
-/* { dg-error "'-m64' requires a PowerPC64 cpu" "PR106680" { target
powerpc*-*-linux* powerpc*-*-freebsd* powerpc-*-rtems* } 0 } */
+/* { dg-error "'-m64' requires a PowerPC64 cpu" "PR106680" { target
powerpc*-*-linux* powerpc*-*-freebsd* powerpc-*-rtems* powerpc*-*-vxworks* } 0
} */
/* { dg-warning "'-m64' requires PowerPC64 architecture, enabling" "PR106680"
{ target powerpc*-*-darwin* } 0 } */
/* { dg-warning "'-maix64' requires PowerPC64 architecture remain enabled"
"PR106680" { target powerpc*-*-aix* } 0 } */
--
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
Free Software Activist GNU Toolchain Engineer
More tolerance and less prejudice are key for inclusion and diversity
Excluding neuro-others for not behaving ""normal"" is *not* inclusive
[PATCH v2] [testsuite] [arm] add effective target and options for pacbti tests
.c
index 79dd8010d2dab..a34bb0842b632 100644
--- a/gcc/testsuite/gcc.target/arm/bti-1.c
+++ b/gcc/testsuite/gcc.target/arm/bti-1.c
@@ -1,7 +1,8 @@
/* Check that GCC does bti instruction. */
/* { dg-do compile } */
-/* { dg-skip-if "avoid conflicting multilib options" { *-*-* } { "-marm"
"-mcpu=*" } } */
-/* { dg-options "-march=armv8.1-m.main -mthumb -mfloat-abi=softfp
-mbranch-protection=bti --save-temps" } */
+/* { dg-require-effective-target arm_arch_v8_1m_main_ok } */
+/* { dg-add-options arm_arch_v8_1m_main } */
+/* { dg-additional-options "-mfloat-abi=softfp -mbranch-protection=bti
--save-temps" } */
int
main (void)
diff --git a/gcc/testsuite/gcc.target/arm/bti-2.c
b/gcc/testsuite/gcc.target/arm/bti-2.c
index 33910563849a4..e5bc4d5543a8d 100644
--- a/gcc/testsuite/gcc.target/arm/bti-2.c
+++ b/gcc/testsuite/gcc.target/arm/bti-2.c
@@ -1,8 +1,9 @@
/* { dg-do compile } */
/* -Os to create jump table. */
/* { dg-options "-Os" } */
-/* { dg-skip-if "avoid conflicting multilib options" { *-*-* } { "-marm"
"-mcpu=*" } } */
-/* { dg-options "-march=armv8.1-m.main -mthumb -mfloat-abi=softfp
-mbranch-protection=bti --save-temps" } */
+/* { dg-require-effective-target arm_arch_v8_1m_main_ok } */
+/* { dg-add-options arm_arch_v8_1m_main } */
+/* { dg-additional-options "-mfloat-abi=softfp -mbranch-protection=bti
--save-temps" } */
extern int f1 (void);
extern int f2 (void);
--
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
Free Software Activist GNU Toolchain Engineer
More tolerance and less prejudice are key for inclusion and diversity
Excluding neuro-others for not behaving ""normal"" is *not* inclusive
Re: [PATCH] [testsuite] [arm] require arm_v8_1m_main for pacbti tests
On Apr 16, 2024, "Richard Earnshaw (lists)" wrote:
> The require-effective-target flags test whether a specific set of
> flags will make the compilation work, so they need to be used in
> conjunction with the corresponding dg-add-options flags that then
> apply those options.
*nod*, that's the theory. Problem is the architectures suported by
[add_options_for_]arm_arch_*[_ok] do not match exactly those expected by
the tests, and I can't quite tell whether the subtle changes they would
introduce would change what they intend to test, or even whether the
differences are irrelevant, or would be sensible to add as variants to
the dg machinery. I think it would take someone more familiar than I am
with all of the ARM variants to do this correctly. I don't even know
how these changes would need to be tested to be sure they remain
correct.
Would you be willing to take it from here, or would you accept the patch
as an incremental yet imperfect improvement, or would you prefer to
guide me in making it correct, and in verifying it (there are questions
below)? I don't have a lot of cycles to put into this (we've already
worked around the testsuite bugs we ran into), but it would be desirable
to get a fix into GCC as well, if we can converge on one without
unreasonably burdening anyone.
v8_1m_main "-march=armv8.1-m.main+fp -mthumb" __ARM_ARCH_8M_MAIN__
v8_1m_main_pacbti "-march=armv8.1-m.main+pacbti+fp -mthumb"
"__ARM_ARCH_8M_MAIN__ && __ARM_FEATURE_BTI &&
__ARM_FEATURE_PAUTH
Why do these have +fp in -march but not in the v8_1m* arch name?
gcc/testsuite/g++.target/arm/pac-1.C:
/* { dg-options "-march=armv8.1-m.main+mve+pacbti -mbranch-protection=pac-ret
-mthumb -mfloat-abi=hard -g -O0" } */
v8_1m_main_pacbti plus +mve minus +fp.
Do we need a dg arch for that?
gcc/testsuite/gcc.target/arm/acle/pacbti-m-predef-7.c:
/* { dg-additional-options "-march=armv8.1-m.main+pacbti+fp --save-temps
-mfloat-abi=hard" } */
gcc/testsuite/gcc.target/arm/acle/pacbti-m-predef-11.c:
/* { dg-options "-march=armv8.1-m.main+fp+pacbti" } */
v8_1m_main_pacbti minus -mthumb.
AFAICT the -mthumb is redundant.
gcc/testsuite/gcc.target/arm/acle/pacbti-m-predef-12.c:
/* { dg-options "-march=armv8-m.main+fp -mfloat-abi=softfp" } */
v8_1m_main minus -mthumb.
AFAICT the -mthumb is redundant.
gcc/testsuite/gcc.target/arm/bti-1.c:
/* { dg-options "-march=armv8.1-m.main -mthumb -mfloat-abi=softfp
-mbranch-protection=bti --save-temps" } */
gcc/testsuite/gcc.target/arm/bti-2.c:
/* { dg-options "-march=armv8.1-m.main -mthumb -mfloat-abi=softfp
-mbranch-protection=bti --save-temps" } */
v8_1m_main minus +fp.
Can these be bumped to +fp, or do we need an extra dg arch?
Are these missing +pacbti?
Thanks,
--
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
Free Software Activist GNU Toolchain Engineer
More tolerance and less prejudice are key for inclusion and diversity
Excluding neuro-others for not behaving ""normal"" is *not* inclusive
Re: [PATCH] [libstdc++] introduce --disable-compat-libstdcxx-abi
On Apr 16, 2024, Jonathan Wakely wrote: >> +dnl >> +dnl Enable -Wabi=2 if not overridden by --disable-compat-libstdcxx-abi. >> +dnl >> +AC_DEFUN([GLIBCXX_ENABLE_WABI], [ >> + # Default. >> + WARN_FLAGS_WABI=\ -Wabi=2 >> + AC_MSG_CHECKING([for --disable-compat-libstdcxx-abi]) >> + AC_ARG_ENABLE([compat-libstdcxx-abi], > We have the GLIBCXX_ENABLE macro to simplify creating new --enable options. *nod*. There was some reason why I didn't use it at first. Maybe it can be used with the patch as it ended up. Will revisit. >> +AC_HELP_STRING([--disable-compat-libstdcxx-abi], >> + [Disable backward-compatibility ABI symbols)]), > There's a stray ')' here. Ugh, thanks >> --- a/libstdc++-v3/doc/html/manual/configure.html >> +++ b/libstdc++-v3/doc/html/manual/configure.html > This should be in doc/xml/manual/configure.xml too, which is used to > generate the HTML using docbook. Oh, right. Doh. So much for grepping for an existing option and jumping to edit the first match :-) > The description here in the docs (and the name of the configure > option) seem much too vague. Libstdc++ has dozens, probably hundreds, > of "backward-compatibility ABI symbols", and this only affects touches > a tiny handful of them. Just the aliases created automatically by the > compiler for mangling changes, right? Yeah. I had used --disable-libstdcxx-Wabi at some point, maybe that's better. FTR, we now have a binutils patch (thanks H.J.Lu) to address the underlying problem, so we'll probably no longer need the workaround that led me to propose this change. I wonder if there's interest in keeping it. I'd be equally happy to make the adjustments, or to withdraw it (or pretty much anything in between ;-). WDYT? -- Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/ Free Software Activist GNU Toolchain Engineer More tolerance and less prejudice are key for inclusion and diversity Excluding neuro-others for not behaving ""normal"" is *not* inclusive
Re: [PATCH] [testsuite] introduce strndup effective target
On Apr 16, 2024, Alexandre Oliva wrote:
> * gcc.dg/builtin-dynamic-object-size-1.c: Likewise.
> * gcc.dg/builtin-dynamic-object-size-2.c: Likewise.
> * gcc.dg/builtin-dynamic-object-size-3.c: Likewise.
> * gcc.dg/builtin-dynamic-object-size-4.c: Likewise.
These hunks were missing from the patch I posted, sorry. I goofed when
resolving the conflicts because the tests had been modified after
gcc-13. I hope the intent was clear from the ChangeLog entry.
Here they are.
diff --git a/gcc/testsuite/gcc.dg/builtin-dynamic-object-size-1.c
b/gcc/testsuite/gcc.dg/builtin-dynamic-object-size-1.c
index ffa59985024f5..76b4f704fed9c 100644
--- a/gcc/testsuite/gcc.dg/builtin-dynamic-object-size-1.c
+++ b/gcc/testsuite/gcc.dg/builtin-dynamic-object-size-1.c
@@ -1,7 +1,7 @@
/* { dg-do run } */
/* { dg-options "-O2 -Wno-stringop-overread" } */
/* { dg-require-effective-target alloca } */
-/* { dg-skip-if "no strndup" { hppa*-*-hpux* } } */
+/* { dg-additional-options "-DSKIP_STRNDUP" { target { ! strndup } } } */
#define __builtin_object_size __builtin_dynamic_object_size
#include "builtin-object-size-1.c"
diff --git a/gcc/testsuite/gcc.dg/builtin-dynamic-object-size-2.c
b/gcc/testsuite/gcc.dg/builtin-dynamic-object-size-2.c
index fff32da7aea14..cb757a8d699cf 100644
--- a/gcc/testsuite/gcc.dg/builtin-dynamic-object-size-2.c
+++ b/gcc/testsuite/gcc.dg/builtin-dynamic-object-size-2.c
@@ -1,7 +1,7 @@
/* { dg-do run } */
/* { dg-options "-O2 -Wno-stringop-overread" } */
/* { dg-require-effective-target alloca } */
-/* { dg-skip-if "no strndup" { hppa*-*-hpux* } } */
+/* { dg-additional-options "-DSKIP_STRNDUP" { target { ! strndup } } } */
#define __builtin_object_size __builtin_dynamic_object_size
#include "builtin-object-size-2.c"
diff --git a/gcc/testsuite/gcc.dg/builtin-dynamic-object-size-3.c
b/gcc/testsuite/gcc.dg/builtin-dynamic-object-size-3.c
index ac223d67b10a4..8a12f023f27bc 100644
--- a/gcc/testsuite/gcc.dg/builtin-dynamic-object-size-3.c
+++ b/gcc/testsuite/gcc.dg/builtin-dynamic-object-size-3.c
@@ -1,7 +1,7 @@
/* { dg-do run } */
/* { dg-options "-O2 -Wno-stringop-overread" } */
/* { dg-require-effective-target alloca } */
-/* { dg-skip-if "no strndup" { hppa*-*-hpux* } } */
+/* { dg-additional-options "-DSKIP_STRNDUP" { target { ! strndup } } } */
#define __builtin_object_size __builtin_dynamic_object_size
#include "builtin-object-size-3.c"
diff --git a/gcc/testsuite/gcc.dg/builtin-dynamic-object-size-4.c
b/gcc/testsuite/gcc.dg/builtin-dynamic-object-size-4.c
index fdf4284ae1158..0efc2d9858422 100644
--- a/gcc/testsuite/gcc.dg/builtin-dynamic-object-size-4.c
+++ b/gcc/testsuite/gcc.dg/builtin-dynamic-object-size-4.c
@@ -1,7 +1,7 @@
/* { dg-do run } */
/* { dg-options "-O2 -Wno-stringop-overread" } */
/* { dg-require-effective-target alloca } */
-/* { dg-skip-if "no strndup" { hppa*-*-hpux* } } */
+/* { dg-additional-options "-DSKIP_STRNDUP" { target { ! strndup } } } */
#define __builtin_object_size __builtin_dynamic_object_size
#include "builtin-object-size-4.c"
--
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
Free Software Activist GNU Toolchain Engineer
More tolerance and less prejudice are key for inclusion and diversity
Excluding neuro-others for not behaving ""normal"" is *not* inclusive
Re: [PATCH] [libstdc++] [testsuite] xfail double-prec from_chars for float128_t
On Apr 16, 2024, Alexandre Oliva wrote: > * testsuite/20_util/to_chars/float128-c++23.cc: Xfail run on > aarch64-vxworks. FTR, here's the fixed ChangeLog entry I'm putting in: (s/-/_/) * testsuite/20_util/to_chars/float128_c++23.cc: Xfail run on aarch64-vxworks. -- Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/ Free Software Activist GNU Toolchain Engineer More tolerance and less prejudice are key for inclusion and diversity Excluding neuro-others for not behaving ""normal"" is *not* inclusive
Re: [PATCH] [testsuite] [arm] accept empty init for bfloat16
On Apr 16, 2024, Mike Stump wrote: > Indeed, I kinda expect coverage already for that feature in > another test case. *nod*, jsm added gcc.dg/c11-empty-init-[123].c (and more) in the patch that implemented this c23 feature. -- Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/ Free Software Activist GNU Toolchain Engineer More tolerance and less prejudice are key for inclusion and diversity Excluding neuro-others for not behaving ""normal"" is *not* inclusive
Re: [PATCH] [strub] improve handling of indirected volatile parms [PR112938]
On Apr 16, 2024, Alexandre Oliva wrote: > I'm going to put it in momentarily. It had been approved for gcc 14, > before it branched off; should I install it there as well? Ermh, nevermind, I'm not sure how I got the idea that we'd already branched, but I was absolutely sure that this was the case. Doh! :-) -- Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/ Free Software Activist GNU Toolchain Engineer More tolerance and less prejudice are key for inclusion and diversity Excluding neuro-others for not behaving ""normal"" is *not* inclusive
Re: [PATCH] [tree-prof] skip if errors were seen [PR113681]
On Mar 29, 2024, Alexandre Oliva wrote:
> On Mar 22, 2024, Jeff Law wrote:
>> On 3/9/24 2:11 AM, Alexandre Oliva wrote:
>>> ipa_tree_profile asserts that the symtab is in IPA_SSA state, but we
>>> don't reach that state and ICE if e.g. ipa-strub passes report errors.
>>> Skip this pass if errors were seen.
>>> Regstrapped on x86_64-linux-gnu. Ok to install?
>>>
>>> for gcc/ChangeLog
>>> PR tree-optimization/113681
>>> * tree-profiling.cc (pass_ipa_tree_profile::gate): Skip if
>>> seen_errors.
>>> for gcc/testsuite/ChangeLog
>>> PR tree-optimization/113681
>>> * c-c++-common/strub-pr113681.c: New.
>> So I've really never dug into strub, but this would seem to imply that
>> an error from strub is non-fatal?
> Yeah. I believe that's no different from other passes.
> Various other passes have seen_errors guards, but ipa-prof didn't.
Specifically, pass_build_ssa_passes in passes.cc is gated with
!seen_errors(), so we skip all the passes bundled in it, and don't
advance the symtab state to IPA_SSA. So other passes that would require
IPA_SSA need to be gated similarly.
> I suppose the insertion point for the strubm pass was one where others
> passes didn't previously issue errors, so that wasn't an issue for
> ipa-prof. But now it is.
The patch needed adjustments to resolve conflicts with unrelated
changes.
[tree-prof] skip if errors were seen [PR113681]
ipa_tree_profile asserts that the symtab is in IPA_SSA state, but we
don't reach that state and ICE if e.g. ipa-strub passes report errors.
Skip this pass if errors were seen.
Regstrapped on x86_64-linux-gnu. Ok to install?
for gcc/ChangeLog
PR tree-optimization/113681
* tree-profiling.cc (pass_ipa_tree_profile::gate): Skip if
seen_errors.
for gcc/testsuite/ChangeLog
PR tree-optimization/113681
* c-c++-common/strub-pr113681.c: New.
---
gcc/testsuite/c-c++-common/strub-pr113681.c | 22 ++
gcc/tree-profile.cc |3 ++-
2 files changed, 24 insertions(+), 1 deletion(-)
create mode 100644 gcc/testsuite/c-c++-common/strub-pr113681.c
diff --git a/gcc/testsuite/c-c++-common/strub-pr113681.c
b/gcc/testsuite/c-c++-common/strub-pr113681.c
new file mode 100644
index 0..3ef9017b2eb70
--- /dev/null
+++ b/gcc/testsuite/c-c++-common/strub-pr113681.c
@@ -0,0 +1,22 @@
+/* { dg-do compile } */
+/* { dg-options "-fstrub=relaxed -fbranch-probabilities" } */
+/* { dg-require-effective-target strub } */
+
+/* Same as torture/strub-inlineable1.c, but with -fbranch-probabilities, to
+ check that IPA tree-profiling won't ICE. It would when we refrained from
+ running passes that would take it to IPA_SSA, but ran the pass that asserted
+ for IPA_SSA. */
+
+inline void __attribute__ ((strub ("internal"), always_inline))
+inl_int_ali (void)
+{
+ /* No internal wrapper, so this body ALWAYS gets inlined,
+ but it cannot be called from non-strub contexts. */
+}
+
+void
+bat (void)
+{
+ /* Not allowed, not a strub context. */
+ inl_int_ali (); /* { dg-error "context" } */
+}
diff --git a/gcc/tree-profile.cc b/gcc/tree-profile.cc
index b87c121790c99..e4bb689cef589 100644
--- a/gcc/tree-profile.cc
+++ b/gcc/tree-profile.cc
@@ -2070,7 +2070,8 @@ pass_ipa_tree_profile::gate (function *)
disabled. */
return (!in_lto_p && !flag_auto_profile
&& (flag_branch_probabilities || flag_test_coverage
- || profile_arc_flag || condition_coverage_flag));
+ || profile_arc_flag || condition_coverage_flag)
+ && !seen_error ());
}
} // anon namespace
--
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
Free Software Activist GNU Toolchain Engineer
More tolerance and less prejudice are key for inclusion and diversity
Excluding neuro-others for not behaving ""normal"" is *not* inclusive
Re: [PATCH] [strub] improve handling of indirected volatile parms [PR112938]
On Mar 11, 2024, Richard Biener wrote: > On Sat, Mar 9, 2024 at 10:10 AM Alexandre Oliva wrote: >> >> >> The earlier patch for PR112938 arranged for volatile parms to be made >> indirect in internal strub wrapped bodies. >> >> The first problem that remained, more evident, was that the indirected >> parameter remained volatile, despite the indirection, but it wasn't >> regimplified, so indirecting it was malformed gimple. >> >> Regimplifying turned out not to be needed. The best course of action >> was to drop the volatility from the by-reference parm, that was being >> unexpectedly inherited from the original volatile parm. >> >> That exposed another problem: the dereferences would then lose their >> volatile status, so we had to bring volatile back to them. >> >> Regstrapped on x86_64-linux-gnu. Ok to install? > OK Thanks, sorry, I dropped the ball on this one. I'm going to put it in momentarily. It had been approved for gcc 14, before it branched off; should I install it there as well? >> >> for gcc/ChangeLog >> >> PR middle-end/112938 >> * ipa-strub.cc (pass_ipa_strub::execute): Drop volatility from >> indirected parm. >> (maybe_make_indirect): Restore volatility in dereferences. >> >> for gcc/testsuite/ChangeLog >> >> PR middle-end/112938 >> * g++.dg/strub-internal-pr112938.cc: New. -- Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/ Free Software Activist GNU Toolchain Engineer More tolerance and less prejudice are key for inclusion and diversity Excluding neuro-others for not behaving ""normal"" is *not* inclusive
[PATCH] [testsuite] [i386] add -msse2 to tests that require it
Without -msse2, an i586-targeting toolchain fails bf16_short_warn.c
because neither type __m128bh nor intrinsic _mm_cvtneps_pbh get
declared.
Regstrapped on x86_64-linux-gnu. Also tested with gcc-13 on arm-,
aarch64-, x86- and x86_64-vxworks7r2. Ok to install?
for gcc/testsuite/ChangeLog
* gcc.target/i386/bf16_short_warn.c: Add -msse2.
---
gcc/testsuite/gcc.target/i386/bf16_short_warn.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/testsuite/gcc.target/i386/bf16_short_warn.c
b/gcc/testsuite/gcc.target/i386/bf16_short_warn.c
index 3e47a815200c2..2e05624bc26f6 100644
--- a/gcc/testsuite/gcc.target/i386/bf16_short_warn.c
+++ b/gcc/testsuite/gcc.target/i386/bf16_short_warn.c
@@ -1,5 +1,5 @@
/* { dg-do compile } */
-/* { dg-options "-O2" } */
+/* { dg-options "-O2 -msse2" } */
#include
typedef struct {
--
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
Free Software Activist GNU Toolchain Engineer
More tolerance and less prejudice are key for inclusion and diversity
Excluding neuro-others for not behaving ""normal"" is *not* inclusive
[PATCH] [testsuite] [i386] work around fails with --enable-frame-pointer
A few x86 tests get unexpected insn counts if the toolchain is
configured with --enable-frame-pointer. Add explicit
-fomit-frame-pointer so that the expected insn sequences are output.
Regstrapped on x86_64-linux-gnu. Also tested with gcc-13 on arm-,
aarch64-, x86- and x86_64-vxworks7r2. Ok to install?
for gcc/testsuite/ChangeLog
* gcc.target/i386/pr107261.c: Add -fomit-frame-pointer.
* gcc.target/i386/pr69482-1.c: Likewise.
* gcc.target/i386/pr69482-2.c: Likewise.
---
gcc/testsuite/gcc.target/i386/pr107261.c |2 +-
gcc/testsuite/gcc.target/i386/pr69482-1.c |2 +-
gcc/testsuite/gcc.target/i386/pr69482-2.c |2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/gcc/testsuite/gcc.target/i386/pr107261.c
b/gcc/testsuite/gcc.target/i386/pr107261.c
index eb1d232fbfc4b..b422af9cbf9a2 100644
--- a/gcc/testsuite/gcc.target/i386/pr107261.c
+++ b/gcc/testsuite/gcc.target/i386/pr107261.c
@@ -1,5 +1,5 @@
/* { dg-do compile } */
-/* { dg-options "-O2 -msse2" } */
+/* { dg-options "-O2 -msse2 -fomit-frame-pointer" } */
typedef __bf16 v4bf __attribute__ ((vector_size (8)));
typedef __bf16 v2bf __attribute__ ((vector_size (4)));
diff --git a/gcc/testsuite/gcc.target/i386/pr69482-1.c
b/gcc/testsuite/gcc.target/i386/pr69482-1.c
index 99bb6ad5a377b..7ef0e71b17c8e 100644
--- a/gcc/testsuite/gcc.target/i386/pr69482-1.c
+++ b/gcc/testsuite/gcc.target/i386/pr69482-1.c
@@ -1,5 +1,5 @@
/* { dg-do compile } */
-/* { dg-options "-O3 -fno-stack-protector" } */
+/* { dg-options "-O3 -fno-stack-protector -fomit-frame-pointer" } */
static inline void memset_s(void* s, int n) {
volatile unsigned char * p = s;
diff --git a/gcc/testsuite/gcc.target/i386/pr69482-2.c
b/gcc/testsuite/gcc.target/i386/pr69482-2.c
index 58e89a7933364..6aabe4fb39399 100644
--- a/gcc/testsuite/gcc.target/i386/pr69482-2.c
+++ b/gcc/testsuite/gcc.target/i386/pr69482-2.c
@@ -1,5 +1,5 @@
/* { dg-do compile } */
-/* { dg-options "-O2" } */
+/* { dg-options "-O2 -fomit-frame-pointer" } */
void bar ()
{
--
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
Free Software Activist GNU Toolchain Engineer
More tolerance and less prejudice are key for inclusion and diversity
Excluding neuro-others for not behaving ""normal"" is *not* inclusive
[PATCH] [testsuite] [arm] accept empty init for bfloat16
Complete r13-2205, adjusting an arm-specific test that expects a
no-longer-issued error at an empty initializer.
Regstrapped on x86_64-linux-gnu. Also tested with gcc-13 on arm-,
aarch64-, x86- and x86_64-vxworks7r2. Ok to install?
for gcc/testsuite/ChangeLog
* gcc.target/arm/bfloat16_scalar_typecheck.c: Accept C23
empty initializers.
---
.../gcc.target/arm/bfloat16_scalar_typecheck.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/gcc/testsuite/gcc.target/arm/bfloat16_scalar_typecheck.c
b/gcc/testsuite/gcc.target/arm/bfloat16_scalar_typecheck.c
index 8c80c55bc9f4c..04ede93bda152 100644
--- a/gcc/testsuite/gcc.target/arm/bfloat16_scalar_typecheck.c
+++ b/gcc/testsuite/gcc.target/arm/bfloat16_scalar_typecheck.c
@@ -42,7 +42,7 @@ bfloat16_t footest (bfloat16_t scalar0)
short initi_1_4 = glob_bfloat; /* { dg-error {invalid conversion from type
'bfloat16_t'} } */
double initi_1_5 = glob_bfloat; /* { dg-error {invalid conversion from type
'bfloat16_t'} } */
- bfloat16_t scalar2_1 = {}; /* { dg-error {empty scalar initializer} } */
+ bfloat16_t scalar2_1 = {};
bfloat16_t scalar2_2 = { glob_bfloat };
bfloat16_t scalar2_3 = { 0 }; /* { dg-error {invalid conversion to type
'bfloat16_t'} } */
bfloat16_t scalar2_4 = { 0.1 }; /* { dg-error {invalid conversion to type
'bfloat16_t'} } */
@@ -94,7 +94,7 @@ bfloat16_t footest (bfloat16_t scalar0)
/* Compound literals. */
- (bfloat16_t) {}; /* { dg-error {empty scalar initializer} } */
+ (bfloat16_t) {};
(bfloat16_t) { glob_bfloat };
(bfloat16_t) { 0 }; /* { dg-error {invalid conversion to type 'bfloat16_t'}
} */
(bfloat16_t) { 0.1 }; /* { dg-error {invalid conversion to type
'bfloat16_t'} } */
--
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
Free Software Activist GNU Toolchain Engineer
More tolerance and less prejudice are key for inclusion and diversity
Excluding neuro-others for not behaving ""normal"" is *not* inclusive
[PATCH] [libstdc++] [testsuite] disable SRA for compare_exchange_padding
On arm-vx7r2, the uses of as.load() as initializer get SRAed, so the
padding bits in the tests are not what we might expect from full-word
struct copies.
I tried adding a function to perform bitwise copying, but even taking
the as.load() argument by const&, we'd still construct a temporary
with SRAed field-wise copying. Unable to find another way to ensure
we wouldn't get a temporary, I went for disabling SRA.
Regstrapped on x86_64-linux-gnu. Also tested with gcc-13 on arm-,
aarch64-, x86- and x86_64-vxworks7r2. Ok to install?
for libstdc++-v3/ChangeLog
* testsuite/29_atomics/atomic/compare_exchange_padding.cc:
Disable SRA.
---
.../29_atomics/atomic/compare_exchange_padding.cc |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git
a/libstdc++-v3/testsuite/29_atomics/atomic/compare_exchange_padding.cc
b/libstdc++-v3/testsuite/29_atomics/atomic/compare_exchange_padding.cc
index 2f18d426e7f7e..a6081968ca869 100644
--- a/libstdc++-v3/testsuite/29_atomics/atomic/compare_exchange_padding.cc
+++ b/libstdc++-v3/testsuite/29_atomics/atomic/compare_exchange_padding.cc
@@ -1,6 +1,7 @@
// { dg-do run { target c++20 } }
// { dg-require-atomic-cmpxchg-word "" }
// { dg-add-options libatomic }
+// { dg-additional-options "-fno-tree-sra" }
#include
#include
@@ -26,10 +27,10 @@ main ()
s.s = 42;
std::atomic as{ s };
- auto ts = as.load();
+ auto ts = as.load(); // SRA might prevent copying of padding bits here.
VERIFY( !compare_struct(s, ts) ); // padding cleared on construction
as.exchange(s);
- auto es = as.load();
+ auto es = as.load(); // SRA might prevent copying of padding bits here.
VERIFY( compare_struct(ts, es) ); // padding cleared on exchange
S n;
--
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
Free Software Activist GNU Toolchain Engineer
More tolerance and less prejudice are key for inclusion and diversity
Excluding neuro-others for not behaving ""normal"" is *not* inclusive
[PATCH] [testsuite] [arm] require arm_v8_1m_main for pacbti tests
arm pac and bti tests that use -march=armv8.1-m.main get an implicit
-mthumb, that is incompatible with vxworks kernel mode. Declaring the
requirement for a 8.1-m.main-compatible toolchain is enough to avoid
those fails, because the toolchain feature test fails in kernel mode.
Regstrapped on x86_64-linux-gnu. Also tested with gcc-13 on arm-,
aarch64-, x86- and x86_64-vxworks7r2. Ok to install?
for gcc/testsuite/ChangeLog
* g++.target/arm/pac-1.C: Require arm_arch_v8_1m_main.
* gcc.target/arm/acle/pacbti-m-predef-11.c: Likewise.
* gcc.target/arm/acle/pacbti-m-predef-12.c: Likewise.
* gcc.target/arm/acle/pacbti-m-predef-7.c: Likewise.
* gcc.target/arm/bti-1.c: Likewise.
* gcc.target/arm/bti-2.c: Likewise.
---
gcc/testsuite/g++.target/arm/pac-1.C |1 +
.../gcc.target/arm/acle/pacbti-m-predef-11.c |1 +
.../gcc.target/arm/acle/pacbti-m-predef-12.c |1 +
.../gcc.target/arm/acle/pacbti-m-predef-7.c|1 +
gcc/testsuite/gcc.target/arm/bti-1.c |1 +
gcc/testsuite/gcc.target/arm/bti-2.c |1 +
6 files changed, 6 insertions(+)
diff --git a/gcc/testsuite/g++.target/arm/pac-1.C
b/gcc/testsuite/g++.target/arm/pac-1.C
index f671a27b048c6..f48ad6cc5cb65 100644
--- a/gcc/testsuite/g++.target/arm/pac-1.C
+++ b/gcc/testsuite/g++.target/arm/pac-1.C
@@ -2,6 +2,7 @@
/* { dg-do compile } */
/* { dg-skip-if "avoid conflicting multilib options" { *-*-* } { "-marm"
"-mcpu=*" } } */
/* { dg-options "-march=armv8.1-m.main+mve+pacbti -mbranch-protection=pac-ret
-mthumb -mfloat-abi=hard -g -O0" } */
+/* { dg-require-effective-target arm_arch_v8_1m_main_ok } */
__attribute__((noinline)) void
fn1 (int a, int b, int c)
diff --git a/gcc/testsuite/gcc.target/arm/acle/pacbti-m-predef-11.c
b/gcc/testsuite/gcc.target/arm/acle/pacbti-m-predef-11.c
index 6a5ae92c567f3..dba4f491cfea7 100644
--- a/gcc/testsuite/gcc.target/arm/acle/pacbti-m-predef-11.c
+++ b/gcc/testsuite/gcc.target/arm/acle/pacbti-m-predef-11.c
@@ -1,6 +1,7 @@
/* { dg-do compile } */
/* { dg-skip-if "avoid conflicting multilib options" { *-*-* } { "-marm"
"-mcpu=*" "-mfloat-abi=*" } } */
/* { dg-options "-march=armv8.1-m.main+fp+pacbti" } */
+/* { dg-require-effective-target arm_arch_v8_1m_main_ok } */
#if (__ARM_FEATURE_BTI != 1)
#error "Feature test macro __ARM_FEATURE_BTI_DEFAULT should be defined to 1."
diff --git a/gcc/testsuite/gcc.target/arm/acle/pacbti-m-predef-12.c
b/gcc/testsuite/gcc.target/arm/acle/pacbti-m-predef-12.c
index db40b17c3b030..308a41eb4ba4c 100644
--- a/gcc/testsuite/gcc.target/arm/acle/pacbti-m-predef-12.c
+++ b/gcc/testsuite/gcc.target/arm/acle/pacbti-m-predef-12.c
@@ -1,6 +1,7 @@
/* { dg-do compile } */
/* { dg-skip-if "avoid conflicting multilib options" { *-*-* } { "-marm"
"-mcpu=*" } } */
/* { dg-options "-march=armv8-m.main+fp -mfloat-abi=softfp" } */
+/* { dg-require-effective-target arm_arch_v8_1m_main_ok } */
#if defined (__ARM_FEATURE_BTI)
#error "Feature test macro __ARM_FEATURE_BTI should not be defined."
diff --git a/gcc/testsuite/gcc.target/arm/acle/pacbti-m-predef-7.c
b/gcc/testsuite/gcc.target/arm/acle/pacbti-m-predef-7.c
index 1b25907635e24..10836a84bde56 100644
--- a/gcc/testsuite/gcc.target/arm/acle/pacbti-m-predef-7.c
+++ b/gcc/testsuite/gcc.target/arm/acle/pacbti-m-predef-7.c
@@ -1,6 +1,7 @@
/* { dg-do compile } */
/* { dg-skip-if "avoid conflicting multilib options" { *-*-* } { "-marm"
"-mcpu=*" } } */
/* { dg-additional-options "-march=armv8.1-m.main+pacbti+fp --save-temps
-mfloat-abi=hard" } */
+/* { dg-require-effective-target arm_arch_v8_1m_main_ok } */
#if defined (__ARM_FEATURE_BTI_DEFAULT)
#error "Feature test macro __ARM_FEATURE_BTI_DEFAULT should be undefined."
diff --git a/gcc/testsuite/gcc.target/arm/bti-1.c
b/gcc/testsuite/gcc.target/arm/bti-1.c
index 79dd8010d2dab..34655387b55f5 100644
--- a/gcc/testsuite/gcc.target/arm/bti-1.c
+++ b/gcc/testsuite/gcc.target/arm/bti-1.c
@@ -2,6 +2,7 @@
/* { dg-do compile } */
/* { dg-skip-if "avoid conflicting multilib options" { *-*-* } { "-marm"
"-mcpu=*" } } */
/* { dg-options "-march=armv8.1-m.main -mthumb -mfloat-abi=softfp
-mbranch-protection=bti --save-temps" } */
+/* { dg-require-effective-target arm_arch_v8_1m_main_ok } */
int
main (void)
diff --git a/gcc/testsuite/gcc.target/arm/bti-2.c
b/gcc/testsuite/gcc.target/arm/bti-2.c
index 33910563849a4..3284aba3020cc 100644
--- a/gcc/testsuite/gcc.target/arm/bti-2.c
+++ b/gcc/testsuite/gcc.target/arm/bti-2.c
@@ -3,6 +3,7 @@
/* { dg-options "-Os" } */
/* { dg-skip-if "avoid conflicting multilib options" { *-*-* } { "-marm"
"-mcpu=*" } } */
/* { dg-options "
[PATCH] [testsuite] [i386] require fpic for pr111497.C
Fix another test that uses -fPIC without requiring fpic support.
Regstrapped on x86_64-linux-gnu. Also tested with gcc-13 on arm-,
aarch64-, x86- and x86_64-vxworks7r2. Ok to install?
PS: This is neither the first nor the last such patch. Maybe the test
harness could detect -fPIC et al in compile options and react
intelligently to them, whether by warning if dg-require-effective-target
fpic is missing, or adding it implicitly. We could have more such
smarts in the testsuite machinery. WDYT?
for gcc/testsuite/ChangeLog
* g++.target/i386/pr111497.C: Require fpic support.
---
gcc/testsuite/g++.target/i386/pr111497.C |1 +
1 file changed, 1 insertion(+)
diff --git a/gcc/testsuite/g++.target/i386/pr111497.C
b/gcc/testsuite/g++.target/i386/pr111497.C
index a645bb95907ee..30e2e0409ad0e 100644
--- a/gcc/testsuite/g++.target/i386/pr111497.C
+++ b/gcc/testsuite/g++.target/i386/pr111497.C
@@ -1,5 +1,6 @@
// { dg-do compile { target ia32 } }
// { dg-options "-march=i686 -mtune=generic -fPIC -O2 -g" }
+// { dg-require-effective-target fpic }
class A;
struct B { const char *b1; int b2; };
--
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
Free Software Activist GNU Toolchain Engineer
More tolerance and less prejudice are key for inclusion and diversity
Excluding neuro-others for not behaving ""normal"" is *not* inclusive
[PATCH] [libstdc++] introduce --disable-compat-libstdcxx-abi
t;
int main()
{
typedef short atomic_type;
@@ -16252,7 +16255,7 @@ $as_echo "$glibcxx_cv_atomic_short" >&6; }
rm -f conftest*
cat > conftest.$ac_ext << EOF
-#line 16255 "configure"
+#line 16258 "configure"
int main()
{
// NB: _Atomic_word not necessarily int.
@@ -16288,7 +16291,7 @@ $as_echo "$glibcxx_cv_atomic_int" >&6; }
rm -f conftest*
cat > conftest.$ac_ext << EOF
-#line 16291 "configure"
+#line 16294 "configure"
int main()
{
typedef long long atomic_type;
@@ -16444,7 +16447,7 @@ $as_echo "mutex" >&6; }
# unnecessary for this test.
cat > conftest.$ac_ext << EOF
-#line 16447 "configure"
+#line 16450 "configure"
int main()
{
_Decimal32 d1;
@@ -16486,7 +16489,7 @@ ac_compiler_gnu=$ac_cv_cxx_compiler_gnu
# unnecessary for this test.
cat > conftest.$ac_ext << EOF
-#line 16489 "configure"
+#line 16492 "configure"
template
struct same
{ typedef T2 type; };
@@ -55671,7 +55674,35 @@ $as_echo "$gxx_include_dir" >&6; }
# OPTIMIZE_CXXFLAGS = -O3 -fstrict-aliasing -fvtable-gc
- WARN_FLAGS="-Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi=2"
+ WARN_FLAGS="-Wall -Wextra -Wwrite-strings -Wcast-qual"
+
+
+
+ # Default.
+ WARN_FLAGS_WABI=\ -Wabi=2
+ { $as_echo "$as_me:${as_lineno-$LINENO}: checking for
--disable-compat-libstdcxx-abi" >&5
+$as_echo_n "checking for --disable-compat-libstdcxx-abi... " >&6; }
+ # Check whether --enable-compat-libstdcxx-abi was given.
+if test "${enable_compat_libstdcxx_abi+set}" = set; then :
+ enableval=$enable_compat_libstdcxx_abi; case "$enableval" in
+ yes) { $as_echo "$as_me:${as_lineno-$LINENO}: result:
enabled$WARN_FLAGS_WABI" >&5
+$as_echo "enabled$WARN_FLAGS_WABI" >&6; } ;;
+ no) WARN_FLAGS_WABI=
+ { $as_echo "$as_me:${as_lineno-$LINENO}: result: disabled" >&5
+$as_echo "disabled" >&6; } ;;
+ *) { $as_echo "$as_me:${as_lineno-$LINENO}: result: unsupported" >&5
+$as_echo "unsupported" >&6; }
+ as_fn_error $? "Unsupported argument to enable/disable compat
libstdc++ abi" "$LINENO" 5;;
+ esac
+else
+
+ { $as_echo "$as_me:${as_lineno-$LINENO}: result: defaulting to
enabled$WARN_FLAGS_WABI" >&5
+$as_echo "defaulting to enabled$WARN_FLAGS_WABI" >&6; }
+
+fi
+
+
+ WARN_FLAGS="$WARN_FLAGS$WARN_FLAGS_WABI"
diff --git a/libstdc++-v3/doc/html/manual/configure.html
b/libstdc++-v3/doc/html/manual/configure.html
index 346b5d345cd1b..8636b2360d9f0 100644
--- a/libstdc++-v3/doc/html/manual/configure.html
+++ b/libstdc++-v3/doc/html/manual/configure.html
@@ -108,6 +108,8 @@
then the [time.clock] implementation will use a system call to access
the realtime and monotonic clocks, which is significantly slower than
the C library's clock_gettime function.
+--disable-compat-libstdcxx-abiDisables
+backward-compatibility ABI symbols.
--enable-libstdcxx-debugBuild separate
debug libraries in addition to what is normally built.
By default, the debug libraries are compiled with
CXXFLAGS='-g3 -O0 -fno-inline'
--
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
Free Software Activist GNU Toolchain Engineer
More tolerance and less prejudice are key for inclusion and diversity
Excluding neuro-others for not behaving ""normal"" is *not* inclusive
[PATCH] [testsuite] xfail pr103798-2 in C++ on vxworks too [PR113706]
pr103798-2.c fails in C++ on targets that provide a ISO C++-compliant
declaration of memchr, because it mismatches the C-compatible builtin,
as per PR113706. Expect the C++ test to fail on vxworks as well.
Regstrapped on x86_64-linux-gnu. Also tested with gcc-13 on arm-,
aarch64-, x86- and x86_64-vxworks7r2. Ok to install?
for gcc/testsuite/ChangeLog
PR testsuite/113706
* c-c++-common/pr103798-2.c: XFAIL in C++ on vxworks too.
---
gcc/testsuite/c-c++-common/pr103798-2.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/testsuite/c-c++-common/pr103798-2.c
b/gcc/testsuite/c-c++-common/pr103798-2.c
index bc126c205e1e3..83cdfaa1660bb 100644
--- a/gcc/testsuite/c-c++-common/pr103798-2.c
+++ b/gcc/testsuite/c-c++-common/pr103798-2.c
@@ -28,4 +28,4 @@ main ()
}
/* See PR c++/113706 for the xfail. */
-/* { dg-final { scan-assembler-not "memchr" { xfail { c++ && *-*-solaris2* } }
} } */
+/* { dg-final { scan-assembler-not "memchr" { xfail { c++ && { *-*-solaris2*
*-*-vxworks* } } } } } */
--
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
Free Software Activist GNU Toolchain Engineer
More tolerance and less prejudice are key for inclusion and diversity
Excluding neuro-others for not behaving ""normal"" is *not* inclusive
[PATCH] [testsuite] [analyzer] include sys/select.h if available
Test that calls select fails on vxworks because select is only declared in sys/select.h. Include that header if it's present. Regstrapped on x86_64-linux-gnu. Also tested with gcc-13 on arm-, aarch64-, x86- and x86_64-vxworks7r2. Ok to install? for gcc/testsuite/ChangeLog * gcc.dg/analyzer/fd-glibc-byte-stream-connection-server.c: Include sys/select.h if present. --- .../fd-glibc-byte-stream-connection-server.c |3 +++ 1 file changed, 3 insertions(+) diff --git a/gcc/testsuite/gcc.dg/analyzer/fd-glibc-byte-stream-connection-server.c b/gcc/testsuite/gcc.dg/analyzer/fd-glibc-byte-stream-connection-server.c index fcbcc740170e6..f922a52238f90 100644 --- a/gcc/testsuite/gcc.dg/analyzer/fd-glibc-byte-stream-connection-server.c +++ b/gcc/testsuite/gcc.dg/analyzer/fd-glibc-byte-stream-connection-server.c @@ -8,6 +8,9 @@ #include #include #include +#if __has_include() +#include +#endif #include #include #include -- Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/ Free Software Activist GNU Toolchain Engineer More tolerance and less prejudice are key for inclusion and diversity Excluding neuro-others for not behaving ""normal"" is *not* inclusive
[PATCH] [vxworks] avoid mangling __STDC_VERSION_LIMITS_H__
The mangling of the macro name that guards limits.h from reinclusion
was mangling a c23-required macro as well. Make the edit pattern
stricter.
Regstrapped on x86_64-linux-gnu. Also tested with gcc-13 on arm-,
aarch64-, x86- and x86_64-vxworks7r2. Ok to install?
for gcc/ChangeLog
* config/t-vxworks (vxw-glimits.h): Don't mangle c23-required
__STDC_VERSION_LIMITS_H__ define.
---
gcc/config/t-vxworks |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/config/t-vxworks b/gcc/config/t-vxworks
index b89350c3c70f4..6063943e346e6 100644
--- a/gcc/config/t-vxworks
+++ b/gcc/config/t-vxworks
@@ -57,7 +57,7 @@ T_GLIMITS_H = vxw-glimits.h
vxw-glimits.h: $(srcdir)/glimits.h
ID=`echo $(BASEVER_c) | sed -e 's/\./_/g'` && \
- sed -e "s/_LIMITS_H__/_LIMITS_H__$${ID}_/" < $< > $@T
+ sed -e "s/_LIMITS_H___/_LIMITS_H__$${ID}_/" < $< > $@T
mv $@T $@
# Arrange to "provide" a tailored version of stdint-gcc.h
--
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
Free Software Activist GNU Toolchain Engineer
More tolerance and less prejudice are key for inclusion and diversity
Excluding neuro-others for not behaving ""normal"" is *not* inclusive
[PATCH] [testsuite] [analyzer] require fork where used
Mark tests that fail due to the lack of fork, as in vxworks kernel
mode, as requiring fork.
Regstrapped on x86_64-linux-gnu. Also tested with gcc-13 on arm-,
aarch64-, x86- and x86_64-vxworks7r2. Ok to install?
for gcc/testsuite/ChangeLog
* gcc.dg/analyzer/pipe-glibc.c: Require fork.
* gcc.dg/analyzer/pipe-manpages.c: Likewise.
---
gcc/testsuite/gcc.dg/analyzer/pipe-glibc.c|5 +++--
gcc/testsuite/gcc.dg/analyzer/pipe-manpages.c |2 ++
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/gcc/testsuite/gcc.dg/analyzer/pipe-glibc.c
b/gcc/testsuite/gcc.dg/analyzer/pipe-glibc.c
index 60558a870b9d7..fe38ddef3959a 100644
--- a/gcc/testsuite/gcc.dg/analyzer/pipe-glibc.c
+++ b/gcc/testsuite/gcc.dg/analyzer/pipe-glibc.c
@@ -1,6 +1,7 @@
-/* Example of pipe usage from glibc manual. */
-
/* { dg-skip-if "" { "avr-*-*" } } */
+/* { dg-require-fork "" } */
+
+/* Example of pipe usage from glibc manual. */
#include
#include
diff --git a/gcc/testsuite/gcc.dg/analyzer/pipe-manpages.c
b/gcc/testsuite/gcc.dg/analyzer/pipe-manpages.c
index 6b9ae4d260281..ac5805fdba092 100644
--- a/gcc/testsuite/gcc.dg/analyzer/pipe-manpages.c
+++ b/gcc/testsuite/gcc.dg/analyzer/pipe-manpages.c
@@ -1,3 +1,5 @@
+/* { dg-require-fork "" } */
+
/* Example of "pipe" from release 5.13 of the Linux man-pages project.
Copyright (C) 2005, 2008, Michael Kerrisk
--
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
Free Software Activist GNU Toolchain Engineer
More tolerance and less prejudice are key for inclusion and diversity
Excluding neuro-others for not behaving ""normal"" is *not* inclusive
[PATCH] [testsuite] [analyzer] skip access-mode: O_ACCMODE on vxworks
O_ACCMODE is not defined on vxworks, and the test is meaningless and
failing without it, so skip it.
Regstrapped on x86_64-linux-gnu. Also tested with gcc-13 on arm-,
aarch64-, x86- and x86_64-vxworks7r2. Ok to install?
for gcc/testsuite/ChangeLog
* gcc.dg/analyzer/fd-access-mode-target-headers.c: Skip on
vxworks as well.
---
.../analyzer/fd-access-mode-target-headers.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/gcc/testsuite/gcc.dg/analyzer/fd-access-mode-target-headers.c
b/gcc/testsuite/gcc.dg/analyzer/fd-access-mode-target-headers.c
index b57b9fa2279c2..9fc32638a3de4 100644
--- a/gcc/testsuite/gcc.dg/analyzer/fd-access-mode-target-headers.c
+++ b/gcc/testsuite/gcc.dg/analyzer/fd-access-mode-target-headers.c
@@ -1,5 +1,4 @@
-/* { dg-skip-if "" { powerpc*-*-aix* || newlib } } */
-/* { dg-skip-if "" { avr-*-* } } */
+/* { dg-skip-if "" { { powerpc*-*-aix* avr-*-* *-*-vxworks* } || newlib } } */
#include
#include
--
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
Free Software Activist GNU Toolchain Engineer
More tolerance and less prejudice are key for inclusion and diversity
Excluding neuro-others for not behaving ""normal"" is *not* inclusive
[PATCH] [testsuite] [analyzer] avoid vxworks libc mode_t
Define macro that prevents mode_t from being defined by vxworks'
headers as well.
Regstrapped on x86_64-linux-gnu. Also tested with gcc-13 on arm-,
aarch64-, x86- and x86_64-vxworks7r2. Ok to install?
for gcc/testsuite/ChangeLog
* gcc.dg/analyzer/fd-4.c: Define macro to avoid mode_t on
vxworks.
---
gcc/testsuite/gcc.dg/analyzer/fd-4.c |1 +
1 file changed, 1 insertion(+)
diff --git a/gcc/testsuite/gcc.dg/analyzer/fd-4.c
b/gcc/testsuite/gcc.dg/analyzer/fd-4.c
index 880de3d789607..d104bfdad547f 100644
--- a/gcc/testsuite/gcc.dg/analyzer/fd-4.c
+++ b/gcc/testsuite/gcc.dg/analyzer/fd-4.c
@@ -1,4 +1,5 @@
/* { dg-additional-options "-D_MODE_T_DECLARED=1" { target newlib } } */
+/* { dg-additional-options "-D_DEFINED_mode_t" { target *-*-vxworks* } } */
#if defined(_AIX) || defined(__hpux)
#define _MODE_T
#endif
--
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
Free Software Activist GNU Toolchain Engineer
More tolerance and less prejudice are key for inclusion and diversity
Excluding neuro-others for not behaving ""normal"" is *not* inclusive
[PATCH] [testsuite] introduce strndup effective target
ite/gcc.dg/builtin-object-size-2.c
index 37d3dcc6f5689..c28d72eee9bfe 100644
--- a/gcc/testsuite/gcc.dg/builtin-object-size-2.c
+++ b/gcc/testsuite/gcc.dg/builtin-object-size-2.c
@@ -1,6 +1,7 @@
/* { dg-do run } */
/* { dg-options "-O2 -Wno-stringop-overread" } */
/* { dg-require-effective-target alloca } */
+/* { dg-additional-options "-DSKIP_STRNDUP" { target { ! strndup } } } */
#include "builtin-object-size-common.h"
@@ -536,7 +537,7 @@ test8 (unsigned cond)
#endif
}
-#if !defined(__AVR__) && !defined(__hpux__) /* avr and hpux have no strndup */
+#ifndef SKIP_STRNDUP
/* Tests for strdup/strndup. */
size_t
__attribute__ ((noinline))
@@ -624,7 +625,7 @@ test9 (void)
FAIL ();
free (res);
}
-#endif /* avr */
+#endif
int
main (void)
@@ -639,7 +640,7 @@ main (void)
test6 ();
test7 ();
test8 (1);
-#if !defined(__AVR__) && !defined(__hpux__) /* avr and hpux have no strndup */
+#ifndef SKIP_STRNDUP
test9 ();
#endif
DONE ();
diff --git a/gcc/testsuite/gcc.dg/builtin-object-size-3.c
b/gcc/testsuite/gcc.dg/builtin-object-size-3.c
index f4d1ebf7027bf..3f58da3d500cd 100644
--- a/gcc/testsuite/gcc.dg/builtin-object-size-3.c
+++ b/gcc/testsuite/gcc.dg/builtin-object-size-3.c
@@ -1,6 +1,7 @@
/* { dg-do run } */
/* { dg-options "-O2 -Wno-stringop-overread" } */
/* { dg-require-effective-target alloca } */
+/* { dg-additional-options "-DSKIP_STRNDUP" { target { ! strndup } } } */
#include "builtin-object-size-common.h"
@@ -628,7 +629,7 @@ test10 (void)
}
}
-#if !defined(__AVR__) && !defined(__hpux__) /* avr and hpux have no strndup */
+#ifndef SKIP_STRNDUP
/* Tests for strdup/strndup. */
size_t
__attribute__ ((noinline))
@@ -717,7 +718,7 @@ test11 (void)
FAIL ();
free (res);
}
-#endif /* avr */
+#endif
int
main (void)
@@ -734,7 +735,7 @@ main (void)
test8 ();
test9 (1);
test10 ();
-#if !defined(__AVR__) && !defined(__hpux__) /* avr and hpux have no strndup */
+#ifndef SKIP_STRNDUP
test11 ();
#endif
DONE ();
diff --git a/gcc/testsuite/gcc.dg/builtin-object-size-4.c
b/gcc/testsuite/gcc.dg/builtin-object-size-4.c
index 2887dd150423b..b3eb36efb744d 100644
--- a/gcc/testsuite/gcc.dg/builtin-object-size-4.c
+++ b/gcc/testsuite/gcc.dg/builtin-object-size-4.c
@@ -1,6 +1,7 @@
/* { dg-do run } */
/* { dg-options "-O2 -Wno-stringop-overread" } */
/* { dg-require-effective-target alloca } */
+/* { dg-additional-options "-DSKIP_STRNDUP" { target { ! strndup } } } */
#include "builtin-object-size-common.h"
@@ -509,7 +510,7 @@ test8 (unsigned cond)
#endif
}
-#if !defined(__AVR__) && !defined(__hpux__) /* avr and hpux have no strndup */
+#ifndef SKIP_STRNDUP
/* Tests for strdup/strndup. */
size_t
__attribute__ ((noinline))
@@ -597,7 +598,7 @@ test9 (void)
FAIL ();
free (res);
}
-#endif /* avr */
+#endif
int
main (void)
@@ -612,7 +613,7 @@ main (void)
test6 ();
test7 ();
test8 (1);
-#if !defined(__AVR__) && !defined(__hpux__) /* avr and hpux have no strndup */
+#ifndef SKIP_STRNDUP
test9 ();
#endif
DONE ();
diff --git a/gcc/testsuite/lib/target-supports.exp
b/gcc/testsuite/lib/target-supports.exp
index edce672c0e21a..17c8382adf143 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -11580,6 +11580,17 @@ proc check_effective_target_stpcpy {} {
return [check_function_available "stpcpy"]
}
+# Returns 1 if "strndup" is available on the target system.
+
+proc check_effective_target_strndup {} {
+if { [istarget *-*-vxworks*] } {
+ # VxWorks doesn't have strndup but our way to test fails
+ # to detect as we're doing partial links for kernel modules.
+ return 0
+}
+return [check_function_available "strndup"]
+}
+
# Returns 1 if "sigsetjmp" is available on the target system.
# Also check if "__sigsetjmp" is defined since that's what glibc
# uses.
--
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
Free Software Activist GNU Toolchain Engineer
More tolerance and less prejudice are key for inclusion and diversity
Excluding neuro-others for not behaving ""normal"" is *not* inclusive
[PATCH] [c++] [testsuite] adjust contracts9.C for negative addresses
The test expected the address of a literal string, converted to long
long, to yield a positive value. That expectation doesn't necessarily
hold, and the test fails where it doesn't.
Adjust the test to use a pointer that will compare as expected.
Regstrapped on x86_64-linux-gnu. Also tested with gcc-13 on arm-,
aarch64-, x86- and x86_64-vxworks7r2. Ok to install?
for gcc/testsuite/ChangeLog
* g++.dg/contracts/contracts9.C: Don't assume string literals
have non-negative addresses.
---
gcc/testsuite/g++.dg/contracts/contracts9.C |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/testsuite/g++.dg/contracts/contracts9.C
b/gcc/testsuite/g++.dg/contracts/contracts9.C
index 09a1a6532c5a0..58b60aca32057 100644
--- a/gcc/testsuite/g++.dg/contracts/contracts9.C
+++ b/gcc/testsuite/g++.dg/contracts/contracts9.C
@@ -27,7 +27,7 @@ int main()
{
fun1(1, -1);
fun1(-1, 1.0);
- fun1(-1, "test");
+ fun1(-1, (const char *)0x1234);
[[ assert: fun1(-1, -5) ]];
[[ assert: test::fun(10, -6) ]];
--
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
Free Software Activist GNU Toolchain Engineer
More tolerance and less prejudice are key for inclusion and diversity
Excluding neuro-others for not behaving ""normal"" is *not* inclusive
[PATCH] [libstdc++] [testsuite] xfail double-prec from_chars for float128_t
Tests 20_util/from_chars/4.cc and 20_util/to_chars/long_double.cc were
adjusted about a year ago to skip long double on some targets, because
the fastfloat library was limited to 64-bit doubles.
The same problem comes up in similar float128_t tests on
aarch64-vxworks. This patch adjusts them similarly.
Unlike the earlier tests, that got similar treatment for
x86_64-vxworks, these haven't failed there.
Regstrapped on x86_64-linux-gnu. Also tested with gcc-13 on arm-,
aarch64-, x86- and x86_64-vxworks7r2. Ok to install?
for libstdc++-v3/ChangeLog
* testsuite/20_util/from_chars/8.cc: Skip float128_t testing
on aarch64-vxworks.
* testsuite/20_util/to_chars/float128-c++23.cc: Xfail run on
aarch64-vxworks.
---
libstdc++-v3/testsuite/20_util/from_chars/8.cc |3 ++-
.../testsuite/20_util/to_chars/float128_c++23.cc |1 +
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/libstdc++-v3/testsuite/20_util/from_chars/8.cc
b/libstdc++-v3/testsuite/20_util/from_chars/8.cc
index ee60d88c332db..a6343422c5a91 100644
--- a/libstdc++-v3/testsuite/20_util/from_chars/8.cc
+++ b/libstdc++-v3/testsuite/20_util/from_chars/8.cc
@@ -17,6 +17,7 @@
// { dg-do run { target c++23 } }
// { dg-add-options ieee }
+// { dg-additional-options "-DSKIP_LONG_DOUBLE" { target aarch64-*-vxworks* } }
#include
#include
@@ -343,7 +344,7 @@ test06()
#if defined(__STDCPP_FLOAT64_T__) && defined(_GLIBCXX_DOUBLE_IS_IEEE_BINARY64)
test_max_mantissa();
#endif
-#if defined(__GLIBCXX_TYPE_INT_N_0) \
+#if defined(__GLIBCXX_TYPE_INT_N_0) && !defined SKIP_LONG_DOUBLE \
&& defined(__STDCPP_FLOAT128_T__) &&
defined(_GLIBCXX_LDOUBLE_IS_IEEE_BINARY128)
test_max_mantissa();
#endif
diff --git a/libstdc++-v3/testsuite/20_util/to_chars/float128_c++23.cc
b/libstdc++-v3/testsuite/20_util/to_chars/float128_c++23.cc
index 547632817b4bb..ca00761ee7c98 100644
--- a/libstdc++-v3/testsuite/20_util/to_chars/float128_c++23.cc
+++ b/libstdc++-v3/testsuite/20_util/to_chars/float128_c++23.cc
@@ -19,6 +19,7 @@
// { dg-require-effective-target ieee_floats }
// { dg-require-effective-target size32plus }
// { dg-add-options ieee }
+// { dg-xfail-run-if "from_chars limited to double-precision" {
aarch64-*-vxworks* } }
#include
#include
--
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
Free Software Activist GNU Toolchain Engineer
More tolerance and less prejudice are key for inclusion and diversity
Excluding neuro-others for not behaving ""normal"" is *not* inclusive
[PATCH] [libstdc++] define zoneinfo_dir_override on vxworks
VxWorks fails to load kernel-mode modules with weak undefined symbols.
In RTP mode modules, that undergo final linking, weak undefined
symbols are not a problem.
This patch adds kernel-mode VxWorks multilibs to the set of targets
that don't support weak undefined symbols without special flags, in
which tzdb's zoneinfo_dir_override is given a weak definition.
Regstrapped on x86_64-linux-gnu. Also tested with gcc-13 on arm-,
aarch64-, x86- and x86_64-vxworks7r2. Ok to install?
for libstdc++-v3/ChangeLog
* src/c++20/tzdb.cc (__gnu_cxx::zoneinfo_dir_override): Define
on VxWorks non-RTP.
---
libstdc++-v3/src/c++20/tzdb.cc |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/libstdc++-v3/src/c++20/tzdb.cc b/libstdc++-v3/src/c++20/tzdb.cc
index 890a4c53e2d44..639d1c440ba16 100644
--- a/libstdc++-v3/src/c++20/tzdb.cc
+++ b/libstdc++-v3/src/c++20/tzdb.cc
@@ -70,8 +70,9 @@ namespace __gnu_cxx
#else
[[gnu::weak]] const char* zoneinfo_dir_override();
-#if defined(__APPLE__) || defined(__hpux__)
- // Need a weak definition for Mach-O.
+#if defined(__APPLE__) || defined(__hpux__) \
+ || (defined(__VXWORKS__) && !defined(__RTP__))
+ // Need a weak definition for Mach-O et al.
[[gnu::weak]] const char* zoneinfo_dir_override()
{
#ifdef _GLIBCXX_ZONEINFO_DIR
--
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
Free Software Activist GNU Toolchain Engineer
More tolerance and less prejudice are key for inclusion and diversity
Excluding neuro-others for not behaving ""normal"" is *not* inclusive
[testsuite] [aarch64] Require fpic effective target
Regstrapped on x86_64-linux-gnu. Also tested with gcc-13 on arm-,
aarch64-, x86- and x86_64-vxworks7r2. Ok to install?
Co-authored-by: Olivier Hainque
for gcc/testsuite/ChangeLog
* gcc.target/aarch64/pr94201.c: Add missing
dg-require-effective-target fpic.
* gcc.target/aarch64/pr103085.c: Likewise.
---
gcc/testsuite/gcc.target/aarch64/pr103085.c |1 +
gcc/testsuite/gcc.target/aarch64/pr94201.c |1 +
2 files changed, 2 insertions(+)
diff --git a/gcc/testsuite/gcc.target/aarch64/pr103085.c
b/gcc/testsuite/gcc.target/aarch64/pr103085.c
index dbc9c15b71f22..347280ed42b2d 100644
--- a/gcc/testsuite/gcc.target/aarch64/pr103085.c
+++ b/gcc/testsuite/gcc.target/aarch64/pr103085.c
@@ -1,5 +1,6 @@
/* { dg-do compile } */
/* { dg-options "-O2 -fstack-protector-strong -fPIC" } */
+/* { dg-require-effective-target fpic } */
void g(int*);
void
diff --git a/gcc/testsuite/gcc.target/aarch64/pr94201.c
b/gcc/testsuite/gcc.target/aarch64/pr94201.c
index 691761691868a..3b9b79059e02b 100644
--- a/gcc/testsuite/gcc.target/aarch64/pr94201.c
+++ b/gcc/testsuite/gcc.target/aarch64/pr94201.c
@@ -1,5 +1,6 @@
/* { dg-do compile } */
/* { dg-options "-mcmodel=tiny -mabi=ilp32 -fPIC" } */
+/* { dg-require-effective-target fpic } */
extern int bar (void *);
extern long long a;
--
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
Free Software Activist GNU Toolchain Engineer
More tolerance and less prejudice are key for inclusion and diversity
Excluding neuro-others for not behaving ""normal"" is *not* inclusive
Re: [PATCH] [tree-prof] skip if errors were seen [PR113681]
On Mar 22, 2024, Jeff Law wrote: > On 3/9/24 2:11 AM, Alexandre Oliva wrote: >> ipa_tree_profile asserts that the symtab is in IPA_SSA state, but we >> don't reach that state and ICE if e.g. ipa-strub passes report errors. >> Skip this pass if errors were seen. >> Regstrapped on x86_64-linux-gnu. Ok to install? >> >> for gcc/ChangeLog >> PR tree-optimization/113681 >> * tree-profiling.cc (pass_ipa_tree_profile::gate): Skip if >> seen_errors. >> for gcc/testsuite/ChangeLog >> PR tree-optimization/113681 >> * c-c++-common/strub-pr113681.c: New. > So I've really never dug into strub, but this would seem to imply that > an error from strub is non-fatal? Yeah. I believe that's no different from other passes. Various other passes have seen_errors guards, but ipa-prof didn't. I suppose the insertion point for the strubm pass was one where others passes didn't previously issue errors, so that wasn't an issue for ipa-prof. But now it is. -- Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/ Free Software Activist GNU Toolchain Engineer More tolerance and less prejudice are key for inclusion and diversity Excluding neuro-others for not behaving ""normal"" is *not* inclusive
[PATCH] [tree-prof] skip if errors were seen [PR113681]
ipa_tree_profile asserts that the symtab is in IPA_SSA state, but we
don't reach that state and ICE if e.g. ipa-strub passes report errors.
Skip this pass if errors were seen.
Regstrapped on x86_64-linux-gnu. Ok to install?
for gcc/ChangeLog
PR tree-optimization/113681
* tree-profiling.cc (pass_ipa_tree_profile::gate): Skip if
seen_errors.
for gcc/testsuite/ChangeLog
PR tree-optimization/113681
* c-c++-common/strub-pr113681.c: New.
---
gcc/testsuite/c-c++-common/strub-pr113681.c | 22 ++
gcc/tree-profile.cc |3 ++-
2 files changed, 24 insertions(+), 1 deletion(-)
create mode 100644 gcc/testsuite/c-c++-common/strub-pr113681.c
diff --git a/gcc/testsuite/c-c++-common/strub-pr113681.c
b/gcc/testsuite/c-c++-common/strub-pr113681.c
new file mode 100644
index 0..3ef9017b2eb70
--- /dev/null
+++ b/gcc/testsuite/c-c++-common/strub-pr113681.c
@@ -0,0 +1,22 @@
+/* { dg-do compile } */
+/* { dg-options "-fstrub=relaxed -fbranch-probabilities" } */
+/* { dg-require-effective-target strub } */
+
+/* Same as torture/strub-inlineable1.c, but with -fbranch-probabilities, to
+ check that IPA tree-profiling won't ICE. It would when we refrained from
+ running passes that would take it to IPA_SSA, but ran the pass that asserted
+ for IPA_SSA. */
+
+inline void __attribute__ ((strub ("internal"), always_inline))
+inl_int_ali (void)
+{
+ /* No internal wrapper, so this body ALWAYS gets inlined,
+ but it cannot be called from non-strub contexts. */
+}
+
+void
+bat (void)
+{
+ /* Not allowed, not a strub context. */
+ inl_int_ali (); /* { dg-error "context" } */
+}
diff --git a/gcc/tree-profile.cc b/gcc/tree-profile.cc
index aed13e2b1bc30..d2bdbe3a08c2f 100644
--- a/gcc/tree-profile.cc
+++ b/gcc/tree-profile.cc
@@ -999,7 +999,8 @@ pass_ipa_tree_profile::gate (function *)
disabled. */
return (!in_lto_p && !flag_auto_profile
&& (flag_branch_probabilities || flag_test_coverage
- || profile_arc_flag));
+ || profile_arc_flag)
+ && !seen_error ());
}
} // anon namespace
--
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
Free Software Activist GNU Toolchain Engineer
More tolerance and less prejudice are key for inclusion and diversity
Excluding neuro-others for not behaving ""normal"" is *not* inclusive
[PATCH] [strub] improve handling of indirected volatile parms [PR112938]
The earlier patch for PR112938 arranged for volatile parms to be made
indirect in internal strub wrapped bodies.
The first problem that remained, more evident, was that the indirected
parameter remained volatile, despite the indirection, but it wasn't
regimplified, so indirecting it was malformed gimple.
Regimplifying turned out not to be needed. The best course of action
was to drop the volatility from the by-reference parm, that was being
unexpectedly inherited from the original volatile parm.
That exposed another problem: the dereferences would then lose their
volatile status, so we had to bring volatile back to them.
Regstrapped on x86_64-linux-gnu. Ok to install?
for gcc/ChangeLog
PR middle-end/112938
* ipa-strub.cc (pass_ipa_strub::execute): Drop volatility from
indirected parm.
(maybe_make_indirect): Restore volatility in dereferences.
for gcc/testsuite/ChangeLog
PR middle-end/112938
* g++.dg/strub-internal-pr112938.cc: New.
---
gcc/ipa-strub.cc|7 +++
gcc/testsuite/g++.dg/strub-internal-pr112938.cc | 12
2 files changed, 19 insertions(+)
create mode 100644 gcc/testsuite/g++.dg/strub-internal-pr112938.cc
diff --git a/gcc/ipa-strub.cc b/gcc/ipa-strub.cc
index dff94222351ad..8fa7bdf530023 100644
--- a/gcc/ipa-strub.cc
+++ b/gcc/ipa-strub.cc
@@ -1940,6 +1940,9 @@ maybe_make_indirect (indirect_parms_t _parms,
tree op, int *rec)
TREE_TYPE (TREE_TYPE (op)),
op,
build_int_cst (TREE_TYPE (op), 0));
+ if (TYPE_VOLATILE (TREE_TYPE (TREE_TYPE (op)))
+ && !TREE_THIS_VOLATILE (ret))
+ TREE_SIDE_EFFECTS (ret) = TREE_THIS_VOLATILE (ret) = 1;
return ret;
}
}
@@ -2894,6 +2897,10 @@ pass_ipa_strub::execute (function *)
probably drop the TREE_ADDRESSABLE and keep the TRUE. */
tree ref_type = build_ref_type_for (nparm);
+ if (TREE_THIS_VOLATILE (nparm)
+ && TYPE_VOLATILE (TREE_TYPE (nparm))
+ && !TYPE_VOLATILE (ref_type))
+ TREE_SIDE_EFFECTS (nparm) = TREE_THIS_VOLATILE (nparm) = 0;
DECL_ARG_TYPE (nparm) = TREE_TYPE (nparm) = ref_type;
relayout_decl (nparm);
TREE_ADDRESSABLE (nparm) = 0;
diff --git a/gcc/testsuite/g++.dg/strub-internal-pr112938.cc
b/gcc/testsuite/g++.dg/strub-internal-pr112938.cc
new file mode 100644
index 0..5a74becc2697e
--- /dev/null
+++ b/gcc/testsuite/g++.dg/strub-internal-pr112938.cc
@@ -0,0 +1,12 @@
+/* { dg-do compile } */
+/* { dg-options "-fdump-tree-optimized -O2" } */
+/* { dg-require-effective-target strub } */
+
+bool __attribute__ ((__strub__ ("internal")))
+f(bool i, volatile bool j)
+{
+ return (i ^ j) == j;
+}
+
+/* Check for two dereferences of the indirected volatile j parm. */
+/* { dg-final { scan-tree-dump-times {={v} \*j_[0-9][0-9]*(D)} 2 "optimized" }
} */
--
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
Free Software Activist GNU Toolchain Engineer
More tolerance and less prejudice are key for inclusion and diversity
Excluding neuro-others for not behaving ""normal"" is *not* inclusive
Re: [PATCH] arm: fix c23 0-named-args caller-side stdarg
On Mar 1, 2024, "Richard Earnshaw (lists)" wrote: > On 01/03/2024 04:38, Alexandre Oliva wrote: >> Thanks for the review. > For closure, Jakub has just pushed a patch to the generic code, so I > don't think we need this now. ACK. I see the c2x-stdarg-4.c test is now passing in our arm-eabi gcc-13 tree. Thank you all. Alas, the same nightly build showed a new riscv fail in c23-stdarg-6.c, that also got backported to gcc-13. Presumably it's failing in the trunk as well, both riscv32-elf and riscv64-elf. I haven't looked into whether it's a regression brought about by the patch or just a new failure mode that the new test exposed. Either way, I'm not sure whether to link this new failure to any of the associated PRs or to file a new one, but, FTR, I'm going to look into it. -- Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/ Free Software Activist GNU Toolchain Engineer More tolerance and less prejudice are key for inclusion and diversity Excluding neuro-others for not behaving ""normal"" is *not* inclusive
Re: [PATCH] calls: Fix up TYPE_NO_NAMED_ARGS_STDARG_P handling [PR107453]
On Feb 27, 2024, Richard Earnshaw wrote: > This one has been festering for a while; both Alexandre and Torbjorn > have attempted to fix it recently, but I'm not sure either is really > right... *nod* xref https://gcc.gnu.org/pipermail/gcc-patches/2024-March/646926.html The patch I proposed was indeed far too limited in scope. > On Arm this is causing all anonymous arguments to be passed on the > stack, which is incorrect per the ABI. On a target that uses > 'pretend_outgoing_vararg_named', why is it correct to set n_named_args > to zero? Is it enough to guard both the statements you've added with > !targetm.calls.pretend_outgoing_args_named? ISTM that the change you suggest over Jakub's patch would address the inconsistency on ARM. Matthew suggested a patch along these lines in the other thread, that I xrefed above, that seems sound to me, but I also suspect it won't fix the ppc64le issue. My hunch is that we'll need a combination of both, possibly with further tweaks to adjust for Jakub's just-added test. -- Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/ Free Software Activist GNU Toolchain Engineer Disinformation flourishes because many people care deeply about injustice but very few check the facts. Think Assange & Stallman. The empires strike back
Re: [PATCH] arm: fix c23 0-named-args caller-side stdarg
Hello, Matthew, Thanks for the review. On Feb 26, 2024, Matthew Malcomson wrote: > I think you're right that the AAPCS32 requires all arguments to be passed in > registers for this testcase. > (Nit on the commit-message: It says that your reading of the AAPCS32 > suggests > that the *caller* is correct -- I believe based on the change you > suggested you > meant *callee* is correct in expecting arguments in registers.) Ugh, yeah, sorry about the typo. > The approach you suggest looks OK to me -- I do notice that it doesn't > fix the > legacy ABI's of `atpcs` and `apcs` and guess it would be nicer to have them > working at the same time though would defer to maintainers on how > important that > is. > (For the benefit of others reading) I don't believe there is any ABI concern > with this since it's fixing something that is currently not working at > all and > only applies to c23 (so a change shouldn't have too much of an impact). > You mention you chose to make the change in the arm backend rather > than general > code due to hesitancy to change the generic ABI-affecting code. That makes > sense to me, certainly at this late stage in the development cycle. *nod* I wrote the patch in the following context: I hit the problem on the very first toolchain I started transitioning to gcc-13. I couldn't really fathom the notion that this breakage could have survived an entire release cycle if it affected many targets, and sort of held on to an assumption that the abi used by our arm-eabi toolchain had to be an uncommon one. All of this hypothesizing falls apart by the now apparent knowledge that the test is faling elsewhere as well, even on other ARM ABIs, it just hadn't been addressed yet. I'm glad we're getting there :-) > From a quick check on c23-stdarg-4.c it does look like the below > change ends up > with the same codegen as your patch (except in the case of those > legacy ABI's, > where the below does make the caller and callee ABI match AFAICT): > ``` > diff --git a/gcc/calls.cc b/gcc/calls.cc > index 01f44734743..0b302f633ed 100644 > --- a/gcc/calls.cc > +++ b/gcc/calls.cc > @@ -2970,14 +2970,15 @@ expand_call (tree exp, rtx target, int ignore) > we do not have any reliable way to pass unnamed args in > registers, so we must force them into memory. */ > - if (type_arg_types != 0 > + if ((type_arg_types != 0 || TYPE_NO_NAMED_ARGS_STDARG_P (funtype)) > && targetm.calls.strict_argument_naming (args_so_far)) > ; > else if (type_arg_types != 0 > && ! targetm.calls.pretend_outgoing_varargs_named > (args_so_far)) > /* Don't include the last named arg. */ > --n_named_args; > - else if (TYPE_NO_NAMED_ARGS_STDARG_P (funtype)) > + else if (TYPE_NO_NAMED_ARGS_STDARG_P (funtype) > + && ! targetm.calls.pretend_outgoing_varargs_named (args_so_far)) > n_named_args = 0; > else > /* Treat all args as named. */ > ``` > Do you agree that this makes sense (i.e. is there something I'm > completely missing)? Yeah, your argument is quite convincing, and the target knobs are indeed in line with the change you suggest, whereas the current code seems to deviate from them. With my ABI designer hat on, however, I see that there's room for ABIs to make decisions about 0-args stdargs that go differently from stdargs with leading named args, from prototyped functions, and even from prototypeless functions, and we might end up needing more knobs to deal with such custom decisions. We can cross that bridge if/when we get to it, though. > (lm32 mcore msp430 gcn cris fr30 frv h8300 arm v850 rx pru) Interesting that ppc64le is not on your list. There's PR107453 about that, and another thread is discussing a fix for it that is somewhat different from what you propose (presumably because the way the problem manifests on ppc64le is different), but it also tweaks expand_call. I'll copy you when following up there. -- Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/ Free Software Activist GNU Toolchain Engineer More tolerance and less prejudice are key for inclusion and diversity Excluding neuro-others for not behaving ""normal"" is *not* inclusive
Re: [PATCH RFA] build: drop target libs from LD_LIBRARY_PATH [PR105688]
On Feb 23, 2024, Jason Merrill wrote: > The problem, as you say, comes when you want to both bootstrap and > build tools that aren't involved in the bootstrap process. It's more visible there, because those don't actively refrain from linking dynamically with libstdc++. But even bootstrapped matter that involves exceptions would have to link in libgcc_s, and that would bring about the same sort of issue. > To support that perhaps we want POSTBOOTSTRAP_HOST_EXPORTS for host > modules without the bootstrap tag, and add the TARGET_LIB_PATH > directories there? That would be welcome, but it doesn't really address the problem, does it? Namely, the problem that we may face two different kinds of scenarios, and each one calls for an opposite solution. 1. system tools used in the build depend on system libraries that are newer than the ones we're about to build This is the scenario that you're attempting to address with these patches. The problem here is that the libraries being built are older than the system libraries, and and system tools won't run if dynamically linked with the older libraries about to be built. 2. the libraries we're about to build are newer than corresponding system libraries, if any This is the scenario that the current build system aims for. Any build tools that rely on older system libraries are likely to work just as well with the newly built libraries. Any newly built libraries linked into programs used and run as part of the build have to be present in LD_LIBRARY_PATH lest we end up trying to use the older system libraries, which may seem to work in some settings, but is bound to break if the differences are large enough. For maximum clarity, consider a bootstrap with LTO using a linker plugin. The linker plugin is built against the newly-built libraries. The linker that attempts to load the plugin also requires the same libraries. Do you see how tending to 1. breaks 2., and vice-versa? Now add ASAN to the picture, for another set of newly-built libraries used during bootstrap. Also use a prebuilt linker with ASAN enabled, for maximum clarity of the problem I'm getting at. Do you see the problem? Do you agree that patching the build system to solve a problem in scenario 1. *will* cause problems in scenario 2., *unless* the fix can distinguish the two scenarios and behave accordingly, but that getting that right is triky and error prone? Do you agree that, until we get there, it's probably better to optimize for the more common scenario? Do you agree that the more common scenario is probably 2.? Do you agree that, until we get a solution that works for both 1. and 2. automatically, offering a reasonably simple workaround for 1., while aiming to work for 2., would be a desirable stopgap? Do you agree that adding support for users to prepend directories to the search path, enabling them to preempt build libraries with (symlinks to?) select newer system libraries, and documenting situations in which this could be needed, is a reasonably simple and desirable stopgap that enables 1. to work while defaulting to the presumed more common case 2.? Here's a patchlet that shows the crux of what I have in mind: (nevermind we'd make the change elsewhere, document it further elsewhere, set an empty default and arrange to passed down to sub-$(MAKE)s) diff --git a/Makefile.in b/Makefile.in index edb0c8a9a427f..10c7646ef98c4 100644 --- a/Makefile.in +++ b/Makefile.in @@ -771,7 +771,12 @@ TARGET_LIB_PATH_libatomic = $$r/$(TARGET_SUBDIR)/libatomic/.libs: # This is the list of directories that may be needed in RPATH_ENVVAR # so that programs built for the host machine work. -HOST_LIB_PATH = $(HOST_LIB_PATH_gmp)$(HOST_LIB_PATH_mpfr)$(HOST_LIB_PATH_mpc)$(HOST_LIB_PATH_isl) +# Users may set PREEMPT_HOST_LIB_PATH to a directory holding symlinks +# to system libraries required by build tools (say the linker) that +# are newer (as in higher-versioned) than the corresponding libraries +# we're building. If older libraries were to override the newer +# system libraries, that could prevent the build tools from running. +HOST_LIB_PATH = $(PREEMPT_HOST_LIB_PATH):$(HOST_LIB_PATH_gmp)$(HOST_LIB_PATH_mpfr)$(HOST_LIB_PATH_mpc)$(HOST_LIB_PATH_isl) # Define HOST_LIB_PATH_gcc here, for the sake of TARGET_LIB_PATH, ouch @if gcc Now, for a more general solution that doesn't require user intervention, configure could go about looking for system libraries in the default search path, or in RPATH_ENV_VAR, that share the soname with those we're about to build, identify preexisting libraries that are newer than those we're about to build, populate a build-tree directory with symlinks to them, and default PREEMPT_HOST_LIB_PATH to that directory. WDYT? -- Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/ Free Software Activist GNU Toolchain Engineer More tolerance and less prejudice are key for inclusion and diversity Excludi
Re: [PATCH RFA] build: drop target libs from LD_LIBRARY_PATH [PR105688]
On Feb 21, 2024, Jason Merrill wrote: > So indeed I guess we still > want both prev and current libgcc directories in RPATH to handle the > case where we've removed the previous stage, as below. *nod*, thanks > I can't think of why we would need to depend on the current stage > target libraries, > If bootstrap doesn't actually need the target libraries. ISTM we may be miscommunicating. I'm not so worried about bootstrap itself as I am about post-bootstrap host tools. Those are unusual in that, after native bootstraps, they're built using the just-built (last-stage) compiler and target libraries, rather than the host compiler and system libraries. While configuring them, we need LD_LIBRARY_PATH (or similar) set up so that native execution tests can pass, at the very least; while building them, we may need LD_LIBRARY_PATH set up so that dependent libraries are found and link correctly. > I'm hoping for a fix that doesn't require individual users to know > about a workaround. I'm sure we'd all appreciate that, but AFAICT the conflicting requirements in scenarios of different freshness of libraries (system vs build) and both system tools and host tools dependencies on them would require a lot more intelligence in our build system to detect and react to the circumstances, deciding whether or not native tools used behind the scenes by the build will run with the just-built libraries, and whether or not the post-bootstrap host tools linked with the just-built libraries will run with the system libraries. There may even be scenarios in which these conflicting requirements would paint users into an inescapable corner AFAICT. The most worrying aspect is not libstdc++, but libgcc_s; it's needed as a dynamic library by languages that support exceptions, and depending on relative freshness of the toolchain being built and system libraries, newer symbols may be required by system programs and by just-built host tools. There doesn't seem to be an easy way around that. You have to either privilege one scenario over the other, like we do now, or introduce cleverness to detect and cope with such conflicting requirements, which we're not even trying to do. The approach in your patch changes the situation from privileging one scenario to privileging a mixed scenario (just-built libgcc but system libstdc++), and I'm pretty sure hunch that this mixed approach is likely to break down the road, even if not right now. -- Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/ Free Software Activist GNU Toolchain Engineer More tolerance and less prejudice are key for inclusion and diversity Excluding neuro-others for not behaving ""normal"" is *not* inclusive
Re: [PATCH] RISC-V: Fix CTZ unnecessary sign extension [PR #106888]
On Feb 20, 2024, Jeff Law wrote: > On 2/19/24 21:26, Alexandre Oliva wrote: >> This backport for gcc-13 is required for pr90838.c to get the expected >> count of andi instructions on riscv64-elf . > In general, shouldn't backports be focused on correctness issues? *nod*. > It's unclear what the motivation is for backporting this change into > gcc-13. There's this unexpected fail in gcc-13 (pr90838.c), one out of a handful that we've hit while transitioning our riscv toolchains to gcc-13. I set out to understand them, I identified the patches that got them to pass in the trunk, and so I've proposed their backports to fix the fails in gcc-13. Surely there are other ways to address each one of the fails. But even if we choose to just xfail them, or leave them failing noisily, I've already gone through the process of identifying the fix, so I figured I might as well share it. -- Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/ Free Software Activist GNU Toolchain Engineer More tolerance and less prejudice are key for inclusion and diversity Excluding neuro-others for not behaving ""normal"" is *not* inclusive
Re: [PATCH RFA] build: drop target libs from LD_LIBRARY_PATH [PR105688]
On Feb 16, 2024, Jason Merrill wrote: > So, for stage2+, let's add just prev- libgcc. I'm pretty sure this will break bootstrap-lean where libgcc_s isn't a system library, and we're building post-bootstrap host tools :-( We need the current stage lib after the prev stage is removed. I also doubt that TARGET_LIB_PATH was defined and used for no reason. My hunch is that bootstrap options and/or targets that don't have these libraries as system libraries will break in some obscure way without it. But I don't have the bandwidth to track down the history behind their inclusion. I insist that the entire approach of choosing the same set of target library directories regardless of the freshness relationship between e.g. a system libstdc++ and the one we're building can't possibly be an overall improvement, it's only trading problems in some scenarios (where we're building an older libstdc++) for problems in other scenarios (where we're building a newer libstdc++). The latter is unfortunately far more likely, which is reason enough for the current arrangement, but libstdc++ problems will likely only hit if the gap between system and being-built libraries is large enough (say, new symbols in the newer libstdc++ used by the compiler, but not available in the system library). I'm really uncomfortable with this change, especially at this stage. I'd much rather have a relatively obscure workaround for this relatively obscure problem, while keeping the defaults that have accumulated lots of testing on lots of configurations. An idea that occurred to me is to have some configure option or just a make variable that would be prepended to RPATH_ENVVAR, so that it would preempt TARGET_LIB_PATH. That would be a far more conservative change, that I think we could make even at this stage. WDYT? -- Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/ Free Software Activist GNU Toolchain Engineer More tolerance and less prejudice are key for inclusion and diversity Excluding neuro-others for not behaving ""normal"" is *not* inclusive
[PATCH] libcpp: Stabilize the location for macros restored after PCH load [PR105608]
This backport for gcc-13 is the second of two required for the
g++.dg/pch/line-map-3.C test to stop hitting a variant of the known
problem mentioned in that testcase: on riscv64-elf and riscv32-elf,
after restoring the PCH, the location of the macros is mentioned as if
they were on line 3 rather than 2, so even the existing xfails fail. I
think this might be too much to backport, and I'm ready to use an xfail
instead, but since this would bring more predictability, I thought I'd
ask whether you'd find this backport acceptable.
Regstrapped on x86_64-linux-gnu, along with other backports, and tested
manually on riscv64-elf. Ok to install?
From: Lewis Hyatt
libcpp currently lacks the infrastructure to assign correct locations to
macros that were defined prior to loading a PCH and then restored
afterwards. While I plan to address that fully for GCC 15, this patch
improves things by using at least a valid location, even if it's not the
best one. Without this change, libcpp uses pfile->directive_line as the
location for the restored macros, but this location_t applies to the old
line map, not the one that was just restored from the PCH, so the resulting
location is unpredictable and depends on what was stored in the line maps
before. With this change, all restored macros get assigned locations at the
line of the #include that triggered the PCH restore. A future patch will
store the actual file name and line number of each definition and then
synthesize locations in the new line map pointing to the right place.
gcc/c-family/ChangeLog:
PR preprocessor/105608
* c-pch.cc (c_common_read_pch): Adjust line map so that libcpp
assigns a location to restored macros which is the same location
that triggered the PCH include.
libcpp/ChangeLog:
PR preprocessor/105608
* pch.cc (cpp_read_state): Set a valid location for restored
macros.
(cherry picked from commit 019dc63819befb2b82077fb2d76b5dd670946f36)
---
gcc/c-family/c-pch.cc | 23 +++
libcpp/pch.cc |9 -
2 files changed, 23 insertions(+), 9 deletions(-)
diff --git a/gcc/c-family/c-pch.cc b/gcc/c-family/c-pch.cc
index 9ee6f1790023c..d60972ba93084 100644
--- a/gcc/c-family/c-pch.cc
+++ b/gcc/c-family/c-pch.cc
@@ -318,6 +318,7 @@ c_common_read_pch (cpp_reader *pfile, const char *name,
struct save_macro_data *smd;
expanded_location saved_loc;
bool saved_trace_includes;
+ int cpp_result;
timevar_push (TV_PCH_RESTORE);
@@ -343,20 +344,26 @@ c_common_read_pch (cpp_reader *pfile, const char *name,
cpp_set_line_map (pfile, line_table);
rebuild_location_adhoc_htab (line_table);
line_table->trace_includes = saved_trace_includes;
- linemap_add (line_table, LC_ENTER, 0, saved_loc.file, saved_loc.line);
+
+ /* Set the current location to the line containing the #include (or the
+ #pragma GCC pch_preprocess) for the purpose of assigning locations to any
+ macros that are about to be restored. */
+ linemap_add (line_table, LC_ENTER, 0, saved_loc.file,
+ saved_loc.line > 1 ? saved_loc.line - 1 : saved_loc.line);
timevar_push (TV_PCH_CPP_RESTORE);
- if (cpp_read_state (pfile, name, f, smd) != 0)
-{
- fclose (f);
- timevar_pop (TV_PCH_CPP_RESTORE);
- goto end;
-}
- timevar_pop (TV_PCH_CPP_RESTORE);
+ cpp_result = cpp_read_state (pfile, name, f, smd);
+ /* Set the current location to the line following the #include, where we
+ were prior to processing the PCH. */
+ linemap_line_start (line_table, saved_loc.line, 0);
+ timevar_pop (TV_PCH_CPP_RESTORE);
fclose (f);
+ if (cpp_result != 0)
+goto end;
+
/* Give the front end a chance to take action after a PCH file has
been loaded. */
if (lang_post_pch_load)
diff --git a/libcpp/pch.cc b/libcpp/pch.cc
index a9f4ff19bf1e1..17e423f44b801 100644
--- a/libcpp/pch.cc
+++ b/libcpp/pch.cc
@@ -838,7 +838,14 @@ cpp_read_state (cpp_reader *r, const char *name, FILE *f,
!= NULL)
{
_cpp_clean_line (r);
- if (!_cpp_create_definition (r, h, 0))
+
+ /* ??? Using r->line_table->highest_line is not ideal here, but we
+do need to use some location that is relative to the new line
+map just loaded, not the old one that was in effect when these
+macros were lexed. The proper fix is to remember the file name
+and line number where each macro was defined, and then add
+these locations into the new line map. See PR105608. */
+ if (!_cpp_create_definition (r, h, r->line_table->highest_line))
abort ();
_cpp_pop_buffer (r);
}
--
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
Free Software Activist GNU Toolchain Engineer
More tolerance and less prejudice are key for inclusion and dive
[PATCH] libcpp: Improve location for macro names [PR66290]
This backport for gcc-13 is the first of two required for the g++.dg/pch/line-map-3.C test to stop hitting a variant of the known problem mentioned in that testcase: on riscv64-elf and riscv32-elf, after restoring the PCH, the location of the macros is mentioned as if they were on line 3 rather than 2, so even the existing xfails fail. I think this might be too much to backport, and I'm ready to use an xfail instead, but since this would bring more predictability, I thought I'd ask whether you'd find this backport acceptable. Regstrapped on x86_64-linux-gnu, along with other backports, and tested manually on riscv64-elf. Ok to install? From: Lewis Hyatt When libcpp reports diagnostics whose locus is a macro name (such as for -Wunused-macros), it uses the location in the cpp_macro object that was stored by _cpp_new_macro. This is currently set to pfile->directive_line, which contains the line number only and no column information. This patch changes the stored location to the src_loc for the token defining the macro name, which includes the location and range information. libcpp/ChangeLog: PR c++/66290 * macro.cc (_cpp_create_definition): Add location argument. * internal.h (_cpp_create_definition): Adjust prototype. * directives.cc (do_define): Pass new location argument to _cpp_create_definition. (do_undef): Stop passing inferior location to cpp_warning_with_line; the default from cpp_warning is better. (cpp_pop_definition): Pass new location argument to _cpp_create_definition. * pch.cc (cpp_read_state): Likewise. gcc/testsuite/ChangeLog: PR c++/66290 * c-c++-common/cpp/macro-ranges.c: New test. * c-c++-common/cpp/line-2.c: Adapt to check for column information on macro-related libcpp warnings. * c-c++-common/cpp/line-3.c: Likewise. * c-c++-common/cpp/macro-arg-count-1.c: Likewise. * c-c++-common/cpp/pr58844-1.c: Likewise. * c-c++-common/cpp/pr58844-2.c: Likewise. * c-c++-common/cpp/warning-zero-location.c: Likewise. * c-c++-common/pragma-diag-14.c: Likewise. * c-c++-common/pragma-diag-15.c: Likewise. * g++.dg/modules/macro-2_d.C: Likewise. * g++.dg/modules/macro-4_d.C: Likewise. * g++.dg/modules/macro-4_e.C: Likewise. * g++.dg/spellcheck-macro-ordering.C: Likewise. * gcc.dg/builtin-redefine.c: Likewise. * gcc.dg/cpp/Wunused.c: Likewise. * gcc.dg/cpp/redef2.c: Likewise. * gcc.dg/cpp/redef3.c: Likewise. * gcc.dg/cpp/redef4.c: Likewise. * gcc.dg/cpp/ucnid-11-utf8.c: Likewise. * gcc.dg/cpp/ucnid-11.c: Likewise. * gcc.dg/cpp/undef2.c: Likewise. * gcc.dg/cpp/warn-redefined-2.c: Likewise. * gcc.dg/cpp/warn-redefined.c: Likewise. * gcc.dg/cpp/warn-unused-macros-2.c: Likewise. * gcc.dg/cpp/warn-unused-macros.c: Likewise. (cherry picked from commit 4f3be7cbebce8ec9e0c5d9340b2772581454b862) --- gcc/testsuite/c-c++-common/cpp/line-2.c|2 gcc/testsuite/c-c++-common/cpp/line-3.c|2 gcc/testsuite/c-c++-common/cpp/macro-arg-count-1.c |4 gcc/testsuite/c-c++-common/cpp/macro-ranges.c | 52 ++ gcc/testsuite/c-c++-common/cpp/pr58844-1.c |4 gcc/testsuite/c-c++-common/cpp/pr58844-2.c |4 .../c-c++-common/cpp/warning-zero-location.c |2 gcc/testsuite/c-c++-common/pragma-diag-14.c|2 gcc/testsuite/c-c++-common/pragma-diag-15.c|2 gcc/testsuite/g++.dg/modules/macro-2_d.C |4 gcc/testsuite/g++.dg/modules/macro-4_d.C |4 gcc/testsuite/g++.dg/modules/macro-4_e.C |2 gcc/testsuite/g++.dg/spellcheck-macro-ordering.C |2 gcc/testsuite/gcc.dg/builtin-redefine.c| 18 - gcc/testsuite/gcc.dg/cpp/Wunused.c |6 gcc/testsuite/gcc.dg/cpp/redef2.c | 20 - gcc/testsuite/gcc.dg/cpp/redef3.c | 14 - gcc/testsuite/gcc.dg/cpp/redef4.c | 520 ++-- gcc/testsuite/gcc.dg/cpp/ucnid-11-utf8.c | 12 gcc/testsuite/gcc.dg/cpp/ucnid-11.c| 12 gcc/testsuite/gcc.dg/cpp/undef2.c |6 gcc/testsuite/gcc.dg/cpp/warn-redefined-2.c| 10 gcc/testsuite/gcc.dg/cpp/warn-redefined.c | 10 gcc/testsuite/gcc.dg/cpp/warn-unused-macros-2.c|2 gcc/testsuite/gcc.dg/cpp/warn-unused-macros.c |2 libcpp/directives.cc | 13 - libcpp/internal.h |2 libcpp/macro.cc| 12 libcpp/pch.cc |2 29 files changed, 405 insertions(+), 342 deletions(-) create mode 100644 gcc/testsuite/c-c++-common/cpp/macro-ranges.c diff --git a/gcc/testsuite/c-c++-common/cpp/line-2.c
[PATCH] RISC-V: Fix CTZ unnecessary sign extension [PR #106888]
This backport for gcc-13 is required for pr90838.c to get the expected
count of andi instructions on riscv64-elf, rather than fail because of
two extra andi insns in functions where it is not necessary. (On
riscv32-elf, it passes). Regstrapped on x86_64-linux-gnu, along with
other backports, and tested manually on riscv64-elf. Ok to install?
From: Raphael Moreira Zinsly
Changes since v1:
- Remove subreg from operand 1.
-- >8 --
We were not able to match the CTZ sign extend pattern on RISC-V
because it gets optimized to zero extend and/or to ANDI patterns.
For the ANDI case, combine scrambles the RTL and generates the
extension by using subregs.
gcc/ChangeLog:
PR target/106888
* config/riscv/bitmanip.md
(disi2): Match with any_extend.
(disi2_sext): New pattern to match
with sign extend using an ANDI instruction.
gcc/testsuite/ChangeLog:
PR target/106888
* gcc.target/riscv/pr106888.c: New test.
* gcc.target/riscv/zbbw.c: Check for ANDI.
(cherry picked from commit 9000da00dd70988f30d43806bae33b22ee6b9904)
---
gcc/config/riscv/bitmanip.md | 13 -
gcc/testsuite/gcc.target/riscv/pr106888.c | 12
gcc/testsuite/gcc.target/riscv/zbbw.c |1 +
3 files changed, 25 insertions(+), 1 deletion(-)
create mode 100644 gcc/testsuite/gcc.target/riscv/pr106888.c
diff --git a/gcc/config/riscv/bitmanip.md b/gcc/config/riscv/bitmanip.md
index 7aa591689ba87..cc55ca133c3fe 100644
--- a/gcc/config/riscv/bitmanip.md
+++ b/gcc/config/riscv/bitmanip.md
@@ -246,13 +246,24 @@ (define_insn "*si2"
(define_insn "*disi2"
[(set (match_operand:DI 0 "register_operand" "=r")
-(sign_extend:DI
+(any_extend:DI
(clz_ctz_pcnt:SI (match_operand:SI 1 "register_operand" "r"]
"TARGET_64BIT && TARGET_ZBB"
"w\t%0,%1"
[(set_attr "type" "bitmanip")
(set_attr "mode" "SI")])
+;; A SImode clz_ctz_pcnt may be extended to DImode via subreg.
+(define_insn "*disi2_sext"
+ [(set (match_operand:DI 0 "register_operand" "=r")
+(and:DI (subreg:DI
+ (clz_ctz_pcnt:SI (match_operand:SI 1 "register_operand" "r")) 0)
+ (match_operand:DI 2 "const_int_operand")))]
+ "TARGET_64BIT && TARGET_ZBB && ((INTVAL (operands[2]) & 0x3f) == 0x3f)"
+ "w\t%0,%1"
+ [(set_attr "type" "bitmanip")
+ (set_attr "mode" "SI")])
+
(define_insn "*di2"
[(set (match_operand:DI 0 "register_operand" "=r")
(clz_ctz_pcnt:DI (match_operand:DI 1 "register_operand" "r")))]
diff --git a/gcc/testsuite/gcc.target/riscv/pr106888.c
b/gcc/testsuite/gcc.target/riscv/pr106888.c
new file mode 100644
index 0..77fb8e5b79c6b
--- /dev/null
+++ b/gcc/testsuite/gcc.target/riscv/pr106888.c
@@ -0,0 +1,12 @@
+/* { dg-do compile } */
+/* { dg-options "-march=rv64gc_zbb -mabi=lp64" } */
+
+int
+ctz (int i)
+{
+ int res = __builtin_ctz (i);
+ return res&0x;
+}
+
+/* { dg-final { scan-assembler-times "ctzw" 1 } } */
+/* { dg-final { scan-assembler-not "andi" } } */
diff --git a/gcc/testsuite/gcc.target/riscv/zbbw.c
b/gcc/testsuite/gcc.target/riscv/zbbw.c
index 709743c3b6807..f7b2b63853f40 100644
--- a/gcc/testsuite/gcc.target/riscv/zbbw.c
+++ b/gcc/testsuite/gcc.target/riscv/zbbw.c
@@ -23,3 +23,4 @@ popcount (int i)
/* { dg-final { scan-assembler-times "clzw" 1 } } */
/* { dg-final { scan-assembler-times "ctzw" 1 } } */
/* { dg-final { scan-assembler-times "cpopw" 1 } } */
+/* { dg-final { scan-assembler-not "andi\t" } } */
--
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
Free Software Activist GNU Toolchain Engineer
More tolerance and less prejudice are key for inclusion and diversity
Excluding neuro-others for not behaving ""normal"" is *not* inclusive
[PATCH] RISC-V: Fix error combine of pred_mov pattern
vd, m,vr,vr")
+(if_then_else:V
+ (unspec:
+[(match_operand: 1 "vector_mask_operand" "vmWc1, Wc1,
vm, vmWc1, Wc1, Wc1")
+ (match_operand 4 "vector_length_operand" " rK,rK,
rK,rK,rK,rK")
+ (match_operand 5 "const_int_operand" "i, i,
i, i, i, i")
+ (match_operand 6 "const_int_operand" "i, i,
i, i, i, i")
+ (match_operand 7 "const_int_operand" "i, i,
i, i, i, i")
+ (reg:SI VL_REGNUM)
+ (reg:SI VTYPE_REGNUM)] UNSPEC_VPREDICATE)
+ (match_operand:V 3 "reg_or_mem_operand" "m, m,
m,vr,vr,vr")
+ (match_operand:V 2 "vector_merge_operand""0,vu,
vu,vu,vu, 0")))]
+ "(TARGET_VECTOR
+&& (register_operand (operands[0], mode)
+|| register_operand (operands[3], mode)))"
"@
vle.v\t%0,%3%p1
vle.v\t%0,%3
vle.v\t%0,%3,%1.t
vse.v\t%3,%0%p1
vmv.v.v\t%0,%3
- vmv.v.v\t%0,%3
- vmv.v.i\t%0,%v3
- vmv.v.i\t%0,%v3"
+ vmv.v.v\t%0,%3"
"&& register_operand (operands[0], mode)
&& register_operand (operands[3], mode)
&& satisfies_constraint_vu (operands[2])
&& INTVAL (operands[7]) == riscv_vector::VLMAX"
[(set (match_dup 0) (match_dup 3))]
""
- [(set_attr "type" "vlde,vlde,vlde,vste,vimov,vimov,vimov,vimov")
+ [(set_attr "type" "vlde,vlde,vlde,vste,vimov,vimov")
(set_attr "mode" "")])
;; Dedicated pattern for vse.v instruction since we can't reuse pred_mov
pattern to include
@@ -1367,6 +1359,26 @@ (define_insn "*pred_broadcast_zero"
[(set_attr "type" "vimovxv,vimovxv")
(set_attr "mode" "")])
+;; Because (vec_duplicate imm) will be converted to (const_vector imm),
+;; This pattern is used to handle this case.
+(define_insn "*pred_broadcast_imm"
+ [(set (match_operand:V 0 "register_operand" "=vr,vr")
+(if_then_else:V
+ (unspec:
+[(match_operand: 1 "vector_all_trues_mask_operand" " Wc1,
Wc1")
+ (match_operand 4 "vector_length_operand" " rK,
rK")
+ (match_operand 5 "const_int_operand" "i,
i")
+ (match_operand 6 "const_int_operand" "i,
i")
+ (match_operand 7 "const_int_operand" "i,
i")
+ (reg:SI VL_REGNUM)
+ (reg:SI VTYPE_REGNUM)] UNSPEC_VPREDICATE)
+ (match_operand:V 3 "vector_const_int_or_double_0_operand" "viWc0, viWc0")
+ (match_operand:V 2 "vector_merge_operand" " vu,
0")))]
+ "TARGET_VECTOR"
+ "vmv.v.i\t%0,%v3"
+ [(set_attr "type" "vimov,vimov")
+ (set_attr "mode" "")])
+
;;
---
;; Predicated Strided loads/stores
;;
-------
diff --git a/gcc/testsuite/gcc.target/riscv/rvv/base/pr110943.c
b/gcc/testsuite/gcc.target/riscv/rvv/base/pr110943.c
new file mode 100644
index 0..8a6c00fc94d29
--- /dev/null
+++ b/gcc/testsuite/gcc.target/riscv/rvv/base/pr110943.c
@@ -0,0 +1,33 @@
+/* { dg-do compile } */
+/* { dg-options "-O3 -march=rv64gcv -mabi=lp64d" } */
+/* { dg-final { check-function-bodies "**" "" } } */
+
+#include
+
+/*
+** foo9:
+** vsetivli\tzero,1,e64,m2,t[au],m[au]
+** ...
+** vs2r.v\tv[0-9]+,0\([a-x0-9]+\)
+** ret
+*/
+void foo9 (void *base, void *out, size_t vl)
+{
+int64_t scalar = *(int64_t*)(base + 100);
+vint64m2_t v = __riscv_vmv_v_x_i64m2 (0, 1);
+*(vint64m2_t*)out = v;
+}
+
+/*
+** foo10:
+** vsetivli\tzero,1,e64,m2,t[au],m[au]
+** ...
+** vs2r.v\tv[0-9]+,0\([a-x0-9]+\)
+** ret
+*/
+void foo10 (void *base, void *out, size_t vl)
+{
+int64_t scalar = *(int64_t*)(base + 100);
+vint64m2_t v = __riscv_vmv_s_x_i64m2 (0, 1);
+*(vint64m2_t*)out = v;
+}
--
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
Free Software Activist GNU Toolchain Engineer
More tolerance and less prejudice are key for inclusion and diversity
Excluding neuro-others for not behaving ""normal"" is *not* inclusive
[PATCH] RISC-V: Revert the convert from vmv.s.x to vmv.v.i
*/
@@ -161,7 +161,7 @@ void foo11 (void *base, void *out, size_t vl)
/*
** foo12:
** ...
-** vmv.v.i\tv[0-9]+,\s*0
+** vmv.s.x\tv[0-9]+,\s*zero
** ...
** ret
*/
@@ -172,6 +172,20 @@ void foo12 (void *base, void *out, size_t vl)
*(vfloat64m2_t*)out = v;
}
+/*
+** foo12_1:
+** ...
+** vfmv.s.f\tv[0-9]+,\s*[a-x0-9]+
+** ...
+** ret
+*/
+void foo12_1 (void *base, void *out, size_t vl)
+{
+vfloat64m2_t merge = *(vfloat64m2_t*) (base + 200);
+vfloat64m2_t v = __riscv_vfmv_s_f_f64m2_tu (merge, 0.2, vl);
+*(vfloat64m2_t*)out = v;
+}
+
/*
** foo13:
** ...
--
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
Free Software Activist GNU Toolchain Engineer
More tolerance and less prejudice are key for inclusion and diversity
Excluding neuro-others for not behaving ""normal"" is *not* inclusive
[PATCH] RISC-V: Fix riscv/arch-19.c with different ISA spec version
This testcase is failing with riscv64-elf and riscv32-elf in the gcc-13
branch, if configured to use an assembler that supports -misa-spec; with
an assembler that doesn't, the test passes both with and without the
following backport from the trunk, so I'd like to install it in gcc-13.
Regstrapped on x86_64-linux-gnu, along with other backports, and tested
manually on riscv64-elf. Ok to install?
From: Kito Cheng
In newer ISA spec, F will implied zicsr, add that into -march option to
prevent different test result on different default -misa-spec version.
gcc/testsuite/
* gcc.target/riscv/arch-19.c: Add -misa-spec.
(cherry picked from commit 9fde76a3be8e1717d9d38492c40675e742611e45)
---
gcc/testsuite/gcc.target/riscv/arch-19.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/gcc/testsuite/gcc.target/riscv/arch-19.c
b/gcc/testsuite/gcc.target/riscv/arch-19.c
index b042e1a49fe6f..95204ede26a69 100644
--- a/gcc/testsuite/gcc.target/riscv/arch-19.c
+++ b/gcc/testsuite/gcc.target/riscv/arch-19.c
@@ -1,4 +1,4 @@
/* { dg-do compile } */
-/* { dg-options "-march=rv64if_zfinx -mabi=lp64" } */
+/* { dg-options "-march=rv64if_zicsr_zfinx -mabi=lp64" } */
int foo() {}
-/* { dg-error "'-march=rv64if_zfinx': z\\*inx conflicts with floating-point
extensions" "" { target *-*-* } 0 } */
+/* { dg-error "'-march=rv64if_zicsr_zfinx': z\\*inx conflicts with
floating-point extensions" "" { target *-*-* } 0 } */
--
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
Free Software Activist GNU Toolchain Engineer
More tolerance and less prejudice are key for inclusion and diversity
Excluding neuro-others for not behaving ""normal"" is *not* inclusive
Re: [PATCH] gcc/Makefile.in: Fix install-info target if BUILD_INFO is empty
Hello, Christophe, On Feb 10, 2024, Christophe Lyon wrote: > gcc/ > * Makefile.in: Add no-info dependency. > * configure.ac: Set BUILD_INFO=no-info if makeinfo is not > available. > * configure: Regenerate. Thank you, this is ok. Now, this doesn't fix a regression, does it? I would support putting this in for GCC 14, but I would be overstepping my authority if I approved even such a small and well-contained improvement patch in the current stage, so I'm approving it for stage1, but maybe some global maintainer or release manager will chime in in support for earlier merging? (hint, hint ;-) -- Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/ Free Software Activist GNU Toolchain Engineer Disinformation flourishes because many people care deeply about injustice but very few check the facts. Think Assange & Stallman. The empires strike back
Re: [PATCH RFA] build: drop target libs from LD_LIBRARY_PATH [PR105688]
On Feb 6, 2024, Jason Merrill wrote: > Reverting that hunk of the change fixed my problem with bubblestrapping GCC > 12 with ccache on a host with a newer system libstdc++. Did you have libcc1, gnattools and gotools enabled in your testing? Those non-bootstrapped tools are most likely to be problem spots. I have a vague recollection that, in native scenarios, when bootstrapping but not when not boostrapping, they are (or used to be?) built using the just-built (last-stage) compiler and target libraries, rather than system tools or previous stage (which I believe would fail bootstrap-lean). Just by looking at the current code I can't bring back to mind all the involved moving parts :-/ but my guess is that the need for TARGET_LIB_PATH comes about for this combination of circumstances, in which we would need to use the just-built native-target libstdc++ to link or to run these host tools using the just-built tools. Having a newer system libstdc++ would, I suspect, unfortunately mask the problem that those who had an older or no system libstdc++ would likely run into. OTOH, if the system linker requires the newer system library, and ld.so and ld overload LD_LIBRARY_PATH for both the libraries loaded for ld to run, the libraries ld searches to link executables, and the libraries loaded for so-linked programs to run, we seem to need some means to distinguish between these three circumstances so as to be able to set LD_LIBRARY_PATH correctly for each one, whether the libstdc++ we're building is newer or older than the system one. And there's an added complication that any single ld invocation involves two different and potentially conflicting uses of LD_LIBRARY_PATH. /me runs screaming :-) Perhaps the best we can do out of these conflicting requirements is to somehow detect a system libstdc++ newer than the one we're about to build, and fail early if we find that some of the tools depend on the newer libstdc++, or disable this env var setting for this case only and hope the newer system library is compatible enough. Holy nightmare, Batman! :-) :-( Perhaps the way to go is an explicit configure setting, recommended by the fail early, to disable the env var setting? -- Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/ Free Software Activist GNU Toolchain Engineer More tolerance and less prejudice are key for inclusion and diversity Excluding neuro-others for not behaving ""normal"" is *not* inclusive
