Created attachment 8659 [details] ELF object that reproduces the above problem hype260@ben:less \\_collab\\_usr\\_global\\_tools\\_order\\_spack\\_opt\\_chaos_5_x86_64_ib\\_gcc\@4.4.7\\_vtk\@6.1.0-2f431570\\_lib\\_libvtkInfovisCore-6.1.so/stderr Functions changes summary: 0 Removed, 8 Changed, 0 Added functions Variables changes summary: 0 Removed, 0 Changed, 0 Added variable <snip a bunch of cases of loss of reference see: pr19035> [C]'method bool vtkVariant::operator<(const vtkVariant&)' has some indirect sub-type changes: 'method bool vtkVariant::operator<(const vtkVariant&)' access changed from 'private' to 'public' The loss of private attribute is something different than I've seen elsewhere.
In another ELF object it appears that the protected attribute gets dropped in certain cases. I expect that this is just a different manifestation of the same problem. hype260@ben:less \\_collab\\_usr\\_global\\_tools\\_order\\_spack\\_opt\\_chaos_5_x86_64_ib\\_gcc\@4.4.7\\_vtk\@6.1.0-2f431570\\_lib\\_libvtkIOParallel-6.1.so/stderr Functions changes summary: 0 Removed, 2 Changed, 0 Added functions Variables changes summary: 0 Removed, 0 Changed, 0 Added variable 2 functions with some indirect sub-type change: [C]'method virtual int vtkPSLACReader::ReadMidpointCoordinates(int, vtkMultiBlockDataSet*, vtkSLACReader::MidpointCoordinateMap&)' has some indirect sub-type changes: parameter 3 of type 'vtkSLACReader::MidpointCoordinateMap&' has sub-type changes: in referenced type 'class vtkSLACReader::MidpointCoordinateMap': 'class vtkSLACReader::MidpointCoordinateMap' access changed from 'protected' to 'none' [C]'method virtual int vtkPSLACReader::ReadMidpointData(int, vtkMultiBlockDataSet*, vtkSLACReader::MidpointIdMap&)' has some indirect sub-type changes: parameter 3 of type 'vtkSLACReader::MidpointIdMap&' has sub-type changes: in referenced type 'class vtkSLACReader::MidpointIdMap': 'class vtkSLACReader::MidpointIdMap' access changed from 'protected' to 'none'
Created attachment 8695 [details] Another reproducer this llvm-as reproducer seems to be a particularly good test case in that it demonstrates a bunch of different problems.
I ran abidw --abidiff on the attached binary, on the master branch at commit https://sourceware.org/git/gitweb.cgi?p=libabigail.git;a=commit;h=09de4435ce4c3d9df2aeda6c0fa615faa2a63bb5, and the problem seems to be gone now. It has maybe been fixed by some of the recent changes. Thank you for reporting this problem!