Hi Richard,
BTW, I would expect this to also exist in all the release branches. Could you
back-port it where
needed please.
I just backported to 4.4, 4.5, and 4.6 branches.
Kazu Hirata
/mayalias-2.c compilation, -O3 -g (internal
compiler error)
That is, I am getting an unintended XPASS for
-O3 fomit-frame-pointer. Also, the -O3 -g one doesn't show XFAIL
even though the options do contain -O3.
How do I make gcc.c-torture/execute/mayalias-2.c XFAIL on -O3 -g?
Thanks,
Kazu
urgent is this? FWIW, I've reproduced
the ICE that Zack mentioned, but I haven't investigated it.
Kazu Hirata
to fix this in future.)
So, Sandra's CALL_EXPEs stuff may be ready for merge, but my TYPE_ARG_TYPE stuff
has a somewhat long way to go.
Thanks,
Kazu Hirata
.
Even more confusing is:
arg = TREE_VALUE (args);
:
:
if (!TYPE_P (arg))
Can a function argument be a type?
Clarification would be greatly apprecaited.
Thanks,
Kazu Hirata
this bit elsewhere.
The TREE_VEC node doesn't really have space for per-parameter data
other than the vector proper. I could use TREE_TYPE of TREE_VEC to
keep an array of boolean values to represent ARG_FINAL_P for each
parameter, but I am not sure if that is a clean solution.
Thoughts?
Kazu Hirata
is actually
no longer used. It hasn't been deleted yet but it won't ever run.
I'm hoping to merge this to trunk after 4.2 branches ... will that
help?
Yes, that definitely helps.
Thanks,
Kazu Hirata
to regroup after ECJ goes in.
OK.
Kazu Hirata
(...)) is NULL. I'll keep putting gcc_assert to see what happens.
Kazu Hirata
in standard_conversion meant to be an optimization or
something that's required for language conformance? If the latter is
the case, can we somehow force a conversion?
Thanks,
Kazu Hirata
there be two consecutive insns that use cc0 after cc0 is set? (I
don't think so. I think there should be one-to-one correspondence
between cc0 setters and cc0 users, but I've never seen a rule written
somewhere.)
Thanks,
Kazu Hirata
remove
the line or convert it to VEC somehow.
Thanks,
Kazu Hirata
Hi Daniel and Diego,
Several months ago, you mentioned that the alias analysis in gcc would
be overhauled. Has this happened yet? If not, I am thinking about
working on alias.c and tree-ssa-alias.c as there are only a handful of
VARRAY uses left.
Thanks,
Kazu Hirata
from VARRAY to VEC
will probably not affect my work, so go ahead. I guess that's what you
have in mind? Switching VARRAY to VEC?
Yes, thanks!
Kazu Hirata
, but that means we are changing the test case. Shall
we add something like gcc.dg/vect/fwrapv-vect-11.c, remove vect-11.c,
and file a missed optimization PR for vect-11.c?
Any thoughts?
Kazu Hirata
you don't see the failure there.
Oops, I now see what's going on. In this case, I think we can just XFAIL
gcc.dg/tree-ssa/gen-vect-11.c.
Kazu Hirata
/gcc-svn/trunk/gcc/df-core.c:833: error: invalid lvalue in assignment
I just fixed these.
Kazu Hirata
this
might have gone unnoticed.
Kazu Hirata
change within one
run of cc1.)
FWIW, the second define_insn above could have plus in
operands[1], in which case it overlaps with other insns with plus.
Thanks in advance,
Kazu Hirata
yet (assuming targets like h8300-elf,
arm-none-eabi, etc).
Is there anyway we could stop configuring libssp in this kind of case?
Or somehow work around the link test? FWIW, I am sitting on the
attached patch to disable libssp for now.
Kazu Hirata
Index: configure.in
are are implicitly
represented by the CFG. I don't think the if-conv is trying to handle
computed gotos here.
By the way, this problem has been filed as PR 18472.
Kazu Hirata
Hi Devang,
Just remove handling of GOTO_EXPR here and in if_convertible_stmt_p().
OK. Will submit a patch.
Kazu Hirata
. It turned out to be a regression from 3.x.
Kazu Hirata
during processing of an array's
initializer -- very early on in the C++ FE.
Do you know how to trigger a RANGE_EXPR? I see that in
build_zero_init, so I tried a big array with only zeros in it, but
that didn't help.
Kazu Hirata
created an array with more than one thousand elements. I still did
not see a RANGE_EXPR in the array's CONSTRUCTOR. How do I get a
RANGE_EXPR in a CONSTRUCTOR?
Kazu Hirata
with a low hanging fruit.
Kazu Hirata
also want to use
VEC_iterate.
Note that the second case above speeds up GCC by 0.5% or so.
Kazu Hirata
are
using stmt_ann while a statement is not linked to a basic block.
Kazu Hirata
from applications (or optimizers if
you like) of the infrastructure.
If this standalone stmt_ann does end up in the instruction stream, we
could structure-copy stmt_ann for the time being (yuck!).
Kazu Hirata
). Then the actual work of embedding
stmt_ann into tree_statement_list_node shouldn't be difficult.
Kazu Hirata
. Meanwhile I'll sit here quietly, collecting information like
which places do weird things with stmt_ann and thinking about how to
go about the transition.
Kazu Hirata
you stmt_ann
given bsi.
3. Let everybody use stmt_ann_from_bsi(), replace stmt_ann(), and
remove the stmt_ann_t pointer from the stmt node (if these are
possible at all).
4. Hand off to Zdenek for his flat statement project.
I hope this message clarifies things.
Kazu Hirata
that an annotation node can identify itself? (Since all these tree
annotations already have a field for annotation type, it's more like
appending tree_statement_list_node to stmt_ann_d.)
Kazu Hirata
. */
}
Err, I don't see how to tell the garbage collector about this without
a type field. We cannot rely on TREE_CODE (stmt) because CALL_EXPR
may appear by itself or as an rhs of MODIFY_EXPR.
Kazu Hirata
structure.
o We can probably remove get_stmt_ann and replace all uses of
stmt_ann. No more lazy stmt_ann allocation.
Thoughts?
Kazu Hirata
to this ICE. set_value_range is
used in many places in tree-vrp.c. I'll try to take a look at these
in the next few days.
Kazu Hirata
Hi Nathan,
Now that you've checked in your new VEC API, I think that's strictly
more powerful than VARRAY. Should we start converting uses of VARRAY
to VEC? I'd be happy to help out here.
Kazu Hirata
of the patch?
Is there more work or refinement needed?
Kazu Hirata
off.
sparc
Eric Botcazou says he is working on predicates.md himself.
http://gcc.gnu.org/ml/gcc-patches/2005-03/msg01694.html
Kazu Hirata
for 4.1 (if every port builds at least).
Mark, it's still April 5, so we could wait for a week and add a couple
of lines to config.gcc in time for 4.0, but if you think this is too
pushy or could distract the 4.0 effort, I am happy to postpone this
until 4.0.1 or 4.1.
Kazu Hirata
, and D.18001_198 itself
may also be used later.
Kazu Hirata
of these days.
Kazu Hirata
version?
Yes, they are blocked by may_propagate_copy. Seems to be const
v.s. non-const pointer issue. I haven't come up with a brakedown of
reasons why copies are blocked.
Kazu Hirata
is to process the CFG
worklist in the DFS order of a dominator tree. I haven't looked
closely at this, but if the speed of propagation is a concern, we
should come back to this.
Kazu Hirata
it
during inlining?
Kazu Hirata
/gcc-patches/2005-03/msg02038.html
Roger Sayle requested to keep the call to get_callee_fndecl so that we
can fold the first operand of a CALL_EXPR to a FUNCTION_DECL.
FYI, the above FIXME comes from
http://gcc.gnu.org/ml/java-patches/2004-q2/msg00083.html
Kazu Hirata
replace h8300 with any port with PREDICATE_CODES. My scripts are not
robust, so don't blame me if they eat your files.
I might actually start posting patches to convert to predicate.md.
Kazu Hirata
conv_predicate_codes.tar.gz
Description: Binary data
to revert any of parts 1 through 15.
On the other hand, after applying parts 16 and 17, it's trivial to
make fold_build[12] available although fold_build3 will take some
time, and it would be a bit awkward to provide fold_build[12] but not
fold_build3.
Thoughts?
Kazu Hirata
of the handling of CALL_EXPR in
fold_ternary. Since ternary expressions are not as common as binary
expressions, I don't except much difference even after we start using
fold_build3.
Kazu Hirata
is what I would do would be fine,
too.
Kazu Hirata
diff -u fold-const.c fold-const.c
--- fold-const.c6 Mar 2005 00:44:01 -
+++ fold-const.c6 Mar 2005 00:45:38 -
@@ -6802,6 +6802,7 @@
{
/* Don't leave an assignment inside a conversion
unless
Hi,
I might need help on others. I'll try to go through these KAZU one
by one, but if you could volunteer to fix one, you are more than
welcome. Suggestions like Here is what I would do would be fine,
too.
Roger kindly suggested what to do for each of these on IRC.
Kazu Hirata
that
argument to the last argument of legitimate_address_p.
Kazu Hirata
have already started
doing this like so:
#ifdef REG_OK_STRICT
#define REG_OK_STRICT_P 1
#else
#define REG_OK_STRICT_P 0
#endif
Kazu Hirata
, a good optimizer should be
able to eliminate most of these bit sets, but a non-pure/const
function call will block the cleanup opportunities. Of course, this
bitmap walk is far more expensive than cse_reg_info_timestamp++.
Kazu Hirata
cse_reg_info_timestamp++.
I just tried this. It comes very close to the current timestamp
approach but loses by 0.3% or so in compile time. I'm attaching a
patch for completeness.
Kazu Hirata
Index: cse.c
===
RCS file: /cvs/gcc/gcc/gcc
55 matches
Mail list logo
