[PATCH] [MSP430] Read mcu data from file instead of hardcoded data

GCC for the MSP430 target uses hard-coded data to choose the correct CPU ISA and hardware multiply version for a given MCU. Since the data is hard-coded, this data can only be updated by updating the compiler itself. The following patch changes the mechanism for processing device data to instead

Re: [51/77] Use opt_scalar_int_mode when iterating over integer modes

On 07/13/2017 02:56 AM, Richard Sandiford wrote: > This patch uses opt_scalar_int_mode rather than machine_mode > when iterating over scalar_int_modes, in cases where that helps > with future patches. (Using machine_mode is still OK in places > that don't really care about the mode being a scalar

Re: [PATCH] Allow fpmath differences in inlining when callee doesn't use FP math

On Thu, Aug 24, 2017 at 1:10 PM, Richard Biener wrote: > > This adjusts the x86 backend to allow -mfpmath differences when > deciding whether to allow inlining. -mfpmath doesn't really > matter for functions not containing FP operations. > > It appears that the can_inline_p

Re: RFC: Explicit move preference hints

Segher Boessenkool wrote: > > "0,r" might work, or "0,?r", or similar (alternatives have commas > between them). No, it doesn't work at all. But that is no surprise if you look at ira_get_dup_out_num. It iterates over the constraint string and if you have anything that matches after a "0", the

Re: PR81635: Use chrecs to help find related data refs

On Tue, Aug 22, 2017 at 4:19 PM, Richard Sandiford wrote: > Richard Biener writes: >> On Fri, Aug 18, 2017 at 12:30 PM, Richard Biener >> wrote: >>> On Thu, Aug 17, 2017 at 2:24 PM, Bin.Cheng

[PATCH] [MSP430] [PR78554] Prevent SUBREG from referencing a SYMBOL_REF

As reported in PR78554, attempting to store an __int20 address in memory causes an ICE due to an invalid insn. This only occurs at optimisation levels higher than -O0 because these optimisation levels pass -ftree-ter, which causes the compiler to try and do the store in one instruction. The issue

Re: [PATCH] handle pathological anti-ranges in gimple_fold_builtin_memory_op (PR 81908)

On 08/24/2017 08:03 AM, Richard Biener wrote: On Wed, Aug 23, 2017 at 9:42 PM, Martin Sebor wrote: Bug 81908 is about a -Wstringop-overflow warning for a Fortran test triggered by a recent VRP improvement. A simple test case that approximates the warning is: void f (char

Re: [PATCH][RFC] Make expansion of balanced binary trees of switches on tree level.

On 08/18/2017 12:25 PM, Martin Liška wrote: > On 08/18/2017 11:30 AM, Richard Biener wrote: >> On Tue, Aug 15, 2017 at 2:37 PM, Martin Liška wrote: >>> On 08/14/2017 10:32 AM, Richard Biener wrote: Hmm, but the existing "lowering" part is called from the

Re: [PATCH PR81913]Skip niter analysis if either IV in exit condition can wrap

On Thu, Aug 24, 2017 at 12:58 PM, Bin Cheng wrote: > Hi, > I added code handle exit condition like "IV1 le/lt IV2" by changing it into > "IV1' le/lt INV". > Unfortunately, wrapping behavior has subtle impact on the transformation. > This patch for > now skips niter analysis

Re: [PATCH] handle pathological anti-ranges in gimple_fold_builtin_memory_op (PR 81908)

On Wed, Aug 23, 2017 at 9:42 PM, Martin Sebor wrote: > Bug 81908 is about a -Wstringop-overflow warning for a Fortran > test triggered by a recent VRP improvement. A simple test case > that approximates the warning is: > > void f (char *d, const char *s, size_t n) > { >

Re: [52/77] Use scalar_int_mode in extract/store_bit_field

On 07/13/2017 02:56 AM, Richard Sandiford wrote: > After a certain point, extract_bit_field and store_bit_field > ensure that they're dealing with integer modes or BLKmode MEMs. > This patch uses scalar_int_mode and opt_scalar_int_mode for > those parts. > > 2017-07-13 Richard Sandiford

Re: [PATCH] C: fix logic within c_expr::get_location

On Wed, Aug 23, 2017 at 02:08:47PM -0400, David Malcolm wrote: > In r251239 I added a c_expr::get_location method for use by > c_parser_expr_list for building the vec for > an expression list, rather than using the location of the first token. > > When determining whether to use the location

Re: ping [PATCH] [MSP430] Fix PR78849: ICE on initialization of global struct containing __int20 array

On 22/08/2017 11:57, Jozef Lawrynowicz wrote: On 02/08/2017 17:45, Joseph Myers wrote: On Wed, 2 Aug 2017, Jeff Law wrote: I think Joseph's suggestion for looking at partial float handling may be useful, though ia64's RFmode may be more interesting as it's not a multiple of 8 in bitsize. 

[PATCH] Allow fpmath differences in inlining when callee doesn't use FP math

This adjusts the x86 backend to allow -mfpmath differences when deciding whether to allow inlining. -mfpmath doesn't really matter for functions not containing FP operations. It appears that the can_inline_p target hook is called from the C++ FE for multi-versioning, thus the ! ipa_fn_summaries

Re: [PATCH] istream_iterator: unexpected read in ctor

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81964 On Thu, 24 Aug 2017 11:55:58 +0300 Petr Ovtchenkov wrote: > istream_iterator do unexpected read from stream > when initialized by istream&. > > It is not required from increment operators of istream_iterator > that _M_ok

Re: RFC: Explicit move preference hints

Vladimir Makarov wrote: > > As I correctly understand, you just want an intuitive allocation. The > current allocation performance has the same quality as the intuitive one. Performance is affected as well but I didn't want to go into details as that distracts from the underlying issue. But if

[PATCH] streambuf_iterator: avoid debug-dependent behaviour

Explicit do sgetc from associated streambuf. Avoid debug-dependent sgetc (within _M_at_eof()): __glibcxx_requires_cond(!_M_at_eof(), _M_message(__gnu_debug::__msg_inc_istreambuf) ._M_iterator(*this)); Increment operators not

[Patch] PR c++/80287 backport on GCC 6 branch

Hi, As described in the PR, gcc-6-branch is impacted by this issue. This patch backports the original fix from Bernd and the recently added testcase (which does not rely on c++17 features). https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80287

[PATCH PR81913]Skip niter analysis if either IV in exit condition can wrap

Hi, I added code handle exit condition like "IV1 le/lt IV2" by changing it into "IV1' le/lt INV". Unfortunately, wrapping behavior has subtle impact on the transformation. This patch for now skips niter analysis if either IV1 or IV2 can wrap. We can still handle pointer case as reported in

Re: [PR middle-end/81931] do not pass 0 precision in get_nonzero_bits

On Thu, Aug 24, 2017 at 8:59 AM, Marc Glisse wrote: > On Thu, 24 Aug 2017, Aldy Hernandez wrote: > >> As discussed in the PR... >> >> CCP is passing a precision of 0 to get_nonzero_bits for complex >> numbers. With my last wide_int sign extension patch, the sign >>

[PATCH] copy_n for input iterator, avoid in-loop jumps

Reword loop in copy_n specialization for input iterator. Avoid condition check and jumps within loop. Pay attention that input iterator incremented n - 1 times, while output iterator incremented n times. See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50119 and

[PATCH] istream_iterator: unexpected read in ctor

istream_iterator do unexpected read from stream when initialized by istream&. It is not required from increment operators of istream_iterator that _M_ok will be true as precondition. --- libstdc++-v3/include/bits/stream_iterator.h| 19 +-

Re: [PATCH] Allow fpmath differences in inlining when callee doesn't use FP math

On Thu, Aug 24, 2017 at 1:34 PM, Richard Biener wrote: > On Thu, 24 Aug 2017, Uros Bizjak wrote: > >> On Thu, Aug 24, 2017 at 1:10 PM, Richard Biener wrote: >> > >> > This adjusts the x86 backend to allow -mfpmath differences when >> > deciding whether to

[PATCH] Fix PR81936

The following fixes offloading fallout from the early LTO debug patches. Bootstrap and regtest running on x86_64-unknown-linux-gnu, at least the compile stage is verified to work for nvptx offloading now. Richard. 2017-08-24 Richard Biener PR debug/81936

Re: [PATCH, gcc-7-branch] Backport PR80038

On 2017-08-22 10:17 +0200, Richard Biener wrote: > > Ok for the gcc 7 branch. > Well, I think I should say I don't have SVN write access... -- Xi Ruoyao School of Aerospace Science and Technology, Xidian University

Re: [Patch] PR c++/80287 backport on GCC 6 branch

On 08/24/2017 08:33 AM, Yvan Roux wrote: Hi, As described in the PR, gcc-6-branch is impacted by this issue. This patch backports the original fix from Bernd and the recently added testcase (which does not rely on c++17 features). https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80287

[PATCH] [MSP430] [PR80993] Prevent lto removing interrupt handlers

As reported in PR80993, enabling lto causes interrupt handlers to be removed. This patch marks interrupt handlers as used, preventing them from being optimized out. If the attached patch is acceptable, I would appreciate if someone could commit it for me, as I do not have write access. Thanks,

Re: [PATCH] Allow fpmath differences in inlining when callee doesn't use FP math

On Thu, 24 Aug 2017, Uros Bizjak wrote: > On Thu, Aug 24, 2017 at 1:10 PM, Richard Biener wrote: > > > > This adjusts the x86 backend to allow -mfpmath differences when > > deciding whether to allow inlining. -mfpmath doesn't really > > matter for functions not containing FP

[PATCH] [MSP430] Pass -mcode/data-region to the linker and assembler

The changes made in a series of binutils patches (https://sourceware.org/ml/binutils/2017-08/msg00274.html) to ld and gas require the -mcode/data-region options to be propagated from gcc. The attached patch adds that functionality. If the patch is acceptable, I would appreciate if someone could

Re: [PATCH] [MSP430] Read mcu data from file instead of hardcoded data

Back when we first designed this, I asked about including devices.csv in the gcc sources, and... no. It's not GPL. So please make sure to thoroughly test the "no devices.csv found" case. It's fine to use it to override the internal data, but not fine to rely on it. > *

[PATCH, testsuite]: Group together target-dependant checks

Some code moved to ease searching for subroutines. 2017-08-24 Uros Bizjak * lib/target-supports.exp: Group together target-dependant checks. Tested on x86_64-linux-gnu {-m32}. Committed to mainline SVN. Uros. diff --git a/gcc/testsuite/lib/target-supports.exp

[C++ PATCH] put all conv-ops onto single overload

Currently the conversion operator member functions are kept on a set of METHOD_VEC slots at the start of the method_vec. These are distinguished by return type. However, usually we want to grab all the conversion operators to see if one permits a conversion to whatever we're converting to.

Re: PR81635: Use chrecs to help find related data refs

Richard Biener writes: > @@ -787,14 +821,14 @@ canonicalize_base_object_address (tree a > > bool > dr_analyze_innermost (innermost_loop_behavior *drb, tree ref, > - struct loop *loop) > + gimple *stmt, struct loop *loop) > { >

Re: [PATCH] Add -static-pie to GCC driver to create static PIE

On Wed, Aug 9, 2017 at 3:39 AM, H.J. Lu wrote: > On Tue, Aug 8, 2017 at 10:36 PM, Richard Biener > wrote: >> On August 9, 2017 12:18:41 AM GMT+02:00, "H.J. Lu" >> wrote: >>>This patch adds -static-pie to GCC driver to

Re: [PATCH v2] Simplify pow with constant

On 08/17/2017 09:43 AM, Alexander Monakov wrote: > On Thu, 17 Aug 2017, Wilco Dijkstra wrote: > >> This patch simplifies pow (C, x) into exp (x * C1) if C > 0, C1 = log (C). > > Note this changes the outcome for C == +Inf, x == 0 (pow is specified to > return 1.0 in that case, but x * C1 ==

Re: [PATCH GCC][04/06]Add copying interface for dependence_info

On 08/14/2017 03:19 AM, Bin Cheng wrote: > HI, > This patch adds copying interface for dependence_info. The methodology > is we don't copy such information by default, and this interface should > be called explicitly when it is safe and necessary to do so. Just like > this patch uses the

Re: [Patch][aarch64] Use IFUNCs to enable LSE instructions in libatomic on aarch64

Ping. > 2017-08-07  Steve Ellcey   > > * Makefile.am (ARCH_AARCH64_LINUX_LSE): Add IFUNC_OPTIONS and > libatomic_la_LIBADD. > * config/linux/aarch64/host-config.h: New file. > * config/linux/aarch64/init.c: New file. > * configure.ac

Drop df_ from df_read_modify_subreg_p

...it's really a general RTL predicate, rather than something that depends on the DF state. Thanks to Segher for the suggestion. Tested on aarch64-linux-gnu and x86_64-linux-gnu. OK to install? Richard 2017-08-24 Richard Sandiford gcc/ * df.h

Re: Make more use of df_read_modify_subreg_p

Segher Boessenkool writes: > On Wed, Aug 23, 2017 at 11:49:03AM +0100, Richard Sandiford wrote: >> This patch uses df_read_modify_subreg_p to check whether writing >> to a subreg would preserve some of the existing contents. > > combine does not keep the DF info

[PATCH] Add --enable-static-pie to build static PIE

--enable-static-pie configures glibc to compile libc.a as PIE and creates static executables as PIE. A static position independent executable (static PIE) is similar to static executable, but can be loaded at any address without help from a dynamic linker. All linker input files must be compiled

Re: [PATCH] Factor out division by squares and remove division around comparisons (1/2)

On 08/17/2017 03:55 AM, Wilco Dijkstra wrote: > Richard Biener wrote: >> On Tue, Aug 15, 2017 at 4:11 PM, Wilco Dijkstra >> wrote: >>> Richard Biener wrote: > We also change the association of > > x / (y * C) -> (x / C) / y > > If C is a

[PATCH, rs6000] Fix PR81504 (vec_ld / vec_st bug)

Hi, https://gcc.gnu.org/PR81504 reports a problem with the use of vec_st to generate the stvx instruction. With swap optimization enabled, the stvx instruction uses the wrong base address, causing data corruption. The problem arises in the recombine_lvx_stvx pre-pass that runs prior to swap

Re: [PATCH] PR81747, ICE in operator[]

On 08/15/2017 09:27 PM, Alan Modra wrote: > Ping? > > On Wed, Aug 09, 2017 at 08:58:31PM +0930, Alan Modra wrote: >> PR rtl-optimization/81747 >> * cse.c (cse_extended_basic_block): Don't attempt to record >> equivalences for degenerate conditional jumps that branch >> to

Re: [PATCH GCC][03/06]Dump dependence information

On 08/14/2017 03:19 AM, Bin Cheng wrote: > Hi, > This simple patch adds code dumping struct dependence_info. > Bootstrap and test in series. Is it OK? > > Thanks, > bin > 2017-08-10 Bin Cheng > > * tree-pretty-print.c (dump_generic_node): Dump fixed length >

Re: [PATCH 1/3] improve detection of attribute conflicts (PR 81544)

The bulk of this patch touches what I think is considered the middle-end (attribs.c) so let me include its maintainers, Ian, Jeff, and Richard: https://gcc.gnu.org/ml/gcc-patches/2017-08/msg01087.html The high-level description and rationale for the change are here:

Re: Drop df_ from df_read_modify_subreg_p

On 08/24/2017 12:21 PM, Richard Sandiford wrote: > ...it's really a general RTL predicate, rather than something that depends > on the DF state. Thanks to Segher for the suggestion. > > Tested on aarch64-linux-gnu and x86_64-linux-gnu. OK to install? > > Richard > > > 2017-08-24 Richard

Re: [54/77] Add explicit int checks for alternative optab implementations

On 07/13/2017 02:57 AM, Richard Sandiford wrote: > expand_unop can expand narrow clz, clrsb, ctz, bswap, parity and > ffs operations using optabs for wider modes. These expansions > apply only to scalar integer modes (and not for example to vectors), > so the patch adds explicit checks for that.

Re: [61/77] Use scalar_int_mode in the AArch64 port

On 07/13/2017 03:00 AM, Richard Sandiford wrote: > This patch makes the AArch64 port use scalar_int_mode in various places. > Other ports won't need this kind of change; we only need it for AArch64 > because of the variable-sized SVE modes. > > The only change in functionality is in the rtx_costs

Re: [62/77] Big machine_mode to scalar_int_mode replacement

On 07/13/2017 03:00 AM, Richard Sandiford wrote: > This patch changes the types of various things from machine_mode > to scalar_int_mode, in cases where (after previous patches) > simply changing the type is enough on its own. The patch does > nothing other than that. > > 2017-07-13 Richard

Re: [PATCH] handle pathological anti-ranges in gimple_fold_builtin_memory_op (PR 81908)

On 08/24/2017 09:03 AM, Martin Sebor wrote: > On 08/24/2017 08:03 AM, Richard Biener wrote: >> On Wed, Aug 23, 2017 at 9:42 PM, Martin Sebor wrote: >>> Bug 81908 is about a -Wstringop-overflow warning for a Fortran >>> test triggered by a recent VRP improvement. A simple test

Re: [PATCH] Improve alloca alignment

On 08/22/2017 08:15 AM, Wilco Dijkstra wrote: > Jeff Law wrote: > On 07/26/2017 05:29 PM, Wilco Dijkstra wrote: > >>> But then the check size_align % MAX_SUPPORTED_STACK_ALIGNMENT != 0 >>> seems wrong too given that round_push uses a different alignment to align >>> to. >> I had started to dig

Re: [PATCH, rs6000] Fix PR81504 (vec_ld / vec_st bug)

Hi! On Thu, Aug 24, 2017 at 04:04:23PM -0500, Bill Schmidt wrote: > @@ -1501,7 +1503,21 @@ recombine_lvx_pattern (rtx_insn *insn, del_info *t > to_delete[INSN_UID (swap_insn)].replace = true; > to_delete[INSN_UID (swap_insn)].replace_insn = swap_insn; > > - XEXP (mem, 0) =

Re: [PING #2] [PATCH] enhance -Wrestrict to handle string built-ins (PR 78918)

On 08/22/2017 02:45 AM, Richard Biener wrote: > On Mon, Aug 21, 2017 at 10:10 PM, Martin Sebor wrote: >> On 08/09/2017 10:14 AM, Jeff Law wrote: >>> >>> On 08/06/2017 05:08 PM, Martin Sebor wrote: >>> > > Well, simply because the way as implemented isn't a must-alias

Re: [55/77] Use scalar_int_mode in simplify_const_unary_operation

On 07/13/2017 02:58 AM, Richard Sandiford wrote: > The main scalar integer block in simplify_const_unary_operation > had the condition: > > if (CONST_SCALAR_INT_P (op) && width > 0) > > where "width > 0" was a roundabout way of testing != VOIDmode. > This patch replaces it with a check for a

Re: [57/77] Use scalar_int_mode in expand_expr_addr_expr

On 07/13/2017 02:58 AM, Richard Sandiford wrote: > This patch rewrites the condition: > > if (tmode != address_mode && tmode != pointer_mode) > tmode = address_mode; > > to the equivalent: > > tmode == pointer_mode ? pointer_mode : address_mode > > The latter has the advantage that the

Re: [58/77] Use scalar_int_mode in a try_combine optimisation

On 07/13/2017 02:59 AM, Richard Sandiford wrote: > This patch uses scalar_int_modes for: > > /* If I2 is setting a pseudo to a constant and I3 is setting some > sub-part of it to another constant, merge them by making a new > constant. */ > > This was already implicit, but the

Re: [59/77] Add a rtx_jump_table_data::get_data_mode helper

On 07/13/2017 02:59 AM, Richard Sandiford wrote: > This patch adds a helper function to get the mode of the addresses > or offsets in a jump table. It also changes the final.c code to use > rtx_jump_table_data over rtx or rtx_insn in cases where it needed > to use the new helper. This in turn

Re: [60/77] Pass scalar_int_modes to do_jump_by_parts_*

On 07/13/2017 02:59 AM, Richard Sandiford wrote: > The callers of do_jump_by_parts_* had already established > that the modes were MODE_INTs, so this patch passes the > modes down as scalar_int_modes. > > 2017-07-13 Richard Sandiford > Alan Hayward

Re: [63/77] Simplifications after type switch

On 07/13/2017 03:01 AM, Richard Sandiford wrote: > This patch makes a few simplifications after the previous > mechanical machine_mode->scalar_int_mode change. > > 2017-07-13 Richard Sandiford > Alan Hayward > David

Re: [PATCH v2] Simplify pow with constant

On 08/17/2017 07:56 AM, Wilco Dijkstra wrote: > This patch simplifies pow (C, x) into exp (x * C1) if C > 0, C1 = log (C). > Do this only for fast-math as accuracy is reduced. This is much faster > since pow is more complex than exp - with current GLIBC the speedup is > more than 7 times for this

Re: [PATCH] handle pathological anti-ranges in gimple_fold_builtin_memory_op (PR 81908)

On 08/24/2017 03:52 PM, Jeff Law wrote: On 08/24/2017 09:03 AM, Martin Sebor wrote: On 08/24/2017 08:03 AM, Richard Biener wrote: On Wed, Aug 23, 2017 at 9:42 PM, Martin Sebor wrote: Bug 81908 is about a -Wstringop-overflow warning for a Fortran test triggered by a recent

Re: [65/77] Add a SCALAR_TYPE_MODE macro

On 07/13/2017 03:01 AM, Richard Sandiford wrote: > This patch adds a SCALAR_TYPE_MODE macro, along the same lines as > SCALAR_INT_TYPE_MODE and SCALAR_FLOAT_TYPE_MODE. It also adds > two instances of as_a to c_common_type, when converting > an unsigned fixed-point SCALAR_TYPE_MODE to the

Re: [48/77] Make subroutines of num_sign_bit_copies operate on scalar_int_mode

On 07/13/2017 02:55 AM, Richard Sandiford wrote: > Similarly to the nonzero_bits patch, this one moves the mode > class check and VOIDmode handling from num_sign_bit_copies1 > to num_sign_bit_copies itself, then changes the subroutines > to operate on scalar_int_modes. > > gcc/ > 2017-07-13

Re: [PR middle-end/81931] do not pass 0 precision in get_nonzero_bits

On Thu, 24 Aug 2017, Aldy Hernandez wrote: As discussed in the PR... CCP is passing a precision of 0 to get_nonzero_bits for complex numbers. With my last wide_int sign extension patch, the sign extension of -1 with a precision of 0 returns 0, whereas it previously was preturning all ones.

Re: [47/77] Make subroutines of nonzero_bits operate on scalar_int_mode

On 07/13/2017 02:55 AM, Richard Sandiford wrote: > nonzero_bits1 assumed that all bits of a floating-point or vector mode > were needed. It seems likely that fixed-point modes should have been > handled in the same way. After excluding those, the only remaining > modes that are likely to be

Re: [49/77] Simplify nonzero/num_sign_bits hooks

On 07/13/2017 02:55 AM, Richard Sandiford wrote: > The two implementations of the reg_nonzero_bits and reg_num_sign_bits > hooks ignored the "known_x", "known_mode" and "known_ret" arguments, > so this patch removes them. It adds a new scalar_int_mode parameter > that specifies the mode of "x".

Re: [PATCH 6/6] qsort comparator consistency checking

On 08/10/2017 05:24 AM, Alexander Monakov wrote: > On Wed, 9 Aug 2017, Jeff Law wrote: The _5th macro isn't that bad either, appart from using reserved namespace identifiers (it really should be something like qsort_5th and the arguments shouldn't start with underscores). >>> >>> I

[PR middle-end/81931] do not pass 0 precision in get_nonzero_bits

As discussed in the PR... CCP is passing a precision of 0 to get_nonzero_bits for complex numbers. With my last wide_int sign extension patch, the sign extension of -1 with a precision of 0 returns 0, whereas it previously was preturning all ones. The attached patch calls element_precision, to

RE: [PATCH][GCC][PATCHv3] Improve fpclassify w.r.t IEEE like numbers in GIMPLE.

On Wed, 23 Aug 2017, Tamar Christina wrote: > Hi Richard, > > Thanks for the feedback, > > > > > I think you should split up your work a bit. The pieces from > > fold_builtin_* you remove and move to lowering that require no control flow > > like __builtin_isnan (x) -> x UNORD x should move

Re: Heads-Up: early LTO debug to land, breaking Mach-O / [X]COFF

On Wed, 23 Aug 2017, Rainer Orth wrote: > Hi Richard, > > > On Fri, 12 May 2017, Richard Biener wrote: > > > >> > >> This is a heads-up that I am in the process of implementing the last > >> of Jasons review comments on the dwarf2out parts of early LTO debug > >> support. I hope to post final

Re: [PATCH] PowerPC cleanup, remove -mpower9-dform{,-scalar,-vector} options

Hi Mike, On Wed, Aug 23, 2017 at 01:34:43PM -0400, Michael Meissner wrote: > This patch eliminates the undocumented debugging options -mpower9-dform, > -mpower9-dform-scalar, and -mpower9-dform-vector. These switches were added > when I added the support for the ISA 3.0 (power9) d-form

Re: [70/77] Make expand_fix/float check for scalar modes

On 07/13/2017 03:03 AM, Richard Sandiford wrote: > The expand_float code: > > /* Unsigned integer, and no way to convert directly. Convert as signed, > then unconditionally adjust the result. */ > > and the expand_fix code: > > /* For an unsigned conversion, there is one more way to

Re: [69/77] Split scalar-only part out of convert_mode

On 07/13/2017 03:03 AM, Richard Sandiford wrote: > This patch splits the final scalar-only part of convert_mode out > into its own subroutine and treats the modes as scalar_modes there. > > 2017-07-13 Richard Sandiford > Alan Hayward

Re: [68/77] Use scalar_mode for is_int_mode/is_float_mode pairs

On 07/13/2017 03:02 AM, Richard Sandiford wrote: > This patch uses scalar_mode for code that operates only on MODE_INT > and MODE_FLOAT. > > 2017-07-13 Richard Sandiford > Alan Hayward > David Sherwood

Re: [66/77] Use scalar_mode for constant integers

On 07/13/2017 03:02 AM, Richard Sandiford wrote: > This patch treats the mode associated with an integer constant as a > scalar_mode. We can't use the more natural-sounding scalar_int_mode > because we also use (const_int 0) for bounds-checking modes. (It might > be worth adding a

Re: [64/77] Add a scalar_mode class

On 07/13/2017 03:01 AM, Richard Sandiford wrote: > This patch adds a scalar_mode class that can hold any scalar mode, > specifically: > > - scalar integers > - scalar floating-point values > - scalar fractional modes > - scalar accumulator modes > - pointer bounds modes > > To start