gcc-11-20200712 is now available

[GCC Administrator via Gcc]

Snapshot gcc-11-20200712 is now available on
  https://gcc.gnu.org/pub/gcc/snapshots/11-20200712/
and on various mirrors, see http://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 master 
revision 267891bd3c7ce3e16662eb2be7273f0bc8be9e7e

You'll find:

 gcc-11-20200712.tar.xz   Complete GCC

  SHA256=dc63acbc7b43c0cff7dd0d1bafa00f44f2273d22c3fe901c3cd2c1fd4f4e0941
  SHA1=2ae618ee15e6ac79d665816a217a81e4dc083243

Diffs from 11-20200705 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-11
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

Re: Split generated insn-emit.c

[Jojo R]

Hi，

I consider four ways to implementation it,

and maybe we can use ‘csplit’ tool to split output file, is that right ?

—Jojo
在 2020年7月9日 +0800 PM3:59，Martin Liška ，写道：
> On 7/9/20 9:54 AM, jiejie_r...@c-sky.com wrote:
> > Hi,
> >
> > The size of generated file like insn-emit.c is very huge
> > if we add lots of define_expand patten or define_insn patten.
> >
> > It’s present easily when there are much more intrinsic interfaces
> > it costs much more time to create toolchain with compiling these files :(
>
> Hello.
>
> Yes, that's a know pain we unfortunately have.
>
> >
> > Does anyone have method to split the generated file to small pieces ?
> > Or any hints to modify GCC toolchain creation process ?
>
> I tried to investigate a bit:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84402
>
> Martin
>
> >
> > Thanks,
> >
> > —Jojo

Re: New x86-64 micro-architecture levels

[Richard Biener via Gcc]

On Fri, Jul 10, 2020 at 11:45 PM H.J. Lu via Gcc  wrote:
>
> On Fri, Jul 10, 2020 at 10:30 AM Florian Weimer  wrote:
> >
> > Most Linux distributions still compile against the original x86-64
> > baseline that was based on the AMD K8 (minus the 3DNow! parts, for Intel
> > EM64T compatibility).
> >
> > There has been an attempt to use the existing AT_PLATFORM-based loading
> > mechanism in the glibc dynamic linker to enable a selection of optimized
> > libraries.  But the general selection mechanism in glibc is problematic:
> >
> >   hwcaps subdirectory selection in the dynamic loader
> >   
> >
> > We also have the problem that the glibc version of "haswell" is distinct
> > from GCC's -march=haswell (and presumably other compilers):
> >
> >   Definition of "haswell" platform is inconsistent with GCC
> >   
> >
> > And that the selection criteria are not what people expect:
> >
> >   Epyc and other current AMD CPUs do not select the "haswell" platform
> >   subdirectory
> >   
> >
> > Since the hwcaps-based selection does not work well regardless of
> > architecture (even in cases the kernel provides glibc with data), I
> > worked on a new mechanism that does not have the problems associated
> > with the old mechanism:
> >
> >   [PATCH 00/30] RFC: elf: glibc-hwcaps support
> >   
> >
> > (Don't be concerned that these patches have not been reviewed; we are
> > busy preparing the glibc 2.32 release, and these changes do not alter
> > the glibc ABI itself, so they do not have immediate priority.  I'm
> > fairly confident that a version of these changes will make it into glibc
> > 2.33, and I hope to backport them into Fedora 33, Fedora 32, and Red Hat
> > Enterprise Linux 8.4.  Debian as well, but I have never done anything
> > like it there, so I don't know if the patches will be accepted.)
> >
> > Out of the box, this should work fairly well for IBM POWER and Z, where
> > there is a clear progression of silicon versions (at least on paper
> > —virtualization may blur the picture somewhat).
> >
> > However, for x86, we do not have such a clear progression of
> > micro-architecture versions.  This is not just as a result of the
> > AMD/Intel competition, but also due to ongoing product differentiation
> > within one chip vendor.  I think we need these levels broadly for the
> > following reasons:
> >
> > * Selecting on individual CPU features (similar to the old hwcaps
> >   mechanism) in glibc has scalability issues, particularly for
> >   LD_LIBRARY_PATH processing.
> >
> > * Developers need guidance about useful targets for optimization.  I
> >   think there is value in limiting the choices, in the sense that “if
> >   you are able to test three builds in total, these are the things you
> >   should build”.
> >
> > * glibc and the compilers should align in their definition of the
> >   levels, so that developers can use an -march= option to build for a
> >   particular level that is recognized by glibc.  This is why I think the
> >   description of the levels should go into the psABI supplement.
> >
> > * A preference order for these levels avoids falling back to the K8
> >   baseline if the platform progresses to a new version due to
> >   glibc/kernel/hypervisor/hardware upgrades.
> >
> > I'm including a proposal for the levels below.  I use single letters for
> > them, but I expect that the concrete implementation of this proposal
> > will use names like “x86-100”, “x86-101”, like in the glibc patch
> > referenced above.  (But we can discuss other approaches.)
> >
> > I looked at various machines in the Red Hat labs and talked to Intel and
> > AMD engineers about this, but this concrete proposal is based on my own
> > analysis of the situation.  I excluded CPU features related to
> > cryptography and cache management, including hardware transactional
> > memory, and CPU timing.  I assume that we will see some of these
> > features being disabled by the firmware or the kernel over time.  That
> > would eliminate entire levels from selection, which is not desirable.
> > For cryptographic code, I expect that localized selection of an
> > optimized implementation works because such code tends to be isolated
> > blocks, running for dozens of cycles each time, not something that gets
> > scattered all over the place by the compiler.
> >
> > We previously discussed not emitting VZEROUPPER at later levels, but I
> > don't think this is beneficial because the ABI does not have
> > callee-saved vector registers, so it can only be useful with local
> > functions (or whatever LTO considers local), where there is no ABI
> > impact anyway.
> >
> > I did not include FSGSBASE because the FS base is already available at
> > %fs:0.  Changing the FS base in userspace breaks too much,

gcc-backport problem on Debian 9

[Hans-Peter Nilsson via Gcc]

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'

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: New x86-64 micro-architecture levels

[Florian Weimer via Gcc]

* H. J. Lu:

> Looks good.  I like it.

Thanks.  What do you think about Level B?  Should we keep it?

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

Re: New x86-64 micro-architecture levels

[Florian Weimer via Gcc]

* Allan Sandfeld Jensen:

> On Freitag, 10. Juli 2020 19:30:09 CEST Florian Weimer via Gcc wrote:
>> glibc (or an alternative loader implementation) would search for
>> libraries starting at level D, going back to level A, and finally the
>> baseline implementation in the default library location.
>> 
>> I expect that some distributions will also use these levels to set a
>> baseline for the entire distribution (i.e., everything would be built to
>> level A or maybe even level C), and these libraries would then be
>> installed in the default location.
>> 
>> I'll be glad if I can get any feedback on this proposal.  I plan to turn
>> it into a merge request for the x86-64 psABI document eventually.

> Sounds good, though if I could dream I would also love a partial
> replacement option. So that you could have a generic x86-64 binary
> that only had some AVX2 optimized replacement functions in a
> supplementary library.
>
> Perhaps implemented by marked the library as a partial replacement, so
> the dynamic linker would also load the base or lower libraries except
> for functions already resolved.

I think you can do something like it today, at least from the glibc
dynamic loader perspective.  Programs link against the soname of the
optimized shared object (which can be empty), and that shared object
depends on the object with the fallback implementation.  A special
link-only shared object containing just the ABI under the front soname
(that of the optimized library) would be used via a linker object, so
that it is not possible to accidentally link against the wrong soname.

For non-versioned symbols, this setup has worked since forever.  For
versioned symbols, delegating from the optimized to the unoptimized
library needs at least glibc 2.30, with commit f0b2132b35248c1f4a80
("ld.so: Support moving versioned symbols between sonames [BZ #24741]"),
although some of us have backported this commit into earlier releases.

Where this falls flat is support for LTO and
-fno-semantic-interposition.  Some care is needed to make precisely the
right set of symbols interposable.  But to honest, I'm not sure if this
entire mechanism is a big improvement over function multi-versioning.

Thanks,
Florian