[Bug preprocessor/38161] [4.4 regression] #elif breaks
--- 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 c/38243] New: Restrict constraint violation not an error with -pedantic-errors
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
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/28520] preprocessed output does not lex to correct tokens
--- 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
--- 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
--- 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/29116] New: Failure to diagnose violation of constraint 6.7.5.2p2
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 c/29125] New: Failure to diagnose violation of constraint 6.7.5.2p2
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
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
--- 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
--- 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
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
--- 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/29237] New: Failure to appropriately qualify C99 pointer decayed from array parameter
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/29467] New: -ansi -pedantic accepts _Bool without diagnostic
_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
--- 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 middle-end/21718] real.c rounding not perfect
--- 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 middle-end/21718] real.c rounding not perfect
--- 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
#include
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 preprocessor/20077] New: GCC accepts macro definitions that fail a constraint
#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
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/20989] The -M option gives object file names without directory
--- 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/35312] New: Invalid syntax in PP expressions not diagnosed in strict mode
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
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.
--- 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 c/39646] New: __FILE__ breaks for empty file name
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
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/31870] New: Failure to diagnose taking address of register variable
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
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
--- 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/31870] Failure to diagnose taking address of register variable
--- 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/32041] New: offsetof buglet
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
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/24293] New: Undefined behaviour not diagnosed with -fsyntax-only
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 preprocessor/22168] #if #A == #B should have a diagnostic
--- 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
--- 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/22192] New: Rejection of valid array declaration.
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.
--- 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 c/22249] New: GCC does not reject an incompatible type declaration
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/22308] New: Failure to diagnose violation of constraint 6.516p2
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/23075] New: Redundant / bogus warning
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
--- 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/23161] New: Labels and empty statement warnings
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/35908] New: Dubious charset conversions
GCC accepts the following with -ansi -pedantic -Wall without diagnostics
#include
wchar_t z[] = L"a" "\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/36088] New: Unevaluated PP expression rejected
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 preprocessor/35010] preprocessor loses leading whitespace
--- 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
--- 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/36320] New: Required diagnosis of syntax error missed
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 c/25897] New: GCC rejects the following strictly conforming code with -ansi -pedantic errors
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/25897] GCC rejects the following strictly conforming code with -ansi -pedantic errors
--- 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/26642] order of multiple assignments to array-values handled differently from gcc 3.3.5
--- 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/21296] New: Missed warning
-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 c/21438] New: Warning about division by zero depends on lexical form
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/21718] New: real.c rounding not perfect
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
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/21781] New: real.c incorrectly values zero with a large exponent
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
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/21857] New: Command line switches controlling acceptance of main
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 preprocessor/19040] #elif token1 token2 doesn't produce a diagnostic
--- 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"
--- 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
