I notice that most issues labelled “confirmed” are about clang’s frontend or codegen, but the issues about crash, miscompilation and missed-optimization in middleend and backend are seldomly labelled “confirmed”.
AFAIK, GCC always confirm the bugs or mark them as invalid/duplicated, but llvm seems that not always do that except for clang, sometimes the issues are labelled about their types. I’m wondering why confirmed label isn’t used for them.
I think it’s at least partially because we don’t really have a strict policy wrt confirming issues or anything like that—at least not as far as I know. Also, this may just be me, but when I ‘confirm’ an issue, if you will (which as I usually work on Clang often just means opening a godbolt link and checking that they’ve selected Clang trunk w/ assertions), I tend to just add e.g. ‘crash-on-valid’ instead, which at least for me already implies ‘confirmed’. I’d imagine the same might be true for e.g. ‘missed optimisation’.
One more thing: maybe that’s also just me, but if the issue was opened by another maintainer, then I typically trust that they’ve actually confirmed that this issue really exists.
I don’t really see the value in the “confirmed” label. There is no action I would condition on the presence or absence of such a label.
The only real use I see for it is so someone can put “I filed N confirmed LLVM issues” in their research paper 
Thanks for the explanation! I see, it sounds like that we focus more on what the issue is about indeed, instead of whether it is a problem.
I understand that. For developers, we just see the issue and then try to figure out why a problem arises and how to solve it.
For reporters researching about testing methods like fuzzing in need of feedback, that would be another story 
.
Every LLVM project might handle issues differently.
On the clang side, we mostly use “confirmed” to signal that there is indeed a bug and not an issue that misunderstood how C++ is supposed to work (as that can be confusing and often require digging in standard wording).
We also validate the issue is reproducing on latest trunk.