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_at_[hidden]> 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
>