RFC: Monitoring old PRs, new dg directives

Marek Polacek polacek@redhat.com
Thu Aug 6 12:27:05 GMT 2020


On Wed, Aug 05, 2020 at 01:01:32PM -0700, Mike Stump wrote:
> On Aug 4, 2020, at 5:54 PM, Marek Polacek <polacek@redhat.com> wrote:
> >> As you find it difficult to express a test using the existing mechanisms, let's talk about those and see if anyone has a good idea on how to express it.  I think ICEs are the most annoying to manage, but, I think excess and prune should be able to handle them.  I think should get an error or warning, or should not get an error or warning are more trivial to manage.
> > 
> > I experimented with
> > // { dg-prune-output ".*internal compiler error.*" }
> > // { dg-xfail-if "" { *-*-* } }
> > but it's a mouthful and the results were poor (when the ICE is fixed but we
> > generate errors instead).  dg-ice is convenient, handles even the different
> > kind of ICE (when the diagnostic routines were re-entered), and generates
> > nice XPASSes when the ICE goes away.
> > 
> > I've also played games with dg-regexp but it was too ugly.
> > 
> > (I honestly don't see why new directives are such a big deal, if they're
> > properly documented.)
> 
> I don't see a bogus here?  I think that can't be skipped.

A dg-bogus?  Where?  Putting it on the line where the ICE happens results in
FAILs.  A complete example of what I had in mind:

// PR c++/88003
// { dg-do compile { target c++14 } }
// { dg-prune-output ".*internal compiler error.*" }
// { dg-xfail-if "" { *-*-* } }

auto test() {
  struct O {
    struct N;
  };
  return O();
}

typedef decltype(test()) TN;
struct TN::N {};


I think I'd still prefer a single dg-ice.

Marek



More information about the Gcc-patches mailing list