https://gcc.gnu.org/bugzilla/show_bug.cgi?id=123730
Bug ID: 123730
Summary: "a68: modules exports" vs.
'!targetm_common.have_named_sections'
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Keywords: build
Severity: normal
Priority: P3
Component: algol68
Assignee: algol68 at gcc dot gnu.org
Reporter: tschwinge at gcc dot gnu.org
CC: jemarch at gcc dot gnu.org
Target Milestone: ---
Target: nvptx
Per commit r16-5734-g51b5a394d93348d1ef85de394604bb35bacf7aed "a68: modules
exports":
This commit adds the code that handles the exports information for the
module definitions in prelude packets. The exports info is generated
in a section in the output object file.
[...]
'gcc/algol68/a68-exports.cc':
193 /* Make the exports section the asm_out_file's new current section. */
194
195 static void
196 a68_switch_to_export_section (void)
197 {
198 static section *exports_sec;
199
200 if (exports_sec == NULL)
201 {
202 gcc_assert (targetm_common.have_named_sections);
203 #ifdef OBJECT_FORMAT_MACHO
204 exports_sec
205 = get_section (A68_EXPORT_SEGMENT_NAME ","
A68_EXPORT_SECTION_NAME,
206 SECTION_DEBUG, NULL);
207 #else
208 exports_sec = get_section (A68_EXPORT_SECTION_NAME,
209 TARGET_AIX_OS ? SECTION_EXCLUDE :
SECTION_DEBUG,
210 NULL);
211 #endif
212 }
213
214 switch_to_section (exports_sec);
215 }
For nvptx:
a681: internal compiler error: in a68_switch_to_export_section, at
algol68/a68-exports.cc:202
0x1ce2f4d internal_error(char const*, ...)
[...]/source-gcc/gcc/diagnostic-global-context.cc:787
0x9280bb fancy_abort(char const*, int, char const*)
[...]/source-gcc/gcc/diagnostics/context.cc:1805
0x670d0e a68_switch_to_export_section
[...]/source-gcc/gcc/algol68/a68-exports.cc:202
[...]
This is not just some random ICEs during 'check-gcc-algol68', but it's a build
failure in 'libga68', for 'transput.a68'.
Targets, like nvptx, that (currently?) don't have a concept of sections, need
some other mechanism to emit and read back the exports information. Could this
be a separate file (as other front ends are doing, if I remember correctly)?
For nvptx, we also have any freedom we like to embed arbitrary textual
meta-data in the PTX code, via "directives" (expressed as comments), so that
could perhaps be used to emulate what we need here? (..., but there currently
is no implementation foreading that back, at GCC level.)
I've not yet looked into the topic any further, but thought, before I try to
invent anything, maybe anyone has any good suggestions?
