[committed] testsuite: Fix lambda-vis.C for targets with user label prefix '_'.
Hi
The lambda-vis.C test fails everywhere for targets that use a ‘_’ as
USER_LABEL_PREFIX.
This prepends an optional match for the additional USER_LABEL_PREFIX
to the scan assembler checks.
Tested on x86_64-darwin, and linux,
applied to master as obvious,
thanks
Iain
2020-03-22 Iain Sandoe
* g++.dg/abi/lambda-vis.C: Amend assembler match
strings for targets using a USER_LABEL_PREFIX.
diff --git a/gcc/testsuite/g++.dg/abi/lambda-vis.C
b/gcc/testsuite/g++.dg/abi/lambda-vis.C
index c3eb157dc20..89683b2076a 100644
--- a/gcc/testsuite/g++.dg/abi/lambda-vis.C
+++ b/gcc/testsuite/g++.dg/abi/lambda-vis.C
@@ -13,11 +13,11 @@ int gvar = gfoo (capture ([]{}));
inline int ivar = ifoo (capture ([]{}));
-// { dg-final { scan-assembler {_Z7captureINL4svarMUlvE_EE7WrapperIT_EOS2_:} }
}
-// { dg-final { scan-assembler {_Z7captureIN4gvarMUlvE_EE7WrapperIT_EOS2_:} } }
-// { dg-final { scan-assembler {_Z7captureIN4ivarMUlvE_EE7WrapperIT_EOS2_:} } }
+// { dg-final { scan-assembler {_?_Z7captureINL4svarMUlvE_EE7WrapperIT_EOS2_:}
} }
+// { dg-final { scan-assembler {_?_Z7captureIN4gvarMUlvE_EE7WrapperIT_EOS2_:}
} }
+// { dg-final { scan-assembler {_?_Z7captureIN4ivarMUlvE_EE7WrapperIT_EOS2_:}
} }
// Calls to the foos are emitted.
-// { dg-final { scan-assembler {call[
\t]*_Z4sfooI7WrapperINL4svarMUlvE_EEEiT_} { target { i?86-*-* x86_64-*-* } } } }
-// { dg-final { scan-assembler {call[ \t]*_Z4gfooI7WrapperIN4gvarMUlvE_EEEiT_}
{ target { i?86-*-* x86_64-*-* } } } }
-// { dg-final { scan-assembler {call[ \t]*_Z4ifooI7WrapperIN4ivarMUlvE_EEEiT_}
{ target { i?86-*-* x86_64-*-* } } } }
+// { dg-final { scan-assembler {call[
\t]*_?_Z4sfooI7WrapperINL4svarMUlvE_EEEiT_} { target { i?86-*-* x86_64-*-* } }
} }
+// { dg-final { scan-assembler {call[
\t]*_?_Z4gfooI7WrapperIN4gvarMUlvE_EEEiT_} { target { i?86-*-* x86_64-*-* } } }
}
+// { dg-final { scan-assembler {call[
\t]*_?_Z4ifooI7WrapperIN4ivarMUlvE_EEEiT_} { target { i?86-*-* x86_64-*-* } } }
}
[committed] d: Generate phony targets for content imported files (PR93038)
Hi,
This patch is an addition to the last change, which started including
content imported files in the make dependency list. Now phony targets
are also written out if -MP is given.
Bootstrapped and regression tested on x86_64-linux-gnu.
Committed to trunk.
Regards
Iain.
---
gcc/d/ChangeLog:
2020-03-22 Iain Buclaw
PR d/93038
* d-lang.cc (deps_write): Generate phony targets for content imported
files.
gcc/testsuite/ChangeLog:
2020-03-22 Iain Buclaw
PR d/93038
* gdc.dg/pr93038b.d: New test.
---
gcc/d/d-lang.cc | 39 +++--
gcc/testsuite/gdc.dg/pr93038b.d | 8 +++
2 files changed, 26 insertions(+), 21 deletions(-)
create mode 100644 gcc/testsuite/gdc.dg/pr93038b.d
diff --git a/gcc/d/d-lang.cc b/gcc/d/d-lang.cc
index 514799d8e89..6848c5e9a1c 100644
--- a/gcc/d/d-lang.cc
+++ b/gcc/d/d-lang.cc
@@ -157,26 +157,21 @@ deps_write (Module *module, OutBuffer *buffer, unsigned
colmax = 72)
Modules modlist;
modlist.push (module);
- Modules phonylist;
-
- const char *str;
- unsigned size;
+ vec phonylist = vNULL;
unsigned column = 0;
/* Write out make target module name. */
if (d_option.deps_target)
{
- size = d_option.deps_target->offset;
- str = d_option.deps_target->extractString ();
+ buffer->writestring (d_option.deps_target->extractString ());
+ column = d_option.deps_target->offset;
}
else
{
- str = module->objfile->name->str;
- size = strlen (str);
+ buffer->writestring (module->objfile->name->str);
+ column = buffer->offset;
}
- buffer->writestring (str);
- column = size;
buffer->writestring (":");
column++;
@@ -185,21 +180,25 @@ deps_write (Module *module, OutBuffer *buffer, unsigned
colmax = 72)
{
Module *depmod = modlist.pop ();
- str = depmod->srcfile->name->str;
+ const char *modstr = depmod->srcfile->name->str;
/* Skip modules that have already been looked at. */
- if (seen_modules.add (str))
+ if (seen_modules.add (modstr))
continue;
- dependencies.safe_push (str);
+ dependencies.safe_push (modstr);
/* Add to list of phony targets if is not being compile. */
if (d_option.deps_phony && !depmod->isRoot ())
- phonylist.push (depmod);
+ phonylist.safe_push (modstr);
/* Add imported files to dependency list. */
for (size_t i = 0; i < depmod->contentImportedFiles.dim; i++)
- dependencies.safe_push (depmod->contentImportedFiles[i]);
+ {
+ const char *impstr = depmod->contentImportedFiles[i];
+ dependencies.safe_push (impstr);
+ phonylist.safe_push (impstr);
+ }
/* Search all imports of the module. */
for (size_t i = 0; i < depmod->aimports.dim; i++)
@@ -238,8 +237,8 @@ deps_write (Module *module, OutBuffer *buffer, unsigned
colmax = 72)
/* Write out all make dependencies. */
for (size_t i = 0; i < dependencies.length (); i++)
{
- str = dependencies[i];
- size = strlen (str);
+ const char *str = dependencies[i];
+ unsigned size = strlen (str);
column += size;
if (colmax && column > colmax)
@@ -259,12 +258,10 @@ deps_write (Module *module, OutBuffer *buffer, unsigned
colmax = 72)
buffer->writenl ();
/* Write out all phony targets. */
- for (size_t i = 0; i < phonylist.dim; i++)
+ for (size_t i = 0; i < phonylist.length (); i++)
{
- Module *m = phonylist[i];
-
buffer->writenl ();
- buffer->writestring (m->srcfile->name->str);
+ buffer->writestring (phonylist[i]);
buffer->writestring (":\n");
}
}
diff --git a/gcc/testsuite/gdc.dg/pr93038b.d b/gcc/testsuite/gdc.dg/pr93038b.d
new file mode 100644
index 000..04177a7e01a
--- /dev/null
+++ b/gcc/testsuite/gdc.dg/pr93038b.d
@@ -0,0 +1,8 @@
+// https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93038
+// { dg-options "-J $srcdir/gdc.dg/fileimports -MMD -MP" }
+// { dg-do compile }
+// { dg-final { scan-file pr93038b.deps "pr93038b.o: \[^\n\]*/pr93038b.d \[
\n\]*\[^\n\]*/fileimports/pr93038.txt\n\n\[^\n\]*/fileimports/pr93038.txt:"
} }
+// { dg-final { file delete pr93038b.deps } }
+module pr93038b;
+
+const VERSION = import("pr93038.txt");
--
2.20.1
New Spanish PO file for 'gcc' (version 10.1-b20200209)
Hello, gentle maintainer. This is a message from the Translation Project robot. A revised PO file for textual domain 'gcc' has been submitted by the Spanish team of translators. The file is available at: https://translationproject.org/latest/gcc/es.po (This file, 'gcc-10.1-b20200209.es.po', has just now been sent to you in a separate email.) All other PO files for your package are available in: https://translationproject.org/latest/gcc/ Please consider including all of these in your next release, whether official or a pretest. Whenever you have a new distribution with a new version number ready, containing a newer POT file, please send the URL of that distribution tarball to the address below. The tarball may be just a pretest or a snapshot, it does not even have to compile. It is just used by the translators when they need some extra translation context. The following HTML page has been updated: https://translationproject.org/domain/gcc.html If any question arises, please contact the translation coordinator. Thank you for all your work, The Translation Project robot, in the name of your translation coordinator.
[PATCH] Test for sigsetjmp support in analyzer tests requiring that feature.
The new-ish analyzer test cases sigsetjmp-5.c and sigsetjmp-6.c were
failing on nios2-elf and probably other newlib targets due to lack of
support for sigsetjmp. I didn't see a suitable existing
effective-target test for this, so I added one.
OK to commit?
-Sandra
commit 86645c71b1ee8ca228a72a0c21ae38c4264da8fb
Author: Sandra Loosemore
Date: Sun Mar 22 10:22:59 2020 -0700
Test for sigsetjmp support in analyzer tests requiring that feature.
2020-03-22 Sandra Loosemore
gcc/testsuite/
* gcc.dg/analyzer/sigsetjmp-5.c: Require sigsetjmp support.
* gcc.dg/analyzer/sigsetjmp-6.c: Likewise.
* lib/target-supports.exp (check_effective_target_sigsetjmp): New.
diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog
index 892fcb6..32fc629 100644
--- a/gcc/testsuite/ChangeLog
+++ b/gcc/testsuite/ChangeLog
@@ -1,3 +1,9 @@
+2020-03-22 Sandra Loosemore
+
+ * gcc.dg/analyzer/sigsetjmp-5.c: Require sigsetjmp support.
+ * gcc.dg/analyzer/sigsetjmp-6.c: Likewise.
+ * lib/target-supports.exp (check_effective_target_sigsetjmp): New.
+
2020-03-22 Iain Buclaw
PR d/93038
diff --git a/gcc/testsuite/gcc.dg/analyzer/sigsetjmp-5.c b/gcc/testsuite/gcc.dg/analyzer/sigsetjmp-5.c
index 68afe9d..2bc73e8 100644
--- a/gcc/testsuite/gcc.dg/analyzer/sigsetjmp-5.c
+++ b/gcc/testsuite/gcc.dg/analyzer/sigsetjmp-5.c
@@ -1,3 +1,5 @@
+/* { dg-require-effective-target sigsetjmp } */
+
#include
#include
#include "analyzer-decls.h"
diff --git a/gcc/testsuite/gcc.dg/analyzer/sigsetjmp-6.c b/gcc/testsuite/gcc.dg/analyzer/sigsetjmp-6.c
index fcd9d0b..d45804b 100644
--- a/gcc/testsuite/gcc.dg/analyzer/sigsetjmp-6.c
+++ b/gcc/testsuite/gcc.dg/analyzer/sigsetjmp-6.c
@@ -1,3 +1,5 @@
+/* { dg-require-effective-target sigsetjmp } */
+
#include
#include
#include
diff --git a/gcc/testsuite/lib/target-supports.exp b/gcc/testsuite/lib/target-supports.exp
index 4413c26..6456126 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -8984,6 +8984,12 @@ proc check_effective_target_stpcpy {} {
return [check_function_available "stpcpy"]
}
+# Returns 1 if "sigsetjmp" is available on the target system.
+
+proc check_effective_target_sigsetjmp {} {
+return [check_function_available "sigsetjmp"]
+}
+
# Check whether the vectorizer tests are supported by the target and
# append additional target-dependent compile flags to DEFAULT_VECTCFLAGS.
# If a port wants to execute the tests more than once it should append
Re: [Patch, 9/10 Regression] fortran: ICE in build_entry_thunks PR93814
Hi Mark, Please find attached Steve Kargl's fix for PR93814. The attached patch does not match the ChangeLog; it seems to be for PR93484. Regards Thomas
Re: [Patch, 10 Regression] fortran: ICE in gfc_match_assignment PR93600
Hi Mark, Please find attached a fix for PR93600. This builds on the patch originally submitted to the PR by Steve Kargl, the dreaded "Unclassifiable statement error" is replaced by the correct error message. It would have been posted earlier had not one of the test cases failed as a result of the fix for PR93581. A small change (resolve.c) was necessary to fix that. As a free gift this also fixes PR93365. OK to commit? OK. Thanks to you and Steve for the patch! Regards Thomas
[PATCH] Save ref->speculative_id before clone_reference.
Hi.
Similarly to other ipa_ref field, we must preserve the values
before create_reference is called. It's due to fact that ipa_ref
is a pointer to a vector that can be relocated to a different location.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed?
Thanks,
Martin
gcc/ChangeLog:
2020-03-21 Martin Liska
PR ipa/94250
* symtab.c (symtab_node::clone_references): Save speculative_id
as ref may be overwritten by create_reference.
(symtab_node::clone_referring): Likewise.
(symtab_node::clone_reference): Likewise.
---
gcc/symtab.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/gcc/symtab.c b/gcc/symtab.c
index 3022acfc1ea..a36cdccf9c1 100644
--- a/gcc/symtab.c
+++ b/gcc/symtab.c
@@ -670,11 +670,12 @@ symtab_node::clone_references (symtab_node *node)
{
bool speculative = ref->speculative;
unsigned int stmt_uid = ref->lto_stmt_uid;
+ unsigned int spec_id = ref->speculative_id;
ref2 = create_reference (ref->referred, ref->use, ref->stmt);
ref2->speculative = speculative;
ref2->lto_stmt_uid = stmt_uid;
- ref2->speculative_id = ref->speculative_id;
+ ref2->speculative_id = spec_id;
}
}
@@ -689,11 +690,12 @@ symtab_node::clone_referring (symtab_node *node)
{
bool speculative = ref->speculative;
unsigned int stmt_uid = ref->lto_stmt_uid;
+ unsigned int spec_id = ref->speculative_id;
ref2 = ref->referring->create_reference (this, ref->use, ref->stmt);
ref2->speculative = speculative;
ref2->lto_stmt_uid = stmt_uid;
- ref2->speculative_id = ref->speculative_id;
+ ref2->speculative_id = spec_id;
}
}
@@ -704,12 +706,13 @@ symtab_node::clone_reference (ipa_ref *ref, gimple *stmt)
{
bool speculative = ref->speculative;
unsigned int stmt_uid = ref->lto_stmt_uid;
+ unsigned int spec_id = ref->speculative_id;
ipa_ref *ref2;
ref2 = create_reference (ref->referred, ref->use, stmt);
ref2->speculative = speculative;
ref2->lto_stmt_uid = stmt_uid;
- ref2->speculative_id = ref->speculative_id;
+ ref2->speculative_id = spec_id;
return ref2;
}
Re: [PATCH] Test for sigsetjmp support in analyzer tests requiring that feature.
On Sun, 2020-03-22 at 11:31 -0600, Sandra Loosemore wrote: > The new-ish analyzer test cases sigsetjmp-5.c and sigsetjmp-6.c were > failing on nios2-elf and probably other newlib targets due to lack > of > support for sigsetjmp. Sorry about the breakage. > I didn't see a suitable existing > effective-target test for this, so I added one. Thanks. > OK to commit? Looks good to me. Dave
Re: [PING^2][PATCH] Fix documentation of -mpoke-function-name ARM option
Hi Wilco, On Mon, Mar 09, 2020 at 05:53:41PM +, Wilco Dijkstra wrote: > Hi, > > There is no single PC offset that is correct given CPUs may use different > offsets. Isn't it always an offset of 8 in ARM mode and 4 bytes in Thumb mode ? At least in ARMv7 and in AArch32 state in ARMv8 ? > GCC may also schedule the instruction that stores the PC. This feature used to > work on early Arms but is no longer functional or useful today, so the best > way > forward is to remove it altogether. There are many similar options that have > been deprecated for years. > I didn't know that this feature is no longer working. Thank your for the info. Thank your for having reviewed my patch, Jérémy
Re: [PR 94044] ICE with sizeof & argument pack
On Fri, Mar 20, 2020 at 8:41 AM Nathan Sidwell wrote: > If it could be tested on arm &| riscv, that'd be additional verification. I did riscv testing, both cross and native, and didn't see any new problems with the patch. Jim
New Swedish PO file for 'gcc' (version 10.1-b20200209)
Hello, gentle maintainer. This is a message from the Translation Project robot. A revised PO file for textual domain 'gcc' has been submitted by the Swedish team of translators. The file is available at: https://translationproject.org/latest/gcc/sv.po (This file, 'gcc-10.1-b20200209.sv.po', has just now been sent to you in a separate email.) All other PO files for your package are available in: https://translationproject.org/latest/gcc/ Please consider including all of these in your next release, whether official or a pretest. Whenever you have a new distribution with a new version number ready, containing a newer POT file, please send the URL of that distribution tarball to the address below. The tarball may be just a pretest or a snapshot, it does not even have to compile. It is just used by the translators when they need some extra translation context. The following HTML page has been updated: https://translationproject.org/domain/gcc.html If any question arises, please contact the translation coordinator. Thank you for all your work, The Translation Project robot, in the name of your translation coordinator.
Re: [PATCH] Save ref->speculative_id before clone_reference.
> Hi.
>
> Similarly to other ipa_ref field, we must preserve the values
> before create_reference is called. It's due to fact that ipa_ref
> is a pointer to a vector that can be relocated to a different location.
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>
> Ready to be installed?
OK,
thanks!
Honza
> Thanks,
> Martin
>
> gcc/ChangeLog:
>
> 2020-03-21 Martin Liska
>
> PR ipa/94250
> * symtab.c (symtab_node::clone_references): Save speculative_id
> as ref may be overwritten by create_reference.
> (symtab_node::clone_referring): Likewise.
> (symtab_node::clone_reference): Likewise.
> ---
> gcc/symtab.c | 9 ++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
>
>
> diff --git a/gcc/symtab.c b/gcc/symtab.c
> index 3022acfc1ea..a36cdccf9c1 100644
> --- a/gcc/symtab.c
> +++ b/gcc/symtab.c
> @@ -670,11 +670,12 @@ symtab_node::clone_references (symtab_node *node)
> {
>bool speculative = ref->speculative;
>unsigned int stmt_uid = ref->lto_stmt_uid;
> + unsigned int spec_id = ref->speculative_id;
>
>ref2 = create_reference (ref->referred, ref->use, ref->stmt);
>ref2->speculative = speculative;
>ref2->lto_stmt_uid = stmt_uid;
> - ref2->speculative_id = ref->speculative_id;
> + ref2->speculative_id = spec_id;
> }
> }
>
> @@ -689,11 +690,12 @@ symtab_node::clone_referring (symtab_node *node)
> {
>bool speculative = ref->speculative;
>unsigned int stmt_uid = ref->lto_stmt_uid;
> + unsigned int spec_id = ref->speculative_id;
>
>ref2 = ref->referring->create_reference (this, ref->use, ref->stmt);
>ref2->speculative = speculative;
>ref2->lto_stmt_uid = stmt_uid;
> - ref2->speculative_id = ref->speculative_id;
> + ref2->speculative_id = spec_id;
> }
> }
>
> @@ -704,12 +706,13 @@ symtab_node::clone_reference (ipa_ref *ref, gimple
> *stmt)
> {
>bool speculative = ref->speculative;
>unsigned int stmt_uid = ref->lto_stmt_uid;
> + unsigned int spec_id = ref->speculative_id;
>ipa_ref *ref2;
>
>ref2 = create_reference (ref->referred, ref->use, stmt);
>ref2->speculative = speculative;
>ref2->lto_stmt_uid = stmt_uid;
> - ref2->speculative_id = ref->speculative_id;
> + ref2->speculative_id = spec_id;
>return ref2;
> }
>
>
Re: [PATCH v2 3/9] aarch64: Add cmp_*_carryinC patterns
Hi! On Fri, Mar 20, 2020 at 07:42:25PM -0700, Richard Henderson via Gcc-patches wrote: > Duplicate all usub_*_carryinC, but use xzr for the output when we > only require the flags output. The signed versions use sign_extend > instead of zero_extend for combine's benefit. You actually use ANY_EXTEND, which makes a lot more sense :-) Did you see combine create a sign_extend, ever? Or do those just come from combining other insns that already contain a sign_extend? Segher
Re: [PATCH v2 3/9] aarch64: Add cmp_*_carryinC patterns
On 3/22/20 12:30 PM, Segher Boessenkool wrote: > Hi! > > On Fri, Mar 20, 2020 at 07:42:25PM -0700, Richard Henderson via Gcc-patches > wrote: >> Duplicate all usub_*_carryinC, but use xzr for the output when we >> only require the flags output. The signed versions use sign_extend >> instead of zero_extend for combine's benefit. > > You actually use ANY_EXTEND, which makes a lot more sense :-) > > Did you see combine create a sign_extend, ever? Or do those just come > from combining other insns that already contain a sign_extend? In the penultimate patch, for cmpti, I emit this sign_extend'ed pattern manually, so that rtl actually gets the proper description of the comparison of the high-half of the TImode variable. r~
[PATCH] c++: Avoid a suspicious -Wnoexcept warning [PR93805]
In this PR we're emitting -Wnoexcept warnings about potentially-throwing NSDMIs
when computing the noexcept specification of a class's defaulted default
constructor. Alhough these warnings are in some sense valid, this patch takes
the route of suppressing them, because:
1. the warning message is confusing in its current form;
2. warning for 'struct C { B b = B(); };' but not for 'struct C { B b; };'
is inconsistent; and
3. emitting a warning here arguably doesn't fall under the umbrella of
-Wnoexcept, whose documentation says it warns only when a
noexcept-expression evaluates to false, but there are noexcept-expressions
here.
Tested on x86_64-pc-linux-gnu, does this look OK to commit?
gcc/cp/ChangeLog:
PR c++/93805
* method.c (walk_field_subobs): Pass tf_none as the complain argument to
expr_noexcept_p.
gcc/testsuite/ChangeLog:
PR c++/93805
* g++.dg/warn/Wnoexcept2.C: New test.
---
gcc/cp/method.c| 2 +-
gcc/testsuite/g++.dg/warn/Wnoexcept2.C | 15 +++
2 files changed, 16 insertions(+), 1 deletion(-)
create mode 100644 gcc/testsuite/g++.dg/warn/Wnoexcept2.C
diff --git a/gcc/cp/method.c b/gcc/cp/method.c
index c131fd41536..41b9ff86bdd 100644
--- a/gcc/cp/method.c
+++ b/gcc/cp/method.c
@@ -1988,7 +1988,7 @@ walk_field_subobs (tree fields, special_function_kind
sfk, tree fnname,
if (nsdmi == error_mark_node)
*spec_p = error_mark_node;
else if (*spec_p != error_mark_node
- && !expr_noexcept_p (nsdmi, complain))
+ && !expr_noexcept_p (nsdmi, tf_none))
*spec_p = noexcept_false_spec;
}
/* Don't do the normal processing. */
diff --git a/gcc/testsuite/g++.dg/warn/Wnoexcept2.C
b/gcc/testsuite/g++.dg/warn/Wnoexcept2.C
new file mode 100644
index 000..60541be3575
--- /dev/null
+++ b/gcc/testsuite/g++.dg/warn/Wnoexcept2.C
@@ -0,0 +1,15 @@
+// PR c++/93805
+// { dg-do compile { target c++11 } }
+// { dg-additional-options "-Wnoexcept" }
+
+struct B
+{
+ B() {}
+};
+
+struct C
+{
+ B b = B();
+};
+
+C c; // { dg-bogus "noexcept-expression" }
--
2.26.0.rc1.11.g30e9940356
Re: [PATCH v2 7/9] aarch64: Adjust result of aarch64_gen_compare_reg
Hi! On Fri, Mar 20, 2020 at 07:42:29PM -0700, Richard Henderson via Gcc-patches wrote: > @@ -2382,7 +2382,7 @@ aarch64_gen_compare_reg_maybe_ze (RTX_CODE code, rtx x, > rtx y, > cc_mode = CC_SWPmode; > cc_reg = gen_rtx_REG (cc_mode, CC_REGNUM); > emit_set_insn (cc_reg, t); > - return cc_reg; > + return gen_rtx_fmt_ee (code, VOIDmode, cc_reg, const0_rtx); > } > } > > @@ -18506,7 +18506,8 @@ aarch64_expand_compare_and_swap (rtx operands[]) > >emit_insn (gen_aarch64_compare_and_swap_lse (mode, rval, mem, > newval, mod_s)); > - cc_reg = aarch64_gen_compare_reg_maybe_ze (NE, rval, oldval, mode); > + x = aarch64_gen_compare_reg_maybe_ze (EQ, rval, oldval, mode); > + PUT_MODE (x, SImode); Maybe this stuff would be simpler (and more obviously correct) if it was more explicit CC_REGNUM is a fixed register, and the code would use it directly everywhere? (Something for stage1 I suppose, if you / the aarch people want to do this at all :-) ) This patch does look correct to me, fwiw. Segher
Re: [PATCH v2 7/9] aarch64: Adjust result of aarch64_gen_compare_reg
On 3/22/20 2:55 PM, Segher Boessenkool wrote: > Maybe this stuff would be simpler (and more obviously correct) if it > was more explicit CC_REGNUM is a fixed register, and the code would use > it directly everywhere? Indeed the biggest issue I have in this patch is what CC_MODE to expose from the high-half compare. For unsigned inequality, only the C bit is valid. For signed inequality, only the N + V bits. For equality, only the Z bit. Which I am trying to expose with the multiple creations of CC_REGNUM, which are used within the comparison, which are indeed sanity checked vs the comparison code via %m/%M. But the mode of the CC_REGNUM does not necessarily match up with the mode of the comparison that generates it. And we do not have a CC_NVmode, so I'm using full CCmode for that. This is the part of the patch that could use the most feedback. r~
[PATCH] c++: Fix ICE in tsubst_default_argument [PR92010]
This patch relaxes an assertion in tsubst_default_argument that exposes a latent
bug in how we substitute an array type into a cv-qualified wildcard function
parameter type. Concretely, the latent bug is that given the function template
template void foo(const T t);
one would expect the type of foo to be void(const int*), but we
(seemingly prematurely) strip function parameter types of their top-level
cv-qualifiers when building the function's TYPE_ARG_TYPES, and instead end up
obtaining void(int*) as the type of foo after substitution and decaying.
We still however correctly substitute into and decay the formal parameter type,
obtaining const int* as the type of t after substitution. But this then leads
to us tripping over the assert in tsubst_default_argument that verifies the
formal parameter type and the function type are consistent.
Assuming it's too late at this stage to fix the substitution bug, we can still
relax the assertion like so. Tested on x86_64-pc-linux-gnu, does this look OK?
gcc/cp/ChangeLog:
PR c++/92010
* pt.c (tsubst_default_argument): Relax assertion to permit
disagreements between the function type and the parameter type
about the cv-qualification of the pointed-to type.
gcc/testsuite/ChangeLog:
PR c++/92010
* g++.dg/template/defarg22.C: New test.
---
gcc/cp/pt.c | 17 -
gcc/testsuite/g++.dg/template/defarg22.C | 11 +++
2 files changed, 27 insertions(+), 1 deletion(-)
create mode 100644 gcc/testsuite/g++.dg/template/defarg22.C
diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 9e1eb9416c9..923166276b8 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -13337,7 +13337,22 @@ tsubst_default_argument (tree fn, int parmnum, tree
type, tree arg,
if (parmtype == error_mark_node)
return error_mark_node;
- gcc_assert (same_type_ignoring_top_level_qualifiers_p (type, parmtype));
+ if (same_type_ignoring_top_level_qualifiers_p (type, parmtype))
+;
+ else if (POINTER_TYPE_P (type) && POINTER_TYPE_P (parmtype))
+{
+ /* The function type and the parameter type can disagree about the
+cv-qualification of the pointed-to type; see PR92010. */
+ gcc_assert (same_type_p (TREE_TYPE (type),
+ strip_top_quals (TREE_TYPE (parmtype;
+ /* Verify that this happens only when the dependent parameter type is a
+cv-qualified wildcard type. */
+ tree pattern_parm = get_pattern_parm (parm, DECL_TI_TEMPLATE (fn));
+ gcc_assert (WILDCARD_TYPE_P (TREE_TYPE (pattern_parm))
+ && cv_qualified_p (TREE_TYPE (pattern_parm)));
+}
+ else
+gcc_unreachable ();
tree *slot;
if (defarg_inst && (slot = defarg_inst->get (parm)))
diff --git a/gcc/testsuite/g++.dg/template/defarg22.C
b/gcc/testsuite/g++.dg/template/defarg22.C
new file mode 100644
index 000..cf6261916d8
--- /dev/null
+++ b/gcc/testsuite/g++.dg/template/defarg22.C
@@ -0,0 +1,11 @@
+// PR c++/92010
+// { dg-do compile }
+
+template
+void foo(const T t = 0)
+{ }
+
+int main()
+{
+ foo();
+}
--
2.26.0.rc1.11.g30e9940356
Re: [PATCH] Support the new ("v0") mangling scheme in rust-demangle.
Ping: https://gcc.gnu.org/pipermail/gcc-patches/2020-March/542012.html Thanks, - Eddy B. On Fri, Mar 13, 2020, at 10:28 PM, Eduard-Mihai Burtescu wrote: > This is the libiberty (mainly for binutils/gdb) counterpart of > https://github.com/alexcrichton/rustc-demangle/pull/23. > > Relevant links for the new Rust mangling scheme (aka "v0"): > * Rust RFC: https://github.com/rust-lang/rfcs/pull/2603 > * tracking issue: https://github.com/rust-lang/rust/issues/60705 > * implementation: https://github.com/rust-lang/rust/pull/57967 > > This implementation includes full support for UTF-8 identifiers > via punycode, so I've included a testcase for that as well. > (Let me know if it causes any issues and I'll take it out) > > Last year I've submitted several small patches to rust-demangle > in preparation for upstreaming the entire new demangler, and > feedback from that has proven useful. > For example, I started with error-handling macros, but instead > the code now has "rdm->errored = 1;" before several returns/gotos. > > The patch is attached instead of inline, as it's over 1000 lines long. > > Bootstrapped and tested on x86_64-unknown-linux-gnu. > > Also, I have no commit access, so I'd be thankful if > someone would commit this for me if/once approved. > Attachments: > * 0001-Support-the-new-v0-mangling-scheme-in-rust-demangle.patch
[RS6000] PR94145, make PLT loads volatile
On Wed, Mar 18, 2020 at 04:53:59PM -0500, Segher Boessenkool wrote:
> Could you please send a new patch (could be the same patch even) that
> is easier to review for me?
The PLT is volatile. On PowerPC it is a bss style section which the
dynamic loader initialises to point at resolver stubs (called glink on
PowerPC64) to support lazy resolution of function addresses. The
first call to a given function goes via the dynamic loader symbol
resolver, which updates the PLT entry for that function and calls the
function. The second call, if there is one and we don't have a
multi-threaded race, will use the updated PLT entry and thus avoid
the relatively slow symbol resolver path.
Calls via the PLT are like calls via a function pointer, except that
no initialised function pointer is volatile like the PLT. All
initialised function pointers are resolved at program startup to point
at the function or are left as NULL. There is no support for lazy
resolution of any user visible function pointer.
So why does any of this matter to gcc? Well, normally the PLT call
mechanism happens entirely behind gcc's back, but since we implemented
inline PLT calls (effectively putting the PLT code stub that loads the
PLT entry inline and making that code sequence scheduled), the load of
the PLT entry is visible to gcc. That load then is subject to gcc
optimization, for example in
/* -S -mcpu=future -mpcrel -mlongcall -O2. */
int foo (int);
void bar (void)
{
while (foo(0))
foo (99);
}
we see the PLT load for foo being hoisted out of the loop and stashed
in a call-saved register. If that happens to be the first call to
foo, then the stashed value is that for the resolver stub, and every
call to foo in the loop will then go via the slow resolver path. Not
a good idea. Also, if foo turns out to be a local function and the
linker replaces the PLT calls with direct calls to foo then gcc has
just wasted a call-saved register.
This patch teaches gcc that the PLT loads are volatile. The change
doesn't affect other loads of function pointers and thus has no effect
on normal indirect function calls. Note that because the
"optimization" this patch prevents can only occur over function calls,
the only place gcc can stash PLT loads is in call-saved registers or
in other memory. I'm reasonably confident that this change will be
neutral or positive for the "ld -z now" case where the PLT is not
volatile, in code where there is any register pressure. Even if gcc
could be taught to recognise cases where the PLT is resolved, you'd
need to discount use of registers to cache PLT loads by some factor
involving the chance that those calls would be converted to direct
calls..
PR target/94145
* config/rs6000/rs6000.c (rs6000_longcall_ref): Use unspec_volatile
for PLT16_LO and PLT_PCREL.
* config/rs6000/rs6000.md (UNSPEC_PLT16_LO, UNSPEC_PLT_PCREL): Remove.
(UNSPECV_PLT16_LO, UNSPECV_PLT_PCREL): Define.
(pltseq_plt16_lo_, pltseq_plt_pcrel): Use unspec_volatile.
diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
index 07f7cf516ba..68046fdb5ee 100644
--- a/gcc/config/rs6000/rs6000.c
+++ b/gcc/config/rs6000/rs6000.c
@@ -19274,8 +19274,9 @@ rs6000_longcall_ref (rtx call_ref, rtx arg)
if (rs6000_pcrel_p (cfun))
{
rtx reg = gen_rtx_REG (Pmode, regno);
- rtx u = gen_rtx_UNSPEC (Pmode, gen_rtvec (3, base, call_ref, arg),
- UNSPEC_PLT_PCREL);
+ rtx u = gen_rtx_UNSPEC_VOLATILE (Pmode,
+ gen_rtvec (3, base, call_ref, arg),
+ UNSPECV_PLT_PCREL);
emit_insn (gen_rtx_SET (reg, u));
return reg;
}
@@ -19294,8 +19295,9 @@ rs6000_longcall_ref (rtx call_ref, rtx arg)
rtx reg = gen_rtx_REG (Pmode, regno);
rtx hi = gen_rtx_UNSPEC (Pmode, gen_rtvec (3, base, call_ref, arg),
UNSPEC_PLT16_HA);
- rtx lo = gen_rtx_UNSPEC (Pmode, gen_rtvec (3, reg, call_ref, arg),
- UNSPEC_PLT16_LO);
+ rtx lo = gen_rtx_UNSPEC_VOLATILE (Pmode,
+ gen_rtvec (3, reg, call_ref, arg),
+ UNSPECV_PLT16_LO);
emit_insn (gen_rtx_SET (reg, hi));
emit_insn (gen_rtx_SET (reg, lo));
return reg;
diff --git a/gcc/config/rs6000/rs6000.md b/gcc/config/rs6000/rs6000.md
index ad88b6783af..5a8e9de670b 100644
--- a/gcc/config/rs6000/rs6000.md
+++ b/gcc/config/rs6000/rs6000.md
@@ -148,8 +148,6 @@
UNSPEC_SI_FROM_SF
UNSPEC_PLTSEQ
UNSPEC_PLT16_HA
- UNSPEC_PLT16_LO
- UNSPEC_PLT_PCREL
])
;;
@@ -178,6 +176,8 @@
UNSPECV_MTFSB1 ; Set FPSCR Field bit to 1
UNSPECV_SPLIT_STACK_RETURN ; A camouflaged return
UNSPECV_SPEC_BARRIER ; Speculation barrier
+ UNSPECV_PLT16_LO
+ UNSPECV_PLT_PCREL
])
; The three different kinds of epi
Re: [PATCH] c++: Fix ICE in tsubst_default_argument [PR92010]
On Sun, 22 Mar 2020, Patrick Palka wrote:
> This patch relaxes an assertion in tsubst_default_argument that exposes a
> latent
> bug in how we substitute an array type into a cv-qualified wildcard function
> parameter type. Concretely, the latent bug is that given the function
> template
>
> template void foo(const T t);
>
> one would expect the type of foo to be void(const int*), but we
> (seemingly prematurely) strip function parameter types of their top-level
> cv-qualifiers when building the function's TYPE_ARG_TYPES, and instead end up
> obtaining void(int*) as the type of foo after substitution and
> decaying.
>
> We still however correctly substitute into and decay the formal parameter
> type,
> obtaining const int* as the type of t after substitution. But this then leads
> to us tripping over the assert in tsubst_default_argument that verifies the
> formal parameter type and the function type are consistent.
>
> Assuming it's too late at this stage to fix the substitution bug, we can still
> relax the assertion like so. Tested on x86_64-pc-linux-gnu, does this look
> OK?
>
> gcc/cp/ChangeLog:
>
> PR c++/92010
> * pt.c (tsubst_default_argument): Relax assertion to permit
> disagreements between the function type and the parameter type
> about the cv-qualification of the pointed-to type.
>
> gcc/testsuite/ChangeLog:
>
> PR c++/92010
> * g++.dg/template/defarg22.C: New test.
> ---
Here's a slightly simpler version of the patch that moves the
POINTER_TYPE_P checks into the gcc_assert:
-- >8 --
---
gcc/cp/pt.c | 16 +++-
gcc/testsuite/g++.dg/template/defarg22.C | 11 +++
2 files changed, 26 insertions(+), 1 deletion(-)
create mode 100644 gcc/testsuite/g++.dg/template/defarg22.C
diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 03a8dfbd37c..849628840d6 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -13337,7 +13337,21 @@ tsubst_default_argument (tree fn, int parmnum, tree
type, tree arg,
if (parmtype == error_mark_node)
return error_mark_node;
- gcc_assert (same_type_ignoring_top_level_qualifiers_p (type, parmtype));
+ if (same_type_ignoring_top_level_qualifiers_p (type, parmtype))
+;
+ else
+{
+ /* The function type and the parameter type can disagree about the
+cv-qualification of the pointed-to type; see PR92010. */
+ gcc_assert (POINTER_TYPE_P (type) && POINTER_TYPE_P (parmtype)
+ && same_type_p (TREE_TYPE (type),
+ strip_top_quals (TREE_TYPE (parmtype;
+ /* Verify that this happens only when the dependent parameter type is a
+cv-qualified wildcard type. */
+ tree pattern_parm = get_pattern_parm (parm, DECL_TI_TEMPLATE (fn));
+ gcc_assert (WILDCARD_TYPE_P (TREE_TYPE (pattern_parm))
+ && cv_qualified_p (TREE_TYPE (pattern_parm)));
+}
tree *slot;
if (defarg_inst && (slot = defarg_inst->get (parm)))
diff --git a/gcc/testsuite/g++.dg/template/defarg22.C
b/gcc/testsuite/g++.dg/template/defarg22.C
new file mode 100644
index 000..cf6261916d8
--- /dev/null
+++ b/gcc/testsuite/g++.dg/template/defarg22.C
@@ -0,0 +1,11 @@
+// PR c++/92010
+// { dg-do compile }
+
+template
+void foo(const T t = 0)
+{ }
+
+int main()
+{
+ foo();
+}
--
2.26.0.rc1.11.g30e9940356
[PATCH PR94266] aarch64：ICE during GIMPLE pass: forwprop
Hi The attached testcase triggers ICE when testing GCC trunk on aarch64 with -S -O2 -ftree-loop-vectorize -march=armv8.2-a+sve -msve-vector-bits=256. Before the forwprop pass, we have two gimple statements as follows: _43 = &MEM[base: _5, offset: 0B]; vect__2.7_24 = MEM [(int *)_43]; The forwprop pass tries to forward propgate the &MEM[base: _5, offset: 0B] to the base of the MEM [(int *)_43]. Thus, we get a gimple statement as follows: vect__2.7_24 = MEM [(int *)&MEM[base: _5, offset: 0B]]; As the &MEM[base: _5, offset: 0B] is a ADDR_EXPR as well as a invalid address for gimple MEM_REF, ICE triggers in function maybe_canonicalize_mem_ref_addr at gcc/gimple-fold.c:4899 as follows: gcc_checking_assert (TREE_CODE (TREE_OPERAND (*t, 0)) == DEBUG_EXPR_DECL || is_gimple_mem_ref_addr (TREE_OPERAND (*t, 0))); where *t is the MEM [(int *)&MEM[base: _5, offset: 0B]] at that time. A simple solution is to add a check before forward propgating a ADDR_EXPR to a MEM_REF. Attached please find the proposed patch. Newly add test fail without the patch and pass after applying the patch. Bootstrap and tested on aarch64 and x86 Linux platform. No new regression witnessed. Any suggestion? Thanks, Qian Chao Log: +2020-03-23 Qian chao + + PR c/94266 + * gcc/tree-ssa-forwprop.c (forward_propagate_addr_expr_1): Add check before forward propgating ADDR_EXPR to the operand of MEM_REF. gcc/testsuite: +2020-03-23 Qian chao + + PR c/94266 + * gcc.target/aarch64/pr94266.c：New test. pr94266-v0.patch Description: pr94266-v0.patch
Re: [PATCH PR94266] aarch64：ICE during GIMPLE pass: forwprop
On Sun, Mar 22, 2020 at 11:13 PM qianchao wrote: > > Hi > > The attached testcase triggers ICE when testing GCC trunk on aarch64 with -S > -O2 -ftree-loop-vectorize -march=armv8.2-a+sve -msve-vector-bits=256. > > Before the forwprop pass, we have two gimple statements as follows: > > _43 = &MEM[base: _5, offset: 0B]; > vect__2.7_24 = MEM [(int *)_43]; > > The forwprop pass tries to forward propgate the &MEM[base: _5, offset: 0B] to > the base of the MEM [(int *)_43]. Thus, we get a gimple > statement as follows: > > vect__2.7_24 = MEM [(int *)&MEM[base: _5, offset: 0B]]; This should have simplified to: MEM [base: _5, offset: 0B]; And not generate the invalid MEM Of an address expression of a MEM. > > As the &MEM[base: _5, offset: 0B] is a ADDR_EXPR as well as a invalid address > for gimple MEM_REF, ICE triggers in function maybe_canonicalize_mem_ref_addr > at gcc/gimple-fold.c:4899 as follows: > > gcc_checking_assert (TREE_CODE (TREE_OPERAND (*t, 0)) == DEBUG_EXPR_DECL >|| is_gimple_mem_ref_addr (TREE_OPERAND (*t, 0))); > > where *t is the MEM [(int *)&MEM[base: _5, offset: 0B]] at > that time. > > A simple solution is to add a check before forward propgating a ADDR_EXPR to > a MEM_REF. No that is wrong, the transformation is correct, just a missing folding. Thanks, Andrew Pinski > > Attached please find the proposed patch. > > Newly add test fail without the patch and pass after applying the patch. > > Bootstrap and tested on aarch64 and x86 Linux platform. No new regression > witnessed. > > Any suggestion? > Thanks, > Qian Chao > > Log: > +2020-03-23 Qian chao > + > + PR c/94266 > + * gcc/tree-ssa-forwprop.c (forward_propagate_addr_expr_1): Add check > before forward propgating ADDR_EXPR to the operand of MEM_REF. > > gcc/testsuite: > +2020-03-23 Qian chao > + > + PR c/94266 > + * gcc.target/aarch64/pr94266.c：New test.
