Hi,
On Fri, 2 Sep 2011, Robert Dewar wrote:
> On 9/2/2011 9:16 AM, Richard Guenther wrote:
>
> Might be interesting to pursue, but we don't know that the null pointers
> being dereferenced are in fact the ones returned by alloca. May not be
> worth the effort.
Given the nature of the work-aro
Hi,
On Thu, 1 Sep 2011, Richard Sandiford wrote:
> Ira Rosen writes:
> >> How about, as Micha suggested, print the location of the loop
> >> we currently investigate from vectorize_loops () where we
> >> call find_loop_location () instead?
> >
> > The problem is that a dump of a single loop can
Hi,
the last change in ipa-split generated a new use of a previously unused
PARM_DECL. When one does this one has to call add_referenced_var. Not
doing so can cause segfault when accessing the (not initialized) var
annotation. So, fixed with the patch.
I took the opportunity to remove all e
Hello,
I'd like to have tighter control over the individual situations that
-mrecip handles, and I think the user might appreciate this too. Hence
I've introduced four new target options -mrecip-div, -mrecip-sqrt,
-mrecip-vec-div and -mrecip-vec-sqrt. I've redefined -mrecip to be
equivalent
Hi,
On Fri, 26 Aug 2011, Jakub Jelinek wrote:
> While you are touching it, I think we should also optimize it as in the
> patch below. I'm afraid no string length optimization would be able to
> figure out that it doesn't have to call strlen twice, because the
> htab_find_slot isn't pure.
Su
Hi,
On Fri, 26 Aug 2011, Richard Guenther wrote:
> >> I am going to be sending the renaming patch later today or tomorrow.
> >> In principle, the things I want to abstract are those that are
> >> forcing me to include lto-streamer.h from
> >> {tree,gimple,data}-streamer.*. I will know better w
Hi,
On Wed, 24 Aug 2011, Richard Guenther wrote:
> This avoids the file/location clutter in front of each line in the
> vectorizer dump. While this is useful for people requesting
> -fvectorizer-verbose=N in dump files this makes you unable to compare
> dumps for testcases on a branch and tru
Hi,
> > Like so. Regstrapped on x86_64-linux (all languages + Ada). Okay for
> > trunk?
>
> Ok.
r177989 (JFYI because it's some time ago to make searching the archives
easier).
Ciao,
Michael.
Hi,
On Tue, 23 Aug 2011, Richard Guenther wrote:
> > This patch removes the comment line, to provide binary reproducibility for
> > any generated gtype.state files.
> >
> > Tested for x86 and PowerPC, no bootstrap in both cases.
> >
> > OK for google/integration? Also, OK for trunk?
>
> Ok for
Hi,
On Mon, 22 Aug 2011, H.J. Lu wrote:
> > void __attribute__((constructor)) bla(void)
> > {
> > __cpu_indicator_init ();
> > }
> >
> > I don't see any complication.?
> >
>
> Order of constructors. A constructor may call functions
> which use __cpu_indicator.
That's why I wrote also:
> The
Hi,
On Mon, 22 Aug 2011, H.J. Lu wrote:
> >> Oh, I thought it was data initialized by the constructor ...
> >
> > Sriramans patch right now has a function __cpu_indicator_init which is
> > called from (adhoc constructed) ctors and that initializes variables
> > __cpu_model and __cpu_features ;-)
Hi,
On Mon, 22 Aug 2011, Richard Guenther wrote:
> > Some functions are extremely large though. Do you mean that MEM
> > itself would be enlarged to have the MEM_ATTRS field so that one
> > operand is the address, then expr, then HWI size, offset, etc.?
> > Because if the mem attrs aren't sh
Hi,
On Sun, 21 Aug 2011, Richard Guenther wrote:
> On Sat, Aug 20, 2011 at 11:02 PM, Richard Henderson wrote:
> > On 08/19/2011 02:04 AM, Richard Guenther wrote:
> >> So make sure that __cpu_indicator initially has a conservative correct
> >> value? I'd still prefer the constructor-in-libgcc op
Hi,
On Thu, 18 Aug 2011, Joseph S. Myers wrote:
> @@ -315,6 +315,10 @@ struct cpp_options
>/* Nonzero means process u/U prefix literals (UTF-16/32). */
>unsigned char uliterals;
>
> + /* Nonzero means process r/R rax strings. If this is set, uliterals
> + must be set as well. */
Hi,
On Thu, 18 Aug 2011, Richard Guenther wrote:
> > CPUID to get target features and set global vars corresponding to the
> > features. So, the builtin should be folded by into the appropriate
> > variable in libgcc.
>
> Hm, but then the variable should reside in libgcc and you'd only need an
Hi,
On Mon, 15 Aug 2011, Michael Matz wrote:
> > > .LFB0:
> > > .cfi_startproc
> > > movsd .LC0(%rip), %xmm2
> > > movapd %xmm0, %xmm1
> > > andpd %xmm2, %xmm1
> > > andnpd %xmm0, %xmm2
> > >
Hi,
On Mon, 15 Aug 2011, Richard Guenther wrote:
> > Adding -msse4, we now generate branchless code using roundsd:
> >
> > .LFB0:
> > .cfi_startproc
> > movsd .LC0(%rip), %xmm2
> > movapd %xmm0, %xmm1
> > andpd %xmm2, %xmm1
> > andnpd %xmm0, %xmm2
> >
Hi,
On Sun, 14 Aug 2011, Richard Guenther wrote:
> > which would be exactly the way no distribution would use it. So please
> > just don't bundle ISL with CLoog.
>
> Well, I would simply have linked the bundled ISL statically into
> libcloog.
Which would still require not exporting the (bundl
Hi,
On Tue, 9 Aug 2011, Michael Matz wrote:
> > Are there any updates on the libada problem or other reasons why the
> > patch cannot go in?
>
> Nope, I've solved that one. Letme update it.
Like so. Regstrapped on x86_64-linux (all languages + Ada). Okay for
Hi,
On Fri, 12 Aug 2011, Diego Novillo wrote:
> 3- Replaces dwarf terminology for numbers with C-like terminology:
> sleb128 -> wide_int
> uleb128 -> wide_uint
I see downthread that this is changed to hwi/uhwi already. I even would
have suggested int/uint directly, as we never stre
Hi,
gcc.dg/graphite/run-id-pr47593.c (included for PR47653) hardcodes -m32 in
dg-options. That's not supported everywhere and the testcase is just as
valid without -m32. If it was the case that it needed -m32 for breaking
that would be catched by normal multilib testing.
Committed as obvious
Hi,
On Wed, 10 Aug 2011, Diego Novillo wrote:
>The API in the tree streamer offers functions to read/write the
>tree header and the body, a streamer cache and everything that
>used to be inside the LTO streamer. This makes no difference to
>LTO, since it simply means that some fo
Hi,
On Tue, 9 Aug 2011, Richard Guenther wrote:
> > Actually we should adjust the ranges only if it's either all positive
> > or negative values from the start and the adjustment keeps us on the
> > same side of zero.
>
> So we kept discussing this to death somewhat. Which eventually resulted
Hi,
On Mon, 8 Aug 2011, Ulrich Weigand wrote:
> > This patch exposes a problem in libada. But I'd still be interested
> > if it fixes the spu problem.
>
> It turns out that the patch not only fixes the pr49771 failure, but in
> fact *all* outstanding vectorizer test case failures on SPU in bo
Hi,
On Mon, 8 Aug 2011, Diego Novillo wrote:
> With these patches I'd like to:
>
> 1 Create independent facilities to stream trees, gimple and other
> data structures independently of LTO. This first patch creates
> the files data-streamer*.[ch], tree-streamer*.[ch] and
> gimple-streamer*
Hi,
On Wed, 3 Aug 2011, Kai Tietz wrote:
> >> This machinery doen't work in this case
> >
> > That's why you have to extend it.
>
> The issue about this machinery is that it assumes that the statement
> itself gets transformed, but for normalized form of invert of bitwise
> operations it is es
Hi,
On Wed, 3 Aug 2011, Kai Tietz wrote:
> > Implement all of this in the normal reassoc machinery that already
> > exists. Don't implement your own walker (which btw is superlinear
> > because you recurse into both operands). If no simplifications were
> > possible you have to fold back the
Hi,
On Tue, 2 Aug 2011, Kai Tietz wrote:
> this patch improves the ability of reassociation pass to simplifiy
> more complex bitwise-binary
> operations with comparisons. We break-up for this patch statements
> like (X | Y) != 0 to X != 0 | Y != 0,
> and (X | Y) == 0 to expanded X == 0 & Y == 0.
Hi,
On Wed, 27 Jul 2011, William J. Schmidt wrote:
> +static long
> +propagate_rank (long rank, tree op)
> +{
> + long phi_prop_rank = phi_propagation_rank (op);
> +
> + if (phi_prop_rank)
> +return MAX (rank, phi_prop_rank);
> +
> + return MAX (rank, get_rank (op));
> +}
I know it's pre-
Hi,
On Wed, 27 Jul 2011, Richard Guenther wrote:
> > > I don't think it is safe to try to get at the VLA type the way you do.
> >
> > I don't understand in what way it's not safe. Do you mean I don't manage to
> > find
> > the type always, or that I find the wrong type, or something else?
>
>
Hi,
On Tue, 26 Jul 2011, Michael Matz wrote:
> On Tue, 26 Jul 2011, Michael Matz wrote:
>
> > Hi,
> >
> > On Tue, 26 Jul 2011, Ulrich Weigand wrote:
> >
> > > > Well, REG_ATTRS->decl is again a decl, not an SSA name. I suppose
> > >
Hi,
jimis noticed this on IRC. Since r160348 there's some dead code in
df_update_entry_block_defs and df_update_exit_block_uses. I'm currently
regstrapping this together with the pointer alignment merging patch on
x86_64-linux, and am going to commit it as obvious when that works.
Ciao,
Mic
On Tue, 26 Jul 2011, Michael Matz wrote:
> Hi,
>
> On Tue, 26 Jul 2011, Ulrich Weigand wrote:
>
> > > Well, REG_ATTRS->decl is again a decl, not an SSA name. I suppose
> > > we'd need to pick a conservative REGNO_POINTER_ALIGN during
> > > expansi
Hi,
On Tue, 26 Jul 2011, Ulrich Weigand wrote:
> > Well, REG_ATTRS->decl is again a decl, not an SSA name. I suppose
> > we'd need to pick a conservative REGNO_POINTER_ALIGN during
> > expansion of the SSA name partition - iterate over all of them in the
> > partition and pick the lowest alignme
Hi,
On Mon, 25 Jul 2011, Richard Henderson wrote:
> >> But the only real consumer of BB_PARTITION is pass_reorder_blocks.
> >> And that pass is already gated to only run if optimization is
> >> enabled. So really there's no point in running this pass without
> >> optimization.
> >>
> >> Comm
Hi,
On Mon, 25 Jul 2011, Dimitrios Apostolou wrote:
> Bug found, in df_mark_reg I need to iterate until regno + n, not n. The error
> is at the following hunk:
>
> --- gcc/df-scan.c 2011-02-02 20:08:06 +
> +++ gcc/df-scan.c 2011-07-24 17:16:46 +
> @@ -3713,35 +3717,40 @@ df_m
Hi,
On Fri, 22 Jul 2011, Richard Henderson wrote:
> Well, technically it's not "broken" yet. It will be as soon as it starts
> touching DF data, since this pass runs before pass_df_initialize_no_opt.
>
> But the only real consumer of BB_PARTITION is pass_reorder_blocks. And
> that pass is alre
Hi,
On Fri, 22 Jul 2011, Richard Guenther wrote:
> Regresses vectorization on i?86 because that defines floathi expanders
> but the vectorizer does not recognize a short -> float conversion
> as that requires different sized vectors (the int -> short truncation
> is also a complication for it).
Hi,
On Tue, 19 Jul 2011, Richard Guenther wrote:
> *** forward_propagate_comparison (gimple stm
> *** 1164,1170
> }
> /* We can propagate the condition into a statement that
>computes the logical negation of the comparison result. */
> ! else if (gi
Hi,
On Mon, 11 Jul 2011, Richard Guenther wrote:
> The following actually works.
>
> Bootstrapped and tested on x86_64-unknown-linux-gnu.
>
> Can you double-check it?
Seems sensible. Given this:
short s;
int i;
for (s = 0; s <= 127; s++)
i += (signed char)(unsigned char)s;
return
Hi,
On Fri, 8 Jul 2011, Kai Tietz wrote:
> This is the reworked patch, It fixes vrp to handle bitwise one-bit
> precision typed operations and to handle some type hoisting cases, Some
> cases can't be handled as long as vrp doesn't allows to insert new
> statements in folding pass. To have in
Hi,
On Fri, 8 Jul 2011, Richard Guenther wrote:
> It should be indeed safe with the current handling of conversions, but
> better be safe. So, like the following?
No. The point is that you can't compare the bounds that VRP computes with
each other when the outcome affects correctness. Think
Hi,
On Thu, 7 Jul 2011, Richard Guenther wrote:
> + tree rhs1 = gimple_assign_rhs1 (stmt);
> + gimple def_stmt = SSA_NAME_DEF_STMT (rhs1);
> + value_range_t *final, *inner;
> +
> + /* Obtain final and inner value-ranges for a conversion
> + sequence (final-type)(intermediate-type)in
Hi,
On Thu, 7 Jul 2011, Richard Guenther wrote:
> Index: gcc/fold-const.c
> ===
> --- gcc/fold-const.c (revision 175962)
> +++ gcc/fold-const.c (working copy)
> @@ -7561,7 +7561,7 @@ fold_unary_loc (location_t loc, enum tre
>if
Hi,
On Wed, 6 Jul 2011, Richard Guenther wrote:
> *** copy_reference_ops_from_ref (tree ref, V
> *** 579,585
>
> memset (&temp, 0, sizeof (temp));
> /* We do not care for spurious type qualifications. */
> ! temp.type = TYPE_MAIN_VARIANT (TREE_TYPE (ref)
Hi,
On Tue, 5 Jul 2011, William J. Schmidt wrote:
> Hm, I didn't think it was (currently) possible for a gimple statement to
> have a mem-ref on both RHS and LHS. Is that incorrect? This is easily
> changed if so, or if the possibility should be left open for the future.
Think aggregate copi
Hi,
On Mon, 4 Jul 2011, Richard Guenther wrote:
> I still do not like the implementation of yet another CSE machinery
> given that we already have two.
>From reading it it really seems to be a normal block-local CSE, without
anything fancy. Hence, moving the pass just a little earlier (before
Hi,
On Wed, 29 Jun 2011, H.J. Lu wrote:
> > diff --git a/gcc/function.c b/gcc/function.c
> > index 81c4d39..131bc09 100644
> > --- a/gcc/function.c
> > +++ b/gcc/function.c
> > @@ -4780,7 +4780,7 @@ expand_function_start (tree subr)
> > cfun->nonlocal_goto_save_area,
> >
Hi,
On Tue, 28 Jun 2011, Andrew Stubbs wrote:
> What I want (and I'm not totally clear on what this actually means) is
> to be able to optimize all the cases where the end result will be the
> same as the compiler produces now (using multiple multiply, shift, and
> add operations).
Okay, then
Hi,
On Tue, 28 Jun 2011, Richard Guenther wrote:
> I'd name the predicate value_preserving_conversion_p which I think is
> what you mean. harmless isn't really descriptive.
>
> Note that you include non-value-preserving conversions, namely int ->
> unsigned int.
It seems that Andrew really d
Hi,
On Mon, 27 Jun 2011, Jan Hubicka wrote:
> > I still like to stream unmodified builtins as builtins, as that is
> > similar to pre-loading the streamer caches with things like
> > void_type_node or sizetype.
>
> Doing so will need us to solve the other one decl rules probly. I didn't
> rea
Hi,
On Tue, 21 Jun 2011, Richard Guenther wrote:
> I failed to see where the scalarizer inserts the temporary vars it
> creates into the scope blocks (thus the gimplify.c hunk ...). Any help
> here is welcome.
The scoping of the scalarizer is a bit funny. gfc_start_scalarized_body
sets up s
Hi,
On Sun, 19 Jun 2011, Mike Stump wrote:
> >> if T is a non-volatile composite type with volatile components, and O
> >> is an object of type T, are the optimizers allowed to remove the
> >> assignment "O := O"?
> >
> > Good question, that I'm not really qualified to answer. Any language
>
Hi,
On Sun, 19 Jun 2011, William J. Schmidt wrote:
> At the risk of being obvious...it seems you could easily combine C1 and
> C2 into a single "bitfield descriptor" TREE_INT_CST operand by using
> both the high and low portions of the constant. Accessor macros could
> be used to hide the sli
Hi,
On Mon, 20 Jun 2011, Richard Guenther wrote:
> > of the specifications; rather, we should consider whether there is a
> > situation where a user could reasonably expect NULL + 0 to be valid.
> > In the example by Richard,
> >
> > int __attribute__((noinline)) foo (void *p, int i)
> > {
> >
Hi,
On Thu, 16 Jun 2011, Richard Guenther wrote:
> > If people want to not create useless conversions in the first place,
> > though, I suspect there are lots of places that create useless
> > conversions in the compiler.
>
> Yeah, the above looks it comes from the frontends - gimplification
Hi,
On Sat, 11 Jun 2011, H.J. Lu wrote:
> We are very inconsistent when saving and restoring non-local goto save
> area. See:
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48016
>
> for detailed analysis. OK for trunk?
> + /* FIXME: update_nonlocal_goto_save_area may pass SA in the wrong
Hi,
On Fri, 10 Jun 2011, Jan Hubicka wrote:
> +static inline struct cgraph_node *
> +cgraph_function_or_thunk_node (struct cgraph_node *node, enum availability
> *availability)
> +{
> + if (availability)
> +*availability = cgraph_function_body_availability (node);
> + return node;
> + ret
Hi,
On Tue, 7 Jun 2011, Richard Guenther wrote:
> > + tree base = get_base_address (lhs);
>
> Probably easier and more complete to do
>
> if (lhs && TREE_CODE (lhs) != SSA_NAME)
> {
> tree base = get_base_address (lhs);
>
>
> I don't like the
Hi,
On Tue, 7 Jun 2011, Richard Guenther wrote:
> > > fold_convert_loc it to the expected type, while the middle-end has
> > > the notion of useless type conversions, fold-const.c is also used by
> > > FEs and I think it is expected to have the types exactly matching.
> > > So (T)s1[10] instea
Hi,
I noticed this a while ago while working on early merging of decls. When
we build thunk decls ourself we give RESULT_DECL of it integer_type, even
when the thunk decl itself says something else. (In particular thunks can
very well return void or a pointer type). This fixes that glitch.
Hi,
On Wed, 1 Jun 2011, Michael Matz wrote:
> Hi,
>
> so here's something more of my patch queue. It adds the facility to merge
> also other trees than types over compilation unit borders. This specific
> patch only deals with STRING_CST and INTEGER_CST nodes. Origi
Hi,
so here's something more of my patch queue. It adds the facility to merge
also other trees than types over compilation unit borders. This specific
patch only deals with STRING_CST and INTEGER_CST nodes. Originally I used
that place for merging declarations, hence the naming of some varia
Hi,
On Mon, 30 May 2011, Alexandre Oliva wrote:
> > 3. expand dominators before dominated blocks, so that DEFs of
> >replaceable SSA names are expanded before their uses. Expand them
> >when they're encountered, but not requiring a REG as a result.
> >Save the RTL expression that
Hi,
On Fri, 27 May 2011, Jakub Jelinek wrote:
> On Fri, May 27, 2011 at 03:59:47PM +0200, Michael Matz wrote:
> > On Thu, 26 May 2011, Steven Bosscher wrote:
> > > > on IRC we discussed about this, here's the RFC patch. It bootstraps
> > > > and causes so
Hi,
On Thu, 26 May 2011, Steven Bosscher wrote:
> > on IRC we discussed about this, here's the RFC patch. It bootstraps
> > and causes some minor regressions most probably due to some missing
> > sprinkled checks for the special clobber insns and sometimes due to
> > having to adjust some reg
Hi,
On Thu, 26 May 2011, Martin Jambor wrote:
> I assume DSE does not remove the stores as that would defeat the purpose
> of the patch.
Right. (The volatileness currently prevents the removal).
> If after optimizations such as SRA, these special stores are the only
> statements accessing th
Hi,
On Thu, 26 May 2011, Richard Guenther wrote:
> > Hmm, I plan to optimize string streaming (since we always stream one
> > uleb to set it is non-NULL that can be easilly handled by assigining
> > NULL string index 0). How precisely you however suggest to bitpack
> > line/column and string
Hi,
On Thu, 26 May 2011, Andrew Haley wrote:
> >>> +Generates the @code{pause} machine instruction.
> >>
> >> But that's missing the fact that it generates a compiler memory
> >> barrier, which is important. And if you think it's not a compiler
> >> memory barrier, please explain
> >>
> >> a.
Hi,
on IRC we discussed about this, here's the RFC patch. It bootstraps and
causes some minor regressions most probably due to some missing sprinkled
checks for the special clobber insns and sometimes due to having to adjust
some regexps.
Anyway, stack slot sharing is currently using the heur
Hi,
On Wed, 25 May 2011, Richard Guenther wrote:
> >> asm volatile ("" : : : "memory") in fact will work as a full memory
> >> barrier
> >
> > How? You surely need MFENCE or somesuch, unless all you care about is
> > a compiler barrier. That's what I think needs to be clarified.
>
> Well, ye
Hi,
On Fri, 20 May 2011, Joseph S. Myers wrote:
> (Apart from the arbitrary division between GCC_OBJS and the xgcc link
> rule, mentioned above, there are other arbitrary divisions that don't
> make sense to me. In particular, the separation between OBJS-common,
> OBJS-md and OBJS-archive, al
Hi,
for various changes we can run into the situation that frontends fill the
cache with a different number of common nodes than the LTO frontend,
leading to confusion of which numbers mean which tree. This can happen
when some global trees are NULL, or when some global trees are
pointer-equa
Hi,
On Mon, 16 May 2011, Ian Lance Taylor wrote:
> >>> httpd being in the top-10 always, fiddling with bugzilla URLs?
> >>> (Note, I don't have access to gcc.gnu.org, I'm relaying info from
> >>> multiple instances of discussion on #gcc and richi poking on it;
> >>> that said, it still might n
Hi,
On Mon, 16 May 2011, Richard Guenther wrote:
> > I think conversion _to_ BOOLEAN_TYPE shouldn't be useless, on the
> > grounds that it requires booleanization (at least conceptually), i.e.
> > conversion to a set of two values (no matter the precision or size)
> > based on the outcome of c
Hi,
On Mon, 16 May 2011, Andrew Haley wrote:
> > It routinely is. bugzilla performance is terrible most of the time
> > for me (up to the point of five timeouts in sequence), svn speed is
> > mediocre at best, and people with access to gcc.gnu.org often observe
> > loads > 25, mostly due to I
Hi,
On Mon, 16 May 2011, Andrew Haley wrote:
> >> It's not quite the same information, surely. Wouldn't searchers be
> >> directed to an email rather than the bug itself?
> >
> > Yes, though there is a link in all mails.
>
> Right, so we are contemplating a reduction in search quality in exch
Hi,
On Mon, 16 May 2011, Richard Guenther wrote:
> We can't use a test for BOOLEAN_TYPE as the middle-end considers a
> INTEGER_TYPE with same precision/signedness as compatible and thus may
> propagate a variable of INTEGER_TYPE there. I don't understand why
> promoting bools to boolean_type
Hi,
On Mon, 16 May 2011, Andrew Haley wrote:
> On 16/05/11 10:45, Richard Guenther wrote:
> > On Fri, May 13, 2011 at 7:14 PM, Ian Lance Taylor wrote:
> >> I noticed that buglist.cgi was taking quite a bit of CPU time. I looked
> >> at some of the long running instances, and they were coming fr
Hi,
On Tue, 10 May 2011, Nathan Froyd wrote:
> > > + /* Do not stream TYPE_POINTER_TO or TYPE_REFERENCE_TO. */
> >
> > Add some wording as to why not? This was copied from existing
> > comments, but I do not remember why we were doing this. Not too
> > critical, anyway.
>
> I'm not entirely
Hi,
On Tue, 10 May 2011, Richard Guenther wrote:
> struct B {
> unsigned bit0 : 1;
> unsigned bit1 : 1;
> };
>
> void
> foo (struct B *b)
> {
> b->bit0 = b->bit0 | b->bit1;
> }
>
> we with this patch generate
>
> D.2686_2 = b_1(D)->bit0;
> D.2688_4 = b_1(D)->bit1;
> D.2693_10 = D.2
Hi,
On Fri, 6 May 2011, Jan Hubicka wrote:
>
> *** dump_cgraph_node (FILE *f, struct cgraph
> *** 1874,1880
> if (node->only_called_at_exit)
> fprintf (f, " only_called_at_exit");
>
> ! fprintf (f, "\n called by: ");
> for (edge = node->callers; edge; edge
Hi,
-Ofast is intended to be -O3 plus -ffast-math. For the compiler proper
this works, but under -ffast-math we add crtfastmath.o (or some
equivalent) to the link command line on some targets. As usual for our
specs this uses matching on command line arguments, hence we'll
explicitely have t
Hi,
On Wed, 4 May 2011, Richard Kenner wrote:
> > There are pros and cons about early optimization, actually.
> > Generating extremely optimized IL very early can actually tie up
> > subsequent passes. For instance, loop unrolling and vectorization.
> > There are others in the literature.
>
> S
Hi,
On Wed, 4 May 2011, Richard Guenther wrote:
> > It prevents save_expr from being called at global level, since you
> > cannot create SAVE_EXPRs outside functions. Likewise in
> > variable_size.
>
> I see several places in fold-const.c that are not properly guarded then.
> But anyway, if
Hi,
On Tue, 3 May 2011, Richard Guenther wrote:
> --- 5858,5890
>
> /* If these are the same operation types, we can associate them
>assuming no overflow. */
> ! if (tcode == code)
> ! {
> ! double_int mul;
> ! int overflow_p;
> ! mul = double_
Hi,
On Mon, 2 May 2011, Richard Guenther wrote:
> >> --- 348,367
> >> bool insert_at_next_slot_p)
> >> {
> >> void **slot;
> >> unsigned ix;
> >> bool existed_p;
> >>
> >> gcc_assert (t);
> >>
> >> ! slot = pointer_map_insert (cache->node_map, t
Hi,
On Mon, 2 May 2011, Richard Guenther wrote:
> >> /* The mapping between tree nodes and slots into the nodes array. */
> >> ! struct pointer_map_t GTY((skip)) *node_map;
> >
> > If you skip node_map you can end up with false entries for re-used
> > trees. So I don't think that's a good
Hi,
On Mon, 2 May 2011, Jan Hubicka wrote:
> ! d_entry.base.from = t;
> ! slot = htab_find_slot (cache->node_map, &d_entry, INSERT);
> ! if (*slot == NULL)
> {
> /* Determine the next slot to use in the cache. */
> if (insert_at_next_slot_p)
> ix = VEC_length (t
Hi,
On Thu, 21 Apr 2011, Richard Guenther wrote:
> >> > It would have been nice to have the top-level tree merging as a
> >> > separate patch, as I am not convinced it is correct, but see below ...
> >>
> >> I'll split it out.
> >
> > Like so (also including the other remarks).
> >
> > Regstrappi
Hi,
since the split of warn_uninitialized to warn_maybe_uninitialized the
fortran and Ada frontends have changed behaviours (causing uninit_func.adb
to fail). I've left out the Java frontend because it also didn't set
warn_uninitialized with -Wall before, and go because it doesn't do
anything
Hi,
On Wed, 27 Apr 2011, Jan Hubicka wrote:
> *** false_predicate (void)
> *** 163,168
> --- 166,195
> }
>
>
> + /* Return true if P is (false). */
> +
> + static inline bool
> + true_predicate_p (struct predicate *p)
Comment doesn't match function.
> + {
> + r
Hi,
On Wed, 20 Apr 2011, Richard Guenther wrote:
> > I had occasion to try this today; this inheritance structure doesn't
> > work. The truncated inheritance tree looks like:
> >
> > * decl_common
> > * field_decl
> > * const_decl
> > * decl_with_rtl
> > * label_decl
> > * result_decl
>
Hi,
On Wed, 20 Apr 2011, Easwaran Raman wrote:
> But you're right - not adding that conflict doesn't actually reduce the
> size of bit maps. Reverting back to what was there originally.
Thanks, I have no more issues with the patch. You'll need to find someone
who can formally approve it, thou
Hi,
On Wed, 20 Apr 2011, Michael Matz wrote:
> > It would have been nice to have the top-level tree merging as a
> > separate patch, as I am not convinced it is correct, but see below ...
>
> I'll split it out.
Like so (also including the other remarks).
Regstrap
Hi,
I wrote:
> Basically we have to set assembler names early also for TYPE_DECLs, we
> can't rely on the frontends langhook to do that after free_lang_data.
>
> Okay for trunk assuming regstrapping on x86_64-linux works?
Patch retracted, doesn't even survive testsuite. The problem is that we
Hi,
as noted in the bug trail the fix for PR48207 broke compilation of C++
programs with -g. This variant fixes the bug too without breaking -g.
Basically we have to set assembler names early also for TYPE_DECLs, we
can't rely on the frontends langhook to do that after free_lang_data.
Okay fo
Hi,
On Wed, 20 Apr 2011, Richard Guenther wrote:
> >> If t is a type, why fix up its field if it may not be the canonical
> >> variant?
> >
> > Because type merging to work sometimes requires already canonicalized
> > fields, at least that's what I found in investigating why some types
> > weren
Hi,
On Tue, 19 Apr 2011, Easwaran Raman wrote:
> > That is correct but is also what the use of stack_vars[u].representative
> > achieves alone, ...
> >
> >> I am adding a check to that effect.
> >
> > ... without any check.
> >
> > @@ -596,7 +581,8 @@
> > if (vb->conflicts)
> > {
> >
Hi,
On Wed, 20 Apr 2011, Richard Guenther wrote:
> > + /* A hashtable of trees that potentially refer to variables or functions
> > + that must be replaced with their prevailing variant. */
> > + static GTY((if_marked ("ggc_marked_p"), param_is (union tree_node)))
> > htab_t
> > + tree_wit
701 - 800 of 848 matches
Mail list logo
