On 22/06/2022 08:40, Chris Johns wrote:
On 22/6/2022 4:39 pm, Sebastian Huber wrote:
On 22/06/2022 08:36, Chris Johns wrote:
The patch works also for GCC 12. I only did a test run of the RTEMS tests.
It failed to apply for me with the gcc-12 for rtems6. The configure pieces did
not apply.
On 22/6/2022 4:39 pm, Sebastian Huber wrote:
> On 22/06/2022 08:36, Chris Johns wrote:
>>> The patch works also for GCC 12. I only did a test run of the RTEMS tests.
>> It failed to apply for me with the gcc-12 for rtems6. The configure pieces
>> did
>> not apply.
>
> I tested with the GCC 12 bra
On 22/06/2022 08:36, Chris Johns wrote:
The patch works also for GCC 12. I only did a test run of the RTEMS tests.
It failed to apply for me with the gcc-12 for rtems6. The configure pieces did
not apply.
I tested with the GCC 12 branch, maybe there are some configure changes
compared to the
There seems to be an issue with the RTEMS pipe() implementation or the
test configuration.
Forwarded Message
Subject: [PATCH] libstdc++: testsuite: use -lbsd for net_ts on RTEMS
Date: Wed, 22 Jun 2022 02:24:19 -0300
From: Alexandre Oliva via Gcc-patches
Reply-To: Alexandre Oli
On 22/6/2022 4:05 pm, Sebastian Huber wrote:
> On 22/06/2022 05:34, Chris Johns wrote:
>> On 22/6/2022 6:38 am, Chris Johns wrote:
On 21 Jun 2022, at 5:39 pm, Sebastian Huber
wrote:
On 09/06/2022 20:19, Sebastian Huber wrote:
> Remove RTEMS support from crossconfig.m4 sinc
On 22/06/2022 08:24, Alexandre Oliva via Libstdc++ wrote:
rtems6's rename() implementation errors with EEXIST when the rename-to
filename exists, even when renaming a file to itself or when renaming
a nonexisting file. Adjust expectations.
Regstrapped on x86_64-linux-gnu, also tested with a cro
On 22/06/2022 08:01, Alexandre Oliva via Gcc-patches wrote:
On rtems under qemu, the frequently-interrupted nanosleep ends up
sleeping shorter than expected, by a margin of less than 0,3%.
I figured failing the library test over a system (emulator?) bug is
undesirable, so I put in some toleranc
On 22/06/2022 05:34, Chris Johns wrote:
On 22/6/2022 6:38 am, Chris Johns wrote:
On 21 Jun 2022, at 5:39 pm, Sebastian Huber
wrote:
On 09/06/2022 20:19, Sebastian Huber wrote:
Remove RTEMS support from crossconfig.m4 since this code is not used due to
"with_newlib" being "yes".
libstdc++-v3/
From: Chris Johns
- This is the fix from PR105880:
https://gcc.gnu.org/bugzilla/attachment.cgi?id=53103
Closes #4661
---
.../config/tools/rtems-gcc-12-newlib-head.cfg | 29 ++-
1 file changed, 21 insertions(+), 8 deletions(-)
diff --git a/rtems/config/tools/rtems-gcc-12-newl
Hi,
This patch applies the fix for non-TLS eh_globals archs. See:
https://devel.rtems.org/ticket/4661
https://gcc.gnu.org/bugzilla/attachment.cgi?id=53103
Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
On 22/6/2022 6:38 am, Chris Johns wrote:
>> On 21 Jun 2022, at 5:39 pm, Sebastian Huber
>> wrote:
>>
>> On 09/06/2022 20:19, Sebastian Huber wrote:
>>> Remove RTEMS support from crossconfig.m4 since this code is not used due to
>>> "with_newlib" being "yes".
>>> libstdc++-v3/ChangeLog:
>>> * c
> On 21 Jun 2022, at 5:39 pm, Sebastian Huber
> wrote:
>
> On 09/06/2022 20:19, Sebastian Huber wrote:
>> Remove RTEMS support from crossconfig.m4 since this code is not used due to
>> "with_newlib" being "yes".
>> libstdc++-v3/ChangeLog:
>>* configure: Regnerate.
>>* configure.ac (ne
Hello Prashanth S,
On Tuesday 21 of June 2022 19:00:42 Prashanth S wrote:
> This is to present the updated CAN message structure.
>
> *Updating the CAN message structure:*
>
> struct can_message {
> uint32_t id; // 32 bits to support extended id (29 bits)
> uint32_t timestamp;
Hi All,
This is to present the updated CAN message structure.
*Updating the CAN message structure:*
struct can_message {
uint32_t id; // 32 bits to support extended id (29 bits)
uint32_t timestamp;
uint16_t flags;// RTR | BRS | EXT ...
uint16_t len;
uint8_t
Am 21.06.22 um 16:31 schrieb Duc Doan:
Using examples of working APIs is a good idea. But be careful not to
copy any code from that framework because the license (GPL) wouldn't be
compatible.
Sure, I don't copy their code but only see what functions should be in a
GPIO API (like re
>
> Using examples of working APIs is a good idea. But be careful not to
> copy any code from that framework because the license (GPL) wouldn't be
> compatible.
Sure, I don't copy their code but only see what functions should be in a
GPIO API (like read, write, toggle, pinmode).
Is set and reset
Hello Prashanth S and others,
I am copying reply to the list for recrd and others consideration
On Sunday 19 of June 2022 17:30:16 Christian Mauderer wrote:
> Would that be a generic test for the CAN API that all BSPs can run? Or
> would it be a hardware specific one?
The CAN base test can be HW
I am forwarding Oliver Hartkopp's founded reply
to the list for archival and rest of the RTEMS
community
-- Forwarded Message --
Subject: Re: Request for feedback for CAN message structure
Date: Tuesday 21 of June 2022, 08:55:03
From: Oliver Hartkopp
To: Pavel Pisa , devel@rtem
The real implementation of hardpps() is defined in kern_ntptime.c. Use it only
if the NTP support is needed by the application.
Update #2349.
---
cpukit/score/src/kern_tc.c | 12
1 file changed, 12 insertions(+)
diff --git a/cpukit/score/src/kern_tc.c b/cpukit/score/src/kern_tc.c
i
Hello Pavel and Prashanth,
Am 20.06.22 um 22:57 schrieb Pavel Pisa:
Hello Prashanth S and others,
excuse me for lower activity last weeks. We have exams period
and I have lot of other duties and was even ill. I am at Embedded
World in Nuremberg now, so may it be there is some chance to meet
som
On 09/06/2022 20:19, Sebastian Huber wrote:
Remove RTEMS support from crossconfig.m4 since this code is not used due to
"with_newlib" being "yes".
libstdc++-v3/ChangeLog:
* configure: Regnerate.
* configure.ac (newlib, *-rtems*): Enable TLS support for all RTEMS
targets
21 matches
Mail list logo
