On Thu, Jun 18, 2020 at 12:03:26PM +0200, Richard Biener wrote:
> Shortly thought about it but then went with int because of the
> pre-existing interface of output_constant_def which "interferes"
> with this (ripples down into users in expr.c as well).
>
> If you insist I'll hunt them all down ...
On Thu, 18 Jun 2020, Jakub Jelinek wrote:
> On Thu, Jun 18, 2020 at 11:08:53AM +0200, Richard Biener wrote:
> > This avoids early assembler output via the gimplifier creating
> > new static CTORs. The output machinery seems to be prepared to
> > output constants recursively and it's just a matter
On Thu, Jun 18, 2020 at 11:08:53AM +0200, Richard Biener wrote:
> This avoids early assembler output via the gimplifier creating
> new static CTORs. The output machinery seems to be prepared to
> output constants recursively and it's just a matter of
> appropriately defering or not defering output
This avoids early assembler output via the gimplifier creating
new static CTORs. The output machinery seems to be prepared to
output constants recursively and it's just a matter of
appropriately defering or not defering output.
This also has the advantage of not outputting .string for
optimized a