Howdy.
There's really no reason why the array bounds code should live in
tree-vrp, when all it really needs is a get_value_range() call back.
Particularly painful is that it partially lives inside the vrp_prop class.
This patch moves the array bounds code into its own class, while taking
in
Funny, I had queued up more or less the same changes on my tree, but
Giuliano beat me to it.
I am committing the attached patch that has been approved by Jeff.
I moved a couple more functions into the vrp_insert class, as well as
abstract out the liveness bitmap into its own class. I also rename
Missed this on the previous patch. The method live_on_edge() no
longer needs to be inside the vrp_insert class. I've removed the
prototype.
Committed to mainline.
On Sun, May 17, 2020 at 1:35 PM Aldy Hernandez wrote:
>
> Funny, I had queued up more or less the same changes on my tree, but
> Gi
There's no reason to export operand_less_p from tree-vrp when its only
use is in vr-values.c. Function moved.
Committed as obvious.
Aldy
commit 8bfc81876f9325891a52d036a9c454d0c81b3033
Author: Aldy Hernandez
Date: Fri May 8 13:36:32 2020 +0200
Move operand_less_p to vr-values.c.
diff
Whoops, I seem to have a discrepancy in my local tree and upstream.
I've reverted this patch.
Aldy
On 5/17/20 1:50 PM, Aldy Hernandez wrote:
There's no reason to export operand_less_p from tree-vrp when its only
use is in vr-values.c. Function moved.
Committed as obvious.
Aldy
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'gcc' has been submitted
by the Swedish team of translators. The file is available at:
https://translationproject.org/latest/gcc/sv.po
(This file, 'gcc-10.1.0.sv.po', has ju
Having noticed this in some other case I went through all of our
pages and found this this instance in the GCC 10 release notes where
.
commit f1d2be6c9fcc52d676266e7ede123953d150aaf3
Author: Jonathan Wakely
Date: Thu May 7 11:24:04 2020 +0100
Document C++17 ABI changes in GC
On Thu, Nov 3, 2016 at 12:51 AM Uros Bizjak wrote:
>
> Hello!
>
> > This patch adds a test to the cmpstrnsi pattern in i386.md so that it
> > will bail out (FAIL) if neither of the strings is a constant string. It
> > can only work as a proper strncmp if the length is not longer than both
> > of t
Hi,
This patch has been backported from mainline r11-154.
The ICE is also present on the gcc-9 branch, and this applies cleanly
there as well, so will send out another email for that backport.
Bootstrapped and regression tested on x86_64-linux-gnu, and committed to
the gcc-10 branch.
Regards
Ia
Hi,
This patch is the gcc-9 backport of mainline r11-154 / gcc-10 r10-8149.
Bootstrapped and regression tested on x86_64-linux-gnu, and committed to
the gcc-9 branch.
Regards
Iain
---
gcc/d/ChangeLog:
PR d/94970
* d-codegen.cc (force_target_expr): Move create_temporary_var
On Sat, May 16, 2020 at 8:13 PM H.J. Lu wrote:
>
> On Fri, May 15, 2020 at 11:21:30AM +0200, Uros Bizjak wrote:
> > On Wed, May 13, 2020 at 5:58 PM H.J. Lu wrote:
> >
> > > > > > The question is, why STV pass creates its funny sequence? The
> > > > > > original
> > > > > > sequence should be eas
On Fri, 8 May 2020, Uros Bizjak wrote:
>> A user reported that gcc -m32 on x86-64 does not define __ILP32__
>> and I found the same on i686 (with gcc -x c -dM -E /dev/null).
:
>> This patch does the same for all "regular" 32-bit x86 targets.
>> Tested on i386-unknown-freebsd11.3 so far.
> OK.
Than
On Sun, May 17, 2020 at 6:14 PM Gerald Pfeifer wrote:
>
> On Fri, 8 May 2020, Uros Bizjak wrote:
> >> A user reported that gcc -m32 on x86-64 does not define __ILP32__
> >> and I found the same on i686 (with gcc -x c -dM -E /dev/null).
> :
> >> This patch does the same for all "regular" 32-bit x86
On Sun, May 17, 2020 at 9:07 AM Uros Bizjak wrote:
>
> On Sat, May 16, 2020 at 8:13 PM H.J. Lu wrote:
> >
> > On Fri, May 15, 2020 at 11:21:30AM +0200, Uros Bizjak wrote:
> > > On Wed, May 13, 2020 at 5:58 PM H.J. Lu wrote:
> > >
> > > > > > > The question is, why STV pass creates its funny sequ
Hi,
This patch merges the D runtime library with upstream druntime 5cc061a8,
and the D standard library with upstream phobos 64ed4684f.
Fixes included within are:
- core.cpuid has been fixed to not use i7 detection on AMD processors
(fixes PR95166).
- std.net.curl has been fixed to correctl
Duplicate the cmpstrn pattern for cmpmem. The only difference is that
the length argument of cmpmem is guaranteed to be less than or equal to
lengths of 2 memory areas. Since "repz cmpsb" can be much slower than
memcmp function implemented with vector instruction, see
https://gcc.gnu.org/bugzill
Hi,
This patch backports r11-445 to the gcc-10 release branch.
Bootstrapped and regression tested on x86_64-linux-gnu, and committed.
Regards,
Iain.
---
libphobos/ChangeLog:
PR d/95166
* libdruntime/core/cpuid.d (cpuidX86): Do not use i7 detection on AMD
processors.
This patch collapses a couple existing patterns (branch_true, branch_false) into
a single pattern and updates all the combiner/peephole branches to use the same
basic structure. This makes the cc0->CC_REG transition easier in a variety of
ways, particularly with optimizing compare/branch sequences
Hi,
This avoids a (bogus) warning that occurs with some bootstrap
compilers.
tested on x86-64-darwin, x86-64-linux-gnu,
applied to master as obvious,
thanks
Iain
gcc/cp/ChangeLog:
2020-05-17 Iain Sandoe
* coroutines.cc (morph_fn_to_coro): Initialize the
gro variable.
---
gc
Ne plus rien recevoir de notre part
Hi,
While trying out -fanalyzer on the bzip2 source code I noticed that it
did warn about some unsafe calls in the signal handler, but din't warn
about the exit call:
https://sourceware.org/pipermail/bzip2-devel/2020q2/000107.html
It was easy to add exit to the async_signal_unsafe_fns, but since
Am 15.05.20 um 22:33 schrieb Harald Anlauf:
Here's a new attempt to finally fix this PR and any known fallout.
In order to handle division by zero in declarations, but still accept the
code snippet adapted from 521.wrf_r (from spec2017), I removed the hunk
that was added to fix PR94399, and defe
On Mon, 2020-05-18 at 00:05 +0200, Mark Wielaard wrote:
> Hi,
>
> While trying out -fanalyzer on the bzip2 source code I noticed that
> it
> did warn about some unsafe calls in the signal handler,
Great.
> but din't warn
> about the exit call:
> https://sourceware.org/pipermail/bzip2-devel/2020
On Sun, 2020-05-17 at 18:39 -0400, David Malcolm via Gcc-patches wrote:
> On Mon, 2020-05-18 at 00:05 +0200, Mark Wielaard wrote:
[...snip...]
> How about something like this (though I even haven't checked if it
> compiles, and am not 100% sure what the wording should be):
>
> bool emit (rich_
On Mon, 2020-05-18 at 00:05 +0200, Mark Wielaard wrote:
> Hi,
>
> While trying out -fanalyzer on the bzip2 source code I noticed that
> it
> did warn about some unsafe calls in the signal handler, but din't
> warn
> about the exit call:
> https://sourceware.org/pipermail/bzip2-devel/2020q2/000107.
Hi,
This changes the definition of Pmode for aarch64 port.
Unlike x86, S390 etc., Pmode is always set to DImode for aarch64 port even
under ILP32.
Because of that definition, machine mode of symbol_ref which is supposed to be
SImode becomes DImode under target ILP32.
Definition of Pmode should
On Sun, May 17, 2020 at 8:23 PM duanbo (C) wrote:
>
> Hi,
>
> This changes the definition of Pmode for aarch64 port.
> Unlike x86, S390 etc., Pmode is always set to DImode for aarch64 port even
> under ILP32.
> Because of that definition, machine mode of symbol_ref which is supposed to
> be SIm
Please find attache a patch for PR39695
Commit message:
Fortran : ProcPtr function results: 'ppr@' in error message PR39695
The value 'ppr@' is set in the name of result symbol, the actual
name of the symbol is in the procedure name symbol pointed
to by the result symbol's namespace (ns). When
28 matches
Mail list logo
