Do we ever pass ERROR_MARK to expanders?

Do we ever pass ERROR_MARK to expanders?

[Kazu Hirata]

Hi,

A lot of expanders seem to check for ERROR_MARK.  For example,
expand_assignment does so like this

  if (TREE_CODE (to) == ERROR_MARK)
    {
      result = expand_expr (from, NULL_RTX, VOIDmode, 0);
      return want_value ? result : NULL_RTX;
    }

Now, do we ever pass ERROR_MARK to expanders these days?  If not, we
should do something like gcc_assert (TREE_CODE (to) != ERROR_MARK);.

Kazu Hirata

Re: Do we ever pass ERROR_MARK to expanders?

[Steven Bosscher]

On Sunday 17 October 2004 17:32, Kazu Hirata wrote:
> Now, do we ever pass ERROR_MARK to expanders these days?  If not, we
> should do something like gcc_assert (TREE_CODE (to) != ERROR_MARK);.

I think we do.  We only don't do optimizations if errorcount or
sorrycount is non-zero, but we do call rest_of_compilation on
functions even after errors.  I don't know *why* we would want to
expand any trees after errors, though...

Gr.
Steven

Re: Do we ever pass ERROR_MARK to expanders?

[Jan Hubicka]

> On Sunday 17 October 2004 17:32, Kazu Hirata wrote:
> > Now, do we ever pass ERROR_MARK to expanders these days?  If not, we
> > should do something like gcc_assert (TREE_CODE (to) != ERROR_MARK);.
> 
> I think we do.  We only don't do optimizations if errorcount or
> sorrycount is non-zero, but we do call rest_of_compilation on
> functions even after errors.  I don't know *why* we would want to
> expand any trees after errors, though...

The main rationaly has always been to get as many warnings as possible.
Perhaps we can weaken this now especialy on tree-profiling branch where
we will throw into tree optimizers everything we would do if we were
producing assembly and thus get all tree level warnings (and I would not
very trust the RTL level warnings to come out sane anyway)

Honza
> 
> Gr.
> Steven

Re: Do we ever pass ERROR_MARK to expanders?

[Kazu Hirata]

Hi Honza,

> > > Now, do we ever pass ERROR_MARK to expanders these days?  If not, we
> > > should do something like gcc_assert (TREE_CODE (to) != ERROR_MARK);.
> > 
> > I think we do.  We only don't do optimizations if errorcount or
> > sorrycount is non-zero, but we do call rest_of_compilation on
> > functions even after errors.  I don't know *why* we would want to
> > expand any trees after errors, though...
> 
> The main rationaly has always been to get as many warnings as possible.
> Perhaps we can weaken this now especialy on tree-profiling branch where
> we will throw into tree optimizers everything we would do if we were
> producing assembly and thus get all tree level warnings (and I would not
> very trust the RTL level warnings to come out sane anyway)

OK.  Then we may be able to stop expanding trees in presence of errors
as early as 4.1.

Kazu Hirata

Re: Do we ever pass ERROR_MARK to expanders?

[Mark Mitchell]

Jan Hubicka wrote:

>>On Sunday 17 October 2004 17:32, Kazu Hirata wrote:
>>    
>>
>>>Now, do we ever pass ERROR_MARK to expanders these days?  If not, we
>>>should do something like gcc_assert (TREE_CODE (to) != ERROR_MARK);.
>>>      
>>>
>>I think we do.  We only don't do optimizations if errorcount or
>>sorrycount is non-zero, but we do call rest_of_compilation on
>>functions even after errors.  I don't know *why* we would want to
>>expand any trees after errors, though...
>>    
>>
>
>The main rationaly has always been to get as many warnings as possible.
>
Which is because of the design bug wherein the optimizers issue 
diagnostics. :-)

-- 
Mark Mitchell
CodeSourcery, LLC
(916) 791-8304
mark@codesourcery.com