Mark Mitchell wrote on 03/22/07 22:10:
PR 29585 (Novillo): ICE-on-valid
This one seems to be a bug in the C++ FE, compounded by alias analysis
papering over the issue. We are failing to mark DECLs in vtbl
initializers as addressable. This causes the failure during aliasing
because it is added
Diego Novillo wrote:
I traced the problem back to the building of vtables. I'm simply
calling cxx_mark_addressable after building the ADDR_EXPR (I'm wondering
if building ADDR_EXPR shouldn't just call langhooks.mark_addressable).
Looks fine to me. Many places in the front end use
Jason Merrill wrote on 03/30/07 11:45:
Looks fine to me. Many places in the front end use build_address rather
than build1 (ADDR_EXPR) to avoid this issue.
Yeah, I found other cases in Java and in c-*.c. In one case, we are
building the address of a LABEL_DECL for a computed goto
Diego Novillo wrote:
Interestingly enough, mark_addressable refuses to mark the label as
addressable, but we need the label addressable so that it's processed
properly by the compute_may_aliases machinery.
Given that we need to be very consistent about addressability marking in
the FEs,
Diego Novillo wrote:
This one seems to be a bug in the C++ FE, compounded by alias analysis
papering over the issue.
Doh! Thank you for tracking this down.
Mark, does this look OK? (not tested yet)
Index: cp/class.c
===
Mark Mitchell wrote on 03/30/07 12:22:
So, I think the right fix is (a) the change above, (b) remove the
TREE_ADDRESSABLE setting from mark_vtable_entries (possibly replacing it
with an assert.)
After removing the papering over TREE_ADDRESSABLE we were doing in the
aliaser, I found that other
Diego Novillo wrote on 03/30/07 13:21:
This patch bootstraps all default languages. I'll test Ada later on,
but I need input from all the FE folks.
Sigh. I forgot to include Mark's suggestion in the patch. With this
patch, calling build_address in dfs_accumulate_vtbl_inits is not
strictly
One thing that I'm wondering about this patch is why hasn't this been
done before? We seem to purposely separate TREE_ADDRESSABLE from
ADDR_EXPR. Perhaps to prevent pessimistic assumptions? The current
aliasing code removes addressability when it can prove otherwise.
One concern I have in
Richard Kenner wrote on 03/30/07 13:45:
One concern I have in marking a DECL addressable that early on is that
it may stay stuck even if the ADDR_EXPR is later eliminated. This can
be common in inlined situations, I thought.
The aliaser is fairly aggressive at removing TREE_ADDRESSABLE from
The aliaser is fairly aggressive at removing TREE_ADDRESSABLE from
variables that do not need it anymore, so that should not be a problem.
Yes, but you're calling the lang hook, which in theory, is allowed
to do all sorts of different things. How do those get undone when we find
*they* aren't
On 3/30/07, Richard Kenner [EMAIL PROTECTED] wrote:
The aliaser is fairly aggressive at removing TREE_ADDRESSABLE from
variables that do not need it anymore, so that should not be a problem.
Yes, but you're calling the lang hook, which in theory, is allowed
to do all sorts of different
The lang hook is supposed to mark the variable as addressable.
The lang hook should not be changing other things that have an affect
on the *middle end*. No exceptions.
But how is it supposed to mark the variable as addressable? If this
just means setting TREE_ADDRESSABLE, what's the point
On 3/30/07, Richard Kenner [EMAIL PROTECTED] wrote:
The lang hook is supposed to mark the variable as addressable.
The lang hook should not be changing other things that have an affect
on the *middle end*. No exceptions.
But how is it supposed to mark the variable as addressable? If this
But how is it supposed to mark the variable as addressable? If this
just means setting TREE_ADDRESSABLE, what's the point of having the hook?
It also issues language specific warnings
Then one suggestion is that we rename the langhook to warn_addressable and
set TREE_ADDRESSABLE
Mark Mitchell wrote on 03/22/07 22:10:
Diego, Roger, Jason, would you please let me know if you can work on the
issues above? I'm going to try to test Jim's patch for PR 31273 tonight.
I'm looking at 29585 today.
Joseph S. Myers wrote:
On Thu, 22 Mar 2007, Mark Mitchell wrote:
Joseph, would you please take a look at PR 31136? Andrew believes this
to be a front-end bug.
I don't think this is a front-end bug.
Thank you for investigating.
(OK to commit this patch to mainline
subject to the usual
On 3/23/07, Mark Mitchell [EMAIL PROTECTED] wrote:
Mark Mitchell wrote:
There are still a number of GCC 4.2.0 P1s, including the following which
are new in GCC 4.2.0 (i.e., did not occur in GCC 4.1.x), together with
-- as near as I can tell, based on Bugzilla -- the responsibility parties.
Mark Mitchell wrote:
There are still a number of GCC 4.2.0 P1s, including the following which
are new in GCC 4.2.0 (i.e., did not occur in GCC 4.1.x), together with
-- as near as I can tell, based on Bugzilla -- the responsibility parties.
PR 29585 (Novillo): ICE-on-valid
PR 30700 (Sayle):
On Thu, 22 Mar 2007, Mark Mitchell wrote:
Joseph, would you please take a look at PR 31136? Andrew believes this
to be a front-end bug.
I don't think this is a front-end bug.
I applied the patch below to make the dumps give more meaningful
information than unnamed type. The format of
19 matches
Mail list logo
