On Fri, Mar 1, 2024 at 8:40 AM Joel Sherrill
wrote:
> On Fri, Mar 1, 2024 at 8:21 AM Kinsey Moore
> wrote:
>
>> A very similar change was made in 2017 to resolve the same warning for a
>> different variable. The only real difference is that it is wrapped in
>> __rtems__ ifdefs. I can move this c
This resovles a warning where a variable could be used before it is
initialized in some code paths.
---
testsuites/benchmarks/dhrystone/dhry_1.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/testsuites/benchmarks/dhrystone/dhry_1.c
b/testsuites/benchmarks/dhrystone/dhry_1.c
index 3ad2e7f204
On Fri, Mar 1, 2024 at 8:21 AM Kinsey Moore
wrote:
> A very similar change was made in 2017 to resolve the same warning for a
> different variable. The only real difference is that it is wrapped in
> __rtems__ ifdefs. I can move this change to the #ifdef'd section if that's
> preferable.
>
Do no
A very similar change was made in 2017 to resolve the same warning for a
different variable. The only real difference is that it is wrapped in
__rtems__ ifdefs. I can move this change to the #ifdef'd section if that's
preferable.
Kinsey
On Fri, Mar 1, 2024 at 1:02 AM Sebastian Huber <
sebastian.h
On 29.02.24 00:05, Chris Johns wrote:
If it is will the details be exported in the pkgconfig file and made available
for users building applications in a consistent and easy to use way?
Application build systems can query the tool using the RTEMS_MKIMAGE package
configuration varible, for exampl
On 29.02.24 00:05, Chris Johns wrote:
It could help to export also EXEEXT and BOOT_IMAGE_EXTENSION in the package
configuration file. For RTEMS 6, we should have a look how our package
configuration support can be used to build applications on some commonly used
build systems. We are currently no
