From: Claudiu Zissulescu
The compiler can match mpyd.eq r0,r1,r0 as a predicated instruction,
which is incorrect. The mpyd(u) instruction takes as input two 32-bit
registers, returning into a double 64-bit even-odd register pair. For
the predicated case, the ARC instruction decoder expects the
d
Hi!
I'd like to ping 3 patches:
https://gcc.gnu.org/pipermail/gcc-patches/2021-January/563710.html
expand: Expand x / y * y as x - x % y if the latter is cheaper [PR96696]
https://gcc.gnu.org/pipermail/gcc-patches/2021-January/563711.html
match.pd: Add some __builtin_ctz (x) cmp cst simplifi
Correction to what I just wrote:
On 25.01.21 11:02, Tobias Burnus wrote:
Executing on $remote_host: rm -f
gcm.cache/$srddir/g++.dg/modules/concept-4.H.gcm(timeout = 360)
→ This deletes in gcm.cache/$srddir
Executing on host: cp -pf /$srcdir/g++.dg/modules/concept-4.H concept-4.H
Executing
I pushed a minor update to the existing entry for s390-specific
--enable-s390-excess-float-precision after validating.
Marius
--->8->8-->8->8---
Reflect the changes in commit 33f925094d02 ("IBM Z: Detect libc's
float_t behavior on cross compiles").
---
htdocs/gcc-11
Hi Tobias,
- Mensaje original -
> De: "Tobias Burnus"
> Para: "jdelia" , "Gfortran List" , "GCC Patches"
> CC: "Jorge D'Elia"
> Enviado: Jueves, 21 de Enero 2021 10:28:02
> Asunto: [Patch, committed] gcc/fortran/intrinsic.texi: Fix typo (was:
> gfortran online docs: small typo in RESUL
Hi All,
Fixed as 'blindingly obvious' on 9-, 10- and 11-branches, using Steve's
patch.
Even if it doesn't fix anything, the patch is totally safe :-)
Paul
Fortran: Fix deferred character lengths in array constructors [PR98517].
2021-01-25 Steve Kargl
gcc/fortran
PR fortran/98517
* resolve.
This is a regression present on the mainline, 10 and 9 branches, in the form
of an internal error when a covariant-only thunk is inlined into its caller.
Tested on x86-64/Linux, applied on the mainline, 10 and 9 branches.
2021-01-25 Eric Botcazou
* gcc-interface/trans.c (make_covari
This simplifies vector_element_bits further, avoiding any mode
dependence and instead relying on boolean vector construction
to populate element precision accordingly.
Bootstrapped and tested on x86_64-unknown-linux-gnu (also with
AVX512 with the help of SDE), pushed.
2021-01-25 Richard Biener
On 1/21/21 7:40 PM, Martin Liška wrote:
Most of the changes are in known contexts:
I've made some progress here, but still I'm unable to get a reproducible build.
Now I see difference in:
161/ 649: cp/decl.o: different
180/ 649: cp/parser.o: different
262/ 649: generic-match.o:
Hi!
binutils since https://sourceware.org/bugzilla/show_bug.cgi?id=25612
changes from March last year until the
https://sourceware.org/pipermail/binutils/2020-August/112684.html
fix in early August emits incorrect .debug_info when assembling files
with --gdwarf-5. Instead of emitting proper DWARF
On 1/22/21 3:51 PM, Jan Hubicka wrote:
gcc/ChangeLog:
PR gcov-profile/98739
* common.opt: Add missing sign symbol.
* value-prof.c (get_nth_most_common_value): Restore handling
of PROFILE_REPRODUCIBILITY_PARALLEL_RUNS and
PROFILE_REPRODUCIBILITY_MULTITHREAD
On 1/22/21 3:33 PM, Jan Hubicka wrote:
It is definitly doable (gcov machinery is quite flexible WRT having more
types of counters).
Yes, that would introduce back the dropped TOPN counters which I intentionally
dropped.
We could bring back topn counters or the easier dominating vlaue ones
and
On Mon, 25 Jan 2021, Jakub Jelinek wrote:
> Hi!
>
> binutils since https://sourceware.org/bugzilla/show_bug.cgi?id=25612
> changes from March last year until the
> https://sourceware.org/pipermail/binutils/2020-August/112684.html
> fix in early August emits incorrect .debug_info when assembling f
Hi Jorge, hi all,
On 25.01.21 11:42, Jorge D'Elia wrote:
Committed as r11-6835-g9be0a89c95cc30089786faa26b89e8d7444c879e
By the way, when will the update be available in https://gcc.gnu.org/onlinedocs
?
e.g. at least until today it is still not seen...
It turned out that the issue was in mu
> I've just installed the patch.
>
> About the negative total value. Something similar can handle it:
> diff --git a/libgcc/libgcov.h b/libgcc/libgcov.h
> index df08e882dd7..ddc688509bd 100644
> --- a/libgcc/libgcov.h
> +++ b/libgcc/libgcov.h
> @@ -443,7 +443,13 @@ gcov_topn_add_value (gcov_type *
> On 1/21/21 7:40 PM, Martin Liška wrote:
> > Most of the changes are in known contexts:
>
> I've made some progress here, but still I'm unable to get a reproducible
> build.
> Now I see difference in:
>
>161/ 649: cp/decl.o: different
>180/ 649: cp/parser.o: different
>262/ 64
On Mon, Jan 25, 2021 at 4:54 AM Martin Liška wrote:
>
> On 1/22/21 3:51 PM, Jan Hubicka wrote:
> >> gcc/ChangeLog:
> >>
> >> PR gcov-profile/98739
> >> * common.opt: Add missing sign symbol.
> >> * value-prof.c (get_nth_most_common_value): Restore handling
> >> of PROFILE_REPRO
Hello
I forgot to update the libgomp documentation to document the new
omp_fulfill_event runtime routine introduced by task detach support. Is this
patch okay for trunk?
Thanks
Kwok
From efeaac839879bc30e0e7e129ca43381192a6f109 Mon Sep 17 00:00:00 2001
From: Kwok Cheung Yeung
Date: Mon, 25
On Mon, Jan 25, 2021 at 03:21:45PM +, Kwok Cheung Yeung wrote:
> I forgot to update the libgomp documentation to document the new
> omp_fulfill_event runtime routine introduced by task detach support. Is this
> patch okay for trunk?
>
> Thanks
>
> Kwok
> From efeaac839879bc30e0e7e129ca433811
Hi Nathan,
looking at testsuite issues, I see many g++ module fails.
Maybe we can fix some.
* * *
As mentioned on IRC:
09:09 < Tobias__> nathan: I get 'ERROR: can't read "identlink": no such
variable'
'identlink' appears in GCC only once:
09:09 < Tobias__> nathan: gcc/testsuite/g++.dg/module
In this testcase, cxx_eval_store_expression got confused trying to build up
CONSTRUCTORs for initializing a subobject because the subobject is a member
of an empty base. In C++14 mode and below we don't build FIELD_DECLs for
empty bases, so the CONSTRUCTOR skipped the empty base, and treated the
m
Hi!
On Thu, Jan 21, 2021 at 05:49:14PM -0600, will schmidt wrote:
> Noted as part of the work-in-progress builtins rewrite, the
> __builtin_dfp_dtstsfi_*_{dd,td} builtins are redundant, and are thusly
> being marked as deprecated. They will be removed as part of the builtins
> rewrite sometime
On 1/25/21 4:06 PM, H.J. Lu wrote:
On Mon, Jan 25, 2021 at 4:54 AM Martin Liška wrote:
On 1/22/21 3:51 PM, Jan Hubicka wrote:
gcc/ChangeLog:
PR gcov-profile/98739
* common.opt: Add missing sign symbol.
* value-prof.c (get_nth_most_common_value): Restore handling
of PR
On 1/22/21 12:19 PM, Nick Alcock wrote:
Searching for sighander_t is unlikely to succeed anywhere.
The attempt to #include is also not working,
and fixing it shows that doing an AC_DEFINE in the body of
an AC_CHECK_TYPE like that is also risky: both fixed.
(The purpose of this check is opaque
On Fri, 22 Jan 2021 at 19:28, Christophe Lyon
wrote:
>
> On Thu, 21 Jan 2021 at 21:35, Daniel Engel wrote:
> >
> > Hi Christophe,
> >
> > On Thu, Jan 21, 2021, at 2:29 AM, Christophe Lyon wrote:
> > > On Sat, 16 Jan 2021 at 17:13, Daniel Engel wrote:
> > > >
> > > > Hi Christophe,
> > > >
> > >
On 25 Jan 2021, Nathan Sidwell uttered the following:
> On 1/22/21 12:19 PM, Nick Alcock wrote:
>> Searching for sighander_t is unlikely to succeed anywhere.
>>
>> The attempt to #include is also not working,
>> and fixing it shows that doing an AC_DEFINE in the body of
>> an AC_CHECK_TYPE like t
Richard Biener writes:
> On Fri, 22 Jan 2021, Segher Boessenkool wrote:
>
>> On Fri, Jan 22, 2021 at 02:47:06PM +0100, Richard Biener wrote:
>> > On Thu, 21 Jan 2021, Segher Boessenkool wrote:
>> > > What is holding up this patch still? Ke Wen has pinged it every month
>> > > since May, and there
[ARM has unique ABI here, hence cc'ing Richard]
Solaris tickled this bug as it has some mutex/sync/something primitive
with a destructor, hence wanted to generate a __cxa_atexit call inside
an inline/template function. But the problem is not solaris-specific.
I tested this bootstrapping both
Greetings.
Big endian support for RISC-V was added in binutils 2.36, released
yesterday. This patch set adds support to gcc for exploting this mode.
Please note that in addition to these patches, an pull of config.sub
from upstreams is needed.
In adding the big endian support, I had the followi
gcc/
* config/riscv/elf.h (LINK_SPEC): Pass linker endianness flag.
* config/riscv/freebsd.h (LINK_SPEC): Likewise.
* config/riscv/linux.h (LINK_SPEC): Likewise.
* config/riscv/riscv.h (ASM_SPEC): Pass -mbig-endian and
-mlittle-endian.
(BYTES_BIG_ENDI
gcc/
* common/config/riscv/riscv-common.c
(TARGET_DEFAULT_TARGET_FLAGS): Set default endianness.
* config.gcc (riscv32be-*, riscv64be-*): Set
TARGET_BIG_ENDIAN_DEFAULT to 1.
* config/riscv/elf.h (LINK_SPEC): Change -melf* value
depending on default en
On 1/25/21 12:50 PM, Nick Alcock wrote:
On 25 Jan 2021, Nathan Sidwell uttered the following:
On 1/22/21 12:19 PM, Nick Alcock wrote:
Searching for sighander_t is unlikely to succeed anywhere.
The attempt to #include is also not working,
and fixing it shows that doing an AC_DEFINE in the bod
I think I never got a clear answer that we'll wait for stage 1 to
consider this patch so here is a ping.
On 01/12/20 8:19 am, François Dumont wrote:
Let me know if I need to reference a specific paper or any other
Standard reference here. Maybe P1690R1 I used here ?
I tried to allow the same
Hi Harald,
the attached patch is pretty much self-explaining: check for bounds violation
when initializing a substring in a data statement and treat the resulting error.
If more detailed information should be emitted with the error message, I'm
open for suggestions.
Currently, we issue these
Hi!
On Mon, Jan 25, 2021 at 05:59:23PM +, Richard Sandiford wrote:
> Richard Biener writes:
> > On Fri, 22 Jan 2021, Segher Boessenkool wrote:
> >> But what could have been done differently that would have helped? Of
> >> course Ke Wen could have written a better patch (aka one that is more
Hi Thomas,
> Gesendet: Montag, 25. Januar 2021 um 19:58 Uhr
> Von: "Thomas Koenig"
> a.f90:3:10:
>
> 3 | print a(0:3)
>| 1
> Error: Substring start index at (1) is less than one
> a.f90:4:10:
>
> 4 | print a(1:4)
>| 1
> Error: Substring end index a
On 1/21/2021 5:04 PM, Joseph Myers wrote:
On Fri, 18 Dec 2020, Patrick McGehearty via Gcc-patches wrote:
TEST Data
I'd still like to see the test data / code used to produce the accuracy
and performance results made available somewhere (presumably with a link
then being provided in the comm
On Mon, 25 Jan 2021, Patrick McGehearty wrote:
> On 1/21/2021 5:04 PM, Joseph Myers wrote:
> > On Fri, 18 Dec 2020, Patrick McGehearty via Gcc-patches wrote:
> >
> > > TEST Data
> > I'd still like to see the test data / code used to produce the accuracy
> > and performance results made available
On 1/25/21 4:43 AM, Jakub Jelinek wrote:
https://gcc.gnu.org/pipermail/gcc-patches/2020-December/560741.html
dwarf: -gdwarf64 fix for 32-bit targets
OK.
Jason
Hi!
On Thu, Oct 08, 2020 at 09:27:55AM +1030, Alan Modra wrote:
> * config/rs6000/rs6000.c (rs6000_rtx_costs): Tidy AND code.
> Don't avoid recursion on const_int shift count.
>
> diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
> index e870ba0039a..bc5e51aa5ce 100
On Thu, Oct 08, 2020 at 09:27:56AM +1030, Alan Modra wrote:
> Most cases use "return false" rather than breaking out of the switch.
> Do so in all cases.
> default:
> - break;
> + return false;
> }
> -
> - return false;
> }
Please don't do this part. The rest is okay. Than
Hi!
On Thu, Oct 08, 2020 at 09:27:57AM +1030, Alan Modra wrote:
> * config/rs6000/rs6000.c (rotate_insert_cost): New function.
> (rs6000_rtx_costs): Cost IOR.
>
> diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
> index 383d2901c9f..15a806fe307 100644
> --- a/gcc/c
There are two open gcc bugzilla bugs for complex divide.
59714 complex divide is surprising on targets with FMA
60646 investigate improved complex division algorithms
Either might be appropriate. 59714 started my investigation,
and my solution resolves that issue, while my solution
seems closer t
> > > --snip--
> > >
> > > If the test server farm is free at some point, would you mind running
> > > another set of regression tests on my v5 patch series?
> >
> > Sure. Given the number of sub-patches, can you send it to me as a
> > single patch file
> > (git format) that I can directly apply to
On Mon, 25 Jan 2021, Patrick McGehearty via Gcc-patches wrote:
> Anyway, once I created the tarball and gzipped it,
> I found it shrank to 100Kbytes. Rather than have further
> delays, I've attached the gzip file to this email.
Thanks. The next patch version can include the URL of this file in t
optabs.c:expand_unop_direct can expand a popcount builtin without a call
under certain conditions even without a popcount pattern of the required
data width:
if (unoptab == popcount_optab
&& is_a (mode, &int_mode)
&& GET_MODE_SIZE (int_mode) == 2 * UNITS_PER_WORD
&& optab_hand
Bootstrapped and regression tested in gcc version
d6f1cf644c45b76a27b6a6869dedaa030e3c7570 on x86_64 GNU/Linux .
Hi!
On Fri, Dec 04, 2020 at 01:19:11PM -0600, acsaw...@linux.ibm.com wrote:
> This patch adds the first batch of patterns to support p10 fusion. These
> will allow combine to create a single insn for a pair of instructions
> that that power10 can fuse and execute. These particular ones have the
>
esirisc has a sub-target that has DImode with 4 byte alignment, and
DFmode with 8 byte alignment. For code like g++.dg/torture/pr39713.C ,
the optimizes changes the mode of a MEM from DImode to DFmode even if
the required alignment is not available.
Appended is is the target-independent part of t
On Thu, Jan 14, 2021 at 7:16 PM Hongtao Liu wrote:
>
> ping.
>
> On Thu, Jan 7, 2021 at 1:22 PM Hongtao Liu wrote:
> >
> > On Wed, Jan 6, 2021 at 10:39 PM Jakub Jelinek wrote:
> > >
> > > On Wed, Jan 06, 2021 at 02:49:13PM +0800, Hongtao Liu wrote:
> > > > ix86_expand_fp_vec_cmp/ix86_expand_in
Hello Kito,
On 20/11/2020 09:33, Kito Cheng wrote:
- Define MULTILIB_DEFAULTS can reduce the total number of multilib if
the default arch and ABI are listed in the multilib config.
- This also simplify the implementation of --with-multilib-list.
gcc/ChangeLog:
* config.gcc (ri
From: "luo...@cn.ibm.com"
UNSPEC_SI_FROM_SF is not supported when TARGET_DIRECT_MOVE_64BIT
is false for -m32, don't generate VIEW_CONVERT_EXPR(ARRAY_REF) for
variable vector insert. Remove rs6000_expand_vector_set_var helper
function, adjust the p8 and p9 definitions position and make them
stati
On Tue, Jan 26, 2021 at 1:25 AM Joern Wolfgang Rennecke
wrote:
>
> optabs.c:expand_unop_direct can expand a popcount builtin without a call
> under certain conditions even without a popcount pattern of the required
> data width:
>
> if (unoptab == popcount_optab
> && is_a (mode, &int_mode
On Tue, Jan 26, 2021 at 3:07 AM Joern Wolfgang Rennecke
wrote:
>
> esirisc has a sub-target that has DImode with 4 byte alignment, and
> DFmode with 8 byte alignment. For code like g++.dg/torture/pr39713.C ,
> the optimizes changes the mode of a MEM from DImode to DFmode even if
> the required al
54 matches
Mail list logo
