On 2017-02-25, at 5:32 PM, Gerald Pfeifer wrote:
> On Sat, 25 Feb 2017, John David Anglin wrote:
>>> Sooo, why not deprecate 32-bit HP-UX with GCC 7?
>> GCC 7 is in reasonable shape on 32-bit HP-UX. I'll do it after it is
>> released.
>
> If you deprecate it with GCC 7, it'd be only removed wit
On Sat, 25 Feb 2017, John David Anglin wrote:
>> Sooo, why not deprecate 32-bit HP-UX with GCC 7?
> GCC 7 is in reasonable shape on 32-bit HP-UX. I'll do it after it is
> released.
If you deprecate it with GCC 7, it'd be only removed with GCC 8.
On the other hand, if you deprecate it past GCC 7
On 2017-02-25, at 12:25 PM, Gerald Pfeifer wrote:
> On Wed, 12 Oct 2016, John David Anglin wrote:
>>> It's really hard to make an argument to do anything other than deprecate
>>> that platform. Given John's ongoing involvement it's much harder to
>>> deprecate 64bit linux (and consequently 64bit
On Wed, 12 Oct 2016, John David Anglin wrote:
>> It's really hard to make an argument to do anything other than deprecate
>> that platform. Given John's ongoing involvement it's much harder to
>> deprecate 64bit linux (and consequently 64bit hpux).
> I believe that deprecating the 32-bit HP-UX pla
On 10/12/2016 10:17 AM, John David Anglin wrote:
> On 2016-10-12 9:48 AM, Jason Merrill wrote:
>> On Wed, Oct 12, 2016 at 4:02 AM, Jakub Jelinek wrote:
>>> On Wed, Oct 12, 2016 at 09:52:04AM +0200, Florian Weimer wrote:
dropping the alignment means that the padding before the lock member
On 2016-10-12 2:01 PM, Florian Weimer wrote:
On 10/12/2016 06:14 PM, Jeff Law wrote:
If the issue is strictly limited to 32 bit hpux, then do we really care?
Can we just deprecate that platform and thus make the issue go away?
Are we talking about HP-XX or Linux on PA-RISC?
The patch was int
On 10/12/2016 06:14 PM, Jeff Law wrote:
If the issue is strictly limited to 32 bit hpux, then do we really care?
Can we just deprecate that platform and thus make the issue go away?
Are we talking about HP-XX or Linux on PA-RISC?
Thanks,
Florian
On 2016-10-12 12:14 PM, Jeff Law wrote:
On 10/12/2016 02:02 AM, Jakub Jelinek wrote:
On Wed, Oct 12, 2016 at 09:52:04AM +0200, Florian Weimer wrote:
dropping the alignment means that the padding before the lock member
vanishes. Consequently, we have just created a silent ABI change in
applicat
On 10/12/2016 02:02 AM, Jakub Jelinek wrote:
On Wed, Oct 12, 2016 at 09:52:04AM +0200, Florian Weimer wrote:
dropping the alignment means that the padding before the lock member
vanishes. Consequently, we have just created a silent ABI change in
application code, which is a big no-no.
Sure, i
On Wed, 12 Oct 2016, Richard Biener wrote:
> I'd say what applies to PA should apply equally well to the pdp11 and
> the alpha port ...
>
> But usually the question is just whether the port has a maintainer
> and/or whether it is
> a maintainance burden to keep it (say, last user of obsolete feat
On 2016-10-12 9:48 AM, Jason Merrill wrote:
On Wed, Oct 12, 2016 at 4:02 AM, Jakub Jelinek wrote:
On Wed, Oct 12, 2016 at 09:52:04AM +0200, Florian Weimer wrote:
dropping the alignment means that the padding before the lock member
vanishes. Consequently, we have just created a silent ABI chan
On Wed, Oct 12, 2016 at 4:02 AM, Jakub Jelinek wrote:
> On Wed, Oct 12, 2016 at 09:52:04AM +0200, Florian Weimer wrote:
>> dropping the alignment means that the padding before the lock member
>> vanishes. Consequently, we have just created a silent ABI change in
>> application code, which is a bi
On 10/12/2016 02:43 PM, Richard Biener wrote:
I'd say what applies to PA should apply equally well to the pdp11 and
the alpha port ...
But usually the question is just whether the port has a maintainer
and/or whether it is
a maintainance burden to keep it (say, last user of obsolete feature X).
On Wed, Oct 12, 2016 at 2:33 PM, Bernd Schmidt wrote:
> On 10/12/2016 02:12 PM, John David Anglin wrote:
>>
>> On 2016-10-12, at 4:02 AM, Jakub Jelinek wrote:
>>
Since this is PA-RISC, which is essentially dead (neither HPE nor Debian
ship it anymore), I stand by my suggestion to bump th
On 10/12/2016 02:12 PM, John David Anglin wrote:
On 2016-10-12, at 4:02 AM, Jakub Jelinek wrote:
Since this is PA-RISC, which is essentially dead (neither HPE nor Debian
ship it anymore), I stand by my suggestion to bump the fundamental alignment
Or just drop support for a dead arch?
Hardwa
On 2016-10-12, at 4:02 AM, Jakub Jelinek wrote:
>> Since this is PA-RISC, which is essentially dead (neither HPE nor Debian
>> ship it anymore), I stand by my suggestion to bump the fundamental alignment
>
> Or just drop support for a dead arch?
Hardware is still available on the second hand mar
On Wed, Oct 12, 2016 at 09:52:04AM +0200, Florian Weimer wrote:
> dropping the alignment means that the padding before the lock member
> vanishes. Consequently, we have just created a silent ABI change in
> application code, which is a big no-no.
Sure, it would be an ABI change, but how many user
On 10/12/2016 09:25 AM, Jakub Jelinek wrote:
No, you can just drop the aligned attributes for HPUX 32-bit, basically
introduce a new ABI. If needed, you could add new symbol versions for
pthread_mutex_* etc. (though, if the current code doesn't care about the
alignment, perhaps you could get aw
On Wed, Oct 12, 2016 at 03:01:51AM -0400, Carlos O'Donell wrote:
> On 10/11/2016 04:04 PM, John David Anglin wrote:
> > On 2016-10-11 2:50 PM, Jason Merrill wrote:
> >> /* Alignment, in bits, a C conformant malloc implementation has to
> >> provide.
> >> The HP-UX malloc implementation provides
On 10/11/2016 04:04 PM, John David Anglin wrote:
> On 2016-10-11 2:50 PM, Jason Merrill wrote:
>> /* Alignment, in bits, a C conformant malloc implementation has to
>> provide.
>> The HP-UX malloc implementation provides a default alignment of 8
>> bytes.
>> This can be increased with mallo
On Tue, Oct 11, 2016 at 4:54 PM, John David Anglin wrote:
> On 2016-10-11 4:11 PM, Jason Merrill wrote:
>>
>> On Tue, Oct 11, 2016 at 2:59 PM, DJ Delorie wrote:
>>>
>>> Jason Merrill writes:
If PA malloc doesn't actually provide 16-byte alignment, this change
seems problematic; it
On Tue, Oct 11, 2016 at 04:54:56PM -0400, John David Anglin wrote:
> But the check isn't directly about malloc. It's between the alignment for
> max_align_t
> and the alignment that the type wants. Joseph indicated that max_align_t
> should have an
> alignment as large as the POSIX types (e.g., p
On 2016-10-11 4:11 PM, Jason Merrill wrote:
On Tue, Oct 11, 2016 at 2:59 PM, DJ Delorie wrote:
Jason Merrill writes:
If PA malloc doesn't actually provide 16-byte alignment, this change
seems problematic; it will mean any type that wants 16-byte alignment
will silently get 8-byte alignment in
On Tue, Oct 11, 2016 at 2:59 PM, DJ Delorie wrote:
>
> Jason Merrill writes:
>> If PA malloc doesn't actually provide 16-byte alignment, this change
>> seems problematic; it will mean any type that wants 16-byte alignment
>> will silently get 8-byte alignment instead.
>
> Should such cases be cal
On 2016-10-11 2:50 PM, Jason Merrill wrote:
/* Alignment, in bits, a C conformant malloc implementation has to
provide.
The HP-UX malloc implementation provides a default alignment of 8
bytes.
This can be increased with mallopt. The glibc implementation also
provides
8-byte alignment
Jason Merrill writes:
> If PA malloc doesn't actually provide 16-byte alignment, this change
> seems problematic; it will mean any type that wants 16-byte alignment
> will silently get 8-byte alignment instead.
Should such cases be calling memalign (or posix_memalign) instead of
malloc?
/* Alignment, in bits, a C conformant malloc implementation has to
provide.
The HP-UX malloc implementation provides a default alignment of 8
bytes.
This can be increased with mallopt. The glibc implementation also
provides
8-byte alignment. Note that this isn't enough for various POSIX
Attached is an updated version using the new builtin __MAX_ALIGN_T_ALIGN__.
This
simplifies the declaration of max_align_t and ensures it is always the same as
max_align_t_align().
Tested on hppa-unknown-linux-gnu. Okay for trunk?
Dave
--
John David Anglin dave.ang...@bell.net
2016-10
On 2016-10-09, at 4:34 AM, Bernd Edlinger wrote:
> For instance have:
>
> typedef struct {
> char __max_align[0] __attribute__((__aligned__(__MAX_ALIGN_T_ALIGN__)));
> } max_align_t;
>
> Provided we do:
>
> builtin_define_with_value ("__MAX_ALIGN_T_ALIGN__",
> targetm.max_align_t_align () / B
On 10/08/16 19:36, John David Anglin wrote:
> On 2016-10-08, at 1:01 PM, Bernd Edlinger wrote:
>
>> I think your callback should also directly control the
>> alignment of max_align_t in stddef.h:
>>
>>
>>long long __max_align_ll __attribute__((__aligned__(__alignof__(long
>> long;
>>lon
On 2016-10-08, at 1:01 PM, Bernd Edlinger wrote:
> I think your callback should also directly control the
> alignment of max_align_t in stddef.h:
>
> typedef struct {
> long long __max_align_ll __attribute__((__aligned__(__alignof__(long
> long;
> long double __max_align_ld
> __attribut
bounced, resent...
Hi,
I think your callback should also directly control the
alignment of max_align_t in stddef.h:
typedef struct {
long long __max_align_ll __attribute__((__aligned__(__alignof__(long
long;
long double __max_align_ld
__attribute__((__aligned__(__alignof__(long doubl
Hi,
I think your callback should also directly control the
alignment of max_align_t in stddef.h:
typedef struct {
long long __max_align_ll __attribute__((__aligned__(__alignof__(long
long;
long double __max_align_ld
__attribute__((__aligned__(__alignof__(long double;
/* _Float1
33 matches
Mail list logo
