Pushed attached patch.
Thanks.
Aldy
On Tue, Sep 24, 2024 at 10:09 AM Filip Kastl wrote:
> On Mon 2024-09-23 09:43:28, Aldy Hernandez wrote:
> > From: Aldy Hernandez
> >
> > ChangeLog:
> >
> > * MAINTAINERS: Update email and add myself to
From: Aldy Hernandez
ChangeLog:
* MAINTAINERS: Update email and add myself to DCO.
---
MAINTAINERS | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index cfd96c9f33e..e9fafaf45a7 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -116,7
4 at 11:37 PM Jason Merrill wrote:
>
> On 4/30/24 12:22, Jakub Jelinek wrote:
> > On Tue, Apr 30, 2024 at 03:09:51PM -0400, Jason Merrill via Gcc wrote:
> >> On Fri, Apr 26, 2024 at 5:44 AM Aldy Hernandez via Gcc
> >> wrote:
> >>>
> >>> I
On Tue, Apr 30, 2024 at 9:58 AM Richard Biener
wrote:
>
> On Fri, Apr 26, 2024 at 11:45 AM Aldy Hernandez via Gcc
> wrote:
> >
> > Hi folks!
> >
> > In implementing prange (pointer ranges), I have found a 1.74% slowdown
> > in VRP, even without any cod
Notice there are no
uses of prange yet.
Thanks.
Aldy
From ee63833c5f56064ef47c2bb9debd485f77d00171 Mon Sep 17 00:00:00 2001
From: Aldy Hernandez
Date: Tue, 19 Mar 2024 18:04:55 +0100
Subject: [PATCH] Move get_bitmask_from_range out of irange class.
---
gcc
After GCC 13 is released we will remove legacy range support from the
compiler, and convert irange's to wide_ints. I want to give everyone
a heads up, to help understand what's involved and what the end result is.
Legacy ranges are basically the value_range type (int_range<1>) where
the internal
Woah. Sad to see you leave!
It's always been a pleasure to work with you.
Thanks for all the great work, and good luck on your next endeavors.
Aldy
On Thu, Feb 16, 2023 at 4:55 PM Martin Liška wrote:
>
> Hello GCC community.
>
> After spending last decade (including my diploma thesis even mor
On 2/16/23 08:57, Richard Biener wrote:
On Wed, Feb 15, 2023 at 11:31 PM Andrew MacLeod via Gcc wrote:
On 2/15/23 14:50, Andrew Pinski wrote:
Hi,
While fixing PR 108354, I came across that
ssa_name_has_boolean_range calls get_range_query with cfun as the
argument but sometimes while i
I suppose most of the calls to tree_expr_nonnegative_p that apply to
floats in match.pd and tree-ssa-math-opts.cc are guarded by
!HONOR_NANS || tree_expr_nonnegative_p. Still feels kinda delicate...
Aldy
On Sun, Nov 13, 2022 at 4:56 PM Aldy Hernandez wrote:
>
> Based on discussions in th
Based on discussions in the last few weeks, aren't most of the cases in
tree_call_nonnegative_warnv_p() wrong when honoring NANS?
For example:
CASE_CFN_ACOS:
CASE_CFN_ACOS_FN:
CASE_CFN_ACOSH:
CASE_CFN_ACOSH_FN:
...
...
/* Always true. */
return true;
But are we guar
Swt!
Would you like me to XFAIL the test or leave it as a failure?
Thanks.
Aldy
On Fri, Jul 29, 2022 at 1:50 PM Jakub Jelinek wrote:
>
> On Fri, Jul 29, 2022 at 01:40:12PM +0200, Aldy Hernandez wrote:
> > With my upcoming patch enabling floating point VRP,
> > g++.dg/
Hi.
With my upcoming patch enabling floating point VRP,
g++.dg/opt/pr94589-2.C is failing:
https://gcc.gnu.org/pipermail/gcc-patches/2022-July/598788.html
The problem is that phiopt no longer sees the following snippet,
because we have folded away the final conditional as true:
bool f5 (double
Issue resolved. Typedef no longer needed.
Sorry for the noise.
Aldy
On Wed, Jun 1, 2022 at 4:29 PM Aldy Hernandez wrote:
>
> Hi folks.
>
> I rolled our own is_a<> implementation for vrange, because it was
> trivial. We needed it to work on references, and GCC's
Hi folks.
I rolled our own is_a<> implementation for vrange, because it was
trivial. We needed it to work on references, and GCC's is-a.h
implementation is pointer-only. However, I now realize it confuses
gengtype when adding additional types:
template
struct vrange_traits
{
// Default to some
I paid for high school and university writing Cobol, so I'm strangely
interested in the project. Seems like life has come full circle for
me :).
Aldy
On Mon, Mar 14, 2022 at 9:35 PM James K. Lowden
wrote:
>
> https://git.symas.net:443/cobolworx/gcc-cobol/
> https://github.com/Apress/beg-cobol-f
After Jeff's explanation of the symbiosis between jump threading and
the uninit pass, I'm beginning to see that (almost) every
Wuninitialized warning is cause for reflection. It usually hides a
missing jump thread. I investigated one such false positive
(uninit-pred-7_a.c) and indeed, there's a m
l sorts of grief.
Out of curiosity, does the attached (untested) patch fix the regression?
Aldy
Regards,
--
Maxim Kuvyrkov
https://www.linaro.org
On 27 Sep 2021, at 02:52, ci_not...@linaro.org wrote:
After gcc commit 4a960d548b7d7d942f316c5295f6d849b74214f5
Author: Aldy Hernandez
Avo
On 9/24/21 1:37 PM, David Brown wrote:
On 24/09/2021 10:03, Aldy Hernandez via Gcc wrote:
Hi folks.
My upcoming threading improvements turn the test below into an infinite
runtime loop:
int a, b;
short c;
int
main ()
{
int j, d = 1;
for (; c >= 0; c++)
{
BODY:
a
On 9/24/21 11:38 AM, Andrew Pinski wrote:
On Fri, Sep 24, 2021 at 2:35 AM Aldy Hernandez wrote:
On 9/24/21 11:29 AM, Andrew Pinski wrote:
On Fri, Sep 24, 2021 at 1:05 AM Aldy Hernandez via Gcc wrote:
Hi folks.
My upcoming threading improvements turn the test below into an infinite
On 9/24/21 11:29 AM, Andrew Pinski wrote:
On Fri, Sep 24, 2021 at 1:05 AM Aldy Hernandez via Gcc wrote:
Hi folks.
My upcoming threading improvements turn the test below into an infinite
runtime loop:
int a, b;
short c;
int
main ()
{
int j, d = 1;
for (; c >= 0; c++)
{
B
On 9/24/21 10:08 AM, Richard Biener wrote:
On Fri, Sep 24, 2021 at 10:04 AM Aldy Hernandez via Gcc wrote:
Hi folks.
My upcoming threading improvements turn the test below into an infinite
runtime loop:
int a, b;
short c;
int
main ()
{
int j, d = 1;
for (; c >= 0
Hi folks.
My upcoming threading improvements turn the test below into an infinite
runtime loop:
int a, b;
short c;
int
main ()
{
int j, d = 1;
for (; c >= 0; c++)
{
BODY:
a = d;
d = 0;
if (b)
{
xprintf (0);
if (j)
xprintf (0);
On Tue, Sep 21, 2021 at 12:48 PM Aldy Hernandez wrote:
> SUMMARY
> ===
>
> The hybrid threader gets 14.5% more jump threads than the legacy code,
> but most of these threads are at the expense of other threading passes.
> The more it gets, the less DOM and the backward t
In order to replace VRP, we need an alternative for the jump threader
embedded within it. Currently, this threader is a forward threader
client that uses ASSERT_EXPRs and the avail/const framework to resolve
statements along a path.
As I have mentioned in the past weeks, I am proposing a hybr
On 9/10/21 6:21 PM, Jeff Law wrote:
On 9/10/2021 10:05 AM, Aldy Hernandez wrote:
On 9/10/21 5:43 PM, Jeff Law wrote:
On 9/9/2021 3:21 AM, Aldy Hernandez wrote:
/* If this path does not thread through the loop latch, then we are
using the FSM threader to find old style
On 9/10/21 5:51 PM, Jeff Law wrote:
On 9/9/2021 4:15 AM, Richard Biener wrote:
b) Even though we can seemingly fold everything DOM/threader does, in
order to replace it with a backward threader instance we'd have to merge
the cost/profitability code scattered throughout the forward thread
On 9/10/21 5:43 PM, Jeff Law wrote:
On 9/9/2021 3:21 AM, Aldy Hernandez wrote:
/* If this path does not thread through the loop latch, then we are
using the FSM threader to find old style jump threads. This
is good, except the FSM threader does not re-use an existing
e latch becomes
polluted with PHI nodes.
OK for trunk?
Aldy
commit e735a2cd01485773635bd66c97af21059992d5a7 (HEAD ->
pending/global-ranges)
Author: Aldy Hernandez
Date: Thu Sep 9 20:30:28 2021 +0200
Disable threading through latches until after loop optimizations.
The motivation
On 9/9/21 4:44 PM, Michael Matz wrote:
Hello,
On Thu, 9 Sep 2021, Aldy Hernandez wrote:
Here there's no simple latch block to start with (the backedge comes
directly out of the loop exit block). So my suggested improvement
(testing if the latch was empty and only then reject the t
On 9/9/21 2:52 PM, Michael Matz wrote:
Hello,
On Thu, 9 Sep 2021, Aldy Hernandez wrote:
The ldist-22 regression is interesting though:
void foo ()
{
int i;
:
goto ; [INV]
:
a[i_1] = 0;
if (i_1 > 100)
goto ; [INV]
else
goto ; [INV]
:
b[i_1] =
On 9/9/21 12:15 PM, Richard Biener wrote:
On Thu, Sep 9, 2021 at 11:21 AM Aldy Hernandez wrote:
On 9/9/21 10:58 AM, Richard Biener wrote:
I ran some experiments a while back, and my current work on the enhanced
solver/threader, can fold virtually everything the DOM/threader gets
(even
On 9/9/21 10:58 AM, Richard Biener wrote:
On Thu, Sep 9, 2021 at 10:36 AM Aldy Hernandez wrote:
On 9/9/21 9:45 AM, Richard Biener wrote:
On Thu, Sep 9, 2021 at 9:37 AM Aldy Hernandez wrote:
On 9/9/21 8:57 AM, Richard Biener wrote:
On Wed, Sep 8, 2021 at 8:13 PM Michael Matz wrote
On 9/9/21 9:45 AM, Richard Biener wrote:
On Thu, Sep 9, 2021 at 9:37 AM Aldy Hernandez wrote:
On 9/9/21 8:57 AM, Richard Biener wrote:
On Wed, Sep 8, 2021 at 8:13 PM Michael Matz wrote:
Hello,
[lame answer to self]
On Wed, 8 Sep 2021, Michael Matz wrote:
The forward threader
On 9/8/21 8:13 PM, Michael Matz wrote:
Hello,
[lame answer to self]
On Wed, 8 Sep 2021, Michael Matz wrote:
The forward threader guards against this by simply disallowing
threadings that involve different loops. As I see
The thread in question (5->9->3) is all within the same outer loop
On 9/9/21 8:57 AM, Richard Biener wrote:
On Wed, Sep 8, 2021 at 8:13 PM Michael Matz wrote:
Hello,
[lame answer to self]
On Wed, 8 Sep 2021, Michael Matz wrote:
The forward threader guards against this by simply disallowing
threadings that involve different loops. As I see
The thread
On 9/8/21 3:49 PM, Richard Biener wrote:
On Wed, Sep 8, 2021 at 3:25 PM Aldy Hernandez wrote:
It would be helpful to have the patch causing the issue to look at the IL.
But as Micha said, there needs to be a perfect loop nest for interchange
to work.
Richard.
Absolutely! I'm atta
dump:
Checking profitability of path (backwards): bb:3 (4 insns) bb:9 (0
insns) bb:5
Control statement insns: 2
Overall: 2 insns
Registering FSM jump thread: (5, 9) incoming edge; (9, 3) (3, 8)
nocopy; (3, 8)
Thanks.
Aldy
commit 1bf3f76a5ff075396b5b9f5f88d6b18649dac2ce
Author: Aldy Hern
First of all. Thanks so much for this incredibly useful explanation.
It helps a lot.
I'm still trying to wrap my head around this, so please bear with me.
On 9/7/21 4:45 PM, Michael Matz wrote:
Hello,
On Tue, 7 Sep 2021, Aldy Hernandez via Gcc wrote:
The regression comes fro
Hi folks.
I have a pending patch for the path solver that pulls in global ranges
when available (the stuff in SSA_NAME_RANGE_INFO). In doing so, I have
run into a regression I was hoping the loop experts could pontificate on.
The regression comes from the simple_reduc_1() function in
tree-s
On 8/3/21 9:33 AM, Martin Liška wrote:
On 8/2/21 7:22 PM, Joseph Myers wrote:
Hey.
Some time ago, someone added a git symbolic-ref for refs/heads/trunk
pointing to refs/heads/master.
Great you found out what caused that. We were aware of commits that didn't
pass gcc-verify check but for s
There's a new jump threader in GCC which is much more aggressive, and
may trigger latent problems with other warning passes, especially
-Warray-bounds, -Woverflow, and -Wuninitialized.
Do your problems go away if you take out commit 2e96b5f14e?
I have notes throughout the commit analyzing variant
On 6/30/21 12:16 AM, Martin Sebor wrote:
On 6/28/21 6:32 PM, Aldy Hernandez wrote:
I had changed my approach to passing -Wno-free-nonheap-object in the
Makefile. Can you try disabling the Makefile bit and bootstrapping,
cause that was still failing.
I see. I just tested it and my patch
I had changed my approach to passing -Wno-free-nonheap-object in the
Makefile. Can you try disabling the Makefile bit and bootstrapping, cause
that was still failing.
Thanks.
Aldy
On Tue, Jun 29, 2021, 00:29 Martin Sebor wrote:
> On 6/28/21 12:17 AM, Aldy Hernandez wrote:
> >
> &
On 6/28/21 10:22 AM, Richard Biener wrote:
On Fri, Jun 25, 2021 at 6:20 PM Aldy Hernandez wrote:
Hi folks.
I'm done with benchmarking, testing and cleanups, so I'd like to post my
patchset for review. However, before doing so, I'd like to address a
handful of meta-issues
On 6/25/21 7:19 PM, Martin Sebor wrote:
On 6/25/21 10:20 AM, Aldy Hernandez via Gcc wrote:
Hi folks.
I'm done with benchmarking, testing and cleanups, so I'd like to post
my patchset for review. However, before doing so, I'd like to address
a handful of meta-issues that m
Hi folks.
I'm done with benchmarking, testing and cleanups, so I'd like to post my
patchset for review. However, before doing so, I'd like to address a
handful of meta-issues that may affect how I post these patches.
Trapping on differences
===
Originally I wanted to con
On 6/9/21 2:09 PM, Richard Biener wrote:
On Wed, Jun 9, 2021 at 1:50 PM Aldy Hernandez via Gcc wrote:
Hi Jeff. Hi folks.
What started as a foray into severing the old (forward) threader's
dependency on evrp, turned into a rewrite of the backwards threader
code. I'd like to d
On 6/17/21 12:18 AM, Jeff Law wrote:
I am pleased to announce that the GCC Steering Committee has appointed
Aldy Hernandez and Ian MacLeod as maintainers for the VRP subsystem
(EVRP, VRP, Ranger).
I don't know who this Ian is, but I'm sure we'll get along splendidly :).
On 6/15/21 6:03 AM, Jeff Law wrote:
On 6/14/2021 12:40 AM, Richard Biener wrote:
I bet it's going to be tougher to remove DOM's threader. It knows how
to do thinks like resolve memory references using temporary equivalences
and such. But I bet it's enough to drop the VRP based threaders
As part of the ranger development we have found that there are various
pieces of the infrastructure that can be used independently, and we’d
like to document them in the hopes that they are useful to others. We
will be contributing short posts documenting parts of the ranger, which
we hope can
On 6/9/21 9:47 PM, Jeff Law wrote:
On 6/9/2021 9:34 AM, Aldy Hernandez wrote:
On 6/9/21 2:09 PM, Richard Biener wrote:
On Wed, Jun 9, 2021 at 1:50 PM Aldy Hernandez via Gcc
wrote:
Hi Jeff. Hi folks.
What started as a foray into severing the old (forward) threader's
dependen
On 6/9/21 2:09 PM, Richard Biener wrote:
On Wed, Jun 9, 2021 at 1:50 PM Aldy Hernandez via Gcc wrote:
Hi Jeff. Hi folks.
What started as a foray into severing the old (forward) threader's
dependency on evrp, turned into a rewrite of the backwards threader
code. I'd like to d
Hi Jeff. Hi folks.
What started as a foray into severing the old (forward) threader's
dependency on evrp, turned into a rewrite of the backwards threader
code. I'd like to discuss the possibility of replacing the current
backwards threader with a new one that gets far more threads and can
p
On 9/9/20 7:03 PM, Martin Sebor wrote:
On 9/3/20 1:14 AM, Aldy Hernandez via Gcc wrote:
Below is a documented we have drafted to provide guidance on using
irange's and converting passes to it. This will future proof any such
passes so that they will work with the ranger, or any
Below is a documented we have drafted to provide guidance on using
irange's and converting passes to it. This will future proof any such
passes so that they will work with the ranger, or any other mechanism
using multiple sub-ranges (as opposed to the more limited value_range).
The official d
Short summary:
a) we'll unify value_range and the irange API, confirm there are no new
bugs nor performance issue. This would considered complete when the
ranger is able to fully run using value_range instead of irange.
[snip]
Does this seem reasonable?
I think that's a reasonable pla
On 5/28/19 10:40 AM, Jeff Law wrote:
On 5/23/19 7:10 AM, Richard Biener wrote:
On Thu, May 23, 2019 at 3:29 AM Andrew MacLeod wrote:
There is a functioning prototype in branch “ssa-range” which is a proof
of concept that the approach is functional as well as quick, and can be
used to answe
On 3/12/19 3:28 PM, Ian Lance Taylor wrote:
On Tue, Mar 12, 2019 at 11:20 AM Aldy Hernandez wrote:
I have some libgo failures which I'm pretty sure I caused (see below for
details), but I can't seem to figure out how to reproduce. Before I go
down the rabbit hole, is there an e
Hi Ian. Hi folks.
I have some libgo failures which I'm pretty sure I caused (see below for
details), but I can't seem to figure out how to reproduce. Before I go
down the rabbit hole, is there an easy way of reproducing say:
FAIL: database/sql
FAIL: net/http
I'm used to scouring
x86_64-pc
On 10/19/18 1:00 PM, Jakub Jelinek wrote:
On Fri, Oct 19, 2018 at 12:47:00PM -0400, Aldy Hernandez wrote:
Howdy!
Are the types for PHI arguments and the corresponding result supposed to
match?
Like with most other gimple stmts, they need to satisfy
useless_type_conversion_p (TREE_TYPE
Howdy!
Are the types for PHI arguments and the corresponding result supposed to
match?
In the backwards threader I'm seeing:
_103 = PHI <_173(11), 0B(12)>
Where the type of _103 is cgraph_node *, and the type of _173 is
symtab_node *.
I know one is derived from the other (struct c
On 07/16/2018 04:19 AM, Richard Sandiford wrote:
Aldy Hernandez writes:
On Thu, Jul 12, 2018 at 1:41 PM Jonathan Wakely wrote:
On Thu, 12 Jul 2018 at 11:41, Richard Sandiford wrote:
+Only use non-constant references in the following situations:
+
+
+
+when they are necessary to conform
On Thu, Jul 12, 2018 at 8:02 PM Pedro Alves wrote:
>
> On 07/12/2018 05:17 PM, Richard Sandiford wrote:
> > Pedro Alves writes:
>
> >> (an
> >>> alternative to pointers is to return a struct with the wide int result
> >>> and the overflow flag),
> >>
> >> +1. I've been pushing GDB in that direct
On Thu, Jul 12, 2018 at 1:41 PM Jonathan Wakely wrote:
>
> On Thu, 12 Jul 2018 at 11:41, Richard Sandiford wrote:
> > +Only use non-constant references in the following situations:
> > +
> > +
> > +
> > +when they are necessary to conform to a standard interface, such as
> > +the first argument to
Wait, there's a pot of money for making SVN go away? Sign me up!
While we're at it, let's start one for TCL and dejagnu!
On Mon, Jul 9, 2018 at 6:58 PM Jeff Law wrote:
>
> On 07/09/2018 10:53 AM, Janus Weil wrote:
> > 2018-07-09 18:35 GMT+02:00 Eric S. Raymond :
> >> David Edelsohn :
> The t
On 07/05/2018 04:07 AM, Richard Biener wrote:
On Thu, Jul 5, 2018 at 9:47 AM Aldy Hernandez wrote:
After 20 years of hacking on GCC I feel like I have literally wasted
days of my life typing out ChangeLog entries that could have easily been
generated programmatically.
Can someone refresh
After 20 years of hacking on GCC I feel like I have literally wasted
days of my life typing out ChangeLog entries that could have easily been
generated programmatically.
Can someone refresh my memory here, what are the remaining arguments for
requiring ChangeLog entries?
I vaguely recall Jak
Howdy.
Am I missing something or are these two sets identical?
/* Get the lower and upper bounds of the type. */
if (TYPE_OVERFLOW_WRAPS (expr_type))
{
type_min = wi::min_value (prec, sgn);
type_max = wi::max_value (prec, sgn);
Howdy.
I'm looking at the ABS_EXPR code in extract_range_from_unary_expr() and
have noticed that by the time we get here:
/* If a VR_ANTI_RANGEs contains zero, then we have
~[-INF, min(MIN, MAX)]. */
if (vr0.type == VR_ANTI_RANGE)
...we have already handled VR_VARYING, V
On 05/30/2018 10:51 AM, Andreas Schwab wrote:
On Mai 30 2018, David Malcolm wrote:
On Tue, 2018-05-29 at 19:53 -0400, Andrew MacLeod wrote:
[...snip...]
The code is located on an svn branch *ssa-range*. It is based on
trunk
at revision *259405***circa mid April 2018.
Is this svn branc
On 10/26/2017 08:31 AM, Richard Biener wrote:
On Thu, Oct 26, 2017 at 1:05 PM, Aldy Hernandez wrote:
Howdy.
In the backwards threader we attempt to thread paths that lead to a basic
block ending in either a GIMPLE_COND, GIMPLE_SWITCH, or a GIMPLE_GOTO. The
latter doesn't make much
Howdy.
In the backwards threader we attempt to thread paths that lead to a
basic block ending in either a GIMPLE_COND, GIMPLE_SWITCH, or a
GIMPLE_GOTO. The latter doesn't make much sense, since we only handle
constants. What does a goto to a constant mean? Does that ever happen?
In tree-s
On Wed, Aug 30, 2017 at 10:32 AM, Jeff Law wrote:
> On 08/30/2017 04:41 AM, Aldy Hernandez wrote:
> If you're looking for further cleanups, pulling the rest of the FSM bits
> out of tree-ssa-threadupdate.c is ripe. In particular this loop:
>
> /* Jump-thread all FSM threa
So ok to default to a lazy one, or are suggesting we leave things
as they are?
Aldy
On Thu, Aug 31, 2017 at 7:38 AM, Richard Biener
wrote:
> On Thu, Aug 31, 2017 at 1:31 PM, Aldy Hernandez wrote:
>> I understand the need for .quick_push(), when we know the size of the
>> all
I understand the need for .quick_push(), when we know the size of the
allocated elements before hand, but do we really need to call the
common variant safe_push? Can't we just call it push()?
Or is there some magic C++ rule/idiom that prohibits us from doing this?
I volunteer to provide a patch
Hi!
I'm looking at tree-ssa-threadbackward.c, where we pass around a lot
of "vec" pointers representing a path through a
flow graph.
I'm wondering why we use va_gc, when AFAICT, the paths are local to
the pass, and we can easily free them with path.release() at the end
of the pass. For that matt
you had in mind, or would you prefer the sign extension
in the wi::int_traits decompose routine?
Or somewhere else entirely ;-).
Thanks.
Aldy
On Sun, Aug 20, 2017 at 6:40 AM, Richard Biener
wrote:
> On August 20, 2017 10:46:54 AM GMT+02:00, Aldy Hernandez
> wrote:
>>Hi folks.
>
Hi folks.
Calling wi::max_value() of a boolean_type creates a wide_int with all
bits set, not just the least significant bit.
tree type = boolean_type_node;
wide_int x = wi::max_value (TYPE_PRECISION (type), TYPE_SIGN (type));
(gdb) print x.dump()
[0x], precision = 1
However,
Jason Merrill writes:
> Yes, the git mirror can lag the SVN repo by a few minutes, that's why
> you need to 'git svn rebase' to pull directly from SVN before a
> commit.
>
> Jason
Markus just said upthread that:
"git svn dcommit" will run "git svn rebase" automatically
Is `git svn rebase' run
Hi folks.
I've been having troubles comparing the results of different test runs
for quite some time, and have finally decided to whine about it.
Perhaps someone can point out to whatever I may be doing wrong.
I generally do "make check -k -j60" on two different trees and compare
the results
Jeff Law writes:
>> If you build sth as part of GCC then why is it a plugin in the first place?
> I think we want plugins for domain-specific analysis. Having a
> repository for well developed checkers makes sense to me, particularly
> for checkers which are useful across projects.
>
> One such
On 09/14/2016 09:32 AM, Jakub Jelinek wrote:
On Wed, Sep 14, 2016 at 09:25:30AM -0400, Aldy Hernandez wrote:
Hi folks. I'm working on better range information with Macleod, and I've
been playing with folding arbitrary range expressions, which I expect fold()
to ahem...fold.
I'm
Hi folks. I'm working on better range information with Macleod, and
I've been playing with folding arbitrary range expressions, which I
expect fold() to ahem...fold.
I'm surprised that even seemingly simple trees can't be folded after
they've been built, because AFAICT, fold actually just wor
Jeff Law writes:
>> We don't need to change the final approval step being from a
>> maintainer to be able to spread the workload.
> Amen. There's a few folks doing this right now outside their areas of
> official maintainership and those comments are always very helpful to
> me.
>
> And note tha
On 07/29/2016 07:30 AM, Aldy Hernandez wrote:
On 07/25/2016 06:30 PM, Manuel López-Ibáñez wrote:
On 25/07/16 21:16, Joseph Myers wrote:
On Mon, 25 Jul 2016, Jeff Law wrote:
I'll pre-approve removing those bits. Alternately, you could look to
resync
with glibc, though that could
On 07/25/2016 06:30 PM, Manuel López-Ibáñez wrote:
On 25/07/16 21:16, Joseph Myers wrote:
On Mon, 25 Jul 2016, Jeff Law wrote:
I'll pre-approve removing those bits. Alternately, you could look to
resync
with glibc, though that could prove painful after 15 years of
divergence.
The current gl
On 07/23/2016 06:33 AM, Aldy Hernandez wrote:
If the REGEX_MALLOC mode in regex.c is unused, can I rip it out? I'd
like to replace it all with alloca with a malloc fallback.
And yes, I realize regex.c already does this most of the time:
if (size1 > MAX_ALL
Hi guys!
I'm looking at libiberty's use of alloca() and trying to place some
bounded checks at alloca() call points.
Silly question, do we have any users of regex.c with REGEX_MALLOC set?
I don't see any #define for REGEX_MALLOC anywhere in binutils or gcc,
and it doesn't look like autoconf
On 03/24/2016 10:02 AM, Alexander Monakov wrote:
Hi,
On Thu, 24 Mar 2016, Bernd Schmidt wrote:
On 03/24/2016 11:17 AM, Aldy Hernandez wrote:
On 03/23/2016 10:25 AM, Bernd Schmidt wrote:
It looks like this block of code is written by a helper function that is
really intended for other
On 03/23/2016 10:25 AM, Bernd Schmidt wrote:
On 03/23/2016 07:32 AM, Aldy Hernandez wrote:
int
maximal_insn_latency (rtx insn)
{
int insn_code;
if (insn == 0)
insn_code = DFA__ADVANCE_CYCLE;
else
{
insn_code = dfa_insn_code (as_a (insn));
if (insn_code
Howdy!
I'm working on enhancements to our out-of-bounds warnings in VRP, such
that we can warn and isolate conditionally out-of-bound accesses
(similar to what we do in gimple-ssa-isolate-paths.c for NULL accesses).
With my WIP I have found the following out of bounds in the array access
at
"Eric S. Raymond" writes:
> The remaining list is pretty short:
>
> bson = bson
I worked on a project together with a Jan Brittenson a very long time
ago. He worked on GNU finger, and some bytecode representation for GCC
way back when... for the FSF.
Actually he was very instrumental in getti
On 06/08/2015 04:03 AM, Iain Sandoe wrote:
Hi Aldy,
On 7 Jun 2015, at 12:37, Aldy Hernandez wrote:
On 06/07/2015 06:19 AM, Andreas Schwab wrote:
Another fallout:
FAIL: obj-c++.dg/try-catch-5.mm -fgnu-runtime (test for excess errors)
Excess errors:
: warning: '_OBJC_Module' defin
On 06/07/2015 11:25 AM, Richard Biener wrote:
On June 7, 2015 5:03:30 PM GMT+02:00, Aldy Hernandez wrote:
On 06/06/2015 05:49 AM, Andreas Schwab wrote:
Bootstrap fails on aarch64:
Comparing stages 2 and 3
warning: gcc/cc1objplus-checksum.o differs
warning: gcc/cc1obj-checksum.o differs
On 06/06/2015 05:49 AM, Andreas Schwab wrote:
Bootstrap fails on aarch64:
Comparing stages 2 and 3
warning: gcc/cc1objplus-checksum.o differs
warning: gcc/cc1obj-checksum.o differs
warning: gcc/cc1plus-checksum.o differs
warning: gcc/cc1-checksum.o differs
Bootstrap comparison failure!
gcc/ira-c
422e1355
Author: Aldy Hernandez
Date: Sun Jun 7 07:32:12 2015 -0400
* objc-runtime-shared-support.c (build_module_descriptor): Set
TREE_USED on UOBJC_MODULES_decl.
diff --git a/gcc/objc/objc-runtime-shared-support.c
b/gcc/objc/objc-runtime-shared-support.c
index d9b3c27..1bcb14a 1
On 06/07/2015 07:28 AM, Ramana Radhakrishnan wrote:
On Sat, Jun 6, 2015 at 10:49 AM, Andreas Schwab wrote:
Bootstrap fails on aarch64:
Comparing stages 2 and 3
warning: gcc/cc1objplus-checksum.o differs
warning: gcc/cc1obj-checksum.o differs
warning: gcc/cc1plus-checksum.o differs
warning: gcc
On 06/06/2015 05:47 PM, Aldy Hernandez wrote:
On 06/06/2015 03:33 PM, Jan Hubicka wrote:
Aldy,
also at PPC64le LTO bootstrap (at gcc112) dies with:
^
0x104ae8f7 check_die
../../gcc/dwarf2out.c:5715
Hmmm... this is in the LTO/ltrans stage? If so, that's weird. The LTO
path doe
On 06/06/2015 03:33 PM, Jan Hubicka wrote:
Aldy,
also at PPC64le LTO bootstrap (at gcc112) dies with:
^
0x104ae8f7 check_die
../../gcc/dwarf2out.c:5715
Hmmm... this is in the LTO/ltrans stage? If so, that's weird. The LTO
path does not do the early DIE dance. Since check_die() is a
On 06/06/2015 09:20 AM, Andreas Schwab wrote:
Aldy Hernandez writes:
Does the attached fix the ia64 failure?
commit 6c40c8f011bbd09ea92749f3925db83f249baf74
Author: Aldy Hernandez
Date: Sat Jun 6 06:48:40 2015 -0400
* dwarf2out.c (gen_lexical_block_die): Initialize stmt_die
1 - 100 of 252 matches
Mail list logo
