This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] Fix ACATS failures in GCC 3.4
- From: Eric Botcazou <ebotcazou at act-europe dot fr>
- To: kenner at vlsi1 dot ultra dot nyu dot edu (Richard Kenner)
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Thu, 26 Feb 2004 11:19:54 +0100
- Subject: Re: [PATCH] Fix ACATS failures in GCC 3.4
- References: <10402252229.AA23178@vlsi1.ultra.nyu.edu>
> But the question is what is the type of the MAX_EXPR? Did it change
No, it didn't. Its type is still 'long int'.
> Is it the same type as both of its operands in both cases?
No, it is not in the second case. Would this matter since the casts are
(wrongly) considered NOPs for MAX_EXPR?
> Maybe the real problem comes from the RTL expander for MAX_EXPR. I'll
> investigate this.
> I don't think so.
Well, there seems to be a little inconsistency in the expander. Here is the
/* First try to do it with a special MIN or MAX instruction.
If that does not win, use a conditional jump to select the proper
this_optab = (TREE_UNSIGNED (type)
? (code == MIN_EXPR ? umin_optab : umax_optab)
: (code == MIN_EXPR ? smin_optab : smax_optab));
temp = expand_binop (mode, this_optab, op0, op1, target, unsignedp,
and the second flavor (which is used in our present case):
int unsignedp = TREE_UNSIGNED (TREE_TYPE (TREE_OPERAND (exp, 1)));
do_compare_rtx_and_jump (target, op1, code == MAX_EXPR ? GE : LE,
unsignedp, mode, NULL_RTX, NULL_RTX,
Note how the signedness is not taken from the same source.