Re: Proposed CHOST change for the 64bit time_t transition

[Andreas K. Huettel via Gcc]

Am Dienstag, 10. September 2024, 01:08:36 CEST schrieb Arsen Arsenović:
> Jacob Bachmeyer  writes:
> 
> >> At that point, we should bump SONAME of libc and simply remove 32-bit
> >> time support.  This would probably be okay generally.
> >
> > This is probably the best solution to this problem at hand, especially since
> > the old ABI has a definite expiration date about 14 years from now.  Bump 
> > the
> > libc SONAME major and hope that we can get rid of the last dependencies on 
> > the
> > old SONAME before the deadline.  We will have 14 years to do it, if that 
> > arch
> > is even still used then.
> 
> Indeed.  I believe the current thinking is that the existing software
> for the old ABI could benefit from libc updates, hence not breaking it,
> but.. it practically is somewhat broken already (hence the troubles that
> lead to this thread).
> 

This is all nice and good, but I would actually like to focus on realistic
targets (ie., ones which could be achieved significantly before 2038... :o)

That's also the beauty of only appending t64 to the last quadruplet field, 
most software is not impacted by it and just accepts it.

-- 
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer 
(council, comrel, toolchain, base-system, perl, libreoffice)
https://wiki.gentoo.org/wiki/User:Dilfridge

signature.asc
Description: This is a digitally signed message part.

Re: Proposed CHOST change for the 64bit time_t transition

[Todd Vierling via Gcc]

> This is all nice and good, but I would actually like to focus on realistic
> targets (ie., ones which could be achieved significantly before 2038... :o)

Right — there are distro releases shipping over the next few years which will 
still be deployed in production in 2038, so the clock is actually running out 
fast for some of us :)

-- 
-- Todd Vierling, Oracle Linux Sustaining and Security 

Late combine & mode switch

[Xi Ruoyao via Gcc]

Hi Richard,

When I hack the LoongArch backend I notice something like

slli.d $r4, $r4, 2
add.w $r4, $r4, $r5

Or

(set (reg:DI 4) (ashift:DI (reg:DI 4) (const_int 2))
(set (reg:DI 4)
 (sign_extend:DI (add:SI (reg:SI 4) (reg:SI 5

can appear after split.  On LoongArch it can be done via an alsl.w
instruction, so I attempted to combine them in late combine with:

(define_insn
  [(set (match_operand:DI 0 "register_operand" "=r")
(sign_extend:DI
  (add:SI
(subreg:SI
  (ashift:DI (match_operand:DI 1 "register_operand" "r")
 (match_operand:SI 2 "const_immalsl_operand" ""))
  0)
(match_operand:SI 3 "register_operand" "r"]
  "TARGET_64BIT"
  "alsl.w\t%0,%1,%3,%2")

But this does not work and I get "RTL substitution failed" with
-fdump-rtl-late_combine2-details.

I want to open an RFE in Bugzilla.  But before that I'm wondering: maybe
I'm just too stupid to figure out the correct way for this?

-- 
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University

Re: Proposed CHOST change for the 64bit time_t transition

[Florian Weimer via Gcc]

* Arsen Arsenović via Gcc:

> Bruno Haible  writes:
>
>> Paul Eggert wrote:
>>> I'd rather just switch, as Debian has.
>>
>> I'd go one step further, and not only
>>   make the ABI transition without changing the canonical triplet,
>> but also
>>   make gcc and clang define -D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64
>>   among their predefines.
>
> At that point, we should bump SONAME of libc and simply remove 32-bit
> time support.  This would probably be okay generally.  Just doing the
> predefine doesn't really fix anything - all the problems of not being
> able to detect whether t64 support exists still persist, with no
> mechanism to prevent mixing.

Defaulting to 64-bit time_t would also make dlsym etc. work again.  For
post-GLIBC_2.1 targets (where valid binaries are expected to use symbol
versioning) it's not absolutely required to do a soname bump, just
changing the symbol version baseline should be enough (set DEFAULT to
e.g. GLIBC_2.40 in shlib-versions).  Old binaries will use
__libc_start_main@GLIBC_2.4 or __libc_start_main@GLIBC_2.34, and fail to
load.  This could be a more source-compatible change becaue I suspect
not everyone uses LIBC_SO in  to get the soname for
libc.so.

I do not have a strong opinion whether this should be done for most
32-bit targets.  Except for i386, where I think we should aim to
preserve compatibility with legacy binaries for many years to come.

All these changes have implications for LSB complinace, as people keep
reminding us:

  LoongArch glibc does not provide libutil shared object, against LSB 5.0 
  

But as I explained on the ticket, the way LSB is constructed, it's
surprisingly architecture-specific even in its generic parts, and 32-bit
Arm with its GLIBC_2.4 baseline won't have the required GLIBC_2.3.4
symbols (such as __chk_fail@GLIBC_2.3.4) anyway.

Thanks,
Florian

Revolutionize Your Software Sales with EngageBay 💻

[Andy Roberts via Gcc]

Is growth possible for a dollar a 
day?..
 Hi there! I'm Andy Roberts, and I've been closely analyzing the dynamic needs 
of the software industry. That's how I discovered your company, and I couldn't 
wait to reach out. EngageBay has emerged as a RevOps champ for software 
companies seeking a budget-friendly yet potent solution. It's a holistic CRM 
and marketing automation platform, crafted with the intricacies of your 
industry in mind. Why EngageBay? Simplify client management and streamline your 
software sales and marketing processes. Automate your outreach, ensuring your 
software solutions gain the visibility they deserve. Exceptional value starting 
at just 14.99 a month. I'm eager to hear your thoughts or even a simple 
indication of your interest level. Schedule an e-meet with me, or just sign up 
to play around with the tool! Regards, Andy Roberts EngageBay Inc Schedule a 
Call Don't want to get emails like this? Unsubscribe from our emails