Re: do we still care about building with gcc-4.9?

Alan Modra <[email protected]>
Newsgroups gmane.comp.gnu.binutils
Message-ID <[email protected]>
On Wed, Jul 15, 2026 at 03:10:05PM +0200, Jan Beulich wrote:
> On 15.07.2026 15:02, Alan Modra wrote:
> > gcc-4.9 does not like the parentheses or cast in AARCH64_FIELD when
> > used in an initialiser:
> > 
> > opcodes/aarch64-opc-2.c:29:3: error: initializer element is not constant
> >    {AARCH64_OPND_CLASS_INT_REG, "Rd", OPD_F_HAS_INSERTER | OPD_F_HAS_EXTRACTOR, {AARCH64_FIELD (0, 5)}, "an integer register"},
> >    ^
> > opcodes/aarch64-opc-2.c:29:3: error: (near initialization for ‘aarch64_operands[1].fields[0]’)
> > 
> 
> To answer your question - I'd much prefer if we did. One of my main test
> systems is at 4.8.5.

Here's another one.  I'll put this on the branch too.
gcc-4.9 doesn't like an empty initialiser.

binutils/readelf.c: In function ‘process_relocs’:
binutils/readelf.c:10229:5: error: missing initializer for field ‘sh_name’ of ‘Elf_Internal_Shdr’ [-Werror=missing-field-initializers]
     Elf_Internal_Shdr section = {};

	* readelf.c (process_relocs): Avoid gcc-4.9 compile error.

diff --git a/binutils/readelf.c b/binutils/readelf.c
index f18fbfbe8b9..a52fe2b8d63 100644
--- a/binutils/readelf.c
+++ b/binutils/readelf.c
@@ -10226,12 +10226,12 @@ process_relocs (Filedata * filedata)
 		     is passed to readelf.  */
 		  uint64_t num_reloc;
 		  uint64_t *relrs = NULL;
-		  Elf_Internal_Shdr section = {};
-		  section.sh_offset
-		    = filedata->dynamic_info[DT_RELR];
-		  section.sh_size = rel_size;
-		  section.sh_entsize = rel_entsz;
-		  section.sh_type = SHT_RELR;
+		  Elf_Internal_Shdr section = {
+		    .sh_type = SHT_RELR,
+		    .sh_offset = filedata->dynamic_info[DT_RELR],
+		    .sh_size = rel_size,
+		    .sh_entsize = rel_entsz
+		  };
 		  validate_section_info (&section, NULL, 0, filedata);
 		  num_reloc = count_relr_relocations (filedata,
 						      &section,


-- 
Alan Modra
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.