[Bug c/39646] New: __FILE__ breaks for empty file name

[neil at gcc dot gnu dot org]

GCC rejects the following strictly conforming TU with -pedantic-errors

extern int x;

#line 24 
extern char z[sizeof __FILE__ == 1];


-- 
   Summary: __FILE__ breaks for empty file name
   Product: gcc
   Version: 4.1.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: neil at gcc dot gnu dot org


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

[Bug c/39647] New: Syntax checks in #line not quite right

[neil at gcc dot gnu dot org]

The following is strictly conforming but GCC rejects it.

extern int x;
#define EMPTY()
#line 2 foo.c EMPTY( )


-- 
   Summary: Syntax checks in #line not quite right
   Product: gcc
   Version: 4.1.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: neil at gcc dot gnu dot org


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

[Bug c/38243] New: Restrict constraint violation not an error with -pedantic-errors

[neil at gcc dot gnu dot org]

The following violates constraint C99 6.7.3p2 yet is only a warning with
-pedantic-errors:

restrict struct s;


-- 
   Summary: Restrict constraint violation not an error with -
pedantic-errors
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: neil at gcc dot gnu dot org


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

[Bug c/38246] New: Restrict constraint violation not an error with -pedantic-errors

[neil at gcc dot gnu dot org]

The following violates constraint C99 6.7.3p2 yet is only a warning with
-pedantic-errors:

restrict struct s;


-- 
   Summary: Restrict constraint violation not an error with -
pedantic-errors
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: neil at gcc dot gnu dot org


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

[Bug preprocessor/38161] [4.4 regression] #elif non-const expression #defined in this #if breaks

[neil at gcc dot gnu dot org]

--- Comment #3 from neil at gcc dot gnu dot org  2008-11-18 22:18 ---
The standard talks about the groups controlled by conditionals being skipped.

There is no conditional controlling the #elif - it is at the top level - so I
see nothing permitting its non-evaluation.


-- 


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

[Bug preprocessor/36320] New: Required diagnosis of syntax error missed

[neil at gcc dot gnu dot org]

The syntax error in #elif below is not diagnosed with (say) --std=c99
-pedantic-errors.

int z;
#if 1
#elif
#endif

Syntax is:

elif-group:
# elif constant-expression new-line groupopt

and constant expression cannot be empty.  The syntax relaxation of 6.10p4 does
not apply as the group that the #elif lies in (beginning with the #if) is not
skipped.


-- 
   Summary: Required diagnosis of syntax error missed
   Product: gcc
   Version: 4.1.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: preprocessor
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: neil at gcc dot gnu dot org


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

[Bug preprocessor/35010] preprocessor loses leading whitespace

[neil at gcc dot gnu dot org]

--- Comment #1 from neil at gcc dot gnu dot org  2008-05-15 02:54 ---
Chris - unless I'm missing something I disagree.  The 

, ## __VA_ARGS__

token sequence is being eaten in its entirety by the empty argument.  Then
between format and the ')' on the #define line, which is the ')' that appears
on the output, there is no whitespace.  It seems GCC's output is correct to me.


-- 

neil at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||neil at gcc dot gnu dot org
 Status|UNCONFIRMED |WAITING


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

[Bug preprocessor/35010] preprocessor loses leading whitespace

[neil at gcc dot gnu dot org]

--- Comment #2 from neil at gcc dot gnu dot org  2008-05-15 02:56 ---
Never mind, I see your point.  The comma isn't being eaten, right.


-- 

neil at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|WAITING |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-05-15 02:56:17
   date||


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

[Bug preprocessor/36088] New: Unevaluated PP expression rejected

[neil at gcc dot gnu dot org]

Compile with pedantic-errors, C99 or C90.

extern int x;
#if 1 ? 0: 1 ? 1/0: 1/0
#endif

Code is fine as the divisions by zero are unevaluated.


-- 
   Summary: Unevaluated PP expression rejected
   Product: gcc
   Version: 4.1.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: preprocessor
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: neil at gcc dot gnu dot org


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

[Bug c/35908] New: Dubious charset conversions

[neil at gcc dot gnu dot org]

GCC accepts the following with -ansi -pedantic -Wall without diagnostics

#include stdlib.h
wchar_t z[] = La \xff;

GCC claims a default execution charset of UTF-8; presumably the default
execution wide character set is UTF-32.  But \xff is a two-character narrow
execution character set string literal, with characters \xff \0, which is
invalid UTF-8 and so cannot be converted in a meaningful way to the execution
character set (whatever it is).

I would expect the above code to be rejected, or at least diagnosed.


-- 
   Summary: Dubious charset conversions
   Product: gcc
   Version: 4.1.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: neil at gcc dot gnu dot org


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

[Bug preprocessor/35312] New: Invalid syntax in PP expressions not diagnosed in strict mode

[neil at gcc dot gnu dot org]

The following expression violates the syntax but is not diagnosed and rejected
with -pedantic-errors, for C90 or C99:

extern int x;
#if #foo
#endif


-- 
   Summary: Invalid syntax in PP expressions not diagnosed in strict
mode
   Product: gcc
   Version: 4.1.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: preprocessor
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: neil at gcc dot gnu dot org


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

[Bug preprocessor/35313] New: Valid pp-expression rejected in C99 mode

[neil at gcc dot gnu dot org]

The following obeys the syntax, semantics and constraints of C99, but is
rejected with -pedantic-errors

extern int x;
#if 0 ? 2,3 : 2
#endif


-- 
   Summary: Valid pp-expression rejected in C99 mode
   Product: gcc
   Version: 4.1.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: preprocessor
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: neil at gcc dot gnu dot org


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

[Bug preprocessor/35301] Function macro nesting depth appears to be uncomfortably limited.

[neil at gcc dot gnu dot org]

--- Comment #4 from neil at gcc dot gnu dot org  2008-02-23 14:03 ---
To be honest this isn't even a disputed case from what I can see.  I doubt you
can find a serious C implementation (i.e. tcc etc. doesn't count) that will do
what you expect.


-- 

neil at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug middle-end/21718] real.c rounding not perfect

[neil at gcc dot gnu dot org]

--- Comment #6 from neil at gcc dot gnu dot org  2007-10-18 15:24 ---
(In reply to comment #5)

 I believe more than 160 bits are required to get even single-precision numbers
 right with DECIMAL_DIG digits precision and an exponent.  I'm going to try and
 prove this by finding an example.  It could be hard as I believe 160 is only
 just below the required number.

Here's an example to prove this assertion.  When compiled with GCC 4.1.2 or
4.1.3 with -std=c99, assuming a correctly-rounding libc (e.g. NetBSD's; glibc
also seems to get this correct) you get the following output:

0x1.8p-147 0x1.4p-147 8.40779078594890243e-45

So not only is it rounded incorrectly, but the number it is rounded to, when
converted back to decimal, does not even match the input number in the first
digit.

#include stdio.h
#include stdlib.h

int main (void)
{
  float f1 = 7.7071415537864938e-45;
  float f2 = strtof (7.7071415537864938e-45, NULL);

  printf( %a %a %0.18g\n, f1, f2, f1);

  return 0;
}


-- 


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

[Bug middle-end/21718] real.c rounding not perfect

[neil at gcc dot gnu dot org]

--- Comment #5 from neil at gcc dot gnu dot org  2007-10-11 03:45 ---
(In reply to comment #1)
 We probably don't even get it right for all cases with DECIMAL_DIG digits for
 all long double formats (required by Annex F).

(In reply to comment #2)
 My reading of F.5#2 is that conversions of all numbers with DECIMAL_DIG
 significant figures are meant to be correct, not just of those which arise 
 from
 converting a representable binary number to decimal (which we probably do get
 right).  I don't think you'll get all conversions with DECIMAL_DIG digits 
 right
 without at least 226 bits internal precision, and proving that any specific
 figure is enough would be hard.

I believe more than 160 bits are required to get even single-precision numbers
right with DECIMAL_DIG digits precision and an exponent.  I'm going to try and
prove this by finding an example.  It could be hard as I believe 160 is only
just below the required number.

I think to do DECIMAL_DIG digits correctly for long-double requires over 11,500
bits of precision.

I'm assuming above you're permitted to attach an exponent to your DECIMAL_DIG
digits; that's how I read the definition of DECIMAL_DIG anyway.  The exponents
push up the required precision enormously.


-- 


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

[Bug c/32041] New: offsetof buglet

[neil at gcc dot gnu dot org]

GCC seems to have taken the view that compound expressions are permitted as the
2nd argument to offsetof.  However the implementor of the grammar forgot that
- could be used.

#include stddef.h
struct s
{
  struct { float f; } sa[2];
};
enum { e = offsetof (struct s, sa-f) };


-- 
   Summary: offsetof buglet
   Product: gcc
   Version: 4.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: neil at gcc dot gnu dot org


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

[Bug c/31870] Failure to diagnose taking address of register variable

[neil at gcc dot gnu dot org]

--- Comment #4 from neil at gcc dot gnu dot org  2007-05-10 00:00 ---
Agreed it's minor; I think I flagged the PR that way.

I'm not sure but I suspect it indicates that the pointer decay is not
happening.  If so and you were using GCC to do source code analysis, you would
have an incorrect type in the expression tree.  Which may not be a big deal.


-- 


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

[Bug c/31870] New: Failure to diagnose taking address of register variable

[neil at gcc dot gnu dot org]

int d (void) { register int a[2]; return a, 1; }


-- 
   Summary: Failure to diagnose taking address of register variable
   Product: gcc
   Version: 4.1.2
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: neil at gcc dot gnu dot org


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

[Bug c/31871] New: C99 failure to diagnose non-integer cast

[neil at gcc dot gnu dot org]

Casts to void * are not permitted in integer constant expressions.

Therefore this code violates constraint 6.7.5.2p2 of C99 (C90 is u.b.) and so
must be diagnosed.

extern int c[1 + ((int) (void *) 0)];


-- 
   Summary: C99 failure to diagnose non-integer cast
   Product: gcc
   Version: 4.1.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: neil at gcc dot gnu dot org


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

[Bug preprocessor/31869] stringifying empty macros

[neil at gcc dot gnu dot org]

--- Comment #2 from neil at gcc dot gnu dot org  2007-05-09 05:01 ---
The space is required by the standard.  Is this a regression?  I believe GCC
used to get this right but I could be wrong.


-- 


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

[Bug c/29467] New: -ansi -pedantic accepts _Bool without diagnostic

[neil at gcc dot gnu dot org]

_Bool x;


-- 
   Summary: -ansi -pedantic accepts _Bool without diagnostic
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: neil at gcc dot gnu dot org


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

[Bug c/29468] off-by-one error for string initialiser warning

[neil at gcc dot gnu dot org]

--- Comment #1 from neil at gcc dot gnu dot org  2006-10-14 12:25 ---
Not a bug - just 2 elements are initialized, the NUL is dropped.


-- 

neil at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug c/29237] New: Failure to appropriately qualify C99 pointer decayed from array parameter

[neil at gcc dot gnu dot org]

The following code should raise a diagnostic with -std=c99 -pedantic-errors

int **p;

void foo (int b[restrict 2])
{
  p = b;
}


-- 
   Summary: Failure to appropriately qualify C99 pointer decayed
from array parameter
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: neil at gcc dot gnu dot org


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

[Bug c/29125] New: Failure to diagnose violation of constraint 6.7.5.2p2

[neil at gcc dot gnu dot org]

In 3.3.3 and GCC svn as of June.  Unbuildable since then.

int a (unsigned int n)
{
  struct c
  {
int d[n];
  } e;

  return e.d[0];
}


-- 
   Summary: Failure to diagnose violation of constraint 6.7.5.2p2
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: neil at gcc dot gnu dot org


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

[Bug c/29126] New: Failure to diagnose violation of constraint 6.7.5.2p2

[neil at gcc dot gnu dot org]

In 3.3.3 and GCC svn as of June.  Unbuildable since then.

int f (unsigned int m)
{
  extern int (*b)[m];

  return (*b)[0];
}


-- 
   Summary: Failure to diagnose violation of constraint 6.7.5.2p2
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: neil at gcc dot gnu dot org


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

[Bug c/29125] Failure to diagnose violation of constraint 6.7.5.2p2

[neil at gcc dot gnu dot org]

--- Comment #1 from neil at gcc dot gnu dot org  2006-09-18 14:02 ---
Fixed in current SVN.


-- 

neil at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug c/29126] Failure to diagnose violation of constraint 6.7.5.2p2

[neil at gcc dot gnu dot org]

--- Comment #1 from neil at gcc dot gnu dot org  2006-09-18 14:02 ---
Fixed in current SVN.


-- 

neil at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug c/29129] New: Strictly conforming code rejected

[neil at gcc dot gnu dot org]

Compile the following with -std=c99 -pedantic-errors

void f(unsigned int [*]);

foo.c:1: error: '[*]' not allowed in other than a declaration


-- 
   Summary: Strictly conforming code rejected
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: neil at gcc dot gnu dot org


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

[Bug c/14050] [DR289] c99 restrict doesn't work in abs declarator

[neil at gcc dot gnu dot org]

--- Comment #5 from neil at gcc dot gnu dot org  2006-09-18 15:13 ---
Confirmed


-- 

neil at gcc dot gnu dot org changed:

   What|Removed |Added

   Last reconfirmed|2006-03-05 03:15:48 |2006-09-18 15:13:12
   date||


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

[Bug c/29116] New: Failure to diagnose violation of constraint 6.7.5.2p2

[neil at gcc dot gnu dot org]

int n = 0, p[n * 0 + 1];

For C90 and C99, as of June SVN at least, and going back at least as far as
3.3.3.

Almost certainly because of overly early CF.


-- 
   Summary: Failure to diagnose violation of constraint 6.7.5.2p2
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: neil at gcc dot gnu dot org


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

[Bug preprocessor/28520] preprocessed output does not lex to correct tokens

[neil at gcc dot gnu dot org]

--- Comment #3 from neil at gcc dot gnu dot org  2006-07-28 23:47 ---
Tokenization is correct on reprocessing since ?= is not a token.


-- 

neil at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug preprocessor/28521] -E output incorrectly concatenates tokens into trigraphs

[neil at gcc dot gnu dot org]

--- Comment #3 from neil at gcc dot gnu dot org  2006-07-28 23:48 ---
Tokenization is correct since preprocessed output has been through stages 1-3
and starts at stage 4.  If you're passing -trigraphs then your command line is
incorrect.


-- 

neil at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug preprocessor/28521] -E output incorrectly concatenates tokens into trigraphs

[neil at gcc dot gnu dot org]

--- Comment #8 from neil at gcc dot gnu dot org  2006-07-29 05:02 ---
This is not a bug.  If you are preprocessing preprocessed output, you must use
-fpreprocessed as documented.  Otherwise many other things will go wrong, not
just this.  The bug is on your command line.


-- 

neil at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID


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

[Bug c/26642] order of multiple assignments to array-values handled differently from gcc 3.3.5

[neil at gcc dot gnu dot org]

--- Comment #1 from neil at gcc dot gnu dot org  2006-03-11 14:28 ---
There is no reason the results should not change.


-- 

neil at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug c/25897] GCC rejects the following strictly conforming code with -ansi -pedantic errors

[neil at gcc dot gnu dot org]

--- Comment #2 from neil at gcc dot gnu dot org  2006-01-21 08:02 ---
Discussing with pinskia, I believe qualifying the array type is intended to be
viewed as qualifying the element type, not the array, so the example is
invalid.


-- 

neil at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug c/25897] New: GCC rejects the following strictly conforming code with -ansi -pedantic errors

[neil at gcc dot gnu dot org]

void foo (const int (*h)[2], int (*i)[2])
{
  1 ? h: i;
}

Also rejected in C99 mode.


-- 
   Summary: GCC rejects the following strictly conforming code with
-ansi -pedantic errors
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: neil at gcc dot gnu dot org


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

[Bug c/24293] New: Undefined behaviour not diagnosed with -fsyntax-only

[neil at gcc dot gnu dot org]

GCC does not diagnose the following translation unit with -fsyntax-only:

static struct foo x;


-- 
   Summary: Undefined behaviour not diagnosed with -fsyntax-only
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P2
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: neil at gcc dot gnu dot org


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

[Bug c/23161] New: Labels and empty statement warnings

[neil at gcc dot gnu dot org]

void foo (void)
{
  if (0)
a: ;
}

Compile with -W, there is no warning about the empty statement.  Remove the
label and there is.  IMO the warning should be independent of whether the
statement is labelled.

-- 
   Summary: Labels and empty statement warnings
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: neil at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug c/23075] New: Redundant / bogus warning

[neil at gcc dot gnu dot org]

Compiling

int foo (void)
{
  return;  
}

with -ansi -pedantic gives two warnings; with GCC 3.3 it only gave one.  As a
QOI issue 3.3's behaviour is superior - warning about control reaching the end
of the function is a bit odd.

-- 
   Summary: Redundant / bogus warning
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P2
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: neil at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug c/23075] Redundant / bogus warning

[neil at gcc dot gnu dot org]

--- Additional Comments From neil at gcc dot gnu dot org  2005-07-26 12:13 
---
I meant to add -Wall to the warning list.

-- 
   What|Removed |Added

Summary|Redundant / bogus warning   |Redundant / bogus warning


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

[Bug c/22308] New: Failure to diagnose violation of constraint 6.516p2

[neil at gcc dot gnu dot org]

With -ansi -pedantic-errors, GCC fails to reject the following assignment.

struct foo s;
volatile struct foo t;
struct foo { const int z; };

void bar (void)
{
  t = s;
}

GCC is tricked by the delayed completion of a qualified form of the type.

-- 
   Summary: Failure to diagnose violation of constraint 6.516p2
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: neil at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug c/22249] New: GCC does not reject an incompatible type declaration

[neil at gcc dot gnu dot org]

I don't believe the standard requires the following to be rejected, but as a QOI
issue I believe it should be.  The debatable point is whether you believe the
composite of the first two is specified by a function definition; if you do then
you must reject.  GCC rejects it if the order of the first two is switched.

void r(x) int (*x)[2]; {}
void r();
void r(int (*x)[3]);/* Ideally rejected.  */

Flags are e.g. -Wall -std=c99 -pedantic

-- 
   Summary: GCC does not reject an incompatible type declaration
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: neil at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug c/22192] New: Rejection of valid array declaration.

[neil at gcc dot gnu dot org]

With -fsyntax-only GCC erroneously rejects the following array 'x' as having
non-constant size.  Its size should evaluate to 1.

int
bar (int v)
{
  int (*p)[v];
  int (*q)[2];

  static int x[sizeof(*(v ? p : q)) == 2 * sizeof (int)];

  return x[0];
}

-- 
   Summary: Rejection of valid array declaration.
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: neil at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug c/22192] Rejection of valid array declaration.

[neil at gcc dot gnu dot org]

--- Additional Comments From neil at gcc dot gnu dot org  2005-06-26 15:11 
---
(In reply to comment #0)
 With -fsyntax-only GCC erroneously rejects the following array 'x' as having
 non-constant size.  Its size should evaluate to 1.
 
 int
 bar (int v)
 {
   int (*p)[v];
   int (*q)[2];
 
   static int x[sizeof(*(v ? p : q)) == 2 * sizeof (int)];
 
   return x[0];
 }

I should add that switching p and q causes GCC to accept it.

-- 


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

[Bug preprocessor/22168] #if #A == #B should have a diagnostic

[neil at gcc dot gnu dot org]

--- Additional Comments From neil at gcc dot gnu dot org  2005-06-24 14:56 
---
Documented behaviour.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug preprocessor/22168] #if #A == #B should have a diagnostic in ISO C mode

[neil at gcc dot gnu dot org]

--- Additional Comments From neil at gcc dot gnu dot org  2005-06-24 22:24 
---
(In reply to comment #6)
 Yup, it's documented.  However, it's still silently accepted even with
-pedantic, and the language doesn't 
 permit that.

My copy of the standard only requires a constant expression - can you point out
where you read its requiring an integer constant expression?

The standard explicitly permits extensions to constant expressions.  Since this
extension is explicitly documented as for use in #if expressions, it should be
obvious that we intend #foo as a constant expression.  No diagnostic is
therefore required.

-- 


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

[Bug c/21857] New: Command line switches controlling acceptance of main

[neil at gcc dot gnu dot org]

GCC rejects the following with -Wall -pedantic-errors but accepts it with -ansi
-pedantic-errors, which seems odd.

typedef enum { foo } int_t;

int main (int_t argc, char **argv)
{
  return 0;
}

-- 
   Summary: Command line switches controlling acceptance of main
   Product: gcc
   Version: 3.3.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: neil at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug c/21781] New: real.c incorrectly values zero with a large exponent

[neil at gcc dot gnu dot org]

The following snippet, if compiled with -Wall, complains about a missing return
statement, indicating GCC is erroneously folding the comparison to false.

int foo(void) { if (.0e2 == 0 ) return 1; }

-- 
   Summary: real.c incorrectly values zero with a large exponent
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: neil at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug c/21794] New: GCC accepts invalid code

[neil at gcc dot gnu dot org]

gcc -Wall -ansi -pedantic -fsyntax-only

erroneously accepts the following:

void bar(void);

void (*baz(void))(void)  { return bar ? bar: (void *)(void *) 0; }

-- 
   Summary: GCC accepts invalid code
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: neil at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug c/21718] New: real.c rounding not perfect

[neil at gcc dot gnu dot org]

When compiled with -Wall,

int foo (void) { if (9007199254740991.45 ==
9007199254740991.5) return 1;}

does not complain about a missing return statement, showing that GCC is folding
the comparison to true.  However, the LHS should round down.

With one less 9 GCC gets it correct.

I'm not convinced it's worthwhile to get perfect rounding, but Joseph wanted me
to file a report.

-- 
   Summary: real.c rounding not perfect
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: neil at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug c/21720] New: GCC incorrectly rounds hex floats

[neil at gcc dot gnu dot org]

Unlike decimal floats, correctly rounding hex floats is easy and cheap, so we
should do it.  Moreover the standard requires it.

With -Wall GCC complains that the following function is missing a return
statement because it has incorrectly folded the comparison to false.

int foo(void) { if (0x1.0101p0f != 1) return
1; }

Remove one of the long line of zeroes and the precision falls within GCC's
limits and it works.

-- 
   Summary: GCC incorrectly rounds hex floats
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: neil at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug c/21438] New: Warning about division by zero depends on lexical form

[neil at gcc dot gnu dot org]

GCC is supposed to suppress division by zero warnings when floating point. 
However the warning is based on the lexical form, i.e. the unpromoted type.  I
suggest it should depend on the promoted type.

float f[] = {
 1.0f/0.0f,  // No warning
 1.0f/0  // Warning (and diagnostic is on the wrong line in 3.3 at least)
};

-- 
   Summary: Warning about division by zero depends on lexical form
   Product: gcc
   Version: 3.3.3
Status: UNCONFIRMED
  Severity: minor
  Priority: P2
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: neil at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug c/21296] New: Missed warning

[neil at gcc dot gnu dot org]

-Wall warns about most statements with no effect.  However, it doesn't warn 
about

volatile int v;
void foo(void)
{
  v;
}

-- 
   Summary: Missed warning
   Product: gcc
   Version: 3.3.3
Status: UNCONFIRMED
  Severity: minor
  Priority: P2
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: neil at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug preprocessor/20989] The -M option gives object file names without directory

[neil at gcc dot gnu dot org]

--- Additional Comments From neil at gcc dot gnu dot org  2005-04-13 13:29 
---
Not a bug - you misunderstand basename.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug preprocessor/20077] New: GCC accepts macro definitions that fail a constraint

[neil at gcc dot gnu dot org]

#define a a ## ##
#define a() a ## ##

-- 
   Summary: GCC accepts macro definitions that fail a constraint
   Product: gcc
   Version: 3.4.4
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: preprocessor
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: neil at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug preprocessor/20078] New: Gcc doesn't complain about non-benign macro definitions

[neil at gcc dot gnu dot org]

According to the standard

#define str(x) #x
#define str(x) %:x

violates a constraint, but GCC accepts it.  Amusingly, Comeau shares the same 
bug.

A similar bug exists with the paste operator.

-- 
   Summary: Gcc doesn't complain about non-benign macro definitions
   Product: gcc
   Version: 3.4.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: preprocessor
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: neil at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug preprocessor/19040] #elif token1 token2 doesn't produce a diagnostic

[neil at gcc dot gnu dot org]

--- Additional Comments From neil at gcc dot gnu dot org  2004-12-16 22:38 
---
Not a bug - the standard requires this.

-- 
   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID


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

[Bug preprocessor/15167] [3.4/4.0 Regression] Internal compiler error with #pragma once

[neil at gcc dot gnu dot org]

--- Additional Comments From neil at gcc dot gnu dot org  2004-12-06 02:26 
---
Eric - can you try your testcase on GCC sources as of around the beginning of
August 2003?

This is when I completely rewrote the whole file lookup mechanism, and contrary
to Zack's claims it did work 100% correctly, to the best of my knowledge, and
would always get links, both hard and soft, correct with #pragma once correct no
matter how contorted or renamed the file was.  Then only issue in that code was
the -remap bug that has since been fixed.

However, since that date, various people have hacked at the code who probably
didn't understand it.  Zack did various optimizations and Apple added a bunch
of stuff for obfuscated include file lookup and line number stuff.  I think it
is very likely it was broken along the way.

If it was broken back around 5th August 2003 I will look into this, as it was my
new code.

-- 


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