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
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
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
>>
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
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
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
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
>> +++
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
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
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
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
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
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
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
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
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.
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
[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
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
"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
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
[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
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
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:
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
> >
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.
*
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
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
*
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
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
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
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
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
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
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
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
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
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
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
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
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 @@
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
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
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
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++
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
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:
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
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
>
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,
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:
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.
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
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
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
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
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.
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
>
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.
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
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
>
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.
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
Hello,
On 19/05/2020 10:24, Jakub Jelinek via Gcc-patches wrote:
+ gomp_mutex_lock (_data->lock);
+ if (__builtin_add_overflow (allocator_data->used_pool_size, new_size,
+ _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
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
On 6/2/20 11:16 AM, Jonathan Wakely wrote:
OK for master?
I like the patch.
Martin
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
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
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
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
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
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
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/
*
When doing subprogram unnesting for GNAT-LLVM (or CCG), the compiler can
crash when it tries to access an unreachable enclosing subprogram that
contains nested subprograms that are marked reachable due to having
Access or Unchecked_Access applied to them. This is fixed by ensuring
that the
The Treat_Fixed_As_Integer mechanism has been degenerate for quite
some time and the flag is only set on divide nodes at this point.
We can use the same trick as in the multiply case to get rid of it
altogether, with the positive by-product that the compiler will stop
doing divisions of small
Use statement SCO code 'X' to specifically identify the statement SCOs
for degenerate subprogram bodies (null procedures and expression
functions). This allows coverage analysis tools to apply specific
processing for these cases if necessary, and ensures consistency with
SCOs generated through
The compiler crashes processing the body of dispatching primitive that
is a function whose controlling type is a tagged private type and its
full view is a derivation of a controlled type.
Tested on x86_64-pc-linux-gnu, committed on trunk
2020-06-02 Javier Miranda
gcc/ada/
*
This changes the type set on bit references made to packed arrays:
instead of Universal_Integer, it is set to Standard.Natural.
The reason is that Universal_Integer must be a type as large as the
largest supported integer type and, therefore, can be much larger than
what is really needed here.
1 - 100 of 125 matches
Mail list logo
