On 5/3/21 8:53 AM, Robin Dapp via Gcc-patches wrote:
Hi,
on s390 a warning test fails:
inline int ATTR ((cold, aligned (8)))
finline_hot_noret_align (int);
inline int ATTR ((warn_unused_result))
finline_hot_noret_align (int);
inline int ATTR ((aligned (4)))
finline_hot_noret_align (int);
On Mon, Apr 26, 2021 at 03:21:30PM -0500, acsaw...@linux.ibm.com wrote:
> This patch modifies the function in genfusion.pl for generating
> the logical-logical patterns so that it can also generate the
> add-logical and logical-add patterns which are very similar.
> + $outer_32 = "%2,%3"
This is a new series of patches for the og10 branch to rework how indirect
struct components are handled for offloaded OpenACC code regions. Compared
to the version posted previously here:
https://gcc.gnu.org/pipermail/gcc-patches/2021-May/570058.html
...the patches have been rebased to the cur
It never makes sense for a GOMP_MAP_ATTACH_DETACH mapping to survive
beyond gimplify.c, so this patch rewrites such mappings to GOMP_MAP_ATTACH
or GOMP_MAP_DETACH unconditionally (rather than checking for a list
of types of OpenACC or OpenMP constructs), in cases where it hasn't
otherwise been done
For historical reasons, it seems that extract_base_bit_offset
unnecessarily used two different ways to strip ARRAY_REF/INDIRECT_REF
nodes from component accesses. I verified that the two ways of performing
the operation gave the same results across the whole testsuite (and
several additional benchm
This patch is a second attempt at refactoring struct component mapping
handling for OpenACC/OpenMP during gimplification, after the patch I
posted here:
https://gcc.gnu.org/pipermail/gcc-patches/2018-November/510503.html
And improved here, post-review:
https://gcc.gnu.org/pipermail/gcc-patch
This patch reworks indirect struct handling in gimplify.c (i.e. for
struct components mapped with "mystruct->a[0:n]", "mystruct->b", etc.),
for OpenACC. The key observation leading to these changes was that
component mappings of references-to-structures is already implemented
and working, and indi
On 19/05/21 16:08 -0400, Jason Merrill wrote:
On 5/19/21 4:05 PM, Jonathan Wakely wrote:
On 19/05/21 20:55 +0100, Jonathan Wakely wrote:
On 19/05/21 13:26 -0400, Jason Merrill wrote:
On 5/19/21 12:46 PM, Jonathan Wakely wrote:
On 19/05/21 17:39 +0100, Jonathan Wakely wrote:
Jakub pointed out
On 19/05/21 11:51 -0600, Martin Sebor wrote:
On 5/19/21 10:39 AM, Jonathan Wakely via Gcc-patches wrote:
Jakub pointed out I'd forgotten the spaces before the opening parens
for function calls. The attached patch should fix all those, with no
other changes.
Tested x86_64-linux. OK for trunk?
On 19/05/21 11:51 -0600, Martin Sebor wrote:
On 5/19/21 10:39 AM, Jonathan Wakely via Gcc-patches wrote:
Jakub pointed out I'd forgotten the spaces before the opening parens
for function calls. The attached patch should fix all those, with no
other changes.
Tested x86_64-linux. OK for trunk?
Hi!
On Mon, Apr 26, 2021 at 02:00:36PM -0500, acsaw...@linux.ibm.com wrote:
> This adds some test cases to make sure that the combine patterns for p10
> fusion are working.
> +++ b/gcc/testsuite/gcc.target/powerpc/fusion-p10-2logical.c
> @@ -0,0 +1,205 @@
> +/* { dg-do compile { target { powerpc*
Hi!
On Wed, May 19, 2021 at 08:35:26PM +0200, Tobias Burnus wrote:
> On 19.05.21 17:15, Segher Boessenkool wrote:
> >>real(16) :: y ! 128bit REAL
> >>integer(16), parameter :: k2 = nint (2 / epsilon (y), kind(k2))
> >>integer(16), parameter :: m2 = 103845937170696552570
On Linux/x86_64,
cd67343703ef4fa61de837f4690eba70d2760825 is the first bad commit
commit cd67343703ef4fa61de837f4690eba70d2760825
Author: Jason Merrill
Date: Tue May 18 12:29:33 2021 -0400
c++: ICE with <=> fallback [PR100367]
caused
FAIL: g++.dg/opt/pr94589-2.C -std=gnu++2a scan-tree-
Hello.
This patch adds support to set the link section of global variables.
I used the ABI 18 because I submitted other patches up to 17.
Thanks for the review.
From c867732ee36003759d479497c85135ecfc4a0cf3 Mon Sep 17 00:00:00 2001
From: Antoni Boucher
Date: Wed, 12 May 2021 07:57:54 -0400
Subject
Here the code for 'using enum' is confused by the combination of a
using-decl and an enum that are not from 'using enum'; this CONST_DECL is
from the normal unscoped enum scoping.
Tested x86_64-pc-linux-gnu, applying to trunk.
PR c++/100659
gcc/cp/ChangeLog:
* cp-tree.h (CONST_D
We were crashing because invalid_nontype_parm_type_p allowed _Complex
template parms, but convert_nontype_argument didn't know what to do for
them. Let's just disallow it, people can and should use std::complex
instead.
Tested x86_64-pc-linux-gnu, applying to trunk.
PR c++/100634
gcc/cp
Hello,
can I ask somebody to push the patch to fix the PCH large file problem
(BUG 14940)? The bug fix was sent in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14940#c49
and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14940#c50
I would copy and paste it, but I'm not the author of this patch.
Ev
On 5/19/2021 3:01 PM, Martin Sebor via Gcc-patches wrote:
The front end -Wnonnull handler has code to suppress warning for
lambdas with null this pointers but the middle end handler has
no corresponding logic. This leads to spurious -Wnonnull in
lambda calls that aren't inlined. That might ha
Hi:
In folding target-specific builtin, when lhs is NULL, create a
temporary variable for it.
Bootstrapped and regtested on x86_64-linux-gnu{-m32,}
gcc/ChangeLog:
PR target/100660
* config/i386/i386.c (ix86_gimple_fold_builtin): Create a tmp
variable for lhs when it doe
Hi Tobias,
> @All, Harald: Does the attached patch make sense?
first of all: sorry for the really badly designed testcase.
The best solution has already been discussed in this thread,
which is to replace
integer(16), parameter :: m1 = 9007199254740992_16!2**53
integer(16)
On Wed, May 19, 2021 at 9:05 PM H.J. Lu wrote:
>
> On Wed, May 19, 2021 at 6:27 AM Bernd Edlinger
> wrote:
> >
> > On 5/19/21 3:22 PM, H.J. Lu wrote:
> > > On Wed, May 19, 2021 at 2:33 AM Richard Biener
> > > wrote:
> > >>
> > >> On Tue, May 18, 2021 at 9:16 PM H.J. Lu wrote:
> > >>>
> > >>> Wh
Hi!
For unprototyped builtins the checking we perform is only about whether
the used argument is integral, pointer etc., not the exact precision.
We emit a warning about the problem though:
pr100576.c: In function ‘foo’:
pr100576.c:9:11: warning: implicit declaration of function ‘memcmp’
[-Wimpli
On Wed, 19 May 2021, Jakub Jelinek wrote:
> Hi!
>
> For unprototyped builtins the checking we perform is only about whether
> the used argument is integral, pointer etc., not the exact precision.
> We emit a warning about the problem though:
> pr100576.c: In function ‘foo’:
> pr100576.c:9:11: war
Hi!
This patch deals with 2 issues:
1) the gimplifier couldn't differentiate between
#pragma omp parallel master
#pragma omp taskloop simd
and
#pragma omp parallel master taskloop simd
when there is a significant difference for clause handling between
the two; as master construct doesn't have a
Hi!
As can be seen on the testcases, before the -fdirectives-only preprocessing
rewrite the preprocessor would assume // comments are terminated by the
end of file even when newline wasn't there, but now we error out.
The following patch restores the previous behavior.
Bootstrapped/regtested on x
Allow V8QI, V4HI and V2SI modes in 64bit general registers for
TARGET_64BIT and add alternatives using general registers
to 64bit vector logic instructions.
2021-05-19 Uroš Bizjak
gcc/
* config/i386/i386.h (VALID_INT_MODE_P):
Add V8QI, V4HI and V2SI modes for TARGET_64BIT.
* config
On 5/18/21 12:34 PM, Richard Biener wrote:
> On Tue, 18 May 2021, Xionghu Luo wrote:
>
>> Hi,
>>
>> On 2021/5/18 15:02, Richard Biener wrote:
>>> Can you, for the new gcc.dg/tree-ssa/ssa-sink-18.c testcase, add
>>> a comment explaining what operations we expect to sink? The testcase
>>> is likely
Status
==
The GCC 9 branch is now frozen for the upcoming GCC 9.4 release.
I will announce a first release candidate shortly.
All changes require release manager approval now.
Quality Data
Priority # Change from last report
--- --
101 - 128 of 128 matches
Mail list logo
