GCC build error on FreeBSD 12.1 with LLVM 8.0.1
Hello,
I tried to build a recent GCC master on FreeBSD 12.1 and it failed with
a compile error:
$ clang --version
FreeBSD clang version 8.0.1 (tags/RELEASE_801/final 366581) (based on
LLVM 8.0.1)
Target: x86_64-unknown-freebsd12.1
Thread model: posix
InstalledDir: /usr/bin
../../gnu-mirror-gcc-5bc9d2f5ed4/gcc/analyzer/engine.cc:2965:13: error:
reinterpret_cast from 'nullptr_t' to 'function *' is not allowed
v.m_fun = reinterpret_cast (NULL);
^~~
../../gnu-mirror-gcc-5bc9d2f5ed4/gcc/analyzer/engine.cc:2977:21: error:
reinterpret_cast from 'nullptr_t' to 'function *' is not allowed
return v.m_fun == reinterpret_cast (NULL);
^~~
This simple test program fails also:
struct function;
function *f(void)
{
return reinterpret_cast(nullptr);
}
$ clang -c test.cc
test.cc:5:10: error: reinterpret_cast from 'nullptr_t' to 'function *'
is not allowed
return reinterpret_cast(nullptr);
^
1 error generated.
I was able to build the GCC master on January 2nd 2020. Does this look
like an LLVM 8.0.1 issue or a GCC issue?
Re: [PATCH] analyzer: fix build error with clang (PR 93543)
On 04/02/2020 16:45, David Malcolm wrote: On Tue, 2020-02-04 at 16:26 +0100, Jakub Jelinek wrote: On Tue, Feb 04, 2020 at 09:00:37AM -0500, David Malcolm wrote: gcc/analyzer/ChangeLog: PR analyzer/93543 * engine.cc (pod_hash_traits::mark_empty): Eliminate reinterpret_cast. (pod_hash_traits::is_empty): Likewise. This is ok for trunk. Thanks. This should now be fixed on master (r10-6434- g1dae549dccfec1edb0cb4e65feadc4722bb3bcc8); I verified the build with the patch with gcc, and Sebastian verified it with clang. Thanks a lot for the quick fix. The master builds now again.
Gcov info registration without constructor?
Hello, I would like to use the -ftest-coverage -fprofile-arcs support on a bare metal system (no operating system or very early stages in the system startup). In this environment I cannot use the gcov info registration via a constructor and __gcov_init(), because there may be some other (more complex) constructors registered which cannot be called at this stage.. Would it be acceptable to add a compiler option which changes the gcov info registration via a constructor to a linker set? If enabled, then for each translation unit (see coverage_obj_init()) a pointer to the gcov info is placed into a special linker section (for example .gcov_info). The linker script collects all .gcov_info data and adds a begin/end symbol. The runtime support can then iterate over all linker section entries (pointers to struct gcov_info) to dump the aggregated gcov data during program termination. Would such changes be acceptable for GCC integration or is this too specific? Kind regards, Sebastian -- embedded brains GmbH 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 PGP: Public key available on request. embedded brains GmbH 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: Gcov info registration without constructor?
Hallo Martin, On 10/11/2020 13:05, Martin Liška wrote: On 11/9/20 6:45 PM, Sebastian Huber wrote: Hello, Hello. There was a similar need some time ago: https://gcc.gnu.org/legacy-ml/gcc/2019-11/msg9.html Please take a look for a possible inspiration. thanks for the pointer. I would like to use the -ftest-coverage -fprofile-arcs support on a bare metal system (no operating system or very early stages in the system startup). In this environment I cannot use the gcov info registration via a constructor and __gcov_init(), because there may be some other (more complex) constructors registered which cannot be called at this stage.. Would it be acceptable to add a compiler option which changes the gcov info registration via a constructor to a linker set? If enabled, then for each translation unit (see coverage_obj_init()) a pointer to the gcov info is placed into a special linker section (for example .gcov_info). The linker script collects all .gcov_info data and adds a begin/end symbol. The runtime support can then iterate over all linker section entries (pointers to struct gcov_info) to dump the aggregated gcov data during program termination. Would such changes be acceptable for GCC integration or is this too specific? That's definitely something we can support. Similarly to the linked message, are you capable of using normal system I/O to stream .gcda files? I cannot use I/O to files. I also cannot use dynamic memory (e.g. malloc()). This is actually not an issue, since it is very easy to dump the gcov info via a simple character output function as plain text. In the Linux kernel see for example convert_to_gcda() in "kernel/gcov/gcc_4_7.c". Instead of copying the data to a buffer you can directly output the data via some printk() function. On the host computer you can collect the text and generate the .gcda files. I guess the first thing we need is a name for the option. What about: -fprofile-info-section -fprofile-info-section=name Register a pointer to the profile information generated by -fprofile-arcs in the named section for each translation unit. If name is not given, then .gcov_info will be used. This option disables the profile information registration through a constructor and it disables the profile information processing through a destructor. This option can be used to support profiling in environments which do not support constructors and destructors. The linker could collect the content of the named section in a continuous memory block and add begin and end symbols. The runtime support could dump the profiling information registered in this linker set during program termination to a serial line for example. -- embedded brains GmbH 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 PGP: Public key available on request. embedded brains GmbH 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: Gcov info registration without constructor?
Hello Martin,
attached is a proof of concept. I am not sure how I can make the new
section read-only. Currently, it is writable:
.section .gcov_info,"aw"
.align 2
.type .LPBX2, @object
.size .LPBX2, 4
.LPBX2:
.long .LPBX0
I probably need also a patch for the GCC options documentation, test
cases, a GCC bootstrap on Linux, release notes, ...? Do I have to wait
for the GCC 11 development start?
--
embedded brains GmbH
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
PGP: Public key available on request.
embedded brains GmbH
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/
>From 305eb4066742418d3b14ee6e8bec76bfb2835a99 Mon Sep 17 00:00:00 2001
From: Sebastian Huber
Date: Tue, 10 Nov 2020 16:21:07 +0100
Subject: [PATCH] Add -fprofile-info-section support
---
gcc/common.opt | 8
gcc/coverage.c | 19 +--
gcc/opts.c | 4
3 files changed, 29 insertions(+), 2 deletions(-)
diff --git a/gcc/common.opt b/gcc/common.opt
index 7d0e0d9c88a..1b69da681e3 100644
--- a/gcc/common.opt
+++ b/gcc/common.opt
@@ -2268,6 +2268,14 @@ fprofile-generate=
Common Joined RejectNegative
Enable common options for generating profile info for profile feedback directed optimizations, and set -fprofile-dir=.
+fprofile-info-section
+Common RejectNegative
+Register a pointer to the profile information in the .gcov_info section.
+
+fprofile-info-section=
+Common Joined RejectNegative Var(profile_info_section)
+Register a pointer to the profile information in the named section.
+
fprofile-partial-training
Common Report Var(flag_profile_partial_training) Optimization
Do not assume that functions never executed during the train run are cold.
diff --git a/gcc/coverage.c b/gcc/coverage.c
index 7711412c3be..ec1c5d3d125 100644
--- a/gcc/coverage.c
+++ b/gcc/coverage.c
@@ -1151,8 +1151,23 @@ coverage_obj_init (void)
ASM_GENERATE_INTERNAL_LABEL (name_buf, "LPBX", 0);
DECL_NAME (gcov_info_var) = get_identifier (name_buf);
- build_init_ctor (gcov_info_type);
- build_gcov_exit_decl ();
+ if (profile_info_section)
+{
+ tree var = build_decl (BUILTINS_LOCATION,
+ VAR_DECL, NULL_TREE,
+ build_pointer_type (gcov_info_type));
+ TREE_STATIC (var) = 1;
+ ASM_GENERATE_INTERNAL_LABEL (name_buf, "LPBX", 2);
+ DECL_NAME (var) = get_identifier (name_buf);
+ set_decl_section_name (var, profile_info_section);
+ DECL_INITIAL (var) = build_fold_addr_expr (gcov_info_var);
+ varpool_node::finalize_decl (var);
+}
+ else
+{
+ build_init_ctor (gcov_info_type);
+ build_gcov_exit_decl ();
+}
return true;
}
diff --git a/gcc/opts.c b/gcc/opts.c
index 96291e89a49..fd6e669471e 100644
--- a/gcc/opts.c
+++ b/gcc/opts.c
@@ -2602,6 +2602,10 @@ common_handle_option (struct gcc_options *opts,
SET_OPTION_IF_UNSET (opts, opts_set, flag_ipa_bit_cp, value);
break;
+case OPT_fprofile_info_section:
+ opts->x_profile_info_section = ".gcov_info";
+ break;
+
case OPT_fpatchable_function_entry_:
{
char *patch_area_arg = xstrdup (arg);
--
2.26.2
Re: Gcov info registration without constructor?
On 10/11/2020 17:23, Sebastian Huber wrote: I am not sure how I can make the new section read-only. Currently, it is writable: .section .gcov_info,"aw" .align 2 .type .LPBX2, @object .size .LPBX2, 4 .LPBX2: .long .LPBX0 I changed the section by adding: TREE_READONLY (var) = 1; get_section (profile_info_section, SECTION_UNNAMED, NULL); This is the generated data: .section .gcov_info,"a" .align 2 .type .LPBX2, @object .size .LPBX2, 4 .LPBX2: .long .LPBX0 .section .rodata .align 2 -- embedded brains GmbH 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 PGP: Public key available on request. embedded brains GmbH 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's instrumentation and the target environment
Hello David,
I also would like to use GCC to get code coverage on an embedded system.
My approach would be to place the gcov information in a dedicated linker
set:
https://gcc.gnu.org/pipermail/gcc-patches/2020-November/559004.html
Please have a look at the attached patches for a proposal to get the
data from the target.
--
embedded brains GmbH
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
PGP: Public key available on request.
embedded brains GmbH
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/
>From ace43807e322dbdb075e507d9a84e676d4c34c64 Mon Sep 17 00:00:00 2001
From: Sebastian Huber
Date: Sat, 14 Nov 2020 13:51:09 +0100
Subject: [PATCH 1/2] gcov: Add and use gcov_are_all_counters_zero()
libgcc/
libgcov.h (gcov_are_all_counters_zero): New.
libgcov-driver.c (write_one_data): Use gcov_are_all_counters_zero().
---
libgcc/libgcov-driver.c | 12 ++--
libgcc/libgcov.h| 12
2 files changed, 14 insertions(+), 10 deletions(-)
diff --git a/libgcc/libgcov-driver.c b/libgcc/libgcov-driver.c
index e53e4dc392a..ba308438474 100644
--- a/libgcc/libgcov-driver.c
+++ b/libgcc/libgcov-driver.c
@@ -428,16 +428,8 @@ write_one_data (const struct gcov_info *gi_ptr,
write_top_counters (ci_ptr, t_ix, n_counts);
else
{
- /* Do not stream when all counters are zero. */
- int all_zeros = 1;
- for (unsigned i = 0; i < n_counts; i++)
- if (ci_ptr->values[i] != 0)
- {
- all_zeros = 0;
- break;
- }
-
- if (all_zeros)
+ if (gcov_are_all_counters_zero (ci_ptr))
+ /* Do not stream when all counters are zero. */
gcov_write_tag_length (GCOV_TAG_FOR_COUNTER (t_ix),
GCOV_TAG_COUNTER_LENGTH (-n_counts));
else
diff --git a/libgcc/libgcov.h b/libgcc/libgcov.h
index e70cf63b414..915a1b1530d 100644
--- a/libgcc/libgcov.h
+++ b/libgcc/libgcov.h
@@ -304,6 +304,18 @@ extern void __gcov_average_profiler_atomic (gcov_type *, gcov_type);
extern void __gcov_ior_profiler (gcov_type *, gcov_type);
extern void __gcov_ior_profiler_atomic (gcov_type *, gcov_type);
+/* Return 1, if all counter values are zero, otherwise 0. */
+
+static inline int
+gcov_are_all_counters_zero (const struct gcov_ctr_info *ci_ptr)
+{
+ for (unsigned i = 0; i < ci_ptr->num; i++)
+if (ci_ptr->values[i] != 0)
+ return 0;
+
+ return 1;
+}
+
#ifndef inhibit_libc
/* The wrappers around some library functions.. */
extern pid_t __gcov_fork (void) ATTRIBUTE_HIDDEN;
--
2.26.2
>From 9235be68b52ee7b321d985fe2d82a38d685ffb4f Mon Sep 17 00:00:00 2001
From: Sebastian Huber
Date: Fri, 13 Nov 2020 22:01:14 +0100
Subject: [PATCH 2/2] gcov: Add __gcov_info_to_gdca()
libgcc/
Makefile.in: Add libgcov-info-to-gcda.c to libgcov.a.
gcov.h (gcov_info): Declare.
(__gcov_info_to_gdca): Likewise.
libgcov-info-to-gcda.c: New.
---
libgcc/Makefile.in| 7 ++-
libgcc/gcov.h | 9 +++
libgcc/libgcov-info-to-gcda.c | 106 ++
3 files changed, 121 insertions(+), 1 deletion(-)
create mode 100644 libgcc/libgcov-info-to-gcda.c
diff --git a/libgcc/Makefile.in b/libgcc/Makefile.in
index d6075d32bd4..ae8ddc23955 100644
--- a/libgcc/Makefile.in
+++ b/libgcc/Makefile.in
@@ -909,13 +909,16 @@ LIBGCOV_INTERFACE = _gcov_dump _gcov_fork\
_gcov_execle _gcov_execv _gcov_execvp _gcov_execve _gcov_reset \
_gcov_lock_unlock
LIBGCOV_DRIVER = _gcov
+LIBGCOV_INFO_TO_GCDA = _gcov_info_to_gcda
libgcov-merge-objects = $(patsubst %,%$(objext),$(LIBGCOV_MERGE))
libgcov-profiler-objects = $(patsubst %,%$(objext),$(LIBGCOV_PROFILER))
libgcov-interface-objects = $(patsubst %,%$(objext),$(LIBGCOV_INTERFACE))
libgcov-driver-objects = $(patsubst %,%$(objext),$(LIBGCOV_DRIVER))
+libgcov-info-to-gcda-objects = $(patsubst %,%$(objext),$(LIBGCOV_INFO_TO_GCDA))
libgcov-objects = $(libgcov-merge-objects) $(libgcov-profiler-objects) \
- $(libgcov-interface-objects) $(libgcov-driver-objects)
+ $(libgcov-interface-objects) $(libgcov-driver-objects) \
+ $(libgcov-info-to-gcda-objects)
$(libgcov-merge-objects): %$(objext): $(srcdir)/libgcov-merge.c $(srcdir)/gcov.h $(srcdir)/libgcov.h
$(gcc_compile) -DL$* -c $(srcdir)/libgcov-merge.c
@@ -926,6 +929,8 @@ $(libgcov-interface-objects): %$(objext): $(srcdir)/libgcov-interface.c $(srcdir
$(libgcov-driver-objects): %$(objext): $(srcdir)/libgcov-driver.c \
$(srcdir)/libgcov-driver-system.c $(srcdir)/gcov.h $(srcdir)/libgcov.h
$(gcc_compile) -DL$* -c $(srcdir)/libgcov-driver.c
+$(libgcov-info-to-gcda-objects): %$(objext): $(srcdir)/libgcov-info-to-gcda.c $(srcdir)/gcov.h $(srcdir)/libgcov.h
+ $(gcc_compi
nios2 -mcustom-round vs. libatomic
Hello, I try to add a nios2 multilib to support the "Nios II Floating Point Hardware 2 Component": https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/ug/ug_nios2_custom_instruction.pdf If I add all custom instructions supported by the component, then I get an error in libatomic since -Werror is used: cc1: error: switch '-mcustom-fmins' has no effect unless '-ffinite-math-only' is specified [-Werror] cc1: error: switch '-mcustom-fmaxs' has no effect unless '-ffinite-math-only' is specified [-Werror] cc1: error: switch '-mcustom-round' has no effect unless '-fno-math-errno' is specified [-Werror] I am not sure how to fix 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: nios2 -mcustom-round vs. libatomic
On 14/01/2021 15:16, Sebastian Huber wrote: Hello, I try to add a nios2 multilib to support the "Nios II Floating Point Hardware 2 Component": https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/ug/ug_nios2_custom_instruction.pdf If I add all custom instructions supported by the component, then I get an error in libatomic since -Werror is used: cc1: error: switch '-mcustom-fmins' has no effect unless '-ffinite-math-only' is specified [-Werror] cc1: error: switch '-mcustom-fmaxs' has no effect unless '-ffinite-math-only' is specified [-Werror] cc1: error: switch '-mcustom-round' has no effect unless '-fno-math-errno' is specified [-Werror] I am not sure how to fix this. Is a compiler warning the right diagnostic for an inconsistent use of compiler options? This warning is not related to code processed by GCC. -- 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/
How can operating systems add linker flags to the GCC specs?
Hello,
for RTEMS we have in gcc/config/rtems.h the following LIB_SPEC:
#undef LIB_SPEC
#define LIB_SPEC "%{!qrtems:" STD_LIB_SPEC "} " \
"%{qrtems:%{!nostdlib:%{!nodefaultlibs:" \
"--start-group -lrtemsbsp -lrtemscpu -latomic -lc -lgcc --end-group} " \
"%{!qnolinkcmds:-T linkcmds%s}}}"
The intention was that a GCC command line to link an executable with
-qrtems -nodefaultlibs
still uses "-T linkcmds", however, this didn't work. I think this is due to
*link_gcc_c_sequence:
%G %{!nolibc:%L %G}
*link_command:
... %{!nostdlib:%{!r:%{!nodefaultlibs:%(link_ssp)
%(link_gcc_c_sequence)}}} ...
%(post_link) }}
So, if nodefaultlib is present, the LIB_SPEC is not evaluated at all?
The problem is that LINK_SPEC is specialized by target. For RTEMS, we
have to use the target definitions. In the default definition of
LINK_COMMAND_SPEC (gcc/gcc.c) there is no define for operating system
customization. Would it be possible to add something this?
diff --git a/gcc/config/rtems.h b/gcc/config/rtems.h
index 743161c4bac..a7cea9b1d2f 100644
--- a/gcc/config/rtems.h
+++ b/gcc/config/rtems.h
@@ -49,9 +49,9 @@
#undef LIB_SPEC
#define LIB_SPEC "%{!qrtems:" STD_LIB_SPEC "} " \
-"%{qrtems:%{!nostdlib:%{!nodefaultlibs:" \
-"--start-group -lrtemsbsp -lrtemscpu -latomic -lc -lgcc --end-group} " \
-"%{!qnolinkcmds:-T linkcmds%s}}}"
+"%{qrtems:--start-group -lrtemsbsp -lrtemscpu -latomic -lc -lgcc
--end-group}"
+
+#define SYSTEM_LINK_SPEC "%{qrtems:%{!qnolinkcmds:-T linkcmds%s}}"
#define TARGET_POSIX_IO
diff --git a/gcc/gcc.c b/gcc/gcc.c
index 7dccfadfef2..eff72cb3412 100644
--- a/gcc/gcc.c
+++ b/gcc/gcc.c
@@ -1107,6 +1107,11 @@ proper position among the other output files. */
%{%:sanitize(leak):" LIBLSAN_SPEC ""
#endif
+/* Linker command line options defined by the operating system. */
+#ifndef SYSTEM_LINK_SPEC
+#define SYSTEM_LINK_SPEC ""
+#endif
+
#ifndef POST_LINK_SPEC
#define POST_LINK_SPEC ""
#endif
@@ -1158,7 +1163,8 @@ proper position among the other output files. */
%:include(libgomp.spec)%(link_gomp)}\
%{fgnu-tm:%:include(libitm.spec)%(link_itm)}\
%(mflib) " STACK_SPLIT_SPEC "\
- %{fprofile-arcs|fprofile-generate*|coverage:-lgcov} "
SANITIZER_SPEC " \
+ %{fprofile-arcs|fprofile-generate*|coverage:-lgcov} " \
+ SANITIZER_SPEC " " SYSTEM_LINK_SPEC " \
%{!nostdlib:%{!r:%{!nodefaultlibs:%(link_ssp)
%(link_gcc_c_sequence)}}}\
%{!nostdlib:%{!r:%{!nostartfiles:%E}}} %{T*} \n%(post_link) }}"
#endif
--
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: How can operating systems add linker flags to the GCC specs?
On 22/01/2021 10:46, Sebastian Huber wrote:
Hello,
for RTEMS we have in gcc/config/rtems.h the following LIB_SPEC:
#undef LIB_SPEC
#define LIB_SPEC "%{!qrtems:" STD_LIB_SPEC "} " \
"%{qrtems:%{!nostdlib:%{!nodefaultlibs:" \
"--start-group -lrtemsbsp -lrtemscpu -latomic -lc -lgcc --end-group} " \
"%{!qnolinkcmds:-T linkcmds%s}}}"
The intention was that a GCC command line to link an executable with
-qrtems -nodefaultlibs
still uses "-T linkcmds", however, this didn't work. I think this is
due to
*link_gcc_c_sequence:
%G %{!nolibc:%L %G}
*link_command:
... %{!nostdlib:%{!r:%{!nodefaultlibs:%(link_ssp)
%(link_gcc_c_sequence)}}} ...
%(post_link) }}
So, if nodefaultlib is present, the LIB_SPEC is not evaluated at all?
The problem is that LINK_SPEC is specialized by target. For RTEMS, we
have to use the target definitions. In the default definition of
LINK_COMMAND_SPEC (gcc/gcc.c) there is no define for operating system
customization. Would it be possible to add something this?
I think the STARTFILES_SPEC can be used as a workaround:
https://gcc.gnu.org/pipermail/gcc-patches/2021-January/564101.html
This avoids modifications in "gcc/gcc.c".
--
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/
Unit tests for libgomp config APIs?
Hello, the libgomp has currently four config support directories: bsd, linux, mingw32and posix. For RTEMS we use currently the POSIX config which has however quite a huge run-time overhead. I would like to implement something similar to the Linux futex based config. There are no unit tests for the APIs defined by bar.h, mutex.h, ptrlock.h and sem.h in the testsuite. Would it be acceptable to add tests for this area? -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
Copy keys of threads compatibility routines for libgcc2?
Hello, the file libgcc/gthr.h defines the interface for the thread support used by libgcc2 and C11. A couple of types are required, e.g. __gthread_key_t Is it allowed to copy objects of this type? For example is the following a valid use case __gthread_key_t k1; __gthread_key_t k2; __gthread_key_create(&k1); k2 = k1; __gthread_setspecific(k2, 0xdeadbeef); __gthread_key_delete(k2); ? -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
libgomp: Purpose of gomp_thread_pool::last_team?
Hello,
does anyone know what the purpose of gomp_thread_pool::last_team is? This field
seems to be used to delay the team destruction in gomp_team_end() in case the
team has more than one thread and the previous team state has no team
associated (identifies this a master thread?):
if (__builtin_expect (thr->ts.team != NULL, 0)
|| __builtin_expect (team->nthreads == 1, 0))
free_team (team);
else
{
struct gomp_thread_pool *pool = thr->thread_pool;
if (pool->last_team)
free_team (pool->last_team);
pool->last_team = team;
}
Why can you not immediately free the team?
--
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail : sebastian.huber at embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
libgomp: gomp_ptrlock*() specification
Hello, from the use cases in libgomp it seems that you may set the value of a ptrlock object at most once via gomp_ptrlock_set() if it wasn't already initialized to a non-NULL value via gomp_ptrlock_init()? Is this correct? Why is there a specialized Linux implementation? Is this to save one extra integer for the mutex? -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.huber at embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
[gomp] Reuse futex barrier implementation for RTEMS
Hello,
the libgomp configuration for RTEMS uses currently the POSIX
implementation. Unfortunately the performance is unacceptable bad, so I
work currently on a specialized RTEMS configuration. I would like to
reuse the code of the Linux futex barrier. On RTEMS there is no
kernel/user space separation. In order to make the futex management
simpler, I would like to optionally embed a futex object in the barrier.
Would a change like this be acceptable?
diff --git a/libgomp/config/linux/bar.h b/libgomp/config/linux/bar.h
index 3236436..b47b9f6 100644
--- a/libgomp/config/linux/bar.h
+++ b/libgomp/config/linux/bar.h
@@ -40,6 +40,9 @@ typedef struct
unsigned generation;
unsigned awaited __attribute__((aligned (64)));
unsigned awaited_final;
+#ifdef HAVE_BARRIER_FUTEX
+ gomp_barrier_futex_t futex;
+#endif
} gomp_barrier_t;
typedef unsigned int gomp_barrier_state_t;
diff --git a/libgomp/config/linux/futex.h b/libgomp/config/linux/futex.h
index c99ea37..7aab595 100644
--- a/libgomp/config/linux/futex.h
+++ b/libgomp/config/linux/futex.h
@@ -68,3 +68,7 @@ cpu_relax (void)
{
__asm volatile ("" : : : "memory");
}
+
+#define barrier_futex_wait(addr, val, futex) futex_wait (addr, val)
+
+#define barrier_futex_wake(addr, count, futex) futex_wake (addr, count)
diff --git a/libgomp/config/linux/bar.c b/libgomp/config/linux/bar.c
index 51fbd99..d776796 100644
--- a/libgomp/config/linux/bar.c
+++ b/libgomp/config/linux/bar.c
@@ -40,7 +40,7 @@ gomp_barrier_wait_end (gomp_barrier_t *bar,
gomp_barrier_state_t state)
bar->awaited = bar->total;
__atomic_store_n (&bar->generation, bar->generation + BAR_INCR,
MEMMODEL_RELEASE);
- futex_wake ((int *) &bar->generation, INT_MAX);
+ barrier_futex_wake ((int *) &bar->generation, INT_MAX, &bar->futex);
}
else
{
@@ -74,7 +74,8 @@ gomp_barrier_wait_last (gomp_barrier_t *bar)
void
gomp_team_barrier_wake (gomp_barrier_t *bar, int count)
{
- futex_wake ((int *) &bar->generation, count == 0 ? INT_MAX : count);
+ barrier_futex_wake ((int *) &bar->generation, count == 0 ? INT_MAX :
count,
+ &bar->futex);
}
void
@@ -100,7 +101,7 @@ gomp_team_barrier_wait_end (gomp_barrier_t *bar,
gomp_barrier_state_t state)
state &= ~BAR_CANCELLED;
state += BAR_INCR - BAR_WAS_LAST;
__atomic_store_n (&bar->generation, state, MEMMODEL_RELEASE);
- futex_wake ((int *) &bar->generation, INT_MAX);
+ barrier_futex_wake ((int *) &bar->generation, INT_MAX, &bar->futex);
return;
}
}
@@ -163,7 +164,7 @@ gomp_team_barrier_wait_cancel_end (gomp_barrier_t *bar,
{
state += BAR_INCR - BAR_WAS_LAST;
__atomic_store_n (&bar->generation, state, MEMMODEL_RELEASE);
- futex_wake ((int *) &bar->generation, INT_MAX);
+ barrier_futex_wake ((int *) &bar->generation, INT_MAX, &bar->futex);
return false;
}
}
@@ -199,13 +200,14 @@ gomp_team_barrier_wait_cancel (gomp_barrier_t *bar)
void
gomp_team_barrier_cancel (struct gomp_team *team)
{
+ gomp_barrier_t *bar = &team->barrier;
gomp_mutex_lock (&team->task_lock);
- if (team->barrier.generation & BAR_CANCELLED)
+ if (bar->generation & BAR_CANCELLED)
{
gomp_mutex_unlock (&team->task_lock);
return;
}
- team->barrier.generation |= BAR_CANCELLED;
+ bar->generation |= BAR_CANCELLED;
gomp_mutex_unlock (&team->task_lock);
- futex_wake ((int *) &team->barrier.generation, INT_MAX);
+ barrier_futex_wake ((int *) &bar->generation, INT_MAX, &bar->futex);
}
--
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
Re: [gomp] Reuse futex barrier implementation for RTEMS
On 17/07/15 08:40, Sebastian Huber wrote:
Hello,
the libgomp configuration for RTEMS uses currently the POSIX
implementation. Unfortunately the performance is unacceptable bad, so
I work currently on a specialized RTEMS configuration. I would like to
reuse the code of the Linux futex barrier. On RTEMS there is no
kernel/user space separation. In order to make the futex management
simpler, I would like to optionally embed a futex object in the
barrier. Would a change like this be acceptable?
Attached is a more complete example.
--
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>From 0410937e6f07dd1923dbcf20a0b2cda5953cd1cc Mon Sep 17 00:00:00 2001
From: Sebastian Huber
Date: Wed, 1 Jul 2015 22:14:38 +0200
Subject: [PATCH] [gomp] Add RTEMS configuration
libgomp/ChangeLog
2015-07-18 Sebastian Huber
* config/rtems/bar.c: New.
* config/rtems/bar.h: Likewise.
* config/rtems/mutex.c: Likewise.
* config/rtems/mutex.h: Likewise.
* config/rtems/sem.c: Likewise.
* config/rtems/sem.h: Likewise.
* config/linux/bar.c (gomp_barrier_wait): Use
barrier_futex_wake() instead of futex_wake(). Use
barrier_futex_wait() instead of futex_wait(). Use
barrier_do_wait() instead of do_wait().
(gomp_team_barrier_wake): Likewise.
(gomp_team_barrier_wait_end): Likewise.
(gomp_team_barrier_wait_end): Likewise.
(gomp_team_barrier_wait_cancel_end): Likewise.
(gomp_team_barrier_cancel): Likewise.
* config/linux/bar.h (gomp_barrier_t): Add optional futex
member.
* config/linux/wait.h (barrier_futex_wake): New.
(barrier_futex_wait): Likewise.
(barrier_do_wait): Likewise.
* configure.ac (*-*-rtems*): Check that Newlib provides a proper
header file.
* configure.tgt (*-*-rtems*): Enable RTEMS configuration if
supported by Newlib.
* configure: Regenerate.
---
libgomp/config/linux/bar.c | 22 ---
libgomp/config/linux/bar.h | 3 ++
libgomp/config/linux/wait.h | 6
libgomp/config/rtems/bar.c | 65
libgomp/config/rtems/bar.h | 39 ++
libgomp/config/rtems/mutex.c | 1 +
libgomp/config/rtems/mutex.h | 57 ++
libgomp/config/rtems/sem.c | 1 +
libgomp/config/rtems/sem.h | 55 +
libgomp/configure| 17
libgomp/configure.ac | 7 +
libgomp/configure.tgt| 7 +
12 files changed, 270 insertions(+), 10 deletions(-)
create mode 100644 libgomp/config/rtems/bar.c
create mode 100644 libgomp/config/rtems/bar.h
create mode 100644 libgomp/config/rtems/mutex.c
create mode 100644 libgomp/config/rtems/mutex.h
create mode 100644 libgomp/config/rtems/sem.c
create mode 100644 libgomp/config/rtems/sem.h
diff --git a/libgomp/config/linux/bar.c b/libgomp/config/linux/bar.c
index 51fbd99..920b85e 100644
--- a/libgomp/config/linux/bar.c
+++ b/libgomp/config/linux/bar.c
@@ -40,12 +40,12 @@ gomp_barrier_wait_end (gomp_barrier_t *bar, gomp_barrier_state_t state)
bar->awaited = bar->total;
__atomic_store_n (&bar->generation, bar->generation + BAR_INCR,
MEMMODEL_RELEASE);
- futex_wake ((int *) &bar->generation, INT_MAX);
+ barrier_futex_wake ((int *) &bar->generation, INT_MAX, &bar->futex);
}
else
{
do
- do_wait ((int *) &bar->generation, state);
+ barrier_do_wait ((int *) &bar->generation, state, &bar->futex);
while (__atomic_load_n (&bar->generation, MEMMODEL_ACQUIRE) == state);
}
}
@@ -74,7 +74,8 @@ gomp_barrier_wait_last (gomp_barrier_t *bar)
void
gomp_team_barrier_wake (gomp_barrier_t *bar, int count)
{
- futex_wake ((int *) &bar->generation, count == 0 ? INT_MAX : count);
+ barrier_futex_wake ((int *) &bar->generation, count == 0 ? INT_MAX : count,
+ &bar->futex);
}
void
@@ -100,7 +101,7 @@ gomp_team_barrier_wait_end (gomp_barrier_t *bar, gomp_barrier_state_t state)
state &= ~BAR_CANCELLED;
state += BAR_INCR - BAR_WAS_LAST;
__atomic_store_n (&bar->generation, state, MEMMODEL_RELEASE);
- futex_wake ((int *) &bar->generation, INT_MAX);
+ barrier_futex_wake ((int *) &bar->generation, INT_MAX, &bar->futex);
return;
}
}
@@ -109,7 +110,7 @@ gomp_team_barrier_wait_end (gomp_barrier_t *bar, gomp_barrier_state_t state)
state &= ~BAR_CANCELLED;
do
{
- do_wait ((int *) &bar->generation, generation);
+ barrier_do_wait ((int *) &bar->generation, generation, &bar->futex);
gen = __atomic_load_n (&bar->generation, MEMMODEL_ACQUIRE);
if (__builtin_expect (gen & BAR_TASK_PEND
Re: [gomp] Reuse futex barrier implementation for RTEMS
On 17/07/15 13:26, Jakub Jelinek wrote: On Fri, Jul 17, 2015 at 01:17:32PM +0200, Sebastian Huber wrote: >On 17/07/15 08:40, Sebastian Huber wrote: > >Hello, > > > >the libgomp configuration for RTEMS uses currently the POSIX > >implementation. Unfortunately the performance is unacceptable bad, so I > >work currently on a specialized RTEMS configuration. I would like to reuse > >the code of the Linux futex barrier. On RTEMS there is no kernel/user > >space separation. In order to make the futex management simpler, I would > >like to optionally embed a futex object in the barrier. Would a change > >like this be acceptable? > >Attached is a more complete example. I'd prefer not to share the two implementations, just copy and adjust the linux/bar.[ch] into rtems/bar.[ch]. Ok, I understand that you want to separate support for a niche system from the mainline Linux, but then I have to deal with all the problems involved with copy and paste of source code, e.g. RTEMS would not automatically profit from bug fixes and improvements of the Linux futex barrier. -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
Re: [gomp] Reuse futex barrier implementation for RTEMS
On 17/07/15 13:43, Jakub Jelinek wrote: On Fri, Jul 17, 2015 at 01:33:41PM +0200, Sebastian Huber wrote: Attached is a more complete example. I'd prefer not to share the two implementations, just copy and adjust the linux/bar.[ch] into rtems/bar.[ch]. Ok, I understand that you want to separate support for a niche system from the mainline Linux, but then I have to deal with all the problems involved with copy and paste of source code, e.g. RTEMS would not automatically profit from bug fixes and improvements of the Linux futex barrier. As you can see from the history, the amount of changes in that area is not all that big, the last change is from 2013 when cancellation has been added. When a support for a new version of the standard is added (roughly every 2 years), the implementation needs to be tested and adjusted anyway. I'd prefer not to have ifdefed code around in the Linux version, and the RTEMS futex doesn't seem to be really similar to the Linux one (doesn't operate on ints which contain the values). The prototypes for the futex support are: int _Futex_Wait( struct _Futex_Control *futex, int *uaddr, int val ) int _Futex_Wake( struct _Futex_Control *futex, int count ) The wait doesn't need the uaddr, since we don't have to search the futex control structure. BTW, dunno how large the _Futex_Control is, but if it is smaller than 64 bytes imnus 2 * sizeof(int), I'd suggest to put it right after the generation field, at least in the Linux version the futex waiting/wakeup is on the generation field in the first cache line, while it is expected the second cache line is being changed independently. Thanks for the hint. The size is 12 bytes on a 32-bit architecture. -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
Re: [gomp] Reuse futex barrier implementation for RTEMS
On 17/07/15 14:36, Torvald Riegel wrote:
On Fri, 2015-07-17 at 13:33 +0200, Sebastian Huber wrote:
>On 17/07/15 13:26, Jakub Jelinek wrote:
> >On Fri, Jul 17, 2015 at 01:17:32PM +0200, Sebastian Huber wrote:
> >> >On 17/07/15 08:40, Sebastian Huber wrote:
> >>> > >Hello,
> >>> > >
> >>> > >the libgomp configuration for RTEMS uses currently the POSIX
> >>> > >implementation. Unfortunately the performance is unacceptable bad, so I
> >>> > >work currently on a specialized RTEMS configuration. I would like to
reuse
> >>> > >the code of the Linux futex barrier. On RTEMS there is no kernel/user
> >>> > >space separation. In order to make the futex management simpler, I
would
> >>> > >like to optionally embed a futex object in the barrier. Would a change
> >>> > >like this be acceptable?
> >> >
> >> >Attached is a more complete example.
> >I'd prefer not to share the two implementations, just copy and adjust
> >the linux/bar.[ch] into rtems/bar.[ch].
>
>Ok, I understand that you want to separate support for a niche system
>from the mainline Linux, but then I have to deal with all the problems
>involved with copy and paste of source code, e.g. RTEMS would not
>automatically profit from bug fixes and improvements of the Linux futex
>barrier.
I agree with Jakub. If your OS implements blocking differently than
Linux futexes, you are probably better off with a barrier implementation
whose blocking is designed for your OS' blocking mechanism.
Ok, I already changed the patch and don't touch the Linux code any more.
How does your blocking mechanism work, roughly? Is _Futex_Control a
wake queue associated with the uaddr, basically?
Yes, exactly. It is very simple:
struct _Futex_Control {
struct _Thread_queue_Queue _Queue;
};
int _Futex_Wait( struct _Futex_Control *futex, int *uaddr, int val )
{
ISR_lock_Context lock_context;
Thread_Control *executing;
int eno;
executing = _Futex_Queue_acquire( futex, &lock_context );
if ( *uaddr == val ) {
_Thread_queue_Enqueue_critical(
_Futex_Get_thread_queue( futex ),
FUTEX_TQ_OPERATIONS,
executing,
STATES_WAITING_FOR_MUTEX,
0,
0,
&lock_context
);
eno = 0;
} else {
_Futex_Queue_release( futex, &lock_context );
eno = EWOULDBLOCK;
}
return eno;
}
Perhaps something
along Java's park/unpark could be more natural for your OS. Or you
could even simplify the barrier implementation if you can check
arbitrary conditions, not just equality of a value and the futex word.
Its certainly possible to optimize it, but using the Linux futex barrier
was very easy, yields acceptable results and I don't have to reverse
engineer the expected behaviour. I don't have an unlimited budget for
this work and have to focus on the hot spots. My next step is to change
the thread pool management of libgomp so that it better fits to the
partitioned/clustered schedulers we have in RTEMS.
--
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
30_threads/timed_mutex/try_lock_until/57641.cc
Hello, in this test case there are two bool test variables (global and local). Is this intentional? -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
[libstdc++] dg-require-atomic-builtins on ARM
Hello,
I would like to run as many tests as possible on the arm-rtems target.
Unfortunately about 100 tests use this:
// { dg-require-atomic-builtins "" }
Which uses a function check_v3_target_atomic_builtins in libstdc++.exp,
which uses this program to determine if the atomic builtins are available:
puts $f "#if __GCC_ATOMIC_BOOL_LOCK_FREE < 2"
puts $f "# error No atomic bool"
puts $f "#endif"
puts $f "#if __GCC_ATOMIC_INT_LOCK_FREE < 2"
puts $f "# error No atomic int"
puts $f "#endif"
The default architecture version on arm-rtems is v4, so
__GCC_ATOMIC_BOOL_LOCK_FREE == 1 and __GCC_ATOMIC_INT_LOCK_FREE == 1.
How do the other ARM testers tackle this issue? Would it be possible to
add for example a "-march=armv7-a" option if the target selector
contains "arm"?
--
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
Re: [libstdc++] dg-require-atomic-builtins on ARM
On 01/09/15 14:22, Andreas Schwab wrote:
Sebastian Huber writes:
How do the other ARM testers tackle this issue? Would it be possible to
add for example a "-march=armv7-a" option if the target selector contains
"arm"?
RUNTESTFLAGS=--target_board=unix\{,-march=armv7-a\}
Thanks for this hint. Do you know the magic to use more than one machine
option, e.g. -march=armv7-a -mthumb? I tried several ways to quote the
space character, and so on, but nothing worked. I didn't find any
documentation for this {} stuff.
--
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
Re: Powerpc atomic_load
On 10/09/15 19:52, David Edelsohn wrote: https://www.cl.cam.ac.uk/~pes20/cpp/cpp0xmappings.html Is there specific reason why the SYNC L,E (Elemental Memory Barriers) defined by Power-ISA V2.07 doesn't appear in this table? -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
Re: gnat 4.9.2 on arm with rtems
On 28/10/15 15:22, Jan Sommer wrote: I got it working. The Set function was always overwriting the address of the previous ATCB, so STPO.Self was always returning the ATCB of the task created last. It turns out that I was building rtems without the --enable-ada option. The option is not mentioned in configure --help and gnat still builds fine. Would it be possible to not have the symbol rtems_task_self if the --enable-ada switch is off? Then linking gnat should fail with an undefined reference. I don't know too much of the rtems internals, but maybe it is as easy as adding ifdefs around the SCORE_EXTERN void *rtems_ada_self in score/threadimpl.h? Since you work on this area, this task variable should go way, since its broken on SMP systems. I would replace it o with functions, e.g. rtems_ada_get_self() and rtems_ada_set_self(), or o POSIX keys, or o thread-local storage. POSIX keys and thread-local storage would make the --enable-ada option superfluous. Thread-local storage is more efficient. It is well supported on ARM, PowerPC and SPARC on RTEMS. @Joel: What shall I do about the changes I made to gcc/ada/s-osinte-rtems.ads and newlib/libc/sys/rtems/sys/cpuset.h ? Just send the patches to you or should I push them to the respective lists with you CC? Please send them as patches to the corresponding lists and CC de...@rtems.org. -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
libatomic on ARM
Hello, I tried to build the libatomic for RTEMS on ARM and I got this error: make[2]: Entering directory `/build/git-build/b-gcc-git-arm-rtems4.12/arm-rtems4.12/thumb/armv6-m/libatomic' /bin/sh ./libtool --tag=CC --mode=compile /build/git-build/b-gcc-git-arm-rtems4.12/./gcc/xgcc -B/build/git-build/b-gcc-git-arm-rtems4.12/./gcc/ -nostdinc -B/build/git-build/b-gcc-git-arm-rtems4.12/arm-rtems4.12/thumb/armv6-m/newlib/ -isystem /build/git-build/b-gcc-git-arm-rtems4.12/arm-rtems4.12/thumb/armv6-m/newlib/targ-include -isystem /home/EB/sebastian_h/archive/gcc-git/newlib/libc/include -B/opt/rtems-4.12/arm-rtems4.12/bin/ -B/opt/rtems-4.12/arm-rtems4.12/lib/ -isystem /opt/rtems-4.12/arm-rtems4.12/include -isystem /opt/rtems-4.12/arm-rtems4.12/sys-include -mthumb -march=armv6-m -DHAVE_CONFIG_H -I/home/EB/sebastian_h/archive/gcc-git/libatomic/config/arm -I/home/EB/sebastian_h/archive/gcc-git/libatomic/config/rtems -I/home/EB/sebastian_h/archive/gcc-git/libatomic -I.-Wall -Werror -g -O2 -fno-sync-libcalls -fno-sync-libcalls -MT exch_1_.lo -MD -MP -MF .deps/exch_1_.lo.Ppo -DN=1 -c -o exch_1_.lo /home/EB/sebastian_h/archive/gcc-git/libatomic/config/arm/exch_n.c libtool: compile: /build/git-build/b-gcc-git-arm-rtems4.12/./gcc/xgcc -B/build/git-build/b-gcc-git-arm-rtems4.12/./gcc/ -nostdinc -B/build/git-build/b-gcc-git-arm-rtems4.12/arm-rtems4.12/thumb/armv6-m/newlib/ -isystem /build/git-build/b-gcc-git-arm-rtems4.12/arm-rtems4.12/thumb/armv6-m/newlib/targ-include -isystem /home/EB/sebastian_h/archive/gcc-git/newlib/libc/include -B/opt/rtems-4.12/arm-rtems4.12/bin/ -B/opt/rtems-4.12/arm-rtems4.12/lib/ -isystem /opt/rtems-4.12/arm-rtems4.12/include -isystem /opt/rtems-4.12/arm-rtems4.12/sys-include -mthumb -march=armv6-m -DHAVE_CONFIG_H -I/home/EB/sebastian_h/archive/gcc-git/libatomic/config/arm -I/home/EB/sebastian_h/archive/gcc-git/libatomic/config/rtems -I/home/EB/sebastian_h/archive/gcc-git/libatomic -I. -Wall -Werror -g -O2 -fno-sync-libcalls -fno-sync-libcalls -MT exch_1_.lo -MD -MP -MF .deps/exch_1_.lo.Ppo -DN=1 -c /home/EB/sebastian_h/archive/gcc-git/libatomic/config/arm/exch_n.c -o exch_1_.o /tmp/ccrU82YJ.s: Assembler messages: /tmp/ccrU82YJ.s:58: Error: selected processor does not support `uadd8 r3,r3,r3' in Thumb mode /tmp/ccrU82YJ.s:59: Error: selected processor does not support `ldrex r2,[r0]' in Thumb mode /tmp/ccrU82YJ.s:60: Error: selected processor does not support `sel r3,r1,r2' in Thumb mode /tmp/ccrU82YJ.s:61: Error: selected processor does not support `strex r5,r3,[r0]' in Thumb mode In "libatomic/config/arm/arm-config.h" we have: #if __ARM_ARCH__ >= 7 || defined(__ARM_ARCH_6K__) || defined(__ARM_ARCH_6ZK__) # define HAVE_STREX1 # define HAVE_STREXBHD1 #elif __ARM_ARCH__ == 6 # define HAVE_STREX1 #endif Is there a particular reason why this file uses __ARM_ARCH_* and not directly __ARM_FEATURE_LDREX? The following patch would fix the build problem: diff --git a/libatomic/config/arm/arm-config.h b/libatomic/config/arm/arm-config.h index 19331e3..79f422f 100644 --- a/libatomic/config/arm/arm-config.h +++ b/libatomic/config/arm/arm-config.h @@ -68,7 +68,7 @@ #if __ARM_ARCH__ >= 7 || defined(__ARM_ARCH_6K__) || defined(__ARM_ARCH_6ZK__) # define HAVE_STREX1 # define HAVE_STREXBHD 1 -#elif __ARM_ARCH__ == 6 +#elif __ARM_ARCH__ == 6 && !defined(__ARM_ARCH_6M__) # define HAVE_STREX1 #endif -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
Re: libatomic on ARM
On 19/04/16 10:52, Sebastian Huber wrote: Hello, I tried to build the libatomic for RTEMS on ARM and I got this error: make[2]: Entering directory `/build/git-build/b-gcc-git-arm-rtems4.12/arm-rtems4.12/thumb/armv6-m/libatomic' /bin/sh ./libtool --tag=CC --mode=compile /build/git-build/b-gcc-git-arm-rtems4.12/./gcc/xgcc -B/build/git-build/b-gcc-git-arm-rtems4.12/./gcc/ -nostdinc -B/build/git-build/b-gcc-git-arm-rtems4.12/arm-rtems4.12/thumb/armv6-m/newlib/ -isystem /build/git-build/b-gcc-git-arm-rtems4.12/arm-rtems4.12/thumb/armv6-m/newlib/targ-include -isystem /home/EB/sebastian_h/archive/gcc-git/newlib/libc/include -B/opt/rtems-4.12/arm-rtems4.12/bin/ -B/opt/rtems-4.12/arm-rtems4.12/lib/ -isystem /opt/rtems-4.12/arm-rtems4.12/include -isystem /opt/rtems-4.12/arm-rtems4.12/sys-include -mthumb -march=armv6-m -DHAVE_CONFIG_H -I/home/EB/sebastian_h/archive/gcc-git/libatomic/config/arm -I/home/EB/sebastian_h/archive/gcc-git/libatomic/config/rtems -I/home/EB/sebastian_h/archive/gcc-git/libatomic -I.-Wall -Werror -g -O2 -fno-sync-libcalls -fno-sync-libcalls -MT exch_1_.lo -MD -MP -MF .deps/exch_1_.lo.Ppo -DN=1 -c -o exch_1_.lo /home/EB/sebastian_h/archive/gcc-git/libatomic/config/arm/exch_n.c libtool: compile: /build/git-build/b-gcc-git-arm-rtems4.12/./gcc/xgcc -B/build/git-build/b-gcc-git-arm-rtems4.12/./gcc/ -nostdinc -B/build/git-build/b-gcc-git-arm-rtems4.12/arm-rtems4.12/thumb/armv6-m/newlib/ -isystem /build/git-build/b-gcc-git-arm-rtems4.12/arm-rtems4.12/thumb/armv6-m/newlib/targ-include -isystem /home/EB/sebastian_h/archive/gcc-git/newlib/libc/include -B/opt/rtems-4.12/arm-rtems4.12/bin/ -B/opt/rtems-4.12/arm-rtems4.12/lib/ -isystem /opt/rtems-4.12/arm-rtems4.12/include -isystem /opt/rtems-4.12/arm-rtems4.12/sys-include -mthumb -march=armv6-m -DHAVE_CONFIG_H -I/home/EB/sebastian_h/archive/gcc-git/libatomic/config/arm -I/home/EB/sebastian_h/archive/gcc-git/libatomic/config/rtems -I/home/EB/sebastian_h/archive/gcc-git/libatomic -I. -Wall -Werror -g -O2 -fno-sync-libcalls -fno-sync-libcalls -MT exch_1_.lo -MD -MP -MF .deps/exch_1_.lo.Ppo -DN=1 -c /home/EB/sebastian_h/archive/gcc-git/libatomic/config/arm/exch_n.c -o exch_1_.o /tmp/ccrU82YJ.s: Assembler messages: /tmp/ccrU82YJ.s:58: Error: selected processor does not support `uadd8 r3,r3,r3' in Thumb mode /tmp/ccrU82YJ.s:59: Error: selected processor does not support `ldrex r2,[r0]' in Thumb mode /tmp/ccrU82YJ.s:60: Error: selected processor does not support `sel r3,r1,r2' in Thumb mode /tmp/ccrU82YJ.s:61: Error: selected processor does not support `strex r5,r3,[r0]' in Thumb mode In "libatomic/config/arm/arm-config.h" we have: #if __ARM_ARCH__ >= 7 || defined(__ARM_ARCH_6K__) || defined(__ARM_ARCH_6ZK__) # define HAVE_STREX1 # define HAVE_STREXBHD1 #elif __ARM_ARCH__ == 6 # define HAVE_STREX1 #endif Is there a particular reason why this file uses __ARM_ARCH_* and not directly __ARM_FEATURE_LDREX? The following patch would fix the build problem: diff --git a/libatomic/config/arm/arm-config.h b/libatomic/config/arm/arm-config.h index 19331e3..79f422f 100644 --- a/libatomic/config/arm/arm-config.h +++ b/libatomic/config/arm/arm-config.h @@ -68,7 +68,7 @@ #if __ARM_ARCH__ >= 7 || defined(__ARM_ARCH_6K__) || defined(__ARM_ARCH_6ZK__) # define HAVE_STREX1 # define HAVE_STREXBHD 1 -#elif __ARM_ARCH__ == 6 +#elif __ARM_ARCH__ == 6 && !defined(__ARM_ARCH_6M__) # define HAVE_STREX1 #endif Next error: /build/git-build/b-gcc-git-arm-rtems4.12/./gcc/xgcc -B/build/git-build/b-gcc-git-arm-rtems4.12/./gcc/ -nostdinc -B/build/git-build/b-gcc-git-arm-rtems4.12/arm-rtems4.12/newlib/ -isystem /build/git-build/b-gcc-git-arm-rtems4.12/arm-rtems4.12/newlib/targ-include -isystem /home/EB/sebastian_h/archive/gcc-git/newlib/libc/include -B/opt/rtems-4.12/arm-rtems4.12/bin/ -B/opt/rtems-4.12/arm-rtems4.12/lib/ -isystem /opt/rtems-4.12/arm-rtems4.12/include -isystem /opt/rtems-4.12/arm-rtems4.12/sys-include -DHAVE_CONFIG_H -I/home/EB/sebastian_h/archive/gcc-git/libatomic/config/arm -I/home/EB/sebastian_h/archive/gcc-git/libatomic/config/rtems -I/home/EB/sebastian_h/archive/gcc-git/libatomic -I. -Wall -Werror -g -O2 -mthumb -march=armv7-m -MT tas_1_.lo -MD -MP -MF .deps/tas_1_.lo.Ppo -DN=1 -c /home/EB/sebastian_h/archive/gcc-git/libatomic/tas_n.c -o tas_1_.o /tmp/cc0LN4Eh.s: Assembler messages: /tmp/cc0LN4Eh.s:58: Error: selected processor does not support `uadd8 r3,r3,r3' in Thumb mode /tmp/cc0LN4Eh.s:60: Error: selected processor does not support `sel r3,r1,r4' in Thumb mode -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
const volatile behaviour change in GCC 7
Hello,
for RTEMS we use linker sets to initialize the system. The following
code worked up to GCC 6, but no longer in GCC 7:
typedef void ( *rtems_sysinit_handler )( void );
typedef struct {
rtems_sysinit_handler handler;
} rtems_sysinit_item;
rtems_sysinit_item volatile const _Linker_set__Sysinit_begin[0]
__attribute__((__section__(".rtemsroset." "_Sysinit" ".begin")))
__attribute__((__used__));
rtems_sysinit_item volatile const _Linker_set__Sysinit_end[0]
__attribute__((__section__(".rtemsroset." "_Sysinit" ".end")))
__attribute__((__used__));
void rtems_initialize_executive(void)
{
const volatile rtems_sysinit_item *cur = _Linker_set__Sysinit_begin;
const volatile rtems_sysinit_item *end = _Linker_set__Sysinit_end;
while ( cur != end ) {
( *cur->handler )();
++cur;
}
}
The corresponding GNU ld linker script section is:
.rtemsroset : ALIGN_WITH_INPUT {
KEEP (*(SORT(.rtemsroset.*)))
} > REGION_RODATA AT > REGION_RODATA_LOAD
In GCC 7, the compiler deduces that "cur != end" is always true and
generates an infinite loop.
Up to GCC 6 the "volatile const" seemed to prevent this optimization. I
know that this linker set stuff is quite non-standard, but is there a
way to get this to work again on GCC 7?
The nice thing with the "type volatile const X[0]..." construct is that
you can generate arbitrary linker sets via it without a need to edit the
linker command file and with no storage overhead.
--
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
Re: const volatile behaviour change in GCC 7
On 22/09/16 14:11, Sergey Organov wrote:
Sebastian Huber writes:
Hello,
for RTEMS we use linker sets to initialize the system. The following
code worked up to GCC 6, but no longer in GCC 7:
typedef void ( *rtems_sysinit_handler )( void );
typedef struct {
rtems_sysinit_handler handler;
} rtems_sysinit_item;
rtems_sysinit_item volatile const _Linker_set__Sysinit_begin[0]
__attribute__((__section__(".rtemsroset." "_Sysinit" ".begin")))
__attribute__((__used__));
rtems_sysinit_item volatile const _Linker_set__Sysinit_end[0]
__attribute__((__section__(".rtemsroset." "_Sysinit" ".end")))
__attribute__((__used__));
void rtems_initialize_executive(void)
{
const volatile rtems_sysinit_item *cur = _Linker_set__Sysinit_begin;
const volatile rtems_sysinit_item *end = _Linker_set__Sysinit_end;
You likely have 'volatile' in a wrong place. Try (untested):
rtems_sysinit_item const _Linker_set__Sysinit_begin[0]
__attribute__((__section__(".rtemsroset." "_Sysinit" ".begin")))
__attribute__((__used__));
rtems_sysinit_item const _Linker_set__Sysinit_end[0]
__attribute__((__section__(".rtemsroset." "_Sysinit" ".end")))
__attribute__((__used__));
void rtems_initialize_executive(void)
{
rtems_sysinit_item const *volatile cur = _Linker_set__Sysinit_begin;
rtems_sysinit_item const *volatile end = _Linker_set__Sysinit_end;
while(cur != end) {
cur->handler();
++cur;
}
}
No, I don't want to load/store the pointers from/to memory all the time
in this loop.
Alternatively, try (untested, and I removed attributes to make my point
clearer):
/* Linker-defined symbols */
rtems_sysinit_item const _Linker_set__Sysinit_begin[0]
__attribute__((__section__(".rtemsroset." "_Sysinit" ".begin")))
__attribute__((__used__));
rtems_sysinit_item const _Linker_set__Sysinit_end[0]
__attribute__((__section__(".rtemsroset." "_Sysinit" ".end")))
__attribute__((__used__));
/* Get volatile pointers to the above */
static rtems_sysinit_item const *volatile begin_ = _Linker_set__Sysinit_begin;
static rtems_sysinit_item const *volatile end_ = _Linker_set__Sysinit_end;
void rtems_initialize_executive(void)
{
rtems_sysinit_item const *cur = begin_;
rtems_sysinit_item const *end = end_;
while(cur != end) {
cur->handler();
++cur;
}
}
I don't want any storage for these begin/end markers.
--
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
[libgomp] No references to env.c -> no libgomp construction
Hello,
after a recent change:
commit 44a69dfd2c96110643d05176803c984a080b696b
Author: amonakov
Date: Wed Nov 23 18:36:41 2016 +
OpenMP offloading to NVPTX: libgomp changes
* Makefile.am (libgomp_la_SOURCES): Add atomic.c, icv.c, icv-device.c.
* Makefile.in. Regenerate.
* configure.ac [nvptx*-*-*] (libgomp_use_pthreads): Set and use it...
(LIBGOMP_USE_PTHREADS): ...here; new define.
* configure: Regenerate.
* config.h.in: Likewise.
* config/posix/affinity.c: Move to...
* affinity.c: ...here (new file). Guard use of Pthreads-specific
interface by LIBGOMP_USE_PTHREADS.
* critical.c: Split out GOMP_atomic_{start,end} into...
* atomic.c: ...here (new file).
* env.c: Split out ICV definitions into...
* icv.c: ...here (new file) and...
* icv-device.c: ...here. New file.
the env.c contains now only local symbols (at least for target *-rtems*-*):
nm --defined-only ./arm-rtems4.12/libgomp/env.o
08d8 t initialize_env
d kinds.9043
t parse_boolean
0880 t parse_int.constprop.4
032c t parse_one_place
01a0 t parse_stacksize
00c4 t parse_unsigned_long
Thus the libgomp constructor is not linked in into executables.
--
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail : sebastian.huber at embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
Re: [libgomp] No references to env.c -> no libgomp construction
- Alexander Monakov schrieb: > Hello, > > On Tue, 29 Nov 2016, Sebastian Huber wrote: > > * env.c: Split out ICV definitions into... > > * icv.c: ...here (new file) and... > > * icv-device.c: ...here. New file. > > > > the env.c contains now only local symbols (at least for target *-rtems*-*): > > > [...] > > > > Thus the libgomp constructor is not linked in into executables. > > Thanks for the report. This issue affects only static libgomp.a (and not on > NVPTX where env.c is deliberately empty). > > I think the minimal solution here is to #include from icv.c instead of > compiling it separately (using <> inclusion rather than "" so in case of NVPTX > we pick up the empty config/nvptx/env.c from toplevel icv.c). > > A slightly more involved but perhaps a preferable approach is to remove > config/nvptx/env.c, introduce LIBGOMP_OFFLOADED_ONLY macro, and use it to > guard inclusion of env.c from icv.c (which then can use the #include "env.c" > form). I guess its sufficient to move pthread_attr_t gomp_thread_attr; from team.c (NVPTX seems to provide its own team.c) to env.c. This generates a reference from team.c to env.c and the constructor is pulled in. -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.huber at embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
Bug in gcc.c for_each_path() (leads to invalid crt0.o selection)?
/ -B/opt/rtems-4.12/arm-rtems4.12/lib/ Its not really clear from the documentation how the search order and command line order is related. The documentation doesn't mention multilib and multiarch options. https://gcc.gnu.org/onlinedocs/gcc/Directory-Options.html If we assume that the command line order determines the search order, then its not clear why for_each_path() first iterates for all paths with the multilib postfix and then without. Shouldn't it iterate over all paths and check with/without multilib postfix in each step? -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list de...@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Bug in gcc.c for_each_path() (leads to invalid crt0.o selection)?
Hallo Joseph,
On 05/12/16 23:02, Joseph Myers wrote:
On Mon, 5 Dec 2016, Sebastian Huber wrote:
If we assume that the command line order determines the search order, then its
not clear why for_each_path() first iterates for all paths with the multilib
postfix and then without. Shouldn't it iterate over all paths and check
with/without multilib postfix in each step?
No. The directory without the multilib postfix is generally the directory
for another multilib, i.e. always wrong to search, and in case the library
appears earlier in the non-multilib directories than the multilib ones,
mixing the search paths (and there may already be some unwanted mixing
when sysroots are involved) would result in the wrong library being
chosen.
Unfortunately, getting rid of the search of non-multilib directories
completely is hard. It was removed in r96915
<https://gcc.gnu.org/ml/gcc-patches/2004-11/msg01895.html>. Then this was
reverted in <https://gcc.gnu.org/ml/gcc-patches/2005-12/msg00818.html>.
Furthermore, it turns out there is a case where the existing multilib
configuration machinery cannot express things correctly without searching
non-multilib directories. Specifically, consider the combination of
MULTILIB_OSDIRNAMES with sysroot suffixes. This is used by
config/mips/{t-mti-linux,mti-linux.h}, for example.
MULTILIB_OSDIRNAMES provides directory names used in two ways: relative to
$target/lib/ in the GCC installation, and relative to lib/ and usr/lib/ in
a sysroot. For the latter, we want names such as plain ../lib64, but
these cannot be used outside the sysroot because different multilibs would
be mapped to the same directory. The solution to this issue relies on
searches without multilib suffixes: you define STARTFILE_PREFIX_SPEC
(which used to be used more widely before MULTILIB_OSDIRNAMES was added in
the first place) so sysroot libraries can be found by the combination of
(sysroot, sysroot suffix, startfile prefix, *no* multilib suffix).
So while this case of MULTILIB_OSDIRNAMES with multiple sysroots makes it
hard to eliminate the search of non-multilib directories, they should be
searched as late as possible to reduce the risk of problems from the wrong
libraries being found.
thanks for the detailed explanation. I guess, then the root cause for my
problem is that the Newlib provided crt0.o files in the build tree are
not in the same relative location of the installation tree. In the build
tree, they reside in a "newlib" subdirectory. I changed the Newlib build
flags set by GCC to use -L instead of -B and this seems to work (comment
is wrong now). Does it make sense to submit such a patch or has it maybe
some nasty side-effects?
diff --git a/configure b/configure
index b6389e4..3c84acb 100755
--- a/configure
+++ b/configure
@@ -7497,7 +7497,7 @@ case " $target_configdirs " in
# If we're building newlib, use its generic headers last, but search
# for any libc-related directories first (so make it the last -B
# switch).
- FLAGS_FOR_TARGET=$FLAGS_FOR_TARGET'
-B$$r/$(TARGET_SUBDIR)/newlib/ -isystem
$$r/$(TARGET_SUBDIR)/newlib/targ-include -isystem $$s/newlib/libc/include'
+ FLAGS_FOR_TARGET=$FLAGS_FOR_TARGET'
-L$$r/$(TARGET_SUBDIR)/newlib/ -isystem
$$r/$(TARGET_SUBDIR)/newlib/targ-include -isystem $$s/newlib/libc/include'
# If we're building libgloss, find the startup file, simulator
library
# and linker script.
diff --git a/configure.ac b/configure.ac
index 51ee705..ca6fb88 100644
--- a/configure.ac
+++ b/configure.ac
@@ -3086,7 +3086,7 @@ case " $target_configdirs " in
# If we're building newlib, use its generic headers last, but search
# for any libc-related directories first (so make it the last -B
# switch).
- FLAGS_FOR_TARGET=$FLAGS_FOR_TARGET'
-B$$r/$(TARGET_SUBDIR)/newlib/ -isystem
$$r/$(TARGET_SUBDIR)/newlib/targ-include -isystem $$s/newlib/libc/include'
+ FLAGS_FOR_TARGET=$FLAGS_FOR_TARGET'
-L$$r/$(TARGET_SUBDIR)/newlib/ -isystem
$$r/$(TARGET_SUBDIR)/newlib/targ-include -isystem $$s/newlib/libc/include'
# If we're building libgloss, find the startup file, simulator
library
# and linker script.
diff --git a/gcc/Makefile.in b/gcc/Makefile.in
index c7b1eaf..9e8dea1 100644
--- a/gcc/Makefile.in
+++ b/gcc/Makefile.in
@@ -3809,7 +3809,7 @@ site.exp: ./config.status Makefile
@if [ -d $(objdir)/../$(target_subdir)/newlib ] \
&& [ "${host}" != "${target}" ]; then \
echo "set newlib_cflags
\"-I$(objdir)/../$(target_subdir)/newlib/targ-include
-I\$$srcdir/../newlib/libc/include\"" >> ./site.tmp; \
- echo "set newlib_ldflags
\"-B$(objdir)/../$(target_subdir)/newlib/\"" >> ./site.tmp; \
+ echo "set newlib_ldflags
\"-L$(objdir)/../$(target_subd
Re: Bug in gcc.c for_each_path() (leads to invalid crt0.o selection)?
On 06/12/16 18:09, Joseph Myers wrote: On Tue, 6 Dec 2016, Sebastian Huber wrote: thanks for the detailed explanation. I guess, then the root cause for my problem is that the Newlib provided crt0.o files in the build tree are not in the same relative location of the installation tree. In the build tree, they reside in a "newlib" subdirectory. I changed the Newlib build flags set by GCC to use -L instead of -B and this seems to work (comment is wrong now). Does it make sense to submit such a patch or has it maybe some nasty side-effects? I don't know what the effects of such a change might be. Using -L instead of -B had the same problems. My attempt to fix this problem is this patch: https://sourceware.org/ml/newlib/2016/msg01145.html -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
Re: Add stdatomic.h
Hello, I test currently the GCC 4.9 release branch. Should work with C++? I use GCC as a cross-compiler for RTEMS targets. RTEMS uses Newlib as C library. I ported the FreeBSD version of to Newlib and use this successfully with C/C++ and GCC pre-4.9 versions. Now with GCC 4.9 I have the problem that two files are installed, e.g. find /opt/rtems-4.11/ -name stdatomic.h /opt/rtems-4.11/lib64/gcc/sparc-rtems4.11/4.9.0/include/stdatomic.h /opt/rtems-4.11/sparc-rtems4.11/include/stdatomic.h The first is provided by GCC, the second by Newlib. The GCC version is the one used. Now I get this when I compile a C++ source which indirectly includes : sparc-rtems4.11-g++ -std=c++11 somefile.cc /opt/rtems-4.11/lib64/gcc/sparc-rtems4.11/4.9.0/include/stdatomic.h:40:9: error: '_Atomic' does not name a type typedef _Atomic _Bool atomic_bool; Is this working as intended? -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
Re: GCC 4.9.0 Released
The Git mirror seems to have no gcc-4_9_0-release tag. -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
SPARC LEON3 and CAS instruction
Hello, recent GCC versions support the C11 atomic operations for the SPARC LEON3 processor via the CASA instruction. GCC emits CASA instructions with an ASI of 0x80. I think this is due to the usage of "cas" if I get the stuff in sync.md right: "(define_insn "*atomic_compare_and_swap_1" [(set (match_operand:I48MODE 0 "register_operand" "=r") (match_operand:I48MODE 1 "mem_noofs_operand" "+w")) (set (match_dup 1) (unspec_volatile:I48MODE [(match_operand:I48MODE 2 "register_operand" "r") (match_operand:I48MODE 3 "register_operand" "0")] UNSPECV_CAS))] "(TARGET_V9 || TARGET_LEON3) && (mode != DImode || TARGET_ARCH64)" "cas\t%1, %2, %0" [(set_attr "type" "multi")])" According to the LEON3 manual we have: "6.2.7 Compare and Swap instruction (CASA) LEON4 implements the SPARC V9 Compare and Swap Alternative (CASA) instruction. The CASA operates as described in the SPARC V9 manual. The instruction is privileged, except when setting ASI = 0xA (user data)." I would like to use atomic operations in user mode. Is it possible to add a machine option to GCC to use an ASI of 0x0A for the atomic operations via CASA on LEON3? -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
Write test case for libstdc++ with C source
Hallo,
I would like to add a test case to the libstdc++ tests to test for C/C++
compatibility of the atomic operations. A straight forward approach
like in the attached patch doesn't work since the
"dg-additional-sources" is not supported:
ERROR: 29_atomics/atomic/pr60932-c++.cc: unknown dg option:
dg-additional-sources 3 pr60932-c.c for " dg-additional-sources 3
"pr60932-c.c" "
UNRESOLVED: 29_atomics/atomic/pr60932-c++.cc: unknown dg option:
dg-additional-sources 3 pr60932-c.c for " dg-additional-sources 3
"pr60932-c.c" "
Since I am not an expert in the GCC test suite scripts, is it possible
to add such a test case at all with a moderate amount of work?
--
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>From 34a2fd03ffdd06c214c62a3490ab720c6c65fa9e Mon Sep 17 00:00:00 2001
From: Sebastian Huber
Date: Sun, 27 Apr 2014 14:08:19 +0200
Subject: [PATCH] PR60932 test case
---
libstdc++-v3/testsuite/29_atomics/atomic/pr60932-c++.cc | 10 ++
libstdc++-v3/testsuite/29_atomics/atomic/pr60932-c.c| 4
libstdc++-v3/testsuite/29_atomics/atomic/pr60932.h | 6 ++
3 files changed, 20 insertions(+)
create mode 100644 libstdc++-v3/testsuite/29_atomics/atomic/pr60932-c++.cc
create mode 100644 libstdc++-v3/testsuite/29_atomics/atomic/pr60932-c.c
create mode 100644 libstdc++-v3/testsuite/29_atomics/atomic/pr60932.h
diff --git a/libstdc++-v3/testsuite/29_atomics/atomic/pr60932-c++.cc b/libstdc++-v3/testsuite/29_atomics/atomic/pr60932-c++.cc
new file mode 100644
index 000..a26f96a
--- /dev/null
+++ b/libstdc++-v3/testsuite/29_atomics/atomic/pr60932-c++.cc
@@ -0,0 +1,10 @@
+// { dg-do link }
+// { dg-options "-std=c++11" }
+// { dg-additional-sources "pr60932-c.c" }
+
+#include "pr60932.h"
+
+int main()
+{
+ return 0;
+}
diff --git a/libstdc++-v3/testsuite/29_atomics/atomic/pr60932-c.c b/libstdc++-v3/testsuite/29_atomics/atomic/pr60932-c.c
new file mode 100644
index 000..9e69a62
--- /dev/null
+++ b/libstdc++-v3/testsuite/29_atomics/atomic/pr60932-c.c
@@ -0,0 +1,4 @@
+// { dg-do compile }
+// { dg-options "-x c -std=c11" }
+
+#include "pr60932.h"
diff --git a/libstdc++-v3/testsuite/29_atomics/atomic/pr60932.h b/libstdc++-v3/testsuite/29_atomics/atomic/pr60932.h
new file mode 100644
index 000..c92cbd8
--- /dev/null
+++ b/libstdc++-v3/testsuite/29_atomics/atomic/pr60932.h
@@ -0,0 +1,6 @@
+#ifdef __cplusplus
+#include
+using namespace std;
+#else
+#include
+#endif
--
1.8.1.4
Re: Write test case for libstdc++ with C source
On 04/27/2014 03:25 PM, Andreas Schwab wrote:
Sebastian Huber writes:
Since I am not an expert in the GCC test suite scripts, is it possible to
add such a test case at all with a moderate amount of work?
Just add load_gcc_lib gcc-defs.exp.
In libstdc++-v3/testsuite/lib/libstdc++.exp? In this case I get:
ERROR: Couldn't find library file target-libpath.exp.
We have in gcc-defs.exp:
load_lib target-libpath.exp
load_lib wrapper.exp
These files are also loaded in libstdc++.exp via:
proc load_gcc_lib { filename } {
global srcdir
load_file $srcdir/../../gcc/testsuite/lib/$filename
}
[...]
load_gcc_lib target-libpath.exp
[...]
load_gcc_lib wrapper.exp
Luckily the target-libpath.exp and wrapper.exp don't use load_lib, so
they cause no problems. Is it possible to add a search path to
something and avoid this load_gcc_lib?
--
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
Re: SPARC LEON3 and CAS instruction
On 2014-04-25 18:31, Eric Botcazou wrote: recent GCC versions support the C11 atomic operations for the SPARC LEON3 processor via the CASA instruction. GCC emits CASA instructions with an ASI of 0x80. I think this is due to the usage of "cas" if I get the stuff in sync.md right: "(define_insn "*atomic_compare_and_swap_1" [(set (match_operand:I48MODE 0 "register_operand" "=r") (match_operand:I48MODE 1 "mem_noofs_operand" "+w")) (set (match_dup 1) (unspec_volatile:I48MODE [(match_operand:I48MODE 2 "register_operand" "r") (match_operand:I48MODE 3 "register_operand" "0")] UNSPECV_CAS))] "(TARGET_V9 || TARGET_LEON3) && (mode != DImode || TARGET_ARCH64)" "cas\t%1, %2, %0" [(set_attr "type" "multi")])" Right, this is a bug, both in the compiler and the assembler, since an ASI of 0x80 is not allowed for SPARC-V8. Ok, I didn't notice this before since it worked well on the LEON4FT in supervisor mode. I work currently with the XtratuM hypervisor and noticed this problem with CAS in user mode. According to the LEON3 manual we have: "6.2.7 Compare and Swap instruction (CASA) LEON4 implements the SPARC V9 Compare and Swap Alternative (CASA) instruction. The CASA operates as described in the SPARC V9 manual. The instruction is privileged, except when setting ASI = 0xA (user data)." I would like to use atomic operations in user mode. Is it possible to add a machine option to GCC to use an ASI of 0x0A for the atomic operations via CASA on LEON3? Yes, I guess we actually want to emit an ASI of either 0xA (user data) or 0xB (supervisor data), predicated on -muser-mode. I'll prepare a patch. Thanks, since this -muser-mode seems to be something new, maybe we should instead use -mcas=supervisor|user to make it more specific? -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
Re: SPARC LEON3 and CAS instruction
On 2014-04-28 10:02, Eric Botcazou wrote: Thanks, since this -muser-mode seems to be something new, maybe we should >instead use -mcas=supervisor|user to make it more specific? I don't think so, we might need to extend its purview in the future. Ok, this makes sense. Which default to you have in mind for the -muser-mode option? -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
Re: SPARC LEON3 and CAS instruction
On 2014-04-28 10:14, Eric Botcazou wrote: Ok, this makes sense. Which default to you have in mind for the -muser-mode >option? -mno-user-mode the default, it's usually what's done in this case I think. I think its more natural to generate user-space code by default. -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
Re: PowerPC builds broken on 4.9 and trunk
On 05/26/2014 09:40 PM, Sandra Loosemore wrote: as reported in PR60102. I'd really hope this could be fixed for 4.9.1 but I'm not sure the relevant people are paying much attention to the issue. Can we at least update the priority/severity of the bug so that it's more likely to show up on the radar? I did look at trying to fix this myself but I think someone who already has some state on this back end is more likely to come up with an acceptable solution. -Sandra I think the main problem is that Freescale abandoned support for the FSF Binutils and GCC. It seems that the Freescale specific PowerPC parts like e500/SPE are in bit rot mode. Here is a list of some bugs in that area: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60950 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60818 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60102 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57816 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57717 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57389 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47856 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47751 -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
Re: Write test case for libstdc++ with C source
On 04/27/2014 03:01 PM, Sebastian Huber wrote: Hallo, I would like to add a test case to the libstdc++ tests to test for C/C++ compatibility of the atomic operations. A straight forward approach like in the attached patch doesn't work since the "dg-additional-sources" is not supported: ERROR: 29_atomics/atomic/pr60932-c++.cc: unknown dg option: dg-additional-sources 3 pr60932-c.c for " dg-additional-sources 3 "pr60932-c.c" " UNRESOLVED: 29_atomics/atomic/pr60932-c++.cc: unknown dg option: dg-additional-sources 3 pr60932-c.c for " dg-additional-sources 3 "pr60932-c.c" " Since I am not an expert in the GCC test suite scripts, is it possible to add such a test case at all with a moderate amount of work? Since this patch 2014-05-20 Sebastian Huber * testsuite/lib/libstdc++.exp (load_gcc_lib): Register loaded libs. I am one step further. The dg-additional-sources is recognized in the attached test case, but it seems to have no effect: Executing on host: /home/sh/git-build/b-gcc-devel-linux/./gcc/xg++ -shared-libgcc -B/home/sh/git-build/b-gcc-devel-linux/./gcc -nostdinc++ -L/home/sh/git-build/b-gcc-devel-linux/x86_64-unknown-linux-gnu/libstdc++-v3/src -L/home/sh/git-build/b-gcc-devel-linux/x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs -L/home/sh/git-build/b-gcc-devel-linux/x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -B/scratch/install-gcc-devel/x86_64-unknown-linux-gnu/bin/ -B/scratch/install-gcc-devel/x86_64-unknown-linux-gnu/lib/ -isystem /scratch/install-gcc-devel/x86_64-unknown-linux-gnu/include -isystem /scratch/install-gcc-devel/x86_64-unknown-linux-gnu/sys-include -B/home/sh/git-build/b-gcc-devel-linux/x86_64-unknown-linux-gnu/./libstdc++-v3/src/.libs -fdiagnostics-color=never -D_GLIBCXX_ASSERT -fmessage-length=0 -ffunction-sections -fdata-sections -g -O2 -DLOCALEDIR="." -nostdinc++ -I/home/sh/git-build/b-gcc-devel-linux/x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu -I/home/sh/git-build/b-gcc-devel-linux/x86_64-unknown-linux-gnu/libstdc++-v3/include -I/home/sh/archive/gcc-devel/libstdc++-v3/libsupc++ -I/home/sh/archive/gcc-devel/libstdc++-v3/include/backward -I/home/sh/archive/gcc-devel/libstdc++-v3/testsuite/util /home/sh/archive/gcc-devel/libstdc++-v3/testsuite/29_atomics/atomic/pr60932-c++.cc -std=c++11 ./libtestc++.a -Wl,--gc-sections -lm -o ./pr60932-c++.exe(timeout = 600) spawn /home/sh/git-build/b-gcc-devel-linux/./gcc/xg++ -shared-libgcc -B/home/sh/git-build/b-gcc-devel-linux/./gcc -nostdinc++ -L/home/sh/git-build/b-gcc-devel-linux/x86_64-unknown-linux-gnu/libstdc++-v3/src -L/home/sh/git-build/b-gcc-devel-linux/x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs -L/home/sh/git-build/b-gcc-devel-linux/x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -B/scratch/install-gcc-devel/x86_64-unknown-linux-gnu/bin/ -B/scratch/install-gcc-devel/x86_64-unknown-linux-gnu/lib/ -isystem /scratch/install-gcc-devel/x86_64-unknown-linux-gnu/include -isystem /scratch/install-gcc-devel/x86_64-unknown-linux-gnu/sys-include -B/home/sh/git-build/b-gcc-devel-linux/x86_64-unknown-linux-gnu/./libstdc++-v3/src/.libs -fdiagnostics-color=never -D_GLIBCXX_ASSERT -fmessage-length=0 -ffunction-sections -fdata-sections -g -O2 -DLOCALEDIR="." -nostdinc++ -I/home/sh/git-build/b-gcc-devel-linux/x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu -I/home/sh/git-build/b-gcc-devel-linux/x86_64-unknown-linux-gnu/libstdc++-v3/include -I/home/sh/archive/gcc-devel/libstdc++-v3/libsupc++ -I/home/sh/archive/gcc-devel/libstdc++-v3/include/backward -I/home/sh/archive/gcc-devel/libstdc++-v3/testsuite/util /home/sh/archive/gcc-devel/libstdc++-v3/testsuite/29_atomics/atomic/pr60932-c++.cc -std=c++11 ./libtestc++.a -Wl,--gc-sections -lm -o ./pr60932-c++.exe /tmp/ccN0vuIk.o: In function `main': /home/sh/archive/gcc-devel/libstdc++-v3/testsuite/29_atomics/atomic/pr60932-c++.cc:12: undefined reference to `i' collect2: error: ld returned 1 exit status compiler exited with status 1 output is: /tmp/ccN0vuIk.o: In function `main': /home/sh/archive/gcc-devel/libstdc++-v3/testsuite/29_atomics/atomic/pr60932-c++.cc:12: undefined reference to `i' collect2: error: ld returned 1 exit status FAIL: 29_atomics/atomic/pr60932-c++.cc (test for excess errors) Excess errors: /home/sh/archive/gcc-devel/libstdc++-v3/testsuite/29_atomics/atomic/pr60932-c++.cc:12: undefined reference to `i' collect2: error: ld returned 1 exit status extra_tool_flags are: -x c -std=c11 compiling and executing as C, not C++ Executing on host: /home/sh/git-build/b-gcc-devel-linux/./gcc/xgcc -B/home/sh/git-build/b-gcc-devel-linux/./gcc/ -B/scratch/install-gcc-devel/x86_64-unknown-linux-gnu/bin/ -B/scratch/install-gcc-devel/x86_64-unknown-linux-gnu/lib/ -isystem /scratch/install-gcc-devel/x86_64-unknown-linux-gnu/include -isystem /scratch/i
stdatomic.h and atomic_load_explicit()
Hello,
GCC provides its own version of stdatomic.h since GCC 4.9. Here we have:
#define atomic_load_explicit(PTR, MO) \
__extension__ \
({\
__auto_type __atomic_load_ptr = (PTR); \
__typeof__ (*__atomic_load_ptr) __atomic_load_tmp; \
__atomic_load (__atomic_load_ptr, &__atomic_load_tmp, (MO));\
__atomic_load_tmp; \
})
According to
http://en.cppreference.com/w/c/atomic/atomic_load
(or in the standard "7.17.7.2 The atomic_load generic functions") we have
C atomic_load_explicit( volatile A* obj, memory_order order );
This test case
#include
int ld(volatile atomic_int *i)
{
return atomic_load_explicit(i, memory_order_relaxed);
}
yields on ARM
arm-rtems4.11-gcc -march=armv7-a -O2 test.c -S && cat test.s
.arch armv7-a
.fpu softvfp
.eabi_attribute 20, 1
.eabi_attribute 21, 1
.eabi_attribute 23, 3
.eabi_attribute 24, 1
.eabi_attribute 25, 1
.eabi_attribute 26, 1
.eabi_attribute 30, 2
.eabi_attribute 34, 1
.eabi_attribute 18, 4
.file "test.c"
.text
.align 2
.global ld
.type ld, %function
ld:
@ args = 0, pretend = 0, frame = 8
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
ldr r3, [r0]
sub sp, sp, #8
str r3, [sp, #4]
ldr r0, [sp, #4]
add sp, sp, #8
@ sp needed
bx lr
.size ld, .-ld
.ident "GCC: (GNU) 4.9.1 20140515 (prerelease)
I think the inheritance of the volatile qualifier via __typeof__
(*__atomic_load_ptr) is an implementation flaw.
With the FreeBSD version of I don't have this problem:
http://svnweb.freebsd.org/base/head/include/stdatomic.h?revision=234958&view=markup&pathrev=234958#l231
--
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
Re: stdatomic.h and atomic_load_explicit()
On 2014-06-25 15:25, Joseph S. Myers wrote: On Wed, 25 Jun 2014, Sebastian Huber wrote: I think the inheritance of the volatile qualifier via __typeof__ (*__atomic_load_ptr) is an implementation flaw. See the comment in c_parser_typeof_specifier: /* For use in macros such as those in , remove _Atomic and const qualifiers from atomic types. (Possibly all qualifiers should be removed; const can be an issue for more macros using typeof than just the ones.) */ (If changing this, remember to change the __auto_type handling as well.) Thanks for the hint. I sent a patch to the list. https://gcc.gnu.org/ml/gcc-patches/2014-06/msg02026.html In case __auto_type discards const and volatile qualifiers, then shouldn't this generate a warning (-Wconst-qual) __auto_type __atomic_load_ptr = (PTR); ? Why is it necessary to discard the const and/or volatile qualifiers in the __auto_type at all? I think for it should be sufficient to discard them only in __typeof__. -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
Localized write permission for OS maintainers
Hello, I have a question regarding the localized write permission for OS maintainers. In https://www.gnu.org/software/gcc/svnwrite.html we have "Localized write permission. This is for people who have primary responsibility for ports, front ends, or other specific aspects of the compiler. These folks are allowed to make changes to areas they maintain and related documentation, web pages, and test cases without approval from anyone else, and approve other people's changes in those areas. They must get approval for changes elsewhere in the compiler. Maintainers of a port maintain the relevant files in |gcc/config|, documentation, web pages, and test cases and aspects of these relevant to that port. Port maintainers do not have approval rights beyond this." Does this cover OS specific areas in the gcc/config.gcc file? For example: https://gcc.gnu.org/ml/gcc-patches/2014-12/msg01214.html -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
Re: Sebastian Huber appointed RTEMS Co-Maintainer
Hello, thanks for your trust. On 21/12/14 17:46, Joel Sherrill wrote: Hi I am pleased to announce that the steering committee has appointed Sebastian Huber as co-maintainer of the RTEMS target in GCC. This is a reflection of the work has done and community involvement Sebastian has already had. We are looking forward to more of this in the future. Please adjust the MAINTAINERS file accordingly, and Happy Hacking! Done in Revision 219003. -- Joel Sherrill, Ph.D. Director of Research & Development joel.sherr...@oarcorp.com On-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available (256) 722-9985 -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
libgomp support for RTEMS
Hello, I would like to add support for libgomp for the RTEMS operating system. I likely cannot use the standard Pthread API for this in some places since I have to account for RTEMS specifics related to partitioned/clustered scheduling and the priority based scheduler. If I implement for example functions like this void gomp_init_thread_affinity (pthread_attr_t *attr, unsigned int place) outside of the GCC provided libgomp (e.g. in the RTEMS sources) can I choose an arbitrary license for this or do I have to use the GPLv3 with the GCC Runtime Library Exception for it? Is it possible to add a gomp_free() to complement the gomp_malloc() etc.? This would enable the usage of a dedicated heap for OpenMP in RTEMS. -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
Re: libgomp support for RTEMS
On 30/01/15 12:50, Jakub Jelinek wrote: On Fri, Jan 30, 2015 at 12:14:26PM +0100, Sebastian Huber wrote: >Hello, > >I would like to add support for libgomp for the RTEMS operating system. I >likely cannot use the standard Pthread API for this in some places since I >have to account for RTEMS specifics related to partitioned/clustered >scheduling and the priority based scheduler. If I implement for example >functions like this > >void gomp_init_thread_affinity (pthread_attr_t *attr, unsigned int place) > >outside of the GCC provided libgomp (e.g. in the RTEMS sources) can I choose >an arbitrary license for this or do I have to use the GPLv3 with the GCC >Runtime Library Exception for it? > >Is it possible to add a gomp_free() to complement the gomp_malloc() etc.? >This would enable the usage of a dedicated heap for OpenMP in RTEMS. Why would you want to implement it outside of libgomp? libgomp has a config/ tree, so just add config/rtems/ in there and implement it in there. RTEMS uses the same method for the thread model. It is easier to maintain since I don't have to build and install a new compiler just to change the libgomp support. The RTEMS API header file is not available during GCC build. I would like to make some parts application configurable via function pointers (e.g. the heap functions). On RTEMS we have a single address space for the operating system, support libraries and the application. In the application we have parts of different criticality and dynamic behaviour, so the management of dynamic memory is highly application dependent. Some systems must run months without a re-boot. I would like to add a config/rtems and implement most of the stuff inside the RTEMS source tree or let even the application provide the implementation. -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
libgomp: gomp_new_team() use free list?
Hello,
I work currently on the libgomp support for the RTEMS operating system. It
uses the POSIX configuration and it works all right so far. One problem is
that each GOMP_parallel() invocation calls gomp_new_team() which uses malloc()
and initializes a couple of mutex, barrier and semaphore objects. On Linux the
initialization and destruction of these objects is negligible, but on RTEMS
these are quite heavy weight operations. The malloc() call however might be
also noticeable on Linux. Does it make sense to introduce a free list of
teams? Something like this:
struct gomp_team *
gomp_new_team(unsigned nthreads)
{
struct gomp_team *team = get_team_from_free_list(nthreads);
if (team == NULL) {
return current_gomp_new_team(nthreads);
} else {
return team;
}
}
--
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail : sebastian.huber at embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
Re: [PATCH v3 1/3] or1k: libgcc: initial support for openrisc
Hello Stafford, I tried to build the or1k-rtems5 target with GCC 4c0c3d1029e79b6709b43fed8c5a5944f245516d and Binutils 417e50dbcfd4b8dd699f48df5ac9b9a733fd80e2. It failed in the libgcc build: /scratch/git-rtems-source-builder/rtems/build/or1k-rtems5-gcc-4c0c3d1029e79b6709b43fed8c5a5944f245516d-newlib-2ab57ad59bc35dafffa69cd4da5e228971de069f-x86_64-linux-gnu-1/build/./gcc/xgcc -B/scratch/git-rtems-source-builder/rtems/build/or1k-rtems5-gcc-4c0c3d1029e79b6709b43fed8c5a5944f245516d-newlib-2ab57ad59bc35dafffa69cd4da5e228971de069f-x86_64-linux-gnu-1/build/./gcc/ -nostdinc -B/scratch/git-rtems-source-builder/rtems/build/or1k-rtems5-gcc-4c0c3d1029e79b6709b43fed8c5a5944f245516d-newlib-2ab57ad59bc35dafffa69cd4da5e228971de069f-x86_64-linux-gnu-1/build/or1k-rtems5/mcmov/newlib/ -isystem /scratch/git-rtems-source-builder/rtems/build/or1k-rtems5-gcc-4c0c3d1029e79b6709b43fed8c5a5944f245516d-newlib-2ab57ad59bc35dafffa69cd4da5e228971de069f-x86_64-linux-gnu-1/build/or1k-rtems5/mcmov/newlib/targ-include -isystem /scratch/git-rtems-source-builder/rtems/build/or1k-rtems5-gcc-4c0c3d1029e79b6709b43fed8c5a5944f245516d-newlib-2ab57ad59bc35dafffa69cd4da5e228971de069f-x86_64-linux-gnu-1/gnu-mirror-gcc-4c0c3d1029e79b6709b43fed8c5a5944f245516d/newlib/libc/include -B/build/rtems/5/or1k-rtems5/bin/ -B/build/rtems/5/or1k-rtems5/lib/ -isystem /build/rtems/5/or1k-rtems5/include -isystem /build/rtems/5/or1k-rtems5/sys-include -mcmov -g -O2 -O2 -I../../../../gnu-mirror-gcc-4c0c3d1029e79b6709b43fed8c5a5944f245516d/libgcc/../newlib/libc/sys/rtems/include -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -Dinhibit_libc -I. -I. -I../../.././gcc -I../../../../gnu-mirror-gcc-4c0c3d1029e79b6709b43fed8c5a5944f245516d/libgcc -I../../../../gnu-mirror-gcc-4c0c3d1029e79b6709b43fed8c5a5944f245516d/libgcc/. -I../../../../gnu-mirror-gcc-4c0c3d1029e79b6709b43fed8c5a5944f245516d/libgcc/../gcc -I../../../../gnu-mirror-gcc-4c0c3d1029e79b6709b43fed8c5a5944f245516d/libgcc/../include -o _ffssi2.o -MT _ffssi2.o -MD -MP -MF _ffssi2.dep -DL_ffssi2 -c ../../../../gnu-mirror-gcc-4c0c3d1029e79b6709b43fed8c5a5944f245516d/libgcc/libgcc2.c -fvisibility=hidden -DHIDE_EXPORTS -save-temps libgcc2.s: Assembler messages: libgcc2.s:60: Error: junk at end of line `l.movhi r17,ha(__clz_tab)' The file content in this area is: .L4: .LVL4: .LM17: .LBE3: .LM18: .LBE2: .LM19: .LBB6: .LBB4: .LM20: l.movhi r17, ha(__clz_tab) l.addi r17, r17, lo(__clz_tab) l.add r3, r17, r3 .LVL5: l.lbz r11, 0(r3) -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
Re: [PATCH v3 1/3] or1k: libgcc: initial support for openrisc
On 13/11/2018 21:20, Stafford Horne wrote: On Tue, Nov 13, 2018 at 11:57:13AM -0600, Joel Sherrill wrote: Sebastian confirmed he couldn't get a complete RTEMS build either. I looked into this enough to spot that old or1k port's libgcc/config.host has an extra_parts line for or1k-*-* that the gcc master does not: The gcc master repo is missing the "extra_parts" line that was in the other repository. or1k-*-*) tmake_file="$tmake_file or1k/t-or1k" tmake_file="$tmake_file t-softfp-sfdf t-softfp-excl t-softfp" extra_parts="$extra_parts crti.o crtn.o" ;; OK for Sebastian or I to add that line? Hi Joel, Did adding that fix the issue? We removed crti.o and crtn.o because we switched to exclusive libc_init/fini_array. It should not help to add those back, see the commit here: https://github.com/stffrdhrn/gcc/commit/46131027c9775ebcddc48bd0ae64ceec5b1f801f What is the error you are seeing? It was an error in our GCC specs file. I fixed it like this: https://git.rtems.org/rtems/commit/?id=28bf4cae7878f4e47cc24c114fc9c5567247ecc1 I was able to build the RTEMS BSP and link the tests with the upstream GCC 9. -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
RTEMS Ada build problem on trunk
Hello, I tried to build the arm-rtems target with Ada support on the trunk yesterday. It fails with: /home/user/rtems-source-builder/rtems/build/arm-rtems6-gcc-0ca47588bd2e38bbfa427503968e08a6b8ab3166-newlib-068182e26c7b397df579b69a18f745092844d1b4-x86 _64-linux-gnu-1/build/./gcc/xgcc -B/home/user/rtems-source-builder/rtems/build/arm-rtems6-gcc-0ca47588bd2e38bbfa427503968e08a6b8ab3166-newlib-068182e26 c7b397df579b69a18f745092844d1b4-x86_64-linux-gnu-1/build/./gcc/ -nostdinc -B/home/user/rtems-source-builder/rtems/build/arm-rtems6-gcc-0ca47588bd2e38bb fa427503968e08a6b8ab3166-newlib-068182e26c7b397df579b69a18f745092844d1b4-x86_64-linux-gnu-1/build/arm-rtems6/newlib/ -isystem /home/user/rtems-source-b uilder/rtems/build/arm-rtems6-gcc-0ca47588bd2e38bbfa427503968e08a6b8ab3166-newlib-068182e26c7b397df579b69a18f745092844d1b4-x86_64-linux-gnu-1/build/arm -rtems6/newlib/targ-include -isystem /home/user/rtems-source-builder/rtems/build/arm-rtems6-gcc-0ca47588bd2e38bbfa427503968e08a6b8ab3166-newlib-068182e 26c7b397df579b69a18f745092844d1b4-x86_64-linux-gnu-1/gnu-mirror-gcc-0ca47588bd2e38bbfa427503968e08a6b8ab3166/newlib/libc/include -B/home/user/rtems-ins tall/arm-rtems6/bin/ -B/home/user/rtems-install/arm-rtems6/lib/ -isystem /home/user/rtems-install/arm-rtems6/include -isystem /home/user/rtems-install/ arm-rtems6/sys-include -c -g -O2 -W -Wall -gnatpg -nostdinc a-envvar.adb -o a-envvar.o a-direct.adb:743:28: "SIZEOF_struct_dirent_alloc" is undefined s-filatt.ads:62:18: "SIZEOF_struct_file_attributes" not declared in "OS_Constants" s-oscons.ads:408:01: (style) multiple blank lines s-oscons.ads:413:01: (style) multiple blank lines In the build tree(gcc/ada/rts) I have this: grep -- '->CND' s-oscons-tmplt.s ... ->CND:#1699:CLOCK_REALTIME:#1:System realtime clock ->CND:#1702:CLOCK_MONOTONIC:#4:System monotonic clock ->CND:#1712:CLOCK_THREAD_CPUTIME_ID:#3:Thread CPU clock ->CND:#1771:PTHREAD_SIZE:#4:pthread_t ->CND:#1772:PTHREAD_ATTR_SIZE:#96:pthread_attr_t ->CND:#1773:PTHREAD_MUTEXATTR_SIZE:#24:pthread_mutexattr_t ->CND:#1774:PTHREAD_MUTEX_SIZE:#64:pthread_mutex_t ->CND:#1775:PTHREAD_CONDATTR_SIZE:#24:pthread_condattr_t ->CND:#1776:PTHREAD_COND_SIZE:#28:pthread_cond_t ->CND:#1777:PTHREAD_RWLOCKATTR_SIZE:#8:pthread_rwlockattr_t ->CND:#1778:PTHREAD_RWLOCK_SIZE:#32:pthread_rwlock_t ->CND:#1779:PTHREAD_ONCE_SIZE:#1:pthread_once_t ->CND:#1800:SIZEOF_struct_file_attributes:#24:struct file_attributes ->CND:#1812:SIZEOF_struct_dirent_alloc:#278:struct dirent allocation The ../bldtools/oscons/xoscons s-oscons produces this tail -20 s-oscons.ads - -- Threads support -- - -- Clock identifier definitions CLOCK_REALTIME : constant := 1; -- System realtime clock CLOCK_MONOTONIC : constant := 4; -- System monotonic clock CLOCK_THREAD_CPUTIME_ID : constant := 3; -- Thread CPU clock CLOCK_RT_Ada : constant := CLOCK_REALTIME; -- Sizes of pthread data types -- File and directory support -- end System.OS_Constants; With GCC 7.4.0 it works and the s-oscons-tmplt.s dosn't look that much different. My native GNAT is: gnat --version GNAT 9.0.0 20190116 (experimental) Copyright (C) 1996-2019, 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. -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
Re: RTEMS Ada build problem on trunk
On 17/01/2019 09:56, Sebastian Huber wrote: Hello, I tried to build the arm-rtems target with Ada support on the trunk yesterday. It fails with: /home/user/rtems-source-builder/rtems/build/arm-rtems6-gcc-0ca47588bd2e38bbfa427503968e08a6b8ab3166-newlib-068182e26c7b397df579b69a18f745092844d1b4-x86 _64-linux-gnu-1/build/./gcc/xgcc -B/home/user/rtems-source-builder/rtems/build/arm-rtems6-gcc-0ca47588bd2e38bbfa427503968e08a6b8ab3166-newlib-068182e26 c7b397df579b69a18f745092844d1b4-x86_64-linux-gnu-1/build/./gcc/ -nostdinc -B/home/user/rtems-source-builder/rtems/build/arm-rtems6-gcc-0ca47588bd2e38bb fa427503968e08a6b8ab3166-newlib-068182e26c7b397df579b69a18f745092844d1b4-x86_64-linux-gnu-1/build/arm-rtems6/newlib/ -isystem /home/user/rtems-source-b uilder/rtems/build/arm-rtems6-gcc-0ca47588bd2e38bbfa427503968e08a6b8ab3166-newlib-068182e26c7b397df579b69a18f745092844d1b4-x86_64-linux-gnu-1/build/arm -rtems6/newlib/targ-include -isystem /home/user/rtems-source-builder/rtems/build/arm-rtems6-gcc-0ca47588bd2e38bbfa427503968e08a6b8ab3166-newlib-068182e 26c7b397df579b69a18f745092844d1b4-x86_64-linux-gnu-1/gnu-mirror-gcc-0ca47588bd2e38bbfa427503968e08a6b8ab3166/newlib/libc/include -B/home/user/rtems-ins tall/arm-rtems6/bin/ -B/home/user/rtems-install/arm-rtems6/lib/ -isystem /home/user/rtems-install/arm-rtems6/include -isystem /home/user/rtems-install/ arm-rtems6/sys-include -c -g -O2 -W -Wall -gnatpg -nostdinc a-envvar.adb -o a-envvar.o a-direct.adb:743:28: "SIZEOF_struct_dirent_alloc" is undefined s-filatt.ads:62:18: "SIZEOF_struct_file_attributes" not declared in "OS_Constants" s-oscons.ads:408:01: (style) multiple blank lines s-oscons.ads:413:01: (style) multiple blank lines In the build tree(gcc/ada/rts) I have this: grep -- '->CND' s-oscons-tmplt.s ... ->CND:#1699:CLOCK_REALTIME:#1:System realtime clock ->CND:#1702:CLOCK_MONOTONIC:#4:System monotonic clock ->CND:#1712:CLOCK_THREAD_CPUTIME_ID:#3:Thread CPU clock ->CND:#1771:PTHREAD_SIZE:#4:pthread_t ->CND:#1772:PTHREAD_ATTR_SIZE:#96:pthread_attr_t ->CND:#1773:PTHREAD_MUTEXATTR_SIZE:#24:pthread_mutexattr_t ->CND:#1774:PTHREAD_MUTEX_SIZE:#64:pthread_mutex_t ->CND:#1775:PTHREAD_CONDATTR_SIZE:#24:pthread_condattr_t ->CND:#1776:PTHREAD_COND_SIZE:#28:pthread_cond_t ->CND:#1777:PTHREAD_RWLOCKATTR_SIZE:#8:pthread_rwlockattr_t ->CND:#1778:PTHREAD_RWLOCK_SIZE:#32:pthread_rwlock_t ->CND:#1779:PTHREAD_ONCE_SIZE:#1:pthread_once_t ->CND:#1800:SIZEOF_struct_file_attributes:#24:struct file_attributes ->CND:#1812:SIZEOF_struct_dirent_alloc:#278:struct dirent allocation The ../bldtools/oscons/xoscons s-oscons produces this tail -20 s-oscons.ads - -- Threads support -- - -- Clock identifier definitions CLOCK_REALTIME : constant := 1; -- System realtime clock CLOCK_MONOTONIC : constant := 4; -- System monotonic clock CLOCK_THREAD_CPUTIME_ID : constant := 3; -- Thread CPU clock CLOCK_RT_Ada : constant := CLOCK_REALTIME; -- Sizes of pthread data types -- File and directory support -- end System.OS_Constants; With GCC 7.4.0 it works and the s-oscons-tmplt.s dosn't look that much different. My native GNAT is: gnat --version GNAT 9.0.0 20190116 (experimental) Copyright (C) 1996-2019, 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. I can build the trunk with a native gnat --version GNAT 8.2.1 20190103 [gcc-8-branch revision 267549] Copyright (C) 1996-2018, 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. -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
Re: RTEMS Ada build problem on trunk
On 17/01/2019 12:40, Eric Botcazou wrote: I can build the trunk with a native gnat --version GNAT 8.2.1 20190103 [gcc-8-branch revision 267549] Copyright (C) 1996-2018, 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. This would suggest that bldtools/oscons/xoscons is miscompiled by the trunk native compiler. How did you configure this latter compiler? Are there some build/source path limits involved while building Ada? With long path names the build failed (path includes full Git hashes). Then I move the source and build roots to a shorter path, then build was successful using the same configure options. -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail :sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
Re: RTEMS Ada build problem on trunk
On 17/01/2019 15:25, Sebastian Huber wrote: On 17/01/2019 12:40, Eric Botcazou wrote: I can build the trunk with a native gnat --version GNAT 8.2.1 20190103 [gcc-8-branch revision 267549] Copyright (C) 1996-2018, 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. This would suggest that bldtools/oscons/xoscons is miscompiled by the trunk native compiler. How did you configure this latter compiler? Are there some build/source path limits involved while building Ada? With long path names the build failed (path includes full Git hashes). Then I move the source and build roots to a shorter path, then build was successful using the same configure options. I reduced the path lengths via short Git hashes. I was able to build GCC 597c6d15f88 sparc-rtems5-gnat --version GNAT 9.0.0 20190118 (RTEMS 6, RSB b794966eebc2cb09f14fee16e402f2b0eb8c0fcf, Newlib 7f983079d) on openSUSE with a native GCC gcc --version gcc (SUSE Linux) 8.2.1 20190103 [gcc-8-branch revision 267549 provided by openSUSE. On Debian GNU/Linux 9 (stretch) with a self built native GCC gcc --version --verbose Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/home/user/gcc-8.2.0/libexec/gcc/x86_64-pc-linux-gnu/8.2.0/lto-wrapper gcc (GCC) 8.2.0 Copyright (C) 2018 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: ../src/gcc-8.2.0/configure --prefix=/home/user/gcc-8.2.0 --disable-multilib --enable-languages=c,c++,ada Thread model: posix gcc version 8.2.0 (GCC) COLLECT_GCC_OPTIONS='--version' '-v' '-mtune=generic' '-march=x86-64' /home/user/gcc-8.2.0/libexec/gcc/x86_64-pc-linux-gnu/8.2.0/cc1 -quiet -v -imultiarch x86_64-linux-gnu help-dummy -quiet -dumpbase help-dummy -mtune=generic -march=x86-64 -auxbase help-dummy -version --version -o /tmp/cc7wWgjz.s GNU C17 (GCC) version 8.2.0 (x86_64-pc-linux-gnu) compiled by GNU C version 8.2.0, GMP version 6.1.0, MPFR version 3.1.4, MPC version 1.0.3, isl version isl-0.18-GMP GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 COLLECT_GCC_OPTIONS='--version' '-v' '-mtune=generic' '-march=x86-64' as -v --64 --version -o /tmp/ccKF8BFi.o /tmp/cc7wWgjz.s GNU assembler version 2.28 (x86_64-linux-gnu) using BFD version (GNU Binutils for Debian) 2.28 GNU assembler (GNU Binutils for Debian) 2.28 Copyright (C) 2017 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License version 3 or later. This program has absolutely no warranty. This assembler was configured for a target of `x86_64-linux-gnu'. COMPILER_PATH=/home/user/gcc-8.2.0/libexec/gcc/x86_64-pc-linux-gnu/8.2.0/:/home/user/gcc-8.2.0/libexec/gcc/x86_64-pc-linux-gnu/8.2.0/:/home/user/gcc-8.2.0/libexec/gcc/x86_64-pc-linux-gnu/:/home/user/gcc-8.2.0/lib/gcc/x86_64-pc-linux-gnu/8.2.0/:/home/user/gcc-8.2.0/lib/gcc/x86_64-pc-linux-gnu/ LIBRARY_PATH=/home/user/gcc-8.2.0/lib/gcc/x86_64-pc-linux-gnu/8.2.0/:/home/user/gcc-8.2.0/lib/gcc/x86_64-pc-linux-gnu/8.2.0/../../../../lib64/:/lib/x86_64-linux-gnu/:/lib/../lib64/:/usr/lib/x86_64-linux-gnu/:/home/user/gcc-8.2.0/lib/gcc/x86_64-pc-linux-gnu/8.2.0/../../../:/lib/:/usr/lib/ COLLECT_GCC_OPTIONS='--version' '-v' '-mtune=generic' '-march=x86-64' /home/user/gcc-8.2.0/libexec/gcc/x86_64-pc-linux-gnu/8.2.0/collect2 -plugin /home/user/gcc-8.2.0/libexec/gcc/x86_64-pc-linux-gnu/8.2.0/liblto_plugin.so -plugin-opt=/home/user/gcc-8.2.0/libexec/gcc/x86_64-pc-linux-gnu/8.2.0/lto-wrapper -plugin-opt=-fresolution=/tmp/cc1NHm21.res -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lc -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s --eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 --version /usr/lib/x86_64-linux-gnu/crt1.o /usr/lib/x86_64-linux-gnu/crti.o /home/user/gcc-8.2.0/lib/gcc/x86_64-pc-linux-gnu/8.2.0/crtbegin.o -L/home/user/gcc-8.2.0/lib/gcc/x86_64-pc-linux-gnu/8.2.0 -L/home/user/gcc-8.2.0/lib/gcc/x86_64-pc-linux-gnu/8.2.0/../../../../lib64 -L/lib/x86_64-linux-gnu -L/lib/../lib64 -L/usr/lib/x86_64-linux-gnu -L/home/user/gcc-8.2.0/lib/gcc/x86_64-pc-linux-gnu/8.2.0/../../.. /tmp/ccKF8BFi.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /home/user/gcc-8.2.0/lib/gcc/x86_64-pc-linux-gnu/8.2.0/crtend.o /usr/lib/x86_64-linux-gnu/crtn.o collect2 version 8.2.0 /usr/bin/ld -plugin /home/user/gcc-8.2.0/libexec/gcc/x86_64-pc-linux-gnu/8.2.0/liblto_plugin.so -plugin-opt=/home/user/gcc-8.2.0/libexec/gcc/x86_64-pc-linux-gnu/8.2
libgomp platform customization
Hello,
we would like to use libgomp in a quite constraint environment. In this
environment using for example the C locale support, errno, malloc(),
realloc(), free(), and abort() are problematic. One option would be to
introduce a new header file "config/*/platform.h" which is included in
libgomp.h right after the #include "config.h". A platform could then do
something like this:
#define malloc(size) platform_malloc(size)
...
In env.c there are some uses of strto*() like this:
errno = 0;
stride = strtol (env, &env, 10);
if (errno)
return false;
I would like to introduce a new header file "strto.h" which defines
something like this:
static inline char *
gomp_strtol (char *s, long *value)
{
char *end;
errno = 0;
*value = strtol (s, &end, 10);
if (errno != 0)
return NULL;
return end;
}
Then use:
env = gomp_strtol (env, &stride);
if (env == NULL)
return false;
A platform could then provide its own "config/*/strto.h" with an
alternative implementation.
Would this be acceptable after the GCC 9 release?
--
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
Re: libgomp platform customization
On 31/01/2019 10:29, Richard Biener wrote:
On Wed, Jan 30, 2019 at 3:46 PM Sebastian Huber
wrote:
Hello,
we would like to use libgomp in a quite constraint environment. In this
environment using for example the C locale support, errno, malloc(),
realloc(), free(), and abort() are problematic. One option would be to
introduce a new header file "config/*/platform.h" which is included in
libgomp.h right after the #include "config.h". A platform could then do
something like this:
#define malloc(size) platform_malloc(size)
...
In env.c there are some uses of strto*() like this:
errno = 0;
stride = strtol (env, &env, 10);
if (errno)
return false;
I would like to introduce a new header file "strto.h" which defines
something like this:
static inline char *
gomp_strtol (char *s, long *value)
{
char *end;
errno = 0;
*value = strtol (s, &end, 10);
if (errno != 0)
return NULL;
return end;
}
Then use:
env = gomp_strtol (env, &stride);
if (env == NULL)
return false;
A platform could then provide its own "config/*/strto.h" with an
alternative implementation.
Would this be acceptable after the GCC 9 release?
I guess you could look at what nvptx and HSA (and GCN on some branch)
do here?
My problem is that our real-time operating system (RTEMS) is somewhere
in between a full blown Linux and the offload hardware. I would like to
get rid of stuff which depends on the Newlib struct _reent since this
pulls in a lot of dependencies. The heavy weight functions are just used
for the initialization (env.c) and error reporting. Containing the heap
allocation functions helps to control the memory used by OpenMP
computations.
--
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
Re: libgomp platform customization
On 31/01/2019 10:56, Jakub Jelinek wrote: On Thu, Jan 31, 2019 at 10:37:29AM +0100, Sebastian Huber wrote: My problem is that our real-time operating system (RTEMS) is somewhere in between a full blown Linux and the offload hardware. I would like to get rid of stuff which depends on the Newlib struct _reent since this pulls in a lot of dependencies. The heavy weight functions are just used for the initialization (env.c) and error reporting. Containing the heap allocation functions helps to control the memory used by OpenMP computations. Heap allocations are everywhere in libgomp, not just in initialization, for parallel, offloading, tasking, worksharing constructs, ... You won't get far without that. I would like to use a specialized heap for OpenMP and not the general purpose malloc(), etc. -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
Re: libgomp platform customization
On 31/01/2019 11:07, Jakub Jelinek wrote: On Thu, Jan 31, 2019 at 10:58:27AM +0100, Sebastian Huber wrote: On 31/01/2019 10:56, Jakub Jelinek wrote: On Thu, Jan 31, 2019 at 10:37:29AM +0100, Sebastian Huber wrote: My problem is that our real-time operating system (RTEMS) is somewhere in between a full blown Linux and the offload hardware. I would like to get rid of stuff which depends on the Newlib struct _reent since this pulls in a lot of dependencies. The heavy weight functions are just used for the initialization (env.c) and error reporting. Containing the heap allocation functions helps to control the memory used by OpenMP computations. Heap allocations are everywhere in libgomp, not just in initialization, for parallel, offloading, tasking, worksharing constructs, ... You won't get far without that. I would like to use a specialized heap for OpenMP and not the general purpose malloc(), etc. I'd prefer not to clobber the generic code with that though. So, if you in some config/rtems/ header or overriding *.c file #undef strtoul #define strtoul(p, e, b) rtems_strtoul (p, e, b) and similarly for malloc, free, calloc, I won't object, but I'm against introducing gomp_strtoul, etc. (we do already have gomp_malloc, but expect free to be usable against that). The strtoul() is used in combination with errno, so using a macro is not enough. I really would like to be able to use env.c in general, since the standard configuration via environment variables is fine. -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
Re: For which gcc release is going to be foreseen the support for the Coroutines TS extension?
Hello, On 06/06/2018 08:33, Florian Weimer wrote: On 06/04/2018 07:36 PM, Jonathan Wakely wrote: On 4 June 2018 at 18:32, Marco Ippolito wrote: Hi all, clang and VS2017 already support the Coroutines TS extensions. For which gcc release is going to be foreseen the support for the Coroutines TS extension? This has been discussed recently, search the mailing list. It will be supported after somebody implements it. If it is in fact implementable on top of the GNU ABI. Some variants of coroutines are not. it seems C++20 will contain coroutines. Are there already some plans to support them in GCC? I ask this so that I can plan my work to support it for RTEMS. For example, are there plans to build them on top of ucontext? -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
How to configure a bi-arch PowerPC GCC?
Hello,
I would like to configure a bi-arch PowerPC GCC. My naive approach was
simply:
diff --git a/gcc/config.gcc b/gcc/config.gcc
index 90308cd..228f941 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -2381,7 +2381,7 @@ powerpc-*-eabi*)
use_gcc_stdint=wrap
;;
powerpc-*-rtems*)
- tm_file="${tm_file} dbxelf.h elfos.h freebsd-spec.h
newlib-stdint.h rs6000/sysv4.h rs6000/eabi.h rs6000/e500.h
rs6000/rtems.h rtems.h"
+ tm_file="rs6000/biarch64.h ${tm_file} dbxelf.h elfos.h
freebsd-spec.h newlib-stdint.h rs6000/sysv4.h rs6000/eabi.h
rs6000/e500.h rs6000/rtems.h rtems.h"
extra_options="${extra_options} rs6000/sysv4.opt"
tmake_file="${tmake_file} rs6000/t-fprules rs6000/t-rtems
rs6000/t-ppccomm"
;;
diff --git a/gcc/config/rs6000/t-rtems b/gcc/config/rs6000/t-rtems
index 7c7637d..8ff0656 100644
--- a/gcc/config/rs6000/t-rtems
+++ b/gcc/config/rs6000/t-rtems
@@ -30,6 +30,9 @@ MULTILIB_DIRNAMES += m403 m505 m603e m604 m860 m7400
m8540 me6500
MULTILIB_OPTIONS += m32
MULTILIB_DIRNAMES += m32
+MULTILIB_OPTIONS += m64
+MULTILIB_DIRNAMES += m64
+
MULTILIB_OPTIONS += msoft-float/mfloat-gprs=double
MULTILIB_DIRNAMES += nof gprsdouble
@@ -77,3 +80,5 @@ MULTILIB_REQUIRED += mcpu=8540/mfloat-gprs=double
MULTILIB_REQUIRED += mcpu=860
MULTILIB_REQUIRED += mcpu=e6500/m32
MULTILIB_REQUIRED += mcpu=e6500/m32/msoft-float/mno-altivec
+MULTILIB_REQUIRED += mcpu=e6500/m64
+MULTILIB_REQUIRED += mcpu=e6500/m64/msoft-float/mno-altivec
This leads to an ICE during libgcc configure:
configure:3660: checking for suffix of object files
configure:3682: /build/git-build/b-gcc-git-powerpc-rtems4.12/./gcc/xgcc
-B/build/git-build/b-gcc-git-powerpc-rtems4.12/./gcc/ -nostdinc
-B/build/git-build/b-gcc-git-powerpc-rtems4.12/powerpc-rtems4.12/me6500/m64/newlib/
-isystem
/build/git-build/b-gcc-git-powerpc-rtems4.12/powerpc-rtems4.12/me6500/m64/newlib/targ-include
-isystem /home/EB/sebastian_h/archive/gcc-git/newlib/libc/include
-B/opt/rtems-4.12/powerpc-rtems4.12/bin/
-B/opt/rtems-4.12/powerpc-rtems4.12/lib/ -isystem
/opt/rtems-4.12/powerpc-rtems4.12/include -isystem
/opt/rtems-4.12/powerpc-rtems4.12/sys-include -mcpu=e6500 -m64 -c -g
-O2 conftest.c >&5
conftest.c: In function 'main':
conftest.c:16:1: error: unrecognizable insn:
}
^
(insn/f 22 21 23 2 (parallel [
(set (reg/f:DI 1 1)
(plus:SI (reg/f:DI 1 1)
(const_int 16 [0x10])))
(set (mem:BLK (reg/f:DI 1 1) [0 A8])
(const_int 0 [0]))
(set (mem:BLK (reg/f:DI 1 1) [0 A8])
(const_int 0 [0]))
]) "conftest.c":16 -1
(expr_list:REG_CFA_DEF_CFA (reg/f:DI 1 1)
(nil)))
conftest.c:16:1: internal compiler error: in extract_insn, at recog.c:2311
0x98ada5 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/home/EB/sebastian_h/archive/gcc-git/gcc/rtl-error.c:108
0x98add9 _fatal_insn_not_found(rtx_def const*, char const*, int, char
const*)
/home/EB/sebastian_h/archive/gcc-git/gcc/rtl-error.c:116
0x95c397 extract_insn(rtx_insn*)
/home/EB/sebastian_h/archive/gcc-git/gcc/recog.c:2311
0x95d3b8 extract_constrain_insn(rtx_insn*)
/home/EB/sebastian_h/archive/gcc-git/gcc/recog.c:2211
0x9609a6 copyprop_hardreg_forward_1
/home/EB/sebastian_h/archive/gcc-git/gcc/regcprop.c:794
0x961982 execute
/home/EB/sebastian_h/archive/gcc-git/gcc/regcprop.c:1301
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
configure:3686: $? = 1
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME "GNU C Runtime Library"
| #define PACKAGE_TARNAME "libgcc"
| #define PACKAGE_VERSION "1.0"
| #define PACKAGE_STRING "GNU C Runtime Library 1.0"
| #define PACKAGE_BUGREPORT ""
| #define PACKAGE_URL "http://www.gnu.org/software/libgcc/";
| /* end confdefs.h. */
|
| int
| main ()
| {
|
| ;
| return 0;
| }
configure:3700: error: in
`/build/git-build/b-gcc-git-powerpc-rtems4.12/powerpc-rtems4.12/me6500/m64/libgcc':
configure:3703: error: cannot compute suffix of object files: cannot compile
I would be happy for some hints how to fix this.
--
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
Re: How to configure a bi-arch PowerPC GCC?
Hello Segher, On 20/01/17 02:04, Segher Boessenkool wrote: Hi, On Thu, Jan 19, 2017 at 01:41:33PM +0100, Sebastian Huber wrote: conftest.c:16:1: error: unrecognizable insn: } ^ (insn/f 22 21 23 2 (parallel [ (set (reg/f:DI 1 1) (plus:SI (reg/f:DI 1 1) (const_int 16 [0x10]))) (set (mem:BLK (reg/f:DI 1 1) [0 A8]) (const_int 0 [0])) (set (mem:BLK (reg/f:DI 1 1) [0 A8]) (const_int 0 [0])) ]) "conftest.c":16 -1 (expr_list:REG_CFA_DEF_CFA (reg/f:DI 1 1) (nil))) This is stack_restore_tie, which requires TARGET_32BIT. It currently is only generated from rs6000_emit_stack_reset: /* This blockage is needed so that sched doesn't decide to move the sp change before the register restores. */ if (DEFAULT_ABI == ABI_V4 || (TARGET_SPE_ABI && info->spe_64bit_regs_used != 0 && info->first_gp_reg_save != 32)) return emit_insn (gen_stack_restore_tie (updt_reg_rtx, frame_reg_rtx, GEN_INT (frame_off))); so you seem to have 64-bit ABI_V4? I wonder how well tested that is, you are likely to run into more problems. Either stack_restore_tie or the above code will need a tweak. thanks for your help. I would had a hard time to figure this out myself. I am flexible in terms of the ABI choice for the 64-bit PowerPC. I guess the ABI_ELFv2 is the way to go? I had to provide SUBSUBTARGET_OVERRIDE_OPTIONS in rtems.h (in config/rs6000/) to set the ABI. The sysv4.h doesn't care about -mabi=elfv2. There seems to be some copy and paste in linux64.h and freebsd64.h for their SUBSUBTARGET_OVERRIDE_OPTIONS. Maybe the common stuff should move to sysv4.h? -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
Re: How to configure a bi-arch PowerPC GCC?
On 21/01/17 01:46, Segher Boessenkool wrote: On Fri, Jan 20, 2017 at 08:35:14AM +0100, Sebastian Huber wrote: so you seem to have 64-bit ABI_V4? I wonder how well tested that is, you are likely to run into more problems. Either stack_restore_tie or the above code will need a tweak. thanks for your help. I would had a hard time to figure this out myself. I am flexible in terms of the ABI choice for the 64-bit PowerPC. I guess the ABI_ELFv2 is the way to go? It certainly is the most modern ABI. It makes some requirements to what Power ISA features are required, which may or may not be a problem for your platform. If you want to use BE, that should work with ELFv2 fine (and it did in the past at least), but it doesn't get serious testing. I use now the attached patch and get the following error types (for several multilibs): /build/git-build/b-gcc-git-powerpc-rtems4.12/./gcc/xgcc -B/build/git-build/b-gcc-git-powerpc-rtems4.12/./gcc/ -nostdinc -B/build/git-build/b-gcc-git-powerpc-rtems4.12/powerpc-rtems4.12/newlib/ -isystem /build/git-build/b-gcc-git-powerpc-rtems4.12/powerpc-rtems4.12/newlib/targ-include -isystem /home/EB/sebastian_h/archive/gcc-git/newlib/libc/include -B/opt/rtems-4.12/powerpc-rtems4.12/bin/ -B/opt/rtems-4.12/powerpc-rtems4.12/lib/ -isystem /opt/rtems-4.12/powerpc-rtems4.12/include -isystem /opt/rtems-4.12/powerpc-rtems4.12/sys-include-g -O2 -mcpu=8540 -O2 -I/home/EB/sebastian_h/archive/gcc-git/libgcc/../newlib/libc/sys/rtems/include -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -Dinhibit_libc -I. -I. -I../../.././gcc -I/home/EB/sebastian_h/archive/gcc-git/libgcc -I/home/EB/sebastian_h/archive/gcc-git/libgcc/. -I/home/EB/sebastian_h/archive/gcc-git/libgcc/../gcc -I/home/EB/sebastian_h/archive/gcc-git/libgcc/../include -DHAVE_CC_TLS -o ibm-ldouble.o -MT ibm-ldouble.o -MD -MP -MF ibm-ldouble.dep -c /home/EB/sebastian_h/archive/gcc-git/libgcc/config/rs6000/ibm-ldouble.c -fvisibility=hidden -DHIDE_EXPORTS # the right startup files when linking shared libgcc. /bin/sh /home/EB/sebastian_h/archive/gcc-git/libgcc/../mkinstalldirs ../../.././gcc/m8540 parts="crtbegin.o crtend.o crtbeginS.o crtendS.o crtbeginT.o ecrti.o ecrtn.o ncrti.o ncrtn.o"; \ for file in $parts; do \ rm -f ../../.././gcc/m8540/$file; \ /usr/bin/install -c -m 644 $file ../../.././gcc/m8540/; \ case $file in \ *.a)\ /opt/rtems-4.12/powerpc-rtems4.12/bin/ranlib ../../.././gcc/m8540/$file ;;\ esac; \ done In file included from /home/EB/sebastian_h/archive/gcc-git/libgcc/config/rs6000/ibm-ldouble.c:374:0: /home/EB/sebastian_h/archive/gcc-git/libgcc/soft-fp/quad.h:72:1: error: unable to emulate 'TF' typedef float TFtype __attribute__ ((mode (TF))); ^~~ config.status: creating auto-target.h config.status: auto-target.h is unchanged config.status: executing default commands In file included from /home/EB/sebastian_h/archive/gcc-git/libgcc/soft-fp/soft-fp.h:321:0, from /home/EB/sebastian_h/archive/gcc-git/libgcc/config/rs6000/ibm-ldouble.c:372: /home/EB/sebastian_h/archive/gcc-git/libgcc/config/rs6000/ibm-ldouble.c: In function 'fmsub': /home/EB/sebastian_h/archive/gcc-git/libgcc/soft-fp/op-common.h:900:10: warning: this statement may fall through [-Wimplicit-fallthrough=] R##_s = X##_s; \ /home/EB/sebastian_h/archive/gcc-git/libgcc/soft-fp/quad.h:182:29: note: in expansion of macro '_FP_MUL' # define FP_MUL_Q(R, X, Y) _FP_MUL (Q, 4, R, X, Y) ^~~ /home/EB/sebastian_h/archive/gcc-git/libgcc/config/rs6000/ibm-ldouble.c:417:5: note: in expansion of macro 'FP_MUL_Q' FP_MUL_Q(U,X,Y); ^~~~ /home/EB/sebastian_h/archive/gcc-git/libgcc/soft-fp/op-common.h:902:2: note: here case _FP_CLS_COMBINE (FP_CLS_INF, FP_CLS_INF): \ ^ /home/EB/sebastian_h/archive/gcc-git/libgcc/soft-fp/quad.h:182:29: note: in expansion of macro '_FP_MUL' # define FP_MUL_Q(R, X, Y) _FP_MUL (Q, 4, R, X, Y) ^~~ /home/EB/sebastian_h/archive/gcc-git/libgcc/config/rs6000/ibm-ldouble.c:417:5: note: in expansion of macro 'FP_MUL_Q' FP_MUL_Q(U,X,Y); ^~~~ /home/EB/sebastian_h/archive/gcc-git/libgcc/soft-fp/op-common.h:913:10: warning: this statement may fall through [-Wimplicit-fallthrough=] R##_s = Y##_s; \ /home/EB/sebastian_h/archive/gcc-git/libgcc/soft-fp/quad.h:182:29: note: in expansion of macro '_FP_MUL' # define FP_MUL_Q(R, X, Y) _FP_MUL (Q, 4, R, X
implicit-fallthrough warnings in powerpc64le-linux GCC build
Hello, I noticed some implicit-fallthrough warnings in a powerpc64le-linux GCC build: /home/sh/b-gcc-git/./gcc/xgcc -B/home/sh/b-gcc-git/./gcc/ -B/home/sh/install-gcc-git/powerpc64le-unknown-linux-gnu/bin/ -B/home/sh/install-gcc-git/powerpc64le-unknown-linux-gnu/lib/ -isystem /home/sh/install-gcc-git/powerpc64le-unknown-linux-gnu/include -isystem /home/sh/install-gcc-git/powerpc64le-unknown-linux-gnu/sys-include -g -O2 -O2 -g -O2 -DIN_GCC-W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fPIC -mlong-double-128 -mno-minimal-toc -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -fPIC -mlong-double-128 -mno-minimal-toc -I. -I. -I../.././gcc -I/home/sh/gcc-git/libgcc -I/home/sh/gcc-git/libgcc/. -I/home/sh/gcc-git/libgcc/../gcc -I/home/sh/gcc-git/libgcc/../include -I/home/sh/gcc-git/libgcc/../libdecnumber/dpd -I/home/sh/gcc-git/libgcc/../libdecnumber -DHAVE_CC_TLS -o _ucmpdi2.o -MT _ucmpdi2.o -MD -MP -MF _ucmpdi2.dep -DL_ucmpdi2 -c /home/sh/gcc-git/libgcc/libgcc2.c -fvisibility=hidden -DHIDE_EXPORTS /home/sh/gcc-git/libgcc/soft-fp/op-common.h:900:10: warning: this statement may fall through [-Wimplicit-fallthrough=] R##_s = X##_s; \ /home/sh/gcc-git/libgcc/soft-fp/quad.h:308:29: note: in expansion of macro ‘_FP_MUL’ # define FP_MUL_Q(R, X, Y) _FP_MUL (Q, 2, R, X, Y) ^~~ mulkf3-sw.c:48:3: note: in expansion of macro ‘FP_MUL_Q’ FP_MUL_Q (R, A, B); ^~~~ /home/sh/gcc-git/libgcc/soft-fp/op-common.h:902:2: note: here case _FP_CLS_COMBINE (FP_CLS_INF, FP_CLS_INF): \ ^ /home/sh/gcc-git/libgcc/soft-fp/quad.h:308:29: note: in expansion of macro ‘_FP_MUL’ # define FP_MUL_Q(R, X, Y) _FP_MUL (Q, 2, R, X, Y) ^~~ mulkf3-sw.c:48:3: note: in expansion of macro ‘FP_MUL_Q’ FP_MUL_Q (R, A, B); ^~~~ /home/sh/gcc-git/libgcc/soft-fp/op-common.h:913:10: warning: this statement may fall through [-Wimplicit-fallthrough=] R##_s = Y##_s; \ /home/sh/gcc-git/libgcc/soft-fp/quad.h:308:29: note: in expansion of macro ‘_FP_MUL’ # define FP_MUL_Q(R, X, Y) _FP_MUL (Q, 2, R, X, Y) ^~~ mulkf3-sw.c:48:3: note: in expansion of macro ‘FP_MUL_Q’ FP_MUL_Q (R, A, B); ^~~~ /home/sh/gcc-git/libgcc/soft-fp/op-common.h:915:2: note: here case _FP_CLS_COMBINE (FP_CLS_NORMAL, FP_CLS_INF): \ ^ /home/sh/gcc-git/libgcc/soft-fp/quad.h:308:29: note: in expansion of macro ‘_FP_MUL’ # define FP_MUL_Q(R, X, Y) _FP_MUL (Q, 2, R, X, Y) ^~~ mulkf3-sw.c:48:3: note: in expansion of macro ‘FP_MUL_Q’ FP_MUL_Q (R, A, B); ^~~ I don't know this code enough to fix them. -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
IEEE 128-bit floating point support for PowerPC RTEMS
Hello,
some time ago IEEE 128-bit floating point support for PowerPC was added
to GCC:
https://gcc.gnu.org/wiki/Ieee128PowerPC
I noticed some issues for RTEMS in this area. Firstly, RTEMS had no
__powerpc__ builtin define, so some source files were effectively
disabled, e.g. ibm-ldouble.c. With __powerpc__ defined, the
ibm-ldouble.c didn't compile due to:
In file included from
/home/EB/sebastian_h/archive/gcc-git/libgcc/config/rs6000/ibm-ldouble.c:374:0:
/home/EB/sebastian_h/archive/gcc-git/libgcc/soft-fp/quad.h:72:1: error:
unable to emulate 'TF'
typedef float TFtype __attribute__ ((mode (TF)));
^~~
I added
#define RS6000_DEFAULT_LONG_DOUBLE_SIZE 128
#undef TARGET_IEEEQUAD
#define TARGET_IEEEQUAD 1
This fixed the problem above and changes the long double type from 8
bytes to 16 bytes.
The new compiler defines now (powerpc-rtems target):
#define __LONG_DOUBLE_128__ 1
#define __LONGDOUBLE128 1
#define __LONG_DOUBLE_IEEE128__ 1
However, the libgcc multilib build fails due to several ICEs. See
attached errors.log.
Is this supposed to work for 32-bit PowerPC. Did I miss some magic
configuration switch?
--
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>From 23951fde45ff6b81afd2432866166b0f43401401 Mon Sep 17 00:00:00 2001
From: Sebastian Huber
Date: Tue, 24 Jan 2017 11:20:22 +0100
Subject: [PATCH] Enable IEEE 754R 128-bit FP for powerpc-rtems
---
gcc/config/rs6000/rtems.h | 6 ++
1 file changed, 6 insertions(+)
diff --git a/gcc/config/rs6000/rtems.h b/gcc/config/rs6000/rtems.h
index 54a36de..449de0f 100644
--- a/gcc/config/rs6000/rtems.h
+++ b/gcc/config/rs6000/rtems.h
@@ -25,6 +25,7 @@
do \
{ \
builtin_define_std ("PPC"); \
+ builtin_define_std ("powerpc"); \
builtin_define ("__rtems__"); \
builtin_define ("__USE_INIT_FINI__"); \
builtin_assert ("system=rtems");\
@@ -58,3 +59,8 @@
#undef SUBSUBTARGET_EXTRA_SPECS
#define SUBSUBTARGET_EXTRA_SPECS \
{ "cpp_os_rtems", CPP_OS_RTEMS_SPEC }
+
+#define RS6000_DEFAULT_LONG_DOUBLE_SIZE 128
+
+#undef TARGET_IEEEQUAD
+#define TARGET_IEEEQUAD 1
--
1.8.4.5
make[4]: Entering directory `/build/powerpc-rtems4.12/m403/libgcc'
# If this is the top-level multilib, build all the other
# multilibs.
/build/./gcc/xgcc -B/build/./gcc/ -nostdinc -B/build/powerpc-rtems4.12/newlib/
-isystem /build/powerpc-rtems4.12/newlib/targ-include -isystem
/gcc/newlib/libc/include -B/opt/rtems-4.12/powerpc-rtems4.12/bin/
-B/opt/rtems-4.12/powerpc-rtems4.12/lib/ -isystem
/opt/rtems-4.12/powerpc-rtems4.12/include -isystem
/opt/rtems-4.12/powerpc-rtems4.12/sys-include-g -O2 -mcpu=403 -O2
-I/gcc/libgcc/../newlib/libc/sys/rtems/include -g -O2 -DIN_GCC
-DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition
-isystem ./include -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector
-Dinhibit_libc -I. -I. -I../../.././gcc -I/gcc/libgcc -I/gcc/libgcc/.
-I/gcc/libgcc/../gcc -I/gcc/libgcc/../include -DHAVE_CC_TLS -o _powitf2.o -MT
_powitf2.o -MD -MP -MF _powitf2.dep -DL_powitf2 -c /gcc/libgcc/libgcc2.c
-fvisibility=hidden -DHIDE_EXPORTS
/gcc/libgcc/libgcc2.c: In function '__powitf2':
/gcc/libgcc/libgcc2.c:1882:9: internal compiler error: Segmentation fault
x = x * x;
~~^~~
0x9fa37f crash_signal
/gcc/gcc/toplev.c:333
0x72d1a3 assign_temp(tree_node*, int, int)
/gcc/gcc/function.c:956
0x6c9f56 emit_push_insn(rtx_def*, machine_mode, tree_node*, rtx_def*, unsigned
int, int, rtx_def*, int, rtx_def*, rtx_def*, int, rtx_def*, bool)
/gcc/gcc/expr.c:4314
0x59ceb0 emit_library_call_value_1
/gcc/gcc/calls.c:4838
0x5a3b81 emit_library_call_value(rtx_def*, rtx_def*, libcall_type,
machine_mode, int, ...)
/gcc/gcc/calls.c:5159
0x90763b expand_binop(machine_mode, optab_tag, rtx_def*, rtx_def*, rtx_def*,
int, optab_methods)
/gcc/gcc/optabs.c:1758
0x6b020b expand_mult(machine_mode, rtx_def*, rtx_def*, rtx_def*, int)
/gcc/gcc/expmed.c:3358
0x6d559b expand_expr_real_2(separate_ops*, rtx_def*, machine_mode,
expand_modifier)
/gcc/gcc/expr.c:8792
0x5b3291 expand_gimple_stmt_1
/gcc/gcc/cfgexpand.c:3677
0x5b3291 expand_gimple_stmt
/gcc/gcc/cfgexpand.c:3737
0x5b5399 expand_gimple_basic_block
/gcc/gcc/cfgexpand.c:5744
0x5badf6 execute
/gcc/gcc/cfgexpand.c:6357
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace w
Re: How to configure a bi-arch PowerPC GCC?
On 23/01/17 18:18, Segher Boessenkool wrote:
Hello again,
On Mon, Jan 23, 2017 at 09:19:04AM +0100, Sebastian Huber wrote:
I am flexible in terms of the ABI choice for the 64-bit PowerPC. I guess
the ABI_ELFv2 is the way to go?
It certainly is the most modern ABI. It makes some requirements to what
Power ISA features are required, which may or may not be a problem for
your platform. If you want to use BE, that should work with ELFv2 fine
(and it did in the past at least), but it doesn't get serious testing.
I use now the attached patch and get the following error types (for
several multilibs):
/home/EB/sebastian_h/archive/gcc-git/libgcc/config/rs6000/ibm-ldouble.c:374:0:
/home/EB/sebastian_h/archive/gcc-git/libgcc/soft-fp/quad.h:72:1: error:
unable to emulate 'TF'
typedef float TFtype __attribute__ ((mode (TF)));
^~~
From rs6000.c (rs6000_scalar_mode_supported_p):
else if (TARGET_FLOAT128_TYPE && (mode == KFmode || mode == IFmode))
return true;
else
return default_scalar_mode_supported_p (mode);
and the latter has
if (precision == LONG_DOUBLE_TYPE_SIZE)
return true;
return false;
so you have no 128-bit FP type at all. Maybe your TARGET_IEEEQUAD definition
is wrong, maybe something else... What type *do* you want for float128?
I disabled the ibm-ldouble.c for RTEMS. Enabling the 128-bit FP support
for the 32-bit powerpc-rtems resulted in a lot of ICEs.
https://gcc.gnu.org/ml/gcc/2017-01/msg00215.html
With -m64 I set now:
+ if (rs6000_isa_flags & OPTION_MASK_64BIT)\
+ { \
+ rs6000_long_double_type_size = 128; \
+ rs6000_elf_abi = 2; \
+ rs6000_current_abi = ABI_ELFv2; \
+ rs6000_isa_flags &= ~OPTION_MASK_EABI; \
/home/EB/sebastian_h/archive/gcc-git/libgcc/unwind-dw2-fde.c: In
function 'search_object':
/home/EB/sebastian_h/archive/gcc-git/libgcc/unwind-dw2-fde.c:588:25:
internal compiler error: in emit_move_insn, at expr.c:3698
v1->array[i1+i2] = v1->array[i1-1];
~^
0x6c49bb emit_move_insn(rtx_def*, rtx_def*)
/home/EB/sebastian_h/archive/gcc-git/gcc/expr.c:3697
0x6a5c2b force_reg
/home/EB/sebastian_h/archive/gcc-git/gcc/explow.c:648
0xd61994 rs6000_legitimize_address
/home/EB/sebastian_h/archive/gcc-git/gcc/config/rs6000/rs6000.c:8873
rs6000_legitimize_address called force_reg which ICEs in emit_move_insn
because the source is not the same mode as the dest (or an immediate, etc.)
You'll have to debug this a bit more to see what is going on.
I still get a lot of ICEs with the attached two patches (examples):
/home/EB/sebastian_h/archive/gcc-git/libgcc/libgcc2.c: In function
'__multc3':
/home/EB/sebastian_h/archive/gcc-git/libgcc/libgcc2.c:2035:1: error:
unrecognizable insn:
}
^
(insn 59 58 60 2 (set (reg:CCFP 219)
(compare:CCFP (reg/v:TF 193 [ x ])
(reg/v:TF 193 [ x ])))
"/home/EB/sebastian_h/archive/gcc-git/libgcc/libgcc2.c":1990 -1
(nil))
/home/EB/sebastian_h/archive/gcc-git/libgcc/libgcc2.c:2035:1: internal
compiler error: in extract_insn, at recog.c:2311
0x9945f5 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/home/EB/sebastian_h/archive/gcc-git/gcc/rtl-error.c:108
0x994629 _fatal_insn_not_found(rtx_def const*, char const*, int, char
const*)
/home/EB/sebastian_h/archive/gcc-git/gcc/rtl-error.c:116
0x965ee7 extract_insn(rtx_insn*)
/home/EB/sebastian_h/archive/gcc-git/gcc/recog.c:2311
0x7238c2 instantiate_virtual_regs_in_insn
/home/EB/sebastian_h/archive/gcc-git/gcc/function.c:1589
0x7238c2 instantiate_virtual_regs
/home/EB/sebastian_h/archive/gcc-git/gcc/function.c:1957
0x7238c2 execute
/home/EB/sebastian_h/archive/gcc-git/gcc/function.c:2006
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
/home/EB/sebastian_h/archive/gcc-git/libgcc/unwind-dw2-fde.c: In
function 'search_object':
/home/EB/sebastian_h/archive/gcc-git/libgcc/unwind-dw2-fde.c:588:25:
internal compiler error: in emit_move_insn, at expr.c:3698
v1->array[i1+i2] = v1->array[i1-1];
~^
0x6c54ab emit_move_insn(rtx_def*, rtx_def*)
/home/EB/sebastian_h/archive/gcc-git/gcc/expr.c:3697
0x6a68eb force_reg
/home/EB/sebastian_h/archive/gcc-git/gcc/explow.c:648
0xd6bbc4 rs6000_legitimize_address
/home/EB/sebastian_h/archive/gcc-git/gcc/config/rs6000/rs6000.c:8871
0x6a76e1 memory_address_addr_space(machine_mode, rtx_def*, unsigned char)
/home/EB/sebastian_h/archive/gcc-git/gcc/explow.c:432
0x6c0551 expand_expr_real_1(tree_node*, rtx
Re: How to configure a bi-arch PowerPC GCC?
On 25/01/17 18:55, Segher Boessenkool wrote: On Wed, Jan 25, 2017 at 01:11:49PM +0100, Sebastian Huber wrote: >I still get a lot of ICEs with the attached two patches (examples): >/home/EB/sebastian_h/archive/gcc-git/libgcc/libgcc2.c: In function >'__multc3': >/home/EB/sebastian_h/archive/gcc-git/libgcc/libgcc2.c:2035:1: error: >unrecognizable insn: > } > ^ >(insn 59 58 60 2 (set (reg:CCFP 219) > (compare:CCFP (reg/v:TF 193 [ x ]) > (reg/v:TF 193 [ x ]))) >"/home/EB/sebastian_h/archive/gcc-git/libgcc/libgcc2.c":1990 -1 > (nil)) >/home/EB/sebastian_h/archive/gcc-git/libgcc/libgcc2.c:2035:1: internal >compiler error: in extract_insn, at recog.c:2311 The IEEE128 code almost certainly has some bugs on non-Linux configurations. You could try debugging it, or you could avoid it (for now) by e.g. making long double the same as double. If I set rs6000_long_double_type_size to 64, then I can build all libgcc multilibs including the one for -m64 -mcpu=e6500. I am a bit surprised that the GCC support for 64-bit PowerPC is so extremely Linux-dependent. I guess that I have to figure out all the magic configuration bits to get everything set up like it is on Linux. It would be nice if the working Linux configuration bits are the default. With rs6000_long_double_type_size == 128, then I get the attached ICEs. I would be glad to get some advice how I can debug them, since I have no idea how the compiler works actually if it comes to code generation. -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. /build/git-build/b-gcc-git-powerpc-rtems4.12/./gcc/xgcc -B/build/git-build/b-gcc-git-powerpc-rtems4.12/./gcc/ -nostdinc -B/build/git-build/b-gcc-git-powerpc-rtems4.12/powerpc-rtems4.12/newlib/ -isystem /build/git-build/b-gcc-git-powerpc-rtems4.12/powerpc-rtems4.12/newlib/targ-include -isystem /home/EB/sebastian_h/archive/gcc-git/newlib/libc/include -B/opt/rtems-4.12/powerpc-rtems4.12/bin/ -B/opt/rtems-4.12/powerpc-rtems4.12/lib/ -isystem /opt/rtems-4.12/powerpc-rtems4.12/include -isystem /opt/rtems-4.12/powerpc-rtems4.12/sys-include-g -O2 -mcpu=e6500 -m64 -O2 -I/home/EB/sebastian_h/archive/gcc-git/libgcc/../newlib/libc/sys/rtems/include -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -Dinhibit_libc -I. -I. -I../../../.././gcc -I/home/EB/sebastian_h/archive/gcc-git/libgcc -I/home/EB/sebastian_h/archive/gcc-git/libgcc/. -I/home/EB/sebastian_h/archive/gcc-git/libgcc/../gcc -I/home/EB/sebastian_h/archive/gcc-git/libgcc/../include -DHAVE_CC_TLS -o _multc3.o -MT _multc3.o -MD -MP -MF _multc3.dep -DL_multc3 -c /home/EB/sebastian_h/archive/gcc-git/libgcc/libgcc2.c -fvisibility=hidden -DHIDE_EXPORTS /home/EB/sebastian_h/archive/gcc-git/libgcc/libgcc2.c: In function '__multc3': /home/EB/sebastian_h/archive/gcc-git/libgcc/libgcc2.c:2035:1: error: unrecognizable insn: } ^ (insn 59 58 60 2 (set (reg:CCFP 219) (compare:CCFP (reg/v:TF 193 [ x ]) (reg/v:TF 193 [ x ]))) "/home/EB/sebastian_h/archive/gcc-git/libgcc/libgcc2.c":1990 -1 (nil)) /home/EB/sebastian_h/archive/gcc-git/libgcc/libgcc2.c:2035:1: internal compiler error: in extract_insn, at recog.c:2311 0x994ea5 _fatal_insn(char const*, rtx_def const*, char const*, int, char const*) /home/EB/sebastian_h/archive/gcc-git/gcc/rtl-error.c:108 0x994ed9 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*) /home/EB/sebastian_h/archive/gcc-git/gcc/rtl-error.c:116 0x966797 extract_insn(rtx_insn*) /home/EB/sebastian_h/archive/gcc-git/gcc/recog.c:2311 0x723ca2 instantiate_virtual_regs_in_insn /home/EB/sebastian_h/archive/gcc-git/gcc/function.c:1589 0x723ca2 instantiate_virtual_regs /home/EB/sebastian_h/archive/gcc-git/gcc/function.c:1957 0x723ca2 execute /home/EB/sebastian_h/archive/gcc-git/gcc/function.c:2006 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <http://gcc.gnu.org/bugs.html> for instructions. make[4]: [_multc3.o] Error 1 (ignored) /build/git-build/b-gcc-git-powerpc-rtems4.12/./gcc/xgcc -B/build/git-build/b-gcc-git-powerpc-rtems4.12/./gcc/ -nostdinc -B/build/git-build/b-gcc-git-powerpc-rtems4.12/powerpc-rtems4.12/newlib/ -isystem /build/git-build/b-gcc-git-powerpc-rtems4.12/powerpc-rtems4.12/newlib/targ-include -isystem /home/EB/sebastian_h/archive/gcc-git/newlib/libc/include -B/opt/rtems-4.12/po
Re: How to configure a bi-arch PowerPC GCC?
On 30/01/17 11:38, Sebastian Huber wrote: On 25/01/17 18:55, Segher Boessenkool wrote: On Wed, Jan 25, 2017 at 01:11:49PM +0100, Sebastian Huber wrote: >I still get a lot of ICEs with the attached two patches (examples): >/home/EB/sebastian_h/archive/gcc-git/libgcc/libgcc2.c: In function >'__multc3': >/home/EB/sebastian_h/archive/gcc-git/libgcc/libgcc2.c:2035:1: error: >unrecognizable insn: > } > ^ >(insn 59 58 60 2 (set (reg:CCFP 219) > (compare:CCFP (reg/v:TF 193 [ x ]) > (reg/v:TF 193 [ x ]))) >"/home/EB/sebastian_h/archive/gcc-git/libgcc/libgcc2.c":1990 -1 > (nil)) >/home/EB/sebastian_h/archive/gcc-git/libgcc/libgcc2.c:2035:1: internal >compiler error: in extract_insn, at recog.c:2311 The IEEE128 code almost certainly has some bugs on non-Linux configurations. You could try debugging it, or you could avoid it (for now) by e.g. making long double the same as double. If I set rs6000_long_double_type_size to 64, then I can build all libgcc multilibs including the one for -m64 -mcpu=e6500. I am a bit surprised that the GCC support for 64-bit PowerPC is so extremely Linux-dependent. I guess that I have to figure out all the magic configuration bits to get everything set up like it is on Linux. It would be nice if the working Linux configuration bits are the default. With rs6000_long_double_type_size == 128, then I get the attached ICEs. I would be glad to get some advice how I can debug them, since I have no idea how the compiler works actually if it comes to code generation. The compiler build shows these warnings: /home/EB/sebastian_h/archive/gcc-git/gcc/config/rs6000/rs6000.md:11023:1: warning: source missing a mode? /home/EB/sebastian_h/archive/gcc-git/gcc/config/rs6000/rs6000.md:11034:1: warning: source missing a mode? /home/EB/sebastian_h/archive/gcc-git/gcc/config/rs6000/rs6000.md:11034:1: warning: source missing a mode? /home/EB/sebastian_h/archive/gcc-git/gcc/config/rs6000/rs6000.md:11050:1: warning: source missing a mode? /home/EB/sebastian_h/archive/gcc-git/gcc/config/rs6000/rs6000.md:11050:1: warning: source missing a mode? /home/EB/sebastian_h/archive/gcc-git/gcc/config/rs6000/rs6000.md:11060:1: warning: source missing a mode? /home/EB/sebastian_h/archive/gcc-git/gcc/config/rs6000/rs6000.md:11060:1: warning: source missing a mode? /home/EB/sebastian_h/archive/gcc-git/gcc/config/rs6000/rs6000.md:11998:1: warning: operand 1 missing mode? /home/EB/sebastian_h/archive/gcc-git/gcc/config/rs6000/spe.md:3467:1: warning: operand 1 missing mode? /home/EB/sebastian_h/archive/gcc-git/gcc/config/rs6000/spe.md:3467:1: warning: operand 2 missing mode? Statistics for recog: Number of decisions: 15193 longest path: 604 (code:593) longest backtrack: 43 (code: 1619) Statistics for split_insns: Number of decisions: 2991 longest path:53 (code:576) longest backtrack: 18 (code:574) Statistics for peephole2_insns: Number of decisions:267 longest path:47 (code: 7) longest backtrack: 3 (code: 26) Is this something to worry about? -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
Re: Obsolete powerpc*-*-*spe*
Hello Segher, On 14/02/17 04:07, Segher Boessenkool wrote: Hi all, I propose to mark powerpc*-*-*spe* as obsolete in GCC 7. This includes the spe.h installed header file, all the __builtin_spe* intrinsics, the -mfloat-gprs= command-line option, and the support for the SPE ABIs. No one has properly tested these targets in a long time (the latest testresults I could find are from July 2015, >1000 failures), and the SPE support makes a lot of code much more complex. Any objections to this obsoletion? GCC 7 will then be the last release with support for SPE (it will need --enable-obsolete to build these targets), and we will delete the SPE support during GCC 8 development. the SPE unit is still used in the embedded PowerPC processors from Freescale/NXP/Qualcomm, for example QorIQ P1020. These products are not obsolete or even not recommended for new designs. These chips have a long product life-cycle. Its a pity that Freescale/NXP/Qualcomm stopped to support GCC development and IBM is burdened to take care of this. I can understand your reasoning, however, its not true that there are no users of the SPE unit. -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
Re: Obsolete powerpc*-*-*spe*
On 14/02/17 15:09, David Brown wrote: On 14/02/17 12:55, Sebastian Huber wrote: Hello Segher, On 14/02/17 04:07, Segher Boessenkool wrote: Hi all, I propose to mark powerpc*-*-*spe* as obsolete in GCC 7. This includes the spe.h installed header file, all the __builtin_spe* intrinsics, the -mfloat-gprs= command-line option, and the support for the SPE ABIs. No one has properly tested these targets in a long time (the latest testresults I could find are from July 2015, >1000 failures), and the SPE support makes a lot of code much more complex. Any objections to this obsoletion? GCC 7 will then be the last release with support for SPE (it will need --enable-obsolete to build these targets), and we will delete the SPE support during GCC 8 development. the SPE unit is still used in the embedded PowerPC processors from Freescale/NXP/Qualcomm, for example QorIQ P1020. These products are not obsolete or even not recommended for new designs. These chips have a long product life-cycle. It is also used in many PPC based microcontrollers, which are used in the automotive industry and other places where you need highly reliable and robust but powerful microcontrollers. However, gcc support for these has traditionally been poor - there is little support for the variety of cores and configurations available from Freescale/NXP. I believe there is a chicken-and-egg situation here - few people use gcc with these devices because there is poorer device support compared to Freescale CodeWarrior or Green Hills, and there is little incentive for gcc developers (such as the CodeSourcery or IBM PPC folks) to support devices in gcc if no one uses that combination. Yes, we use GCC also one these chips, however, due to the lack of VLE support the situation is even worse. Looks like support for the non-IBM PowerPC is dead in GCC. I can understand this pretty well. With the Qualcomm takeover of Freescale/NXP I guess the PowerPC has no future in this area and they will move to ARM for the processor cores. Its a pity that Freescale/NXP/Qualcomm stopped to support GCC development and IBM is burdened to take care of this. I can understand your reasoning, however, its not true that there are no users of the SPE unit. I think what would be needed would be for Freescale/NXP/Qualcomm to put some money and effort in here, with the aim of making gcc their standard compiler for these targets (as they have done for ARM, replacing the old CodeWarrior compiler). Failing that, it is of course better to have no SPE support than broken SPE support, especially if it makes development harder for other devices. Yes, in case Qualcomm shows no interest to support their PowerPC stuff in GCC its quite understandable to remove the support for it eventually. IBM already did a great job in keeping it up and running for a long time. -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
Re: [contribution] C11 threads implementation for Unix and Windows environments
Hello Gokan, you may have a look at: https://svnweb.freebsd.org/base/head/lib/libstdthreads/ -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
Re: __sync_-builtins cause undefined references on some sparc targets
On 03/03/17 13:23, Eric Botcazou wrote:
Is libbacktrace excluded from the build, or is it build but broken?
Neither, it's presumably falls back to __atomic. No big deal in any case,
since you'll presumably never use libbacktrace in practice.
We have (libgcc/config/gthr-rtems.h)
static inline int
__gthread_active_p (void)
{
return 1;
}
and (libgfortran/runtime/backtrace.c)
void
show_backtrace (bool in_signal_handler)
{
struct backtrace_state *lbstate;
struct mystate state = { 0, false, in_signal_handler };
lbstate = backtrace_create_state (NULL, __gthread_active_p (),
error_callback, NULL);
and (libgfortran/runtime/backtrace.c)
struct backtrace_state *
backtrace_create_state (const char *filename, int threaded,
backtrace_error_callback error_callback,
void *data)
{
struct backtrace_state init_state;
struct backtrace_state *state;
#ifndef HAVE_SYNC_FUNCTIONS
if (threaded)
{
error_callback (data, "backtrace library does not support
threads", 0);
return NULL;
}
#endif
So, I doubt this works for RTEMS.
I guess libgfortran needs an option to be a bit less verbose on some
targets.
--
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
Re: Obsolete powerpc*-*-*spe*
On 16/03/17 22:16, Andrew Jenner wrote: On 16/03/2017 21:11, Segher Boessenkool wrote: The e200z3 upwards have SPE units. None of them have classic FP. So it would make most sense for the e200/VLE support to be part of the SPE backend rather than the classic PowerPC backend. Great to hear! And all e300 are purely "classic"? That's one I'm less familiar with (as we don't deliver a multilib for it), but yes - my understanding is that this is classic core. Yes, the e300 is a classic PowerPC. It is a successor of the 603e. The name e300 is confusing. It is quite unrelated to the e200 and e500 cores. -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
Re: GCC 6.4 Status Report (2016-12-21)
Hello, GCC 7.1 was released this week. Are there any plans for a GCC 6.4 release? -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
Read-only *.ali files in adalib installation?
Hello, I built an Ada cross-compiler and noticed that all the *.ali files in adalib are read-only, e.g. ll /opt/rtems-4.12/lib64/gcc/powerpc-rtems4.12/7.1.1/adalib/ [...] -r--r--r-- 1 sebastian_h domain users 5210 Jun 12 14:06 i-fortra.ali -r--r--r-- 1 sebastian_h domain users 2769 Jun 12 14:06 interfac.ali -r--r--r-- 1 sebastian_h domain users 805 Jun 12 14:06 ioexcept.ali -r--r--r-- 1 sebastian_h domain users 4179 Jun 12 14:06 i-pacdec.ali -rw-r--r-- 1 sebastian_h domain users 1450556 Jun 12 14:30 libgnarl.a -rw-r--r-- 1 sebastian_h domain users 16076716 Jun 12 14:30 libgnat.a [...] This is unlike the lib*.a files, which are user writeable. Its this intentional? In a GCC installation with C, C++ and Ada only files of the Ada domain have 0444 access permissions, e.g. find /opt/rtems-4.12/ -perm 0444 | grep -v ada outputs nothing and we have find /opt/rtems-4.12/ -perm 0444 | wc 109750 109750 9202043 -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
Re: How to configure a bi-arch PowerPC GCC?
On 30/01/17 11:38, Sebastian Huber wrote:
On 25/01/17 18:55, Segher Boessenkool wrote:
On Wed, Jan 25, 2017 at 01:11:49PM +0100, Sebastian Huber wrote:
>I still get a lot of ICEs with the attached two patches (examples):
>/home/EB/sebastian_h/archive/gcc-git/libgcc/libgcc2.c: In function
>'__multc3':
>/home/EB/sebastian_h/archive/gcc-git/libgcc/libgcc2.c:2035:1: error:
>unrecognizable insn:
> }
> ^
>(insn 59 58 60 2 (set (reg:CCFP 219)
> (compare:CCFP (reg/v:TF 193 [ x ])
> (reg/v:TF 193 [ x ])))
>"/home/EB/sebastian_h/archive/gcc-git/libgcc/libgcc2.c":1990 -1
> (nil))
>/home/EB/sebastian_h/archive/gcc-git/libgcc/libgcc2.c:2035:1: internal
>compiler error: in extract_insn, at recog.c:2311
The IEEE128 code almost certainly has some bugs on non-Linux
configurations.
You could try debugging it, or you could avoid it (for now) by e.g.
making
long double the same as double.
If I set rs6000_long_double_type_size to 64, then I can build all
libgcc multilibs including the one for -m64 -mcpu=e6500. I am a bit
surprised that the GCC support for 64-bit PowerPC is so extremely
Linux-dependent. I guess that I have to figure out all the magic
configuration bits to get everything set up like it is on Linux. It
would be nice if the working Linux configuration bits are the default.
With rs6000_long_double_type_size == 128, then I get the attached ICEs.
I would be glad to get some advice how I can debug them, since I have
no idea how the compiler works actually if it comes to code generation.
I gave it a new try after the SPE split up. I still have problems to
build a bi-arch PowerPC compiler for RTEMS. I get an ICE with this test
case:
typedef float TFtype __attribute__ ((mode (TF)));
void
f (TFtype b)
{
if (b - b) {
__asm__ volatile ("");
}
}
xgcc -B/build/git-build/b-gcc-git-powerpc-rtems4.12/./gcc/ -mcpu=e6500
-m64 -O2 -fpreprocessed -S test-v0.i -o /dev/null 2>&1
test-v0.i: In function 'f':
test-v0.i:8:1: error: unrecognizable insn:
}
^
(insn 12 11 13 2 (set (reg:CCFP 126)
(compare:CCFP (reg:TF 123)
(reg:TF 124))) "test-v0.i":5 -1
(nil))
during RTL pass: vregs
test-v0.i:8:1: internal compiler error: in extract_insn, at recog.c:2311
0x40a233 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/home/EB/sebastian_h/archive/gcc-git/gcc/rtl-error.c:108
0x40a252 _fatal_insn_not_found(rtx_def const*, char const*, int, char
const*)
/home/EB/sebastian_h/archive/gcc-git/gcc/rtl-error.c:116
0x965abf extract_insn(rtx_insn*)
/home/EB/sebastian_h/archive/gcc-git/gcc/recog.c:2311
0x71dd73 instantiate_virtual_regs_in_insn
/home/EB/sebastian_h/archive/gcc-git/gcc/function.c:1589
0x71dd73 instantiate_virtual_regs
/home/EB/sebastian_h/archive/gcc-git/gcc/function.c:1957
0x71dd73 execute
/home/EB/sebastian_h/archive/gcc-git/gcc/function.c:2006
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
I built a native GCC on gcc112. It produces:
./install-gcc-git/bin/gcc -S -O2 -mcpu=e6500 -m64 -o - test.c
.file "test.c"
.abiversion 2
.globl __gcc_qsub
.section".text"
.align 2
.p2align 4,,15
.globl f
.type f, @function
f:
.LCF0:
0: addis 2,12,.TOC.-.LCF0@ha
addi 2,2,.TOC.-.LCF0@l
.localentry f,.-f
fmr 4,2
mflr 0
fmr 3,1
std 0,16(1)
stdu 1,-32(1)
bl __gcc_qsub
nop
addis 9,2,.LC0@toc@ha
addi 9,9,.LC0@toc@l
lfd 12,0(9)
lfd 13,8(9)
fcmpu 7,1,12
bne 7,$+8
fcmpu 7,2,13
beq- 7,.L1
.L1:
addi 1,1,32
ld 0,16(1)
mtlr 0
blr
.long 0
.byte 0,0,0,1,128,0,0,0
.size f,.-f
.section.rodata.cst16,"aM",@progbits,16
.align 4
.LC0:
.long 0
.long 0
.long 0
.long 0
.ident "GCC: (GNU) 8.0.0 20170720 (experimental) [master
revision f37822f:0bf6d30:61658d61fdbd0e76bb1b7ea20c3bb8dc334568cd]"
.gnu_attribute 4, 5
.section.note.GNU-stack,"",@progbits
So, I looked for " __gcc_qsub" in the GCC sources. It seems this is
generated by rs6000_init_libfuncs() for some "sub_optab" stuff. If I run
my bi-arch GCC in GDB, then I get:
Breakpoint 1, rs6000_init_libfuncs () at
/home/EB/sebastian_h/archive/gcc-git/gcc/config/rs6000/rs6000.c:18670
18670 if (TARGET_FLOAT128_TYPE)
(gdb) n
18677 if (TARGET_LONG_DOUBLE_128)
(gdb)
18684 init_float128_ieee (TFmode);
(gdb) s
init_float128_ieee (mode=TFmode) at
/home/EB/se
GCC Runtime Library Exception in gcc/config/* files?
Hello, there are some files in gcc/config/* that contain the GCC Runtime Library Exception grep -r --include='*.[ch]' 'GCC Runtime Library Exception' -l gcc/config | wc 186 1865361 and some files that don't include it grep -r --include='*.[ch]' 'GCC Runtime Library Exception' -l gcc/config -v | wc 753 753 20927 Does it matter? What should be used for new files? -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
Re: GCC Runtime Library Exception in gcc/config/* files?
On 21/07/17 15:50, Ian Lance Taylor wrote: On Fri, Jul 21, 2017 at 2:24 AM, Sebastian Huber wrote: there are some files in gcc/config/* that contain the GCC Runtime Library Exception grep -r --include='*.[ch]' 'GCC Runtime Library Exception' -l gcc/config | wc 186 1865361 and some files that don't include it grep -r --include='*.[ch]' 'GCC Runtime Library Exception' -l gcc/config -v | wc 753 753 20927 Does it matter? What should be used for new files? I think that in general we should probably use the Runtime Library Exception for header files that might need to be included by a plugin, which means anything that might be included by tm.h. But I can't think of any reason to use the Exception for .c files. For example gcc/config/rs6000/linux64.h has the GCC Runtime Library Exception, but gcc/config/rs6000/freebsd64.h has it not. I update currently gcc/config/rs6000/rtems.h to support 64-bit, so know I am a bit confused. -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
64-bit PowerPC and small data area?
Hello,
in the PowerPC ELFv2 specification
https://members.openpowerfoundation.org/document/dl/576
we have
"3.4.2 Use of the Small Data Area
For a data item in the .sdata or .sbss sections, a compiler may generate
short-form one-instruction refer-
ences. In an executable file or shared library, such a reference is
relative to the address of the TOC base
symbol (which can be obtained from r2 if a TOC pointer is initialized).
A compiler that generates code using
the small data area should provide an option to select the maximum size
of objects placed in the small data
area, and a means of disabling any use of the small data area. When
generating code for ELF shared
libraries, the small data area should not be used for default-visibility
global objects. This is to satisfy ELF
shared-library symbol interposition rules. That is, an ordinary global
symbol in a shared library may be over-
ridden by a symbol of the same name defined in the executable or another
shared library. Supporting interpo-
sition when using TOC-pointer relative addressing would require text
relocations."
I tried to generate code using the small data area on a 64-bit PowerPC
GCC, but I was not successful. We have in the GCC sources
(gcc/config/rs6000/rs6000.c):
/* Return 1 for an operand in small memory on V.4/eabi. */
int
small_data_operand (rtx op ATTRIBUTE_UNUSED,
machine_mode mode ATTRIBUTE_UNUSED)
{
#if TARGET_ELF
rtx sym_ref;
if (rs6000_sdata == SDATA_NONE || rs6000_sdata == SDATA_DATA)
return 0;
if (DEFAULT_ABI != ABI_V4)
return 0;
So, it looks like the small data stuff is not support for ABI_ELFv2? Are
there main issues with the small data area using ELVv2 or is this simply
not implemented due to a lack of interested?
--
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
Re: 64-bit PowerPC and small data area?
- Segher Boessenkool schrieb: > Hi! > > On Tue, Jul 25, 2017 at 02:38:45PM +0200, Sebastian Huber wrote: > > So, it looks like the small data stuff is not support for ABI_ELFv2? Are > > there main issues with the small data area using ELVv2 or is this simply > > not implemented due to a lack of interested? > > It is just not implemented. ELFv2 is so far only used on Linux, and > only on LE at that (BE is not regularly tested). Ok, thank you for the clarification. > Will this buy you anything though? Small data already ends up in the > TOC. Do you / should you use -mcmodel=small? Yes, we use statically linked applications together with the operating system (< 32MiB). So, we don't need this fancy stuff for the dynamic libraries. Is there a 64-bit ABI with ready to use support for the small data area? -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.huber at embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
How to support 64-bit PowerPC -mcmodel=medium?
Hello,
it seems that the -mcmodel=small was not the right default for RTEMS
applications, since I get
relocation truncated to fit: R_PPC64_TOC16_DS against `.got'+118
errors quite quickly.
So, I try to add the -mcmodel option. However, some piece is missing:
/build/git-build/b-gcc-git-powerpc-rtems4.12/./gcc/xgcc
-B/build/git-build/b-gcc-git-powerpc-rtems4.12/./gcc/ -nostdinc
-B/build/git-build/b-gcc-git-powerpc-rtems4.12/powerpc-rtems4.12/me6500/m64/newlib/
-isystem
/build/git-build/b-gcc-git-powerpc-rtems4.12/powerpc-rtems4.12/me6500/m64/newlib/targ-include
-isystem /home/EB/sebastian_h/archive/gcc-git/newlib/libc/include
-B/opt/rtems-4.12/powerpc-rtems4.12/bin/
-B/opt/rtems-4.12/powerpc-rtems4.12/lib/ -isystem
/opt/rtems-4.12/powerpc-rtems4.12/include -isystem
/opt/rtems-4.12/powerpc-rtems4.12/sys-include -mcpu=e6500 -m64 -g -O2
-O2 -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall
-Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes
-Wmissing-prototypes -Wold-style-definition -isystem ./include -I. -I.
-I../../../.././gcc -I/home/EB/sebastian_h/archive/gcc-git/libgcc
-I/home/EB/sebastian_h/archive/gcc-git/libgcc/.
-I/home/EB/sebastian_h/archive/gcc-git/libgcc/../gcc
-I/home/EB/sebastian_h/archive/gcc-git/libgcc/../include -g0
-finhibit-size-directive -fno-inline -fno-exceptions
-fno-zero-initialized-in-bss -fno-toplevel-reorder -fno-tree-vectorize
-fbuilding-libgcc -fno-stack-protector -Dinhibit_libc -I. -I.
-I../../../.././gcc -I/home/EB/sebastian_h/archive/gcc-git/libgcc
-I/home/EB/sebastian_h/archive/gcc-git/libgcc/.
-I/home/EB/sebastian_h/archive/gcc-git/libgcc/../gcc
-I/home/EB/sebastian_h/archive/gcc-git/libgcc/../include -o crtbeginS.o
-MT crtbeginS.o -MD -MP -MF crtbeginS.dep -msdata=none -O2 -c
/home/EB/sebastian_h/archive/gcc-git/libgcc/crtstuff.c -DCRT_BEGIN
-DCRTSTUFFS_O -fPIC -mcmodel=medium -save-temps
crtstuff.s: Assembler messages:
crtstuff.s:44: Error: can't resolve `.tm_clone_table' {.tm_clone_table
section} - `.LCTOC1' {.toc1 section}
crtstuff.s:45: Error: can't resolve `__TMC_END__' {*UND* section} -
`.LCTOC1' {.toc1 section}
crtstuff.s:82: Error: can't resolve `.tm_clone_table' {.tm_clone_table
section} - `.LCTOC1' {.toc1 section}
crtstuff.s:83: Error: can't resolve `__TMC_END__' {*UND* section} -
`.LCTOC1' {.toc1 section}
crtstuff.s:131: Error: can't resolve `.bss' {.bss section} - `.LCTOC1'
{.toc1 section}
crtstuff.s:143: Error: can't resolve `__dso_handle' {.sdata section} -
`.LCTOC1' {.toc1 section}
crtstuff.s:149: Error: can't resolve `__DTOR_END__' {*UND* section} -
`.LCTOC1' {.toc1 section}
crtstuff.s:150: Error: can't resolve `.dtors' {.dtors section} -
`.LCTOC1' {.toc1 section}
crtstuff.s:153: Error: can't resolve `.bss' {.bss section} - `.LCTOC1'
{.toc1 section}
crtstuff.s:157: Error: can't resolve `.dtors' {.dtors section} -
`.LCTOC1' {.toc1 section}
crtstuff.s:162: Error: can't resolve `.bss' {.bss section} - `.LCTOC1'
{.toc1 section}
crtstuff.s:185: Error: can't resolve `.eh_frame' {.eh_frame section} -
`.LCTOC1' {.toc1 section}
crtstuff.s:192: Error: can't resolve `.bss' {.bss section} - `.LCTOC1'
{.toc1 section}
crtstuff.s:226: Error: can't resolve `.bss' {.bss section} - `.LCTOC1'
{.toc1 section}
crtstuff.s:227: Error: can't resolve `.eh_frame' {.eh_frame section} -
`.LCTOC1' {.toc1 section}
The code generation works with -mcmodel=small and -mcmodel=large.
--
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>From 7d2b18f303cc7cf62d29328b362e645027884270 Mon Sep 17 00:00:00 2001
From: Sebastian Huber
Date: Fri, 11 Aug 2017 11:26:19 +0200
Subject: [PATCH] PowerPC/RTEMS: Enable -mcmodel option
---
gcc/config.gcc| 2 +-
gcc/config/rs6000/rtems.h | 47 +++
2 files changed, 48 insertions(+), 1 deletion(-)
diff --git a/gcc/config.gcc b/gcc/config.gcc
index a9196cd26d9..593631849bb 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -2416,7 +2416,7 @@ powerpc-*-eabi*)
;;
powerpc-*-rtems*)
tm_file="rs6000/biarch64.h ${tm_file} dbxelf.h elfos.h freebsd-spec.h newlib-stdint.h rs6000/sysv4.h rs6000/e500.h rs6000/rtems.h rtems.h"
- extra_options="${extra_options} rs6000/sysv4.opt"
+ extra_options="${extra_options} rs6000/sysv4.opt rs6000/linux64.opt"
tmake_file="${tmake_file} rs6000/t-fprules rs6000/t-rtems rs6000/t-ppccomm"
;;
powerpc*-*-linux*)
diff --git a/gcc/config/rs6000/rtems.h b/gcc/config/rs6000/rtems.h
Re: How to support 64-bit PowerPC -mcmodel=medium?
On 12/08/17 01:15, Segher Boessenkool wrote:
On Fri, Aug 11, 2017 at 11:33:08AM +0200, Sebastian Huber wrote:
crtstuff.s: Assembler messages:
crtstuff.s:44: Error: can't resolve `.tm_clone_table' {.tm_clone_table
section} - `.LCTOC1' {.toc1 section}
crtstuff.s:45: Error: can't resolve `__TMC_END__' {*UND* section} -
`.LCTOC1' {.toc1 section}
Maybe you want to
#define USE_TM_CLONE_REGISTRY 0
for your subtarget?
I don't see what is the real problem causing your issues, but that
should allow you to get further at least.
I had to do this:
https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=251275
The main issue was that I didn't define RS6000_ABI_NAME, so
SUBTARGET_OVERRIDE_OPTIONS() from sysv4.h selected ABI_V4. This triggered:
if (flag_pic > 1 && DEFAULT_ABI == ABI_V4) \
{\
/* Note: flag_pic should not change any option flags that would\
be invalid with or pessimise -fno-PIC code. LTO turns off\
flag_pic when linking/recompiling a fixed position executable. \
However, if the objects were originally compiled with -fPIC, \
then other target options forced on here by -fPIC are restored \
when recompiling those objects without -fPIC. In particular \
TARGET_RELOCATABLE must not be enabled here by flag_pic. */ \
rs6000_isa_flags |= OPTION_MASK_MINIMAL_TOC;\
TARGET_NO_FP_IN_TOC = 1;\
}
The minimal TOC option apparently didn't work well for the crtbeginS.o.
With this patch I am now able to build RTEMS with the FreeBSD network
stack utilizing > 4GiB of RAM on a T4240. Segher, thanks for your kind
help. Without your help I would still struggle with the GCC configuration.
--
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
Re: How to configure a bi-arch PowerPC GCC?
On 13/09/17 15:11, Andreas Schwab wrote: On Jul 20 2017, Sebastian Huber wrote: Ok, so why do I get a "error: unrecognizable insn:"? How can I debug a message like this: (insn 12 11 13 2 (set (reg:CCFP 126) (compare:CCFP (reg:TF 123) (reg:TF 124))) "test-v0.i":5 -1 (nil)) This is supposed to be matched by the cmptf_internal1 pattern with -mabi=ibmlongdouble. Looks like your configuration defaults to -mabi=ieeelongdouble. Yes, originally I tried to enable the 128-bit IEEE float support. I use now the default settings. -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
-ffunction-sections and -fdata-sections documentation
Hello, I would like to update the documentation of these compiler flags and have some questions. The -ffunction-sections and -fdata-sections documentation is currently: "Place each function or data item into its own section in the output file if the target supports arbitrary sections. The name of the function or the name of the data item determines the section’s name in the output file. Use these options on systems where the linker can perform optimizations to improve locality of reference in the instruction space. Most systems using the ELF object format and SPARC processors running Solaris 2 have linkers with such optimizations. AIX may have these optimizations in the future. Only use these options when there are significant benefits from doing so. When you specify these options, the assembler and linker create larger object and executable files and are also slower. You cannot use |gprof| on all systems if you specify this option, and you may have problems with debugging if you specify both this option and -g." The end-of-life of Solaris 2.6 was 2006. Is it worth to mention this here? This "AIX may have these optimizations in the future." is there since at least 1996. What is the current AIX status? Is the "Only use these options when there are significant benefits from doing so. When you specify these options, the assembler and linker create larger object and executable files and are also slower. You cannot use |gprof| on all systems if you specify this option, and you may have problems with debugging if you specify both this option and -g." still correct on the systems of today? Do these options affect the code generation? -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
Re: -ffunction-sections and -fdata-sections documentation
- Am 13. Okt 2017 um 16:02 schrieb David Edelsohn dje@gmail.com: > On Fri, Oct 13, 2017 at 3:06 AM, Sebastian Huber > wrote: >> Hello, >> >> I would like to update the documentation of these compiler flags and have >> some questions. The -ffunction-sections and -fdata-sections documentation >> is currently: >> >> "Place each function or data item into its own section in the output file if >> the target supports arbitrary sections. The name of the function or the name >> of the data item determines the section’s name in the output file. >> >> Use these options on systems where the linker can perform optimizations to >> improve locality of reference in the instruction space. Most systems using >> the ELF object format and SPARC processors running Solaris 2 have linkers >> with such optimizations. AIX may have these optimizations in the future. >> >> Only use these options when there are significant benefits from doing so. >> When you specify these options, the assembler and linker create larger >> object and executable files and are also slower. You cannot use |gprof| on >> all systems if you specify this option, and you may have problems with >> debugging if you specify both this option and -g." >> >> The end-of-life of Solaris 2.6 was 2006. Is it worth to mention this here? >> >> This "AIX may have these optimizations in the future." is there since at >> least 1996. What is the current AIX status? >> >> Is the "Only use these options when there are significant benefits from >> doing so. When you specify these options, the assembler and linker create >> larger object and executable files and are also slower. You cannot use >> |gprof| on all systems if you specify this option, and you may have problems >> with debugging if you specify both this option and -g." still correct on the >> systems of today? >> >> Do these options affect the code generation? > > Out of date documentation in GCC? What a surprise! > > -ffunction-sections and -fdata-sections are available on AIX. The AIX > linker rearranges sections (CSECTs) based on the call graph. The > performance impact varies. > > I'm not certain what the central question of the email message is. The central question for me is the effect on code generation.
Re: -ffunction-sections and -fdata-sections documentation
- Am 13. Okt 2017 um 16:11 schrieb Jeff Law l...@redhat.com: > On 10/13/2017 01:06 AM, Sebastian Huber wrote: >> Hello, >> >> I would like to update the documentation of these compiler flags and >> have some questions. The -ffunction-sections and -fdata-sections >> documentation is currently: >> >> "Place each function or data item into its own section in the output >> file if the target supports arbitrary sections. The name of the function >> or the name of the data item determines the section’s name in the output >> file. >> >> Use these options on systems where the linker can perform optimizations >> to improve locality of reference in the instruction space. Most systems >> using the ELF object format and SPARC processors running Solaris 2 have >> linkers with such optimizations. AIX may have these optimizations in the >> future. >> >> Only use these options when there are significant benefits from doing >> so. When you specify these options, the assembler and linker create >> larger object and executable files and are also slower. You cannot use >> |gprof| on all systems if you specify this option, and you may have >> problems with debugging if you specify both this option and -g." >> >> The end-of-life of Solaris 2.6 was 2006. Is it worth to mention this here? >> >> This "AIX may have these optimizations in the future." is there since at >> least 1996. What is the current AIX status? >> >> Is the "Only use these options when there are significant benefits from >> doing so. When you specify these options, the assembler and linker >> create larger object and executable files and are also slower. You >> cannot use |gprof| on all systems if you specify this option, and you >> may have problems with debugging if you specify both this option and >> -g." still correct on the systems of today? >> >> Do these options affect the code generation? > They can affect code generation. By placing each object into its own > section it's no longer viable to use one object to refer to another > because the relative addresses are unknown until link time. Without > those options the assembler can compute the offset between two objects > within a given section when they come from the same translation unit. Is this similar to moving all distinct objects into one compiler generated structure? > > While such tricks aren't valid C code, the compiler and assembler can > work together under the hood to perform these kinds of optimizations. > > The documentation is clearly dated. A patch to update it would be > greatly appreciated :-) I will try to update it.
Re: -ffunction-sections and -fdata-sections documentation
- Am 13. Okt 2017 um 20:39 schrieb David Edelsohn dje@gmail.com: > On Fri, Oct 13, 2017 at 2:34 PM, Sebastian Huber > wrote: > >>>> Do these options affect the code generation? >>> They can affect code generation. By placing each object into its own >>> section it's no longer viable to use one object to refer to another >>> because the relative addresses are unknown until link time. Without >>> those options the assembler can compute the offset between two objects >>> within a given section when they come from the same translation unit. >> >> Is this similar to moving all distinct objects into one compiler generated >> structure? > > It places each function and each datum into a separate section, which > can be placed or removed independently. It is not combining data or > altering the order of structures. It allows the linker to position > functions and data items as individual components instead of a single > object file "text" or "data" blobs. Is the optimization opportunity described by Jeff (which is prevented by the use of function and data sections) similar to moving all distinct objects into one compiler generated structure?
Re: -ffunction-sections and -fdata-sections documentation
On 16/10/17 12:31, David Brown wrote:
On 13/10/17 09:06, Sebastian Huber wrote:
Hello,
I would like to update the documentation of these compiler flags and
have some questions. The -ffunction-sections and -fdata-sections
documentation is currently:
Do these options affect the code generation?
-fdata-sections certainly can affect code generation on some targets.
Testing with this sample, using gcc 6.3 for the ARM with -O2:
int a, b, c;
void foo(void) {
a = 1;
b = 1;
c = 1;
}
Generated assembly code is:
foo():
mov r2, #1
ldr r3, .L2
str r2, [r3]
str r2, [r3, #4]
str r2, [r3, #8]
bx lr
.L2:
.word .LANCHOR0
With -fdata-section, you get:
foo():
mov r3, #1
ldr r0, .L2
ldr r1, .L2+4
ldr r2, .L2+8
str r3, [r0]
str r3, [r1]
str r3, [r2]
bx lr
.L2:
.word .LANCHOR0
.word .LANCHOR1
.word .LANCHOR2
I only realised this recently, but it can make a significant difference
on targets that don't use direct addressing modes (such as ARM). It is
maybe worth mentioning this in any changes to the gcc documentation.
I already sent a documentation patch:
https://gcc.gnu.org/ml/gcc-patches/2017-10/msg00959.html
--
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
Re: atomic_thread_fence() semantics
On 19/10/17 14:18, Andrew Haley wrote: On 19/10/17 13:10, Jonathan Wakely wrote: There are no atomic operations on atomic objects here, so the fence doesn't synchronize with anything. Really? This seems rather unhelpful, to say the least. An atomic release operation X in thread A synchronizes-with an acquire fence F in thread B, if there exists an atomic read Y (with any memory order) Y reads the value written by X (or by the release sequence headed by X) Y is sequenced-before F in thread B In this case, all non-atomic and relaxed atomic stores that happen-before X in thread A will be synchronized-with all non-atomic and relaxed atomic loads from the same locations made in thread B after F. Where is the acquire fence or a load in the example? -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
PowerPC64 + Ada + RTEMS: Infinite loop in process_bb_lives()
Hello, I added support for the 64-bit PowerPC some months ago using a variant of the ELFv2 ABI. I don't know which kind of long double support I use on this target. This is difficult for me to understand how this works on 64-bit PowerPC. This was no problem up to now since nobody used long double with RTEMS on this target. I tried to build a GCC with Ada support today for the powerpc-rtems5 target. It ends up in infinite loops while building the Ada run-time multilib for a 64-bit PowerPC variant (similar a-coteio.ads): gdb --args /build/git-build/b-gcc-git-powerpc-rtems5/./gcc/gnat1 -gnatwa -quiet -nostdinc -nostdinc -dumpbase a-scteio.ads -auxbase-strip a-scteio.o -O2 -Wextra -Wall -g -mcpu=e6500 -msoft-float -gnatpg -mcpu=e6500 -m64 -msoft-float -mno-altivec -gnatO a-scteio.o a-scteio.ads ... (gdb) bt #0 process_bb_lives (bb=0x7700a680, curr_point=@0x7fffd38c: 387, dead_insn_p=dead_insn_p@entry=false) at /scratch/svn-gcc/gcc/lra-lives.c:838 #1 0x00b32b3a in lra_create_live_ranges_1 (all_p=all_p@entry=true, dead_insn_p=dead_insn_p@entry=false) at /scratch/svn-gcc/gcc/lra-lives.c:1305 #2 0x00b33620 in lra_create_live_ranges (all_p=all_p@entry=true, dead_insn_p=dead_insn_p@entry=false) at /scratch/svn-gcc/gcc/lra-lives.c:1369 #3 0x00b159c2 in lra (f=) at /scratch/svn-gcc/gcc/lra.c:2438 #4 0x00ac95d2 in do_reload () at /scratch/svn-gcc/gcc/ira.c:5443 #5 (anonymous namespace)::pass_reload::execute (this=) at /scratch/svn-gcc/gcc/ira.c:5627 #6 0x00bc1d49 in execute_one_pass (pass=pass@entry=0x24cc430) at /scratch/svn-gcc/gcc/passes.c:2497 #7 0x00bc25f1 in execute_pass_list_1 (pass=0x24cc430) at /scratch/svn-gcc/gcc/passes.c:2586 #8 0x00bc2603 in execute_pass_list_1 (pass=0x24cb350) at /scratch/svn-gcc/gcc/passes.c:2587 #9 0x00bc2645 in execute_pass_list (fn=, pass=) at /scratch/svn-gcc/gcc/passes.c:2597 #10 0x00883683 in cgraph_node::expand (this=0x76fd6000) at /scratch/svn-gcc/gcc/cgraphunit.c:2139 #11 0x00884bd1 in expand_all_functions () at /scratch/svn-gcc/gcc/cgraphunit.c:2275 #12 symbol_table::compile (this=this@entry=0x76e48000) at /scratch/svn-gcc/gcc/cgraphunit.c:2623 #13 0x00887477 in symbol_table::compile (this=0x76e48000) at /scratch/svn-gcc/gcc/cgraphunit.c:2719 #14 symbol_table::finalize_compilation_unit (this=0x76e48000) at /scratch/svn-gcc/gcc/cgraphunit.c:2716 #15 0x00c938dd in compile_file () at /scratch/svn-gcc/gcc/toplev.c:480 #16 0x0044485d in do_compile () at /scratch/svn-gcc/gcc/toplev.c:2059 #17 toplev::main (this=this@entry=0x7fffd72e, argc=, argc@entry=23, argv=, argv@entry=0x7fffd828) at /scratch/svn-gcc/gcc/toplev.c:2194 #18 0x00446bdb in main (argc=23, argv=0x7fffd828) at /scratch/svn-gcc/gcc/main.c:39 (gdb) -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
Re: PowerPC64 + Ada + RTEMS: Infinite loop in process_bb_lives()
On 05/12/17 15:17, Segher Boessenkool wrote: Hi! On Mon, Dec 04, 2017 at 03:34:09PM +0100, Sebastian Huber wrote: I added support for the 64-bit PowerPC some months ago using a variant of the ELFv2 ABI. I don't know which kind of long double support I use on this target. This is difficult for me to understand how this works on 64-bit PowerPC. This was no problem up to now since nobody used long double with RTEMS on this target. I tried to build a GCC with Ada support today for the powerpc-rtems5 target. It ends up in infinite loops while building the Ada run-time multilib for a 64-bit PowerPC variant (similar a-coteio.ads): Is this against trunk? Please open a bug, with enough info so we can reproduce the problem. Ideally a simple reduced testcase, but we'll take whatever you have, as long as it allows to reproduce the problem ;-) Thanks for your offer to look at this problem. I opened a bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83387 -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
Build Ada compiler for nios2?
Hello, I tried to build an Ada compiler for nios2-rtems5 and ended up with this: /run/user/10351/b-gcc-nios2/./gcc/xgcc -B/run/user/10351/b-gcc-nios2/./gcc/ -nostdinc -B/run/user/10351/b-gcc-nios2/nios2-rtems5/newlib/ -isystem /run/user/10351/b-gcc-nios2/nios2-rtems5/newlib/targ-include -isystem /home/sh/src/gcc/newlib/libc/include -B/home/sh/install/nios2-rtems5/bin/ -B/home/sh/install/nios2-rtems5/lib/ -isystem /home/sh/install/nios2-rtems5/include -isystem /home/sh/install/nios2-rtems5/sys-include -c -DCROSS_DIRECTORY_STRUCTURE -DIN_GCC -W -Wall -g -O2 -g -O2 -fexceptions -DIN_RTS -DHAVE_GETIPINFO \ -iquote /home/sh/src/gcc/gcc \ -iquote . -iquote .. -iquote ../.. -iquote /home/sh/src/gcc/gcc/ada -iquote /home/sh/src/gcc/gcc -I/home/sh/src/gcc/include \ targext.c -o targext.o In file included from ../../tm.h:19, from targext.c:46: /home/sh/src/gcc/gcc/config/nios2/nios2.h:436:31: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'nios2_section_threshold' extern unsigned HOST_WIDE_INT nios2_section_threshold; This HOST_WIDE_INT is defined in gcc/hwint.h. Who is supposed to include this file? Is this done via an #include or via a tm_file (gcc/config.gcc)? -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
Re: Build Ada compiler for nios2?
On 04/01/18 16:03, Andreas Schwab wrote: On Jan 04 2018, Sebastian Huber wrote: /home/sh/src/gcc/gcc/config/nios2/nios2.h:436:31: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'nios2_section_threshold' extern unsigned HOST_WIDE_INT nios2_section_threshold; Change the preprocessor conditional to check USED_FOR_TARGET instead of IN_LIBGCC2. Thanks, this worked: nios2-rtems5-gnat --version GNAT 8.0.0 20180105 (experimental) [master revision 9b012eb:c9100e4:1c579c0e17cba22beb7bd87244d1148784c52dab] Copyright (C) 1996-2018, 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. -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
Status of m32c target?
Hello, what is the status of the m32c target? There are some open bugs that prevent the C/C++ compiler build: https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=SUSPENDED&bug_status=WAITING&bug_status=REOPENED&cf_known_to_fail_type=allwords&cf_known_to_work_type=allwords&list_id=197687&product=gcc&query_format=advanced&short_desc=m32c&short_desc_type=allwordssubstr -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
Re: Status of m32c target?
On 13/01/18 00:16, Jeff Law wrote: On 01/12/2018 04:07 PM, Joseph Myers wrote: On Fri, 12 Jan 2018, Jeff Law wrote: I was going to suggest deprecation for gcc-8 given how badly it was broken in gcc-7 and the lack of maintenance on the target. While we're considering deprecations, what happened to the idea of setting a timescale by which cc0 targets need to be converted away from cc0 or be removed? I don't think we ever really hashed through what that might look like. I'd be comfortable saying gcc-8 is the deprecation point. I know some folks won't like that (someone already said so WRT the m68k, but didn't step up to do the conversion), but I think that unless we set a point nothing is likely to happen. How much work is it to convert the m68k to LRA. Is this person days, weeks, months or years? -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
RISC-V ELF multilibs
Hello, I built a riscv64-rtems5 GCC (it uses gcc/config/riscv/t-elf-multilib). The following multilibs are built: riscv64-rtems5-gcc -print-multi-lib .; rv32i/ilp32;@march=rv32i@mabi=ilp32 rv32im/ilp32;@march=rv32im@mabi=ilp32 rv32iac/ilp32;@march=rv32iac@mabi=ilp32 rv32imac/ilp32;@march=rv32imac@mabi=ilp32 rv32imafc/ilp32f;@march=rv32imafc@mabi=ilp32f rv64imac/lp64;@march=rv64imac@mabi=lp64 rv64imafdc/lp64d;@march=rv64imafdc@mabi=lp64d If I print out the builtin defines and search paths for the default settings and the -march=rv64imafdc and compare the results I get: riscv64-rtems5-gcc -E -P -v -dD empty.c > def.txt 2>&1 riscv64-rtems5-gcc -E -P -v -dD empty.c -march=rv64imafdc > rv64imafdc.txt 2>&1 diff -u def.txt rv64imafdc.txt --- def.txt 2018-05-26 14:53:26.277760090 +0200 +++ rv64imafdc.txt 2018-05-26 14:53:47.705638409 +0200 @@ -4,8 +4,8 @@ Configured with: ../gcc-7.3.0/configure --prefix=/opt/rtems/5 --bindir=/opt/rtems/5/bin --exec_prefix=/opt/rtems/5 --includedir=/opt/rtems/5/include --libdir=/opt/rtems/5/lib --libexecdir=/opt/rtems/5/libexec --mandir=/opt/rtems/5/share/man --infodir=/opt/rtems/5/share/info --datadir=/opt/rtems/5/share --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=riscv64-rtems5 --disable-libstdcxx-pch --with-gnu-as --with-gnu-ld --verbose --with-newlib --disable-nls --without-included-gettext --disable-win32-registry --enable-version-specific-runtime-libs --disable-lto --enable-newlib-io-c99-formats --enable-newlib-iconv --enable-newlib-iconv-encodings=big5,cp775,cp850,cp852,cp855,cp866,euc_jp,euc_kr,euc_tw,iso_8859_1,iso_8859_10,iso_8859_11,iso_8859_13,iso_8859_14,iso_8859_15,iso_8859_2,iso_8859_3,iso_8859_4,iso_8859_5,iso_8859_6,iso_8859_7,iso_8859_8,iso_8859_9,iso_ir_111,koi8_r,koi8_ru,koi8_u,koi8_uni,ucs_2,ucs_2_internal,ucs_2be,ucs_2le,ucs_4,ucs_4_internal,ucs_4be,ucs_4le,us_ascii,utf_16,utf_16be,utf_16le,utf_8,win_1250,win_1251,win_1252,win_1253,win_1254,win_1255,win_1256,win_1257,win_1258 --enable-threads --disable-plugin --enable-libgomp --enable-languages=c,c++,ada Thread model: rtems gcc version 7.3.0 20180125 (RTEMS 5, RSB a3a6c34c150a357e57769a26a460c475e188438f, Newlib 3.0.0) (GCC) -COLLECT_GCC_OPTIONS='-E' '-P' '-v' '-dD' '-march=rv64gc' '-mabi=lp64d' - /opt/rtems/5/libexec/gcc/riscv64-rtems5/7.3.0/cc1 -E -quiet -v -P -imultilib rv64imafdc/lp64d empty.c -march=rv64gc -mabi=lp64d -dD +COLLECT_GCC_OPTIONS='-E' '-P' '-v' '-dD' '-march=rv64imafdc' '-mabi=lp64d' + /opt/rtems/5/libexec/gcc/riscv64-rtems5/7.3.0/cc1 -E -quiet -v -P -imultilib rv64imafdc/lp64d empty.c -march=rv64imafdc -mabi=lp64d -dD ignoring nonexistent directory "/opt/rtems/5/lib/gcc/riscv64-rtems5/7.3.0/../../../../riscv64-rtems5/sys-include" #include "..." search starts here: #include <...> search starts here: @@ -338,4 +338,4 @@ #define __ELF__ 1 COMPILER_PATH=/opt/rtems/5/libexec/gcc/riscv64-rtems5/7.3.0/:/opt/rtems/5/libexec/gcc/riscv64-rtems5/7.3.0/:/opt/rtems/5/libexec/gcc/riscv64-rtems5/:/opt/rtems/5/lib/gcc/riscv64-rtems5/7.3.0/:/opt/rtems/5/lib/gcc/riscv64-rtems5/:/opt/rtems/5/lib/gcc/riscv64-rtems5/7.3.0/../../../../riscv64-rtems5/bin/ LIBRARY_PATH=/opt/rtems/5/lib/gcc/riscv64-rtems5/7.3.0/rv64imafdc/lp64d/:/opt/rtems/5/lib/gcc/riscv64-rtems5/7.3.0/../../../../riscv64-rtems5/lib/rv64imafdc/lp64d/:/opt/rtems/5/lib/gcc/riscv64-rtems5/7.3.0/:/opt/rtems/5/lib/gcc/riscv64-rtems5/7.3.0/../../../../riscv64-rtems5/lib/:/lib/:/usr/lib/ -COLLECT_GCC_OPTIONS='-E' '-P' '-v' '-dD' '-march=rv64gc' '-mabi=lp64d' +COLLECT_GCC_OPTIONS='-E' '-P' '-v' '-dD' '-march=rv64imafdc' '-mabi=lp64d' This looks pretty much the same and the documentation says that G == IMAFD. Why is the default multilib and a variant identical? Most variants include the C extension. Would it be possible to add -march=rv32g and -march=rv64g variants? -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
RISC-V problem with weak function references and -mcmodel=medany
Hello,
I try to build a 64-bit RISC-V tool chain for RTEMS. RTEMS doesn't use
virtual memory. The reference chips for 64-bit RISC-V such as FU540-C000
locate the RAM at 0x8000_. This forces me to use -mcmodel=medany in
64-bit mode. The ctrbegin.o contains this code (via crtstuff.c):
extern void *__deregister_frame_info (const void *)
__attribute__ ((weak));
...
# 370 "libgcc/crtstuff.c"
static void __attribute__((used))
__do_global_dtors_aux (void)
{
static _Bool completed;
if (__builtin_expect (completed, 0))
return;
# 413 "libgcc/crtstuff.c"
deregister_tm_clones ();
# 423 "libgcc/crtstuff.c"
if (__deregister_frame_info)
__deregister_frame_info (__EH_FRAME_BEGIN__);
completed = 1;
}
Which is:
.text
.align 1
.type __do_global_dtors_aux, @function
__do_global_dtors_aux:
lbu a5,completed.3298
bnez a5,.L22
addi sp,sp,-16
sd ra,8(sp)
call deregister_tm_clones
lla a5,__deregister_frame_info
beqz a5,.L17
lla a0,__EH_FRAME_BEGIN__
call __deregister_frame_info
.L17:
ld ra,8(sp)
li a5,1
sb a5,completed.3298,a4
addi sp,sp,16
jr ra
.L22:
ret
If I link an executable I get this:
/opt/rtems/5/lib64/gcc/riscv64-rtems5/9.0.0/../../../../riscv64-rtems5/bin/ld:
/opt/rtems/5/lib64/gcc/riscv64-rtems5/9.0.0/crtbegin.o: in function `.L0 ':
crtstuff.c:(.text+0x72): relocation truncated to fit: R_RISCV_CALL
against undefined symbol `__deregister_frame_info'
I guess, that the resolution of the weak reference to the undefined
symbol __deregister_frame_info somehow sets __deregister_frame_info to
the absolute address 0 which is illegal in the following "call
__deregister_frame_info"? Is this construct with weak references and a
-mcmodel=medany supported on RISC-V at all?
If I change crtstuff.c like this using weak function definitions
diff --git a/libgcc/crtstuff.c b/libgcc/crtstuff.c
index 5e894455e16..770e3420c92 100644
--- a/libgcc/crtstuff.c
+++ b/libgcc/crtstuff.c
@@ -177,13 +177,24 @@ call_ ## FUNC
(void) \
/* References to __register_frame_info and __deregister_frame_info should
be weak in this file if at all possible. */
-extern void __register_frame_info (const void *, struct object *)
- TARGET_ATTRIBUTE_WEAK;
+extern void __register_frame_info (const void *, struct object *) ;
+TARGET_ATTRIBUTE_WEAK void __register_frame_info (const void *unused,
struct object *unused2)
+{
+ (void)unused;
+ (void)unused2;
+}
+
extern void __register_frame_info_bases (const void *, struct object *,
void *, void *)
TARGET_ATTRIBUTE_WEAK;
-extern void *__deregister_frame_info (const void *)
- TARGET_ATTRIBUTE_WEAK;
+
+extern void *__deregister_frame_info (const void *);
+TARGET_ATTRIBUTE_WEAK void *__deregister_frame_info (const void *unused)
+{
+ (void)unused;
+ return 0;
+}
+
extern void *__deregister_frame_info_bases (const void *)
TARGET_ATTRIBUTE_WEAK;
extern void __do_global_ctors_1 (void);
then the example program links.
--
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
Re: RISC-V problem with weak function references and -mcmodel=medany
Changing the code to something like this
void f(void) __attribute__((__weak__));
void _start(void)
{
void (*g)(void) = f;
if (g != 0) {
(*g)();
}
}
doesn't work either, since this is optimized to
.option nopic
.text
.align 1
.globl _start
.type _start, @function
_start:
lla a5,f
beqz a5,.L1
tail f
.L1:
ret
.size _start, .-_start
.weak f
Why doesn't the RISC-V generate a trampoline code to call far functions?
The non-optimized example code with "tail f" replaced by "jalr a5" links
well:
.option nopic
.text
.align 1
.globl _start
.type _start, @function
_start:
addi sp,sp,-32
sd ra,24(sp)
sd s0,16(sp)
addi s0,sp,32
lla a5,f
sd a5,-24(s0)
ld a5,-24(s0)
beqz a5,.L3
ld a5,-24(s0)
jalr a5
.L3:
nop
ld ra,24(sp)
ld s0,16(sp)
addi sp,sp,32
jr ra
.size _start, .-_start
.weak f
--
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
