[Bug c/35908] Dubious charset conversions
--- Comment #2 from neil at daikokuya dot co dot uk 2008-04-12 04:40 --- Subject: Re: Dubious charset conversions joseph at codesourcery dot com wrote:- > > 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. > > Accepting it as equivalent to L"a\xff" (generating a wide character L'a' > followed by one with value 0xff) seems in accordance with the principles > of N951, the relevant ones of which are implemented in GCC. > > http://www.open-std.org/jtc1/sc22/wg14/www/docs/n951.htm > http://gcc.gnu.org/ml/gcc-patches/2003-07/msg00532.html Ah, I'd forgotten about that. That document does make much more sense, thanks. However I think there are at least two things wrong in "Principle 7"; I've mailed Clive about those. [The single byte requirement cannot be fulfilled for Latin source charset to UTF-8 target, for example, and UCNs are escape sequences that typically cannot be encoded as a single byte]. GCC should perhaps consider not creating invalid UTF-8 (i.e. no 5 or 6 bytes forms, or encodings of \ufffe \u etc.) Please feel free to close this report. Neil. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35908
[Bug c/31870] Failure to diagnose taking address of register variable
--- Comment #2 from neil at daikokuya dot co dot uk 2007-05-09 23:39
---
Subject: Re: Failure to diagnose taking address of register variable
bangerth at dealii dot org wrote:-
> Uh, can you elaborate? We get the warning you want if we have
> int d (void) { register int a[2]; return a; }
> instead. In your case, i.e. "return a,1", we return 1, but we still
> need evaluate the expression "a". I assume that you mean that this
> implies that we have to do the array-to-pointer decay operation. However,
Yes, it has to be done.
> for that case, C99's clause 6.3.2.1/3 says that that's possible for
> register storage class arrays but that the result is undefined.
Right. GCC seems to want to diagnose this undefined behaviour; it
does in all other circumstances.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31870
[Bug preprocessor/29836] Concatenation operator ## doesn't work with this: / ## /
--- Comment #1 from neil at daikokuya dot co dot uk 2006-11-14 22:49
---
Subject: Re: New: Concatenation operator ## doesn't work with this: / ## /
michael dot bishop at gdcanada dot com wrote:-
> I am trying to use the macro concatenation operator to make a "conditional
> comment". I want a symbol that I can sprinkle throught my C code that will be
> replaced either be a C++ style // comment, or it will be replaced with
> nothing.
There is no such thing as a conditional comment. Only Microsoft's
preprocessor, broken in many ways, seems to support this (and those
compilers that attempt to emulate MS). This has been discussed before;
GCC will never support this.
> The compiler error messages are:
>
> t.c:8:1: pasting "/" and "/" does not give a valid preprocessing token
> t.c:10:1: pasting "/" and "/" does not give a valid preprocessing token
This is correct.
> The output from the preprocessor (using the -E command line switch) is:
>
> int
> main ( void )
> {
> int i ;
> / / int j ;
>
> / / j = i ;
>
> return ( 0 ) ;
> }
>
> I find it strange that the preprocessor puts a blank space between the two '/'
> characters. This looks like a bug to me. I don't think there should be a
> blank space between the characters.
It's because the preprocessor is taking care to avoid creating something
that looks like a comment, from two separate tokens.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29836
[Bug preprocessor/27195] hex and oct constants are converted to wrong type
--- Comment #6 from neil at daikokuya dot co dot uk 2006-10-26 12:42 --- Subject: Re: hex and oct constants are converted to wrong type lukew at radterm dot com dot au wrote:- > > The resulting tokens compose the controlling constant expression which > > is evaluated according to the rules of 6.6. For the purposes of this > > token conversion and evaluation, all signed integer types and all > > unsigned integer types act as if they have the same representation as, > > respectively, the types intmax_t and uintmax_t defined in the header > > .142) > > > > 142) Thus, on an implementation where INT_MAX is 0x7FFF and UINT_MAX is > > 0x, the constant 0x8000 is signed and positive within a #if > > expression even though it would be unsigned in translation phase 7. > > > > I don't get it. > > How can 0x8000 be signed AND positive when INT_MAX is a 16 bit integer? Ask yourself what its type is. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27195
[Bug c/29467] -ansi -pedantic accepts _Bool without diagnostic
--- Comment #2 from neil at daikokuya dot co dot uk 2006-10-14 16:19 --- Subject: Re: -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. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29467
[Bug c/29444] parser bug for variable declaration immediately following case statement in switch block
--- Comment #2 from neil at daikokuya dot co dot uk 2006-10-12 22:27 --- Subject: Re: 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. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29444
[Bug c/29129] [4.2 Regression] Strictly conforming code rejected
--- Comment #3 from neil at daikokuya dot co dot uk 2006-09-19 13:04 --- Subject: Re: [4.2 Regression] Strictly conforming code rejected joseph at codesourcery dot com wrote:- > > foo.c:1: error: '[*]' not allowed in other than a declaration > > As the diagnostic indicates, "unsigned int [*]" is not a declaration with > function prototype scope but a type name. Feel free to submit a DR > regarding the exact meaning of "can only be used in declarations with > function prototype scope". I'm quite happy my reading is correct, thanks, but don't let me stop you. I'd be interested in why you believe an alternative reading is justified despite its explicit inclusion in the grammar of 6.7.6, plus examples. DR 295 is an example of continuing imprecise wording that is far more gratuitous. Neil. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29129
[Bug c/29062] Parse error after label and variable declaration
--- Comment #2 from neil at daikokuya dot co dot uk 2006-09-13 22:27 --- Subject: Re: Parse error after label and variable declaration schwab at suse dot de wrote:- > > > --- Comment #1 from schwab at suse dot de 2006-09-13 15:32 --- > A label can only be part of a statement. A declaration is not a statement. > Considering the number of times this is reported, and people clearly don't understand what is wrong with their code, it should be considered a case of very poor diagnostics. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29062
[Bug c/28768] [4.0/4.1/4.2 Regression] Preprocessor doesn't parse tokens correctly?
--- Comment #6 from neil at daikokuya dot co dot uk 2006-08-23 13:16 --- Subject: Re: [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. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28768
[Bug preprocessor/27750] bogus 'backslash-newline at end of file' warning
--- Comment #8 from neil at daikokuya dot co dot uk 2006-05-24 12:55 --- Subject: Re: 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. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27750
[Bug c/27697] [4.0/4.1/4.2 Regression] incorrect warning about constness of pointer to an array in a const struct
--- Comment #3 from neil at daikokuya dot co dot uk 2006-05-21 23:17 --- Subject: Re: [4.0/4.1/4.2 Regression] incorrect warning about constness of pointer to an array in a const struct pinskia at gcc dot gnu dot org wrote:- > > > --- Comment #2 from pinskia at gcc dot gnu dot org 2006-05-21 16:15 > --- > This is also rejects valid with -pedantic-errors. > I don't understand what is correct here so I am not going to confirm it. If I understand correctly I think the report is correct about validity for both C90 and C99; another front end gives "/tmp/bar.c", line 10: error: cannot convert initializer of type "const int (*)[10]" to type "int (*)[10]" int (*qoox)[10] = bar.x; /* should warn */ ^ "/tmp/bar.c", line 11: error: expression must be a modifiable lvalue bar.x[0][1] = 23; /* error: asignment to const */ ^ "/tmp/bar.c", line 9: warning: variable "baz" declared but not used const int (*baz)[10] = bar.x; /* should be ok */ ^ 2 errors found compiling "/tmp/bar.c". -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27697
[Bug c/14366] variable previously declared `static' redeclared `extern' is valid ISO C - 3.4 and 4.0 regression
--- Comment #7 from neil at daikokuya dot co dot uk 2006-05-18 22:22
---
Subject: Re: 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?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14366
[Bug middle-end/26632] [4.1/4.2 Regression] spurious warning: value computed is not used
--- Comment #4 from neil at daikokuya dot co dot uk 2006-03-11 00:15 --- Subject: Re: spurious warning: value computed is not used pinskia at gcc dot gnu dot org wrote:- > > > --- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-10 15:16 > --- > Hmm, what is going on here is the following. > 0 ? h() : g(); > is not really just that but instead: > 0 ? h() : (long)g(); > which then gets foldded into: > (long)g(); > and we warn about the cast. Every time we get bitten by issuing diagnostics after parts of GCC other than the front end manipulate the IR. These bugs won't go away until GCC stops doing this. Neil. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26632
[Bug c/8268] no compile time array index checking
--- Comment #30 from neil at daikokuya dot co dot uk 2006-02-19 00:52
---
Subject: Re: 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.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8268
[Bug c/25161] [4.0/4.1/4.2 Regression] Internal compiler error (segfault) instead of error message
--- Comment #7 from neil at daikokuya dot co dot uk 2006-01-09 04:38 --- Subject: Re: [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. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25161
[Bug preprocessor/8270] [3.4/4.0/4.1 Regression] back-slash newline extension can't be removed
--- Comment #32 from neil at daikokuya dot co dot uk 2005-10-26 23:07 --- Subject: Re: [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. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8270
[Bug preprocessor/9449] UCNs not recognized in identifiers (c++/c99)
--- Additional Comments From neil at daikokuya dot co dot uk 2005-09-15 22:58 --- Subject: Re: UCNs not recognized in identifiers (c++/c99) joseph at codesourcery dot com wrote:- > I don't believe I said I'd file a DR unless I saw a defect. There is no > defect because models A or C need to be implemented by an > implementation-defined mapping (documented as such; we don't even document > the removal of trailing whitespace from lines; of course anything > replacing UCNs with the characters they designate only in certain places > is a pain to document because it doesn't fit in with the C model of phases > of translation). Doug Gwyn's reading in reflector message 10751, > > Yes, "spelling" is meant in terms of the source code characters. > The idea is to permit simple strcmp-like checking by the preprocessor. I think this is what we will need to do to fix the # and ## and spacing bugs in macro replacements too - base the decision upon a memcmp or strcmp. Neil. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9449
[Bug preprocessor/9449] UCNs not recognized in identifiers (c++/c99)
--- Additional Comments From neil at daikokuya dot co dot uk 2005-09-15 22:53 --- Subject: Re: 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. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9449
[Bug c/23895] switch and struct
--- Additional Comments From neil at daikokuya dot co dot uk 2005-09-15
22:50 ---
Subject: Re: 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.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23895
[Bug c++/23823] Is this right?
--- Additional Comments From neil at daikokuya dot co dot uk 2005-09-12 12:42 --- Subject: Re: Is this right? igodard at pacbell dot net wrote:- > > --- Additional Comments From igodard at pacbell dot net 2005-09-12 03:17 > --- > In the case you give I count one template argument specificatiob, and two > template parameters. Your understanding of the meaning of "parameter" and "argument" is backwards, which is probably the source of your confusion. Neil. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23823
[Bug preprocessor/20348] [4.0/4.1 Regression] File not included when file with same name is included before
--- Additional Comments From neil at daikokuya dot co dot uk 2005-08-27 05:44 --- Subject: Re: [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. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20348
[Bug c/23365] Declaration within case statement produces syntax error
--- Additional Comments From neil at daikokuya dot co dot uk 2005-08-13 05:30 --- Subject: Re: 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. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23365
[Bug c/23113] The -Wunused (value computed is not used) option missed an important case
--- Additional Comments From neil at daikokuya dot co dot uk 2005-07-28 22:46 --- Subject: Re: 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? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23113
[Bug preprocessor/19475] [3.3/3.4/4.0/4.1 Regression] missing whitespace after macro name in C90 or C++
--- Additional Comments From neil at daikokuya dot co dot uk 2005-04-05 11:31 --- Subject: Re: [PATCH] Fix PR preprocessor/19475 Jakub Jelinek wrote:- > Is there some limitation on how many bytes or error messages > dejagnu groks or something? I think it gets confused by the column numbers; if you add -fno-columns (or whatever it is) the problem would probably go away. Neil. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19475
[Bug preprocessor/20262] __LINE__ implementation flaky.
--- Additional Comments From neil at daikokuya dot co dot uk 2005-03-01 23:36 --- Subject: Re: __LINE__ implementation flaky. neil at daikokuya dot co dot uk wrote:- > > --- Additional Comments From neil at daikokuya dot co dot uk 2005-03-01 > 23:13 --- > Subject: Re: __LINE__ implementation flaky. > > pinskia at gcc dot gnu dot org wrote:- > > > > > --- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-01 > > 17:16 --- > > Outer Macros are expanded before inner ones and they get all placed on one > > line so this is invalid. > > Huh? This is a bug. Actually I take that back - I think you can say that the wording of the standard is sufficiently vague that this is not a bug, and may even be correct behaviour. The standard says that (at the time of expansion) it's the "presumed current source line of the file". Since expansion happens after argument collection, it's not hard to argue that the current source line of the file is constant for both __LINE__ tokens. Neil. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20262
[Bug preprocessor/20262] __LINE__ implementation flaky.
--- Additional Comments From neil at daikokuya dot co dot uk 2005-03-01 23:13 --- Subject: Re: __LINE__ implementation flaky. pinskia at gcc dot gnu dot org wrote:- > > --- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-01 > 17:16 --- > Outer Macros are expanded before inner ones and they get all placed on one > line so this is invalid. Huh? This is a bug. The reason it happens is nothing to do with inner or outer macros, but the fact that arguments are collected before being expanded, and an implementation detail where we don't take the line from the token (otherwise __LINE__ would be misexpanded if the RHS of a macro definition) but from the global line counter. It may not be worth fixing; I suspect the reason other implementations fail too is that it's hard to get it right, and the ability to easily do so is heavily dependent on exactly how your preprocessor is implemented. (a bit like the #s vs %:s bug). Neil. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20262
[Bug c/20258] error generated for storage class specified for function parameter
--- Additional Comments From neil at daikokuya dot co dot uk 2005-03-01 12:39 --- Subject: Re: error generated for storage class specified for function parameter schlie at comcast dot net wrote:- > Yes I understand. However it seems somewhat ironic that "static const" > already does just that, as it specifies the storage class and access What if it were the pointer that was like this? You need a type qualifier, not a storage class. Neil. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20258
[Bug preprocessor/9449] UCNs not recognized in identifiers (c++/c99)
--- Additional Comments From neil at daikokuya dot co dot uk 2005-02-21
23:00 ---
Subject: Re: UCNs not recognized in identifiers (c++/c99)
jsm28 at gcc dot gnu dot org wrote:-
> * The greedy algorithm applies for lexing UCNs: for example,
> a\U000z is three preprocessing tokens {a}{\}{U000z} (and
> shouldn't get a diagnostic on lexing, presuming macros are defined
> such that the eventual token sequence is valid).
I'm not sure I agree with this: it would seem to be unnecessary
extra work; further I suspect the user would benefit from it being
pointed out he entered an ill-formed UCN rather than something random
from the front end complaining about an unexpected backslash.
The only case where you wouldn't get a syntax error from the
front end, or an invalid escape in a literal, is with -E. I'm
not sure lexing to the letter of the standard is worthwhile in
this case, as the standard doesn't discuss -E.
If you have an example where a compiled program is acceptable
with multiple lexing tokens then I would agree with you.
> * The spelling of UCNs is preserved for the # and ## operators.
This is very hard with CPP's current implementation - it assumes
it can deduce the spelling of an identifier from its hash table
entry. IMO the proper way to fix this to use a different approach
entirely, rather than kludge it in the existing implementation
(which would bloat some common datastructures) but that's some work.
> * I think the only reasonable interpretation of the lexing rules in
> the context of forbidden characters is that first identifiers are
> lexed (allowing any UCNs) then bad characters yield an error (rather
> than stopping the identifier before the bad character and treating it
> as not a UCN).
Agreed - as I say above I don't see why this shouldn't apply for
partial UCNs too, even with -E.
The rest seems reasonable.
Neil.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9449
[Bug c++/20019] incorrect overflow warning
--- Additional Comments From neil at daikokuya dot co dot uk 2005-02-17 15:12 --- Subject: Re: incorrect overflow warning schlie at comcast dot net wrote:- > > --- Additional Comments From schlie at comcast dot net 2005-02-17 14:33 > --- > (In reply to comment #8) > > char x = 0x80; warning: value changes sign during integer type conversion > > Implying an analogous warning for all assignments between dissimilarly > signed variables (i.e. signed x; unsigned y; x = y;) which I believe are > considered "compatible"; and half of all unsigned hex constants being > assigned to signed types even if cast, as it's arguably the cast which > produces the virtual numerical over/underflow. > > (where although you're numerically correct, seems like a lot of noise?) Well it's certainly a matter of taste. char is arguably a special case as you cannot assign a value with the high bit set without creating the warning on some targets. But if you are assigning values with the high bit set then arguably you have in mind whether you are dealing with signed or unsigned values and should be explicit about signedness. As such like any warning it tends to expose sloppy thinking. Your x=y example is of course not the same; whether a value is changing sign or not is not knowable at compile time and probably rarely the case, so I agree complaining about that would be annoying. Some people have in the past requested command-line switches to generate warnings for any implicit integer conversion. I agree a singed <-> unsigned should not be on by default, though potentially narrowing conversions are debatably more appropriate to have on by default. Neil. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20019
[Bug c++/20019] incorrect overflow warning
--- Additional Comments From neil at daikokuya dot co dot uk 2005-02-17 14:00 --- Subject: Re: incorrect overflow warning schlie at comcast dot net wrote:- > > --- Additional Comments From schlie at comcast dot net 2005-02-17 13:20 > --- > (In reply to comment #6) > > What should get a warning is the assignment of 0x80 to a char. > > Not that either, as although the two differ in sign, the value does not > exceed the type's precision. I disagree. Like so: "/tmp/foo.c", line 1: warning: value changes sign during integer type conversion char x = 0x80; ^ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20019
[Bug c++/20019] incorrect overflow warning
--- Additional Comments From neil at daikokuya dot co dot uk 2005-02-17 11:34 --- Subject: Re: incorrect overflow warning pinskia at gcc dot gnu dot org wrote:- > > --- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-17 > 03:14 --- > No the warning is correct as char on a lot of targets is signed by default so > promoting (char)0x80 to int > will give 0xFF80. This explanation just doesn't make sense. What should get a warning is the assignment of 0x80 to a char. Neil. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20019
[Bug preprocessor/19836] -E -dD includes predefined macros
--- Additional Comments From neil at daikokuya dot co dot uk 2005-02-09 22:48 --- Subject: Re: -E -dD includes predefined macros jason at catapult dot com wrote:- > Where did you read this? This is what is written in the CPP and GCC manpages, > and the GCC online docs. > > D - Like M except in two respects: it does not include the predefined macros, > and it outputs both the #define directives and the result of preprocessing. > Both > kinds of output go to the standard output file. > > Neil, thanks for the suggestion, it removed all of them except for #define > __STDC_HOSTED__ 1, which I can take out with sed. OK, so 2 bugs here then 8-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19836
[Bug preprocessor/19836] -E -dD includes predefined macros
--- Additional Comments From neil at daikokuya dot co dot uk 2005-02-09 11:06 --- Subject: Re: -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. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19836
[Bug preprocessor/19821] Preprocessor oom with nested vector operations
--- Additional Comments From neil at daikokuya dot co dot uk 2005-02-08 14:02 --- Subject: Re: New: Preprocessor oom with nested vector operations pochini at shiny dot it wrote:- > With 4 nested vec_add()'s gcc goes out of memory on my 512MB+1GBswap ppc box. > With 3 adds it consumes about 150MB of memory and eventually succeeds. The > preprocessor expands the y=... line into an exagerately huge expression. > fftw3 > fails to compile because of this. But it is ridiculously big. If you think it's expanding it wrong then please elaborate. Otherwise don't use brain-dead macros 8-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19821
[Bug preprocessor/19361] -MT option does not escape funny characters
--- Additional Comments From neil at daikokuya dot co dot uk 2005-01-10 15:01 --- Subject: Re: 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? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19361
[Bug preprocessor/19309] [3.4/4.0 Regression] Wrong documentation of predefined __GNUC__ with cpp invocation
--- Additional Comments From neil at daikokuya dot co dot uk 2005-01-07 21:44 --- Subject: Re: [3.4/4.0 Regression] Wrong documentation of predefined __GNUC__ with cpp invocation pinskia at gcc dot gnu dot org wrote:- > > --- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-07 > 14:00 --- > I don't know if this an excepted change, but either way the documention does > not match reality. > Oh, in 3.3.2 we did predefined those macros which is why this is a regression. This is a doc bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19309
[Bug preprocessor/17798] [3.4/4.0 Regression] high cpp memory usage with undefined symbols
--- Additional Comments From neil at daikokuya dot co dot uk 2004-12-14 13:57 --- Subject: Re: [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. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17798
[Bug preprocessor/15220] [3.3/3.4/4.0 regression] "gcc -E -MM -MG" reports missing system headers in source directory
--- Additional Comments From neil at daikokuya dot co dot uk 2004-11-28 00:50 --- Subject: Re: [3.3/3.4/4.0 regression] "gcc -E -MM -MG" reports missing system headers in source directory neroden at gcc dot gnu dot org wrote:- > > --- Additional Comments From neroden at gcc dot gnu dot org 2004-11-27 > 23:18 --- > Ow. The dependencies are emitted in open_file_failed in libcpp/files.c; but > that routine *doesn't know* whether the file was called for in a <> or a "" > directive. > > Fixing this requires some restructuring of libcpp code so that the > dependencies are emitted in a place which does know (perhaps the same place, > but that requires a lot of extra information passing). Note that current behaviour was discussed and agreed in a thread in 2003, on a previous bug report about prior behaviour. Neil. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15220
