Created attachment 636197 [details] Preprocessed output the compiler dumped. Description of problem: Trying to fix some bugs in gnu-efi and got an ICE: /usr/bin/gcc -I./../lib -I./../lib/../inc -I./../lib/../inc/x86_64 -I./../lib/../inc/protocol -O2 -fpic -Wall -fshort-wchar -fno-strict-aliasing -fno-merge-constants -mno-red-zone -DCONFIG_x86_64 -DGNU_EFI_USE_MS_ABI -maccumulate-outgoing-args -c print.c -o print.o print.c:279:8: warning: return type defaults to ‘int’ [-Wreturn-type] print.c: In function ‘_PoolCatPrint’: print.c:417:1: error: unrecognizable insn: (insn 17 16 18 3 (set (plus:DI (reg:DI 64) (const_int 24 [0x18])) (reg/v/f:DI 60 [ args ])) print.c:414 -1 (nil)) print.c:417:1: internal compiler error: in extract_insn, at recog.c:2123 Please submit a full bug report, with preprocessed source if appropriate. See <http://bugzilla.redhat.com/bugzilla> for instructions. Preprocessed source stored into /tmp/cc7nYjwC.out file, please attach this to your bugreport. Version-Release number of selected component (if applicable): eddie:~/devel/github.com/gnu-efi-3.0$ gcc --version gcc (GCC) 4.7.2 20121001 (Red Hat 4.7.2-3) Copyright (C) 2012 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. eddie:~/devel/github.com/gnu-efi-3.0$ rpm -q gcc gcc-4.7.2-3.fc18.x86_64 How reproducible: Seems to be some interaction between va_copy() + __attribute__((ms_abi)). If I (incorrectly) remove EFIAPI (which is #defined to that attribute) from some of the related functions, I merely get (correct) type errors.
Created attachment 636198 [details] Output of compilation with -fdump-rtl-all .
Reproducible with: #include <stdio.h> #include <stdarg.h> struct foo { char *fmt; va_list args; }; int __attribute__((ms_abi)) very_unfortunate(struct foo *foo) { return vprintf(foo->fmt, foo->args); } int __attribute__((ms_abi)) unfortunate(char *fmt, va_list args) { struct foo foo; int rc; foo.fmt = fmt; va_copy(foo.args, args); rc = very_unfortunate(&foo); va_end(foo.args); return rc; }
I believe that is a user error, for stdarg in ms_abi functions when compilation is non-ms_abi by default (or vice versa) you should be using cross-stdarg.h header instead, and ms_va_list or sysv_va_list type and __ms_va* resp. __sysv_va* depending on which va_list kind do you need. Note that the two are incompatible, so if you say use the ms va_list, then you can't pass that to vprintf if that expects sysv va_list. CCing Kai who authored all this.
yes, this is invalid code. you can't mix ms_abi va_list with gnu-style one. you need to use here types provided by cross-stdarg.h header. But of course be aware that "vprintf" has host's default abi.
Even if it's invalid code, an ICE is not the way to present that to the user. The compiler needs to generate a suitable error message.
This message is a reminder that Fedora 18 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 18. 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 WONTFIX if it remains open with a Fedora 'version' of '18'. 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 prior to Fedora 18's end of life. Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 18 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 to Fedora 18's end of life. 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 18 changed to end-of-life (EOL) status on 2014-01-14. Fedora 18 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.
Still happening in Fedora 22.
This is related to GCC PR#50818. We are also seeing this problem when building OpenSSL as part of the TianoCore UEFI implementation. Public functions in UEFI are marked with 'EFIAPI'; i.e. __attribute__((ms_abi)). Internal functions can use whatever the default ABI of the compiler is. Which *might* be the MS ABI for some build environments, and might be the SYSV ABI. We have no way, in the general case, to ensure that our VA_LIST macro does the right thing. It looks like GCC makes an *attempt* to get this right according to the ABI of the function it happens to be compiling at the time — I can see calls to targetm.fn_abi_va_list() in stabilize_va_list_loc() for example, which looks like it's trying to do what we need. But that particular case fails because it *only* calls the fn_abi_va_list() method when the canonical_va_list_type() method returns NULL. Which it doesn't. So this really does look like a bug, rather than a missing feature. And it *ought* to be considered a bug, because there's no way in the general case that the source code can manually use the appropriate __builtin_{sysv,ms}_va_list based on whether the particular function it's invoked in is EFIAPI or not. And it's *certainly* a bug when the failure mode is an ICE, as Jeff noted 2½ years ago!
Still present gcc-5.3.1-2.fc23.x86_64 as well as current mainline.
Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 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.