This is the mail archive of the gcc@gcc.gnu.org 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]
Other format: [Raw text]

Re: [PATCH] Fix __builtin_expect (setjmp (buf) == 0, 1)) generatesbroken code


Jakub Jelinek <jakub at redhat dot com> writes:

> The problem seems to be that unsafe_for_reeval returned 1 for baz () == 0
> and thus baz () == 0 was surrounded into UNSAVE_EXPR. But do_jump didn't
> handle UNSAVE_EXPR specially, so it did expand_expr on the UNSAVE_EXPR
> forcing baz () == 0 into a temporary and then did a conditional jummp based
> on that.

Ugh.

> Ok to commit if testing succeeds? What about 3.2/3.3 (with the obvious
> changes (expr.c instead of dojump.c in both and unsave_expr_now instead
> of (*lang_hooks.unsave_expr_now) on 3.2))?

This looks good to me for 3.3 and mainline, but wait 24 hours for
reactions from people who know more about tree->rtl expansion.  You'll
have to ask Gabriel about 3.2.

It would be good if you could figure out some way to write a test case
for this problem, it keeps coming up.  One approach that might work is
to have a file with a macro that expands either to
__builtin_expect(expr, val) or just to (expr).  Compile it twice to
assembly, once with the __builtin_expect and once without, with
-fno-reorder-blocks both times (so that the __builtin_expect is a
no-op at the RTL level, but chould still potentially have an effect at
the tree level).  Compare the results.

zw


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