Re: [PATCH V2] Disable sched1 in functions that call setjmp
On Fri, 23 Dec 2022, Qing Zhao wrote: > BTW, Why sched1 is not enabled on x86 by default? Register allocation is tricky on x86 due to small number of general-purpose registers, and sched1 can make it even more difficult. I think before register pressure modeling was added, sched1 could not be enabled because then allocation would sometimes fail, and now there's no incentive to enable it, as it is not so important for modern x86 CPUs. Perhaps someone else has a more comprehensive answer. > Another question is: As discussed in the original bug PR57067: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57067 The root cause of this > issue related to the abnormal control flow edges (from setjmp/longjmp) cannot > be represented correctly at RTL stage, shall we fix this root cause instead? You'd need an experienced reviewer to work with you, especially on high-level design decisions such as "How ABNORMAL_DISPATCHER should be represented on RTL". I'm afraid it's not just a matter of applying a small patch in one place. Alexander
Re: [PATCH V2] Disable sched1 in functions that call setjmp
> Am 24.12.2022 um 09:11 schrieb Alexander Monakov via Gcc-patches > : > > >> On Fri, 23 Dec 2022, Qing Zhao wrote: >> >> BTW, Why sched1 is not enabled on x86 by default? > > Register allocation is tricky on x86 due to small number of general-purpose > registers, and sched1 can make it even more difficult. I think before register > pressure modeling was added, sched1 could not be enabled because then > allocation > would sometimes fail, and now there's no incentive to enable it, as it is not > so > important for modern x86 CPUs. Perhaps someone else has a more comprehensive > answer. > >> Another question is: As discussed in the original bug PR57067: >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57067 The root cause of this >> issue related to the abnormal control flow edges (from setjmp/longjmp) cannot >> be represented correctly at RTL stage, shall we fix this root cause instead? > > You'd need an experienced reviewer to work with you, especially on high-level > design decisions such as "How ABNORMAL_DISPATCHER should be represented on > RTL". > I'm afraid it's not just a matter of applying a small patch in one place. For nonlocal goto we Thread the abnormal dispatcher. Of course by regenerating abnormal edges, not by keeping and modifying them. We cannot re-generate the (optimal) set of abnormal edges for setjmp so we want to preserve those edges. But as you say it’s a very non-trivial change. Richard > Alexander
Re: [PATCH V2] Disable sched1 in functions that call setjmp
>> Am 24.12.2022 um 09:11 schrieb Alexander Monakov via Gcc-patches >> : >> >> >>> On Fri, 23 Dec 2022, Qing Zhao wrote: >>> >>> BTW, Why sched1 is not enabled on x86 by default? >> >> Register allocation is tricky on x86 due to small number of general-purpose >> registers, and sched1 can make it even more difficult. I think before >> register >> pressure modeling was added, sched1 could not be enabled because then >> allocation >> would sometimes fail, and now there's no incentive to enable it, as it is >> not so >> important for modern x86 CPUs. Perhaps someone else has a more comprehensive >> answer. >> >>> Another question is: As discussed in the original bug PR57067: >>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57067 The root cause of this >>> issue related to the abnormal control flow edges (from setjmp/longjmp) >>> cannot >>> be represented correctly at RTL stage, shall we fix this root cause >>> instead? >> >> You'd need an experienced reviewer to work with you, especially on high-level >> design decisions such as "How ABNORMAL_DISPATCHER should be represented on >> RTL". >> I'm afraid it's not just a matter of applying a small patch in one place. > > For nonlocal goto we Thread the abnormal dispatcher. Of course by > regenerating abnormal edges, not by keeping and modifying them. We > cannot re-generate the (optimal) set of abnormal edges for setjmp so > we want to preserve those edges. But as you say it’s a very > non-trivial change. Allright, so we have two short-term alternatives for at least remove the possibility that GCC generates wrong code for valid C when the scheduler is turned on: a) To disable sched1 in functions that call setjmp. b) To change deps_analyze_insn so instructions are not moved across function calls before register allocation (!reload_completed). Both patches fix our particular use cases and are regression free in aarch64-linux-gnu. However, there is something I don't understand: wouldn't sched2 introduce the same problem when -fsched2-use-superblocks is specified? In that case, the option a) would need to be expanded to disable sched2 as well, and b) wouldn't have effect (!after_reload)? Using -fsched2-use-superblocks doesn't trigger the problem in our use case.
Re: [PATCH] libstdc++, configure: Fix GLIBCXX_ZONEINFO_DIR configuration macro.
Hi,
> On 23 Dec 2022, at 23:17, Jonathan Wakely wrote:
>
> On Fri, 23 Dec 2022, 17:06 Iain Sandoe via Libstdc++,
> wrote:
> This is a patch for comment on the approach - tested on x86_64-darwi21
> thoughts?
> Iain
>
> --- 8< ---
>
> Testing on Darwin revealed that the GLIBCXX_ZONEINFO_DIR was not doing quite
> the right thing (we ended up with ${withval} in the config.h file).
>
> This patch proposes revising the behaviour of the configure flag thus:
>
> --with-libstdcxx-zoneinfo-dir=
> unspecified : Set _GLIBCXX_ZONEINFO_DIR to a default suitable for $host
> yes : Set _GLIBCXX_ZONEINFO_DIR to a default suitable for $host
> no : Do not set _GLIBCXX_ZONEINFO_DIR
>
> What's the use case for "no"? Enforcing a UTC-only tzdb that doesn't even try
> to load the tzdata? If that's desirable, we could #ifdef huge parts of
> src/c++20/tzdb.cc to make the library smaller. That might make sense for a
> toolchain for embedded targets where it's known there's no need for time zone
> conversions.
Actually, I had not explored all those possibilities.
My thinking was that ’no’ is a valid answer and either we need to produce a
configure diagnostic saying that it is not a valid choice - or we should apply
it in some useful way. Silent acceptance but doing something different from
what the user was expecting seems a bad idea.
Your use cases seem quite reasonable - and, yes, I guess that means the code
could be stubbed or given a trivial impl. for that case.
cheers, and season’s greetings,
Iain
>
>
>
> /some/path : set _GLIBCXX_ZONEINFO_DIR = "/some/path"
>
> Signed-off-by: Iain Sandoe
>
> libstdc++-v3/ChangeLog:
>
> * acinclude.m4 (GLIBCXX_ZONEINFO_DIR): Revise configure flag
> handling.
> * configure: Regenerate.
> * src/c++20/tzdb.cc: Add a comment that an unset _GLIBCXX_ZONEINFO_DIR
> implies that the configuration specified that no directory should be
> used.
> ---
> libstdc++-v3/acinclude.m4 | 21 ++---
> libstdc++-v3/configure | 28 +++-
> libstdc++-v3/src/c++20/tzdb.cc | 1 +
> 3 files changed, 34 insertions(+), 16 deletions(-)
>
> diff --git a/libstdc++-v3/acinclude.m4 b/libstdc++-v3/acinclude.m4
> index f73946a4918..3653822aed4 100644
> --- a/libstdc++-v3/acinclude.m4
> +++ b/libstdc++-v3/acinclude.m4
> @@ -5153,18 +5153,25 @@ AC_DEFUN([GLIBCXX_ZONEINFO_DIR], [
>AC_ARG_WITH([libstdcxx-zoneinfo-dir],
> AC_HELP_STRING([--with-libstdcxx-zoneinfo-dir],
>[the directory to search for tzdata files]),
> -[zoneinfo_dir="${withval}"
> - AC_DEFINE(_GLIBCXX_ZONEINFO_DIR, "${withval}",
> - [Define if a non-default location should be used for tzdata files.])
> -],
> -[
> +[],[with_libstdcxx_zoneinfo_dir=yes])
> +
> + # Pick a default when no specific path is set.
> + if test x${with_libstdcxx_zoneinfo_dir} = xyes; then
> case "$host" in
># *-*-aix*) zoneinfo_dir="/usr/share/lib/zoneinfo" ;;
> + *-*-darwin2*) zoneinfo_dir="/usr/share/lib/zoneinfo.default" ;;
>*) zoneinfo_dir="/usr/share/zoneinfo" ;;
> esac
> -])
> -
> + elif test x${with_libstdcxx_zoneinfo_dir} = xno; then
> +zoneinfo_dir=none
> + else
> +zoneinfo_dir=${with_libstdcxx_zoneinfo_dir}
> + fi
>AC_MSG_NOTICE([zoneinfo data directory: ${zoneinfo_dir}])
> + if test x${zoneinfo_dir} != xnone; then
> +AC_DEFINE_UNQUOTED(_GLIBCXX_ZONEINFO_DIR, "${zoneinfo_dir}",
> + [Define if a non-default location should be used for tzdata files.])
> + fi
> ])
>
> # Macros from the top-level gcc directory.
>
> diff --git a/libstdc++-v3/src/c++20/tzdb.cc b/libstdc++-v3/src/c++20/tzdb.cc
> index 5f5c4199f65..c4311d0902a 100644
> --- a/libstdc++-v3/src/c++20/tzdb.cc
> +++ b/libstdc++-v3/src/c++20/tzdb.cc
> @@ -52,6 +52,7 @@
> # endif
> #endif
>
> +// This is a bit odd; the configure-time setting was 'no zoneinfo directory'
> #ifndef _GLIBCXX_ZONEINFO_DIR
> # define _GLIBCXX_ZONEINFO_DIR "/usr/share/zoneinfo"
> #endif
> --
> 2.37.1 (Apple Git-137.1)
Re: [PATCH] libstdc++, configure: Fix GLIBCXX_ZONEINFO_DIR configuration macro.
On Sat, 24 Dec 2022, 09:56 Iain Sandoe, wrote:
> Hi,
>
> > On 23 Dec 2022, at 23:17, Jonathan Wakely wrote:
> >
> > On Fri, 23 Dec 2022, 17:06 Iain Sandoe via Libstdc++, <
> libstd...@gcc.gnu.org> wrote:
> > This is a patch for comment on the approach - tested on x86_64-darwi21
> > thoughts?
> > Iain
> >
> > --- 8< ---
> >
> > Testing on Darwin revealed that the GLIBCXX_ZONEINFO_DIR was not doing
> quite
> > the right thing (we ended up with ${withval} in the config.h file).
> >
> > This patch proposes revising the behaviour of the configure flag thus:
> >
> > --with-libstdcxx-zoneinfo-dir=
> > unspecified : Set _GLIBCXX_ZONEINFO_DIR to a default suitable for $host
> > yes : Set _GLIBCXX_ZONEINFO_DIR to a default suitable for $host
> > no : Do not set _GLIBCXX_ZONEINFO_DIR
> >
> > What's the use case for "no"? Enforcing a UTC-only tzdb that doesn't
> even try to load the tzdata? If that's desirable, we could #ifdef huge
> parts of src/c++20/tzdb.cc to make the library smaller. That might make
> sense for a toolchain for embedded targets where it's known there's no need
> for time zone conversions.
>
> Actually, I had not explored all those possibilities.
>
> My thinking was that ’no’ is a valid answer and either we need to produce
> a configure diagnostic saying that it is not a valid choice - or we should
> apply it in some useful way. Silent acceptance but doing something
> different from what the user was expecting seems a bad idea.
>
> Your use cases seem quite reasonable - and, yes, I guess that means the
> code could be stubbed or given a trivial impl. for that case.
>
I'll look into doing that in the new year.
> cheers, and season’s greetings,
> Iain
>
>
> >
> >
> >
> > /some/path : set _GLIBCXX_ZONEINFO_DIR = "/some/path"
> >
> > Signed-off-by: Iain Sandoe
> >
> > libstdc++-v3/ChangeLog:
> >
> > * acinclude.m4 (GLIBCXX_ZONEINFO_DIR): Revise configure flag
> > handling.
> > * configure: Regenerate.
> > * src/c++20/tzdb.cc: Add a comment that an unset
> _GLIBCXX_ZONEINFO_DIR
> > implies that the configuration specified that no directory
> should be
> > used.
> > ---
> > libstdc++-v3/acinclude.m4 | 21 ++---
> > libstdc++-v3/configure | 28 +++-
> > libstdc++-v3/src/c++20/tzdb.cc | 1 +
> > 3 files changed, 34 insertions(+), 16 deletions(-)
> >
> > diff --git a/libstdc++-v3/acinclude.m4 b/libstdc++-v3/acinclude.m4
> > index f73946a4918..3653822aed4 100644
> > --- a/libstdc++-v3/acinclude.m4
> > +++ b/libstdc++-v3/acinclude.m4
> > @@ -5153,18 +5153,25 @@ AC_DEFUN([GLIBCXX_ZONEINFO_DIR], [
> >AC_ARG_WITH([libstdcxx-zoneinfo-dir],
> > AC_HELP_STRING([--with-libstdcxx-zoneinfo-dir],
> >[the directory to search for tzdata files]),
> > -[zoneinfo_dir="${withval}"
> > - AC_DEFINE(_GLIBCXX_ZONEINFO_DIR, "${withval}",
> > - [Define if a non-default location should be used for tzdata
> files.])
> > -],
> > -[
> > +[],[with_libstdcxx_zoneinfo_dir=yes])
> > +
> > + # Pick a default when no specific path is set.
> > + if test x${with_libstdcxx_zoneinfo_dir} = xyes; then
> > case "$host" in
> ># *-*-aix*) zoneinfo_dir="/usr/share/lib/zoneinfo" ;;
> > + *-*-darwin2*) zoneinfo_dir="/usr/share/lib/zoneinfo.default" ;;
> >*) zoneinfo_dir="/usr/share/zoneinfo" ;;
> > esac
> > -])
> > -
> > + elif test x${with_libstdcxx_zoneinfo_dir} = xno; then
> > +zoneinfo_dir=none
> > + else
> > +zoneinfo_dir=${with_libstdcxx_zoneinfo_dir}
> > + fi
> >AC_MSG_NOTICE([zoneinfo data directory: ${zoneinfo_dir}])
> > + if test x${zoneinfo_dir} != xnone; then
> > +AC_DEFINE_UNQUOTED(_GLIBCXX_ZONEINFO_DIR, "${zoneinfo_dir}",
> > + [Define if a non-default location should be used for tzdata
> files.])
> > + fi
> > ])
> >
> > # Macros from the top-level gcc directory.
> >
> > diff --git a/libstdc++-v3/src/c++20/tzdb.cc
> b/libstdc++-v3/src/c++20/tzdb.cc
> > index 5f5c4199f65..c4311d0902a 100644
> > --- a/libstdc++-v3/src/c++20/tzdb.cc
> > +++ b/libstdc++-v3/src/c++20/tzdb.cc
> > @@ -52,6 +52,7 @@
> > # endif
> > #endif
> >
> > +// This is a bit odd; the configure-time setting was 'no zoneinfo
> directory'
> > #ifndef _GLIBCXX_ZONEINFO_DIR
> > # define _GLIBCXX_ZONEINFO_DIR "/usr/share/zoneinfo"
> > #endif
> > --
> > 2.37.1 (Apple Git-137.1)
>
>
Re: [PATCH V2] Disable sched1 in functions that call setjmp
> Am 24.12.2022 um 10:54 schrieb Jose E. Marchesi : > > Am 24.12.2022 um 09:11 schrieb Alexander Monakov via Gcc-patches : >>> >>> On Fri, 23 Dec 2022, Qing Zhao wrote: BTW, Why sched1 is not enabled on x86 by default? >>> >>> Register allocation is tricky on x86 due to small number of general-purpose >>> registers, and sched1 can make it even more difficult. I think before >>> register >>> pressure modeling was added, sched1 could not be enabled because then >>> allocation >>> would sometimes fail, and now there's no incentive to enable it, as it is >>> not so >>> important for modern x86 CPUs. Perhaps someone else has a more comprehensive >>> answer. >>> Another question is: As discussed in the original bug PR57067: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57067 The root cause of this issue related to the abnormal control flow edges (from setjmp/longjmp) cannot be represented correctly at RTL stage, shall we fix this root cause instead? >>> >>> You'd need an experienced reviewer to work with you, especially on >>> high-level >>> design decisions such as "How ABNORMAL_DISPATCHER should be represented on >>> RTL". >>> I'm afraid it's not just a matter of applying a small patch in one place. >> >> For nonlocal goto we Thread the abnormal dispatcher. Of course by >> regenerating abnormal edges, not by keeping and modifying them. We >> cannot re-generate the (optimal) set of abnormal edges for setjmp so >> we want to preserve those edges. But as you say it’s a very >> non-trivial change. > > Allright, so we have two short-term alternatives for at least remove the > possibility that GCC generates wrong code for valid C when the scheduler > is turned on: > > a) To disable sched1 in functions that call setjmp. > > b) To change deps_analyze_insn so instructions are not moved across > function calls before register allocation (!reload_completed). > > Both patches fix our particular use cases and are regression free in > aarch64-linux-gnu. > > However, there is something I don't understand: wouldn't sched2 > introduce the same problem when -fsched2-use-superblocks is specified? > In that case, the option a) would need to be expanded to disable sched2 > as well, and b) wouldn't have effect (!after_reload)? > > Using -fsched2-use-superblocks doesn't trigger the problem in our use > case. I’d go with b) and revisit sched2 when we run into a testcase that’s mishandled. Richard
Re: [PATCH V2] Disable sched1 in functions that call setjmp
On Sat, 24 Dec 2022, Jose E. Marchesi wrote: > However, there is something I don't understand: wouldn't sched2 > introduce the same problem when -fsched2-use-superblocks is specified? Superblocks are irrelevant, a call instruction does not end a basic block and the problematic motion happens within a BB on your testcase. Didn't you ask about this already? > In that case, the option a) would need to be expanded to disable sched2 > as well, and b) wouldn't have effect (!after_reload)? See my response to Qing Zhao, I think due to special-casing of pseudos that are live at setjmp during register allocation, sched2 will not move them in such manner (they should be assigned to memory and I don't expect sched2 will move such MEMs across calls). But of course there may be holes in this theory. On some targets disabling sched2 is not so easy because it's responsible for VLIW packing (bundling on ia64). Alexander
[PATCH] libstdc++: Export the __gnu_cxx::zoneinfo_dir_override symbol.
If this is not the right place to export the symbol (or you do not want
to export it in the general case), I can always add a platform-specific
file for it. So far, tested on x86_64-darwin21, wider testing will
follow over the holidays.
OK for trunk?
Iain
--- 8< ---
This symbol needs to be visible in the library interface for Darwin
to override it with a user-provided one.
Signed-off-by: Iain Sandoe
libstdc++-v3/ChangeLog:
* config/abi/pre/gnu.ver (GLIBCXX_3.4):
Add __gnu_cxx::zoneinfo_dir_override().
---
libstdc++-v3/config/abi/pre/gnu.ver | 3 +++
1 file changed, 3 insertions(+)
diff --git a/libstdc++-v3/config/abi/pre/gnu.ver
b/libstdc++-v3/config/abi/pre/gnu.ver
index 570ffca8710..bd4ab450652 100644
--- a/libstdc++-v3/config/abi/pre/gnu.ver
+++ b/libstdc++-v3/config/abi/pre/gnu.ver
@@ -1104,6 +1104,9 @@ GLIBCXX_3.4 {
# std::uncaught_exception()
_ZSt18uncaught_exceptionv;
+# __gnu_cxx::zoneinfo_dir_override()
+_ZN9__gnu_cxx21zoneinfo_dir_overrideEv
+
# DO NOT DELETE THIS LINE. Port-specific symbols, if any, will be here.
local:
--
2.37.1 (Apple Git-137.1)
[PATCH] libstdc++: Test for tzdata.zi before fallback version files.
I tested this (along with the other posted patches for zoneinfo) using
an installation built from the 2022g release on x86_64-darwin21. Wider
testing will follow. If we are in an installation without the tzdata.zi
then although we'll report the version OK, the available functionality
will be basic.
OK for trunk?
Iain
--- 8< ---
Several systems/distributions do not provide the raw tzdata.zi file in
their zoneinfo installation. However, we might provide an alternate
installation path at configure time, so that we should check for the
tzdata.zi file first and then fall back to system-specific files like
+VERSION etc. on those systems.
Signed-off-by: Iain Sandoe
libstdc++-v3/ChangeLog:
* src/c++20/tzdb.cc (remote_version): Look for the tzdata.zi
file before falling back to system-specific ones on Darwin and
BSD.
---
libstdc++-v3/src/c++20/tzdb.cc | 17 ++---
1 file changed, 10 insertions(+), 7 deletions(-)
diff --git a/libstdc++-v3/src/c++20/tzdb.cc b/libstdc++-v3/src/c++20/tzdb.cc
index c4311d0902a..39e4466f932 100644
--- a/libstdc++-v3/src/c++20/tzdb.cc
+++ b/libstdc++-v3/src/c++20/tzdb.cc
@@ -1061,16 +1061,11 @@ namespace std::chrono
namespace
{
// Read the version number from a tzdata.zi file.
+// Note that some systems do not have this file available by default
+// but we can configure the library to point to an alternate installation.
string
remote_version(istream* zif)
{
-#if defined __NetBSD__
-if (string ver; ifstream(zoneinfo_dir() + "/TZDATA_VERSION") >> ver)
- return ver;
-#elif defined __APPLE__
-if (string ver; ifstream(zoneinfo_dir() + "/+VERSION") >> ver)
- return ver;
-#else
ifstream f;
if (!zif)
{
@@ -1083,6 +1078,14 @@ namespace std::chrono
if (*zif >> hash >> label >> version)
if (hash == '#' && label == "version")
return version;
+#if defined __NetBSD__
+if (string ver; ifstream(zoneinfo_dir() + "/TZDATA_VERSION") >> ver)
+ return ver;
+#elif defined __APPLE__
+// The standard install on macOS has no tzdata.zi, but we can find the
+// version from +VERSION.
+if (string ver; ifstream(zoneinfo_dir() + "/+VERSION") >> ver)
+ return ver;
#endif
__throw_runtime_error("tzdb: no version found in tzdata.zi");
}
--
2.37.1 (Apple Git-137.1)
[PATCH] libstdc++, testsuite: Correct an init.
Noticed while debugging tz info support on Darwin, unless I miss
some other reasoning...
OK for trunk?
Iain
--- 8< ---
in leap_seconds.cc, we are testing to see if the function that
overrides the default zoneinfo directory has been called. That
is implemented with a static boolean that needs to be initialized
to false.
Signed-off-by: Iain Sandoe
libstdc++-v3/ChangeLog:
* testsuite/std/time/tzdb/leap_seconds.cc: Initialize the
override_used test var to false.
---
libstdc++-v3/testsuite/std/time/tzdb/leap_seconds.cc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libstdc++-v3/testsuite/std/time/tzdb/leap_seconds.cc
b/libstdc++-v3/testsuite/std/time/tzdb/leap_seconds.cc
index 82303e8bdf0..2b289436583 100644
--- a/libstdc++-v3/testsuite/std/time/tzdb/leap_seconds.cc
+++ b/libstdc++-v3/testsuite/std/time/tzdb/leap_seconds.cc
@@ -7,7 +7,7 @@
#include
#include
-static bool override_used = true;
+static bool override_used = false;
namespace __gnu_cxx
{
--
2.37.1 (Apple Git-137.1)
Re: [PATCH] libstdc++: Test for tzdata.zi before fallback version files.
On Sat, 24 Dec 2022, 11:40 Iain Sandoe via Libstdc++,
wrote:
> I tested this (along with the other posted patches for zoneinfo) using
> an installation built from the 2022g release on x86_64-darwin21. Wider
> testing will follow. If we are in an installation without the tzdata.zi
> then although we'll report the version OK, the available functionality
> will be basic.
>
Yeah, my thinking was that you could still query the "remote version" i.e.
the one on disk, even if it can't be loaded (in which case, the basic
fallback one has version "ersatz", so you can tell it doesn't match the one
on disk).
> OK for trunk?
> Iain
>
> --- 8< ---
>
> Several systems/distributions do not provide the raw tzdata.zi file in
> their zoneinfo installation. However, we might provide an alternate
> installation path at configure time, so that we should check for the
> tzdata.zi file first and then fall back to system-specific files like
> +VERSION etc. on those systems.
>
Oh yes, good point. If we have an override for tzdata then than is the
on-disk one and we should check its version.
OK for trunk, thanks.
> Signed-off-by: Iain Sandoe
>
> libstdc++-v3/ChangeLog:
>
> * src/c++20/tzdb.cc (remote_version): Look for the tzdata.zi
> file before falling back to system-specific ones on Darwin and
> BSD.
> ---
> libstdc++-v3/src/c++20/tzdb.cc | 17 ++---
> 1 file changed, 10 insertions(+), 7 deletions(-)
>
> diff --git a/libstdc++-v3/src/c++20/tzdb.cc
> b/libstdc++-v3/src/c++20/tzdb.cc
> index c4311d0902a..39e4466f932 100644
> --- a/libstdc++-v3/src/c++20/tzdb.cc
> +++ b/libstdc++-v3/src/c++20/tzdb.cc
> @@ -1061,16 +1061,11 @@ namespace std::chrono
>namespace
>{
> // Read the version number from a tzdata.zi file.
> +// Note that some systems do not have this file available by default
> +// but we can configure the library to point to an alternate
> installation.
> string
> remote_version(istream* zif)
> {
> -#if defined __NetBSD__
> -if (string ver; ifstream(zoneinfo_dir() + "/TZDATA_VERSION") >> ver)
> - return ver;
> -#elif defined __APPLE__
> -if (string ver; ifstream(zoneinfo_dir() + "/+VERSION") >> ver)
> - return ver;
> -#else
>ifstream f;
>if (!zif)
> {
> @@ -1083,6 +1078,14 @@ namespace std::chrono
>if (*zif >> hash >> label >> version)
> if (hash == '#' && label == "version")
> return version;
> +#if defined __NetBSD__
> +if (string ver; ifstream(zoneinfo_dir() + "/TZDATA_VERSION") >> ver)
> + return ver;
> +#elif defined __APPLE__
> +// The standard install on macOS has no tzdata.zi, but we can find the
> +// version from +VERSION.
> +if (string ver; ifstream(zoneinfo_dir() + "/+VERSION") >> ver)
> + return ver;
> #endif
>__throw_runtime_error("tzdb: no version found in tzdata.zi");
> }
> --
> 2.37.1 (Apple Git-137.1)
>
>
Re: [PATCH] libstdc++, testsuite: Correct an init.
On Sat, 24 Dec 2022, 11:43 Iain Sandoe via Libstdc++,
wrote:
> Noticed while debugging tz info support on Darwin, unless I miss
> some other reasoning...
> OK for trunk?
>
Doh, thanks. OK for trunk.
Iain
>
> --- 8< ---
>
> in leap_seconds.cc, we are testing to see if the function that
> overrides the default zoneinfo directory has been called. That
> is implemented with a static boolean that needs to be initialized
> to false.
>
> Signed-off-by: Iain Sandoe
>
> libstdc++-v3/ChangeLog:
>
> * testsuite/std/time/tzdb/leap_seconds.cc: Initialize the
> override_used test var to false.
> ---
> libstdc++-v3/testsuite/std/time/tzdb/leap_seconds.cc | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libstdc++-v3/testsuite/std/time/tzdb/leap_seconds.cc
> b/libstdc++-v3/testsuite/std/time/tzdb/leap_seconds.cc
> index 82303e8bdf0..2b289436583 100644
> --- a/libstdc++-v3/testsuite/std/time/tzdb/leap_seconds.cc
> +++ b/libstdc++-v3/testsuite/std/time/tzdb/leap_seconds.cc
> @@ -7,7 +7,7 @@
> #include
> #include
>
> -static bool override_used = true;
> +static bool override_used = false;
>
> namespace __gnu_cxx
> {
> --
> 2.37.1 (Apple Git-137.1)
>
>
Re: [PATCH] libstdc++: Export the __gnu_cxx::zoneinfo_dir_override symbol.
On Sat, 24 Dec 2022, 11:35 Iain Sandoe via Libstdc++,
wrote:
> If this is not the right place to export the symbol (or you do not want
> to export it in the general case), I can always add a platform-specific
> file for it. So far, tested on x86_64-darwin21, wider testing will
> follow over the holidays.
>
> OK for trunk?
>
I'd like to check if this causes the undefined weak symbol to be exported
on ELF, but I suppose that doesn't really cause any harm if it is. The
symbol name is in our own namespace so can't clash with user symbols. We
can't declare that function in a header, because "zoneinfo_dir_override" is
not a reserved name so could clash with user macros (we could prefix it
with underscores, but since it's possible to override it without the
library providing a declaration, I think it would be "nicer" to not use an
ugly reserved name for something users are supposed to define themselves).
Iain
>
> --- 8< ---
>
> This symbol needs to be visible in the library interface for Darwin
> to override it with a user-provided one.
>
> Signed-off-by: Iain Sandoe
>
> libstdc++-v3/ChangeLog:
>
> * config/abi/pre/gnu.ver (GLIBCXX_3.4):
> Add __gnu_cxx::zoneinfo_dir_override().
> ---
> libstdc++-v3/config/abi/pre/gnu.ver | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/libstdc++-v3/config/abi/pre/gnu.ver
> b/libstdc++-v3/config/abi/pre/gnu.ver
> index 570ffca8710..bd4ab450652 100644
> --- a/libstdc++-v3/config/abi/pre/gnu.ver
> +++ b/libstdc++-v3/config/abi/pre/gnu.ver
> @@ -1104,6 +1104,9 @@ GLIBCXX_3.4 {
> # std::uncaught_exception()
> _ZSt18uncaught_exceptionv;
>
> +# __gnu_cxx::zoneinfo_dir_override()
> +_ZN9__gnu_cxx21zoneinfo_dir_overrideEv
> +
># DO NOT DELETE THIS LINE. Port-specific symbols, if any, will be here.
>
>local:
> --
> 2.37.1 (Apple Git-137.1)
>
>
Re: [PATCH] libstdc++: Export the __gnu_cxx::zoneinfo_dir_override symbol.
> On 24 Dec 2022, at 12:12, Jonathan Wakely wrote:
>
>
>
> On Sat, 24 Dec 2022, 11:35 Iain Sandoe via Libstdc++,
> wrote:
> If this is not the right place to export the symbol (or you do not want
> to export it in the general case), I can always add a platform-specific
> file for it. So far, tested on x86_64-darwin21, wider testing will
> follow over the holidays.
>
> OK for trunk?
>
> I'd like to check if this causes the undefined weak symbol to be exported on
> ELF,
I’d expect so, since it’s in the common file.
> but I suppose that doesn't really cause any harm if it is. The symbol name is
> in our own namespace so can't clash with user symbols. We can't declare that
> function in a header, because "zoneinfo_dir_override" is not a reserved name
> so could clash with user macros (we could prefix it with underscores, but
> since it's possible to override it without the library providing a
> declaration, I think it would be "nicer" to not use an ugly reserved name for
> something users are supposed to define themselves).
I can also investigate the alternate solution for Darwin - where we pass
-U,symbolname to the linker.
In that case, we do not need to provide a weak def. in the library (it looks
more ELF-like) but the symbol
does still need to be exported - however that could Darwin-local too as noted
above.
(none of this is urgent, bootstrap is fixed - I was just poking at the problems
while they were fresh in
my mind; although the fails are removed when I configure to an installation
with tzdata.zi, there are
still fails to deal with when using the system installation .. so I’m not
’there’ yet .. )
cheers
Iain
>
>
>
>
> Iain
>
> --- 8< ---
>
> This symbol needs to be visible in the library interface for Darwin
> to override it with a user-provided one.
>
> Signed-off-by: Iain Sandoe
>
> libstdc++-v3/ChangeLog:
>
> * config/abi/pre/gnu.ver (GLIBCXX_3.4):
> Add __gnu_cxx::zoneinfo_dir_override().
> ---
> libstdc++-v3/config/abi/pre/gnu.ver | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/libstdc++-v3/config/abi/pre/gnu.ver
> b/libstdc++-v3/config/abi/pre/gnu.ver
> index 570ffca8710..bd4ab450652 100644
> --- a/libstdc++-v3/config/abi/pre/gnu.ver
> +++ b/libstdc++-v3/config/abi/pre/gnu.ver
> @@ -1104,6 +1104,9 @@ GLIBCXX_3.4 {
> # std::uncaught_exception()
> _ZSt18uncaught_exceptionv;
>
> +# __gnu_cxx::zoneinfo_dir_override()
> +_ZN9__gnu_cxx21zoneinfo_dir_overrideEv
> +
># DO NOT DELETE THIS LINE. Port-specific symbols, if any, will be here.
>
>local:
> --
> 2.37.1 (Apple Git-137.1)
>
Re: [PATCH] libstdc++: Test for tzdata.zi before fallback version files.
On Dez 24 2022, Iain Sandoe via Gcc-patches wrote:
> @@ -1083,6 +1078,14 @@ namespace std::chrono
>if (*zif >> hash >> label >> version)
> if (hash == '#' && label == "version")
> return version;
> +#if defined __NetBSD__
> +if (string ver; ifstream(zoneinfo_dir() + "/TZDATA_VERSION") >> ver)
> + return ver;
> +#elif defined __APPLE__
> +// The standard install on macOS has no tzdata.zi, but we can find the
> +// version from +VERSION.
> +if (string ver; ifstream(zoneinfo_dir() + "/+VERSION") >> ver)
> + return ver;
> #endif
>__throw_runtime_error("tzdb: no version found in tzdata.zi");
> }
Looks like indentation is off here.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
Re: Adding a new thread model to GCC
On 2022-12-24 05:58, NightStrike wrote:
I think this might have broken fortran. I'm assuming because the
backtrace includes gthr.h, and I just did a git pull:
In file included from /tmp/rtmingw/mingw/include/windows.h:71,
from ../libgcc/gthr-default.h:606,
from ../../../libgfortran/../libgcc/gthr.h:148,
from ../../../libgfortran/io/io.h:33,
from ../../../libgfortran/runtime/error.c:27:
../../../libgfortran/io/io.h:298:24: error: expected identifier before
numeric constant
298 | { CC_LIST, CC_FORTRAN, CC_NONE,
|^~~
yes, you are right!
this is because the `CC_NONE` was previously defined in `wingdi.h` as
`#define CC_NONE 0`
thinking...
Re: Adding a new thread model to GCC
On 2022-12-24 13:50, i.nix...@autistici.org wrote:
On 2022-12-24 05:58, NightStrike wrote:
I think this might have broken fortran. I'm assuming because the
backtrace includes gthr.h, and I just did a git pull:
In file included from /tmp/rtmingw/mingw/include/windows.h:71,
from ../libgcc/gthr-default.h:606,
from ../../../libgfortran/../libgcc/gthr.h:148,
from ../../../libgfortran/io/io.h:33,
from ../../../libgfortran/runtime/error.c:27:
../../../libgfortran/io/io.h:298:24: error: expected identifier before
numeric constant
298 | { CC_LIST, CC_FORTRAN, CC_NONE,
|^~~
yes, you are right!
this is because the `CC_NONE` was previously defined in `wingdi.h` as
`#define CC_NONE 0`
thinking...
fixed and tested.
Jonathan Yong, could you please apply the attached patch too?
kings regards!
diff --git a/libgcc/config/i386/gthr-win32.h b/libgcc/config/i386/gthr-win32.h
index 9485dd50bf9..2b5b782c894 100644
--- a/libgcc/config/i386/gthr-win32.h
+++ b/libgcc/config/i386/gthr-win32.h
@@ -93,8 +93,9 @@ see the files COPYING3 and COPYING.RUNTIME respectively. If not, see
#endif
#define WIN32_LEAN_AND_MEAN
#include
-/* Now undef the windows BOOL. */
+/* Now undef the windows BOOL and CC_NONE */
#undef BOOL
+#undef CC_NONE
/* Key structure for maintaining thread specific storage */
static DWORD __gthread_objc_data_tls = TLS_OUT_OF_INDEXES;
Re: Adding a new thread model to GCC
On 2022-12-24 15:42, i.nix...@autistici.org wrote: fixed and tested. Jonathan Yong, could you please apply the attached patch too? kings regards! oh no... please wait.
Re: [PATCH] RISC-V: Fix ICE for avl_info deprecated copy and pp_print error.
On Dez 23 2022, juzhe.zh...@rivai.ai wrote: > * config/riscv/riscv-vsetvl.cc (change_insn): Remove pp_print. > (avl_info::avl_info): Add copy function. > (vector_insn_info::dump): Remove pp_print. > * config/riscv/riscv-vsetvl.h: Add copy function. Survived bootstrap so far. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
[pushed] libgcc, Darwin: No early install for the compatibility libgcc_s.1.dylib.
Tested on i686, x86_64 Darwin and x86_64-linux-gnu (with a 32b multilib). pushed to master, thanks Iain --- 8< --- On Darwin, GCC now uses a libgcc_s.1.1 for builtins and forwards the system unwinder. We do, however, build a backwards compatibility libgcc_s.1.dylib. However, this is not needed by GCC and can cause incorrect operation when DYLD_LIBRARY_PATH is in use. Since we do not need or use it during the build, the solution is to skip the installation into the $build/gcc directory. Signed-off-by: Iain Sandoe libgcc/ChangeLog: * config/t-slibgcc-darwin (install-darwin-libgcc-stubs): Skip the install of libgcc_s.1.dylib when the installation is into the build gcc directory. --- libgcc/config/t-slibgcc-darwin | 21 ++--- 1 file changed, 14 insertions(+), 7 deletions(-) diff --git a/libgcc/config/t-slibgcc-darwin b/libgcc/config/t-slibgcc-darwin index a8f69666a82..cb0cbbdb1c5 100644 --- a/libgcc/config/t-slibgcc-darwin +++ b/libgcc/config/t-slibgcc-darwin @@ -72,14 +72,15 @@ all: libgcc_ehs$(SHLIB_EXT) LGCC_FILES += libgcc_ehs.$(SHLIB_SOVERSION)$(SHLIB_EXT) endif - -# Provide libgcc_s.1 for backwards compatibility. -LGCC_FILES += libgcc_s.1.dylib - endif INSTALL_FILES=$(LGCC_FILES) +ifeq ($(BUILD_LIBGCCS1),YES) +# Provide libgcc_s.1 for backwards compatibility. +INSTALL_FILES += libgcc_s.1.dylib +endif + # For the toplevel multilib, build FAT dylibs including all the multilibs. ifeq ($(MULTIBUILDTOP),) @@ -158,9 +159,15 @@ endif install-darwin-libgcc-stubs : $(mkinstalldirs) $(DESTDIR)$(slibdir) - for d in $(INSTALL_FILES) ; do \ - $(INSTALL_DATA) $$d $(DESTDIR)$(slibdir)/$$d || exit 1 ; \ - done + if test x$(slibdir) = x; then \ + for d in $(LGCC_FILES) ; do \ + $(INSTALL_DATA) $$d $(DESTDIR)$(slibdir)/$$d || exit 1 ; \ + done; \ + else \ + for d in $(INSTALL_FILES) ; do \ + $(INSTALL_DATA) $$d $(DESTDIR)$(slibdir)/$$d || exit 1 ; \ + done; \ + fi else -- 2.37.1 (Apple Git-137.1)
Re: [PATCH] libstdc++: Test for tzdata.zi before fallback version files.
> On 24 Dec 2022, at 12:25, Andreas Schwab wrote:
>
> On Dez 24 2022, Iain Sandoe via Gcc-patches wrote:
>
>> @@ -1083,6 +1078,14 @@ namespace std::chrono
>> if (*zif >> hash >> label >> version)
>> if (hash == '#' && label == "version")
>>return version;
>> +#if defined __NetBSD__
>> +if (string ver; ifstream(zoneinfo_dir() + "/TZDATA_VERSION") >> ver)
>> + return ver;
>> +#elif defined __APPLE__
>> +// The standard install on macOS has no tzdata.zi, but we can find the
>> +// version from +VERSION.
>> +if (string ver; ifstream(zoneinfo_dir() + "/+VERSION") >> ver)
>> + return ver;
>> #endif
>> __throw_runtime_error("tzdb: no version found in tzdata.zi");
>> }
>
> Looks like indentation is off here.
thanks, I corrected that before pushing the patch.
Iain
>
> --
> Andreas Schwab, sch...@linux-m68k.org
> GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
> "And now for something completely different."
[PATCH] Ada, Darwin: Do not link libgcc statically on Darwin [PR108202].
Tested on i686, x86-64 darwin, x86_64-linux (with a 32b multilib). OK for trunk? Iain --- 8< --- Normally, GCC executables are built with -static-libstdc++ -static-libgcc on Darwin. This is fine in most cases, because GCC executables typically do not use exceptions. However gnat1 does use exceptions and also pulls in system libraries that are linked against the installed shared libgcc which contains the system unwinder. This means that gnat1 effectively has two unwinder instances (which does not work reliably since the unwinders have global state). A recent change in the initialization of FDEs has made this a hard error now on Darwin versions with libgcc installed in /usr/lib (gnat1 now hangs when an exception is thrown). The solution is to link libgcc dynamically, picking up the installed system version. To do this we strip -static-libgcc from the link flags. PR ada/108202 gcc/ada/ChangeLog: * gcc-interface/Make-lang.in (GCC_LINKERFLAGS, GCC_LDFLAGS): Versions of ALL_LINKERFLAGS, LDFLAGS with -Werror and -static-libgcc filtered out for Darwin (-Werror only for other hosts). --- gcc/ada/gcc-interface/Make-lang.in | 14 -- 1 file changed, 12 insertions(+), 2 deletions(-) diff --git a/gcc/ada/gcc-interface/Make-lang.in b/gcc/ada/gcc-interface/Make-lang.in index 2acd195017e..64273c3bdb4 100644 --- a/gcc/ada/gcc-interface/Make-lang.in +++ b/gcc/ada/gcc-interface/Make-lang.in @@ -261,10 +261,20 @@ else endif # Strip -Werror during linking for the LTO bootstrap + +ifneq ($(findstring darwin,$(host)),) +# gnat1 uses exceptions which is incompatible with statically-linked libgcc +# on Darwin, since gnat1 also pulls in libraries linked with the system +# unwinder. +GCC_LINKERFLAGS = $(filter-out -Werror -static-libgcc, $(ALL_LINKERFLAGS)) +GCC_LDFLAGS = $(filter-out -static-libgcc, $(LDFLAGS)) +else GCC_LINKERFLAGS = $(filter-out -Werror, $(ALL_LINKERFLAGS)) +GCC_LDFLAGS = $(LDFLAGS) +endif -GCC_LINK=$(LINKER) $(GCC_LINKERFLAGS) $(LDFLAGS) -GCC_LLINK=$(LLINKER) $(GCC_LINKERFLAGS) $(LDFLAGS) +GCC_LINK=$(LINKER) $(GCC_LINKERFLAGS) $(GCC_LDFLAGS) +GCC_LLINK=$(LLINKER) $(GCC_LINKERFLAGS) $(GCC_LDFLAGS) # Lists of files for various purposes. -- 2.37.1 (Apple Git-137.1)
[PATCH] cp: warn uninitialized const/ref in base class [PR80681]
On this example:
```
struct Fine {
private:
const int f;
};
struct BuggyA {
const int a;
int &b;
};
struct BuggyB : private BuggyA {
};
```
g++ currently emits:
```
test.cc:3:19: warning: non-static const member ‘const int Fine::f’ in class
without a constructor [-Wuninitialized]
3 | const int f;
|
```
(relevant godbolt: https://godbolt.org/z/KGMK6e1zc)
The issue here is that g++ misses the uninitialized const and ref members in
BuggyA that are inherited as
private in BuggyB. It should warn about those members when checking BuggyB.
With this patch, g++ emits the following:
```
test.cc:3:19: warning: non-static const member ‘const int Fine::f’ in class
without a constructor [-Wuninitialized]
3 | const int f;
| ^
test.cc:7:19: warning: while processing ‘BuggyB’: non-static const member
‘const int BuggyA::a’ in class without a constructor [-Wuninitialized]
7 | const int a;
| ^
test.cc:7:19: note: ‘BuggyB’ inherits ‘BuggyA’ as private, so all fields
contained within ‘BuggyA’ are private to ‘BuggyB’
test.cc:8:14: warning: while processing ‘BuggyB’: non-static reference ‘int&
BuggyA::b’ in class without a constructor [-Wuninitialized]
8 | int &b;
| ^
test.cc:8:14: note: ‘BuggyB’ inherits ‘BuggyA’ as private, so all fields
contained within ‘BuggyA’ are private to ‘BuggyB’
```
Now, the compiler warns about the uninitialized members.
In terms of testing, I added three tests:
- a status quo test that makes sure that the existing warning behavior
works
- A simple test based off of the PR
- Another example with multiple inheritance
- A final example with mutliple levels of inheritance.
These tests all pass. I also bootstrapped the project without any
regressions.
PR c++/80681
gcc/cp/ChangeLog:
* class.cc (warn_uninitialized_const_and_ref): Extract warn logic
into new func, add inform for inheritance warning
(check_bases_and_members): Move warn logic to
warn_unintialized_const_and_ref, check subclasses for warnings
as well
gcc/testsuite/ChangeLog:
* g++.dg/pr80681-1.C: New test.
Signed-off-by: Charlie Sale
---
gcc/cp/class.cc | 110 +--
gcc/testsuite/g++.dg/pr80681-1.C | 51 ++
2 files changed, 142 insertions(+), 19 deletions(-)
create mode 100644 gcc/testsuite/g++.dg/pr80681-1.C
diff --git a/gcc/cp/class.cc b/gcc/cp/class.cc
index aebcb53739e..72172bea6ad 100644
--- a/gcc/cp/class.cc
+++ b/gcc/cp/class.cc
@@ -6018,6 +6018,76 @@ explain_non_literal_class (tree t)
}
}
+
+/* Warn for private const or reference class members that cannot be initialized
+ due to the class not having a default constructor. If a child type is
+ provided, then we are checking class_type's members in case they cannot be
+ initialized by child_type. If child_type is null, then we simply check
+ class_type. */
+static void
+warn_uninitialized_const_and_ref (tree class_type, tree child_type)
+{
+ /* Check the fields on this class type. */
+ tree field;
+ for (field = TYPE_FIELDS (class_type); field; field = DECL_CHAIN (field))
+{
+ /* We only want to check variable declarations.
+ Exclude fields that are not field decls or are not initialized. */
+ if (TREE_CODE (field) != FIELD_DECL
+ || DECL_INITIAL (field) != NULL_TREE)
+ continue;
+
+ tree type = TREE_TYPE (field);
+
+ if (TYPE_REF_P (type))
+ {
+ if (child_type != nullptr)
+ {
+ /* Show parent class while processing. */
+ auto_diagnostic_group d;
+ warning_at (DECL_SOURCE_LOCATION (field),
+ OPT_Wuninitialized, "while processing %qE: "
+ "non-static reference %q#D in class without a constructor",
+ child_type, field);
+ inform (DECL_SOURCE_LOCATION (field),
+ "%qE inherits %qE as private, so all fields "
+ "contained within %qE are private to %qE",
+ child_type, class_type, class_type, child_type);
+ }
+ else
+ {
+ warning_at (DECL_SOURCE_LOCATION (field),
+ OPT_Wuninitialized, "non-static reference %q#D "
+ "in class without a constructor", field);
+ }
+ }
+ else if (CP_TYPE_CONST_P (type)
+ && (!CLASS_TYPE_P (type)
+ || !TYPE_HAS_DEFAULT_CONSTRUCTOR (type)))
+ {
+ if (child_type)
+ {
+ /* ditto. */
+ auto_diagnostic_group d;
+ warning_at (DECL_SOURCE_LOCATION (field),
+ OPT_Wuninitialized, "while processing %qE: "
+ "non-static const member %q#D in class "
+ "without a constructor", child_type, field);
+ inform (DECL_SOURCE_LOCATION (field),
+ "%qE inherits %qE as private, so all fields "
Re: [PATCH] libgccjit: Fix a failing test
Ping David Le jeu. 15 déc. 2022 à 11:34, Guillaume Gomez a écrit : > Forgot it indeed, thanks for notifying me! > > I modified the commit message to add it and added it into this email. > > Le mer. 14 déc. 2022 à 16:12, Antoni Boucher a écrit : > >> Thanks! >> >> In your patch, you're missing this line at the end of the commit >> message: >> >>Signed-off-by: Guillaume Gomez >> >> On Wed, 2022-12-14 at 14:39 +0100, Guillaume Gomez via Jit wrote: >> > Hi, >> > >> > This fixes bug 107999. >> > >> > Thanks in advance for the review. >> >>
Re: Adding a new thread model to GCC
On 2022-12-24 15:57, i.nix...@autistici.org wrote: On 2022-12-24 15:42, i.nix...@autistici.org wrote: fixed and tested. Jonathan Yong, could you please apply the attached patch too? kings regards! oh no... please wait. fixed now. bootstrapped successfully! Jonathan Yong, could you please apply the attached patch too? best! diff --git a/libgcc/config/i386/gthr-win32.h b/libgcc/config/i386/gthr-win32.h index 9485dd50bf9..146357fa436 100644 --- a/libgcc/config/i386/gthr-win32.h +++ b/libgcc/config/i386/gthr-win32.h @@ -93,8 +93,9 @@ see the files COPYING3 and COPYING.RUNTIME respectively. If not, see #endif #define WIN32_LEAN_AND_MEAN #include -/* Now undef the windows BOOL. */ +/* Now undef the windows BOOL and CC_NONE */ #undef BOOL +#undef CC_NONE /* Key structure for maintaining thread specific storage */ static DWORD __gthread_objc_data_tls = TLS_OUT_OF_INDEXES; @@ -604,6 +605,7 @@ __gthread_cond_timedwait (__gthread_cond_t *__cond, __gthread_mutex_t *__mutex, #define WIN32_LEAN_AND_MEAN #include +#undef CC_NONE __GTHREAD_WIN32_INLINE int __gthread_detach (__gthread_t __thr)
[Committed] Tweak new gcc.target/i386/pr107548-1.c for -march=cascadelake.
My recently added testcases gcc.target/i386/pr107548-[12].c need to be
tweaked slightly for -march=cascadelake. Committed as obvious.
2022-12-24 Roger Sayle
gcc/testsuite/ChangeLog
PR target/107548
* gcc.target/i386/pr107548-1.c: Match both vmovd and movd.
* gcc.target/i386/pr107548-2.c: Match both vpaddq and paddq.
Roger
--
diff --git a/gcc/testsuite/gcc.target/i386/pr107548-1.c
b/gcc/testsuite/gcc.target/i386/pr107548-1.c
index da78f75..f384492 100644
--- a/gcc/testsuite/gcc.target/i386/pr107548-1.c
+++ b/gcc/testsuite/gcc.target/i386/pr107548-1.c
@@ -20,6 +20,6 @@ unsigned int foo3 (v4si a, v4si b)
return a[0] + a[3];
}
-/* { dg-final { scan-assembler-times "\tmovd\t" 3 } } */
-/* { dg-final { scan-assembler-times "paddd" 6 } } */
+/* { dg-final { scan-assembler-times "\tv?movd\t" 3 } } */
+/* { dg-final { scan-assembler-times "v?paddd" 6 } } */
/* { dg-final { scan-assembler-not "addl" } } */
diff --git a/gcc/testsuite/gcc.target/i386/pr107548-2.c
b/gcc/testsuite/gcc.target/i386/pr107548-2.c
index b57594e..58f7b1c 100644
--- a/gcc/testsuite/gcc.target/i386/pr107548-2.c
+++ b/gcc/testsuite/gcc.target/i386/pr107548-2.c
@@ -9,5 +9,5 @@ unsigned long long foo(v2di a, v2di b)
}
/* { dg-final { scan-assembler-not "\taddq\t" } } */
-/* { dg-final { scan-assembler-times "paddq" 2 } } */
-/* { dg-final { scan-assembler "psrldq" } } */
+/* { dg-final { scan-assembler-times "v?paddq" 2 } } */
+/* { dg-final { scan-assembler "v?psrldq" } } */
Re: Re: [PATCH] RISC-V: Fix ICE for avl_info deprecated copy and pp_print error.
I just want to make sure. You mean the bootstrap can pass now with this patch? If yes, plz merge this patch. Thank you so much. juzhe.zh...@rivai.ai From: Andreas Schwab Date: 2022-12-25 00:58 To: juzhe.zhong CC: gcc-patches Subject: Re: [PATCH] RISC-V: Fix ICE for avl_info deprecated copy and pp_print error. On Dez 23 2022, juzhe.zh...@rivai.ai wrote: > * config/riscv/riscv-vsetvl.cc (change_insn): Remove pp_print. > (avl_info::avl_info): Add copy function. > (vector_insn_info::dump): Remove pp_print. > * config/riscv/riscv-vsetvl.h: Add copy function. Survived bootstrap so far. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
Re: Adding a new thread model to GCC
On 12/24/22 21:22, i.nix...@autistici.org wrote: On 2022-12-24 15:57, i.nix...@autistici.org wrote: On 2022-12-24 15:42, i.nix...@autistici.org wrote: fixed and tested. Jonathan Yong, could you please apply the attached patch too? kings regards! oh no... please wait. fixed now. bootstrapped successfully! Jonathan Yong, could you please apply the attached patch too? best! Done, pushed to master, thanks.
