[PATCH] Handle __builtin_bswap{16,32,64} in bitwise ccp (PR tree-optimization/89475)
Hi!
These builtins are perfect candidates for bitwise ccp, the bytes are
preserved, just byte-swapped.
Noticed this while wondering why we haven't optimized the f9 function
in another PR, bswap64 zero extended from 32-bits, later casted to 32-bit
unsigned int is 0.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for GCC10?
2019-02-23 Jakub Jelinek
PR tree-optimization/89475
* tree-ssa-ccp.c (evaluate_stmt): Handle BUILT_IN_BSWAP{16,32,64}
calls.
* gcc.dg/tree-ssa/pr89475.c: New test.
--- gcc/tree-ssa-ccp.c.jj 2019-01-01 12:37:17.078976247 +0100
+++ gcc/tree-ssa-ccp.c 2019-02-23 22:35:23.888343273 +0100
@@ -1960,6 +1960,35 @@ evaluate_stmt (gimple *stmt)
break;
}
+ case BUILT_IN_BSWAP16:
+ case BUILT_IN_BSWAP32:
+ case BUILT_IN_BSWAP64:
+ val = get_value_for_expr (gimple_call_arg (stmt, 0), true);
+ if (val.lattice_val == UNDEFINED)
+ break;
+ else if (val.lattice_val == CONSTANT
+ && val.value
+ && TREE_CODE (val.value) == INTEGER_CST)
+ {
+ tree type = TREE_TYPE (gimple_call_lhs (stmt));
+ int prec = TYPE_PRECISION (type);
+ wide_int wval = wi::to_wide (val.value);
+ val.value
+ = wide_int_to_tree (type,
+ wide_int::from (wval, prec,
+ UNSIGNED).bswap ());
+ val.mask
+ = widest_int::from (wide_int::from (val.mask, prec,
+ UNSIGNED).bswap (),
+ UNSIGNED);
+ if (wi::sext (val.mask, prec) != -1)
+ break;
+ }
+ val.lattice_val = VARYING;
+ val.value = NULL_TREE;
+ val.mask = -1;
+ break;
+
default:;
}
}
--- gcc/testsuite/gcc.dg/tree-ssa/pr89475.c.jj 2019-02-23 18:58:23.035845645
+0100
+++ gcc/testsuite/gcc.dg/tree-ssa/pr89475.c 2019-02-23 18:59:38.462607598
+0100
@@ -0,0 +1,104 @@
+/* PR tree-optimization/89475 */
+/* { dg-do compile { target { ilp32 || lp64 } } } */
+/* { dg-options "-O2 -fdump-tree-optimized" } */
+/* { dg-final { scan-tree-dump-not "link_error " "optimized" } } */
+
+void link_error (void);
+
+unsigned short
+f0 (unsigned short x)
+{
+ x &= 0xaa55;
+ x = __builtin_bswap16 (x);
+ if (x & 0xaa55)
+link_error ();
+ return x;
+}
+
+unsigned short
+f1 (unsigned short x)
+{
+ x &= 0x55aa;
+ x = __builtin_bswap16 (x);
+ if (x & 0x55aa)
+link_error ();
+ return x;
+}
+
+unsigned int
+f2 (unsigned int x)
+{
+ x &= 0x55aa5aa5U;
+ x = __builtin_bswap32 (x);
+ if (x & 0x5aa555aaU)
+link_error ();
+ return x;
+}
+
+unsigned long long int
+f3 (unsigned long long int x)
+{
+ x &= 0x55aa5aa544cc2211ULL;
+ x = __builtin_bswap64 (x);
+ if (x & 0xeedd33bb5aa555aaULL)
+link_error ();
+ return x;
+}
+
+unsigned short
+f4 (unsigned short x)
+{
+ x = __builtin_bswap32 (x);
+ if (x != 0)
+link_error ();
+ return x;
+}
+
+unsigned int
+f5 (unsigned int x)
+{
+ x = __builtin_bswap64 (x);
+ if (x != 0)
+link_error ();
+ return x;
+}
+
+unsigned short
+f6 (unsigned short x)
+{
+ x |= 0xaa55;
+ x = __builtin_bswap16 (x);
+ if ((x | 0xaa55) != 0x)
+link_error ();
+ return x;
+}
+
+unsigned short
+f7 (unsigned short x)
+{
+ x |= 0x55aa;
+ x = __builtin_bswap16 (x);
+ if ((x | 0x55aa) != 0x)
+link_error ();
+ return x;
+}
+
+unsigned int
+f8 (unsigned int x)
+{
+ x |= 0x55aa5aa5U;
+ x = __builtin_bswap32 (x);
+ if ((x | 0x5aa555aaU) != 0xU)
+link_error ();
+ return x;
+}
+
+unsigned long long int
+f9 (unsigned long long int x)
+{
+ x |= 0x55aa5aa544cc2211ULL;
+ x = __builtin_bswap64 (x);
+ if ((x | 0xeedd33bb5aa555aaULL) != 0xULL)
+link_error ();
+ return x;
+}
Jakub
New French PO file for 'gcc' (version 9.1-b20190203)
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: https://translationproject.org/latest/gcc/fr.po (This file, 'gcc-9.1-b20190203.fr.po', has just now been sent to you in a separate email.) All other PO files for your package are available in: https://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: https://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, fortran] Fix PR 89174, segfault on allocate with MOLD
Hello world,
the attached patch fixes a regression where a segfault occured at
runtime for the attached test case. The regression made it out
into the wild with the 8.3 release. Unfortunately, it was discovered too
late before release to do anything about it.
In effect, this patch reverts a part of r265171 for one special case: If
the argument to gfc_find_and_cut_at_last_class_ref is the
MOLD argument to allocate.
Of course, there could also be a more profound way of fixing this
bug :-)
Regression-tested on x86_64-pc-linux-gnu. OK for trunk and gcc-8?
Regards
Thomas
2019-02-24 Thomas Koenig
PR fortran/89174
* trans-expr.c (gfc_find_and_cut_at_last_class_ref): Add is_mold
to garguments. If we are dealing with a MOLD, call
gfc_expr_to_initialize().
* trans-stmt.c (gfc_trans_allocate): For MOLD, pass is_mold=true
to gfc_find_and_cut_at_last_class_ref.
* trans.h (gfc_find_and_cut_at_last_class_ref): Add optional
argument is_mold with default false.
2019-02-24 Thomas Koenig
PR fortran/89174
* gfortran.dg/allocate_with_mold_3.f90: New test.
Index: trans-expr.c
===
--- trans-expr.c (Revision 269161)
+++ trans-expr.c (Arbeitskopie)
@@ -352,7 +352,7 @@ gfc_vptr_size_get (tree vptr)
of refs following. */
gfc_expr *
-gfc_find_and_cut_at_last_class_ref (gfc_expr *e)
+gfc_find_and_cut_at_last_class_ref (gfc_expr *e, bool is_mold)
{
gfc_expr *base_expr;
gfc_ref *ref, *class_ref, *tail = NULL, *array_ref;
@@ -394,7 +394,10 @@ gfc_expr *
e->ref = NULL;
}
- base_expr = gfc_copy_expr (e);
+ if (is_mold)
+base_expr = gfc_expr_to_initialize (e);
+ else
+base_expr = gfc_copy_expr (e);
/* Restore the original tail expression. */
if (class_ref)
Index: trans-stmt.c
===
--- trans-stmt.c (Revision 269161)
+++ trans-stmt.c (Arbeitskopie)
@@ -6641,7 +6641,7 @@ gfc_trans_allocate (gfc_code * code)
/* Use class_init_assign to initialize expr. */
gfc_code *ini;
ini = gfc_get_code (EXEC_INIT_ASSIGN);
- ini->expr1 = gfc_find_and_cut_at_last_class_ref (expr);
+ ini->expr1 = gfc_find_and_cut_at_last_class_ref (expr, true);
tmp = gfc_trans_class_init_assign (ini);
gfc_free_statements (ini);
gfc_add_expr_to_block (&block, tmp);
Index: trans.h
===
--- trans.h (Revision 269161)
+++ trans.h (Arbeitskopie)
@@ -412,7 +412,7 @@ tree gfc_class_data_get (tree);
tree gfc_class_vptr_get (tree);
tree gfc_class_len_get (tree);
tree gfc_class_len_or_zero_get (tree);
-gfc_expr * gfc_find_and_cut_at_last_class_ref (gfc_expr *);
+gfc_expr * gfc_find_and_cut_at_last_class_ref (gfc_expr *, bool is_mold = false);
/* Get an accessor to the class' vtab's * field, when a class handle is
available. */
tree gfc_class_vtab_hash_get (tree);
! { dg-do run }
! PR fortran/89174 - this used to segfault on execution.
! Test case by Neil Carlson.
module mod
type :: array_data
class(*), allocatable :: mold
contains
procedure :: push
end type
contains
subroutine push(this, value)
class(array_data), intent(inout) :: this
class(*), intent(in) :: value
allocate(this%mold, mold=value) ! <== SEGFAULTS HERE
end subroutine
end module
use mod
type(array_data) :: foo
call foo%push(42)
end
Re: [PATCH] Handle __builtin_bswap{16,32,64} in bitwise ccp (PR tree-optimization/89475)
On February 24, 2019 12:58:05 PM GMT+01:00, Jakub Jelinek
wrote:
>Hi!
>
>These builtins are perfect candidates for bitwise ccp, the bytes are
>preserved, just byte-swapped.
>
>Noticed this while wondering why we haven't optimized the f9 function
>in another PR, bswap64 zero extended from 32-bits, later casted to
>32-bit
>unsigned int is 0.
>
>Bootstrapped/regtested on x86_64-linux and i686-linux, ok for GCC10?
OK.
Richard.
>2019-02-23 Jakub Jelinek
>
> PR tree-optimization/89475
> * tree-ssa-ccp.c (evaluate_stmt): Handle BUILT_IN_BSWAP{16,32,64}
> calls.
>
> * gcc.dg/tree-ssa/pr89475.c: New test.
>
>--- gcc/tree-ssa-ccp.c.jj 2019-01-01 12:37:17.078976247 +0100
>+++ gcc/tree-ssa-ccp.c 2019-02-23 22:35:23.888343273 +0100
>@@ -1960,6 +1960,35 @@ evaluate_stmt (gimple *stmt)
> break;
> }
>
>+ case BUILT_IN_BSWAP16:
>+ case BUILT_IN_BSWAP32:
>+ case BUILT_IN_BSWAP64:
>+val = get_value_for_expr (gimple_call_arg (stmt, 0), true);
>+if (val.lattice_val == UNDEFINED)
>+ break;
>+else if (val.lattice_val == CONSTANT
>+ && val.value
>+ && TREE_CODE (val.value) == INTEGER_CST)
>+ {
>+tree type = TREE_TYPE (gimple_call_lhs (stmt));
>+int prec = TYPE_PRECISION (type);
>+wide_int wval = wi::to_wide (val.value);
>+val.value
>+ = wide_int_to_tree (type,
>+ wide_int::from (wval, prec,
>+ UNSIGNED).bswap ());
>+val.mask
>+ = widest_int::from (wide_int::from (val.mask, prec,
>+ UNSIGNED).bswap (),
>+ UNSIGNED);
>+if (wi::sext (val.mask, prec) != -1)
>+ break;
>+ }
>+val.lattice_val = VARYING;
>+val.value = NULL_TREE;
>+val.mask = -1;
>+break;
>+
> default:;
> }
> }
>--- gcc/testsuite/gcc.dg/tree-ssa/pr89475.c.jj 2019-02-23
>18:58:23.035845645 +0100
>+++ gcc/testsuite/gcc.dg/tree-ssa/pr89475.c2019-02-23
>18:59:38.462607598 +0100
>@@ -0,0 +1,104 @@
>+/* PR tree-optimization/89475 */
>+/* { dg-do compile { target { ilp32 || lp64 } } } */
>+/* { dg-options "-O2 -fdump-tree-optimized" } */
>+/* { dg-final { scan-tree-dump-not "link_error " "optimized" } } */
>+
>+void link_error (void);
>+
>+unsigned short
>+f0 (unsigned short x)
>+{
>+ x &= 0xaa55;
>+ x = __builtin_bswap16 (x);
>+ if (x & 0xaa55)
>+link_error ();
>+ return x;
>+}
>+
>+unsigned short
>+f1 (unsigned short x)
>+{
>+ x &= 0x55aa;
>+ x = __builtin_bswap16 (x);
>+ if (x & 0x55aa)
>+link_error ();
>+ return x;
>+}
>+
>+unsigned int
>+f2 (unsigned int x)
>+{
>+ x &= 0x55aa5aa5U;
>+ x = __builtin_bswap32 (x);
>+ if (x & 0x5aa555aaU)
>+link_error ();
>+ return x;
>+}
>+
>+unsigned long long int
>+f3 (unsigned long long int x)
>+{
>+ x &= 0x55aa5aa544cc2211ULL;
>+ x = __builtin_bswap64 (x);
>+ if (x & 0xeedd33bb5aa555aaULL)
>+link_error ();
>+ return x;
>+}
>+
>+unsigned short
>+f4 (unsigned short x)
>+{
>+ x = __builtin_bswap32 (x);
>+ if (x != 0)
>+link_error ();
>+ return x;
>+}
>+
>+unsigned int
>+f5 (unsigned int x)
>+{
>+ x = __builtin_bswap64 (x);
>+ if (x != 0)
>+link_error ();
>+ return x;
>+}
>+
>+unsigned short
>+f6 (unsigned short x)
>+{
>+ x |= 0xaa55;
>+ x = __builtin_bswap16 (x);
>+ if ((x | 0xaa55) != 0x)
>+link_error ();
>+ return x;
>+}
>+
>+unsigned short
>+f7 (unsigned short x)
>+{
>+ x |= 0x55aa;
>+ x = __builtin_bswap16 (x);
>+ if ((x | 0x55aa) != 0x)
>+link_error ();
>+ return x;
>+}
>+
>+unsigned int
>+f8 (unsigned int x)
>+{
>+ x |= 0x55aa5aa5U;
>+ x = __builtin_bswap32 (x);
>+ if ((x | 0x5aa555aaU) != 0xU)
>+link_error ();
>+ return x;
>+}
>+
>+unsigned long long int
>+f9 (unsigned long long int x)
>+{
>+ x |= 0x55aa5aa544cc2211ULL;
>+ x = __builtin_bswap64 (x);
>+ if ((x | 0xeedd33bb5aa555aaULL) != 0xULL)
>+link_error ();
>+ return x;
>+}
>
> Jakub
[PATCH] Fix arm *subsi3_carryin_{compare_,}const patterns (PR target/89434)
Hi!
As the testcase shows, *subsi3_carryin_{const,compare_const} patterns
don't express in RTL what they are actually doing, which may (on the
testcase) does cause miscompilation if we manage to propagate constants
into it or for other reason simplify-rtx.c etc. tries to simplify them,
or if combiner matches them for how they look like.
The *subsi3_carryin{,_compare} patterns look correct, the reason why the
_const patterns want to be different is that the canonical form of
(minus (reg) (const_int N)) is actually (plus (reg) (const_int -N));
the patterns were actually implementing (plus (reg) (const_int ~N))
which is off-by-one. I had to fix up also two splitters that were
generating these. Finally, (plus (reg) (const_int 0)) is not canonical,
it should be just (reg), but it is pretty widely used case,
so I've added two simpler patterns for those (the const0 ones).
Bootstrapped/regtested on armv7hl-linux-gnueabi, ok for trunk?
2019-02-24 Jakub Jelinek
PR target/89434
* config/arm/arm.md (*subsi3_carryin_const): Use
arm_neg_immediate_operand predicate instead of
arm_not_immediate_operand, "L" constraint instead of "K" and
print it using %n2 instead of %B2.
(*subsi3_carryin_const0): New define_insn.
(*subsi3_carryin_compare_const): Use const_int_I_operand predicate
instead of arm_not_operand and "I" constraint instead of "K" and
print it using %n3 instead of %B2. Instead of using match_dup 2 add
another match_operand and in the condition check that it is negation
of operands[2].
(*subsi3_carryin_compare_const0): New define_ins.
(*subdi_di_zesidi): Adjust to use *subsi3_carryin_const0 instead of
*subsi3_carryin_const.
(*arm_cmpdi_insn): Fix splitting into *subsi3_carryin_compare_const,
split into *subsi3_carryin_compare_const0 if the highpart is zero.
* gcc.c-torture/execute/pr89434.c: New test.
--- gcc/config/arm/arm.md.jj2019-02-22 15:22:16.034999035 +0100
+++ gcc/config/arm/arm.md 2019-02-23 12:10:47.079659675 +0100
@@ -1145,10 +1145,20 @@ (define_insn "*subsi3_carryin"
(define_insn "*subsi3_carryin_const"
[(set (match_operand:SI 0 "s_register_operand" "=r")
(minus:SI (plus:SI (match_operand:SI 1 "s_register_operand" "r")
- (match_operand:SI 2 "arm_not_immediate_operand"
"K"))
+ (match_operand:SI 2 "arm_neg_immediate_operand"
"L"))
(ltu:SI (reg:CC_C CC_REGNUM) (const_int 0]
"TARGET_32BIT"
- "sbc\\t%0, %1, #%B2"
+ "sbc\\t%0, %1, #%n2"
+ [(set_attr "conds" "use")
+ (set_attr "type" "adc_imm")]
+)
+
+(define_insn "*subsi3_carryin_const0"
+ [(set (match_operand:SI 0 "s_register_operand" "=r")
+(minus:SI (match_operand:SI 1 "s_register_operand" "r")
+ (ltu:SI (reg:CC_C CC_REGNUM) (const_int 0]
+ "TARGET_32BIT"
+ "sbc\\t%0, %1, #0"
[(set_attr "conds" "use")
(set_attr "type" "adc_imm")]
)
@@ -1170,13 +1180,26 @@ (define_insn "*subsi3_carryin_compare"
(define_insn "*subsi3_carryin_compare_const"
[(set (reg:CC CC_REGNUM)
(compare:CC (match_operand:SI 1 "reg_or_int_operand" "r")
-(match_operand:SI 2 "arm_not_operand" "K")))
+(match_operand:SI 2 "const_int_I_operand" "I")))
(set (match_operand:SI 0 "s_register_operand" "=r")
(minus:SI (plus:SI (match_dup 1)
- (match_dup 2))
+ (match_operand:SI 3 "arm_neg_immediate_operand"
"L"))
+ (ltu:SI (reg:CC_C CC_REGNUM) (const_int 0]
+ "TARGET_32BIT && UINTVAL (operands[2]) == -UINTVAL (operands[3])"
+ "sbcs\\t%0, %1, #%n3"
+ [(set_attr "conds" "set")
+ (set_attr "type" "adcs_imm")]
+)
+
+(define_insn "*subsi3_carryin_compare_const0"
+ [(set (reg:CC CC_REGNUM)
+(compare:CC (match_operand:SI 1 "reg_or_int_operand" "r")
+ (const_int 0)))
+ (set (match_operand:SI 0 "s_register_operand" "=r")
+(minus:SI (match_dup 1)
(ltu:SI (reg:CC_C CC_REGNUM) (const_int 0]
"TARGET_32BIT"
- "sbcs\\t%0, %1, #%B2"
+ "sbcs\\t%0, %1, #0"
[(set_attr "conds" "set")
(set_attr "type" "adcs_imm")]
)
@@ -1301,14 +1324,13 @@ (define_insn_and_split "*subdi_di_zesidi
[(parallel [(set (reg:CC CC_REGNUM)
(compare:CC (match_dup 1) (match_dup 2)))
(set (match_dup 0) (minus:SI (match_dup 1) (match_dup 2)))])
- (set (match_dup 3) (minus:SI (plus:SI (match_dup 4) (match_dup 5))
+ (set (match_dup 3) (minus:SI (match_dup 4)
(ltu:SI (reg:CC_C CC_REGNUM) (const_int 0]
{
operands[3] = gen_highpart (SImode, operands[0]);
operands[0] = gen_lowpart (SImode, operands[0]);
operands[4] = gen_highpart (SImode, operands[1]);
operands[1] = gen_lowpart (SImode, operands[1]);
-operands[5] = GEN_INT (~0);
}
[(set_attr
[PATCH] PR d/89177 - Fix unaligned access in std.digest.murmurhash
Backport latest murmurhash version from upstream (2.084.1). Ran gdc testsuite
on X86_64 linux and got feedback on the bugzilla this really fixes the issue.
libphobos/ChangeLog:
2019-02-24 Johannes Pfau
* src/std/digest/murmurhash.d: PR d/89177: Backport from upstream.
Fixes unaligned data access (PR d/89177).
---
libphobos/src/std/digest/murmurhash.d | 122 +-
1 file changed, 101 insertions(+), 21 deletions(-)
diff --git a/libphobos/src/std/digest/murmurhash.d
b/libphobos/src/std/digest/murmurhash.d
index 74efed56898..b5b5bc74f98 100644
--- a/libphobos/src/std/digest/murmurhash.d
+++ b/libphobos/src/std/digest/murmurhash.d
@@ -9,7 +9,7 @@ The older MurmurHash 1 and 2 are currently not supported.
MurmurHash3 comes in three flavors, listed in increasing order of throughput:
$(UL
-$(LI $(D MurmurHash3!32) produces a 32-bit value and is optimized for 32-bit
architectures)
+$(LI `MurmurHash3!32` produces a 32-bit value and is optimized for 32-bit
architectures)
$(LI $(D MurmurHash3!(128, 32)) produces a 128-bit value and is optimized for
32-bit architectures)
$(LI $(D MurmurHash3!(128, 64)) produces a 128-bit value and is optimized for
64-bit architectures)
)
@@ -26,7 +26,7 @@ This module conforms to the APIs defined in $(MREF std,
digest).
This module publicly imports $(MREF std, digest) and can be used as a
stand-alone module.
-Source: $(PHOBOSSRC std/digest/_murmurhash.d)
+Source: $(PHOBOSSRC std/digest/murmurhash.d)
License: $(HTTP www.boost.org/LICENSE_1_0.txt, Boost License 1.0).
Authors: Guillaume Chatelet
References: $(LINK2 https://github.com/aappleby/smhasher, Reference
implementation)
@@ -38,6 +38,11 @@ $(BR) $(LINK2 https://en.wikipedia.org/wiki/MurmurHash,
Wikipedia)
*/
module std.digest.murmurhash;
+version (X86)
+version = HaveUnalignedLoads;
+else version (X86_64)
+version = HaveUnalignedLoads;
+
///
@safe unittest
{
@@ -500,28 +505,75 @@ struct MurmurHash3(uint size /* 32 or 128 */ , uint opt =
size_t.sizeof == 8 ? 6
// Buffer should never be full while entering this function.
assert(bufferSize < Element.sizeof);
-// Check if we have some leftover data in the buffer. Then fill the
first block buffer.
+// Check if the incoming data doesn't fill up a whole block buffer.
if (bufferSize + data.length < Element.sizeof)
{
buffer.data[bufferSize .. bufferSize + data.length] = data[];
bufferSize += data.length;
return;
}
-const bufferLeeway = Element.sizeof - bufferSize;
-assert(bufferLeeway <= Element.sizeof);
-buffer.data[bufferSize .. $] = data[0 .. bufferLeeway];
-putElement(buffer.block);
-data = data[bufferLeeway .. $];
+
+// Check if there's some leftover data in the first block buffer, and
+// fill the remaining space first.
+if (bufferSize != 0)
+{
+const bufferLeeway = Element.sizeof - bufferSize;
+buffer.data[bufferSize .. $] = data[0 .. bufferLeeway];
+putElement(buffer.block);
+element_count += Element.sizeof;
+data = data[bufferLeeway .. $];
+}
// Do main work: process chunks of `Element.sizeof` bytes.
const numElements = data.length / Element.sizeof;
const remainderStart = numElements * Element.sizeof;
-foreach (ref const Element block; cast(const(Element[]))(data[0 ..
remainderStart]))
+version (HaveUnalignedLoads)
{
-putElement(block);
+foreach (ref const Element block; cast(const(Element[])) data[0 ..
remainderStart])
+{
+putElement(block);
+}
}
-// +1 for bufferLeeway Element.
-element_count += (numElements + 1) * Element.sizeof;
+else
+{
+void processChunks(T)() @trusted
+{
+alias TChunk = T[Element.sizeof / T.sizeof];
+foreach (ref const chunk; cast(const(TChunk[])) data[0 ..
remainderStart])
+{
+static if (T.alignof >= Element.alignof)
+{
+putElement(*cast(const(Element)*) chunk.ptr);
+}
+else
+{
+Element[1] alignedCopy = void;
+(cast(T[]) alignedCopy)[] = chunk[];
+putElement(alignedCopy[0]);
+}
+}
+}
+
+const startAddress = cast(size_t) data.ptr;
+static if (size >= 64)
+{
+if ((startAddress & 7) == 0)
+{
+processChunks!ulong();
+goto L_end;
+}
+}
+static assert(size >= 32);
+if ((startAddress & 3) == 0)
+proce
Re: [PATCH] libstdc++/89130 and libstdc++/89090 fixes for vector relocation
On 21/02/19 20:47 +, Jonathan Wakely wrote:
On 05/02/19 14:45 +, Jonathan Wakely wrote:
This fixes two PRs, one trivial (don't use C++17 features in C++11
mode) and one more serious (don't require MoveInsertable when we
should only need CopyInsertable).
It would be nice to rely on if-constexpr in C++11 mode, but it causes
clang warnings, complicates testcase bisection/reduction, and causes
users to file bogus bug reports. So let's just avoid it.
Tested powerpc64le-linux, committed to trunk.
commit 51908e56bd32b5f89bc909193c3da957de01c3e0
Author: Jonathan Wakely
Date: Tue Feb 5 11:50:18 2019 +
PR libstdc++/89130 restore support for non-MoveConstructible types
The changes to "relocate" std::vector elements can lead to new errors
outside the immediate context, because moving the elements to new
storage no longer makes use of the move-if-noexcept utilities. This
means that types with deleted moves no longer degenerate to copies, but
are just ill-formed. The errors happen while instantiating the
noexcept-specifier for __relocate_object_a, when deciding whether to try
to relocate.
This patch introduces indirections to avoid the ill-formed
instantiations of std::__relocate_object_a. In order to avoid using
if-constexpr prior to C++17 this is done by tag dispatching. After this
patch all uses of std::__relocate_a are guarded by checks that will
support sensible code (i.e. code not using custom allocators that fool
the new checks).
PR libstdc++/89130
* include/bits/alloc_traits.h (__is_copy_insertable_impl): Rename to
__is_alloc_insertable_impl. Replace single type member with two
members, one for each of copy and move insertable.
(__is_move_insertable): New trait for internal use.
* include/bits/stl_vector.h (vector::_S_nothrow_relocate(true_type))
(vector::_S_nothrow_relocate(true_type)): New functions to
conditionally check if __relocate_a can throw.
(vector::_S_use_relocate()): Dispatch to _S_nothrow_relocate based
on __is_move_insertable.
(vector::_S_do_relocate): New overloaded functions to conditionally
call __relocate_a.
(vector::_S_relocate): New function that dispatches to _S_do_relocate
based on _S_use_relocate.
* include/bits/vector.tcc (vector::reserve, vector::_M_realloc_insert)
(vector::_M_default_append): Call _S_relocate instead of __relocate_a.
* testsuite/23_containers/vector/modifiers/push_back/89130.cc: New.
diff --git a/libstdc++-v3/include/bits/alloc_traits.h
b/libstdc++-v3/include/bits/alloc_traits.h
index ed61ce845f8..3b0c16fbf64 100644
--- a/libstdc++-v3/include/bits/alloc_traits.h
+++ b/libstdc++-v3/include/bits/alloc_traits.h
@@ -577,14 +577,16 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
}
template
-class __is_copy_insertable_impl
+class __is_alloc_insertable_impl
{
- typedef allocator_traits<_Alloc> _Traits;
+ using _Traits = allocator_traits<_Alloc>;
+ using value_type = typename _Traits::value_type;
- template,
+ typename
= decltype(_Traits::construct(std::declval<_Alloc&>(),
-std::declval<_Up*>(),
-std::declval()))>
+std::declval<_Tp*>(),
+std::declval<_Up>()))>
static true_type
_M_select(int);
@@ -593,13 +595,14 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
_M_select(...);
public:
- typedef decltype(_M_select(0)) type;
+ using copy = decltype(_M_select(0));
+ using move = decltype(_M_select(0));
This caused another regression, fixed by the attached patch.
That patch doesn't work with Clang because I made the members
protected and forgot to make them public again (and GCC doesn't cre,
only Clang notices).
Tested powerpc64le-linux, committed to trunk.
commit 6f46cf624c814ea231490bf69afe970acf493543
Author: Jonathan Wakely
Date: Sun Feb 24 15:32:03 2019 +
PR libstdc++/89416 fix accessibility of members
PR libstdc++/89416
* include/bits/alloc_traits.h (__is_alloc_insertable_impl): Make
copy and move members public.
diff --git a/libstdc++-v3/include/bits/alloc_traits.h b/libstdc++-v3/include/bits/alloc_traits.h
index 71892cbfaba..9a3d816c42c 100644
--- a/libstdc++-v3/include/bits/alloc_traits.h
+++ b/libstdc++-v3/include/bits/alloc_traits.h
@@ -590,7 +590,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
static false_type
_M_select(...);
- protected:
+ public:
template
using copy = decltype(_M_select<_Alloc, const _Tp&>(0));
Re: [PATCH] bring netbsd/arm support up to speed. eabi, etc.
Pinging with updated patch.
I removed a conflict with copyright year change. No longer using
unwind-arm (we use dwarf on eabi).
I re-tested cross compilation and resulting C and C++ works (caveat:
with text relocations, i tested small programs)
I believe matt #2 (green) has sent a copyright assignment.
Changelog:
gcc:
config.gcc (arm*-*-netbsdelf*) Add support for EABI configuration
config.host (arm*-*-netbsd*): Build driver-arm.o
config/arm/netbsd-eabi.h: New file.
config/arm/netbsd-elf.h
config/netbsd-elf.h: Define SUBTARGET_EXTRA_SPECS.
libgcc:
config.host (arm*-*-netbsdelf*): Add support for EABI configuration
config/arm/t-netbsd: LIB1ASMFUNCS: Append to existing set.
HOST_LIBGCC2_CFLAGS: workaround possible bug
config/arm/t-netbsd-eabi: New file.
>From c138b94b036e1485ed71c57966894e80f84fea1a Mon Sep 17 00:00:00 2001
From: coypu
Date: Wed, 31 Oct 2018 00:33:06 +0200
Subject: [PATCH 1/1] netbsd eabi
Now with:
armv4 isn't needed as a separate case, because strongarm is the
default for all netbsd. it makes no difference otherwise.
-mfpu=auto
cleaned up things as requested by richard earnshaw.
tested: armv6,7 hf.
---
gcc/config.gcc | 29 +-
gcc/config.host | 2 +-
gcc/config/arm/netbsd-eabi.h| 97 +
gcc/config/arm/netbsd-elf.h | 10
gcc/config/netbsd-elf.h | 15 +
libgcc/config.host | 10 +++-
libgcc/config/arm/t-netbsd | 10 +++-
libgcc/config/arm/t-netbsd-eabi | 18 ++
8 files changed, 184 insertions(+), 7 deletions(-)
create mode 100644 gcc/config/arm/netbsd-eabi.h
create mode 100644 libgcc/config/arm/t-netbsd-eabi
diff --git a/gcc/config.gcc b/gcc/config.gcc
index 3ee31c5993d..736b2163a24 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -1161,10 +1161,33 @@ arm*-*-freebsd*)# ARM FreeBSD EABI
with_tls=${with_tls:-gnu}
;;
arm*-*-netbsdelf*)
- tm_file="dbxelf.h elfos.h ${nbsd_tm_file} arm/elf.h arm/aout.h
${tm_file} arm/netbsd-elf.h"
- extra_options="${extra_options} netbsd.opt netbsd-elf.opt"
- tmake_file="${tmake_file} arm/t-arm"
target_cpu_cname="strongarm"
+ tmake_file="${tmake_file} arm/t-arm"
+ tm_file="dbxelf.h elfos.h ${nbsd_tm_file} arm/elf.h"
+ extra_options="${extra_options} netbsd.opt netbsd-elf.opt"
+ case ${target} in
+ arm*eb-*) tm_defines="${tm_defines} TARGET_BIG_ENDIAN_DEFAULT=1" ;;
+ esac
+ case ${target} in
+ arm*-*-netbsdelf-*eabi*)
+ tm_file="$tm_file arm/bpabi.h arm/netbsd-elf.h arm/netbsd-eabi.h"
+ tmake_file="$tmake_file arm/t-bpabi arm/t-netbsdeabi"
+ ;;
+ *)
+ tm_file="$tm_file arm/netbsd-elf.h"
+ tmake_file="$tmake_file arm/t-netbsd"
+ ;;
+ esac
+ tm_file="${tm_file} arm/aout.h arm/arm.h"
+ case ${target} in
+ arm*-*-netbsdelf-*eabihf*)
+ tm_defines="${tm_defines}
TARGET_DEFAULT_FLOAT_ABI=ARM_FLOAT_ABI_HARD"
+ ;;
+ esac
+ case ${target} in
+ armv6*) target_cpu_cname="arm1176jzf-s";;
+ armv7*) target_cpu_cname="generic-armv7-a";;
+ esac
;;
arm*-*-linux-*)# ARM GNU/Linux with ELF
tm_file="dbxelf.h elfos.h gnu-user.h linux.h linux-android.h
glibc-stdint.h arm/elf.h arm/linux-gas.h arm/linux-elf.h"
diff --git a/gcc/config.host b/gcc/config.host
index 816a0f06cb7..5077c0ee33a 100644
--- a/gcc/config.host
+++ b/gcc/config.host
@@ -107,7 +107,7 @@ case ${host} in
;;
esac
;;
- arm*-*-freebsd* | arm*-*-linux* | arm*-*-fuchsia*)
+ arm*-*-freebsd* | arm*-*-netbsd* | arm*-*-linux* | arm*-*-fuchsia*)
case ${target} in
arm*-*-*)
host_extra_gcc_objs="driver-arm.o"
diff --git a/gcc/config/arm/netbsd-eabi.h b/gcc/config/arm/netbsd-eabi.h
new file mode 100644
index 000..13bc274175d
--- /dev/null
+++ b/gcc/config/arm/netbsd-eabi.h
@@ -0,0 +1,97 @@
+/* Definitions of target machine for GNU compiler, NetBSD/arm ELF version.
+ Copyright (C) 2002, 2003, 2004, 2005, 2007 Free Software Foundation, Inc.
+ Contributed by Wasabi Systems, Inc.
+
+ This file is part of GCC.
+
+ GCC is free software; you can redistribute it and/or modify it
+ under the terms of the GNU General Public License as published
+ by the Free Software Foundation; either version 3, or (at your
+ option) any later version.
+
+ GCC is distributed in the hope that it will be useful, but WITHOUT
+ ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
+ or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public
+ License for more details.
+
+ You should have received a copy of the GNU General Public License
+ along with GCC; see the file COPYING3. If not see
+
Re: [patch, fortran] Fix PR 89174, segfault on allocate with MOLD
Hi Thomas, > Of course, there could also be a more profound way of fixing this > bug :-) I wish that it were the case. I am unable to decide whether the design choices made for an F95 compiler have cause the add-ons to be intrinsically complicated or whether or whether F2018, extensions and legacy support is the cause of the complexity - probably both. Either way, profundity is rarely to be found in bugfixes. > > Regression-tested on x86_64-pc-linux-gnu. OK for trunk and gcc-8? Yes, that's good for both branches. Thanks for the fix. Paul
Re: [patch, fortran] Fix PR 89174, segfault on allocate with MOLD
On Sun, Feb 24, 2019 at 05:42:14PM +, Paul Richard Thomas wrote: > > > Of course, there could also be a more profound way of fixing this > > bug :-) > > I wish that it were the case. I am unable to decide whether the design > choices made for an F95 compiler have cause the add-ons to be > intrinsically complicated or whether or whether F2018, extensions and > legacy support is the cause of the complexity - probably both. Either > way, profundity is rarely to be found in bugfixes. > flang project was going to port PGI's frontend to use llvm as it middle/backend. A part of the port was to update PGI bits to include modern Fortran. The flang developers have decided to write an entirely new, from scratch, frontend. My conclusion is our 15+ year-old decisions and the addition of newer features (both modern Fortran and legacy) have complicated parts of the compiler to an almost unmanageable state. You can probably appreciate this better than most of us. -- Steve
Re: [PATCH] Limit simplify_merge_mask optimization to cases where it can't trap (PR rtl-optimization/89445)
On February 23, 2019 1:27:46 AM GMT+01:00, Jakub Jelinek
wrote:
>Hi!
>
>The following testcase is miscompiled on x86_64. The problem is that
>simplify_merge_mask optimization throws away an inner VEC_MERGE when
>there
>is an outer one with the same mask. This can be done only if the
>change
>doesn't have observable side-effects. The code already uses
>side_effects_p
>tests in various spots, that is needed, but as this testcase shows, not
>sufficient. Another issue is if there is a MEM load or store and not
>MEM_NOTRAP_P, as the testcase shows. And another problem can be vector
>integer division by zero (I think only mips has such insn), or various
>floating point operations if we care about floating point exceptions.
>
>While fixing this, I've found that may_trap_p_1 doesn't really support
>vector operations very much, vector floating point arithmetics can
>cause
>exceptions like scalar floating point arithmetics; on the other side,
>the
>4 VEC_* codes can't trap themselves, though their operands could.
>
>Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
OK.
Richard.
>2019-02-23 Jakub Jelinek
>
> PR rtl-optimization/89445
> * simplify-rtx.c (simplify_ternary_operation): Don't use
> simplify_merge_mask on operands that may trap.
> * rtlanal.c (may_trap_p_1): Use FLOAT_MODE_P instead of
> SCALAR_FLOAT_MODE_P checks. For integral division by zero, if
> second operand is CONST_VECTOR, check if any element could be zero.
> Don't expect traps for VEC_{MERGE,SELECT,CONCAT,DUPLICATE} unless
> their operands can trap.
>
> * gcc.target/i386/avx512f-pr89445.c: New test.
>
>--- gcc/simplify-rtx.c.jj 2019-01-10 11:43:14.390377646 +0100
>+++ gcc/simplify-rtx.c 2019-02-22 19:01:08.977661098 +0100
>@@ -6073,8 +6073,10 @@ simplify_ternary_operation (enum rtx_cod
>
> if (!side_effects_p (op2))
> {
>-rtx top0 = simplify_merge_mask (op0, op2, 0);
>-rtx top1 = simplify_merge_mask (op1, op2, 1);
>+rtx top0
>+ = may_trap_p (op0) ? NULL_RTX : simplify_merge_mask (op0, op2,
>0);
>+rtx top1
>+ = may_trap_p (op1) ? NULL_RTX : simplify_merge_mask (op1, op2,
>1);
> if (top0 || top1)
> return simplify_gen_ternary (code, mode, mode,
>top0 ? top0 : op0,
>--- gcc/rtlanal.c.jj 2019-02-20 10:00:49.279492877 +0100
>+++ gcc/rtlanal.c 2019-02-22 19:03:02.478790634 +0100
>@@ -2846,10 +2846,28 @@ may_trap_p_1 (const_rtx x, unsigned flag
> case UMOD:
> if (HONOR_SNANS (x))
> return 1;
>- if (SCALAR_FLOAT_MODE_P (GET_MODE (x)))
>+ if (FLOAT_MODE_P (GET_MODE (x)))
> return flag_trapping_math;
> if (!CONSTANT_P (XEXP (x, 1)) || (XEXP (x, 1) == const0_rtx))
> return 1;
>+ if (GET_CODE (XEXP (x, 1)) == CONST_VECTOR)
>+ {
>+/* For CONST_VECTOR, return 1 if any element is or might be zero.
>*/
>+unsigned int n_elts;
>+rtx op = XEXP (x, 1);
>+if (!GET_MODE_NUNITS (GET_MODE (op)).is_constant (&n_elts))
>+ {
>+if (!CONST_VECTOR_DUPLICATE_P (op))
>+ return 1;
>+for (unsigned i = 0; i < (unsigned int) XVECLEN (op, 0); i++)
>+ if (CONST_VECTOR_ENCODED_ELT (op, i) == const0_rtx)
>+return 1;
>+ }
>+else
>+ for (unsigned i = 0; i < n_elts; i++)
>+if (CONST_VECTOR_ELT (op, i) == const0_rtx)
>+ return 1;
>+ }
> break;
>
> case EXPR_LIST:
>@@ -2898,12 +2916,16 @@ may_trap_p_1 (const_rtx x, unsigned flag
> case NEG:
> case ABS:
> case SUBREG:
>+case VEC_MERGE:
>+case VEC_SELECT:
>+case VEC_CONCAT:
>+case VEC_DUPLICATE:
> /* These operations don't trap even with floating point. */
> break;
>
> default:
> /* Any floating arithmetic may trap. */
>- if (SCALAR_FLOAT_MODE_P (GET_MODE (x)) && flag_trapping_math)
>+ if (FLOAT_MODE_P (GET_MODE (x)) && flag_trapping_math)
> return 1;
> }
>
>--- gcc/testsuite/gcc.target/i386/avx512f-pr89445.c.jj 2019-02-22
>19:19:17.709898754 +0100
>+++ gcc/testsuite/gcc.target/i386/avx512f-pr89445.c2019-02-22
>19:18:58.115216531 +0100
>@@ -0,0 +1,54 @@
>+/* PR rtl-optimization/89445 */
>+/* { dg-do run { target { avx512f && mmap } } } */
>+/* { dg-options "-O2 -mavx512f" } */
>+
>+#include "avx512f-check.h"
>+
>+#include
>+#ifndef MAP_ANONYMOUS
>+#define MAP_ANONYMOUS MAP_ANON
>+#endif
>+#ifndef MAP_ANON
>+#define MAP_ANON 0
>+#endif
>+#ifndef MAP_FAILED
>+#define MAP_FAILED ((void *)-1)
>+#endif
>+
>+__attribute__ ((noipa))
>+void daxpy (unsigned long n, double a, double const *__restrict x,
>+ double *__restrict y)
>+{
>+ const __m512d v_a = _mm512_broadcastsd_pd (_mm_set_sd (a));
>+ const __mmask16 final = (1U << (n % 8u)) - 1;
>+ __mmask16 mask = 65535u;
>+ unsigned long i;
>+ for (i = 0; i < n * sizeof
Re: [PR fortran/89266, patch] - ICE with TRANSFER of len=0 character array constructor
Committed as rev. 269177. As this patch also fixed PR88326,
I added the testcase below.
Thanks for the review,
Harald
2019-02-24 Harald Anlauf
PR fortran/88326
* gfortran.dg/pr88326.f90: New test.
On 02/23/19 19:10, Thomas Koenig wrote:
> Hi Harald,
>
>> OK for trunk? Or rather wait for post-9.1?
>
> I think this can go into current trunk.
>
> Thanks!
>
> Regards
>
> Thomas
>
Index: gcc/testsuite/gfortran.dg/pr88326.f90
===
--- gcc/testsuite/gfortran.dg/pr88326.f90 (nonexistent)
+++ gcc/testsuite/gfortran.dg/pr88326.f90 (working copy)
@@ -0,0 +1,11 @@
+! { dg-do compile }
+!
+! PR fortran/88326 - ICE in gfc_conv_array_initializer
+
+program p
+ character, parameter :: x(3) = ['a','b','c']
+ character:: y(1) = transfer('', x) ! { dg-error "Different shape for
array assignment" }
+ character(0) :: z(1) = transfer('', x) ! { dg-error "Different shape for
array assignment" }
+ character:: u(0) = transfer('', x)
+ print *, y, z, u
+end
[PATCH] i386: Compile PR target/87007 tests with -mfpmath=sse
-mfpmath=sse is needed to enable SSE for FP math in 32-bit.
PR target/87007
* gcc.target/i386/pr87007-1.c: Compile with -mfpmath=sse.
* gcc.target/i386/pr87007-2.c: Likewise.
---
gcc/testsuite/ChangeLog | 6 ++
gcc/testsuite/gcc.target/i386/pr87007-1.c | 2 +-
gcc/testsuite/gcc.target/i386/pr87007-2.c | 2 +-
3 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog
index 804cf456fe4..39d7ab5d9d7 100644
--- a/gcc/testsuite/ChangeLog
+++ b/gcc/testsuite/ChangeLog
@@ -1,3 +1,9 @@
+2019-02-24 H.J. Lu
+
+ PR target/87007
+ * gcc.target/i386/pr87007-1.c: Compile with -mfpmath=sse.
+ * gcc.target/i386/pr87007-2.c: Likewise.
+
2019-02-24 Harald Anlauf
PR fortran/89266
diff --git a/gcc/testsuite/gcc.target/i386/pr87007-1.c
b/gcc/testsuite/gcc.target/i386/pr87007-1.c
index 93cf1dcdfa5..616a70c834a 100644
--- a/gcc/testsuite/gcc.target/i386/pr87007-1.c
+++ b/gcc/testsuite/gcc.target/i386/pr87007-1.c
@@ -1,5 +1,5 @@
/* { dg-do compile } */
-/* { dg-options "-O2 -march=skylake" } */
+/* { dg-options "-O2 -march=skylake -mfpmath=sse" } */
extern float f;
extern double d;
diff --git a/gcc/testsuite/gcc.target/i386/pr87007-2.c
b/gcc/testsuite/gcc.target/i386/pr87007-2.c
index cca7ae7afbc..fc0b3f5d56f 100644
--- a/gcc/testsuite/gcc.target/i386/pr87007-2.c
+++ b/gcc/testsuite/gcc.target/i386/pr87007-2.c
@@ -1,5 +1,5 @@
/* { dg-do compile } */
-/* { dg-options "-O2 -march=skylake" } */
+/* { dg-options "-O2 -march=skylake -mfpmath=sse" } */
extern float f;
extern double d;
--
2.20.1
Re: [ping] [PATCH doc] correct/improve -Wmissing-attributes and -Wattribute-alias
On 2/15/19 6:57 PM, Sandra Loosemore wrote: On 2/6/19 9:16 AM, Martin Sebor wrote: The manual documents the -Wno-missing-attributes form of the option as if it was enabled by default, even though it's enabled by -Wall (I can't get this -Wno- convention straight in my head). I also got private comments on the documentation of the option suggesting to add cross-references, and to list the attributes -Wattribute-alias considers (the same ones as -Wmissing-attributes). The attached patch makes these changes. I found the discussion of both options incomprehensible even with this patch. :-( The defaults are incorrect, there are typos, awkward wording and confusing paragraph organization, etc. So I consulted the sources and came up with the attached alternative patch. Can you review this for correctness and generally making sense? 2019-02-15 Sandra Loosemore Martin Sebor gcc/ * c-family/c.opt (Wmissing-attributes): Clean up doc string. * common.opt (Wattribute-alias): Likewise. * doc/invoke.texi (Option Summary): List general form of -Wattribute-alias=. List positive form of -Wmissing-attributes. (-Wmissing-attributes): Invert entry, rewrite and correct default. Add cross-references. (-Wattribute-alias): Rewrite and correct default. Mention considered attributes (same as for -Wmissing-attributes). Any thoughts on this patch? I'll go ahead and commit it if I don't hear any objection in the next couple of days it can't be any worse than the existing documentation. :-P -Sandra
