Commit: PR 22823: Fix gcc 8 compile time warnings

[Maciej W. Rozycki]

Hi Nick,

> >  Unfortunately this has broken LD severely, in a host rather than target 
> > dependent manner I believe.
> 
> Yikes!  Sorry about that.  For some reason this problem does not show up
> on my machine, even when compiling at -O0.  We must be using slightly 
> different versions of the compiler.

 Undoubtedly, GCC 4.4.7 here.

> Please could you try out the attached patch and let me know if it solves
> the problem ?

 It does change code produced somewhat, by adding instructions between 
last MOVAPS and the call to `bfd_set_error'.  The prologue is unchanged 
however and hence the crash remains.  I wouldn't expect anything else, 
because the UB observed is from the mismatch between the prototype and the 
definition.

 Here's new disassembly for the record:

Dump of assembler code for function bfd_false_any:
0x0000000000455119 <bfd_false_any+0>:	push   %rbp
0x000000000045511a <bfd_false_any+1>:	mov    %rsp,%rbp
0x000000000045511d <bfd_false_any+4>:	sub    $0xe0,%rsp
0x0000000000455124 <bfd_false_any+11>:	mov    %rsi,-0xa8(%rbp)
0x000000000045512b <bfd_false_any+18>:	mov    %rdx,-0xa0(%rbp)
0x0000000000455132 <bfd_false_any+25>:	mov    %rcx,-0x98(%rbp)
0x0000000000455139 <bfd_false_any+32>:	mov    %r8,-0x90(%rbp)
0x0000000000455140 <bfd_false_any+39>:	mov    %r9,-0x88(%rbp)
0x0000000000455147 <bfd_false_any+46>:	movzbl %al,%eax
0x000000000045514a <bfd_false_any+49>:	mov    %rax,-0xe0(%rbp)
0x0000000000455151 <bfd_false_any+56>:	mov    -0xe0(%rbp),%rdx
0x0000000000455158 <bfd_false_any+63>:	lea    0x0(,%rdx,4),%rax
0x0000000000455160 <bfd_false_any+71>:	movq   $0x45519f,-0xe0(%rbp)
0x000000000045516b <bfd_false_any+82>:	sub    %rax,-0xe0(%rbp)
0x0000000000455172 <bfd_false_any+89>:	lea    -0x1(%rbp),%rax
0x0000000000455176 <bfd_false_any+93>:	mov    -0xe0(%rbp),%rdx
0x000000000045517d <bfd_false_any+100>:	jmpq   *%rdx
0x000000000045517f <bfd_false_any+102>:	movaps %xmm7,-0xf(%rax)
0x0000000000455183 <bfd_false_any+106>:	movaps %xmm6,-0x1f(%rax)
0x0000000000455187 <bfd_false_any+110>:	movaps %xmm5,-0x2f(%rax)
0x000000000045518b <bfd_false_any+114>:	movaps %xmm4,-0x3f(%rax)
0x000000000045518f <bfd_false_any+118>:	movaps %xmm3,-0x4f(%rax)
0x0000000000455193 <bfd_false_any+122>:	movaps %xmm2,-0x5f(%rax)
0x0000000000455197 <bfd_false_any+126>:	movaps %xmm1,-0x6f(%rax)
0x000000000045519b <bfd_false_any+130>:	movaps %xmm0,-0x7f(%rax)
0x000000000045519f <bfd_false_any+134>:	mov    %rdi,-0xd8(%rbp)
0x00000000004551a6 <bfd_false_any+141>:	lea    -0xd0(%rbp),%rax
0x00000000004551ad <bfd_false_any+148>:	movl   $0x8,(%rax)
0x00000000004551b3 <bfd_false_any+154>:	lea    -0xd0(%rbp),%rax
0x00000000004551ba <bfd_false_any+161>:	movl   $0x30,0x4(%rax)
0x00000000004551c1 <bfd_false_any+168>:	lea    -0xd0(%rbp),%rax
0x00000000004551c8 <bfd_false_any+175>:	lea    0x10(%rbp),%rdx
0x00000000004551cc <bfd_false_any+179>:	mov    %rdx,0x8(%rax)
0x00000000004551d0 <bfd_false_any+183>:	lea    -0xd0(%rbp),%rax
0x00000000004551d7 <bfd_false_any+190>:	lea    -0xb0(%rbp),%rdx
0x00000000004551de <bfd_false_any+197>:	mov    %rdx,0x10(%rax)
0x00000000004551e2 <bfd_false_any+201>:	mov    $0x5,%edi
0x00000000004551e7 <bfd_false_any+206>:	callq  0x44eda4 <bfd_set_error>
0x00000000004551ec <bfd_false_any+211>:	mov    $0x0,%eax
0x00000000004551f1 <bfd_false_any+216>:	leaveq 
0x00000000004551f2 <bfd_false_any+217>:	retq   
End of assembler dump.

 Perhaps GCC 8 would be kind enough to shut up if you made a non-prototype 
declaration of `bfd_false' as follows:

extern bfd_boolean bfd_false ();

and then reverted to using `bfd_false' where you changed it to 
`bfd_false_any'.  

 Unfortunately someone was clever enough to require parameter type lists 
to unconditionally match for two function types to be compatible, ruling 
out traditional use:

"For two function types to be compatible, both shall specify compatible 
return types.  Moreover, the parameter type lists, if both are present, 
shall agree in the number of parameters and in use of the ellipsis 
terminator; corresponding parameters shall have compatible types. [...]"

so the warning appears legitimate to me although (as Alan observed) it 
fails to trip on an ellipsis mismatch.

References:

[1] "Programming languages -- C", ISO/IEC 9899:201x, N1570 Committee Draft 
    -- April 12, 2011, Paragraph 6.7.6.3 "Function declarators (including 
    prototypes)", clause 15, p. 133

  Maciej