[PATCH v2] gcov: Add GCOV_TYPE_SIZE target macro

If -fprofile-update=atomic is used, then the target must provide atomic operations for the counters of the type returned by get_gcov_type(). This is a 64-bit type for targets which have a 64-bit long long type. On 32-bit targets this could be an issue since they may not provide 64-bit atomic operat

[PATCH] c++: Fix unnecessary error when top-level cv-qualifiers is dropped [PR101783]

The root cause of this bug is that it considers reference with cv-qualifiers as an error by generating value for variable "bad_quals". However, this is not correct for case of typedef. Here I quote spec: "Cv-qualified references are ill-formed except when the cv-qualifiers are introduced through th

Re: [RFC] Don't move cold code out of loop by checking bb count

On Tue, Aug 10, 2021 at 4:03 AM Xionghu Luo via Gcc-patches wrote: > For this case, theorotically I think the master GCC will optimize it to: > > invariant; > for (;;) > if (unlikely_cond) > for (;;) > ; > > 'invariant' is moved out of outer loop, but with the patch, it will

[C++ PATCH] Fix unnecessary error when top-level cv-qualifiers is dropped (PR c++/101783)

The root cause of this bug is that it considers reference with cv-qualifiers as an error by generating value for variable "bad_quals". However, this is not correct for case of typedef. Here I quote spec: "Cv-qualified references are ill-formed except when the cv-qualifiers are introduced through

Re: [RFC] Don't move cold code out of loop by checking bb count

Hi, On 2021/8/6 20:15, Richard Biener wrote: > On Mon, Aug 2, 2021 at 7:05 AM Xiong Hu Luo wrote: >> >> There was a patch trying to avoid move cold block out of loop: >> >> https://gcc.gnu.org/pipermail/gcc/2014-November/215551.html >> >> Richard suggested to "never hoist anything from a bb with

Re: [PATCH 03/34] rs6000: Add the rest of the [altivec] stanza to the builtins file

On Mon, Aug 09, 2021 at 02:18:48PM -0500, Bill Schmidt wrote: > >>"const void" is meaningless, and maybe even invalid C. I think the code > >>is wrong, not (just) the documentation! This wants to be > >>void *const > >>but it is > >>const void * > >>as far as I can see? > >> > >>As I said

Re: [C PATCH] Evaluate argument of sizeof that are structs of variable size.

Am Montag, den 09.08.2021, 21:42 + schrieb Joseph Myers: > On Mon, 9 Aug 2021, Uecker, Martin wrote: > > > Evaluate arguments of sizeof that are structs of variable size. > > > > Evaluate arguments of sizeof for all types of variable size > > and not just for VLAs. This fixes some issues rela

Re: [C PATCH] Evaluate argument of sizeof that are structs of variable size.

On Mon, 9 Aug 2021, Uecker, Martin wrote: > Evaluate arguments of sizeof that are structs of variable size. > > Evaluate arguments of sizeof for all types of variable size > and not just for VLAs. This fixes some issues related to > [PR29970] where statement expressions need to be evaluated > so

Re: [Patch v2 Fortran] Fix c_float128 and c_float128_complex on targets with 128-bit long double.

On 8/5/21 2:09 PM, Michael Meissner wrote: All PowerPC systems that I'm aware of that use 128-bit floating point use the IBM format. It is anticipated that one or more Linux distributions in the future may move to IEEE 128-bit format, but right now, I'm not aware that any have moved. OK. I n

[C PATCH] Evaluate argument of sizeof that are structs of variable size.

Here is a patch which changes the behavior of sizeof when applied to structs of variable size (a GNU extension) to evaluate its arguments as it does for VLAs. This is a breaking change, but it seems this is required if we want to fix [PR29970] (and it is also more consistent). Together with the pa

Re: [PATCH] c++: Improve memory usage of subsumption [PR100828]

On Wed, Jul 28, 2021 at 4:42 PM Jason Merrill wrote: > > On 7/19/21 6:05 PM, Patrick Palka wrote: > > Constraint subsumption is implemented in two steps. The first step > > computes the disjunctive (or conjunctive) normal form of one of the > > constraints, and the second step verifies that each

[PATCH 5/6] rs6000: Support more SSE4.1 "cmp", "mul", "pack" intrinsics

Also, copy tests for: - _mm_cmpeq_epi64, _mm_cmpgt_epi64 - _mm_mullo_epi32, _mm_mul_epi32 - _mm_packus_epi32 from gcc/testsuite/gcc.target/i386. 2021-08-09 Paul A. Clarke gcc * config/rs6000/smmintrin.h (_mm_cmpeq_epi64, _mm_cmpgt_epi64, _mm_mullo_epi32, _mm_mul_epi32, _mm_pac

[PATCH 4/6] rs6000: Support SSE4.1 "cvt" intrinsics

Also, copy tests for: - _mm_cvtepi8_epi16, _mm_cvtepi8_epi32, _mm_cvtepi8_epi64 - _mm_cvtepi16_epi32, _mm_cvtepi16_epi64 - _mm_cvtepi32_epi64, - _mm_cvtepu8_epi16, _mm_cvtepu8_epi32, _mm_cvtepu8_epi64 - _mm_cvtepu16_epi32, _mm_cvtepu16_epi64 - _mm_cvtepu32_epi64 from gcc/testsuite/gcc.target/i386.

[COMMITTED] PR tree-optimization/101741 - Ensure toupper and tolower follow the expected pattern.

The user has overridden the function name "toupper" . Its marked as a builtin function, presumably because it matches the name.  In range folding, we were assuming the LHS and the parameter were compatible types...  but they are not in this case.. I don't know if we should be marking such a th

[PATCH 3/6] rs6000: Simplify some SSE4.1 "test" intrinsics

Copy some simple redirections from i386 , for: - _mm_test_all_zeros - _mm_test_all_ones - _mm_test_mix_ones_zeros 2021-08-09 Paul A. Clarke gcc * config/rs6000/smmintrin.h (_mm_test_all_zeros, _mm_test_all_ones, _mm_test_mix_ones_zeros): Replace. --- gcc/config/rs6000/smmintri

[PATCH 1/6] rs6000: Support SSE4.1 "round" intrinsics

Suppress exceptions (when specified), by saving, manipulating, and restoring the FPSCR. Similarly, save, set, and restore the floating-point rounding mode when required. No attempt is made to optimize writing the FPSCR (by checking if the new value would be the same), other than using lighter wei

[PATCH 2/6] rs6000: Support SSE4.1 "min" and "max" intrinsics

Also, copy tests for _mm_min_epi8, _mm_min_epu16, _mm_min_epi32, _mm_min_epu32, _mm_max_epi8, _mm_max_epu16, _mm_max_epi32, _mm_max_epu32 from gcc/testsuite/gcc.target/i386. sse4_1-pmaxsb.c and sse4_1-pminsb.c were modified from using "char" types to "signed char" types, because the default is uns

[PATCH 0/6] rs6000: Support more SSE4.1 intrinsics

Paul A. Clarke (6): rs6000: Support SSE4.1 "round" intrinsics rs6000: Support SSE4.1 "min" and "max" intrinsics rs6000: Simplify some SSE4.1 "test" intrinsics rs6000: Support SSE4.1 "cvt" intrinsics rs6000: Support more SSE4.1 "cmp", "mul", "pack" intrinsics rs6000: Guard some x86 intri

[PATCH 6/6] rs6000: Guard some x86 intrinsics implementations

Some compatibility implementations of x86 intrinsics include Power intrinsics which require POWER8. Guard them. emmintrin.h: - _mm_cmpord_pd: Remove code which was ostensibly for pre-POWER8, but which indeed depended on POWER8 (vec_cmpgt(v2du)/vcmpgtud). The "POWER8" version works fine on pre

Re: trunk -D_GLIBCXX_DEBUG #include fails

On Mon, 9 Aug 2021 at 15:42, Jonathan Wakely wrote: > > On Mon, 9 Aug 2021 at 15:27, Jonathan Wakely wrote: > > > > On Mon, 9 Aug 2021 at 13:05, François Dumont via Libstdc++ > > wrote: > > > > > > On 09/08/21 12:05 pm, Jonathan Wakely via Libstdc++ wrote: > > > > On Mon, 9 Aug 2021 at 10:51, Ste

Re: [PATCH 03/34] rs6000: Add the rest of the [altivec] stanza to the builtins file

Hi Segher, + pcvoid_type_node += build_pointer_type (build_qualified_type (void_type_node, + TYPE_QUAL_CONST)); A const void? Interesting. You are building a pointer to a const void here, not a const pointer to void. Is that what you wanted?

[PATCH v4] x86: Optimize load of const FP all bits set vectors

On Mon, Aug 9, 2021 at 11:53 AM Uros Bizjak wrote: > > On Mon, Aug 9, 2021 at 7:47 PM H.J. Lu wrote: > > > > On Mon, Aug 9, 2021 at 8:27 AM Uros Bizjak wrote: > > > > > > On Mon, Aug 9, 2021 at 5:24 PM H.J. Lu wrote: > > > > > > > > On Sun, Aug 8, 2021 at 1:23 PM Uros Bizjak wrote: > > > > > >

Re: [PATCH v3] x86: Optimize load of const all 1s FP vectors

On Mon, Aug 9, 2021 at 7:47 PM H.J. Lu wrote: > > On Mon, Aug 9, 2021 at 8:27 AM Uros Bizjak wrote: > > > > On Mon, Aug 9, 2021 at 5:24 PM H.J. Lu wrote: > > > > > > On Sun, Aug 8, 2021 at 1:23 PM Uros Bizjak wrote: > > > > > > > > On Sat, Aug 7, 2021 at 4:41 PM H.J. Lu wrote: > > > > > > > >

Re: [wwwdocs] gcc-12/changes.html (GCN): >1 workers per gang

On Mon, 9 Aug 2021, Tobias Burnus wrote: > Comments and/or suggestions? Looks good from my perspective, with the feedback that Thomas provided. (Is "CU" a sufficiently established term, or might it make sense to spell it out?) Thanks, Gerald

Re: [PATCH] gcov: Add GCOV_TYPE_SIZE target macro

On 09/08/2021 15:58, Sebastian Huber wrote: If -fprofile-update=atomic is used, then the target must provide atomic operations for the counters of the type returned by get_gcov_type(). This is a 64-bit type for targets which have a 64-bit long long type. On 32-bit targets this could be an issue s

[r12-2808 Regression] FAIL: gfortran.dg/ieee/pr77372.f90 -O (test for excess errors) on Linux/x86_64

On Linux/x86_64, 527a1cf32c27a3fbeaf6be7596241570d864cc4c is the first bad commit commit 527a1cf32c27a3fbeaf6be7596241570d864cc4c Author: Tobias Burnus Date: Mon Aug 9 12:35:23 2021 +0200 testsuite/lib/gfortran.exp: Add -I for ISO*.h [PR101305, PR101660] caused FAIL: gfortran.dg/ieee/dec

Re: [PATCH 03/34] rs6000: Add the rest of the [altivec] stanza to the builtins file

On Sun, Aug 08, 2021 at 03:53:01PM -0500, Bill Schmidt wrote: > On 8/8/21 3:27 PM, Segher Boessenkool wrote: > >Okido. What about the signed char though? > > Sorry, forgot to address that.  There are two reasons to keep it as is:  > (a) It matches what we have in the old support, and (b) it make

Re: [committed v2 3/3] arm: reorder assembler architecture directives [PR101723]

Hi Richard, On Fri, Aug 6, 2021 at 4:08 PM Christophe Lyon < christophe.lyon@gmail.com> wrote: > > > On Thu, Aug 5, 2021 at 1:58 PM Richard Earnshaw wrote: > >> >> A change to the way gas interprets the .fpu directive in binutils-2.34 >> means that issuing .fpu will clear any features set b

[PATCH v3] x86: Optimize load of const all 1s FP vectors

On Mon, Aug 9, 2021 at 8:27 AM Uros Bizjak wrote: > > On Mon, Aug 9, 2021 at 5:24 PM H.J. Lu wrote: > > > > On Sun, Aug 8, 2021 at 1:23 PM Uros Bizjak wrote: > > > > > > On Sat, Aug 7, 2021 at 4:41 PM H.J. Lu wrote: > > > > > > > > Update vector_all_ones_operand to return true for const all 1s

[PATCH] c++: recognize class-scope non-template dguides [PR79501]

It looks like we still don't recognize class-scope non-template deduction guides even after r12-2260. This is because deduction guides are handled in cp_parser_init_declarator after calling cp_parser_declarator, but in the class-scope non-template case we call cp_parser_declarator directly from c

[PATCH] c++: most vexing parse and braced CTAD [PR89062]

Here grokdeclarator is emitting the error error: class template placeholder ‘Foo’ not permitted in this context during the tentative (and ultimately futile) parse of 'x' as a function declaration. This happens because when parsing 'Foo{1}', cp_parser_parameter_declaration yields an parameter d

Re: [patch][version 6] add -ftrivial-auto-var-init and variable attribute "uninitialized" to gcc

On August 9, 2021 6:38:21 PM GMT+02:00, Qing Zhao wrote: >Hi, Richard, > >Thanks a lot for you review. > >Although these comments are not made on the latest patch (7th version) :-), >all the comments are valid since the parts you commented >are not changed in the 7th version. I actually reviewed

Re: [patch][version 6] add -ftrivial-auto-var-init and variable attribute "uninitialized" to gcc

Hi, Richard, Thanks a lot for you review. Although these comments are not made on the latest patch (7th version) :-), all the comments are valid since the parts you commented are not changed in the 7th version. > On Aug 9, 2021, at 9:09 AM, Richard Biener wrote: > > On Tue, 27 Jul 2021, Qing

Re: [ARM] PR98435: Missed optimization in expanding vector constructor

On Mon, Aug 9, 2021 at 7:07 AM Prathamesh Kulkarni < prathamesh.kulka...@linaro.org> wrote: > On Fri, 6 Aug 2021 at 17:31, Christophe Lyon > wrote: > > > > > > > > On Fri, Aug 6, 2021 at 11:51 AM Prathamesh Kulkarni < > prathamesh.kulka...@linaro.org> wrote: > >> > >> On Fri, 6 Aug 2021 at 14:49,

Re: [r12-2789 Regression] FAIL: gcc.dg/tree-ssa/gen-vect-11b.c scan-tree-dump-times vect "vectorized 0 loops" 1 on Linux/x86_64

On Sun, Aug 8, 2021 at 12:58 AM Jeff Law via Gcc-patches < gcc-patches@gcc.gnu.org> wrote: > > > On 8/6/2021 11:24 PM, Jeff Law wrote: > > > > > > On 8/6/2021 2:59 PM, sunil.k.pandey via Gcc-patches wrote: > >> On Linux/x86_64, > >> > >> f31da42e047e8018ca6ad9809273bc7efb6ffcaf is the first bad co

Re: [PATCH] gcov: Add -fprofile-update=force-atomic

On 09/08/2021 10:00, Sebastian Huber wrote: If get_gcov_type() returns a 64-bit type, then 64-bit atomic operations in hardware are required for the "atomic" method. Add a new method to force atomic operations even if a library implementation (libatomic) must be used. gcc/ * common.opt

Re: [PATCH v2] x86: Optimize load of const all 1s float vectors

On Mon, Aug 9, 2021 at 5:24 PM H.J. Lu wrote: > > On Sun, Aug 8, 2021 at 1:23 PM Uros Bizjak wrote: > > > > On Sat, Aug 7, 2021 at 4:41 PM H.J. Lu wrote: > > > > > > Update vector_all_ones_operand to return true for const all 1s float > > > vectors. > > > > > > gcc/ > > > > > > PR target

[PATCH v2] x86: Optimize load of const all 1s float vectors

On Sun, Aug 8, 2021 at 1:23 PM Uros Bizjak wrote: > > On Sat, Aug 7, 2021 at 4:41 PM H.J. Lu wrote: > > > > Update vector_all_ones_operand to return true for const all 1s float > > vectors. > > > > gcc/ > > > > PR target/101804 > > * config/i386/predicates.md (vector_all_ones_oper

Re: [PATCH] diagnose more new/delete mismatches (PR 101791)

On 8/5/2021 4:02 PM, Martin Sebor via Gcc-patches wrote: -Wmismatched-new-delete partly relies on valid_new_delete_pair_p() to detect matching calls to operator new and delete.  The function returns a conservative result which, when indicating a mismatch, the warning then works to make more ac

Re: Warn for reads from write-only arguments [PR101734]

On 8/2/2021 3:44 PM, Martin Sebor via Gcc-patches wrote: The write_only mode to attribute access specifies that the pointer applies to is used to write to the referenced object but not read from it. A function that uses the pointer to read the referenced object might rely on the contents of

Re: trunk -D_GLIBCXX_DEBUG #include fails

On Mon, 9 Aug 2021 at 15:27, Jonathan Wakely wrote: > > On Mon, 9 Aug 2021 at 13:05, François Dumont via Libstdc++ > wrote: > > > > On 09/08/21 12:05 pm, Jonathan Wakely via Libstdc++ wrote: > > > On Mon, 9 Aug 2021 at 10:51, Stephan Bergmann via Libstdc++ > > > wrote: > > >> Not sure why I start

[PATCH] i386: Name V2SF logic insns [PR101812]

Name V2SF logic insns, so expand_simple_binop works with V2SF modes. 2021-08-09 Uroš Bizjak gcc/ PR target/101812 * config/i386/mmx.md (v2sf3): Rename from *mmx_v2sf3 gcc/testsuite/ PR target/101812 * gcc.target/i386/pr101812.c: New test. Bootstrapped and regression teste

Re: [PATCH 2/2] Ada: Remove debug line number for DECL_IGNORED_P functions

> But it is okay that we can set a breakpoint on defs__struct1IP, > in the test case of PR 101598. > And the debugger shall only show assembler here. > Right? The defs__struct1IP procedure should be totally transparent for the user, so setting a breakpoint in it is not supposed to come into play.

Re: [wwwdocs] gcc-12/changes.html (GCN): >1 workers per gang

Hi! On 2021-08-09T15:55:07+0200, Tobias Burnus wrote: > Now that the GCN/OpenACC patches for this have been committed today, > I think it makes sense to add it to the documentation. Thanks for thinking of this. > (I was told that some follow-up items are still pending, but as > the feature does

Re: [PATCH] Avoid allocator operator== in _Safe_container

On Mon, 9 Aug 2021 at 13:08, François Dumont wrote: > > On 09/08/21 1:52 pm, François Dumont wrote: > > On 09/08/21 12:45 pm, Jonathan Wakely wrote: > >> On Mon, 9 Aug 2021 at 11:34, Jonathan Wakely wrote: > >>> On Mon, 9 Aug 2021 at 11:33, Jonathan Wakely wrote: > On Mon, 9 Aug 2021 at 11:26

Re-unify 'omp_build_component_ref' and 'oacc_build_component_ref'

[from internal] Hi! This concerns a class of ICEs seen as of og10 branch with the "openacc: Middle-end worker-partitioning support" and "amdgcn: Enable OpenACC worker partitioning for AMD GCN" changes applied: On 2020-06-06T16:07:36+0100, Kwok Cheung Yeung wrote: > On 01/06/2020 8:48 pm, Kwok

Re: [PATCH] Fix ICE when mixing VLAs and statement expressions [PR91038]

Am Montag, den 09.08.2021, 15:52 +0200 schrieb Eric Botcazou: > > I think the patch makes sense but the comment says > > > > Java requires that we elaborated nodes in source order. That > > means we must gimplify the inner expression followed by each > > of > > the indices, in o

Re: [patch][version 6] add -ftrivial-auto-var-init and variable attribute "uninitialized" to gcc

On Tue, 27 Jul 2021, Qing Zhao wrote: > Hi, > > This is the 6th version of the patch for the new security feature for GCC. > > I have tested it with bootstrap on both x86 and aarch64, regression testing > on both x86 and aarch64. > Also compile CPU2017 (running is ongoing), without any issue. (

[PATCH] gcov: Add GCOV_TYPE_SIZE target macro

If -fprofile-update=atomic is used, then the target must provide atomic operations for the counters of the type returned by get_gcov_type(). This is a 64-bit type for targets which have a 64-bit long long type. On 32-bit targets this could be an issue since they may not provide 64-bit atomic operat

[wwwdocs] gcc-12/changes.html (GCN): >1 workers per gang

Now that the GCN/OpenACC patches for this have been committed today, I think it makes sense to add it to the documentation. (I was told that some follow-up items are still pending, but as the feature does work ...) Cf. also Andrew's talk of last year, https://linuxplumbersconf.org/event/7/contrib

Re: [PATCH] Fix ICE when mixing VLAs and statement expressions [PR91038]

> I think the patch makes sense but the comment says > > Java requires that we elaborated nodes in source order. That > means we must gimplify the inner expression followed by each of > the indices, in order. But we can't gimplify the inner > expression until we deal with any

Re [PATCH] Fix ICE when mixing VLAs and statement expressions [PR91038]

Am Montag, den 02.08.2021, 16:19 +0200 schrieb Martin Uecker: > > Am Montag, den 02.08.2021, 16:05 +0200 schrieb Martin Uecker: > > > On Sun, Aug 1, 2021 at 7:37 PM Uecker, Martin > > > wrote: > > > > > > > > Here is an attempt to fix some old and annoying bugs related > > > > to VLAs and statem

Re: Re: [PATCH] Fix ICE when mixing VLAs and statement expressions [PR91038]

Am Montag, den 02.08.2021, 16:05 +0200 schrieb Martin Uecker: > > On Sun, Aug 1, 2021 at 7:37 PM Uecker, Martin > > wrote: > > > > > > > > > Here is an attempt to fix some old and annoying bugs related > > > to VLAs and statement expressions. In particulary, this seems > > > to fix the issues

Re: [PATCH 1/4] openacc: Middle-end worker-partitioning support

Hi! On 2021-08-06T10:25:22+0100, Julian Brown wrote: > On Wed, 4 Aug 2021 15:56:49 +0200 > Thomas Schwinge wrote: >> a nontrivial amount of data structures/logic/code did get >> duplicated from the nvptx back end, and modified slightly or >> not-so-slightly (RTL vs. GIMPLE plus certain implement

Re: [PATCH] Port GCC documentation to Sphinx

On 7/13/21 4:54 PM, Tamar Christina wrote: Hi Martin, -Original Message- From: Gcc-patches On Behalf Of Martin Liška Sent: Tuesday, June 29, 2021 11:09 AM To: Joseph Myers Cc: GCC Development ; gcc-patches@gcc.gnu.org Subject: Re: [PATCH] Port GCC documentation to Sphinx On 6/28/21 5

Re: [PATCH 3/4] amdgcn: Enable OpenACC worker partitioning for AMD GCN

Hi! On 2021-03-02T04:20:13-0800, Julian Brown wrote: > This patch enables worker-partitioning support via gimple rewriting for > AMD GCN. Thanks! > Older (and currently unused) parts of this support are already > present in the AMD GCN backend: those vestigial parts are enabled or > updated, as

Re: [PATCH 1/4] openacc: Middle-end worker-partitioning support

Hi! On 2021-03-02T04:20:11-0800, Julian Brown wrote: > This patch implements worker-partitioning support in the middle end, > by rewriting gimple. [...] Thanks! > The OpenACC execution model requires that code > can run in either "worker single" mode where only a single worker per > gang is ac

Re: Re: [PATCH] Fix ICE when mixing VLAs and statement expressions [PR91038]

On Tue, Aug 3, 2021 at 9:31 PM Martin Uecker wrote: > > Am Dienstag, den 03.08.2021, 11:26 +0200 schrieb Richard Biener: > > On Tue, Aug 3, 2021 at 10:28 AM Martin Uecker wrote: > > > > > > Does the same issue arise with writing the testcases as > > > > ({ ... }) + i; > > > > ? How can we fix i

[PATCH] tree-optimization/101801 - rework generic vector vectorization more

This builds ontop of the vect_worthwhile_without_simd_p refactoring done earlier. It was wrong in dropping the appearant double checks for operation support since the optab check can happen with an integer vector emulation mode and thus succeed but vector lowering might not actually support the op

Re: Re: [PATCH] Fix ICE when mixing VLAs and statement expressions [PR91038]

> On Sun, Aug 1, 2021 at 7:37 PM Uecker, Martin > wrote: > > > > > > > > Here is an attempt to fix some old and annoying bugs related > > to VLAs and statement expressions. In particulary, this seems > > to fix the issues with variably-modified types which are > > returned from statement expressio

[PATCH] ipa: Fix testsuite/gcc.dg/ipa/remref-6.c

Hi, I forgot to add -fdump-ipa-inline to options of testsuite/gcc.dg/ipa/remref-6.c and so the dump scan test were not PASSing but ended up as UNRESOLVED. Fixing that revealed that the one of the dumps it was looking for had a double space, so I removed it too. Tested with make -k check-gcc RU

Re: [PATCH] Port GCC documentation to Sphinx

On 7/12/21 7:18 PM, Martin Sebor wrote: On 6/29/21 4:09 AM, Martin Liška wrote: On 6/28/21 5:33 PM, Joseph Myers wrote: Are formatted manuals (HTML, PDF, man, info) corresponding to this patch version also available for review? I've just uploaded them here: https://splichal.eu/gccsphinx-final

Re: [PATCH] Avoid allocator operator== in _Safe_container

On 09/08/21 1:52 pm, François Dumont wrote: On 09/08/21 12:45 pm, Jonathan Wakely wrote: On Mon, 9 Aug 2021 at 11:34, Jonathan Wakely wrote: On Mon, 9 Aug 2021 at 11:33, Jonathan Wakely wrote: On Mon, 9 Aug 2021 at 11:26, François Dumont via Libstdc++ wrote: Some newly introduced tests in 23

Re: [PATCH] Avoid allocator operator== in _Safe_container

On 09/08/21 12:45 pm, Jonathan Wakely wrote: On Mon, 9 Aug 2021 at 11:34, Jonathan Wakely wrote: On Mon, 9 Aug 2021 at 11:33, Jonathan Wakely wrote: On Mon, 9 Aug 2021 at 11:26, François Dumont via Libstdc++ wrote: Some newly introduced tests in 23_containers/unordered_map/cons/default.cc rev

Re: [1/3] OpenACC reductions

Hi! On 2015-11-02T11:18:37-0500, Nathan Sidwell wrote: > This is the core execution bits of OpenACC reductions. > > We have a new internal fn 'IFN_GOACC_REDUCTION' and a new target hook > goacc.reduction, to lower it on the target compiler. Yay for proper abstraction! Long ago committed in r229

Re: [PATCH v4 15/20] remove explicit dependencies

Hi! On 2013-09-23T08:11:55-0600, Tom Tromey wrote: > This removes most of the explicit dependencies for host objects. Yay for automating this! > --- a/gcc/Makefile.in > +++ b/gcc/Makefile.in > -trans-mem.o : [...] \ > - gt-trans-mem.h Etc. As obvious, pushed '[documentation] No need anym

Re: Minor doc updates.

Hi! On 2002-07-29T16:48:45-0700, Geoffrey Keating wrote: > - Some improvements to the GTY documentation Yay for documentation! > --- doc/gty.texi 27 Jul 2002 20:54:52 - 1.5 > +++ doc/gty.texi 29 Jul 2002 23:47:39 - > +For source files that aren't header files, the machin

[PATCH] Adjust volatile handling of the operand scanner

The GIMPLE SSA operand scanner handles COMPONENT_REFs that are not marked TREE_THIS_VOLATILE but have a TREE_THIS_VOLATILE FIELD_DECL as volatile. That's inconsistent in how TREE_THIS_VOLATILE testing on GENERIC refs works which requires operand zero of component references to mirror TREE_THIS_VOL

Re: [ARM] PR66791: Replace builtins for fp and unsigned vmul_n intrinsics

On Tue, 3 Aug 2021 at 18:23, Christophe Lyon wrote: > > > > On Mon, Jul 19, 2021 at 2:34 PM Prathamesh Kulkarni > wrote: >> >> On Thu, 15 Jul 2021 at 16:46, Prathamesh Kulkarni >> wrote: >> > >> > On Thu, 15 Jul 2021 at 14:47, Christophe Lyon >> > wrote: >> > > >> > > Hi Prathamesh, >> > > >>

Re: [PATCH] gcov: Add -fprofile-update=force-atomic

On 09/08/2021 12:19, Richard Biener wrote: On Mon, Aug 9, 2021 at 10:01 AM Sebastian Huber wrote: If get_gcov_type() returns a 64-bit type, then 64-bit atomic operations in hardware are required for the "atomic" method. Add a new method to force atomic operations even if a library implemen

Re: [PATCH 3/3] [PR libfortran/101305] Fix ISO_Fortran_binding.h paths in gfortran testsuite

Hi Andreas, On 04.08.21 11:00, Andreas Schwab wrote: On Jul 13 2021, Sandra Loosemore wrote: -#include "../../../libgfortran/ISO_Fortran_binding.h" +#include "ISO_Fortran_binding.h" Shouldn't that use since that is an installed header, not one that is supposed to be picked up from the current

committed – Re: [Patch] testsuite/lib/gfortran.exp: Add -I for ISO*.h [PR101305, PR101660] (was: Re: [Patch] gfortran.dg/dg.exp: Add libgfortran as -I flag for ISO*.h [PR101305] (was: [PATCH 3/3] [PR

Now committed as obvious as https://gcc.gnu.org/r12-2808-g527a1cf32c27a3fbeaf6be7596241570d864cc4c Follow-up suggestions are welcome. To recap, it changes three things: * In the testcases, update "..." to "<...>" for the include * -I $specpath/libgfortran - to find the .h file in the build dir

[PATCH] [i386] Support cond_ashr/lshr/ashl for vector integer modes under AVX512.

Hi: Boostrapped and regtested on x86_64-linux-gnu{-m32,}. gcc/ChangeLog: * config/i386/sse.md (cond_): New expander. (VI248_AVX512VLBW): New mode iterator. * config/i386/predicates.md (nonimmediate_or_const_vec_dup_operand): New predicate. gcc/testsuite/ChangeLo

Re: [PATCH] Avoid allocator operator== in _Safe_container

On Mon, 9 Aug 2021 at 11:34, Jonathan Wakely wrote: > > On Mon, 9 Aug 2021 at 11:33, Jonathan Wakely wrote: > > > > On Mon, 9 Aug 2021 at 11:26, François Dumont via Libstdc++ > > wrote: > > > > > > Some newly introduced tests in > > > 23_containers/unordered_map/cons/default.cc revealed that we ar

Re: [PATCH] Avoid allocator operator== in _Safe_container

On Mon, 9 Aug 2021 at 11:33, Jonathan Wakely wrote: > > On Mon, 9 Aug 2021 at 11:26, François Dumont via Libstdc++ > wrote: > > > > Some newly introduced tests in > > 23_containers/unordered_map/cons/default.cc revealed that we are forcing > > the allocator type to have a operator==. > > All alloc

Re: [PATCH] Avoid allocator operator== in _Safe_container

On Mon, 9 Aug 2021 at 11:26, François Dumont via Libstdc++ wrote: > > Some newly introduced tests in > 23_containers/unordered_map/cons/default.cc revealed that we are forcing > the allocator type to have a operator==. All allocators are required to have operator== so that should not be a problem

Re: [PATCH, libgomp, OpenMP 5.0, OG11, committed] Implement omp_get_device_num

On Mon, 9 Aug 2021 15:16:45 +0800 Chung-Lin Tang wrote: > This commit also effective reverts the one-liner patch by Cesar: > https://gcc.gnu.org/pipermail/gcc-patches/2017-October/484844.html > > (which was still kept in OG11 at > 59ef9fea377db72f198b2bd5a95d5aef58b3f9c4) > > That small patch i

[PATCH] Avoid allocator operator== in _Safe_container

Some newly introduced tests in 23_containers/unordered_map/cons/default.cc revealed that we are forcing the allocator type to have a operator==. It can be avoided by checking allocator_traits::is_always_equal.     libstdc++: [_GLIBCXX_DEBUG] Avoid allocator operator== when always equal    

Re: [PATCH] gcov: Add -fprofile-update=force-atomic

On Mon, Aug 9, 2021 at 10:01 AM Sebastian Huber wrote: > > If get_gcov_type() returns a 64-bit type, then 64-bit atomic operations in > hardware are required for the "atomic" method. Add a new method to force > atomic operations even if a library implementation (libatomic) must be used. I do won

Re: [PATCH] Recognize highpart multiplication during RTL expansion

On Sun, Aug 8, 2021 at 1:40 PM Roger Sayle wrote: > > > Doh! ENOPATCH. This time with attachments... > https://gcc.gnu.org/pipermail/gcc-patches/2021-August/576922.html Note I was originally suggesting to perform the matching on GIMPLE but only in one of the "instruction selection passes". There

Re: [PATCH] Improve handling of unknown sign bit in CCP.

On Sun, Aug 8, 2021 at 12:43 PM Roger Sayle wrote: > > > This middle-end patch implements several related improvements to > tree-ssa's conditional (bit) constant propagation pass. The current > code handling ordered comparisons contains the comment "If the > most significant bits are not known we

Re: trunk -D_GLIBCXX_DEBUG #include fails

On Mon, 9 Aug 2021 at 10:51, Stephan Bergmann via Libstdc++ wrote: > > Not sure why I started to experience this now with a recent > GCC/libstdc++ trunk build: > > > $ cat test.cc > > #include > > > $ gcc/trunk/inst/bin/g++ -D_GLIBCXX_DEBUG -fsyntax-only test.cc > > In file included from > > /ho

Re: [EXTERNAL] Re: [PATCH] tree-optimization: Optimize division followed by multiply [PR95176]

On Sat, Aug 7, 2021 at 12:49 AM Marc Glisse wrote: > > On Fri, 6 Aug 2021, Victor Tong wrote: > > > Thanks for the feedback. Here's the updated pattern: > > > > /* X - (X - Y) --> Y */ > > (simplify > >(minus (convert1? @0) (convert2? (minus@2 (convert3? @@0) @1))) > >(if (ANY_INTEGRAL_T

trunk -D_GLIBCXX_DEBUG #include fails

Not sure why I started to experience this now with a recent GCC/libstdc++ trunk build: $ cat test.cc #include $ gcc/trunk/inst/bin/g++ -D_GLIBCXX_DEBUG -fsyntax-only test.cc In file included from /home/sbergman/gcc/trunk/inst/include/c++/12.0.0/bits/regex_automaton.h:401,

Re: [PATCH] testsuite: aarch64: Fix invalid SVE tests

Jonathan Wright writes: > Hi, > > Some scan-assembler tests for SVE code generation were erroneously > split over multiple lines - meaning they became invalid. This patch > gets the tests working again by putting each test on a single line. > > The extract_[1234].c tests are corrected to expect th

[PATCH] testsuite: aarch64: Fix invalid SVE tests

Hi, Some scan-assembler tests for SVE code generation were erroneously split over multiple lines - meaning they became invalid. This patch gets the tests working again by putting each test on a single line. The extract_[1234].c tests are corrected to expect that extracted 32-bit values are moved

Re: [PATCH] testsuite: aarch64: Fix failing vector structure tests on big-endian

Jonathan Wright writes: > Hi, > > I've corrected the quoting and moved everything on to one line. > > Ok for master? > > Thanks, > Jonathan > > --- > > gcc/testsuite/ChangeLog: > > 2021-08-04 Jonathan Wright > > * gcc.target/aarch64/vector_structure_intrinsics.c: Restrict > test

Re: [PATCH] testsuite: aarch64: Fix failing vector structure tests on big-endian

Hi, I've corrected the quoting and moved everything on to one line. Ok for master? Thanks, Jonathan --- gcc/testsuite/ChangeLog: 2021-08-04  Jonathan Wright   * gcc.target/aarch64/vector_structure_intrinsics.c: Restrict tests to little-endian targets. From: Richard Sandifo

[PATCH] middle-end/101824 - properly handle volatiles in nested fn lowering

When we build the COMPONENT_REF of a formerly volatile local off the FRAME decl we have to make sure to mark the COMPONENT_REF as TREE_THIS_VOLATILE. While the GIMPLE operand scanner looks at the FIELD_DECL this is not how volatile GENERIC refs work. Bootstrap & regtest in progress on x86_64-unkn

Re: [PATCH] Make sure we're playing with integral modes before call extract_integral_bit_field.

On Fri, Aug 6, 2021 at 7:27 PM Richard Biener via Gcc-patches wrote: > > On Fri, Aug 6, 2021 at 11:05 AM Richard Sandiford > wrote: > > > > Richard Biener via Gcc-patches writes: > > > On Fri, Aug 6, 2021 at 5:32 AM liuhongt wrote: > > >> > > >> Hi: > > >> --- > > >> OK, I think sth is amiss he

[PATCH] Improved handling of MULT_EXPR in bit CCP.

This patch allows GCC to constant fold (i | (i<<16)) | ((i<<24) | (i<<8)), where i is an unsigned char, or the equivalent (i*65537) | (i*16777472), to i*16843009. The trick is to teach tree_nonzero_bits which bits may be set in the result of a multiplication by a constant given which bits are pot

Re: [PATCH AArch64]Fix expanding of %w for *extend... pattern

"bin.cheng via Gcc-patches" writes: > Hi, > When playing with std::experimental::simd, I found a bug newly introduced in > AArch64 backend. As commit message describes: > 7 Pattern "*extend2_aarch64" is duplicated > 8 from the corresponding zero_extend pattern, however % needs > 9

[PATCH] gcov: Add -fprofile-update=force-atomic

If get_gcov_type() returns a 64-bit type, then 64-bit atomic operations in hardware are required for the "atomic" method. Add a new method to force atomic operations even if a library implementation (libatomic) must be used. gcc/ * common.opt (fprofile-update): Add force-atomic method.

[PATCH, libgomp, OpenMP 5.0, OG11, committed] Implement omp_get_device_num

The omp_get_device_num patch was merged to devel/omp/gcc-11 (OG11) after testing. Commit was 83177ca9f262b230c892e667ebf685f96a718ec8. This commit also effective reverts the one-liner patch by Cesar: https://gcc.gnu.org/pipermail/gcc-patches/2017-October/484844.html (which was still kept in OG1