https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104237
--- Comment #21 from Chengnian Sun ---
Thank you, Andrew and Jakub.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104237
--- Comment #20 from Jakub Jelinek ---
(In reply to Andrew Pinski from comment #19)
> (In reply to Chengnian Sun from comment #18)
> > Hello folks,
> >
> > While testing gcc with -fcompare-debug, I was asked a question which puzzled
> > me as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104237
--- Comment #19 from Andrew Pinski ---
(In reply to Chengnian Sun from comment #18)
> Hello folks,
>
> While testing gcc with -fcompare-debug, I was asked a question which puzzled
> me as well.
>
> What if we always enable -g, and use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104237
--- Comment #18 from Chengnian Sun ---
Hello folks,
While testing gcc with -fcompare-debug, I was asked a question which puzzled me
as well.
What if we always enable -g, and use 'strip' to remove debug information from
the binary file? Then
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104237
--- Comment #17 from Chengnian Sun ---
Thanks for the prompt help. I managed to locate the exact commit.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104237
--- Comment #16 from Jakub Jelinek ---
-gf4ee27d32 means something didn't work correctly, normally it should be
something like r12-6853-gf4ee27d32 which you can use directly in git.
Anyway, the git has is after the -g, so f4ee27d32.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104237
--- Comment #15 from Andrew Pinski ---
The g part of the uuid stands for global revision and the g needs to be removed
to get a normal gut hash.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104237
--- Comment #14 from Chengnian Sun ---
How to interpret the version string of "gcc -v"? For example, in the following
output, I tried to locate the commit with id gf4ee27d32, but did not get
anything.
"gcc version 12.0.1 20220125
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104237
--- Comment #13 from Chengnian Sun ---
(In reply to Jakub Jelinek from comment #10)
> Because -fcompare-debug tells the driver to compile the TU twice, once
> without and once with -gtoggle, and compare the result.
> So, if there is a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104237
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104237
--- Comment #11 from CVS Commits ---
The releases/gcc-11 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:88ff2eb5cc2c1af2ae751c02997d0b5667662782
commit r11-9594-g88ff2eb5cc2c1af2ae751c02997d0b5667662782
Author: Jakub Jelinek
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104237
--- Comment #10 from Jakub Jelinek ---
Because -fcompare-debug tells the driver to compile the TU twice, once without
and once with -gtoggle, and compare the result.
So, if there is a difference in the generated IL e.g. for -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104237
--- Comment #9 from Chengnian Sun ---
Hi,
Could you explain why the flag `-fcompare-debug` does not detect this bug? Is
it because the bug is triggered with -flto and -fcompare-debug does not work
with -flto?
Thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104237
Jakub Jelinek changed:
What|Removed |Added
Summary|[11/12 Regression] Emitted |[11 Regression] Emitted
14 matches
Mail list logo
