https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81668
Jan Hubicka changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81668
--- Comment #16 from Steinar H. Gunderson ---
Yes, I'm fine with closing this bug; the spurious cases are gone, and the
traces seem to be genuinely helpful now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81668
--- Comment #15 from Jan Hubicka ---
> I tested with a GCC snapshot (at r267505). I can now build all mysqld with LTO
> and get exactly one LTO warning, and it's a true positive (two Bison parsers
> that we haven't managed to untangle yet).
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81668
--- Comment #14 from Steinar H. Gunderson ---
I tested with a GCC snapshot (at r267505). I can now build all mysqld with LTO
and get exactly one LTO warning, and it's a true positive (two Bison parsers
that we haven't managed to untangle yet).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81668
--- Comment #13 from Jan Hubicka ---
Warnings from comment #8 are fixed now. I would love to know if there are any
issues with what GCC 9 outputs. We still can't track locations to the original
.o files though.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81668
--- Comment #12 from sgunderson at bigfoot dot com ---
The spurious warning seems to be gone in GCC 8.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81668
Jan Hubicka changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81668
--- Comment #10 from Jan Hubicka ---
Problem is that we do not have location info that would say us the origin.
I have sent patch to add location info into TRANSLATION_UNIT_DECL some time ago
(at least a year) but I do not think it was approved.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81668
--- Comment #9 from sgunderson at bigfoot dot com ---
(In reply to Manuel López-Ibáñez from comment #8)
> Actually, what would be more useful is to detect that the difference in type
> comes from S and point out where S has been declared as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81668
--- Comment #8 from Manuel López-Ibáñez ---
(In reply to sgunderson from comment #7)
> What I'd like is some sort of indication about where test.h came in from
> (test1.cc and test2.cc).
Actually, what would be more useful is to detect that the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81668
--- Comment #7 from sgunderson at bigfoot dot com ---
(In reply to Manuel López-Ibáñez from comment #6)
>> fts0pars.y:62:0: note: a field with different name is defined in another
>> translation unit
> Did you cut the above? It looks like a note
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81668
Manuel López-Ibáñez changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81668
--- Comment #5 from sgunderson at bigfoot dot com ---
(In reply to Markus Trippelsdorf from comment #3)
> I don't see any bug, all relevant information is in the warnings.
My point is that all relevant information _isn't_ in the warnings.
In
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81668
Martin Sebor changed:
What|Removed |Added
CC||msebor at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81668
Markus Trippelsdorf changed:
What|Removed |Added
CC||trippels at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81668
--- Comment #2 from sgunderson at bigfoot dot com ---
Running with -fno-diagnostics-show-caret does not help any:
../include/violite.h:288:8: warning: type ‘struct st_vio’ violates the C++ One
Definition Rule [-Wodr]
../include/violite.h:288:0:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81668
Richard Biener changed:
What|Removed |Added
Keywords||diagnostic, lto
CC|
17 matches
Mail list logo
