Re: [PATCH] Add OpenACC 2.6 `acc_get_property' support
Hi Thomas,
On 23.01.20 15:32, Thomas Schwinge wrote:
> On 2020-01-20T15:01:01+0100, "Harwath, Frederik"
> wrote:
>> On 16.01.20 17:00, Thomas Schwinge wrote:
>>> On 2019-12-20T17:46:57+0100, "Harwath, Frederik"
>>> wrote:
>> Ok to push the commit to master?
>
> Thanks, OK. Reviewed-by: Thomas Schwinge
Thank you. Committed as 4bd03ed69bd789278a0286017b692f49052ffe5c, including the
changes to the size_t
formatting.
Best regards,
Frederik
>
>
> As a low-priority follow-up, please look into:
>
>
> source-gcc/libgomp/testsuite/libgomp.oacc-c-c++-common/acc_get_property-aux.c:
> In function 'expect_device_properties':
>
> source-gcc/libgomp/testsuite/libgomp.oacc-c-c++-common/acc_get_property-aux.c:74:24:
> warning: format '%d' expects argument of type 'int', but argument 3 has type
> 'const char *' [-Wformat=]
>74 | fprintf (stderr, "Expected value of unknown string property
> to be NULL, "
> |
> ^~~~
>75 | "but was %d.\n", s);
> | ~
> | |
> | const char *
>
> source-gcc/libgomp/testsuite/libgomp.oacc-c-c++-common/acc_get_property-aux.c:75:19:
> note: format string is defined here
>75 | "but was %d.\n", s);
> | ~^
> | |
> | int
> | %s
>
> ..., and (random example):
>
>>int unknown_property = 16058;
>> - int v = acc_get_property (dev_num, dev_type,
>> (acc_device_property_t)unknown_property);
>> + size_t v = acc_get_property (dev_num, dev_type,
>> (acc_device_property_t)unknown_property);
>>if (v != 0)
>> {
>>fprintf (stderr, "Expected value of unknown numeric property to equal
>> 0, "
>> - "but was %d.\n", v);
>> + "but was %zd.\n", v);
>>abort ();
>> }
>
> ..., shouldn't that be '%zu' given that 'size_t' is 'unsigned'?
>
> libgomp.oacc-c-c++-common/acc_get_property-aux.c: fprintf (stderr,
> "Expected acc_property_memory to equal %zd, "
> libgomp.oacc-c-c++-common/acc_get_property-aux.c:"but was
> %zd.\n", expected_memory, total_mem);
> libgomp.oacc-c-c++-common/acc_get_property-aux.c:", but free
> memory was %zd and total memory was %zd.\n",
> libgomp.oacc-c-c++-common/acc_get_property-aux.c:"but was
> %zd.\n", v);
> libgomp.oacc-c-c++-common/acc_get_property.c: printf ("Total
> memory: %zd\n", v);
> libgomp.oacc-c-c++-common/acc_get_property.c: printf ("Free
> memory: %zd\n", v);
>
>
> Grüße
> Thomas
>
From 4bd03ed69bd789278a0286017b692f49052ffe5c Mon Sep 17 00:00:00 2001
From: Frederik Harwath
Date: Mon, 20 Jan 2020 14:07:03 +0100
Subject: [PATCH 1/2] Fix expectation and types in acc_get_property tests
* Weaken expectation concerning acc_property_free_memory.
Do not expect the value returned by CUDA since that value might have
changed in the meantime.
* Use correct type for the results of calls to acc_get_property in tests.
libgomp/
* testsuite/libgomp.oacc-c-c++-common/acc_get_property-aux.c
(expect_device_properties): Remove "expected_free_mem" argument,
change "expected_total_mem" argument type to size_t;
change types of acc_get_property results to size_t,
adapt format strings.
* testsuite/libgomp.oacc-c-c++-common/acc_get_property.c:
Use %zu instead of %zd to print size_t values.
* testsuite/libgomp.oacc-c-c++-common/acc_get_property-2.c: Adapt and
rename to ...
* testsuite/libgomp.oacc-c-c++-common/acc_get_property-nvptx.c: ... this.
* testsuite/libgomp.oacc-c-c++-common/acc_get_property-3.c: Adapt and
rename to ...
* testsuite/libgomp.oacc-c-c++-common/acc_get_property-host.c: ... this.
Reviewed-by: Thomas Schwinge
---
.../acc_get_property-aux.c| 30 +--
...t_property-3.c => acc_get_property-host.c} | 7 ++---
..._property-2.c => acc_get_property-nvptx.c} | 9 +++---
.../acc_get_property.c| 4 +--
4 files changed, 25 insertions(+), 25 deletions(-)
rename libgomp/testsuite/libgomp.oacc-c-c++-common/{acc_get_property-3.c => acc_get_property-host.c} (63%)
rename libgomp/testsuite/libgomp.oacc-c-c++-common/{acc_get_property-2.c => acc_get_property-nvptx.c} (86%)
diff --git a/libgomp/testsuite/libgomp.oacc-c-c++-common/acc_get_property-aux.c b/libgomp/testsuite/libgomp.oacc-c-c++-common/acc_get_property-aux.c
index 952bdbf6aea..6bb01250148 100644
--- a/libgomp/testsuite/libgomp.oacc-c-c++-common/acc_get_property-aux.c
+++ b/libgomp/testsuite/libgomp.oacc-c-c++-common/acc_get_property-aux.c
@@ -8,9 +8,8 @@
void expect_device_properties
(acc_device_t dev_type, int dev_num,
- int expected_total_mem, int expected_free_mem,
- const char* expected_vendor, const char* expected_name,
- const c
*ping* Re: [patch, fortran] Fix PR 85781, ICE on valid
Admittedly an early PING. On 1/22/20 11:59 AM, Tobias Burnus wrote: Hi Thomas, hi all, first, I have now attached a different fix for PR 85781 (= original bug). Can you have a look? I have the feeling (but didn't check) that your patch does not handle the following variant of the test case: "print *, x(m:n)" (i.e. the lower bound is not known at compile time). I confirmed that my suspicion was right: the "resolve_substring" patch (first patch in this email thread) is not sufficient as all my test cases (of this patch) will still ICE with it. I hope my patch covers all issues. – OK for the trunk? Cheers, Tobias Secondly: On 1/21/20 7:32 PM, Thomas König wrote: the attached patch fixes an ICE which could occur for empty substrings (see test case). I think one should rather fix the following issue. I am not sure what you mean. Does that mean that fixing the following issue will also fix PR 85781 I am no longer sure what I meant myself ;-) I initially thought those are directly related – but they now look related but independent bugs: PR 85781 is about getting a non-ARRAY_TYPE (tree dump: "character") and using it as ARRAY_TYPE (tree dump: "character[lb:ub]"). While PR93336 is about (1) using an ARRAY_TYPE when one should not. – And, additionally, about missing diagnostic related to (2) bind(c) and kind=4, (3) passing zero-length strings to non-zero-length dummy args, (4) diagnostic about truncating too long strings (esp. if of non-default, non-c_char kind). Tobias
Re: [PATCH] debug/92763 keep DIEs that might be used in DW_TAG_inlined_subroutine
On Mon, 20 Jan 2020 at 12:09, Jakub Jelinek wrote:
>
> On Mon, Jan 20, 2020 at 12:04:12PM +0100, Richard Biener wrote:
> >
> > We were pruning type-local subroutine DIEs if their context is unused
> > despite us later needing those DIEs as abstract origins for inlines.
> > The patch makes code already present for -fvar-tracking-assignments
> > unconditional.
> >
> > Bootstrapped and tested on x86_64-unknown-linux-gnu, OK?
> >
> > Thanks,
> > Richard.
> >
> > 2020-01-20 Richard Biener
> >
> > PR debug/92763
> > * dwarf2out.c (prune_unused_types): Unconditionally mark
> > called function DIEs.
> >
> > * g++.dg/debug/pr92763.C: New testcase.
>
> Ok.
>
Hi,
I have committed that attached patch as obvious: it requires the
fopenmp effective-target for the testcase, to avoid failures on
targets such as aarch64-elf or arm-eabi.
2020-01-24 Christophe Lyon
PR debug/92763
* g++.dg/debug/pr92763.C: Require fopenmp.
Thanks,
Christophe
> Jakub
>
commit ad8e2415d6e2dc7c6f1206e78d48f999ff6b0bc4
Author: Christophe Lyon
Date: Fri Jan 24 09:07:58 2020 +
debug/92763 Fix testcase to require fopenmp
The testcase fails to link on targets without -pthread which is
implied by -fopenmp. Use dg-require-effective-target fopenmp to avoid
this problem.
2020-01-24 Christophe Lyon
PR debug/92763
* g++.dg/debug/pr92763.C: Require fopenmp.
diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog
index df547bc..c465ff9 100644
--- a/gcc/testsuite/ChangeLog
+++ b/gcc/testsuite/ChangeLog
@@ -1,3 +1,8 @@
+2020-01-24 Christophe Lyon
+
+ PR debug/92763
+ * g++.dg/debug/pr92763.C: Require fopenmp.
+
2020-01-23 David Malcolm
PR analyzer/93367
diff --git a/gcc/testsuite/g++.dg/debug/pr92763.C
b/gcc/testsuite/g++.dg/debug/pr92763.C
index 8e32d60..16dccf3 100644
--- a/gcc/testsuite/g++.dg/debug/pr92763.C
+++ b/gcc/testsuite/g++.dg/debug/pr92763.C
@@ -1,4 +1,5 @@
// { dg-do compile }
+// { dg-require-effective-target fopenmp }
// { dg-additional-options "-fno-var-tracking-assignments -fopenmp" }
struct A
Re: [PATCH] simplify-rtx: Punt for modes with precision above MAX_BITSIZE_MODE_ANY_INT [PR93376]
Jakub Jelinek writes: > Hi! > > The following patch makes sure we punt in the 3 spots if precision is above > MAX_BITSIZE_MODE_ANY_INT. > > Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? > > 2020-01-23 Jakub Jelinek > > PR target/93376 > * simplify-rtx.c (simplify_const_unary_operation, > simplify_const_binary_operation): Punt for mode precision above > MAX_BITSIZE_MODE_ANY_INT. OK, thanks. Richard
Re: [PATCH] Fix component mappings with derived types for OpenACC
Hi Julian,
the gfortran part is rather obvious and it and the test case look fine
to me → OK.
The oacc-mem.c also looks okay, but I assume Thomas needs to
rubber-stamp it.
Tobias
On 1/10/20 2:49 AM, Julian Brown wrote:
This patch fixes a bug with mapping Fortran components (i.e. with the
manual deep-copy support) which themselves have derived types. I've
also added a couple of new tests to make sure such mappings are lowered
correctly, and to check for the case that Tobias found in the message:
https://gcc.gnu.org/ml/gcc-patches/2020-01/msg00215.html
The previous incorrect mapping was causing the error condition mentioned
in that message to fail to trigger, and I think (my!) code in libgomp
(goacc_exit_data_internal) to handle GOMP_MAP_STRUCT specially was
papering over the bad mapping also. Oops!
I haven't attempted to implement the (harder) sub-copy detection, if
that is indeed supposed to be forbidden by the spec. This patch should
get us to the same behaviour in Fortran as in C & C++ though.
Tested with offloading to nvptx, also with the (uncommitted)
reference-count self-checking patch enabled.
OK?
Thanks,
Julian
ChangeLog
gcc/fortran/
* trans-openmp.c (gfc_trans_omp_clauses): Use inner not decl for
components with derived types.
gcc/testsuite/
* gfortran.dg/goacc/mapping-tests-3.f90: New test.
* gfortran.dg/goacc/mapping-tests-4.f90: New test.
libgomp/
* oacc-mem.c (goacc_exit_data_internal): Remove special (no-copyback)
behaviour for GOMP_MAP_STRUCT.
component-mappings-derived-types-1.diff
commit 5e9d8846bbaa33a9bdb08adcf1ee9f224a8e8fc0
Author: Julian Brown
Date: Wed Jan 8 15:57:46 2020 -0800
Fix component mappings with derived types for OpenACC
gcc/fortran/
* trans-openmp.c (gfc_trans_omp_clauses): Use inner not decl for
components with derived types.
gcc/testsuite/
* gfortran.dg/goacc/mapping-tests-3.f90: New test.
* gfortran.dg/goacc/mapping-tests-4.f90: New test.
libgomp/
* oacc-mem.c (goacc_exit_data_internal): Remove special
(no-copyback)
behaviour for GOMP_MAP_STRUCT.
diff --git a/gcc/fortran/trans-openmp.c b/gcc/fortran/trans-openmp.c
index 9835d2aae3c..efc392d7fa6 100644
--- a/gcc/fortran/trans-openmp.c
+++ b/gcc/fortran/trans-openmp.c
@@ -2783,9 +2783,9 @@ gfc_trans_omp_clauses (stmtblock_t *block,
gfc_omp_clauses *clauses,
}
else
{
- OMP_CLAUSE_DECL (node) = decl;
+ OMP_CLAUSE_DECL (node) = inner;
OMP_CLAUSE_SIZE (node)
- = TYPE_SIZE_UNIT (TREE_TYPE (decl));
+ = TYPE_SIZE_UNIT (TREE_TYPE (inner));
}
}
else if (lastcomp->next
diff --git a/gcc/testsuite/gfortran.dg/goacc/mapping-tests-3.f90
b/gcc/testsuite/gfortran.dg/goacc/mapping-tests-3.f90
new file mode 100644
index 000..312f596461e
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/goacc/mapping-tests-3.f90
@@ -0,0 +1,15 @@
+! { dg-options "-fopenacc -fdump-tree-omplower" }
+
+subroutine foo
+ type one
+integer i, j
+ end type
+ type two
+type(one) A, B
+ end type
+
+ type(two) x
+
+ !$acc enter data copyin(x%A)
+! { dg-final { scan-tree-dump-times "omp target oacc_enter_exit_data map\\(struct:x \\\[len:
1\\\]\\) map\\(to:x.a \\\[len: \[0-9\]+\\\]\\)" 1 "omplower" } }
+end
diff --git a/gcc/testsuite/gfortran.dg/goacc/mapping-tests-4.f90
b/gcc/testsuite/gfortran.dg/goacc/mapping-tests-4.f90
new file mode 100644
index 000..6257af942df
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/goacc/mapping-tests-4.f90
@@ -0,0 +1,17 @@
+subroutine foo
+ type one
+integer i, j
+ end type
+ type two
+type(one) A, B
+ end type
+
+ type(two) x
+
+! This is accepted at present, although it represents a probably-unintentional
+! overlapping subcopy.
+ !$acc enter data copyin(x%A, x%A%i)
+! But this raises an error.
+ !$acc enter data copyin(x%A, x%A%i, x%A%i)
+! { dg-error ".x.a.i. appears more than once in map clauses" "" { target
"*-*-*" } 15 }
+end
diff --git a/libgomp/oacc-mem.c b/libgomp/oacc-mem.c
index 2d4bba78efd..232683a85f0 100644
--- a/libgomp/oacc-mem.c
+++ b/libgomp/oacc-mem.c
@@ -1136,38 +1136,6 @@ goacc_exit_data_internal (struct gomp_device_descr
*acc_dev, size_t mapnum,
break;
case GOMP_MAP_STRUCT:
- {
- int elems = sizes[i];
- for (int j = 1; j <= elems; j++)
- {
- struct splay_tree_key_s k;
- k.host_start = (uintptr_t) hostaddrs[i + j];
- k.host_end = k.host_start + sizes[i + j];
- splay_tree_key str;
- str = splay_tree_lookup (&acc_dev->mem_map, &k);
- if (str)
- {
-
Re: [PATCH] analyzer: fixes to tree_cmp and other comparators
On Thu, Jan 23, 2020 at 05:13:20PM -0500, David Malcolm wrote: [...] > > Fixes build on s390x-ibm-linux-gnu for stage 1, at least, with no > testsuite regressions. Full bootstrap and regression test run > in progress. Thank you for taking care of this! With your new patch I can successfully bootstrap + regtest. Cheers, Stefan
Re: [PATCH] cprop: Don't replace fixed hard regs with pseudos [PR93124]
Jeff Law writes: > Finding a way to drop the naked clobbers/uses would be a better way > forward. I'm a bit surprised we need them as much as we apparently do. > We're conflating issues a bit here though. FWIW, I think they're a really useful feature. E.g. they help when modelling the lifetimes of multi-hard-reg pseudos that are accessed via subregs. Without them, we do a poor job tracking register lifetimes for things like ST3 and ST4 (g:3ba4ff4130903a3ded931d715a2204bd8834fe60). We might eventually be able to avoid some of that by using better subreg tracking, but I suspect there are always going to be cases in which clobber information inherited from gimple will be needed (or least work better). Also, the fact that gimple has essentially the same feature (for clobbers at least) suggests this might be one of those things that is bound to be invented if it doesn't already exist. ;-) Richard
Re: [PATCH] Suppress deprecation warnings in tbb effective target check
You didn't provide a ChangeLog entry. Please be sure to add one.
OK for master and gcc-9 branch, with the ChangeLog entry. Thanks.
On 23/01/20 21:59 -0800, Thomas Rodgers wrote:
TBB 2020 added deprecation warnings which produced output not expected by
check_effective_target_tbb-backend
---
libstdc++-v3/testsuite/lib/libstdc++.exp | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/libstdc++-v3/testsuite/lib/libstdc++.exp
b/libstdc++-v3/testsuite/lib/libstdc++.exp
index 94f3fdb2bc8..f451719bdd4 100644
--- a/libstdc++-v3/testsuite/lib/libstdc++.exp
+++ b/libstdc++-v3/testsuite/lib/libstdc++.exp
@@ -1597,7 +1597,8 @@ proc check_effective_target_tbb-backend { } {
puts $f "}"
close $f
-set lines [v3_target_compile $src $exe executable
"additional_flags=-std=c++17 additional_flags=-ltbb"]
+set lines [v3_target_compile $src $exe executable
"additional_flags=-std=c++17 additional_flags=-ltbb
+
additional_flags=-DTBB_SUPPRESS_DEPRECATED_MESSAGES=1"]
file delete $src
if [string match "" $lines] {
--
2.21.1
Re: [PATCH] wwwdocs: document scripts to access personal and vendor spaces
On 23/01/20 16:23 +, Richard Earnshaw (lists) wrote: On 21/01/2020 18:58, Richard Earnshaw (lists) wrote: This patch documents some of the scripts that I've published for managing the personal and vendor spaces on the server. It also covers some of the other features that those scripts enable, so that it's all in one place. This is a complete rewrite of the material I had written previously since before we did not have these scripts to make use of. I've not filled in the documentation for gcc-descr and gcc-undescr, Jakub has agreed to provide that at a later date. R. I've pushed this. I think it's better to have this in than nothing at all. We can iterate on it as required. I've pushed the attached fix for a couple of typos. Do we want to repeat the "do not push changes to that space without their express permission" for user branches? There are no access checks to prevent it, but I hsouldn't be changing things in your branches without your permission. Finally, why does this qualify it as "If you have multiple clones"? If you have multiple clones of the gcc repository you can fetch updates from your personal space by running git fetch me Isn't that the right command even if you only have one clone? commit 182ab16b43b0b40b985e0678891b29debef2c9a2 Author: Jonathan Wakely Date: Fri Jan 24 10:59:14 2020 + Fix typos in gitwrite.html diff --git a/htdocs/gitwrite.html b/htdocs/gitwrite.html index ad073b53..c0fe8526 100644 --- a/htdocs/gitwrite.html +++ b/htdocs/gitwrite.html @@ -391,7 +391,7 @@ configuration steps can give access to them. in refs/vendors/vendor-name/tags. -Scripts exist the contrib directory to help manage these spaces. +Scripts exist in the contrib directory to help manage these spaces. contrib/gcc-git-customization.sh @@ -413,7 +413,7 @@ some aliases that might be useful when developing GCC. The script will work this out based on the URL used to fetch from the git server, or fall back to your local user name if that fails. Using this name on the server for your personal space ensures that your branches will -not conflict with anybody elses. +not conflict with anybody else's. The prefix to use for your personal branches - the default is me, but you can change this if you prefer. The script will add configuration information to allow local branches that
[committed v4] Add `--with-toolexeclibdir=' configuration option
Provide means, in the form of a `--with-toolexeclibdir=' configuration option, to override the default installation directory for target libraries, otherwise known as $toolexeclibdir. This is so that it is possible to get newly-built libraries, particularly the shared ones, installed in a common place, so that they can be readily used by the target system as their host libraries, possibly over NFS, without a need to manually copy them over from the currently hardcoded location they would otherwise be installed in. In the presence of the `--enable-version-specific-runtime-libs' option and for configurations building native GCC the option is ignored. config/ * toolexeclibdir.m4: New file. gcc/ * doc/install.texi (Cross-Compiler-Specific Options): Document `--with-toolexeclibdir' option. libada/ * Makefile.in (configure_deps): Add `toolexeclibdir.m4'. * configure.ac: Handle `--with-toolexeclibdir='. * configure: Regenerate. libatomic/ * configure.ac: Handle `--with-toolexeclibdir='. * Makefile.in: Regenerate. * aclocal.m4: Regenerate. * configure: Regenerate. * testsuite/Makefile.in: Regenerate. libffi/ * configure.ac: Handle `--with-toolexeclibdir='. * Makefile.in: Regenerate. * aclocal.m4: Regenerate. * configure: Regenerate. * include/Makefile.in: Regenerate. * man/Makefile.in: Regenerate. * testsuite/Makefile.in: Regenerate. libgcc/ * Makefile.in (configure_deps): Add `toolexeclibdir.m4'. * configure.ac: Handle `--with-toolexeclibdir='. * configure: Regenerate. libgfortran/ * configure.ac: Handle `--with-toolexeclibdir='. * Makefile.in: Regenerate. * aclocal.m4: Regenerate. * configure: Regenerate. libgomp/ * configure.ac: Handle `--with-toolexeclibdir='. * Makefile.in: Regenerate. * aclocal.m4: Regenerate. * configure: Regenerate. * testsuite/Makefile.in: Regenerate. libhsail-rt/ * configure.ac: Handle `--with-toolexeclibdir='. * Makefile.in: Regenerate. * aclocal.m4: Regenerate. * configure: Regenerate. libitm/ * configure.ac: Handle `--with-toolexeclibdir='. * Makefile.in: Regenerate. * aclocal.m4: Regenerate. * configure: Regenerate. * testsuite/Makefile.in: Regenerate. libobjc/ * Makefile.in (aclocal_deps): Add `toolexeclibdir.m4'. * aclocal.m4: Include `toolexeclibdir.m4'. * configure.ac: Handle `--with-toolexeclibdir='. * configure: Regenerate. liboffloadmic/ * plugin/configure.ac: Handle `--with-toolexeclibdir='. * plugin/Makefile.in: Regenerate. * plugin/aclocal.m4: Regenerate. * plugin/configure: Regenerate. * configure.ac: Handle `--with-toolexeclibdir='. * Makefile.in: Regenerate. * aclocal.m4: Regenerate. * configure: Regenerate. libphobos/ * m4/druntime.m4: Handle `--with-toolexeclibdir='. * m4/Makefile.in: Regenerate. * libdruntime/Makefile.in: Regenerate. * src/Makefile.in: Regenerate. * testsuite/Makefile.in: Regenerate. * Makefile.in: Regenerate. * aclocal.m4: Regenerate. * configure: Regenerate. libquadmath/ * configure.ac: Handle `--with-toolexeclibdir='. * Makefile.in: Regenerate. * aclocal.m4: Regenerate. * configure: Regenerate. libsanitizer/ * configure.ac: Handle `--with-toolexeclibdir='. * Makefile.in: Regenerate. * aclocal.m4: Regenerate. * configure: Regenerate. * asan/Makefile.in: Regenerate. * interception/Makefile.in: Regenerate. * libbacktrace/Makefile.in: Regenerate. * lsan/Makefile.in: Regenerate. * sanitizer_common/Makefile.in: Regenerate. * tsan/Makefile.in: Regenerate. * ubsan/Makefile.in: Regenerate. libssp/ * configure.ac: Handle `--with-toolexeclibdir='. * Makefile.in: Regenerate. * aclocal.m4: Regenerate. * configure: Regenerate. libstdc++-v3/ * acinclude.m4: Handle `--with-toolexeclibdir='. * Makefile.in: Regenerate. * aclocal.m4: Regenerate. * configure: Regenerate. * doc/Makefile.in: Regenerate. * include/Makefile.in: Regenerate. * libsupc++/Makefile.in: Regenerate. * po/Makefile.in: Regenerate. * python/Makefile.in: Regenerate. * src/Makefile.in: Regenerate. * src/c++11/Makefile.in: Regenerate. * src/c++17/Makefile.in: Regenerate. * src/c++98/Makefile.in: Regenerate. * src/filesystem/Makefile.in: Regenerate. * testsuite/Makefile.in: Regenerate. libvtv/ *
Re: [RFC] [c-family] PR92867 - Add returns_arg attribute
On Tue, 21 Jan 2020 at 04:35, Joseph Myers wrote:
>
> On Mon, 20 Jan 2020, Prathamesh Kulkarni wrote:
>
> > Hi,
> > This patch attempts to add returns_arg attribute for c-family
> > languages. For C++ methods, first arg is assumed to be this pointer,
>
> This is missing .texi documentation explaining the attribute and the cases
> for which it would be useful.
>
> A restriction to the first 4 arguments is not a good design of a language
> feature, whatever implementation issues there may be.
>
> Do you intend to update builtins.def in a followup patch for the various
> built-in functions (e.g. memcpy) for which such an attribute would be
> applicable?
>
> When extracting an integer value from an INTEGER_CST provided in user
> source code, you should always use tree_to_uhwi / tree_to_shwi as
> appropriate, after checking the relevant tree_fits_*, rather than using
> TREE_INT_CST_LOW directly, to avoid mishandling arguments that have a
> small number in the low part of the INTEGER_CST but have bits set in the
> high part as well. Any direct use of TREE_INT_CST_LOW should have a
> specific justification for why it is correct to discard the high part of
> the integer. See c-attribs.c:positional_argument, and try to use that
> function if possible rather than reimplementing bits of it, so that
> handling of attribute arguments giving the position of a function argument
> can be as consistent as possible between different attributes.
>
> There are coding style issues, e.g. diagnostics should not end with '.'
> and lines should be broken before not after an operator.
Hi Joseph,
Thanks for the suggestions. Using positional_argument helped to
simplify the patch,
and also catches the case when return-type and arg-type differ.
Does it look OK ?
I will update builtins.def in follow-up patch.
The middle-end representation issue of ERF_RETURNS_ARG still remains,
which restricts the attribute till first four args. The patch simply
emits sorry(), for arguments beyond first four..
I will try to address this in follow up patch.
Thanks,
Prathamesh
>
> --
> Joseph S. Myers
> jos...@codesourcery.com
diff --git a/gcc/c-family/c-attribs.c b/gcc/c-family/c-attribs.c
index dc9579c5c60..baed1b811ba 100644
--- a/gcc/c-family/c-attribs.c
+++ b/gcc/c-family/c-attribs.c
@@ -150,6 +150,7 @@ static tree handle_designated_init_attribute (tree *, tree, tree, int, bool *);
static tree handle_patchable_function_entry_attribute (tree *, tree, tree,
int, bool *);
static tree handle_copy_attribute (tree *, tree, tree, int, bool *);
+static tree handle_returns_arg_attribute (tree *, tree, tree, int, bool *);
/* Helper to define attribute exclusions. */
#define ATTR_EXCL(name, function, type, variable) \
@@ -484,6 +485,8 @@ const struct attribute_spec c_common_attribute_table[] =
handle_noinit_attribute, attr_noinit_exclusions },
{ "access", 1, 3, false, true, true, false,
handle_access_attribute, NULL },
+ { "returns_arg", 1, 1, true, false, false, false,
+ handle_returns_arg_attribute, NULL },
{ NULL, 0, 0, false, false, false, false, NULL, NULL }
};
@@ -4603,6 +4606,55 @@ handle_patchable_function_entry_attribute (tree *, tree name, tree args,
return NULL_TREE;
}
+/* Handle a "returns_arg" attribute; arguments as in
+ struct attribute_spec.handler. */
+
+static tree
+handle_returns_arg_attribute (tree *node, tree name, tree args,
+ int flags, bool *no_add_attrs)
+{
+ tree decl = *node;
+ tree rettype = TREE_TYPE (decl);
+
+ if (TREE_CODE (rettype) == METHOD_TYPE
+ || TREE_CODE (rettype) == FUNCTION_TYPE)
+rettype = TREE_TYPE (rettype);
+
+ if (VOID_TYPE_P (rettype))
+{
+ warning_at (DECL_SOURCE_LOCATION (decl), OPT_Wattributes,
+ "%qE attribute ignored on a function returning %qT.",
+ name, rettype);
+ *no_add_attrs = true;
+ return NULL_TREE;
+}
+
+ if (!positional_argument (TREE_TYPE (decl), name, TREE_VALUE (args),
+ TREE_CODE (rettype)))
+{
+ *no_add_attrs = true;
+ return NULL_TREE;
+}
+
+ *no_add_attrs = false;
+ gcc_assert (args);
+ tree val = TREE_VALUE (args);
+ unsigned HOST_WIDE_INT argnum = tree_to_uhwi (val);
+
+ if (argnum >= 4)
+sorry ("returns_arg attr can only be applied to first four args.\n");
+
+ char s[2];
+ s[0] = argnum + '0';
+ s[1] = '\0';
+
+ tree attr = tree_cons (get_identifier ("fn spec"),
+ build_tree_list (NULL_TREE, build_string (1, s)),
+ NULL_TREE);
+ decl_attributes (node, attr, flags);
+ return NULL_TREE;
+}
+
/* Attempt to partially validate a single attribute ATTR as if
it were to be applied to an entity OPER. */
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index ec99c38a607..3531e0c8292 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -3566,6 +3566,19 @@ diagnosed. Because a pure function cannot have any observable side
effects it does not make sense for such a function to re
Re: [PATCH] wwwdocs: document scripts to access personal and vendor spaces
On 24/01/2020 11:04, Jonathan Wakely wrote: On 23/01/20 16:23 +, Richard Earnshaw (lists) wrote: On 21/01/2020 18:58, Richard Earnshaw (lists) wrote: This patch documents some of the scripts that I've published for managing the personal and vendor spaces on the server. It also covers some of the other features that those scripts enable, so that it's all in one place. This is a complete rewrite of the material I had written previously since before we did not have these scripts to make use of. I've not filled in the documentation for gcc-descr and gcc-undescr, Jakub has agreed to provide that at a later date. R. I've pushed this. I think it's better to have this in than nothing at all. We can iterate on it as required. I've pushed the attached fix for a couple of typos. Do we want to repeat the "do not push changes to that space without their express permission" for user branches? There are no access checks to prevent it, but I hsouldn't be changing things in your branches without your permission. Absolutely. I guess I took this as read in the personal spaces. Finally, why does this qualify it as "If you have multiple clones"? If you have multiple clones of the gcc repository you can fetch updates from your personal space by running git fetch me Isn't that the right command even if you only have one clone? Well, if you only have one clone, why would you need to pull branches from upstream that you pushed yourself? In fact, why would you even need to push them in that case, unless it's for backup? ... and if you're restoring your backup, then that's a new clone. You might temporally have only only one clone, but across all time you have more than one. It's pedantry, though, so feel free to re-word it. Thanks for the tweaks, anyway. R.
Re: [PATCH] wwwdocs: document scripts to access personal and vendor spaces
On 24/01/20 11:48 +, Richard Earnshaw (lists) wrote: On 24/01/2020 11:04, Jonathan Wakely wrote: On 23/01/20 16:23 +, Richard Earnshaw (lists) wrote: On 21/01/2020 18:58, Richard Earnshaw (lists) wrote: This patch documents some of the scripts that I've published for managing the personal and vendor spaces on the server. It also covers some of the other features that those scripts enable, so that it's all in one place. This is a complete rewrite of the material I had written previously since before we did not have these scripts to make use of. I've not filled in the documentation for gcc-descr and gcc-undescr, Jakub has agreed to provide that at a later date. R. I've pushed this. I think it's better to have this in than nothing at all. We can iterate on it as required. I've pushed the attached fix for a couple of typos. Do we want to repeat the "do not push changes to that space without their express permission" for user branches? There are no access checks to prevent it, but I hsouldn't be changing things in your branches without your permission. Absolutely. I guess I took this as read in the personal spaces. If we don't document it, somebody will get it wrong :-) Maybe like so, after the "To create a new personal branch" paragraph: Personal spaces are controlled by the individual user. Do not push changes to somebody else's space without their express permission. (Rather than pushing to somebody else's personal branch, consider pushing to your own personal branch and having collaborators pull from there). Is the parenthesis going into too much detail, too early? This page doesn't describe how to pull from somebody else's personal branch (and arguably that would be too much info here anyway, but it might make sense for https://gcc.gnu.org/wiki/GitCookbook instead). So maybe just the part in . Finally, why does this qualify it as "If you have multiple clones"? If you have multiple clones of the gcc repository you can fetch updates from your personal space by running git fetch me Isn't that the right command even if you only have one clone? Well, if you only have one clone, why would you need to pull branches from upstream that you pushed yourself? Good point. In fact, why would you even need to push them in that case, unless it's for backup? ... and if So other people can see your work in progress (without the overhead of setting up a devel/* branch for a short-lived topic branch). you're restoring your backup, then that's a new clone. You might temporally have only only one clone, but across all time you have more than one. Right. I was stuck in small-minded, non-distributed thinking :-) It's pedantry, though, so feel free to re-word it. How about: "You can fetch updates from your personal space into some other clone of the repository (e.g. on a machine used for testing) by running:"
[patch] Bogus __has_include handling
I noticed, but ignored this code when addressing p80005, but having
fixed up defined(X) on the modules branch, I could see where it came
from, and it's obviously wrong as we've just pulled out a string
contant from the token.
pushed to trunk.
nathan
--
Nathan Sidwell
2020-01-24 Nathan Sidwell
* expr.c (parse_has_include): Remove bogus controlling macro code.
diff --git i/libcpp/expr.c w/libcpp/expr.c
index df21a4b9fb9..6c56803e3b0 100644
--- i/libcpp/expr.c
+++ w/libcpp/expr.c
@@ -2211,14 +2211,12 @@ parse_has_include (cpp_reader *pfile, cpp_hashnode *op, include_type type)
pfile->state.angled_headers = false;
bool bracket = token->type != CPP_STRING;
- cpp_hashnode *node = NULL;
char *fname = NULL;
if (token->type == CPP_STRING || token->type == CPP_HEADER_NAME)
{
fname = XNEWVEC (char, token->val.str.len - 1);
memcpy (fname, token->val.str.text + 1, token->val.str.len - 2);
fname[token->val.str.len - 2] = '\0';
- node = token->val.node.node;
}
else if (token->type == CPP_LESS)
fname = _cpp_bracket_include (pfile);
@@ -2241,8 +2239,5 @@ parse_has_include (cpp_reader *pfile, cpp_hashnode *op, include_type type)
cpp_error (pfile, CPP_DL_ERROR,
"missing ')' after \"%s\" operand", NODE_NAME (op));
- if (node)
-pfile->mi_ind_cmacro = node;
-
return result;
}
Re: [PATCH] dojump: Fix gcc.dg/torture/pr91323.c for aarch64 targets
Ping
Richard Sandiford writes:
> PR91323 was fixed for x86 and sparc in target code, but aarch64
> instead relies on the target-independent comparison splitters.
> Since LTGT is an unordered-signalling operation, we should split
> it into unordered-signalling operations for any input that could
> be NaN, not just inputs that could be signalling NaNs.
>
> Tested on aarch64-linux-gnu and x86_64-linux-gnu. OK to install?
>
> Richard
>
>
> 2020-01-17 Richard Sandiford
>
> gcc/
> * dojump.c (split_comparison): Use HONOR_NANS rather than
> HONOR_SNANS when splitting LTGT.
> ---
> gcc/dojump.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/gcc/dojump.c b/gcc/dojump.c
> index 7bf578a7178..28b47b7ab6d 100644
> --- a/gcc/dojump.c
> +++ b/gcc/dojump.c
> @@ -897,7 +897,7 @@ split_comparison (enum rtx_code code, machine_mode mode,
>return false;
> case LTGT:
>/* Do not turn a trapping comparison into a non-trapping one. */
> - if (HONOR_SNANS (mode))
> + if (HONOR_NANS (mode))
> {
>*code1 = LT;
>*code2 = GT;
Re: [RFC c-common PATCH] PR c++/40752 - useless -Wconversion with short +=.
Jason, There is no ChangeLog entry for the testsuite changes. I'm also still trying to determine if Wconversion-pr40752.c requires -fsigned-char option. Thanks, David
Re: [PATCH] wwwdocs: document scripts to access personal and vendor spaces
On 24/01/2020 12:19, Jonathan Wakely wrote: On 24/01/20 11:48 +, Richard Earnshaw (lists) wrote: On 24/01/2020 11:04, Jonathan Wakely wrote: On 23/01/20 16:23 +, Richard Earnshaw (lists) wrote: On 21/01/2020 18:58, Richard Earnshaw (lists) wrote: This patch documents some of the scripts that I've published for managing the personal and vendor spaces on the server. It also covers some of the other features that those scripts enable, so that it's all in one place. This is a complete rewrite of the material I had written previously since before we did not have these scripts to make use of. I've not filled in the documentation for gcc-descr and gcc-undescr, Jakub has agreed to provide that at a later date. R. I've pushed this. I think it's better to have this in than nothing at all. We can iterate on it as required. I've pushed the attached fix for a couple of typos. Do we want to repeat the "do not push changes to that space without their express permission" for user branches? There are no access checks to prevent it, but I hsouldn't be changing things in your branches without your permission. Absolutely. I guess I took this as read in the personal spaces. If we don't document it, somebody will get it wrong :-) Maybe like so, after the "To create a new personal branch" paragraph: Personal spaces are controlled by the individual user. Do not push changes to somebody else's space without their express permission. (Rather than pushing to somebody else's personal branch, consider pushing to your own personal branch and having collaborators pull from there). Is the parenthesis going into too much detail, too early? This page doesn't describe how to pull from somebody else's personal branch (and arguably that would be too much info here anyway, but it might make sense for https://gcc.gnu.org/wiki/GitCookbook instead). I think the 'pull' model is probably preferable for personal spaces. At some point we might need to enforce something like that anyway. So maybe just the part in . Finally, why does this qualify it as "If you have multiple clones"? If you have multiple clones of the gcc repository you can fetch updates from your personal space by running git fetch me Isn't that the right command even if you only have one clone? Well, if you only have one clone, why would you need to pull branches from upstream that you pushed yourself? Good point. In fact, why would you even need to push them in that case, unless it's for backup? ... and if So other people can see your work in progress (without the overhead of setting up a devel/* branch for a short-lived topic branch). you're restoring your backup, then that's a new clone. You might temporally have only only one clone, but across all time you have more than one. Right. I was stuck in small-minded, non-distributed thinking :-) It's pedantry, though, so feel free to re-word it. How about: "You can fetch updates from your personal space into some other clone of the repository (e.g. on a machine used for testing) by running:" Yes, that's fine. Note, that I spotted a problem with the simple "me" remote, in that git gets confused if you have both refs/heads// and refs/remotes// (checking out me/ results in complaints about an ambiguous ref). I'm currently reworking my scripts to use users/ for the remote, much like the 'vendors' space. Watch this space... R.
contrib: Change 'remote' for personal branches and add branch creation script
Whilst trying to convert the add vendor branch script to work with
personal branches I encountered a minor issue where git would report
ambiguous refs when checking out the new branch.
It turns out that this is because git considers / to be
ambiguous if both
refs/heads//
and
refs/remotes//
exist in the list of known branches.
Having thought about this a bit, I think the best solution is to adopt
something more like the vendors space and call the remote users/
(this also works better if you want to set up remotes to track other
users branches as well).
So this patch has two parts.
1) It updates gcc-git-customization.sh to set up the new 'remote' and
converts any existing remote and branches tracking that to the new format
2) It adds a new script to set up a personal branch on the gcc git
repository.
I'll produce an update to wwwdocs/.../gitwrite.html to cover these
changes shortly.
R.
* gcc-git-customization.sh: Use users/ for the personal remote
rather than just . Convert any existing user branches to the
new remote.
* git-add-user-branch.sh: New file.
diff --git a/contrib/gcc-git-customization.sh b/contrib/gcc-git-customization.sh
index c16db747503..f3e48316ead 100755
--- a/contrib/gcc-git-customization.sh
+++ b/contrib/gcc-git-customization.sh
@@ -128,7 +128,7 @@ url=$(git config --get "remote.${upstream}.url")
pushurl=$(git config --get "remote.${upstream}.pushurl")
for v in $vendors
do
-echo "Migrating vendor $v to new remote vendors/$v"
+echo "Migrating vendor \"$v\" to new remote \"vendors/$v\""
git config --unset-all "remote.${upstream}.fetch" "refs/vendors/$v/"
git config --unset-all "remote.${upstream}.push" "refs/vendors/$v/"
git config "remote.vendors/${v}.url" "${url}"
@@ -140,15 +140,36 @@ do
git config --add "remote.vendors/${v}.fetch" "+refs/vendors/$v/tags/*:refs/tags/vendors/${v}/*"
done
-echo "Setting up tracking for personal namespace $remote_id in remotes/${new_pfx}"
-git config "remote.${new_pfx}.url" "${url}"
+# Convert the remote 'pfx' to users/pfx to avoid problems with ambiguous refs
+# on user branches
+old_remote=$(git config --get "remote.${old_pfx}.url")
+if [ -n "${old_remote}" ]
+then
+echo "Migrating remote \"${old_pfx}\" to new remote \"users/${new_pfx}\""
+# Create a dummy fetch rule that will cause the subsequent prune to remove the old remote refs.
+git config --replace-all "remote.${old_pfx}.fetch" "+refs/empty/*:refs/remotes/${old_pfx}/*"
+# Remove any remotes
+git remote prune ${old_pfx}
+git config --remove-section "remote.${old_pfx}"
+for br in $(git branch --list "${old_pfx}/*")
+do
+ old_remote=$(git config --get "branch.${br}.remote")
+ if [ "${old_remote}" = "${old_pfx}" ]
+ then
+ git config "branch.${br}.remote" "users/${new_pfx}"
+ fi
+done
+fi
+
+echo "Setting up tracking for personal namespace $remote_id in remotes/users/${new_pfx}"
+git config "remote.users/${new_pfx}.url" "${url}"
if [ "x$pushurl" != "x" ]
then
-git config "remote.${new_pfx}.pushurl" "${pushurl}"
+git config "remote.users/${new_pfx}.pushurl" "${pushurl}"
fi
-git config --replace-all "remote.${new_pfx}.fetch" "+refs/users/${remote_id}/heads/*:refs/remotes/${new_pfx}/*" ":refs/remotes/${old_pfx}/"
-git config --replace-all "remote.${new_pfx}.fetch" "+refs/users/${remote_id}/tags/*:refs/tags/${new_pfx}/*" ":refs/tags/${old_pfx}/"
-git config --replace-all "remote.${new_pfx}.push" "refs/heads/${new_pfx}/*:refs/users/${remote_id}/heads/*" ":refs/users/${remote_id}"
+git config --replace-all "remote.users/${new_pfx}.fetch" "+refs/users/${remote_id}/heads/*:refs/remotes/users/${new_pfx}/*" "refs/users/${remote_id}/heads/"
+git config --replace-all "remote.users/${new_pfx}.fetch" "+refs/users/${remote_id}/tags/*:refs/tags/users/${new_pfx}/*" "refs/users/${remote_id}/tags/"
+git config --replace-all "remote.users/${new_pfx}.push" "refs/heads/${new_pfx}/*:refs/users/${remote_id}/heads/*" "refs/users/${remote_id}"
if [ "$old_pfx" != "$new_pfx" -a "$old_pfx" != "${upstream}" ]
then
@@ -157,3 +178,5 @@ fi
git config --unset-all "remote.${upstream}.fetch" "refs/users/${remote_id}/"
git config --unset-all "remote.${upstream}.push" "refs/users/${remote_id}/"
+
+git fetch "users/${new_pfx}"
diff --git a/contrib/git-add-user-branch.sh b/contrib/git-add-user-branch.sh
new file mode 100755
index 000..e014f7518fb
--- /dev/null
+++ b/contrib/git-add-user-branch.sh
@@ -0,0 +1,46 @@
+#! /bin/sh -e
+
+# Create a new upstream user branch.
+
+# Usage:
+# contrib/git-add-user-branch.sh [/]
+
+usage ()
+{
+echo "Usage:"
+echo " $0 [/] "
+echo
+echo "personal space must already have been set up using"
+echo "contrib/gcc-git-customization.sh"
+exit 1
+}
+
+if [ $# != 2 ]
+then
+usage
+fi
+
+userpfx=$(git config --get "gcc-config.userpfx")
+user=$(git config --get "gcc-config.user")
+
+if [ -z "$userpfx" -o -z "$user" ]
+then
+
Re: [committed v4] Add `--with-toolexeclibdir=' configuration option
On Fri, Jan 24, 2020 at 3:27 AM Maciej W. Rozycki wrote: > > Provide means, in the form of a `--with-toolexeclibdir=' configuration > option, to override the default installation directory for target > libraries, otherwise known as $toolexeclibdir. This is so that it is > possible to get newly-built libraries, particularly the shared ones, > installed in a common place, so that they can be readily used by the > target system as their host libraries, possibly over NFS, without a need > to manually copy them over from the currently hardcoded location they > would otherwise be installed in. > > In the presence of the `--enable-version-specific-runtime-libs' option > and for configurations building native GCC the option is ignored. > > --- > On Mon, 20 Jan 2020, Ian Lance Taylor wrote: > > > > 2. push all the bits sans the libgo/ part and you'll push the libgo/ part > > >to your repo and then you'll merge it to GCC. > > > > > > There is a slight technical advantage to going with #1 as there'll be no > > > window where the new option is not consistently supported; it's also less > > > work as you won't have to do the merge. But I have no strong preference > > > either way. > > > > I'd rather do #2. Thanks. A small window is unlikely to matter to > > anyone. Let me know when the rest of the patch is committed. > > This is the version I have committed. I've also attached the libgo part > with a ChangeLog entry for your convenience (you'll have to write your own > change description though). Thanks. Committed upstream and to GCC master. Ian
[committed, amdgcn] Fix ICE on unsupported FP comparison
I've committed this patch to fix an ICE building the gcc.dg/vect/fast-math-pr55281.c testcase. The problem was that the combine pass was trying to use the "unle" and "ungt" FP comparison operators. There's no hardware support for these, so the operators should have been rejected, but the predicates were too loose. Andrew Fix ICE on unsupported FP comparison 2020-01-24 Andrew Stubbs gcc/ * config/gcn/gcn-valu.md (vec_cmpdi): Use gcn_fp_compare_operator. (vec_cmpudi): Use gcn_compare_operator. (vec_cmpv64qidi): Use gcn_compare_operator. (vec_cmpdi_exec): Use gcn_fp_compare_operator. (vec_cmpudi_exec): Use gcn_compare_operator. (vec_cmpv64qidi_exec): Use gcn_compare_operator. (vec_cmpdi_dup): Use gcn_fp_compare_operator. (vec_cmpdi_dup_exec): Use gcn_fp_compare_operator. (vcond): Use gcn_fp_compare_operator. (vcond_exec): Use gcn_fp_compare_operator. (vcondu): Use gcn_fp_compare_operator. (vcondu_exec): Use gcn_fp_compare_operator. diff --git a/gcc/config/gcn/gcn-valu.md b/gcc/config/gcn/gcn-valu.md index 7c3de8cbc7e..331c768cb88 100644 --- a/gcc/config/gcn/gcn-valu.md +++ b/gcc/config/gcn/gcn-valu.md @@ -2530,7 +2530,7 @@ (define_insn "vec_cmpdi" [(set (match_operand:DI 0 "register_operand" "=cV,cV, e, e,Sg,Sg") - (match_operator 1 "comparison_operator" + (match_operator 1 "gcn_fp_compare_operator" [(match_operand:VCMP_MODE 2 "gcn_alu_operand" "vSv, B,vSv, B, v,vA") (match_operand:VCMP_MODE 3 "gcn_vop3_operand" @@ -2549,7 +2549,7 @@ (define_expand "vec_cmpudi" [(match_operand:DI 0 "register_operand") - (match_operator 1 "comparison_operator" + (match_operator 1 "gcn_compare_operator" [(match_operand:VCMP_MODE_INT 2 "gcn_alu_operand") (match_operand:VCMP_MODE_INT 3 "gcn_vop3_operand")])] "" @@ -2565,7 +2565,7 @@ ; There's no instruction for 8-bit vector comparison, so we need to extend. (define_expand "vec_cmpv64qidi" [(match_operand:DI 0 "register_operand") - (match_operator 1 "comparison_operator" + (match_operator 1 "gcn_compare_operator" [(any_extend:V64SI (match_operand:V64QI 2 "gcn_alu_operand")) (any_extend:V64SI (match_operand:V64QI 3 "gcn_vop3_operand"))])] "can_create_pseudo_p ()" @@ -2582,7 +2582,7 @@ (define_insn "vec_cmpdi_exec" [(set (match_operand:DI 0 "register_operand" "=cV,cV, e, e,Sg,Sg") (and:DI - (match_operator 1 "comparison_operator" + (match_operator 1 "gcn_fp_compare_operator" [(match_operand:VCMP_MODE 2 "gcn_alu_operand" "vSv, B,vSv, B, v,vA") (match_operand:VCMP_MODE 3 "gcn_vop3_operand" @@ -2602,7 +2602,7 @@ (define_expand "vec_cmpudi_exec" [(match_operand:DI 0 "register_operand") - (match_operator 1 "comparison_operator" + (match_operator 1 "gcn_compare_operator" [(match_operand:VCMP_MODE_INT 2 "gcn_alu_operand") (match_operand:VCMP_MODE_INT 3 "gcn_vop3_operand")]) (match_operand:DI 4 "gcn_exec_reg_operand")] @@ -2619,7 +2619,7 @@ (define_expand "vec_cmpv64qidi_exec" [(match_operand:DI 0 "register_operand") - (match_operator 1 "comparison_operator" + (match_operator 1 "gcn_compare_operator" [(any_extend:V64SI (match_operand:V64QI 2 "gcn_alu_operand")) (any_extend:V64SI (match_operand:V64QI 3 "gcn_vop3_operand"))]) (match_operand:DI 4 "gcn_exec_reg_operand")] @@ -2639,7 +2639,7 @@ (define_insn "vec_cmpdi_dup" [(set (match_operand:DI 0 "register_operand" "=cV,cV, e,e,Sg") - (match_operator 1 "comparison_operator" + (match_operator 1 "gcn_fp_compare_operator" [(vec_duplicate:VCMP_MODE (match_operand: 2 "gcn_alu_operand" " Sv, B,Sv,B, A")) @@ -2658,7 +2658,7 @@ (define_insn "vec_cmpdi_dup_exec" [(set (match_operand:DI 0 "register_operand" "=cV,cV, e,e,Sg") (and:DI - (match_operator 1 "comparison_operator" + (match_operator 1 "gcn_fp_compare_operator" [(vec_duplicate:VCMP_MODE (match_operand: 2 "gcn_alu_operand" " Sv, B,Sv,B, A")) @@ -2690,7 +2690,7 @@ [(match_operand:VEC_ALLREG_MODE 0 "register_operand") (match_operand:VEC_ALLREG_MODE 1 "gcn_vop3_operand") (match_operand:VEC_ALLREG_MODE 2 "gcn_alu_operand") - (match_operator 3 "comparison_operator" + (match_operator 3 "gcn_fp_compare_operator" [(match_operand:VEC_ALLREG_ALT 4 "gcn_alu_operand") (match_operand:VEC_ALLREG_ALT 5 "gcn_vop3_operand")])] "" @@ -2707,7 +2707,7 @@ [(match_operand:VEC_ALLREG_MODE 0 "register_operand") (match_operand:VEC_ALLREG_MODE 1 "gcn_vop3_operand") (match_operand:VEC_ALLREG_MODE 2 "gcn_alu_operand") - (match_operator 3 "comparison_operator" + (match_operator 3 "gcn_fp_compare_operator" [(match_operand:VEC_ALLREG_ALT 4 "gcn_alu_operand") (match_operand:VEC_ALLREG_ALT 5 "gcn_vop3_operand")]) (match_operand:DI 6 "gcn_exec_reg_operand" "e")] @@ -2725,7 +2725,7 @@ [(match_operand:VEC_ALLREG_MODE 0 "register_operand") (match_operand:VEC_ALLREG_MODE 1 "gcn_v
[Patch] [libgomp, build] Skip plugin-{gcn,hsa} for (-m)x32 (PR bootstrap/93409)
As reported in PR93409, the build of libgomp/plugin/plugin-gcn.c fails
with a bunch of error messages when building with
--with-multilib-list=m32,m64,mx32
The reason is that the GCN plugin assumes 64bit pointers. As with HSA,
the build is only enabled for x86-64 and "-m32" is excluded. — However,
it seems as if it makes sense to exclude also "-mx32".
This patch was tested with -m32/-m64 multilib as I do not have a -mx32
setup.
OK for the trunk?
Tobias
PS: PowerPC support for ROCm was recently added, cf.
https://www.phoronix.com/scan.php?page=news_item&px=AMDKFD-Compute-POWERPC
— And, if I understood it correctly, 32bit support would be possible but
requires work on multiple ends and no one works on it.
PR bootstrap/93409
* plugin/configfrag.ac (enable_offload_targets): Skip
HSA and GCN plugin besides -m32 also for -mx32.
* configure: Regenerate.
diff --git a/libgomp/configure b/libgomp/configure
index 04a6fd96610..404b677e5f1 100755
--- a/libgomp/configure
+++ b/libgomp/configure
@@ -14991,7 +14991,7 @@ fi
# Plugins for offload execution, configure.ac fragment. -*- mode: autoconf -*-
#
-# Copyright (C) 2014-2019 Free Software Foundation, Inc.
+# Copyright (C) 2014-2020 Free Software Foundation, Inc.
#
# Contributed by Mentor Embedded.
#
@@ -15320,7 +15320,7 @@ rm -f core conftest.err conftest.$ac_objext \
case "${target}" in
x86_64-*-*)
case " ${CC} ${CFLAGS} " in
- *" -m32 "*)
+ *" -m32 "*|*" -mx32 "*)
PLUGIN_HSA=0
;;
*)
@@ -15360,7 +15360,7 @@ rm -f core conftest.err conftest.$ac_objext \
case "${target}" in
x86_64-*-*)
case " ${CC} ${CFLAGS} " in
- *" -m32 "*)
+ *" -m32 "*|*" -mx32 "*)
PLUGIN_GCN=0
;;
*)
diff --git a/libgomp/plugin/configfrag.ac b/libgomp/plugin/configfrag.ac
index 9a424aa1c9c..fc91702a434 100644
--- a/libgomp/plugin/configfrag.ac
+++ b/libgomp/plugin/configfrag.ac
@@ -211,7 +211,7 @@ if test x"$enable_offload_targets" != x; then
case "${target}" in
x86_64-*-*)
case " ${CC} ${CFLAGS} " in
- *" -m32 "*)
+ *" -m32 "*|*" -mx32 "*)
PLUGIN_HSA=0
;;
*)
@@ -251,7 +251,7 @@ if test x"$enable_offload_targets" != x; then
case "${target}" in
x86_64-*-*)
case " ${CC} ${CFLAGS} " in
- *" -m32 "*)
+ *" -m32 "*|*" -mx32 "*)
PLUGIN_GCN=0
;;
*)
Re: [PATCH] wwwdocs: document scripts to access personal and vendor spaces
On 24/01/20 13:55 +, Richard Earnshaw (lists) wrote: On 24/01/2020 12:19, Jonathan Wakely wrote: On 24/01/20 11:48 +, Richard Earnshaw (lists) wrote: On 24/01/2020 11:04, Jonathan Wakely wrote: On 23/01/20 16:23 +, Richard Earnshaw (lists) wrote: On 21/01/2020 18:58, Richard Earnshaw (lists) wrote: This patch documents some of the scripts that I've published for managing the personal and vendor spaces on the server. It also covers some of the other features that those scripts enable, so that it's all in one place. This is a complete rewrite of the material I had written previously since before we did not have these scripts to make use of. I've not filled in the documentation for gcc-descr and gcc-undescr, Jakub has agreed to provide that at a later date. R. I've pushed this. I think it's better to have this in than nothing at all. We can iterate on it as required. I've pushed the attached fix for a couple of typos. Do we want to repeat the "do not push changes to that space without their express permission" for user branches? There are no access checks to prevent it, but I hsouldn't be changing things in your branches without your permission. Absolutely. I guess I took this as read in the personal spaces. If we don't document it, somebody will get it wrong :-) Maybe like so, after the "To create a new personal branch" paragraph: Personal spaces are controlled by the individual user. Do not push changes to somebody else's space without their express permission. (Rather than pushing to somebody else's personal branch, consider pushing to your own personal branch and having collaborators pull from there). Is the parenthesis going into too much detail, too early? This page doesn't describe how to pull from somebody else's personal branch (and arguably that would be too much info here anyway, but it might make sense for https://gcc.gnu.org/wiki/GitCookbook instead). I think the 'pull' model is probably preferable for personal spaces. At some point we might need to enforce something like that anyway. So maybe just the part in . Finally, why does this qualify it as "If you have multiple clones"? If you have multiple clones of the gcc repository you can fetch updates from your personal space by running git fetch me Isn't that the right command even if you only have one clone? Well, if you only have one clone, why would you need to pull branches from upstream that you pushed yourself? Good point. In fact, why would you even need to push them in that case, unless it's for backup? ... and if So other people can see your work in progress (without the overhead of setting up a devel/* branch for a short-lived topic branch). you're restoring your backup, then that's a new clone. You might temporally have only only one clone, but across all time you have more than one. Right. I was stuck in small-minded, non-distributed thinking :-) It's pedantry, though, so feel free to re-word it. How about: "You can fetch updates from your personal space into some other clone of the repository (e.g. on a machine used for testing) by running:" Yes, that's fine. OK, I've pushed the attached patch. commit 0bce4cca846fa1d79f080d2784f90aaa5c447e2b Author: Jonathan Wakely Date: Fri Jan 24 15:00:57 2020 + Adjust docs on personal Git branches diff --git a/htdocs/gitwrite.html b/htdocs/gitwrite.html index c0fe8526..5b631607 100644 --- a/htdocs/gitwrite.html +++ b/htdocs/gitwrite.html @@ -424,8 +424,8 @@ some aliases that might be useful when developing GCC. The script will settings configured by the script will still be useful. -If you have multiple clones of the gcc repository you can fetch -updates from your personal space by running +You can fetch updates from your personal space into some other clone +of the repository (e.g. on a machine used for testing) by running git fetch me (or whatever personal prefix you've chosen). You can also push an already existing branch using git push me me/branch. @@ -444,6 +444,12 @@ used: If you've used a different personal prefix to 'me' then use that in the sequence described above. +Personal spaces are controlled by the individual user. Do not push +changes to somebody else's space without their express permission. +(Rather than pushing to somebody else's personal branch, consider pushing +to your own personal branch and having collaborators pull from there.) + + The script also defines a few useful aliases that can be used with the repository:
[committed] wwwdocs: gitwrite: tweaks for the change in the personal branch support
As described in https://gcc.gnu.org/ml/gcc-patches/2020-01/msg01660.html I've had to change the personal branch space configuration slightly to avoid problems with ambiguous refs. This patch updates wwwdocs to reflect that change. It also adds documentation for the new contrib/git-add-user-branch.sh script. Applied. R. diff --git a/htdocs/gitwrite.html b/htdocs/gitwrite.html index c0fe8526..55667a2d 100644 --- a/htdocs/gitwrite.html +++ b/htdocs/gitwrite.html @@ -424,25 +424,17 @@ some aliases that might be useful when developing GCC. The script will settings configured by the script will still be useful. -If you have multiple clones of the gcc repository you can fetch +If you have personal branches pushed to the gcc repository you can fetch updates from your personal space by running - git fetch me -(or whatever personal prefix you've chosen). You can also push an -already existing branch using git push me me/branch. -Beware that if you have more than one personal branch set up locally, -simply typing git push me will potentially push all such -personal branches. Use --dry-run to check that what will be pushed is -what you intend. - -To create a new personal branch, the following sequence of steps can be -used: - - git push me:refs/users/ /heads/ - git fetch me - git checkout -b me/ remotes/me/ - -If you've used a different personal prefix to 'me' then use that - in the sequence described above. +git fetch users/me (or whatever personal prefix you've +chosen). You can also push an already existing branch using git +push users/me me/branch. Beware that if you have more than one +personal branch set up locally, simply typing git push +users/me will potentially push all personal branches based on +that remote. Use --dry-run to check that what will be pushed is what +you intend. The script contrib/git-add-user-branch.sh +can be used to create a new personal branch which can be pushed and +pulled from the users/me remote. The script also defines a few useful aliases that can be used with the repository: @@ -523,6 +515,28 @@ This will create the branch both locally and on the server, but will not check the branch out locally. You can do that afterwards with git checkout or git worktree. +contrib/git-add-user-branch.sh + +before this script can be used, your personal space access should be + set up by running contrib/gcc-git-cusomization.sh. + +The script takes two arguments, the name of the new branch to create + and a ref to create it from. The personal prefix for the new + branch is optional and will be automatically added if omitted. For example, + if your personal prefix is the default (me), then running: + + +contrib/git-add-user-branch.sh topic master + + +will set up a branch called topic on the server and a + local branch called me/topic that tracks it. The banch + can then be pushed using: + + +git push users/me me/topic + + Tips&Tricks around your account
Re: [PATCH] wwwdocs: document scripts to access personal and vendor spaces
On 24/01/20 15:09 +, Jonathan Wakely wrote: On 24/01/20 13:55 +, Richard Earnshaw (lists) wrote: On 24/01/2020 12:19, Jonathan Wakely wrote: On 24/01/20 11:48 +, Richard Earnshaw (lists) wrote: On 24/01/2020 11:04, Jonathan Wakely wrote: On 23/01/20 16:23 +, Richard Earnshaw (lists) wrote: On 21/01/2020 18:58, Richard Earnshaw (lists) wrote: This patch documents some of the scripts that I've published for managing the personal and vendor spaces on the server. It also covers some of the other features that those scripts enable, so that it's all in one place. This is a complete rewrite of the material I had written previously since before we did not have these scripts to make use of. I've not filled in the documentation for gcc-descr and gcc-undescr, Jakub has agreed to provide that at a later date. R. I've pushed this. I think it's better to have this in than nothing at all. We can iterate on it as required. I've pushed the attached fix for a couple of typos. Do we want to repeat the "do not push changes to that space without their express permission" for user branches? There are no access checks to prevent it, but I hsouldn't be changing things in your branches without your permission. Absolutely. I guess I took this as read in the personal spaces. If we don't document it, somebody will get it wrong :-) Maybe like so, after the "To create a new personal branch" paragraph: Personal spaces are controlled by the individual user. Do not push changes to somebody else's space without their express permission. (Rather than pushing to somebody else's personal branch, consider pushing to your own personal branch and having collaborators pull from there). Is the parenthesis going into too much detail, too early? This page doesn't describe how to pull from somebody else's personal branch (and arguably that would be too much info here anyway, but it might make sense for https://gcc.gnu.org/wiki/GitCookbook instead). I think the 'pull' model is probably preferable for personal spaces. At some point we might need to enforce something like that anyway. So maybe just the part in . Finally, why does this qualify it as "If you have multiple clones"? If you have multiple clones of the gcc repository you can fetch updates from your personal space by running git fetch me Isn't that the right command even if you only have one clone? Well, if you only have one clone, why would you need to pull branches from upstream that you pushed yourself? Good point. In fact, why would you even need to push them in that case, unless it's for backup? ... and if So other people can see your work in progress (without the overhead of setting up a devel/* branch for a short-lived topic branch). you're restoring your backup, then that's a new clone. You might temporally have only only one clone, but across all time you have more than one. Right. I was stuck in small-minded, non-distributed thinking :-) It's pedantry, though, so feel free to re-word it. How about: "You can fetch updates from your personal space into some other clone of the repository (e.g. on a machine used for testing) by running:" Yes, that's fine. OK, I've pushed the attached patch. Oops, wrong patch, *this* is what I pushed. commit f526c4724b183482fc7fe1a5ce78e1597fd1005f Author: Jonathan Wakely Date: Fri Jan 24 15:00:57 2020 + Adjust docs on personal Git branches diff --git a/htdocs/gitwrite.html b/htdocs/gitwrite.html index 55667a2d..b5d7ff35 100644 --- a/htdocs/gitwrite.html +++ b/htdocs/gitwrite.html @@ -436,6 +436,12 @@ you intend. The script contrib/git-add-user-branch.sh can be used to create a new personal branch which can be pushed and pulled from the users/me remote. +Personal spaces are controlled by the individual user. Do not push +changes to somebody else's space without their express permission. +(Rather than pushing to somebody else's personal branch, consider pushing +to your own personal branch and having collaborators pull from there.) + + The script also defines a few useful aliases that can be used with the repository:
[PATCH] wwwdocs: Document support for extended identifiers added to GCC 10
Hello-
There was a comment on PR67224:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67224#c33 suggesting to
document this feature in changes.html. Here would be my suggestion, in case
that's desirable. Thanks!
-Lewis
commit 6aad009fb93ced5fc79867a79a9021adec0d23d1
Author: Lewis Hyatt
Date: Tue Jan 14 18:52:20 2020 -0500
Document support for extended identifiers added to GCC 10 in changes.html
diff --git a/htdocs/gcc-10/changes.html b/htdocs/gcc-10/changes.html
index ef27c9bb..1f6c03cd 100644
--- a/htdocs/gcc-10/changes.html
+++ b/htdocs/gcc-10/changes.html
@@ -204,6 +204,15 @@ a work-in-progress.
with the new attribute access.
+ Extended characters in identifiers may now be specified directly in
+ the input encoding (UTF-8, by default), in addition to the UCN syntax
+ (\u or \U) that is already
+ supported:
+
+static const int π = 3;
+int get_naïve_pi() {
+ return π;
+}
C
[PATCH] wwwdocs: Two patches committed to gcc-10 release notes
I've pushed these to wwwdocs. commit b1bd21c81af3bc3098fca4293af164a6c6a4544a Author: Jonathan Wakely Date: Fri Jan 24 15:30:06 2020 + Make it clear C++2a support is experimental diff --git a/htdocs/gcc-10/changes.html b/htdocs/gcc-10/changes.html index ef27c9bb..dcce6b86 100644 --- a/htdocs/gcc-10/changes.html +++ b/htdocs/gcc-10/changes.html @@ -331,7 +331,7 @@ a work-in-progress. Runtime Library (libstdc++) - Improved C++2a support, including: + Improved experimental C++2a support, including: std::span (thanks to JeanHeyd Meneide). commit 8fdda0b261bcd59e3bed41228fe9ced40ad1397f Author: Jonathan Wakely Date: Fri Jan 24 15:29:46 2020 + Document C++ header reorganisation diff --git a/htdocs/gcc-10/porting_to.html b/htdocs/gcc-10/porting_to.html index 7d45a962..980d3af1 100644 --- a/htdocs/gcc-10/porting_to.html +++ b/htdocs/gcc-10/porting_to.html @@ -49,6 +49,26 @@ and provide solutions. Let us know if you have suggestions for improvements! extern int y; // correct declaration in a header file + +C++ language issues + +Header dependency changes + +Some C++ Standard Library headers have been changed to no longer include +theheader. +As such, C++ programs that used components defined in + or without +explicitly including the right headers will no longer compile. + + +Previously components such as std::runtime_error, +std::string and std::allocator +were implicitly defined after including unrelated headers such as + and . +Correct code should include the appropriate headers for the classes being used. + + + Fortran language issues Argument mismatches
Re: [C++ PATCH] PR c++/93299 - ICE in tsubst_copy with parenthesized expression.
Ping.
On Fri, Jan 17, 2020 at 04:03:09PM -0500, Marek Polacek wrote:
> Since e4511ca2e9ecdb51d41b64452398f8e2df575668 force_paren_expr can create
> a VIEW_CONVERT_EXPR so that we have something to set REF_PARENTHESIZED_P
> on, while not making the expression dependent. But tsubst_copy can't cope
> with such a VIEW_CONVERT_EXPR, because it's not location_wrapper_p, or
> a TEMPLATE_PARM_INDEX wrapped in a VIEW_CONVERT_EXPR.
>
> I think we need to teach tsubst_copy how to handle it. Setting
> EXPR_LOCATION_WRAPPER_P in force_paren_expr would make the ICE go away
> too, but tsubst_copy would lose the REF_PARENTHESIZED_P flag.
>
> Bootstrapped/regtested on x86_64-linux, ok for trunk and 9?
>
> * pt.c (tsubst_copy): Handle a REF_PARENTHESIZED_P VIEW_CONVERT_EXPR.
>
> * g++.dg/cpp1y/paren5.C: New test.
> ---
> gcc/cp/pt.c | 8
> gcc/testsuite/g++.dg/cpp1y/paren5.C | 12
> 2 files changed, 20 insertions(+)
> create mode 100644 gcc/testsuite/g++.dg/cpp1y/paren5.C
>
> diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
> index 1b3d07b1a52..5d3d127e528 100644
> --- a/gcc/cp/pt.c
> +++ b/gcc/cp/pt.c
> @@ -16423,6 +16423,14 @@ tsubst_copy (tree t, tree args, tsubst_flags_t
> complain, tree in_decl)
> return op;
> }
> }
> + /* force_paren_expr can also create a VIEW_CONVERT_EXPR. */
> + else if (code == VIEW_CONVERT_EXPR && REF_PARENTHESIZED_P (t))
> + {
> + op = tsubst_copy (op, args, complain, in_decl);
> + op = build1 (code, TREE_TYPE (op), op);
> + REF_PARENTHESIZED_P (op) = true;
> + return op;
> + }
> /* We shouldn't see any other uses of these in templates. */
> gcc_unreachable ();
> }
> diff --git a/gcc/testsuite/g++.dg/cpp1y/paren5.C
> b/gcc/testsuite/g++.dg/cpp1y/paren5.C
> new file mode 100644
> index 000..86a51356465
> --- /dev/null
> +++ b/gcc/testsuite/g++.dg/cpp1y/paren5.C
> @@ -0,0 +1,12 @@
> +// PR c++/93299 - ICE in tsubst_copy with parenthesized expression.
> +// { dg-do compile { target c++14 } }
> +
> +template struct A {
> + enum { b = 8 };
> +};
> +
> +template struct __attribute__((aligned((A::b D { };
> +struct S : D<0> { };
> +
> +template struct __attribute__((aligned((A::b) + N))) D2 { };
> +struct S2 : D2<0> { };
>
> base-commit: 6687d13a87c42dddc7d1c7adade38d31ba0d1401
> --
> 2.24.1
>
Marek
Re: [PATCH] wwwdocs: document scripts to access personal and vendor spaces
On 24/01/2020 15:12, Jonathan Wakely wrote: On 24/01/20 15:09 +, Jonathan Wakely wrote: On 24/01/20 13:55 +, Richard Earnshaw (lists) wrote: On 24/01/2020 12:19, Jonathan Wakely wrote: On 24/01/20 11:48 +, Richard Earnshaw (lists) wrote: On 24/01/2020 11:04, Jonathan Wakely wrote: On 23/01/20 16:23 +, Richard Earnshaw (lists) wrote: On 21/01/2020 18:58, Richard Earnshaw (lists) wrote: This patch documents some of the scripts that I've published for managing the personal and vendor spaces on the server. It also covers some of the other features that those scripts enable, so that it's all in one place. This is a complete rewrite of the material I had written previously since before we did not have these scripts to make use of. I've not filled in the documentation for gcc-descr and gcc-undescr, Jakub has agreed to provide that at a later date. R. I've pushed this. I think it's better to have this in than nothing at all. We can iterate on it as required. I've pushed the attached fix for a couple of typos. Do we want to repeat the "do not push changes to that space without their express permission" for user branches? There are no access checks to prevent it, but I hsouldn't be changing things in your branches without your permission. Absolutely. I guess I took this as read in the personal spaces. If we don't document it, somebody will get it wrong :-) Maybe like so, after the "To create a new personal branch" paragraph: Personal spaces are controlled by the individual user. Do not push changes to somebody else's space without their express permission. (Rather than pushing to somebody else's personal branch, consider pushing to your own personal branch and having collaborators pull from there). Is the parenthesis going into too much detail, too early? This page doesn't describe how to pull from somebody else's personal branch (and arguably that would be too much info here anyway, but it might make sense for https://gcc.gnu.org/wiki/GitCookbook instead). I think the 'pull' model is probably preferable for personal spaces. At some point we might need to enforce something like that anyway. So maybe just the part in . Finally, why does this qualify it as "If you have multiple clones"? If you have multiple clones of the gcc repository you can fetch updates from your personal space by running git fetch me Isn't that the right command even if you only have one clone? Well, if you only have one clone, why would you need to pull branches from upstream that you pushed yourself? Good point. In fact, why would you even need to push them in that case, unless it's for backup? ... and if So other people can see your work in progress (without the overhead of setting up a devel/* branch for a short-lived topic branch). you're restoring your backup, then that's a new clone. You might temporally have only only one clone, but across all time you have more than one. Right. I was stuck in small-minded, non-distributed thinking :-) It's pedantry, though, so feel free to re-word it. How about: "You can fetch updates from your personal space into some other clone of the repository (e.g. on a machine used for testing) by running:" Yes, that's fine. OK, I've pushed the attached patch. Oops, wrong patch, *this* is what I pushed. Thanks. On reflection, I've reworded this slightly and moved it up to the introduction to the personal and vendor spaces. The same principle applies to both. Pushed. R. diff --git a/htdocs/gitwrite.html b/htdocs/gitwrite.html index b5d7ff35..97d60870 100644 --- a/htdocs/gitwrite.html +++ b/htdocs/gitwrite.html @@ -378,7 +378,7 @@ The GCC git repository is used by many people and the branch and tag namespace would become very polluted if all branches lived at the top-level naming space. To help minimise the amount of data that needs to be fetched the git repository on gcc.gnu.org supports -having personal and vendor branches that developers use to +having personal and vendor spaces that developers use to share their work. These are not pulled by default, but simple configuration steps can give access to them. @@ -391,7 +391,14 @@ configuration steps can give access to them. in refs/vendors/vendor-name/tags. -Scripts exist in the contrib directory to help manage these spaces. +Personal and vendor spaces are controlled by the individual +user or vendor. Do not push changes to somebody else's space without +their express permission. Rather than pushing to somebody +else's branch, consider pushing to your own personal branch and having +collaborators pull from there. + + +Scripts exist in the contrib directory to help manage these spaces. contrib/gcc-git-customization.sh @@ -436,12 +443,6 @@ you intend. The script contrib/git-add-user-branch.sh can be used to create a new personal branch which can be pushed and pulled from the users/me remote. -Personal spaces are controlled by t
Re: [PATCH 2/3] Don't allow mixed component and non-component accesses for OpenACC/Fortran
Hi Julian, On 1/10/20 2:51 AM, Julian Brown wrote: Actually, it does not seem to work if one modifies the test case a bit. The following code compiles – but I think it should not: […] At least the last line has x%A%i twice but it is accepted. This bit is fixed by: https://gcc.gnu.org/ml/gcc-patches/2020-01/msg00512.html (Side remark: that's checked in gimplify_scan_omp_clauses, which is the "Duplicate components are detected elsewhere".) [ https://gcc.gnu.org/ml/gcc-patches/2020-01/msg00088.html ] OK again if that one goes in? OK from my side – but I think those patches are orthogonal, i.e. this one can go in without depending on the other one(s). Tobias
[committed] [PR target/13721] Emit reasonable diagnostic rather than ICE for bogus ASM on H8 port
This fixes a long standing minor issue with the H8 port. Again, given
the very narrow scope here, I'm going forward even though we're in
stage4.
The H8 port will ICE under the right (wrong?) circumstances when we get
an unexpected operand in an asm, particularly asms that want to output
the name of a byte sized register.
Eons ago this was a segfault. Kazu improved things with an assertion,
but really the right thing to do here is to use output_operand_lossage.
This patch protects the calls to byte_reg, ensuring it's only called
with REGs and adds calls to output_operand_lossage for the other cases.
Tested in my tester overnight with no regressions. Committed to the
trunk.
Jeff
commit 64c9f2d9972ad359a32f0a97ee0a806c2532db15
Author: Jeff Law
Date: Fri Jan 24 08:57:46 2020 -0700
Emit reasonable diagnostic rather than ICE on invalid ASM on H8 port
PR target/13721
* config/h8300/h8300.c (h8300_print_operand): Only call byte_reg
for REGs. Call output_operand_lossage to get more reasonable
diagnostics.
PR target/13721
* gcc.target/h8300/pr13721.c: New test.
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 27e5ec23409..4d851c0b170 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,10 @@
+2020-01-24 Jeff Law
+
+ PR target/13721
+ * config/h8300/h8300.c (h8300_print_operand): Only call byte_reg
+ for REGs. Call output_operand_lossage to get more reasonable
+ diagnostics.
+
2020-01-24 Andrew Stubbs
* config/gcn/gcn-valu.md (vec_cmpdi): Use
diff --git a/gcc/config/h8300/h8300.c b/gcc/config/h8300/h8300.c
index ffbfa9eaaa9..def8be344af 100644
--- a/gcc/config/h8300/h8300.c
+++ b/gcc/config/h8300/h8300.c
@@ -1647,40 +1647,52 @@ h8300_print_operand (FILE *file, rtx x, int code)
case 's':
if (GET_CODE (x) == CONST_INT)
fprintf (file, "#%ld", (INTVAL (x)) & 0xff);
- else
+ else if (GET_CODE (x) == REG)
fprintf (file, "%s", byte_reg (x, 0));
+ else
+ output_operand_lossage ("Expected register or constant integer.");
break;
case 't':
if (GET_CODE (x) == CONST_INT)
fprintf (file, "#%ld", (INTVAL (x) >> 8) & 0xff);
- else
+ else if (GET_CODE (x) == REG)
fprintf (file, "%s", byte_reg (x, 1));
+ else
+ output_operand_lossage ("Expected register or constant integer.");
break;
case 'w':
if (GET_CODE (x) == CONST_INT)
fprintf (file, "#%ld", INTVAL (x) & 0xff);
- else
+ else if (GET_CODE (x) == REG)
fprintf (file, "%s",
byte_reg (x, TARGET_H8300 ? 2 : 0));
+ else
+ output_operand_lossage ("Expected register or constant integer.");
break;
case 'x':
if (GET_CODE (x) == CONST_INT)
fprintf (file, "#%ld", (INTVAL (x) >> 8) & 0xff);
- else
+ else if (GET_CODE (x) == REG)
fprintf (file, "%s",
byte_reg (x, TARGET_H8300 ? 3 : 1));
+ else
+ output_operand_lossage ("Expected register or constant integer.");
break;
case 'y':
if (GET_CODE (x) == CONST_INT)
fprintf (file, "#%ld", (INTVAL (x) >> 16) & 0xff);
- else
+ else if (GET_CODE (x) == REG)
fprintf (file, "%s", byte_reg (x, 0));
+ else
+ output_operand_lossage ("Expected register or constant integer.");
break;
case 'z':
if (GET_CODE (x) == CONST_INT)
fprintf (file, "#%ld", (INTVAL (x) >> 24) & 0xff);
- else
+ else if (GET_CODE (x) == REG)
fprintf (file, "%s", byte_reg (x, 1));
+ else
+ output_operand_lossage ("Expected register or constant integer.");
break;
default:
diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog
index c465ff99541..c0699907f1c 100644
--- a/gcc/testsuite/ChangeLog
+++ b/gcc/testsuite/ChangeLog
@@ -1,3 +1,8 @@
+2020-01-24 Jeff Law
PR debug/92763
diff --git a/gcc/testsuite/gcc.target/h8300/pr13721.c
b/gcc/testsuite/gcc.target/h8300/pr13721.c
new file mode 100644
index 000..817b5377448
--- /dev/null
+++ b/gcc/testsuite/gcc.target/h8300/pr13721.c
@@ -0,0 +1,71 @@
+static __inline__ __attribute__((always_inline)) void set_bit(int nr, volatile
void * addr)
+{
+ volatile unsigned char *b_addr;
+ b_addr = (volatile unsigned char *)addr + ((nr >> 3) ^ 3);
+ nr &= 7;
+ if (__builtin_constant_p (nr))
+ {
+ switch(nr)
+ {
+ case 0:
+ __asm__("bset #0,%0" :"+m"(*b_addr) :"m"(*b_addr));
+ break;
+ case 1:
[PATCH] analyzer: restore input_location (PR 93349)
PR analyzer/93349 reports an ICE in IPA pass: simdclone for
some input files when -fanalyzer is supplied, with:
error: location references block not in block tree
The root cause is that the analyzer touches input_location in some
places (to make it easier to track down which source construct the
analyzer can't handle in the case of an analyzer ICE) and fails to reset
it. For the ICE in question, this sets input_location to a location_t
that references some arbitrary block (specifically, that of the last
statement to be analyzed, within the original CFG of whichever is the
last such function to be analyzed).
Later, within omp-simd-clone.c, input_location is used by gimplify_expr
(called via gimplify_and_add), which has:
14492 if (!gimple_seq_empty_p (*pre_p))
14493 annotate_all_with_location_after (*pre_p, pre_last_gsi,
input_location);
thus using whatever the value of input_location is, leading
to statements that reference some arbitrary block in the original CFG.
For the reproducer, this happens to be a block in the CFG for the
original function, rather than that of the clone, but in general it
could be some arbitrary other function in the TU.
This code appears to assume that input_location has some arbitrary
value *not* in the block tree, which is potentially violated by the
analyzer's changes to input_location.
This patch adds a save and restore of input_location at the top-level
function of the analyzer, fixing the ICE.
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
OK for master?
gcc/analyzer/ChangeLog:
PR analyzer/93349
* engine.cc (run_checkers): Save and restore input_location.
gcc/testsuite/ChangeLog:
PR analyzer/93349
* gcc.dg/analyzer/torture/pr93349.c: New test.
---
gcc/analyzer/engine.cc | 8
gcc/testsuite/gcc.dg/analyzer/torture/pr93349.c | 4
2 files changed, 12 insertions(+)
create mode 100644 gcc/testsuite/gcc.dg/analyzer/torture/pr93349.c
diff --git a/gcc/analyzer/engine.cc b/gcc/analyzer/engine.cc
index 939401140e7..b881a1d9218 100644
--- a/gcc/analyzer/engine.cc
+++ b/gcc/analyzer/engine.cc
@@ -3589,6 +3589,9 @@ impl_run_checkers (logger *logger)
void
run_checkers ()
{
+ /* Save input_location. */
+ location_t saved_input_location = input_location;
+
/* Handle -fdump-analyzer and -fdump-analyzer-stderr. */
FILE *dump_fout = NULL;
/* Track if we're responsible for closing dump_fout. */
@@ -3619,6 +3622,11 @@ run_checkers ()
if (owns_dump_fout)
fclose (dump_fout);
+
+ /* Restore input_location. Subsequent passes may assume that input_location
+ is some arbitrary value *not* in the block tree, which might be violated
+ if we didn't restore it. */
+ input_location = saved_input_location;
}
} // namespace ana
diff --git a/gcc/testsuite/gcc.dg/analyzer/torture/pr93349.c
b/gcc/testsuite/gcc.dg/analyzer/torture/pr93349.c
new file mode 100644
index 000..a9d06367722
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/analyzer/torture/pr93349.c
@@ -0,0 +1,4 @@
+__attribute__ ((simd)) void
+test (void)
+{
+}
--
2.21.0
Re: [PATCH] Decrease cortexa57_extra_costs's alu.shift_reg
writes: > From: Andrew Pinski > > Like I mentioned in https://gcc.gnu.org/ml/gcc/2020-01/msg00157.html, > The shift by a register should be just COSTS_N_INSNS (1) rather than > COSTS_N_INSNS (2). This allows lshift_cheap_p to return true now > and converting switches to be using shift and other like > structures. I noticed this difference when I was working > through PR 93131 and understanding what reassoc could handle. > > OK? Bootstrapped and tested on aarch64-linux-gnu with no regressions. OK, thanks. (Sorry for the slow response. It turned out that our servers bounced some gcc-patches emails from the git switchover weekend, so I didn't see this till now.) Richard > > Thanks, > Andrew Pinski > > ChangeLog: > * config/arm/aarch-cost-tables.h (cortexa57_extra_costs): Change > alu.shift_reg to 0. > --- > gcc/config/arm/aarch-cost-tables.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/gcc/config/arm/aarch-cost-tables.h > b/gcc/config/arm/aarch-cost-tables.h > index 6a30d92cde9..cf818659901 100644 > --- a/gcc/config/arm/aarch-cost-tables.h > +++ b/gcc/config/arm/aarch-cost-tables.h > @@ -235,7 +235,7 @@ const struct cpu_cost_table cortexa57_extra_costs = > 0, /* arith. */ > 0, /* logical. */ > 0, /* shift. */ > -COSTS_N_INSNS (1), /* shift_reg. */ > +0, /* shift_reg. */ > COSTS_N_INSNS (1), /* arith_shift. */ > COSTS_N_INSNS (1), /* arith_shift_reg. */ > COSTS_N_INSNS (1), /* log_shift. */
Re: [RFC c-common PATCH] PR c++/40752 - useless -Wconversion with short +=.
On 1/24/20 8:45 AM, David Edelsohn wrote: There is no ChangeLog entry for the testsuite changes. I don't believe in ChangeLog entries for testcases, but I'll add one for the target-supports.exp change, thanks. I'm also still trying to determine if Wconversion-pr40752.c requires -fsigned-char option. It shouldn't. Jason
Re: [C++ PATCH] PR c++/93299 - ICE in tsubst_copy with parenthesized expression.
On 1/17/20 4:03 PM, Marek Polacek wrote:
Since e4511ca2e9ecdb51d41b64452398f8e2df575668 force_paren_expr can create
a VIEW_CONVERT_EXPR so that we have something to set REF_PARENTHESIZED_P
on, while not making the expression dependent. But tsubst_copy can't cope
with such a VIEW_CONVERT_EXPR, because it's not location_wrapper_p, or
a TEMPLATE_PARM_INDEX wrapped in a VIEW_CONVERT_EXPR.
I think we need to teach tsubst_copy how to handle it. Setting
EXPR_LOCATION_WRAPPER_P in force_paren_expr would make the ICE go away
too, but tsubst_copy would lose the REF_PARENTHESIZED_P flag.
Bootstrapped/regtested on x86_64-linux, ok for trunk and 9?
* pt.c (tsubst_copy): Handle a REF_PARENTHESIZED_P VIEW_CONVERT_EXPR.
OK.
* g++.dg/cpp1y/paren5.C: New test.
---
gcc/cp/pt.c | 8
gcc/testsuite/g++.dg/cpp1y/paren5.C | 12
2 files changed, 20 insertions(+)
create mode 100644 gcc/testsuite/g++.dg/cpp1y/paren5.C
diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 1b3d07b1a52..5d3d127e528 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -16423,6 +16423,14 @@ tsubst_copy (tree t, tree args, tsubst_flags_t
complain, tree in_decl)
return op;
}
}
+ /* force_paren_expr can also create a VIEW_CONVERT_EXPR. */
+ else if (code == VIEW_CONVERT_EXPR && REF_PARENTHESIZED_P (t))
+ {
+ op = tsubst_copy (op, args, complain, in_decl);
+ op = build1 (code, TREE_TYPE (op), op);
+ REF_PARENTHESIZED_P (op) = true;
+ return op;
+ }
/* We shouldn't see any other uses of these in templates. */
gcc_unreachable ();
}
diff --git a/gcc/testsuite/g++.dg/cpp1y/paren5.C
b/gcc/testsuite/g++.dg/cpp1y/paren5.C
new file mode 100644
index 000..86a51356465
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp1y/paren5.C
@@ -0,0 +1,12 @@
+// PR c++/93299 - ICE in tsubst_copy with parenthesized expression.
+// { dg-do compile { target c++14 } }
+
+template struct A {
+ enum { b = 8 };
+};
+
+template struct __attribute__((aligned((A::b D { };
+struct S : D<0> { };
+
+template struct __attribute__((aligned((A::b) + N))) D2 { };
+struct S2 : D2<0> { };
base-commit: 6687d13a87c42dddc7d1c7adade38d31ba0d1401
[COMMITTED] libstdc++: Simplify construction of comparison category types
The _Eq and _Ord enumerations can be combined into one, reducing the
number of constructors needed for the comparison category types. The
redundant equal enumerator can be removed and equivalent used in its
place. The _Less and _Greater enumerators can be renamed because 'less'
and 'greater' are already reserved names anyway.
* libsupc++/compare (__cmp_cat::_Eq): Remove enumeration type.
(__cmp_cat::_Ord::equivalent): Add enumerator.
(__cmp_cat::_Ord::_Less, __cmp_cat::_Ord::_Greater): Rename to less
and greater.
(partial_ordering, weak_ordering, strong_ordering): Remove
constructors taking __cmp_cat::_Eq parameters. Use renamed
enumerators.
Tested powerpc64le-linux, committed to trunk.
commit 482eeff5f114c7635c1a06edb2deee3e5433c3f3
Author: Jonathan Wakely
Date: Fri Jan 24 17:07:01 2020 +
libstdc++: Simplify construction of comparison category types
The _Eq and _Ord enumerations can be combined into one, reducing the
number of constructors needed for the comparison category types. The
redundant equal enumerator can be removed and equivalent used in its
place. The _Less and _Greater enumerators can be renamed because 'less'
and 'greater' are already reserved names anyway.
* libsupc++/compare (__cmp_cat::_Eq): Remove enumeration type.
(__cmp_cat::_Ord::equivalent): Add enumerator.
(__cmp_cat::_Ord::_Less, __cmp_cat::_Ord::_Greater): Rename to less
and greater.
(partial_ordering, weak_ordering, strong_ordering): Remove
constructors taking __cmp_cat::_Eq parameters. Use renamed
enumerators.
diff --git a/libstdc++-v3/libsupc++/compare b/libstdc++-v3/libsupc++/compare
index 98a592cbb14..117340ff184 100644
--- a/libstdc++-v3/libsupc++/compare
+++ b/libstdc++-v3/libsupc++/compare
@@ -48,10 +48,7 @@ namespace std
namespace __cmp_cat
{
-enum class _Eq
-{ equal = 0, equivalent = equal, nonequal = 1, nonequivalent = nonequal };
-
-enum class _Ord { _Less = -1, _Greater = 1 };
+enum class _Ord { equivalent = 0, less = -1, greater = 1 };
enum class _Ncmp { _Unordered = -127 };
@@ -66,11 +63,6 @@ namespace std
int _M_value;
bool _M_is_ordered;
-constexpr explicit
-partial_ordering(__cmp_cat::_Eq __v) noexcept
-: _M_value(int(__v)), _M_is_ordered(true)
-{ }
-
constexpr explicit
partial_ordering(__cmp_cat::_Ord __v) noexcept
: _M_value(int(__v)), _M_is_ordered(true)
@@ -146,13 +138,13 @@ namespace std
// valid values' definitions
inline constexpr partial_ordering
- partial_ordering::less(__cmp_cat::_Ord::_Less);
+ partial_ordering::less(__cmp_cat::_Ord::less);
inline constexpr partial_ordering
- partial_ordering::equivalent(__cmp_cat::_Eq::equivalent);
+ partial_ordering::equivalent(__cmp_cat::_Ord::equivalent);
inline constexpr partial_ordering
- partial_ordering::greater(__cmp_cat::_Ord::_Greater);
+ partial_ordering::greater(__cmp_cat::_Ord::greater);
inline constexpr partial_ordering
partial_ordering::unordered(__cmp_cat::_Ncmp::_Unordered);
@@ -161,10 +153,6 @@ namespace std
{
int _M_value;
-constexpr explicit
-weak_ordering(__cmp_cat::_Eq __v) noexcept : _M_value(int(__v))
-{ }
-
constexpr explicit
weak_ordering(__cmp_cat::_Ord __v) noexcept : _M_value(int(__v))
{ }
@@ -243,23 +231,18 @@ namespace std
// valid values' definitions
inline constexpr weak_ordering
- weak_ordering::less(__cmp_cat::_Ord::_Less);
+ weak_ordering::less(__cmp_cat::_Ord::less);
inline constexpr weak_ordering
- weak_ordering::equivalent(__cmp_cat::_Eq::equivalent);
+ weak_ordering::equivalent(__cmp_cat::_Ord::equivalent);
inline constexpr weak_ordering
- weak_ordering::greater(__cmp_cat::_Ord::_Greater);
+ weak_ordering::greater(__cmp_cat::_Ord::greater);
class strong_ordering
{
int _M_value;
-constexpr explicit
-strong_ordering(__cmp_cat::_Eq __v) noexcept
-: _M_value(int(__v))
-{ }
-
constexpr explicit
strong_ordering(__cmp_cat::_Ord __v) noexcept
: _M_value(int(__v))
@@ -350,16 +333,16 @@ namespace std
// valid values' definitions
inline constexpr strong_ordering
- strong_ordering::less(__cmp_cat::_Ord::_Less);
+ strong_ordering::less(__cmp_cat::_Ord::less);
inline constexpr strong_ordering
- strong_ordering::equal(__cmp_cat::_Eq::equal);
+ strong_ordering::equal(__cmp_cat::_Ord::equivalent);
inline constexpr strong_ordering
- strong_ordering::equivalent(__cmp_cat::_Eq::equivalent);
+ strong_ordering::equivalent(__cmp_cat::_Ord::equivalent);
inline constexpr strong_ordering
- strong_ordering::greater(__cmp_cat::_Ord::_Greater);
+ strong_ordering::greater(__cmp_cat::_Ord::greater);
// named comparison functions
[COMMITTED] c++: Unshare expressions from constexpr cache.
Another place we need to unshare cached expressions.
Tested x86_64-pc-linux-gnu, applying to trunk.
PR c++/92852 - ICE with generic lambda and reference var.
* constexpr.c (maybe_constant_value): Likewise.
---
gcc/cp/constexpr.c | 2 +-
gcc/testsuite/g++.dg/cpp1y/lambda-generic-ref1.C | 12
gcc/testsuite/g++.dg/cpp1z/decomp48.C| 8
3 files changed, 17 insertions(+), 5 deletions(-)
create mode 100644 gcc/testsuite/g++.dg/cpp1y/lambda-generic-ref1.C
diff --git a/gcc/cp/constexpr.c b/gcc/cp/constexpr.c
index f6b8f331bc9..8e8806345c1 100644
--- a/gcc/cp/constexpr.c
+++ b/gcc/cp/constexpr.c
@@ -6598,7 +6598,7 @@ maybe_constant_value (tree t, tree decl, bool
manifestly_const_eval)
if (cv_cache == NULL)
cv_cache = hash_map::create_ggc (101);
if (tree *cached = cv_cache->get (t))
-return *cached;
+return unshare_expr_without_location (*cached);
r = cxx_eval_outermost_constant_expr (t, true, true, false, false, decl);
gcc_checking_assert (r == t
diff --git a/gcc/testsuite/g++.dg/cpp1y/lambda-generic-ref1.C
b/gcc/testsuite/g++.dg/cpp1y/lambda-generic-ref1.C
new file mode 100644
index 000..a96fa1ce237
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp1y/lambda-generic-ref1.C
@@ -0,0 +1,12 @@
+// PR c++/92852
+// { dg-do compile { target c++14 } }
+
+struct S { int operator<<(const int &); } glob;
+void foo()
+{
+ S& message_stream = glob;
+ auto format = [&message_stream](auto && x)
+ { message_stream << x ; };
+ format(3);
+ format(4u);
+}
diff --git a/gcc/testsuite/g++.dg/cpp1z/decomp48.C
b/gcc/testsuite/g++.dg/cpp1z/decomp48.C
index 3c50b02a6c2..35413c79a9d 100644
--- a/gcc/testsuite/g++.dg/cpp1z/decomp48.C
+++ b/gcc/testsuite/g++.dg/cpp1z/decomp48.C
@@ -18,7 +18,7 @@ f2 ()
{
S v {1, 2};
auto& [s, t] = v;// { dg-warning "structured bindings only available
with" "" { target c++14_down } }
- return s;// { dg-warning "reference to local variable 'v'
returned" "" { target *-*-* } .-1 }
+ return s;// { dg-warning "reference to local variable 'v'
returned" }
}
int &
@@ -33,7 +33,7 @@ f4 ()
{
int a[3] = {1, 2, 3};
auto& [s, t, u] = a; // { dg-warning "structured bindings only available
with" "" { target c++14_down } }
- return s;// { dg-warning "reference to local variable 'a'
returned" "" { target *-*-* } .-1 }
+ return s;// { dg-warning "reference to local variable 'a'
returned" }
}
int &
@@ -78,7 +78,7 @@ f10 ()
{
S v {1, 2};
auto& [s, t] = v;// { dg-warning "structured bindings only available
with" "" { target c++14_down } }
- return &s; // { dg-warning "address of local variable 'v'
returned" "" { target *-*-* } .-1 }
+ return &s; // { dg-warning "address of local variable 'v'
returned" }
}
int *
@@ -93,7 +93,7 @@ f12 ()
{
int a[3] = {1, 2, 3};
auto& [s, t, u] = a; // { dg-warning "structured bindings only available
with" "" { target c++14_down } }
- return &s; // { dg-warning "address of local variable 'a'
returned" "" { target *-*-* } .-1 }
+ return &s; // { dg-warning "address of local variable 'a'
returned" }
}
int *
base-commit: 64c9f2d9972ad359a32f0a97ee0a806c2532db15
--
2.18.1
Re: [RFC c-common PATCH] PR c++/40752 - useless -Wconversion with short +=.
On Fri, Jan 24, 2020 at 12:00 PM Jason Merrill wrote: > > On 1/24/20 8:45 AM, David Edelsohn wrote: > > There is no ChangeLog entry for the testsuite changes. > > I don't believe in ChangeLog entries for testcases, but I'll add one for > the target-supports.exp change, thanks. Is this a general policy change that we want to make? Current we still have gcc/testsuite/ChangeLog and developers are updating that file. Thanks, David
Re: [RFC c-common PATCH] PR c++/40752 - useless -Wconversion with short +=.
On Fri, Jan 24, 2020 at 12:46 PM David Edelsohn wrote: > On Fri, Jan 24, 2020 at 12:00 PM Jason Merrill wrote: > > > > On 1/24/20 8:45 AM, David Edelsohn wrote: > > > There is no ChangeLog entry for the testsuite changes. > > > > I don't believe in ChangeLog entries for testcases, but I'll add one for > > the target-supports.exp change, thanks. > > Is this a general policy change that we want to make? Current we > still have gcc/testsuite/ChangeLog and developers are updating that > file. > I would support formalizing that as policy; currently there is no policy. https://gcc.gnu.org/codingconventions.html#ChangeLogs "There is no established convention on when ChangeLog entries are to be made for testsuite changes." Jason
[PATCH][wwwdocs] Document GNU-stack support added to GCC 10 for MIPS
From: "Dragan Mladjenovic" diff --git a/htdocs/gcc-10/changes.html b/htdocs/gcc-10/changes.html index ef27c9b..7736990 100644 --- a/htdocs/gcc-10/changes.html +++ b/htdocs/gcc-10/changes.html @@ -623,7 +623,14 @@ a work-in-progress. - +MIPS + + The mips*-*-linux* targets now mark object files with appropriate GNU-stack note, +facilitating use of non-executable stack hardening on GNU/Linux. +The soft-float targets have this feature enabled by default, while +for hard-float targets it requires use of glibc 2.31 or later. + + -- 1.9.1
Re: [PATCH] asan_test.C: disable -Wstringop-overflow, PR/93058
On Fri, Jan 24, 2020 at 07:57:22AM +, slyfox.inbox.ru via gcc-patches wrote: > From: Sergei Trofimovich > > From: Sergei Trofimovich > > asan's test allocates 2 pages via pvalloc(kPageSize + 100) > and makes sure dereference of 'kPageSize + 101' does not > trigger asan checks. > > glibc's and gcc's malloc-like attribute checkers trigger > a warning: > asan_test.cc:129:22: error: writing 1 byte into a region > of size 0 [-Werror=stringop-overflow=] > > As there is no easy way to convey pvalloc()'s granularity > to gcc let's just disable the warning for this test. > > * g++.dg/asan/asan_test.C: disable -Wstringop-overflow. No. That is a glibc bug and it has been fixed in glibc already, if we disabled this, we might never discovered it. Jakub
[COMMITTED] c++: Fix parameter map handling of member typedef.
any_template_parm_r was looking at the args of an alias template-id, but we
need to look at all args of a member alias/typedef, including implicit ones
from the enclosing class.
Tested x86_64-pc-linux-gnu, applying to trunk.
PR c++/93377 - ICE with member alias in constraint.
* pt.c (any_template_parm_r): Look at template arguments for all
aliases, not only alias templates.
---
gcc/cp/pt.c | 20 +++
gcc/testsuite/g++.dg/cpp2a/concepts-alias5.C | 62
2 files changed, 71 insertions(+), 11 deletions(-)
create mode 100644 gcc/testsuite/g++.dg/cpp2a/concepts-alias5.C
diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 95719927249..209044135cb 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -10427,19 +10427,15 @@ any_template_parm_r (tree t, void *data)
} \
while (0)
+ /* A mention of a member alias/typedef is a use of all of its template
+ arguments, including those from the enclosing class, so we don't use
+ alias_template_specialization_p here. */
+ if (TYPE_P (t) && typedef_variant_p (t))
+if (tree tinfo = TYPE_ALIAS_TEMPLATE_INFO (t))
+ WALK_SUBTREE (TI_ARGS (tinfo));
+
switch (TREE_CODE (t))
{
-case RECORD_TYPE:
-case UNION_TYPE:
-case ENUMERAL_TYPE:
- /* Search for template parameters in type aliases. */
- if (tree ats = alias_template_specialization_p (t, nt_opaque))
- {
- tree tinfo = TYPE_ALIAS_TEMPLATE_INFO (ats);
- WALK_SUBTREE (TI_ARGS (tinfo));
-}
- break;
-
case TEMPLATE_TYPE_PARM:
/* Type constraints of a placeholder type may contain parameters. */
if (is_auto (t))
@@ -10472,6 +10468,8 @@ any_template_parm_r (tree t, void *data)
tree cparms = ftpi->ctx_parms;
while (TMPL_PARMS_DEPTH (dparms) > ftpi->max_depth)
dparms = TREE_CHAIN (dparms);
+ while (TMPL_PARMS_DEPTH (cparms) > TMPL_PARMS_DEPTH (dparms))
+ cparms = TREE_CHAIN (cparms);
while (dparms
&& (TREE_TYPE (TREE_VALUE (dparms))
!= TREE_TYPE (TREE_VALUE (cparms
diff --git a/gcc/testsuite/g++.dg/cpp2a/concepts-alias5.C
b/gcc/testsuite/g++.dg/cpp2a/concepts-alias5.C
new file mode 100644
index 000..907b0c2e357
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp2a/concepts-alias5.C
@@ -0,0 +1,62 @@
+// PR c++/93377
+// { dg-do compile { target c++2a } }
+
+struct empty
+{};
+
+template
+c value;
+
+template
+auto func(value);
+
+template
+struct alignment_algorithm;
+
+template
+struct select
+{
+ template
+ decltype(algorithm_t()(func<_args_t>...)) choose();
+
+ template
+ static empty choose();
+
+ using type = decltype(choose, args_t...>());
+};
+
+template
+struct select_algorithm : select
+{};
+
+template struct maybe_value { int value; };
+
+template
+struct maybe_value;
+
+struct function
+{
+ template >::value)>
+ function(algorithm_t);
+};
+
+template
+struct alignment_configuration_traits
+{
+ static constexpr bool is_vectorised = 0;
+};
+
+template
+struct alignment_algorithm
+{
+ using traits_t = alignment_configuration_traits;
+ template
+ void operator()(indexed_sequence_pairs_t) requires traits_t::is_vectorised;
+};
+
+int main()
+{
+function{alignment_algorithm{}};
+}
base-commit: 14e5881e37771f1f58123e77c558adb3b90c8764
--
2.18.1
Re: [PATCH] asan_test.C: disable -Wstringop-overflow, PR/93058
On Fri, 24 Jan 2020 22:20:43 +0100 Jakub Jelinek wrote: > On Fri, Jan 24, 2020 at 07:57:22AM +, slyfox.inbox.ru via gcc-patches > wrote: > > From: Sergei Trofimovich > > > > From: Sergei Trofimovich > > > > asan's test allocates 2 pages via pvalloc(kPageSize + 100) > > and makes sure dereference of 'kPageSize + 101' does not > > trigger asan checks. > > > > glibc's and gcc's malloc-like attribute checkers trigger > > a warning: > > asan_test.cc:129:22: error: writing 1 byte into a region > > of size 0 [-Werror=stringop-overflow=] > > > > As there is no easy way to convey pvalloc()'s granularity > > to gcc let's just disable the warning for this test. > > > > * g++.dg/asan/asan_test.C: disable -Wstringop-overflow. > > No. That is a glibc bug and it has been fixed in glibc already, if we > disabled this, we might never discovered it. Aha, I assume it was fixed by https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=768c83b7f60d82db6677e19dc51be9f341e0f3fc I'll close gcc PR as invalid then. Thank you! -- Sergei pgpvHeT_dmPCm.pgp Description: Цифровая подпись OpenPGP
[committed] [PR tree-optimization/92788] Check right edge flags when suppressing jump threading
When we thread through the successor of a joiner block we make a clone
of the joiner block and redirect its outgoing edges. Of course if
there's cases where we can't redirect an edge, then bad things will
happen.
The code already checked for EDGE_ABNORMAL to suppress threading in
that case. But it really should have been checking EDGE_COMPLEX which
includes ABNORMAL_CALL, EH and PRESERVE.
This patch fixes that oversight and resolves the BZ. Bootstrapped and
regression tested on x86_64. Committed to the trunk.
jeff
commit 98181563dc4c65c9d23eaa99134e18876b6ec671
Author: Jeff Law
Date: Fri Jan 24 17:44:10 2020 -0500
Fix ICE due to invalid jump threading request
PR tree-optimization/92788
* tree-ssa-threadedge.c (thread_across_edge): Check EDGE_COMPLEX
not EDGE_ABNORMAL.
PR tree-optimization/92788
* g++.dg/pr92788.C: New test.
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index b1b46326306..0f19fc44212 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,9 @@
+2020-01-24 Jeff Law
+
+ PR tree-optimization/92788
+ * tree-ssa-threadedge.c (thread_across_edge): Check EDGE_COMPLEX
+ not EDGE_ABNORMAL.
+
2020-01-24 Jakub Jelinek
PR target/93395
diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog
index 1fc95b334a8..a8d517ad8a3 100644
--- a/gcc/testsuite/ChangeLog
+++ b/gcc/testsuite/ChangeLog
@@ -1,3 +1,8 @@
+2020-01-24 Jeff Law
PR target/93395
diff --git a/gcc/testsuite/g++.dg/pr92788.C b/gcc/testsuite/g++.dg/pr92788.C
new file mode 100644
index 000..b92ae38f7aa
--- /dev/null
+++ b/gcc/testsuite/g++.dg/pr92788.C
@@ -0,0 +1,470 @@
+/* { dg-do compile { target i?86-*-* x86_64-*-* } } */
+/* { dg-require-effective-target c++11 } */
+/* { dg-options "-O3 -fnon-call-exceptions -ftracer -march=k8
-Wno-return-type" } */
+
+
+template struct integral_constant {
+
+ static constexpr int value = __v;
+
+};
+
+template using __bool_constant = integral_constant<__v>;
+
+template
+
+struct is_same : integral_constant {};
+
+template using __enable_if_t = _Tp;
+
+void *operator new(unsigned long, void *__p) { return __p; }
+
+template class __normal_iterator {
+
+ _Iterator _M_current;
+
+
+
+public:
+
+ __normal_iterator(_Iterator) {}
+
+ void operator++() { ++_M_current; }
+
+ _Iterator base() { return _M_current; }
+
+};
+
+template
+
+bool operator!=(__normal_iterator<_IteratorL, _Container> __lhs,
+
+ __normal_iterator<_IteratorR, _Container> __rhs) {
+
+ return __lhs.base() != __rhs.base();
+
+}
+
+template void construct_at(_Tp *__location) noexcept {
+
+ new (__location) _Tp;
+
+}
+
+template void _Construct(_Tp __p) { construct_at(__p); }
+
+struct _Any_data {
+
+ template _Tp _M_access();
+
+};
+
+enum _Manager_operation {};
+
+template class function;
+
+class _Function_base {
+
+public:
+
+ template class _Base_manager {
+
+public:
+
+static bool _M_manager(_Any_data, _Any_data __source, _Manager_operation) {
+
+ _Functor(*__source._M_access<_Functor *>());
+
+ return true;
+
+}
+
+ };
+
+ typedef bool (*_Manager_type)(_Any_data &, const _Any_data &,
+
+_Manager_operation);
+
+ _Manager_type _M_manager;
+
+};
+
+template class _Function_handler;
+
+template
+
+class _Function_handler<_Res(_ArgTypes...), _Functor> : _Function_base {
+
+public:
+
+ static bool _M_manager(_Any_data &__dest, const _Any_data &__source,
+
+_Manager_operation __op) {
+
+_Base_manager<_Functor>::_M_manager(__dest, __source, __op);
+
+ }
+
+};
+
+template
+
+class function<_Res(_ArgTypes...)> : _Function_base {
+
+ template using _Requires = _Tp;
+
+
+
+public:
+
+ template , void>,
+
+typename = _Requires<_Functor, void>>
+
+ function(_Functor);
+
+};
+
+template
+
+template
+
+function<_Res(_ArgTypes...)>::function(_Functor) {
+
+ _M_manager = _Function_handler<_Res(), _Functor>::_M_manager;
+
+}
+
+template class new_allocator {
+
+public:
+
+ _Tp *allocate(long) { return static_cast<_Tp *>(operator new(sizeof(_Tp))); }
+
+};
+
+namespace std {
+
+ template struct allocator_traits;
+
+ template struct allocator_traits> {
+
+using allocator_type = new_allocator<_Tp>;
+
+using pointer = _Tp *;
+
+using const_pointer = _Tp *;
+
+using size_type = long;
+
+template using rebind_alloc = new_allocator<_Up>;
+
+static pointer allocate(allocator_type __a, size_type __n) {
+
+ return __a.allocate(__n);
+
+}
+
+static void deallocate(allocator_type, pointer, size_type);
+
+ };
+
+}
+
+template
+
+struct __alloc_traits : std::allocator_traits<_Alloc> {
+
+ template struct rebind {
+
+typedef typename std::allocator_traits<_Alloc>::template rebind_alloc<_Tp>
other;
+
+ };
+
+};
+
+namespace std {
+
+ struct __uninitialized_copy {
+
+template
+
+static _ForwardIterator __uninit_copy(_InputIterator __first,
+
+ _InputIterator __last,
+
+ _ForwardI
Re: [RFC] [c-family] PR92867 - Add returns_arg attribute
On Fri, 24 Jan 2020, Prathamesh Kulkarni wrote: > The middle-end representation issue of ERF_RETURNS_ARG still remains, > which restricts the attribute till first four args. The patch simply > emits sorry(), for arguments beyond first four.. I think this should be fixed (e.g. make the middle-end check for the attribute, or something like that). The language semantics of the attribute should not be driven by such internal implementation details; rather, implementation details should be determined by the language semantics to be implemented. The sorry () has coding style issues. Diagnostics should not end with '.' or '\n', should use full words (attribute not attr, arguments not args) and programming language text in them should be surrounded by %<%> (so %). -- Joseph S. Myers jos...@codesourcery.com
[C++ PATCH] c++: Poor diagnostic for dynamic_cast in constexpr context [PR93414]
I neglected to add a proper diagnostic for the reference dynamic_cast
case when the operand of a dynamic_cast doesn't refer to a public base
of Derived, resulting in suboptimal error message
error: call to non-'constexpr' function 'void* __cxa_bad_cast()'
Tested x86_64-linux, ok for trunk?
2020-01-24 Marek Polacek
PR c++/93414 - poor diagnostic for dynamic_cast in constexpr context.
* constexpr.c (cxx_eval_dynamic_cast_fn): Add a reference
dynamic_cast diagnostic.
* g++.dg/cpp2a/constexpr-dynamic18.C: New test.
---
gcc/cp/constexpr.c| 15 -
.../g++.dg/cpp2a/constexpr-dynamic18.C| 22 +++
2 files changed, 36 insertions(+), 1 deletion(-)
create mode 100644 gcc/testsuite/g++.dg/cpp2a/constexpr-dynamic18.C
diff --git a/gcc/cp/constexpr.c b/gcc/cp/constexpr.c
index 8e8806345c1..577022e9b9a 100644
--- a/gcc/cp/constexpr.c
+++ b/gcc/cp/constexpr.c
@@ -1888,7 +1888,20 @@ cxx_eval_dynamic_cast_fn (const constexpr_ctx *ctx, tree
call,
if (tree t = (TREE_CODE (obj) == COMPONENT_REF
? TREE_OPERAND (obj, 1) : obj))
if (TREE_CODE (t) != FIELD_DECL || !DECL_FIELD_IS_BASE (t))
- return integer_zero_node;
+ {
+ if (reference_p)
+ {
+ if (!ctx->quiet)
+ {
+ error_at (loc, "reference % failed");
+ inform (loc, "dynamic type %qT of its operand does "
+ "not have a base class of type %qT",
+ objtype, type);
+ }
+ *non_constant_p = true;
+ }
+ return integer_zero_node;
+ }
/* [class.cdtor] When a dynamic_cast is used in a constructor ...
or in a destructor ... if the operand of the dynamic_cast refers
diff --git a/gcc/testsuite/g++.dg/cpp2a/constexpr-dynamic18.C
b/gcc/testsuite/g++.dg/cpp2a/constexpr-dynamic18.C
new file mode 100644
index 000..346f9f56470
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp2a/constexpr-dynamic18.C
@@ -0,0 +1,22 @@
+// PR c++/93414 - poor diagnostic for dynamic_cast in constexpr context.
+// { dg-do compile { target c++2a } }
+// Here 'b' doesn't point/refer to a public base of Derived.
+
+struct Base {
+constexpr virtual ~Base(){}
+};
+
+struct Derived: Base {
+constexpr ~Derived(){}
+};
+
+constexpr const Derived& cast(const Base& b) {
+return dynamic_cast(b); // { dg-error "reference
.dynamic_cast. failed" }
+// { dg-message "dynamic type .const Base. of its operand does not have a base
class of type .Derived." "" { target *-*-* } .-1 }
+}
+
+auto test() {
+static constexpr Base b;
+constexpr auto res = cast(b);
+return res;
+}
base-commit: 55dd44535d2e4e5703c0103c26e7c51ab8c502c4
--
Marek Polacek • Red Hat, Inc. • 300 A St, Boston, MA
[PATCH] analyzer: fix build with gcc 4.4 (PR 93276)
This patch fixes various build failures seen with gcc 4.4
gcc prior to 4.6 complains about:
error: #pragma GCC diagnostic not allowed inside functions
for various uses of PUSH_IGNORE_WFORMAT and POP_IGNORE_WFORMAT.
This patch makes them a no-op with such compilers.
The patch also fixes various errors with template base initializers
and redundant uses of "typename" that older g++ implementations
can't cope with.
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu
with gcc gcc 9.2.1.
Appears to fix the build with gcc 4.4: I was able to successfully
build stage1 xgcc and cc1 and run the analyzer test suite (though
I'm seeing an apparently unrelated:
pure virtual method called
terminate called without an active exception
in the selftests for diagnostic-show-locus.c)
OK for master?
gcc/analyzer/ChangeLog:
PR analyzer/93276
* analyzer.h (PUSH_IGNORE_WFORMAT, POP_IGNORE_WFORMAT): Guard these
macros with GCC_VERSION >= 4006, making them no-op otherwise.
* engine.cc (exploded_edge::exploded_edge): Specify template for
base class initializer.
(exploded_graph::add_edge): Specify template when chaining up to
base class add_edge implementation.
(viz_callgraph_node::dump_dot): Drop redundant "typename".
(viz_callgraph_edge::viz_callgraph_edge): Specify template for
base class initializer.
* program-state.cc (sm_state_map::clone_with_remapping): Drop
redundant "typename".
(sm_state_map::print): Likewise.
(sm_state_map::hash): Likewise.
(sm_state_map::operator==): Likewise.
(sm_state_map::remap_svalue_ids): Likewise.
(sm_state_map::on_svalue_purge): Likewise.
(sm_state_map::validate): Likewise.
* program-state.h (sm_state_map::iterator_t): Likewise.
* supergraph.h (superedge::superedge): Specify template for base
class initializer.
gcc/ChangeLog:
PR analyzer/93276
* digraph.cc (test_edge::test_edge): Specify template for base
class initializer.
---
gcc/analyzer/analyzer.h | 16 ++--
gcc/analyzer/engine.cc| 10 +-
gcc/analyzer/program-state.cc | 16
gcc/analyzer/program-state.h | 2 +-
gcc/analyzer/supergraph.h | 2 +-
gcc/digraph.cc| 2 +-
6 files changed, 26 insertions(+), 22 deletions(-)
diff --git a/gcc/analyzer/analyzer.h b/gcc/analyzer/analyzer.h
index e84e6958cec..9746c9e0123 100644
--- a/gcc/analyzer/analyzer.h
+++ b/gcc/analyzer/analyzer.h
@@ -98,17 +98,21 @@ public:
~auto_cfun () { pop_cfun (); }
};
-/* Begin suppressing -Wformat and -Wformat-extra-args. */
+/* Macros for temporarily suppressing -Wformat and -Wformat-extra-args,
+ for those versions of GCC that support pragmas within a function
+ (4.6 onwards). */
-#define PUSH_IGNORE_WFORMAT \
+#if GCC_VERSION >= 4006
+# define PUSH_IGNORE_WFORMAT \
_Pragma("GCC diagnostic push") \
_Pragma("GCC diagnostic ignored \"-Wformat\"") \
_Pragma("GCC diagnostic ignored \"-Wformat-extra-args\"")
-
-/* Finish suppressing -Wformat and -Wformat-extra-args. */
-
-#define POP_IGNORE_WFORMAT \
+# define POP_IGNORE_WFORMAT \
_Pragma("GCC diagnostic pop")
+#else
+# define PUSH_IGNORE_WFORMAT
+# define POP_IGNORE_WFORMAT
+#endif
/* A template for creating hash traits for a POD type. */
diff --git a/gcc/analyzer/engine.cc b/gcc/analyzer/engine.cc
index 737ea1dd6e4..a2587a33a66 100644
--- a/gcc/analyzer/engine.cc
+++ b/gcc/analyzer/engine.cc
@@ -1377,7 +1377,7 @@ rewind_info_t::add_events_to_path (checker_path
*emission_path,
dst_stack_depth, this));
}
-/* class exploded_edge : public dedge. */
+/* class exploded_edge : public dedge. */
/* exploded_edge's ctor. */
@@ -1385,7 +1385,7 @@ exploded_edge::exploded_edge (exploded_node *src,
exploded_node *dest,
const superedge *sedge,
const state_change &change,
custom_info_t *custom_info)
-: dedge (src, dest), m_sedge (sedge), m_change (change),
+: dedge (src, dest), m_sedge (sedge), m_change (change),
m_custom_info (custom_info)
{
change.validate (dest->get_state ());
@@ -1991,7 +1991,7 @@ exploded_graph::add_edge (exploded_node *src,
exploded_node *dest,
exploded_edge::custom_info_t *custom_info)
{
exploded_edge *e = new exploded_edge (src, dest, sedge, change, custom_info);
- digraph::add_edge (e);
+ digraph::add_edge (e);
return e;
}
@@ -3332,7 +3332,7 @@ public:
// TODO: also show the per-callstring breakdown
const exploded_graph::call_string_data_map_t *per_cs_data
= args.m_eg->get_per_call_string_data ();
- for (typename exploded_graph::call_string_data_map_t::iterator iter
+ for (exploded_graph::call_string_data_map_t::iterator iter
= per_cs_data->begin ();
iter != per_cs_data->end ();
Re: [PATCH] analyzer: fix build with gcc 4.4 (PR 93276)
On Fri, 2020-01-24 at 19:53 -0500, David Malcolm wrote: > This patch fixes various build failures seen with gcc 4.4 > > gcc prior to 4.6 complains about: > > error: #pragma GCC diagnostic not allowed inside functions > > for various uses of PUSH_IGNORE_WFORMAT and POP_IGNORE_WFORMAT. > This patch makes them a no-op with such compilers. > > The patch also fixes various errors with template base initializers > and redundant uses of "typename" that older g++ implementations > can't cope with. > > Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu > with gcc gcc 9.2.1. > Appears to fix the build with gcc 4.4: I was able to successfully > build stage1 xgcc and cc1 and run the analyzer test suite (though > I'm seeing an apparently unrelated: > pure virtual method called > terminate called without an active exception > in the selftests for diagnostic-show-locus.c) > > OK for master? > > gcc/analyzer/ChangeLog: > PR analyzer/93276 > * analyzer.h (PUSH_IGNORE_WFORMAT, POP_IGNORE_WFORMAT): Guard these > macros with GCC_VERSION >= 4006, making them no-op otherwise. > * engine.cc (exploded_edge::exploded_edge): Specify template for > base class initializer. > (exploded_graph::add_edge): Specify template when chaining up to > base class add_edge implementation. > (viz_callgraph_node::dump_dot): Drop redundant "typename". > (viz_callgraph_edge::viz_callgraph_edge): Specify template for > base class initializer. > * program-state.cc (sm_state_map::clone_with_remapping): Drop > redundant "typename". > (sm_state_map::print): Likewise. > (sm_state_map::hash): Likewise. > (sm_state_map::operator==): Likewise. > (sm_state_map::remap_svalue_ids): Likewise. > (sm_state_map::on_svalue_purge): Likewise. > (sm_state_map::validate): Likewise. > * program-state.h (sm_state_map::iterator_t): Likewise. > * supergraph.h (superedge::superedge): Specify template for base > class initializer. > > gcc/ChangeLog: > PR analyzer/93276 > * digraph.cc (test_edge::test_edge): Specify template for base > class initializer. OK. And more generally, if you're hacking on facilities just used by the analyzer go ahead. While we haven't gone through the formal process of naming you maintainer of hte analyzer, I'm certain we will once I can come up for air and propose it. jeff >
[COMMITTED] c++: Fix ICE with lambda in member operator (PR93279)
Here the problem was that we were remembering the lookup in template scope,
and then trying to reuse that lookup in the instantiation without
substituting into it at all. The simplest solution is to not try to
remember a lookup that finds a class-scope declaration, as in that case
doing the normal lookup again at instantiation time will always find the
right declarations.
Tested x86_64-pc-linux-gnu, applying to trunk.
PR c++/93279 - ICE with lambda in member operator.
* name-lookup.c (maybe_save_operator_binding): Don't remember
class-scope bindings.
---
gcc/cp/name-lookup.c | 6 ++
.../g++.dg/cpp0x/lambda/lambda-template16.C | 15 +++
2 files changed, 21 insertions(+)
create mode 100644 gcc/testsuite/g++.dg/cpp0x/lambda/lambda-template16.C
diff --git a/gcc/cp/name-lookup.c b/gcc/cp/name-lookup.c
index cd7a5816e46..572100766cb 100644
--- a/gcc/cp/name-lookup.c
+++ b/gcc/cp/name-lookup.c
@@ -7616,6 +7616,12 @@ maybe_save_operator_binding (tree e)
if (!fns && (fns = op_unqualified_lookup (fnname)))
{
+ tree fn = get_first_fn (fns);
+ if (DECL_CLASS_SCOPE_P (fn))
+ /* We don't need to remember class-scope functions, normal unqualified
+ lookup will find them again. */
+ return;
+
bindings = tree_cons (fnname, fns, bindings);
if (attr)
TREE_VALUE (attr) = bindings;
diff --git a/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-template16.C
b/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-template16.C
new file mode 100644
index 000..faaff68b968
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-template16.C
@@ -0,0 +1,15 @@
+// PR c++/93279
+// { dg-do compile { target c++11 } }
+
+template struct B { using f = int; };
+template struct E {
+ template ::f = 0>
+ void operator*(U l) { [l](T m) { m * l; }; }
+};
+
+int
+main ()
+{
+ E, 1> n;
+ n * 4.f;
+}
base-commit: c671727004b87f0f256191c3a99c50dc4888e79b
--
2.18.1
Re: [C++ PATCH] c++: Poor diagnostic for dynamic_cast in constexpr context [PR93414]
[C++ PATCH] c++: is unnecessarily redundant, you can just write [PATCH].
On 1/24/20 6:20 PM, Marek Polacek wrote:> I neglected to add a proper
diagnostic for the reference dynamic_cast> case when the operand of a
dynamic_cast doesn't refer to a public base> of Derived, resulting in
suboptimal error message>
error: call to non-'constexpr' function 'void* __cxa_bad_cast()'
Tested x86_64-linux, ok for trunk?
OK.
2020-01-24 Marek Polacek
PR c++/93414 - poor diagnostic for dynamic_cast in constexpr context.
* constexpr.c (cxx_eval_dynamic_cast_fn): Add a reference
dynamic_cast diagnostic.
* g++.dg/cpp2a/constexpr-dynamic18.C: New test.
---
gcc/cp/constexpr.c| 15 -
.../g++.dg/cpp2a/constexpr-dynamic18.C| 22 +++
2 files changed, 36 insertions(+), 1 deletion(-)
create mode 100644 gcc/testsuite/g++.dg/cpp2a/constexpr-dynamic18.C
diff --git a/gcc/cp/constexpr.c b/gcc/cp/constexpr.c
index 8e8806345c1..577022e9b9a 100644
--- a/gcc/cp/constexpr.c
+++ b/gcc/cp/constexpr.c
@@ -1888,7 +1888,20 @@ cxx_eval_dynamic_cast_fn (const constexpr_ctx *ctx, tree
call,
if (tree t = (TREE_CODE (obj) == COMPONENT_REF
? TREE_OPERAND (obj, 1) : obj))
if (TREE_CODE (t) != FIELD_DECL || !DECL_FIELD_IS_BASE (t))
- return integer_zero_node;
+ {
+ if (reference_p)
+ {
+ if (!ctx->quiet)
+ {
+ error_at (loc, "reference % failed");
+ inform (loc, "dynamic type %qT of its operand does "
+ "not have a base class of type %qT",
+ objtype, type);
+ }
+ *non_constant_p = true;
+ }
+ return integer_zero_node;
+ }
/* [class.cdtor] When a dynamic_cast is used in a constructor ...
or in a destructor ... if the operand of the dynamic_cast refers
diff --git a/gcc/testsuite/g++.dg/cpp2a/constexpr-dynamic18.C
b/gcc/testsuite/g++.dg/cpp2a/constexpr-dynamic18.C
new file mode 100644
index 000..346f9f56470
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp2a/constexpr-dynamic18.C
@@ -0,0 +1,22 @@
+// PR c++/93414 - poor diagnostic for dynamic_cast in constexpr context.
+// { dg-do compile { target c++2a } }
+// Here 'b' doesn't point/refer to a public base of Derived.
+
+struct Base {
+constexpr virtual ~Base(){}
+};
+
+struct Derived: Base {
+constexpr ~Derived(){}
+};
+
+constexpr const Derived& cast(const Base& b) {
+return dynamic_cast(b); // { dg-error "reference .dynamic_cast.
failed" }
+// { dg-message "dynamic type .const Base. of its operand does not have a base class of type
.Derived." "" { target *-*-* } .-1 }
+}
+
+auto test() {
+static constexpr Base b;
+constexpr auto res = cast(b);
+return res;
+}
base-commit: 55dd44535d2e4e5703c0103c26e7c51ab8c502c4
[COMMITTED] c++: Fix ICE with constrained friend (PR93400).
Here, the problem was that tsubst_friend_function was modifying the
CONSTRAINT_INFO for the friend template to have the constraints for one
instantiation, which fell down when we went to adjust it for another
instantiation. Fixed by deferring substitution of trailing requirements
until we try to check declaration matching.
Tested x86_64-pc-linux-gnu, applying to trunk.
PR c++/93400 - ICE with constrained friend.
* constraint.cc (maybe_substitute_reqs_for): New.
* decl.c (function_requirements_equivalent_p): Call it.
* pt.c (tsubst_friend_function): Only substitute
TEMPLATE_PARMS_CONSTRAINTS.
(tsubst_template_parms): Copy constraints.
---
gcc/cp/cp-tree.h | 1 +
gcc/cp/constraint.cc | 23 ++
gcc/cp/decl.c | 2 ++
gcc/cp/pt.c | 31 +--
gcc/testsuite/g++.dg/cpp2a/concepts-friend3.C | 3 ++
gcc/testsuite/g++.dg/cpp2a/concepts-friend5.C | 8 +
gcc/testsuite/g++.dg/cpp2a/concepts-pr84140.C | 5 ++-
7 files changed, 47 insertions(+), 26 deletions(-)
create mode 100644 gcc/testsuite/g++.dg/cpp2a/concepts-friend5.C
diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
index 77bcf046608..b8035b4360d 100644
--- a/gcc/cp/cp-tree.h
+++ b/gcc/cp/cp-tree.h
@@ -7832,6 +7832,7 @@ extern void remove_constraints (tree);
extern tree current_template_constraints (void);
extern tree associate_classtype_constraints (tree);
extern tree build_constraints (tree, tree);
+extern tree maybe_substitute_reqs_for (tree, const_tree);
extern tree get_template_head_requirements (tree);
extern tree get_trailing_function_requirements (tree);
extern tree get_shorthand_constraints (tree);
diff --git a/gcc/cp/constraint.cc b/gcc/cp/constraint.cc
index 823604afb89..cda644eabe2 100644
--- a/gcc/cp/constraint.cc
+++ b/gcc/cp/constraint.cc
@@ -1189,6 +1189,29 @@ remove_constraints (tree t)
decl_constraints->remove (t);
}
+/* If DECL is a friend, substitute into REQS to produce requirements suitable
+ for declaration matching. */
+
+tree
+maybe_substitute_reqs_for (tree reqs, const_tree decl_)
+{
+ if (reqs == NULL_TREE)
+return NULL_TREE;
+ tree decl = CONST_CAST_TREE (decl_);
+ tree result = STRIP_TEMPLATE (decl);
+ if (DECL_FRIEND_P (result))
+{
+ tree tmpl = decl == result ? DECL_TI_TEMPLATE (result) : decl;
+ tree gargs = generic_targs_for (tmpl);
+ processing_template_decl_sentinel s;
+ if (uses_template_parms (gargs))
+ ++processing_template_decl;
+ reqs = tsubst_constraint (reqs, gargs,
+ tf_warning_or_error, NULL_TREE);
+}
+ return reqs;
+}
+
/* Returns the template-head requires clause for the template
declaration T or NULL_TREE if none. */
diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
index 98ed79f3579..e55de5dd53d 100644
--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -942,6 +942,8 @@ function_requirements_equivalent_p (tree newfn, tree oldfn)
tree reqs2 = get_trailing_function_requirements (oldfn);
if ((reqs1 != NULL_TREE) != (reqs2 != NULL_TREE))
return false;
+ reqs1 = maybe_substitute_reqs_for (reqs1, newfn);
+ reqs2 = maybe_substitute_reqs_for (reqs2, oldfn);
return cp_tree_equal (reqs1, reqs2);
}
diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 209044135cb..45c204e4269 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -10834,29 +10834,12 @@ tsubst_friend_function (tree decl, tree args)
DECL_SAVED_TREE (DECL_TEMPLATE_RESULT (new_friend))
= DECL_SAVED_TREE (DECL_TEMPLATE_RESULT (decl));
- /* Attach the template requirements to the new declaration
- for declaration matching. We need to rebuild the requirements
- so that parameter levels match. */
- if (tree ci = get_constraints (decl))
- {
- tree parms = DECL_TEMPLATE_PARMS (new_friend);
- tree args = generic_targs_for (new_friend);
- tree treqs = tsubst_constraint (CI_TEMPLATE_REQS (ci), args,
- tf_warning_or_error, NULL_TREE);
- tree freqs = tsubst_constraint (CI_DECLARATOR_REQS (ci), args,
- tf_warning_or_error, NULL_TREE);
-
- /* Update the constraints -- these won't really be valid for
-checking, but that's not what we need them for. These ensure
-that the declared function can find the friend during
-declaration matching. */
- tree new_ci = get_constraints (new_friend);
- CI_TEMPLATE_REQS (new_ci) = treqs;
- CI_DECLARATOR_REQS (new_ci) = freqs;
-
- /* Also update the template parameter list. */
- TEMPLATE_PARMS_CONSTRAINTS (parms) = treqs;
- }
+ /* Substitute TEMPLATE_PARMS_CONSTRAINTS so that parameter levels will
+match in decls_match. */
+
