On 30/06/2022 09:52, Alexandre Oliva via Gcc-patches wrote:
On Jun 27, 2022, Alexandre Oliva wrote:
I see two potential ways to avoid this:
Another possibility occurred to me: seeking back to the entry we're
about to remove, before removing it. Then, POSIX-compliant
implementations will ju
On 6/30/2022 01:34, Sebastian Huber wrote:
On 30/06/2022 07:58, Sebastian Huber wrote:
On 29/06/2022 17:54, Kinsey Moore wrote:
On 6/29/2022 04:34, Sebastian Huber wrote:
On 29/06/2022 11:20, Chris Johns wrote:
On 29 Jun 2022, at 4:42 pm, Sebastian Huber
wrote:
On 29/06/2022 08:40, Se
On 30/6/2022 4:34 pm, Sebastian Huber wrote:
> On 30/06/2022 07:58, Sebastian Huber wrote:
>> On 29/06/2022 17:54, Kinsey Moore wrote:
>>> On 6/29/2022 04:34, Sebastian Huber wrote:
On 29/06/2022 11:20, Chris Johns wrote:
>
>> On 29 Jun 2022, at 4:42 pm, Sebastian Huber
>> wrote:
On 30/6/2022 1:42 am, Sebastian Huber wrote:
> On 27/06/2022 08:27, Sebastian Huber wrote:
>> On 27/06/2022 05:02, Chris Johns wrote:
>>> On 24/6/2022 7:44 pm, Sebastian Huber wrote:
On 20.06.22 04:03, chr...@rtems.org wrote:
> From: Chris Johns
>
> ---
> bsps/include/dev/i
On 28/6/2022 11:09 pm, andrew.butterfi...@scss.tcd.ie wrote:
> Dear RTEMS Developers,
>
> While the validation tests from the RTEMS pre-qualification activity are
> now merged into the RTEMS master, the work done in investigating and
> deploying formal methods techniques is not yet merged.
>
> T
Gedare and Hesham ... congratulations, this is fantastic news.
I know there has been a lot of work in these achievements and they are well
deserved.
Chris
On 29/6/2022 12:23 am, Joel Sherrill wrote:
> Hi
>
> I'd like to congratulate two RTEMS core developers on recent significant
> achievements
OK and thanks
Chris
On 29/6/2022 12:19 am, Sebastian Huber wrote:
> Initialize the debug console only once during early system initialization.
> ---
> bsps/arm/xilinx-zynq/console/debug-console.c | 5 +
> 1 file changed, 1 insertion(+), 4 deletions(-)
>
> diff --git a/bsps/arm/xilinx-zynq/c
On 29/6/2022 4:30 pm, Sebastian Huber wrote:
> The waf build system uses lists for tool flags. The build items may use
> variable substitution. Add the ability to use the variable substitution in
> lists. For example:
>
> MORE_FLAGS = ['-more', '-flags']
>
> flags:
> - -some-flag
> - ${MORE_FL
On 29/6/2022 4:30 pm, Sebastian Huber wrote:
> Update #4670.
> ---
> cpukit/include/rtems/score/io.h | 4 +
> cpukit/include/rtems/test-info.h| 6 ++
> cpukit/libtest/testgcovdumpinfo.c | 66 ++
> cpukit/score/src/iogcovdumpinfo.c | 101
On 29/6/2022 4:30 pm, Sebastian Huber wrote:
> This patch set adds support to build the RTEMS libraries with gcov
> instrumentation to get code and branch coverage. There are some improvements
> necessary in the build system to support different compiler flags for
> libraries
> and tests. In gen
On 01.07.22 02:18, Chris Johns wrote:
On 29/6/2022 4:30 pm, Sebastian Huber wrote:
The waf build system uses lists for tool flags. The build items may use
variable substitution. Add the ability to use the variable substitution in
lists. For example:
MORE_FLAGS = ['-more', '-flags']
flags:
On 01.07.22 02:37, Chris Johns wrote:
+void _IO_Gcov_dump_info_base64( IO_Put_char put_char, void *arg );
+
Why just a per char interface? Given this is in the score a buffer plus length
interface would make more sense? It would make the interface more efficient.
All the test output uses a sin
On 01.07.22 03:19, Chris Johns wrote:
On 29/6/2022 4:30 pm, Sebastian Huber wrote:
This patch set adds support to build the RTEMS libraries with gcov
instrumentation to get code and branch coverage. There are some improvements
necessary in the build system to support different compiler flags
On 1/7/2022 3:07 pm, Sebastian Huber wrote:
> On 01.07.22 03:19, Chris Johns wrote:
>> On 29/6/2022 4:30 pm, Sebastian Huber wrote:
>>> This patch set adds support to build the RTEMS libraries with gcov
>>> instrumentation to get code and branch coverage. There are some
>>> improvements
>>> neces
On 1/7/2022 3:00 pm, Sebastian Huber wrote:
> On 01.07.22 02:37, Chris Johns wrote:
>>> +void _IO_Gcov_dump_info_base64( IO_Put_char put_char, void *arg );
>>> +
>> Why just a per char interface? Given this is in the score a buffer plus
>> length
>> interface would make more sense? It would make t
On 01.07.22 07:48, Chris Johns wrote:
On 1/7/2022 3:00 pm, Sebastian Huber wrote:
On 01.07.22 02:37, Chris Johns wrote:
+void _IO_Gcov_dump_info_base64( IO_Put_char put_char, void *arg );
+
Why just a per char interface? Given this is in the score a buffer plus length
interface would make more
On 28/6/2022 1:14 pm, Kinsey Moore wrote:
> On 6/26/2022 22:37, Chris Johns wrote:
>> On 24/6/2022 7:43 pm, Sebastian Huber wrote:
>>> The GICv3 support is used by AArch32 (indicated by the ARM_MULTILIB_ARCH_V4
>>> define) and AArch64 targets. Use the existing WRITE_SR() abstraction to
>>> access
On 01.07.22 07:38, Chris Johns wrote:
If this enable is specific to GCC's gcov then maybe we should clearly label it
as that and avoid overloading the term and any possible confusion that might
bring. For example RTEMS_GCOV_CONVERGE?
It is not per se specific to GCC. Maybe we should name it
RT
On 1/7/2022 3:59 pm, Sebastian Huber wrote:
> On 01.07.22 07:48, Chris Johns wrote:
>> On 1/7/2022 3:00 pm, Sebastian Huber wrote:
>>> On 01.07.22 02:37, Chris Johns wrote:
> +void _IO_Gcov_dump_info_base64( IO_Put_char put_char, void *arg );
> +
Why just a per char interface? Given th
On 1/7/2022 4:03 pm, Sebastian Huber wrote:
> On 01.07.22 07:38, Chris Johns wrote:
If this enable is specific to GCC's gcov then maybe we should clearly
label it
as that and avoid overloading the term and any possible confusion that
might
bring. For example RTEMS_GCOV_CO
On 01.07.22 08:22, Chris Johns wrote:
I am encouraged by some of the generated code I have reviewed. I like what it
does.
I am a little lost with the difference between LIBRARY_OPTIMIZATION_FLAGS and
OPTIMIZATION_FLAGS? RTEMS is always a library so what is difference between
them? Are the OPT
On 1/7/2022 4:25 pm, Sebastian Huber wrote:
> On 01.07.22 08:22, Chris Johns wrote:
I am encouraged by some of the generated code I have reviewed. I like what
it
does.
>> I am a little lost with the difference between
>> LIBRARY_OPTIMIZATION_FLAGS and
>> OPTIMIZATI
---
testsuites/sptests/sppps01/init.c | 49 +--
1 file changed, 46 insertions(+), 3 deletions(-)
diff --git a/testsuites/sptests/sppps01/init.c
b/testsuites/sptests/sppps01/init.c
index 996a3a1e16..7779f7d9e7 100644
--- a/testsuites/sptests/sppps01/init.c
+++ b/testsu
23 matches
Mail list logo
