[Bug c++/94569] alignas(object) with a weaker (smaller) alignment than the alignas(type) of it's type compiles, inconsistent with the C++ standard

2020-07-02 Thread sinbal2l at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94569

--- Comment #10 from Inbal Levi  ---
Actually, you're right about the origin being [dcl.align]p5 here too, though
the test cases are different. 
Thanks.

[Bug c++/94569] alignas(object) with a weaker (smaller) alignment than the alignas(type) of it's type compiles, inconsistent with the C++ standard

2020-07-02 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94569

--- Comment #9 from Jonathan Wakely  ---
Both bugs are violations of [dcl.align] p5 though. The bug is not that GCC
doesn't follow [basic.align] p1 (it does) but that it allows alignas to weaken
the alignment later. GCC should not allow alignas to weaken alignment on any
declaration, whether a class declaration or variable declaration, and that's PR
65685. I've added a more complete testcase there, which includes alignas on
object declarations.

[Bug c++/94569] alignas(object) with a weaker (smaller) alignment than the alignas(type) of it's type compiles, inconsistent with the C++ standard

2020-07-02 Thread sinbal2l at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94569

--- Comment #8 from Inbal Levi  ---
See here: https://bugs.llvm.org/show_bug.cgi?id=45890

[Bug c++/94569] alignas(object) with a weaker (smaller) alignment than the alignas(type) of it's type compiles, inconsistent with the C++ standard

2020-07-02 Thread sinbal2l at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94569

--- Comment #7 from Inbal Levi  ---
Not exactly.

94594 is talking about object's members impose their alignment on the object's
type, whether this bug is talking about object type imposes its alignment on
every object of that type (notice that in the example here, unlike the one on
94594, there's no alignment of the members). (this restriction is located at: 

  [basic.align/1]

  [...] An object type imposes an alignment requirement on every object of that 
  type; stricter alignment can be requested using the alignment specifier.

as posted below in the comments, unfortunately, since I couldn't edit the bug)

(Though, since posting that bug, I realized that though the restriction should
hold, the querying part, which is alignof(object), should first be qualified in
the standard. There's a paper: P2152 :) )

[Bug c++/94569] alignas(object) with a weaker (smaller) alignment than the alignas(type) of it's type compiles, inconsistent with the C++ standard

2020-07-02 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94569

Jonathan Wakely  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|NEW |RESOLVED

--- Comment #6 from Jonathan Wakely  ---
This seems like another dup of PR 65685

*** This bug has been marked as a duplicate of bug 65685 ***

[Bug c++/94569] alignas(object) with a weaker (smaller) alignment than the alignas(type) of it's type compiles, inconsistent with the C++ standard

2020-05-09 Thread sinbal2l at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94569

--- Comment #5 from Inbal Levi  ---
Stumbled across another rule which might be relevant here is:

[basic.align/1]

[...] An object type imposes an alignment requirement on every object of that
type; stricter alignment can be requested using the alignment specifier
(9.12.2).

Inherited from the C standard, which results in an error for the following
code:

#include 
typedef struct U U;
struct U {
} __attribute__((aligned (32))); 

int main() {
_Alignas(16) U my_u; // alignas(obj) of a weaker alignment than the
type.
}

https://godbolt.org/z/tdEJgo

[Bug c++/94569] alignas(object) with a weaker (smaller) alignment than the alignas(type) of it's type compiles, inconsistent with the C++ standard

2020-04-14 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94569

Jonathan Wakely  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-04-14

[Bug c++/94569] alignas(object) with a weaker (smaller) alignment than the alignas(type) of it's type compiles, inconsistent with the C++ standard

2020-04-14 Thread richard-gccbugzilla at metafoo dot co.uk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94569

--- Comment #4 from Richard Smith  ---
(In reply to Richard Biener from comment #3)
> But isn't the alignas(32) also "appertaining to that entity"?

No. The alignas(32) appertains to the struct. This is specified in [class]/2:
"The optional attribute-specifier-seq appertains to the class".

[Bug c++/94569] alignas(object) with a weaker (smaller) alignment than the alignas(type) of it's type compiles, inconsistent with the C++ standard

2020-04-14 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94569

Richard Biener  changed:

   What|Removed |Added

   Keywords||accepts-invalid

--- Comment #3 from Richard Biener  ---
But isn't the alignas(32) also "appertaining to that entity"?

[Bug c++/94569] alignas(object) with a weaker (smaller) alignment than the alignas(type) of it's type compiles, inconsistent with the C++ standard

2020-04-12 Thread sinbal2l at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94569

--- Comment #2 from Inbal Levi  ---
Yes, you're probably right, got the wrong one.
Thanks!

[Bug c++/94569] alignas(object) with a weaker (smaller) alignment than the alignas(type) of it's type compiles, inconsistent with the C++ standard

2020-04-12 Thread richard-gccbugzilla at metafoo dot co.uk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94569

Richard Smith  changed:

   What|Removed |Added

 CC||richard-gccbugzilla@metafoo
   ||.co.uk

--- Comment #1 from Richard Smith  ---
I believe the particular rule that is violated by this example is
[dcl.align]p5:

"The combined effect of all alignment-specifiers in a declaration shall not
specify an alignment that is less strict than the alignment that would be
required for the entity being declared if all alignment-specifiers appertaining
to that entity were omitted."