On Sep 12, 2019, Richard Biener <richard.guent...@gmail.com> wrote: > Your new predicate looks a bit excessive here given it builds the type > again?
Err, there seems to be some misunderstanding here. The predicate avoids outputting a type for the definition if it's the same DIE that would go in the specification. Now, when it's a different DIE, sometimes it might still refer to the same type, as in array-2.C, but I think that's not just acceptable, it's desirable, for it reflects the different ways used to denote the same type. Before posting the patch, I added an inform() to the case in which completing_type_p would return true (bringing about a debug info change), and reviewed all of the messages in a bootstrap. The only ones that weren't just adding array element count were those that inspired array-2.C and array-3.C. > So I'm obviously fine with your patch and I guess if we independently > arrive at this solution that answers my question what "correct DWARF" > is by a majority decision ;) Good. Once we clear up the misunderstanding (I'm not sure whether you misunderstood the patch, or I misunderstood your response), I'll be glad to put it in. > So - maybe we can have the patch a bit cleaner by adding > a flag to add_type_attribute saying we only want it if it's > different from that already present (on the specification DIE)? That's exactly what I meant completing_type_p to check. Do you mean it should be stricter, do it more cheaply, or what? -- Alexandre Oliva, freedom fighter he/him https://FSFLA.org/blogs/lxo Be the change, be Free! FSF.org & FSF Latin America board member GNU Toolchain Engineer Free Software Evangelist Hay que enGNUrecerse, pero sin perder la terGNUra jamás - Che GNUevara
