Re: [PATCH] PR target/97250: i386: Add support for x86-64-v2, x86-64-v3, x86-64-v4 levels for x86-64

On 9/30/20 2:27 PM, Florian Weimer wrote: > These micro-architecture levels are defined in the x86-64 psABI: > > https://gitlab.com/x86-psABIs/x86-64-ABI/-/commit/77566eb03bc6a326811cb7e9 > > PTA_NO_TUNE is introduced so that the new processor alias table entries > do not affect the CPU tuning se

Re: [PATCH] data-ref: Tighten index-based alias checks [PR99726]

On Wed, Mar 31, 2021 at 11:15:08AM +0100, Richard Sandiford via Gcc-patches wrote: > gcc/testsuite/ > PR tree-optimization/99726 > * gcc.target/i386/pr99726.c: New test. -m32 shouldn't be used in gcc.target/i386/ testcases, people do test with -m32/-m64 to get 32-bit compilation teste

Re: [PATCH] PR target/97250: i386: Add support for x86-64-v2, x86-64-v3, x86-64-v4 levels for x86-64

On April 2, 2021 10:00:53 AM GMT+02:00, Matthias Klose wrote: >On 9/30/20 2:27 PM, Florian Weimer wrote: >> These micro-architecture levels are defined in the x86-64 psABI: >> >> >https://gitlab.com/x86-psABIs/x86-64-ABI/-/commit/77566eb03bc6a326811cb7e9 >> >> PTA_NO_TUNE is introduced so that t

Re: [gcc r11-7940] Make USES_COMDAT_LOCAL CIF_FINAL_NORMAL

On Mär 31 2021, Jan Hubicka via Gcc-cvs wrote: > https://gcc.gnu.org/g:e7fd3b783238d034018443e43a58ff87908b4db6 > > commit r11-7940-ge7fd3b783238d034018443e43a58ff87908b4db6 > Author: Jan Hubicka > Date: Wed Mar 31 22:44:20 2021 +0200 > > Make USES_COMDAT_LOCAL CIF_FINAL_NORMAL > >

Re: RFC: Sphinx for GCC documentation

On 4/1/21 7:30 AM, Martin Liška wrote: Hey. I've returned to the David's project and I'm willing to finish his transition effort. I believe using Sphinx documentation can rapidly improve readability, both HTML and PDF version, of various GCC manuals ([1]). I've spent some time working on the D

Re: [gcc r11-7940] Make USES_COMDAT_LOCAL CIF_FINAL_NORMAL

> This breaks bootstrap on riscv64: > > In function ‘alloca_type_and_limit alloca_call_type(range_query&, gimple*, > bool ’, > inlined from ‘virtual unsigned int pass_walloca::execute(function*)’ at > ../../gcc/gimple-ssa-warn-alloca.c:295:25: > ../../gcc/gimple-ssa-warn-alloca.c:206:13: err

Re: [gcc r11-7940] Make USES_COMDAT_LOCAL CIF_FINAL_NORMAL

On 4/2/21 9:40 AM, Jan Hubicka wrote: This breaks bootstrap on riscv64: In function ‘alloca_type_and_limit alloca_call_type(range_query&, gimple*, bool ’, inlined from ‘virtual unsigned int pass_walloca::execute(function*)’ at ../../gcc/gimple-ssa-warn-alloca.c:295:25: ../../gcc/gimple-ss

c++: header unit purview [PR 99283]

This case occurs due to some equivocation about module_purview. Header-unit building is treated as a module-purview, but we should not treat entities imported from that as module purview. (header units were not a thing when I started). The testcase didn't understand we had a local textual d

Re: [gcc r11-7940] Make USES_COMDAT_LOCAL CIF_FINAL_NORMAL

On Apr 02 2021, Martin Sebor wrote: > One way to confirm this hypothesis might be to explicitly > initialize the limit member in the ctor even the argument is > ALLOCA_OK and see if the warning goes away. Yes, it does. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 757

[pushed] c++: lambda pack init-capture within generic lambda

We represent the type of a pack init-capture as auto... with packs from the initializer stuck into PACK_EXPANSION_PARAMETER_PACKS so that expanding it produces the right number of elements. But when partially instantiating the auto..., we were changing PACK_EXPANSION_PARAMETER_PACKS to refer to on

enable __ieee128 for p9vector tests

Several compile tests that use the __ieee128 type do not ensure it is defined. This patch adds -mfloat128 to their command lines, and disregards the warning that may be issued by it. Tested on x86_64-linux-gnu with a cross to powerpc-wrs-vxworks7r2, configured for a CPU without altivec/vsx supp

silence expected psabi warning in ipa-sra-19 on ppc-vxworks

The default CPU for our ppc-vx7r2 toolchain has no support for altivec or vsx, so an ABI without vector support is selected. The selected calling conventions do not cover passing or returning vector types, so -Wpsabi warns about such uses. powerpc-ibm-aix* already silences these warnings with -

New Swedish PO file for 'gcc' (version 11.1-b20210321)

Hello, gentle maintainer. This is a message from the Translation Project robot. A revised PO file for textual domain 'gcc' has been submitted by the Swedish team of translators. The file is available at: https://translationproject.org/latest/gcc/sv.po (This file, 'gcc-11.1-b20210321.sv.po'

Re: c++: imported templates and alias-template changes [PR 99283]

On Fri, 26 Mar 2021, Nathan Sidwell wrote: > > During development of modules, I had difficulty deciding whether the > module > flags of a template should live on the decl_template_result, the > template_decl, or both. I chose the latter, and require them to be > consistent. This and a fe

Re: RFC: Sphinx for GCC documentation

> On Apr 2, 2021, at 11:40 AM, Martin Sebor via Gcc-patches > wrote: > > ... > I'm not excited about changing tools. I like that Texinfo is a GNU > project; AFACT, Sphinx is not. Why is that important? It's an open source tool, and if it better in interesting ways I don't see why its aff

Re: [PATCH] rs6000: Avoid -fpatchable-function-entry* regressions on powerpc64 be [PR98125]

Hi! Alan tells me -fpatchable-function-entry is inconsequential on PowerPC, since the option is really only for the Linux kernel, and that uses -mprofile-kernel for us, instead. That option is only for 64 bit. The kernel does not support profiling for 32-bit PowerPC. Curiously, the kernel also

Re: [PATCH] rs6000: Fix up libgcc ABI when built with --with-long-double-format=ieee [PR97653]

Hi! On Wed, Mar 31, 2021 at 08:25:14PM +0200, Jakub Jelinek wrote: > __floatunditf and __fixtfdi and a couple of other libgcc{.a,_s.so} > entrypoints for backwards compatibility should mean IBM double double > handling (i.e. IFmode), gcc emits such calls for that format and > form IEEE long double

Re: silence expected psabi warning in ipa-sra-19 on ppc-vxworks

On Fri, Apr 02, 2021 at 02:05:24PM -0300, Alexandre Oliva wrote: > The default CPU for our ppc-vx7r2 toolchain has no support for altivec > or vsx, so an ABI without vector support is selected. The selected > calling conventions do not cover passing or returning vector types, so > -Wpsabi warns ab

[PATCH] c++: GC during late parsing collects live data [PR91416]

Coming back to : This is a crash that points to a GC problem. Consider this test: __attribute__ ((unused)) struct S { S() { } } s; We're parsing a simple-declaration. While parsing the decl specs, we parse the attribute

[pushed] c++: dependent attribute on parameter [PR97900]

We were copying attributes from the template to the instantiation without considering that they might be dependent. To make sure that the new parms have the appropriate properties for the code pattern, let's just regenerate them. Tested x86_64-pc-linux-gnu, applying to trunk. gcc/cp/ChangeLog:

[pushed] c++: PMF template parm and noexcept [PR90664]

The constexpr code only wants to preserve PTRMEM_CST in conversions if the conversions are only qualification conversions; dropping noexcept counts as a qualification adjustment in overload resolution, so let's include it here. Tested x86_64-pc-linux-gnu, applying to trunk. gcc/cp/ChangeLog:

[pushed] c++: NRV in lambda in template [PR91217]

tsubst_lambda_expr was producing a function with two blocks that claimed to be the outermost block in the function body, one from the call to start_lambda_function in tsubst_lambda_expr, and one from tsubsting the block added by start_lambda_function when we first parsed the lambda. This messed wi