On 3/18/22 14:47, Jakub Jelinek wrote:
On Fri, Mar 18, 2022 at 02:27:30PM -0400, Jason Merrill wrote:
That is also correct C++ expression, but user probably has no idea what is
present at offset 32 into the variable.
Of course if there is a type match and not any kind of type punning,
it will tr
On Linux/x86_64,
c7a6a32739d62deab03266e2b5449fce261b1ecb is the first bad commit
commit c7a6a32739d62deab03266e2b5449fce261b1ecb
Author: Marek Polacek
Date: Wed Mar 16 09:34:34 2022 -0400
c++: alias template and empty parameter packs [PR104008]
caused
FAIL: g++.dg/cpp0x/variadic-alias3.
Hi,
For complex scalar intrinsic like _mm_mask_fcmadd_sch, the
mask should be and by 1 to ensure the mask is bind to lowest byte.
Bootstraped/regtested on x86_64-pc-linux-gnu{-m32,} and sde.
Ok for master?
gcc/ChangeLog:
PR target/104978
* config/i386/sse.md
(avx512fp16
Hi,
This patch fixes typo in subst for scalar complex mask_round operand.
Bootstraped/regtested on x86_64-pc-linux-gnu{-m32,} and sde.
Ok for master?
gcc/ChangeLog:
PR target/104977
* config/i386/sse.md
(avx512fp16_fmash_v8hf):
Correct round operand for intel
The existing analyzer code attempts to purge the state of SSA names
where it can in order to minimize the size of program_state instances,
and to increase the chances of being able to reuse exploded_node
instances whilst exploring the user's code.
PR analyzer/104943 identifies that we fail to purg
This patch adds various regression tests as preparatory work for
purging irrelevant local decls from state (PR analyzer/104943)
Tested on x86_64-pc-linux-gnu.
Pushed to trunk as r12-7717-g1c1daca1cdf7bc0156d57bb2b9083ee70c66b000.
gcc/testsuite/ChangeLog:
PR analyzer/104943
* gcc.d
On 3/18/2022 12:06 PM, Tom Tromey via Gcc-patches wrote:
The top-level configure options --with-gmp-dir and --with-mpfr-dir
were obsoleted and marked as "REMOVED" back in 2006. I think that's
long enough ago for everyone to have updated their scripts, so this
patch removes them entirely. Whi
On Fri, Mar 11, 2022 at 06:46:42PM -0500, Jason Merrill wrote:
> On 3/10/22 18:04, Marek Polacek wrote:
> > Since r9-6073 cxx_eval_store_expression preevaluates the value to
> > be stored, and that revealed a crash where a template code (here,
> > code=IMPLICIT_CONV_EXPR) leaks into cxx_eval*.
> >
On 3/16/22 7:33 AM, Segher Boessenkool wrote:
> On Tue, Mar 15, 2022 at 02:49:39PM -0500, Peter Bergner wrote:
>> The trunk patch has been confirmed to fix the glibc build errors and no
>> issues
>> with the patch has surfaced, so ok for the GCC11 and GCC10 release branches?
>
> If you can confir
> On Mar 18, 2022, at 11:09 AM, Richard Sandiford
> wrote:
>
> Xi Ruoyao writes:
>>>
>>> If we have to go this way, I think it’s better to make the change you
>>> suggested above,
>>> and then also update the documentation, both internal documentation on
>>> how to define
>>> the hook and
On Fri, Mar 18, 2022 at 02:27:30PM -0400, Jason Merrill wrote:
> > That is also correct C++ expression, but user probably has no idea what is
> > present at offset 32 into the variable.
> > Of course if there is a type match and not any kind of type punning,
> > it will try to print much shorter an
On Fri, Mar 18, 2022 at 5:01 PM Jeff Law wrote:
>
>
>
> On 3/18/2022 7:16 AM, Andrew MacLeod wrote:
> > On 3/17/22 19:27, Jeff Law via Gcc-patches wrote:
> >>
> >> On 3/15/2022 2:03 AM, Roger Sayle wrote:
> -Original Message-
> From: Richard Biener
> Sent: 15 March 2022 07:
On 3/18/22 14:20, Jakub Jelinek wrote:
On Fri, Mar 18, 2022 at 01:35:53PM -0400, Jason Merrill wrote:
On 3/15/22 12:06, Jakub Jelinek wrote:
On Tue, Mar 15, 2022 at 11:57:22AM -0400, Jason Merrill wrote:
The intent of r11-6729 is that it prints something that helps user to figure
out what exac
The following patch fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104961
The patch was successfully bootstrapped and tested on x86-64.
commit 4e2291789a8b31c550271405782356e8aeddcee3
Author: Vladimir N. Makarov
Date: Fri Mar 18 14:23:40 2022 -0400
[PR104961] LRA: split hard reg for
On Fri, Mar 18, 2022 at 01:35:53PM -0400, Jason Merrill wrote:
> On 3/15/22 12:06, Jakub Jelinek wrote:
> > On Tue, Mar 15, 2022 at 11:57:22AM -0400, Jason Merrill wrote:
> > > > The intent of r11-6729 is that it prints something that helps user to
> > > > figure
> > > > out what exactly is being
The problem in both PR92918 and PR104476 is overloading of base member
functions brought in by 'using' with direct member functions during parsing
of the class body. To this point they've had a troublesome coexistence
which was resolved by set_class_bindings when the class is complete, but we
also
On Fri, Mar 18, 2022 at 2:07 PM Andrew MacLeod wrote:
>
> On 3/18/22 03:43, Roger Sayle wrote:
> > Hi Jeff/Andrew,
> >> If you're going to do more work in this space, you might want to reach out
> >> to
> >> Aldy and Andrew to see if there's space for collaboration.
> > One (clever?) suggestion t
The top-level configure options --with-gmp-dir and --with-mpfr-dir
were obsoleted and marked as "REMOVED" back in 2006. I think that's
long enough ago for everyone to have updated their scripts, so this
patch removes them entirely. While doing this, I also found one other
leftover that wasn't rem
This fixes a new FAIL caused by my r12-7699 change to libstdc++ headers.
Pushed to trunk as obvious.
-- >8 --
gcc/testsuite/ChangeLog:
* g++.dg/torture/pr104601.C: Include .
---
gcc/testsuite/g++.dg/torture/pr104601.C | 1 +
1 file changed, 1 insertion(+)
diff --git a/gcc/testsuite/g+
> Am 18.03.2022 um 18:01 schrieb Jakub Jelinek via Gcc-patches
> :
>
> Hi!
>
> Starting with GCC11 we keep emitting false positive -Warray-bounds or
> -Wstringop-overflow etc. warnings on widely used *(type *)0x12345000
> style accesses (or memory/string routines to such pointers).
> This is
On 3/15/22 12:06, Jakub Jelinek wrote:
On Tue, Mar 15, 2022 at 11:57:22AM -0400, Jason Merrill wrote:
The intent of r11-6729 is that it prints something that helps user to figure
out what exactly is being accessed.
When we find a unique non-static data member that is being accessed, even
when we
On Linux/x86_64,
ac73c944eac88f37db2767aa4acc7ff6f4983f21 is the first bad commit
commit ac73c944eac88f37db2767aa4acc7ff6f4983f21
Author: Jonathan Wakely
Date: Thu Mar 17 16:45:43 2022 +
libstdc++: Reduce header dependencies from PSTL headers [PR92546]
caused
FAIL: g++.dg/torture/pr1
Hi!
Starting with GCC11 we keep emitting false positive -Warray-bounds or
-Wstringop-overflow etc. warnings on widely used *(type *)0x12345000
style accesses (or memory/string routines to such pointers).
This is a standard programming style supported by all C/C++ compilers
I've ever tried, used mo
On 3/16/22 12:55, Jakub Jelinek wrote:
On Tue, Mar 15, 2022 at 04:19:05PM -0400, Jason Merrill wrote:
But if you strongly prefer it that way, I can do that.
Note, probably not 3 new args but 4, depends on whether we could turn
all those cases where the tree arg0 = CALL_EXPR_ARG (oldop, 0);
is do
On 3/16/22 17:18, Marek Polacek wrote:
Zero-length pack expansions are treated as if no list were provided
at all, that is, with
template struct S { };
template
void g() {
S...>;
}
g will result in S<>. In the following test we have something
similar:
template
using Is
On Fri, Mar 18, 2022 at 05:27:02PM +0100, Tobias Burnus wrote:
> SELECT TYPE, SELECT RANK and ASSOCIATE have
> associate-name => selector
> and create a pointer to the selector.
>
> GCC was fixed to handle CLASS properly in
> class(t) :: var
> !$omp ... firstprivate(var)
> As a side effect,
This patch adds support for "declare mapper" directives (and the "mapper"
modifier on "map" clauses) for C. As for C++, arrays of custom-mapped
objects are not supported yet.
I've taken hints from the existing C support for "declare reduction"
directives: this works a little differently from C++
This patch uses the new OMP_ARRAY_SECTION tree code to represent OpenMP
array sections, rather than TREE_LIST. As for the C++ FE, using TREE_LIST
becomes unwieldy when the array-section representation sticks around
for longer due to adding "declare mapper" support.
We must be a little careful her
This patch implements OpenMP 5.0 "declare mapper" support for C++ --
except for arrays of structs with mappers, which are TBD. I've taken cues
from the existing "declare reduction" support where appropriate, though
obviously the details of implementation differ somewhat (in particular,
"declare map
SELECT TYPE, SELECT RANK and ASSOCIATE have
associate-name => selector
and create a pointer to the selector.
GCC was fixed to handle CLASS properly in
class(t) :: var
!$omp ... firstprivate(var)
As a side effect, firstprivate(assoc_name) now also gets
handled that way, effectively trying to
This patch changes the representation of OMP array sections in the
C++ front end to use the new OMP_ARRAY_SECTION tree code instead of a
TREE_LIST. This is important for "declare mapper" support, because the
array section representation may stick around longer (in "declare mapper"
definitions), an
This patch adds support for parsing general lvalues for OpenMP "map"
clauses to the C front-end, similar to the previous patch for C++.
This version of the patch has been adjusted for changes to the address
inspector patch, but is otherwise the same as the last posted version.
2022-03-17 Julian
This patch changes parsing for OpenMP map clauses in C++ to use the
generic expression parser, hence adds support for parsing general
lvalues (as required by OpenMP 5.0+). So far only a few new types of
expression are actually supported throughout compilation (including
everything in the testsuite
This patch relates to OpenMP mapping clauses containing struct members of
reference type, e.g. "mystruct.myref.myptr[:N]". To be able to access
the array slice through the reference in the middle, we need to perform
an attach action for that reference, since it is represented internally
as a point
Several places in the C and C++ front-ends dig through OpenMP and OpenACC
addresses from "map" clauses (etc.) in order to determine whether they
are component accesses that need "attach" operations, check duplicate
mapping clauses, and so on. When we're extending support for more kinds
of lvalues
This patch is a combination of several previously-posted patches,
rebased and squashed together, and with a couple of additional bugfixes:
"Rewrite GOMP_MAP_ATTACH_DETACH mappings unconditionally"
https://gcc.gnu.org/pipermail/gcc-patches/2021-November/585440.html
"OpenMP/OpenACC: Move array_ref/
This patch reimplements the omp_target_reorder_clauses function in
anticipation of supporting "deeper" struct mappings (that is, with
several structure dereference operators, or similar).
The idea is that in place of the (possibly quadratic) algorithm in
omp_target_reorder_clauses that greedily mo
This patch has been split out from the previous one to avoid a
confusingly-interleaved diff. The two patches should probably be
committed squashed together.
2021-10-01 Julian Brown
gcc/
* gimplify.c (omp_target_reorder_clauses): Delete.
---
gcc/gimplify.cc | 207 -
Hi Jakub,
This is a new version of the series posted here:
https://gcc.gnu.org/pipermail/gcc-patches/2022-February/590582.html
Again, this isn't for committing now (it's definitely stage 1 material)
but I'm posting now for comments on the general approach (to any of the
contained parts) and to
Richard Biener writes:
> The following arranges for the GIMPLE frontend to parse an
> additional loops(...) specification, currently consisting of
> 'normal' and 'lcssa'. The intent is to allow unit testing
> of passes inside the GIMPLE loop optimization pipeline where
> we keep the IL in loop-cl
Xi Ruoyao writes:
>>
>> If we have to go this way, I think it’s better to make the change you
>> suggested above,
>> and then also update the documentation, both internal documentation on
>> how to define
>> the hook and the user level documentation on what the user might
>> expect when using
On 3/18/2022 7:16 AM, Andrew MacLeod wrote:
On 3/17/22 19:27, Jeff Law via Gcc-patches wrote:
On 3/15/2022 2:03 AM, Roger Sayle wrote:
-Original Message-
From: Richard Biener
Sent: 15 March 2022 07:29
To: Roger Sayle
Cc: GCC Patches
Subject: Re: [PATCH] Ignore (possible) signed z
Oops, I meant to change the commit summary line to Un-simplify, since
it was reverting the "Simplify constaints ..." commit.
On Fri, 18 Mar 2022 at 15:43, Jonathan Wakely via Libstdc++
wrote:
>
> Tested powerpc64le-linux, pushed to trunk,
>
> -- >8 --
>
> Partially revert r12-4190-g6da36b7d0e43b
Tested powerpc64le-linux, pushed to trunk,
-- >8 --
Partially revert r12-4190-g6da36b7d0e43b6f9281c65c19a025d4888a25b2d
because using __and_<..., is_copy_constructible> when T is incomplete
results in an error about deriving from is_copy_constructible when
that is incomplete. I don't know how to
Darwin versions <= 10 (macOS 10.6) emit different diagnostics for the failure
case being tested by bad-mapper-1.C. Adjust the dg- expressions to reflect
this.
tested on powerpc,i686-darwin9, x86-64-darwin10,17,20
powerpc64le,powerpc64,x86_64-linux-gnu,
pushed to master, thanks
Iain
Signed-off-
On 3/18/22 15:56, Jakub Jelinek wrote:
On Fri, Mar 18, 2022 at 03:42:48PM +0100, Tom de Vries wrote:
And for NVPTX we somehow lower the taskloop into GIMPLE_ASM
or how we end up ICEing?
In the nvptx backend, gen_comment (triggering not very frequently atm) uses
gen_rtx_ASM_INPUT_loc with as l
On Fri, Mar 18, 2022 at 03:42:48PM +0100, Tom de Vries wrote:
> > And for NVPTX we somehow lower the taskloop into GIMPLE_ASM
> > or how we end up ICEing?
> >
>
> In the nvptx backend, gen_comment (triggering not very frequently atm) uses
> gen_rtx_ASM_INPUT_loc with as location argument DECL_SOU
Hi,
Consider test-case pr104952-1.c, included in this commit, containing:
...
#pragma omp target map(tofrom:result) map(to:arr)
#pragma omp simd reduction(||: result)
...
When run on x86_64 with nvptx accelerator, the test-case either aborts or
hangs.
The reduction clause is translated by th
On 3/18/22 14:01, Jakub Jelinek wrote:
On Fri, Mar 18, 2022 at 01:44:00PM +0100, Tom de Vries wrote:
The test-case included in this patch contains:
...
#pragma omp taskloop simd shared(a) lastprivate(myId)
...
This is translated to 3 taskloop statements in gimple, visible with
-fdump-tree-gi
On Fri, Mar 18, 2022 at 02:15:11PM +0100, Tobias Burnus wrote:
> This patch addresses a side issue found when looking at PR103039.
>
> Namely instead of printing:
>
>55 | !$omp parallel firstprivate(tt)
> | 1
> Error: ASSOCIATE name ‘__tmp_INTEGER_4’ in FI
On 3/17/22 19:27, Jeff Law via Gcc-patches wrote:
On 3/15/2022 2:03 AM, Roger Sayle wrote:
-Original Message-
From: Richard Biener
Sent: 15 March 2022 07:29
To: Roger Sayle
Cc: GCC Patches
Subject: Re: [PATCH] Ignore (possible) signed zeros in operands of FP
comparisons.
On Mon, Mar
This patch addresses a side issue found when looking at PR103039.
Namely instead of printing:
55 | !$omp parallel firstprivate(tt)
| 1
Error: ASSOCIATE name ‘__tmp_INTEGER_4’ in FIRSTPRIVATE clause at (1)
With the patch, the error is:
Error: Associate na
>
> If we have to go this way, I think it’s better to make the change you
> suggested above,
> and then also update the documentation, both internal documentation on
> how to define
> the hook and the user level documentation on what the user might
> expect when using
> this option (i.e, it’s
On 3/18/22 03:43, Roger Sayle wrote:
Hi Jeff/Andrew,
If you're going to do more work in this space, you might want to reach out to
Aldy and Andrew to see if there's space for collaboration.
One (clever?) suggestion that I do have for ranger would be to add support for
an additional value_range_
On Fri, Mar 18, 2022 at 01:44:00PM +0100, Tom de Vries wrote:
> The test-case included in this patch contains:
> ...
> #pragma omp taskloop simd shared(a) lastprivate(myId)
> ...
>
> This is translated to 3 taskloop statements in gimple, visible with
> -fdump-tree-gimple:
> ...
> #pragma omp t
On Fri, 18 Mar 2022 at 12:47, Rainer Orth wrote:
>
> Hi Jonathan,
>
> > I did some very brief testing and it seemed like a program linked to
> > the Solaris 11.3 libstdc++.so.6.0.30 (with from_chars@GLIBCXX_3.4.30)
> > can still run against libstdc++.so.6.0.30 with
> > from_chars@GLIBCXX_3.4.29 (wh
Hi Jonathan,
> I did some very brief testing and it seemed like a program linked to
> the Solaris 11.3 libstdc++.so.6.0.30 (with from_chars@GLIBCXX_3.4.30)
> can still run against libstdc++.so.6.0.30 with
> from_chars@GLIBCXX_3.4.29 (which should match what you get on Solaris
> 11.4 if I correctly
Hi,
The test-case included in this patch contains:
...
#pragma omp taskloop simd shared(a) lastprivate(myId)
...
This is translated to 3 taskloop statements in gimple, visible with
-fdump-tree-gimple:
...
#pragma omp taskloop private(D.2124)
#pragma omp taskloop shared(a) shared(myId) pri
On Fri, 18 Mar 2022 at 11:49, Rainer Orth wrote:
>
> Hi Jonathan,
>
> > Tested x86_64-linux and sparc-sun-solaris2.11 (but 11.3 only).
> >
> > Pushed to trunk.
> >
> > Rainer, this should allow you to continue omitting the
> > _ZSt10from_charsPKcS0_R[def]St12chars_format symbols from the baseline,
Hi Jonathan,
> Tested x86_64-linux and sparc-sun-solaris2.11 (but 11.3 only).
>
> Pushed to trunk.
>
> Rainer, this should allow you to continue omitting the
> _ZSt10from_charsPKcS0_R[def]St12chars_format symbols from the baseline,
> without the current FAIL. Please check on your other Solaris tar
On Fri, 18 Mar 2022 at 10:16, Jonathan Wakely wrote:
>
> On Thu, 17 Mar 2022 at 20:44, Thomas Rodgers wrote:
> >
> > Looks ok to me. I just am curious, does the change to src/c++17/fs_path.cc
> > need to be part of this change (It's not obvious to me that it is related
> > to the other changes in
> You meant cbo_zero, right?
> CMO was only the task-group name, but the extensions ended up having "cbo"
> in their name…
Yeah, named with an extension name makes more sense, thank you for
pointing that out.
Either __builtin_riscv_cbo_zero or __builtin_riscv_zicboz_cbo_zero is
fine to me since I
On Fri, Mar 18, 2022 at 9:18 AM liuhongt wrote:
>
> Set attr from HImode to HFmode which uses vmovsh instead of vmovw for
> movment between sse registers.
>
> Bootstrapped and regstested on x86_64-pc-linux-gnu{-m32,}.
> Ok for main trunk?
>
> gcc/ChangeLog:
>
> PR target/104974
> *
On Thu, 17 Mar 2022 at 20:44, Thomas Rodgers wrote:
>
> Looks ok to me. I just am curious, does the change to src/c++17/fs_path.cc
> need to be part of this change (It's not obvious to me that it is related to
> the other changes in the patch).
It's related. fs_path.cc uses std::array but was no
On Fri, Mar 18, 2022 at 7:58 AM Kito Cheng wrote:
> I would suggest rename those __builtin_riscv_* to
> __builtin_riscv_cmo_*, that's less confusing, __builtin_riscv_zero
> just seems like it will return a zero value.
>
You meant cbo_zero, right?
CMO was only the task-group name, but the extens
This patch avoid a warning of "c-ada-spec.cc:1660:34: warning:
'sprintf' may write a terminating nul past the end of the
destination [-Wformat-overflow=]" when build GCC.
gcc/c-family/
* c-ada-spec.cc: Change array length
---
gcc/c-family/c-ada-spec.cc | 2 +-
1 file changed, 1 inserti
Set attr from HImode to HFmode which uses vmovsh instead of vmovw for
movment between sse registers.
Bootstrapped and regstested on x86_64-pc-linux-gnu{-m32,}.
Ok for main trunk?
gcc/ChangeLog:
PR target/104974
* config/i386/i386.md (*movhi_internal): Set attr type from HI
Hi Jeff/Andrew,
> If you're going to do more work in this space, you might want to reach out to
> Aldy and Andrew to see if there's space for collaboration.
One (clever?) suggestion that I do have for ranger would be to add support for
an additional value_range_kind, VR_NONZEROBITS, which would
On Fri, Mar 18, 2022 at 11:32 AM Cui,Lili wrote:
>
> Hi Hongtao,
>
> This patch is to correct march=sapphirerapids to base on icelake server.
> and update sapphirerapids in the documentation.
>
> OK for master and backport to GCC 11?
Ok.
>
>
> gcc/Changelog:
>
> PR target/104963
>
Hi Jakub!
On 2022-03-17T17:16:04+0100, Jakub Jelinek wrote:
> On Thu, Nov 11, 2021 at 02:14:05PM +0100, Thomas Schwinge wrote:
>> There appears to be yet another issue: there still are quite a number of
>> 'FAIL: libgomp.c/places-10.c execution test' reports on
>> . Also in my testing testing, o
70 matches
Mail list logo
