Description of problem: When configured to use link time optimization, GCC generates incorrect code for Emacs, causing Emacs to crash. Version-Release number of selected component (if applicable): gcc (GCC) 7.1.1 20170622 (Red Hat 7.1.1-3) How reproducible: git clone -b master git://git.sv.gnu.org/emacs.git emacs-gcc-test cd emacs-gcc-test git checkout 1454ad6f068f1d94070943b6784bc127a3119055 ./autogen.sh ./configure --enable-checking --enable-link-time-optimization CFLAGS='-g3 -Os' make gdb src/temacs (gdb) disas Fffloor (gdb) disas 0x55e3ae Actual results: (gdb) disas Fffloor Dump of assembler code for function Fffloor: 0x000000000055e3fe <+0>: push %rbx 0x000000000055e3ff <+1>: mov %rdi,%rbx 0x000000000055e402 <+4>: callq 0x55e3ae <CHECK_FLOAT.lto_priv.386> 0x000000000055e407 <+9>: mov %rbx,%rdi 0x000000000055e40a <+12>: callq 0x547f65 <XFLOAT_DATA> 0x000000000055e40f <+17>: callq 0x415090 <floor@plt> 0x000000000055e414 <+22>: pop %rbx 0x000000000055e415 <+23>: jmpq 0x495929 <make_float> End of assembler dump. (gdb) disas 0x55e3ae Dump of assembler code for function CHECK_FLOAT.lto_priv.386: 0x000000000055e3ae <+0>: mov $0x2c4e350,%edi 0x000000000055e3b3 <+5>: jmpq 0x549592 <make_lisp_symbol> End of assembler dump. Expected results: This does not match the source code for Fffloor in src/floatfns.c, which says: CHECK_FLOAT (arg); double d = XFLOAT_DATA (arg); d = floor (d); return make_float (d); and where CHECK_FLOAT is defined as follows: static void CHECK_FLOAT (Lisp_Object x) { CHECK_TYPE (FLOATP (x), builtin_lisp_symbol (501), x); } where builtin_lisp_symbol(501) is an inline call that can be evaluated at compile time to be equivalent to make_lisp_symbol(0x2c4e350), and where the called functions are defined as follows: _Bool FLOATP (Lisp_Object x) { return XTYPE (x) == Lisp_Float; } extern _Noreturn void wrong_type_argument (Lisp_Object, Lisp_Object); inline void CHECK_TYPE (int ok, Lisp_Object predicate, Lisp_Object x) { (ok ? (void) 0 : wrong_type_argument (predicate, x)); } In other words, the body of CHECK_FLOAT is being evaluated as if it were simply builtin_lisp_symbol(501), instead of its full definiens. Evidently there is a code-generation bug in this particular combination of C compiler options, which includes -g3 -Os -flto=4 -ffat-lto-objects on my platform (and many other options, but I expect these are the crucial ones). Additional info:
This message is a reminder that Fedora 26 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 26. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '26'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 26 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
I am still observing a bug with Fedora 28, though with slightly different symptoms. Fedora 28 uses this GCC version: gcc (GCC) 8.0.1 20180324 (Red Hat 8.0.1-0.20) The same set of commands: git clone -b master git://git.sv.gnu.org/emacs.git emacs-gcc-test cd emacs-gcc-test git checkout 1454ad6f068f1d94070943b6784bc127a3119055 ./autogen.sh ./configure --enable-checking --enable-link-time-optimization CFLAGS='-g3 -Os' make gdb src/temacs ... now results in the following behavior: (gdb) disas Fffloor Dump of assembler code for function Fffloor: 0x000000000054f6ab <+0>: push %rbx 0x000000000054f6ac <+1>: mov %rdi,%rbx 0x000000000054f6af <+4>: callq 0x54f65b <CHECK_FLOAT> 0x000000000054f6b4 <+9>: mov %rbx,%rdi 0x000000000054f6b7 <+12>: callq 0x545c8a <XFLOAT_DATA> 0x000000000054f6bc <+17>: callq 0x415220 <floor@plt> 0x000000000054f6c1 <+22>: pop %rbx 0x000000000054f6c2 <+23>: jmpq 0x4a28d7 <make_float> End of assembler dump. (gdb) disas 0x54f65b Dump of assembler code for function CHECK_FLOAT: 0x000000000054f65b <+0>: mov $0x2c48130,%edi 0x000000000054f660 <+5>: jmpq 0x54712f <make_lisp_symbol> End of assembler dump. The machine code for CHECK_FLOAT is still incorrect, as it is still just calling make_lisp_symbol as opposed to actually doing the checking.
This message is a reminder that Fedora 28 is nearing its end of life. On 2019-May-28 Fedora will stop maintaining and issuing updates for Fedora 28. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '28'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 28 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
I am still seeing the same failure in Fedora 29, with the same symptoms that I reported for Fedora 28. My platform is x86-64, as before.
I am still observing incorrect code generated by GCC with Fedora 30, though with slightly different symptoms. Fedora 30 uses this GCC version: gcc (GCC) 9.1.1 20190503 (Red Hat 9.1.1-1) The same set of commands: git clone -b master git://git.sv.gnu.org/emacs.git emacs-gcc-test cd emacs-gcc-test git checkout 1454ad6f068f1d94070943b6784bc127a3119055 ./autogen.sh ./configure --enable-checking --enable-link-time-optimization CFLAGS='-g3 -Os' make gdb src/temacs ... now results in the following behavior: (gdb) disas Fffloor Dump of assembler code for function Fffloor: 0x000000000048e7bd <+0>: sub $0x18,%rsp 0x000000000048e7c1 <+4>: mov %rdi,0x8(%rsp) 0x000000000048e7c6 <+9>: callq 0x48e697 <CHECK_FLOAT> 0x000000000048e7cb <+14>: mov 0x8(%rsp),%rdi 0x000000000048e7d0 <+19>: callq 0x4fab2c <XFLOAT_DATA> 0x000000000048e7d5 <+24>: callq 0x415540 <floor@plt> 0x000000000048e7da <+29>: add $0x18,%rsp 0x000000000048e7de <+33>: jmpq 0x4af5b1 <make_float> End of assembler dump. (gdb) disas CHECK_FLOAT Dump of assembler code for function CHECK_FLOAT: 0x000000000048e697 <+0>: mov $0xa17bd0,%edi 0x000000000048e69c <+5>: jmpq 0x4fbd6b <make_lisp_symbol> End of assembler dump. The machine code for CHECK_FLOAT is still incorrect, as it is still just calling make_lisp_symbol as opposed to actually doing the checking.
This message is a reminder that Fedora 30 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 30 on 2020-05-26. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '30'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 30 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
I am still observing incorrect code generated by GCC with Fedora 31, though with slightly different symptoms. Fedora 31 uses this GCC version: gcc (GCC) 9.3.1 20200408 (Red Hat 9.3.1-2) The same set of commands: git clone -b master git://git.sv.gnu.org/emacs.git emacs-gcc-test cd emacs-gcc-test git checkout 1454ad6f068f1d94070943b6784bc127a3119055 ./autogen.sh ./configure --enable-checking --enable-link-time-optimization CFLAGS='-g3 -Os' make gdb src/temacs ... now results in the following behavior: (gdb) disas Fffloor Dump of assembler code for function Fffloor: 0x000000000048ed0e <+0>: sub $0x18,%rsp 0x000000000048ed12 <+4>: mov %rdi,0x8(%rsp) 0x000000000048ed17 <+9>: callq 0x48ec8e <CHECK_FLOAT> 0x000000000048ed1c <+14>: mov 0x8(%rsp),%rdi 0x000000000048ed21 <+19>: callq 0x4fb3c5 <XFLOAT_DATA> 0x000000000048ed26 <+24>: callq 0x415570 <floor@plt> 0x000000000048ed2b <+29>: add $0x18,%rsp 0x000000000048ed2f <+33>: jmpq 0x4afe20 <make_float> End of assembler dump. (gdb) disas CHECK_FLOAT Dump of assembler code for function CHECK_FLOAT: 0x000000000048ec8e <+0>: mov $0xa19d10,%edi 0x000000000048ec93 <+5>: jmpq 0x4fc604 <make_lisp_symbol> End of assembler dump. The machine code for CHECK_FLOAT is still incorrect, as it is still just calling make_lisp_symbol as opposed to actually doing the checking.
This message is a reminder that Fedora 31 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 31 on 2020-11-24. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '31'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 31 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 31 changed to end-of-life (EOL) status on 2020-11-24. Fedora 31 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.
I am no longer seeing the bug in Fedora 33, and so am marking it as CURRENTRELEASE (which I assume means the bug is fixed). Thanks to whoever fixed it.