On Tue, Feb 27, 2018 at 7:52 PM, Martin Sebor wrote:
> There are many places in the C++ front-end where a string
> enclosed in G_() is assigned to a pointer and later used
> in a diagnostic call. Is there something different about
> the usage I introduced that makes it unsuitable for
> translatio
On 02/28/2018 02:51 AM, Jakub Jelinek wrote:
On Mon, Feb 26, 2018 at 09:19:56PM -0700, Martin Sebor wrote:
PR c++/83871
PR c++/83503
* g++.dg/ext/attr-const.C: New test.
* g++.dg/ext/attr-pure.C: New test.
I've tried to fix these 2 tests with following patch, wi
On Mon, Feb 26, 2018 at 09:19:56PM -0700, Martin Sebor wrote:
> PR c++/83871
> PR c++/83503
> * g++.dg/ext/attr-const.C: New test.
> * g++.dg/ext/attr-pure.C: New test.
I've tried to fix these 2 tests with following patch, without
-fdump-tree-optimized all the scan-tree-dum
On Mon, Feb 26, 2018 at 09:19:56PM -0700, Martin Sebor wrote:
> PR c++/83871
> PR c++/83503
> * g++.dg/Wmissing-attributes.C: New test.
> * g++.dg/ext/attr-const-pure.C: New test.
> * g++.dg/ext/attr-const.C: New test.
> * g++.dg/ext/attr-deprecated-2.C: New test
On 02/27/2018 04:44 PM, Jakub Jelinek wrote:
On Mon, Feb 26, 2018 at 09:19:56PM -0700, Martin Sebor wrote:
+ /* Put together a list of the black listed attributes that the primary
+ template is declared with that the specialization is not, in case
+ it's not apparent from the most recen
On Mon, Feb 26, 2018 at 09:19:56PM -0700, Martin Sebor wrote:
> + /* Put together a list of the black listed attributes that the primary
> + template is declared with that the specialization is not, in case
> + it's not apparent from the most recent declaration of the primary. */
> + uns
On 02/27/2018 04:21 PM, David Edelsohn wrote:
Martin,
This patch broke bootstrap.
diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 42fd872..9c2e5e6 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -24,6 +24,7 @@ along with GCC; see the file COPYING3. If not see
all methods must be provided in h
Martin,
This patch broke bootstrap.
diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 42fd872..9c2e5e6 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -24,6 +24,7 @@ along with GCC; see the file COPYING3. If not see
all methods must be provided in header files; can't use a source
file that
On 02/26/2018 11:19 PM, Martin Sebor wrote:
While reviewing other related bugs I noticed 83502. This patch
doesn't fix the first test case in the bug (attribute noinline
vs always_inline). Somehow those are still copied from
the primary to the specialization and can cause conflicts.
Hmm, that
While reviewing other related bugs I noticed 83502. This patch
doesn't fix the first test case in the bug (attribute noinline
vs always_inline). Somehow those are still copied from
the primary to the specialization and can cause conflicts.
Hmm, that's odd. Why is that?
Because duplicate_dec
On 02/21/2018 06:03 PM, Martin Sebor wrote:
On 02/13/2018 11:33 AM, Jason Merrill wrote:
On Tue, Feb 13, 2018 at 1:00 PM, Martin Sebor wrote:
On 02/13/2018 07:47 AM, Jason Merrill wrote:
On Mon, Feb 12, 2018 at 6:39 PM, Martin Sebor wrote:
I really don't think it's helpful to try to force
On 02/13/2018 11:33 AM, Jason Merrill wrote:
On Tue, Feb 13, 2018 at 1:00 PM, Martin Sebor wrote:
On 02/13/2018 07:47 AM, Jason Merrill wrote:
On Mon, Feb 12, 2018 at 6:39 PM, Martin Sebor wrote:
I really don't think it's helpful to try to force noreturn
to match between the primary and it
On Tue, Feb 13, 2018 at 1:00 PM, Martin Sebor wrote:
> On 02/13/2018 07:47 AM, Jason Merrill wrote:
>>
>> On Mon, Feb 12, 2018 at 6:39 PM, Martin Sebor wrote:
>>>
>>> I really don't think it's helpful to try to force noreturn
>>> to match between the primary and its specializations.
>>
>> I conti
On 02/13/2018 07:47 AM, Jason Merrill wrote:
On Mon, Feb 12, 2018 at 6:39 PM, Martin Sebor wrote:
I really don't think it's helpful to try to force noreturn
to match between the primary and its specializations.
I continue to disagree.
Can you explain what use case you are concerned about th
On 02/13/2018 08:59 AM, Michael Matz wrote:
Hi,
On Mon, 12 Feb 2018, Martin Sebor wrote:
Removing noreturn from the whitelist means having to prevent
the attribute from causing conflicts with the attributes on
the blacklist. E.g., in this:
template [[malloc]] void* allocate (int);
temp
Hi,
On Mon, 12 Feb 2018, Martin Sebor wrote:
> >> Removing noreturn from the whitelist means having to prevent
> >> the attribute from causing conflicts with the attributes on
> >> the blacklist. E.g., in this:
> >>
> >> template [[malloc]] void* allocate (int);
> >>
> >> template <> [[nore
On Mon, Feb 12, 2018 at 6:39 PM, Martin Sebor wrote:
> I really don't think it's helpful to try to force noreturn
> to match between the primary and its specializations.
I continue to disagree.
Jason
On 02/12/2018 10:11 AM, Jason Merrill wrote:
On Mon, Feb 12, 2018 at 11:59 AM, Martin Sebor wrote:
On 02/12/2018 09:30 AM, Jason Merrill wrote:
On Fri, Feb 9, 2018 at 6:57 PM, Martin Sebor wrote:
On 02/09/2018 12:52 PM, Jason Merrill wrote:
On 02/08/2018 04:52 PM, Martin Sebor wrote:
On Mon, Feb 12, 2018 at 11:59 AM, Martin Sebor wrote:
> On 02/12/2018 09:30 AM, Jason Merrill wrote:
>>
>> On Fri, Feb 9, 2018 at 6:57 PM, Martin Sebor wrote:
>>>
>>> On 02/09/2018 12:52 PM, Jason Merrill wrote:
On 02/08/2018 04:52 PM, Martin Sebor wrote:
>
>
> I took me a w
On 02/12/2018 09:30 AM, Jason Merrill wrote:
On Fri, Feb 9, 2018 at 6:57 PM, Martin Sebor wrote:
On 02/09/2018 12:52 PM, Jason Merrill wrote:
On 02/08/2018 04:52 PM, Martin Sebor wrote:
I took me a while to find DECL_TEMPLATE_RESULT. Hopefully
that's the right way to get the primary from a
On Fri, Feb 9, 2018 at 6:57 PM, Martin Sebor wrote:
> On 02/09/2018 12:52 PM, Jason Merrill wrote:
>> On 02/08/2018 04:52 PM, Martin Sebor wrote:
>>>
>>> I took me a while to find DECL_TEMPLATE_RESULT. Hopefully
>>> that's the right way to get the primary from a TEMPLATE_DECL.
>>
>> Yes.
>>
>
On 02/09/2018 12:52 PM, Jason Merrill wrote:
On 02/08/2018 04:52 PM, Martin Sebor wrote:
I took me a while to find DECL_TEMPLATE_RESULT. Hopefully
that's the right way to get the primary from a TEMPLATE_DECL.
Yes.
Attached is an updated patch. It hasn't gone through full
testing yet but pl
On 02/08/2018 04:52 PM, Martin Sebor wrote:
I took me a while to find DECL_TEMPLATE_RESULT. Hopefully
that's the right way to get the primary from a TEMPLATE_DECL.
Yes.
Attached is an updated patch. It hasn't gone through full
testing yet but please let me know if you'd like me to make
some
__attribute__ ((nothrow))? The patch includes a test case with
wrong-code due to inheriting the attribute. With exception
specifications having to match between the primary and its
specializations it's the only way to make them different.
I've left this unchanged but let me know if I'm missing
s
On 02/06/2018 11:01 PM, Martin Sebor wrote:
On 02/05/2018 02:52 PM, Jason Merrill wrote:
On 02/04/2018 07:07 PM, Martin Sebor wrote:
To resolve the underlying root cause of the P1 bug c++/83503
- bogus -Wattributes for const and pure on function template
specialization, that we discussed last w
On 02/05/2018 02:52 PM, Jason Merrill wrote:
On 02/04/2018 07:07 PM, Martin Sebor wrote:
To resolve the underlying root cause of the P1 bug c++/83503
- bogus -Wattributes for const and pure on function template
specialization, that we discussed last week, I've taken a stab
at making the change t
On 02/05/2018 05:55 PM, Joseph Myers wrote:
On Mon, 5 Feb 2018, Martin Sebor wrote:
On 02/05/2018 04:44 PM, Joseph Myers wrote:
On Sun, 4 Feb 2018, Martin Sebor wrote:
We've talked about (2) in the past (bug 71463) but this seems
like an opportunity to revisit it and (hopefully) make a chang
On Mon, 5 Feb 2018, Martin Sebor wrote:
> On 02/05/2018 04:44 PM, Joseph Myers wrote:
> > On Sun, 4 Feb 2018, Martin Sebor wrote:
> >
> > > We've talked about (2) in the past (bug 71463) but this seems
> > > like an opportunity to revisit it and (hopefully) make a change
> > > to treat these the
On 02/05/2018 04:44 PM, Joseph Myers wrote:
On Sun, 4 Feb 2018, Martin Sebor wrote:
We've talked about (2) in the past (bug 71463) but this seems
like an opportunity to revisit it and (hopefully) make a change
to treat these the same as all other function attributes rather
than type attributes.
On Sun, 4 Feb 2018, Martin Sebor wrote:
> We've talked about (2) in the past (bug 71463) but this seems
> like an opportunity to revisit it and (hopefully) make a change
> to treat these the same as all other function attributes rather
> than type attributes. Besides fixing the wrong code bugs an
On 02/04/2018 07:07 PM, Martin Sebor wrote:
To resolve the underlying root cause of the P1 bug c++/83503
- bogus -Wattributes for const and pure on function template
specialization, that we discussed last week, I've taken a stab
at making the change to avoid applying primary template's
attributes
31 matches
Mail list logo
