On 26.04.22 15:53, Martin Liška wrote:
This if fine, except 2 places where you have trailing whitespace
at the end of a line.
Thanks for the review.
Should I use "-ftest-coverage -fprofile-arcs" or "--coverage" in the
tutorial?
--
embedded brains GmbH
Herr Sebastian
Commit 621cccba3f8b0cd2757feda171e66e3820b55c2c broke the Ada build for all
RTEMS targets except aarch64.
gcc/ada/
* tracebak.c: Add support for ARM RTEMS. Add support for RTEMS to PPC
ELF. Add support for RTEMS to SPARC. Merge aarch64 support of Linux
and RTEMS.
---
gc
This patch fixes an issue introduced by commit
ef9a53feae5701953da9161afef2aea0329ec8b2:
gcc --coverage main.c && ./a.out
libgcov profiling error:a-main.gcda:Error writing
gcc/ChangeLog:
* gcov-io.cc (gcov_rewrite): Clear the file error status.
---
gcc/gcov-io.cc | 5 -
1 file chan
Register the profile information in the specified section instead of using a
constructor/destructor. A pointer to the profile information generated by
-fprofile-arcs or -ftest-coverage is placed in the specified section for each
translation unit. This option disables the profile information regis
dump_all();
return 0;
}
In the linker command file you need these directives in a read-only
memory area:
PROVIDE (__gcov_info_start = .);
KEEP (*(.gcov_info))
PROVIDE (__gcov_info_end = .);
--
embedded brains GmbH
Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@e
On 16/11/2020 12:02, Sebastian Huber wrote:
I sent a proposal for a simple function to convert a gcov info to a
gcda byte stream:
https://lists.rtems.org/mailman/listinfo
Sorry, wrong URL. This is the right one:
https://gcc.gnu.org/pipermail/gcc/2020-November/234213.html
--
embedded
On 30/08/2021 14:01, Sebastian Huber wrote:
Do not declare abort in "libgcc/unwind-arm-common.inc" since it is already
provided by "tsystem.h". It fixes the following build error:
In file included from libgcc/config/arm/unwind-arm.c:144:
libgcc/unwind-arm-common.inc:55:24:
Add __gcov_info_to_gcda() to libgcov to get the gcda data for a gcda info in a
free-standing environment. It is intended to be used with the
-fprofile-info-section option. A crude test program which doesn't use a linker
script is (use "gcc -coverage -fprofile-info-section -lgcc test.c" to compile
On 13/07/2021 15:03, Sebastian Huber wrote:
memset (list_sizes, 0, counters * sizeof (unsigned));
Sorry, I just realized that memset() cannot be used if inhibit_libc is
defined. I will send a v2 of the patch.
--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Add __gcov_info_to_gcda() to libgcov to get the gcda data for a gcda info in a
freestanding environment. It is intended to be used with the
-fprofile-info-section option. A crude test program which doesn't use a linker
script is (use "gcc -coverage -fprofile-info-section -lgcc test.c" to compile
If the -fprofile-info-section is used, then the gcov information is registered
in a linker set. This is done by build_gcov_info_var_registration(). The
compiler generated object placed in the section was not marked as referenced,
so once optimization was enabled, this object was optimized away.
Hallo Martin,
thanks for your review.
On 23/07/2021 07:31, Martin Liška wrote:
On 7/13/21 10:15 PM, Sebastian Huber wrote:
Hello.
Thanks for working on that, there's my review:
Add __gcov_info_to_gcda() to libgcov to get the gcda data for a gcda
info in a
freestanding environment.
?
--
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
hout a gocv_ prefix,
for example write_one_data(), write_topn_counters().
--
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ün
o.c.
Sorry, I still don't know how I can get the summary information if I
only have a pointer to the gcov_info structure which does not contain a
summary member.
--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +
/gcov-info-to-gcda.c:5:10:
fatal error: gcov.h: No such file or directory
compilation terminated.
Is it possible to do such kind of tests? I also have to link to -lgcov?
--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
On 23/07/2021 11:17, Sebastian Huber wrote:
On 23/07/2021 08:52, Martin Liška wrote:
It would be nice having a test-case that can test your approach.
The problem is that you need the linker set to get access to the gcov
information. The test program of the commit message works on my
Add __gcov_info_to_gcda() to libgcov to get the gcda data for a gcda info in a
freestanding environment. It is intended to be used with the
-fprofile-info-section option. A crude test program which doesn't use a linker
script is (use "gcc -coverage -fprofile-info-section -lgcc test.c" to compile
On 23/07/2021 09:16, Martin Liška wrote:
On 7/23/21 9:06 AM, Sebastian Huber wrote:
On 23/07/2021 08:52, Martin Liška wrote:
+#ifdef NEED_L_GCOV_INFO_TO_GCDA
+/* Convert the gcov info to a gcda data stream. It is intended for
+ free-standing environments which do not support the C library
gcc/ChangeLog:
* config.gcc (aarch64-*-rtems*): Add target makefile fragment
t-aarch64-rtems.
* config/aarch64/t-aarch64-rtems: New file.
---
gcc/config.gcc | 1 +
gcc/config/aarch64/t-aarch64-rtems | 41 ++
2 files changed,
Add a multilib with workarounds for Cortex-A53 errata.
gcc/ChangeLog:
* config.gcc (aarch64-*-rtems*): Add target makefile fragment
t-aarch64-rtems.
* config/aarch64/t-aarch64-rtems: New file.
---
gcc/config.gcc | 1 +
gcc/config/aarch64/t-aarch64-rte
Add a multilib with workarounds for Cortex-A53 errata.
gcc/ChangeLog:
* config.gcc (aarch64-*-rtems*): Add target makefile fragment
t-aarch64-rtems.
* config/aarch64/t-aarch64-rtems: New file.
---
gcc/config.gcc | 1 +
gcc/config/aarch64/t-aarch64-rte
to the GCC 14 release notes.
--
embedded brains GmbH & Co. KG
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax: +49-89-18 94 741 - 08
Registergericht: Amtsgericht München
Registernummer: HRB 15
On 09.04.24 14:10, Sam James wrote:
Sebastian Huber writes:
On 20.11.23 10:56, Florian Weimer wrote:
In the future, it may make sense to avoid cascading errors from
the implicit declaration, especially its assumed int return type.
This change here only changes the kind of the diagnostic, not
mpiler (32-bit and 64-bit). It seems you
removed the -m32 handling, so I am not sure how to approach this issue.
I added a test case to the PR:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106680
--
embedded brains GmbH & Co. KG
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
ema
On 11.09.23 14:57, Sebastian Huber wrote:
On 04.07.23 08:20, Sebastian Huber wrote:
On 22.05.23 14:51, Sebastian Huber wrote:
Make sure that the API enums have at least the size of int.
Otherwise the
following build error may occur:
In file included from gcc/libgomp/env.c:34:
./libgomp_f.h
In libgcov we use defined (__LIBGCC_HAVE_LIBATOMIC), so we must define it only
if needed (vs. #if __LIBGCC_HAVE_LIBATOMIC).
gcc/c-family/ChangeLog:
PR target/112777
* c-cppbuiltin.cc (c_cpp_builtins): Define __LIBGCC_HAVE_LIBATOMIC
only if targetm.have_libatomic is true.
libgcc/ChangeLog:
PR target/112777
* libgcov.h (GCOV_SUPPORTS_ATOMIC): Honor that __LIBGCC_HAVE_LIBATOMIC
is
always defined as either 0 or 1.
---
libgcc/libgcov.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libgcc/libgcov.h b/libgcc/libgcov.h
ind
On 13/12/2022 15:30, Richard Biener wrote:
On Fri, Dec 9, 2022 at 2:56 PM Sebastian Huber
wrote:
The code coverage support uses counters to determine which edges in the control
flow graph were executed. If a counter overflows, then the code coverage
information is invalid. Therefore the
The code coverage support uses counters to determine which edges in the control
flow graph were executed. If a counter overflows, then the code coverage
information is invalid. Therefore the counter type should be a 64-bit integer.
In multithreaded applications, it is important that the counter i
:
__gcov_inc_counter(counter) -> updated value
This function could use a __gthread_mutex_t mutex for updates. This ends
up probably with quite a bad performance.
--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone:
On 16.12.22 13:09, Richard Biener wrote:
On Fri, Dec 16, 2022 at 11:39 AM Sebastian Huber
wrote:
On 16.12.22 10:47, Richard Biener wrote:
No, if you select -fprofile-update=atomic, then the updates shall be
atomic from my point of view. If a fallback is acceptable, then you can
use
Build libatomic for all targets. Use gthr.h to provide a default
implementation. If the thread model is "single", then this implementation will
not work if for example atomic operations are used for thread/interrupt
synchronization.
libatomic/ChangeLog:
* Makefile.am (BUILT_SOURCES): Ne
On 19/12/2022 17:02, Sebastian Huber wrote:
Build libatomic for all targets. Use gthr.h to provide a default
implementation. If the thread model is "single", then this implementation will
not work if for example atomic operations are used for thread/interrupt
synchronization.
Is th
On 04.07.23 08:20, Sebastian Huber wrote:
On 22.05.23 14:51, Sebastian Huber wrote:
Make sure that the API enums have at least the size of int. Otherwise
the
following build error may occur:
In file included from gcc/libgomp/env.c:34:
./libgomp_f.h: In function 'omp_check_de
On 31.05.23 09:27, Richard Biener wrote:
On Wed, May 31, 2023 at 7:31 AM Sebastian Huber
wrote:
On 30.05.23 13:17, Richard Biener wrote:
The alternative would be to provide the required subset of atomic
library functions from libgcov.a and emit calls to that directly?
The locked data isn&#
Sebastian Huber (4):
gcov: Remove TARGET_GCOV_TYPE_SIZE target hook
Add TARGET_HAVE_LIBATOMIC
gcov: Add gen_counter_update()
gcov: Improve -fprofile-update=atomic
gcc/c-family/c-cppbuiltin.cc | 4 +-
gcc/config/rtems.h | 2 +
gcc/config/sparc/rtemself.h | 2 -
gcc/config
Add target data to indicate if libatomic is available.
gcc/ChangeLog:
* config/rtems.h (TARGET_HAVE_LIBATOMIC): Define.
* doc/tm.texi: Regenerate.
* doc/tm.texi.in (TARGET_HAVE_LIBATOMIC): Add.
* target.def (have_libatomic): New.
---
gcc/config/rtems.h | 2 ++
gcc
Move the counter update to the new gen_counter_update() helper function. Use
it in gimple_gen_edge_profiler() and gimple_gen_time_profiler(). The resulting
gimple instructions should be identical with the exception of the removed
unshare_expr() call. The unshare_expr() call was used in
gimple_ge
This reverts commit 8cdcea51c0fd753e6a652c9b236e91b3a6e0911c.
gcc/c-family/ChangeLog:
* c-cppbuiltin.cc (c_cpp_builtins): Do not define
__LIBGCC_GCOV_TYPE_SIZE.
gcc/ChangeLog:
* config/sparc/rtemself.h (SPARC_GCOV_TYPE_SIZE): Remove.
* config/sparc/sparc.cc (spar
The code coverage support uses counters to determine which edges in the control
flow graph were executed. If a counter overflows, then the code coverage
information is invalid. Therefore the counter type should be a 64-bit integer.
In multi-threaded applications, it is important that the counter
Hello,
sorry, in the patch I should use targetm.have_atomic instead of
TARGET_HAVE_LIBATOMIC.
---
embedded brains GmbH & Co. KG
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax: +49-89-18 94 741
Hello Dimitar,
On 19.11.23 10:00, Dimitar Dimitrov wrote:
On Tue, Nov 14, 2023 at 11:08:24PM +0100, Sebastian Huber wrote:
Move the counter update to the new gen_counter_update() helper function. Use
it in gimple_gen_edge_profiler() and gimple_gen_time_profiler(). The resulting
gimple
This change fixes issues like this:
gcc.dg/gomp/pr27573.c: In function ‘main._omp_fn.0’:
gcc.dg/gomp/pr27573.c:19:1: error: non-trivial conversion in ‘ssa_name’
19 | }
| ^
long int
long unsigned int
# .MEM_19 = VDEF <.MEM_18>
__gcov7.main._omp_fn.0[0] = PROF_time_profile_1
This fixes issues like this:
gcc/testsuite/gcc.dg/no_profile_instrument_function-attr-1.c: In function
'main':
gcc/testsuite/gcc.dg/no_profile_instrument_function-attr-1.c:19:1: error:
incorrect sharing of tree nodes
__gcov0.main[0]
# .MEM_12 = VDEF <.MEM_9>
__gcov0.main[0] = PROF_edge
On 20.11.23 15:56, Jakub Jelinek wrote:
On Mon, Nov 20, 2023 at 03:33:31PM +0100, Sebastian Huber wrote:
This change fixes issues like this:
gcc.dg/gomp/pr27573.c: In function ‘main._omp_fn.0’:
gcc.dg/gomp/pr27573.c:19:1: error: non-trivial conversion in ‘ssa_name’
19
This change fixes issues like this:
gcc.dg/gomp/pr27573.c: In function ‘main._omp_fn.0’:
gcc.dg/gomp/pr27573.c:19:1: error: non-trivial conversion in ‘ssa_name’
19 | }
| ^
long int
long unsigned int
# .MEM_19 = VDEF <.MEM_18>
__gcov7.main._omp_fn.0[0] = PROF_time_profile_1
make_ssa_name() would be the first use in this file.
--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax: +49-89-18 94 741 - 08
Registergericht: Amtsgericht München
Registernummer: HRB 157899
On 21.11.23 11:46, Jakub Jelinek wrote:
On Tue, Nov 21, 2023 at 11:42:06AM +0100, Sebastian Huber wrote:
On 21.11.23 11:34, Jakub Jelinek wrote:
--- a/gcc/tree-profile.cc
+++ b/gcc/tree-profile.cc
@@ -281,10 +281,13 @@ gen_assign_counter_update (gimple_stmt_iterator *gsi,
gcall *call, tree
On 22.11.23 15:22, Christophe Lyon wrote:
On Tue, 21 Nov 2023 at 12:22, Sebastian Huber
wrote:
On 21.11.23 11:46, Jakub Jelinek wrote:
On Tue, Nov 21, 2023 at 11:42:06AM +0100, Sebastian Huber wrote:
On 21.11.23 11:34, Jakub Jelinek wrote:
--- a/gcc/tree-profile.cc
+++ b/gcc/tree
On 23.11.23 09:11, Jiang, Haochen wrote:
-Original Message-
From: Sebastian Huber
Sent: Wednesday, November 22, 2023 10:24 PM
To: Christophe Lyon
Cc: Jakub Jelinek;gcc-patches@gcc.gnu.org
Subject: Re: [PATCH v2] gcov: Fix integer types in gen_counter_update()
On 22.11.23 15:22
gcc/ChangeLog:
PR tree-optimization/112678
* tree-profile.cc (tree_profiling): Do not use atomic operations
for -fprofile-update=single.
---
gcc/tree-profile.cc | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/gcc/tree-profile.cc b/gcc/tree-prof
On 23.11.23 15:19, Richard Biener wrote:
On Thu, Nov 23, 2023 at 2:47 PM Sebastian Huber
wrote:
gcc/ChangeLog:
PR tree-optimization/112678
* tree-profile.cc (tree_profiling): Do not use atomic operations
for -fprofile-update=single.
---
gcc/tree-profile.cc | 8
On 23.11.23 09:20, Sebastian Huber wrote:
On 23.11.23 09:11, Jiang, Haochen wrote:
-Original Message-
From: Sebastian Huber
Sent: Wednesday, November 22, 2023 10:24 PM
To: Christophe Lyon
Cc: Jakub Jelinek;gcc-patches@gcc.gnu.org
Subject: Re: [PATCH v2] gcov: Fix integer types in
On 23.11.23 18:29, Sebastian Huber wrote:
On 23.11.23 09:20, Sebastian Huber wrote:
On 23.11.23 09:11, Jiang, Haochen wrote:
-Original Message-
From: Sebastian Huber
Sent: Wednesday, November 22, 2023 10:24 PM
To: Christophe Lyon
Cc: Jakub Jelinek;gcc-patches@gcc.gnu.org
Subject: Re
contrib/ChangeLog
* download_prerequisites: Update to gmp-6.3.0, mpfr-4.2.1,
mpc-1.3.1, isl-0.26, and gettext-0.22.4.
* prerequisites.md5: Update hash.
* prerequisites.sha512: Likewise.
---
contrib/download_prerequisites | 10 +-
contrib/prerequisites.md5
On 25.11.23 14:59, Richard Biener wrote:
On Sat, Nov 25, 2023 at 12:26 PM Sebastian Huber
wrote:
contrib/ChangeLog
Did you verify an in-tree build with these works and the testsuite
is clean?
I was able to build a native GCC:
/tmp/sh/i-native/bin/gcc --version --verbose
Using built-in
On 26.11.23 01:35, Iain Sandoe wrote:
On 25 Nov 2023, at 21:44, Sebastian Huber
wrote:
On 25.11.23 14:59, Richard Biener wrote:
On Sat, Nov 25, 2023 at 12:26 PM Sebastian Huber
wrote:
contrib/ChangeLog
Did you verify an in-tree build with these works and the testsuite
is clean?
I
On 26.11.23 11:15, Iain Sandoe wrote:
On 26 Nov 2023, at 10:05, Sebastian Huber
wrote:
On 26.11.23 01:35, Iain Sandoe wrote:
On 25 Nov 2023, at 21:44, Sebastian Huber
wrote:
On 25.11.23 14:59, Richard Biener wrote:
On Sat, Nov 25, 2023 at 12:26 PM Sebastian Huber
wrote:
contrib
On 26.11.23 12:18, haochen.jiang wrote:
On Linux/x86_64,
a350a74d6113e3a84943266eb691275951c109d9 is the first bad commit
commit a350a74d6113e3a84943266eb691275951c109d9
Author: Sebastian Huber
Date: Sat Oct 21 15:52:15 2023 +0200
gcov: Add gen_counter_update()
caused
FAIL: gcc.dg
On 26.11.23 12:18, haochen.jiang wrote:
On Linux/x86_64,
20a3c74c347429c109bc7002285b735be83f6a0b is the first bad commit
commit 20a3c74c347429c109bc7002285b735be83f6a0b
Author: Sebastian Huber
Date: Tue Nov 14 21:36:51 2023 +0100
gcov: Improve -fprofile-update=atomic
caused
FAIL
On 26.11.23 12:18, haochen.jiang wrote:
On Linux/x86_64,
41aacdea55c5d795a7aa195357d966645845d00e is the first bad commit
commit 41aacdea55c5d795a7aa195357d966645845d00e
Author: Sebastian Huber
Date: Mon Nov 20 15:26:38 2023 +0100
gcov: Fix integer types in gen_counter_update()
caused
---
htdocs/gcc-14/changes.html | 11 +++
1 file changed, 11 insertions(+)
diff --git a/htdocs/gcc-14/changes.html b/htdocs/gcc-14/changes.html
index 8ac08e9a..a183fad8 100644
--- a/htdocs/gcc-14/changes.html
+++ b/htdocs/gcc-14/changes.html
@@ -231,6 +231,17 @@ a work-in-progress.
prev
---
v2: Remove listing of options.
htdocs/gcc-14/changes.html | 2 ++
1 file changed, 2 insertions(+)
diff --git a/htdocs/gcc-14/changes.html b/htdocs/gcc-14/changes.html
index 8ac08e9a..665d050a 100644
--- a/htdocs/gcc-14/changes.html
+++ b/htdocs/gcc-14/changes.html
@@ -231,6 +231,8 @@ a work-
- Am 15. Apr 2024 um 8:05 schrieb Sebastian Huber
sebastian.hu...@embedded-brains.de:
> ---
> v2: Remove listing of options.
>
> htdocs/gcc-14/changes.html | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/htdocs/gcc-14/changes.html b/htdocs/gcc-14/changes.
On 24.04.24 14:28, Sebastian Huber wrote:
- Am 15. Apr 2024 um 8:05 schrieb Sebastian Huber
sebastian.hu...@embedded-brains.de:
---
v2: Remove listing of options.
htdocs/gcc-14/changes.html | 2 ++
1 file changed, 2 insertions(+)
diff --git a/htdocs/gcc-14/changes.html b/htdocs/gcc-14
the C section.
How about this? OK for wwwdocs?
This is fine for me as well, thanks.
--
embedded brains GmbH & Co. KG
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax: +49-89-18 94 741 - 08
Registerger
t the end,
however the support for static initialization is quite important from my
point of view especially for applications for embedded systems. Here,
dynamic allocations may not be allowed or feasible.
--
embedded brains GmbH & Co. KG
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germ
On 06.05.24 09:08, Richard Biener wrote:
On Sat, 4 May 2024, Sebastian Huber wrote:
On 07.08.23 16:22, Qing Zhao via Gcc-patches wrote:
Hi,
This is the 2nd version of the patch.
Comparing to the 1st version, the only change is to address Richard's
comment on refering a warning optio
control \
name##_Objects[ _Objects_Maximum_per_allocation( max ) ]; \
static RTEMS_SECTION( ".noinit.rtems.content.objects." #name ) \
I would like no know which consequences the deprecation this GCC
extension has.
--
embedded brains GmbH & Co. KG
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
ema
the end, how would I add a
configuration defined number of elements at the end?
--
embedded brains GmbH & Co. KG
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax: +49-89-18 94 741 - 08
Registerger
Recently support for LEON3 specific instructions were added to GCC.
Make this support available for RTEMS.
This patch should be committed to GCC 4.9.
gcc/ChangeLog
2013-08-29 Sebastian Huber
* config/sparc/t-rtems: Add leon3 multilibs.
---
gcc/config/sparc/t-rtems |4 ++--
1
ror-always still
>>does not build.
>>
>>As before, Sandra and me will serve as nios2 port maintainers.
>>
>>Attached is the patch for the compiler-proper.
>>
>>Thanks,
>>Chung-Lin
--
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4,
=leon3 in RTEMS.
To my knowledge, GCC up to 4.8.1 doesn't support -mcpu=leon3 at all, but I
don't know about the status on current gcc-4_8-branch.
Ralf
I don't expect that this will be back ported to GCC 4.8. You also need
Binutils 2.24 for this.
--
Sebastian Huber, embedded brains
PARC-specific,
but perhaps the RMs are of a different opinion here.
A back port would be quite nice for us, since we work currently on SMP support
for LEON3/4 and C11 atomic operations would be very handy for this.
--
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82178 Puch
tresults/2012-09/msg02507.html
--
Sebastian Huber, embedded brains GmbH
Address : Obere Lagerstr. 30, D-82178 Puchheim, Germany
Phone : +49 89 18 90 80 79-6
Fax : +49 89 18 90 80 79-9
E-Mail : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist
On 10/09/2012 11:08 AM, Sebastian Huber wrote:
Hello,
this is an updated patch for the GCC 4.8. It renames the target
"arm-rtemseabi" to "arm-rtems" to bring the ARM tool chain back to the standard
RTEMS target pattern "$ARCH-rtems".
GCC test suite re
Updated patch.
--
Sebastian Huber, embedded brains GmbH
Address : Obere Lagerstr. 30, D-82178 Puchheim, Germany
Phone : +49 89 18 90 80 79-6
Fax : +49 89 18 90 80 79-9
E-Mail : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine
--
Sebastian Huber, embedded brains GmbH
Address : Obere Lagerstr. 30, D-82178 Puchheim, Germany
Phone : +49 89 18 90 80 79-6
Fax : +49 89 18 90 80 79-9
E-Mail : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche
On 03/09/2012 10:01 AM, Sebastian Huber wrote:
Hi,
please have a look at the attached patch. Test suite results for GCC 4.7
http://gcc.gnu.org/ml/gcc-testresults/2012-03/msg00986.html
This patch is still pending for GCC 4.7 and 4.8. Can someone please review and
commit it. Without this
Hello Alan,
thanks for looking at this issue.
On 10/24/2012 04:50 PM, Alan Modra wrote:
On Tue, Oct 23, 2012 at 06:25:43PM +0200, Sebastian Huber wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55033
This patch fixes my problem, but I am absolutely not sure if this is the
right way
Hello,
here is a test case for PR55033.
--
Sebastian Huber, embedded brains GmbH
Address : Obere Lagerstr. 30, D-82178 Puchheim, Germany
Phone : +49 89 18 90 80 79-6
Fax : +49 89 18 90 80 79-9
E-Mail : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.
Diese
On 10/26/2012 02:22 PM, Sebastian Huber wrote:
Hello,
here is a test case for PR55033.
Is there something wrong with this test case? It compiles well with Alan's
patch.
--
Sebastian Huber, embedded brains GmbH
Address : Obere Lagerstr. 30, D-82178 Puchheim, Germany
Phone : +49 89
Hello,
what needs to be done to get this committed?
--
Sebastian Huber, embedded brains GmbH
Address : Obere Lagerstr. 30, D-82178 Puchheim, Germany
Phone : +49 89 18 90 80 79-6
Fax : +49 89 18 90 80 79-9
E-Mail : sebastian.hu...@embedded-brains.de
PGP : Public key available on
want to
look at the remaining 104 test cases which are marked as UNSUPPORTED for RTEMS
some time in the future. Please have a look at the attached patches.
On 10/31/2012 01:12 AM, Alan Modra wrote:
On Tue, Oct 30, 2012 at 02:45:40PM +0100, Sebastian Huber wrote:
On 10/26/2012 02:22 PM
hich one
should I choose as a naive user? Are the versions in the
contrib/download_prerequisites script the recommended ones?
--
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 : seba
On 02/02/16 19:00, Mike Stump wrote:
On Feb 2, 2016, at 2:23 AM, Sebastian Huber
wrote:
>It would be good to have a recommended version as well (similar for cloog,
gmp, mpc and mpfr). If you present me three versions which one should I choose as
a naive user?
The latest release, or
On 03/02/16 07:29, Sebastian Huber wrote:
On 02/02/16 19:00, Mike Stump wrote:
On Feb 2, 2016, at 2:23 AM, Sebastian
Huber wrote:
>It would be good to have a recommended version as well (similar for
cloog, gmp, mpc and mpfr). If you present me three versions which
one should I choose
2014-01-06 Sebastian Huber
* config.gcc (*-*-rtems*): Add t-rtems to tmake_file.
(arm*-*-eabi* | arm*-*-symbianelf* | arm*-*-rtems*): Do not
override an existing tmake_file.
(arm*-*-rtems*): Use t-rtems from existing tmake_file.
(avr-*-rtems*): Likewise
Hello Richard,
would you mind having a look at the ARM specific part of this patch:
On 01/06/2014 07:27 PM, Sebastian Huber wrote:
2014-01-06 Sebastian Huber
* config.gcc (*-*-rtems*): Add t-rtems to tmake_file.
(arm*-*-eabi* | arm*-*-symbianelf* | arm*-*-rtems*): Do not
v2: Do not override an existing tmake_file in (arm*-*-uclinux*eabi*).
The ARM changes are already approved:
http://gcc.gnu.org/ml/gcc-patches/2014-01/msg00254.html
The rest is RTEMS specific.
gcc/ChangeLog
2014-01-07 Sebastian Huber
* config.gcc (*-*-rtems*): Add t-rtems to
Ping.
On 07/07/15 14:17, Sebastian Huber wrote:
Try to re-use the previous team to avoid the use of malloc() and free()
in the normal case where number of threads is the same. Avoid
superfluous destruction and initialization of team synchronization
objects.
Using the microbenchmark posted
On 13/07/15 09:17, Jakub Jelinek wrote:
On Mon, Jul 13, 2015 at 08:32:33AM +0200, Sebastian Huber wrote:
Ping.
Space in gomp_thread is precious, that is a TLS variable, and you want
to only handle the non-nested case only anyway, so why don't you
just try to use
if (thr->thr
-13 Sebastian Huber
* team.c (get_recycable_team): New.
(gomp_new_team): Recycle last non-nested team if possible.
(free_team): Destroy more team synchronization objects.
(gomp_team_end): Move some team synchronization object
destructions to free_team
On 13/07/15 16:17, Jakub Jelinek wrote:
On Mon, Jul 13, 2015 at 01:15:44PM +0200, Sebastian Huber wrote:
diff --git a/libgomp/team.c b/libgomp/team.c
index b98b233..0bcbaf8 100644
--- a/libgomp/team.c
+++ b/libgomp/team.c
@@ -134,6 +134,25 @@ gomp_thread_start (void *xdata)
return NULL
On 13/07/15 16:33, Sebastian Huber wrote:
On 13/07/15 16:17, Jakub Jelinek wrote:
On Mon, Jul 13, 2015 at 01:15:44PM +0200, Sebastian Huber wrote:
diff --git a/libgomp/team.c b/libgomp/team.c
index b98b233..0bcbaf8 100644
--- a/libgomp/team.c
+++ b/libgomp/team.c
@@ -134,6 +134,25
On 14/07/15 09:04, Sebastian Huber wrote:
#include
static inline struct gomp_team *
get_last_team (unsigned nthreads)
{
struct gomp_thread *thr = gomp_thread ();
if (thr->ts.team == NULL)
{
struct gomp_thread_pool *pool = thr->thread_pool;
if (pool !
On 14/07/15 09:19, Jakub Jelinek wrote:
On Tue, Jul 14, 2015 at 09:09:01AM +0200, Sebastian Huber wrote:
I pasted the wrong version, since I wanted to check that I get a failure in
case generation % BAR_INCR != 0.
There is also config/posix/bar* implementation, which would need to be
checked
On 14/07/15 12:44, Jakub Jelinek wrote:
On Tue, Jul 14, 2015 at 11:28:18AM +0200, Sebastian Huber wrote:
>If I destroy the barrier of the last team, and then initialize it later in
>gomp_new_team()
>
>+static inline struct gomp_team *
>+get_last_team (unsigned nthreads)
Thanks, I checked this in:
https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=225811
--
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
101 - 200 of 490 matches
Mail list logo
