On Wed, May 29, 2024 at 7:13 PM 赵海峰 via Gcc wrote:
>
> Dear Sir/Madam,
>
>
> We found that running on intel SPR UnixBench compiled with gcc 10.3 performs
> worse than with gcc 8.5 for dhry2reg benchmark.
>
>
> I found it related with -fcommon option which is disabled in 10.3 by default.
> Fcommo
Dear Sir/Madam,
We found that running on intel SPR UnixBench compiled with gcc 10.3 performs
worse than with gcc 8.5 for dhry2reg benchmark.
I found it related with -fcommon option which is disabled in 10.3 by default.
Fcommon will make global variables addresses in special order in bss
sect
Snapshot gcc-11-20240529 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/11-20240529/
and on various mirrors, see https://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 11 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch
On 28 May 2024, at 14:35, Zack Weinberg wrote:
> These are probably all either vendor or OS names from the late 1980s or
> early 1990s. Can anyone help me fill out the following list of things
> that ought to appear in testsuite/config-sub.data, if I knew what to
> put in place of the question ma
On Wed, May 29, 2024 at 1:34 PM Tom Tromey wrote:
> > "Jason" == Jason Merrill writes:
>
> Jason> Thanks, though I don't think all that code needs to go;
> Jason> AC_PROG_CXX_STDCXX_EDITION_TRY still looks useful for a project that
> Jason> relies on features from a particular standard. We j
> "Jason" == Jason Merrill writes:
Jason> Thanks, though I don't think all that code needs to go;
Jason> AC_PROG_CXX_STDCXX_EDITION_TRY still looks useful for a project that
Jason> relies on features from a particular standard. We just don't want
Jason> AC_PROG_CXX to invoke it.
I didn't re
On Wed, 29 May 2024 10:33:16 +0100
Jonathan Wakely wrote:
> > 1. Some GCC binaries hardcode RUNPATH and use
>
> Binaries, or just libraries?
>
I meant GCC shared library binaries. The actual executables under bin/
do not use RUNPATH with GCC default build behaviour.
I think FreeBSD GCC compil
On Wed, 29 May 2024 at 09:15, Sad Clouds via Gcc wrote:
>
> On Wed, 29 May 2024 09:05:50 +0200
> Richard Biener wrote:
>
> > If you build an executable to pick up libstdc++ via a RUNPATH that apps
> > RUNPATH
> > should apply to libgcc as well. If you use LD_LIBRARY_PATH the story
> > is the sa
On Wed, May 29, 2024 at 10:14 AM Sad Clouds wrote:
>
> On Wed, 29 May 2024 09:05:50 +0200
> Richard Biener wrote:
>
> > If you build an executable to pick up libstdc++ via a RUNPATH that apps
> > RUNPATH
> > should apply to libgcc as well. If you use LD_LIBRARY_PATH the story
> > is the same.
>
On Wed, 29 May 2024 09:05:50 +0200
Richard Biener wrote:
> If you build an executable to pick up libstdc++ via a RUNPATH that apps
> RUNPATH
> should apply to libgcc as well. If you use LD_LIBRARY_PATH the story
> is the same.
>
> So what's your actual failure mode?
Hello, the concern I have
On Wed, May 29, 2024 at 8:47 AM Sad Clouds via Gcc wrote:
>
> Hello, I'm noticing some issues with libstdc++ after building GCC from
> sources and installing into /opt/gcc-14.1.0. Specifically:
>
> $ objdump -x /opt/gcc-14.1.0/lib/libstdc++.so.6 | grep RUNPATH
>
> $ ldd /opt/gcc-14.1.0/lib/libstdc
11 matches
Mail list logo
