[vtk-developers] Various issues on my dashboards... help needed...

Fri Aug 18 10:00:50 EDT 2017

FYI: this dashboard is looking better. I think I have all of the
non-vtkDataArray template stuff taken care of in the XML writers and the
flow path filters as well. I'll take a stab at the vtkPSLACReader. We have
some new stuff with the vtkHyperTreeGrid changes but Dave DeMarle is
actively working on that.

On Thu, Aug 17, 2017 at 11:29 AM, Allie Vacanti <allison.vacanti at kitware.com
> wrote:

> I agree, the scope for disabling the warnings should be as small as
> possible -- Leave the warnings on, and then if we find one that's
> harmless, just push/pop the warnings around the template function. Ken
> pointed me at a few of these warnings a couple weeks ago and we ended
> up fixing a few real template resolution bugs these warnings uncovered
> that severely affected performance.
>
> I took a closer look through these and fixed a few harmless warnings
> that could be easily addressed without pragmas. See
> https://gitlab.kitware.com/vtk/vtk/merge_requests/3163
>
> The vtkXMLWriter patch will probably still throw warnings after that
> MR is merged, but they can be safely ignored with the others. That
> patch just makes the optimization more robust in the case that e.g.
> vtkFloatArray is in the dispatch list, instead of
> vtkAOSDataArrayTemplate<float> (Generic template parameters are used
> before the compiler will check inheritance).
>
> There were two in places I'm not familiar with, so I'll leave those
> for someone more familiar with these classes:
>
> Filters/General/vtkQuadraturePointsUtilities.hxx:119
> Rendering/Context2D/vtkContextActor.cxx:88
>
> The rest (overloads with AOS/SOA specific arguments) can be safely
> ignored. Sean, would you mind patching those? I don't have a suitable
> version of clang to test on so it'd probably faster if you could test
> locally. Most of those are in files generated from
> Common/Core/Testing/Cxx/TestDataArrayAPI.cxx.in, so realistically
> there are only a couple places that need patching.
>
> Allie
>
> On Thu, Aug 17, 2017 at 9:46 AM, Ken Martin <ken.martin at kitware.com>
> wrote:
> > I think the warning is valuable. I do not believe it applies to general
> > class templates that have external linkage.
> >
> > I believe in this case the error is specifically due to the fact the
> > templated function in question has internal linkage. By defining it
> inside
> > an anonymous namespace the templated function cannot be used anywhere
> else,
> > and yet it is unused. So the compiler warns us.
> >
> > Potential fixes could be to
> >
> > - pull that struct (CheckShallowCopy) out of the anonymous namespace (I
> > think that changes its linkage to external)
> >
> > - do an ifdef to remove the function for this test case
> >
> > - declare that function in CheckShallowCopy as extern forcing it to have
> > external linkage
> >
> > I'm not 100% sure which if any of those solutions would work but that
> would
> > be my guess. Maybe Sean could give one of them a shot on his system?
> >
> >
> > Dave here is the llvm thread I looked at last time that talks a bit about
> > this
> >
> > https://reviews.llvm.org/D29877
> >
> >
> >
> >
> > On Wed, Aug 16, 2017 at 8:37 PM, David Cole via vtk-developers
> > <vtk-developers at vtk.org> wrote:
> >>
> >> In this thread :
> >> http://public.kitware.com/pipermail/vtk-developers/2017-
> August/035314.html
> >> , Ken Martin said
> >>
> >> "the llvm folks added this due to some ODR violation checking.
> >> That having it unused can cause it to be defined multiple times in a
> >> translation unit for some reason."
> >>
> >> Despite my Google skillz, I could not find what exactly he was
> >> referring to, and a search on the quoted "-Wunused-template" doesn't
> >> help much. Or I didn't dig deep enough.
> >>
> >> Anyhow:
> >>
> >> I think you should favor limiting the disabled bit of the warning to
> >> the scope where you know it's safe to ignore, and not just put a
> >> blanket suppression on it. Each warning is useful to somebody for some
> >> code, and ignoring them everywhere by a global compile flag is not the
> >> best way to suppress a warning in a handful of files among thousands.
> >>
> >>
> >> Just my opinion ... but there you have it.
> >>
> >> David C.
> >>
> >>
> >>
> >>
> >>
> >> On Wed, Aug 16, 2017 at 7:06 PM, Sean McBride <sean at rogue-research.com>
> >> wrote:
> >> > On Wed, 16 Aug 2017 13:54:26 -0400, Allie Vacanti said:
> >> >
> >> >>> Allison, do you think you can work on the data array warnings?
> >> >>>
> >> >>> I think if both Allison and I take care of those it should whittle
> >> >>> down the
> >> >>> list to a more manageable size to start getting others to help out
> >> >>> with.
> >> >>
> >> >>I think we should just disable the unused-template warnings. Most of
> >> >>these cases depend on the ArrayDispatch configuration and can't be
> >> >>removed without breaking features, even though some builds don't use
> >> >>them.
> >> >
> >> > Allie,
> >> >
> >> > OK, so we just have to decide if we should:
> >> >  a) use "#pragma clang diagnostic ignored" to disable this warning for
> >> > the ArrayDispatch file(s)
> >> > or
> >> >  b) I just add -Wno-unused-template to disable it everywhere and
> always
> >> >
> >> > I guess it depends if the warning is generally useful (except for the
> >> > funky case of ArrayDispatch stuff), or generally useless.
> >> >
> >> > Cheers,
> >> >
> >> > --
> >> > ____________________________________________________________
> >> > Sean McBride, B. Eng                 sean at rogue-research.com
> >> > Rogue Research                        www.rogue-research.com
> >> > Mac Software Developer              Montréal, Québec, Canada
> >> >
> >> >
> >> > _______________________________________________
> >> > Powered by www.kitware.com
> >> >
> >> > Visit other Kitware open-source projects at
> >> > http://www.kitware.com/opensource/opensource.html
> >> >
> >> > Search the list archives at:
> >> > http://markmail.org/search/?q=vtk-developers
> >> >
> >> > Follow this link to subscribe/unsubscribe:
> >> > http://public.kitware.com/mailman/listinfo/vtk-developers
> >> >
> >> _______________________________________________
> >> Powered by www.kitware.com
> >>
> >> Visit other Kitware open-source projects at
> >> http://www.kitware.com/opensource/opensource.html
> >>
> >> Search the list archives at: http://markmail.org/search/?q=
> vtk-developers
> >>
> >> Follow this link to subscribe/unsubscribe:
> >> http://public.kitware.com/mailman/listinfo/vtk-developers
> >>
> >
> >
> >
> > --
> > Ken Martin PhD
> > Distinguished Engineer
> > Kitware Inc.
> > 28 Corporate Drive
> > Clifton Park NY 12065
> >
> > This communication, including all attachments, contains confidential and
> > legally privileged information, and it is intended only for the use of
> the
> > addressee.  Access to this email by anyone else is unauthorized. If you
> are
> > not the intended recipient, any disclosure, copying, distribution or any
> > action taken in reliance on it is prohibited and may be unlawful. If you
> > received this communication in error please notify us immediately and
> > destroy the original message.  Thank you.
> >
> > _______________________________________________
> > Powered by www.kitware.com
> >
> > Visit other Kitware open-source projects at
> > http://www.kitware.com/opensource/opensource.html
> >
> > Search the list archives at: http://markmail.org/search/?q=
> vtk-developers
> >
> > Follow this link to subscribe/unsubscribe:
> > http://public.kitware.com/mailman/listinfo/vtk-developers
> >
> >
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at http://www.kitware.com/
> opensource/opensource.html
>
> Search the list archives at: http://markmail.org/search/?q=vtk-developers
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/vtk-developers
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20170818/f09b40f4/attachment-0001.html>