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 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/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 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 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/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/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/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/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 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 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/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: 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.
Re: bug in tradcpp.c and patch fixing it
Sam Steingold wrote:- > there is a bug in gcc/tradcpp.c which can potentially cause a segfault. Hmmm. One down, 1632 to go. You couldn't patch all the others too? 8=) > the patch which fixes the bug, made against the files in the GCC-3.0 > distribution, is appended to this message. Thanks a lot. I'll take a look and apply it soon if all's OK. Neil.
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/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/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.
