On Mon, 2006-04-17 at 14:48 +0200, Marcin 'Qrczak' Kowalczyk wrote:
> There is a missing opportunity for optimization.
>
> int f(void);
> void test(int x) {
>if (x & 1 ? x == 0 : x > 0) f();
> }
>
> This is gcc-4.1.0-0.20051206 with some patches by PLD Linux
> Distribution. gcc -S -O2 -fomit-
On Mon, 2006-04-10 at 13:29 -0700, Mark Mitchell wrote:
> You and Mike have suggested that recruiting GCC developers is a
> reasonable use of the list. Before we go to the SC, asking for approval
> to change the policy, we should address some other issues:
>
> 1. What do we do if people do advert
On Fri, 2006-03-31 at 09:55 +0100, Andrew Haley wrote:
> Well, it's not just functionss but also global variables. AFAICS
> there are three sources of data: args, retvals, and globals. And
> there are quite a few of these globals we can usefully tag as "known
> never to be null".
Seems to me the
On Thu, 2006-03-30 at 18:39 +0100, Andrew Haley wrote:
> Jeffrey A Law writes:
> > On Wed, 2006-03-29 at 14:28 -0700, Tom Tromey wrote:
> >
> > > On irc today we were discussing handling 'this' in gcj. We can add an
> > > attribute to the argum
On Tue, 2006-03-28 at 23:49 +0200, Duncan Sands wrote:
> That still leaves the problem of how the Ada front-end tells the
> middle-end that a variable is known to be in a certain range. Due
> to the way the language works, the front-end often does know a useful
> range, helpful for optimisation.
On Wed, 2006-03-29 at 14:28 -0700, Tom Tromey wrote:
> On irc today we were discussing handling 'this' in gcj. We can add an
> attribute to the argument to mark it as non-null... but strangely
> there doesn't seem to be a way to mark other local variables as
> known-non-null -- a curious deficien
On Tue, 2006-03-28 at 01:03 +0200, Duncan Sands wrote:
> Hi Jeff,
>
> On Monday 27 March 2006 21:00, Jeffrey A Law wrote:
> > On Sat, 2006-03-25 at 10:35 -0500, Diego Novillo wrote:
> >
> > > Start by looking at tree-vrp.c:infer_value_range.
> > I'm no
On Sat, 2006-03-25 at 10:35 -0500, Diego Novillo wrote:
> Start by looking at tree-vrp.c:infer_value_range.
I'm not so sure this is the best place to start.
It seems to me that the asserts could be registered at the
start of insert_range_assertions.
Just walk the parameter list and extract the d
On Fri, 2006-03-24 at 18:50 +0100, Duncan Sands wrote:
> Hi Jeff, while your patch catches many cases, the logic seems a bit wonky
> for types with TYPE_MIN/TYPE_MAX different to those that can be deduced
> from TYPE_PRECISION. For example, there is nothing stopping inner_type
> having a bigger T
On Thu, 2006-03-23 at 10:40 +0100, Duncan Sands wrote:
> Hi Jeff, this seems to work nicely - thanks again. I still see a bunch
> of suboptimal range calculations in the Ada code I'm looking at, but these
> now just coming from having everything initialised to VR_VARYING rather than
> [TYPE_MIN, T
On Tue, 2006-03-21 at 10:14 +0100, Duncan Sands wrote:
> Hi Jeff, on the subject of seeing through typecasts, I was playing around
> with VRP and noticed that the following "if" statement is not eliminated:
>
> int u (unsigned char c) {
> int i = c;
>
> if (i < 0 || i > 255)
>
On Tue, 2006-03-21 at 18:13 +0100, Duncan Sands wrote:
> Is memory use a problem here? VR_VARYING has the advantage of using
> a bit less memory. On the other hand, I guess you could introduce the
> convention that VR_RANGE with null min/mae means to use TYPE_MIN/
> TYPE_MAX, or something along
On Tue, 2006-03-21 at 17:41 +0100, Duncan Sands wrote:
> Should it be? I was surprised to see that all ranges are initialised
> to VR_VARYING in the vrp pass, since many types have natural ranges
> associated with them, for example [0, 255] for the above unsigned char;
> starting off with this na
On Tue, 2006-03-21 at 10:14 +0100, Duncan Sands wrote:
> Hi Jeff, on the subject of seeing through typecasts, I was playing around
> with VRP and noticed that the following "if" statement is not eliminated:
>
> int u (unsigned char c) {
> int i = c;
>
> if (i < 0 || i > 255)
>
On Sat, 2006-03-18 at 10:24 +0100, Laurent GUERBY wrote:
> On Fri, 2006-03-17 at 12:51 -0700, Jeffrey A Law wrote:
> > I'm not suggesting the FEs deduce more types and track ranges;
> > that would be rather absurd. What I'm saying is that exposing
> > these type
On Tue, 2006-03-14 at 03:16 +0100, Waldek Hebisch wrote:
> I think that it is easy for back end to make good use of
> TYPE_MIN_VALUE/TYPE_MAX_VALUE. Namely, consider the assignment
>
> x := y + z * w;
>
> where variables y, z and w have values in the interval [0,7] and
> x have values in [0,1000
On Mon, 2006-02-27 at 20:08 +0100, Waldek Hebisch wrote:
> What do you mean by "abuse"? TYPE_MAX_VALUE means maximal value
> allowed by given type.
As long as you're *absolutely* clear that a variable with a
restricted range can never hold a value outside that the
restricted range in a conformin
On Wed, 2006-03-08 at 17:21 +0100, Eric Botcazou wrote:
> > One more note, we see the same kind of conditional and test
> > simplification with for cxa4028 in Ada.Strings.Superbounded.Super_Trim.
> > So I'm pretty confident that if we fix the bogus trees generated for
> > a-stwifi.adb that all thre
On Wed, 2006-03-08 at 12:36 +0100, Eric Botcazou wrote:
> > Presumably there's a reason why enumeral types don't have a
> > base type?
>
> They are viewed as full-blown types by Ada, forming the class of discrete
> types with integral types, so there are probably no semantics reasons why
> ENUME
On Tue, 2006-03-07 at 08:00 -0500, Richard Kenner wrote:
> if (INTEGRAL_TYPE_P (etype) && TREE_TYPE (etype))
> {
> etype = TREE_TYPE (etype);
> exp = fold_convert (etype, exp);
> low = fold_convert (etype, low);
> value = fold_convert (etype, value);
>
On Mon, 2006-03-06 at 14:26 -0500, Andrew Pinski wrote:
> On Mar 6, 2006, at 2:21 PM, Joe Buck wrote:
>
> > On Mon, Mar 06, 2006 at 12:34:42PM -0500, Andrew Pinski wrote:
> >> What is the policy for testsuite regressions that have been
> >> there for over 48 hours and effect all targets and have n
On Mon, 2006-03-06 at 00:31 +0100, Eric Botcazou wrote:
> cxa4025 and cxa4033 are very likely yours, originating in a miscompilation of
> the runtime (a-stwifi.adb) at -O2. They succeed if the aforementioned unit
> is compiled at -O2 -fno-tree-vrp. You ca
On Mon, 2006-03-06 at 00:31 +0100, Eric Botcazou wrote:
>
>
> cxa4025 and cxa4033 are very likely yours, originating in a miscompilation of
> the runtime (a-stwifi.adb) at -O2. They succeed if the aforementioned unit
> is compiled at -O2 -fno-tree-vrp. You can pass -a to gnatmake to cause the
On Mon, 2006-03-06 at 12:34 -0500, Andrew Pinski wrote:
> I noticed that some testsuite regressions were not getting fixed.
> There are 3 failures in the gcc.dg/tree-ssa (PR 26344).
> And 5 in g++.dg (PR 26115 and PR 26114).
> All of these testsuite regressions have been there for almost
> three we
On Thu, 2006-03-02 at 12:35 -0700, Roger Sayle wrote:
> Sorry for the breakage. I'll have a fix before the sun goes down,
> that performs the shift in the correct mode, then appropriately
> sign extends, zero extends or truncates if necessary.
>
> Many thanks for analyzing this failure. Sorry a
On Thu, 2006-03-02 at 14:05 +0100, Eric Botcazou wrote:
> > # BLOCK 6
> > # PRED: 4 (false,exec)
> > :;
> > iftmp.78_63 = D.1309_32;
> > iftmp.78_64 = D.1309_32;
> > D.1316_65 = (c460008__unsigned_edge_8) D.1309_32;
> > if (D.1316_65 == 255) goto ; else goto ;
> > # SUCC: 7 (true,exec
This change:
2006-02-17 Roger Sayle <[EMAIL PROTECTED]>
PR middle-end/25600
* fold-const.c (fold_binary): Fold (X >> C) != 0 into X < 0 when
C is one less than the width of X (and related transformations).
* simplify-rtx.c (simplify_unary_operation_1): Transform
Here's the next segment in the ongoing saga of VRP vs Ada...
Not surprisingly we have another case where an object gets a
value outside of its TYPE_MIN_VALUE/TYPE_MAX_VALUE defined range.
Investigating the c460008 testsuite failure we have the following
code for Fixed_To_Short before VRP runs:
On Wed, 2006-03-01 at 08:24 -0500, Richard Kenner wrote:
> So this is likely to be a FE Ada coding bug and not a FE/ME/BE interface
> issue, thanks for spotting this!
>
> Sorry, my last suggestion is clearly wrong. I think is right.
>
> *** uintp.adb 12 Sep 2003 21:50:56 - 1.80
On Wed, 2006-03-01 at 08:15 +0100, Eric Botcazou wrote:
> Hi,
>
> I'm a big fan of Zack's "over-my-dead-body" motto when it comes to ditching
> bootstrap with non-GCC compilers. :-) It turns out that bootstrap is again
> broken on mainline for them (at least Sun CC) and that the problem is anot
On Tue, 2006-02-28 at 17:51 -0500, Diego Novillo wrote:
> Jeffrey A Law wrote:
>
> > Diego -- do you recall what code actually triggered this problem?
> >
> Not sure, exactly.
>
> However, in figuring out what this code was working around, I remembered
> this thr
On Tue, 2006-02-28 at 18:50 +0100, Eric Botcazou wrote:
> > It's an ugly hack in extract_range_from_assert:
> >
> > /* Special handling for integral types with super-types. Some FEs
> > construct integral types derived from other types and restrict
> > the range of values these new typ
On Tue, 2006-02-28 at 18:42 +0100, Eric Botcazou wrote:
> > Basically with the way Ada's setting of TYPE_MIN_VALUE/TYPE_MAX_VALUE
> > effectively makes them useless as we can not rely on them to
> > actually reflect the set of values allowed in an object.
>
> Sorry, but why are you saying "we can
On Tue, 2006-02-28 at 12:06 +0100, Eric Botcazou wrote:
> [Sorry for the delay]
No worries.
> I was actually referring to explicit constraints on TYPE_MAX_VALUE and
> TYPE_MIN_VALUE derived from TYPE_PRECISION and TYPE_UNSIGNED, for example
> that ceil(log2(TYPE_MAX_VALUE - TYPE_MIN_VALUE)) must
On Mon, 2006-02-27 at 20:26 +0100, Sebastian Pop wrote:
> Jeffrey A Law wrote:
> > On Fri, 2006-02-24 at 19:47 +0100, Sebastian Pop wrote:
> > > Jeffrey A Law wrote:
> > > > Another possibility is to simply not allow conversions between a
> > > > subtyp
On Sat, 2006-02-25 at 09:48 +0100, Zdenek Dvorak wrote:
> Hello,
>
> > Jeffrey A Law wrote:
> > > Another possibility is to simply not allow conversions between a
> > > subtype and basetype.
> >
> > Such a patch also solves the problem. But I'm
On Fri, 2006-02-24 at 19:47 +0100, Sebastian Pop wrote:
> Jeffrey A Law wrote:
> > Another possibility is to simply not allow conversions between a
> > subtype and basetype.
>
> Such a patch also solves the problem. But I'm not sure to understand
> the impact on
On Fri, 2006-02-24 at 19:47 +0100, Sebastian Pop wrote:
> Jeffrey A Law wrote:
> > Another possibility is to simply not allow conversions between a
> > subtype and basetype.
>
> Such a patch also solves the problem. But I'm not sure to understand
> the impact on
On Fri, 2006-02-24 at 18:42 +0100, Sebastian Pop wrote:
> Richard Kenner wrote:
> > Just to make sure I've dotted the i's and crossed the t's, this is not
> > what's happening when we hang in VRP when compiling a-textio.
> >
> > We convert the incoming object from natural___XDLU_0___21
On Fri, 2006-02-24 at 18:42 +0100, Sebastian Pop wrote:
> Richard Kenner wrote:
> > Just to make sure I've dotted the i's and crossed the t's, this is not
> > what's happening when we hang in VRP when compiling a-textio.
> >
> > We convert the incoming object from natural___XDLU_0___21
On Fri, 2006-02-24 at 18:42 +0100, Sebastian Pop wrote:
> Richard Kenner wrote:
> > Just to make sure I've dotted the i's and crossed the t's, this is not
> > what's happening when we hang in VRP when compiling a-textio.
> >
> > We convert the incoming object from natural___XDLU_0___21
On Wed, 2006-02-22 at 13:25 -0500, Richard Kenner wrote:
> When I speak about doing arithmetic in a type, I'm referring to the
> type of the expression & its input operands in a gimplified
> expression. At that point I do not care about base types or anything
> like that. All
On Wed, 2006-02-22 at 13:25 -0500, Richard Kenner wrote:
> When I speak about doing arithmetic in a type, I'm referring to the
> type of the expression & its input operands in a gimplified
> expression. At that point I do not care about base types or anything
> like that. All
On Wed, 2006-02-22 at 13:25 -0500, Richard Kenner wrote:
> The base type reference is that I'm *also* saying "If you see an arithmetic
> node where TREE_TYPE is *not* a base type, there's a bug someplace that
> has to be fixed". (Well, with the exception of such things as sizetypes
> or subtypes th
On Wed, 2006-02-22 at 09:00 -0800, Mark Mitchell wrote:
> Jeffrey A Law wrote:
>
> > This does highlight one of the issues that keeps nagging at me.
> > For an enumeration type, presumably we have TYPE_PRECISION set to
> > the minimum precision necessary to hold al
On Tue, 2006-02-21 at 23:23 +0100, Laurent GUERBY wrote:
> On Tue, 2006-02-21 at 15:02 -0700, Jeffrey A Law wrote:
> > Given an expression, we have to do computations in some other type than
> > the type of the expression? Now that's just silly. If the expression
> >
On Mon, 2006-02-20 at 23:00 +0100, Richard Guenther wrote:
> On 2/20/06, Richard Kenner <[EMAIL PROTECTED]> wrote:
> > Indeed. Ada should in this case generate
> >
> >R = (T)( (basetype)100 + (basetype)X - (basetype)X )
> >
> > i.e. carry out all arithmetic explicitly in the base
On Tue, 2006-02-21 at 18:11 -0500, Robert Dewar wrote:
> Richard Kenner wrote:
>
> > Let me try again and take a simpler example. If we have
> >
> > subtype T is Integer range 20..50;
> >
> > Y: T;
> >
> >... Y + 1 ...
> >
> > What the tree looks like is a PLUS_EXPR of type "I
On Tue, 2006-02-21 at 17:22 -0500, Richard Kenner wrote:
> Given an expression, we have to do computations in some other type than
> the type of the expression? Now that's just silly.
>
> Sure, but that's not what I said.
>
> If the expression has some type X, then we should be d
On Tue, 2006-02-21 at 14:56 -0800, Mark Mitchell wrote:
> Jeffrey A Law wrote:
>
> > My feeling? Absolutely, TYPE_MIN_VALUE and TYPE_MAX_VALUE should
> > represent the set of values that an object of the type may hold.
> > Any other definition effectively renders thos
On Tue, 2006-02-21 at 18:20 -0500, Robert Dewar wrote:
> Laurent GUERBY wrote:
>
> > You keep saying "brain damage", but please if you see a better design
> > (other than "forget about user range types" :), let us all know!
>
> Actually I think everyone agrees on what is appropriate here. it is
>
On Wed, 2006-02-22 at 11:51 +0100, Richard Guenther wrote:
> On 2/21/06, Mark Mitchell <[EMAIL PROTECTED]> wrote:
> > Jeffrey A Law wrote:
> >
> > > My feeling? Absolutely, TYPE_MIN_VALUE and TYPE_MAX_VALUE should
> > > represent the set of values that an
On Tue, 2006-02-21 at 16:24 -0500, Richard Kenner wrote:
> So, back to my example. If I have an object with a range [0,
> 0x7ff f] based on the type of the object and I add one to that
> object, then I can safely conclude that the result of the addition has
> the range [1
On Tue, 2006-02-21 at 15:40 -0500, Richard Kenner wrote:
> So in the case above, the set of permissible values is
> [1, 0x7fff] after the addition, right?
>
> Well, not quite. The addition isn't done in type X, but in type X'Base,
> which does not have the restricted TYPE_{MIN,MA
On Tue, 2006-02-21 at 14:34 -0500, Robert Dewar wrote:
> Jeffrey A Law wrote:
>
> > So, if we have an object with the range based on its type of
> > [0, 0x7fff] and we add 1 to that object, the resulting range
> > should be [1, 0x7fff]. ie, 0x8000 is not a
On Tue, 2006-02-21 at 14:14 -0500, Richard Kenner wrote:
> OK. So if a program sets an object to a value outside
> TYPE_MIN_VALUE/TYPE_MAX_VALUE, then that program is
> invalid for the purposes of this discussion?
>
> Correct. Of course, it has to be the *program* that's doing th
On Tue, 2006-02-21 at 13:57 -0500, Richard Kenner wrote:
> Can a conforming program set the object to a value outside of
> TYPE_MIN_VALUE/TYPE_MAX_VALUE.
>
> Let's forget about the obscure unchecked conversion -> 'Valid case
> because we're going to handle that in whatever way we need to
On Tue, 2006-02-21 at 13:31 -0500, Richard Kenner wrote:
> Err, no they don't. Clearly an object of the type can hold a value
> outside TYPE_MIN_VALUE/TYPE_MAX_VALUE at runtime. That IMHO means
> that TYPE_MIN_VALUE/TYPE_MAX_VALUE do not reflect reality.
>
> What does "can" mean
On Tue, 2006-02-21 at 12:46 -0500, Richard Kenner wrote:
> But if the values in there do not reflect the reality of what values
> are valid for the type, then I don't see how they can be generally
> useful -- that's my point. We have two fields that are inaccurate,
> apparently
On Mon, 2006-02-20 at 22:00 +0100, Richard Guenther wrote:
> On 2/20/06, Jeffrey A Law <[EMAIL PROTECTED]> wrote:
> > On Sun, 2006-02-19 at 20:43 +0100, Laurent GUERBY wrote:
> > > On Sun, 2006-02-19 at 14:23 -0500, Richard Kenner wrote:
> > > > "
On Sun, 2006-02-19 at 20:15 +0100, Eric Botcazou wrote:
> >"Now for the first "oddity". If we look at the underlying type
> > for last we have a type "natural___XDLU_0__2147483647". What's
> >interesting about it is that it has a 32bit type precision, but
> > the min/max values only specify 31 b
On Mon, 2006-02-20 at 16:49 -0500, Richard Kenner wrote:
> Which leaves us with a very fundamental issue. Namely that we can not
> use TYPE_MIN_VALUE or TYPE_MAX_VALUE for ranges.
>
> The point is that it *is* supposed to be usable in general. If it can't
> be used in a specific case
On Sun, 2006-02-19 at 20:43 +0100, Laurent GUERBY wrote:
> On Sun, 2006-02-19 at 14:23 -0500, Richard Kenner wrote:
> > "Second, for a given integer type (such as
> > natural___XDLU_0_2147483647), the type for the nodes in TYPE_MIN_VALUE
> > and TYPE_MAX_VALUE really should be a natural
On Tue, 2006-02-14 at 17:42 +0100, Marcin Dalecki wrote:
> On 2006-02-14, at 11:21, Rainer Emrich wrote:
>
> > ICE in stage2:
> >
> > 'tree_duplicate_sese_region':
> > /SCRATCH/gcc-build/HP-UX/hppa2.0w-hp-hpux11.00/src/gcc/tree-cfg.c:
> > 4430: internal
> > compiler error: in do_compare_rtx_and_j
On Mon, 2006-01-02 at 19:31 +0100, Laurent GUERBY wrote:
> Hi Rainer, this is PR24994:
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24994
>
> And is under investigation:
>
> http://gcc.gnu.org/ml/gcc-patches/2005-12/msg01756.html
>
So, here's what appears to be happening.
1. A statement i
On Tue, 2006-01-03 at 15:02 -0500, Diego Novillo wrote:
> On Tuesday 03 January 2006 14:57, Jeffrey A Law wrote:
>
> > No, this is not sufficient.
> >
> *shrug* that works for me without the legacy_va_layout setting.
>
> $ sysctl vm.legacy_va_layout
> vm.legacy
On Tue, 2006-01-03 at 14:51 -0500, Diego Novillo wrote:
> On Tuesday 03 January 2006 14:47, Andrew Haley wrote:
>
> > Please, post instructions about how to turn on the old style VM layout
> > in the kernel. Sooner or later, many of us on this list will need to
> > know...
> >
> Adding this to /e
On Mon, 2006-01-02 at 19:31 +0100, Laurent GUERBY wrote:
> Hi Rainer, this is PR24994:
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24994
>
> And is under investigation:
>
> http://gcc.gnu.org/ml/gcc-patches/2005-12/msg01756.html
Finally!
To stop the annoying VM randomization you need to tur
On Mon, 2006-01-02 at 19:31 +0100, Laurent GUERBY wrote:
> Hi Rainer, this is PR24994:
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24994
>
> And is under investigation:
>
> http://gcc.gnu.org/ml/gcc-patches/2005-12/msg01756.html
Hmmm, I'm still having trouble disabling this (*&@#$ address
sp
On Mon, 2006-01-02 at 19:31 +0100, Laurent GUERBY wrote:
> Hi Rainer, this is PR24994:
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24994
>
> And is under investigation:
>
> http://gcc.gnu.org/ml/gcc-patches/2005-12/msg01756.html
Still under investigation. Very little happened over the last
On Tue, 2005-12-13 at 11:41 -0700, Tom Tromey wrote:
> First, yeah, this is known. And, kudos to HJ for trying to fix this
> in 'make'.
If nothing else, HJ's hack is keeping things from being too insane
while y'all sort out the best fix.
> I've been considering working around this problem by ju
On Wed, 2005-11-30 at 13:44 +0100, Paolo Bonzini wrote:
> You probably are on a svn:// tree. Try something along the lines of
Ahhh.
> svn switch --relocate {svn://,svn+ssh://[EMAIL PROTECTED]/svn/gcc
Thanks. I doubt I would have come up with that one on my own! :-)
jeff
I just tried to check in a change on the 4.1 branch. I get this
nice little message :
svn: Commit failed (details follow):
svn: Authorization failed
svn: Your commit message was left in a temporary file:
svn:'/fuel98/export/svn/gcc-4_1-branch/svn-commit.2.tmp'
Suggestions?
jeff
> Our understanding was that the debugger actually uses the symbol table,
> in addition to the debugging information, in some cases. (This must be
> true when not running with -g, but I thought it was true in other cases
> as well.) It might be true for other tools, too.
I can't offhand recall i
On Wed, 2005-11-16 at 12:06 -0800, Richard Henderson wrote:
> On Sun, Nov 13, 2005 at 02:26:31PM -0700, Jeffrey A Law wrote:
> > On Sun, 2005-11-13 at 22:20 +0100, Steven Bosscher wrote:
> > > On Sunday 13 November 2005 22:02, Jeffrey A Law wrote:
> > > > No
On Tue, 2005-11-15 at 13:31 -0800, Joe Buck wrote:
> On Tue, Nov 15, 2005 at 02:15:44PM -0700, Jeffrey A Law wrote:
> >
> > So, is it just me or does execute/930529-1.c invoke undefined or
> > implementation defined behavior due to its reliance upon overflow
> >
So, is it just me or does execute/930529-1.c invoke undefined or
implementation defined behavior due to its reliance upon overflow
behavior for signed types?
In particular look at the control for the second loop:
int i;
[ ... ]
for (i = ((unsigned) ~0 >> 1) - 3; i <= ((unsigned) ~0 >> 1) +
On Sun, 2005-11-13 at 22:20 +0100, Steven Bosscher wrote:
> On Sunday 13 November 2005 22:02, Jeffrey A Law wrote:
> > No great insights on how to make dbr_schedule CFG aware -- just
> > remember that a filled delay slot can represent 3 different cases:
> >
> > 1
On Sun, 2005-11-13 at 21:20 +0100, Steven Bosscher wrote:
> Hi,
>
> I'm trying to figure out how much effort it would take to make
> dbr_schedule CFG aware. One of the issues I'm running into is
> that the RTL CFG stuff doesn't support SEQUENCEs at all. So if
> I have a delay slot filled, e.g.,
On Tue, 2005-11-08 at 21:10 -0500, Kaveh R. Ghazi wrote:
> > I've put a possible patch in the metabug (24639). As I mention in
> > the comments, I'm not comfortable self-approving it given my lack of
> > knowledge about the option processing code and the debate over what
> > we want the defaul
On Wed, 2005-11-02 at 18:02 -0800, Mark Mitchell wrote:
> Jeffrey A Law wrote:
>
> > For example, if the only use was inside an unreachable hunk of
> > code, does that count as a use or not?
>
> Yes, the EDG front-end does this:
>
> [EMAIL PROTECTED]:~/tmp$ cat t
On Wed, 2005-11-02 at 20:44 -0500, Daniel Jacobowitz wrote:
> On Wed, Nov 02, 2005 at 05:32:51PM -0800, Joe Buck wrote:
> > On Thu, Nov 03, 2005 at 02:13:05AM +0100, Gabriel Dos Reis wrote:
> > > | Have -Wuninitialized be a very simple detector, which is either in the
> > > front-ends
> > > | or i
On Wed, 2005-11-02 at 16:43 -0800, Mark Mitchell wrote:
> Jeff, I'm sorry you're upset; I actually think we're closer to consensus
> than we've ever been before on this issue. :-)
Maybe that's what's getting under my skin! Rehashing those
issues where I think we do have a consensus, namely the nee
On Wed, 2005-11-02 at 20:35 -0500, Kaveh R. Ghazi wrote:
> > Have another option to detect variables which are set but their values
> > are not used (this was in one of the -Wuninitialized bugs and has been
> > asked before). The EDG front-end implements this option.
> > Andrew Pinski
>
> The
On Wed, 2005-11-02 at 19:04 -0500, Kaveh R. Ghazi wrote:
> > I would suggest you look at our testsuite and our PR database and
> > see how many PRs we've got about false-positive warnings. Achieving
> > consistency will merely increase the false-positives and as a result
> > make the warning l
On Wed, 2005-11-02 at 14:19 -0500, Andrew Pinski wrote:
> > > However, I'll freely admit this is just my notoriously fallible memory
> > > at work here; I've not reviewed the PRs.
> > Mine is as fallable as yours :-)
>
> All of the PRs that I could find, closed or not are in the meta-bug filed
>
On Wed, 2005-11-02 at 12:55 -0600, Chris Lattner wrote:
> > I think it's worth noting that we build the SSA form even when we're
> > not optimizing. Which in turn with running the maybe-uninitialized
> > warning code early would give you the warnings you expect without
> > needing to run the optim
On Wed, 2005-11-02 at 09:58 -0800, Mark Mitchell wrote:
> Jeffrey A Law wrote:
>
> > Again, the problem I have with the notion that we want to get
> > consistent answers is that doing so, is going to give us a lot of
> > false positives. That IMHO is a huge step backwa
On Wed, 2005-11-02 at 12:01 -0600, Chris Lattner wrote:
[ ... big snip ... ]
> For users like myself, I would really like to have an option to switch the
> unused var warning to be emitted from the *front-end* where it works when
> compiling with optimization disabled (a huge feature in itself) a
On Tue, 2005-11-01 at 12:56 -0800, Mark Mitchell wrote:
> Diego Novillo wrote:
>
> > We won't get perfect answers, which is fine given the nature of the
> > problem. However, I would like, to get *consistent* answers.
>
> Yes, I agree that's very important. In fact, I'd like to generalize
> th
On Tue, 2005-11-01 at 13:26 -0500, Diego Novillo wrote:
> We won't get perfect answers, which is fine given the nature of the
> problem. However, I would like, to get *consistent* answers. If we
> decide to re-organize the optimization pipeline, we should not be getting
> different -Wuninitial
On Tue, 2005-11-01 at 22:10 -0500, Kaveh R. Ghazi wrote:
>
> I prefer consistency in warnings, regardless of optimization level.
I disagree and I think we have a significant contingency of
users that would disagree -- if optimizations allow us to avoid
false-positive warnings, then we should use
On Tue, 2005-11-01 at 10:32 -0800, Joe Buck wrote:
> On Tue, Nov 01, 2005 at 11:17:52AM -0700, Jeffrey A Law wrote:
> > On Tue, 2005-11-01 at 11:06 -0500, Diego Novillo wrote:
> > > To prevent losing location information for the warning, I had modified
> > > the
>
On Tue, 2005-11-01 at 13:26 -0500, Diego Novillo wrote:
> We won't get perfect answers, which is fine given the nature of the
> problem.
Right.
> However, I would like, to get *consistent* answers.
Depends on how you define "consistent" :-)
> If we
> decide to re-organize the optimization
On Tue, 2005-11-01 at 11:06 -0500, Diego Novillo wrote:
> To prevent losing location information for the warning, I had modified the
> propagation engine to warn as it folded the expression away.
Possibly a useful thing to have, but I don't think we want to put
the burden of detecting uninitialize
On Tue, 2005-11-01 at 11:06 -0500, Diego Novillo wrote:
> On Monday 31 October 2005 18:49, Jeffrey A Law wrote:
>
> > Thoughts?
> >
> I'm not sure this would buy you much better precision.
It's less about better precision as it is about catching those
cases which a
On Tue, 2005-11-01 at 20:49 +0900, Neil Booth wrote:
> I think this is a better approach than the current one, and that
> if we go down this patch then we should grasp the opportunity to
> do it right - the early pass should be in the front end. Let the
> optimizers do the fancy cases. 90% of ca
On Mon, 2005-10-31 at 20:46 -0800, Ian Lance Taylor wrote:
> Jeffrey A Law <[EMAIL PROTECTED]> writes:
>
> > We clearly disagree then. Though my 15+ years of working with GCC I've
> > seen far more complaints about false positives than missing instances
> >
On Mon, 2005-10-31 at 18:52 -0500, Daniel Jacobowitz wrote:
> On Mon, Oct 31, 2005 at 04:49:43PM -0700, Jeffrey A Law wrote:
> > On Sun, 2005-10-30 at 23:40 -0800, Mark Mitchell wrote:
> > > In reviewing the PR list, I saw several (maybe 5?) PRs about problems
> >
On Mon, 2005-10-31 at 17:11 -0800, Mark Mitchell wrote:
> > Certainly if we can't prove f always returns a nonzero value, then a
> > warning should be issued. If we do prove f always returns a nonzero
> > value, then I think it becomes unclear if we should generate a warning.
>
> I don't think i
1 - 100 of 181 matches
Mail list logo
