* [Bug lto/85574] [8/9 Regression] LTO bootstapped binaries differ
[not found] <bug-85574-4@http.gcc.gnu.org/bugzilla/>
@ 2021-01-26 15:45 ` ebotcazou at gcc dot gnu.org
2021-01-26 19:35 ` ebotcazou at gcc dot gnu.org
` (7 subsequent siblings)
8 siblings, 0 replies; 9+ messages in thread
From: ebotcazou at gcc dot gnu.org @ 2021-01-26 15:45 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85574
Eric Botcazou <ebotcazou at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |ebotcazou at gcc dot gnu.org
--- Comment #33 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
The bootstrap-lto.mk patch breaks LTO bootstrap on Windows: you cannot compare
executables on this system since they are timestamped. I really don't see the
point in this patch, why comparing lto1 and not other compilers?
^ permalink raw reply [flat|nested] 9+ messages in thread* [Bug lto/85574] [8/9 Regression] LTO bootstapped binaries differ
[not found] <bug-85574-4@http.gcc.gnu.org/bugzilla/>
2021-01-26 15:45 ` [Bug lto/85574] [8/9 Regression] LTO bootstapped binaries differ ebotcazou at gcc dot gnu.org
@ 2021-01-26 19:35 ` ebotcazou at gcc dot gnu.org
2021-01-27 9:04 ` rguenth at gcc dot gnu.org
` (6 subsequent siblings)
8 siblings, 0 replies; 9+ messages in thread
From: ebotcazou at gcc dot gnu.org @ 2021-01-26 19:35 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85574
--- Comment #34 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
"cmp -i 256" seems to be a way out though.
^ permalink raw reply [flat|nested] 9+ messages in thread* [Bug lto/85574] [8/9 Regression] LTO bootstapped binaries differ
[not found] <bug-85574-4@http.gcc.gnu.org/bugzilla/>
2021-01-26 15:45 ` [Bug lto/85574] [8/9 Regression] LTO bootstapped binaries differ ebotcazou at gcc dot gnu.org
2021-01-26 19:35 ` ebotcazou at gcc dot gnu.org
@ 2021-01-27 9:04 ` rguenth at gcc dot gnu.org
2021-01-27 9:42 ` ebotcazou at gcc dot gnu.org
` (5 subsequent siblings)
8 siblings, 0 replies; 9+ messages in thread
From: rguenth at gcc dot gnu.org @ 2021-01-27 9:04 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85574
--- Comment #35 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Eric Botcazou from comment #33)
> The bootstrap-lto.mk patch breaks LTO bootstrap on Windows: you cannot
> compare executables on this system since they are timestamped. I really
> don't see the point in this patch, why comparing lto1 and not other
> compilers?
Because I didn't try to invent a clever way to detect which ones will
actually exist (but I know lto1 will). Sure some extra-compare-if-exists
could be invented. If there's no way to compare binaries on windows
then there's maybe a way to conditionalize the extra-compare setting
in the makefile fragment.
^ permalink raw reply [flat|nested] 9+ messages in thread* [Bug lto/85574] [8/9 Regression] LTO bootstapped binaries differ
[not found] <bug-85574-4@http.gcc.gnu.org/bugzilla/>
` (2 preceding siblings ...)
2021-01-27 9:04 ` rguenth at gcc dot gnu.org
@ 2021-01-27 9:42 ` ebotcazou at gcc dot gnu.org
2021-01-27 10:54 ` rguenther at suse dot de
` (4 subsequent siblings)
8 siblings, 0 replies; 9+ messages in thread
From: ebotcazou at gcc dot gnu.org @ 2021-01-27 9:42 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85574
--- Comment #36 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
> Because I didn't try to invent a clever way to detect which ones will
> actually exist (but I know lto1 will). Sure some extra-compare-if-exists
> could be invented. If there's no way to compare binaries on windows
> then there's maybe a way to conditionalize the extra-compare setting
> in the makefile fragment.
There is one, see above. And it looks like contrib/compare-lto should be
rewritten from scratch, it takes a lot of time on Windows for nothing IIUC.
^ permalink raw reply [flat|nested] 9+ messages in thread* [Bug lto/85574] [8/9 Regression] LTO bootstapped binaries differ
[not found] <bug-85574-4@http.gcc.gnu.org/bugzilla/>
` (3 preceding siblings ...)
2021-01-27 9:42 ` ebotcazou at gcc dot gnu.org
@ 2021-01-27 10:54 ` rguenther at suse dot de
2021-01-27 20:18 ` ebotcazou at gcc dot gnu.org
` (3 subsequent siblings)
8 siblings, 0 replies; 9+ messages in thread
From: rguenther at suse dot de @ 2021-01-27 10:54 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85574
--- Comment #37 from rguenther at suse dot de <rguenther at suse dot de> ---
On Wed, 27 Jan 2021, ebotcazou at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85574
>
> --- Comment #36 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
> > Because I didn't try to invent a clever way to detect which ones will
> > actually exist (but I know lto1 will). Sure some extra-compare-if-exists
> > could be invented. If there's no way to compare binaries on windows
> > then there's maybe a way to conditionalize the extra-compare setting
> > in the makefile fragment.
>
> There is one, see above. And it looks like contrib/compare-lto should be
> rewritten from scratch, it takes a lot of time on Windows for nothing IIUC.
Feel free to improve things - I do not have any Windows system to
test on or an idea what you think needs to be improved. I would
guess similar things apply to compare-debug which it was derived from.
^ permalink raw reply [flat|nested] 9+ messages in thread* [Bug lto/85574] [8/9 Regression] LTO bootstapped binaries differ
[not found] <bug-85574-4@http.gcc.gnu.org/bugzilla/>
` (4 preceding siblings ...)
2021-01-27 10:54 ` rguenther at suse dot de
@ 2021-01-27 20:18 ` ebotcazou at gcc dot gnu.org
2021-01-28 10:34 ` cvs-commit at gcc dot gnu.org
` (2 subsequent siblings)
8 siblings, 0 replies; 9+ messages in thread
From: ebotcazou at gcc dot gnu.org @ 2021-01-27 20:18 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85574
--- Comment #38 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
> Feel free to improve things - I do not have any Windows system to
> test on or an idea what you think needs to be improved. I would
> guess similar things apply to compare-debug which it was derived from.
That's even more broken than initially thought: nobody sets $(exeext) at top
level so gcc/lto1 is passed and then the behavior is random since some tools
apppend the missing .exe implicitly and some don't.
^ permalink raw reply [flat|nested] 9+ messages in thread* [Bug lto/85574] [8/9 Regression] LTO bootstapped binaries differ
[not found] <bug-85574-4@http.gcc.gnu.org/bugzilla/>
` (5 preceding siblings ...)
2021-01-27 20:18 ` ebotcazou at gcc dot gnu.org
@ 2021-01-28 10:34 ` cvs-commit at gcc dot gnu.org
2021-01-28 10:35 ` cvs-commit at gcc dot gnu.org
2021-01-28 10:40 ` cvs-commit at gcc dot gnu.org
8 siblings, 0 replies; 9+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2021-01-28 10:34 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85574
--- Comment #39 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Eric Botcazou <ebotcazou@gcc.gnu.org>:
https://gcc.gnu.org/g:f7a6d314e7f7eeb6240a4f62511c189c90ef300c
commit r11-6951-gf7a6d314e7f7eeb6240a4f62511c189c90ef300c
Author: Eric Botcazou <ebotcazou@adacore.com>
Date: Thu Jan 28 11:31:35 2021 +0100
Fix LTO bootstrap on Windows
The latest fix introduced a comparison of executables and this cannot
directly work on Windows because they are timestamped. Moreover nobody
sets $(exeext) at top level, at least on MinGW, so you get weird behavior
because some tools add the implicit .exe suffix and others do not.
contrib/
PR lto/85574
* compare-lto: Deal with PE-COFF executables specifically.
^ permalink raw reply [flat|nested] 9+ messages in thread* [Bug lto/85574] [8/9 Regression] LTO bootstapped binaries differ
[not found] <bug-85574-4@http.gcc.gnu.org/bugzilla/>
` (6 preceding siblings ...)
2021-01-28 10:34 ` cvs-commit at gcc dot gnu.org
@ 2021-01-28 10:35 ` cvs-commit at gcc dot gnu.org
2021-01-28 10:40 ` cvs-commit at gcc dot gnu.org
8 siblings, 0 replies; 9+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2021-01-28 10:35 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85574
--- Comment #40 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-10 branch has been updated by Eric Botcazou
<ebotcazou@gcc.gnu.org>:
https://gcc.gnu.org/g:4be929be0317b2baf1c67b430ad0a2fbaed05152
commit r10-9307-g4be929be0317b2baf1c67b430ad0a2fbaed05152
Author: Eric Botcazou <ebotcazou@adacore.com>
Date: Thu Jan 28 11:31:35 2021 +0100
Fix LTO bootstrap on Windows
The latest fix introduced a comparison of executables and this cannot
directly work on Windows because they are timestamped. Moreover nobody
sets $(exeext) at top level, at least on MinGW, so you get weird behavior
because some tools add the implicit .exe suffix and others do not.
contrib/
PR lto/85574
* compare-lto: Deal with PE-COFF executables specifically.
^ permalink raw reply [flat|nested] 9+ messages in thread* [Bug lto/85574] [8/9 Regression] LTO bootstapped binaries differ
[not found] <bug-85574-4@http.gcc.gnu.org/bugzilla/>
` (7 preceding siblings ...)
2021-01-28 10:35 ` cvs-commit at gcc dot gnu.org
@ 2021-01-28 10:40 ` cvs-commit at gcc dot gnu.org
8 siblings, 0 replies; 9+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2021-01-28 10:40 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85574
--- Comment #41 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-9 branch has been updated by Eric Botcazou
<ebotcazou@gcc.gnu.org>:
https://gcc.gnu.org/g:faed344ee5f17b9a19961b3b1f8ea0ed10db6f2d
commit r9-9208-gfaed344ee5f17b9a19961b3b1f8ea0ed10db6f2d
Author: Eric Botcazou <ebotcazou@adacore.com>
Date: Thu Jan 28 11:31:35 2021 +0100
Fix LTO bootstrap on Windows
The latest fix introduced a comparison of executables and this cannot
directly work on Windows because they are timestamped. Moreover nobody
sets $(exeext) at top level, at least on MinGW, so you get weird behavior
because some tools add the implicit .exe suffix and others do not.
contrib/
PR lto/85574
* compare-lto: Deal with PE-COFF executables specifically.
^ permalink raw reply [flat|nested] 9+ messages in thread