Re: [PATCH] [PR c++/85039] no type definitions in builtin offsetof

2018-04-13 Thread Jason Merrill
On Fri, Apr 13, 2018, 6:09 PM Alexandre Oliva wrote: > On Apr 11, 2018, Jason Merrill wrote: > > > I raised this issue with the C++ committee, and it seems that nobody > > expects defining a type here to work. So let's go back to your first > > patch,

Re: [PATCH] [PR c++/85039] no type definitions in builtin offsetof

2018-04-13 Thread Alexandre Oliva
On Apr 11, 2018, Jason Merrill wrote: > I raised this issue with the C++ committee, and it seems that nobody > expects defining a type here to work. So let's go back to your first > patch, removing the offending part of semicolon3.C. All right, here's the adjusted patch.

Re: [PATCH] [PR c++/85039] no type definitions in builtin offsetof

2018-04-11 Thread Jason Merrill
On Thu, Apr 5, 2018 at 9:33 AM, Jason Merrill wrote: > On Wed, Apr 4, 2018 at 12:25 PM, Alexandre Oliva wrote: >> On Apr 4, 2018, Jason Merrill wrote: >> >>> On Tue, Apr 3, 2018 at 11:25 PM, Alexandre Oliva wrote:

Re: [PATCH] [PR c++/85039] no type definitions in builtin offsetof

2018-04-05 Thread Jason Merrill
On Wed, Apr 4, 2018 at 12:25 PM, Alexandre Oliva wrote: > On Apr 4, 2018, Jason Merrill wrote: > >> On Tue, Apr 3, 2018 at 11:25 PM, Alexandre Oliva wrote: >>> I still think we could attempt to retain the extension as it is, parsing >>>

Re: [PATCH] [PR c++/85039] no type definitions in builtin offsetof

2018-04-04 Thread Alexandre Oliva
On Apr 4, 2018, Jason Merrill wrote: > On Tue, Apr 3, 2018 at 11:25 PM, Alexandre Oliva wrote: >> I still think we could attempt to retain the extension as it is, parsing >> types introduced in data member initializers within the scope of the >> class

Re: [PATCH] [PR c++/85039] no type definitions in builtin offsetof

2018-04-04 Thread Jason Merrill
On Tue, Apr 3, 2018 at 11:25 PM, Alexandre Oliva wrote: > On Apr 3, 2018, Alexandre Oliva wrote: > >> On Apr 2, 2018, Jason Merrill wrote: >>> On Sat, Mar 31, 2018 at 7:12 AM, Alexandre Oliva wrote: struct a {

Re: [PATCH] [PR c++/85039] no type definitions in builtin offsetof

2018-04-03 Thread Alexandre Oliva
On Apr 3, 2018, Alexandre Oliva wrote: > On Apr 2, 2018, Jason Merrill wrote: >> On Sat, Mar 31, 2018 at 7:12 AM, Alexandre Oliva wrote: >>> struct a { >>> static int const z, i = __builtin_offsetof(struct b { int j; }, j); >>> b c; >>>

Re: [PATCH] [PR c++/85039] no type definitions in builtin offsetof

2018-04-03 Thread Nathan Sidwell
On 04/02/2018 06:18 PM, Jason Merrill wrote: About d in the example, I'm not sure how you mean the global namespace is the current scope; we should be pushed into a when parsing the initializer for a::z. this may be related to the brokenness I encountered in 85046. We push member structs

Re: [PATCH] [PR c++/85039] no type definitions in builtin offsetof

2018-04-03 Thread Alexandre Oliva
On Apr 2, 2018, Jason Merrill wrote: > On Sat, Mar 31, 2018 at 7:12 AM, Alexandre Oliva wrote: >> struct a { >> static int const z, i = __builtin_offsetof(struct b { int j; }, j); >> b c; >> }; >> int const a::z = __builtin_offsetof(struct d { int k; },

Re: [PATCH] [PR c++/85039] no type definitions in builtin offsetof

2018-04-02 Thread Jason Merrill
On Sat, Mar 31, 2018 at 7:12 AM, Alexandre Oliva wrote: > On Mar 30, 2018, Jason Merrill wrote: > >> On Fri, Mar 30, 2018 at 3:55 AM, Alexandre Oliva wrote: >>> Types defined within a __builtin_offsetof argument don't always get >>>

Re: [PATCH] [PR c++/85039] no type definitions in builtin offsetof

2018-03-31 Thread Alexandre Oliva
On Mar 30, 2018, Jason Merrill wrote: > On Fri, Mar 30, 2018 at 3:55 AM, Alexandre Oliva wrote: >> Types defined within a __builtin_offsetof argument don't always get >> properly recorded as members of their context types >> I suppose this means I should

Re: [PATCH] [PR c++/85039] no type definitions in builtin offsetof

2018-03-30 Thread Jason Merrill
On Fri, Mar 30, 2018 at 3:55 AM, Alexandre Oliva wrote: > Types defined within a __builtin_offsetof argument don't always get > properly recorded as members of their context types, so if they're > anonymous, we may fail to assign them an anon type index for mangling > and ICE.