This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Small update to reversed_comparison_code

Rob, Nick, Richard, Mark and Jeffrey,

I've just sent patch to the list that handles part of the problem.  Real
problem is, that ifcvt is completely unaware of the danger of reversing fp
comparisons in the integer way.  My patch made that code trigger in bootstrap,
but if you construct any conditional execution block using c9x unordered
comparisons builtins, you get exactly the same problem resulting in crash
of compiler handling UNKNOWN compares.

I've fixed this by using reversed_comparison_code infrastructure, but it
triggers another problem in flow.c, that follows same assumption of integerness
of all comparisons and crashes on constructing UNKNOWN compare.  This seems to
be nontrivial to solve, since reversing is handled by
REVERSE_CONDEXEC_PREDICATES_P, that gets just code, so it can't decide about
safety of reversal - perhaps we should make it to get whole comparison and
make flow.c ready for not being able to reverse the codes, but I don't 100%
understand the algorithm, so I don't think I can do that myself.

Mark, Nick, Richard:
Moreover converisons are incorect for the ordered compares too.
Fixing the problem seems to be quite nontrivial, so I would like to ask you
how to proceed in release branch. I would like to disable conditional move
generation for floating point in release branch.  Is that possible to do
easilly? Perhaps using IFCVT_MODIFY_TESTS hack?

Mark, Jeffrey:
I must say I feel quite unconformatble about reversing the patch.  Sure, if
patch itself is broken, it is good to reverse it, but this patch isn't and
just makes other bugs to show up (those bugs triggers in normal tree usually
by using unordered builtins too).
I've waited after 3.0 branching with that patch, since I was aware of possible
problems (I didn't exepcted them tought) and I believe keeping it in the tree
will just make 3.0 branch more stable, since we will fix such crashes earlier.
Also it brings important optimizations - for example we never generated
conditional moves based on fp comparisons before without -ffast-math.
Also I don't think I was unresponsible about fixing the problems - the arm
took me 2 days, mips 3.

So I would suggest concentrating on the real problem and re-installing the
patch to the tree soon.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]