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

2023-10-05 Thread Sergei Trofimovich via Gcc
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

2023-10-05 Thread Sergei Trofimovich via Gcc
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

2023-10-04 Thread Sergei Trofimovich via Gcc
o you think? Thanks! -- 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__

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

2020-03-28 Thread Sergei Trofimovich via Gcc
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

2020-03-28 Thread Sergei Trofimovich via Gcc
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 --disable-multi

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

2020-03-26 Thread Sergei Trofimovich via Gcc
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, some

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

2020-03-26 Thread Sergei Trofimovich via Gcc
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 - sparc64

musl, glibc and ideal place for __stack_chk_fail_local

2020-01-25 Thread Sergei Trofimovich
[ 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: https://bugs.gen

Re: RFC: Support non-standard extension (call via casted function pointer)

2016-03-13 Thread Sergei Trofimovich
On Thu, 28 Jan 2016 19:10:03 +0100 Andreas Schwab wrote: > Why does the dummy declaration need to use a pointer type? Just a historical remnant. Historically it was a single declaration used for both "known" prototypes (for functions generated by GHC) and "unknown" prototypes (arbitrary C funct

Re: IA64: short data segment overflowed issue

2015-12-30 Thread Sergei Trofimovich
On Thu, 20 Jan 2011 17:27:14 -0800 Richard Henderson 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? > > > > From what I see: &

Re: Are we fast yet?

2012-07-01 Thread Sergei Trofimovich
> * 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 --num-c

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

2011-05-05 Thread Sergei Trofimovich
On Thu, 5 May 2011 16:28:34 +0100 Jonathan Wakely wrote: > On 5 May 2011 16:08, Sergei Trofimovich 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: 'The GNU Compiler for the JavaTM Programming Language' translation

2011-05-05 Thread Sergei Trofimovich
> 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: IA64: short data segment overflowed issue

2011-01-22 Thread Sergei Trofimovich
On Thu, 20 Jan 2011 17:27:14 -0800 Richard Henderson 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 look like >

Re: IA64: short data segment overflowed issue

2011-01-20 Thread Sergei Trofimovich
On Thu, 06 Jan 2011 09:47:49 -0800 Richard Henderson 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: > > http://software.in