Re: Patch ping - [PATCH] file-prefix-map: Fix up -f*-prefix-map= [PR108464]

On Fri, 2023-03-10 at 09:05 +, Richard Biener wrote: > On Fri, 10 Mar 2023, Jakub Jelinek wrote: > > > Hi! > > > > I'd like to ping these patches. All 3 variants have been > > bootstrapped/regtested on x86_64-linux and i686-linux, the last > > one is my preference I guess. The current

[PATCH] gcc/file-prefix-map: Fix NULL filename handling

e5c15eb183f17e806ad6b58c9497321ded87866f introduced a regression as some ada tests end up passing NULL as the filename to remap_filename(). Handle this as before to fix the tests. gcc/ChangeLog: * file-prefix-map.cc (remap_filename): Handle NULL filenames. Signed-off-by: Richard Purdie ---

Re: [PATCH 1/2] gcc/file-prefix-map: Allow remapping of relative paths

On Fri, 2022-11-04 at 10:12 +0100, Eric Botcazou wrote: > > gcc/ChangeLog: > > > > * file-prefix-map.cc (remap_filename): Allow remapping of > > relative paths > > Small regression in Ada though, probably a missing guard somewhere: > > === gnat tests === > > > Running

Re: [PATCH 2/2] libcpp: Avoid remapping filenames within directives

On Tue, 2022-11-01 at 13:32 -0600, Jeff Law wrote: > On 8/17/22 06:15, Richard Purdie via Gcc-patches wrote: > > Code such as: > #include __FILE__ > > > > can interact poorly with file-prefix-map options when cross compiling. In > > general you're after to rem

[PATCH v2] libcpp: Avoid remapping filenames within directives

Code such as: #include __FILE__ can interact poorly with the *-prefix-map options when cross compiling. In general you're after to remap filenames for use in target context but the local paths should be used to find include files at compile time. Ingoring filename remapping for directives

Re: [PATCH] config/rs6000/t-float128: Don't encode full build paths into headers

On Wed, 2022-08-17 at 13:10 +0100, Richard Purdie via Gcc-patches wrote: > Avoid encoding full build paths into headers, just use the basename of the > file. > This aids build reproducibility where the build paths vary and source is saved > for debugging purposes. > >

Re: [PATCH 2/2] libcpp: Avoid remapping filenames within directives

On Wed, 2022-08-17 at 13:15 +0100, Richard Purdie via Gcc-patches wrote: > Code such as: > > can interact poorly with file-prefix-map options when cross compiling. In > general you're after to remap filenames for use in target context but the > local paths should be used to fin

[PATCH 1/2] gcc/file-prefix-map: Allow remapping of relative paths

Relative paths currently aren't remapped by -ffile-prefix-map and friends. When cross compiling with separate 'source' and 'build' directories, the same relative paths between directories may not be available on target as compared to build time. In order to be able to remap these relative build

[PATCH 2/2] libcpp: Avoid remapping filenames within directives

Code such as: can interact poorly with file-prefix-map options when cross compiling. In general you're after to remap filenames for use in target context but the local paths should be used to find include files at compile time. Ingoring filename remapping for directives is one way to avoid such

[PATCH] config/rs6000/t-float128: Don't encode full build paths into headers

Avoid encoding full build paths into headers, just use the basename of the file. This aids build reproducibility where the build paths vary and source is saved for debugging purposes. libgcc/ChangeLog: * config/rs6000/t-float128: Don't encode full build paths into headers Signed-off-by:

Re: [PATCH 3/5] gcc: Add --nostdlib++ option

On Thu, 2021-12-02 at 20:04 -0700, Jeff Law wrote: > > On 10/28/2021 10:39 AM, Richard Purdie wrote: > > On Thu, 2021-10-28 at 08:51 -0600, Jeff Law wrote: > > > On 10/27/2021 2:05 PM, Richard Purdie via Gcc-patches wrote: > > > > OpenEmbedded/Yocto Project builds

Re: [PATCH 3/5] gcc: Add --nostdlib++ option

On Wed, 2021-10-27 at 22:56 +0200, Bernhard Reutner-Fischer wrote: > On Wed, 27 Oct 2021 21:05:03 +0100 > Richard Purdie via Gcc-patches wrote: > > > OpenEmbedded/Yocto Project builds libgcc and the other gcc runtime libraries > > separately from the compiler and

Re: [PATCH 3/5] gcc: Add --nostdlib++ option

On Thu, 2021-10-28 at 08:51 -0600, Jeff Law wrote: > > On 10/27/2021 2:05 PM, Richard Purdie via Gcc-patches wrote: > > OpenEmbedded/Yocto Project builds libgcc and the other gcc runtime libraries > > separately from the compiler and slightly differently to the stand

[PATCH 1/5] Makefile.in: Ensure build CPP/CPPFLAGS is used for build targets

During cross compiling, CPP is being set to the target compiler even for build targets. As an example, when building a cross compiler targetting mingw, the config.log for libiberty in build.x86_64-pokysdk-mingw32.i586-poky-linux/build-x86_64-linux/libiberty/config.log shows: configure:3786:

[PATCH 0/5] OpenEmbedded/Yocto Project gcc patches

OpenEmbedded/Yocto Project extensively uses gcc to cross compile in many different and interesting places. On the most part we're very happy, thanks! We do have a small collection of patches and I believe it would be beneficial to share some of them. I've picked some of the simpler ones and have

[PATCH 5/5] gcc: Pass sysroot options to cpp for preprocessed source

OpenEmbedded/Yocto Project extensively uses the --sysroot support within gcc. We discovered that when compiling preprocessed source (.i or .ii files), the compiler will try and access the builtin sysroot location rather than the --sysroot option specified on the commandline. If access to that

[PATCH 3/5] gcc: Add --nostdlib++ option

OpenEmbedded/Yocto Project builds libgcc and the other gcc runtime libraries separately from the compiler and slightly differently to the standard gcc build. In general this works well but in trying to build them separately we run into an issue since we're using our gcc, not xgcc and there is no

[PATCH 4/5] gcc/nios2: Define the musl linker

Add a definition of the musl linker used on the nios2 platform. 2021-10-26 Richard Purdie gcc/ChangeLog: * config/nios2/linux.h (MUSL_DYNAMIC_LINKER): Add musl linker Signed-off-by: Richard Purdie --- gcc/config/nios2/linux.h | 1 + 1 file changed, 1 insertion(+) diff --git

[PATCH 2/5] gcc: Fix "argument list too long" from install-plugins

When building in longer build paths (200+ characters), the "echo $(PLUGIN_HEADERS)" from the install-plugins target would cause an "argument list too long error" on some systems. Avoid this by calling make's sort function on the list which removes duplicates and stops the overflow from reaching

Re: [PATCH 1/4] Makefile.in: Ensure build CPP is used for build targets

On Tue, 2021-10-26 at 14:55 +0200, Richard Biener wrote: > On Tue, Oct 26, 2021 at 2:45 PM Richard Purdie via Gcc-patches > wrote: > > > > During cross compiling, CPP is being set to the target compiler even for > > build targets. As an example, when building a c

[PATCH 3/4] gcc: Add --nostdlib++ option

OpenEmbedded/Yocto Project builds libgcc and the other gcc runtime libraries separately from the compiler and slightly differently to the standard gcc build. In general this works well but in trying to build them separately we run into an issue since we're using our gcc, not xgcc and there is no

[PATCH 4/4] gcc/nios2: Define the musl linker

Add a definition of the musl linker used on the nios2 platform. 2021-10-26 Richard Purdie gcc/ChangeLog: * config/nios2/linux.h (MUSL_DYNAMIC_LINKER): Add musl linker Signed-off-by: Richard Purdie --- gcc/config/nios2/linux.h | 1 + 1 file changed, 1 insertion(+) diff --git

[PATCH 2/4] gcc: Fix "argument list too long" from install-plugins

When building in longer build paths (200+ characters), the "echo $(PLUGIN_HEADERS)" from the install-plugins target would cause an "argument list too long error" on some systems. Avoid this by calling make's sort function on the list which removes duplicates and stops the overflow from reaching

[PATCH 1/4] Makefile.in: Ensure build CPP is used for build targets

During cross compiling, CPP is being set to the target compiler even for build targets. As an example, when building a cross compiler targetting mingw, the config.log for libiberty in build.x86_64-pokysdk-mingw32.i586-poky-linux/build-x86_64-linux/libiberty/config.log shows: configure:3786: