On Wed, 5 Feb 2014, Andreas Schwab wrote:
Marc Glisse marc.gli...@inria.fr 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
Marc Glisse marc.gli...@inria.fr 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
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 not
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
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
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).
Are there
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
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, 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
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
Marc Glisse marc.gli...@inria.fr 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
On Wed, 5 Feb 2014, Andreas Schwab wrote:
Marc Glisse marc.gli...@inria.fr 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
Marc Glisse marc.gli...@inria.fr 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
Marc Glisse marc.gli...@inria.fr 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
On Tue, 4 Feb 2014, Andreas Schwab wrote:
Marc Glisse marc.gli...@inria.fr writes:
Index: gcc/testsuite/g++.dg/cpp0x/constexpr-attribute2.C
===
--- gcc/testsuite/g++.dg/cpp0x/constexpr-attribute2.C (revision 0)
+++
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
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,
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 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 not
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
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
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
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 is basically copied from the constructor attribute. The C
front-end is much less forgiving than the C++
26 matches
Mail list logo
