Some x86 tests of stack realignment, that disaligned the stack with
pushes and pops, failed when the compiler was configured to tune for a
target that preferred to accumulate outgoing arguments: the stack
space is reserved before the asm push, the call sequence overwrites
the saved register, and th
Last week's enhancement to detect one-byte buffer overflows exposed
a bug that let the warning use the size of a prior MEM_REF access
and "override" the size of the actual store to the character array.
When the store was smaller than the prior access (e.g., one byte,
vs an 8-byte null pointer read
-Wclass-memaccess doesn't trigger for access to arrays of
objects whose type it's designed to trigger for. It looks
to me like a simple oversight in maybe_warn_class_memaccess.
Attached is a trivial patch to correct it tested on
x86_64-linux.
Martin
PR c++/92001 - missing -Wclass-memaccess with
Since TS 18661-1 has been integrated into C2X, this patch makes C2X
imply -fno-fp-int-builtin-inexact.
Bootstrapped with no regressions on x86_64-pc-linux-gnu. Applied to
mainline.
gcc:
2019-10-08 Joseph Myers
* doc/invoke.texi (-ffp-int-builtin-inexact): Document
-fno-fp-in
On Fri, 4 Oct 2019 at 16:08, Richard Biener wrote:
>
> On Thu, Oct 3, 2019 at 1:42 AM Prathamesh Kulkarni
> wrote:
> >
> > On Wed, 25 Sep 2019 at 09:17, Prathamesh Kulkarni
> > wrote:
> > >
> > > On Mon, 16 Sep 2019 at 08:54, Prathamesh Kulkarni
> > > wrote:
> > > >
> > > > On Mon, 9 Sep 2019 a
On Mon, 7 Oct 2019 at 03:11, Richard Biener wrote:
>
> On Fri, 4 Oct 2019, Prathamesh Kulkarni wrote:
>
> > On Fri, 4 Oct 2019 at 12:18, Richard Biener wrote:
> > >
> > > On Thu, 3 Oct 2019, Prathamesh Kulkarni wrote:
> > >
> > > > On Wed, 2 Oct 2019 at 12:28, Richard Biener wrote:
> > > > >
> >
On Mon, Oct 07, 2019 at 02:56:10PM -0400, Jason Merrill wrote:
> > @@ -1378,7 +1381,7 @@ standard_conversion (tree to, tree from, tree expr,
> > bool c_cast_p,
> > if (same_type_p (from, to))
> > /* OK */;
> > - else if (c_cast_p && comp_ptr_ttypes_const (to, from))
> > + els
This patch includes a rather comprehensive test case for
"use_device_addr" – and fixes the fall out. Notes:
* Only scalars and non-descriptor arrays are tested
* In particular, polymorphic types, absent optional arguments and
array-descriptor arrays are not; nor are associate-block variables n
On Sat, 5 Oct 2019, Bernd Edlinger wrote:
> > Like
> >
> > #define DEFAULT_SOME_MACRO(PARMS) { lots of code }
> >
> > becomes
> >
> > #define DEFAULT_SOME_MACRO(PARMS) default_some_macro(PARMS)
> >
> > static inline int
> > default_some_macro (int parm, long another)
> > {
> > lots of code;
On 10/7/19 4:57 PM, Jakub Jelinek wrote:
On Mon, Oct 07, 2019 at 04:37:13PM -0400, Jason Merrill wrote:
How? By adding a SAVE_EXPR in there, so that generic code is safe?
Something like that, yes.
Ok, will try that tomorrow.
I haven't touched the ARRAY_REF case earlier, because that I bel
On Mon, Oct 07, 2019 at 04:37:13PM -0400, Jason Merrill wrote:
> > How? By adding a SAVE_EXPR in there, so that generic code is safe?
>
> Something like that, yes.
Ok, will try that tomorrow.
> > I haven't touched the ARRAY_REF case earlier, because that I believe is
> > handled right in the gi
On Mon, Oct 7, 2019 at 4:47 PM Indu Bhagat wrote:
> On 10/07/2019 12:35 AM, Richard Biener wrote:
> > On Fri, Oct 4, 2019 at 9:12 PM Indu Bhagat
> wrote:
> >> Hello,
> >>
> >> At GNU Tools Cauldron this year, some folks were curious to know more
> on how
> >> the "type representation" in CTF com
On 10/07/2019 12:35 AM, Richard Biener wrote:
On Fri, Oct 4, 2019 at 9:12 PM Indu Bhagat wrote:
Hello,
At GNU Tools Cauldron this year, some folks were curious to know more on how
the "type representation" in CTF compares vis-a-vis DWARF.
[...]
So, for the small C testcase with a union, e
On Fri, Oct 04, 2019 at 06:31:34PM -0300, Tulio Magno Quites Machado Filho
wrote:
> Michael Meissner writes:
>
> > And then I built Spec 2006 and 2017 with my normal options on a power8
> > system
> > running Ubuntu and an older set of host libraries. If I have this patch
> > installed, it bre
To improve consistency in the naming scheme for functions and other C objects
in the msp430 backend, the attached patch replaces names that start with "msp_"
with "msp430_".
The patch exposed some whitespace issues in msp430.md. These have also been
fixed.
Regtested on trunk.
Committed as obvious.
On 10/7/19 4:10 PM, Jakub Jelinek wrote:
On Mon, Oct 07, 2019 at 03:51:05PM -0400, Jason Merrill wrote:
- if (TREE_CODE (arg1) == COMPOUND_EXPR)
+ if (TREE_CODE (arg1) == COMPOUND_EXPR
+ && (flag_strong_eval_order != 2
+ /* C++17 disallows this canonicalization for
In preparation for upcoming changes to the addsi splitter, the attached patch
puts C code to perform the splitting in its own function.
Regtested on trunk.
Committed as obvious.
From 41e73d742fda612b0978cf84ae8732b430c4ef5a Mon Sep 17 00:00:00 2001
From: jozefl
Date: Mon, 7 Oct 2019 20:05:30 +000
For weak, hidden vars the indirection should just be as normal; that
is, that the indirections for such symbols should appear in the non-lazy
symbol pointers table, not in the .data section.
tested on x86_64-darwin16, applied to mainline,
thanks
Iain
gcc/ChangeLog:
2019-10-07 Iain Sandoe
MSP430 supports post increment addressing for the source operand only. The
attached patch enables post increment addressing for MSP430 in GCC.
Regtested on trunk for the small and large memory models.
Ok for trunk?
>From d75e48ba434d7bab141c09d442793b2cb26afa69 Mon Sep 17 00:00:00 2001
From: Joze
We want to improve the detection and caching of symbol-properties
so that (a) we can make the compiler's output match the platform
norms (b) we can improve efficiency by checking flags instead of
inspecting strings. (c) The fix for PR71767 was a largish hammer
and we want to reduce the number of sy
On Mon, Oct 07, 2019 at 03:51:05PM -0400, Jason Merrill wrote:
> > - if (TREE_CODE (arg1) == COMPOUND_EXPR)
> > + if (TREE_CODE (arg1) == COMPOUND_EXPR
> > + && (flag_strong_eval_order != 2
> > + /* C++17 disallows this canonicalization for shifts. */
> > + || (code !
On 10/7/19 12:23 PM, Jakub Jelinek wrote:
Hi!
So, C++17 and later says that in E1[E2] and E1 << E2 and E1 >> E2 the
E1 expression is sequenced before E2.
Similarly to the recent call expression PR, while the gimplifier
gimplifies the first operand before the second one, it uses is_gimple_val
as
On 10/7/19 1:42 PM, Marek Polacek wrote:
On Sun, Oct 06, 2019 at 03:39:25PM +, Tam S. B. wrote:
Hi, sorry for chiming in.
Hi, no worries, comments are welcome!
IIUC P0388R4 does not allow implicit conversion from `T(*)[]` to `T(*)[N]`. Per
[conv.qual]/3,
A prvalue of type `T1` can be
Hi!
On 2019-09-05T08:45:50+0100, Jonathan Wakely wrote:
> Committed to trunk. I think I'll backport this too, so we don't keep a
> non-working link in the docs on release branches.
> commit 45a605e970ea6db474e40c02aef6b18993fea05c
> Author: Jonathan Wakely
> Date: Thu Sep 5 08:40:35 2019 +010
Hi!
On 2019-09-08T19:35:52+0800, Gerald Pfeifer wrote:
> On Thu, 29 Aug 2019, Jose E. Marchesi wrote:
>> ChangeLog:
>>
>> * MAINTAINERS: Add myself as the maintainer of the eBPF port.
>
> Approved.
>
> As in: Approved by the steering committed assuming the patchset passes
> technical review
Put some functions to a better place.
2019-10-07 Uroš Bizjak
* config/i386/i386-expand.c (ix86_expand_floorceildf_32,
ix86_expand_rounddf_32): Reorder functions.
* config/i386/i386-protos.h: Update..
Bootstrapped and regression tested on x86_64-linux-gnu {,-m32}.
Committed to mai
Hi Jakub!
On 2018-12-03T16:51:14+, "Maciej W. Rozycki" wrote:
> Add generic support for the OpenACC 2.6 `acc_get_property' and
> `acc_get_property_string' routines [...]
..., which allow for user code to query the implementation for stuff like:
> OpenACC vendor: GNU
> OpenACC name: GOMP
>
On Mon, 7 Oct 2019, Aldy Hernandez wrote:
On 10/4/19 2:09 PM, Jeff Law wrote:
You're right. Easier to refer to the before/after directly. Sometimes
diffs just suck.
OK
jeff
In testing this patch in isolation from the non-zero canonicalization patch,
I found one regression due to the fact
On Mon, Oct 07, 2019 at 05:11:27PM +, Bernd Edlinger wrote:
> On 10/7/19 9:20 AM, Eric Botcazou wrote:
> > No, please, the cure would be much worse than the disease.
>
> Ack.
>
> I think the least worse thing would be a pragma in the macro where the
> shadowing
> variable is declared...
The
On Sun, Oct 06, 2019 at 03:39:25PM +, Tam S. B. wrote:
> Hi, sorry for chiming in.
Hi, no worries, comments are welcome!
> IIUC P0388R4 does not allow implicit conversion from `T(*)[]` to `T(*)[N]`.
> Per [conv.qual]/3,
>
> > A prvalue of type `T1` can be converted to type `T2` if the cv-c
On 10/7/19 9:20 AM, Eric Botcazou wrote:
>> If this ends up acked then please add this to ansidecl.h or
>> somewhere else global as template:
>>
>> template
>> struct push {
>> push (T &);
>> ~push ();
>> T *m_loc;
>> T m_val;
>> };
>>
>> because it would be a general solution for _all_ sh
On 01.10.19 15:27, wrote:
> gcc/testsuite/ChangeLog:
>
> 2019-08-09 Ilya Leoshkevich
>
> PR target/77918
> * gcc.target/s390/s390.exp: Enable Fortran tests.
> * gcc.target/s390/zvector/autovec-double-quiet-eq.c: New test.
> * gcc.target/s390/zvector/autovec-double-quie
Hi!
So, C++17 and later says that in E1[E2] and E1 << E2 and E1 >> E2 the
E1 expression is sequenced before E2.
Similarly to the recent call expression PR, while the gimplifier
gimplifies the first operand before the second one, it uses is_gimple_val
as predicate (and we don't really have a usable
On 01.10.19 15:27, Ilya Leoshkevich wrote:
> dg-torture.exp=inf-compare-1.c is failing, because (qNaN > +Inf)
> comparison is compiled to CDB instruction, which does not signal an
> invalid operation exception. KDB should have been used instead.
>
> This patch introduces a new CCmode and a new pat
On 01.10.19 15:27, Ilya Leoshkevich wrote:
> z13 supports only non-signaling vector comparisons. This means we
> cannot vectorize LT, LE, GT, GE and LTGT when compiling for z13. Notify
> middle-end about this by using more restrictive operator predicate in
> vcond.
>
> gcc/ChangeLog:
>
> 2019-0
Hi!
This testcase started FAILing on i?86-linux with r276603 (the -O2 inlining
changes):
/home/jakub/src/gcc/gcc/testsuite/gcc.target/i386/pr71801.c:12:3: warning:
writing 24 bytes into a region of size 1 [-Wstringop-overflow=]
/home/jakub/src/gcc/gcc/testsuite/gcc.target/i386/pr71801.c:14:5: war
> Am 03.10.2019 um 14:42 schrieb Richard Sandiford :
>
> Ilya Leoshkevich writes:
>> z13 supports only non-signaling vector comparisons. This means we
>> cannot vectorize LT, LE, GT, GE and LTGT when compiling for z13.
>> However, we cannot express this restriction today: the code only checks
>>
On 10/6/19 11:39 AM, Tam S. B. wrote:
Hi, sorry for chiming in.
IIUC P0388R4 does not allow implicit conversion from `T(*)[]` to `T(*)[N]`. Per
[conv.qual]/3,
A prvalue of type `T1` can be converted to type `T2` if the cv-combined type of
`T1` and `T2` is `T2`.
When T1 is `T(*)[]` and T2 i
OK.
Hi Chung-Lin!
On 2019-08-20T19:36:56+0800, Chung-Lin Tang wrote:
> --- libgomp/testsuite/libgomp.oacc-c-c++-common/noncontig_array-1.c
> (nonexistent)
> +++ libgomp/testsuite/libgomp.oacc-c-c++-common/noncontig_array-1.c
> (working copy)
> @@ -0,0 +1,103 @@
> +/* { dg-do run { target { ! op
Hi Chung-Lin!
Thanks for your work on this.
Please reference PR76739 in your submission/ChangeLog updates.
We'll need Jakub to review the generic code changes, but let me provide
some first review remarks, too.
On 2019-08-20T19:36:24+0800, Chung-Lin Tang wrote:
> The first patch here are th
On Fri, 4 Oct 2019 at 16:35, Richard Sandiford
wrote:
> Christophe Lyon writes:
> > On Mon, 30 Sep 2019 at 00:20, Jeff Law wrote:
> >
> > On 9/11/19 1:17 PM, Richard Sandiford wrote:
> > > This is a straight replacement of an existing "full or partial"
> > > call-clobber check.
> >
On 07/10/2019 10:25 am, Thomas Schwinge wrote:
Hi Kwok, Tobias!
On 2019-07-29T21:55:52+0100, Kwok Cheung Yeung wrote:
> if (omp_is_reference (new_var)
> && TREE_CODE (TREE_TYPE (new_var)) != POINTER_TYPE)
As is, this code in lower_omp_target will always rejec
On 10/7/19 8:56 AM, Richard Biener wrote:
> On Sun, Oct 6, 2019 at 1:24 PM Bernd Edlinger
> wrote:
>>
>> On 10/5/19 8:24 PM, Segher Boessenkool wrote:
>>>
>>> I am maintainer of combine, I know all about its many problems (it has much
>>> deeper problems than this unfortunately). Thanks for your
Hi,
the below fixes those two functions consistently with
cp_parser_new_expression. Additionally, a few rather straightforward
tweaks along the usual lines, more DECL_SOURCE_LOCATION and id_loc.
Tested x86_64-linux.
Thanks, Paolo.
/
/cp
2019-10-07 Paolo Carlini
On 10/4/19 1:17 PM, Jeff Law wrote:
On 10/4/19 10:14 AM, Aldy Hernandez wrote:
On 10/4/19 12:02 PM, Jeff Law wrote:
On 10/4/19 9:49 AM, Aldy Hernandez wrote:
On 10/4/19 11:38 AM, Jeff Law wrote:
On 10/4/19 6:59 AM, Aldy Hernandez wrote:
When I did the value_range canonicalization work, I
+bool
+ipa_vr::nonzero_p (tree expr_type) const
+{
+ if (type == VR_ANTI_RANGE && wi::eq_p (min, 0) && wi::eq_p (max, 0))
+ return true;
+
+ unsigned prec = TYPE_PRECISION (expr_type);
+ return (type == VR_RANGE
+ && wi::eq_p (min, wi::one (prec))
+ && wi::eq_p (max, wi::m
On 10/4/19 2:09 PM, Jeff Law wrote:
You're right. Easier to refer to the before/after directly. Sometimes
diffs just suck.
OK
jeff
In testing this patch in isolation from the non-zero canonicalization
patch, I found one regression due to the fact that:
a) As discussed, two non-zero repre
On Tue, 1 Oct 2019, Tamar Christina wrote:
> Hi All,
>
> This adds a framework to allow pattern matchers to be written at based on the
> SLP tree. The difference between this one and the one in tree-vect-patterns
> is
> that this matcher allows the matching of an arbitrary number of parallel
>
On Fri, 4 Oct 2019, Prathamesh Kulkarni wrote:
> On Fri, 4 Oct 2019 at 12:18, Richard Biener wrote:
> >
> > On Thu, 3 Oct 2019, Prathamesh Kulkarni wrote:
> >
> > > On Wed, 2 Oct 2019 at 12:28, Richard Biener wrote:
> > > >
> > > > On Wed, 2 Oct 2019, Prathamesh Kulkarni wrote:
> > > >
> > > > >
On Tue, Oct 1, 2019 at 1:48 PM Dmitrij Pochepko
wrote:
>
> Hi Richard,
>
> I updated patch according to all your comments.
> Also bootstrapped and tested again on x86_64-pc-linux-gnu and
> aarch64-linux-gnu, which took some time.
>
> attached v3.
OK.
Thanks,
Richard.
> Thanks,
> Dmitrij
>
> On
On Tue, Oct 1, 2019 at 3:27 PM Ilya Leoshkevich wrote:
>
> Right now gimplifier does not allow VEC_COND_EXPR's condition to trap
> and introduces a temporary if this could happen, for example, generating
>
> _5 = _4 > { 2.0e+0, 2.0e+0, 2.0e+0, 2.0e+0 };
> _6 = VEC_COND_EXPR <_5, { -1, -1, -1,
Instead of looking inside a range to determine if it has one sub-range,
use the API.
Committed as obvious.
Aldy
commit 93d4733dd1f8ce8ca4959f4584cec4bdd96d063e
Author: Aldy Hernandez
Date: Mon Oct 7 09:15:30 2019 +0200
Use value_range_base::num_pairs instead of vrp_val_is* to check if a
> > This is why we currently have way to order function when outputting them
> > and use that with FDO (using Martin's first execution logic). This has
> > drwarback of making the functions to flow in that order through late
> > optimizations and RTL backend and thus we lose IPA-RA and some
> > IP
Hi!
Jakub, ping -- and/or: Kwok, Tobias, as you recently worked through that
code for related issues (Fortran optional arguments), do you happen to
have any comments?
On 2019-06-07T16:01:29+0200, I wrote:
> As I had mentioned in the PR...
>
> On Tue, 7 Aug 2018 14:55:07 -0700, Cesar Philippidis
Hi Kwok, Tobias!
On 2019-07-29T21:55:52+0100, Kwok Cheung Yeung wrote:
> >if (omp_is_reference (new_var)
> >&& TREE_CODE (TREE_TYPE (new_var)) != POINTER_TYPE)
>
> As is, this code in lower_omp_target will always reject optional arguments,
> so
> it must be changed
The following tries to address the issue that PRE is quite happy
to introduce new IVs in loops just because it can compute some
constant value on the loop entry edge. In principle there's
already code that should work against that but it simply searches
for a optimize_edge_for_speed () edge. Th
Currently there's a surprising difference in unrolling size estimation
depending on how exactly you formulate your IV expressions. The following
patch makes it less dependent on this, behaving like the more optimistical
treatment (&a + 1 being constant). In the end it's still a heuristic
and in
On Mon, Oct 07, 2019 at 08:56:44AM +0200, Richard Biener wrote:
> But I agree that mechanically "fixing" the current code-base, while ending up
> with no new introductions of local shadowing, is worse if it makes the current
> code-base worse.
Obfucating the names is not often a good fix for the "
On Fri, Oct 4, 2019 at 9:12 PM Indu Bhagat wrote:
>
> Hello,
>
> At GNU Tools Cauldron this year, some folks were curious to know more on how
> the "type representation" in CTF compares vis-a-vis DWARF.
>
> I use small testcase below to gather some numbers to help drive this
> discussion.
>
> [ib
> If this ends up acked then please add this to ansidecl.h or
> somewhere else global as template:
>
> template
> struct push {
> push (T &);
> ~push ();
> T *m_loc;
> T m_val;
> };
>
> because it would be a general solution for _all_ shadow=local warnings?!
No, please, the cure would b
On Thu, Oct 3, 2019 at 5:18 PM Bernd Edlinger wrote:
>
> Hi,
>
> this fixes -Wshadow=local warnings in passes.c.
> The non-trivial part is due to the PUSH_INSERT_PASSES_WITHIN
> is used recursively, and shadows the local value p
> in each invocation.
>
> Fixed by using a helper class that restores
On Sun, Oct 6, 2019 at 4:38 PM Jan Hubicka wrote:
>
> > On 9/19/19 2:33 AM, Martin Liška wrote:
> > > Hi.
> > >
> > > Function reordering has been around for quite some time and a naive
> > > implementation was also part of my diploma thesis some time ago.
> > > Currently, the GCC can reorder func
63 matches
Mail list logo
