Re: [PATCH] Deprecate -frepo option.

On 9/5/19 2:51 PM, Martin Liška wrote: > On 9/5/19 2:31 PM, Richard Biener wrote: >> On Thu, Sep 5, 2019 at 2:06 PM Jonathan Wakely wrote: >>> >>> On Thu, 5 Sep 2019 at 12:21, Martin Liška wrote: On 9/5/19 1:09 PM, Richard Biener wrote: > So, let's just remove it now? I'm

[PATCH] Refactoring the misaligned expansion bits

Hi, as discussed already I propose this little refactoring as a follow-up which is not supposed to be doing any change to the code generation. I tried to get the description of ALT_RTL right, since it changed quite a lot recently what this weird parameter does, and nobody cared to update the com

C++ PATCH for c++/91678 - wrong error with decltype and location wrapper

Compiling this testcase results in a bogus "invalid cast" error; this occurs since the introduction of location wrappers in finish_id_expression. Here we are parsing the decltype expression via cp_parser_decltype_expr which can lead to calling various fold_* and c-family routines. They use non_lv

Re: [PATCH v2] [AARCH64] Add support for new control bits CTR_EL0.DIC and CTR_EL0.IDC

Hi Kyrill, On 2019/9/5 17:41, Kyrill Tkachov wrote: > Hi Shaokun, > > On 9/5/19 10:37 AM, Shaokun Zhang wrote: >> Hi Kyrill, >> >> On 2019/9/3 19:13, Kyrill Tkachov wrote: >>> Hi Shaokun, >>> >>> On 9/3/19 9:35 AM, Shaokun Zhang wrote: The DCache clean & ICache invalidation requirements for

Re: [PATCH V3, #1 of 10], Add basic pc-relative support

On Thu, Aug 29, 2019 at 04:32:07PM -0500, Segher Boessenkool wrote: > This is not just for reload anymore, so please don't name it that. Renaming > things isn't hard, this isn't a public API or anything :-) This hasn't just be for reload for several years now. Do you have a name you prefer? --

Re: [PATCH] RISC-V: Fix bad insn splits with paradoxical subregs.

On Thu, Sep 5, 2019 at 3:03 PM Segher Boessenkool wrote: > My big question is why do other targets not have this problem? Or what > is it they do differently? RISC-V doesn't have convenient sign/zero extend instructions. We also have a 12-bit immediate, whereas most other RISCs have a 16-bit im

Re: [PATCH, V3, #8 of 10], Miscellaneous prefixed addressing tests

On Thu, Sep 05, 2019 at 05:01:25PM -0400, Michael Meissner wrote: > On Tue, Sep 03, 2019 at 06:17:23PM -0500, Segher Boessenkool wrote: > > > +/* { dg-do compile { target { powerpc*-*-* && lp64 } } } */ > > > > All of these except the ld and std and lwa should work on -m32 as well, > > right? > >

Re: [PATCH V6 05/11] bpf: new GCC port

[Resending this email, because for some reason it seems it didn't reach the list a couple of days ago.] I think the bits are in good enough shape they can go in now. Thanks! I guess I should wait for acceptance of the remaining patches not having an explicit ack? To my recollection,

Re: [PATCH, V3, #6 of 10], Fix vec_extract breakage

Hi Mike, On Thu, Sep 05, 2019 at 04:48:28PM -0400, Michael Meissner wrote: > On Tue, Sep 03, 2019 at 02:49:01PM -0500, Segher Boessenkool wrote: > > On Mon, Aug 26, 2019 at 05:20:12PM -0400, Michael Meissner wrote: > > > @@ -3249,9 +3249,10 @@ (define_insn "vsx_vslo_" > > > ;; Variable V2DI/V2DF

Re: [PATCH] RISC-V: Fix bad insn splits with paradoxical subregs.

Hi Jim, On Thu, Sep 05, 2019 at 01:34:09PM -0700, Jim Wilson wrote: > Shifting by more than the size of a SUBREG_REG doesn't work, so we either > need to disable splits if an input is paradoxical, or else we need to > generate a clean temporary for intermediate results. My big question is why do

Re: [PATCH, V3, #8 of 10], Miscellaneous prefixed addressing tests

On Tue, Sep 03, 2019 at 06:17:23PM -0500, Segher Boessenkool wrote: > On Mon, Aug 26, 2019 at 05:48:08PM -0400, Michael Meissner wrote: > > This patch contains the miscellaneous tests for GCC to test some features of > > --- gcc/testsuite/gcc.target/powerpc/paddi-1.c (revision 274879) > > +++

Re: [ARM/FDPIC v5 13/21] [ARM] FDPIC: Force LSB bit for PC in Cortex-M architecture

Christophe Lyon writes: > Sorry, I forgot again to cc: Ian. As far as I'm concerned, it's fine for architecture maintainers to approve changes to architecture-specific files in libgcc. Ian > On Thu, 5 Sep 2019 at 10:30, Christophe Lyon > wrote: >> >> On Thu, 29 Aug 2019 at 17:32, Kyrill Tk

Re: [PATCH, V3, #6 of 10], Fix vec_extract breakage

On Tue, Sep 03, 2019 at 02:49:01PM -0500, Segher Boessenkool wrote: > Hi! > > On Mon, Aug 26, 2019 at 05:20:12PM -0400, Michael Meissner wrote: > > @@ -3249,9 +3249,10 @@ (define_insn "vsx_vslo_" > > ;; Variable V2DI/V2DF extract > > (define_insn_and_split "vsx_extract__var" > >[(set (match_

[PATCH] RISC-V: Fix bad insn splits with paradoxical subregs.

Shifting by more than the size of a SUBREG_REG doesn't work, so we either need to disable splits if an input is paradoxical, or else we need to generate a clean temporary for intermediate results. This was tested with rv32i/newlib and rv64gc/linux cross builds and checks. There were no regressions

Re: C++ PATCH for c++/90537 - Implement P1286R2, Contra CWG DR1778

On Thu, Sep 05, 2019 at 04:15:06PM -0400, Jason Merrill wrote: > On Thu, Sep 5, 2019 at 2:14 PM Marek Polacek wrote: > > > > This patch implements C++20 P1286R2, Contra CWG DR1778 as described here > > . > > Essentially, it remo

Re: C++ PATCH for c++/90537 - Implement P1286R2, Contra CWG DR1778

On Thu, Sep 5, 2019 at 2:14 PM Marek Polacek wrote: > > This patch implements C++20 P1286R2, Contra CWG DR1778 as described here > . > Essentially, it removes the restriction that the exception specification of > a defaulted spe

Re: [PR fortran/91496] !GCC$ directives error if mistyped or unknown

Looks like a straight forward mechanical change. Probably doesn't need a review. OK. -- steve On Thu, Sep 05, 2019 at 09:55:58PM +0200, Harald Anlauf wrote: > Ping! > > On 08/28/19 21:58, Harald Anlauf wrote: > > Hi Bernhard, > > > > On 08/28/19 20:57, Bernhard Reutner-Fischer wrote: > >> I

Re: [PR fortran/91496] !GCC$ directives error if mistyped or unknown

Ping! On 08/28/19 21:58, Harald Anlauf wrote: > Hi Bernhard, > > On 08/28/19 20:57, Bernhard Reutner-Fischer wrote: >> I see that you copied the unfortunate error-message "commence a loop" >> and i see that i completely forgot to adjust it as per Mike's >> preference in >> https://gcc.gnu.org/ml/

[PATCH, libstdc++] Doc changes for constexpr additions for C++20 status.

Here is a patch to the libstdc++ docs re constexpr additions. They reflect the latest macro assignments AFAICT. Constexpr interator reqs are implemented in 9.1, the rest for 10.1. Ok? Should I bother adding the Constexpr interator requirements to the gcc-9 branch docs? Ed Index: doc/html/

Re: [PATCH][middle-end/88784] Middle end is missing some optimizations about unsigned

On 9/5/19 3:17 PM, Richard Biener wrote: That said, the patterns can be quite a bit simplified I think. I will take care of it as well. Martin

Re: [PATCH][middle-end/88784] Middle end is missing some optimizations about unsigned

On 9/5/19 3:01 PM, Richard Biener wrote: Not sure if you or Martin wants to improve it according to my comments. Yes please. I'm working on that based on the review you provided. Thanks, Martin

C++ PATCH for c++/90537 - Implement P1286R2, Contra CWG DR1778

This patch implements C++20 P1286R2, Contra CWG DR1778 as described here . Essentially, it removes the restriction that the exception specification of a defaulted special member matches the implicit exception specification. "Impl

Re: [PATCH v2 4/6] compiler-gcc.h: add asm_inline definition

On Thu, Sep 5, 2019 at 5:52 PM Miguel Ojeda wrote: > > Yes and no. GNU libc defines feature test macros like you say, but > C++'s feature macros are like Rasmus/Nick are saying. I think libc's > definition is weird, I would call those "feature selection macros" > instead, because the user is selec

[PATCH] Fix testcase to not use vtable verification with LTO

Yesterday I submitted a patch that disallows using vtable verfication with LTO (they don't work properly together), but I missed fixing the flags for one testcase. This patch fixes that omission. Testing: Tescase passes with this change. Is this ok to commit? -- Caroline cmt...@google.com Chang

[OG9, committed] Backport GCN expcnt patches

I just committed the attached patch to the openacc-gcc-9-branch. The patch removes the redundant s_waitcnt instruction from store instructions. The s_waitcnt with expcnt was a misunderstanding of the documentation. Andrew Backport expcnt patches. 2019-09-05 Andrew Stubbs Backport from m

Re: [PATCH] [ARM] Adjust test expectations of unaligned-memcpy-2/3.c (PR 91614)

On 03/09/2019 21:45, Bernd Edlinger wrote: Hi, due to the introduction of unaligned_loaddi and unaligned_storedi, two test cases show some regression as PR 91614 points out. I would like to change the test expectations if these two test cases, since they seem to be bogus. That is the test case

Re: [PATCH v2 4/6] compiler-gcc.h: add asm_inline definition

On Thu, Sep 5, 2019 at 3:45 PM Segher Boessenkool wrote: > > [ That's not what a feature test macro is; a feature test macro allows the > user to select some optional behaviour. Things like _GNU_SOURCE. ] Yes and no. GNU libc defines feature test macros like you say, but C++'s feature macros

[PATCH][GCC] Optimize unnecessary casts out of binary math operations.

Hello, This patch changes a match.pd expression so that binary math expressions will not be done in the precision of it's widest type if -funsafe-math-optimizations is enabled. This patch has been extracted from https://gcc.gnu.org/ml/gcc-patches/2019-09/msg00072.html based on upstream comments.

Re: [PATCH] detect strcat/strcpy overflowing member arrays (PR 91631)

On 9/4/19 3:15 PM, Martin Sebor wrote: > While testing some other buffer overflow improvements I was > reminded that GCC doesn't detect even some basic instances > of overflowing struct members involving strcpy calls with > non-constant strings, with or without _FORTIFY_SOURCE.  For > example: > >

[PATCH] PR tree-optimization/90836 Missing popcount pattern matching

This patch adds matching for Hamming weight (popcount) implementation. The following sources: int foo64 (unsigned long long a) { unsigned long long b = a; b -= ((b>>1) & 0xULL); b = ((b>>2) & 0xULL) + (b & 0xULL); b = ((b>>4) + b) &

Re: C++ PATCH for c++/91644 - ICE with constinit in function template

On 9/4/19 3:06 PM, Marek Polacek wrote: On Wed, Sep 04, 2019 at 04:00:24PM -0400, Jason Merrill wrote: On 9/3/19 4:08 PM, Marek Polacek wrote: First constinit bug report (yay?). The problem is that while I made sure that constinit variable templates work as they should, I clearly neglected ord

Re: [PATCH 2/6] [og9] OpenACC middle-end worker-partitioning support

On Thu, 5 Sep 2019 21:52:00 +0800 Chung-Lin Tang wrote: > On 2019/9/5 9:45 AM, Julian Brown wrote: > > Much of omp-sese.c originates from code written for NVPTX by Nathan > > Sidwell (adapted to work on gimple instead of RTL) -- though at > > present, only the per-basic-block scheme is implemente

Re: [PATCH v2 4/6] compiler-gcc.h: add asm_inline definition

On Thu, Sep 05, 2019 at 04:23:11PM +0200, Rasmus Villemoes wrote: > On 05/09/2019 15.45, Segher Boessenkool wrote: > > On Thu, Sep 05, 2019 at 01:07:11PM +0200, Rasmus Villemoes wrote: > >> Perhaps something like below, though that > >> won't affect the already released gcc 9.1 and 9.2, of course.

Re: [PATCH, AArch64, v3 0/6] LSE atomics out-of-line

Hi Richard, >What I have not done, but is now a possibility, is to use a custom >calling convention for the out-of-line routines. I now only clobber >2 (or 3, for TImode) temp regs and set a return value. This would be a great feature to have since it reduces the overhead of outlinin

Re: [committed, amdgcn] Remove expcnt waits.

On 31/07/2019 13:02, Andrew Stubbs wrote: However, in a couple of cases there is an exposed-pipeline issue that needs to be resolved with an actual "nop", which we no longer have. The patch also takes care of adding these, where appropriate. (As it happens, the cmpswap instruction will now get

Re: [PATCH v2 4/6] compiler-gcc.h: add asm_inline definition

On 05/09/2019 15.45, Segher Boessenkool wrote: > Hi Rasmus, > > On Thu, Sep 05, 2019 at 01:07:11PM +0200, Rasmus Villemoes wrote: >> On 05/09/2019 02.18, Nick Desaulniers wrote: >>> Is it too late to ask for a feature test macro? Maybe one already >>> exists? >> >> No, not as far as I know. > >

Re: [ PATCH ] C++20

On 05/09/19 12:27 +0100, Jonathan Wakely wrote: On 04/09/19 18:47 -0400, JeanHeyd Meneide wrote: Thank you for the thorough review! On Tue, Sep 3, 2019 at 9:31 AM Jonathan Wakely wrote: It looks like__adl_begin and __adl_end should be guarded by #ifdef _GLIBCXX_P1394 because they're not ne

Re: [PATCH 2/6] [og9] OpenACC middle-end worker-partitioning support

On 2019/9/5 9:45 AM, Julian Brown wrote: Much of omp-sese.c originates from code written for NVPTX by Nathan Sidwell (adapted to work on gimple instead of RTL) -- though at present, only the per-basic-block scheme is implemented, and the SESE-finding algorithm isn't yet used. Hi Julian, it appe

Re: [PATCH v2 4/6] compiler-gcc.h: add asm_inline definition

Hi Rasmus, On Thu, Sep 05, 2019 at 01:07:11PM +0200, Rasmus Villemoes wrote: > On 05/09/2019 02.18, Nick Desaulniers wrote: > > Is it too late to ask for a feature test macro? Maybe one already > > exists? > > No, not as far as I know. [ That's not what a feature test macro is; a feature test m

Re: [PATCH] Fix unaligned TARGET_MEM_REF expansion (PR 91615)

On Thu, 5 Sep 2019, Bernd Edlinger wrote: > Hi, > > it turns out the TARGET_MEM_REF causes ICEs in armeb-none-linux-gnueabihf, > a big-endian cross compiler. See PR 91615. > > All of them are caused by an unaligned TARGET_MEM_REF for which there is > no movmisalign optab, as it seems. > > Fixe

Re: [PATCH] Fix ICE with TYPE_TRANSPARENT_AGGR (PR middle-end/91001)

On Thu, 5 Sep 2019, Jakub Jelinek wrote: > Hi! > > The following testcase ICEs on most targets. The problem is that > initialize_argument_information properly considers the type of the first > field in this case for how the aggregate should be passed, but then > load_register_parameters uses the

Re: [PATCH][middle-end/88784] Middle end is missing some optimizations about unsigned

On Tue, 16 Jul 2019, Li Jia He wrote: > Hi, > > I made some changes based on the recommendations. Would you like to > help me to see it again ? Sorry, it took so long time to provide the > patch. > > Note: 1. I keep the code for and_comparisons_1 and or_comparisons_1. > The reason

Re: [PATCH][middle-end/88784] Middle end is missing some optimizations about unsigned

On Tue, 16 Jul 2019, Li Jia He wrote: > Hi, > > I made some changes based on the recommendations. Would you like to > help me to see it again ? Sorry, it took so long time to provide the > patch. > > Note: 1. I keep the code for and_comparisons_1 and or_comparisons_1. > The reason

Re: [PATCH, AArch64, v3 4/6] aarch64: Add out-of-line functions for LSE atomics

On 9/5/19 1:12 PM, Richard Henderson wrote: On 9/5/19 3:00 AM, Kyrill Tkachov wrote: +/* Define the symbol gating the LSE implementations.  */ +extern _Bool __aa64_have_atomics +    __attribute__((visibility("hidden"), nocommon)); + Bootstrapping this patch series on an Armv8-A system with OO

Re: [PATCH] Deprecate -frepo option.

On 9/5/19 2:31 PM, Richard Biener wrote: > On Thu, Sep 5, 2019 at 2:06 PM Jonathan Wakely wrote: >> >> On Thu, 5 Sep 2019 at 12:21, Martin Liška wrote: >>> >>> On 9/5/19 1:09 PM, Richard Biener wrote: So, let's just remove it now? >>> >>> I'm all for that. May I install the patch? >> >> To b

Re: [SVE] PR86753

On Thu, 5 Sep 2019 at 14:29, Richard Sandiford wrote: > > Sorry for the slow reply. > > Prathamesh Kulkarni writes: > > On Fri, 30 Aug 2019 at 16:15, Richard Biener > > wrote: > >> > >> On Wed, Aug 28, 2019 at 11:02 AM Richard Sandiford > >> wrote: > >> > > >> > Prathamesh Kulkarni writes: >

Re: [PATCH] Deprecate -frepo option.

On Thu, Sep 5, 2019 at 2:06 PM Jonathan Wakely wrote: > > On Thu, 5 Sep 2019 at 12:21, Martin Liška wrote: > > > > On 9/5/19 1:09 PM, Richard Biener wrote: > > > So, let's just remove it now? > > > > I'm all for that. May I install the patch? > > To be clear, I wasn't objecting to installing the

Re: [PATCH, AArch64, v3 5/6] aarch64: Implement -matomic-ool

On 9/5/19 2:56 AM, Kyrill Tkachov wrote: > On 11/1/18 9:46 PM, Richard Henderson wrote: >> +  else if (TARGET_ATOMIC_OOL) >> +    { >> +  /* Oldval must satisfy compare afterward.  */ >> +  if (!aarch64_plus_operand (oldval, mode)) >> +   oldval = force_reg (mode, oldval); >> +  rtx

Re: [PATCH, AArch64, v3 4/6] aarch64: Add out-of-line functions for LSE atomics

On 9/5/19 3:00 AM, Kyrill Tkachov wrote: >> +/* Define the symbol gating the LSE implementations.  */ >> +extern _Bool __aa64_have_atomics >> +    __attribute__((visibility("hidden"), nocommon)); >> + > > Bootstrapping this patch series on an Armv8-A system with OOL atomics enabled > by default ga

Re: [PATCH] Deprecate -frepo option.

On Thu, 5 Sep 2019 at 12:21, Martin Liška wrote: > > On 9/5/19 1:09 PM, Richard Biener wrote: > > So, let's just remove it now? > > I'm all for that. May I install the patch? To be clear, I wasn't objecting to installing the patch now, just asking whether it would be possible to revert it later i

Re: [ PATCH ] C++20

On 04/09/19 18:47 -0400, JeanHeyd Meneide wrote: Thank you for the thorough review! On Tue, Sep 3, 2019 at 9:31 AM Jonathan Wakely wrote: It looks like__adl_begin and __adl_end should be guarded by #ifdef _GLIBCXX_P1394 because they're not needed otherwise. I'm absolutely going to ne

Re: [PATCH] Deprecate -frepo option.

On 9/5/19 1:09 PM, Richard Biener wrote: > So, let's just remove it now? I'm all for that. May I install the patch? Martin

[preprocessor/91639] #includes at EOF

This fixes 91639. #include processing needs to rewind by one line before doing the inclusion, so that that happens on the #include line itself. Except that the lexer doesn't increment the lineno on the last \n of a file -- because there's no point. So we had code in the include path to figur

[PATCH v3 9/9] S/390: Test signaling FP comparison instructions

gcc/testsuite/ChangeLog: 2019-08-09 Ilya Leoshkevich PR target/77918 * gcc.target/s390/s390.exp: Enable Fortran tests. * gcc.target/s390/zvector/autovec-double-quiet-eq.c: New test. * gcc.target/s390/zvector/autovec-double-quiet-ge.c: New test. * gcc.tar

[PATCH v3 6/9] S/390: Remove code duplication in vec_unordered

vec_unordered is vec_ordered plus a negation at the end. Reuse vec_unordered logic. gcc/ChangeLog: 2019-08-13 Ilya Leoshkevich PR target/77918 * config/s390/vector.md (vec_unordered): Call gen_vec_ordered. --- gcc/config/s390/vector.md | 14 +++--- 1 file chan

[PATCH v3 8/9] S/390: Use signaling FP comparison instructions

dg-torture.exp=inf-compare-1.c is failing, because (qNaN > +Inf) comparison is compiled to CDB instruction, which does not signal an invalid operation exception. KDB should have been used instead. This patch introduces a new CCmode and a new pattern in order to generate signaling instructions in t

[PATCH v3 5/9] S/390: Implement vcond expander for V1TI,V1TF

Currently gcc does not emit wf{c,k}* instructions when comparing long double values. Middle-end actually adds them in the first place, but then veclower pass replaces them with floating point register pair operations, because the corresponding expander is missing. gcc/ChangeLog: 2019-08-09 Ilya

[PATCH v3 7/9] S/390: Remove code duplication in vec_* comparison expanders

s390.md uses a lot of near-identical expanders that perform dispatching to other expanders based on operand types. Since the following patch would require even more of these, avoid copy-pasting the code by generating these expanders using an iterator. gcc/ChangeLog: 2019-08-09 Ilya Leoshkevich

[PATCH v3 4/9] S/390: Do not use signaling vector comparisons on z13

z13 supports only non-signaling vector comparisons. This means we cannot vectorize LT, LE, GT, GE and LTGT when compiling for z13. Notify middle-end about this using more restrictive operator predicate in vcond. gcc/ChangeLog: 2019-08-21 Ilya Leoshkevich PR target/77918 * co

[PATCH v3 3/9] Introduce can_vector_compare_p function

z13 supports only non-signaling vector comparisons. This means we cannot vectorize LT, LE, GT, GE and LTGT when compiling for z13. However, we cannot express this restriction today: the code only checks whether vcond$a$b optab exists, which does not contain information about the operation. Introd

[PATCH v3 2/9] Introduce rtx_alloca, alloca_raw_REG and alloca_rtx_fmt_*

One of the next patches in series needs to frequently pass short-lived fake rtxes to the back-end in order to test its capabilities. In order to reduce the load on GC, it is beneficial to allocate these rtxes on stack. Provide the macro counterparts of gen_* functions required by the next patch i

Re: [PATCH] Deprecate -frepo option.

On Thu, Sep 5, 2019 at 1:02 PM Nathan Sidwell wrote: > > On 9/5/19 6:03 AM, Martin Liška wrote: > > On 9/5/19 12:01 PM, Richard Biener wrote: > >> On Wed, Sep 4, 2019 at 2:57 PM Nathan Sidwell wrote: > >>> > >>> On 9/4/19 7:20 AM, Martin Liška wrote: > On 9/4/19 11:22 AM, Jonathan Wakely wro

[PATCH v3 0/9] S/390: Use signaling FP comparison instructions

Bootstrapped and regtested on s390x-redhat-linux, x86_64-redhat-linux, ppc64le-redhat-linux. This patch series adds signaling FP comparison support (both scalar and vector) to s390 backend. Patches 1-4 make it possible to query supported vcond rtxes and make use of that for z13. Patches 5-7 are

[PATCH v3 1/9] Allow COND_EXPR and VEC_COND_EXPR condtions to trap

Right now gimplifier does not allow VEC_COND_EXPR's condition to trap and introduces a temporary if this could happen, for example, generating _5 = _4 > { 2.0e+0, 2.0e+0, 2.0e+0, 2.0e+0 }; _6 = VEC_COND_EXPR <_5, { -1, -1, -1, -1 }, { 0, 0, 0, 0 }>; from GENERIC VEC_COND_EXPR < (*b > { 2.0

Re: [PATCH v2 4/6] compiler-gcc.h: add asm_inline definition

On 05/09/2019 02.18, Nick Desaulniers wrote: > On Fri, Aug 30, 2019 at 4:15 PM Rasmus Villemoes > wrote: >> >> This adds an asm_inline macro which expands to "asm inline" [1] when gcc >> is new enough (>= 9.1), and just asm for older gccs and other >> compilers. >> >> Signed-off-by: Rasmus Villemo

Re: [PATCH] Deprecate -frepo option.

On 9/5/19 6:03 AM, Martin Liška wrote: On 9/5/19 12:01 PM, Richard Biener wrote: On Wed, Sep 4, 2019 at 2:57 PM Nathan Sidwell wrote: On 9/4/19 7:20 AM, Martin Liška wrote: On 9/4/19 11:22 AM, Jonathan Wakely wrote: The point of the warning was to see if users complain. Three weeks isn't

[PATCH] Fix PR90501

The following fixes D testsuite ICEs by properly marking a return slot addressable after we built an address of it during inlining. Bootstrapped / tested on x86_64-unknown-linux-gnu, applied. Richard. 2019-09-05 Richard Biener PR middle-end/90501 * tree-inline.c (declare_re

Re: [PATCH] Fix PR91657 (and likely dups)

On Thu, 5 Sep 2019, Richard Biener wrote: > > I've made an error with the gcse-after-reload patch in disabling > record_last_mem_set_info, but only for the first function so > testing didn't reveal it. > > The following fixes this, avoding a few more allocations when > not needing transp computa

Re: [PATCH] Deprecate -frepo option.

On 9/5/19 12:01 PM, Richard Biener wrote: > On Wed, Sep 4, 2019 at 2:57 PM Nathan Sidwell wrote: >> >> On 9/4/19 7:20 AM, Martin Liška wrote: >>> On 9/4/19 11:22 AM, Jonathan Wakely wrote: >> >> The point of the warning was to see if users complain. Three weeks isn't a very long time to

Re: [PATCH, AArch64, v3 4/6] aarch64: Add out-of-line functions for LSE atomics

Hi Richard, On 11/1/18 9:46 PM, Richard Henderson wrote: This is the libgcc part of the interface -- providing the functions. Rationale is provided at the top of libgcc/config/aarch64/lse.S.     * config/aarch64/lse-init.c: New file.     * config/aarch64/lse.S: New file.     * confi

Re: [PATCH] Deprecate -frepo option.

On Wed, Sep 4, 2019 at 2:57 PM Nathan Sidwell wrote: > > On 9/4/19 7:20 AM, Martin Liška wrote: > > On 9/4/19 11:22 AM, Jonathan Wakely wrote: > > > >> The point of the warning was to see if users complain. Three weeks > >> isn't a very long time to see if users are going to complain :-) > >> > >

Re: [PATCH, AArch64, v3 5/6] aarch64: Implement -matomic-ool

Hi Richard, On 11/1/18 9:46 PM, Richard Henderson wrote:     * config/aarch64/aarch64.opt (-matomic-ool): New.     * config/aarch64/aarch64.c (aarch64_atomic_ool_func): New.     (aarch64_ool_cas_names, aarch64_ool_swp_names): New.     (aarch64_ool_ldadd_names, aarch64_ool_ldset_n

Re: r272976 - in /trunk/gcc/ada: ChangeLog ali.adb ...

> > Can someone please remind me in which repository I can find the GCC > > prerequisites doc sources? > > Answering my own question: found it under gcc/doc/install.texi > > Working on it... Just installed the following change on trunk, thanks again for your feedback! 2019-09-05 Arnaud Charlet

Re: [PATCH, AArch64, v3 0/6] LSE atomics out-of-line

Hi Richard, On 11/1/18 9:46 PM, Richard Henderson wrote: From: Richard Henderson Changes since v2:   * Committed half of the patch set.   * Split inline TImode support from out-of-line patches.   * Removed the ST out-of-line functions, to match inline.   * Moved the out-of-line functions to as

Re: [PATCH][GCC] Simplify to single precision where possible for binary/builtin maths operations.

On Tue, Sep 3, 2019 at 5:23 PM Barnaby Wilks wrote: > > > > On 9/3/19 9:23 AM, Richard Biener wrote: > > On Mon, 2 Sep 2019, Barnaby Wilks wrote: > > > >> Hello, > >> > >> This patch introduces an optimization for narrowing binary and builtin > >> math operations to the smallest type when unsafe m

Re: [PATCH v2] [AARCH64] Add support for new control bits CTR_EL0.DIC and CTR_EL0.IDC

Hi Shaokun, On 9/5/19 10:37 AM, Shaokun Zhang wrote: Hi Kyrill, On 2019/9/3 19:13, Kyrill Tkachov wrote: Hi Shaokun, On 9/3/19 9:35 AM, Shaokun Zhang wrote: The DCache clean & ICache invalidation requirements for instructions to be data coherence are discoverable through new fields in CTR_EL

Re: [PATCH v2] [AARCH64] Add support for new control bits CTR_EL0.DIC and CTR_EL0.IDC

Hi Kyrill, On 2019/9/3 19:13, Kyrill Tkachov wrote: > Hi Shaokun, > > On 9/3/19 9:35 AM, Shaokun Zhang wrote: >> The DCache clean & ICache invalidation requirements for instructions >> to be data coherence are discoverable through new fields in CTR_EL0. >> Let's support the two bits if they are e

Re: [PATCHv5] Fix not 8-byte aligned ldrd/strd on ARMv5 (PR 89544)

On 9/5/19 11:21 AM, Richard Earnshaw (lists) wrote: > On 04/09/2019 16:48, Richard Earnshaw (lists) wrote: >> On 04/09/2019 16:00, Bernd Edlinger wrote: >>> On 9/4/19 4:14 PM, Richard Earnshaw (lists) wrote: On 04/09/2019 14:28, Bernd Edlinger wrote: > On 9/4/19 2:53 PM, Richard Earnshaw (

Re: [PATCHv5] Fix not 8-byte aligned ldrd/strd on ARMv5 (PR 89544)

On 04/09/2019 16:48, Richard Earnshaw (lists) wrote: On 04/09/2019 16:00, Bernd Edlinger wrote: On 9/4/19 4:14 PM, Richard Earnshaw (lists) wrote: On 04/09/2019 14:28, Bernd Edlinger wrote: On 9/4/19 2:53 PM, Richard Earnshaw (lists) wrote: Index: gcc/testsuite/gcc.target/arm/unaligned-argume

[PATCH] Fix ICE with TYPE_TRANSPARENT_AGGR (PR middle-end/91001)

Hi! The following testcase ICEs on most targets. The problem is that initialize_argument_information properly considers the type of the first field in this case for how the aggregate should be passed, but then load_register_parameters uses the type of the aggregate unmodified in the computation o

Re: [ARM/FDPIC v5 13/21] [ARM] FDPIC: Force LSB bit for PC in Cortex-M architecture

Hi Christophe, On 9/5/19 9:30 AM, Christophe Lyon wrote: On Thu, 29 Aug 2019 at 17:32, Kyrill Tkachov wrote: Hi Christophe, On 5/15/19 1:39 PM, Christophe Lyon wrote: Without this, when we are unwinding across a signal frame we can jump to an even address which leads to an exception. This i

Re: [SVE] PR86753

Sorry for the slow reply. Prathamesh Kulkarni writes: > On Fri, 30 Aug 2019 at 16:15, Richard Biener > wrote: >> >> On Wed, Aug 28, 2019 at 11:02 AM Richard Sandiford >> wrote: >> > >> > Prathamesh Kulkarni writes: >> > > On Tue, 27 Aug 2019 at 21:14, Richard Sandiford >> > > wrote: >> > >>

Re: [PATCH, i386]: Do not limit the cost of moves to/from XMM register to minimum 8.

On Thu, Sep 5, 2019 at 7:47 AM Hongtao Liu wrote: > > On Wed, Sep 4, 2019 at 9:44 AM Hongtao Liu wrote: > > > > On Wed, Sep 4, 2019 at 12:50 AM Uros Bizjak wrote: > > > > > > On Tue, Sep 3, 2019 at 1:33 PM Richard Biener > > > wrote: > > > > > > > > > Note: > > > > > > Removing limit of cost wo

Re: r272976 - in /trunk/gcc/ada: ChangeLog ali.adb ...

> Can someone please remind me in which repository I can find the GCC > prerequisites doc sources? Answering my own question: found it under gcc/doc/install.texi Working on it...

[PATCH] Fix PR91657 (and likely dups)

I've made an error with the gcse-after-reload patch in disabling record_last_mem_set_info, but only for the first function so testing didn't reveal it. The following fixes this, avoding a few more allocations when not needing transp computation and checking a variable which is actually initializ

Re: [PATCH] Disable postreload GCSE on large code

On Thu, 5 Sep 2019, Dimitar Dimitrov wrote: > On вторник, 3 септември 2019 г. 14:54:19 EEST Richard Biener wrote: > > 2019-09-02 Richard Biener > > > > PR rtl-optimization/36262 > > * postreload-gcse.c: Include intl.h and gcse.h. > > (insert_expr_in_table): Insert at th

Re: [ARM/FDPIC v5 13/21] [ARM] FDPIC: Force LSB bit for PC in Cortex-M architecture

Sorry, I forgot again to cc: Ian. Thanks, Christophe On Thu, 5 Sep 2019 at 10:30, Christophe Lyon wrote: > > On Thu, 29 Aug 2019 at 17:32, Kyrill Tkachov > wrote: > > > > Hi Christophe, > > > > On 5/15/19 1:39 PM, Christophe Lyon wrote: > > > Without this, when we are unwinding across a signal

Re: [ARM/FDPIC v5 13/21] [ARM] FDPIC: Force LSB bit for PC in Cortex-M architecture

On Thu, 29 Aug 2019 at 17:32, Kyrill Tkachov wrote: > > Hi Christophe, > > On 5/15/19 1:39 PM, Christophe Lyon wrote: > > Without this, when we are unwinding across a signal frame we can jump > > to an even address which leads to an exception. > > > > This is needed in __gnu_persnality_sigframe_fd

Re: [ARM/FDPIC v5 04/21] [ARM] FDPIC: Add support for FDPIC for arm architecture

Christophe Lyon writes: > + if (SYMBOL_REF_P (orig)) > +{ > + if (CONSTANT_POOL_ADDRESS_P (orig)) > + { > + *is_readonly = true; > + return true; > + } > + if (SYMBOL_REF_LOCAL_P (orig) > + && !SYMBOL_REF_EXTERNAL_P (orig) > + && SYMBOL_REF_DECL (orig

RE: [PATCH] [ARC] Pass along -mcode-density flag to the assembler

It looks good. I'll merge it asap. Thank you for your contribution, Claudiu > -Original Message- > From: Shahab Vahedi [mailto:shahab.vah...@gmail.com] > Sent: Tuesday, September 03, 2019 7:14 PM > To: Claudiu Zissulescu > Cc: Shahab Vahedi ; gcc-patches@gcc.gnu.org; > Francois Bedard >

[PATCH] Remove broken URL from libstdc++ manual

The URL for the "What Are Allocators Good For?" article has been a recurring source of problems. It moved from the C/C++ Users Journal website to the Dr Dobbs site after CUJ shut down, and the original domain changed hands, leaving old links pointing to nefarious sites. Now the URL to the copy on

Re: r272976 - in /trunk/gcc/ada: ChangeLog ali.adb ...

Maciej, Thank you for your comments, I definitely agree with you that the document is too well hidden and could be improved, I'll work on that and put the Ada build requirements in a single, easier to find place (probably the prerequisites since both you and I started from there). Can someone ple

Re: [PATCH] PR fortran/91660 -- Improve and restore error messages

On Thu, Sep 5, 2019 at 7:51 AM Steve Kargl wrote: > > Built and regression tested on x86_64-*-freebsd. > > The patch restores an improved error message for a malformed > type-spec. See pr91660_1.f90 for code demonstrating problem. > While here, improve the error messages for other malformed > typ