Re: [PATCH] Fix a C++ crash with may_alias type attribute

On 04/05/17 00:33, Ville Voutilainen wrote: > On 5 April 2017 at 00:29, Bernd Edlinger wrote: >>> The new test doesn't really belong in the libstdc++, does it? >>> >>> If this is a bug in the front-end then a reduced version of the test >>> belongs in the g++ testsuite.

port contrib/download_prerequisites script to macOS

All, The attached patch modifies the contrib/download_prerequisites script to work on macOS.  The revised script detects the operating system and adjusts the shasum and md5 commands  to their expected name and arguments on macOS.  The revised script also uses curl if  wget is not present.  

Re: [PATCH] Fix a C++ crash with may_alias type attribute

On 5 April 2017 at 00:29, Bernd Edlinger wrote: >> The new test doesn't really belong in the libstdc++, does it? >> >> If this is a bug in the front-end then a reduced version of the test >> belongs in the g++ testsuite. >> > > Yes, I moved the test case to the

[PATCH] PR target/79890: S/390: Fix crash.

The attached patch fixes PR 79890. Bootstrapped and regression tested on s390x biarch and s390. Ciao Dominik ^_^ ^_^ -- Dominik Vogt IBM Germany gcc/ChangeLog-pr79890 PR target/79890 * config/s390/s390.c (s390_register_info_gprtofpr): Return if call_eh_return is

Re: [PATCH] Fix a C++ crash with may_alias type attribute

On 04/04/17 14:58, Jonathan Wakely wrote: > On 04/04/17 12:39 +, Bernd Edlinger wrote: >> Hi, >> >> I noticed that the already created reference and pointer types >> are left in an inconsistent state if the may_alias attribute >> is added to a class, in some cases. >> >> The attached patch

Re: [PR 79905] ICE with vector_type

> On Apr 4, 2017, at 1:02 PM, Nathan Sidwell wrote: > > On 04/04/2017 01:40 PM, Bill Schmidt wrote: >> At first blush, the POC patch breaks every test that uses -flto. I'll see >> if I can dig deeper after a bit, >> in case this doesn't make the problem obvious. > > Try this.

Re: Fix MIPS builds with current trunk

On 04/04/2017 01:15 PM, Matthew Fortune wrote: Jeff Law writes: All the MIPS compilers will fail to build using the trunk due to a couple minor uninitialized memory issues. First in mips_multi_add we add an uninitialized mips_multi_member object to the mips_multi_members vec.

Re: [PATCH] Avoid weird -Wpsabi warnings from NRV (PR target/80310)

On April 4, 2017 9:29:19 PM GMT+02:00, Jakub Jelinek wrote: >Hi! > >When I've implemented vector -fsanitize=signed-integer-overflow, >we've started to emit weirdo warnings on e.g. the following testcase. > >There is really no call with return value that changes ABI >based on ISA

[PATCH] PR libstdc++/80316 make promise::set_value throw no_state error

We got a bug report from a customer pointing out that calling promise::set_value on a moved-from promise crashes instead of throwing an exception with error code future_errc::no_state. This fixes it, by moving the _S_check calls to *before* we deference the pointer that the calls check! This

libgo patch committed: make time test more robust

This patch to libgo backports a change from Go tip to make the time test ParseInLocation more robust. This lets the test pass on systems that have updated their timezone database to 2017a or later. This fixes GCC PR 80302. Bootstrapped and ran Go time test on x86_64-pc-linux-gnu. Committed to

[PATCH] Avoid weird -Wpsabi warnings from NRV (PR target/80310)

Hi! When I've implemented vector -fsanitize=signed-integer-overflow, we've started to emit weirdo warnings on e.g. the following testcase. There is really no call with return value that changes ABI based on ISA options, there is just an internal fn call that is expanded completely inline

[PATCH] Don't error about x86 return value in SSE reg (or x86 reg) or argument in SSE reg too early (PR target/80298)

Hi! aggregate_value_p is called often very early during compilation, e.g. from allocate_function or during gimplification of a call with lhs. The problem with that is e.g. that on x86_64 -m64 -mno-sse we can't include , because the always_inline inline functions in mmx and 3dnow intrinsic headers

[committed] FIx a tree sharing issue in generic-match.c (PR c++/80297)

Hi! While generic tree sharing is usually harmless, because we unshare everything before gimplification, on the following testcase a match.pd pattern that uses @1 twice introduces tree sharing during the C gimplification langhook, so after everything has been unshared. The following patch fixes

RE: Fix MIPS builds with current trunk

Jeff Law writes: > All the MIPS compilers will fail to build using the trunk due to a > couple minor uninitialized memory issues. > > First in mips_multi_add we add an uninitialized mips_multi_member object > to the mips_multi_members vec. It's easy enough to just memset the

Re: New prerequisites to support multi image COARRAY in gfortran

On 04/04/2017 10:44 AM, FX wrote: >> We choose mpich as a default only because it is very stable. > > Why are why tying ourselves to one MPI implementation? > > FX > Not tying ourselves at all. This just gives users who install gcc manually with the ./configure process a default to use and

Re: New prerequisites to support multi image COARRAY in gfortran

  On April 4, 2017 at 9:48:23 AM, Jerry DeLisle (jvdeli...@charter.net(mailto:jvdeli...@charter.net)) wrote: > Gerald, (or who does this) > > Since shared memory parallel programming with Fortran is now a Standard > feature > of the language, we would like to support full parallelism

Re: New prerequisites to support multi image COARRAY in gfortran

  Resending as plain text (although now I realize my reply is at least partially redundant since reading Andre’s email): On April 4, 2017 at 10:44:09 AM, FX (fxcoud...@gmail.com(mailto:fxcoud...@gmail.com)) wrote: > > We choose mpich as a default only because it is very stable. > > Why are

Re: [PR 79905] ICE with vector_type

On 04/04/2017 01:40 PM, Bill Schmidt wrote: At first blush, the POC patch breaks every test that uses -flto. I'll see if I can dig deeper after a bit, in case this doesn't make the problem obvious. Try this. nathan -- Nathan Sidwell Index: c-family/c-common.c

Re: New prerequisites to support multi image COARRAY in gfortran

Hi FX, we don't really do. You can use other MPI implementation as well, albeit not all features are implemented in all the others. For failed images support we needed the fault tolerance support for MPI, which I see only in mpich from 3.2 on. The other MPI implementations publicy available do

Re: New prerequisites to support multi image COARRAY in gfortran

> We choose mpich as a default only because it is very stable. Why are why tying ourselves to one MPI implementation? FX

Re: [RFC]: Fix Ada boostrap failure on S/390 with -mzarch

> This worked as well. I've committed the following patch: > > gcc/ada/ChangeLog: > > 2017-04-04 Andreas Krebbel > > * system-linux-s390.ads: Use Long_Integer'Size to define > Memory_Size. Thanks! -- Eric Botcazou

Re: [PR 79905] ICE with vector_type

At first blush, the POC patch breaks every test that uses -flto. I'll see if I can dig deeper after a bit, in case this doesn't make the problem obvious. Thanks, Bill > On Apr 4, 2017, at 9:02 AM, Nathan Sidwell wrote: > > On 04/04/2017 09:57 AM, Bill Schmidt wrote: >> I'll

Re: [PATCH] On x86 allow if-conversion of more than one insn as long as there is at most one cmov (PR tree-optimization/79390)

On 04/01/2017 06:20 AM, Jakub Jelinek wrote: Hi! As discussed in the PR, in the following testcase we don't if-convert with the generic (and many other) tuning, because we default to --param max-rtl-if-conversion-insns=1 in most of the tunings. The problem we have is with multiple cmov

Re: [PATCH, GCC/ARM, gcc-6-branch, ping2] Fix PR80082: LDRD erronously used for 64bit load on ARMv7-R

Ping? Best regards, Thomas On 30/03/17 11:46, Thomas Preudhomme wrote: Ping? Best regards, Thomas On 27/03/17 12:15, Thomas Preudhomme wrote: Hi, Currently GCC is happy to use LDRD to perform a 64bit load on ARMv7-R, as shown by the testcase on this patch. However, LDRD is only atomic

Re: [PATCH, GCC/testsuite/ARM, stage4, ping] Compile atomic_loaddi_11 for Cortex-R5

Hi, gcc.target/arm/atomic_loaddi_11.c testcase contributed in r246365 does not test the changed code since ARMv7-R does not have division instructions in ARM state. This patch changes it to target Cortex-R5 processor instead which does have division instructions in ARM state. ChangeLog entry is

New prerequisites to support multi image COARRAY in gfortran

Gerald, (or who does this) Since shared memory parallel programming with Fortran is now a Standard feature of the language, we would like to support full parallelism through the use of mpich and OpenCorrays. We choose mpich as a default only because it is very stable. We choose OpenCoarrays

Re: [PATCH, GCC/ARM, stage4] Fix small multiply feature

On 04/04/17 11:30, Thomas Preudhomme wrote: > Small multiply variants of ARM Cortex-M0, Cortex-M0+ and Cortex-M1 were > relying on the old cost model to work when optimizing for speed. These > stopped being used in r241965 which led to these cores starting to use > mul instructions instead of

Re: Fix for PR79987

On 04/04/2017 09:07 AM, Alexander Ivchenko wrote: Hi, When creating static bounds for foo below we end up with: *((unsigned long *) &__chkp_bounds_of_foo + 8) = ~(__builtin_ia32_sizeof (foo) + ((long unsigned int) + 18446744073709551615)); This fails in gimplify_function_tree with gcc_assert

Fix MIPS builds with current trunk

All the MIPS compilers will fail to build using the trunk due to a couple minor uninitialized memory issues. First in mips_multi_add we add an uninitialized mips_multi_member object to the mips_multi_members vec. It's easy enough to just memset the new member. Second in

Re: [PATCH] Fix typos in comments throughout source tree

On Apr 4, 2017, at 4:19 AM, Jonathan Wakely wrote: > Here's one more that somebody reported to the unofficial github > mirror: https://github.com/gcc-mirror/gcc/pull/6/files > > Committed to trunk. Thanks.

Re: [BUILDROBOT] Maybe uninitialized warnings in mips targets

On 03/18/2017 12:20 PM, Jan-Benedict Glaw wrote: Hi Richard, Catherine, Matthew On Thu, 2017-03-02 14:40:46 +0100, Richard Biener wrote: [...] On IRC we decided to wait for the TREE_NO_WARNING issue. So the following is what I committed. Bootstrapped / tested on

Re: [PATCH] Bump the default thread stack size on Darwin in libgomp (PR libgomp/79876)

On Apr 4, 2017, at 2:20 AM, Dominique d'Humières wrote: >> Dominique has already tested it on Darwin 16 and said he'll test on Darwin >> 10; I'm waiting for those results. >> >> Jakub > > No problem with darwin10. I'm fine with the patch.

Re: [PATCH, rs6000] Document location of ELF V2 ABI specification

> On Apr 1, 2017, at 12:15 PM, Gerald Pfeifer wrote: > > On Fri, 31 Mar 2017, Bill Schmidt wrote: >> OK, I've committed this as r246617. Gerald, please let me know >> if you'd like any changes to the text. > > This looks fine to me. > > Just "These are described briefly

Re: [PATCH] Fix MMX/SSE/AVX* shifts by non-immediate scalar (PR target/80286)

On Tue, Apr 04, 2017 at 02:33:24PM +0200, Uros Bizjak wrote: > > I assume split those before reload. Because we want to give reload a chance > > to do the zero extension on GPRs if it is more beneficial, and it might > > choose to store it into memory and load into XMM from memory and that is > >

Fix for PR79987

Hi, When creating static bounds for foo below we end up with: *((unsigned long *) &__chkp_bounds_of_foo + 8) = ~(__builtin_ia32_sizeof (foo) + ((long unsigned int) + 18446744073709551615)); This fails in gimplify_function_tree with gcc_assert (!VOID_TYPE_P (TREE_TYPE (*expr_p))); Is it OK?

Re: libbacktrace PATCH: improve comment for backtrace_create_state

On 2017-04-04 16:04, Ian Lance Taylor wrote: On Tue, Apr 4, 2017 at 6:50 AM, wrote: On 2017-04-04 15:38, Ian Lance Taylor wrote: How about we just add backtrace_destroy_state? I don't know how to code that. In my https://github.com/bstarynk/melt-monitor I

Re: libbacktrace PATCH: improve comment for backtrace_create_state

On Tue, Apr 4, 2017 at 6:50 AM, wrote: > On 2017-04-04 15:38, Ian Lance Taylor wrote: > >> How about we just add backtrace_destroy_state? > > I don't know how to code that. In my > https://github.com/bstarynk/melt-monitor I observed that calling free on > such > a

Re: [PR 79905] ICE with vector_type

On 04/04/2017 09:57 AM, Bill Schmidt wrote: I'll try the POC patch in a bit (kind of ugly as we have to replicate this for a whole bunch of types, I guess). thanks. Yup, all rs6000's builtins. Wrapping it all in a tree my_builtin_vector (char const *name, tree elt, unsigned num); helper

Re: [PR 79905] ICE with vector_type

I'll try the POC patch in a bit (kind of ugly as we have to replicate this for a whole bunch of types, I guess). Just FYI, I noticed this similar bug report came in today, not sure about the types: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80309 -- Bill Bill Schmidt, Ph.D. GCC for Linux

Re: libbacktrace PATCH: improve comment for backtrace_create_state

On 2017-04-04 15:38, Ian Lance Taylor wrote: On Tue, Apr 4, 2017 at 5:05 AM, wrote: I just discovered that backtrace_create_state should be called once, that it is returning some heap-allocated data (which cannot be free-d, because there is no

Re: [PR 79905] ICE with vector_type

On 04/04/2017 09:00 AM, Richard Biener wrote: tree add_builtin_type (const char *name, tree type) { tree id = get_identifier (name); tree decl = build_decl (BUILTINS_LOCATION, TYPE_DECL, id, type); return lang_hooks.decls.pushdecl (decl); } this seems to miss setting TYPE_NAME (type) =

Re: libbacktrace PATCH: improve comment for backtrace_create_state

On Tue, Apr 4, 2017 at 5:05 AM, wrote: > > I just discovered that backtrace_create_state should be called once, that it > is returning some heap-allocated data (which cannot be free-d, because there > is no > backtrace_destroy_state routine). > > I suggest the attached

Re: [PR 79905] ICE with vector_type

On Tue, Apr 4, 2017 at 1:31 PM, Nathan Sidwell wrote: > On 04/04/2017 04:27 AM, Richard Biener wrote: >> >> On Mon, Apr 3, 2017 at 9:03 PM, Nathan Sidwell wrote: > > >>> However, as you can see there's already a get-out for COMPLEX_TYPE, and I >>> think the same

Re: [PATCH] Fix a C++ crash with may_alias type attribute

On 04/04/17 12:39 +, Bernd Edlinger wrote: Hi, I noticed that the already created reference and pointer types are left in an inconsistent state if the may_alias attribute is added to a class, in some cases. The attached patch fixes this by adding another loop over all type variants of each

[PATCH] Fix a C++ crash with may_alias type attribute

Hi, I noticed that the already created reference and pointer types are left in an inconsistent state if the may_alias attribute is added to a class, in some cases. The attached patch fixes this by adding another loop over all type variants of each pointer and reference type. The new test case

Re: [PATCH] Fix MMX/SSE/AVX* shifts by non-immediate scalar (PR target/80286)

On Tue, Apr 4, 2017 at 2:00 PM, Jakub Jelinek wrote: > On Tue, Apr 04, 2017 at 08:39:59AM +0200, Uros Bizjak wrote: >> > Any thoughts on what to do to generate reasonable code when the shift count >> > comes from memory (e.g. as int variable) or is in the low bits of some XMM >>

Re: [DOC PATCH] PowerPC extended asm example

Revised patch. * doc/extend.texi (Extended Asm ): Rename to "Clobbers and Scratch Registers". Add OpenBLAS example. diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi index 0f44ece..0b0a021 100644 --- a/gcc/doc/extend.texi +++ b/gcc/doc/extend.texi @@ -7869,7 +7869,7 @@ A

libbacktrace PATCH: improve comment for backtrace_create_state

Hello All, I just discovered that backtrace_create_state should be called once, that it is returning some heap-allocated data (which cannot be free-d, because there is no backtrace_destroy_state routine). I suggest the attached patch (against GCC trunk r246678) which just improves the

Re: [PATCH] Fix MMX/SSE/AVX* shifts by non-immediate scalar (PR target/80286)

On Tue, Apr 04, 2017 at 08:39:59AM +0200, Uros Bizjak wrote: > > Any thoughts on what to do to generate reasonable code when the shift count > > comes from memory (e.g. as int variable) or is in the low bits of some XMM > > regioster? > > The problem with int variable from memory is, that shifts

Re: [RFC]: Fix Ada boostrap failure on S/390 with -mzarch

On 04/03/2017 06:18 PM, Eric Botcazou wrote: >> On S/390 UNITS_PER_WORD is: >> 8 with -m64 >> 4 with -m31 >> 8 with -m31 -mzarch >> >> This has been chosen to support use of 64 bit registers also in 32 bit >> code. Code compiled with -m31 -mzarch is supposed to adhere to the 32 >> bit ABI. In

Re: [PR 79905] ICE with vector_type

On 04/04/2017 04:27 AM, Richard Biener wrote: On Mon, Apr 3, 2017 at 9:03 PM, Nathan Sidwell wrote: However, as you can see there's already a get-out for COMPLEX_TYPE, and I think the same is needed for VECTOR_TYPE. Hmm, but that is essentially a hack given that

Re: [PATCH] Fix typos in comments throughout source tree

On 03/04/17 23:31 +0100, Jonathan Wakely wrote: On 03/04/17 20:06 +0100, Jonathan Wakely wrote: On 03/04/17 11:48 -0700, Mike Stump wrote: [ dup, I sent the wrong from the wrong email address, you might not see it because of that ] On Apr 3, 2017, at 11:47 AM, Mike Stump

Re: [PATCH] ARM: Introduce ARM_DEFAULT_SHORT_ENUMS

On 04/04/17 12:50, Sebastian Huber wrote: On 04/04/17 12:41, Ramana Radhakrishnan wrote: [dropping devel at rtems dot org as I don't want more bounces] On Tue, Apr 4, 2017 at 10:07 AM, Sebastian Huber wrote: >On 04/04/17 11:00, Ramana Radhakrishnan

Re: [PATCH] ARM: Introduce ARM_DEFAULT_SHORT_ENUMS

On 04/04/17 12:41, Ramana Radhakrishnan wrote: [dropping devel at rtems dot org as I don't want more bounces] On Tue, Apr 4, 2017 at 10:07 AM, Sebastian Huber wrote: >On 04/04/17 11:00, Ramana Radhakrishnan wrote: >>> >>> > static bool >>> >

Re: [PATCH] ARM: Introduce ARM_DEFAULT_SHORT_ENUMS

[dropping devel at rtems dot org as I don't want more bounces] On Tue, Apr 4, 2017 at 10:07 AM, Sebastian Huber wrote: > On 04/04/17 11:00, Ramana Radhakrishnan wrote: >>> >>> > static bool >>> > arm_default_short_enums (void) >>> > { >>> >- return

[PATCH v2] ARM: Introduce ARM_DEFAULT_SHORT_ENUMS

Allow targets to define the default for the short enums option. v2: Move ARM_DEFAULT_SHORT_ENUMS to arm.h. gcc/ * config/arm/arm.h: (ARM_DEFAULT_SHORT_ENUMS): Provide default definition. * config/arm/arm.c: (arm_default_short_enums): Use ARM_DEFAULT_SHORT_ENUMS.

[PATCH, GCC/ARM, stage4] Fix small multiply feature

Small multiply variants of ARM Cortex-M0, Cortex-M0+ and Cortex-M1 were relying on the old cost model to work when optimizing for speed. These stopped being used in r241965 which led to these cores starting to use mul instructions instead of synthetizing the multiplications. This was not caught

[PATCH 3/3] [ARC] Use long jumps for CRT calls

There are situations when the range offered by the bl instruction is not sufficient to reach CRT routines. Thus, use a long jump construction. gcc/ 2016-04-21 Claudiu Zissulescu * config/arc/arc.h (CRT_CALL_STATIC_FUNCTION): Use long calls. ---

[PATCH 1/3] [ARC] Update mode_dependent_address_p hook.

Update arc_mode_dependent_address_p to avoid emitting subreg(mem (reg ..)) when expanding. gcc/ 2016-10-11 Claudiu Zissulescu * config/arc/arc.c (arc_mode_dependent_address_p): Relax conditions to take advantage of various optimizations. ---

[PATCH 2/3] [ARC] DWARF emitting cleanup.

The use of CFA_FRAME_BASE_OFFSET and ARG_POINTER_CFA_OFFSET macros leads to wrong offset calculation for DW_OP_fbreg constructions. Remove them. gcc/ 2016-10-17 Claudiu Zissulescu * config/arc/arc-protos.h (arc_decl_pretend_args): Remove. *

[PATCH 0/3] ARC patches series

Hi Andrew, Please find a number of small patches which are adding support to for CRT long calls, and fixes some errors when generating dwarf information and addresses. Please let me know if more info is required, Claudiu Claudiu Zissulescu (3): [ARC] Update mode_dependent_address_p hook.

[C++ PATCH] Fix PR80294 -- Segfault in constexpr.c (reduced_constant_expression_p)

As the testcase shows, elt can become a NULL tree during FOR_EACH_CONSTRUCTOR_VALUE. So guard against this possibility before calling reduced_constant_expression_p() recursively. Tested on ppc64le. OK for trunk? PR c++/80294 * constexpr.c (reduced_constant_expression_p): Guard

Re: [PATCH] Fix profiledbootstrap ada checking failure (PR debug/79255)

> eric@polaris:~/build/gcc/native/gcc> rm ada/sem_util.o > eric@polaris:~/build/gcc/native/gcc> make ADAFLAGS="-gnatpgn" > /home/eric/build/gcc/native/./prev-gcc/xgcc - > B/home/eric/build/gcc/native/./prev-gcc/ > -B/home/eric/install/gcc/x86_64-suse- linux/bin/ >

Re: [PATCH] Bump the default thread stack size on Darwin in libgomp (PR libgomp/79876)

> Le 3 avr. 2017 à 19:00, Jakub Jelinek a écrit : > > On Mon, Apr 03, 2017 at 10:56:13AM -0600, Jeff Law wrote: >> On 04/01/2017 06:24 AM, Jakub Jelinek wrote: >>> Apparently Darwin has insane default stack size for pthread_create >>> unless overridden through

Re: [Patch C++/80296] Fix broken diagnostic: 'unary_plus_expr' not supported by expression

On Mon, Apr 3, 2017 at 10:47 PM, Volker Reichelt wrote: > The following patch fixes a broken diagnostic: > #'unary_plus_expr' not supported by expression# > > The code to handle UNARY_PLUS_EXPR is already in place in > cxx_pretty_printer::unary_expression. However,

Re: [PATCH] Fix profiledbootstrap ada checking failure (PR debug/79255)

> We have local modifications in the Ada front-end so I cannot reproduce it > with the pristine tree either. :-( I apparently screwed up yesterday, this can be reproduced as such in the directory of a boostrapped compiler: eric@polaris:~/build/gcc/native/gcc> rm ada/sem_util.o

Re: [PATCH] ARM: Introduce ARM_DEFAULT_SHORT_ENUMS

On 04/04/17 11:00, Ramana Radhakrishnan wrote: > static bool > arm_default_short_enums (void) > { >- return TARGET_AAPCS_BASED && arm_abi != ARM_ABI_AAPCS_LINUX; >+ return ARM_DEFAULT_SHORT_ENUMS; > } > > >diff --git a/gcc/config/arm/rtems.h b/gcc/config/arm/rtems.h >index 53cd987..b34bbe8

Re: [PATCH] ARM: Introduce ARM_DEFAULT_SHORT_ENUMS

On Mon, Apr 3, 2017 at 12:32 PM, Sebastian Huber wrote: > Allow targets to define the default for the short enums option. > > gcc/ > > * config/arm/arm.c: (ARM_DEFAULT_SHORT_ENUMS): Provide default > definition. > * config/arm/rtems.h

Re: [PATCH] ARM: Introduce ARM_DEFAULT_SHORT_ENUMS

On Tue, Apr 4, 2017 at 8:43 AM, Bernhard Reutner-Fischer wrote: > On 3 April 2017 13:32:30 CEST, Sebastian Huber > wrote: >>Allow targets to define the default for the short enums option. > > Does this work nowadays? > About 10 years

Re: [PR 79905] ICE with vector_type

On Mon, Apr 3, 2017 at 9:03 PM, Nathan Sidwell wrote: > Bill, > can you give this patch a spin please? I've smoke tested it on a ppc64le > x-compiler, but don't have one to run executables. regression testing on an > x86_64-linux system is ok. > > The DEPENDENT_TYPE_VALID_P thing

Re: [PATCH] ARM: Introduce ARM_DEFAULT_SHORT_ENUMS

On 04/04/17 09:43, Bernhard Reutner-Fischer wrote: On 3 April 2017 13:32:30 CEST, Sebastian Huber wrote: Allow targets to define the default for the short enums option. Does this work nowadays? About 10 years ago I did this for some arm and had to force

Re: [PATCH] ARM: Introduce ARM_DEFAULT_SHORT_ENUMS

On 3 April 2017 13:32:30 CEST, Sebastian Huber wrote: >Allow targets to define the default for the short enums option. Does this work nowadays? About 10 years ago I did this for some arm and had to force TREE_CODE at al to 16 bit manually, IIRC.

Re: [PATCH] For broken exception handling in GDB on AIX platform

Hi Jeff, Our AIX team is parallely working on the issue that why EH is not working with static linking on AIX. For time being this patch will be work around for the issue. On Thu, Mar 30, 2017 at 1:07 AM, Jeff Law wrote: > On 03/26/2017 06:05 PM, Joel Brobecker wrote: >> >>

Re: [PATCH] Fix PR80275

On Tue, 4 Apr 2017, Marc Glisse wrote: > On Tue, 4 Apr 2017, Markus Trippelsdorf wrote: > > > On 2017.04.03 at 11:16 +0200, Richard Biener wrote: > > > > > > The following extends split_address_to_core_and_offset to handle > > > POINTER_PLUS_EXPR to be able to simplify > > > (unsigned long)

Re: [PATCH] Fix MMX/SSE/AVX* shifts by non-immediate scalar (PR target/80286)

On Mon, Apr 3, 2017 at 10:34 PM, Jakub Jelinek wrote: > Hi! > > This patch deals just with correctness of vector shifts by scalar > non-immediate. The manuals say the shift count is bits [0:63] of > the corresponding source operand (XMM reg or memory in some cases), > and if

Re: [PATCH] Fix PR80275

On Tue, 4 Apr 2017, Markus Trippelsdorf wrote: On 2017.04.03 at 11:16 +0200, Richard Biener wrote: The following extends split_address_to_core_and_offset to handle POINTER_PLUS_EXPR to be able to simplify (unsigned long) [(void *) + 12B] - (unsigned long) ((const int *) + 4) which appears