Re: ChangeLog files - server and client scripts
On Thu, May 21, 2020 at 03:12:21PM -0700, Ian Lance Taylor via Gcc wrote: > Hi, this unfortunately breaks gccgo development. Significant parts of > the gccgo sources are simply copied from other repositories. Those > other repositories do not use ChangeLog files. The git commit hook > should not require ChangeLog files for those changes. And, when the > time comes, no ChangeLog files should be created for changes in those > directories. > > The directories in question are > > gcc/go/gofrontend > libgo > gcc/testsuite/go.test/test The script has: ignored_prefixes = [ 'gcc/d/dmd/', 'gcc/go/frontend/', 'libgo/', 'libphobos/libdruntime', 'libphobos/src/', 'libsanitizer/', ] so perhaps it just misses gcc/testsuite/go.test/test ? Or what exact files you've changed in your script? Jakub
Re: [PATCH][PR92658] Add missing vector truncmn2 expanders for avx512f
On Thu, May 21, 2020 at 7:18 PM Uros Bizjak wrote: > > On Thu, May 21, 2020 at 7:35 AM Hongtao Liu wrote: > > > > On Wed, May 20, 2020 at 11:43 PM Uros Bizjak wrote: > > > > > > On Wed, May 20, 2020 at 10:35 AM Hongtao Liu wrote: > > > > > > > > Hi: > > > > Bootstrap is ok, regression test on i386/x86-64 backend is ok. > > > > > > > > gcc/ChangeLog: > > > > PR target/92658 > > > > * config/i386/sse.md > > > > (trunc2, truncv32hiv32qi2, > > > > trunc2): New expander. > > > > > > > > gcc/testsuite/ChangeLog: > > > > * gcc.target/i386/pr92658-avx512f.c: New test. > > > > * gcc.target/i386/pr92658-avx512vl.c: Ditto. > > > > * gcc.target/i386/pr92658-avx512bw-trunc.c: Ditto. > > > > > > There are more conversions to be added. There are: > > > > > > V2DImode to V2QImode, V2HImode, V2SImode > > > V4DImode to V4QImode, V4HImode, V4SImode > > > V8DImode to V8QImode, V8HImode, V8SImode > > > > > > V4SImode to V4QImode, V4HImode > > > V8SImode to V8QImode, V8HImode > > > V16SImode to V16QImode, V16HImode > > > > > > V8HImode to V8QImode > > > V16HImode to V16QImode > > > V32HImode to V32QImode > > > > > All of them are added > > > > Vectorization failure: (Add xfail in testcase for them since they need > > generic part) > > V2DImode to V2QImode, V2HImode > > V4DImode to V4QImode, V4HImode > > V8DImode to V8QImode > > > > V4SImode to V4QImode, V4HImode > > V8SImode to V8QImode > > > > V8HImode to V8QImode > > > > Vectorization success: > > V2DImode to V2SImode (under TARGET_MMX_WITH_SSE) > > V4DImode to V4SImode > > V8DImode to V8HImode, V8SImode > > > > V8SImode to V8HImode > > V16SImode to V16QImode, V16HImode > > > > V32HImode to V32QImode > > V16HImode to V16HImode. > > > > > > > Uros. > > > > Update patch. > > Regression test on i386/x86-64 backend is ok, bootstrap is ok. > > > > gcc/ChangeLog: > > PR target/92658 > > * config/i386/sse.md > > (trunc2): New expander > > (truncv32hiv32qi2): Ditto. > > (trunc2): Ditto. > > (trunc2): Ditto. > > (trunc2): Ditto. > > (truncv2div2si2): Ditto. > > (truncv8div8qi2): Ditto. > > (avx512f_v8div16qi2): Renaming > > from *avx512f_v8div16qi2. > > (avx512vl_v2div2si): Renaming > > from *avx512vl_v2div2si2. > > (avx512vl_v2qi2): Renaming > > from *avx512vl_vqi2. > > > > gcc/testsuite/ChangeLog: > > * gcc.target/i386/pr92658-avx512f.c: New test. > > * gcc.target/i386/pr92658-avx512vl.c: Ditto. > > * gcc.target/i386/pr92658-avx512bw-trunc.c: Ditto. > > > + rtx op = simplify_subreg (V16QImode, operands[0], mode, 0); > + operands[0] = op ? op : gen_rtx_SUBREG (V16QImode, operands[0], 0); > > You should use simplify_gen_subreg, without null op fixup: > > operands[0] = simplify_gen_subreg (V16QImode, operands[0], mode, > 0); > Changed. > + "TARGET_MMX_WITH_SSE && TARGET_AVX512VL" > > Do you really need TARGET_MMX_WITH_SSE? Narrow modes are active even > without this flag. > Changed. > Uros. Update patch. -- BR, Hongtao 0001-Add-missing-vector-truncmn2-expanders-PR92658_V3.patch Description: Binary data
[PATCH v3] Add -fuse-ld= to specify an arbitrary executable as the linker
On 2020-05-21, Martin Liška wrote:
On 5/21/20 1:52 AM, Fangrui Song wrote:
The above issues motivated me to touch this line in PATCH v2.
Dropped in PATCH v2.
Thank you for the updated patch.
The patch is fine except coding style issues:
$ ./contrib/check_GNU_style.py
/tmp/0001-Add-fuse-ld-to-specify-an-arbitrary-executable-as-th.patch
=== ERROR type #1: blocks of 8 spaces should be replaced with tabs (4 error(s))
===
gcc/collect2.c:1135:0:ld_file_name = find_a_file(,
ld_suffixes[selected_linker], X_OK);
gcc/collect2.c:1137:0: for `ld' (if native linking) or `TARGET-ld' (if
cross). */
gcc/collect2.c:1139:0:ld_file_name =
gcc/collect2.c:1140:0:find_a_file(,
full_ld_suffixes[selected_linker], X_OK);
=== ERROR type #2: there should be exactly one space between function name and
parenthesis (2 error(s)) ===
gcc/collect2.c:1135:34:ld_file_name = find_a_file(,
ld_suffixes[selected_linker], X_OK);
gcc/collect2.c:1140:23:find_a_file(,
full_ld_suffixes[selected_linker], X_OK);
Thank you. I did not know ./contrib/check_GNU_style.py
PATCH v3 fixes the above style issues and checks both cpath and path
which appears to make more sense (and compatible with clang).
=== ERROR type #3: trailing operator (1 error(s)) ===
gcc/collect2.c:1139:21:ld_file_name =
but I can't fix this one because joining two lines will break the 80-column
rule.
Note that I can't approve the patch, please wait for a reviewer that can
approve it.
Martin
I'll wait for a reviewer to approve and apply it.
>From 1fea80498891db3fef831bd65f231603951e5f14 Mon Sep 17 00:00:00 2001
From: Fangrui Song
Date: Tue, 19 May 2020 12:21:26 -0700
Subject: [PATCH] Add -fuse-ld= to specify an arbitrary executable as the
linker
The value can be either a relative path (relative to a COMPILER_PATH
directory or a PATH directory) or an absolute path. Unlike
-fuse-ld={bfd,gold,lld}, -fuse-ld= does not add a prefix `ld.`
PR driver/93645
* common.opt (-fuse-ld=): Add -fuse-ld=.
* opts.c (common_handle_option): Handle OPT_fuse_ld_.
* gcc.c (driver_handle_option): Likewise.
* collect2.c (main): Likewise.
* doc/invoke.texi: Document -fuse-ld=.
---
gcc/collect2.c | 32
gcc/common.opt | 4
gcc/doc/invoke.texi | 4
gcc/opts.c | 1 +
4 files changed, 33 insertions(+), 8 deletions(-)
diff --git a/gcc/collect2.c b/gcc/collect2.c
index f8a5ce45994..cc57a20e08b 100644
--- a/gcc/collect2.c
+++ b/gcc/collect2.c
@@ -844,6 +844,7 @@ main (int argc, char **argv)
const char **ld1;
bool use_plugin = false;
bool use_collect_ld = false;
+ const char *use_ld = NULL;
/* The kinds of symbols we will have to consider when scanning the
outcome of a first pass link. This is ALL to start with, then might
@@ -967,6 +968,11 @@ main (int argc, char **argv)
selected_linker = USE_GOLD_LD;
else if (strcmp (argv[i], "-fuse-ld=lld") == 0)
selected_linker = USE_LLD_LD;
+ else if (!strncmp (argv[i], "-fuse-ld=", 9))
+ {
+ use_ld = argv[i] + 9;
+ selected_linker = USE_LD_MAX;
+ }
else if (strncmp (argv[i], "-o", 2) == 0)
{
/* Parse the output filename if it's given so that we can make
@@ -1117,14 +1123,24 @@ main (int argc, char **argv)
ld_file_name = find_a_file (, collect_ld_suffix, X_OK);
use_collect_ld = ld_file_name != 0;
}
- /* Search the compiler directories for `ld'. We have protection against
- recursive calls in find_a_file. */
- if (ld_file_name == 0)
-ld_file_name = find_a_file (, ld_suffixes[selected_linker], X_OK);
- /* Search the ordinary system bin directories
- for `ld' (if native linking) or `TARGET-ld' (if cross). */
- if (ld_file_name == 0)
-ld_file_name = find_a_file (, full_ld_suffixes[selected_linker], X_OK);
+ if (selected_linker == USE_LD_MAX)
+{
+ ld_file_name = find_a_file (, use_ld, X_OK);
+ if (ld_file_name == 0)
+ ld_file_name = find_a_file (, use_ld, X_OK);
+}
+ else
+{
+ /* Search the compiler directories for `ld'. We have protection against
+ recursive calls in find_a_file. */
+ if (ld_file_name == 0)
+ ld_file_name = find_a_file (, ld_suffixes[selected_linker], X_OK);
+ /* Search the ordinary system bin directories
+ for `ld' (if native linking) or `TARGET-ld' (if cross). */
+ if (ld_file_name == 0)
+ ld_file_name =
+ find_a_file (, full_ld_suffixes[selected_linker], X_OK);
+}
#ifdef REAL_NM_FILE_NAME
nm_file_name = find_a_file (, REAL_NM_FILE_NAME, X_OK);
diff --git a/gcc/common.opt b/gcc/common.opt
index 4464049fc1f..6408d042d8c 100644
--- a/gcc/common.opt
+++ b/gcc/common.opt
@@ -2908,6 +2908,10 @@ fuse-ld=lld
Common Driver Negative(fuse-ld=lld)
Use the lld LLVM linker instead of the default linker.
+fuse-ld=
+Common Driver Joined
+Use the specified executable instead of the default linker.
+
fuse-linker-plugin
Common Undocumented
Re: [PATCH 1/2] rs6000: tune cunroll for simple loops at O2
Jiufu Guo writes: > Jan Hubicka writes: > >>> Segher Boessenkool writes: >>> >>> > On Wed, May 20, 2020 at 12:30:30PM +0200, Richard Biener wrote: >>> >> I think this is the wrong way to approach this. You're doing too many >>> >> things at once. Try to fix the powerpc regression with the extra >>> >> flag_rtl_unroll_loops, that could be backported. Then you can >>> >>> Or flag_complete_unroll_loops(-fcomplete-unroll-loops) for GIMPLE >>> cunroll? >>> >> independently see whether enabling more unrolling at -O2 makes >>> >> sense. Because currently we _do_ unroll at -O2 when it does >>> >> not increase size. Its just your patches make this as aggressive >>> >> as -O3. >>> >>> I'm also thinking about enabling more cunroll at -O2 even with some size >>> increasing. Full cunroll enablement make it like -O3. As some >>> discussion in PRs (e.g. PR88760), small/simple loops unrolling may be in >>> favor of some platforms (but not for all platforms, like x86_64?). This >>> would make us to have target specified hook. Or do some generic >>> setting: accept to unroll/peel limit times if the loop body is simple >>> and small, together with target specific hook. >> >> We now have --params that can be tuned differently for -O2 and -O3 so One thing about tunning --param based on optimization level, some times difference function may has different optimization level. While --params may not be set per function, if so, --param may not work as expect at some functions. Not sure if this is an issue you may concern about. Thanks! Jiufu >> looking into cunroll was one of my todo for GCC 10 -O2 retuning but i did >> not get any very conclusive benchmark results outside SPEC. >> I planned to return to it next stage1, so it may be good time. >> Do you have any benchmarks on ppc? > > 541.leela_r, 548.exchange2_r and 557.xz_r from SPEC2017 are visbily > affected by cunroll. They can be used to tune cunroll, I think. > >> Of couse there is no need to keep same defaults for all targets, but in >> general having target specific defaults increases number of knobs we >> need to check and keep up to date. > > Thanks, > Jiufu > >> >> Honza > >>> >>> Any comments? Thanks! >>> Jiufu >>> >>> > >>> > Just do a separate flag (and option) for cunroll, instead? >>> > >>> > The RTL unroller is *the* unroller, and has been since forever. >>> > >>> > >>> > Segher
Re: drop -aux{dir,base}, revamp -dump{dir,base}
On May 19, 2020, Richard Biener wrote: > On Tue, 19 May 2020, Alexandre Oliva wrote: >> I've refreshed the patch, approved back on Jan 22 for gcc-11, in >> refs/users/aoliva/heads/aux-dump-revamp, and committed 3 other related >> patches on top of it, that I hope to get approved for folding and joint >> installation: > Thanks again for doing this. May I also suggest to prepare a short > entry for gcc-11/changes.html with these things (like "Output of > auxiliary files changed. See https://gcc.gnu.org/ml/gcc-patches/... > for details")? How about, under Caveats: * Naming and location of auxiliary and dump output files changed. If you compile multiple input files in a single command, if you enable Link Time Optimization, or if you use -dumpbase, -dumpdir, -save-temps=*, and you expect any file other than the primary output file(s) to be created as a side effect, watch out for improvements and a few surprises. See https://gcc.gnu.org/ml/... Before I can check it all in, I'm still missing a review of: https://gcc.gnu.org/pipermail/gcc-patches/2020-May/546015.html Did you by any chance miss it, or choose not to review it? Any takers? I've just realized I failed to mention I'd regstrapped the patchset on x86_64-linux-gnu, and got successful cross builds and regression test results for arm-elf, aarch64-elf, aarch64-vx7r2, and x86_64-windows. -- Alexandre Oliva, freedom fighterhe/himhttps://FSFLA.org/blogs/lxo/ Free Software Evangelist Stallman was right, but he's left :( GNU Toolchain Engineer Live long and free, and prosper ethically
RFC: Provide diagnostic hints for missing inttypes.h string constants.
This is on top of the stdbool.h and stdint.h patches.
This adds a flag to c_parser so we know when we were trying to
constract a string literal. If there is a parse error and we were
constructing a string literal, and the next token is an unknown
identifier name, and we know there is a standard header that defines
that name as a string literal, then add a missing header hint to
the error messsage.
I haven't checked yet if we can do something similar for the C++
parser. And the testcase needs to be extended a bit. But I hope the
direction is OK.
For the following source:
const char *hex64_fmt = PRIx64;
const char *msg_fmt = "Provide %" PRIx64 "\n";
void foo (uint32_t v)
{
printf ("%" PRIu32, v);
}
We will get the following:
$ /opt/local/gcc/bin/gcc -c t.c
t.c:4:26: error: ‘PRIx64’ undeclared here (not in a function)
4 | const char *hex64_fmt = PRIx64;
| ^~
t.c:3:1: note: ‘PRIx64’ is defined in header ‘’; did you forget to
‘#include ’?
2 | #include
+++ |+#include
3 |
t.c:5:35: error: expected ‘,’ or ‘;’ before ‘PRIx64’
5 | const char *msg_fmt = "Provide %" PRIx64 "\n";
| ^~
t.c:5:35: note: ‘PRIx64’ is defined in header ‘’; did you forget to
‘#include ’?
t.c: In function ‘foo’:
t.c:9:14: error: expected ‘)’ before ‘PRIu32’
9 | printf ("%" PRIu32, v);
| ^~~
| )
t.c:9:15: note: ‘PRIu32’ is defined in header ‘’; did you forget to
‘#include ’?
9 | printf ("%" PRIu32, v);
| ^~
---
gcc/c-family/known-headers.cc | 88 ++
gcc/c-family/known-headers.h | 2 +
gcc/c/c-parser.c | 29 +++
gcc/testsuite/gcc.dg/spellcheck-inttypes.c | 32
4 files changed, 151 insertions(+)
create mode 100644 gcc/testsuite/gcc.dg/spellcheck-inttypes.c
diff --git a/gcc/c-family/known-headers.cc b/gcc/c-family/known-headers.cc
index 1e2bf49c439a..b9772af21863 100644
--- a/gcc/c-family/known-headers.cc
+++ b/gcc/c-family/known-headers.cc
@@ -46,6 +46,71 @@ struct stdlib_hint
const char *header[NUM_STDLIBS];
};
+/* These can be used as string macros or as identifiers. Must all be
+ string-literals. Used in get_stdlib_header_for_name and
+ get_c_stdlib_header_for_string_macro_name. */
+static const stdlib_hint c99_cxx11_macro_hints[] = {
+/* and . */
+{"PRId8", {"", ""} },
+{"PRId16", {"", ""} },
+{"PRId32", {"", ""} },
+{"PRId64", {"", ""} },
+{"PRIi8", {"", ""} },
+{"PRIi16", {"", ""} },
+{"PRIi32", {"", ""} },
+{"PRIi64", {"", ""} },
+{"PRIo8", {"", ""} },
+{"PRIo16", {"", ""} },
+{"PRIo32", {"", ""} },
+{"PRIo64", {"", ""} },
+{"PRIu8", {"", ""} },
+{"PRIu16", {"", ""} },
+{"PRIu32", {"", ""} },
+{"PRIu64", {"", ""} },
+{"PRIx8", {"", ""} },
+{"PRIx16", {"", ""} },
+{"PRIx32", {"", ""} },
+{"PRIx64", {"", ""} },
+{"PRIX8", {"", ""} },
+{"PRIX16", {"", ""} },
+{"PRIX32", {"", ""} },
+{"PRIX64", {"", ""} },
+
+{"PRIdPTR", {"", ""} },
+{"PRIiPTR", {"", ""} },
+{"PRIoPTR", {"", ""} },
+{"PRIuPTR", {"", ""} },
+{"PRIxPTR", {"", ""} },
+{"PRIXPTR", {"", ""} },
+
+{"SCNd8", {"", ""} },
+{"SCNd16", {"", ""} },
+{"SCNd32", {"", ""} },
+{"SCNd64", {"", ""} },
+{"SCNi8", {"", ""} },
+{"SCNi16", {"", ""} },
+{"SCNi32", {"", ""} },
+{"SCNi64", {"", ""} },
+{"SCNo8", {"", ""} },
+{"SCNo16", {"", ""} },
+{"SCNo32", {"", ""} },
+{"SCNo64", {"", ""} },
+{"SCNu8", {"", ""} },
+{"SCNu16", {"", ""} },
+{"SCNu32", {"", ""} },
+{"SCNu64", {"", ""} },
+{"SCNx8", {"", ""} },
+{"SCNx16", {"", ""} },
+{"SCNx32", {"", ""} },
+{"SCNx64", {"", ""} },
+
+{"SCNdPTR", {"", ""} },
+{"SCNiPTR", {"", ""} },
+{"SCNoPTR", {"", ""} },
+{"SCNuPTR", {"", ""} },
+{"SCNxPTR", {"", ""} }
+};
+
/* Given non-NULL NAME, return the header name defining it within either
the standard library (with '<' and '>'), or NULL.
Only handles a subset of the most common names within the stdlibs. */
@@ -196,6 +261,14 @@ get_stdlib_header_for_name (const char *name, enum stdlib
lib)
if (strcmp (name, c99_cxx11_hints[i].name) == 0)
return c99_cxx11_hints[i].header[lib];
+ const size_t num_c99_cxx11_macro_hints
+= sizeof (c99_cxx11_macro_hints) / sizeof (c99_cxx11_macro_hints[0]);
+ if ((lib == STDLIB_C && flag_isoc99)
+ || (lib == STDLIB_CPLUSPLUS && cxx_dialect >= cxx11 ))
+for (size_t i = 0; i < num_c99_cxx11_macro_hints; i++)
+ if (strcmp (name, c99_cxx11_macro_hints[i].name) == 0)
+ return c99_cxx11_macro_hints[i].header[lib];
+
return NULL;
}
@@ -217,6 +290,21 @@ get_cp_stdlib_header_for_name (const char *name)
return get_stdlib_header_for_name (name, STDLIB_CPLUSPLUS);
}
+/* Given non-NULL NAME, return the header name
Re: [PATCH] gcc/Makefile.in: move SELFTEST_DEPS before including language makefile fragments
On Thu, 2020-05-21 at 17:35 +0200, Romain Naour wrote: > As reported by several Buildroot users [1][2][3], the gcc build > may fail while running selftests makefile target. > > The problem only occurs when ccache is used with gcc 9 and 10, > probably due to a race condition. > > While debuging with "make -p" we can notice that s-selftest-c target > contain only "cc1" as dependency instead of cc1 and SELFTEST_DEPS > [4]. > > s-selftest-c: cc1 > > While the build is failing, the s-selftest-c dependencies recipe is > still running and reported as a bug by make. > > "Dependencies recipe running (THIS IS A BUG)." > > A change [5] in gcc 9 seems to introduce the problem since we can't > reproduce this problem with gcc 8. Sorry about introducing the breakage. The patch looks sane to me, though I don't know if I can formally approve it (and I'm now doubting my "make" skills...) Dave
Re: ChangeLog files - server and client scripts
On Tue, May 19, 2020 at 2:26 AM Martin Liška wrote: > > We've just installed server git hooks that verify git messages > for a correct ChangeLog format. For a limited time period, please > still apply ChangeLog changes to the corresponding ChangeLog files. > We'll use it for comparison of auto-generated CangeLog entries. > > The format is documented here: > https://gcc.gnu.org/codingconventions.html#ChangeLogs > > And I would recommend to install the new 'git gcc-verify' hook from: > contrib/gcc-git-customization.sh > > Feel free to contact me about future troubles you'll see. Hi, this unfortunately breaks gccgo development. Significant parts of the gccgo sources are simply copied from other repositories. Those other repositories do not use ChangeLog files. The git commit hook should not require ChangeLog files for those changes. And, when the time comes, no ChangeLog files should be created for changes in those directories. The directories in question are gcc/go/gofrontend libgo gcc/testsuite/go.test/test This is as documented in the README.gcc files in those directories. How can I exempt those directories from the server hook? Right now, as far as I can tell, I cannot commit Go changes. I get remote: *** ChangeLog format failed: remote: ERR: cannot find a ChangeLog location in message remote: remote: Please see: https://gcc.gnu.org/codingconventions.html#ChangeLogs remote: remote: error: hook declined to update refs/heads/master To git+ssh://gcc.gnu.org/git/gcc ! [remote rejected] master -> master (hook declined) error: failed to push some refs to 'git+ssh://gcc.gnu.org/git/gcc' Thanks. Ian
Re: New mklog script
On Fri, May 15, 2020 at 11:39 AM Martin Liška wrote:
>
> On 5/15/20 3:22 PM, Marek Polacek wrote:
> > On Fri, May 15, 2020 at 03:12:27PM +0200, Martin Liška wrote:
> >> On 5/15/20 2:42 PM, Marek Polacek wrote:
> >>> I actually use mklog -i all the time. But I can work around it if it
> >>> disappears.
> >>
> >> Ah, I can see a consumer.
> >> There's an updated version that supports that.
> >>
> >> For the future, will you still use the option? Wouldn't be better
> >> to put the ChangeLog content directly to commit message? Note
> >> that you won't have to copy the entries to a particular ChangeLog file.
> >
> > The way I do it is to generate a patch using format-patch, use mklog -i
> > on it, then add the ChangeLog entry to the commit message via commit
> > --amend.
>
> Hmm, you can do much better with:
>
> $ git diff | ./contrib/mklog > changelog && git commit -a -t changelog
>
> Or for an already created commit you can do:
>
> $ git diff HEAD~ | ./contrib/mklog > changelog && git commit -a --amend -e -F
> changelog
With these git aliases:
mklog-editor = "!f() { git show | git gcc-mklog >> $1; }; f"
addlog = "!f() { GIT_EDITOR='git mklog-editor' git commit --amend; }; f"
I can 'git addlog' to append the output of mklog to the current
commit. Probably better would be to do something with
prepare-commit-msg.
Jason
Re: ChangeLog files - server and client scripts
On 5/21/20 11:01 PM, Jason Merrill wrote: Why? What is the use of requiring ChangeLog entries at all for these changes? I must confirm a common test-suite ChangeLog entry is something like: $ grep ':' gcc/testsuite/ChangeLog | sed 's/.*://' | sort | uniq -c | sort -n | tac | head -n 15 6309 Likewise. 1306 New test. 231 New. 68 New testcase. 55 54 Ditto. 47 New file. 33 Same. 27 Move into ... 24 New tests. 21 Add typedef for int32_t. 19 This. Clean up 17 Rename to... 16 This. 12 ...this. $ grep ':' gcc/testsuite/ChangeLog-2019 | sed 's/.*://' | sort | uniq -c | sort -n | tac | head -n 15 2981 Likewise. 2287 New test. 399 New testcase. 263 Same. 263 New. 217 Ditto. 111 Adjust. 88 New file. 62 32 Require exceptions. 30 Remove. 25 New 20 Update test. 17 New tests. 15 Add $ grep ':' gcc/testsuite/ChangeLog-2018 | sed 's/.*://' | sort | uniq -c | sort -n | tac | head -n 15 5071 Likewise. 2071 New test. 443 New. 413 New testcase. 395 Remove. 256 Ditto. 224 Same. 108 New file. 66 Likwise. 65 Adjust. 53 52 Dito. 39 Add -flinker-output=nolto-rel. 32 New test case. 26 Delete testcase. So I'm open for relaxation of the rule. What about the others? Martin
Re: ChangeLog files - server and client scripts
On Thu, May 21, 2020 at 4:27 PM Martin Liška wrote: > On 5/21/20 9:51 PM, Jason Merrill wrote: > > Modified. Adjustments to expected errors in testcases don't seem to me > worth documenting in a ChangeLog. > > I see. As Jakub mentioned, I would keep the hook stricter for now. > Why? What is the use of requiring ChangeLog entries at all for these changes? Jason
Re: ChangeLog files - server and client scripts
On 5/21/20 9:51 PM, Jason Merrill wrote: Modified. Adjustments to expected errors in testcases don't seem to me worth documenting in a ChangeLog. I see. As Jakub mentioned, I would keep the hook stricter for now. Martin
Re: [stage1][PATCH] Lower VEC_COND_EXPR into internal functions.
Hi!
On Thu, May 21, 2020 at 03:29:49PM +0200, Martin Liška wrote:
> Adding Segher to CC, he can help us.
Oh dear. Are you sure?
> On 5/21/20 2:51 PM, Martin Liška wrote:
> >Back to this I noticed that ppc64le target build is broken due to:
> >insn-emit.o -MMD -MP -MF ./.deps/insn-emit.TPo insn-emit.c
> >/home/marxin/Programming/gcc/gcc/config/rs6000/vector.md:357:11: error:
> >vcondv4sfv4sf cannot FAIL
> > 357 | FAIL;
Is it new that vcond cannot FAIL? Because we have done that for years.
Since this breaks bootstrap on a primary target, please revert the patch
until it is sorted.
> >which is caused by the 4 added optabs:
> >
> >+DEF_INTERNAL_OPTAB_FN (VCOND, 0, vcond, vec_cond)
> >+DEF_INTERNAL_OPTAB_FN (VCONDU, 0, vcondu, vec_condu)
> >+DEF_INTERNAL_OPTAB_FN (VCONDEQ, 0, vcondeq, vec_condeq)
> >+DEF_INTERNAL_OPTAB_FN (VCOND_MASK, 0, vcond_mask, vec_cond_mask)
> >looking at the generator:
> >I get there due to:
> >
> >B- │516 if (find_optab (, XSTR (expand,
> >0)))│
> > │517
> > { │
> > │518 gcc_assert (p.op <
> > NUM_OPTABS); │
> > │519 if
> > (nofail_optabs[p.op]) │
> > │520 can_fail_p =
> > false; │
> > │521
> > } │
> >
> >
> >#define DEF_INTERNAL_OPTAB_FN(NAME, FLAGS, OPTAB, TYPE) \
> > nofail_optabs[OPTAB##_optab] = true;
So yes it is new. Please fix :-(
> >Any hint what's bad? Note that x86_64-linux-gnu is fine.
> >Do I miss a target hook?
There is a new IFN that requires the existing optabs to never fail. But
they *do* sometimes fail. That is what I understand from this anyway,
please correct if needed :-)
We can make the rs6000 patterns never FAIL if that is a good idea (I am
not convinced however), but this should be documented, and all existing
targets need to be checked.
In general it is not pleasant at all to have patterns that cannot FAIL,
it makes writing a (new) port much harder, and there can be cases where
there is no sane code at all that can be generated for some cases, etc.
Segher
Re: ChangeLog files - server and client scripts
On Thu, May 21, 2020 at 2:58 PM Martin Liška wrote:
> On 5/21/20 8:52 PM, Jason Merrill wrote:
> > Was there a decision somewhere to require ChangeLog entries for all
> testcase changes now, as the hook is enforcing? They were optional before.
>
> Right now we ignore newly added test-case, these don't have to be
> mentioned.
> Can you please attach the patch (git format-patch)?
>
> Are you talking about modified or delete test-cases? If so, we can
> definitely
> relax the rules..
>
Modified. Adjustments to expected errors in testcases don't seem to me
worth documenting in a ChangeLog.
From c5a15303c57171b5b284b7a8ec0eb97f991779d6 Mon Sep 17 00:00:00 2001
From: Jason Merrill
Date: Thu, 21 May 2020 10:27:11 -0400
Subject: [PATCH 1/4] c++: Improve error-recovery for parms.
To: gcc-patches@gcc.gnu.org
If a parameter is erroneous, we currently drop it, leading to "too many
arguments" errors later. Treating the function as (...) avoids those
errors.
gcc/cp/ChangeLog
2020-05-21 Jason Merrill
* decl.c (grokparms): Return NULL_TREE if any parms were erroneous.
---
gcc/cp/decl.c| 18 +-
gcc/testsuite/g++.dg/parse/error33.C | 4 ++--
2 files changed, 15 insertions(+), 7 deletions(-)
diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
index 024ddc88a4c..a389579ee52 100644
--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -13961,7 +13961,10 @@ grokparms (tree parmlist, tree *parms)
break;
if (! decl || TREE_TYPE (decl) == error_mark_node)
- continue;
+ {
+ any_error = 1;
+ continue;
+ }
type = TREE_TYPE (decl);
if (VOID_TYPE_P (type))
@@ -14014,7 +14017,8 @@ grokparms (tree parmlist, tree *parms)
TREE_TYPE (decl) = type;
}
else if (abstract_virtuals_error (decl, type))
- any_error = 1; /* Seems like a good idea. */
+ /* Ignore any default argument. */
+ init = NULL_TREE;
else if (cxx_dialect < cxx17 && INDIRECT_TYPE_P (type))
{
/* Before C++17 DR 393:
@@ -14043,9 +14047,7 @@ grokparms (tree parmlist, tree *parms)
decl, t);
}
- if (any_error)
- init = NULL_TREE;
- else if (init && !processing_template_decl)
+ if (init && !processing_template_decl)
init = check_default_argument (decl, init, tf_warning_or_error);
}
@@ -14058,6 +14060,12 @@ grokparms (tree parmlist, tree *parms)
if (parm)
result = chainon (result, void_list_node);
*parms = decls;
+ if (any_error)
+result = NULL_TREE;
+
+ if (any_error)
+/* We had parm errors, recover by giving the function (...) type. */
+result = NULL_TREE;
return result;
}
diff --git a/gcc/testsuite/g++.dg/parse/error33.C b/gcc/testsuite/g++.dg/parse/error33.C
index 0d25386a879..61b0cc3f2dc 100644
--- a/gcc/testsuite/g++.dg/parse/error33.C
+++ b/gcc/testsuite/g++.dg/parse/error33.C
@@ -8,9 +8,9 @@ struct A
typedef void (A::T)(); /* { dg-error "15:typedef name may not be a nested" } */
-void bar(T); /* { dg-message "note: declared here" } */
+void bar(T);
void baz()
{
- bar(::foo); /* { dg-error "too many arguments" } */
+ bar(::foo);
}
--
2.18.1
[pushed] coroutines: Partial reversion of r11-437-g5ef067eb14d4.
Hi I got a bit over-zealous in the attempt to make better use of the higher- level APIs in the c++ FE, this reverts that part of the change, Tested on x86_64-darwin, applied to master, thanks Iain co_returns are statements, not expressions; they do not need to be wrapped in an EXPR_STMT. gcc/cp/ChangeLog: * coroutines.cc (finish_co_return_stmt): Revert change to use finish_expr_stmt. --- gcc/cp/coroutines.cc | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/gcc/cp/coroutines.cc b/gcc/cp/coroutines.cc index 4cbc0e09994..b79e2c66b70 100644 --- a/gcc/cp/coroutines.cc +++ b/gcc/cp/coroutines.cc @@ -1102,7 +1102,8 @@ finish_co_return_stmt (location_t kw, tree expr) " % statement"); expr = build2_loc (kw, CO_RETURN_EXPR, void_type_node, expr, co_ret_call); - return finish_expr_stmt (expr); + expr = maybe_cleanup_point_expr_void (expr); + return add_stmt (expr); } /* We need to validate the arguments to __builtin_coro_promise, since the -- 2.24.1
Re: ChangeLog files - server and client scripts
On 5/21/20 8:52 PM, Jason Merrill wrote: Was there a decision somewhere to require ChangeLog entries for all testcase changes now, as the hook is enforcing? They were optional before. Right now we ignore newly added test-case, these don't have to be mentioned. Can you please attach the patch (git format-patch)? Are you talking about modified or delete test-cases? If so, we can definitely relax the rules.. Martin
Re: ChangeLog files - server and client scripts
On Thu, May 21, 2020 at 02:52:37PM -0400, Jason Merrill wrote: > Was there a decision somewhere to require ChangeLog entries for all > testcase changes now, as the hook is enforcing? They were optional before. > > remote: *** ChangeLog format failed: > remote: ERR: changed file not mentioned in a > ChangeLog:"gcc/testsuite/g++.dg/parse/error33.C" They are optional for newly added testcases (even other new files); for that it will add : New test. or something similar, Martin knows the details. But right now they are not optional if an existing file is modified, because in that case no script can (easily) find out what to say about it, : Some change. would be too useless/fuzzy. Jakub
Re: ChangeLog files - server and client scripts
Was there a decision somewhere to require ChangeLog entries for all testcase changes now, as the hook is enforcing? They were optional before. remote: *** ChangeLog format failed: remote: ERR: changed file not mentioned in a ChangeLog:"gcc/testsuite/g++.dg/parse/error33.C" On Thu, May 21, 2020 at 11:38 AM Rainer Orth wrote: > Hi Martin, > > >> two comments: > >> > >> * Can you please avoid the use grey highlighting in that section? Black > >>script on a grey background is already hard to read for someone with > >>reasonable vision. I suspect it will be much harder for > >>vision-impaired people. > > > > You are right, I fixed that. > > thanks. > > >> * In changelog_location, you allow only (among others) "a/b/c/" and > >>"\ta/b/c/". Please also accept the "a/b/c:" and "\ta/b/c:" forms > >>here: especially the second seems quite common. > > > > Sure, can you please link some git revisions that use the format? > > Apart from using it myself ;-), I've seen it several times, but no > examples off-hand. However, it seems only consistent with the forms > ending in /ChangeLog where you allow the trailing colon, too. > > Rainer > > -- > > - > Rainer Orth, Center for Biotechnology, Bielefeld University > >
[pushed] c++: Check constant array bounds later.
We give a better diagnostic for non-constant array bounds in
compute_array_index_type_loc, we don't need to diagnose it in the parser.
But to avoid a regression on parse/varmod1.C we need to actually check
non-dependent expressions in a template.
Tested x86_64-pc-linux-gnu, applying to trunk.
gcc/cp/ChangeLog
2020-05-21 Jason Merrill
* decl.c (compute_array_index_type_loc): Diagnose expressions
in a template that can't be constant.
* parser.c (cp_parser_direct_declarator): Don't check
non-constant array bounds here.
---
gcc/cp/decl.c | 12 ++--
gcc/cp/parser.c | 2 ++
gcc/testsuite/c-c++-common/gomp/depend-iterator-2.c | 2 +-
gcc/testsuite/g++.dg/ext/vla1.C | 3 +--
gcc/testsuite/g++.dg/template/array9.C | 4 ++--
gcc/testsuite/g++.dg/template/error41.C | 2 +-
6 files changed, 13 insertions(+), 12 deletions(-)
diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
index 6d1c08e064a..2e1390837e8 100644
--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -10328,13 +10328,14 @@ compute_array_index_type_loc (location_t name_loc,
tree name, tree size,
dependent type or whose size is specified by a constant expression
that is value-dependent. */
/* We can only call value_dependent_expression_p on integral constant
- expressions; treat non-constant expressions as dependent, too. */
+ expressions. */
if (processing_template_decl
- && (!TREE_CONSTANT (size) || value_dependent_expression_p (size)))
+ && potential_constant_expression (size)
+ && value_dependent_expression_p (size))
{
- /* We cannot do any checking for a SIZE that isn't known to be
-constant. Just build the index type and mark that it requires
+ /* Just build the index type and mark that it requires
structural equality checks. */
+in_template:
itype = build_index_type (build_min (MINUS_EXPR, sizetype,
size, size_one_node));
TYPE_DEPENDENT_P (itype) = 1;
@@ -10447,8 +10448,7 @@ compute_array_index_type_loc (location_t name_loc, tree
name, tree size,
}
if (processing_template_decl && !TREE_CONSTANT (size))
-/* A variable sized array. */
-itype = build_min (MINUS_EXPR, sizetype, size, integer_one_node);
+goto in_template;
else
{
if (!TREE_CONSTANT (size))
diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index 6a0ef4d76ee..54ca875ce54 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -21366,6 +21366,8 @@ cp_parser_direct_declarator (cp_parser* parser,
/* OK */;
else if (error_operand_p (bounds))
/* Already gave an error. */;
+ else if (!cp_parser_uncommitted_to_tentative_parse_p (parser))
+ /* Let compute_array_index_type diagnose this. */;
else if (!parser->in_function_body
|| current_binding_level->kind == sk_function_parms)
{
diff --git a/gcc/testsuite/c-c++-common/gomp/depend-iterator-2.c
b/gcc/testsuite/c-c++-common/gomp/depend-iterator-2.c
index 127528271ee..fff32a4761f 100644
--- a/gcc/testsuite/c-c++-common/gomp/depend-iterator-2.c
+++ b/gcc/testsuite/c-c++-common/gomp/depend-iterator-2.c
@@ -41,7 +41,7 @@ f1 (void)
;
#pragma omp task depend (iterator (int i = 0:4, \
struct U { int (*p)[i + 2]; } *p = 0:2) ,
in : a) /* { dg-error "type of iterator 'p' refers to outer iterator 'i'" "" {
target c } } */
- ;/* {
dg-error "types may not be defined in iterator type|not an integer constant" ""
{ target c++ } .-1 } */
+ ;/* {
dg-error "types may not be defined in iterator type|not an integral constant"
"" { target c++ } .-1 } */
#pragma omp task depend (iterator (i = 0:4, j = i:16) , in : a) /* {
dg-error "begin expression refers to outer iterator 'i'" } */
;
#pragma omp task depend (iterator (i = 0:4, j = 2:i:1) , in : a) /* {
dg-error "end expression refers to outer iterator 'i'" } */
diff --git a/gcc/testsuite/g++.dg/ext/vla1.C b/gcc/testsuite/g++.dg/ext/vla1.C
index c017b6e90ed..cae3f82135a 100644
--- a/gcc/testsuite/g++.dg/ext/vla1.C
+++ b/gcc/testsuite/g++.dg/ext/vla1.C
@@ -19,8 +19,7 @@ class B { B (int); };
B::B (int i)
{
struct S {
-int ar[1][i]; // { dg-error "15:size of array .ar. is not an integral" ""
{ target c++11 } }
-// { dg-error "array bound" "" { target c++98_only } .-1 }
+int ar[1][i]; // { dg-error "15:size of array .ar. is not an integral" }
} s;
s.ar[0][0] = 0; // { dg-prune-output "no member" }
diff --git a/gcc/testsuite/g++.dg/template/array9.C
b/gcc/testsuite/g++.dg/template/array9.C
index f3e8335c943..ce9fb649d3a 100644
---
[pushed] c++: Improve error recovery for =.
In a template we were happily embedding error_mark_node in a MODOP_EXPR,
leading to confusion later.
Tested x86_64-pc-linux-gnu, applying to trunk.
gcc/cp/ChangeLog
2020-05-21 Jason Merrill
* typeck.c (build_x_modify_expr): Handle error_mark_node arguments.
---
gcc/cp/typeck.c | 3 +++
gcc/testsuite/g++.dg/cpp0x/lambda/lambda-ice30.C | 4 ++--
gcc/testsuite/g++.dg/cpp0x/lambda/lambda-ice31.C | 2 +-
gcc/testsuite/g++.dg/ext/fixed1.C| 2 ++
gcc/testsuite/g++.dg/template/crash107.C | 4 ++--
gcc/testsuite/g++.dg/template/error35.C | 2 +-
gcc/testsuite/g++.dg/template/sizeof-template-argument.C | 4 ++--
7 files changed, 13 insertions(+), 8 deletions(-)
diff --git a/gcc/cp/typeck.c b/gcc/cp/typeck.c
index 0181984bb99..f01ae656254 100644
--- a/gcc/cp/typeck.c
+++ b/gcc/cp/typeck.c
@@ -8768,6 +8768,9 @@ build_x_modify_expr (location_t loc, tree lhs, enum
tree_code modifycode,
tree overload = NULL_TREE;
tree op = build_nt (modifycode, NULL_TREE, NULL_TREE);
+ if (lhs == error_mark_node || rhs == error_mark_node)
+return cp_expr (error_mark_node, loc);
+
if (processing_template_decl)
{
if (modifycode == NOP_EXPR
diff --git a/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-ice30.C
b/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-ice30.C
index 46350bd1d52..7b0a155a31a 100644
--- a/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-ice30.C
+++ b/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-ice30.C
@@ -3,11 +3,11 @@
template void foo()
{
- int x[=]; // { dg-error "expected" }
+ int x[=]; // { dg-error "" }
[]{};
}
void bar()
{
- foo<0>();
+ foo<0>();// { dg-prune-output "not declared" }
}
diff --git a/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-ice31.C
b/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-ice31.C
index 54ded7bb282..f0ecf8cc26f 100644
--- a/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-ice31.C
+++ b/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-ice31.C
@@ -4,5 +4,5 @@
template void foo()
{
T x[=]; // { dg-error "expected" }
- []{};
+ []{}; // { dg-prune-output "not declared" }
}
diff --git a/gcc/testsuite/g++.dg/ext/fixed1.C
b/gcc/testsuite/g++.dg/ext/fixed1.C
index 5a479d6891a..92e3184ea59 100644
--- a/gcc/testsuite/g++.dg/ext/fixed1.C
+++ b/gcc/testsuite/g++.dg/ext/fixed1.C
@@ -6,3 +6,5 @@ template struct A {};
template struct B : A {}; // { dg-error "not
supported" }
template struct C : A {}; // { dg-error "not
supported" }
+
+// { dg-prune-output "template argument" }
diff --git a/gcc/testsuite/g++.dg/template/crash107.C
b/gcc/testsuite/g++.dg/template/crash107.C
index 932a3a68059..aab882d8446 100644
--- a/gcc/testsuite/g++.dg/template/crash107.C
+++ b/gcc/testsuite/g++.dg/template/crash107.C
@@ -10,9 +10,9 @@ template struct Vec { // { dg-message "note" ""
{ target c++17_dow
X = y*rhs.z() - z*rhs.y(); // { dg-error "not declared|no member" }
}
Vec& operator^(Vec& rhs) {
-return Vec(*this)^=rhs; // { dg-message "required" }
+return Vec(*this)^=rhs;
}
};
Vec v(3,4,12); // { dg-error "no matching|too many initializers" }
Vec V(12,4,3); // { dg-error "no matching|too many initializers" }
-Vec c = v^V; // { dg-message "required" }
+Vec c = v^V;
diff --git a/gcc/testsuite/g++.dg/template/error35.C
b/gcc/testsuite/g++.dg/template/error35.C
index d52e599315e..0ba8635507b 100644
--- a/gcc/testsuite/g++.dg/template/error35.C
+++ b/gcc/testsuite/g++.dg/template/error35.C
@@ -1,3 +1,3 @@
// PR c++/33494
-template void foo(int(*f=0)()); // { dg-error "declared
void|scope|erroneous-expression" }
+template void foo(int(*f=0)()); // { dg-error "declared void|scope|cannot
be used as a function" }
diff --git a/gcc/testsuite/g++.dg/template/sizeof-template-argument.C
b/gcc/testsuite/g++.dg/template/sizeof-template-argument.C
index 2bfff6d9a18..b5e12d699ae 100644
--- a/gcc/testsuite/g++.dg/template/sizeof-template-argument.C
+++ b/gcc/testsuite/g++.dg/template/sizeof-template-argument.C
@@ -3,9 +3,9 @@
template struct A {};
-template struct B : A {}; /* { dg-error "expected
primary-expression" } */
+template struct B : A {}; /* { dg-error "" } */
-template struct C : A {}; /* { dg-error "expected
primary-expression" } */
+template struct C : A {}; /* { dg-error "" } */
int a;
base-commit: 149c8c7c27a17a2941d07e2f76b1e1c823e2fa80
--
2.18.1
[pushed] c++: Constant expression parsing and parameters.
The difference between a "potential" constant-expression and a regular
constant-expression is the treatment of parameters; in a constexpr function,
a parameter is potentially constant when evaluating a call to that function,
but it is not constant during parsing of the function.
cp_parser_constant_expression should check the latter rather than the
former.
Tested x86_64-pc-linux-gnu, applying to trunk.
gcc/cp/ChangeLog
2020-05-21 Jason Merrill
* constexpr.c (is_rvalue_constant_expression): New.
* parser.c (cp_parser_constant_expression): Use it.
* decl.c (cp_finish_decl): Try to treat a constexpr initializer in a
template as constant.
---
gcc/cp/cp-tree.h | 1 +
gcc/cp/constexpr.c | 8
gcc/cp/decl.c | 2 +-
gcc/cp/parser.c| 4 ++--
4 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
index 07c16144c98..db125a3a1db 100644
--- a/gcc/cp/cp-tree.h
+++ b/gcc/cp/cp-tree.h
@@ -7939,6 +7939,7 @@ extern tree constexpr_fn_retval (tree);
extern tree ensure_literal_type_for_constexpr_object (tree);
extern bool potential_constant_expression (tree);
extern bool is_constant_expression (tree);
+extern bool is_rvalue_constant_expression (tree);
extern bool is_nondependent_constant_expression (tree);
extern bool is_nondependent_static_init_expression (tree);
extern bool is_static_init_expression(tree);
diff --git a/gcc/cp/constexpr.c b/gcc/cp/constexpr.c
index c1ab9288f72..98c974e657f 100644
--- a/gcc/cp/constexpr.c
+++ b/gcc/cp/constexpr.c
@@ -8359,6 +8359,14 @@ is_constant_expression (tree t)
return potential_constant_expression_1 (t, false, true, true, tf_none);
}
+/* As above, but expect an rvalue. */
+
+bool
+is_rvalue_constant_expression (tree t)
+{
+ return potential_constant_expression_1 (t, true, true, true, tf_none);
+}
+
/* Like above, but complain about non-constant expressions. */
bool
diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
index a389579ee52..6d1c08e064a 100644
--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -7612,7 +7612,7 @@ cp_finish_decl (tree decl, tree init, bool
init_const_expr_p,
init = boolean_true_node;
}
else if (init
- && init_const_expr_p
+ && (init_const_expr_p || DECL_DECLARED_CONSTEXPR_P (decl))
&& !TYPE_REF_P (type)
&& decl_maybe_constant_var_p (decl)
&& !(dep_init = value_dependent_init_p (init)))
diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index a8082d39aca..6a0ef4d76ee 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -10184,10 +10184,10 @@ cp_parser_constant_expression (cp_parser* parser,
if (TREE_TYPE (expression)
&& TREE_CODE (TREE_TYPE (expression)) == ARRAY_TYPE)
decay = build_address (expression);
- bool is_const = potential_rvalue_constant_expression (decay);
+ bool is_const = is_rvalue_constant_expression (decay);
parser->non_integral_constant_expression_p = !is_const;
if (!is_const && !allow_non_constant_p)
- require_potential_rvalue_constant_expression (decay);
+ require_rvalue_constant_expression (decay);
}
if (allow_non_constant_p)
*non_constant_p = parser->non_integral_constant_expression_p;
base-commit: 149c8c7c27a17a2941d07e2f76b1e1c823e2fa80
--
2.18.1
[pushed] c++: Improve error-recovery for parms.
If a parameter is erroneous, we currently drop it, leading to "too many
arguments" errors later. Treating the function as (...) avoids those
errors.
Tested x86_64-pc-linux-gnu, applying to trunk.
gcc/cp/ChangeLog
2020-05-21 Jason Merrill
* decl.c (grokparms): Return NULL_TREE if any parms were erroneous.
---
gcc/cp/decl.c| 18 +-
gcc/testsuite/g++.dg/parse/error33.C | 4 ++--
2 files changed, 15 insertions(+), 7 deletions(-)
diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
index 024ddc88a4c..a389579ee52 100644
--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -13961,7 +13961,10 @@ grokparms (tree parmlist, tree *parms)
break;
if (! decl || TREE_TYPE (decl) == error_mark_node)
- continue;
+ {
+ any_error = 1;
+ continue;
+ }
type = TREE_TYPE (decl);
if (VOID_TYPE_P (type))
@@ -14014,7 +14017,8 @@ grokparms (tree parmlist, tree *parms)
TREE_TYPE (decl) = type;
}
else if (abstract_virtuals_error (decl, type))
- any_error = 1; /* Seems like a good idea. */
+ /* Ignore any default argument. */
+ init = NULL_TREE;
else if (cxx_dialect < cxx17 && INDIRECT_TYPE_P (type))
{
/* Before C++17 DR 393:
@@ -14043,9 +14047,7 @@ grokparms (tree parmlist, tree *parms)
decl, t);
}
- if (any_error)
- init = NULL_TREE;
- else if (init && !processing_template_decl)
+ if (init && !processing_template_decl)
init = check_default_argument (decl, init, tf_warning_or_error);
}
@@ -14058,6 +14060,12 @@ grokparms (tree parmlist, tree *parms)
if (parm)
result = chainon (result, void_list_node);
*parms = decls;
+ if (any_error)
+result = NULL_TREE;
+
+ if (any_error)
+/* We had parm errors, recover by giving the function (...) type. */
+result = NULL_TREE;
return result;
}
diff --git a/gcc/testsuite/g++.dg/parse/error33.C
b/gcc/testsuite/g++.dg/parse/error33.C
index 0d25386a879..61b0cc3f2dc 100644
--- a/gcc/testsuite/g++.dg/parse/error33.C
+++ b/gcc/testsuite/g++.dg/parse/error33.C
@@ -8,9 +8,9 @@ struct A
typedef void (A::T)(); /* { dg-error "15:typedef name may not be a nested" } */
-void bar(T); /* { dg-message "note: declared here" } */
+void bar(T);
void baz()
{
- bar(::foo); /* { dg-error "too many arguments" } */
+ bar(::foo);
}
base-commit: 149c8c7c27a17a2941d07e2f76b1e1c823e2fa80
--
2.18.1
Re: [PATCH] Fix handling of OPT_mgeneral_regs_only in attribute.
Ah, you are right. Please forget about this patch mgeneral-regs-only Target Report RejectNegative Mask(GENERAL_REGS_ONLY) Save also contains the RejectNegative keyword. Martin
Re: [PATCH] gcc/Makefile.in: move SELFTEST_DEPS before including language makefile fragments
On Thu, 2020-05-21 at 19:31 +0200, Richard Biener via Gcc-patches wrote: > On May 21, 2020 5:35:19 PM GMT+02:00, Romain Naour via Gcc-patches < > gcc-patches@gcc.gnu.org> wrote: > > As reported by several Buildroot users [1][2][3], the gcc build > > may fail while running selftests makefile target. > > > > The problem only occurs when ccache is used with gcc 9 and 10, > > probably due to a race condition. > > Just as a note since a while I am regularly running into (the same?) issue > when > bootstrapping that xgcc is not yet built when self tests want to run and I > stumbled across the very same dependency line. My tester trips it once in a while too, so a big thanks to Romain for digging into it. It's definitely in my queue of things to review. jeff >
V2 [PATCH] x86: Move cpuinfo.h from libgcc to common/config/i386
On Wed, May 20, 2020 at 4:21 AM H.J. Lu wrote: > > On Tue, May 19, 2020 at 11:10 PM Uros Bizjak wrote: > > > > On Tue, May 19, 2020 at 11:40 PM H.J. Lu wrote: > > > > > > > > > > > > I will take a look to see if we share the same CPU > > > > > > > > > > detection code between > > > > > > > > > > libgcc and config/i386/driver-i386.c. > > > > > > > > > > > > > > > > > > I don't think it will bring any benefit, this is mainly one > > > > > > > > > huge > > > > > > > > > switch statement that maps to different stuff in libgcc and > > > > > > > > > driver-i386. > > > > > > > > > > > > > > > > libgcc and config/i386/driver-i386.c differ even before my > > > > > > > > patch. > > > > > > > > I think we can do better. > > > > > > > > > > > > > > > > > > > > > > Move cpuinfo.h from libgcc to common/config/i386 so that > > > > > > > get_intel_cpu > > > > > > > can be shared by libgcc, GCC driver, > > > > > > > gcc.target/i386/builtin_target.c > > > > > > > and libgfortran to detect the specific type of Intel CPU. Update > > > > > > > libgfortran to use has_cpu_feature to detect x86 CPU features. > > > > > > > > > > > > > > Tested on Linux/x86 and Linux/x86-64. OK for master? > > > > > > > > > > > > Handling only Intel targets and not others is a sure way for patch > > > > > > to > > > > > > be ignored. > > > > > > > > > > > > > > > > Here is the updated patch to cover AMD CPU. It also fixes: > > > > > > > > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95212 > > > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95220 > > > > > > > > > > OK for master? > > > > > > > > Huh... I didn't think the solution will be this messy... I have to > > > > rethink the approach a bit. > > > > > > That is what will happen when we have the same info in more than one place > > > There should only one place for CPU info. > > > > Looking at the patch, it is clear that cpuinfo.c and driver-i386.c > > should stay apart. They are two different things, and they are > > orthogonal to each other; one can be updated without affecting the > > other one. driver-i386.c handles way more targets than cpuinfo.c and > > your patch only handles a subset of them. The unification does not > > bring any benefit, it even complicates things more. > > There should one place to check a CPU feature, not 2. It can > be done with a proper cpuinfo.h. > This updated patch does it. It removes duplicated codes and simplifies the implementation. With this patch, we just to update a single place to add the new ISA support. -- H.J. From 719fe259432fdea0b2880a92549934e6c5dcca24 Mon Sep 17 00:00:00 2001 From: "H.J. Lu" Date: Mon, 18 May 2020 05:58:41 -0700 Subject: [PATCH] x86: Move cpuinfo.h from libgcc to common/config/i386 Move cpuinfo.h from libgcc to common/config/i386 so that get_intel_cpu can be shared by libgcc, GCC driver and gcc.target/i386/builtin_target.c to detect the specific type of Intel and AMD CPUs: 1. Use the same enum processor_features in libgcc and x86 backend. 2. Add more processor features to enum processor_features. 3. Add M_VENDOR, M_CPU_TYPE and M_CPU_SUBTYPE in i386-builtins.c to avoid duplication in. 4. Use cpu_indicator_init, has_cpu_feature, get_amd_cpu and get_intel_cpu in driver-i386.c and builtin_target.c. gcc/ PR target/95259 * common/config/i386/cpuinfo.h: Moved from libgcc/config/i386. (processor_vendor): Add VENDOR_CENTAUR, VENDOR_CYRIX, VENDOR_NSC and BUILTIN_VENDOR_MAX. (processor_types): Add BUILTIN_CPU_TYPE_MAX. (processor_features): Add FEATURE_3DNOW, FEATURE_3DNOWP, FEATURE_ADX, FEATURE_ABM, FEATURE_CLDEMOTE, FEATURE_CLFLUSHOPT, FEATURE_CLWB, FEATURE_CLZERO, FEATURE_CMPXCHG16B, FEATURE_CMPXCHG8B, FEATURE_ENQCMD, FEATURE_F16C, FEATURE_FSGSBASE, FEATURE_FXSAVE, FEATURE_HLE, FEATURE_IBT, FEATURE_LAHF_LM, FEATURE_LM, FEATURE_LWP, FEATURE_LZCNT, FEATURE_MOVBE, FEATURE_MOVDIR64B, FEATURE_MOVDIRI, FEATURE_MWAITX, FEATURE_OSPKE, FEATURE_OSXSAVE, FEATURE_PCONFIG, FEATURE_PKU, FEATURE_PREFETCHWT1, FEATURE_PRFCHW, FEATURE_PTWRITE, FEATURE_RDPID, FEATURE_RDRND, FEATURE_RDSEED, FEATURE_RTM, FEATURE_SERIALIZE, FEATURE_SGX, FEATURE_SHA, FEATURE_SHSTK, FEATURE_TBM, FEATURE_TSXLDTRK, FEATURE_VAES, FEATURE_WAITPKG, FEATURE_WBNOINVD, FEATURE_XSAVE, FEATURE_XSAVEC, FEATURE_XSAVEOPT and FEATURE_XSAVES (__processor_model2): New. (__cpu_model): Removed. (__cpu_features2): Likewise. (SIZE_OF_CPU_FEATURES): New. (CHECK___builtin_cpu_is): New. Defined as empty if not defined. (has_cpu_feature): New function. (set_cpu_feature): Likewise. (get_amd_cpu): Moved from libgcc/config/i386/cpuinfo.c. Use CHECK___builtin_cpu_is. Return AMD CPU name. (get_intel_cpu): Moved from libgcc/config/i386/cpuinfo.c. Use Use CHECK___builtin_cpu_is. Return Intel CPU name. (get_available_features): Moved from libgcc/config/i386/cpuinfo.c. Also check FEATURE_3DNOW, FEATURE_3DNOWP, FEATURE_ADX, FEATURE_ABM, FEATURE_CLDEMOTE, FEATURE_CLFLUSHOPT, FEATURE_CLWB, FEATURE_CLZERO, FEATURE_CMPXCHG16B, FEATURE_CMPXCHG8B,
RE: [PATCH] Fix handling of OPT_mgeneral_regs_only in attribute.
Hi Martin > -Original Message- > From: Martin Liška > Sent: 21 May 2020 16:01 > To: gcc-patches@gcc.gnu.org > Cc: Sudakshina Das > Subject: [PATCH] Fix handling of OPT_mgeneral_regs_only in attribute. > > Hi. > > Similarly to: > > case OPT_mstrict_align: >if (val) > opts->x_target_flags |= MASK_STRICT_ALIGN; >else > opts->x_target_flags &= ~MASK_STRICT_ALIGN; >return true; > > the MASK_GENERAL_REGS_ONLY mask should be handled the same way. My old patch added the -mno-* version of the option and hence needed the change. Without the _no_ version for mgeneral-regs-only, I would imagine "val" to only ever have 1 as a value. Am I missing something here? Sudi > > @Sudakshina: The 'opts->x_target_flags |= MASK_STRICT_ALIGN' change is > not backported to all active branches. Can you please do it? > > Ready to be installed? > > gcc/ChangeLog: > > 2020-05-21 Martin Liska > > * common/config/aarch64/aarch64-common.c > (aarch64_handle_option): > Properly maask MASK_GENERAL_REGS_ONLY based on val. > --- > gcc/common/config/aarch64/aarch64-common.c | 5 - > 1 file changed, 4 insertions(+), 1 deletion(-) >
Re: [PATCH] gcc/Makefile.in: move SELFTEST_DEPS before including language makefile fragments
On May 21, 2020 5:35:19 PM GMT+02:00, Romain Naour via Gcc-patches wrote: >As reported by several Buildroot users [1][2][3], the gcc build >may fail while running selftests makefile target. > >The problem only occurs when ccache is used with gcc 9 and 10, >probably due to a race condition. Just as a note since a while I am regularly running into (the same?) issue when bootstrapping that xgcc is not yet built when self tests want to run and I stumbled across the very same dependency line. >While debuging with "make -p" we can notice that s-selftest-c target >contain only "cc1" as dependency instead of cc1 and SELFTEST_DEPS [4]. > > s-selftest-c: cc1 > >While the build is failing, the s-selftest-c dependencies recipe is >still running and reported as a bug by make. > > "Dependencies recipe running (THIS IS A BUG)." > >A change [5] in gcc 9 seems to introduce the problem since we can't >reproduce this problem with gcc 8. > >As suggested by Yann E. MORIN [6], move SELFTEST_DEPS before >including language makefile fragments. > >With the fix applied, the s-seltest-c dependency contains >SELFTEST_DEPS value. > >s-selftest-c: cc1 xgcc specs stmp-int-hdrs >../../gcc/testsuite/selftests > >[1] http://lists.busybox.net/pipermail/buildroot/2020-May/282171.html >[2] http://lists.busybox.net/pipermail/buildroot/2020-May/282766.html >[3] >https://github.com/cirosantilli/linux-kernel-module-cheat/issues/108 >[4] >https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/c/Make-lang.in;h=bfae6fd2549c4f728816cd355fa9739dcc08fcde;hb=033eb5671769a4c681a44aad08a454e667e08502#l120 >[5] >https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=033eb5671769a4c681a44aad08a454e667e08502 >[6] http://lists.busybox.net/pipermail/buildroot/2020-May/283213.html > >Signed-off-by: Romain Naour >Cc: Ben Dakin-Norris >Cc: Maxim Kochetkov >Cc: Thomas Petazzoni >Cc: Yann E. MORIN >Cc: Cc: David Malcolm >--- >This patch should be backported to gcc 10 and gcc 9. >--- > gcc/ChangeLog | 5 + > gcc/Makefile.in | 6 -- > 2 files changed, 9 insertions(+), 2 deletions(-) > >diff --git a/gcc/ChangeLog b/gcc/ChangeLog >index 977e7664b62..c3bb18f2afd 100644 >--- a/gcc/ChangeLog >+++ b/gcc/ChangeLog >@@ -1,3 +1,8 @@ >+2020-05-21 Romain Naour >+ >+ * Makefile.in: move SELFTEST_DEPS before including language >+ makefile fragments. >+ > 2020-05-21 H.J. Lu > > PR target/95260 >diff --git a/gcc/Makefile.in b/gcc/Makefile.in >index 0fe2ba241e3..867a0fa8202 100644 >--- a/gcc/Makefile.in >+++ b/gcc/Makefile.in >@@ -1730,6 +1730,10 @@ $(FULL_DRIVER_NAME): ./xgcc > rm -f $@ > $(LN_S) $< $@ > >+# SELFTEST_DEPS need to be set before including language makefile >fragments. >+# Otherwise $(SELFTEST_DEPS) is empty when used from various >/Make-lang.in. >+SELFTEST_DEPS = $(GCC_PASSES) stmp-int-hdrs >$(srcdir)/testsuite/selftests >+ > # > > # Language makefile fragments. > >@@ -2006,8 +2010,6 @@ DEVNULL=$(if $(findstring >mingw,$(build)),nul,/dev/null) > SELFTEST_FLAGS = -nostdinc $(DEVNULL) -S -o $(DEVNULL) \ > -fself-test=$(srcdir)/testsuite/selftests > >-SELFTEST_DEPS = $(GCC_PASSES) stmp-int-hdrs >$(srcdir)/testsuite/selftests >- ># Run the selftests during the build once we have a driver and the >frontend, > # so that self-test failures are caught as early as possible. > # Use "s-selftest-FE" to ensure that we only run the selftests if the
Re: [PATCH] Fix handling of OPT_mgeneral_regs_only in attribute.
On Thu, May 21, 2020 at 9:22 AM Martin Liška wrote: > > Hi. > > Similarly to: > > case OPT_mstrict_align: >if (val) > opts->x_target_flags |= MASK_STRICT_ALIGN; >else > opts->x_target_flags &= ~MASK_STRICT_ALIGN; >return true; > > the MASK_GENERAL_REGS_ONLY mask should be handled the same way. > > @Sudakshina: The 'opts->x_target_flags |= MASK_STRICT_ALIGN' change is not > backported > to all active branches. Can you please do it? > > Ready to be installed? > > gcc/ChangeLog: > > 2020-05-21 Martin Liska > > * common/config/aarch64/aarch64-common.c (aarch64_handle_option): > Properly maask MASK_GENERAL_REGS_ONLY based on val. ^ mask > --- > gcc/common/config/aarch64/aarch64-common.c | 5 - > 1 file changed, 4 insertions(+), 1 deletion(-) > > -- H.J.
Re: [PATCH] Let numeric_limits::is_iec559 reflect -ffast-math
On 21/05/20 17:46 +0200, Marc Glisse wrote: On Thu, 21 May 2020, Jonathan Wakely wrote: On 27/04/20 17:09 +0200, Matthias Kretz wrote: From: Matthias Kretz PR libstdc++/84949 * include/std/limits: Let is_iec559 reflect whether __GCC_IEC_559 says float and double support IEEE 754-2008. * testsuite/18_support/numeric_limits/is_iec559.cc: Test IEC559 mandated behavior if is_iec559 is true. * testsuite/18_support/numeric_limits/infinity.cc: Only test inf behavior if is_iec559 is true, otherwise there is no guarantee how arithmetic on inf behaves. * testsuite/18_support/numeric_limits/quiet_NaN.cc: ditto for NaN. * testsuite/18_support/numeric_limits/denorm_min-1.cc: Compile with -ffast-math. * testsuite/18_support/numeric_limits/epsilon-1.cc: ditto. * testsuite/18_support/numeric_limits/infinity-1.cc: ditto. * testsuite/18_support/numeric_limits/is_iec559-1.cc: ditto. * testsuite/18_support/numeric_limits/quiet_NaN-1.cc: ditto. I'm inclined to go ahead and commit this (to master only, obviously). It certainly seems more correct to me, and we'll probably never find out if it's "safe" to do unless we actually change it and see what happens. Marc, do you have an opinion? I don't have a strong opinion on this. I thought we were refraining from changing numeric_limits based on flags (like -fwrapv for modulo) because that would lead to ODR violations when people link objects compiled with different flags. There is a value in libstdc++.so, which may have been compiled with different flags than the application. Also, IIRC part of the effect of -ffast-math is at link time (linking some object that enables flush-to-zero). Anyway, as discussed in the PR, what numeric_limits says here is not very meaningful, and users can't rely on it 100%. By default, numeric_limits gives yes if IEC support exists on the platform. The change would sometimes make it say no, when we know for sure that this support is not enabled at the beginning of the translation unit. Why not... Good point about ODR violations. Maybe we should just let numeric_limits fade away and be irrelevant, and replace it with something better which can be more useful.
Re: [PATCH] Let numeric_limits::is_iec559 reflect -ffast-math
On Thu, 21 May 2020, Jonathan Wakely wrote: On 27/04/20 17:09 +0200, Matthias Kretz wrote: From: Matthias Kretz PR libstdc++/84949 * include/std/limits: Let is_iec559 reflect whether __GCC_IEC_559 says float and double support IEEE 754-2008. * testsuite/18_support/numeric_limits/is_iec559.cc: Test IEC559 mandated behavior if is_iec559 is true. * testsuite/18_support/numeric_limits/infinity.cc: Only test inf behavior if is_iec559 is true, otherwise there is no guarantee how arithmetic on inf behaves. * testsuite/18_support/numeric_limits/quiet_NaN.cc: ditto for NaN. * testsuite/18_support/numeric_limits/denorm_min-1.cc: Compile with -ffast-math. * testsuite/18_support/numeric_limits/epsilon-1.cc: ditto. * testsuite/18_support/numeric_limits/infinity-1.cc: ditto. * testsuite/18_support/numeric_limits/is_iec559-1.cc: ditto. * testsuite/18_support/numeric_limits/quiet_NaN-1.cc: ditto. I'm inclined to go ahead and commit this (to master only, obviously). It certainly seems more correct to me, and we'll probably never find out if it's "safe" to do unless we actually change it and see what happens. Marc, do you have an opinion? I don't have a strong opinion on this. I thought we were refraining from changing numeric_limits based on flags (like -fwrapv for modulo) because that would lead to ODR violations when people link objects compiled with different flags. There is a value in libstdc++.so, which may have been compiled with different flags than the application. Also, IIRC part of the effect of -ffast-math is at link time (linking some object that enables flush-to-zero). Anyway, as discussed in the PR, what numeric_limits says here is not very meaningful, and users can't rely on it 100%. By default, numeric_limits gives yes if IEC support exists on the platform. The change would sometimes make it say no, when we know for sure that this support is not enabled at the beginning of the translation unit. Why not... -- Marc Glisse
Re: ChangeLog files - server and client scripts
Hi Martin, >> two comments: >> >> * Can you please avoid the use grey highlighting in that section? Black >>script on a grey background is already hard to read for someone with >>reasonable vision. I suspect it will be much harder for >>vision-impaired people. > > You are right, I fixed that. thanks. >> * In changelog_location, you allow only (among others) "a/b/c/" and >>"\ta/b/c/". Please also accept the "a/b/c:" and "\ta/b/c:" forms >>here: especially the second seems quite common. > > Sure, can you please link some git revisions that use the format? Apart from using it myself ;-), I've seen it several times, but no examples off-hand. However, it seems only consistent with the forms ending in /ChangeLog where you allow the trailing colon, too. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
[PATCH] gcc/Makefile.in: move SELFTEST_DEPS before including language makefile fragments
As reported by several Buildroot users [1][2][3], the gcc build may fail while running selftests makefile target. The problem only occurs when ccache is used with gcc 9 and 10, probably due to a race condition. While debuging with "make -p" we can notice that s-selftest-c target contain only "cc1" as dependency instead of cc1 and SELFTEST_DEPS [4]. s-selftest-c: cc1 While the build is failing, the s-selftest-c dependencies recipe is still running and reported as a bug by make. "Dependencies recipe running (THIS IS A BUG)." A change [5] in gcc 9 seems to introduce the problem since we can't reproduce this problem with gcc 8. As suggested by Yann E. MORIN [6], move SELFTEST_DEPS before including language makefile fragments. With the fix applied, the s-seltest-c dependency contains SELFTEST_DEPS value. s-selftest-c: cc1 xgcc specs stmp-int-hdrs ../../gcc/testsuite/selftests [1] http://lists.busybox.net/pipermail/buildroot/2020-May/282171.html [2] http://lists.busybox.net/pipermail/buildroot/2020-May/282766.html [3] https://github.com/cirosantilli/linux-kernel-module-cheat/issues/108 [4] https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/c/Make-lang.in;h=bfae6fd2549c4f728816cd355fa9739dcc08fcde;hb=033eb5671769a4c681a44aad08a454e667e08502#l120 [5] https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=033eb5671769a4c681a44aad08a454e667e08502 [6] http://lists.busybox.net/pipermail/buildroot/2020-May/283213.html Signed-off-by: Romain Naour Cc: Ben Dakin-Norris Cc: Maxim Kochetkov Cc: Thomas Petazzoni Cc: Yann E. MORIN Cc: Cc: David Malcolm --- This patch should be backported to gcc 10 and gcc 9. --- gcc/ChangeLog | 5 + gcc/Makefile.in | 6 -- 2 files changed, 9 insertions(+), 2 deletions(-) diff --git a/gcc/ChangeLog b/gcc/ChangeLog index 977e7664b62..c3bb18f2afd 100644 --- a/gcc/ChangeLog +++ b/gcc/ChangeLog @@ -1,3 +1,8 @@ +2020-05-21 Romain Naour + + * Makefile.in: move SELFTEST_DEPS before including language + makefile fragments. + 2020-05-21 H.J. Lu PR target/95260 diff --git a/gcc/Makefile.in b/gcc/Makefile.in index 0fe2ba241e3..867a0fa8202 100644 --- a/gcc/Makefile.in +++ b/gcc/Makefile.in @@ -1730,6 +1730,10 @@ $(FULL_DRIVER_NAME): ./xgcc rm -f $@ $(LN_S) $< $@ +# SELFTEST_DEPS need to be set before including language makefile fragments. +# Otherwise $(SELFTEST_DEPS) is empty when used from various /Make-lang.in. +SELFTEST_DEPS = $(GCC_PASSES) stmp-int-hdrs $(srcdir)/testsuite/selftests + # # Language makefile fragments. @@ -2006,8 +2010,6 @@ DEVNULL=$(if $(findstring mingw,$(build)),nul,/dev/null) SELFTEST_FLAGS = -nostdinc $(DEVNULL) -S -o $(DEVNULL) \ -fself-test=$(srcdir)/testsuite/selftests -SELFTEST_DEPS = $(GCC_PASSES) stmp-int-hdrs $(srcdir)/testsuite/selftests - # Run the selftests during the build once we have a driver and the frontend, # so that self-test failures are caught as early as possible. # Use "s-selftest-FE" to ensure that we only run the selftests if the -- 2.25.4
Re: ChangeLog files - server and client scripts
On 5/21/20 5:14 PM, Rainer Orth wrote: Hi Martin, We've just installed server git hooks that verify git messages for a correct ChangeLog format. For a limited time period, please still apply ChangeLog changes to the corresponding ChangeLog files. We'll use it for comparison of auto-generated CangeLog entries. The format is documented here: https://gcc.gnu.org/codingconventions.html#ChangeLogs two comments: * Can you please avoid the use grey highlighting in that section? Black script on a grey background is already hard to read for someone with reasonable vision. I suspect it will be much harder for vision-impaired people. You are right, I fixed that. * In changelog_location, you allow only (among others) "a/b/c/" and "\ta/b/c/". Please also accept the "a/b/c:" and "\ta/b/c:" forms here: especially the second seems quite common. Sure, can you please link some git revisions that use the format? Thanks, Martin Thanks. Rainer
Re: ChangeLog files - server and client scripts
Hi Martin, > We've just installed server git hooks that verify git messages > for a correct ChangeLog format. For a limited time period, please > still apply ChangeLog changes to the corresponding ChangeLog files. > We'll use it for comparison of auto-generated CangeLog entries. > > The format is documented here: > https://gcc.gnu.org/codingconventions.html#ChangeLogs two comments: * Can you please avoid the use grey highlighting in that section? Black script on a grey background is already hard to read for someone with reasonable vision. I suspect it will be much harder for vision-impaired people. * In changelog_location, you allow only (among others) "a/b/c/" and "\ta/b/c/". Please also accept the "a/b/c:" and "\ta/b/c:" forms here: especially the second seems quite common. Thanks. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
[COMMITTED] Include memmodel.h in adjust-alignment.c
Hi Kito,
> Tested and committed with fixes, thanks your review :)
this patch broke SPARC bootstrap:
In file included from ./tm_p.h:4,
from /vol/gcc/src/hg/master/local/gcc/adjust-alignment.c:28:
/vol/gcc/src/hg/master/local/gcc/config/sparc/sparc-protos.h:45:47: error: use
of enum 'memmodel' without previous declaration
extern void sparc_emit_membar_for_model (enum memmodel, int, int);
^~~~
Fixed by including memmodel.h. Bootstrapped on sparc-sun-solaris2.11
and i386-pc-solaris2.11, installed as obvious.
Rainer
--
-
Rainer Orth, Center for Biotechnology, Bielefeld University
2020-05-21 Rainer Orth
gcc:
* adjust-alignment.c: Include memmodel.h.
# HG changeset patch
# Parent 874f4dad97cc15024c5ed184a1b4e54daa37e69a
Include memmodel.h in adjust-alignment.c
diff --git a/gcc/adjust-alignment.c b/gcc/adjust-alignment.c
--- a/gcc/adjust-alignment.c
+++ b/gcc/adjust-alignment.c
@@ -25,6 +25,7 @@ along with GCC; see the file COPYING3.
#include "target.h"
#include "tree.h"
#include "tree-pass.h"
+#include "memmodel.h"
#include "tm_p.h"
namespace {
[PATCH] Fix handling of OPT_mgeneral_regs_only in attribute.
Hi. Similarly to: case OPT_mstrict_align: if (val) opts->x_target_flags |= MASK_STRICT_ALIGN; else opts->x_target_flags &= ~MASK_STRICT_ALIGN; return true; the MASK_GENERAL_REGS_ONLY mask should be handled the same way. @Sudakshina: The 'opts->x_target_flags |= MASK_STRICT_ALIGN' change is not backported to all active branches. Can you please do it? Ready to be installed? gcc/ChangeLog: 2020-05-21 Martin Liska * common/config/aarch64/aarch64-common.c (aarch64_handle_option): Properly maask MASK_GENERAL_REGS_ONLY based on val. --- gcc/common/config/aarch64/aarch64-common.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/gcc/common/config/aarch64/aarch64-common.c b/gcc/common/config/aarch64/aarch64-common.c index 51bd319d6d3..ef6b34025d9 100644 --- a/gcc/common/config/aarch64/aarch64-common.c +++ b/gcc/common/config/aarch64/aarch64-common.c @@ -98,7 +98,10 @@ aarch64_handle_option (struct gcc_options *opts, return true; case OPT_mgeneral_regs_only: - opts->x_target_flags |= MASK_GENERAL_REGS_ONLY; + if (val) + opts->x_target_flags |= MASK_GENERAL_REGS_ONLY; + else + opts->x_target_flags &= ~MASK_GENERAL_REGS_ONLY; return true; case OPT_mfix_cortex_a53_835769:
Re: [PATCH] Implement no_stack_protect attribute.
On 5/21/20 5:28 AM, Martin Liška wrote: On 5/18/20 10:37 PM, Martin Sebor wrote: I know there are some somewhat complex cases the attribute exclusion mechanism isn't general enough to handle but this seems simple enough that it should work. Unless I'm missing something that makes it not feasible I would suggest to use it. Hi Martin. Do we have a better place where we check for attribute collision? If by collision you mean the same thing as the mutual exclusion I was talking about then that's done by creating an attribute_spec::exclusions array like for instance attr_cold_hot_exclusions in c-attribs.c and pointing to it from the attribute_spec entries for each of the mutually exclusive attributes in the attribute table. Everything else is handled automatically by decl_attributes. Martin
Re: [PATCH] Let numeric_limits::is_iec559 reflect -ffast-math
On 27/04/20 17:09 +0200, Matthias Kretz wrote:
From: Matthias Kretz
PR libstdc++/84949
* include/std/limits: Let is_iec559 reflect whether
__GCC_IEC_559 says float and double support IEEE 754-2008.
* testsuite/18_support/numeric_limits/is_iec559.cc: Test IEC559
mandated behavior if is_iec559 is true.
* testsuite/18_support/numeric_limits/infinity.cc: Only test inf
behavior if is_iec559 is true, otherwise there is no guarantee
how arithmetic on inf behaves.
* testsuite/18_support/numeric_limits/quiet_NaN.cc: ditto for
NaN.
* testsuite/18_support/numeric_limits/denorm_min-1.cc: Compile
with -ffast-math.
* testsuite/18_support/numeric_limits/epsilon-1.cc: ditto.
* testsuite/18_support/numeric_limits/infinity-1.cc: ditto.
* testsuite/18_support/numeric_limits/is_iec559-1.cc: ditto.
* testsuite/18_support/numeric_limits/quiet_NaN-1.cc: ditto.
I'm inclined to go ahead and commit this (to master only, obviously).
It certainly seems more correct to me, and we'll probably never find
out if it's "safe" to do unless we actually change it and see what
happens.
Marc, do you have an opinion?
---
libstdc++-v3/include/std/limits | 9 ++--
.../18_support/numeric_limits/denorm_min-1.cc | 2 +
.../18_support/numeric_limits/epsilon-1.cc| 2 +
.../18_support/numeric_limits/infinity-1.cc | 2 +
.../18_support/numeric_limits/infinity.cc | 4 +-
.../18_support/numeric_limits/is_iec559-1.cc | 2 +
.../18_support/numeric_limits/is_iec559.cc| 44 ++-
.../18_support/numeric_limits/quiet_NaN-1.cc | 2 +
.../18_support/numeric_limits/quiet_NaN.cc| 5 ++-
9 files changed, 51 insertions(+), 21 deletions(-)
create mode 100644 libstdc++-v3/testsuite/18_support/numeric_limits/
denorm_min-1.cc
create mode 100644 libstdc++-v3/testsuite/18_support/numeric_limits/
epsilon-1.cc
create mode 100644 libstdc++-v3/testsuite/18_support/numeric_limits/
infinity-1.cc
create mode 100644 libstdc++-v3/testsuite/18_support/numeric_limits/
is_iec559-1.cc
create mode 100644 libstdc++-v3/testsuite/18_support/numeric_limits/
quiet_NaN-1.cc
diff --git a/libstdc++-v3/include/std/limits b/libstdc++-v3/include/std/limits
index 898406f91ee..c27350c9ec4 100644
--- a/libstdc++-v3/include/std/limits
+++ b/libstdc++-v3/include/std/limits
@@ -1714,8 +1714,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
static _GLIBCXX_CONSTEXPR float
denorm_min() _GLIBCXX_USE_NOEXCEPT { return __FLT_DENORM_MIN__; }
- static _GLIBCXX_USE_CONSTEXPR bool is_iec559
- = has_infinity && has_quiet_NaN && has_denorm == denorm_present;
+ static _GLIBCXX_USE_CONSTEXPR bool is_iec559 = __GCC_IEC_559 >= 2;
static _GLIBCXX_USE_CONSTEXPR bool is_bounded = true;
static _GLIBCXX_USE_CONSTEXPR bool is_modulo = false;
@@ -1789,8 +1788,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
static _GLIBCXX_CONSTEXPR double
denorm_min() _GLIBCXX_USE_NOEXCEPT { return __DBL_DENORM_MIN__; }
- static _GLIBCXX_USE_CONSTEXPR bool is_iec559
- = has_infinity && has_quiet_NaN && has_denorm == denorm_present;
+ static _GLIBCXX_USE_CONSTEXPR bool is_iec559 = __GCC_IEC_559 >= 2;
static _GLIBCXX_USE_CONSTEXPR bool is_bounded = true;
static _GLIBCXX_USE_CONSTEXPR bool is_modulo = false;
@@ -1864,8 +1862,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
static _GLIBCXX_CONSTEXPR long double
denorm_min() _GLIBCXX_USE_NOEXCEPT { return __LDBL_DENORM_MIN__; }
- static _GLIBCXX_USE_CONSTEXPR bool is_iec559
- = has_infinity && has_quiet_NaN && has_denorm == denorm_present;
+ static _GLIBCXX_USE_CONSTEXPR bool is_iec559 = __GCC_IEC_559 >= 2;
static _GLIBCXX_USE_CONSTEXPR bool is_bounded = true;
static _GLIBCXX_USE_CONSTEXPR bool is_modulo = false;
diff --git a/libstdc++-v3/testsuite/18_support/numeric_limits/denorm_min-1.cc
b/libstdc++-v3/testsuite/18_support/numeric_limits/denorm_min-1.cc
new file mode 100644
index 000..8ff2950d77e
--- /dev/null
+++ b/libstdc++-v3/testsuite/18_support/numeric_limits/denorm_min-1.cc
@@ -0,0 +1,2 @@
+// { dg-options "-ffast-math" }
+#include "denorm_min.cc"
diff --git a/libstdc++-v3/testsuite/18_support/numeric_limits/epsilon-1.cc
b/libstdc++-v3/testsuite/18_support/numeric_limits/epsilon-1.cc
new file mode 100644
index 000..34548976bea
--- /dev/null
+++ b/libstdc++-v3/testsuite/18_support/numeric_limits/epsilon-1.cc
@@ -0,0 +1,2 @@
+// { dg-options "-ffast-math" }
+#include "epsilon.cc"
diff --git a/libstdc++-v3/testsuite/18_support/numeric_limits/infinity-1.cc
b/libstdc++-v3/testsuite/18_support/numeric_limits/infinity-1.cc
new file mode 100644
index 000..7ff8ea81242
--- /dev/null
+++ b/libstdc++-v3/testsuite/18_support/numeric_limits/infinity-1.cc
@@ -0,0 +1,2 @@
+// { dg-options "-ffast-math" }
+#include "infinity.cc"
diff --git a/libstdc++-v3/testsuite/18_support/numeric_limits/infinity.cc
[PATCH] config/i386/cpuid.h: Use hexadecimal in comments
Since Intel SDM uses hexadecimal, use hexadecimal in comments. PR target/95260 * config/i386/cpuid.h: Use hexadecimal in comments. --- gcc/ChangeLog | 5 + gcc/config/i386/cpuid.h | 6 +++--- 2 files changed, 8 insertions(+), 3 deletions(-) diff --git a/gcc/ChangeLog b/gcc/ChangeLog index 89b908f64d8..977e7664b62 100644 --- a/gcc/ChangeLog +++ b/gcc/ChangeLog @@ -1,3 +1,8 @@ +2020-05-21 H.J. Lu + + PR target/95260 + * config/i386/cpuid.h: Use hexadecimal in comments. + 2020-05-21 H.J. Lu PR target/95212 diff --git a/gcc/config/i386/cpuid.h b/gcc/config/i386/cpuid.h index 9fee32a8f1d..94af4910d3c 100644 --- a/gcc/config/i386/cpuid.h +++ b/gcc/config/i386/cpuid.h @@ -125,16 +125,16 @@ #define bit_SERIALIZE (1 << 14) #define bit_TSXLDTRK(1 << 16) -/* XFEATURE_ENABLED_MASK register bits (%eax == 13, %ecx == 0) */ +/* XFEATURE_ENABLED_MASK register bits (%eax == 0xd, %ecx == 0) */ #define bit_BNDREGS (1 << 3) #define bit_BNDCSR (1 << 4) -/* Extended State Enumeration Sub-leaf (%eax == 13, %ecx == 1) */ +/* Extended State Enumeration Sub-leaf (%eax == 0xd, %ecx == 1) */ #define bit_XSAVEOPT (1 << 0) #define bit_XSAVEC (1 << 1) #define bit_XSAVES (1 << 3) -/* PT sub leaf (%eax == 14, %ecx == 0) */ +/* PT sub leaf (%eax == 0x14, %ecx == 0) */ /* %ebx */ #define bit_PTWRITE(1 << 4) -- 2.26.2
Re: [PATCH] Add outline-atomics to target attribute.
Martin Liška writes:
> On 5/21/20 12:11 PM, Richard Sandiford wrote:
>> Yeah, agree it'd be worth having tests for both directions. The patch
>> itself looks good though -- thanks for doing this.
>
> Thanks. There's a version with 2 new tests that I've just tested.
>
> I'm going to install the patch for master. Is it also fine for all
> active branches where you backported the atomics outlining?
Yeah, OK for all those too.
Thanks,
Richard
> Martin
>
> From 357a86fbf18ad511a72e6e9c703a6e0b0dd30ddf Mon Sep 17 00:00:00 2001
> From: Martin Liska
> Date: Thu, 21 May 2020 09:19:21 +0200
> Subject: [PATCH] Add outline-atomics to target attribute.
>
> gcc/ChangeLog:
>
> 2020-05-21 Martin Liska
>
> * common/config/aarch64/aarch64-common.c (aarch64_handle_option):
> Handle OPT_moutline_atomics.
> * config/aarch64/aarch64.c: Add outline-atomics to
> aarch64_attributes.
> * doc/extend.texi: Document the newly added target attribute.
>
> gcc/testsuite/ChangeLog:
>
> 2020-05-21 Martin Liska
>
> * gcc.target/aarch64/target_attr_20.c: New test.
> * gcc.target/aarch64/target_attr_21.c: New test.
> ---
> gcc/common/config/aarch64/aarch64-common.c| 4 +++
> gcc/config/aarch64/aarch64.c | 2 ++
> gcc/doc/extend.texi | 6 +
> .../gcc.target/aarch64/target_attr_20.c | 27 +++
> .../gcc.target/aarch64/target_attr_21.c | 27 +++
> 5 files changed, 66 insertions(+)
> create mode 100644 gcc/testsuite/gcc.target/aarch64/target_attr_20.c
> create mode 100644 gcc/testsuite/gcc.target/aarch64/target_attr_21.c
>
> diff --git a/gcc/common/config/aarch64/aarch64-common.c
> b/gcc/common/config/aarch64/aarch64-common.c
> index 0bddcc8c3e9..51bd319d6d3 100644
> --- a/gcc/common/config/aarch64/aarch64-common.c
> +++ b/gcc/common/config/aarch64/aarch64-common.c
> @@ -116,6 +116,10 @@ aarch64_handle_option (struct gcc_options *opts,
>opts->x_flag_omit_leaf_frame_pointer = val;
>return true;
>
> +case OPT_moutline_atomics:
> + opts->x_aarch64_flag_outline_atomics = val;
> + return true;
> +
> default:
>return true;
> }
> diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
> index 79c016f4dc3..78db0a56323 100644
> --- a/gcc/config/aarch64/aarch64.c
> +++ b/gcc/config/aarch64/aarch64.c
> @@ -15266,6 +15266,8 @@ static const struct aarch64_attribute_info
> aarch64_attributes[] =
> aarch64_handle_attr_branch_protection, OPT_mbranch_protection_ },
>{ "sign-return-address", aarch64_attr_enum, false, NULL,
> OPT_msign_return_address_ },
> + { "outline-atomics", aarch64_attr_bool, true, NULL,
> + OPT_moutline_atomics},
>{ NULL, aarch64_attr_custom, false, NULL, OPT }
> };
>
> diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
> index c80848e9061..a2ebef8cf8c 100644
> --- a/gcc/doc/extend.texi
> +++ b/gcc/doc/extend.texi
> @@ -4066,6 +4066,12 @@ Select the function scope on which branch protection
> will be applied. The
> behavior and permissible arguments are the same as for the command-line
> option
> @option{-mbranch-protection=}. The default value is @code{none}.
>
> +@item outline-atomics
> +@cindex @code{outline-atomics} function attribute, AArch64
> +Enable or disable calls to out-of-line helpers to implement atomic
> operations.
> +This corresponds to the behavior of the command line options
> +@option{-moutline-atomics} and @option{-mno-outline-atomics}.
> +
> @end table
>
> The above target attributes can be specified as follows:
> diff --git a/gcc/testsuite/gcc.target/aarch64/target_attr_20.c
> b/gcc/testsuite/gcc.target/aarch64/target_attr_20.c
> new file mode 100644
> index 000..509fb039e84
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/aarch64/target_attr_20.c
> @@ -0,0 +1,27 @@
> +/* { dg-do compile } */
> +/* { dg-options "-march=armv8-a+nolse -moutline-atomics" } */
> +
> +int b, c, d, e, f, h;
> +short g;
> +int foo (int) __attribute__ ((__const__));
> +
> +__attribute__ ((target ("no-outline-atomics")))
> +void
> +bar (void)
> +{
> + while (1)
> +{
> + while (1)
> + {
> + __atomic_load_n (, 0);
> + if (foo (2))
> + __sync_val_compare_and_swap (, 0, f);
> + b = 1;
> + if (h == e)
> + break;
> + }
> + __sync_val_compare_and_swap (, -1, f);
> +}
> +}
> +
> +/* { dg-final { scan-assembler-not "bl.*__aarch64_cas2_acq_rel" } } */
> diff --git a/gcc/testsuite/gcc.target/aarch64/target_attr_21.c
> b/gcc/testsuite/gcc.target/aarch64/target_attr_21.c
> new file mode 100644
> index 000..acace4c8f2a
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/aarch64/target_attr_21.c
> @@ -0,0 +1,27 @@
> +/* { dg-do compile } */
> +/* { dg-options "-march=armv8-a+nolse -mno-outline-atomics" } */
> +
> +int b, c, d, e, f, h;
> +short g;
> +int foo (int) __attribute__ ((__const__));
> +
> +__attribute__
Re: [stage1][PATCH] Lower VEC_COND_EXPR into internal functions.
Adding Segher to CC, he can help us.
Martin
On 5/21/20 2:51 PM, Martin Liška wrote:
Hi.
Back to this I noticed that ppc64le target build is broken due to:
g++ -fno-PIE -c -g -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -fno-exceptions
-fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic
-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common
-DHAVE_CONFIG_H -I. -I. -I/home/marxin/Programming/gcc/gcc
-I/home/marxin/Programming/gcc/gcc/.
-I/home/marxin/Programming/gcc/gcc/../include
-I/home/marxin/Programming/gcc/gcc/../libcpp/include
-I/home/marxin/Programming/gcc/gcc/../libdecnumber
-I/home/marxin/Programming/gcc/gcc/../libdecnumber/dpd -I../libdecnumber
-I/home/marxin/Programming/gcc/gcc/../libbacktrace -o insn-emit.o -MT
insn-emit.o -MMD -MP -MF ./.deps/insn-emit.TPo insn-emit.c
/home/marxin/Programming/gcc/gcc/config/rs6000/vector.md:357:11: error:
vcondv4sfv4sf cannot FAIL
357 | FAIL;
| ^
/home/marxin/Programming/gcc/gcc/config/rs6000/vector.md:357:11: error:
vcondv2dfv2df cannot FAIL
357 | FAIL;
| ^
/home/marxin/Programming/gcc/gcc/config/rs6000/vector.md:374:11: error:
vcondv16qiv16qi cannot FAIL
374 | FAIL;
| ^
/home/marxin/Programming/gcc/gcc/config/rs6000/vector.md:374:11: error:
vcondv8hiv8hi cannot FAIL
374 | FAIL;
| ^
...
which is caused by the 4 added optabs:
+DEF_INTERNAL_OPTAB_FN (VCOND, 0, vcond, vec_cond)
+DEF_INTERNAL_OPTAB_FN (VCONDU, 0, vcondu, vec_condu)
+DEF_INTERNAL_OPTAB_FN (VCONDEQ, 0, vcondeq, vec_condeq)
+DEF_INTERNAL_OPTAB_FN (VCOND_MASK, 0, vcond_mask, vec_cond_mask)
looking at the generator:
Breakpoint 6, gen_expand (info=0x7fffe160) at
/home/marxin/Programming/gcc/gcc/genemit.c:516
516 if (find_optab (, XSTR (expand, 0)))
(gdb) bt
#0 emit_c_code (code=0x7fa0f0 "{\n if (rs6000_emit_vector_cond_expr (operands[0],
operands[1], operands[2],\n\t\t\t\t operands[3], operands[4], operands[5]))\n DONE;\n else\n
FAIL;\n}", can_fail_p=false, name=0x7fa190 "vcondv4sfv4sf")
at /home/marxin/Programming/gcc/gcc/genemit.c:306
#1 0x004039b5 in gen_expand (info=0x7fffe160) at
/home/marxin/Programming/gcc/gcc/genemit.c:522
#2 0x00404912 in main (argc=4, argv=0x7fffe288) at
/home/marxin/Programming/gcc/gcc/genemit.c:916
I get there due to:
B- │516 if (find_optab (, XSTR (expand, 0)))│
│517 { │
│518 gcc_assert (p.op < NUM_OPTABS); │
│519 if (nofail_optabs[p.op]) │
│520 can_fail_p = false; │
│521 } │
#define DEF_INTERNAL_OPTAB_FN(NAME, FLAGS, OPTAB, TYPE) \
nofail_optabs[OPTAB##_optab] = true;
#include "internal-fn.def"
Any hint what's bad? Note that x86_64-linux-gnu is fine.
Do I miss a target hook?
Martin
Re: [PATCH] Enable simple invocation of runtest in testsuite
On 23/04/20 12:58 +0200, Matthias Kretz wrote: I noticed this inconvenience while learning dejagnu. From: Matthias Kretz * testsuite/Makefile.am: Remove dup target_triplet and set tool, allowing runtest to work without arguments. Committed to master, thanks.
Re: Optimize SCC streaming a bit
On May 21, 2020 1:11:33 PM GMT+02:00, Jan Hubicka wrote:
>Hi,
>this patch saves few bytes from SCC streaming. First we stream end
>markers
>that are fully ignored at stream in.
>Second I missed streaming of emtry_len in the previous change so it is
>pointlessly streamed for LTO_trees. Moreover entry_len is almost always
>1
>(always during gcc bootstrap) and thus it makes sense to avoid
>stremaing it
>in majority of cases.
It's then only one byte, no? But yes...
>
>ltobootstrapped/regtested x86_64-linux, OK?
OK.
Richard.
>gcc/ChangeLog:
>
>2020-05-21 Jan Hubicka
>
> * lto-streamer-in.c (lto_read_tree): Do not stream end markers.
> (lto_input_scc): Optimize streaming of entry lengths.
> * lto-streamer-out.c (lto_write_tree): Do not stream end markers
> (DFS::DFS): Optimize stremaing of entry lengths
>
>gcc/lto/ChangeLog:
>
>2020-05-21 Jan Hubicka
>
> * lto-common.c (compare_tree_sccs):
>
>diff --git a/gcc/lto-streamer-in.c b/gcc/lto-streamer-in.c
>index 85d0edf49a7..d0532c5ac51 100644
>--- a/gcc/lto-streamer-in.c
>+++ b/gcc/lto-streamer-in.c
>@@ -1417,8 +1417,6 @@ lto_read_tree (class lto_input_block *ib, class
>data_in *data_in,
>
> lto_read_tree_1 (ib, data_in, result);
>
>- /* end_marker = */ streamer_read_uchar (ib);
>-
> return result;
> }
>
>@@ -1431,12 +1429,18 @@ hashval_t
> lto_input_scc (class lto_input_block *ib, class data_in *data_in,
> unsigned *len, unsigned *entry_len, bool shared_scc)
> {
>- /* A blob of unnamed tree nodes, fill the cache from it and
>- recurse. */
> unsigned size = streamer_read_uhwi (ib);
>- hashval_t scc_hash = shared_scc ? streamer_read_uhwi (ib) : 0;
>+ hashval_t scc_hash = 0;
> unsigned scc_entry_len = 1;
>
>+ if (shared_scc)
>+{
>+ if (size & 1)
>+ scc_entry_len = streamer_read_uhwi (ib);
>+ size /= 2;
>+ scc_hash = streamer_read_uhwi (ib);
>+}
>+
> if (size == 1)
> {
> enum LTO_tags tag = streamer_read_record_start (ib);
>@@ -1447,8 +1451,6 @@ lto_input_scc (class lto_input_block *ib, class
>data_in *data_in,
> unsigned int first = data_in->reader_cache->nodes.length ();
> tree result;
>
>- scc_entry_len = streamer_read_uhwi (ib);
>-
> /* Materialize size trees by reading their headers. */
> for (unsigned i = 0; i < size; ++i)
> {
>@@ -1471,7 +1473,6 @@ lto_input_scc (class lto_input_block *ib, class
>data_in *data_in,
> result = streamer_tree_cache_get_tree (data_in->reader_cache,
>first + i);
> lto_read_tree_1 (ib, data_in, result);
>-/* end_marker = */ streamer_read_uchar (ib);
> }
> }
>
>diff --git a/gcc/lto-streamer-out.c b/gcc/lto-streamer-out.c
>index 0e179468043..09a2e827f8e 100644
>--- a/gcc/lto-streamer-out.c
>+++ b/gcc/lto-streamer-out.c
>@@ -473,9 +473,6 @@ lto_write_tree (struct output_block *ob, tree expr,
>bool ref_p)
> streamer_write_tree_header (ob, expr);
>
> lto_write_tree_1 (ob, expr, ref_p);
>-
>- /* Mark the end of EXPR. */
>- streamer_write_zero (ob);
> }
>
>/* Emit the physical representation of tree node EXPR to output block
>OB,
>@@ -764,7 +761,12 @@ DFS::DFS (struct output_block *ob, tree expr, bool
>ref_p, bool this_ref_p,
> {
> gcc_checking_assert (ob->section_type == LTO_section_decls);
> streamer_write_record_start (ob, LTO_tree_scc);
>-streamer_write_uhwi (ob, size);
>+/* In wast majority of cases scc_entry_len is 1 and size is
>small
>+ integer. Use extra bit of size to stream info about
>+ exceptions. */
>+streamer_write_uhwi (ob, size * 2 + (scc_entry_len != 1));
>+if (scc_entry_len != 1)
>+ streamer_write_uhwi (ob, scc_entry_len);
> streamer_write_uhwi (ob, scc_hash);
> }
> /* Non-trivial SCCs must be packed to trees blocks so forward
>@@ -783,8 +785,6 @@ DFS::DFS (struct output_block *ob, tree expr, bool
>ref_p, bool this_ref_p,
> lto_output_tree_1 (ob, expr, scc_hash, ref_p, this_ref_p);
> else
> {
>-/* Write the size of the SCC entry candidates. */
>-streamer_write_uhwi (ob, scc_entry_len);
>
> /* Write all headers and populate the streamer cache. */
> for (unsigned i = 0; i < size; ++i)
>@@ -807,12 +807,7 @@ DFS::DFS (struct output_block *ob, tree expr, bool
>ref_p, bool this_ref_p,
>
> /* Write the bitpacks and tree references. */
> for (unsigned i = 0; i < size; ++i)
>- {
>-lto_write_tree_1 (ob, sccstack[first+i].t, ref_p);
>-
>-/* Mark the end of the tree. */
>-streamer_write_zero (ob);
>- }
>+ lto_write_tree_1 (ob, sccstack[first+i].t, ref_p);
> }
>
> /* Finally truncate the vector. */
Re: [RFC] analyzer: Add exit, and _exit replacement, to sm-signal.
On Thu, 2020-05-21 at 00:48 +0200, Mark Wielaard wrote:
> Hi,
>
> On Mon, May 18, 2020 at 07:30:58PM -0400, Marek Polacek wrote:
> > > + /* Returns a replacement function as text if it
> > > exists. Currently
> > > + only "exit" has a signal-safe replacement "_exit", which
> > > does
> > > + slightly less, but can be used in a signal handler. */
> > > + const char *
> > > + get_replacement_fn ()
> > > + {
> > > +gcc_assert (m_unsafe_fndecl && DECL_P (m_unsafe_fndecl));
> > > +
> > > +if (strcmp ("exit",
> > > + IDENTIFIER_POINTER (DECL_NAME (m_unsafe_fndecl))) == 0)
> >
> > Instead of strcmp, you should be able to use id_equal here, making
> > this a bit
> > simpler.
>
> That does make it a little easier to read.
> How about the attached?
>
> Thanks,
>
> Mark
> + exit(1); /* { dg-warning "call to 'exit' from within signal handler" } */
> + /* { dg-message "note: '_exit' is a possible signal-safe alternative for
> 'exit'" "" { target *-*-* } 12 } */
A couple of nits here:
(a) if two dg diagnostic directives share the same line, it's best to
give them names so that they can be disambiguated in the gcc.sum
output, in case something starts failing for some reason. So please
replace that "" with e.g. "replacement note" and give the warning a
name (e.g. "warning").
(b) rather than hardcoding the absolute line number as 12 above, it's
more future-proof to use a relative line number .-1
So the above should read something like:
+ exit(1); /* { dg-warning "call to 'exit' from within signal handler"
"warning" } */
+ /* { dg-message "note: '_exit' is a possible signal-safe alternative for
'exit'" "replacement note" { target *-*-* } .-1 } */
OK with that change (but please double-check I got the syntax correct!)
Thanks
Dave
[PATCH] x86: Handle -mavx512vpopcntdq for -march=native
Add -mavx512vpopcntdq for -march=native if AVX512VPOPCNTDQ is available. PR target/95258 * config/i386/driver-i386.c (host_detect_local_cpu): Detect AVX512VPOPCNTDQ. --- gcc/config/i386/driver-i386.c | 9 ++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/gcc/config/i386/driver-i386.c b/gcc/config/i386/driver-i386.c index 7612ddfb846..3a816400729 100644 --- a/gcc/config/i386/driver-i386.c +++ b/gcc/config/i386/driver-i386.c @@ -420,6 +420,7 @@ const char *host_detect_local_cpu (int argc, const char **argv) unsigned int has_avx5124fmaps = 0, has_avx5124vnniw = 0; unsigned int has_gfni = 0, has_avx512vbmi2 = 0; unsigned int has_avx512bitalg = 0; + unsigned int has_avx512vpopcntdq = 0; unsigned int has_shstk = 0; unsigned int has_avx512vnni = 0, has_vaes = 0; unsigned int has_vpclmulqdq = 0; @@ -528,6 +529,7 @@ const char *host_detect_local_cpu (int argc, const char **argv) has_vaes = ecx & bit_VAES; has_vpclmulqdq = ecx & bit_VPCLMULQDQ; has_avx512bitalg = ecx & bit_AVX512BITALG; + has_avx512vpopcntdq = ecx & bit_AVX512VPOPCNTDQ; has_movdiri = ecx & bit_MOVDIRI; has_movdir64b = ecx & bit_MOVDIR64B; has_enqcmd = ecx & bit_ENQCMD; @@ -1189,6 +1191,7 @@ const char *host_detect_local_cpu (int argc, const char **argv) const char *avx512vp2intersect = has_avx512vp2intersect ? " -mavx512vp2intersect" : " -mno-avx512vp2intersect"; const char *tsxldtrk = has_tsxldtrk ? " -mtsxldtrk " : " -mno-tsxldtrk"; const char *avx512bitalg = has_avx512bitalg ? " -mavx512bitalg" : " -mno-avx512bitalg"; + const char *avx512vpopcntdq = has_avx512vpopcntdq ? " -mavx512vpopcntdq" : " -mno-avx512vpopcntdq"; const char *movdiri = has_movdiri ? " -mmovdiri" : " -mno-movdiri"; const char *movdir64b = has_movdir64b ? " -mmovdir64b" : " -mno-movdir64b"; const char *enqcmd = has_enqcmd ? " -menqcmd" : " -mno-enqcmd"; @@ -1210,9 +1213,9 @@ const char *host_detect_local_cpu (int argc, const char **argv) avx512ifma, avx512vbmi, avx5124fmaps, avx5124vnniw, clwb, mwaitx, clzero, pku, rdpid, gfni, shstk, avx512vbmi2, avx512vnni, vaes, vpclmulqdq, - avx512bitalg, movdiri, movdir64b, waitpkg, cldemote, - ptwrite, avx512bf16, enqcmd, avx512vp2intersect, - serialize, tsxldtrk, NULL); + avx512bitalg, avx512vpopcntdq, movdiri, movdir64b, + waitpkg, cldemote, ptwrite, avx512bf16, enqcmd, + avx512vp2intersect, serialize, tsxldtrk, NULL); } done: -- 2.26.2
Re: [stage1][PATCH] Lower VEC_COND_EXPR into internal functions.
Hi.
Back to this I noticed that ppc64le target build is broken due to:
g++ -fno-PIE -c -g -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -fno-exceptions
-fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic
-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common
-DHAVE_CONFIG_H -I. -I. -I/home/marxin/Programming/gcc/gcc
-I/home/marxin/Programming/gcc/gcc/.
-I/home/marxin/Programming/gcc/gcc/../include
-I/home/marxin/Programming/gcc/gcc/../libcpp/include
-I/home/marxin/Programming/gcc/gcc/../libdecnumber
-I/home/marxin/Programming/gcc/gcc/../libdecnumber/dpd -I../libdecnumber
-I/home/marxin/Programming/gcc/gcc/../libbacktrace -o insn-emit.o -MT
insn-emit.o -MMD -MP -MF ./.deps/insn-emit.TPo insn-emit.c
/home/marxin/Programming/gcc/gcc/config/rs6000/vector.md:357:11: error:
vcondv4sfv4sf cannot FAIL
357 | FAIL;
| ^
/home/marxin/Programming/gcc/gcc/config/rs6000/vector.md:357:11: error:
vcondv2dfv2df cannot FAIL
357 | FAIL;
| ^
/home/marxin/Programming/gcc/gcc/config/rs6000/vector.md:374:11: error:
vcondv16qiv16qi cannot FAIL
374 | FAIL;
| ^
/home/marxin/Programming/gcc/gcc/config/rs6000/vector.md:374:11: error:
vcondv8hiv8hi cannot FAIL
374 | FAIL;
| ^
...
which is caused by the 4 added optabs:
+DEF_INTERNAL_OPTAB_FN (VCOND, 0, vcond, vec_cond)
+DEF_INTERNAL_OPTAB_FN (VCONDU, 0, vcondu, vec_condu)
+DEF_INTERNAL_OPTAB_FN (VCONDEQ, 0, vcondeq, vec_condeq)
+DEF_INTERNAL_OPTAB_FN (VCOND_MASK, 0, vcond_mask, vec_cond_mask)
looking at the generator:
Breakpoint 6, gen_expand (info=0x7fffe160) at
/home/marxin/Programming/gcc/gcc/genemit.c:516
516 if (find_optab (, XSTR (expand, 0)))
(gdb) bt
#0 emit_c_code (code=0x7fa0f0 "{\n if (rs6000_emit_vector_cond_expr (operands[0],
operands[1], operands[2],\n\t\t\t\toperands[3], operands[4], operands[5]))\nDONE;\n else\n
FAIL;\n}", can_fail_p=false, name=0x7fa190 "vcondv4sfv4sf")
at /home/marxin/Programming/gcc/gcc/genemit.c:306
#1 0x004039b5 in gen_expand (info=0x7fffe160) at
/home/marxin/Programming/gcc/gcc/genemit.c:522
#2 0x00404912 in main (argc=4, argv=0x7fffe288) at
/home/marxin/Programming/gcc/gcc/genemit.c:916
I get there due to:
B- │516 if (find_optab (, XSTR (expand, 0)))│
│517 { │
│518 gcc_assert (p.op < NUM_OPTABS); │
│519 if (nofail_optabs[p.op]) │
│520 can_fail_p = false; │
│521 } │
#define DEF_INTERNAL_OPTAB_FN(NAME, FLAGS, OPTAB, TYPE) \
nofail_optabs[OPTAB##_optab] = true;
#include "internal-fn.def"
Any hint what's bad? Note that x86_64-linux-gnu is fine.
Do I miss a target hook?
Martin
[PATCH] Fix a test-case warning.
Hi.
It fixes:
./gcc/xgcc -Bgcc
/home/marxin/Programming/gcc/gcc/testsuite/g++.target/i386/pr95229.C -c -O3
-march=znver1 -Werror -std=gnu++98
/home/marxin/Programming/gcc/gcc/testsuite/g++.target/i386/pr95229.C:13:3: error:
unnamed type with no linkage used to declare variable ‘ e’ with
linkage [-Werror]
13 | } e;
| ^
cc1plus: all warnings being treated as errors
Installed to master.
Martin
gcc/testsuite/ChangeLog:
2020-05-21 Martin Liska
PR target/95229
* g++.target/i386/pr95229.C: Fix
error: unnamed type with no linkage used
to declare variable ‘ e’ with linkage
with -std=gnu++98.
---
gcc/testsuite/g++.target/i386/pr95229.C | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/testsuite/g++.target/i386/pr95229.C b/gcc/testsuite/g++.target/i386/pr95229.C
index edf5aa4389e..98bdd57794c 100644
--- a/gcc/testsuite/g++.target/i386/pr95229.C
+++ b/gcc/testsuite/g++.target/i386/pr95229.C
@@ -7,7 +7,7 @@ struct a {
unsigned long long c;
};
-class {
+class my_class {
public:
a d;
} e;
Re: [PATCH] Extend std::copy/std::copy_n char* overload to deque iterator
On 07/05/20 09:12 +0200, François Dumont via Libstdc++ wrote:    This patch purpose is to make sure that existing std::copy/std::copy_n overloads for char* will also be used for std::deque iterators when dealing with istreambuf_iterator. It also make sure that it still works when _GLIBCXX_DEBUG is activated.    * include/bits/stl_algo.h (__copy_n_a): Move to ...    * include/bits/stl_algobase.h (__copy_n_a): ...here. Add __strict    parameter.    (__niter_base(const _Safe_iterator<_Ite, _Seq,    random_access_iterator_tag>&)): New declaration.    (__copy_move_a2(istreambuf_iterator<>, istreambuf_iterator<>,    _Deque_iterator<>)): New declaration.    (__copy_n_a(istreambuf_iterator<>, _Size, _Deque_iterator<>, bool)):    New declaration.    * include/bits/deque.tcc    (__copy_move_a2(istreambuf_iterator<>, istreambuf_iterator<>,    _Deque_iterator<>)): Add definition.    (__copy_n_a(istreambuf_iterator<>, _Size, _Deque_iterator<>, bool)):    Add definition.    * include/bits/streambuf_iterator.h    (__copy_n_a(istreambuf_iterator<>, _Size, _CharT*, bool)): Adapt    definition.    * include/debug/safe_iterator.tcc (__niter_base): Add definition.    * testsuite/25_algorithms/copy/streambuf_iterators/char/4.cc (test03):    New.    * testsuite/25_algorithms/copy/streambuf_iterators/char/debug/    deque_neg.cc: New.    * testsuite/25_algorithms/copy_n/debug/istreambuf_ite_deque_neg.cc:    New.    * testsuite/25_algorithms/copy_n/istreambuf_iterator/2.cc: New.    * testsuite/25_algorithms/copy_n/istreambuf_iterator/deque.cc: New. Already tested for a while on Linux x64 normal and debug modes but I am currently rebuilding everything and will commit only once all succeeded again. Ok ? François diff --git a/libstdc++-v3/include/bits/deque.tcc b/libstdc++-v3/include/bits/deque.tcc index e773f32b256..45207066c48 100644 --- a/libstdc++-v3/include/bits/deque.tcc +++ b/libstdc++-v3/include/bits/deque.tcc @@ -1065,6 +1065,57 @@ _GLIBCXX_END_NAMESPACE_CONTAINER return __result; } +#if __cplusplus >= 201103L Why is the optimization not done for C++03 mode? It looks like the uses of 'auto' can be reaplced easily, and __enable_if_t<> can be replaced with __gnu_cxx::__enable_if<>::__type.
Re: [preprocessor] a few cleanups in c-family
On 5/21/20 4:02 AM, Andreas Schwab wrote: On Mai 20 2020, Nathan Sidwell wrote: I'm reverting that change. It is not ready. The first map has a different string for the main file name, and we were relying on that not equalling the later ones via pointer comparison. I must have become confused over what tree I was testing. Sorry about that. What's up with gcc/testsuite/c-c++-common/cpp/cmd-1.c? aw crap. and man those were hard to delete. The commit hooks are FAR TOO PICKY NOW. nathan -- Nathan Sidwell
Re: [stage1][PATCH] Add gcc_assert that _options are not dirty modified.
PING^1 On 3/20/20 4:55 PM, Martin Liška wrote: Ok, it would be possible, but if you take a look at options-save.c there's no function that will leverage that. It's a generated code so I guess we can live with that?
Re: Avoid SCC hashing on unmergeable trees
On 5/20/20 1:49 PM, Jan Hubicka wrote: On related note, I remember us discussing that std compression has problem with bigger headers then zlib. Since we stream our header that says if section is compressed, I wonder if we could teach stream-out phase to skip compression if it is not benefical, so the size info is not duplicated? Hello. I've collected statistics for that on tramp3d (with -O2 -flto) and I see: sections: 3041, not beneficial: 16 before: 13804315, after: 4753009 can save: -128 (-0.00%) So there are only 16 sections that are bigger when compressed with ZSTD (including zstd header size). The benefit is negligible. Martin
[PATCH] libgcc: Move FEATURE_AVX512VP2INTERSECT after FEATURE_AVX512BF16
On Tue, May 19, 2020 at 2:38 PM Uros Bizjak wrote:
>
> On Tue, May 19, 2020 at 11:37 PM H.J. Lu wrote:
> >
> > Add FEATURE_AVX512VP2INTERSECT to libgcc so that enum processor_features
> > in libgcc matches enum processor_features in i386-builtins.c. Update
> > GFNI check to support processors with SSE and AVX versions of GFNI.
> >
> > PR target/95212
> > PR target/95220
> > * config/i386/cpuinfo.c (get_available_features): Fix
> > FEATURE_GFNI check. Also check FEATURE_AVX512VP2INTERSECT.
> > * config/i386/cpuinfo.h (processor_features): Add
> > FEATURE_AVX512VP2INTERSECT.
>
> OK for mainline and backports.
>
Move FEATURE_AVX512VP2INTERSECT after FEATURE_AVX512BF16 to avoid
changing libgcc ABI.
I am checking it into master and GCC 10 branch.
--
H.J.
From 00aa604bef585720c8d336108270259a0d4c2204 Mon Sep 17 00:00:00 2001
From: "H.J. Lu"
Date: Thu, 21 May 2020 04:17:06 -0700
Subject: [PATCH] libgcc: Move FEATURE_AVX512VP2INTERSECT after
FEATURE_AVX512BF16
Move FEATURE_AVX512VP2INTERSECT after FEATURE_AVX512BF16 to avoid
changing libgcc ABI.
gcc/
PR target/95212
* config/i386/i386-builtins.c (processor_features): Move
F_AVX512VP2INTERSECT after F_AVX512BF16.
(isa_names_table): Likewise.
libgcc/
PR target/95212
* config/i386/cpuinfo.h (processor_features): Move
FEATURE_AVX512VP2INTERSECT after FEATURE_AVX512BF16.
---
gcc/config/i386/i386-builtins.c | 6 +++---
libgcc/config/i386/cpuinfo.h| 4 ++--
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/gcc/config/i386/i386-builtins.c b/gcc/config/i386/i386-builtins.c
index 4b203635428..be3ed0158f2 100644
--- a/gcc/config/i386/i386-builtins.c
+++ b/gcc/config/i386/i386-builtins.c
@@ -1911,8 +1911,8 @@ enum processor_features
F_VPCLMULQDQ,
F_AVX512VNNI,
F_AVX512BITALG,
- F_AVX512VP2INTERSECT,
F_AVX512BF16,
+ F_AVX512VP2INTERSECT,
F_MAX
};
@@ -2062,8 +2062,8 @@ static const _isa_names_table isa_names_table[] =
{"vpclmulqdq", F_VPCLMULQDQ, P_ZERO},
{"avx512vnni", F_AVX512VNNI, P_ZERO},
{"avx512bitalg", F_AVX512BITALG, P_ZERO},
- {"avx512vp2intersect",F_AVX512VP2INTERSECT, P_ZERO},
- {"avx512bf16", F_AVX512BF16, P_ZERO}
+ {"avx512bf16", F_AVX512BF16, P_ZERO},
+ {"avx512vp2intersect",F_AVX512VP2INTERSECT, P_ZERO}
};
/* This parses the attribute arguments to target in DECL and determines
diff --git a/libgcc/config/i386/cpuinfo.h b/libgcc/config/i386/cpuinfo.h
index fd6d12a7d68..0f97510cde1 100644
--- a/libgcc/config/i386/cpuinfo.h
+++ b/libgcc/config/i386/cpuinfo.h
@@ -122,8 +122,8 @@ enum processor_features
FEATURE_VPCLMULQDQ,
FEATURE_AVX512VNNI,
FEATURE_AVX512BITALG,
- FEATURE_AVX512VP2INTERSECT,
- FEATURE_AVX512BF16
+ FEATURE_AVX512BF16,
+ FEATURE_AVX512VP2INTERSECT
};
extern struct __processor_model
--
2.26.2
Re: [PATCH] Implement no_stack_protect attribute.
On 5/18/20 10:37 PM, Martin Sebor wrote: I know there are some somewhat complex cases the attribute exclusion mechanism isn't general enough to handle but this seems simple enough that it should work. Unless I'm missing something that makes it not feasible I would suggest to use it. Hi Martin. Do we have a better place where we check for attribute collision? Martin
Re: [PATCH] Implement no_stack_protect attribute.
On 5/18/20 5:56 PM, Florian Weimer via Gcc-patches wrote: * Michael Matz: So does -fcf-protection. -fno-omit-frame-pointer does not work for me at all for some reason, the frame pointer is always missing? Not for me: I see. I didn't know that -fno-omit-frame-pointer only applies to non-leaf functions. For them, the behavior I see matches yours. Thanks, Florian I bet it's related to this issue https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92860#c4. The issue is about update of target options from optimization option and there's proper restore to the original state. Martin
Re: [PATCH][PR92658] Add missing vector truncmn2 expanders for avx512f
On Thu, May 21, 2020 at 7:35 AM Hongtao Liu wrote: > > On Wed, May 20, 2020 at 11:43 PM Uros Bizjak wrote: > > > > On Wed, May 20, 2020 at 10:35 AM Hongtao Liu wrote: > > > > > > Hi: > > > Bootstrap is ok, regression test on i386/x86-64 backend is ok. > > > > > > gcc/ChangeLog: > > > PR target/92658 > > > * config/i386/sse.md > > > (trunc2, truncv32hiv32qi2, > > > trunc2): New expander. > > > > > > gcc/testsuite/ChangeLog: > > > * gcc.target/i386/pr92658-avx512f.c: New test. > > > * gcc.target/i386/pr92658-avx512vl.c: Ditto. > > > * gcc.target/i386/pr92658-avx512bw-trunc.c: Ditto. > > > > There are more conversions to be added. There are: > > > > V2DImode to V2QImode, V2HImode, V2SImode > > V4DImode to V4QImode, V4HImode, V4SImode > > V8DImode to V8QImode, V8HImode, V8SImode > > > > V4SImode to V4QImode, V4HImode > > V8SImode to V8QImode, V8HImode > > V16SImode to V16QImode, V16HImode > > > > V8HImode to V8QImode > > V16HImode to V16QImode > > V32HImode to V32QImode > > > All of them are added > > Vectorization failure: (Add xfail in testcase for them since they need > generic part) > V2DImode to V2QImode, V2HImode > V4DImode to V4QImode, V4HImode > V8DImode to V8QImode > > V4SImode to V4QImode, V4HImode > V8SImode to V8QImode > > V8HImode to V8QImode > > Vectorization success: > V2DImode to V2SImode (under TARGET_MMX_WITH_SSE) > V4DImode to V4SImode > V8DImode to V8HImode, V8SImode > > V8SImode to V8HImode > V16SImode to V16QImode, V16HImode > > V32HImode to V32QImode > V16HImode to V16HImode. > > > > Uros. > > Update patch. > Regression test on i386/x86-64 backend is ok, bootstrap is ok. > > gcc/ChangeLog: > PR target/92658 > * config/i386/sse.md > (trunc2): New expander > (truncv32hiv32qi2): Ditto. > (trunc2): Ditto. > (trunc2): Ditto. > (trunc2): Ditto. > (truncv2div2si2): Ditto. > (truncv8div8qi2): Ditto. > (avx512f_v8div16qi2): Renaming > from *avx512f_v8div16qi2. > (avx512vl_v2div2si): Renaming > from *avx512vl_v2div2si2. > (avx512vl_v2qi2): Renaming > from *avx512vl_vqi2. > > gcc/testsuite/ChangeLog: > * gcc.target/i386/pr92658-avx512f.c: New test. > * gcc.target/i386/pr92658-avx512vl.c: Ditto. > * gcc.target/i386/pr92658-avx512bw-trunc.c: Ditto. + rtx op = simplify_subreg (V16QImode, operands[0], mode, 0); + operands[0] = op ? op : gen_rtx_SUBREG (V16QImode, operands[0], 0); You should use simplify_gen_subreg, without null op fixup: operands[0] = simplify_gen_subreg (V16QImode, operands[0], mode, 0); + "TARGET_MMX_WITH_SSE && TARGET_AVX512VL" Do you really need TARGET_MMX_WITH_SSE? Narrow modes are active even without this flag. Uros.
Optimize SCC streaming a bit
Hi,
this patch saves few bytes from SCC streaming. First we stream end markers
that are fully ignored at stream in.
Second I missed streaming of emtry_len in the previous change so it is
pointlessly streamed for LTO_trees. Moreover entry_len is almost always 1
(always during gcc bootstrap) and thus it makes sense to avoid stremaing it
in majority of cases.
ltobootstrapped/regtested x86_64-linux, OK?
gcc/ChangeLog:
2020-05-21 Jan Hubicka
* lto-streamer-in.c (lto_read_tree): Do not stream end markers.
(lto_input_scc): Optimize streaming of entry lengths.
* lto-streamer-out.c (lto_write_tree): Do not stream end markers
(DFS::DFS): Optimize stremaing of entry lengths
gcc/lto/ChangeLog:
2020-05-21 Jan Hubicka
* lto-common.c (compare_tree_sccs):
diff --git a/gcc/lto-streamer-in.c b/gcc/lto-streamer-in.c
index 85d0edf49a7..d0532c5ac51 100644
--- a/gcc/lto-streamer-in.c
+++ b/gcc/lto-streamer-in.c
@@ -1417,8 +1417,6 @@ lto_read_tree (class lto_input_block *ib, class data_in
*data_in,
lto_read_tree_1 (ib, data_in, result);
- /* end_marker = */ streamer_read_uchar (ib);
-
return result;
}
@@ -1431,12 +1429,18 @@ hashval_t
lto_input_scc (class lto_input_block *ib, class data_in *data_in,
unsigned *len, unsigned *entry_len, bool shared_scc)
{
- /* A blob of unnamed tree nodes, fill the cache from it and
- recurse. */
unsigned size = streamer_read_uhwi (ib);
- hashval_t scc_hash = shared_scc ? streamer_read_uhwi (ib) : 0;
+ hashval_t scc_hash = 0;
unsigned scc_entry_len = 1;
+ if (shared_scc)
+{
+ if (size & 1)
+ scc_entry_len = streamer_read_uhwi (ib);
+ size /= 2;
+ scc_hash = streamer_read_uhwi (ib);
+}
+
if (size == 1)
{
enum LTO_tags tag = streamer_read_record_start (ib);
@@ -1447,8 +1451,6 @@ lto_input_scc (class lto_input_block *ib, class data_in
*data_in,
unsigned int first = data_in->reader_cache->nodes.length ();
tree result;
- scc_entry_len = streamer_read_uhwi (ib);
-
/* Materialize size trees by reading their headers. */
for (unsigned i = 0; i < size; ++i)
{
@@ -1471,7 +1473,6 @@ lto_input_scc (class lto_input_block *ib, class data_in
*data_in,
result = streamer_tree_cache_get_tree (data_in->reader_cache,
first + i);
lto_read_tree_1 (ib, data_in, result);
- /* end_marker = */ streamer_read_uchar (ib);
}
}
diff --git a/gcc/lto-streamer-out.c b/gcc/lto-streamer-out.c
index 0e179468043..09a2e827f8e 100644
--- a/gcc/lto-streamer-out.c
+++ b/gcc/lto-streamer-out.c
@@ -473,9 +473,6 @@ lto_write_tree (struct output_block *ob, tree expr, bool
ref_p)
streamer_write_tree_header (ob, expr);
lto_write_tree_1 (ob, expr, ref_p);
-
- /* Mark the end of EXPR. */
- streamer_write_zero (ob);
}
/* Emit the physical representation of tree node EXPR to output block OB,
@@ -764,7 +761,12 @@ DFS::DFS (struct output_block *ob, tree expr, bool ref_p,
bool this_ref_p,
{
gcc_checking_assert (ob->section_type == LTO_section_decls);
streamer_write_record_start (ob, LTO_tree_scc);
- streamer_write_uhwi (ob, size);
+ /* In wast majority of cases scc_entry_len is 1 and size is small
+integer. Use extra bit of size to stream info about
+exceptions. */
+ streamer_write_uhwi (ob, size * 2 + (scc_entry_len != 1));
+ if (scc_entry_len != 1)
+ streamer_write_uhwi (ob, scc_entry_len);
streamer_write_uhwi (ob, scc_hash);
}
/* Non-trivial SCCs must be packed to trees blocks so forward
@@ -783,8 +785,6 @@ DFS::DFS (struct output_block *ob, tree expr, bool ref_p,
bool this_ref_p,
lto_output_tree_1 (ob, expr, scc_hash, ref_p, this_ref_p);
else
{
- /* Write the size of the SCC entry candidates. */
- streamer_write_uhwi (ob, scc_entry_len);
/* Write all headers and populate the streamer cache. */
for (unsigned i = 0; i < size; ++i)
@@ -807,12 +807,7 @@ DFS::DFS (struct output_block *ob, tree expr, bool ref_p,
bool this_ref_p,
/* Write the bitpacks and tree references. */
for (unsigned i = 0; i < size; ++i)
- {
- lto_write_tree_1 (ob, sccstack[first+i].t, ref_p);
-
- /* Mark the end of the tree. */
- streamer_write_zero (ob);
- }
+ lto_write_tree_1 (ob, sccstack[first+i].t, ref_p);
}
/* Finally truncate the vector. */
Fix hashing of prestreamed nodes
Hi,
this patch seems to solve basically all collisions while building cc1.
From:
[WPA] read 3312246 unshared trees
[WPA] read 1144381 mergeable SCCs of average size 4.833785
[WPA] 8843938 tree bodies read in total
[WPA] tree SCC table: size 524287, 197767 elements, collision ratio: 0.506446
[WPA] tree SCC max chain length 43 (size 1)
[WPA] Compared 946614 SCCs, 775077 collisions (0.818789)
to
[WPA] read 3314520 unshared trees
[WPA] read 1144763 mergeable SCCs of average size 4.835021
[WPA] 8849473 tree bodies read in total
[WPA] tree SCC table: size 524287, 200574 elements, collision ratio: 0.486418
[WPA] tree SCC max chain length 2 (size 1)
[WPA] Compared 944189 SCCs, 179 collisions (0.000190)
The problem is that preloaded nodes all have hash code 0 because
cache->nodes.length is not updated while streaming out.
I also added an arbitrary constant to avoid clash with constant of 0 used to
hash NULL pointers and 1 used to hash pointers inside SCC.
Bootstrapped/regtested x86_64-linux, comitted.
* tree-streamer.c (record_common_node): Fix hash value of pre-streamed
nodes.
diff --git a/gcc/tree-streamer.c b/gcc/tree-streamer.c
index f6181fafc4c..b0afa1dc6c0 100644
--- a/gcc/tree-streamer.c
+++ b/gcc/tree-streamer.c
@@ -299,10 +299,11 @@ record_common_node (struct streamer_tree_cache_d *cache,
tree node)
if (!node)
node = error_mark_node;
- /* ??? FIXME, devise a better hash value. But the hash needs to be equal
- for all frontend and lto1 invocations. So just use the position
- in the cache as hash value. */
- streamer_tree_cache_append (cache, node, cache->nodes.length ());
+ /* This hash needs to be equal for all frontend and lto1 invocations. So
+ just use the position in the cache as hash value.
+ Small integers are used by hash_tree to record positions within scc
+ hash. Values are not in same range. */
+ streamer_tree_cache_append (cache, node, cache->next_idx + 0xc001);
switch (TREE_CODE (node))
{
Re: [PATCH] Add outline-atomics to target attribute.
On 5/21/20 12:11 PM, Richard Sandiford wrote:
Yeah, agree it'd be worth having tests for both directions. The patch
itself looks good though -- thanks for doing this.
Thanks. There's a version with 2 new tests that I've just tested.
I'm going to install the patch for master. Is it also fine for all
active branches where you backported the atomics outlining?
Martin
>From 357a86fbf18ad511a72e6e9c703a6e0b0dd30ddf Mon Sep 17 00:00:00 2001
From: Martin Liska
Date: Thu, 21 May 2020 09:19:21 +0200
Subject: [PATCH] Add outline-atomics to target attribute.
gcc/ChangeLog:
2020-05-21 Martin Liska
* common/config/aarch64/aarch64-common.c (aarch64_handle_option):
Handle OPT_moutline_atomics.
* config/aarch64/aarch64.c: Add outline-atomics to
aarch64_attributes.
* doc/extend.texi: Document the newly added target attribute.
gcc/testsuite/ChangeLog:
2020-05-21 Martin Liska
* gcc.target/aarch64/target_attr_20.c: New test.
* gcc.target/aarch64/target_attr_21.c: New test.
---
gcc/common/config/aarch64/aarch64-common.c| 4 +++
gcc/config/aarch64/aarch64.c | 2 ++
gcc/doc/extend.texi | 6 +
.../gcc.target/aarch64/target_attr_20.c | 27 +++
.../gcc.target/aarch64/target_attr_21.c | 27 +++
5 files changed, 66 insertions(+)
create mode 100644 gcc/testsuite/gcc.target/aarch64/target_attr_20.c
create mode 100644 gcc/testsuite/gcc.target/aarch64/target_attr_21.c
diff --git a/gcc/common/config/aarch64/aarch64-common.c b/gcc/common/config/aarch64/aarch64-common.c
index 0bddcc8c3e9..51bd319d6d3 100644
--- a/gcc/common/config/aarch64/aarch64-common.c
+++ b/gcc/common/config/aarch64/aarch64-common.c
@@ -116,6 +116,10 @@ aarch64_handle_option (struct gcc_options *opts,
opts->x_flag_omit_leaf_frame_pointer = val;
return true;
+case OPT_moutline_atomics:
+ opts->x_aarch64_flag_outline_atomics = val;
+ return true;
+
default:
return true;
}
diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index 79c016f4dc3..78db0a56323 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -15266,6 +15266,8 @@ static const struct aarch64_attribute_info aarch64_attributes[] =
aarch64_handle_attr_branch_protection, OPT_mbranch_protection_ },
{ "sign-return-address", aarch64_attr_enum, false, NULL,
OPT_msign_return_address_ },
+ { "outline-atomics", aarch64_attr_bool, true, NULL,
+ OPT_moutline_atomics},
{ NULL, aarch64_attr_custom, false, NULL, OPT }
};
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index c80848e9061..a2ebef8cf8c 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -4066,6 +4066,12 @@ Select the function scope on which branch protection will be applied. The
behavior and permissible arguments are the same as for the command-line option
@option{-mbranch-protection=}. The default value is @code{none}.
+@item outline-atomics
+@cindex @code{outline-atomics} function attribute, AArch64
+Enable or disable calls to out-of-line helpers to implement atomic operations.
+This corresponds to the behavior of the command line options
+@option{-moutline-atomics} and @option{-mno-outline-atomics}.
+
@end table
The above target attributes can be specified as follows:
diff --git a/gcc/testsuite/gcc.target/aarch64/target_attr_20.c b/gcc/testsuite/gcc.target/aarch64/target_attr_20.c
new file mode 100644
index 000..509fb039e84
--- /dev/null
+++ b/gcc/testsuite/gcc.target/aarch64/target_attr_20.c
@@ -0,0 +1,27 @@
+/* { dg-do compile } */
+/* { dg-options "-march=armv8-a+nolse -moutline-atomics" } */
+
+int b, c, d, e, f, h;
+short g;
+int foo (int) __attribute__ ((__const__));
+
+__attribute__ ((target ("no-outline-atomics")))
+void
+bar (void)
+{
+ while (1)
+{
+ while (1)
+ {
+ __atomic_load_n (, 0);
+ if (foo (2))
+ __sync_val_compare_and_swap (, 0, f);
+ b = 1;
+ if (h == e)
+ break;
+ }
+ __sync_val_compare_and_swap (, -1, f);
+}
+}
+
+/* { dg-final { scan-assembler-not "bl.*__aarch64_cas2_acq_rel" } } */
diff --git a/gcc/testsuite/gcc.target/aarch64/target_attr_21.c b/gcc/testsuite/gcc.target/aarch64/target_attr_21.c
new file mode 100644
index 000..acace4c8f2a
--- /dev/null
+++ b/gcc/testsuite/gcc.target/aarch64/target_attr_21.c
@@ -0,0 +1,27 @@
+/* { dg-do compile } */
+/* { dg-options "-march=armv8-a+nolse -mno-outline-atomics" } */
+
+int b, c, d, e, f, h;
+short g;
+int foo (int) __attribute__ ((__const__));
+
+__attribute__ ((target ("outline-atomics")))
+void
+bar (void)
+{
+ while (1)
+{
+ while (1)
+ {
+ __atomic_load_n (, 0);
+ if (foo (2))
+ __sync_val_compare_and_swap (, 0, f);
+ b = 1;
+ if (h == e)
+ break;
+ }
+ __sync_val_compare_and_swap (, -1, f);
+}
+}
+
+/* { dg-final { scan-assembler-times "bl.*__aarch64_cas2_acq_rel" 1 } } */
--
2.26.2
Re: [PATCH] Add outline-atomics to target attribute.
Jakub Jelinek via Gcc-patches writes:
> On Thu, May 21, 2020 at 10:03:37AM +0200, Martin Liška wrote:
>> On 5/21/20 9:56 AM, Jakub Jelinek wrote:
>> > Can't it be __attribute__((target ("outline-atomics"))) instead?
>>
>> Ah sorry, I wan unclear.
>> It's support the this _target_ attribute which you mentioned.
>
> Ok, better, will defer review to target maintainers of course.
> But the above clearly shows you forgot to add testcase coverage,
> both that dg-options -moutline-atomics target "no-outline-atomics"
> routine with scan-assembler and the other way around.
Yeah, agree it'd be worth having tests for both directions. The patch
itself looks good though -- thanks for doing this.
Richard
Re: [PATCH] Implement no_stack_protect attribute.
On 5/18/20 1:49 PM, Richard Biener wrote: On Mon, May 18, 2020 at 1:10 PM Jakub Jelinek via Gcc-patches wrote: On Mon, May 18, 2020 at 01:03:40PM +0200, Jakub Jelinek wrote: The optimize attribute is used to specify that a function is to be compiled with different optimization options than specified on the command line. ``` It's pretty clear about the command line arguments (that are ignored). That is not clear at all. The difference is primarily in what the option string says in there. And if we decide we want to keep existing behavior (haven't checked if we actually behave that way yet), we should add some syntax that will allow ammending command line options rather than replacing it. Hello. Back to this, I must say that option handling is a complex thing in the GCC. We do behave this way - while we're running against the current gcc_options we call decode_options which first does default_options_optimization. So it behaves inconsistently with respect to options not explicitly listed in default_options_table. Yes, we basically build on top of the currently selection flags. We use default_options_table because any optimization level selection in an optimization attribute should efficiently enforce call of default_options_table. What about using them only in case one changes optimization level (patch)? Martin But I also think doing the whole processing as in decode_options is the only thing that's really tested. And a fix would be to not start from the current set of options but from a clean slate... The code clearly thinks we're doing incremental changes: /* Save current options. */ cl_optimization_save (_opts, _options); /* If we previously had some optimization options, use them as the default. */ if (old_opts) cl_optimization_restore (_options, TREE_OPTIMIZATION (old_opts)); /* Parse options, and update the vector. */ parse_optimize_options (args, true); DECL_FUNCTION_SPECIFIC_OPTIMIZATION (*node) = build_optimization_node (_options); /* Restore current options. */ cl_optimization_restore (_options, _opts); so for example you should see -fipa-pta preserved from the command-line while -fno-tree-pta would be overridden even if not mentioned explicitely in the optimize attribute. IMHO the current situation is far from useful... Richard. Could be say start the optimize attribute string with + or something similar. Does target attribute behave that way too? Jakub diff --git a/gcc/opts.c b/gcc/opts.c index ec3ca0720f9..8c39562c697 100644 --- a/gcc/opts.c +++ b/gcc/opts.c @@ -571,6 +571,7 @@ default_options_optimization (struct gcc_options *opts, unsigned int i; int opt2; bool openacc_mode = false; + bool opt_level_changed = false; /* Scan to see what optimization level has been specified. That will determine the default value of many flags. */ @@ -603,6 +604,7 @@ default_options_optimization (struct gcc_options *opts, opts->x_optimize_debug = 0; } } + opt_level_changed = true; break; case OPT_Os: @@ -612,6 +614,7 @@ default_options_optimization (struct gcc_options *opts, opts->x_optimize = 2; opts->x_optimize_fast = 0; opts->x_optimize_debug = 0; + opt_level_changed = true; break; case OPT_Ofast: @@ -620,6 +623,7 @@ default_options_optimization (struct gcc_options *opts, opts->x_optimize = 3; opts->x_optimize_fast = 1; opts->x_optimize_debug = 0; + opt_level_changed = true; break; case OPT_Og: @@ -628,6 +632,7 @@ default_options_optimization (struct gcc_options *opts, opts->x_optimize = 1; opts->x_optimize_fast = 0; opts->x_optimize_debug = 1; + opt_level_changed = true; break; case OPT_fopenacc: @@ -641,10 +646,11 @@ default_options_optimization (struct gcc_options *opts, } } - maybe_default_options (opts, opts_set, default_options_table, - opts->x_optimize, opts->x_optimize_size, - opts->x_optimize_fast, opts->x_optimize_debug, - lang_mask, handlers, loc, dc); + if (opt_level_changed) +maybe_default_options (opts, opts_set, default_options_table, + opts->x_optimize, opts->x_optimize_size, + opts->x_optimize_fast, opts->x_optimize_debug, + lang_mask, handlers, loc, dc); /* -O2 param settings. */ opt2 = (opts->x_optimize >= 2);
[PATCH] Prepare git_update_version.py for real usage.
Hi.
I've just installed changed that are prepared for script usage
at server.
Martin
contrib/ChangeLog:
2020-05-21 Martin Liska
* gcc-changelog/git_update_version.py: Prepare the script, the
only missing piece is pushing of the updated branches.
---
contrib/gcc-changelog/git_update_version.py | 17 -
1 file changed, 8 insertions(+), 9 deletions(-)
diff --git a/contrib/gcc-changelog/git_update_version.py b/contrib/gcc-changelog/git_update_version.py
index f38e011df45..ee3989beb27 100755
--- a/contrib/gcc-changelog/git_update_version.py
+++ b/contrib/gcc-changelog/git_update_version.py
@@ -24,8 +24,7 @@ from git import Repo
from git_repository import parse_git_revisions
-# TODO: remove sparta suffix
-current_timestamp = datetime.datetime.now().strftime('%Y%m%d sparta\n')
+current_timestamp = datetime.datetime.now().strftime('%Y%m%d\n')
def read_timestamp(path):
@@ -36,11 +35,9 @@ def prepend_to_changelog_files(repo, folder, git_commit):
if not git_commit.success:
for error in git_commit.errors:
print(error)
-# TODO: add error message
-return
+raise AssertionError()
for entry, output in git_commit.to_changelog_entries(use_commit_ts=True):
-# TODO
-full_path = os.path.join(folder, entry, 'ChangeLog.test')
+full_path = os.path.join(folder, entry, 'ChangeLog')
print('writting to %s' % full_path)
if os.path.exists(full_path):
content = open(full_path).read()
@@ -73,9 +70,10 @@ for ref in origin.refs:
branch = repo.branches[name]
else:
branch = repo.create_head(name, ref).set_tracking_branch(ref)
+print('=== Working on: %s ===' % branch, flush=True)
origin.pull(rebase=True)
branch.checkout()
-print('=== Working on: %s ===' % branch)
+print('branch pulled and checked out')
assert not repo.index.diff(None)
commit = branch.commit
commit_count = 1
@@ -90,9 +88,8 @@ for ref in origin.refs:
datestamp_path = os.path.join(args.git_path, 'gcc/DATESTAMP')
if read_timestamp(datestamp_path) != current_timestamp:
print('DATESTAMP will be changed:')
-# TODO: set strict=True after testing period
commits = parse_git_revisions(args.git_path, '%s..HEAD'
- % commit.hexsha, strict=False)
+ % commit.hexsha)
for git_commit in reversed(commits):
prepend_to_changelog_files(repo, args.git_path, git_commit)
# update timestamp
@@ -101,5 +98,7 @@ for ref in origin.refs:
repo.git.add(datestamp_path)
repo.index.commit('Daily bump.')
# TODO: push the repository
+# repo.git.push('origin', branch)
else:
print('DATESTAMP unchanged')
+print('branch is done\n', flush=True)
Re: [PATCH 1/2] rs6000: tune cunroll for simple loops at O2
Jan Hubicka writes: >> Segher Boessenkool writes: >> >> > On Wed, May 20, 2020 at 12:30:30PM +0200, Richard Biener wrote: >> >> I think this is the wrong way to approach this. You're doing too many >> >> things at once. Try to fix the powerpc regression with the extra >> >> flag_rtl_unroll_loops, that could be backported. Then you can >> >> Or flag_complete_unroll_loops(-fcomplete-unroll-loops) for GIMPLE >> cunroll? >> >> independently see whether enabling more unrolling at -O2 makes >> >> sense. Because currently we _do_ unroll at -O2 when it does >> >> not increase size. Its just your patches make this as aggressive >> >> as -O3. >> >> I'm also thinking about enabling more cunroll at -O2 even with some size >> increasing. Full cunroll enablement make it like -O3. As some >> discussion in PRs (e.g. PR88760), small/simple loops unrolling may be in >> favor of some platforms (but not for all platforms, like x86_64?). This >> would make us to have target specified hook. Or do some generic >> setting: accept to unroll/peel limit times if the loop body is simple >> and small, together with target specific hook. > > We now have --params that can be tuned differently for -O2 and -O3 so > looking into cunroll was one of my todo for GCC 10 -O2 retuning but i did > not get any very conclusive benchmark results outside SPEC. > I planned to return to it next stage1, so it may be good time. > Do you have any benchmarks on ppc? 541.leela_r, 548.exchange2_r and 557.xz_r from SPEC2017 are visbily affected by cunroll. They can be used to tune cunroll, I think. > Of couse there is no need to keep same defaults for all targets, but in > general having target specific defaults increases number of knobs we > need to check and keep up to date. Thanks, Jiufu > > Honza >> >> Any comments? Thanks! >> Jiufu >> >> > >> > Just do a separate flag (and option) for cunroll, instead? >> > >> > The RTL unroller is *the* unroller, and has been since forever. >> > >> > >> > Segher
Re: [PATCH PR95254] aarch64: gcc generate inefficient code with fixed sve vector length
"Yangfei (Felix)" writes:
> Hi,
>
> Notice a tiny SVE-related performance issue:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95254
>
> For the given test case, SLP succeeds with VNx8HImode with or without
> option -msve-vector-bits=256.
> The root cause for the difference is that we choose a different mode in
> aarch64_vectorize_related_mode under -msve-vector-bits=256: VNx2HImode
> instead of V4HImode.
> Then in the final tree ssa forwprop pass, we need to do a VIEW_CONVERT from
> V4HImode to VNx2HImode.
>
> PATCH catch and simplify the pattern in aarch64_expand_sve_mem_move,
> emitting a mov pattern of V4HImode instead.
> I am assuming endianness does not make a difference here considering this
> simplification.
> Bootstrap and tested on aarch64-linux-gnu. Comments?
I think we should try to catch this at the gimple level, possibly
during SLP itself. Although the patch handles the case in which
the V4HI is stored directly to memory, I assume it won't help
if the code instead does:
for (i = 0; i < 4; i++)
b[i] = u.a[i] + 1;
targetm.can_change_mode_class (..., ALL_REGS) would be a good
indicator of whether the needed VIEW_CONVERT_EXPR is cheap or expensive.
I agree it might still be worth handling this in the move patterns too.
It feels like a target-independent optimisation though, and for example
should also apply to V4HI moves involving subregs of VNx2HIs.
So I think it would be worth trying to do this in emit_move_insn.
In principle it would be useful for:
// M1 and M2 equal size, !targetm.can_change_mode_class (M1, M2, ALL_REGS)
(set (subreg:M1 (reg:M2 ...)) (subreg:M1 (reg:M2 ...)))
(set (subreg:M1 (reg:M2 ...)) (mem:M1 ADDR))
(set (mem:M1 ADDR) (subreg:M1 (reg:M2 ...)))
(set (subreg:M1 (reg:M2 ...)) (constant C))
It would be nice if we could do this even without the can_change_mode_class
condition, provided that it doesn't turn valid M1 constants or MEMs into
invalid M2 ones (or at least, M2 ones that need to be validated).
Unfortunately, going that far is likely to interfere with target-specific
choices, so it's probably too dangerous.
With the can_change_mode_class condition it should be fine though,
since it's avoiding an implicit round trip through memory. The change
should be a win even if the MEMs or constants need legitimising for M2.
> [...]
> + if (inner != NULL_RTX
> + && aarch64_classify_vector_mode (inner_mode) == VEC_ADVSIMD
> + && GET_MODE_INNER (mode) == GET_MODE_INNER (inner_mode)
> + && known_eq (GET_MODE_SIZE (mode), GET_MODE_SIZE (inner_mode))
> + && GET_MODE_BITSIZE (inner_mode).to_constant () <= alignment)
> +{
> + rtx addr, mem;
> + if (MEM_P (src))
> + {
> + addr = XEXP (src, 0);
> + mem = gen_rtx_MEM (inner_mode, addr);
> + emit_move_insn (inner, mem);
> + }
> + else
> + {
> + addr = XEXP (dest, 0);
> + mem = gen_rtx_MEM (inner_mode, addr);
> + emit_move_insn (mem, inner);
gen_rtx_MEM shouldn't be used to create new versions of existing MEMs,
since it drops all the attributes. It's better to use something like
adjust_address instead. That will also take care of making sure that
the address is valid for the new mode.
Thanks,
Richard
Re: [PATCH] Support DR entries for gcc-changelog.
On 5/21/20 10:49 AM, Jakub Jelinek wrote:
On Thu, May 21, 2020 at 10:23:38AM +0200, Martin Liška wrote:
Hi.
The patch understand DR entries in git commit messages and
preserve them for ChangeLog entries.
Do you handle other free-style comments above the commit?
No. Note that the PR (and DR now) are markers that identify start of
ChangeLog section in git commit message
I mean, especially in gcc/cp/ Jason, Marek and others use something like:
r11-292-g52c5933f5838adb7bf6035e648b770b4958d137f
Resolve C++20 NB comment CA104
etc.?
Does it work only when one uses the email line in the commit message,
not at all or works fine even without that?
Can you be please more concrete about this?
I've made a quick analysis of cp/ChangeLog entries and I see these
interesting beginnings:
Resolve C++20 NB comment CA104
CWG 2235
Implement P2092R0, Disambiguating Nested-Requirements
P1937R2 - Fixing inconsistencies between const{expr,eval} functions
P1937R2 - Fixing inconsistencies between const{expr,eval} functions
P0780R2: Resolve lambda init-capture pack grammar.
Implement P1946R0, Allow defaulting comparisons by value.
Implement D1957R0, T* to bool should be considered narrowing.
Implement D1959R0, remove weak_equality and strong_equality.
Implement D1907R1 "structural type".
Implement P1286R2, Contra CWG1778
Implement p1301 [[nodiscard("should have a reason")]] + p1771 DR
P1091R3 - Extending structured bindings to be more like var decls
P1381R1 - Reference capture of structured bindings
CWG 2094 - volatile scalars are trivially copyable.
CWG 2096 - constraints on literal unions.
Implement P0634R3, Down with typename!
Implement P1094R2, Nested inline namespaces.
Implement P0479R5, [[likely]] and [[unlikely]].
Remove ovl_used, it is no longer needed
P1236R1 - Signed integers are two's complement
Implement P0315R4, Lambdas in unevaluated contexts.
Implement P0722R3, destroying operator delete.
Implement P0780R2, pack expansion in lambda init-capture.
Implement UDL changes from P0732R2.
Implement P0732R2, class types in non-type template parameters.
Implement P0846R0, ADL and function templates.
Implement P0892R2, explicit(bool).
Implement P0840, language support for empty objects.
Add -Wclass-conversion.
P1064R0 - Allowing Virtual Function Calls in Constant Expressions
P0806R2 - Deprecate implicit capture of this via [=]
P0595R1 - is_constant_evaluated
P1008R1 - prohibit aggregates with user-declared constructors
I'm open for supporting more of these, but I would like to keep it simple as
possible.
Martin
Jakub
Re: [PATCH] libgfortran: Use __builtin_cpu_is/__builtin_cpu_supports
Am 21.05.20 um 07:53 schrieb H.J. Lu via Fortran: * m4/matmul.m4: Don't include . Use __builtin_cpu_is/__builtin_cpu_supports * generated/matmul_c10.c: Regenerated. * generated/matmul_c16.c: Likewise. * generated/matmul_c4.c: Likewise. * generated/matmul_c8.c: Likewise. * generated/matmul_i1.c: Likewise. * generated/matmul_i16.c: Likewise. * generated/matmul_i2.c: Likewise. * generated/matmul_i4.c: Likewise. * generated/matmul_i8.c: Likewise. * generated/matmul_r10.c: Likewise. * generated/matmul_r16.c: Likewise. * generated/matmul_r4.c: Likewise. * generated/matmul_r8.c: Likewise. OK for trunk. Regards Thomas
Re: [PATCH] Support DR entries for gcc-changelog.
On Thu, May 21, 2020 at 10:23:38AM +0200, Martin Liška wrote: > Hi. > > The patch understand DR entries in git commit messages and > preserve them for ChangeLog entries. Do you handle other free-style comments above the commit? I mean, especially in gcc/cp/ Jason, Marek and others use something like: r11-292-g52c5933f5838adb7bf6035e648b770b4958d137f Resolve C++20 NB comment CA104 etc.? Does it work only when one uses the email line in the commit message, not at all or works fine even without that? Jakub
Re: [PATCH] Add outline-atomics to target attribute.
On Thu, May 21, 2020 at 10:03:37AM +0200, Martin Liška wrote:
> On 5/21/20 9:56 AM, Jakub Jelinek wrote:
> > Can't it be __attribute__((target ("outline-atomics"))) instead?
>
> Ah sorry, I wan unclear.
> It's support the this _target_ attribute which you mentioned.
Ok, better, will defer review to target maintainers of course.
But the above clearly shows you forgot to add testcase coverage,
both that dg-options -moutline-atomics target "no-outline-atomics"
routine with scan-assembler and the other way around.
Jakub
Re: [PATCH v2] Add -fuse-ld= to specify an arbitrary executable as the linker
On 5/21/20 1:52 AM, Fangrui Song wrote: The above issues motivated me to touch this line in PATCH v2. Dropped in PATCH v2. Thank you for the updated patch. The patch is fine except coding style issues: $ ./contrib/check_GNU_style.py /tmp/0001-Add-fuse-ld-to-specify-an-arbitrary-executable-as-th.patch === ERROR type #1: blocks of 8 spaces should be replaced with tabs (4 error(s)) === gcc/collect2.c:1135:0:ld_file_name = find_a_file(, ld_suffixes[selected_linker], X_OK); gcc/collect2.c:1137:0: for `ld' (if native linking) or `TARGET-ld' (if cross). */ gcc/collect2.c:1139:0:ld_file_name = gcc/collect2.c:1140:0:find_a_file(, full_ld_suffixes[selected_linker], X_OK); === ERROR type #2: there should be exactly one space between function name and parenthesis (2 error(s)) === gcc/collect2.c:1135:34:ld_file_name = find_a_file(, ld_suffixes[selected_linker], X_OK); gcc/collect2.c:1140:23:find_a_file(, full_ld_suffixes[selected_linker], X_OK); === ERROR type #3: trailing operator (1 error(s)) === gcc/collect2.c:1139:21:ld_file_name = Note that I can't approve the patch, please wait for a reviewer that can approve it. Martin
[PATCH] Support DR entries for gcc-changelog.
Hi.
The patch understand DR entries in git commit messages and
preserve them for ChangeLog entries.
Installed to master.
Martin
contrib/ChangeLog:
2020-05-21 Martin Liska
* gcc-changelog/git_commit.py: Support DR entries/
* gcc-changelog/test_email.py: New test for it.
* gcc-changelog/test_patches.txt: New patch for it.
---
contrib/gcc-changelog/git_commit.py| 5 -
contrib/gcc-changelog/test_email.py| 4
contrib/gcc-changelog/test_patches.txt | 27 ++
3 files changed, 35 insertions(+), 1 deletion(-)
diff --git a/contrib/gcc-changelog/git_commit.py b/contrib/gcc-changelog/git_commit.py
index 8c347d1c421..e22d3a2d6f0 100755
--- a/contrib/gcc-changelog/git_commit.py
+++ b/contrib/gcc-changelog/git_commit.py
@@ -145,6 +145,7 @@ author_line_regex = \
additional_author_regex = re.compile(r'^\t(?P\ *)?(?P.* <.*>)')
changelog_regex = re.compile(r'^([a-z0-9+-/]*)/ChangeLog:?')
pr_regex = re.compile(r'\tPR (?P[a-z+-]+\/)?([0-9]+)$')
+dr_regex = re.compile(r'\tDR ([0-9]+)$')
star_prefix_regex = re.compile(r'\t\*(?P\ *)(?P.*)')
LINE_LIMIT = 100
@@ -297,7 +298,7 @@ class GitCommit:
continue
if (changelog_regex.match(b) or self.find_changelog_location(b)
or star_prefix_regex.match(b) or pr_regex.match(b)
-or author_line_regex.match(b)):
+or dr_regex.match(b) or author_line_regex.match(b)):
self.changes = body[i:]
return
self.errors.append(Error('cannot find a ChangeLog location in '
@@ -350,6 +351,8 @@ class GitCommit:
continue
else:
pr_line = line.lstrip()
+elif dr_regex.match(line):
+pr_line = line.lstrip()
lowered_line = line.lower()
if lowered_line.startswith(CO_AUTHORED_BY_PREFIX):
diff --git a/contrib/gcc-changelog/test_email.py b/contrib/gcc-changelog/test_email.py
index ce69c64c79e..d522e6ef7e3 100755
--- a/contrib/gcc-changelog/test_email.py
+++ b/contrib/gcc-changelog/test_email.py
@@ -272,3 +272,7 @@ class TestGccChangelog(unittest.TestCase):
email = self.from_patch_glob('0001-Fortran-ProcPtr-function.patch')
assert not email.errors
assert len(email.changelog_entries[0].author_lines) == 1
+
+def test_dr_entry(self):
+email = self.from_patch_glob('0001-c-C-20-DR-2237.patch')
+assert email.changelog_entries[0].prs == ['DR 2237']
diff --git a/contrib/gcc-changelog/test_patches.txt b/contrib/gcc-changelog/test_patches.txt
index d80cfc3a0c8..3445c3d9f11 100644
--- a/contrib/gcc-changelog/test_patches.txt
+++ b/contrib/gcc-changelog/test_patches.txt
@@ -2541,3 +2541,30 @@ index 000..ecb0a43929f
--
2.26.2
+=== 0001-c-C-20-DR-2237.patch ===
+From 4b38d56dbac6742b038551a36ec80200313123a1 Mon Sep 17 00:00:00 2001
+From: Marek Polacek
+Date: Sat, 4 Apr 2020 18:09:53 -0400
+Subject: [PATCH] c++: C++20 DR 2237, disallow simple-template-id in cdtor.
+
+This patch implements DR 2237 which says that a simple-template-id is
+no longer valid as the declarator-id of a constructor or destructor;
+see [diff.cpp17.class]#2. It is not explicitly stated but out-of-line
+destructors with a simple-template-id are also meant to be ill-formed
+now. (Out-of-line constructors like that are invalid since DR1435 I
+think.) This change only applies to C++20; it is not a DR against C++17.
+
+I'm not crazy about the diagnostic in constructors but ISTM that
+cp_parser_constructor_declarator_p shouldn't print errors.
+
+ DR 2237
+ * parser.c (cp_parser_unqualified_id): Reject simple-template-id as
+ the declarator-id of a destructor.
+---
+diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
+index a6a5d975af3..a8082d39aca 100644
+--- a/gcc/cp/parser.c
b/gcc/cp/parser.c
+@@ -1 +1,2 @@
+
++
Re: New mklog script
Hello Martin. Can you please compare the current mklog.py. Is there anything you miss compared to your current script? Thanks, Martin
[PATCH] mklog: support parsing of DR.
Hi.
Let's support automatic detection of DRs from test-suite, similarly
what we do for PR entries.
Installed.
Martin
contrib/ChangeLog:
2020-05-21 Martin Liska
* mklog.py: Support DR parsing.
* test_mklog.py: New test for DR parsing.
---
contrib/mklog.py | 9 -
contrib/test_mklog.py | 39 +++
2 files changed, 47 insertions(+), 1 deletion(-)
diff --git a/contrib/mklog.py b/contrib/mklog.py
index b27fad0ca2e..7a19b5d0949 100755
--- a/contrib/mklog.py
+++ b/contrib/mklog.py
@@ -36,6 +36,7 @@ import requests
from unidiff import PatchSet
pr_regex = re.compile(r'(\/(\/|\*)|[Cc*!])\s+(?PPR [a-z+-]+\/[0-9]+)')
+dr_regex = re.compile(r'(\/(\/|\*)|[Cc*!])\s+(?PDR [0-9]+)')
identifier_regex = re.compile(r'^([a-zA-Z0-9_#].*)')
comment_regex = re.compile(r'^\/\*')
struct_regex = re.compile(r'^(class|struct|union|enum)\s+'
@@ -142,7 +143,13 @@ def generate_changelog(data, no_functions=False, fill_pr_titles=False):
if pr not in prs:
prs.append(pr)
else:
-break
+m = dr_regex.search(line.value)
+if m:
+dr = m.group('dr')
+if dr not in prs:
+prs.append(dr)
+else:
+break
if fill_pr_titles:
out += get_pr_titles(prs)
diff --git a/contrib/test_mklog.py b/contrib/test_mklog.py
index 774b6ea62d0..ef7f2b1a594 100755
--- a/contrib/test_mklog.py
+++ b/contrib/test_mklog.py
@@ -344,6 +344,41 @@ gcc/ChangeLog:
'''
+PATCH7 = '''\
+diff --git a/gcc/testsuite/g++.dg/DRs/dr2237.C b/gcc/testsuite/g++.dg/DRs/dr2237.C
+new file mode 100644
+index 000..f3d6d11e61e
+--- /dev/null
b/gcc/testsuite/g++.dg/DRs/dr2237.C
+@@ -0,0 +1,18 @@
++// DR 2237 - Can a template-id name a constructor?
++
++template
++struct X {
++ X(); // { dg-error "expected" "" { target c++20 } }
++ X(int); // OK, injected-class-name used
++ ~X(); // { dg-error "template-id not allowed for destructor" "" { target c++20 } }
++};
++
++// ill-formed since DR1435
++template X::X() {} // { dg-error "names the constructor|as no template constructors" }
++template X::~X() {} // { dg-error "template-id not allowed for destructor" "" { target c++20 } }
++
++struct Q {
++ // ill-formed since DR1435
++ template friend X::X(); // { dg-error "names the constructor|as no template constructors" }
++ template friend X::~X(); // { dg-error "template-id not allowed for destructor" "" { target c++20 } }
++};
+'''
+
+EXPECTED7 = '''\
+gcc/testsuite/ChangeLog:
+
+ DR 2237
+ * g++.dg/DRs/dr2237.C: New test.
+
+'''
+
class TestMklog(unittest.TestCase):
def test_macro_definition(self):
changelog = generate_changelog(PATCH1)
@@ -372,3 +407,7 @@ class TestMklog(unittest.TestCase):
def test_gty_in_struct(self):
changelog = generate_changelog(PATCH6, fill_pr_titles=True)
assert changelog == EXPECTED6
+
+def test_dr_detection_in_test_case(self):
+changelog = generate_changelog(PATCH7)
+assert changelog == EXPECTED7
[PATCH PR95254] aarch64: gcc generate inefficient code with fixed sve vector length
Hi, Notice a tiny SVE-related performance issue: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95254 For the given test case, SLP succeeds with VNx8HImode with or without option -msve-vector-bits=256. The root cause for the difference is that we choose a different mode in aarch64_vectorize_related_mode under -msve-vector-bits=256: VNx2HImode instead of V4HImode. Then in the final tree ssa forwprop pass, we need to do a VIEW_CONVERT from V4HImode to VNx2HImode. PATCH catch and simplify the pattern in aarch64_expand_sve_mem_move, emitting a mov pattern of V4HImode instead. I am assuming endianness does not make a difference here considering this simplification. Bootstrap and tested on aarch64-linux-gnu. Comments? Thanks, Felix pr95254-v1.diff Description: pr95254-v1.diff
Re: [PATCH] Add outline-atomics to target attribute.
On 5/21/20 9:56 AM, Jakub Jelinek wrote:
Can't it be __attribute__((target ("outline-atomics"))) instead?
Ah sorry, I wan unclear.
It's support the this _target_ attribute which you mentioned.
Martin
Re: [PATCH 1/2] rs6000: tune cunroll for simple loops at O2
> Segher Boessenkool writes: > > > On Wed, May 20, 2020 at 12:30:30PM +0200, Richard Biener wrote: > >> I think this is the wrong way to approach this. You're doing too many > >> things at once. Try to fix the powerpc regression with the extra > >> flag_rtl_unroll_loops, that could be backported. Then you can > > Or flag_complete_unroll_loops(-fcomplete-unroll-loops) for GIMPLE > cunroll? > >> independently see whether enabling more unrolling at -O2 makes > >> sense. Because currently we _do_ unroll at -O2 when it does > >> not increase size. Its just your patches make this as aggressive > >> as -O3. > > I'm also thinking about enabling more cunroll at -O2 even with some size > increasing. Full cunroll enablement make it like -O3. As some > discussion in PRs (e.g. PR88760), small/simple loops unrolling may be in > favor of some platforms (but not for all platforms, like x86_64?). This > would make us to have target specified hook. Or do some generic > setting: accept to unroll/peel limit times if the loop body is simple > and small, together with target specific hook. We now have --params that can be tuned differently for -O2 and -O3 so looking into cunroll was one of my todo for GCC 10 -O2 retuning but i did not get any very conclusive benchmark results outside SPEC. I planned to return to it next stage1, so it may be good time. Do you have any benchmarks on ppc? Of couse there is no need to keep same defaults for all targets, but in general having target specific defaults increases number of knobs we need to check and keep up to date. Honza > > Any comments? Thanks! > Jiufu > > > > > Just do a separate flag (and option) for cunroll, instead? > > > > The RTL unroller is *the* unroller, and has been since forever. > > > > > > Segher
Re: [preprocessor] a few cleanups in c-family
On Mai 20 2020, Nathan Sidwell wrote: > I'm reverting that change. It is not ready. The first map has a > different string for the main file name, and we were relying on that not > equalling the later ones via pointer comparison. > > I must have become confused over what tree I was testing. Sorry about that. What's up with gcc/testsuite/c-c++-common/cpp/cmd-1.c? Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
Re: [PATCH] Add outline-atomics to target attribute.
On Thu, May 21, 2020 at 09:23:47AM +0200, Martin Liška wrote:
> As mentioned in the ovmf project [1], they would like to have a control
> over the -mno-outline-atomics via a function attribute. They struggle
> with configure detection and this can help them to disable the outlining.
>
> Would it be possible to add the attribute?
Can't it be __attribute__((target ("outline-atomics"))) instead?
I'm not a fan of adding new attributes that just stand for enable this or
disable this command line option for a particular function, we have
target and optimize attributes for that.
Jakub
[PATCH] Add outline-atomics to target attribute.
Hi.
As mentioned in the ovmf project [1], they would like to have a control
over the -mno-outline-atomics via a function attribute. They struggle
with configure detection and this can help them to disable the outlining.
Would it be possible to add the attribute?
Thanks,
Martin
[1] https://bugzilla.tianocore.org/show_bug.cgi?id=2723
gcc/ChangeLog:
2020-05-21 Martin Liska
* common/config/aarch64/aarch64-common.c (aarch64_handle_option):
Handle OPT_moutline_atomics.
* config/aarch64/aarch64.c: Add outline-atomics to
aarch64_attributes.
* doc/extend.texi: Document the newly added target attribute.
---
gcc/common/config/aarch64/aarch64-common.c | 4
gcc/config/aarch64/aarch64.c | 2 ++
gcc/doc/extend.texi| 6 ++
3 files changed, 12 insertions(+)
diff --git a/gcc/common/config/aarch64/aarch64-common.c b/gcc/common/config/aarch64/aarch64-common.c
index 0bddcc8c3e9..51bd319d6d3 100644
--- a/gcc/common/config/aarch64/aarch64-common.c
+++ b/gcc/common/config/aarch64/aarch64-common.c
@@ -116,6 +116,10 @@ aarch64_handle_option (struct gcc_options *opts,
opts->x_flag_omit_leaf_frame_pointer = val;
return true;
+case OPT_moutline_atomics:
+ opts->x_aarch64_flag_outline_atomics = val;
+ return true;
+
default:
return true;
}
diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index 79c016f4dc3..78db0a56323 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -15266,6 +15266,8 @@ static const struct aarch64_attribute_info aarch64_attributes[] =
aarch64_handle_attr_branch_protection, OPT_mbranch_protection_ },
{ "sign-return-address", aarch64_attr_enum, false, NULL,
OPT_msign_return_address_ },
+ { "outline-atomics", aarch64_attr_bool, true, NULL,
+ OPT_moutline_atomics},
{ NULL, aarch64_attr_custom, false, NULL, OPT }
};
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index c80848e9061..a2ebef8cf8c 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -4066,6 +4066,12 @@ Select the function scope on which branch protection will be applied. The
behavior and permissible arguments are the same as for the command-line option
@option{-mbranch-protection=}. The default value is @code{none}.
+@item outline-atomics
+@cindex @code{outline-atomics} function attribute, AArch64
+Enable or disable calls to out-of-line helpers to implement atomic operations.
+This corresponds to the behavior of the command line options
+@option{-moutline-atomics} and @option{-mno-outline-atomics}.
+
@end table
The above target attributes can be specified as follows:
[committed] libstdc++: Avoid constraint recursion with iterator_traits (PR 93983)
Checking whether a filesystem::path constructor argument is an iterator
requires instantiating std::iterator_traits. In C++20 that checks for
satisfaction of std::iterator_traits constraints, which checks if the
type is copyable, which can end up recursing back to the path
constructor. The fix in LWG 3420 is to reorder the cpp17-iterator
concept's constraints to check if the type looks vaguely like an
iterator before checking copyable. That avoids the recursion for types
which definitely aren't iterators, but isn't foolproof.
PR libstdc++/93983
* include/bits/iterator_concepts.h (__detail::__cpp17_iterator):
Reorder constraints to avoid recursion when constructors use
iterator_traits (LWG 3420).
* testsuite/24_iterators/customization_points/lwg3420.cc: New test.
Tested powerpc64le-linux, committed to master.
This needs to be backported to gcc-10 too.
commit f094665d465cdf8903797cc58bea13007e588616
Author: Jonathan Wakely
Date: Thu May 21 07:32:15 2020 +0100
libstdc++: Avoid constraint recursion with iterator_traits (PR 93983)
Checking whether a filesystem::path constructor argument is an iterator
requires instantiating std::iterator_traits. In C++20 that checks for
satisfaction of std::iterator_traits constraints, which checks if the
type is copyable, which can end up recursing back to the path
constructor. The fix in LWG 3420 is to reorder the cpp17-iterator
concept's constraints to check if the type looks vaguely like an
iterator before checking copyable. That avoids the recursion for types
which definitely aren't iterators, but isn't foolproof.
PR libstdc++/93983
* include/bits/iterator_concepts.h (__detail::__cpp17_iterator):
Reorder constraints to avoid recursion when constructors use
iterator_traits (LWG 3420).
* testsuite/24_iterators/customization_points/lwg3420.cc: New test.
diff --git a/libstdc++-v3/include/bits/iterator_concepts.h
b/libstdc++-v3/include/bits/iterator_concepts.h
index e221ec70367..31b58408fe9 100644
--- a/libstdc++-v3/include/bits/iterator_concepts.h
+++ b/libstdc++-v3/include/bits/iterator_concepts.h
@@ -249,14 +249,15 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
namespace __detail
{
+// _GLIBCXX_RESOLVE_LIB_DEFECTS
+// 3420. cpp17-iterator should check [type] looks like an iterator first
template
- concept __cpp17_iterator = copyable<_Iter>
- && requires(_Iter __it)
+ concept __cpp17_iterator = requires(_Iter __it)
{
{ *__it } -> __can_reference;
{ ++__it } -> same_as<_Iter&>;
{ *__it++ } -> __can_reference;
- };
+ } && copyable<_Iter>;
template
concept __cpp17_input_iterator = __cpp17_iterator<_Iter>
@@ -269,7 +270,8 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
typename indirectly_readable_traits<_Iter>::value_type&>;
typename common_reference_t::value_type&>;
- requires signed_integral::difference_type>;
+ requires signed_integral<
+ typename incrementable_traits<_Iter>::difference_type>;
};
template
diff --git
a/libstdc++-v3/testsuite/24_iterators/customization_points/lwg3420.cc
b/libstdc++-v3/testsuite/24_iterators/customization_points/lwg3420.cc
new file mode 100644
index 000..72289a995fc
--- /dev/null
+++ b/libstdc++-v3/testsuite/24_iterators/customization_points/lwg3420.cc
@@ -0,0 +1,43 @@
+// Copyright (C) 2020 Free Software Foundation, Inc.
+//
+// This file is part of the GNU ISO C++ Library. This library is free
+// software; you can redistribute it and/or modify it under the
+// terms of the GNU General Public License as published by the
+// Free Software Foundation; either version 3, or (at your option)
+// any later version.
+
+// This library is distributed in the hope that it will be useful,
+// but WITHOUT ANY WARRANTY; without even the implied warranty of
+// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+// GNU General Public License for more details.
+
+// You should have received a copy of the GNU General Public License along
+// with this library; see the file COPYING3. If not see
+//
