A number of options, -mregparm=3 and -mrtd for example, change the calling convention in ways that would be incompatible with normal system header files. These options are thus useless outside of freestanding code. Distinct settings should be available for the app itself and for other stuff. Ideally, "other stuff" would also be split with distinct settings for system headers and for the libgcc-like things that the compiler may itself generate calls to. This would require that gcc distinguish between memcpy used via system header and memcpy used to implement struct copy. For more direct control, perhaps this is reasonable: #include <stdlib.h> __attribute__((regparm(0))) An example showing this unawareness follows: //////////////////////////////////////////////////////// foo 0 $ cat atoi.c #include <stdlib.h> // a SYSTEM header int a2i(const char *s){ return atoi(s); } foo 0 $ gcc -W -Wall -std=gnu99 -m32 -Os -fomit-frame-pointer -S atoi.c foo 0 $ cat atoi.s .file "atoi.c" .text .globl a2i .type a2i, @function a2i: jmp atoi .size a2i, .-a2i .ident "GCC: (GNU) 4.1.1 20060828 (Red Hat 4.1.1-20)" .section .note.GNU-stack,"",@progbits foo 0 $ gcc -W -Wall -std=gnu99 -m32 -Os -fomit-frame-pointer -mregparm=3 -S atoi.c foo 0 $ cat atoi.s .file "atoi.c" .text .globl a2i .type a2i, @function a2i: jmp atoi .size a2i, .-a2i .ident "GCC: (GNU) 4.1.1 20060828 (Red Hat 4.1.1-20)" .section .note.GNU-stack,"",@progbits foo 0 $ gcc -W -Wall -std=gnu99 -m32 -Os -fomit-frame-pointer -mrtd -S atoi.c foo 0 $ cat atoi.s .file "atoi.c" .text .globl a2i .type a2i, @function a2i: jmp atoi .size a2i, .-a2i .ident "GCC: (GNU) 4.1.1 20060828 (Red Hat 4.1.1-20)" .section .note.GNU-stack,"",@progbits foo 0 $
Yes those change the ABI which means don't use them unless you know what you are doing.
(In reply to comment #1) > Yes those change the ABI which means don't use them unless you know what you > are doing. I damn well do know what I want to do, and gcc does not support it. What, you expect me to edit the system header files to add __attribute__((regparm(0))) and such all over the place? This is not practical. Adding __attribute__((regparm(3))) all over the app is not good either. For other reasons, gcc already distinguishes between system header files and non-system header files. If this distinction were used for ABI-related issues, -mregparm=3 and similar would be practical for normal app code. As far as I can tell, that would only leave the problem of callback functions such as the fourth qsort() argument and main(). Probably main() should be handled automatically.
(In reply to comment #2) First you should not be using options that change the ABI if you don't know what you are doing. because they change the ABI. Second, none of options you gave are really options because some people actually use the options correctly in that they want the ABI to change with all the header files and you are no longer doing it correct.
(In reply to comment #3) > (In reply to comment #2) > First you should not be using options that change the ABI if you don't know > what you are doing. because they change the ABI. Second, none of options you > gave are really options because some people actually use the options correctly > in that they want the ABI to change with all the header files and you are no > longer doing it correct. I tend to think that these people are NOT using the options correctly. They should have built their compiler to use a different ABI if that is what the interfaces in their system header files require. Another way to make things work: gcc -mregparm-app=3 ... That is, add new options which change the ABI only for local files. The interfaces declared in the system headers would not be affected. Imagine building gcc itself with regparm 3. You probably don't want to mark up the gcc source to enable this, but marking up the system header files is definitely not an option.
Did you read the documention? Warning: if you use this switch, and num is nonzero, then you must build all modules with the same value, including any libraries. This includes the system libraries and startup modules. Warning: this calling convention is incompatible with the one normally used on Unix, so you cannot use it if you need to call libraries compiled with the Unix compiler.
(In reply to comment #4) > Imagine building gcc itself with regparm 3. You probably don't want > to mark up the gcc source to enable this, but marking up the system > header files is definitely not an option. Or even better letting GCC do it automatically which it already does for local functions and with LTO it can do with functions that don't escape.
(In reply to comment #4) > (In reply to comment #3) > > (In reply to comment #2) > Imagine building gcc itself with regparm 3. You probably don't want > to mark up the gcc source to enable this, but marking up the system > header files is definitely not an option. Actually, om mingw32, the system headers are marked up (explicitly) with calling convention (__cdecl, __stdcall, __fastcall), to avoid the -mrtd problem. So it is an option. I think that MSVC headers also do this. Danny
(In reply to comment #5) > Did you read the documention? > Warning: if you use this switch, and num is nonzero, then you must build all > modules with the same value, including any libraries. This includes the system > libraries and startup modules. > > Warning: this calling convention is incompatible with the one normally used on > Unix, so you cannot use it if you need to call libraries compiled with the Unix > compiler. I sure as heck did read this. It is the problem. Every time I read that, I am annoyed that gcc does not take advantage of the "system headers" concept to make things work OK. The mingw32 example in Comment #7 has a defect. System headers do not always come from one single supplier. On a typical Linux system, there are header files from numerous packages installed in /usr/include. There is no reasonable way to get them all marked up with the ABI. This would be a fine interface: gcc -mregparm-app-only=3 ... (likewise for -mrtd as -mrtd-app-only, etc.)
Why do you think this is a bug? Again the options should not act this way at all, it is a bit crazy to treat system headers different than normal headers. In fact you can get different behavior when you do: #include <stdio.h> and you also have -iquote /usr/include
Andrew, stop closing this bug. If necessary I will ask the SC for a statement preventing you from closing bugs as invalid when the submitter disagrees, since you haven't shown a willingness to listen to what they are saying. I don't think that keying this off system headers would be a good idea - it's very dangerous because of the number of ways it can silently break, e.g. -iquote, manually prototyping a function, callbacks. However, some more general mechanism for setting the default ABI of a header might be useful. I'm thinking something like #pragma GCC visibility here.
> However, some more > general mechanism for setting the default ABI of a header might be useful. I'm > thinking something like #pragma GCC visibility here. Which is PR 15892 by the way.