| Message ID | 20240130001434.35b2b856@nbbrfq.loc |
|---|---|
| State | New |
| Headers | show |
| Series | [stage-1,RFC] : i386: attribute regparm/stdcall and vaargs | expand |
On Tue, 30 Jan 2024, Bernhard Reutner-Fischer via Gcc wrote: > * builtin-attrs.def (ATTR_TM_NOTHROW_RT_LIST): Use ATTR_NOTHROW_LIST > instead of ATTR_TM_NOTHROW_LIST, thus removing ATTR_TM_REGPARM. That doesn't make sense. ATTR_TM_NOTHROW_RT_LIST is specifically a transactional memory attribute list, but you're removing all transactional memory attributes from it. A list without the "*tm regparm" internal attribute would have a different name.
Hi Joseph! On Tue, 30 Jan 2024 14:54:49 +0000 (UTC) Joseph Myers <josmyers@redhat.com> wrote: > On Tue, 30 Jan 2024, Bernhard Reutner-Fischer via Gcc wrote: > > > * builtin-attrs.def (ATTR_TM_NOTHROW_RT_LIST): Use ATTR_NOTHROW_LIST > > instead of ATTR_TM_NOTHROW_LIST, thus removing ATTR_TM_REGPARM. > > That doesn't make sense. ATTR_TM_NOTHROW_RT_LIST is specifically a > transactional memory attribute list, but you're removing all transactional > memory attributes from it. A list without the "*tm regparm" internal > attribute would have a different name. > AFAICS there is no pre-existing attr list with just returns_twice and nothrow. Would ATTR_NOTHROW_RT_LIST be more appropriate as name, and should i move this up to before the format attribute lists, before DEF_FORMAT_ATTRIBUTE? Alternatively, there is an existing ATTR_RT_NOTHROW_LEAF_LIST used by setjmp. But that would add leaf to _ITM_beginTransaction where it was not marked leaf before. Would it be appropriate to use this for _ITM_beginTransaction too, which behaves setjmp()ish AFAICS? thanks
On Fri, 2 Feb 2024, Bernhard Reutner-Fischer via Gcc wrote: > Hi Joseph! > > On Tue, 30 Jan 2024 14:54:49 +0000 (UTC) > Joseph Myers <josmyers@redhat.com> wrote: > > > On Tue, 30 Jan 2024, Bernhard Reutner-Fischer via Gcc wrote: > > > > > * builtin-attrs.def (ATTR_TM_NOTHROW_RT_LIST): Use ATTR_NOTHROW_LIST > > > instead of ATTR_TM_NOTHROW_LIST, thus removing ATTR_TM_REGPARM. > > > > That doesn't make sense. ATTR_TM_NOTHROW_RT_LIST is specifically a > > transactional memory attribute list, but you're removing all transactional > > memory attributes from it. A list without the "*tm regparm" internal > > attribute would have a different name. > > > > AFAICS there is no pre-existing attr list with just returns_twice and > nothrow. Would ATTR_NOTHROW_RT_LIST be more appropriate as name, and > should i move this up to before the format attribute lists, before > DEF_FORMAT_ATTRIBUTE? Yes, both of those seem appropriate for such an attribute list. I do not know what attributes are appropriate for _ITM_beginTransaction.
diff --git a/gcc/builtin-attrs.def b/gcc/builtin-attrs.def index 71f4db1f3da..4813509b9c3 100644 --- a/gcc/builtin-attrs.def +++ b/gcc/builtin-attrs.def @@ -400,7 +400,7 @@ DEF_ATTR_TREE_LIST (ATTR_TM_NORETURN_NOTHROW_LIST, DEF_ATTR_TREE_LIST (ATTR_TM_CONST_NOTHROW_LIST, ATTR_TM_REGPARM, ATTR_NULL, ATTR_CONST_NOTHROW_LIST) DEF_ATTR_TREE_LIST (ATTR_TM_NOTHROW_RT_LIST, - ATTR_RETURNS_TWICE, ATTR_NULL, ATTR_TM_NOTHROW_LIST) + ATTR_RETURNS_TWICE, ATTR_NULL, ATTR_NOTHROW_LIST) /* Same attributes used for BUILT_IN_MALLOC except with TM_PURE thrown in. */ DEF_ATTR_TREE_LIST (ATTR_TMPURE_MALLOC_NOTHROW_LIST, diff --git a/gcc/config/i386/i386-options.cc b/gcc/config/i386/i386-options.cc index 3605c2c53fb..daea2394e1a 100644 --- a/gcc/config/i386/i386-options.cc +++ b/gcc/config/i386/i386-options.cc @@ -3679,6 +3679,12 @@ ix86_handle_cconv_attribute (tree *node, tree name, tree args, int, name, REGPARM_MAX); *no_add_attrs = true; } + else if (FUNC_OR_METHOD_TYPE_P (*node) && stdarg_p (*node)) + { + warning (OPT_Wattributes, "%qE attribute ignored " + "on function with variable number of arguments", name); + *no_add_attrs = true; + } return NULL_TREE; } @@ -3732,6 +3738,12 @@ ix86_handle_cconv_attribute (tree *node, tree name, tree args, int, { error ("stdcall and thiscall attributes are not compatible"); } + if (FUNC_OR_METHOD_TYPE_P (*node) && stdarg_p (*node)) + { + warning (OPT_Wattributes, "%qE attribute ignored " + "on function with variable number of arguments", name); + *no_add_attrs = true; + } } /* Can combine cdecl with regparm and sseregparm. */ @@ -3768,6 +3780,15 @@ ix86_handle_cconv_attribute (tree *node, tree name, tree args, int, error ("cdecl and thiscall attributes are not compatible"); } } + else if (is_attribute_p ("sseregparm", name)) + { + if (FUNC_OR_METHOD_TYPE_P (*node) && stdarg_p (*node)) + { + warning (OPT_Wattributes, "%qE attribute ignored " + "on function with variable number of arguments", name); + *no_add_attrs = true; + } + } /* Can combine sseregparm with all attributes. */ diff --git a/gcc/testsuite/gcc.dg/lto/trans-mem.h b/gcc/testsuite/gcc.dg/lto/trans-mem.h index add5a297b51..a1c97cb28c1 100644 --- a/gcc/testsuite/gcc.dg/lto/trans-mem.h +++ b/gcc/testsuite/gcc.dg/lto/trans-mem.h @@ -14,7 +14,7 @@ # define ITM_REGPARM #endif -ITM_REGPARM noinline uint32_t _ITM_beginTransaction(uint32_t a, ...) { asm(""); } +noinline uint32_t _ITM_beginTransaction(uint32_t a, ...) { asm(""); } ITM_REGPARM noinline void _ITM_commitTransaction (void) { asm(""); } ITM_REGPARM noinline void _ITM_WU4 (void *a, uint32_t b) { asm(""); } ITM_REGPARM noinline void _ITM_WU8 (void *a, uint64_t b) { asm(""); } diff --git a/gcc/testsuite/gcc.target/i386/attributes-error-sse.c b/gcc/testsuite/gcc.target/i386/attributes-error-sse.c new file mode 100644 index 00000000000..dd5381b72c7 --- /dev/null +++ b/gcc/testsuite/gcc.target/i386/attributes-error-sse.c @@ -0,0 +1,7 @@ +/* { dg-do compile } */ +/* { dg-require-effective-target ia32 } */ +/* { dg-require-effective-target sse } */ + +char *foo1(int, ...) __attribute__((sseregparm)); /* { dg-warning "attribute ignored on function with variable number of arguments" } */ +char *foo2(float, ...) __attribute__((sseregparm)); /* { dg-warning "attribute ignored on function with variable number of arguments" } */ + diff --git a/gcc/testsuite/gcc.target/i386/attributes-error.c b/gcc/testsuite/gcc.target/i386/attributes-error.c index 405eda50105..54eaa688bc5 100644 --- a/gcc/testsuite/gcc.target/i386/attributes-error.c +++ b/gcc/testsuite/gcc.target/i386/attributes-error.c @@ -9,4 +9,7 @@ void foo5(int i, int j) __attribute__((stdcall, fastcall)); /* { dg-error "not c void foo6(int i, int j) __attribute__((cdecl, fastcall)); /* { dg-error "not compatible" } */ void foo7(int i, int j) __attribute__((cdecl, stdcall)); /* { dg-error "not compatible" } */ void foo8(int i, int j) __attribute__((regparm(2), fastcall)); /* { dg-error "not compatible" } */ +char *foo9(const char *format, ...) __attribute__((regparm(3),stdcall)); /* { dg-warning "attribute ignored on function with variable number of arguments" } */ +char *foo10(int, ...) __attribute__((regparm(2))); /* { dg-warning "attribute ignored on function with variable number of arguments" } */ +char *foo11(int, ...) __attribute__((stdcall)); /* { dg-warning "attribute ignored on function with variable number of arguments" } */ diff --git a/libitm/libitm.h b/libitm/libitm.h index a361be7df24..a3357f13796 100644 --- a/libitm/libitm.h +++ b/libitm/libitm.h @@ -154,7 +154,7 @@ typedef uint64_t _ITM_transactionId_t; /* Transaction identifier */ extern _ITM_transactionId_t _ITM_getTransactionId(void) ITM_REGPARM; -extern uint32_t _ITM_beginTransaction(uint32_t, ...) ITM_REGPARM; +extern uint32_t _ITM_beginTransaction(uint32_t, ...); extern void _ITM_abortTransaction(_ITM_abortReason) ITM_REGPARM ITM_NORETURN;
[I was torn towards asking gcc@ only, individual i386 maintainers in private or bluntly asking for help on gcc-patches or re-iterate through ABI, so in an attempt to cut off years of latency i hereby ask all and everybody for assistance. Stage4 means any chances are low, i know.. hence stage 1 material since it's not pressing in any foreseeable way] Hello i386 maintainers Recently, elsewhere, there was discussion about attribute regparm (and stdcall) on functions with variable number of arguments in C. Allegedly clang warns about these but GCC does not. I did not look at clang. gcc/doc/extend.texi currently states that: ---8<--- @cindex @code{regparm} function attribute, x86 [] Functions that take a variable number of arguments continue to be passed all of their arguments on the stack. [] @cindex @code{sseregparm} function attribute, x86 [] Functions that take a variable number of arguments continue to pass all of their floating-point arguments on the stack. [] @cindex @code{stdcall} function attribute, x86-32 [] On x86-32 targets, the @code{stdcall} attribute causes the compiler to assume that the called function pops off the stack space used to pass arguments, unless it takes a variable number of arguments. ---8<--- which seems to suggest that all of attribute regparm/sseregparm/stdcall are ignored on functions with variable number of arguments. I.e. the ABI mandates that everything is passed on the stack. [Right? ISTM that this is correct; Didn't follow ABI (tweaks) too closely in the last decade, admittedly.. But i think this still holds. Please correct me if i missed something?] If this is correct, then ISTM that attributes regparm/sseregparm/stdcall should be rejected on functions with variable number of arguments also in GCC. There seems to be (exact) struct function cfun->va_list_[fg]pr_size for the real fpr and gpr save area sizes. But (unfortunately / of course) they are layed out way later than parsing the attributes in both the C++ and C FEs, so using those in ix86_handle_cconv_attribute is not possible as there is no cfun readily available there yet. ²). Hence i would propose to ¹): gcc/ChangeLog: * builtin-attrs.def (ATTR_TM_NOTHROW_RT_LIST): Use ATTR_NOTHROW_LIST instead of ATTR_TM_NOTHROW_LIST, thus removing ATTR_TM_REGPARM. * config/i386/i386-options.cc (ix86_handle_cconv_attribute): Decline regparm, stdcall and regparm attribute on functions with variable number of arguments. libitm/ChangeLog: * libitm.h (_ITM_beginTransaction): Remove ITM_REGPARM. gcc/testsuite/ChangeLog: * gcc.dg/lto/trans-mem.h: Remove ITM_REGPARM. * gcc.target/i386/attributes-error.c: Extend to cover (regparm(3),stdcall) on vaargs functions. * gcc.target/i386/attributes-error-sse.c: New test. ¹) as per attached ²) Unfortunately, the C FE does not readily provide a sensible locus for the attributes in question but points input_location at that spot of the beginning of the declaration of such a function. The C++ FE is a little bit better in this regard: [here i meant to verbatim emphasis discrepancy of the C++ and C FE diagnostics for the abovementioned target tests, striking, isn't it, But see yourselves.] ³) unreferenced, hence implied, where would on do this instead, more helpful?