[gcc/devel/rust/master] Add a test regular variadic functions errors

[Thomas Schwinge via Gcc-cvs]

https://gcc.gnu.org/g:0f9752e4b23cab42709824ca8f504b0dcd941c10

commit 0f9752e4b23cab42709824ca8f504b0dcd941c10
Author: Pierre-Emmanuel Patry 
Date:   Mon Nov 20 11:37:12 2023 +0100

Add a test regular variadic functions errors

Add a new regression test for the error message in regular function
variadic errors during ast validation pass.

gcc/testsuite/ChangeLog:

* rust/compile/non_foreign_variadic_function.rs: New test.

Signed-off-by: Pierre-Emmanuel Patry 

Diff:
---
 gcc/testsuite/rust/compile/non_foreign_variadic_function.rs | 4 
 1 file changed, 4 insertions(+)

diff --git a/gcc/testsuite/rust/compile/non_foreign_variadic_function.rs 
b/gcc/testsuite/rust/compile/non_foreign_variadic_function.rs
new file mode 100644
index ..2a4d3090a66b
--- /dev/null
+++ b/gcc/testsuite/rust/compile/non_foreign_variadic_function.rs
@@ -0,0 +1,4 @@
+pub fn toto(a: i32, ...) {}
+// { dg-error "only foreign or .unsafe extern .C.. functions may be 
C-variadic" "" { target *-*-* } .-1 }
+
+fn main() {}

[gcc/devel/rust/master] Parse variadic functions

[Thomas Schwinge via Gcc-cvs]

https://gcc.gnu.org/g:afb8e75e08526cdde7a513a56050046dc0ba0368

commit afb8e75e08526cdde7a513a56050046dc0ba0368
Author: Pierre-Emmanuel Patry 
Date:   Wed Oct 18 14:31:53 2023 +0200

Parse variadic functions

Variadic functions were not parsed because it is an unstable feature.
While it is still unstable, it is required in order to parse libcore.

gcc/rust/ChangeLog:

* parse/rust-parse-impl.h (Parser::parse_function_param): Parse
variadic functions.

Signed-off-by: Pierre-Emmanuel Patry 

Diff:
---
 gcc/rust/parse/rust-parse-impl.h | 30 +++---
 1 file changed, 23 insertions(+), 7 deletions(-)

diff --git a/gcc/rust/parse/rust-parse-impl.h b/gcc/rust/parse/rust-parse-impl.h
index d509cdf5045f..5fce140ad0a9 100644
--- a/gcc/rust/parse/rust-parse-impl.h
+++ b/gcc/rust/parse/rust-parse-impl.h
@@ -3584,6 +3584,13 @@ Parser::parse_function_param ()
 
   // TODO: should saved location be at start of outer attributes or pattern?
   location_t locus = lexer.peek_token ()->get_locus ();
+
+  if (lexer.peek_token ()->get_id () == ELLIPSIS) // Unnamed variadic
+{
+  lexer.skip_token (); // Skip ellipsis
+  return AST::FunctionParam (std::move (outer_attrs), locus);
+}
+
   std::unique_ptr param_pattern = parse_pattern ();
 
   // create error function param if it doesn't exist
@@ -3599,15 +3606,24 @@ Parser::parse_function_param ()
   return AST::FunctionParam::create_error ();
 }
 
-  std::unique_ptr param_type = parse_type ();
-  if (param_type == nullptr)
+  if (lexer.peek_token ()->get_id () == ELLIPSIS) // Named variadic
 {
-  // skip?
-  return AST::FunctionParam::create_error ();
+  lexer.skip_token (); // Skip ellipsis
+  return AST::FunctionParam (std::move (param_pattern),
+std::move (outer_attrs), locus);
+}
+  else
+{
+  std::unique_ptr param_type = parse_type ();
+  if (param_type == nullptr)
+   {
+ // skip?
+ return AST::FunctionParam::create_error ();
+   }
+  return AST::FunctionParam (std::move (param_pattern),
+std::move (param_type),
+std::move (outer_attrs), locus);
 }
-
-  return AST::FunctionParam (std::move (param_pattern), std::move (param_type),
-std::move (outer_attrs), locus);
 }
 
 /* Parses a function or method return type syntactical construction. Also

[COMMITTED 022/101] gccrs: Add a test regular variadic functions errors

[arthur . cohen]

From: Pierre-Emmanuel Patry 

Add a new regression test for the error message in regular function
variadic errors during ast validation pass.

gcc/testsuite/ChangeLog:

* rust/compile/non_foreign_variadic_function.rs: New test.

Signed-off-by: Pierre-Emmanuel Patry 
---
 gcc/testsuite/rust/compile/non_foreign_variadic_function.rs | 4 
 1 file changed, 4 insertions(+)
 create mode 100644 gcc/testsuite/rust/compile/non_foreign_variadic_function.rs

diff --git a/gcc/testsuite/rust/compile/non_foreign_variadic_function.rs 
b/gcc/testsuite/rust/compile/non_foreign_variadic_function.rs
new file mode 100644
index 000..2a4d3090a66
--- /dev/null
+++ b/gcc/testsuite/rust/compile/non_foreign_variadic_function.rs
@@ -0,0 +1,4 @@
+pub fn toto(a: i32, ...) {}
+// { dg-error "only foreign or .unsafe extern .C.. functions may be 
C-variadic" "" { target *-*-* } .-1 }
+
+fn main() {}
-- 
2.42.1

[COMMITTED 022/101] gccrs: Add a test regular variadic functions errors

[arthur . cohen]

From: Pierre-Emmanuel Patry 

Add a new regression test for the error message in regular function
variadic errors during ast validation pass.

gcc/testsuite/ChangeLog:

* rust/compile/non_foreign_variadic_function.rs: New test.

Signed-off-by: Pierre-Emmanuel Patry 
---
 gcc/testsuite/rust/compile/non_foreign_variadic_function.rs | 4 
 1 file changed, 4 insertions(+)
 create mode 100644 gcc/testsuite/rust/compile/non_foreign_variadic_function.rs

diff --git a/gcc/testsuite/rust/compile/non_foreign_variadic_function.rs 
b/gcc/testsuite/rust/compile/non_foreign_variadic_function.rs
new file mode 100644
index 000..2a4d3090a66
--- /dev/null
+++ b/gcc/testsuite/rust/compile/non_foreign_variadic_function.rs
@@ -0,0 +1,4 @@
+pub fn toto(a: i32, ...) {}
+// { dg-error "only foreign or .unsafe extern .C.. functions may be 
C-variadic" "" { target *-*-* } .-1 }
+
+fn main() {}
-- 
2.42.1

[Bug target/79364] some variadic functions with an empty struct miscompiled with C++ (at least for x64 targets)

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79364

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |8.0
 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #6 from Andrew Pinski  ---
Fixed via PR 60336.

Re: No-named-argument variadic functions

[Joseph Myers]

On Thu, 20 Oct 2022, Richard Biener via Gcc wrote:

> > 1. How should (...) be represented differently from unprototyped functions
> > so that stdarg_p and prototype_p handle it properly?  Should I add a new
> > language-independent type flag (there are plenty spare) to use for this?
> 
> I'd say unprototyped should stay with a NULL TYPE_ARG_TYPES but
> a varargs function might change to have a TREE_LIST with a NULL type
> as the trailing element?  Not sure if we want to change this also for
> varargs functions with actual arguments.
> 
> If we want to go down the route with a flag on the function type then
> I'd rather flag the unprototyped case and leave varargs without any
> actual arguments as NULL TYPE_ARG_TYPES?

The issue with both of those options is that they don't seem very safe for 
code that accesses TYPE_ARG_TYPES directly, of which I think we have a 
lot.  Such code is quite likely to fall over on a TREE_LIST with a NULL 
type entry, and having code that encounters a (...) prototype treat it 
like an unprototyped function seems safer than having code that encounters 
an unprototyped function treat it like a (...) prototype because the code 
that created the function type failed to set a flag to say it's 
unprototyped.

(In principle TYPE_ARG_TYPES could change to have static type other than 
tree, with explicit flags both for stdarg_p and for prototype_p, which 
would provide GCC-build-time assurance that there's no non-updated code 
left that expects an old representation.  But that would be a very large 
change.)

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: No-named-argument variadic functions

[Richard Biener via Gcc]

On Thu, Oct 20, 2022 at 1:54 AM Joseph Myers  wrote:
>
> C2x allows variable-argument functions declared with (...) as parameters -
> no named arguments - as in C++.  It *also* allows such functions to access
> their parameters, unlike C++, by relaxing the requirements on va_start so
> it no longer needs to be passed the name of the last named parameter.
>
> My assumption is that such functions should thus use the ABI for
> variable-argument functions, to the extent that's different from that for
> other functions.  The main implementation issue I see is that GCC's
> internal representation for function types can't actually distinguish the
> (...) type from an unprototyped function - C++ functions with (...)
> arguments are treated by the middle end and back ends as unprototyped.
> (This probably works sufficiently well in ABI terms when the function
> can't actually use its arguments.  Back ends may well call what they think
> are unprototyped functions in a way compatible with variadic callees
> anyway, for compatibility with pre-standard C code that calls e.g. printf
> without a prototype, even though standard C has never allowed calling
> variable-argument functions without a prototype.)
>
> So there are a few questions here for implementing this C2x feature:
>
> 1. How should (...) be represented differently from unprototyped functions
> so that stdarg_p and prototype_p handle it properly?  Should I add a new
> language-independent type flag (there are plenty spare) to use for this?

I'd say unprototyped should stay with a NULL TYPE_ARG_TYPES but
a varargs function might change to have a TREE_LIST with a NULL type
as the trailing element?  Not sure if we want to change this also for
varargs functions with actual arguments.

If we want to go down the route with a flag on the function type then
I'd rather flag the unprototyped case and leave varargs without any
actual arguments as NULL TYPE_ARG_TYPES?

> 2. Does anyone see any likely ABI or back end issues from allowing
> single-argument calls to __builtin_va_start to access the arguments to
> such a function?  (I'd propose to redefine va_start in stdarg.h to use a
> single-argument call, discarding any subsequent arguments, only for C2x.)
>
> 3. Should the C++ front end be changed to mark (...) functions in whatever
> way is chosen for question 1 above, so that they start using the
> appropriate ABI (and, in particular, calls between C and C++, where a C
> implementation of such a function might use the arguments, work properly)?
> Or would there be problems with compatibility with existing callers or
> callees assuming the unprototyped function ABI?
>
> --
> Joseph S. Myers
> jos...@codesourcery.com

No-named-argument variadic functions

[Joseph Myers]

C2x allows variable-argument functions declared with (...) as parameters - 
no named arguments - as in C++.  It *also* allows such functions to access 
their parameters, unlike C++, by relaxing the requirements on va_start so 
it no longer needs to be passed the name of the last named parameter.

My assumption is that such functions should thus use the ABI for 
variable-argument functions, to the extent that's different from that for 
other functions.  The main implementation issue I see is that GCC's 
internal representation for function types can't actually distinguish the 
(...) type from an unprototyped function - C++ functions with (...) 
arguments are treated by the middle end and back ends as unprototyped.  
(This probably works sufficiently well in ABI terms when the function 
can't actually use its arguments.  Back ends may well call what they think 
are unprototyped functions in a way compatible with variadic callees 
anyway, for compatibility with pre-standard C code that calls e.g. printf 
without a prototype, even though standard C has never allowed calling 
variable-argument functions without a prototype.)

So there are a few questions here for implementing this C2x feature:

1. How should (...) be represented differently from unprototyped functions 
so that stdarg_p and prototype_p handle it properly?  Should I add a new 
language-independent type flag (there are plenty spare) to use for this?

2. Does anyone see any likely ABI or back end issues from allowing 
single-argument calls to __builtin_va_start to access the arguments to 
such a function?  (I'd propose to redefine va_start in stdarg.h to use a 
single-argument call, discarding any subsequent arguments, only for C2x.)

3. Should the C++ front end be changed to mark (...) functions in whatever 
way is chosen for question 1 above, so that they start using the 
appropriate ABI (and, in particular, calls between C and C++, where a C 
implementation of such a function might use the arguments, work properly)?  
Or would there be problems with compatibility with existing callers or 
callees assuming the unprototyped function ABI?

-- 
Joseph S. Myers
jos...@codesourcery.com

[Bug c/103810] -fallow-parameterless-variadic-functions flag could use a testcase that covers its documentation better

[egallager at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103810

--- Comment #2 from Eric Gallager  ---
(In reply to jos...@codesourcery.com from comment #1)
> Note also that there is a proposal for C23 (N2854) to allow such 
> functions, including changing the requirements on va_start to make it 
> possible to read their arguments.

OK, but even if it becomes accepted as standard C in C23, I'm assuming the flag
would still stick around for previous standards?

[Bug c/103810] -fallow-parameterless-variadic-functions flag could use a testcase that covers its documentation better

[joseph at codesourcery dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103810

--- Comment #1 from joseph at codesourcery dot com  ---
Note also that there is a proposal for C23 (N2854) to allow such 
functions, including changing the requirements on va_start to make it 
possible to read their arguments.

[Bug c/103810] New: -fallow-parameterless-variadic-functions flag could use a testcase that covers its documentation better

[egallager at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103810

Bug ID: 103810
   Summary: -fallow-parameterless-variadic-functions flag could
use a testcase that covers its documentation better
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: documentation
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: egallager at gcc dot gnu.org
CC: gingold at adacore dot com
  Target Milestone: ---

So, I'm giving the GCC docs another read-through, and the
-fallow-parameterless-variadic-functions docs say:

"Accept variadic functions without named parameters. Although it is possible to
define such a function, this is not very useful as it is not possible to read
the arguments. This is only supported for C as this construct is allowed by
C++."

However, looking in the testsuite for where this flag is actually tested, I
only find gcc/testsuite/gcc.dg/va-arg-5.c which only has a single declaration
of the kind allowed by the flag. If the docs are correct that it is possible to
define such a function, and not just declare it, shouldn't there be a test for
a function definition to go with the declaration? Also, what are you supposed
to do with such a declaration/definition after you have it, if you can't read
the arguments? You can still call it even if you can't read the arguments,
can't you? Shouldn't the testcase test calling it, too, then?

(cc-ing person who added the option)

[Bug target/79364] some variadic functions with an empty struct miscompiled with C++ (at least for x64 targets)

[egallager at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79364

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=69846,
   ||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=52154

--- Comment #5 from Eric Gallager  ---
(In reply to Guillaume Knispel from comment #4)
> The dup seems to be 69846
> This might also be vaguely related to 52154

Adding "bug" before the numbers will get bugzilla to auto-link them for you:
bug 69846
bug 52154

(In reply to Guillaume Knispel from comment #2)
> Note: I hit that bug after cleaning some real code after a cppcheck static
> analysis. 

What did the cppcheck output look like?

[Bug target/79364] some variadic functions with an empty struct miscompiled with C++ (at least for x64 targets)

[xilun0 at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79364

--- Comment #4 from Guillaume Knispel  ---
The dup seems to be 69846
This might also be vaguely related to 52154

[Bug target/79364] some variadic functions with an empty struct miscompiled with C++ (at least for x64 targets)

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79364

Richard Biener  changed:

   What|Removed |Added

   Keywords||ABI

--- Comment #3 from Richard Biener  ---
Yep, there's a dup for this but I think it may have been fixed (under an
option?)

[Bug target/79364] some variadic functions with an empty struct miscompiled with C++ (at least for x64 targets)

[xilun0 at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79364

--- Comment #2 from Guillaume Knispel  ---
Note: I hit that bug after cleaning some real code after a cppcheck static
analysis. The original code sometimes had "..." after references, which is
technically forbidden (but seems to work with g++, for now)
One of the "natural" ways to avoid this theoretical UB (... after a ref) is to
create an allowed type just to prefix the ... in those cases. Technically, an
empty struct seems to be allowed by the standard, so it's a good candidate.
After I got some additional crashes following that change and traced back their
origin to it, I switched my vatag type to typedef void* in order to workaround
that compiler bug.

[Bug target/79364] some variadic functions with an empty struct miscompiled with C++ (at least for x64 targets)

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79364

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||wrong-code

--- Comment #1 from Andrew Pinski  ---
I thought there was another bug filed for this.  Basically x86_64 back-end is
treating this empty struct incorrectly.  In the case of C++, empty struct
sizeof cannot be 0 so it is 1.  But GNU C defines the sizeof of an empty struct
to be 0.  There is some confusion in either the calleer or callee part of
argument passing.

[Bug c++/79364] New: some variadic functions miscompiled (at least for x64 targets)

[xilun0 at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79364

Bug ID: 79364
   Summary: some variadic functions miscompiled (at least for x64
targets)
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: xilun0 at gmail dot com
  Target Milestone: ---

Hello,

G++ miscompiles the following program at least for x64, at least from gcc 4.7
to 7.0 20170115
Compiling with or without O2 changes the observed behavior (segfault or
garbage) but the program is miscompiled in both cases.
gcc seems to compile the corresponding C program correctly.

The expected output is: 1 2 3 4 5 6 coucou
The actual "output" is a segfault or some garbage instead of "coucou"

Cheers!



#include 
#include 
struct vatag {};
void tst(vatag tag, ...)
{
int i;
va_list ap;
va_start(ap, tag);
#define P_INT i = va_arg(ap, int); printf("%i ", i);
P_INT P_INT P_INT P_INT P_INT P_INT
const char* s = va_arg(ap, char*); printf("%s\n", s);
va_end(ap);
}
int main(void)
{
tst(vatag{}, 1, 2, 3, 4, 5, 6, "coucou");
}

[PATCH 2/3] [D] libiberty: Fix demangling of D-style variadic functions

[Iain Buclaw]

This one fixes support for D-style variadic functions, specifically
where non-variadic parameters can be omitted entirely.

Iain
---
libiberty/

 2016-01-26  Iain Buclaw  <ibuc...@gdcproject.org>
 
	* d-demangle.c (dlang_function_args): Append ',' for variadic functions
	only if parameters were seen before the elipsis symbol.
	* testsuite/d-demangle-expected: Add coverage test for parameter-less
	variadic functions.

diff --git a/libiberty/d-demangle.c b/libiberty/d-demangle.c
index 9c4d459..9e5a8043 100644
--- a/libiberty/d-demangle.c
+++ b/libiberty/d-demangle.c
@@ -399,7 +399,9 @@ dlang_function_args (string *decl, const char *mangled)
 	  return mangled;
 	case 'Y': /* (variadic T t, ...) style.  */
 	  mangled++;
-	  string_append (decl, ", ...");
+	  if (n != 0)
+	string_append (decl, ", ");
+	  string_append (decl, "...");
 	  return mangled;
 	case 'Z': /* Normal function.  */
 	  mangled++;
diff --git a/libiberty/testsuite/d-demangle-expected b/libiberty/testsuite/d-demangle-expected
index 11785f2..8f0b167 100644
--- a/libiberty/testsuite/d-demangle-expected
+++ b/libiberty/testsuite/d-demangle-expected
@@ -342,6 +342,10 @@ _D8demangle4testFaaYv
 demangle.test(char, char, ...)
 #
 --format=dlang
+_D8demangle4testFYv
+demangle.test(...)
+#
+--format=dlang
 _D8demangle4testFaaZv
 demangle.test(char, char)
 #

Re: [PATCH 2/3] [D] libiberty: Fix demangling of D-style variadic functions

[Ian Lance Taylor]

On Tue, Jan 26, 2016 at 4:36 PM, Iain Buclaw <ibuc...@gdcproject.org> wrote:
> This one fixes support for D-style variadic functions, specifically
> where non-variadic parameters can be omitted entirely.

This is OK.

Thanks.

Ian

[C PATCH] Warn about variadic functions defined without prototypes (PR c/68024)

[Marek Polacek]

Joseph, is this what you had in mind in this PR?  With this patch, we
warn anytime we see a prototype-less function that is variadic.  It
seems rare enough not to warrant a separate warning option for it.

Bootstrapped/regtested on x86_64-linux, ok for trunk?

2015-10-21  Marek Polacek  

PR c/68024
* c-decl.c (start_function): Warn about vararg functions without
a prototype.

* gcc.dg/pr68024.c: New test.

diff --git gcc/c/c-decl.c gcc/c/c-decl.c
index ce8406a..4a0e090 100644
--- gcc/c/c-decl.c
+++ gcc/c/c-decl.c
@@ -8328,6 +8328,12 @@ start_function (struct c_declspecs *declspecs, struct 
c_declarator *declarator,
  && comptypes (TREE_TYPE (TREE_TYPE (decl1)),
TREE_TYPE (TREE_TYPE (old_decl
{
+ if (stdarg_p (TREE_TYPE (old_decl)))
+   {
+ warning_at (loc, 0, "%q+D defined as variadic function "
+ "without prototype", decl1);
+ locate_old_decl (old_decl);
+   }
  TREE_TYPE (decl1) = composite_type (TREE_TYPE (old_decl),
  TREE_TYPE (decl1));
  current_function_prototype_locus = DECL_SOURCE_LOCATION (old_decl);
diff --git gcc/testsuite/gcc.dg/pr68024.c gcc/testsuite/gcc.dg/pr68024.c
index e69de29..a750917 100644
--- gcc/testsuite/gcc.dg/pr68024.c
+++ gcc/testsuite/gcc.dg/pr68024.c
@@ -0,0 +1,5 @@
+/* PR c/68024 */
+/* { dg-do compile } */
+
+void f (int, ...);
+void f (a) int a; {} /* { dg-warning "defined as variadic function without 
prototype" } */

Marek

[Bug c/68024] Diagnose variadic functions defined without prototypes

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68024

Marek Polacek  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org

Re: [C PATCH] Warn about variadic functions defined without prototypes (PR c/68024)

[Joseph Myers]

On Wed, 21 Oct 2015, Marek Polacek wrote:

> Joseph, is this what you had in mind in this PR?  With this patch, we
> warn anytime we see a prototype-less function that is variadic.  It
> seems rare enough not to warrant a separate warning option for it.
> 
> Bootstrapped/regtested on x86_64-linux, ok for trunk?

OK.

-- 
Joseph S. Myers
jos...@codesourcery.com

[Bug c/68024] Diagnose variadic functions defined without prototypes

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68024

--- Comment #2 from Marek Polacek  ---
Author: mpolacek
Date: Wed Oct 21 17:30:20 2015
New Revision: 229131

URL: https://gcc.gnu.org/viewcvs?rev=229131=gcc=rev
Log:
PR c/68024
* c-decl.c (start_function): Warn about vararg functions without
a prototype.

* gcc.dg/pr68024.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr68024.c
Modified:
trunk/gcc/c/ChangeLog
trunk/gcc/c/c-decl.c
trunk/gcc/testsuite/ChangeLog

[Bug c/68024] Diagnose variadic functions defined without prototypes

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68024

Marek Polacek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from Marek Polacek  ---
Fixed.

[Bug c/68024] Diagnose variadic functions defined without prototypes

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68024

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-10-20
 CC||mpolacek at gcc dot gnu.org
   Target Milestone|--- |6.0
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Confirmed.

[Bug c/68024] New: Diagnose variadic functions defined without prototypes

[jsm28 at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68024

Bug ID: 68024
   Summary: Diagnose variadic functions defined without prototypes
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jsm28 at gcc dot gnu.org
  Target Milestone: ---

As a quality-of-implementation-issue, we should diagnose code such as:

void f (int, ...);
void f (a) int a; {}

which defines a variadic function without using "...".

The types are compatible as defined by ISO C (see C11 6.7.6.3#15), so no
diagnostic is required.  However, this case is explicitly undefined behavior
(C11 6.9.1#8: "If a function that accepts a variable number of arguments is
defined without a parameter type list that ends with the ellipsis notation, the
behavior is undefined."; likewise back to C90).  So it is valid to reject it
(this is undefined behavior as a property of a program, not of a particular
execution of a program), and certainly seems a good idea at least to give a
diagnostic.

This showed up with such a (declaration, definition) pair in glibc only being
diagnosed after converting the definition from K style to prototype-style.

[Bug c/61898] Variadic functions accept va_list without warning

[andi-gcc at firstfloor dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61898

--- Comment #4 from Andi Kleen andi-gcc at firstfloor dot org ---
The patch has several issues (making it  currently fail bootstrap):
- it warns for vfprintf too (fixed)
- on i386 it gets confused between va_list * and char *, so something like

char *format;
char buf[100];

printf(format, buf)

warns too because the underlying types are the same.
Not sure about a good solution for this, need a new type attribute?

[Bug c/61898] Variadic functions accept va_list without warning

[andi-gcc at firstfloor dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61898

Andi Kleen andi-gcc at firstfloor dot org changed:

   What|Removed |Added

 CC||andi-gcc at firstfloor dot org

--- Comment #3 from Andi Kleen andi-gcc at firstfloor dot org ---
Created attachment 33633
  -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33633action=edit
Proposed patch

This patch implements the warning for the non constant format case.

Not done for passing va_list to a real format, but I assume that is rare and in
most cases caught by the normal type checking.

Let me know if it works.

[Bug c/61898] Variadic functions accept va_list without warning

[ak at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61898

--- Comment #1 from ak at gcc dot gnu.org ---
I agree such a warning would make sense.

[Bug c/61898] Variadic functions accept va_list without warning

[manu at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61898

Manuel López-Ibáñez manu at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-09-28
 CC||manu at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Manuel López-Ibáñez manu at gcc dot gnu.org ---
It could be added to Wformat or Wformat-security, but we still need someone to
step up and implement it. John, if you think it could be useful for you, why
not contribute an implementation? It is probably not technically difficult, it
just requires some time and perseverance.

See gcc/c-family/c-format.c

[Bug c/61898] New: Variadic functions accept va_list without warning

[jzwinck at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61898

Bug ID: 61898
   Summary: Variadic functions accept va_list without warning
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jzwinck at gmail dot com

This is a type of error I've seen multiple times in production code.  It
typically arises when forwarding variadic arguments to another function, like
so:



#include stdarg.h
#include stdio.h

void printfBadly(const char* fmt, ...)
{
  va_list ap;
  va_start(ap, fmt);
  printf(fmt, ap); // oops, we wanted vprintf
  va_end(ap);
}



GCC 4.9.0 (and 4.7.2) with -Wall -Wextra compiles this program with no
complaint, but it produces undefined behavior.  There are two types of errors
which GCC could check for:

(1) GCC knows how to check printf when the format string is a literal, but
otherwise doesn't seem to check the arguments at all.  Passing a va_list to
printf (or any function with attribute(format(printf))) is almost certainly an
error.  The only conversion specifier that seems usable with a va_list is %p,
and even that is non-portable, unlikely to be useful, and probably not what the
programmer intended.  Related to this, there is also no warning when passing a
struct (by value) to printf, though such code is likely incorrect.

(2) Passing a va_list via variadic arguments is almost never correct.  The
example above used printf when it needed vprintf, but this is a more general
point: a va_list passed anywhere within ellipsis varags is very likely to be a
mistake which results in undefined behavior.  This type of error applies not
only to printf-like functions, but to variadic functions in general.

In either case, a warning would be very useful (with -Wextra at least).

Variadic functions arguments passing

[Umesh Kalappa]

Hi All,

In our private port ,we define function_arg hook  to pass the first
three args in the reg and rest will go to stack.

But for variadic  functions the arguments  need  to  pass  through the stack.

How we can achieve this ?? Any inputs will be appreciate.

Thank you
~Umesh

Re: Variadic functions arguments passing

[Ian Lance Taylor]

On Fri, Apr 25, 2014 at 11:27 AM, Umesh Kalappa
umesh.kalap...@gmail.com wrote:

 In our private port ,we define function_arg hook  to pass the first
 three args in the reg and rest will go to stack.

 But for variadic  functions the arguments  need  to  pass  through the stack.

 How we can achieve this ?? Any inputs will be appreciate.

In INIT_CUMULATIVE_ARGS, which gets the type of the function being
called, set a flag in your CUMULATIVE_ARGS struct, and check it in
FUNCTION_ARG.

Ian

[Bug target/47025] Dead stores in variadic functions not eliminated

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47025

Richard Guenther rguenth at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2011-09-06 
14:08:31 UTC ---
We expand __builtin_va_end as

/* Expand EXP, a call to __builtin_va_end.  */

static rtx
expand_builtin_va_end (tree exp)
{
  tree valist = CALL_EXPR_ARG (exp, 0);

  /* Evaluate for side effects, if needed.  I hate macros that don't
 do that.  */
  if (TREE_SIDE_EFFECTS (valist))
expand_expr (valist, const0_rtx, VOIDmode, EXPAND_NORMAL);

  return const0_rtx;
}

thus, it has no side-effects (apart from those of its argument).  It's
simply dropped...

Attached patch is already applied.

Mine.

[Bug target/47025] Dead stores in variadic functions not eliminated

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47025

Jakub Jelinek jakub at gcc dot gnu.org changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2011-09-06 
15:02:30 UTC ---
Note that the stdarg pass relies on __builtin_va_end not being optimized away
completely, at least by the time that pass is run.  It can be of course
optimized away afterwards.

[Bug target/47025] Dead stores in variadic functions not eliminated

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47025

--- Comment #5 from Richard Guenther rguenth at gcc dot gnu.org 2011-09-06 
15:56:26 UTC ---
Author: rguenth
Date: Tue Sep  6 15:56:20 2011
New Revision: 178601

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=178601
Log:
2011-09-06  Richard Guenther  rguent...@suse.de

PR tree-optimization/47025
* tree-ssa-alias.c (ref_maybe_used_by_call_p_1): BUILT_IN_VA_END
uses nothing.
(call_may_clobber_ref_p_1): BUILT_IN_VA_END is a barrier like
BUILT_IN_FREE.
(stmt_kills_ref_p_1): BUILT_IN_VA_END kills what its argument
definitely points to.
* tree-ssa-structalias.c (find_func_aliases_for_builtin_call):
BUILT_IN_VA_START doesn't let its va_list argument escape.
* tree-ssa-dce.c (propagate_necessity): BUILT_IN_VA_END does
not make any previous stores necessary.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-ssa-alias.c
trunk/gcc/tree-ssa-dce.c
trunk/gcc/tree-ssa-structalias.c

[Bug target/47025] Dead stores in variadic functions not eliminated

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47025

Richard Guenther rguenth at gcc dot gnu.org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.7.0

--- Comment #6 from Richard Guenther rguenth at gcc dot gnu.org 2011-09-06 
15:56:52 UTC ---
Fixed for 4.7.

[Bug c/48731] regression: __attribute__((flatten)) produces error with function calling variadic functions

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48731

--- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2011-04-26 
12:59:33 UTC ---
Author: rguenth
Date: Tue Apr 26 12:59:22 2011
New Revision: 172963

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=172963
Log:
2011-04-26  Richard Guenther  rguent...@suse.de

PR tree-optimization/48731
* ipa-inline.c (cgraph_flatten): Test if function is inlinable.

* gcc.dg/torture/pr48731.c: New testcase.

Added:
branches/gcc-4_6-branch/gcc/testsuite/gcc.dg/torture/pr48731.c
Modified:
branches/gcc-4_6-branch/gcc/ChangeLog
branches/gcc-4_6-branch/gcc/ipa-inline.c
branches/gcc-4_6-branch/gcc/testsuite/ChangeLog

[Bug c/48731] regression: __attribute__((flatten)) produces error with function calling variadic functions

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48731

--- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2011-04-26 
13:00:58 UTC ---
Author: rguenth
Date: Tue Apr 26 13:00:53 2011
New Revision: 172964

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=172964
Log:
2011-04-26  Richard Guenther  rguent...@suse.de

PR tree-optimization/48731
* gcc.dg/torture/pr48731.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr48731.c
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug c/48731] regression: __attribute__((flatten)) produces error with function calling variadic functions

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48731

Richard Guenther rguenth at gcc dot gnu.org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.6.1

--- Comment #4 from Richard Guenther rguenth at gcc dot gnu.org 2011-04-26 
13:01:55 UTC ---
Fixed.

[Bug c/48731] regression: __attribute__((flatten)) produces error with function calling variadic functions

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48731

Richard Guenther rguenth at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2011.04.23 09:13:41
 AssignedTo|unassigned at gcc dot   |rguenth at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1

--- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2011-04-23 
09:13:41 UTC ---
I will have a look.

[Bug c/48731] New: regression: __attribute__((flatten)) produces error with function calling variadic functions

[florent.bruneau_gcc at m4x dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48731

   Summary: regression: __attribute__((flatten)) produces error
with function calling variadic functions
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: florent.bruneau_...@m4x.org


Created attachment 24075
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24075
preprocessed example source

Function with the flatten attribute that call variadic function do not compile
anymore with gcc-4.6. It worked perfectly with gcc-4.5. The attachment provide
a simple example of code.

Compilation flag:
% gcc-4.6 -std=gnu99 --save-temp -O3 -c flatten_variadic.c

Resulting error:
flatten_variadic.c: In function ‘blah2’:
flatten_variadic.c:5:23: error: ‘va_start’ used in function with fixed args

GCC: gcc-4.6 (Debian 4.6.0-4) 4.6.1 20110419 (prerelease)
System: Debian: Linux edelzwicker 2.6.38-2-amd64 #1 SMP Thu Apr 7 04:28:07 UTC
2011 x86_64 GNU/Linux

Variadic functions

[Jonas Bonn]

Hi,
I am forwarding to you a mail that I sent to the uClibc mailing list as
I think it is actually a compiler issue.  Please see below for the
original.  Any tips would be greatly appreciated.
/Jonas

 Forwarded Message 
From: jonas at southpole dot se
To: ucl...@uclibc.org
Subject: Variadic functions
Date: Tue, 08 Jun 2010 09:22:28 +0200

Hi,
I am working on the OPENRISC32 (or32) architecture port of uClibc and
have run into a bit of conundrum that I was hoping someone could help me
understand a bit better.  Please bear with me...

--

The preconditions:

i) The declaration of xdrproc_t is variadic:

typedef bool_t (*xdrproc_t) (XDR *, void *, ...);

ii) In libc/inet/rpc/xdr.c the functions choices-proc, which of type
xdrproc_t is called:

return (*(choices-proc)) (xdrs, unp, LASTUNSIGNED);

iii) choices-proc may be dereferenced to the function
xdr_accepted_reply which is defined in libc/inet/rpc/rpc_prot.c as:

bool_t
xdr_accepted_reply (XDR *xdrs, struct accepted_reply *ar) { ... }

---

Now, the problem:
i)  As xdr_accepted_reply is not defined as variadic, the function is
compiled to find the parameters in registers r3 and r4.
ii)  As choices-proc is variadic (according to the declaration), the
compiler puts the first parameter in a register and the second on on the
stack.

This, of course, becomes problematic!!!

---

Workaround:
i)  By redefining xdr_accepted_reply to be variadic, the compiler makes
the function look for paramter 1 in a register and paramter 2 on the
stack, thus matching what it does for the function call.  Like this...

bool_t
xdr_accepted_reply (XDR *xdrs, struct accepted_reply *ar, ...) { ... }



Questions:
i)  Is my compiler broken?  If so, is there somewhere in GCC that
specifically handles register/stack parameter passing for variadic
functions???  (GCC 4.2, patched for or32)
ii)  What is the correct compiler behaviour variadic
declarations/definitions?  Should xdr_accepted_reply not be variadic
since it is used in such a context?  Note that there are several
functions that are cast to xdrproc_t and none of them are defined as
variadic...
iii)  Any advice on how to proceed... I know I need to patch something,
but I'm not sure if it's GCC,binutils, or uClibc.

Thanks for bearing with me on this.  Regards,
Jonas

Re: Variadic functions

[Ian Lance Taylor]

Jonas Bonn jo...@southpole.se writes:

 I am forwarding to you a mail that I sent to the uClibc mailing list as
 I think it is actually a compiler issue.  Please see below for the
 original.  Any tips would be greatly appreciated.

This message would be more appropriate for the mailing list
gcc-h...@gcc.gnu.org.  Please take any followups to gcc-help.
Thanks.

 i) The declaration of xdrproc_t is variadic:

 typedef bool_t (*xdrproc_t) (XDR *, void *, ...);

 ii) In libc/inet/rpc/xdr.c the functions choices-proc, which of type
 xdrproc_t is called:

 return (*(choices-proc)) (xdrs, unp, LASTUNSIGNED);

 iii) choices-proc may be dereferenced to the function
 xdr_accepted_reply which is defined in libc/inet/rpc/rpc_prot.c as:

 bool_t
 xdr_accepted_reply (XDR *xdrs, struct accepted_reply *ar) { ... }


Casting a function pointer to a different type and then calling it is
undefined behaviour in C/C++.  The standard does not guarantee that
this program will work.


 i)  Is my compiler broken?  If so, is there somewhere in GCC that
 specifically handles register/stack parameter passing for variadic
 functions???  (GCC 4.2, patched for or32)

This problem does not indicate that your program is broken.  Calling
variadic functions is handled specially in the backend.  I am not
familiar with the or32 backend, but that is where the code would be.


 ii)  What is the correct compiler behaviour variadic
 declarations/definitions?  Should xdr_accepted_reply not be variadic
 since it is used in such a context?  Note that there are several
 functions that are cast to xdrproc_t and none of them are defined as
 variadic...

That is broken.  You can not casually cast function pointers to
different types.  You especially can not cast them between variadic
and non-variadic.


 iii)  Any advice on how to proceed... I know I need to patch something,
 but I'm not sure if it's GCC,binutils, or uClibc.

You need to patch the source code.  It sounds like that source code is
in uClibc.

Ian

[Bug libstdc++/37718] Demangling of variadic functions

[jason at gcc dot gnu dot org]

--- Comment #4 from jason at gcc dot gnu dot org  2008-11-14 23:18 ---
Fixed.


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37718

[Bug libstdc++/37718] Demangling of variadic functions

[jan dot kratochvil at redhat dot com]

--- Comment #3 from jan dot kratochvil at redhat dot com  2008-10-07 23:10 
---
FYI I find at least this specific reported testcase as already fixed by Jason:

http://gcc.gnu.org/ml/gcc-patches/2008-09/msg00729.html
http://gcc.gnu.org/ml/gcc-patches/2008-10/msg00189.html

GCC now even produces different mangled names:
GNU C++ (GCC) version 4.4.0 20081007 (experimental) (x86_64-unknown-linux-gnu)
 compiled by GNU C version 4.4.0 20081007 (experimental), GMP version 4.2.2,
MPFR version 2.3.1.

004005c3 w F .text 003f _Z1fIdIiEEiT_DpT0_
00400602 w F .text 0012 _Z1fIiIEEiT_DpT0_ 
00400584 w F .text 003f _Z1fIiIdiEEiT_DpT0_

004005c3 w F .text 003f int fdouble, int(double, int) 
00400602 w F .text 0012 int fint, (int, )
00400584 w F .text 003f int fint, double, int(int,
double, int)


-- 

jan dot kratochvil at redhat dot com changed:

   What|Removed |Added

 CC||jan dot kratochvil at redhat
   ||dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37718

[Bug libstdc++/37718] Demangling of variadic functions

[paolo dot carlini at oracle dot com]

--- Comment #2 from paolo dot carlini at oracle dot com  2008-10-03 10:51 
---
Then, I guess we can just assign to Jason.


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 CC|jason at gcc dot gnu dot org|
 AssignedTo|unassigned at gcc dot gnu   |jason at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-10-03 10:51:58
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37718

[Bug libstdc++/37718] New: Demangling of variadic functions

[jakub at gcc dot gnu dot org]

int f()
{
  return 0;
}

template typename T, typename... U
int f(T t, U... u)
{
  return (t ? 1 : 0) * sizeof...(U) + f(u...);
}

int
main()
{
  return f(1, 1.0, 2);
}

has 3 mangled names, but 2 of them demangle weirdly (I'd say we should demangle
U10__variadic to something containing ..., not __variadic) and one doesn't
demangle at all:

#include cxxabi.h
#include iostream

int
main ()
{
  char buf[128];
  size_t len;
  int status;
  len = sizeof (buf);
  status = 0;
  abi::__cxa_demangle (_Z1fIdiEiT_U10__variadicT0_, buf, len, status);
  std::cout  buf len status  std::endl;
  abi::__cxa_demangle (_Z1fIiEiT_U10__variadicT0_, buf, len, status);
  std::cout  buf len status  std::endl;
  abi::__cxa_demangle (_Z1fIidiEiT_U10__variadicT0_, buf, len, status);
  std::cout  buf len status  std::endl;
}

G++ in all cases mangles the variadic arg as U10__variadicT0_, as the variadic
template parameter is 2nd, but that parameter is never mangled among the I
parameters and so the demangler considers it out of range and refuses to
demangle it.  Not mentioning the parameter packs in the I list IMHO has a
bigger
effect than just having out of range U10__variadic template parameter types.
As for functions the parameter packs don't need to be at the end of template
argument list, we get out of range mangling even for say:
template typename T, typename... U, typename W, typename ... V
int foo (T a, W b)
{
  return a + b;
}

int
bar (void)
{
  return foo (1, 2);
}

_Z3fooIiiEiT_T1_


-- 
   Summary: Demangling of variadic functions
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: ABI
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37718

[Bug libstdc++/37718] Demangling of variadic functions

[jason at redhat dot com]

--- Comment #1 from jason at redhat dot com  2008-10-03 02:27 ---
Subject: Re:   New: Demangling of variadic functions

I've been working on a bunch of mangling/demangling issues lately, this 
among them.

Jason


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37718

[Bug c/26921] New: long long bit fields are passed to variadic functions as longs

[bugzilla at hburch dot com]

When compiled under Linux, at least, gcc 3.2.3 appears to pass a long long bit
field to a variadic function as a long.  In particular, if you say printf
(%lld, s.a), where s.a is a long long bit field, s.a appears to only pass a
long.

The resulting assembly reads (for a 3 bit long long field):
movbfoo, %al
sall$5, %eax
movb%al, %cl
sarb$5, %cl
movsbl  %cl,%eax
cltd
pushl   %eax
pushl   $.LC0
callprintf

I do not believe this is correct behavior for gcc.

With -Wall, the above example generates a warning about the operation:
a.c: In function `main':
a.c:10: warning: long long int format, different type arg (arg 2)

I see similar behavior on gcc 4.0.0 on a Macintosh, but that's based on the
output produced by the executible, since I cannot read it's assembly.

Compiled using: gcc -Wall -v --save-temps a.c


-- 
   Summary: long long bit fields are passed to variadic functions as
longs
   Product: gcc
   Version: 3.2.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bugzilla at hburch dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26921

[Bug c/26921] long long bit fields are passed to variadic functions as longs

[bugzilla at hburch dot com]

--- Comment #1 from bugzilla at hburch dot com  2006-03-29 14:54 ---
Created an attachment (id=11150)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11150action=view)
Bundle for Linux


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26921

[Bug c/26921] long long bit fields are passed to variadic functions as longs

[bugzilla at hburch dot com]

--- Comment #2 from bugzilla at hburch dot com  2006-03-29 14:54 ---
Created an attachment (id=11151)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11151action=view)
Bundle for Mac OS X


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26921

[Bug c/26921] long long bit fields are passed to variadic functions as longs

[bugzilla at hburch dot com]

--- Comment #3 from bugzilla at hburch dot com  2006-03-29 14:59 ---
#include stdio.h

struct s {
long long int a : 33;
};

struct s foo = {0};

int main(void) {
printf (%lld\n, foo.a);
return 0;
}

produces the following output using gcc -Wall -o a a.c for same system as Mac
OS X Bundle (gcc 4.0.0):
gcc -Wall -o a a.c
a.c: In function 'main':
a.c:10: warning: format '%lld' expects type 'long long int', but argument 2 has
type 'long long int'

Attached here because almost assuredly related.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26921

[Bug c/26921] long long bit fields are passed to variadic functions as longs

[pinskia at gcc dot gnu dot org]

--- Comment #4 from pinskia at gcc dot gnu dot org  2006-03-29 19:25 ---
The warning mess has been corrected:
t.c: In function 'main':
t.c:10: warning: format '%lld' expects type 'long long int', but argument 2 has
type 'long long int:33'


This is not a bug, GCC is correct in warning.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26921

[Bug target/16000] for h8 targets variadic functions are not working properly

[bonzini at gnu dot org]

--- Additional Comments From bonzini at gnu dot org  2004-06-15 15:26 ---
Graham is right.  This is a problem in user code, unless this fails as well...

int variadic_test (int, unsigned long, unsigned long);

int main (void)
{
int result_varfunc;
int result_local;

result_local   =  1 + 2 + 3;
result_varfunc =  variadic_test(1, 2, 3);

if (result_local != result_varfunc) {
//printf(error);
return 0;
} else
return 1;
}

Paolo

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16000