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 state
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
---
gcc
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 targe
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 t
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 allows
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.
>
>
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 f
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 pa
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
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: Rich
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
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 slight
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
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: checki
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 t
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 direc
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 w
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 a/gcc/config
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 th
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
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 w
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 a/gcc/config
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 th
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: checki
24 matches
Mail list logo
