https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84052
--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> --- (In reply to Cao jin from comment #2) > (In reply to Andrew Pinski from comment #1) > > Plugins issues like this should reported to the plugin author and not to > > gcc. > > I don't know gcc internals, from my very limited understanding about gcc & > that plugin, the plugin just does one optimization on the intermediate > language: redefine a structure with randomized order and set it back to its > context. So the backend would see a structure different from its original > definition in source file and could generate the proper debuginfo. So I > feels this issue may be more close to gcc. > > I was not sure where should I report this problem. I was hoping gcc guys > could take a look at that plugin, I feel it is not hard for you gcc expert > to read, even I can tell the basic logic inside. It is not the job of gcc developers to figure out a bug in a plugin or gcc. It is plugin writer's job to do that. (In reply to PaX Team from comment #3) > (In reply to Andrew Pinski from comment #1) > > Plugins issues like this should reported to the plugin author and not to > > gcc. > what makes you think it's a plugin issue? i reported several gcc bugs myself > over the years that i ran across while developing plugins (some have yet to > be addressed fwiw). this case is no different, it's a gcc bug where > sometimes gcc emits debug info for a type that has not even been constructed > yet. Because debug information happens early on and has many interactions with the front end. Most optimizations don't change types. In fact changing of the type after the fact is not the correct approach, you need to duplication the type and then lay it out and change all of the ir. This is how struct reorg would work. Also you have to check to make sure the types don't escape. Now of that code exists in gcc right now. So again this is outside of the scope of gcc bug.
