> "Diego" == Diego Novillo <[EMAIL PROTECTED]> writes:
Diego> This patch bootstraps all default languages. I'll test Ada later on,
Diego> but I need input from all the FE folks.
I don't think this should hurt gcj. I don't think we test
TREE_ADDRESSABLE for anything important.
Rebuilding li
> > 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
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
> 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 poi
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 thi
> 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
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 f
> 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
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
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 oth
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
> =
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, wouldn't
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
(finish_l
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 build_addres
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
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
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
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 . The format of output is the sa
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 (Say
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): Incorrect constant generatio
21 matches
Mail list logo
