summaryrefslogtreecommitdiffstats
path: root/contrib/gcc/c-common.c
Commit message (Collapse)AuthorAgeFilesLines
* Use the stock 3.2.1-prerelease file.kan2002-09-011-14/+29
| | | | Approved by: obrien
* Use the stock 3.1-prerelease file.obrien2002-05-091-10/+142
|
* We use the stock 3.1-snap file now.obrien2002-02-011-2162/+2955
| | | | All the -Wformat related code moved to c-format.c.
* Teach gcc about '%+' so it will not warn when using '%+' in a formatobrien2001-05-251-1/+1
| | | | | | | string when using strftime(), since our libc supports it. PR: 26827 Submitted by: Marc Olzheim <marcolz@ilse.nl>
* Clarify that the "yields only last 2 digits of year in some locales" warningobrien2000-04-181-1/+1
| | | | | | does not apply to BSD. Submitted by: ache
* From FSFChangeLog: (tfaff): Now a function, not a string. All users changed.obrien2000-04-181-2/+2
| | | | | | | | | I did not catch this on the EGCS 1.1.x --> GCC 2.95 upgrade. So propogate this change to our custom hacks. PR: 15549 Submitted by: Naohiko Tsuji <yakisoba@osaka.interq.or.jp> Patrick Bihan-Faou <patrick@mindstep.com>
* Merge our -fformat-extensions and printf0() into GCC 2.95.2.obrien1999-11-011-4/+48
|
* Merge our -fformat-extensions and printf0() into GCC 2.95.1.obrien1999-10-161-88/+322
|
* Don't accept %q length specifiers in the kernel (more precisely,obrien1999-08-271-1/+2
| | | | | | | | | | | | | | | | | | | | | | | if compiling with -fformat-extensions). Gcc's format checker never actually supported %q length specifiers. It treats %q as an alias for %ll, which is correct if quad_t is long long (e.g., on i386's) and broken otherwise (e.g., on alphas). quad_t's currently should be printed in the same way that they already need to be printed to avoid compiler warnings on all supported systems: cast them to a standard type that is at least as large (long or long long) and use the length specifier for that (%l or %ll). This is problematic since long long isn't standard yet. C9x's intmax_t should be implemented soon. Don't accept %L length specifiers in the kernel either. The only legitimate ones are for long doubles, but the kernel doesn't even support plain doubles. (gcc bogusly accepts %Ld as an alias for %lld, and it sometimes prints "q" in error messages about "ll" and "L" length specifiers, becauses it represents all these specifiers as 'q'.) Submitted by: bde
* Fixed kernel format checking:obrien1999-08-271-3/+3
| | | | | | | | | | | | - plain %r and %z were disallowed. The hard NULs in the warnings were hopefully caused by disallowing of plain formats being nonsense. - new formats for shortening to a byte were allowed, but even the libc printf doesn't support them. - old %hr and %hz formats were allowed, but the kernel printf doesn't support them. The kernel doesn't support %hd either, but this is harder to fix. Submitted by: bde
* Fix conflicts.obrien1999-08-271-260/+983
| | | | | This brings revs 1.2 (-fformat-extensions) and 1.3 (printf0()) into EGCS 1.1.2.
* Support printf format checking of FreeBSD kernel formats %[Dbrz].bde1998-08-241-2/+60
| | | | | | | | | | | | This is enabled by the undocumented option -fformat-extensions. This option should be named better and/or give more control over the extensions. Fixed a message - don't warn about the field width when it's the precision that has the wrong type. Didn't fix excessive checking for the precision relative to the type - ANSI requires both to be ints, but gcc permits the field width to be either int or unsigned int.
* Add support for a new archetype "printf0" for the "format" functionjdp1998-07-151-15/+36
| | | | | | | | | | attribute. It is like the existing "printf" archetype, except that it doesn't complain if the format string is a null pointer. See the node "Function Attributes" in the GCC info pages if you don't know what this is all about. This change will allow us to add format string checking for the err(3) family of functions.
* Import of unmodified (but trimmed) gcc-2.7.2. The bigger parts of thepeter1996-09-181-0/+2255
non-i386, non-unix, and generatable files have been trimmed, but can easily be added in later if needed. gcc-2.7.2.1 will follow shortly, it's a very small delta to this and it's handy to have both available for reference for such little cost. The freebsd-specific changes will then be committed, and once the dust has settled, the bmakefiles will be committed to use this code.
OpenPOWER on IntegriCloud