Hi Richard,
> -Original Message-
> From: Richard Sandiford [mailto:richard.sandif...@arm.com]
> Sent: Wednesday, June 3, 2020 1:19 AM
> To: Yangfei (Felix)
> Cc: gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH PR95459] aarch64: ICE in aarch64_short_vector_p, at
> config/aarch64/aarch64.c:16
Hi Richard,
Thanks a lot for your great comments!
on 2020/6/2 下午7:50, Richard Sandiford wrote:
> "Kewen.Lin" writes:
>> Hi Richard,
>>
>> on 2020/5/29 下午4:32, Richard Sandiford wrote:
>>> "Kewen.Lin" writes:
on 2020/5/27 下午6:02, Richard Sandiford wrote:
> "Kewen.Lin" writes:
>> Hi
On 6/2/20 3:19 PM, Martin Liška wrote:
I'm suggesting to pre-allocate 16 gcov_kvp in the gcov run-time library.
Please take a look at the attached patch. I also added a test-case that
stresses that. I've just finished LTO PGO bootstrap of the GCC.
Ready for master?
There's V2 of the patch:
-
We must guard used atomic builtins with GCOV_SUPPORTS_ATOMIC.
The patch is tested on AIX and I'm going to push it.
libgcc/ChangeLog:
PR gcov-profile/95480
* libgcov-profiler.c (GCOV_SUPPORTS_ATOMIC): Move to...
* libgcov.h (GCOV_SUPPORTS_ATOMIC): ...here.
(gcov_co
On 6/3/20 3:07 AM, Gerald Pfeifer wrote:
On Tue, 2 Jun 2020, Martin Liška wrote:
Ready for master?
Before that, my nightly tester on i386-unknown-freebsd11 just ran into
the following:
/scratch/tmp/gerald/GCC-HEAD/gcc/../libgcc/libgcov.h:396:51: error:
cannot initialize a parameter of t
On 6/3/20 5:58 AM, Alexandre Oliva wrote:
Please let me know if you'd prefer me to take this PR over.
Yes, please take a look.
Martin
Frederik Harwath writes:
ping :-)
> Frederik Harwath writes:
>
> Hi Rainer, hi Mike,
> ping: https://gcc.gnu.org/pipermail/gcc-patches/2020-May/545803.html
>
> Best regards,
> Frederik
>
>> Hi Thomas,
>>
>> Thomas Schwinge writes:
>>
>>> I can't formally approve testsuite patches, but did a re
Jiufu Guo via Gcc-patches writes:
Hi,
I would like to reping this, hope to get approval for this patch.
https://gcc.gnu.org/legacy-ml/gcc-patches/2020-02/msg00927.html
BR,
Jiufu Guo
> Jiufu Guo writes:
>
> Hi,
>
> I'd like to ping this patch for trunk on stage 1.
>
> This patch could fix the
Hello, Martin,
On Jun 2, 2020, Martin Liška wrote:
> The problem happens when we generate temp file
> for .res file. Tested locally with the problematic
> options.
Thanks for looking into this.
> Ready for master?
Erhm, no, I don't think that's correct.
With local analysis, the length compu
Hi Richi,
on 2020/6/2 下午7:38, Richard Biener wrote:
> On Thu, 28 May 2020, Kewen.Lin wrote:
>
>> Hi,
>>
>> This is one repost and you can refer to the original series
>> via https://gcc.gnu.org/pipermail/gcc-patches/2020-January/538360.html.
>>
>> As we discussed in the thread
>> https://gcc.gnu
On Mon, Jun 01, 2020 at 05:45:34PM -0500, will schmidt wrote:
> Similar/same comment as was made in Apr.I recommend something like
>
> "Test whether pc-relative prefixed instructions
> are generated for the _Decimal64 type."
Ok, I missed that comment in April.
--
Michael Meissner, IBM
IBM
Hi Richard,
on 2020/6/2 下午3:14, Richard Sandiford wrote:
> "Kewen.Lin" writes:
>> Hi Richard,
>>
>> Thanks for the comments!
>>
>> on 2020/6/2 上午1:59, Richard Sandiford wrote:
>>> Could you go into more detail about this choice of cost calculation?
>>> It looks like we first calculate per-group f
Hi:
When dest is memory, zero-masking is not valid, only merging-masking
is available,
Bootstrap is ok, regression test on i386/x86-64 backend is ok.
gcc/ChangeLog:
* gcc/config/i386/sse.md (*vcvtps2ph_store):
Refine from *vcvtps2ph_store.
(vcvtps2ph256): Refine constr
Richard Biener writes:
> On Tue, Jun 2, 2020 at 4:10 AM Jiufu Guo wrote:
>>
>> Jiufu Guo writes:
>>
>> Hi,
>>
>> I updated the patch just a little accordinlgy. Thanks!
>>
>> diff --git a/gcc/common.opt b/gcc/common.opt
>> index 4464049fc1f..570e2aa53c8 100644
>> --- a/gcc/common.opt
>> +++ b/g
On Tue, 2 Jun 2020, Martin Liška wrote:
> Ready for master?
Before that, my nightly tester on i386-unknown-freebsd11 just ran into
the following:
/scratch/tmp/gerald/GCC-HEAD/gcc/../libgcc/libgcov.h:396:51: error:
cannot initialize a parameter of type 'gcov_type' (aka 'long long')
with a
The compute_objsize() function started out as a thin wrapper around
compute_builtin_object_size(), but over time developed its own
features to compensate for the other function's limitations (such
as its inability to work with ranges). The interaction of these
features and the limitations has sta
On Tue, Jun 02, 2020 at 04:56:49PM -0400, David Edelsohn wrote:
> > > + if (TREE_CODE (type) == RECORD_TYPE
> > > + && rs6000_discover_homogeneous_aggregate (TYPE_MODE (type), type,
> > > NULL,
> > > + NULL))
> > > +{
> > > + tree field_ty
PR jit/95426 reports a crash deep inside "expand" when using
__builtin_unreachable via gcc_jit_context_get_builtin_function,
due to BLOCK_FOR_INSN being erroneously used on a barrier within
rtl_verify_bb_pointers.
The root cause turns out to be that I didn't implement
LANG_HOOKS_COMMON_ATTRIBUTE_T
On Mon, 1 Jun 2020, Feng Xue OS via Gcc-patches wrote:
* match.pd ((PTR + A) - (PTR + B)) -> (ptrdiff_t)(A - B): New
simplification.
Not new, modified.
* ((PTR_A + O) - (PTR_B + O)) -> (PTR_A - PTR_B): New simplification.
O might not be the best choice because of ho
When checking that a constrained partial specialization is more
constrained than the primary template, we pass only the innermost level
of generic template arguments to strictly_subsumes. This leads to us
doing a nonsensical substitution from normalize_concept_check if the
full set of template arg
The same problem also arises for plfs where prefixed_load_p()
doesn't recognize it so we get just lfs in the asm output
with a @pcrel address.
OK for trunk if regstrap on ppc64le passes?
Thanks,
Aaron
PR target/95347
* config/rs6000/rs6000.c (is_stfs_insn): Rename to
On Tue, Jun 2, 2020 at 4:32 PM Segher Boessenkool
wrote:
>
> Hi Xiong Hu,
>
> On Tue, Jun 02, 2020 at 04:41:50AM -0500, Xionghu Luo wrote:
> > Double array in structure as function arguments or return value is accessed
> > by BLKmode, they are stored to stack and load from stack with redundant
> >
Hi Xiong Hu,
On Tue, Jun 02, 2020 at 04:41:50AM -0500, Xionghu Luo wrote:
> Double array in structure as function arguments or return value is accessed
> by BLKmode, they are stored to stack and load from stack with redundant
> conversion from DF->DI->DF. This patch checks the homogeneous type an
On 24/05/20 15:43 +0200, François Dumont via Libstdc++ wrote:
Now tested in C++98 mode, there was indeed a small problem.
I even wonder if I shouldn't have extend the std::copy overload to any
call with deque iterator as the output so that it is transform into an
output to pointer.
Ok to co
When determining the most specialized partial specialization of a
primary template that is nested inside a class template, we first
tsubst the outer template arguments into the TEMPLATE_DECL of each
partial specialization, and then check for satisfaction of the new
TEMPLATE_DECL's constraints.
But
Here, the capture proxy for *this is const, but its DECL_VALUE_EXPR is not.
Don't ICE on this; it's a reasonable difference, since in C++ an rvalue of
scalar type does not have cv-qualifiers.
Tested x86_64-pc-linux-gnu, applying to trunk.
gcc/cp/ChangeLog:
PR c++/95193
* pt.c (ts
[I'll start by repeating what I wrote about a similar libgcc change to
provide background and context.]
When AIX added 64 bit support, it implemented what Apple MacOS Darwin
calls "FAT" libraries for its equivalent functionality -- both 32 bit
and 64 bit objects (or shared objects) are co-located
The ISA manual specifies that divide by zero always returns -1 as the result.
We were failing to do that when the dividend was negative.
Tested with cross toolchain builds for riscv32-elf and riscv64-linux. There
were no regressions.
Committed.
Jim
libgcc/
* config/riscv/div.S
On Fri, May 29, 2020 at 1:53 AM MOSER Virginie via Gcc-patches
wrote:
> The assembly code in libgcc/config/riscv/div.S does not handle the division
> by zero as specified in the riscv-spec v2.2 chapter 6.2 in case of signed
> division:
This looks OK. There are some administrative comments to m
Remove occurrences of auxbase that remained in comments.
Regstrapped on x86_64-linux-gnu. Pre-approved by Arno.
for gcc/ada/ChangeLog
* lib.ads (Compilation_Switches): Remove -auxbase from
comments.
* switch.ads (Is_Internal_GCC_Switch): Likewise.
---
ada/lib.ads|
On Sat, 2020-05-30 at 18:51 +, Pip Cet wrote:
> On Sat, May 30, 2020 at 5:06 PM David Malcolm
> wrote:
> > On Sat, 2020-05-30 at 13:40 +, Pip Cet via Gcc-patches wrote:
> > > I think we should just omit the triangle inequality test from the
> > > self-test, as in the attached patch.
> >
>
On Mon, 2020-06-01 at 14:11 -0600, Tom Tromey wrote:
> > Did the full DejaGnu testsuite get run? There are a lot of tests
> > in it
> > that make use of this code.
>
> I did "make check" and only saw some XFAILs.
>
> Here's v2 of the patch, which I think addresses your comments. I did
> not add
"Yangfei (Felix)" writes:
> Hi,
>
> Please review this trivial patch fixing an ICE in aarch64_short_vector_p.
> Bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95459
>
> In aarch64_short_vector_p, we are simply checking whether a type (and a
> mode)
> is a 64/128-bit short vect
When given a type which can convert to any container-like type, the
C(const C&) copy constructor and C(const C::_Base&) converting
constructor are ambiguous. This change replaces the converting
constructor's parameter with a reference_wrapper-like type so that
calling that constructor requires an a
[Starting with tne VN issue]
> For the VN case the issue is interpreting a read via memcpy (non
> reverse-storage) as a reverse-storage one when matching up with a hashtable
> entry from a regular reverse-storage order store, correct?
It's a read from a scalar (hence native order) combined with a
On Tue, Jun 02, 2020 at 12:50:25PM +0100, Richard Sandiford wrote:
> This might not be the best time to bring this up :-) but it seems
> odd to be asking the target for the induction variable type here.
> I got the impression that the hook was returning DImode, whereas
> the PowerPC instructions on
Hi all,
This patch adds support for the Arm Zeus CPU.
Bootstrapped and tested on aarch64-none-linux-gnu.
Committing to the GCC 8 branch.
Thanks,
Kyrill
gcc/
2020-06-02 Kyrylo Tkachov
* config/aarch64/aarch64-cores.def (zeus): Define.
* config/aarch64/aarch64-tune.md: Regener
Hi all,
This patch adds support for the Arm Zeus CPU.
Bootstrapped and tested on aarch64-none-linux-gnu.
Committing to the GCC 9 branch.
Thanks,
Kyrill
2020-06-02 Kyrylo Tkachov
* config/aarch64/aarch64-cores.def (zeus): Define.
* config/aarch64/aarch64-tune.md: Regenerate.
On Tue, Jun 02, 2020 at 12:52:31PM +0200, Richard Biener wrote:
> On Tue, Jun 2, 2020 at 11:43 AM Xionghu Luo via Gcc-patches
> wrote:
> > Double array in structure as function arguments or return value is accessed
> > by BLKmode, they are stored to stack and load from stack with redundant
> > con
Hi all,
This patch adds support for the Arm Zeus CPU.
Bootstrapped and tested on aarch64-none-linux-gnu.
Committing to trunk (and to the GCC 10 branch).
Thanks,
Kyrill
gcc/
2020-06-02 Kyrylo Tkachov
* config/aarch64/aarch64-cores.def (zeus): Define.
* config/aarch64/aarch64-
On 5/28/20 8:46 PM, David Malcolm via Gcc-patches wrote:
> On Thu, 2020-05-28 at 16:51 -0300, Nicolas Bértolo wrote:
>>> I'm going to have to trust your Windows expertise here; the tempdir
>>> code looks convoluted to me, but perhaps that's the only way to do
>> it.
>>> (Microsoft's docs for "SECUR
Hi,
this patch makes tree referneces to be stream by one integer rather then
by pair of tag and index. This makes function streams about 3% smaller
and reduces number of ulebs we stream (that still shows high in
profiles).
lto-bootstrapped/regtested x86_64-linux, comitted.
Honza
* lto-s
On 6/2/20 1:09 PM, Richard Biener wrote:
So please be constructive. Like, provide a testcase that ICEs
with the FAILs replaced by gcc_unreachable (). Martin, may I suggest
to do this replacement and bootstrap/test? I think it would be nice
to have testsuite coverage for the FAILs, and maybe we
This patch removes the vestiges of the GCN-specific -mlocal-symbol-id
option. Previously, this was part of a horrible workaround for a bug in
the Radeon Open Compute ELF loader. The bug has been fixed a while now,
and the name mangling has not been present in the compiler for a while,
so the op
On 6/2/20 4:14 PM, Jonathan Wakely wrote:
On Tue, 2 Jun 2020 at 14:56, Jonathan Wakely wrote:
On Tue, 2 Jun 2020 at 14:16, Martin Liška wrote:
On 6/2/20 1:48 PM, Martin Liška wrote:
I tend to this approach. Let me prepare a patch candidate for it.
There's a patch for it. Can you please J
Hi
Any feedback regarding this patch ?
François
On 26/05/20 1:45 pm, François Dumont wrote:
On 24/05/20 3:43 pm, François Dumont wrote:
Now tested in C++98 mode, there was indeed a small problem.
I even wonder if I shouldn't have extend the std::copy overload to
any call with deque iterato
On Tue, 2 Jun 2020 at 14:56, Jonathan Wakely wrote:
>
> On Tue, 2 Jun 2020 at 14:16, Martin Liška wrote:
> >
> > On 6/2/20 1:48 PM, Martin Liška wrote:
> > > I tend to this approach. Let me prepare a patch candidate for it.
> >
> > There's a patch for it. Can you please Jonathan take a look?
>
>
> From: Alexandre Oliva
> Date: Tue, 2 Jun 2020 13:29:03 +0200
> Hello, Anthony, H-P,
>
> On May 27, 2020, Anthony Green wrote:
>
> > Hans-Peter Nilsson via Gcc-patches writes:
> >> And here's an improper bug report.
> >>
> >> One of the commits between cfdff3eeb90..5c8344e7289 caused every
On 6/2/20 3:56 PM, Jonathan Wakely wrote:
On Tue, 2 Jun 2020 at 14:16, Martin Liška wrote:
On 6/2/20 1:48 PM, Martin Liška wrote:
I tend to this approach. Let me prepare a patch candidate for it.
There's a patch for it. Can you please Jonathan take a look?
Looks great, thanks!
+
Hello,
The operands in RTL patterns of MVE vector scatter store intrinsics are wrongly
grouped, because of which few
vector loads and stores instructions are wrongly getting optimized out with -O2.
A new predicate "mve_scatter_memory" is defined in this patch, this predicate
returns TRUE on
mat
This patch uses parameter packs to define insn_gen_fn::operator().
I guess in some ways it's C++-ification for its own sake, but it does
make things simpler and removes the current artificial limit of 16
arguments.
Note that the call is still strongly typed: all arguments have to have
implicit con
On Tue, 2 Jun 2020 at 14:16, Martin Liška wrote:
>
> On 6/2/20 1:48 PM, Martin Liška wrote:
> > I tend to this approach. Let me prepare a patch candidate for it.
>
> There's a patch for it. Can you please Jonathan take a look?
Looks great, thanks!
+if name not in wildcard_prefixe
On 6/2/20 10:27 AM, Jan Hubicka wrote:
The patch looks good (and is OK for mainline). I am bit concerned about
two things.
Hello.
Thank you for the review!
1) I think we should add support to pre-allocate memory pool so we hide
the problem with instrumenting malloc (I think with big eno
On 6/2/20 1:48 PM, Martin Liška wrote:
I tend to this approach. Let me prepare a patch candidate for it.
There's a patch for it. Can you please Jonathan take a look?
Thanks,
Martin
>From 4d2cf31b6deb03c9ddc8062b9a45d2511e4a58bb Mon Sep 17 00:00:00 2001
From: Martin Liska
Date: Tue, 2 Jun 2020
On Fri, May 29, 2020 at 8:52 PM Erick Ochoa
wrote:
>
>
>
> This pass is a variant of constant propagation where global
> primitive constants with a single write are propagated to multiple
> read statements.
Just a few small comments while skimming through the code
> ChangeLog:
>
> 2020-05-20 Er
On Fri, May 29, 2020 at 8:44 PM Erick Ochoa
wrote:
>
> Hello everyone,
>
> I wanted to highlight this ticket on bugzilla [0]. It is a missed
> optimization that I worked on. It involves propagating constants across
> function calls at link-time. I am relatively new to GCC and this would
> be my fi
On 02/06/2020 14:29, Richard Biener wrote:
On Sat, May 30, 2020 at 12:18 AM Jan Hubicka wrote:
---
gcc/tree.h | 11 +++
1 file changed, 11 insertions(+)
diff --git a/gcc/tree.h b/gcc/tree.h
index bd0c51b2a18..86a4542f58b 100644
--- a/gcc/tree.h
+++ b/gcc/tree.h
@@ -6156,6 +615
On Sat, May 30, 2020 at 12:18 AM Jan Hubicka wrote:
>
> >
> > ---
> > gcc/tree.h | 11 +++
> > 1 file changed, 11 insertions(+)
> >
> > diff --git a/gcc/tree.h b/gcc/tree.h
> > index bd0c51b2a18..86a4542f58b 100644
> > --- a/gcc/tree.h
> > +++ b/gcc/tree.h
> > @@ -6156,6 +6156,17 @@ int_b
On Tue, 2 Jun 2020, Alexandre Oliva wrote:
> On May 27, 2020, Alexandre Oliva wrote:
>
> > - The prepending of -Wl, to file names in ldflags et al was done in a
> > way that introduced empty arguments when consecutive blanks appeared
> > in these board configuration knobs. Skip the empty string
The calloc was in the original tested version of the patch
and I made accidental last minute change.
Installed to master as obvious.
libgcc/ChangeLog:
* libgcov.h (gcov_topn_add_value): Use xcalloc instead
of xmalloc.
---
libgcc/libgcov.h | 2 +-
1 file changed, 1 insertion(+),
On Thu, 28 May 2020, Martin Jambor wrote:
> PR 93385 reveals that if the user explicitely disables DCE, IPA-SRA
> can leave behind statements which are useless because their results
> are eventually not used but can have problematic side effects,
> especially since their inputs are now bogus that
On May 27, 2020, Alexandre Oliva wrote:
> - The prepending of -Wl, to file names in ldflags et al was done in a
> way that introduced empty arguments when consecutive blanks appeared
> in these board configuration knobs. Skip the empty strings between
> consecutive blanks to avoid this problem.
"Kewen.Lin" writes:
> Hi Richard,
>
> on 2020/5/29 下午4:32, Richard Sandiford wrote:
>> "Kewen.Lin" writes:
>>> on 2020/5/27 下午6:02, Richard Sandiford wrote:
"Kewen.Lin" writes:
> Hi Richard,
>
>
> Snip ...
>
>>>
>>> Thanks a lot for your detailed explanation! This proposal looks go
On 6/2/20 1:22 PM, Jonathan Wakely via Gcc-patches wrote:
On Tue, 2 Jun 2020 at 12:09, Jonathan Wakely wrote:
On Tue, 2 Jun 2020 at 12:05, Jonathan Wakely wrote:
On Tue, 2 Jun 2020 at 11:56, Gerald Pfeifer wrote:
On Mon, 1 Jun 2020, Jonathan Wakely via Gcc-patches wrote:
The libstdc++ m
On Thu, 28 May 2020, Martin Jambor wrote:
> PR 95113 revealed that when reasoning about which parameters are dead,
> IPA-SRA does not perform the same check related to non-call exceptions
> as tree DCE. It most certainly should and so this patch moves the
> condition used in tree-ssa-dce.c into a
On Thu, 28 May 2020, Kewen.Lin wrote:
> Hi,
>
> This is one repost and you can refer to the original series
> via https://gcc.gnu.org/pipermail/gcc-patches/2020-January/538360.html.
>
> As we discussed in the thread
> https://gcc.gnu.org/ml/gcc-patches/2020-01/msg00196.html
> Original: https://
Hello, Anthony, H-P,
On May 27, 2020, Anthony Green wrote:
> Hans-Peter Nilsson via Gcc-patches writes:
>> And here's an improper bug report.
>>
>> One of the commits between cfdff3eeb90..5c8344e7289 caused every
>> single *linked* test to fail for cris-elf, like:
> I can confirm that the mox
On Fri, 29 May 2020, Hao Liu OS wrote:
> Hi Richard,
>
> Thanks for your comments. It's a good idea to simplify the code and remove
> get_inner_reference. I've updated the patch accordingly. I also simplified
> the code to ignore other loads, which can not help to check if a store can be
> tra
On Tue, 2 Jun 2020 at 12:09, Jonathan Wakely wrote:
>
> On Tue, 2 Jun 2020 at 12:05, Jonathan Wakely wrote:
> >
> > On Tue, 2 Jun 2020 at 11:56, Gerald Pfeifer wrote:
> > >
> > > On Mon, 1 Jun 2020, Jonathan Wakely via Gcc-patches wrote:
> > > > The libstdc++ manual is written in Docbook XML, bu
The usual stupid confusion between bits and bytes... The tree-pretty-print.c
hunk is unrelated and has been approved by Richard elsewhere.
Tested on SPARC64/Linux, applied on the mainline as obvious.
2020-06-02 Eric Botcazou
PR middle-end/95395
* optabs.c (expand_unop): Fix
"Yangfei (Felix)" writes:
> Hi,
>
>> -Original Message-
>> From: Richard Sandiford [mailto:richard.sandif...@arm.com]
>> Sent: Monday, June 1, 2020 4:47 PM
>> To: Yangfei (Felix)
>> Cc: gcc-patches@gcc.gnu.org; Uros Bizjak ; Jakub
>> Jelinek ; Hongtao Liu ; H.J. Lu
>>
>> Subject: Re: [PA
On Tue, Jun 2, 2020 at 4:10 AM Jiufu Guo wrote:
>
> Jiufu Guo writes:
>
> Hi,
>
> I updated the patch just a little accordinlgy. Thanks!
>
> diff --git a/gcc/common.opt b/gcc/common.opt
> index 4464049fc1f..570e2aa53c8 100644
> --- a/gcc/common.opt
> +++ b/gcc/common.opt
> @@ -2856,6 +2856,10 @@
On Sat, May 30, 2020 at 3:08 PM Segher Boessenkool
wrote:
>
> Hi!
>
> On Sat, May 30, 2020 at 08:15:55AM +0100, Richard Sandiford wrote:
> > Segher Boessenkool writes:
> > >> Sure. But the point is that FAILing isn't “explicitly allowed” for
> > >> vcond*.
> > >> In fact it's the opposite.
>
>
On Tue, 2 Jun 2020 at 12:05, Jonathan Wakely wrote:
>
> On Tue, 2 Jun 2020 at 11:56, Gerald Pfeifer wrote:
> >
> > On Mon, 1 Jun 2020, Jonathan Wakely via Gcc-patches wrote:
> > > The libstdc++ manual is written in Docbook XML, but we commit both the
> > > XML and generated HTML pages to Git. Som
On Tue, 2 Jun 2020 at 07:44, Martin Liška wrote:
>
> On 6/1/20 7:24 PM, Jonathan Wakely wrote:
> > On Mon, 25 May 2020 at 23:50, Jakub Jelinek via Gcc
> > wrote:
> >>
> >> Hi!
> >>
> >> I've turned the strict mode of Martin Liška's hook changes,
> >> which means that from now on no commits to th
On Tue, 2 Jun 2020 at 11:56, Gerald Pfeifer wrote:
>
> On Mon, 1 Jun 2020, Jonathan Wakely via Gcc-patches wrote:
> > The libstdc++ manual is written in Docbook XML, but we commit both the
> > XML and generated HTML pages to Git. Sometimes a small XML file can
> > result in dozens of mechanical ch
Ping
On Tue, May 19, 2020 at 08:33:24AM +0200, Stefan Schulze Frielinghaus via
Gcc-patches wrote:
> While bootstrapping GCC on S/390 the following warning is raised:
>
> gcc/fortran/matchexp.c: In function 'match match_level_5(gfc_expr**)':
> gcc/fortran/matchexp.c:401:18: error: 'e' may be used
On Mon, 1 Jun 2020, Jonathan Wakely via Gcc-patches wrote:
> The libstdc++ manual is written in Docbook XML, but we commit both the
> XML and generated HTML pages to Git. Sometimes a small XML file can
> result in dozens of mechanical changes to the generated HTML files,
> which we record in the Ch
Hi,
Like a similarly named function in the visitor class for statements,
this ensures that the current input_location is set to the correct
source file location of the decl.
It is likely that there are a number of cases where declarations have
ended up with no location without this.
Bootstrapped
On Tue, Jun 2, 2020 at 11:43 AM Xionghu Luo via Gcc-patches
wrote:
>
> Double array in structure as function arguments or return value is accessed
> by BLKmode, they are stored to stack and load from stack with redundant
> conversion from DF->DI->DF. This patch checks the homogeneous type and
> u
On 02/06/20 11:18 +0100, Jonathan Wakely wrote:
On 02/06/20 11:37 +0200, Martin Liška wrote:
On 6/2/20 11:23 AM, Jonathan Wakely wrote:
On 02/06/20 10:22 +0100, Jonathan Wakely wrote:
This error is wrong, the line is what exceeds LINE_LIMIT characters, the
limit doesn't exceed itself.
contrib
On Fri, May 29, 2020 at 01:57:30PM +0200, Andreas Krebbel wrote:
> On 28.05.20 20:24, Stefan Schulze Frielinghaus wrote:
> > Vector alignment hints are fully supported since z14. On z13 alignment
> > hints have no effect, however, instructions with alignment hints are
> > still legal. Thus, emit
On 02/06/20 11:37 +0200, Martin Liška wrote:
On 6/2/20 11:23 AM, Jonathan Wakely wrote:
On 02/06/20 10:22 +0100, Jonathan Wakely wrote:
This error is wrong, the line is what exceeds LINE_LIMIT characters, the
limit doesn't exceed itself.
contrib/ChangeLog:
* gcc-changelog/git_commit.py (G
On Tue, Jun 02, 2020 at 11:26:37AM +0200, Sebastian Huber wrote:
> with this patch I get the following error for target arm-rtems6:
>
> ../../../gnu-mirror-gcc-86b14bb/libgomp/allocator.c: In function 'omp_free':
> ../../../gnu-mirror-gcc-86b14bb/libgomp/allocator.c:351:42: error: 'struct
> omp_me
Double array in structure as function arguments or return value is accessed
by BLKmode, they are stored to stack and load from stack with redundant
conversion from DF->DI->DF. This patch checks the homogeneous type and
use the actual element type to do block move to by pass the conversions.
gcc/C
On 6/2/20 11:23 AM, Jonathan Wakely wrote:
On 02/06/20 10:22 +0100, Jonathan Wakely wrote:
This error is wrong, the line is what exceeds LINE_LIMIT characters, the
limit doesn't exceed itself.
contrib/ChangeLog:
* gcc-changelog/git_commit.py (GitCommit.parse_changelog): Fix
* grammar.
On 6/2/20 11:22 AM, Jonathan Wakely wrote:
OK for master?
You're right.
Please install it.
Martin
On Fri, May 29, 2020 at 5:56 AM Naveen Hurugalawadi via Gcc-patches
wrote:
>
> Hi,
>
> Please find attached the patch that addresses PR94882.
>
> Bootstrapped and regression tested on x86_64-pc-linux-gnu.
Is the pattern correct for saturating arithmetic? Some related
patterns test !TYPE_SATURATI
Hello,
On 19/05/2020 10:24, Jakub Jelinek via Gcc-patches wrote:
+ gomp_mutex_lock (&allocator_data->lock);
+ if (__builtin_add_overflow (allocator_data->used_pool_size, new_size,
+ &used_pool_size)
+ || used_pool_size > allocator_data->pool_size
On 02/06/20 10:22 +0100, Jonathan Wakely wrote:
This error is wrong, the line is what exceeds LINE_LIMIT characters, the
limit doesn't exceed itself.
contrib/ChangeLog:
* gcc-changelog/git_commit.py (GitCommit.parse_changelog): Fix
* grammar.
OK for master?
commit ba4ddb102
This error is wrong, the line is what exceeds LINE_LIMIT characters, the
limit doesn't exceed itself.
contrib/ChangeLog:
* gcc-changelog/git_commit.py (GitCommit.parse_changelog): Fix
* grammar.
OK for master?
commit ba4ddb1023844202f84a32275e451f9c7a0bb7b7
Author: Jonathan Wake
On 6/2/20 11:16 AM, Jonathan Wakely wrote:
OK for master?
I like the patch.
Martin
If a user installs this script as .git/hooks/prepare-commit-msg and then
works on an old branch which doesn't have the mklog.py script, trying to
commit will fail with an error like:
environment: /.../gcc/contrib/mklog.py: No such file or directory
This makes it exit cleanly so it's possible to c
PING^2
On 5/15/20 11:58 AM, Martin Liška wrote:
We're in stage1: PING^1
On 4/3/20 8:15 PM, Egeyar Bagcioglu wrote:
On 3/18/20 10:05 AM, Martin Liška wrote:
On 3/17/20 7:43 PM, Egeyar Bagcioglu wrote:
Hi Martin,
I like the patch. It definitely serves our purposes at Oracle and provides
an
OK?
Yes.
The problem happens when we generate temp file
for .res file. Tested locally with the problematic
options.
Ready for master?
Thanks,
Martin
gcc/ChangeLog:
PR driver/95456
* gcc.c (do_spec_1): Append to tempfile only when
input_basename != NULL.
---
gcc/gcc.c | 2 +-
1 f
Hi Richard,
on 2020/5/29 下午4:32, Richard Sandiford wrote:
> "Kewen.Lin" writes:
>> on 2020/5/27 下午6:02, Richard Sandiford wrote:
>>> "Kewen.Lin" writes:
Hi Richard,
Snip ...
>>
>> Thanks a lot for your detailed explanation! This proposal looks good
>> based on the current implementa
This further tweaks the expanded code generated by the front-end, so as
to avoid having references to Universal_Integer reaching the code
generator, either directly or indirectly through attributes returning
Universal_Integer. There is also a minor tweak to the a-sequio.adb unit
of the runtime to t
This further tweaks the expanded code generated by the front-end, so as
to avoid having references to Universal_Integer reaching the code
generator, either directly or indirectly through attributes returning
Universal_Integer.
The reason is that Universal_Integer must be a type as large as the
lar
In order to simplify the long term maintenance of the GNAT frontend,
support for generating trees for ASIS is removed from trunk. ASIS is
being phased out at this stage in favor of Libadalang.
Tested on x86_64-pc-linux-gnu, committed on trunk
2020-06-02 Arnaud Charlet
gcc/ada/
* atre
1 - 100 of 126 matches
Mail list logo
