On Sun, 2005-02-27 at 18:16 -0500, Kazu Hirata wrote:
> Hi,
>
> Consider the following code from
> tree-ssa-dom.c:tree_ssa_dominator_optimize.
>
> /* Thread jumps, creating duplicate blocks as needed. */
> cfg_altered = thread_through_all_blocks ();
>
> /* Removal of statement
On Mon, 2005-02-28 at 17:08 +0100, Richard Guenther wrote:
> Hi!
>
> It seems the current dg infrastructure does not support scanning
> tree-dumps dumped via -fdump-ipa-XXX because they are labeled
> differently. I worked around this by replacing
>
> set output_file "[glob [file tail $testca
On Mon, 2005-02-28 at 10:01 -0800, Dale Johannesen wrote:
> On Feb 28, 2005, at 4:43 AM, Joern RENNECKE wrote:
>
> > Dale Johannesen wrote:
> >
> >>Well, no, what is supposed to happen (I haven't tried it for a
> >> while, so I don't promise
> >> this still works) is code like this:
> >>
> >>
On Tue, 2005-03-01 at 14:09 -0500, Diego Novillo wrote:
> Janis Johnson wrote:
>
> > I also find it annoying that the dump files aren't cleaned up. Should
> > the dump files for failing tests be left, or would it be OK to remove
> > all of them?
> >
> Much as I don't use the failing executables
On Tue, 2005-03-01 at 10:25 -0800, Janis Johnson wrote:
> On Mon, Feb 28, 2005 at 10:23:56AM -0700, Jeffrey A Law wrote:
> > On Mon, 2005-02-28 at 17:08 +0100, Richard Guenther wrote:
> > > Hi!
> > >
> > > It seems the current dg infrastructure does not supp
On Wed, 2005-03-02 at 14:55 -0800, Janis Johnson wrote:
> On Wed, Mar 02, 2005 at 11:41:13AM -0700, Jeffrey A Law wrote:
> > On Tue, 2005-03-01 at 14:09 -0500, Diego Novillo wrote:
> > > Janis Johnson wrote:
> > >
> > > > I also find it annoying that th
On Tue, 2005-03-08 at 09:06 -0800, Mark Mitchell wrote:
> Nathan Sidwell wrote:
>
> > Notice that the last specified argument 'union U' has no name. when
> > compiled for ia64-hp-hpux11.23 with -mlp64 this ICEs because of this
> > bit of code in assign_parm_find_data_types
> >
> > /* Set LAST_
On Tue, 2005-03-08 at 17:25 +, Paul Brook wrote:
> > (a) the numbers reported by the "time" command,
>
> real3m52.604s
> user3m15.490s
> sys 0m29.550s
>
> > (b) what sort of machine this is and how old
>
> hp-pa 712/80. At least 7 years only, probably more. This machine takes man
On Mon, 2005-03-14 at 16:17 -0800, Joe Buck wrote:
> On Mon, Mar 14, 2005 at 06:44:16PM -0500, Richard Stallman wrote:
> > After some 20 years of developing popular free software, I have
> > somewhat of an idea what users are likely to do.
>
> Many of us have developed software for a similar perio
I'm sitting here analyzing a regression with some pending jump threading
changes and I've stumbled upon this quirk in IV opts which, if nothing
else, makes it very difficult to evaluate the jump threading changes.
Specifically, the set of IVs selected for a loop changes when the
version #s of ob
On Fri, 2005-03-18 at 18:25 +0100, Zdenek Dvorak wrote:
> Hello,
>
> > Which appears to walk down the array and try and choose better IV sets.
> > Since it walks down the IV array, which is in SSA_NAME_VERSION order.
> > Thus two loops which are equivalent in all ways except that they use
> > diff
On Sun, 2005-03-27 at 20:08 -0500, Kazu Hirata wrote:
> Hi Diego,
>
> > By merging, do you mean *replacing* CCP with VRP? Yes, it's
> > doable. No, it's not a good idea.
>
> Understood.
>
> Also, if we are inserting ASSERT_EXPRs, it seems to be a good idea to
> run copy-prop before VRP. Other
On Wed, 2005-03-30 at 13:22 -0500, Diego Novillo wrote:
> On Wed, Mar 30, 2005 at 10:58:39AM -0700, Jeffrey A Law wrote:
>
> > Whatever scheme we use to explicitly expose context sensitive
> > equivalences in the IL needs to be a pure expression.
> >
> Well, that&
On Wed, 2005-03-30 at 14:19 -0500, Kazu Hirata wrote:
> Hi Jeff,
>
> > We'd have to go back and find the PR. I don't remember all the
> > details, but the problem was big enough to make ASSERT_EXPRs a
> > far inferior solution to the others I'd looked at for recording
> > context sensitive equiva
There's a rather annoying bug in the vectorizer which can cause us to
have SSA_NAMEs which are used, but never defined.
Consider this testcase compiled with -msse2 -ftree-vectorize:
typedef char achar __attribute__ ((__aligned__(16)));
int main1 ()
{
struct {
achar *p;
achar *q;
} s;
On Fri, 2005-04-08 at 13:04 -0400, Daniel Berlin wrote:
> > When we rescan the operands, we get a different set of V_MAY_DEFS,
> > specifically we lose the V_MAY_DEF for SFT.3_20.
>
> Why?
>
> It should be copying subvars to the new vectorizer variable too.
> At least, i believe i added that.
Whe
On Fri, 2005-04-08 at 18:58 +0200, Jakub Jelinek wrote:
> On Fri, Apr 08, 2005 at 10:52:02AM -0600, Jeffrey A Law wrote:
> > There's a rather annoying bug in the vectorizer which can cause us to
> > have SSA_NAMEs which are used, but never defined.
> >
> > Cons
On Fri, 2005-04-08 at 13:27 -0400, Andrew MacLeod wrote:
>
>
> What are these uses?
The later uses are scalar reads from the same memory location.
> If they are references to things that aliased
> *D.1470_8, we should eliminate the VUSE/MAYDEF, shouldnt we? I presume
> they arent relevant any
On Fri, 2005-04-08 at 13:55 -0400, Diego Novillo wrote:
> On Fri, Apr 08, 2005 at 10:52:02AM -0600, Jeffrey A Law wrote:
>
> > It would probably be wise to audit the other uses of
> > copy_virtual_operands. We might also consider forcing statement
> > rescans as part of
On Fri, 2005-04-08 at 13:41 -0400, Andrew MacLeod wrote:
> On Fri, 2005-04-08 at 13:27, Andrew MacLeod wrote:
> > On Fri, 2005-04-08 at 12:52, Jeffrey A Law wrote:
> >
>
> actually, I'll jsut keep talking to myself here :-)
>
> > > In the interest of br
On Fri, 2005-04-08 at 13:39 -0400, Daniel Berlin wrote:
> On Fri, 2005-04-08 at 11:08 -0600, Jeffrey A Law wrote:
> > On Fri, 2005-04-08 at 13:04 -0400, Daniel Berlin wrote:
> > > > When we rescan the operands, we get a different set of V_MAY_DEFS,
> > > > speci
On Mon, 2005-04-11 at 13:03 -0400, Daniel Jacobowitz wrote:
> On Mon, Apr 11, 2005 at 10:02:06AM -0700, Daniel Kegel wrote:
> > BTW, I hope -fno-unit-at-a-time doesn't go away until at least gcc-4.1.1
> > or so... I still lean on that crutch.
>
> A user! Can you explain why?
Actually, I still use
On Sat, 2005-04-09 at 23:23 -0400, Diego Novillo wrote:
> On Fri, Apr 08, 2005 at 10:52:02AM -0600, Jeffrey A Law wrote:
>
> > When we vectorize the store we copy the virtual operands from the
> > original statement to the new vectorized statement via this code:
> >
>
On Tue, 2005-04-12 at 14:36 -0400, Kazu Hirata wrote:
> Hi,
>
> Note that with -O1, we limit the number of iterations of DOM to 1 so
> that we can get resonable compile time performance. I was wondering
> what happens if we do the same with -O2 now that we have passes like
> copy-prop, VRP, and i
On Sat, 2005-04-09 at 23:23 -0400, Diego Novillo wrote:
> On Fri, Apr 08, 2005 at 10:52:02AM -0600, Jeffrey A Law wrote:
>
> > When we vectorize the store we copy the virtual operands from the
> > original statement to the new vectorized statement via this code:
> >
>
So the combination of the TCB merge plus the pending jump threading
changes apparently has ticked a reload bug which manifests itself with
the stage1 compiler mis-compiling the stage2 compiler.
Upon entry into local-alloc we have the following key insns:
(insn:HI 88 85 89 10 (set (reg:QI 66 [ D.
On Tue, 2005-04-19 at 08:49 +0200, Eric Botcazou wrote:
> > So the combination of the TCB merge plus the pending jump threading
> > changes apparently has ticked a reload bug which manifests itself with
> > the stage1 compiler mis-compiling the stage2 compiler.
> >
> > [...]
> >
> > Which faults be
On Tue, 2005-04-19 at 21:36 +0200, Eric Botcazou wrote:
> > > For 3.3 and 3.4, this was "fixed" by not recording memory equivalences
> > > that have the infamous RTX_UNCHANGING_P flag set.
> >
> > Also a possibility. Making the equivalent change (!MEM_READONLY_P)
> > appears to do the trick for ma
On Wed, 2005-04-20 at 17:18 +0200, Eric Botcazou wrote:
> > Think about it for a while -- given a SET where the SET_SRC is a
> > pseudo which did not get a hard register and is equivalenced to
> > a read-only memory location, then the SET must be dead as it
> > can only be setting the memory locati
On Wed, 2005-04-20 at 18:51 +0200, Eric Botcazou wrote:
> > Yes, I meant SET_DEST. Do you see how if a SET_DEST is a pseudo
> > which did not get a hard register and is equivalent to a readonly
> > memory location that the insn is useless?
>
> Yes, I think so: being equivalenced implies that ther
Just some notes I've gathered on folding statements modified by TER...
First, a lot of the changes made do not affect the code we generate in
a meaningful way. That's because a lot of the changes merely reorder
operands in conditionals, arithmetic expressions and the like. For
example, after TE
On Tue, 2005-04-26 at 23:40 -0700, Zack Weinberg wrote:
> Wasn't TER a temporary kludge that should be going away?
When we have a tree combiner I would expect TER to disappear.
jeff
On Wed, 2005-04-27 at 16:19 +0200, Richard Guenther wrote:
> fold_indirect_ref, called from the gimplifier happily converts
>
> const char *a;
>
> ...
>
> *(char *)&a[x] = 0;
>
> to
>
> a[x] = 0;
>
> confusing alias1 and ICEing in verify_ssa:
>
> /net/alwazn/home/rguenth/src/gcc/cvs/gcc-4
On Wed, 2005-04-27 at 09:35 -0700, Richard Henderson wrote:
> On Wed, Apr 27, 2005 at 12:36:41AM -0600, Jeffrey A Law wrote:
> > Anyway, I'm going to look into why we're seeing so many *& expressions
> > during TER.
>
> We have an open PR for this. We don&
On Wed, 2005-04-27 at 08:47 -0400, Andrew MacLeod wrote:
> On Wed, 2005-04-27 at 04:22, Jeffrey A Law wrote:
> > On Tue, 2005-04-26 at 23:40 -0700, Zack Weinberg wrote:
> > > Wasn't TER a temporary kludge that should be going away?
> > When we have a tree combiner I
On Wed, 2005-04-27 at 19:14 +0200, Richard Guenther wrote:
> Jeffrey A Law wrote:
> > On Wed, 2005-04-27 at 16:19 +0200, Richard Guenther wrote:
> >
> >>fold_indirect_ref, called from the gimplifier happily converts
> >>
> >> const char *a;
> >>
On Wed, 2005-04-27 at 16:19 +0200, Richard Guenther wrote:
> fold_indirect_ref, called from the gimplifier happily converts
>
> const char *a;
>
> ...
>
> *(char *)&a[x] = 0;
>
> to
>
> a[x] = 0;
>
> confusing alias1 and ICEing in verify_ssa:
>
> /net/alwazn/home/rguenth/src/gcc/cvs/gcc-4
On Wed, 2005-05-04 at 10:28 -0400, Andrew MacLeod wrote:
> Why is it we try to swap operands in get_expr_operands, where we are
> otherwise simply parsing not modifying?
>
> /* If it would be profitable to swap the operands, then do so to
>canonicalize the statement, enabling b
On Mon, 2005-05-09 at 17:45 +0300, Mostafa Hagog wrote:
>
>
>
> It appears that GCSE considers "read only memory" as call clobbered, which
> is not the case in CSE. I have took the test for read-only memory from CSE
> and add it to GCSE where we compute the transparency. Here is a patch that
> d
On Thu, 2005-05-12 at 15:37 -0700, Richard Henderson wrote:
> On Thu, May 12, 2005 at 01:14:15PM -0400, Diego Novillo wrote:
> > Am I missing something here?
>
> Probably not.
Isn't operand_equal_p used in situations where we're eliminating
instructions -- and isn't the TREE_SIDE_EFFECT bit there
On Mon, 2005-05-23 at 11:42 -0400, Eric Christopher wrote:
> > Eric (and anyone else who wasn't aware): there's been a lot of
> > discussion about this on gcc-patches since I posted that message:
> >
> > http://gcc.gnu.org/ml/gcc-patches/2005-05/msg02029.html
> >
> > It's also PR21638:
> >
>
On Mon, 2005-05-23 at 16:34 +0100, Richard Earnshaw wrote:
> On Mon, 2005-05-23 at 16:19, Eric Christopher wrote:
> > > > http://gcc.gnu.org/wiki/GCC%204.1%20Slush
> > >
> > > Just to let folks know that mips-elf fails to build newlib.
> > > There's a segfault in is_gimple_reg_type(), which is b
On Mon, 2005-05-23 at 12:19 -0400, Daniel Berlin wrote:
> >
>
> Originally, this is one of the reasons the patch was not committed:
> There were places in fortran that weren't clean, etc, and i just didn't
> have time to go hunting (which is why i posted it to gcc patches, and
> left it out there
On Mon, 2005-05-23 at 17:25 +0100, Richard Earnshaw wrote:
> On Mon, 2005-05-23 at 17:20, Jeffrey A Law wrote:
> > On Mon, 2005-05-23 at 16:34 +0100, Richard Earnshaw wrote:
> > > On Mon, 2005-05-23 at 16:19, Eric Christopher wrote:
> > > > > > http:
On Mon, 2005-05-23 at 11:04 -0700, Mark Mitchell wrote:
> Jeffrey A Law wrote:
> > much rather bite the bullet and get them fixed now. The fact that it's
> > affecting a lot of people keep the coals hot on my feet :-)
>
> Jeff --
>
> I know you're doing e
On Mon, 2005-05-23 at 11:43 -0700, Mark Mitchell wrote:
> Fair enough. Would you mind reporting back later today, then? One
> possibility is to do the changes that fix our primary languages (C, C++,
> and Java, since it's easy) and deal with Fortran later. If we can get
> the mainline bootst
So when's the last time someone bootstrapped Ada with the mainline
sources on i686-pc-linux-gnu?
I was trying to get it built to further exercise the ADDR_EXPR
status bit checking code and it consistently hangs building the
stage3 compiler (even with all the recent ADDR_EXPR stuff disabled).
Rat
On Wed, 2005-05-25 at 14:14 -0400, Diego Novillo wrote:
> On Wed, May 25, 2005 at 02:09:12PM -0400, Richard Kenner wrote:
> > I may be mistaken, but didn't GCC miscompile the Ada front end because
> > of this VRP bug here: http://gcc.gnu.org/PR21332 ?
> >
> > I'm not sure if that was it,
On Wed, 2005-05-25 at 23:46 +0200, Andreas Schwab wrote:
> Jeffrey A Law <[EMAIL PROTECTED]> writes:
>
> > So, if I wanted to be able to bootstrap Ada, what I do I need
> > to do? Disable VRP? Disable something in the loop optimizer?
> > Anything else?
>
>
On Mon, 2005-05-30 at 12:32 -0400, Diego Novillo wrote:
> I have a new test case where the dump file ought to have 2
> occurrences of the pattern "PREDICATE: p.* ne_expr 0B", so I
> added
>
> /* { dg-final { scan-tree-dump-times "PREDICATE: p.* ne_expr 0B" 2 "vrp" } }
> */
>
> but I'm getting a
On Mon, 2005-05-23 at 10:47 +0300, Mostafa Hagog wrote:
>
>
>
>
> Jeffrey A Law <[EMAIL PROTECTED]> wrote on 09/05/2005 18:17:45:
>
> > Yes, it looks quite reasonable. Please go ahead with the full testing
> > cycle and consider the patch pre-approved onc
On Sun, 2005-06-05 at 12:41 -0400, Nathanael Nerode wrote:
> * hppa1.1-*-bsd*
I'm 99.9% sure this can go -- in fact, I just recently found out that
the previous single largest installation of PA BSD boxes recently shut
off its last PA.
jeff
> The VRP pass is inside tree-ssa-dom.c for GCC 4.0.
Yup. And it's very very weak.
> GCC 4.1 has a much more powerful VRP pass, which is not related
> to the DOM pass.
Exactly. Hopefully we'll be able to remove the DOM version before
4.1 since the new tree-vrp.c is vastly better.
jeff
On Tue, 2005-06-28 at 00:20 -0700, Mark Mitchell wrote:
> As stated earlier, the only patches I'm considering for 4.0.1 at present
> are wrong-code cases on primary platforms. There are several open, but
> the only one I consider a show-stopper is PR 22051, which Jeff Law is
> working on, and h
On Tue, 2005-06-28 at 08:50 -0700, Mark Mitchell wrote:
> Perhaps you could get a patch put together, test it by staring
> atassembly output, and then ask for a volunteer to test it? I expect
> that Joseph could do a test run on PA-HPUX for you.
It might be the best bet. I'm going to clean out
On Tue, 2005-06-28 at 08:50 -0700, Mark Mitchell wrote:
> Jeffrey A Law wrote:
> > On Tue, 2005-06-28 at 00:20 -0700, Mark Mitchell wrote:
> >
> >>As stated earlier, the only patches I'm considering for 4.0.1 at present
> >>are wrong-code cases on primary p
On Tue, 2005-06-28 at 08:50 -0700, Mark Mitchell wrote:
> Jeffrey A Law wrote:
> > On Tue, 2005-06-28 at 00:20 -0700, Mark Mitchell wrote:
> >
> >>As stated earlier, the only patches I'm considering for 4.0.1 at present
> >>are wrong-code cases on primary p
On Wed, 2005-06-29 at 13:39 -0700, Mark Mitchell wrote:
> First, we're close to a release. We've been waiting on one fix since
> Friday, and Jeff Law has promised to fix it today.
The fix is written, I'm just waiting on test results. Someone mucked
up the hpux11 target description (*) which caus
On Wed, 2005-06-29 at 16:17 -0700, Joe Buck wrote:
> On Wed, Jun 29, 2005 at 03:53:18PM -0600, Jeffrey A Law wrote:
> > (*) The hpux11 target description assumes that the linker shipped with
> > hpux11 supports +init as an option. Well, that may work OK for some
> > versi
On Thu, 2005-06-30 at 18:55 +0200, Steven Bosscher wrote:
> On Thursday 30 June 2005 18:05, fjahanian wrote:
> > On Jun 27, 2005, at 2:50 PM, Fariborz Jahanian wrote:
> > > On Jun 27, 2005, at 12:56 PM, Richard Henderson wrote:
> > >> Hmm. I would suspect this is obsolete now. We'll have forced
>
On Thu, 2005-06-30 at 20:12 +0200, Bernd Schmidt wrote:
> Jeffrey A Law wrote:
> > I'd tend to agree. I'd rather see the option go away than linger on
> > if the option is no longer useful.
>
> I wouldn't mind that, but I'd also like to point out that th
On Fri, 2005-08-05 at 09:59 -0400, Diego Novillo wrote:
> In PR 23046 we ICE inside tree-vrp.c because fold() does not
> realize that for
>
> enum enumtype { ENUM1, ENUM2 } x;
>
> the predicate 'if (x > 1)' is always false. This causes VRP to
> create the impossible range [2, 1] for that predica
On Sun, 2005-08-21 at 20:32 +0200, Falk Hueffner wrote:
> Hi,
>
> I'm trying to implement a tree pass that warns about bad array
> accesses as suggested for PR 8268 by Jeff Law. However, I have trouble
> with the following:
>
> char digit_vector[5];
> const char *ggc_alloc_string(int length) {
>
On Wed, 2005-08-24 at 13:22 -0400, Daniel Berlin wrote:
> Currently, get_expr_operands "renormalizes" the actual tree operands on
> it's own whim , such that if you call update_stmt on something like "a +
> c", it may be "c + a" after the call to update_stmt.
> This is not the same as sorting the u
> Ive never been a big fan of having to call something to release
> ssa_names, its too bug prone. I would much prefer to see something like
> a cleanup pass done every once in a while... an ssa-name garbage
> collector if you will :-). It seems to me that between major
> optimization passes, any
On Wed, 2005-08-24 at 18:19 -0400, Andrew Pinski wrote:
> I am writing a "quick and dirty" DCE pass which is faster the
> current DCE and does not do anything with stores/loads.
FWIW, I've always been a fan of a very very simple DCE pass
which can be scheduled often, possibly after every pass that
On Wed, 2005-08-24 at 18:28 -0400, Daniel Berlin wrote:
> > If we take this after DCE, we still refer to a statement which no longer
> > exists which we don't collect in the GC.
> As i said when i pointed this out to you, we should probably skip
> walking common.chain on SSA_NAME.
> But that's non-
On Thu, 2005-08-25 at 02:42 -0400, James Morrison wrote:
> Hey,
>
> I'm going to do more testing on this, but it seems this patch reduces the
> number of DOM iterations from the number of else if statements in pr19097 to
> 2 DOM iterations.
Certainly any time we can optimize more of the compari
On Mon, 2005-09-05 at 17:39 -0400, Richard Kenner wrote:
> Suppose lhs_vr is [64,64] and vr_result is ~[0,0]. It would seem
> that the code near the end of this function will malfunction.
>
> Shouldn't the test be that both lhs_vr *and* vr_result are VR_RANGE?
>
> This is causing an ACATS failur
On Sun, 2005-09-11 at 10:37 +0200, Zdenek Dvorak wrote:
> Hello,
>
> I have run into following problem with dom. One of the places
> where cfg_altered is set is wrong:
It's not really wrong, it's set this way on purpose, specifically
to avoid the compile-time explosion you're seeing.
> So I trie
On Sun, 2005-09-11 at 16:41 +0200, Zdenek Dvorak wrote:
> No, it unfortunately cannot help. The new blocks are placed before the
> loop, and jump threading only occurs inside the loop, so the sizes of
> copied blocks remain small.
Yea, you're right. It's been a while since I looked at this...
Th
On Sat, 2005-10-22 at 03:25 +0200, Giovanni Bajo wrote:
> Besides the fact that you must have used -N, remember that you don't need all
> those merging tags anymore (forever). You can either live with a single tag
> per
> branch which you move along, or don't use tags alone and use svnmerge.py (se
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
> with -Wuninitialized.
Joys...
> All of these problems related to getting confused in the optimizers in
> various ways; sometimes we think things are uninitialized when
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
> with -Wuninitialized.
[ ... ]
After pondering this some more I almost wonder if what we need is a
separate warning for variables which were potentially uninitialized
bu
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
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 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 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 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 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 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 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 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 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 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 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 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: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 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 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 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 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: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 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 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 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 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
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 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
> >
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
1 - 100 of 181 matches
Mail list logo
