Re: [Bug c/29467] -ansi -pedantic accepts _Bool without diagnostic
pinskia at gcc dot gnu dot org wrote:- --- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-14 15:29 --- Hmm, isn't _Bool in the implemenation keyword space anyways? It is, so is _Complex, and that is diagnosed. I'm not saying it's a conformance problem, just that it's probably a bug.
Re: [Bug c/29444] parser bug for variable declaration immediately following case statement in switch block
pinskia at gcc dot gnu dot org wrote:- --- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-12 20:47 --- This is not valid C code. even though declarations can appear intermixed with statements, they are still not a statement and cannot be placed anywhere a statement can. This is a dup of bug 29062. It's going to keep getting reported until the diagnostic improves and shows that it's not the compiler that is confused. Neil.
Re: [Bug c/28768] [4.0/4.1/4.2 Regression] Preprocessor doesn't parse tokens correctly?
pinskia at gcc dot gnu dot org wrote:- --- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-18 05:11 --- Confirmed, a regression from 3.3.3. Rather, intended behaviour since 3.3.3. Neil.
Re: [Bug preprocessor/27750] New: bogus 'backslash-newline at end of file' warning
sabre at nondot dot org wrote:- $ gcc bug.c -Wall -pedantic -fsyntax-only -trigraphs -std=c99 yields: bug.c:2:9: warning: trigraph ??/ converted to \ bug.c:2:9: warning: backslash-newline at end of file bug.c:2:1: warning: multi-line comment bug.c:1: warning: ISO C forbids an empty source file A couple of issues. First, the diagnostics are not sorted. The last one should be issued first. Second, more importantly, the 2nd diagnostic is incorrect. There is no backslash-newline at the end of the file. The first and third diagnostics are accurate. The empty source file diagnostic is clearly incorrect, it has text in it 8-) However I think it's quite logical it appear last as that it where it can be discovered. The backslash diagnostic is clearly bogus too. Neil.
Re: [Bug c/14366] variable previously declared `static' redeclared `extern' is valid ISO C - 3.4 and 4.0 regression
pinskia at gcc dot gnu dot org wrote:-
Hmm, I think this causes the following invalid code to be accepted (but I am
not sure if this is invalid code or not):
enum in_section { in_toc };
int f(void) { extern int in_toc; }
--
In 3.3 and before we got:
t1.c: In function `f':
t1.c:1: error: `in_toc' redeclared as different kind of symbol
t1.c:1: error: previous declaration of `in_toc'
I believe this should be accepted. Either way in_toc is not
redeclared, there is only one declaration at block scope and that
hides the outer declaration.
More serious is the fact that a missing return statement is
apparently not diagnosed?
Re: [Bug c/8268] no compile time array index checking
rguenth at gcc dot gnu dot org wrote:-
Also make sure not to trip on
typedef struct {
int len;
char str[4];
} String;
char foo(String *s)
{
return s-str[42];
}
That definitely deserves a warning.
Neil.
Re: [Bug c/25161] [4.0/4.1/4.2 Regression] Internal compiler error (segfault) instead of error message
steven at gcc dot gnu dot org wrote:- Sadly I have no idea what this variable is for, and Joseph did not add any Detecting jumps over variably modified types as required in C99. Neil.
Re: [Bug preprocessor/8270] [3.4/4.0/4.1 Regression] back-slash newline extension can't be removed
pinskia at gcc dot gnu dot org wrote:- That would be the consensus from Andrew, not from people concerned that deal with language issues routinely. Wait a minute, if you actually look at the people agrueing for the change, it is only Apple employees. Joe has said we should not change it. It looks like DJ is saying the same in the new thread which shows the real issues with the other compilers implemenation. I've said we should change it, I don't work for Apple. Please stop trying to claim your opinion is some kind of consensus. Neil.
Re: [Bug c/23895] switch and struct
pinskia at gcc dot gnu dot org wrote:-
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-15
14:22 ---
Small testcase:
void f(int i)
{
switch (i)
{
case 1:
struct a *b;
}
}
But IIRC this is invalid code as variable defintions are not allowed right
after a label.
void f(int i)
{
a:
struct a *b;
}
In fact This is a dup of bug 7508.
Really this error message needs to be much better. Otherwise this
PR will keep coming back.
Neil.
Re: [Bug preprocessor/9449] UCNs not recognized in identifiers (c++/c99)
geoffk at gcc dot gnu dot org wrote:- --- Additional Comments From geoffk at gcc dot gnu dot org 2005-09-15 22:34 --- (In reply to comment #39) Another reason why spelling needs preserving (in addition to implementing # correctly) is for the constraints on duplicate macro definitions. #define foo \u00c1 #define foo \u00C1 is invalid (different spelling in replacement), as is We discussed this on the list and decided that this was probably a defect in the C standard, since the Rationale says that the kind of implementation we have now is supposed to be permitted, and jsm said he'd file a DR. How's that going? I very much doubt this is a defect. Just because it doesn't fit your implementation... Neil.
Re: [Bug preprocessor/20348] [4.0/4.1 Regression] File not included when file with same name is included before
jakub at gcc dot gnu dot org wrote:- --- Additional Comments From jakub at gcc dot gnu dot org 2005-08-26 15:57 --- This got broken by the libcpp/files.c part of http://gcc.gnu.org/ml/gcc-patches/2004-06/msg00272.html My understanding of the change was that this was just a performance improvement. The question is if that change is fixable to handle this and keep the improvements where they can be used, or if it should be reverted. I would back it out; I suspect the perceived performance improvement came from missing some cases like these. IMO the code was already quite efficient. Neil.
Re: [Bug c/23365] Declaration within case statement produces syntax error
jsm28 at gcc dot gnu dot org wrote:- --- Additional Comments From jsm28 at gcc dot gnu dot org 2005-08-12 20:54 --- Labels can only be applied to statements, not declarations; see the C99 standard. That would be a much better error message.
Re: [Bug c/23113] The -Wunused (value computed is not used) option missed an important case
pinskia at gcc dot gnu dot org wrote:- --- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-28 17:28 --- foo() has side effects. *p++ has the side effect of increasing p by 1. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID Um, did you read the PR Andrew?
Re: [Bug preprocessor/19836] -E -dD includes predefined macros
jason at catapult dot com wrote:- --- Additional Comments From jason at catapult dot com 2005-02-09 06:27 --- (In reply to comment #1) This is documented to do this so this is not a bug. I thought -dD was supposed to NOT include predefined macros? Use -undef if you don't want them.
Re: [Bug preprocessor/19361] New: -MT option does not escape funny characters
abbott at dima dot unige dot it wrote:- The -MT option really does use precisely the specified string as the target. It would be better if spaces (and other funny characters) were escaped (using backslash) in the output. Note: for my purposes it would be enough to follow the proposal in bug #15185 that there be an option to force the full path name in the target. EXAMPLE: compare the outputs of the following two calls to gcc $ touch my\ prog.c $ gcc -MM my\ prog.c my\ prog.o: my\ prog.c $ gcc -MM my\ prog.c -MT my\ prog.o my prog.o: my\ prog.c I am inclined to say that the second output is wrong. What's wrong with -MQ?
Re: [Bug preprocessor/17798] [3.4/4.0 Regression] high cpp memory usage with undefined symbols
pinskia at gcc dot gnu dot org wrote:- --- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-14 05:53 --- The first thing is that read_file_guts mallocs the whole file which seems wrong. That accounts for 500M. The next problem is that keep every identifier we parsed even though we don't need it. 3014 calls for 12,273,008 bytes: thread_a000a1ec |0x0 | _dyld_start | _start | main | toplev_main | do_compile | compile_file | c_common_parse_file | c_parse_file | yyparse | yylex | _yylex | c_lex | c_lex_with_flags | cpp_get_token | _cpp_lex_token | _cpp_handle_directive | do_ifdef | lex_macro_node | _cpp_lex_token | _cpp_lex_direct | lex_identifier | ht_lookup_with_hash | _obstack_newchunk | xmalloc | malloc | malloc_zone_malloc And this is where the problem comes from. No there is no leak we keep a reference to all of thes identifiers but this seems like we should not. Not doing either of these involves a major rework of cpplib FWIW. I happen to think it would be beneficial, but I also think that the whole approach CPP takes needs rethinking. Neil.
Re: preprocessor bug: @ + MACRO does not work in gcc-3.0
Zack Weinberg wrote:- I agree with you that (2) is a bad solution. However, I don't like (1) either. It is a major quiet change to the semantics of Objective C. I have no way of evaluating how widespread this sort of thing is, so I'm going to be really conservative. Also, looking at cpplex.c and c-parse.in, I think going for (3) might actually simplify the code. What do you think of the appended patch? With it, the preprocessor crunches Nicola's test case correctly. However, this only exposes another bug - see separate report. Two things: 1) Is it a good idea to introduce yet another token type, when CPP_OTHER would do (from what I can see)? 2) Don't you just drop stray @ tokens, in e.g. int x = y @ + z; without a diagnostic? (And what about in C?) Neil.
