https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93369
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93369
--- Comment #20 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:bb40460646ce4e6ad27a2f6795106d004d405314
commit r10-7652-gbb40460646ce4e6ad27a2f6795106d004d405314
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93369
--- Comment #19 from Jan Hubicka ---
The reason why we get link failure is that we behave differently to mismatched
comdats. While linker choose comdat that wins and eliminate other one we keep
the other symbol and end up compiling it which
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93369
Richard Biener changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93369
--- Comment #17 from Jan Hubicka ---
Note that to fully fix the problem we need to resolve the way aliases works.
In this case ODR violation makes one COMDAT section to contain only ctor, while
other contains ctor and its thunk. The first
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93369
Martin Liška changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93369
--- Comment #15 from Jan Hubicka ---
The testcase has an ODR violation that makes comdat groups go out of sync. So I
guess it is just about finding way to not make verifier to ICE.
With release settings the testcase will however quietly compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93369
--- Comment #14 from Segher Boessenkool ---
We can use the r10-1234 names in exactly the places we use r123456 before.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93369
--- Comment #13 from Martin Liška ---
>
> Should we be putting the short version like "r10-1234" in the summary line?
I'm planning to start doing that.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93369
--- Comment #12 from Bill Seurer ---
On 2020-01-27 02:19, jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93369
>
> --- Comment #9 from Jakub Jelinek ---
> Even the git gcc-descr --full output can be shortened,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93369
--- Comment #11 from Jakub Jelinek ---
(In reply to Martin Liška from comment #10)
> > if you want, and the non---full output is something meant for the subjects,
> > r10-1234 is unique,
>
> ... but not a git approach (the hash is missing and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93369
--- Comment #10 from Martin Liška ---
(In reply to Jakub Jelinek from comment #9)
> Even the git gcc-descr --full output can be shortened, use fewer sha digits
I will then shorten it.
> if you want, and the non---full output is something meant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93369
--- Comment #9 from Jakub Jelinek ---
Even the git gcc-descr --full output can be shortened, use fewer sha digits if
you want, and the non---full output is something meant for the subjects,
r10-1234 is unique, will be redirected to the right
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93369
Martin Liška changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93369
--- Comment #7 from Segher Boessenkool ---
Why? Is there any advantage to that? The probability of having a collision
anywhere in the repo is nihil with ten digits already, and anywhere in the
world ever with twelve. Why do we want
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93369
--- Comment #6 from Martin Liška ---
(In reply to Segher Boessenkool from comment #5)
> You can also shorten the sha, say, g:28307164dfed here.
Yes, but I was asked by Jakub to always use:
git gcc-descr --full $hash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93369
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93369
--- Comment #4 from Martin Liška ---
(In reply to seurer from comment #3)
> Will do in the future re: using g:
Good.
>
> Should it also go in the Summary line? The hashes would make it quite long.
Dunno, but I don't do it as it would really
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93369
--- Comment #3 from seurer at gcc dot gnu.org ---
Will do in the future re: using g:
Should it also go in the Summary line? The hashes would make it quite long.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93369
Martin Liška changed:
What|Removed |Added
Status|NEW |ASSIGNED
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93369
--- Comment #2 from Martin Liška ---
Like g:28307164dfed294855bf3d55bed357de560f083b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93369
--- Comment #1 from Martin Liška ---
(In reply to seurer from comment #0)
> THIS STARTED WITH COMMIT 28307164dfed294855bf3d55bed357de560f083b
Please prefix commit hash with g: . It will provide a http link.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93369
Richard Biener changed:
What|Removed |Added
Priority|P3 |P1
Status|UNCONFIRMED
23 matches
Mail list logo
