[Bug c/20000] missing warning for noreturn function returning non-void
--- Additional Comments From zack at codesourcery dot com 2005-02-16 06:48 --- ... because the attribute used to get translated to a volatile qualifier on the function type, iirc. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2
[Bug middle-end/18785] [4.0 Regression] isdigit builtin function fails with EBCDIC character sets
--- Additional Comments From zack at codesourcery dot com 2005-02-20 17:07 --- Patch checked in. Related bugs remain, which should receive separate PRs. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18785
[Bug preprocessor/9449] UCNs not recognized in identifiers (c++/c99)
--- Additional Comments From zack at codesourcery dot com 2005-02-21 20:14 --- Subject: Re: UCNs not recognized in identifiers (c++/c99) "geoffk at geoffk dot org" <[EMAIL PROTECTED]> writes: > Although I agree that these are all (except the below) nice things to > have, I don't think I agree that they are all preconditions to having > any part of an implementation. For instance, an implementation that > said sorry() when using # on an identifier from a UCN would still be > more useful than the complete lack of implementation we have now. In my book, a complete lack of implementation of this particular feature is better than an incomplete one. This is because I see the vast majority of the work required to do a complete implementation as being due-diligence tasks needed to ensure that the feature cannot crash the compiler, cause wrong code generation, or introduce compatibility problems, and as long as someone is going to do all that work, why shouldn't they do the rest of the job as long as they're in there? > The second half would a pp-number, instead. It is always true that > splitting an identifier between characters yields two valid > preprocessing tokens. Joseph has mostly explained this, but I should add that what you get if you split, say, "a\u0660b", between the "a" and the backslash is two identifiers, the second of which's "initial character is a universal character name designating a digit", which violates a shall-clause in a semantics paragraph, and therefore provokes undefined behavior. (C99 6.4.2.1p3.) Standing policy is that all cases which provoke undefined behavior inside the preprocessor, except already-documented GNU extensions, shall produce hard errors. I am tempted to make a partial exception in this case in the interest of better compatibility with C++. Almost all of the UCNs in the "digits" block of C99 annex D are completely excluded from C++98 annex E - so "a\u0660b" for instance is an invalid identifier, and we never get as far as wondering what happens if we split it before the backslash. However, the range 0e50-0e59 is in the "Thai" range of C++98/E, but *both* the "Thai" and the "Digits" ranges of C99/D. It would be sensible, IMO, to resolve the error in C99/D by removing 0e50-0e59 from the "Digits" range, thus permitting those characters to begin identifiers in both C and C++. [Note that currently ucnid.tab takes the opposite position.] zw -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9449
[Bug preprocessor/9449] UCNs not recognized in identifiers (c++/c99)
--- Additional Comments From zack at codesourcery dot com 2005-02-21 20:23 --- Subject: Re: UCNs not recognized in identifiers (c++/c99) "geoffk at geoffk dot org" <[EMAIL PROTECTED]> writes: >>> The second half would a pp-number, instead. It is always true that >>> splitting an identifier between characters yields two valid >>> preprocessing tokens. >> >> It would not be a pp-number, as a UCN for a digit is still an >> identifier-nondigit rather than a digit in terms of the syntax and >> pp-numbers can't start with identifiers-nondigits. > > That's a defect in the standard, the tail of an identifier is supposed > to be either an identifier or a pp-number, that's why pp-number exists. Arguably yes. *shrug* You perhaps begin to see why I did not want this feature implemented? Or at least why I want it done with great caution and consideration of all these corner cases? Does your opinion of this particular corner case change in view of C++ not permitting most of the "digit" UCNs in identifiers at all? zw -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9449
[Bug preprocessor/9449] UCNs not recognized in identifiers (c++/c99)
--- Additional Comments From zack at codesourcery dot com 2005-02-21 20:54 --- Subject: Re: UCNs not recognized in identifiers (c++/c99) "geoffk at geoffk dot org" <[EMAIL PROTECTED]> writes: >>> The second half would a pp-number, instead. It is always true that >>> splitting an identifier between characters yields two valid >>> preprocessing tokens. >> >> Joseph has mostly explained this, but I should add that what you get >> if you split, say, "a\u0660b", between the "a" and the backslash is >> two identifiers, the second of which's "initial character is a >> universal character name designating a digit", which violates a >> shall-clause in a semantics paragraph, and therefore provokes >> undefined behavior. (C99 6.4.2.1p3.) > > A shall-clause in a semantics paragraph requires a diagnostic, C99 > 5.1.1.3. Um, no, 5.1.1.3 does not say that. It says a diagnostic is required for a violation of any "syntax rule or constraint"; shall-clauses in semantics paragraphs are neither. Constraints only appear in constraints paragraphs. See 4p2 for the meaning of shall-clauses outside constraints paragraphs. zw -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9449
[Bug target/20617] shared SH libgcc is exporting too many symbols
--- Additional Comments From zack at codesourcery dot com 2005-03-24 16:06 --- Subject: Re: shared SH libgcc is exporting too many symbols Why not just add the problematic symbols to sh/libgcc-excl.ver? That is what it is there for. zw -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20617
[Bug target/20617] [4.0/4.1 regression] shared SH libgcc is exporting too many symbols
--- Additional Comments From zack at codesourcery dot com 2005-03-24 18:46 --- Subject: Re: [4.0/4.1 regression] shared SH libgcc is exporting too many symbols "joern dot rennecke at st dot com" <[EMAIL PROTECTED]> writes: > Almost all the symbols in config/sh/lib1funcs.asm are problematic. > Moreover, adding a new function to lib1funcs.asm can inadvertantly > create a new exported symbol. It is much safer to make the symbols > by default not exported. You may want to consider use of LIB1FUNCS_ST instead of LIB1FUNCS, so that the symbols are not put into libgcc_s.so in the first place. > I'm currently working on merging most of the machine-dependent > patches from our sources into gcc 4.1 - that's a 400 KB patch - and > this will change most of the FUNC definitions in lib1funcs.asm to > HIDDEN_FUNC, and all the ALIAS defintions into HIDDEN_ALIAS, and > also change the way references to symbols in lib1funcs.asm are > generated, so that for some symbols GOT references are made rather > than PLT ones when compiling pic/PIC code. This sounds fine. I want to make sure that you understand the point of my patch to remove the local copy of libgcc-std.ver. From time to time new global symbols are added to libgcc2.c. Most of those are appropriately visible from libgcc_s.so; in some cases it can be essential that they are. If an architecture has a private copy of the version file, we have to remember to update it. I observed that people were forgetting to update SH's private copy, so I eliminated it. Note that the private copy that you had, did *not* exclude hundreds of lib1funcs.asm symbols. The only symbols not in it, that were in libgcc-std.ver, and were not due to people forgetting to update it, are the symbols currently listed in sh/libgcc-excl.ver. zw -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20617
[Bug target/20617] [4.0/4.1 regression] shared SH libgcc is exporting too many symbols
--- Additional Comments From zack at codesourcery dot com 2005-03-24 22:54 --- Subject: Re: [4.0/4.1 regression] shared SH libgcc is exporting too many symbols "joern dot rennecke at st dot com" <[EMAIL PROTECTED]> writes: [LIB1FUNCS_ST] > Won't this have the effect that any of the referenced symbols remain > undefined in libgc_s.so, and will get a GOT (and in 4.0 even a PLT > entry) in libgcc.so? You can avoid this problem by including libgcc.a in the final link of libgcc_s.so. Every global symbol in libgcc.a is or ought to be hidden (that being a goal of all the work I put in on libgcc construction last year) so the effect will be that libgcc_s.so gets private copies of everything that it actually uses, but nothing more. > I didn't say hundreds - I said some hundred. greps counts 94 hidden > functions ans aliases in my current lib1funcs.asm working copy. The > largest group, with 40 members, is probably the set of movstr* and > movmem* functions, none of which was mentioned in libgcc-std.ver > (and hence was excluded), and none of which is mentioned in > sh/libgcc-excl.ver (and hence is now included). It sounds like you are misunderstanding the way libgcc-excl.ver works? It subtracts from the set established by libgcc-std.ver, not from the set of all symbols that could be visible. (If this is not happening, there is a problem with your t-fragments or with mklibgcc.) zw -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20617
[Bug target/20617] [4.0/4.1 regression] shared SH libgcc is exporting too many symbols
--- Additional Comments From zack at codesourcery dot com 2005-03-24 23:54 --- Subject: Re: [4.0/4.1 regression] shared SH libgcc is exporting too many symbols "joern dot rennecke at st dot com" <[EMAIL PROTECTED]> writes: > So you are saying this needs to list only to-be-excluded symbols > that are mentioned in libgcc-std.ver, and all the other symbols from > lib1funcs.asm are automatically hidden? Yes, that is how it is supposed to work. If it isn't working that way, either mklibgcc or your t-fragment is buggy. > FWIW, __mulsi3 should also not be exported, although that is not a > regression. Feel free to add it to libgcc-excl.ver... zw -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20617
[Bug preprocessor/19475] [3.3/3.4/4.0/4.1 Regression] missing whitespace after macro name in C90 or C++
--- Additional Comments From zack at codesourcery dot com 2005-04-05 16:49 --- Subject: Re: [PATCH] Fix PR preprocessor/19475 Jakub Jelinek <[EMAIL PROTECTED]> writes: > Hi! > > This patch fixes PR preprocessor/19475 by issuing just warning, not pedwarn, > for < ISO C99 if there is no whitespace between macro definition and > replacement, but replacement starts with a basic character set character. > Ok to commit? OK except please remove the ?, ?= testcases as those tokens are probably going to be removed in the near future. zw -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19475
[Bug preprocessor/19475] [3.3/3.4/4.0/4.1 Regression] missing whitespace after macro name in C90 or C++
--- Additional Comments From zack at codesourcery dot com 2005-04-05 17:05 --- Subject: Re: [PATCH] Fix PR preprocessor/19475 Jakub Jelinek <[EMAIL PROTECTED]> writes: > On Tue, Apr 05, 2005 at 09:49:19AM -0700, Zack Weinberg wrote: >> > This patch fixes PR preprocessor/19475 by issuing just warning, not >> > pedwarn, >> > for < ISO C99 if there is no whitespace between macro definition and >> > replacement, but replacement starts with a basic character set character. >> > Ok to commit? >> >> OK except please remove the ?, ?= testcases as those tokens >> are probably going to be removed in the near future. > > I know, but that IMHO shouldn't matter for the testcase. > #define a should be still treated like > #define a in C90 (with a warning), no matter whether http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19475
[Bug preprocessor/19475] [3.3/3.4/4.0 Regression] missing whitespace after macro name in C90 or C++
--- Additional Comments From zack at codesourcery dot com 2005-04-05 23:39 --- Subject: Re: [PATCH] Fix PR preprocessor/19475 Per Bothner <[EMAIL PROTECTED]> writes: > http://gcc.gnu.org/ml/gcc-patches/2005-04/msg00183.html Yah, check that in already. zw -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19475
[Bug target/20617] [4.0/4.1 regression] shared SH libgcc is exporting too many symbols
--- Additional Comments From zack at codesourcery dot com 2005-04-06 20:03 --- Subject: Re: [4.0/4.1 regression] shared SH libgcc is exporting too many symbols "amylaar at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes: > I just had a look, and actually there appears to be no variable called > LIB1FUNCS_ST. ... so add one. zw -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20617
[Bug target/20617] [4.0/4.1 regression] shared SH libgcc is exporting too many symbols
-- What|Removed |Added CC|zack at codesourcery dot com| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20617
[Bug debug/914] libgcc2 compile causes internal error for mips-wrs-vxworks
--- Additional Comments From zack at codesourcery dot com 2005-06-14 07:09 --- Subject: Re: libgcc2 compile causes internal error for mips-wrs-vxworks The target will eventually be readded, but you might as well close the bug - it hasn't shown up in our internal testing, so it's probably dead. zw -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=914
[Bug preprocessor/9449] UCNs not recognized in identifiers (c++/c99)
--- Additional Comments From zack at codesourcery dot com 2004-12-16 02:16 --- Subject: Re: gcc and UCN in identifiers: bug PR 9449 Al Simons <[EMAIL PROTECTED]> writes: > Hi, Zack. > > I'm looking into adding UCN support for identifiers into the HP > C/C++ compiler, and wondered if there is any new status on your > implementation / design? We'd like to do things the same way if at > all possible. I don't intend to implement this feature until the C committee, the C++ committee, and the Unicode committee all agree on which Unicode character sequences are legitimate in identifiers and what sort of canonicalization is to be performed. As long as there is no agreement, implementation of this feature risks indeterminacy in shared library ABIs. Suppose that the identifier "get_length_in_Ångstroms" is part of a shared library's public interface. The Å might be U+212B, U+00C5, or U+0041 U+030A. Suppose further that the person who implemented the shared library used a text editor that generates NFD, so the library header reads U+0041 U+030A. But their compiler normalizes to NFC on input, so the name in the shared library's symbol table reads U+00C5. Now someone comes along with a compiler that does no normalization whatsoever and tries to use the library. They're going to get a link error and they're not going to know why. Worse, if someone recompiles the library with a compiler that chose to normalize to NFD, its ABI silently changes. Joseph Myers insists that this situation cannot arise, because C99/C++'s lists of valid Unicode code points in identifiers exclude all combining forms. But if I enforce those rules users will hate the compiler, because their text editors will generate what looks like perfectly fine text and then the compiler will barf on it. And I am not prepared to trust that every editor on the planet will adhere to C99/C++'s rules. And even if I were, we'd still have the problem of the C99 and C++ lists not being identical. > There is a link in the bug report that appears to be broken; any > chance you can hook it back up? > > <<http://www.codesourcery.com/lists?2:mss:1481:danfdfbkjoaahbcmmeam>http://www.codesourcery.com/lists?2:mss:1481:danfdfbkjoaahbcmmeam> My best guess is that this is now <http://www.codesourcery.com/archives/cxx-abi-dev/msg00676.html>. This is mostly about how to mangle non-ASCII characters in identifiers to get them past limited linkers, and doesn't offer any help with the problems I described above. zw -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9449
[Bug preprocessor/9449] UCNs not recognized in identifiers (c++/c99)
--- Additional Comments From zack at codesourcery dot com 2004-12-16 03:03 --- Subject: Re: UCNs not recognized in identifiers (c++/c99) Because of the ABI implications, I consider it completely unacceptable to implement this feature according to the letter of C99 or C++98. Ever. Once the "oddities" are resolved at the standards level, I will consider supporting the feature as resolved, but *only* as resolved. zw -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9449
[Bug c++/17964] [4.0 Regression] cpp error messages contain wrong line in C++
--- Additional Comments From zack at codesourcery dot com 2005-02-09 02:28 --- I am testing a patch for this bug now. -- What|Removed |Added Status|NEW |ASSIGNED Last reconfirmed|2005-01-11 13:34:31 |2005-02-09 02:28:52 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17964
[Bug c++/18491] testsuite failure: WARNING: g++.old-deja/g++.mike/p10769a.C compilation failed to produce executable
--- Additional Comments From zack at codesourcery dot com 2005-02-09 23:58 --- There is also p10769b.C (in the same directory) with exactly the same dubious construct, this time marked as should-give-an-error. Do we want to keep that one? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18491
[Bug target/17982] [4.0 regression] asm declaration ignored due to conflict with previous rename
--- Additional Comments From zack at codesourcery dot com 2004-10-13 23:29 --- Subject: Re: [4.0 regression] asm declaration ignored due to conflict with previous rename Hmm. Why are we calling assemble_external before EOF? zw -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17982
[Bug c++/18047] [4.0 Regression] Wrong precedence between equality (==, !=) and < operators
--- Additional Comments From zack at codesourcery dot com 2004-10-18 15:02 --- Subject: Re: [4.0 Regression] Wrong precedence between equality (==, !=) and < operators I doubt that. I'd be inclined to point fingers at the operator-precedence parser patch, myself. zw -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18047
[Bug target/6123] __pic__/__PIC__ not defined when -fpic/-fPIC is specified
--- Additional Comments From zack at codesourcery dot com 2004-11-08 21:23 --- Subject: Re: __pic__/__PIC__ not defined when -fpic/-fPIC is specified Ah. This is why I thought it had already been done. Maybe you want to poke Alan Modra about the research he said he would do? zw -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6123
[Bug middle-end/17982] [4.0 regression] asm declaration ignored due to conflict with previous rename
--- Additional Comments From zack at codesourcery dot com 2004-11-23 22:19 --- Subject: Re: [4.0 regression] asm declaration ignored due to conflict with previous rename "hjl at lucon dot org" <[EMAIL PROTECTED]> writes: > --- Additional Comments From hjl at lucon dot org 2004-11-23 21:13 > --- > Does this patch > > --- gcc/c-pragma.c.rename 2004-11-09 12:03:42.0 -0800 > +++ gcc/c-pragma.c 2004-11-23 13:03:26.020304351 -0800 > @@ -473,8 +473,11 @@ maybe_apply_renaming_pragma (tree decl, > return asmname; > >/* If the DECL_ASSEMBLER_NAME is already set, it does not change, > - but we may warn about a rename that conflicts. */ > - if (DECL_ASSEMBLER_NAME_SET_P (decl)) > + but we may warn about a rename that conflicts. > + FIXME: the DECL_ASSEMBLER_NAME can be set to DECL_NAME (decl) > + without renaming pragma nor asm declaration involved. */ This will not work. At this point ia64 has already emitted an external-reference directive for the old name into the assembly stream. The necessary fix is to prevent assemble_external from ever being called before EOF. zw -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17982
[Bug middle-end/17982] [4.0 regression] asm declaration ignored due to conflict with previous rename
--- Additional Comments From zack at codesourcery dot com 2004-11-27 20:25 --- Subject: Re: [4.0 regression] asm declaration ignored due to conflict with previous rename That's not what HJ's patch does, though. zw -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17982
[Bug preprocessor/16621] [4.0 Regression] C4x fails miserably
--- Additional Comments From zack at codesourcery dot com 2004-11-27 20:25 --- Subject: Re: [4.0 Regression] C4x fails miserably I have no plans to do anything about this bug. Someone who cares about C4x should look at it. zw -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16621
[Bug middle-end/17982] [4.0 regression] asm declaration ignored due to conflict with previous rename
--- Additional Comments From zack at codesourcery dot com 2004-11-28 20:16 --- Subject: Re: [4.0 regression] asm declaration ignored due to conflict with previous rename You continue not to get it. In this context, DECL_ASSEMBLER_NAME has been set because assemble_external has been called on the symbol. assemble_external is *not* a no-op on ia64. It emits a directive to the assembly output, using the name of the symbol. It is *not* safe to rename the symbol after that has happened. That you are not seeing a problem on ia64-linux is either because GAS isn't as picky as the reference assembler, or because your test case is not stringent enough. zw -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17982
[Bug middle-end/17982] [4.0 regression] asm declaration ignored due to conflict with previous rename
--- Additional Comments From zack at codesourcery dot com 2004-11-29 16:38 --- Subject: Re: [4.0 regression] asm declaration ignored due to conflict with previous rename ... so this has always been broken, is that what you're saying? zw -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17982
[Bug middle-end/17982] [4.0 regression] asm declaration ignored due to conflict with previous rename
--- Additional Comments From zack at codesourcery dot com 2004-11-29 17:15 --- Subject: Re: [4.0 regression] asm declaration ignored due to conflict with previous rename I'm hoping to have some time to work on this this week, but no promises. zw -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17982
