This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Dejagnu-fu/pex-fu/diagnostics-fu needed to get LTO warnings right


> > The patch applied cleanly - this is what I got as a result:
> > 
> > https://gcc.gnu.org/ml/gcc-testresults/2015-04/msg01450.html
> > 
> > I hope this is useful.
> 
> ok, so the problem would seem to be graphite-scop-detection.c is
> including front end specific headers.  Can you put a #error in cp-tree.h
> and recompile graphite-scop-detection.o to see what the path to
> including it is?

I am happy the patch found its use. I guess I should revive it for
this stage1 then, but IMO the extra note with no location info is ugly.
I wondered if we don't want to update the debug machinery itself to
output something like
  translation_unit:source_file:line:column
tuples or transparently add notes as we do for inline chains? I.e. adding extra
note after each warning with location saying "originating from this translation
unit".

I guess the translation_unit should be .o name
instead of the soruce code, because one source code may be used to build
multiple units (like in libgcc). Any idea how to get this done?

I suppose we need to do this in a way IDEs are not overly confused.

Another thing we probably want to solve this time is to teach PEX in libiberty
to not redirect STDERR, so colors are preserved and warnings are not cached
until very end of compilation. Does anyone have understanding why the caching
is done? I looked at pex briefly but it is all greek to me.

Final think we need to solve is dejagnu support for LTO warning checks.
I would be also very happy to find volunteer for that

Honza


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]