Re: [PATCH] issues with configure --enable-checking option

Ping with CCing Jeff and Joseph. I think patch is rather obvious, but hopefully other items will also get some attention. 29.01.2020 16:32, Roman Zhuykov wrote: > Hi! > I've investigated a bit, because some of the following confused me > while working with some local 9.2-based branch. > >

[PATCH 14/14] Incorporate new code into the build machinery.

2020-02-03 Bill Schmidt * config.gcc (powerpc-*-*-*): Add rs6000-bif.o to extra_objs. * config/rs6000/t-rs6000 (rs6000-genbif.o): New target. (rbtree.o): Likewise. (rs6000-genbif): Likewise. (rs6000-bif.c): Likewise. (rs6000-bif.o): Likewise. ---

[PATCH 11/14] Write #defines to rs6000-vecdefines.h.

2020-02-03 Bill Schmidt * config/rs6000/rs6000-genbif.c (write_defines_file): Implement. --- gcc/config/rs6000/rs6000-genbif.c | 4 1 file changed, 4 insertions(+) diff --git a/gcc/config/rs6000/rs6000-genbif.c b/gcc/config/rs6000/rs6000-genbif.c index 7bb7d2b24a4..0bcd035060d

[PATCH 10/14] Build function type identifiers and store them.

2020-02-03 Bill Schmidt * config/rs6000/rs6000-genbif.c (complete_vector_type): New function. (complete_base_type): New function. (construct_fntype_id): New function. (parse_bif_entry): Call construct_fntype_id. (parse_ovld_entry): Likewise. ---

[PATCH 13/14] Write code to rs6000-bif.c.

2020-02-03 Bill Schmidt * config/rs6000/rs6000-genbif.c (typemap): New struct. (TYPE_MAP_SIZE): New defined constant. (type_map): New filescope variable. (write_fntype): New callback function. (map_token_to_type_node): New function.

[PATCH 12/14] Write code to rs6000-bif.h.

2020-02-03 Bill Schmidt * config/rs6000/rs6000-genbif.c (write_autogenerated_header): New function. (write_bif_enum): New callback function. (write_ovld_enum): New callback function. (write_decls): New function. (write_extern_fntype): New

[PATCH 09/14] Add parsing support for rs6000-overload.def.

2020-02-03 Bill Schmidt * config/rs6000/rs6000-genbif.c (ovld_stanza): New struct. (MAXOVLDSTANZAS): New defined constant. (ovld_stanzas): New filescope variable. (curr_ovld_stanza): Likewise. (MAXOVLDS): New defined constant. (ovlddata): New

[PATCH 06/14] Red-black tree implementation for balanced tree search.

2020-02-03 Bill Schmidt * config/rs6000/rbtree.c: New file. * config/rs6000/rbtree.h: New file. --- gcc/config/rs6000/rbtree.c | 233 + gcc/config/rs6000/rbtree.h | 51 2 files changed, 284 insertions(+) create mode 100644

[PATCH 08/14] Add support for parsing rs6000-bif.def.

2020-02-03 Bill Schmidt * config/rs6000/rs6000-genbif.c (MAXBIFSTANZAS): New defined constant. (bif_stanzas): New filescope variable. (curr_bif_stanza): Likewise. (fnkinds): New enum. (typelist): New struct. (attrinfo): New struct.

[PATCH 05/14] Add support functions for matching types.

2020-02-03 Bill Schmidt * config/rs6000/rs6000-genbif.c (void_status): New enum. (basetype): Likewise. (restriction): Likewise. (typeinfo): New struct. (match_basetype): New function. (match_const_restriction): New function. (match_type):

[PATCH 07/14] Add main function with stub functions for parsing and output.

2020-02-03 Bill Schmidt * config/rs6000/rs6000-genbif.c (rbtree.h): New include. (num_bif_stanzas): New filescope variable. (num_bifs): Likewise. (num_ovld_stanzas): Likewise. (num_ovlds): Likewise. (exit_codes): Add more enum values.

[PATCH 04/14] Support functions to parse whitespace, lines, identifiers, integers.

2020-02-03 Bill Schmidt * config/rs6000/rs6000-genbif.c (MININT): New defined constant. (exit_codes): New enum. (consume_whitespace): New function. (advance_line): New function. (safe_inc_pos): New function. (match_identifier): New function.

[PATCH 02/14] Add stubs for input files. These will grow much larger.

This patch adds a subset of the builtin and overload descriptions. I've also started annotating the old-style descriptions in rs6000-c.c where I'm deliberately not planning to support new versions of them. We may have to have some discussion around these at some point, but this helps me track this

[PATCH 01/14] Initial create of rs6000-genbif.c.

Includes header documentation and initial set of include directives. 2020-02-03 Bill Schmidt * config/rs6000/rs6000-genbif.c: New file. --- gcc/config/rs6000/rs6000-genbif.c | 124 ++ 1 file changed, 124 insertions(+) create mode 100644

[PATCH 00/14] rs6000: Begin replacing built-in support

The current built-in support in the rs6000 back end requires at least a master's degree in spelunking to comprehend. It's full of cruft, redundancy, and unused bits of code, and long overdue for a replacement. This is the first part of my project to do that. My intent is to make adding new

[PATCH 03/14] Add file support and functions for diagnostic support.

2020-02-03 Bill Schmidt * config/rs6000/rs6000-genbif.c (bif_file): New filescope variable. (ovld_file): Likewise. (header_file): Likewise. (init_file): Likewise. (defines_file): Likewise. (pgm_path): Likewise. (bif_path):

Re: libgo patch committed: Update to Go1.14beta1

On Sun, Feb 2, 2020 at 2:27 AM Andreas Schwab wrote: > > I'm getting these errors on aarch64 with -mabi=ilp32: > > ../../../../libgo/go/runtime/mpagealloc.go:226:38: error: shift count overflow > 226 | chunks [1 << pallocChunksL1Bits]*[1 << pallocChunksL2Bits]pallocData > |

Re: libgo patch committed: Update to Go1.14beta1

On Sat, Feb 1, 2020 at 5:38 AM Andreas Schwab wrote: > > ../../../libgo/go/syscall/syscall_linux_riscv64.go:7:14: error: imported and > not used: unsafe > 7 | import "unsafe" > | ^ > ../../../libgo/go/syscall/syscall_linux_riscv64.go:13:1: error: redefinition > of

libbacktrace patch committed: Always build tests with -g

This patch ensures that the libbacktrace tests are always built with -g. It also builds them with the default warning flags, so I had to add a few casts to ztest.c to get it pass without warnings. This should fix PR 90636. Bootstrapped and ran libbacktrace tests on x86_64-pc-linux-gnu.

Re: [PATCH] i386: Define TARGET_ASM_PRINT_PATCHABLE_FUNCTION_ENTRY

On Mon, Feb 3, 2020 at 4:02 PM H.J. Lu wrote: > > On Mon, Feb 3, 2020 at 10:35 AM H.J. Lu wrote: > > > > Define TARGET_ASM_PRINT_PATCHABLE_FUNCTION_ENTRY to make sure that the > > ENDBR are emitted before the patch area. When -mfentry -pg is also used > > together, there should be no ENDBR

[PATCH 3/3] libstdc++: Implement C++20 range adaptors

This patch implements [range.adaptors]. It also includes the changes from P3280 and P3278 and P3323, without which many standard examples won't work. The implementation is mostly dictated by the spec and there was not much room for implementation discretion. The most interesting part that was

[PATCH 1/3] libstdc++: Apply the move_iterator changes described in P1207R4

These changes are needed for some of the tests in the constrained algorithm patch, because they use move_iterator with an uncopyable output_iterator. The other changes described in the paper are already applied, it seems. libstdc++-v3/ChangeLog: * include/bits/stl_iterator.h

Re: [PATCH Coroutines v2] Handle type deduction of auto and decltype(auto) with indirect_ref expression

在 2020/2/3 下午8:53, Nathan Sidwell 写道: On 2/2/20 9:28 PM, JunMa wrote: 在 2020/2/3 上午9:03, JunMa 写道: I think all you want here is:   await_expr = convert_from_reference (await_expr); Thanks, I'll update it. Regards JunMa Hi nathan, Here is the update.    /* This will produce the

[PATCH] avoid issuing -Wrestrict from folder (PR 93519)

PR 93519 reports a false positive -Wrestrict issued for an inlined call to strcpy that carefully guards against self-copying. This is caused by the caller's arguments substituted into the call during inlining and before dead code elimination. The attached patch avoids this by removing

Re: [PATCH] V12 patch #3 of 14, Improve address validation in rs6000_adjust_vec_address

On Mon, Feb 03, 2020 at 06:19:07PM -0500, Michael Meissner wrote: > On Fri, Jan 31, 2020 at 05:43:20PM -0600, Segher Boessenkool wrote: > > On Thu, Jan 09, 2020 at 07:27:58PM -0500, Michael Meissner wrote: > > > * config/rs6000/rs6000.c (reg_to_non_prefixed): Add forward > > > reference. > >

Re: [PATCH] V12 patch #2 of 14, Refactor rs6000_adjust_vec_address & rs6000_split_vec_extract_var

On Mon, Feb 03, 2020 at 05:02:25PM -0500, Michael Meissner wrote: > On Fri, Jan 31, 2020 at 11:30:22AM -0600, Segher Boessenkool wrote: > > But why is that the correct thing to do? Garbage in, garbage out is > > perfectly fine? Or do we have (e.g.) builtins that specify this masking? > > If so,

Re: [PATCH] i386: Define TARGET_ASM_PRINT_PATCHABLE_FUNCTION_ENTRY

On Mon, Feb 3, 2020 at 10:35 AM H.J. Lu wrote: > > Define TARGET_ASM_PRINT_PATCHABLE_FUNCTION_ENTRY to make sure that the > ENDBR are emitted before the patch area. When -mfentry -pg is also used > together, there should be no ENDBR before "call __fentry__". > > OK for master if there is no

Re: [PATCH] V12 patch #5 of 14, Make -mpcrel default for -mcpu=future on little endian Linux 64-bit systems

On Mon, Feb 03, 2020 at 04:52:42PM -0500, Michael Meissner wrote: > > I understand why this is needed for pcrel (or useful at least), but why > > for prefixed addressing in general as well? What OS support is needed > > for that? > > > > Put another way, is this just carefulness, or do you run

[PATCH] contrib/vimrc: detect more C-like files

Currently this script doesn't set the indentation style for the standard library headers under libstdc++/ because they lack a file extension. But they do have a modeline, so the file type is still set appropriately by Vim. So by inspecting , we can also detect these standard library headers as

Re: [PATCH] V12 patch #3 of 14, Improve address validation in rs6000_adjust_vec_address

On Fri, Jan 31, 2020 at 05:43:20PM -0600, Segher Boessenkool wrote: > Hi! > > On Thu, Jan 09, 2020 at 07:27:58PM -0500, Michael Meissner wrote: > > * config/rs6000/rs6000.c (reg_to_non_prefixed): Add forward > > reference. > > FWIW, it is better to just reorder the code, in most cases. >

[COMMITTED 1/2] c++: Allow parm of empty class type in constexpr.

Since copying a class object is defined in terms of the copy constructor, copying an empty class is OK even if it would otherwise not be usable in a constant expression. Relatedly, using a parameter as an lvalue is no more problematic than a local variable, and calling a member function uses the

[COMMITTED 2/2] c++: Fix constexpr vs. reference parameter.

[expr.const] specifically rules out mentioning a reference even if its address is never used, because it implies indirection that is similarly non-constant for a pointer variable. Tested x86_64-pc-linux-gnu, applying to trunk. PR c++/66477 * constexpr.c

Re: [PATCH] Add --with-diagnostics-urls configuration option and GCC_URLS/TERM_URLS env var

On 2/3/20 10:05 PM, Segher Boessenkool wrote: > On Mon, Feb 03, 2020 at 08:16:52PM +, Bernd Edlinger wrote: >> So gnome terminal is a problem, since it depend heavily on the software >> version, VTE library, and gnome-terminal. >> Sometimes URLs are functional, sometimes competely buggy. >> >>

Re: [PATCH] V12 patch #2 of 14, Refactor rs6000_adjust_vec_address & rs6000_split_vec_extract_var

On Fri, Jan 31, 2020 at 11:30:22AM -0600, Segher Boessenkool wrote: > But why is that the correct thing to do? Garbage in, garbage out is > perfectly fine? Or do we have (e.g.) builtins that specify this masking? > If so, please say that here. It has been this way since I added these for power7

Re: [PATCH] V12 patch #5 of 14, Make -mpcrel default for -mcpu=future on little endian Linux 64-bit systems

On Fri, Jan 31, 2020 at 07:12:53PM -0600, Segher Boessenkool wrote: > Hi! > > On Thu, Jan 09, 2020 at 07:40:08PM -0500, Michael Meissner wrote: > > * config/rs6000/linux64.h (PREFIXED_ADDR_SUPPORTED_BY_OS): Set to > > 1 to enable prefixed addressing if -mcpu=future. > >

Re: [PATCH] Add --with-diagnostics-urls configuration option and GCC_URLS/TERM_URLS env var

On Mon, Feb 03, 2020 at 08:16:52PM +, Bernd Edlinger wrote: > So gnome terminal is a problem, since it depend heavily on the software > version, VTE library, and gnome-terminal. > Sometimes URLs are functional, sometimes competely buggy. > > But, wait a moment, here is the deal: > > I can

Re: [PATCH] Add --with-diagnostics-urls configuration option and GCC_URLS/TERM_URLS env var

On 2/3/20 9:26 PM, Jakub Jelinek wrote: > On Mon, Feb 03, 2020 at 08:16:52PM +, Bernd Edlinger wrote: >> Jakub, can you confirm that the COLORTERM on your working >> gnome-terminal is set to "truecolor" ? > > On the box where I have display attached to yes, but it isn't propagated > through

Re: [PATCH] Add --with-diagnostics-urls configuration option and GCC_URLS/TERM_URLS env var

On Mon, Feb 03, 2020 at 08:16:52PM +, Bernd Edlinger wrote: > Jakub, can you confirm that the COLORTERM on your working > gnome-terminal is set to "truecolor" ? On the box where I have display attached to yes, but it isn't propagated through ssh to the workstation that I do GCC development

Re: [PATCH] Add --with-diagnostics-urls configuration option and GCC_URLS/TERM_URLS env var

On 2/3/20 3:08 PM, Segher Boessenkool wrote: > On Sun, Feb 02, 2020 at 08:00:44AM +, Bernd Edlinger wrote: Okay, thanks. That is a strong indication that there is no need to interfere with screen, which proves that any auto-disabling should have a very specific terminal

Re: [PATCH, v3] wwwdocs: e-mail subject lines for contributions

On Mon, Feb 03, 2020 at 06:20:20PM +, Michael Matz wrote: > On Mon, 3 Feb 2020, Richard Earnshaw (lists) wrote: > > Well, I'd review a patch differently depending on whether or not it was > > already committed, a patch requiring review or an RFC looking for more > > general comments, so I

[committed] analyzer: detect zero-assignment in phis (PR 93544)

PR analyzer/93544 reports an ICE when attempting to report a double-free within diagnostic_manager::prune_for_sm_diagnostic, in which the variable of interest has become an INTEGER_CST. Additionally, it picks a nonsensical path through the function in which the pointer being double-freed is known

[committed] analyzer: show BBs in .dot dumps

I found this useful whilst debugging PR analyzer/93544 Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu. Pushed to master as 73f386581bddc4d630b93eeb0cddd32943bf24e7. gcc/analyzer/ChangeLog: * engine.cc (supernode_cluster::dump_dot): Show BB index as well as SN

[committed] analyzer: fix ICE merging models containing label pointers (PR 93546)

PR analyzer/93546 reports an ICE within region_model::add_region_for_type when merging two region_models each containing a label pointer. The two labels are stored as pointers to symbolic_regions, but these regions were created with NULL type, leading to an assertion failure when a merged copy is

[committed] analyzer: fix ICE due to comparing int and real constants (PR 93547)

Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu. Pushed to master as r10-6409-g287ccd3bd6b92f11ec90c52ffccb764aacfadb89. gcc/analyzer/ChangeLog: PR analyzer/93547 * constraint-manager.cc (constraint_manager::get_or_add_equiv_class): Ensure types are

Re: [PATCH, v3] wwwdocs: e-mail subject lines for contributions

On Mon, Feb 03, 2020 at 06:54:05PM +0100, Jakub Jelinek wrote: > On Mon, Feb 03, 2020 at 05:48:57PM +, Michael Matz wrote: > > On Mon, 3 Feb 2020, Richard Earnshaw (lists) wrote: > > > > > The idea is that the [...] part is NOT part of the commit, only part of > > > the email. > > > > I

Re: [PATCH] adjust object size computation for union accesses and PHIs (PR 92765)

On Fri, 2020-01-31 at 12:04 -0700, Martin Sebor wrote: > Attached is a reworked patch since the first one didn't go far > enough to solve the major problems. The new solution relies on > get_range_strlen_dynamic the same way as the sprintf optimization, > and does away with the

[PATCH] i386: Define TARGET_ASM_PRINT_PATCHABLE_FUNCTION_ENTRY

Define TARGET_ASM_PRINT_PATCHABLE_FUNCTION_ENTRY to make sure that the ENDBR are emitted before the patch area. When -mfentry -pg is also used together, there should be no ENDBR before "call __fentry__". OK for master if there is no regression? Thanks. H.J. -- gcc/ PR target/93492 *

Re: [PATCH, v3] wwwdocs: e-mail subject lines for contributions

Hello, On Mon, 3 Feb 2020, Richard Earnshaw (lists) wrote: > Well, I'd review a patch differently depending on whether or not it was > already committed, a patch requiring review or an RFC looking for more > general comments, so I *do* think such an email prefix is useful. As I said: a very

[PATCH] rs6000: Update constraint documentation

This un-documents constraints that cannot (or should not) be used in inline assembler. It also improves markup, and presentation in general. More work is needed, but gradual improvement is easier to do. Committing to trunk. Segher 2020-02-03 Segher Boessenkool *

Re: [PATCH, v3] wwwdocs: e-mail subject lines for contributions

Hello, On Mon, 3 Feb 2020, Jakub Jelinek wrote: > > > The idea is that the [...] part is NOT part of the commit, only part of > > > the email. > > > > I understand that, but the subject line of this thread says "e-mail > > subject lines", so I thought we were talking about, well, exactly

Re: [PATCH, v3] wwwdocs: e-mail subject lines for contributions

On Mon, 3 Feb 2020, Michael Matz wrote: > I understand that, but the subject line of this thread says "e-mail > subject lines", so I thought we were talking about, well, exactly that; > and I see no value of these tags in e-mails either. I agree that [PATCH] is not useful (and in general,

Re: [PATCH, v3] wwwdocs: e-mail subject lines for contributions

On 03/02/2020 17:48, Michael Matz wrote: Hi, On Mon, 3 Feb 2020, Richard Earnshaw (lists) wrote: The idea is that the [...] part is NOT part of the commit, only part of the email. I understand that, but the subject line of this thread says "e-mail subject lines", so I thought we were

Re: [PATCH, v3] wwwdocs: e-mail subject lines for contributions

On Mon, Feb 03, 2020 at 05:48:57PM +, Michael Matz wrote: > On Mon, 3 Feb 2020, Richard Earnshaw (lists) wrote: > > > The idea is that the [...] part is NOT part of the commit, only part of > > the email. > > I understand that, but the subject line of this thread says "e-mail > subject

Re: [PATCH, v3] wwwdocs: e-mail subject lines for contributions

Hi, On Mon, 3 Feb 2020, Richard Earnshaw (lists) wrote: > The idea is that the [...] part is NOT part of the commit, only part of > the email. I understand that, but the subject line of this thread says "e-mail subject lines", so I thought we were talking about, well, exactly that; and I see

Re: [PATCH][AArch64] Improve popcount expansion

On Mon, Feb 3, 2020 at 7:02 AM Wilco Dijkstra wrote: > > The popcount expansion uses umov to extend the result and move it back > to the integer register file. If we model ADDV as a zero-extending > operation, fmov can be used to move back to the integer side. This > results in a ~0.5% speedup

[committed] arm: Use move-if-change for updating regenerated files [PR93548]

The t-arm make fragment currently uses 'mv' to update some files that are automatically regenerated, but this causes problems on read-only filesystems if the date stamps are incorrect and the files have not really changed. So use move-if-change instead. PR target/93548 *

Re: [PATCH, v3] wwwdocs: e-mail subject lines for contributions

On 03/02/2020 17:31, Michael Matz wrote: Hello, On Mon, 3 Feb 2020, Richard Earnshaw (lists) wrote: Where does your '50 chars' limit come from? It's not in the glibc text, and it's not in the linux kernel text either. AFAICT this is your invention and you seem to be the only person

Re: [PATCH, v3] wwwdocs: e-mail subject lines for contributions

On Mon, Feb 03, 2020 at 01:59:58PM +, Richard Earnshaw (lists) wrote: > I think the linux rule (the whole line, not including the parts that are > removed on commit, should not exceed 75 characters) is far more sensible > - which is why this draft states this. FWIW, on a slightly older

[committed, amdgcn] Remove gfx801 "carrizo" support

This patch removes the -march=carrizo option and all the gfx801 related bits. The Carrizo options were inherited from the original GCN port, but they've not been tested since (we don't have the hardware), and there's no XNACK handling, so it probably wouldn't work reliably. Additionally,

Re: [PATCH, v3] wwwdocs: e-mail subject lines for contributions

Hello, On Mon, 3 Feb 2020, Richard Earnshaw (lists) wrote: > Where does your '50 chars' limit come from? It's not in the glibc text, > and it's not in the linux kernel text either. AFAICT this is your > invention and you seem to be the only person proposing it. Nope, it's fairly common, so

[GCC][PATCH][ARM] Regenerate arm-tables.opt for Armv8.1-M patch

Hi all, I've regenerated arm-tables.opt in config/arm to replace the improperly generated arm-tables.opt file from "[PATCH, GCC/ARM, 2/10] Add command line support for Armv8.1-M Mainline" (9722215a027b68651c3c7a8af9204d033197e9c0). 2020-02-03 Mihail Ionescu * config/arm/arm-tables.opt:

[GCC][PATCH][ARM] Set profile to M for Armv8.1-M

Hi, We noticed that the profile for armv8.1-m.main was not set in arm-cpus.in , which led to TARGET_ARM_ARCH_PROFILE and _ARM_ARCH_PROFILE not being defined properly. gcc/ChangeLog: 2020-02-03 Mihail Ionescu * config/arm/arm-cpus.in: Set profile M for armv8.1-m.main. Ok

Re: [PATCH, v3] wwwdocs: e-mail subject lines for contributions

On Mon, Feb 03, 2020 at 01:59:58PM +, Richard Earnshaw (lists) wrote: > On 03/02/2020 13:54, Segher Boessenkool wrote: > >None of this are *rules*. We should not pretend they are. An email > >subject should be useful to what the receivers of that email use it for: > >see if it very

Re: [PATCH, v3] wwwdocs: e-mail subject lines for contributions

On Mon, Feb 03, 2020 at 01:59:58PM +, Richard Earnshaw (lists) wrote: > On 03/02/2020 13:54, Segher Boessenkool wrote: > >None of this are *rules*. We should not pretend they are. An email > >subject should be useful to what the receivers of that email use it for: > >see if it very

Re: [PATCH 1/4] [ARC] Update mlo/mhi handling when big-endian CPU.

On Mon, 2020-02-03 at 12:38 +0100, Claudiu Zissulescu wrote: > The ARC 600 MUL64 instructions are using mlo/mhi registers to pass the > 64-bit result. However, the mlo/mhi registers are not swapping > depending on endianess. Update multiplication patterns to reflect > this fact. > > gcc/ >

Re: [Patch] Inline optimization for tanh(x)/sinh(x) -> 1.0/cosh(x)

On Fri, 2020-01-31 at 15:50 -0300, Vitor Guidi wrote: > I took the required steps. The patch is attached to this email, I hope > I got it right this time. I did not forward the patch to gcc-patches > the first time, sorry for the inconvenience. > > Thank you for your attention, > > Vitor. > >

Re: [PATCH 4/4] arc: Don't use if-conversion when optimizing for size.

On Mon, 2020-02-03 at 12:38 +0100, Claudiu Zissulescu wrote: > For ARC, predicated instructions are not very friendly with size > optimizations, leading to increased object size. Disable if-conversion > step when optimized for size. > > gcc/ > -xx-xx Claudiu Zissulescu > > *

Re: [PATCH 2/4] [ARC] Use TARGET_INSN_COST.

On Mon, 2020-02-03 at 12:38 +0100, Claudiu Zissulescu wrote: > TARGET_INSN_COST gives us a better control over the instruction costs > than classical RTX_COSTS. A simple cost scheme is in place for the > time being, when optimizing for size, the cost is given by the > instruction length. When

Re: [PATCH 3/4] [ARC] Deprecate q-class option.

On Mon, 2020-02-03 at 12:38 +0100, Claudiu Zissulescu wrote: > This option was used to control the short instruction selection. However, > there is no difference in cycles if we use or not a short instruction, > and always someone wants a smaller program. > > gcc/ > -xx-xx Claudiu

Re: [PATCH] correct COUNT and PROB for unrolled loop

> On Mon, 2020-02-03 at 10:04 -0600, Pat Haugen wrote: > > On 2/3/20 2:17 AM, Jiufu Guo wrote: > > > +/* { dg-final { scan-rtl-dump-times "REG_BR_PROB 937042044" 1 > > > "loop2_unroll"} } */ > > > > Sorry I didn't catch this addition to the original testcase earlier, but I > > wonder how stable

Re: [PATCH] correct COUNT and PROB for unrolled loop

On Mon, 2020-02-03 at 10:04 -0600, Pat Haugen wrote: > On 2/3/20 2:17 AM, Jiufu Guo wrote: > > +/* { dg-final { scan-rtl-dump-times "REG_BR_PROB 937042044" 1 > > "loop2_unroll"} } */ > > Sorry I didn't catch this addition to the original testcase earlier, but I > wonder how stable this test is

Re: [PATCH, v3] wwwdocs: e-mail subject lines for contributions

On Mon, 3 Feb 2020 15:04:57 + "Richard Earnshaw (lists)" wrote: > On 03/02/2020 14:13, Jonathan Wakely wrote: > > On Mon, 3 Feb 2020 at 14:00, Richard Earnshaw (lists) wrote: > >> Where does your '50 chars' limit come from? It's not in the glibc text, > >> and it's not in the linux kernel

Re: [PATCH] correct COUNT and PROB for unrolled loop

On 2/3/20 2:17 AM, Jiufu Guo wrote: > +/* { dg-final { scan-rtl-dump-times "REG_BR_PROB 937042044" 1 > "loop2_unroll"} } */ Sorry I didn't catch this addition to the original testcase earlier, but I wonder how stable this test is going to be. If there are future changes to default

Re: [wwwdocs] Updates to contribute.html for git-friendly posting rules

(Old thread, first time I see it though): On Mon, Jan 20, 2020 at 11:45:28AM +, Richard Earnshaw (lists) wrote: > The more we make the process lightweight for contributors, the more work > we make for maintainers. If the contribution is sent correctly, then > ideally, the patch can be

Re: [PATCH, v3] wwwdocs: e-mail subject lines for contributions

On 03/02/2020 15:13, Richard Earnshaw (lists) wrote: On 03/02/2020 14:10, Jason Merrill wrote: On Mon, Feb 3, 2020 at 7:57 AM Alexander Monakov wrote: On Mon, 3 Feb 2020, Richard Earnshaw (lists) wrote: Upper case is what glibc has, though it appears that it's a rule that is not

Re: [PATCH, v3] wwwdocs: e-mail subject lines for contributions

On 03/02/2020 14:10, Jason Merrill wrote: On Mon, Feb 3, 2020 at 7:57 AM Alexander Monakov wrote: On Mon, 3 Feb 2020, Richard Earnshaw (lists) wrote: Upper case is what glibc has, though it appears that it's a rule that is not strictly followed. If we change it, then it becomes another

Re: [PATCH, v3] wwwdocs: e-mail subject lines for contributions

On 03/02/2020 14:13, Jonathan Wakely wrote: On Mon, 3 Feb 2020 at 14:00, Richard Earnshaw (lists) wrote: Where does your '50 chars' limit come from? It's not in the glibc text, and it's not in the linux kernel text either. AFAICT this is your invention and you seem to be the only person

[PATCH][AArch64] Improve popcount expansion

The popcount expansion uses umov to extend the result and move it back to the integer register file. If we model ADDV as a zero-extending operation, fmov can be used to move back to the integer side. This results in a ~0.5% speedup on deepsjeng on Cortex-A57. A typical __builtin_popcount

Re: Make OpenACC 'acc_get_property' with 'acc_device_current' work

Hi Thomas, On 1/30/20 4:54 PM, Thomas Schwinge wrote: That's still pending. Recently, "Missing definition for acc_device_current" got filed; let's (also/first) watch/wait what comes out of that. (Still pending.) Please review the

[COMMITTED] c++: Fix cast to pointer to VLA.

The C front-end fixed this issue in r257620 by adding a DECL_EXPR from grokdeclarator. We don't have an easy way to do that in the C++ front-end, but it works fine to create and prepend a DECL_EXPR when we are genericizing the NOP_EXPR for the cast. The C patch wraps the DECL_EXPR in a

Re: [PATCH, v3] wwwdocs: e-mail subject lines for contributions

On Mon, 3 Feb 2020 at 14:00, Richard Earnshaw (lists) wrote: > Where does your '50 chars' limit come from? It's not in the glibc text, > and it's not in the linux kernel text either. AFAICT this is your > invention and you seem to be the only person proposing it. It's a fairly well established

Re: [PATCH, v3] wwwdocs: e-mail subject lines for contributions

On Mon, Feb 3, 2020 at 7:57 AM Alexander Monakov wrote: > On Mon, 3 Feb 2020, Richard Earnshaw (lists) wrote: > > > Upper case is what glibc has, though it appears that it's a rule that is > not > > strictly followed. If we change it, then it becomes another friction > point > > between

Re: [PATCH] Add --with-diagnostics-urls configuration option and GCC_URLS/TERM_URLS env var

On Sun, Feb 02, 2020 at 08:00:44AM +, Bernd Edlinger wrote: > >> Okay, thanks. That is a strong indication that there is no need > >> to interfere with screen, which proves that any auto-disabling should > >> have a very specific terminal detection logic. > > > > Jakub says that he tested

Re: [PATCH, v3] wwwdocs: e-mail subject lines for contributions

On 03/02/2020 13:54, Segher Boessenkool wrote: On Mon, Feb 03, 2020 at 02:54:05PM +0300, Alexander Monakov wrote: On Mon, 3 Feb 2020, Richard Earnshaw (lists) wrote: I've not seen any follow-up to this version. Should we go ahead and adopt this? Can we please go with 'committed'

Re: [PATCH, v3] wwwdocs: e-mail subject lines for contributions

On Mon, Feb 03, 2020 at 02:54:05PM +0300, Alexander Monakov wrote: > On Mon, 3 Feb 2020, Richard Earnshaw (lists) wrote: > > > I've not seen any follow-up to this version. Should we go ahead and adopt > > this? > > Can we please go with 'committed' (lowercase) rather than all-caps COMMITTED? >

Re: [PATCH] simplify-rtx: Extend (truncate (*extract ...)) fold [PR87763]

Maxim Kuvyrkov writes: > Hi Richard, > > You patch below increases code-size on aarch64-linux-gnu with -Os on SPEC2k6 > 400.perlbench and 453.povray -- by 1% and 2% respectively. > > 400.perlbench,perlbench_base.default, 101,939261,951221 > 453.povray,povray_base.default,

Re: [PATCH Coroutines v1] Handle type deduction of auto and decltype(auto) with indirect_ref expression

On 2/2/20 9:28 PM, JunMa wrote: 在 2020/2/3 上午9:03, JunMa 写道: I think all you want here is:   await_expr = convert_from_reference (await_expr); Thanks, I'll update it. Regards JunMa Hi nathan, Here is the update. /* This will produce the value (if one is provided) from the

Re: [PATCH, v3] wwwdocs: e-mail subject lines for contributions

On Mon, 3 Feb 2020, Richard Earnshaw (lists) wrote: > Upper case is what glibc has, though it appears that it's a rule that is not > strictly followed. If we change it, then it becomes another friction point > between developer groups. Personally, I'd leave it as is, then turn a blind > eye to

Re: [PATCH, v4] coroutines: Fix ICE on invalid (PR93458).

On 2/1/20 6:55 AM, Iain Sandoe wrote: Nathan Sidwell wrote: On 1/30/20 9:43 AM, Iain Sandoe wrote: Hi Nathan, however. …. also, what if you find something, but it's not a type template? … I’ve switched the complain off on lookup_qualified_name and now check for a type template. I'm

Re: [PATCH] Prevent IPA-SRA from creating calls to local comdats (PR 92676)

Hello Honza, ping. Thanks, Martin On Mon, Dec 16 2019, Martin Jambor wrote: > Hi, > > since r278669 (fix for PR ipa/91956), IPA-SRA makes sure that the clone > it creates is put into the same same_comdat as the original cgraph_node, > so that it can call private comdats (such as the ipa-split

Re: Make OpenACC 'acc_get_property' with 'acc_device_current' work (was: [PATCH] Add OpenACC 2.6 `acc_get_property' support)

Hi Thomas, On 30.01.20 16:54, Thomas Schwinge wrote: > > [...] the 'acc_device_current' interface should work already now. > > [...] Please review > the attached (Tobias the Fortran test cases, please), and test with AMD > GCN offloading. If approving this patch, please respond with I have

Re: [PATCH, v3] wwwdocs: e-mail subject lines for contributions

On 03/02/2020 11:54, Alexander Monakov wrote: On Mon, 3 Feb 2020, Richard Earnshaw (lists) wrote: I've not seen any follow-up to this version. Should we go ahead and adopt this? Can we please go with 'committed' (lowercase) rather than all-caps COMMITTED? Spelling this with all-caps seems

Re: [PATCH, v3] wwwdocs: e-mail subject lines for contributions

On Mon, 3 Feb 2020, Richard Earnshaw (lists) wrote: > I've not seen any follow-up to this version. Should we go ahead and adopt > this? Can we please go with 'committed' (lowercase) rather than all-caps COMMITTED? Spelling this with all-caps seems like a recent thing on gcc-patches, before

Re: [PATCH, v3] wwwdocs: e-mail subject lines for contributions

On 22/01/2020 17:45, Richard Earnshaw (lists) wrote: [updated based on v2 discussions] This patch proposes some new (additional) rules for email subject lines when contributing to GCC.  The goal is to make sure that, as far as possible, the subject for a patch will form a good summary when the

[PATCH 2/4] [ARC] Use TARGET_INSN_COST.

TARGET_INSN_COST gives us a better control over the instruction costs than classical RTX_COSTS. A simple cost scheme is in place for the time being, when optimizing for size, the cost is given by the instruction length. When optimizing for speed, the cost is 1 for any recognized instruction, and

[PATCH 4/4] arc: Don't use if-conversion when optimizing for size.

For ARC, predicated instructions are not very friendly with size optimizations, leading to increased object size. Disable if-conversion step when optimized for size. gcc/ -xx-xx Claudiu Zissulescu * common/config/arc/arc-common.c (arc_option_optimization_table): Disable

[PATCH 1/4] [ARC] Update mlo/mhi handling when big-endian CPU.

The ARC 600 MUL64 instructions are using mlo/mhi registers to pass the 64-bit result. However, the mlo/mhi registers are not swapping depending on endianess. Update multiplication patterns to reflect this fact. gcc/ -xx-xx Claudiu Zissulescu * config/arc/arc.md (mulsidi_600):

[PATCH 3/4] [ARC] Deprecate q-class option.

This option was used to control the short instruction selection. However, there is no difference in cycles if we use or not a short instruction, and always someone wants a smaller program. gcc/ -xx-xx Claudiu Zissulescu * config/arc/arc.c (arc_conditional_register_usage): R0-R3

Re: [PR47785] COLLECT_AS_OPTIONS

On Thu, 30 Jan 2020 at 19:10, Richard Biener wrote: > > On Thu, Jan 30, 2020 at 5:31 AM Prathamesh Kulkarni > wrote: > > > > On Tue, 28 Jan 2020 at 17:17, Richard Biener > > wrote: > > > > > > On Fri, Jan 24, 2020 at 7:04 AM Prathamesh Kulkarni > > > wrote: > > > > > > > > On Mon, 20 Jan 2020

[Pingx3][GCC][PATCH][ARM]Add ACLE intrinsics for dot product (vusdot - vector, vdot - by element) for AArch32 AdvSIMD ARMv8.6 Extension

On 1/27/20 3:54 PM, Stam Markianos-Wright wrote: On 1/16/20 4:05 PM, Stam Markianos-Wright wrote: On 1/10/20 6:48 PM, Stam Markianos-Wright wrote: On 12/18/19 1:25 PM, Stam Markianos-Wright wrote: On 12/13/19 10:22 AM, Stam Markianos-Wright wrote: Hi all, This patch adds the

  1   2   >