Hi Andrew,
On Wed, 25 Oct 2006, Andrew Haley wrote:
> I must admit to being a little perplexed by this.
>
> We have an unsafe optimization that causes bad code to be generated on
> at least one platform. However, we want to continue to perform this
> unsafe optimization on our release branch unt
On Wed, 25 Oct 2006, Richard Sandiford wrote:
> Roger Sayle <[EMAIL PROTECTED]> writes:
> > Once explained, I'd expect most maintainers would make precisely the
> > same call?
>
> I suppose the counter-argument is that we shouldn't ship 4.2 in its
> curre
On Wed, 25 Oct 2006, David Daney wrote:
> The patch is fully tested and ready to go for the 4.2 branch.
The last thing I want is for this fix to get delayed whilst we argue
over patch testing/approval policy. This fix addresses the known
wrong-code issue, and at worst may replace it with missed
Hi Paolo,
On Mon, 30 Oct 2006, Paolo Bonzini wrote:
> Given that Roger started the ball rolling, by approving Steven's
> -fcse-skip-blocks patch, I'll ping the discussion...
>
> http://gcc.gnu.org/ml/gcc-patches/2006-10/msg01066.html
I believe the appropriate next step is to freshen these patche
On Tue, 31 Oct 2006, Dave Korn wrote:
> Tracking down a gcse bug while unrolling a loop where the count is
> known to be one, I've narrowed the problem down to the actions of
> commit_edge_insertions and bypass_conditional_jumps, and I could use
> a little help in appreciating the reasoning behin
Hi Manuel and Paolo,
On Sun, January 14, 2007 3:59 pm, Paolo Carlini wrote:
>>> By the way, "new" also wrt current 4_2-branch, in the sense that the
>>> latter doesn't emit *any* overflow warning for the snippet in 30465,
>>> with explicit -Wconversion too...
I think I can explain everything. T
I should probably also add that if any of the branches scheduled for
merge prior to 4.1 contain/require changes to "fold", perhaps for
additional transformations they need, I'll be glad to review/approve
those specific changes now, ahead of their branch's planned merge dates
to allow them to synch
On Thu, 3 Mar 2005, Kazu Hirata wrote:
> If we want to change fold_builtin to take operands like op0, op1, and
> op2, I would have to change so many things that depend on
> fold_builtin. (Note that the subroutines of fold_builtin also depends
> on fold_builtin in a sense that they need the origin
Hi Alex and Mark,
On 7 Mar 2005, mark at codesourcery dot com wrote:
> Yes, I understand. You still need to take it up with Roger, though.
My apologies to both of you for being curiously/annoyingly silent on
this is issue. I've been getting up to speed on the internals of the
C++ parser, in or
On Mon, 7 Mar 2005, Mark Mitchell wrote:
> Roger Sayle wrote:
> > For example, I believe that Alex's proposed solution to PR c++/19199
> > isn't an appropriate fix. It's perfectly reasonable for fold to convert
> > a C++ COND_EXPR into a MIN_EXPR or MAX_EXP
On Mon, 7 Mar 2005, Mark Mitchell wrote:
> Roger Sayle wrote:
> > I truly hope you're not trying to suggest that it was me that introduced
> > the concept of MIN_EXPR and MAX_EXPR as lvalues into the C++ front-end:
>
> I thought you were the person who introduced change
On Mon, 7 Mar 2005, Richard Henderson wrote:
> On Mon, Mar 07, 2005 at 08:55:14AM -0700, Roger Sayle wrote:
> > For rvalue MIN_EXPR and rvalue MAX_EXPR, the semantics need
> > to specify a reference to the first operand is returned for values
> > comparing equal.
>
&
Hi DJ,
On Mon, 21 Mar 2005, DJ Delorie wrote:
> 2005-03-21 DJ Delorie <[EMAIL PROTECTED]>
>
> * optabs.c (expand_binop): Make sure the first subword's result
> gets stored.
This is OK for mainline, provided that you bootstrap and regression
test it somewhere. Thanks. You're quite
ken to extremes, these policies can clearly
be dangerous (if none of these cc1 files contains K&R prototypes,
perhaps we could drop parser support for pre-ANSI C, etc...).
Roger
--
Roger Sayle, E-mail: [EMAIL PROTECTED]
OpenEye Scientific Software, WWW: http://www.eyesopen.com/
Suite 1107, 3600 Cerrillos Road, Tel: (+1) 505-473-7385
Santa Fe, New Mexico, 87507. Fax: (+1) 505-473-0833
I seem to have inadvertantly annoyed Steven Bosscher on IRC,
so by way of an apology and explanation I thought I'd post my current
opinion and thinking on the optimizations performed by GCC's middle-end
both at the tree-level in the tree-ssa optimizers and at the
RTL-level in the exisiting RTL-opt
On Sat, 16 Apr 2005, Richard Kenner wrote:
> Although, RTL expansion may introduce new loops, these tend to be
> rare, and the expanders have all the information they need to
> hoist/sink invariant expressions and unroll/peel themselves.
>
> I disagree. In order to make the proper dec
On Mon, 18 Apr 2005, Paolo Bonzini wrote:
> Roger proposed lowering 64-bit arithmetic to 32-bit in tree-ssa! How
> would you do it? Take
>
> long long a, b, c;
> c = a + b;
>
> Would it be
>
> c = ((int)a + (int)b)
> + ((int) (a >> 32) + (int) (b >> 32)
> + ((
NO_MATH_INLINES should cure
this.
Thanks in advance,
Roger
--
Roger Sayle, E-mail: [EMAIL PROTECTED]
OpenEye Scientific Software, WWW: http://www.eyesopen.com/
Suite 1107, 3600 Cerrillos Road, Tel: (+1) 505-473-7385
Santa Fe, New Mexico, 87507. Fax: (+1) 505-473-0833
On 30 Apr 2005, Gabriel Dos Reis wrote:
> There were 36 PRs open against it (as of this morning, 6am, GMT-05).
> I wnet through all of them and the appeared to be very minor or
> impossible bugs to fix in 3.3.6 major restructuring (typically, they
> were bugs fixed in 3.4.x or 4.0.x). Two of them
On Sun, 15 May 2005, Richard Guenther wrote:
> What can be done about this issues? First, we can use VIEW_CONVERT_EXPR
> unconditionally in fold_indirect_ref and only break some optimizations
> (like temp1.C). Second, we can declare fold_indirect_ref being unsafe
> about types and deal with this
On Sun, 15 May 2005, Richard Guenther wrote:
> > Exactly which optimization do we miss by changing:
> >
> > /* *&p => p */
> > - if (lang_hooks.types_compatible_p (type, optype))
> > + if (type == optype)
> > return op;
>
> I don't know - maybe stripping sign casts. But if w
On Thu, 26 May 2005, Scott Robert Ladd wrote:
> I prefer breaking out the hardware intrinsics from
> -funsafe-math-optimizations, such that people can compile to use their
> hardware *without* the other transformations implicit in the current
> collective.
>
> If someone can explain how this hurts
On Sun, 29 May 2005, Steven Bosscher wrote:
> I don't understand what lines 2728 to 2741 are for. Could someone give
> an example of when we can have a then_bb that has no successors, but
> still ends in something that satisfies simplejump_p()? What kind of
> strange indirect jump would that be?
Hi Diego,
On Fri, 5 Aug 2005, 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 predicate.
>
On Sun, 21 Aug 2005, Leehod Baruch wrote:
> *** 329,334
> --- 328,341
> GET_MODE (SUBREG_REG (x)),
> SUBREG_BYTE (x));
> return op0 ? op0 : x;
> + }
> + if (code == SET)
> + {
> +
On Sun, 21 Aug 2005, Leehod Baruch wrote:
> >>(insn 1 0 2 0 (set (reg/v:Xmode r)
> >>(sign_extend:Xmode (op:Ymode (...
> >>(insn 2 1 3 0 (set (lhs) (rhs)))
>
> 1. Can you please give me an example of something bad that can happen to
> the LHS. Maybe I'm missing something here.
(set
On Mon, 22 Aug 2005, Dale Johannesen wrote:
> There is some clever code in convert_to_real that converts
>
> double d;
> (float)floor(d)
>
> to
>
> floorf((float)d)
> ...
>
> Comments? Should I preserve the buggy behavior with -ffast-math?
Good catch. This is indeed a -ffast-math (or more precis
On Thu, 1 Dec 2005, Richard Guenther wrote:
> It looks like it is safe to exchange both of them (the first one for sure)
> to fold_convert (...) due to the fact that fold_unary handles NOP_EXPR
> the same way than CONVERT_EXPR apart from cases that look like oversights,
> ...
> In fact, I remember
Hi Dan,
On Wed, 7 Dec 2005, Daniel Berlin wrote:
> This is *already* wrong, AFAICT, because reg:QI 58 is uninitialized, and
> we are trying to use it's value. Why do we do this?
This may have been a rhetorical question, but the middle-end's RTL
expanders are generating uses of uninitialized reg
One significant (philosophical) difference between the floating point
code generated by GCC vs that generated by commercial compilers for
IA-32, is the decision whether or not to hoist floating point constants
on the x87. Or phrased equivalently, whether to allocate an x87 stack
register to hold
Hi Diego,
On Thu, 12 Jan 2006, Diego Novillo wrote:
> In fold_binary() we are asserting:
>
> gcc_assert (IS_EXPR_CODE_CLASS (kind)
> && TREE_CODE_LENGTH (code) == 2
> && op0 != NULL_TREE
> && op1 != NULL_TREE);
...
> DEFTREECODE (OMP_SINGLE, "omp_single
. Many thanks to Dan
and H-P for investigating the problem on IRC.
Roger
--
Roger Sayle, E-mail: [EMAIL PROTECTED]
OpenEye Scientific Software, WWW: http://www.eyesopen.com/
Suite 1107, 3600 Cerrillos Road, Tel: (+1) 505-473-7385
Santa Fe, New Mexico, 87507. Fax: (+1) 505-473-0833
On Fri, 20 Jan 2006, Zdenek Dvorak wrote:
> I propose the following workaround instead, that also restores
> bootstrap. It changes the way loop-iv uses df to more conservative one,
> that does not seem to cause problems.
That's what I like to see... options. Yes, this is OK for mainline,
please
On Mon, 23 Jan 2006, Paolo Bonzini wrote:
> 2006-01-23 Paolo Bonzini <[EMAIL PROTECTED]>
>
> PR rtl-optimization/25890
> PR rtl-optimization/25905
> * combine.c (expand_compound_operation, expand_field_assignment):
> Fail if the bitfield's final position is out of bounds.
I've a IA-32 backend question on the intended behaviour of the functions
ix86_binary_operator_ok and ix86_fixup_binary_operands.
My confusion is that these functions currently allow arithmetic
operations of the form "reg = op(mem,immed)" even though this
shape isn't supported by x86 ISA. For exa
On Thu, 2 Mar 2006, Jeffrey A Law wrote:
> Is causing 961206-1.c to regress at -O1 and -O2 on i686-pc-linux-gnu
> and possibly other platforms.
Doh! This doesn't fail on x86_64-unknown-linux-gnu, where I developed
that patch, but I am now seeing those failures on i686-pc-linux-gnu.
> OUCH. Ins
On Mon, 27 Mar 2006, [UTF-8] Rafael Esp??ndola wrote:
> I have put toghether a hack to remove the convert callback. It consists in
> 1) adding a lang prefix to the implementations of convert (cxx_, c_,
>gfc_, etc)
> 2) defining a convert2 function that is basically a copy of c_convert
> 3) co
resumably everyone agrees that this evolution is a good thing.
The contention is whether everyone agrees that we're ready for
such a step. Is such a transition safe for stage 3 mainline,
and/or would front-ends prefer some time to double check that
this won't cause problems on conformance tests
On Sun, 2 Apr 2006, Eric Botcazou wrote:
> > 2006-04-01 Roger Sayle <[EMAIL PROTECTED]>
> >
> > * tree.c (integer_zerop): Ignore TREE_CONSTANT_OVERFLOW.
> > [...]
> > (int_size_in_bytes): Likewise.
> > (host_integerp): Likewise.
>
On Mon, 3 Apr 2006, Richard Guenther wrote:
> negate_expr_p currently contains
> ...
> where it looks bogus to simply return true for signed types but
> unset flag_trapv.
> ...
> which is bogus as it should read || (!flag_trapv && flag_wrapv) - no?
> I hit this with a patch to fold A +- CST to A -
On Mon, 3 Apr 2006, Richard Guenther wrote:
>
> || (TREE_CODE (type) == INTEGER_TYPE
>&& (TREE_CODE (arg1) == INTEGER_CST
>|| TYPE_UNSIGNED (type)
>|| (flag_wrapv && !flag_trapv)))
>
> Does this sound reasonable?
Yes, this sound
On Thu, 6 Apr 2006, Daniel Bratell wrote:
> that it would be safe to use that flag unless I relied on extreme
> precision or behaviour related to NaN or +-Inf, and that normal simple
> arithmetics should still give the same result.
Unfortunately, with -ffast-math simple arithemtics no longer have
I've a quick question regarding the policy for granting/sponsoring
CVS/subversion write access. There seems to have been a recent
change in thinking (or difference of opinions) on the pre-requisites
for allowing a new contributor modification rights to GCC's source
repository.
My understanding (
Hi Mark,
On Tue, 2 May 2006, Mark Mitchell wrote:
> Roger, I know that you reviewed the SEE patches. Is there anything
> more than needs to be done to get them committed, in your view?
As far as I'm aware, we're still just waiting for the Haifa folks to
commit them to mainline. There are a num
Hi Mircea,
On Fri, 5 May 2006, Mircea Namolaru wrote:
> > That certainly does suggest a bug in the SEE patches. They needn't do
> > anything useful on IA32/AMD64, but they should presumably either (a) not
> > cause a bootstrap failure on these architectures, or (b) be disabled on
> > these archi
Hi Mark and Richard,
On Fri, 19 May 2006, Mark Mitchell wrote:
> Roger, would you please revert your MIPS MIN_UNITS_PER_WORD change
> for MIPS on the GCC 4.1 branch?
>
> (My brain failed to digest the fact that the patch was on 4.1 as well as
> on mainline, perhaps in part because there doesn't s
Hi Richard,
On Fri, 19 May 2006, Richard Sandiford wrote:
> Mark Mitchell <[EMAIL PROTECTED]> writes:
> > (My brain failed to digest the fact that the patch was on 4.1 as well as
> > on mainline, perhaps in part because there doesn't seem to be a PR;
> > Richard indicated to me that he would loca
On Fri, 19 May 2006, Mark Mitchell wrote:
> > No, you can invoke it via using the attribute mode(TI)
> Sure, but I'm not worried about that case.
That would be the only class of C or C++ failures that I could easily
construct by hand. Although the RTL optimizers will introduce TImode
moves and t
On Fri, 19 May 2006, Mark Mitchell wrote:
> I'm evaluating the options. It would be helpful if someone has time to
> apply and test Richard's patch on 4.1, as that would let us know whether
> that option is viable as well.
I've bootstrapped and regression tested a backport of Richard's patch
aga
a real problem that I'm sorry I zoned on myself.
Fixed with the following patch. Committed to mainline as obvious as
revision 115076, after a full 3-stage bootstrap of the gcc/ directory
on x86_64-unknown-linux-gnu.
My apologies yet again for the breakage, and especially to Mark.
2
Hi Ian,
On Sun, 9 Jul 2006, Ian Blanes wrote:
> I've been recently looking at the splay tree implementation. I've noticed
> that this revision http://gcc.gnu.org/viewcvs?view=rev&revision=106584
> does a strange splaying. It does a bottom up splaying but starting at the
> root (not the same that
Hi Denis,
On Mon, 31 Jul 2006, Jim Wilson wrote:
> At the moment, there is probably no one who understands this code as
> well as you do, so you may not get much help from others.
In my defence, I'm struggling to get up to speed with all of the
issues. The first and obvious comments are that pa
t: 16 June 2023 13:51
> To: GCC Mailing List
> Cc: Roger Sayle
> Subject: Issue generating GCC coverage report since r14-1625-geba3565ce6d766
>
> Hello,
>
> we try to build coverage info for GCC for our testsuite and upload it to
> https://gcc.opensuse.org/gcc-lcov/
On Sat, 12 Feb 2005, Nathan Sidwell wrote:
> I question if it is better to fold early. As I've said before, I think
> the optimizations that fold performs should be turned into a proper SSA
> optimization phase% -- that can be repeatedly applied as necessary.
As for a proper tree-ssa optimizatio
On Tue, 15 Feb 2005, Andrew Haley wrote:
> There's one other thing to bear in mind when considering the way that
> fold relates to language front ends. We've seen problems in Java
> where fold() returned tree nodes that Java didn't recognize: one time,
> for example, it returned a BITFIELD_EXPR.
allow the potential non-loop
performance degradations to be addressed as follow-up patches and therefore
regression fixes suitable for stage 3?
Congratulations again to Michael for this impressive performance
improvement.
Roger
--
Roger Sayle, Ph.D.
OpenEye Scientific Software,
Suite #D, 9 Bisbee Court,
Santa Fe, New Mexico, 87508.
56 matches
Mail list logo
