On Tue, 1 Feb 2022, H.J. Lu wrote:
LGTM.
> ---
> htdocs/gcc-12/changes.html | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/htdocs/gcc-12/changes.html b/htdocs/gcc-12/changes.html
> index 2719b9d5..479bd6c5 100644
> --- a/htdocs/gcc-12/changes.html
> +++ b/htdocs/gcc-12/changes.
On code where reload has an effect (i.e. quite rarely, just enough to be
noticeable), this change gets code quality back to the situation prior
to "Remove CRIS v32 ACR artefacts". We had from IRA a pseudoregister
marked to be reloaded from a union of all allocatable registers (here:
SPEC_GENNONACR
When the tightest class including both SPECIAL_REGS and GENERAL_REGS
is ALL_REGS, artificially special-casing for *either* to or from, hits
artificially hard. This gets the port back to the code quality before
the previous patch ("cris: Remove CRIS v32 ACR artefacts") - except
for_vfprintf_r and _
This is the change to which I alluded to this in r11-220 /
d0780379c1b6 as "causes extra register moves in libgcc". It has
unfortunate side-effects due to the change in register-class topology.
There's a slight improvement in coremark numbers (< 0.07%) though also
increase in code size total (< 0.
In a session investigating unexpected fallout from a change, I
noticed reload needs one operand being a register to make an
informed decision. It can happen that there's just a constant
and a memory operand, as in:
(insn 668 667 42 104 (parallel [
(set (mem:SI (plus:SI (reg/v/f:SI 347
On 2/1/22 17:15, Jonathan Wakely wrote:
On Wed, 2 Feb 2022 at 00:13, Martin Sebor wrote:
On 2/1/22 12:48, Jonathan Wakely wrote:
On Tue, 1 Feb 2022 at 18:54, Martin Sebor via Libstdc++
wrote:
Passing an uninitialized object to a function that takes its argument
by const reference is diagno
This flips the default for the errata handling for an old version
(TL;DR: workaround: no multiply instruction last on a cache-line).
Newer versions of the CRIS cpu don't have that bug. While the impact
of the workaround is very marginal (coremark: less than .05% larger,
less than .0005% slower) it
I'm taking advantage of CRIS being a lesser important target and as
such not subject to the constraints of GCC being in stage 4.
I'm applying this set of CRIS-specific changes that don't have much
expected effect on generated code.
1: cris: Don't default to -mmul-bug-workaround
Avoid the workaroun
On Wed, 2 Feb 2022 at 00:13, Martin Sebor wrote:
>
> On 2/1/22 12:48, Jonathan Wakely wrote:
> > On Tue, 1 Feb 2022 at 18:54, Martin Sebor via Libstdc++
> > wrote:
> >>
> >> Passing an uninitialized object to a function that takes its argument
> >> by const reference is diagnosed by -Wmaybe-unini
On 2/1/22 12:48, Jonathan Wakely wrote:
On Tue, 1 Feb 2022 at 18:54, Martin Sebor via Libstdc++
wrote:
Passing an uninitialized object to a function that takes its argument
by const reference is diagnosed by -Wmaybe-uninitialized because most
such functions read the argument. The exceptions a
On Tue, 1 Feb 2022 at 22:00, Jonathan Wakely via Libstdc++
wrote:
>
> The standard requires directory iterators to become equal to the end
> iterator value if they report an error. Some members functions of
> filesystem::recursive_directory_iterator fail to do that.
>
> libstdc++-v3/ChangeLog:
>
>
The attached patch adjusts the placement of the warn-access pass
as the two of you suggested in the bug. Please let me know if
this is good to commit or if you want me to make some other tweaks.
The patch passes tests in an x86_64-linux bootstrap.
MartinPR middle-end/104260 - Misplaced waccess3
From: Andrew Pinski
As reported at
https://gcc.gnu.org/pipermail/gcc/2022-February/238216.html,
multiprecision.org now uses https so this updates the documentation
to use https instead of http.
Committed as obvious.
gcc/ChangeLog:
* doc/install.texi:
---
gcc/doc/install.texi | 2 +-
1
On Fri, Jan 28, 2022 at 11:50:23AM -0600, Bill Schmidt wrote:
> These built-ins were misimplemented as always having big-endian semantics.
> PR target/95082
> * config/rs6000/rs6000-builtin.cc (rs6000_expand_builtin): Handle
> endianness for vclzlsbb and vctzlsbb.
> * confi
Dear Fortranners,
a check in gfc_calculate_transfer_sizes had a bug in the logic:
it did not trigger for MOLD having a storage size zero when
arugment SIZE was present. The attached obvious patch fixes this.
Regtested on x86_64-pc-linux-gnu. OK for mainline/11/10/9?
Thanks,
Harald
From b8f124
On Tue, Feb 01, 2022 at 08:53:52AM -0600, Bill Schmidt wrote:
> As discussed, I simplified this patch by just changing how the error
> message is produced:
>
> We currently give different error messages for built-in functions that
> violate range restrictions on their arguments, depending on wheth
Tested powerpc64le-linux, pushed to trunk.
The PR 97731 test was added to verify a fix to the Filesystem TS code,
but we should also have the same test to avoid similar regressions in
the C++17 std::filesystem code.
Also add tests for directory_options::follow_directory_symlink
libstdc++-v3/Cha
Tested powerpc64le-linux, pushed to trunk.
The standard requires directory iterators to become equal to the end
iterator value if they report an error. Some members functions of
filesystem::recursive_directory_iterator fail to do that.
libstdc++-v3/ChangeLog:
* src/c++17/fs_dir.cc (recu
Tested powerpc64le-linux, pushed to trunk.
libstdc++-v3/ChangeLog:
* include/bits/fs_fwd.h (filesystem::perms): Fix comment.
---
libstdc++-v3/include/bits/fs_fwd.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libstdc++-v3/include/bits/fs_fwd.h
b/libstdc++-v3/incl
Tested powerpc64le-linux, pushed to trunk.
Currently we just print "checking for underlying I/O to use... stdio"
unconditionally, whether configured to use stdio_pure or stdio_posix. We
should make it clear that the user's configure option chose the right
thing.
libstdc++-v3/ChangeLog:
On Tue, Feb 01, 2022 at 08:49:34AM -0600, Bill Schmidt wrote:
> I've modified the previous patch to add more explanatory commentary about
> the number-of-arguments test that was previously confusing, and to convert
> the switch into an if-then-else chain. The rest of the patch is unchanged.
> Boot
On 2/1/22 21:49, Ilya Leoshkevich wrote:
> Bootstrapped and regtested on s390x-redhat-linux. Ok for master?
>
>
> s390_code_end () puts indirect branch tables into separate sections and
> tries to switch back to wherever it was in the beginning by calling
> switch_to_section (current_function_se
Bootstrapped and regtested on s390x-redhat-linux. Ok for master?
s390_code_end () puts indirect branch tables into separate sections and
tries to switch back to wherever it was in the beginning by calling
switch_to_section (current_function_section ()).
First of all, this is unnecessary - the o
Dear all,
another trivial and obvious one, discovered by Gerhard.
We can have a NULL pointer dereference simplifying EOSHIFT on an array
that was not properly declared.
Pushed to mainline as r12-6977 after regtesting on x86_64-pc-linux-gnu.
Will backport to affected branches [11/10] with some de
> From: Richard Sandiford
> Hans-Peter Nilsson via Gcc-patches writes:
> > The mystery isn't so much that there's code mismatching comments or
> > intent, but that this code has been there "forever". There has been a
> > function reg_classes_intersect_p, in gcc since r0-54, even *before*
> > the
On Tue, 1 Feb 2022 at 18:54, Martin Sebor via Libstdc++
wrote:
>
> Passing an uninitialized object to a function that takes its argument
> by const reference is diagnosed by -Wmaybe-uninitialized because most
> such functions read the argument. The exceptions are functions that
> don't access the
On 2/1/22 10:31, Jakub Jelinek wrote:
On Tue, Feb 01, 2022 at 10:03:57AM +0100, Jakub Jelinek via Gcc-patches wrote:
I wonder if we shouldn't replace that
toks[0] = pfile->directive_result;
line with
toks[0] = pfile->avoid_paste;
or even replace those
toks = XNEW (cpp_token)
Hi!
Jakub, thanks for fixing this. I didn't realize the PCH implications here,
clearly...
On 2/1/22 12:33 PM, Segher Boessenkool wrote:
> Hi!
>
> On Tue, Feb 01, 2022 at 04:27:40PM +0100, Jakub Jelinek wrote:
>> +/* PR target/104323 */
>> +/* { dg-require-effective-target powerpc_altivec_ok } *
Passing an uninitialized object to a function that takes its argument
by const reference is diagnosed by -Wmaybe-uninitialized because most
such functions read the argument. The exceptions are functions that
don't access the object but instead use its address to compute
a result. This includes a
Ping
On Mon, Jan 24, 2022, 20:20 Aldy Hernandez wrote:
> On Mon, Jan 24, 2022 at 9:51 AM Richard Biener
> wrote:
> >
> > On Fri, Jan 21, 2022 at 1:12 PM Aldy Hernandez wrote:
> > >
> > > On Fri, Jan 21, 2022 at 11:56 AM Richard Biener
> > > wrote:
> > > >
> > > > On Fri, Jan 21, 2022 at 11:30
Hi!
On Tue, Feb 01, 2022 at 04:27:40PM +0100, Jakub Jelinek wrote:
> +/* PR target/104323 */
> +/* { dg-require-effective-target powerpc_altivec_ok } */
> +/* { dg-options "-maltivec" } */
> +
> +#include
> testcase which I'm not including into testsuite because for some reason
> the test fails o
Hi,
On a GT 1030, with driver version 470.94 and -mptx=3.1 I run into:
...
FAIL: libgomp.oacc-c/../libgomp.oacc-c-c++-common/parallel-dims.c \
-DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0 -foffload=nvptx-none \
-O2 execution test
...
which minimizes to the same test-case as listed in commit "
Hi,
On a GT 1030 (sm_61), with driver version 470.94 I run into:
...
FAIL: libgomp.oacc-c/../libgomp.oacc-c-c++-common/parallel-dims.c \
-DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0 -foffload=nvptx-none \
-O2 execution test
...
which minimizes to the same test-case as listed in commit "[nvptx
Hi,
With the following example, minimized from parallel-dims.c:
...
int
main (void)
{
int vectors_max = -1;
#pragma acc parallel num_gangs (1) num_workers (1) copy (vectors_max)
{
for (int i = 0; i < 2; i++)
for (int j = 0; j < 2; j++)
#pragma acc loop vector reduction (max
Hi,
In ptx isa 6.0, a new barrier instruction was added, and bar.sync was
redefined as barrier.sync.aligned.
The aligned modifier indicates that all threads in a CTA will execute the same
barrier instruction.
The seems fine for a form "bar.sync 0".
But a "bar.sync %rx,64" (as used for vector le
Hi,
When running libgomp test-case reduction-7.c on an nvptx accelerator
(T400, driver version 470.86) and GOMP_NVPTX_JIT=-O0, I run into:
...
reduction-7.exe:reduction-7.c:312: v_p_2: \
Assertion `out[j * 32 + i] == (i + j) * 2' failed.
FAIL: libgomp.oacc-c/../libgomp.oacc-c-c++-common/reductio
Hi,
The ptx insn atom doesn't support local memory. In case of doing an atomic
operation on local memory, we run into:
...
operation not supported on global/shared address space
...
This is the cuGetErrorString message for CUDA_ERROR_INVALID_ADDRESS_SPACE.
The message is somewhat confusing given
Hi,
When I run the libgomp test-case reduction-cplx-dbl.c on an nvptx accelerator
(T400, driver version 470.86), I run into:
...
FAIL: libgomp.oacc-c/../libgomp.oacc-c-c++-common/reduction-cplx-dbl.c \
-DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0 -foffload=nvptx-none -O0 \
execution test
FA
Tested x86_64-pc-linux-gnu, committed to master.
Backported to GCC-11.
On Sun, Jan 16, 2022 at 12:31 PM Jonathan Wakely wrote:
>
>
> On Sun, 16 Jan 2022 at 01:48, Thomas Rodgers via Libstdc++ <
> libstd...@gcc.gnu.org> wrote:
>
>> This patch updates the memory order of atomic accesses to the wai
On Mon, Jan 31, 2022 at 11:21 PM Richard Biener
wrote:
>
> On Mon, Jan 31, 2022 at 7:56 PM H.J. Lu via Gcc-patches
> wrote:
> >
> > Backport -mindirect-branch-cs-prefix:
>
> LGTM in case a x86 maintainer also acks this. Can you amend
> the 10.3 release gcc-11/changes.html notes accordingly?
Did
---
htdocs/gcc-12/changes.html | 6 ++
1 file changed, 6 insertions(+)
diff --git a/htdocs/gcc-12/changes.html b/htdocs/gcc-12/changes.html
index 2719b9d5..479bd6c5 100644
--- a/htdocs/gcc-12/changes.html
+++ b/htdocs/gcc-12/changes.html
@@ -387,6 +387,12 @@ a work-in-progress.
x86 sys
On 1/31/2022 1:46 AM, Martin Liška wrote:
On 1/28/22 23:01, Jonathan Wakely wrote:
On Fri, 28 Jan 2022 at 18:17, Jeff Law wrote:
On 1/24/2022 4:11 AM, Martin Liška wrote:
On 1/21/22 17:54, Jonathan Wakely wrote:
Yes, OK (but please CC the libstdc++ list, not just me).
Hello.
Sorry fo
On 2/1/2022 8:37 AM, Martin Liška wrote:
As the minimal GCC version that can build the current master
is 4.8, it does not make sense mentioning something for older
versions.
Ready to be installed?
Thanks,
Martin
gcc/ChangeLog:
* doc/install.texi: Remove option for GCC < 4.8.
OK
jeff
As the minimal GCC version that can build the current master
is 4.8, it does not make sense mentioning something for older
versions.
Ready to be installed?
Thanks,
Martin
gcc/ChangeLog:
* doc/install.texi: Remove option for GCC < 4.8.
---
gcc/doc/install.texi | 5 -
1 file changed,
On Tue, Feb 01, 2022 at 10:03:57AM +0100, Jakub Jelinek via Gcc-patches wrote:
> I wonder if we shouldn't replace that
> toks[0] = pfile->directive_result;
> line with
> toks[0] = pfile->avoid_paste;
> or even replace those
> toks = XNEW (cpp_token);
> toks[0] = pfile->direc
Hi!
As mentioned in the PR and as can be seen on:
--- gcc/testsuite/gcc.dg/pch/pr104323-1.c.jj2022-02-01 13:06:00.163192414
+0100
+++ gcc/testsuite/gcc.dg/pch/pr104323-1.c 2022-02-01 13:13:41.226712735
+0100
@@ -0,0 +1,16 @@
+/* PR target/104323 */
+/* { dg-require-effective-target pow
> +/* As a special case, X + C < Y + C is the same as X < Y even with wrapping
> + overflow if X and Y are signed integers of the same size, and C is an
> + unsigned constant with all bits except MSB set to 0 and size >= that of
> + X/Y. */
> +(for op (lt le ge gt)
> + (simplify
> + (op (pl
Hi!
As discussed, I simplified this patch by just changing how the error
message is produced:
We currently give different error messages for built-in functions that
violate range restrictions on their arguments, depending on whether we
record them as requiring an n-bit literal or a literal betwee
Hi,
I've modified the previous patch to add more explanatory commentary about
the number-of-arguments test that was previously confusing, and to convert
the switch into an if-then-else chain. The rest of the patch is unchanged.
Bootstrapped and tested on powerpc64le-linux-gnu. Is this okay for t
Hi,
this is a bugfix for aa8cfe785953a0e87d2472311e1260cd98c605c0 which
broke an or1k test case (PR104153) as well as SPARC bootstrap (PR104198).
cond_exec_get_condition () returns the jump condition directly and we
now it to the backend. The or1k backend modified the condition in-place
but this
Excerpts from Martin Liška's message of Januar 31, 2022 9:50 am:
> Pushed as obvious.
>
Thanks,
Iain.
Pushed to wwwdocs.
commit 996afe17497b8c06f00c763bcf7fe2b971bb0f05
Author: Jonathan Wakely
Date: Tue Feb 1 12:56:07 2022 +
Uncomment header for Fortran issues
diff --git a/htdocs/gcc-12/porting_to.html b/htdocs/gcc-12/porting_to.html
index 7f4a2936..470703c7 100644
--- a/htdocs/gcc-12
Pushed to wwwdocs.
commit 5f199e1197b67b4304a3be54579c2141c39bff30
Author: Jonathan Wakely
Date: Tue Feb 1 12:54:42 2022 +
Fix grammar for computed goto notes
diff --git a/htdocs/gcc-12/porting_to.html b/htdocs/gcc-12/porting_to.html
index 86d99723..7f4a2936 100644
--- a/htdocs/gcc-12/
Pushed to wwwdocs.
commit 9f6040a13e7c552a8c1c65352b702dc5d71b369e
Author: Jonathan Wakely
Date: Tue Feb 1 12:40:46 2022 +
Document C++20 and C++23 library additions
diff --git a/htdocs/gcc-12/changes.html b/htdocs/gcc-12/changes.html
index c6baee75..2719b9d5 100644
--- a/htdocs/gcc-1
Pushed to wwwdocs.
commit 7193a0fb5d1b164fa676beb35df13cc603a6cf67
Author: Jonathan Wakely
Date: Tue Feb 1 12:38:59 2022 +
Add C++ "porting to" notes
diff --git a/htdocs/gcc-12/porting_to.html b/htdocs/gcc-12/porting_to.html
index 42179c11..86d99723 100644
--- a/htdocs/gcc-12/porting_
Pushed to wwwdocs.
commit d334ee4964c7e186336396b44129197f618100f7
Author: Jonathan Wakely
Date: Tue Feb 1 12:37:38 2022 +
Fix grammar in C++ header dependency notes
diff --git a/htdocs/gcc-11/porting_to.html b/htdocs/gcc-11/porting_to.html
index 4d27c163..1d15570e 100644
--- a/htdocs
On Fri, Jan 28, 2022 at 10:47:06PM -0500, Michael Meissner via Gcc-patches
wrote:
> 2022-01-28 Michael Meissner
>
> gcc/
> PR target/104253
> * config/rs6000/rs6000.cc (init_float128_ibm): Use the TF names
> for builtin conversions between __ibm128 and DImode when long
>
Tamar Christina writes:
>> -Original Message-
>> From: Richard Sandiford
>> Sent: Friday, December 17, 2021 4:49 PM
>> To: Tamar Christina
>> Cc: gcc-patches@gcc.gnu.org; nd ; Richard Earnshaw
>> ; Marcus Shawcroft
>> ; Kyrylo Tkachov
>> Subject: Re: [2/3 PATCH]AArch64 use canonical ord
As at r2.2 of the RISC-V ISA specification[1] (equivalent to version 2.0
of the "F" and "D" standard architecture extensions for single-precision
and double-precision floating-point respectively) the FMIN and FMAX
machine instructions fully match our requirement for the `fminM3' and
`fmaxM3' st
apinski--- via Gcc-patches writes:
> From: Andrew Pinski
>
> The problem here is that aarch64_expand_setmem does not change the alignment
> for strict alignment case. This is version 3 of this patch, is is based on
> version 2 and moves the check for the number of instructions from the
> optimizi
Kyrylo Tkachov writes:
> Hi Richard,
>
> Sorry for the delay in getting back to this. I'm now working on a patch to
> adjust this.
>
>> -Original Message-
>> From: Richard Sandiford
>> Sent: Tuesday, December 14, 2021 10:48 AM
>> To: Kyrylo Tkachov via Gcc-patches
>> Cc: Kyrylo Tkachov
> -Original Message-
> From: Tamar Christina
> Sent: Tuesday, December 21, 2021 12:32 PM
> To: gcc-patches@gcc.gnu.org
> Cc: nd ; Ramana Radhakrishnan
> ; Richard Earnshaw
> ; ni...@redhat.com; Kyrylo Tkachov
>
> Subject: [PATCH][AArch32]: correct usdot-product RTL patterns.
>
> Hi All
Ping x3
> -Original Message-
> From: Tamar Christina
> Sent: Tuesday, January 11, 2022 7:10 AM
> To: gcc-patches@gcc.gnu.org
> Cc: nd ; Ramana Radhakrishnan
> ; Richard Earnshaw
> ; ni...@redhat.com; Kyrylo Tkachov
>
> Subject: RE: [PATCH][AArch32]: correct usdot-product RTL patterns.
>
> -Original Message-
> From: Tamar Christina
> Sent: Monday, December 20, 2021 4:22 PM
> To: gcc-patches@gcc.gnu.org
> Cc: nd ; Ramana Radhakrishnan
> ; Richard Earnshaw
> ; ni...@redhat.com; Kyrylo Tkachov
>
> Subject: RE: [3/3 PATCH][AArch32] use canonical ordering for complex mul,
>
On Tue, 1 Feb 2022, Jakub Jelinek wrote:
> On Tue, Feb 01, 2022 at 10:29:03AM +0100, Richard Biener wrote:
> > So I think it's all fine besides the handling of VEC_COND_EXPRs where
> > the use is in rhs1 and rhs2 and/or rhs3 - I don't really understand
> > your worry here but shouldn't the stmt en
Ping x3.
> -Original Message-
> From: Tamar Christina
> Sent: Tuesday, January 11, 2022 7:11 AM
> To: Richard Sandiford
> Cc: gcc-patches@gcc.gnu.org; nd ; Richard Earnshaw
> ; Marcus Shawcroft
> ; Kyrylo Tkachov
> Subject: RE: [2/3 PATCH]AArch64 use canonical ordering for complex mul,
>
Ping x3
> -Original Message-
> From: Tamar Christina
> Sent: Tuesday, January 11, 2022 7:11 AM
> To: gcc-patches@gcc.gnu.org
> Cc: nd ; Ramana Radhakrishnan
> ; Richard Earnshaw
> ; 'ni...@redhat.com' ;
> Kyrylo Tkachov
> Subject: RE: [3/3 PATCH][AArch32] use canonical ordering for comple
On Tue, Feb 01, 2022 at 10:29:03AM +0100, Richard Biener wrote:
> So I think it's all fine besides the handling of VEC_COND_EXPRs where
> the use is in rhs1 and rhs2 and/or rhs3 - I don't really understand
> your worry here but shouldn't the stmt end up on the vector at least
> once? You can use g
On Tue, 1 Feb 2022, Jakub Jelinek wrote:
> Hi!
>
> The following testcase fails -fcompare-debug, because expand_vector_comparison
> since r11-1786-g1ac9258cca8030745d3c0b8f63186f0adf0ebc27 sets
> vec_cond_expr_only when it sees some use other than VEC_COND_EXPR that uses
> the lhs in its conditio
Hi!
The following testcase fails -fcompare-debug, because expand_vector_comparison
since r11-1786-g1ac9258cca8030745d3c0b8f63186f0adf0ebc27 sets
vec_cond_expr_only when it sees some use other than VEC_COND_EXPR that uses
the lhs in its condition.
Obviously we should ignore debug stmts when doing s
On Tue, Feb 01, 2022 at 12:28:57AM +0100, Jakub Jelinek via Gcc-patches wrote:
> I haven't, but will do so now.
So, I've done another bootstrap/regtest with incremental
--- gcc/c-family/c-lex.cc.jj2022-01-18 00:18:02.558747051 +0100
+++ gcc/c-family/c-lex.cc 2022-02-01 00:39:47.314183266
This patch fixes PR tree-optimization/102950, which is a P2 regression,
by providing better range bounds for BIT_XOR_EXPR, BIT_AND_EXPR and
BIT_IOR_EXPR on signed integer types. In general terms, any binary
bitwise operation on sign-extended or zero-extended integer types will
produce results tha
On Tue, Feb 01, 2022 at 08:20:39AM +0100, Tom de Vries wrote:
> [libgomp, testsuite] Reduce recursion depth in declare_target-*.f90
>
> libgomp/ChangeLog:
>
> 2022-01-27 Tom de Vries
>
> * testsuite/libgomp.fortran/examples-4/declare_target-1.f90: Reduce
> recursion depth.
>
73 matches
Mail list logo
