From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id CE0DC385801F; Tue, 22 Feb 2022 20:05:12 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org CE0DC385801F From: "adhemerval.zanella at linaro dot org" To: glibc-bugs@sourceware.org Subject: [Bug ports/28872] Building glibc for MIPSel single float targets Date: Tue, 22 Feb 2022 20:05:12 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: ports X-Bugzilla-Version: 2.30 X-Bugzilla-Keywords: X-Bugzilla-Severity: critical X-Bugzilla-Who: adhemerval.zanella at linaro dot org X-Bugzilla-Status: RESOLVED X-Bugzilla-Resolution: INVALID X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: glibc-bugs@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Glibc-bugs mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2022 20:05:12 -0000 https://sourceware.org/bugzilla/show_bug.cgi?id=3D28872 --- Comment #16 from Adhemerval Zanella --- (In reply to Den from comment #15) > (In reply to Adhemerval Zanella from comment #14) >=20 > Zanella, thank you for your support. >=20 > > In fact it does exactly what I suggested ... on comment #5. >=20 > Well, your patches here just replaces l.d to ldc1 and s.d to sdc1, but as= I > replied to your comment#5, the opcodes sdc1/ldc1 (the almost same load/st= ore > double but from/to coprocessor1) are not supported for single float targe= ts > as well. What about lwc1/swc1 and BYTES_PER_WORD? - doubles will not be > doubles after those instructions, right? >=20 > By the way, you made a mistake in setjmp_aux.c (s.d and sdc1 instead of l= .d > and ldc1). Moreover, the files.c (at least them) can not be compiled when > there are such presentations of LDFPR/STFPR inside asm volatiles. I suppo= se > you just showed a quick realization. >=20 > > $ mips64-linux-gnu/bin/mips64-glibc-linux-gnu-gcc -mabi=3D32 -mips2 > > -mhard-float -mfpxx t.c -o t >=20 > Please, while tests, additionally use flag -msingle-float and/or -mfp32 > instead of -mfpxx I am confused because in some places you refers to r5900 and other r6000. A= FAIK r6000 was never supported on Linux [1], and it seems that gcc also does not fully support the r6010 floating point controller: $ cat test.c void foo (double *m, double v) { *m =3D v; } $ mips64el-glibc-linux-gnu-gcc -O2 -mabi=3D32 -march=3Dr6000 -mfp32 -msingl= e-float -mhard-float test.c -S -o - .file 1 "test.c" .section .mdebug.abi32 .previous .nan legacy .module singlefloat .module nooddspreg .abicalls .option pic0 .text .align 2 .globl foo .set nomips16 .set nomicromips .ent foo .type foo, @function foo: .frame $sp,0,$31 # vars=3D 0, regs=3D 0/0, args=3D 0= , gp=3D 0 .mask 0x00000000,0 .fmask 0x00000000,0 .set noreorder .set nomacro sw $6,0($4) jr $31 sw $7,4($4) [...] So gcc does not transform double stores to 'swc1', it seems to be using sof= tfp in this case. In an case, I think you can try replace LDFPR and STFPR on my patch to the = with 'lwc1' and 'swc1' if __mips_fpr is 32. Something like: #if __mips_fpr =3D=3D 0 || __mips_fpr =3D=3D 64 # define STFPR sdc1 #else if __mips_fpr =3D=3D 32 # define STFPR swc1 #else # define STFPR s.d #endif Assuming that the mips machine ou are targetting have the same set of float= ing -point registers. [1] https://www.linux-mips.org/wiki/R6000 --=20 You are receiving this mail because: You are on the CC list for the bug.=