On Tue, Mar 24, 2015 at 01:14:50AM -0400, Jason Merrill wrote:
Here's my shot at this.
The problem is that the type is considered dependent in a template but is
not actually dependent, so we can see the exact same type outside a template
Yeah, I think this is true...
and it's not dependent.
On Tue, Mar 31, 2015 at 02:32:32PM +0200, Marek Polacek wrote:
On Tue, Mar 31, 2015 at 02:25:14PM +0200, Kai Tietz wrote:
Hi,
I had tried same approach as Marek. For me it solved the PR, but
caused other regressions on boostrap. So I dropped the way via
dependent_type_p.
Well,
2015-03-31 14:34 GMT+02:00 Marek Polacek pola...@redhat.com:
On Tue, Mar 31, 2015 at 02:32:32PM +0200, Marek Polacek wrote:
On Tue, Mar 31, 2015 at 02:25:14PM +0200, Kai Tietz wrote:
Hi,
I had tried same approach as Marek. For me it solved the PR, but
caused other regressions on
Hi,
I had tried same approach as Marek. For me it solved the PR, but
caused other regressions on boostrap. So I dropped the way via
dependent_type_p.
Well, this bootstrap-issue might be caused by some local changes I had
forgot to remove, but I doubt it.
Marek, have you tried to do a boostrap
On Tue, Mar 31, 2015 at 02:25:14PM +0200, Kai Tietz wrote:
Hi,
I had tried same approach as Marek. For me it solved the PR, but
caused other regressions on boostrap. So I dropped the way via
dependent_type_p.
Well, this bootstrap-issue might be caused by some local changes I had
forgot
OK, thanks.
Jason
On Tue, Mar 31, 2015 at 02:32:32PM +0200, Marek Polacek wrote:
Of course, with --enable-languages=all. I'll re-run the bootstrap with more
languages enabled, though.
--enable-languages=all,obj-c++,go bootstrap passed again on x86_64 and ppc64.
Marek
On 03/20/2015 10:53 AM, Kai Tietz wrote:
* tree.c (strip_typedefs): Ignore alignment
difference during processing template.
+ || (processing_template_decl
+ TYPE_ALIGN (t) != TYPE_ALIGN (result)))
Your change is actually ignoring alignment differences when *not*
Hello,
the problem here is that for cases of vla-array-types, the types don't
get finally layouted in build_cplus_array_type. So the type-alignment
isn't set in such cases for the resulting type.
ChangeLog
2015-03-20 Kai Tietz kti...@redhat.com
PR c++/65390
* tree.c
On 03/16/2015 03:22 PM, Kai Tietz wrote:
2015-03-16 19:07 GMT+01:00 Jason Merrill ja...@redhat.com:
If there is an alignment mismatch without user intervention, there is a
problem, we can't just ignore it.
Where we run into trouble is with array types where the version built
earlier has not
2015-03-17 13:36 GMT+01:00 Jason Merrill ja...@redhat.com:
On 03/16/2015 03:22 PM, Kai Tietz wrote:
2015-03-16 19:07 GMT+01:00 Jason Merrill ja...@redhat.com:
If there is an alignment mismatch without user intervention, there is a
problem, we can't just ignore it.
Where we run into trouble
Hi,
this patch avoids the attempt to create user-aligned-type for variants
original and main-variants type-alignment differ and original type
isn't user-aligned.
Not sure if this is the preferred variant, we could create for such
cases an aligned-type without setting user-align.
But as this
If there is an alignment mismatch without user intervention, there is a
problem, we can't just ignore it.
Where we run into trouble is with array types where the version built
earlier has not been laid out yet but the new one has been. I've been
trying to deal with that by making sure that
2015-03-16 19:07 GMT+01:00 Jason Merrill ja...@redhat.com:
If there is an alignment mismatch without user intervention, there is a
problem, we can't just ignore it.
Where we run into trouble is with array types where the version built
earlier has not been laid out yet but the new one has
14 matches
Mail list logo
