Remove the BlueGene compilers from the specification - #277
Merged
Conversation
The bg_gcc, bg_g++, and bg_gfortran compilers no longer have any platform (the bluegenep platforms were removed from the specification some time ago), but they still had compiler_opt_trans facts. That trips the "not defined as a compiler, but has optimization translation defined" sanity check in write_tuples, which makes it impossible to regenerate the platform directories from the current specification: gprolog halts before writing any tuples. Remove the three dead compilers from the low/high/max optimization translation lists and regenerate the platform directories (gprolog 1.5.0, Makefile.genspec gen-clean gen-all). Note on regeneration drift: the checked-in tuples.gz files were stale relative to the current specification (they still contained the removed ppc32_linux/ppc32_bgp*/ppc64_bgq* platform metadata), so regenerating rewrites them. All harness-driving generated files (test_info_new.gen.C, cmake-mutatees.txt, group boilerplate) reproduce byte-for-byte from the current spec; the only other change is generator-emitted trailing whitespace in cmake-mutators.txt that had been hand-stripped in the checked-in copies. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Remove the eight BlueGene compiler definitions and every fact that references them: - BlueGene/P: bg_gcc, bg_g++, bg_gfortran (their bluegenep platforms were removed from the specification long ago, so they were already unreachable; the previous commit removed their last live facts) - BlueGene/Q: bgq_gcc, bgq_g++, bgq_gfortran, bgxlc, bgxlc++ This covers compiler_format, compiler_platform, mutatee_comp, mutator_comp, compiler_define_string, compiler_s, compiler_pic, compiler_static_link/compiler_dynamic_link, comp_std_flags_str, comp_mutatee_flags_str, mutatee_link_options, the comp_lang / compiler_opt_trans / compiler_pic_trans / compiler_parm_trans / compiler_for_mutatee membership lists, and the bgxlc-only -qpic translation clause. The ppc64_bgq_ion platform definition itself is left in place (it now simply has no compilers, which the generator accepts); removing the platform and the bluegene OS guards wholesale can be a separate cleanup. Regenerated the platform directories (gprolog 1.5.0 + python2, Makefile.genspec gen-clean gen-all): the only generated-file change is the bgq compiler metadata disappearing from each platform's tuples.gz; no mutatee/mutator build lists change on any checked-in platform. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Member
Author
|
@hainest do you want me to remove all reference to these compilers transitively? |
With the BlueGene compilers gone, the ppc64_bgq_ion platform is fully inert, and every rule keyed on the 'bluegene' OS is unreachable. Remove: - the platform fact, its platform_abi, and its platform-list entry - the 'bluegene' entries in the OS membership guards (test_platform rules, aux_compiler_for_platform) - the \+ platform(_, 'bluegene', ...) exclusions (test1_40, pc_thread_cont, pc_temp_detach) - the bluegene clauses of platform_module, pcPlatforms, and runmode_platform, and the S \= 'bluegene' guards on the dyninst createProcess/useAttach runmodes - the OS \= 'bluegene' conditions on the gcc/g++ compiler_platform rules and the 'bluegenel' guard on dynamicMutatee platform_format - the BG/P platform_mode machinery (VN/DUAL/SMP modes and bg_vn_exclude); platform_mode/4 keeps its 'NONE' clause, which now applies unconditionally remote_platform/1 and mutatee_compiler_platform_exclude/2 had only bluegene clauses but are still consulted by runmode_launch_params and the mutatee/compiler pairing rules, and they are declared discontiguous, not dynamic -- removing their last clause would raise an existence error during generation. Each keeps a single explicit always-fail clause with a comment. Regenerated the platform directories: the only generated-file change is the two ppc64_bgq_ion metadata records disappearing from each platform's tuples.gz (platform list + object-suffix record); no mutatee/mutator build lists change on any checked-in platform. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Contributor
Yeah. They are long dead, so we can completely scrub them. |
bbiiggppiigg
marked this pull request as ready for review
August 5, 2026 02:20
Member
Author
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Title: Remove the BlueGene compilers from the specification
Split out of #276 per review — the spec fix that PR needed to regenerate the
platform directories, extended to remove the BlueGene/Q compilers as
requested.
Commit 1 —
spec: drop optimization translations for removed bluegene-P compilersThe
bg_gcc,bg_g++, andbg_gfortrancompilers no longer have anyplatform (the bluegenep platforms were removed from the specification some
time ago), but they still had
compiler_opt_transfacts. That trips the"not defined as a compiler, but has optimization translation defined"
sanity check in
write_tuples, so gprolog halts before writing any tuples —making it impossible to regenerate the platform directories from the current
specification.
Commit 2 —
spec: remove the BlueGene compilersRemoves the eight BlueGene compiler definitions and every fact referencing
them:
bg_gcc,bg_g++,bg_gfortran(already unreachable, seeabove)
bgq_gcc,bgq_g++,bgq_gfortran,bgxlc,bgxlc++Covers
compiler_format,compiler_platform,mutatee_comp,mutator_comp,compiler_define_string,compiler_s,compiler_pic,compiler_static_link/compiler_dynamic_link,comp_std_flags_str,comp_mutatee_flags_str,mutatee_link_options, thecomp_lang/compiler_opt_trans/compiler_pic_trans/compiler_parm_trans/compiler_for_mutateemembership lists, and the bgxlc-only-qpictranslation clause.
Commit 3 —
spec: remove the BlueGene/Q platform and the bluegene OS guardsWith the compilers gone,
ppc64_bgq_ionis fully inert, so this removes theplatform fact,
platform_abi, the platform-list entry, and every rule keyedon the
'bluegene'OS (membership guards,\+ platformexclusions, thebluegene clauses of
platform_module/pcPlatforms/runmode_platform, thegcc/g++
OS \= 'bluegene'conditions, and the BG/Pplatform_modeVN/DUAL/SMP machinery).
remote_platform/1andmutatee_compiler_platform_exclude/2had only bluegene clauses but are stillconsulted during generation and are declared discontiguous (not dynamic), so
each keeps a single explicit always-fail clause. After this commit the
specification is entirely BlueGene-free.
Regeneration: platform directories regenerated with gprolog 1.5.0 +
python2 (
Makefile.genspec gen-clean gen-all). The only generated-filechange is the bgq compiler metadata disappearing from each platform's
tuples.gz; no mutatee/mutator build lists change on any checked-inplatform. (Note: the checked-in
tuples.gzwere stale relative to thecurrent spec — they still carried the removed
ppc32_linux/ppc32_bgp*/ppc64_bgq*platform metadata — so regeneratingrewrites them; all harness-driving generated files reproduce byte-for-byte.)
#276 will be restacked on this branch and shrinks to just the ported-test
removal.