Re: __float128 typeinfo

On 06/06/14 16:40, Marc Glisse wrote: On Fri, 6 Jun 2014, Ramana Radhakrishnan wrote: On Fri, Jun 6, 2014 at 3:16 PM, Marc Glisse wrote: Hello, here is a new try on adding __float128 typeinfo to libsupc++. The front-end part is based on the discussion with Jason yesterday. The libstdc

Re: [PATCH ARM] PR/61062 Fix arm_neon.h ZIP/UZP/TRN for bigendian

On Wed, May 14, 2014 at 2:52 PM, Alan Lawrence wrote: > Hi, > > Due to differences in how the ARM C Language Extensions and gcc's vector > extensions deal with indices within vectors, the __builtin_shuffle masks > used to implement the ZIP, UZP and TRN Neon Intrinsics in arm_neon.h are > correct o

Re: [Patch ARM/testsuite 00/22] Neon intrinsics executable tests

On 06/06/14 15:40, Christophe Lyon wrote: On 6 June 2014 01:32, Joseph S. Myers wrote: Have these been tested for both big and little endian (especially for tests where memory layout matters - load / store / lane number tests - remembering that GNU C vector initializers always use array orderin

[Patch ARM] Remove XFmode from arm-modes.def

Ramana Radhakrishnan * config/arm/arm-modes.def: Remove XFmode. Index: gcc/config/arm/arm-modes.def === --- gcc/config/arm/arm-modes.def(revision 211317) +++ gcc/config/arm/arm-modes.def(working copy) @@ -21,9

Re: [RFC][ARM] TARGET_ATOMIC_ASSIGN_EXPAND_FENV hook

On Tue, Jun 10, 2014 at 12:25 AM, Kugan wrote: > On 30/05/14 18:35, Ramana Radhakrishnan wrote: >>> + if (!TARGET_VFP) >>> +return; >>> + >>> + /* Generate the equivalence of : >> >> s/equivalence/equivalent. >> >> Ok with

Re: [Patch ARM/testsuite 00/22] Neon intrinsics executable tests

On Thu, Jun 5, 2014 at 11:04 PM, Christophe Lyon wrote: > This is patch series is a more complete version of the patch I sent > some time ago: > https://gcc.gnu.org/ml/gcc-patches/2013-10/msg00624.html > > I have created a series of patches to help review. The 1st one adds > some documentation, t

Re: [PATCH] Install config/vxworks-dummy.h for plugins on arm (PR plugins/45078)

On 06/13/14 19:17, Jakub Jelinek wrote: On Thu, Jun 12, 2014 at 07:47:49PM +0200, Jakub Jelinek wrote: Seems http://gcc.gnu.org/r197156 effectively reverted the PR45078 fix for arm*-linux* (where unfortunately tm_file is always overridden). Was the removal of vxworks-dummy.h from that line inte

Re: breakage with "[PATCH 1/6] Add FOR_EACH_INSN{_INFO}_{DEFS,USES,EQ_USES}"

On Mon, Jun 16, 2014 at 9:04 AM, Andreas Schwab wrote: > Hans-Peter Nilsson writes: > >> On Sun, 15 Jun 2014, Hans-Peter Nilsson wrote: >> >>> On Sun, 15 Jun 2014, Hans-Peter Nilsson wrote: >>> > On Sun, 15 Jun 2014, Steven Bosscher wrote: >>> > > Can you please try: >>> > > >>> > > [...] >>> > >

Re: Another AIX Bootstrap failure

On Mon, Jun 16, 2014 at 5:35 AM, Jan Hubicka wrote: >> Honza, >> >> The cgraph patch in r211600 broke AIX bootstrap again. I cannot find >> the corresponding patch in the GCC Patches mailing list, so I do not >> see where this was discussed or approved. > > Sorry, I remember writting mail about t

[Patch LRA] PR 61522 - Handle NULL targetm.spill_class

breakage causing commit on arm-none-linux-gnueabihf) I'll apply this in about 45 minutes when I get back to my desk if no one objects. regards Ramana 2014-06-16 Ramana Radhakrishnan PR rtl-optimization/61522 * lra-assigns.c (assign_by_spills): Handle

Re: [Patch LRA] PR 61522 - Handle NULL targetm.spill_class

On Mon, Jun 16, 2014 at 5:11 PM, Vladimir Makarov wrote: > On 2014-06-16, 11:05 AM, Ramana Radhakrishnan wrote: >> >> Hi, >> >> This handles NULL targetm.spill_class in assign_by_spills. This >> showed up as a segfault during a build for arm-none-linux-gnuea

Re: Another AIX Bootstrap failure

On Mon, Jun 16, 2014 at 4:08 PM, Jan Hubicka wrote: >> Honza, >> >> Thanks for reverting the patch. I will check if this resolves the >> current bootstrap problem. >> >> I was suggesting that you create a branch for all of the visibility >> changes to make it easier to track the various original p

Re: [PATCH, ARM] MI-thunk fix for TARGET_THUMB1_ONLY

On Sun, Jun 8, 2014 at 12:27 PM, Chung-Lin Tang wrote: > Hi Richard, Ramana, > > Attached is a small fix for resolving a g++.old-deja/g++.jason/thunk2.C > regression we found under a TARGET_THUMB1_ONLY multilib (-mthumb > -march=armv6-m to be exact). Basically under those conditions, the thunk > i

Re: [PATCH, PR61219]: Fix sNaN handling in ARM float to double conversion

On Sun, May 18, 2014 at 10:23 PM, Aurelien Jarno wrote: > On ARM soft-float, the float to double conversion doesn't convert a sNaN > to qNaN as the IEEE Std 754 standard mandates: > > "Under default exception handling, any operation signaling an invalid > operation exception and for which a floati

Re: [RFC ARM] Error if overriding --with-tune by --with-cpu

On Fri, May 30, 2014 at 5:34 PM, James Greenhalgh wrote: > > Hi, > > We error in the case where both --with-tune and --with-cpu are specified at > configure time. In this case, we cannot distinguish this situation from the > situation where --with-tune was specified at configure time and -mcpu was

Re: [PATCH][ARM] FAIL: gcc.target/arm/pr58041.c scan-assembler ldrb

On Fri, May 30, 2014 at 12:19 AM, Maciej W. Rozycki wrote: > On Wed, 28 May 2014, Richard Earnshaw wrote: > >> Ah, light dawns (maybe). >> >> I guess the problems stem from the attempts to combine Neon with ARMv5. >> Neon shouldn't be used with anything prior to ARMv7, since that's the >> earlies

Re: [PATCH] [ARM] [RFC] Fix longstanding push_minipool_fix ICE (PR49423, lp1296601)

On Wed, Apr 2, 2014 at 2:29 PM, Charles Baylis wrote: > Hi > > This patch fixes the push_minipool_fix ICE, which occurs when the ARM > backend encounters a zero/sign extending load from a constant pool. > > I don't have a current test case for trunk, lp1296601 has a test case > which affects the l

[Patch libstdc++] PR61536 Export out of line comparison operations.

-gnueabihf. Paolo proposed this on the bugzilla and asked if I could commit it. I've tweaked the comment slightly. Tested on arm-none-linux-gnueabihf and verified the link time failures now disappear. Applied to trunk. Ramana 2014-06-18 Paolo Carlini Ramana Radhakri

Re: [RFC][ARM]: Fix reload spill failure (PR 60617)

On Mon, Jun 16, 2014 at 1:53 PM, Venkataramanan Kumar wrote: > Hi Maintainers, > > This patch fixes the PR 60617 that occurs when we turn on reload pass > in thumb2 mode. > > It occurs for the pattern "*ior_scc_scc" that gets generated for the 3 > argument of the below function call. > > JIT:emitS

Re: [PATCH] [ARM] Post-indexed addressing for NEON memory access

On Mon, Jun 2, 2014 at 5:47 PM, Charles Baylis wrote: > This patch adds support for post-indexed addressing for NEON structure > memory accesses. > > For example VLD1.8 {d0}, [r0], r1 > > > Bootstrapped and checked on arm-unknown-gnueabihf using Qemu. > > Ok for trunk? This is OK. Ramana > > > g

Re: [PATCH] [ARM] Post-indexed addressing for NEON memory access

On Tue, Jun 17, 2014 at 4:03 PM, Charles Baylis wrote: > On 5 June 2014 07:27, Ramana Radhakrishnan wrote: >> On Mon, Jun 2, 2014 at 5:47 PM, Charles Baylis >> wrote: >>> This patch adds support for post-indexed addressing for NEON structure >>> memory accesse

Re: [PATCH, ARM] Enable fuse-caller-save for ARM

On Sun, Jun 1, 2014 at 12:27 PM, Tom de Vries wrote: > Richard, > > This patch: > - adds the for TARGET_CALL_FUSAGE_CONTAINS_NON_CALLEE_CLOBBERS required > clobbers in CALL_INSN_FUNCTION_USAGE, > - sets TARGET_CALL_FUSAGE_CONTAINS_NON_CALLEE_CLOBBERS to true, which > enables > the fuse-caller-

Re: [PATCH] Fix for PR 61561

On 19/06/14 16:12, Kyrill Tkachov wrote: On 19/06/14 16:05, Marat Zakirov wrote: Hi all, Here's a patch for PR 61561 (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61561). It fixes ICE. Thanks for your contribution. However, this is *really* not the way to submit a patch and is the sort

Re: [PATCH] Fix 61565 -- cmpelim vs non-call exceptions

On 20/06/14 21:28, Richard Henderson wrote: There aren't too many users of the cmpelim pass, and previously they were all small embedded targets without an FPU. I'm a bit surprised that Ramana decided to enable this pass for aarch64, as that target is not so limited as the block comment for th

Re: [PATCH] Fix 61565 -- cmpelim vs non-call exceptions

On 23/06/14 15:01, Richard Henderson wrote: On 06/23/2014 02:29 AM, Ramana Radhakrishnan wrote: On 20/06/14 21:28, Richard Henderson wrote: There aren't too many users of the cmpelim pass, and previously they were all small embedded targets without an FPU. I'm a bit surprised t

[Patch ARM/testsuite] Adjust flags for gcc.target/vect-noalign.c

=vfpv3-d16/-mfloat-abi=softfp} and {-mthumb/-march=armv8-a/-mfpu=crypto-neon-fp-armv8/-mfloat-abi=hard} on the AEM. Ramana 2014-06-25 Ramana Radhakrishnan * gcc.target/arm/vect-noalign.c: Adjust options. Index: gcc/testsuite/gcc.target/arm/vect-noalign.c

Re: [patch passes.def]: Fix regression on ARM PR/61608

[Apologies about the duplicates to folks - resending to make this hit the lists] On 25/06/14 16:28, Jeff Law wrote: On 06/25/14 09:04, Kai Tietz wrote: 2014-06-25 16:04 GMT+02:00 Jeff Law : So why is the peephole not working in its current location? Jeff Hi Jeff, that is what I read out o

Re: [Patch ARM/testsuite 01/22] Neon intrinsics execution tests initial framework.

On Thu, Jun 5, 2014 at 11:04 PM, Christophe Lyon wrote: > * documentation (README) > * dejanu driver (neon-intrinsics.exp) > * support macros (arm-neon-ref.h, compute-ref-data.h) > * Tests for 2 intrinsics: vaba, vld1 > > diff --git a/gcc/testsuite/gcc.target/arm/neon-intrinsics/README > b/gcc/te

Re: [PATCH ARM] Improve ARM memset inlining

On Tue, May 6, 2014 at 5:59 AM, bin.cheng wrote: > > >> -Original Message- >> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches- >> ow...@gcc.gnu.org] On Behalf Of bin.cheng >> Sent: Monday, May 05, 2014 3:21 PM >> To: Richard Earnshaw >> Cc: gcc-patches@gcc.gnu.org >> Subject: RE: [

Re: [Patch ARM/testsuite 02/22] Add unary operators: vabs and vneg.

On Thu, Jun 5, 2014 at 11:04 PM, Christophe Lyon wrote: > > diff --git a/gcc/testsuite/gcc.target/arm/neon-intrinsics/unary_op.inc > b/gcc/testsuite/gcc.target/arm/neon-intrinsics/unary_op.inc > new file mode 100644 > index 000..33f9b5f > --- /dev/null > +++ b/gcc/testsuite/gcc.target/arm/neo

Re: [Patch ARM/testsuite 03/22] Add binary operators: vadd, vand, vbic, veor, vorn, vorr, vsub.

On Thu, Jun 5, 2014 at 11:04 PM, Christophe Lyon wrote: > vadd tests also show how to add directives to scan the assembly > output. > > diff --git a/gcc/testsuite/gcc.target/arm/neon-intrinsics/binary_op.inc > b/gcc/testsuite/gcc.target/arm/neon-intrinsics/binary_op.inc > new file mode 100644 > i

Re: [Patch ARM/testsuite 03/22] Add binary operators: vadd, vand, vbic, veor, vorn, vorr, vsub.

>> I'd rather drop the scan-assembler. I'm not convinced that the fragile >> nature of this is required. Can you add a note to the README that says >> that this is meant to be a complete execution test for the Advanced >> SIMD intrinsics and does not cover all the assembler that is > > Sure. > >> g

Re: [PATCH ARM]Handle REG addressing mode in output_move_neon explicitly

On Mon, May 5, 2014 at 8:21 AM, bin.cheng wrote: > > >> -Original Message- >> From: Richard Earnshaw >> Sent: Thursday, May 01, 2014 10:03 PM >> To: Bin Cheng >> Cc: gcc-patches@gcc.gnu.org >> Subject: Re: [PATCH ARM]Handle REG addressing mode in >> output_move_neon explicitly >> >> On 29/

Re: [Patch ARM-AArch64/testsuite v2 02/21] Add unary operators: vabs and vneg.

On Tue, Jul 1, 2014 at 11:05 AM, Christophe Lyon wrote: > > diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog > index 3a0f99b..44c4990 100644 > --- a/gcc/testsuite/ChangeLog > +++ b/gcc/testsuite/ChangeLog > @@ -1,5 +1,11 @@ > 2014-06-30 Christophe Lyon > > + * gcc.target/aa

Re: [Patch ARM-AArch64/testsuite v2 03/21] Add binary operators: vadd, vand, vbic, veor, vorn, vorr, vsub.

On Tue, Jul 1, 2014 at 11:05 AM, Christophe Lyon wrote: > > diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog > index 44c4990..73709c6 100644 > --- a/gcc/testsuite/ChangeLog > +++ b/gcc/testsuite/ChangeLog > @@ -1,5 +1,16 @@ > 2014-06-30 Christophe Lyon > > + * gcc.target/aa

Re: [Patch, GCC/Thumb-1]Mishandle the label type insn in function thumb1_reorg

On Fri, Jul 4, 2014 at 10:36 AM, Bin.Cheng wrote: > On Wed, Jun 18, 2014 at 10:16 AM, Terry Guo wrote: >> >> >>> -Original Message- >>> From: Richard Earnshaw >>> Sent: Wednesday, June 18, 2014 4:31 PM >>> To: Terry Guo >>> C

Re: [PATCH ARM]Handle REG addressing mode in output_move_neon explicitly

>> > This is the rebased patch, though the original one doesn't conflict with > latest trunk. Is it OK? Ok. Ramana > > Thanks, > bin

Re: [PATCH][ARM] Fix PR 65955: Do not take REGNO on non-REG operand in movcond_addsi

On 05/05/15 09:22, Kyrill Tkachov wrote: Hi all, As the PR says, the movcond_addsi pattern takes the REGNO of an operand that may be a CONST_INT. The fix for that is rather simple (perhaps even obvious?). Unfortunately the testcase is in ada, and I'm not sure how to integrate this into the

Re: [PATCH] Add {u,}mulvhi4 patterns on i?86 (PR target/66112)

On Tue, May 12, 2015 at 7:43 PM, Jakub Jelinek wrote: > Hi! > > This patch improves expansion of __builtin_mul_overflow for HImode, both > signed and unsigned, on x86_64/i686. > > Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? > > 2015-05-12 Jakub Jelinek > > PR ta

Re: [PATCH, ARM, doc] add missing -mtune options

On 07/05/15 23:12, Jim Wilson wrote: I noticed that the list of -mtune options in the arm-cores.def file didn't match the list in the doc/invoke.texi file. There are 3 cores missing: generic-armv7-a, cortex-a17, and cortex-a17.cortex-a7. This patch adds the missing cores to the docs. Jim

Re: Fwd: [PING 2][PATCH] libgcc: Add CFI directives to the soft floating point support code for ARM

On 12/05/15 14:01, Martin Galvan wrote: On Tue, May 12, 2015 at 5:49 AM, Ramana Radhakrishnan wrote: That's what I mean when I say email clients "munged it" : email clients and / or some popular email servers appear to end up munging white spaces and patches don't apply

Re: Fwd: [PING 2][PATCH] libgcc: Add CFI directives to the soft floating point support code for ARM

On 13/05/15 17:37, Ramana Radhakrishnan wrote: On 12/05/15 14:01, Martin Galvan wrote: On Tue, May 12, 2015 at 5:49 AM, Ramana Radhakrishnan wrote: That's what I mean when I say email clients "munged it" : email clients and / or some popular email servers appear to end u

Re: [ARM] fix arm bootstrap

On 15/05/15 07:41, Kugan wrote: Hi Richard, r223090 seem to miss a parenthesis and seem to be causing: from ../../widen/gcc/fold-const.c:46: ../../widen/gcc/fold-const.c: In function 'tree_node* fold_range_test(location_t, tree_code, tree, tree, tree)': ../../widen/gcc/confi

Re: Fwd: [PING 2][PATCH] libgcc: Add CFI directives to the soft floating point support code for ARM

On 13/05/15 19:11, Martin Galvan wrote: Here's the new patch. I downloaded the gcc sources from the SVN repository, removed the extra semicolon from my version of the files and re-generated the patch using svn diff, making sure the context info had all the tabs from the original. I then e-maile

Re: [PATCH][ARM] PR/65711: Don't pass '-dynamic-linker' when '-shared' is used

On Thu, Apr 23, 2015 at 9:29 AM, Ludovic Courtès wrote: > As discussed at . > > Patch is for both 4.8 and 4.9 (possibly 5.1 too, I haven’t checked.) > OK for trunk. This is also ok for all release branches if no objections in 24 hours. Sorry ab

[Patch ARM] Add cpu_defines.h for ARM

. regards Ramana 2015-05-17 Ramana Radhakrishnan * configure.host: Define cpu_defines_dir for ARM. * config/cpu/arm/cpu_defines.h: New file. Index: ChangeLog === --- ChangeLog (revision 223359) +++ ChangeLog

[Patch AArch64] Add cpu_defines.h for AArch64.

Hi, Like the ARM port, the AArch64 ports needs to set glibc_integral_traps to false as integer divide instructions do not trap. Bootstrapped and regression tested on aarch64-none-linux-gnu Ok to apply ? regards Ramana 2015-05-17 Ramana Radhakrishnan * configure.host: Define

Re: [Patch AArch64] Add cpu_defines.h for AArch64.

On Tue, May 19, 2015 at 4:54 PM, wrote: > > > > >> On May 19, 2015, at 5:54 AM, Ramana Radhakrishnan >> wrote: >> >> Hi, >> >> Like the ARM port, the AArch64 ports needs to set glibc_integral_traps to >> false as integer divide instr

[Patch AArch64] PR target/66200 - gcc / libstdc++ TLC for weak memory models.

bably wrongly on the assumption that one doesn't need the barriers elsewhere). I suspect other architectures like MIPS may also be affected by this. commit 414345c424fa020717c6c3083089cd987f3032db Author: Ramana Radhakrishnan Date: Wed May 20 13:55:44 2015 +0100 Add relaxed memory or

Re: [Patch AArch64] PR target/66200 - gcc / libstdc++ TLC for weak memory models.

And here's an additional patch for the testsuite which was missed in the original posting. This is a testism that's testing code generation as per TARGET_RELAXED_ORDERING being false and therefore needs to be adjusted as attached. Ramana PR target/66200 * g++.dg/abi/aarch64_guard1.C: Adjust

Re: [PATCH] [PATCH][ARM] Fix sibcall testcases.

On Wed, May 20, 2015 at 9:11 PM, Joseph Myers wrote: > On Wed, 20 May 2015, Alex Velenko wrote: > >> Hi, >> >> This patch prevents arm_thumb1_ok XPASS in sibcall-3.c and sibcall-4.c >> testcases. Sibcalls are not ok for Thumb1 and testcases need to be fixed. > > arm_thumb1_ok means "this is an ARM

[Patch ARM] Fix PR target/65937

Testism introduced by last commit to fix PR26702 on arm-*-linux* targets. The fix is to restore target selector to arm*-*-eabi* as the target macro changes only affect arm*-*-eabi* Applied to trunk as obvious Ramana * gcc.target/arm/pr26702.c: Adjust target selector. Index: gcc.target/arm/pr2

Re: [patch, testsuite, ARM] don't try to execute advsimd-intrinsics tests on hardware without NEON

On 21/05/15 06:33, Sandra Loosemore wrote: ARM testing shares the AArch64 advsimd-intrinsics execution tests. On ARM, though, the NEON support being tested is optional -- some arches are compatible with the NEON compilation options but hardware available for testing might or might not be able

[RFC / CFT] PR c++/66192 - Remove TARGET_RELAXED_ORDERING and use load acquires.

+ adrpx20, .LANCHOR0 + add x19, x20, :lo12:.LANCHOR0 + ldarx0, [x19] + tbz x0, 0, .L11 +.L9: + ldr x0, [x19, 8] regards Ramana 2015-05-22 Ramana Radhakrishnan PR c++/66192 * config/alpha/alpha.c (TARGET_RELAXED_ORDERING): Like

Re: [RFC / CFT] PR c++/66192 - Remove TARGET_RELAXED_ORDERING and use load acquires.

Bah ! now with patch attached. Ramana diff --git a/gcc/config/alpha/alpha.c b/gcc/config/alpha/alpha.c index 1ba99d0..857c9ac 100644 --- a/gcc/config/alpha/alpha.c +++ b/gcc/config/alpha/alpha.c @@ -9987,12 +9987,6 @@ alpha_atomic_assign_expand_fenv (tree *hold, tree *clear, tree *update) #unde

Re: [PATCH 1/3][AArch64] Strengthen barriers for sync-fetch-op builtins.

> > Ok for trunk? I can't approve but do you mind taking care of -march=armv8-a in the arm backend too as that would have the same issues. Ramana > Matthew > > gcc/ > 2015-05-21 Matthew Wahab > > * config/aarch64/aarch64.c (aarch64_emit_post_barrier): New. > (aarch64_split_ato

[Patch libstdc++] Rewrite cpu/generic/atomic_word.h

neric/atomic_word.h: Rewrite using atomics. commit a360fdf84683777db764ba313354da92691aeb17 Author: Ramana Radhakrishnan Date: Fri May 22 08:00:10 2015 + rewrite as atomics. diff --git a/libstdc++-v3/config/cpu/generic/atomic_word.h b/libstdc++-v3/config/cpu/generic/atomic_word.h index 19

Re: [PATCH][ARM] Handle UNSPEC_VOLATILE in rtx costs and don't recurse inside the unspec

On Mon, Apr 20, 2015 at 5:28 PM, Kyrill Tkachov wrote: > Hi all, > > A pet project of mine is to get to the point where backend rtx costs > functions won't have > to handle rtxes that don't match down to any patterns/expanders we have. Or > at least limit such cases. > A case dealt with in this pa

Re: [RFC / CFT] PR c++/66192 - Remove TARGET_RELAXED_ORDERING and use load acquires.

On 22/05/15 14:40, Jason Merrill wrote: On 05/22/2015 07:23 AM, Ramana Radhakrishnan wrote: + /* Load the guard value only through an atomic acquire load. */ + guard = build_atomic_load (guard, MEMMODEL_ACQUIRE); + /* Check to see if the GUARD is zero. */ guard = get_guard_bits

Re: [RFC / CFT] PR c++/66192 - Remove TARGET_RELAXED_ORDERING and use load acquires.

On 22/05/15 15:28, Jason Merrill wrote: On 05/22/2015 09:55 AM, David Edelsohn wrote: On Fri, May 22, 2015 at 9:40 AM, Jason Merrill wrote: On 05/22/2015 07:23 AM, Ramana Radhakrishnan wrote: + /* Load the guard value only through an atomic acquire load. */ + guard = build_atomic_load

Re: [PATCH, ARM] attribute target (thumb,arm) [2.2/6] respin (5th)

On 13/05/15 11:16, Christian Bruel wrote: > - [2.2/6]: Redefine TARGET_MACROS for #pragma GCC target without "thumbness" the glue. Here it is, no regression for arm-sim/ arm-sim//-march=armv7-a arm-sim//-mthumb arm-sim//-mthumb/-march=armv7-a Obviously, [4/6],[5/6] an

Re: Copy TYPE_NO_FORCE_BLK in finalize_type_size

On 26/05/15 09:58, Richard Biener wrote: On Fri, May 22, 2015 at 5:44 PM, Jan Hubicka wrote: Hi, PR 66181 is about ICE in verify_type that complains that type and its variant differs by TYPE_NO_FORCE_BLK. This flag is kind-of internal to stor-layout.c, so the divergence may not matter (I a

Re: [PATCH, ARM] attribute target (thumb,arm) [2.2/6] respin (5th)

On Tue, May 26, 2015 at 2:42 PM, Christian Bruel wrote: > > > On 05/26/2015 12:11 PM, Ramana Radhakrishnan wrote: >> >> >> >> On 13/05/15 11:16, Christian Bruel wrote: >>> >>> >>> > - [2.2/6]: Redefine TARGET_MACROS for #pragma

Re: [PATCH, ARM] attribute target (thumb,arm) [2.1/6] respin (5th)

On Wed, May 13, 2015 at 9:49 AM, Christian Bruel wrote: > 2 parts for maintainers > > - c-family: machine descriptions export macro definitions into c > implementation : need to export 'builtin_define_with_int_value' and ' > builtin_define_type_sizeof' > >Could a global reviewer check this ?

Re: [RFC / CFT] PR c++/66192 - Remove TARGET_RELAXED_ORDERING and use load acquires.

On 22/05/15 18:36, Jason Merrill wrote: On 05/22/2015 11:23 AM, Ramana Radhakrishnan wrote: On 22/05/15 15:28, Jason Merrill wrote: I do notice that get_guard_bits after build_atomic_load just won't work on non-ARM targets, as it ends up trying to take the address of a value. So on po

Re: [RFC][PATCH][X86_64] Eliminate PLT stubs for specified external functions via -fno-plt=

Why isn't it just an indirect call in the cases that would require a GOT slot and a direct call otherwise ? I'm trying to work out what's so different on each target that mandates this to be in the target backend. Also it would be better to push the tests into gcc.dg if you can and check for the

Re: [PATCH] [PATCH][ARM] Fix thumb-ltu.c testcase.

On 01/06/15 10:48, Alex Velenko wrote: Hi, This patch fix thumb-ltu.c to pass excess error test. Without default -std=gnu90 flag, this testcase started failing as some functions were called before being predefined. Is patch ok? gcc/testsuite 2015-06-01 Alex Velenko * gcc.target

Re: [PATCH, ARM] attribute target (thumb,arm) [3/6] respin (4th)

2015-05-11 9:49 GMT+01:00 Christian Bruel : > -BEGIN PGP MESSAGE- > Version: GnuPG v1.4.11 (GNU/Linux) > > hQIOA7kay12Fw5I3EAf/dJLl6z88mNVga3f+gsF8SKunpHWh+OsNTdg0zovUsPH/ > YX1l86qL92we5htdf86j8rKTOH9PdOQCITsAnwKecWgpas5cGV4s2LHcbX/wQyl4 > UGnVaQhDrGZputPDjJkaysrX+aI/Tv0JWBm7XZE5pyTRN6ngm/

Re: [PATCH, ARM] attribute target (thumb,arm) [3/6] respin (4th)

://gcc.gnu.org/ml/gcc-patches/2015-05/msg01539.html > (5.2/6) https://gcc.gnu.org/ml/gcc-patches/2015-05/msg01558.html > (6 /6) https://gcc.gnu.org/ml/gcc-patches/2015-05/msg01542.html > > Cheers > > Christian > > > > On 06/01/2015 11:53 AM, Ramana Radhakrishnan wrote: &

Re: [RFC][PATCH][X86_64] Eliminate PLT stubs for specified external functions via -fno-plt=

On Mon, Jun 1, 2015 at 7:01 PM, Sriraman Tallam wrote: > On Mon, Jun 1, 2015 at 1:24 AM, Ramana Radhakrishnan > wrote: >> >>>> Why isn't it just an indirect call in the cases that would require a GOT >>>> slot and a direct call otherwise ? I'm tryin

Re: [RFC][PATCH][X86_64] Eliminate PLT stubs for specified external functions via -fno-plt=

On Mon, Jun 1, 2015 at 7:55 PM, Sriraman Tallam wrote: > On Mon, Jun 1, 2015 at 11:41 AM, Ramana Radhakrishnan > wrote: >> On Mon, Jun 1, 2015 at 7:01 PM, Sriraman Tallam wrote: >>> On Mon, Jun 1, 2015 at 1:24 AM, Ramana Radhakrishnan >>> wrote: >>>>

Re: [RFC][PATCH][X86_64] Eliminate PLT stubs for specified external functions via -fno-plt=

On Tue, Jun 2, 2015 at 7:15 PM, Sriraman Tallam wrote: > On Mon, Jun 1, 2015 at 1:33 PM, Ramana Radhakrishnan > wrote: >> On Mon, Jun 1, 2015 at 7:55 PM, Sriraman Tallam wrote: >>> On Mon, Jun 1, 2015 at 11:41 AM, Ramana Radhakrishnan >>> wrote: >>>>

Re: [GCC, ARM] armv8 linux toolchain asan testcase fail due to stl missing conditional code

On 03/06/15 05:12, Shiva Chen wrote: It seems that stl should generate as stlne. Otherwise, slt will get null reference when r3 is 0. To fix the issue, add %? when output stl assembly pattern in sync.md. Please also mark these patterns as predicable. i.e. (set_attr "predicable" "yes"

Re: [RFC][PATCH][X86_64] Eliminate PLT stubs for specified external functions via -fno-plt=

Hi Sriraman, Thanks for the detailed explanation, that was useful. I'm sorry I'm going to push back again for the same reason. Let me describe the problem I am having in a little more detail: For the PIC case, I think there is no confusion. Both of us agree on what is being done. Attribute

Re: [RFC / CFT] PR c++/66192 - Remove TARGET_RELAXED_ORDERING and use load acquires.

On 29/05/15 20:40, Jason Merrill wrote: On 05/29/2015 09:18 AM, Ramana Radhakrishnan wrote: +static tree +build_atomic_load_byte (tree src, HOST_WIDE_INT model) This function needs a comment. The C++ changes are OK with that. Jason I'm assuming your review and rth's review

Re: [PATCH] [PATCH][ARM] Fix thumb-ltu.c testcase.

Committed with said change r223982. Is patch ok for fsf-5 backport? Alex OK if no regressions. Ramana

Re: [PATCH, ARM] attribute target (thumb,arm) [4/6] respin (5th)

On 08/06/15 09:45, Christian Bruel wrote: Hi Ramana, Ok, I see. The patch looks ok to me modulo the typo nits I pointed out, but I think Ramana should have the final say here as he's already started reviewing it and it adds quite a lot of functionality. Thanks, Kyrill do you have other f

Re: [PATCH PR65767]Fix test case failure on arm-none-eabi

On Mon, Apr 20, 2015 at 7:50 AM, Bin Cheng wrote: > Hi, > As comments at PR65767 and PR65718, we should use namespace other than std > to avoid duplicated definition problem on arm-none-eabi. This patch fixes > the issue. It is an obvious change, but I will wait for approval because of > GCC5 br

Re: [PATCH] [1/2] [ARM] [libgcc] Support RTABI half-precision conversion functions.

On Mon, Apr 13, 2015 at 12:25 PM, Joseph Myers wrote: > On Mon, 13 Apr 2015, Hale Wang wrote: > >> Yes, you are right. It's my fault to add the "only" here. Thank you to point >> out this. >> Beside this, is this patch OK for you? > > I don't think it's a good idea for libgcc to include large piec

Re: [PATCH] [1/2] [ARM] [libgcc] Support RTABI half-precision conversion functions.

On Wed, Apr 22, 2015 at 9:32 AM, Hale Wang wrote: >> -Original Message- >> From: Ramana Radhakrishnan [mailto:ramana@googlemail.com] >> Sent: Wednesday, April 22, 2015 3:50 PM >> To: Joseph Myers >> Cc: Hale Wang; GCC Patches >> Subject: Re: [PATCH

Re: [PATCH] PR target/65846: Optimize data access in PIE with copy reloc

On Wed, Apr 22, 2015 at 5:34 PM, H.J. Lu wrote: > Normally, with PIE, GCC accesses globals that are extern to the module > using GOT. This is two instructions, one to get the address of the global > from GOT and the other to get the value. Examples: > > --- > extern int a_glob; > int > main () >

Re: [PATCH] Fix for PR26702: Emit .size for BSS variables on arm-eabi

On Mon, Mar 30, 2015 at 9:25 PM, Kwok Cheung Yeung wrote: > This is a simple patch that ensures that a .size directive is emitted when > space is allocated for a static variable in the BSS on bare-metal ARM > targets. This allows other tools such as GDB to look up the size of the > object correct

Re: [PATCH][ARM] Rewrite vc NEON patterns to use RTL operations rather than UNSPECs

On Wed, Feb 4, 2015 at 12:12 PM, Kyrill Tkachov wrote: > Hi all, > > This patch improves the vc patterns in neon.md to use proper RTL > operations rather than UNSPECS. > It is done in a similar way to the analogous aarch64 operations i.e. vceq is > expressed as > (neg (eq (...) (...))) > since we

Re: [PATCH] Improve targetm.binds_local_p for common symbols on s390*/arm/aarch64 (PR target/65780)

On 23/04/15 17:36, Jakub Jelinek wrote: Hi! This patch undoes the PR65780 performance regressions on a few targets I have tested to work fine. This PR was about an access to uninitialized COMMON symbol defined in executable (or PIE) where there is a normal symbol definition in a shared library

Re: [PING 2][PATCH] libgcc: Add CFI directives to the soft floating point support code for ARM

On Tue, Apr 28, 2015 at 4:19 PM, Martin Galvan wrote: > This patch adds CFI directives to the soft floating point support code for > ARM. > > Previously, if we tried to do a backtrace from that code in a debug session > we'd > get something like this: > > (gdb) bt > #0 __nedf2 () at > ../../..

Re: [PATCH,PING][ARM]Remove vec_shr and vec_shr optabs

On Tue, Apr 28, 2015 at 4:15 PM, Alan Lawrence wrote: >> No new code here ;). There is a slight change of execution path, i.e. some >> VEC_PERM_EXPRs (e.g. those for reductions via shifts) will be expanded >> using >> arm_expand_vec_perm_const rather than the vec_shr pattern. This generates >> EXT

Re: ping: [PATCH, ARM] attribute target (thumb,arm) [0-6]

On Mon, Apr 20, 2015 at 9:35 AM, Christian Bruel wrote: > Hello Ramana > >>> >> >> Can you respin this now that we are in stage1 again ? >> >> Ramana >> > > Attached the rebased, rechecked set of patches. Original with comments > posted in > > https://gcc.gnu.org/ml/gcc-patches/2014-11/msg02455.ht

Re: ping: [PATCH, ARM] attribute target (thumb,arm) [0-6]

Christian A general note, please reply to each of the patches with a rebased patch as a separate email. Further more all your patches appear to have dos line endings so they don't seem to apply cleanly. Please don't have spurious headers in your patch submission - it then makes it hard to , p

Re: ping**n re [patch, ARM] Add support for crtfastmath.o

On Tue, May 5, 2015 at 6:53 PM, Sandra Loosemore wrote: > This patch I posted last fall: > > https://gcc.gnu.org/ml/gcc-patches/2014-11/msg00711.html > > still has not been reviewed, in spite of me pinging it several times before > GCC 5 went into stage 4. Now that we're back in stage 1 again, ca

Re: [patch, arm] align saved FP regs on stack

On Sat, Nov 15, 2014 at 12:46 AM, Sandra Loosemore wrote: > On ARM targets, the stack is aligned to an 8-byte boundary, but when > saving/restoring the VFP coprocessor registers in the function > prologue/epilogue, it is possible for the 8-byte values to end up at > locations that are 4-byte align

Re: [PATCH, ARM, PR64208] LRA ICE Fix

On Thu, Apr 30, 2015 at 6:49 PM, Yvan Roux wrote: > Hi, > > On 23 March 2015 at 18:47, Yvan Roux wrote: >> Hi, >> >> On 23 March 2015 at 17:08, Ramana Radhakrishnan >> wrote: >>> On Wed, Mar 18, 2015 at 10:19 AM, Yvan Roux wrote: >>>> H

Re: [PATCH, ARM] attribute target (thumb,arm) [1/6] respin (4th)

2014-09-23 Christian Bruel * config/arm/arm.h (arm_option_override): Reoganized and split. Reorganized and split into (arm_option_params_internal); New function. s/;/: " New function." (arm_option_check_internal): New function. (arm_option_overr

Re: [PATCH, ARM] attribute target (thumb,arm) [2/6] respin (4th)

On 06/05/15 15:20, Christian Bruel wrote: In preparation of the pragma target reorganize ÂTARGET_CPU_CPP_BUILTINSÂ to redefine mode dependent macros based on current thumb_p. I'm not entirely happy with this patch as it appears to be too tied to just the "thumbness" of the attributes. Addit

Re: [PATCH, ARM] attribute target (thumb,arm) [3/6] respin (4th)

On 06/05/15 15:22, Christian Bruel wrote: Re-implement ARM_DECLARE_FUNCTION_NAME as a function. That will make changed related to unified/divided and mode directives easier to insert. Patch could be smaller as below. Thanks Christian 2014-09-23 Christian Bruel * config/arm/ar

Re: [PATCH, ARM] attribute target (thumb,arm) [4/6] respin (4th)

I'm still playing with the code, so this is a partial review. We should prevent inlining of ARM state functions into functions we know will be T16 if !TARGET_SOFT_FLOAT on the grounds that the architecture doesn't have floating point instruction encodings in the T16 ISA (Thumb1). We'll just c

Re: [PATCH, ARM] attribute target (thumb,arm) [5/6] respin (4th)

On 06/05/15 15:27, Christian Bruel wrote: Implements the hooks for #pragma GCC target A test included to check that macros were correctly defined/undefined on pragma regions. Thanks Christian Missing the hooks - this only appears to have the test. Ramana

Re: Fwd: [PING 2][PATCH] libgcc: Add CFI directives to the soft floating point support code for ARM

n Tue, Apr 28, 2015 at 2:07 PM, Martin Galvan wrote: Thanks a lot. I don't have write access to the repository, could you commit this for me? On Tue, Apr 28, 2015 at 1:21 PM, Ramana Radhakrishnan wrote: On Tue, Apr 28, 2015 at 4:19 PM, Martin Galvan wrote: This patch adds CFI directives to

Re: [PATCH, ARM] Fix testcase for PR64616

On Mon, May 11, 2015 at 10:43 AM, Thomas Preud'homme wrote: > Hi, > > Testcase made for PR64616 was only passing when using a litteral pool. Rather > than having an alternative for systems where this is not true, this patch > changes the test to check that a global copy propagation occurs in cpr

Re: [PATCH, ARM] attribute target (thumb,arm) [1/6] respin (4th)

On Mon, May 11, 2015 at 10:13 AM, Christian Bruel wrote: >> >> >> OK with those changes. >> >> >> >> Ramana >> > > thanks, done > > following up the thumb_code cleanup, here is a missing chunk for the vxworks > config. > > arm-vxworks build checked. ok for trunk ? > > thanks, > > Christian OK th

Re: Fwd: [PING 2][PATCH] libgcc: Add CFI directives to the soft floating point support code for ARM

On 11/05/15 20:44, Martin Galvan wrote: On Mon, May 11, 2015 at 4:45 AM, Ramana Radhakrishnan wrote: sorry about the slow response, I was travelling for a bit and missed your emails. Trying your patch out gives me failures possibly because my mail client munged it when it received this

<    1   2   3   4   5   6   7   8   9   10   >