public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
* [tree-ssa] -fdisable-gimple
@ 2003-10-03 13:21 Jeff Sturm
  2003-10-03 14:23 ` Daniel Berlin
                   ` (2 more replies)
  0 siblings, 3 replies; 6+ messages in thread
From: Jeff Sturm @ 2003-10-03 13:21 UTC (permalink / raw)
  To: rth, dnovillo; +Cc: gcc

How important is it that the branch continue to support -fdisable-gimple?
For C or all frontends?

I see that Java has been completely broken with -fdisable-gimple for some
time.  The flag gets no routine testing, making it worse than useless IMO.

More urgently, I don't think we can do tree_rest_of_compilation in any
sane fashion without resorting to

void
java_expand_body (tree fndecl)
{
  if (! flag_disable_gimple)
    tree_rest_of_compilation (fndecl);
  else
    {
      /* ... preserve all old cruft here ... */
    }
}

Jeff

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [tree-ssa] -fdisable-gimple
  2003-10-03 13:21 [tree-ssa] -fdisable-gimple Jeff Sturm
@ 2003-10-03 14:23 ` Daniel Berlin
  2003-10-03 16:27   ` Jeff Sturm
  2003-10-03 15:04 ` Steven Bosscher
  2003-10-03 17:02 ` Diego Novillo
  2 siblings, 1 reply; 6+ messages in thread
From: Daniel Berlin @ 2003-10-03 14:23 UTC (permalink / raw)
  To: Jeff Sturm; +Cc: rth, dnovillo, gcc



On Fri, 3 Oct 2003, Jeff Sturm wrote:

> How important is it that the branch continue to support -fdisable-gimple?
> For C or all frontends?

I believe it's only actual use is by the SPEC tester to have something to
use as the baseline.

>
> I see that Java has been completely broken with -fdisable-gimple for some
> time.  The flag gets no routine testing, making it worse than useless IMO.

Actually, the SPEC tester uses it every night, right Diego?


>
> More urgently, I don't think we can do tree_rest_of_compilation in any
> sane fashion without resorting to
>
> void
> java_expand_body (tree fndecl)
> {
>   if (! flag_disable_gimple)
>     tree_rest_of_compilation (fndecl);
>   else
>     {
>       /* ... preserve all old cruft here ... */
>     }
> }
>
> Jeff
>
>

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [tree-ssa] -fdisable-gimple
  2003-10-03 13:21 [tree-ssa] -fdisable-gimple Jeff Sturm
  2003-10-03 14:23 ` Daniel Berlin
@ 2003-10-03 15:04 ` Steven Bosscher
  2003-10-03 17:11   ` Gerald Pfeifer
  2003-10-03 17:02 ` Diego Novillo
  2 siblings, 1 reply; 6+ messages in thread
From: Steven Bosscher @ 2003-10-03 15:04 UTC (permalink / raw)
  To: Jeff Sturm; +Cc: rth, dnovillo, gcc

Op vr 03-10-2003, om 15:21 schreef Jeff Sturm:
> How important is it that the branch continue to support -fdisable-gimple?
> For C or all frontends?

There already are C and C++ programs that do not compile with
-fdisable-gimple (such as the test case for PR8361), and nobody has
complained so apparently it's not all that important.

Gr.
Steven

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [tree-ssa] -fdisable-gimple
  2003-10-03 14:23 ` Daniel Berlin
@ 2003-10-03 16:27   ` Jeff Sturm
  0 siblings, 0 replies; 6+ messages in thread
From: Jeff Sturm @ 2003-10-03 16:27 UTC (permalink / raw)
  To: Daniel Berlin; +Cc: rth, dnovillo, gcc

On Fri, 3 Oct 2003, Daniel Berlin wrote:
> On Fri, 3 Oct 2003, Jeff Sturm wrote:
> > I see that Java has been completely broken with -fdisable-gimple for some
> > time.  The flag gets no routine testing, making it worse than useless IMO.
>
> Actually, the SPEC tester uses it every night, right Diego?

It might.  SPEC doesn't touch Java.

So I can try to make it work again, leave it broken or just kill
-fdisable-gimple in Java.  What do tree-ssa folks prefer?

Jeff

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [tree-ssa] -fdisable-gimple
  2003-10-03 13:21 [tree-ssa] -fdisable-gimple Jeff Sturm
  2003-10-03 14:23 ` Daniel Berlin
  2003-10-03 15:04 ` Steven Bosscher
@ 2003-10-03 17:02 ` Diego Novillo
  2 siblings, 0 replies; 6+ messages in thread
From: Diego Novillo @ 2003-10-03 17:02 UTC (permalink / raw)
  To: Jeff Sturm; +Cc: Richard Henderson, gcc

On Fri, 2003-10-03 at 09:21, Jeff Sturm wrote:
> How important is it that the branch continue to support -fdisable-gimple?
> For C or all frontends?
> 
It's not.  At first it was a way of debugging the gimplifier, then it
became a quick and dirty way of comparing tree-ssa against
something-resembling-mainline when running SPEC.  I never modified the
SPEC scripts to do comparison runs between different compilers.  I
should.

Unless any FE folk have a use for it, I'd say we should discard the
flag.


Diego.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [tree-ssa] -fdisable-gimple
  2003-10-03 15:04 ` Steven Bosscher
@ 2003-10-03 17:11   ` Gerald Pfeifer
  0 siblings, 0 replies; 6+ messages in thread
From: Gerald Pfeifer @ 2003-10-03 17:11 UTC (permalink / raw)
  To: Steven Bosscher; +Cc: Jeff Sturm, rth, Diego Novillo, gcc

On Fri, 3 Oct 2003, Steven Bosscher wrote:
>> How important is it that the branch continue to support -fdisable-gimple?
> There already are C and C++ programs that do not compile with
> -fdisable-gimple (such as the test case for PR8361), and nobody has
> complained so apparently it's not all that important.

Well, it's interesting in that the test case for PR8361 fails both
with -fdisable-gimple and without -- and with two different failure
modes! :-(

It would be really, really good could someone finally debug this and
fix tree-ssa.

Gerald

PS: I'm even willing to take a bet that fixing this bug will help
uncover further tree-ssa bugs triggered by my code.

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2003-10-03 17:11 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-10-03 13:21 [tree-ssa] -fdisable-gimple Jeff Sturm
2003-10-03 14:23 ` Daniel Berlin
2003-10-03 16:27   ` Jeff Sturm
2003-10-03 15:04 ` Steven Bosscher
2003-10-03 17:11   ` Gerald Pfeifer
2003-10-03 17:02 ` Diego Novillo

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).