Hi Sebastian, on 2024/2/5 18:38, Sebastian Huber wrote: > Hello, > > On 27.12.22 11:16, Kewen.Lin via Gcc-patches wrote: >> Hi Segher, >> >> on 2022/12/24 04:26, Segher Boessenkool wrote: >>> Hi! >>> >>> On Wed, Oct 12, 2022 at 04:12:21PM +0800, Kewen.Lin wrote: >>>> PR106680 shows that -m32 -mpowerpc64 is different from >>>> -mpowerpc64 -m32, this is determined by the way how we >>>> handle option powerpc64 in rs6000_handle_option. >>>> >>>> Segher pointed out this difference should be taken as >>>> a bug and we should ensure that option powerpc64 is >>>> independent of -m32/-m64. So this patch removes the >>>> handlings in rs6000_handle_option and add some necessary >>>> supports in rs6000_option_override_internal instead. >>> >>> Sorry for the late review. >>> >>>> + /* Don't expect powerpc64 enabled on those OSes with >>>> OS_MISSING_POWERPC64, >>>> + since they don't support saving the high part of 64-bit registers on >>>> + context switch. If the user explicitly specifies it, we won't >>>> interfere >>>> + with the user's specification. */ >>> >>> It depends on the OS, and what you call "context switch". For example >>> on Linux the context switches done by the kernel are fine, only things >>> done by setjmp/longjmp and getcontext/setcontext are not. So just be a >>> bit more vague here? "Since they do not save and restore the high half >>> of the GPRs correctly in all cases", something like that? >>> >>> Okay for trunk like that. Thanks! >>> >> >> Thanks! Adjusted as you suggested and committed in r13-4894-gacc727cf02a144. > > I am a bit late, however, this broke the 32-bit support for -mcpu=e6500. For > RTEMS, I have the following multilibs: > > MULTILIB_REQUIRED += mcpu=e6500/m32 > MULTILIB_REQUIRED += mcpu=e6500/m32/mvrsave > MULTILIB_REQUIRED += mcpu=e6500/m32/msoft-float/mno-altivec > MULTILIB_REQUIRED += mcpu=e6500/m64 > MULTILIB_REQUIRED += mcpu=e6500/m64/mvrsave > > I configured GCC as a bi-arch compiler (32-bit and 64-bit). It seems you > removed the -m32 handling, so I am not sure how to approach this issue. I > added a test case to the PR: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106680
Thanks for reporting, I'll have a look at it (but I'm starting to be on vacation, so there may be slow response). I'm not sure what's happened in bugzilla recently, but I didn't receive any mail notifications on your comments #c5 and #c6 (sorry for the late response), since PR106680 is in state resolved maybe it's good to file a new one for further tracking. :) BR, Kewen
