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: gcc.dg/guality
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
> !HAVE_
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 worked, thanks! Note that I
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
I pushed this patch to openacc-gcc-7-branch to allow the runtime to
dynamically select a suitable num_worker for OpenACC parallel regions
which do not make use of the num_workers clause. As with num_gangs, the
default num_workers is now influenced by the GOMP_OPENACC_DIM
environment variable. Befor
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
whi
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 == ALTI
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 those
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
>> primary focus is to make sure th
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 translata
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.
>> This patch ins
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 (libgcc_floating_mode_supported_p): Take a
> scalar_float_mode.
> * doc/tm.texi: Regenerate.
>
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 an opt_scalar_float_mode.
> * doc/tm.texi: Regenerate.
> * config/
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
> Alan Hayward
> David S
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
>
> gcc/
> * coretypes.h (opt_scalar_float_mode): New typ
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 scalar_float_mode.
> * config/arm/arm.c (arm_assemble_integer): Update according
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 type
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))
>
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 fo
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 n
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
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 modes
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
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.
>>>
>>> - FOR_EACH
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 class,
>> startin
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
>
> gcc/
> * tree-switch-conversion.c (array_value_t
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 modes
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 inform if the warning w
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
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 San
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
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 al
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
> >> workaround for PR81430.
> > Should this be rev
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
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 a
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
>>> to do this, and re
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) {
>
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 a
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 match
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 precise diagnostics
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 literals doesn't really
> h
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
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.
T
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 alte
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
> vars
> via size re
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 aarch64-none-linu
46 matches
Mail list logo
