[PATCH] libgo: Add support for sh
Hello!
The attached patch adds the necessary definitions to enable libgo
to build on sh (Hitachi SuperH).
Two remarks:
1.
I'm not sure whether all the definitions in libgo/configure.ac are
correct for SuperH. I made the assumptions that the values are similar
for ARM 32-bit and SuperH as these architectures are comparable, except
that SH has always 16-bit instructions.
2.
In order for the build to succeed, I had to adjust the signature of
ioctl() in libgo/go/exp/terminal/util.go to make the second parameter
"uint" instead of "int", see [1]. With this change, the signature also
matches the signature used on Linux [2] and FreeBSD [3].
Without the change, the build fails with an integer overflow:
./libtool: line 1143: warning: setlocale: LC_ALL: cannot change locale
(en_US.UTF-8)
../../../src/libgo/go/exp/terminal/util.go:70:23: error: integer constant
overflow
if ioctl(fd, syscall.TIOCGWINSZ, unsafe.Pointer(&dimensions)) < 0 {
^
Makefile:3342: recipe for target 'exp/terminal.lo' failed
Thanks,
Adrian
> [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83308#c10
> [2] http://man7.org/linux/man-pages/man2/ioctl.2.html
> [3] https://www.freebsd.org/cgi/man.cgi?query=ioctl&sektion=2
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaub...@debian.org
`. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
>From a20d0d921734a94da1e72beff862091323534ce0 Mon Sep 17 00:00:00 2001
From: John Paul Adrian Glaubitz
Date: Sat, 16 Dec 2017 10:05:20 +0100
Subject: [PATCH] 2017-12-16 John Paul Adrian Glaubitz
PR go/83308
* libgo/configure.ac: Add autoconf definitions for sh.
* libgo/go/cmd/cgo/main.go: Enable build on sh.
* libgo/go/go/build/syslist.go: Likewise.
* libgo/go/runtime/hash32.go: Likewise.
* libgo/go/runtime/lfstack_32bit.go: Likewise.
* libgo/go/runtime/unaligned2.go: Likewise.
* libgo/go/syscall/endian_little.go: Likewise.
* libgo/testsuite/gotest: Likewise.
* libgo/match.sh: Add architecture matching for sh.
---
ChangeLog | 13 +
libgo/configure.ac| 7 +++
libgo/go/cmd/cgo/main.go | 2 ++
libgo/go/go/build/syslist.go | 2 +-
libgo/go/runtime/hash32.go| 2 +-
libgo/go/runtime/lfstack_32bit.go | 2 +-
libgo/go/runtime/unaligned2.go| 2 +-
libgo/go/syscall/endian_little.go | 2 +-
libgo/match.sh| 4 ++--
libgo/testsuite/gotest| 4 ++--
10 files changed, 31 insertions(+), 9 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index 275a340f6a8..f6efeb3e809 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,16 @@
+2017-12-16 John Paul Adrian Glaubitz
+
+PR go/83308
+* libgo/configure.ac: Add autoconf definitions for sh.
+* libgo/go/cmd/cgo/main.go: Enable build on sh.
+* libgo/go/go/build/syslist.go: Likewise.
+* libgo/go/runtime/hash32.go: Likewise.
+* libgo/go/runtime/lfstack_32bit.go: Likewise.
+* libgo/go/runtime/unaligned2.go: Likewise.
+* libgo/go/syscall/endian_little.go: Likewise.
+* libgo/testsuite/gotest: Likewise.
+* libgo/match.sh: Add architecture matching for sh.
+
2017-12-12 Stafford Horne
* configure.ac: Remove logic adding gdb to noconfigsdirs for or1k.
diff --git a/libgo/configure.ac b/libgo/configure.ac
index 7b0c629653f..65a9fb9c54e 100644
--- a/libgo/configure.ac
+++ b/libgo/configure.ac
@@ -360,6 +360,13 @@ GOARCH_MINFRAMESIZE=8
GOARCH_CACHELINESIZE=256
GOARCH_PCQUANTUM=2
;;
+ sh*-*-*)
+GOARCH=sh
+GOARCH_FAMILY=SH
+GOARCH_CACHELINESIZE=32
+GOARCH_PCQUANTUM=2
+GOARCH_MINFRAMESIZE=4
+;;
sparc*-*-*)
AC_COMPILE_IFELSE([
#if defined(__sparcv9) || defined(__arch64__)
diff --git a/libgo/go/cmd/cgo/main.go b/libgo/go/cmd/cgo/main.go
index c9a44fdd166..9c821db2d90 100644
--- a/libgo/go/cmd/cgo/main.go
+++ b/libgo/go/cmd/cgo/main.go
@@ -161,6 +161,7 @@ var ptrSizeMap = map[string]int64{
"ppc64le": 8,
"s390":4,
"s390x": 8,
+ "sh": 4,
"sparc": 4,
"sparc64": 8,
}
@@ -183,6 +184,7 @@ var intSizeMap = map[string]int64{
"ppc64le": 8,
"s390":4,
"s390x": 8,
+ "sh": 4,
"sparc": 4,
"sparc64": 8,
}
diff --git a/libgo/go/go/build/syslist.go b/libgo/go/go/build/syslist.go
index 290ba9efa0c..395dc8cd15a 100644
--- a/libgo/go/go/build/syslist.go
+++ b/libgo/go/go/build/syslist.go
@@ -5,4 +5,4 @@
package build
const goosList = "aix android darwin dragonfly freebsd linux nacl netbsd openbsd plan9 solaris windows zos "
-const goarchList = "386 amd64 amd64p32 arm armbe arm64 arm64be alpha m68k ppc64 ppc64le mips mipsle mips64 mips64le mips64p32 mips64p32le ppc s390 s390x sparc sparc64 "
+const goarchList = "386 amd64 amd64p32 arm armbe arm64 arm64be alpha m6
[v3 PATCH] PR libstdc++/68430
The compiler-powered is_constructible that we have in gcc 8 is powerful
enough to give the right answer to an is_constructible question
that would be hard for a pure-library implementation to get right
in a well-formed fashion. This is just adding a test for it. Tested
on Linux-PPC64, OK for trunk?
2017-12-16 Ville Voutilainen
PR libstdc++/68430
* testsuite/20_util/is_constructible/68430.cc: New.
diff --git a/libstdc++-v3/testsuite/20_util/is_constructible/68430.cc
b/libstdc++-v3/testsuite/20_util/is_constructible/68430.cc
new file mode 100644
index 000..3f880b3
--- /dev/null
+++ b/libstdc++-v3/testsuite/20_util/is_constructible/68430.cc
@@ -0,0 +1,6 @@
+// { dg-do compile { target c++11 } }
+
+#include
+
+template struct Foo { Foo(T = nullptr) {} };
+static_assert(!std::is_constructible>::value, "");
Re: [PATCH] libgo: Add support for sh
On 12/16/2017 10:24 AM, John Paul Adrian Glaubitz wrote: > The attached patch adds the necessary definitions to enable libgo > to build on sh (Hitachi SuperH). Forgot to mention: I can compile Go programs for SH with the patched gcc-7 which work fine on my Renesas SH7785LCR evaluation board running Debian unstable (sh4). The programs crash on qemu-sh4-user though but that's a limitation in QEMU. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
[PATCH] C++: handle locations wrappers when calling warn_for_memset
On Mon, 2017-12-11 at 18:36 -0500, Jason Merrill wrote:
> On 11/10/2017 04:45 PM, David Malcolm wrote:
> > We need to strip away location wrappers in tree.c predicates like
> > integer_zerop, otherwise they fail when they're called on
> > wrapped INTEGER_CST; an example can be seen for
> >c-c++-common/Wmemset-transposed-args1.c
> > in g++.sum, where the warn_for_memset fails to detect integer zero
> > if the location wrappers aren't stripped.
>
> These shouldn't be needed; callers should have folded away location
> wrappers. I would hope for STRIP_ANY_LOCATION_WRAPPER to be almost
> never needed.
>
> warn_for_memset may be missing some calls to fold_for_warn.
It is, thanks.
Here's a revised fix for e.g. Wmemset-transposed-args1.c, replacing
"[PATCH 05/14] tree.c: strip location wrappers from integer_zerop etc"
and
"[PATCH 10/14] warn_for_memset: handle location wrappers"
This version of the patch simply calls fold_for_warn on each of the
arguments before calling warn_for_memset. This ensures that
warn_for_memset detects integer zero. It also adds a
literal_integer_zerop to deal with location wrapper nodes when
building "literal_mask" for the call, since this must be called
*before* the fold_for_warn calls.
Successfully bootstrapped®rtested on x86_64-pc-linux-gnu, as
part of the kit.
Is this OK for trunk, once the rest of the kit is approved?
gcc/cp/ChangeLog:
* parser.c (literal_integer_zerop): New function.
(cp_parser_postfix_expression): When calling warn_for_memset,
replace integer_zerop calls with literal_integer_zerop, and
call fold_for_warn on the arguments.
---
gcc/cp/parser.c | 18 --
1 file changed, 16 insertions(+), 2 deletions(-)
diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index d15769a..7bca460 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -6621,6 +6621,16 @@ cp_parser_compound_literal_p (cp_parser *parser)
return compound_literal_p;
}
+/* Return 1 if EXPR is the integer constant zero or a complex constant
+ of zero, without any folding, but ignoring location wrappers. */
+
+static int
+literal_integer_zerop (const_tree expr)
+{
+ STRIP_ANY_LOCATION_WRAPPER (expr);
+ return integer_zerop (expr);
+}
+
/* Parse a postfix-expression.
postfix-expression:
@@ -7168,8 +7178,12 @@ cp_parser_postfix_expression (cp_parser *parser, bool
address_p, bool cast_p,
tree arg0 = (*args)[0];
tree arg1 = (*args)[1];
tree arg2 = (*args)[2];
- int literal_mask = ((!!integer_zerop (arg1) << 1)
- | (!!integer_zerop (arg2) << 2));
+ /* Handle any location wrapper nodes. */
+ arg0 = fold_for_warn (arg0);
+ int literal_mask = ((!!literal_integer_zerop (arg1) << 1)
+ | (!!literal_integer_zerop (arg2) << 2));
+ arg1 = fold_for_warn (arg1);
+ arg2 = fold_for_warn (arg2);
if (TREE_CODE (arg2) == CONST_DECL)
arg2 = DECL_INITIAL (arg2);
warn_for_memset (input_location, arg0, arg2, literal_mask);
--
1.8.5.3
Re: [Patch combine] Don't create vector mode ZERO_EXTEND from subregs
I was happily going to close PR 55549, but it looks like we are trying the same transformation in a second place in that file :-( On Mon, 11 Dec 2017, James Greenhalgh wrote: Hi, In simplify_set we try transforming the paradoxical subreg expression: (set FOO (subreg:M (mem:N BAR) 0)) in to: (set FOO (zero_extend:M (mem:N BAR))) However, this code does not consider the case where M is a vector mode, allowing it to construct (for example): (zero_extend:V4SI (mem:SI)) This would clearly have the wrong semantics, but fortunately we fail long before then in expand_compound_operation. As we really don't want a vector zero_extend of a scalar value. We need to explicitly reject vector modes from this transformation. This fixes a failure I'm seeing on a branch in which I'm trying to tackle some performance regressions, so I have no live testcase for this, but it is wrong by observation. Tested on aarch64-none-elf and bootstrapped on aarch64-none-linux-gnu with no issues. OK? Thanks, James --- 2017-12-11 James Greenhalgh * combine.c (simplify_set): Do not transform subregs to zero_extends if the destination mode is a vector mode. -- Marc Glisse
Re: [Patch, testcase] PR82767 Fix scan-assembler patterns in i386/pr71321.c
On 11/06/2017 12:11 AM, Uros Bizjak wrote:
> On Mon, Nov 6, 2017 at 12:19 AM, Peryt, Sebastian
> wrote:
>>> On Sun, Nov 5, 2017 at 12:14 PM, Peryt, Sebastian
>>>
>>> wrote:
Hi,
After r253934 gcc.target/i386/pr71321.c started to fail due to the wrong
>>> number of scan-assembler - 2 instead of 3. This patch is fixing that.
>>>
>>> Are you sure that there is no problem with the code generation? Did you
>>> investigate original PR for what it is testing and why it is testing for
>>> these 3
>>> LEAs?
>>
>> Well, the problem is due to the change in cost model. This can be reverted
>> by simple modification:
>>
>> diff --git a/gcc/config/i386/x86-tune-costs.h
>> b/gcc/config/i386/x86-tune-costs.h
>> index c7ac70e..bb5b3e2 100644
>> --- a/gcc/config/i386/x86-tune-costs.h
>> +++ b/gcc/config/i386/x86-tune-costs.h
>> @@ -2253,7 +2253,7 @@ struct processor_costs core_cost = {
>> COSTS_N_INSNS (4), /* DI
>> */
>> COSTS_N_INSNS (4)}, /*other
>> */
>>0, /* cost of multiply per each bit set
>> */
>> - {COSTS_N_INSNS (8), /* cost of a divide/mod for QI */
>> + {COSTS_N_INSNS (18), /* cost of a divide/mod for QI */
>> COSTS_N_INSNS (8), /* HI */
>> /* 8-11 */
>> COSTS_N_INSNS (11), /* SI */
>>
>> The original PR was to make better code generation when dividing and modulo
>> small integers.
>>
>> Ok, maybe I missed something. I'll get back to PR and see if any other
>> solution will be proposed
>> since for now I have nothing.
>
> Please also note that this testcase is intended for generic cost
> model, and you are testing --with-cpu=corei7. The testcase can be
> "fixed" by adding "-mtune=generic", but please investigate the tuning
> change anyway.
So I ack'd a change from Markus last night to bump the costs for the
div/mod insns on core2 and a couple other micro-architectures. They
weren't as a big a bump as Sebastian's change.
I've also committed Sebastian's change to use generic tuning on the test.
jeff
[patch, libgfortran] Bug 81937 - stack-buffer-overflow on memcpy
Hi all,
This problem was found with -fsanitize=address.
Turns out we are not correctly tracking the bytes left in the internal unit
string and we were reading memory past the end. I am sure the problem exists in
gcc 7 and I will examine gcc 6 as well and fix this in all cases I see. The
function sread is basically a wrapper on memcpy
The patch is fairly straight forward.
Regression tested on x86_64-pc-linux-gnu. OK for trunk and back ports as I find?
Regards,
Jerry
2017-12-16 Jerry DeLisle
PR libgfortran/81937
* io/list_read.c (next_char_internal): Don't attempt to read
from the internal unit stream if no bytes are left. Decrement
bytes_left in the right place.
diff --git a/libgfortran/io/list_read.c b/libgfortran/io/list_read.c
index 379050cecad..037f2daa647 100644
--- a/libgfortran/io/list_read.c
+++ b/libgfortran/io/list_read.c
@@ -266,15 +266,19 @@ next_char_internal (st_parameter_dt *dtp)
}
/* Get the next character and handle end-of-record conditions. */
-
- if (is_char4_unit(dtp)) /* Check for kind=4 internal unit. */
- length = sread (dtp->u.p.current_unit->s, &c, 1);
+ if (likely (dtp->u.p.current_unit->bytes_left > 0))
+{
+ if (unlikely (is_char4_unit(dtp))) /* Check for kind=4 internal unit. */
+ length = sread (dtp->u.p.current_unit->s, &c, 1);
+ else
+ {
+ char cc;
+ length = sread (dtp->u.p.current_unit->s, &cc, 1);
+ c = cc;
+ }
+}
else
- {
- char cc;
- length = sread (dtp->u.p.current_unit->s, &cc, 1);
- c = cc;
- }
+length = 0;
if (unlikely (length < 0))
{
@@ -290,7 +294,6 @@ next_char_internal (st_parameter_dt *dtp)
generate_error (&dtp->common, LIBERROR_INTERNAL_UNIT, NULL);
return '\0';
}
- dtp->u.p.current_unit->bytes_left--;
}
else
{
@@ -302,6 +305,7 @@ next_char_internal (st_parameter_dt *dtp)
dtp->u.p.at_eof = 1;
}
}
+ dtp->u.p.current_unit->bytes_left--;
done:
dtp->u.p.at_eol = (c == '\n' || c == EOF);
Re: [PATCH] set range for strlen(array) to avoid spurious -Wstringop-overflow (PR 83373 , PR 78450)
On 12/15/2017 10:29 AM, Martin Sebor wrote:
On 12/15/2017 09:17 AM, Richard Biener wrote:
On December 15, 2017 4:58:14 PM GMT+01:00, Martin Sebor
wrote:
On 12/15/2017 01:48 AM, Richard Biener wrote:
On Thu, Dec 14, 2017 at 5:01 PM, Martin Sebor
wrote:
On 12/14/2017 03:43 AM, Richard Biener wrote:
On Wed, Dec 13, 2017 at 4:47 AM, Martin Sebor
wrote:
On 12/12/2017 05:35 PM, Jeff Law wrote:
On 12/12/2017 01:15 PM, Martin Sebor wrote:
Bug 83373 - False positive reported by -Wstringop-overflow, is
another example of warning triggered by a missed optimization
opportunity, this time in the strlen pass. The optimization
is discussed in pr78450 - strlen(s) return value can be assumed
to be less than the size of s. The gist of it is that the
result
of strlen(array) can be assumed to be less than the size of
the array (except in the corner case of last struct members).
To avoid the false positive the attached patch adds this
optimization to the strlen pass. Although the patch passes
bootstrap and regression tests for all front-ends I'm not sure
the way it determines the upper bound of the range is 100%
correct for languages with arrays with a non-zero lower bound.
Maybe it's just not as tight as it could be.
What about something hideous like
struct fu {
char x1[10];
char x2[10];
int avoid_trailing_array;
}
Where objects stored in x1 are not null terminated. Are we in
the realm
of undefined behavior at that point (I hope so)?
Yes, this is undefined. Pointer arithmetic (either direct or
via standard library functions) is only defined for pointers
to the same object or subobject. So even something like
memcpy (pfu->x1, pfu->x1 + 10, 10);
is undefined.
There's nothing undefined here - computing the pointer pointing
to one-after-the-last element of an array is valid (you are just
not allowed to dereference it).
Right, and memcpy dereferences it, so it's undefined.
That's interpretation of the standard that I don't share.
It's not an interpretation. It's a basic rule of the languages
that the standards are explicit about. In C11 you will find
this specified in detail in 6.5.6, paragraph 7 and 8 (of
particular relevance to your question below is p7: "a pointer
to an object that is not an element of an array behaves the same
as a pointer to the first element of an array of length one.")
I know.
Also, if I have struct f { int i; int j; }; and a int * that points
to the j member you say I have no standard conforming way
to get at a pointer to the i member from this, right?
Correct. See above.
Because
the pointer points to an 'int' object. But it also points within
a struct f object! So at least maybe (int *)((char *)p - offsetof
(struct f, j))
should be valid?
No, not really. It works in practice but it's not well-defined.
It doesn't matter how you get at the result. What matters is
what you start with. As Jeff said, to derive a pointer to
distinct suobjects of a larger object you need to start with
a pointer to the larger object and treat it as an array of
chars.
That's obviously not constraints people use C and C++ with so I see no
way to enforce this within gimple.
There's code out there that relies on all sorts of undefined
behavior. It's a judgment call in each instance as to how much
of such code exists and how important it is. In this case, I'd
expect it to be confined to low-level software like OS kernels
and such whose authors use C as a more convenient assembly
language to talk directly to the hardware. Programmers in other
domains are usually more conscious of the requirements and limited
guarantees of the language and less willing to make assumptions
based on what this or that processor lets them get away with.
That being said, it certainly is possible to enforce this
constraint within GIMPLE. My -Wrestrict patch does it to
an extent for the memory and string built-ins. The -Warray-bounds
patch I submitted for offsets does it for all other expressions.
Neither patch exposed any such code in the Linux kernel, so it
doesn't look like abuses of this sort are common even in low-level
code.
Let me correct myself on this last point. I forgot I had disabled
the offset checking for memcpy. With it enabled, the enhanced
-Warray-bounds warning finds about a dozen distinct instances of
memcpy calls in the Linux kernel that cross the subobject boundary.
Most of them involve struct ieee80211_hdr and its adjacent unsigned
char array members. I think it would be worthwhile to do a more
careful review and, if this turns out to be the only (or predominant)
use case, consider tightening up GCC checkers to allow only it but
not cases involving members of any other types (especially
non-arrays). The most troublesome of those being variations on:
struct S {
...
char array[N];
void (*pfunc)(void);
...
};
extern struct S *ps;
memcpy (ps->array, data, N + X);
where the memcpy call clobbers the function pointer ps->pf
Re: [Patch, testcase] PR82767 Fix scan-assembler patterns in i386/pr71321.c
> On 11/06/2017 12:11 AM, Uros Bizjak wrote:
> > On Mon, Nov 6, 2017 at 12:19 AM, Peryt, Sebastian
> > wrote:
> >>> On Sun, Nov 5, 2017 at 12:14 PM, Peryt, Sebastian
> >>>
> >>> wrote:
> Hi,
>
> After r253934 gcc.target/i386/pr71321.c started to fail due to the wrong
> >>> number of scan-assembler - 2 instead of 3. This patch is fixing that.
> >>>
> >>> Are you sure that there is no problem with the code generation? Did you
> >>> investigate original PR for what it is testing and why it is testing for
> >>> these 3
> >>> LEAs?
> >>
> >> Well, the problem is due to the change in cost model. This can be reverted
> >> by simple modification:
> >>
> >> diff --git a/gcc/config/i386/x86-tune-costs.h
> >> b/gcc/config/i386/x86-tune-costs.h
> >> index c7ac70e..bb5b3e2 100644
> >> --- a/gcc/config/i386/x86-tune-costs.h
> >> +++ b/gcc/config/i386/x86-tune-costs.h
> >> @@ -2253,7 +2253,7 @@ struct processor_costs core_cost = {
> >> COSTS_N_INSNS (4), /*
> >> DI */
> >> COSTS_N_INSNS (4)}, /*
> >> other */
> >>0, /* cost of multiply per each bit
> >> set */
> >> - {COSTS_N_INSNS (8), /* cost of a divide/mod for QI */
> >> + {COSTS_N_INSNS (18), /* cost of a divide/mod for QI */
> >> COSTS_N_INSNS (8), /* HI */
> >> /* 8-11 */
> >> COSTS_N_INSNS (11), /* SI */
> >>
> >> The original PR was to make better code generation when dividing and
> >> modulo small integers.
> >>
> >> Ok, maybe I missed something. I'll get back to PR and see if any other
> >> solution will be proposed
> >> since for now I have nothing.
> >
> > Please also note that this testcase is intended for generic cost
> > model, and you are testing --with-cpu=corei7. The testcase can be
> > "fixed" by adding "-mtune=generic", but please investigate the tuning
> > change anyway.
> So I ack'd a change from Markus last night to bump the costs for the
> div/mod insns on core2 and a couple other micro-architectures. They
> weren't as a big a bump as Sebastian's change.
>
> I've also committed Sebastian's change to use generic tuning on the test.
Thanks. Lets see how far from reality we need to go. It should not be too hard
to teach mov/div expansion about the parallelism that should make costs more
realistic.
Honza
>
> jeff
Re: [patch, libgfortran] Bug 81937 - stack-buffer-overflow on memcpy
On Sat, Dec 16, 2017 at 6:26 PM, Jerry DeLisle wrote: > Hi all, > > This problem was found with -fsanitize=address. > > Turns out we are not correctly tracking the bytes left in the internal unit > string and we were reading memory past the end. I am sure the problem exists > in > gcc 7 and I will examine gcc 6 as well and fix this in all cases I see. The > function sread is basically a wrapper on memcpy > > The patch is fairly straight forward. > > Regression tested on x86_64-pc-linux-gnu. OK for trunk and back ports as I > find? > > Regards, > > Jerry > > 2017-12-16 Jerry DeLisle > > PR libgfortran/81937 > * io/list_read.c (next_char_internal): Don't attempt to read > from the internal unit stream if no bytes are left. Decrement > bytes_left in the right place. > Looks good, Ok for trunk/7/6. Thanks! -- Janne Blomqvist
Re: [PATCH] C++: handle locations wrappers when calling warn_for_memset
On 12/16/2017 06:12 AM, David Malcolm wrote:
On Mon, 2017-12-11 at 18:36 -0500, Jason Merrill wrote:
On 11/10/2017 04:45 PM, David Malcolm wrote:
We need to strip away location wrappers in tree.c predicates like
integer_zerop, otherwise they fail when they're called on
wrapped INTEGER_CST; an example can be seen for
c-c++-common/Wmemset-transposed-args1.c
in g++.sum, where the warn_for_memset fails to detect integer zero
if the location wrappers aren't stripped.
These shouldn't be needed; callers should have folded away location
wrappers. I would hope for STRIP_ANY_LOCATION_WRAPPER to be almost
never needed.
warn_for_memset may be missing some calls to fold_for_warn.
It is, thanks.
Here's a revised fix for e.g. Wmemset-transposed-args1.c, replacing
"[PATCH 05/14] tree.c: strip location wrappers from integer_zerop etc"
and
"[PATCH 10/14] warn_for_memset: handle location wrappers"
This version of the patch simply calls fold_for_warn on each of the
arguments before calling warn_for_memset. This ensures that
warn_for_memset detects integer zero. It also adds a
literal_integer_zerop to deal with location wrapper nodes when
building "literal_mask" for the call, since this must be called
*before* the fold_for_warn calls.
Successfully bootstrapped®rtested on x86_64-pc-linux-gnu, as
part of the kit.
Is this OK for trunk, once the rest of the kit is approved?
gcc/cp/ChangeLog:
* parser.c (literal_integer_zerop): New function.
(cp_parser_postfix_expression): When calling warn_for_memset,
replace integer_zerop calls with literal_integer_zerop, and
call fold_for_warn on the arguments.
---
gcc/cp/parser.c | 18 --
1 file changed, 16 insertions(+), 2 deletions(-)
diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index d15769a..7bca460 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -6621,6 +6621,16 @@ cp_parser_compound_literal_p (cp_parser *parser)
return compound_literal_p;
}
+/* Return 1 if EXPR is the integer constant zero or a complex constant
+ of zero, without any folding, but ignoring location wrappers. */
+
+static int
+literal_integer_zerop (const_tree expr)
+{
+ STRIP_ANY_LOCATION_WRAPPER (expr);
+ return integer_zerop (expr);
+}
+
/* Parse a postfix-expression.
postfix-expression:
@@ -7168,8 +7178,12 @@ cp_parser_postfix_expression (cp_parser *parser, bool
address_p, bool cast_p,
tree arg0 = (*args)[0];
tree arg1 = (*args)[1];
tree arg2 = (*args)[2];
- int literal_mask = ((!!integer_zerop (arg1) << 1)
- | (!!integer_zerop (arg2) << 2));
+ /* Handle any location wrapper nodes. */
+ arg0 = fold_for_warn (arg0);
+ int literal_mask = ((!!literal_integer_zerop (arg1) << 1)
+ | (!!literal_integer_zerop (arg2) << 2));
The double negation jumped out at me. The integer_zerop() function
looks like a predicate that hasn't yet been converted to return bool.
It seems that new predicates that are implemented on top of it could
return bool and their callers avoid this conversion. (At some point
in the future it would also be nice to convert the existing
predicates to return bool).
Martin
+ arg1 = fold_for_warn (arg1);
+ arg2 = fold_for_warn (arg2);
if (TREE_CODE (arg2) == CONST_DECL)
arg2 = DECL_INITIAL (arg2);
warn_for_memset (input_location, arg0, arg2, literal_mask);
[PATCH] rtlanal: dead_or_set_regno_p should handle CLOBBER (PR83424)
In PR83424 combine's move_deaths puts a REG_DEAD not in the wrong place
because dead_or_set_regno_p does not account for CLOBBER insns. This
fixes it.
Bootstrapped and tested on powerpc64-linux {-m32,-m64} and on x86_64-linux.
Is this okay for trunk?
Segher
2017-12-16 Segher Boessenkool
PR rtl-optimization/83424
* rtlanal.c (dead_or_set_regno_p): Handle CLOBBER just like SET.
gcc/testsuite/
PR rtl-optimization/83424
* gcc.dg/pr83424.c: New testsuite.
---
gcc/rtlanal.c |2 +-
gcc/testsuite/gcc.dg/pr83424.c | 30 ++
2 files changed, 31 insertions(+), 1 deletion(-)
create mode 100644 gcc/testsuite/gcc.dg/pr83424.c
diff --git a/gcc/rtlanal.c b/gcc/rtlanal.c
index c91f3f1..9f6988b 100644
--- a/gcc/rtlanal.c
+++ b/gcc/rtlanal.c
@@ -2082,7 +2082,7 @@ dead_or_set_regno_p (const rtx_insn *insn, unsigned int
test_regno)
if (GET_CODE (pattern) == COND_EXEC)
return 0;
- if (GET_CODE (pattern) == SET)
+ if (GET_CODE (pattern) == SET || GET_CODE (pattern) == CLOBBER)
return covers_regno_p (SET_DEST (pattern), test_regno);
else if (GET_CODE (pattern) == PARALLEL)
{
diff --git a/gcc/testsuite/gcc.dg/pr83424.c b/gcc/testsuite/gcc.dg/pr83424.c
new file mode 100644
index 000..5a304f5
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr83424.c
@@ -0,0 +1,30 @@
+/* PR rtl-optimization/83424 */
+/* { dg-do run { target int128 } } */
+/* { dg-options "-O -fno-tree-ccp -fno-tree-coalesce-vars" } */
+
+typedef unsigned char u8;
+typedef unsigned int u32;
+typedef unsigned __int128 u128;
+
+u32 a, c;
+u8 b;
+
+static u128 __attribute__ ((noinline, noclone))
+foo (u128 p)
+{
+ u8 x = ~b;
+ p &= c;
+ x *= -p;
+ x &= a == 0;
+ x >>= 1;
+ return p + x;
+}
+
+int
+main (void)
+{
+ u128 x = foo (0);
+ if (x != 0)
+__builtin_abort ();
+ return 0;
+}
--
1.7.10.4
Re: [PATCH] libgo: Add support for sh
On 12/16/2017 10:24 AM, John Paul Adrian Glaubitz wrote: > I'm not sure whether all the definitions in libgo/configure.ac are > correct for SuperH. I made the assumptions that the values are similar > for ARM 32-bit and SuperH as these architectures are comparable, except > that SH has always 16-bit instructions. According to the SuperH SH-4 CPU datasheet, the cacheline size is 32 bytes: > www.st.com/resource/en/user_manual/cd00147165.pdf (page 75) No idea about GOARCH_MINFRAMESIZE though. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
[PATCH 15/14] Use fold_for_warn in get_atomic_generic_size
I rebased the v2 patchkit; here's an extra patch to fix an issue
with it uncovered by a recently-added testcase (in r254990).
With the patch kit, but without this patch, g++'s
c-c++-common/pr83059.c
fails to emit the "invalid memory model argument 6" warning.
Successfully bootstrapped®rtested on x86_64-pc-linux-gnu, as
part of the kit.
Is this OK for trunk, assuming the rest of the kit is approved?
gcc/c-family/ChangeLog:
* c-common.c (get_atomic_generic_size): Call fold_for_warn on the
params before checking for INTEGER_CST.
---
gcc/c-family/c-common.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/c-family/c-common.c b/gcc/c-family/c-common.c
index 3438b87..ab03b7d 100644
--- a/gcc/c-family/c-common.c
+++ b/gcc/c-family/c-common.c
@@ -6720,7 +6720,7 @@ get_atomic_generic_size (location_t loc, tree function,
/* Check memory model parameters for validity. */
for (x = n_param - n_model ; x < n_param; x++)
{
- tree p = (*params)[x];
+ tree p = fold_for_warn ((*params)[x]);
if (TREE_CODE (p) == INTEGER_CST)
{
/* memmodel_base masks the low 16 bits, thus ignore any bits above
--
1.8.5.3
Re: [Patch combine] Don't create vector mode ZERO_EXTEND from subregs
Hi! On Mon, Dec 11, 2017 at 02:18:53PM +, James Greenhalgh wrote: > > In simplify_set we try transforming the paradoxical subreg expression: > > (set FOO (subreg:M (mem:N BAR) 0)) > > in to: > > (set FOO (zero_extend:M (mem:N BAR))) > > However, this code does not consider the case where M is a vector > mode, allowing it to construct (for example): > > (zero_extend:V4SI (mem:SI)) > > This would clearly have the wrong semantics, but fortunately we fail long > before then in expand_compound_operation. As we really don't want a vector > zero_extend of a scalar value. > > We need to explicitly reject vector modes from this transformation. It does not consider any other modes either. Both modes involved are required to be SCALAR_INT_MODE_P (for zero_extend to be valid at all and to be equivalent to the subreg); could you test for that instead please? Segher
[patch, doc] fix some typos
I noticed some repeated typos ("isntructions") in the ARM options
section of invoke.texi when I was skimming it looking for something
else. Then I looked around and found a few other typos elsewhere. I've
checked in this correction.
-Sandra
2017-12-16 Sandra Loosemore
gcc/
* doc/invoke.texi: Fix some typos.
Index: gcc/doc/invoke.texi
===
--- gcc/doc/invoke.texi (revision 255758)
+++ gcc/doc/invoke.texi (working copy)
@@ -2947,7 +2947,7 @@ might bypass the class non-trivial or de
violate const-correctness or encapsulation, or corrupt the virtual table.
Modifying the representation of such objects may violate invariants maintained
by member functions of the class. For example, the call to @code{memset}
-below is undefined becase it modifies a non-trivial class object and is,
+below is undefined because it modifies a non-trivial class object and is,
therefore, diagnosed. The safe way to either initialize or clear the storage
of objects of such types is by using the appropriate constructor or assignment
operator, if one is available.
@@ -9832,7 +9832,7 @@ of the loop on both branches (modified a
@item -floop-unroll-and-jam
@opindex floop-unroll-and-jam
-Apply unroll and jam transoformations on feasible loops. In a loop
+Apply unroll and jam transformations on feasible loops. In a loop
nest this unrolls the outer loop by some factor and fuses the resulting
multiple inner loops.
@@ -15648,7 +15648,7 @@ Permissible names are:
@samp{iwmmxt} and @samp{iwmmxt2}.
Additionally, the following architectures, which lack support for the
-Thumb exection state, are recognized but support is deprecated:
+Thumb execution state, are recognized but support is deprecated:
@samp{armv2}, @samp{armv2a}, @samp{armv3}, @samp{armv3m},
@samp{armv4}, @samp{armv5} and @samp{armv5e}.
@@ -15816,7 +15816,7 @@ The ARMv8-A Advanced SIMD and floating-p
@item +crypto
The cryptographic instructions.
@item +nocrypto
-Disable the cryptographic isntructions.
+Disable the cryptographic instructions.
@item +nofp
Disable the floating-point, Advanced SIMD and cryptographic instructions.
@end table
@@ -15831,7 +15831,7 @@ The cryptographic instructions. This al
floating-point instructions.
@item +nocrypto
-Disable the cryptographic isntructions.
+Disable the cryptographic instructions.
@item +nofp
Disable the floating-point, Advanced SIMD and cryptographic instructions.
@@ -15924,7 +15924,7 @@ The ARMv8-A Advanced SIMD and floating-p
@item +crypto
The cryptographic instructions.
@item +nocrypto
-Disable the cryptographic isntructions.
+Disable the cryptographic instructions.
@item +nofp
Disable the floating-point, Advanced SIMD and cryptographic instructions.
@end table
