[gofrontend-dev] Go patch committed: Avoid warning by using a local var for std::ofstream

[Florian Weimer]

* John David Anglin:

> On Tue, Sep 20, 2016 at 09:27:17PM +0200, Florian Weimer wrote:
>> * Ian Lance Taylor:
>> 
>> > GCC PR 77625 is about a warning while compiling the Go frontend.  The
>> > Go frontend called `new std::ofstream()`, and the warning is "error:
>> > `new' of type `std::ofstream {aka std::basic_ofstream<char>}' with
>> > extended alignment 16".  Frankly I'm not sure how this supposed to
>> > work: shouldn't it be possible to write new std::ofstream()?  But the
>> > problem is easy to avoid, since in this case the std::ofstream can be
>> > a local variable, and that is a better approach anyhow.  This patch
>> > was bootstrapped on x86_64-pc-linux-gnu.  Committed to mainline.
>> 
>> This happens only on hppa, right?  It looks as if libstdc++ is
>> seriously broken there.
>
> I'm not sure I understand the comment.  I created a short testcase.
> I agree that the issue is hppa specific but the extended alignment
> is coming from the __lock field in pthread_mutex_t.  I'm not sure
> why this affects new std::ofstream().

Ahh, thanks for the explanation.  The C++ streams probably have some
internal locks (hidden behind libstdc++ abstractions).

> The alignment of 16 arises in code that used the ldcw instruction.
> Although this could be avoided in glibc there are numerous other
> packages with objects requiring 16-byte alignment.  So, I'm tending
> to think the typedef for max_align_t should be adjusted on hppa-linux
> so that it has 16-byte alignment.  Is that the correct approach?

Yes, and for the warning to go away, GCC's MALLOC_ABI_ALIGNMENT needs
to be increased as well, I think.

Nowadays, we can change the glibc malloc alignment fairly easily, but
interposed mallocs won't be so nice.  But it is unlikely that any of
this matters in practice because the issue is not new (only the
warning is).

I have Cc:ed a few people who might have ideas how to deal with this.

Torvald, would it be possible to align mutexes internally on hppa, to
avoid the 16-byte alignment of the entire struct (that is, store a
pointer to the actual mutex object, which points to a sub-region of
the struct which is suitably aligned)?

We probably could add libstdc++ compile-time tests which make sure
that all relevant C++ types can be allocated with the global operator
new.