User account creation filtered due to spam.

Bug 22297 - [4.3/4.4/4.5/4.6 Regression] missing uninitialized warning (builtin functions)
Summary: [4.3/4.4/4.5/4.6 Regression] missing uninitialized warning (builtin functions)
Alias: None
Product: gcc
Classification: Unclassified
Component: c (show other bugs)
Version: 4.1.0
: P5 minor
Target Milestone: 4.6.0
Assignee: Not yet assigned to anyone
Keywords: diagnostic
Depends on:
Blocks: Wuninitialized
  Show dependency treegraph
Reported: 2005-07-04 20:31 UTC by Andrew Pinski
Modified: 2011-01-19 21:40 UTC (History)
3 users (show)

See Also:
Known to work: 4.6.0
Known to fail: 4.0.4
Last reconfirmed: 2009-02-06 15:46:39


Note You need to log in before you can comment on or make changes to this bug.
Description Andrew Pinski 2005-07-04 20:31:08 UTC
Take the following code (useless example but just shows the problem, there are other testcase which 
show the problem too which less useless):
#include <string.h>
int g(char *);
int f(void)
  char *s;
  return g(s);
Comment 1 Andrew Pinski 2005-07-04 20:46:35 UTC
The patch here fixes one issue: <>.

But the next problem is located in the front-end:
#0  default_function_array_conversion (exp={value = 0x41da9f00, original_code = ERROR_MARK}) at /
#1  0x000b8ae4 in c_parser_expression_conv (parser=0x41d9e0c0) at /Users/pinskia/src/cool/gcc/
#2  0x000b3898 in c_parser_statement_after_labels (parser=0x41d9e0c0) at /Users/pinskia/src/cool/
#3  0x000b2ee4 in c_parser_compound_statement_nostart (parser=0x41d9e0c0) at /Users/pinskia/
#4  0x000b2a58 in c_parser_compound_statement (parser=0x41d9e0c0) at /Users/pinskia/src/cool/
#5  0x000ae994 in c_parser_declaration_or_fndef (parser=0x41d9e0c0, fndef_ok=1 '\001', 
empty_ok=1 '\001', nested=0 '\0', start_attr_ok=1 '\001') at /Users/pinskia/src/cool/gcc/gcc/c-
Comment 2 Andrew Pinski 2005-08-05 04:10:48 UTC
Comment 3 Mark Mitchell 2005-10-31 04:02:10 UTC
The patch in Comment #1 has been applied.

Andrew, what is your point about the C++ front-end?  What is it you think is wrong?

In any case, this will never be release critical.
Comment 4 Andrew Pinski 2005-10-31 04:13:41 UTC
(In reply to comment #3)
> Andrew, what is your point about the C++ front-end?  What is it you think is
> wrong?
There is no mention of the C++ front-end here at all.
Comment 5 Gabriel Dos Reis 2007-01-18 11:43:43 UTC
nnot release critical for GCC-4.0.x
Comment 6 Joseph S. Myers 2008-07-04 19:57:03 UTC
Closing 4.1 branch.
Comment 7 Manuel López-Ibáñez 2009-02-06 15:46:39 UTC
Still fails in GCC 4.4. My understanding is that this code in fold_builtin_n 

  if (ret)
      ret = build1 (NOP_EXPR, TREE_TYPE (ret), ret);
=>    TREE_NO_WARNING (ret) = 1;
      return ret;

creates a NOP(s), where the NOP tree is marked nowarning. Then, at some moment later, the nowarning is copied to the tree corresponding to s. In my opinion, this is the bug: the nowarning bit should not pass to s.
Comment 8 Joseph S. Myers 2009-03-31 18:50:03 UTC
Closing 4.2 branch.
Comment 9 Richard Biener 2009-08-04 12:26:26 UTC
GCC 4.3.4 is being released, adjusting target milestone.
Comment 10 Richard Biener 2010-05-22 18:10:31 UTC
GCC 4.3.5 is being released, adjusting target milestone.
Comment 11 Nicola Pero 2011-01-19 21:40:14 UTC
This works for me with GCC 4.6.0 --

[nicola@lampone ~]$ cat x.c
#include <string.h>

int g(char *);
int f(void)
  char *s;
  return g(s);
[nicola@lampone ~]$ gcc x.c -Wall -c -O2
x.c: In function ‘f’:
x.c:8:3: warning: ‘s’ is used uninitialized in this function [-Wuninitialized]
[nicola@lampone ~]$

The same doesn't work with GCC 4.1.2, where the same gcc command generates
no warnings at all.

So it looks like the problem has been fixed :-)