[Bug c++/64232] New: Derived class with implicitly declared assignment operator is std::assignable though base class is not std::assignable

[Bug c++/64232] New: Derived class with implicitly declared assignment operator is std::assignable though base class is not std::assignable

[mmehlich at semanticdesigns dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64232

            Bug ID: 64232
           Summary: Derived class with implicitly declared assignment
                    operator is std::assignable though base class is not
                    std::assignable
           Product: gcc
           Version: 4.8.3
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: mmehlich at semanticdesigns dot com

Derived class with implicitly declared assignment operator is std::assignable
though the base class is not std::assignable

Code:

#include <iostream>
#include <type_traits>

struct X {
    X(const X&) = delete;
    void operator=(X x);
};

struct Y: X {
};

int main()
{
    std::cout << std::is_assignable<X&,X>::value << std::endl;
    std::cout << std::is_assignable<Y&,Y>::value << std::endl;
}

Output:
0
1

[Bug c++/64232] Derived class with implicitly declared assignment operator is std::is_assignable though base class is not std::is_assignable

[redi at gcc dot gnu.org]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="UTF-8", Size: 4850 bytes --]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64232

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |INVALID

--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> ---
std::is_assignable says:

"Only the validity of the immediate context of the assignment expression is
considered. [ Note: The compilation of the expression can result in side
effects such as the instantiation of class template specializations and
function template
specializations, the generation of implicitly-defined functions, and so on.
Such
side effects are not in the “immediate context” and can result in the program
being ill-formed. — end note ]"

i.e. is_assignable isn't magic and can't give the right answer in all cases,
especially if you have members with nonsensical signatures.
>From gcc-bugs-return-469868-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Dec 09 12:19:43 2014
Return-Path: <gcc-bugs-return-469868-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 27311 invoked by alias); 9 Dec 2014 12:19:43 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 27275 invoked by uid 48); 9 Dec 2014 12:19:39 -0000
From: "wolfgang.roehrl@gi-de.com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/64236] New: Missing alignment
Date: Tue, 09 Dec 2014 12:19:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: 4.8.3
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: wolfgang.roehrl@gi-de.com
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter
Message-ID: <bug-64236-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-12/txt/msg00875.txt.bz2
Content-length: 2013

https://gcc.gnu.org/bugzilla/show_bug.cgi?idd236

            Bug ID: 64236
           Summary: Missing alignment
           Product: gcc
           Version: 4.8.3
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: wolfgang.roehrl@gi-de.com

Hi,
I would like to post a bug report for the GNU C/C++ compiler 4.8.3.
We use the compiler to generate code for a PowerPC processor.
Invokation line for the GNU C++ compiler:

ccppc -c -x c++ -std=c++11 -Wall -Werror -g -mcpu…40 -meabi
      -ftls-model=local-exec -msdata=sysv -fno-common -mspe -mabi=spe
      -mfloat-gprs=double -mbig -mmultiple -mno-string -misel -mstrict-align
      -fverbose-asm -fno-exceptions -fno-rtti -fgcse-sm -fno-section-anchors
      -ftemplate-backtrace-limit  -G 8 -O3
      -I<some include paths>
      -D<some #define's>
      X.CPP -oX.O


// file X.CPP

#define SIZE_DATA_CACHE_BLOCK 32u

struct S
{ double d; };

struct alignas(sizeof(S)) S1
{ char d[sizeof(S)]; };

struct alignas(SIZE_DATA_CACHE_BLOCK) alignas(sizeof(S)) S2
{ char d[sizeof(S)]; };


alignas(S) char s1[sizeof(S)];
alignas(SIZE_DATA_CACHE_BLOCK) alignas(S) char s2[sizeof(S)];
S1 s3;
S2 s4;



An inspection of the generated assembler file (see below) shows the following
alignments:
. s1: alignment = 8
. s2: alignment = 32
. s3: alignment = 8
. s4: alignment = 8 ???

I think that s4 should also be aligned on a 32-byte boundary (C++11 standard,
7.6.2/4).


Following is the generated assembler file:

 .globl s4
 .section ".sbss","aw",@nobits
 .align 3    <--- 8-byte alignment ???
s4:
 .zero 8
 .size s4, 8
 .type s4, @object
 .globl s3
 .align 3    <--- 8-byte alignment
s3:
 .zero 8
 .size s3, 8
 .type s3, @object
 .globl s2
 .align 5    <--- 32-byte alignment
s2:
 .zero 8
 .size s2, 8
 .type s2, @object
 .globl s1
 .align 3    <--- 8-byte alignment
s1:
 .zero 8
 .size s1, 8
 .type s1, @object



Kind regards
W. Roehrl

[Bug c++/64232] Derived class with implicitly declared assignment operator is std::is_assignable though base class is not std::is_assignable

[mmehlich at semanticdesigns dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64232

--- Comment #2 from Michael Mehlich <mmehlich at semanticdesigns dot com> ---
My expectation was that the compiler declares the copy assignment operator of Y
as deleted as its base class X is not assignable; std::is_assignable would then
just have to look at the copy constructor for Y and notice that it is deleted,
which would obviously be in the immediate context.
But arguably, 12.8 paragraph 34 item 4 only looks at the copy assignment
operator for X, not whether X can actually be copy-assigned, which - as the
example above shows - may require that the copy constructor for X is not
deleted.
By the way, std::is_nothrow_assign has the same problem (i.e. declaring X(const
X&) as throwing, and operator=(X x) as not throwing results in gcc claiming
that the copy assignment operator for Y is not throwing).