OK, thanks.
On Wed, Dec 14, 2016 at 12:01 PM, Marek Polacek wrote:
> On Wed, Dec 14, 2016 at 11:30:17AM -0500, Jason Merrill wrote:
>> On Wed, Dec 14, 2016 at 10:39 AM, Marek Polacek wrote:
>> > + if (TREE_CODE (type) == ARRAY_TYPE
>> > + &&
On Wed, Dec 14, 2016 at 11:30:17AM -0500, Jason Merrill wrote:
> On Wed, Dec 14, 2016 at 10:39 AM, Marek Polacek wrote:
> > + if (TREE_CODE (type) == ARRAY_TYPE
> > + && TYPE_DOMAIN (type) == NULL_TREE
> > + && init != NULL_TREE)
> > + error_at
On Wed, Dec 14, 2016 at 10:39 AM, Marek Polacek wrote:
> + if (TREE_CODE (type) == ARRAY_TYPE
> + && TYPE_DOMAIN (type) == NULL_TREE
> + && init != NULL_TREE)
> + error_at (DECL_SOURCE_LOCATION (current_function_decl),
> + "member
On Wed, Dec 14, 2016 at 09:04:01AM -0500, Jason Merrill wrote:
> On Wed, Dec 14, 2016 at 8:16 AM, Marek Polacek wrote:
> > + if (TREE_CODE (type) == ARRAY_TYPE
> > + && TYPE_DOMAIN (type) == NULL_TREE
> > + && init != NULL_TREE)
> > + error_at
On Wed, Dec 14, 2016 at 8:16 AM, Marek Polacek wrote:
> + if (TREE_CODE (type) == ARRAY_TYPE
> + && TYPE_DOMAIN (type) == NULL_TREE
> + && init != NULL_TREE)
> + error_at (DECL_SOURCE_LOCATION (member),
> + "initialization of a
On Thu, Dec 08, 2016 at 02:56:56PM -0500, Nathan Sidwell wrote:
> On 12/08/2016 01:05 PM, Jason Merrill wrote:
> > If the problem is the member initializer, we can diagnose that
> > directly rather than wait until we're in a constructor.
>
> What about:
> struct Foo {
> int a;
> char ary[];
> Foo
On 12/13/2016 02:32 PM, Jason Merrill wrote:
On 12/13/2016 03:25 PM, Martin Sebor wrote:
On 12/13/2016 12:06 PM, Jason Merrill wrote:
On 12/09/2016 07:46 PM, Martin Sebor wrote:
On 12/09/2016 02:49 PM, Jason Merrill wrote:
On Fri, Dec 9, 2016 at 11:33 AM, Martin Sebor
On 12/13/2016 03:25 PM, Martin Sebor wrote:
On 12/13/2016 12:06 PM, Jason Merrill wrote:
On 12/09/2016 07:46 PM, Martin Sebor wrote:
On 12/09/2016 02:49 PM, Jason Merrill wrote:
On Fri, Dec 9, 2016 at 11:33 AM, Martin Sebor wrote:
For flexible array members, because
On 12/13/2016 12:06 PM, Jason Merrill wrote:
On 12/09/2016 07:46 PM, Martin Sebor wrote:
On 12/09/2016 02:49 PM, Jason Merrill wrote:
On Fri, Dec 9, 2016 at 11:33 AM, Martin Sebor wrote:
For flexible array members, because they're not in C++, we get to
make up the rules
On 12/09/2016 07:46 PM, Martin Sebor wrote:
On 12/09/2016 02:49 PM, Jason Merrill wrote:
On Fri, Dec 9, 2016 at 11:33 AM, Martin Sebor wrote:
For flexible array members, because they're not in C++, we get to
make up the rules that make the most sense to us. IMO, they should
On 12/09/2016 02:49 PM, Jason Merrill wrote:
On Fri, Dec 9, 2016 at 11:33 AM, Martin Sebor wrote:
For flexible array members, because they're not in C++, we get to
make up the rules that make the most sense to us. IMO, they should
fit in well with the rest of the language.
On Fri, Dec 9, 2016 at 11:33 AM, Martin Sebor wrote:
> For flexible array members, because they're not in C++, we get to
> make up the rules that make the most sense to us. IMO, they should
> fit in well with the rest of the language.
I disagree; we should support C code, but
On 12/09/2016 08:34 AM, Nathan Sidwell wrote:
On 12/09/2016 10:18 AM, Martin Sebor wrote:
On 12/09/2016 08:09 AM, Jakub Jelinek wrote:
On Fri, Dec 09, 2016 at 08:04:11AM -0700, Martin Sebor wrote:
then (IMO) so is this:
struct Foo {
int a;
char ary[];
Foo () : ary ("bob") {}
On 12/09/2016 10:18 AM, Martin Sebor wrote:
On 12/09/2016 08:09 AM, Jakub Jelinek wrote:
On Fri, Dec 09, 2016 at 08:04:11AM -0700, Martin Sebor wrote:
then (IMO) so is this:
struct Foo {
int a;
char ary[];
Foo () : ary ("bob") {}
};
So what does this mean? Assume that the
On 12/09/2016 08:09 AM, Jakub Jelinek wrote:
On Fri, Dec 09, 2016 at 08:04:11AM -0700, Martin Sebor wrote:
I'm not sure I understand what you mean. Since the following is
valid and meaningful (i.e., initializes the array with the elements
of the string):
struct Foo {
int a;
char
On Fri, Dec 09, 2016 at 08:04:11AM -0700, Martin Sebor wrote:
> I'm not sure I understand what you mean. Since the following is
> valid and meaningful (i.e., initializes the array with the elements
> of the string):
>
> struct Foo {
>int a;
>char ary[4];
>Foo () : ary ("bob") {}
>
On 12/09/2016 05:34 AM, Nathan Sidwell wrote:
On 12/08/2016 03:42 PM, Martin Sebor wrote:
On 12/08/2016 01:28 PM, Marek Polacek wrote:
On Thu, Dec 08, 2016 at 02:56:56PM -0500, Nathan Sidwell wrote:
struct Foo {
int a;
char ary[];
Foo () : ary ("bob"){}
Clang accepts this test case
On 12/08/2016 03:42 PM, Martin Sebor wrote:
On 12/08/2016 01:28 PM, Marek Polacek wrote:
On Thu, Dec 08, 2016 at 02:56:56PM -0500, Nathan Sidwell wrote:
struct Foo {
int a;
char ary[];
Foo () : ary ("bob"){}
Clang accepts this test case although it does reject the originally
submitted
On Thu, Dec 08, 2016 at 01:42:44PM -0700, Martin Sebor wrote:
> On 12/08/2016 01:28 PM, Marek Polacek wrote:
> > On Thu, Dec 08, 2016 at 02:56:56PM -0500, Nathan Sidwell wrote:
> > > On 12/08/2016 01:05 PM, Jason Merrill wrote:
> > > > If the problem is the member initializer, we can diagnose that
On 12/08/2016 01:28 PM, Marek Polacek wrote:
On Thu, Dec 08, 2016 at 02:56:56PM -0500, Nathan Sidwell wrote:
On 12/08/2016 01:05 PM, Jason Merrill wrote:
If the problem is the member initializer, we can diagnose that
directly rather than wait until we're in a constructor.
What about:
struct
On Thu, Dec 08, 2016 at 02:56:56PM -0500, Nathan Sidwell wrote:
> On 12/08/2016 01:05 PM, Jason Merrill wrote:
> > If the problem is the member initializer, we can diagnose that
> > directly rather than wait until we're in a constructor.
>
> What about:
> struct Foo {
> int a;
> char ary[];
> Foo
On 12/08/2016 01:05 PM, Jason Merrill wrote:
If the problem is the member initializer, we can diagnose that
directly rather than wait until we're in a constructor.
What about:
struct Foo {
int a;
char ary[];
Foo () : ary ("bob"){}
};
? That ICEs in the same way.
nathan
--
Nathan Sidwell
If the problem is the member initializer, we can diagnose that
directly rather than wait until we're in a constructor.
On Wed, Dec 7, 2016 at 3:26 PM, Marek Polacek wrote:
> We were crashing in finish_expr_stmt here:
> 676 /* If we ran into a problem, make sure we
We were crashing in finish_expr_stmt here:
676 /* If we ran into a problem, make sure we complained. */
677 gcc_assert (expr != error_mark_node || seen_error ());
Well, we ran into a problem, but never raised an error. The problem was that
we couldn't determine the max index of the
24 matches
Mail list logo