Re: RISC-V: `ld.so' fails linking against `libgcc.a' built at `-O0'

2020-07-13 Thread Richard Biener via Gcc
On Tue, Jul 14, 2020 at 7:24 AM Andreas Schwab wrote: > > On Jul 14 2020, Maciej W. Rozycki wrote: > > > Arguably this might probably be called a deficiency in libgcc, however > > the objects are built with `-fexceptions -fnon-call-exceptions' > > I consider that broken. It doesn't make any sens

Re: RISC-V: `ld.so' fails linking against `libgcc.a' built at `-O0'

2020-07-13 Thread Andreas Schwab
On Jul 14 2020, Maciej W. Rozycki wrote: > Arguably this might probably be called a deficiency in libgcc, however > the objects are built with `-fexceptions -fnon-call-exceptions' I consider that broken. It doesn't make any sense to build a lowlevel runtime library like libgcc with exceptions.

RISC-V: `ld.so' fails linking against `libgcc.a' built at `-O0' (was: Re: [PATCH] Allow memset local PLT reference for RISC-V.)

2020-07-13 Thread Maciej W. Rozycki via Gcc
On Sun, 12 Jul 2020, Maciej W. Rozycki wrote: > I don't think we have a way to redirect the reference to `__GI_memset'. Additionally, I need to mention that where `libgcc.a' has been built at `-O0', RV32 `ld.so' fails linking due to unresolved `malloc' and `free' references from numerous `lib

Re: Question about indirect functions and PGO

2020-07-13 Thread Victor Rodriguez via Gcc
On Mon, Jul 13, 2020 at 6:41 AM Erick Ochoa wrote: > > Hi, > > I just wanted to answer myself. > It seems that there are two thresholds that need to be met if a function > is to be specialized within a particular context: > > 1. --param=hot-bb-count-ws-permille=. This option controls the hotness >

Re: gcc-backport problem on Debian 9

2020-07-13 Thread David Malcolm via Gcc
On Mon, 2020-07-13 at 08:39 +0200, Hans-Peter Nilsson via Gcc wrote: > Again, Debian 9. Doing "git gcc-backport a4aca1edaf37d43" on > releases/gcc-10 gave me: > > [releases/gcc-10 83cf5a7c6a5] PR94600: fix volatile access to the > whole of a compound object. > Date: Sun Jul 5 20:50:52 2020 +0200

Re: Accessing result data of target options without Mask or Var properties

2020-07-13 Thread Joseph Myers
On Sat, 11 Jul 2020, The Other via Gcc wrote: > Hi, > How would I access the result data of target options that don't have Mask > or Var properties? For example, how would I access the result ISA string in > the -march option for the RISC-V target? If an option doesn't specify somewhere to store

Re: ERR: ChangeLog, DATESTAMP, BASE-VER and DEV-PHASE updates

2020-07-13 Thread Martin Sebor via Gcc
On 7/13/20 8:21 AM, Martin Sebor wrote: Could someone explain what the following error means and how to avoid it?  It's for a commit to the 10 branch with the usual commit message format and changes to only .c/.C files (same as in r11-1899).  There's nothing more about the subject of the ERR at t

ERR: ChangeLog, DATESTAMP, BASE-VER and DEV-PHASE updates

2020-07-13 Thread Martin Sebor via Gcc
Could someone explain what the following error means and how to avoid it? It's for a commit to the 10 branch with the usual commit message format and changes to only .c/.C files (same as in r11-1899). There's nothing more about the subject of the ERR at the link it points to than what it says.

Re: New x86-64 micro-architecture levels

2020-07-13 Thread Jakub Jelinek via Gcc
On Mon, Jul 13, 2020 at 06:31:31AM -0700, H.J. Lu via Gcc wrote: > > > H.J. has patches for ELF program properties. I think > > > GNU_PROPERTY_X86_ISA_1_NEEDED would convey this information. This > > > proposal and the glibc patches are independent of that. > > > > From (partly just halfway) rece

Re: New x86-64 micro-architecture levels

2020-07-13 Thread H.J. Lu via Gcc
On Mon, Jul 13, 2020 at 12:48 AM Jan Beulich wrote: > > On 13.07.2020 09:40, Florian Weimer wrote: > > * Richard Biener: > >>> 2. I have a library with AVX2 and FMA, which directory should it go? > >> > >> Eventually GCC/gas can annotate objects with the lowest architecture > >> level that is appl

Re: New x86-64 micro-architecture levels

2020-07-13 Thread H.J. Lu via Gcc
On Sun, Jul 12, 2020 at 11:49 PM Florian Weimer wrote: > > * H. J. Lu: > > > Looks good. I like it. > > Thanks. What do you think about Level B? Should we keep it? Please drop Level B. > > My only concerns are > > > > 1. Names like “x86-100”, “x86-101”, what features do they support? > > I th

Re: documentation of powerpc64{,le}-linux-gnu as primary platform

2020-07-13 Thread Bill Schmidt via Gcc
On 7/13/20 7:08 AM, Florian Weimer wrote: * Bill Schmidt via Gcc: Matthias, if you want to post a patch for GCC 9 and GCC 10, I'm sure that would be accepted (though I do not have the power to pre-approve it).  Or I can put it on my list for later in the summer when my life settles down.  Your

Re: documentation of powerpc64{,le}-linux-gnu as primary platform

2020-07-13 Thread Florian Weimer via Gcc
* Bill Schmidt via Gcc: > Matthias, if you want to post a patch for GCC 9 and GCC 10, I'm sure > that would be accepted (though I do not have the power to pre-approve > it).  Or I can put it on my list for later in the summer when my life > settles down.  Your choice. I posted a patch:

Re: Question about indirect functions and PGO

2020-07-13 Thread Erick Ochoa
Hi, I just wanted to answer myself. It seems that there are two thresholds that need to be met if a function is to be specialized within a particular context: 1. --param=hot-bb-count-ws-permille=. This option controls the hotness threshold of basic blocks and is needed for function specializa

Re: SRA argument after materialization

2020-07-13 Thread Erick Ochoa
On 13/07/2020 13:13, Martin Jambor wrote: Hi, On Fri, Jul 10 2020, Erick Ochoa wrote: Hello, is there a way to determine just how an argument is affected by SRA after SRA has occured? How would I be able to determine the effects of ISRA on the struct argument? For the changes performed b

Re: SRA argument after materialization

2020-07-13 Thread Martin Jambor
Hi, On Fri, Jul 10 2020, Erick Ochoa wrote: > Hello, > > is there a way to determine just how an argument is affected by SRA > after SRA has occured? > > How would I be able to determine the effects of ISRA on the struct argument? For the changes performed by IPA-SRA (but also to spot arguments

Re: New x86-64 micro-architecture levels

2020-07-13 Thread Richard Biener via Gcc
On Mon, Jul 13, 2020 at 9:40 AM Florian Weimer wrote: > > * Richard Biener: > > >> Looks good. I like it. > > > > Likewise. Btw, did you check that VIA family chips slot into Level A > > at least? > > Those seem to lack SSE4.2, so they land in the baseline. > > > Where do AMD bdverN slot in? > >

Re: New x86-64 micro-architecture levels

2020-07-13 Thread Florian Weimer via Gcc
* Joseph Myers: > On Fri, 10 Jul 2020, Florian Weimer via Gcc wrote: > >> * Level A >> >> CMPXCHG16B, LAHF/SAHF, POPCNT, SSE3, SSE4.1, SSE4.2, SSSE3 >> >> This is one step above the K8 baseline and corresponds to a mainline CPU >> model ca. 2008 to 2011. It is also implemented by recent-ish >>

Re: New x86-64 micro-architecture levels

2020-07-13 Thread Jan Beulich
On 13.07.2020 09:40, Florian Weimer wrote: > * Richard Biener: >>> 2. I have a library with AVX2 and FMA, which directory should it go? >> >> Eventually GCC/gas can annotate objects with the lowest architecture >> level that is applicable? > > H.J. has patches for ELF program properties. I think

Re: New x86-64 micro-architecture levels

2020-07-13 Thread Florian Weimer via Gcc
* Richard Biener: >> Looks good. I like it. > > Likewise. Btw, did you check that VIA family chips slot into Level A > at least? Those seem to lack SSE4.2, so they land in the baseline. > Where do AMD bdverN slot in? bdver1 to bdver3 (as defined by GCC) should land in Level B (so Level A if t