Re: New x86-64 micro-architecture levels

[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 that is dropped).  bdver4 and znver1 (and later) should land in
Level C.

>>  My only concerns are
>>
>> 1. Names like “x86-100”, “x86-101”, what features do they support?
>
> Indeed I didn't get the -100, -101 part.  On the GCC side I'd have
> suggested -march=generic-{A,B,C,D} implying the respective
> -mtune.

With literal A, B, C, D, or are they just placeholders?  If not literal
levels, then what we should use there?

I like the simplicity of numbers.  I used letters in the proposal to
avoid confusion if we alter the proposal by dropping or levels, shifting
the meaning of those that come later.  I expect to switch back to
numbers again for the final version.

> Do the patches end up annotating ELF binaries with the architecture
> level and does ld.so check that info?

This is a separate feature that H.J. has been working on.

> For example IIRC there's a penalty to switch between VEX and
> not VEX encoded instructions so even on AVX capable hardware
> it might be profitable to use non-AVX libraries if the program is
> using only architecture level A?

But this is impossible to know in general.  It may also be possible that
the library contains an inner loop that can be nicely vectorized with
AVX instructions, but not with SSE4.2 instructions and earlier.  Then
preferring the non-AVX version would be a mistake.

Regarding the transition penalty, I believe this is mostly addressed by
those VZEROUPPER instructions?  I've already explained why I think those
aren't a viable optimization target, given the current calling
convention.

My glibc patches already provide a way to mask subdirectories which
would otherwise be selected, so manual optimization is still possible.

> On that side, does architecture level B+ suggest using VEX encoding
> everywhere?  It would be indeed nice to have the architecture levels
> documented in the psABI.

I think this falls under optimization, and I really did not want to
discuss.

If there is a plan to change/amend the calling convention and some of
the levels should prefer to that, it's a different matter, of course.
(glibc can only give you four callee-saved 256-bit wide registers
easily, though, more would need close cooperation with GCC.)

The new glibc-hwcaps scheme in glibc scales a bit better than the old
one, so we do not have to settle this immediately and could add
additional subdirectories for objects that follow new calling convention
requirements.

>> 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
GNU_PROPERTY_X86_ISA_1_NEEDED would convey this information.  This
proposal and the glibc patches are independent of that.

If that function ever gets deployed, I plan to add those notes to
ld.so.cache, so that ld.so can select shared objects based on them (or
any allocated ELF note, really).  Efficient LD_LIBRARY_PATH support is
not possible, I think, so those designated glibc-hwcaps subdirectories
still have a place.

Thanks,
Florian

Re: New x86-64 micro-architecture levels

[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
> GNU_PROPERTY_X86_ISA_1_NEEDED would convey this information.  This
> proposal and the glibc patches are independent of that.

>From (partly just halfway) recent discussions with H.J. I gained
the understanding that the piece we're aiming at getting to work
properly is the recording of GNU_PROPERTY_X86_FEATURE_2_*, not
so much GNU_PROPERTY_X86_ISA_1_*. If the ISA one is to be used as
a basis here, a lot of new flags will need adding (and properly
setting) first, I think.

Jan

Re: New x86-64 micro-architecture levels

[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
>> generations of Intel Atom server CPUs (although I haven't tested the
>> latest version).  A 32-bit variant would have to list many additional
>> CPU features here.
>
> FWIW, this is also the limit of what can be run under QEMU emulation, as 
> QEMU lacks support for AVX and newer instruction set features.

Oh, I had forgotten about.  I should have Cc:ed the QEMU folks as well.
We'll need to make sure that we have matching CPU models in
QEMU/libvirt, even for the levels that do not have TCG support.

valgrind is another consumer, but in my tests, it was mostly okay with
AVX2 code (but that was without auto-vectorization).  AVX-512 is a
different matter, but that is also much further out.

> On the other hand, virtual machines seem liable to report something closer 
> to the K8 baseline to the guest OS, missing the level A features, even 
> when the underlying hardware supports everything in level B or level C.

They do this to support migration.  I'm suspect that in many cases,
those are just configuration errors.  That's why I want at least one
major distribution to switch to Level C as the baseline, to clean the
pipes.  Then even those distributions that depend on run-time selection
for performance-critical code will benefit. 8-/

Thanks,
Florian

Re: New x86-64 micro-architecture levels

[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?
>
> bdver1 to bdver3 (as defined by GCC) should land in Level B (so Level A
> if that is dropped).  bdver4 and znver1 (and later) should land in
> Level C.
>
> >>  My only concerns are
> >>
> >> 1. Names like “x86-100”, “x86-101”, what features do they support?
> >
> > Indeed I didn't get the -100, -101 part.  On the GCC side I'd have
> > suggested -march=generic-{A,B,C,D} implying the respective
> > -mtune.
>
> With literal A, B, C, D, or are they just placeholders?  If not literal
> levels, then what we should use there?
>
> I like the simplicity of numbers.  I used letters in the proposal to
> avoid confusion if we alter the proposal by dropping or levels, shifting
> the meaning of those that come later.  I expect to switch back to
> numbers again for the final version.

They are indeed placeholders though I somehow prefer letters to
numbers.  But this is really bike-shedding territory.  Good documentation
on the tools side will be more imporant as well as consistent spelling
between tools sets, possibly driven by a good choice from within the
psABI document.

Richard.

Re: SRA argument after materialization

[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 removed
as constant or unused by IPA-CP), look into the corresponding
cgraph_node->clone.param_adjustments.

(Assuming you want to do it programmatically, if you're just debugging
stuff, the IPA-SRA dump is probably the place to look at.)

Martin

Re: SRA argument after materialization

[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 by IPA-SRA (but also to spot arguments removed
as constant or unused by IPA-CP), look into the corresponding
cgraph_node->clone.param_adjustments.

(Assuming you want to do it programmatically, if you're just debugging
stuff, the IPA-SRA dump is probably the place to look at.)

Martin



Doing it programmatically. Thanks Martin!

Re: Question about indirect functions and PGO

[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 specialization 
during LTO. If a callsite is not in a hot basic block, it seems that the 
callsite will not be specialized for a particular parameter.
2. --param=ipa-cp-eval-threshold=. This option controls a heuristic that 
lets constant propagation happen if a function is a good candidate for 
cloning. This parameter is used for both: function specialization within 
a particular context and for all contexts.


On 10/07/2020 13:19, Erick Ochoa wrote:
Forgot to mention that these functions take a function pointer as a 
parameter and as a result, the specialized functions are able to replace 
the indirect function call with a direct function call.


On 10/07/2020 13:17, Erick Ochoa wrote:

Hello,

I'm working on an optimization and I encountered this interesting 
behaviour. There are a couple of functions that are specialized when 
the program is not compiled with PGO (-fprofile-generate and 
-fprofile-use)


However, when the program is compiled with PGO the compiler does not 
specialize the function calls.


I printing the program just after materializing all clones.

I am running this version of GCC:
Author: GCC Administrator 
Date:   Fri Jul 10 00:16:28 2020 +

 Daily bump.

I can imagine that the profiling information was used to determine 
that specializing these functions is a bad tradeoff between binary 
size and speed. But I do not know this for sure. How can I find out 
why these functions were not specialized? (I.e. is there a threshold 
that wasn't met, and if so, where is it located and what's its value?)


Thanks!

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

[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:

  

Thanks,
Florian

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

[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 choice.

I posted a patch:

   



Thanks, Florian!

Bill



Thanks,
Florian

Re: New x86-64 micro-architecture levels

[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 think we can add more diagnostic output to ld.so --help.  My patch
> does not show individual CPU flags, but I agree this could be useful.
> (It's not needed for the legacy HWCAP subdirectories because in general,
> those are named & defined by the kernel, not by individually named CPU
> feature flags.)
>
> > 2. I have a library with AVX2 and FMA, which directory should it go?
> >
> > Can we pass such info to ld.so and ld.so prints out the best directory
> > name?
>
> I think this would require generating matching GNU property notes (list
> the CPU features required by the binary).  Once we have that, we can add

I have turned on -mx86-used-note=yes by default for binutils 2.36.
I will add more ISAs bits after we determine which ISAs will be used.
But compilers need to generate GNU_PROPERTY_X86_ISA_1_NEEDED
property.

> something to binutils or indeed ld.so to analyze them and print the
> recommended directory.  But I think this is something that could come
> later.
>
> We can also write a GCC header which looks at macros such as __AVX2__
> and prints a #warning with the recommended directory name.  Checking for
> excess flags will be tricky in this context, though, and if we miss
> something, a wrong recommendation will be the result.
>
> Thanks,
> Florian


-- 
H.J.

Re: New x86-64 micro-architecture levels

[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 applicable?
> >
> > 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) recent discussions with H.J. I gained
> the understanding that the piece we're aiming at getting to work
> properly is the recording of GNU_PROPERTY_X86_FEATURE_2_*, not
> so much GNU_PROPERTY_X86_ISA_1_*. If the ISA one is to be used as
> a basis here, a lot of new flags will need adding (and properly
> setting) first, I think.
>

We can update GNU_PROPERTY_X86_ISA_1_* as needed.

-- 
H.J.

Re: New x86-64 micro-architecture levels

[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) recent discussions with H.J. I gained
> > the understanding that the piece we're aiming at getting to work
> > properly is the recording of GNU_PROPERTY_X86_FEATURE_2_*, not
> > so much GNU_PROPERTY_X86_ISA_1_*. If the ISA one is to be used as
> > a basis here, a lot of new flags will need adding (and properly
> > setting) first, I think.
> >
> 
> We can update GNU_PROPERTY_X86_ISA_1_* as needed.

I am not really sure such properties are a good idea, it will be a
maintainability nightmare (as it is on other OSes like Solaris).
Think about function multiversioning, target attribute for just some
functions, #pragma omp declare simd.  How do you differentiate between
using those on carefully written code that handles cpuid detection itself or
uses compiler support for that, where we do not want to mark the objects in
any way, they should work just fine even on K8, and cases where users want
something like that?

E.g. look for -mclear-hwcap stuff needed for Solaris because of that.

Jakub

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

[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.

remote: *** ChangeLog format failed:
remote: ERR: ChangeLog, DATESTAMP, BASE-VER and DEV-PHASE updates should 
be done separately from normal commits

remote:
remote: Please see: https://gcc.gnu.org/codingconventions.html#ChangeLogs
remote:
remote: error: hook declined to update refs/heads/releases/gcc-10
To git+ssh://gcc.gnu.org/git/gcc.git

Thanks
Martin

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

[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 the link it points to than what it says.

remote: *** ChangeLog format failed:
remote: ERR: ChangeLog, DATESTAMP, BASE-VER and DEV-PHASE updates should 
be done separately from normal commits

remote:
remote: Please see: https://gcc.gnu.org/codingconventions.html#ChangeLogs
remote:
remote: error: hook declined to update refs/heads/releases/gcc-10
To git+ssh://gcc.gnu.org/git/gcc.git


The cause of the error turned out to be that for some reason,
after a rebase, the diff I was trying to push also contained
upstream ChangeLog updates that I didn't scroll far enough in
the commit log to see.

I don't know if this happens often enough to make improving
the error worthwhile or if it was just my luck that I did
something silly this time, but mentioning the pathnames of
the changed ChangeLog, DATESTAMP, BASE-VER, and DEV-PHASE
files in the error message  found in the commit would help
avoid the confusion. E.g., something like:

  remote: Error: found one or more ChangeLog, DATESTAMP,
  BASE-VER or DEV-PHASE files in commit:
...list of pathnames of files...
  Updates to these files should be made separately from those
  to ordinary files.

Martin

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

[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 the argument, that means 
all the processing of that option is expected to be done in the option 
handler.  In this case, riscv_handle_option has an OPT_march_: case.  
Code running later in the compiler is then expected to get whatever 
information it needs from wherever riscv_handle_option (which calls 
riscv_parse_arch_string) stored the results of its processing.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: gcc-backport problem on Debian 9

[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
>  9 files changed, 276 insertions(+), 1 deletion(-)
>  create mode 100644 gcc/testsuite/gcc.dg/pr94600-1.c
>  create mode 100644 gcc/testsuite/gcc.dg/pr94600-2.c
>  create mode 100644 gcc/testsuite/gcc.dg/pr94600-3.c
>  create mode 100644 gcc/testsuite/gcc.dg/pr94600-4.c
>  create mode 100644 gcc/testsuite/gcc.dg/pr94600-5.c
>  create mode 100644 gcc/testsuite/gcc.dg/pr94600-6.c
>  create mode 100644 gcc/testsuite/gcc.dg/pr94600-7.c
>  create mode 100644 gcc/testsuite/gcc.dg/pr94600-8.c
> Traceback (most recent call last):
>   File "/mnt/storage1/hp/autotest/gccgit/gcc/contrib/git-
> backport.py", line 34, in 
> changelogs = subprocess.check_output(cmd, shell=True,
> encoding='utf8')
>   File "/usr/lib/python3.5/subprocess.py", line 316, in check_output
> **kwargs).stdout
>   File "/usr/lib/python3.5/subprocess.py", line 383, in run
> with Popen(*popenargs, **kwargs) as process:
> TypeError: __init__() got an unexpected keyword argument 'encoding'

This is subprocess.Popen.__init__, which is part of the Python standard
library.

https://docs.python.org/3.6/library/subprocess.html#popen-constructor
states:
  "New in version 3.6: 'encoding' and 'errors' were added."

Hence it looks like git-backport.py is implicitly assuming Python 3.6
or later.


> The commit looked fine with a "(cherry picked from commit
> a4aca1edaf37d43b2b7e9111825837a7a317b1b0)", appended to the
> commit log, so I pushed it successfully (using git am on the
> format-patch of this commit on another machine, so the sha above
> is not the final one, but 6f49c66ed4e060c333d8bcd).
> 
> Not sure what other information is needed, but maybe:
> 
> $ dpkg -s python3
> Package: python3
> Status: install ok installed
> Priority: optional
> Section: python
> Installed-Size: 67
> Maintainer: Matthias Klose 
> Architecture: amd64
> Multi-Arch: allowed
> Source: python3-defaults
> Version: 3.5.3-1
> Replaces: python3-minimal (<< 3.1.2-2)
> Provides: python3-profiler
> Depends: python3.5 (>= 3.5.3-1~), libpython3-stdlib (= 3.5.3-1), dh-
> python
> Pre-Depends: python3-minimal (= 3.5.3-1)
> Suggests: python3-doc (>= 3.5.3-1), python3-tk (>= 3.5.3-1~),
> python3-venv (>= 3.5.3-1)
> Description: interactive high-level object-oriented language (default
> python3 version)
>  Python, the high-level, interactive object oriented language,
>  includes an extensive class library with lots of goodies for
>  network programming, system administration, sounds and graphics.
>  .
>  This package is a dependency package, which depends on Debian's
> default
>  Python 3 version (currently v3.5).
> Homepage: http://www.python.org/
> 
> FWIW, I manually did "apt-get install python3-unidiff" and
> "apt-get install python3-dateutil" to deal with missing packages
> in other related scripts.  Perhaps this is a different
> incantation.  Are the dependencies listed somewhere?
> 
> brgds, H-P
> 

Re: Question about indirect functions and PGO

[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
> threshold of basic blocks and is needed for function specialization
> during LTO. If a callsite is not in a hot basic block, it seems that the
> callsite will not be specialized for a particular parameter.
> 2. --param=ipa-cp-eval-threshold=. This option controls a heuristic that
> lets constant propagation happen if a function is a good candidate for
> cloning. This parameter is used for both: function specialization within
> a particular context and for all contexts.
>
> On 10/07/2020 13:19, Erick Ochoa wrote:
> > Forgot to mention that these functions take a function pointer as a
> > parameter and as a result, the specialized functions are able to replace
> > the indirect function call with a direct function call.
> >
> > On 10/07/2020 13:17, Erick Ochoa wrote:
> >> Hello,
> >>
> >> I'm working on an optimization and I encountered this interesting
> >> behaviour. There are a couple of functions that are specialized when
> >> the program is not compiled with PGO (-fprofile-generate and
> >> -fprofile-use)
> >>
> >> However, when the program is compiled with PGO the compiler does not
> >> specialize the function calls.
> >>
> >> I printing the program just after materializing all clones.
> >>
> >> I am running this version of GCC:
> >> Author: GCC Administrator 
> >> Date:   Fri Jul 10 00:16:28 2020 +
> >>
> >>  Daily bump.
> >>
> >> I can imagine that the profiling information was used to determine
> >> that specializing these functions is a bad tradeoff between binary
> >> size and speed. But I do not know this for sure. How can I find out
> >> why these functions were not specialized? (I.e. is there a threshold
> >> that wasn't met, and if so, where is it located and what's its value?)
> >>

Have you tried the new option-fprofile-partial-training ?

-fprofile-partial-training can now be used to inform the compiler that
code paths not covered by the training run should not be optimized for
size.

I tested by myself this week and it literally do not optimize at all
the functions not touched by the training

Regards

Victor Rodriguez

> >> Thanks!

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

[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 `libgcc.a' objects.  This is because those 
objects pull in the exception unwinder; specifically `__divdi3', 
`__moddi3', and `__umoddi3' all include a call to `_Unwind_Resume' each.

 Arguably this might probably be called a deficiency in libgcc, however 
the objects are built with `-fexceptions -fnon-call-exceptions' and at 
`-O0' GCC might not be able to see through code that no exception may 
happen there.  Therefore I am not sure offhand if this needs to be 
considered a GCC or glibc bug.

  Maciej

.../bin/../lib/gcc/riscv64-linux-gnu/10.0.1/../../../../riscv64-linux-gnu/bin/ld:
 .../obj/glibc-boot/ilp32/elf/librtld.os: in function 
`init_dwarf_reg_size_table':
.../src/gcc/libgcc/unwind-dw2.c:1572: undefined reference to `malloc'
.../bin/../lib/gcc/riscv64-linux-gnu/10.0.1/../../../../riscv64-linux-gnu/bin/ld:
 .../obj/glibc-boot/ilp32/elf/librtld.os: in function `uw_init_context_1':
.../src/gcc/libgcc/unwind-dw2.c:1613: undefined reference to `malloc'
.../bin/../lib/gcc/riscv64-linux-gnu/10.0.1/../../../../riscv64-linux-gnu/bin/ld:
 .../obj/glibc-boot/ilp32/elf/librtld.os: in function `uw_install_context_1':
.../src/gcc/libgcc/unwind-dw2.c:1694: undefined reference to `free'
.../bin/../lib/gcc/riscv64-linux-gnu/10.0.1/../../../../riscv64-linux-gnu/bin/ld:
 .../src/gcc/libgcc/unwind-dw2.c:1711: undefined reference to `free'
.../bin/../lib/gcc/riscv64-linux-gnu/10.0.1/../../../../riscv64-linux-gnu/bin/ld:
 .../obj/glibc-boot/ilp32/elf/librtld.os: in function 
`_Unwind_ForcedUnwind_Phase2':
.../src/gcc/libgcc/unwind.inc:152: undefined reference to `malloc'
.../bin/../lib/gcc/riscv64-linux-gnu/10.0.1/../../../../riscv64-linux-gnu/bin/ld:
 .../src/gcc/libgcc/unwind.inc:163: undefined reference to `malloc'
.../bin/../lib/gcc/riscv64-linux-gnu/10.0.1/../../../../riscv64-linux-gnu/bin/ld:
 .../obj/glibc-boot/ilp32/elf/librtld.os: in function `_Unwind_DeleteException':
.../src/gcc/libgcc/unwind.inc:281: undefined reference to `free'
collect2: error: ld returned 1 exit status
Makefile:554: recipe for target '.../obj/glibc-boot/ilp32/elf/ld.so' failed
make[2]: *** [.../obj/glibc-boot/ilp32/elf/ld.so] Error 1

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

[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.

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

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

[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 sense to build a lowlevel
> runtime library like libgcc with exceptions.

Indeed - you only need to be able to unwind through those, so
-fasynchronous-unwind-tables should be used.

Richard.

> Andreas.
>
> --
> Andreas Schwab, sch...@linux-m68k.org
> GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
> "And now for something completely different."