[PATCH] i386: Replace frame pointer with stack pointer in debug insns

When we eliminate frame pointer, we should also replace frame pointer with stack pointer - UNITS_PER_WORD in debug insns. This patch fixed: FAIL: gcc.dg/guality/pr58791-5.c -Os line pr58791-5.c:20 b1 == 9 FAIL: gcc.dg/guality/pr58791-5.c -Os line pr58791-5.c:20 b2 == 73 FAIL:

Re: [RS6000] linux startfile/endfile

On Fri, Aug 11, 2017 at 12:23:26PM +0930, Alan Modra wrote: > These need to match the gnu-user.h definitions to support > --enable-default-pie. Otherwise we end up linking the wrong startup > files when defaulting to PIE. > > I've just copied the HAVE_LD_PIE variants as we don't need the >

Re: [PATCH] [PR79542][Ada] Fix ICE in dwarf2out.c with nested func. inlining

On Fri, Aug 11, 2017 at 6:05 AM, Pierre-Marie de Rodat wrote: > On 08/07/2017 08:42 PM, Jason Merrill wrote: >> >> Perhaps the DECL_ABSTRACT_ORIGIN check in my patch should be >> decl_ultimate_origin instead, which should return null in that case? > > > It looks like it

[PATCH] [i386,testsuite] [PR 71958] Error on -mx32 with -mabi=ms

We currently error when -mx32 -mabi=sysv and we encounter a function with attribute ms_abi, but we are not erroring on -mx32 and -mabi=ms (either explicitly or when it is the default on Windows). In fact, it generates code that runs, but is of an undfined ABI. I'm running -m64 and -m32 tests now

Re: [PATCH 0/2] add unique_ptr class

On 05/08/17 20:05 +0100, Pedro Alves wrote: On 08/04/2017 07:52 PM, Jonathan Wakely wrote: On 31/07/17 19:46 -0400, tbsaunde+...@tbsaunde.org wrote: I've been saying I'd do this for a long time, but I'm finally getting to importing the C++98 compatable unique_ptr class Pedro wrote for gdb a

Re: [PATCH, rs6000] More diagnostic cleanup, addressing PR79845

On Fri, Aug 11, 2017 at 02:21:17PM -0500, Bill Schmidt wrote: > >> if (nargs == 0) > >>{ > >> -error ("%s only accepts %d arguments", name, (fcode == > >> ALTIVEC_BUILTIN_VEC_PROMOTE)+1 ); > >> +error ("builtin %qs only accepts %d arguments", name, > >> + (fcode ==

[og7] Adjust k80 resources

I've pushed this patch to openacc-gcc-7-branch to teach the libgomp nvptx plugin how to cope with the hardware resources on K80 boards. K80 boards have two physical GPUs on a single board. Consequently, the CUDA driver reports that 2x the amount of registers and shared memory are available on

Re: [PATCH, rs6000] More diagnostic cleanup, addressing PR79845

Hi Segher, Thanks for the review! > On Aug 11, 2017, at 2:14 PM, Segher Boessenkool > wrote: > > Hi Bill, > > On Thu, Aug 10, 2017 at 04:28:49PM -0500, Bill Schmidt wrote: >> This continues the cleanup of diagnostic messages in the rs6000 back end. >> The >>

Re: [PATCH, rs6000] More diagnostic cleanup, addressing PR79845

Hi Bill, On Thu, Aug 10, 2017 at 04:28:49PM -0500, Bill Schmidt wrote: > This continues the cleanup of diagnostic messages in the rs6000 back end. The > primary focus is to make sure that we use quoted strings with %qs, %<, %> as > appropriate, and that option strings are separated from

Re: [06/77] Make GET_MODE_WIDER return an opt_mode

Jeff Law writes: > On 07/13/2017 02:40 AM, Richard Sandiford wrote: >> GET_MODE_WIDER previously returned VOIDmode if no wider mode existed. >> That would cause problems with stricter mode classes, since VOIDmode >> isn't for example a valid scalar integer or floating-point mode.

Re: [14/77] Make libgcc_floating_mode_supported_p take a scalar_float_mode

On 07/13/2017 02:43 AM, Richard Sandiford wrote: > As per subject. > > 2017-07-13 Richard Sandiford > Alan Hayward > David Sherwood > > gcc/ > * target.def

Re: [13/77] Make floatn_mode return an opt_scalar_float_mode

On 07/13/2017 02:43 AM, Richard Sandiford wrote: > As per subject. > > 2017-07-13 Richard Sandiford > Alan Hayward > David Sherwood > > gcc/ > * target.def (default_floatn_mode): Return

Re: [12/77] Use opt_scalar_float_mode when iterating over float modes

On 07/13/2017 02:42 AM, Richard Sandiford wrote: > This means that we know when accessing the modes that the size is > a compile-time constant, even for SVE. It also enables stricter > type safety in later patches. > > 2017-07-13 Richard Sandiford >

Re: [11/77] Add a float_mode_for_size helper function

On 07/13/2017 02:42 AM, Richard Sandiford wrote: > This provides a type-safe way to ask for a float mode and get it as a > scalar_float_mode. > > 2017-07-13 Richard Sandiford > Alan Hayward > David Sherwood

Re: [10/77] Make assemble_real take a scalar_float_mode

On 07/13/2017 02:41 AM, Richard Sandiford wrote: > As per subject. > > 2017-07-13 Richard Sandiford > Alan Hayward > David Sherwood > > gcc/ > * output.h (assemble_real): Take a

Re: [09/77] Add SCALAR_FLOAT_TYPE_MODE

On 07/13/2017 02:41 AM, Richard Sandiford wrote: > This patch adds a macro that extracts the TYPE_MODE and forcibly > converts it to a scalar_float_mode. The forcible conversion > includes a gcc_checking_assert that the mode is a SCALAR_FLOAT_MODE_P. > > This becomes important as more static

Re: [08/77] Simplify gen_trunc/extend_conv_libfunc

On 07/13/2017 02:40 AM, Richard Sandiford wrote: > Replace checks of: > > GET_MODE_CLASS (fmode) != MODE_FLOAT && !DECIMAL_FLOAT_MODE_P (fmode) > > with !is_a and use MODE_CLASS equality/inequality > instead of: > > (GET_MODE_CLASS (tmode) == MODE_FLOAT && DECIMAL_FLOAT_MODE_P (fmode)) >

Re: [07/77] Add scalar_float_mode

On 07/13/2017 02:40 AM, Richard Sandiford wrote: > This patch adds a scalar_float_mode class, which wraps a mode enum > that is known to satisfy SCALAR_FLOAT_MODE_P. Things like "SFmode" > now give a scalar_float_mode object instead of a machine_mode. > This in turn needs a change to the real.h

Re: [06/77] Make GET_MODE_WIDER return an opt_mode

On 07/13/2017 02:40 AM, Richard Sandiford wrote: > GET_MODE_WIDER previously returned VOIDmode if no wider mode existed. > That would cause problems with stricter mode classes, since VOIDmode > isn't for example a valid scalar integer or floating-point mode. > This patch instead makes it return a

Re: C PATCH to fix bogus inform with -Wc++-compat (PR c/81795)

On Fri, 11 Aug 2017, Marek Polacek wrote: > Pretty trivial patch -- these two informs weren't properly guarded so > they'd trigger even if the warning was disabled via #pragma. > > Bootstrapped/regtested on x86_64-linux, ok for trunk? OK. -- Joseph S. Myers jos...@codesourcery.com

Re: [04/77] Add FOR_EACH iterators for modes

On 07/13/2017 02:39 AM, Richard Sandiford wrote: > The new iterators are: > > - FOR_EACH_MODE_IN_CLASS: iterate over all the modes in a mode class. > > - FOR_EACH_MODE_FROM: iterate over all the modes in a class, > starting at a given mode. > > - FOR_EACH_WIDER_MODE: iterate over all the

Re: *ping* [patch, fortran] Fix PR 60355, missing error for BIND(C) outside module scope

Hi Paul, It looks fine to me. OK for trunk. Thanks, committed. Paul PS What about PR34640 ? Your patch is OK if you bump the library version. Regards Thomas

Re: [04/77] Add FOR_EACH iterators for modes

On 08/11/2017 11:16 AM, Richard Sandiford wrote: > Hi Jeff, > > First, many thanks for the reviews! > > Jeff Law writes: >> On 07/13/2017 02:39 AM, Richard Sandiford wrote: >>> The new iterators are: >>> >>> - FOR_EACH_MODE_IN_CLASS: iterate over all the modes in a mode class.

Re: [04/77] Add FOR_EACH iterators for modes

Hi Jeff, First, many thanks for the reviews! Jeff Law writes: > On 07/13/2017 02:39 AM, Richard Sandiford wrote: >> The new iterators are: >> >> - FOR_EACH_MODE_IN_CLASS: iterate over all the modes in a mode class. >> >> - FOR_EACH_MODE_FROM: iterate over all the modes in a

Re: [05/77] Small tweak to array_value_type

On 07/13/2017 02:39 AM, Richard Sandiford wrote: > Store the type mode in a variable so that a later, > more mechanical patch can change its type. > > 2017-07-13 Richard Sandiford > Alan Hayward > David Sherwood

Re: [04/77] Add FOR_EACH iterators for modes

On 07/13/2017 02:39 AM, Richard Sandiford wrote: > The new iterators are: > > - FOR_EACH_MODE_IN_CLASS: iterate over all the modes in a mode class. > > - FOR_EACH_MODE_FROM: iterate over all the modes in a class, > starting at a given mode. > > - FOR_EACH_WIDER_MODE: iterate over all the

C PATCH to fix bogus inform with -Wc++-compat (PR c/81795)

Pretty trivial patch -- these two informs weren't properly guarded so they'd trigger even if the warning was disabled via #pragma. Bootstrapped/regtested on x86_64-linux, ok for trunk? 2017-08-11 Marek Polacek PR c/81795 * c-decl.c (pushtag): Only print

Re: [03/77] Allow machine modes to be classes

On 07/13/2017 02:38 AM, Richard Sandiford wrote: > This patch makes various changes that allow modes like SImode to be > classes rather than enums. > > Firstly, it adds inline functions for all mode size properties, > with the macros being simple wrappers around them. This is necessary > for the

Re: [02/77] Add an E_ prefix to mode names and update case statements

On 07/13/2017 02:38 AM, Richard Sandiford wrote: > All case statements need to be updated to use the prefixed names, > since the unprefixed names will eventually not be integer constant > expressions. This patch does a mechanical substitution over the whole > codebase. > > 2017-07-13 Richard

Re: [01/77] Add an E_ prefix to mode names

On 07/13/2017 02:36 AM, Richard Sandiford wrote: > Later patches will add wrapper types for specific classes > of mode. E.g. SImode will be a scalar_int_mode, SFmode will be a > scalar_float_mode, etc. This patch prepares for that change by adding > an E_ prefix to the mode enum values. It also

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

On Fri, 11 Aug 2017, Martin Sebor wrote: > > (An optional warning for different information in different declarations > > is reasonable enough. Actually in glibc it would be useful to have a > > warning for a different but related case - two functions both declared, > > later one defined as an

Re: [committed, nvptx] Add nvptx_override_options_after_change

Hi! On Tue, 8 Aug 2017 10:58:12 +0200, Tom de Vries wrote: > On 08/08/2017 10:45 AM, Thomas Schwinge wrote: > > On Fri, 21 Jul 2017 11:49:11 +0200, Tom de Vries > > wrote: > >> this patch adds nvptx_override_options_after_change, containing a >

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

On 08/10/2017 03:55 PM, Joseph Myers wrote: On Wed, 9 Aug 2017, Martin Sebor wrote: The problem isn't that the declarations aren't merged at the call site but rather that the middle-end gives const precedence over pure so when both attributes are provided the former wins. But that precedence

Re: [PATCH][testsuite] Add check_effective_target_autoincdec

Hi Wilco, > Richard Earnshaw wrote: >> Except that I think this would be better done as an 'effective target' >> test; something like >> >> dg-require-effective-target autoincdec > > Right I figured out how to do this - not trivial as it needs a secret flag > in the > glob call - if anyone knows

Re: [PATCH] Add macro DISABLE_COPY_AND_ASSIGN

On 08/02/2017 12:19 PM, Yao Qi wrote: > On Wed, Jul 26, 2017 at 9:55 AM, Yao Qi wrote: >> On 17-07-19 10:30:45, Yao Qi wrote: >>> We have many classes that copy cotr and assignment operator are deleted >>> in different projects, gcc, gdb and gold. So this patch adds a macro

Re: [AArch64, PATCH] Improve Neon store of zero

On 10/08/17 14:12, Jackson Woodruff wrote: > Hi all, > > This patch changes patterns in aarch64-simd.md to replace > > moviv0.4s, 0 > strq0, [x0, 16] > > With: > > stp xzr, xzr, [x0, 16] > > When we are storing zeros to vectors like this: > > void f(uint32x4_t *p) { >

Re: [PATCH] [PR79542][Ada] Fix ICE in dwarf2out.c with nested func. inlining

On 08/07/2017 08:42 PM, Jason Merrill wrote: Perhaps the DECL_ABSTRACT_ORIGIN check in my patch should be decl_ultimate_origin instead, which should return null in that case? It looks like it worked, thanks! Note that I had to tweak a bit your change in process_scope_vars to avoid a crash in

Re: [PATCH][GCC][AArch64] Fix pattern guard relaxations that are allowing more constants than they should.

On Fri, Aug 11, 2017 at 12:01:40PM +0100, Tamar Christina wrote: > Hi All, > > > Hi previous float immediate patches changed > > aarch64_reg_or_fp_zero into aarch64_reg_or_fp_float > for each of the movdf/sf/hf causing the RTL to contain > stores to memory it would never be able to find a

Small tweak to tree-sra diagnostics

In the case where build_access_from_expr_1 returns NULL because of a storage order barrier. No functional changes. Tested on x86_64-suse-linux, applied on the mainline as obvious. 2017-08-11 Eric Botcazou * tree-sra.c (build_access_from_expr_1): Use more

Re: [AARCH64] Disable pc relative literal load irrespective of TARGET_FIX_ERR_A53_84341

On 11 August 2017 at 13:50, Wilco Dijkstra wrote: > Kugan wrote: >> Ping^2? > > Could you make sure to either include the patch or provide a link to it? > (https://gcc.gnu.org/ml/gcc-patches/2017-06/msg01967.html) > > I think the patch is fine since avoiding adrp/ldr on

Re: [AARCH64] Disable pc relative literal load irrespective of TARGET_FIX_ERR_A53_84341

Kugan wrote: > Ping^2? Could you make sure to either include the patch or provide a link to it? (https://gcc.gnu.org/ml/gcc-patches/2017-06/msg01967.html) I think the patch is fine since avoiding adrp/ldr on literals doesn't really help when global variables still use adrp. If you really want to

[PATCH][GCC][AArch64] Fix pattern guard relaxations that are allowing more constants than they should.

Hi All, Hi previous float immediate patches changed aarch64_reg_or_fp_zero into aarch64_reg_or_fp_float for each of the movdf/sf/hf causing the RTL to contain stores to memory it would never be able to find a matching pattern for. Reload would then decide to store them to a register instead.

[PATCH] skip patchable_function_entry tests on ia64

As Andreas found out, patchable_function_entry tests generate false failures on ia64. On a closer look, this feature needs some more thought on itanium: I *could* imagine it is a good idea to generate N complete nop "bundles", which would be properly aligned and allow for easy replacement with

Re: [PATCH] Do not instrument void variables with MPX (PR tree-opt/79987).

On 08/11/2017 01:51 AM, Ilya Enkovich wrote: > 2017-08-10 10:40 GMT+03:00 Martin Liška : >> Hello. >> >> In order to prevent the ICE, CHKP should not isntrument variables of void >> type. > > Hi, > > There was another thread for this PR where I proposed a way to handle such >

[PATCH][GCC][AArch64] Restrict lrint inlining on ILP32.

Hi All, The inlining of lrint isn't valid in all cases on ILP32 when -fno-math-errno is used because an inexact exception is raised in certain circumstances. For ILP32 I now restrict the inlining only when -fno-trapping-math is also specified. This fixed PR/81800. Regtested on

Re: [AARCH64] Disable pc relative literal load irrespective of TARGET_FIX_ERR_A53_84341

Ping^2? Thanks, Kugan On 21 July 2017 at 20:12, Kugan Vivekanandarajah wrote: > Ping ? > > Thanks, > Kugan > > On 27 June 2017 at 11:20, Kugan Vivekanandarajah > wrote: >>