On Fri, Oct 4, 2019 at 1:55 PM Uecker, Martin
<martin.uec...@med.uni-goettingen.de> wrote:
>
> Am Freitag, den 04.10.2019, 12:29 +0200 schrieb Richard Biener:
> > On Wed, Oct 2, 2019 at 8:24 PM Uecker, Martin
> > <martin.uec...@med.uni-goettingen.de> wrote:
> > >
> > > Am Mittwoch, den 02.10.2019, 17:37 +0200 schrieb Richard Biener:
>
> > >
> > > ...
> > >
> > > > > > Oh, and LTO does _not_ merge types declared inside a function,
> > > > > > so
> > > > > >
> > > > > > void foo () { struct S { int i; }; }
> > > > > > void bar () { struct S { int i; }; }
> > > > > >
> > > > > > the two S are distinct and objects of that type do not conflict.
> > > > >
> > > > > This is surprising as these types are compatible across TUs. So
> > > > > if some pointer is passed between these functions this is
> > > > > supposed to work.
> > > >
> > > > So if they are compatible the frontend needs to mark them so in this
> > > > case.
> > >
> > > It can't. The front end never sees the other TU.
> >
> > If the type "leaves" the CU via a call the called function has a prototype
> > through which it "sees" the CU.
>
> The prototype could be local to the function or it could be a void*
> (or other pointer type) argument.
>
>
>
> TU1-----------------------
> #include <stdio.h>
>
> extern void f(void *p);
>
> int main()
> {
> struct foo { int x; } b;
> b.x = 2;
> f(&b);
> printf("%d\n", b.x);
> }
>
> TU2-----------------------------
> extern void f(void *p)
> {
> struct foo { int x; } *q = p;
> q->x = 3;
> }
If the frontend puts those structures at local scope
then yes, the above presents a problem to LTO
at the moment. So, trigger some inlining,
make main() read b.x after f(&b) and assert that
it is 3. I think that would fail at the moment.
Richard.
> Best,
> Martin
