[Patch, www-docs, Fortran, Coarray-ABI] Announce coarray-ABI changes in gfortran-15
Hi all,
attached patch makes an attempt to announce the ABI-changes in the coarrays
library. Me being German always has difficulties to find a proper wording. So
please propose improvements.
Stupid question: How to I test this? The change looks good in my browser. Is
there a style checker, I don't see?
Regards,
Ande
--
Andre Vehreschild * Email: vehre ad gmx dot de
From 8b1ba25dd27c89dc6ff860835431e09f3895a4e1 Mon Sep 17 00:00:00 2001
From: Andre Vehreschild
Date: Thu, 20 Feb 2025 10:47:22 +0100
Subject: [PATCH] gcc-15/changes: Document coarray changes.
ABI of coarrays has changed. Document possible linker errors for
caf_single.
---
htdocs/gcc-15/changes.html | 6 ++
1 file changed, 6 insertions(+)
diff --git a/htdocs/gcc-15/changes.html b/htdocs/gcc-15/changes.html
index 853fad03..ea1e7553 100644
--- a/htdocs/gcc-15/changes.html
+++ b/htdocs/gcc-15/changes.html
@@ -436,6 +436,12 @@ asm (".text; %cc0: mov %cc2, %%r0; .previous;"
incompatible with the module format generated by GCC 8 - 14, but GCC
15 can for compatibility still read GCC 8 - 14 created module
files.
+ Coarray support has been reworked to allow access to data in derived types
+ that have not been compiled with coarray support enabled. Esp. when the
+ derived type is in a binary only module. This may lead to linking errors
+ with the provided caf_single-libraries of previous GCC versions. It is
+ recommended to only use the newest version of caf_single. The OpenCoarrays
+ library is not affected and provides all ABIs.
--
2.48.1
Contents of PO file 'cpplib-15-b20250216.zh_CN.po'
cpplib-15-b20250216.zh_CN.po.gz Description: Binary data The Translation Project robot, in the name of your translation coordinator.
New Chinese (simplified) PO file for 'cpplib' (version 15-b20250216)
Hello, gentle maintainer. This is a message from the Translation Project robot. A revised PO file for textual domain 'cpplib' has been submitted by the Chinese (simplified) team of translators. The file is available at: https://translationproject.org/latest/cpplib/zh_CN.po (This file, 'cpplib-15-b20250216.zh_CN.po', has just now been sent to you in a separate email.) All other PO files for your package are available in: https://translationproject.org/latest/cpplib/ Please consider including all of these in your next release, whether official or a pretest. Whenever you have a new distribution with a new version number ready, containing a newer POT file, please send the URL of that distribution tarball to the address below. The tarball may be just a pretest or a snapshot, it does not even have to compile. It is just used by the translators when they need some extra translation context. The following HTML page has been updated: https://translationproject.org/domain/cpplib.html If any question arises, please contact the translation coordinator. Thank you for all your work, The Translation Project robot, in the name of your translation coordinator.
[PATCH 1/2] libstdc++: Use init_priority attribute for tzdb globals [PR118811]
When linking statically to libstdc++.a (or to libstdc++_nonshared.a in
the RHEL devtoolset compiler) there's a static initialization order
problem where user code might be constructed before the
std::chrono::tzdb_list globals, and so might try to use them after
they've already been destroyed.
Use the init_priority attribute on those globals so that they are
initialized early. Since r15-7511-g4e7f74225116e7 we can disable the
warnings for using a reserved priority using a diagnostic pragma.
libstdc++-v3/ChangeLog:
PR libstdc++/118811
* src/c++20/tzdb.cc (tzdb_list::_Node): Use init_priority
attribute on static data members.
* testsuite/std/time/tzdb_list/pr118811.cc: New test.
---
Tested x86_64-linux. Pushed to trunk.
This needs to be backported too, but will have to use the system header
hack to use the attribute without warnings.
libstdc++-v3/src/c++20/tzdb.cc| 11 +---
.../testsuite/std/time/tzdb_list/pr118811.cc | 25 +++
2 files changed, 32 insertions(+), 4 deletions(-)
create mode 100644 libstdc++-v3/testsuite/std/time/tzdb_list/pr118811.cc
diff --git a/libstdc++-v3/src/c++20/tzdb.cc b/libstdc++-v3/src/c++20/tzdb.cc
index 7e8cce7ce8c..c3bb6a12ccc 100644
--- a/libstdc++-v3/src/c++20/tzdb.cc
+++ b/libstdc++-v3/src/c++20/tzdb.cc
@@ -133,6 +133,8 @@ namespace std::chrono
// of this type gives them access to the private members of time_zone
// and tzdb, without needing them declared in the header.
+// The tzdb_list singleton. This doesn't contain the actual linked list,
+// but it has member functions that give access to it.
static tzdb_list _S_the_list;
#if USE_ATOMIC_SHARED_PTR
@@ -177,15 +179,16 @@ namespace std::chrono
// Implementation of the private constructor used for the singleton object.
constexpr tzdb_list::tzdb_list(nullptr_t) { }
- // The tzdb_list singleton. This doesn't contain the actual linked list,
- // but it has member functions that give access to it.
+#pragma GCC diagnostic ignored "-Wprio-ctor-dtor"
+
+ [[gnu::init_priority(99)]]
constinit tzdb_list tzdb_list::_Node::_S_the_list(nullptr);
- // Shared pointer to the first Node in the list.
+ [[gnu::init_priority(99)]]
constinit tzdb_list::_Node::head_ptr
tzdb_list::_Node::_S_head_owner{nullptr};
#if USE_ATOMIC_LIST_HEAD
- // Lock-free access to the first Node in the list.
+ [[gnu::init_priority(99)]]
constinit atomic tzdb_list::_Node::_S_head_cache{nullptr};
#endif
diff --git a/libstdc++-v3/testsuite/std/time/tzdb_list/pr118811.cc
b/libstdc++-v3/testsuite/std/time/tzdb_list/pr118811.cc
new file mode 100644
index 000..3968be3f0ec
--- /dev/null
+++ b/libstdc++-v3/testsuite/std/time/tzdb_list/pr118811.cc
@@ -0,0 +1,25 @@
+// { dg-do run { target c++20 } }
+// { dg-require-effective-target tzdb }
+// { dg-require-effective-target cxx11_abi }
+// { dg-require-static-libstdcxx }
+// { dg-additional-options "-static-libstdc++" }
+
+#include
+
+struct Global
+{
+ Global()
+ {
+(void) std::chrono::current_zone(); // initialize tzdb on first use
+ }
+
+ ~Global()
+ {
+(void) std::chrono::current_zone(); // attempt to use it again on exit
+ }
+
+} global;
+
+int main()
+{
+}
--
2.48.1
[PATCH 2/2] libstdc++: Remove workaround for reserved init_priority warnings
Since r15-7511-g4e7f74225116e7 we can disable the warnings for using a
reserved priority using a diagnostic pragma. That means we no longer
need to put globals using that attribute into separate files that get
included.
This replaces the two uses of such separate files by moving the variable
definition into the source file and adding the diagnostic pragma.
libstdc++-v3/ChangeLog:
* src/c++17/memory_resource.cc (default_res): Define here
instead of including default_resource.h.
* src/c++98/globals_io.cc (__ioinit): Define here instead of
including ios_base_init.h.
* src/c++17/default_resource.h: Removed.
* src/c++98/ios_base_init.h: Removed.
---
Tested x86_64-linux. Pushed to trunk.
libstdc++-v3/src/c++17/default_resource.h | 15 ---
libstdc++-v3/src/c++17/memory_resource.cc | 5 -
libstdc++-v3/src/c++98/globals_io.cc | 11 ++-
libstdc++-v3/src/c++98/ios_base_init.h| 13 -
4 files changed, 14 insertions(+), 30 deletions(-)
delete mode 100644 libstdc++-v3/src/c++17/default_resource.h
delete mode 100644 libstdc++-v3/src/c++98/ios_base_init.h
diff --git a/libstdc++-v3/src/c++17/default_resource.h
b/libstdc++-v3/src/c++17/default_resource.h
deleted file mode 100644
index f8d03d7d3bc..000
--- a/libstdc++-v3/src/c++17/default_resource.h
+++ /dev/null
@@ -1,15 +0,0 @@
-// This is only in a header so we can use the system_header pragma,
-// to suppress the warning caused by using a reserved init_priority.
-#pragma GCC system_header
-
-#ifndef _GLIBCXX_HAS_GTHREADS
-# error "This file should not be included for this build"
-#elif ATOMIC_POINTER_LOCK_FREE == 2
-# error "This file should not be included for this build"
-#elif defined __GTHREAD_MUTEX_INIT
-# error "This file should not be included for this build"
-#endif
-
-struct {
- atomic_mem_res obj = &newdel_res.obj;
-} default_res __attribute__ ((init_priority (100)));
diff --git a/libstdc++-v3/src/c++17/memory_resource.cc
b/libstdc++-v3/src/c++17/memory_resource.cc
index 2b6bfbd4dd3..0e984f27b82 100644
--- a/libstdc++-v3/src/c++17/memory_resource.cc
+++ b/libstdc++-v3/src/c++17/memory_resource.cc
@@ -149,7 +149,10 @@ namespace pmr
#ifdef _GLIBCXX_ATOMIC_MEM_RES_CAN_BE_CONSTANT_INITIALIZED
__constinit constant_init default_res{&newdel_res.obj};
#else
-# include "default_resource.h"
+# pragma GCC diagnostic ignored "-Wprio-ctor-dtor"
+struct {
+ atomic_mem_res obj = &newdel_res.obj;
+} default_res __attribute__ ((init_priority (100)));
#endif
} // namespace
diff --git a/libstdc++-v3/src/c++98/globals_io.cc
b/libstdc++-v3/src/c++98/globals_io.cc
index 6dc6bf40fe2..e30edf7eae2 100644
--- a/libstdc++-v3/src/c++98/globals_io.cc
+++ b/libstdc++-v3/src/c++98/globals_io.cc
@@ -69,7 +69,16 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
fake_wostream wclog;
#endif
-#include "ios_base_init.h"
+// If the target supports init priorities, set up a static object in the
+// compiled library to perform the initialization once and
+// sufficiently early (so that it happens before any other global
+// constructor when statically linking with libstdc++.a), instead of
+// doing so in (each TU that includes) .
+// This needs to be done in the same TU that defines the stream objects.
+#if _GLIBCXX_USE_INIT_PRIORITY_ATTRIBUTE
+#pragma GCC diagnostic ignored "-Wprio-ctor-dtor"
+static ios_base::Init __ioinit __attribute__((init_priority(90)));
+#endif
_GLIBCXX_END_NAMESPACE_VERSION
} // namespace
diff --git a/libstdc++-v3/src/c++98/ios_base_init.h
b/libstdc++-v3/src/c++98/ios_base_init.h
deleted file mode 100644
index f7edfc84625..000
--- a/libstdc++-v3/src/c++98/ios_base_init.h
+++ /dev/null
@@ -1,13 +0,0 @@
-// This is only in a header so we can use the system_header pragma,
-// to suppress the warning caused by using a reserved init_priority.
-#pragma GCC system_header
-
-// If the target supports init priorities, set up a static object in the
-// compiled library to perform the initialization once and
-// sufficiently early (so that it happens before any other global
-// constructor when statically linking with libstdc++.a), instead of
-// doing so in (each TU that includes) .
-// This needs to be done in the same TU that defines the stream objects.
-#if _GLIBCXX_USE_INIT_PRIORITY_ATTRIBUTE
-static ios_base::Init __ioinit __attribute__((init_priority(90)));
-#endif
--
2.48.1
[PATCH 2/2] libstdc++: Workaround Clang bug with __array_rank built-in [PR118559]
We started using the __array_rank built-in with r15-1252-g6f0dfa6f1acdf7
but that built-in is buggy in versions of Clang up to and including 19.
libstdc++-v3/ChangeLog:
PR libstdc++/118559
* include/std/type_traits (rank, rank_v): Do not use
__array_rank for Clang 19 and older.
---
Tested x86_64-linux. Pushed to trunk.
libstdc++-v3/include/std/type_traits | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/libstdc++-v3/include/std/type_traits
b/libstdc++-v3/include/std/type_traits
index 33892818257..676cdf2d7e6 100644
--- a/libstdc++-v3/include/std/type_traits
+++ b/libstdc++-v3/include/std/type_traits
@@ -1484,7 +1484,8 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
};
/// rank
-#if _GLIBCXX_USE_BUILTIN_TRAIT(__array_rank)
+#if _GLIBCXX_USE_BUILTIN_TRAIT(__array_rank) \
+ && (!defined(__clang__) || __clang_major__ >= 20) // PR118559
template
struct rank
: public integral_constant { };
@@ -3656,7 +3657,8 @@ template
template
inline constexpr size_t alignment_of_v = alignment_of<_Tp>::value;
-#if _GLIBCXX_USE_BUILTIN_TRAIT(__array_rank)
+#if _GLIBCXX_USE_BUILTIN_TRAIT(__array_rank) \
+ && (!defined(__clang__) || __clang_major__ >= 20) // PR118559
template
inline constexpr size_t rank_v = __array_rank(_Tp);
#else
--
2.48.1
[PATCH 1/2] libstdc++: Add parentheses around _GLIBCXX_HAS_BUILTIN definition
This allows _GLIBCXX_HAS_BUILTIN (or _GLIBCXX_USE_BUILTIN_TRAIT) to be used as part of a larger logical expression. libstdc++-v3/ChangeLog: * include/bits/c++config (_GLIBCXX_HAS_BUILTIN): Add parentheses. --- Tested x86_64-linux. Pushed to trunk. This isn't currently necessary on the release branches but it might be worth backporting anyway, in case we want to be able to use this macro as `_GLIBCXX_HAS_BUILTIN(foo) && bar` on the branches in future. libstdc++-v3/include/bits/c++config | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libstdc++-v3/include/bits/c++config b/libstdc++-v3/include/bits/c++config index b0ca6579cfb..07f75ea6659 100644 --- a/libstdc++-v3/include/bits/c++config +++ b/libstdc++-v3/include/bits/c++config @@ -885,7 +885,7 @@ namespace __gnu_cxx #ifdef __has_builtin # ifdef __is_identifier // Intel and older Clang require !__is_identifier for some built-ins: -# define _GLIBCXX_HAS_BUILTIN(B) __has_builtin(B) || ! __is_identifier(B) +# define _GLIBCXX_HAS_BUILTIN(B) (__has_builtin(B) || ! __is_identifier(B)) # else # define _GLIBCXX_HAS_BUILTIN(B) __has_builtin(B) # endif -- 2.48.1
[PATCH v2 2/2] libstdc++: Use new type-generic built-ins in [PR118855]
This makes several functions in faster to compile, with fewer
expressions to parse and fewer instantiations of __numeric_traits
required.
libstdc++-v3/ChangeLog:
PR libstdc++/118855
* include/std/bit (__count_lzero, __count_rzero, __popcount):
Use type-generic built-ins when available.
---
The v1 patch used __has_builtin directly, but this version uses
_GLIBCXX_USE_BUILTIN_TRAIT instead.
Tested x86_64-linux. Pushed to trunk.
libstdc++-v3/include/std/bit | 12
1 file changed, 12 insertions(+)
diff --git a/libstdc++-v3/include/std/bit b/libstdc++-v3/include/std/bit
index 483801ee85b..a4817818d19 100644
--- a/libstdc++-v3/include/std/bit
+++ b/libstdc++-v3/include/std/bit
@@ -205,6 +205,9 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
using __gnu_cxx::__int_traits;
constexpr auto _Nd = __int_traits<_Tp>::__digits;
+#if _GLIBCXX_USE_BUILTIN_TRAIT(__builtin_clzg)
+ return __builtin_clzg(__x, _Nd);
+#else
if (__x == 0)
return _Nd;
@@ -242,6 +245,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
unsigned long long __low = __x & __max_ull;
return (_Nd - _Nd_ull) + __builtin_clzll(__low);
}
+#endif
}
template
@@ -258,6 +262,9 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
using __gnu_cxx::__int_traits;
constexpr auto _Nd = __int_traits<_Tp>::__digits;
+#if _GLIBCXX_USE_BUILTIN_TRAIT(__builtin_ctzg)
+ return __builtin_ctzg(__x, _Nd);
+#else
if (__x == 0)
return _Nd;
@@ -283,6 +290,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
unsigned long long __high = __x >> _Nd_ull;
return __builtin_ctzll(__high) + _Nd_ull;
}
+#endif
}
template
@@ -296,6 +304,9 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
constexpr int
__popcount(_Tp __x) noexcept
{
+#if _GLIBCXX_USE_BUILTIN_TRAIT(__builtin_popcountg)
+ return __builtin_popcountg(__x);
+#else
using __gnu_cxx::__int_traits;
constexpr auto _Nd = __int_traits<_Tp>::__digits;
@@ -319,6 +330,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
unsigned long long __high = __x >> _Nd_ull;
return __builtin_popcountll(__low) + __builtin_popcountll(__high);
}
+#endif
}
template
--
2.48.1
Re: [PATCH] RISC-V: Minimal support for Qualcomm uC Xqccmp extension.
On Thu, Feb 20, 2025 at 12:33 AM Dongyan Chen
wrote:
>
> This patch support Qualcomm uC Xqccmp extension[1].
> To enable GCC to recognize and process xqccmp extension correctly at compile
> time.
>
> [1]https://github.com/quic/riscv-unified-db/releases/tag/Xqccmp_extension-0.1.0
I am kinda of curious why you need this? Also is there a corresponding
binutils patch?
Please also CC myself (quic_apin...@quicinc.com) on all qualcomm
related GCC/GNU binutils patches.
Thanks,
Andrew Pinski
>
> gcc/ChangeLog:
>
> * common/config/riscv/riscv-common.cc: New extension.
> * common/config/riscv/riscv-ext-bitmask.def (RISCV_EXT_BITMASK):
> Ditto.
> * config/riscv/riscv.opt: Ditto.
>
> gcc/testsuite/ChangeLog:
>
> * gcc.target/riscv/arch-45.c: New test.
>
> ---
> gcc/common/config/riscv/riscv-common.cc | 6 ++
> gcc/common/config/riscv/riscv-ext-bitmask.def | 1 +
> gcc/config/riscv/riscv.opt| 5 +
> gcc/testsuite/gcc.target/riscv/arch-45.c | 5 +
> 4 files changed, 17 insertions(+)
> create mode 100644 gcc/testsuite/gcc.target/riscv/arch-45.c
>
> diff --git a/gcc/common/config/riscv/riscv-common.cc
> b/gcc/common/config/riscv/riscv-common.cc
> index 5038f0eb959a..6fbdb5ed2316 100644
> --- a/gcc/common/config/riscv/riscv-common.cc
> +++ b/gcc/common/config/riscv/riscv-common.cc
> @@ -229,6 +229,8 @@ static const riscv_implied_info_t riscv_implied_info[] =
>
>{"xsfvcp", "zve32x"},
>
> + {"xqccmp", "zca"},
> +
>{NULL, NULL}
> };
>
> @@ -442,6 +444,8 @@ static const struct riscv_ext_version
> riscv_ext_version_table[] =
>{"xsfvqmaccdod",ISA_SPEC_CLASS_NONE, 1, 0},
>{"xsfvfnrclipxfqf", ISA_SPEC_CLASS_NONE, 1, 0},
>
> + {"xqccmp", ISA_SPEC_CLASS_NONE, 0, 1},
> +
>/* Terminate the list. */
>{NULL, ISA_SPEC_CLASS_NONE, 0, 0}
> };
> @@ -1778,6 +1782,8 @@ static const riscv_ext_flag_table_t
> riscv_ext_flag_table[] =
>RISCV_EXT_FLAG_ENTRY ("xsfvqmaccdod",x_riscv_sifive_subext,
> MASK_XSFVQMACCDOD),
>RISCV_EXT_FLAG_ENTRY ("xsfvfnrclipxfqf", x_riscv_sifive_subext,
> MASK_XSFVFNRCLIPXFQF),
>
> + RISCV_EXT_FLAG_ENTRY ("xqccmp", x_riscv_qc_subext, MASK_XQCCMP),
> +
>{NULL, NULL, NULL, 0}
> };
>
> diff --git a/gcc/common/config/riscv/riscv-ext-bitmask.def
> b/gcc/common/config/riscv/riscv-ext-bitmask.def
> index 8b4e6d6349a7..c2809460d582 100644
> --- a/gcc/common/config/riscv/riscv-ext-bitmask.def
> +++ b/gcc/common/config/riscv/riscv-ext-bitmask.def
> @@ -79,5 +79,6 @@ RISCV_EXT_BITMASK ("zcd", 1, 4)
> RISCV_EXT_BITMASK ("zcf", 1, 5)
> RISCV_EXT_BITMASK ("zcmop",1, 6)
> RISCV_EXT_BITMASK ("zawrs",1, 7)
> +RISCV_EXT_BITMASK ("xqccmp", 1, 8)
>
> #undef RISCV_EXT_BITMASK
> diff --git a/gcc/config/riscv/riscv.opt b/gcc/config/riscv/riscv.opt
> index 7515c8ea13dd..61cc8258e323 100644
> --- a/gcc/config/riscv/riscv.opt
> +++ b/gcc/config/riscv/riscv.opt
> @@ -535,6 +535,11 @@ Mask(XSFVQMACCDOD) Var(riscv_sifive_subext)
>
> Mask(XSFVFNRCLIPXFQF) Var(riscv_sifive_subext)
>
> +TargetVariable
> +int riscv_qc_subext
> +
> +Mask(XQCCMP) Var(riscv_qc_subext)
> +
> TargetVariable
> int riscv_fmv_priority = 0
>
> diff --git a/gcc/testsuite/gcc.target/riscv/arch-45.c
> b/gcc/testsuite/gcc.target/riscv/arch-45.c
> new file mode 100644
> index ..590d4f130325
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/riscv/arch-45.c
> @@ -0,0 +1,5 @@
> +/* { dg-do compile } */
> +/* { dg-options "-march=rv64gc_xqccmp -mabi=lp64" } */
> +int foo()
> +{
> +}
> --
> 2.43.0
>
Re: The COBOL front end, version 3, now in 14 easy pieces
On Wed, Feb 19, 2025 at 12:38 AM James K. Lowden
wrote:
>
> The following 14 patches constitute 105,720 lines of code in 83 files
> to build and document the COBOL front end. The messages are
> in a more or less logical order. We have:
>
> 1/14 4K dir: create gcc/cobol and libgcobol directories
> 2/14 8K pre: introduce ChangeLog files
> 3/14 80K bld: config and build machinery
> 4/14 376K hdr: header files
> 5/14 152K lex: lexer
> 6/14 476K par: parser
> 7/14 344K cbl: parser support
> 8/14 516K api: GENERIC interface
> 9/14 244K gen: GENERIC interface support
> 10/14 72K doc: man pages and GnuCOBOL emulation
> 11/14 84K lhd: libgcobol header files
> 12/14 320K lib: libgcobol support
> 13/14 372K lcc: libgcobol, main file
> 14/14 148K fun: libgcobol, intrinsic functions
>
> To slide under the 400 KB limit, the intrinsic functions now have
> their own patch. The configure files are removed, as is the Posix
> adapter framework.
>
> They are still against the master branch as of
>
> commit 3e08a4ecea27c54fda90e8f58641b1986ad957e1
> Date: Wed Feb 5 14:22:33 2025 -0700
>
> Our repository is
>
> https://gitlab.cobolworx.com/COBOLworx/gcc-cobol/
>
> using branch
>
> cobol-stage
>
> I tested these patches using "git apply" to an unpublished branch
> "cobol-patched".
>
> We have endeavored to address all must-fix issues raised in Round 2.
>
> 1. Generated files use Autoconf 2.69
> 2. Commit message matches mail Subject: line
> 3. Various problems with Make-lang.in and cobol1.cc
> 4. s/assert(false)/gcc_unreachable()/g
> 5. Nixed range-based cases
> 6. Removed Posix adapter files & generated configure scripts
> 7. Explained memory-management engineering choice
> 8. s/option_id/option_zero/g, for clarity
> 9. GTY issues
> 10. Require only C++14 (not 17)
> 11. Moved #include
> 12. Check regex buffer bounds outside gcc_assert
>
> Still to do (no particular order):
>
> 13. Try SARIF options
> 14. Do not compose messages (I18N).
> 15. Try valgrind for memory report
> 16. Review
> https://github.com/cooljeanius/legislation/blob/master/tech/21-R-mrg.htm.diff
> 17. Enumerated warnings in cobol/lang.opt.
> 18. texinfo update to describe gcobol
> 19. cross-compilation
>
> There are a few places where gcc_unreachable() is now followed by truly
> unreachable code. We will lop off those bits soon.
>
> This patchset still excludes tests. I will supply tests separately.
> Simplest I think is to use the NIST test suite, assuming the code and
> documentation pass legal muster.
Looking at 'cobol-stage' it contains more than the patches. Can you make
'cobol-patched' published (you can rebase that at will IMO) to make it easier
to look at the whole thing as proposed to merge at this point?
> I have also prepared release notes for the www repository under
> separate cover.
>
> We remain hopeful the COBOL front end will be accepted into gcc-15.
Me too, I think we are at the point where merging and fixing issues that pop
up during the remains of stage4 is probably more efficient than repeated
re-spinning of the patches.
Can you clarify on the future development model for Cobol after it has
been merged? Is the cobolworx gitlab still going to be the primary
development location and changes should be made there and then merged
to the GCC side? If the gcc.gnu.org git repository isn't the primary
source this should be noted in the README (the situation might differ
for libgcobol and gcc/cobol I guess).
The most important part for GCC 15 will be documentation to get
user expectancy right. Having a minimal harness in GCCs testsuite
is critical - I'd expect a gcc/testsuite/gcobol.dg/dg.exp supporting
execution tests. I assume Cobol has a way to exit OK or fatally
and this should be distinguished as testsuite PASS or FAIL. I'm not
sure if /* { dg-... } */ directive support is easy or desirable (well,
desirable for sure). I'd be happy with a setup like the old
gcc.c-torture/{execute,compile}. Possibly tcl/shell wrapping
around the NIST tests (even if not included in the GCC tree,
running that by unpacking it in gcc/testsuite/gcobol/nist would be nice).
Thanks,
Richard.
> Thank you for your kind consideration of our work.
>
> --jkl
Re: 7/7 [Fortran, Patch, Coarray, PR107635] Remove deprecated coarray routines
Hi all, I just merged the patch series as gcc-15-7644-gd3244675441. Thanks for all the reviews. I will now prepare the Relasenotes. Regards and thanks again, Andre On Tue, 18 Feb 2025 18:13:53 +0100 Thomas Koenig wrote: > Am 18.02.25 um 16:00 schrieb Andre Vehreschild: > > Hi Thomas, > > > >> This patch series (of necessity) introduces ABI changes. What will > >> happen with user code compiled against the old interface? > > > > That depends on the library you are linking against. When using caf_single > > from gfortran, then you will get link failures when you mix code compiled by > > gfortran < 15 and gfortran-15. But caf_single is anyhow only considered for > > testing. So why should one do this ? > > OK. > > > If your questions targets the users of this ABI, which to my knowledge is > > only OpenCoarrays at the moment, then the user will experience nothing. A > > mix of pre-gfortran-15 and gfortran-15 generated .o-files will link and > > work as expected, because OpenCoarrays provides all ABIs. We do not compile > > a gfortran-15 exclusive version of OpenCoarrays, i.e. all routines are > > present, fully functional and interoperable. > > Very good, then. > > >> I guess a link failure (plus an answer in stack exchange where the > >> explanation is given, so people can google it, and a mention in the > >> release notes) would be acceptable, but is there anything that > >> can be done in addition? > > > > I can provide an entry in release notes, if need be. Where do I have to do > > this? Never did. > > It is a separate repository from the gcc source, it can be found by > cloning git+ssh://you...@gcc.gnu.org/git/gcc-wwwdocs.git . > > Best regards (and a lot of thanks for the patch series!) > > Thomas > -- Andre Vehreschild * Email: vehre ad gmx dot de
Re: [PATCH] RISC-V: Minimal support for Qualcomm uC Xqccmp extension.
Seeing some work submitted in llvm, I would like to add support in gcc
as well. I am sorry that the binutils patch is working in progress, and
I will CC you the binutils patches as soon as possible.
Thanks,
Dongyan Chen
在 2025/2/20 16:39, Andrew Pinski 写道:
On Thu, Feb 20, 2025 at 12:33 AM Dongyan Chen
wrote:
This patch support Qualcomm uC Xqccmp extension[1].
To enable GCC to recognize and process xqccmp extension correctly at compile
time.
[1]https://github.com/quic/riscv-unified-db/releases/tag/Xqccmp_extension-0.1.0
I am kinda of curious why you need this? Also is there a corresponding
binutils patch?
Please also CC myself (quic_apin...@quicinc.com) on all qualcomm
related GCC/GNU binutils patches.
Thanks,
Andrew Pinski
gcc/ChangeLog:
* common/config/riscv/riscv-common.cc: New extension.
* common/config/riscv/riscv-ext-bitmask.def (RISCV_EXT_BITMASK): Ditto.
* config/riscv/riscv.opt: Ditto.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/arch-45.c: New test.
---
gcc/common/config/riscv/riscv-common.cc | 6 ++
gcc/common/config/riscv/riscv-ext-bitmask.def | 1 +
gcc/config/riscv/riscv.opt| 5 +
gcc/testsuite/gcc.target/riscv/arch-45.c | 5 +
4 files changed, 17 insertions(+)
create mode 100644 gcc/testsuite/gcc.target/riscv/arch-45.c
diff --git a/gcc/common/config/riscv/riscv-common.cc
b/gcc/common/config/riscv/riscv-common.cc
index 5038f0eb959a..6fbdb5ed2316 100644
--- a/gcc/common/config/riscv/riscv-common.cc
+++ b/gcc/common/config/riscv/riscv-common.cc
@@ -229,6 +229,8 @@ static const riscv_implied_info_t riscv_implied_info[] =
{"xsfvcp", "zve32x"},
+ {"xqccmp", "zca"},
+
{NULL, NULL}
};
@@ -442,6 +444,8 @@ static const struct riscv_ext_version
riscv_ext_version_table[] =
{"xsfvqmaccdod",ISA_SPEC_CLASS_NONE, 1, 0},
{"xsfvfnrclipxfqf", ISA_SPEC_CLASS_NONE, 1, 0},
+ {"xqccmp", ISA_SPEC_CLASS_NONE, 0, 1},
+
/* Terminate the list. */
{NULL, ISA_SPEC_CLASS_NONE, 0, 0}
};
@@ -1778,6 +1782,8 @@ static const riscv_ext_flag_table_t
riscv_ext_flag_table[] =
RISCV_EXT_FLAG_ENTRY ("xsfvqmaccdod",x_riscv_sifive_subext,
MASK_XSFVQMACCDOD),
RISCV_EXT_FLAG_ENTRY ("xsfvfnrclipxfqf", x_riscv_sifive_subext,
MASK_XSFVFNRCLIPXFQF),
+ RISCV_EXT_FLAG_ENTRY ("xqccmp", x_riscv_qc_subext, MASK_XQCCMP),
+
{NULL, NULL, NULL, 0}
};
diff --git a/gcc/common/config/riscv/riscv-ext-bitmask.def
b/gcc/common/config/riscv/riscv-ext-bitmask.def
index 8b4e6d6349a7..c2809460d582 100644
--- a/gcc/common/config/riscv/riscv-ext-bitmask.def
+++ b/gcc/common/config/riscv/riscv-ext-bitmask.def
@@ -79,5 +79,6 @@ RISCV_EXT_BITMASK ("zcd", 1, 4)
RISCV_EXT_BITMASK ("zcf", 1, 5)
RISCV_EXT_BITMASK ("zcmop",1, 6)
RISCV_EXT_BITMASK ("zawrs",1, 7)
+RISCV_EXT_BITMASK ("xqccmp", 1, 8)
#undef RISCV_EXT_BITMASK
diff --git a/gcc/config/riscv/riscv.opt b/gcc/config/riscv/riscv.opt
index 7515c8ea13dd..61cc8258e323 100644
--- a/gcc/config/riscv/riscv.opt
+++ b/gcc/config/riscv/riscv.opt
@@ -535,6 +535,11 @@ Mask(XSFVQMACCDOD) Var(riscv_sifive_subext)
Mask(XSFVFNRCLIPXFQF) Var(riscv_sifive_subext)
+TargetVariable
+int riscv_qc_subext
+
+Mask(XQCCMP) Var(riscv_qc_subext)
+
TargetVariable
int riscv_fmv_priority = 0
diff --git a/gcc/testsuite/gcc.target/riscv/arch-45.c
b/gcc/testsuite/gcc.target/riscv/arch-45.c
new file mode 100644
index ..590d4f130325
--- /dev/null
+++ b/gcc/testsuite/gcc.target/riscv/arch-45.c
@@ -0,0 +1,5 @@
+/* { dg-do compile } */
+/* { dg-options "-march=rv64gc_xqccmp -mabi=lp64" } */
+int foo()
+{
+}
--
2.43.0
[PATCH] Append a newline in debug_edge
Append a newline in debug_edge so that we get
(gdb) call debug_edge (e)
edge (bb_9, bb_1)
(gdb)
instead of
(gdb) call debug_edge (e)
edge (bb_9, bb_1)(gdb)
* sese.cc (debug_edge): Append a newline.
--
H.J.
From 9d209112f37f681cd1e214a3412336476ca18527 Mon Sep 17 00:00:00 2001
From: "H.J. Lu"
Date: Fri, 21 Feb 2025 10:31:04 +0800
Subject: [PATCH] Append a newline in debug_edge
Append a newline in debug_edge so that we get
(gdb) call debug_edge (e)
edge (bb_9, bb_1)
(gdb)
instead of
(gdb) call debug_edge (e)
edge (bb_9, bb_1)(gdb)
* sese.cc (debug_edge): Append a newline.
Signed-off-by: H.J. Lu
---
gcc/sese.cc | 1 +
1 file changed, 1 insertion(+)
diff --git a/gcc/sese.cc b/gcc/sese.cc
index 02cfcf914ec..6076b03f359 100644
--- a/gcc/sese.cc
+++ b/gcc/sese.cc
@@ -489,6 +489,7 @@ DEBUG_FUNCTION void
debug_edge (const_edge e)
{
print_edge (stderr, e);
+ fprintf (stderr, "\n");
}
/* Pretty print sese S to STDERR. */
--
2.48.1
[PATCH] c++: too many errors with sneaky template [PR118516]
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >8 --
Since C++20 P0846, a name followed by a < can be treated as a template-name
even though name lookup did not find a template-name. That happens
in this test with "i < foo ()":
for (int id = 0; i < foo(); ++id);
and results in a raft of errors about non-constant foo(). The problem
is that the require_potential_constant_expression call in
cp_parser_template_argument emits errors even when we're parsing
tentatively. So we repeat the error when we're trying to parse
as a nested-name-specifier, type-name, etc.
Guarding the call with !cp_parser_uncommitted_to_tentative_parse_p would
mean that require_potential_constant_expression never gets called. But
we don't need the call at all as far as I can tell. Stuff like
template struct S { };
int foo () { return 4; }
void
g ()
{
S s;
}
gets diagnosed in convert_nontype_argument. In fact, with this patch,
we only emit "call to non-constexpr function" once. (That is, in C++17
only; C++14 uses a different path.)
PR c++/118516
gcc/cp/ChangeLog:
* parser.cc (cp_parser_template_argument): Don't call
require_potential_constant_expression.
gcc/testsuite/ChangeLog:
* g++.dg/cpp2a/fn-template11.C:
* g++.dg/template/fn-template1.C: New test.
* g++.dg/template/fn-template2.C: New test.
---
gcc/cp/parser.cc | 1 -
gcc/testsuite/g++.dg/cpp2a/fn-template11.C | 2 +-
gcc/testsuite/g++.dg/template/fn-template1.C | 12
gcc/testsuite/g++.dg/template/fn-template2.C | 9 +
4 files changed, 22 insertions(+), 2 deletions(-)
create mode 100644 gcc/testsuite/g++.dg/template/fn-template1.C
create mode 100644 gcc/testsuite/g++.dg/template/fn-template2.C
diff --git a/gcc/cp/parser.cc b/gcc/cp/parser.cc
index 0578aad1b1c..84b36a21767 100644
--- a/gcc/cp/parser.cc
+++ b/gcc/cp/parser.cc
@@ -20315,7 +20315,6 @@ cp_parser_template_argument (cp_parser* parser)
/* With C++17 generalized non-type template arguments we need to handle
lvalue constant expressions, too. */
argument = cp_parser_assignment_expression (parser);
- require_potential_constant_expression (argument);
}
if (!maybe_type_id)
diff --git a/gcc/testsuite/g++.dg/cpp2a/fn-template11.C
b/gcc/testsuite/g++.dg/cpp2a/fn-template11.C
index 1a6b6882900..ca25403f39b 100644
--- a/gcc/testsuite/g++.dg/cpp2a/fn-template11.C
+++ b/gcc/testsuite/g++.dg/cpp2a/fn-template11.C
@@ -7,5 +7,5 @@ int nonconst ();
int foo ()
{
return blah < // { dg-error "not declared" }
-nonconst (), nonconst (); // { dg-error "call to non-.constexpr. function"
}
+nonconst (), nonconst ();
}
diff --git a/gcc/testsuite/g++.dg/template/fn-template1.C
b/gcc/testsuite/g++.dg/template/fn-template1.C
new file mode 100644
index 000..14b98836880
--- /dev/null
+++ b/gcc/testsuite/g++.dg/template/fn-template1.C
@@ -0,0 +1,12 @@
+// PR c++/118516
+// { dg-do compile }
+// Like cpp2a/fn-template11.C but with blah declared.
+
+int nonconst ();
+
+int foo ()
+{
+ int blah = 20;
+ return blah <
+nonconst (), nonconst ();
+}
diff --git a/gcc/testsuite/g++.dg/template/fn-template2.C
b/gcc/testsuite/g++.dg/template/fn-template2.C
new file mode 100644
index 000..c7c31dd9b30
--- /dev/null
+++ b/gcc/testsuite/g++.dg/template/fn-template2.C
@@ -0,0 +1,9 @@
+// PR c++/118516
+// { dg-do compile }
+
+int foo();
+int main()
+{
+for (int id = 0; i < // { dg-error "not declared in this
scope" }
+foo(); ++id); // { dg-bogus "call to non-.constexpr." }
+}
base-commit: 4e9ee99647ebb9a7cab1497d78477f75d1157ac5
--
2.48.1
[PATCH] gimple-fold: Improve optimize_memcpy_to_memset to handle STRING_CST [PR78408]
While looking into PR 118947, I noticed that optimize_memcpy_to_memset didn't
handle STRING_CST which are also used for a memset of 0 but for char arrays.
This fixes that and improves optimize_memcpy_to_memset to handle that case.
This fixes part of PR 118947 but not the whole thing; we still need to skip over
vdefs in some cases.
Boostrapped and tested on x86_64-linux-gnu.
PR tree-optimization/78408
PR tree-optimization/118947
gcc/ChangeLog:
* gimple-fold.cc (optimize_memcpy_to_memset): Handle STRING_CST case
too.
gcc/testsuite/ChangeLog:
* gcc.dg/pr78408-3.c: New test.
Signed-off-by: Andrew Pinski
---
gcc/gimple-fold.cc | 17 +
gcc/testsuite/gcc.dg/pr78408-3.c | 14 ++
2 files changed, 31 insertions(+)
create mode 100644 gcc/testsuite/gcc.dg/pr78408-3.c
diff --git a/gcc/gimple-fold.cc b/gcc/gimple-fold.cc
index 0380c7af4c2..1a48778da5a 100644
--- a/gcc/gimple-fold.cc
+++ b/gcc/gimple-fold.cc
@@ -919,6 +919,23 @@ optimize_memcpy_to_memset (gimple_stmt_iterator *gsip,
tree dest, tree src, tree
poly_int64 offset, offset2;
tree val = integer_zero_node;
if (gimple_store_p (defstmt)
+ && gimple_assign_single_p (defstmt)
+ && TREE_CODE (gimple_assign_rhs1 (defstmt)) == STRING_CST
+ && !gimple_clobber_p (defstmt))
+{
+ tree str = gimple_assign_rhs1 (defstmt);
+ src2 = gimple_assign_lhs (defstmt);
+ /* The string must contain all null char's for now. */
+ for (int i = 0; i < TREE_STRING_LENGTH (str); i++)
+ {
+ if (TREE_STRING_POINTER (str)[i] != 0)
+ {
+ src2 = NULL_TREE;
+ break;
+ }
+ }
+}
+ else if (gimple_store_p (defstmt)
&& gimple_assign_single_p (defstmt)
&& TREE_CODE (gimple_assign_rhs1 (defstmt)) == CONSTRUCTOR
&& !gimple_clobber_p (defstmt))
diff --git a/gcc/testsuite/gcc.dg/pr78408-3.c b/gcc/testsuite/gcc.dg/pr78408-3.c
new file mode 100644
index 000..3de90d02392
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr78408-3.c
@@ -0,0 +1,14 @@
+/* PR tree-optimization/78408 */
+/* { dg-do compile { target size32plus } } */
+/* { dg-options "-O2 -fdump-tree-forwprop1-details" } */
+/* { dg-final { scan-tree-dump-times "after previous" 1 "forwprop1" } } */
+
+void* aaa();
+void* bbb()
+{
+void* ret = aaa();
+char buf[32] = {};
+__builtin_memcpy(ret, buf, 32);
+return ret;
+}
+
--
2.43.0
Re: The COBOL front end, version 3, now in 14 easy pieces (+NIST)
On Thu, 20 Feb 2025, James K. Lowden wrote:
> The Makefile fetches the NIST archive from our website. (We originally
> got it from NIST, but their site was reorganized last year. The file
> went missing, as apparently did my email to the webmaster.
> Technology!) The file might have 100 targets to run various bits. For
> gcc's purpose, only one matters: "make report".
The normal build and test process ("make" and "make check") must never
rely on any network connectivity. It's OK to have special maintainer-only
targets that connect to the network in order to update files in the source
tree, but normal running the testsuite must not do so; testsuite files
need to be checked in to be used by "make check".
--
Joseph S. Myers
josmy...@redhat.com
[COMMITED] invoke.texi: Fix typo in the file-cache-lines param
Pushed as obvious.
Filip Kastl
-- 8< --
file-cache-lines param was documented as file-cache-files. This fixes
the typo.
gcc/ChangeLog:
* doc/invoke.texi: Fix typo file-cache-files ->
file-cache-lines.
Signed-off-by: Filip Kastl
---
gcc/doc/invoke.texi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 0c7adc039b5..bad49a017cc 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -15787,7 +15787,7 @@ Max number of files in the file cache.
The file cache is used to print source lines in diagnostics and do some
source checks like @option{-Wmisleading-indentation}.
-@item file-cache-files
+@item file-cache-lines
Max number of lines to index into file cache. When 0 this is automatically
sized.
The file cache is used to print source lines in diagnostics and do some
source checks like @option{-Wmisleading-indentation}.
--
2.47.1
[PATCH] tree-optimization/118521 - bogus diagnostic from unreachable code
When SCCP does final value replacement we end up with unfolded IL like
__result_274 = _150 + 1;
...
__new_finish_106 = __result_274 + 3; <-- from SCCP
_115 = _150 + 4;
if (__new_finish_106 != _115)
this does only get rectified by the next full folding which happens
in forwprop4 which is after the strlen pass emitting the unwanted
diagnostic. The following mitigates this case in a similar way as
r15-7472 did for PR118817 - by ensuring we have the IL folded.
This is done by simply folding all immediate uses of the former
PHI def that SCCP replaces. All other more general approaches have
too much fallout at this point.
Bootstrapped and tested on x86_64-unknown-linux-gnu, OK?
Thanks,
Richard.
PR tree-optimization/118521
* tree-scalar-evolution.cc (final_value_replacement_loop):
Fold uses of the replaced PHI def.
* g++.dg/torture/pr118521.C: New testcase.
---
gcc/testsuite/g++.dg/torture/pr118521.C | 14 ++
gcc/tree-scalar-evolution.cc| 18 ++
2 files changed, 32 insertions(+)
create mode 100644 gcc/testsuite/g++.dg/torture/pr118521.C
diff --git a/gcc/testsuite/g++.dg/torture/pr118521.C
b/gcc/testsuite/g++.dg/torture/pr118521.C
new file mode 100644
index 000..1a66aca0e8d
--- /dev/null
+++ b/gcc/testsuite/g++.dg/torture/pr118521.C
@@ -0,0 +1,14 @@
+// { dg-do compile }
+// { dg-additional-options "-Wall" }
+
+#include // dg-bogus new_allocator.h:191 warning: writing 1 byte into
a region of size 0
+
+void bar(std::vector);
+
+void foo()
+{
+ std::vector v{1, 2};
+ v.insert(v.end(), 2, 0);
+ v.push_back(1);
+ bar(v);
+}
diff --git a/gcc/tree-scalar-evolution.cc b/gcc/tree-scalar-evolution.cc
index 0ba85917d41..4ca08751a0d 100644
--- a/gcc/tree-scalar-evolution.cc
+++ b/gcc/tree-scalar-evolution.cc
@@ -284,6 +284,7 @@ along with GCC; see the file COPYING3. If not see
#include "tree-into-ssa.h"
#include "builtins.h"
#include "case-cfn-macros.h"
+#include "tree-eh.h"
static tree analyze_scalar_evolution_1 (class loop *, tree);
static tree analyze_scalar_evolution_for_address_of (class loop *loop,
@@ -3947,6 +3948,23 @@ final_value_replacement_loop (class loop *loop)
print_gimple_stmt (dump_file, SSA_NAME_DEF_STMT (rslt), 0);
fprintf (dump_file, "\n");
}
+
+ /* Re-fold immediate uses of the replaced def, but avoid
+CFG manipulations from this function. For now only do
+a single-level re-folding, not re-folding uses of
+folded uses. */
+ if (! SSA_NAME_OCCURS_IN_ABNORMAL_PHI (rslt))
+ {
+ gimple *use_stmt;
+ imm_use_iterator imm_iter;
+ FOR_EACH_IMM_USE_STMT (use_stmt, imm_iter, rslt)
+ {
+ gimple_stmt_iterator gsi = gsi_for_stmt (use_stmt);
+ if (!stmt_can_throw_internal (cfun, use_stmt)
+ && fold_stmt (&gsi, follow_all_ssa_edges))
+ update_stmt (gsi_stmt (gsi));
+ }
+ }
}
return any;
--
2.43.0
Re: [PATCH][v3] tree-optimization/86270 - improve SSA coalescing for loop exit test
On 2/20/25 12:38 AM, Richard Biener wrote: On Wed, 19 Feb 2025, Jeff Law wrote: On 2/15/25 6:36 AM, Richard Biener wrote: The PR indicates a very specific issue with regard to SSA coalescing failures because there's a pre IV increment loop exit test. While IVOPTs created the desired IL we later simplify the exit test into the undesirable form again. The following fixes this up during RTL expansion where we try to improve coalescing of IVs. That seems easier that trying to avoid the simplification with some weird heuristics (it could also have been written this way). Ugh. I think we've got hacks in multiple places to deal with similar issues. One could ask the question if one or more of those could be removed, though clearly that's gcc-16 material. I think they are all in this place (and rightfully so). If you remember others elsewhere I'd like to know ;) There's "simple_iv_increment_p" and its uses in DOM. But I think that was inherited from somewhere else, though perhaps those other cases have since been removed. Thanks, pushed (clearing through old regressins assigned to me...) I'm going through them as well (as you probably guessed). Though I'm not terribly selective. Whatever looks like it might be solvable. jeff
Re: [PATCH] tree-optimization/118521 - bogus diagnostic from unreachable code
On 2/20/25 5:47 AM, Richard Biener wrote:
When SCCP does final value replacement we end up with unfolded IL like
__result_274 = _150 + 1;
...
__new_finish_106 = __result_274 + 3; <-- from SCCP
_115 = _150 + 4;
if (__new_finish_106 != _115)
this does only get rectified by the next full folding which happens
in forwprop4 which is after the strlen pass emitting the unwanted
diagnostic. The following mitigates this case in a similar way as
r15-7472 did for PR118817 - by ensuring we have the IL folded.
This is done by simply folding all immediate uses of the former
PHI def that SCCP replaces. All other more general approaches have
too much fallout at this point.
Bootstrapped and tested on x86_64-unknown-linux-gnu, OK?
Thanks,
Richard.
PR tree-optimization/118521
* tree-scalar-evolution.cc (final_value_replacement_loop):
Fold uses of the replaced PHI def.
* g++.dg/torture/pr118521.C: New testcase.
Guess I should have included "have scev clean up its own mess" as an
option in the BZ :-)
I dismissed pass reordering without even investigating. I'm always
skeptical of that as the solution.
I'd pondered how to make this work in a DOM context and even tried
something akin to what you're doing (though just in the debugger and I
think I used the single use edge callback which obviously didn't work).
Point being I think that's probably the best solution we're going to
see. LGTM.
I hesitate to even bring it up (but we need to). Do we want to consider
the state/future of these warnings for gcc-16? Is this stuff
salvageable? I think there's utility in these warnings, but they're
clearly a pain point across multiple contexts.
jeff
---
gcc/testsuite/g++.dg/torture/pr118521.C | 14 ++
gcc/tree-scalar-evolution.cc| 18 ++
2 files changed, 32 insertions(+)
create mode 100644 gcc/testsuite/g++.dg/torture/pr118521.C
diff --git a/gcc/testsuite/g++.dg/torture/pr118521.C
b/gcc/testsuite/g++.dg/torture/pr118521.C
new file mode 100644
index 000..1a66aca0e8d
--- /dev/null
+++ b/gcc/testsuite/g++.dg/torture/pr118521.C
@@ -0,0 +1,14 @@
+// { dg-do compile }
+// { dg-additional-options "-Wall" }
+
+#include // dg-bogus new_allocator.h:191 warning: writing 1 byte into
a region of size 0
+
+void bar(std::vector);
+
+void foo()
+{
+ std::vector v{1, 2};
+ v.insert(v.end(), 2, 0);
+ v.push_back(1);
+ bar(v);
+}
diff --git a/gcc/tree-scalar-evolution.cc b/gcc/tree-scalar-evolution.cc
index 0ba85917d41..4ca08751a0d 100644
--- a/gcc/tree-scalar-evolution.cc
+++ b/gcc/tree-scalar-evolution.cc
@@ -284,6 +284,7 @@ along with GCC; see the file COPYING3. If not see
#include "tree-into-ssa.h"
#include "builtins.h"
#include "case-cfn-macros.h"
+#include "tree-eh.h"
static tree analyze_scalar_evolution_1 (class loop *, tree);
static tree analyze_scalar_evolution_for_address_of (class loop *loop,
@@ -3947,6 +3948,23 @@ final_value_replacement_loop (class loop *loop)
print_gimple_stmt (dump_file, SSA_NAME_DEF_STMT (rslt), 0);
fprintf (dump_file, "\n");
}
+
+ /* Re-fold immediate uses of the replaced def, but avoid
+CFG manipulations from this function. For now only do
+a single-level re-folding, not re-folding uses of
+folded uses. */
+ if (! SSA_NAME_OCCURS_IN_ABNORMAL_PHI (rslt))
+ {
+ gimple *use_stmt;
+ imm_use_iterator imm_iter;
+ FOR_EACH_IMM_USE_STMT (use_stmt, imm_iter, rslt)
+ {
+ gimple_stmt_iterator gsi = gsi_for_stmt (use_stmt);
+ if (!stmt_can_throw_internal (cfun, use_stmt)
+ && fold_stmt (&gsi, follow_all_ssa_edges))
+ update_stmt (gsi_stmt (gsi));
+ }
+ }
}
return any;
Re: [PATCH v2] ira: Add a target hook for callee-saved register cost scale
> On Wed, Feb 19, 2025 at 9:06 PM Jan Hubicka wrote: > > > > Hi, > > this is a variant of a hook I benchmarked on cpu2016 with -Ofast -flto > > and -O2 -flto. For non -Os and no Windows ABI should be pratically the > > same as your variant that was simply returning mem_cost - 2. > > > I've tested O2/(Ofast march=native) with SPEC2017 on SPR, mostly > neutral (small improvement on povray). So I got ryzen3 runs with -O2, -O3 and -fno-ipa-ra. Overall differences are quite small, but I think it is expected. Here is what I get with -O2: --- --- - ---- - - 500.perlbench_r 1188 8.46 S 1183 8.69 S 500.perlbench_r 1187 8.52 * 1182 8.75 * 500.perlbench_r 1186 8.56 S 1182 8.75 S 502.gcc_r 1139 10.2 S 1137 10.3 * 502.gcc_r 1139 10.2 S 1137 10.4 S 502.gcc_r 1139 10.2 * 1137 10.3 S 505.mcf_r 1187 8.66 * 1188 8.61 S 505.mcf_r 1186 8.70 S 1187 8.66 * 505.mcf_r 1188 8.62 S 1187 8.66 S 520.omnetpp_r 1213 6.15 * 1207 6.32 * 520.omnetpp_r 1212 6.18 S 1206 6.37 S 520.omnetpp_r 1219 5.99 S 1215 6.11 S 523.xalancbmk_r 1 --CE 1 -- CE 525.x264_r1135 13.0 S 1135 12.9 * 525.x264_r1135 13.0 * 1135 12.9 S 525.x264_r1135 13.0 S 1135 12.9 S 531.deepsjeng_r 1167 6.86 * 1167 6.85 S 531.deepsjeng_r 1167 6.86 S 1168 6.84 S 531.deepsjeng_r 1167 6.86 S 1167 6.85 * 541.leela_r 1296 5.60 S 1292 5.67 * 541.leela_r 1293 5.65 S 1293 5.65 S 541.leela_r 1296 5.60 * 1292 5.67 S 548.exchange2_r 1208 12.6 S 1208 12.6 S 548.exchange2_r 1208 12.6 * 1208 12.6 S 548.exchange2_r 1208 12.6 S 1208 12.6 * 557.xz_r 1194 5.58 S 1193 5.58 S 557.xz_r 1192 5.62 S 1193 5.60 S 557.xz_r 1193 5.60 * 1193 5.59 * = 500.perlbench_r 1187 8.52 * 1182 8.75 * 502.gcc_r 1139 10.2 * 1137 10.3 * 505.mcf_r 1187 8.66 * 1187 8.66 * 520.omnetpp_r 1213 6.15 * 1207 6.32 * 523.xalancbmk_r NR NR 525.x264_r1135 13.0 * 1135 12.9 * 531.deepsjeng_r 1167 6.86 * 1167 6.85 * 541.leela_r 1296 5.60 * 1292 5.67 * 548.exchange2_r 1208 12.6 * 1208 12.6 * 557.xz_r 1193 5.60 * 1193 5.59 * Est. SPECrate2017_int_base 8.17 Est. SPECrate2017_int_peak 8.24 Perlbench seems to improve consistently without LTO (bot -O2, -O3 and -O2 -fno-ipa-ra and I think it may be just a luck with code layout gcc is quie concistent in all settings. Overall it seems consistent little win. For fp tests, I see only off-noise povray differences and only in -Ofast and -Ofast -flto. Comparing code sizes at -O2: 500.perlbench_r/run/run_base_refrate_regalloc-m64./perlbench_r_base.regalloc-m64 16999871731648 101.86 502.gcc_r/run/run_base_refrate_regalloc-m64./cpugcc_r_base.regalloc-m64 70720317226911 102.19 503.bwaves_r/run/run_base_refrate_regalloc-m64./bwaves_r_base.regalloc-m64 41327 41327 100.00 505.mcf_r/run/run_base_refrate_regalloc-m64./mcf_r_base.regalloc-m64 17023 17023 100.00 507.cactuBSSN_r/run/run_base_refrate_regalloc-m64./cactusBSSN_r_base.regalloc-m64 34323263464950 100.95 508.namd_r/run/run_base_refrate_regalloc-m64./namd_r_base.regalloc-
[PATCH v2] rs6000: Adding missed ISA 3.0 atomic memory operation instructions.
Hi All,
The following patch has been bootstrapped and regtested on powerpc64le-linux.
Changes to amo.h include the addition of the following load atomic operations:
Compare and Swap Not Equal, Fetch and Increment Bounded, Fetch and Increment
Equal, and Fetch and Decrement Bounded. Additionally, Store Twin is added for
store atomic operations.
2025-02-20 Peter Bergner
gcc/:
* config/rs6000/amo.h: Add missing atomic memory operations.
* doc/extend.texi (PowerPC Atomic Memory Operation Functions):
Document new functions.
gcc/testsuite/:
* gcc.target/powerpc/amo3.c: New test.
* gcc.target/powerpc/amo4.c: Likewise.
* gcc.target/powerpc/amo5.c: Likewise.
* gcc.target/powerpc/amo6.c: Likewise.
* gcc.target/powerpc/amo7.c: Likewise.
Co-authored-by: Jeevitha Palanisamy
diff --git a/gcc/config/rs6000/amo.h b/gcc/config/rs6000/amo.h
index 25ab1c7b4c4..10960208d31 100644
--- a/gcc/config/rs6000/amo.h
+++ b/gcc/config/rs6000/amo.h
@@ -71,6 +71,64 @@ NAME (TYPE *_PTR, TYPE _VALUE)
\
return _RET; \
}
+/* Implementation of the LWAT/LDAT operations that take two input registers
+ and modify one word or double-word of memory and return the value that was
+ previously in the memory location. The destination and two source
+ registers are encoded with only one register number, so we need three
+ consecutive GPR registers and there is no C/C++ type that will give
+ us that, so we have to use register asm variables to achieve that.
+
+ The LWAT/LDAT opcode requires the address to be a single register,
+ and that points to a suitably aligned memory location. Asm volatile
+ is used to prevent the optimizer from moving the operation. */
+
+#define _AMO_LD_CMPSWP(NAME, TYPE, OPCODE, FC) \
+static __inline__ TYPE \
+NAME (TYPE *_PTR, TYPE _COND, TYPE _VALUE) \
+{ \
+ register TYPE _ret asm ("r8"); \
+ register TYPE _cond asm ("r9") = _COND; \
+ register TYPE _value asm ("r10") = _VALUE; \
+ __asm__ __volatile__ (OPCODE " %[ret],%P[addr],%[code]" \
+ : [addr] "+Q" (_PTR[0]), [ret] "=r" (_ret) \
+ : "r" (_cond), "r" (_value), [code] "n" (FC)); \
+ return _ret; \
+}
+
+/* Implementation of the LWAT/LDAT fetch and increment operations.
+
+ The LWAT/LDAT opcode requires the address to be a single register that
+ points to a suitably aligned memory location. Asm volatile is used to
+ prevent the optimizer from moving the operation. */
+
+#define _AMO_LD_INCREMENT(NAME, TYPE, OPCODE, FC) \
+static __inline__ TYPE \
+NAME (TYPE *_PTR) \
+{ \
+ TYPE _RET; \
+ __asm__ volatile (OPCODE " %[ret],%P[addr],%[code]\n"
\
+ : [addr] "+Q" (_PTR[0]), [ret] "=r" (_RET) \
+ : "Q" (*(TYPE (*)[2]) _PTR), [code] "n" (FC)); \
+ return _RET; \
+}
+
+/* Implementation of the LWAT/LDAT fetch and decrement operations.
+
+ The LWAT/LDAT opcode requires the address to be a single register that
+ points to a suitably aligned memory location. Asm volatile is used to
+ prevent the optimizer from moving the operation. */
+
+#define _AMO_LD_DECREMENT(NAME, TYPE, OPCODE, FC) \
+static __inline__ TYPE \
+NAME (TYPE *_PTR) \
+{ \
+ TYPE _RET; \
+ __asm__ volatile (OPCODE " %[ret],%P[addr],%[code]\n"
\
+ : [addr] "+Q" (_PTR[1]), [ret] "=r" (_RET) \
+ : "Q" (*(TYPE (*)[2]) (_PTR)), [code] "n" (FC));\
+ return _RET; \
+}
+
_AMO_LD_SIMPLE (amo_lwat_add, uint32_t, "lwat", _AMO_LD_ADD)
_AMO_LD_SIMPLE (amo_lwat_xor, uint32_t, "lwat", _AMO_LD_XOR)
_AMO_LD_SIMPLE (amo_lwat_ior, uint32_t, "lwat", _AMO_LD_IOR)
@@ -78,11 +136,19 @@ _AMO_LD_SIMPLE (amo_lwat_and, uint32_t, "lwat",
_AMO_LD_AND)
_AMO_LD_SIMPLE (amo_lwat_umax, uint32_t, "lwat", _AMO_LD_UMAX)
_AMO_LD_SIMPLE (amo_lwat_umin, uint32_t, "lwat", _AMO_LD_UMIN)
_AMO_LD_S
Re: [PATCH][RFC][PR tree-optimization/117829] Bogus Warray-bounds warning
On 2/20/25 12:52 AM, Richard Biener wrote:
On Wed, Feb 19, 2025 at 11:29 PM Jeff Law wrote:
An interesting little bug. We're just emitting what appears to me to be
a silly warning.
By the time the array-bounds checker runs we have this statement in the IL:
MEM[(int *)_42 + -4B] ={v} {CLOBBER(eob)};
Naturally that looks like an out of bounds array index and we warn.
Which seems dubious at best. My first thought is we shouldn't be trying
to analyze a gimple clobber for out of bounds array indexes.
OTOH all clobbers are inserted for actual allocated storage (even if not
accessed).
True, but the clobbers seem like the wrong object to be checking for OOB
access. We should be checking actual references.
But like most things in GCC, it's never that simple.
It looks like we're relying on warning for that case for
Warray-bounds-20.C.
[local count: 1073741824]:
MEM[(struct D1 *)&a + 1B] ={v} {CLOBBER(bob)};
MEM[(struct B *)&a + 1B]._vptr.B = &MEM [(void *)&_ZTC2D10_1B +
24B];
MEM[(struct A *)&a + 9B]._vptr.A = &MEM [(void *)&_ZTC2D10_1B +
64B];
C::C (&MEM[(struct D1 *)&a + 1B].D.3003, &MEM [(void
*)&_ZTT2D1 + 48B]);
My sense is that this test is passing more by accident than by design
and that the warning really should be triggered by one of the other
statements.
And it isn't? So A and B are smaller than D1 and only D1 overruns?
But it's not actually stored to?
The overruns are completely missed AFAICT. The warning we get today is
from the clobber statement.
Martin just got it wrong here AFAICT. I did go back and
check the original BZ (pr98266). It's unaffected as it doesn't have the
gimple clobbers.
I'll note the unwanted diagnostic is on a EOB (end-of-object) while the
wanted is on a BOB (begin-of-object). Both are not begin/end-of-storage.
Now find a convincing argument that any of those are not worth diagnosing...
I think diagnosing overruns is good, but the clobber statement isn't the
right thing to be analyzing for an overrun.
Jeff
Re: [PATCH] tree-optimization/118521 - bogus diagnostic from unreachable code
On Thu, 20 Feb 2025, Jeff Law wrote:
>
>
> On 2/20/25 5:47 AM, Richard Biener wrote:
> > When SCCP does final value replacement we end up with unfolded IL like
> >
> > __result_274 = _150 + 1;
> > ...
> > __new_finish_106 = __result_274 + 3; <-- from SCCP
> > _115 = _150 + 4;
> > if (__new_finish_106 != _115)
> >
> > this does only get rectified by the next full folding which happens
> > in forwprop4 which is after the strlen pass emitting the unwanted
> > diagnostic. The following mitigates this case in a similar way as
> > r15-7472 did for PR118817 - by ensuring we have the IL folded.
> > This is done by simply folding all immediate uses of the former
> > PHI def that SCCP replaces. All other more general approaches have
> > too much fallout at this point.
> >
> > Bootstrapped and tested on x86_64-unknown-linux-gnu, OK?
> >
> > Thanks,
> > Richard.
> >
> > PR tree-optimization/118521
> > * tree-scalar-evolution.cc (final_value_replacement_loop):
> > Fold uses of the replaced PHI def.
> >
> > * g++.dg/torture/pr118521.C: New testcase.
> Guess I should have included "have scev clean up its own mess" as an option in
> the BZ :-)
>
> I dismissed pass reordering without even investigating. I'm always skeptical
> of that as the solution.
>
> I'd pondered how to make this work in a DOM context and even tried something
> akin to what you're doing (though just in the debugger and I think I used the
> single use edge callback which obviously didn't work).
>
> Point being I think that's probably the best solution we're going to see.
> LGTM.
>
> I hesitate to even bring it up (but we need to). Do we want to consider the
> state/future of these warnings for gcc-16? Is this stuff salvageable? I
> think there's utility in these warnings, but they're clearly a pain point
> across multiple contexts.
What I'd like to see is less diagnostics emitted from random passes
but instead, like we did with the array-bounds pass, do it separately.
And then have those passes not be randomly spread but in one or two
places.
But in general as you say the "advancd IL diagnostics" face the
same issue as static analyzers - we usually lack knowledge of all
pre-conditions to avoid false positives and there's no nice way
to annotate source with those in a way not affecting code generation
(because we warn off the IL, so those need to be in the IL itself).
The analyzer should have the very same issue here. There's Qings
patch to improve the diagnostic to help users write missing
pre-conditions, so that's a thing to look at.
Other than that - I don't have a good solution.
Richard.
> jeff
>
>
>
>
> > ---
> > gcc/testsuite/g++.dg/torture/pr118521.C | 14 ++
> > gcc/tree-scalar-evolution.cc| 18 ++
> > 2 files changed, 32 insertions(+)
> > create mode 100644 gcc/testsuite/g++.dg/torture/pr118521.C
> >
> > diff --git a/gcc/testsuite/g++.dg/torture/pr118521.C
> > b/gcc/testsuite/g++.dg/torture/pr118521.C
> > new file mode 100644
> > index 000..1a66aca0e8d
> > --- /dev/null
> > +++ b/gcc/testsuite/g++.dg/torture/pr118521.C
> > @@ -0,0 +1,14 @@
> > +// { dg-do compile }
> > +// { dg-additional-options "-Wall" }
> > +
> > +#include // dg-bogus new_allocator.h:191 warning: writing 1 byte
> > into a region of size 0
> > +
> > +void bar(std::vector);
> > +
> > +void foo()
> > +{
> > + std::vector v{1, 2};
> > + v.insert(v.end(), 2, 0);
> > + v.push_back(1);
> > + bar(v);
> > +}
> > diff --git a/gcc/tree-scalar-evolution.cc b/gcc/tree-scalar-evolution.cc
> > index 0ba85917d41..4ca08751a0d 100644
> > --- a/gcc/tree-scalar-evolution.cc
> > +++ b/gcc/tree-scalar-evolution.cc
> > @@ -284,6 +284,7 @@ along with GCC; see the file COPYING3. If not see
> > #include "tree-into-ssa.h"
> > #include "builtins.h"
> > #include "case-cfn-macros.h"
> > +#include "tree-eh.h"
> >
> > static tree analyze_scalar_evolution_1 (class loop *, tree);
> > static tree analyze_scalar_evolution_for_address_of (class loop *loop,
> > @@ -3947,6 +3948,23 @@ final_value_replacement_loop (class loop *loop)
> > print_gimple_stmt (dump_file, SSA_NAME_DEF_STMT (rslt), 0);
> > fprintf (dump_file, "\n");
> > }
> > +
> > + /* Re-fold immediate uses of the replaced def, but avoid
> > +CFG manipulations from this function. For now only do
> > +a single-level re-folding, not re-folding uses of
> > +folded uses. */
> > + if (! SSA_NAME_OCCURS_IN_ABNORMAL_PHI (rslt))
> > + {
> > + gimple *use_stmt;
> > + imm_use_iterator imm_iter;
> > + FOR_EACH_IMM_USE_STMT (use_stmt, imm_iter, rslt)
> > + {
> > + gimple_stmt_iterator gsi = gsi_for_stmt (use_stmt);
> > + if (!stmt_can_throw_internal (cfun, use_stmt)
> > + && fold_stmt (&gsi, follow_all_ssa_edges))
> > + update_stmt (gsi_stmt (gsi));
> > + }
> > + }
> > }
> >
> > return any;
>
>
--
Richard Biener
SUSE Software Solutions Ge
Re: [PATCH v2] ira: Add a target hook for callee-saved register cost scale
Jan Hubicka writes: >> On Wed, Feb 19, 2025 at 9:06 PM Jan Hubicka wrote: >> > >> > Hi, >> > this is a variant of a hook I benchmarked on cpu2016 with -Ofast -flto >> > and -O2 -flto. For non -Os and no Windows ABI should be pratically the >> > same as your variant that was simply returning mem_cost - 2. >> > >> I've tested O2/(Ofast march=native) with SPEC2017 on SPR, mostly >> neutral (small improvement on povray). > > So I got ryzen3 runs with -O2, -O3 and -fno-ipa-ra. > > Overall differences are quite small, but I think it is expected. Here is > what I get with -O2: > --- --- - ---- - - > 500.perlbench_r 1188 8.46 S 1183 > 8.69 S > 500.perlbench_r 1187 8.52 * 1182 > 8.75 * > 500.perlbench_r 1186 8.56 S 1182 > 8.75 S > 502.gcc_r 1139 10.2 S 1137 10.3 > * > 502.gcc_r 1139 10.2 S 1137 10.4 > S > 502.gcc_r 1139 10.2 * 1137 10.3 > S > 505.mcf_r 1187 8.66 * 1188 > 8.61 S > 505.mcf_r 1186 8.70 S 1187 > 8.66 * > 505.mcf_r 1188 8.62 S 1187 > 8.66 S > 520.omnetpp_r 1213 6.15 * 1207 > 6.32 * > 520.omnetpp_r 1212 6.18 S 1206 > 6.37 S > 520.omnetpp_r 1219 5.99 S 1215 > 6.11 S > 523.xalancbmk_r 1 --CE 1 -- > CE > 525.x264_r1135 13.0 S 1135 12.9 > * > 525.x264_r1135 13.0 * 1135 12.9 > S > 525.x264_r1135 13.0 S 1135 12.9 > S > 531.deepsjeng_r 1167 6.86 * 1167 > 6.85 S > 531.deepsjeng_r 1167 6.86 S 1168 > 6.84 S > 531.deepsjeng_r 1167 6.86 S 1167 > 6.85 * > 541.leela_r 1296 5.60 S 1292 > 5.67 * > 541.leela_r 1293 5.65 S 1293 > 5.65 S > 541.leela_r 1296 5.60 * 1292 > 5.67 S > 548.exchange2_r 1208 12.6 S 1208 12.6 > S > 548.exchange2_r 1208 12.6 * 1208 12.6 > S > 548.exchange2_r 1208 12.6 S 1208 12.6 > * > 557.xz_r 1194 5.58 S 1193 > 5.58 S > 557.xz_r 1192 5.62 S 1193 > 5.60 S > 557.xz_r 1193 5.60 * 1193 > 5.59 * > = > 500.perlbench_r 1187 8.52 * 1182 > 8.75 * > 502.gcc_r 1139 10.2 * 1137 10.3 > * > 505.mcf_r 1187 8.66 * 1187 > 8.66 * > 520.omnetpp_r 1213 6.15 * 1207 > 6.32 * > 523.xalancbmk_r NR > NR > 525.x264_r1135 13.0 * 1135 12.9 > * > 531.deepsjeng_r 1167 6.86 * 1167 > 6.85 * > 541.leela_r 1296 5.60 * 1292 > 5.67 * > 548.exchange2_r 1208 12.6 * 1208 12.6 > * > 557.xz_r 1193 5.60 * 1193 > 5.59 * > Est. SPECrate2017_int_base 8.17 > Est. SPECrate2017_int_peak 8.24 > > Perlbench seems to improve consistently without LTO (bot -O2, -O3 and > -O2 -fno-ipa-ra and I think it may be just a luck with code layout > gcc is quie concistent in all settings. Overall it seems consistent > little win. For fp tests, I see only off-noise povray differences and only in > -Ofast and -Ofast -flto. > > Comparing code sizes at -O2: > > 500.perlbench_r/run/run_base_refrate_regalloc-m64./perlbench_r_base.regalloc-m64 > 16999871731648 101.86 > 502.gcc_r/run/run_base_refrate_regalloc-m64./cpugcc_r_base.regalloc-m64 > 70720317226911 102.19 > 503.bwaves_r/run/run_base_refrate_regalloc-m64./bwaves_r_base.regalloc-m64 > 41327 41327 100.00 > 505.mcf_r/run/run_base_refrate_regalloc-m64./mcf_r_base.regalloc-m64 >
[PATCH] arm: Fix signedness of some vld1q intrinsic parameters for ARM NEON
vld1q_s8_x3, vld1q_s16_x3, vld1q_s8_x4 and vld1q_s16_x4 were expecting
pointers to unsigned integers. These parameters should be pointers to
signed integers.
gcc/ChangeLog:
* config/arm/arm_neon.h (vld1q_s8_x3): Use int8_t instead of
uint16_t.
(vld1q_s16_x3): Use int16_t instead of uint16_t.
(vld1q_s8_x4): Likewise.
(vld1q_s16_x4): Likewise.
Signed-off-by: Hannes Braun
---
gcc/config/arm/arm_neon.h | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/gcc/config/arm/arm_neon.h b/gcc/config/arm/arm_neon.h
index 5b1c55c8d9f..578ada88fa6 100644
--- a/gcc/config/arm/arm_neon.h
+++ b/gcc/config/arm/arm_neon.h
@@ -10854,7 +10854,7 @@ vld1q_s64_x2 (const int64_t * __a)
__extension__ extern __inline int8x16x3_t
__attribute__ ((__always_inline__, __gnu_inline__, __artificial__))
-vld1q_s8_x3 (const uint8_t * __a)
+vld1q_s8_x3 (const int8_t * __a)
{
union { int8x16x3_t __i; __builtin_neon_ci __o; } __rv;
__rv.__o = __builtin_neon_vld1q_x3v16qi ((const __builtin_neon_qi *) __a);
@@ -10863,7 +10863,7 @@ vld1q_s8_x3 (const uint8_t * __a)
__extension__ extern __inline int16x8x3_t
__attribute__ ((__always_inline__, __gnu_inline__, __artificial__))
-vld1q_s16_x3 (const uint16_t * __a)
+vld1q_s16_x3 (const int16_t * __a)
{
union { int16x8x3_t __i; __builtin_neon_ci __o; } __rv;
__rv.__o = __builtin_neon_vld1q_x3v8hi ((const __builtin_neon_hi *) __a);
@@ -10890,7 +10890,7 @@ vld1q_s64_x3 (const int64_t * __a)
__extension__ extern __inline int8x16x4_t
__attribute__ ((__always_inline__, __gnu_inline__, __artificial__))
-vld1q_s8_x4 (const uint8_t * __a)
+vld1q_s8_x4 (const int8_t * __a)
{
union { int8x16x4_t __i; __builtin_neon_xi __o; } __rv;
__rv.__o = __builtin_neon_vld1q_x4v16qi ((const __builtin_neon_qi *) __a);
@@ -10899,7 +10899,7 @@ vld1q_s8_x4 (const uint8_t * __a)
__extension__ extern __inline int16x8x4_t
__attribute__ ((__always_inline__, __gnu_inline__, __artificial__))
-vld1q_s16_x4 (const uint16_t * __a)
+vld1q_s16_x4 (const int16_t * __a)
{
union { int16x8x4_t __i; __builtin_neon_xi __o; } __rv;
__rv.__o = __builtin_neon_vld1q_x4v8hi ((const __builtin_neon_hi *) __a);
--
2.48.1
Re: [PATCH 1/2] libstdc++: Fix invalid signed arguments to functions
On Sat, 15 Feb 2025, Jonathan Wakely wrote:
> These should have been unsigned, but the static assertions are only in
> the public std::bit_ceil and std::bit_width functions, not the internal
> __bit_ceil and __bit_width ones.
>
> libstdc++-v3/ChangeLog:
>
> * include/experimental/bits/simd.h (__find_next_valid_abi): Cast
> __bit_ceil argument to unsigned.
> * src/c++17/floating_from_chars.cc (__floating_from_chars_hex):
> Cast __bit_ceil argument to unsigned.
> * src/c++17/memory_resource.cc (big_block): Cast __bit_width
> argument to unsigned.
> ---
>
> Tested x86_64-linux.
>
> libstdc++-v3/include/experimental/bits/simd.h | 2 +-
> libstdc++-v3/src/c++17/floating_from_chars.cc | 5 +++--
> libstdc++-v3/src/c++17/memory_resource.cc | 3 ++-
> 3 files changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/libstdc++-v3/include/experimental/bits/simd.h
> b/libstdc++-v3/include/experimental/bits/simd.h
> index 500c1781ae54..f0cb101aaa82 100644
> --- a/libstdc++-v3/include/experimental/bits/simd.h
> +++ b/libstdc++-v3/include/experimental/bits/simd.h
> @@ -4634,7 +4634,7 @@ template class _Abi, int _Bytes,
> typename _Tp>
> static constexpr auto
> _S_choose()
> {
> - constexpr int _NextBytes = std::__bit_ceil(_Bytes) / 2;
> + constexpr int _NextBytes = std::__bit_ceil((unsigned)_Bytes) / 2;
>using _NextAbi = _Abi<_NextBytes>;
>if constexpr (_NextBytes < sizeof(_Tp) * 2) // break recursion
> return _Abi<_Bytes>();
> diff --git a/libstdc++-v3/src/c++17/floating_from_chars.cc
> b/libstdc++-v3/src/c++17/floating_from_chars.cc
> index f8b1e23937d2..d48f1c0d4545 100644
> --- a/libstdc++-v3/src/c++17/floating_from_chars.cc
> +++ b/libstdc++-v3/src/c++17/floating_from_chars.cc
> @@ -1102,8 +1102,9 @@ namespace
>{
> // If the leading hexit is not '1', shift MANTISSA to make it so.
> // This normalizes input like "4.08p0" into "1.02p2".
> - const int leading_hexit = mantissa >> mantissa_bits;
> - const int leading_hexit_width = __bit_width(leading_hexit); // FIXME:
> optimize?
> + const unsigned leading_hexit = mantissa >> mantissa_bits;
> + const int leading_hexit_width
> + = __bit_width((unsigned)leading_hexit); // FIXME: optimize?
Not a big deal, but isn't this cast redundant if we've defined
leading_hexit as unsigned?
> __glibcxx_assert(leading_hexit_width >= 1 && leading_hexit_width <= 4);
> shift_mantissa(leading_hexit_width - 1);
> // After this adjustment, we can assume the leading hexit is '1'.
> diff --git a/libstdc++-v3/src/c++17/memory_resource.cc
> b/libstdc++-v3/src/c++17/memory_resource.cc
> index 2b6bfbd4dd33..893736bcf5dd 100644
> --- a/libstdc++-v3/src/c++17/memory_resource.cc
> +++ b/libstdc++-v3/src/c++17/memory_resource.cc
> @@ -588,7 +588,8 @@ namespace pmr
> // The minimum size of a big block.
> // All big_block allocations will be a multiple of this value.
> // Use bit_ceil to get a power of two even for e.g. 20-bit size_t.
> -static constexpr size_t min = __bit_ceil(numeric_limits::digits);
> +static constexpr size_t min
> + = __bit_ceil((unsigned)numeric_limits::digits);
>
> constexpr
> big_block(size_t bytes, size_t alignment)
> --
> 2.48.1
>
>
Fix 'libstdc++-v3/src/c++20/tzdb.cc' build for '__GTHREADS && !__GTHREADS_CXX0X' configurations (was: libstdc++: '_GLIBCXX_HAS_GTHREADS' -- '__GTHREADS' vs. '__GTHREADS_CXX0X')
Hi!
On 2025-02-20T14:14:44+, Jonathan Wakely wrote:
> On Thu, 20 Feb 2025 at 14:08, Jonathan Wakely wrote:
>> On Thu, 20 Feb 2025 at 13:53, Thomas Schwinge wrote:
>> > On 2025-02-20T12:51:15+, Jonathan Wakely wrote:
>> > > On Thu, 20 Feb 2025 at 12:29, Thomas Schwinge
>> > > wrote:
>> > >> I'm still working on libstdc++ support for GCC's GPU targets: GCN,
>> > >> nvptx.
>> > >> These configurations are (in typical use) multi-threaded, and support
>> > >> mutexes etc., but they don't support dynamic spawning of threads etc.
>> > >> Therefore, re 'libgcc/gthr.h', they define '__GTHREADS' but *not*
>> > >> '__GTHREADS_CXX0X'. (See 'libgcc/config/gcn/gthr-gcn.h'; nvptx still to
>> > >> be done, currently 'Thread model: single', very likely bogus...)
>> > >>
>> > >> Now, 'libstdc++-v3/acinclude.m4:GLIBCXX_CHECK_GTHREADS' does:
>> > >>
>> > >> [...]
>> > >> AC_MSG_CHECKING([for gthreads library])
>> > >>
>> > >> AC_TRY_COMPILE([#include "gthr.h"],
>> > >> [
>> > >> #ifndef __GTHREADS_CXX0X
>> > >> #error
>> > >> #endif
>> > >> ], [ac_has_gthreads=yes], [ac_has_gthreads=no])
>> > >> else
>> > >> ac_has_gthreads=no
>> > >> fi
>> > >>
>> > >> AC_MSG_RESULT([$ac_has_gthreads])
>> > >>
>> > >> if test x"$ac_has_gthreads" = x"yes"; then
>> > >> AC_DEFINE(_GLIBCXX_HAS_GTHREADS, 1,
>> > >> [Define if gthreads library is available.])
>> > >> [...]
>> > >>
>> > >> That is, it defines '_GLIBCXX_HAS_GTHREADS' per '__GTHREADS_CXX0X'.
>> > >> Dependent on this '_GLIBCXX_HAS_GTHREADS',
>> > >> 'libstdc++-v3/include/bits/std_mutex.h' then enables 'class mutex'. In
>> > >> other words, in the current GCN configuration ('__GTHREADS', but not
>> > >> '__GTHREADS_CXX0X'), 'class mutex' (and probably more) is not available,
>> > >> which leads to build issues (and presumably a lot of noise in the test
>> > >> suite).
>> > >
>> > > What are the build issues? There shouldn't be any, because we should
>> > > be checking _GLIBCXX_HAS_GTHREADS as needed.
>> >
>> > The build issue is 'libstdc++-v3/src/c++20/tzdb.cc', which checks
>> > '#if defined __GTHREADS' (which GCN defines), and then assumes that
>> > 'mutex' is available,
>>
>> Right, that's a bug (and not the first time I've done that).
Specifically:
../../../../../source-gcc/libstdc++-v3/src/c++20/tzdb.cc:687:9: error:
‘mutex’ does not name a type; did you mean ‘minutes’? [-Wtemplate-body]
687 | mutex infos_mutex;
| ^
| minutes
>> > but that one via '_GLIBCXX_HAS_GTHREADS' is guarded
>> > on '__GTHREADS_CXX0X' (which GCN doesn't define).
>> >
>> > Now clearly 'std::chrono::tzdb' is not going to be used in offloaded code
>> > regions, but (a) famous last words..., and (b) I was more worried about
>> > the general case, where code (user code or libstdc++-internal) would see
>> > '!_GLIBCXX_HAS_GTHREADS', and from that deduce that locking for
>> > concurrent access etc. is not necessary.
>> >
>> > > And the testsuite should use dg-require-gthreads.
>> >
>> > > So instead of trying to make the C++11 thread library work without the
>> > > necessary gthreads support
>> >
>> > Right, we're not attempting to make 'std::thread::detach' work, for
>> > example. But I was assuming that we could/had to make 'std::mutex'
>> > etc. work, so that algorithms in presence of "external parallelism" still
>> > do the appropriate locking etc.
>> >
>> > Like, when used within a GPU parallel kernel, 'std::chrono::tzdb' needs
>> > to 'mutex' its internal state, thus, guarding that on '__GTHREADS' would
>> > seem correct, even if '!__GTHREADS_CXX0X'?
>>
>> Yes. Elsewhere in the library we do that with __gnu_cxx::__mutex
>> instead of std::mutex.
So you're saying, for '__GTHREADS && !__GTHREADS_CXX0X' configurations,
libstdc++ internally still does locking (via '__GTHREADS' primitives),
just the user-facing 'std::mutex' etc. isn't available?
>> I think this should fix it:
>>
>> --- a/libstdc++-v3/src/c++20/tzdb.cc
>> +++ b/libstdc++-v3/src/c++20/tzdb.cc
>> @@ -48,6 +48,7 @@
>> #else
>> # define USE_ATOMIC_LIST_HEAD 0
>> # define USE_ATOMIC_SHARED_PTR 0
>> +# include
>> #endif
>>
>> #if USE_ATOMIC_SHARED_PTR && ! USE_ATOMIC_LIST_HEAD
>> @@ -101,6 +102,8 @@ namespace std::chrono
>> #ifndef __GTHREADS
>> // Dummy no-op mutex type for single-threaded targets.
>> struct mutex { void lock() { } void unlock() { } };
>> +#elif ! defined _GLIBCXX_HAS_GHTREADS
>
> Oops, s/GHTR/GTHR/
>
>> +using mutex = __gnu_cxx::__mutex;
>> #endif
>> inline mutex& list_mutex()
>> {
GCN has 'defined __GTHREADS && ATOMIC_POINTER_LOCK_FREE == 2', so we
have:
#if defined __GTHREADS && ATOMIC_POINTER_LOCK_FREE == 2
# define USE_ATOMIC_LIST_HEAD 1
// TODO benchmark atomic> vs mutex.
# define USE_ATOMIC_SHARED_PTR 1
Maybe the attached
"Fix 'libstdc++-v3/src/c++20/tzdb.cc' build for '__GTHREADS &&
Re: [PATCH] c++: ICE with GOTO_EXPR [PR118928]
Now with the test fixed.
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >8 --
In this PR we crash in cxx_eval_constant_expression/GOTO_EXPR on:
gcc_assert (cxx_dialect >= cxx23);
The code obviously doesn't expect to see a goto pre-C++23. But we can
get here with the new prvalue optimization. In this test we found
ourselves in synthesize_method for X::X(). This function calls:
a) finish_function, which does cp_genericize -> ... -> genericize_c_loops,
which creates the GOTO_EXPR;
b) expand_or_defer_fn -> maybe_clone_body -> ... -> cp_fold_function
where we reach the new maybe_constant_init call and crash on the
goto.
Since we can validly get to that assert, I think we should just remove
it. I don't see other similar asserts like this one.
PR c++/118928
gcc/cp/ChangeLog:
* constexpr.cc (cxx_eval_constant_expression) : Remove
an assert.
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/constexpr-prvalue5.C: New test.
---
gcc/cp/constexpr.cc | 1 -
.../g++.dg/cpp0x/constexpr-prvalue5.C | 24 +++
2 files changed, 24 insertions(+), 1 deletion(-)
create mode 100644 gcc/testsuite/g++.dg/cpp0x/constexpr-prvalue5.C
diff --git a/gcc/cp/constexpr.cc b/gcc/cp/constexpr.cc
index 59dd0668af3..c68666cc5dd 100644
--- a/gcc/cp/constexpr.cc
+++ b/gcc/cp/constexpr.cc
@@ -8691,7 +8691,6 @@ cxx_eval_constant_expression (const constexpr_ctx *ctx,
tree t,
*jump_target = TREE_OPERAND (t, 0);
else
{
- gcc_assert (cxx_dialect >= cxx23);
if (!ctx->quiet)
error_at (loc, "% is not a constant expression");
*non_constant_p = true;
diff --git a/gcc/testsuite/g++.dg/cpp0x/constexpr-prvalue5.C
b/gcc/testsuite/g++.dg/cpp0x/constexpr-prvalue5.C
new file mode 100644
index 000..1f847bbe183
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/constexpr-prvalue5.C
@@ -0,0 +1,24 @@
+// PR c++/118928
+// { dg-do compile { target c++11 } }
+// { dg-options "-O" }
+
+using size_t = decltype(sizeof(0));
+
+namespace std {
+template struct initializer_list {
+ const T *_M_array;
+ size_t _M_len;
+};
+struct S {
+ constexpr S(const char *); // { dg-warning "used but never defined" }
+};
+struct vector {
+ constexpr vector(initializer_list) {}
+};
+}
+struct Y {
+std::vector v;
+};
+struct X {
+ Y y{{""}};
+} x;
base-commit: a2755339c6c9832467c573d956e91565943ecdc1
--
2.48.1
Re: rs6000: Add -msplit-patch-nops (PR112980)
On Wed, Nov 13, 2024 at 4:45 PM Andreas Schwab wrote:
>
> On Nov 13 2024, Michael Matz wrote:
>
> > @@ -31658,6 +31660,17 @@ requires @code{.plt} and @code{.got}
> > sections that are both writable and executable.
> > This is a PowerPC 32-bit SYSV ABI option.
> >
> > +@opindex msplit-patch-nops
> > +@item -msplit-patch-nops
> > +When adding NOPs for a patchable area via the
> > +@option{-fpatchable-function-entry} option emit the "before" NOPs in front
> > +of the global entry point and the "after" NOPs after the local entry point.
>
> Please use TeX quotes ``before'' and ``after''.
The patch is OK for trunk with this change suggested by Andreas. Please give
powerpc target maintainers a week to object or perform an review on
their behalf.
Thanks,
Richard.
>
> --
> Andreas Schwab, SUSE Labs, sch...@suse.de
> GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
> "And now for something completely different."
Re: [PATCH] config.host: add crtbeginT.o to extra_parts for FreeBSD [PR118685]
On Sat, 8 Feb 2025, Gerald Pfeifer wrote: > On Tue, 28 Jan 2025, Dimitry Andric wrote: >> Ref: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118685 >> >> This ensures that gcc uses its own crt objects for static linking. >> Otherwise, it could mix the base system's crtbeginT.o with libgcc's >> crtend.o, leading to possible segfaults. >> >> Signed-off-by: Dimitry Andric > Thank you, Dim! > > I ran a regression test and pushed this to trunk adding a ChangeLog entry > and adjusting the commit message a bit as follows. I plan to push back to > the gcc-14 branch shortly and the gcc-13 and gcc-12 branches gradually. I pushed this to the gcc-13 branch earlier this week and gcc-12 just now. With that all active GCC release branches are covered. Thanks again, Dim! Gerald
Re: [PATCH][RFC][PR tree-optimization/117829] Bogus Warray-bounds warning
On Thu, Feb 20, 2025 at 3:14 PM Jeff Law wrote:
>
>
>
> On 2/20/25 12:52 AM, Richard Biener wrote:
> > On Wed, Feb 19, 2025 at 11:29 PM Jeff Law wrote:
> >>
> >>
> >> An interesting little bug. We're just emitting what appears to me to be
> >> a silly warning.
> >>
> >> By the time the array-bounds checker runs we have this statement in the
> >> IL:
> >>
> >>>MEM[(int *)_42 + -4B] ={v} {CLOBBER(eob)};
> >>
> >> Naturally that looks like an out of bounds array index and we warn.
> >> Which seems dubious at best. My first thought is we shouldn't be trying
> >> to analyze a gimple clobber for out of bounds array indexes.
> >
> > OTOH all clobbers are inserted for actual allocated storage (even if not
> > accessed).
> True, but the clobbers seem like the wrong object to be checking for OOB
> access. We should be checking actual references.
>
> >
> >> But like most things in GCC, it's never that simple.
> >>
> >> It looks like we're relying on warning for that case for
> >> Warray-bounds-20.C.
> >>
> >>
> >>> [local count: 1073741824]:
> >>> MEM[(struct D1 *)&a + 1B] ={v} {CLOBBER(bob)};
> >>> MEM[(struct B *)&a + 1B]._vptr.B = &MEM [(void
> >>> *)&_ZTC2D10_1B + 24B];
> >>> MEM[(struct A *)&a + 9B]._vptr.A = &MEM [(void
> >>> *)&_ZTC2D10_1B + 64B];
> >>> C::C (&MEM[(struct D1 *)&a + 1B].D.3003, &MEM [(void
> >>> *)&_ZTT2D1 + 48B]);
> >>
> >> My sense is that this test is passing more by accident than by design
> >> and that the warning really should be triggered by one of the other
> >> statements.
> >
> > And it isn't? So A and B are smaller than D1 and only D1 overruns?
> > But it's not actually stored to?
> The overruns are completely missed AFAICT. The warning we get today is
> from the clobber statement.
>
> >
> >> Martin just got it wrong here AFAICT. I did go back and
> >> check the original BZ (pr98266). It's unaffected as it doesn't have the
> >> gimple clobbers.
> >
> > I'll note the unwanted diagnostic is on a EOB (end-of-object) while the
> > wanted is on a BOB (begin-of-object). Both are not begin/end-of-storage.
> >
> > Now find a convincing argument that any of those are not worth diagnosing...
> I think diagnosing overruns is good, but the clobber statement isn't the
> right thing to be analyzing for an overrun.
The very case of placement new made me question this.
struct x { int x; };
char a[1];
x *p = new (a) x;
should be diagnosed (ideally). That we diagnose it as an array bound
violation is of course bogus - the wording could be improved to
say (for bob or bos) 'constructing object of type X does not fit in
storage of size Y'
or so.
For
struct x[2];
x *p = new (&x[2]) x;
of course there's an array bound violation. But the way Martin added handling
of general MEM_REF to array-bound diagnostics of course makes this
susceptible to be misleading ...
So I think the patch is OK if you file a bugreport about the missed object
instantiation diagnostic from clobbers and for the missed diagnostic on
the actual access you showed above (we likely fail to handle component-ref
subsetted MEM_REFs ...), basically for the testcases you XFAIL.
Thanks,
Richard.
>
> Jeff
Re: [PATCH v2] aarch64: Ignore target pragmas while defining intrinsics
On Wed, Feb 19, 2025 at 12:17:55PM +, Richard Sandiford wrote:
> Andrew Carlotti writes:
> > [...]
> > @@ -204,6 +207,18 @@ static constexpr aarch64_processor_info all_cores[] =
> >{NULL, aarch64_no_cpu, aarch64_no_arch, 0}
> > };
> >
> > +/* Return the set of feature flags that are required to be enabled when the
> > + features in FLAGS are enabled. */
> > +
> > +aarch64_feature_flags
> > +aarch64_get_required_features (aarch64_feature_flags flags)
> > +{
> > + const struct aarch64_extension_info *opt;
> > + for (opt = all_extensions; opt->name != NULL; opt++)
> > +if (flags & opt->flag_canonical)
> > + flags |= opt->flags_required;
> > + return flags;
> > +}
>
> For the record, the transitive closure is available at compile time
> using aarch64-features-deps.h, so we could have required clients of
> aarch64_target_switcher to use that. But I agree that this approach
> is simpler.
>
> > /* Print a list of CANDIDATES for an argument, and try to suggest a
> > specific
> > close match. */
> > diff --git a/gcc/config/aarch64/aarch64-builtins.cc
> > b/gcc/config/aarch64/aarch64-builtins.cc
> > index
> > 128cc365d3d585e01cb69668f285318ee56a36fc..5174fb1daefee2d73a5098e0de1cca73dc103416
> > 100644
> > --- a/gcc/config/aarch64/aarch64-builtins.cc
> > +++ b/gcc/config/aarch64/aarch64-builtins.cc
> > @@ -1877,23 +1877,31 @@ aarch64_scalar_builtin_type_p (aarch64_simd_type t)
> >return (t == Poly8_t || t == Poly16_t || t == Poly64_t || t ==
> > Poly128_t);
> > }
> >
> > -/* Enable AARCH64_FL_* flags EXTRA_FLAGS on top of the base Advanced SIMD
> > - set. */
> > -aarch64_simd_switcher::aarch64_simd_switcher (aarch64_feature_flags
> > extra_flags)
> > +/* Temporarily set FLAGS as the enabled target features. */
> > +aarch64_target_switcher::aarch64_target_switcher (aarch64_feature_flags
> > flags)
> >: m_old_asm_isa_flags (aarch64_asm_isa_flags),
> > -m_old_general_regs_only (TARGET_GENERAL_REGS_ONLY)
> > +m_old_general_regs_only (TARGET_GENERAL_REGS_ONLY),
> > +m_old_target_pragma (current_target_pragma)
> > {
> > + /* Include all dependencies. */
> > + flags = aarch64_get_required_features (flags);
> > +
> >/* Changing the ISA flags should be enough here. We shouldn't need to
> > pay the compile-time cost of a full target switch. */
> > - global_options.x_target_flags &= ~MASK_GENERAL_REGS_ONLY;
> > - aarch64_set_asm_isa_flags (AARCH64_FL_FP | AARCH64_FL_SIMD |
> > extra_flags);
> > + if (flags & AARCH64_FL_FP)
> > +global_options.x_target_flags &= ~MASK_GENERAL_REGS_ONLY;
> > + aarch64_set_asm_isa_flags (flags);
>
> In the earlier review I'd suggested keeping aarch64_simd_(target_)switcher
> as a separate class, with aarch64_target_switcher being a new base class
> that handles the pragma.
>
> This patch seems to be more in the direction of treating
> aarch64_target_switcher as a one-stop shop that works out what to do
> based on the flags. I can see the attraction of that, but I think
> we should then fold sve_(target_)switcher into it too, for consistency.
I think I want to take a step back and look at what all the switcher effects
are and (to some extent) why they're needed.
1. Setting the value of aarch64_isa_flags - this requires unsetting
MASK_GENERAL_REGS_ONLY (for fp/simd targets), calling aarc64_set_asm_isa_flags,
and (for functions) unsetting current_target_pragma. I'm not sure what breaks
if this isn't done.
2. Setting maximum_field_alignment = 0 (to disable the effect of -fpack-struct)
- I think this is only relevant for ensuring the correct layout of the SVE
tuple types.
3. Enabling have_regs_for_mode[] for the SVE modes - I'm not sure specifically
why this is needed either, but I'm guessing this normally gets enabled as part
of a full target switch (though I couldn't immediately see how).
I think it makes sense to me for 1. and 3. to be based on flags (although I
think we need to base 3. upon either of SVE or SME being specified, to support
decoupling that dependency in the future). I'm not sure the same applies
for 2., however - perhaps it makes more sense for that to be a separate
standalone switcher class that is only used when defining the SVE tuple types?
How does that sound?
> Thanks,
> Richard
>
> > +
> > + /* Target pragmas are irrelevant when defining intrinsics artificially.
> > */
> > + current_target_pragma = NULL_TREE;
> > }
> >
> > -aarch64_simd_switcher::~aarch64_simd_switcher ()
> > +aarch64_target_switcher::~aarch64_target_switcher ()
> > {
> >if (m_old_general_regs_only)
> > global_options.x_target_flags |= MASK_GENERAL_REGS_ONLY;
> >aarch64_set_asm_isa_flags (m_old_asm_isa_flags);
> > + current_target_pragma = m_old_target_pragma;
> > }
> >
> > /* Implement #pragma GCC aarch64 "arm_neon.h".
> > @@ -1903,7 +1911,7 @@ aarch64_simd_switcher::~aarch64_simd_switcher ()
> > void
> > handle_arm_neon_h (void)
> > {
> > - aarch64_simd_switcher simd;
> > +
[PATCH] libiberty: move DW_LANG_* definitions to dwarf2.def
[Note: I don't have push access to gcc, so if approved, please push it
on my behalf, thanks.]
I need to have a "DW_LANG_* to string" function for a change I'm making
in binutils-gdb. I'm sending this patch to gcc first, once merged I'll
sync it to binutils-gdb.
- move the "DW_LANG_*" definitions from dwarf2.h to dwarf2.def
- add the necessary macros in dwarf2.h to generate the enumeration
- add the necessary macros in dwarfnames.c to generate the "to string"
function
include/ChangeLog:
* dwarf2.h (DW_LANG, DW_FIRST_LANG, DW_END_LANG): Define then
undefine.
(enum dwarf_source_language): Remove.
(get_DW_LANG_name): Declare.
* dwarf2.def: Define DW_LANG_* constants.
libiberty/ChangeLog:
* dwarfnames.c (DW_FIRST_LANG, DW_END_LANG, DW_LANG): Define
then undefine.
---
include/dwarf2.def | 89 +++
include/dwarf2.h | 103 +
libiberty/dwarfnames.c | 9
3 files changed, 109 insertions(+), 92 deletions(-)
diff --git a/include/dwarf2.def b/include/dwarf2.def
index 989f078041d4..4326e63646ee 100644
--- a/include/dwarf2.def
+++ b/include/dwarf2.def
@@ -830,3 +830,92 @@ DW_UT (DW_UT_split_type, 0x06)
DW_UT (DW_UT_lo_user, 0x80)
DW_UT (DW_UT_hi_user, 0xff)
DW_END_UT
+
+DW_FIRST_LANG (DW_LANG_C89, 0x0001)
+DW_LANG (DW_LANG_C, 0x0002)
+DW_LANG (DW_LANG_Ada83, 0x0003)
+DW_LANG (DW_LANG_C_plus_plus, 0x0004)
+DW_LANG (DW_LANG_Cobol74, 0x0005)
+DW_LANG (DW_LANG_Cobol85, 0x0006)
+DW_LANG (DW_LANG_Fortran77, 0x0007)
+DW_LANG (DW_LANG_Fortran90, 0x0008)
+DW_LANG (DW_LANG_Pascal83, 0x0009)
+DW_LANG (DW_LANG_Modula2, 0x000a)
+/* DWARF 3. */
+DW_LANG (DW_LANG_Java, 0x000b)
+DW_LANG (DW_LANG_C99, 0x000c)
+DW_LANG (DW_LANG_Ada95, 0x000d)
+DW_LANG (DW_LANG_Fortran95, 0x000e)
+DW_LANG (DW_LANG_PLI, 0x000f)
+DW_LANG (DW_LANG_ObjC, 0x0010)
+DW_LANG (DW_LANG_ObjC_plus_plus, 0x0011)
+DW_LANG (DW_LANG_UPC, 0x0012)
+DW_LANG (DW_LANG_D, 0x0013)
+/* DWARF 4. */
+DW_LANG (DW_LANG_Python, 0x0014)
+/* DWARF 5. */
+DW_LANG (DW_LANG_OpenCL, 0x0015)
+DW_LANG (DW_LANG_Go, 0x0016)
+DW_LANG (DW_LANG_Modula3, 0x0017)
+DW_LANG (DW_LANG_Haskell, 0x0018)
+DW_LANG (DW_LANG_C_plus_plus_03, 0x0019)
+DW_LANG (DW_LANG_C_plus_plus_11, 0x001a)
+DW_LANG (DW_LANG_OCaml, 0x001b)
+DW_LANG (DW_LANG_Rust, 0x001c)
+DW_LANG (DW_LANG_C11, 0x001d)
+DW_LANG (DW_LANG_Swift, 0x001e)
+DW_LANG (DW_LANG_Julia, 0x001f)
+DW_LANG (DW_LANG_Dylan, 0x0020)
+DW_LANG (DW_LANG_C_plus_plus_14, 0x0021)
+DW_LANG (DW_LANG_Fortran03, 0x0022)
+DW_LANG (DW_LANG_Fortran08, 0x0023)
+DW_LANG (DW_LANG_RenderScript, 0x0024)
+DW_LANG (DW_LANG_BLISS, 0x0025)
+/* Post DWARF 5 additions to the DWARF set.
+See https://dwarfstd.org/languages.html . */
+DW_LANG (DW_LANG_Kotlin, 0x0026)
+DW_LANG (DW_LANG_Zig, 0x0027)
+DW_LANG (DW_LANG_Crystal, 0x0028)
+DW_LANG (DW_LANG_C_plus_plus_17, 0x002a)
+DW_LANG (DW_LANG_C_plus_plus_20, 0x002b)
+DW_LANG (DW_LANG_C17, 0x002c)
+DW_LANG (DW_LANG_Fortran18, 0x002d)
+DW_LANG (DW_LANG_Ada2005, 0x002e)
+DW_LANG (DW_LANG_Ada2012, 0x002f)
+DW_LANG (DW_LANG_HIP, 0x0030)
+DW_LANG (DW_LANG_Assembly, 0x0031)
+DW_LANG (DW_LANG_C_sharp, 0x0032)
+DW_LANG (DW_LANG_Mojo, 0x0033)
+DW_LANG (DW_LANG_GLSL, 0x0034)
+DW_LANG (DW_LANG_GLSL_ES, 0x0035)
+DW_LANG (DW_LANG_HLSL, 0x0036)
+DW_LANG (DW_LANG_OpenCL_CPP, 0x0037)
+DW_LANG (DW_LANG_CPP_for_OpenCL, 0x0038)
+DW_LANG (DW_LANG_SYCL, 0x0039)
+DW_LANG (DW_LANG_C_plus_plus_23, 0x003a)
+DW_LANG (DW_LANG_Odin, 0x003b)
+DW_LANG (DW_LANG_P4, 0x003c)
+DW_LANG (DW_LANG_Metal, 0x003d)
+DW_LANG (DW_LANG_C23, 0x003e)
+DW_LANG (DW_LANG_Fortran23, 0x003f)
+DW_LANG (DW_LANG_Ruby, 0x0040)
+DW_LANG (DW_LANG_Move, 0x0041)
+DW_LANG (DW_LANG_Hylo, 0x0042)
+
+DW_LANG (DW_LANG_lo_user, 0x8000) /* Implementation-defined range start.
*/
+DW_LANG (DW_LANG_hi_user, 0x) /* Implementation-defined range start.
*/
+
+/* MIPS. */
+DW_LANG (DW_LANG_Mips_Assembler, 0x8001)
+/* UPC. */
+DW_LANG (DW_LANG_Upc, 0x8765)
+/* HP extensions. */
+DW_LANG (DW_LANG_HP_Bliss, 0x8003)
+DW_LANG (DW_LANG_HP_Basic91, 0x8004)
+DW_LANG (DW_LANG_HP_Pascal91, 0x8005)
+DW_LANG (DW_LANG_HP_IMacro, 0x8006)
+DW_LANG (DW_LANG_HP_Assembler, 0x8007)
+
+/* Rust extension, but replaced in DWARF 5. */
+DW_LANG (DW_LANG_Rust_old, 0x9000)
+DW_END_LANG
diff --git a/include/dwarf2.h b/include/dwarf2.h
index 37fbc368..43744818611d 100644
--- a/include/dwarf2.h
+++ b/include/dwarf2.h
@@ -56,6 +56,7 @@
#define DW_IDX(name, value) , name = value
#define DW_IDX_DUP(name, value) , name = value
#define DW_UT(name, value) , name = value
+#define DW_LANG(name, value) , name = value
#define DW_FIRST_TAG(name, value) enum dwarf_tag { \
name = value
@@ -86,6 +87,9 @@
#define DW_FIRST_UT(name, value) enum dwarf_unit_type { \
name = value
#define DW_END_UT };
+#define DW_FIRST_LANG(name, value) enum dwarf_source_language { \
+ name = value
+#define DW_END_LANG };
#include "dwarf2.def"
@@ -105,6 +109,8 @@
#
Re: Larger diagnostic questions/plan
On 2/20/25 7:17 AM, Richard Biener wrote: I hesitate to even bring it up (but we need to). Do we want to consider the state/future of these warnings for gcc-16? Is this stuff salvageable? I think there's utility in these warnings, but they're clearly a pain point across multiple contexts. What I'd like to see is less diagnostics emitted from random passes but instead, like we did with the array-bounds pass, do it separately. And then have those passes not be randomly spread but in one or two places. I think that's fair. The two that come to mind in terms of too tightly integrated into an optimization pass are sprintf and all the stuff in the strlen pass. I think of the two the strlen bits are the most "interesting". My recollection was the whole point was to get access to nuggets of information in the strlen pass that would help drive down the false positives. At least conceptually if we found a way to expose the data in the IL or turn the analysis into a reusable module to be used by the diagnostics and the strlen optimizations independently that would take us in the right direction much like we did with pulling the array bounds warnings out of VRP. As for where they fit in the pipeline. I'm torn as I tend to believe that things are where they are for a reason. We need to be willing to tolerate more false positives (and I am) to bring some cleanliness to this problem. I think the other thing we need to look at are various (sometimes dubious) heuristics that possibly made sense at the time, but with the knowledge we've gained we probably want to revisit. But in general as you say the "advancd IL diagnostics" face the same issue as static analyzers - we usually lack knowledge of all pre-conditions to avoid false positives and there's no nice way to annotate source with those in a way not affecting code generation (because we warn off the IL, so those need to be in the IL itself). The analyzer should have the very same issue here. There's Qings patch to improve the diagnostic to help users write missing pre-conditions, so that's a thing to look at. I think you've hit one of the other key pain points. We've often found it quite hard at times to turn off the diagnostics properly, either with a pragma or careful use of __builtin_unreachable. That's really hard on the end users. Jeff
Re: [PATCH 1/2] libstdc++: Fix invalid signed arguments to functions
On Thu, 20 Feb 2025 at 14:41, Patrick Palka wrote:
>
> On Sat, 15 Feb 2025, Jonathan Wakely wrote:
>
> > These should have been unsigned, but the static assertions are only in
> > the public std::bit_ceil and std::bit_width functions, not the internal
> > __bit_ceil and __bit_width ones.
> >
> > libstdc++-v3/ChangeLog:
> >
> > * include/experimental/bits/simd.h (__find_next_valid_abi): Cast
> > __bit_ceil argument to unsigned.
> > * src/c++17/floating_from_chars.cc (__floating_from_chars_hex):
> > Cast __bit_ceil argument to unsigned.
> > * src/c++17/memory_resource.cc (big_block): Cast __bit_width
> > argument to unsigned.
> > ---
> >
> > Tested x86_64-linux.
> >
> > libstdc++-v3/include/experimental/bits/simd.h | 2 +-
> > libstdc++-v3/src/c++17/floating_from_chars.cc | 5 +++--
> > libstdc++-v3/src/c++17/memory_resource.cc | 3 ++-
> > 3 files changed, 6 insertions(+), 4 deletions(-)
> >
> > diff --git a/libstdc++-v3/include/experimental/bits/simd.h
> > b/libstdc++-v3/include/experimental/bits/simd.h
> > index 500c1781ae54..f0cb101aaa82 100644
> > --- a/libstdc++-v3/include/experimental/bits/simd.h
> > +++ b/libstdc++-v3/include/experimental/bits/simd.h
> > @@ -4634,7 +4634,7 @@ template class _Abi, int _Bytes,
> > typename _Tp>
> > static constexpr auto
> > _S_choose()
> > {
> > - constexpr int _NextBytes = std::__bit_ceil(_Bytes) / 2;
> > + constexpr int _NextBytes = std::__bit_ceil((unsigned)_Bytes) / 2;
> >using _NextAbi = _Abi<_NextBytes>;
> >if constexpr (_NextBytes < sizeof(_Tp) * 2) // break recursion
> > return _Abi<_Bytes>();
> > diff --git a/libstdc++-v3/src/c++17/floating_from_chars.cc
> > b/libstdc++-v3/src/c++17/floating_from_chars.cc
> > index f8b1e23937d2..d48f1c0d4545 100644
> > --- a/libstdc++-v3/src/c++17/floating_from_chars.cc
> > +++ b/libstdc++-v3/src/c++17/floating_from_chars.cc
> > @@ -1102,8 +1102,9 @@ namespace
> >{
> > // If the leading hexit is not '1', shift MANTISSA to make it so.
> > // This normalizes input like "4.08p0" into "1.02p2".
> > - const int leading_hexit = mantissa >> mantissa_bits;
> > - const int leading_hexit_width = __bit_width(leading_hexit); // FIXME:
> > optimize?
> > + const unsigned leading_hexit = mantissa >> mantissa_bits;
> > + const int leading_hexit_width
> > + = __bit_width((unsigned)leading_hexit); // FIXME: optimize?
>
> Not a big deal, but isn't this cast redundant if we've defined
> leading_hexit as unsigned?
You can never be too careful in C++! ;-)
Yes you're absolutely right. I think I added the cast at first, then
realised that I could just make the variable unsigned, but forgot to
undo the cast.
The attached patch reverts the cast part, just leaving the
s/int/unsigned/ part on the previous line.
commit ef1655d3c3caeac56cc9124a2479a5bfac90a239
Author: Jonathan Wakely
AuthorDate: Thu Feb 20 15:16:11 2025
Commit: Jonathan Wakely
CommitDate: Thu Feb 20 15:16:11 2025
libstdc++: Remove redundant cast in floating_from_chars.cc
In r15-7647-g32457bc25fea80 I added a cast and also changed the type of
the variable, making the cast redundant. This removes the cast.
libstdc++-v3/ChangeLog:
* src/c++17/floating_from_chars.cc (__floating_from_chars_hex):
Remove redundant cast.
diff --git a/libstdc++-v3/src/c++17/floating_from_chars.cc
b/libstdc++-v3/src/c++17/floating_from_chars.cc
index d48f1c0d454..9bad12c7f69 100644
--- a/libstdc++-v3/src/c++17/floating_from_chars.cc
+++ b/libstdc++-v3/src/c++17/floating_from_chars.cc
@@ -1103,8 +1103,7 @@ namespace
// If the leading hexit is not '1', shift MANTISSA to make it so.
// This normalizes input like "4.08p0" into "1.02p2".
const unsigned leading_hexit = mantissa >> mantissa_bits;
- const int leading_hexit_width
- = __bit_width((unsigned)leading_hexit); // FIXME: optimize?
+ const int leading_hexit_width = __bit_width(leading_hexit); // FIXME:
optimize?
__glibcxx_assert(leading_hexit_width >= 1 && leading_hexit_width <= 4);
shift_mantissa(leading_hexit_width - 1);
// After this adjustment, we can assume the leading hexit is '1'.
Re: [PATCH] libstdc++: implement constexpr memory algorithms
On Sun, 16 Feb 2025, Giuseppe D'Angelo wrote:
> Hello,
>
> the attached patch implements the C++26 papers that add `constexpr` to the
> specialized memory algorithms (the uninitialized_* family). Tested on x86-64
> Linux.
>
> Thank you,
> --
> Giuseppe D'Angelo
>
> Subject: [PATCH] libstdc++: implement constexpr memory algorithms
>
> This commit adds support for C++26's constexpr specialized memory
> algorithms, introduced by P2283R2, P3508R0, P3369R0.
>
> The uninitialized_default, value, copy, move and fill algorithms are
> affected, in all of their variants (iterator-based, range-based and _n
> versions.)
>
> The changes are mostly mechanical -- add `constexpr` to a number of
> signatures. I've introduced a helper macro to conditionally expand to
> `constexpr` only in C++26 and above modes. The internal helper guard
> class for range algorithms instead can be marked unconditionally.
>
> uninitialized_fill is the only algorithm where I had to add a branch to
> a constexpr-friendly version (already existing).
Seems the patch also adds code to uninitialized_copy and
uninitialized_fill_n?
>
> For each algorithm family I've added only one test to cover it and its
> variants; the idea is to avoid too much repetition and simplify future
> maintenance.
>
> libstdc++-v3/ChangeLog:
>
> * include/bits/ranges_uninitialized.h: Mark the specialized
> memory algorithms as constexpr in C++26. Also mark the members
> of the _DestroyGuard helper class.
> * include/bits/stl_uninitialized.h: Ditto.
> * include/bits/stl_construct.h: Mark _Construct_novalue (which
> uses placement new to do default initialization) as constexpr
> in C++26. This is possible due to P2747R2, which GCC already
> implements; check P2747's feature-testing macro to avoid
> issues with other compilers.
> * include/bits/version.def: Bump the feature-testing macro.
> * include/bits/version.h: Regenerate.
> * testsuite/20_util/specialized_algorithms/feature_test_macro.cc: New
> test.
> *
> testsuite/20_util/specialized_algorithms/uninitialized_copy/constexpr.cc: New
> test.
> *
> testsuite/20_util/specialized_algorithms/uninitialized_default_construct/constexpr.cc:
> New test.
> *
> testsuite/20_util/specialized_algorithms/uninitialized_fill/constexpr.cc: New
> test.
> *
> testsuite/20_util/specialized_algorithms/uninitialized_move/constexpr.cc: New
> test.
> *
> testsuite/20_util/specialized_algorithms/uninitialized_value_construct/constexpr.cc:
> New test.
>
> Signed-off-by: Giuseppe D'Angelo
> ---
> .../include/bits/ranges_uninitialized.h | 29
> libstdc++-v3/include/bits/stl_construct.h | 3 +
> libstdc++-v3/include/bits/stl_uninitialized.h | 42
> libstdc++-v3/include/bits/version.def | 5 ++
> libstdc++-v3/include/bits/version.h | 7 +-
> .../feature_test_macro.cc | 14
> .../uninitialized_copy/constexpr.cc | 58
> .../constexpr.cc | 67 ++
> .../uninitialized_fill/constexpr.cc | 68 +++
> .../uninitialized_move/constexpr.cc | 51 ++
> .../constexpr.cc | 64 +
> 11 files changed, 407 insertions(+), 1 deletion(-)
> create mode 100644
> libstdc++-v3/testsuite/20_util/specialized_algorithms/feature_test_macro.cc
> create mode 100644
> libstdc++-v3/testsuite/20_util/specialized_algorithms/uninitialized_copy/constexpr.cc
> create mode 100644
> libstdc++-v3/testsuite/20_util/specialized_algorithms/uninitialized_default_construct/constexpr.cc
> create mode 100644
> libstdc++-v3/testsuite/20_util/specialized_algorithms/uninitialized_fill/constexpr.cc
> create mode 100644
> libstdc++-v3/testsuite/20_util/specialized_algorithms/uninitialized_move/constexpr.cc
> create mode 100644
> libstdc++-v3/testsuite/20_util/specialized_algorithms/uninitialized_value_construct/constexpr.cc
>
> diff --git a/libstdc++-v3/include/bits/ranges_uninitialized.h
> b/libstdc++-v3/include/bits/ranges_uninitialized.h
> index ced7bda5e37..337d321702d 100644
> --- a/libstdc++-v3/include/bits/ranges_uninitialized.h
> +++ b/libstdc++-v3/include/bits/ranges_uninitialized.h
> @@ -35,6 +35,12 @@
>
> #include
>
> +#if __glibcxx_raw_memory_algorithms >= 202411L // >= C++26
> +# define _GLIBCXX26_CONSTEXPR_RAW_MEMORY_ALGORITHMS constexpr
> +#else
> +# define _GLIBCXX26_CONSTEXPR_RAW_MEMORY_ALGORITHMS
> +#endif
> +
> namespace std _GLIBCXX_VISIBILITY(default)
> {
> _GLIBCXX_BEGIN_NAMESPACE_VERSION
> @@ -105,15 +111,18 @@ namespace ranges
> const _Iter* _M_cur;
>
>public:
> + constexpr
> explicit
> _DestroyGuard(const _Iter& __iter)
> : _M_first(__iter), _M_cur(std::__addressof(__iter))
> { }
>
> + constexpr
> void
> release() noe
Re: Fix 'libstdc++-v3/src/c++20/tzdb.cc' build for '__GTHREADS && !__GTHREADS_CXX0X' configurations (was: libstdc++: '_GLIBCXX_HAS_GTHREADS' -- '__GTHREADS' vs. '__GTHREADS_CXX0X')
On 20/02/25 15:50 +0100, Thomas Schwinge wrote:
Hi!
On 2025-02-20T14:14:44+, Jonathan Wakely wrote:
On Thu, 20 Feb 2025 at 14:08, Jonathan Wakely wrote:
On Thu, 20 Feb 2025 at 13:53, Thomas Schwinge wrote:
> On 2025-02-20T12:51:15+, Jonathan Wakely wrote:
> > On Thu, 20 Feb 2025 at 12:29, Thomas Schwinge
wrote:
> >> I'm still working on libstdc++ support for GCC's GPU targets: GCN, nvptx.
> >> These configurations are (in typical use) multi-threaded, and support
> >> mutexes etc., but they don't support dynamic spawning of threads etc.
> >> Therefore, re 'libgcc/gthr.h', they define '__GTHREADS' but *not*
> >> '__GTHREADS_CXX0X'. (See 'libgcc/config/gcn/gthr-gcn.h'; nvptx still to
> >> be done, currently 'Thread model: single', very likely bogus...)
> >>
> >> Now, 'libstdc++-v3/acinclude.m4:GLIBCXX_CHECK_GTHREADS' does:
> >>
> >> [...]
> >> AC_MSG_CHECKING([for gthreads library])
> >>
> >> AC_TRY_COMPILE([#include "gthr.h"],
> >> [
> >> #ifndef __GTHREADS_CXX0X
> >> #error
> >> #endif
> >> ], [ac_has_gthreads=yes], [ac_has_gthreads=no])
> >> else
> >> ac_has_gthreads=no
> >> fi
> >>
> >> AC_MSG_RESULT([$ac_has_gthreads])
> >>
> >> if test x"$ac_has_gthreads" = x"yes"; then
> >> AC_DEFINE(_GLIBCXX_HAS_GTHREADS, 1,
> >> [Define if gthreads library is available.])
> >> [...]
> >>
> >> That is, it defines '_GLIBCXX_HAS_GTHREADS' per '__GTHREADS_CXX0X'.
> >> Dependent on this '_GLIBCXX_HAS_GTHREADS',
> >> 'libstdc++-v3/include/bits/std_mutex.h' then enables 'class mutex'. In
> >> other words, in the current GCN configuration ('__GTHREADS', but not
> >> '__GTHREADS_CXX0X'), 'class mutex' (and probably more) is not available,
> >> which leads to build issues (and presumably a lot of noise in the test
> >> suite).
> >
> > What are the build issues? There shouldn't be any, because we should
> > be checking _GLIBCXX_HAS_GTHREADS as needed.
>
> The build issue is 'libstdc++-v3/src/c++20/tzdb.cc', which checks
> '#if defined __GTHREADS' (which GCN defines), and then assumes that
> 'mutex' is available,
Right, that's a bug (and not the first time I've done that).
Specifically:
../../../../../source-gcc/libstdc++-v3/src/c++20/tzdb.cc:687:9: error:
‘mutex’ does not name a type; did you mean ‘minutes’? [-Wtemplate-body]
687 | mutex infos_mutex;
| ^
| minutes
Ah right, so the error is later.
> but that one via '_GLIBCXX_HAS_GTHREADS' is guarded
> on '__GTHREADS_CXX0X' (which GCN doesn't define).
>
> Now clearly 'std::chrono::tzdb' is not going to be used in offloaded code
> regions, but (a) famous last words..., and (b) I was more worried about
> the general case, where code (user code or libstdc++-internal) would see
> '!_GLIBCXX_HAS_GTHREADS', and from that deduce that locking for
> concurrent access etc. is not necessary.
>
> > And the testsuite should use dg-require-gthreads.
>
> > So instead of trying to make the C++11 thread library work without the
> > necessary gthreads support
>
> Right, we're not attempting to make 'std::thread::detach' work, for
> example. But I was assuming that we could/had to make 'std::mutex'
> etc. work, so that algorithms in presence of "external parallelism" still
> do the appropriate locking etc.
>
> Like, when used within a GPU parallel kernel, 'std::chrono::tzdb' needs
> to 'mutex' its internal state, thus, guarding that on '__GTHREADS' would
> seem correct, even if '!__GTHREADS_CXX0X'?
Yes. Elsewhere in the library we do that with __gnu_cxx::__mutex
instead of std::mutex.
So you're saying, for '__GTHREADS && !__GTHREADS_CXX0X' configurations,
libstdc++ internally still does locking (via '__GTHREADS' primitives),
just the user-facing 'std::mutex' etc. isn't available?
Yes, there's a __gnu_cxx::__mutex type that has existed since before
__GTHREADS_CXX0X was added, and only requires __GTHREADS.
I think this should fix it:
--- a/libstdc++-v3/src/c++20/tzdb.cc
+++ b/libstdc++-v3/src/c++20/tzdb.cc
@@ -48,6 +48,7 @@
#else
# define USE_ATOMIC_LIST_HEAD 0
# define USE_ATOMIC_SHARED_PTR 0
+# include
#endif
#if USE_ATOMIC_SHARED_PTR && ! USE_ATOMIC_LIST_HEAD
@@ -101,6 +102,8 @@ namespace std::chrono
#ifndef __GTHREADS
// Dummy no-op mutex type for single-threaded targets.
struct mutex { void lock() { } void unlock() { } };
+#elif ! defined _GLIBCXX_HAS_GHTREADS
Oops, s/GHTR/GTHR/
+using mutex = __gnu_cxx::__mutex;
#endif
inline mutex& list_mutex()
{
GCN has 'defined __GTHREADS && ATOMIC_POINTER_LOCK_FREE == 2', so we
have:
#if defined __GTHREADS && ATOMIC_POINTER_LOCK_FREE == 2
# define USE_ATOMIC_LIST_HEAD 1
// TODO benchmark atomic> vs mutex.
# define USE_ATOMIC_SHARED_PTR 1
Maybe the attached
"Fix 'libstdc++-v3/src/c++20/tzdb.cc' build for '__GTHREADS && !__GTHREADS_CXX0X'
configurations"?
Only GCN, nvptx build-tested so far.
Grüße
Tho
Re: [PATCH] arm: Fix signedness of some vld1q intrinsic parameters for ARM NEON
Hi,
On Thu, 20 Feb 2025 at 15:18, Hannes Braun wrote:
>
> vld1q_s8_x3, vld1q_s16_x3, vld1q_s8_x4 and vld1q_s16_x4 were expecting
> pointers to unsigned integers. These parameters should be pointers to
> signed integers.
>
> gcc/ChangeLog:
>
> * config/arm/arm_neon.h (vld1q_s8_x3): Use int8_t instead of
> uint16_t.
> (vld1q_s16_x3): Use int16_t instead of uint16_t.
> (vld1q_s8_x4): Likewise.
> (vld1q_s16_x4): Likewise.
Thanks for catching this and providing a fix.
Too bad the testcases are not compiled with enough warnings to detect this.
Minor comments (I can't approve the patch)
IIUC, that's for PR 118942? So the ChangeLog entry should mention PR
target/118942 (just before the * config/arm/arm_neon.h line), and the
commit title should end with [PR 118942], but that can be fixed at
commit time.
The contrib/gcc-changelog/git_check_commit.py script can help you
check that your commit message will be accepted by the commit hooks.
Looking at the original patch from Ezra, I think we should also have
enabled the relevant tests in gcc.target/aarch64/advsimd-intrinsics
(e.g. vld1x3.c) ?
Thanks,
Christophe
>
> Signed-off-by: Hannes Braun
> ---
> gcc/config/arm/arm_neon.h | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/gcc/config/arm/arm_neon.h b/gcc/config/arm/arm_neon.h
> index 5b1c55c8d9f..578ada88fa6 100644
> --- a/gcc/config/arm/arm_neon.h
> +++ b/gcc/config/arm/arm_neon.h
> @@ -10854,7 +10854,7 @@ vld1q_s64_x2 (const int64_t * __a)
>
> __extension__ extern __inline int8x16x3_t
> __attribute__ ((__always_inline__, __gnu_inline__, __artificial__))
> -vld1q_s8_x3 (const uint8_t * __a)
> +vld1q_s8_x3 (const int8_t * __a)
> {
>union { int8x16x3_t __i; __builtin_neon_ci __o; } __rv;
>__rv.__o = __builtin_neon_vld1q_x3v16qi ((const __builtin_neon_qi *) __a);
> @@ -10863,7 +10863,7 @@ vld1q_s8_x3 (const uint8_t * __a)
>
> __extension__ extern __inline int16x8x3_t
> __attribute__ ((__always_inline__, __gnu_inline__, __artificial__))
> -vld1q_s16_x3 (const uint16_t * __a)
> +vld1q_s16_x3 (const int16_t * __a)
> {
>union { int16x8x3_t __i; __builtin_neon_ci __o; } __rv;
>__rv.__o = __builtin_neon_vld1q_x3v8hi ((const __builtin_neon_hi *) __a);
> @@ -10890,7 +10890,7 @@ vld1q_s64_x3 (const int64_t * __a)
>
> __extension__ extern __inline int8x16x4_t
> __attribute__ ((__always_inline__, __gnu_inline__, __artificial__))
> -vld1q_s8_x4 (const uint8_t * __a)
> +vld1q_s8_x4 (const int8_t * __a)
> {
>union { int8x16x4_t __i; __builtin_neon_xi __o; } __rv;
>__rv.__o = __builtin_neon_vld1q_x4v16qi ((const __builtin_neon_qi *) __a);
> @@ -10899,7 +10899,7 @@ vld1q_s8_x4 (const uint8_t * __a)
>
> __extension__ extern __inline int16x8x4_t
> __attribute__ ((__always_inline__, __gnu_inline__, __artificial__))
> -vld1q_s16_x4 (const uint16_t * __a)
> +vld1q_s16_x4 (const int16_t * __a)
> {
>union { int16x8x4_t __i; __builtin_neon_xi __o; } __rv;
>__rv.__o = __builtin_neon_vld1q_x4v8hi ((const __builtin_neon_hi *) __a);
> --
> 2.48.1
>
[PATCH 3/4] libstdc++: Avoid '-Wunused-parameter' for 'is_directory' in member function 'bool std::filesystem::__cxx11::_Dir::do_unlink(bool, std::error_code&) const'
In a newlib configuration:
../../../../../source-gcc/libstdc++-v3/src/c++17/fs_dir.cc: In member
function ‘bool std::filesystem::__cxx11::_Dir::do_unlink(bool,
std::error_code&) const’:
../../../../../source-gcc/libstdc++-v3/src/c++17/fs_dir.cc:147:18: error:
unused parameter ‘is_directory’ [-Werror=unused-parameter]
147 | do_unlink(bool is_directory, error_code& ec) const noexcept
| ~^~~~
libstdc++-v3/
* src/c++17/fs_dir.cc (do_unlink): Tag 'is_directory' as
'[[maybe_unused]]'.
---
libstdc++-v3/src/c++17/fs_dir.cc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libstdc++-v3/src/c++17/fs_dir.cc b/libstdc++-v3/src/c++17/fs_dir.cc
index cd75e0541d3..9347a8a46dc 100644
--- a/libstdc++-v3/src/c++17/fs_dir.cc
+++ b/libstdc++-v3/src/c++17/fs_dir.cc
@@ -144,7 +144,7 @@ struct fs::_Dir : _Dir_base
}
bool
- do_unlink(bool is_directory, error_code& ec) const noexcept
+ do_unlink([[maybe_unused]] bool is_directory, error_code& ec) const noexcept
{
#if _GLIBCXX_HAVE_UNLINKAT
const auto atp = current();
--
2.34.1
Re: [PATCH 2/4] libstdc++: Avoid '-Wunused-parameter' for 'nofollow' in static member function 'static std::filesystem::__gnu_posix::DIR* std::filesystem::_Dir_base::openat(const _At_path&, bool)'
On Thu, 20 Feb 2025 at 16:58, Thomas Schwinge wrote:
>
> In a newlib configuration:
>
> In file included from
> ../../../../../source-gcc/libstdc++-v3/src/c++17/fs_dir.cc:37,
> from
> ../../../../../source-gcc/libstdc++-v3/src/c++17/cow-fs_dir.cc:26:
>
> ../../../../../source-gcc/libstdc++-v3/src/c++17/../filesystem/dir-common.h:
> In static member function ‘static std::filesystem::__gnu_posix::DIR*
> std::filesystem::_Dir_base::openat(const _At_path&, bool)’:
>
> ../../../../../source-gcc/libstdc++-v3/src/c++17/../filesystem/dir-common.h:210:36:
> error: unused parameter ‘nofollow’ [-Werror=unused-parameter]
> 210 | openat(const _At_path& atp, bool nofollow)
> | ~^~~~
>
> libstdc++-v3/
> * src/filesystem/dir-common.h (openat): Tag 'nofollow' as
> '[[maybe_unused]]'.
OK (there are quite a few unused params in the filesystem code that I
haven't bothered to mark with the attribute, because I don't see the
warnings on the targets I usually test).
> ---
> libstdc++-v3/src/filesystem/dir-common.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libstdc++-v3/src/filesystem/dir-common.h
> b/libstdc++-v3/src/filesystem/dir-common.h
> index 5ff621c3380..c7d4bc4e6ed 100644
> --- a/libstdc++-v3/src/filesystem/dir-common.h
> +++ b/libstdc++-v3/src/filesystem/dir-common.h
> @@ -207,7 +207,7 @@ struct _Dir_base
>}
>
>static posix::DIR*
> - openat(const _At_path& atp, bool nofollow)
> + openat(const _At_path& atp, [[maybe_unused]] bool nofollow)
>{
> #if _GLIBCXX_HAVE_FDOPENDIR && defined O_RDONLY && defined O_DIRECTORY \
> && ! _GLIBCXX_FILESYSTEM_IS_WINDOWS
> --
> 2.34.1
>
[PATCH 4/4] libstdc++: Avoid '-Wunused-parameter' for 'out' in member function 'std::codecvt_base::result std::__format::{anonymous}::__encoding::conv(std::string_view, std::string&) const'
In a newlib configuration:
../../../../../source-gcc/libstdc++-v3/src/c++20/format.cc: In member
function ‘std::codecvt_base::result
std::__format::{anonymous}::__encoding::conv(std::string_view, std::string&)
const’:
../../../../../source-gcc/libstdc++-v3/src/c++20/format.cc:100:35: error:
unused parameter ‘out’ [-Werror=unused-parameter]
100 | conv(string_view input, string& out) const
| ^~~
libstdc++-v3/
* src/c++20/format.cc (conv): Tag 'out' as '[[maybe_unused]]'.
---
libstdc++-v3/src/c++20/format.cc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libstdc++-v3/src/c++20/format.cc b/libstdc++-v3/src/c++20/format.cc
index 1a24fcab7f7..6967d53259d 100644
--- a/libstdc++-v3/src/c++20/format.cc
+++ b/libstdc++-v3/src/c++20/format.cc
@@ -97,7 +97,7 @@ struct __encoding : locale::facet
// Convert `input` to UTF-8, using `out` to hold the result.
codecvt_base::result
- conv(string_view input, string& out) const
+ conv(string_view input, [[maybe_unused]] string& out) const
{
if (input.empty()) [[unlikely]]
return codecvt_base::noconv;
--
2.34.1
[PATCH 1/4] libstdc++: Avoid '-Wunused-parameter' for '__what' in function 'void std::__throw_format_error(const char*)'
In a '-fno-exceptions' configuration: In file included from ../../../../../source-gcc/libstdc++-v3/src/c++20/format.cc:29: [...]/build-gcc/[...]/libstdc++-v3/include/format: In function ‘void std::__throw_format_error(const char*)’: [...]/build-gcc/[...]/libstdc++-v3/include/format:200:36: error: unused parameter ‘__what’ [-Werror=unused-parameter] 200 | __throw_format_error(const char* __what) |^~ libstdc++-v3/ * include/bits/c++config [!__cpp_exceptions] (_GLIBCXX_THROW_OR_ABORT): Reference '_EXC'. --- libstdc++-v3/include/bits/c++config | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libstdc++-v3/include/bits/c++config b/libstdc++-v3/include/bits/c++config index b0ca6579cfb..e9782c03ee2 100644 --- a/libstdc++-v3/include/bits/c++config +++ b/libstdc++-v3/include/bits/c++config @@ -253,7 +253,7 @@ # if __cpp_exceptions # define _GLIBCXX_THROW_OR_ABORT(_EXC) (throw (_EXC)) # else -# define _GLIBCXX_THROW_OR_ABORT(_EXC) (__builtin_abort()) +# define _GLIBCXX_THROW_OR_ABORT(_EXC) ((void) (_EXC), __builtin_abort()) # endif #endif -- 2.34.1
libstdc++: Avoid '-Wunused-parameter's
Hi! In the following, a few patches for libstdc++ to avoid '-Wunused-parameter' diagnostics (actually '-Werror=unused-parameter', for my '--enable-werror' builds). So far, only build-tested for GCN, nvptx. Are these changes OK? What are exactly the semantics for '_GLIBCXX_THROW_OR_ABORT', should this evaluate its argument for '!__cpp_exceptions' or not? For example, compare to how 'gcc/system.h:gcc_checking_assert' gets defined so that "in release build EXPR is not evaluated". The other patches do similar to how '[[maybe_unused]]' appears to be used elsewhere, or should we rather '(void)' cast only in the specific '#if' regions where the variables are actually unused? Grüße Thomas
Re: [PATCH 4/4] libstdc++: Avoid '-Wunused-parameter' for 'out' in member function 'std::codecvt_base::result std::__format::{anonymous}::__encoding::conv(std::string_view, std::string&) const'
On Thu, 20 Feb 2025 at 16:59, Thomas Schwinge wrote:
>
> In a newlib configuration:
>
> ../../../../../source-gcc/libstdc++-v3/src/c++20/format.cc: In member
> function ‘std::codecvt_base::result
> std::__format::{anonymous}::__encoding::conv(std::string_view, std::string&)
> const’:
> ../../../../../source-gcc/libstdc++-v3/src/c++20/format.cc:100:35: error:
> unused parameter ‘out’ [-Werror=unused-parameter]
> 100 | conv(string_view input, string& out) const
> | ^~~
>
> libstdc++-v3/
> * src/c++20/format.cc (conv): Tag 'out' as '[[maybe_unused]]'.
OK
> ---
> libstdc++-v3/src/c++20/format.cc | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libstdc++-v3/src/c++20/format.cc
> b/libstdc++-v3/src/c++20/format.cc
> index 1a24fcab7f7..6967d53259d 100644
> --- a/libstdc++-v3/src/c++20/format.cc
> +++ b/libstdc++-v3/src/c++20/format.cc
> @@ -97,7 +97,7 @@ struct __encoding : locale::facet
>
>// Convert `input` to UTF-8, using `out` to hold the result.
>codecvt_base::result
> - conv(string_view input, string& out) const
> + conv(string_view input, [[maybe_unused]] string& out) const
>{
> if (input.empty()) [[unlikely]]
>return codecvt_base::noconv;
> --
> 2.34.1
>
Re: [PATCH 3/4] libstdc++: Avoid '-Wunused-parameter' for 'is_directory' in member function 'bool std::filesystem::__cxx11::_Dir::do_unlink(bool, std::error_code&) const'
On Thu, 20 Feb 2025 at 17:02, Thomas Schwinge wrote:
>
> In a newlib configuration:
>
> ../../../../../source-gcc/libstdc++-v3/src/c++17/fs_dir.cc: In member
> function ‘bool std::filesystem::__cxx11::_Dir::do_unlink(bool,
> std::error_code&) const’:
> ../../../../../source-gcc/libstdc++-v3/src/c++17/fs_dir.cc:147:18: error:
> unused parameter ‘is_directory’ [-Werror=unused-parameter]
> 147 | do_unlink(bool is_directory, error_code& ec) const noexcept
> | ~^~~~
>
> libstdc++-v3/
> * src/c++17/fs_dir.cc (do_unlink): Tag 'is_directory' as
> '[[maybe_unused]]'.
OK
> ---
> libstdc++-v3/src/c++17/fs_dir.cc | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libstdc++-v3/src/c++17/fs_dir.cc
> b/libstdc++-v3/src/c++17/fs_dir.cc
> index cd75e0541d3..9347a8a46dc 100644
> --- a/libstdc++-v3/src/c++17/fs_dir.cc
> +++ b/libstdc++-v3/src/c++17/fs_dir.cc
> @@ -144,7 +144,7 @@ struct fs::_Dir : _Dir_base
>}
>
>bool
> - do_unlink(bool is_directory, error_code& ec) const noexcept
> + do_unlink([[maybe_unused]] bool is_directory, error_code& ec) const
> noexcept
>{
> #if _GLIBCXX_HAVE_UNLINKAT
> const auto atp = current();
> --
> 2.34.1
>
[PATCH] i386: Quote user-defined symbols in assembly in Intel syntax
Hello,
This patch proposes a solution to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53929, and is
required by https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80881.
I have so far bootstrapped master on i686-w64-mingw32 with DWARF2 exception model, and on
x86_64-w64-mingw32 with SEH exception model, both patched to use Intel syntax by default. I have
also bootstrapped on x86_64-linux-gnu with default AT&T syntax, and verified that it produces
expected assembly with `-masm=intel`.
--
Best regards,
LIU Hao
From 07baacbc7de1f5dc5db9e834b030c1b642774a37 Mon Sep 17 00:00:00 2001
From: LIU Hao
Date: Thu, 20 Feb 2025 18:12:14 +0800
Subject: [PATCH] i386: Quote user-defined symbols in assembly in Intel syntax
With `-masm=intel`, GCC generates registers without % prefixes. If a
user-declared symbol happens to match a register, it will confuse the
assembler. User-defined symbols should be quoted, so they are not to
be mistaken for registers or operators.
Support for quoted symbols were added in Binutils 2.26, originally
for ARM assembly, where registers are also unprefixed:
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=d02603dc201f80cd9d2a1f4b1a16110b1e04222b
This change is required for `@SECREL32` to work in Intel syntax when
targeting Windows, where `@` is allowed as part of a symbol. GNU AS
fails to parse a plain symbol with that suffix:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80881#c79
gcc/config/:
PR target/53929
PR target/80881
* gcc/config/i386/i386-protos.h (ix86_asm_output_labelref): Declare new
function for quoting user-defined symbols in Intel syntax.
* gcc/config/i386/i386.cc (ix86_asm_output_labelref): Implement it.
* gcc/config/i386/i386.h (ASM_OUTPUT_LABELREF): Use it.
* gcc/config/i386/cygming.h (ASM_OUTPUT_LABELREF): Use it.
---
gcc/config/i386/cygming.h | 5 +++--
gcc/config/i386/i386-protos.h | 1 +
gcc/config/i386/i386.cc | 22 ++
gcc/config/i386/i386.h| 7 +++
4 files changed, 33 insertions(+), 2 deletions(-)
diff --git a/gcc/config/i386/cygming.h b/gcc/config/i386/cygming.h
index 3ddcbecb22fd..4a192900045a 100644
--- a/gcc/config/i386/cygming.h
+++ b/gcc/config/i386/cygming.h
@@ -247,9 +247,10 @@ do {
\
#undef ASM_OUTPUT_LABELREF
#define ASM_OUTPUT_LABELREF(STREAM, NAME) \
do { \
+ const char* prefix = ""; \
if ((NAME)[0] != FASTCALL_PREFIX)\
-fputs (user_label_prefix, (STREAM)); \
- fputs ((NAME), (STREAM));\
+prefix = user_label_prefix;\
+ ix86_asm_output_labelref ((STREAM), prefix, (NAME)); \
} while (0)
/* This does much the same in memory rather than to a stream. */
diff --git a/gcc/config/i386/i386-protos.h b/gcc/config/i386/i386-protos.h
index bea3fd4b2e2a..3b9e28ced91c 100644
--- a/gcc/config/i386/i386-protos.h
+++ b/gcc/config/i386/i386-protos.h
@@ -198,6 +198,7 @@ extern int ix86_attr_length_vex_default (rtx_insn *, bool,
bool);
extern rtx ix86_libcall_value (machine_mode);
extern bool ix86_function_arg_regno_p (int);
extern void ix86_asm_output_function_label (FILE *, const char *, tree);
+extern void ix86_asm_output_labelref (FILE *, const char *, const char *);
extern void ix86_call_abi_override (const_tree);
extern int ix86_reg_parm_stack_space (const_tree);
diff --git a/gcc/config/i386/i386.cc b/gcc/config/i386/i386.cc
index 3128973ba79c..6cbed7e4906e 100644
--- a/gcc/config/i386/i386.cc
+++ b/gcc/config/i386/i386.cc
@@ -1709,6 +1709,28 @@ ix86_asm_output_function_label (FILE *out_file, const
char *fname,
}
}
+/* Output a user-defined label. In AT&T syntax, registers are prefixed
+ with %, so labels require no punctuation. In Intel syntax, registers
+ are unprefixed, so labels may clash with registers or other operators,
+ and require quoting. */
+void
+ix86_asm_output_labelref (FILE *file, const char *prefix, const char *label)
+{
+ if (ASSEMBLER_DIALECT != ASM_INTEL)
+fprintf (file, "%s%s", prefix, label);
+ else
+{
+ /* When generating DWARF2 debug info, GCC may emit an expression
+like `label+42`, where only `label` shall be quoted. */
+ const char* op = strpbrk (label, "+-");
+ if (op == NULL)
+ fprintf (file, "\"%s%s\"", prefix, label);
+ else
+ fprintf (file, "\"%s%.*s\"%s",
+prefix, static_cast (op - label), label, op);
+}
+}
+
/* Implementation of call abi switching target hook. Specific to FNDECL
the specific call register sets are set. See also
ix86_conditional_register_usage for more details. */
diff --git a/gcc/config/i386/i386.h b/gcc/config/i386/i386.h
index 40b1aa4e6dfe..79a1afdde02c 100644
--- a/gcc/config/i386/i386.h
+++ b/gcc/config/i386/i386.h
@@ -2251,6 +2251,13 @@ extern unsigned int const
svr4_debugger_register_map
[pushed] aarch64: Remove old aarch64_expand_sve_vec_cmp_float code
While looking at PR118956, I noticed that we had some dead code
left over after the removal of the vcond patterns. The can_invert_p
path is no longer used.
Tested on aarch64-linux-gnu & pushed.
Richard
gcc/
* config/aarch64/aarch64-protos.h (aarch64_expand_sve_vec_cmp_float):
Remove can_invert_p argument and change return type to void.
* config/aarch64/aarch64.cc (aarch64_expand_sve_vec_cmp_float):
Likewise.
* config/aarch64/aarch64-sve.md (vec_cmp): Update call
accordingly.
---
gcc/config/aarch64/aarch64-protos.h | 2 +-
gcc/config/aarch64/aarch64-sve.md | 2 +-
gcc/config/aarch64/aarch64.cc | 36 -
3 files changed, 11 insertions(+), 29 deletions(-)
diff --git a/gcc/config/aarch64/aarch64-protos.h
b/gcc/config/aarch64/aarch64-protos.h
index 4235f4a0ca5..0291a8aa761 100644
--- a/gcc/config/aarch64/aarch64-protos.h
+++ b/gcc/config/aarch64/aarch64-protos.h
@@ -1098,7 +1098,7 @@ void aarch64_finish_ldpstp_peephole (rtx *, bool,
enum rtx_code = (enum rtx_code)0);
void aarch64_expand_sve_vec_cmp_int (rtx, rtx_code, rtx, rtx);
-bool aarch64_expand_sve_vec_cmp_float (rtx, rtx_code, rtx, rtx, bool);
+void aarch64_expand_sve_vec_cmp_float (rtx, rtx_code, rtx, rtx);
bool aarch64_prepare_sve_int_fma (rtx *, rtx_code);
bool aarch64_prepare_sve_cond_int_fma (rtx *, rtx_code);
diff --git a/gcc/config/aarch64/aarch64-sve.md
b/gcc/config/aarch64/aarch64-sve.md
index e975286a019..a93bc463a90 100644
--- a/gcc/config/aarch64/aarch64-sve.md
+++ b/gcc/config/aarch64/aarch64-sve.md
@@ -8495,7 +8495,7 @@ (define_expand "vec_cmp"
"TARGET_SVE"
{
aarch64_expand_sve_vec_cmp_float (operands[0], GET_CODE (operands[1]),
- operands[2], operands[3], false);
+ operands[2], operands[3]);
DONE;
}
)
diff --git a/gcc/config/aarch64/aarch64.cc b/gcc/config/aarch64/aarch64.cc
index f5f23f6ff4b..fe76730b0a7 100644
--- a/gcc/config/aarch64/aarch64.cc
+++ b/gcc/config/aarch64/aarch64.cc
@@ -26877,14 +26877,10 @@ aarch64_emit_sve_invert_fp_cond (rtx target, rtx_code
code, rtx pred,
/* Expand an SVE floating-point comparison using the SVE equivalent of:
- (set TARGET (CODE OP0 OP1))
-
- If CAN_INVERT_P is true, the caller can also handle inverted results;
- return true if the result is in fact inverted. */
+ (set TARGET (CODE OP0 OP1)). */
-bool
-aarch64_expand_sve_vec_cmp_float (rtx target, rtx_code code,
- rtx op0, rtx op1, bool can_invert_p)
+void
+aarch64_expand_sve_vec_cmp_float (rtx target, rtx_code code, rtx op0, rtx op1)
{
machine_mode pred_mode = GET_MODE (target);
machine_mode data_mode = GET_MODE (op0);
@@ -26902,16 +26898,14 @@ aarch64_expand_sve_vec_cmp_float (rtx target,
rtx_code code,
case GE:
case EQ:
case NE:
- {
- /* There is native support for the comparison. */
- aarch64_emit_sve_fp_cond (target, code, ptrue, true, op0, op1);
- return false;
- }
+ /* There is native support for the comparison. */
+ aarch64_emit_sve_fp_cond (target, code, ptrue, true, op0, op1);
+ return;
case LTGT:
/* This is a trapping operation (LT or GT). */
aarch64_emit_sve_or_fp_conds (target, LT, GT, ptrue, true, op0, op1);
- return false;
+ return;
case UNEQ:
if (!flag_trapping_math)
@@ -26920,7 +26914,7 @@ aarch64_expand_sve_vec_cmp_float (rtx target, rtx_code
code,
op1 = force_reg (data_mode, op1);
aarch64_emit_sve_or_fp_conds (target, UNORDERED, EQ,
ptrue, true, op0, op1);
- return false;
+ return;
}
/* fall through */
case UNLT:
@@ -26941,15 +26935,9 @@ aarch64_expand_sve_vec_cmp_float (rtx target, rtx_code
code,
code = NE;
else
code = reverse_condition_maybe_unordered (code);
- if (can_invert_p)
- {
- aarch64_emit_sve_fp_cond (target, code,
- ordered, false, op0, op1);
- return true;
- }
aarch64_emit_sve_invert_fp_cond (target, code,
ordered, false, op0, op1);
- return false;
+ return;
}
break;
@@ -26964,13 +26952,7 @@ aarch64_expand_sve_vec_cmp_float (rtx target, rtx_code
code,
/* There is native support for the inverse comparison. */
code = reverse_condition_maybe_unordered (code);
- if (can_invert_p)
-{
- aarch64_emit_sve_fp_cond (target, code, ptrue, true, op0, op1);
- return true;
-}
aarch64_emit_sve_invert_fp_cond (target, code, ptrue, true, op0, op1);
- return false;
}
/* Return true if:
--
2.25.1
Re: [PATCH 1/4] libstdc++: Avoid '-Wunused-parameter' for '__what' in function 'void std::__throw_format_error(const char*)'
On Thu, 20 Feb 2025 at 17:06, Thomas Schwinge wrote: > > In a '-fno-exceptions' configuration: > > In file included from > ../../../../../source-gcc/libstdc++-v3/src/c++20/format.cc:29: > [...]/build-gcc/[...]/libstdc++-v3/include/format: In function ‘void > std::__throw_format_error(const char*)’: > [...]/build-gcc/[...]/libstdc++-v3/include/format:200:36: error: unused > parameter ‘__what’ [-Werror=unused-parameter] > 200 | __throw_format_error(const char* __what) > |^~ > > libstdc++-v3/ > * include/bits/c++config [!__cpp_exceptions] > (_GLIBCXX_THROW_OR_ABORT): Reference '_EXC'. > --- > libstdc++-v3/include/bits/c++config | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/libstdc++-v3/include/bits/c++config > b/libstdc++-v3/include/bits/c++config > index b0ca6579cfb..e9782c03ee2 100644 > --- a/libstdc++-v3/include/bits/c++config > +++ b/libstdc++-v3/include/bits/c++config > @@ -253,7 +253,7 @@ > # if __cpp_exceptions > # define _GLIBCXX_THROW_OR_ABORT(_EXC) (throw (_EXC)) > # else > -# define _GLIBCXX_THROW_OR_ABORT(_EXC) (__builtin_abort()) > +# define _GLIBCXX_THROW_OR_ABORT(_EXC) ((void) (_EXC), __builtin_abort()) We don't want to evaluate _EXC before aborting. There's no reason to e.g. concatenate strings and allocate memory to do so, or copy filesystem::path objects into a filesystem::filesystem_error that will never be thrown, or obtain a reference to an error_category. I don't think we want/need this at all, but it could be done like this if we need _EXC to be present but unused: # define _GLIBCXX_THROW_OR_ABORT(_EXC) (__builtin_abort(), (void)(_EXC))
Fix 'libstdc++-v3/src/c++20/tzdb.cc' build for '__GTHREADS && !__GTHREADS_CXX0X' configurations (was: libstdc++: '_GLIBCXX_HAS_GTHREADS' -- '__GTHREADS' vs. '__GTHREADS_CXX0X')
Hi!
On 2025-02-20T16:36:56+, Jonathan Wakely wrote:
> On 20/02/25 15:50 +0100, Thomas Schwinge wrote:
>>From 820e015494e25187c9a5ffbd69911ec6ce612789 Mon Sep 17 00:00:00 2001
>>From: Jonathan Wakely
>>Date: Thu, 20 Feb 2025 14:08:11 +
>>Subject: [PATCH] Fix 'libstdc++-v3/src/c++20/tzdb.cc' build for '__GTHREADS &&
>> !__GTHREADS_CXX0X' configurations
>>
>> libstdc++-v3/
>> * src/c++20/tzdb.cc [__GTHREADS && !__GTHREADS_CXX0X]: Use
>> '__gnu_cxx::__mutex'.
>>
>>Co-authored-by: Thomas Schwinge
>>---
>> libstdc++-v3/src/c++20/tzdb.cc | 8 +++-
>> 1 file changed, 7 insertions(+), 1 deletion(-)
>>
>>diff --git a/libstdc++-v3/src/c++20/tzdb.cc b/libstdc++-v3/src/c++20/tzdb.cc
>>index 7e8cce7ce8c..70ba7b0ef53 100644
>>--- a/libstdc++-v3/src/c++20/tzdb.cc
>>+++ b/libstdc++-v3/src/c++20/tzdb.cc
>>@@ -35,6 +35,9 @@
>> #include // atomic, atomic
>> #include // atomic>
>> #include // mutex
>>+#if defined __GTHREADS && ! defined _GLIBCXX_HAS_GHTREADS
>>+# include // __gnu_cxx::__mutex
>>+#endif
>> #include // filesystem::read_symlink
>>
>> #ifndef _AIX
>>@@ -97,11 +100,14 @@ namespace std::chrono
>> {
>> namespace
>> {
>>-#if ! USE_ATOMIC_SHARED_PTR
>> #ifndef __GTHREADS
>> // Dummy no-op mutex type for single-threaded targets.
>> struct mutex { void lock() { } void unlock() { } };
>>+#elif ! defined _GLIBCXX_HAS_GHTREADS
>
> This still has my GHTREADS typo.
Eh. I had fixed that, but apparently lost it. Re-fixed.
> A comment here would be good too:
>
> // Use __gnu_cxx::__mutex is std::mutex isn't available.
Added.
>>+using mutex = __gnu_cxx::__mutex;
>> #endif
>>+
>>+#if ! USE_ATOMIC_SHARED_PTR
>> inline mutex& list_mutex()
>> {
>> #ifdef __GTHREAD_MUTEX_INIT
>
> Strictly speaking, we also need a change here, because unlike
> std::mutex, __gnu_cxx::__mutex can't be initialized with `constinit`.
> But that can wait, because it's not needed for your configuration.
I've added an '#error' for such a configuration. (But happy to drop, if
you think that's overkill.)
Please see v2 of
"Fix 'libstdc++-v3/src/c++20/tzdb.cc' build for '__GTHREADS &&
!__GTHREADS_CXX0X' configurations"
attached. Still only GCN, nvptx build-tested.
Grüße
Thomas
>From 229e4d57fcfd036f37ad210b1780b6272dc5acd2 Mon Sep 17 00:00:00 2001
From: Jonathan Wakely
Date: Thu, 20 Feb 2025 14:08:11 +
Subject: [PATCH] Fix 'libstdc++-v3/src/c++20/tzdb.cc' build for '__GTHREADS &&
!__GTHREADS_CXX0X' configurations
libstdc++-v3/
* src/c++20/tzdb.cc [__GTHREADS && !__GTHREADS_CXX0X]: Use
'__gnu_cxx::__mutex'.
Co-authored-by: Thomas Schwinge
---
libstdc++-v3/src/c++20/tzdb.cc | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/libstdc++-v3/src/c++20/tzdb.cc b/libstdc++-v3/src/c++20/tzdb.cc
index 7e8cce7ce8c..e9eaf017690 100644
--- a/libstdc++-v3/src/c++20/tzdb.cc
+++ b/libstdc++-v3/src/c++20/tzdb.cc
@@ -35,6 +35,9 @@
#include // atomic, atomic
#include // atomic>
#include // mutex
+#if defined __GTHREADS && ! defined _GLIBCXX_HAS_GTHREADS
+# include // __gnu_cxx::__mutex
+#endif
#include // filesystem::read_symlink
#ifndef _AIX
@@ -97,11 +100,18 @@ namespace std::chrono
{
namespace
{
-#if ! USE_ATOMIC_SHARED_PTR
#ifndef __GTHREADS
// Dummy no-op mutex type for single-threaded targets.
struct mutex { void lock() { } void unlock() { } };
+#elif ! defined _GLIBCXX_HAS_GTHREADS
+// Use __gnu_cxx::__mutex is std::mutex isn't available.
+using mutex = __gnu_cxx::__mutex;
+# if ! USE_ATOMIC_SHARED_PTR && defined __GTHREAD_MUTEX_INIT
+# error "TODO: __gnu_cxx::__mutex can't be initialized with 'constinit'"
+# endif
#endif
+
+#if ! USE_ATOMIC_SHARED_PTR
inline mutex& list_mutex()
{
#ifdef __GTHREAD_MUTEX_INIT
--
2.34.1
Re: Fix 'libstdc++-v3/src/c++20/tzdb.cc' build for '__GTHREADS && !__GTHREADS_CXX0X' configurations (was: libstdc++: '_GLIBCXX_HAS_GTHREADS' -- '__GTHREADS' vs. '__GTHREADS_CXX0X')
On Thu, 20 Feb 2025 at 17:28, Thomas Schwinge wrote:
>
> Hi!
>
> On 2025-02-20T16:36:56+, Jonathan Wakely wrote:
> > On 20/02/25 15:50 +0100, Thomas Schwinge wrote:
> >>From 820e015494e25187c9a5ffbd69911ec6ce612789 Mon Sep 17 00:00:00 2001
> >>From: Jonathan Wakely
> >>Date: Thu, 20 Feb 2025 14:08:11 +
> >>Subject: [PATCH] Fix 'libstdc++-v3/src/c++20/tzdb.cc' build for '__GTHREADS
> >>&&
> >> !__GTHREADS_CXX0X' configurations
> >>
> >> libstdc++-v3/
> >> * src/c++20/tzdb.cc [__GTHREADS && !__GTHREADS_CXX0X]: Use
> >> '__gnu_cxx::__mutex'.
> >>
> >>Co-authored-by: Thomas Schwinge
> >>---
> >> libstdc++-v3/src/c++20/tzdb.cc | 8 +++-
> >> 1 file changed, 7 insertions(+), 1 deletion(-)
> >>
> >>diff --git a/libstdc++-v3/src/c++20/tzdb.cc b/libstdc++-v3/src/c++20/tzdb.cc
> >>index 7e8cce7ce8c..70ba7b0ef53 100644
> >>--- a/libstdc++-v3/src/c++20/tzdb.cc
> >>+++ b/libstdc++-v3/src/c++20/tzdb.cc
> >>@@ -35,6 +35,9 @@
> >> #include // atomic, atomic
> >> #include // atomic>
> >> #include // mutex
> >>+#if defined __GTHREADS && ! defined _GLIBCXX_HAS_GHTREADS
> >>+# include // __gnu_cxx::__mutex
> >>+#endif
> >> #include // filesystem::read_symlink
> >>
> >> #ifndef _AIX
> >>@@ -97,11 +100,14 @@ namespace std::chrono
> >> {
> >> namespace
> >> {
> >>-#if ! USE_ATOMIC_SHARED_PTR
> >> #ifndef __GTHREADS
> >> // Dummy no-op mutex type for single-threaded targets.
> >> struct mutex { void lock() { } void unlock() { } };
> >>+#elif ! defined _GLIBCXX_HAS_GHTREADS
> >
> > This still has my GHTREADS typo.
>
> Eh. I had fixed that, but apparently lost it. Re-fixed.
>
> > A comment here would be good too:
> >
> > // Use __gnu_cxx::__mutex is std::mutex isn't available.
>
> Added.
>
> >>+using mutex = __gnu_cxx::__mutex;
> >> #endif
> >>+
> >>+#if ! USE_ATOMIC_SHARED_PTR
> >> inline mutex& list_mutex()
> >> {
> >> #ifdef __GTHREAD_MUTEX_INIT
> >
> > Strictly speaking, we also need a change here, because unlike
> > std::mutex, __gnu_cxx::__mutex can't be initialized with `constinit`.
> > But that can wait, because it's not needed for your configuration.
>
> I've added an '#error' for such a configuration. (But happy to drop, if
> you think that's overkill.)
That's great, thanks.
No existing targets should be broken by that new #error, because they
would be failing to build already.
>
> Please see v2 of
> "Fix 'libstdc++-v3/src/c++20/tzdb.cc' build for '__GTHREADS &&
> !__GTHREADS_CXX0X' configurations"
> attached. Still only GCN, nvptx build-tested.
OK for trunk if testing goes well.
Is this needed for gcc-14 too?
Re: [PATCH v2] ira: Add a target hook for callee-saved register cost scale
> > Thanks for running these. I saw poor results for perlbench with my > initial aarch64 hooks because the hooks reduced the cost to zero for > the entry case: > > auto entry_cost = targetm.callee_save_cost > (spill_cost_type::SAVE, hard_regno, mode, saved_nregs, > ira_memory_move_cost[mode][rclass][0] * saved_nregs / nregs, > allocated_callee_save_regs, existing_spills_p); > /* In the event of a tie between caller-save and callee-save, > prefer callee-save. We apply this to the entry cost rather > than the exit cost since the entry frequency must be at > least as high as the exit frequency. */ > if (entry_cost > 0) > entry_cost -= 1; > > I "fixed" that by bumping the cost to a minimum of 2, but I was > wondering whether the "entry_cost > 0" should instead be "entry_cost > 1", > so that the cost is always greater than not using a callee save for > registers that don't cross a call. WDYT? For x86 perfomance costs, the push cost should be memory_move_cost which is 6, -2 for adjustment in the target hook and -1 for this. So cost should not be 0 I think. For size cost, I currently return 1, so we indeed get 0 after adjustment. I think cost of 0 will make us to pick callee save even if caller save is available and there are no function calls, so I guess we do not want that Honza
Re: [Patch] Fortran: Improve gfc_array_kind for assumed rank; gfc_tree_array_size on 'tree'
Just to be clear: the following touches generic Fortran code and, hence,
needs Fortran FE review (still pending):
Tobias Burnus wrote:
(1) gfc_tree_array_size now can determine the array size not only from
the passed Fortran gfc_expr but also using a descriptor, passed as
gimple 'tree'.
(2) Adds missing GFC_ARRAY_ASSUMED_RANK_{ALLOCATABLE,POINTER{,_CONT}} […]
OK for mainline?
While changes to OpenMP-specific code in gfortran, it can be either
OpenMP or Fortran approval.* – In any case, code review is always
welcome, whether required or not, whether done by an approved
reviewer/maintainer or simple bystanders!
Tobias
(* Fortran only has reviewers (as some other parts of the compiler);
while other code parts have maintainers. The difference is whether one
can approve one own's patch or not. See MAINTAINERS for details.)
Re: libstdc++: Avoid '-Wunused-parameter's
On Thu, 20 Feb 2025 at 17:06, Thomas Schwinge wrote: > > Hi! > > In the following, a few patches for libstdc++ to avoid > '-Wunused-parameter' diagnostics (actually '-Werror=unused-parameter', > for my '--enable-werror' builds). So far, only build-tested for GCN, > nvptx. Are these changes OK? > > What are exactly the semantics for '_GLIBCXX_THROW_OR_ABORT', should this > evaluate its argument for '!__cpp_exceptions' or not? For example, > compare to how 'gcc/system.h:gcc_checking_assert' gets defined so that > "in release build EXPR is not evaluated". See my comment on that patch. I don't see any reason to evaluate the argument, and I've written code using that macro which very definitely assumes it *won't* be evaluated. > The other patches do similar to how '[[maybe_unused]]' appears to be used > elsewhere, or should we rather '(void)' cast only in the specific '#if' > regions where the variables are actually unused? No, [[maybe_unused]] is the right fix.
Re: [Patch] Fortran: Improve gfc_array_kind for assumed rank; gfc_tree_array_size on 'tree'
On 2/19/25 10:08 AM, Tobias Burnus wrote:
The attached patch does some ground-laying work for OpenMP
deep mapping - touching common gfortran code.
It does so by:
(1)gfc_tree_array_size now can determine the array size not only from
the passed Fortran gfc_expr but also using a descriptor, passed as
gimple 'tree'.
(2) Adds missingGFC_ARRAY_ASSUMED_RANK_{ALLOCATABLE,POINTER{,_CONT}} to
enum gfc_array_kind to complete the kinds – for non-assumed-rank, those
subtypes already existed, for assumed rank, the pointer/allocatable
flags were missing (and for pointer: contiguous, while allocatables are
always contigous).
Build and regtested on x86-64_gnu-linux.
OK for mainline?
Looks good Tobias. I don't know if anyone else was looking through it.
Jerry
* * *
When doing the change (2) back when I first created the patch, I
encountered an issue, which I could not fix quickly. Hence, I filed
https://gcc.gnu.org/PR104651 - see also the FIXME in the code which
should be IMHO be used but it causes fails. Although, the proper fix is
probably to change how CLASS/attributes in it are represented (cf. PR).
[I don't recall the details - and don't know more anymore than what's
in the FIXME comment and in the problem report.]
* * *
BACKGROUND/EXAMPLE
-> OpenMP + derived-type mapping with allocatable components
(i.e. why I need the modifications; for those changes, I will also
add testcases.)
Namely, assume:
type t
real, allocatable :: x(:)
real, pointer :: p(:)
end type t
type(t) :: var(4)
!$omp target enter data map(to:var)
This is supposed to copy 'var' onto an offloading device
(device = omp_get_default_device()) - by doing a deep
copying/mapping. Thus, the compiler needs to generate code
like - pseudocode:
map (to: var [size: 4*storage_size(type(t))])
for i = 1 to 4:
if (allocated (var(i)%x)
map (to: var(i)%x [size: size(var(i)%x) * sizeof(real)])
[plus attaching the just mapped data to the base_addr
of the array descriptor.]
Namely: var and also var(:)%x have to be copied to the device,
var(:)%p is not touched – as it is a pointer and not an allocatable.
Another example would be:
!$omp target
var(1)%x(2) = 7
!$omp end target
where 'map(tofrom:var)' is implicitly added, which happens
quite late in the game. Thus, the code handles the mapping
both by explicit and implicit mapping and does so very late.
(omp-low.cc calls back to the Fortran front-end to do the
work.)
* * *
Soon/next, I will post the patch that handles code above (for
nonpolymorphic allocatable components). However, if you want to
glance at the code, already you can find an older version at
* https://gcc.gnu.org/pipermail/gcc-patches/2022-March/591144.html
And a re-based commit relative to GCC 14, applied to OG14
(devel/omp/gcc-14) at https://gcc.gnu.org/g:92c3af3d4f8
(or 'git log ' or 'git log devel/omp/gcc-14' in any of
your GCC repos).
Note that the to-be-posted patch will differ a bit as:
- the middle end bits are already in
- the CLASS/polymorphic handling will be removed.
- minor cleanup/fixes
Reason for not including polymorphism support:
* As the vtab is not handled, there is no benefit of having it.
Additionally, the patch changes what's in the vtable/vtab by
adding an entry, breaking all backward compatibility of vtabs.
Thus, I only want to add it when it works properly.
* On the OpenMP spec side, it is similar: OpenMP 6.0 clarified
that mapping polymorphic variables in Fortran is not supported
(5.x was unclear) but it added full support for shared-memory
part (data sharing clauses). Plus there is on-going work to
add polymorphism support to OpenMP 6.1.
[For 6.1, parts of the GCC polymorphism patch will be resurrected
in some way, but for now not having polymorphism is simply better!]
* * *
Tobias
Re: [PATCH] COBOL 3/15 92K bld: config and build machinery
> On Feb 19, 2025, at 8:18 PM, James K. Lowden wrote: > > On Wed, 19 Feb 2025 12:55:03 +0100 > Matthias Klose wrote: > >> libgcobol/ChangeLog >> * Makefile.in: New file. >> * acinclude.m4: New file. >> * aclocal.m4: New file. >> * configure.ac: New file. >> * configure.tgt: New file. >> >> I had updated the configure.tgt, please find it attached here again. > > It seems we missed your updated patch and invented our own solution, such as > it is. Sorry for the misunderstanding. I certainly never meant to ignore > you. > > We know we're currently being too restrictive by limiting host and target to > x86_64 and aarch64. But your patch as supplied is also insufficient, so we > attempted to generalize it. > > I would like to do this in a way you approve of. Let me lay out the > requirements as of today. For both host and target: > > 1. support for _Float128 > 2. support for __int128 I understand a target requirement if you need to generate code that uses that datatype. But why a host requirement? For floating point arithmetic at compile time, there is the GCC internal "real" component, which offers host-independent floating point arithmetic. One of the reasons that exists is to allow compile-time arithmetic for targets that have a wider float range than the host (say, VAX vs. IEEE), but it should also enable high precision floating point operations inside GCC without caring what width floating point is native to the host. paul
Re: 6/7 [Fortran, Patch, Coarray, PR107635] Add transfer_between_remotes
Hi Andre, this patch broke Solaris bootstrap: /vol/gcc/src/hg/master/local/libgfortran/caf/single.c: In function ‘_gfortran_caf_transfer_between_remotes’: /vol/gcc/src/hg/master/local/libgfortran/caf/single.c:675:23: error: implicit declaration of function ‘alloca’ [-Wimplicit-function-declaration] 675 | transfer_desc = alloca (desc_size); | ^~ /vol/gcc/src/hg/master/local/libgfortran/caf/single.c:675:23: warning: incompatible implicit declaration of built-in function ‘alloca’ [-Wbuiltin-declaration-mismatch] /vol/gcc/src/hg/master/local/libgfortran/caf/single.c:680:20: warning: incompatible implicit declaration of built-in function ‘alloca’ [-Wbuiltin-declaration-mismatch] 680 | transfer_ptr = alloca (*opt_dst_charlen * src_size); |^~ make[3]: *** [Makefile:4675: caf/single.lo] Error 1 Solaris needs to include to get an alloca declaration. While this could be handled with AC_FUNC_ALLOCA (like libcpp does) or checking for alloca.h and including it if found (like libssp does), I guess there's a simpler way: several runtime libs use __builtin_alloca unconditionally (libgcc, libquadmath, libstdc++-v3). Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: The COBOL front end, version 3, now in 14 easy pieces (+NIST)
On Thu, 20 Feb 2025 11:38:58 +0100
Richard Biener wrote:
> Can you clarify on the future development model for Cobol after it has
> been merged? Is the cobolworx gitlab still going to be the primary
> development location and changes should be made there and then merged
> to the GCC side?
I would like the future development model for Cobol to be convenient
for all involved. If we don't change anything then, yes, we'll keep
using our cobolworx gitlab server. But we don't insist on that. From
our point of view, one git server is as good as another. That's what
peer-to-peer is all about, right? We can use gcc's git as the primary,
and mirror that ourselves, if that's what you're suggesting.
Branches in git don't have independent permissions. If we use
gcc.gnu.org git, are we granted commit rights with the priviso that we
color inside the lines, and commit only to our own branches?
> The most important part for GCC 15 will be documentation to get
> user expectancy right.
Absolutely, that's in everyone's interest.
> Having a minimal harness in GCCs testsuite is critical - I'd expect a
> gcc/testsuite/gcobol.dg/dg.exp supporting execution tests. I assume
> Cobol has a way to exit OK or fatally and this should be
> distinguished as testsuite PASS or FAIL.
Yes, a COBOL program exits with a return status. And we rigged up NIST
to do that. What that means requires a long explanation, sorry.
NIST Is highly configurable within its envelope. It generates most of
its inputs, and a configuration process controls the names of the data
files. (There is also a substitution capability to adapt the COBOL
source to the compiler.) The "configuration process" is itself a COBOL
program called EXEC85. It reads the source archive and produces
modified COBOL programs for compilation and execution.
NIST as we use it comprises 12 modules covering different aspects
of COBOL. Each module is designated a 2-letter prefix, NC for "NIST
core", IX for "Indexed I/O", etc. We create one directory per module.
Each module has ~100 programs, each with many tests. Some programs
must be run in a fixed order because they produce and process files in
series.
Each program simply runs and reports its tests' results to a file (which
could be stdout, but isn't in our setup). The program always exits
normally unless it crashes, of course. Test failures are indicated by
"FAIL*" in the report.
As it's set up now in our CI/CD, NIST lives in its own subdirectory,
gcc/cobol/nist. There we have two critical files: Makefile (900
lines) and report.awk (56 lines). In each module's directory we also
maintain any configuration inputs to EXEC85. In nist/NC, for example,
we have NC109M.conf and NC204M.conf.
The Makefile fetches the NIST archive from our website. (We originally
got it from NIST, but their site was reorganized last year. The file
went missing, as apparently did my email to the webmaster.
Technology!) The file might have 100 targets to run various bits. For
gcc's purpose, only one matters: "make report".
That target:
1. fetches the archive
2. extracts & patches EXEC85.cbl
3. compiles to produce EXEC85
4. runs EXEC85 against the archive to extract modified COBOL
test programs.
5. compiles the programs
6. runs each program, producing a .rpt file for each one
7. trundles over each .rpt file with report.awk searching for failures
Because the process is run under make(1), steps 2-6 run in parallel, N
jobs for -j N. If there are no failures, report.awk returns 0 to make,
else 1. Start to end, it takes just a few minutes on a fast machine.
Now you know what I know, and I need to know what you know.
> I'm not sure if /* { dg-... } */ directive support is easy or
> desirable (well, desirable for sure). I'd be happy with a setup like
> the old gcc.c-torture/{execute,compile}. Possibly tcl/shell wrapping
> around the NIST tests (even if not included in the GCC tree, running
> that by unpacking it in gcc/testsuite/gcobol/nist would be nice).
I don't understand most of that. I think you would like to use
DejaGnu, and I think we can get there. One hurdle is that I've never
used that software.
I suggest a 2-phase process, one expedient and the other long term.
1. For now, keep the above intact, and put it where it belongs, wired
up with the least possible glue (to mix metaphors). That will work,
and more than meet the "minimal" threshold.
2. Modify the above to run each test file under DejaGnu. It's my
understanding DG uses Tcl and expect(1). (The last time I used that
program was with tip(1). There was a Hayes Smartmodem involved.) We
know what good output looks like. Be advised, it is voluminous.
We can use DG instead of awk to compare results.
There's also a Step 0. We need to agree on what to do about the
documentation and the NIST source code archive. Do they go in the
repository or are they hosted externally and, if so, where?
I sincerely believe gcc users are
[PATCH] Fortran: initialize non-saved pointers with -fcheck=pointer [PR48958]
Dear all,
the attached simple patch addresses a small, left-over issue in the
above PR and was already OK'ed in the PR by Thomas. With it we
initialize the data component of a non-saved pointer variable when
-fcheck=pointer is specified, so that subsequent pointer checks
(e.g. for the SIZE intrinsic) trigger consistently and not randomly.
I plan to commit within 24h unless there are comments.
Regtested on x86_64-pc-linux-gnu. ON for mainline?
Thanks,
Harald
From eca02da7cfa3781727dfd1a0914b7d9d377b1511 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Thu, 20 Feb 2025 21:03:12 +0100
Subject: [PATCH] Fortran: initialize non-saved pointers with -fcheck=pointer
[PR48958]
PR fortran/48958
gcc/fortran/ChangeLog:
* trans-array.cc (gfc_trans_deferred_array): Initialized the data
component of non-saved pointers when -fcheck=pointer is set.
gcc/testsuite/ChangeLog:
* gfortran.dg/pointer_init_13.f90: New test.
---
gcc/fortran/trans-array.cc| 7 --
gcc/testsuite/gfortran.dg/pointer_init_13.f90 | 24 +++
2 files changed, 29 insertions(+), 2 deletions(-)
create mode 100644 gcc/testsuite/gfortran.dg/pointer_init_13.f90
diff --git a/gcc/fortran/trans-array.cc b/gcc/fortran/trans-array.cc
index ec627dddffd..27378c432f7 100644
--- a/gcc/fortran/trans-array.cc
+++ b/gcc/fortran/trans-array.cc
@@ -12122,8 +12122,11 @@ gfc_trans_deferred_array (gfc_symbol * sym, gfc_wrapped_block * block)
type = TREE_TYPE (descriptor);
}
- /* NULLIFY the data pointer, for non-saved allocatables. */
- if (GFC_DESCRIPTOR_TYPE_P (type) && !sym->attr.save && sym->attr.allocatable)
+ /* NULLIFY the data pointer for non-saved allocatables, or for non-saved
+ pointers when -fcheck=pointer is specified. */
+ if (GFC_DESCRIPTOR_TYPE_P (type) && !sym->attr.save
+ && (sym->attr.allocatable
+ || (sym->attr.pointer && (gfc_option.rtcheck & GFC_RTCHECK_POINTER
{
gfc_conv_descriptor_data_set (&init, descriptor, null_pointer_node);
if (flag_coarray == GFC_FCOARRAY_LIB && sym->attr.codimension)
diff --git a/gcc/testsuite/gfortran.dg/pointer_init_13.f90 b/gcc/testsuite/gfortran.dg/pointer_init_13.f90
new file mode 100644
index 000..ece423a9db6
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/pointer_init_13.f90
@@ -0,0 +1,24 @@
+! { dg-do compile }
+! { dg-options "-fcheck=pointer -fdump-tree-optimized -O -fno-inline" }
+!
+! PR fortran/48958
+!
+! Initialize non-saved pointers with -fcheck=pointer to support runtime checks
+! of uses of possibly undefined pointers
+
+program p
+ implicit none
+ call s
+contains
+ subroutine s
+integer, pointer :: a(:)
+integer, pointer :: b(:) => NULL()
+if (size (a) /= 0) stop 1
+if (size (b) /= 0) stop 2
+print *, size (a)
+print *, size (b)
+ end
+end
+
+! { dg-final { scan-tree-dump-times "_gfortran_runtime_error_at" 1 "optimized" } }
+! { dg-final { scan-tree-dump-not "_gfortran_stop_numeric" "optimized" } }
--
2.43.0
[PATCH] i386: Fix pr101950-2.c [PR115028]
So what is happening here is that after r15-268-g9dbff9c05520a7,
a move instruction still exists after combine and the register
allocator choses different register allocation order for the xor
and because the input operand of lzcntq is not the same as output
operand, there is an extra xor that happens (due to an errata).
This fixes the testcase by using loading from a pointer instead
of a function argument directly. The register allocator has more
freedom since the load has no hard register associated with it (rdi)
so it can be in eax register right away.
Tested for both -m32 and -m64 on x86_64-linux-gnu.
gcc/testsuite/ChangeLog:
PR testsuite/115028
* gcc.target/i386/pr101950-2.c:
Signed-off-by: Andrew Pinski
---
gcc/testsuite/gcc.target/i386/pr101950-2.c | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/gcc/testsuite/gcc.target/i386/pr101950-2.c
b/gcc/testsuite/gcc.target/i386/pr101950-2.c
index 896f1b46414..ccc361e3a46 100644
--- a/gcc/testsuite/gcc.target/i386/pr101950-2.c
+++ b/gcc/testsuite/gcc.target/i386/pr101950-2.c
@@ -6,14 +6,19 @@
/* { dg-final { scan-assembler-times "\txor\[ql]\t" 2 } } */
/* { dg-final { scan-assembler-times "\tsar\[ql]\t|\tcltd" 2 } } */
+/* Use pointers to avoid register allocation difference due to argument
+ and return register being different and the difference in selecting eax
+ for one the result of the xor vs selecting rdi due to the order of the
+ shift vs the not shift. */
+
int
-foo (long x)
+foo (long *x)
{
- return __builtin_clrsbl (x);
+ return __builtin_clrsbl (*x);
}
int
-bar (int x)
+bar (int *x)
{
- return __builtin_clrsb (x);
+ return __builtin_clrsb (*x);
}
--
2.43.0
RE: [PATCH] COBOL 3/15 92K bld: config and build machinery
> -Original Message- > From: Paul Koning > Sent: Thursday, February 20, 2025 13:22 > To: James K. Lowden > Cc: Matthias Klose ; gcc-patches@gcc.gnu.org > Subject: Re: [PATCH] COBOL 3/15 92K bld: config and build machinery > > > > > On Feb 19, 2025, at 8:18 PM, James K. Lowden > wrote: > > > > On Wed, 19 Feb 2025 12:55:03 +0100 > > Matthias Klose wrote: > > > >> libgcobol/ChangeLog > >> * Makefile.in: New file. > >> * acinclude.m4: New file. > >> * aclocal.m4: New file. > >> * configure.ac: New file. > >> * configure.tgt: New file. > >> > >> I had updated the configure.tgt, please find it attached here again. > > > > It seems we missed your updated patch and invented our own solution, > such as it is. Sorry for the misunderstanding. I certainly never meant > to ignore you. > > > > We know we're currently being too restrictive by limiting host and > target to x86_64 and aarch64. But your patch as supplied is also > insufficient, so we attempted to generalize it. > > > > I would like to do this in a way you approve of. Let me lay out the > requirements as of today. For both host and target: > > > > 1. support for _Float128 > > 2. support for __int128 > > I understand a target requirement if you need to generate code that uses > that datatype. But why a host requirement? For floating point arithmetic > at compile time, there is the GCC internal "real" component, which offers > host-independent floating point arithmetic. One of the reasons that > exists is to allow compile-time arithmetic for targets that have a wider > float range than the host (say, VAX vs. IEEE), but it should also enable > high precision floating point operations inside GCC without caring what > width floating point is native to the host. > > paul For the simple reason that I didn't know about them when I wrote the code. Switching over to real.h and wide-int.h will be a priority for me, going forward. Thanks very much, Bob Dubner
[PATCH 2/4] libstdc++: Avoid '-Wunused-parameter' for 'nofollow' in static member function 'static std::filesystem::__gnu_posix::DIR* std::filesystem::_Dir_base::openat(const _At_path&, bool)'
In a newlib configuration:
In file included from
../../../../../source-gcc/libstdc++-v3/src/c++17/fs_dir.cc:37,
from
../../../../../source-gcc/libstdc++-v3/src/c++17/cow-fs_dir.cc:26:
../../../../../source-gcc/libstdc++-v3/src/c++17/../filesystem/dir-common.h: In
static member function ‘static std::filesystem::__gnu_posix::DIR*
std::filesystem::_Dir_base::openat(const _At_path&, bool)’:
../../../../../source-gcc/libstdc++-v3/src/c++17/../filesystem/dir-common.h:210:36:
error: unused parameter ‘nofollow’ [-Werror=unused-parameter]
210 | openat(const _At_path& atp, bool nofollow)
| ~^~~~
libstdc++-v3/
* src/filesystem/dir-common.h (openat): Tag 'nofollow' as
'[[maybe_unused]]'.
---
libstdc++-v3/src/filesystem/dir-common.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libstdc++-v3/src/filesystem/dir-common.h
b/libstdc++-v3/src/filesystem/dir-common.h
index 5ff621c3380..c7d4bc4e6ed 100644
--- a/libstdc++-v3/src/filesystem/dir-common.h
+++ b/libstdc++-v3/src/filesystem/dir-common.h
@@ -207,7 +207,7 @@ struct _Dir_base
}
static posix::DIR*
- openat(const _At_path& atp, bool nofollow)
+ openat(const _At_path& atp, [[maybe_unused]] bool nofollow)
{
#if _GLIBCXX_HAVE_FDOPENDIR && defined O_RDONLY && defined O_DIRECTORY \
&& ! _GLIBCXX_FILESYSTEM_IS_WINDOWS
--
2.34.1
[PATCH] RISC-V: Minimal support for Qualcomm uC Xqccmp extension.
This patch support Qualcomm uC Xqccmp extension[1].
To enable GCC to recognize and process xqccmp extension correctly at compile
time.
[1]https://github.com/quic/riscv-unified-db/releases/tag/Xqccmp_extension-0.1.0
gcc/ChangeLog:
* common/config/riscv/riscv-common.cc: New extension.
* common/config/riscv/riscv-ext-bitmask.def (RISCV_EXT_BITMASK): Ditto.
* config/riscv/riscv.opt: Ditto.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/arch-45.c: New test.
---
gcc/common/config/riscv/riscv-common.cc | 6 ++
gcc/common/config/riscv/riscv-ext-bitmask.def | 1 +
gcc/config/riscv/riscv.opt| 5 +
gcc/testsuite/gcc.target/riscv/arch-45.c | 5 +
4 files changed, 17 insertions(+)
create mode 100644 gcc/testsuite/gcc.target/riscv/arch-45.c
diff --git a/gcc/common/config/riscv/riscv-common.cc
b/gcc/common/config/riscv/riscv-common.cc
index 5038f0eb959a..6fbdb5ed2316 100644
--- a/gcc/common/config/riscv/riscv-common.cc
+++ b/gcc/common/config/riscv/riscv-common.cc
@@ -229,6 +229,8 @@ static const riscv_implied_info_t riscv_implied_info[] =
{"xsfvcp", "zve32x"},
+ {"xqccmp", "zca"},
+
{NULL, NULL}
};
@@ -442,6 +444,8 @@ static const struct riscv_ext_version
riscv_ext_version_table[] =
{"xsfvqmaccdod",ISA_SPEC_CLASS_NONE, 1, 0},
{"xsfvfnrclipxfqf", ISA_SPEC_CLASS_NONE, 1, 0},
+ {"xqccmp", ISA_SPEC_CLASS_NONE, 0, 1},
+
/* Terminate the list. */
{NULL, ISA_SPEC_CLASS_NONE, 0, 0}
};
@@ -1778,6 +1782,8 @@ static const riscv_ext_flag_table_t
riscv_ext_flag_table[] =
RISCV_EXT_FLAG_ENTRY ("xsfvqmaccdod",x_riscv_sifive_subext,
MASK_XSFVQMACCDOD),
RISCV_EXT_FLAG_ENTRY ("xsfvfnrclipxfqf", x_riscv_sifive_subext,
MASK_XSFVFNRCLIPXFQF),
+ RISCV_EXT_FLAG_ENTRY ("xqccmp", x_riscv_qc_subext, MASK_XQCCMP),
+
{NULL, NULL, NULL, 0}
};
diff --git a/gcc/common/config/riscv/riscv-ext-bitmask.def
b/gcc/common/config/riscv/riscv-ext-bitmask.def
index 8b4e6d6349a7..c2809460d582 100644
--- a/gcc/common/config/riscv/riscv-ext-bitmask.def
+++ b/gcc/common/config/riscv/riscv-ext-bitmask.def
@@ -79,5 +79,6 @@ RISCV_EXT_BITMASK ("zcd", 1, 4)
RISCV_EXT_BITMASK ("zcf", 1, 5)
RISCV_EXT_BITMASK ("zcmop",1, 6)
RISCV_EXT_BITMASK ("zawrs",1, 7)
+RISCV_EXT_BITMASK ("xqccmp", 1, 8)
#undef RISCV_EXT_BITMASK
diff --git a/gcc/config/riscv/riscv.opt b/gcc/config/riscv/riscv.opt
index 7515c8ea13dd..61cc8258e323 100644
--- a/gcc/config/riscv/riscv.opt
+++ b/gcc/config/riscv/riscv.opt
@@ -535,6 +535,11 @@ Mask(XSFVQMACCDOD) Var(riscv_sifive_subext)
Mask(XSFVFNRCLIPXFQF) Var(riscv_sifive_subext)
+TargetVariable
+int riscv_qc_subext
+
+Mask(XQCCMP) Var(riscv_qc_subext)
+
TargetVariable
int riscv_fmv_priority = 0
diff --git a/gcc/testsuite/gcc.target/riscv/arch-45.c
b/gcc/testsuite/gcc.target/riscv/arch-45.c
new file mode 100644
index ..590d4f130325
--- /dev/null
+++ b/gcc/testsuite/gcc.target/riscv/arch-45.c
@@ -0,0 +1,5 @@
+/* { dg-do compile } */
+/* { dg-options "-march=rv64gc_xqccmp -mabi=lp64" } */
+int foo()
+{
+}
--
2.43.0
Re: [PATCH] RISC-V: Minimal support for Qualcomm uC Xqccmp extension.
On 20/2/2025 16:31, Dongyan Chen wrote:
This patch support Qualcomm uC Xqccmp extension[1].
To enable GCC to recognize and process xqccmp extension correctly at compile
time.
[1]https://github.com/quic/riscv-unified-db/releases/tag/Xqccmp_extension-0.1.0
gcc/ChangeLog:
* common/config/riscv/riscv-common.cc: New extension.
* common/config/riscv/riscv-ext-bitmask.def (RISCV_EXT_BITMASK): Ditto.
* config/riscv/riscv.opt: Ditto.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/arch-45.c: New test.
---
gcc/common/config/riscv/riscv-common.cc | 6 ++
gcc/common/config/riscv/riscv-ext-bitmask.def | 1 +
gcc/config/riscv/riscv.opt| 5 +
gcc/testsuite/gcc.target/riscv/arch-45.c | 5 +
4 files changed, 17 insertions(+)
create mode 100644 gcc/testsuite/gcc.target/riscv/arch-45.c
diff --git a/gcc/common/config/riscv/riscv-common.cc
b/gcc/common/config/riscv/riscv-common.cc
index 5038f0eb959a..6fbdb5ed2316 100644
--- a/gcc/common/config/riscv/riscv-common.cc
+++ b/gcc/common/config/riscv/riscv-common.cc
@@ -229,6 +229,8 @@ static const riscv_implied_info_t riscv_implied_info[] =
{"xsfvcp", "zve32x"},
+ {"xqccmp", "zca"},
+
{NULL, NULL}
};
@@ -442,6 +444,8 @@ static const struct riscv_ext_version
riscv_ext_version_table[] =
{"xsfvqmaccdod",ISA_SPEC_CLASS_NONE, 1, 0},
{"xsfvfnrclipxfqf", ISA_SPEC_CLASS_NONE, 1, 0},
+ {"xqccmp", ISA_SPEC_CLASS_NONE, 0, 1},
+
/* Terminate the list. */
{NULL, ISA_SPEC_CLASS_NONE, 0, 0}
};
@@ -1778,6 +1782,8 @@ static const riscv_ext_flag_table_t
riscv_ext_flag_table[] =
RISCV_EXT_FLAG_ENTRY ("xsfvqmaccdod",x_riscv_sifive_subext,
MASK_XSFVQMACCDOD),
RISCV_EXT_FLAG_ENTRY ("xsfvfnrclipxfqf", x_riscv_sifive_subext,
MASK_XSFVFNRCLIPXFQF),
+ RISCV_EXT_FLAG_ENTRY ("xqccmp", x_riscv_qc_subext, MASK_XQCCMP),
+
{NULL, NULL, NULL, 0}
};
diff --git a/gcc/common/config/riscv/riscv-ext-bitmask.def
b/gcc/common/config/riscv/riscv-ext-bitmask.def
index 8b4e6d6349a7..c2809460d582 100644
--- a/gcc/common/config/riscv/riscv-ext-bitmask.def
+++ b/gcc/common/config/riscv/riscv-ext-bitmask.def
@@ -79,5 +79,6 @@ RISCV_EXT_BITMASK ("zcd", 1, 4)
RISCV_EXT_BITMASK ("zcf", 1, 5)
RISCV_EXT_BITMASK ("zcmop", 1, 6)
RISCV_EXT_BITMASK ("zawrs", 1, 7)
+RISCV_EXT_BITMASK ("xqccmp", 1, 8)
#undef RISCV_EXT_BITMASK
Please don't add the xqccmp extension here, as this file should be
consistent with the RISC-V C-API. Additionally, it should only contain
standard extensions.
diff --git a/gcc/config/riscv/riscv.opt b/gcc/config/riscv/riscv.opt
index 7515c8ea13dd..61cc8258e323 100644
--- a/gcc/config/riscv/riscv.opt
+++ b/gcc/config/riscv/riscv.opt
@@ -535,6 +535,11 @@ Mask(XSFVQMACCDOD) Var(riscv_sifive_subext)
Mask(XSFVFNRCLIPXFQF) Var(riscv_sifive_subext)
+TargetVariable
+int riscv_qc_subext
+
+Mask(XQCCMP) Var(riscv_qc_subext)
+
TargetVariable
int riscv_fmv_priority = 0
diff --git a/gcc/testsuite/gcc.target/riscv/arch-45.c
b/gcc/testsuite/gcc.target/riscv/arch-45.c
new file mode 100644
index ..590d4f130325
--- /dev/null
+++ b/gcc/testsuite/gcc.target/riscv/arch-45.c
@@ -0,0 +1,5 @@
+/* { dg-do compile } */
+/* { dg-options "-march=rv64gc_xqccmp -mabi=lp64" } */
+int foo()
+{
+}
--
2.43.0
[pushed: r15-7657] sarif-replay: improve error for unescaped braces in messages (§3.11.5)
Spotted via https://github.com/llvm/llvm-project/issues/128024
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r15-7657-g5a30a3aba065f6.
gcc/ChangeLog:
* libsarifreplay.cc
(sarif_replayer::make_plain_text_within_result_message): Capture
which json::string was used. When reporting on unescaped "{" or
"}" in SARIF message strings, use that string rather than the
message object, and refer the user to §3.11.5 ("Messages with
placeholders") rather than §3.11.11 ("arguments"). Ideally we'd
place the error at the precise character, but that can't be done
without reworking json-parsing.cc's lexer::lex_string, which is
too invasive for stage 4.
(sarif_replayer::get_plain_text_from_mfms): Capture which
json::string was used.
(sarif_replayer::lookup_plain_text_within_result_message):
Likewise.
gcc/testsuite/ChangeLog:
* sarif-replay.dg/2.1.0-invalid/3.11.11-malformed-placeholder.sarif:
Rename to...
* sarif-replay.dg/2.1.0-invalid/3.11.5-unescaped-braces.sarif:
...this. Update expected subsection in error message, and
expected underline in quoted JSON.
Signed-off-by: David Malcolm
---
gcc/libsarifreplay.cc | 43 +--
...er.sarif => 3.11.5-unescaped-braces.sarif} | 4 +-
2 files changed, 33 insertions(+), 14 deletions(-)
rename
gcc/testsuite/sarif-replay.dg/2.1.0-invalid/{3.11.11-malformed-placeholder.sarif
=> 3.11.5-unescaped-braces.sarif} (84%)
diff --git a/gcc/libsarifreplay.cc b/gcc/libsarifreplay.cc
index cc051dcd485..ce42bdace3c 100644
--- a/gcc/libsarifreplay.cc
+++ b/gcc/libsarifreplay.cc
@@ -272,12 +272,14 @@ private:
const char *
lookup_plain_text_within_result_message (const json::object
*tool_component_obj,
const json::object &message_obj,
- const json::object *rule_obj);
+ const json::object *rule_obj,
+ const json::string *&out_js_str);
// "multiformatMessageString" object (§3.12).
const char *
get_plain_text_from_mfms (json::value &mfms_val,
- const property_spec_ref &prop);
+ const property_spec_ref &prop,
+ const json::string *&out_js_str);
// "run" object (§3.14)
enum status
@@ -1367,13 +1369,17 @@ make_plain_text_within_result_message (const
json::object *tool_component_obj,
const json::object &message_obj,
const json::object *rule_obj)
{
+ const json::string *js_str = nullptr;
const char *original_text
= lookup_plain_text_within_result_message (tool_component_obj,
message_obj,
- rule_obj);
+ rule_obj,
+ js_str);
if (!original_text)
return label_text::borrow (nullptr);
+ gcc_assert (js_str);
+
/* Look up any arguments for substituting into placeholders. */
const property_spec_ref arguments_prop ("message", "arguments", "3.11.11");
const json::array *arguments
@@ -1425,7 +1431,9 @@ make_plain_text_within_result_message (const json::object
*tool_component_obj,
}
else
{
- report_invalid_sarif (message_obj, arguments_prop,
+ const spec_ref msgs_with_placeholders ("3.11.5");
+ gcc_assert (js_str);
+ report_invalid_sarif (*js_str, msgs_with_placeholders,
"unescaped '%c' within message string",
ch);
return label_text::borrow (nullptr);
@@ -1450,11 +1458,14 @@ make_plain_text_within_result_message (const
json::object *tool_component_obj,
/* Handle a value that should be a multiformatMessageString object (§3.12).
Complain using prop if MFMS_VAL is not an object.
- Return get the "text" value (or nullptr, and complain). */
+ Return get the "text" value (or nullptr, and complain).
+ If the result is non-null, write the json::string that was actually used
+ to OUT_JS_STR. */
const char *
sarif_replayer::get_plain_text_from_mfms (json::value &mfms_val,
- const property_spec_ref &prop)
+ const property_spec_ref &prop,
+ const json::string *&out_js_str)
{
auto mfms_obj = require_object (mfms_val, prop);
if (!mfms_obj)
@@ -1465,6 +1476,7 @@ sarif_replayer::get_plain_text_from_mfms (json::value
&mfms_val,
auto text_jstr = get_required_property (*mfms_obj, text_prop);
if (!text_jstr)
return nullptr;
+ out_js_str = t
[pushed: r15-7659] diagnostics: add comments about global_dc
No functional change intended.
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r15-7659-g4e9ee99647ebb9.
gcc/ChangeLog:
* diagnostic-core.h: Add comments making clear that these
functions implicitly use global_dc.
Signed-off-by: David Malcolm
---
gcc/diagnostic-core.h | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/gcc/diagnostic-core.h b/gcc/diagnostic-core.h
index 8724fa2fd21..1e89c9fac5e 100644
--- a/gcc/diagnostic-core.h
+++ b/gcc/diagnostic-core.h
@@ -1,6 +1,6 @@
/* Declarations of core diagnostic functionality for code that does
not need to deal with diagnostic contexts or diagnostic info
- structures.
+ structures. These functions implicitly use global_dc.
Copyright (C) 1998-2025 Free Software Foundation, Inc.
This file is part of GCC.
@@ -39,7 +39,7 @@ typedef enum
DK_ANY,
} diagnostic_t;
-/* RAII-style class for grouping related diagnostics. */
+/* RAII-style class for grouping related diagnostics within global_dc. */
class auto_diagnostic_group
{
@@ -48,7 +48,7 @@ class auto_diagnostic_group
~auto_diagnostic_group ();
};
-/* RAII-style class for nesting hierarchical diagnostics.
+/* RAII-style class for nesting hierarchical diagnostics within global_dc.
Any diagnostics emitted within the lifetime of this object
will be treated as one level of nesting deeper than diagnostics
emitted outside the lifetime of the object. */
@@ -88,6 +88,9 @@ extern const char *progname;
extern const char *trim_filename (const char *);
+/* Various functions for emitting diagnostics follow.
+ All of these implicitly use global_dc. */
+
/* If we haven't already defined a front-end-specific diagnostics
style, use the generic one. */
#ifndef GCC_DIAG_STYLE
--
2.26.3
[pushed: r15-7658] sarif-replay: add testcase for empty input file
Successfully tested on x86_64-pc-linux-gnu.
Pushed to trunk as r15-7658-gc5f541e40aca2d
gcc/testsuite/ChangeLog:
* sarif-replay.dg/malformed-json/empty.sarif: New test.
Signed-off-by: David Malcolm
---
gcc/testsuite/sarif-replay.dg/malformed-json/empty.sarif | 2 ++
1 file changed, 2 insertions(+)
create mode 100644 gcc/testsuite/sarif-replay.dg/malformed-json/empty.sarif
diff --git a/gcc/testsuite/sarif-replay.dg/malformed-json/empty.sarif
b/gcc/testsuite/sarif-replay.dg/malformed-json/empty.sarif
new file mode 100644
index 000..070677e3cf7
--- /dev/null
+++ b/gcc/testsuite/sarif-replay.dg/malformed-json/empty.sarif
@@ -0,0 +1,2 @@
+/* Empty file (apart from these comments). */
+/* { dg-error "expected a JSON value but got EOF" "" { target *-*-* } 3 } */
--
2.26.3
Ping: [PATCH v2 0/5][STAGE1] Add btf_decl_tag and btf_type_tag C attributes
Gentle ping for this series. https://gcc.gnu.org/pipermail/gcc-patches/2025-February/675241.html On 2/6/25 11:54, David Faust wrote: > [v1: https://gcc.gnu.org/pipermail/gcc-patches/2024-October/666911.html > Changes from v1: > - Fix a bug in v1 related to generating DWARF for type tags applied to >struct or union types, especially if the type had multiple type tags >or was also part of a typedef. > - Simplified the dwarf2ctf translation of types having both cv-qualifiers >and type tags applied to them. > - Add a few new tests. > - Address review comments from v1. ] > > This patch series adds support for the btf_decl_tag and btf_type_tag > attributes > to GCC. This entails: > > - Two new C-family attributes that allow to associate (to "tag") particular > declarations and types with arbitrary strings. As explained below, this is > intended to be used to, for example, characterize certain pointer types. A > single declaration or type may have multiple occurrences of these > attributes. > > - The conveyance of that information in the DWARF output in the form of a new > DIE: DW_TAG_GNU_annotation, and a new attribute: DW_AT_GNU_annotation. > > - The conveyance of that information in the BTF output in the form of two new > kinds of BTF objects: BTF_KIND_DECL_TAG and BTF_KIND_TYPE_TAG. These BTF > kinds are already supported by LLVM and other tools in the BPF ecosystem. > > Both of these attributes are already supported by clang, and beginning to be > used in various ways by BPF users and inside the Linux kernel. > > It is worth noting that while the Linux kernel and BPF/BTF is the motivating > use > case of this feature, the format of the new DWARF extension is generic. This > work could be easily adapted to provide a general way for program authors to > annotate types and declarations with arbitrary information for any > post-compilation analysis needs, not just the Linux kernel BPF verifier. For > example, these annotations could be used to aid in ABI analysis. > > Purpose > === > > 1) Addition of C-family language constructs (attributes) to specify free-text > tags on certain language elements, such as struct fields. > > The purpose of these annotations is to provide additional information > about > types, variables, and function parameters of interest to the kernel. A > driving use case is to tag pointer types within the Linux kernel and BPF > programs with additional semantic information, such as '__user' or > '__rcu'. > > For example, consider the Linux kernel function do_execve with the > following declaration: > > static int do_execve(struct filename *filename, > const char __user *const __user *__argv, > const char __user *const __user *__envp); > > Here, __user could be defined with these annotations to record semantic > information about the pointer parameters (e.g., they are user-provided) in > DWARF and BTF information. Other kernel facilities such as the BPF > verifier > can read the tags and make use of the information. > > 2) Conveying the tags in the generated DWARF debug info. > > The main motivation for emitting the tags in DWARF is that the Linux > kernel > generates its BTF information via pahole, using DWARF as a source: > > ++ BTF BTF +--+ > | pahole |---> vmlinux.btf --->| verifier | > ++ +--+ > ^^ > || > DWARF |BTF | > || > vmlinux +-+ > module1.ko | BPF program | > module2.ko +-+ >... > > This is because: > > a) Unlike GCC, LLVM will only generate BTF for BPF programs. > > b) GCC can generate BTF for whatever target with -gbtf, but there is no > support for linking/deduplicating BTF in the linker. > > c) pahole injects additional BTF information based on specific knowledge > of kernel objects which is not available to the compiler. > > In the scenario above, the verifier needs access to the pointer tags of > both the kernel types/declarations (conveyed in the DWARF and translated > to BTF by pahole) and those of the BPF program (available directly in > BTF). > > Another motivation for having the tag information in DWARF, unrelated to > BPF and BTF, is that the drgn project (another DWARF consumer) also wants > to benefit from these tags in order to differentiate between different > kinds of pointers in the kernel. > > 3) Conveying the tags in the generated BTF debug info. > > This is easy: the main purpose of having this info i
