Other callers of mark_single_function might also want to look through these
wrapapers.

	PR c++/104618

gcc/cp/ChangeLog:

	* decl2.cc (mark_single_function): Look through parens and location
	wrapper.
	* typeck.cc (cp_build_addr_expr_1): Not here.

	* fr.po, sv.po: Update.

	PR fortran/99585
	PR fortran/104430

gcc/fortran/ChangeLog:

	* trans-expr.cc (conv_parent_component_references): Fix comment;
	simplify comparison.
	(gfc_maybe_dereference_var): Avoid d referencing a nonpointer.

gcc/testsuite/ChangeLog:

	* gfortran.dg/class_result_10.f90: New test.

PR analyzer/101983 reports what I thought were false positives
from -Wanalyzer-malloc-leak, but on closer inspection, the
analyzer is correctly reporting heap-allocated buffers that are
no longer reachable.

However, these "leaks" occur at the end of "main".  The analyzer already
has some logic to avoid reporting leaks at the end of main, where the
leak is detected at the end of the EXIT basic block.  However, in this case,
the leak is detected at the clobber in BB 2 here:
  <bb 2> :
  func (&res);
  res ={v} {CLOBBER(eol)};
  _4 = 0;

  <bb 3> :
<L0>:
  return _4;

where we have a chain BB 2 -> BB 3 -> EXIT BB.

This patch generalizes the "are we at the end of 'main'" detection to
handle such cases, silencing -Wanalyzer-malloc-leak on them.

There's a remaining issue where the analyzer unhelpfully describes one
of the leaking values as '<unknown>', rather than 'res.a', but I'm
leaving that for a followup (covered by PR analyzer/99771).

gcc/analyzer/ChangeLog:
	PR analyzer/101983
	* engine.cc (returning_from_function_p): New.
	(impl_region_model_context::on_state_leak): Use it when rejecting
	leaks at the return from "main".

gcc/testsuite/ChangeLog:
	PR analyzer/101983
	* gcc.dg/analyzer/pr101983-main.c: New test.
	* gcc.dg/analyzer/pr101983-not-main.c: New test.

Signed-off-by: David Malcolm <dmalcolm@redhat.com>

gcc/fortran/ChangeLog:

	* array.cc (gfc_ref_dimen_size): Fix comment typo.
	* dump-parse-tree.cc (gfc_dump_c_prototypes): Likewise.
	* frontend-passes.cc (cfe_code): Likewise.
	* gfortran.texi: Likewise.
	* resolve.cc (generate_component_assignments): Likewise.
	* simplify.cc (gfc_simplify_this_image): Likewise.
	* trans-expr.cc (trans_scalar_class_assign,
	gfc_maybe_dereference_var): Likewise.
	* intrinsic.texi: Remove word duplication.
	* invoke.texi: Likewise.

As C++20 has already been published, we don't need to link to the draft
(which is now the C++23 draft anyway). And there's no need to say it's
part of the C++20 spec, or that there might be defect reports. That's
true for everything in C++20, so calling it out here just for Modules
isn't needed.

gcc/ChangeLog:

	* doc/invoke.texi (C++ Modules): Remove anachronism.

The _GLIBCXX_PSEUDO_VISIBILITY macro isn't defined until after including
os_defines.h, so we can't use _GLIBCXX_VISIBILITY early in c++config.
Replace the uses of that macro with #pragma visibility push(default)
instead.

libstdc++-v3/ChangeLog:

	PR libstdc++/104807
	* include/bits/c++config (__terminate, __glibcxx_assert_fail):
	Replace _GLIBCXX_VISIBILITY on function with visibility pragma.
	(__is_constant_evaluated): Add visibility pragma.

Note -fvar-tracking is enabled automatically with OPT_LEVELS_1_PLUS and
so we need to drop it if we are called from optimize attribute and the
option is unset.

	PR middle-end/104381

gcc/ChangeLog:

	* opts.cc (finish_options): If debug info is disabled
	(debug_info_level) and -fvar-tracking is unset, disable it.

gcc/testsuite/ChangeLog:

	* gcc.dg/pr104381.c: New test.

After more than 2 years I've run my
https://gcc.gnu.org/ml/gcc-patches/2017-02/msg00844.html
script again.  While it has lots of false positives, it discovered
two bugs.

2022-03-07  Jakub Jelinek  <jakub@redhat.com>

gcc/c/
	* c-parser.cc (c_parser_omp_clause_map): Add missing space in string
	literal.
gcc/cp/
	* parser.cc (cp_parser_omp_clause_map): Add missing space in string
	literal.

Like in r10-7215-g700d4cb08c88aec37c13e21e63dd61fd698baabc 2 years ago,
I've run
grep -v 'long long\|optab optab\|template template\|double double' *.{[chS],cc} */*.{[chS],cc} *.def config/*/* 2>/dev/null | grep ' \([a-zA-Z]\+\) \1 '
and for the cases that looked clearly wrong changed them, mostly by removing
one of the duplicated words but in some cases with other changes.

2022-03-07  Jakub Jelinek  <jakub@redhat.com>

gcc/
	* tree-ssa-propagate.cc: Fix up duplicated word issue in a comment.
	* config/riscv/riscv.cc: Likewise.
	* config/darwin.h: Likewise.
	* config/i386/i386.cc: Likewise.
	* config/aarch64/thunderx3t110.md: Likewise.
	* config/aarch64/fractional-cost.h: Likewise.
	* config/vax/vax.cc: Likewise.
	* config/rs6000/pcrel-opt.md: Likewise.
	* config/rs6000/predicates.md: Likewise.
	* ctfc.h: Likewise.
	* tree-ssa-uninit.cc: Likewise.
	* value-relation.h: Likewise.
	* gimple-range-gori.cc: Likewise.
	* ipa-polymorphic-call.cc: Likewise.
	* pointer-query.cc: Likewise.
	* ipa-sra.cc: Likewise.
	* internal-fn.cc: Likewise.
	* varasm.cc: Likewise.
	* gimple-ssa-warn-access.cc: Likewise.
gcc/analyzer/
	* store.cc: Fix up duplicated word issue in a comment.
	* analyzer.cc: Likewise.
	* engine.cc: Likewise.
	* sm-taint.cc: Likewise.
gcc/c-family/
	* c-attribs.cc: Fix up duplicated word issue in a comment.
gcc/cp/
	* cvt.cc: Fix up duplicated word issue in a comment.
	* pt.cc: Likewise.
	* module.cc: Likewise.
	* coroutines.cc: Likewise.
gcc/fortran/
	* trans-expr.cc: Fix up duplicated word issue in a comment.
	* gfortran.h: Likewise.
	* scanner.cc: Likewise.
gcc/jit/
	* libgccjit.h: Fix up duplicated word issue in a comment.

	PR target/104794

gcc/ChangeLog:

	* config/arm/arm.cc (arm_option_override_internal): Add missing
	space.

This reverts the reversion of r10-5979 amending the CTOR case
with a comment as to why the conversion is not necessary there.
It also adds a testcase (but not for the CTOR case).

2022-03-07  Richard Biener  <rguenther@suse.de>

	PR tree-optimization/104782
	* tree-vect-slp.cc (vectorize_slp_instance_root_stmt):
	Re-instantiate r10-5979 fix, add comment.

	* gcc.dg/vect/pr104782.c: New testcase.

	PR target/104797

gcc/ChangeLog:

	* config/msp430/msp430.cc (msp430_expand_delay_cycles): Remove
	parenthesis from built-in name.

	PR target/104794

gcc/ChangeLog:

	* config/arm/arm.cc (arm_option_override_internal): Fix quoting
	of options in error messages.
	(arm_option_reconfigure_globals): Likewise.

	PR target/104794

gcc/ChangeLog:

	* config/arm/arm-builtins.cc (arm_expand_builtin): Reuse error
	message.  Fix ARM_BUILTIN_WRORHI and ARM_BUILTIN_WRORH that can
	have only range [0,32].

The following testcase fails to assemble due to clgte %r6,0(%r1,%r10)
insn not being accepted by assembler.
My rough understanding is that in the RSY-b insn format the spot
in other formats used for index registers is used instead for M3 what
kind of comparison it is, so this patch follows what other similar
instructions use for constraint (i.e. one without index register).

2022-03-07  Jakub Jelinek  <jakub@redhat.com>

	PR target/104775
	* config/s390/s390.md (*cmp_and_trap_unsigned_int<mode>): Use
	S constraint instead of T in the last alternative.

	* gcc.target/s390/pr104775.c: New test.

PR translation/90148

gcc/fortran/ChangeLog:

	* intrinsic.cc (gfc_is_intrinsic): Remove asterisk from error
	message.

gcc/ChangeLog:

	* plugin.cc (default_plugin_dir_name): Remove <dir> from error
	message.

	PR translation/90148

gcc/ChangeLog:

	* config/rs6000/rs6000.cc (rs6000_linux64_override_options): Put
	quote to a proper place.
	* plugin.cc (default_plugin_dir_name): Likewise.

gcc/fortran/ChangeLog:

	* intrinsic.cc (gfc_is_intrinsic): Put
	quote to a proper place.

	PR target/99297

gcc/ChangeLog:

	* config/rx/rx.cc (rx_expand_builtin_mvtc): Fix translation
	string.

The following testcase ICEs, because the cond_andv* expander
has vector_operand predicates in both of the commutative inputs
and calls gen_andv*_mask which calls ix86_binary_operator_ok
in its condition, but nothing calls ix86_fixup_binary_operands_no_copy
during the expansion, which means cond_* accepts even operands
like 2 MEMs which then can't be matched.

The following patch handles it like most other insns that the other
cond_* patterns use - by having a separate define_expand that calls
ix86_fixup_binary_operands_no_copy and define_ins with
ix86_binary_operator_ok.

2022-03-07  Jakub Jelinek  <jakub@redhat.com>

	PR target/104779
	* config/i386/sse.md (avx512dq_mul<mode>3<mask_name>): New
	define_expand pattern.  Rename define_insn to ...
	(*avx512dq_mul<mode>3<mask_name>): ... this.
	(<code><mode>3_mask): New any_logic define_expand pattern.
	(<mask_codefor><code><mode>3<mask_name>): Rename to ...
	(*<code><mode>3<mask_name>): ... this.

	* gcc.target/i386/pr104779.c: New test.

There doesn't seem to be any reason for this TU to include
<iostream>, and it causes errors when the resulting libstdc++ is used
on our VxWorks 5.5 target - presumably because now libstdc++ itself
contains an instance of std::ios_base::Init. Which should be mostly
harmless, but apparently isn't, and from a QoI viewpoint should
probably be avoided anyway.

libstdc++-v3/ChangeLog:

	* config/locale/vxworks/ctype_members.cc: Remove <iostream>
	  include.

This updates gcc.dg/lower-subreg-1.c to reflect that the i386 backend now
lowers iordi3 itself, rather than relying on the middle-end's subreg1 pass.
Committed as obvious.

2022-03-06  Roger Sayle  <roger@nextmovesoftware.com>

gcc/testsuite/ChangeLog
	* gcc.dg/lower-subreg-1.c: Update test case.  iordi3 is no longer
	lowered by the RTL subreg1 pass on ia32 [even with -mno-stv].

This ensures there's no linker error if libstdc++ headers are included
following a pragma that sets hidden visibility.

Similarly for std::__terminate, which is always-inline so shouldn't
matter, but it's not wrong to do this anyway.

libstdc++-v3/ChangeLog:

	* include/bits/c++config (__glibcxx_assert_fail): Add visibility
	attribute.
	(__terminate): Likewise.

On Fri, Mar 04, 2022 at 02:58:37PM +0100, Jakub Jelinek via Gcc-patches wrote:
> On Thu, Mar 03, 2022 at 05:08:30PM -0700, Martin Sebor wrote:
> > > 1) shouldn't it give up for EDGE_ABNORMAL too?  I mean, e.g.
> > >     following a non-local goto forced edge from a noreturn call
> > >     to a non-local label (if there is just one) doesn't seem
> > >     right to me
> >
> > Possibly yes.  I can add it but I don't have a lot of experience with
> > these bits so if you can suggest a test case to exercise this that
> > would be helpful.
>
> Something like:
> void
> foo (void)
> {
>   __label__ l;
>   __attribute__((noreturn)) void bar (int x) { if (x) goto l; __builtin_trap (); }
>   bar (0);
> l:;
> }
> shows a single EDGE_ABNORMAL from the bar call.
> But it would need tweaking for the ptr use and clobber.
>
> > > 2) if EDGE_DFS_BACK is computed and 1) is done, is there any
> > >     reason why you need 2 levels of protection, i.e. the EDGE_DFS_BACK
> > >     check as well as the visited bitmap (and having them use
> > >     very different answers, if EDGE_DFS_BACK is seen, the function
> > >     will return false, if visited bitmap has a bb, it will return true)?
> > >     Can't the visited bitmap go away?
> >
> > Possibly.  As I said above, I don't have enough experience with these
> > bits to make (and test) the changes quickly, or enough bandwidth to
> > come up to speed on them.  Please feel free to make these improvements.
>
> I'll change that if it passes testing.

Here is a patch to do both.  I don't think we really need to have a testcase
for the EDGE_ABNORMAL case (Martin, feel free to add it later), abnormal
edges simply aren't normal control flow and what exactly it means varies.

2022-03-05  Jakub Jelinek  <jakub@redhat.com>

	* gimple-ssa-warn-access.cc (pass_waccess::use_after_inval_p): Remove
	visited bitmap and its use.  Also punt on EDGE_ABNORMAL edges.

This clean-up patch resolves PR testsuite/104732, the failure of the recent
test gcc.target/i386/pr100711-1.c on 32-bit Solaris/x86.  Rather than just
tweak the testcase, the proposed approach is to fix the underlying problem
by removing the "TARGET_STV && TARGET_SSE2" conditionals from the DI mode
logical operation expanders and pre-reload splitters in i386.md, which as
I'll show generate inferior code (even a GCC 12 regression) on !TARGET_64BIT
whenever -mno-stv (such as Solaris) or -msse (but not -msse2).

First a little bit of history.  In the beginning, DImode operations on
i386 weren't defined by the machine description, and lowered during RTL
expansion to SI mode operations.  The with PR 65105 in 2015, -mstv was
added, together with a SWIM1248x mode iterator (later renamed to SWIM1248x)
together with several *<code>di3_doubleword post-reload splitters that
made use of register allocation to perform some double word operations
in 64-but XMM registers.  A short while later in 2016, PR 70322 added
similar support for one_cmpldi2.  All of this logic was dependent upon
"!TARGET_64BIT && TARGET_STV && TARGET_SSE2".  With the passing of time,
these conditions became irrelevant when in 2019, it was decided to split
these double-word patterns before reload.
https://gcc.gnu.org/pipermail/gcc-patches/2019-June/523877.html
https://gcc.gnu.org/pipermail/gcc-patches/2019-October/532236.html
Hence the current situation, where on most modern CPU architectures
(where "TARGET_STV && TARGET_SSE2" is true), RTL is expanded with DI
mode operations, that are then split into two SI mode instructions
before reload, except on Solaris and other odd cases, where the splitting
is to two SI mode instructions is done during RTL expansion.  By the
time compilation reaches register allocation both paths in theory
produce identical or similar code, so the vestigial legacy/logic would
appear to be harmless.

Unfortunately, there is one place where this arbitrary choice of how
to lower DI mode doubleword operations is visible to the middle-end,
it controls whether the backend appears to have a suitable optab, and
the presence (or not) of DImode optabs can influence vectorization
cost models and veclower decisions.

The issue (and code quality regression) can be seen in this test case:

typedef long long v2di __attribute__((vector_size (16)));
v2di x;
void foo (long long a)
{
    v2di t = {a, a};
    x = ~t;
}

which when compiled with "-O2 -m32 -msse -march=pentiumpro" produces:

foo:    subl    $28, %esp
        movl    %ebx, 16(%esp)
        movl    32(%esp), %eax
        movl    %esi, 20(%esp)
        movl    36(%esp), %edx
        movl    %edi, 24(%esp)
        movl    %eax, %esi
        movl    %eax, %edi
        movl    %edx, %ebx
        movl    %edx, %ecx
        notl    %esi
        notl    %ebx
        movl    %esi, (%esp)
        notl    %edi
        notl    %ecx
        movl    %ebx, 4(%esp)
        movl    20(%esp), %esi
        movl    %edi, 8(%esp)
        movl    16(%esp), %ebx
        movl    %ecx, 12(%esp)
        movl    24(%esp), %edi
        movss   8(%esp), %xmm1
        movss   12(%esp), %xmm2
        movss   (%esp), %xmm0
        movss   4(%esp), %xmm3
        unpcklps        %xmm2, %xmm1
        unpcklps        %xmm3, %xmm0
        movlhps %xmm1, %xmm0
        movaps  %xmm0, x
        addl    $28, %esp
        ret

Importantly notice the four "notl" instructions.  With this patch:

foo:	subl    $28, %esp
        movl    32(%esp), %edx
        movl    36(%esp), %eax
        notl    %edx
        movl    %edx, (%esp)
        notl    %eax
        movl    %eax, 4(%esp)
        movl    %edx, 8(%esp)
        movl    %eax, 12(%esp)
        movaps  (%esp), %xmm1
        movaps  %xmm1, x
        addl    $28, %esp
        ret

Notice only two "notl" instructions.  Checking with godbolt.org, GCC
generated 4 NOTs in GCC 4.x and 5.x, 2 NOTs between GCC 6.x and 9.x,
and regressed to 4 NOTs since GCC 10.x [which hopefully qualifies
this clean-up as suitable for stage 4].

Most significantly, this patch allows pr100711-1.c to pass with
-mno-stv, allowing pandn to be used with V2DImode on Solaris/x86.
Fingers-crossed this should reduce the number of discrepancies
encountered supporting Solaris/x86.

2022-03-05  Roger Sayle  <roger@nextmovesoftware.com>
	    Uroš Bizjak  <ubizjak@gmail.com>

gcc/ChangeLog
	PR testsuite/104732
	* config/i386/i386.md (SWIM1248x): Renamed from SWIM1248s.
	Include DI mode unconditionally.
	(*anddi3_doubleword): Remove && TARGET_STV && TARGET_SSE2 condition,
	i.e. always split on !TARGET_64BIT.
	(*<any_or>di3_doubleword): Likewise.
	(*one_cmpldi2_doubleword): Likewise.
	(and<mode>3 expander): Update to use SWIM1248x from SWIM1248s.
	(<any_or><mode>3 expander): Likewise.
	(one_cmpl<mode>2 expander): Likewise.

gcc/testsuite/ChangeLog
	PR testsuite/104732
	* gcc.target/i386/pr104732.c: New test case.

On power10, GCC tries to optimize the signed conversion from DImode to
TImode by using the vextsd2q instruction.  However to generate this
instruction, it would have to generate 3 direct moves (1 from the GPR
registers to the altivec registers, and 2 from the altivec registers to
the GPR register).

This patch generates the shift right immediate instruction to do the
conversion if the target/source registers ares GPR registers like it does
on earlier systems.  If the target/source registers are Altivec registers,
it will generate the vextsd2q instruction.

2022-03-05   Michael Meissner  <meissner@linux.ibm.com>

gcc/
	PR target/104698
	* config/rs6000/vsx.md (UNSPEC_MTVSRD_DITI_W1): Delete.
	(mtvsrdd_diti_w1): Delete.
	(extendditi2): Convert from define_expand to
	define_insn_and_split.  Replace with code to deal with both GPR
	registers and with altivec registers.

gcc/testsuite/
	PR target/104698
	* gcc.target/powerpc/pr104698-1.c: New test.
	* gcc.target/powerpc/pr104698-2.c: New test.

	* de.po: Update.

This adds more correct .machine for most older CPUs.  It should be
conservative in the sense that everything we handled before we handle at
least as well now.  This does not yet revamp the server CPU handling, it
is too risky at this point in time.

Tested on powerpc64-linux {-m32,-m64}.  Also manually tested with all
-mcpu=, and the output of that passed through the GNU assembler.

2022-03-04  Segher Boessenkool  <segher@kernel.crashing.org>

	* config/rs6000/rs6000.cc (rs6000_machine_from_flags): Restructure a
	bit.  Handle most older CPUs.

gcc/po/
	* be.po, da.po, de.po, el.po, es.po, fi.po, fr.po, hr.po, id.po,
	ja.po, nl.po, ru.po, sr.po, sv.po, tr.po, uk.po, vi.po, zh_CN.po,
	zh_TW.po: Update.

libcpp/po/
	* be.po, ca.po, da.po, de.po, el.po, eo.po, es.po, fi.po, fr.po,
	id.po, ja.po, nl.po, pt_BR.po, ru.po, sr.po, sv.po, tr.po, uk.po,
	vi.po, zh_CN.po, zh_TW.po: Update.

The std manglings for things like std::string should not apply if
we're not in the global module.

gcc/cp/
	* mangle.cc (is_std_substitution): Check global module.
	(is_std_substitution_char): Return bool.
gcc/testsuite/
	* g++.dg/modules/std-subst-2.C: New.
	* g++.dg/modules/std-subst-3.C: New.
	* g++.dg/modules/std-subst-4_a.C: New.
	* g++.dg/modules/std-subst-4_b.C: New.
	* g++.dg/modules/std-subst-4_c.C: New.

Fix-up for recent commit 8935589b
"OMP lowering: Regimplify 'OMP_CLAUSE_MAP_DECL_MAKE_ADDRESSABLE' DECLs
[PR100280, PR104132, PR104133]": adjust for a GCN offloading workaround
added just before commit: '(volatile void *) &f1;'.

	PR testsuite/104791
	libgomp/
	* testsuite/libgomp.oacc-c-c++-common/kernels-decompose-1.c: Fix
	expected diagnostics.

PR analyzer/103521 reports that commit r12-5585-g132902177138c09803d639e12b1daebf2b9edddc
("analyzer: further false leak fixes due to overzealous state merging [PR103217]")
led to failures of gcc.dg/analyzer/pr93032-mztools.c on some targets,
where rather than reporting FILE * leaks, the analyzer would hit
complexity limits and give up.

The cause is that pr93032-mztools.c has some 'unsigned char' values that
are copied to 'char'.  On targets where 'char' defaults to being signed,
this leads to casts, whereas on targets where 'char' defaults to being
unsigned, no casts are needed.

When the casts occur, various symbolic values within the loop (the
locals 'crc', 'cpsize', and 'uncpsize') become sufficiently complex as
to hit the --param=analyzer-max-svalue-depth= limit, and are treated as
UNKNOWN, allowing the analysis of the loop to quickly terminate, with
much of this state as UNKNOWN (but retaining the FILE * information, and
thus correctly reporting the FILE * leaks).

Without the casts, the symbolic values for these variables don't quite
hit the complexity limit, and the analyzer attempts to track these
values in the loop, leading to the analyzer eventually hitting the
per-program-point limit on the number of states, and giving up on
these execution paths, thus failing to report the FILE * leaks.

This patch tweaks the default value of the param:
  --param=analyzer-max-svalue-depth=.
from 13 down to 12.  This allows the pr93032-mztools.c testcase to
succeeed with both -fsigned-char and -funsigned-char, and thus allows
this integration test to succeed on both styles of target without
requiring extra command-line flags.  The patch duplicates the test so
it runs with both -fsigned-char and -funsigned-char.

My hope is that this will allow similar cases to terminate loop analysis
earlier.  I tried reducing it further, but doing so caused some test
cases to regress.

The tradeoff here is between:
(a) precision of individual states in the analysis, versus
(b) maximizing code-path coverage in the analysis

I can imagine a more nuanced approach that splits the current
per-program-point hard limit into soft and hard limits: on hitting the
soft limit at a program point, go into a less precise mode for states
at that program point, in the hope that we can fully explore execution
paths beyond it without hitting the hard limit, but this seems like
GCC 13 material.

Another possible future fix might be for the analysis plan to make an
attempt to prioritize parts of the code in an enode budget, rather than
setting the same hard limit uniformly across all program points.

gcc/analyzer/ChangeLog:
	PR analyzer/103521
	* analyzer.opt (-param=analyzer-max-svalue-depth=): Reduce from 13
	to 12.

gcc/testsuite/ChangeLog:
	PR analyzer/103521
	* gcc.dg/analyzer/pr93032-mztools.c: Move to...
	* gcc.dg/analyzer/pr93032-mztools-signed-char.c: ...this, adding
	-fsigned-char to args, and...
	* gcc.dg/analyzer/pr93032-mztools-unsigned-char.c: ...copy to here,
	adding -funsigned-char to args.

Signed-off-by: David Malcolm <dmalcolm@redhat.com>

We don't need it, and it breaks uclibc.

	PR go/101246

Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/390021

golang/x/sync/semaphore is required by gofmt.go.

Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/388634

Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/388635

DECL_MD_FUNCTION_CODE() returns an int, on one particular compiler the
code in darwin_fold_builtin() triggers a warning.

Fixed thus.

Signed-off-by: Iain Sandoe <iain@sandoe.co.uk>

gcc/ChangeLog:

	* config/darwin.cc (darwin_fold_builtin): Make fcode an int to
	avoid a mismatch with DECL_MD_FUNCTION_CODE().