In 1998 Jeff created this as a dump from an e-mail (hence all the
contents in a environment).
Since then we haven't really change any contents, though it's interesting
to review the commit log which reflects general changes around our web
site (to XHTML, later reducing preprocessing, now HTML 5
Committed.
The test makes sense only for targets that return the
"struct { int a, b, c; }" in registers (not in memory).
Starting a skip-construct is IMHO better than another iteration of
that obscuring "{ ... && { ! mytarget-*-* } }". New targets can just
append to the list without additional
Committed.
IV (loop2_unroll) doesn't like the mmix port. The feelings are mutual.
For mmix, gcc.dg/pr30957-1.c fails (runtime and rtl-scan) for these
reasons:
- IV doesn't handle the zero-extension-by-shift sequences generated by
middle-end (expr.c:convert_mode_scalar) in the absence of
zer
On 8/6/20 10:29 AM, Peter Bergner wrote:
> On 8/5/20 6:06 PM, Segher Boessenkool wrote:
> Ok, updated patch pushed to trunk. I'll push to GCC10 after a day or two.
And now pushed to GCC 10.
Peter
On 8/7/20 8:59 PM, Peter Bergner wrote:
> On 8/7/20 6:52 PM, Segher Boessenkool wrote:
>> Okay for trunk if that is true (or with the necessary adjustments), and
>> okay for 10 after letting it soak for a bit. Thanks!
>
> Ok, I did s/element_mode/TYPE_MODE/g here and am retesting.
> I'll commit i
Hi!
The following valid testcase is rejected, because cxx_eval_binary_expression
is called on the SPACESHIP_EXPR with lval = true, as the address of the
spaceship needs to be passed to a method call.
After recursing on the operands and calling genericize_spaceship which turns
it into a TARGET_EXPR
Hi!
On Mon, Aug 03, 2020 at 07:44:12PM +0200, Jakub Jelinek via Gcc-patches wrote:
> Can you try that? Or do you want me to try?
If the walk_body on the various sequences of reduction, lastprivate and/or
linear
clauses needs to create a temporary variable, we should declare that variable
in tha
Hi!
The following testcase ICEs with -fexceptions -fnon-call-exceptions because
in that mode floating point comparisons should not be done at the end of bb
in GIMPLE_COND. Fixed by forcing it into a bool SSA_NAME and comparing that
against
false.
Bootstrapped/regtested on x86_64-linux and i686-
Hi Kewen,
Sorry for the late reply.
The patch's most important change is below cost computation:
> @@ -5890,6 +5973,10 @@ determine_iv_cost (struct ivopts_data *data, struct
> iv_cand *cand)
> cost_step = add_cost (data->speed, TYPE_MODE (TREE_TYPE (base)));
> cost = cost_step + adjust_setu
