Hi Richard,
on 2020/7/1 下午11:17, Richard Sandiford wrote:
> "Kewen.Lin" writes:
>> on 2020/7/1 上午3:53, Richard Sandiford wrote:
>>> "Kewen.Lin" writes:
poly_uint64 vf = LOOP_VINFO_VECT_FACTOR (loop_vinfo);
+ tree length_limit = NULL_TREE;
+ /* For length, we need
On 2020-07-01, Martin Liška wrote:
On 6/30/20 5:32 PM, Fāng-ruì Sòng wrote:
There is some concern about clang's -fuse-ld=path
http://lists.llvm.org/pipermail/cfe-dev/2020-June/065710.html and use
of COMPILER_PATH vs PATH.
Shall we introduce another option like -fld-path=path (PATH is used,
Hi Jim:
> I think it is reasonable to start a discussion in riscv-isa-manual, to
> try to get an official answer for what is valid and how to interpret
> it, instead of just making up our own rules.
Agree, issue[1] created on riscv-isa-manual.
[1]
Hi Jim:
Committed, thanks.
On Thu, Jul 2, 2020 at 7:28 AM Jim Wilson wrote:
>
> On Wed, Jul 1, 2020 at 12:13 AM Kito Cheng wrote:
> > * config/riscv/multilib-generator (arch_canonicalize): Handle
> > multi-letter extension.
> > Using underline as separator between
Jiufu Guo writes:
I would like to reping this patch.
Since this is correcting COUNT and PROB for hot blocks, it helps some
cases.
https://gcc.gnu.org/legacy-ml/gcc-patches/2020-02/msg00927.html
Thanks,
Jiufu Guo
> Jiufu Guo writes:
>
> Gentle ping.
>
On Tue, Jun 30, 2020 at 8:16 PM Kito Cheng wrote:
> I agree the version of G is kind of problematic for GCC implementation,
> That reminds me there was a long discussion[1] last year,
> The conclusion is version of G is too confusing, it might just don't
> accept any version for G.
> I thought it
On Wed, Jul 1, 2020 at 12:13 AM Kito Cheng wrote:
> * config/riscv/multilib-generator (arch_canonicalize): Handle
> multi-letter extension.
> Using underline as separator between different extensions.
Looks fine to me. Though I was expecting you to just commit the patch
This patch fixes a PR that I noticed several years ago during power8
development. I noticed that the compiler would often create a two element
vector and store the vector.
Particularly for DImode on power8, this could involve two direct moves and a
XXPERMDI to glue the two parts together. On
On Wed, May 27, 2020 at 08:50:43AM -0700, Carl Love wrote:
> The following patch adds support for builtins vec_genbm(), vec_genhm(),
> vec_genwm(), vec_gendm(), vec_genqm(), vec_cntm(), vec_expandm(),
> vec_extractm(). Support for instructions mtvsrbm, mtvsrhm, mtvsrwm,
> mtvsrdm, mtvsrqm, cntm,
This patch adds support for the IEEE 128-bit floating point minimum, maximum,
and compare instructions generating a mask. These instructions were added in
ISA 3.1 (i.e. power10).
Compared to the last time I submitted the patches, I changed from using
-mcpu=future to -mcpu=power10. Along with
This patch changes the name of two functions that were added to support power9
instructions, so that the name of these functions are no longer specific to
power9.
The next patch will add support for the power10 IEEE 128-bit minimum, maximum,
and conditional move instructions. This patch renames
The two patches that will be mailed as replies to this patch add support for
the IEEE 128-bit floating point minimum, maximum, and set mask based on
comparison instructions.
These patches were previous submitted as:
https://gcc.gnu.org/pipermail/gcc-patches/2020-June/546992.html
On 6/27/20 1:40 AM, Thomas Koenig via Fortran wrote:
Hi Mark,
Use -fdec-add-missing-indexes to enable feature. Also enabled by fdec.
A warning that the lower bound is being used for a mission dimension
is output unless suppressed by using -Wno-missing-index.
This is... seriously
Hi,
the mechanism generating debug info for removed parameters did not
adjust index of the argument in the call statement to take into
account extra arguments IPA-SRA might have produced when splitting a
strucutre. This patch addresses that omission and stops gdb from
showing incorrect value for
On 7/1/20 3:31 PM, Martin Sebor wrote:
The attached patch avoids null pointer checking for the first
argument to calls to the member operator() of lambda objects
emitted by the C++ front end. This avoids both the spurious
-Wnonnull warnings for such calls as well as the ICE reported
in the bug.
> Hmm, that's a good question - so would your patch be replaceable by
> simply amending var_decl_component_p by
>
> (var_decl_component_p (TREE_OPERAND (src, 0))
>
>|| TREE_CODE (TREE_OPERAND (src, 0)) == STRING_CST)
>
> ?
The gimple_call_alloca_for_var_p (stmt) kludge is still needed
On Wed, 1 Jul 2020 at 23:53, Jonathan Wakely wrote:
>
> On 01/07/20 23:32 +0300, Ville Voutilainen via Libstdc++ wrote:
> >On Wed, 1 Jul 2020 at 21:09, Ville Voutilainen
> > wrote:
> >> And sure, s/move-construction/move-assignment/.
> >
> >And with dg-options.
>
> OK for master and gcc-10,
Omar Tahir writes:
> Hi Richard,
>
> From: Richard Sandiford
>> > @@ -3719,6 +3722,7 @@ static unsigned int rest_of_handle_sched (void)
>> > { #ifdef INSN_SCHEDULING
>> > + first_moveable_pseudo = last_moveable_pseudo;
>> >if (flag_selective_scheduling
>> >&& !
On Fri, 2020-06-05 at 18:23 +, Pip Cet via Gcc-patches wrote:
> David Malcolm writes:
>
> > On Sat, 2020-05-30 at 18:51 +, Pip Cet wrote:
> > > How's this?
> >
> > Thanks; looks good to me. Hopefully this doesn't clash with Tom's
> > patch.
>
> It doesn't, but I hope I got the commit
Omar Tahir writes:
> Hi,
>
> Got a small bugfix here regarding BTIs and trampolines.
>
> If two functions require trampolines, and the first has BTI enabled while the
> second doesn't, the generated template will be lacking a BTI instruction.
> This patch fixes this by always adding a BTI
On 01/07/20 23:32 +0300, Ville Voutilainen via Libstdc++ wrote:
On Wed, 1 Jul 2020 at 21:09, Ville Voutilainen
wrote:
And sure, s/move-construction/move-assignment/.
And with dg-options.
OK for master and gcc-10, thanks.
Does it apply cleanly to gcc-9 too?
On Mon, 2020-06-15 at 09:32 +0200, Richard Biener via Gcc-patches wrote:
> On Thu, Jun 4, 2020 at 5:09 PM Naveen Hurugalawadi
> wrote:
> > Hi,
> >
> > Thanks for reviewing the patch and sharing your comments.
> >
> > > > nop_convert4 cannot happen, constants will have been constant folded
> >
These functions can't be noexcept because the iterators stored in the
sub_match objects can throw on any operation.
libstdc++-v3/ChangeLog:
PR libstdc++/94627
* include/bits/regex.h (operator==, operator!=): Remove noexcept
equality comparisons for match_results.
On Wed, 1 Jul 2020 at 21:09, Ville Voutilainen
wrote:
> And sure, s/move-construction/move-assignment/.
And with dg-options.
2020-07-01 Ville Voutilainen
PR libstdc++/91807
* include/std/variant
(_Copy_assign_base::operator=(const _Copy_assign_base&):
Do the move-assignment
On Mon, 2020-06-29 at 08:58 +0200, Richard Biener wrote:
> On Sat, Jun 27, 2020 at 4:52 PM Marc Glisse wrote:
> > On Fri, 26 Jun 2020, Jeff Law via Gcc-patches wrote:
> >
> > > In theory yes, but there are cases where paths converge (like you've
> > > shown) where
> > > you may have evaluated
On Sat, 2020-06-27 at 01:03 +0200, Ilya Leoshkevich wrote:
> On Fri, 2020-06-26 at 16:04 -0600, Jeff Law wrote:
> > On Fri, 2020-06-26 at 23:54 +0200, Ilya Leoshkevich wrote:
> > > How should this work ideally? Suppose we have:
> > >
> > > static inline void foo (int i)
> > > {
> > > if
On Wed, 2020-07-01 at 11:57 -0600, Jeff Law wrote:
> On Wed, 2020-07-01 at 14:29 +0200, Ilya Leoshkevich via Gcc-patches
> wrote:
> > gcc/ChangeLog:
> >
> > 2020-06-30 Ilya Leoshkevich
> >
> > * asan.c (asan_emit_stack_protection): Use CODE_LABEL_BOUNDARY.
> > * defaults.h
The attached patch avoids null pointer checking for the first
argument to calls to the member operator() of lambda objects
emitted by the C++ front end. This avoids both the spurious
-Wnonnull warnings for such calls as well as the ICE reported
in the bug.
In addition, the patch also avoids
This patch breaks bootstrap.
It is not portable to use _( ... ) to initialize an array.
In file included from /nasfarm/edelsohn/src/src/gcc/fortran/gfortran.h:52,
from /nasfarm/edelsohn/src/src/gcc/fortran/check.c:32:
/nasfarm/edelsohn/src/src/gcc/fortran/check.c: In function
On 01.07.20 14:29, Ilya Leoshkevich wrote:
...
> gcc/ChangeLog:
>
> 2020-06-30 Ilya Leoshkevich
>
> * config/s390/s390.h (CODE_LABEL_BOUNDARY): Specify that s390
> requires code labels to be aligned on a 2-byte boundary.
>
> gcc/testsuite/ChangeLog:
>
> 2019-06-30 Ilya
On Wed, 1 Jul 2020 at 20:46, Ville Voutilainen
wrote:
>
> Looks like just a small thinko. We construct a temporary and move-construct
> from it, but we should construct the temporary with the right index.
>
> OK for trunk and gcc-10 if full tests pass?
>
> 2020-07-01 Ville Voutilainen
>
>
On Wed, 2020-07-01 at 14:29 +0200, Ilya Leoshkevich via Gcc-patches wrote:
> gcc/ChangeLog:
>
> 2020-06-30 Ilya Leoshkevich
>
> * asan.c (asan_emit_stack_protection): Use CODE_LABEL_BOUNDARY.
> * defaults.h (CODE_LABEL_BOUNDARY): New macro.
> * doc/tm.texi: Document
Hi Mark,
I suspect this change may be behind a bootstrap failure I'm seeing.
My guess is that the hint needs to be a pointer rather than an array.
Thanks
Martin
In file included from /ssd/test/src/gcc/trunk/gcc/fortran/gfortran.h:52,
from
On 7/1/20 1:29 PM, Jonathan Wakely wrote:
On 30/06/20 17:43 +0100, Jonathan Wakely wrote:
gcc/testsuite/ChangeLog:
* g++.dg/analyzer/pr94028.C: Make operator new non-throwing so
that the compiler doesn't implicitly mark it as returning
non-null.
Fixes these:
FAIL:
Looks like just a small thinko. We construct a temporary and move-construct
from it, but we should construct the temporary with the right index.
OK for trunk and gcc-10 if full tests pass?
2020-07-01 Ville Voutilainen
PR libstdc++/91807
* include/std/variant
On 30/06/20 17:43 +0100, Jonathan Wakely wrote:
gcc/testsuite/ChangeLog:
* g++.dg/analyzer/pr94028.C: Make operator new non-throwing so
that the compiler doesn't implicitly mark it as returning
non-null.
Fixes these:
FAIL: g++.dg/analyzer/pr94028.C -std=c++98 (test
On Wed, 2020-07-01 at 12:00 -0500, Segher Boessenkool wrote:
> Hi!
>
> On Mon, Jun 29, 2020 at 03:31:48PM -0700, Carl Love wrote:
> > On Mon, 2020-06-29 at 16:58 -0500, Segher Boessenkool wrote:
> > > On Mon, Jun 29, 2020 at 02:29:54PM -0700, Carl Love wrote:
> > > > Segher:
> > > >
> > > > On
This patch adds support for the Power10 BRD, BRW, and BRH instructions that do
byte swapping on values in GPRs.
This patch is a revision of the byte swap patch proposed in:
https://gcc.gnu.org/pipermail/gcc-patches/2020-June/546990.html
I changed the DI swap function bswapdi2_brd instead of
Hi!
On Mon, Jun 29, 2020 at 03:31:48PM -0700, Carl Love wrote:
> On Mon, 2020-06-29 at 16:58 -0500, Segher Boessenkool wrote:
> > On Mon, Jun 29, 2020 at 02:29:54PM -0700, Carl Love wrote:
> > > Segher:
> > >
> > > On Thu, 2020-06-25 at 17:39 -0500, Segher Boessenkool wrote:
> > > > > +;; Return
(Version 3)
(Added in version 3)
Support for half, float, extended, and long double precision has
been added to the prior work for double precision. Since half precision
is computed with float precision as per current libgcc practice,
the enhanced underflow/overflow tests provide no benefit for
Andrea Corallo writes:
>> It occurred to me that the entrypoint is combining two things:
>> - creating a global char[]
>> - creating an initializer for that global
>>
>> which got me wondering if we should instead have a way to add
>> initializers for globals.
>>
>> My first thought was
Similar to what we've seen elsewhere. The change to c++17 by default is causing
m68k to not bootstrap due to use of the "register" keyword. This patch removes
the half-dozen or so instances I immediately saw. I'll spin up another m68k
bootstrap attempt today/tonight.
Jeff
commit
> -Original Message-
> From: Srinath Parvathaneni
> Sent: 22 June 2020 17:21
> To: gcc-patches@gcc.gnu.org
> Cc: Kyrylo Tkachov
> Subject: [PATCH][GCC-10 Backport] arm: Fix the failing mve scalar shift
> execution tests.
>
> Hello,
>
> In GCC testsuite the MVE scalar shift execution
A further adjustment of the function cloning. Rather than have
copy_fndecl_with_name deduce whether a particular cdtor needs a
vtt_parm and/or has inherited parms to drop, pass that information in
from the caller. In particular build_cdtor_clones knows when its
building the particular cdtors
Richard Sandiford writes:
> OK with those changes, thanks.
>
> Richard
Hi Richard,
thanks for the quick review.
I've installed the patch with the suggested changes as:
0d7e5fa655e aarch64: Add 64 bit setter getter fpsr fpcr
Regards
Andrea
gcc/ChangeLog
*
This patch provides an initial set of definition for the rest of library-wide
OMPD functions.
It addresses all feedbacks.
2020-07-01 Tony Sim
libgomp/ChangeLog:
* libgompd.h: Include omp-tools.h.
(gompd_callbacks): New extern declaration.
* ompd-lib.c
"Kewen.Lin" writes:
> on 2020/7/1 上午3:53, Richard Sandiford wrote:
>> "Kewen.Lin" writes:
>>>poly_uint64 vf = LOOP_VINFO_VECT_FACTOR (loop_vinfo);
>>> + tree length_limit = NULL_TREE;
>>> + /* For length, we need length_limit to check length in range. */
>>> + if (!vect_for_masking)
>>>
Gentle ping to keep this in your inbox. :) There are still many more
important things ahead of this.
Bill
On 6/17/20 2:46 PM, Bill Schmidt via Gcc-patches wrote:
I posted a version of these patches back in stage 4 (February),
but we agreed that holding off until stage 1 was a better idea.
Hi,
How are you doing today?
I am following up with my previous email to check if you are interested in
our services.
Did you receive my email? Please let me know your thoughts.
Thank you and I look forward to hearing from you.
Regards
Brittany Wall
*From:* Brittnay Wall
On 6/15/20 10:28 PM, Kwok Cheung Yeung wrote:
> Hello
>
> This patch adds support on nvptx for __sync_val_compare_and_swap
> operations on 1- and 2-byte values. The implementation is a straight
> copy of the version for AMD GCN.
Actually it also adds support for __sync_bool_compare_and_swap, be
> On 7/1/20 3:15 AM, Martin Liška wrote:
> > On 6/30/20 3:24 PM, Nathan Sidwell wrote:
> > > On 6/30/20 8:53 AM, Martin Liška wrote:
>
> > Yes, if there's a real need for a solid compression, then I would use a
> > generic compressor of a final streamed file.
>
> for avoidance of doubt, I'm good
On 7/1/20 3:15 AM, Martin Liška wrote:
On 6/30/20 3:24 PM, Nathan Sidwell wrote:
On 6/30/20 8:53 AM, Martin Liška wrote:
Yes, if there's a real need for a solid compression, then I would use a
generic compressor of a final streamed file.
for avoidance of doubt, I'm good with your current
Pushed.
commit 59ae91dc7fff5d0745ab3410ce9e71d127c4b148
Author: Marek Polacek
Date: Wed Jul 1 09:17:17 2020 -0400
C++ DRs: Add new CWGs, update existing ones.
diff --git a/htdocs/projects/cxx-dr-status.html
b/htdocs/projects/cxx-dr-status.html
index 85924fd1..8a107dfd 100644
---
Hi Richard,
on 2020/6/30 下午11:32, Richard Sandiford wrote:
> "Kewen.Lin" writes:
>> Hi Richard,
>>
>> Thanks for the comments!
>>
>> on 2020/6/29 下午6:07, Richard Sandiford wrote:
>>> Thanks for the update. I agree with the summary of the IRC discussion
>>> except for…
>>>
>>> "Kewen.Lin"
Hi Richard,
Many thanks for your great review comments!
on 2020/7/1 上午3:53, Richard Sandiford wrote:
> "Kewen.Lin" writes:
>> diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
>> index 06a04e3d7dd..284c15705ea 100644
>> --- a/gcc/doc/invoke.texi
>> +++ b/gcc/doc/invoke.texi
>> @@ -13389,6
The following patch adds support for the popc and mul.wide instructions to the
nvptx backend.
I've a follow-up patch for supporting mul.hi instructions, but those changes
require some minor
tweaks to GCC's middle-end, so I'll submit those pieces separately.
Tested by "make" and "make -k check"
"Yangfei (Felix)" writes:
>> On June 30, 2020 4:23:03 PM GMT+02:00, Richard Sandiford
>> wrote:
>> >Richard Biener writes:
>> >> So it seems odd to somehow put in the number of vectors... so to me
>> >> it would have made sense if it did
>> >>
>> >> possible_npeel_number = lower_bound
On Tue, 30 Jun 2020 at 15:34, Kyrylo Tkachov wrote:
>
>
>
> > -Original Message-
> > From: Christophe Lyon
> > Sent: 30 June 2020 14:32
> > To: Kyrylo Tkachov
> > Cc: gcc-patches@gcc.gnu.org
> > Subject: Re: [PATCH] arm: Warn if IRQ handler is not compiled with -
> > mgeneral-regs-only
Hi,
> -Original Message-
> From: Richard Biener [mailto:rguent...@suse.de]
> Sent: Tuesday, June 30, 2020 10:50 PM
> To: Richard Sandiford
> Cc: Richard Biener ; Yangfei (Felix)
> ; gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH PR95961] vect: ICE: in exact_div, at poly-int.h:2182
>
> On
Currently s390 emits the following sequence to store a frame_pc:
a:
.LASANPC0:
lg %r1,.L5-.L4(%r13)
la %r1,0(%r1,%r12)
stg %r1,176(%r11)
.L5:
.quad .LASANPC0@GOTOFF
The reason GOT
gcc/ChangeLog:
2020-06-30 Ilya Leoshkevich
* asan.c (asan_emit_stack_protection): Use CODE_LABEL_BOUNDARY.
* defaults.h (CODE_LABEL_BOUNDARY): New macro.
* doc/tm.texi: Document CODE_LABEL_BOUNDARY.
* doc/tm.texi.in: Likewise.
---
gcc/asan.c | 1 +
v1: https://gcc.gnu.org/pipermail/gcc-patches/2019-July/525016.html
v2: https://gcc.gnu.org/pipermail/gcc-patches/2019-July/525069.html
v3: https://gcc.gnu.org/pipermail/gcc-patches/2020-June/548338.html
Andreas suggested that I should split the patch in two, so that common
code and
On Wed, Jul 1, 2020 at 12:32 PM Eric Botcazou wrote:
>
> > + && TREE_CODE (TREE_OPERAND (src, 0)) == STRING_CST
> > + && tree_int_cst_equal
> > +(TYPE_SIZE_UNIT (TREE_TYPE (TREE_OPERAND (src, 0))), len))
> > + {
> >
> > I guess we miss a BITS_PER_UNIT == 8 check
On 7/1/20 1:37 PM, Andreas Schwab wrote:
On Jul 01 2020, Martin Liška wrote:
+ fnotice (file, " -j, --json-format Output JSON intermediate
format \n\
Please avoid the trailing space.
Thanks for heads up, fixed.
Martin
Andreas.
On Jul 01 2020, Martin Liška wrote:
> + fnotice (file, " -j, --json-format Output JSON intermediate
> format \n\
Please avoid the trailing space.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And
On Fri, 26 Jun 2020, Richard Biener wrote:
> (sorry for the duplicate, forgot to copy the list)
>
> This teaches SLP analysis about vector typed externals that are
> fed into the SLP operations via lane extracting BIT_FIELD_REFs.
> It shows that there's currently no good representation for
>
This is something I had lying around since late stage4, re-checked
and pushed now.
Richard.
This moves ISL system header includes to system.h.
* system.h (INCLUDE_ISL): New guarded include.
* graphite-dependences.c: Use it.
* graphite-isl-ast-to-gimple.c: Likewise.
Installed to master.
gcc/ChangeLog:
* gcov.c (print_usage): Shorted option description for -j
option.
---
gcc/gcov.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/gcc/gcov.c b/gcc/gcov.c
index c60f5112d2c..99c52f6a318 100644
--- a/gcc/gcov.c
+++
On 7/1/20 9:49 AM, Richard Biener wrote:
Please keep the old options as aliases, documented as obsoleted in --help.
Good idea! I've done that and made an alias for -i -> -j option.
I'm going to push it to master.
Martin
>From f0564852b5acbc2fcde604308e61109f22815ac1 Mon Sep 17 00:00:00 2001
> + && TREE_CODE (TREE_OPERAND (src, 0)) == STRING_CST
> + && tree_int_cst_equal
> +(TYPE_SIZE_UNIT (TREE_TYPE (TREE_OPERAND (src, 0))), len))
> + {
>
> I guess we miss a BITS_PER_UNIT == 8 check here?
OK, added.
> + gimple_set_vuse (new_stmt,
Hi Richard,
From: Richard Sandiford
> > @@ -3719,6 +3722,7 @@ static unsigned int rest_of_handle_sched (void)
> > { #ifdef INSN_SCHEDULING
> > + first_moveable_pseudo = last_moveable_pseudo;
> >if (flag_selective_scheduling
> >&& ! maybe_skip_selective_scheduling ())
> >
On Tue, 30 Jun 2020, Richard Sandiford wrote:
> Richard Biener writes:
> >> Another thing we'd like for SVE in general is to allow vectors *with*
> >> gaps throughout the SLP graph, since with predication it's simple to
> >> ignore any inactive element where necessary. This is often much
Andrea Corallo writes:
> +/* Initialize all builtins in the AARCH64_BUILTIN_GENERAL group. */
> +
> +void
> +aarch64_general_init_builtins (void)
> +{
> +
Excess blank line here.
> + aarch64_init_fpsr_fpcr_builtins ();
> +
>aarch64_init_fp16_types ();
>
>aarch64_init_bf16_types ();
Hi all,
Second version of the patch addressing comments.
This introduces the following 64bit builtins variants as FPCR and FPSR
registers getter/setter:
unsigned long long __builtin_aarch64_get_fpcr64 ()
void __builtin_aarch64_set_fpcr64 (unsigned long long)
unsigned long long
On Wed, Jul 1, 2020 at 9:12 AM Martin Liška wrote:
>
> Hey.
>
> Even thought an option renaming is a problematic change, I still believe
> the option names were selected poorly and this patch is attempt to improve it.
>
> Thoughts?
Please keep the old options as aliases, documented as obsoleted
On Wed, Jul 1, 2020 at 8:50 AM Eric Botcazou wrote:
>
> Hi,
>
> the GIMPLE store merging pass doesn't merge STRING_CSTs in the general case,
> although they are accepted by native_encode_expr; the reason is that the pass
> only works with integral modes, i.e. with chunks whose size is a power of
On 6/30/20 3:24 PM, Nathan Sidwell wrote:
On 6/30/20 8:53 AM, Martin Liška wrote:
Hey.
The bug reported confirmed that using the direct merging provides a solid
speed and so I don't insist on this patch. Using a generic compression algorithm
would be a better solution anyway.
Thanks for the
- The order of multi-lib config could be wrong if multi-ltter are
used, e.g. `./multilib-generator rv32izfh-ilp32--c`, would expect
rv32ic_zfh/ilp32 reuse rv32i_zfh/ilp32, however the multi-ltter is not
handled correctly, it will generate reuse rule for rv32izfhc/ilp32
which is
On 6/30/20 5:32 PM, Fāng-ruì Sòng wrote:
There is some concern about clang's -fuse-ld=path
http://lists.llvm.org/pipermail/cfe-dev/2020-June/065710.html and use
of COMPILER_PATH vs PATH.
Shall we introduce another option like -fld-path=path (PATH is used,
COMPILER_PATH is not used)?
I would
Hey.
Even thought an option renaming is a problematic change, I still believe
the option names were selected poorly and this patch is attempt to improve it.
Thoughts?
Thanks,
Martin
gcc/ChangeLog:
* doc/gcov.texi: Rename 2 options.
* gcov.c (print_usage): Rename
Please find attached a patch to fix PR95981. Original patch by Steve Kargl.
OK to commit and backport?
Commit message:
Fortran : ICE in gfc_find_array_ref(): No ref found PR95981
When looking for an array reference allow NULL references. If
no array reference is found dim_rank_check
Hi,
the GIMPLE store merging pass doesn't merge STRING_CSTs in the general case,
although they are accepted by native_encode_expr; the reason is that the pass
only works with integral modes, i.e. with chunks whose size is a power of two.
There are two possible ways of extending it to handle
Please find attached a patch which is a fix for PR95612. The original
patch is by Steve Kargl.
OK to commit and backport?
Commit message:
Fortran : ICE in gfc_check_pointer_assign PR95612
Output an error if the right hand value is a zero sized array or
does not have a symbol tree otherwise
83 matches
Mail list logo
