On Wed, 5 Feb 2014, Andreas Schwab wrote:
Marc Glisse writes:
On Wed, 5 Feb 2014, Andreas Schwab wrote:
Wrt. the function decl it should probably just be changed to a variable
decl. Alignments on function decls are kind of exotic.
Good idea. How about this patch then?
LGTM.
Done at r
Marc Glisse writes:
> On Wed, 5 Feb 2014, Andreas Schwab wrote:
>
>> Wrt. the function decl it should probably just be changed to a variable
>> decl. Alignments on function decls are kind of exotic.
>
> Good idea. How about this patch then?
LGTM.
Andreas.
--
Andreas Schwab, SUSE Labs, sch...
On Wed, 5 Feb 2014, Andreas Schwab wrote:
Marc Glisse writes:
On Wed, 5 Feb 2014, Dominique Dhumieres wrote:
I'll give it a day (it can easily be changed again later).
IMO it would be better (more general) to use a dg-require-effective-target
with the corresponding test(s) in target-suppo
Marc Glisse writes:
> On Wed, 5 Feb 2014, Dominique Dhumieres wrote:
>
>>> I'll give it a day (it can easily be changed again later).
>>
>> IMO it would be better (more general) to use a dg-require-effective-target
>> with the corresponding test(s) in target-supports-dg.exp.
>
> But which tests?
On Wed, Feb 05, 2014 at 10:43:24AM +0100, Marc Glisse wrote:
> On Wed, 5 Feb 2014, Dominique Dhumieres wrote:
>
> >>I'll give it a day (it can easily be changed again later).
> >
> >IMO it would be better (more general) to use a dg-require-effective-target
> >with the corresponding test(s) in targ
On Wed, 5 Feb 2014, Dominique Dhumieres wrote:
I'll give it a day (it can easily be changed again later).
IMO it would be better (more general) to use a dg-require-effective-target
with the corresponding test(s) in target-supports-dg.exp.
But which tests? One for over/under alignment of func
> I'll give it a day (it can easily be changed again later).
IMO it would be better (more general) to use a dg-require-effective-target
with the corresponding test(s) in target-supports-dg.exp.
Dominique
On Wed, 5 Feb 2014, Jakub Jelinek wrote:
On Wed, Feb 05, 2014 at 09:58:28AM +0100, Marc Glisse wrote:
On Wed, 5 Feb 2014, Jakub Jelinek wrote:
On Wed, Feb 05, 2014 at 09:28:16AM +0100, Andreas Schwab wrote:
Feel free to replace 8 with 16 in the initialization of size (you can
commit it as ob
On Wed, Feb 05, 2014 at 09:58:28AM +0100, Marc Glisse wrote:
> On Wed, 5 Feb 2014, Jakub Jelinek wrote:
>
> >On Wed, Feb 05, 2014 at 09:28:16AM +0100, Andreas Schwab wrote:
> >>>Feel free to replace 8 with 16 in the initialization of size (you can
> >>>commit it as obvious if it works for you).
>
On Wed, 5 Feb 2014, Jakub Jelinek wrote:
On Wed, Feb 05, 2014 at 09:28:16AM +0100, Andreas Schwab wrote:
Feel free to replace 8 with 16 in the initialization of size (you can
commit it as obvious if it works for you).
Are there any targets that may reject an overaligned function decl?
I thi
The test g++.dg/cpp0x/constexpr-attribute2.C fails on darwin
with
FAIL: g++.dg/cpp0x/constexpr-attribute2.C (test for excess errors)
Excess errors:
/opt/gcc/_clean/gcc/testsuite/g++.dg/cpp0x/constexpr-attribute2.C:9:40: error:
'init_priority' attribute is not supported on this platform
/opt/gcc/_
On Wed, Feb 05, 2014 at 09:28:16AM +0100, Andreas Schwab wrote:
> > Feel free to replace 8 with 16 in the initialization of size (you can
> > commit it as obvious if it works for you).
>
> Are there any targets that may reject an overaligned function decl?
I think that is very well possible. Why
Marc Glisse writes:
>> /usr/local/gcc/gcc-20140204/gcc/testsuite/g++.dg/cpp0x/constexpr-attribute2.C:32:6:
>> error: alignment for 'void g()' must be at least 16
>
> (I don't know why we error out for this, align specifies a minimal
> alignment, if it ends up more aligned, that's fine)
Probably
On Tue, 4 Feb 2014, Andreas Schwab wrote:
Marc Glisse writes:
Index: gcc/testsuite/g++.dg/cpp0x/constexpr-attribute2.C
===
--- gcc/testsuite/g++.dg/cpp0x/constexpr-attribute2.C (revision 0)
+++ gcc/testsuite/g++.dg/cpp0x/conste
Marc Glisse writes:
> Index: gcc/testsuite/g++.dg/cpp0x/constexpr-attribute2.C
> ===
> --- gcc/testsuite/g++.dg/cpp0x/constexpr-attribute2.C (revision 0)
> +++ gcc/testsuite/g++.dg/cpp0x/constexpr-attribute2.C (working copy)
> @@ -0,
On 02/03/2014 12:46 PM, Marc Glisse wrote:
The C version of default_conversion does not convert a function_decl to
a pointer (that's done earlier, during parsing), it ICEs.
Ah, I see. The patch is OK, then.
Jason
On Mon, 3 Feb 2014, Jason Merrill wrote:
On 01/18/2014 05:33 PM, Marc Glisse wrote:
So when we have: __attribute__((nonnull(bar,bar)))
the parser will keep bar as an identifier for the first argument, but
parse the second one as an expr-list and thus find the associated
function_decl.
OK, tha
On 01/18/2014 05:33 PM, Marc Glisse wrote:
So when we have: __attribute__((nonnull(bar,bar)))
the parser will keep bar as an identifier for the first argument, but
parse the second one as an expr-list and thus find the associated
function_decl.
OK, that makes sense. But why do we need to handl
On Sun, 2 Feb 2014, Marc Glisse wrote:
> An alternative could be to have a helper function that does nothing in C and
> calls default_conversion in C++. Or make the C version of default_conversion
> return its argument unchanged instead of asserting when it sees an unexpected
> tree.
Well, in pri
On Sun, 2 Feb 2014, Joseph S. Myers wrote:
On Sat, 1 Feb 2014, Marc Glisse wrote:
Ping
http://gcc.gnu.org/ml/gcc-patches/2014-01/msg01168.html
As I understand it, this is only relevant to C++ (in C you should have an
INTEGER_CST here, and if you don't then default_conversion won't give you
o
On Sat, 1 Feb 2014, Marc Glisse wrote:
> Ping
> http://gcc.gnu.org/ml/gcc-patches/2014-01/msg01168.html
As I understand it, this is only relevant to C++ (in C you should have an
INTEGER_CST here, and if you don't then default_conversion won't give you
one), so would best be reviewed by Jason no
Ping
http://gcc.gnu.org/ml/gcc-patches/2014-01/msg01168.html
(conversation starts at
http://gcc.gnu.org/ml/gcc-patches/2013-11/msg03822.html )
On Sat, 18 Jan 2014, Marc Glisse wrote:
On Thu, 2 Jan 2014, Jason Merrill wrote:
On 11/30/2013 05:41 AM, Marc Glisse wrote:
for some reason one of
On Thu, 2 Jan 2014, Jason Merrill wrote:
On 11/30/2013 05:41 AM, Marc Glisse wrote:
for some reason one of the attributes can see a FUNCTION_DECL where others
see an IDENTIFIER_NODE, I didn't try to understand why and just added that
check to the code.
Please do check.
In the C front-end (
On 11/30/2013 05:41 AM, Marc Glisse wrote:
for some reason one of the attributes can see a FUNCTION_DECL where others see
an IDENTIFIER_NODE, I didn't try to understand why and just added that check to
the code.
Please do check.
+ if (size && size != error_mark_node && TREE_CODE (size) !=
Ping http://gcc.gnu.org/ml/gcc-patches/2013-11/msg03822.html
On Sat, 30 Nov 2013, Marc Glisse wrote:
Hello,
we currently reject:
constexpr int s = 32;
typedef double VEC __attribute__ ((__vector_size__ (s)));
and similarly for other attributes, while we accept s+0 or (int)s, etc. The
code i
25 matches
Mail list logo
