[PATCH] diagnostics: fix gcc-urlifier.cc bootstrap failure [PR112379]

From: Sergei Trofimovich Without the change `./configure --enable-checking=release` bootstrap fails as: gcc/gcc-urlifier.cc:100:1: error: 'get_url_suffix_for_quoted_text()' defined but not used [-Werror=unused-function] This happens because the helper is used only in `ASSERT

Re: [PATCH] libgcc: make heap-based trampolines conditional on libc presence

On Mon, 23 Oct 2023 13:54:01 +0100 Iain Sandoe wrote: > hi Sergei, > > > On 23 Oct 2023, at 13:43, Sergei Trofimovich wrote: > > > > From: Sergei Trofimovich > > > > To build `libc` for a target one needs to build `gcc` without `libc` > > supp

[PATCH] libgcc: make heap-based trampolines conditional on libc presence

From: Sergei Trofimovich To build `libc` for a target one needs to build `gcc` without `libc` support first. Commit r14-4823-g8abddb187b3348 "libgcc: support heap-based trampolines" added unconditional `libc` dependency and broke libc-less `gcc` builds. An example failure on `x86_

[PATCH v4] ipa-utils: avoid uninitialized probabilities on ICF [PR111559]

places. Oh, great point! Completely forgot about it. Attached v4. If it still looks reasonable I'll check again if `python` and `profiledbootstrap` still survives it and will push. -- Sergei >From cb9852216b5b2524f72964b399c133557ec98df0 Mon Sep 17 00:00:00 2001 From: Sergei Trofimovich Date: Wed, 27 Sep 2023 14:29:12 +

Re: [PATCH v2] ipa-utils: avoid uninitialized probabilities on ICF [PR111559]

On Thu, Oct 05, 2023 at 01:52:30PM +0200, Jan Hubicka wrote: > > From: Sergei Trofimovich > > > > r14-3459-g0c78240fd7d519 "Check that passes do not forget to define profile" > > exposed check failures in cases when gcc produces uninitialized profile >

Re: Scaling -fmacro-prefix-map= to thousands entries

On Thu, Oct 05, 2023 at 07:20:35AM -0400, Ben Boeckel wrote: > On Wed, Oct 04, 2023 at 22:19:32 +0100, Sergei Trofimovich via Gcc wrote: > > The prototype that creates equivalent of the following commands does > > work for smaller packages: > > > > > &

Re: Scaling -fmacro-prefix-map= to thousands entries

On Thu, Oct 05, 2023 at 09:19:15AM +0200, Richard Biener wrote: > On Wed, Oct 4, 2023 at 11:20 PM Sergei Trofimovich via Gcc > wrote: > > > > Hi gcc developers! > > > > Tl;DR: > > > > I would like to implement a scalable way to pass `-fmacro-prefix-m

Scaling -fmacro-prefix-map= to thousands entries

! -- Sergei >From b10785c1be469319a09b10bc69db21159b0599ee Mon Sep 17 00:00:00 2001 From: Sergei Trofimovich Date: Fri, 22 Sep 2023 22:41:49 +0100 Subject: [PATCH] gcc/file-prefix-map.cc: always mangle __FILE__ into invalid store path Without the change `__FILE__` used in static inl

[PATCH] Makefile.tpl: disable -Werror for feedback stage [PR111663]

From: Sergei Trofimovich Without the change profiled bootstrap fails for various warnings on master branch as: $ ../gcc/configure $ make profiledbootstrap ... gcc/genmodes.cc: In function ‘int main(int, char**)’: gcc/genmodes.cc:2152:1: error: ‘gcc/build/genmodes.gcda

[PATCH v2] ipa-utils: avoid uninitialized probabilities on ICF [PR111559]

From: Sergei Trofimovich r14-3459-g0c78240fd7d519 "Check that passes do not forget to define profile" exposed check failures in cases when gcc produces uninitialized profile probabilities. In case of PR/111559 uninitialized profile is generated by edges executed 0 times reported by I

[PATCH v2] rtl: fix build failure on -fchecking=2 [PR111642]

From: Sergei Trofimovich Before the change `make bootstrap4` (or `make profiledbootstrap`) failed as: gcc/rtl-tests.cc:249:25: in ‘constexpr’ expansion of ‘poly_int<1, long int>(1, 1)’ gcc/poly-int.h:453:5: error: too many initializers for ‘long int [1]’ The failure happene

[PATCH] rtl: fix buidl failure on -fchecking=2 [PR111642]

From: Sergei Trofimovich Before the change `make bootstrap4` (or `make profiledbootstrap`) failed as: gcc/rtl-tests.cc:249:25: in ‘constexpr’ expansion of ‘poly_int<1, long int>(1, 1)’ gcc/poly-int.h:453:5: error: too many initializers for ‘long int [1]’ The failure happene

[PATCH] ggc: do not wipe out unrelated data via gt_ggc_rtab

From: Sergei Trofimovich There are 3 GC root tables: gt_ggc_rtab gt_ggc_deletable_rtab gt_pch_scalar_rtab `deletable` and `scalar` tables are both simple: each element always contains a pointer to the beginning of the object and it's size is the full object. `rtab` is different: it's

[PATCH] ipa-utils: avoid generating uninitialized probabilities on merges.

From: Sergei Trofimovich r14-3459-g0c78240fd7d519 "Check that passes do not forget to define profile" exposed check failures in cases when gcc produces uninitialized profile probabilities. In case of PR/111559 uninitialized profile is generated by edges executed 0 times duri

[PATCH] Drop unused enum vrp_mode.

From: Sergei Trofimovich Follow removal of EVRP and clean up unused defines. gcc/ * flag-types.h (vrp_mode): Remove unused. --- gcc/flag-types.h | 7 --- 1 file changed, 7 deletions(-) diff --git a/gcc/flag-types.h b/gcc/flag-types.h index 36305de589e..7466c1106f2 100644 --- a/gcc

[PATCH] mh-mingw: drop unused BOOT_CXXFLAGS variable

From: Sergei Trofimovich gcc's build system has BOOT_CFLAGS and various STAGE_C{,XX}FLAGS variables. BOOT_CXXFLAGS is not handled anywhere. config/ * mh-mingw: Drop assignment of unused BOOT_CXXFLAGS variable. --- config/mh-mingw | 1 - 1 file changed, 1 deletion(-) diff --git

PING [PATCH] gcc/config/t-i386: add build dependencies on i386-builtin-types.inc

On Thu, 22 Sep 2022 22:07:52 +0100 Sergei Trofimovich wrote: > On Fri, 16 Sept 2022 at 19:49, Sergei Trofimovich wrote: > > > > From: Sergei Trofimovich > > > > i386-builtin-types.inc is included indirectly via i386-builtins.h > > into 4 files: i386.cc i38

Re: [PATCH] gcc/config/t-i386: add build dependencies on i386-builtin-types.inc

On Fri, 16 Sept 2022 at 19:49, Sergei Trofimovich wrote: > > From: Sergei Trofimovich > > i386-builtin-types.inc is included indirectly via i386-builtins.h > into 4 files: i386.cc i386-builtins.cc i386-expand.cc i386-features.cc > > Only i386.cc dependency was present

[PATCH] gcc/config/t-i386: add build dependencies on i386-builtin-types.inc

From: Sergei Trofimovich i386-builtin-types.inc is included indirectly via i386-builtins.h into 4 files: i386.cc i386-builtins.cc i386-expand.cc i386-features.cc Only i386.cc dependency was present in gcc/config/t-i386 makefile. As a result parallel builds occasionally fail as: g++ ... -o

[PATCH] Makefile.def: drop remnants of unused libelf

From: Sergei Trofimovich Use of libelf was removed from gcc in misc/cutover-cvs2svn-32781-g48215350c24 ("re PR lto/46273 (Failed to bootstrap)") around 2010, before gcc-4.6.0. This change removes unused references to libelf from top-level condifure and Makefile. / * Makefile

[PATCH] Add libgo dependency on libbacktrace.

From: Sergei Trofimovich Noticed missing dependency when regenerated Makefile.in for unrelated change with 'autoget Makefile.def'. The change was lost in basepoints/gcc-12-6861-gaeac414923a ("Revert "Fix PR 67102: Add libstdc++ dependancy to libffi" [PR67102]"). /

[PATCH] driver: fix environ corruption after putenv() [PR106624]

From: Sergei Trofimovich The bug appeared afte r13-2010-g1270ccda70ca09 "Factor out jobserver_active_p" slightly changed `putenv()` use from allocating to non-allocating: -xputenv (concat ("MAKEFLAGS=", dup, NULL)); +xputenv (jinfo.skipped_makeflags.c_str ()); `xpu

[PATCH v2] jit: avoid calloc() poisoning on musl [PR106102]

From: Sergei Trofimovich On musl uses calloc() (via ). jit/ includes it directly and exposes use of poisoned calloc(): /build/build/./prev-gcc/xg++ ... ../../gcc-13-20220626/gcc/jit/jit-playback.cc make[3]: *** [Makefile:1143: jit/libgccjit.o] Error 1 make[3]: *** Waiting

[PATCH] jit: avoid calloc() poisoning on musl [PR106102]

From: Sergei Trofimovich On musl uses calloc() (via ). jit/ includes it directly and exposes use of poisoned calloc(): /build/build/./prev-gcc/xg++ ... ../../gcc-13-20220626/gcc/jit/jit-playback.cc make[3]: *** [Makefile:1143: jit/libgccjit.o] Error 1 make[3]: *** Waiting

[PATCH] c++: avoid poisoning on musl [PR106102]

From: Sergei Trofimovich On musl uses calloc() (via ). includes it indirectly and exposes use of poisoned calloc() when module code is built: /build/build/./prev-gcc/xg++ ... ../../gcc-13-20220626/gcc/cp/mapper-resolver.cc In file included from /<>/musl-1.2.3-dev/i

[PATCH, gcc-11 backport] gcov-profile: Allow negative counts of indirect calls [PR105282]

From: Sergei Trofimovich TOPN metrics are histograms that contain overall count and per-bucket count. Overall count can be negative when two profiles merge and some of per-bucket metrics are disacarded. Noticed as an ICE on python PGO build where gcc crashes as: during IPA pass: modref

[PATCH] gcov-profile: Allow negavive counts of indirect calls [PR105282]

From: Sergei Trofimovich TOPN metrics are histograms that contain overall count and per-bucket count. Overall count can be nevative when two profiles merge and some of per-bucket metrics are dropped. Noticed as an ICE on python PGO build where gcc crashes as: during IPA pass: modref

[PATCH] libgcc: IA64: don't compile glibc-based unwinder without libc headers

From: Sergei Trofimovich In --without-headers mode gcc fails to bootstrap on libgcc as: /build/build/./gcc/xgcc -B/build/build/./gcc/ ... -Dinhibit_libc -c fde-glibc.c ../../../gcc-12-20220403/libgcc/config/ia64/fde-glibc.c:33:10: fatal error: stdlib.h: No such file

[PATCH v2] Fortran manual: extend deprecated BOZ examples with X'ABC'

From: Sergei Trofimovich gcc/fortran/ * gfortran.texi (BOZ literal constants): add X'ABC' to the list of valid examples. --- gcc/fortran/gfortran.texi | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/gcc/fortran/gfortran.texi b/gcc/fortran

[PATCH] Fortran manual: fix invalid BOZ 'ABC'X example to be X'ABC'.

From: Sergei Trofimovich gcc/fortran/ * gfortran.texi (BOZ literal constants): fix invalid BOZ 'ABC'X example to be X'ABC'. --- gcc/fortran/gfortran.texi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/gcc/fortran/gfortran.texi b/gcc/fortran

Re: [PATCH] libbacktrace: fix fd leak tests on systems with extra descriptors

On Fri, 13 Aug 2021 09:52:53 -0700 Ian Lance Taylor wrote: > On Fri, Aug 13, 2021 at 12:05 AM Sergei Trofimovich wrote: > > > > On Thu, 12 Aug 2021 16:16:04 -0700 > > Ian Lance Taylor wrote: > > > > > On Thu, Aug 12, 2021 at 3:34 PM Sergei Trof

Re: [PATCH] libbacktrace: fix fd leak tests on systems with extra descriptors

On Thu, 12 Aug 2021 16:16:04 -0700 Ian Lance Taylor wrote: > On Thu, Aug 12, 2021 at 3:34 PM Sergei Trofimovich via Gcc-patches > wrote: > > > > From: Sergei Trofimovich > > > > I noticed test failures when ran gcc test suite from under mc shell. > > m

[PATCH] libbacktrace: fix b2test_buildid test on non-english locales

From: Sergei Trofimovich On LANG=ru_RU.UTF-8 'b2test_buildid' test fails due to localized readelf output: $ LANG=ru_RU.UTF-8 readelf -n b2test | fgrep 4e37e8f ID сборки: 4e37e8fead8d6e8b0a9dc95ea25cd784dff3a393 $ LANG=C readelf -n b2test | fgrep 4e37e8f Build ID

[PATCH] libbacktrace: fix fd leak tests on systems with extra descriptors

From: Sergei Trofimovich I noticed test failures when ran gcc test suite from under mc shell. mc opens fd=9 and exposes it to child processes. As a result a few tests failes: FAIL: b2test_buildid FAIL: btest_gnudebuglink FAIL: btest FAIL: btest_lto FAIL: btest_alloc FAIL

Re: [PATCH] c++: suppress all warnings on memper pointers to work around dICE [PR101219]

On Wed, 11 Aug 2021 15:19:58 -0400 Jason Merrill wrote: > On 8/6/21 11:34 AM, Sergei Trofimovich wrote: > > On Thu, 29 Jul 2021 11:41:39 -0400 > > Jason Merrill wrote: > > > >> On 7/22/21 7:15 PM, Sergei Trofimovich wrote: > >>> From: Sergei T

Re: [PATCH] c++: suppress all warnings on memper pointers to work around dICE [PR101219]

On Thu, 29 Jul 2021 11:41:39 -0400 Jason Merrill wrote: > On 7/22/21 7:15 PM, Sergei Trofimovich wrote: > > From: Sergei Trofimovich > > > > r12-1804 ("cp: add support for per-location warning groups.") among other > > things removed warning suppression fr

Re: [PATCH] c++: suppress all warnings on memper pointers to work around dICE [PR101219]

On Fri, 23 Jul 2021 10:33:09 -0600 Jeff Law wrote: > On 7/22/2021 5:15 PM, Sergei Trofimovich via Gcc-patches wrote: > > From: Sergei Trofimovich > > > > r12-1804 ("cp: add support for per-location warning groups.") among other > > things removed warning su

[PATCH] c++: suppress all warnings on memper pointers to work around dICE [PR101219]

From: Sergei Trofimovich r12-1804 ("cp: add support for per-location warning groups.") among other things removed warning suppression from a few places including ptrmemfuncs. Currently ptrmemfuncs don't have valid BINFO attached which causes ICEs in access checks: crash_signal

[PATCH] musl: always use 'lib' directory for all x86_64 ABIs [PR90077]

From: Sergei Trofimovich musl library intentionally does not support glibc-style multilib layout and usually assumes --libdir=lib (Gentoo and Alpine Linux both use it). Before the change --disable-multilib x86_64-gentoo-linux-musl returned: $ gcc -print-multi-os-directory ../lib64

[PATCH] docs: drop unbalanced parenthesis in rtl.texi

From: Sergei Trofimovich gcc/ChangeLog: * doc/rtl.texi: drop unbalanced parenthesis. --- gcc/doc/rtl.texi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/gcc/doc/rtl.texi b/gcc/doc/rtl.texi index 5af71137a87..e1e76a93a8b 100644 --- a/gcc/doc/rtl.texi +++ b/gcc/doc

[PATCH] tree-optimization/98499 - fix modref analysis on RVO statements

From: Sergei Trofimovich Before the change RVO gimple statements were treated as local stores by modres analysis. But in practice RVO escapes target. 2021-01-30 Sergei Trofimovich gcc/ChangeLog: PR tree-optimization/98499 * ipa-modref.c: treat RVO conservatively and assume

[PATCH] ipa-modref: avoid linebreak split in debug print

From: Sergei Trofimovich * ipa-modref.c (merge_call_side_effects): Fix linebreak split by reordering two print calls. --- gcc/ipa-modref.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/gcc/ipa-modref.c b/gcc/ipa-modref.c index fcc676d25e4

Re: [PATCH] PR preprocessor/94657: use $AR, not 'ar',

On Fri, 13 Nov 2020 11:45:56 -0700 Jeff Law wrote: > > On 4/22/20 4:05 PM, Sergei Trofimovich wrote: > > From: Sergei Trofimovich > > > > On system with 'ar' and '${CHOST}-ar' the latter is preferred. > > as it might not match default 'ar'. > > > > Bug

[PATCH gcc-10] gcov: fix TOPN streaming from shared libraries

From: Sergei Trofimovich Before the change gcc did not stream correctly TOPN counters if counters belonged to a non-local shared object. As a result zero-section optimization generated TOPN sections in a form not recognizable by '__gcov_merge_topn'. The problem happens because in a case

Re: [PATCH] gcov: fix TOPN streaming from shared libraries

On Mon, 21 Sep 2020 20:38:07 +0300 (MSK) Alexander Monakov wrote: > On Mon, 21 Sep 2020, Martin Liška wrote: > > > On 9/6/20 1:24 PM, Sergei Trofimovich wrote: > > > From: Sergei Trofimovich > > > > > > Before the change gcc did not stream correctly T

Re: [PATCH] -fprofile-reproducible: fix option value handling

On Mon, 14 Sep 2020 09:34:08 +0200 Richard Biener wrote: > On Fri, Sep 11, 2020 at 11:56 PM Sergei Trofimovich via Gcc-patches > wrote: > > > > From: Sergei Trofimovich > > > > Before the change option handling did not accept an argument: > > xgcc: er

[PATCH] doc: use @code{} instead of @samp{@command{}} around 'date %s'

From: Sergei Trofimovich Before the change 'man gcc' rendered "SOURCE_DATE_EPOCH" section as: ... the output of @command{date +%s} on GNU/Linux ... After the change it renders as: ... the output of "date +%s" on GNU/Linux ... gcc/ChangeLog: * doc/cp

[PATCH] doc: fix spelling of -fprofile-reproducibility

From: Sergei Trofimovich gcc/ChangeLog: * doc/invoke.texi: fix '-fprofile-reproducibility' option spelling in maunal. --- gcc/doc/invoke.texi | 9 + 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi index bca8c856dc8

[PATCH] -fprofile-reproducible: fix option value handling

From: Sergei Trofimovich Before the change option handling did not accept an argument: xgcc: error: unknown profile reproducibility method '=serial' xgcc: note: valid arguments to '-fprofile-reproducible' are: multithreaded parallel-runs serial; did you mean 'serial'? The change also

[PATCH] gcov: fix TOPN streaming from shared libraries

From: Sergei Trofimovich Before the change gcc did not stream correctly TOPN counters if counters belonged to a non-local shared object. As a result zero-section optimization generated TOPN sections in a form not recognizable by '__gcov_merge_topn'. The problem happens because in a case

[PATCH] profile: clarify comment around histogram format

From: Sergei Trofimovich gcc/ChangeLog: * gcc/profile.c (sort_hist_values): Clarify hist format: start with a value, not counter. --- gcc/profile.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/gcc/profile.c b/gcc/profile.c index f5c206813c7..fe8963cc9e9

[PATCH] var-tracking: fix uninitialised use of 'in_pending' [PR96404]

From: Sergei Trofimovich r11-2447-g:1212cfad093 ("Improve var-tracking dataflow iteration order") changed 'in_pending' initialization from: in_pending = sbitmap_alloc (last_basic_block_for_fn (cfun)); bitmap_ones (in_pending); to more complex partial bit population algo

Re: [PATCH] ipa/96291: don't crash on unoptimized lto functions

On Mon, 27 Jul 2020 14:41:14 +0200 Martin Jambor wrote: > Hi, > > On Mon, Jul 27 2020, Richard Biener via Gcc-patches wrote: > > On Sat, Jul 25, 2020 at 8:35 PM Sergei Trofimovich via Gcc-patches > > wrote: > >> > >> From: Sergei Trofimovich >

[PATCH v2] ipa/96291: don't crash on unoptimized lto functions

From: Sergei Trofimovich In PR ipa/96291 the test contained an SCC with one unoptimized function. This tricked ipa-cp into NULL dereference. has_undead_caller_from_outside_scc_p() did not take into account that unoptimized funtions don't have IPA summary analysis. And dereferenced NULL pointer

[PATCH] ipa/96291: don't crash on unoptimized lto functions

From: Sergei Trofimovich In PR ipa/96291 the test contained an SCC with one unoptimized function. This tricked ipa-cp into NULL dereference. has_undead_caller_from_outside_scc_p() did not take into account that unoptimized funtions don't have IPA summary analysis. and dereferenced NULL pointer

Re: [PATCH v2] sparc/sparc64: use crtendS.o for default-pie executables [PR96190]

On Fri, 17 Jul 2020 10:19:41 +0200 Eric Botcazou wrote: > > Oh! Sent out v3 with tweaked description as > > https://gcc.gnu.org/pipermail/gcc-patches/2020-July/550168.html > > Thanks. > > > I don't have a push access to gcc tree. Should I request one via > >

Re: [PATCH v2] sparc/sparc64: use crtendS.o for default-pie executables [PR96190]

On Wed, 15 Jul 2020 13:46:12 +0200 Eric Botcazou wrote: > > This should be: > > > > PR target/96190 > > * config/sparc/linux.h (ENDFILE_SPEC): Use GNU_USER_TARGET_ENDFILE_SPEC > > to get crtendS.o for !no-pie mode. > > * config/sparc/linux64.h(ENDFILE_SPEC): Ditto. > >

[PATCH v3] sparc/sparc64: use crtendS.o for default-pie executables [PR96190]

From: Sergei Trofimovich In --enable-default-pie mode compiler should switch from using crtend.o to crtendS.o. On sparc it is especially important because crtend.o contains PIC-unfriendly code. We use GNU_USER_TARGET_ENDFILE_SPEC as a baseline spec to get crtendS.o instead of crtend.o

[PATCH v2] sparc/sparc64: use crtendS.o for default-pie executables [PR96190]

From: Sergei Trofimovich In --enable-default-pie mode compiler should switch from using crtend.o to crtendS.o. On sparc it is especially important because crtend.o contains PIC-unfriendly code. We use GNU_USER_TARGET_ENDFILE_SPEC as a baseline spec to get crtendS.o instead of crtend.o

[PATCH] sparc/sparc64: use PIE_SPEC to select crtendS.o [PR96190]

From: Sergei Trofimovich In --enable-default-pie mode compiler should switch from using crtend.o to crtendS.o. On sparc it is especially visible because crtend.o contains PIC-unfriendly code. gcc: 2020-07-14 Sergei Trofimovich PR driver/96190 * config/sparc/linux.h: Use

[OBSOLETE][PATCH] PR preprocessor/94657: use $AR, not 'ar',

On Thu, 7 May 2020 08:18:31 +0100 Sergei Trofimovich via Gcc-patches wrote: > On Wed, 22 Apr 2020 23:05:38 +0100 > Sergei Trofimovich wrote: > > > From: Sergei Trofimovich > > > > On system with 'ar' and '${CHOST}-ar' the latter is preferred. > >

Re: [PATCH] PR preprocessor/94657: use $AR, not 'ar',

On Wed, 22 Apr 2020 23:05:38 +0100 Sergei Trofimovich wrote: > From: Sergei Trofimovich > > On system with 'ar' and '${CHOST}-ar' the latter is preferred. > as it might not match default 'ar'. > > Bug is initially reported downstream as https://bugs.gentoo.org/718004. >

[PATCH] PR preprocessor/94657: use $AR, not 'ar',

From: Sergei Trofimovich On system with 'ar' and '${CHOST}-ar' the latter is preferred. as it might not match default 'ar'. Bug is initially reported downstream as https://bugs.gentoo.org/718004. libcpp/ChangeLog: PR libcpp/94657 * Makefile.in: use @AR@ placeholder

Re: './configure --disable-multilib' and 'gcc -print-multi-os-directory' interaction

On Sat, 28 Mar 2020 11:35:36 +0100 Andreas Schwab wrote: > On Mär 28 2020, Sergei Trofimovich via Gcc wrote: > > > x86_64-linux-musl targets do not support multilib layout as-is > > and usually expects libdir=lib. glibc target usually uses libdir=lib64. > > If x

'./configure --disable-multilib' and 'gcc -print-multi-os-directory' interaction

x86_64-linux-musl targets do not support multilib layout as-is and usually expects libdir=lib. glibc target usually uses libdir=lib64. In https://bugs.gentoo.org/675954 (also touched on https://gcc.gnu.org/PR90077) Gentoo discovered the following discrepancy when gcc is built with

Re: -static-pie does not seem to work on alpha, hppa, m68k, sparc

On Thu, 26 Mar 2020 22:43:37 + Joseph Myers wrote: > On Thu, 26 Mar 2020, Sergei Trofimovich via Gcc wrote: > > > Hi all! > > > > Recently I attempted to build glibc-2.31 with --enable-static-pie > > (gcc-9.3.0). > > Some targets work just fine,

-static-pie does not seem to work on alpha, hppa, m68k, sparc

Hi all! Recently I attempted to build glibc-2.31 with --enable-static-pie (gcc-9.3.0). Some targets work just fine, some don't. A few faulty ones so far are: - alpha-unknown-linux-gnu - hppa-unknown-linux-gnu - hppa2.0-unknown-linux-gnu - m68k-unknown-linux-gnu - sparc-unknown-linux-gnu -

musl, glibc and ideal place for __stack_chk_fail_local

[ sending it to musl, glibc and gcc devel mailing list as we need to build a consensus across the projects ] To support smash stack protection gcc emits __stack_chk_fail calls on all targets. On top of that gcc emits __stack_chk_fail_local calls at least on i386 and powerpc:

Re: [PATCH] asan_test.C: disable -Wstringop-overflow, PR/93058

On Fri, 24 Jan 2020 22:20:43 +0100 Jakub Jelinek wrote: > On Fri, Jan 24, 2020 at 07:57:22AM +, slyfox.inbox.ru via gcc-patches > wrote: > > From: Sergei Trofimovich > > > > From: Sergei Trofimovich > > > > asan's test allocates 2 pages via pvalloc

Re: [PATCH v2] libgcc: m68k: avoid TEXTRELs in shared library (PR 86224)

On Mon, 17 Sep 2018 15:29:08 -0600 Jeff Law wrote: > On 9/17/18 3:18 PM, Sergei Trofimovich wrote: > > On Sat, 28 Jul 2018 20:42:02 +0100 > > "slyfox.inbox.ru via gcc-patches" wrote: > > > >> From: Sergei Trofimovich > >> > >> Cc: Ia

Re: [PATCH v2] libgcc: m68k: avoid TEXTRELs in shared library (PR 86224)

On Sat, 28 Jul 2018 20:42:02 +0100 "slyfox.inbox.ru via gcc-patches" wrote: > From: Sergei Trofimovich > > Cc: Ian Lance Taylor > Cc: Jeff Law > Cc: Andreas Schwab > Signed-off-by: Sergei Trofimovich > --- > libgcc/config/m68k/lb1sf68.S | 3 +++ > 1 fi

Re: [PATCH] libgcc: m68k: avoid TEXTRELs in shared library (PR 86224)

On Sat, 28 Jul 2018 21:11:22 -0400 Rich Felker wrote: > On Sat, Jul 28, 2018 at 08:47:33PM +0200, Andreas Schwab wrote: > > On Jul 28 2018, sly...@inbox.ru wrote: > > > > > From: Sergei Trofimovich > > > > > > Cc: Ian Lance Taylor > > > C

[PATCH] gcc/configure.ac: add --disable-systemtap switch

From: Sergei Trofimovich <sly...@gentoo.org> Before the change systemtap probes were enabled if target headers had sys/sdt.h at ./configure time. After the change explicitly ask to enable or disable for probe support and not rely on automagic dependency discovery. Bug: https://bugs.gent

[PING from 2013][PATCH] fixincludes: handle symlinks with multiple slashes

Looks like the following patch falled through the cracks https://gcc.gnu.org/ml/gcc-patches/2012-12/msg01397.html https://bugs.gentoo.org/show_bug.cgi?id=434180#c16 Thanks! -- Sergei pgpUpEUwrmHQi.pgp Description: Цифровая подпись OpenPGP

Re: [PATCH] x86_64: fix 'gather' avx2 builtin names

On Sun, 25 Sep 2016 19:01:14 +0200 Jakub Jelinek <ja...@redhat.com> wrote: > On Sun, Sep 25, 2016 at 02:48:19PM +0100, Sergei Trofimovich wrote: > > From: Sergei Trofimovich <siarh...@google.com> > > > > Today I traced AVX2 optimisation bug

[PATCH] x86_64: fix 'gather' avx2 builtin names

From: Sergei Trofimovich <siarh...@google.com> Today I traced AVX2 optimisation bug in gcc and distilled it down to '__builtin_ia32_gatheraltdiv4si256' generated by gcc. When I attempted to use this builtin directly in a simple program gcc refused to recognise it as known: #include

Re: [PATCH v2] ia64: don't use dynamic relocations for local symbols

On Sat, 2 Jan 2016 11:50:56 + Sergei Trofimovich <sly...@inbox.ru> wrote: > Attached updated patch and test runs on a crosscompiler before > and after the change. > > Now I'm building on real ia64 hardware as > make bootstrap > make -k check > > fo

Re: [PATCH v2] ia64: don't use dynamic relocations for local symbols

On Tue, 5 Jan 2016 10:41:14 -0700 Jeff Law wrote: > On 01/05/2016 02:39 AM, Eric Botcazou wrote: > >> 'make bootstrap' works fine on ia64 but I've failed to run 'make check'. > >> Testsuite's LD_LIBRARY_PATHs are not correct and can run tests. > > > > You need to run 'make -k

[PATCH v2] ia64: don't use dynamic relocations for local symbols

as make bootstrap make -k check for both clean and patched trees. -- Sergei From 04a34fd97cffae4f40e1c226489129f42f3ceb2a Mon Sep 17 00:00:00 2001 From: Sergei Trofimovich <siarh...@google.com> Date: Mon, 28 Dec 2015 17:33:43 + Subject: [PATCH] ia64: don't use dynamic reloc

Re: IA64: short data segment overflowed issue

On Thu, 20 Jan 2011 17:27:14 -0800 Richard Henderson <r...@redhat.com> wrote: > On 01/20/2011 01:26 PM, Sergei Trofimovich wrote: > > So I would like to have "large data segment" feature! > > Can you elaborate what exactly needs to be implemented? > >

[PATCH] ia64: don't use dynamic relocations for local symbols

From: Sergei Trofimovich <siarh...@google.com> Tested on the following example: void * a[77] __attribute((visibility("hidden"))); void f(long o, void * v) { a[0x6eff - o + 66] = v; } Before the patch generated code uses .GOT entry: addl r14 = @ltoffx(a#), r1

Re: Are we fast yet?

* Unfortunately Callgrind doesn't save the full stack trace so what you see is a statistical breakdown for callees. It doesn't necessarily mean that a call path displayed actually exists deeper than its first level. But the numbers add-up so this is minor. You might give a try to

Re: 'The GNU Compiler for the JavaTM Programming Language' translation

And either Google Translate is very very good at Belarusian, or the pages this guy translates have just been piped through Google Translate. They're identical. And I'm afraid worthless. Can you show me a link? I'm kinda Belarusian native speaker. blog format is a bit suspicious to maintain

Re: 'The GNU Compiler for the JavaTM Programming Language' translation

On Thu, 5 May 2011 16:28:34 +0100 Jonathan Wakely jwakely@gmail.com wrote: On 5 May 2011 16:08, Sergei Trofimovich sly...@gmail.com wrote: And either Google Translate is very very good at Belarusian, or the pages this guy translates have just been piped through Google Translate

Re: IA64: short data segment overflowed issue

On Thu, 20 Jan 2011 17:27:14 -0800 Richard Henderson r...@redhat.com wrote: Depending on how Haskell programs are built, it may be better to avoid the GOT entirely. E.g. -mcmodel=large a-la the x86_64 port. This generates full 64-bit absolute relocations. For ia64 code this would

Re: IA64: short data segment overflowed issue

On Thu, 06 Jan 2011 09:47:49 -0800 Richard Henderson r...@redhat.com wrote: On 01/06/2011 01:17 AM, Karel Gardas wrote: BTW: This is on GCC Compile Farm IA64 machine. Now my question is: how to solve this issue? Does GCC already support something Intel discusses in 2008 here:

[resend][stl] std::vector::data - nonstandard method.

Hi, today i've occasionally wrote importable code :] std::vector::data() is absent in some other (standard conformant?) STLs. Would be a good idea to rename data() or change specifier (- protected?). g++ -v: Using built-in specs. Target: x86_64-pc-linux-gnu Configured with:

[mudflap] __mf_strlen + nl_langinfo false positive

Sample session: (sources are below) $ make g++ main.o -g -O0 -fmudflapth -lmudflapth -pthread -o bug $ LANG=C ./bug *** mudflap violation 1 (check/read): time=1225460499.358020 ptr=0x7fe182d90300 size=15 pc=0x7fe183996779 location=`(strlen region)'