Hi Iain, Thanks very much for your time!!! on 2022/9/29 03:09, Iain Sandoe wrote: > Hi Kewen > >> On 28 Sep 2022, at 17:18, Iain Sandoe wrote: >> >> (reduced CC list, if folks want to be re-included .. please add them back). >> >>> On 28 Sep 2022, at 07:37, Iain Sandoe wrote: >> >>>> On 28 Sep 2022, at 06:30, Kewen.Lin via Gcc-patches 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. >>>> >>>> With this patch, if users specify -m{no-,}powerpc64, the >>>> specified value is honoured, otherwise, for 64bit it >>>> always enables OPTION_MASK_POWERPC64 while for 32bit >>>> it disables OPTION_MASK_POWERPC64 if OS_MISSING_POWERPC64. >>>> >>>> Bootstrapped and regress-tested on: >>>> - powerpc64-linux-gnu P7 and P8 {-m64,-m32} >>>> - powerpc64le-linux-gnu P9 and P10 >>>> - powerpc-ibm-aix7.2.0.0 {-maix64,-maix32} >>>> >>>> Hi Iain, could you help to test this on darwin to ensure >>>> it won't break darwin's build and new tests are fine? >>>> Thanks in advance! >>> >>> Will do, it will take a day or so, thanks, >> >> Perhaps a small exposition on the target: >> >> powerpc-apple-darwin, is perhaps somewhat unusual in that it is nominally a 32b kernel, but the OS supports 64b processes on suitable hardware (and the OS does preserve the upper bits of 64b regs in the context). >> >> ----- >> >> I bootstrapped (all supported languages) and tested r13-2892 yesterday with “nominal” results. >> >> Then I added this patch .. and did a clean bootstrap (same configuration). >> >> the bootstrap fails on the stage3 libgomp (building the ppc64 multilib) with the error below >> What is somewhat odd here is that libgomp is bootstrapped with the compiler and, apparently, >> openacc-init.c built OK at stage2. >> >> —— >> >> Of course, powerpc-darwin is not a blocker for anything, it should not hold you up (but sometimes it >> manages to find a glitch missed elsewhere). I will try to take a look at this this evening see if I can throw >> any more light on it. >> >> ------ >> >> /src-local/gcc-master/libgomp/oacc-init.c:876:1: internal compiler error: ‘global_options’ are modified in local context >> 876 | { >> | ^ >> 0xe940d7 cl_optimization_compare(gcc_options*, gcc_options*) >> /scratch/10-5-leo/gcc-master/gcc/options-save.cc:14082 > > This repeats on a cross from x86_64-darwin to powerpc-darwin .. (makes debug a bit quicker) > > this is the failing case - which does not (immediately) seem directly connected .. does it ring > any bells for you? > > 16649 if (ptr1->x_rs6000_sched_restricted_insns_priority != ptr2->x_rs6000_sched_restricted_insns_priority) > -> 16650 internal_error ("% are modified in local context”); > I found this flag is mainly related to tune setting and spotted that we have some code for tune setting when no explicit cpu is given. ... else { size_t i; enum processor_type tune_proc = (TARGET_POWERPC64 ? PROCESSOR_DEFAULT64 : PROCESSOR_DEFAULT); tune_index = -1; for (i = 0; i < ARRAY_SIZE (processor_target_table); i++) if (processor_target_table[i].processor == tune_proc) { tune_index = i; break; } } It checks TARGET_POWERPC64 directly here, my proposed patch will adjust TARGET_POWERPC64 after this hunk, so it seems to be problematic for some case. I'm testing the attached diff which can be applied on top of the previous proposed patch on ppc64 and ppc64le, could you help to test it can fix the issue? BR, Kewen