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
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, _mode)
>
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
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
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:
> > > >
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
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
>
Bootstrapped and regression tested in gcc version
d6f1cf644c45b76a27b6a6869dedaa030e3c7570 on x86_64 GNU/Linux .
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, _mode)
&& GET_MODE_SIZE (int_mode) == 2 * UNITS_PER_WORD
&& optab_handler
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
> > > --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
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
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
> ---
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.
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
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
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/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
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
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 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
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
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
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
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.
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
[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
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
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
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 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 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
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
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
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:
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
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 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
> 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/
> 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
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
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
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
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
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
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:
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
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
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
*
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
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").
---
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
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
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
54 matches
Mail list logo
