RFC: Front-end cleanups

[Tobias Schlüter]

Hi,

François-Xavier Coudert wrote:
>>>       All other unary operators have an equivalent GIMPLE unary operator.  */
>>>    if (code == TRUTH_NOT_EXPR)
>>>      se->expr = build2 (EQ_EXPR, type, operand.expr,
>>> -                    build_int_cst (type, 0));
>>> +                    build_int_cst (TREE_TYPE (operand.expr), 0));
>>>    else
>>>      se->expr = build1 (code, type, operand.expr);
>>>
>> (This hunk is unrelated to your other clenaups.)> Unless I'm mistaken,
>> TREE_TYPE (operand.expr) == type here, as the necessary conversions
>> should have been added during resolution.
> 
> Yes, that one is a temporary workaround that I have for PR33626
> (failure to get the correct kind for parenthesized expression). I
> think there are still a few shortcomings of the parentheses handling
> in the front-end, maybe more than we are currently aware (see last
> testcase of comment #20 in PR31608;
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31608#c20)

Since the misguided (in so far, as it was used for call-by-value 
semantics, where it was coded for maintaining correct evaluation order) 
original patch for INTRINSIC_PARENTHESES was my work, I'm looking into 
this.  Unfortunately, when I tried to build an up-to-date compiler it 
ended up in an infinite loop, so I'll have to find a solutions for these 
issues first :(

>> This has nothing to do with your cleanups, but I think that change is
>> wrong.  It's not an error the user made, but a shortcoming of the compiler.
> 
> I beg to differ. I think the compiler has a right to impose any limit
> it sees fit on the size of arrays, and this is what we do here. It
> would certainly improve the quality of our compiler to get rid of this
> limit, but I don't think it's a non-conforming behaviour.

You're right, the problem I was concerned about was that changing from 
an internal_error to a normal error message makes it look like the user 
is doing something inherently wrong, which he isn't.  I agree with the 
change, provided you make clear from the error message that the problem 
lies on the side of the compiler (say, by prefixing the message with 
"Implementation Limit" and indicating by how much the limit is exceeded 
for lack of a better idea.  Do as you please: it's not terribly 
important, and I'm worried that I'm in the process of selecting a paint 
for a bikeshed.)

Cheers,
- Tobi