On Wed, Aug 05, 2020 at 01:01:32PM -0700, Mike Stump wrote:
> On Aug 4, 2020, at 5:54 PM, Marek Polacek <pola...@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
