This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [review v3] slotinfo in struct dtv_slotinfo_list should be flexible array [BZ #25...


On 11/12/19 3:14 PM, Carlos O'Donell wrote:

If the new glibc cannot be compiled with gcc8 or gcc9 for nios2, then that's
a problem though. It immediately makes it difficult to test a new glibc on
existing systems without upgrading the system compiler.

If there is a backend bug then it absolutely needs to be fixed, and it looks
like Sandra will try that, but that won't reach the affected compilers until
much much later.

I dislike backing out the changes you made because they are quite nice
cleanups, and the downstream vendors tend to upgrade glibc and gcc and binutils
all in one big group to avoid these issues so I don't expect they will ever
see this problem. It's only us as developers that see the larger version
skew problem.

IIUC Intel uses whatever versions of binutils/gcc/glibc that Mentor Graphics gives them (currently 2.32/9.2/2.30 respectively) in their SDK and does not mess with mainline trunk sources at all. I can raise the issue with them, but IIRC this would not be the first time some changes have been made to glibc that require newish tools for building it.

My inclination is to fix the gcc problem, backport the solution to the active
FSF branches, and then that fixes our testers.

In order of importance:
- Fix all gcc10 issues.
- Fix the nios2 backend issue.
- Backport nios2 backend to active FSF branches.
- Rebuild and test to make sure we are all clean again.

Yes, that's my plan.

How long will that take and is it OK to leave things in a broken state for that long
for a given target like nios2?

Preparing and testing a patch for the Nios II GCC bug might take a couple days, but I have another one ahead of it in my queue that I'm trying to finish before Stage 1 closes at the end of the week. So maybe a week maximum?

BTW, does this problem affect any other target that tries to use GP-relative addressing for small data, like MIPS?

-Sandra


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]