Fix hitrate of indirect call predictor
Hi, this patch fixes hitrate of indirect call predictor according to Martin's measurements. Boostrapped/regtested x86_64-linux, comitted. Honza PR middle-end/77484 * predict.def (PRED_INDIR_CALL): Set to 86. Index: predict.def === --- predict.def (revision 244206) +++ predict.def (working copy) @@ -121,7 +121,7 @@ DEF_PREDICTOR (PRED_CALL, "call", HITRAT /* PRED_CALL is not very reliable predictor and it turns out to be even less reliable for indirect calls and polymorphic calls. For spec2k6 the predictio nis slightly in the direction of taking the call. */ -DEF_PREDICTOR (PRED_INDIR_CALL, "indirect call", HITRATE (51), 0) +DEF_PREDICTOR (PRED_INDIR_CALL, "indirect call", HITRATE (86), 0) DEF_PREDICTOR (PRED_POLYMORPHIC_CALL, "polymorphic call", HITRATE (59), 0) /* Recursive calls are usually not taken or the function will recurse
New Swedish PO file for 'gcc' (version 7.1-b20170101)
Hello, gentle maintainer. This is a message from the Translation Project robot. A revised PO file for textual domain 'gcc' has been submitted by the Swedish team of translators. The file is available at: http://translationproject.org/latest/gcc/sv.po (This file, 'gcc-7.1-b20170101.sv.po', has just now been sent to you in a separate email.) All other PO files for your package are available in: http://translationproject.org/latest/gcc/ Please consider including all of these in your next release, whether official or a pretest. Whenever you have a new distribution with a new version number ready, containing a newer POT file, please send the URL of that distribution tarball to the address below. The tarball may be just a pretest or a snapshot, it does not even have to compile. It is just used by the translators when they need some extra translation context. The following HTML page has been updated: http://translationproject.org/domain/gcc.html If any question arises, please contact the translation coordinator. Thank you for all your work, The Translation Project robot, in the name of your translation coordinator.
Re: [PATCH] PR 78534 Change character length from int to size_t
> r244027 reverts r244011. Sorry for the breakage. It seems to affect > all i686 as well in addition to power, maybe all 32-bit hosts. For the record, I see the following failures with an instrumented r244026 (as in pr78672) FAIL: gfortran.dg/char_length_20.f90 -O* execution test FAIL: gfortran.dg/char_length_21.f90 -O* execution test FAIL: gfortran.dg/repeat_2.f90 -O1 execution test … FAIL: gfortran.dg/repeat_2.f90 -Os execution test FAIL: gfortran.dg/widechar_6.f90 -O1 execution test … FAIL: gfortran.dg/widechar_6.f90 -Os execution test FAIL: gfortran.dg/widechar_intrinsics_6.f90 -O* execution test The run time failures are all of the kind = ==43614==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60200168 at pc 0x00010abfb578 bp 0x7fff55735250 sp 0x7fff55735248 READ of size 8 at 0x60200168 thread T0 #0 0x10abfb577 in _gfortran_string_len_trim (/opt/gcc/gcc7gp/lib/libgfortran.4.dylib+0x728577) #1 0x10a4cae2c in MAIN__ (/Users/dominiq/Documents/Fortran/g95bench/win/f90/bug/a.out+0x10e2c) #2 0x10a4caea6 in main (/Users/dominiq/Documents/Fortran/g95bench/win/f90/bug/a.out+0x10ea6) #3 0x7fffbd674254 in start (/usr/lib/system/libdyld.dylib+0x5254) 0x60200168 is located 8 bytes to the left of 1-byte region [0x60200170,0x60200171) allocated by thread T0 here: #0 0x10c043319 in wrap_malloc (/opt/gcc/gcc7a/lib/libasan.4.dylib+0x61319) #1 0x10a4cad11 in MAIN__ (/Users/dominiq/Documents/Fortran/g95bench/win/f90/bug/a.out+0x10d11) #2 0x10a4caea6 in main (/Users/dominiq/Documents/Fortran/g95bench/win/f90/bug/a.out+0x10ea6) #3 0x7fffbd674254 in start (/usr/lib/system/libdyld.dylib+0x5254) SUMMARY: AddressSanitizer: heap-buffer-overflow (/opt/gcc/gcc7gp/lib/libgfortran.4.dylib+0x728577) in _gfortran_string_len_trim Shadow bytes around the buggy address: 0x1c03ffd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x1c03ffe0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x1c03fff0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x1c04: fa fa fd fd fa fa fd fd fa fa 00 07 fa fa 00 06 0x1c040010: fa fa 03 fa fa fa 00 00 fa fa 00 06 fa fa 06 fa =>0x1c040020: fa fa 07 fa fa fa 07 fa fa fa fd fa fa[fa]01 fa 0x1c040030: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x1c040040: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x1c040050: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x1c040060: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x1c040070: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user:f7 Container overflow: fc Array cookie:ac Intra object redzone:bb ASan internal: fe Left alloca redzone: ca Right alloca redzone:cb ==43614==ABORTING Program received signal SIGABRT: Process abort signal. Backtrace for this error: #0 0x10a4d8558 #1 0x10a4d65f5 #2 0x7fffbd881bb9 Abort Dominique
Re: [PATCH, i386]: Fix PR 78967, inserts are not effective
> The patch also tightens scan-assembler patterns in a couple of pr78904 > testcases. This caused https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79026. TIA Dominique
[contrib,Java] Remove contrib/download_ecj
Committed. Gerald 2017-01-08 Gerald Pfeifer * download_ecj: Remove. Index: download_ecj === --- download_ecj(revision 244208) +++ download_ecj(nonexistent) @@ -1,25 +0,0 @@ -#! /bin/sh - -# -# Download the ecj jar file needed by gcj. -# Run this from the top level of the gcc source tree and the libjava -# build will do the right thing. -# -# (C) 2006 Free Software Foundation -# -# This script is Free Software, and it can be copied, distributed and -# modified as defined in the GNU General Public License. A copy of -# its license can be downloaded from http://www.gnu.org/copyleft/gpl.html -# - -ftp -n sourceware.org << EOF -verbose -hash -user ftp '' -cd /pub/java -binary -get ecj-latest.jar -EOF - -mv ecj-latest.jar ecj.jar - Property changes on: download_ecj ___ Deleted: svn:executable ## -1 +0,0 ## -* \ No newline at end of property
Re: [PATCH] avoid infinite recursion in maybe_warn_alloc_args_overflow (pr 78775)
On 01/06/2017 09:45 AM, Jeff Law wrote:
On 01/05/2017 08:52 PM, Martin Sebor wrote:
So Richi asked for removal of the VR_ANTI_RANGE handling, which would
imply removal of operand_signed_p.
What are the implications if we do that?
I just got back to this yesterday. The implications of the removal
of the anti-range handling are a number of false negatives in the
test suite:
I was thinking more at a higher level. ie, are the warnings still
useful if we don't have the anti-range handling? I suspect so, but
would like to hear your opinion.
...
n = ~[-4, MAX]; (I.e., n is either negative or too big.)
p = malloc (n);
Understood. The low level question is do we get these kinds of ranges
often enough in computations leading to allocation sizes?
My intuition tells me that they are likely common enough not to
disregard but I don't have a lot of data to back it up with. In
a Bash build a full 23% of all checked calls are of this kind (24
out of 106). In a Binutils build only 4% are (9 out of 228). In
Glibc, a little under 3%. My guess is that the number will be
inversely proportional to the quality of the code.
So I think you've made a case that we do want to handle this case. So
what's left is how best to avoid the infinite recursion and mitigate the
pathological cases.
What you're computing seems to be "this object may have been derived
from a signed type". Right? It's a property we can compute for any
given SSA_NAME and it's not context/path specific beyond the
context/path information encoded by the SSA graph.
So just thinking out load here, could we walk the IL once to identify
call sites and build a worklist of SSA_NAMEs we care about. Then we
iterate on the worklist much like Aldy's code he's working on for the
unswitching vs uninitialized variable issue?
Thanks for the suggestion. It occurred to me while working on the fix
for 78973 (the non-bug) that size ranges should be handled the same by
-Wstringop-overflow as by -Walloc-size-larger-than, and that both have
the same problem: missing or incomplete support for anti-ranges. The
attached patch moves get_size_range() from builtins.c to calls.c and
adds better support for anti-ranges. That solves the problems also
lets it get rid of the objectionable operand_positive_p function.
Martin
PS The change to the alloc_max_size function is only needed to make
it possible to specify any argument to the -Walloc-size-larger-than
option, including 0 and -1, so that allocations of any size, including
zero can be flagged.
PR tree-optimization/78775 - [7 Regression] ICE in maybe_warn_alloc_args_overflow
gcc/ChangeLog:
PR tree-optimization/78775
* builtins.c (get_size_range): Move...
* calls.c: ...to here.
(alloc_max_size): Accept zero argument.
(operand_signed_p): Remove.
(maybe_warn_alloc_args_overflow): Call get_size_range.
* calls.h (get_size_range): Declare.
gcc/testsuite/ChangeLog:
PR tree-optimization/78775
* gcc.dg/attr-alloc_size-4.c: Add test cases.
* gcc.dg/pr78775.c: New test.
* gcc.dg/pr78973-2.c: New test.
* gcc.dg/pr78973.c: New test.
diff --git a/gcc/builtins.c b/gcc/builtins.c
index 5b76dfd..bf68e31 100644
--- a/gcc/builtins.c
+++ b/gcc/builtins.c
@@ -3031,42 +3031,6 @@ expand_builtin_memcpy_args (tree dest, tree src, tree len, rtx target, tree exp)
return dest_addr;
}
-/* Fill the 2-element RANGE array with the minimum and maximum values
- EXP is known to have and return true, otherwise null and return
- false. */
-
-static bool
-get_size_range (tree exp, tree range[2])
-{
- if (tree_fits_uhwi_p (exp))
-{
- range[0] = range[1] = exp;
- return true;
-}
-
- if (TREE_CODE (exp) == SSA_NAME)
-{
- wide_int min, max;
- enum value_range_type range_type = get_range_info (exp, &min, &max);
-
- if (range_type == VR_RANGE)
- {
- /* Interpret the bound in the variable's type. */
- range[0] = wide_int_to_tree (TREE_TYPE (exp), min);
- range[1] = wide_int_to_tree (TREE_TYPE (exp), max);
- return true;
- }
- else if (range_type == VR_ANTI_RANGE)
- {
- /* FIXME: Handle anti-ranges. */
- }
-}
-
- range[0] = NULL_TREE;
- range[1] = NULL_TREE;
- return false;
-}
-
/* Try to verify that the sizes and lengths of the arguments to a string
manipulation function given by EXP are within valid bounds and that
the operation does not lead to buffer overflow. Arguments other than
diff --git a/gcc/calls.c b/gcc/calls.c
index b7bbec5..c0d60bb 100644
--- a/gcc/calls.c
+++ b/gcc/calls.c
@@ -1197,92 +1197,189 @@ alloc_max_size (void)
{
alloc_object_size_limit = TYPE_MAX_VALUE (ssizetype);
- unsigned HOST_WIDE_INT unit = 1;
-
- char *end;
- errno = 0;
- unsigned HOST_WIDE_INT limit
- = warn_alloc_size_limit ? strtoull (warn_alloc_size_limit, &end, 10) : 0;
-
- if (limit && !errno)
+ if (warn_alloc_size_limit)
{
- if (end && *end)
+ char *end = NULL;
+ errno = 0;
+ unsigned HOST_WIDE_INT unit = 1;
+
New Danish PO file for 'gcc' (version 7.1-b20170101)
Hello, gentle maintainer. This is a message from the Translation Project robot. A revised PO file for textual domain 'gcc' has been submitted by the Danish team of translators. The file is available at: http://translationproject.org/latest/gcc/da.po (This file, 'gcc-7.1-b20170101.da.po', has just now been sent to you in a separate email.) All other PO files for your package are available in: http://translationproject.org/latest/gcc/ Please consider including all of these in your next release, whether official or a pretest. Whenever you have a new distribution with a new version number ready, containing a newer POT file, please send the URL of that distribution tarball to the address below. The tarball may be just a pretest or a snapshot, it does not even have to compile. It is just used by the translators when they need some extra translation context. The following HTML page has been updated: http://translationproject.org/domain/gcc.html If any question arises, please contact the translation coordinator. Thank you for all your work, The Translation Project robot, in the name of your translation coordinator.
Re: [PATCH] move snprintf truncation warnings under own option ()
PR tree-optimization/78913 - Probably misleading error reported by -Wformat-length PR middle-end/77708 - -Wformat-length %s warns for snprintf gcc/c-family/ChangeLog: PR tree-optimization/78913 PR middle-end/77708 * c.opt (-Wformat-truncation): New option. gcc/testsuite/ChangeLog: PR tree-optimization/78913 PR middle-end/77708 * gcc.dg/tree-ssa/builtin-snprintf-warn-1.c: New test. * gcc.dg/tree-ssa/builtin-snprintf-warn-2.c: New test. * gcc.dg/tree-ssa/builtin-sprintf-warn-6.c: XFAIL test cases failing due to bug 78969. gcc/ChangeLog: PR tree-optimization/78913 PR middle-end/77708 * doc/invoke.texi (Warning Options): Document -Wformat-truncation. * gimple-ssa-sprintf.c (call_info::reval_used, call_info::warnopt): New member functions. (format_directive): Used them. (add_bytes): Sam (pass_sprintf_length::handle_gimple_call): Same. OK. jeff Thanks. The option exposed a few instances of possible unchecked truncation in GCC that I had missed, most likely because I'd looked at the test results for one of my other patches by mistake. Since the fixes were all trivial and involved increasing local buffers by a few bytes I committed the result in r244210 without posting the updated patch for review first. Martin
[doc, committed] (finally) fix -pthread documentation
Returning to a patch I first posted about a month ago: the conclusion
seemed to be that -pthread needed to be documented with both the linker
and preprocessor options. Now that I've gotten the existing cpp options
documentation at least somewhat cleaned up of other cruft :-) I've
checked in this patch to fix the -pthread docs.
-Sandra
2017-01-08 Sandra Loosemore
PR other/16519
gcc/
* doc/invoke.texi (Option Summary): Move -pthread to Linker Options
and Preprocessor Options.
(Options for Linking): Document -pthread here
(RS/6000 and PowerPC Options): ...not here.
(Solaris 2 Options): ...or here.
* doc/cppopts.texi: Document -pthread.
Index: gcc/doc/cppopts.texi
===
--- gcc/doc/cppopts.texi (revision 244213)
+++ gcc/doc/cppopts.texi (working copy)
@@ -69,6 +69,13 @@ standard predefined macros remain define
@xref{Standard Predefined Macros}.
@end ifset
+@item -pthread
+@opindex pthread
+Define additional macros required for using the POSIX threads library.
+You should use this option consistently for both compilation and linking.
+This option is supported on GNU/Linux targets, most other Unix derivatives,
+and also on x86 Cygwin and MinGW targets.
+
@item -M
@opindex M
@cindex @command{make}
Index: gcc/doc/invoke.texi
===
--- gcc/doc/invoke.texi (revision 244213)
+++ gcc/doc/invoke.texi (working copy)
@@ -475,7 +475,7 @@ Objective-C and Objective-C++ Dialects}.
-fwide-exec-charset=@var{charset} -fworking-directory @gol
-H -imacros @var{file} -include @var{file} @gol
-M -MD -MF -MG -MM -MMD -MP -MQ -MT @gol
--no-integrated-cpp -P -remap @gol
+-no-integrated-cpp -P -pthread -remap @gol
-traditional -traditional-cpp -trigraphs @gol
-U@var{macro} -undef @gol
-Wp,@var{option} -Xpreprocessor @var{option}}
@@ -487,7 +487,7 @@ Objective-C and Objective-C++ Dialects}.
@item Linker Options
@xref{Link Options,,Options for Linking}.
@gccoptlist{@var{object-file-name} -fuse-ld=@var{linker} -l@var{library} @gol
--nostartfiles -nodefaultlibs -nostdlib -pie -rdynamic @gol
+-nostartfiles -nodefaultlibs -nostdlib -pie -pthread -rdynamic @gol
-s -static -static-libgcc -static-libstdc++ @gol
-static-libasan -static-libtsan -static-liblsan -static-libubsan @gol
-static-libmpx -static-libmpxwrappers @gol
@@ -1023,7 +1023,7 @@ See RS/6000 and PowerPC Options.
-mfloat-gprs=yes -mfloat-gprs=no -mfloat-gprs=single -mfloat-gprs=double @gol
-mprototype -mno-prototype @gol
-msim -mmvme -mads -myellowknife -memb -msdata @gol
--msdata=@var{opt} -mvxworks -G @var{num} -pthread @gol
+-msdata=@var{opt} -mvxworks -G @var{num} @gol
-mrecip -mrecip=@var{opt} -mno-recip -mrecip-precision @gol
-mno-recip-precision @gol
-mveclibabi=@var{type} -mfriz -mno-friz @gol
@@ -1096,7 +1096,7 @@ See RS/6000 and PowerPC Options.
@emph{Solaris 2 Options}
@gccoptlist{-mclear-hwcap -mno-clear-hwcap -mimpure-text -mno-impure-text @gol
--pthreads -pthread}
+-pthreads}
@emph{SPARC Options}
@gccoptlist{-mcpu=@var{cpu-type} @gol
@@ -11566,6 +11566,14 @@ or model suboptions) when you specify th
@opindex no-pie
Don't produce a position independent executable.
+@item -pthread
+@opindex pthread
+Link with the POSIX threads library. This option is supported on
+GNU/Linux targets, most other Unix derivatives, and also on
+x86 Cygwin and MinGW targets. On some targets this option also sets
+flags for the preprocessor, so it should be used consistently for both
+compilation and linking.
+
@item -rdynamic
@opindex rdynamic
Pass the flag @option{-export-dynamic} to the ELF linker, on targets
@@ -22040,11 +22048,6 @@ reliably associate function call with ar
TLS optimization, which in turn allows GCC to better schedule the
sequence.
-@item -pthread
-@opindex pthread
-Adds support for multithreading with the @dfn{pthreads} library.
-This option sets flags for both the preprocessor and linker.
-
@item -mrecip
@itemx -mno-recip
@opindex mrecip
@@ -23186,14 +23189,7 @@ These switches are supported in addition
@table @gcctabopt
@item -pthreads
@opindex pthreads
-Add support for multithreading using the POSIX threads library. This
-option sets flags for both the preprocessor and linker. This option does
-not affect the thread safety of object code produced by the compiler or
-that of libraries supplied with it.
-
-@item -pthread
-@opindex pthread
-This is a synonym for @option{-pthreads}.
+This is a synonym for @option{-pthread}.
@end table
@node SPARC Options
[doc, committed] add xref to documentation of mode attribute
I've checked in this patch to fix another long-standing (but easy)
documentation PR.
-Sandra
2017-01-08 Sandra Loosemore
PR middle-end/17660
gcc/
* extend.texi (Common Variable Attributes): Add xref to GCC
Internals manual to explain mode attribute keywords.
Index: gcc/doc/extend.texi
===
--- gcc/doc/extend.texi (revision 244213)
+++ gcc/doc/extend.texi (working copy)
@@ -5725,6 +5725,8 @@ This attribute specifies the data type f
type corresponds to the mode @var{mode}. This in effect lets you
request an integer or floating-point type according to its width.
+@xref{Machine Modes,,, gccint, GNU Compiler Collection (GCC) Internals},
+for a list of the possible keywords for @var{mode}.
You may also specify a mode of @code{byte} or @code{__byte__} to
indicate the mode corresponding to a one-byte integer, @code{word} or
@code{__word__} for the mode of a one-word integer, and @code{pointer}
Re: [PATCH] avoid infinite recursion in maybe_warn_alloc_args_overflow (pr 78775)
On 01/08/2017 02:04 PM, Martin Sebor wrote:
On 01/06/2017 09:45 AM, Jeff Law wrote:
On 01/05/2017 08:52 PM, Martin Sebor wrote:
So Richi asked for removal of the VR_ANTI_RANGE handling, which would
imply removal of operand_signed_p.
What are the implications if we do that?
I just got back to this yesterday. The implications of the removal
of the anti-range handling are a number of false negatives in the
test suite:
I was thinking more at a higher level. ie, are the warnings still
useful if we don't have the anti-range handling? I suspect so, but
would like to hear your opinion.
...
n = ~[-4, MAX]; (I.e., n is either negative or too big.)
p = malloc (n);
Understood. The low level question is do we get these kinds of ranges
often enough in computations leading to allocation sizes?
My intuition tells me that they are likely common enough not to
disregard but I don't have a lot of data to back it up with. In
a Bash build a full 23% of all checked calls are of this kind (24
out of 106). In a Binutils build only 4% are (9 out of 228). In
Glibc, a little under 3%. My guess is that the number will be
inversely proportional to the quality of the code.
So I think you've made a case that we do want to handle this case. So
what's left is how best to avoid the infinite recursion and mitigate the
pathological cases.
What you're computing seems to be "this object may have been derived
from a signed type". Right? It's a property we can compute for any
given SSA_NAME and it's not context/path specific beyond the
context/path information encoded by the SSA graph.
So just thinking out load here, could we walk the IL once to identify
call sites and build a worklist of SSA_NAMEs we care about. Then we
iterate on the worklist much like Aldy's code he's working on for the
unswitching vs uninitialized variable issue?
Thanks for the suggestion. It occurred to me while working on the fix
for 78973 (the non-bug) that size ranges should be handled the same by
-Wstringop-overflow as by -Walloc-size-larger-than, and that both have
the same problem: missing or incomplete support for anti-ranges. The
attached patch moves get_size_range() from builtins.c to calls.c and
adds better support for anti-ranges. That solves the problems also
lets it get rid of the objectionable operand_positive_p function.
Martin
PS The change to the alloc_max_size function is only needed to make
it possible to specify any argument to the -Walloc-size-larger-than
option, including 0 and -1, so that allocations of any size, including
zero can be flagged.
gcc-78775.diff
PR tree-optimization/78775 - [7 Regression] ICE in
maybe_warn_alloc_args_overflow
gcc/ChangeLog:
PR tree-optimization/78775
* builtins.c (get_size_range): Move...
* calls.c: ...to here.
(alloc_max_size): Accept zero argument.
(operand_signed_p): Remove.
(maybe_warn_alloc_args_overflow): Call get_size_range.
* calls.h (get_size_range): Declare.
gcc/testsuite/ChangeLog:
PR tree-optimization/78775
* gcc.dg/attr-alloc_size-4.c: Add test cases.
* gcc.dg/pr78775.c: New test.
* gcc.dg/pr78973-2.c: New test.
* gcc.dg/pr78973.c: New test.
+
+ wide_int min, max;
+ enum value_range_type range_type = get_range_info (exp, &min, &max);
+
+ tree exptype = TREE_TYPE (exp);
+ unsigned expprec = TYPE_PRECISION (exptype);
+ wide_int wzero = wi::zero (expprec);
+
+ /* Set SIGNED_P once (will be used by recursive calls). */
+ if (signed_p < 0)
+signed_p = !TYPE_UNSIGNED (exptype);
+
+ if (range_type == VR_VARYING)
{
- gimple *def = SSA_NAME_DEF_STMT (op);
- if (is_gimple_assign (def))
+ /* No range information available. */
+ range[0] = NULL_TREE;
+ range[1] = NULL_TREE;
+ return false;
+}
Might as well move this range_type test earlier since it doesn't use
exptype, expprec, wzero or signed_p.
OK with that change.
jeff
Re: [PATCH] better handling of ranges (PR 78703)
On 12/23/2016 02:25 PM, Martin Sebor wrote:
Bug 78703 points out that the decimal point character in floating
directives can be longer than just one byte (in locales where the
decimal point is a multibyte character). The decimal point can
result in anywhere between 1 and MB_LEN_MAX bytes. This is unlikely
but locales with two-byte decimal point are known to exist, and
the gimple-ssa-sprintf pass must handle them correctly.
In a comment on the bug Jakub suggests that while printf return
value optimization must correctly deal with the worst case (i.e.,
MB_LEN_MAX of 6 for UTF-8), reflecting the worst case in the text
of warnings could be confusing to users most of whom expect
a single byte decimal point.
Finally, a limitation of the gimple-ssa-sprintf pass has been that
it only understands constant width and precision and treats others
as essentially unlimited even if they are constrained to a limited
range of values. This results in false positives and negatives
that can be avoided.
The attached patch enhances the pass to overcome both of these
limitations. It does that by first replacing the exact byte counter
with two other counters: 1) a likely counter that tracks the number
of bytes a directive is likely to result in, and 2) an "unlikely"
byte for lack of a better name, that tracks the unlikely maximum
byte count in cases like multibyte decimal point, and second by
adding range handling for width and precision specified by the
asterisk (such as in sprintf("%*.*i", w, p, i)).
The patch resulted in more extensive changes than I initially
intended but the result is a simplified implementation. A good
amount of the changes is factoring code out into more general
functions that can be shared throughout the pass.
With these enhancements, although the support for ranges in the
pass is complete, it's not as robust as it could be. I think
having the pass run later could improve things.
The pass does produce a fair number of warnings for calls to
snprintf in the linux kernel. Some of these I suspect will be
considered false positives. I think it might be worth splitting
up the snprintf warning from -Wformat-length and adding a separate
option to control it.
Martin
gcc-78703.diff
PR middle-end/78703 - -fprintf-return-value floating point handling incorrect
in locales with a mulltibyte decimal point
gcc/ChangeLog:
PR middle-end/78703
* gimple-ssa-sprintf.c (get_int_range): New function.
(struct result_range): Add members.
(struct format_result): Replace number_chars, number_chars_min, and
number_chars_max, with struct result_ramge. Remove constant.
(format_result::operator+=): Update and define out of class.
(struct fmtresult): Add constructors. Remove constant and bounded
members.
(format_result::type_max_digits): New function.
(format_result::adjust_for_width_and_precision): New function.
(struct conversion_spec): Rename...
(struct directive): ...to this.
(struct directive): Add new data members.
(directive::set_width, directive::set_precison): New functions.
(bytes_remaining, get_int_range, format_character, format_plain): Same.
(should_warn_p, maybe_warn, parse_directive): Same.
(min_bytes_remaining, add_bytes): Remove.
(format_percent, get_string_length): Simplify.
(format_integer): Handle width and precision ranges.
(format_floating): Same.
(get_mpfr_format_length): Work around MPFR bugs and simplify.
(format_string): Factor single character handling into
format_character. Handle width and precision ranges.
(format_directive): Factor out most warning code into maybe_warn.
(pass_sprintf_length::compute_format_length): Factor out parsing
into parse_directive.
(try_substitute_return_value): Handle unlikely maximum byte counter.
Simplify for better clarity.
gcc/testsuite/ChangeLog:
PR middle-end/78703
* gcc.dg/tree-ssa/builtin-sprintf-2.c: Adjust.
* gcc.dg/tree-ssa/builtin-sprintf-5.c: Same.
* gcc.dg/tree-ssa/builtin-sprintf-warn-1.c: Same.
* gcc.dg/tree-ssa/builtin-sprintf-warn-2.c: Same.
* gcc.dg/tree-ssa/builtin-sprintf-warn-3.c: Same.
* gcc.dg/tree-ssa/builtin-sprintf-warn-4.c: Same.
* gcc.dg/tree-ssa/builtin-sprintf-warn-7.c: Same.
* gcc.dg/tree-ssa/builtin-sprintf-warn-9.c: New test.
* gcc.dg/tree-ssa/builtin-sprintf.c: Adjust.
* gcc.dg/format/pr78569.c: Same.
+ /* Get the real type format desription for the target. */
s/desription/description/
@@ -1613,24 +1738,23 @@ get_string_length (tree str)
if (lenrange [0] || lenrange [1])
{
- fmtresult res;
+ fmtresult res (tree_fits_uhwi_p (lenrange[0])
+? tree_to_uhwi (lenrange[0]) : 1 < warn_format_length,
Ordering of operands.
+ else if (0 < min && min < 128)
Order
[doc, committed] fix Option Summary formatting in invoke.texi
This documentation patch only has boring formatting changes.
I spotted some over-long lines in the Option Summary section in the PDF
version of the GCC manual. While I was fixing that up, I saw that
several places were also inconsistent about whether to use one space or
two to separate options in the list. I did a mechanical
search-and-replace to uniformly use two spaces.
There are some overfull hbox warnings elsewhere in the manual, too; I'll
take a look at those separately.
-Sandra
2017-01-08 Sandra Loosemore
gcc/
* invoke.texi (Option Summary): Correct spacing in option lists
and add line breaks to fix over-long lines.
Index: gcc/doc/invoke.texi
===
--- gcc/doc/invoke.texi (revision 244214)
+++ gcc/doc/invoke.texi (working copy)
@@ -172,26 +172,26 @@ in the following sections.
@gccoptlist{-c -S -E -o @var{file} -x @var{language} @gol
-v -### --help@r{[}=@var{class}@r{[},@dots{}@r{]]} --target-help --version @gol
-pass-exit-codes -pipe -specs=@var{file} -wrapper @gol
-@@@var{file} -fplugin=@var{file} -fplugin-arg-@var{name}=@var{arg} @gol
--fdump-ada-spec@r{[}-slim@r{]} -fada-spec-parent=@var{unit} -fdump-go-spec=@var{file}}
+@@@var{file} -fplugin=@var{file} -fplugin-arg-@var{name}=@var{arg} @gol
+-fdump-ada-spec@r{[}-slim@r{]} -fada-spec-parent=@var{unit} -fdump-go-spec=@var{file}}
@item C Language Options
@xref{C Dialect Options,,Options Controlling C Dialect}.
@gccoptlist{-ansi -std=@var{standard} -fgnu89-inline @gol
-fpermitted-flt-eval-methods=@var{standard} @gol
--aux-info @var{filename} -fallow-parameterless-variadic-functions @gol
--fno-asm -fno-builtin -fno-builtin-@var{function} -fgimple@gol
--fhosted -ffreestanding -fopenacc -fopenmp -fopenmp-simd @gol
--fms-extensions -fplan9-extensions -fsso-struct=@var{endianness}
--fallow-single-precision -fcond-mismatch -flax-vector-conversions @gol
+-aux-info @var{filename} -fallow-parameterless-variadic-functions @gol
+-fno-asm -fno-builtin -fno-builtin-@var{function} -fgimple@gol
+-fhosted -ffreestanding -fopenacc -fopenmp -fopenmp-simd @gol
+-fms-extensions -fplan9-extensions -fsso-struct=@var{endianness} @gol
+-fallow-single-precision -fcond-mismatch -flax-vector-conversions @gol
-fsigned-bitfields -fsigned-char @gol
-funsigned-bitfields -funsigned-char}
@item C++ Language Options
@xref{C++ Dialect Options,,Options Controlling C++ Dialect}.
@gccoptlist{-fabi-version=@var{n} -fno-access-control @gol
--faligned-new=@var{n} -fargs-in-order=@var{n} -fcheck-new @gol
--fconstexpr-depth=@var{n} -fconstexpr-loop-limit=@var{n} @gol
+-faligned-new=@var{n} -fargs-in-order=@var{n} -fcheck-new @gol
+-fconstexpr-depth=@var{n} -fconstexpr-loop-limit=@var{n} @gol
-ffriend-injection @gol
-fno-elide-constructors @gol
-fno-enforce-eh-specs @gol
@@ -204,7 +204,7 @@ in the following sections.
-fno-nonansi-builtins -fnothrow-opt -fno-operator-names @gol
-fno-optional-diags -fpermissive @gol
-fno-pretty-templates @gol
--frepo -fno-rtti -fsized-deallocation @gol
+-frepo -fno-rtti -fsized-deallocation @gol
-ftemplate-backtrace-limit=@var{n} @gol
-ftemplate-depth=@var{n} @gol
-fno-threadsafe-statics -fuse-cxa-atexit @gol
@@ -213,13 +213,13 @@ in the following sections.
-fvisibility-ms-compat @gol
-fext-numeric-literals @gol
-Wabi=@var{n} -Wabi-tag -Wconversion-null -Wctor-dtor-privacy @gol
--Wdelete-non-virtual-dtor -Wliteral-suffix -Wmultiple-inheritance @gol
--Wnamespaces -Wnarrowing @gol
--Wnoexcept -Wnon-virtual-dtor -Wreorder -Wregister @gol
--Weffc++ -Wstrict-null-sentinel -Wtemplates @gol
+-Wdelete-non-virtual-dtor -Wliteral-suffix -Wmultiple-inheritance @gol
+-Wnamespaces -Wnarrowing @gol
+-Wnoexcept -Wnon-virtual-dtor -Wreorder -Wregister @gol
+-Weffc++ -Wstrict-null-sentinel -Wtemplates @gol
-Wno-non-template-friend -Wold-style-cast @gol
-Woverloaded-virtual -Wno-pmf-conversions @gol
--Wsign-promo -Wvirtual-inheritance}
+-Wsign-promo -Wvirtual-inheritance}
@item Objective-C and Objective-C++ Language Options
@xref{Objective-C and Objective-C++ Dialect Options,,Options Controlling
@@ -249,8 +249,8 @@ Objective-C and Objective-C++ Dialects}.
@gccoptlist{-fmessage-length=@var{n} @gol
-fdiagnostics-show-location=@r{[}once@r{|}every-line@r{]} @gol
-fdiagnostics-color=@r{[}auto@r{|}never@r{|}always@r{]} @gol
--fno-diagnostics-show-option -fno-diagnostics-show-caret @gol
--fdiagnostics-parseable-fixits -fdiagnostics-generate-patch @gol
+-fno-diagnostics-show-option -fno-diagnostics-show-caret @gol
+-fdiagnostics-parseable-fixits -fdiagnostics-generate-patch @gol
-fno-show-column}
@item Warning Options
@@ -258,59 +258,59 @@ Objective-C and Objective-C++ Dialects}.
@gccoptlist{-fsyntax-only -fmax-errors=@var{n} -Wpedantic @gol
-pedantic-errors @gol
-w -Wextra -Wall -Waddress -Waggregate-return @gol
--Walloc-zero -Walloc-size-larger-than=@var{n}
--Walloca -Walloca-larger-t
Re: [PATCH] Implement P0393R3
On Tue, Jan 3, 2017 at 6:17 AM, Jonathan Wakely wrote:
> On 01/01/17 04:17 -0800, Tim Shen via libstdc++ wrote:
>>
>> +#define _VARIANT_RELATION_FUNCTION_TEMPLATE(__op, __name) \
>> + template \
>> +constexpr bool operator __op(const variant<_Types...>& __lhs, \
>> +const variant<_Types...>& __rhs) \
>> +{ \
>> + return __lhs._M##__name(__rhs,
>> std::index_sequence_for<_Types...>{}); \
>> +} \
>> +\
>> + constexpr bool operator __op(monostate, monostate) noexcept \
>> + { return 0 __op 0; }
>> +
>> + _VARIANT_RELATION_FUNCTION_TEMPLATE(<, _erased_less_than)
>> + _VARIANT_RELATION_FUNCTION_TEMPLATE(<=, _erased_less_equal)
>> + _VARIANT_RELATION_FUNCTION_TEMPLATE(==, _erased_equal)
>> + _VARIANT_RELATION_FUNCTION_TEMPLATE(!=, _erased_not_equal)
>> + _VARIANT_RELATION_FUNCTION_TEMPLATE(>=, _erased_greater_than)
>> + _VARIANT_RELATION_FUNCTION_TEMPLATE(>, _erased_greater)
>
>
> These need double underscore prefixes.
Done.
>
> Still reviewing the rest ...
>
--
Regards,
Tim Shen
commit fba8c3c8cca773a501766aff90b13f72e42d9355
Author: Tim Shen
Date: Sun Jan 1 04:07:15 2017 -0800
2017-01-01 Tim Shen
PR libstdc++/78723
* include/std/variant: Implement P0393R3.
* testsuite/20_util/variant/compile.cc: Adjust tests.
* testsuite/20_util/variant/run.cc: Adjust tests.
diff --git a/libstdc++-v3/include/std/variant b/libstdc++-v3/include/std/variant
index 3d025a7..9ca61d6 100644
--- a/libstdc++-v3/include/std/variant
+++ b/libstdc++-v3/include/std/variant
@@ -263,21 +263,23 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
swap(__ref_cast<_Lhs>(__lhs), __ref_cast<_Rhs>(__rhs));
}
- template
-constexpr bool
-__erased_equal_to(_Variant&& __lhs, _Variant&& __rhs)
-{
- return __get<_Np>(std::forward<_Variant>(__lhs))
- == __get<_Np>(std::forward<_Variant>(__rhs));
+#define _VARIANT_RELATION_FUNCTION_TEMPLATE(__op, __function_name) \
+ template \
+constexpr bool \
+__function_name(const _Variant& __lhs, const _Variant& __rhs) \
+{ \
+ return __get<_Np>(std::forward<_Variant>(__lhs)) \
+ __op __get<_Np>(std::forward<_Variant>(__rhs)); \
}
- template
-constexpr bool
-__erased_less_than(const _Variant& __lhs, const _Variant& __rhs)
-{
- return __get<_Np>(std::forward<_Variant>(__lhs))
- < __get<_Np>(std::forward<_Variant>(__rhs));
-}
+ _VARIANT_RELATION_FUNCTION_TEMPLATE(<, __erased_less_than)
+ _VARIANT_RELATION_FUNCTION_TEMPLATE(<=, __erased_less_equal)
+ _VARIANT_RELATION_FUNCTION_TEMPLATE(==, __erased_equal)
+ _VARIANT_RELATION_FUNCTION_TEMPLATE(!=, __erased_not_equal)
+ _VARIANT_RELATION_FUNCTION_TEMPLATE(>=, __erased_greater_than)
+ _VARIANT_RELATION_FUNCTION_TEMPLATE(>, __erased_greater)
+
+#undef _VARIANT_RELATION_FUNCTION_TEMPLATE
template
constexpr size_t
@@ -800,63 +802,31 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
return get_if<__detail::__variant::__index_of_v<_Tp, _Types...>>(__ptr);
}
- template
-constexpr bool operator==(const variant<_Types...>& __lhs,
- const variant<_Types...>& __rhs)
-{
- return __lhs._M_equal_to(__rhs, std::index_sequence_for<_Types...>{});
-}
-
- template
-constexpr inline bool
-operator!=(const variant<_Types...>& __lhs, const variant<_Types...>&
__rhs)
-{ return !(__lhs == __rhs); }
-
- template
-constexpr inline bool
-operator<(const variant<_Types...>& __lhs, const variant<_Types...>& __rhs)
-{
- return __lhs._M_less_than(__rhs, std::index_sequence_for<_Types...>{});
-}
-
- template
-constexpr inline bool
-operator>(const variant<_Types...>& __lhs, const variant<_Types...>& __rhs)
-{ return __rhs < __lhs; }
-
- template
-constexpr inline bool
-operator<=(const variant<_Types...>& __lhs, const variant<_Types...>&
__rhs)
-{ return !(__lhs > __rhs); }
+ struct monostate { };
- template
-constexpr inline bool
-operator>=(const variant<_Types...>& __lhs, const variant<_Types...>&
__rhs)
-{ return !(__lhs < __rhs); }
+#define _VARIANT_RELATION_FUNCTION_TEMPLATE(__op, __name) \
+ template \
+constexpr bool operator __op(const variant<_Types...>& __lhs, \
+const variant<_Types...>& __rhs) \
+{ \
+ return __lhs._M##__name(__rhs, std::index_sequence_for<_Types...>{}); \
+} \
+\
+ constexpr bool operator __op(monostate, monostate) noexcept \
+ { return 0 __op 0; }
+
+ _VARIANT_RELATION_FUNCTION_TEMPLATE(<, __erased_less_than)
+ _VARIANT_RELATION_FUNCTION_TEMPLATE(<=, __erased_less_equal)
+ _VARIANT_RELATION_FUNCTION_TEMPLATE(==, __erased_equal)
+ _VARIANT_RELATION_FUNCTION_TEMPLATE(!=, __erased_not_equal)
+ _VARIANT_RELATION_FUNCTION_TEMPLATE(>=, __erased_greater_than)
+ _VARIANT_RELATION_FUNCTION_TEMPLATE(>, __erased_greater)
+
+#undef _VARIANT_RELATION_FUNCTION_TEMPLATE
tem
