On Thu, Apr 05, 2018 at 09:01:02AM +0200, Andreas Krebbel wrote:
> > Wouldn't it be better to just use aligned (8) and aligned (16) instead of
> > aligned (4) and aligned (8)?
>
> aligned (8) does not trigger the warning anymore. Neither on s390 nor on
> x86. I don't think there
> is a way to
On 04/04/2018 07:34 PM, Jakub Jelinek wrote:
> On Wed, Apr 04, 2018 at 06:51:00PM +0200, Andreas Krebbel wrote:
>>> On targets enforcing a function alignment bigger than 4 bytes this triggers
>>> an error instead:
>>>
>>> +inline int ATTR ((aligned (4)))
>>> +finline_hot_noret_align (int); /* {
On Wed, Apr 04, 2018 at 06:51:00PM +0200, Andreas Krebbel wrote:
> > On targets enforcing a function alignment bigger than 4 bytes this triggers
> > an error instead:
> >
> > +inline int ATTR ((aligned (4)))
> > +finline_hot_noret_align (int); /* { dg-warning "ignoring attribute
> > .aligned
On 04/04/2018 10:51 AM, Andreas Krebbel wrote:
On 04/04/2018 06:16 PM, Andreas Krebbel wrote:
On 10/03/2017 12:23 AM, Jeff Law wrote:
On 09/20/2017 12:04 PM, Martin Sebor wrote:
On 09/19/2017 03:00 PM, Joseph Myers wrote:
On Tue, 19 Sep 2017, Martin Sebor wrote:
In general, the data
On 04/04/2018 06:16 PM, Andreas Krebbel wrote:
> On 10/03/2017 12:23 AM, Jeff Law wrote:
>> On 09/20/2017 12:04 PM, Martin Sebor wrote:
>>> On 09/19/2017 03:00 PM, Joseph Myers wrote:
On Tue, 19 Sep 2017, Martin Sebor wrote:
>> In general, the data structures where you need to ensure
On 10/03/2017 12:23 AM, Jeff Law wrote:
> On 09/20/2017 12:04 PM, Martin Sebor wrote:
>> On 09/19/2017 03:00 PM, Joseph Myers wrote:
>>> On Tue, 19 Sep 2017, Martin Sebor wrote:
>>>
> In general, the data structures where you need to ensure manually that if
>
> attribute A is listed in
On 09/20/2017 12:04 PM, Martin Sebor wrote:
> On 09/19/2017 03:00 PM, Joseph Myers wrote:
>> On Tue, 19 Sep 2017, Martin Sebor wrote:
>>
In general, the data structures where you need to ensure manually that if
attribute A is listed in EXCL for B, then attribute B is also listed in
On 09/19/2017 03:00 PM, Joseph Myers wrote:
On Tue, 19 Sep 2017, Martin Sebor wrote:
In general, the data structures where you need to ensure manually that if
attribute A is listed in EXCL for B, then attribute B is also listed in
EXCL for A, seem concerning. I'd expect either data structures
On Tue, 19 Sep 2017, Martin Sebor wrote:
> > In general, the data structures where you need to ensure manually that if
> > attribute A is listed in EXCL for B, then attribute B is also listed in
> > EXCL for A, seem concerning. I'd expect either data structures that make
> > such asymmetry
On 09/12/2017 11:06 AM, Jeff Law wrote:
On 08/17/2017 10:03 AM, Martin Sebor wrote:
First, there is the risk that someone will write code based
on the pure declaration even if there's no intervening call
to the function between it and the const one. Code tends to
be sloppy, and it's also not
On 09/06/2017 05:30 PM, Joseph Myers wrote:
On Thu, 17 Aug 2017, Martin Sebor wrote:
+/* Check LAST_DECL and NODE of the same symbol for attributes that are
+ recorded in EXCL to be mutually exclusive with ATTRNAME, diagnose
+ them, and return true if any have been found. NODE can be a
On 08/17/2017 10:03 AM, Martin Sebor wrote:
>
> First, there is the risk that someone will write code based
> on the pure declaration even if there's no intervening call
> to the function between it and the const one. Code tends to
> be sloppy, and it's also not uncommon to declare the same
>
On 08/09/2017 01:55 PM, Joseph Myers wrote:
> On Wed, 9 Aug 2017, Martin Sebor wrote:
>
>> the same function with the other of this pair attributes. I'd
>> also be okay with not diagnosing this combination if I could
>> convince myself that it's safe (or can be made safe) and treated
>>
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
On Thu, 17 Aug 2017, Martin Sebor wrote:
> +/* Check LAST_DECL and NODE of the same symbol for attributes that are
> + recorded in EXCL to be mutually exclusive with ATTRNAME, diagnose
> + them, and return true if any have been found. NODE can be a DECL
> + or a TYPE. */
> +
> +static
Ping: https://gcc.gnu.org/ml/gcc-patches/2017-08/msg01087.html
On 08/24/2017 02:43 PM, Martin Sebor wrote:
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:
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:
Attached is an updated patch with just the minor editorial
tweaks for the issues pointed out by Marek (stray comments
and spaces), and with the C++ and libstdc++ bits removed
and posted separately. I also added some text to the manual
to clarify the const/pure effects.
I thought quite a bit
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
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
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 is correct. Any function with the
On 08/09/2017 01:55 PM, Joseph Myers wrote:
On Wed, 9 Aug 2017, Martin Sebor wrote:
the same function with the other of this pair attributes. I'd
also be okay with not diagnosing this combination if I could
convince myself that it's safe (or can be made safe) and treated
consistently.
I'd
On Wed, 9 Aug 2017, Martin Sebor wrote:
> the same function with the other of this pair attributes. I'd
> also be okay with not diagnosing this combination if I could
> convince myself that it's safe (or can be made safe) and treated
> consistently.
I'd expect it to be safe; it might simply
On 08/09/2017 11:13 AM, Joseph Myers wrote:
On Wed, 9 Aug 2017, Martin Sebor wrote:
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/ssa-ccp-2.c
b/gcc/testsuite/gcc.dg/tree-ssa/ssa-ccp-2.c
index 146b76c..58a4742 100644
--- a/gcc/testsuite/gcc.dg/tree-ssa/ssa-ccp-2.c
+++
On Wed, 9 Aug 2017, Martin Sebor wrote:
> > > diff --git a/gcc/testsuite/gcc.dg/tree-ssa/ssa-ccp-2.c
> > > b/gcc/testsuite/gcc.dg/tree-ssa/ssa-ccp-2.c
> > > index 146b76c..58a4742 100644
> > > --- a/gcc/testsuite/gcc.dg/tree-ssa/ssa-ccp-2.c
> > > +++ b/gcc/testsuite/gcc.dg/tree-ssa/ssa-ccp-2.c
>
On 08/09/2017 05:53 AM, Marek Polacek wrote:
(Not a proper review really.)
On Tue, Aug 08, 2017 at 10:13:07AM -0600, Martin Sebor wrote:
@@ -490,7 +583,9 @@ decl_attributes (tree *node, tree attributes, int flags)
| (int) ATTR_FLAG_ARRAY_NEXT))
{
(Not a proper review really.)
On Tue, Aug 08, 2017 at 10:13:07AM -0600, Martin Sebor wrote:
> @@ -490,7 +583,9 @@ decl_attributes (tree *node, tree attributes, int flags)
> | (int) ATTR_FLAG_ARRAY_NEXT))
> {
> /* Pass on this attribute to be tried again.
27 matches
Mail list logo
