Re: [RFC][PR82479] missing popcount builtin detection

On Wed, Jan 24, 2018 at 10:56 PM, Kugan Vivekanandarajah wrote: > Hi All, > > Here is a patch for popcount builtin detection similar to LLVM. I > would like to queue this for review for next stage 1. > > 1. This is done part of loop-distribution and effective for -O3 and above. > 2. This does not

PR84033, powerpc64le -moptimize-swaps bad code with vec_vbpermq

vbpermq produces its output in bits 48..63 of the target vector reg, so the output cannot be lane swapped. Bootstrapped and regression tested powerpc64le-linux. OK to apply mainline, and backport to the branches? gcc/ PR target/84033 * config/rs6000/rs6000-p8swap.c (rtx_is_swappa

Re: Add support for bitwise reductions

Rainer Orth writes: > Jeff Law writes: >> On 11/22/2017 11:12 AM, Richard Sandiford wrote: >>> Richard Sandiford writes: This patch adds support for the SVE bitwise reduction instructions (ANDV, ORV and EORV). It's a fairly mechanical extension of existing REDUC_* operators.

[nvptx, PR84028] Add exit insn after noreturn call for neutered workers

Hi, [ Note: this is similar to "[nvptx, PR81352] Add exit insn after noreturn call for neutered threads in warp" https://gcc.gnu.org/ml/gcc-patches/2018-01/msg02013.html ]. atm the test-case contained in this patch hangs at -O1 and higher. For the test-case we generate: ... $L4: @ %r56 bra

[PATCH] Fix PR84003

The following patch fixes PR84003 where RTL DSE removes a redundant store (a store storing the same value as an earlier store) but in doing this changing program semantics because the later store changes the effective type of the memory location. This in turn allows sched2 to do an originally inv

[PATCH] Fix PR81082

The mitigation for PR66313 (bogus re-association causing undefined overflow) causes missed optimizations because the fix was to perform possibly dangerous transforms in unsigned arithmetic. Unfortunately this loses knowledge of no-overflow which means SCEV analysis when facing the unsigned comput

Re: [PATCH] Fix PR81082

On Thu, 25 Jan 2018, Richard Biener wrote: --- gcc/match.pd(revision 257047) +++ gcc/match.pd(working copy) @@ -1939,6 +1939,37 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT) (minus (convert (view_convert:stype @1)) (convert (view_convert:stype @2))) +/* (A * C) +-

Re: [PATCH] Fix PR81082

On Thu, 25 Jan 2018, Marc Glisse wrote: > On Thu, 25 Jan 2018, Richard Biener wrote: > > > --- gcc/match.pd(revision 257047) > > +++ gcc/match.pd(working copy) > > @@ -1939,6 +1939,37 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT) > > (minus (convert (view_convert:stype @1)) > > (co

Re: PR84033, powerpc64le -moptimize-swaps bad code with vec_vbpermq

On Jan 25, 2018, at 4:09 AM, Alan Modra wrote: > > vbpermq produces its output in bits 48..63 of the target vector reg, > so the output cannot be lane swapped. Bootstrapped and regression > tested powerpc64le-linux. OK to apply mainline, and backport to the > branches? I can't approve, but FWI

Re: C++ PATCH to fix ICE with vector expr folding (PR c++/83659)

On Fri, Jan 05, 2018 at 09:52:36AM +0100, Richard Biener wrote: > On Wed, Jan 3, 2018 at 5:31 PM, Marek Polacek wrote: > > Here we are crashing because cxx_fold_indirect_ref got a POINTER_PLUS_EXPR > > with offset > signed HOST_WIDE_INT and we tried to convert it to sHWI. > > > > The matching code

Re: [PATCH] PR fortran/83998 -- fix dot_product on 0-sized arrays

On Thu, Jan 25, 2018 at 08:37:54AM +0100, Thomas Koenig wrote: > First, why is > > > @@ -2253,22 +2253,19 @@ gfc_simplify_dim (gfc_expr *x, gfc_expr *y) > > gfc_expr* > > gfc_simplify_dot_product (gfc_expr *vector_a, gfc_expr *vector_b) > > { > > + /* If vector_a is a zero-sized array, the

Go patch committed: Don't write sink constants to the C header file

This patch to the Go frontend skips writing sink constants to the C header file. These are constants named "_". We were generating nonsensical $sinkconst names in the header files, which are unnecessary and can break building the C code in some cases. Bootstrapped on x86_64-pc-linux-gnu. Committ

[og7] Build libffi during bootstrap.

I've applied this patch to openacc-gcc-7-branch to build libffi during bootstrap whenever it's required by libgomp. This was causing the host OpenACC execution test to fail in libgomp because the struct containing the offloaded data mappings wasn't being expanded into individual variables at runtim

[C++ PATCH] Fix decomp handling of unnamed bitfields (PR c++/84031)

Hi! Unnamed bitfields are not data members, so we should ignore them when counting the members or picking up members to initialize from, and also should ignore them in find_decomp_class_base, they can appear in various bases etc. and still there could be just one base containing direct non-static

Re: [PATCH] Fix ICEs with "omp declare simd" attribute on versioned fns or omp_fn* (PR middle-end/83977)

On Wed, Jan 24, 2018 at 06:51:54PM +0100, Richard Biener wrote: > >Well, "omp declare simd" is a part of the ABI just for the original > >exported > >functions, for everything else it is a pure optimization, but I'm not > >sure > >if we want to deoptimize e.g. callers of these functions outside of

libbacktrace patch committed: Another memcpy -> coff_read4 fix

This libbacktrace patch fixes another cases where memcpy was used in a way that would leave some bytes uninitialized on a 64-bit system. Committed to mainline. Ian 2018-01-25 Ian Lance Taylor * pecoff.c (coff_add): Another memcpy -> coff_read4 fix. Index: pecoff.c

libbacktrace patch committed: Only free sym_view if it is valid

Another libbacktrace patch to avoid use of uninitialized memory: only free sym_view if it is valid. Committed to mainline. Ian 2018-01-25 Ian Lance Taylor * pecoff.c (coff_add): Only release syms_view if it is valid. Index: pecoff.c ===

Re: [C++ PATCH] Fix decomp handling of unnamed bitfields (PR c++/84031)

OK. On Thu, Jan 25, 2018 at 10:26 AM, Jakub Jelinek wrote: > Hi! > > Unnamed bitfields are not data members, so we should ignore them when > counting the members or picking up members to initialize from, and > also should ignore them in find_decomp_class_base, they can appear > in various bases e

Re: [C++ PATCH] Fix decomp handling of unnamed bitfields (PR c++/84031)

Hi all, On 25/01/2018 16:26, Jakub Jelinek wrote: + || (DECL_C_BIT_FIELD (field) && !DECL_NAME (field))) By the way, I see we are accumulating uses of DECL_C_BIT_FIELD && !DECL_NAME, shall we add a new macro? For Stage 1? In case, how shall we name it? Paolo.

Re: [C++ PATCH] Fix decomp handling of unnamed bitfields (PR c++/84031)

On Thu, Jan 25, 2018 at 11:17 AM, Paolo Carlini wrote: > Hi all, > > On 25/01/2018 16:26, Jakub Jelinek wrote: >> >> + || (DECL_C_BIT_FIELD (field) && !DECL_NAME (field))) > > By the way, I see we are accumulating uses of DECL_C_BIT_FIELD && > !DECL_NAME, shall we add a new macro? For Stage

Re: [C++ PATCH] Fix decomp handling of unnamed bitfields (PR c++/84031)

Hi, On 25/01/2018 17:25, Jason Merrill wrote: On Thu, Jan 25, 2018 at 11:17 AM, Paolo Carlini wrote: Hi all, On 25/01/2018 16:26, Jakub Jelinek wrote: + || (DECL_C_BIT_FIELD (field) && !DECL_NAME (field))) By the way, I see we are accumulating uses of DECL_C_BIT_FIELD && !DECL_NAME, s

Re: [PATCH] Fix missing profiles with PGO (PR tree-optimization/83051).

> Hello. > > Following ICE can be seen when we have -fprofile-generate or -fprofile-use w/ > missing > gcda file. I hope the proper fix is to check for reliable profile. > > Patch can bootstrap on ppc64le-redhat-linux and survives regression tests. > > Ready to be installed? > Martin > > gcc/C

libgo patch committed: fix lfstackUnpack on ia64

This libgo patch by James Clarke fixes lfstackUnpack on ia64. The top three region number bits must be masked out before right-shifting the address bits into place, otherwise they will be copied down into the lower always-zero address bits. Bootstrapped and ran Go runtime tests on x86_64-pc-linux

Re: bugs in external debug info support in libbacktrace

On Mon, Nov 27, 2017 at 2:23 AM, Milian Wolff wrote: > > I was made aware that libbacktrace got support for external debug info with > [1], great work! I have just synced the latest libbacktrace into heaptrack [2] > in a local branch and played around with it and noticed two limitations: > > [1]:

Re: [PATCH] PR fortran/83998 -- fix dot_product on 0-sized arrays

On Thu, Jan 25, 2018 at 07:06:10AM -0800, Steve Kargl wrote: > On Thu, Jan 25, 2018 at 08:37:54AM +0100, Thomas Koenig wrote: > > > > Second, why do you remove this > > > > > - temp.value.op.op = INTRINSIC_NONE; > > > - temp.value.op.op1 = vector_a; > > > - temp.value.op.op2 = vector_b; > > >

[PATCH] Document PowerPC 'native' cpu type

The PowerPC port(s) of GCC have included auto-detection of host cpu type through the "native" option, but it had not been documented. This patch adds the documentation to the GCC Manual. * doc/invoke.texi (PowerPC Options): Document 'native' cpu type. Thanks, David Index: invoke.texi ===

Re: [PATCH] Document PowerPC 'native' cpu type

Hi! On Thu, Jan 25, 2018 at 01:24:56PM -0500, David Edelsohn wrote: > +Specifying @samp{native} as cpu type detects and selects the > +architecture option that corresponds to the host processor of the > +system performing the compilation. > +@option{-march=native} has no effect if GCC does not rec

Re: [PATCH] Document PowerPC 'native' cpu type

On Thu, Jan 25, 2018 at 1:44 PM, Segher Boessenkool wrote: > Hi! > > On Thu, Jan 25, 2018 at 01:24:56PM -0500, David Edelsohn wrote: >> +Specifying @samp{native} as cpu type detects and selects the >> +architecture option that corresponds to the host processor of the >> +system performing the comp

[PATCH] fix for diagnostic/84034

Hi, as PR diagnostic/84034 shows, source files with dos style line endings can cause a glitch in the terminal emulation that erases the source line that is supposed to be shown. That happens when the colorizing escape sequences are printed between the CR and the LF. Apparently the LF is being ig

Re: [PATCH, rs6000] Updates for vec_neg() gimple-folding vector tests

Hi! On Wed, Jan 24, 2018 at 10:45:49AM -0600, Will Schmidt wrote: > Update the vec-neg-longlong folding tests to handle codegen variations > as seen between p8 and p9 targets. (And fold-vec-neg-int). > 2018-01-24 Will Schmidt > > * gcc.target/powerpcfold-vec-neg-longlong.h: Ne

Re: [PATCH] PR fortran/83998 -- fix dot_product on 0-sized arrays

Hi Steve, thanks for your explanations. The patch is OK for trunk. Thanks a lot! Regards Thomas

Re: [PATCH] PR fortran/83998 -- fix dot_product on 0-sized arrays

On Thu, Jan 25, 2018 at 07:58:22PM +0100, Thomas Koenig wrote: > Hi Steve, > > thanks for your explanations. > > The patch is OK for trunk. Thanks a lot! > Upon even further reading, the code segment with temp might be needed. If one looks in compute_dot_product(), one finds result = gfc_ge

Re: [Bug fortran/83999] [8 Regression] ICE in gfc_trans_assignment_1, at fortran/trans-expr.c:10233

Hi Jakub, Thanks for the OK and the help in getting the padding sorted out. Committed as Committed revision 257065. Paul On 24 January 2018 at 20:26, Paul Richard Thomas wrote: > Hi Jakub, > > I have made the changes to the types of the dtype elements that you > suggested. It led to a cast bei

Re: [PATCH, rs6000] Updates for vec_abs() gimple-folding vector tests

Hi! On Wed, Jan 24, 2018 at 10:46:02AM -0600, Will Schmidt wrote: > 2018-01-24 Will Schmidt > > * gcc.target/powerpc/fold-vec-abs-int.c: remove scan-assembler stanzas. Only one space after : and start with a cap. > * gcc.target/powerpc/fold-vec-abs-int-fwrap.c: Same. > *

Re: [PATCH] PR fortran/83998 -- fix dot_product on 0-sized arrays

On Thu, Jan 25, 2018 at 11:07:04AM -0800, Steve Kargl wrote: > On Thu, Jan 25, 2018 at 07:58:22PM +0100, Thomas Koenig wrote: > > Hi Steve, > > > > thanks for your explanations. > > > > The patch is OK for trunk. Thanks a lot! > > > > Upon even further reading, the code segment with temp might

Re: [PATCH, rs6000] Updates for vec_cmp_*() gimple-folding vector testcases

Hi! On Wed, Jan 24, 2018 at 10:46:11AM -0600, Will Schmidt wrote: > Assorted updates for the vector intrinsics / gimple folding vec_cmp() > testcases to handle codegen variations as seen between P8,P9 targets. > This breaks apart the testcases into a #included header that contains the > testcase

[committed] jit: remove some unused fields from recording::union_ (PR jit/81672)

gcc::jit::recording::union_ has some stray fields, which are duplicates of those in the compound_type base class. It looks like these have been present since the initial merger of the jit branch to trunk (r217374), where it had three duplicate fields: location *m_loc; string *m_name; fields *m

[PATCH] RL78 addsi3 improvement

Hello, The following patch improves addsi3 by eliminating addw ax, #0 and replacing addw ax, #-1 with decw ax where possible (if operand 2 is const) The patch adds also a test case to check this. Regression test is OK, tested with the following command: make -k check-gcc RUNTESTFLAGS=--target_b

Re: [PATCH] RL78 addsi3 improvement

This is OK. I wonder if these types of optimizations should be added to the assembler too? At least, if relaxation is enabled...

Re: [PATCH] Fix PR84003

Richard Biener writes: > The following patch fixes PR84003 where RTL DSE removes a redundant > store (a store storing the same value as an earlier store) but in > doing this changing program semantics because the later store changes > the effective type of the memory location. This in turn allows

Re: [PATCH] Fix PR84003

Richard Sandiford writes: > Richard Biener writes: >> The following patch fixes PR84003 where RTL DSE removes a redundant >> store (a store storing the same value as an earlier store) but in >> doing this changing program semantics because the later store changes >> the effective type of the memo

Re: [SFN+LVU+IEPM v4 7/9] [LVU] Introduce location views

On Jan 24, 2018, Jakub Jelinek wrote: > On Tue, Dec 12, 2017 at 12:52:18AM -0200, Alexandre Oliva wrote: >> --- a/include/dwarf2.h >> +++ b/include/dwarf2.h >> @@ -298,6 +298,14 @@ enum dwarf_location_list_entry_type >> DW_LLE_start_end = 0x07, >> DW_LLE_start_length = 0x08, >> >> + /* >>

Re: [SFN+LVU+IEPM v4 9/9] [IEPM] Introduce inline entry point markers

On Jan 24, 2018, Jakub Jelinek wrote: > I think this asks for > if (flag_checking) > gcc_assert (block_within_block_p (block, > DECL_INITIAL (current_function_decl), > true)); 'k, changed. > Otherwise the patch looks

Re: [C++ PATCH] Fix constexpr handling of arrays with unknown bound (PR c++/83993)

On 01/24/2018 04:19 PM, Jakub Jelinek wrote: Hi! In constexpr evaluation of array references for arrays with unknown bounds, we need to diagnose out of bounds accesses, but really don't know the bounds at compile time, right now GCC will see nelts as error_mark_node + 1 and will not consider the

Re: [PATCH, rs6000] Fix PR56010 and PR83743, -mcpu=native use wrong names

Hi! On Wed, Jan 24, 2018 at 03:49:26PM -0600, Peter Bergner wrote: > The following patch fixes both PR56010 and PR83743. PR56010 is fixed by > adding an extra altname field to the RS6000_CPU table which matches the > cases where the Linux kernel's AT_PLATFORM name differs from the name GCC > expe

Re: [PR81611] improve auto-inc

On Jan 24, 2018, Richard Biener wrote: > given gimple_assign_ssa_name_copy checks it is an assign *nod* > the lhs != preinc check is always false given you got to phi via > SSA_NAME_DEF_STMT of preinc. *nod* > The simple_iv_increment_p change is ok with that change. Thanks, I'll retest with

Re: Go patch committed: Rationalize external symbol names

Hi Ian, > This patch to the Go frontend rationalizes the external symbol names > that appear in assembler code. It changes from the ad hoc mechanisms > used to date to produce a set of names that are at least somewhat more > coherent. They are also more readable, after applying a simple > demang

Re: [PATCH][Middle-end][version 2]2nd patch of PR78809 and PR83026

Hi, Jeff, Really sorry for my delay. Your email on 1/12/2018 and Richard’s email on 1/15/2018, were completely lost in my mailboxes until yesterday my colleague, Paolo Carlini, forwarded it to me. I really apologize for the late reply. Please see my reply below: > On Jan 12, 2018, at 4:

Re: PR84033, powerpc64le -moptimize-swaps bad code with vec_vbpermq

On Thu, Jan 25, 2018 at 08:39:21PM +1030, Alan Modra wrote: > vbpermq produces its output in bits 48..63 of the target vector reg, > so the output cannot be lane swapped. Bootstrapped and regression > tested powerpc64le-linux. OK to apply mainline, and backport to the > branches? > > gcc/ >

[PATCH] PR libgcc/59714 complex division is surprising on aarch64

From: Vladimir Mezentsev Tested on aarch64-linux-gnu, x86_64-pc-linux-gnu and sparc64-unknown-linux-gnu. No regression. New tests now passed. There is a performance degradation for complex double type: failed cases |time old new| old new complex-32

Re: [PATCH][Middle-end][version 2]2nd patch of PR78809 and PR83026

> > We're now in stage4 so please queue this patch and ping it during > next stage1. > I will update my patch based on Jeff and your comments, and send it during next stage 1. thanks. Qing

Re: Go patch committed: Rationalize external symbol names

On Thu, Jan 25, 2018 at 12:28 PM, Rainer Orth wrote: > >> This patch to the Go frontend rationalizes the external symbol names >> that appear in assembler code. It changes from the ad hoc mechanisms >> used to date to produce a set of names that are at least somewhat more >> coherent. They are a

Re: Go patch committed: Rationalize external symbol names

On Thu, Jan 25, 2018 at 12:40:13PM -0800, Ian Lance Taylor wrote: > >> Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu. Committed > >> to mainline. > > > > this patch almost certainly (i.e. I didn't reghunt, but it's the only > > plausible candidate between r257023 and r257057) Solaris/x8

Re: Go patch committed: Rationalize external symbol names

Hi Ian, > From the error messages I guess the problem is that the assembler > doesn't like symbols that start with ".1". Do you know what names the > assembler permits? The x86 Assembly Language Reference Manual states: 2.1.2.1 Identifiers An identifier is an arbitrarily-long sequence of lette

[C++ Patch] Add DECL_UNNAMED_BIT_FIELD and use it

Hi, this is the complete patch, tested x86_64-linux. Thanks, Paolo. /c-family 2018-01-25 Paolo Carlini * c-common.h (DECL_UNNAMED_BIT_FIELD): New. /c 2018-01-25 Paolo Carlini * c-typeck.c (really_start_incremental_init, push_init_level,

Silence false positive on LTO type merging waring

Hi, the testcase triggers invalid warning on type mismatch because array of pointers to complete type has different alias set from array of pointers to incomplete type. This is valid, because incoplete pointer has alias set of void_ptr which alias all pointers and arrays alias with their members.

C++ PATCH to fix rejects-valid with constexpr ctor in C++17 (PR c++/83692)

This is a similar problem to 83116: we'd cached a constexpr call, but after a store the result had become invalid, yet we used the wrong result again when encountering the same call later. This resulted in evaluating a THROW_EXPR which doesn't work. Details in https://gcc.gnu.org/bugzilla/show_bu

Re: [PATCH, rs6000] Fix PR56010 and PR83743, -mcpu=native use wrong names

On 1/25/18 2:18 PM, Segher Boessenkool wrote: > Don't add this to rs6000-cpus.def; it belongs to the Linux support only. Well, the reason I liked adding it to rs6000-cpus.def is that it keeps the names together, so only one place to hold all of the info. If you prefer a separate table, then I can

[PATCH] Fix -Wrestrict SSA_NAME handling (PR c/83989)

Hi! builtin_memref ctor for a SSA_NAME with non-NULL SSA_NAME_VAR returns the underlying variable, rather than just the SSA_NAME. Later on the code checks if the bases are equal and then compares corresponding offsets. The fact that two different SSA_NAMEs have the same underlying variable says n

Re: C++ PATCH to fix rejects-valid with constexpr ctor in C++17 (PR c++/83692)

On Thu, Jan 25, 2018 at 10:16:39PM +0100, Marek Polacek wrote: > This is a similar problem to 83116: we'd cached a constexpr call, but after a > store the result had become invalid, yet we used the wrong result again when > encountering the same call later. This resulted in evaluating a THROW_EXPR

[PATCH] Fix RTL DCE with separate shrink wrapped epilogues (PR rtl-optimization/83985)

Hi! The r241060 change added the second hunk in this patch which the patch is reverting. The problem is that not deleting some unmarked insns in delete_unmarked_insns is done in a wrong place, it causes indeed not to delete the instruction we don't want to DCE, but the instructions that are neede

Re: [C++ PATCH] Speed up inplace_merge algorithm & fix inefficient logic(PR c++/83938)

Hi: 1. The __len = (__len + 1) / 2; is as you suggested, need to modify as __len = (__len == 1) ? 0 : ((__len + 1) / 2); 2. The coding gain has been shown PR c++/83938; I re-post here 21 20 19 18 17 16 0.471136 0.625695 0.767262 0.907461 1.04838 1.19508 0.340845

Re: [C++ PATCH] Fix constexpr handling of arrays with unknown bound (PR c++/83993)

On Thu, Jan 25, 2018 at 01:13:56PM -0700, Martin Sebor wrote: > On 01/24/2018 04:19 PM, Jakub Jelinek wrote: > > Hi! > > > > In constexpr evaluation of array references for arrays with unknown bounds, > > we need to diagnose out of bounds accesses, but really don't know the bounds > > at compile t

Re: Go patch committed: Rationalize external symbol names

On Thu, Jan 25, 2018 at 12:50 PM, Rainer Orth wrote: > >> From the error messages I guess the problem is that the assembler >> doesn't like symbols that start with ".1". Do you know what names the >> assembler permits? > > The x86 Assembly Language Reference Manual states: Thanks. Looking back,

Go patch committed: Look through aliases when looking for methods

This patch to the Go frontend fixes it to look through aliases when looking for methods. The code is simplified by adding Type::is_alias to do this, replacing a few existing loops. This fixes https://golang.org/issue/23489. The test case for this is https://golang.org/cl/89935. Bootstrapped and

Re: [PATCH] Fix RTL DCE with separate shrink wrapped epilogues (PR rtl-optimization/83985)

On Thu, Jan 25, 2018 at 11:20:33PM +0100, Jakub Jelinek wrote: > Hi! > > The r241060 change added the second hunk in this patch which the patch is > reverting. The problem is that not deleting some unmarked insns in > delete_unmarked_insns is done in a wrong place, it causes indeed not to > delet

Re: [PATCH] PR libgcc/59714 complex division is surprising on aarch64

On Thu, 25 Jan 2018, vladimir.mezent...@oracle.com wrote: > From: Vladimir Mezentsev > > Tested on aarch64-linux-gnu, x86_64-pc-linux-gnu and > sparc64-unknown-linux-gnu. > No regression. New tests now passed. > There is a performance degradation for complex double type: This is, of course, so

[PATCH] restore -Warray-bounds for string literals (PR 83776)

PR tree-optimization/83776 - [6/7/8 Regression] missing -Warray-bounds indexing past the end of a string literal, identified a not-so-recent improvement to constant propagation as the reason for GCC no longer being able to detect out-of- bounds accesses to string literals. The root cause is that

Re: [PATCH, rs6000] Fix PR56010 and PR83743, -mcpu=native use wrong names

On 1/25/18 3:56 PM, Peter Bergner wrote: > Ok, I'll move the table to driver-rs6000.c and I'll resubmit. Ok, here is a separate translation table like you wanted. I still use the RS6000_CPU table to hold entire list of canonical cpu names, the new translation table in driver-rs6000.c only contain

Re: [PATCH] Fix various x86 avx512{bitalg, vpopcntdq, vbmi2} issues (PR target/83488)

Hello Julia, On 24 Jan 14:00, Koval, Julia wrote: > Hi, > Fixed it. Ok for trunk? > > gcc/ > * config/i386/avx512bitalgintrin.h (_mm512_bitshuffle_epi64_mask, > _mm512_mask_bitshuffle_epi64_mask, _mm256_bitshuffle_epi64_mask, > _mm256_mask_bitshuffle_epi64_mask, _mm_bitshuffle_ep

Re: [PATCH, wwwdocs] Update GCC 8 release notes for NDS32 port

Gerald Pfeifer on 2018/1/23 22:39 wrote: On Tue, 23 Jan 2018, Chung-Ju Wu wrote: +New command-line options -mext-perf -mext-perf2 -mext-string Can you write this as "...-mext-perf, -mext-perf2, and -mext-string..." please? Approved with that change. Thank you for the review. :)