[PATCH] IBM Z: Fix "+fvm" constraint with long doubles
Bootstrapped and regtested on s390x-redhat-linux. Ok for master?
When a long double is passed to an asm statement with a "+fvm"
constraint, a LRA loop occurs. This happens, because LRA chooses the
widest register class in this case (VEC_REGS), but the code generated
by s390_md_asm_adjust() always wants FP_REGS. Mismatching register
classes cause infinite reloading.
Fix by treating "fv" constraints as "v" in s390_md_asm_adjust().
gcc/ChangeLog:
* config/s390/s390.c (f_constraint_p): Treat "fv" constraints
as "v".
gcc/testsuite/ChangeLog:
* gcc.target/s390/vector/long-double-asm-fprvrmem.c: New test.
---
gcc/config/s390/s390.c | 12 ++--
.../s390/vector/long-double-asm-fprvrmem.c | 11 +++
2 files changed, 21 insertions(+), 2 deletions(-)
create mode 100644
gcc/testsuite/gcc.target/s390/vector/long-double-asm-fprvrmem.c
diff --git a/gcc/config/s390/s390.c b/gcc/config/s390/s390.c
index 151136bedbc..f7b1c03561e 100644
--- a/gcc/config/s390/s390.c
+++ b/gcc/config/s390/s390.c
@@ -16714,13 +16714,21 @@ s390_shift_truncation_mask (machine_mode mode)
static bool
f_constraint_p (const char *constraint)
{
+ bool seen_f_p = false;
+ bool seen_v_p = false;
+
for (size_t i = 0, c_len = strlen (constraint); i < c_len;
i += CONSTRAINT_LEN (constraint[i], constraint + i))
{
if (constraint[i] == 'f')
- return true;
+ seen_f_p = true;
+ if (constraint[i] == 'v')
+ seen_v_p = true;
}
- return false;
+
+ /* Treat "fv" constraints as "v", because LRA will choose the widest register
+ * class. */
+ return seen_f_p && !seen_v_p;
}
/* Implement TARGET_MD_ASM_ADJUST hook in order to fix up "f"
diff --git a/gcc/testsuite/gcc.target/s390/vector/long-double-asm-fprvrmem.c
b/gcc/testsuite/gcc.target/s390/vector/long-double-asm-fprvrmem.c
new file mode 100644
index 000..f95656c5723
--- /dev/null
+++ b/gcc/testsuite/gcc.target/s390/vector/long-double-asm-fprvrmem.c
@@ -0,0 +1,11 @@
+/* { dg-do compile } */
+/* { dg-options "-O3 -march=z14 -mzarch" } */
+
+long double
+foo (long double x)
+{
+ x = x * x;
+ asm("# %0" : "+fvm"(x));
+ x = x + x;
+ return x;
+}
--
2.29.2
Re: c++: Fix 2 testcases [PR 99601]
On Mon, Mar 15, 2021 at 03:28:06PM -0400, Nathan Sidwell wrote:
>
> I'd failed to correctly restrict some checks to lp64 x86 targets.
>
> PR c++/99601
> gcc/testsuite/
> * g++.dg/modules/builtin-3_a.C: Fix lp64 x86 detection.
> * g++.dg/modules/builtin-3_b.C: Fix lp64 x86 detection.
ERROR: tcl error sourcing
/home/jakub/src/gcc/gcc/testsuite/g++.dg/modules/modules.exp.
ERROR: unmatched open brace in list
while executing
"foreach op $tmp {
switch [lindex $op 0] {
"dg-options" {
set std_prefix "-std=gnu++"
if { [string match "*-std=*" [lindex $op 2]] } {
..."
(procedure "module-init" line 7)
invoked from within
"module-init $src"
invoked from within
"if [runtest_file_p $runtests $src] {
set tests [lsort [find [file dirname $src] [regsub {_a.[CHX]$} [file
tail $src] {_[a-z].[CHX]}]]]
set std_lis..."
("foreach" body line 3)
invoked from within
"foreach src [lsort [find $srcdir/$subdir {*_a.[CHX}]] {
# use the FOO_a.C name as the parallelization key
if [runtest_file_p $runtests $src] {..."
(file "/home/jakub/src/gcc/gcc/testsuite/g++.dg/modules/modules.exp" line
304)
invoked from within
"source /home/jakub/src/gcc/gcc/testsuite/g++.dg/modules/modules.exp"
("uplevel" body line 1)
invoked from within
"uplevel #0 source /home/jakub/src/gcc/gcc/testsuite/g++.dg/modules/modules.exp"
invoked from within
"catch "uplevel #0 source $test_file_name""
Tested on x86_64-linux -m32/-m64, committed to trunk as obvious.
BTW, that i?86-*-linux* *-*-darwin* case probably needs to be
{ { { i?86-*-linux* x86_64-*-linux* } && ia32 } || *-*-darwin* }
or so, but haven't tested that.
2021-03-16 Jakub Jelinek
PR c++/99601
* g++.dg/modules/builtin-3_a.C: Fix target selector syntax errors.
* g++.dg/modules/builtin-3_b.C: Likewise.
--- gcc/testsuite/g++.dg/modules/builtin-3_a.C.jj 2021-03-15
22:04:58.227425350 +0100
+++ gcc/testsuite/g++.dg/modules/builtin-3_a.C 2021-03-16 00:19:23.480612490
+0100
@@ -30,8 +30,8 @@ export inline int count (int a, ...)
// The implementation details of va_list's are target-specific.
// Usually one of two patterns though
// { dg-final { scan-lang-dump-not { Cluster members:\n \[0\]=decl
declaration '::__builtin_va_list'\n \[1\]=binding '::__builtin_va_list'\n}
module { target i?86-*-linux* x86_64-*-linux* } } }
-// { dg-final { scan-lang-dump {Wrote GMF:-[0-9]*
type_decl:'::__builtin_va_list'@builtins} module { { target x86_64-*-linux*
i>86-*-linux* } && lp64 } }
-// { dg-final { scan-lang-dump {Writing:-[0-9]*'s named merge key \(decl\)
type_decl:'::__builtin_va_list'} module { target { x86_64-*-linux*
i?86-*-linux* } && lp64 } } }
+// { dg-final { scan-lang-dump {Wrote GMF:-[0-9]*
type_decl:'::__builtin_va_list'@builtins} module { target { { x86_64-*-linux*
i?86-*-linux* } && lp64 } } } }
+// { dg-final { scan-lang-dump {Writing:-[0-9]*'s named merge key \(decl\)
type_decl:'::__builtin_va_list'} module { target { { x86_64-*-linux*
i?86-*-linux* } && lp64 } } } }
// { dg-final { scan-lang-dump {Writing:-1's named merge key \(decl\)
type_decl:'::__gnuc_va_list'} module { target i?86-*-linux* *-*-darwin* } } }
// { dg-final { scan-lang-dump {Wrote GMF:-3
type_decl:'::__gnuc_va_list'@builtins} module { target i?86-*-linux*
*-*-darwin* } } }
--- gcc/testsuite/g++.dg/modules/builtin-3_b.C.jj 2021-03-15
22:04:58.227425350 +0100
+++ gcc/testsuite/g++.dg/modules/builtin-3_b.C 2021-03-16 00:18:48.467995815
+0100
@@ -8,6 +8,6 @@ int main ()
}
// { dg-final { scan-lang-dump {Read:-[0-9]*'s named merge key \(matched\)
function_decl:'::__builtin_strlen'} module } }
-// { dg-final { scan-lang-dump {Read:-[0-9]*'s named merge key \(matched\)
type_decl:'::__builtin_va_list'} module { target { { x86_64-*-linux*
i?86-*-linux* } && lp64 } } }
+// { dg-final { scan-lang-dump {Read:-[0-9]*'s named merge key \(matched\)
type_decl:'::__builtin_va_list'} module { target { { x86_64-*-linux*
i?86-*-linux* } && lp64 } } } }
// { dg-final { scan-lang-dump {Read:-[0-9]*'s named merge key \(new\)
type_decl:'::va_list'} module } }
// { dg-final { scan-lang-dump {Read:-[0-9]*'s named merge key \(new\)
type_decl:'::__gnuc_va_list'} module } }
Jakub
libgo patch committed: Update to Go 1.16.2 release
This patch updates libgo to the Go 1.16.2 release. Bootstrapped and
ran Go testsuite on x86_64-pc-linux-gnu. Committed to mainline.
Ian
d5eae60451faeea9d87ae3815f7e4db0e6e182ed
diff --git a/gcc/go/gofrontend/MERGE b/gcc/go/gofrontend/MERGE
index e5756c6662c..c0bfa1ff78a 100644
--- a/gcc/go/gofrontend/MERGE
+++ b/gcc/go/gofrontend/MERGE
@@ -1,4 +1,4 @@
-2f281eb24ef256a2d3bb9fc1a7ef964d82b40182
+10b00ad87303d37c68b2d54dd25d655bd316946e
The first line of this file holds the git revision number of the last
merge done from the gofrontend repository.
diff --git a/libgo/MERGE b/libgo/MERGE
index 183b0245ee2..a52dceb182f 100644
--- a/libgo/MERGE
+++ b/libgo/MERGE
@@ -1,4 +1,4 @@
-f21be2fdc6f1becdbed1592ea0b245cdeedc5ac8
+3979fb9af9ccfc0b7ccb613dcf256b18c2c295f0
The first line of this file holds the git revision number of the
last merge done from the master library sources.
diff --git a/libgo/VERSION b/libgo/VERSION
index 4befab24bc9..d0b0a900460 100644
--- a/libgo/VERSION
+++ b/libgo/VERSION
@@ -1 +1 @@
-go1.16
+go1.16.2
diff --git a/libgo/go/archive/zip/reader.go b/libgo/go/archive/zip/reader.go
index 8b4e77875fb..c288ad965bc 100644
--- a/libgo/go/archive/zip/reader.go
+++ b/libgo/go/archive/zip/reader.go
@@ -664,7 +664,7 @@ func toValidName(name string) string {
if strings.HasPrefix(p, "/") {
p = p[len("/"):]
}
- for strings.HasPrefix(name, "../") {
+ for strings.HasPrefix(p, "../") {
p = p[len("../"):]
}
return p
diff --git a/libgo/go/archive/zip/reader_test.go
b/libgo/go/archive/zip/reader_test.go
index 34e96f7da43..5faf1f49b51 100644
--- a/libgo/go/archive/zip/reader_test.go
+++ b/libgo/go/archive/zip/reader_test.go
@@ -1081,3 +1081,38 @@ func TestFS(t *testing.T) {
t.Fatal(err)
}
}
+
+func TestCVE202127919(t *testing.T) {
+ // Archive containing only the file "../test.txt"
+ data := []byte{
+ 0x50, 0x4b, 0x03, 0x04, 0x14, 0x00, 0x08, 0x00,
+ 0x08, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+ 0x00, 0x00, 0x0b, 0x00, 0x00, 0x00, 0x2e, 0x2e,
+ 0x2f, 0x74, 0x65, 0x73, 0x74, 0x2e, 0x74, 0x78,
+ 0x74, 0x0a, 0xc9, 0xc8, 0x2c, 0x56, 0xc8, 0x2c,
+ 0x56, 0x48, 0x54, 0x28, 0x49, 0x2d, 0x2e, 0x51,
+ 0x28, 0x49, 0xad, 0x28, 0x51, 0x48, 0xcb, 0xcc,
+ 0x49, 0xd5, 0xe3, 0x02, 0x04, 0x00, 0x00, 0xff,
+ 0xff, 0x50, 0x4b, 0x07, 0x08, 0xc0, 0xd7, 0xed,
+ 0xc3, 0x20, 0x00, 0x00, 0x00, 0x1a, 0x00, 0x00,
+ 0x00, 0x50, 0x4b, 0x01, 0x02, 0x14, 0x00, 0x14,
+ 0x00, 0x08, 0x00, 0x08, 0x00, 0x00, 0x00, 0x00,
+ 0x00, 0xc0, 0xd7, 0xed, 0xc3, 0x20, 0x00, 0x00,
+ 0x00, 0x1a, 0x00, 0x00, 0x00, 0x0b, 0x00, 0x00,
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x2e,
+ 0x2e, 0x2f, 0x74, 0x65, 0x73, 0x74, 0x2e, 0x74,
+ 0x78, 0x74, 0x50, 0x4b, 0x05, 0x06, 0x00, 0x00,
+ 0x00, 0x00, 0x01, 0x00, 0x01, 0x00, 0x39, 0x00,
+ 0x00, 0x00, 0x59, 0x00, 0x00, 0x00, 0x00, 0x00,
+ }
+ r, err := NewReader(bytes.NewReader([]byte(data)), int64(len(data)))
+ if err != nil {
+ t.Fatalf("Error reading the archive: %v", err)
+ }
+ _, err = r.Open("test.txt")
+ if err != nil {
+ t.Errorf("Error reading file: %v", err)
+ }
+}
diff --git a/libgo/go/cmd/go.mod b/libgo/go/cmd/go.mod
index 235e28f64f3..35582f3975f 100644
--- a/libgo/go/cmd/go.mod
+++ b/libgo/go/cmd/go.mod
@@ -6,7 +6,7 @@ require (
github.com/google/pprof v0.0.0-20201203190320-1bf35d6f28c2
golang.org/x/arch v0.0.0-20201008161808-52c3e6f60cff
golang.org/x/crypto v0.0.0-20201016220609-9e8e0b390897
- golang.org/x/mod v0.4.1
+ golang.org/x/mod v0.4.2-0.20210302225053-d515b24adc21
golang.org/x/sys v0.0.0-20201204225414-ed752295db88 // indirect
golang.org/x/tools v0.0.0-20210107193943-4ed967dd8eff
)
diff --git a/libgo/go/cmd/go/internal/get/get.go
b/libgo/go/cmd/go/internal/get/get.go
index 38ff3823f22..329a2f5eda4 100644
--- a/libgo/go/cmd/go/internal/get/get.go
+++ b/libgo/go/cmd/go/internal/get/get.go
@@ -431,7 +431,7 @@ func downloadPackage(p *load.Package) error {
}
importPrefix = importPrefix[:slash]
}
- if err := module.CheckImportPath(importPrefix); err != nil {
+ if err := checkImportPath(importPrefix); err != nil {
return fmt.Errorf("%s: invalid import path: %v", p.ImportPath,
err)
}
security := web.SecureOnly
@@ -591,3 +591,31 @@ func selectTag(goVersion string, tags []string) (match
string) {
}
return ""
}
+
+// checkImportPath is like module.CheckImportPath, but it forbids
Re: [PATCH][pushed] analyzer: document new param
On 3/12/21 7:02 AM, Martin Liška wrote: On 3/12/21 2:56 PM, David Malcolm wrote: On Fri, 2021-03-12 at 09:45 +0100, Martin Liška wrote: Identified by my check that compares documentation of params with content of --help=param output. Pushed as obvious. Martin Thanks. Which check is this, BTW? (presumably this is something I should add to my patch testing workflow) ./gcc/xgcc -Bgcc --help=param &>params.txt ../contrib/check-params-in-docs.py ../gcc/doc/invoke.texi params.txt Any plans to integrate it into the testsuite? (That way we presumably wouldn't need to remember to run it by hand.) Martin Cheers, Martin Dave gcc/ChangeLog: * doc/invoke.texi: Add missing param documentation. --- gcc/doc/invoke.texi | 4 1 file changed, 4 insertions(+) diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi index 4a3c1e2fa0f..7a368959e5e 100644 --- a/gcc/doc/invoke.texi +++ b/gcc/doc/invoke.texi @@ -14362,6 +14362,10 @@ recurse deeper. The maximum depth of a symbolic value, before approximating the value as unknown. +@item analyzer-max-infeasible-edges +The maximum number of infeasible edges to reject before declaring +a diagnostic as infeasible. + @item gimple-fe-computed-hot-bb-threshold The number of executions of a basic block which is considered hot. The parameter is used only in GIMPLE FE.
c++: Fix 2 testcases [PR 99601]
I'd failed to correctly restrict some checks to lp64 x86 targets.
PR c++/99601
gcc/testsuite/
* g++.dg/modules/builtin-3_a.C: Fix lp64 x86 detection.
* g++.dg/modules/builtin-3_b.C: Fix lp64 x86 detection.
--
Nathan Sidwell
diff --git c/gcc/testsuite/g++.dg/modules/builtin-3_a.C w/gcc/testsuite/g++.dg/modules/builtin-3_a.C
index ad30ccf2a01..5f61fa4efab 100644
--- c/gcc/testsuite/g++.dg/modules/builtin-3_a.C
+++ w/gcc/testsuite/g++.dg/modules/builtin-3_a.C
@@ -30,8 +30,8 @@ export inline int count (int a, ...)
// The implementation details of va_list's are target-specific.
// Usually one of two patterns though
// { dg-final { scan-lang-dump-not { Cluster members:\n \[0\]=decl declaration '::__builtin_va_list'\n \[1\]=binding '::__builtin_va_list'\n} module { target i?86-*-linux* x86_64-*-linux* } } }
-// { dg-final { scan-lang-dump {Wrote GMF:-[0-9]* type_decl:'::__builtin_va_list'@builtins} module { target x86_64-*-linux* } } }
-// { dg-final { scan-lang-dump {Writing:-[0-9]*'s named merge key \(decl\) type_decl:'::__builtin_va_list'} module { target x86_64-*-linux* } } }
+// { dg-final { scan-lang-dump {Wrote GMF:-[0-9]* type_decl:'::__builtin_va_list'@builtins} module { { target x86_64-*-linux* i>86-*-linux* } && lp64 } }
+// { dg-final { scan-lang-dump {Writing:-[0-9]*'s named merge key \(decl\) type_decl:'::__builtin_va_list'} module { target { x86_64-*-linux* i?86-*-linux* } && lp64 } } }
// { dg-final { scan-lang-dump {Writing:-1's named merge key \(decl\) type_decl:'::__gnuc_va_list'} module { target i?86-*-linux* *-*-darwin* } } }
// { dg-final { scan-lang-dump {Wrote GMF:-3 type_decl:'::__gnuc_va_list'@builtins} module { target i?86-*-linux* *-*-darwin* } } }
diff --git c/gcc/testsuite/g++.dg/modules/builtin-3_b.C w/gcc/testsuite/g++.dg/modules/builtin-3_b.C
index 93489bddba4..5c94890c9c4 100644
--- c/gcc/testsuite/g++.dg/modules/builtin-3_b.C
+++ w/gcc/testsuite/g++.dg/modules/builtin-3_b.C
@@ -8,6 +8,6 @@ int main ()
}
// { dg-final { scan-lang-dump {Read:-[0-9]*'s named merge key \(matched\) function_decl:'::__builtin_strlen'} module } }
-// { dg-final { scan-lang-dump {Read:-[0-9]*'s named merge key \(matched\) type_decl:'::__builtin_va_list'} module { target { x86_64-*-linux* } } } }
+// { dg-final { scan-lang-dump {Read:-[0-9]*'s named merge key \(matched\) type_decl:'::__builtin_va_list'} module { target { { x86_64-*-linux* i?86-*-linux* } && lp64 } } }
// { dg-final { scan-lang-dump {Read:-[0-9]*'s named merge key \(new\) type_decl:'::va_list'} module } }
// { dg-final { scan-lang-dump {Read:-[0-9]*'s named merge key \(new\) type_decl:'::__gnuc_va_list'} module } }
c++: Incorrect type equivalence [PR 99496]
This bug was caused by not marking dependent template aliases
correctly -- these things look like typedefs, but are not
(necessarily) equivalent to the canonical type. We need to record that.
PR c++/99496
gcc/cp/
* module.cc (trees_out::decl_value): Adjust typedef streaming,
indicate whether it is a dependent alias.
(trees_in::decl_value): Likewise. Set as dependent alias, if it
is one.
gcc/testsuite/
* g++.dg/modules/pr99496_a.H: New.
* g++.dg/modules/pr99496_b.C: New.
--
Nathan Sidwell
diff --git c/gcc/cp/module.cc w/gcc/cp/module.cc
index 19bdfc7cb21..6dbdc926cb4 100644
--- c/gcc/cp/module.cc
+++ w/gcc/cp/module.cc
@@ -7719,18 +7719,35 @@ trees_out::decl_value (tree decl, depset *dep)
}
}
- bool is_typedef = (!type && inner
- && TREE_CODE (inner) == TYPE_DECL
- && DECL_ORIGINAL_TYPE (inner)
- && TYPE_NAME (TREE_TYPE (inner)) == inner);
- if (is_typedef)
+ bool is_typedef = false;
+ if (!type && inner && TREE_CODE (inner) == TYPE_DECL)
{
- /* A typedef type. */
- int type_tag = insert (TREE_TYPE (inner));
+ tree t = TREE_TYPE (inner);
+ unsigned tdef_flags = 0;
+ if (DECL_ORIGINAL_TYPE (inner)
+ && TYPE_NAME (TREE_TYPE (inner)) == inner)
+ {
+ tdef_flags |= 1;
+ if (TYPE_STRUCTURAL_EQUALITY_P (t)
+ && TYPE_DEPENDENT_P_VALID (t)
+ && TYPE_DEPENDENT_P (t))
+ tdef_flags |= 2;
+ }
if (streaming_p ())
- dump (dumper::TREE)
- && dump ("Cloned:%d typedef %C:%N", type_tag,
- TREE_CODE (TREE_TYPE (inner)), TREE_TYPE (inner));
+ u (tdef_flags);
+
+ if (tdef_flags & 1)
+ {
+ /* A typedef type. */
+ int type_tag = insert (t);
+ if (streaming_p ())
+ dump (dumper::TREE)
+ && dump ("Cloned:%d %s %C:%N", type_tag,
+ tdef_flags & 2 ? "depalias" : "typedef",
+ TREE_CODE (t), t);
+
+ is_typedef = true;
+ }
}
if (streaming_p () && DECL_MAYBE_IN_CHARGE_CDTOR_P (decl))
@@ -7993,12 +8010,6 @@ trees_in::decl_value ()
dump (dumper::TREE) && dump ("Read:%d %C:%N", tag, TREE_CODE (decl), decl);
- /* Regular typedefs will have a NULL TREE_TYPE at this point. */
- bool is_typedef = (!type && inner
- && TREE_CODE (inner) == TYPE_DECL
- && DECL_ORIGINAL_TYPE (inner)
- && !TREE_TYPE (inner));
-
existing = back_refs[~tag];
bool installed = install_entity (existing);
bool is_new = existing == decl;
@@ -8030,6 +8041,16 @@ trees_in::decl_value ()
}
}
+ /* Regular typedefs will have a NULL TREE_TYPE at this point. */
+ unsigned tdef_flags = 0;
+ bool is_typedef = false;
+ if (!type && inner && TREE_CODE (inner) == TYPE_DECL)
+{
+ tdef_flags = u ();
+ if (tdef_flags & 1)
+ is_typedef = true;
+}
+
if (is_new)
{
/* A newly discovered node. */
@@ -8076,6 +8097,14 @@ trees_in::decl_value ()
TREE_TYPE (inner) = DECL_ORIGINAL_TYPE (inner);
DECL_ORIGINAL_TYPE (inner) = NULL_TREE;
set_underlying_type (inner);
+ if (tdef_flags & 2)
+ {
+ /* Match instantiate_alias_template's handling. */
+ tree type = TREE_TYPE (inner);
+ TYPE_DEPENDENT_P (type) = true;
+ TYPE_DEPENDENT_P_VALID (type) = true;
+ SET_TYPE_STRUCTURAL_EQUALITY (type);
+ }
}
if (inner_tag)
@@ -10661,6 +10690,9 @@ trees_in::key_mergeable (int tag, merge_kind mk, tree decl, tree inner,
spec.tmpl = tree_node ();
spec.args = tree_node ();
+ if (get_overrun ())
+ return error_mark_node;
+
DECL_NAME (decl) = DECL_NAME (spec.tmpl);
DECL_CONTEXT (decl) = DECL_CONTEXT (spec.tmpl);
DECL_NAME (inner) = DECL_NAME (decl);
diff --git c/gcc/testsuite/g++.dg/modules/pr99496_a.H w/gcc/testsuite/g++.dg/modules/pr99496_a.H
new file mode 100644
index 000..71b77fbb49c
--- /dev/null
+++ w/gcc/testsuite/g++.dg/modules/pr99496_a.H
@@ -0,0 +1,17 @@
+// PR 99496 different types with same canonical
+// (requires spec hasher to be a constant, so we get collisions)
+// { dg-additional-options -fmodule-header }
+// { dg-module-cmi {} }
+
+template using __void_t = void;
+
+template
+struct __is_referenceable
+{ };
+
+template
+struct __is_referenceable<_Tp, __void_t<_Tp&>>
+{ };
+
+template::value>
+struct __is_copy_constructible_impl;
diff --git c/gcc/testsuite/g++.dg/modules/pr99496_b.C w/gcc/testsuite/g++.dg/modules/pr99496_b.C
new file mode 100644
index 000..57b71d13f54
--- /dev/null
+++ w/gcc/testsuite/g++.dg/modules/pr99496_b.C
@@ -0,0 +1,3 @@
+// { dg-additional-options {-fmodules-ts -fno-module-lazy} }
+
+import "pr99496_a.H";
[PATCH v3] c: don't drop typedef information in casts
The TYPE_MAIN_VARIANT() here was, for casts to a typedef'd type name,
resulting in all information about the typedef's involvement getting
lost. This drops necessary information for warnings and can make them
confusing or even misleading. It also makes specialized warnings for
unspecified-size system types (pid_t, uid_t, ...) impossible.
gcc/c/ChangeLog:
2021-03-09 David Lamparter
PR c/99526
* c-typeck.c (build_c_cast): retain (unqualified) typedefs in
casts rather than stripping down to basic type.
---
gcc/c/c-typeck.c| 39 ++---
gcc/testsuite/gcc.dg/cast-typedef.c | 35 ++
2 files changed, 71 insertions(+), 3 deletions(-)
create mode 100644 gcc/testsuite/gcc.dg/cast-typedef.c
diff --git a/gcc/c/c-typeck.c b/gcc/c/c-typeck.c
index 4e6d369c4c9c..c3c0d0c3cf55 100644
--- a/gcc/c/c-typeck.c
+++ b/gcc/c/c-typeck.c
@@ -5816,6 +5816,7 @@ c_safe_function_type_cast_p (tree t1, tree t2)
tree
build_c_cast (location_t loc, tree type, tree expr)
{
+ tree res_type, walk_type;
tree value;
bool int_operands = EXPR_INT_CONST_OPERANDS (expr);
@@ -5836,7 +5837,39 @@ build_c_cast (location_t loc, tree type, tree expr)
if (objc_is_object_ptr (type) && objc_is_object_ptr (TREE_TYPE (expr)))
return build1 (NOP_EXPR, type, expr);
+ /* Want to keep typedef information, but at the same time we need to strip
+ qualifiers for a proper rvalue. Unfortunately, we don't know if any
+ qualifiers on a typedef are part of the typedef or were locally supplied.
+ So grab the original typedef and use that only if it has no qualifiers.
+ cf. cast-typedef testcase */
+
+ res_type = NULL;
+
+ for (walk_type = type;
+ walk_type && TYPE_NAME (walk_type)
+ && TREE_CODE (TYPE_NAME (walk_type)) == TYPE_DECL;
+ walk_type = DECL_ORIGINAL_TYPE (TYPE_NAME (walk_type)))
+{
+ tree walk_unqual, orig_type, orig_decl;
+
+ walk_unqual = build_qualified_type (walk_type, TYPE_UNQUALIFIED);
+
+ orig_decl = lookup_name (TYPE_IDENTIFIER (walk_type));
+ if (!orig_decl || TREE_CODE (orig_decl) != TYPE_DECL)
+ continue;
+ orig_type = TREE_TYPE (orig_decl);
+
+ if (walk_unqual == orig_type)
+ {
+ res_type = walk_unqual;
+ break;
+ }
+}
+
type = TYPE_MAIN_VARIANT (type);
+ if (!res_type)
+res_type = type;
+ gcc_assert (TYPE_MAIN_VARIANT (res_type) == type);
if (TREE_CODE (type) == ARRAY_TYPE)
{
@@ -5864,7 +5897,7 @@ build_c_cast (location_t loc, tree type, tree expr)
"ISO C forbids casting nonscalar to the same type");
/* Convert to remove any qualifiers from VALUE's type. */
- value = convert (type, value);
+ value = convert (res_type, value);
}
else if (TREE_CODE (type) == UNION_TYPE)
{
@@ -6018,7 +6051,7 @@ build_c_cast (location_t loc, tree type, tree expr)
" from %qT to %qT", otype, type);
ovalue = value;
- value = convert (type, value);
+ value = convert (res_type, value);
/* Ignore any integer overflow caused by the cast. */
if (TREE_CODE (value) == INTEGER_CST && !FLOAT_TYPE_P (otype))
@@ -6054,7 +6087,7 @@ build_c_cast (location_t loc, tree type, tree expr)
&& INTEGRAL_TYPE_P (TREE_TYPE (expr)))
|| TREE_CODE (expr) == REAL_CST
|| TREE_CODE (expr) == COMPLEX_CST)))
- value = build1 (NOP_EXPR, type, value);
+ value = build1 (NOP_EXPR, res_type, value);
/* If the expression has integer operands and so can occur in an
unevaluated part of an integer constant expression, ensure the
diff --git a/gcc/testsuite/gcc.dg/cast-typedef.c b/gcc/testsuite/gcc.dg/cast-typedef.c
new file mode 100644
index ..3058e5a0b190
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/cast-typedef.c
@@ -0,0 +1,35 @@
+/* Test cast <> typedef interactions */
+/* Origin: David Lamparter */
+/* { dg-do compile } */
+/* { dg-options "-Wconversion" } */
+
+typedef int typedefname;
+typedef volatile int qual1;
+typedef volatile typedefname qual2;
+
+extern int val;
+extern void f2(unsigned char arg);
+
+void
+f (void)
+{
+ /* -Wconversion just used to print out the actual type */
+
+ f2 ((typedefname) val); /* { dg-warning "typedefname" } */
+ f2 ((volatile typedefname) val); /* { dg-warning "typedefname" } */
+ f2 ((qual1) val); /* { dg-warning "int" } */
+ f2 ((qual2) val); /* { dg-warning "typedefname" } */
+
+ /* { dg-bogus "volatile" "qualifiers should be stripped" { target { "*-*-*" } } 19 } */
+ /* { dg-bogus "volatile" "qualifiers should be stripped" { target { "*-*-*" } } 20 } */
+ /* { dg-bogus "volatile" "qualifiers should be stripped" { target { "*-*-*" } } 21 } */
+
+ /* { dg-bogus "qual1" "typedef with qualifier should not be used" { target { "*-*-*" } } 20 } */
+ /* { dg-bogus "qual2" "typedef with qualifier should not be used" { target { "*-*-*" } } 21 } */
+
+ /* shadow "typedefname" & make sure it's not used */
+ typedef
Re: [PATCH v2] c: don't drop typedef information in casts
On Fri, Mar 12, 2021 at 09:35:44AM +0100, Jakub Jelinek wrote:
> On Fri, Mar 12, 2021 at 04:08:17AM +0100, David Lamparter wrote:
> >
> > The TYPE_MAIN_VARIANT() here was, for casts to a typedef'd type name,
> > resulting in all information about the typedef's involvement getting
> > lost. This drops necessary information for warnings and can make them
> > confusing or even misleading. It also makes specialized warnings for
> > unspecified-size system types (pid_t, uid_t, ...) impossible.
>
> I don't think you can/should do the lookup_name calls in build_c_cast,
> that just can't be right. The lookups need to be done only when parsing
> the typedefs.
I don't have enough understanding of the GCC codebase to be able to make
a more complex change than this, but your feedback gave me another idea:
> Because, one certainly can have e.g.
> typedef ... A;
> typedef A ... B; // with some extra qualifiers or whatever
> void
> foo (void)
> {
> typedef ... A; // Override in local scope A but not B
> ... = (B) ...; // build_c_cast called
> }
> You don't want to find the overridden A, you need the original one.
... I could simply check the lookup result for equality against the type
being iterated over (without its qualifiers). While this means that
shadowed types like in your example will be skipped, this knda makes
sense from a user perspective since there wouldn't be a distinguisher in
the report.
Patch following up to this mail. It still does the lookup in
build_c_cast, do you think this altered approach is acceptable?
Cheers,
-David
Re: [RFC][patch for gcc12][version 1] add -ftrivial-auto-var-init and variable attribute "uninitialized" to gcc
(CC’ing gcc-patch alias).
Hi, Kees,
> On Mar 12, 2021, at 3:55 PM, Kees Cook wrote:
>
> On Fri, Mar 12, 2021 at 03:35:28PM -0600, Qing Zhao wrote:
>> Hi, Kees,
>>
>> I am looking at the structure padding initialization issue. And also have
>> some questions:
>>
>>
>>> On Feb 24, 2021, at 10:41 PM, Kees Cook wrote:
>>>
>>> It looks like there is still some issues with padding and pre-case
>>> switch variables. Here's the test output, FWIW:
>>>
>>>
>>> test_stackinit: small_hole_static_all FAIL (uninit bytes: 3)
>>> test_stackinit: big_hole_static_all FAIL (uninit bytes: 61)
>>> test_stackinit: trailing_hole_static_all FAIL (uninit bytes: 7)
>>> test_stackinit: small_hole_dynamic_all FAIL (uninit bytes: 3)
>>> test_stackinit: big_hole_dynamic_all FAIL (uninit bytes: 61)
>>> test_stackinit: trailing_hole_dynamic_all FAIL (uninit bytes: 7)
>>>
>>> test_stackinit: switch_1_none FAIL (uninit bytes: 8)
>>> test_stackinit: switch_2_none FAIL (uninit bytes: 8)
>>> test_stackinit: failures: 8
>>>
>>>
>>> /* Simple structure with padding likely to be covered by compiler. */
>>> struct test_small_hole {
>>> size_t one;
>>> char two;
>>> /* 3 byte padding hole here. */
>>> int three;
>>> unsigned long four;
>>> };
>>>
>>> /* Try to trigger unhandled padding in a structure. */
>>> struct test_aligned {
>>> u32 internal1;
>>> u64 internal2;
>>> } __aligned(64);
>>>
>>> struct test_big_hole {
>>> u8 one;
>>> u8 two;
>>> u8 three;
>>> /* 61 byte padding hole here. */
>>> struct test_aligned four;
>>> } __aligned(64);
>>>
>>> struct test_trailing_hole {
>>> char *one;
>>> char *two;
>>> char *three;
>>> char four;
>>> /* "sizeof(unsigned long) - 1" byte padding hole here. */
>>> };
>>>
>>> They fail when they're statically initialized (either fully or
>>> partially),
>>
>> So, when the structure is not statically initialized, the compiler
>> initialization is good?
>>
>> For the failing cases, what’s the behavior of the LLVM
>> -ftrivial-auto-var-init?
>>
>> From the LLVM patch: (https://reviews.llvm.org/D54604
>> )
>>
>>
>> To keep the patch simple, only some undef is removed for now, see
>> replaceUndef. The padding-related infoleaks are therefore not all gone yet.
>> This will be addressed in a follow-up, mainly because addressing
>> padding-related
>> leaks should be a stand-alone option which is implied by variable
>> initialization.
>>
>
> Right, padding init happened in:
> https://github.com/llvm/llvm-project/commit/4f7bc0eee7e6099b1abd57dac3c83529944ab23c
>
> And was further clarified that, IIUC, padding _must be zero_ regardless
> of pattern-vs-zero in:
> https://github.com/llvm/llvm-project/commit/d39fbc7e20d84364e409ce59724ce20625637062
Thanks a lot for the above information, they are very useful.
I will take a look at the LLVM patch and try to implement this feature into GCC
as well.
>
>> Yes, in GCC’s implementation, I think that fixing all padding-related leaks
>> also require a
>> separate patch.
>
> That's fine -- but it'll need to be tied to -ftrivial-auto-var-init,
> since otherwise the memory isn't actually fully initialized. :)
Okay, will do that.
Thanks again.
Qing
>
> -Kees
>
> --
> Kees Cook
Re: [PATCH] coroutines: Correct frame capture of compiler temps [PR95591+4].
Iain Sandoe wrote:
Iain Sandoe wrote:
Jason Merrill wrote:
I notice this patch includes
+ var_nest_node () = default;
which will break GCC 10 bootstrap with a C++98 compiler; we only
switched to C++11 for GCC 11.
Hmm, the patch was already backported…
… I will fix this.
I missed the warning during testing.
We set -std=gnu++98 for the stage1 compiler, which does warn about this
(although there
is a lot of warning output from a bootstrap, it’s easy to miss one).
I’m mostly bootstrapping with GCC-7.5 and it appears that this does not
actually produce
any error even if one actually uses the defaulted ctor (at least in a
trivial test).
= anyway ….
OK for gcc-10?
Nathan acked this on IRC, so I pushed now.
thanks
Iain
this removes the warning from the stage #1.
thanks
Iain
==
[PATCH] coroutines : Avoid a C++11ism.
The master version of the code uses a defaulted CTOR, which had
been inadvertently backported to gcc-10. Fixed thus.
gcc/cp/ChangeLog:
* coroutines.cc (struct var_nest_node): Provide a default
CTOR.
---
gcc/cp/coroutines.cc | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/gcc/cp/coroutines.cc b/gcc/cp/coroutines.cc
index 9133f024434..4902d1a4c4f 100644
--- a/gcc/cp/coroutines.cc
+++ b/gcc/cp/coroutines.cc
@@ -2697,7 +2697,9 @@ find_interesting_subtree (tree *expr_p, int *dosub,
void *d)
struct var_nest_node
{
- var_nest_node () = default;
+ var_nest_node ()
+: var(NULL_TREE), init(NULL_TREE),
+ prev(NULL), next(NULL), then_cl(NULL), else_cl(NULL) {}
var_nest_node (tree v, tree i, var_nest_node *p, var_nest_node *n)
: var(v), init(i), prev(p), next(n)
{
--
2.24.1
Re: [arm/testsuite]: Skip pr97969.c if -mthumb is not compatible [PR target/97969]
On Wed, 3 Mar 2021 at 15:00, Richard Earnshaw
wrote:
>
> On 02/03/2021 18:35, Christophe Lyon wrote:
> > On Tue, 2 Mar 2021 at 19:18, Richard Earnshaw
> > wrote:
> >>
> >> On 02/03/2021 18:14, Richard Earnshaw via Gcc-patches wrote:
> >>> On 02/03/2021 18:10, Christophe Lyon wrote:
> On Tue, 2 Mar 2021 at 17:25, Richard Earnshaw
> wrote:
> >
> > On 02/03/2021 16:19, Richard Earnshaw via Gcc-patches wrote:
> >> On 01/03/2021 15:26, Christophe Lyon via Gcc-patches wrote:
> >>> Ping?
> >>>
> >>> On Wed, 3 Feb 2021 at 10:01, Christophe Lyon
> >>> wrote:
>
> Ping?
> I guess that's obvious enough?
>
> On Wed, 27 Jan 2021 at 10:03, Christophe Lyon
> wrote:
> >
> > Depending on how the toolchain is configured or how the testsuite is
> > executed, -mthumb may not be compatible. Like for other tests, skip
> > pr97969.c in this case.
> >
> > For instance arm-linux-gnueabihf and -march=armv5t in RUNTESTFLAGS.
> >
> > 2021-01-27 Christophe Lyon
> >
> > gcc/testsuite/
> > PR target/97969
> > * gcc.target/arm/pr97969.c: Skip if thumb mode is not available.
> >
> > diff --git a/gcc/testsuite/gcc.target/arm/pr97969.c
> > b/gcc/testsuite/gcc.target/arm/pr97969.c
> > index 714a1d1..0b5d07f 100644
> > --- a/gcc/testsuite/gcc.target/arm/pr97969.c
> > +++ b/gcc/testsuite/gcc.target/arm/pr97969.c
> > @@ -1,4 +1,5 @@
> > /* { dg-do compile } */
> > +/* { dg-skip-if "" { ! { arm_thumb1_ok || arm_thumb2_ok } } } */
> > /* { dg-options "-std=c99 -fno-omit-frame-pointer -mthumb -w -Os"
> > } */
> >
> > typedef a[23];
> >>
> >> I'm working on a patch to make this sort of change unnecessary (I
> >> hope).
> >> Just running some final checks.
> >>
> >> R.
> >>
> >
> > Ah, wait. This one already has an explicit -mthumb, so my patch won't
> > affect this. But why is -mthumb needed for this test anyway? It's just
> > a compilation test, so why not drop that and we'll generally get better
> > coverage all round.
> >
>
> For instance I see the test fail for target arm-none-linux-gnueabihf
> --with-mode arm --with-cpu cortex-a9 --with-fpu vfp
> and running the tests with -march=armv5t
>
> We get the famous thumb-1 + hard-float ABI not supported.
>
> I guess -mthumb is inherited from the bug report?
>
> Christophe
>
> >>>
> >>> dropping the -mthumb should fix that though?
> >>>
> >>> In fact, I'd drop -Os as well, it's not needed as -Os is just one of the
> >>> many options that are used to build this test already.
> >>>
> >>> R.
> >>>
> >>
> >> But maybe then we need to change dg-options into dg-add-options.
> >>
> >
> > Not sure to follow: the test is compiled only once, with:
> > -std=c99 -fno-omit-frame-pointer -mthumb -w -Os
> > in my logs
> >
>
> I think it's only run the once /because/ the test sets dg-options rather
> than dg-add-options.
>
Hi, sorry for the delay...
I guess you mean dg-additional-options ?
I did try that, to be sure, but the tests in gcc.target/arm are only
compiled once.
Back to the original discussion, if we drop -mthumb, which is required
according to the PR (?), how do we ensure coverage? Sure I'm running
the testsuite with various RUNTESTFLAGS settings, but wouldn't it be
better to test what the PR reports by default?
Thanks
Christophe
.
Re: [PATCH] fwprop: Fix single_use_p calculation
On 02/03/2021 23:37, Ilya Leoshkevich wrote:
> Bootstrapped and regtested on x86_64-redhat-linux, ppc64le-redhat-linux
> and s390x-redhat-linux. Ok for master?
>
>
>
> Commit efb6bc55a93a ("fwprop: Allow (subreg (mem)) simplifications")
> introduced a check that was supposed to look at the propagated def's
> number of uses. It uses insn_info::num_uses (), which in reality
> returns the number of uses def's insn has. The whole change therefore
> works only by accident.
>
> Fix by looking at def_info's uses instead of insn_info's uses. This
> requires passing around def_info instead of insn_info.
>
If building glibc on s390x with -march=z14, there is currently an extra
"unneeded" stackframe in e.g. sqrtl, llroundl, lroundl, llrintl, llrint
and roundevenl.
<__ieee754_sqrtl>:
0: b3 c1 00 4f ldgr%f4,%r15
4: e3 f0 ff 50 ff 71 lay %r15,-176(%r15)
a: e3 00 f0 a8 00 20 cg %r0,168(%r15)
# The long double argument is loaded ...
10: e7 00 30 00 30 06 vl %v0,0(%r3),3
# ... stored to extra "unneeded" stackframe ...
16: e7 00 f0 a0 30 0e vst %v0,160(%r15),3
# ... and loaded from there into a floating-point-pair
1c: 68 00 f0 a0 ld %f0,160(%r15)
20: 68 20 f0 a8 ld %f2,168(%r15)
24: b3 16 00 00 sqxbr %f0,%f0
28: 60 00 20 00 std %f0,0(%r2)
2c: 60 20 20 08 std %f2,8(%r2)
30: b3 cd 00 f4 lgdr%r15,%f4
34: 07 fe br %r14
With this patch, there is no stackframe in those functions anymore as it
was if build with gcc 10.
<__ieee754_sqrtl>:
0: 68 00 30 00 ld %f0,0(%r3)
4: 68 20 30 08 ld %f2,8(%r3)
8: b3 16 00 00 sqxbr %f0,%f0
c: 60 00 20 00 std %f0,0(%r2)
10: 60 20 20 08 std %f2,8(%r2)
14: 07 fe br %r14
Thanks,
Stefan
[PATCH] tree-optimization/98834 - fix optimization regression with _b_c_p
The following makes FRE optimize a load we formerly required
SRA + CCP for which now run after we get rid of all __builtin_constant_p
calls.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
2021-03-15 Richard Biener
PR tree-optimization/98834
* tree-ssa-sccvn.c (vn_reference_lookup_3): Handle missing
subsetting by truncating the access size.
* g++.dg/opt/pr98834.C: New testcase.
---
gcc/testsuite/g++.dg/opt/pr98834.C | 71 ++
gcc/tree-ssa-sccvn.c | 12 -
2 files changed, 82 insertions(+), 1 deletion(-)
create mode 100644 gcc/testsuite/g++.dg/opt/pr98834.C
diff --git a/gcc/testsuite/g++.dg/opt/pr98834.C
b/gcc/testsuite/g++.dg/opt/pr98834.C
new file mode 100644
index 000..fafd3227181
--- /dev/null
+++ b/gcc/testsuite/g++.dg/opt/pr98834.C
@@ -0,0 +1,71 @@
+/* { dg-do compile } */
+/* { dg-require-effective-target c++17 } */
+/* { dg-options "-O2 -fdump-tree-fre3" } */
+
+struct _Base
+{
+ int _M_data = 0;
+};
+
+struct _Wrapper : _Base
+{
+ _Wrapper(int) {}
+
+ bool _M_is_constprop() { return __builtin_constant_p(_M_data); }
+};
+
+struct _Impl
+{
+ _Wrapper _S_multiplies(_Wrapper __x, _Wrapper __y)
+ {
+if (__x._M_is_constprop() || __y._M_is_constprop())
+ return __y;
+return 0;
+ }
+};
+
+struct _TupleData
+{
+ _Wrapper first;
+ int second;
+};
+
+struct _Tuple : _TupleData
+{
+ template
+_Tuple _M_apply_per_chunk(_Fp __fun, _Tuple __y)
+{
+ return {__fun(first, __y.first), second};
+}
+};
+
+struct _ImplFixed
+{
+ static _Tuple _S_multiplies(_Tuple __x, _Tuple __y)
+ {
+return __x._M_apply_per_chunk(
+ []( auto __xx, auto __yy) {
+ return _Impl()._S_multiplies(__xx, __yy);
+ },
+ __y);
+ }
+};
+
+class simd
+{
+public:
+ [[__gnu__::__always_inline__]] friend simd operator*(simd __x, simd __y)
+ { return _ImplFixed::_S_multiplies(__x._M_data, __y._M_data); }
+
+ simd(_Tuple __init) : _M_data(__init) {}
+
+ _Tuple _M_data;
+};
+
+int main()
+{
+ simd({0, 0}) * simd({0, 0});
+}
+
+/* FRE3 should elide all conditionals in the remaining main. */
+/* { dg-final { scan-tree-dump-times "size, r.size))
- return (void *)-1;
+ {
+ /* If the access lacks some subsetting simply apply that by
+shortening it. That in the end can only be successful
+if we can pun the lookup result which in turn requires
+exact offsets. */
+ if (known_eq (r.size, r.max_size)
+ && known_lt (ref->size, r.size))
+ r.size = r.max_size = ref->size;
+ else
+ return (void *)-1;
+ }
*ref = r;
/* Do not update last seen VUSE after translating. */
--
2.26.2
Re: [Ada] Fix PR ada/99264
> The change is supposed to be binary compatible so not sure what this > means. Our problem is related with distribution, not with a specific library or its ABI. Imagine that: $VENDOR1 builds GNAT without the fix. $VENDOR2 builds libfoo against GNAT. $administrator installs both. I write bar.adb using foo.adb. $VENDOR1 rebuilds GNAT with the fix modifying s-osinte__linux.ads and s-osinte.ali. $administrator updates GNAT. My next attempt to rebuild bar.adb fails. GNAT (correctly) reports that foo.ali is obsolete and should be rebuilt against the updated s-osinte.ali. I don’t understand the problem because I have never heard of s-osinte.ali. The error happens while building bar.adb, the message mentions libfoo, but the problem originates in an unrelated GNAT update. Even if I did, I could not apply the right fix ($VENDOR2 should rebuild libfoo fory all users). Here VENDOR1=VENDOR2=administrator=Debian wants to prevent this scenario for end users. We must choose to revert the patch or rebuild most Ada packages (the error may affects any recursive dependency of libgnat…). Currently, a stable release is in preparation so the second option has a much higher price.
[Patch, fortran] PR99545 [11 Regression] ICE in gfc_trans_assignment since r11-6253-gce8dcc9105cbd404
Applied to all three branches, after regtesting on each, as blindingly obvious. The testcase is the reduced version in comment #6 of the PR. Paul Fortran: Fix problem with allocate initialization [PR99545]. 2021-03-15 Paul Thomas gcc/fortran/ChangeLog PR fortran/99545 * trans-stmt.c (gfc_trans_allocate): Mark the initialization assignment by setting init_flag. gcc/testsuite/ChangeLog PR fortran/99545 * gfortran.dg/pr99545.f90: New test. diff --git a/gcc/fortran/trans-stmt.c b/gcc/fortran/trans-stmt.c index 547468f7648..7cbdef7a304 100644 --- a/gcc/fortran/trans-stmt.c +++ b/gcc/fortran/trans-stmt.c @@ -7001,7 +7001,7 @@ gfc_trans_allocate (gfc_code * code) gfc_expr *init_expr = gfc_expr_to_initialize (expr); gfc_expr *rhs = e3rhs ? e3rhs : gfc_copy_expr (code->expr3); flag_realloc_lhs = 0; - tmp = gfc_trans_assignment (init_expr, rhs, false, false, true, + tmp = gfc_trans_assignment (init_expr, rhs, true, false, true, false); flag_realloc_lhs = realloc_lhs; /* Free the expression allocated for init_expr. */
Re: [PATCH] libstdc++: Implement missing operator overloads in max_size_type.h
On 15/03/21 10:18 -0400, Patrick Palka via Libstdc++ wrote: This implements operator++, operator-- and operator<=> for the integer-class types defined in max_size_type.h, which I overlooked when originally implementing the class. Tested on x86_64-pc-linux-gnu, does this look OK for trunk? OK, thanks.
[PATCH] libstdc++: Implement missing operator overloads in max_size_type.h
This implements operator++, operator-- and operator<=> for the
integer-class types defined in max_size_type.h, which I overlooked
when originally implementing the class.
Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
libstdc++-v3/ChangeLog:
* include/bits/max_size_type.h (__max_size_type::operator _Tp):
Fix formatting.
(__max_size_type::operator++): Define.
(__max_size_type::operator--): Likewise.
(__max_size_type::operator<=>): Conditionally define (in place
of the other comparison operators).
(__max_diff_type::operator _Tp): Fix formatting.
(__max_diff_type::operator++): Define.
(__max_diff_type::operator--): Likewise.
(__max_diff_type::operator<=>): Conditionally define (in place
of the other comparison operators).
* testsuite/std/ranges/iota/max_size_type.cc (test01): Test
these operator overloads.
---
libstdc++-v3/include/bits/max_size_type.h | 78 ++-
.../std/ranges/iota/max_size_type.cc | 36 +
2 files changed, 112 insertions(+), 2 deletions(-)
diff --git a/libstdc++-v3/include/bits/max_size_type.h
b/libstdc++-v3/include/bits/max_size_type.h
index 05984a30f1d..27d63797c49 100644
--- a/libstdc++-v3/include/bits/max_size_type.h
+++ b/libstdc++-v3/include/bits/max_size_type.h
@@ -71,7 +71,8 @@ namespace ranges
__max_size_type(const __max_diff_type& __d) noexcept;
template requires integral<_Tp> || __is_int128<_Tp>
- constexpr explicit operator _Tp() const noexcept
+ constexpr explicit
+ operator _Tp() const noexcept
{ return _M_val; }
constexpr explicit
@@ -90,6 +91,30 @@ namespace ranges
operator-() const noexcept
{ return operator~() + 1; }
+ constexpr __max_size_type&
+ operator++() noexcept
+ { return *this += 1; }
+
+ constexpr __max_size_type
+ operator++(int) noexcept
+ {
+ auto __tmp = *this;
+ ++*this;
+ return __tmp;
+ }
+
+ constexpr __max_size_type&
+ operator--() noexcept
+ { return *this -= 1; }
+
+ constexpr __max_size_type
+ operator--(int) noexcept
+ {
+ auto __tmp = *this;
+ --*this;
+ return __tmp;
+ }
+
constexpr __max_size_type&
operator+=(const __max_size_type& __r) noexcept
{
@@ -355,6 +380,16 @@ namespace ranges
operator==(const __max_size_type& __l, const __max_size_type& __r)
noexcept
{ return __l._M_val == __r._M_val && __l._M_msb == __r._M_msb; }
+#if __cpp_lib_three_way_comparison
+ friend constexpr strong_ordering
+ operator<=>(const __max_size_type& __l, const __max_size_type& __r)
noexcept
+ {
+ if (__l._M_msb ^ __r._M_msb)
+ return __l._M_msb ? strong_ordering::greater : strong_ordering::less;
+ else
+ return __l._M_val <=> __r._M_val;
+ }
+#else
friend constexpr bool
operator!=(const __max_size_type& __l, const __max_size_type& __r)
noexcept
{ return !(__l == __r); }
@@ -379,6 +414,7 @@ namespace ranges
friend constexpr bool
operator>=(const __max_size_type& __l, const __max_size_type& __r)
noexcept
{ return __r <= __l; }
+#endif
#if __SIZEOF_INT128__
using __rep = unsigned __int128;
@@ -417,7 +453,8 @@ namespace ranges
{ }
template requires integral<_Tp> || __is_int128<_Tp>
- constexpr explicit operator _Tp() const noexcept
+ constexpr explicit
+ operator _Tp() const noexcept
{ return static_cast<_Tp>(_M_rep); }
constexpr explicit
@@ -436,6 +473,30 @@ namespace ranges
operator~() const noexcept
{ return __max_diff_type(~_M_rep); }
+ constexpr __max_diff_type&
+ operator++() noexcept
+ { return *this += 1; }
+
+ constexpr __max_diff_type
+ operator++(int) noexcept
+ {
+ auto __tmp = *this;
+ ++*this;
+ return __tmp;
+ }
+
+ constexpr __max_diff_type&
+ operator--() noexcept
+ { return *this -= 1; }
+
+ constexpr __max_diff_type
+ operator--(int) noexcept
+ {
+ auto __tmp = *this;
+ --*this;
+ return __tmp;
+ }
+
constexpr __max_diff_type&
operator+=(const __max_diff_type& __r) noexcept
{
@@ -647,6 +708,18 @@ namespace ranges
operator==(const __max_diff_type& __l, const __max_diff_type& __r)
noexcept
{ return __l._M_rep == __r._M_rep; }
+#if __cpp_lib_three_way_comparison
+ constexpr strong_ordering
+ operator<=>(const __max_diff_type& __r) const noexcept
+ {
+ const auto __lsign = _M_rep._M_msb;
+ const auto __rsign = __r._M_rep._M_msb;
+ if (__lsign ^ __rsign)
+ return __lsign ? strong_ordering::less : strong_ordering::greater;
+ else
+ return _M_rep <=> __r._M_rep;
+ }
+#else
friend constexpr bool
operator!=(const
Re: [PATCH] c++: Prune dead functions.
On Mon, Mar 15, 2021 at 08:31:09AM -0400, Nathan Sidwell wrote: > On 3/11/21 3:58 PM, Marek Polacek via Gcc-patches wrote: > > I was looking at the LCOV coverage report for the C++ FE and > > found a bunch of unused functions that I think we can remove. > > Obviously, I left alone various dump_* and debug_* routines. > > I haven't removed cp_build_function_call although it is also > > currently unused. > > > > * lambda_return_type: was used in parser.c in GCC 7, unused since r255950, > > * classtype_has_non_deleted_copy_ctor: appeared in GCC 10, its usage > >was removed in c++/95350, > > * contains_wildcard_p: used in GCC 9, unused since r276764, > > * get_template_head_requirements: seems to never have been used, > > * check_constrained_friend: seems to never have been used, > > * subsumes_constraints: unused since r276764, > > * push_void_library_fn: usage removed in r248328, > > * get_template_parms_at_level: unused since r157857, > > * get_pattern_parm: unused since r275387. > > > > (Some of the seemingly unused functions, such as set_global_friend, are > > actually used in libcc1.) > > > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? > > Stage 1 stuff, IMHO Works for me, will defer. Marek
Re: [PATCH] GCC_CET_HOST_FLAGS: Check if host supports multi-byte NOPs
On Sun, Feb 14, 2021 at 9:26 AM H.J. Lu wrote:
>
> Check if host supports multi-byte NOPs before enabling CET on host.
>
> config/
>
> PR binutils/27397
> * cet.m4 (GCC_CET_HOST_FLAGS): Check if host supports multi-byte
> NOPs.
>
> libiberty/
>
> PR binutils/27397
> * configure: Regenerated.
> ---
> config/cet.m4 | 19 ---
> libiberty/configure | 29 +
> 2 files changed, 45 insertions(+), 3 deletions(-)
>
> diff --git a/config/cet.m4 b/config/cet.m4
> index c67fb4f35b6..7718be1afe8 100644
> --- a/config/cet.m4
> +++ b/config/cet.m4
> @@ -130,6 +130,18 @@ fi
> if test x$may_have_cet = xyes; then
>if test x$cross_compiling = xno; then
> AC_TRY_RUN([
> +int
> +main ()
> +{
> + asm ("endbr32");
> + return 0;
> +}
> +],
> +[have_multi_byte_nop=yes],
> +[have_multi_byte_nop=no])
> +have_cet=no
> +if test x$have_multi_byte_nop = xyes; then
> + AC_TRY_RUN([
> static void
> foo (void)
> {
> @@ -155,9 +167,10 @@ main ()
>bar ();
>return 0;
> }
> -],
> -[have_cet=no],
> -[have_cet=yes])
> + ],
> + [have_cet=no],
> + [have_cet=yes])
> +fi
> if test x$enable_cet = xno -a x$have_cet = xyes; then
>AC_MSG_ERROR([Intel CET must be enabled on Intel CET enabled host])
> fi
> diff --git a/libiberty/configure b/libiberty/configure
> index 160b8c9e8b1..29a690d44fc 100755
> --- a/libiberty/configure
> +++ b/libiberty/configure
> @@ -5539,6 +5539,34 @@ else
>cat confdefs.h - <<_ACEOF >conftest.$ac_ext
> /* end confdefs.h. */
>
> +int
> +main ()
> +{
> + asm ("endbr32");
> + return 0;
> +}
> +
> +_ACEOF
> +if ac_fn_c_try_run "$LINENO"; then :
> + have_multi_byte_nop=yes
> +else
> + have_multi_byte_nop=no
> +fi
> +rm -f core *.core core.conftest.* gmon.out bb.out conftest$ac_exeext \
> + conftest.$ac_objext conftest.beam conftest.$ac_ext
> +fi
> +
> +have_cet=no
> +if test x$have_multi_byte_nop = xyes; then
> + if test "$cross_compiling" = yes; then :
> + { { $as_echo "$as_me:${as_lineno-$LINENO}: error: in \`$ac_pwd':" >&5
> +$as_echo "$as_me: error: in \`$ac_pwd':" >&2;}
> +as_fn_error $? "cannot run test program while cross compiling
> +See \`config.log' for more details" "$LINENO" 5; }
> +else
> + cat confdefs.h - <<_ACEOF >conftest.$ac_ext
> +/* end confdefs.h. */
> +
> static void
> foo (void)
> {
> @@ -5575,6 +5603,7 @@ rm -f core *.core core.conftest.* gmon.out bb.out
> conftest$ac_exeext \
>conftest.$ac_objext conftest.beam conftest.$ac_ext
> fi
>
> +fi
> if test x$enable_cet = xno -a x$have_cet = xyes; then
>as_fn_error $? "Intel CET must be enabled on Intel CET enabled host"
> "$LINENO" 5
> fi
> --
> 2.29.2
>
If there are no objections, I will check it in on Wednesday.
--
H.J.
Re: [PATCH] c++: Prune dead functions.
On 3/11/21 3:58 PM, Marek Polacek via Gcc-patches wrote: I was looking at the LCOV coverage report for the C++ FE and found a bunch of unused functions that I think we can remove. Obviously, I left alone various dump_* and debug_* routines. I haven't removed cp_build_function_call although it is also currently unused. * lambda_return_type: was used in parser.c in GCC 7, unused since r255950, * classtype_has_non_deleted_copy_ctor: appeared in GCC 10, its usage was removed in c++/95350, * contains_wildcard_p: used in GCC 9, unused since r276764, * get_template_head_requirements: seems to never have been used, * check_constrained_friend: seems to never have been used, * subsumes_constraints: unused since r276764, * push_void_library_fn: usage removed in r248328, * get_template_parms_at_level: unused since r157857, * get_pattern_parm: unused since r275387. (Some of the seemingly unused functions, such as set_global_friend, are actually used in libcc1.) Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? Stage 1 stuff, IMHO gcc/cp/ChangeLog: * class.c (classtype_has_non_deleted_copy_ctor): Remove. * constraint.cc (contains_wildcard_p): Likewise. (get_template_head_requirements): Likewise. (check_constrained_friend): Likewise. (subsumes_constraints): Likewise. * cp-tree.h (classtype_has_non_deleted_copy_ctor): Likewise. (push_void_library_fn): Likewise. (get_pattern_parm): Likewise. (get_template_parms_at_level): Likewise. (lambda_return_type): Likewise. (get_template_head_requirements): Likewise. (check_constrained_friend): Likewise. (subsumes_constraints): Likewise. * decl.c (push_void_library_fn): Likewise. * lambda.c (lambda_return_type): Likewise. * pt.c (get_template_parms_at_level): Likewise. (get_pattern_parm): Likewise. -- Nathan Sidwell
Re: [PATCH v1] libstdc++-v3: Update VTV vars for libtool link commands [PR99172]
On 12/03/21 15:33 -0800, Caroline Tice wrote: I have updated the patch as you suggested, to filter the "-fvtable-verify=std" out of AM_CXXFLAGS, and I have verified that it passes the testsuite with no regressions and fixes the reported bug. This means we also don't pass it to LTCXXCOMPILE, instead of just removing it from CXXLINK as in the original patch. Since I have never understood what libtool is for, I don't really know if that's OK, but if it works then it works. Is this OK to commit now? OK, thanks. -- Caroline Tice cmt...@google.com libstdc++-v3/ChangeLog 2021-03-12 Caroline Tice PR libstdc++/99172 * src/Makefile.am (AM_CXXFLAGS_PRE, AM_CXXFLAGS): Add AM_CXXFLAGS_PRE with the old definition of AM_CXXFLAGS; make AM_CXXFLAGS to be AM_CXXFLAGS_PRE with '-fvtable-verify=std' filtered out. * src/Makefile.in: Regenerate. -- Caroline cmt...@google.com On Thu, Mar 11, 2021 at 9:10 AM Jonathan Wakely wrote: On 11/03/21 17:46 +0100, Jakub Jelinek via Libstdc++ wrote: >On Thu, Mar 11, 2021 at 04:31:51PM +, Jonathan Wakely via Gcc-patches wrote: >> On 11/03/21 16:27 +, Jonathan Wakely wrote: >> > That seems cleaner to me, rather than adding another variable with >> > minor differences from the existing AM_CXXFLAGS. >> >> My specific concern is that AM_CXXFLAGS and AM_CXXFLAGS_LT will get >> out of sync, i.e. we'll add something to the former and forget to add >> it to the latter. >> >> If we keep using AM_CXXFLAGS but cancel out the -fvtable-verify=std >> option, then there aren't two separate variables that can diverge. >> >> But I think it's too late in the gcc-11 process for that kind of >> refactoring. > >I think $(filter-out -fvtable-verify=std,$(AM_CXXFLAGS)) should be fairly >simple thing if that is all that needs to be done. Yes, we could do that now, and then in stage 1 look at the other changes (like moving -Wl,-u options to the link flags not cxxflags). Using filter-out does assume that no target is going to add anything different that should also be filtered out, but that's true as of today.
Re: [PATCH] analyzer: fix missing comma in initializer
On Mon, 2021-03-15 at 09:32 +0100, Martin Liška wrote: > Fixes the following valid clang warning: > > gcc/analyzer/sm-file.cc:250:5: warning: suspicious concatenation of > string literals in an array initialization; > did you mean to separate the elements with a comma? [-Wstring- > concatenation] > > Survives make check -k RUNTESTFLAGS="analyzer.exp". > > Ready to be installed? > Thanks, > Martin LGTM Thanks Dave > gcc/analyzer/ChangeLog: > > * sm-file.cc (get_file_using_fns): Add missing comma in > initializer. > --- > gcc/analyzer/sm-file.cc | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/gcc/analyzer/sm-file.cc b/gcc/analyzer/sm-file.cc > index 48ef4aa2334..7a81c8ff632 100644 > --- a/gcc/analyzer/sm-file.cc > +++ b/gcc/analyzer/sm-file.cc > @@ -246,7 +246,7 @@ get_file_using_fns () > "__fbufsize", > "__flbf", > "__fpending", > - "__fpurge" > + "__fpurge", > "__freadable", > "__freading", > "__fsetlocking",
Re: [PATCH] libstdc++, Darwin, ppc : Add new long double symbols.
On 15/03/21 00:34 +, Iain Sandoe wrote: Hi We need to add the symbols for to_chars and from_chars for the long double cases. The testsuite test cases fail to build without this, so there’s no need for an additional test. Tested on powerpc-darwin9. OK for master? OK, thanks. thanks Iain libstdc++-v3/ChangeLog: * config/os/bsd/darwin/ppc-extra.ver: Add matching for to_chars and from_chars for long double. --- libstdc++-v3/config/os/bsd/darwin/ppc-extra.ver | 3 +++ 1 file changed, 3 insertions(+) diff --git a/libstdc++-v3/config/os/bsd/darwin/ppc-extra.ver b/libstdc++-v3/config/os/bsd/darwin/ppc-extra.ver index f0aee9e8dac..970f3bb50ed 100644 --- a/libstdc++-v3/config/os/bsd/darwin/ppc-extra.ver +++ b/libstdc++-v3/config/os/bsd/darwin/ppc-extra.ver @@ -16,6 +16,9 @@ # 3.4.10 _ZNKSt3tr14hashIgEclEg; _ZNKSt4hashIgEclEg; +# LDBL_3.4.29 + _ZSt10from_charsPKcS0_RgSt12chars_format; + _ZSt8to_charsPcS_g*; # ldbl 1.3 _ZT[IS]g; _ZT[IS]Pg; -- 2.24.1
Re: [PATCH] libstdc++, testsuite, Darwin : Adjust for names used in system headers.
On 15/03/21 00:40 +, Iain Sandoe wrote: Hi, What is slightly odd here is that this problem shows up for installed testing, but not when the test-suite is run in-tree. However, the issue is clear (and doesn’t need to depend on figuring out why it doesn’t show in-tree). tested on powerpc-darwin9, x86_64-darwin OK for master? thanks Iain For all current Darwin SDKs inttypes.h has: extern intmax_t imaxabs(intmax_t j); So we need to exclude j from the defined symbol starts. libstdc++-v3/ChangeLog: * testsuite/17_intro/names.cc: Exclude j from the list of symbol starts on Darwin platform. OK with adjusted changelog as discussed on IRC, thanks. libstdc++-v3/testsuite/17_intro/names.cc | 5 + 1 file changed, 5 insertions(+) diff --git a/libstdc++-v3/testsuite/17_intro/names.cc b/libstdc++-v3/testsuite/17_intro/names.cc index 4534d790772..624e3ed9ccf 100644 --- a/libstdc++-v3/testsuite/17_intro/names.cc +++ b/libstdc++-v3/testsuite/17_intro/names.cc @@ -197,6 +197,11 @@ #undef v #endif +#ifdef __APPLE__ +// inttypes.h: extern intmax_t imaxabs(intmax_t j); +#undef j +#endif + #ifdef __hpux__ #undef d #undef r -- 2.24.1
ping^2 Re: [PATCH] Objective-C++ : Fix handling of unnamed message parms [PR49070].
Iain Sandoe wrote:
Although this is an Objective-C++ patch, I need to touch stuff outside
“objc local”
contexts, so think it needs review,
(this is a regression fix for all open branches).
Iain Sandoe wrote:
We were discussing proposed reflection splicing syntax - [:reflection:]
in SG7
which has some similarities with objective-c++ message syntax with unnamed
params.
This reminded me that we have a *very* long-standing regression against
objective-c++ where it is not able to handle unnamed message parameters
(an
idiom used in practice).
Fixed as below.
tested on x86_64-darwin, x86_64-linux-gnu,
OK for master / open branches?
thanks
Iain
--
When we are parsing an Objective-C++ message, a colon is a valid
terminator for a assignment-expression. That is:
[receiver meth:x:x:x:x];
Is a valid, if somewhat unreadable, construction; corresponding
to a method declaration like:
- (id) meth:(id)arg0 :(id)arg1 :(id)arg2 :(id)arg3;
Where three of the message params have no name.
If fact, although it might be unintentional, Objective-C/C++ can
accept message selectors with all the parms unnamed (this applies
to the clang implementation too, which is taken as the reference
for the language).
For regular C++, the pattern x:x is not valid in that position an
an error is emitted with a fixit for the expected scope token.
If we simply made that error conditional on !c_c_dialect_objc()
that would regress Objective-C++ diagnostics for cases outside a
message selector, so we add a state flag for this.
gcc/cp/ChangeLog:
PR objc++/49070
* parser.c (cp_debug_parser): Add Objective-C++ message
state flag.
(cp_parser_nested_name_specifier_opt): Allow colon to
terminate an assignment-expression when parsing Objective-
C++ messages.
(cp_parser_objc_message_expression): Set and clear message
parsing state on entry and exit.
* parser.h (struct cp_parser): Add a context flag for
Objective-C++ message state.
gcc/testsuite/ChangeLog:
PR objc++/49070
* obj-c++.dg/pr49070.mm: New test.
* objc.dg/unnamed-parms.m: New test.
---
gcc/cp/parser.c | 8 -
gcc/cp/parser.h | 4 +++
gcc/testsuite/obj-c++.dg/pr49070.mm | 52 +++
gcc/testsuite/objc.dg/unnamed-parms.m | 28 +++
4 files changed, 91 insertions(+), 1 deletion(-)
create mode 100644 gcc/testsuite/obj-c++.dg/pr49070.mm
create mode 100644 gcc/testsuite/objc.dg/unnamed-parms.m
diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index 70775792161..e5ba1dcffaa 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -572,6 +572,8 @@ cp_debug_parser (FILE *file, cp_parser *parser)
parser->colon_corrects_to_scope_p);
cp_debug_print_flag (file, "Colon doesn't start a class definition",
parser->colon_doesnt_start_class_def_p);
+ cp_debug_print_flag (file, "Parsing an Objective-C++ message context",
+ parser->objective_c_message_context_p);
if (parser->type_definition_forbidden_message)
fprintf (file, "Error message for forbidden type definitions: %s %s\n",
parser->type_definition_forbidden_message,
@@ -6622,7 +6624,9 @@ cp_parser_nested_name_specifier_opt (cp_parser
*parser,
if (token->type == CPP_COLON
&& parser->colon_corrects_to_scope_p
- && cp_lexer_peek_nth_token (parser->lexer, 3)->type == CPP_NAME)
+ && cp_lexer_peek_nth_token (parser->lexer, 3)->type == CPP_NAME
+ /* name:name is a valid sequence in an Objective C message. */
+ && !parser->objective_c_message_context_p)
{
gcc_rich_location richloc (token->location);
richloc.add_fixit_replace ("::");
@@ -32965,6 +32969,7 @@ cp_parser_objc_message_expression (cp_parser*
parser)
{
tree receiver, messageargs;
+ parser->objective_c_message_context_p = true;
location_t start_loc = cp_lexer_peek_token (parser->lexer)->location;
cp_lexer_consume_token (parser->lexer); /* Eat '['. */
receiver = cp_parser_objc_message_receiver (parser);
@@ -32981,6 +32986,7 @@ cp_parser_objc_message_expression (cp_parser*
parser)
location_t combined_loc = make_location (start_loc, start_loc, end_loc);
protected_set_expr_location (result, combined_loc);
+ parser->objective_c_message_context_p = false;
return result;
}
diff --git a/gcc/cp/parser.h b/gcc/cp/parser.h
index d587cf2404b..a468b6992ad 100644
--- a/gcc/cp/parser.h
+++ b/gcc/cp/parser.h
@@ -350,6 +350,10 @@ struct GTY(()) cp_parser {
is terminated by colon. */
bool colon_doesnt_start_class_def_p;
+ /* TRUE if we are parsing an objective c message, and ':' is permitted
+ to terminate an assignment-expression. */
+ bool objective_c_message_context_p;
+
/* If non-NULL, then we are parsing a construct where new type
definitions are not
Re: [PATCH] coroutines : Convert await_ready () expressions to bool [PR99047].
On 3/14/21 8:29 PM, Iain Sandoe wrote: Hi The awaiter.await_ready() should be converted per [expr.await]/3 (3.6) await-ready is the expression e.await_ready(), contextually converted to bool. The conversion had been omitted, fixed as below, tested on x86_64-darwin, x86_64-linux-gnu, and on cppcoro and folly/coroutines. OK for master / 10.x? thanks Iain gcc/cp/ChangeLog: * coroutines.cc (expand_one_await_expression): If the await_ready() expression is not a boolean then convert it as required. ok -- Nathan Sidwell
Re: [PATCH] coroutines : Handle rethrow from unhandled_exception [PR98704].
On 3/14/21 8:25 PM, Iain Sandoe wrote: Hi Although there is still some discussion in CWG2451 on this, the implementors are agreed on the intent (thus it is wording that is expected to change - the implementations should be brought into sync). tested on x86_64-darwin, x86_64-linux-gnu and with cppcoro and folly/coroutines. OK for master / 10.x? thanks Iain --- When promise.unhandled_exception () is entered, the coroutine is considered to be still running - returning from the method will cause the final await expression to be evaluated. If the method throws, that action is considered to make the coroutine suspend (since, otherwise, it would be impossible to reclaim its resources, since one cannot destroy a running coro). The wording issue is to do with how to represent the place at which the coroutine should be considered suspended. For the implementation here, that place is immediately before the promise life-time ends. A handler for the rethrown exception, can thus call .destroy() which will run DTORs for the promise and any parameter copies [as needed] then the coroutine frame will be deallocated. At present, we also set "done=true" in this case (for compatibility with other current implementations). One might consider 'done()' to be misleading in the case of an abnormal termination - that is also part of the CGW 2451 discussion. gcc/cp/ChangeLog: PR c++/98740 * coroutines.cc (build_actor_fn): Make destroy index 1 correspond to the abnormal unhandled_exception() exit. Substitute the proxy for the resume index. (coro_rewrite_function_body): Arrange to reset the resume index and make done = true for a rethrown exception from unhandled_exception (). (morph_fn_to_coro): Adjust calls to build_actor_fn and coro_rewrite_function_body. ok. missing newline in test ... --- /dev/null +++ b/gcc/testsuite/g++.dg/coroutines/torture/pr98704.C @@ -0,0 +1,93 @@ +} \ No newline at end of file -- Nathan Sidwell
Re: [PATCH] coroutines : Handle for await expressions in for stmts [PR98480].
On 3/14/21 8:22 PM, Iain Sandoe wrote:
Hi
Apparently, I had a brainstorm when posting patches to cover the
cases with await expressions in do {} while; and while {} ; and
omitted the for loop case.
Fixed thus.
tested on x86_64-darwin, x86_64-linux-gnu and with cppcoro and
folly/coroutines.
OK for master / 10.x?
thanks
Iain
gcc/cp/ChangeLog:
* coroutines.cc (replace_continue): Rewrite continue into
'goto label'.
(await_statement_walker): Handle await expressions in the
initializer, condition and iteration expressions of for
loops.
ok
--
Nathan Sidwell
Re: [PATCH] coroutines : Avoid generating empty statements [96749].
On 3/14/21 8:17 PM, Iain Sandoe wrote: Hi In the compiler-only idiom: " a = (target expr creates temp, op uses temp)" the target expression variable needs to be promoted to a frame one (if the expression has a suspend point). However, the only uses of the var are in the second part of the compound expression - and we were creating an empty statement corresponding to the (now unused) first arm. This then produces the spurious warnings noted. Fixed by avoiding generation of a separate variable nest for isolated target expressions (or similarly isolated co_awaits used in a function call). tested on x86_64-darwin, x86_64-linux-gnu and with cppcoro and folly/coroutines OK for master/10.x? thanks Iain gcc/cp/ChangeLog: * coroutines.cc (flatten_await_stmt): Allow for the case where a target expression variable only has uses in the second part of a compound expression. (maybe_promote_temps): Avoid emiting empty statements. ok -- Nathan Sidwell
znver3 tuning part 1
Hi,
I plan to commit some retuning of znver3 codegen that is based on real
hardware benchmarks. It turns out that there are not too many changes
necessary sinze Zen3 is quite smooth upgrade to Zen2. In summary:
- some instructions (like idiv) have shorter latencies. Adjusting
costs reduces code size a bit but seems within noise in benchmark
(since our cost calculation is quite off anyway because it does not
account register pressure and parallelism that does make huge
difference here)
- gather instructions are still microcoded but a lot faster than in
znver1/znver2 and it turns out they are now beneficial for few tsmc
benchmarks, so I plan to enable them.
It seems we missed revisiting this for znver2 tuning.
I think even for znver2 it may make sense to re-enable them, so I
will benchmark this as well.
- memcpy/memset expansion seems to work same way as for znver2,
so I am keeping same changes.
- instruction scheduler is already modified in trunk to some degree
reflecting new units. Problem with instruction scheduling is that
it treats zen as in-order CPU and is unlikely going to fill all
execution resources this way.
We may want to try to model the out-of-order nature similar way as
LLVM does, but at the other hand the current scheduling logic seems
to do mostly fine (i.e. not worse than llvm's). What matters is
to schedule for long latencies and just after branch boundaries
where simplified model seems to do just fine.
- some move instruction latencies does not reflect reality
(at least the published latencies by Agner Fog or AMD optimization
manual that themseleves does not agree with each otehr).
Adjusting tables however triggers regressions in ImageMagick and
parest, so I am still looking if there is easy fix for this and if
not, I will wait for next stage1 with these.
Interesting property is that reg-reg moves are a zero latency.
Since costs are officially relative to reg-reg move it makes it bit
hard to define here :)
- fmadd was optimized and it is now 4 cycles (was 5 and 6 cycles on
znver2 and znver1 respectively) like on Intel. However there is still
problem with extending the critical chain in matrix multiplication
loop. The difference seems to be that Intel implementation needs the
accumulator value to be ready only 1 cycle after the execution
started processing the multiplication.
So there is still a performance regression on matmul and thus I am
keeping the logic to break critical chains.
This first patch is no-op and it only copies the cost tables. I will
adjust them one-by-one for easier hunting of possible regressions.
Honza
2021-03-15 Jan Hubicka
* config/i386/i386-options.c (processor_cost_table): Add znver3_cost.
* config/i386/x86-tune-costs.h (znver3_cost): New gobal variable; copy
of znver2_cost.
diff --git a/gcc/config/i386/i386-options.c b/gcc/config/i386/i386-options.c
index e93935f6f2c..7865bc110a3 100644
--- a/gcc/config/i386/i386-options.c
+++ b/gcc/config/i386/i386-options.c
@@ -743,7 +743,7 @@ static const struct processor_costs *processor_cost_table[]
=
_cost,
_cost,
_cost,
- _cost
+ _cost
};
/* Guarantee that the array is aligned with enum processor_type. */
diff --git a/gcc/config/i386/x86-tune-costs.h b/gcc/config/i386/x86-tune-costs.h
index cc27c7911e3..e655e668c7a 100644
--- a/gcc/config/i386/x86-tune-costs.h
+++ b/gcc/config/i386/x86-tune-costs.h
@@ -1688,6 +1688,140 @@ struct processor_costs znver2_cost = {
"16",/* Func alignment. */
};
+struct processor_costs znver3_cost = {
+ {
+ /* Start of register allocator costs. integer->integer move cost is 2. */
+
+ /* reg-reg moves are done by renaming and thus they are even cheaper than
+ 1 cycle. Because reg-reg move cost is 2 and following tables correspond
+ to doubles of latencies, we do not model this correctly. It does not
+ seem to make practical difference to bump prices up even more. */
+ 6, /* cost for loading QImode using
+ movzbl. */
+ {6, 6, 6}, /* cost of loading integer registers
+ in QImode, HImode and SImode.
+ Relative to reg-reg move (2). */
+ {8, 8, 8}, /* cost of storing integer
+ registers. */
+ 2, /* cost of reg,reg fld/fst. */
+ {6, 6, 16}, /* cost of loading fp registers
+ in SFmode, DFmode and XFmode. */
+ {8, 8, 16}, /* cost of storing fp registers
+ in SFmode, DFmode and XFmode. */
+ 2, /* cost of moving MMX
[PATCH] analyzer: fix missing comma in initializer
Fixes the following valid clang warning: gcc/analyzer/sm-file.cc:250:5: warning: suspicious concatenation of string literals in an array initialization; did you mean to separate the elements with a comma? [-Wstring-concatenation] Survives make check -k RUNTESTFLAGS="analyzer.exp". Ready to be installed? Thanks, Martin gcc/analyzer/ChangeLog: * sm-file.cc (get_file_using_fns): Add missing comma in initializer. --- gcc/analyzer/sm-file.cc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/gcc/analyzer/sm-file.cc b/gcc/analyzer/sm-file.cc index 48ef4aa2334..7a81c8ff632 100644 --- a/gcc/analyzer/sm-file.cc +++ b/gcc/analyzer/sm-file.cc @@ -246,7 +246,7 @@ get_file_using_fns () "__fbufsize", "__flbf", "__fpending", -"__fpurge" +"__fpurge", "__freadable", "__freading", "__fsetlocking", -- 2.30.1
[PATCH][pushed] Fix -Wstring-concatenation warning.
Fix the following clang warning:
gcc/spellcheck.c:477:3: warning: suspicious concatenation of string literals in
an array initialization;
did you mean to separate the elements with a comma? [-Wstring-concatenation]
It's quite obvious issue in unit tests, thus I'm going to push it.
Martin
gcc/ChangeLog:
* spellcheck.c: Add missing comma in initialization.
---
gcc/spellcheck.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/spellcheck.c b/gcc/spellcheck.c
index f76e094bc63..c39c5073a26 100644
--- a/gcc/spellcheck.c
+++ b/gcc/spellcheck.c
@@ -473,7 +473,7 @@ static const char * const test_data[] = {
"foo",
"food",
"boo",
- "1234567890123456789012345678901234567890123456789012345678901234567890"
+ "1234567890123456789012345678901234567890123456789012345678901234567890",
"abc",
"ac",
"ca",
--
2.30.1
Re: [patch, fortran] Fix PR 99345, ICE with DO loop checking
Hello Thomas, hello World, On 14.03.21 21:18, Thomas Koenig via Fortran wrote: the attached, rather obvious patch fixes an ICE on valid which came about because I did not handle EXEC_IOLENGTH as start of an I/O statement when checking for the DO loop variable. This is an 11 regression. Thanks to Harald for reducing this down to the bare minimum. Regression-tested on x86_64-pc-linux-gnu. OK for trunk? OK. Thanks for the patch and thanks to Martin & Harald for the test-case reduction and for Mathias "doko" for the reporting! Tobias Handle EXEC_IOLENGTH in doloop_contained_procedure_code. gcc/fortran/ChangeLog: PR fortran/99345 * frontend-passes.c (doloop_contained_procedure_code): Properly handle EXEC_IOLENGTH. gcc/testsuite/ChangeLog: PR fortran/99345 * gfortran.dg/do_check_16.f90: New test. * gfortran.dg/do_check_17.f90: New test. - Mentor Graphics (Deutschland) GmbH, Arnulfstrasse 201, 80634 München Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Frank Thürauf
Re: [Patch] OpenMP: Fix 'omp declare target' handling for vars [PR99509]
On Mon, Mar 15, 2021 at 09:17:47AM +0100, Tobias Burnus wrote: > gcc/c/ChangeLog: > > PR c++/99509 > * c-decl.c (finish_decl): For 'omp declare target implicit' vars, > ensure that the varpool node is marked as offloadable. > > gcc/cp/ChangeLog: > > PR c++/99509 > * decl.c (cp_finish_decl): For 'omp declare target implicit' vars, > ensure that the varpool node is marked as offloadable. > > libgomp/ChangeLog: > > PR c++/99509 > * testsuite/libgomp.c-c++-common/declare_target-1.c: New test. Ok, thanks. Jakub
Re: [Patch] OpenMP: Fix 'omp declare target' handling for vars [PR99509]
On 12.03.21 13:20, Jakub Jelinek wrote:
On Wed, Mar 10, 2021 at 03:20:42PM +0100, Tobias Burnus wrote:
The C/C++ FE sets for an 'omp declare target' ... 'omp end declare target'
the attribute 'omp declare target implicit'.
That's later processed (for C++) in decl.c - which remove that attribute
and either keeps and explicit 'omp declare target' or 'omp declare target link'
attribute.
Unfortunately, adding 'omp declare target' comes too late as the varpool
has been generated.
Looking attributes on every get rather than just once is IMHO too expensive.
For explicit declare target, we use:
...
(e.g. from cp/parser.c).
So, I think it would be better to do the same thing
I concur. I was already wondering whether it should be in the FE or
not, thinking about some separation between FE and ME. But given
the precedent and the performance issue, it surely makes sense to
solve it in c*/*decl.c.
Done now. OK for mainline?
Tobias
-
Mentor Graphics (Deutschland) GmbH, Arnulfstrasse 201, 80634 München
Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Frank
Thürauf
OpenMP: Fix 'omp declare target' handling for vars [PR99509]
For variables with 'declare target' attribute,
varpool_node::get_create marks variables as offload; however,
if the node already exists, it is not updated. C/C++ may tag
decl with 'declare target implicit', which may only be after
varpool creation turned into 'declare target' or 'declare target link';
in this case, the tagging has to happen in the FE.
gcc/c/ChangeLog:
PR c++/99509
* c-decl.c (finish_decl): For 'omp declare target implicit' vars,
ensure that the varpool node is marked as offloadable.
gcc/cp/ChangeLog:
PR c++/99509
* decl.c (cp_finish_decl): For 'omp declare target implicit' vars,
ensure that the varpool node is marked as offloadable.
libgomp/ChangeLog:
PR c++/99509
* testsuite/libgomp.c-c++-common/declare_target-1.c: New test.
gcc/c/c-decl.c | 22 +++---
gcc/cp/decl.c | 21 ++---
.../libgomp.c-c++-common/declare_target-1.c| 22 ++
3 files changed, 59 insertions(+), 6 deletions(-)
diff --git a/gcc/c/c-decl.c b/gcc/c/c-decl.c
index b559ed5d76a..3b2241bfd97 100644
--- a/gcc/c/c-decl.c
+++ b/gcc/c/c-decl.c
@@ -58,6 +58,9 @@ along with GCC; see the file COPYING3. If not see
#include "c-family/name-hint.h"
#include "c-family/known-headers.h"
#include "c-family/c-spellcheck.h"
+#include "context.h" /* For 'g'. */
+#include "omp-general.h"
+#include "omp-offload.h" /* For offload_vars. */
#include "tree-pretty-print.h"
@@ -5658,9 +5661,22 @@ finish_decl (tree decl, location_t init_loc, tree init,
DECL_ATTRIBUTES (decl))
&& !lookup_attribute ("omp declare target link",
DECL_ATTRIBUTES (decl)))
- DECL_ATTRIBUTES (decl)
- = tree_cons (get_identifier ("omp declare target"),
- NULL_TREE, DECL_ATTRIBUTES (decl));
+ {
+ DECL_ATTRIBUTES (decl)
+ = tree_cons (get_identifier ("omp declare target"),
+ NULL_TREE, DECL_ATTRIBUTES (decl));
+ symtab_node *node = symtab_node::get (decl);
+ if (node != NULL)
+ {
+ node->offloadable = 1;
+ if (ENABLE_OFFLOADING)
+ {
+ g->have_offload = true;
+ if (is_a (node))
+ vec_safe_push (offload_vars, decl);
+ }
+ }
+ }
}
/* This is the last point we can lower alignment so give the target the
diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
index 9c7f6e59bbb..1b671cec9a3 100644
--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -53,7 +53,9 @@ along with GCC; see the file COPYING3. If not see
#include "asan.h"
#include "gcc-rich-location.h"
#include "langhooks.h"
+#include "context.h" /* For 'g'. */
#include "omp-general.h"
+#include "omp-offload.h" /* For offload_vars. */
/* Possible cases of bad specifiers type used by bad_specifiers. */
enum bad_spec_place {
@@ -8176,9 +8178,22 @@ cp_finish_decl (tree decl, tree init, bool init_const_expr_p,
DECL_ATTRIBUTES (decl))
&& !lookup_attribute ("omp declare target link",
DECL_ATTRIBUTES (decl)))
- DECL_ATTRIBUTES (decl)
- = tree_cons (get_identifier ("omp declare target"),
- NULL_TREE, DECL_ATTRIBUTES (decl));
+ {
+ DECL_ATTRIBUTES (decl)
+ = tree_cons (get_identifier ("omp declare target"),
+ NULL_TREE, DECL_ATTRIBUTES (decl));
+ symtab_node *node = symtab_node::get (decl);
+ if (node != NULL)
+ {
+ node->offloadable = 1;
+ if (ENABLE_OFFLOADING)
+ {
+ g->have_offload = true;
+ if (is_a (node))
+ vec_safe_push (offload_vars, decl);
+ }
+ }
+ }
}
/* This is the last point we can lower alignment so give the target the
diff --git a/libgomp/testsuite/libgomp.c-c++-common/declare_target-1.c b/libgomp/testsuite/libgomp.c-c++-common/declare_target-1.c
new file mode 100644
index 000..c5670dfb7db
--- /dev/null
+++
