Thank you Jens!

That is very helpful. I fixed the points mentioned.

> I can't find any in the standard. Please list those

I ment 'alignas(exp)' for example - 'alignas(obj)' even though it's undefined. I added examples to the paper (E.g. under [expr.const] section 10, N4892)

> "The alignment of an object in C is resolved to the strictest amongst its members"

> While I believe such a rule might be reasonable to provide explicitly (at least for standard-layout or trivial types), I fail to find it in WG14 N2573 6.7.5

This appears on reference [6] in the paper. It's under '6.7.5 Alignment specifier' / section 5 (in N2596 C standard). To my understanding, this results from: "The combined effect of all alignment specifiers in a declaration shall not specify an alignment that is less strict than the alignment that would otherwise be required for the type of the object or member being declared."

This does not exist on C++, and I was hoping to fix it in C++'s standard (that's under section 4.2) but I removed it from [dclait's more important to me to move forward with the fixes in consensus.

> [expr.alignof] talks about alignof(expr), but doesn't say what it means at all.

I'll point out that I did avoid specifying the value of alignof(obj) on purpose (just like there is no explicit value specification of alignof(type-id), I refer to it as an issue, it's only mentioned that it cannot be smaller than the alignment value if it was omitted). I also refer in the paper to implementation details and Itanium ABI.

> [dcl.align] This wording should move to [basic.align], saying that the alignment requirement of a (trivial? standard-layout?) class type is the strictest alignment of its non-static data members or so.

The change in [dcl.align] is an attempt to 'fix' the paragraph to be like in C, in order to address the issue brought up in the previous section. I removed this.

We already have under section [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", but I feel comfortable with adding wording as you suggested.

Attaching a link to fixed R1 (not published yet): https://isocpp.org/files/papers/D2152R1.pdf

Thanks again,

Inbal Levi

On Sat, 15 May 2021 at 20:03, Jens Maurer <Jens.Maurer@gmx.net> wrote:

On 10/05/2021 19.52, Inbal Levi via Liaison wrote:
>
> Hello all!
> I would love SG22's input on D2152R1 <https://isocpp.org/files/papers/D2152R1.pdf> of the paper: "P2152: Querying the Alignment of an Object [Aligning Alignment]"

4.1

"Issue [4.1.1]: The standard does not allow alignof(exp) (this is a GNU extension)."

Agreed.

"However, there are multiple references to functionality derived from allowing alignof(exp)."

I can't find any in the standard. Please list those "multiple
references" (in the paper).

"As a result, there is inconsistency between different compilers,"

Not surprising with an extension.

" and within the C++ standard."

Please provide specific evidence.

> The paper was originally created to solve a rather small issue: Core#1008 <https://wiki.edg.com/pub/Wg21summer2020/CoreWorkingGroup/cwg_closed.html#1008> but during the process I have stumbled across a wider issue.

In section 4.1, please say what the desired semantics are supposed to be.

alignof(expr) is the same as alignof(decltype(expr)), or what?
(Note that the object designated by "expr" might happen to be aligned
stricter than its type is required to be.)

> _I would most appreciate the groups' feedback, and particularly on the following:_
>
> 1. My preferred direction is to enforce a striker rule then of C (and which is aligned with Clang's behaviour) regarding alignment specification (reasoning is under section 4.2) but I would love feedback on that.

4.2 claims

"The alignment of an object in C is resolved to the strictest amongst its members"

While I believe such a rule might be reasonable to provide explicitly
(at least for standard-layout or trivial types), I fail to find it in
WG14 N2573 6.7.5. Could you please point to a specific paragraph?

"Consider the following C code:"

Code involving "__attribute__" is neither (standard) C nor C++, I believe.

> 2. The paper does not have a "formal" wording (though it has been reviewed by Daveed on it's early stages) so I would love your input, especially with respect to defining the types of which we enforce the alignment (4.2 again).

[basic.align] The yellow addition should be a note at best.
(The alignment is already implementation-defined, what more to say?)

[expr.alignof] talks about alignof(expr), but doesn't say what it
means at all.

[dcl.align] This wording should move to [basic.align], saying that
the alignment requirement of a (trivial? standard-layout?) class
type is the strictest alignment of its non-static data members or so.

[expr.reinterpret.cast]
I don't know what you want to do here. We already guarantee
you get the original pointer value, which is more than restoring
the bit-pattern. The addition of "alignment" is superfluous
at best and possibly misleading.

Jens