On Wed, Apr 11, 2012 at 5:54 AM, Tobias Burnus <bur...@net-b.de> wrote: > Dear all, > > my recent patch for setting PRIVATE module variables and procedures to > TREE_PUBLIC()=0 had a flaw: I completely forgot about generic interfaces. > Even if the specific name is PRIVATE, the specific function is still > callable through the a (public) generic name. > > Thanks to HJ for the report. (The bug causes a failures of SPEC CPU 2006.) > > I think the handling of type-bound procedures is correct. However, I > wouldn't mind if someone could confirm it. I only check for the specific > entries as GENERIC, OPERATOR and ASSIGNMENT use a type-bound-proc name, > which is already handled. I also didn't try to optimize for private DT, > private generics etc. First, I think it is not needed. And secondly, through > inheritance, it can get extremely complicated. > > Build and regtested on x86-64-linux. > OK for the trunk? >
The testcase failed with /export/gnu/import/git/gcc-test-ia32/src-trunk/gcc/testsuite/gfortran.dg/public_private_module_4.f90:11.4:^M ^M use m^M 1^M Fatal Error: Can't open module file 'm.mod' for reading at (1): No such file or directory^M compiler exited with status 1 -- H.J.