[PATCH] MAINTAINERS: add myself

2019-12-20 Thread Jérôme Lambourg
Add myself to MAINTAINERS file

2019-12-20  Jerome Lambourg 

 * MAINTAINERS: Add myself to Write After Approval



maintainers.patch
Description: Binary data


[patch] libstdc++/configure: strengthen the check for availability of pthread_rwlock_t

2019-12-17 Thread Jérôme Lambourg
Hello,

This patch to libstdc++ configure ensures that pthread_rwlock_t is used only
when pthread is used for gthreads implementation.

The original issue is that VxWorks comes with its native tasking layer and an
optional pthread layer built above it. As pthread is an optional feature of the
kernel it may not be available on the target board.

Now, even being optional, the headers are present in the development
environment, and are in particular partially available when including the main
vxWorks.h header, and so are detected automatically as available by libstdc++.

This patch will thus refine the check and will make configure try to use
pthread_rwlock_t only when the gthr library already relies on pthread.

This was of course tested with vxworks targets, and we also verified that this
does not impact Linux (that uses pthread) or Windows (that does not use
pthread).

Best regards,
- Jerome

2019-12-16  Jerome Lambourg  

libstdc++
* acinclude.m4 (_GLIBCXX_USE_PTHREAD_RWLOCK_T): Checks that _PTHREADS
is defined after including gthr.h.
* configure: Regenerate.



pthread_rwlock_libstdcxx_configure.patch
Description: Binary data


[patch] Test setrlimit with c++ in libstdc++/configure

2019-12-16 Thread Jérôme Lambourg
Hello,

In libstdc++, the test for the presence of setrlimit on the target is currently
performed in C as opposed to the other similar tests there. This leads on only a
warning being issued during configure as opposed to the expected error, and thus
improper definition of _GLIBCXX_RES_LIMITS.

This happens in particular on VxWorks where the standard header files are
available and the "struct rlimit" type definition is there. During configure,
only the setrlimit function prototype is missing so the compilation in C only
yield warnings and the test passes.

This patch fixes that by switching to C++ before testing setrlimit. It was
implemented first on gcc-8 for our internal needs, then ported to gcc-9 and now
mainline for contribution.

This change shouldn't impact targets where setrlimit is actually defined. I
tested the change on Linux to check that the result of the configure stage is
not changed by this patch.

Best regards,
Jerome


2019-12-16  Corentin Gay  
   Jerome Lambourg  

libstdc++
* acinclude.m4 (GLIBCXX_CHECK_SETRLIMIT): Test with AC_LANG_CPLUSPLUS.
* configure: Regenerate.



setrlimit_libstdcxx_configure.patch
Description: Binary data


Re: [PATCH ARM] Fix armv8-m multilib build failure with stdint.h

2018-05-16 Thread Jérôme Lambourg
Hello Kyrill,

> Thanks for the patch! To validate it your changes you can also look at the 
> disassembly
> of the cmse.c binary in the build tree. If the binary changes with your patch 
> then that
> would indicate some trouble.

Good idea. So I just did that and the assembly of both objects are identical
(before and after the patch).

> There are places in arm_cmse.h that use intptr_t. You should replace those as 
> well.
> Look for the cmse_nsfptr_create and cmse_is_nsfptr macros...

Indeed, good catch. I did not see those as this part is not included in the 
armv8-m.

Below the updated patch and modified changelog.

2018-05-16  Jerome Lambourg  
gcc/
* config/arm/arm_cmse.h (cmse_nsfptr_create, cmse_is_nsfptr): Remove
#include . Replace intptr_t with __INTPTR_TYPE__.

libgcc/
* config/arm/cmse.c (cmse_check_address_range): Replace
UINTPTR_MAX with __UINTPTR_MAX__ and uintptr_t with __UINTPTR_TYPE__.



gcc.patch
Description: Binary data


[PATCH ARM] Fix armv8-m multilib build failure with stdint.h

2018-05-15 Thread Jérôme Lambourg
Hello gcc-patch list,

While trying to build a x86_64-linux hosted cross arm bare metal compiler with
both --with-multilib-list=rmprofile and --without-headers, the libgcc build
fails while trying to build the armv8-m variant with the following message:

In file included from .../build/gcc/include/arm_cmse.h:38,
 from .../gcc/libgcc/config/arm/cmse.c:27:
.../build/gcc/include/stdint.h:9:16: fatal error: stdint.h: No such file or 
directory
 # include_next 
^~

Attached is a patch that removes the dependency over stdint.h (to respect
--without-headers) and replaces uintptr_t and UINTPTR_MAX in cmse.c with their
equivalent gcc predefined macros, respectively __UINTPTR_TYPE__ and
__UINTPTR_MAX__.

For the record, I configured gcc (r260250) with the following command:
../gcc/configure  --enable-languages=c --with-gnu-as --with-gnu-ld \
  --with-multilib-list=rmprofile --disable-nls --without-libiconv-prefix \
  --enable-multilib --target=arm-eabi --without-headers

Unfortunately, I don't have an armv8-m testing environment, so could only check
that the libgcc now builds fine. But the patch is small and simple enough that
I'm confident the generated code is equivalent to the original intent.

2018-05-15  Jerome Lambourg  

gcc/
* config/arm/arm_cmse.h: Remove #include 

libgcc/
* config/arm/cmse.c (cmse_check_address_range): Replace
UINTPTR_MAX with __UINTPTR_MAX__ and uintptr_t with __UINTPTR_TYPE__.



gcc.patch
Description: Binary data


Re: [patch] allow --target=e500v[12]-* in configure

2016-06-24 Thread Jérôme Lambourg
Hello,

Anyone to review this proposal?

Best regards,
- Jerome

> An initial patch has been integrated into gnu-config to translate triplets 
> like
> e500v2-*- into powerpc-*-spe.



[patch] allow --target=e500v[12]-* in configure

2016-06-17 Thread Jérôme Lambourg
Hello,

An initial patch has been integrated into gnu-config to translate triplets like
e500v2-*- into powerpc-*-spe.

The spe extension to the os is expected for targets such as e500v[12]-*-linux
(translated as powerpc-*-linux-gnuspe) or eabi targets.

This patch integrates the patch of gnu-config (config.sub), and takes care of
the vxworks case, as well as properly set the default value for --with-cpu.

I checked that this works with the following targets:
* e500v2-wrs-vxworks
* e500v2-gnu-linux

Thanks in advance for your feedback,

- Jérôme

Author: Jerome Lambourg 
Date:   Tue Jun 14 10:57:06 2016 +0200

P614-008: support e500v[12] configuration as PPC with cpu 854[08]

toplevel/
* config.sub: merge with gnu-config trunk. Accept e500v[12] cpu names, and
canonicalize to powerpc, and add a "spe" suffix to the os name.
* gcc/config.gcc: determine with_cpu from the non canonical target name, and
make sure the powerpc-wrs-vxworks*spe is properly handled.
* libgcc/config.host: accept vxworks*spe when configuring libgcc.



gcc-e500v12-config.diff
Description: Binary data