[C++ PATCH] Extend the list of implicit noexcept C library symbols for -std=c++11 and -std=c++17 (PR middle-end/78901)
Hi!
C++ says that C library functions are implicitly noexcept, except for those
like qsort and bsearch where exceptions can be thrown from the callbacks.
We handle this through cfns.gperf, but that contains only list of C89
functions, while C++11 and C++14 refer to C99 and C++17 refers to C11.
I went through the C99 and C11 standards, gathered all functions from there
(not macros nor generic functions) and using gperf %struct-type feature
attached the C version next to each symbol, so that e.g. snprintf is
noexcept only with -std=c++11 and above and e.g. mbrtoc16 only with
-std=c++17. Without this, we still consider snprintf as potentially
throwing, which breaks gimple-ssa-sprintf.c assumptions. For -std=c++98
snprintf is not considered a builtin.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2016-12-23 Jakub Jelinek
PR middle-end/78901
* except.c (nothrow_libfn_p): Expect libc_name_p to return
const struct libc_name_struct *, if it returns NULL, return 0,
otherwise check c_ver and use flag_isoc99 or flag_isoc11.
* cfns.gperf: Add %struct-type and libc_name_struct definition.
For all C89 C library functions add , 89 after the name, add
C99 C library functions with , 99 and C11 C library functions
with , 11 suffix.
* cfns.h: Regenerated.
--- gcc/cp/except.c.jj 2016-10-31 13:28:11.0 +0100
+++ gcc/cp/except.c 2016-12-23 01:29:52.390997316 +0100
@@ -892,8 +892,17 @@ nothrow_libfn_p (const_tree fn)
unless the system headers are playing rename tricks, and if
they are, we don't want to be confused by them. */
id = DECL_NAME (fn);
- return !!libc_name::libc_name_p (IDENTIFIER_POINTER (id),
- IDENTIFIER_LENGTH (id));
+ const struct libc_name_struct *s
+= libc_name::libc_name_p (IDENTIFIER_POINTER (id), IDENTIFIER_LENGTH (id));
+ if (s == NULL)
+return 0;
+ switch (s->c_ver)
+{
+case 89: return 1;
+case 99: return flag_isoc99;
+case 11: return flag_isoc11;
+default: gcc_unreachable ();
+}
}
/* Returns nonzero if an exception of type FROM will be caught by a
--- gcc/cp/cfns.gperf.jj2016-02-19 23:16:32.0 +0100
+++ gcc/cp/cfns.gperf 2016-12-23 01:18:23.377729732 +0100
@@ -1,5 +1,6 @@
%language=C++
%define class-name libc_name
+%struct-type
%{
/* Copyright (C) 2000-2016 Free Software Foundation, Inc.
@@ -19,6 +20,7 @@ You should have received a copy of the G
along with GCC; see the file COPYING3. If not see
Re: [PATCH] PR 78534 Change character length from int to size_t
On Wed, Dec 21, 2016 at 3:14 PM, Andre Vehreschild wrote:
>> Now when I think about this some more, I have a vague recollection
>> that a long time ago it used to be something like that. The problem
>> is that MIN_EXPR will of course be
>> NON-CONSTANT, so the memcpy call can't be inlined. Hence it was
>> changed to two separate __builtin_memmove() calls to have better
>> opportunity to inline. So probably a no-go to change it back. :(
>
> I don't get that. From the former only one of the memmove's could have been
> inlined assuming that only CONSTANT sizes are inlined.
Yes. Which is better than not being able to inline, assuming the
inlined branch is more likely to be taken, no?
> The other one had a
> NON-CONSTANT as long as pointer following and constant propagation was not
> effective together. In our case the "NON-CONSTANT branch" would have been
> used,
> which is resolved by constant propagation (of the size of constant memory p
> points to). I assume the warning is triggered, because dead-code elimination
> has not removed the else part.
Probably yes, in this case. My performance worries were more about the
general case. But perhaps they are unfounded, IDK really. Does anybody
have a battery of string operation benchmarks that mirrors how real
Fortran code does string handling?
Anyway, the attached patch accomplishes that. It turns the tree dump I
showed two days ago into something like
{
integer(kind=8) D.3484;
unsigned long D.3485;
D.3484 = *_p;
D.3485 = (unsigned long) D.3484 + 18446744073709551608;
if (D.3484 != 0)
{
__builtin_memmove ((void *) *p, (void *) &"12345679"[1]{lb: 1
sz: 1}, MIN_EXPR <(unsigned long) D.3484, 8>);
if ((unsigned long) D.3484 > 8)
{
__builtin_memset ((void *) *p + 8, 32, D.3485);
}
}
}
and gets rid of the -Wstringop-overflow warning. (It causes a two new
testsuite failures (gfortran.dg/dependency_49.f90 and
gfortran.dg/transfer_intrinsic_1.f90), but those are just tests that
grep for patterns in the .original dump and need to be adjusted).
If that is Ok, do you prefer it as part of the charlen-size_t patch,
or would you (GFortran maintainers in general) prefer that it's a
separate patch?
--
Janne Blomqvist
diff --git a/gcc/fortran/trans-expr.c b/gcc/fortran/trans-expr.c
index 3767a28..6708ee03 100644
--- a/gcc/fortran/trans-expr.c
+++ b/gcc/fortran/trans-expr.c
@@ -6455,33 +6455,19 @@ gfc_trans_string_copy (stmtblock_t * block, tree
dlength, tree dest,
return;
}
+ /* The string copy algorithm below generates code like
+
+ if (dlen > 0) {
+ memmove (dest, src, min(dlen, slen));
+ if (slen < dlen)
+ memset(&dest[slen], ' ', dlen - slen);
+ }
+ */
+
/* Do nothing if the destination length is zero. */
cond = fold_build2_loc (input_location, GT_EXPR, boolean_type_node, dlen,
build_int_cst (size_type_node, 0));
- /* The following code was previously in _gfortran_copy_string:
-
- // The two strings may overlap so we use memmove.
- void
- copy_string (GFC_INTEGER_4 destlen, char * dest,
-GFC_INTEGER_4 srclen, const char * src)
- {
- if (srclen >= destlen)
- {
- // This will truncate if too long.
- memmove (dest, src, destlen);
- }
- else
- {
- memmove (dest, src, srclen);
- // Pad with spaces.
- memset (&dest[srclen], ' ', destlen - srclen);
- }
- }
-
- We're now doing it here for better optimization, but the logic
- is the same. */
-
/* For non-default character kinds, we have to multiply the string
length by the base type size. */
chartype = gfc_get_char_type (dkind);
@@ -6504,17 +6490,19 @@ gfc_trans_string_copy (stmtblock_t * block, tree
dlength, tree dest,
else
src = gfc_build_addr_expr (pvoid_type_node, src);
- /* Truncate string if source is too long. */
- cond2 = fold_build2_loc (input_location, GE_EXPR, boolean_type_node, slen,
- dlen);
+ /* First do the memmove. */
+ tmp2 = fold_build2_loc (input_location, MIN_EXPR, TREE_TYPE (dlen), dlen,
+ slen);
tmp2 = build_call_expr_loc (input_location,
builtin_decl_explicit (BUILT_IN_MEMMOVE),
- 3, dest, src, dlen);
+ 3, dest, src, tmp2);
+ stmtblock_t tmpblock2;
+ gfc_init_block (&tmpblock2);
+ gfc_add_expr_to_block (&tmpblock2, tmp2);
- /* Else copy and pad with spaces. */
- tmp3 = build_call_expr_loc (input_location,
- builtin_decl_explicit (BUILT_IN_MEMMOVE),
- 3, dest, src, slen);
+ /* If the destination is longer, fill the end with spaces. */
+ cond2 = fold_build2_loc (input_location, LT_EXPR, boolean_type_node, slen,
+
RE: [PATCH, testsuite] MIPS: Cleanup the forcing of assembly output in error tests.
> From: Catherine Moore > > > > > gcc/testsuite/ChangeLog: > > > > * gcc.target/mips/oddspreg-2.c (dg-options): Remove dg-skip-if > > for > > -fno-fat-lto-objects and add the -ffat-lto-objects option, along > > with > > an explanation for its purpose. > > * gcc.target/mips/oddspreg-3.c (dg-options): Likewise. > > * gcc.target/mips/oddspreg-6.c (dg-options): Likewise. > > * gcc.target/mips/no-dsp-1.c: Add an explanation for the > > purpose of > > -ffat-lto-objects. > > * gcc.target/mips/pr54240.c: Likewise. > > * gcc.target/mips/r10k-cache-barrier-14.c: Likewise. > > * gcc.target/mips/soft-float-1.c: Likewise. > > > > This is OK. Thank you for reviewing this so close to the holidays. Committed as r243908. Regards, Toma
Re: [PATCH, Fortran, alloc_poly, v2] Fix allocation of memory for polymorphic assignment
Hi Janus, hi all,
thanks for the review. Committed as r243909.
Regards,
Andre
On Thu, 22 Dec 2016 23:26:19 +0100
Janus Weil wrote:
> 2016-12-20 17:07 GMT+01:00 Andre Vehreschild :
> > Hi Janus,
> >
> >> 1) After adding that code block in gfc_trans_assignment_1, it seems
> >> like the comment above is outdated, right?
> >
> > Thanks for noting.
> >
> >> 2) Wouldn't it be better to move this block, which does the correct
> >> allocation for CLASS variables, into
> >> "alloc_scalar_allocatable_for_assignment", where the allocation for
> >> all other cases is done?
> >
> > I tried to, but that would have meant to extend the interface of
> > alloc_scalar_allocatable_for_assignment significantly, while at the location
> > where I finally added the code, I could use the data available. Secondly
> > putting the malloc at the correct location is not possible at
> > alloc_scalar_... because the pre-blocks have already been joined to the
> > body. That way the malloc was always placed either before even the vptr was
> > set, or after the data was copied. Both options were quite hazardous.
> >
> > I now went to add the allocation into trans_class_assignment (). This allows
> > even more reuse of already present and needed data, e.g., the vptr.
> >
> > Bootstrapped and regtested ok on x86_64-linux/f23. Ok for trunk?
>
> Thanks for the explanations. The patch is ok with me in this form.
>
> Cheers,
> Janus
--
Andre Vehreschild * Email: vehre ad gmx dot de
Index: gcc/fortran/trans-expr.c
===
--- gcc/fortran/trans-expr.c (Revision 243908)
+++ gcc/fortran/trans-expr.c (Arbeitskopie)
@@ -9625,18 +9625,39 @@
static tree
trans_class_assignment (stmtblock_t *block, gfc_expr *lhs, gfc_expr *rhs,
- gfc_se *lse, gfc_se *rse, bool use_vptr_copy)
+ gfc_se *lse, gfc_se *rse, bool use_vptr_copy,
+ bool class_realloc)
{
- tree tmp;
- tree fcn;
- tree stdcopy, to_len, from_len;
+ tree tmp, fcn, stdcopy, to_len, from_len, vptr;
vec *args = NULL;
- tmp = trans_class_vptr_len_assignment (block, lhs, rhs, rse, &to_len,
+ vptr = trans_class_vptr_len_assignment (block, lhs, rhs, rse, &to_len,
&from_len);
- fcn = gfc_vptr_copy_get (tmp);
+ /* Generate allocation of the lhs. */
+ if (class_realloc)
+{
+ stmtblock_t alloc;
+ tree class_han;
+ tmp = gfc_vptr_size_get (vptr);
+ class_han = GFC_CLASS_TYPE_P (TREE_TYPE (lse->expr))
+ ? gfc_class_data_get (lse->expr) : lse->expr;
+ gfc_init_block (&alloc);
+ gfc_allocate_using_malloc (&alloc, class_han, tmp, NULL_TREE);
+ tmp = fold_build2_loc (input_location, EQ_EXPR,
+ boolean_type_node, class_han,
+ build_int_cst (prvoid_type_node, 0));
+ tmp = fold_build3_loc (input_location, COND_EXPR, void_type_node,
+ gfc_unlikely (tmp,
+ PRED_FORTRAN_FAIL_ALLOC),
+ gfc_finish_block (&alloc),
+ build_empty_stmt (input_location));
+ gfc_add_expr_to_block (&lse->pre, tmp);
+}
+
+ fcn = gfc_vptr_copy_get (vptr);
+
tmp = GFC_CLASS_TYPE_P (TREE_TYPE (rse->expr))
? gfc_class_data_get (rse->expr) : rse->expr;
if (use_vptr_copy)
@@ -9961,15 +9982,10 @@
}
if (is_poly_assign)
-{
- tmp = trans_class_assignment (&body, expr1, expr2, &lse, &rse,
-use_vptr_copy || (lhs_attr.allocatable
- && !lhs_attr.dimension));
- /* Modify the expr1 after the assignment, to allow the realloc below.
- Therefore only needed, when realloc_lhs is enabled. */
- if (flag_realloc_lhs && !lhs_attr.pointer)
- gfc_add_data_component (expr1);
-}
+tmp = trans_class_assignment (&body, expr1, expr2, &lse, &rse,
+ use_vptr_copy || (lhs_attr.allocatable
+ && !lhs_attr.dimension),
+ flag_realloc_lhs && !lhs_attr.pointer);
else if (flag_coarray == GFC_FCOARRAY_LIB
&& lhs_caf_attr.codimension && rhs_caf_attr.codimension
&& ((lhs_caf_attr.allocatable && lhs_refs_comp)
@@ -10011,7 +10027,8 @@
if (lss == gfc_ss_terminator)
{
/* F2003: Add the code for reallocation on assignment. */
- if (flag_realloc_lhs && is_scalar_reallocatable_lhs (expr1))
+ if (flag_realloc_lhs && is_scalar_reallocatable_lhs (expr1)
+ && !is_poly_assign)
alloc_scalar_allocatable_for_assignment (&block, string_length,
expr1, expr2);
Index: gcc/fortran/ChangeLog
===
--- gcc/fortran/ChangeLog (Revision 243908)
+++ gcc/fortran/ChangeLog (Arbeitskopie)
@@ -1,3 +1,10 @@
+2016-12-23 Andre Vehreschild
+
+ * trans-expr.c (trans_class_assignment): Allocate memory of _vptr->size
+before assigning an allocatable class object.
+ (gfc_trans_assignment_1): Flag that (re-)alloc of the class object
+ shall be done.
+
2016-12-21 Jakub Jelinek
PR fortran/78866
Index: gcc/testsuite/gfortran.dg/class_assign_1.f08
==
Re: [testsuite,committed] Fix prototype of memset in a test case.
On 22.12.2016 19:20, Richard Sandiford wrote:
Georg-Johann Lay writes:
One test case used unsigned long for the 3rd parameter of memset, which
should be size_t. This made the test crash for targets where correct
parameter passing depends on correct prototypes.
Fixed and committed as obvious.
Catching up on backlog, but... I'm not sure this counts as obvious
if the crash was an ICE. We should at least fail gracefully.
The crash I mentioned happened on avr where parameter passing needs
correct prototypes. The code crashed when executed on avr because
a long gets passed in regs R22..R25 (LSBs first) but a size_t is
passed in R24..R25. Hence the implementation of memset would pick
up the upper two bytes of the length (zero) which crashes when run.
PR30778 was about wrong-code because more than the specified number
of bytes were written. It was reported for x64_64 where we have
size_t = unsigned long, hence the change is a no-op on the platform
the PR was originally reported against (similar for x86 where
size_t = unsigned).
Moreover, the test case is condensed from GCC's combine.c and I'd
expect that GCC's header are using correct prototypes :-)
Johann
Thanks,
Richard
Johann
gcc/testsuite/
* gcc.c-torture/execute/pr30778.c (memset): Use size_t for 3rd
parameter in declaration.
Index: gcc.c-torture/execute/pr30778.c
===
--- gcc.c-torture/execute/pr30778.c (revision 242541)
+++ gcc.c-torture/execute/pr30778.c (working copy)
@@ -1,4 +1,4 @@
-extern void *memset (void *, int, unsigned long);
+extern void *memset (void *, int, __SIZE_TYPE__);
extern void abort (void);
struct reg_stat {
PR78631 fix
Hi Ilya,
Would that patch be OK to submit? (it is HJ's one with added testcase)
diff --git a/gcc/testsuite/gcc.target/i386/mpx/memcpy-1.c
b/gcc/testsuite/gcc.target/i386/mpx/memcpy-1.c
new file mode 100644
index 000..1691348
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/mpx/memcpy-1.c
@@ -0,0 +1,23 @@
+/* { dg-do run } */
+/* { dg-shouldfail "bounds violation" } */
+/* { dg-options "-fcheck-pointer-bounds -mmpx" } */
+
+/* Fix for PR78631 */
+
+#define SHOULDFAIL
+
+#include
+#include
+
+char s[10];
+char d[10];
+__attribute__((noinline))
+
+char* foo(char* dst, char* src, size_t size) {
+ return memcpy(dst, src, size);
+}
+int main() {
+ char* r = foo(d, s, 11);
+ printf("r = %p\n", r);
+ return 0;
+}
diff --git a/libmpx/mpxwrap/libtool-version b/libmpx/mpxwrap/libtool-version
index fab30fb..e241350 100644
--- a/libmpx/mpxwrap/libtool-version
+++ b/libmpx/mpxwrap/libtool-version
@@ -3,4 +3,4 @@
# a separate file so that version updates don't involve re-running
# automake.
# CURRENT:REVISION:AGE
-2:0:0
+2:1:0
diff --git a/libmpx/mpxwrap/mpx_wrappers.c b/libmpx/mpxwrap/mpx_wrappers.c
index 171a780..aea0346 100644
--- a/libmpx/mpxwrap/mpx_wrappers.c
+++ b/libmpx/mpxwrap/mpx_wrappers.c
@@ -30,14 +30,20 @@
#include
#include "mpxrt/mpxrt.h"
-void *
-__mpx_wrapper_malloc (size_t size)
+/* Since internal MPX wrapper calls must avoid PLT which will clear bound
+ registers, we make them static with an external alias. */
+#define EXTERN_ALIAS(f) \
+ __typeof (f) __##f __attribute__((alias(#f)));
+
+static void *
+mpx_wrapper_malloc (size_t size)
{
void *p = (void *)malloc (size);
if (!p) return __bnd_null_ptr_bounds (p);
return __bnd_set_ptr_bounds (p, size);
}
+EXTERN_ALIAS (mpx_wrapper_malloc)
void *
__mpx_wrapper_mmap (void *addr, size_t length, int prot, int flags,
@@ -52,7 +58,7 @@ void *
__mpx_wrapper_realloc (void *ptr, size_t n)
{
if (!ptr)
-return __mpx_wrapper_malloc (n);
+return mpx_wrapper_malloc (n);
/* We don't kwnow how much data is copied by realloc
and therefore may check only lower bounds. */
@@ -74,8 +80,8 @@ __mpx_wrapper_calloc (size_t n_elements, size_t element_size)
return __bnd_set_ptr_bounds (p, n_elements * element_size);
}
-void *
-__mpx_wrapper_memset (void *dstpp, int c, size_t len)
+static void *
+mpx_wrapper_memset (void *dstpp, int c, size_t len)
{
if (len > 0)
{
@@ -85,10 +91,12 @@ __mpx_wrapper_memset (void *dstpp, int c, size_t len)
return dstpp;
}
+EXTERN_ALIAS (mpx_wrapper_memset)
+
void
__mpx_wrapper_bzero (void *dst, size_t len)
{
- __mpx_wrapper_memset (dst, 0, len);
+ mpx_wrapper_memset (dst, 0, len);
}
/* The mpx_pointer type is used for getting bits
@@ -484,8 +492,8 @@ move_bounds (void *dst, const void *src, size_t n)
return;
}
-void *
-__mpx_wrapper_memmove (void *dst, const void *src, size_t n)
+static void *
+mpx_wrapper_memmove (void *dst, const void *src, size_t n)
{
if (n == 0)
return dst;
@@ -513,17 +521,20 @@ __mpx_wrapper_memmove (void *dst, const void
*src, size_t n)
return dst;
}
+EXTERN_ALIAS (mpx_wrapper_memmove)
-void *
-__mpx_wrapper_memcpy (void *dst, const void *src, size_t n)
+static void *
+mpx_wrapper_memcpy (void *dst, const void *src, size_t n)
{
- return __mpx_wrapper_memmove (dst, src, n);
+ return mpx_wrapper_memmove (dst, src, n);
}
+EXTERN_ALIAS (mpx_wrapper_memcpy)
+
void *
__mpx_wrapper_mempcpy (void *dst, const void *src, size_t n)
{
- return (char *)__mpx_wrapper_memcpy (dst, src, n) + n;
+ return (char *)mpx_wrapper_memcpy (dst, src, n) + n;
}
char *
[PATCH] PR 78534 Change character length from int to size_t
In order to handle large character lengths on (L)LP64 targets, switch the GFortran character length from an int to a size_t. This is an ABI change, as procedures with character arguments take hidden arguments with the character length. I also changed the _size member in vtables from int to size_t, as there were some cases where character lengths and sizes were apparently mixed up and caused regressions otherwise. Although I haven't tested, this might enable very large derived types as well. Also, as there are some places in the frontend were negative character lengths are used as special flag values, in the frontend the character length is handled as a signed variable of the same size as a size_t, although in the runtime library it really is size_t. I haven't changed the character length variables for the co-array intrinsics, as this is something that may need to be synchronized with OpenCoarrays. Another change in this place is that the algorithm for gfc_trans_string_copy has been rewritten to avoid a -Wstringop-overflow warning. Regtested on x86_64-pc-linux-gnu, Ok for trunk? frontend: 2016-12-23 Janne Blomqvist PR fortran/78534 PR fortran/66310 * arith.c (gfc_check_charlen_range): New function. (gfc_range_check): Use gfc_check_charlen_range. * class.c (gfc_find_derived_vtab): Use gfc_size_kind instead of hardcoded kind. (find_intrinsic_vtab): Likewise. * expr.c (gfc_get_character_expr): Length parameter of type gfc_charlen_t. (gfc_get_int_expr): Value argument of type long. (gfc_extract_long): New function. * gfortran.h (gfc_typespec): New member is_charlen. (gfc_charlen_t): New typedef. (gfc_expr): Use gfc_charlen_t for character lengths. (gfc_size_kind): New extern variable. (gfc_extract_long): New prototype. (gfc_get_character_expr): Use gfc_charlen_t for character length. (gfc_get_int_expr): Use long type for value argument. * iresolve.c (gfc_resolve_repeat): Use gfc_charlen_t, gfc_charlen_int_kind, set is_charlen. * match.c (select_intrinsic_set_tmp): Use long for charlen. * module.c (atom_int): Change type from int to HOST_WIDE_INT. (parse_integer): Don't complain about large integers. (write_atom): Use HOST_WIDE_INT for integers. (mio_integer): Handle integer type mismatch. (mio_hwi): New function. (mio_intrinsic_op): Use HOST_WIDE_INT. (mio_array_ref): Likewise. (mio_expr): Likewise. * resolve.c (resolve_substring): Use get_type_static_bounds. (resolve_select_type): Use long for charlen. (resolve_charlen): Use long for charlen, get_type_static_bounds. * simplify.c (gfc_simplify_repeat): Likewise. * target-memory.c (gfc_interpret_character): Use gfc_charlen_t. * trans-array.c (get_array_ctor_var_strlen): Use gfc_conv_mpz_to_tree_type. * trans-const.c (gfc_conv_mpz_to_tree_type): New function. * trans-const.h (gfc_conv_mpz_to_tree_type): New prototype. * trans-decl.c (create_function_arglist): Assert that length is not NULL_TREE. * trans-expr.c (gfc_class_len_or_zero_get): Build const of type gfc_charlen_type_node. (gfc_conv_intrinsic_to_class): Use gfc_charlen_int_kind instead of 4, fold_convert to correct type. (gfc_conv_class_to_class): Build const of type size_type_node for size. (gfc_copy_class_to_class): Likewise. (gfc_conv_string_length): Use same type in expression. (gfc_conv_substring): Likewise, use long for charlen. (gfc_conv_string_tmp): Make sure len is of the right type. (gfc_conv_concat_op): Use same type in expression. (gfc_conv_procedure_call): Likewise. (gfc_trans_string_copy): Rewrite to avoid -Wstringop-overflow warning in generated code. (alloc_scalar_allocatable_for_subcomponent_assignment): fold_convert to right type. (gfc_trans_subcomponent_assign): Likewise. (trans_class_vptr_len_assignment): Build const of correct type. (gfc_trans_pointer_assignment): Likewise. (alloc_scalar_allocatable_for_assignment): fold_convert to right type in expr. (trans_class_assignment): Build const of correct type. * trans-intrinsic.c (gfc_conv_associated): Likewise. (gfc_conv_intrinsic_repeat): Do calculation in sizetype. * trans-io.c (gfc_build_io_library_fndecls): Use gfc_charlen_type_node for character lengths. * trans-stmt.c (gfc_trans_label_assign): Build const of gfc_charlen_type_node. (gfc_trans_character_select): Likewise. (gfc_trans_allocate): Likewise, don't typecast strlen result. (gfc_trans_deallocate): Don't typecast strlen result. * trans-types.c (gfc_size_kind): New variable. (gfc_init_types):
Re: [C++ PATCH] Extend the list of implicit noexcept C library symbols for -std=c++11 and -std=c++17 (PR middle-end/78901)
On Fri, Dec 23, 2016 at 3:48 AM, Jakub Jelinek wrote: > Hi! > > C++ says that C library functions are implicitly noexcept, except for those > like qsort and bsearch where exceptions can be thrown from the callbacks. > > We handle this through cfns.gperf, but that contains only list of C89 > functions, while C++11 and C++14 refer to C99 and C++17 refers to C11. > > I went through the C99 and C11 standards, gathered all functions from there > (not macros nor generic functions) and using gperf %struct-type feature > attached the C version next to each symbol, so that e.g. snprintf is > noexcept only with -std=c++11 and above and e.g. mbrtoc16 only with > -std=c++17. Without this, we still consider snprintf as potentially > throwing, which breaks gimple-ssa-sprintf.c assumptions. For -std=c++98 > snprintf is not considered a builtin. Let's only be strict about this if flag_iso is set; for C library usage it shouldn't usually matter what C++ standard we're using. Jason
Re: Fix compilation errors with libstdc++v3 for AVR target and allow --enable-libstdcxx
On Fri, Dec 16, 2016 at 10:45 AM, Jonathan Wakely wrote: > On 15/12/16 21:41 -0300, Felipe Magno de Almeida wrote: >> >> Good point. Do you want me to update the patch with __men or go your way >> with the wrapper? Hello Jonathan, > I think my wrapper's too ugly :-) :) > So please follow the same approach as for tm_mon (pass __mem to the > function, the copy it to tm_mon if there was no error). That adds a > write and a branch for every extracted field, which I hope shouldn't > have too much impact. Please find it attached. Changelog is the same: 2016-11-10 Felipe Magno de Almeida * include/bits/locale_facets_nonio.tcc: Avoid compilation errors with non-standard struct tm. -- Felipe Magno de Almeida From f5da929741a2e58cfc9bcc4fab3f8b053d56d800 Mon Sep 17 00:00:00 2001 From: Felipe Magno de Almeida Date: Thu, 15 Sep 2016 18:52:57 -0300 Subject: [PATCH] Use temporary int objects to access struct tm members Call _M_extract_* functions family through temporary int objects, so it doesn't convert from lvalue to rvalue through a temporary in AVR because of the incompatible types used in AVR-Libc. This fixes compilation errors with AVR-Libc while compiling libstdc++ for AVR target. --- libstdc++-v3/include/bits/locale_facets_nonio.tcc | 44 --- 1 file changed, 32 insertions(+), 12 deletions(-) diff --git a/libstdc++-v3/include/bits/locale_facets_nonio.tcc b/libstdc++-v3/include/bits/locale_facets_nonio.tcc index 1a4f9a0..306dd2e 100644 --- a/libstdc++-v3/include/bits/locale_facets_nonio.tcc +++ b/libstdc++-v3/include/bits/locale_facets_nonio.tcc @@ -659,30 +659,38 @@ _GLIBCXX_END_NAMESPACE_LDBL_OR_CXX11 // Abbreviated weekday name [tm_wday] const char_type* __days1[7]; __tp._M_days_abbreviated(__days1); - __beg = _M_extract_name(__beg, __end, __tm->tm_wday, __days1, + __beg = _M_extract_name(__beg, __end, __mem, __days1, 7, __io, __tmperr); + if (!__tmperr) +__tm->tm_wday = __mem; break; case 'A': // Weekday name [tm_wday]. const char_type* __days2[7]; __tp._M_days(__days2); - __beg = _M_extract_name(__beg, __end, __tm->tm_wday, __days2, + __beg = _M_extract_name(__beg, __end, __mem, __days2, 7, __io, __tmperr); + if (!__tmperr) +__tm->tm_wday = __mem; break; case 'h': case 'b': // Abbreviated month name [tm_mon] const char_type* __months1[12]; __tp._M_months_abbreviated(__months1); - __beg = _M_extract_name(__beg, __end, __tm->tm_mon, + __beg = _M_extract_name(__beg, __end, __mem, __months1, 12, __io, __tmperr); + if (!__tmperr) +__tm->tm_mon = __mem; break; case 'B': // Month name [tm_mon]. const char_type* __months2[12]; __tp._M_months(__months2); - __beg = _M_extract_name(__beg, __end, __tm->tm_mon, + __beg = _M_extract_name(__beg, __end, __mem, __months2, 12, __io, __tmperr); + if (!__tmperr) +__tm->tm_mon = __mem; break; case 'c': // Default time and date representation. @@ -693,18 +701,22 @@ _GLIBCXX_END_NAMESPACE_LDBL_OR_CXX11 break; case 'd': // Day [01, 31]. [tm_mday] - __beg = _M_extract_num(__beg, __end, __tm->tm_mday, 1, 31, 2, + __beg = _M_extract_num(__beg, __end, __mem, 1, 31, 2, __io, __tmperr); + if (!__tmperr) +__tm->tm_mday = __mem; break; case 'e': // Day [1, 31], with single digits preceded by // space. [tm_mday] if (__ctype.is(ctype_base::space, *__beg)) - __beg = _M_extract_num(++__beg, __end, __tm->tm_mday, 1, 9, + __beg = _M_extract_num(++__beg, __end, __mem, 1, 9, 1, __io, __tmperr); else - __beg = _M_extract_num(__beg, __end, __tm->tm_mday, 10, 31, + __beg = _M_extract_num(__beg, __end, __mem, 10, 31, 2, __io, __tmperr); + if (!__tmperr) +__tm->tm_mday = __mem; break; case 'D': // Equivalent to %m/%d/%y.[tm_mon, tm_mday, tm_year] @@ -715,13 +727,17 @@ _GLIBCXX_END_NAMESPACE_LDBL_OR_CXX11 break; case 'H': // Hour [00, 23]. [tm_hour] - __beg = _M_extract_num(__beg, __end, __tm->tm_hour, 0, 23, 2, + __beg = _M_extract_num(__beg, __end, __mem, 0, 23, 2, __io, __tmperr); + if (!__tmperr) +__tm->tm_hour = __mem; break; case 'I': // Hour [01, 12]. [tm_hour] - __beg = _M_extract_num(__beg, __end, __tm->tm_hour, 1, 12, 2, + __beg = _M_extract_num(__beg, __end, __mem, 1, 12, 2, __io, __tmperr); + if (!__tmperr) +__tm->tm_hour = __mem; break; case 'm': // Month [01, 12]. [tm_mon] @@ -732,8 +748,10 @@ _GLIBCXX_END_NAMESPACE_LDBL_OR_CXX11 break; case 'M': // Minute [00, 59]. [tm_min] - __beg = _M_extract_num(__beg, __end, __tm->tm_min, 0, 59, 2, + __beg = _M_extract_num(__beg, __end, __mem, 0, 59, 2, __io, __tmperr); +
Re: [C++ PATCH] Extend the list of implicit noexcept C library symbols for -std=c++11 and -std=c++17 (PR middle-end/78901)
On Fri, Dec 23, 2016 at 10:09:05AM -0500, Jason Merrill wrote:
> On Fri, Dec 23, 2016 at 3:48 AM, Jakub Jelinek wrote:
> > Hi!
> >
> > C++ says that C library functions are implicitly noexcept, except for those
> > like qsort and bsearch where exceptions can be thrown from the callbacks.
> >
> > We handle this through cfns.gperf, but that contains only list of C89
> > functions, while C++11 and C++14 refer to C99 and C++17 refers to C11.
> >
> > I went through the C99 and C11 standards, gathered all functions from there
> > (not macros nor generic functions) and using gperf %struct-type feature
> > attached the C version next to each symbol, so that e.g. snprintf is
> > noexcept only with -std=c++11 and above and e.g. mbrtoc16 only with
> > -std=c++17. Without this, we still consider snprintf as potentially
> > throwing, which breaks gimple-ssa-sprintf.c assumptions. For -std=c++98
> > snprintf is not considered a builtin.
>
> Let's only be strict about this if flag_iso is set; for C library
> usage it shouldn't usually matter what C++ standard we're using.
So like this?
2016-12-23 Jakub Jelinek
PR middle-end/78901
* except.c (nothrow_libfn_p): Expect libc_name_p to return
const struct libc_name_struct *, if it returns NULL, return 0,
otherwise check c_ver and use flag_isoc99 or flag_isoc11.
* cfns.gperf: Add %struct-type and libc_name_struct definition.
For all C89 C library functions add , 89 after the name, add
C99 C library functions with , 99 and C11 C library functions
with , 11 suffix.
* cfns.h: Regenerated.
--- gcc/cp/except.c.jj 2016-10-31 13:28:11.0 +0100
+++ gcc/cp/except.c 2016-12-23 01:29:52.390997316 +0100
@@ -892,8 +892,17 @@ nothrow_libfn_p (const_tree fn)
unless the system headers are playing rename tricks, and if
they are, we don't want to be confused by them. */
id = DECL_NAME (fn);
- return !!libc_name::libc_name_p (IDENTIFIER_POINTER (id),
- IDENTIFIER_LENGTH (id));
+ const struct libc_name_struct *s
+= libc_name::libc_name_p (IDENTIFIER_POINTER (id), IDENTIFIER_LENGTH (id));
+ if (s == NULL)
+return 0;
+ switch (s->c_ver)
+{
+case 89: return 1;
+case 99: return !flag_iso || flag_isoc99;
+case 11: return !flag_iso || flag_isoc11;
+default: gcc_unreachable ();
+}
}
/* Returns nonzero if an exception of type FROM will be caught by a
--- gcc/cp/cfns.gperf.jj2016-02-19 23:16:32.0 +0100
+++ gcc/cp/cfns.gperf 2016-12-23 01:18:23.377729732 +0100
@@ -1,5 +1,6 @@
%language=C++
%define class-name libc_name
+%struct-type
%{
/* Copyright (C) 2000-2016 Free Software Foundation, Inc.
@@ -19,6 +20,7 @@ You should have received a copy of the G
along with GCC; see the file COPYING3. If not see
Re: [PATCH v2] combine: Improve change_zero_ext, call simplify_set afterwards.
Segher Boessenkool schrieb:
On Thu, Dec 22, 2016 at 04:18:34PM +0100, Georg-Johann Lay wrote:
If you don't have instruction scheduling subregs of mem are allowed (and
are counted as registers). Combine asks recog, and it think this is
fine.
Why does reload use r31 here? Why does it think that is valid for
HImode?
I can't tell you, all I'm seeing bunch of new FAILs after r243578.
The avr port does not define CANNOT_CHANGE_MODE_CLASS. It probably
should.
Thanks for that pointer, I'll try it as soon as I can.
i.e. the paradoxical subreg could be resolved somehow and R25 is
uninitialized. It this the purpose of the combine change to come
up with uninitialized regs because it is known that just the
initialized parts are used by the code?
The purpose of the combine change is to write widening extracts in a
more general form, so that backends for processors that can do such
more general things do not have to write hundreds (literally) extra
patterns for all the cases that could be written as zero_extract.
One problem is that not all expressions are canonicalized and combine
might come up with many different kinds of representations for the
same action. One common example is inserting one bit. This might
be represented as (set (zero_extract)) or as set with masking and
shifting around or as (set (if_then_else)), with different
representations if the sign bit is involved or if the source
bit position is the same or lower or higher than the destination's
bit position.
In a private back end I had the same problem that I didn't want to
support dozens of combine patterns and added a new hook that allows
the back end to canonicalize expressions synthesized by combine.
This runs right before recog(_for_combine) and can replace single_set
by equivalent ones. This makes also simplifies porting the back end
because just one place in combine has to be touches and not hundreds
of places in combine.c. Moreover, different targets might come up
with different, conflicting preferences so that a one-fits-all
solution in combine.c doesn't always exist anyway.
(insn 98 97 58 9 (set (reg:QI 31 r31)
(mem:QI (reg:HI 30 r30) [1 *operands_17(D)+0 S1 A8]))
"pr26833.c":11 56 {movqi_insn}
(nil))
(jump_insn 58 98 59 9 (set (pc)
(if_then_else (eq (and:HI (reg:HI 31 r31)
(const_int 1 [0x1]))
(const_int 0 [0]))
(label_ref 70)
(pc))) "pr26833.c":11 415 {*sbrx_and_branchhi}
(int_list:REG_BR_PROB 375 (nil))
-> 70)
insn 98 is valid but overrides parts of HI:30 set by insn 97.
As it appears, the QI memory is loaded to R31 which is valid, and
then reload drops in that register as replacement for the paradoxical
subreg and comes up with HI:31 in insn 58.
Actually a zero-extend would be needed, does it?
The AND clears the top bits already.
OK, I didn't know that the register allocator analyses that parts of
a value (high part in this case) are effectively unused and skips
the extension. Cool feature.
Johann
Please correct me if I'm wrong, but I see no bugs in the combined
expressions.
Algebraically it looks correct, but I am unsure if reload is supposed
to handle such situations.
It is valid RTL. reload should handle it.
And I must admit I never saw "paradoxical"
extractions before; I would expected an extension in that case, not an
extraction.
An extension _of an extraction_. Widening extractions are valid (and I
didn't see them until a few weeks ago either, heh -- that's why Dominik
needed this patch ;-) )
Segher
Re: [PATCH v2] combine: Improve change_zero_ext, call simplify_set afterwards.
On Fri, Dec 23, 2016 at 05:54:01PM +0100, Georg-Johann Lay wrote: > >The purpose of the combine change is to write widening extracts in a > >more general form, so that backends for processors that can do such > >more general things do not have to write hundreds (literally) extra > >patterns for all the cases that could be written as zero_extract. > > One problem is that not all expressions are canonicalized and combine > might come up with many different kinds of representations for the > same action. One common example is inserting one bit. This might > be represented as (set (zero_extract)) or as set with masking and > shifting around or as (set (if_then_else)), with different > representations if the sign bit is involved or if the source > bit position is the same or lower or higher than the destination's > bit position. Yeah. > In a private back end I had the same problem that I didn't want to > support dozens of combine patterns and added a new hook that allows > the back end to canonicalize expressions synthesized by combine. The problem with this is that you create new RTL for every insn fed to recog (so, a lot more insns then there are in your program). That isn't very nice (combine tries very hard to create as little garbage as it can). > This runs right before recog(_for_combine) and can replace single_set > by equivalent ones. This makes also simplifies porting the back end > because just one place in combine has to be touches and not hundreds > of places in combine.c. I don't understand what you mean here, what hundreds of places in combine? What is "porting", here? > Moreover, different targets might come up > with different, conflicting preferences so that a one-fits-all > solution in combine.c doesn't always exist anyway. Yeah. > Actually a zero-extend would be needed, does it? > > > >The AND clears the top bits already. > > OK, I didn't know that the register allocator analyses that parts of > a value (high part in this case) are effectively unused and skips > the extension. Cool feature. It was a paradoxical subreg before, the RA just changes that to hard regs? Segher
Make it cheaper to test whether an SSA name is a virtual operand
virtual_operand_p handled SSA names by looking at the flags of the
underlying variable. This seems to be a relatively common source
of cache misses, mainly because virtual_operand_p is the first thing
tested by is_gimple_reg.
This patch caches the information in the SSA name itself. Several
flags seem to be free so the patch arbitrarily uses public_flag.
Tested on aarch64-linux-gnu and x86_64-linux-gnu. It improves
compile time by a small (<1%) but reproducable amount on the
tests I've tried. OK to install?
Thanks,
Richard
gcc/
* tree-core.h (tree_base): Document the meaning of public_flag
for SSA names.
* tree.h (SSA_NAME_IS_VIRTUAL_OPERAND): New macro.
(SET_SSA_NAME_VAR_OR_IDENTIFIER): Record whether the variable
is a virtual operand.
* gimple-expr.h (virtual_operand_p): Use SSA_NAME_IS_VIRTUAL_OPERAND.
diff --git a/gcc/gimple-expr.h b/gcc/gimple-expr.h
index f2ccd29..faf4c53 100644
--- a/gcc/gimple-expr.h
+++ b/gcc/gimple-expr.h
@@ -105,11 +105,7 @@ static inline bool
virtual_operand_p (tree op)
{
if (TREE_CODE (op) == SSA_NAME)
-{
- op = SSA_NAME_VAR (op);
- if (!op)
- return false;
-}
+return SSA_NAME_IS_VIRTUAL_OPERAND (op);
if (TREE_CODE (op) == VAR_DECL)
return VAR_DECL_IS_VIRTUAL_OPERAND (op);
diff --git a/gcc/tree-core.h b/gcc/tree-core.h
index eec2d4f3..59d771c 100644
--- a/gcc/tree-core.h
+++ b/gcc/tree-core.h
@@ -1091,6 +1091,9 @@ struct GTY(()) tree_base {
FALLTHROUGH_LABEL_P in
LABEL_DECL
+ SSA_NAME_IS_VIRTUAL_OPERAND in
+ SSA_NAME
+
private_flag:
TREE_PRIVATE in
diff --git a/gcc/tree.h b/gcc/tree.h
index 62cd7bb..e994e93 100644
--- a/gcc/tree.h
+++ b/gcc/tree.h
@@ -1665,6 +1665,11 @@ extern void protected_set_expr_location (tree,
location_t);
/* SSA_NAME accessors. */
+/* Whether SSA_NAME NODE is a virtual operand. This simply caches the
+ information in the underlying SSA_NAME_VAR for efficiency. */
+#define SSA_NAME_IS_VIRTUAL_OPERAND(NODE) \
+ SSA_NAME_CHECK (NODE)->base.public_flag
+
/* Returns the IDENTIFIER_NODE giving the SSA name a name or NULL_TREE
if there is no name associated with it. */
#define SSA_NAME_IDENTIFIER(NODE) \
@@ -1683,7 +1688,16 @@ extern void protected_set_expr_location (tree,
location_t);
? NULL_TREE : (NODE)->ssa_name.var)
#define SET_SSA_NAME_VAR_OR_IDENTIFIER(NODE,VAR) \
- do { SSA_NAME_CHECK (NODE)->ssa_name.var = (VAR); } while (0)
+ do \
+{ \
+ tree var_ = (VAR); \
+ SSA_NAME_CHECK (NODE)->ssa_name.var = var_; \
+ SSA_NAME_IS_VIRTUAL_OPERAND (NODE) \
+ = (var_ \
+ && TREE_CODE (var_) == VAR_DECL \
+ && VAR_DECL_IS_VIRTUAL_OPERAND (var_)); \
+} \
+ while (0)
/* Returns the statement which defines this SSA name. */
#define SSA_NAME_DEF_STMT(NODE)SSA_NAME_CHECK (NODE)->ssa_name.def_stmt
Short-circuit alt_fail case in record_reg_classes
record_reg_classes is often the hottest function when generating
unoptimised output. It seems typical for over 60% of the instructions
it handles to be moves, and of course moves tend to be the instructions
with the longest constraint strings.
Maybe we should avoid using move constraints to set costs in unoptimised
output and instead use the "natural" class for the mode being moved.
That's too invasive for stage 3 though.
However, seeing so many moves means that we see many "failing"
alternatives, usually because of '*' or because of hard registers
in function call sequences. The frequency of alternatives that are
detected as failures after the first operand tends again to be more
than 60%. Previously we would continue to process the other operands
of the alternative regardless. This patch instead adds a short-cut.
As well as avoiding unnecessary work, it means that the alt_fail
variable can be jump-threaded away.
Tested on aach64-linux-gnu and x86_64-linux-gnu. It reduces compile
time by about 1% on some tests with "-g -O0". OK to install?
Thanks,
Richard
gcc/
* ira-costs.c (record_reg_classes): Break from the inner loop
early once alt_fail is known to be true. Update outer loop
handling accordingly.
diff --git a/gcc/ira-costs.c b/gcc/ira-costs.c
index bdd5cb5..45a1304 100644
--- a/gcc/ira-costs.c
+++ b/gcc/ira-costs.c
@@ -820,6 +820,9 @@ record_reg_classes (int n_alts, int n_ops, rtx *ops,
constraints[i] = p;
+ if (alt_fail)
+ break;
+
/* How we account for this operand now depends on whether it
is a pseudo register or not. If it is, we first check if
any register classes are valid. If not, we ignore this
@@ -999,10 +1002,21 @@ record_reg_classes (int n_alts, int n_ops, rtx *ops,
alt_cost += ira_memory_move_cost[mode][classes[i]][1];
else
alt_fail = 1;
+
+ if (alt_fail)
+ break;
}
if (alt_fail)
- continue;
+ {
+ /* The loop above might have exited early once the failure
+was seen. Skip over the constraints for the remaining
+operands. */
+ i += 1;
+ for (; i < n_ops; ++i)
+ constraints[i] = skip_alternative (constraints[i]);
+ continue;
+ }
op_cost_add = alt_cost * frequency;
/* Finally, update the costs with the information we've
Avoid excessively-big hash tables in empty-add cycles
A big source of cache misses when compiling a recent version of
gimple-match.ii was the call to cv_cache.empty () in clear_cv_cache.
The problem was that at one early point the hash table had grown
to 8191 entries (128k on LP64 hosts). It then stayed at that size
for the rest of the compilation, even though subsequent uses needed
only a small number of entries (usually fewer than ten). We would
still clear the whole 128k each time clear_cv_cache was called.
empty() already looks for cases where the hash table is very big
and cuts it down. At the moment it fires when the table is 1M
in size and reduces it to the next selected prime above 1K (so
almost 2K in practice). One fix would have been to lower the
threshold, but that didn't feel like the right approach. Reducing
the current limit of 1M by a factor of 8 would be pretty significant
on its own, but I think this cv_cache behaviour would have been a
problem even with 64k or 32k tables.
I think the existing check is really for cases in which even a
well-populated table would need to be shrunk rather than cleared.
Here the problem isn't that the table is excessively big in
absolute terms, more that one outlier has made the table much
too big for the general case.
traverse() already shrinks the table if it's "too empty",
which is taken to be if:
no. elements * 8 < capacity && capacity > 32
So an alternative would be to apply the same test (and the same choice
of shrunken size) to empty_slow too. The patch below does this.
It gives a 2.5% improvement in gimple-match.ii compile time at -O0 -g
and doesn't seem to adversely affect any other tests I've tried.
Of course, there's a theoretical risk of a table alternating between
one large element count and one small element count. If there was a
factor of eight difference between the two, we could shrink the table
on seeing each small element count, then grow it again when adding the
large number of elements. That seems pretty unlikely in practice
though.
Also, empty_slow() does involve a traversal if some form of manual
gc is needed on active elements, so trying to recover from an outlier
should have even more benefit there. (cv_cache uses automatic gc and so
the traversal gets optimised away.)
The calculation of the existing 1M threshold was assuming that each
entry was pointer-sized. This patch makes it use the actual size of the
entry instead.
Tested on aarch64-linux-gnu and x86_64-linux-gnu. OK to install?
Thanks,
Richard
[Sorry for the verbose write-up]
gcc/
* hash-table.h (hash_table::too_empty_p): New function.
(hash_table::expand): Use it.
(hash_table::traverse): Likewise.
(hash_table::empty_slot): Use sizeof (value_type) instead of
sizeof (PTR) to convert bytes to elements. Shrink the table
if the current size is excessive for the current number of
elements.
diff --git a/gcc/hash-table.h b/gcc/hash-table.h
index e925e1e..273d07b 100644
--- a/gcc/hash-table.h
+++ b/gcc/hash-table.h
@@ -503,6 +503,7 @@ private:
value_type *alloc_entries (size_t n CXX_MEM_STAT_INFO) const;
value_type *find_empty_slot_for_expand (hashval_t);
+ bool too_empty_p (unsigned int);
void expand ();
static bool is_deleted (value_type &v)
{
@@ -691,6 +692,15 @@ hash_table::find_empty_slot_for_expand (hashval_t hash)
}
}
+/* Return true if the current table is excessively big for ELTS elements. */
+
+template class Allocator>
+inline bool
+hash_table::too_empty_p (unsigned int elts)
+{
+ return elts * 8 < m_size && m_size > 32;
+}
+
/* The following function changes size of memory allocated for the
entries and repeatedly inserts the table elements. The occupancy
of the table after the call will be about 50%. Naturally the hash
@@ -712,7 +722,7 @@ hash_table::expand ()
too full or too empty. */
unsigned int nindex;
size_t nsize;
- if (elts * 2 > osize || (elts * 8 < osize && osize > 32))
+ if (elts * 2 > osize || too_empty_p (elts))
{
nindex = hash_table_higher_prime_index (elts * 2);
nsize = prime_tab[nindex].prime;
@@ -764,6 +774,7 @@ void
hash_table::empty_slow ()
{
size_t size = m_size;
+ size_t nsize = size;
value_type *entries = m_entries;
int i;
@@ -772,9 +783,14 @@ hash_table::empty_slow ()
Descriptor::remove (entries[i]);
/* Instead of clearing megabyte, downsize the table. */
- if (size > 1024*1024 / sizeof (PTR))
+ if (size > 1024*1024 / sizeof (value_type))
+nsize = 1024 / sizeof (value_type);
+ else if (too_empty_p (m_n_elements))
+nsize = m_n_elements * 2;
+
+ if (nsize != size)
{
- int nindex = hash_table_higher_prime_index (1024 / sizeof (PTR));
+ int nindex = hash_table_higher_prime_index (nsize);
int nsize = prime_tab[nindex].prime;
if (!m_ggc)
@@ -965,8 +981,7 @@ template ::traverse (Argument argument)
{
- size_t size = m_size;
- if (elements () * 8 < size && size > 32)
+ if (too_empty_p (el
Re: better debug info for C++ cdtors, aliases, thunks and other trampolines
Sorry this has taken so long. In future, please feel free to ping me as
much as once a week, in email and/or IRC.
On 09/23/2016 08:41 PM, Alexandre Oliva wrote:
support aliases and trampolines in dwarf2
I know that "trampoline" is the term used in the DWARF standard, but in
GCC it typically means specifically code for nested functions created at
runtime, as in https://gcc.gnu.org/onlinedocs/gccint/Trampolines.html
So I'd prefer to use "thunk" as the generic term in this patch, as
cgraph does.
+ /* C1 and C2 ctors may be trampolines to C4; D0, D1 and D2 dtors may
+ be trampolines to D4. Check their mangled names, so that the
+ test will work even during LTO compilations, when the cdtor
+ clones retrofitted into trampolines might not be right after the
+ unified one in the DECL_CHAIN, and we don't have C++-specific
+ data structures or lang hooks to check that the cdtors are of
+ different kinds and belong to the same class.
This will be simpler with richi's LTO debug work, but that hasn't gone
in yet. Until then, we probably want to emit what we can in early debug
(i.e. from the front end rather than cgraph), and not worry too much
about LTO.
This is more or less what richi was saying in
https://gcc.gnu.org/ml/gcc-patches/2016-02/msg01629.html .
- return lang_hooks.dwarf_name (decl, scope ? 1 : 0);
+ const char *name = lang_hooks.dwarf_name (decl, scope ? 1 : 0);
+ if (name && name[0] == '*')
+name++;
This is TARGET_STRIP_NAME_ENCODING. I'm also surprised that the
dwarf_name langhook would return such an encoded name.
+ /* ??? It would be nice if we could just link back to the symbol
+ declaration, but DW_AT_specification is not a welcome attribute
+ for a DW_TAG_imported_declaration. */
+ if (0 && old_alias_die)
+{
+ add_AT_die_ref (alias_die, DW_AT_specification, old_alias_die);
+ return;
+}
Strictly speaking, neither is DW_AT_external or DW_AT_artificial.
Where we're using an alias to define a function rather than give it its
own separate definition, I'm not sure DW_AT_imported_declaration is the
right representation; this is a distinct function, the alias is just an
implementation detail.
libcc1 C++ support review to follow.
Jason
Re: [testsuite,committed] Fix prototype of memset in a test case.
Georg-Johann Lay writes:
> On 22.12.2016 19:20, Richard Sandiford wrote:
>> Georg-Johann Lay writes:
>>> One test case used unsigned long for the 3rd parameter of memset, which
>>> should be size_t. This made the test crash for targets where correct
>>> parameter passing depends on correct prototypes.
>>>
>>> Fixed and committed as obvious.
>>
>> Catching up on backlog, but... I'm not sure this counts as obvious
>> if the crash was an ICE. We should at least fail gracefully.
>
> The crash I mentioned happened on avr where parameter passing needs
> correct prototypes. The code crashed when executed on avr because
> a long gets passed in regs R22..R25 (LSBs first) but a size_t is
> passed in R24..R25. Hence the implementation of memset would pick
> up the upper two bytes of the length (zero) which crashes when run.
Ah, OK, so it was the test executable that crashed and not the compiler.
In that case sorry for the noise.
Richard
> PR30778 was about wrong-code because more than the specified number
> of bytes were written. It was reported for x64_64 where we have
> size_t = unsigned long, hence the change is a no-op on the platform
> the PR was originally reported against (similar for x86 where
> size_t = unsigned).
>
> Moreover, the test case is condensed from GCC's combine.c and I'd
> expect that GCC's header are using correct prototypes :-)
>
> Johann
>
>>
>> Thanks,
>> Richard
>>
>>>
>>> Johann
>>>
>>>
>>> gcc/testsuite/
>>> * gcc.c-torture/execute/pr30778.c (memset): Use size_t for 3rd
>>> parameter in declaration.
>>>
>>> Index: gcc.c-torture/execute/pr30778.c
>>> ===
>>> --- gcc.c-torture/execute/pr30778.c (revision 242541)
>>> +++ gcc.c-torture/execute/pr30778.c (working copy)
>>> @@ -1,4 +1,4 @@
>>> -extern void *memset (void *, int, unsigned long);
>>> +extern void *memset (void *, int, __SIZE_TYPE__);
>>> extern void abort (void);
>>>
>>> struct reg_stat {
>>
Re: PR78631 fix
Hi,
ChangeLog? Otherwise OK.
Ilya
2016-12-23 14:02 GMT+03:00 Alexander Ivchenko :
> Hi Ilya,
>
> Would that patch be OK to submit? (it is HJ's one with added testcase)
>
> diff --git a/gcc/testsuite/gcc.target/i386/mpx/memcpy-1.c
> b/gcc/testsuite/gcc.target/i386/mpx/memcpy-1.c
> new file mode 100644
> index 000..1691348
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/i386/mpx/memcpy-1.c
> @@ -0,0 +1,23 @@
> +/* { dg-do run } */
> +/* { dg-shouldfail "bounds violation" } */
> +/* { dg-options "-fcheck-pointer-bounds -mmpx" } */
> +
> +/* Fix for PR78631 */
> +
> +#define SHOULDFAIL
> +
> +#include
> +#include
> +
> +char s[10];
> +char d[10];
> +__attribute__((noinline))
> +
> +char* foo(char* dst, char* src, size_t size) {
> + return memcpy(dst, src, size);
> +}
> +int main() {
> + char* r = foo(d, s, 11);
> + printf("r = %p\n", r);
> + return 0;
> +}
> diff --git a/libmpx/mpxwrap/libtool-version b/libmpx/mpxwrap/libtool-version
> index fab30fb..e241350 100644
> --- a/libmpx/mpxwrap/libtool-version
> +++ b/libmpx/mpxwrap/libtool-version
> @@ -3,4 +3,4 @@
> # a separate file so that version updates don't involve re-running
> # automake.
> # CURRENT:REVISION:AGE
> -2:0:0
> +2:1:0
> diff --git a/libmpx/mpxwrap/mpx_wrappers.c b/libmpx/mpxwrap/mpx_wrappers.c
> index 171a780..aea0346 100644
> --- a/libmpx/mpxwrap/mpx_wrappers.c
> +++ b/libmpx/mpxwrap/mpx_wrappers.c
> @@ -30,14 +30,20 @@
> #include
> #include "mpxrt/mpxrt.h"
>
> -void *
> -__mpx_wrapper_malloc (size_t size)
> +/* Since internal MPX wrapper calls must avoid PLT which will clear bound
> + registers, we make them static with an external alias. */
> +#define EXTERN_ALIAS(f) \
> + __typeof (f) __##f __attribute__((alias(#f)));
> +
> +static void *
> +mpx_wrapper_malloc (size_t size)
> {
>void *p = (void *)malloc (size);
>if (!p) return __bnd_null_ptr_bounds (p);
>return __bnd_set_ptr_bounds (p, size);
> }
>
> +EXTERN_ALIAS (mpx_wrapper_malloc)
>
> void *
> __mpx_wrapper_mmap (void *addr, size_t length, int prot, int flags,
> @@ -52,7 +58,7 @@ void *
> __mpx_wrapper_realloc (void *ptr, size_t n)
> {
>if (!ptr)
> -return __mpx_wrapper_malloc (n);
> +return mpx_wrapper_malloc (n);
>
>/* We don't kwnow how much data is copied by realloc
> and therefore may check only lower bounds. */
> @@ -74,8 +80,8 @@ __mpx_wrapper_calloc (size_t n_elements, size_t
> element_size)
>return __bnd_set_ptr_bounds (p, n_elements * element_size);
> }
>
> -void *
> -__mpx_wrapper_memset (void *dstpp, int c, size_t len)
> +static void *
> +mpx_wrapper_memset (void *dstpp, int c, size_t len)
> {
>if (len > 0)
> {
> @@ -85,10 +91,12 @@ __mpx_wrapper_memset (void *dstpp, int c, size_t len)
>return dstpp;
> }
>
> +EXTERN_ALIAS (mpx_wrapper_memset)
> +
> void
> __mpx_wrapper_bzero (void *dst, size_t len)
> {
> - __mpx_wrapper_memset (dst, 0, len);
> + mpx_wrapper_memset (dst, 0, len);
> }
>
> /* The mpx_pointer type is used for getting bits
> @@ -484,8 +492,8 @@ move_bounds (void *dst, const void *src, size_t n)
>return;
> }
>
> -void *
> -__mpx_wrapper_memmove (void *dst, const void *src, size_t n)
> +static void *
> +mpx_wrapper_memmove (void *dst, const void *src, size_t n)
> {
>if (n == 0)
> return dst;
> @@ -513,17 +521,20 @@ __mpx_wrapper_memmove (void *dst, const void
> *src, size_t n)
>return dst;
> }
>
> +EXTERN_ALIAS (mpx_wrapper_memmove)
>
> -void *
> -__mpx_wrapper_memcpy (void *dst, const void *src, size_t n)
> +static void *
> +mpx_wrapper_memcpy (void *dst, const void *src, size_t n)
> {
> - return __mpx_wrapper_memmove (dst, src, n);
> + return mpx_wrapper_memmove (dst, src, n);
> }
>
> +EXTERN_ALIAS (mpx_wrapper_memcpy)
> +
> void *
> __mpx_wrapper_mempcpy (void *dst, const void *src, size_t n)
> {
> - return (char *)__mpx_wrapper_memcpy (dst, src, n) + n;
> + return (char *)mpx_wrapper_memcpy (dst, src, n) + n;
> }
>
> char *
Re: Make it cheaper to test whether an SSA name is a virtual operand
On December 23, 2016 6:47:37 PM GMT+01:00, Richard Sandiford
wrote:
>virtual_operand_p handled SSA names by looking at the flags of the
>underlying variable. This seems to be a relatively common source
>of cache misses, mainly because virtual_operand_p is the first thing
>tested by is_gimple_reg.
>
>This patch caches the information in the SSA name itself. Several
>flags seem to be free so the patch arbitrarily uses public_flag.
>
>Tested on aarch64-linux-gnu and x86_64-linux-gnu. It improves
>compile time by a small (<1%) but reproducable amount on the
>tests I've tried. OK to install?
OK.
Richard.
>Thanks,
>Richard
>
>
>gcc/
> * tree-core.h (tree_base): Document the meaning of public_flag
> for SSA names.
> * tree.h (SSA_NAME_IS_VIRTUAL_OPERAND): New macro.
> (SET_SSA_NAME_VAR_OR_IDENTIFIER): Record whether the variable
> is a virtual operand.
> * gimple-expr.h (virtual_operand_p): Use SSA_NAME_IS_VIRTUAL_OPERAND.
>
>diff --git a/gcc/gimple-expr.h b/gcc/gimple-expr.h
>index f2ccd29..faf4c53 100644
>--- a/gcc/gimple-expr.h
>+++ b/gcc/gimple-expr.h
>@@ -105,11 +105,7 @@ static inline bool
> virtual_operand_p (tree op)
> {
> if (TREE_CODE (op) == SSA_NAME)
>-{
>- op = SSA_NAME_VAR (op);
>- if (!op)
>- return false;
>-}
>+return SSA_NAME_IS_VIRTUAL_OPERAND (op);
>
> if (TREE_CODE (op) == VAR_DECL)
> return VAR_DECL_IS_VIRTUAL_OPERAND (op);
>diff --git a/gcc/tree-core.h b/gcc/tree-core.h
>index eec2d4f3..59d771c 100644
>--- a/gcc/tree-core.h
>+++ b/gcc/tree-core.h
>@@ -1091,6 +1091,9 @@ struct GTY(()) tree_base {
>FALLTHROUGH_LABEL_P in
> LABEL_DECL
>
>+ SSA_NAME_IS_VIRTUAL_OPERAND in
>+ SSA_NAME
>+
>private_flag:
>
>TREE_PRIVATE in
>diff --git a/gcc/tree.h b/gcc/tree.h
>index 62cd7bb..e994e93 100644
>--- a/gcc/tree.h
>+++ b/gcc/tree.h
>@@ -1665,6 +1665,11 @@ extern void protected_set_expr_location (tree,
>location_t);
>
> /* SSA_NAME accessors. */
>
>+/* Whether SSA_NAME NODE is a virtual operand. This simply caches the
>+ information in the underlying SSA_NAME_VAR for efficiency. */
>+#define SSA_NAME_IS_VIRTUAL_OPERAND(NODE) \
>+ SSA_NAME_CHECK (NODE)->base.public_flag
>+
> /* Returns the IDENTIFIER_NODE giving the SSA name a name or NULL_TREE
>if there is no name associated with it. */
> #define SSA_NAME_IDENTIFIER(NODE) \
>@@ -1683,7 +1688,16 @@ extern void protected_set_expr_location (tree,
>location_t);
>? NULL_TREE : (NODE)->ssa_name.var)
>
> #define SET_SSA_NAME_VAR_OR_IDENTIFIER(NODE,VAR) \
>- do { SSA_NAME_CHECK (NODE)->ssa_name.var = (VAR); } while (0)
>+ do \
>+{ \
>+ tree var_ = (VAR); \
>+ SSA_NAME_CHECK (NODE)->ssa_name.var = var_; \
>+ SSA_NAME_IS_VIRTUAL_OPERAND (NODE) \
>+ = (var_ \
>+ && TREE_CODE (var_) == VAR_DECL \
>+ && VAR_DECL_IS_VIRTUAL_OPERAND (var_)); \
>+} \
>+ while (0)
>
> /* Returns the statement which defines this SSA name. */
>#define SSA_NAME_DEF_STMT(NODE)SSA_NAME_CHECK
>(NODE)->ssa_name.def_stmt
New French PO file for 'gcc' (version 6.2.0)
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 French team of translators. The file is available at: http://translationproject.org/latest/gcc/fr.po (This file, 'gcc-6.2.0.fr.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.
[PATCH], Fix PowerPC ISA 3.0 word extract/insert thinkos
I had two thinkos in my previous patches for ISA 3.0 (power9) support that both
relate to word extraction and insertion.
The first thinko was that I thought the index for the first byte in the 4 bytes
to be extracted should be 0..11, when it should be 0..12. If it isn't allowed
to be 12, you cannot extract the 32-bit word at the bottom of the vector
register.
The second thinko is where I was doing zeo extending of a 32-bit value within
a vector register, I used xxextractuw with a byte offset of 1 instead of 4.
I have done the usual bootstrap and make check with no regressions on these
patches. Can I install them into the trunk?
2016-12-23 Michael Meissner
* config/rs6000/predicates.md (const_0_to_12_operand): Rename
predicate and change test from 0..11 to 0..12 to match the
semantics of the word extract/insert instructions. Change all
callers.
(const_0_to_11_operand): Likewise.
* config/rs6000/vsx.md (vextract4b): Likewise.
(vextract4b_internal): Likewise.
(vinsert4b): Likewise.
(vinsert4b_internal): Likewise.
(vinsert4b_di): Likewise.
(vinsert4b_di_internal): Likewise.
* config/rs6000/rs6000.md (zero_extendsi2): Fix offset used
in xxextractuw to zero extend the word in the vector registers.
(lfiwzx): Likewise.
--
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.vnet.ibm.com, phone: +1 (978) 899-4797
Index: gcc/config/rs6000/predicates.md
===
--- gcc/config/rs6000/predicates.md (revision 243891)
+++ gcc/config/rs6000/predicates.md (working copy)
@@ -211,9 +211,9 @@ (define_predicate "const_0_to_7_operand"
(match_test "IN_RANGE (INTVAL (op), 0, 7)")))
;; Match op = 0..11
-(define_predicate "const_0_to_11_operand"
+(define_predicate "const_0_to_12_operand"
(and (match_code "const_int")
- (match_test "IN_RANGE (INTVAL (op), 0, 11)")))
+ (match_test "IN_RANGE (INTVAL (op), 0, 12)")))
;; Match op = 0..15
(define_predicate "const_0_to_15_operand"
Index: gcc/config/rs6000/rs6000.md
===
--- gcc/config/rs6000/rs6000.md (revision 243891)
+++ gcc/config/rs6000/rs6000.md (working copy)
@@ -855,7 +855,7 @@ (define_insn "zero_extendsi2"
lxsiwzx %x0,%y1
mtvsrwz %x0,%1
mfvsrwz %0,%x1
- xxextractuw %x0,%x1,1"
+ xxextractuw %x0,%x1,4"
[(set_attr "type" "load,shift,fpload,fpload,mffgpr,mftgpr,vecexts")])
(define_insn_and_split "*zero_extendsi2_dot"
@@ -5131,7 +5131,7 @@ (define_insn "lfiwzx"
lfiwzx %0,%y1
lxsiwzx %x0,%y1
mtvsrwz %x0,%1
- xxextractuw %x0,%x1,1"
+ xxextractuw %x0,%x1,4"
[(set_attr "type" "fpload,fpload,mftgpr,vecexts")])
(define_insn_and_split "floatunssi2_lfiwzx"
Index: gcc/config/rs6000/vsx.md
===
--- gcc/config/rs6000/vsx.md(revision 243891)
+++ gcc/config/rs6000/vsx.md(working copy)
@@ -3813,7 +3813,7 @@ (define_insn "vextuwrx"
(define_expand "vextract4b"
[(set (match_operand:DI 0 "gpc_reg_operand")
(unspec:DI [(match_operand:V16QI 1 "vsx_register_operand")
- (match_operand:QI 2 "const_0_to_11_operand")]
+ (match_operand:QI 2 "const_0_to_12_operand")]
UNSPEC_XXEXTRACTUW))]
"TARGET_P9_VECTOR"
{
@@ -3824,7 +3824,7 @@ (define_expand "vextract4b"
(define_insn_and_split "*vextract4b_internal"
[(set (match_operand:DI 0 "gpc_reg_operand" "=wj,r")
(unspec:DI [(match_operand:V16QI 1 "vsx_register_operand" "wa,v")
- (match_operand:QI 2 "const_0_to_11_operand" "n,n")]
+ (match_operand:QI 2 "const_0_to_12_operand" "n,n")]
UNSPEC_XXEXTRACTUW))]
"TARGET_P9_VECTOR"
"@
@@ -3852,7 +3852,7 @@ (define_expand "vinsert4b"
[(set (match_operand:V16QI 0 "vsx_register_operand")
(unspec:V16QI [(match_operand:V4SI 1 "vsx_register_operand")
(match_operand:V16QI 2 "vsx_register_operand")
- (match_operand:QI 3 "const_0_to_11_operand")]
+ (match_operand:QI 3 "const_0_to_12_operand")]
UNSPEC_XXINSERTW))]
"TARGET_P9_VECTOR"
{
@@ -3870,7 +3870,7 @@ (define_insn "*vinsert4b_internal"
[(set (match_operand:V16QI 0 "vsx_register_operand" "=wa")
(unspec:V16QI [(match_operand:V4SI 1 "vsx_register_operand" "wa")
(match_operand:V16QI 2 "vsx_register_operand" "0")
- (match_operand:QI 3 "const_0_to_11_operand" "n")]
+ (match_operand:QI 3 "const_0_to_12_operand" "n")]
UNSPEC_XXINSERTW))]
"TARGET_P9_VECTOR"
"xxinsertw %x0,%x1,%3"
@@ -3880,7 +3880,7 @@ (define_expand "vinsert4b_di"
[(set (match_operand:V16QI 0 "vsx_register_operand")
(unspec:V16QI
Re: [PATCH], Fix PowerPC ISA 3.0 word extract/insert thinkos
On Fri, Dec 23, 2016 at 04:47:22PM -0500, Michael Meissner wrote: > I had two thinkos in my previous patches for ISA 3.0 (power9) support that > both > relate to word extraction and insertion. > > The first thinko was that I thought the index for the first byte in the 4 > bytes > to be extracted should be 0..11, when it should be 0..12. If it isn't allowed > to be 12, you cannot extract the 32-bit word at the bottom of the vector > register. > > The second thinko is where I was doing zeo extending of a 32-bit value within > a vector register, I used xxextractuw with a byte offset of 1 instead of 4. > > I have done the usual bootstrap and make check with no regressions on these > patches. Can I install them into the trunk? Yes please. It sounds like we need a few more testcases though? Segher > 2016-12-23 Michael Meissner > > * config/rs6000/predicates.md (const_0_to_12_operand): Rename > predicate and change test from 0..11 to 0..12 to match the > semantics of the word extract/insert instructions. Change all > callers. > (const_0_to_11_operand): Likewise. > * config/rs6000/vsx.md (vextract4b): Likewise. > (vextract4b_internal): Likewise. > (vinsert4b): Likewise. > (vinsert4b_internal): Likewise. > (vinsert4b_di): Likewise. > (vinsert4b_di_internal): Likewise. > * config/rs6000/rs6000.md (zero_extendsi2): Fix offset used > in xxextractuw to zero extend the word in the vector registers. > (lfiwzx): Likewise.
Re: [C++ PATCH] Extend the list of implicit noexcept C library symbols for -std=c++11 and -std=c++17 (PR middle-end/78901)
On Fri, Dec 23, 2016 at 11:09 AM, Jakub Jelinek wrote: > On Fri, Dec 23, 2016 at 10:09:05AM -0500, Jason Merrill wrote: >> On Fri, Dec 23, 2016 at 3:48 AM, Jakub Jelinek wrote: >> > Hi! >> > >> > C++ says that C library functions are implicitly noexcept, except for those >> > like qsort and bsearch where exceptions can be thrown from the callbacks. >> > >> > We handle this through cfns.gperf, but that contains only list of C89 >> > functions, while C++11 and C++14 refer to C99 and C++17 refers to C11. >> > >> > I went through the C99 and C11 standards, gathered all functions from there >> > (not macros nor generic functions) and using gperf %struct-type feature >> > attached the C version next to each symbol, so that e.g. snprintf is >> > noexcept only with -std=c++11 and above and e.g. mbrtoc16 only with >> > -std=c++17. Without this, we still consider snprintf as potentially >> > throwing, which breaks gimple-ssa-sprintf.c assumptions. For -std=c++98 >> > snprintf is not considered a builtin. >> >> Let's only be strict about this if flag_iso is set; for C library >> usage it shouldn't usually matter what C++ standard we're using. > > So like this? Yes, OK. Jason
Re: [PATCH] better handling of ranges (PR 78703)
On 2016.12.23 at 14:25 -0700, 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.
I must confess that I find these -Wformat-length warnings nearly
unparseable. They need much better documentation that explains where all
these seemingly random looking numbers are coming from.
And I also think that -Wformat-length should not be enabled by -Wall and
not even by -Wextra. The user should specifically ask for it.
--
Markus
