Skip to content

Remove the BlueGene compilers from the specification - #277

Merged
hainest merged 3 commits into
masterfrom
bbiiggppiigg/remove-bluegene-compilers
Aug 5, 2026
Merged

Remove the BlueGene compilers from the specification#277
hainest merged 3 commits into
masterfrom
bbiiggppiigg/remove-bluegene-compilers

Conversation

@bbiiggppiigg

@bbiiggppiigg bbiiggppiigg commented Aug 4, 2026

Copy link
Copy Markdown
Member

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 compilers

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, 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 compilers

Removes the eight BlueGene compiler definitions and every fact referencing
them:

  • BlueGene/P: bg_gcc, bg_g++, bg_gfortran (already unreachable, see
    above)
  • BlueGene/Q: 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, the comp_lang /
compiler_opt_trans / compiler_pic_trans / compiler_parm_trans /
compiler_for_mutatee membership lists, and the bgxlc-only -qpic
translation clause.

Commit 3 — spec: remove the BlueGene/Q platform and the bluegene OS guards

With the compilers gone, ppc64_bgq_ion is fully inert, so this removes the
platform fact, platform_abi, the platform-list entry, and every rule keyed
on the 'bluegene' OS (membership guards, \+ platform exclusions, the
bluegene clauses of platform_module/pcPlatforms/runmode_platform, the
gcc/g++ OS \= 'bluegene' conditions, and the BG/P platform_mode
VN/DUAL/SMP machinery). remote_platform/1 and
mutatee_compiler_platform_exclude/2 had only bluegene clauses but are still
consulted 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-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. (Note: the checked-in tuples.gz were stale relative to the
current spec — they still carried the removed
ppc32_linux/ppc32_bgp*/ppc64_bgq* platform metadata — so regenerating
rewrites 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.

bbiiggppiigg and others added 2 commits August 4, 2026 16:31
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>
@bbiiggppiigg

Copy link
Copy Markdown
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>
@hainest

hainest commented Aug 4, 2026

Copy link
Copy Markdown
Contributor

@hainest do you want me to remove all reference to these compilers transitively?

Yeah. They are long dead, so we can completely scrub them.

@bbiiggppiigg
bbiiggppiigg requested a review from hainest August 5, 2026 02:20
@bbiiggppiigg
bbiiggppiigg marked this pull request as ready for review August 5, 2026 02:20
@bbiiggppiigg bbiiggppiigg changed the title Title: Remove the BlueGene compilers from the specification Remove the BlueGene compilers from the specification Aug 5, 2026
@bbiiggppiigg

Copy link
Copy Markdown
Member Author

@hainest do you want me to remove all reference to these compilers transitively?

Yeah. They are long dead, so we can completely scrub them.

@hainest done.

@hainest hainest left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM.

@hainest
hainest merged commit 9a1ec76 into master Aug 5, 2026
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants