Re: [PATCH] Enable Intel AVX512_4FMAPS and AVX512_4VNNIW instructions
On Fri, Nov 18, 2016 at 09:30:06PM +0100, Jakub Jelinek wrote:
> On Fri, Nov 18, 2016 at 08:41:01PM +0100, Jakub Jelinek wrote:
> > I'm seeing lots of ICEs with this.
>
> Here is untested fix for that, will bootstrap/regtest it soon (after my
> current set of bootstraps finishes).
>
> 2016-11-18 Jakub Jelinek
>
> * config/i386/i386.c (ix86_expand_builtin): Remove msk_mov variable,
> don't initialize it, don't use it for the case where it isn't
> provable %{z} nor using the same argument, instead move merge
> argument into a new pseudo and use that as target. Formatting fixes.
Now successfully bootstrapped/regtested on x86_64-linux and i686-linux and
fixed a couple of FAILs, but not tons of others.
Here is another patch I'm going to test which fixes many other FAILs, but
still some are left:
FAIL: gcc.target/i386/funcspec-3.c (internal compiler error)
FAIL: gcc.target/i386/funcspec-3.c (test for excess errors)
FAIL: gcc.target/i386/mvc1.c (internal compiler error)
FAIL: gcc.target/i386/mvc1.c (test for excess errors)
FAIL: gcc.target/i386/mvc6.c (internal compiler error)
FAIL: gcc.target/i386/mvc6.c (test for excess errors)
FAIL: gcc.target/i386/mvc6.c scan-assembler vpshufb
FAIL: gcc.target/i386/mvc6.c scan-assembler punpcklbw
FAIL: gcc.target/i386/mvc8.c (internal compiler error)
FAIL: gcc.target/i386/mvc8.c (test for excess errors)
FAIL: gcc.target/i386/pr67995-2.c (internal compiler error)
FAIL: gcc.target/i386/pr67995-2.c (test for excess errors)
FAIL: gcc.target/i386/pr71652-3.c (internal compiler error)
FAIL: gcc.target/i386/pr71652-3.c (test for errors, line 5)
FAIL: gcc.target/i386/pr71652-3.c (test for excess errors)
Will debug even those.
2016-11-19 Jakub Jelinek
* config/i386/i386.c (def_builtin, def_builtin2, def_builtin_const2,
ix86_add_new_builtins): Formatting fixes.
(ix86_expand_builtin): Use || instead of && for isa vs. isa2.
(ix86_get_builtin): Likewise.
--- gcc/config/i386/i386.c.jj 2016-11-18 22:30:16.0 +0100
+++ gcc/config/i386/i386.c 2016-11-19 08:37:45.748175866 +0100
@@ -30924,7 +30924,7 @@ def_builtin (HOST_WIDE_INT mask, const c
means that *both* cpuid bits must be set for the built-in to be
available.
Handle this here. */
if (mask & ix86_isa_flags & OPTION_MASK_ISA_AVX512VL)
- mask &= ~OPTION_MASK_ISA_AVX512VL;
+ mask &= ~OPTION_MASK_ISA_AVX512VL;
mask &= ~OPTION_MASK_ISA_64BIT;
if (mask == 0
@@ -30976,8 +30976,8 @@ def_builtin_const (HOST_WIDE_INT mask, c
static inline tree
def_builtin2 (HOST_WIDE_INT mask, const char *name,
-enum ix86_builtin_func_type tcode,
-enum ix86_builtins code)
+ enum ix86_builtin_func_type tcode,
+ enum ix86_builtins code)
{
tree decl = NULL_TREE;
@@ -30992,8 +30992,8 @@ def_builtin2 (HOST_WIDE_INT mask, const
tree type = ix86_get_builtin_func_type (tcode);
decl = add_builtin_function (name, type, code, BUILT_IN_MD,
NULL, NULL_TREE);
- ix86_builtins[(int) code] = decl;
- ix86_builtins_isa[(int) code].set_and_not_built_p = false;
+ ix86_builtins[(int) code] = decl;
+ ix86_builtins_isa[(int) code].set_and_not_built_p = false;
}
else
{
@@ -31016,7 +31016,7 @@ def_builtin2 (HOST_WIDE_INT mask, const
static inline tree
def_builtin_const2 (HOST_WIDE_INT mask, const char *name,
- enum ix86_builtin_func_type tcode, enum ix86_builtins code)
+ enum ix86_builtin_func_type tcode, enum ix86_builtins code)
{
tree decl = def_builtin2 (mask, name, tcode, code);
if (decl)
@@ -31034,8 +31034,8 @@ def_builtin_const2 (HOST_WIDE_INT mask,
static void
ix86_add_new_builtins (HOST_WIDE_INT isa, HOST_WIDE_INT isa2)
{
- if (((isa & deferred_isa_values) == 0)
- && ((isa2 & deferred_isa_values2) == 0))
+ if ((isa & deferred_isa_values) == 0
+ && (isa2 & deferred_isa_values2) == 0)
return;
/* Bits in ISA value can be removed from potential isa values. */
@@ -31048,7 +31048,8 @@ ix86_add_new_builtins (HOST_WIDE_INT isa
for (i = 0; i < (int)IX86_BUILTIN_MAX; i++)
{
- if ix86_builtins_isa[i].isa & isa) != 0) ||
((ix86_builtins_isa[i].isa2 & isa2) != 0))
+ if (((ix86_builtins_isa[i].isa & isa) != 0
+ || (ix86_builtins_isa[i].isa2 & isa2) != 0)
&& ix86_builtins_isa[i].set_and_not_built_p)
{
tree decl, type;
@@ -36549,7 +36550,7 @@ ix86_expand_builtin (tree exp, rtx targe
whether it is supported. */
if ((ix86_builtins_isa[fcode].isa
&& !(ix86_builtins_isa[fcode].isa & ix86_isa_flags))
- && (ix86_builtins_isa[fcode].isa2
+ || (ix86_builtins_isa[fcode].isa2
&& !(ix86_builtins_isa[fcode].isa2 & ix86_isa_flags2)))
{
char *opts = ix86_target_string (ix86_builtins_isa[fcode].isa,
@@ -38514,7 +38515,7 @@ static tree ix86_get_buil
Re: [PATCH] Enable Intel AVX512_4FMAPS and AVX512_4VNNIW instructions
On Sat, Nov 19, 2016 at 09:05:05AM +0100, Jakub Jelinek wrote:
> On Fri, Nov 18, 2016 at 09:30:06PM +0100, Jakub Jelinek wrote:
> > On Fri, Nov 18, 2016 at 08:41:01PM +0100, Jakub Jelinek wrote:
> > > I'm seeing lots of ICEs with this.
> >
> > Here is untested fix for that, will bootstrap/regtest it soon (after my
> > current set of bootstraps finishes).
> >
> > 2016-11-18 Jakub Jelinek
> >
> > * config/i386/i386.c (ix86_expand_builtin): Remove msk_mov variable,
> > don't initialize it, don't use it for the case where it isn't
> > provable %{z} nor using the same argument, instead move merge
> > argument into a new pseudo and use that as target. Formatting fixes.
>
> Now successfully bootstrapped/regtested on x86_64-linux and i686-linux and
> fixed a couple of FAILs, but not tons of others.
>
> Here is another patch I'm going to test which fixes many other FAILs, but
> still some are left:
> FAIL: gcc.target/i386/funcspec-3.c (internal compiler error)
> FAIL: gcc.target/i386/funcspec-3.c (test for excess errors)
> FAIL: gcc.target/i386/mvc1.c (internal compiler error)
> FAIL: gcc.target/i386/mvc1.c (test for excess errors)
> FAIL: gcc.target/i386/mvc6.c (internal compiler error)
> FAIL: gcc.target/i386/mvc6.c (test for excess errors)
> FAIL: gcc.target/i386/mvc6.c scan-assembler vpshufb
> FAIL: gcc.target/i386/mvc6.c scan-assembler punpcklbw
> FAIL: gcc.target/i386/mvc8.c (internal compiler error)
> FAIL: gcc.target/i386/mvc8.c (test for excess errors)
> FAIL: gcc.target/i386/pr67995-2.c (internal compiler error)
> FAIL: gcc.target/i386/pr67995-2.c (test for excess errors)
> FAIL: gcc.target/i386/pr71652-3.c (internal compiler error)
> FAIL: gcc.target/i386/pr71652-3.c (test for errors, line 5)
> FAIL: gcc.target/i386/pr71652-3.c (test for excess errors)
> Will debug even those.
The fix for that (still not bootstrapped/regtested) is below.
Will now bootstrap/regtest all 3 patches and hopefully all the 4fma*
introduced regressions will be gone.
2016-11-19 Jakub Jelinek
* config/i386/i386.c (ix86_valid_target_attribute_tree): Don't
clear opts->x_ix86_isa_flags, clear opts->x_ix86_isa_flags2
instead and using = 0 instead of &= 0.
--- gcc/config/i386/i386.c.jj 2016-11-19 08:54:37.0 +0100
+++ gcc/config/i386/i386.c 2016-11-19 09:20:52.314913008 +0100
@@ -6845,7 +6845,7 @@ ix86_valid_target_attribute_tree (tree a
| OPTION_MASK_ABI_64
| OPTION_MASK_ABI_X32
| OPTION_MASK_CODE16);
- opts->x_ix86_isa_flags &= 0;
+ opts->x_ix86_isa_flags2 = 0;
}
else if (!orig_arch_specified)
opts->x_ix86_arch_string = NULL;
Jakub
[PATCH, committed] TILEPro: link against libgcc.a when creating shared libraries
This patch forces gcc to link against libgcc.a when creating shared
libraries, needed for 64-bit multiplies.
Bootstrapped and tested on tilepro hardware, also backported to GCC 6.
2016-11-18 Walter Lee
* config.host (tilepro*-*-linux*): Add t-slibgcc-libgcc.
diff --git a/libgcc/config.host b/libgcc/config.host
index 64beb21..e7e5413 100644
--- a/libgcc/config.host
+++ b/libgcc/config.host
@@ -1267,7 +1267,7 @@ tilegx*-*-linux*)
md_unwind_header=tilepro/linux-unwind.h
;;
tilepro*-*-linux*)
- tmake_file="${tmake_file} tilepro/t-crtstuff t-softfp-sfdf t-softfp
tilepro/t-tilepro"
+ tmake_file="${tmake_file} tilepro/t-crtstuff t-softfp-sfdf t-softfp
tilepro/t-tilepro t-slibgcc-libgcc"
md_unwind_header=tilepro/linux-unwind.h
;;
v850*-*-*)
Re: [Patch, Fortran] PR 78392: ICE in gfc_trans_auto_array_allocation, at fortran/trans-array.c:5979
Hi all,
> I previously assumed that the test case for this PR would be legal,
> but by now I think that's wrong. The test case should be rejected, and
> we already have checking mechanisms for this (see
> resolve_fl_variable), but apparently they are not working.
>
> My current suspicion is that 'gfc_is_constant_expr' has a bug, because
> it claims the call to the function 'get_i' to be a constant
> expression. This is not true, because get_i() can not be reduced to a
> compile-time constant.
some more reading in the standard confirms this suspicion: In
gfc_is_constant_expr there is a piece of code which claims that
specification functions are constant. That is certainly not true, and
so what I'm doing in the attached fix is to remove that code and add
some references to the standard to make things clearer.
The code that I'm removing has last been touched in this commit by
Jerry six years ago:
https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=166520
However, this did not introduce the bug in the first place (not sure
when that happened).
In any case the new patch in the attachment regtests cleanly and
correctly rejects the original test case as well as one of the cases
mentioned by Dominique. Ok for trunk?
Cheers,
Janus
2016-11-19 Janus Weil
PR fortran/78392
* expr.c (gfc_is_constant_expr): Specification functions are not
compile-time constants. Update documentation (add reference to F08
standard), add a FIXME.
(external_spec_function): Add reference to F08 standard.
* resolve.c (resolve_fl_variable): Ditto.
2016-11-19 Janus Weil
PR fortran/78392
* gfortran.dg/constant_shape.f90: New test case.
Index: gcc/fortran/expr.c
===
--- gcc/fortran/expr.c (Revision 242620)
+++ gcc/fortran/expr.c (Arbeitskopie)
@@ -883,8 +883,9 @@ done:
}
-/* Function to determine if an expression is constant or not. This
- function expects that the expression has already been simplified. */
+/* Determine if an expression is constant in the sense of F08:7.1.12.
+ * This function expects that the expression has already been simplified.
+ * FIXME: Return a bool, not an int. */
int
gfc_is_constant_expr (gfc_expr *e)
@@ -891,7 +892,6 @@ gfc_is_constant_expr (gfc_expr *e)
{
gfc_constructor *c;
gfc_actual_arglist *arg;
- gfc_symbol *sym;
if (e == NULL)
return 1;
@@ -920,25 +920,6 @@ gfc_is_constant_expr (gfc_expr *e)
return 0;
}
- /* Specification functions are constant. */
- /* F95, 7.1.6.2; F2003, 7.1.7 */
- sym = NULL;
- if (e->symtree)
- sym = e->symtree->n.sym;
- if (e->value.function.esym)
- sym = e->value.function.esym;
-
- if (sym
- && sym->attr.function
- && sym->attr.pure
- && !sym->attr.intrinsic
- && !sym->attr.recursive
- && sym->attr.proc != PROC_INTERNAL
- && sym->attr.proc != PROC_ST_FUNCTION
- && sym->attr.proc != PROC_UNKNOWN
- && gfc_sym_get_dummy_args (sym) == NULL)
- return 1;
-
if (e->value.function.isym
&& (e->value.function.isym->elemental
|| e->value.function.isym->pure
@@ -2741,7 +2722,8 @@ restricted_args (gfc_actual_arglist *a)
/* Restricted/specification expressions */
-/* Make sure a non-intrinsic function is a specification function. */
+/* Make sure a non-intrinsic function is a specification function,
+ * see F08:7.1.11.5. */
static bool
external_spec_function (gfc_expr *e)
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c (Revision 242620)
+++ gcc/fortran/resolve.c (Arbeitskopie)
@@ -11831,8 +11831,8 @@ resolve_fl_variable (gfc_symbol *sym, int mp_flag)
&& !sym->attr.pointer
&& is_non_constant_shape_array (sym))
{
- /* The shape of a main program or module array needs to be
-constant. */
+ /* F08:C541. The shape of an array defined in a main program or module
+ * needs to be constant. */
gfc_error ("The module or main program array %qs at %L must "
"have constant shape", sym->name, &sym->declared_at);
specification_expr = saved_specification_expr;
! { dg-do compile }
!
! PR 78392: ICE in gfc_trans_auto_array_allocation, at fortran/trans-array.c:5979
!
! Contributed by Janus Weil
module mytypes
implicit none
contains
pure integer function get_i ()
get_i = 13
end function
end module
program test
use mytypes
implicit none
integer, dimension(get_i()) :: x ! { dg-error "must have constant shape" }
print *, size (x)
end
New Spanish 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 Spanish team of translators. The file is available at: http://translationproject.org/latest/gcc/es.po (This file, 'gcc-6.2.0.es.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] libgcc/mkmap-symver: support skip_underscore (PR74748)
Hello, On Thu, 17 Nov 2016 14:08:34 -0700, Jeff Law wrote: > AFAICT this skips the first character regardless of whether or not it is > an underscore when skip_underscore is in effect, right. Correct. > Is that intentional? All symbols in Blackfin are prepended with an underscore, so we're pretty much guaranteed there is one, and we precisely want to get rid of this prepended underscore. So I'd say it's good enough to get rid of the first character, without checking if it's an underscore or not. Of course, if you think we really want to be extra safe and only remove it after making sure it's an underscore, I can probably improve the awk logic to handle this. Thanks for the feedback! Thomas -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com
Re: [PATCH] Enable Intel AVX512_4FMAPS and AVX512_4VNNIW instructions
On Sat, Nov 19, 2016 at 9:05 AM, Jakub Jelinek wrote:
> On Fri, Nov 18, 2016 at 09:30:06PM +0100, Jakub Jelinek wrote:
>> On Fri, Nov 18, 2016 at 08:41:01PM +0100, Jakub Jelinek wrote:
>> > I'm seeing lots of ICEs with this.
>>
>> Here is untested fix for that, will bootstrap/regtest it soon (after my
>> current set of bootstraps finishes).
>>
>> 2016-11-18 Jakub Jelinek
>>
>> * config/i386/i386.c (ix86_expand_builtin): Remove msk_mov variable,
>> don't initialize it, don't use it for the case where it isn't
>> provable %{z} nor using the same argument, instead move merge
>> argument into a new pseudo and use that as target. Formatting fixes.
>
> Now successfully bootstrapped/regtested on x86_64-linux and i686-linux and
> fixed a couple of FAILs, but not tons of others.
>
> Here is another patch I'm going to test which fixes many other FAILs, but
> still some are left:
> FAIL: gcc.target/i386/funcspec-3.c (internal compiler error)
> FAIL: gcc.target/i386/funcspec-3.c (test for excess errors)
> FAIL: gcc.target/i386/mvc1.c (internal compiler error)
> FAIL: gcc.target/i386/mvc1.c (test for excess errors)
> FAIL: gcc.target/i386/mvc6.c (internal compiler error)
> FAIL: gcc.target/i386/mvc6.c (test for excess errors)
> FAIL: gcc.target/i386/mvc6.c scan-assembler vpshufb
> FAIL: gcc.target/i386/mvc6.c scan-assembler punpcklbw
> FAIL: gcc.target/i386/mvc8.c (internal compiler error)
> FAIL: gcc.target/i386/mvc8.c (test for excess errors)
> FAIL: gcc.target/i386/pr67995-2.c (internal compiler error)
> FAIL: gcc.target/i386/pr67995-2.c (test for excess errors)
> FAIL: gcc.target/i386/pr71652-3.c (internal compiler error)
> FAIL: gcc.target/i386/pr71652-3.c (test for errors, line 5)
> FAIL: gcc.target/i386/pr71652-3.c (test for excess errors)
I wonder why patch submitter didn't get these failures during
regtesting. There are plenty of tests (the above multi-vrsioning
tests) that depend on correct handling of ISA variables. I assumed
that these tests passed and consequently didn't went deep into the
implementation, but rather requested a couple of additional tests that
exercised added functionality.some more.
> Will debug even those.
Thanks!
Uros.
> 2016-11-19 Jakub Jelinek
>
> * config/i386/i386.c (def_builtin, def_builtin2, def_builtin_const2,
> ix86_add_new_builtins): Formatting fixes.
> (ix86_expand_builtin): Use || instead of && for isa vs. isa2.
> (ix86_get_builtin): Likewise.
>
> --- gcc/config/i386/i386.c.jj 2016-11-18 22:30:16.0 +0100
> +++ gcc/config/i386/i386.c 2016-11-19 08:37:45.748175866 +0100
> @@ -30924,7 +30924,7 @@ def_builtin (HOST_WIDE_INT mask, const c
> means that *both* cpuid bits must be set for the built-in to be
> available.
> Handle this here. */
>if (mask & ix86_isa_flags & OPTION_MASK_ISA_AVX512VL)
> - mask &= ~OPTION_MASK_ISA_AVX512VL;
> + mask &= ~OPTION_MASK_ISA_AVX512VL;
>
>mask &= ~OPTION_MASK_ISA_64BIT;
>if (mask == 0
> @@ -30976,8 +30976,8 @@ def_builtin_const (HOST_WIDE_INT mask, c
>
> static inline tree
> def_builtin2 (HOST_WIDE_INT mask, const char *name,
> -enum ix86_builtin_func_type tcode,
> -enum ix86_builtins code)
> + enum ix86_builtin_func_type tcode,
> + enum ix86_builtins code)
> {
>tree decl = NULL_TREE;
>
> @@ -30992,8 +30992,8 @@ def_builtin2 (HOST_WIDE_INT mask, const
>tree type = ix86_get_builtin_func_type (tcode);
>decl = add_builtin_function (name, type, code, BUILT_IN_MD,
>NULL, NULL_TREE);
> - ix86_builtins[(int) code] = decl;
> - ix86_builtins_isa[(int) code].set_and_not_built_p = false;
> + ix86_builtins[(int) code] = decl;
> + ix86_builtins_isa[(int) code].set_and_not_built_p = false;
> }
>else
> {
> @@ -31016,7 +31016,7 @@ def_builtin2 (HOST_WIDE_INT mask, const
>
> static inline tree
> def_builtin_const2 (HOST_WIDE_INT mask, const char *name,
> - enum ix86_builtin_func_type tcode, enum ix86_builtins code)
> + enum ix86_builtin_func_type tcode, enum ix86_builtins
> code)
> {
>tree decl = def_builtin2 (mask, name, tcode, code);
>if (decl)
> @@ -31034,8 +31034,8 @@ def_builtin_const2 (HOST_WIDE_INT mask,
> static void
> ix86_add_new_builtins (HOST_WIDE_INT isa, HOST_WIDE_INT isa2)
> {
> - if (((isa & deferred_isa_values) == 0)
> - && ((isa2 & deferred_isa_values2) == 0))
> + if ((isa & deferred_isa_values) == 0
> + && (isa2 & deferred_isa_values2) == 0)
> return;
>
>/* Bits in ISA value can be removed from potential isa values. */
> @@ -31048,7 +31048,8 @@ ix86_add_new_builtins (HOST_WIDE_INT isa
>
>for (i = 0; i < (int)IX86_BUILTIN_MAX; i++)
> {
> - if ix86_builtins_isa[i].isa & isa) != 0) ||
> ((ix86_builtins_isa[i].isa2 & isa2) != 0))
> + if (((ix86_builtins_isa[i].isa & isa)
[PATCHv2, C++] Warn on redefinition of builtin functions (PR c++/71973)
Hi,
On 11/18/16 22:19, Jason Merrill wrote:
> On 11/05/2016 12:44 PM, Bernd Edlinger wrote:
>> + warning_at (DECL_SOURCE_LOCATION (newdecl), 0,
>> + "declaration of %q+#D conflicts with built-in "
>> + "declaration %q#D", newdecl, olddecl);
>
> There needs to be a way to disable this warning, even if it's enabled by
> default.
>
>> - TREE_NOTHROW (olddecl) = 0;
>> + TREE_NOTHROW (olddecl) = TREE_NOTHROW (newdecl);
>
> I still think a better fix would be to add a copy of TREE_NOTHROW to the
> else block of the if (types_match), to go with the existing copies of
> TREE_READONLY and TREE_THIS_VOLATILE.
>
I changed the patch as requested. I think meanwhile that this else
block does only handle a built-in function with different signature.
I have now changed also the C front end to emit the warning with the new
default-enabled -Wbuiltin-declaration-mismatch.
When I looked at the c-decl.c code, I saw there are effectively two
warnings, one for a function that does not match the builtin signature,
and another for a global variable that has the the name of a built-in.
like:
test.c
int printf;
gives warning:
test.c:1:5: warning: built-in function 'printf' declared as non-function
int printf;
the same in C++ gives nothing.
That is because of this in duplicate_decls:
if (TREE_CODE (newdecl) != FUNCTION_DECL)
{
/* Avoid warnings redeclaring built-ins which have not been
explicitly declared. */
if (DECL_ANTICIPATED (olddecl))
return NULL_TREE;
That is from gcc3.1 in 2002 a rather radical patch I would say.
I left the warning for declaring a variable with the name of built-in
function for next time, maybe...
Bootstrapped and reg-tested on x86_64-pc-linux-gnu.
Is it OK for trunk?
Thanks
Bernd.
gcc:
2016-11-19 Bernd Edlinger
PR c++/71973
* doc/invoke.texi (-Wno-builtin-declaration-mismatch): Document the
new default-enabled warning..
* builtin-types.def (BT_CONST_TM_PTR): New primitive type.
(BT_PTR_CONST_STRING): Updated.
(BT_FN_SIZE_STRING_SIZE_CONST_STRING_CONST_PTR): Removed.
(BT_FN_SIZE_STRING_SIZE_CONST_STRING_CONST_TM_PTR): New function type.
* builtins.def (DEF_TM_BUILTIN): Disable BOTH_P for TM builtins.
(strftime): Update builtin function.
* tree-core.h (TI_CONST_TM_PTR_TYPE): New enum value.
* tree.h (const_tm_ptr_type_node): New type node.
* tree.c (free_lang_data, build_common_tree_nodes): Initialize
const_tm_ptr_type_node.
c-family:
2016-11-19 Bernd Edlinger
PR c++/71973
* c.opt (-Wbuiltin-declaration-mismatch): New warning.
* c-common.c (c_common_nodes_and_builtins): Initialize
const_tm_ptr_type_node.
c:
2016-11-19 Bernd Edlinger
PR c++/71973
* c-decl.c (diagnose_mismatched_decls): Use
OPT_Wbuiltin_declaration_mismatch here too.
cp:
2016-11-19 Bernd Edlinger
PR c++/71973
* decl.c (duplicate_decls): Warn when a built-in function is redefined.
Don't overload builtin functions with C++ functions.
Handle const_tm_ptr_type_node like file_ptr_node.
Copy the TREE_NOTHROW flag unmodified to the old decl.
lto:
2016-11-05 Bernd Edlinger
PR c++/71973
* lto-lang.c (lto_init): Assert const_tm_ptr_type_node is sane.
testsuite:
2016-11-05 Bernd Edlinger
PR c++/71973
* g++.dg/pr71973-1.C: New test.
* g++.dg/pr71973-2.C: New test.
* g++.dg/pr71973-3.C: New test.
* g++.dg/lto/pr68811_0.C: Add -w to first lto-options.
* g++.dg/lookup/extern-c-redecl4.C: Adjust test expectations.
* g++.old-deja/g++.mike/p700.C: Add -w to dg-options.
* g++.old-deja/g++.other/realloc.C: Add -w to dg-options.
* g++.old-deja/g++.other/builtins10.C: Adjust test expectation.
Index: gcc/builtin-types.def
===
--- gcc/builtin-types.def (revision 242620)
+++ gcc/builtin-types.def (working copy)
@@ -103,6 +103,7 @@ DEF_PRIMITIVE_TYPE (BT_COMPLEX_LONGDOUBLE, complex
DEF_PRIMITIVE_TYPE (BT_PTR, ptr_type_node)
DEF_PRIMITIVE_TYPE (BT_FILEPTR, fileptr_type_node)
+DEF_PRIMITIVE_TYPE (BT_CONST_TM_PTR, const_tm_ptr_type_node)
DEF_PRIMITIVE_TYPE (BT_CONST_PTR, const_ptr_type_node)
DEF_PRIMITIVE_TYPE (BT_VOLATILE_PTR,
build_pointer_type
@@ -146,7 +147,12 @@ DEF_PRIMITIVE_TYPE (BT_I16, builtin_type_for_size
DEF_PRIMITIVE_TYPE (BT_BND, pointer_bounds_type_node)
-DEF_POINTER_TYPE (BT_PTR_CONST_STRING, BT_CONST_STRING)
+/* The C type `char * const *'. */
+DEF_PRIMITIVE_TYPE (BT_PTR_CONST_STRING,
+ build_pointer_type
+ (build_qualified_type (string_type_node,
+ TYPE_QUAL_CONST)))
+
DEF_POINTER_TYPE (BT_PTR_UINT, BT_UINT)
DEF_POINTER_TYPE (BT_PTR_LONG, BT_LONG)
DEF_POINTER_TYPE (BT_PTR_ULONG, BT_ULONG)
@@ -511,8 +517,8 @@ DEF_F
Re: [PATCH] Fix NetBSD bootstrap
On Thu, 17 Nov 2016, Joseph Myers wrote: I'll presume you know best about the choices of stdint.h types. You may wish to consider what the correct value of use_gcc_stdint is - the default "none" (rely on the system's header), or "wrap" (use GCC's header in freestanding mode) or "provide" (always use GCC's header). I committed the following to set it to "wrap" (which is consistent with how the other BSDs handle it). Bootstrapped and tested on x86_64-unknown-netbsd6.1. /Krister 2016-11-19 Krister Walfridsson * config.gcc (*-*-netbsd): Set use_gcc_stdint=wrap. Index: gcc/config.gcc === --- gcc/config.gcc (revision 242620) +++ gcc/config.gcc (revision 242621) @@ -768,6 +768,7 @@ tmake_file="t-slibgcc" gas=yes gnu_ld=yes + use_gcc_stdint=wrap # NetBSD 2.0 and later get POSIX threads enabled by default. # Allow them to be explicitly enabled on any other version.
Re: [PATCH] Enable Intel AVX512_4FMAPS and AVX512_4VNNIW instructions
On Sat, Nov 19, 2016 at 11:17:55AM +0100, Uros Bizjak wrote:
> > Here is another patch I'm going to test which fixes many other FAILs, but
> > still some are left:
> > FAIL: gcc.target/i386/funcspec-3.c (internal compiler error)
> > FAIL: gcc.target/i386/funcspec-3.c (test for excess errors)
> > FAIL: gcc.target/i386/mvc1.c (internal compiler error)
> > FAIL: gcc.target/i386/mvc1.c (test for excess errors)
> > FAIL: gcc.target/i386/mvc6.c (internal compiler error)
> > FAIL: gcc.target/i386/mvc6.c (test for excess errors)
> > FAIL: gcc.target/i386/mvc6.c scan-assembler vpshufb
> > FAIL: gcc.target/i386/mvc6.c scan-assembler punpcklbw
> > FAIL: gcc.target/i386/mvc8.c (internal compiler error)
> > FAIL: gcc.target/i386/mvc8.c (test for excess errors)
> > FAIL: gcc.target/i386/pr67995-2.c (internal compiler error)
> > FAIL: gcc.target/i386/pr67995-2.c (test for excess errors)
> > FAIL: gcc.target/i386/pr71652-3.c (internal compiler error)
> > FAIL: gcc.target/i386/pr71652-3.c (test for errors, line 5)
> > FAIL: gcc.target/i386/pr71652-3.c (test for excess errors)
>
> I wonder why patch submitter didn't get these failures during
> regtesting. There are plenty of tests (the above multi-vrsioning
> tests) that depend on correct handling of ISA variables. I assumed
> that these tests passed and consequently didn't went deep into the
> implementation, but rather requested a couple of additional tests that
> exercised added functionality.some more.
Dunno, clearly the patch has not been tested at all, at least not in
the form that has been checked in.
I've now bootstrapped/regtested on x86_64-linux and i686-linux all these
3 patches:
http://gcc.gnu.org/ml/gcc-patches/2016-11/msg01992.html
http://gcc.gnu.org/ml/gcc-patches/2016-11/msg02026.html
http://gcc.gnu.org/ml/gcc-patches/2016-11/msg02027.html
, e.g. on x86_64-linux they fix:
-FAIL: gcc.target/i386/avx-2.c (internal compiler error)
-FAIL: gcc.target/i386/avx-2.c (test for excess errors)
-FAIL: gcc.target/i386/avx2-gather-2.c scan-tree-dump-times vect "note:
vectorized 1 loops in function" 16
-FAIL: gcc.target/i386/avx2-gather-6.c scan-tree-dump-times vect "note:
vectorized 1 loops in function" 1
-FAIL: gcc.target/i386/avx512f-ceil-sfix-vec-2.c scan-assembler-times
vcvttpd2dq[^\\n]*zmm[0-9].{7}(?:\\n|[ t]+#) 2
-FAIL: gcc.target/i386/avx512f-ceil-sfix-vec-2.c scan-assembler-times
vrndscalepd[^\\n]*zmm[0-9](?:\\n|[ t]+#) 2
-FAIL: gcc.target/i386/avx512f-ceil-vec-2.c scan-assembler-times
vrndscalepd[^\\n]+zmm[0-9](?:\\n|[ t]+#) 1
-FAIL: gcc.target/i386/avx512f-ceilf-sfix-vec-2.c scan-assembler-times
vcvttps2dq[^\\n]+zmm[0-9].{7}(?:\\n|[ t]+#) 1
-FAIL: gcc.target/i386/avx512f-ceilf-sfix-vec-2.c scan-assembler-times
vrndscaleps[^\\n]+zmm[0-9](?:\\n|[ t]+#) 1
-FAIL: gcc.target/i386/avx512f-ceilf-vec-2.c scan-assembler-times
vrndscaleps[^\\n]+zmm[0-9](?:\\n|[ t]+#) 1
-FAIL: gcc.target/i386/avx512f-floor-sfix-vec-2.c scan-assembler-times
vcvttpd2dq[^\\n]*zmm[0-9].{7}(?:\\n|[ t]+#) 2
-FAIL: gcc.target/i386/avx512f-floor-sfix-vec-2.c scan-assembler-times
vrndscalepd[^\\n]*zmm[0-9](?:\\n|[ t]+#) 2
-FAIL: gcc.target/i386/avx512f-floor-vec-2.c scan-assembler-times
vrndscalepd[^\\n]+zmm[0-9](?:\\n|[ t]+#) 1
-FAIL: gcc.target/i386/avx512f-floorf-sfix-vec-2.c scan-assembler-times
vcvttps2dq[^\\n]+zmm[0-9].{7}(?:\\n|[ t]+#) 1
-FAIL: gcc.target/i386/avx512f-floorf-sfix-vec-2.c scan-assembler-times
vrndscaleps[^\\n]+zmm[0-9](?:\\n|[ t]+#) 1
-FAIL: gcc.target/i386/avx512f-floorf-vec-2.c scan-assembler-times
vrndscaleps[^\\n]+zmm[0-9](?:\\n|[ t]+#) 1
-FAIL: gcc.target/i386/avx512f-gather-2.c scan-tree-dump-times vect "note:
vectorized 1 loops in function" 16
-FAIL: gcc.target/i386/avx512f-gather-5.c scan-assembler-times
gather[^\\n]*zmm[0-9]+{%k[1-7]}(?:\\n|[ t]+#) 2
-FAIL: gcc.target/i386/avx512f-rint-sfix-vec-2.c scan-assembler-times
vcvtpd2dq[^\\n]+ymm[0-9](?:\\n|[ t]+#) 2
-FAIL: gcc.target/i386/avx512f-rint-sfix-vec-2.c scan-assembler-times
vinserti64x4[^\\n]+zmm[0-9](?:\\n|[ t]+#) 1
-FAIL: gcc.target/i386/avx512f-rintf-sfix-vec-2.c scan-assembler-times
vcvtps2dq[^\\n]+zmm[0-9](?:\\n|[ t]+#) 1
-FAIL: gcc.target/i386/avx512f-round-sfix-vec-2.c scan-assembler-times
vcvttpd2dq[^\\n]+zmm[0-9].{7}(?:\\n|[ t]+#) 2
-FAIL: gcc.target/i386/avx512f-round-sfix-vec-2.c scan-assembler-times
vrndscalepd[^\\n]+zmm[0-9](?:\\n|[ t]+#) 2
-FAIL: gcc.target/i386/avx512f-roundf-sfix-vec-2.c scan-assembler-times
vcvttps2dq[^\\n]+zmm[0-9].{7}(?:\\n|[ t]+#) 1
-FAIL: gcc.target/i386/avx512f-roundf-sfix-vec-2.c scan-assembler-times
vrndscaleps[^\\n]+zmm[0-9](?:\\n|[ t]+#) 1
-FAIL: gcc.target/i386/avx512f-trunc-vec-2.c scan-assembler-times
vrndscalepd[^\\n]+zmm[0-9](?:\\n|[ t]+#) 1
-FAIL: gcc.target/i386/avx512f-truncf-vec-2.c scan-assembler-times
vrndscaleps[^\\n]+zmm[0-9](?:\\n|[ t]+#) 1
-FAIL: gcc.target/i386/funcspec-8.c (test for errors, line 104)
-FAIL: gcc.target/i386/funcspec-8.c (t
[PATCH] shrink-wrap: Fix problem with DF checking (PR78400)
With my previous patch the compiler ICEs if you use --enable-checking=df. This patch fixes it, by calling df_update_entry_exit_and_calls instead of df_update_entry_block_defs and df_update_exit_block_uses. Bootstrapped and checked on powerpc64-linux (also with --enable-checking=df). Is this okay for trunk? Thanks, Segher 2016-11-19 Segher Boessenkool PR rtl-optimization/78400 * shrink-wrap.c (try_shrink_wrapping_separate): Call df_update_entry_exit_and_calls instead of df_update_entry_block_defs and df_update_exit_block_uses. --- gcc/shrink-wrap.c | 6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/gcc/shrink-wrap.c b/gcc/shrink-wrap.c index f838696..59feca1 100644 --- a/gcc/shrink-wrap.c +++ b/gcc/shrink-wrap.c @@ -1798,8 +1798,7 @@ try_shrink_wrapping_separate (basic_block first_bb) the register for that component is in the IN or GEN or KILL set for that block. */ df_scan->local_flags |= DF_SCAN_EMPTY_ENTRY_EXIT; - df_update_entry_block_defs (); - df_update_exit_block_uses (); + df_update_entry_exit_and_calls (); df_live_add_problem (); df_live_set_all_dirty (); df_analyze (); @@ -1867,8 +1866,7 @@ try_shrink_wrapping_separate (basic_block first_bb) /* All done. */ df_scan->local_flags &= ~DF_SCAN_EMPTY_ENTRY_EXIT; - df_update_entry_block_defs (); - df_update_exit_block_uses (); + df_update_entry_exit_and_calls (); df_live_set_all_dirty (); df_analyze (); } -- 1.9.3
[patch committed SH] Fix PR target/78426
I've applied the attached patch to fix PR target/78426 which is
a regression caused by rtl sharing with sh_expand_{cmpnstr,setmem}.
Tested with "make -k check" on sh4-unknown-linux-gnu. I'll backport
it to release branches.
Regards,
kaz
--
2016-11-19 Kaz Kojima
PR target/78426
* config/sh/sh-mem.cc (sh_expand_cmpnstr): Use copy_to_mode_reg
instead of force_reg.
(sh_expand_setmem): Likewise.
--
diff --git a/config/sh/sh-mem.cc b/config/sh/sh-mem.cc
index b965aed..f91afa5 100644
--- a/config/sh/sh-mem.cc
+++ b/config/sh/sh-mem.cc
@@ -347,7 +347,7 @@ sh_expand_cmpnstr (rtx *operands)
rtx_code_label *L_loop_byte = gen_label_rtx ();
rtx_code_label *L_end_loop_byte = gen_label_rtx ();
- rtx len = force_reg (SImode, operands[3]);
+ rtx len = copy_to_mode_reg (SImode, operands[3]);
int constp = CONST_INT_P (operands[3]);
const unsigned int addr1_alignment = MEM_ALIGN (operands[1]) / BITS_PER_UNIT;
@@ -672,9 +672,9 @@ sh_expand_setmem (rtx *operands)
rtx_insn *jump;
rtx dest = copy_rtx (operands[0]);
rtx dest_addr = copy_addr_to_reg (XEXP (dest, 0));
- rtx val = force_reg (SImode, operands[2]);
+ rtx val = copy_to_mode_reg (SImode, operands[2]);
int align = INTVAL (operands[3]);
- rtx len = force_reg (SImode, operands[1]);
+ rtx len = copy_to_mode_reg (SImode, operands[1]);
if (! CONST_INT_P (operands[1]))
return;
Re: [PATCH] Enable Intel AVX512_4FMAPS and AVX512_4VNNIW instructions
2016-11-19 13:17 GMT+03:00 Uros Bizjak :
> On Sat, Nov 19, 2016 at 9:05 AM, Jakub Jelinek wrote:
>> On Fri, Nov 18, 2016 at 09:30:06PM +0100, Jakub Jelinek wrote:
>>> On Fri, Nov 18, 2016 at 08:41:01PM +0100, Jakub Jelinek wrote:
>>> > I'm seeing lots of ICEs with this.
>>>
>>> Here is untested fix for that, will bootstrap/regtest it soon (after my
>>> current set of bootstraps finishes).
>>>
>>> 2016-11-18 Jakub Jelinek
>>>
>>> * config/i386/i386.c (ix86_expand_builtin): Remove msk_mov variable,
>>> don't initialize it, don't use it for the case where it isn't
>>> provable %{z} nor using the same argument, instead move merge
>>> argument into a new pseudo and use that as target. Formatting fixes.
>>
>> Now successfully bootstrapped/regtested on x86_64-linux and i686-linux and
>> fixed a couple of FAILs, but not tons of others.
>>
>> Here is another patch I'm going to test which fixes many other FAILs, but
>> still some are left:
>> FAIL: gcc.target/i386/funcspec-3.c (internal compiler error)
>> FAIL: gcc.target/i386/funcspec-3.c (test for excess errors)
>> FAIL: gcc.target/i386/mvc1.c (internal compiler error)
>> FAIL: gcc.target/i386/mvc1.c (test for excess errors)
>> FAIL: gcc.target/i386/mvc6.c (internal compiler error)
>> FAIL: gcc.target/i386/mvc6.c (test for excess errors)
>> FAIL: gcc.target/i386/mvc6.c scan-assembler vpshufb
>> FAIL: gcc.target/i386/mvc6.c scan-assembler punpcklbw
>> FAIL: gcc.target/i386/mvc8.c (internal compiler error)
>> FAIL: gcc.target/i386/mvc8.c (test for excess errors)
>> FAIL: gcc.target/i386/pr67995-2.c (internal compiler error)
>> FAIL: gcc.target/i386/pr67995-2.c (test for excess errors)
>> FAIL: gcc.target/i386/pr71652-3.c (internal compiler error)
>> FAIL: gcc.target/i386/pr71652-3.c (test for errors, line 5)
>> FAIL: gcc.target/i386/pr71652-3.c (test for excess errors)
>
> I wonder why patch submitter didn't get these failures during
> regtesting. There are plenty of tests (the above multi-vrsioning
> tests) that depend on correct handling of ISA variables. I assumed
> that these tests passed and consequently didn't went deep into the
> implementation, but rather requested a couple of additional tests that
> exercised added functionality.some more.
Completely my bad. Starting from addition last intrinsics testing gone wrong.
Will double check next time to avoid repeating in the future.
>> Will debug even those.
Thank you, Jakub.
Re: PR69741: Bad error in formal with array scalar loop counters
Hi Steve, all,
On 11/19/16 02:18, Steve Kargl wrote:
> The error message is still not clear. 42 is a scalar integer. Why
> not use the language in the standard?
>
> C739 (R753) The index-name shall be a named scalar variable of type integer.
I had adjusted the error message to the same appearing in resolve.c
in another place, but you are absolutely right. The attached patch
takes this into account. The testcase is derived from the PR.
>>
>> Whoever wants to take this one.
>>
>
> Ever thought about getting a commit bit and getting more involved
> in gfortran development? I know 4 or 5 other gentlemen that would
> welcome you with open arms.
>
Thanks.
During the stabilization phase of gcc-6 I tried to understand more
of the internals of gfortran. However, most of the time I just got
lost. I therefore decided to tackle a few simple things.
I don't have the resources to follow the development continuously,
especially when there are changes to ABI or module format. So it
makes more sense for me to wait till the dust settles.
I'll try to find some time during the current stage 3 to check
whether there are regressions affecting my codes, but no promises.
Harald
2016-11-19 Harald Anlauf
PR fortran/69741
* resolve.c (gfc_resolve_forall): Check for non-scalar index
variables.
2016-11-19 Harald Anlauf
PR fortran/69741
* gfortran.dg/forall_18.f90: New testcase.
Index: gfortran.dg/forall_18.f90
===
--- gfortran.dg/forall_18.f90 (revision 0)
+++ gfortran.dg/forall_18.f90 (revision 0)
@@ -0,0 +1,12 @@
+! { dg-do compile }
+! PR 69741 - improve error message for non-scalar FORALL index variables
+!
+subroutine check
+ integer :: ii(2), i, j
+ real :: a(3,2)
+
+ forall (ii(1)=1:3, ii(2)=1:2) ! { dg-error "scalar variable of type
integer" }
+ a(ii(1),ii(2)) = ii(1) * ii(2)
+ end forall
+
+end subroutine check
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c (revision 242607)
+++ gcc/fortran/resolve.c (working copy)
@@ -9668,6 +9668,13 @@
and stride. The FORALL index can not appear in start, end or stride. */
for (fa = code->ext.forall_iterator; fa; fa = fa->next)
{
+ if (fa->var->ref && fa->var->ref->type == REF_ARRAY)
+ {
+ gfc_error ("FORALL index-name at %L must be a scalar variable "
+ "of type integer", &fa->var->where);
+ continue;
+ }
+
/* Check if any outer FORALL index name is the same as the current
one. */
for (i = 0; i < nvar; i++)
Re: PR69741: Bad error in formal with array scalar loop counters
Sorry, forgot to mention: regtested on i686-pc-linux-gnu
Harald
On 11/19/16 15:42, Harald Anlauf wrote:
> Hi Steve, all,
>
> On 11/19/16 02:18, Steve Kargl wrote:
>> The error message is still not clear. 42 is a scalar integer. Why
>> not use the language in the standard?
>>
>> C739 (R753) The index-name shall be a named scalar variable of type integer.
>
> I had adjusted the error message to the same appearing in resolve.c
> in another place, but you are absolutely right. The attached patch
> takes this into account. The testcase is derived from the PR.
>
>>>
>>> Whoever wants to take this one.
>>>
>>
>> Ever thought about getting a commit bit and getting more involved
>> in gfortran development? I know 4 or 5 other gentlemen that would
>> welcome you with open arms.
>>
>
> Thanks.
>
> During the stabilization phase of gcc-6 I tried to understand more
> of the internals of gfortran. However, most of the time I just got
> lost. I therefore decided to tackle a few simple things.
>
> I don't have the resources to follow the development continuously,
> especially when there are changes to ABI or module format. So it
> makes more sense for me to wait till the dust settles.
>
> I'll try to find some time during the current stage 3 to check
> whether there are regressions affecting my codes, but no promises.
>
> Harald
>
>
> 2016-11-19 Harald Anlauf
>
> PR fortran/69741
> * resolve.c (gfc_resolve_forall): Check for non-scalar index
> variables.
>
> 2016-11-19 Harald Anlauf
>
> PR fortran/69741
> * gfortran.dg/forall_18.f90: New testcase.
>
> Index: gfortran.dg/forall_18.f90
> ===
> --- gfortran.dg/forall_18.f90 (revision 0)
> +++ gfortran.dg/forall_18.f90 (revision 0)
> @@ -0,0 +1,12 @@
> +! { dg-do compile }
> +! PR 69741 - improve error message for non-scalar FORALL index variables
> +!
> +subroutine check
> + integer :: ii(2), i, j
> + real :: a(3,2)
> +
> + forall (ii(1)=1:3, ii(2)=1:2) ! { dg-error "scalar variable of type
> integer" }
> + a(ii(1),ii(2)) = ii(1) * ii(2)
> + end forall
> +
> +end subroutine check
>
--
Harald Anlauf
Dieburger Str. 17
60386 Frankfurt
Tel.: (069) 4014 8318
Re: [PATCH, Fortran, pr78395, v1] [OOP] error on polymorphic assignment
Hi Andre, > When checking the shortened example in comment #3 one gets a segfault, because > v6 is not allocated explicitly. The initial example made sure, that v6 was > allocated. sorry, I guess that's my fault. I blindly removed the allocate statement when looking for a reduced test case for the compile-time error. > Btw, when using the in gcc-7 available > polymorphic assign, then v6 is actually auto-allocated and the program runs > fine. So what are your opinions on the auto-allocation issue? I suspect that auto-allocation does not apply to defined assignment, but I'm not fully sure. Looking in the F08 standard, it seems to be mentioned in 7.2.1.3, but not in 7.2.1.4. As Thomas mentioned, you could take that question to c.l.f. to get a more qualified answer and/or open a follow-up PR for it. > This patch fixes the wrong error messages in both gcc-7 and gcc-6. > Bootstraped and regtested on x86_64-linux/F23 for gcc-7 and -6. Ok for trunk > and gcc-6? Yes, looks good to me (at least for trunk; gcc-6 if you like). Thanks for the patch, Janus
Re: [PATCH] Enable Intel AVX512_4FMAPS and AVX512_4VNNIW instructions
On Sat, Nov 19, 2016 at 12:28:22PM +0100, Jakub Jelinek wrote: > On x86_64-linux with the 3 patches I'm not seeing any new FAILs > compared to before r242569, on i686-linux there is still: > +FAIL: gcc.target/i386/pr57756.c (test for errors, line 6) > +FAIL: gcc.target/i386/pr57756.c (test for warnings, line 14) > compared to pre-r242569 (so some further fix is needed). And finally here is yet another patch that fixes pr57756 on i686-linux. Ok for trunk together with the other 3 patches? 2016-11-19 Jakub Jelinek * config/i386/i386.c (ix86_can_inline_p): Use || instead of & when checking if callee's isa flags are subset of caller's isa flags. Fix comment wording. --- gcc/config/i386/i386.c.jj 2016-11-19 18:02:56.0 +0100 +++ gcc/config/i386/i386.c 2016-11-19 18:21:23.649463040 +0100 @@ -6981,13 +6981,13 @@ ix86_can_inline_p (tree caller, tree cal struct cl_target_option *caller_opts = TREE_TARGET_OPTION (caller_tree); struct cl_target_option *callee_opts = TREE_TARGET_OPTION (callee_tree); - /* Callee's isa options should a subset of the caller's, i.e. a SSE4 function -can inline a SSE2 function but a SSE2 function can't inline a SSE4 -function. */ + /* Callee's isa options should be a subset of the caller's, i.e. a SSE4 +function can inline a SSE2 function but a SSE2 function can't inline +a SSE4 function. */ if (((caller_opts->x_ix86_isa_flags & callee_opts->x_ix86_isa_flags) - != callee_opts->x_ix86_isa_flags) & - ((caller_opts->x_ix86_isa_flags2 & callee_opts->x_ix86_isa_flags2) - != callee_opts->x_ix86_isa_flags2)) + != callee_opts->x_ix86_isa_flags) + || ((caller_opts->x_ix86_isa_flags2 & callee_opts->x_ix86_isa_flags2) + != callee_opts->x_ix86_isa_flags2)) ret = false; /* See if we have the same non-isa options. */ Jakub
Re: [PATCH] shrink-wrap: New spread_components
Ping.
On Wed, Nov 09, 2016 at 09:46:55PM +, Segher Boessenkool wrote:
> This patch changes spread_components to use a simpler algorithm that
> puts prologue components as early as possible, and epilogue components
> as late as possible. This allows better scheduling, and also saves a
> bit of code size. The blocks that run with some specific component
> enabled after this patch is a strict superset of those that had it
> before the patch.
>
> It does this by finding for every component the basic blocks where that
> component is not needed on some path from the entry block (it reuses
> head_components to store this), and similarly the blocks where the
> component is not needed on some path to the exit block (or the exit can
> not be reached from that block) (stored in tail_components). Blocks
> that then are in neither of those two sets get the component active.
>
> Tested on powerpc64-linux {-m32,-m64}. Is this okay for trunk?
>
>
> Segher
>
>
> 2016-11-09 Segher Boessenkool
>
> * shrink-wrap.c (init_separate_shrink_wrap): Do not clear
> head_components and tail_components.
> (spread_components): New algorithm.
> (emit_common_tails_for_components): Clear head_components and
> tail_components.
> (insert_prologue_epilogue_for_components): Write extra output to the
> dump file for sibcalls and abnormal exits.
>
> ---
> gcc/shrink-wrap.c | 181
> +++---
> 1 file changed, 146 insertions(+), 35 deletions(-)
>
> diff --git a/gcc/shrink-wrap.c b/gcc/shrink-wrap.c
> index 4395d8a..e480d4d 100644
> --- a/gcc/shrink-wrap.c
> +++ b/gcc/shrink-wrap.c
> @@ -1131,8 +1131,6 @@ init_separate_shrink_wrap (sbitmap components)
>SW (bb)->head_components = sbitmap_alloc (SBITMAP_SIZE (components));
>SW (bb)->tail_components = sbitmap_alloc (SBITMAP_SIZE (components));
>bitmap_clear (SW (bb)->has_components);
> - bitmap_clear (SW (bb)->head_components);
> - bitmap_clear (SW (bb)->tail_components);
> }
> }
>
> @@ -1253,48 +1251,151 @@ place_prologue_for_one_component (unsigned int
> which, basic_block head)
> }
> }
>
> -/* Mark HAS_COMPONENTS for every block dominated by at least one block with
> - HAS_COMPONENTS set for the respective components, starting at HEAD. */
> +/* Set HAS_COMPONENTS in every block to the maximum it can be set to without
> + setting it on any path from entry to exit where it was not already set
> + somewhere (or, for blocks that have no path to the exit, consider only
> + paths from the entry to the block itself). */
> static void
> -spread_components (basic_block head)
> +spread_components (sbitmap components)
> {
> - basic_block bb = head;
> - bool first_visit = true;
> - /* This keeps a tally of all components active. */
> - sbitmap components = SW (head)->has_components;
> + basic_block entry_block = ENTRY_BLOCK_PTR_FOR_FN (cfun);
> + basic_block exit_block = EXIT_BLOCK_PTR_FOR_FN (cfun);
>
> - for (;;)
> + /* A stack of all blocks left to consider, and a bitmap of all blocks
> + on that stack. */
> + vec todo;
> + todo.create (n_basic_blocks_for_fn (cfun));
> + bitmap seen = BITMAP_ALLOC (NULL);
> +
> + sbitmap old = sbitmap_alloc (SBITMAP_SIZE (components));
> +
> + /* Find for every block the components that are *not* needed on some path
> + from the entry to that block. Do this with a flood fill from the entry
> + block. Every block can be visited at most as often as the number of
> + components (plus one), and usually much less often. */
> +
> + if (dump_file)
> +fprintf (dump_file, "Spreading down...\n");
> +
> + basic_block bb;
> + FOR_ALL_BB_FN (bb, cfun)
> +bitmap_clear (SW (bb)->head_components);
> +
> + bitmap_copy (SW (entry_block)->head_components, components);
> +
> + edge e;
> + edge_iterator ei;
> +
> + todo.quick_push (single_succ (entry_block));
> + bitmap_set_bit (seen, single_succ (entry_block)->index);
> + while (!todo.is_empty ())
> {
> - if (first_visit)
> - {
> - bitmap_ior (SW (bb)->has_components, SW (bb)->has_components,
> - components);
> + bb = todo.pop ();
>
> - if (first_dom_son (CDI_DOMINATORS, bb))
> - {
> - components = SW (bb)->has_components;
> - bb = first_dom_son (CDI_DOMINATORS, bb);
> - continue;
> - }
> - }
> + bitmap_copy (old, SW (bb)->head_components);
>
> - components = SW (bb)->has_components;
> + FOR_EACH_EDGE (e, ei, bb->preds)
> + bitmap_ior (SW (bb)->head_components, SW (bb)->head_components,
> + SW (e->src)->head_components);
>
> - if (next_dom_son (CDI_DOMINATORS, bb))
> + bitmap_and_compl (SW (bb)->head_components, SW (bb)->head_components,
> + SW (bb)->has_components);
> +
> + if (!bitmap_equal_p (old, SW (bb)->head_components))
> + FOR_EACH_EDGE
[PR target/25111] New patterns for m68k bit insns
This BZ is a request to improve the code we generate for single bit
set/clear/flip on the m68k where the target bit varies *and* is properly
masked to avoid undefined behavior.
I wasn't able to trigger this in GCC or newlib's runtime, but in the
past Kazu was looking at real embedded code, so I'm going to go with the
assumption that's where this request came from.
Tested by building the GCC and newlib runtimes (where it does not
trigger) and the m68k testsuite (where I've added a trivial test).
Installing on the trunk.
Jeff
commit adfa4e7a5d603569c0ab401ec89af574dff04bcf
Author: law
Date: Sat Nov 19 17:52:04 2016 +
PR target/25111
* config/m68k/m68k.md (bsetdreg): New pattern.
(bchgdreg, bclrdreg): Likewise.
PR target/25111
* gcc.target/m68k/pr25111.c: New test.
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@242623
138bc75d-0d04-0410-961f-82ee72b054a4
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index fd09a79..1d560f5 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,9 @@
+2016-11-19 Jeff Law
+
+ PR target/25111
+ * config/m68k/m68k.md (bsetdreg): New pattern.
+ (bchgdreg, bclrdreg): Likewise.
+
2016-11-19 Kaz Kojima
PR target/78426
diff --git a/gcc/config/m68k/m68k.md b/gcc/config/m68k/m68k.md
index 7b7f373..2085619 100644
--- a/gcc/config/m68k/m68k.md
+++ b/gcc/config/m68k/m68k.md
@@ -5336,6 +5336,45 @@
}
[(set_attr "type" "bitrw")])
+(define_insn "*bsetdreg"
+ [(set (match_operand:SI 0 "register_operand" "+d")
+ (ior:SI (ashift:SI (const_int 1)
+ (and:SI (match_operand:SI 1 "register_operand" "d")
+ (const_int 31)))
+ (match_operand:SI 2 "register_operand" "0")))]
+ ""
+{
+ CC_STATUS_INIT;
+ return "bset %1,%0";
+}
+ [(set_attr "type" "bitrw")])
+
+(define_insn "*bchgdreg"
+ [(set (match_operand:SI 0 "register_operand" "+d")
+ (xor:SI (ashift:SI (const_int 1)
+ (and:SI (match_operand:SI 1 "register_operand" "d")
+ (const_int 31)))
+ (match_operand:SI 2 "register_operand" "0")))]
+ ""
+{
+ CC_STATUS_INIT;
+ return "bchg %1,%0";
+}
+ [(set_attr "type" "bitrw")])
+
+(define_insn "*bclrdreg"
+ [(set (match_operand:SI 0 "register_operand" "+d")
+ (and:SI (rotate:SI (const_int -2)
+ (and:SI (match_operand:SI 1 "register_operand" "d")
+ (const_int 31)))
+ (match_operand:SI 2 "register_operand" "0")))]
+ ""
+{
+ CC_STATUS_INIT;
+ return "bclr %1,%0";
+}
+ [(set_attr "type" "bitrw")])
+
;; clear bit, bit number is int
(define_insn "bclrmemqi"
[(set (zero_extract:SI (match_operand:QI 0 "memory_operand" "+m")
diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog
index 50b..41133d8 100644
--- a/gcc/testsuite/ChangeLog
+++ b/gcc/testsuite/ChangeLog
@@ -1,3 +1,8 @@
+2016-11-18 Jeff Law
+
+ PR target/25111
+ * gcc.target/m68k/pr25111.c: New test.
+
2016-11-18 Jakub Jelinek
PR c++/68180
diff --git a/gcc/testsuite/gcc.target/m68k/pr25111.c
b/gcc/testsuite/gcc.target/m68k/pr25111.c
new file mode 100644
index 000..950eeda
--- /dev/null
+++ b/gcc/testsuite/gcc.target/m68k/pr25111.c
@@ -0,0 +1,32 @@
+/* { dg-do compile } */
+/* { dg-options "-O2" } */
+
+/* { dg-final { scan-assembler-times "bset" 1 } } */
+/* { dg-final { scan-assembler-times "bchg" 1 } } */
+/* { dg-final { scan-assembler-times "bclr" 1 } } */
+
+int bar (void);
+
+int
+foo1 (int b)
+{
+ int a = bar ();
+ return ( a | (1 << (b & 31)));
+}
+
+int
+foo2 (int b)
+{
+ int a = bar ();
+ return ( a ^ (1 << (b & 31)));
+}
+
+
+int
+foo3 (int b)
+{
+ int a = bar ();
+ return ( a & ~(1 << (b & 31)));
+}
+
+
[committed] Link various gfortran tests against libatomic when available
The attached change fixes these tests on hppa. We need to link against
libatomic.
Committed to trunk.
Dave
--
John David Anglin dave.ang...@bell.net
2016-11-19 John David Anglin
* gfortran.dg/coarray_alloc_comp_1.f08: Add "-latomic" option if
libatomic_available.
* gfortran.dg/coarray_alloc_comp_2.f08: Likewise.
* gfortran.dg/coarray_allocate_10.f08: Likewise.
* gfortran.dg/coarray_allocate_7.f08: Likewise.
* gfortran.dg/coarray_allocate_8.f08: Likewise.
* gfortran.dg/coarray_allocate_9.f08: Likewise.
* gfortran.dg/coarray_send_by_ref_1.f08: Likewise.
* gfortran.dg/coarray_stat_2.f90: Likewise.
* gfortran.dg/coindexed_1.f90: Likewise.
Index: gfortran.dg/coarray_alloc_comp_1.f08
===
--- gfortran.dg/coarray_alloc_comp_1.f08(revision 242021)
+++ gfortran.dg/coarray_alloc_comp_1.f08(working copy)
@@ -1,5 +1,6 @@
! { dg-do run }
! { dg-options "-fcoarray=lib -lcaf_single" }
+! { dg-additional-options "-latomic" { target libatomic_available } }
! Contributed by Damian Rouson
! Check the new _caf_get_by_ref()-routine.
Index: gfortran.dg/coarray_alloc_comp_2.f08
===
--- gfortran.dg/coarray_alloc_comp_2.f08(revision 242021)
+++ gfortran.dg/coarray_alloc_comp_2.f08(working copy)
@@ -1,5 +1,6 @@
! { dg-do run }
! { dg-options "-fcoarray=lib -lcaf_single" }
+! { dg-additional-options "-latomic" { target libatomic_available } }
! Contributed by Damian Rouson
! Check the new _caf_send_by_ref()-routine.
Index: gfortran.dg/coarray_allocate_10.f08
===
--- gfortran.dg/coarray_allocate_10.f08 (revision 242021)
+++ gfortran.dg/coarray_allocate_10.f08 (working copy)
@@ -1,5 +1,6 @@
! { dg-do run }
! { dg-options "-fcoarray=lib -lcaf_single" }
+! { dg-additional-options "-latomic" { target libatomic_available } }
program alloc_comp
implicit none
Index: gfortran.dg/coarray_allocate_7.f08
===
--- gfortran.dg/coarray_allocate_7.f08 (revision 242021)
+++ gfortran.dg/coarray_allocate_7.f08 (working copy)
@@ -1,5 +1,6 @@
! { dg-do run }
! { dg-options "-fcoarray=lib -lcaf_single -fdump-tree-original" }
+! { dg-additional-options "-latomic" { target libatomic_available } }
! Contributed by Damian Rouson
! Checking whether (de-)registering of coarrays works.
Index: gfortran.dg/coarray_allocate_8.f08
===
--- gfortran.dg/coarray_allocate_8.f08 (revision 242021)
+++ gfortran.dg/coarray_allocate_8.f08 (working copy)
@@ -1,5 +1,6 @@
! { dg-do run }
! { dg-options "-fcoarray=lib -lcaf_single -fdump-tree-original" }
+! { dg-additional-options "-latomic" { target libatomic_available } }
program alloc_comp
implicit none
Index: gfortran.dg/coarray_allocate_9.f08
===
--- gfortran.dg/coarray_allocate_9.f08 (revision 242021)
+++ gfortran.dg/coarray_allocate_9.f08 (working copy)
@@ -1,5 +1,6 @@
! { dg-do run }
! { dg-options "-fcoarray=lib -lcaf_single" }
+! { dg-additional-options "-latomic" { target libatomic_available } }
! Contributed by Damian Rouson
Index: gfortran.dg/coarray_send_by_ref_1.f08
===
--- gfortran.dg/coarray_send_by_ref_1.f08 (revision 242021)
+++ gfortran.dg/coarray_send_by_ref_1.f08 (working copy)
@@ -1,5 +1,6 @@
! { dg-do run }
! { dg-options "-fcoarray=lib -lcaf_single" }
+! { dg-additional-options "-latomic" { target libatomic_available } }
program check_caf_send_by_ref
Index: gfortran.dg/coarray_stat_2.f90
===
--- gfortran.dg/coarray_stat_2.f90 (revision 242021)
+++ gfortran.dg/coarray_stat_2.f90 (working copy)
@@ -1,5 +1,6 @@
! { dg-do run }
! { dg-options "-fcoarray=lib -lcaf_single" }
+! { dg-additional-options "-latomic" { target libatomic_available } }
!
! Support for stat= in caf reference
!
Index: gfortran.dg/coindexed_1.f90
===
--- gfortran.dg/coindexed_1.f90 (revision 242021)
+++ gfortran.dg/coindexed_1.f90 (working copy)
@@ -1,5 +1,6 @@
! { dg-do run }
! { dg-options "-fcoarray=lib -lcaf_single" }
+! { dg-additional-options "-latomic" { target libatomic_available } }
!
! Contributed by Reinhold Bader
!
Re: [PATCH] Enable Intel AVX512_4FMAPS and AVX512_4VNNIW instructions
On Sat, Nov 19, 2016 at 6:24 PM, Jakub Jelinek wrote: > On Sat, Nov 19, 2016 at 12:28:22PM +0100, Jakub Jelinek wrote: >> On x86_64-linux with the 3 patches I'm not seeing any new FAILs >> compared to before r242569, on i686-linux there is still: >> +FAIL: gcc.target/i386/pr57756.c (test for errors, line 6) >> +FAIL: gcc.target/i386/pr57756.c (test for warnings, line 14) >> compared to pre-r242569 (so some further fix is needed). > > And finally here is yet another patch that fixes pr57756 on i686-linux. > Ok for trunk together with the other 3 patches? OK for the whole patch series. Big thanks, Uros. > > 2016-11-19 Jakub Jelinek > > * config/i386/i386.c (ix86_can_inline_p): Use || instead of & > when checking if callee's isa flags are subset of caller's isa flags. > Fix comment wording. > > --- gcc/config/i386/i386.c.jj 2016-11-19 18:02:56.0 +0100 > +++ gcc/config/i386/i386.c 2016-11-19 18:21:23.649463040 +0100 > @@ -6981,13 +6981,13 @@ ix86_can_inline_p (tree caller, tree cal >struct cl_target_option *caller_opts = TREE_TARGET_OPTION > (caller_tree); >struct cl_target_option *callee_opts = TREE_TARGET_OPTION > (callee_tree); > > - /* Callee's isa options should a subset of the caller's, i.e. a SSE4 > function > -can inline a SSE2 function but a SSE2 function can't inline a SSE4 > -function. */ > + /* Callee's isa options should be a subset of the caller's, i.e. a SSE4 > +function can inline a SSE2 function but a SSE2 function can't inline > +a SSE4 function. */ >if (((caller_opts->x_ix86_isa_flags & callee_opts->x_ix86_isa_flags) > - != callee_opts->x_ix86_isa_flags) & > - ((caller_opts->x_ix86_isa_flags2 & callee_opts->x_ix86_isa_flags2) > - != callee_opts->x_ix86_isa_flags2)) > + != callee_opts->x_ix86_isa_flags) > + || ((caller_opts->x_ix86_isa_flags2 & > callee_opts->x_ix86_isa_flags2) > + != callee_opts->x_ix86_isa_flags2)) > ret = false; > >/* See if we have the same non-isa options. */ > > > Jakub
Re: [PATCH] libgcc/mkmap-symver: support skip_underscore (PR74748)
On 11/19/2016 02:45 AM, Thomas Petazzoni wrote: All symbols in Blackfin are prepended with an underscore, so we're pretty much guaranteed there is one, and we precisely want to get rid of this prepended underscore. So I'd say it's good enough to get rid of the first character, without checking if it's an underscore or not. Of course, if you think we really want to be extra safe and only remove it after making sure it's an underscore, I can probably improve the awk logic to handle this. Let's be extra safe -- skip_underscore, in my mind, implies that it's only going to skip an underscore. Jeff
Re: [PATCH v3] bb-reorder: Improve compgotos pass (PR71785)
On Nov 17 2016, Segher Boessenkool wrote:
> PR rtl-optimization/71785
> * bb-reorder.c (maybe_duplicate_computed_goto): New function.
> (duplicate_computed_gotos): New function.
> (pass_duplicate_computed_gotos::execute): Rewrite.
This breaks gcc.c-torture/execute/comp-goto-1.c execution test with -O2
-flto on ia64 and m68k. The label sim_base_addr has been placed after
the L_LOAD32_RR and L_METAOP_DONE labels, so that
op_map[program[i].f1.offset] - base_addr becomes negative. That can be
fixed by making .offset a signed bitfield. Installed as obvious.
Andreas.
* gcc.c-torture/execute/comp-goto-1.c (insn_t): Change offset to
signed int.
diff --git a/gcc/testsuite/gcc.c-torture/execute/comp-goto-1.c
b/gcc/testsuite/gcc.c-torture/execute/comp-goto-1.c
index 3bf9a26f65..4c41b71c34 100644
--- a/gcc/testsuite/gcc.c-torture/execute/comp-goto-1.c
+++ b/gcc/testsuite/gcc.c-torture/execute/comp-goto-1.c
@@ -14,7 +14,7 @@ typedef union
{
struct
{
- unsigned int offset:18;
+ signed int offset:18;
unsigned int ignore:4;
unsigned int s1:8;
int :2;
--
2.10.2
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Re: [RFC PATCH] avoid printing type suffix with %E (PR c/78165)
On 10/26/2016 02:46 PM, Joseph Myers wrote:
On Wed, 26 Oct 2016, Martin Sebor wrote:
The attached patch implements one such approach by having the pretty
printer recognize the space format flag to suppress the type suffix,
so "%E" still prints the suffix but "% E" does not. I did this to
preserve the existing output but I think it would be nicer to avoid
printing the suffix with %E and treat (for instance) the pound sign
as a request to add the suffix. I have tested the attached patch
but not the alternative.
I think printing the suffixes is a relic of %E being used to print full
expressions.
It's established by now that printing expressions reconstructed from trees
is a bad idea; we can get better results by having precise location ranges
and underlining the relevant part of the source. So if we could make sure
nowhere is trying the use %E (or %qE, etc.) with expressions that might
not be constants, where the type might be relevant, then we'd have
confidence that stopping printing the suffix is safe. But given the low
quality of the reconstructed expressions, it's probably safe anyway.
(Most %qE uses are for identifiers not expressions. If we give
identifiers a different static type from "tree" - and certainly there
isn't much reason for them to have the same type as expressions - then
we'll need to change the format for either identifiers or expressions.)
Attached is a trivial patch to remove the suffix. I didn't see
any failures in the test suite as a result. I didn't attempt to
remove the type suffix from any tests (nor did my relatively
superficial search find any) but it will help simplify the tests
for my patches that are still in the review queue.
I should add to the rationale for the change I gave in my reply
to Jeff:
https://gcc.gnu.org/ml/gcc-patches/2016-11/msg01692.html
that the print_dec[su] function that's sometimes used to format
integers in warning messages (e.g., by the -Walloca-larger-than
pass) doesn't add the suffix because it doesn't have knowledge
of the argument's type (it operates on wide_int). That further
adds to the inconsistency in diagnostics. This patch makes all
integers in diagnostics consistent regardless of their type.
Thanks
Martin
PR c/78165 - avoid printing type suffix for constants in %E output
gcc/c-family/ChangeLog:
PR c/78165
* c-pretty-print (pp_c_integer_constant): Avoid formatting type
suffix.
diff --git a/gcc/c-family/c-pretty-print.c b/gcc/c-family/c-pretty-print.c
index 7ad5900..c32d0a0 100644
--- a/gcc/c-family/c-pretty-print.c
+++ b/gcc/c-family/c-pretty-print.c
@@ -904,15 +904,6 @@ pp_c_void_constant (c_pretty_printer *pp)
static void
pp_c_integer_constant (c_pretty_printer *pp, tree i)
{
- int idx;
-
- /* We are going to compare the type of I to other types using
- pointer comparison so we need to use its canonical type. */
- tree type =
-TYPE_CANONICAL (TREE_TYPE (i))
-? TYPE_CANONICAL (TREE_TYPE (i))
-: TREE_TYPE (i);
-
if (tree_fits_shwi_p (i))
pp_wide_integer (pp, tree_to_shwi (i));
else if (tree_fits_uhwi_p (i))
@@ -929,24 +920,6 @@ pp_c_integer_constant (c_pretty_printer *pp, tree i)
print_hex (wi, pp_buffer (pp)->digit_buffer);
pp_string (pp, pp_buffer (pp)->digit_buffer);
}
- if (TYPE_UNSIGNED (type))
-pp_character (pp, 'u');
- if (type == long_integer_type_node || type == long_unsigned_type_node)
-pp_character (pp, 'l');
- else if (type == long_long_integer_type_node
- || type == long_long_unsigned_type_node)
-pp_string (pp, "ll");
- else for (idx = 0; idx < NUM_INT_N_ENTS; idx ++)
-if (int_n_enabled_p[idx])
- {
- char buf[2+20];
- if (type == int_n_trees[idx].signed_type
- || type == int_n_trees[idx].unsigned_type)
- {
- sprintf (buf, "I%d", int_n_data[idx].bitsize);
- pp_string (pp, buf);
- }
- }
}
/* Print out a CHARACTER literal. */
Re: Ping: Re: [PATCH 1/2] gcc: Remove unneeded global flag.
* Christophe Lyon [2016-11-18 13:21:50 +0100]:
> On 16 November 2016 at 23:12, Andrew Burgess
> wrote:
> > * Mike Stump [2016-11-16 12:59:53 -0800]:
> >
> >> On Nov 16, 2016, at 12:09 PM, Andrew Burgess
> >> wrote:
> >> > My only remaining concern is the new tests, I've tried to restrict
> >> > them to targets that I suspect they'll pass on with:
> >> >
> >> >/* { dg-final-use { scan-assembler "\.section\[\t
> >> > \]*\.text\.unlikely\[\\n\\r\]+\[\t \]*\.size\[\t \]*foo\.cold\.0" {
> >> > target *-*-linux* *-*-gnu* } } } */
> >> >
> >> > but I'm still nervous that I'm going to introduce test failures. Is
> >> > there any advice / guidance I should follow before I commit, or are
> >> > folk pretty relaxed so long as I've made a reasonable effort?
> >>
> >> So, if you are worried about the way the line is constructed, I usually
> >> test it by misspelling the *-*-linux* *-*-gnu* part as *-*-linNOTux*
> >> *-*-gnNOTu* and see if the test then doesn't run on your machine. If it
> >> doesn't then you can be pretty confident that only machines that match the
> >> target triplet can be impacted. I usually do this type of testing by
> >> running the test case in isolation (not the full tests suite). Anyway, do
> >> the best you can, and don't worry about t it too much, learn from the
> >> experience, even if it goes wrong in some way. If it did go wrong, just
> >> be responsive (don't check it in just before a 6 week vacation) about
> >> fixing it, if you can.
> >>
> >
> > Thanks for the feedback.
> >
> > Change committed as revision 242519. If anyone sees any issues just
> > let me know.
> >
>
> Hi Andrew,
>
> Sorry for the delay, there are so many commits these days, with so
> many regression
> reports to check manually before reporting here
>
> So, your new test fails on arm* targets:
After a little digging I think the problem might be that
-freorder-blocks-and-partition is not supported on arm.
This should be detected as the new tests include:
/* { dg-require-effective-target freorder } */
however this test passed on arm as -freorder-blocks-and-partition does
not issue any warning unless -fprofile-use is also passed.
The patch below extends check_effective_target_freorder to check using
-fprofile-use. With this change in place the tests are skipped on
arm.
All feedback welcome,
Thanks,
Andrew
---
arm/gcc: Tighten checks in check_effective_target_freorder
In check_effective_target_freorder we check to see if the target
supports -freorder-blocks-and-partition. However we disable
-freorder-blocks-and-partition when -fprofile-use is not supplied so
for some targets we'll not see any message about lack of support for
-freorder-blocks-and-partition unless -fprofile-use is also passed.
This commit extends check_effective_target_freorder to first try
-freorder-blocks-and-partition on its own, then try -fprofile-use and
-freorder-blocks-and-partition.
gcc/testsuite/ChangeLog:
* lib/target-supports.exp (check_effective_target_freorder): Check
additional case.
---
gcc/testsuite/ChangeLog | 5 +
gcc/testsuite/lib/target-supports.exp | 8 +++-
2 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/gcc/testsuite/lib/target-supports.exp
b/gcc/testsuite/lib/target-supports.exp
index 8a2abd2..0716792 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -1014,9 +1014,15 @@ proc check_effective_target_fstack_protector {} {
# for trivial code, 0 otherwise.
proc check_effective_target_freorder {} {
-return [check_no_compiler_messages freorder object {
+if { [check_no_compiler_messages freorder object {
void foo (void) { }
} "-freorder-blocks-and-partition"]
+&& [check_no_compiler_messages fprofile_use_freorder object {
+ void foo (void) { }
+} "-fprofile-use -freorder-blocks-and-partition"] } {
+ return 1
+}
+return 0
}
# Return 1 if -fpic and -fPIC are supported, as in no warnings or errors
--
2.6.4
Re: [PATCH] avoid calling alloca(0)
So far I thought the warning is trying to make no differences between malloc, realloc and alloca. I would say that using realloc(x,0) is for sure always wrong. Nobody will object against a warning for that. Thanks for calling out the realloc(0, p) case! Realloc(0, p) is impossible to use portably and has been deprecated in C11 in response to defect report 400: http://www.open-std.org/jtc1/sc22/wg14/www/docs/summary.htm#dr_400 This change will be published in the 2017 technical corrigendum to the C11 standard. And yes, malloc(0) is unportable, but if the result is not used and directly fed into free that should be no problem, but a warning would be also helpful because it is unportable code. But I hope that it is not the same as with the false positive array bounds warnings where the compiler first transforms the source code into something completely different and then starts to warn about it. I'm not aware of any such transformation or false positives due to it but if you have more details or a test case I'll verify that it doesn't trip it up. Regarding alloca, there are probably three different forms. First a function that is not a builtin but has the name "alloca" like special_function_p understands it. It has no attributes unless the header mentions them. Calling this function with 0 should not be warned about, right? Right. (I assume this means -fno-builtin-alloca or its equivalent such as -ffreestanding; otherwise GCC mostly treats "alloca" the same as "__builtin_alloca", with the exception of special_function_p). Then a function that has the name "alloca" and matches the signature of the builtin "alloca" function. Right. (This means that -fbuiltin-alloca is set (i.e., without an explicit -fno-builtin-alloca, -fno-builtin, or -ffreestanding). And last a function that has the name "__builtin_alloca". Right. (Either a direct call to it or as a result of macro expansion like in Glibc .) You can distinguish between these, and possibly only warn for __builtin_alloca? Note, that will depend on the way the glibc header works. Yes, it's possible to distinguish these cases. The last patch I posted doesn't warn on case (1) when -fno-builtin-alloca is set because then the function code isn't BUILT_IN_ALLOCA. It does warn on case (2) because it only looks at the function code. I offered to make it not warn on case (2) to help avoid changing calls to it from alloca(n) to alloca(n + !n) when n is determined to be zero by constant propagation. Everything would be more easy if the glibc header would not do that, and just use the alloca and no macro. Then it would be more natural to warn about alloca and not about __builtin_alloca, because that is always implemented in a sensible way. But even if the __builtin_alloca is called with 0, what do we do with the result? I mean any use of the value would be wrong. So why is there a warning, when the value is not used? As best I can tell the result isn't actually used (the code that uses the result gets branched over). GCC just doesn't see it. I verified this by changing the XALLOCAVEC macro to #define XALLOCAVEC(T, N) (N ? alloca (sizeof (T) * N) : 0) and bootstrapping and running the regression test suite with no apparent regressions. If you or others are concerned about the rate of false positives of this warning please point me at a code base that might be a good test bed to to try it on. Besides GCC I've built Binutils and the Linux kernel with just the 5 instances in GCC. you should also include glibc and busybox, to be sure. Thanks for the suggestion. I've done that and found no instances of any of these warnings in either Busybox 1.25.1 or Glibc trunk. Martin
Re: [PATCH] warn on overflow in calls to allocation functions (bugs 77531 and 78284)
The attached update is an attempt to incorporate the feedback I received last week during the discussion of the prerequisite patch to avoid calling alloca(0). The important changes are: 1) Add attribute returns_nonnull to __builtin_alloca. 2) Prevent calls to alloca(0) from triggering the -Walloc-zero warning when the call is to the function named alloca (as opposed to one made explicitly to __builtin_alloca). I don't think this special treatment is necessary but a concern was voiced that short of disabling the warning altogether there was no way to suppress the warning for individual calls to alloca without adding 1 to the size, and that the addition might adversely affect performance. 3) Fix a bug in the handling of certain calls to calloc(a, b) with signed arguments. Besides bootstrapping GCC and running the test suite I tested this patch by compiling Binutils 2.27, Busybox 1.25.1, the trunk of Glibc, and the Linux kernel with no instances of either of the new warnings. (GCC requires the alloca(0) patch to fix the -Walloc-zero warnings.) Since there has been quite a bit of discussion in response to the related and prerequisite alloca(0) patch for GCC let me summarize the rationale for this patch and the two new warnings it adds: 1) -Walloc-larger-than=max (enabled by default with SIZE_MAX / 2) Calls to calloc(a, b) where the product (a * b) overflows are a source of bugs. calloc is expected to fail in this case but implementations have been known to get this wrong. See [1]. Calls to allocation functions such as malloc with a very large argument can be the result of an incorrect computation or conversion from a negative argument, or integer overflow. Such calls normally fail at runtime but malloc error handling is often poorly exercised and the error handling code buggy. Detecting these early helps avoid these problems. 2) -Walloc-zero (enabled with -Wextra) Zero allocations are a notorious source bugs and security vulnerabilities, not only because the result of such calls is implementation-defined (some return null, others a non-null pointer to a zero-sized object), but also because such calls are sometimes the result of integer overflow. See [2]. In addition, C11 has deprecated calling realloc(0, p) in response to defect report 400 [3]. Finally, calling alloca(0) is dangerous because like malloc(0), the result may be either null or non-null, but unlike malloc, when non-null, the pointer need not be distinct from others. This warning is analogous to the Clang static analyzer warning for zero-size allocation calls. [1] RUS-CERT Advisory 2002-08:02 – Flaw in calloc and similar routines https://cert.uni-stuttgart.de/ticker/advisories/calloc.html [2] Zero-sized heap allocations vulnerability analysis https://www.usenix.org/legacy/event/woot10/tech/full_papers/Vanegue.pdf [3] DR 400 - realloc with size zero problems http://www.open-std.org/jtc1/sc22/wg14/www/docs/summary.htm#dr_400 On 11/17/2016 05:15 PM, Martin Sebor wrote: Attached is an update to the patch that avoids duplicating the -Walloca-larger-than warnings. This version also avoids warning for calls with zero allocation size to functions declared with the returns_nonnull attribute (like libiberty's xmalloc). Since such functions cannot return null there's no portability issue to worry/warn about. When applied along with the patch to avoid calling alloca(0) in GCC posted earlier today (link below) this version bootstraps and passes all tests on x86_64. It also builds Binutils 2.27 and the Linux kernel with no new warnings. https://gcc.gnu.org/ml/gcc-patches/2016-11/msg01838.html Martin On 11/16/2016 10:19 AM, Martin Sebor wrote: Attached is an updated version of the patch that also adds attribute alloc_size to the standard allocation built-ins (aligned_alloc, alloca, malloc, calloc, and realloc) and handles alloca. Besides that, I've renamed the option to -Walloc-size-larger-than to make it less similar to -Walloca-larger-than. It think the new name works because the option works with the alloc_size attribute. Other suggestions are of course welcome. I've left the alloc_max_size function in place until I receive some feedback on it. I've regression-tested the patch on x86_64 with a few issues. The biggest is that the -Walloc-zero option enabled by -Wextra causes a number of errors during bootstrap due to invoking the XALLOCAVEC macro with a zero argument. The errors look valid to me (and I got past them by temporarily changing the XALLOCAVEC macro to always allocate at least one byte) but I haven't fixed the errors yet. I'll post a separate patch for those. The other open issue is that the new warning duplicates a small subset of the -Walloca-larger-than warnings. I expect removing the duplicates to be straightforward. I post this updated patch for review while I work on the remaining issues. Martin On 11/13/2016 08:19 PM
Re: [PATCH] avoid calling alloca(0)
On Sat, Nov 19, 2016 at 04:43:29PM -0700, Martin Sebor wrote:
> Thanks for calling out the realloc(0, p) case! Realloc(0, p) is
?? The DR you refer to deprecates realloc(p, 0), not realloc(0, p).
The latter is used much more widely, e.g. by not special casing
the first allocation. So you use
void *p = NULL;
for (...)
{
void *q = realloc (p, sz);
if (q == NULL)
whatever;
p = q;
...
}
Jakub
