[PATCH][wwwdocs] Add -moutline-atomics for AArch64 on gcc-9 and gcc-8
Add the backported functionality of -moutline-atomics for AArch64 to the gcc-9 and gcc-8 changes.html Validates. Is this OK? diff --git a/htdocs/gcc-8/changes.html b/htdocs/gcc-8/changes.html index 83dd1bc010a6e4debb76790b3fe62275bf0e0657..83e57db181294110f71a5d59960fb4d3fed7be98 100644 --- a/htdocs/gcc-8/changes.html +++ b/htdocs/gcc-8/changes.html @@ -1394,5 +1394,22 @@ known to be fixed in the 8.4 release. This list might not be complete (that is, it is possible that some PRs that have been fixed are not listed here). + +GCC 8.5 + + Target Specific Changes + +AArch64 + + + The option -moutline-atomics has been added to aid + deployment of the Large System Extensions (LSE) on GNU/Linux systems built + with a baseline architecture targeting Armv8-A. When the option is + specified code is emitted to detect the presence of LSE instructions at + runtime and use them for standard atomic operations. + For more information please refer to the documentation. + + + diff --git a/htdocs/gcc-9/changes.html b/htdocs/gcc-9/changes.html index 74c7cde72ef5ab8ec059e20a8da3e46907ecd9a3..a2a28a9aeb851cae298e828d2c4b57c6fa414cf4 100644 --- a/htdocs/gcc-9/changes.html +++ b/htdocs/gcc-9/changes.html @@ -1132,5 +1132,21 @@ complete (that is, it is possible that some PRs that have been fixed are not listed here). +GCC 9.4 + + Target Specific Changes + +AArch64 + + + The option -moutline-atomics has been added to aid + deployment of the Large System Extensions (LSE) on GNU/Linux systems built + with a baseline architecture targeting Armv8-A. When the option is + specified code is emitted to detect the presence of LSE instructions at + runtime and use them for standard atomic operations. + For more information please refer to the documentation. + + +
RE: [PATCH PR94708] rtl combine should consider NaNs when generate fp min/max
> -Original Message- > From: Richard Biener [mailto:richard.guent...@gmail.com] > Sent: Friday, April 24, 2020 2:19 PM > To: Zhanghaijian (A) > Cc: Segher Boessenkool ; > gcc-patches@gcc.gnu.org > Subject: Re: [PATCH PR94708] rtl combine should consider NaNs when generate > fp min/max > > On Fri, Apr 24, 2020 at 5:05 AM Zhanghaijian (A) > wrote: > > > > Thanks for your suggestions. For safety, I put back > flag_unsafe_math_optimizations. > > Attached please find the v3 patch which is suitable for git am. Bootstrap > > and > tested on aarch64 Linux platform. > > Is the v3 patch ok? > > OK. Thanks for reviewing this. Please help install this patch as I am not a committer. Thanks, Haijian Zhang
Re: [rs6000] fix mffsl emulation
Hello, Segher, On Apr 23, 2020, Segher Boessenkool wrote: > On Thu, Apr 23, 2020 at 05:08:55AM -0300, Alexandre Oliva wrote: >> I wasn't sure simplify_gen_subreg might possibly emit any code in >> obscure cases, > It never does, it just returns an RTX. Where would it emit the insns to? I'm pretty sure there are or were subreg-extraction functions that could emit new insns onto whatever insn stream was active in certain unusual circumstances; I wasn't sure whether this was one of them. > since all the top bits are zeros always, it will always be a subnormal > number, so all comparisons will work as expected / wanted. *nod*, as long as there's no trapping on subnormals. >> Yet another issue is that the test assumed the mmfs bits not extracted >> by mffsl are all zero. > All those extra bits are required to be set to 0. Not in the mffs output, no. See, at this point I'm not talking about the emulation, but about the mffs use in the test proper. Consider the case of emulated mffsl: we end up comparing the mffs output value with a masked version thereof. If any of the mffs output bits could possibly be nonzero, the compare would fail, not because the emulation is wrong, but because the test is comparing the output of mffsl with that of mffs, with all its bits. In my testing, mffs output zero in this program, so it worked, but are all the non-mffsl bits of FPSCR guaranteed to be zero, so the output of mffs doesn't have to be masked out by the test? What if some future CPU defines some of the reserved bits in FPSCR in a way that they should be nonzero? (And, could the ISA of such a future CPU possibly specify that mffsl should preserve those extra bits from FPSCR, rather than zero them out?) >> for gcc/ChangeLog >> >> * gcc/config/rs6000/rs6000.md (rs6000_mffsl): Copy result to >> output operand in emulation. Simplify. > Indent with a tab please. Erhm, what I posted had TABs there. Did it get mangled? :-( >> + rtx tmp_df = operands[0]; > Please don't reuse pseudos Aah, I see, that's what the original tmp_di was trying to accomplish! I'm familiar with that general guidance, but I didn't think there's much for optimizers to do with an mffs output, and the predicate ensures we have a reg, but... I suppose additional pseudos make the subregging safer, and not adding extra uses for operands[0] might help with register allocation for it, so... How about this, to also avoid reusing tmpdi as anddi input and output? rtx tmp_df = gen_reg_rtx (DFmode); /* The mffs instruction reads the entire FPSCR. Emulate the mffsl instruction using the mffs instruction and masking off the bits the mmsl instruction actually reads. */ emit_insn (gen_rs6000_mffs (tmp_df)); rtx tmp_df_as_di = simplify_gen_subreg (DImode, tmp_df, DFmode, 0); rtx tmp_di = gen_reg_rtx (DImode); emit_insn (gen_anddi3 (tmp_di, tmp_df_as_di, GEN_INT (0x70007f0ffLL))); rtx tmp_di_as_df = simplify_gen_subreg (DFmode, tmp_di, DImode, 0); emit_move_insn (operands[0], tmp_di_as_df); DONE; > "mffsl instruction". Heh, I see the original was bad already, oops. Double oops. I had that typo fixed in some earlier version of the patch, but somehow I managed to drop that fix. >> + if (operands[0] != tmp_df) >> +emit_move_insn (operands[0], tmp_df); >> + DONE; > That "==" won't do what you want, I guess? If the incoming operands[0] is a REG, we'd be back to it after subregging back and forth; if it was a SUBREG to begin with, the cheap test would fail and we'd output the redundant move, that later passes will catch. Anyway, that's gone in the snippet above. > (Is there a PR, btw?) Not that I know of; we've hit the testcase FAIL in our own testing. -- 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
RE: [PATCH][wwwdocs] Add -moutline-atomics for AArch64 on gcc-9 and gcc-8
> -Original Message- > From: Andre Vieira (lists) > Sent: 24 April 2020 08:49 > To: gcc-patches@gcc.gnu.org > Cc: Kyrylo Tkachov > Subject: [PATCH][wwwdocs] Add -moutline-atomics for AArch64 on gcc-9 and > gcc-8 > > Add the backported functionality of -moutline-atomics for AArch64 to the > gcc-9 and gcc-8 changes.html > > Validates. Is this OK? Ok. Thanks, Kyrill
Re: [PATCH PR94708] rtl combine should consider NaNs when generate fp min/max
On Fri, Apr 24, 2020 at 9:52 AM Zhanghaijian (A) wrote: > > > > > -Original Message- > > From: Richard Biener [mailto:richard.guent...@gmail.com] > > Sent: Friday, April 24, 2020 2:19 PM > > To: Zhanghaijian (A) > > Cc: Segher Boessenkool ; > > gcc-patches@gcc.gnu.org > > Subject: Re: [PATCH PR94708] rtl combine should consider NaNs when generate > > fp min/max > > > > On Fri, Apr 24, 2020 at 5:05 AM Zhanghaijian (A) > > wrote: > > > > > > Thanks for your suggestions. For safety, I put back > > flag_unsafe_math_optimizations. > > > Attached please find the v3 patch which is suitable for git am. Bootstrap > > > and > > tested on aarch64 Linux platform. > > > Is the v3 patch ok? > > > > OK. > > > Thanks for reviewing this. > Please help install this patch as I am not a committer. Will do. Richard. > Thanks, > Haijian Zhang
[PATCH v2] aarch64: Fix .cfi_window_save with pac-ret [PR94515]
On aarch64 -mbranch-protection=pac-ret reuses the dwarf
opcode for window_save to mean "toggle the return address
mangle state", but in the dwarf2cfi internal logic the
state was not updated when an opcode was emitted, the
currently present update logic is only valid for the
original sparc use of window_save so a separate bool is
used on aarch64 to track the state.
This bug can cause the unwinder not to authenticate return
addresses that were signed (or vice versa) which means a
runtime crash on a pauth enabled system.
Currently only aarch64 pac-ret uses REG_CFA_TOGGLE_RA_MANGLE.
This should be backported to gcc-9 and gcc-8 branches.
gcc/ChangeLog:
2020-04-23 Szabolcs Nagy
PR target/94515
* dwarf2cfi.c (struct GTY): Add ra_mangled.
(cfi_row_equal_p): Check ra_mangled.
(dwarf2out_frame_debug_cfa_window_save): Remove the argument,
this only handles the sparc logic now.
(dwarf2out_frame_debug_cfa_toggle_ra_mangle): New function for
the aarch64 specific logic.
(dwarf2out_frame_debug): Update to use the new subroutines.
(change_cfi_row): Check ra_mangled.
gcc/testsuite/ChangeLog:
2020-04-23 Szabolcs Nagy
PR target/94515
* g++.target/aarch64/pr94515-1.C: New test.
* g++.target/aarch64/pr94515-2.C: New test.
---
gcc/dwarf2cfi.c | 40 ++
gcc/testsuite/g++.target/aarch64/pr94515-1.C | 44
gcc/testsuite/g++.target/aarch64/pr94515-2.C | 41 ++
3 files changed, 118 insertions(+), 7 deletions(-)
create mode 100644 gcc/testsuite/g++.target/aarch64/pr94515-1.C
create mode 100644 gcc/testsuite/g++.target/aarch64/pr94515-2.C
diff --git a/gcc/dwarf2cfi.c b/gcc/dwarf2cfi.c
index 229fbfacc30..fa9e6089b2a 100644
--- a/gcc/dwarf2cfi.c
+++ b/gcc/dwarf2cfi.c
@@ -71,6 +71,9 @@ struct GTY(()) dw_cfi_row
/* True if the register window is saved. */
bool window_save;
+
+ /* True if the return address is in a mangled state. */
+ bool ra_mangled;
};
/* The caller's ORIG_REG is saved in SAVED_IN_REG. */
@@ -772,6 +775,9 @@ cfi_row_equal_p (dw_cfi_row *a, dw_cfi_row *b)
if (a->window_save != b->window_save)
return false;
+ if (a->ra_mangled != b->ra_mangled)
+return false;
+
return true;
}
@@ -1370,20 +1376,33 @@ dwarf2out_frame_debug_cfa_restore (rtx reg)
}
/* A subroutine of dwarf2out_frame_debug, process a REG_CFA_WINDOW_SAVE.
- FAKE is true if this is not really a window save but something else.
??? Perhaps we should note in the CIE where windows are saved (instead
of assuming 0(cfa)) and what registers are in the window. */
static void
-dwarf2out_frame_debug_cfa_window_save (bool fake)
+dwarf2out_frame_debug_cfa_window_save (void)
+{
+ dw_cfi_ref cfi = new_cfi ();
+
+ cfi->dw_cfi_opc = DW_CFA_GNU_window_save;
+ add_cfi (cfi);
+ cur_row->window_save = true;
+}
+
+/* A subroutine of dwarf2out_frame_debug, process a REG_CFA_TOGGLE_RA_MANGLE.
+ Note: DW_CFA_GNU_window_save dwarf opcode is reused for toggling RA mangle
+ state, this is a target specific operation on AArch64 and can only be used
+ on other targets if they don't use the window save operation otherwise. */
+
+static void
+dwarf2out_frame_debug_cfa_toggle_ra_mangle (void)
{
dw_cfi_ref cfi = new_cfi ();
cfi->dw_cfi_opc = DW_CFA_GNU_window_save;
add_cfi (cfi);
- if (!fake)
-cur_row->window_save = true;
+ cur_row->ra_mangled = !cur_row->ra_mangled;
}
/* Record call frame debugging information for an expression EXPR,
@@ -2143,13 +2162,12 @@ dwarf2out_frame_debug (rtx_insn *insn)
break;
case REG_CFA_TOGGLE_RA_MANGLE:
- /* This uses the same DWARF opcode as the next operation. */
- dwarf2out_frame_debug_cfa_window_save (true);
+ dwarf2out_frame_debug_cfa_toggle_ra_mangle ();
handled_one = true;
break;
case REG_CFA_WINDOW_SAVE:
- dwarf2out_frame_debug_cfa_window_save (false);
+ dwarf2out_frame_debug_cfa_window_save ();
handled_one = true;
break;
@@ -2221,6 +2239,14 @@ change_cfi_row (dw_cfi_row *old_row, dw_cfi_row *new_row)
cfi->dw_cfi_opc = DW_CFA_GNU_window_save;
add_cfi (cfi);
}
+
+ if (old_row->ra_mangled != new_row->ra_mangled)
+{
+ dw_cfi_ref cfi = new_cfi ();
+ /* DW_CFA_GNU_window_save is reused for toggling RA mangle state. */
+ cfi->dw_cfi_opc = DW_CFA_GNU_window_save;
+ add_cfi (cfi);
+}
}
/* Examine CFI and return true if a cfi label and set_loc is needed
diff --git a/gcc/testsuite/g++.target/aarch64/pr94515-1.C
b/gcc/testsuite/g++.target/aarch64/pr94515-1.C
new file mode 100644
index 000..cd63f4fb259
--- /dev/null
+++ b/gcc/testsuite/g++.target/aarch64/pr94515-1.C
@@ -0,0 +1,44 @@
+/* PR target/94515. Check .cfi_window_save with multiple return paths. */
+/* { dg-do run } */
+/* { dg-require-effective-target lp64 } */
+/* { dg-addition
Re: introduce target tmpnam and require it in tests relying on it
On Apr 23, 2020, Martin Sebor wrote:
> Sure. I'd go with _fileio but that's just a suggestion.
Okiedokie, here's the patch using fileio instead of tmpnam for the
effective target name. I'm going to check it in shortly.
introduce target fileio and require it in tests that use tmpnam
Some target C libraries that aren't recognized as freestanding don't
have filesystem support, so calling tmpnam, fopen/open and
remove/unlink fails to link.
This patch introduces a fileio effective target to the testsuite, and
requires it in the tests that call tmpnam.
for gcc/testsuite/ChangeLog
* lib/target-supports.exp (check_effective_target_fileio): New.
* gcc.c-torture/execute/fprintf-2.c: Require it.
* gcc.c-torture/execute/printf-2.c: Likewise.
* gcc.c-torture/execute/user-printf.c: Likewise.
---
gcc/testsuite/gcc.c-torture/execute/fprintf-2.c |1 +
gcc/testsuite/gcc.c-torture/execute/printf-2.c|1 +
gcc/testsuite/gcc.c-torture/execute/user-printf.c |1 +
gcc/testsuite/lib/target-supports.exp | 13 +
4 files changed, 16 insertions(+)
diff --git a/gcc/testsuite/gcc.c-torture/execute/fprintf-2.c
b/gcc/testsuite/gcc.c-torture/execute/fprintf-2.c
index c723867..d8e19e7 100644
--- a/gcc/testsuite/gcc.c-torture/execute/fprintf-2.c
+++ b/gcc/testsuite/gcc.c-torture/execute/fprintf-2.c
@@ -1,6 +1,7 @@
/* Verify that calls to fprintf don't get eliminated even if their
result on success can be computed at compile time (they can fail).
The calls can still be transformed into those of other functions.
+ { dg-require-effective-target fileio }
{ dg-prune-output "warning: warning: \[^\n\r\]* possibly used unsafely" }
{ dg-skip-if "requires io" { avr-*-* } }
{ dg-skip-if "requires io" { freestanding } } */
diff --git a/gcc/testsuite/gcc.c-torture/execute/printf-2.c
b/gcc/testsuite/gcc.c-torture/execute/printf-2.c
index 57f467e..4e7d8f7 100644
--- a/gcc/testsuite/gcc.c-torture/execute/printf-2.c
+++ b/gcc/testsuite/gcc.c-torture/execute/printf-2.c
@@ -2,6 +2,7 @@
result on success can be computed at compile time (they can fail).
The calls can still be transformed into those of other functions.
{ dg-require-effective-target unwrapped }
+ { dg-require-effective-target fileio }
{ dg-prune-output "warning: warning: \[^\n\r\]* possibly used unsafely" }
{ dg-skip-if "requires io" { avr-*-* } }
{ dg-skip-if "requires io" { freestanding } } */
diff --git a/gcc/testsuite/gcc.c-torture/execute/user-printf.c
b/gcc/testsuite/gcc.c-torture/execute/user-printf.c
index 006d99e..42a3b17 100644
--- a/gcc/testsuite/gcc.c-torture/execute/user-printf.c
+++ b/gcc/testsuite/gcc.c-torture/execute/user-printf.c
@@ -2,6 +2,7 @@
don't get eliminated even if their result on success can be computed at
compile time (they can fail).
{ dg-require-effective-target unwrapped }
+ { dg-require-effective-target fileio }
{ dg-prune-output "warning: warning: \[^\n\r\]* possibly used unsafely" }
{ dg-skip-if "requires io" { avr-*-* } }
{ dg-skip-if "requires io" { freestanding } } */
diff --git a/gcc/testsuite/lib/target-supports.exp
b/gcc/testsuite/lib/target-supports.exp
index e42d0ea..476d795 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -751,6 +751,19 @@ proc check_effective_target_freestanding { } {
return 0
}
+# Check to see that file I/O functions are available.
+proc check_effective_target_fileio { } {
+return [check_no_compiler_messages fileio_available executable {
+#include
+int main() {
+char *n = tmpnam (NULL);
+FILE *f = fopen (n, "w");
+fclose (f);
+remove (n);
+return 0;
+} } ""]
+}
+
# Return 1 if target has packed layout of structure members by
# default, 0 otherwise. Note that this is slightly different than
# whether the target has "natural alignment": both attributes may be
--
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
Re: [PATCH 4/5] testsuite: [arm/mve] Use dg-add-options arm_v8_1m_mve in MVE tests
On Tue, 14 Apr 2020 at 10:38, Andre Vieira (lists)
wrote:
>
> On 10/04/2020 14:55, Christophe Lyon via Gcc-patches wrote:
> > Several ARM/MVE tests can be compiled even if the toolchain does not
> > support -mfloat-abi=hard (softfp is OK).
> >
> > Use dg-add-options arm_v8_1m_mve or arm_v8_1m_mve_fp instead of using
> > dg-additional-options.
> Hi Christophe,
>
> I think a bunch of these tests were initially meant to test hard float
> abi with vectors, especially in the MVE integer cases, this is what the
> scan-assemblers are meant to test. However, it seems to pass for
> float-abi=softfp too ... which means these tests don't really mean
> anything. I think it would be good to remove the scan-assembler tests
> for now and improve these tests later with run tests, or some smarter
> function body testing.
>
> I suggest we apply your changes and I can follow up with a patch to
> remove the scan-assemblers for now, if a maintainer agrees with me that is.
Not sure why I missed that, but mve_vector_float2.c
fails on arm-linux-gnueabi, because it's scan-assembler works only
with mfloat-abi=hard:
gcc.target/arm/mve/intrinsics/mve_vector_float2.c scan-assembler
vmov\\tq[0-7], q[0-7]
I checked that
diff --git a/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_vector_float2.c
b/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_vector_float2.c
index e3cf8f8..10fe904 100644
--- a/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_vector_float2.c
+++ b/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_vector_float2.c
@@ -1,6 +1,7 @@
+/* { dg-require-effective-target arm_hard_ok } */
/* { dg-require-effective-target arm_v8_1m_mve_fp_ok } */
/* { dg-add-options arm_v8_1m_mve_fp } */
-/* { dg-skip-if "Incompatible float ABI" { *-*-* } {
"-mfloat-abi=soft" } {""} } */
+/* { dg-additional-options "-mfloat-abi=hard" } */
#include "arm_mve.h"
does the trick, but I also tried the check-function-bodies route. I
hoped it would
be easy, but... it wasn't because the testcase is also executed in C++
mode, so the function label is no longer foo32: but _Z5foo32v:
and check-function-bodies wants exact matching here.
Sigh
Christophe
>
> Cheers,
> Andre
> > 2020-04-10 Christophe Lyon
> >
> > gcc/testsuite/
> > * gcc.target/arm/mve/intrinsics/mve_vector_float.c: Use
> > arm_v8_1m_mve_fp.
> > * gcc.target/arm/mve/intrinsics/mve_vector_float1.c: Likewise.
> > * gcc.target/arm/mve/intrinsics/mve_vector_float2.c: Likewise.
> > * gcc.target/arm/mve/intrinsics/mve_vector_int.c: Use
> > arm_v8_1m_mve.
> > * gcc.target/arm/mve/intrinsics/mve_vector_int1.c: Likewise.
> > * gcc.target/arm/mve/intrinsics/mve_vector_int2.c: Likewise.
> > * gcc.target/arm/mve/intrinsics/mve_vector_uint.c: Likewise.
> > * gcc.target/arm/mve/intrinsics/mve_vector_uint1.c: Likewise.
> > * gcc.target/arm/mve/intrinsics/mve_vector_uint2.c: Likewise.
> > ---
> > gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_vector_float.c | 2 +-
> > gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_vector_float1.c | 2 +-
> > gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_vector_float2.c | 2 +-
> > gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_vector_int.c| 2 +-
> > gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_vector_int1.c | 2 +-
> > gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_vector_int2.c | 2 +-
> > gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_vector_uint.c | 2 +-
> > gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_vector_uint1.c | 2 +-
> > gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_vector_uint2.c | 2 +-
> > 9 files changed, 9 insertions(+), 9 deletions(-)
> >
> > diff --git a/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_vector_float.c
> > b/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_vector_float.c
> > index 881157f..6519b81 100644
> > --- a/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_vector_float.c
> > +++ b/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_vector_float.c
> > @@ -1,6 +1,6 @@
> > /* { dg-require-effective-target arm_v8_1m_mve_fp_ok } */
> > +/* { dg-add-options arm_v8_1m_mve_fp } */
> > /* { dg-skip-if "Incompatible float ABI" { *-*-* } { "-mfloat-abi=soft" }
> > {""} } */
> > -/* { dg-additional-options "-march=armv8.1-m.main+mve.fp -mfpu=auto
> > -mfloat-abi=hard -mthumb --save-temps" } */
> >
> > #include "arm_mve.h"
> >
> > diff --git
> > a/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_vector_float1.c
> > b/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_vector_float1.c
> > index 9515ed6..855e3b8 100644
> > --- a/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_vector_float1.c
> > +++ b/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_vector_float1.c
> > @@ -1,6 +1,6 @@
> > /* { dg-require-effective-target arm_v8_1m_mve_fp_ok } */
> > +/* { dg-add-options arm_v8_1m_mve_fp } */
> > /* { dg-skip-if "Incompatible float ABI" { *-*-* } { "-mfloat-abi=soft" }
> > {""} } */
> > -/* { dg-additional-options "-march=arm
Re: [wwwdocs] Remove form for (un)subscribing from old mailing lists
On Thu, 23 Apr 2020, Jonathan Wakely wrote: > This no longer works, so direct people to the mailman listinfo pages > instead. > > OK to commit to wwwdocs? Yes, thank you! I was wondering whether we could keep something similar to this nice form, but could not come up with a good way. So a regression we'll swallow as part of the system migration. Gerald
[committed] aarch64: Add an extra comment to arm_sve.h
I've had a couple of conversations now in which the shortness of arm_sve.h was causing confusion, with people thinking that the types and intrinsics were missing. It seems worth adding a comment to explain what's going on. Tested on aarch64-linux-gnu, pushed. Richard 2020-04-24 Richard Sandiford gcc/ * config/aarch64/arm_sve.h: Add a comment. --- gcc/config/aarch64/arm_sve.h | 5 + 1 file changed, 5 insertions(+) diff --git a/gcc/config/aarch64/arm_sve.h b/gcc/config/aarch64/arm_sve.h index f2d2d0ce9aa..5cad9a4cb2e 100644 --- a/gcc/config/aarch64/arm_sve.h +++ b/gcc/config/aarch64/arm_sve.h @@ -32,6 +32,11 @@ typedef __fp16 float16_t; typedef float float32_t; typedef double float64_t; +/* NOTE: This implementation of arm_sve.h is intentionally short. It does + not define the SVE types and intrinsic functions directly in C and C++ + code, but instead uses the following pragma to tell GCC to insert the + necessary type and function definitions itself. The net effect is the + same, and the file is a complete implementation of arm_sve.h. */ #pragma GCC aarch64 "arm_sve.h" #endif
Re: [RFC] split pseudos during loop unrolling in RTL unroller
On Fri, Apr 24, 2020 at 08:15:36AM +0200, Richard Biener wrote: > On Thu, Apr 23, 2020 at 4:54 PM Eric Botcazou wrote: > > > > > What is wrong with DF? > > > > > > > > It's slow and memory hungry? > > > > > > Very true, of course. But can this be significantly better? > > > > That's a good question worth investigating in my opinion, because DF didn't > > quite achieve its initial goal of replacing all the custom liveness analysis > > passes only because of its performance; the rest is quite neat. But IIRC > > long-time GCC hackers were involved in it, so it was probably tuned already. > > Having looked at DF a few times one of its problems seems to be too much > indirection in its data structures which is probably a fallout of making it > on-the-side rather than a part of the core RTL data structures (like SSA > and immediate uses are on GIMPLE). But then where it blows up is usually > during computing of the dataflow problems to create those data structures > and there's little room for improvement because it deals with a more complex > problem than we have on the GIMPLE side. But passes are also mindlessly > throwing 'compute-me-everyting' flags at it without really thinking > what they need, so ... And also, throwing away all existing info way too often. Part of that is causes by the interfaces to DF we have. That shouldn't be hard to fix. But mainly it is because too many things do not keep the info up-to-date after changes. > In the end I question the need of true "global" optimization passes on the > RTL IL. Almost everything should be local to interesting-CFG-shape regions. Depending on the target, almost *everything* depends on how far some code is from other code, and you can get much better code if you know you *are* close. But many passes already are per-BB of course. It's just the hard ones (RA...) that are not local at all. So you'll have to attack IRA if you want DF to be more local only, I think? > And yes, it probably requires a further lowering on GIMPLE to expose things > like multi-reg operations, As I said before, I don't think this is a good idea. > lowered bit-precision arithmetic, lowered But that is :-) > address generation and eventually constant legitimization (introducing a > constant pool already on GIMPLE, ideally maintaining it in the symbol > table). That might work on some targets, sure :-/ Segher
Re: [wwwdocs] Remove form for (un)subscribing from old mailing lists
On 24/04/20 12:57 +0200, Gerald Pfeifer wrote: On Thu, 23 Apr 2020, Jonathan Wakely wrote: This no longer works, so direct people to the mailman listinfo pages instead. OK to commit to wwwdocs? Yes, thank you! I was wondering whether we could keep something similar to this nice form, but could not come up with a good way. So a regression we'll swallow as part of the system migration. We could link directly to the listinfo page for each list, to get there in a single click. We can add that later, for now I wanted a quick fix for the broken form (and I've pushed that change).
Re: [wwwdocs] Remove form for (un)subscribing from old mailing lists
On 24/04/20 12:17 +0100, Jonathan Wakely wrote: On 24/04/20 12:57 +0200, Gerald Pfeifer wrote: On Thu, 23 Apr 2020, Jonathan Wakely wrote: This no longer works, so direct people to the mailman listinfo pages instead. OK to commit to wwwdocs? Yes, thank you! I was wondering whether we could keep something similar to this nice form, but could not come up with a good way. So a regression we'll swallow as part of the system migration. We could link directly to the listinfo page for each list, to get there in a single click. We can add that later, for now I wanted a quick fix for the broken form (and I've pushed that change). We could just add a link after the name of each list, as in this patch. What do you think? We could replace the text "(info)" with an icon like https://en.wikipedia.org/wiki/File:Information_icon.svg if we want to be "fancy" ;-) diff --git a/htdocs/gcc-10/porting_to.html b/htdocs/gcc-10/porting_to.html index 9574aacc..1f118ca6 100644 --- a/htdocs/gcc-10/porting_to.html +++ b/htdocs/gcc-10/porting_to.html @@ -73,6 +73,18 @@ were implicitly defined after including unrelated headers such as Correct code should include the appropriate headers for the classes being used. +Names not redeclared in __gnu_cxx + + +In previous releases a number of names from namespace std were +redeclared in namespace __gnu_cxx. This meant that names such as +__gnu_cxx::pair, __gnu_cxx::vector, and +__gnu_cxx::size_t were aliases for std::pair, +std::vector, and std::size_t. These aliases were only +present as implementation details and were never meant to be part of the +public API. The aliases have been removed, so names from namespace +std should be qualified with std::. + Fortran language issues diff --git a/htdocs/gitwrite.html b/htdocs/gitwrite.html index 97d60870..3f638249 100644 --- a/htdocs/gitwrite.html +++ b/htdocs/gitwrite.html @@ -271,7 +271,14 @@ made after you called git add for them. After exiting the editor, Git will check in your changes locally. When your prompt returns the local checkin is finished, but you still need to -push the changes to the shared repository; do git push. +push the changes to the shared repository. Before pushing it to gcc.gnu.org, +make sure your local branch only contains the changes you expect, +e.g. by reviewing the git status or git log output. +Once you're ready to publish the changes, do git push, +or to be more explicit, +git push origin HEAD:, +where is the branch on the remote, +such as master or releases/gcc-9. A message will be sent to the gcc-cvs mailing list indicating that a change was made. If git push gives an error because someone else has pushed their own changes to the same branch, diff --git a/htdocs/lists.html b/htdocs/lists.html index ea37aedc..b6bbfaf5 100644 --- a/htdocs/lists.html +++ b/htdocs/lists.html @@ -26,6 +26,7 @@ before subscribing and posting to these lists. https://gcc.gnu.org/ml/gcc-announce/";>gcc-announce + https://gcc.gnu.org/mailman/listinfo/gcc-announce";>(info) is a read-only low volume list where we post announcements about releases or other important events. @@ -34,10 +35,12 @@ before subscribing and posting to these lists. https://gcc.gnu.org/ml/gcc-help/";>gcc-help + https://gcc.gnu.org/mailman/listinfo/gcc-help";>(info) is a relatively high volume list for people searching for help in building or using GCC. https://gcc.gnu.org/ml/gcc/";>gcc + https://gcc.gnu.org/mailman/listinfo/gcc";>(info) is a high volume list for general development discussions about GCC. Anything relevant to the development or testing of GCC and not covered by other mailing lists is suitable for discussion here. @@ -53,35 +56,43 @@ before subscribing and posting to these lists. development process. https://gcc.gnu.org/ml/gcc-bugs/";>gcc-bugs + https://gcc.gnu.org/mailman/listinfo/gcc-bugs";>(info) is a relatively high volume list with mails from our bug-tracking system. https://gcc.gnu.org/ml/gcc-patches/";>gcc-patches + https://gcc.gnu.org/mailman/listinfo/gcc-patches";>(info) is a relatively high volume list for patch submissions and discussion of particular patches. All patches (including those for front ends and web pages) and all discussion for a particular patch should be sent to this list. https://gcc.gnu.org/ml/gcc-testresults/";> - gcc-testresults is a moderate volume list where test results for + gcc-testresults + https://gcc.gnu.org/mailman/listinfo/gcc-testresults";>(info) + is a moderate volume list where test results for the GCC compilers are posted. https://gcc.gnu.org/ml/gcc-regression/";>gcc-regression + https://gcc.gnu.org/mailman/listinfo/gcc-regression";>(info) is a moderate volume list where regression results for the GCC compilers are posted. https://gcc.gnu.org/ml/libstdc++/";>libstdc++ + https://gcc.gnu.org/mailman/listinfo/libstdc++";>(info) is the main d
Re: [GCC][PATCH][ARM]: Modify the MVE polymorphic variant arguments to match the MVE intrinsic definition.
On Thu, 23 Apr 2020 at 10:03, Kyrylo Tkachov wrote: > > > > > -Original Message- > > From: Srinath Parvathaneni > > Sent: 22 April 2020 14:00 > > To: gcc-patches@gcc.gnu.org > > Cc: Kyrylo Tkachov > > Subject: [GCC][PATCH][ARM]: Modify the MVE polymorphic variant > > arguments to match the MVE intrinsic definition. > > > > Hello, > > > > When MVE intrinsic's are called, few implicit typecasting are done on the > > formal arguments to match the intrinsic parameters. > > But when same intrinsics are called through MVE polymorphic variants, > > _Generic feature used here does strict type checking and fails to match the > > exact intrinsic. > > This patch corrects the behaviour of polymorphic variants and match the > > expected intrinsic by explicitly typecasting the polymorphic variant's > > arguments. > > > > Please refer to M-profile Vector Extension (MVE) intrinsics [1] for more > > details. > > [1] https://developer.arm.com/architectures/instruction-sets/simd- > > isas/helium/mve-intrinsics > > > > Regression tested on arm-none-eabi and found no regressions. > > > > Ok for trunk? Hi, I have noticed a few regressions: gcc.target/arm/mve/intrinsics/vbicq_f16.c (test for excess errors) gcc.target/arm/mve/intrinsics/vbicq_f32.c (test for excess errors) gcc.target/arm/mve/intrinsics/vbicq_s16.c (test for excess errors) gcc.target/arm/mve/intrinsics/vbicq_s32.c (test for excess errors) gcc.target/arm/mve/intrinsics/vbicq_s8.c (test for excess errors) gcc.target/arm/mve/intrinsics/vbicq_u16.c (test for excess errors) gcc.target/arm/mve/intrinsics/vbicq_u32.c (test for excess errors) gcc.target/arm/mve/intrinsics/vbicq_u8.c (test for excess errors) The errors are: /gcc/testsuite/gcc.target/arm/mve/intrinsics/vbicq_f16.c:18:9: error: cannot convert a vector of type 'float16x8_t' to type 'short int' which has different size /gcc/testsuite/gcc.target/arm/mve/intrinsics/vbicq_f32.c:18:9: error: cannot convert a vector of type 'float32x4_t' to type 'short int' which has different size etc In that case, the tests are compiled with -mfloat-abi=hard -mfpu=auto -march=armv8.1-m.main+mve.fp -mthumb did you test with different settings? Thanks, Christophe > > Ok. > Thanks, > Kyrill > > > > > Thanks, > > Srinath. > > > > gcc/ChangeLog: > > > > 2020-04-22 Srinath Parvathaneni > > > > * config/arm/arm_mve.h (__arm_vbicq_n_u16): Modify function > > parameter's > > datatype. > > (__arm_vbicq_n_s16): Likewise. > > (__arm_vbicq_n_u32): Likewise. > > (__arm_vbicq_n_s32): Likewise. > > (__arm_vbicq): Likewise. > > (__arm_vbicq_n_s16): Modify MVE polymorphic variant argument's > > datatype. > > (__arm_vbicq_n_s32): Likewise. > > (__arm_vbicq_n_u16): Likewise. > > (__arm_vbicq_n_u32): Likewise. > > (__arm_vdupq_m_n_s8): Likewise. > > (__arm_vdupq_m_n_s16): Likewise. > > (__arm_vdupq_m_n_s32): Likewise. > > (__arm_vdupq_m_n_u8): Likewise. > > (__arm_vdupq_m_n_u16): Likewise. > > (__arm_vdupq_m_n_u32): Likewise. > > (__arm_vdupq_m_n_f16): Likewise. > > (__arm_vdupq_m_n_f32): Likewise. > > (__arm_vldrhq_gather_offset_s16): Likewise. > > (__arm_vldrhq_gather_offset_s32): Likewise. > > (__arm_vldrhq_gather_offset_u16): Likewise. > > (__arm_vldrhq_gather_offset_u32): Likewise. > > (__arm_vldrhq_gather_offset_f16): Likewise. > > (__arm_vldrhq_gather_offset_z_s16): Likewise. > > (__arm_vldrhq_gather_offset_z_s32): Likewise. > > (__arm_vldrhq_gather_offset_z_u16): Likewise. > > (__arm_vldrhq_gather_offset_z_u32): Likewise. > > (__arm_vldrhq_gather_offset_z_f16): Likewise. > > (__arm_vldrhq_gather_shifted_offset_s16): Likewise. > > (__arm_vldrhq_gather_shifted_offset_s32): Likewise. > > (__arm_vldrhq_gather_shifted_offset_u16): Likewise. > > (__arm_vldrhq_gather_shifted_offset_u32): Likewise. > > (__arm_vldrhq_gather_shifted_offset_f16): Likewise. > > (__arm_vldrhq_gather_shifted_offset_z_s16): Likewise. > > (__arm_vldrhq_gather_shifted_offset_z_s32): Likewise. > > (__arm_vldrhq_gather_shifted_offset_z_u16): Likewise. > > (__arm_vldrhq_gather_shifted_offset_z_u32): Likewise. > > (__arm_vldrhq_gather_shifted_offset_z_f16): Likewise. > > (__arm_vldrwq_gather_offset_s32): Likewise. > > (__arm_vldrwq_gather_offset_u32): Likewise. > > (__arm_vldrwq_gather_offset_f32): Likewise. > > (__arm_vldrwq_gather_offset_z_s32): Likewise. > > (__arm_vldrwq_gather_offset_z_u32): Likewise. > > (__arm_vldrwq_gather_offset_z_f32): Likewise. > > (__arm_vldrwq_gather_shifted_offset_s32): Likewise. > > (__arm_vldrwq_gather_shifted_offset_u32): Likewise. > > (__arm_vldrwq_gather_shifted_offset_f32): Likewise. > > (__arm_vldrwq_gather_shifted_offset_z_s32): Likewise. > > (__arm_vldrwq_gather_shifted_offset_z_u32): Likewise. >
[committed] coroutines, testsuite: Add test for fixed pr [PR94288]
Hi,
This is a version of the reproducer in the PR, usable on multiple platforms.
tested on x86_64-linux/darwin, powerpc64-linux,
pushed to master,
thanks
Iain
gcc/testsuite/
2020-04-24 Iain Sandoe
PR c++/94288
* g++.dg/coroutines/pr94288.C: New test.
diff --git a/gcc/testsuite/g++.dg/coroutines/pr94288.C
b/gcc/testsuite/g++.dg/coroutines/pr94288.C
new file mode 100644
index 000..2557e3e0f2b
--- /dev/null
+++ b/gcc/testsuite/g++.dg/coroutines/pr94288.C
@@ -0,0 +1,70 @@
+// { dg-additional-options "-w" }
+
+#include "coro.h"
+
+#include
+
+template struct promise {
+ T _value;
+ coro::coroutine_handle<> _continuation = nullptr;
+
+ struct final_awaitable {
+bool _has_continuation;
+final_awaitable(bool has_continuation)
+: _has_continuation(has_continuation) {}
+
+bool await_ready() const noexcept { return !_has_continuation; }
+
+template
+coro::coroutine_handle<>
+await_suspend(coro::coroutine_handle coro) noexcept {
+ return coro.promise()._continuation;
+}
+
+void await_resume() noexcept {}
+ };
+
+ auto get_return_object() noexcept {
+return coro::coroutine_handle::from_promise(*this);
+ }
+
+ auto initial_suspend() noexcept { return coro::suspend_always(); }
+
+ auto final_suspend() noexcept {
+return final_awaitable(_continuation != nullptr);
+ }
+
+ void return_value(T value) { _value = value; }
+
+ void unhandled_exception() { /*std::terminate();*/ }
+
+};
+
+template struct task {
+ using promise_type = promise;
+ coro::coroutine_handle> _handle;
+
+ task(coro::coroutine_handle> handle) : _handle(handle) {}
+
+ bool await_ready() noexcept { return _handle.done(); }
+
+ coro::coroutine_handle<>
+ await_suspend(coro::coroutine_handle<> handle) noexcept {
+_handle.promise()._continuation = handle;
+return _handle;
+ }
+
+ T await_resume() noexcept { return _handle.promise()._value; }
+};
+
+task> foo()
+{
+ co_return std::vector();
+}
+
+task bar()
+{
+ while ((co_await foo()).empty()) {
+ }
+ co_return 0;
+}
--
2.24.1
Re: [committed] libstdc++: Add default constructor to net::service_already_exists (PR 94199)
On 16/03/20 22:54 +, Jonathan Wakely wrote:
The service_already_exists exception type specified in the TS doesn't
have any constructors defined. Since its base class isn't default
constructible, that means has no usable constructors. This may be a
defect in the TS.
This patch fixes it by adding a default constructor, but making it
private. The make_service function is declared as a friend to be able to
call that private constructor.
PR libstdc++/94199
* include/experimental/executor (service_already_exists): Add default
constructor. Declare make_service to be a friend.
* testsuite/experimental/net/execution_context/make_service.cc: New
test.
LWG preferred to make the constrcutor public, so this patch does that.
Tested x86_64-linux, committed to master.
commit 00082ff88cf4e25fc1041e9effd1c92fbaaa8d62
Author: Jonathan Wakely
Date: Fri Apr 24 14:15:51 2020 +0100
libstdc++: Make net::service_already_exists default constructible
The LWG issue I created is Tentatively Ready and proposes to declare a
public default constructor, rather than the private one I added
recently.
* include/experimental/executor (service_already_exists): Make default
constructor public (LWG 3414).
* testsuite/experimental/net/execution_context/make_service.cc: Check
the service_already_exists can be default constructed.
diff --git a/libstdc++-v3/include/experimental/executor b/libstdc++-v3/include/experimental/executor
index fa39eaa0468..3560e345e8a 100644
--- a/libstdc++-v3/include/experimental/executor
+++ b/libstdc++-v3/include/experimental/executor
@@ -129,10 +129,9 @@ inline namespace v1
class service_already_exists : public logic_error
{
-template
- friend _Service&
- make_service(execution_context&, _Args&&...);
-
+ public:
+// _GLIBCXX_RESOLVE_LIB_DEFECTS
+// 3414. service_already_exists has no usable constructors
service_already_exists() : logic_error("service already exists") { }
};
diff --git a/libstdc++-v3/testsuite/experimental/net/execution_context/make_service.cc b/libstdc++-v3/testsuite/experimental/net/execution_context/make_service.cc
index f134add48b5..0898d12927a 100644
--- a/libstdc++-v3/testsuite/experimental/net/execution_context/make_service.cc
+++ b/libstdc++-v3/testsuite/experimental/net/execution_context/make_service.cc
@@ -34,3 +34,6 @@ void test01(net::execution_context& c)
{
net::make_service(c);
}
+
+static_assert(std::is_default_constructible(),
+ "LWG 3414. service_already_exists has no usable constructors");
Re: [PATCH] libstdc++: don't use #include_next in c_global headers
On 23/04/20 09:23 +0100, Jonathan Wakely wrote: On 23/04/20 06:32 +0200, Helmut Grohne wrote: Hi, On Mon, Apr 20, 2020 at 10:12:37AM +0100, Jonathan Wakely wrote: Now you are probably going to say that "-isystem /usr/include" is a bad idea and that you shouldn't do that. Right. I'm inclined to agree. This isn't a problem just yet. Debian wants to move /usr/include/stdlib.h to /usr/include//stdlib.h. After that move, the problematic flag becomes "-isystem /usr/include/". Unfortunately, around 30 Debian packages[1] do pass exactly that flag. Regardless whether doing so is a bad idea, I guess we will have to support that. Or Debian should fix what they're going to break. This is not quite precise. The offending -isystem /usr/include/ flag is already being passed. According to what you write later, doing so is broken today. It just happens to work by accident. So all we do is making the present breakage visible. I am proposing to replace those two #include_next with plain #include. That'll solve the problem described above, but it is not entirely obvious that doing so doesn't break something else. After switching those #include_next to #include, libstdc++-v3/include/c_global/cstdlib will continue to temporarily will #include . Now, it'll search all include directories. It may find libstdc++-v3/include/c_comaptibility/stdlib.h or the libc's version. We cannot tell which. If it finds the one from libstdc++-v3, the header will notice the _GLIBCXX_INCLUDE_NEXT_C_HEADERS macro and immediately #include_next skipping the rest of the header. That in turn will find the libc version. So in both cases, it ends up using the right one. Precisely what we wanted. As Marc said, this doesn't work. That is not very precise either. Marc said that it won't fix all cases. In practice, it would make those work that don't #include but use #include instead. Marc also indicated that using include_next for a header of a different name is wrong. So this is a bug in libstdc++ regardless of whether it breaks or unbreaks other pieces of software. He said he doesn't like it, that doesn't mean it's a bug or actually causes incorrect results. Whereas using -isystem provably *does* break the implementation, making it impossible for #include to meet the requirements of the C++ standard. And your proposed patch doesn't prevent that. If a program tries to include it needs to get the libstdc++ version, otherwise only the libc versions of certain functions are defined. That means the additional C++ overloads such as ::abs(long) and ::abs(long long) won't be defined. That is the reason why libstdc++ provides its own . And if you do -isystem /usr/include (or any other option that causes libstdc++'s to be skipped) that doesn't work. Only ::abs(int) gets defined. So -isystem /usr/include breaks code, with or without your patch. It is very difficult to disagree with -isystem /usr/include or -isystem /usr/include/ being broken and unsupported. Having you state it that clearly does help with communicating to other upstreams. For this reason, I've looked into the remaining cases. It turns out that there aren't that many left. In particular chromium, opencv and vtk got fixed in the mean time. Basically all remaining failures could be attributed to qmake, which passes all directories below /usr/include (including /usr/include and /usr/include/ if a .pc file mentions them) using -isystem. I've sent a patch https://bugs.debian.org/958479 to make qmake stop doing that. I therefore agree with you that the patch I sent for libstdc++ is not necessary to make packages build on Debian. Removing the offending -isystem flags from the respective builds is a manageable option and has already happened to a large extend. Yes, I introduced the current and wrappers years ago in GCC 6, and so I'm surprised to see it coming up again now. Several packages had problems and already fixed them. We can conclude that the motivation for my patch is not a good one, because it embraces broken behaviour. However, the use of include_next remains a bug, because the name of the including and the name of the included header differ, and it should be fixed on that ground. Not liking something is not a bug. You need to demonstrate an actual bug (e.g. failure to compile, non-conformance to the C++ standard) that is not caused by user error (like misuse of -isystem) to argue for fixing something. N.B. the GCC docs are quite clear that reordering include directories risk breaking GCC's necessary use of #include_next: If a standard system include directory, or a directory specified with -isystem, is also specified with -I, the -I option is ignored. The directory is still searched but as a system directory at its normal position in the system include chain. This is to ensure that GCC's procedure to fix buggy system headers and the ordering for the "#include_next" directive are not inadvertently changed. If you really need to change
[committed] amdgcn: Testsuite tweaks
This patch tweaks the testsuite expectations for amdgcn.
The result on the testsuite is a lot of removed failures, some new
passes, and a few new fails that are at least accurate.
Andrew
amdgcn: Testsuite tweaks
The vector size chosen here is for V64DImode. The concept of this setting is
not well adapted for GCN, in which the vector size varies with the number of
lanes, not the other way around, but this is ok for now.
2020-04-24 Andrew Stubbs
gcc/testsuite/
* lib/target-supports.exp (available_vector_sizes): Add amdgcn.
(check_effective_target_vect_cmdline_needed): Disable for amdgcn.
(check_effective_target_vect_pack_trunc): Add amdgcn.
diff --git a/gcc/testsuite/lib/target-supports.exp b/gcc/testsuite/lib/target-supports.exp
index 008def691b3..f416d5cafda 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -3261,7 +3261,8 @@ proc check_effective_target_vect_cmdline_needed { } {
|| [check_effective_target_powerpc_altivec]))
|| ([istarget sparc*-*-*] && [check_effective_target_sparc_vis])
|| ([istarget arm*-*-*] && [check_effective_target_arm_neon])
- || [istarget aarch64*-*-*] } {
+ || [istarget aarch64*-*-*]
+ || [istarget amdgcn*-*-*]} {
return 0
} else {
return 1
@@ -6806,7 +6807,8 @@ proc check_effective_target_vect_pack_trunc { } {
|| ([istarget mips*-*-*]
&& [et-is-effective-target mips_msa])
|| ([istarget s390*-*-*]
- && [check_effective_target_s390_vx]) }}]
+ && [check_effective_target_s390_vx])
+ || [istarget amdgcn*-*-*] }}]
}
# Return 1 if the target plus current options supports a vector
@@ -7231,6 +7233,8 @@ proc available_vector_sizes { } {
}
} elseif { [istarget sparc*-*-*] } {
lappend result 64
+} elseif { [istarget amdgcn*-*-*] } {
+ lappend result 4096
} else {
# The traditional default asumption.
lappend result 128
Re: [PATCH v2] aarch64: Fix .cfi_window_save with pac-ret [PR94515]
Szabolcs Nagy writes:
> @@ -2221,6 +2239,14 @@ change_cfi_row (dw_cfi_row *old_row, dw_cfi_row
> *new_row)
>cfi->dw_cfi_opc = DW_CFA_GNU_window_save;
>add_cfi (cfi);
> }
> +
> + if (old_row->ra_mangled != new_row->ra_mangled)
> +{
> + dw_cfi_ref cfi = new_cfi ();
> + /* DW_CFA_GNU_window_save is reused for toggling RA mangle state. */
> + cfi->dw_cfi_opc = DW_CFA_GNU_window_save;
> + add_cfi (cfi);
> +}
> }
>
> /* Examine CFI and return true if a cfi label and set_loc is needed
I wonder if it would be worth asserting:
gcc_assert (!old_row->ra_mangled && !new_row->ra_mangled);
in the "SPARC" block and:
gcc_assert (!old_row->window_save && !new_row->window_save);
in the "aarch64" block?
> diff --git a/gcc/testsuite/g++.target/aarch64/pr94515-2.C
> b/gcc/testsuite/g++.target/aarch64/pr94515-2.C
> new file mode 100644
> index 000..1f13e1200ad
> --- /dev/null
> +++ b/gcc/testsuite/g++.target/aarch64/pr94515-2.C
> @@ -0,0 +1,41 @@
> +/* PR target/94515. Check .cfi_window_save with multiple return paths. */
> +/* { dg-do run } */
> +/* { dg-require-effective-target lp64 } */
> +/* { dg-additional-options "-O2 -mbranch-protection=pac-ret" } */
> +
> +volatile int zero = 0;
> +int global = 0;
> +
> +__attribute__((noinline))
> +int bar(void)
> +{
> + if (zero == 0) return 3;
> + return 0;
> +}
> +
> +__attribute__((noinline, noreturn))
> +void unwind (void)
> +{
> + throw 42;
> +}
> +
> +__attribute__((noinline, noipa, target("branch-protection=pac-ret")))
I'm probably just showing my ignorance, but is this target attribute
needed? It looks like all functions in the test are compiled with pac-ret.
LGTM otherwise, but please give others 24 hrs to object.
Thanks,
Richard
[GCC][PATCH][ARM]: Change arm constraint name from "e" to "Te".
Hello,
This patches changes the constraint "e" to "Te".
Regression tested on arm-none-eabi and found no regressions.
Ok for trunk?
Thanks,
Srinath.
gcc/ChangeLog:
2020-04-24 Srinath Parvathaneni
* config/arm/constraints.md (e): Remove constraint.
(Te): Define constraint.
* config/arm/mve.md (vaddvq_): Modify constraint in
operand 0 from "e" to "Te".
(vaddvaq_): Likewise.
(vaddvq_p_): Likewise.
(vmladavq_): Likewise.
(vmladavxq_s): Likewise.
(vmlsdavq_s): Likewise.
(vmlsdavxq_s): Likewise.
(vaddvaq_p_): Likewise.
(vmladavaq_): Likewise.
(vmladavq_p_): Likewise.
(vmladavxq_p_s): Likewise.
(vmlsdavq_p_s): Likewise.
(vmlsdavxq_p_s): Likewise.
(vmlsdavaxq_s): Likewise.
(vmlsdavaq_s): Likewise.
(vmladavaxq_s): Likewise.
(vmladavaq_p_): Likewise.
(vmladavaxq_p_s): Likewise.
(vmlsdavaq_p_s): Likewise.
(vmlsdavaxq_p_s): Likewise.
### Attachment also inlined for ease of reply###
diff --git a/gcc/config/arm/constraints.md b/gcc/config/arm/constraints.md
index
41a85e2713b59f75f0b191b6be03a7ac8f6e321e..fed6c7c84032dd8aba45142b59b980b4a6240d6d
100644
--- a/gcc/config/arm/constraints.md
+++ b/gcc/config/arm/constraints.md
@@ -32,7 +32,7 @@
;; The following multi-letter normal constraints have been used:
;; in ARM/Thumb-2 state: Da, Db, Dc, Dd, Dn, DN, Dm, Dl, DL, Do, Dv, Dy, Di,
-;; Dt, Dp, Dz, Tu
+;; Dt, Dp, Dz, Tu, Te
;; in Thumb-1 state: Pa, Pb, Pc, Pd, Pe
;; in Thumb-2 state: Ha, Pj, PJ, Ps, Pt, Pu, Pv, Pw, Px, Py, Pz, Rd, Rf, Rb,
Ra,
;; Rg, Ri
@@ -50,8 +50,8 @@
(define_register_constraint "Uf" "TARGET_HAVE_MVE ? VFPCC_REG : NO_REGS"
"MVE FPCCR register")
-(define_register_constraint "e" "TARGET_HAVE_MVE ? EVEN_REG : NO_REGS"
- "MVE EVEN registers @code{r0}, @code{r2}, @code{r4}, @code{r6}, @code{r8},
+(define_register_constraint "Te" "TARGET_HAVE_MVE ? EVEN_REG : NO_REGS"
+ "EVEN core registers @code{r0}, @code{r2}, @code{r4}, @code{r6}, @code{r8},
@code{r10}, @code{r12}, @code{r14}")
(define_constraint "Rd"
diff --git a/gcc/config/arm/mve.md b/gcc/config/arm/mve.md
index
9cb18ef50e8320b2d7160346361343c4ab1685b9..f43dabbfd4f15b602f0627a9b0ea423064501e51
100644
--- a/gcc/config/arm/mve.md
+++ b/gcc/config/arm/mve.md
@@ -1102,7 +1102,7 @@
;;
(define_insn "mve_vaddvq_"
[
- (set (match_operand:SI 0 "s_register_operand" "=e")
+ (set (match_operand:SI 0 "s_register_operand" "=Te")
(unspec:SI [(match_operand:MVE_2 1 "s_register_operand" "w")]
VADDVQ))
]
@@ -1477,7 +1477,7 @@
;;
(define_insn "mve_vaddvaq_"
[
- (set (match_operand:SI 0 "s_register_operand" "=e")
+ (set (match_operand:SI 0 "s_register_operand" "=Te")
(unspec:SI [(match_operand:SI 1 "s_register_operand" "0")
(match_operand:MVE_2 2 "s_register_operand" "w")]
VADDVAQ))
@@ -1492,7 +1492,7 @@
;;
(define_insn "mve_vaddvq_p_"
[
- (set (match_operand:SI 0 "s_register_operand" "=e")
+ (set (match_operand:SI 0 "s_register_operand" "=Te")
(unspec:SI [(match_operand:MVE_2 1 "s_register_operand" "w")
(match_operand:HI 2 "vpr_register_operand" "Up")]
VADDVQ_P))
@@ -2032,7 +2032,7 @@
;;
(define_insn "mve_vmladavq_"
[
- (set (match_operand:SI 0 "s_register_operand" "=e")
+ (set (match_operand:SI 0 "s_register_operand" "=Te")
(unspec:SI [(match_operand:MVE_2 1 "s_register_operand" "w")
(match_operand:MVE_2 2 "s_register_operand" "w")]
VMLADAVQ))
@@ -2047,7 +2047,7 @@
;;
(define_insn "mve_vmladavxq_s"
[
- (set (match_operand:SI 0 "s_register_operand" "=e")
+ (set (match_operand:SI 0 "s_register_operand" "=Te")
(unspec:SI [(match_operand:MVE_2 1 "s_register_operand" "w")
(match_operand:MVE_2 2 "s_register_operand" "w")]
VMLADAVXQ_S))
@@ -2062,7 +2062,7 @@
;;
(define_insn "mve_vmlsdavq_s"
[
- (set (match_operand:SI 0 "s_register_operand" "=e")
+ (set (match_operand:SI 0 "s_register_operand" "=Te")
(unspec:SI [(match_operand:MVE_2 1 "s_register_operand" "w")
(match_operand:MVE_2 2 "s_register_operand" "w")]
VMLSDAVQ_S))
@@ -2077,7 +2077,7 @@
;;
(define_insn "mve_vmlsdavxq_s"
[
- (set (match_operand:SI 0 "s_register_operand" "=e")
+ (set (match_operand:SI 0 "s_register_operand" "=Te")
(unspec:SI [(match_operand:MVE_2 1 "s_register_operand" "w")
(match_operand:MVE_2 2 "s_register_operand" "w")]
VMLSDAVXQ_S))
@@ -3685,7 +3685,7 @@
;;
(define_insn "mve_vaddvaq_p_"
[
- (set (match_operand:SI 0 "s_register_operand" "=e")
+ (set (match_operand:SI 0 "s_register_operand" "=Te")
(unspec:SI [(match_operand:SI 1 "s_register_operand" "0")
(mat
Re: [rs6000] fix mffsl emulation
Hi! On Fri, Apr 24, 2020 at 04:52:46AM -0300, Alexandre Oliva wrote: > On Apr 23, 2020, Segher Boessenkool wrote: > > On Thu, Apr 23, 2020 at 05:08:55AM -0300, Alexandre Oliva wrote: > >> I wasn't sure simplify_gen_subreg might possibly emit any code in > >> obscure cases, > > > It never does, it just returns an RTX. Where would it emit the insns to? > > I'm pretty sure there are or were subreg-extraction functions that could > emit new insns onto whatever insn stream was active in certain unusual > circumstances; Yeah, I think so too. > I wasn't sure whether this was one of them. Doesn't look that way, thankfully :-) > > since all the top bits are zeros always, it will always be a subnormal > > number, so all comparisons will work as expected / wanted. > > *nod*, as long as there's no trapping on subnormals. There isn't :-) I did say this isn't clean at all, just *happens* to work, right? :-) > >> Yet another issue is that the test assumed the mmfs bits not extracted > >> by mffsl are all zero. > > > All those extra bits are required to be set to 0. > > Not in the mffs output, no. See, at this point I'm not talking about > the emulation, but about the mffs use in the test proper. Hrm, I don't see it then. > Consider the case of emulated mffsl: we end up comparing the mffs output > value with a masked version thereof. If any of the mffs output bits > could possibly be nonzero, the compare would fail, not because the > emulation is wrong, but because the test is comparing the output of > mffsl with that of mffs, with all its bits. Oh. I thought that was masked as well. > In my testing, mffs output zero in this program, so it worked, but are > all the non-mffsl bits of FPSCR guaranteed to be zero, so the output of > mffs doesn't have to be masked out by the test? No, and there are many bits not yet defined, so it may change for future versions of the ISA. > What if some future CPU defines some of the reserved bits in FPSCR in a > way that they should be nonzero? In a way different between mffs and mffsl. Yeah. > (And, could the ISA of such a future CPU possibly specify that mffsl > should preserve those extra bits from FPSCR, rather than zero them out?) Yes, I don't see why not? Hrm, the exact language for the mffsl description does not allow that, but that wouldn't be the best thing to reply on. > >> for gcc/ChangeLog > >> > >> * gcc/config/rs6000/rs6000.md (rs6000_mffsl): Copy result to > >> output operand in emulation. Simplify. > > > Indent with a tab please. > > Erhm, what I posted had TABs there. Did it get mangled? :-( Yes, to eight spaces, so that aligned "output" under "gcc". > >> + rtx tmp_df = operands[0]; > > > Please don't reuse pseudos > > Aah, I see, that's what the original tmp_di was trying to accomplish! :-) > I'm familiar with that general guidance, but I didn't think there's much > for optimizers to do with an mffs output, and the predicate ensures we > have a reg, but... I suppose additional pseudos make the subregging > safer, and not adding extra uses for operands[0] might help with > register allocation for it, so... How about this, to also avoid reusing > tmpdi as anddi input and output? No pseudo should be assigned to more than once. A la SSA, or "webs". Many of our optimisers do not work well otherwise. > rtx tmp_df = gen_reg_rtx (DFmode); > > /* The mffs instruction reads the entire FPSCR. Emulate the mffsl >instruction using the mffs instruction and masking off the bits >the mmsl instruction actually reads. */ > emit_insn (gen_rs6000_mffs (tmp_df)); > > rtx tmp_df_as_di = simplify_gen_subreg (DImode, tmp_df, DFmode, 0); > rtx tmp_di = gen_reg_rtx (DImode); > emit_insn (gen_anddi3 (tmp_di, tmp_df_as_di, GEN_INT (0x70007f0ffLL))); > > rtx tmp_di_as_df = simplify_gen_subreg (DFmode, tmp_di, DImode, 0); > emit_move_insn (operands[0], tmp_di_as_df); > DONE; Sure, that looks fine. Maybe tmp1, tmp2, etc. woukld be clearer here? :-) > > "mffsl instruction". Heh, I see the original was bad already, oops. > > Double oops. I had that typo fixed in some earlier version of the > patch, but somehow I managed to drop that fix. > > >> + if (operands[0] != tmp_df) > >> + emit_move_insn (operands[0], tmp_df); > >> + DONE; > > > That "==" won't do what you want, I guess? > > If the incoming operands[0] is a REG, we'd be back to it after > subregging back and forth; if it was a SUBREG to begin with, the cheap > test would fail and we'd output the redundant move, that later passes > will catch. Anyway, that's gone in the snippet above. > > > (Is there a PR, btw?) > > Not that I know of; we've hit the testcase FAIL in our own testing. Could you open one? This patch will need backporting, etc. I can do it, if you really hate bugzilla, but I think it is easier for you to do it :-) Thanks! Segher
Re: [PATCH v2] aarch64: Fix .cfi_window_save with pac-ret [PR94515]
The 04/24/2020 15:17, Richard Sandiford wrote:
> Szabolcs Nagy writes:
> > @@ -2221,6 +2239,14 @@ change_cfi_row (dw_cfi_row *old_row, dw_cfi_row
> > *new_row)
> >cfi->dw_cfi_opc = DW_CFA_GNU_window_save;
> >add_cfi (cfi);
> > }
> > +
> > + if (old_row->ra_mangled != new_row->ra_mangled)
> > +{
> > + dw_cfi_ref cfi = new_cfi ();
> > + /* DW_CFA_GNU_window_save is reused for toggling RA mangle state. */
> > + cfi->dw_cfi_opc = DW_CFA_GNU_window_save;
> > + add_cfi (cfi);
> > +}
> > }
> >
> > /* Examine CFI and return true if a cfi label and set_loc is needed
>
> I wonder if it would be worth asserting:
>
> gcc_assert (!old_row->ra_mangled && !new_row->ra_mangled);
>
> in the "SPARC" block and:
>
> gcc_assert (!old_row->window_save && !new_row->window_save);
>
> in the "aarch64" block?
makes sense.
i'll fix it.
> > diff --git a/gcc/testsuite/g++.target/aarch64/pr94515-2.C
> > b/gcc/testsuite/g++.target/aarch64/pr94515-2.C
> > new file mode 100644
> > index 000..1f13e1200ad
> > --- /dev/null
> > +++ b/gcc/testsuite/g++.target/aarch64/pr94515-2.C
> > @@ -0,0 +1,41 @@
> > +/* PR target/94515. Check .cfi_window_save with multiple return paths. */
> > +/* { dg-do run } */
> > +/* { dg-require-effective-target lp64 } */
> > +/* { dg-additional-options "-O2 -mbranch-protection=pac-ret" } */
> > +
> > +volatile int zero = 0;
> > +int global = 0;
> > +
> > +__attribute__((noinline))
> > +int bar(void)
> > +{
> > + if (zero == 0) return 3;
> > + return 0;
> > +}
> > +
> > +__attribute__((noinline, noreturn))
> > +void unwind (void)
> > +{
> > + throw 42;
> > +}
> > +
> > +__attribute__((noinline, noipa, target("branch-protection=pac-ret")))
>
> I'm probably just showing my ignorance, but is this target attribute
> needed? It looks like all functions in the test are compiled with pac-ret.
no, that's left over before i added it to the cflags,
i'll fix it.
>
> LGTM otherwise, but please give others 24 hrs to object.
thanks.
>
> Thanks,
> Richard
--
[committed] amdgcn: Split 64-bit constant loads post-reload
This patch changes the split-point of 64-bit moves to after register
allocation. This means that LRA sees a simpler instruction stream, and
seems to produce better code on some testcases.
Andrew
amdgcn: Split 64-bit constant loads post-reload
This helps avoid spilling 64-bit constant loads to stack by simplifying the
code that LRA sees.
2020-04-17 Andrew Stubbs
gcc/
* config/gcn/gcn.md (*mov_insn): Only split post-reload.
diff --git a/gcc/config/gcn/gcn.md b/gcc/config/gcn/gcn.md
index 702ba55c11a..8f5937781b2 100644
--- a/gcc/config/gcn/gcn.md
+++ b/gcc/config/gcn/gcn.md
@@ -615,9 +615,11 @@
ds_read_b64\t%0, %A1%O1\;s_waitcnt\tlgkmcnt(0)
global_load_dwordx2\t%0, %A1%O1%g1\;s_waitcnt\tvmcnt(0)
global_store_dwordx2\t%A0, %1%O0%g0"
- "(reload_completed && !MEM_P (operands[0]) && !MEM_P (operands[1])
-&& !gcn_sgpr_move_p (operands[0], operands[1]))
- || (GET_CODE (operands[1]) == CONST_INT && !gcn_constant64_p (operands[1]))"
+ "reload_completed
+ && ((!MEM_P (operands[0]) && !MEM_P (operands[1])
+&& !gcn_sgpr_move_p (operands[0], operands[1]))
+ || (GET_CODE (operands[1]) == CONST_INT
+ && !gcn_constant64_p (operands[1])))"
[(set (match_dup 0) (match_dup 1))
(set (match_dup 2) (match_dup 3))]
{
[PATCH] cselim: Don't assume it is safe to cstore replace a store to a local variable with unknown offset [PR94734]
Hi!
As the new testcase shows, it is not safe to assume we can optimize
a conditional store into an automatic non-addressable var, we can do it
only if we can prove that the unconditional load or store actually will
not be outside of the boundaries of the variable.
If the offset and size are constant, we can, but this is already all
checked in !tree_could_trap_p, otherwise we really need to check for
a dominating unconditional store, or for the specific case of automatic
non-addressable variables, it is enough if there is a dominating load
(that is what those 4 testcases have). tree-ssa-phiopt.c has some
infrastructure for this already, see the add_or_mark_expr method etc.,
but right now it handles only MEM_REFs with SSA_NAME first operand
and some integral offset. So, I think it can be for GCC11 extended
to handle other memory references, possibly up to just doing
get_inner_reference and hasing based on the base, offset expressions
and bit_offset and bit_size, and have also a special case that for
!TREE_ADDRESSABLE automatic variables it could ignore whether something
is a load or store because the local stack should be always writable.
But it feels way too dangerous to do this this late for GCC10, so this
patch just restricts the optimization to the safe case (where lhs doesn't
trap), and on Richi's request also ignores TREE_ADDRESSABLE bit if
flag_store_data_races, because my understanding the reason for
TREE_ADDRESSABLE check is that we want to avoid introducing
store data races (if address of an automatic var escapes, some other thread
could be accessing it concurrently).
Bootstrapped/regtested on powerpc64{,le}-linux, ok for trunk?
2020-04-24 Jakub Jelinek
Richard Biener
PR tree-optimization/94734
PR tree-optimization/89430
* tree-ssa-phiopt.c: Include tree-eh.h.
(cond_store_replacement): Return false if an automatic variable
access could trap. If -fstore-data-races, don't return false
just because an automatic variable is addressable.
* gcc.dg/tree-ssa/pr89430-1.c: Add xfail.
* gcc.dg/tree-ssa/pr89430-2.c: Add xfail.
* gcc.dg/tree-ssa/pr89430-5.c: Add xfail.
* gcc.dg/tree-ssa/pr89430-6.c: Add xfail.
* gcc.c-torture/execute/pr94734.c: New test.
--- gcc/tree-ssa-phiopt.c.jj2020-03-19 10:23:50.542872359 +0100
+++ gcc/tree-ssa-phiopt.c 2020-04-24 12:33:02.368355735 +0200
@@ -45,6 +45,7 @@ along with GCC; see the file COPYING3.
#include "tree-scalar-evolution.h"
#include "tree-inline.h"
#include "case-cfn-macros.h"
+#include "tree-eh.h"
static unsigned int tree_ssa_phiopt_worker (bool, bool, bool);
static bool two_value_replacement (basic_block, basic_block, edge, gphi *,
@@ -2237,10 +2238,13 @@ cond_store_replacement (basic_block midd
whose value is not available readily, which we want to avoid. */
if (!nontrap->contains (lhs))
{
- /* If LHS is a local variable without address-taken, we could
+ /* If LHS is an access to a local variable without address-taken
+(or when we allow data races) and known not to trap, we could
always safely move down the store. */
tree base = get_base_address (lhs);
- if (!auto_var_p (base) || TREE_ADDRESSABLE (base))
+ if (!auto_var_p (base)
+ || (TREE_ADDRESSABLE (base) && !flag_store_data_races)
+ || tree_could_trap_p (lhs))
return false;
}
--- gcc/testsuite/gcc.dg/tree-ssa/pr89430-1.c.jj2020-01-12
11:54:37.606395410 +0100
+++ gcc/testsuite/gcc.dg/tree-ssa/pr89430-1.c 2020-04-24 11:26:45.021425675
+0200
@@ -9,4 +9,4 @@ unsigned test(unsigned k, unsigned b) {
return a[0]+a[1];
}
-/* { dg-final { scan-tree-dump "Conditional store replacement" "cselim" } } */
+/* { dg-final { scan-tree-dump "Conditional store replacement" "cselim" {
xfail *-*-* } } } */
--- gcc/testsuite/gcc.dg/tree-ssa/pr89430-2.c.jj2020-01-12
11:54:37.606395410 +0100
+++ gcc/testsuite/gcc.dg/tree-ssa/pr89430-2.c 2020-04-24 11:26:52.319316212
+0200
@@ -11,4 +11,4 @@ unsigned test(unsigned k, unsigned b) {
return a[0]+a[1];
}
-/* { dg-final { scan-tree-dump "Conditional store replacement" "cselim" } } */
+/* { dg-final { scan-tree-dump "Conditional store replacement" "cselim" {
xfail *-*-* } } } */
--- gcc/testsuite/gcc.dg/tree-ssa/pr89430-5.c.jj2020-01-12
11:54:37.606395410 +0100
+++ gcc/testsuite/gcc.dg/tree-ssa/pr89430-5.c 2020-04-24 11:26:59.782204277
+0200
@@ -13,4 +13,4 @@ int test(int b, int k) {
return a.data[0] + a.data[1];
}
-/* { dg-final { scan-tree-dump "Conditional store replacement" "cselim" } } */
+/* { dg-final { scan-tree-dump "Conditional store replacement" "cselim" {
xfail *-*-* } } } */
--- gcc/testsuite/gcc.dg/tree-ssa/pr89430-6.c.jj2020-01-12
11:54:37.606395410 +0100
+++ gcc/testsuite/gcc.dg/tree-ssa/pr89430-6.c 2020-04-24 11:27:06.456104170
+0200
@@ -16,4 +16,4 @@ int test(int b, int k)
Re: [PATCH] testsuite: C++14 vs. C++17 struct-layout-1.exp testing with ALT_CXX_UNDER_TEST [PR94383]
On Thu, 2020-04-23 at 21:08 +0200, Jakub Jelinek via Gcc-patches wrote:
> Hi!
>
> On Tue, Apr 21, 2020 at 11:57:02AM +0200, Jakub Jelinek wrote:
> > I haven't added (yet) checks if the alternate compiler does support these
> > options (I think that can be done incrementally), so for now this testing is
> > done only if the alternate compiler is not used.
>
> This patch does that, so now when testing against not too old compiler
> it can do the -std=c++14 vs. -std=c++17 testing also between under test and
> alt compilers.
>
> Tested on x86_64-linux, without ALT_CXX_UNDER_TEST (all tests still used),
> with ALT_CXX_UNDER_TEST=g++ (all tests still used too), and after tweaking
> it to test -std=c++20 instead of -std=c++17 that my system g++ doesn't
> support, where it only used tests before *_32* and bootstrapped/regtested
> on powerpc64{,le}-linux, ok for trunk?
>
> 2020-04-23 Jakub Jelinek
>
> PR c++/94383
> * g++.dg/compat/struct-layout-1.exp: Use the -std=c++14 vs. -std=c++17
> ABI compatibility testing even with ALT_CXX_UNDER_TEST, as long as
> that compiler accepts -std=c++14 and -std=c++17 options.
OK
jeff
>
[PATCH] c++: Avoid -Wreturn-type warning if a template fn calls noreturn template fn [PR94742]
Hi!
finish_call_expr already has code to set current_function_returns_abnormally
if a template calls a noreturn function, but on the following testcase it
doesn't call a FUNCTION_DECL, but TEMPLATE_DECL instead, in which case
we didn't check noreturn at all and just assumed it could return.
Fixed thusly, bootstrapped/regtested on powerpc64{,le}-linux, ok for trunk?
2020-04-24 Jakub Jelinek
PR c++/94742
* semantics.c (finish_call_expr): When looking if all overloads
are noreturn, use STRIP_TEMPLATE to look through TEMPLATE_DECLs.
* g++.dg/warn/Wreturn-type-12.C: New test.
--- gcc/cp/semantics.c.jj 2020-03-30 22:54:37.828795752 +0200
+++ gcc/cp/semantics.c 2020-04-24 14:30:36.001664888 +0200
@@ -2508,7 +2508,7 @@ finish_call_expr (tree fn, vec
+[[noreturn]] void
+foo (T const &t, char const *)
+{
+ throw T (t);
+}
+
+template
+int
+bar ()
+{
+ foo (42, __FUNCTION__);
+} // { dg-bogus "no return statement in function returning non-void" }
+
+int
+main ()
+{
+ bar();
+}
Jakub
[PATCH v4] aarch64: Add TX3 machine model
Here is the patch introducing thunderxt311 maching model
for the scheduler. A name for the new chip was added to the
list of the names to be recognized as a valid parameter for mcpu
and mtune flags. The TX2 cost model was reused for TX3.
The previously used "cryptic" name for the command line
parameter is replaced with the same "thunderxt311" name.
Added the new chip name to the documentation. Fixed
copyright names and dates.
Lowering the chip capabilities to v8.3 to be on the
safe side.
Bootstrapped on AArch64.
2020-04-23 Anton Youdkevitch
* config/aarch64/aarch64-cores.def: Add the chip name.
* config/aarch64/aarch64-tune.md: Regenerated.
* config/aarch64/aarch64.c: Add the cost tables for the chip.
* config/aarch64/thunderx3t11.md: New file: add the new
machine model for the scheduler
* config/aarch64/aarch64.md: Include the new model.
* doc/invoke.texi: Add the new name to the list
---
gcc/config/aarch64/aarch64-cores.def | 3 +
gcc/config/aarch64/aarch64-tune.md | 2 +-
gcc/config/aarch64/aarch64.c | 27 ++
gcc/config/aarch64/aarch64.md| 1 +
gcc/config/aarch64/thunderx3t11.md | 686 +
gcc/doc/invoke.texi | 2 +-
6 files changed, 719 insertions(+), 2 deletions(-)
>From 4c2c69ab7327bda62d2380139cd2825bcc647988 Mon Sep 17 00:00:00 2001
From: Anton Youdkevitch
Date: Mon, 23 Mar 2020 13:22:35 -0700
Subject: [PATCH] TX3 scheduling and tuning implementation
Added the scheduler descriptions for TX3 and the
cost tables borrowed them from TX2.
---
gcc/config/aarch64/aarch64-cores.def | 3 +
gcc/config/aarch64/aarch64-tune.md | 2 +-
gcc/config/aarch64/aarch64.c | 27 ++
gcc/config/aarch64/aarch64.md| 1 +
gcc/config/aarch64/thunderx3t11.md | 686 +++
gcc/doc/invoke.texi | 2 +-
6 files changed, 719 insertions(+), 2 deletions(-)
create mode 100644 gcc/config/aarch64/thunderx3t11.md
diff --git a/gcc/config/aarch64/aarch64-cores.def b/gcc/config/aarch64/aarch64-cores.def
index ea9b98b..4269c6c 100644
--- a/gcc/config/aarch64/aarch64-cores.def
+++ b/gcc/config/aarch64/aarch64-cores.def
@@ -95,6 +95,9 @@ AARCH64_CORE("vulcan", vulcan, thunderx2t99, 8_1A, AARCH64_FL_FOR_ARCH8_1 | AA
/* Cavium ('C') cores. */
AARCH64_CORE("thunderx2t99", thunderx2t99, thunderx2t99, 8_1A, AARCH64_FL_FOR_ARCH8_1 | AARCH64_FL_CRYPTO, thunderx2t99, 0x43, 0x0af, -1)
+/* Marvell cores (TX3). */
+AARCH64_CORE("thunderx3t11", thunderx3t11, thunderx3t11, 8_3A, AARCH64_FL_FOR_ARCH8_3 | AARCH64_FL_CRYPTO | AARCH64_FL_RCPC | AARCH64_FL_SM4 | AARCH64_FL_SHA3 | AARCH64_FL_F16FML | AARCH64_FL_RCPC8_4, thunderx3t11, 0x43, 0x0b8, 0x0a)
+
/* ARMv8.2-A Architecture Processors. */
/* ARM ('A') cores. */
diff --git a/gcc/config/aarch64/aarch64-tune.md b/gcc/config/aarch64/aarch64-tune.md
index 3cc1c4d..573a4a9 100644
--- a/gcc/config/aarch64/aarch64-tune.md
+++ b/gcc/config/aarch64/aarch64-tune.md
@@ -1,5 +1,5 @@
;; -*- buffer-read-only: t -*-
;; Generated automatically by gentune.sh from aarch64-cores.def
(define_attr "tune"
- "cortexa34,cortexa35,cortexa53,cortexa57,cortexa72,cortexa73,thunderx,thunderxt88p1,thunderxt88,octeontx,octeontxt81,octeontxt83,thunderxt81,thunderxt83,emag,xgene1,falkor,qdf24xx,exynosm1,phecda,thunderx2t99p1,vulcan,thunderx2t99,cortexa55,cortexa75,cortexa76,cortexa76ae,cortexa77,cortexa65,cortexa65ae,ares,neoversen1,neoversee1,octeontx2,octeontx2t98,octeontx2t96,octeontx2t93,octeontx2f95,octeontx2f95n,octeontx2f95mm,tsv110,saphira,cortexa57cortexa53,cortexa72cortexa53,cortexa73cortexa35,cortexa73cortexa53,cortexa75cortexa55,cortexa76cortexa55"
+ "cortexa34,cortexa35,cortexa53,cortexa57,cortexa72,cortexa73,thunderx,thunderxt88p1,thunderxt88,octeontx,octeontxt81,octeontxt83,thunderxt81,thunderxt83,emag,xgene1,falkor,qdf24xx,exynosm1,phecda,thunderx2t99p1,vulcan,thunderx2t99,thunderx3t11,cortexa55,cortexa75,cortexa76,cortexa76ae,cortexa77,cortexa65,cortexa65ae,ares,neoversen1,neoversee1,octeontx2,octeontx2t98,octeontx2t96,octeontx2t93,octeontx2f95,octeontx2f95n,octeontx2f95mm,tsv110,saphira,cortexa57cortexa53,cortexa72cortexa53,cortexa73cortexa35,cortexa73cortexa53,cortexa75cortexa55,cortexa76cortexa55"
(const (symbol_ref "((enum attr_tune) aarch64_tune)")))
diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index 24c055d..7abce6a 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -1216,6 +1216,33 @@ static const struct tune_params thunderx2t99_tunings =
&thunderx2t99_prefetch_tune
};
+static const struct tune_params thunderx3t11_tunings =
+{
+ &thunderx2t99_extra_costs,
+ &thunderx2t99_addrcost_table,
+ &thunderx2t99_regmove_cost,
+ &thunderx2t99_vector_cost,
+ &generic_branch_cost,
+ &generic_approx_modes,
+ SVE_NOT_IMPLEMENTED, /* sve_width */
+ 4, /* memmov_cost. */
+ 4, /* issue_rate. */
+ (AARCH64_FUSE_ALU_BRANCH | AARC
Re: [PATCH] cselim: Don't assume it is safe to cstore replace a store to a local variable with unknown offset [PR94734]
On Fri, 24 Apr 2020, Jakub Jelinek wrote:
> Hi!
>
> As the new testcase shows, it is not safe to assume we can optimize
> a conditional store into an automatic non-addressable var, we can do it
> only if we can prove that the unconditional load or store actually will
> not be outside of the boundaries of the variable.
> If the offset and size are constant, we can, but this is already all
> checked in !tree_could_trap_p, otherwise we really need to check for
> a dominating unconditional store, or for the specific case of automatic
> non-addressable variables, it is enough if there is a dominating load
> (that is what those 4 testcases have). tree-ssa-phiopt.c has some
> infrastructure for this already, see the add_or_mark_expr method etc.,
> but right now it handles only MEM_REFs with SSA_NAME first operand
> and some integral offset. So, I think it can be for GCC11 extended
> to handle other memory references, possibly up to just doing
> get_inner_reference and hasing based on the base, offset expressions
> and bit_offset and bit_size, and have also a special case that for
> !TREE_ADDRESSABLE automatic variables it could ignore whether something
> is a load or store because the local stack should be always writable.
> But it feels way too dangerous to do this this late for GCC10, so this
> patch just restricts the optimization to the safe case (where lhs doesn't
> trap), and on Richi's request also ignores TREE_ADDRESSABLE bit if
> flag_store_data_races, because my understanding the reason for
> TREE_ADDRESSABLE check is that we want to avoid introducing
> store data races (if address of an automatic var escapes, some other thread
> could be accessing it concurrently).
>
> Bootstrapped/regtested on powerpc64{,le}-linux, ok for trunk?
OK.
Thanks,
Richard.
> 2020-04-24 Jakub Jelinek
> Richard Biener
>
> PR tree-optimization/94734
> PR tree-optimization/89430
> * tree-ssa-phiopt.c: Include tree-eh.h.
> (cond_store_replacement): Return false if an automatic variable
> access could trap. If -fstore-data-races, don't return false
> just because an automatic variable is addressable.
>
> * gcc.dg/tree-ssa/pr89430-1.c: Add xfail.
> * gcc.dg/tree-ssa/pr89430-2.c: Add xfail.
> * gcc.dg/tree-ssa/pr89430-5.c: Add xfail.
> * gcc.dg/tree-ssa/pr89430-6.c: Add xfail.
> * gcc.c-torture/execute/pr94734.c: New test.
>
> --- gcc/tree-ssa-phiopt.c.jj 2020-03-19 10:23:50.542872359 +0100
> +++ gcc/tree-ssa-phiopt.c 2020-04-24 12:33:02.368355735 +0200
> @@ -45,6 +45,7 @@ along with GCC; see the file COPYING3.
> #include "tree-scalar-evolution.h"
> #include "tree-inline.h"
> #include "case-cfn-macros.h"
> +#include "tree-eh.h"
>
> static unsigned int tree_ssa_phiopt_worker (bool, bool, bool);
> static bool two_value_replacement (basic_block, basic_block, edge, gphi *,
> @@ -2237,10 +2238,13 @@ cond_store_replacement (basic_block midd
> whose value is not available readily, which we want to avoid. */
>if (!nontrap->contains (lhs))
> {
> - /* If LHS is a local variable without address-taken, we could
> + /* If LHS is an access to a local variable without address-taken
> + (or when we allow data races) and known not to trap, we could
>always safely move down the store. */
>tree base = get_base_address (lhs);
> - if (!auto_var_p (base) || TREE_ADDRESSABLE (base))
> + if (!auto_var_p (base)
> + || (TREE_ADDRESSABLE (base) && !flag_store_data_races)
> + || tree_could_trap_p (lhs))
> return false;
> }
>
> --- gcc/testsuite/gcc.dg/tree-ssa/pr89430-1.c.jj 2020-01-12
> 11:54:37.606395410 +0100
> +++ gcc/testsuite/gcc.dg/tree-ssa/pr89430-1.c 2020-04-24 11:26:45.021425675
> +0200
> @@ -9,4 +9,4 @@ unsigned test(unsigned k, unsigned b) {
> return a[0]+a[1];
> }
>
> -/* { dg-final { scan-tree-dump "Conditional store replacement" "cselim" } }
> */
> +/* { dg-final { scan-tree-dump "Conditional store replacement" "cselim" {
> xfail *-*-* } } } */
> --- gcc/testsuite/gcc.dg/tree-ssa/pr89430-2.c.jj 2020-01-12
> 11:54:37.606395410 +0100
> +++ gcc/testsuite/gcc.dg/tree-ssa/pr89430-2.c 2020-04-24 11:26:52.319316212
> +0200
> @@ -11,4 +11,4 @@ unsigned test(unsigned k, unsigned b) {
> return a[0]+a[1];
> }
>
> -/* { dg-final { scan-tree-dump "Conditional store replacement" "cselim" } }
> */
> +/* { dg-final { scan-tree-dump "Conditional store replacement" "cselim" {
> xfail *-*-* } } } */
> --- gcc/testsuite/gcc.dg/tree-ssa/pr89430-5.c.jj 2020-01-12
> 11:54:37.606395410 +0100
> +++ gcc/testsuite/gcc.dg/tree-ssa/pr89430-5.c 2020-04-24 11:26:59.782204277
> +0200
> @@ -13,4 +13,4 @@ int test(int b, int k) {
> return a.data[0] + a.data[1];
> }
>
> -/* { dg-final { scan-tree-dump "Conditional store replacement" "cselim" } }
> */
> +/* { dg-final { scan-tree-dump "Conditional store replacement" "cselim" {
> xfail *-*
[PATCH] rs6000: Properly handle LE index munging in vec_shr (PR94710)
The PR shows the compiler crashing with -mvsx -mlittle -O0. This turns
out to be caused by a failure to make of the higher bits in an index
endian conversion.
Tested on powerpc64-linux {-m32,-m64} and on powerpc64le-linux.
Committing to trunk.
(This will need backports).
Segher
2020-04-24 Segher Boessenkool
PR target/94710
* config/rs6000/vector.md (vec_shr_ for VEC_L): Correct little
endian byteshift_val calculation.
---
gcc/config/rs6000/vector.md | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/gcc/config/rs6000/vector.md b/gcc/config/rs6000/vector.md
index 5bc8f80..662521e 100644
--- a/gcc/config/rs6000/vector.md
+++ b/gcc/config/rs6000/vector.md
@@ -1426,7 +1426,8 @@ (define_expand "vec_shr_"
emit_move_insn (zero_reg, CONST0_RTX (mode));
if (!BYTES_BIG_ENDIAN)
{
- byteshift_val = 16 - byteshift_val;
+ /* Note, byteshift_val can be 0! */
+ byteshift_val = -byteshift_val & 15;
op1 = zero_reg;
op2 = operands[1];
}
--
1.8.3.1
[committed] amdgcn: Fix wrong-code bug in 64-bit masked add
This patch fixes a bug in which the high-part of a 64-bit add doesn't always merge in the masked lanes properly, depending on register allocation. Unfortunately I don't have a small reproducer for this one, so there's no testcase. Andrew amdgcn: Fix wrong-code bug in 64-bit masked add 2020-04-24 Andrew Stubbs gcc/ * config/gcn/gcn-valu.md (add_zext_dup2_exec): Fix merge of high-part. (add_sext_dup2_exec): Likewise. diff --git a/gcc/config/gcn/gcn-valu.md b/gcc/config/gcn/gcn-valu.md index 0422e153cf3..d3badb4059c 100644 --- a/gcc/config/gcn/gcn-valu.md +++ b/gcc/config/gcn/gcn-valu.md @@ -1497,7 +1497,8 @@ rtx dsthi = gcn_operand_part (mode, operands[0], 1); emit_insn (gen_vec_duplicate_exec (dsthi, gcn_operand_part (DImode, operands[2], 1), - gcn_gen_undef (mode), operands[4])); + gcn_operand_part (mode, operands[3], 1), + operands[4])); emit_insn (gen_addc3_exec (dsthi, dsthi, const0_rtx, vcc, vcc, gcn_operand_part (mode, operands[3], 1), @@ -1564,7 +1565,8 @@ rtx dsthi = gcn_operand_part (mode, operands[0], 1); emit_insn (gen_vec_duplicate_exec (dsthi, gcn_operand_part (DImode, operands[2], 1), - gcn_gen_undef (mode), operands[4])); + gcn_operand_part (mode, operands[3], 1), + operands[4])); emit_insn (gen_addc3_exec (dsthi, dsthi, operands[5], vcc, vcc, gcn_operand_part (mode, operands[3], 1),
[PATCH] Enable Intel CET in liblto_plugin.so on Intel CET enabled host
Since ld is Intel CET enabled on Intel CET enabled host, dlopen fails on
liblto_plugin.so if it isn't Intel CET enabled. Add GCC_CET_HOST_FLAGS
to cet.m4, use it in libiberty and lto-plugin to always enable Intel
CET in liblto_plugin.so on Intel CET enabled host.
On Linux/x86 host, enable Intel CET by default if assembler and compiler
support Intel CET so that generated the liblto_plugin.so can be used on
both CET and non-CET machines. It is an error to disable Intel CET in
liblto_plugin.so on Intel CET enabled host.
OK for master?
Thanks.
H.J.
---
config/
PR bootstrap/94739
* cet.m4 (GCC_CET_HOST_FLAGS): New.
libiberty/
PR bootstrap/94739
* Makefile.in (COMPILE.c): Add @CET_HOST_FLAGS@.
(configure_deps): Add $(srcdir)/../config/cet.m4 and
$(srcdir)/../config/enable.m4.
* aclocal.m4: Include ../config/cet.m4 and ../config/enable.m4.
* configure.ac: Add GCC_CET_HOST_FLAGS(CET_HOST_FLAGS) and
AC_SUBST(CET_HOST_FLAGS).
* configure: Regenerated.
lto-plugin/
PR bootstrap/94739
* Makefile.am (AM_CFLAGS): Add $(CET_HOST_FLAGS).
* configure.ac: Add GCC_CET_HOST_FLAGS(CET_HOST_FLAGS) and
AC_SUBST(CET_HOST_FLAGS).
* Makefile.in: Regenerated.
* aclocal.m4: Likewise.
* configure: Likewise.
---
config/cet.m4 | 94 +
libiberty/Makefile.in | 5 +-
libiberty/aclocal.m4| 2 +
libiberty/configure | 145 ++
libiberty/configure.ac | 3 +
lto-plugin/Makefile.am | 2 +-
lto-plugin/Makefile.in | 5 +-
lto-plugin/aclocal.m4 | 2 +
lto-plugin/configure| 149 +++-
lto-plugin/configure.ac | 3 +
10 files changed, 405 insertions(+), 5 deletions(-)
diff --git a/config/cet.m4 b/config/cet.m4
index b53c1bbd5cd..8b9e01fd492 100644
--- a/config/cet.m4
+++ b/config/cet.m4
@@ -48,3 +48,97 @@ else
AC_MSG_RESULT([no])
fi
])
+
+dnl
+dnl GCC_CET_HOST_FLAGS
+dnl(SHELL-CODE_HANDLER)
+dnl
+AC_DEFUN([GCC_CET_HOST_FLAGS],[dnl
+GCC_ENABLE(cet, auto, ,[enable Intel CET in host libraries],
+ permit yes|no|auto)
+AC_MSG_CHECKING([for CET support])
+
+case "$host" in
+ i[[34567]]86-*-linux* | x86_64-*-linux*)
+may_have_cet=yes
+save_CFLAGS="$CFLAGS"
+CFLAGS="$CFLAGS -fcf-protection"
+case "$enable_cet" in
+ auto)
+ # Check if target supports multi-byte NOPs
+ # and if assembler supports CET insn.
+ AC_COMPILE_IFELSE(
+[AC_LANG_PROGRAM(
+ [],
+ [
+#if !defined(__SSE2__)
+#error target does not support multi-byte NOPs
+#else
+asm ("setssbsy");
+#endif
+ ])],
+[enable_cet=yes],
+[enable_cet=no])
+ ;;
+ yes)
+ # Check if assembler supports CET.
+ AC_COMPILE_IFELSE(
+[AC_LANG_PROGRAM(
+ [],
+ [asm ("setssbsy");])],
+[],
+[AC_MSG_ERROR([assembler with CET support is required for
--enable-cet])])
+ ;;
+esac
+CFLAGS="$save_CFLAGS"
+;;
+ *)
+may_have_cet=no
+enable_cet=no
+;;
+esac
+
+if test x$may_have_cet = xyes; then
+ save_LDFLAGS="$LDFLAGS"
+ LDFLAGS="$LDFLAGS -Wl,-z,ibt,-z,shstk"
+ AC_TRY_RUN([
+static void
+foo (void)
+{
+}
+
+static void
+__attribute__ ((noinline, noclone))
+xxx (void (*f) (void))
+{
+ f ();
+}
+
+static void
+__attribute__ ((noinline, noclone))
+bar (void)
+{
+ xxx (foo);
+}
+
+int
+main ()
+{
+ bar ();
+ return 0;
+}
+ ],
+ [have_cet=no],
+ [have_cet=yes])
+ LDFLAGS="$save_LDFLAGS"
+ if test x$enable_cet = xno -a x$have_cet = xyes; then
+AC_MSG_ERROR([Intel CET must be enabled on Intel CET enabled host])
+ fi
+fi
+if test x$enable_cet = xyes; then
+ $1="-fcf-protection"
+ AC_MSG_RESULT([yes])
+else
+ AC_MSG_RESULT([no])
+fi
+])
diff --git a/libiberty/Makefile.in b/libiberty/Makefile.in
index fe738d0db43..d6b302e02fd 100644
--- a/libiberty/Makefile.in
+++ b/libiberty/Makefile.in
@@ -112,7 +112,8 @@ installcheck: installcheck-subdir
INCDIR=$(srcdir)/$(MULTISRCTOP)../include
COMPILE.c = $(CC) -c @DEFS@ $(CFLAGS) $(CPPFLAGS) -I. -I$(INCDIR) \
- $(HDEFINES) @ac_libiberty_warn_cflags@ -D_GNU_SOURCE
+ $(HDEFINES) @ac_libiberty_warn_cflags@ -D_GNU_SOURCE \
+ @CET_HOST_FLAGS@
# Just to make sure we don't use a built-in rule with VPATH
.c.$(objext):
@@ -481,6 +482,8 @@ config.status: $(srcdir)/configure
AUTOCONF = autoconf
configure_deps = $(srcdir)/aclocal.m4 \
$(srcdir)/../config/acx.m4 \
+ $(srcdir)/../config/cet.m4 \
+ $(srcdir)/../config/enable.m4 \
$(srcdir)/../config/no-executables.m4 \
$(srcdir)/../config/override.m4 \
$(srcdir)/../config/picflag.m4 \
diff --git a/libiberty/aclocal.m4 b/libiberty/aclocal.m4
index bf8a907100f..34c0a5bab62 100644
--- a/libiberty/aclocal.m4
+++ b/libiberty/aclocal.m4
@@ -1,4 +1,6 @@
sinclude(../config/acx.m4)
+si
[PATCH] c++: add "'requires' only available with ..." note
This adds a note suggesting to enable concepts whenever 'requires' is parsed as
an invalid type name with concepts disabled.
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK to commit?
gcc/cp/ChangeLog:
* parser.c (cp_parser_diagnose_invalid_type_name): Suggest to enable
concepts if the invalid identifier is 'requires'.
gcc/testsuite/ChangeLog:
* g++.dg/concepts/diagnostic11.C: New test.
---
gcc/cp/parser.c | 3 +++
gcc/testsuite/g++.dg/concepts/diagnostic11.C | 6 ++
2 files changed, 9 insertions(+)
create mode 100644 gcc/testsuite/g++.dg/concepts/diagnostic11.C
diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index 47e3f2bbd3d..337f22d2784 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -3378,6 +3378,9 @@ cp_parser_diagnose_invalid_type_name (cp_parser *parser,
tree id,
else if (!flag_concepts && id == ridpointers[(int)RID_CONCEPT])
inform (location, "% only available with %<-std=c++2a%> or "
"%<-fconcepts%>");
+ else if (!flag_concepts && id == ridpointers[(int)RID_REQUIRES])
+ inform (location, "% only available with %<-std=c++2a%> or "
+ "%<-fconcepts%>");
else if (processing_template_decl && current_class_type
&& TYPE_BINFO (current_class_type))
{
diff --git a/gcc/testsuite/g++.dg/concepts/diagnostic11.C
b/gcc/testsuite/g++.dg/concepts/diagnostic11.C
new file mode 100644
index 000..7c60912352a
--- /dev/null
+++ b/gcc/testsuite/g++.dg/concepts/diagnostic11.C
@@ -0,0 +1,6 @@
+// { dg-do compile { target c++17_only } }
+
+template
+ requires B // { dg-error ".requires. does not name a type" }
+// { dg-message ".requires. only available with" "" { target *-*-* } .-1 }
+void foo() { }
--
2.26.2.266.ge870325ee8
Re: [PATCH v2] c++: Explicit constructor called in copy-initialization [PR90320]
On 4/23/20 7:08 PM, Marek Polacek wrote:
On Thu, Apr 23, 2020 at 02:48:38PM -0400, Jason Merrill wrote:
On 4/22/20 11:27 PM, Marek Polacek wrote:
This test is rejected with a bogus "use of deleted function" error
starting with r225705 whereby convert_like_real/ck_base no longer
sets LOOKUP_ONLYCONVERTING for user_conv_p conversions. This does
not seem to be always correct. To recap, when we have something like
T t = x where T is a class type and the type of x is not T or derived
from T, we perform copy-initialization, something like:
1. choose a user-defined conversion to convert x to T, the result is
a prvalue,
2. use this prvalue to direct-initialize t.
In the second step, explicit constructors should be considered, since
we're direct-initializing. This is what r225705 fixed.
In this PR we are dealing with the first step, I think, where explicit
constructors should be skipped. [over.match.copy] says "The converting
constructors of T are candidate functions" which clearly eliminates
explicit constructors. But we also have to copy-initialize the argument
we are passing to such a converting constructor, and here we should
disregard explicit constructors too.
In this testcase we have
V v = m;
and we choose V::V(M) to convert m to V. But we wrongly choose
the explicit M::M(M&) to copy-initialize the argument; it's
a better match for a non-const lvalue than the implicit M::M(const M&)
but because it's explicit, we shouldn't use it.
When convert_like is processing the ck_user conversion -- the convfn is
V::V(M) -- it can see that cand->flags contains LOOKUP_ONLYCONVERTING,
but then when we're in build_over_call for this convfn, we have no way
to pass the flag to convert_like for the argument 'm', because convert_like
doesn't take flags. So I've resorted to setting need_temporary_p in
a ck_rvalue, thus far unused, to signal that we're only interested in
non-explicit constructors.
LOOKUP_COPY_PARM looks relevant, but again, it's a LOOKUP_* flag, so
can't pass it to convert_like. DR 899 also seemed related, but that
deals with direct-init contexts only.
Does this make sense?
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
PR c++/90320
* call.c (standard_conversion): Set need_temporary_p if FLAGS demands
LOOKUP_ONLYCONVERTING.
(convert_like_real) : If a ck_rvalue has
need_temporary_p set, or LOOKUP_ONLYCONVERTING into FLAGS.
* g++.dg/cpp0x/explicit13.C: New test.
---
gcc/cp/call.c | 24 +---
gcc/testsuite/g++.dg/cpp0x/explicit13.C | 14 ++
2 files changed, 31 insertions(+), 7 deletions(-)
create mode 100644 gcc/testsuite/g++.dg/cpp0x/explicit13.C
diff --git a/gcc/cp/call.c b/gcc/cp/call.c
index c58231601c9..d802f1a0c2f 100644
--- a/gcc/cp/call.c
+++ b/gcc/cp/call.c
@@ -92,10 +92,10 @@ struct conversion {
language standards, e.g. disregarding pointer qualifiers or
converting integers to pointers. */
BOOL_BITFIELD bad_p : 1;
- /* If KIND is ck_ref_bind ck_base_conv, true to indicate that a
+ /* If KIND is ck_ref_bind or ck_base, true to indicate that a
temporary should be created to hold the result of the
- conversion. If KIND is ck_ambig or ck_user, true means force
- copy-initialization. */
+ conversion. If KIND is ck_ambig, ck_rvalue, or ck_user, true means
+ force copy-initialization. */
BOOL_BITFIELD need_temporary_p : 1;
/* If KIND is ck_ptr or ck_pmem, true to indicate that a conversion
from a pointer-to-derived to pointer-to-base is being performed. */
@@ -1252,6 +1252,8 @@ standard_conversion (tree to, tree from, tree expr, bool
c_cast_p,
if (flags & LOOKUP_PREFER_RVALUE)
/* Tell convert_like_real to set LOOKUP_PREFER_RVALUE. */
conv->rvaluedness_matches_p = true;
+ if (flags & LOOKUP_ONLYCONVERTING)
+ conv->need_temporary_p = true;
Presumably we want the same thing for ck_base?
We actually already set need_temporary_p for ck_base in standard_conversion:
1529 conv->need_temporary_p = !(flags & LOOKUP_NO_TEMP_BIND);
Hmm, yes. So with your patch the flag means different things for
ck_base and ck_rvalue. This suggests to me that overloading
need_temporary_p to also indicate copy-initialization is problematic,
and we should move that information to a new flag.
@@ -7654,10 +7656,18 @@ convert_like_real (conversion *convs, tree expr, tree
fn, int argnum,
destination [is treated as direct-initialization]. [dcl.init] */
flags = LOOKUP_NORMAL;
if (convs->user_conv_p)
- /* This conversion is being done in the context of a user-defined
- conversion (i.e. the second step of copy-initialization), so
- don't allow any more. */
- flags |= LOOKUP_NO_CONVERSION;
+ {
+ /* This conversion is being done in the context of a user-defined
+conversion
Re: [PATCH] c++: Avoid -Wreturn-type warning if a template fn calls noreturn template fn [PR94742]
On 4/24/20 1:12 PM, Jakub Jelinek wrote:
Hi!
finish_call_expr already has code to set current_function_returns_abnormally
if a template calls a noreturn function, but on the following testcase it
doesn't call a FUNCTION_DECL, but TEMPLATE_DECL instead, in which case
we didn't check noreturn at all and just assumed it could return.
Fixed thusly, bootstrapped/regtested on powerpc64{,le}-linux, ok for trunk?
OK.
2020-04-24 Jakub Jelinek
PR c++/94742
* semantics.c (finish_call_expr): When looking if all overloads
are noreturn, use STRIP_TEMPLATE to look through TEMPLATE_DECLs.
* g++.dg/warn/Wreturn-type-12.C: New test.
--- gcc/cp/semantics.c.jj 2020-03-30 22:54:37.828795752 +0200
+++ gcc/cp/semantics.c 2020-04-24 14:30:36.001664888 +0200
@@ -2508,7 +2508,7 @@ finish_call_expr (tree fn, vec
+[[noreturn]] void
+foo (T const &t, char const *)
+{
+ throw T (t);
+}
+
+template
+int
+bar ()
+{
+ foo (42, __FUNCTION__);
+} // { dg-bogus "no return statement in function returning non-void" }
+
+int
+main ()
+{
+ bar();
+}
Jakub
Re: [PATCH] c++: add "'requires' only available with ..." note
On 4/24/20 3:52 PM, Patrick Palka wrote:
This adds a note suggesting to enable concepts whenever 'requires' is parsed as
an invalid type name with concepts disabled.
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK to commit?
OK.
gcc/cp/ChangeLog:
* parser.c (cp_parser_diagnose_invalid_type_name): Suggest to enable
concepts if the invalid identifier is 'requires'.
gcc/testsuite/ChangeLog:
* g++.dg/concepts/diagnostic11.C: New test.
---
gcc/cp/parser.c | 3 +++
gcc/testsuite/g++.dg/concepts/diagnostic11.C | 6 ++
2 files changed, 9 insertions(+)
create mode 100644 gcc/testsuite/g++.dg/concepts/diagnostic11.C
diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index 47e3f2bbd3d..337f22d2784 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -3378,6 +3378,9 @@ cp_parser_diagnose_invalid_type_name (cp_parser *parser,
tree id,
else if (!flag_concepts && id == ridpointers[(int)RID_CONCEPT])
inform (location, "% only available with %<-std=c++2a%> or "
"%<-fconcepts%>");
+ else if (!flag_concepts && id == ridpointers[(int)RID_REQUIRES])
+ inform (location, "% only available with %<-std=c++2a%> or "
+ "%<-fconcepts%>");
else if (processing_template_decl && current_class_type
&& TYPE_BINFO (current_class_type))
{
diff --git a/gcc/testsuite/g++.dg/concepts/diagnostic11.C
b/gcc/testsuite/g++.dg/concepts/diagnostic11.C
new file mode 100644
index 000..7c60912352a
--- /dev/null
+++ b/gcc/testsuite/g++.dg/concepts/diagnostic11.C
@@ -0,0 +1,6 @@
+// { dg-do compile { target c++17_only } }
+
+template
+ requires B // { dg-error ".requires. does not name a type" }
+// { dg-message ".requires. only available with" "" { target *-*-* } .-1 }
+void foo() { }
Re: [PATCH v2] aarch64: Fix .cfi_window_save with pac-ret [PR94515]
On 4/24/20 4:19 AM, Szabolcs Nagy wrote:
On aarch64 -mbranch-protection=pac-ret reuses the dwarf
opcode for window_save to mean "toggle the return address
mangle state", but in the dwarf2cfi internal logic the
state was not updated when an opcode was emitted, the
currently present update logic is only valid for the
original sparc use of window_save so a separate bool is
used on aarch64 to track the state.
This bug can cause the unwinder not to authenticate return
addresses that were signed (or vice versa) which means a
runtime crash on a pauth enabled system.
Currently only aarch64 pac-ret uses REG_CFA_TOGGLE_RA_MANGLE.
I suppose factoring things so that this logic could live in the backend
is too much trouble for how small the code is. The patch is OK.
This should be backported to gcc-9 and gcc-8 branches.
gcc/ChangeLog:
2020-04-23 Szabolcs Nagy
PR target/94515
* dwarf2cfi.c (struct GTY): Add ra_mangled.
(cfi_row_equal_p): Check ra_mangled.
(dwarf2out_frame_debug_cfa_window_save): Remove the argument,
this only handles the sparc logic now.
(dwarf2out_frame_debug_cfa_toggle_ra_mangle): New function for
the aarch64 specific logic.
(dwarf2out_frame_debug): Update to use the new subroutines.
(change_cfi_row): Check ra_mangled.
gcc/testsuite/ChangeLog:
2020-04-23 Szabolcs Nagy
PR target/94515
* g++.target/aarch64/pr94515-1.C: New test.
* g++.target/aarch64/pr94515-2.C: New test.
---
gcc/dwarf2cfi.c | 40 ++
gcc/testsuite/g++.target/aarch64/pr94515-1.C | 44
gcc/testsuite/g++.target/aarch64/pr94515-2.C | 41 ++
3 files changed, 118 insertions(+), 7 deletions(-)
create mode 100644 gcc/testsuite/g++.target/aarch64/pr94515-1.C
create mode 100644 gcc/testsuite/g++.target/aarch64/pr94515-2.C
diff --git a/gcc/dwarf2cfi.c b/gcc/dwarf2cfi.c
index 229fbfacc30..fa9e6089b2a 100644
--- a/gcc/dwarf2cfi.c
+++ b/gcc/dwarf2cfi.c
@@ -71,6 +71,9 @@ struct GTY(()) dw_cfi_row
/* True if the register window is saved. */
bool window_save;
+
+ /* True if the return address is in a mangled state. */
+ bool ra_mangled;
};
/* The caller's ORIG_REG is saved in SAVED_IN_REG. */
@@ -772,6 +775,9 @@ cfi_row_equal_p (dw_cfi_row *a, dw_cfi_row *b)
if (a->window_save != b->window_save)
return false;
+ if (a->ra_mangled != b->ra_mangled)
+return false;
+
return true;
}
@@ -1370,20 +1376,33 @@ dwarf2out_frame_debug_cfa_restore (rtx reg)
}
/* A subroutine of dwarf2out_frame_debug, process a REG_CFA_WINDOW_SAVE.
- FAKE is true if this is not really a window save but something else.
??? Perhaps we should note in the CIE where windows are saved (instead
of assuming 0(cfa)) and what registers are in the window. */
static void
-dwarf2out_frame_debug_cfa_window_save (bool fake)
+dwarf2out_frame_debug_cfa_window_save (void)
+{
+ dw_cfi_ref cfi = new_cfi ();
+
+ cfi->dw_cfi_opc = DW_CFA_GNU_window_save;
+ add_cfi (cfi);
+ cur_row->window_save = true;
+}
+
+/* A subroutine of dwarf2out_frame_debug, process a REG_CFA_TOGGLE_RA_MANGLE.
+ Note: DW_CFA_GNU_window_save dwarf opcode is reused for toggling RA mangle
+ state, this is a target specific operation on AArch64 and can only be used
+ on other targets if they don't use the window save operation otherwise. */
+
+static void
+dwarf2out_frame_debug_cfa_toggle_ra_mangle (void)
{
dw_cfi_ref cfi = new_cfi ();
cfi->dw_cfi_opc = DW_CFA_GNU_window_save;
add_cfi (cfi);
- if (!fake)
-cur_row->window_save = true;
+ cur_row->ra_mangled = !cur_row->ra_mangled;
}
/* Record call frame debugging information for an expression EXPR,
@@ -2143,13 +2162,12 @@ dwarf2out_frame_debug (rtx_insn *insn)
break;
case REG_CFA_TOGGLE_RA_MANGLE:
- /* This uses the same DWARF opcode as the next operation. */
- dwarf2out_frame_debug_cfa_window_save (true);
+ dwarf2out_frame_debug_cfa_toggle_ra_mangle ();
handled_one = true;
break;
case REG_CFA_WINDOW_SAVE:
- dwarf2out_frame_debug_cfa_window_save (false);
+ dwarf2out_frame_debug_cfa_window_save ();
handled_one = true;
break;
@@ -2221,6 +2239,14 @@ change_cfi_row (dw_cfi_row *old_row, dw_cfi_row *new_row)
cfi->dw_cfi_opc = DW_CFA_GNU_window_save;
add_cfi (cfi);
}
+
+ if (old_row->ra_mangled != new_row->ra_mangled)
+{
+ dw_cfi_ref cfi = new_cfi ();
+ /* DW_CFA_GNU_window_save is reused for toggling RA mangle state. */
+ cfi->dw_cfi_opc = DW_CFA_GNU_window_save;
+ add_cfi (cfi);
+}
}
/* Examine CFI and return true if a cfi label and set_loc is needed
diff --git a/gcc/testsuite/g++.target/aarch64/pr94515-1.C
b/gcc/testsuite/g++.target/aarch64/pr94515-1.C
new file mode 100644
index 000..cd63f4fb2
Re: [PATCH v2] rs6000: Don't use HARD_FRAME_POINTER_REGNUM if it's not live in pro_and_epilogue (PR91518)
Hi!
On Fri, Apr 17, 2020 at 01:35:15PM +0800, luoxhu wrote:
> On 2020/4/17 08:52, Segher Boessenkool wrote:
> > On Mon, Apr 13, 2020 at 10:11:43AM +0800, luoxhu wrote:
> >> frame_pointer_needed is set to true in reload pass setup_can_eliminate,
> >> but regs_ever_live[31] is false, pro_and_epilogue uses it without live
> >> check causing CPU2006 465.tonto segment fault of loading from invalid
> >> addresses due to r31 not saved/restored. Thus, add
> >> HARD_FRAME_POINTER_REGNUM
> >> live check with frame_pointer_needed_indeed_p when generating
> >> pro_and_epilogue
> >> instructions.
> >
> > I see.
> >
> > Can you instead make a boolean variable "frame_pointer_needed_indeed",
> > that you set somewhere early in *logue processing? So that we can be
> > sure that it will not change behind our backs.
>
>
> Thanks, rs6000_emit_prologue seems the proper place to set the
> frame_pointer_needed_indeed,
Yeah.
> but it's strange that hard_frame_pointer_rtx will be marked USE in
> make_prologue_seq, also
This is for when profiling is enabled. If this routine itself does not
use the hard frame pointer, the profiling code (not generated by GCC
here!) could still use it, so we need the USE to make sure later GCC
passes will see the hard frame pointer as live.
This is generic code; it isn't relevant for rs6000 I think.
> need check here though not causing segfault?
I'm not sure how it would?
> function.c
> static rtx_insn *
> make_prologue_seq (void)
> {
> if (!targetm.have_prologue ())
> return NULL;
>
> start_sequence ();
> rtx_insn *seq = targetm.gen_prologue ();
> emit_insn (seq);
>
> /* Insert an explicit USE for the frame pointer
> if the profiling is on and the frame pointer is required. */
> if (crtl->profile && frame_pointer_needed)
> emit_use (hard_frame_pointer_rtx);
> ...
> Any way, update the patch as below with your previous comments:
>
>
>
> This bug is exposed by FRE refactor of r263875. Comparing the fre
> dump file shows no obvious change of the segment fault function proves
> it to be a target issue.
> frame_pointer_needed is set to true in reload pass setup_can_eliminate,
> but regs_ever_live[31] is false, pro_and_epilogue uses it without live
> check causing CPU2006 465.tonto segment fault of loading from invalid
> addresses due to r31 not saved/restored. Thus, add HARD_FRAME_POINTER_REGNUM
> live check with frame_pointer_needed_indeed when generating pro_and_epilogue
> instructions.
>
> Bootstrap and regression tested pass on Power8-LE. Backport to gcc-9
> required once approved.
>
> gcc/ChangeLog
>
> 2020-04-17 Xiong Hu Luo
>
> PR target/91518
> * config/rs6000/rs6000-logue.c (frame_pointer_needed_indeed):
> New variable.
> (rs6000_emit_prologue_components):
> Check with frame_pointer_needed_indeed.
> (rs6000_emit_epilogue_components): Likewise.
> (rs6000_emit_epilogue): Likewise.
> (rs6000_emit_prologue): Set frame_pointer_needed_indeed.
The patch is okay for trunk. (And for backports later). Thank you!
Segher
Re: [PATCH] RS6000: Use .machine ppc for some CRT files
On Fri, Apr 17, 2020 at 07:59:02AM +0200, Sebastian Huber wrote: > would you mind having a look at this patch. Hi! I see no patch? Segher
Re: [PATCH,rs6000] enable -fweb for small loops unrolling
Hi! On Mon, Apr 20, 2020 at 09:57:31PM +0800, guojiufu wrote: > Previously -fweb was disabled if only unroll small loops. After that > we find there is cases where it could help to rename pseudos and aovid > some anti-dependence which may occur after unroll. > > Below is a patch to disable -fweb during loop unrolling. > > Bootstrap and regtest pass on powerpc, spec2017 run shows no performance > downgrade. > > Is this ok for trunk? Yes, this is fine for trunk. Thank you! A changelog nit: > gcc/ > 2020-04-20 Jiufu Guo > > * common/config/rs6000/rs6000-common.c > (rs6000_option_optimization_table)[OPT_LEVELS_ALL]: Remove turn off > -fweb. There should be a space before the "[". Segher
[committed] d: Fix order of precedence for -defaultlib and -debuglib
Hi,
The order of precedence used by the upstream reference compiler for
determining what library to link against is:
- No library if -nophoboslib or -fno-druntime was seen.
- The library passed to -debuglib if -g was also seen.
- The library passed to -defaultlib
- The in-tree libgphobos library.
This patch aligns the D language driver to follow the same rules.
Bootstrapped and regression tested on x86_64-linux-gnu, and committed to
mainline.
Regards
Iain.
---
gcc/d/ChangeLog:
* d-spec.cc (need_phobos): Remove.
(lang_specific_driver): Replace need_phobos with phobos_library.
Reorder -debuglib and -defaultlib to have precedence over libphobos.
(lang_specific_pre_link): Remove test for need_phobos.
---
gcc/d/d-spec.cc | 84 +
1 file changed, 36 insertions(+), 48 deletions(-)
diff --git a/gcc/d/d-spec.cc b/gcc/d/d-spec.cc
index e0844222520..f4744763ab6 100644
--- a/gcc/d/d-spec.cc
+++ b/gcc/d/d-spec.cc
@@ -61,10 +61,6 @@ enum phobos_action
static phobos_action phobos_library = PHOBOS_DEFAULT;
-/* If true, use the standard D runtime library when linking with
- standard libraries. */
-static bool need_phobos = true;
-
/* If true, do load libgphobos.spec even if not needed otherwise. */
static bool need_spec = false;
@@ -151,13 +147,15 @@ lang_specific_driver (cl_decoded_option
**in_decoded_options,
break;
case OPT_nophoboslib:
- need_phobos = false;
+ phobos_library = PHOBOS_NOLINK;
args[i] |= SKIPOPT;
break;
case OPT_fdruntime:
if (!value)
- need_phobos = false;
+ phobos_library = PHOBOS_NOLINK;
+ else
+ phobos_library = PHOBOS_LINK;
break;
case OPT_defaultlib_:
@@ -165,7 +163,6 @@ lang_specific_driver (cl_decoded_option
**in_decoded_options,
free (CONST_CAST (char *, defaultlib));
if (arg != NULL)
{
- need_phobos = false;
args[i] |= SKIPOPT;
defaultlib = XNEWVEC (char, strlen (arg));
strcpy (CONST_CAST (char *, defaultlib), arg);
@@ -177,7 +174,6 @@ lang_specific_driver (cl_decoded_option
**in_decoded_options,
free (CONST_CAST (char *, debuglib));
if (arg != NULL)
{
- need_phobos = false;
args[i] |= SKIPOPT;
debuglib = XNEWVEC (char, strlen (arg));
strcpy (CONST_CAST (char *, debuglib), arg);
@@ -314,10 +310,11 @@ lang_specific_driver (cl_decoded_option
**in_decoded_options,
#endif
/* Make sure to have room for the trailing NULL argument.
- - needstdcxx might add `-lstdcxx'
+ - need_stdcxx might add `-lstdcxx'
- libphobos adds `-Bstatic -lphobos -Bdynamic'
- only_source adds 1 more arg, also maybe add `-o'. */
- num_args = argc + need_stdcxx + shared_libgcc + need_phobos * 4 + 2;
+ num_args = argc + need_stdcxx + shared_libgcc
++ (phobos_library != PHOBOS_NOLINK) * 4 + 2;
new_decoded_options = XNEWVEC (cl_decoded_option, num_args);
i = 0;
@@ -409,60 +406,51 @@ lang_specific_driver (cl_decoded_option
**in_decoded_options,
}
/* Add `-lgphobos' if we haven't already done so. */
- if (phobos_library != PHOBOS_NOLINK && need_phobos)
+ if (phobos_library != PHOBOS_NOLINK)
{
/* Default to static linking. */
if (phobos_library != PHOBOS_DYNAMIC)
phobos_library = PHOBOS_STATIC;
#ifdef HAVE_LD_STATIC_DYNAMIC
- if (phobos_library == PHOBOS_DYNAMIC && static_link)
- {
- generate_option (OPT_Wl_, LD_DYNAMIC_OPTION, 1, CL_DRIVER,
- &new_decoded_options[j]);
- j++;
- }
- else if (phobos_library == PHOBOS_STATIC && !static_link)
+ if (phobos_library == PHOBOS_STATIC && !static_link)
{
generate_option (OPT_Wl_, LD_STATIC_OPTION, 1, CL_DRIVER,
- &new_decoded_options[j]);
- j++;
+ &new_decoded_options[j++]);
}
#endif
-
- generate_option (OPT_l,
- saw_profile_flag ? LIBPHOBOS_PROFILE : LIBPHOBOS, 1,
- CL_DRIVER, &new_decoded_options[j]);
- added_libraries++;
- j++;
-
-#ifdef HAVE_LD_STATIC_DYNAMIC
- if (phobos_library == PHOBOS_DYNAMIC && static_link)
+ /* Order of precedence in determining what library to link against is:
+- `-l' from `-debuglib=' if `-g' was also seen.
+- `-l' from `-defaultlib='.
+- `-lgphobos' unless `-nophoboslib' or `-fno-druntime' was seen. */
+ if (debuglib && saw_debug_flag)
{
- generate_option (OPT_Wl_, LD_STATIC_OPTION, 1, CL_DRIVER,
- &new_decoded_options[j]);
- j++;
+ generate_option (OPT_l, debuglib, 1, CL_DRIVER,
+ &new_decoded_options[j++]);
+ added_libraries++;
}
Re: [PATCH] RS6000: Use .machine ppc for some CRT files
On 4/17/20 12:59 AM, Sebastian Huber wrote: > Hello Segher, > > would you mind having a look at this patch. > His patch is here: https://gcc.gnu.org/pipermail/gcc-patches/2020-April/543396.html Peter
Re: [PATCH, V5] PowerPC Turn on -mpcrel by default for -mcpu=future
Hi!
On Wed, Apr 22, 2020 at 12:53:03AM -0400, Michael Meissner wrote:
> 2020-04-21 Michael Meissner
>
> * config/rs6000/linux64.h (PCREL_SUPPORTED_BY_OS): Define to
> enable PC-relative addressing for -mcpu=future.
> * config/rs6000/rs6000-cpus.def (ISA_FUTURE_MASKS_SERVER): Move
> after OTHER_FUTURE_MASKS. Use OTHER_FUTURE_MASKS.
> * config/rs6000/rs6000.c (PCREL_SUPPORTED_BY_OS): If not defined,
> suppress PC-relative addressing.
> (rs6000_option_override_internal): Split up error messages
> checking for -mprefixed and -mpcrel. Enable -mpcrel if the target
> system supports it.
>
> --- /tmp/ud7l8s_linux64.h 2020-04-21 16:09:26.761209165 -0400
> +++ gcc/config/rs6000/linux64.h 2020-04-21 16:04:59.432652447 -0400
> @@ -640,3 +640,10 @@ extern int dot_symbols;
> enabling the __float128 keyword. */
> #undef TARGET_FLOAT128_ENABLE_TYPE
> #define TARGET_FLOAT128_ENABLE_TYPE 1
> +
> +/* Enable using prefixed PC-relative addressing on the 'future' machine if
> the
> + ABI supports it. The ELF v2 ABI only supports PC-relative relocations for
> + the medium code model. */
> +#define PCREL_SUPPORTED_BY_OS(TARGET_FUTURE && TARGET_PREFIXED
> \
> + && ELFv2_ABI_CHECK \
> + && (TARGET_CMODEL == CMODEL_MEDIUM))
No extra parens around comparisons please. If the macros malfunction
without it, fix the macros!
> + /* If the ABI has support for PC-relative relocations, enable it by
> default.
> + This test depends on the sub-target tests above setting the code model
> to
> + medium for ELF v2 systems. */
> + if (PCREL_SUPPORTED_BY_OS
> + && (rs6000_isa_flags_explicit & OPTION_MASK_PCREL) == 0)
> +rs6000_isa_flags |= OPTION_MASK_PCREL;
> +
>/* -mpcrel requires -mcmodel=medium, but we can't check TARGET_CMODEL until
>after the subtarget override options are done. */
> - if (TARGET_PCREL && TARGET_CMODEL != CMODEL_MEDIUM)
> + else if (TARGET_PCREL && TARGET_CMODEL != CMODEL_MEDIUM)
> {
>if ((rs6000_isa_flags_explicit & OPTION_MASK_PCREL) != 0)
> error ("%qs requires %qs", "-mpcrel", "-mcmodel=medium");
If pcrel is enabled by the first if(), we still need to test for cmodel,
I think? This same code won't work, of course.
Okay for trunk with that first thing fixed, and that second thing can be
dealt with in a later patch.
Thanks!
Segher
[Version 4][PATCH][gcc][PR94230]provide an option to change the size limitation for -Wmisleading-indent
Hi, Dave,
Thanks a lot for the review and comments.
I just updated the patch with all your suggestions, bootstrapped it and run
regression test, no any issue.
The newest patch is attached with this email.
Richard/Jakub, please advise on whether I can commit this patch to Gcc10?
Thanks a lot.
Qing
gcc/c-family/ChangeLog:
2020-04-24 qing zhao
* c-indentation.c (get_visual_column): Add a hint to use the new
-flarge-source-files option.
gcc/ChangeLog:
2020-04-24 qing zhao
* common.opt: Add -flarge-source-files.
* doc/invoke.texi: Document it.
* toplev.c (process_options): Set line_table->default_range_bits
to 0 when flag_large_source_files is true.
gcc/testsuite/ChangeLog:
2020-04-24 qing zhao
* gcc.dg/plugin/location-overflow-test-1.c (fn_1): New message to
verify that hint about -flarge-source-files is emitted.
PR94230.patch
Description: Binary data
> On Apr 23, 2020, at 5:13 PM, David Malcolm wrote:
>
> On Thu, 2020-04-23 at 16:05 -0500, Qing Zhao wrote:
>
>> Hi, Richard,
>>
>> This is the 3rd version of the patch, updated based on your previous
>> comments.
>
> Thanks for working on this, and to Richard for the useful comments.
>
>> Please take a look at it and let me know whether it’s okay to commit?
>
> I like the overall approach.
>
> Some nits inline.
>
>
> Maybe: "Verify that hint about -flarge-source-files is emitted".
>
>
>> + if (!flag_large_source_files)
>> +inform (loc,
>> +"please add %<-flarge-source-files%> to invoke more"
>> +" column-tracking for large source files");
>
> It's great having a hint here, but I don't love the wording of the
> hint.
>
> Maybe reword to:
>
> "adding %<-flarge-source-files%> will allow for more column-tracking
> support, at the expense of compilation time and memory".
>
> or somesuch.
>
>> +This means that diagnostics for later lines do not include column numbers.
>> +It also means that options like @option{-Wmisleading-indent} cease to work
> ^^^
> This should be:-Wmisleading-indentation
>
>> +at that point, although the compiler prints a note if this happens.
>> +Passing @option{-flarge-source-files} significantly increases the number
>> +of source lines that GCC can process before it stops tracking column.
> ^^
> This should be:columns
>
>> + if (flag) x = 3; y = 2; /* { dg-message "-:disabled from this point" "add
>> '-flarge-source-files'" } */
>
> May need updating to match the hint message.
>
> [...]
>
> This is OK for stage 1 with those nits fixed.
>
> There was talk earlier in the thread about fixing this in GCC 10.
>
> Richi/Jakub: is this OK for stage 4? Although it adds a new command-
> line option, it's a workaround for a regression introduced in GCC 6 and
> should be low risk.
>
> Thanks
> Dave
>
Re: [PATCH v2] aarch64: Add TX3 machine model
On Wed, Apr 22, 2020 at 8:25 PM Joel Jones wrote: > > Yes, Bellsoft's contribution is to be covered under the Marvell copyright > > assignment, as this is a work for hire. Thanks ! Ramana > > > > Joel > > > > >Yes, Bellsoft's contribution is to be covered under the Marvell copyright > > >assignment, as this is a work for hire. > > > > > >Joel > > > > > >>>Hi Anton, > > >>> > > -Original Message- > > From: Gcc-patches On Behalf Of Anton > > Youdkevitch > > Sent: 20 April 2020 19:29 > > To: gcc-patches@gcc.gnu.org > > Cc: jo...@marvell.com > > Subject: [PATCH v2] aarch64: Add TX3 machine model > > > > Here is the patch introducing thunderxt311 maching model > > for the scheduler. A name for the new chip was added to the > > list of the names to be recognized as a valid parameter for mcpu > > and mtune flags. The TX2 cost model was reused for TX3. > > > > The previously used "cryptic" name for the command line > > parameter is replaced with the same "thunderxt311" name. > > > > Bootstrapped on AArch64. > > >>> > > >>>Thanks for the patch. I had meant to ask, do you have a copyright > >>>assignment in place? > > >>>We'd need one to accept a contribution of this size. > > >>>Thanks, > > >>>Kyrill > > >>> > > > > 2020-04-20 Anton Youdkevitch > > > > * config/aarch64/aarch64-cores.def: Add the chip name. > > * config/aarch64/aarch64-tune.md: Regenerated. > > * gcc/config/aarch64/aarch64.c: Add the cost tables for the chip. > > * gcc/config/aarch64/thunderx3t11.md: New file: add the new > > machine model for the scheduler > > * gcc/config/aarch64/aarch64.md: Include the new model. > > > > --- > > gcc/config/aarch64/aarch64-cores.def | 3 + > > gcc/config/aarch64/aarch64-tune.md | 2 +- > > gcc/config/aarch64/aarch64.c | 27 + > > gcc/config/aarch64/aarch64.md| 1 + > > gcc/config/aarch64/thunderx3t11.md | 686 +++ > > 5 files changed, 718 insertions(+), 1 deletion(-) > > >>> > > >>> > > >>> > > >>> > > >
Re: [Version 4][PATCH][gcc][PR94230]provide an option to change the size limitation for -Wmisleading-indent
On Fri, 2020-04-24 at 17:22 -0500, Qing Zhao wrote: > Hi, Dave, > > Thanks a lot for the review and comments. > I just updated the patch with all your suggestions, bootstrapped it > and run regression test, no any issue. > > The newest patch is attached with this email. > > Richard/Jakub, please advise on whether I can commit this patch to > Gcc10? > > Thanks a lot. > > Qing > Thanks Qing. One more wording nit (sorry!) > + if (!flag_large_source_files) > + inform (loc, > + "adding %<-flarge-source-files%> will allow for more" > + " column-tracking support, at the expense of compilation" > + " and memory"); ^ Please add "time" here i.e. " time and memory"); Dave
Re: [PATCH] RS6000: Use .machine ppc for some CRT files
On Fri, Apr 24, 2020 at 04:47:31PM -0500, Peter Bergner wrote: > On 4/17/20 12:59 AM, Sebastian Huber wrote: > > Hello Segher, > > > > would you mind having a look at this patch. > > > > His patch is here: > > https://gcc.gnu.org/pipermail/gcc-patches/2020-April/543396.html (And at https://patchwork.ozlabs.org/project/gcc/patch/20200407051825.12516-1-sebastian.hu...@embedded-brains.de/ where you can see headers as well). Ah, I wasn't Cc:ed, and I don't have a regexp for "RS6000" :-) Segher
[committed] d: Merge upstream dmd 09db0c41e, druntime e68a5ae3.
Hi, This patch merges the D front-end implementation with upstream dmd 09db0c41e, and the D runtime library with upstream druntime e68a5ae3. * New core.math.toPrec templates have been added as an intrinsic. Some floating point algorithms, such as Kahan-Babuska-Neumaier Summation, require rounding to specific precisions. Rounding to precision after every operation, however, loses overall precision in the general case and is a runtime performance problem. Adding these functions guarantee the rounding at required points in the code, and document where in the algorithm the requirement exists. * Support IBM long double types in core.internal.convert. * Add missing aliases for 64-bit vectors in core.simd. * RUNNABLE_PHOBOS_TEST directive has been properly integrated into the D2 language testsuite. Bootstrapped and regression tested on x86_64-linux-gnu, committed to mainline. Regards Iain --- gcc/d/ChangeLog: * intrinsics.cc (expand_intrinsic_toprec): New function. (maybe_expand_intrinsic): Handle toPrec intrinsics. * intrinsics.def (TOPRECF, TOPREC, TOPRECL): Add toPrec intrinsics. --- gcc/d/dmd/MERGE | 2 +- gcc/d/intrinsics.cc | 22 +++ gcc/d/intrinsics.def | 3 + .../gdc.test/compilable/interpret3.d | 16 ++ gcc/testsuite/gdc.test/runnable/builtin.d | 2 +- gcc/testsuite/gdc.test/runnable/complex.d | 2 +- gcc/testsuite/gdc.test/runnable/constfold.d | 3 +- gcc/testsuite/gdc.test/runnable/foreach4.d| 3 +- gcc/testsuite/gdc.test/runnable/ifti.d| 2 +- gcc/testsuite/gdc.test/runnable/implicit.d| 3 +- gcc/testsuite/gdc.test/runnable/inner.d | 3 +- gcc/testsuite/gdc.test/runnable/interpret.d | 47 - gcc/testsuite/gdc.test/runnable/issue8671.d | 2 +- gcc/testsuite/gdc.test/runnable/lazy.d| 2 +- gcc/testsuite/gdc.test/runnable/mars1.d | 2 +- gcc/testsuite/gdc.test/runnable/mixin1.d | 3 +- gcc/testsuite/gdc.test/runnable/mixin2.d | 2 +- gcc/testsuite/gdc.test/runnable/s2ir.d| 3 +- gcc/testsuite/gdc.test/runnable/stress.d | 2 +- gcc/testsuite/gdc.test/runnable/template4.d | 2 +- gcc/testsuite/gdc.test/runnable/template9.d | 2 +- gcc/testsuite/gdc.test/runnable/test10942.d | 2 +- gcc/testsuite/gdc.test/runnable/test11.d | 2 +- gcc/testsuite/gdc.test/runnable/test12.d | 2 +- gcc/testsuite/gdc.test/runnable/test12197.d | 2 +- gcc/testsuite/gdc.test/runnable/test15.d | 2 +- gcc/testsuite/gdc.test/runnable/test22.d | 2 +- gcc/testsuite/gdc.test/runnable/test23.d | 2 +- gcc/testsuite/gdc.test/runnable/test24.d | 2 +- gcc/testsuite/gdc.test/runnable/test27.d | 2 +- gcc/testsuite/gdc.test/runnable/test28.d | 2 +- gcc/testsuite/gdc.test/runnable/test34.d | 3 +- gcc/testsuite/gdc.test/runnable/test37.d | 2 +- gcc/testsuite/gdc.test/runnable/test42.d | 3 +- gcc/testsuite/gdc.test/runnable/test5305.d| 2 +- gcc/testsuite/gdc.test/runnable/test60.d | 2 +- gcc/testsuite/gdc.test/runnable/testaa.d | 2 +- .../gdc.test/runnable/testbitarray.d | 2 +- gcc/testsuite/gdc.test/runnable/testdstress.d | 2 +- gcc/testsuite/gdc.test/runnable/testfile.d| 2 +- gcc/testsuite/gdc.test/runnable/testformat.d | 2 +- gcc/testsuite/gdc.test/runnable/testline.d| 2 +- gcc/testsuite/gdc.test/runnable/testmmfile.d | 2 +- gcc/testsuite/gdc.test/runnable/testscope2.d | 2 +- gcc/testsuite/gdc.test/runnable/testsignals.d | 2 +- gcc/testsuite/gdc.test/runnable/testsocket.d | 2 +- gcc/testsuite/gdc.test/runnable/teststdio.d | 2 +- gcc/testsuite/gdc.test/runnable/testthread2.d | 2 +- gcc/testsuite/gdc.test/runnable/testtypeid.d | 3 +- gcc/testsuite/gdc.test/runnable/traits.d | 2 +- gcc/testsuite/gdc.test/runnable/wc.d | 2 +- gcc/testsuite/gdc.test/runnable/wc2.d | 2 +- gcc/testsuite/gdc.test/runnable/wc3.d | 2 +- gcc/testsuite/gdc.test/runnable/xtest46.d | 2 +- gcc/testsuite/gdc.test/runnable/xtest55.d | 2 +- libphobos/libdruntime/MERGE | 2 +- libphobos/libdruntime/core/cpuid.d| 2 +- libphobos/libdruntime/core/internal/convert.d | 170 -- libphobos/libdruntime/core/math.d | 71 libphobos/libdruntime/core/simd.d | 6 +- 60 files changed, 329 insertions(+), 121 deletions(-) diff --git a/gcc/d/dmd/MERGE b/gcc/d/dmd/MERGE index 155286dd765..a878cb9f42e 100644 --- a/gcc/d/dmd/MERGE +++ b/gcc/d/dmd/MERGE @@ -1,4 +1,4 @@ -62ce36f3737de691217c21f0173f411734eb1d43 +09db0c41ee922502fa0966bde24c1cb9b15ad436 The first line of this file holds the git revision number of the last merge done from the dlang/dmd repository. diff --git a/gcc/d/intrinsics.cc b/gcc/d/intrinsics.cc index 9a9fd4
Re: [PATCH] RS6000: Use .machine ppc for some CRT files
Hi! On Tue, Apr 07, 2020 at 07:18:25AM +0200, Sebastian Huber wrote: > Since commit e154242724b084380e3221df7c08fcdbd8460674 the flag -many is > sometimes not passed to the assembler. Use .machine ppc to prevent > errors if these files are assembled for an ISA which does not support > FPRs. > > libgcc/ > > * config/rs6000/crtresfpr.S: Use .machine ppc. > * config/rs6000/crtresxfpr.S: Likewise. > * config/rs6000/crtsavfpr.S: Likewise. This is fine. Okay for trunk. Thank you! Also okay for backports if you want -- after letting it simmer on trunk for a week or so. Segher
[pushed] c++: implicit operator== with previous decl [PR94583]
P2085 clarified that a defaulted comparison operator must be the first
declaration of the function. Rejecting that avoids the ICE trying to
compare the noexcept-specifications.
Tested x86_64-pc-linux-gnu, applying to trunk.
gcc/cp/ChangeLog
2020-04-24 Jason Merrill
PR c++/94583
* decl.c (redeclaration_error_message): Reject defaulted comparison
operator that has been previously declared.
---
gcc/cp/decl.c | 8
gcc/testsuite/g++.dg/cpp2a/spaceship-synth6.C | 11 +++
2 files changed, 19 insertions(+)
create mode 100644 gcc/testsuite/g++.dg/cpp2a/spaceship-synth6.C
diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
index c8c2f080763..31b5884ca3a 100644
--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -2972,6 +2972,14 @@ redeclaration_error_message (tree newdecl, tree olddecl)
}
}
+ /* [class.compare.default]: A definition of a comparison operator as
+defaulted that appears in a class shall be the first declaration of
+that function. */
+ special_function_kind sfk = special_function_p (olddecl);
+ if (sfk == sfk_comparison && DECL_DEFAULTED_FN (newdecl))
+ return G_("comparison operator %q+D defaulted after "
+ "its first declaration");
+
check_abi_tag_redeclaration
(olddecl, lookup_attribute ("abi_tag", DECL_ATTRIBUTES (olddecl)),
lookup_attribute ("abi_tag", DECL_ATTRIBUTES (newdecl)));
diff --git a/gcc/testsuite/g++.dg/cpp2a/spaceship-synth6.C
b/gcc/testsuite/g++.dg/cpp2a/spaceship-synth6.C
new file mode 100644
index 000..e8296bbb60a
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp2a/spaceship-synth6.C
@@ -0,0 +1,11 @@
+// PR c++/94583
+// { dg-do compile { target c++2a } }
+
+namespace std { struct strong_ordering { }; }
+
+bool operator==(const struct Q&, const struct Q&);
+struct Q {
+ // { dg-error "defaulted after its first declaration" "" { target *-*-* }
.+1 }
+ friend std::strong_ordering operator<=>(const Q&, const Q&) = default;
+};
+bool b = Q() == Q();
base-commit: cbd2a10dd9edadb262934aed64c0959339da68d1
--
2.18.1
Connect
Hi, I'd like to offer you farm automation solutions to save your precious time and get better results. I'm the founder of a small IT company which is providing IoT Services. Currently I'm looking for an earlier adopter customers. We need to build strong references that's why level of attention to your business as well the price is going exceptionally attractive. I'd like to hear from you please if you are interested in IoT product. Example - smart valves watering based on desired outcome. i.e. keep soil moisture level at 60-80%. the beast conditions for plant https://www.sasiot.com.au/water-case - convert any analogic data to digital chart with our Camera module. I.e. existing water meter or electric board, pressure sensor, weight and so on. No need to re-install existing facility. Very cost effective way to get digitilization. Put our camera sensor in front of required object and that's all! - various sensors which are collecting data. like air quality, moisture, light level, contactless distance meter, ultrasonic liquid volume\level https://www.sasiot.com.au/smart-solutions - combined analytical system with dashboards and geo maps. - heat\UV map, centralized data store and much more see demo here https://sasiot.com.au/ Truly wireless. all sensors are coming with the small solar panels. so all sensors are self-sufficient. From the business side you are getting optimized water consumption and enhanced tracking system for each plant. There are could be other needs you have which I can analyzed and help your business Thank you Konstantin https://sasiot.com.au/
