Re: [PATCH 1/2] correct BB frequencies after loop changed

On 12/4/20 7:17 AM, Jiufu Guo via Gcc-patches wrote: Oh, this may be indicate 'approval with comments', right?:) Yes, Honza can you please review the patch? Thanks, Martin

Re: [PATCH 1/2] correct BB frequencies after loop changed

Jiufu Guo writes: > Jiufu Guo writes: > >> Jeff Law writes: >> >>> On 11/18/20 12:28 AM, Richard Biener wrote: On Tue, 17 Nov 2020, Jeff Law wrote: > Minor questions for Jan and Richi embedded below... > > On 10/9/20 4:12 AM, guojiufu via Gcc-patches wrote: >> When

Ping: [PATCH 2/2] Power10: Add IEEE 128-bit fp conditional move

I haven't received a reply for this patch: | Date: Sun, 15 Nov 2020 23:53:20 -0500 | Subject: [PATCH 2/2] Power10: Add IEEE 128-bit fp conditional move | Message-ID: <20201116045320.gb3...@ibm-toto.the-meissners.org> | https://gcc.gnu.org/pipermail/gcc-patches/2020-November/559167.html --

Ping: [PATCH 1/2] Power10: Add IEEE 128-bit xsmaxcqp and xsmincqp support.

I haven't received a reply for this patch: | Date: Sun, 15 Nov 2020 23:50:51 -0500 | Subject: [PATCH 1/2] Power10: Add IEEE 128-bit xsmaxcqp and xsmincqp support. | Message-ID: <20201116045051.ga3...@ibm-toto.the-meissners.org> | https://gcc.gnu.org/pipermail/gcc-patches/2020-November/559166.html

Ping: [PATCH] PowerPC: Add float128/Decimal conversions

I haven't received a reply for this patch: | Date: Thu, 19 Nov 2020 19:05:24 -0500 | Subject: [PATCH] PowerPC: Add float128/Decimal conversions | Message-ID: <2020112524.ga...@ibm-toto.the-meissners.org> | https://gcc.gnu.org/pipermail/gcc-patches/2020-November/559661.html -- Michael

Ping [PATCH] PowerPC: Map IEEE 128-bit long double built-in functions

I haven't received a response for this patch: | Date: Thu, 19 Nov 2020 18:58:14 -0500 | Subject: [PATCH] PowerPC: Map IEEE 128-bit long double built-in functions | Message-ID: <20201119235814.ga...@ibm-toto.the-meissners.org> | https://gcc.gnu.org/pipermail/gcc-patches/2020-November/559659.html

Ping: [PATCH] PowerPC: Set long double size for IBM/IEEE.

I haven't received a replay for this patch: | Date: Thu, 19 Nov 2020 19:00:11 -0500 | Subject: [PATCH] PowerPC: Set long double size for IBM/IEEE. | Message-ID: <2020112011.ga...@ibm-toto.the-meissners.org> | https://gcc.gnu.org/pipermail/gcc-patches/2020-November/559660.html -- Michael

[PATCH, Committed] PowerPC PR libgcc/o7543 and libgcc/97643, Fix long double issues

I committed the following patch today. After a burn-in period, I plan to commit the patch to older GCC releases, and close out the two PRs. PowerPC: PR libgcc/97543 and libgcc/97643, fix long double issues If you use a compiler with long double defaulting to 64-bit instead of 128-bit with IBM

[PATCH 1/3] PowerPC: Add long double target-supports.

PowerPC: Add long double target-supports. I messed up posting this patch, using the wrong subject line. This patch is what I meant to post. This patch replaces the patch submitted on November 21st: | Date: Sat, 21 Nov 2020 00:33:52 -0500 | Subject: [PATCH 1/3] PowerPC: Add long double

[PATCH 3/3] PowerPC: Force IBM long double for conversion test.

PowerPC: Force IBM long double for conversion test. This patch replaces the following patch: | Date: Sat, 21 Nov 2020 00:39:53 -0500 | Subject: [PATCH 3/3] PowerPC: Require IBM long double for conversion test. | Message-ID: <20201121053953.ge17...@ibm-toto.the-meissners.org> |

[PATCH 2/3] PowerPC: require IBM long double for pr70117.

PowerPC: PR target/70117, Force long double to be IBM 128-bit. This patch replaces the following patch: | Date: Sat, 21 Nov 2020 00:37:10 -0500 | Subject: [PATCH 2/3] PowerPC: require IBM long double for pr70117. | Message-ID: <20201121053710.gd17...@ibm-toto.the-meissners.org> |

Date: Sat, 21 Nov 2020 00:33:52 -0500

PowerPC: Add long double target-supports. This patch replaces the patch submitted on November 21st: | Date: Sat, 21 Nov 2020 00:33:52 -0500 | Subject: [PATCH 1/3] PowerPC: Add long double target-supports. | Message-ID: <20201121053352.gc17...@ibm-toto.the-meissners.org> |

[PATCH 0/3] Updates for float128 tests

These patches update the test suite patches I posted on November 21. There are 3 patches in this series. 1) The first patch adds new target-support options; 2) The second patch updates pr70117.c; (and) 3) The third patch updates convert-bfp-11.c. In the target supports patches, I

Re: [PATCH 1/2] correct BB frequencies after loop changed

Jiufu Guo writes: > Jeff Law writes: > >> On 11/18/20 12:28 AM, Richard Biener wrote: >>> On Tue, 17 Nov 2020, Jeff Law wrote: >>> Minor questions for Jan and Richi embedded below... On 10/9/20 4:12 AM, guojiufu via Gcc-patches wrote: > When investigating the issue from

Merge from trunk to gccgo branch

I merged trunk revision 3089f5feef36810c625b5813370a97b4ecc841f8 to the gccgo branch. Ian

Re: [PATCH] v2: doc/implement-c.texi: About same-as-scalar-type volatile aggregate accesses, PR94600

On 12/3/20 12:14 PM, Hans-Peter Nilsson via Gcc-patches wrote: Belatedly, here's an updated version, using Martin Sebor's suggested wording from "https://gcc.gnu.org/pipermail/gcc-patches/2020-July/549580.html;. I added two commas, hopefully helpfully. Albeit ok'd by Richard Biener in

Re: [PATCH] libstdc++: Add C++ runtime support for new 128-bit long double format

On 03/12/20 20:07 -0300, Tulio Magno Quites Machado Filho via Libstdc++ wrote: Jonathan Wakely via Libstdc++ writes: diff --git a/libstdc++-v3/configure.ac b/libstdc++-v3/configure.ac index cbfdf4c6bad..d25842fef35 100644 --- a/libstdc++-v3/configure.ac +++ b/libstdc++-v3/configure.ac @@

[PATCH 2/2] Warn used and not used symbols in the same section

When SECTION_RETAIN is used, issue a warning of symbol without used attribute is placed in the same section with symbol with used attribute, like int __attribute__((used,section(".data.foo"))) foo2 = 2; int __attribute__((section(".data.foo"))) foo1 = 1; since assembler will put them in

[PATCH 1/2] Switch to a new section if the SECTION_RETAIN bit doesn't match

When definitions marked with used attribute and unmarked definitions are placed in the same section, switch to a new section if the SECTION_RETAIN bit doesn't match. gcc/ PR other/98121 * output.h (switch_to_section): Add a tree argument, default to nullptr. *

[PATCH 0/2] Switch to a new section if the SECTION_RETAIN bit doesn't match

When SECTION_RETAIN is used, definitions marked with used attribute and unmarked definitions are placed in the same section. Instead of issue an error: [hjl@gnu-cfl-2 gcc]$ /usr/gcc-11.0.0-x32/bin/gcc -S c.c -fdiagnostics-plain-output c.c:2:49: error: ‘foo1’ causes a section type conflict with

[r11-5719 Regression] FAIL: g++.dg/cpp2a/concepts-nodiscard1.C -std=c++2a (test for excess errors) on Linux/x86_64

On Linux/x86_64, 5ea36d20c352a3ca436aa764404f6210b090866b is the first bad commit commit 5ea36d20c352a3ca436aa764404f6210b090866b Author: Jason Merrill Date: Thu Dec 3 13:55:51 2020 -0500 c++: Add testcase for PR98019 caused FAIL: g++.dg/cpp2a/concepts-nodiscard1.C -std=c++2a (test for

Re: [PATCH] libstdc++: Add C++ runtime support for new 128-bit long double format

Jonathan Wakely via Libstdc++ writes: > diff --git a/libstdc++-v3/configure.ac b/libstdc++-v3/configure.ac > index cbfdf4c6bad..d25842fef35 100644 > --- a/libstdc++-v3/configure.ac > +++ b/libstdc++-v3/configure.ac > @@ -421,12 +425,43 @@ case "$target" in > >

Re: How to traverse all the local variables that declared in the current routine?

Hi, Richard, Thanks a lot for your suggestion. Actually, I like this idea. My understanding of your suggestion is: 1. During gimplification phase: For each auto-variable that does not have an explicit initializer, insert the following initializer for it: X = DEFERRED_INIT (X, INIT) In

[pushed] c++: Fix bootstrap on 32-bit hosts [PR91828]

Using the releasing_vec op[] with an int index was breaking on 32-bit hosts because of ambiguity with the built-in operator and the conversion function. Since the built-in operator has a ptrdiff_t, this was fine on 64-bit targets where ptrdiff_t is larger than int, but broke on 32-bit targets

Re: [17/23] recog: Add a class for propagating into insns

On 11/13/20 1:20 AM, Richard Sandiford via Gcc-patches wrote: > This patch adds yet another way of propagating into an instruction and > simplifying the result. (The net effect of the series is to keep the > total number of propagation approaches the same though, since a later > patch removes

Re: [PATCH v2 08/31] jump: Also handle jumps wrapped in UNSPEC or UNSPEC_VOLATILE

On 12/2/20 8:50 PM, Maciej W. Rozycki wrote: > VAX has interlocked branch instructions used for atomic operations and > we want to have them wrapped in UNSPEC_VOLATILE so as not to have code > carried across. This however breaks with jump optimization and leads > to an ICE in the build of

[r11-5712 Regression] FAIL: g++.dg/template/pr98116.C -std=c++2a (test for excess errors) on Linux/x86_64

On Linux/x86_64, 7254a78cf4c419a9b9361289d8c535130cf1dfd0 is the first bad commit commit 7254a78cf4c419a9b9361289d8c535130cf1dfd0 Author: Nathan Sidwell Date: Thu Dec 3 08:40:43 2020 -0800 c++: Testcases [PR 98115] caused FAIL: g++.dg/template/pr98116.C -std=c++2a (internal compiler

Re: [PATCH] [X86_64]: Enable support for next generation AMD Zen3 CPU

On 12/3/20 8:29 AM, Kumar, Venkataramanan via Gcc-patches wrote: > [AMD Public Use] > > > Hi Maintainers, > > PFA, the patch that enables support for the next generation AMD Zen3 CPU via > -march=znver3. > This is a very basic enablement patch. As of now the cost, tuning and > scheduler

Re: [PATCH] c++: Distinguish unsatisfaction vs errors during satisfaction [PR97093]

On 12/3/20 9:24 AM, Patrick Palka wrote: During satisfaction, the flag info.noisy() controls three things: whether to diagnose fatal errors (such as the satisfaction value of an atom being non-bool); whether to diagnose unsatisfaction; and whether to bypass the satisfaction cache. This flag

Re: [PATCH 0/6] Add missing calls to `onlyjump_p'

On 12/3/20 4:34 AM, Maciej W. Rozycki wrote: > Hi, > > As discussed here: > > > > here is a small patch series adding missing calls to `onlyjump_p' around > `any_condjump_p' and `any_uncondjump_p' use where the jump in

Re: [PATCH 5/6] loop-doloop: Add missing call to `onlyjump_p'

On 12/3/20 4:35 AM, Maciej W. Rozycki wrote: > Keep any jump that has side effects as those must not be removed. > > gcc/ > * loop-doloop.c (add_test): Only remove the jump if `onlyjump_p'. OK jeff

Re: [PATCH 5/6] loop-doloop: Add missing call to `onlyjump_p'

On 12/3/20 4:35 AM, Maciej W. Rozycki wrote: > Keep any jump that has side effects as those must not be removed. > > gcc/ > * loop-doloop.c (add_test): Only remove the jump if `onlyjump_p'. OK jeff

Re: [PATCH 4/6] cfgrtl: Add missing call to `onlyjump_p'

On 12/3/20 4:34 AM, Maciej W. Rozycki wrote: > If any unconditional jumps within a block have side effects then the > block cannot be considered empty. > > gcc/ > * cfgrtl.c (rtl_block_empty_p): Return false if `!onlyjump_p' > too. OK jeff

Re: [PATCH 3/6] sel-sched-ir: Add missing call to `onlyjump_p'

On 12/3/20 4:34 AM, Maciej W. Rozycki wrote: > Do not try to remove a conditional jump if it has side effects. > > gcc/ > * sel-sched-ir.c (maybe_tidy_empty_bb): Only try to remove a > conditional jump if `onlyjump_p'. OK jeff

Re: [PATCH 2/6] loop-iv: Add missing calls to `onlyjump_p'

On 12/3/20 4:34 AM, Maciej W. Rozycki wrote: > Ignore jumps that have side effects in loop processing as pasting the > body of a loop multiple times within is semantically equivalent to jump > deletion (between the iterations unrolled) even if we do not physically > delete the jump RTL insn.

Re: [PATCH 1/6] ifcvt: Add missing call to `onlyjump_p'

On 12/3/20 4:34 AM, Maciej W. Rozycki wrote: > Do not convert a conditional jump into conditional execution (and remove > the jump as a consequence) if the jump has side effects. > > gcc/ > * ifcvt.c (dead_or_predicable) [!IFCVT_MODIFY_TESTS]: Bail out > if `!onlyjump_p'. OK

Re: [PATCH RFA] vec: Simplify use with C++11 range-based 'for'.

On 12/3/20 10:53 AM, Jason Merrill via Gcc-patches wrote: > It looks cleaner if we can use a vec* directly as a range for the C++11 > range-based 'for' loop, without needing to indirect from it, and also works > with null pointers. > > The change in cp_parser_late_parsing_default_args is an

c++: Exported using decls

With modules we need to record whethe a (namespace-scope) using decl is exporting the named entities. Record this on the OVERLOAD marking the used decl. gcc/cp/ * cp-tree.h (OVL_EXPORT): New. (class ovl_iterator): Add get_using, exporting_p. * tree.c

Re: Go testsuite patch committed: Add a bunch of new tests

On Thu, Dec 3, 2020 at 11:15 AM Ian Lance Taylor wrote: > > This patch to the Go testsuite adds a bunch of new tests from the > source repo. These are mostly tests that were added specifically to > test gccgo. There are still other tests in the source repo that are > not reflected in the gccgo

Re: [PATCH v2] rs6000, vector integer multiply/divide/modulo instructions

On Tue, 2020-12-01 at 15:48 -0800, Carl Love via Gcc-patches wrote: > Segher, Pat: > > I have updated the patch to address the comments below. > > On Wed, 2020-11-25 at 20:30 -0600, Segher Boessenkool wrote: > > On Tue, Nov 24, 2020 at 08:34:51PM -0600, Pat Haugen wrote: > > > On 11/24/20 8:17

Re: [committed] libstdc++: Add std::bit_cast for C++20 [PR 93121]

On 03/12/20 19:25 +, Jonathan Wakely wrote: Thanks to Jakub's addition of the built-in, we can add this to the library now. The compiler tests for the built-in are quite extensive, including verifying the constraints, so this only adds minimal tests to the library testsuite. This doesn't

Re: [ PATCH ] [ C++ ] [ libstdc++ ] P1208r6 Merge source_location

On 02/01/20 17:20 -0500, JeanHeyd Meneide wrote: On Thu, Jan 2, 2020 at 5:07 PM Jakub Jelinek wrote: On Thu, Jan 02, 2020 at 04:57:01PM -0500, JeanHeyd Meneide wrote: > +#if defined(_GLIBCXX_HAVE_BUILTIN_SOURCE_LOCATION) > +# define __cpp_lib_source_location 201907L > +#elif

[committed] libstdc++: Update C++20 library implementation status

libstdc++-v3/ChangeLog: * doc/xml/manual/status_cxx2020.xml: Update C++20 status. * doc/html/*: Regenerate. Tested powerpc64le-linux. Committed to trunk. commit 44ac1ea0e2244343b798ff1ccc7048029cb9fa02 Author: Jonathan Wakely Date: Thu Dec 3 19:17:13 2020 libstdc++:

[committed] libstdc++: Add std::bit_cast for C++20 [PR 93121]

Thanks to Jakub's addition of the built-in, we can add this to the library now. The compiler tests for the built-in are quite extensive, including verifying the constraints, so this only adds minimal tests to the library testsuite. This doesn't add a new _GLIBCXX_HAVE_BUILTIN_BIT_CAST because

c++: uninstantiated template friends

template friends need to be recognized by module streaming and associated with the befriending class. but their context is that of the friend (a namespace or other class). This adds a flag to mark such templates, and uses their DECL_CHAIN to point at the befriender. gcc/cp *

Go testsuite patch committed: Add a bunch of new tests

This patch to the Go testsuite adds a bunch of new tests from the source repo. These are mostly tests that were added specifically to test gccgo. There are still other tests in the source repo that are not reflected in the gccgo copy. Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu.

[PATCH] v2: doc/implement-c.texi: About same-as-scalar-type volatile aggregate accesses, PR94600

Belatedly, here's an updated version, using Martin Sebor's suggested wording from "https://gcc.gnu.org/pipermail/gcc-patches/2020-July/549580.html;. I added two commas, hopefully helpfully. Albeit ok'd by Richard Biener in "https://gcc.gnu.org/pipermail/gcc-patches/2020-July/549922.html;, better

[patch] Fix checking failure in IPA-SRA

Hi, this is a regression present on the mainline and 10 branch: on the one hand, IPA-SRA does *not* disqualify accesses with zero size but, on the other hand, it checks that accesses present in the tree have a (strictly) positive size, thus trivially yielding an ICE, for example on the attached

Go testsuite patch committed: Add -I. when compiling in directory

This Go testsuite patch adds a -I. argument when compiling sources in a directory. This tells the compiler to import packages in the current directory first, which is what we want in the testsuite. Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu. Committed to mainline. Ian *

Re: [gcc r11-4816] Fix Ada build failure for the SuSE PowerPC64/Linux compiler

On Dez 03 2020, Eric Botcazou wrote: > I'm afraid we cannot support both given the current setup, so you'll have to > make a choice for the powerpc64-suse-linux compiler. I'm using the same configuration as the system compiler. There is no choice to make. Andreas. -- Andreas Schwab,

Re: [gcc r11-4816] Fix Ada build failure for the SuSE PowerPC64/Linux compiler

> Nope. The default is 64-bit. That's not what Richard said under PR ada/97504 though: "Yes, we're building a 64bit compiler defaulting to -m32. Our "ppc" target was never a true 32bit system but a 64bit system with a 32bit "default" runtime and 64bit multilibs, so most binaries in the system

Go testsuite: update existing tests to source repo

I've committed a patch to update the existing Go tests, the ones under go.test, to the versions in the source repo at https://go.googlesource.com/. This does not include any of the new tests, just updates the ones we already have and removes the ones that no longer exist in the source. The

Re: [PATCH RFA] vec: Simplify use with C++11 range-based 'for'.

On Thu, Dec 03, 2020 at 12:53:22PM -0500, Jason Merrill via Gcc-patches wrote: > It looks cleaner if we can use a vec* directly as a range for the C++11 > range-based 'for' loop, without needing to indirect from it, and also works > with null pointers. Nice. > The change in

[PATCH RFA] vec: Simplify use with C++11 range-based 'for'.

It looks cleaner if we can use a vec* directly as a range for the C++11 range-based 'for' loop, without needing to indirect from it, and also works with null pointers. The change in cp_parser_late_parsing_default_args is an example of how this can be used to simplify many loops over vec*. I

Re: [PATCH] implement pre-c++20 contracts

On 12/3/20 12:07 PM, Andrew Sutton wrote: > Attached is a new squashed revision of the patch sans ChangeLogs. The > current work is now being done on github: > https://github.com/lock3/gcc/tree/contracts-jac-alt I'm

Re: How to traverse all the local variables that declared in the current routine?

Richard Biener via Gcc-patches writes: > On Tue, Nov 24, 2020 at 4:47 PM Qing Zhao wrote: >> Another issue is, in order to check whether an auto-variable has >> initializer, I plan to add a new bit in “decl_common” as: >> /* In a VAR_DECL, this is DECL_IS_INITIALIZED. */ >> unsigned

Re: [pushed] c++: Push parms when late parsing default args

Hi Jason, > In this testcase we weren't catching the error in A::f because the parameter > 'I' wasn't in scope, so the default argument for 'b' found the global > typedef I. Fixed by pushing the parms before parsing. This is a bit > complicated because pushdecl clears DECL_CHAIN;

Re: [PATCH] 2/2 Remove debug/array

On 03/12/20 18:14 +0100, Daniel Krügler via Libstdc++ wrote: Am Do., 3. Dez. 2020 um 18:10 Uhr schrieb Jonathan Wakely via Libstdc++ : [..] >>Ok to commit ? > >Yes, this is a nice simplification, thanks. This broke the C++11 constexpr support in std::array. Fixed with this patch. Tested

[committed] libstdc++: Update powerpc-linux baselines for GCC 10.1

This should have been done before the GCC 10.1 release. libstdc++-v3/ChangeLog: * config/abi/post/powerpc-linux-gnu/baseline_symbols.txt: Update. * config/abi/post/powerpc64-linux-gnu/32/baseline_symbols.txt: Update. Tested powerpc64-linux. Committed to trunk.

[PATCH][GCC10][6/6] arm: Add vstN_lane_bf16 + vstNq_lane_bf16 intrisics

Hi all, last patch of the series to backport a number of bfloat16 intrinsics from trunk to gcc-10. These patch are including the fixes to the tests that we have applied into master. Please see refer to: ACLE ISA

Re: [PATCH] 2/2 Remove debug/array

Am Do., 3. Dez. 2020 um 18:10 Uhr schrieb Jonathan Wakely via Libstdc++ : > [..] > >>Ok to commit ? > > > >Yes, this is a nice simplification, thanks. > > This broke the C++11 constexpr support in std::array. Fixed with this > patch. Tested x86_64-linux, committed to trunk. Wouldn't a

[PATCH][GCC10][5/6] arm: Add vldN_lane_bf16 + vldNq_lane_bf16 intrisics

Hi all, fifth patch of the series to backport a number of bfloat16 intrinsics from trunk to gcc-10. These patch are including the fixes to the tests that we have applied into master. Please see refer to: ACLE ISA

[PATCH][GCC10][4/6] arm: Add vst1_bf16 + vst1q_bf16 intrinsics

Hi all, forth patch of the series to backport a number of bfloat16 intrinsics from trunk to gcc-10. These patch are including the fixes to the tests that we have applied into master. Please see refer to: ACLE ISA

[PATCH][GCC10][3/6] arm: Add vld1_bf16 + vld1q_bf16 intrinsics

Hi all, third patch of the series to backport a number of bfloat16 intrinsics from trunk to gcc-10. These patch are including the fixes to the tests that we have applied into master. Please see refer to: ACLE ISA

Re: [PATCH] 2/2 Remove debug/array

On 09/11/20 13:07 +, Jonathan Wakely wrote: On 08/11/20 15:27 +0100, François Dumont via Libstdc++ wrote: Following a recent fix on std::array this test started to fail in _GLIBCXX_DEBUG mode. FAIL: 23_containers/array/comparison_operators/96851.cc (test for excess errors) Rather than

[PATCH][GCC10][2/6] arm: Add vst1_lane_bf16 + vstq_lane_bf16 intrinsics

Hi all, second patch of the series to backport a number of bfloat16 intrinsics from trunk to gcc-10. These patch are including the fixes to the tests that we have applied into master. Please see refer to: ACLE ISA

[PATCH][GCC10][1/6] arm: Add vld1_lane_bf16 + vldq_lane_bf16 intrinsics

Hi all, first patch of the series to backport a number of bfloat16 intrinsics from trunk to gcc-10. These patch are including the fixes to the tests that we have applied into master. Please see refer to: ACLE ISA

Re: [PATCH] implement pre-c++20 contracts

> > > > Attached is a new squashed revision of the patch sans ChangeLogs. The > > current work is now being done on github: > > https://github.com/lock3/gcc/tree/contracts-jac-alt > > I'm starting to review this now, sorry for the delay. Is this still the > branch you want me to consider for GCC

[PATCH v2]: i386: Fix up ix86_md_asm_adjust for TImode [PR98086]

ix86_md_asm_adjust assumes that dest_mode can be only [QHSD]Imode and nothing else. The patch rewrites zero-extension part to use convert_to_mode to handle TImode and hypothetically even wider modes. 2020-12-03 Uroš Bizjak Jakub Jelinek gcc/ PR target/98086 *

c++: templatey type creation

This patch makes a couple of type-creation routines available to modules. That needs to create unbound template parms, and canonical template parms. gcc/cp/ * cp-tree.h (make_unbound_class_template_raw): Declare. (canonical_type_parameter): Declare. * decl.c

Re: How to traverse all the local variables that declared in the current routine?

Richard Biener via Gcc-patches writes: > On December 3, 2020 5:07:28 PM GMT+01:00, Qing Zhao > wrote: >> >> >>> On Dec 3, 2020, at 2:45 AM, Richard Biener >> wrote: >>> >>> On Wed, Dec 2, 2020 at 4:36 PM Qing Zhao >> wrote: On Dec 2, 2020, at

Re: introduce overridable clear_cache emitter

On 12/3/20 7:08 AM, Alexandre Oliva wrote: > On Dec 3, 2020, Christophe Lyon wrote: > >> This patches causes a lot of regressions in fortran on arm and aarch64, > On Dec 3, 2020, Andreas Schwab wrote: > >> On Dez 03 2020, Andreas Schwab wrote: >>> ../../../../libffi/src/aarch64/ffi.c: In

Re: c++: Fix array type dependency [PR 98107]

These two testcases provide coverage for 98115, which doesn't trigger on all hosts. PR c++/98115 PR c++/98116 gcc/testsuite/ * g++.dg/template/pr98115.C: New. * g++.dg/template/pr98116.C: New. nathan -- Nathan Sidwell diff --git

Re: How to traverse all the local variables that declared in the current routine?

> On Dec 3, 2020, at 10:36 AM, Richard Biener > wrote: > > On December 3, 2020 5:07:28 PM GMT+01:00, Qing Zhao > wrote: >> >> of uninitialized analysis in the later stage. >>> >>> I don't see how the issue can be resolved, you can't get both, uninit >>>

Re: How to traverse all the local variables that declared in the current routine?

On December 3, 2020 5:07:28 PM GMT+01:00, Qing Zhao wrote: > > >> On Dec 3, 2020, at 2:45 AM, Richard Biener > wrote: >> >> On Wed, Dec 2, 2020 at 4:36 PM Qing Zhao > wrote: >>> >>> >>> >>> On Dec 2, 2020, at 2:45 AM, Richard Biener > wrote: >>> >>> On Tue, Dec

Go patch committed: Convert comparison function result to expected bool type

This patch to the Go frontend converts the result type of calling a comparison function to the expected bool type. Otherwise cases like type mybool bool var b mybool = [10]string{} == [10]string{} get an incorrect type checking error. Bootstrapped and ran Go testsuite on

Go patch committed: Defer to middle-end for complex division

This patch to the Go frontend and libgo defers to the middle-end for complex division. Go used to use slightly different semantics than C99 for complex division, so we used runtime routines to handle the difference. The gc compiler has changed its behavior to match C99, so change ours as well.

Re: How to traverse all the local variables that declared in the current routine?

> On Dec 3, 2020, at 2:45 AM, Richard Biener wrote: > > On Wed, Dec 2, 2020 at 4:36 PM Qing Zhao > wrote: >> >> >> >> On Dec 2, 2020, at 2:45 AM, Richard Biener >> wrote: >> >> On Tue, Dec 1, 2020 at 8:49 PM Qing Zhao wrote: >> >> >> Hi, Richard, >> >>

[Committed] IBM Z: Fix mode in probe_stack pattern

The probe pattern uses Pmode but the middle-end wants to emit a word_mode probe check. This - as usual - breaks on Z with -m31 -mzarch were word_mode doesn't match Pmode. Bootstrapped and regression-tested on s390x. gcc/ChangeLog: * config/s390/s390.md ("@probe_stack2"): Change mode

c++: Fix array type dependency [PR 98107]

I'd missed somepaths through build_cplus_array_type, plus, some arrays come via the C-type builder. This propagates dependencyin more places and asserts that in the cases where TYPE_DEPENDENT_P_VALID is unset, the type is non-dependent. PR c++/98107 gcc/cp/ * tree.c

Re: OpenMP patch ping ** 2

Hi, I would like to ping the following OpenMP-related patches: On 27.11.20 17:09, Tobias Burnus wrote: OpenMP-related patch pings: Kwok's: * Re: [PATCH] openmp: Implicit 'declare target' for C++ static initializers https://gcc.gnu.org/pipermail/gcc-patches/2020-November/559624.html *

[committed] aarch64: Don't fold svundef* at the gimple level

As the testcase shows, folding svundef*() at the gimple level has the unfortunate side-effect of introducing -Wuninitialized or -Wmaybe-uninitialized warnings. We don't have a testcase that relies on the fold, so the easiest fix seems to be to remove it. Tested on aarch64-linux-gnu and

[PATCH] [X86_64]: Enable support for next generation AMD Zen3 CPU

[AMD Public Use] Hi Maintainers, PFA, the patch that enables support for the next generation AMD Zen3 CPU via -march=znver3. This is a very basic enablement patch. As of now the cost, tuning and scheduler changes are kept same as znver2. Further changes to the cost and tunings will be done

RE: [PATCH] [X86_64]: Enable support for next generation AMD Zen3 CPU

[AMD Public Use] Thanks Uros, I forgot to change. Please ignore this thread . I will send fresh one. Regards, Venkat. -Original Message- From: Uros Bizjak Sent: Thursday, December 3, 2020 8:44 PM To: Kumar, Venkataramanan Cc: gcc-patches@gcc.gnu.org; Jan Hubicka Subject: Re:

Re: [PATCH] [X86_64]: Enable support for next generation AMD Zen3 CPU

The message says that it is for internal distribution. Please repost. Thanks, Uros. On Thu, Dec 3, 2020 at 4:11 PM Kumar, Venkataramanan wrote: > > [AMD Official Use Only - Internal Distribution Only] > > > Hi Maintainers, > > > > PFA, the patch that enables support for the next generation AMD

[PATCH] [X86_64]: Enable support for next generation AMD Zen3 CPU

[AMD Official Use Only - Internal Distribution Only] Hi Maintainers, PFA, the patch that enables support for the next generation AMD Zen3 CPU via -march=znver3. This is a very basic enablement patch. As of now the cost, tuning and scheduler changes are kept same as znver2. Further changes to

Re: [PATCH] c++: v3: Add __builtin_bit_cast to implement std::bit_cast [PR93121]

On 11/26/20 10:09 AM, Jakub Jelinek wrote: Sorry, thought I had replied to this before. The following patch removes the mask from the new native_interpret_aggregate moved to fold-const.c altogether. Instead, the code uses the __builtin_clear_padding infrastructure (new entrypoint in there).

[PATCH] c++: Distinguish unsatisfaction vs errors during satisfaction [PR97093]

During satisfaction, the flag info.noisy() controls three things: whether to diagnose fatal errors (such as the satisfaction value of an atom being non-bool); whether to diagnose unsatisfaction; and whether to bypass the satisfaction cache. This flag turns out to be too coarse however, for

Re: [PATCH 3/4] rs6000: Enable vec_insert for P8 with rs6000_expand_vector_set_var_p8

Ping. Thanks. On 2020/11/27 09:04, Xionghu Luo via Gcc-patches wrote: Hi Segher, Thanks for the approval of [PATCH 1/4] and [PATCH 2/4], what's your opinion of this [PATCH 3/4] for P8, please? xxinsertw only exists since v3.0, so we had to implement by another way. Xionghu On 2020/10/10

Re: introduce overridable clear_cache emitter

On Dec 3, 2020, Christophe Lyon wrote: > This patches causes a lot of regressions in fortran on arm and aarch64, On Dec 3, 2020, Andreas Schwab wrote: > On Dez 03 2020, Andreas Schwab wrote: >> ../../../../libffi/src/aarch64/ffi.c: In function 'ffi_prep_closure_loc': >>

Re: [PATCH] c++: consteval-defarg1.C test variant for templates

On 12/3/20 4:29 AM, Jakub Jelinek wrote: On Wed, Dec 02, 2020 at 10:15:25PM -0500, Jason Merrill wrote: Jakub noticed that we weren't recognizing a default argument for a consteval member function as being in immediate function context because there was no function parameter scope to look at.

C++ patch ping

Hi! I'd like to ping https://gcc.gnu.org/pipermail/gcc-patches/2020-November/560372.html - v3 of the __builtin_bit_cast (with (hopefully) all earlier feedback incorporated). Thanks Jakub

[PATCH] tree-optimization/98113 - vectorize a sequence of BIT_INSERT_EXPRs

This adds the capability to handle a sequence of vector BIT_INSERT_EXPRs to be vectorized similar as to how we vectorize vector constructors. Bootstrapped and tested on x86_64-unknown-linux-gnu, OK at this stage or do we want to defer to stage1 and regress for the PRs testcase? The testcase can

Re: [stage1][PATCH] Change semantics of -frecord-gcc-switches and add -frecord-gcc-switches-format.

On Thu, Nov 26, 2020 at 2:55 PM Martin Liška wrote: > > On 11/25/20 2:48 PM, Richard Biener wrote: > > On Mon, Nov 23, 2020 at 2:02 PM Martin Liška wrote: > >> > >> On 11/23/20 12:00 PM, Richard Biener wrote: > >>> Can you split out the unifying of -[gf]record-gcc-switches processing > >>> and

Re: introduce overridable clear_cache emitter

On Dez 03 2020, Andreas Schwab wrote: > ../../../../libffi/src/aarch64/ffi.c: In function 'ffi_prep_closure_loc': > ../../../../libffi/src/aarch64/ffi.c:67:3: error: both arguments to > '__builtin___clear_cache' must be pointers >67 | __builtin___clear_cache (start, end); > |

Re: [gcc r11-4816] Fix Ada build failure for the SuSE PowerPC64/Linux compiler

On Dez 03 2020, Eric Botcazou wrote: >> This breaks build of libada, it is missing all of $(GNATRTL_128BIT_OBJS). > > In the default multilib? Yes, that's the point, since it's 32-bit apparently. Nope. The default is 64-bit. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key

Re: [patch] Fix PR middle-end/98082

On Thu, Dec 3, 2020 at 11:49 AM Eric Botcazou wrote: > > Hi, > > this fixes an ICE introduced on the mainline by my fix for PR middle-end/97078 > where I changed use_register_for_decl to return true at -O0 for a parameter of > a thunk. It turns out that we need to do the same for a result in

Re: [patch] Fix PR middle-end/98099

On Thu, Dec 3, 2020 at 11:49 AM Eric Botcazou wrote: > > Hi, > > this replaces the ICE by a sorry message for the use of reverse scalar storage > order with a 128-bit decimal floating-point type on 32-bit platforms. > > Tested on x86-64/Linux, OK for the mainline? OK. Richard. > > 2020-12-03

Re: introduce overridable clear_cache emitter

../../../../libffi/src/aarch64/ffi.c: In function 'ffi_prep_closure_loc': ../../../../libffi/src/aarch64/ffi.c:67:3: error: both arguments to '__builtin___clear_cache' must be pointers 67 | __builtin___clear_cache (start, end); | ^~~~ Andreas. --

[BUG/PATCH] ppc64 g5 and cell optimizations result in .machine power7

Hi, Since reworking the rs6000 .machine output selection in commit e154242724b084380e3221df7c08fcdbd8460674 22 May 2019, compiling glibc with either G5 or cell results in power7 assembly optimizations to be chosen, which obviously crash with illegal instructions. This is because gcc's .machine

  1   2   >