Re: ZynqMP APU RAM Start
On 14.05.24 08:03, Sebastian Huber wrote: Hello, the ZynqMP APU RAM start addresses are far away from 0x0: Sorry, I selected the wrong mailing list. -- embedded brains GmbH & Co. KG Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/
ZynqMP APU RAM Start
Hello,
the ZynqMP APU RAM start addresses are far away from 0x0:
cat spec/build/bsps/aarch64/xilinx-zynqmp/optramori.yml
SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
actions:
- get-integer: null
- assert-uint32: null
- env-assign: null
- format-and-define: null
build-type: option
copyrights:
- Copyright (C) 2020 On-Line Applications Research (OAR)
default:
- enabled-by:
- aarch64/xilinx_zynqmp_lp64_a53
- aarch64/xilinx_zynqmp_ilp32_zu3eg
- aarch64/xilinx_zynqmp_lp64_cfc400x
- aarch64/xilinx_zynqmp_lp64_zu3eg
value: 0x1000
- enabled-by: true
value: 0x40018000
description: |
base address of memory area available to the BSP
enabled-by: true
format: '{:#010x}'
links: []
name: BSP_XILINX_ZYNQMP_RAM_BASE
type: build
What is the rationale for doing this? Any objections to change the start
address to 0x0?
What is the MMU page size used by the BSPs? Would it be possible to add
a NULL pointer protection page?
--
embedded brains GmbH & Co. KG
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax: +49-89-18 94 741 - 08
Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
Re: [V2][PATCH] gcc-14/changes.html: Deprecate a GCC C extension on flexible array members.
On 07.05.24 16:26, Qing Zhao wrote: Hi, Sebastian, Thanks for your explanation. Our goal is to deprecate the GCC extension on structure containing a flexible array member not at the end of another structure. In order to achieve this goal, we provided the warning option -Wflex-array-member-not-at-end for the users to locate all such cases in their source code and update the source code to eliminate such cases. What is the benefit of deprecating this GCC extension? If GCC extensions are removed, then it would be nice to enable the associated warnings by default. The static initialization of structures with flexible array members will still work as long as the flexible array members are at the end of the structures. Removing the support for flexible array members in the middle of compounds will make the static initialization practically infeasible. My question: is it possible to update your source code to move the structure with flexible array member to the end of the containing structure? i.e, in your example, in the struct Thread_Configured_control, move the field “Thread_Control Control” to the end of the structure? If we move the Thread_Control to the end, how would I add a configuration defined number of elements at the end? -- embedded brains GmbH & Co. KG Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/
Re: [V2][PATCH] gcc-14/changes.html: Deprecate a GCC C extension on flexible array members.
On 06.05.24 16:20, Qing Zhao wrote:
Hi, Sebastian,
Looks like that the behavior you described is correct.
What’s your major concern? ( a little confused).
I am concerned that the static initialization of structures with
flexible array members no longer works. In the RTEMS open source
real-time operating system, we use flexible array members in some parts.
One example is the thread control block which is used to manage a thread:
struct _Thread_Control {
/** This field is the object management structure for each thread. */
Objects_Control Object;
[...]
/**
* @brief Variable length array of user extension pointers.
*
* The length is defined by the application via .
*/
void *extensions[];
};
In a static configuration of the operating system we have something like
this:
struct Thread_Configured_control {
/*
* This was added to address the following warning.
* warning: invalid use of structure with flexible array member
*/
#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wpedantic"
Thread_Control Control;
#pragma GCC diagnostic pop
#if CONFIGURE_MAXIMUM_USER_EXTENSIONS > 0
void *extensions[ CONFIGURE_MAXIMUM_USER_EXTENSIONS + 1 ];
#endif
Configuration_Scheduler_node Scheduler_nodes[
_CONFIGURE_SCHEDULER_COUNT ];
RTEMS_API_Control API_RTEMS;
#ifdef RTEMS_POSIX_API
POSIX_API_Control API_POSIX;
#endif
#if CONFIGURE_MAXIMUM_THREAD_NAME_SIZE > 1
char name[ CONFIGURE_MAXIMUM_THREAD_NAME_SIZE ];
#endif
#if defined(_CONFIGURE_ENABLE_NEWLIB_REENTRANCY) && \
!defined(_REENT_THREAD_LOCAL)
struct _reent Newlib;
#endif
};
This is used to define a table of thread control blocks:
Thread_Configured_control \
name##_Objects[ _Objects_Maximum_per_allocation( max ) ]; \
static RTEMS_SECTION( ".noinit.rtems.content.objects." #name ) \
I would like no know which consequences the deprecation this GCC
extension has.
--
embedded brains GmbH & Co. KG
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax: +49-89-18 94 741 - 08
Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
Re: [V2][PATCH] gcc-14/changes.html: Deprecate a GCC C extension on flexible array members.
On 06.05.24 09:08, Richard Biener wrote:
On Sat, 4 May 2024, Sebastian Huber wrote:
On 07.08.23 16:22, Qing Zhao via Gcc-patches wrote:
Hi,
This is the 2nd version of the patch.
Comparing to the 1st version, the only change is to address Richard's
comment on refering a warning option for diagnosing deprecated behavior.
Okay for committing?
thanks.
Qing
==
*htdocs/gcc-14/changes.html (Caveats): Add notice about deprecating a C
extension about flexible array members.
---
htdocs/gcc-14/changes.html | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/htdocs/gcc-14/changes.html b/htdocs/gcc-14/changes.html
index dad1ba53..eae25f1a 100644
--- a/htdocs/gcc-14/changes.html
+++ b/htdocs/gcc-14/changes.html
@@ -30,7 +30,18 @@ a work-in-progress.
Caveats
- ...
+ C:
+ Support for the GCC extension, a structure containing a C99 flexible
array
+ member, or a union containing such a structure, is not the last field
of
+ another structure, is deprecated. Refer to
+ https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html;>
+ Zero Length Arrays.
+ Any code relying on this extension should be modifed to ensure that
+ C99 flexible array members only end up at the ends of structures.
+ Please use the warning option
+ https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wflex-array-member-not-at-end;>-Wflex-array-member-not-at-end
to
+ identify all such cases in the source code and modify them.
+
I have a question with respect to the static initialization of flexible array
members. According to the documentation this is supported by GCC:
https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
"GCC allows static initialization of flexible array members. This is
equivalent to defining a new structure containing the original structure
followed by an array of sufficient size to contain the data. E.g. in the
following, f1 is constructed as if it were declared like f2.
struct f1 {
int x; int y[];
} f1 = { 1, { 2, 3, 4 } };
struct f2 {
struct f1 f1; int data[3];
} f2 = { { 1 }, { 2, 3, 4 } };
"
However, when I compile this code, I get a warning like this:
flex-array.c:6:13: warning: structure containing a flexible array member is
not at the end of another structure [-Wflex-array-member-not-at-end]
6 | struct f1 f1; int data[3];
|
In general, I agree that flexible array members should be at the end, however
the support for static initialization is quite important from my point of view
especially for applications for embedded systems. Here, dynamic allocations
may not be allowed or feasible.
I do not get a diagnostic for this on trunk? And I agree there shouldn't
be any.
It seems that this warning is not enabled by -Wall and -Wextra. I tried
this:
gcc -Wflex-array-member-not-at-end -S -o - flex-array.c
.file "flex-array.c"
flex-array.c:6:13: warning: structure containing a flexible array member
is not at the end of another structure [-Wflex-array-member-not-at-end]
6 | struct f1 f1; int data[3];
| ^~
.text
.globl f1
.data
.align 4
.type f1, @object
.size f1, 16
f1:
.long 1
.long 2
.long 3
.long 4
.globl f2
.align 16
.type f2, @object
.size f2, 16
f2:
.long 1
.long 2
.long 3
.long 4
.ident "GCC: (GNU) 15.0.0 20240506 (experimental) [master
ec1cdad89af]"
.section.note.GNU-stack,"",@progbits
--
embedded brains GmbH & Co. KG
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax: +49-89-18 94 741 - 08
Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
Re: [V2][PATCH] gcc-14/changes.html: Deprecate a GCC C extension on flexible array members.
On 07.08.23 16:22, Qing Zhao via Gcc-patches wrote:
Hi,
This is the 2nd version of the patch.
Comparing to the 1st version, the only change is to address Richard's
comment on refering a warning option for diagnosing deprecated behavior.
Okay for committing?
thanks.
Qing
==
*htdocs/gcc-14/changes.html (Caveats): Add notice about deprecating a C
extension about flexible array members.
---
htdocs/gcc-14/changes.html | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/htdocs/gcc-14/changes.html b/htdocs/gcc-14/changes.html
index dad1ba53..eae25f1a 100644
--- a/htdocs/gcc-14/changes.html
+++ b/htdocs/gcc-14/changes.html
@@ -30,7 +30,18 @@ a work-in-progress.
Caveats
- ...
+ C:
+ Support for the GCC extension, a structure containing a C99 flexible
array
+ member, or a union containing such a structure, is not the last field of
+ another structure, is deprecated. Refer to
+ https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html;>
+ Zero Length Arrays.
+ Any code relying on this extension should be modifed to ensure that
+ C99 flexible array members only end up at the ends of structures.
+ Please use the warning option
+ https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wflex-array-member-not-at-end;>-Wflex-array-member-not-at-end
to
+ identify all such cases in the source code and modify them.
+
I have a question with respect to the static initialization of flexible
array members. According to the documentation this is supported by GCC:
https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
"GCC allows static initialization of flexible array members. This is
equivalent to defining a new structure containing the original structure
followed by an array of sufficient size to contain the data. E.g. in the
following, f1 is constructed as if it were declared like f2.
struct f1 {
int x; int y[];
} f1 = { 1, { 2, 3, 4 } };
struct f2 {
struct f1 f1; int data[3];
} f2 = { { 1 }, { 2, 3, 4 } };
"
However, when I compile this code, I get a warning like this:
flex-array.c:6:13: warning: structure containing a flexible array member
is not at the end of another structure [-Wflex-array-member-not-at-end]
6 | struct f1 f1; int data[3];
|
In general, I agree that flexible array members should be at the end,
however the support for static initialization is quite important from my
point of view especially for applications for embedded systems. Here,
dynamic allocations may not be allowed or feasible.
--
embedded brains GmbH & Co. KG
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax: +49-89-18 94 741 - 08
Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
Re: [PATCH v2] gcc-14: Mention that some warnings are now errors
On 03.05.24 17:06, Jonathan Wakely wrote: I think it would be helpful to reference this change in the C section. This warning to error change causes some issues with legacy software. I agree it should be mentioned, but I would put it in the caveats section at the top, not as the last item of the C section. How about this? OK for wwwdocs? This is fine for me as well, thanks. -- embedded brains GmbH & Co. KG Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/
Re: [PATCH v2] gcc-14: Mention that some warnings are now errors
On 24.04.24 14:28, Sebastian Huber wrote: - Am 15. Apr 2024 um 8:05 schrieb Sebastian Huber sebastian.hu...@embedded-brains.de: --- v2: Remove listing of options. htdocs/gcc-14/changes.html | 2 ++ 1 file changed, 2 insertions(+) diff --git a/htdocs/gcc-14/changes.html b/htdocs/gcc-14/changes.html index 8ac08e9a..665d050a 100644 --- a/htdocs/gcc-14/changes.html +++ b/htdocs/gcc-14/changes.html @@ -231,6 +231,8 @@ a work-in-progress. previous options -std=c2x, -std=gnu2x and -Wc11-c2x-compat, which are deprecated but remain supported. + Some warnings are now errors by default (see also + Porting to GCC 14). C++ -- 2.35.3 Ping. I think it would be helpful to reference this change in the C section. This warning to error change causes some issues with legacy software. -- embedded brains GmbH & Co. KG Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/
Re: [PATCH v2] gcc-14: Mention that some warnings are now errors
- Am 15. Apr 2024 um 8:05 schrieb Sebastian Huber sebastian.hu...@embedded-brains.de: > --- > v2: Remove listing of options. > > htdocs/gcc-14/changes.html | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/htdocs/gcc-14/changes.html b/htdocs/gcc-14/changes.html > index 8ac08e9a..665d050a 100644 > --- a/htdocs/gcc-14/changes.html > +++ b/htdocs/gcc-14/changes.html > @@ -231,6 +231,8 @@ a work-in-progress. > previous options -std=c2x, -std=gnu2x > and -Wc11-c2x-compat, which are deprecated but remain > supported. > + Some warnings are now errors by default (see also > + Porting to GCC 14). > > > C++ > -- > 2.35.3 Ping. -- embedded brains GmbH & Co. KG Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/
[gcc r13-8615] RTEMS: Fix powerpc configuration
https://gcc.gnu.org/g:3bfe591d62551605a9d2c6422257dc67b0fa9a2f commit r13-8615-g3bfe591d62551605a9d2c6422257dc67b0fa9a2f Author: Sebastian Huber Date: Mon Feb 12 14:53:21 2024 +0100 RTEMS: Fix powerpc configuration gcc/ChangeLog: * config/rs6000/rtems.h (OS_MISSING_POWERPC64): Define. (cherry picked from commit ce3c743d8cfbadc0aaa80267bc002fd05267ffac) Diff: --- gcc/config/rs6000/rtems.h | 4 1 file changed, 4 insertions(+) diff --git a/gcc/config/rs6000/rtems.h b/gcc/config/rs6000/rtems.h index 57a2325991b..b36e64fec77 100644 --- a/gcc/config/rs6000/rtems.h +++ b/gcc/config/rs6000/rtems.h @@ -36,6 +36,10 @@ #endif #endif +/* RTEMS configured for the 32-bit multilibs doesn't support saving and + restoring 64-bit regs. */ +#define OS_MISSING_POWERPC64 !TARGET_64BIT + /* Copy and paste from linux64.h and freebsd64.h */ #undef TARGET_AIX #defineTARGET_AIX TARGET_64BIT
[gcc r13-8614] RTEMS: Add multilib configuration for aarch64
https://gcc.gnu.org/g:b68995dcafa3412bcf0bfd19947758d807527dd2
commit r13-8614-gb68995dcafa3412bcf0bfd19947758d807527dd2
Author: Sebastian Huber
Date: Mon Mar 25 08:00:02 2024 +0100
RTEMS: Add multilib configuration for aarch64
Add a multilib with workarounds for Cortex-A53 errata.
gcc/ChangeLog:
* config.gcc (aarch64-*-rtems*): Add target makefile fragment
t-aarch64-rtems.
* config/aarch64/t-aarch64-rtems: New file.
(cherry picked from commit ddee4376d15ddde9280c9a6725ddd76bf33f2871)
Diff:
---
gcc/config.gcc | 1 +
gcc/config/aarch64/t-aarch64-rtems | 42 ++
2 files changed, 43 insertions(+)
diff --git a/gcc/config.gcc b/gcc/config.gcc
index 648b3dc2110..c3b73d05eb7 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -1139,6 +1139,7 @@ aarch64*-*-elf | aarch64*-*-fuchsia* | aarch64*-*-rtems*)
;;
aarch64-*-rtems*)
tm_file="${tm_file} aarch64/rtems.h rtems.h"
+ tmake_file="${tmake_file} aarch64/t-aarch64-rtems"
;;
esac
case $target in
diff --git a/gcc/config/aarch64/t-aarch64-rtems
b/gcc/config/aarch64/t-aarch64-rtems
new file mode 100644
index 000..7598d636165
--- /dev/null
+++ b/gcc/config/aarch64/t-aarch64-rtems
@@ -0,0 +1,42 @@
+# Multilibs for aarch64 RTEMS targets.
+#
+# Copyright (C) 2024 Free Software Foundation, Inc.
+#
+# This file is part of GCC.
+#
+# GCC is free software; you can redistribute it and/or modify it
+# under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 3, or (at your option)
+# any later version.
+#
+# GCC is distributed in the hope that it will be useful, but
+# WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+# General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with GCC; see the file COPYING3. If not see
+# <http://www.gnu.org/licenses/>.
+
+MULTILIB_OPTIONS =
+MULTILIB_DIRNAMES =
+MULTILIB_REQUIRED =
+
+MULTILIB_OPTIONS += mabi=ilp32
+MULTILIB_DIRNAMES += ilp32
+
+MULTILIB_OPTIONS += mno-outline-atomics
+MULTILIB_DIRNAMES += nooa
+
+MULTILIB_OPTIONS += mcpu=cortex-a53
+MULTILIB_DIRNAMES += a53
+
+MULTILIB_OPTIONS += mfix-cortex-a53-835769
+MULTILIB_DIRNAMES += fix835769
+
+MULTILIB_OPTIONS += mfix-cortex-a53-843419
+MULTILIB_DIRNAMES += fix843419
+
+MULTILIB_REQUIRED += mabi=ilp32
+MULTILIB_REQUIRED +=
mabi=ilp32/mno-outline-atomics/mcpu=cortex-a53/mfix-cortex-a53-835769/mfix-cortex-a53-843419
+MULTILIB_REQUIRED +=
mno-outline-atomics/mcpu=cortex-a53/mfix-cortex-a53-835769/mfix-cortex-a53-843419
[PATCH v2] gcc-14: Mention that some warnings are now errors
--- v2: Remove listing of options. htdocs/gcc-14/changes.html | 2 ++ 1 file changed, 2 insertions(+) diff --git a/htdocs/gcc-14/changes.html b/htdocs/gcc-14/changes.html index 8ac08e9a..665d050a 100644 --- a/htdocs/gcc-14/changes.html +++ b/htdocs/gcc-14/changes.html @@ -231,6 +231,8 @@ a work-in-progress. previous options -std=c2x, -std=gnu2x and -Wc11-c2x-compat, which are deprecated but remain supported. + Some warnings are now errors by default (see also + Porting to GCC 14). C++ -- 2.35.3
[wwwdocs] gcc-14: Mention that some warnings are now errors
--- htdocs/gcc-14/changes.html | 11 +++ 1 file changed, 11 insertions(+) diff --git a/htdocs/gcc-14/changes.html b/htdocs/gcc-14/changes.html index 8ac08e9a..a183fad8 100644 --- a/htdocs/gcc-14/changes.html +++ b/htdocs/gcc-14/changes.html @@ -231,6 +231,17 @@ a work-in-progress. previous options -std=c2x, -std=gnu2x and -Wc11-c2x-compat, which are deprecated but remain supported. + The following warnings are now errors (see also +Porting to GCC 14): + + -Werror=declaration-missing-parameter-type + -Werror=implicit-function-declaration + -Werror=implicit-int + -Werror=incompatible-pointer-types + -Werror=int-conversion + -Werror=return-mismatch + + C++ -- 2.35.3
[gcc r14-9871] RTEMS: Fix powerpc configuration
https://gcc.gnu.org/g:ce3c743d8cfbadc0aaa80267bc002fd05267ffac commit r14-9871-gce3c743d8cfbadc0aaa80267bc002fd05267ffac Author: Sebastian Huber Date: Mon Feb 12 14:53:21 2024 +0100 RTEMS: Fix powerpc configuration gcc/ChangeLog: * config/rs6000/rtems.h (OS_MISSING_POWERPC64): Define. Diff: --- gcc/config/rs6000/rtems.h | 4 1 file changed, 4 insertions(+) diff --git a/gcc/config/rs6000/rtems.h b/gcc/config/rs6000/rtems.h index 5a27f02960f..06f481fcd7b 100644 --- a/gcc/config/rs6000/rtems.h +++ b/gcc/config/rs6000/rtems.h @@ -36,6 +36,10 @@ #endif #endif +/* RTEMS configured for the 32-bit multilibs doesn't support saving and + restoring 64-bit regs. */ +#define OS_MISSING_POWERPC64 !TARGET_64BIT + /* Copy and paste from linux64.h and freebsd64.h */ #undef TARGET_AIX #defineTARGET_AIX TARGET_64BIT
Re: [PATCH v3 06/11] c: Turn -Wimplicit-function-declaration into a permerror
On 09.04.24 14:10, Sam James wrote: Sebastian Huber writes: On 20.11.23 10:56, Florian Weimer wrote: In the future, it may make sense to avoid cascading errors from the implicit declaration, especially its assumed int return type. This change here only changes the kind of the diagnostic, not its wording or consequences. Maybe this change should be added to the GCC 14 release notes. Can you be more specific? Florian wrote about it in detail at https://gcc.gnu.org/gcc-14/porting_to.html#c. If you're referring specifically to the cascade-affecting-diagnostics, that change hasn't been made yet. What am I missing? I searched for "implicit-function-declaration" at https://gcc.gnu.org/gcc-14/changes.html and found nothing. All right, the https://gcc.gnu.org/gcc-14/porting_to.html has a description, but this is one step away from the release notes. Maybe something like this could be added to the release notes: diff --git a/htdocs/gcc-14/changes.html b/htdocs/gcc-14/changes.html index ff69e859..90a14f37 100644 --- a/htdocs/gcc-14/changes.html +++ b/htdocs/gcc-14/changes.html @@ -231,6 +231,17 @@ a work-in-progress. previous options -std=c2x, -std=gnu2x and -Wc11-c2x-compat, which are deprecated but remain supported. + The following warnings are now errors (see also +Porting to GCC 14): + + -Werror=declaration-missing-parameter-type + -Werror=implicit-function-declaration + -Werror=implicit-int + -Werror=incompatible-pointer-types + -Werror=int-conversion + -Werror=return-mismatch + + C++ -- embedded brains GmbH & Co. KG Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/
Re: [PATCH v3 06/11] c: Turn -Wimplicit-function-declaration into a permerror
On 20.11.23 10:56, Florian Weimer wrote: In the future, it may make sense to avoid cascading errors from the implicit declaration, especially its assumed int return type. This change here only changes the kind of the diagnostic, not its wording or consequences. Maybe this change should be added to the GCC 14 release notes. -- embedded brains GmbH & Co. KG Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/
[gcc r14-9854] RTEMS: Add multilib configuration for aarch64
https://gcc.gnu.org/g:ddee4376d15ddde9280c9a6725ddd76bf33f2871
commit r14-9854-gddee4376d15ddde9280c9a6725ddd76bf33f2871
Author: Sebastian Huber
Date: Mon Mar 25 08:00:02 2024 +0100
RTEMS: Add multilib configuration for aarch64
Add a multilib with workarounds for Cortex-A53 errata.
gcc/ChangeLog:
* config.gcc (aarch64-*-rtems*): Add target makefile fragment
t-aarch64-rtems.
* config/aarch64/t-aarch64-rtems: New file.
Diff:
---
gcc/config.gcc | 1 +
gcc/config/aarch64/t-aarch64-rtems | 42 ++
2 files changed, 43 insertions(+)
diff --git a/gcc/config.gcc b/gcc/config.gcc
index 2e320dd26c5..63a88bce484 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -1199,6 +1199,7 @@ aarch64*-*-elf | aarch64*-*-fuchsia* | aarch64*-*-rtems*)
;;
aarch64-*-rtems*)
tm_file="${tm_file} aarch64/rtems.h rtems.h"
+ tmake_file="${tmake_file} aarch64/t-aarch64-rtems"
;;
esac
case $target in
diff --git a/gcc/config/aarch64/t-aarch64-rtems
b/gcc/config/aarch64/t-aarch64-rtems
new file mode 100644
index 000..7598d636165
--- /dev/null
+++ b/gcc/config/aarch64/t-aarch64-rtems
@@ -0,0 +1,42 @@
+# Multilibs for aarch64 RTEMS targets.
+#
+# Copyright (C) 2024 Free Software Foundation, Inc.
+#
+# This file is part of GCC.
+#
+# GCC is free software; you can redistribute it and/or modify it
+# under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 3, or (at your option)
+# any later version.
+#
+# GCC is distributed in the hope that it will be useful, but
+# WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+# General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with GCC; see the file COPYING3. If not see
+# <http://www.gnu.org/licenses/>.
+
+MULTILIB_OPTIONS =
+MULTILIB_DIRNAMES =
+MULTILIB_REQUIRED =
+
+MULTILIB_OPTIONS += mabi=ilp32
+MULTILIB_DIRNAMES += ilp32
+
+MULTILIB_OPTIONS += mno-outline-atomics
+MULTILIB_DIRNAMES += nooa
+
+MULTILIB_OPTIONS += mcpu=cortex-a53
+MULTILIB_DIRNAMES += a53
+
+MULTILIB_OPTIONS += mfix-cortex-a53-835769
+MULTILIB_DIRNAMES += fix835769
+
+MULTILIB_OPTIONS += mfix-cortex-a53-843419
+MULTILIB_DIRNAMES += fix843419
+
+MULTILIB_REQUIRED += mabi=ilp32
+MULTILIB_REQUIRED +=
mabi=ilp32/mno-outline-atomics/mcpu=cortex-a53/mfix-cortex-a53-835769/mfix-cortex-a53-843419
+MULTILIB_REQUIRED +=
mno-outline-atomics/mcpu=cortex-a53/mfix-cortex-a53-835769/mfix-cortex-a53-843419
[PATCH] RTEMS: Add multilib configuration for aarch64
Add a multilib with workarounds for Cortex-A53 errata.
gcc/ChangeLog:
* config.gcc (aarch64-*-rtems*): Add target makefile fragment
t-aarch64-rtems.
* config/aarch64/t-aarch64-rtems: New file.
---
gcc/config.gcc | 1 +
gcc/config/aarch64/t-aarch64-rtems | 42 ++
2 files changed, 43 insertions(+)
create mode 100644 gcc/config/aarch64/t-aarch64-rtems
diff --git a/gcc/config.gcc b/gcc/config.gcc
index 648b3dc2110..c3b73d05eb7 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -1139,6 +1139,7 @@ aarch64*-*-elf | aarch64*-*-fuchsia* | aarch64*-*-rtems*)
;;
aarch64-*-rtems*)
tm_file="${tm_file} aarch64/rtems.h rtems.h"
+ tmake_file="${tmake_file} aarch64/t-aarch64-rtems"
;;
esac
case $target in
diff --git a/gcc/config/aarch64/t-aarch64-rtems
b/gcc/config/aarch64/t-aarch64-rtems
new file mode 100644
index 000..11f8c380222
--- /dev/null
+++ b/gcc/config/aarch64/t-aarch64-rtems
@@ -0,0 +1,42 @@
+# Machine description for AArch64 architecture.
+# Copyright (C) 2024 Free Software Foundation, Inc.
+#
+# This file is part of GCC.
+#
+# GCC is free software; you can redistribute it and/or modify it
+# under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 3, or (at your option)
+# any later version.
+#
+# GCC is distributed in the hope that it will be useful, but
+# WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+# General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with GCC; see the file COPYING3. If not see
+#
[PATCH v2] RTEMS: Add multilib configuration for aarch64
Add a multilib with workarounds for Cortex-A53 errata.
gcc/ChangeLog:
* config.gcc (aarch64-*-rtems*): Add target makefile fragment
t-aarch64-rtems.
* config/aarch64/t-aarch64-rtems: New file.
---
gcc/config.gcc | 1 +
gcc/config/aarch64/t-aarch64-rtems | 42 ++
2 files changed, 43 insertions(+)
create mode 100644 gcc/config/aarch64/t-aarch64-rtems
diff --git a/gcc/config.gcc b/gcc/config.gcc
index 648b3dc2110..c3b73d05eb7 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -1139,6 +1139,7 @@ aarch64*-*-elf | aarch64*-*-fuchsia* | aarch64*-*-rtems*)
;;
aarch64-*-rtems*)
tm_file="${tm_file} aarch64/rtems.h rtems.h"
+ tmake_file="${tmake_file} aarch64/t-aarch64-rtems"
;;
esac
case $target in
diff --git a/gcc/config/aarch64/t-aarch64-rtems
b/gcc/config/aarch64/t-aarch64-rtems
new file mode 100644
index 000..11f8c380222
--- /dev/null
+++ b/gcc/config/aarch64/t-aarch64-rtems
@@ -0,0 +1,42 @@
+# Machine description for AArch64 architecture.
+# Copyright (C) 2024 Free Software Foundation, Inc.
+#
+# This file is part of GCC.
+#
+# GCC is free software; you can redistribute it and/or modify it
+# under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 3, or (at your option)
+# any later version.
+#
+# GCC is distributed in the hope that it will be useful, but
+# WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+# General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with GCC; see the file COPYING3. If not see
+#
[GCC] RTEMS: Add multilib configuration for aarch64
gcc/ChangeLog:
* config.gcc (aarch64-*-rtems*): Add target makefile fragment
t-aarch64-rtems.
* config/aarch64/t-aarch64-rtems: New file.
---
gcc/config.gcc | 1 +
gcc/config/aarch64/t-aarch64-rtems | 41 ++
2 files changed, 42 insertions(+)
create mode 100644 gcc/config/aarch64/t-aarch64-rtems
diff --git a/gcc/config.gcc b/gcc/config.gcc
index 648b3dc2110..c3b73d05eb7 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -1139,6 +1139,7 @@ aarch64*-*-elf | aarch64*-*-fuchsia* | aarch64*-*-rtems*)
;;
aarch64-*-rtems*)
tm_file="${tm_file} aarch64/rtems.h rtems.h"
+ tmake_file="${tmake_file} aarch64/t-aarch64-rtems"
;;
esac
case $target in
diff --git a/gcc/config/aarch64/t-aarch64-rtems
b/gcc/config/aarch64/t-aarch64-rtems
new file mode 100644
index 000..88e07f54551
--- /dev/null
+++ b/gcc/config/aarch64/t-aarch64-rtems
@@ -0,0 +1,41 @@
+# Machine description for AArch64 architecture.
+# Copyright (C) 2024 Free Software Foundation, Inc.
+#
+# This file is part of GCC.
+#
+# GCC is free software; you can redistribute it and/or modify it
+# under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 3, or (at your option)
+# any later version.
+#
+# GCC is distributed in the hope that it will be useful, but
+# WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+# General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with GCC; see the file COPYING3. If not see
+#
Re: [PATCH v2] rs6000: Rework option -mpowerpc64 handling [PR106680]
Hello, On 27.12.22 11:16, Kewen.Lin via Gcc-patches wrote: Hi Segher, on 2022/12/24 04:26, Segher Boessenkool wrote: Hi! On Wed, Oct 12, 2022 at 04:12:21PM +0800, Kewen.Lin wrote: PR106680 shows that -m32 -mpowerpc64 is different from -mpowerpc64 -m32, this is determined by the way how we handle option powerpc64 in rs6000_handle_option. Segher pointed out this difference should be taken as a bug and we should ensure that option powerpc64 is independent of -m32/-m64. So this patch removes the handlings in rs6000_handle_option and add some necessary supports in rs6000_option_override_internal instead. Sorry for the late review. + /* Don't expect powerpc64 enabled on those OSes with OS_MISSING_POWERPC64, + since they don't support saving the high part of 64-bit registers on + context switch. If the user explicitly specifies it, we won't interfere + with the user's specification. */ It depends on the OS, and what you call "context switch". For example on Linux the context switches done by the kernel are fine, only things done by setjmp/longjmp and getcontext/setcontext are not. So just be a bit more vague here? "Since they do not save and restore the high half of the GPRs correctly in all cases", something like that? Okay for trunk like that. Thanks! Thanks! Adjusted as you suggested and committed in r13-4894-gacc727cf02a144. I am a bit late, however, this broke the 32-bit support for -mcpu=e6500. For RTEMS, I have the following multilibs: MULTILIB_REQUIRED += mcpu=e6500/m32 MULTILIB_REQUIRED += mcpu=e6500/m32/mvrsave MULTILIB_REQUIRED += mcpu=e6500/m32/msoft-float/mno-altivec MULTILIB_REQUIRED += mcpu=e6500/m64 MULTILIB_REQUIRED += mcpu=e6500/m64/mvrsave I configured GCC as a bi-arch compiler (32-bit and 64-bit). It seems you removed the -m32 handling, so I am not sure how to approach this issue. I added a test case to the PR: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106680 -- embedded brains GmbH & Co. KG Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/
Re: [PATCH] libgomp: Fix build for -fshort-enums
On 11.09.23 14:57, Sebastian Huber wrote: On 04.07.23 08:20, Sebastian Huber wrote: On 22.05.23 14:51, Sebastian Huber wrote: Make sure that the API enums have at least the size of int. Otherwise the following build error may occur: In file included from gcc/libgomp/env.c:34: ./libgomp_f.h: In function 'omp_check_defines': ./libgomp_f.h:77:8: error: size of array 'test' is negative 77 | char test[(28 != sizeof (omp_lock_t) | ^~~~ libgomp/ChangeLog: * omp.h.in (omp_alloctrait_key_t): Add __omp_alloctrait_key_t_max__ with a value of the int type maximum. --- libgomp/omp.h.in | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/libgomp/omp.h.in b/libgomp/omp.h.in index bd1286c2a3f..3b1612fcb15 100644 --- a/libgomp/omp.h.in +++ b/libgomp/omp.h.in @@ -146,7 +146,8 @@ typedef enum omp_alloctrait_key_t omp_atk_fallback = 5, omp_atk_fb_data = 6, omp_atk_pinned = 7, - omp_atk_partition = 8 + omp_atk_partition = 8, + __omp_alloctrait_key_t_max__ = __INT_MAX__ } omp_alloctrait_key_t; typedef enum omp_alloctrait_value_t Could someone please have a look at this. Ping. Any chance to get this integrated for GCC 14? -- embedded brains GmbH & Co. KG Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/
[PATCH] gcov: Fix use of __LIBGCC_HAVE_LIBATOMIC
libgcc/ChangeLog: PR target/112777 * libgcov.h (GCOV_SUPPORTS_ATOMIC): Honor that __LIBGCC_HAVE_LIBATOMIC is always defined as either 0 or 1. --- libgcc/libgcov.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libgcc/libgcov.h b/libgcc/libgcov.h index f5959a8bf5c..a44f145ce25 100644 --- a/libgcc/libgcov.h +++ b/libgcc/libgcov.h @@ -98,7 +98,7 @@ typedef unsigned gcov_type_unsigned __attribute__ ((mode (QI))); /* Detect whether target can support atomic update of profilers. */ #if (__SIZEOF_LONG_LONG__ == 4 && __GCC_HAVE_SYNC_COMPARE_AND_SWAP_4) \ || (__SIZEOF_LONG_LONG__ == 8 && __GCC_HAVE_SYNC_COMPARE_AND_SWAP_8) \ -|| defined (__LIBGCC_HAVE_LIBATOMIC) +|| __LIBGCC_HAVE_LIBATOMIC #define GCOV_SUPPORTS_ATOMIC 1 #else #define GCOV_SUPPORTS_ATOMIC 0 -- 2.35.3
[PATCH] gcov: Fix __LIBGCC_HAVE_LIBATOMIC definition
In libgcov we use defined (__LIBGCC_HAVE_LIBATOMIC), so we must define it only
if needed (vs. #if __LIBGCC_HAVE_LIBATOMIC).
gcc/c-family/ChangeLog:
PR target/112777
* c-cppbuiltin.cc (c_cpp_builtins): Define __LIBGCC_HAVE_LIBATOMIC
only if targetm.have_libatomic is true.
---
gcc/c-family/c-cppbuiltin.cc | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/gcc/c-family/c-cppbuiltin.cc b/gcc/c-family/c-cppbuiltin.cc
index e536429fa4c..f8ec6f1747c 100644
--- a/gcc/c-family/c-cppbuiltin.cc
+++ b/gcc/c-family/c-cppbuiltin.cc
@@ -1570,8 +1570,8 @@ c_cpp_builtins (cpp_reader *pfile)
/* For libgcov. */
builtin_define_with_int_value ("__LIBGCC_VTABLE_USES_DESCRIPTORS__",
TARGET_VTABLE_USES_DESCRIPTORS);
- builtin_define_with_int_value ("__LIBGCC_HAVE_LIBATOMIC",
-targetm.have_libatomic);
+ if (targetm.have_libatomic)
+ cpp_define (pfile, "__LIBGCC_HAVE_LIBATOMIC");
}
/* For use in assembly language. */
--
2.35.3
Re: [r14-5666 Regression] FAIL: gcc.dg/tree-prof/time-profiler-3.c scan-ipa-dump-times profile "Read tp_first_run: 2" 1 on Linux/x86_64
On 26.11.23 12:18, haochen.jiang wrote: On Linux/x86_64, 41aacdea55c5d795a7aa195357d966645845d00e is the first bad commit commit 41aacdea55c5d795a7aa195357d966645845d00e Author: Sebastian Huber Date: Mon Nov 20 15:26:38 2023 +0100 gcov: Fix integer types in gen_counter_update() caused FAIL: gcc.dg/tree-prof/time-profiler-3.c scan-ipa-dump-times profile "Read tp_first_run: 0" 1 FAIL: gcc.dg/tree-prof/time-profiler-3.c scan-ipa-dump-times profile "Read tp_first_run: 2" 1 Please have a look at: https://gcc.gnu.org/pipermail/gcc-patches/2023-November/638104.html -- embedded brains GmbH & Co. KG Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/
Re: [r14-5579 Regression] FAIL: gcc.dg/tree-ssa/ssa-lim-11.c scan-tree-dump-times lim2 "Executing store motion of __gcov0.access_buf\\[[12]\\] from loop 1" 2 on Linux/x86_64
On 26.11.23 12:18, haochen.jiang wrote: On Linux/x86_64, 20a3c74c347429c109bc7002285b735be83f6a0b is the first bad commit commit 20a3c74c347429c109bc7002285b735be83f6a0b Author: Sebastian Huber Date: Tue Nov 14 21:36:51 2023 +0100 gcov: Improve -fprofile-update=atomic caused FAIL: gcc.dg/tree-ssa/ssa-lim-11.c scan-tree-dump-times lim2 "Executing store motion of __gcov0.access_buf\\[[12]\\] from loop 1" 2 This error was fixed by: commit 8674d70ce37ca3249a641fb418c6849d4f95f348 Author: Sebastian Huber Date: Thu Nov 23 14:45:50 2023 +0100 gcov: No atomic ops for -fprofile-update=single -- embedded brains GmbH & Co. KG Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/
Re: [r14-5578 Regression] FAIL: gfortran.dg/gomp/pr27573.f90 -O (test for excess errors) on Linux/x86_64
On 26.11.23 12:18, haochen.jiang wrote: On Linux/x86_64, a350a74d6113e3a84943266eb691275951c109d9 is the first bad commit commit a350a74d6113e3a84943266eb691275951c109d9 Author: Sebastian Huber Date: Sat Oct 21 15:52:15 2023 +0200 gcov: Add gen_counter_update() caused FAIL: gcc.dg/gomp/pr27573.c (internal compiler error: verify_gimple failed) FAIL: gcc.dg/gomp/pr27573.c (test for excess errors) FAIL: gcc.dg/profile-update-warning.c (internal compiler error: verify_gimple failed) FAIL: gcc.dg/profile-update-warning.c (test for excess errors) FAIL: gfortran.dg/gomp/pr27573.f90 -O (internal compiler error: verify_gimple failed) FAIL: gfortran.dg/gomp/pr27573.f90 -O (test for excess errors) The errors were fixed by: commit 41aacdea55c5d795a7aa195357d966645845d00e Author: Sebastian Huber Date: Mon Nov 20 15:26:38 2023 +0100 gcov: Fix integer types in gen_counter_update() commit a034cca0a222598cb42302c059262b654685ff19 Author: Sebastian Huber Date: Mon Nov 20 14:48:03 2023 +0100 gcov: Use unshare_expr() in gen_counter_update() -- embedded brains GmbH & Co. KG Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/
Re: [PATCH] Update GMP/MPFR/MPC/ISL/gettext to latest release
On 26.11.23 11:15, Iain Sandoe wrote: On 26 Nov 2023, at 10:05, Sebastian Huber wrote: On 26.11.23 01:35, Iain Sandoe wrote: On 25 Nov 2023, at 21:44, Sebastian Huber wrote: On 25.11.23 14:59, Richard Biener wrote: On Sat, Nov 25, 2023 at 12:26 PM Sebastian Huber wrote: contrib/ChangeLog Did you verify an in-tree build with these works and the testsuite is clean? I was able to build a native GCC: /tmp/sh/i-native/bin/gcc --version --verbose Using built-in specs. COLLECT_AS_OPTIONS='--version' COLLECT_GCC=/tmp/sh/i-native/bin/gcc COLLECT_LTO_WRAPPER=/tmp/sh/i-native/lib/gcc/x86_64-pc-linux-gnu/14.0.0/lto-wrapper gcc (GCC) 14.0.0 20231125 (experimental) [master 9c26c91b94e] Copyright (C) 2023 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Target: x86_64-pc-linux-gnu Configured with: /home/EB/sebastian_h/src/gcc/configure --prefix=/tmp/sh/i-native --verbose --enable-checking=yes,rtl --disable-libsanitizer --disable-multilib --disable-bootstrap --enable-languages=c,c++ Thread model: posix Supported LTO compression algorithms: zlib gcc version 14.0.0 20231125 (experimental) [master 9c26c91b94e] (GCC) COLLECT_GCC_OPTIONS='--version' '-v' '-mtune=generic' '-march=x86-64' '-dumpdir' 'a-' /tmp/sh/i-native/lib/gcc/x86_64-pc-linux-gnu/14.0.0/cc1 -quiet -v help-dummy -quiet -dumpdir a- -dumpbase help-dummy -mtune=generic -march=x86-64 -version --version -o /tmp/ccHTKJ5B.s GNU C17 (GCC) version 14.0.0 20231125 (experimental) [master 9c26c91b94e] (x86_64-pc-linux-gnu) compiled by GNU C version 14.0.0 20231122 (experimental) [master 6bf66276e3e], GMP version 6.3.0, MPFR version 4.2.1, MPC version 1.3.1, isl version isl-0.26-GMP [...] However, I noticed that this was with a disabled bootstrap (for the git bisect). The bootstrap fails with an error in ISL 0.26 which seems to be a known issue: https://www.mail-archive.com/gcc@gcc.gnu.org/msg101643.html I thought that the GCC prerequisite library maintainers check that a new release is able to bootstrap GCC, but this seems to be not the case. The older releases have problems to recognize arm64-apple. 0.24 (at least) builds fine in-tree on aarch64-apple-darwin21; do you have a pointer to the recognition issue? I’ll try 0.25 in the next few days. For the RTEMS Project we had to add patches to ISL, MPC, MPFR for ARM64/Darwin hosts: https://github.com/RTEMS/rtems-source-builder/commit/5e76e64bccc2d84acb6c37380f2f9d98df3b7382 Specifically for ISL 0.24 this is: https://devel.rtems.org/raw-attachment/ticket/4657/fix-mac-arm64-isl-config.patch OK, it is possible (even likely) that the issue you are seeing is configuring with “arm64--darwinNN”. Although Apple has named the platform Arm64, the configuration used for OSS is still “aarch64-apple-darwinNN” When I first began work on the port, I discussed this with the config script maintainers, and the end result was that “aarch64-apple-darwinNN” had already been adopted (and that was, shall we say, a “firm position” from their perspective), so arm64-apple-darwinNN is not actually canonical. We do use “-arch arm64” in specs etc. that have to interface with system tools (like ld etc); but elsewhere the port is ‘aarch64’. e.g. $ ./config.sub arm64-apple-darwin21 aarch64-apple-darwin21 For the RTEMS Project, we only build cross compilers. Maybe this caused the trouble. We observed also other issues with recent Apple systems and GCC: https://lists.rtems.org/pipermail/users/2023-November/068909.html -- embedded brains GmbH & Co. KG Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/
Re: [PATCH] Update GMP/MPFR/MPC/ISL/gettext to latest release
On 26.11.23 01:35, Iain Sandoe wrote: On 25 Nov 2023, at 21:44, Sebastian Huber wrote: On 25.11.23 14:59, Richard Biener wrote: On Sat, Nov 25, 2023 at 12:26 PM Sebastian Huber wrote: contrib/ChangeLog Did you verify an in-tree build with these works and the testsuite is clean? I was able to build a native GCC: /tmp/sh/i-native/bin/gcc --version --verbose Using built-in specs. COLLECT_AS_OPTIONS='--version' COLLECT_GCC=/tmp/sh/i-native/bin/gcc COLLECT_LTO_WRAPPER=/tmp/sh/i-native/lib/gcc/x86_64-pc-linux-gnu/14.0.0/lto-wrapper gcc (GCC) 14.0.0 20231125 (experimental) [master 9c26c91b94e] Copyright (C) 2023 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Target: x86_64-pc-linux-gnu Configured with: /home/EB/sebastian_h/src/gcc/configure --prefix=/tmp/sh/i-native --verbose --enable-checking=yes,rtl --disable-libsanitizer --disable-multilib --disable-bootstrap --enable-languages=c,c++ Thread model: posix Supported LTO compression algorithms: zlib gcc version 14.0.0 20231125 (experimental) [master 9c26c91b94e] (GCC) COLLECT_GCC_OPTIONS='--version' '-v' '-mtune=generic' '-march=x86-64' '-dumpdir' 'a-' /tmp/sh/i-native/lib/gcc/x86_64-pc-linux-gnu/14.0.0/cc1 -quiet -v help-dummy -quiet -dumpdir a- -dumpbase help-dummy -mtune=generic -march=x86-64 -version --version -o /tmp/ccHTKJ5B.s GNU C17 (GCC) version 14.0.0 20231125 (experimental) [master 9c26c91b94e] (x86_64-pc-linux-gnu) compiled by GNU C version 14.0.0 20231122 (experimental) [master 6bf66276e3e], GMP version 6.3.0, MPFR version 4.2.1, MPC version 1.3.1, isl version isl-0.26-GMP [...] However, I noticed that this was with a disabled bootstrap (for the git bisect). The bootstrap fails with an error in ISL 0.26 which seems to be a known issue: https://www.mail-archive.com/gcc@gcc.gnu.org/msg101643.html I thought that the GCC prerequisite library maintainers check that a new release is able to bootstrap GCC, but this seems to be not the case. The older releases have problems to recognize arm64-apple. 0.24 (at least) builds fine in-tree on aarch64-apple-darwin21; do you have a pointer to the recognition issue? I’ll try 0.25 in the next few days. For the RTEMS Project we had to add patches to ISL, MPC, MPFR for ARM64/Darwin hosts: https://github.com/RTEMS/rtems-source-builder/commit/5e76e64bccc2d84acb6c37380f2f9d98df3b7382 Specifically for ISL 0.24 this is: https://devel.rtems.org/raw-attachment/ticket/4657/fix-mac-arm64-isl-config.patch I naively thought that updating to the latest releases would help us to get rid of the patches. -- embedded brains GmbH & Co. KG Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/
Re: [PATCH] Update GMP/MPFR/MPC/ISL/gettext to latest release
On 25.11.23 14:59, Richard Biener wrote: On Sat, Nov 25, 2023 at 12:26 PM Sebastian Huber wrote: contrib/ChangeLog Did you verify an in-tree build with these works and the testsuite is clean? I was able to build a native GCC: /tmp/sh/i-native/bin/gcc --version --verbose Using built-in specs. COLLECT_AS_OPTIONS='--version' COLLECT_GCC=/tmp/sh/i-native/bin/gcc COLLECT_LTO_WRAPPER=/tmp/sh/i-native/lib/gcc/x86_64-pc-linux-gnu/14.0.0/lto-wrapper gcc (GCC) 14.0.0 20231125 (experimental) [master 9c26c91b94e] Copyright (C) 2023 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Target: x86_64-pc-linux-gnu Configured with: /home/EB/sebastian_h/src/gcc/configure --prefix=/tmp/sh/i-native --verbose --enable-checking=yes,rtl --disable-libsanitizer --disable-multilib --disable-bootstrap --enable-languages=c,c++ Thread model: posix Supported LTO compression algorithms: zlib gcc version 14.0.0 20231125 (experimental) [master 9c26c91b94e] (GCC) COLLECT_GCC_OPTIONS='--version' '-v' '-mtune=generic' '-march=x86-64' '-dumpdir' 'a-' /tmp/sh/i-native/lib/gcc/x86_64-pc-linux-gnu/14.0.0/cc1 -quiet -v help-dummy -quiet -dumpdir a- -dumpbase help-dummy -mtune=generic -march=x86-64 -version --version -o /tmp/ccHTKJ5B.s GNU C17 (GCC) version 14.0.0 20231125 (experimental) [master 9c26c91b94e] (x86_64-pc-linux-gnu) compiled by GNU C version 14.0.0 20231122 (experimental) [master 6bf66276e3e], GMP version 6.3.0, MPFR version 4.2.1, MPC version 1.3.1, isl version isl-0.26-GMP [...] However, I noticed that this was with a disabled bootstrap (for the git bisect). The bootstrap fails with an error in ISL 0.26 which seems to be a known issue: https://www.mail-archive.com/gcc@gcc.gnu.org/msg101643.html I thought that the GCC prerequisite library maintainers check that a new release is able to bootstrap GCC, but this seems to be not the case. The older releases have problems to recognize arm64-apple. -- embedded brains GmbH & Co. KG Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/
[PATCH] Update GMP/MPFR/MPC/ISL/gettext to latest release
contrib/ChangeLog * download_prerequisites: Update to gmp-6.3.0, mpfr-4.2.1, mpc-1.3.1, isl-0.26, and gettext-0.22.4. * prerequisites.md5: Update hash. * prerequisites.sha512: Likewise. --- contrib/download_prerequisites | 10 +- contrib/prerequisites.md5 | 10 +- contrib/prerequisites.sha512 | 10 +- 3 files changed, 15 insertions(+), 15 deletions(-) diff --git a/contrib/download_prerequisites b/contrib/download_prerequisites index 9568091c0dba..b9deab316917 100755 --- a/contrib/download_prerequisites +++ b/contrib/download_prerequisites @@ -27,11 +27,11 @@ version='(unversioned)' # remember to also update the files `contrib/prerequisites.sha512` and # `contrib/prerequisites.md5` with the new checksums. -gmp='gmp-6.2.1.tar.bz2' -mpfr='mpfr-4.1.0.tar.bz2' -mpc='mpc-1.2.1.tar.gz' -isl='isl-0.24.tar.bz2' -gettext='gettext-0.22.tar.gz' +gmp='gmp-6.3.0.tar.bz2' +mpfr='mpfr-4.2.1.tar.bz2' +mpc='mpc-1.3.1.tar.gz' +isl='isl-0.26.tar.bz2' +gettext='gettext-0.22.4.tar.gz' base_url='http://gcc.gnu.org/pub/gcc/infrastructure/' diff --git a/contrib/prerequisites.md5 b/contrib/prerequisites.md5 index 716a9ff910c7..2ccff4a4c44f 100644 --- a/contrib/prerequisites.md5 +++ b/contrib/prerequisites.md5 @@ -1,5 +1,5 @@ -28971fc21cf028042d4897f02fd355ea gmp-6.2.1.tar.bz2 -44b892bc5a45bafb4294d134e13aad1d mpfr-4.1.0.tar.bz2 -9f16c976c25bb0f76b50be749cd7a3a8 mpc-1.2.1.tar.gz -dd2f7b78e118c25bd96134a52aae7f4d isl-0.24.tar.bz2 -c092102240f8f66134d22718421d5115 gettext-0.22.tar.gz +c1cd6ef33085e9cb818b9b08371f9000 gmp-6.3.0.tar.bz2 +7765afa036e4ce7fb0e02bce0fef894b mpfr-4.2.1.tar.bz2 +5c9bc658c9fd0f940e8e3e0f09530c62 mpc-1.3.1.tar.gz +da50c85e9841db36d48a492bbe836863 isl-0.26.tar.bz2 +e541ba3603674a853cff9b28a68dd61e gettext-0.22.4.tar.gz diff --git a/contrib/prerequisites.sha512 b/contrib/prerequisites.sha512 index f71398bdbc31..9bc9ce468fdc 100644 --- a/contrib/prerequisites.sha512 +++ b/contrib/prerequisites.sha512 @@ -1,5 +1,5 @@ -8904334a3bcc5c896ececabc75cda9dec642e401fb5397c4992c4fabea5e962c9ce8bd44e8e4233c34e55c8010cc28db0545f5f750cbdbb5f00af538dc763be9 gmp-6.2.1.tar.bz2 -410208ee0d48474c1c10d3d4a59decd2dfa187064183b09358ec4c4666e34d74383128436b404123b831e585d81a9176b24c7ced9d913967c5fce35d4040a0b4 mpfr-4.1.0.tar.bz2 -3279f813ab37f47fdcc800e4ac5f306417d07f539593ca715876e43e04896e1d5bceccfb288ef2908a3f24b760747d0dbd0392a24b9b341bc3e12082e5c836ee mpc-1.2.1.tar.gz -aab3bddbda96b801d0f56d2869f943157aad52a6f6e6a61745edd740234c635c38231af20bc3f1a08d416a5e973a90e18249078ed8e4ae2f1d5de57658738e95 isl-0.24.tar.bz2 -e2a58dde1cae3e6b79c03e7ef3d888f7577c1f4cba283b3b0f31123ceea8c33d7c9700e83de57104644de23e5f5c374868caa0e091f9c45edbbe87b98ee51c04 gettext-0.22.tar.gz +3b684c9bcb9ede2b7e54d0ba4c9764bfa17c20d4f317c553b6f1e135b536949580ff37341680c25dc236cfe0ba1db8cfdfe619ce013656189ef0871b89f8 gmp-6.3.0.tar.bz2 +c81842532ecc663348deb7400d911ad71933d3b525a2f9e5adcd04265c9c0fdd1f22eca229f482703ac7f222ef209fc9e339dd1fa47d72ae57f7f70b2336a76f mpfr-4.2.1.tar.bz2 +4bab4ef6076f8c5dfdc99d810b51108ced61ea2942ba0c1c932d624360a5473df20d32b300fc76f2ba4aa2a97e1f275c9fd494a1ba9f07c4cb2ad7ceaeb1ae97 mpc-1.3.1.tar.gz +492deba2cbfc693efb41621861a0679390becf2777e32111aceef8db1d38d772385dfd83cee14a41c930f9904549334e4d6dc2c5fce0c69e0bef9c8cf031d6b5 isl-0.26.tar.bz2 +ad2fa2f69be996a637e9b51e8941a39e10050060245dcec1fe75c15b68d0ff973043c87b77e4e2830e407e3bdd040b578f8e24fd05bba43adb94eaee34001aa5 gettext-0.22.4.tar.gz -- 2.35.3
Re: [PATCH v2] gcov: Fix integer types in gen_counter_update()
On 23.11.23 18:29, Sebastian Huber wrote:
On 23.11.23 09:20, Sebastian Huber wrote:
On 23.11.23 09:11, Jiang, Haochen wrote:
-Original Message-
From: Sebastian Huber
Sent: Wednesday, November 22, 2023 10:24 PM
To: Christophe Lyon
Cc: Jakub Jelinek;gcc-patches@gcc.gnu.org
Subject: Re: [PATCH v2] gcov: Fix integer types in gen_counter_update()
On 22.11.23 15:22, Christophe Lyon wrote:
On Tue, 21 Nov 2023 at 12:22, Sebastian Huber
wrote:
On 21.11.23 11:46, Jakub Jelinek wrote:
On Tue, Nov 21, 2023 at 11:42:06AM +0100, Sebastian Huber wrote:
On 21.11.23 11:34, Jakub Jelinek wrote:
--- a/gcc/tree-profile.cc
+++ b/gcc/tree-profile.cc
@@ -281,10 +281,13 @@ gen_assign_counter_update
(gimple_stmt_iterator *gsi, gcall *call, tree func,
if (result)
{
tree result_type = TREE_TYPE (TREE_TYPE (func));
- tree tmp = make_temp_ssa_name (result_type, NULL, name);
- gimple_set_lhs (call, tmp);
+ tree tmp1 = make_temp_ssa_name (result_type, NULL, name);
+ gimple_set_lhs (call, tmp1);
gsi_insert_after (gsi, call, GSI_NEW_STMT);
- gassign *assign = gimple_build_assign (result, tmp);
+ tree tmp2 = make_ssa_name (TREE_TYPE (result));
+ gassign *assign = gimple_build_assign (tmp2, NOP_EXPR,
tmp1);
+ gsi_insert_after (gsi, assign, GSI_NEW_STMT);
+ assign = gimple_build_assign (result, gimple_assign_lhs
(assign));
When you use a temporary tmp2 for the lhs of the conversion,
you can
just
use it here,
assign = gimple_build_assign (result, tmp2);
Ok for trunk with that change.
Just a question, could I also use
tree tmp2 = make_temp_ssa_name (TREE_TYPE (result), NULL, name);
?
This make_temp_ssa_name() is used throughout the file and the new
make_ssa_name() would be the first use in this file.
Yes. The only difference is that it won't be _234 = (type)
something;
but PROF_time_profile_234 = (type) something; in the dumps, but
sure,
consistency is useful.
Thanks for your help. I checked in an updated version.
Our CI bisected a regression to this commit:
Running gcc:gcc.dg/tree-prof/tree-prof.exp ...
FAIL: gcc.dg/tree-prof/time-profiler-3.c scan-ipa-dump-times profile
"Read tp_first_run: 0" 1
FAIL: gcc.dg/tree-prof/time-profiler-3.c scan-ipa-dump-times profile
"Read tp_first_run: 2" 1
(on aarch64)
Can you check?
Yes, I will have a look at it.
The same issue also happened on i386. You can also reproduce that on
x86-64 platforms.
I was able to reproduce it using a native aarch64 GCC on cfarm185, but
I have some difficulties to understand what this test case does actually.
Could the problem be caused by some other recent commit?
I built this commit:
commit 3ef8882adcb1ab5fa535e9e1a2a28ea7c8eeca4f
Author: Sebastian Huber
Date: Tue Nov 14 21:27:37 2023 +0100
Add TARGET_HAVE_LIBATOMIC
Here, the test passes. If I build
commit e9b39df9333d565ee06fa65d62bfca4bbcb92e44 (origin/trunk,
origin/master, origin/HEAD)
Author: Iain Sandoe
Date: Tue Nov 21 10:19:29 2023 +
testsuite: Update path to intl include.
the test fails.
To check that my changes caused the problem, I applied the following
patches to 3ef8882adcb1ab5fa535e9e1a2a28ea7c8eeca4f (git cherry-pick):
Author: Sebastian Huber
Date: Sat Oct 21 15:52:15 2023 +0200
gcov: Add gen_counter_update()
Author: Sebastian Huber
Date: Mon Nov 20 14:48:03 2023 +0100
gcov: Use unshare_expr() in gen_counter_update()
Author: Sebastian Huber
Date: Mon Nov 20 15:26:38 2023 +0100
gcov: Fix integer types in gen_counter_update()
Author: Sebastian Huber
Date: Tue Nov 14 21:36:51 2023 +0100
gcov: Improve -fprofile-update=atomic
Author: Jakub Jelinek
Date: Tue Nov 21 10:49:51 2023 +0100
gcov: Formatting fixes
Author: Sebastian Huber
Date: Thu Nov 23 06:44:15 2023 +
gcov: Do not use atomic ops for -fprofile-update=single
With these changes alone on top of
3ef8882adcb1ab5fa535e9e1a2a28ea7c8eeca4f I don't see the regressions:
Executing on host: /home/sh/b-gcc/gcc/xgcc -B/home/sh/b-gcc/gcc/
/home/sh/gcc/gcc/testsuite/gcc.dg/tree-prof/time-profiler-3.c
-fdiagnostics-plain-output -O2 -fdump-ipa-profile
-fprofile-update=atomic -fprofile-generate -D_PROFILE_GENERATE
-dumpbase-ext .x01 -lm -o
/home/sh/b-gcc/gcc/testsuite/gcc5/time-profiler-3.x01 (timeout = 300)
spawn -ignore SIGHUP /home/sh/b-gcc/gcc/xgcc -B/home/sh/b-gcc/gcc/
/home/sh/gcc/gcc/testsuite/gcc.dg/tree-prof/time-profiler-3.c
-fdiagnostics-plain-output -O2 -fdump-ipa-profile
-fprofile-update=atomic -fprofile-generate -D_PROFILE_GENERATE
-dumpbase-ext .x01 -lm -o
/home/sh/b-gcc/gcc/testsuite/gcc5/time-profiler-3.x01
PASS: gcc.dg/tree-prof/time-profiler-3.c compilation, -fprofile-generate
-D_PROFILE_GENERATE
Setting LD_LIBRARY_PATH to
:/home/sh/b-gcc/gcc:/home/sh/b-gcc/aarch64-unknown-linux-gnu/./libatomic/.libs::/home/sh/b-gcc/gcc:/home/sh/b-gcc/aarch64-unknown-linux-gnu/./libatomic/.libs:/h
Re: [PATCH v2] gcov: Fix integer types in gen_counter_update()
On 23.11.23 09:20, Sebastian Huber wrote:
On 23.11.23 09:11, Jiang, Haochen wrote:
-Original Message-
From: Sebastian Huber
Sent: Wednesday, November 22, 2023 10:24 PM
To: Christophe Lyon
Cc: Jakub Jelinek;gcc-patches@gcc.gnu.org
Subject: Re: [PATCH v2] gcov: Fix integer types in gen_counter_update()
On 22.11.23 15:22, Christophe Lyon wrote:
On Tue, 21 Nov 2023 at 12:22, Sebastian Huber
wrote:
On 21.11.23 11:46, Jakub Jelinek wrote:
On Tue, Nov 21, 2023 at 11:42:06AM +0100, Sebastian Huber wrote:
On 21.11.23 11:34, Jakub Jelinek wrote:
--- a/gcc/tree-profile.cc
+++ b/gcc/tree-profile.cc
@@ -281,10 +281,13 @@ gen_assign_counter_update
(gimple_stmt_iterator *gsi, gcall *call, tree func,
if (result)
{
tree result_type = TREE_TYPE (TREE_TYPE (func));
- tree tmp = make_temp_ssa_name (result_type, NULL, name);
- gimple_set_lhs (call, tmp);
+ tree tmp1 = make_temp_ssa_name (result_type, NULL, name);
+ gimple_set_lhs (call, tmp1);
gsi_insert_after (gsi, call, GSI_NEW_STMT);
- gassign *assign = gimple_build_assign (result, tmp);
+ tree tmp2 = make_ssa_name (TREE_TYPE (result));
+ gassign *assign = gimple_build_assign (tmp2, NOP_EXPR,
tmp1);
+ gsi_insert_after (gsi, assign, GSI_NEW_STMT);
+ assign = gimple_build_assign (result, gimple_assign_lhs
(assign));
When you use a temporary tmp2 for the lhs of the conversion, you
can
just
use it here,
assign = gimple_build_assign (result, tmp2);
Ok for trunk with that change.
Just a question, could I also use
tree tmp2 = make_temp_ssa_name (TREE_TYPE (result), NULL, name);
?
This make_temp_ssa_name() is used throughout the file and the new
make_ssa_name() would be the first use in this file.
Yes. The only difference is that it won't be _234 = (type)
something;
but PROF_time_profile_234 = (type) something; in the dumps, but sure,
consistency is useful.
Thanks for your help. I checked in an updated version.
Our CI bisected a regression to this commit:
Running gcc:gcc.dg/tree-prof/tree-prof.exp ...
FAIL: gcc.dg/tree-prof/time-profiler-3.c scan-ipa-dump-times profile
"Read tp_first_run: 0" 1
FAIL: gcc.dg/tree-prof/time-profiler-3.c scan-ipa-dump-times profile
"Read tp_first_run: 2" 1
(on aarch64)
Can you check?
Yes, I will have a look at it.
The same issue also happened on i386. You can also reproduce that on
x86-64 platforms.
I was able to reproduce it using a native aarch64 GCC on cfarm185, but I
have some difficulties to understand what this test case does actually.
Could the problem be caused by some other recent commit?
I built this commit:
commit 3ef8882adcb1ab5fa535e9e1a2a28ea7c8eeca4f
Author: Sebastian Huber
Date: Tue Nov 14 21:27:37 2023 +0100
Add TARGET_HAVE_LIBATOMIC
Here, the test passes. If I build
commit e9b39df9333d565ee06fa65d62bfca4bbcb92e44 (origin/trunk,
origin/master, origin/HEAD)
Author: Iain Sandoe
Date: Tue Nov 21 10:19:29 2023 +
testsuite: Update path to intl include.
the test fails.
To check that my changes caused the problem, I applied the following
patches to 3ef8882adcb1ab5fa535e9e1a2a28ea7c8eeca4f (git cherry-pick):
Author: Sebastian Huber
Date: Sat Oct 21 15:52:15 2023 +0200
gcov: Add gen_counter_update()
Author: Sebastian Huber
Date: Mon Nov 20 14:48:03 2023 +0100
gcov: Use unshare_expr() in gen_counter_update()
Author: Sebastian Huber
Date: Mon Nov 20 15:26:38 2023 +0100
gcov: Fix integer types in gen_counter_update()
Author: Sebastian Huber
Date: Tue Nov 14 21:36:51 2023 +0100
gcov: Improve -fprofile-update=atomic
Author: Jakub Jelinek
Date: Tue Nov 21 10:49:51 2023 +0100
gcov: Formatting fixes
Author: Sebastian Huber
Date: Thu Nov 23 06:44:15 2023 +
gcov: Do not use atomic ops for -fprofile-update=single
With these changes alone on top of
3ef8882adcb1ab5fa535e9e1a2a28ea7c8eeca4f I don't see the regressions:
Executing on host: /home/sh/b-gcc/gcc/xgcc -B/home/sh/b-gcc/gcc/
/home/sh/gcc/gcc/testsuite/gcc.dg/tree-prof/time-profiler-3.c
-fdiagnostics-plain-output -O2 -fdump-ipa-profile
-fprofile-update=atomic -fprofile-generate -D_PROFILE_GENERATE
-dumpbase-ext .x01 -lm -o
/home/sh/b-gcc/gcc/testsuite/gcc5/time-profiler-3.x01(timeout = 300)
spawn -ignore SIGHUP /home/sh/b-gcc/gcc/xgcc -B/home/sh/b-gcc/gcc/
/home/sh/gcc/gcc/testsuite/gcc.dg/tree-prof/time-profiler-3.c
-fdiagnostics-plain-output -O2 -fdump-ipa-profile
-fprofile-update=atomic -fprofile-generate -D_PROFILE_GENERATE
-dumpbase-ext .x01 -lm -o
/home/sh/b-gcc/gcc/testsuite/gcc5/time-profiler-3.x01
PASS: gcc.dg/tree-prof/time-profiler-3.c compilation,
-fprofile-generate -D_PROFILE_GENERATE
Setting LD_LIBRARY_PATH to
:/home/sh/b-gcc/gcc:/home/sh/b-gcc/aarch64-unknown-linux-gnu/./libatomic/.libs::/home/sh/b-gcc/gcc:/home/sh/b-gcc/aarch64-unknown-linux-gnu/./libatomic/.libs:/home/sh/b-gcc/aarch64-unknown-linux-gnu/libstdc++-v3/
Re: [PATCH] gcov: No atomic ops for -fprofile-update=single
On 23.11.23 15:19, Richard Biener wrote:
On Thu, Nov 23, 2023 at 2:47 PM Sebastian Huber
wrote:
gcc/ChangeLog:
PR tree-optimization/112678
* tree-profile.cc (tree_profiling): Do not use atomic operations
for -fprofile-update=single.
---
gcc/tree-profile.cc | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/gcc/tree-profile.cc b/gcc/tree-profile.cc
index 1ac0fdb3bc98..9c8fdb8b18f4 100644
--- a/gcc/tree-profile.cc
+++ b/gcc/tree-profile.cc
@@ -767,6 +767,7 @@ tree_profiling (void)
= HAVE_sync_compare_and_swapsi || HAVE_atomic_compare_and_swapsi;
bool have_atomic_8
= HAVE_sync_compare_and_swapdi || HAVE_atomic_compare_and_swapdi;
+ bool needs_split = gcov_type_size == 8 && !have_atomic_8 && have_atomic_4;
if (!can_support_atomic)
{
if (gcov_type_size == 4)
@@ -775,6 +776,9 @@ tree_profiling (void)
can_support_atomic = have_atomic_8;
}
+ if (flag_profile_update != PROFILE_UPDATE_SINGLE && needs_split)
+counter_update = COUNTER_UPDATE_ATOMIC_PARTIAL;
+
I wonder if it's cleaner to set can_support_atomic when we can support
it with splitting instead, avoiding a != PROFILE_UPDATE_SINGLE check
here?
The bug was that counter_update was set to COUNTER_UPDATE_ATOMIC_PARTIAL
for -fprofile-update=single. I don't think we can get rid of the
flag_profile_update != PROFILE_UPDATE_SINGLE without changing this whole
code block considerably.
--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax: +49-89-18 94 741 - 08
Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
[PATCH] gcov: No atomic ops for -fprofile-update=single
gcc/ChangeLog:
PR tree-optimization/112678
* tree-profile.cc (tree_profiling): Do not use atomic operations
for -fprofile-update=single.
---
gcc/tree-profile.cc | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/gcc/tree-profile.cc b/gcc/tree-profile.cc
index 1ac0fdb3bc98..9c8fdb8b18f4 100644
--- a/gcc/tree-profile.cc
+++ b/gcc/tree-profile.cc
@@ -767,6 +767,7 @@ tree_profiling (void)
= HAVE_sync_compare_and_swapsi || HAVE_atomic_compare_and_swapsi;
bool have_atomic_8
= HAVE_sync_compare_and_swapdi || HAVE_atomic_compare_and_swapdi;
+ bool needs_split = gcov_type_size == 8 && !have_atomic_8 && have_atomic_4;
if (!can_support_atomic)
{
if (gcov_type_size == 4)
@@ -775,6 +776,9 @@ tree_profiling (void)
can_support_atomic = have_atomic_8;
}
+ if (flag_profile_update != PROFILE_UPDATE_SINGLE && needs_split)
+counter_update = COUNTER_UPDATE_ATOMIC_PARTIAL;
+
if (flag_profile_update == PROFILE_UPDATE_ATOMIC
&& !can_support_atomic)
{
@@ -788,13 +792,11 @@ tree_profiling (void)
if (flag_profile_update == PROFILE_UPDATE_ATOMIC)
{
- if (gcov_type_size == 8 && !have_atomic_8 && have_atomic_4)
+ if (needs_split)
counter_update = COUNTER_UPDATE_ATOMIC_SPLIT;
else
counter_update = COUNTER_UPDATE_ATOMIC_BUILTIN;
}
- else if (gcov_type_size == 8 && have_atomic_4)
-counter_update = COUNTER_UPDATE_ATOMIC_PARTIAL;
/* This is a small-ipa pass that gets called only once, from
cgraphunit.cc:ipa_passes(). */
--
2.35.3
Re: [PATCH v2] gcov: Fix integer types in gen_counter_update()
On 23.11.23 09:11, Jiang, Haochen wrote:
-Original Message-
From: Sebastian Huber
Sent: Wednesday, November 22, 2023 10:24 PM
To: Christophe Lyon
Cc: Jakub Jelinek;gcc-patches@gcc.gnu.org
Subject: Re: [PATCH v2] gcov: Fix integer types in gen_counter_update()
On 22.11.23 15:22, Christophe Lyon wrote:
On Tue, 21 Nov 2023 at 12:22, Sebastian Huber
wrote:
On 21.11.23 11:46, Jakub Jelinek wrote:
On Tue, Nov 21, 2023 at 11:42:06AM +0100, Sebastian Huber wrote:
On 21.11.23 11:34, Jakub Jelinek wrote:
--- a/gcc/tree-profile.cc
+++ b/gcc/tree-profile.cc
@@ -281,10 +281,13 @@ gen_assign_counter_update
(gimple_stmt_iterator *gsi, gcall *call, tree func,
if (result)
{
tree result_type = TREE_TYPE (TREE_TYPE (func));
- tree tmp = make_temp_ssa_name (result_type, NULL, name);
- gimple_set_lhs (call, tmp);
+ tree tmp1 = make_temp_ssa_name (result_type, NULL, name);
+ gimple_set_lhs (call, tmp1);
gsi_insert_after (gsi, call, GSI_NEW_STMT);
- gassign *assign = gimple_build_assign (result, tmp);
+ tree tmp2 = make_ssa_name (TREE_TYPE (result));
+ gassign *assign = gimple_build_assign (tmp2, NOP_EXPR, tmp1);
+ gsi_insert_after (gsi, assign, GSI_NEW_STMT);
+ assign = gimple_build_assign (result, gimple_assign_lhs (assign));
When you use a temporary tmp2 for the lhs of the conversion, you can
just
use it here,
assign = gimple_build_assign (result, tmp2);
Ok for trunk with that change.
Just a question, could I also use
tree tmp2 = make_temp_ssa_name (TREE_TYPE (result), NULL, name);
?
This make_temp_ssa_name() is used throughout the file and the new
make_ssa_name() would be the first use in this file.
Yes. The only difference is that it won't be _234 = (type) something;
but PROF_time_profile_234 = (type) something; in the dumps, but sure,
consistency is useful.
Thanks for your help. I checked in an updated version.
Our CI bisected a regression to this commit:
Running gcc:gcc.dg/tree-prof/tree-prof.exp ...
FAIL: gcc.dg/tree-prof/time-profiler-3.c scan-ipa-dump-times profile
"Read tp_first_run: 0" 1
FAIL: gcc.dg/tree-prof/time-profiler-3.c scan-ipa-dump-times profile
"Read tp_first_run: 2" 1
(on aarch64)
Can you check?
Yes, I will have a look at it.
The same issue also happened on i386. You can also reproduce that on
x86-64 platforms.
I was able to reproduce it using a native aarch64 GCC on cfarm185, but I
have some difficulties to understand what this test case does actually.
--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax: +49-89-18 94 741 - 08
Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
Re: [PATCH v2] gcov: Fix integer types in gen_counter_update()
On 22.11.23 15:22, Christophe Lyon wrote:
On Tue, 21 Nov 2023 at 12:22, Sebastian Huber
wrote:
On 21.11.23 11:46, Jakub Jelinek wrote:
On Tue, Nov 21, 2023 at 11:42:06AM +0100, Sebastian Huber wrote:
On 21.11.23 11:34, Jakub Jelinek wrote:
--- a/gcc/tree-profile.cc
+++ b/gcc/tree-profile.cc
@@ -281,10 +281,13 @@ gen_assign_counter_update (gimple_stmt_iterator *gsi,
gcall *call, tree func,
if (result)
{
tree result_type = TREE_TYPE (TREE_TYPE (func));
- tree tmp = make_temp_ssa_name (result_type, NULL, name);
- gimple_set_lhs (call, tmp);
+ tree tmp1 = make_temp_ssa_name (result_type, NULL, name);
+ gimple_set_lhs (call, tmp1);
gsi_insert_after (gsi, call, GSI_NEW_STMT);
- gassign *assign = gimple_build_assign (result, tmp);
+ tree tmp2 = make_ssa_name (TREE_TYPE (result));
+ gassign *assign = gimple_build_assign (tmp2, NOP_EXPR, tmp1);
+ gsi_insert_after (gsi, assign, GSI_NEW_STMT);
+ assign = gimple_build_assign (result, gimple_assign_lhs (assign));
When you use a temporary tmp2 for the lhs of the conversion, you can just
use it here,
assign = gimple_build_assign (result, tmp2);
Ok for trunk with that change.
Just a question, could I also use
tree tmp2 = make_temp_ssa_name (TREE_TYPE (result), NULL, name);
?
This make_temp_ssa_name() is used throughout the file and the new
make_ssa_name() would be the first use in this file.
Yes. The only difference is that it won't be _234 = (type) something;
but PROF_time_profile_234 = (type) something; in the dumps, but sure,
consistency is useful.
Thanks for your help. I checked in an updated version.
Our CI bisected a regression to this commit:
Running gcc:gcc.dg/tree-prof/tree-prof.exp ...
FAIL: gcc.dg/tree-prof/time-profiler-3.c scan-ipa-dump-times profile
"Read tp_first_run: 0" 1
FAIL: gcc.dg/tree-prof/time-profiler-3.c scan-ipa-dump-times profile
"Read tp_first_run: 2" 1
(on aarch64)
Can you check?
Yes, I will have a look at it.
--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax: +49-89-18 94 741 - 08
Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
Re: [PATCH v2] gcov: Fix integer types in gen_counter_update()
On 21.11.23 11:46, Jakub Jelinek wrote:
On Tue, Nov 21, 2023 at 11:42:06AM +0100, Sebastian Huber wrote:
On 21.11.23 11:34, Jakub Jelinek wrote:
--- a/gcc/tree-profile.cc
+++ b/gcc/tree-profile.cc
@@ -281,10 +281,13 @@ gen_assign_counter_update (gimple_stmt_iterator *gsi,
gcall *call, tree func,
if (result)
{
tree result_type = TREE_TYPE (TREE_TYPE (func));
- tree tmp = make_temp_ssa_name (result_type, NULL, name);
- gimple_set_lhs (call, tmp);
+ tree tmp1 = make_temp_ssa_name (result_type, NULL, name);
+ gimple_set_lhs (call, tmp1);
gsi_insert_after (gsi, call, GSI_NEW_STMT);
- gassign *assign = gimple_build_assign (result, tmp);
+ tree tmp2 = make_ssa_name (TREE_TYPE (result));
+ gassign *assign = gimple_build_assign (tmp2, NOP_EXPR, tmp1);
+ gsi_insert_after (gsi, assign, GSI_NEW_STMT);
+ assign = gimple_build_assign (result, gimple_assign_lhs (assign));
When you use a temporary tmp2 for the lhs of the conversion, you can just
use it here,
assign = gimple_build_assign (result, tmp2);
Ok for trunk with that change.
Just a question, could I also use
tree tmp2 = make_temp_ssa_name (TREE_TYPE (result), NULL, name);
?
This make_temp_ssa_name() is used throughout the file and the new
make_ssa_name() would be the first use in this file.
Yes. The only difference is that it won't be _234 = (type) something;
but PROF_time_profile_234 = (type) something; in the dumps, but sure,
consistency is useful.
Thanks for your help. I checked in an updated version.
--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax: +49-89-18 94 741 - 08
Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
Re: [PATCH v2] gcov: Fix integer types in gen_counter_update()
On 21.11.23 11:34, Jakub Jelinek wrote:
--- a/gcc/tree-profile.cc
+++ b/gcc/tree-profile.cc
@@ -281,10 +281,13 @@ gen_assign_counter_update (gimple_stmt_iterator *gsi,
gcall *call, tree func,
if (result)
{
tree result_type = TREE_TYPE (TREE_TYPE (func));
- tree tmp = make_temp_ssa_name (result_type, NULL, name);
- gimple_set_lhs (call, tmp);
+ tree tmp1 = make_temp_ssa_name (result_type, NULL, name);
+ gimple_set_lhs (call, tmp1);
gsi_insert_after (gsi, call, GSI_NEW_STMT);
- gassign *assign = gimple_build_assign (result, tmp);
+ tree tmp2 = make_ssa_name (TREE_TYPE (result));
+ gassign *assign = gimple_build_assign (tmp2, NOP_EXPR, tmp1);
+ gsi_insert_after (gsi, assign, GSI_NEW_STMT);
+ assign = gimple_build_assign (result, gimple_assign_lhs (assign));
When you use a temporary tmp2 for the lhs of the conversion, you can just
use it here,
assign = gimple_build_assign (result, tmp2);
Ok for trunk with that change.
Just a question, could I also use
tree tmp2 = make_temp_ssa_name (TREE_TYPE (result), NULL, name);
?
This make_temp_ssa_name() is used throughout the file and the new
make_ssa_name() would be the first use in this file.
--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax: +49-89-18 94 741 - 08
Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
[PATCH v2] gcov: Fix integer types in gen_counter_update()
This change fixes issues like this:
gcc.dg/gomp/pr27573.c: In function ‘main._omp_fn.0’:
gcc.dg/gomp/pr27573.c:19:1: error: non-trivial conversion in ‘ssa_name’
19 | }
| ^
long int
long unsigned int
# .MEM_19 = VDEF <.MEM_18>
__gcov7.main._omp_fn.0[0] = PROF_time_profile_12;
during IPA pass: profile
gcc.dg/gomp/pr27573.c:19:1: internal compiler error: verify_gimple failed
gcc/ChangeLog:
PR middle-end/112634
* tree-profile.cc (gen_assign_counter_update): Cast the unsigned result
type of
__atomic_add_fetch() to the signed counter type.
(gen_counter_update): Fix formatting.
---
v2: Use NOP_EXPR to do the cast. Fix formatting.
gcc/tree-profile.cc | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/gcc/tree-profile.cc b/gcc/tree-profile.cc
index f12b374ca27..ff95f8ef7cd 100644
--- a/gcc/tree-profile.cc
+++ b/gcc/tree-profile.cc
@@ -281,10 +281,13 @@ gen_assign_counter_update (gimple_stmt_iterator *gsi,
gcall *call, tree func,
if (result)
{
tree result_type = TREE_TYPE (TREE_TYPE (func));
- tree tmp = make_temp_ssa_name (result_type, NULL, name);
- gimple_set_lhs (call, tmp);
+ tree tmp1 = make_temp_ssa_name (result_type, NULL, name);
+ gimple_set_lhs (call, tmp1);
gsi_insert_after (gsi, call, GSI_NEW_STMT);
- gassign *assign = gimple_build_assign (result, tmp);
+ tree tmp2 = make_ssa_name (TREE_TYPE (result));
+ gassign *assign = gimple_build_assign (tmp2, NOP_EXPR, tmp1);
+ gsi_insert_after (gsi, assign, GSI_NEW_STMT);
+ assign = gimple_build_assign (result, gimple_assign_lhs (assign));
gsi_insert_after (gsi, assign, GSI_NEW_STMT);
}
else
@@ -309,8 +312,8 @@ gen_counter_update (gimple_stmt_iterator *gsi, tree
counter, tree result,
{
/* __atomic_fetch_add (, 1, MEMMODEL_RELAXED); */
tree f = builtin_decl_explicit (TYPE_PRECISION (type) > 32
- ? BUILT_IN_ATOMIC_ADD_FETCH_8:
- BUILT_IN_ATOMIC_ADD_FETCH_4);
+ ? BUILT_IN_ATOMIC_ADD_FETCH_8
+ : BUILT_IN_ATOMIC_ADD_FETCH_4);
gcall *call = gimple_build_call (f, 3, addr, one, relaxed);
gen_assign_counter_update (gsi, call, f, result, name);
}
--
2.35.3
Re: [PATCH 2/2] gcov: Fix integer types in gen_counter_update()
On 20.11.23 15:56, Jakub Jelinek wrote:
On Mon, Nov 20, 2023 at 03:33:31PM +0100, Sebastian Huber wrote:
This change fixes issues like this:
gcc.dg/gomp/pr27573.c: In function ‘main._omp_fn.0’:
gcc.dg/gomp/pr27573.c:19:1: error: non-trivial conversion in ‘ssa_name’
19 | }
| ^
long int
long unsigned int
# .MEM_19 = VDEF <.MEM_18>
__gcov7.main._omp_fn.0[0] = PROF_time_profile_12;
during IPA pass: profile
gcc.dg/gomp/pr27573.c:19:1: internal compiler error: verify_gimple failed
gcc/ChangeLog:
PR middle-end/112634
* tree-profile.cc (gen_assign_counter_update): Cast the unsigned result
type of
__atomic_add_fetch() to the signed counter type.
---
gcc/tree-profile.cc | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/gcc/tree-profile.cc b/gcc/tree-profile.cc
index 68db09f6189..54938e1d165 100644
--- a/gcc/tree-profile.cc
+++ b/gcc/tree-profile.cc
@@ -284,7 +284,9 @@ gen_assign_counter_update (gimple_stmt_iterator *gsi, gcall
*call, tree func,
tree tmp = make_temp_ssa_name (result_type, NULL, name);
gimple_set_lhs (call, tmp);
gsi_insert_after (gsi, call, GSI_NEW_STMT);
- gassign *assign = gimple_build_assign (result, tmp);
+ gassign *assign = gimple_build_assign (result,
+build_int_cst (TREE_TYPE (result),
+ tmp));
This can't be correct.
tmp is a SSA_NAME, so calling build_int_cst on it is not appropriate, the
second argument should be some unsigned HOST_WIDE_INT value.
If result_type is different type from TREE_TYPE (result), but both are
integer types, then you want
gassign *assing = gimple_build_assign (result, NOP_EXPR, tmp);
or so.
I really don't know what I am doing here, so a lot of guess work is
involved from my side. The change fixed at least the failing test case.
When I use the NOP_EXPR
static inline void
gen_assign_counter_update (gimple_stmt_iterator *gsi, gcall *call, tree
func,
tree result, const char *name)
{
if (result)
{
tree result_type = TREE_TYPE (TREE_TYPE (func));
tree tmp = make_temp_ssa_name (result_type, NULL, name);
gimple_set_lhs (call, tmp);
gsi_insert_after (gsi, call, GSI_NEW_STMT);
gassign *assign = gimple_build_assign (result, NOP_EXPR, tmp);
gsi_insert_after (gsi, assign, GSI_NEW_STMT);
}
else
gsi_insert_after (gsi, call, GSI_NEW_STMT);
}
I get
gcc -O2 -fopenmp -fprofile-generate
./gcc/testsuite/gcc.dg/gomp/pr27573.c -S -o -
.file "pr27573.c"
./gcc/testsuite/gcc.dg/gomp/pr27573.c: In function ‘main._omp_fn.0’:
./gcc/testsuite/gcc.dg/gomp/pr27573.c:19:1: error: non-register as LHS
of unary operation
19 | }
| ^
# .MEM_19 = VDEF <.MEM_18>
__gcov7.main._omp_fn.0[0] = (long int) PROF_time_profile_12;
during IPA pass: profile
./gcc/testsuite/gcc.dg/gomp/pr27573.c:19:1: internal compiler error:
verify_gimple failed
--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax: +49-89-18 94 741 - 08
Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
[PATCH 1/2] gcov: Use unshare_expr() in gen_counter_update()
This fixes issues like this:
gcc/testsuite/gcc.dg/no_profile_instrument_function-attr-1.c: In function
'main':
gcc/testsuite/gcc.dg/no_profile_instrument_function-attr-1.c:19:1: error:
incorrect sharing of tree nodes
__gcov0.main[0]
# .MEM_12 = VDEF <.MEM_9>
__gcov0.main[0] = PROF_edge_counter_4;
during IPA pass: profile
gcc/testsuite/gcc.dg/no_profile_instrument_function-attr-1.c:19:1: internal
compiler error: verify_gimple failed
Unshare the counter expression in the second gimple_build_assign() in
gen_counter_update(). This is similar to the original
gimple_gen_edge_profiler() for "ref":
void
gimple_gen_edge_profiler (int edgeno, edge e)
{
tree one;
one = build_int_cst (gcov_type_node, 1);
if (flag_profile_update == PROFILE_UPDATE_ATOMIC)
[...]
else
{
tree ref = tree_coverage_counter_ref (GCOV_COUNTER_ARCS, edgeno);
tree gcov_type_tmp_var = make_temp_ssa_name (gcov_type_node,
NULL, "PROF_edge_counter");
gassign *stmt1 = gimple_build_assign (gcov_type_tmp_var, ref);
gcov_type_tmp_var = make_temp_ssa_name (gcov_type_node,
NULL, "PROF_edge_counter");
gassign *stmt2 = gimple_build_assign (gcov_type_tmp_var, PLUS_EXPR,
gimple_assign_lhs (stmt1), one);
gassign *stmt3 = gimple_build_assign (unshare_expr (ref),
gimple_assign_lhs (stmt2));
gsi_insert_on_edge (e, stmt1);
gsi_insert_on_edge (e, stmt2);
gsi_insert_on_edge (e, stmt3);
}
}
However, the orignal gimple_gen_time_profiler() did not use unshare_expr() for
the counter expression (tree_time_profiler_counter):
void
gimple_gen_time_profiler (unsigned tag)
{
[...]
/* Emit: counters[0] = ++__gcov_time_profiler_counter. */
if (flag_profile_update == PROFILE_UPDATE_ATOMIC)
[...]
else
{
tree tmp = make_temp_ssa_name (type, NULL, "PROF_time_profile");
gassign *assign = gimple_build_assign (tmp, tree_time_profiler_counter);
gsi_insert_before (, assign, GSI_NEW_STMT);
tmp = make_temp_ssa_name (type, NULL, "PROF_time_profile");
assign = gimple_build_assign (tmp, PLUS_EXPR, gimple_assign_lhs (assign),
one);
gsi_insert_after (, assign, GSI_NEW_STMT);
assign = gimple_build_assign (original_ref, tmp);
gsi_insert_after (, assign, GSI_NEW_STMT);
assign = gimple_build_assign (tree_time_profiler_counter, tmp);
gsi_insert_after (, assign, GSI_NEW_STMT);
}
}
gcc/ChangeLog:
* tree-profile.cc (gen_counter_update): Use unshare_expr() for the
counter expression in the second gimple_build_assign().
---
gcc/tree-profile.cc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/tree-profile.cc b/gcc/tree-profile.cc
index 7d3cb1ef089..68db09f6189 100644
--- a/gcc/tree-profile.cc
+++ b/gcc/tree-profile.cc
@@ -354,7 +354,7 @@ gen_counter_update (gimple_stmt_iterator *gsi, tree
counter, tree result,
tree tmp2 = make_temp_ssa_name (type, NULL, name);
gassign *assign2 = gimple_build_assign (tmp2, PLUS_EXPR, tmp1, one);
gsi_insert_after (gsi, assign2, GSI_NEW_STMT);
- gassign *assign3 = gimple_build_assign (counter, tmp2);
+ gassign *assign3 = gimple_build_assign (unshare_expr (counter), tmp2);
gsi_insert_after (gsi, assign3, GSI_NEW_STMT);
if (result)
{
--
2.35.3
[PATCH 2/2] gcov: Fix integer types in gen_counter_update()
This change fixes issues like this: gcc.dg/gomp/pr27573.c: In function ‘main._omp_fn.0’: gcc.dg/gomp/pr27573.c:19:1: error: non-trivial conversion in ‘ssa_name’ 19 | } | ^ long int long unsigned int # .MEM_19 = VDEF <.MEM_18> __gcov7.main._omp_fn.0[0] = PROF_time_profile_12; during IPA pass: profile gcc.dg/gomp/pr27573.c:19:1: internal compiler error: verify_gimple failed gcc/ChangeLog: PR middle-end/112634 * tree-profile.cc (gen_assign_counter_update): Cast the unsigned result type of __atomic_add_fetch() to the signed counter type. --- gcc/tree-profile.cc | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/gcc/tree-profile.cc b/gcc/tree-profile.cc index 68db09f6189..54938e1d165 100644 --- a/gcc/tree-profile.cc +++ b/gcc/tree-profile.cc @@ -284,7 +284,9 @@ gen_assign_counter_update (gimple_stmt_iterator *gsi, gcall *call, tree func, tree tmp = make_temp_ssa_name (result_type, NULL, name); gimple_set_lhs (call, tmp); gsi_insert_after (gsi, call, GSI_NEW_STMT); - gassign *assign = gimple_build_assign (result, tmp); + gassign *assign = gimple_build_assign (result, +build_int_cst (TREE_TYPE (result), + tmp)); gsi_insert_after (gsi, assign, GSI_NEW_STMT); } else -- 2.35.3
Re: [PATCH 3/4] gcov: Add gen_counter_update()
Hello Dimitar, On 19.11.23 10:00, Dimitar Dimitrov wrote: On Tue, Nov 14, 2023 at 11:08:24PM +0100, Sebastian Huber wrote: Move the counter update to the new gen_counter_update() helper function. Use it in gimple_gen_edge_profiler() and gimple_gen_time_profiler(). The resulting gimple instructions should be identical with the exception of the removed unshare_expr() call. The unshare_expr() call was used in gimple_gen_edge_profiler(). gcc/ChangeLog: * tree-profile.cc (gen_assign_counter_update): New. (gen_counter_update): Likewise. (gimple_gen_edge_profiler): Use gen_counter_update(). (gimple_gen_time_profiler): Likewise. --- gcc/tree-profile.cc | 133 +--- 1 file changed, 62 insertions(+), 71 deletions(-) Hi Sebastian, This patch caused a bunch of test failures on arm-none-eabi and pru-unknown-elf targets. thanks for the report. I will have a look at this next week. I guess it has something to do with the removed unshare_expr() call. I don't really know what it does, but I will try to figure this out. -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/
Re: [PATCH 4/4] gcov: Improve -fprofile-update=atomic
Hello, sorry, in the patch I should use targetm.have_atomic instead of TARGET_HAVE_LIBATOMIC. --- embedded brains GmbH & Co. KG Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ v2-0001-gcov-Improve-fprofile-update-atomic.patch Description: application/mbox
[PATCH 4/4] gcov: Improve -fprofile-update=atomic
The code coverage support uses counters to determine which edges in the control
flow graph were executed. If a counter overflows, then the code coverage
information is invalid. Therefore the counter type should be a 64-bit integer.
In multi-threaded applications, it is important that the counter increments are
atomic. This is not the case by default. The user can enable atomic counter
increments through the -fprofile-update=atomic and
-fprofile-update=prefer-atomic options.
If the target supports 64-bit atomic operations, then everything is fine. If
not and -fprofile-update=prefer-atomic was chosen by the user, then non-atomic
counter increments will be used. However, if the target does not support the
required atomic operations and -fprofile-atomic=update was chosen by the user,
then a warning was issued and as a forced fallback to non-atomic operations was
done. This is probably not what a user wants. There is still hardware on the
market which does not have atomic operations and is used for multi-threaded
applications. A user which selects -fprofile-update=atomic wants consistent
code coverage data and not random data.
This patch removes the fallback to non-atomic operations for
-fprofile-update=atomic the target platform supports libatomic. To
mitigate potential performance issues an optimization for systems which
only support 32-bit atomic operations is provided. Here, the edge
counter increments are done like this:
low = __atomic_add_fetch_4 (, 1, MEMMODEL_RELAXED);
high_inc = low == 0 ? 1 : 0;
__atomic_add_fetch_4 (, high_inc, MEMMODEL_RELAXED);
In gimple_gen_time_profiler() this split operation cannot be used, since the
updated counter value is also required. Here, a library call is emitted. This
is not a performance issue since the update is only done if counters[0] == 0.
gcc/c-family/ChangeLog:
* c-cppbuiltin.cc (c_cpp_builtins): Define
__LIBGCC_HAVE_LIBATOMIC for libgcov.
gcc/ChangeLog:
* doc/invoke.texi (-fprofile-update): Clarify default method. Document
the atomic method behaviour.
* tree-profile.cc (enum counter_update_method): New.
(counter_update): Likewise.
(gen_counter_update): Use counter_update_method. Split the
atomic counter update in two 32-bit atomic operations if
necessary.
(tree_profiling): Select counter_update_method.
libgcc/ChangeLog:
* libgcov.h (GCOV_SUPPORTS_ATOMIC): Always define it.
Set it also to 1, if __LIBGCC_HAVE_LIBATOMIC is defined.
---
gcc/c-family/c-cppbuiltin.cc | 2 +
gcc/doc/invoke.texi | 19 ++-
gcc/tree-profile.cc | 99 +---
libgcc/libgcov.h | 10 ++--
4 files changed, 114 insertions(+), 16 deletions(-)
diff --git a/gcc/c-family/c-cppbuiltin.cc b/gcc/c-family/c-cppbuiltin.cc
index cdf9850cb19e..e8576737fafb 100644
--- a/gcc/c-family/c-cppbuiltin.cc
+++ b/gcc/c-family/c-cppbuiltin.cc
@@ -1538,6 +1538,8 @@ c_cpp_builtins (cpp_reader *pfile)
/* For libgcov. */
builtin_define_with_int_value ("__LIBGCC_VTABLE_USES_DESCRIPTORS__",
TARGET_VTABLE_USES_DESCRIPTORS);
+ builtin_define_with_int_value ("__LIBGCC_HAVE_LIBATOMIC",
+TARGET_HAVE_LIBATOMIC);
}
/* For use in assembly language. */
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index de40f62e219c..8fe3c86ad419 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -16603,7 +16603,24 @@ while the second one prevents profile corruption by
emitting thread-safe code.
Using @samp{prefer-atomic} would be transformed either to @samp{atomic},
when supported by a target, or to @samp{single} otherwise. The GCC driver
automatically selects @samp{prefer-atomic} when @option{-pthread}
-is present in the command line.
+is present in the command line, otherwise the default method is @samp{single}.
+
+If @samp{atomic} is selected, then the profile information is updated using
+atomic operations on a best-effort basis. Ideally, the profile information is
+updated through atomic operations in hardware. If the target platform does not
+support the required atomic operations in hardware, however, @file{libatomic}
+is available, then the profile information is updated through calls to
+@file{libatomic}. If the target platform neither supports the required atomic
+operations in hardware nor @file{libatomic}, then the profile information is
+not atomically updated and a warning is issued. In this case, the obtained
+profiling information may be corrupt for multi-threaded applications.
+
+For performance reasons, if 64-bit counters are used for the profiling
+information and the target platform only supports 32-bit atomic operations in
+hardware, then the performance critical profiling updates are done using two
+32-bit atomic operations for each counter update. If a signal interrupts these
+two operations updating
[PATCH 1/4] gcov: Remove TARGET_GCOV_TYPE_SIZE target hook
This reverts commit 8cdcea51c0fd753e6a652c9b236e91b3a6e0911c.
gcc/c-family/ChangeLog:
* c-cppbuiltin.cc (c_cpp_builtins): Do not define
__LIBGCC_GCOV_TYPE_SIZE.
gcc/ChangeLog:
* config/sparc/rtemself.h (SPARC_GCOV_TYPE_SIZE): Remove.
* config/sparc/sparc.cc (sparc_gcov_type_size): Likewise.
(TARGET_GCOV_TYPE_SIZE): Likewise.
* coverage.cc (get_gcov_type): Use LONG_LONG_TYPE_SIZE instead
of removed target hook.
* doc/tm.texi: Regenerate.
* doc/tm.texi.in (TARGET_GCOV_TYPE_SIZE): Remove.
* target.def: Likewise.
* targhooks.cc (default_gcov_type_size): Likewise.
* targhooks.h (default_gcov_type_size): Likewise.
libgcc/ChangeLog:
* libgcov.h (gcov_type): Use LONG_LONG_TYPE_SIZE.
(gcov_type_unsigned): Likewise.
---
gcc/c-family/c-cppbuiltin.cc | 2 --
gcc/config/sparc/rtemself.h | 2 --
gcc/config/sparc/sparc.cc| 11 ---
gcc/coverage.cc | 2 +-
gcc/doc/tm.texi | 11 ---
gcc/doc/tm.texi.in | 2 --
gcc/target.def | 12
gcc/targhooks.cc | 7 ---
gcc/targhooks.h | 2 --
libgcc/libgcov.h | 6 +++---
10 files changed, 4 insertions(+), 53 deletions(-)
diff --git a/gcc/c-family/c-cppbuiltin.cc b/gcc/c-family/c-cppbuiltin.cc
index 5d64625fcd7a..cdf9850cb19e 100644
--- a/gcc/c-family/c-cppbuiltin.cc
+++ b/gcc/c-family/c-cppbuiltin.cc
@@ -1538,8 +1538,6 @@ c_cpp_builtins (cpp_reader *pfile)
/* For libgcov. */
builtin_define_with_int_value ("__LIBGCC_VTABLE_USES_DESCRIPTORS__",
TARGET_VTABLE_USES_DESCRIPTORS);
- builtin_define_with_int_value ("__LIBGCC_GCOV_TYPE_SIZE",
-targetm.gcov_type_size());
}
/* For use in assembly language. */
diff --git a/gcc/config/sparc/rtemself.h b/gcc/config/sparc/rtemself.h
index bf4682238aea..28400a36126c 100644
--- a/gcc/config/sparc/rtemself.h
+++ b/gcc/config/sparc/rtemself.h
@@ -40,5 +40,3 @@
/* Use the default */
#undef LINK_GCC_C_SEQUENCE_SPEC
-
-#define SPARC_GCOV_TYPE_SIZE 32
diff --git a/gcc/config/sparc/sparc.cc b/gcc/config/sparc/sparc.cc
index 8c0c9dce9714..fd21281aee83 100644
--- a/gcc/config/sparc/sparc.cc
+++ b/gcc/config/sparc/sparc.cc
@@ -971,17 +971,6 @@ char sparc_hard_reg_printed[8];
#undef TARGET_ZERO_CALL_USED_REGS
#define TARGET_ZERO_CALL_USED_REGS sparc_zero_call_used_regs
-#ifdef SPARC_GCOV_TYPE_SIZE
-static HOST_WIDE_INT
-sparc_gcov_type_size (void)
-{
- return SPARC_GCOV_TYPE_SIZE;
-}
-
-#undef TARGET_GCOV_TYPE_SIZE
-#define TARGET_GCOV_TYPE_SIZE sparc_gcov_type_size
-#endif
-
struct gcc_target targetm = TARGET_INITIALIZER;
/* Return the memory reference contained in X if any, zero otherwise. */
diff --git a/gcc/coverage.cc b/gcc/coverage.cc
index 7ed3a5d4cebf..ad55f0f19096 100644
--- a/gcc/coverage.cc
+++ b/gcc/coverage.cc
@@ -138,7 +138,7 @@ tree
get_gcov_type (void)
{
scalar_int_mode mode
-= smallest_int_mode_for_size (targetm.gcov_type_size ());
+= smallest_int_mode_for_size (LONG_LONG_TYPE_SIZE > 32 ? 64 : 32);
return lang_hooks.types.type_for_mode (mode, false);
}
diff --git a/gcc/doc/tm.texi b/gcc/doc/tm.texi
index a660e33739bd..d93b33099dd4 100644
--- a/gcc/doc/tm.texi
+++ b/gcc/doc/tm.texi
@@ -12431,17 +12431,6 @@ Store the result in @var{target} if convenient.
The default clears the top byte of the original pointer.
@end deftypefn
-@deftypefn {Target Hook} HOST_WIDE_INT TARGET_GCOV_TYPE_SIZE (void)
-Returns the gcov type size in bits. This type is used for example for
-counters incremented by profiling and code-coverage events. The default
-value is 64, if the type size of long long is greater than 32, otherwise the
-default value is 32. A 64-bit type is recommended to avoid overflows of the
-counters. If the @option{-fprofile-update=atomic} is used, then the
-counters are incremented using atomic operations. Targets not supporting
-64-bit atomic operations may override the default value and request a 32-bit
-type.
-@end deftypefn
-
@deftypevr {Target Hook} bool TARGET_HAVE_SHADOW_CALL_STACK
This value is true if the target platform supports
@option{-fsanitize=shadow-call-stack}. The default value is false.
diff --git a/gcc/doc/tm.texi.in b/gcc/doc/tm.texi.in
index f7ab5d48a634..9061a5b26af9 100644
--- a/gcc/doc/tm.texi.in
+++ b/gcc/doc/tm.texi.in
@@ -7981,6 +7981,4 @@ maintainer is familiar with.
@hook TARGET_MEMTAG_UNTAGGED_POINTER
-@hook TARGET_GCOV_TYPE_SIZE
-
@hook TARGET_HAVE_SHADOW_CALL_STACK
diff --git a/gcc/target.def b/gcc/target.def
index 171bbd1caf15..5c10c702a26e 100644
--- a/gcc/target.def
+++ b/gcc/target.def
@@ -7118,18 +7118,6 @@ DEFHOOK
void, (void),
NULL)
-DEFHOOK
-(gcov_type_size,
- "Returns the gcov type size in bits. This type is used for example for\n\
-counters incremented by profiling and code-coverage events. The
[PATCH 3/4] gcov: Add gen_counter_update()
Move the counter update to the new gen_counter_update() helper function. Use
it in gimple_gen_edge_profiler() and gimple_gen_time_profiler(). The resulting
gimple instructions should be identical with the exception of the removed
unshare_expr() call. The unshare_expr() call was used in
gimple_gen_edge_profiler().
gcc/ChangeLog:
* tree-profile.cc (gen_assign_counter_update): New.
(gen_counter_update): Likewise.
(gimple_gen_edge_profiler): Use gen_counter_update().
(gimple_gen_time_profiler): Likewise.
---
gcc/tree-profile.cc | 133 +---
1 file changed, 62 insertions(+), 71 deletions(-)
diff --git a/gcc/tree-profile.cc b/gcc/tree-profile.cc
index da300d5f9e8d..24805ff905c7 100644
--- a/gcc/tree-profile.cc
+++ b/gcc/tree-profile.cc
@@ -235,47 +235,78 @@ gimple_init_gcov_profiler (void)
}
}
-/* Output instructions as GIMPLE trees to increment the edge
- execution count, and insert them on E. We rely on
- gsi_insert_on_edge to preserve the order. */
+/* If RESULT is not null, then output instructions as GIMPLE trees to assign
+ the updated counter from CALL of FUNC to RESULT. Insert the CALL and the
+ optional assignment instructions to GSI. Use NAME for temporary values. */
-void
-gimple_gen_edge_profiler (int edgeno, edge e)
+static inline void
+gen_assign_counter_update (gimple_stmt_iterator *gsi, gcall *call, tree func,
+ tree result, const char *name)
{
- tree one;
+ if (result)
+{
+ tree result_type = TREE_TYPE (TREE_TYPE (func));
+ tree tmp = make_temp_ssa_name (result_type, NULL, name);
+ gimple_set_lhs (call, tmp);
+ gsi_insert_after (gsi, call, GSI_NEW_STMT);
+ gassign *assign = gimple_build_assign (result, tmp);
+ gsi_insert_after (gsi, assign, GSI_NEW_STMT);
+}
+ else
+gsi_insert_after (gsi, call, GSI_NEW_STMT);
+}
- one = build_int_cst (gcov_type_node, 1);
+/* Output instructions as GIMPLE trees to increment the COUNTER. If RESULT is
+ not null, then assign the updated counter value to RESULT. Insert the
+ instructions to GSI. Use NAME for temporary values. */
+
+static inline void
+gen_counter_update (gimple_stmt_iterator *gsi, tree counter, tree result,
+ const char *name)
+{
+ tree type = gcov_type_node;
+ tree addr = build_fold_addr_expr (counter);
+ tree one = build_int_cst (type, 1);
+ tree relaxed = build_int_cst (integer_type_node, MEMMODEL_RELAXED);
if (flag_profile_update == PROFILE_UPDATE_ATOMIC)
{
/* __atomic_fetch_add (, 1, MEMMODEL_RELAXED); */
- tree addr = tree_coverage_counter_addr (GCOV_COUNTER_ARCS, edgeno);
- tree f = builtin_decl_explicit (TYPE_PRECISION (gcov_type_node) > 32
- ? BUILT_IN_ATOMIC_FETCH_ADD_8:
- BUILT_IN_ATOMIC_FETCH_ADD_4);
- gcall *stmt = gimple_build_call (f, 3, addr, one,
- build_int_cst (integer_type_node,
- MEMMODEL_RELAXED));
- gsi_insert_on_edge (e, stmt);
+ tree f = builtin_decl_explicit (TYPE_PRECISION (type) > 32
+ ? BUILT_IN_ATOMIC_ADD_FETCH_8:
+ BUILT_IN_ATOMIC_ADD_FETCH_4);
+ gcall *call = gimple_build_call (f, 3, addr, one, relaxed);
+ gen_assign_counter_update (gsi, call, f, result, name);
}
else
{
- tree ref = tree_coverage_counter_ref (GCOV_COUNTER_ARCS, edgeno);
- tree gcov_type_tmp_var = make_temp_ssa_name (gcov_type_node,
- NULL, "PROF_edge_counter");
- gassign *stmt1 = gimple_build_assign (gcov_type_tmp_var, ref);
- gcov_type_tmp_var = make_temp_ssa_name (gcov_type_node,
- NULL, "PROF_edge_counter");
- gassign *stmt2 = gimple_build_assign (gcov_type_tmp_var, PLUS_EXPR,
- gimple_assign_lhs (stmt1), one);
- gassign *stmt3 = gimple_build_assign (unshare_expr (ref),
- gimple_assign_lhs (stmt2));
- gsi_insert_on_edge (e, stmt1);
- gsi_insert_on_edge (e, stmt2);
- gsi_insert_on_edge (e, stmt3);
+ tree tmp1 = make_temp_ssa_name (type, NULL, name);
+ gassign *assign1 = gimple_build_assign (tmp1, counter);
+ gsi_insert_after (gsi, assign1, GSI_NEW_STMT);
+ tree tmp2 = make_temp_ssa_name (type, NULL, name);
+ gassign *assign2 = gimple_build_assign (tmp2, PLUS_EXPR, tmp1, one);
+ gsi_insert_after (gsi, assign2, GSI_NEW_STMT);
+ gassign *assign3 = gimple_build_assign (counter, tmp2);
+ gsi_insert_after (gsi, assign3, GSI_NEW_STMT);
+ if (result)
+ {
+ gassign *assign4 = gimple_build_assign (result, tmp2);
+ gsi_insert_after (gsi, assign4, GSI_NEW_STMT);
+ }
}
}
[PATCH 0/4] gcov: Improve -fprofile-update=atomic
Sebastian Huber (4): gcov: Remove TARGET_GCOV_TYPE_SIZE target hook Add TARGET_HAVE_LIBATOMIC gcov: Add gen_counter_update() gcov: Improve -fprofile-update=atomic gcc/c-family/c-cppbuiltin.cc | 4 +- gcc/config/rtems.h | 2 + gcc/config/sparc/rtemself.h | 2 - gcc/config/sparc/sparc.cc| 11 -- gcc/coverage.cc | 2 +- gcc/doc/invoke.texi | 19 ++- gcc/doc/tm.texi | 16 +-- gcc/doc/tm.texi.in | 4 +- gcc/target.def | 20 ++- gcc/targhooks.cc | 7 -- gcc/targhooks.h | 2 - gcc/tree-profile.cc | 232 +++ libgcc/libgcov.h | 16 +-- 13 files changed, 197 insertions(+), 140 deletions(-) -- 2.35.3
[PATCH 2/4] Add TARGET_HAVE_LIBATOMIC
Add target data to indicate if libatomic is available.
gcc/ChangeLog:
* config/rtems.h (TARGET_HAVE_LIBATOMIC): Define.
* doc/tm.texi: Regenerate.
* doc/tm.texi.in (TARGET_HAVE_LIBATOMIC): Add.
* target.def (have_libatomic): New.
---
gcc/config/rtems.h | 2 ++
gcc/doc/tm.texi| 5 +
gcc/doc/tm.texi.in | 2 ++
gcc/target.def | 8
4 files changed, 17 insertions(+)
diff --git a/gcc/config/rtems.h b/gcc/config/rtems.h
index 8641ea15271d..2c006e4c1e54 100644
--- a/gcc/config/rtems.h
+++ b/gcc/config/rtems.h
@@ -53,6 +53,8 @@
#define TARGET_POSIX_IO
+#define TARGET_HAVE_LIBATOMIC true
+
/* Prefer int for int32_t (see stdint-newlib.h). */
#undef STDINT_LONG32
#define STDINT_LONG32 (INT_TYPE_SIZE != 32 && LONG_TYPE_SIZE == 32)
diff --git a/gcc/doc/tm.texi b/gcc/doc/tm.texi
index d93b33099dd4..04cd12de792c 100644
--- a/gcc/doc/tm.texi
+++ b/gcc/doc/tm.texi
@@ -12435,3 +12435,8 @@ The default clears the top byte of the original pointer.
This value is true if the target platform supports
@option{-fsanitize=shadow-call-stack}. The default value is false.
@end deftypevr
+
+@deftypevr {Target Hook} bool TARGET_HAVE_LIBATOMIC
+This value is true if the target platform supports
+libatomic. The default value is false.
+@end deftypevr
diff --git a/gcc/doc/tm.texi.in b/gcc/doc/tm.texi.in
index 9061a5b26af9..19d21999317a 100644
--- a/gcc/doc/tm.texi.in
+++ b/gcc/doc/tm.texi.in
@@ -7982,3 +7982,5 @@ maintainer is familiar with.
@hook TARGET_MEMTAG_UNTAGGED_POINTER
@hook TARGET_HAVE_SHADOW_CALL_STACK
+
+@hook TARGET_HAVE_LIBATOMIC
diff --git a/gcc/target.def b/gcc/target.def
index 5c10c702a26e..bf0d6e0aeda1 100644
--- a/gcc/target.def
+++ b/gcc/target.def
@@ -7126,6 +7126,14 @@ DEFHOOKPOD
@option{-fsanitize=shadow-call-stack}. The default value is false.",
bool, false)
+/* This value represents whether libatomic is available on
+ the target platform. */
+DEFHOOKPOD
+(have_libatomic,
+ "This value is true if the target platform supports\n\
+libatomic. The default value is false.",
+ bool, false)
+
/* Close the 'struct gcc_target' definition. */
HOOK_VECTOR_END (C90_EMPTY_HACK)
--
2.35.3
License of libgcc/config/sparc/lb1spc.S?
Hello, under which license is libgcc/config/sparc/lb1spc.S? The header says: /* This is an assembly language implementation of mulsi3, divsi3, and modsi3 for the sparc processor. These routines are derived from the SPARC Architecture Manual, version 8, slightly edited to match the desired calling convention, and also to optimize them for our purposes. */ -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/
Re: [PATCH] libatomic: Provide gthr.h default implementation
On 31.05.23 09:27, Richard Biener wrote: On Wed, May 31, 2023 at 7:31 AM Sebastian Huber wrote: On 30.05.23 13:17, Richard Biener wrote: The alternative would be to provide the required subset of atomic library functions from libgcov.a and emit calls to that directly? The locked data isn't part of any ABI so no compatibility guarantee needs to be maintained? So, if atomic operations are not available in hardware, then I should emit calls to libgcov.a which would use gthr.h to implement them? I guess that I can to this, but it needs a bit of time. Before doing that it would be nice to get buy-in from others - maybe my ABI concern for libatomic isn't shared by others. I would be nice if I could add the multi-threaded gcov support for targets lacking atomic operations in GCC 14 (for example 32-bit RISC-V). I need a direction how to implement this. Should it be done through a generic libatomic implementation based on gthr.h or through a special function provided by libgcov? Should I add the libgcov functions to builtin_decl_explicit()? No, they shouldn't be any different from other libgcov functions. Ok. -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/
Re: [PATCH] libgomp: Fix build for -fshort-enums
On 04.07.23 08:20, Sebastian Huber wrote: On 22.05.23 14:51, Sebastian Huber wrote: Make sure that the API enums have at least the size of int. Otherwise the following build error may occur: In file included from gcc/libgomp/env.c:34: ./libgomp_f.h: In function 'omp_check_defines': ./libgomp_f.h:77:8: error: size of array 'test' is negative 77 | char test[(28 != sizeof (omp_lock_t) | ^~~~ libgomp/ChangeLog: * omp.h.in (omp_alloctrait_key_t): Add __omp_alloctrait_key_t_max__ with a value of the int type maximum. --- libgomp/omp.h.in | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/libgomp/omp.h.in b/libgomp/omp.h.in index bd1286c2a3f..3b1612fcb15 100644 --- a/libgomp/omp.h.in +++ b/libgomp/omp.h.in @@ -146,7 +146,8 @@ typedef enum omp_alloctrait_key_t omp_atk_fallback = 5, omp_atk_fb_data = 6, omp_atk_pinned = 7, - omp_atk_partition = 8 + omp_atk_partition = 8, + __omp_alloctrait_key_t_max__ = __INT_MAX__ } omp_alloctrait_key_t; typedef enum omp_alloctrait_value_t Could someone please have a look at this. Ping. -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/
Re: [PATCH] libgomp: Fix build for -fshort-enums
On 22.05.23 14:51, Sebastian Huber wrote: Make sure that the API enums have at least the size of int. Otherwise the following build error may occur: In file included from gcc/libgomp/env.c:34: ./libgomp_f.h: In function 'omp_check_defines': ./libgomp_f.h:77:8: error: size of array 'test' is negative 77 | char test[(28 != sizeof (omp_lock_t) |^~~~ libgomp/ChangeLog: * omp.h.in (omp_alloctrait_key_t): Add __omp_alloctrait_key_t_max__ with a value of the int type maximum. --- libgomp/omp.h.in | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/libgomp/omp.h.in b/libgomp/omp.h.in index bd1286c2a3f..3b1612fcb15 100644 --- a/libgomp/omp.h.in +++ b/libgomp/omp.h.in @@ -146,7 +146,8 @@ typedef enum omp_alloctrait_key_t omp_atk_fallback = 5, omp_atk_fb_data = 6, omp_atk_pinned = 7, - omp_atk_partition = 8 + omp_atk_partition = 8, + __omp_alloctrait_key_t_max__ = __INT_MAX__ } omp_alloctrait_key_t; typedef enum omp_alloctrait_value_t Could someone please have a look at this. -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/
Re: [PATCH] libatomic: Provide gthr.h default implementation
On 30.05.23 13:17, Richard Biener wrote: The alternative would be to provide the required subset of atomic library functions from libgcov.a and emit calls to that directly? The locked data isn't part of any ABI so no compatibility guarantee needs to be maintained? So, if atomic operations are not available in hardware, then I should emit calls to libgcov.a which would use gthr.h to implement them? I guess that I can to this, but it needs a bit of time. Should I add the libgcov functions to builtin_decl_explicit()? -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/
Re: [PATCH] libatomic: Provide gthr.h default implementation
On 30.05.23 11:53, Richard Biener wrote: On Tue, May 23, 2023 at 11:28 AM Sebastian Huber wrote: On 10.01.23 16:38, Sebastian Huber wrote: On 19/12/2022 17:02, Sebastian Huber wrote: Build libatomic for all targets. Use gthr.h to provide a default implementation. If the thread model is "single", then this implementation will not work if for example atomic operations are used for thread/interrupt synchronization. Is this and the related -fprofile-update=atomic patch something for GCC 14? Now that the GCC 14 development is in progress, what about this patch? Sorry, there doesn't seem to be a main maintainer for libatomic and your patch touches targets which didn't have it before. Can you explain how this affects the ABI of targets not having (needing?!) libatomic? It might help if you can say this is still opt-in and targets not building libatomic right now would not with your patch and targets already building libatomic have no changes with your patch. That said - what kind of ABI implications has providing libatomic support for a target that didn't do so before? Sorry for the missing context. The root problem I want to solve is getting gcov support for multi-threaded applications. For this we need atomic 64-bit operations, see also: https://gcc.gnu.org/pipermail/gcc-patches/2022-December/608620.html The libatomic patch lets it build for every target. Targets with no explicit support will use the gthr.h API to provide a default implementation. An alternative would be to use the RTEMS approach which uses the following API (provided by Newlib for RTEMS): #include #include __BEGIN_DECLS __uint32_t _Libatomic_Protect_start(void *); void _Libatomic_Protect_end(void *, __uint32_t); void _Libatomic_Lock_n(void *, __size_t); void _Libatomic_Unlock_n(void *, __size_t); __END_DECLS We could also leave libatomic as is, but then you may get unresolved references if you use -fprofile-update=atomic with the patch mentioned above. -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/
Re: [PATCH] libatomic: Provide gthr.h default implementation
On 10.01.23 16:38, Sebastian Huber wrote: On 19/12/2022 17:02, Sebastian Huber wrote: Build libatomic for all targets. Use gthr.h to provide a default implementation. If the thread model is "single", then this implementation will not work if for example atomic operations are used for thread/interrupt synchronization. Is this and the related -fprofile-update=atomic patch something for GCC 14? Now that the GCC 14 development is in progress, what about this patch? -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/
[PATCH] libgomp: Fix build for -fshort-enums
Make sure that the API enums have at least the size of int. Otherwise the following build error may occur: In file included from gcc/libgomp/env.c:34: ./libgomp_f.h: In function 'omp_check_defines': ./libgomp_f.h:77:8: error: size of array 'test' is negative 77 | char test[(28 != sizeof (omp_lock_t) |^~~~ libgomp/ChangeLog: * omp.h.in (omp_alloctrait_key_t): Add __omp_alloctrait_key_t_max__ with a value of the int type maximum. --- libgomp/omp.h.in | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/libgomp/omp.h.in b/libgomp/omp.h.in index bd1286c2a3f..3b1612fcb15 100644 --- a/libgomp/omp.h.in +++ b/libgomp/omp.h.in @@ -146,7 +146,8 @@ typedef enum omp_alloctrait_key_t omp_atk_fallback = 5, omp_atk_fb_data = 6, omp_atk_pinned = 7, - omp_atk_partition = 8 + omp_atk_partition = 8, + __omp_alloctrait_key_t_max__ = __INT_MAX__ } omp_alloctrait_key_t; typedef enum omp_alloctrait_value_t -- 2.35.3
Re: [wwwdocs] gcc-13: Mention new gcov feature
On 26.04.23 08:10, Sebastian Huber wrote: --- htdocs/gcc-13/changes.html | 5 + 1 file changed, 5 insertions(+) diff --git a/htdocs/gcc-13/changes.html b/htdocs/gcc-13/changes.html index 4515a6af..bae65219 100644 --- a/htdocs/gcc-13/changes.html +++ b/htdocs/gcc-13/changes.html @@ -154,6 +154,11 @@ a work-in-progress. where the json-prefixed variants refer to GCC's own JSON diagnostic format. + +Support for profiling and test coverage in freestanding environments has +been added, see also +https://gcc.gnu.org/onlinedocs/gcc/Freestanding-Environments.html;>Profiling and Test Coverage in Freestanding Environments. + Yes, no, maybe? -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/
[wwwdocs] gcc-13: Mention new gcov feature
--- htdocs/gcc-13/changes.html | 5 + 1 file changed, 5 insertions(+) diff --git a/htdocs/gcc-13/changes.html b/htdocs/gcc-13/changes.html index 4515a6af..bae65219 100644 --- a/htdocs/gcc-13/changes.html +++ b/htdocs/gcc-13/changes.html @@ -154,6 +154,11 @@ a work-in-progress. where the json-prefixed variants refer to GCC's own JSON diagnostic format. + +Support for profiling and test coverage in freestanding environments has +been added, see also +https://gcc.gnu.org/onlinedocs/gcc/Freestanding-Environments.html;>Profiling and Test Coverage in Freestanding Environments. + -- 2.35.3
Re: Third GC 13.1 Release Candidate available from gcc.gnu.org
On 21.04.23 23:14, William Seurer via Gcc wrote: I bootstrapped and tested this on powerpc64 power 7, 8, 9, and 10 and on both BE and LE and saw nothing unexpected. I have problems to build a 32-bit powerpc compiler. It cannot build Newlib: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109566 -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/
Re: [gcc] RTEMS: Tune multilib selection
On 23.02.23 19:38, Palmer Dabbelt wrote: On Thu, 23 Feb 2023 03:48:26 PST (-0800), sebastian.hu...@embedded-brains.de wrote: gcc/ChangeLog: * config/riscv/t-rtems: Keep only -mcmodel=medany 64-bit multilibs. Add non-compact 32-bit multilibs. --- gcc/config/riscv/t-rtems | 17 + 1 file changed, 9 insertions(+), 8 deletions(-) diff --git a/gcc/config/riscv/t-rtems b/gcc/config/riscv/t-rtems index 41f5927fc87..19b12030895 100644 --- a/gcc/config/riscv/t-rtems +++ b/gcc/config/riscv/t-rtems @@ -1,8 +1,8 @@ MULTILIB_OPTIONS = MULTILIB_DIRNAMES = -MULTILIB_OPTIONS += march=rv32i/march=rv32im/march=rv32imafd/march=rv32iac/march=rv32imac/march=rv32imafc/march=rv64imafd/march=rv64imac/march=rv64imafdc -MULTILIB_DIRNAMES += rv32i rv32im rv32imafd rv32iac rv32imac rv32imafc rv64imafd rv64imac rv64imafdc +MULTILIB_OPTIONS += march=rv32i/march=rv32iac/march=rv32im/march=rv32ima/march=rv32imac/march=rv32imaf/march=rv32imafc/march=rv32imafd/march=rv32imafdc/march=rv64ima/march=rv64imac/march=rv64imafd/march=rv64imafdc +MULTILIB_DIRNAMES += rv32i rv32iac rv32im rv32ima rv32imac rv32imaf rv32imafc rv32imafd rv32imafdc rv64ima rv64imac rv64imafd rv64imafdc MULTILIB_OPTIONS += mabi=ilp32/mabi=ilp32f/mabi=ilp32d/mabi=lp64/mabi=lp64d MULTILIB_DIRNAMES += ilp32 ilp32f ilp32d lp64 lp64d @@ -12,14 +12,15 @@ MULTILIB_DIRNAMES += medany MULTILIB_REQUIRED = MULTILIB_REQUIRED += march=rv32i/mabi=ilp32 -MULTILIB_REQUIRED += march=rv32im/mabi=ilp32 -MULTILIB_REQUIRED += march=rv32imafd/mabi=ilp32d MULTILIB_REQUIRED += march=rv32iac/mabi=ilp32 +MULTILIB_REQUIRED += march=rv32im/mabi=ilp32 +MULTILIB_REQUIRED += march=rv32ima/mabi=ilp32 MULTILIB_REQUIRED += march=rv32imac/mabi=ilp32 +MULTILIB_REQUIRED += march=rv32imaf/mabi=ilp32f MULTILIB_REQUIRED += march=rv32imafc/mabi=ilp32f -MULTILIB_REQUIRED += march=rv64imafd/mabi=lp64d -MULTILIB_REQUIRED += march=rv64imafd/mabi=lp64d/mcmodel=medany -MULTILIB_REQUIRED += march=rv64imac/mabi=lp64 +MULTILIB_REQUIRED += march=rv32imafd/mabi=ilp32d +MULTILIB_REQUIRED += march=rv32imafdc/mabi=ilp32d +MULTILIB_REQUIRED += march=rv64ima/mabi=lp64/mcmodel=medany MULTILIB_REQUIRED += march=rv64imac/mabi=lp64/mcmodel=medany -MULTILIB_REQUIRED += march=rv64imafdc/mabi=lp64d +MULTILIB_REQUIRED += march=rv64imafd/mabi=lp64d/mcmodel=medany MULTILIB_REQUIRED += march=rv64imafdc/mabi=lp64d/mcmodel=medany Reviewed-by: Palmer Dabbelt IMO it's fine to remove multilibs from the default set. It could be seen as breaking users, but IIRC last time we talked about something like this it was OK as otherwise we're going to end up with a huge set of multilibs for defunct ISAs. This one is also extra safe, since moving to medany shouldn't break any users (aside from maybe a slight performance issue). Thanks for the review. Which performance issue may show up here? Are you aiming for GCC-13 with this? I wouldn't be opposed to that: there's some risk of breaking users this late in the process, but my guess is that most of them aren't looking until release anyway. Still better to hold off, but if there's something in RTEMS land that benefits from this being early then I think it's fine. RTEMS has its own release cycle, so I would back port this change to all GCC branches which may be used with RTEMS 6 and this is GCC 10 or later. -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/
[gcc] RTEMS: Tune multilib selection
gcc/ChangeLog: * config/riscv/t-rtems: Keep only -mcmodel=medany 64-bit multilibs. Add non-compact 32-bit multilibs. --- gcc/config/riscv/t-rtems | 17 + 1 file changed, 9 insertions(+), 8 deletions(-) diff --git a/gcc/config/riscv/t-rtems b/gcc/config/riscv/t-rtems index 41f5927fc87..19b12030895 100644 --- a/gcc/config/riscv/t-rtems +++ b/gcc/config/riscv/t-rtems @@ -1,8 +1,8 @@ MULTILIB_OPTIONS = MULTILIB_DIRNAMES = -MULTILIB_OPTIONS += march=rv32i/march=rv32im/march=rv32imafd/march=rv32iac/march=rv32imac/march=rv32imafc/march=rv64imafd/march=rv64imac/march=rv64imafdc -MULTILIB_DIRNAMES += rv32i rv32im rv32imafd rv32iac rv32imac rv32imafc rv64imafd rv64imac rv64imafdc +MULTILIB_OPTIONS += march=rv32i/march=rv32iac/march=rv32im/march=rv32ima/march=rv32imac/march=rv32imaf/march=rv32imafc/march=rv32imafd/march=rv32imafdc/march=rv64ima/march=rv64imac/march=rv64imafd/march=rv64imafdc +MULTILIB_DIRNAMES += rv32i rv32iac rv32im rv32ima rv32imac rv32imaf rv32imafc rv32imafd rv32imafdc rv64ima rv64imac rv64imafd rv64imafdc MULTILIB_OPTIONS += mabi=ilp32/mabi=ilp32f/mabi=ilp32d/mabi=lp64/mabi=lp64d MULTILIB_DIRNAMES += ilp32 ilp32f ilp32d lp64 lp64d @@ -12,14 +12,15 @@ MULTILIB_DIRNAMES += medany MULTILIB_REQUIRED = MULTILIB_REQUIRED += march=rv32i/mabi=ilp32 -MULTILIB_REQUIRED += march=rv32im/mabi=ilp32 -MULTILIB_REQUIRED += march=rv32imafd/mabi=ilp32d MULTILIB_REQUIRED += march=rv32iac/mabi=ilp32 +MULTILIB_REQUIRED += march=rv32im/mabi=ilp32 +MULTILIB_REQUIRED += march=rv32ima/mabi=ilp32 MULTILIB_REQUIRED += march=rv32imac/mabi=ilp32 +MULTILIB_REQUIRED += march=rv32imaf/mabi=ilp32f MULTILIB_REQUIRED += march=rv32imafc/mabi=ilp32f -MULTILIB_REQUIRED += march=rv64imafd/mabi=lp64d -MULTILIB_REQUIRED += march=rv64imafd/mabi=lp64d/mcmodel=medany -MULTILIB_REQUIRED += march=rv64imac/mabi=lp64 +MULTILIB_REQUIRED += march=rv32imafd/mabi=ilp32d +MULTILIB_REQUIRED += march=rv32imafdc/mabi=ilp32d +MULTILIB_REQUIRED += march=rv64ima/mabi=lp64/mcmodel=medany MULTILIB_REQUIRED += march=rv64imac/mabi=lp64/mcmodel=medany -MULTILIB_REQUIRED += march=rv64imafdc/mabi=lp64d +MULTILIB_REQUIRED += march=rv64imafd/mabi=lp64d/mcmodel=medany MULTILIB_REQUIRED += march=rv64imafdc/mabi=lp64d/mcmodel=medany -- 2.35.3
Re: [PATCH] libatomic: Provide gthr.h default implementation
On 19/12/2022 17:02, Sebastian Huber wrote: Build libatomic for all targets. Use gthr.h to provide a default implementation. If the thread model is "single", then this implementation will not work if for example atomic operations are used for thread/interrupt synchronization. Is this and the related -fprofile-update=atomic patch something for GCC 14? -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/
[PATCH] libatomic: Provide gthr.h default implementation
Build libatomic for all targets. Use gthr.h to provide a default implementation. If the thread model is "single", then this implementation will not work if for example atomic operations are used for thread/interrupt synchronization. libatomic/ChangeLog: * Makefile.am (BUILT_SOURCES): New. (gthr.h): Link from libgcc source file if USE_CONFIG_GTHR is enabled. (gthr-default.h): Likewise. * Makefile.in: Regenerate. * configure: Likewise. * configure.ac: Map thread model to thread header. (thread_header): New substitution. (USE_CONFIG_GTHR): New automake conditional. * configure.tgt (*-*-elf*): Delete. (UNSUPPORTED): Likewise. (USE_CONFIG_GTHR): Define as default. * testsuite/Makefile.in: Regenerate. * config/gthr/host-config.h: New file. * config/gthr/lock.c: Likewise. --- libatomic/Makefile.am | 12 +++ libatomic/Makefile.in | 40 +--- libatomic/config/gthr/host-config.h | 55 +++ libatomic/config/gthr/lock.c| 136 libatomic/configure | 40 +++- libatomic/configure.ac | 10 +- libatomic/configure.tgt | 16 +--- libatomic/testsuite/Makefile.in | 4 +- 8 files changed, 281 insertions(+), 32 deletions(-) create mode 100644 libatomic/config/gthr/host-config.h create mode 100644 libatomic/config/gthr/lock.c diff --git a/libatomic/Makefile.am b/libatomic/Makefile.am index 41e5da28512..d56d553c9d5 100644 --- a/libatomic/Makefile.am +++ b/libatomic/Makefile.am @@ -34,6 +34,18 @@ search_path = $(addprefix $(top_srcdir)/config/, $(config_path)) \ vpath % $(strip $(search_path)) +BUILT_SOURCES = + +if USE_CONFIG_GTHR +gthr.h: $(top_srcdir)/../libgcc/gthr.h + -$(LN_S) $< $@ + +gthr-default.h: $(top_srcdir)/../libgcc/$(thread_header) + -$(LN_S) $< $@ + +BUILT_SOURCES += gthr.h gthr-default.h +endif + DEFAULT_INCLUDES = $(addprefix -I, $(search_path)) AM_CFLAGS = $(XCFLAGS) AM_CCASFLAGS = $(XCFLAGS) diff --git a/libatomic/Makefile.in b/libatomic/Makefile.in index a0fa3dfc8cc..2e3ddd014f8 100644 --- a/libatomic/Makefile.in +++ b/libatomic/Makefile.in @@ -89,15 +89,16 @@ POST_UNINSTALL = : build_triplet = @build@ host_triplet = @host@ target_triplet = @target@ -@ARCH_AARCH64_LINUX_TRUE@@HAVE_IFUNC_TRUE@am__append_1 = $(foreach s,$(SIZES),$(addsuffix _$(s)_1_.lo,$(SIZEOBJS))) -@ARCH_AARCH64_LINUX_TRUE@@HAVE_IFUNC_TRUE@am__append_2 = atomic_16.S -@ARCH_ARM_LINUX_TRUE@@HAVE_IFUNC_TRUE@am__append_3 = $(foreach \ +@USE_CONFIG_GTHR_TRUE@am__append_1 = gthr.h gthr-default.h +@ARCH_AARCH64_LINUX_TRUE@@HAVE_IFUNC_TRUE@am__append_2 = $(foreach s,$(SIZES),$(addsuffix _$(s)_1_.lo,$(SIZEOBJS))) +@ARCH_AARCH64_LINUX_TRUE@@HAVE_IFUNC_TRUE@am__append_3 = atomic_16.S +@ARCH_ARM_LINUX_TRUE@@HAVE_IFUNC_TRUE@am__append_4 = $(foreach \ @ARCH_ARM_LINUX_TRUE@@HAVE_IFUNC_TRUE@ s,$(SIZES),$(addsuffix \ @ARCH_ARM_LINUX_TRUE@@HAVE_IFUNC_TRUE@ _$(s)_1_.lo,$(SIZEOBJS))) \ @ARCH_ARM_LINUX_TRUE@@HAVE_IFUNC_TRUE@ $(addsuffix \ @ARCH_ARM_LINUX_TRUE@@HAVE_IFUNC_TRUE@ _8_2_.lo,$(SIZEOBJS)) -@ARCH_I386_TRUE@@HAVE_IFUNC_TRUE@am__append_4 = $(addsuffix _8_1_.lo,$(SIZEOBJS)) -@ARCH_X86_64_TRUE@@HAVE_IFUNC_TRUE@am__append_5 = $(addsuffix _16_1_.lo,$(SIZEOBJS)) \ +@ARCH_I386_TRUE@@HAVE_IFUNC_TRUE@am__append_5 = $(addsuffix _8_1_.lo,$(SIZEOBJS)) +@ARCH_X86_64_TRUE@@HAVE_IFUNC_TRUE@am__append_6 = $(addsuffix _16_1_.lo,$(SIZEOBJS)) \ @ARCH_X86_64_TRUE@@HAVE_IFUNC_TRUE@ $(addsuffix _16_2_.lo,$(SIZEOBJS)) subdir = . @@ -115,7 +116,8 @@ am__aclocal_m4_deps = $(top_srcdir)/../config/acx.m4 \ $(top_srcdir)/../ltversion.m4 $(top_srcdir)/../lt~obsolete.m4 \ $(top_srcdir)/acinclude.m4 $(top_srcdir)/../libtool.m4 \ $(top_srcdir)/../config/enable.m4 \ - $(top_srcdir)/../config/cet.m4 $(top_srcdir)/configure.ac + $(top_srcdir)/../config/cet.m4 $(top_srcdir)/../config/gthr.m4 \ + $(top_srcdir)/configure.ac am__configure_deps = $(am__aclocal_m4_deps) $(CONFIGURE_DEPENDENCIES) \ $(ACLOCAL_M4) DIST_COMMON = $(srcdir)/Makefile.am $(top_srcdir)/configure \ @@ -392,6 +394,7 @@ target_alias = @target_alias@ target_cpu = @target_cpu@ target_os = @target_os@ target_vendor = @target_vendor@ +thread_header = @thread_header@ tmake_file = @tmake_file@ toolexecdir = @toolexecdir@ toolexeclibdir = @toolexeclibdir@ @@ -404,6 +407,7 @@ gcc_version := $(shell @get_gcc_base_ver@ $(top_srcdir)/../gcc/BASE-VER) search_path = $(addprefix $(top_srcdir)/config/, $(config_path)) \ $(top_srcdir) $(top_builddir) +BUILT_SOURCES = $(am__append_1) DEFAULT_INCLUDES = $(addprefix -I, $(search_path)) AM_CFLAGS = $(XCFLAGS) AM_CCASFLAGS = $(XCFLAGS) @@ -419,7 +423,7 @@ noinst_LTLIBRARIES = libatomic_convenience.la libatomic_version_info = -version-info $(libtool_VERSION) libatomic_la_LDFLAGS = $(libatomic_version_info)
Re: Why is there no libatomic default implementation using gthr.h?
On 19/12/2022 13:41, Jonathan Wakely wrote: 3. Use gthr as the default implementation of libatomic. I have no objection to doing this, but I don't see why you need to touch libstdc++ to do it. Just make libatomic create its own copy of gthr.h (if a fallback gthreads-based implementation is actually needed) and compile that locally in the libatomic build dir. That shouldn't need changes to libgcc or libstdc++, should it? Yes, this would also work. I can probably duplicate the gthr configure/Makefile stuff from libstdc++ for this. -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/
Why is there no libatomic default implementation using gthr.h?
Hello, I would like to fix the -fprofile-update=atomic implementation so that it works on all targets. Currently, it works only on targets with 64-bit atomic operations in hardware (and some special cases). I tried to fix it like this: https://gcc.gnu.org/pipermail/gcc-patches/2022-December/608620.html The problem with this patch is that it falls back to use functions provided by libatomic. The libatomic is currently not supported on all targets, for example: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77466 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77378 Why is there no libatomic default implementation using gthr.h? The C++ library already depends on gthr.h and installs the headers in "bits/gthr.h" etc. For this the libstdc++-v3 configure/Makefile duplicates some logic from libgcc. Why is the gthr.h stuff not installed by libgcc itself? In libatomic, the POSIX implementation could be easily rewritten to use the gthr interface. Any objections to do the following? 1. Install gthr.h to "bits/gthr.h" by libgcc (including the other gthr headers). 2. Remove the gthr configure/Makefile support from libstdc++-v3. 3. Use gthr as the default implementation of libatomic. -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/
Re: [PATCH] gcov: Fix -fprofile-update=atomic
On 16.12.22 13:09, Richard Biener wrote:
On Fri, Dec 16, 2022 at 11:39 AM Sebastian Huber
wrote:
On 16.12.22 10:47, Richard Biener wrote:
No, if you select -fprofile-update=atomic, then the updates shall be
atomic from my point of view. If a fallback is acceptable, then you can
use -fprofile-update=prefer-atomic. Using the fallback in
-fprofile-update=atomic is a bug which prevents the use of gcov for
multi-threaded applications on the lower end targets which do not have
atomic operations in hardware.
Ah, OK. So the fallback there is libatomic calls as well then? Note
not all targets support libatomic, for those the failure mode is likely
a link error (which might be fine, but we eventually might want to
amend documentation to indicate this failure mode).
It seems these library calls caused issues in the past:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77466
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77378
Hmm, those are testsuite-isms in some way but of course
users would run into the same issue, needing explicit
-latomic (where available). I suppose target specs could
automatically add that for -fprofile-update=atomic but this
would need to be specified at link time as well then.
Why can't we provide libatomic for all targets? Is gthr.h not always
available?
One option could be to emit calls to a new libgcov function:
__gcov_inc_counter(counter) -> updated value
This function could use a __gthread_mutex_t mutex for updates. This ends
up probably with quite a bad performance.
But that's eventually what libatomic will do as well as fallback.
For libatomic, hosts can implement a protect_start() and protect_end()
function. On RTEMS, this is implemented like this:
#include
static inline UWORD
protect_start (void *ptr)
{
return _Libatomic_Protect_start (ptr);
}
static inline void
protect_end (void *ptr, UWORD isr_level)
{
_Libatomic_Protect_end (ptr, isr_level);
}
On single-core systems, this is mapped to interrupt disable/enable. This
is quite efficient (compared to a mutex).
I don't have a good idea here.
Do you have to explicitely link -latomic on RISCV?
For RTEMS, libatomic is always added to the linker command line:
gcc/config/rtems.h:"%{qrtems:--start-group -lrtemsbsp -lrtemscpu
-latomic -lc -lgcc --end-group}"
For riscv, there seems to be also a linux special case:
gcc/config/riscv/linux.h: " %{pthread:" LD_AS_NEEDED_OPTION " -latomic
" LD_NO_AS_NEEDED_OPTION "}"
gcc/config/riscv/linux.h:#define LIB_SPEC GNU_USER_TARGET_LIB_SPEC "
-latomic "
--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax: +49-89-18 94 741 - 08
Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
Re: [PATCH] gcov: Fix -fprofile-update=atomic
On 16.12.22 10:47, Richard Biener wrote: No, if you select -fprofile-update=atomic, then the updates shall be atomic from my point of view. If a fallback is acceptable, then you can use -fprofile-update=prefer-atomic. Using the fallback in -fprofile-update=atomic is a bug which prevents the use of gcov for multi-threaded applications on the lower end targets which do not have atomic operations in hardware. Ah, OK. So the fallback there is libatomic calls as well then? Note not all targets support libatomic, for those the failure mode is likely a link error (which might be fine, but we eventually might want to amend documentation to indicate this failure mode). It seems these library calls caused issues in the past: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77466 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77378 One option could be to emit calls to a new libgcov function: __gcov_inc_counter(counter) -> updated value This function could use a __gthread_mutex_t mutex for updates. This ends up probably with quite a bad performance. -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/
[PATCH v2] gcov: Fix -fprofile-update=atomic
The code coverage support uses counters to determine which edges in the control
flow graph were executed. If a counter overflows, then the code coverage
information is invalid. Therefore the counter type should be a 64-bit integer.
In multithreaded applications, it is important that the counter increments are
atomic. This is not the case by default. The user can enable atomic counter
increments through the -fprofile-update=atomic and
-fprofile-update=prefer-atomic options.
If the hardware supports 64-bit atomic operations, then everything is fine. If
not and -fprofile-update=prefer-atomic was chosen by the user, then non-atomic
counter increments will be used. However, if the hardware does not support the
required atomic operations and -fprofile-atomic=update was chosen by the user,
then a warning was issued and as a forced fallback to non-atomic operations was
done. This is probably not what a user wants. There is still hardware on the
market which does not have atomic operations and is used for multithreaded
applications. A user which selects -fprofile-update=atomic wants consistent
code coverage data and not random data.
This patch removes the fallback to non-atomic operations for
-fprofile-update=atomic. If atomic operations in hardware are not available,
then a library call to libatomic is emitted. To mitigate potential performance
issues an optimization for systems which only support 32-bit atomic operations
is provided. Here, the edge counter increments are done like this:
low = __atomic_add_fetch_4 (, 1, MEMMODEL_RELAXED);
high_inc = low == 0 ? 1 : 0;
__atomic_add_fetch_4 (, high_inc, MEMMODEL_RELAXED);
In gimple_gen_time_profiler() this split operation cannot be used, since the
updated counter value is also required. Here, a library call is emitted. This
is not a performance issue since the update is only done if counters[0] == 0.
gcc/ChangeLog:
* tree-profile.cc (split_atomic_increment): New.
(gimple_gen_edge_profiler): Split the atomic edge counter increment in
two 32-bit atomic operations if necessary.
(tree_profiling): Remove profile update warning and fallback. Set
split_atomic_increment if necessary.
* doc/invoke.texi (-fprofile-update): Clarify default method. Document
the atomic method behaviour.
---
v2:
* Check gcov_type_size for split_atomic_increment.
* Update documentation.
gcc/doc/invoke.texi | 16 -
gcc/tree-profile.cc | 81 +
2 files changed, 74 insertions(+), 23 deletions(-)
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index a50417a4ab7..6b32b659e50 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -16457,7 +16457,21 @@ while the second one prevents profile corruption by
emitting thread-safe code.
Using @samp{prefer-atomic} would be transformed either to @samp{atomic},
when supported by a target, or to @samp{single} otherwise. The GCC driver
automatically selects @samp{prefer-atomic} when @option{-pthread}
-is present in the command line.
+is present in the command line, otherwise the default method is @samp{single}.
+
+If @samp{atomic} is selected, then the profile information is updated using
+atomic operations. If the target does not support atomic operations in
+hardware, then function calls to @code{__atomic_fetch_add_4} or
+@code{__atomic_fetch_add_8} are emitted. These functions are usually provided
+by the @file{libatomic} runtime library. Not all targets provide the
+@file{libatomic} runtime library. If it is not available for the target, then
+a linker error may happen. Using function calls to update the profiling
+information may be a performance issue. For targets which use 64-bit counters
+for the profiling information and support only 32-bit atomic operations, the
+performance critical profiling updates are done using two 32-bit atomic
+operations for each counter update. If a signal interrupts these two
+operations updating a counter, then the profiling information may be in an
+inconsistent state.
@item -fprofile-filter-files=@var{regex}
@opindex fprofile-filter-files
diff --git a/gcc/tree-profile.cc b/gcc/tree-profile.cc
index 2beb49241f2..49c8caeae18 100644
--- a/gcc/tree-profile.cc
+++ b/gcc/tree-profile.cc
@@ -73,6 +73,17 @@ static GTY(()) tree ic_tuple_var;
static GTY(()) tree ic_tuple_counters_field;
static GTY(()) tree ic_tuple_callee_field;
+/* If the user selected atomic profile counter updates
+ (-fprofile-update=atomic), then the counter updates will be done atomically.
+ Ideally, this is done through atomic operations in hardware. If the
+ hardware supports only 32-bit atomic increments and gcov_type_node is a
+ 64-bit integer type, then for the profile edge counters the increment is
+ performed through two separate 32-bit atomic increments. This case is
+ indicated by the split_atomic_increment variable begin true. If the
+ hardware does not support atomic
Re: [PATCH] gcov: Fix -fprofile-update=atomic
On 13/12/2022 15:30, Richard Biener wrote:
On Fri, Dec 9, 2022 at 2:56 PM Sebastian Huber
wrote:
The code coverage support uses counters to determine which edges in the control
flow graph were executed. If a counter overflows, then the code coverage
information is invalid. Therefore the counter type should be a 64-bit integer.
In multithreaded applications, it is important that the counter increments are
atomic. This is not the case by default. The user can enable atomic counter
increments through the -fprofile-update=atomic and
-fprofile-update=prefer-atomic options.
If the hardware supports 64-bit atomic operations, then everything is fine. If
not and -fprofile-update=prefer-atomic was chosen by the user, then non-atomic
counter increments will be used. However, if the hardware does not support the
required atomic operations and -fprofile-atomic=update was chosen by the user,
then a warning was issued and as a forced fall-back to non-atomic operations
was done. This is probably not what a user wants. There is still hardware on
the market which does not have atomic operations and is used for multithreaded
applications. A user which selects -fprofile-update=atomic wants consistent
code coverage data and not random data.
This patch removes the fall-back to non-atomic operations for
-fprofile-update=atomic. If atomic operations in hardware are not available,
then a library call to libatomic is emitted. To mitigate potential performance
issues an optimization for systems which only support 32-bit atomic operations
is provided. Here, the edge counter increments are done like this:
low = __atomic_add_fetch_4 (, 1, MEMMODEL_RELAXED);
high_inc = low == 0 ? 1 : 0;
__atomic_add_fetch_4 (, high_inc, MEMMODEL_RELAXED);
You check for compare_and_swapsi and the old code checks
TYPE_PRECISION (gcov_type_node) > 32 to determine whether 8 byte or 4 byte
gcov_type is used. But you do not seem to handle the case where
neither SImode nor DImode atomic operations are available? Can we instead
do
if (gcov_type_size == 4)
can_support_atomic4
= HAVE_sync_compare_and_swapsi || HAVE_atomic_compare_and_swapsi;
else if (gcov_type_size == 8)
can_support_atomic8
= HAVE_sync_compare_and_swapdi || HAVE_atomic_compare_and_swapdi;
if (flag_profile_update == PROFILE_UPDATE_ATOMIC
&& !can_support_atomic4 && !can_support_atomic8)
{
warning (0, "target does not support atomic profile update, "
"single mode is selected");
flag_profile_update = PROFILE_UPDATE_SINGLE;
}
thus retain the diagnostic & fallback for this case?
No, if you select -fprofile-update=atomic, then the updates shall be
atomic from my point of view. If a fallback is acceptable, then you can
use -fprofile-update=prefer-atomic. Using the fallback in
-fprofile-update=atomic is a bug which prevents the use of gcov for
multi-threaded applications on the lower end targets which do not have
atomic operations in hardware.
The existing
code also suggests
there might be targets with HImode or TImode counters?
Sorry, I don't know.
In another mail you mentioned that for gen_time_profiler this doesn't
work but its
code relies on flag_profile_update as well. So do we need to split the flag
somehow, or continue using the PROFILE_UPDATE_SINGLE fallback when
we are doing more than just edge profiling?
If atomic operations are not available in hardware, then with this patch
calls to libatomic are emitted. In gen_time_profiler() this is not an
issue at all, since the atomic increment is only done if counters[0] ==
0 (if I read the code correctly).
For example for
void f(void) {}
we get on riscv:
gcc --coverage -O2 -S -o - test.c -fprofile-update=atomic
lui a4,%hi(__gcov0.f)
li a3,1
addia4,a4,%lo(__gcov0.f)
amoadd.w a5,a3,0(a4)
lui a4,%hi(__gcov0.f+4)
addia5,a5,1
seqza5,a5
addia4,a4,%lo(__gcov0.f+4)
amoadd.w zero,a5,0(a4)
ret
gcc --coverage -O2 -S -o - test.c -fprofile-update=atomic -mbig-endian
lui a4,%hi(__gcov0.f+4)
li a3,1
addia4,a4,%lo(__gcov0.f+4)
amoadd.w a5,a3,0(a4)
lui a4,%hi(__gcov0.f)
addia5,a5,1
seqza5,a5
addia4,a4,%lo(__gcov0.f)
amoadd.w zero,a5,0(a4)
ret
gcc --coverage -O2 -S -o - test.c -fprofile-update=atomic -march=rv64g
-mabi=lp64
lui a5,%hi(__gcov0.f)
li a4,1
addia5,a5,%lo(__gcov0.f)
amoadd.d zero,a4,0(a5)
ret
gcc --coverage -O2 -S -o - test.c -fprofile-update=atomic -march=rv32id
lui a0,%hi(__gcov0.f)
li a3,0
li a1,1
li a2,0
addia0,a0,%lo(__gcov0.f)
tail__atomic_fetch_add_8
gcc --coverage -O2 -S -o - test.c -fprofile-update=prefer-atomic
-ma
[PATCH] gcov: Fix -fprofile-update=atomic
The code coverage support uses counters to determine which edges in the control
flow graph were executed. If a counter overflows, then the code coverage
information is invalid. Therefore the counter type should be a 64-bit integer.
In multithreaded applications, it is important that the counter increments are
atomic. This is not the case by default. The user can enable atomic counter
increments through the -fprofile-update=atomic and
-fprofile-update=prefer-atomic options.
If the hardware supports 64-bit atomic operations, then everything is fine. If
not and -fprofile-update=prefer-atomic was chosen by the user, then non-atomic
counter increments will be used. However, if the hardware does not support the
required atomic operations and -fprofile-atomic=update was chosen by the user,
then a warning was issued and as a forced fall-back to non-atomic operations
was done. This is probably not what a user wants. There is still hardware on
the market which does not have atomic operations and is used for multithreaded
applications. A user which selects -fprofile-update=atomic wants consistent
code coverage data and not random data.
This patch removes the fall-back to non-atomic operations for
-fprofile-update=atomic. If atomic operations in hardware are not available,
then a library call to libatomic is emitted. To mitigate potential performance
issues an optimization for systems which only support 32-bit atomic operations
is provided. Here, the edge counter increments are done like this:
low = __atomic_add_fetch_4 (, 1, MEMMODEL_RELAXED);
high_inc = low == 0 ? 1 : 0;
__atomic_add_fetch_4 (, high_inc, MEMMODEL_RELAXED);
gcc/ChangeLog:
* tree-profile.cc (split_atomic_increment): New.
(gimple_gen_edge_profiler): Split the atomic edge counter increment in
two 32-bit atomic operations if necessary.
(tree_profiling): Remove profile update warning and fall-back. Set
split_atomic_increment if necessary.
---
gcc/tree-profile.cc | 81 +
1 file changed, 59 insertions(+), 22 deletions(-)
diff --git a/gcc/tree-profile.cc b/gcc/tree-profile.cc
index 2beb49241f2..1d326dde59a 100644
--- a/gcc/tree-profile.cc
+++ b/gcc/tree-profile.cc
@@ -73,6 +73,17 @@ static GTY(()) tree ic_tuple_var;
static GTY(()) tree ic_tuple_counters_field;
static GTY(()) tree ic_tuple_callee_field;
+/* If the user selected atomic profile counter updates
+ (-fprofile-update=atomic), then the counter updates will be done atomically.
+ Ideally, this is done through atomic operations in hardware. If the
+ hardware supports only 32-bit atomic increments and gcov_type_node is a
+ 64-bit integer type, then for the profile edge counters the increment is
+ performed through two separate 32-bit atomic increments. This case is
+ indicated by the split_atomic_increment variable begin true. If the
+ hardware does not support atomic operations at all, then a library call to
+ libatomic is emitted. */
+static bool split_atomic_increment;
+
/* Do initialization work for the edge profiler. */
/* Add code:
@@ -242,30 +253,59 @@ gimple_init_gcov_profiler (void)
void
gimple_gen_edge_profiler (int edgeno, edge e)
{
- tree one;
-
- one = build_int_cst (gcov_type_node, 1);
+ const char *name = "PROF_edge_counter";
+ tree ref = tree_coverage_counter_ref (GCOV_COUNTER_ARCS, edgeno);
+ tree one = build_int_cst (gcov_type_node, 1);
if (flag_profile_update == PROFILE_UPDATE_ATOMIC)
{
- /* __atomic_fetch_add (, 1, MEMMODEL_RELAXED); */
- tree addr = tree_coverage_counter_addr (GCOV_COUNTER_ARCS, edgeno);
- tree f = builtin_decl_explicit (TYPE_PRECISION (gcov_type_node) > 32
- ? BUILT_IN_ATOMIC_FETCH_ADD_8:
- BUILT_IN_ATOMIC_FETCH_ADD_4);
- gcall *stmt = gimple_build_call (f, 3, addr, one,
- build_int_cst (integer_type_node,
- MEMMODEL_RELAXED));
- gsi_insert_on_edge (e, stmt);
+ tree addr = build_fold_addr_expr (ref);
+ tree relaxed = build_int_cst (integer_type_node, MEMMODEL_RELAXED);
+ if (!split_atomic_increment)
+ {
+ /* __atomic_fetch_add (, 1, MEMMODEL_RELAXED); */
+ tree f = builtin_decl_explicit (TYPE_PRECISION (gcov_type_node) > 32
+ ? BUILT_IN_ATOMIC_FETCH_ADD_8:
+ BUILT_IN_ATOMIC_FETCH_ADD_4);
+ gcall *stmt = gimple_build_call (f, 3, addr, one, relaxed);
+ gsi_insert_on_edge (e, stmt);
+ }
+ else
+ {
+ /* low = __atomic_add_fetch_4 (addr, 1, MEMMODEL_RELAXED);
+high_inc = low == 0 ? 1 : 0;
+__atomic_add_fetch_4 (addr_high, high_inc, MEMMODEL_RELAXED); */
+ tree zero32 = build_zero_cst (uint32_type_node);
+ tree one32 = build_one_cst
Re: [PATCH v2 1/2] Allow subtarget customization of CC1_SPEC
On 07/12/2022 10:50, Richard Sandiford wrote: How about going back to Jose's suggestion from the original thread of using OS_CC1_SPEC? The patch is OK with that change if no-one objects in 24 hours. I checked in this change: https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=3e4b8dc477c12f303171ec7f0394c97494095545 -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/
Re: -fprofile-update=atomic vs. 32-bit architectures
On 04.11.22 09:27, Sebastian Huber wrote: Hello, even recent 32-bit architectures such as RISC-V do not support 64-bit atomic operations. Using -fprofile-update=atomic for the 32-bit RISC-V RV32GC ISA yields: warning: target does not support atomic profile update, single mode is selected For multi-threaded applications it is quite important to use atomic counter increments to get valid coverage data. I think this fall back is not really good. Maybe we should consider using this approach from Jakub Jelinek for 32-bit architectures lacking 64-bit atomic operations: if (__atomic_add_fetch_4 ((unsigned int *) , 1, __ATOMIC_RELAXED) == 0) __atomic_fetch_add_4 (((unsigned int *) ) + 1, 1, __ATOMIC_RELAXED); https://patchwork.ozlabs.org/project/gcc/patch/19c4a81d-6ecd-8c6e-b641-e257c1959...@suse.cz/#1447334 Last year I added the TARGET_GCOV_TYPE_SIZE target hook to optionally reduce the gcov type size to 32 bits. I am not really sure if this was a good idea. Longer running executables may observe counter overflows leading to invalid coverage data. If someone wants atomic updates, then the updates should be atomic even if this means to use a library implementation (libatomic). What about the following approach if -fprofile-update=atomic is given: 1. Use 64-bit atomics if available. 2. Use if (__atomic_add_fetch_4 ((unsigned int *) , 1, __ATOMIC_RELAXED) == 0) __atomic_fetch_add_4 (((unsigned int *) ) + 1, 1, __ATOMIC_RELAXED); if 32-bit atomics are available. This approach works fine for the edge counters in gimple_gen_edge_profiler() because we don't have to read the counter value. We just have to do an increment. In gimple_gen_time_profiler() we have to do this: /* Emit: counters[0] = ++__gcov_time_profiler_counter. */ So here we have to do an atomic increment and fetch the value. This doesn't work with the approach above. For example let thread A increment the lower part from 0xfffe to 0x, then let thread B increment the lower part from 0x to 0x0, then the higher part from 0x7 to 0x8, then let thread A read 0x8. Thread A would then get 0x8_ instead of the correct 0x7_. 3. Else use a library call (libatomic). -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/
Re: -fprofile-update=atomic vs. 32-bit architectures
On 07.12.22 10:09, Richard Biener wrote:
On Wed, Dec 7, 2022 at 9:51 AM Sebastian Huber
wrote:
On 06.12.22 17:08, Richard Biener wrote:
Likely. I'd use the gimple_build () API from gimple-fold.h which
builds the expression(s) to a gimple_seq creating necessary temporaries
on-the-fly and then insert that sequence on the edge.
Thanks, I will have a look at this.
I am struggling to convert a uint32_type_node node to a gcov_type_node
(64-bit). I tried to use this:
if (result != NULL_TREE)
{
tree tmp1 = make_temp_ssa_name (gcov_type_node, NULL, name);
gassign *stmt7 = gimple_build_assign (result, VIEW_CONVERT_EXPR,
build1 (VIEW_CONVERT_EXPR, gcov_type_node,
high));
You want
gimple_build_assign (result, NOP_EXPR, high);
here (a conversion, from unsigned it will zero-extend)
Thanks, with this NOP_EXPR it did work. I have now a proof of concept
ready. Should I wait for the GCC 14 development cycle or can I post a
patch set now?
--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax: +49-89-18 94 741 - 08
Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
Re: -fprofile-update=atomic vs. 32-bit architectures
On 06.12.22 17:08, Richard Biener wrote:
Likely. I'd use the gimple_build () API from gimple-fold.h which
builds the expression(s) to a gimple_seq creating necessary temporaries
on-the-fly and then insert that sequence on the edge.
Thanks, I will have a look at this.
I am struggling to convert a uint32_type_node node to a gcov_type_node
(64-bit). I tried to use this:
if (result != NULL_TREE)
{
tree tmp1 = make_temp_ssa_name (gcov_type_node, NULL, name);
gassign *stmt7 = gimple_build_assign (result, VIEW_CONVERT_EXPR,
build1 (VIEW_CONVERT_EXPR, gcov_type_node,
high));
tree tmp2 = make_temp_ssa_name (gcov_type_node, NULL, name);
gassign *stmt8 = gimple_build_assign (tmp2, LSHIFT_EXPR, tmp1,
build_int_cst (integer_type_node, 32));
gassign *stmt9 = gimple_build_assign (result, BIT_IOR_EXPR, tmp2,
tmp1);
gsi_insert_after (gsi, stmt7, GSI_NEW_STMT);
gsi_insert_after (gsi, stmt8, GSI_NEW_STMT);
gsi_insert_after (gsi, stmt9, GSI_NEW_STMT);
}
This ends up in:
../test.c: In function 'f':
../test.c:4:1: error: conversion of register to a different size in
'view_convert_expr'
4 | }
| ^
VIEW_CONVERT_EXPR(PROF_time_profiler_15);
PROF_time_profile_9 = VIEW_CONVERT_EXPRint>(PROF_time_profiler_15);
during IPA pass: profile
../test.c:4:1: internal compiler error: verify_gimple failed
0xdddc95 verify_gimple_in_cfg(function*, bool, bool)
/home/EB/sebastian_h/src/gcc/gcc/tree-cfg.cc:5647
0xc20221 execute_function_todo
/home/EB/sebastian_h/src/gcc/gcc/passes.cc:2091
0xc1efd6 do_per_function
/home/EB/sebastian_h/src/gcc/gcc/passes.cc:1701
0xc20416 execute_todo
/home/EB/sebastian_h/src/gcc/gcc/passes.cc:2145
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax: +49-89-18 94 741 - 08
Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
Re: [PATCH v2 1/2] Allow subtarget customization of CC1_SPEC
On 07.12.22 08:10, Thomas Schwinge wrote:
Hi!
On 2022-12-07T07:04:10+0100, Sebastian Huber
wrote:
On 06.12.22 22:06, Thomas Schwinge wrote:
I suppose I just fail to see some detail here, but:
On 2022-11-21T08:25:25+0100, Sebastian
Huber wrote:
gcc/ChangeLog:
* gcc.cc (SUBTARGET_CC1_SPEC): Define if not defined.
(cc1_spec): Append SUBTARGET_CC1_SPEC.
---
v2: Append SUBTARGET_CC1_SPEC directly to cc1_spec and not through CC1_SPEC.
This avoids having to modify all the CC1_SPEC definitions in the targets.
gcc/gcc.cc | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/gcc/gcc.cc b/gcc/gcc.cc
index 830ab88701f..4e1574a4df1 100644
--- a/gcc/gcc.cc
+++ b/gcc/gcc.cc
@@ -706,6 +706,13 @@ proper position among the other output files. */
#define CPP_SPEC ""
#endif
+/* Subtargets can define SUBTARGET_CC1_SPEC to provide extra args to cc1 and
+ cc1plus or extra switch-translations. The SUBTARGET_CC1_SPEC is appended
+ to CC1_SPEC. */
+#ifndef SUBTARGET_CC1_SPEC
+#define SUBTARGET_CC1_SPEC ""
+#endif
+
/* config.h can define CC1_SPEC to provide extra args to cc1 and cc1plus
or extra switch-translations. */
#ifndef CC1_SPEC
@@ -1174,7 +1181,7 @@ proper position among the other output files. */
static const char *asm_debug = ASM_DEBUG_SPEC;
static const char *asm_debug_option = ASM_DEBUG_OPTION_SPEC;
static const char *cpp_spec = CPP_SPEC;
-static const char *cc1_spec = CC1_SPEC;
+static const char *cc1_spec = CC1_SPEC SUBTARGET_CC1_SPEC;
static const char *cc1plus_spec = CC1PLUS_SPEC;
static const char *link_gcc_c_sequence_spec = LINK_GCC_C_SEQUENCE_SPEC;
static const char *link_ssp_spec = LINK_SSP_SPEC;
... doesn't this (at least potentially?) badly interact with any existing
'SUBTARGET_CC1_SPEC' definitions -- which pe rabove get appended to
'cc1_spec'?
gcc/config/loongarch/gnu-user.h- and provides this hook instead. */
gcc/config/loongarch/gnu-user.h:#undef SUBTARGET_CC1_SPEC
gcc/config/loongarch/gnu-user.h:#define SUBTARGET_CC1_SPEC
GNU_USER_TARGET_CC1_SPEC
gcc/config/loongarch/gnu-user.h-
--
gcc/config/loongarch/loongarch.h-#define EXTRA_SPECS \
gcc/config/loongarch/loongarch.h: {"subtarget_cc1_spec",
SUBTARGET_CC1_SPEC}, \
gcc/config/loongarch/loongarch.h- {"subtarget_cpp_spec",
SUBTARGET_CPP_SPEC}, \
--
gcc/config/mips/gnu-user.h- and provides this hook instead. */
gcc/config/mips/gnu-user.h:#undef SUBTARGET_CC1_SPEC
gcc/config/mips/gnu-user.h:#define SUBTARGET_CC1_SPEC
GNU_USER_TARGET_CC1_SPEC
gcc/config/mips/gnu-user.h-
--
gcc/config/mips/linux-common.h-
gcc/config/mips/linux-common.h:#undef SUBTARGET_CC1_SPEC
gcc/config/mips/linux-common.h:#define SUBTARGET_CC1_SPEC
\
gcc/config/mips/linux-common.h- LINUX_OR_ANDROID_CC
(GNU_USER_TARGET_CC1_SPEC, \
--
gcc/config/mips/mips.h-
gcc/config/mips/mips.h:/* SUBTARGET_CC1_SPEC is passed to the compiler
proper. It may be
gcc/config/mips/mips.h- overridden by subtargets. */
gcc/config/mips/mips.h:#ifndef SUBTARGET_CC1_SPEC
gcc/config/mips/mips.h:#define SUBTARGET_CC1_SPEC ""
gcc/config/mips/mips.h-#endif
--
gcc/config/mips/mips.h-#define EXTRA_SPECS
\
gcc/config/mips/mips.h: { "subtarget_cc1_spec", SUBTARGET_CC1_SPEC },
\
gcc/config/mips/mips.h- { "subtarget_cpp_spec", SUBTARGET_CPP_SPEC },
\
--
gcc/config/mips/r3900.h-/* By default (if not mips-something-else)
produce code for the r3900 */
gcc/config/mips/r3900.h:#undef SUBTARGET_CC1_SPEC
gcc/config/mips/r3900.h:#define SUBTARGET_CC1_SPEC "\
gcc/config/mips/r3900.h-%{mhard-float:%e-mhard-float not supported} \
Oh, I came up with the name SUBTARGET_CC1_SPEC after a discussion on the
mailing list
I've put Iain in CC.
and I have to admit that I didn't check that it was
actually already in use.
Always one of the first things I do. ;-)
What about renaming the loongarch/mips define
to LOONGARCH_CC1_SPEC and MIPS_CC1_SPEC?
Also in use are a number of other 'SUBTARGET_[...]_SPEC' and
corresponding 'subtarget_[...]_spec' in 'EXTRA_SPECS', for example:
gcc/config/mips/mips.h-#define EXTRA_SPECS
\
gcc/config/mips/mips.h: { "subtarget_cc1_spec", SUBTARGET_CC1_SPEC },
\
gcc/config/mips/mips.h: { "subtarget_cpp_spec", SUBTARGET_CPP_SPEC },
\
gcc/config/mips/mips.h: { "subtarget_asm_debugging_spec",
SUBTARGET_ASM_DEBUGGING_SPEC }, \
gcc/config/mips/mips.
Re: [PATCH v2 1/2] Allow subtarget customization of CC1_SPEC
On 06.12.22 22:06, Thomas Schwinge wrote:
Hi!
I suppose I just fail to see some detail here, but:
On 2022-11-21T08:25:25+0100, Sebastian
Huber wrote:
gcc/ChangeLog:
* gcc.cc (SUBTARGET_CC1_SPEC): Define if not defined.
(cc1_spec): Append SUBTARGET_CC1_SPEC.
---
v2: Append SUBTARGET_CC1_SPEC directly to cc1_spec and not through CC1_SPEC.
This avoids having to modify all the CC1_SPEC definitions in the targets.
gcc/gcc.cc | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/gcc/gcc.cc b/gcc/gcc.cc
index 830ab88701f..4e1574a4df1 100644
--- a/gcc/gcc.cc
+++ b/gcc/gcc.cc
@@ -706,6 +706,13 @@ proper position among the other output files. */
#define CPP_SPEC ""
#endif
+/* Subtargets can define SUBTARGET_CC1_SPEC to provide extra args to cc1 and
+ cc1plus or extra switch-translations. The SUBTARGET_CC1_SPEC is appended
+ to CC1_SPEC. */
+#ifndef SUBTARGET_CC1_SPEC
+#define SUBTARGET_CC1_SPEC ""
+#endif
+
/* config.h can define CC1_SPEC to provide extra args to cc1 and cc1plus
or extra switch-translations. */
#ifndef CC1_SPEC
@@ -1174,7 +1181,7 @@ proper position among the other output files. */
static const char *asm_debug = ASM_DEBUG_SPEC;
static const char *asm_debug_option = ASM_DEBUG_OPTION_SPEC;
static const char *cpp_spec = CPP_SPEC;
-static const char *cc1_spec = CC1_SPEC;
+static const char *cc1_spec = CC1_SPEC SUBTARGET_CC1_SPEC;
static const char *cc1plus_spec = CC1PLUS_SPEC;
static const char *link_gcc_c_sequence_spec = LINK_GCC_C_SEQUENCE_SPEC;
static const char *link_ssp_spec = LINK_SSP_SPEC;
... doesn't this (at least potentially?) badly interact with any existing
'SUBTARGET_CC1_SPEC' definitions -- which pe rabove get appended to
'cc1_spec'?
gcc/config/loongarch/gnu-user.h- and provides this hook instead. */
gcc/config/loongarch/gnu-user.h:#undef SUBTARGET_CC1_SPEC
gcc/config/loongarch/gnu-user.h:#define SUBTARGET_CC1_SPEC
GNU_USER_TARGET_CC1_SPEC
gcc/config/loongarch/gnu-user.h-
--
gcc/config/loongarch/loongarch.h-#define EXTRA_SPECS \
gcc/config/loongarch/loongarch.h: {"subtarget_cc1_spec",
SUBTARGET_CC1_SPEC}, \
gcc/config/loongarch/loongarch.h- {"subtarget_cpp_spec",
SUBTARGET_CPP_SPEC}, \
--
gcc/config/mips/gnu-user.h- and provides this hook instead. */
gcc/config/mips/gnu-user.h:#undef SUBTARGET_CC1_SPEC
gcc/config/mips/gnu-user.h:#define SUBTARGET_CC1_SPEC
GNU_USER_TARGET_CC1_SPEC
gcc/config/mips/gnu-user.h-
--
gcc/config/mips/linux-common.h-
gcc/config/mips/linux-common.h:#undef SUBTARGET_CC1_SPEC
gcc/config/mips/linux-common.h:#define SUBTARGET_CC1_SPEC
\
gcc/config/mips/linux-common.h- LINUX_OR_ANDROID_CC
(GNU_USER_TARGET_CC1_SPEC, \
--
gcc/config/mips/mips.h-
gcc/config/mips/mips.h:/* SUBTARGET_CC1_SPEC is passed to the compiler
proper. It may be
gcc/config/mips/mips.h- overridden by subtargets. */
gcc/config/mips/mips.h:#ifndef SUBTARGET_CC1_SPEC
gcc/config/mips/mips.h:#define SUBTARGET_CC1_SPEC ""
gcc/config/mips/mips.h-#endif
--
gcc/config/mips/mips.h-#define EXTRA_SPECS
\
gcc/config/mips/mips.h: { "subtarget_cc1_spec", SUBTARGET_CC1_SPEC },
\
gcc/config/mips/mips.h- { "subtarget_cpp_spec", SUBTARGET_CPP_SPEC },
\
--
gcc/config/mips/r3900.h-/* By default (if not mips-something-else) produce
code for the r3900 */
gcc/config/mips/r3900.h:#undef SUBTARGET_CC1_SPEC
gcc/config/mips/r3900.h:#define SUBTARGET_CC1_SPEC "\
gcc/config/mips/r3900.h-%{mhard-float:%e-mhard-float not supported} \
Oh, I came up with the name SUBTARGET_CC1_SPEC after a discussion on the
mailing list and I have to admit that I didn't check that it was
actually already in use. What about renaming the loongarch/mips define
to LOONGARCH_CC1_SPEC and MIPS_CC1_SPEC?
--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax: +49-89-18 94 741 - 08
Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
Re: -fprofile-update=atomic vs. 32-bit architectures
On 05/12/2022 08:44, Richard Biener wrote:
On Mon, Dec 5, 2022 at 8:26 AM Sebastian Huber
wrote:
On 08/11/2022 11:25, Richard Biener wrote:
It would be great to have a code example for the construction of the "if
(f()) f();".
I think for the function above we need to emit __atomic_fetch_add_8,
not the emulated form because we cannot insert the required control
flow (if (f()) f()) on an edge. The __atomic_fetch_add_8 should then be
lowered after the instrumentation took place.
Would it help to change the
if (__atomic_add_fetch_4 ((unsigned int *) , 1, __ATOMIC_RELAXED)
== 0)
__atomic_fetch_add_4 (((unsigned int *) ) + 1, 1,
__ATOMIC_RELAXED);
into
unsigned int v = __atomic_add_fetch_4 ((unsigned int *) , 1,
__ATOMIC_RELAXED)
== 0)
v = (unsigned int)(v == 0);
__atomic_fetch_add_4 (((unsigned int *) ) + 1, 1,
__ATOMIC_RELAXED);
that's supposed to add 'v' instead of 1? Possibly use uint32_t here
(aka uint32_type_node).
to get rid of an inserted control flow?
That for sure wouldn't require any changes to how the profile
instrumentation works,
so yes it would be simpler.
Yes, this seems to work. After a bit of trial and error I ended up with
something in gimple_gen_edge_profiler() like this (endian support is
missing):
else if (flag_profile_update == PROFILE_UPDATE_SPLIT_ATOMIC)
{
tree addr = tree_coverage_counter_addr (GCOV_COUNTER_ARCS, edgeno);
tree f = builtin_decl_explicit (BUILT_IN_ATOMIC_ADD_FETCH_4);
gcall *stmt1 = gimple_build_call (f, 3, addr, one,
build_int_cst (integer_type_node,
MEMMODEL_RELAXED));
tree low = create_tmp_var (uint32_type_node);
gimple_call_set_lhs (stmt1, low);
tree is_zero = create_tmp_var (boolean_type_node);
gassign *stmt2 = gimple_build_assign (is_zero, EQ_EXPR, low,
build_zero_cst (uint32_type_node));
tree high_inc = create_tmp_var (uint32_type_node);
gassign *stmt3 = gimple_build_assign (high_inc, COND_EXPR, is_zero,
build_one_cst (uint32_type_node),
build_zero_cst (uint32_type_node));
tree addr_high = create_tmp_var (TREE_TYPE (addr));
gassign *stmt4 = gimple_build_assign (addr_high, addr);
gassign *stmt5 = gimple_build_assign (addr_high, POINTER_PLUS_EXPR,
addr_high,
build_int_cst (size_type_node, 4));
gcall *stmt6 = gimple_build_call (f, 3, addr_high, high_inc,
build_int_cst (integer_type_node,
MEMMODEL_RELAXED));
gsi_insert_on_edge (e, stmt1);
gsi_insert_on_edge (e, stmt2);
gsi_insert_on_edge (e, stmt3);
gsi_insert_on_edge (e, stmt4);
gsi_insert_on_edge (e, stmt5);
gsi_insert_on_edge (e, stmt6);
}
It can be probably simplified. The generated code:
.type f, @function
f:
lui a4,%hi(__gcov0.f)
li a3,1
addia4,a4,%lo(__gcov0.f)
amoadd.w a5,a3,0(a4)
lui a4,%hi(__gcov0.f+4)
addia5,a5,1
seqza5,a5
addia4,a4,%lo(__gcov0.f+4)
amoadd.w zero,a5,0(a4)
li a0,3
ret
looks good for this code:
int f(void)
{
return 3;
}
The loading of the high address could be probably optimized from
lui a4,%hi(__gcov0.f+4)
addia4,a4,%lo(__gcov0.f+4)
to
addia4,a4,4
I wasn't able to figure out how to do this.
--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax: +49-89-18 94 741 - 08
Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
Re: -fprofile-update=atomic vs. 32-bit architectures
On 08/11/2022 11:25, Richard Biener wrote: It would be great to have a code example for the construction of the "if (f()) f();". I think for the function above we need to emit __atomic_fetch_add_8, not the emulated form because we cannot insert the required control flow (if (f()) f()) on an edge. The __atomic_fetch_add_8 should then be lowered after the instrumentation took place. Would it help to change the if (__atomic_add_fetch_4 ((unsigned int *) , 1, __ATOMIC_RELAXED) == 0) __atomic_fetch_add_4 (((unsigned int *) ) + 1, 1, __ATOMIC_RELAXED); into unsigned int v = __atomic_add_fetch_4 ((unsigned int *) , 1, __ATOMIC_RELAXED) == 0) v = (unsigned int)(v == 0); __atomic_fetch_add_4 (((unsigned int *) ) + 1, 1, __ATOMIC_RELAXED); to get rid of an inserted control flow? On riscv this is optimized to: li a4,1 amoadd.w a5,a4,0(a0) addia5,a5,1 seqza5,a5 addia4,a0,4 amoadd.w zero,a5,0(a4) -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/
Re: [PATCH 1/2] Allow subtarget customization of CC1_SPEC
On 20/11/2022 17:57, Jeff Law wrote: On 10/26/22 03:34, Sebastian Huber wrote: On 04/10/2022 11:47, Sebastian Huber wrote: On 08/09/2022 07:33, Sebastian Huber wrote: On 04/08/2022 15:02, Sebastian Huber wrote: On 22/07/2022 15:02, Sebastian Huber wrote: gcc/ChangeLog: * gcc.cc (SUBTARGET_CC1_SPEC): Define if not defined. (CC1_SPEC): Define to SUBTARGET_CC1_SPEC. * config/arm/arm.h (CC1_SPEC): Remove. * config/arc/arc.h (CC1_SPEC): Append SUBTARGET_CC1_SPEC. * config/cris/cris.h (CC1_SPEC): Likewise. * config/frv/frv.h (CC1_SPEC): Likewise. * config/i386/i386.h (CC1_SPEC): Likewise. * config/ia64/ia64.h (CC1_SPEC): Likewise. * config/lm32/lm32.h (CC1_SPEC): Likewise. * config/m32r/m32r.h (CC1_SPEC): Likewise. * config/mcore/mcore.h (CC1_SPEC): Likewise. * config/microblaze/microblaze.h: Likewise. * config/nds32/nds32.h (CC1_SPEC): Likewise. * config/nios2/nios2.h (CC1_SPEC): Likewise. * config/pa/pa.h (CC1_SPEC): Likewise. * config/rs6000/sysv4.h (CC1_SPEC): Likewise. * config/rx/rx.h (CC1_SPEC): Likewise. * config/sparc/sparc.h (CC1_SPEC): Likewise. Could someone please have a look at this patch set? Ping Would someone mind having a look at this patch set? If there is a better approach to customize the default TLS model, then please let me know. It would be nice if someone could review the patch before the Stage 1 ends at November 13th. Just a reminder. The guidelines are a patch needs to be posted before the end of stage1 to make the deadline. Review & integration can happen after the deadline. I realize the idea here is to allow RTEMS to change the default TLS model. But does it also happen to make it possible to solve Keith Packard's issues with picolibc? See the Aug/Sep gcc-patches archives. It looks sensible. I assume you did a "find" to identify all the CC1_SPECs to change. OK for the trunk, Thanks for having a look at the patch. After looking at the patch again, I think it can be simplified to: https://gcc.gnu.org/pipermail/gcc-patches/2022-November/606841.html Jeff Anyway, does this also solve some of the issue Keith Packard was try to nail down for picolibc? I had a look at this, however, I think this is a slightly different problem since LIB_SPEC needs to be replaced and not extended. -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/
[PATCH v2 2/2] RTEMS: Use local-exec TLS model by default
gcc/ChangeLog:
* config/rtems.h (SUBTARGET_CC1_SPEC): Undef and define.
---
gcc/config/rtems.h | 4
1 file changed, 4 insertions(+)
diff --git a/gcc/config/rtems.h b/gcc/config/rtems.h
index 95bcdc41b2f..4742b1f3722 100644
--- a/gcc/config/rtems.h
+++ b/gcc/config/rtems.h
@@ -56,3 +56,7 @@
/* Prefer int for int32_t (see stdint-newlib.h). */
#undef STDINT_LONG32
#define STDINT_LONG32 (INT_TYPE_SIZE != 32 && LONG_TYPE_SIZE == 32)
+
+/* Default to local-exec TLS model. */
+#undef SUBTARGET_CC1_SPEC
+#define SUBTARGET_CC1_SPEC " %{!ftls-model=*:-ftls-model=local-exec}"
--
2.35.3
[PATCH v2 1/2] Allow subtarget customization of CC1_SPEC
gcc/ChangeLog: * gcc.cc (SUBTARGET_CC1_SPEC): Define if not defined. (cc1_spec): Append SUBTARGET_CC1_SPEC. --- v2: Append SUBTARGET_CC1_SPEC directly to cc1_spec and not through CC1_SPEC. This avoids having to modify all the CC1_SPEC definitions in the targets. gcc/gcc.cc | 9 - 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/gcc/gcc.cc b/gcc/gcc.cc index 830ab88701f..4e1574a4df1 100644 --- a/gcc/gcc.cc +++ b/gcc/gcc.cc @@ -706,6 +706,13 @@ proper position among the other output files. */ #define CPP_SPEC "" #endif +/* Subtargets can define SUBTARGET_CC1_SPEC to provide extra args to cc1 and + cc1plus or extra switch-translations. The SUBTARGET_CC1_SPEC is appended + to CC1_SPEC. */ +#ifndef SUBTARGET_CC1_SPEC +#define SUBTARGET_CC1_SPEC "" +#endif + /* config.h can define CC1_SPEC to provide extra args to cc1 and cc1plus or extra switch-translations. */ #ifndef CC1_SPEC @@ -1174,7 +1181,7 @@ proper position among the other output files. */ static const char *asm_debug = ASM_DEBUG_SPEC; static const char *asm_debug_option = ASM_DEBUG_OPTION_SPEC; static const char *cpp_spec = CPP_SPEC; -static const char *cc1_spec = CC1_SPEC; +static const char *cc1_spec = CC1_SPEC SUBTARGET_CC1_SPEC; static const char *cc1plus_spec = CC1PLUS_SPEC; static const char *link_gcc_c_sequence_spec = LINK_GCC_C_SEQUENCE_SPEC; static const char *link_ssp_spec = LINK_SSP_SPEC; -- 2.35.3
Re: [PATCH 3/3] Add '--oslib=' option when default C library is picolibc
On 03/09/2022 08:07, Keith Packard via Gcc-patches wrote:
diff --git a/gcc/config/arm/elf.h b/gcc/config/arm/elf.h
index 3d111433ede..dc5b9374814 100644
--- a/gcc/config/arm/elf.h
+++ b/gcc/config/arm/elf.h
@@ -150,3 +150,8 @@
#undef L_floatundisf
#endif
+#if DEFAULT_LIBC == LIBC_PICOLIBC
+#undef LIB_SPEC
+#define LIB_SPEC "--start-group %(libgcc) -lc %{-oslib=*:-l%*} --end-group"
+#endif
+
Can't you add a gcc/config/picolibc.h (similar to gcc/config/rtems.h)
which is placed in gcc/config.gcc with something like this:
picolibc)
default_libc=LIBC_PICOLIBC
tm_file="${tm_file} picolibc.h"
;;
In this header place:
#undef LIB_SPEC
#define LIB_SPEC "--start-group %(libgcc) -lc %{-oslib=*:-l%*} --end-group"
#endif
This avoids having to modify all the ELF-specific files.
--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax: +49-89-18 94 741 - 08
Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
Re: -fprofile-update=atomic vs. 32-bit architectures
On 08.11.22 11:25, Richard Biener wrote: How do I get ((unsigned int *) ) + 1 from tree addr? It would be great to have a code example for the construction of the "if (f()) f();". I think for the function above we need to emit __atomic_fetch_add_8, not the emulated form because we cannot insert the required control flow (if (f()) f()) on an edge. The __atomic_fetch_add_8 should then be lowered after the instrumentation took place. Ok, I am not a compiler expert, so I have just a vague feeling how this works. I am not sure which piece is responsible for the "lowering" of this particular __atomic_fetch_add_8. I guess we don't want to split all __atomic_fetch_add_8 into this if (f()) f(); form? There's currently no helper to create a diamond so the canonical way is to create a GIMPLE_COND, split the block after this stmt, split the outgoing edge and then redirect edges to form a half-diamond. move_sese_in_condition has most of that CFG manipulation (but it performs sth different) Thanks, I will probably able to do this with a bit trial and error. -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/
Re: -fprofile-update=atomic vs. 32-bit architectures
On 05.11.22 12:18, Richard Biener wrote:
On Fri, Nov 4, 2022 at 9:28 AM Sebastian Huber
wrote:
Hello,
even recent 32-bit architectures such as RISC-V do not support 64-bit
atomic operations. Using -fprofile-update=atomic for the 32-bit RISC-V
RV32GC ISA yields:
warning: target does not support atomic profile update, single mode is
selected
For multi-threaded applications it is quite important to use atomic
counter increments to get valid coverage data. I think this fall back is
not really good. Maybe we should consider using this approach from Jakub
Jelinek for 32-bit architectures lacking 64-bit atomic operations:
if (__atomic_add_fetch_4 ((unsigned int *) , 1, __ATOMIC_RELAXED)
== 0)
__atomic_fetch_add_4 (((unsigned int *) ) + 1, 1,
__ATOMIC_RELAXED);
https://patchwork.ozlabs.org/project/gcc/patch/19c4a81d-6ecd-8c6e-b641-e257c1959...@suse.cz/#1447334
Last year I added the TARGET_GCOV_TYPE_SIZE target hook to optionally
reduce the gcov type size to 32 bits. I am not really sure if this was a
good idea. Longer running executables may observe counter overflows
leading to invalid coverage data. If someone wants atomic updates, then
the updates should be atomic even if this means to use a library
implementation (libatomic).
What about the following approach if -fprofile-update=atomic is given:
1. Use 64-bit atomics if available.
2. Use
if (__atomic_add_fetch_4 ((unsigned int *) , 1, __ATOMIC_RELAXED)
== 0)
__atomic_fetch_add_4 (((unsigned int *) ) + 1, 1,
__ATOMIC_RELAXED);
if 32-bit atomics are available.
3. Else use a library call (libatomic).
sounds good, though a library call would really be prohibitly expensive?
I someone wants to profile a multi-threaded application and selects
-fprofile-update=atomic, then probably a correct result is preferred.
You still have the option to select -fprofile-update=prefer-atomic.
For 2. I have to modify:
void
gimple_gen_edge_profiler (int edgeno, edge e)
{
tree one;
one = build_int_cst (gcov_type_node, 1);
if (flag_profile_update == PROFILE_UPDATE_ATOMIC)
{
/* __atomic_fetch_add (, 1, MEMMODEL_RELAXED); */
tree addr = tree_coverage_counter_addr (GCOV_COUNTER_ARCS, edgeno);
tree f = builtin_decl_explicit (TYPE_PRECISION (gcov_type_node) > 32
? BUILT_IN_ATOMIC_FETCH_ADD_8:
BUILT_IN_ATOMIC_FETCH_ADD_4);
gcall *stmt = gimple_build_call (f, 3, addr, one,
build_int_cst (integer_type_node,
MEMMODEL_RELAXED));
gsi_insert_on_edge (e, stmt);
}
Is
if (WORDS_BIG_ENDIAN)
the right way to check for big/little endian?
How do I get ((unsigned int *) ) + 1 from tree addr?
It would be great to have a code example for the construction of the "if
(f()) f();".
--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax: +49-89-18 94 741 - 08
Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
Re: -fprofile-update=atomic vs. 32-bit architectures
On 04/11/2022 10:53, Gabriel Paubert wrote: 2. Use if (__atomic_add_fetch_4 ((unsigned int *) , 1, __ATOMIC_RELAXED) == 0) __atomic_fetch_add_4 (((unsigned int *) ) + 1, 1, __ATOMIC_RELAXED); if 32-bit atomics are available. This assumes little-endian byte order. Yes, but this approach would also work on big-endian architectures. You just have to use other addresses. I guess the compiler knows for which endianess it generates code. -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/
-fprofile-update=atomic vs. 32-bit architectures
Hello, even recent 32-bit architectures such as RISC-V do not support 64-bit atomic operations. Using -fprofile-update=atomic for the 32-bit RISC-V RV32GC ISA yields: warning: target does not support atomic profile update, single mode is selected For multi-threaded applications it is quite important to use atomic counter increments to get valid coverage data. I think this fall back is not really good. Maybe we should consider using this approach from Jakub Jelinek for 32-bit architectures lacking 64-bit atomic operations: if (__atomic_add_fetch_4 ((unsigned int *) , 1, __ATOMIC_RELAXED) == 0) __atomic_fetch_add_4 (((unsigned int *) ) + 1, 1, __ATOMIC_RELAXED); https://patchwork.ozlabs.org/project/gcc/patch/19c4a81d-6ecd-8c6e-b641-e257c1959...@suse.cz/#1447334 Last year I added the TARGET_GCOV_TYPE_SIZE target hook to optionally reduce the gcov type size to 32 bits. I am not really sure if this was a good idea. Longer running executables may observe counter overflows leading to invalid coverage data. If someone wants atomic updates, then the updates should be atomic even if this means to use a library implementation (libatomic). What about the following approach if -fprofile-update=atomic is given: 1. Use 64-bit atomics if available. 2. Use if (__atomic_add_fetch_4 ((unsigned int *) , 1, __ATOMIC_RELAXED) == 0) __atomic_fetch_add_4 (((unsigned int *) ) + 1, 1, __ATOMIC_RELAXED); if 32-bit atomics are available. 3. Else use a library call (libatomic). -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/
Re: [PATCH] riscv/RTEMS: Add RISCV_GCOV_TYPE_SIZE
On 28/10/2022 01:05, Palmer Dabbelt wrote:
On Thu, 27 Oct 2022 15:56:17 PDT (-0700), gcc-patches@gcc.gnu.org wrote:
On 10/26/22 01:49, Sebastian Huber wrote:
The RV32A extension does not support 64-bit atomic operations. For
RTEMS, use
a 32-bit gcov type for RV32.
gcc/ChangeLog:
* config/riscv/riscv.cc (riscv_gcov_type_size): New.
(TARGET_GCOV_TYPE_SIZE): Likewise.
* config/riscv/rtems.h (RISCV_GCOV_TYPE_SIZE): New.
Why make this specific to rtems? ISTM the logic behind this change
would apply independently of the os.
Reducing the gcov type to 32-bit has the drawback that the program
runtime is reduced. I am not sure if this is generally acceptable.
Looks like rv32gc is just broken here:
$ cat test.s
int func(int x) { return x + 1; }
$ gcc -march=rv32gc -O3 -fprofile-update=atomic -fprofile-arcs test.c -S
-o-
func(int):
lui a4,%hi(__gcov0.func(int))
lw a5,%lo(__gcov0.func(int))(a4)
lw a2,%lo(__gcov0.func(int)+4)(a4)
addi a0,a0,1
addi a3,a5,1
sltu a5,a3,a5
add a5,a5,a2
sw a3,%lo(__gcov0.func(int))(a4)
sw a5,%lo(__gcov0.func(int)+4)(a4)
ret
_sub_I_00100_0:
lui a0,%hi(.LANCHOR0)
addi a0,a0,%lo(.LANCHOR0)
tail __gcov_init
_sub_D_00100_1:
tail __gcov_exit
__gcov0.func(int):
.zero 8
Those are not atomic...
Well, you get at least a warning:
test.c:1:1: warning: target does not support atomic profile update,
single mode is selected
With the patch you get:
riscv-rtems6-gcc -march=rv32gc -O3 -fprofile-update=atomic
-fprofile-arcs test.c -S -o-
func:
lui a5,%hi(__gcov0.func)
li a4,1
addia5,a5,%lo(__gcov0.func)
amoadd.w zero,a4,0(a5)
addia0,a0,1
ret
.size func, .-func
The Armv7-A doesn't have an issue with 64-bit atomics:
arm-rtems6-gcc -march=armv7-a -O3 -fprofile-update=atomic -fprofile-arcs
test.c -S -o-
func:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
movwr3, #:lower16:.LANCHOR0
movtr3, #:upper16:.LANCHOR0
push{r4, r5, r6, r7}
mov r4, #1
mov r5, #0
.L2:
ldrexd r6, r7, [r3]
addsr6, r6, r4
adc r7, r7, r5
strexd r1, r6, r7, [r3]
cmp r1, #0
bne .L2
add r0, r0, #1
pop {r4, r5, r6, r7}
bx lr
Maybe RV32 should also support LL/SC instructions with two 32-bit registers.
Another option would be to split the atomic increment into two parts as
suggested by Jakub Jelinek:
https://patchwork.ozlabs.org/project/gcc/patch/19c4a81d-6ecd-8c6e-b641-e257c1959...@suse.cz/#1447334
Another option would be to use library calls if hardware atomics are not
available.
--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax: +49-89-18 94 741 - 08
Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
Re: [PATCH 1/2] Allow subtarget customization of CC1_SPEC
On 04/10/2022 11:47, Sebastian Huber wrote: On 08/09/2022 07:33, Sebastian Huber wrote: On 04/08/2022 15:02, Sebastian Huber wrote: On 22/07/2022 15:02, Sebastian Huber wrote: gcc/ChangeLog: * gcc.cc (SUBTARGET_CC1_SPEC): Define if not defined. (CC1_SPEC): Define to SUBTARGET_CC1_SPEC. * config/arm/arm.h (CC1_SPEC): Remove. * config/arc/arc.h (CC1_SPEC): Append SUBTARGET_CC1_SPEC. * config/cris/cris.h (CC1_SPEC): Likewise. * config/frv/frv.h (CC1_SPEC): Likewise. * config/i386/i386.h (CC1_SPEC): Likewise. * config/ia64/ia64.h (CC1_SPEC): Likewise. * config/lm32/lm32.h (CC1_SPEC): Likewise. * config/m32r/m32r.h (CC1_SPEC): Likewise. * config/mcore/mcore.h (CC1_SPEC): Likewise. * config/microblaze/microblaze.h: Likewise. * config/nds32/nds32.h (CC1_SPEC): Likewise. * config/nios2/nios2.h (CC1_SPEC): Likewise. * config/pa/pa.h (CC1_SPEC): Likewise. * config/rs6000/sysv4.h (CC1_SPEC): Likewise. * config/rx/rx.h (CC1_SPEC): Likewise. * config/sparc/sparc.h (CC1_SPEC): Likewise. Could someone please have a look at this patch set? Ping. Would someone mind having a look at this patch set? If there is a better approach to customize the default TLS model, then please let me know. It would be nice if someone could review the patch before the Stage 1 ends at November 13th. -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/
[PATCH] riscv/RTEMS: Add RISCV_GCOV_TYPE_SIZE
The RV32A extension does not support 64-bit atomic operations. For RTEMS, use
a 32-bit gcov type for RV32.
gcc/ChangeLog:
* config/riscv/riscv.cc (riscv_gcov_type_size): New.
(TARGET_GCOV_TYPE_SIZE): Likewise.
* config/riscv/rtems.h (RISCV_GCOV_TYPE_SIZE): New.
---
gcc/config/riscv/riscv.cc | 11 +++
gcc/config/riscv/rtems.h | 2 ++
2 files changed, 13 insertions(+)
diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc
index 4e18a43539a..1b7f4fb1981 100644
--- a/gcc/config/riscv/riscv.cc
+++ b/gcc/config/riscv/riscv.cc
@@ -6637,6 +6637,17 @@ riscv_vector_alignment (const_tree type)
#undef TARGET_VECTOR_ALIGNMENT
#define TARGET_VECTOR_ALIGNMENT riscv_vector_alignment
+#ifdef RISCV_GCOV_TYPE_SIZE
+static HOST_WIDE_INT
+riscv_gcov_type_size (void)
+{
+ return RISCV_GCOV_TYPE_SIZE;
+}
+
+#undef TARGET_GCOV_TYPE_SIZE
+#define TARGET_GCOV_TYPE_SIZE riscv_gcov_type_size
+#endif
+
struct gcc_target targetm = TARGET_INITIALIZER;
#include "gt-riscv.h"
diff --git a/gcc/config/riscv/rtems.h b/gcc/config/riscv/rtems.h
index 14e5e59caaa..3982b24382f 100644
--- a/gcc/config/riscv/rtems.h
+++ b/gcc/config/riscv/rtems.h
@@ -29,3 +29,5 @@
builtin_define ("__USE_INIT_FINI__"); \
builtin_assert ("system=rtems");\
} while (0)
+
+#define RISCV_GCOV_TYPE_SIZE (TARGET_64BIT ? 64 : 32)
--
2.35.3
Re: [PATCH 1/2] Allow subtarget customization of CC1_SPEC
On 08/09/2022 07:33, Sebastian Huber wrote: On 04/08/2022 15:02, Sebastian Huber wrote: On 22/07/2022 15:02, Sebastian Huber wrote: gcc/ChangeLog: * gcc.cc (SUBTARGET_CC1_SPEC): Define if not defined. (CC1_SPEC): Define to SUBTARGET_CC1_SPEC. * config/arm/arm.h (CC1_SPEC): Remove. * config/arc/arc.h (CC1_SPEC): Append SUBTARGET_CC1_SPEC. * config/cris/cris.h (CC1_SPEC): Likewise. * config/frv/frv.h (CC1_SPEC): Likewise. * config/i386/i386.h (CC1_SPEC): Likewise. * config/ia64/ia64.h (CC1_SPEC): Likewise. * config/lm32/lm32.h (CC1_SPEC): Likewise. * config/m32r/m32r.h (CC1_SPEC): Likewise. * config/mcore/mcore.h (CC1_SPEC): Likewise. * config/microblaze/microblaze.h: Likewise. * config/nds32/nds32.h (CC1_SPEC): Likewise. * config/nios2/nios2.h (CC1_SPEC): Likewise. * config/pa/pa.h (CC1_SPEC): Likewise. * config/rs6000/sysv4.h (CC1_SPEC): Likewise. * config/rx/rx.h (CC1_SPEC): Likewise. * config/sparc/sparc.h (CC1_SPEC): Likewise. Could someone please have a look at this patch set? Ping. Would someone mind having a look at this patch set? If there is a better approach to customize the default TLS model, then please let me know. -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/
Re: [PATCH 1/2] Allow subtarget customization of CC1_SPEC
On 04/08/2022 15:02, Sebastian Huber wrote: On 22/07/2022 15:02, Sebastian Huber wrote: gcc/ChangeLog: * gcc.cc (SUBTARGET_CC1_SPEC): Define if not defined. (CC1_SPEC): Define to SUBTARGET_CC1_SPEC. * config/arm/arm.h (CC1_SPEC): Remove. * config/arc/arc.h (CC1_SPEC): Append SUBTARGET_CC1_SPEC. * config/cris/cris.h (CC1_SPEC): Likewise. * config/frv/frv.h (CC1_SPEC): Likewise. * config/i386/i386.h (CC1_SPEC): Likewise. * config/ia64/ia64.h (CC1_SPEC): Likewise. * config/lm32/lm32.h (CC1_SPEC): Likewise. * config/m32r/m32r.h (CC1_SPEC): Likewise. * config/mcore/mcore.h (CC1_SPEC): Likewise. * config/microblaze/microblaze.h: Likewise. * config/nds32/nds32.h (CC1_SPEC): Likewise. * config/nios2/nios2.h (CC1_SPEC): Likewise. * config/pa/pa.h (CC1_SPEC): Likewise. * config/rs6000/sysv4.h (CC1_SPEC): Likewise. * config/rx/rx.h (CC1_SPEC): Likewise. * config/sparc/sparc.h (CC1_SPEC): Likewise. Could someone please have a look at this patch set? Ping. -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/
[PATCH/gcc] RTEMS: Add -mvrsave multilibs
gcc/ChangeLog:
* config/rs6000/rtems.h (CPP_OS_DEFAULT_SPEC): Define __PPC_VRSAVE__ if
-mvrsave is present.
* config/rs6000/t-rtems: Add -mvrsave multilib variants for
-mcpu=e6500.
---
gcc/config/rs6000/rtems.h | 3 ++-
gcc/config/rs6000/t-rtems | 5 +
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/gcc/config/rs6000/rtems.h b/gcc/config/rs6000/rtems.h
index 7ea9ebdb77b..683004eb07c 100644
--- a/gcc/config/rs6000/rtems.h
+++ b/gcc/config/rs6000/rtems.h
@@ -252,7 +252,8 @@
%{mcpu=821: %{!Dppc*: %{!Dmpc*: -Dmpc821} } } \
%{mcpu=860: %{!Dppc*: %{!Dmpc*: -Dmpc860} } } \
%{mcpu=8540: %{!Dppc*: %{!Dmpc*: -Dppc8540} } } \
-%{mcpu=e6500: -D__PPC_CPU_E6500__}"
+%{mcpu=e6500: -D__PPC_CPU_E6500__} \
+%{mvrsave: -D__PPC_VRSAVE__}"
#undef ASM_DEFAULT_SPEC
#defineASM_DEFAULT_SPEC "-mppc%{m64:64}"
diff --git a/gcc/config/rs6000/t-rtems b/gcc/config/rs6000/t-rtems
index 66c20aadea5..278ebb69e60 100644
--- a/gcc/config/rs6000/t-rtems
+++ b/gcc/config/rs6000/t-rtems
@@ -36,6 +36,9 @@ MULTILIB_DIRNAMES += nof gprsdouble
MULTILIB_OPTIONS += mno-spe/mno-altivec
MULTILIB_DIRNAMES += nospe noaltivec
+MULTILIB_OPTIONS += mvrsave
+MULTILIB_DIRNAMES += vrsave
+
MULTILIB_MATCHES += ${MULTILIB_MATCHES_ENDIAN}
MULTILIB_MATCHES += ${MULTILIB_MATCHES_SYSV}
# Map 405 to 403
@@ -76,5 +79,7 @@ MULTILIB_REQUIRED += mcpu=8540/msoft-float/mno-spe
MULTILIB_REQUIRED += mcpu=8540/mfloat-gprs=double
MULTILIB_REQUIRED += mcpu=860
MULTILIB_REQUIRED += mcpu=e6500/m32
+MULTILIB_REQUIRED += mcpu=e6500/m32/mvrsave
MULTILIB_REQUIRED += mcpu=e6500/m32/msoft-float/mno-altivec
MULTILIB_REQUIRED += mcpu=e6500/m64
+MULTILIB_REQUIRED += mcpu=e6500/m64/mvrsave
--
2.26.2
Re: [PATCH 1/2] Allow subtarget customization of CC1_SPEC
On 22/07/2022 15:02, Sebastian Huber wrote: gcc/ChangeLog: * gcc.cc (SUBTARGET_CC1_SPEC): Define if not defined. (CC1_SPEC): Define to SUBTARGET_CC1_SPEC. * config/arm/arm.h (CC1_SPEC): Remove. * config/arc/arc.h (CC1_SPEC): Append SUBTARGET_CC1_SPEC. * config/cris/cris.h (CC1_SPEC): Likewise. * config/frv/frv.h (CC1_SPEC): Likewise. * config/i386/i386.h (CC1_SPEC): Likewise. * config/ia64/ia64.h (CC1_SPEC): Likewise. * config/lm32/lm32.h (CC1_SPEC): Likewise. * config/m32r/m32r.h (CC1_SPEC): Likewise. * config/mcore/mcore.h (CC1_SPEC): Likewise. * config/microblaze/microblaze.h: Likewise. * config/nds32/nds32.h (CC1_SPEC): Likewise. * config/nios2/nios2.h (CC1_SPEC): Likewise. * config/pa/pa.h (CC1_SPEC): Likewise. * config/rs6000/sysv4.h (CC1_SPEC): Likewise. * config/rx/rx.h (CC1_SPEC): Likewise. * config/sparc/sparc.h (CC1_SPEC): Likewise. Could someone please have a look at this patch set? -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/
Re: [PATCH] Add condition coverage profiling
On 02/08/2022 09:58, Jørgen Kvalsvik wrote: Based on this established terminology I can think of a few good candidates: condition outcomes covered n/m outcomes covered n/m What do you think? Both are fine, but I would prefer "condition outcomes covered n/m". -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/
Re: [PATCH 1/2] Allow subtarget customization of CC1_SPEC
Hallo Jose, On 22/07/2022 16:02, Jose E. Marchesi wrote: I find "subtarget" confusing in this context. If it is about rtems.h, linux.h or sol2.h, wouldn't this be better called OS_CC1_SPEC or similar? These files specify configurations that apply to a set of targets, not to a subset of a target... Iain Sandoe told me that for the GCC implementation the OSs are sub-targets of the architecture: https://gcc.gnu.org/pipermail/gcc/2022-July/239158.html -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/
[PATCH 1/2] Allow subtarget customization of CC1_SPEC
gcc/ChangeLog:
* gcc.cc (SUBTARGET_CC1_SPEC): Define if not defined.
(CC1_SPEC): Define to SUBTARGET_CC1_SPEC.
* config/arm/arm.h (CC1_SPEC): Remove.
* config/arc/arc.h (CC1_SPEC): Append SUBTARGET_CC1_SPEC.
* config/cris/cris.h (CC1_SPEC): Likewise.
* config/frv/frv.h (CC1_SPEC): Likewise.
* config/i386/i386.h (CC1_SPEC): Likewise.
* config/ia64/ia64.h (CC1_SPEC): Likewise.
* config/lm32/lm32.h (CC1_SPEC): Likewise.
* config/m32r/m32r.h (CC1_SPEC): Likewise.
* config/mcore/mcore.h (CC1_SPEC): Likewise.
* config/microblaze/microblaze.h: Likewise.
* config/nds32/nds32.h (CC1_SPEC): Likewise.
* config/nios2/nios2.h (CC1_SPEC): Likewise.
* config/pa/pa.h (CC1_SPEC): Likewise.
* config/rs6000/sysv4.h (CC1_SPEC): Likewise.
* config/rx/rx.h (CC1_SPEC): Likewise.
* config/sparc/sparc.h (CC1_SPEC): Likewise.
---
gcc/config/arc/arc.h | 3 ++-
gcc/config/arm/arm.h | 4
gcc/config/cris/cris.h | 3 ++-
gcc/config/frv/frv.h | 2 +-
gcc/config/i386/i386.h | 2 +-
gcc/config/ia64/ia64.h | 2 +-
gcc/config/lm32/lm32.h | 2 +-
gcc/config/m32r/m32r.h | 2 +-
gcc/config/mcore/mcore.h | 2 +-
gcc/config/microblaze/microblaze.h | 3 ++-
gcc/config/nds32/nds32.h | 2 +-
gcc/config/nios2/nios2.h | 2 +-
gcc/config/pa/pa.h | 2 +-
gcc/config/rs6000/sysv4.h | 3 ++-
gcc/config/rx/rx.h | 3 ++-
gcc/config/sparc/sparc.h | 2 +-
gcc/gcc.cc | 8 +++-
17 files changed, 27 insertions(+), 20 deletions(-)
diff --git a/gcc/config/arc/arc.h b/gcc/config/arc/arc.h
index 539a1662084..177287b11aa 100644
--- a/gcc/config/arc/arc.h
+++ b/gcc/config/arc/arc.h
@@ -68,7 +68,8 @@ along with GCC; see the file COPYING3. If not see
#define CC1_SPEC "%{EB:%{EL:%emay not use both -EB and -EL}} \
%{EB:-mbig-endian} %{EL:-mlittle-endian} \
%{G*} \
-"
+" \
+SUBTARGET_CC1_SPEC
extern const char *arc_cpu_to_as (int argc, const char **argv);
#define EXTRA_SPEC_FUNCTIONS \
diff --git a/gcc/config/arm/arm.h b/gcc/config/arm/arm.h
index f479540812a..24fdf7fde23 100644
--- a/gcc/config/arm/arm.h
+++ b/gcc/config/arm/arm.h
@@ -91,10 +91,6 @@ extern tree arm_bf16_ptr_type_node;
#undef CPP_SPEC
#define CPP_SPEC "%(subtarget_cpp_spec)"
-#ifndef CC1_SPEC
-#define CC1_SPEC ""
-#endif
-
/* This macro defines names of additional specifications to put in the specs
that can be used in various specifications like CC1_SPEC. Its definition
is an initializer with a subgrouping for each command option.
diff --git a/gcc/config/cris/cris.h b/gcc/config/cris/cris.h
index 6edfe13d92c..ed89b3fa6b0 100644
--- a/gcc/config/cris/cris.h
+++ b/gcc/config/cris/cris.h
@@ -135,7 +135,8 @@ extern int cris_cpu_version;
%{metrax100:-march=v8}\
%{march=*:-march=%*}\
%{mcpu=*:-mcpu=%*}\
- %(cc1_subtarget)"
+ %(cc1_subtarget)" \
+ SUBTARGET_CC1_SPEC
/* For the cris-*-elf subtarget. */
#define CRIS_CC1_SUBTARGET_SPEC \
diff --git a/gcc/config/frv/frv.h b/gcc/config/frv/frv.h
index 8cd67f75b09..b0f39ee238e 100644
--- a/gcc/config/frv/frv.h
+++ b/gcc/config/frv/frv.h
@@ -115,7 +115,7 @@
Do not define this macro if it does not need to do anything. */
/* For ABI compliance, we need to put bss data into the normal data section.
*/
-#define CC1_SPEC "%{G*}"
+#define CC1_SPEC "%{G*}" SUBTARGET_CC1_SPEC
#undef LINK_SPEC
#define LINK_SPEC "\
diff --git a/gcc/config/i386/i386.h b/gcc/config/i386/i386.h
index f16df633e84..f1ceb6b2557 100644
--- a/gcc/config/i386/i386.h
+++ b/gcc/config/i386/i386.h
@@ -614,7 +614,7 @@ extern const char *host_detect_local_cpu (int argc, const
char **argv);
#define TARGET_D_HAS_STDCALL_CONVENTION ix86_d_has_stdcall_convention
#ifndef CC1_SPEC
-#define CC1_SPEC "%(cc1_cpu) "
+#define CC1_SPEC "%(cc1_cpu) " SUBTARGET_CC1_SPEC
#endif
/* This macro defines names of additional specifications to put in the
diff --git a/gcc/config/ia64/ia64.h b/gcc/config/ia64/ia64.h
index bd0ef35e9a4..0e11cef0edc 100644
--- a/gcc/config/ia64/ia64.h
+++ b/gcc/config/ia64/ia64.h
@@ -51,7 +51,7 @@ do { \
{ "asm_extra", ASM_EXTRA_SPEC }, \
SUBTARGET_EXTRA_SPECS
-#define CC1_SPEC "%(cc1_cpu) "
+#define CC1_SPEC "%(cc1_cpu) " SUBTARGET_CC1_SPEC
#define ASM_EXTRA_SPEC ""
diff --git a/gcc/config/lm32/lm32.h b/gcc/config/lm32/lm32.h
index 23f66c90446..65a9141cd94 100644
--- a/gcc/config/lm32/lm32.h
+++ b/gcc/config/lm32/lm32.h
@@ -63,7 +63,7 @@
#define LIB_SPEC "%{!T*:-T sim.ld}"
#undef CC1_SPEC
-#define CC1_SPEC "%{G*}"
+#define CC1_SPEC "%{G*}" SUBTARGET_CC1_SPEC
[PATCH 2/2] RTEMS: Use local-exec TLS model by default
gcc/ChangeLog:
* config/rtems.h (SUBTARGET_CC1_SPEC): Undef and define.
---
gcc/config/rtems.h | 4
1 file changed, 4 insertions(+)
diff --git a/gcc/config/rtems.h b/gcc/config/rtems.h
index 95bcdc41b2f..4742b1f3722 100644
--- a/gcc/config/rtems.h
+++ b/gcc/config/rtems.h
@@ -56,3 +56,7 @@
/* Prefer int for int32_t (see stdint-newlib.h). */
#undef STDINT_LONG32
#define STDINT_LONG32 (INT_TYPE_SIZE != 32 && LONG_TYPE_SIZE == 32)
+
+/* Default to local-exec TLS model. */
+#undef SUBTARGET_CC1_SPEC
+#define SUBTARGET_CC1_SPEC " %{!ftls-model=*:-ftls-model=local-exec}"
--
2.35.3
Re: Use -ftls-model=local-exec for RTEMS by default?
On 21.07.22 10:03, Iain Sandoe wrote:
This sounds like an interesting approach in the long run, however, I need a
short term solution which I can back port to GCC 10, 11, and 12. I guess I will
add a
MULTILIB_EXTRA_OPTS = ftls-model=local-exec
to all RTEMS multilib configurations.
In general I think the target hooks are hard to customize for operating systems.
(IMO) It can be not too tricky - Darwin customises several - you just have to
override the default definition in your target-specific header and provide the
replacement e.g ( override in config/darwin.h, replacement in config/darwin.cc):
#undef TARGET_ENCODE_SECTION_INFO
#define TARGET_ENCODE_SECTION_INFO darwin_encode_section_info
The problem is that in this case you need a target-specific copy and
paste solution. For example lets suppose you want to use
#define CC1_SPEC "%{!ftls-model=*:-ftls-model=local-exec}"
for RTEMS (in gcc/config/rtems.h), then you have a problem on for
example microblaze (gcc/config/microblaze/microblaze.h):
#ifndef CC1_SPEC
#define CC1_SPEC " \
%{G*} \
%(subtarget_cc1_spec) \
%{mxl-multiply-high:-mcpu=v6.00.a} \
"
#endif
or nios2 (gcc/config/nios2/nios2.h):
#define CC1_SPEC "%{G*}"
For each target you would have to check if you have to provide some
extra times for CC1_SPEC through copy and paste.
--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax: +49-89-18 94 741 - 08
Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
